Demystifying 5G Data Transfer Part 2: 5G Control Plane

Introduction

This article took on a new life as I was writing it and what I intended to be a bit by bit analysis using Wireshark, but realized it would be beneficial to include log file analysis since crucial Control Plane procedures related to the PHY are not captured in the pcaps.

Log Files

In this article I will be using the log files and pcaps that have been uploaded to the Nuradio Concepts GitHub.

srsUE config file (ue.conf)
srsRAN gNB config file (gnb_n3_srsue.yml)
gnb_f1ap.pcap
gnb_mac.pcap
gnb_ngap.pcap
gnb_rlc.pcap
gnb.log
ue_mac_nr.pcap
ue_nas.pcap
ue.log

I will also be using tcpdump pcaps that were captured on the srsUE and srsRAN computers, but am not posting them on the github page.

My setup for these captures is very basic

Computer 1: srsUE with USRP B210 and GPSDO
Computer 2: srsRAN with USRP B210 and GPSDO
- I did not run the gNB DU gNB CU split configurations, so all gNB DU/CU data is aggregated into each log file
Both systems were run in an open environment with approximately 6 feet of separation between system antennas.

Log Configurations

srsUE

[pcap]
enable = mac_nr,nas
mac_filename = /tmp/ue_mac.pcap
mac_nr_filename = /tmp/ue_mac_nr.pcap
nas_filename = /tmp/ue_nas.pcap

[log]
all_level = debug
phy_lib_level = debug
all_hex_limit = 32
filename = /tmp/ue.log
file_max_size = -1

srsRAN gNB

log:
  filename: /tmp/gnb.log              
  all_level: debug
  tracing_filename: /tmp/gnb_trace.log

pcap:
  mac_enable: enable               
  mac_filename: /tmp/gnb_mac.pcap  
  ngap_enable: enable              
  ngap_filename: /tmp/gnb_ngap.pcap
  rlc_enable: enable 
  rlc_rb_type: all
  rlc_filename: /tmp/gnb_rlc.pcap

Log Considerations

One key consideration between the srsUE and srsRAN logs is the format of the System Frame Numbers between the two files.

srsRAN uses a decimal to seprate the SFN from the Slot
- Examples below
  - SFN 551, Slot 5
  - SFN 1018, slot 6
srsUE does NOT use a decimal
- Examples below
  - SFN 551, slot 5
  - SFN 617, slot 9

## srsRAN example
2024-12-19T14:40:39.815917 [PHY     ] [D] [   551.5] PDCCH: rnti=0x4601 ss_id=2 format=1_0 cce=0 al=2 t=20.8us

2024-12-19T14:40:44.491547 [PHY     ] [D] [  1018.6] PUCCH: rnti=0x4601 format=2 prb=[104, 105) prb2=na symb=[10, 12) csi1=1111 t=47.7us


## srsUE example
2024-12-19T14:40:39.847986 [PHY1-NR] [I] [ 5515] PUSCH: cc=0 pid=0 c-rnti=0x4601 prb=(3,3) symb=(0,13) CW0: mod=64QAM
2024-12-19T14:40:40.511155 [MAC-NR ] [D] [ 6179] SCHED: Searching C-RNTI=0x4601

The srsUE ue.log file ends up being a large file, very quickly. I generally go through the file and add markers for key events and procedures and identify lines that may not be relevant for analysis. When I find specific lines that are irrelevant, I remove the lines.

the srsRAN gNB gnb.log file doesn’t end up being as large as the ue.log, though I still find irrelevant lines and remove them.

For example, I generally use Sublime Text and conduct a “find all” on “[FAPI ]”, I select all of the results and copy and paste them to a blank document where I can see if there are any relevant lines before I go back to the original log and delete all of the lines containing “[FAPI ]”. I will continue to do this for other lines and will refine my “find all” filter if necessary.

Log file vs. PCAP

In the pcap files there will be no information related to the PHY layer, as opposed to the log files which will show the the Physical Channels that are transmitted and received at the UE and gNB.

The pcap files will be the most beneficial and easiest to analyze when relating concepts back to the Networking Basics concepts presented in the first article in this series. Pcap’s will also provide us with message details and information that the log files do not collect. The Log files will aid in the understanding of the Physical layer procedures, as well as how each layers process data from transmission and reception.

In the examples below observe the logical flow through the protocol stack from the PHY to upper layers. This will be important when understanding what each layer is responsible for.

## srsRAN example: Receiving Authentication Response

[PHY     ] [D] [   568.9] PUSCH: rnti=0x4601 h_id=0 prb=[3, 9) symb=[0, 14) mod=64QAM rv=0 tbs=544 crc=OK iter=2.0 sinr=26.6dB t=241.8us uci_t=0.0us ret_t=0.0us
[MAC     ] [I] [   569.4] UL rnti=0x4601 ue=0 subPDUs: [lcid=1: len=3, lcid=1: len=67, SBSR: lcg=0 bs=7, PAD: len=467]
[MAC     ] [D] [   569.4] UL rnti=0x4601 ue=0 lcid=1 UL-DCCH: Forwarding SDU of 3 bytes
[RLC     ] [D] du=0 ue=0 SRB1 UL: RX control PDU. pdu_len=3
[RLC     ] [I] du=0 ue=0 SRB1 UL: RX status PDU. ack_sn=2 n_nack=0
[MAC     ] [D] [   569.4] UL rnti=0x4601 ue=0 lcid=1 UL-DCCH: Forwarding SDU of 67 bytes
[RLC     ] [I] du=0 ue=0 SRB1 UL: RX PDU. pdu_len=67 dc=data p=1 si=full sn=2
[RLC     ] [D] du=0 ue=0 SRB1 UL: Status report requested via polling bit.
[RLC     ] [D] du=0 ue=0 SRB1 UL: RX SDU. payload_len=65 dc=data p=1 si=full sn=2
[RLC     ] [D] du=0 ue=0 SRB1 UL: Adding sn=2 to window.
[RLC     ] [D] du=0 ue=0 SRB1 UL: RX entity state. rx_next=2 rx_next_status_trigger=0 rx_highest_status=2 rx_next_highest=2
[RLC     ] [D] du=0 ue=0 SRB1 UL: Updated rx_next_highest=3.
[RLC     ] [I] du=0 ue=0 SRB1 UL: RX SDU. sn=2 sdu_len=65
[RLC     ] [D] du=0 ue=0 SRB1 DL: Received ACK or NACK for poll_sn=1. Stopping t-PollRetransmit.
[RLC     ] [D] du=0 ue=0 SRB1 DL: Removing sn=1 from window
[RLC     ] [D] du=0 ue=0 SRB1 DL: Processed status report ACKs. ack_sn=2 tx_next_ack=2
[RLC     ] [D] du=0 ue=0 SRB1 DL: Sending buffer state update to lower layer. bs=0
[DU-F1   ] [I] Tx PDU du=0 ue=0 cu_ue=0 du_ue=0: ULRRCMessageTransfer
[RLC     ] [I] du=0 ue=0 SRB1 DL: Handled status report. t=8us ack_sn=2 n_nack=0
[CU-CP-F1] [I] Rx PDU du=0 ue=0 cu_ue=0 du_ue=0: ULRRCMessageTransfer
[RRC     ] [D] ue=0 c-rnti=0x4601: RX SRB1 PDCP PDU
[PDCP    ] [D] ue=0 SRB1 UL: RX PDU. pdu_len=65
[PDCP    ] [D] ue=0 SRB1 UL: RX entity state. rx_next=2 rx_deliv=2 rx_reord=0
[PDCP    ] [I] ue=0 SRB1 UL: RX PDU. type=data pdu_len=65 sn=2 count=2
[PDCP    ] [D] ue=0 SRB1 UL: Adding sn=2 to window.
[PDCP    ] [I] ue=0 SRB1 UL: RX SDU. count=2
[PDCP    ] [D] ue=0 SRB1 UL: Removing sn=2 from window
[PDCP    ] [D] ue=0 SRB1 UL: RX entity state. rx_next=3 rx_deliv=3 rx_reord=0
[RRC     ] [D] ue=0 c-rnti=0x4601: Rx SRB1 DCCH UL ulInformationTransfer (59 B)
[RRC     ] [D] ue=0 c-rnti=0x4601: Containerized ulInformationTransfer: [
[NGAP    ] [I] Tx PDU ue=0 ran_ue=0 amf_ue=3: UplinkNASTransport

srsUE example: Receiving Security Mode Command

[MAC-NR ] [D] [ 5663] new_grant_dl(): cc_idx=0, tti=5663, rnti=17921, pid=1, tbs=80, ndi=1, rv=0
[PHY2-NR] [I] [ 5663] PDSCH: cc=0 pid=1 c-rnti=0x4601 prb=(0,0) symb=(1,13) CW0: mod=64QAM tbs=80 R=0.911 rv=0 CRC=OK 
[MAC-NR ] [D] [ 5663] tb_decoded(): cc_idx=0, tti=5663, rnti=0x4601, pid=1, tbs=80, ndi=1, rv=0, result=OK
[MAC-NR ] [D] [ 5663] Delivering PDU=80 bytes to Dissassemble and Demux unit
[MAC-NR ] [I] [ 5663] DL 1:  newTX tbs=80, rv=0, ack=OK, ndi=1
[PHY2-NR] [D] [ 5663] use_pusch=n nof_cc=1
[MAC-NR ] [D] [ 5664] Handling MAC PDU (80 B)
[MAC-NR ] [I] [ 5664] DL LCID=1 len=30 PAD: len=47
[MAC-NR ] [D] [ 5664] Handling subPDU 1/2: rnti=0x0 lcid=1, sdu_len=30
[RLC-NR ] [I] SRB1: Rx PDU - N bytes 30
[RLC-NR ] [I] SRB1: Rx data PDU SN=1 (30 B)
[RLC-NR ] [D] SRB1: [Data PDU, P=1, SI=full, SN_SIZE=12 bits, SN=1, SO=0]
[RLC-NR ] [I] SRB1: status packet requested through polling bit
[RLC-NR ] [D] SRB1: RX entity state: Rx_Next=1, Rx_Next_Status_Trigger=0, Rx_Highest_Status=1, Rx_Next_Highest=1
[PDCP-NR] [I] RX SRB1 PDU (28 B), integrity=none, encryption=none
[PDCP-NR] [D] Rx PDCP state - RX_NEXT=1, RX_DELIV=1, RX_REORD=0
[PDCP-NR] [D] Estimated RCVD_HFN=0, RCVD_SN=1, RCVD_COUNT=1
[PDCP-NR] [D] Delivering SDU with RCVD_COUNT 1
[RRC-NR ] [D] RX PDU, LCID: 1
[RRC-NR ] [D] SRB1 - Rx dlInformationTransfer (22 B)
[RRC-NR ] [D] Content:[
[PDCP-NR] [D] Rx PDCP state - RX_NEXT=2, RX_DELIV=2, RX_REORD=0
[MAC-NR ] [D] [ 5664] Handling subPDU 2/2: rnti=0x0 lcid=63, sdu_len=47
[NAS5G  ] [I] DL PDU (length 19)
[NAS5G  ] [I] Decrypted DL PDU (length 19)
[NAS5G  ] [I] Handling Security Mode Command
[NAS5G  ] [D] Generating integrity check. integ_algo:2, count_dl:1
 [NAS5G  ] [I] Integrity check ok. Local: count=0, Received: count=0  [0b 38 e4 40]

Wireshark Setup

Please see the Wireshark Tips section of the previous post in this series to configure Wireshark to analyze the data. If you do not have specific DLT_USER profiles configured then you will not be able to analyze specific protocol data in Wireshark. srsRAN also provides a guide for configuring Wireshark.

Demystifying 5G Data Transfer Part 1: Networking Basics

An additional consideration would be to set your Wireshark time to UTC time so that the time stamps between the Logs and the pcaps align.

Select Preference
Navigate to Appearance > Columns
Select the “Time” Row, and double click the Time “Type” to observe the drop down menu
Select “UTC Time” and then select OK

This will make it easier to correlate events seen in the pcaps to the logs

5G Control Plane

For the purpose of this article, we will primarily be focusing on the Control Plane between the UE and gNB. Since the Control Plane extends from the gNB to the AMF using the NGAP protocol to carry NAS messages to the 5GC, we will also touch on that aspect of the Control Plane.

The Control Plane consists of the following layers, where they are located, and their general functionality.

Protocol	UE	gNB	Functions
NGAP		X	Interface Management, UE Context Management, NAS Message Transfer
NAS	X		Connection Management, Mobility Management, Session Management, Authentication, Security
RRC	X	X	System Information, Paging, Radio Connection Management, Security, Mobility, Measurements, NAS message transfer
PDCP	X	X	Sequencing, Compression, Ciphering/Integrity, SDU discard, Data Recovery, PDU Duplication
RLC	X	X	Sequencing, Error Correction, Segmentation, SDU reassembly, Duplicate Detection, SDU Discard
MAC	X	X	SDU Multiplexing, Scheduling, Error Correction, Padding
PHY	X	X	Error Detection, Modulation, Synchronization, RF Processing, Coding

Data Transport

Each layer of the Control Plane stack produces its own data, which traverses upper or lower layers depending on the direction of the data (uplink or downlink). Each protocol has mechanisms for transporting data from layer to layer, though the data is only received and decoded at its peer protocol layer.

This is similar to Application data flowing through the OSI or TCP/IP stacks, where data is originated and additional headers and information are added before its transmission across the Physical layer. For the purpose of 5G Control Plane, we will be focusing mostly on the connection between two nodes (UE and gNB), though in reality, telecomm networks are just as complex as computer networks where data may need to extend to multiple additional nodes, relays, routers, etc. Where each node adds and takes away specific headers of information that are necessary or unnecessary for the data’s next destination.

To simplify this concept, refer to the graphic below. In this scenario there is data that flows through each protocol starting with the NAS Message.

There are also simpler instances where data originates from another protocol, and that data may not be required to have all protocols in the stack attach headers and information. This is commonly seen in

System Information
- SIB1 is generated at RRC and bypasses PDCP and RLC, and the MAC layer is “transparent” to where no MAC header is added, because the MAC PDU is the MAC SDU that is aligned to a Transport Block. (38.321 6.1.4)
Random Access messages
- MSG1 and MSG 2 only involve MAC and PHY

Downlink Transport

Depending on what is being sent from the gNB to the UE, or being broadcast, depends on the route the data traverses the Control Plane stack to reach the air interface. Signaling Radio Bearers (SRB), Logical Channels, Transport Channels, and Physical Channels pass data through the stack to the air interface.

Messages that do not require an RRC Connection, such as MIB, SIB1, Paging, are generated at the RRC layer and are passed to the PHY by Logical and Transport channels, not requiring any additional protocol information. Note that these messages use use BCCH and PCCH and are common messages.

RRC Messages that use SRB0 are transmitted before SRB1 is configured, use the CCCH logical channel. Once the UE receives this message it can configure SRB1, where subsequent messages are transferred until the RRC Connection is released.

The RLC layer operates in Transparent Mode (RLC TM) for messages that are transferred prior to RRC Connection being established between the UE and gNB. The RRC Setup message provides the UE with the RLC configuration. When RLC TM is used, the PDCP layer is bypassed and with data being sent on the BCCH, PCCH, or CCCH.

Once RRC Connection is established, NAS and RRC Control Plane messages are transferred on SRB1 using the DCCH Logical channel using RLC Acknowledged Mode (RLC AM).

We will cover each protocol and layer in depth later in this article.

Downlink Procedures *Not including TAG Command, HARQ, Scheduling, etc.

Uplink Transport

The uplink side of data transfer is more straight forward than downlink with less Transport Channels since there is no need to broadcast on the uplink.

The Random Access procedure mostly occurs at the MAC and PHY layers, though RRC Messages are transferred with Message 3 and Message 4. Message 1 RACH Preamble is sent from the RACH Transport Channel to the PRACH Physical channel, where the RACH transport channel does not map to upper layers or a Logical Channel.

The same concepts with downlink apply to uplink in terms of RRC Connection, where the RRC Setup Request that is sent with Message 3, is sent on SRB0 on the CCCH using RLC TM. The UE receives the RRC Setup message and applies SRB1 configuration as well as RLC AM configuration so it can send subsequent messages using the DCCH.

Uplink Procedures *Not including BSR, SR, HARQ, etc.

Data Types

NAS (24.501)

NAS Messages or PDUs have three generic message structures

Plain 5GMM NAS Message (9.1.1.1)
Plain 5GSM NAS Message(9.1.1.1)
Security Protected NAS Message (9.1.1.2)

Here we can break down the NAS message structures of the Security Protected NAS messages and Plain NAS 5G MM Messages for Registration Complete and PDU Session Establishment Request that includes a Payload Container. The Payload Container includes a Plain NAS 5G SM Message as well.

Registration Complete with PDU Session Establishment Request Example

NAS UE Log Messages

[NAS5G  ] [I] DL PDU (length 19)
    0000: 7e 03 0b 38 e4 40 00 7e 00 5d 02 01 02 f0 70 e1
    0010: 36 01 02
[NAS5G  ] [I] Decrypted DL PDU (length 19)
    0000: 7e 03 0b 38 e4 40 00 7e 00 5d 02 01 02 f0 70 e1
    0010: 36 01 02
[NAS5G  ] [I] Handling Security Mode Command

RRC

RRC Messages can encapsulate NAS messages for transportation to the gNB RRC layer, where the NAS message PDU is transferred to the NGAP layer.

dlInformationTransfer
- Identity Request
- Authentication Request
- Security Mode Command
- Configuration Update Command
- Registration Accept
ulInformationTransfer
- Identity Response
- Authentication Response
- Security Mode Complete
- Registration Complete
- PDU Session Establishment Request
RRC Setup Complete
- Registration Request
RRC Reconfiguration
- PDU Session Establishment Accept

There are also dedicated RRC messages that manage radio connectivity.

Downlink
- MIB
- SIB1
- Other System Information
- RRC Setup (Configured SRB1)
- Security Mode Command
- ueCapabilityEnquiry
- RRC Reconfiguration
Uplink
- RRC Setup Request
- RRC Setup Complete
- Security Mode Complete
- ueCapabilityInformation
- RRC Reconfiguration Complete
- Measurement Report

RRC UE Log Messages

[RRC-NR ] [D] SRB0 - Rx rrcSetup (286 B)
    0000: 20 40 04 08 ca e0 05 80 08 8b d7 63 80 83 0f 00
    0010: 03 e0 10 23 41 e0 40 00 20 90 4c 0c a8 00 0f ff

[RRC-NR ] [D] Content:[
  {
    "DL-CCCH-Message": {

[RRC-NR ] [D] Applying SRB Add/Mod to SRB1

[RRC-NR ] [D] Preparing RRC Connection Setup Complete
[RRC-NR ] [D] SRB1 - Tx rrcSetupComplete (27 B)
    0000: 10 00 05 df 80 10 5e 40 03 40 40 3c 44 00 00 00
    0010: 00 04 0c 95 1d 82 0b 80 bc 1c 00
[RRC-NR ] [D] Content:[
  {
    "UL-DCCH-Message": {

RRC gNB Log Messages

[RRC     ] [D] ue=0 c-rnti=0x4601: Rx CCCH UL rrcSetupRequest (6 B)
[RRC     ] [D] ue=0 c-rnti=0x4601: Containerized rrcSetupRequest: [
[RRC     ] [D] ue=0 c-rnti=0x4601: Creating SRB1
[RRC     ] [D] ue=0 c-rnti=0x4601: Tx CCCH DL rrcSetup (286 B)
[RRC     ] [D] ue=0 c-rnti=0x4601: Containerized rrcSetup: [
[RRC     ] [D] ue=0 c-rnti=0x4601: TX SRB0 PDU
[RRC     ] [D] ue=0 c-rnti=0x4601: RX SRB1 PDCP PDU
[RRC     ] [D] ue=0 c-rnti=0x4601: Rx SRB1 DCCH UL rrcSetupComplete (27 B)
[RRC     ] [D] ue=0 c-rnti=0x4601: Containerized rrcSetupComplete: [
[RRC     ] [D] ue=0 c-rnti=0x4601: "RRC Setup Procedure" finished successfully

PDCP

For the Control Plane with the srsRAN logs provided, observe that messages sent on SRB1 add a PDCP header that includes a Sequence Number and Message Authentication Code (MAC). The PDCP data is the RRC Message.

The PDCP layer is not used for initial connection procedures and broadcast messages.

PDCP controls the encryption and integrity procedures for data transfer, where you can see from the srs logs below, that Integrity verification occurs among other PDCP functions.

PDCP UE Log Messages

[PDCP-NR] [I] SRB1 PDCP-NR entity configured. SN_LEN=12, Discard timer -1, Re-ordering timer 500, RLC=AM, RAT=NR
[PDCP-NR] [I] Add SRB1 (lcid=1, sn_len=12bits)
[PDCP-NR] [I] TX SRB1 SDU (27B), integrity=none, encryption=none
[PDCP-NR] [D] Integrity gen input: COUNT 0, Bearer ID 1, Direction Uplink
[PDCP-NR] [D] Integrity gen key:
[PDCP-NR] [D] Integrity gen input msg:
[PDCP-NR] [D] MAC (generated)
[PDCP-NR] [I] TX SRB1 PDU (33B), HFN=0, SN=0, integrity=none, encryption=none
[PDCP-NR] [D] Received delivery notification from RLC. Nof SNs=1
[PDCP-NR] [D] Stopping discard timer for SN=0

[PDCP-NR] [D] Enabled integrity. LCID=1, integrity=tx/rx
[PDCP-NR] [I] TX SRB1 SDU (2B), integrity=tx/rx, encryption=none
[PDCP-NR] [D] Integrity gen input: COUNT 3, Bearer ID 1, Direction Uplink
[PDCP-NR] [D] Integrity gen key:
[PDCP-NR] [D] Integrity gen input msg:
[PDCP-NR] [D] MAC (generated)
[PDCP-NR] [I] TX SRB1 PDU (8B), HFN=0, SN=3, integrity=tx/rx, encryption=none
[PDCP-NR] [D] Enabled encryption. LCID=1, encryption=tx/rx
[PDCP-NR] [D] Received delivery notification from RLC. Nof SNs=1
[PDCP-NR] [D] Stopping discard timer for SN=3
[PDCP-NR] [I] RX SRB1 PDU (55 B), integrity=tx/rx, encryption=tx/rx
[PDCP-NR] [D] Rx PDCP state - RX_NEXT=3, RX_DELIV=3, RX_REORD=0

[PDCP-NR] [D] Integrity check input - COUNT 3, Bearer ID 1, Direction Downlink
[PDCP-NR] [D] Integrity check key:
[PDCP-NR] [D] MAC match (expected):
[PDCP-NR] [D] MAC match (found):
[PDCP-NR] [D] Integrity check input msg (Bytes=51):
[PDCP-NR] [D] SRB1: Integrity verification successful

PDCP gNB Log Messages

[PDCP    ] [D] ue=0 SRB1 UL: RX PDU. pdu_len=65
[PDCP    ] [D] ue=0 SRB1 UL: RX entity state. rx_next=2 rx_deliv=2 rx_reord=0
[PDCP    ] [I] ue=0 SRB1 UL: RX PDU. type=data pdu_len=65 sn=2 count=2
[PDCP    ] [D] ue=0 SRB1 UL: Adding sn=2 to window.
[PDCP    ] [I] ue=0 SRB1 UL: RX SDU. count=2
[PDCP    ] [D] ue=0 SRB1 UL: Removing sn=2 from window
[PDCP    ] [D] ue=0 SRB1 UL: RX entity state. rx_next=3 rx_deliv=3 rx_reord=0


[PDCP    ] [I] ue=0 SRB1 UL: Security configured: NIA2 NEA0 domain=RRC
[PDCP    ] [I] ue=0 SRB1 UL: 128 K_int: 
[PDCP    ] [I] ue=0 SRB1 UL: 128 K_enc: 
[PDCP    ] [I] ue=0 SRB1 UL: Set integrity_enabled=on
[PDCP    ] [I] ue=0 SRB1 UL: Set ciphering_enabled=off
[PDCP    ] [I] ue=0 SRB1 DL: Security configured: NIA2 NEA0 domain=RRC
[PDCP    ] [I] ue=0 SRB1 DL: 128 K_int: 
[PDCP    ] [I] ue=0 SRB1 DL: 128 K_enc: 
[PDCP    ] [I] ue=0 SRB1 DL: Set integrity_enabled=on
[PDCP    ] [I] ue=0 SRB1 DL: Set ciphering_enabled=off
[PDCP    ] [D] ue=0 SRB1 DL: TX SDU. sdu_len=3
[PDCP    ] [D] ue=0 SRB1 DL: Integrity gen. count=2 bearer_id=0 dir=DL
[PDCP    ] [D] ue=0 SRB1 DL: Integrity gen key: 
[PDCP    ] [D] ue=0 SRB1 DL: Integrity gen input message.
[PDCP    ] [D] ue=0 SRB1 DL: MAC generated: 

[PDCP    ] [D] ue=0 SRB1 UL: Integrity check. is_valid=true count=3 bearer_id=0 dir=UL
[PDCP    ] [D] ue=0 SRB1 UL: Integrity check key: 
[PDCP    ] [D] ue=0 SRB1 UL: MAC expected: 
[PDCP    ] [D] ue=0 SRB1 UL: MAC found: 
[PDCP    ] [D] ue=0 SRB1 UL: Integrity check input message. len=4
[PDCP    ] [D] ue=0 SRB1 UL: Integrity passed.

RLC

RLC headers and fields for Control Plane are

RLC AM Data PDU
- D/C bit: Indicates Data or Control PDU
- P: Indicates Polling bit
- SI: Segment Indicator
- SN: 12 bit sequence number
RLC AM Control PDU (Status PDU)
- D/C bit: Indicates Data or Control PDU
- CPT: Control PDU Type Indicates a Status PDU
- ACK_SN: 12 bit ACK sequence number
- E: Extension Bit
- R: 7 reserved bits

RLC UE Log Messages

[RLC-NR ] [I] Added LTE radio bearer with LCID 0 in Transparent Mode
[RLC-NR ] [I] BCCH TXSCH message received.

[RLC-NR ] [I] SRB0: Tx SDU, queue size=1, bytes=6
[RLC-NR ] [D] SRB0: Complete SDU scheduled for tx. Stack latency: 20067 us
[RLC-NR ] [I] SRB0: Tx Transparent Mode PDU, queue size=0, bytes=0

[RLC-NR ] [D] SRB1: RLC AM NR configured rx entity.
[RLC-NR ] [D] SRB1: RLC AM NR configured tx entity.
[RLC-NR ] [I] SRB1: AM NR configured - tx_sn_field_length=12, rx_sn_field_length=12, t_poll_retx=45, poll_pdu=-1, poll_byte=-1, max_retx_thresh=8, t_reassembly=35, t_status_prohibit=0, tx_queue_length=256
[RLC-NR ] [I] Added NR radio bearer with LCID 1 in Acknowledged Mode
[RLC-NR ] [I] SRB1: Tx SDU (33 B, PDCP_SN=0 tx_sdu_queue_len=1)

[RLC-NR ] [D] SRB1: buffer state - do_status=yes
[RLC-NR ] [D] SRB1: Generating status PDU
[RLC-NR ] [D] SRB1: buffer state - total status report: 3 bytes
[RLC-NR ] [D] SRB1: total buffer state - 1 SDUs (35 B)

RLC gNB Log Messages

[RLC     ] [D] du=0 ue=0 SRB1 DL: MAC opportunity. grant_len=55 tx_window_size=1
[RLC     ] [D] du=0 ue=0 SRB1 DL: Re-transmission required. retx_queue_size=1
[RLC     ] [D] du=0 ue=0 SRB1 DL: Processing RETX. sn=0 so=0 len=51
[RLC     ] [D] du=0 ue=0 SRB1 DL: Creating RETX PDU. sn=0 so=0 len=51 si=full retx_payload_len=51 expected_hdr_len=2 grant_len=55
[RLC     ] [D] du=0 ue=0 SRB1 DL: Checking poll bit requirements for PDU. sn=0 is_retx=true sdu_bytes=0 poll_sn=0
[RLC     ] [D] du=0 ue=0 SRB1 DL: Setting poll bit due to empty buffers/inablity to TX. sn=0 poll_sn=0
[RLC     ] [D] du=0 ue=0 SRB1 DL: Setting poll bit due to expired poll retransmit timer. sn=0 poll_sn=0
[RLC     ] [D] du=0 ue=0 SRB1 DL: Started poll retransmit timer. poll_sn=0
[RLC     ] [I] du=0 ue=0 SRB1 DL: RETX PDU. dc=data p=1 si=full sn=0 pdu_len=53 grant_len=55 retx_count=1
[RLC     ] [D] du=0 ue=0 SRB1 DL: TX entity state. tx_next_ack=0 tx_next=1 poll_sn=0 pdu_without_poll=0 byte_without_poll=0 sn_under_segmentation=none

MAC

The MAC layer provides

MAC PDU
- consists of one or more MAC subPDUs
  - DL-SCH
  - UL-SCH
  - Transparent (PCH, BCH, DL-SCH, BCCH)
  - Random Access Response
MAC subPDU
- MAC subheader only (including padding)
- MAC subheader and MAC SDU
- MAC subheader and MAC CE
- MAC subheader and padding
MAC Subheader
- Corresponds to either a MAC SDU, MAC CE, or Padding
MAC SDU
- Variable size bit string that is byte aligned
MAC Control Elements
- Buffer Status Report
- C-RNTI
- Contention Resolution
- Timing Advance Command
- etc.

The MAC layer transfers and decodes Transport Blocks between the MAC and PHY layer.

MAC Subheader Parameters

LCID: Identifies the logical channel corresponding to the MAC SDU, MAC CE, or Padding.
- From Examples Above – observe which transport channel is used in the MAC header (DL-SCH or UL-SCH) and reference the tables below
  - DL-SCH LCID = 62 (UE Contention Resolution Identity)
  - DL-SCH LCID = 63 (Padding)
  - UL-SCH LCID = 52 (CCCH)
  - UL-SCH LCID = 61 (Short BSR)
  - UL-SCH LCID = 63 (Padding)

Random Access Response Subheader

E (Extension)
T (Type)
R (Reserved)
RAPID (Random Access Preamble Identity)

RAR Payload

R (Reserved)
Timing Advance Command
Uplink Grant
Temporary C-RNTI

MAC UE Log Messages

## UE RX Authentication Request
[MAC-NR ] [D] [ 5530] tb_decoded(): cc_idx=0, tti=5530, rnti=0x4601, pid=0, tbs=80, ndi=1, rv=0, result=OK
[MAC-NR ] [D] [ 5530] Delivering PDU=80 bytes to Dissassemble and Demux unit
[MAC-NR ] [I] [ 5530] DL 0:  newTX tbs=80, rv=0, ack=OK, ndi=1
 [MAC-NR ] [D] [ 5531] nof_lcids_with_data=0, nof_lcgs_with_data=0, last_non_zero_lcg=-1 [lcg0=0, ] [lcid0=0, lcid1=0, ]
[MAC-NR ] [D] [ 5531] Handling MAC PDU (80 B)
[MAC-NR ] [I] [ 5531] DL LCID=1 len=53 PAD: len=24
[MAC-NR ] [D] [ 5531] Handling subPDU 1/2: rnti=0x0 lcid=1, sdu_len=53
[MAC-NR ] [D] [ 5531] Handling subPDU 2/2: rnti=0x0 lcid=63, sdu_len=24

## UE TX Short BSR
[MAC-NR ] [D] [ 5655] new_grant_ul(): cc_idx=0, tti=5659, rnti=0x4601, pid=0, tbs=88, ndi=0, rv=0, is_rar=0
[MAC-NR ] [D] [ 5655] Building new MAC PDU (88 B)
[MAC-NR ] [D] [ 5655] Adding SDUs for LCID=0 (max 86 B)
[MAC-NR ] [D] [ 5655] Adding SDUs for LCID=1 (max 86 B)
[MAC-NR ] [I] [ 5655] UL SBSR: lcg=0 bs=0 PAD: len=85
[MAC-NR ] [D] [ 5655] Generated MAC PDU (88 B)
[MAC    ] [I] [ 5655] UL 0:  New TX, rv=0, tbs=88

MAC gNB Log Messages

## GNB TX RLC Control Status PDU 
[MAC     ] [I] [   565.5] DL PDU: ue=0 rnti=0x4601 size=80: SDU: lcid=1 nof_sdus=1 total_size=5

## GNB RX Security Mode Complete / Registration Request
[MAC     ] [I] [   569.4] UL rnti=0x4601 ue=0 subPDUs: [lcid=1: len=3, lcid=1: len=67, SBSR: lcg=0 bs=7, PAD: len=467]
[MAC     ] [D] [   569.4] UL rnti=0x4601 ue=0 lcid=1 UL-DCCH: Forwarding SDU of 3 bytes

PHY

PHY Transmission and reception is very detailed and complex and, though it does fall under the topic of “Data Transmission”, the scope of the Physical Layer for this article will only include the Physical Channels that data is sent and received on.

Downlink Physical Channels

PBCH
- Master Information Block
PDCCH
- Layer 1 Control Information using Downlink Control Information (DCI)
PDSCH
- RRC Messages
- System Information
- Paging
- Application Data (User Plane)

Uplink Physical Channels

PRACH
- Random Access Message 1 (Preamble)
PUCCH
- Layer 1 Control Information using Uplink Control Information (UCI)
PUSCH
- RRC Messages
- Application Data (User Plane)

PHY UE Log Messages

[PHY2-NR] [D] [ 5510] PBCH-MIB: sfn=551 ssb_idx=0 hrf=n scs=15 ssb_offset=6 dmrs_typeA_pos=pos2 coreset0=12 ss0=0 barred=n intra_freq_reselection=n spare=0

[PHY-SA ] [I] [ 5443] PRACH: cell.id=1, configIdx=1, rootSequence=1, zeroCorrelationConfig=0, freqOffset=0
[PHY-SA ] [D] [ 5450] PRACH Buffer: Ready to send at tti: 5454 (now is 5450)
[PHY-SA ] [I] [ 5450] PRACH: Transmitted preamble=0, tti_tx=5454, CFO=-0.02 KHz, nof_sf=1, target_power=-1.0 dBm

[PHY1-NR] [D] [ 5473] PDCCH: c-rnti=0x4601 dci=0_0 ss=common3 L=2 cce=0 EPRE=-4.91, RSRP=-26.95, corr=0.006 nof_bits=41 crc=KO
[PHY2-NR] [I] [ 5474] PDCCH: cc=0, c-rnti=0x4601 dci=1_0 ss=common0 L=2 cce=0 f_alloc=0x5ff t_alloc=0x0 vrb_to_prb_map=0 mcs=0 ndi=1 rv=0 harq_id=0 dai=0 pucch_tpc=1 pucch_res=3 harq_feedback=3 
[PHY2-NR] [I] [ 5474] PDCCH: coreset=0,
[PHY2-NR] [I] [ 5474] PDSCH: cc=0 pid=0 c-rnti=0x4601 prb=(2,83) symb=(1,13) CW0: mod=QPSK tbs=301 R=0.123 rv=0 CRC=OK iter=1.0 evm=0.05 t_us=383 epre=+22.5 snr=+19.8 cfo=+1.9 delay=+0.0  cfo=1.9

[PHY0-NR] [I] [ 5484] Decoding not required. Skipping PDSCH. ack_tti_tx=5488
[PHY0-NR] [D] [ 5484] use_pusch=n nof_cc=1
[PHY0-NR] [I] [ 5484] PUCCH: cc=0, f=1 prb=0:1 symb=0:14 cs=0 occ=0 rnti=0x4601 ack=1 , tti_tx=5488

[PHY0-NR] [I] [ 5505] PUSCH: cc=0 pid=0 c-rnti=0x4601 prb=(3,26) symb=(0,13) CW0: mod=QPSK tbs=528 R=0.670 rv=0  t=153 us cfo=15 tti_tx=5509

PHY gNB Log Messages

[PHY     ] [D] [   545.4] PRACH: rsi=1 rssi=+1.1dB detected_preambles=[{idx=0 ta=2.34us detection_metric=6.6}] t=576.4us

[PHY     ] [D] [   546.0] PDSCH: rnti=0x0039 prb=[0, 3) symb=[1, 14) mod=QPSK rv=0 tbs=10 t=31.4us
[PHY     ] [D] [   546.0] PDCCH: rnti=0x0039 ss_id=1 format=1_0 cce=0 al=4 t=36.5us

[PHY     ] [D] [   550.6] PUCCH: rnti=0x4601 format=2 prb=[104, 105) prb2=na symb=[10, 12) csi1=1111 t=54.0us
[PHY     ] [D] [   550.9] PUSCH: rnti=0x4601 h_id=0 prb=[3, 27) symb=[0, 14) mod=QPSK rv=0 tbs=528 crc=OK iter=1.0 sinr=16.6dB t=276.7us uci_t=0.0us ret_t=0.0us

Procedure Analysis

Message Sizes

When analyzing logs I know that I can focus on Physical Channels to localize specific procedures since messages are transferred over the air interface on PDSCH or PUSCH. For example, I will take all of the gNB PDSCH messages and compare the Transport Block Size (TBS) in bytes, to the pcaps. I focus a lot on the size of messages, PDUs, headers, etc.

2024-12-19T14:40:39.760728 [PHY     ] [   546.0] PDSCH: rnti=0x0039 prb=[0, 3) symb=[1, 14) rv=0 tbs=10

Authentication Request

Using the Authentication Request as an example and look at the graphic below the PCAP data, we can see how each of the layers are encapsulated by the subsequent lower layer.


MAC-NR DL-SCH (LCID:1 53 bytes) (Padding 24 bytes) 
    [Context (RNTI=17921)
        [Radio Type: FDD (1)]
        [Direction: Downlink (1)]
        [RNTI: 0x4601 (17921)]
        [RNTI Type: C-RNTI (3)]
        [UEId: 1]
        [HarqId: 0]
    Subheader: (LCID:1 53 bytes) 
        0... .... = Reserved: 0x00
        .0.. .... = Format: 8 bits
        ..00 0001 = LCID: 1 (1)
        SDU Length: 53
        DL-SCH SDU: c000000028854fc00ac020400004311cf353ab99fe6e1b51f84100450000e4021615448f373f300017d2f99839701b570000000000
    RLC-NR   UEId=1 [DL] [AM] SRB:1  [DATA] (P) SN=0               [51-bytes]
        [Context]
            [Direction: Downlink (1)]
            [RLC Mode: Acknowledged Mode (4)]
            [UEId: 1]
            [Bearer Type: SRB (4)]
            [Bearer Id: 1]
            [PDU Length: 53]
            [Sequence Number length: 12]
        AM Header  (P) SN=0             
            1... .... = Data/Control: Data PDU
            .1.. .... = Polling Bit: Status report is requested
            ..00 .... = Segmentation Info: Data field contains all bytes of an RLC SDU (0x0)
            .... 0000 0000 0000 = Sequence Number: 0
        AM Data: 000028854fc00ac020400004311cf353ab99fe6e1b51f84100450000e4021615448f373f300017d2f99839701b570000000000
        PDCP-NR (SN=0   )
            [Configuration: UEId=  1   SRB-1  (direction=Downlink, plane=Signalling)]
                [Direction: Downlink (1)]
                [Plane: Signalling (1)]
                [UE: 1]
                [Bearer type: DCCH (1)]
                [Bearer Id: 1]
                [Seqnum length: 12]
                [MAC-I Present: True]
            0000 .... = Reserved: 0
            .... 0000 0000 0000 = Seq Num: 0
            [Sequence Analysis - OK]
                [OK: True]
            NR Radio Resource Control (RRC) protocol
                DL-DCCH-Message
                    message: c1 (0)
                        c1: dlInformationTransfer (5)
                            dlInformationTransfer
                                rrc-TransactionIdentifier: 0
                                criticalExtensions: dlInformationTransfer (0)
                                    dlInformationTransfer
                                        dedicatedNAS-Message: 7e0056010200002188e79a9d5ccff370da8fc208022800072010b0aa2479b9f98000be97ccc1cb80dab8
            MAC: 0x00000000 [Matches calculated result]
    Subheader: (Padding 24 bytes) 
        00.. .... = Reserved: 0x00
        ..11 1111 = LCID: Padding (63)
        Padding: 000000000000000000000000000000000000000000000000
Non-Access-Stratum 5GS (NAS)PDU
    Plain NAS 5GS Message
        Extended protocol discriminator: 5G mobility management messages (126)
        0000 .... = Spare Half Octet: 0
        .... 0000 = Security header type: Plain NAS message, not security protected (0)
        Message type: Authentication request (0x56)
        0000 .... = Spare Half Octet: 0
        NAS key set identifier - ngKSI
            .... 0... = Type of security context flag (TSC): Native security context (for KSIAMF)
            .... .001 = NAS key set identifier: 1
        ABBA
            Length: 2
            ABBA Contents: 0000
        Authentication Parameter RAND - 5G authentication challenge
            Element ID: 0x21
            RAND value: 88e79a9d5ccff370da8fc20802280007
        Authentication Parameter AUTN (UMTS and EPS authentication challenge) - 5G authentication challenge
            Element ID: 0x20
            Length: 16
            AUTN value: b0aa2479b9f98000be97ccc1cb80dab8
                SQN xor AK: b0aa2479b9f9
                AMF: 8000
                MAC: be97ccc1cb80dab8