5G/NR - Radio Protocol Stack Architecture

 

 

 

5G/NR System Architecture

5G/NR System Architecture is almost same as LTE System Architecture. If you are already familiar with LTE protocol stack or general concept of radio protocol stack, you would not need to spend too much time in reading this page. Just take a brief look at the various figures / diagrams shown in this page would be enough. If you are new to the concept of LTE/NR radio protocol stack, I would suggest you to go through this page whenever you have chance and try to form your own big picture.

I would not describe much details on each component of the protocol stack in this page. It is too much to describe everything in a single page. The purpose of this page is to provide you with some big picture or intuitive understanding of the radio protocol stack. Most of the fundamental idea in this page comes from 3GPP 38.300 (Radio Access) and 23.501(NAS/Core Network).

High Level Overview

As in LTE / WCDMA, NR radio protocol stack has two different stack depending on the type of data that is processed by the stack. If the data is Signaling message, it goes through the C-plane stack and if it is user data, it goes through U-Plane stack. Both U-Plane and C-Plane is made up of a common structure : PHY <-> MAC <-> RLC <-> PDCP, but the components sitting on top of PHY/MAC/RLC/PDCP gets different between C-Plane and U-Plane. In case of U-Plane, a layer called SDAP is sitting at the top of the radio stack and the SDP is connected to UPF (User Plane Function). In case of C-Plane, the two layers RRC and NAS are sitting at the top of the stack. NAS layer gets connected to AMF (Access and Mobility Management Function).

What I've mentioned can be described in a block diagram as shown below.

User plane and control plane protocol stacks side by side : SDAP over PDCP, RLC, MAC and PHY on the user plane, and NAS and RRC over the same four layers on the control plane, with NAS terminating at the AMF

Exploding the architecture into more detailed level, it can be illustrated as follows. The entire system is made up of roughly two part : Radio Accesss component and Core Network component. The main component of Radio Access parts are UE (e.g, mobile phone) and RAN (e.g, gNB, eNB etc) and the core network components are the remaining parts outside of UE and RAN.

5G system architecture in reference point form, with NSSF, NEF, NRF, PCF, UDM, AF, AUSF, AMF, SMF, UPF and DN above, and the UE and RAN protocol stacks expanded below

The two labelled bars at the right edge are the division that matters. Everything in the upper box belongs to 23.501, and everything in the two expanded stacks belongs to 38.300.

The numbered ovals on the connecting lines are the reference points, N1 through N22. They are the 23.501 way of drawing the same system the service based view draws as a bus, and the numbering is what specifications cite when they say where a procedure runs.

Three of them are enough to follow this page. N1 joins the UE to the AMF and carries NAS. N2 joins the RAN to the AMF and carries NGAP. N3 joins the RAN to the UPF and carries user data. The first two are control plane and the third is user plane, which is the same split the drawing above this one makes.

Now compare the two expanded stacks at the bottom. The UE stack has a NAS box and the RAN stack does not. That absence is the whole reason N1 is drawn as a line between the UE and the AMF rather than as two hops. NAS messages cross the RAN, and the RAN does not read them.

  • The RAN terminates RRC, never NAS : the gNB stack ends at RRC. A NAS message travels inside an RRC container, and the gNB forwards it without decoding it.
  • SDAP sits beside PDCP in the drawing, not above it : the double arrow between them marks that SDAP exists only for user plane data. Control plane traffic goes from RRC straight into PDCP.
  • The specification split follows the box, not the layer : 38.300 covers everything the UE and the gNB do on the radio, and 23.501 takes over at the AMF and the UPF.

 

Message Flow across the System

This is to show overall signal flow through the entire system with focus on radio access network. This image illustrates the high-level process of message flow in a 5G network, starting from the user's mobile device and moving through various network components until it reaches the data server. The arrows indicate the direction of the data flow, illustrating a complete cycle of communication from the user's device to the network and back.

Click on the image or here and you can get the animated slideshow for this flow and descriptions of each steps.

End to end message flow numbered 1 to 7, from a tap on the phone through the application processor, modem and RF frontend to the base station, core network, internet and data server

High level description of the signal flow depicted on this illustration is :

  • The user interacts with an application on their smartphone, which generates data to be transmitted.
  • The smartphone's modem and application processor work together to prepare and encode this data for transmission.
  • The data is then transmitted as a radio signal via the device's RF (Radio Frequency) frontend.
  • This radio signal is received by a base station (part of the 5G Radio Access Network).
  • The base station forwards the data to the core network, which is responsible for overall network management and internet connectivity.
  • The core network connects to the broader internet, routing the data to the appropriate data server.
  • The data server receives the request, processes it, and generates a response.
  • The response follows the reverse path: from the data server back to the internet, through the core network and base station, and finally to the user's smartphone, where it's processed by the modem and application processor for the user to view or use

System Component and Specification Mapping

If you are working in cellular communication industry or studying seriously in this area, you know you have to live with a huge set of specification documents called 3GPP TS(Test Specification). However you would often have difficulties in finding the appropriate documents for a specific topics you want to look into.

I want to give you some high level mapping to each of the area of 5G system as summarized below. I think this would cover the fundamental parts of each components, but this is not the entire list. You may look into many of additional documents especially for core network components, but the specification listed here can definitely be a good starting point.

This table outlines system components and their corresponding 3GPP specification numbers for 5G networks. I want you to use this table as a cheatsheet to map each network function with its technical specification, which is essential for developers, engineers, and researchers working with 5G technology to ensure compliance with international standards. The notes and references indicated by numbers in brackets ([1], [2], [3], etc.) are likely to provide additional context or details relevant to each component or specification. If you click on the numbers, it will take you to the note on sharetechnote with the detailed technical information.

Notes on Sharetechnote

System Architecture

 

Mapping of each protocol layer and network function to its 3GPP specification number, from PHY at 38.211 to 38.214 up to UPF at 33.513

 

[1]

[1]

[1]

[1],[2],[3],[4]

[1],[2],[3],[4],[5],[6]

[1], [2] ,[3],[4]

 

[1]

[1]

[1], [2], [3], [4], [5]

[1],[2],[3],[4],[5],[6],[7],[8],[9],[10],[11],[12]

Followings are the text version of this table with direct link to 3GPP document site

  • System Level Specification for Core Network : TS 24.501, 24.502, 23.003
    • UPF (User Plane Function): Specified by 3GPP TS 33.513.
    • UDM (Unified Data Management): Specified by 3GPP TS 29.503.
    • SMF (Session Management Function): Specified by 3GPP TS 29.502.
    • AUSF (Authentication Server Function): Specified by 3GPP TS 29.509.
    • AMF (Access and Mobility Management Function): Specified by 3GPP TS 33.512 and TS 29.518.
  • System Level Specification for Access Network : TS 38.300
    • NAS (Non-Access Stratum): Specified by 3GPP TS 24.501.
    • RRC (Radio Resource Control): Specified by 3GPP TS 38.331 and TS 38.306.
    • SDAP (Service Data Adaptation Protocol): Specified by 3GPP TS 37.324.
    • PDCP (Packet Data Convergence Protocol): Specified by 3GPP TS 38.323.
    • RLC (Radio Link Control): Specified by 3GPP TS 38.322.
    • MAC (Medium Access Control): Specified by 3GPP TS 38.321.
    • PHY (Physical Layer): Specified by multiple documents including 3GPP TS 38.211, 38.212, 38.213, and 38.214.

L2 Radio Stack Overview

Now let's look just one step further into the protocol stack. Take a look at the L2 (layer 2) structure of the NR U-Plane radio protocol. The structure of L2 downlink stack can be illustrated as shown below. Except the new layer called SDAP, you would notice that the overall structure is almost identical to LTE L2 structure. NR support carrier aggregation from the beginning, data for each carrier is processed separately for each carrier in SDAP, PDCP, RLC and multiplexed/scheduled in the common MAC layer. This is also same as LTE Rel 10 or higher.

38.300 downlink Layer 2 structure : QoS flows into SDAP, radio bearers into PDCP, RLC channels into RLC, logical channels into MAC, with per UE multiplexing and HARQ above the transport channels

Following is L2 structure of NR U-Plane Uplink radio protocol. Basic structure is same as downlink structure except that the uplink MAC multiplexes only this one UE.

38.300 uplink Layer 2 structure : the same sublayer ladder with a single multiplexing block, because a UE multiplexes only its own logical channels

Both drawings are the structures without carrier aggregation, which is what 38.300 Figures 6.1-1 and 6.1-2 show. Uplink carrier aggregation is supported, and 38.300 draws it separately in Figure 6.7-2. With CA configured there is one independent HARQ entity per serving cell in both directions, and one transport block per grant per serving cell when there is no spatial multiplexing.

The difference the two drawings above really show is in the MAC box. The downlink one has a Multiplexing block per UE, because a gNB serves many UEs from one scheduler. The uplink one has a single Multiplexing block, because a UE multiplexes only its own logical channels. Scheduling appears in both, but in the uplink it is the UE applying a grant rather than choosing one.

The dashed lines running across both drawings are worth naming, because each one is an interface with its own vocabulary. 38.300 states the ladder in one list, and the labels in the figures follow it exactly.

  • The physical layer offers transport channels to MAC.
  • MAC offers logical channels to RLC.
  • RLC offers RLC channels to PDCP.
  • PDCP offers radio bearers to SDAP.
  • SDAP offers QoS flows to the 5GC.

One more thing is hidden in those figures rather than drawn. BCCH and PCCH are left out for clarity, so the picture shows the traffic path and not the whole channel set. The section on channel mapping further down puts them back.

  • Each sublayer boundary renames the data : transport channel, logical channel, RLC channel, radio bearer, QoS flow. The name tells you which boundary a log line is describing.
  • Carrier aggregation is a MAC-level concept : the multi-carrier nature of the physical layer is exposed only to MAC. SDAP, PDCP and RLC therefore look the same with CA and without it.
  • Downlink multiplexes UEs, uplink multiplexes bearers : the same MAC sublayer does a different job in each direction, and that is the difference the two figures above are drawing.
  • The figures omit BCCH and PCCH : 38.300 says so explicitly. Reading them as the complete channel set leaves out broadcast and paging entirely.

What Each Layer Does

The drawings above name the sublayers and stack them in order, and that is as far as they go. The next thing a reader needs is what each sublayer is responsible for, because that is what decides which layer a problem belongs to. 38.300 lists those responsibilities in one clause per sublayer, and the table below collects them.

Read it downward for the shape of the stack. Each sublayer receives what the one above produced, performs one narrow function, and delivers the result under a different name.

Sublayer

Specification

Main services and functions

SDAP

37.324

Mapping between a QoS flow and a data radio bearer. Marking the QoS flow ID in both downlink and uplink packets.

PDCP

38.323

Sequence numbering. Header compression with ROHC or EHC. Uplink data compression. Ciphering and integrity protection. Timer based SDU discard. Routing for split bearers. Duplication. Reordering, in-order delivery, out-of-order delivery and duplicate discarding.

RLC

38.322

Transfer of upper layer PDUs. Its own sequence numbering, independent of the PDCP one. ARQ. Segmentation and re-segmentation. Reassembly. Duplicate detection. SDU discard. Re-establishment. Protocol error detection.

MAC

38.321

Mapping between logical channels and transport channels. Multiplexing and demultiplexing into transport blocks. Scheduling information reporting. HARQ. Priority handling between UEs, between logical channels of one UE, and between overlapping resources. Padding.

PHY

38.211 to 38.214

Offers transport channels to MAC. Everything the section below this one lists : synchronization, channelization, power control, beam management, frame structure and the rest.

Security appears once, at PDCP. Retransmission appears twice, as HARQ in MAC and as ARQ in RLC, and the two are not alternatives.

Two rows matter more than the others. PDCP is the only sublayer that ciphers, so anything below it is in the clear on the air interface and anything above it is protected. That single fact decides where a capture has to be taken to be readable.

RLC is the only sublayer whose function list changes with configuration, because it has three transmission modes and they do different amounts of work.

Mode

Used for

What it provides

Transparent Mode (TM)

SRB0, paging and broadcast system information

No sequence number, no segmentation, no ARQ. The RLC header is empty.

Unacknowledged Mode (UM)

DRBs that prefer latency over reliability

Sequence numbering, segmentation and reassembly, SDU discard. No ARQ.

Acknowledged Mode (AM)

every SRB other than SRB0, and DRBs that need reliability

Everything UM has, plus ARQ, re-segmentation, duplicate detection and protocol error detection.

The mode is configured per logical channel, and it does not depend on the numerology or the transmission duration of that channel.

  • Security lives at exactly one layer : PDCP ciphers and integrity protects. RLC, MAC and PHY handle ciphertext, so a MAC level capture shows structure and not content.
  • HARQ and ARQ are both retransmission, at different speeds : HARQ sits in MAC and works per transport block with soft combining. ARQ sits in RLC, works per SDU or segment, and only exists in AM.
  • Two independent sequence numbers run at once : PDCP has its own and RLC has its own, and 38.300 states that they are independent. A gap in one does not imply a gap in the other.
  • SDAP is the thinnest sublayer in the stack : two functions, and one SDAP entity per PDU session. It exists because 5G moved QoS from bearers to flows, and something had to map one onto the other.
  • SRB0 gets no RLC processing at all : transparent mode adds no header and no sequence number, which is what makes it usable before any configuration exists.

Channel Mapping across the Stack

The L2 figures above show data crossing sublayer boundaries but never name what crosses them. Those names are the channels, and there are three sets of them stacked on top of each other. Confusing one set for another is the most common way to misread a protocol trace, because a channel name alone does not say which of the three it belongs to.

Logical channels say what is being carried. Transport channels say how it is carried over the air. Physical channels are the actual time and frequency resources. The mapping between them is fixed by 38.300 and is short enough to draw in full.

Channel mapping through the stack Downlink BCCH PCCH CCCH DCCH DTCH logical BCH PCH DL-SCH transport PBCH PDSCH physical Uplink CCCH DCCH DTCH logical UL-SCH RACH transport PUSCH PRACH physical PDCCH carries no transport channel. It carries DCI directly, which is why it has no box in the middle row.

Almost everything funnels into one shared channel per direction. That concentration is the point of a shared channel design, and it is why scheduling matters so much.

Look at how narrow the middle row is. In the downlink, five logical channels reduce to three transport channels, and two of those three land on PDSCH. In the uplink, three logical channels reduce to one. The stack narrows as it descends, and DL-SCH and UL-SCH are where nearly all of it arrives.

Two entries do not follow the pattern, and both are worth knowing. BCCH is the only logical channel with two possible transport channels. The MIB goes over BCH and reaches the UE on PBCH, while the rest of the system information goes over DL-SCH and reaches it on PDSCH. That split is why a UE can read the MIB before it can read anything else.

RACH is the other. It has no logical channel above it, because nothing at MAC or above generates its content. A preamble is a sequence rather than a message, so the transport channel starts at MAC and there is nothing to map onto it.

PDCCH is missing from the drawing for a related reason. It carries DCI, which is produced by the physical layer procedures rather than passed down as a transport block, so no transport channel maps onto it. The same is true of PUCCH in the uplink.

  • Three sets of channel names, one stack : logical at the MAC to RLC boundary, transport at the PHY to MAC boundary, physical on the air. A name only makes sense once you know which of the three it belongs to.
  • Nearly everything arrives at the shared channel : DL-SCH carries BCCH, CCCH, DCCH and DTCH, and UL-SCH carries CCCH, DCCH and DTCH. Scheduling is where the traffic is separated again.
  • BCCH is the only logical channel that splits : onto BCH for the MIB and onto DL-SCH for the rest of the system information. That is the bootstrap order of an initial access.
  • Some physical channels carry no transport channel : PDCCH and PUCCH carry control information generated at the physical layer, so they have no box in the transport row.
  • RACH has no logical channel above it : it is a transport channel that starts at MAC, because a preamble is a sequence and not a message.

PHY Layer Topics

Regardless of the generations from 2G through 5G, there are some common features/functionalities even though the detailed mechanism and implementation are different. There are alsom some features/functionalities that are specific to a specific radio technology.

PHY topics wheel : Time Sync, Channelization, Power Control and Frequency Scan marked as core functions used in every generation, and MIMO, Beam Management, Frame Structure and CSI Report marked as functions that vary widely with technology

Each of these items are a huge topics and there are even more items not mentioned here. A very brief description of these items are :

  • Frequency Scan: Scanning different frequencies to identify the best ones for use in communication.
  • Time Synchronization: Ensuring that the transmission and reception of signals are precisely timed across the network.
  • Channelization: The process of definining multiple different physical resource properties and transmitting the data (e.g, user traffic, control data, sync signal etc) via different profile called 'channel'.
  • Power Control: Managing the power levels used for signal transmission to optimize performance and reduce interference.
  • Beam Management: In the context of 5G, this would involve the management of beamforming processes for directional signal transmission and reception.
  • Frame Structure: Defining the format of data frames for efficient communication and data delivery.
  • CSI Report: Channel State Information reporting, which involves the mobile device reporting back to the network on the quality of the received signal.
  • MIMO: Stands for Multiple Input Multiple Output, a method for multiplying the capacity of a radio link using multiple transmission and receiving antennas to exploit multipath propagation.

Reference

  • 3GPP TS 38.300 V19.3.0 : NR and NG-RAN Overall description. Clause 5.5 lists the transport channels, and clauses 6.1 to 6.5 hold the sublayer functions and the channel mapping
  • 3GPP TS 37.324 : Service Data Adaptation Protocol (SDAP) specification
  • 3GPP TS 38.212 : Multiplexing and channel coding. Its clause structure is where the transport channel to physical channel mapping is stated