For nr_DRB_preconfiguration() and fill_default_secondaryCellGroup(),
there is duplicated code to generate and RLC-BearerConfig, when calling
the existing get_DRB_RLC_BearerConfig() (with the right parameters)
yields a similar configuration (see exceptions below).
Differences:
- We do not support reestablishmentRLC, so we don't set it
- Set prioritisedBitrate to 8kbps instead of infinity (we don't
prioritize anything, anyway)
- bucketSizeDuration is 50ms instead of 100ms
Cosmetic changes, also changed the LOG message for updating the UEid, and moved the drb_id_to_setup_start and nb_drb_to_setup right before the function that they are used
Simplify RRCReestablishmentComplete procedure with respective function,
removed the block that creates the ASN1 DRBs and created a function, with doxygen
Simplify RRCReestablishmentComplete procedure with respective function,
removed the block that updates NGU Tunnels and created a function, with doxygen
Simplify RRCReestablishmentComplete procedure with respective function,
removed the block that updates NAS PDUSession and created a function, with doxygen
Cosmetic changes, added doxygen configuration, and changed the rrc_gNB_process_RRCReestablishmentComplete function arguments' alignment, so in the future if an argument is removed or added to be better visible in the commits
The generateDRB function now creates a DRB and puts it in the struct member of gNB_RRC_UE_t, from this struct we can generate ASN1 messages by calling the generateDRB_ASN1
The GTP module is common for 4G and 5G. It hardcodes the functions to
call when creating S1U and NGU tunnels. The S1U case is both applicable
for LTE and NR (NSA), which until now was not a problem as the PDCP data
forwarding functions where called pdcp_data_req. The issue is that in this
branch, the NR PDCP functions have changed to nr_pdcp_data_req_drb().
When setting up a GTP tunnel, we now pass the PDCP data forwarding
functions into GTP, since the caller knows whether it is in 4G or 5G,
but GTP itself does not.
Creates function that have nr_pdcp_ prepended to their name, and change
the signature of some functions for the 5G PDCP:
- nr_pdcp_layer_init()
- nr_pdcp_data_req()
- nr_pdcp_remove_UE()
- nr_pdcp_config_set_security()
- nr_pdcp_remove_UE()
- Make separate functions for nr_pdcp_data_req_srb/drb()
The message is never sent to the RRC. And this message is to be
forwarded by the DU to the UE, hence it should not even be handled by
the RRC (as the RRC in the CU sends it).
Robert Schmidt