I will begin posting logs that are referenced in the blog posts on the Nuradio Concepts Github page
https://github.com/Nuradioconcepts/blog_data/tree/main
In the last post, we ended with covering a RACH failure. This scenario was using srsUE and not a commercial UE. Hopefully, you asked, “Well, why did the RACH fail??”
Let’s look at the logs from the gNB when srsUE attempts the RACH process and when a commercial UE attempts the RACH process…
RACH Failure Analysis Continued…
Message 1 from UE
There aren’t too many differences except for RF… srsUE is received at a higher RSSI value, and in turn, the SNR value degrades to -7.7 dB compared to the Commercial UE SNR of 1.8 dB
Message 3 from UE
Similarly, when the gNB receives message 3 from each UE, the SNR of the failure scenario is much lower than the SNR of the pass scenario.
At the time of writing this post, I was not able to dial in the srsUE and gNB configurations to create a successful RACH scenario while using bladeRF with srsUE. Commercial UE’s are optimized to dynamically adjust power settings to establish connections with the network; software-defined radios depend on user-defined configurations, which are much more static. These configurations change depending on all sorts of variables… Distance between radios, tx/rx gain, antennas, attenuators, using an RF chamber, frequency band, etc.
However, I was able to successfully RACH srsUE using another USRP b210. This prompted another failure, “Scheduling request failed: releasing RRC connection…”
After investigating, I changed the tx/rx gain on the srsUE and gNB configurations and got srsUE to establish a connection with the 5G Network.
Notice the difference in the PUSCH value at the gNB when failing at -26.3 and then succeeding at ~4.6
This proves how valuable analyzing logs can be when troubleshooting your hardware and software configurations.
Signaling Radio Bearers (SRB)
A note about the use of SRBs in 5G. You will see them referenced often in the following logs.
- SRB0 is used on the UL/DL for RRC Setup Procedures and is not ciphered or integrity-protected. These messages are sent on the Common Control Channel (CCCH).
- [RLC-NR ] [I] SRB0: Tx SDU
- [RLC-NR ] [D] SRB0: Complete SDU scheduled for tx
- [RLC-NR ] [I] SRB0: Tx Transparent Mode PDU
- [RRC-NR ] [D] SRB0 – Tx
- [RRC-NR ] [D] SRB0 – Rx
- SRB1 Once the UE is RRC Connected (after the Random Access procedure), Procedures between the UE, gNB, and 5GC utilize SRB1. SRB1 uses ciphering and integrity protection and transfers over Dedicate Control Channels (DCCH).
- [RLC-NR ] [I] SRB1: Rx PDU
- [RLC-NR ] [I] SRB1: Rx data PDU
- [RLC-NR ] [I] SRB1: Tx SDU
- [PDCP-NR] [I] RX SRB1 PDU
- [PDCP-NR] [I] TX SRB1 SDU
- [RRC-NR ] [D] SRB1 – Rx dlInformationTransfer
- [RRC-NR ] [D] SRB1 – Tx ulInformationTransfer
- SRB2 is Used for DL/UL Data encapsulation after security activation and is transferred over Dedicated Control Channels (DCCH).
Random Access
Now that we have made progress, we can use srsUE to analyze follow-network procedures. The con to using srsUE is that it isn’t a commercial UE, and we will be limited to hardware and software capability. The pro is that we can collect UE logs to a detail that not even some engineering handsets can display.
We will start the Random Access procedure from where it began to fail in the previous blog post.
Random Access Message 4 – Contention Resolution
UE monitors PDCCH for DCI format 1_0 with scrambled CRC/TC-RNTI
UE receives PDSCH and stops ra-ContentionResolutionTimer.
UE decodes MAC PDU containing contention resolution identity (48 bits) that correlates to the CCCH SDU sent by the UE in msg3. At this point, contention resolution has been achieved.
C-RNTI is set to the previously configured temporary identity. Random Access procedure is complete.
RRC Connection Establishment
Now is the time for the UE and gNB to complete the RRC Connection Establishment. UE prepares the RRC Setup Complete message, which carries the NAS REGISTRATION REQUEST.
UE sends RRC Setup Complete on SRB1 – RRC Connection Establishment is complete.
NAS Authentication
*All NAS Procedures will be reviewed in depth in other blog posts.
UE receives the NAS AUTHENTICATION REQUEST on SRB1. The 5GC Generates the keys based on the information provided by the UE in the REGISTRATION REQUEST.
The AUTHENTICATION REQUEST contains the RAND and AUTN, which are generated in the AUSF of the 5GC.
UE performs key generation.
UE calculates the RES (Response) that is sent back to the 5G Network in the AUTHENTICATION RESPONSE.
5GC compared the UE RES to the Expected Response (XRES)
NAS Security
NAS Security guarantees NAS messages are secure between the UE and 5GC.
AMF selects ciphering and integrity algorithms that are supported by the UE
- cipher_algo 0
- integ_algo 2
UE uses k_nas_enc and k_nas_int and conducts an integrity check of the NAS SECURITY MODE COMMAND message. All subsequent communication between the UE and 5GC is now protected if this procedure passes.
AS Security
Access Stratum (AS) security can be set up once NAS security is active.
UE receives the AS Security Mode Command on SRB1
AMF once again selects encryption and integrity algorithms that the UE is capable of and notifies the UE in this message.
- Encryption: NEA0
- Integrity: 128-NIA2
There are four keys associated with the AS that can be seen in the UE query of the USIM. These keys are derived from the K_gnb based on the K_amf key.
- K_RRC_int: Integrity protects RRC signaling
- K_RRC_enc: Ciphers RRC signaling
- K_UP_int: Integrity protects user plane data
- K_UP_enc: Ciphers user plane data
UE generates the keys and sends in the Security Mode Response message. All control plane messages are now protected on the AS level, and User Plane data will be secured per data bearer connection.
Registration Accept/Complete
UE receives REGISTRATION ACCEPT message on SRB1
UE verifies the integrity of SRB1
UE verifies the integrity of the REGISTRATION ACCEPT message, which puts the UE in 5G Mobility Management (5GMM) state Registered for Normal Service. UE then sends the REGISTRATION COMPLETE message to the 5GC.
REGISTRATION COMPLETE message is sent on SRB1 and is ciphered and integrity protected. UE then sends the PDU SESSION ESTABLISHMENT REQUEST message to the 5GC.
PDU SESSION ESTABLISHMENT REQUEST message is also ciphered and integrity protected.
Conclusion
This article shows and covers a lot of detail on the UE interacting with the gNB and 5GC for Cell Selection and Network Registration. Showing the UE side of the transactions provides many benefits that are not commonly seen. Also, if I included the gNB and 5GC logs, this post might never end… You will encounter issues past the Random Access procedure; most will be configuration errors in your 5GC or gNB with invalid credentials or parameters that merit specific messages to the UE. Some of these messages are…
- RRCReject
- Registration Reject (with various cause code values)
You can configure a default reject cause code for users who are not configured in your subscriber database in the amf.yaml under 3GPP Specification > Access Control > default reject cause
- Authentication Reject (with various cause code values)
Two consecutive Authentication Failure cause 21 causes the network to terminate the 5G AKA process
- Authentication Failure (with various cause code values)
cause 20 (MAC Failure) when USIM detects that the MAC in the Authentication Request is not fresh
cause 21 (Sync failure) when USIM detects that the SQN in the Authentication Request is out of range
- Security Mode Reject (with various cause code values)
- Service Reject (with various cause code values)
- PDU Session Establishment Reject (with various cause code values)
We will cover these scenarios in further blog topics.
Leave a Reply