In the first blog post of this series the different virtual RAN functions, interfaces and protocols have been discussed. Now it is time to have a look at a set of procedures that are required for the establishment of an UE connection in virtual 5G RAN.
When looking at the 5G RAN there are two of such tunnels: one on NG-U (aka N3) that is controlled by NGAP, and one on F1-U that is controlled by F1AP - see figure 1.
On behalf of these two tunnels payload data can be transported between the 5G core network User Plane Function (UPF) to the gNB Distributed Unit (gNB-DU) and vice versa. For the transport over the 5G RAN fronthaul (realized e.g. as eCPRI) and across the radio interface a dedicated radio bearer (DRB) for the user plane transport must be configured by the gNB Central Unit for the Control Plane (gNB-CU CP).
As in LTE it is the RRC protocol that establishes this DRB. However, due to the virtualization the different protocol layers for the air interface are also distributed and the gNB-DU is in charge of all the lower layer PHY/RLC/MAC parameters (e.g the c-RNTI), while the gNB-CU CP assigns higher layer parameters of PDCP and RRC like the DRB-ID. Since only the gNB-CU CP can send downlink RRC messages to the UE the lower layer parameters from the DU first need to be sent in uplink direction to the gNB-CU CP.
Beside this parameter exchange the F1AP is also responsible for the tunnel management of the F1-U Tunnel.
The downlink tunnel endpoint information is provided by the gNB-DU using F1AP, but the uplink tunnel endpoint terminates at the gNB-CU UP and thus, its endpoint parameters are received by the gNB-CU CP when it exchanges information with the gNB-CU UP on behalf of the E1AP protocol.
A similar situation we see for the NG-U tunnel that is controlled by NGAP, the protocol for communication between gNB-CU CP and the Access and Mobility Management Function (AMF) in the 5G core. Neither the gNB-CU CP nor hte AMF have direct access to the NG-U tunnel endpoints. Hence, E1AP is used again to transmit the downlink tunnel parameters to the gNB-CU CP while the uplink tunnel endpoint parameters must be sent by the UPF to the Session Management Function (SMF) using the Packet Forwarding Control Protocol (PFCP) and later by the SMF to the AMF over the service-based interface where the tunnel endpoint parameters are embedded in a JavaScript Object Notation (JSON) container.
By the way, JSON is a quite generic format for exchanging and storing different kind of data. Between the AMF and the SMF JSON is used to transport Non-Access Stratum Session Management messages (defined in 3GPP 24.501).
It looks complicated, because the F1AP messages carry RRC plus NAS messages in uplink and downlink direction, but when understanding the underlying logic it is easy.
The very first step (in the figure: step 0) is the random access procedure executed on the MAC layer involving the UE and the gNB-DU.
After successful random access the UE sends the NR RRC Setup Request message. This is the Initial UL RRC Message transported by the F1AP from the gNB-DU to the gNB-CU CP. Actually the F1AP carries PDCP transport blocks and inside the PDCP the NR RRC messages are found, but to keep it simple I do not show the PDCP header in the ladder diagram.
Beside RRC Setup Request there are also some other initial NR RRC messages and RRC response messages possible (see step 1 and 2).
More RRC messages are transported over F1AP until the RRC Connection establishment is complete.
The NR RRC Setup Complete message also transports the initial NAS message and the reception of this message by the gNB-CU CP triggers the setup of a F1AP UE context. The concept of UE context management in F1AP is the same as in NGAP or - when looking back into the E-UTRAN - in S1AP.
The GTP/IP transport tunnel on F1-U is established during F1AP UE Context Setup assisted by E1AP Bearer Context Setup procedure that provides the necessary tunnel endpoint parameters.
In the same manner the NG-U tunnel is established by the NGAP Initial UE Context Setup procedure.
Additional NAS messages (especially for session management) and NR RRC Reconfiguration are exchanged to establish the end-to-end UE connection through the core network. And that's it.
Related Posts:
The Big Picture
In 5G standalone RAN the crucial elements for user plane payload transport of an UE connection are GTP/IP transport tunnels and a dedicated radio bearer on the radio interface.When looking at the 5G RAN there are two of such tunnels: one on NG-U (aka N3) that is controlled by NGAP, and one on F1-U that is controlled by F1AP - see figure 1.
On behalf of these two tunnels payload data can be transported between the 5G core network User Plane Function (UPF) to the gNB Distributed Unit (gNB-DU) and vice versa. For the transport over the 5G RAN fronthaul (realized e.g. as eCPRI) and across the radio interface a dedicated radio bearer (DRB) for the user plane transport must be configured by the gNB Central Unit for the Control Plane (gNB-CU CP).
As in LTE it is the RRC protocol that establishes this DRB. However, due to the virtualization the different protocol layers for the air interface are also distributed and the gNB-DU is in charge of all the lower layer PHY/RLC/MAC parameters (e.g the c-RNTI), while the gNB-CU CP assigns higher layer parameters of PDCP and RRC like the DRB-ID. Since only the gNB-CU CP can send downlink RRC messages to the UE the lower layer parameters from the DU first need to be sent in uplink direction to the gNB-CU CP.
Beside this parameter exchange the F1AP is also responsible for the tunnel management of the F1-U Tunnel.
The downlink tunnel endpoint information is provided by the gNB-DU using F1AP, but the uplink tunnel endpoint terminates at the gNB-CU UP and thus, its endpoint parameters are received by the gNB-CU CP when it exchanges information with the gNB-CU UP on behalf of the E1AP protocol.
 |
| Figure 1: Network Functions, Protocols and Parameters involved in Setup of User Plane Data Transmission Resources (click on the image to see full size) |
By the way, JSON is a quite generic format for exchanging and storing different kind of data. Between the AMF and the SMF JSON is used to transport Non-Access Stratum Session Management messages (defined in 3GPP 24.501).
The Ladder Diagram
Having the Big Picture in mind it is now easier to look at the ladder diagram with the individual RAN messages for UE connection setup - shown in Figure 2.
It looks complicated, because the F1AP messages carry RRC plus NAS messages in uplink and downlink direction, but when understanding the underlying logic it is easy.
 |
| Figure 2: 5G VRAN Successful UE Connection Setup (click on the image to see full size) |
The very first step (in the figure: step 0) is the random access procedure executed on the MAC layer involving the UE and the gNB-DU.
After successful random access the UE sends the NR RRC Setup Request message. This is the Initial UL RRC Message transported by the F1AP from the gNB-DU to the gNB-CU CP. Actually the F1AP carries PDCP transport blocks and inside the PDCP the NR RRC messages are found, but to keep it simple I do not show the PDCP header in the ladder diagram.
Beside RRC Setup Request there are also some other initial NR RRC messages and RRC response messages possible (see step 1 and 2).
More RRC messages are transported over F1AP until the RRC Connection establishment is complete.
The NR RRC Setup Complete message also transports the initial NAS message and the reception of this message by the gNB-CU CP triggers the setup of a F1AP UE context. The concept of UE context management in F1AP is the same as in NGAP or - when looking back into the E-UTRAN - in S1AP.
The GTP/IP transport tunnel on F1-U is established during F1AP UE Context Setup assisted by E1AP Bearer Context Setup procedure that provides the necessary tunnel endpoint parameters.
In the same manner the NG-U tunnel is established by the NGAP Initial UE Context Setup procedure.
Additional NAS messages (especially for session management) and NR RRC Reconfiguration are exchanged to establish the end-to-end UE connection through the core network. And that's it.
Related Posts:
GNB-DU should be in charge of High layer Phy/MAC/RLC instead of "low layer Phy/RLC/MAC"?
ReplyDeleteInstead of "the gNB-DU is in charge of all the lower layer PHY/RLC/MAC parameters (e.g the c-RNTI)", is it gonna be " high layer Phy/MAC/RLC"?
ReplyDelete