While testing the OAI 5G RAN in SA mode, it appears that the PDU session
establishment request is using the wrong security header type.
The current used header is: "Integrity protected and ciphered with new
5G NAS security context".
However, according to TS 24.501, Table 9.3.1, this header can only be used
by the "Security mode complete" procedure.
Changes:
- Hence, the new security header has been changed to "Integrity protected
and ciphered", which will use the security context generated during the
"Security mode complete".
- Sequences numbers and NAS counters have been updated to reflect that
change.
remove several unused files
remove mem_block_t that is never used in a different way than a simple heap buffer
move up IP address type and remove duplications of the same struct declaration
Remove dead code, result of 2136ceec0d: we
cannot connect() in GTP on multiple remotes (as then only packets of one
host might be received), but might need to send to multiple remote
sockets.
Introduce a --no-itti-threads command line option to disable threading
in ITTI, and call message handlers in the current thread. This is being
introduced in order to increase repeatability when testing the nrUE with
the IQPlayer. Without this feature, runs with the IQPlayer will end up
differently, depending on the timing of ITTI threads, mostly when
sending messages to RRC and NAS.
This allows to communicate with multiple remote hosts. A further
improvement would be to refactor this piece of code into a function and
call it only when necessary, i.e., when we know the remote host, or want
to add one to a list of hosts.
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.
Laurent THOMAS