Use 5G-S-TMSI as UE identity in RRCSetupRequest
This MR includes the following implementation:
- Handle 5G-S-TMSI in RRCSetup:
- Set the ue-Identity to ng-5G-S-TMSI-Part1 in RRCSetupRequest and
- If RRCSetup is received in response to an RRCSetupRequest: set the
ng-5G-S-TMSI-Value to ng-5G-S-TMSI-Part2 in do_RRCSetupComplete
TS 38.331 5.3.3.3 Actions related to transmission of RRCSetupRequest message:
The UE shall set the contents of RRCSetupRequest message as follows:
1> set the ue-Identity as follows:
2> if upper layers provide a 5G-S-TMSI:
3> set the ue-Identity to ng-5G-S-TMSI-Part1;
- Pass 5G-S-TMSI to RRC when NAS receives GUTI in Registration Accept
- NAS extracts GUTI from Registration Accept
- send ITTI indication from NAS to RRC when GUTI is available and store
5G-S-TMSI in RRC instance
- Rework of Initial UE message handling in RRCSetupComplete: simplify code and memory management
- Fix for integrity failure after UE comes back from RRC IDLE
- Other NAS fixes
Note:
- Initial implementation of Initial NAS Message: Service Request -> moved to !3065 (merged)
- Rework of Registration Request added to !3176 (merged)
Closes#772
After a new connection from RRC IDLE, an integrity failure occurs. This
commit is addressing this issue to pass the integrity check.
* Reset ciphering and integrity algorithms when going into RRC IDLE
* Use uplink NAS COUNT in Registration Request for initial KgNB derivation
* Temporarily deriving UP protection keys in Registration Request
* Note: AS SMC handling should be done according to 33.501 §6.8.1.1.2.2
* Use the 5G-S-TMSI stored in RRC to be used as UE identity
* Use 5G-S-TMSI part 1 in RRCSetupRequest encoding (TS 38.331 clause 5.3.3.3)
* Set the ng-5G-S-TMSI-Value in RRCSetupComplete to ng-5G-S-TMSI-Part2 (5.3.3.4 of 3GPP TS 38.331)
* current and only scenario: RRCSetup is received in response to an RRCSetupRequest
* use initialNasMsg to store nas messages buffer and length
* buffer is dynamically allocated in generateRegistrationRequest, so do the
same in NSA and free dynamic allocated data afterwards
* NAS -> RRC: RRC receives an ITTI message with NAS 5GMM indication message
containing the 5G-S-TMSI derived from NAS GUTI
* 5G-S-TMSI is stored in the RRC instance and to be later encoded in the RRCSetup
fix NTN LEO scenarios
- gNB: add support for NTN parameter ta-CommonDrift-r17
- NR UE: fix application of NTN TA information
- NR UE: add command line parameter ntn-initial-time-drift to compensate
time drift during initial sync
- NR UE: fix writeTimestamp inconsistencies
- NR UE: add MAC state UE_RECEIVING_SIB ensuring to start RA only after
successfully receiving SIBs
- rfsimulator: update earth radius for LEO simulation to match UE
position in ue.conf file
- update conf files for NTN LEO scenario
- update description how to run NTN scenarios in RUNMODEM.md
- fix: ta-Common is a round-trip-time, not a one-way delay
- NR UE: simplify calculation of next_tx_slot_and_frame by moving up
assignment of duration_rx_to_tx
- cellbarredNTN indicates notbarred in SIB1 if NTN access is available
- Removed b66 NTN and enabled B254 NTN conf file in CI
- NR UE: RRC layer now explicitly tells MAC layer when the RA procedure
can be started
- move NTN LEO config to band 254 and update doc/RUNMODEM.md
Closes#901
Refactor and extend NAS Registration Request
Extended NAS Registration Request generation and encoding according to
8.2.6 of 3GPP TS 24.501. Main topics:
- NAS Registration Type
- NAS KSI
- integrity protection
- NAS container encoding
Improvements:
- Add 5GMM Modes in NAS
- Introduced 5GMM state machine
Fixes:
- add 5GMM Capability IE to Registration Request
- closes#881, #819
E1AP enc/dec lib improvements
This MR is including some fixes and improvements for the E1AP library,
focusing mostly on Bearer Context Management:
- struct reorganization: split setup and modification request messages
into distinct structures, ensuring compliance with 3GPP TS 38.463
specifications
- add encoding/decoding sub-functions for different IEs
- improvements to Bearer Context Management: Implemented various
improvements to the E1 Bearer Context Setup Response and Request,
including the adoption of encoding/decoding sub-functions for
different IEs
- use lib functions whenever need (e.g. cp_bearer_context_setup_request
in cucp_cuup_e1ap.c)
- handle optional struct members as pointers
- updated copy/equality check utility functions
EDIT: The MR is also including the changes from !3222 (closed):
> While testing E1 with security enabled for DRBs, it was found that
> data traffic was not functional.
>
> The problem was that security settings were modified in the PDCP
> reestablishment happening when receiving Bearer Context Modification
> Request.
>
> So some restructuring was done.
>
> The actual fix is in 18176297, the others are for support. Basically
> we introduce a boolean to check if the security settings are present in
> Bearer Context Modification Request and we change PDCP security settings
> only if they are.
>
> (Note that in OAI CU security settings are not sent in Bearer Context
> Modification Request, so we could also remove all this, but we need to
> be compatible with other cu-up and/or cu-cp.)
Added Support of 35Mhz,45Mhz,70Mhz Bandwidth
Added Support of 35Mhz,45Mhz,70Mhz Bandwidth for 30Khz Subcarrier
Spacing, Also added 35Mhz, 45Mhz bw for 15Khz Subcarrierspacing.
Referred Spec TS 38.101 v18.6.0 section 5.3.2, table 5.3.2-1
Reset E1 UE contexts after E1 Setup Response
38.463 sec. 8.2.3 says
> This procedure also re-initialises the E1AP UE-related contexts (if
> any) and erases all related signalling connections in the two nodes
> like a Reset procedure would do.
Hence, delete all contexts after reception of E1 Setup Response. This
minimizes a risk of receiving an E1 bearer setup req for an existing UE,
which currently leads to an assert [we trust the CU-CP does not send the
same UE ID twice, as we only "mirror" the existing UE ID]. After this
MR, this is what happens if these entities fail:
- CU-CP fails: all context lost implicitly, upon reconnection, both DU
and CU-UP reset all contexts (like "start from zero")
- DU fails: CU-CP triggers NGAP UE context release request immediately
(radio connection with UE lost), all UE contexts attached to this DU
cleared (like "start from zero" for affected DU)
- CU-UP fails: initially, nothing (UE has no user plane); upon
reconnection of CU-UP, CU-CP triggers NGAP UE context release request
(cause radio connection with UE lost) and sends F1 Reset to DU, all UE
contexts associated to this DU cleared (like "start from zero")
for the last case, a possible improvement could be to use the F1 Reset
message to only clear affected UE conetxts. I chose not to do this,
because this MR is very big now already, and possible "victim" UEs
that were not at that CU-UP will reconnect as well
In Bearer Context Modification Request, the security information
field is needed only if we change the PDCP algorithms/keys. Since we
don't, no need to pass it.
Let's keep the old code, maybe the current understanding of the
specifications is wrong.
This was not a big problem, but we were advertising wrong
algorithm and deriving keys using this wrong algorithm in case
DRB ciphering and/or integrity was not active. (Say SRBs
are configured with NIA2 but DRBs are configured without
integrity, we would advertise NIA2 and send the integrity
key derived for NIA2, instead of NIA0 for both.)
It was not a problem because in the PDU Session Resource To Setup
item, there is "securityIndication" which we use to effectively
activate/deactivate the ciphering and/or integrity.
But it did not look clean to see a SecurityInformation with
incorrect data when inspecting the message in wireshark.
So let's use the correct values.
We could also not include the SecurityInformation if both ciphering
and integrity are not used, and only include ciphering if integrity
is not used (because integrity settings are optional).
But then if only integrity is used, we still need to include
ciphering, setting algorithm to NEA0 (no ciphering), because
the ciphering settings are always included.
This logic is too complex, let's use the simple one to always
include SecurityInformation with NEA0 and/or NIA0 if ciphering
and/or integrity is not activated.
As in deba3ae066 ("Reset CU-UP E1 UE contexts after E1 Setup
Response"), the CU-CP should reset the E1 UE contexts after E1 Setup
Response. 38.463 sec. 8.2.3 says
> This procedure also re-initialises the E1AP UE-related contexts (if
> any) and erases all related signalling connections in the two nodes like
> a Reset procedure would do.
In the case of CU-CP, this is a bit more complicated. More precisely, we
need to wait for the CU-UP to be available again before informing the DU
about the loss (implemented via an F1 Reset message), because otherwise,
the UE might reconnect immediately, before the CU-UP is online again.
Hence, on connection loss, we mark affected UEs (by setting their E1
association ID to 0); as long as the CU-UP does not connect, nothing
will happen (but UEs don't have user plane). Upon CU-UP connecting
again, we request release of the UEs via NGAP (similarly to what is done
if the DU goes offline, see invalidate_du_connections()), free the UE
contexts locally, and send an F1 Reset message to the DU, because
38.473 sec 8.2.1.2.1 says
> a failure at the gNB-CU [...] has resulted in the loss of some or
> all transaction reference information [...] a RESET message shall be
> sent to the gNB-DU.
The core should accept and send an NGAP release command message; since
no UE contexts are to be found (already deleted), the CU-CP will just
send a release complete (together with some warnings).
It might be possible to more gracefully handle the situation (e.g., as
described in 38.401 section 8.9.5 "Change of gNB-CU-UP"), but
- we lack the PDCP SN exchange
- the current procedure has the advantage of being equivalent to
"restart of the entire gNB", with less downtown.
The next commit will use rrc_remove_ue() to delete a CU(-CP+-UP)
context. However, we don't send NGAP UE context release at that moment
(we will instead *request* the release); more generally, it's not clear
that every user of rrc_remove_ue() wants to actually send this message.
Hence, refactor the code by separately calling
rrc_gNB_send_NGAP_UE_CONTEXT_RELEASE_COMPLETE() where appropriate.
Bearer context setup request and modification request messages
differ in various IEs according to 9.2.2 of 3GPP TS 38.463, e.g.
the Bearer context setup request does not contain a list of
DRBs to modify and does not contain an UP TL configuration.
Thus, the goal of this commit is to split the setup request message
and the modification request into two different structs:
* adopt e1ap_bearer_mod_req_t where necessary (e.g. fill_e1_bearer_modif)
Also, reorganized existing struct members according to specs:
* remove irrelevant struct members from the setup request
* group members from the same IEs into structs
* set optional struct members IEs as pointers
* add and adopt enc/dec/cp/eq lib functions for single IEs
* add UP_TL_information_t struct with TEID and TL address info and adopt in stack
* use int instead of long for count types
* update the relevant copy/equality check utility functions
Extra:
* add a function to handle Security Information in RRC in the process
* add create_up_tl_info and adopt in unit tests
* Without a valid 5G NAS security context:
* Send REGISTRATION REQUEST with cleartext IEs only.
* After activating a security context via Security Mode Control:
wrap the entire REGISTRATION REQUEST (with both non-cleartext and cleartext)
in a NAS message container IE, include it in SECURITY MODE COMPLETE
* With a valid 5G NAS security context:
* If non-cleartext IEs are needed, wrap the entire message in a NAS message container IE and cipher it.
* If only cleartext IEs are needed, send the message directly without the NAS message container IE.
Changes to support multiple TDD patterns
- Updated the configuration changes for 2 Patterns
- Update the TDD table configuration for NFAPI
- Added the tdd bitmap for the period
- Adapted the bitmap for UL/DL for the multi TDD pattern
- Updated the RACH procedure for multi TDD pattern
- Updated DL and UL scheduler for multi TDD pattern
NAS 5GS refactor
The goal of this MR is to reorganize the NR NAS code into:
- enc/dec library functions (5GS, 5GMM, 5GSM, NR_NAS_defs.h,
nr_fgs_nas_lib.c)
- handlers and callbacks (nr_nas_msg.c)
The following changes are introduced:
1. migrate 5GS enc/dec lib (5GMM and 5GSM) to a dedicated folder
2. add a nested CMakeLists structure
3. refactor NR NAS enc/dec functions
4. refactor NR NAS messages struct definitions
5. remove most of dependency from NAS LTE
6. further refactor of PDU Session Establishment Accept processing to
separate enc/dec from handling
7. made naming of 5GS definitions consistent whenever necessary
8. cleanup unused code
9. remove redundant struct definitions
Also:
1. fix decoding of AMF Set ID in 5G-S-TMSI UE identity
2. replace Byte_t directly with uint8_t
* take into account pattern2 in nr_rrc_config_dl_tda
* use get_tdd_period_idx in nr_rrc_config_ul_tda
* use get_first_ul_slot_multi_tdd in set_SR_periodandoffset
Co-authored-by: Guido Casati <guido.casati@firecell.io>
* refactor set_ideal_period to use frame_structure from MAC
* use get_ul_slot_offset to assign slot offset to nth UE and adopt in
updated config_csirs, configure_periodic_srs, set_csi_meas_periodicity
Co-authored-by: Guido Casati <guido.casati@firecell.io>
francescomani