- 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
- 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
This commit introduces a separate thread (l1_tx_thread) that processes
gNB DL/TX slots. It receives a message from the ru_thread when a new
slot started, and starts processing.
The DL part of the scheduler is run in the l1_tx_thread. Therefore,
only call UL indication (for scheduler) in UL slots. The UL indication
previously triggered the DL scheduler -- hence, it had to be called in
every slot. Now, since the DL scheduler is moved into the DL thread, we
don't have to call the scheduler in every slot anymore.
The reorder thread is removed, as reordering with this scheme is not
necessary anymore.
The main advantage of this version is that the TX can be scheduled
earlier (sl_ahead). Further, there can no longer be race conditions in
the TX path, since the scheduler/L2, TX L1 processing and the RU tx
function are all execute in the same thread (L1_tX_thread).
Also, the scheduler prepares PRACH/PUSCH/PUCCH FAPI PDUs. As of this
commit, the scheduler runs in the TX processing chain, whereas these
PDUs are destined for RX processing. Thus, too avoid data races,
instead of triggering the RX processing at the same time as TX
processing in the RU thread, this commit changes the code to trigger RX
processing after the scheduler has been run in TX processing to avoid
data races.
Finally, we synchronize RU and L1 threads. This is important for
rfsimulator, since unlike most radios, rfsimulator can run slower or
faster, depending on I/O and CPU (it does not have a stable "tick").
Co-authored-by: kiran <saikiran@iitj.ac.in>
The next commit introduces a separate gNB TX processing thread. To
properly separate DL scheduler (for scheduling decisions) from UL
indication handling (for UL packets), this commit introduces a slot
indication "tick" to run the DL scheduler which will be put into the gNB
TX processing chain instead of the UL indication.
For different reasons, the frame/slot numbers might jump (e.g., gNB and
RU machines not properly synced). The scheduler would assert for PUCCH
allocations. Handle this gracefully by printing an error message, and
resetting the PUCCH structure.
- create hash table to save ric_req_id (key) and array of ran_param_id(s) (values), per each subscription
- create RB tree to store list of ric_req_id(s) for each ran_param_id
=> when the async event occurs, it is easier and faster to search per ran_param_id and send the indication message to all xApps (ric_req_id(s)) subscribed to the same ran_param_id
- it is important to mention that both data structures need to be maintained, especially when unsubscription occurs (free_aperiodic_subscription)
We used to trigger the UECapabilityEnquiry right after
SecurityModeComplete, and before the RRCReconfiguration (which we call
"default" reconfiguration). However, 38.401 tells us that we should send
the RRCReconfiguration right after the SecurityModeComplete. In fact,
even though we get the UE capabilities, we cannot use them during this
reconfiguration, as we would first need to update the DU with a UE
Context Modification Request, which we cannot, as we just sent the UE
Context Setup Request, and the DU relies on first getting the
RRCReconfiguration.
Since we rely on a subsequent reconfiguration anyway, we can safely
trigger the UECapabilityEnquiry after RRCReconfigurationComplete.
(38.331 also says we can send UECapabilityEnquiry at any point.)
To cater for the possibility that there might not be any reconfiguration
coming afterwards, we check if a DRB has been set up. If not, we assume
a reconfiguration will come, and do not trigger one only for the UE
capabilities (this is what we do before this commit). If we already have
DRBs set up, they might have been set up during the "default" RRC
Reconfiguration, and another reconfiguration might not follow soon; in
this case, we trigger the reconfiguration by sending the UE capabilities
to the DU right away.
The next commit moves the UE Capability Enquiry after the first
reconfiguration. This has the effect that for some UEs (e.g., iPhone),
the Setup Requests come too close to each other, triggering RRC
Reconfigurations while previous transactions are ongoing.
I think the "true" solution would be to implement some tracking of
transactions across RRC, F1AP, E1AP, but this might require many
changes. For the moment, limit to delaying PDU session resource setups
to prevent above problem. Delaying is done using ITTI timers (to be able
to serve other UEs), waiting 10ms each time, up to 20 times (to not
deadlock the transaction -- after all, if the UE is unhappy, it will
drop the connection).
This commit allows the gNB to handle PDU sessions that the core requests
to setup during the NGAP Initial UE Context Setup. Previously, we only
managed them as part of PDU Session Resource Setup Request.
The RRC will, depending on whether a PDU session is in the NGAP Initial
UE Context Setup, either directly trigger the Security Command, or first
do a bearer setup at the CU-UP. Some asserts have been lifted, as now
the PDU sessions might be present before the RRC Connection is fully
established.
Implement the correct forwarding of the bearers in an F1 UE Context
Setup Request message.
This solves bug #672.
Guido Casati