Also, this commit changes the len argument in the
pusharray32 to match the actual field type (uint16_t).
There is also simple name change from sf -> slot.
The new queueing system is not a permanent solution.
It was simply a way for us to try to handle late
dl_tti_requests. If we queue every single ul_tti_req
that we get, the queue gets full very quickly becasue
we only remove ul_ttis from the queue when a uci has
been populated with a matching sfn/sf. Because of this,
we only queue ul_ttis if we have a uci_indication
prepared already. Rarely, a dl_tti_req will arrive at
the NRUE too late, and the NRUE does not have time
to create the uci_ind so we dont process the corresponding
ul_tti. A seprate queue was made to hold all other ul_ttis
the arrive in the NRUE (this queue will continuously
get full and then emptied) but will occasionally hold
a ul_tti that corresponds to a uci that hasnt
been populated yet.
-Add also a temporary artificial trigger just to be able to test with OAI UE
-Comment out most of the part of the UE context release command handler function at the DU in order to separate properly the RRC from F1AP functionality later.
This commit changes the stub functionality entirely.
We are now queueing any received NR nFAPI message
and handling it only after we recevie a slot ind
that corresponds with the nFAPI message's sfn/slot
value. When doing this, an existing issue has been
brought to light. The gNB and NR UE are not in sync
when it comes to their slot indications. Generally,
the NR UE seems to be ahead of the gNB by around 6-7
slots. This commit has a hack... when we receive a
slot indication at the moment, we decrament it by 6
to try to keep the NRUE from being ahead of the gNB.
This will be fixed shortly... This was a temporary
fix..
-F1 message successfully encoded at the CU (including SRB2, DRB and F1-U tunnel configuration) and received from the DU.
-Next steps: handling of UE context modification request at the DU and triggering the UE context setup response towards the CU.
-Trigger UE context setup response at the DU and RRC Reconfiguration at the CU upon reception of UE context setup response.
-Pending: The DU should generate some updates on the master cell groupconfig based also on the received UE capabilities and add them in
the UE context setup response message so that they can be included in the RRC Reconfiguration message sent from the CU. For the moment the
corresponding function is empty.
-Next steps: trigger UE context modification procedures
-Include UE_Capability_RAT_container_list in UE context setup request so that it gets processed at the DU
-Next steps: DU should store and process the UE capabilities and generate updates in master cell group config
to be included in UE context setup response. Then upon reception of UE context setup response, the first RRC Reconfiguration
can be triggered at the CU with the updates on master cell group config.
Laurent THOMAS