This branch series implements the usage of the F1 Setup Request
internally at the gNB, even if CU and DU run in the same process. Until
now, the F1 Setup Request contained struct fields to pass IP
configuration to the F1AP module; this information is not necessary in
monolithic, nor should it be relevant when passing the information in
F1 Setup Request.
Therefore, this commit moves all IP connection-related information out
of the F1 Setup Request and into a separate structure instead. In order
to give the F1AP module the necessary connection information, the
DU_REGISTER_REQ message is introduced that combines the F1 Setup Request
and IP configuration, such that the F1AP module can setup the SCTP
connection and then send the F1 Setup Request message.
In a later commit, there will be a callback for F1 Setup Request at MAC
to simply register the DU at the CU. The monolithic callback will simply
forward the F1 Setup Request The F1AP callback will look up the IP
configuration and create DU_REGISTER_REQ message containing IP
configuration and F1 Setup Request, which is then handled by the F1AP
module. To this end, a separate function in gnb_config.c allows to read
IP information from configuration.
Instead of storing the F1 Setup Request implicitly in F1 context, we
provide the F1 Setup Request message to be encoded explicitly to the
encoding function.
In the case of MIMO, we reused memory to point to the same PUCCH
resource. This is problematic, since ASN_STRUCT_FREE() would try to free
this resource twice.
This commit changes to create distinct memory for the PUCCH resources,
while putting the same configuration to still use the same PUCCH
resource from a radio configuration point of view.
integration_2023_w36
See merge request oai/openairinterface5g!2333
* !2185 DL delay compensation
* !2255 Add condition to call or not the function nr_mac_prepare_ra_ue()
* !2301 NR UE handling MCS for retransmissions
* !2308 Heap Allocation issue: Removed Dynamic allocation
* !2317 bugfix: don't force an UE to support en-dc, respect its capabilities
* !2318 Set security for all active SRBs after NR_RRCReestablishment
* !2321 Use appropriate CMake flags to link to UHD
* !2332 T tracer: add a trace for NR SIB1
* !2322 Remove small races in ue
* !2323 NR UE fix DCI candidates
* !2328 Add SRB1 and SRB2 received bytes to statistics
integration_2023_w34
See merge request oai/openairinterface5g!2316
* !2283 going back to sync mode when cell is barred in MIB
* !2290 fix gtp delete. we should not delete all bearer in case of dedicaded bearer release
* !2299 fix-mem-overflow_64qam
* !2288 NR UE avoid crashes upon renewal of SIB1
* !2279 web server enhancement and doc link fix
* !2302 Tutorials: update links for Open Cells SIM Card programming tool and Ubuntu 22.04 LTS
* !2303 NR gNB limit on PUCCH bits to be scheduled
* !2207 Use F1 internally: UE Context Modification Required
* !2315 Fix LCID to RB association, allow more than 8 LCIDs in the UE
integration_2023_w33
See merge request oai/openairinterface5g!2300
* !2247 Fix cppcheck warnings related to nullPointerArithmeticRedundantCheck
* !2250 Fix cppcheck warnings related to negativeIndex
* !2281 avoid NR UE stalling if SIB not decoded
* !2273 NR_UE: fix limited UL data throughput in do-ra mode
* !2295 hack: see Bye. message when quitting gnb running with aw2s
* !2298 mapping LCID to RBID to index RLC entities
* !2267 Make read-only global variables const, additional fixes
* !2297 nr rlc: change retx logic
* !2230 Readme correction
* Lower scheduler PF averaging constant
This time constant plays a major role in how long a UE has to wait
maximally before it might be scheduled. For instance, if a UE had a lot
of traffic, the average traffic will be high, pushing the PF coefficient
down. If another UE with no traffic in the past becomes active with
heavy traffic, the first UE might not be scheduled for an extended
period of time.
In the AW2S-Amarisoft UE CI test pipeline, we sometimes see that the
maximum number of RLC retransmissions was reached. While this might not
be the (only) cause, scheduling a UE more often might prevent such
situations, and we saw an improved stability.
After removing RA.crnti, there is no need to use a separate function
nr_generate_Msg3_dcch_dtch_response() to generate Msg.4 (yes, the
function mentions Msg3 but it does Msg3 response == Msg.4).
Also, using nr_generate_Msg4() has the advantage that it waits until we
have the reconfiguration available in RLC to be sent to the UE. Finally,
we can delete the old nr_generate_Msg3_dcch_dtch_response() as we don't
need it anymore.
The RA.crnti field is marked as being used by NSA mode, but it is not.
OTOH, it is used in the case of RA with Msg.3 with C-RNTI MAC CE. The
latter does not necessarily need it, though, as we can change the RNTI
of the RA process when we receive C-RNTI MAC CE.
This introduces a slight complication, though, as we cannot remove the
MAC UE Context (generated when receiving Msg.3) directly when parsing
the C-RNTI MAC CE. Previously, we had both rnti and crnti in the RA
struct, and when sending Msg.4 after Msg.3 with C-RNTI MAC CE, we would
remove the UE context (this is changed in the next commit). Therefore,
we employ nr_mac_trigger_release_timer() which releases the UE after
60ms, circumventing this complication.
The RRC should not trigger RLC bearer establishment: this should be done
only via F1, and in the remaining code (removed here), this principle
was violated.
Further, this code was doubly wrong, as it used the CU UE ID for the
RLC, setting up bearers with IDs 1,2,3 etc instead of the RNTI.
The MAC_NR target is not needed; every dependent target also links
L2_NR. Therefore, this target just creates double compilation. We can
remove it without problems.
integration_2023_w32
See merge request oai/openairinterface5g!2293
* !2061 Rel16 NR PRS improvements
* !2113 handle TDD pattern2 at UE
* !2266 Use cmake3 command if on RHEL
* !2287 Initialize OAIgraph before usage
* !2285 Fix alignment of Tpool user data to 32 bytes
* !2284 USRP driver: Make it compile for UHD < 4.0.0
* !2214 Use F1 Internally: switch to CU UE ID in CU
This commit repairs the reestablishment after the introduction of the CU
UE ID in the CU, different from the DU UE ID. Now, the CU uses an
identifier different from the RNTI, used in the MAC, to refer to UEs.
To repair the reestablishment, a number of changes needed to be
introduced:
- Handle old_gNB_DU_UE_id in MAC
The MAC handles the old_gNB_DU_UE_id field in the DL RRC Message. The
commit adds encoding/decoding of the field. The MAC will drop the old
UE, but retain the CellGroup of the corresponding UE(!). Because a UE
releases the spCellGroup on reestablishment, the MAC does the same; it
needs to reapply the old configuration after a reconfiguration. For the
latter, introduce new variables to keep a "future" CellGroupConfig to be
applied (reconfigCellGroup) and a flag (expect_reconfiguration) that
applies the CellGroupConfig if a DL RRC Message transfer on DCCH, which
is assumed to be the reconfiguration.
- Add RNTI change in RLC
The RLC needs to reuse the old UE context. Hence, we simply change the
RNTI in the old context, and delete the new one.
- No PDCP UE ID change
The previous implementation of the PDCP used the RNTI; hence, the ID
needed to be switch (as above for the RLC). Since the PDCP now also uses
the CU UE ID, no identifier change is needed, and we remove all
corresponding code.
- No MAC modifications/update from CU
As foreseen by the spec, the CU does not modify or change the
cellGroupConfig in the RRC during reestablishment. This change will be
generalized in the future to all of the RRC. Also, the
nr_rrc_mac_remove_ue() function has been removed: the MAC handles any UE
changes autonomeously, without being triggered from the RRC explicitly.
- Remove reestablish_rnti_map
The RRC does not use RNTIs for UE identification. Hence, a
reestablish_rnti_map to link two UEs to each other is not necessary
anymore.
After a reestablishment, the PDCP sequence number counters have to be
reset. Implement an API to allow the RRC to reset the sequence numbers
for a particular UE in the case of reestablishment
The RRC gives its own RRC UE ID. It won't intervene if DUs assign the same RNTI to different UEs: it simply does not care what the DUs do with the RNTI.
- Use the same CU-UP in E1 as in CU-CP: we don't have a separate entity
to allocate IDs, and we just use the same as the CU-CP
- Correct gNB CU-UP/CP UE IDs in E1AP message types to 32bit
- Set CU UP UE ID explicitly for clarity
- Remove RNTI from E1 messages, E1 does not know what an RNTI is
The UE had a list of known UEs. With the introduction of a separate
module for F1 UE ID handling that is also used in monolithic (to
separate CU UE ID from DU UE ID), this functionality is not needed, and
deleted in this commit.
Previously, the F1AP handler called various functions directly, instead
of sending an ITTI message to the RRC thread. This has two drawbacks:
- it can lead to data races if the RRC task uses functionality that is
being accessed by the F1 task through this function
- no homogeneity: all other handlers send an ITTI message, so this one
should too
- The CU/DU UE ID is used in DL RRC Message Transfer
- Note: The CU UE ID currently is still the RNTI
- on every DL RRC Message, the DU verifies that the UE exists
- Refactor RRC: common function to forward protected SRB PDUs
Robert Schmidt