NAS Handle 5G-S-TMSI and pass it to lower layers (nrUE)
Issues:
-
5G-S-TMSI is hardcoced at UE side: solved in !2690 (merged) 38.331:
if upper layers provide a 5G-S-TMSI: if the RRCSetup is received in response to an RRCSetupRequest: set the ng-5G-S-TMSI-Value to ng-5G-S-TMSI-Part2; else: set the ng-5G-S-TMSI-Value to ng-5G-S-TMSI;
-
UE upper layers (NAS) shall provide to UE RRC the 5G-S-TMSI: 1) NAS gets TMSI from AMF 2) reestablishment 3) RRCSetup needs 5g-s-TMSI from "higher layers" 4) RRC gets tmsi from NAS to fill that info. - NAS gets GUTI from AMF apparently. From that it needs to derive 5G-S-TMSI and then depending on a few of conditions (5.3.1.1 in 24.501) possibly sending it to the RRC
What has been observed:
Initial Context Setup Request is not received by gNB when UE attaches from RRC IDLE. When the UE does the RRCSetup procedure from the IDLE mode, the gNB does not get the Initial Context Setup Request, so the setup is not completed:
[NR_PHY] [gNB 0][RAPROC] Frame 855, slot 19 Initiating RA procedure with preamble 44, energy 57.0 dB (I0 346, thres 120), delay 0 start symbol 0 freq index 0
[NR_MAC] [gNB 0][RAPROC] CC_id 0 Frame 855 Activating Msg2 generation in frame 856, slot 7 using RA rnti 10b SSB, new rnti 4d5f index 0 RA index 0
[NR_MAC] [gNB 0][RAPROC] CC_id 0 Frame 856, slotP 7: Generating RA-Msg2 DCI, rnti 0x10b, state 1, CoreSetType 0
[NR_MAC] [RAPROC] Msg3 slot 17: current slot 7 Msg3 frame 856 k2 7 Msg3_tda_id 3
[NR_MAC] Adding new UE context with RNTI 0x4d5f
[NR_MAC] [gNB 0][RAPROC] PUSCH with TC_RNTI 0x4d5f received correctly, adding UE MAC Context RNTI 0x4d5f
[NR_MAC] [RAPROC] RA-Msg3 received (sdu_lenP 7)
[RLC] activated srb0 for UE with RNTI 0x4d5f
[RLC] Added srb 1 to UE with RNTI 0x4d5f
[NR_MAC] Activating scheduling RA-Msg4 for TC_RNTI 0x4d5f (state WAIT_Msg3)
[93m[NR_MAC] Unexpected ULSCH HARQ PID 0 (have -1) for RNTI 0x4d5f (ignore this warning for RA)
[NR_RRC] Decoding CCCH: RNTI 4d5f, payload_size 6
[NR_RRC] Created new UE context: CU UE ID 1 DU UE ID 19807 (rnti: 4d5f, random ue id b01c1bb574000000)
[RRC] activate SRB 1 of UE 1
[NR_RRC] rrc_gNB_generate_RRCSetup for RNTI 4d5f
[NR_MAC] No CU UE ID stored for UE RNTI 4d5f, adding CU UE ID 1
[NR_MAC] UE 4d5f Generate msg4: feedback at 857.17, payload 169 bytes, next state WAIT_Msg4_ACK
[NR_MAC] (UE RNTI 0x4d5f) Received Ack of RA-Msg4. CBRA procedure succeeded!
[NR_RRC] 5g_s_TMSI: 0x123456789ABC, amf_set_id: 0x48 (72), amf_pointer: 0x34 (52), 5g TMSI: 0x56789ABC
[NR_RRC] UE 1 Processing NR_RRCSetupComplete from UE
[NR_RRC] [FRAME 00000][gNB][MOD 00][RNTI 1] UE State = NR_RRC_CONNECTED
[NGAP] UE 1: Chose AMF 'OAI-AMF' (assoc_id 7) through selected PLMN Identity index 0 MCC 1 MNC 1
[34m[NGAP] FIVEG_S_TMSI_PRESENT
[NR_MAC] Frame.Slot 896.0
UE RNTI 4d5f CU-UE-ID 1 in-sync PH 0 dB PCMAX 0 dBm, average RSRP -44 (4 meas)
UE 4d5f: dlsch_rounds 6/0/0/0, dlsch_errors 0, pucch0_DTX 0, BLER 0.08100 MCS (0) 9
UE 4d5f: ulsch_rounds 9/0/0/0, ulsch_errors 0, ulsch_DTX 0, BLER 0.07290 MCS (0) 9
UE 4d5f: MAC: TX 615 RX 498 bytes
UE 4d5f: LCID 1: TX 62 RX 56 bytes
The issue is then that a UE that is re-attaching from IDLE state does not complete the attachment. I see in the AMF logs that the UE is attaching with GUTI:
[2024-04-02 13:06:43.420] [common] [debug] Decoded RegistrationRequest message (len 27)
[2024-04-02 13:06:43.420] [common] [debug] 5G GUTI 0010118100000001
rather than IMSI, as in the initial attachment:
[2024-04-02 13:05:56.562] [common] [debug] Decoded RegistrationRequest message (len 29)
[2024-04-02 13:05:56.562] [amf_n1] [debug] Received IMSI 001010000000001
However the AMF is not sending the Registration-Accept, and the procedure does not complete.
In the InitialUEMessage there's probably an issue when encoding FiveG-S-TMSI IE from gNB side.
in the registered AMF we have:
[2024-04-02 13:01:48.063] [config ] [info] AMF Set ID.............................: 001
[2024-04-02 13:01:48.063] [config ] [info] AMF Pointer............................: 01
while in the RRCSetupComplete on UE we are hardocoding the 5G-S-TMSI:
stmsi->buf[0] = 0x12; --> AMF Set ID
stmsi->buf[1] = 0x34; --> AMF Pointer
stmsi->buf[2] = 0x56; --> 5G-TMSI
stmsi->buf[3] = 0x78; --> 5G-TMSI
stmsi->buf[4] = 0x9A; --> 5G-TMSI
stmsi->buf[5] = 0xBC; --> 5G-TMSI
then on gNB we have also an enconding issue on the Set ID, e.g. it is 0x48, should be 0x12:
[NR_RRC] 5G-S-TMSI: 0x123456789ABC/AMF Set ID: 0x48 (72)/AMF pointer: 0x34 (52)/5G-TMSI: 0x56789ABC (1450744508)
the 5G-S-TMSI = AMF Set ID + AMF Pointer + 5G-TMSI
When receiving the Registration Request from UE with TMSI, CN sent a request to have UE identity (Identity Request) but no response from UE. That's why the registration procedure is not completed.