From the spec, it does not seem to be mandated to check that the random
identity needs to be unique within a cell. Also, from experience we see
that this only happens when the same UE "comes back"; so since one UE
can only have one connection, the other RRC UE contexts (with the same
identity) should be removed at some point, anyway, leaving only one with
the same identity.
They use 4G NUMBER_OF_UE_MAX, which is not supposed to be present in 5G.
Further, the mutex and variable are global state; for Paging, we should
use F1.
We can only support up to 30 UEs for SRS. In this commit, we change:
- if the total number of UEs is > 32, throw error during compilation to
raise awareness (32 so that a multiple of two still works, everything
else is confusing, see also next point)
- during runtime, handle gracefully if UID is 30 or 31 to not abort (we
can simply not allocate SRS resources)
Also, refactor config_srs() to always give back new memory; the code is
shorter and clearer. Rename to get_contig_srs() to make it explicit.
- PDCP reestablishment on CUCP (DRBs) triggering Bearer Context Modification procedures over E1
- Performing PDCP reestablishment for requested DRBs on CUUP
- Introduced function to notify re-establishment to CU-UP
- removed call to PDCP reestablishment for the DRBs on CUCP (it's done on CUUP)
cuup_notify_reestablishment:
- to fetch PDU session to setup in E1 following logic as in e1_send_bearer_updates
- fill bearer context modification request with stored F1-U tunnel information
during E1 reestablishment, otherwise it would initialized to 0 by default
- update GTP tunnel with the stored configuration after E1 reestablishment
The previous code removed the "secondary UE" data (about DU association,
DU UE ID, associated CU UP), and only filled the F1-related data. In
other words, the associated CU-UP was lost. This commit reworks this
piece of code to retrieve old data, and update the relevant data without
destroying other.
- many structs and definitions are overlapping between the two different E1 procedures
- introduced naming specific to E1 Bearer Context Modification to improve readability
- grouped SDAP and PDCP configuration IEs for better reusability and readability
- introduced functions to set and get default PDCP config (DRBs and Bearer Contexts)
find_or_next_pdu_session:
- find_or_next_pdu_session refers to the E1 Bearer Context Modification Request
-- therefore it has to return pdu_session_to_mod_t* and takes in input e1ap_bearer_mod_req_t *
see !MR2545 for more context
- according to specs, in NR there are 4 SRBs
- in OAI the relevant define is used in the RRC procedures
- this commit harmonizes code by removing redundancy
- triggered by RRC reconfiguration events according to clause 5.3.5.6.5 of TS 38.331
- This procedure does QoS flow to DRB mapping according to clause 5.3.1 of TS 37.324
- QoS flows to DRBs to be released are also handled
for FR2 offsetToPointA is expressed in terms of 60 kHz SCS and k_SSB expressed in terms of the subcarrier spacing provided by the higher-layer parameter subCarrierSpacingCommon
- Phy configuration will be prepared by MAC
- Sidelink preconfiguration parameters passed from RRC->MAC
- Only 1 SSB TA allocation used
- psbch payload prepared by MAC after receiving the tx slss req
francescomani