Open RAN Terminology and Players

When we made our little Open RAN explainer, couple of years back, we never imagined this day when so many people in the industry will be talking about Open RAN. I have lost track of the virtual events taking place and Open RAN whitepapers that have been made available just in the last month.

One of the whitepapers just released was from NTT Docomo, just in time for MWC 2021. You can see the link in the Tweet

NTT Docomo has published 5G Open RAN Ecosystem (OREC) Whitepaper - https://t.co/17CJZuGnTT#Free5Gtraining #3G4G5G #4G #5G #NTT #NTTDocomo #OpenRAN #ORAN #OpenNetworks #Interfaces #Virtualization #Intelligence #TCO #IOT #Integration #RIC #Security #Performance #Deployment pic.twitter.com/1niHXnWr1v

— Free 5G Training (@5Gtraining) June 29, 2021

Even after so much information being available, many people still have basic questions about Open RAN and O-RAN. I helped make an Open RAN explainer series and blogged about it here. Just last week, I blogged about the O-RAN explainer series that I am currently working on, here.

There were some other topics that I couldn't cover elsewhere so made some short videos on them for the 3G4G YouTube channel. The first video/presentation explains Open RAN terminology that different people, companies and organizations use. It starts with open interfaces and then looks at radio hardware disaggregation and compute disaggregation. Moving from 2G/3G/4G to 5G, it also explains the Open RAN approach to a decomposed architecture with RAN functional splits.

If you look at the Telecom Infra Project (TIP) OpenRAN group or O-RAN Alliance, the organizations driving the Open RAN vision and mission, you will notice many new small RAN players are joining one or both of them. In addition, you hear about other Open RAN consortiums that again include small innovative vendors that may not be very well known. 

The second video is an opinion piece looking at what is driving these companies to invest in Open RAN and what can they expect as return in future.

As always, all 3G4G videos' slides are available on our SlideShare channel.

Related Posts:

• The 3G4G Blog: A quick tutorial on Open RAN, vRAN & White Box RAN
• The 3G4G Blog: Open RAN Explanation, Videos, White papers and Other Resources
• The 3G4G Blog: O-RAN Introduction for Beginners
• Telecoms Infrastructure Blog: NTT Docomo's 5G Network is based on 'Open RAN' Principles
• Telecoms Infrastructure Blog: NTT Docomo's 5G RAN Infrastructure
• The 3G4G Blog: 5G RAN Functional Splits
• The 3G4G Blog: From traditional RAN to Open RAN - O-RAN: Goals and Challenges
• 3G4G: Open RAN, OpenRAN and O-RAN 

Open RAN Explanation, Videos, White papers and Other Resources

Couple of years back, just before MWC 2019, we made what I would like to think of as the first proper explanation of Open RAN. I posted it on this blog here and the video has been viewed nearly 45,000 times. At that time, the concept of Open RAN was still quite new and in my day job with Parallel Wireless*, I was spending quite some time explaining what it really means.

Anyway, I think it made the concept of Open RAN so easy to understand that I have seen tens, if not hundreds, of people copy it, but only a few kind people give credit. 

With the Telecom Infra Project (TIP) and O-RAN driving the ecosystem further, I along with my Parallel Wireless colleagues, created a series of videos to explain the concept a bit more in detail. As expected, the introductory videos have been extremely popular while the others have been reasonably popular as well. The concept from these videos have been copied even far and wider than the original one. 

Embedded below is the playlist of all the videos (6 currently but 1 more in works):

In addition to these, I maintain a list of Open RAN whitepapers (publicly available without registration), some good articles, etc. on the 3G4G website here. I try and update the site on a regular basis so feel free to put any resources in the comments of this post and I will add them on the site during the next update.

Related Posts:

• The 3G4G Blog: O-RAN Introduction for Beginners
• The 3G4G Blog: A quick tutorial on Open RAN, vRAN & White Box RAN
• 3G4G: Open RAN, OpenRAN and O-RAN
• Telecoms Infrastructure Blog: Small Cells World Summit Open RAN Webinar
• The 3G4G Blog: From traditional RAN to Open RAN - O-RAN: Goals and Challenges
• Telecoms Infrastructure Blog: NTT Docomo's 5G Network is based on 'Open RAN' Principles 

*Full Disclosure: I work for Parallel Wireless as a Senior Director, Technology & Innovation Strategy. This blog is maintained in my personal capacity and expresses my own views, not the views of my employer or anyone else. Anyone who knows me well would know this. 

A Look into 5G Virtual/Open RAN - Part 7: Change of gNB-CU-UP without Handover

This will be the last part of my series about Virtual/Open RAN signaling procedures. In this final post (although not the last one on this blog) I would like to present a very unique procedure that emerges from the facts of virtualization and automation of the RAN. And again I would like to present the big picture overview of the scenario that is called "Change of gNB-CU UP" (without handover). The full message flow (ladder diagram) can be found in 3GPP 38.401, chapter 8.9.5.

In the same chapter one can read that the trigger point for starting a change of the gNB-CU UP is quite vague. 3GPP writes: "e.g. a measurement report". However, which particular measurement event should trigger such a procedure? Even when looking into the Rel. 16 versions of 3GPP 38.331 (NR RRC) it becomes evident that all measurement events that are not dealing with NR sidelink or V2X connectivity are triggered by changing reference signal strength or rising interference. 

However, in case of a gNB-CU UP change without handover the UE does not move to a different cell. This makes me think - correct me if I am wrong - the true trigger points for this procedures come form a different entity, e.g. from the AI-driven policies and algorithms of the RAN Intelligence Controller (RIC) that is a fundamental element of the Open RAN architecture.

So what is necessary from a signaling perspective to change the gNB-CU UP during an ongoing connection?

There are new transport network resources aka GTP/IP-Tunnels required to steer the user plane traffic to and through the RAN. A new F1-U tunnel is necessary as well a a new NG-U tunnel, because also the user plane traffic between RAN and the UPF in the 5G core network must be exchange using a new route.

When it is clear which new UP transport tunnels need to be established (and which old ones need to be deleted) it is really simple to understand the overall scenario.

A F1AP UE Context Modification procedure is performed to switch the F1-U tunnel. NGAP Path Switch procedure is performed to switch the NG-U tunnel. And an E1AP Bearer Context Modification procedure is the prerequisite, because it delivers the new UL GTP-TEID for the F1-U tunnel as well as the new DL GTP-TEID for the NG-U tunnel.

Unfortunately the authors of 3GPP 38.401 are not very precise when mentioning protocol procedures defined in other specs. Thus, they speak about "bearer modification" when looking at F1AP and "Path Update" for NGAP.

It is not a big deal, but something you just need to know if you want to analyze real-world message flows of this scenario.

Related Posts:

• 3G4G: Open RAN, OpenRAN and O-RAN

A Look into 5G Virtual/Open RAN - Part 6: Inter-gNB CU Handover involving Xn

In previous blog posts I have discussed intra-gNB-DU handover and inter-gNB-DU handover scenarios.Now it is time to look at inter-gNB-CU handover that uses the Xn interface.

At the RRC protocol layer there will be the measurement setups and measurement reports as in the intra-gNB handover cases. And F1AP UE Context Setup and Release Procedures are identical with the ones discussed for inter-gNB-DU handover. Only the cause values are expected to be different, e.g. "successful handover".

Thus, I do not want to  focus here on la adder diagram call flow (that is by the way very well described in 3GPP 38.401, chapter 8.9.4), but invite you to have a look at a "big picture" that you see below.

(click image to enlarge)

What characterizes the inter-gNB handover is the transfer of the UE RRC/NGAP context form the source gNB-CU to the target gNB-CU. When the Xn interface is available to connect two neighbor gNBs this context transfer is executed using the XnAP Handover Preparation procedure. The Initiating Message of this procedure transfers the UE context parameters to the target gNB-CU. Then embedded in the Successful Outcome message the handover command is sent in return to the source gNB-CU that forwards it to the UE. In addition a temporary user plane transport tunnel for the purpose of data forwarding is established and later on released on the Xn user plane interface.

Once the UE performed the handover on the radio interface all the transport tunnels for the payload transmission need to be switched from the old gNB to the new one. This includes the tunnel to the UPF that is managed by the NGAP. Thus, the target gNB-CU starts the NGAP Path Switch procedure. 

In the target gNB environment it is necessary to establish a new F1AP UE context, new E1AP Bearer Context and new F1-U payload transport tunnel. All this happens BEFORE the Handover Command is sent to the source gNB/UE. And once there is an indication that the handover is completed all the radio and transport resources controlled by the source gNB will be released.

So the figure above looks complicated, but actually the underlying logic of context/data forwarding, radio resource allocation and transport tunnel switching is quite simple.

Special note: In case there is no Xn interface available the UE context/handover information can be transmitted using NGAP Handover Preparation procedure on the source side of the connection and NGAP Handover Resource Allocation procedure on the target side of the connection.

Related Posts:

• A Look into 5G Virtual/Open RAN - Part 7: Change of gNB-CU-UP without Handover
• 3G4G: Open RAN, OpenRAN and O-RAN

A Look into 5G Virtual/Open RAN - Part 5: Inter-gNB DU Handover

My last blog post discussed the intra-gNB-DU handover. Now it is time to look at inter-gNB-DU handover. This means: the target cell is located in the same gNB, but connected to a different gNB Distributed Unit (gNB-DU) than the source cell.

The figure below shows the message flow:

(Click on the image to enlarge)

As you can see it was not so easy to show all the messages in one flow chart and again I have simplified things a little bit. So it is not shown that NR RRC messages are transparently forwarded by the gNB-DU when sent to or received from the UE.

It should also be noted that between step 8 and 9 the UE performs a random access procedure on the radio interface that is also not shown.

Beside this the RRC measurement configuration and measurement report is identical with the same procedure in the intra-gNB-DU handover case (step 1+2)

However, due to the fact the target cell is connected to a different gNB-DU a new F1AP UE context must be established on the incoming F1-C leg (step 3+4). As in a new connection setup scenario the target gNB-DU provides all necessary lower layer parameters for the target cell radio link including a new c-RNTI.

Since we need also a new user plane transport tunnel to exchange payload on the F1-U interface between the target gNB-DU and the gNB-CU UP an E1AP Bearer Context Modification procedure is performed in step 5+6.

The following F1AP UE Context Modification Request is used to transmit the handover command (NR RRC Reconfiguration message with target cell parameters) towards the UE (step 7). In step 8 the F1AP UE Context Modification Response confirms that the handover command was forwarded to the UE.

After successful random access the UE sends NR RRC Reconfiguration Complete message on the new radio link (step 9) and this triggers the F1AP UE Context Release procedure on the outgoing F1-C leg.

Related Posts:

• A Look into 5G Virtual/Open RAN - Part 6: Inter-gNB CU Handover involving Xn
• 3G4G: Open RAN, OpenRAN and O-RAN

A Look into 5G Virtual/Open RAN - Part 4: Intra-gNB DU Handover

In the previous posts of this series I described O-RAN interfaces and protocols, connection establishment and connection release procedures. Now it is time to look at handovers.

As mentioned in one of the earlier posts the gNB-CU CP will be in charge of controlling hundreds of gNB-DUs in a similar way like the 3G RNC was in charge of controlling hundreds of UMTS NodeBs. As a result the most common 5G SA intra-system handovers will be intra-gNB handovers. These handovers can further be classified into intra-gNB-DU handovers (inter- as well as intra-frequency) and inter-gNB-DU handovers.

Due to the virtualization of RAN network functions we will also find another form of switching transmission path, which is a change of the gNB-CU UP during the call without mobility of the UE. This scenario I will discuss later in a separate blog post.

Today I want to focus on the intra-gNB DU handover. Here the UE moves from one cell to another one within the same distributed unit as shown in the figure below.

A prerequisite is the successful establishment of a NR RRC connection and a F1AP UE Context between the gNB-DU and the gNB-CU CP.

The F1AP transports all RRC messages between these two entities. Indeed, it transports the PDCP blocks and the gNB-DU is not aware that these PDCP blocks contain RRC messages. However, for better illustration I have not shown the PDPC part in the ladder diagram.

What we see in step 1 is a NR RRC Reconfiguration message that contains RRC measurement configurations to be enabled on the UE side. A typical trigger event for intra-frequency handovers is the A3 event that is already known from LTE RRC.

Once the UE detects a better neighbor cell meeting the A3 criteria it sends a RRC Measurement Report to the gNB-CU CP (step 2).

In step 3 the gNB-CU CP orders the gNB-DU to perform a F1AP UE Context Modification. The purpose is to allocate radio resources for the UE in the target cell and to prepare the cell change.

The gNB-DU replies with F1AP UE Context Modification Response. This messages contains the new C-RNTI and a large block of lower layer configuration parameters (e.g. for RLC and MAC layer) that need to be sent to the UE and thus, need to be transported to the gNB-CU CP before, because it is the only RAN function capable to communicate with the UE using the RRC protocol.

Hence, in step 5 we see another downlink RRC message transfer. This time it is used to transport the handover command towards the UE. The handover command is a NR RRC Reconfiguration message and it contains the new C-RNTI (new UE identity within the cell) as well as the physical cell ID of the target cell and the full set of lower layer configuration parameters previously provided by the gNB-DU.

When the gNB-CU CP receives the RRC Reconfiguration Complete message sent by the UE in step 6 the handover is successfully completed and the UE is now served by the cell with NR PCI 2.

As mentioned before there is neither XnAP (communication between two neighbor gNBs) nor NGAP (communication between gNB and AMF) involved in this handover procedure.

Related Posts:

• A Look into 5G Virtual/Open RAN - Part 5: Inter-gNB DU Handover
• 3G4G: Open RAN, OpenRAN and O-RAN

A Look into 5G Virtual/Open RAN - Part 3: Connection Release and Suspend

The 3rd post of this series introduces the details of connection release in the 5G RAN.

Indeed, we find most of the release causes known from E-UTRAN in the 5G specs and it is clear that all protocols that have been involved in the connection setup need to be perform a release procedure at the end of the connection.

However, again the split into different virtual functions brings the demand for some addition messages.

This is illustrated in figure 1 for the a release due to "user inactivity", which means: the gNB-CU UP detected that for a define time (typical settings for the user inactivity timer are expected to be between 10 and 20 seconds) no downlink payload packets have been arrived from the UPF to be transmitted.

So the gNB-CU UP sends an E1AP Bearer Context Inactivity Notification message to the gNB-CU CP that triggers the release procedures on NGAP, F1AP, RRC and E1AP. The RRC Releases message is transported over the F1 interface to the gNB-DU where is forwarded across the radio interface to the UE.

Figure 1: Connection Release due to "user inacativity"

An alternative to the connection release is the RRC Suspend procedure shown in figure 2. Here the UE is ordered to switch to the RRC Inactive state, which allows a very quick resume of the RRC connection when necessary.

Figure 2: RRC Connection Suspend

In case of suspending the RRC connection the RRC Release message contains a set of suspend configuration parameters. The probably most important one is the I-RNTI, the (RRC) Inactive Radio Network Temporary Identity.

If the RRC connection is suspended, F1AP and E1AP Contexts are released, but the NGAP UE Context remains active. Just NGAP RRC Inactivity Transition Report is sent to the AMF.

Related Posts:

• A Look into 5G Virtual/Open RAN - Part 4: Intra-gNB DU Handover
• 3G4G: Open RAN, OpenRAN and O-RAN

A Look into 5G Virtual/Open RAN - Part 2

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.

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)

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).

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:

• A Look into 5G Virtual/Open RAN - Part 3: Connection Release and Suspend
• 3G4G: Open RAN, OpenRAN and O-RAN

A Look into 5G Virtual/Open RAN - Part 1

Although it is understood in general that virtualization and increasing complexity are inherent characteristics of 5G networks many people are surprised when they realize the significant differences of 5G RAN architecture and signaling procedures compared to what they know from LTE or UTRAN.

In this blog post series I want to highlight some details that are not immediately visible when reading the 3GPP specs.

Figure 1 shows a virtualized gNB and the protocols it uses to communicate with its internal entities as well as with the UE and peer entities in neighbor network elements/functions.

Figure 1: Virtual Network Functions and Protocols in 5G RAN
(click on the image to see full size)

The core of the whole thing is the gNB-Central Unit for the Control Plane (gNB-CU CP). This function communicates directly with the UE using the NR RRC protocol. It also "talks" to the 5G Core Network represented by the AMF using the NGAP, a protocol very similar to the S1AP known from E-UTRAN. Neighboring 5G base stations are contacted using the XnAP, neighboring eNBs can be reached by using X2AP.

The other virtual functions of the gNB are the Central Units for User Plane (gNB-CU UP) and the Distributed Units (gNB-DU). While the gNB-CU UP is responsible for handling the transport of payload the gNB-DUs deal with all the allocation of radio resources, especially the scheduling. As a result the lower layer radio interface protocols, especially RLC and MAC terminate in the gNB-DUs.

For the RAN monitoring tools and the 3GPP Minimization of Drive Test (MDT) feature this means that RRC and Logged Measurement Reports sent by UEs will be available at gN-CU CP while all uplink radio quality measurements and call-related user plane metrics is only available at the gNB-DU - see figure 3.

Figure 2: Distribution of un-correlated RAN measurement tasks among different gNB virtual functions
(click on the image to see full size) 

And today, there is no 3GPP-standardized procedure to correlate this measurement information collected by different virtual gNB functions.

The full impact of the 5G RAN virtualization becomes even more evident when looking at Figure 3. It shows a single gNB-CU CP in charge of controlling several gNB-CU UPs and gNB-DUs.

In a live network deployment a single gNB-CU CP will control hundreds of gNB-DUs and maybe several gNB-CU UPs. This is why it is misleading to compare the connectivity of a gNB-CU CP with that of a LTE eNB. Rather it could be compared with a UTRAN RNC controlling a similar number of 3G base stations.

Figure 3: 5G RAN Connectivity
(click on the image to see full size)

Looking back into figure 1 we see that the F1AP is used for communication between gNB-CU CP and its gNB-DUs while the E1AP is the protocol that connects the gNB-CU CP with surrounding gNB-CU UPs.

Call-related control plane procedures of F1AP and E1AP are very similar to what is known from NGAP. There is a UE context established between the gNB-CU CP and the gNB-DU. On F1-U a GTP tunnel is established for user plane transport. At the same time an E1 Bearer Context in gNB-CU CP and gNB-CU UP keeps track of the most relevant user plane transport parameters.

All in all for setting up a single subscriber connection in the virtualized 5G RAN there are significantly more signaling transactions necessary than in E-UTRAN. Figure 4 shows a practical example.

Figure 4: 5G RAN Call Trace in NETSCOUT Session Analyzer
(click on the image to see full size)

The volume and complexity of signaling information is increasing when the UE moves or is redirected to virtual functions within one gNB e.g. due to load balancing.

The next blog post of this series will dive deeper into details of such call scenarios.

Stay tuned...

Related Posts:

• The 3G4G Blog: A Look into 5G Virtual/Open RAN - Part 2
• 3G4G: Open RAN, OpenRAN and O-RAN