Showing posts with label Signalling. Show all posts
Showing posts with label Signalling. Show all posts

Wednesday 1 April 2020

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:

Wednesday 4 March 2020

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:

Friday 21 February 2020

EPS Fallback in 5G Standalone Deployments

It can be expected that later this year some mobile network operators will launch their initial 5G standalone (5G SA) deployments.

Nevertheless there will remain areas with temporary or permanently weak 5G NR coverage. One possible reason might be that even when 5G and LTE antennas are co-located, which means: mounted at the same remote radio head, the footprint of the 5G NR cell is significantly smaller when it uses a higher frequency band than LTE - see figure 1.

Figure 1: Smaller footprint of co-located 5G NR cell with higher frequency

Especially UEs making Voice over New Radio (VoNR) calls from the 5G cell edge have a high risk of experiencing bad call quality, in worst case a call drop. To prevent this the UE is forced  during the voice call setup towards 5G core network (5GC) to switch to a LTE/EPS connection where the radio conditions are better for the voice service.

The same procedure for which the term "EPS Fallback" was coined by 3GPP also applies when the UE is served by a 5G cell that is not configured/not optimized for VoNR calls or when the UE does not have all needed VoNR capabilities.

Figure 2: Two options for EPS fallback

When looking at the RAN there are two options for executing the EPS Fallback as shown in figure 2.

In option A the 5G radio connection is released after the initial call attempt is successfully finished and with the 5G RRC Release the UE is ordered to reselect to a 4G cell where a new radio connection is started for the VoLTE call. In this case the UE context is transferred from the AMF to the MME over the N26 interface. 3GPP seems to use also the term "RAT fallback" for this option.

Option B is to perform a 5G-4G inter-RAT handover. Here the session management and user plane tunnels in the core network are handed over from SMF/UPF to MME/S-GW in addition. This is realized with the GTPv2 Forward Relocation procedure on N26 interface.

All in all the EPS fallback is expected to cause an additional call setup delay of approximately 2 seconds.

For the inter-RAT handover case it is easy to detect from signaling information that an EPS fallback was triggered. In the source-eNodeB-to-target-eNodeB-transparent-container sent by the gNB to the eNB a boolean "IMS voice EPS fallback from 5G" indicator will be found that is set to "true". This container is named according to the receiving entity and will be carried by the NGAP Handover Preparation, GTPv2 Forward Relocation Request and the S1AP Handover Request messages.

If a redirection for Voice EPS Fallback is possible or not is indicated in the NGAP Initial Context Setup Request, Handover Request (during 5G intra-system handover) and Path Switch Request Acknowledge (after Xn handover) messages, all sent by the AMF to the gNB.

Further the NGAP protocol provides the cause value "IMS voice EPS fallback or RAT fallback triggered" in the PDU Session Resource Modify Response message indicating that a requested VoNR session cannot be established.  

An excellent, very detailed description of N26 interface functionality and testing ia available here.

Tuesday 21 January 2020

How MOCN RAN-Sharing Works

Shared RAN deployment scenarios are an excellent opportunity for mobile network operators to lower their investments on both, network hardware and operational costs by sharing resources.

The MORAN approach where each operator continues to have its dedicated spectrum (= radio network cells) is easy to understand.

However, the Multi-Operator Core Network (MOCN) is a bit more complex, especially if one of the involved operators asks for service assurance KPIs that apply to its - and only its - subscribers. In this case it is a prerequisite to find out which "call" belongs to which core network operator to enable further KPI correlation and aggregation.

The figure below illustrates how this works:

(click on picture for larger version)

In the System Information Block (SIB) 1 of the cell a list of PLMN-IDs is broadcasted followed by a single Tracking Area Code (which can be combined each of the PLMN-IDs to get multiple TAIs) and a single Cell Identity.

Encoding is specified in 3GPP 36.331 (RRC) as follows:

SystemInformationBlockType1 ::=     SEQUENCE {
    cellAccessRelatedInfo              SEQUENCE {
       plmn-IdentityList                 PLMN-IdentityList,
       trackingAreaCode                  TrackingAreaCode,
       cellIdentity                      CellIdentity,

The spec further defines that the ECGI is the CellIdentiy combined with the first (!!!) PLMN-ID from the PLMN-ID List:

CellGlobalIdEUTRA field descriptions
cellIdentity
Identity of the cell within the context of the PLMN.
plmn-Identity
Identifies the PLMN of the cell as given by the first PLMN entry in the plmn-IdentityList in SystemInformationBlockType1.

So there is one and only 1 ECGI per radio cell in the network, but multiple PLMN-IDs and hence, multiple TAI, one fore each core network operator, are broadcasted.

During RRC establishement a particular UE signals on behalf on the selected PLMN-ID information element in the RRC Connection Setup Complete message to which core network operator shall be used.

This information is "translated" by the eNB into ECGI and TAI with different PLMN-IDs. While the ECGI displays the PLMN-ID of the operator that owns the RAN equipment the TAI shows the selected PLMN-ID of the UE's core network operator. 

Related Posts:

Sunday 19 January 2020

2-step RACH Enhancement for 5G New Radio (NR)

5G Americas recently published a white paper titled, "The 5G Evolution: 3GPP Releases 16-17" highlighting new features in 5G that will define the next phase of 5G network deployments across the globe. It's available here. One of the sections in that details the 2-step RACH enhancement that is being discussed for a while in 3GPP. The 2-step process would supercede the 4-step process today and would reduce the lartency and optimise the signalling.


Here are the details from the 5G Americas whitepaper:

RACH stands for Random Access Channel, which is the first message from UE to eNB when it is powered on. In terms of Radio Access Network implementation, handling RACH design can be one of the most important / critical portions.
The contention-based random-access procedure from Release 15 is a four-step procedure, as shown in Figure 3.12. The UE transmits a contention-based PRACH preamble, also known as Msg1. After detecting the preamble, the gNB responds with a random-access response (RAR), also known as Msg2. The RAR includes the detected preamble ID, a time-advance command, a temporary C-RNTI (TC-RNTI), and an uplink grant for scheduling a PUSCH transmission from the UE known as Msg3. The UE transmits Msg3 in response to the RAR including an ID for contention resolution. Upon receiving Msg3, the network transmits the contention resolution message, also known as Msg4, with the contention resolution ID. The UE receives Msg4, and if it finds its contention-resolution ID it sends an acknowledgement on a PUCCH, which completes the 4-step random access procedure.

The four-step random-access procedure requires two round-trip cycles between the UE and the base station, which not only increases the latency but also incurs additional control-signaling overhead. The motivation of two-step RACH is to reduce latency and control-signaling overhead by having a single round trip cycle between the UE and the base station. This is achieved by combining the preamble (Msg1) and the scheduled PUSCH transmission (Msg3) into a single message (MsgA) from the UE, known as MsgA. Then by combining the random-access respond (Msg2) and the contention resolution message (Msg4) into a single message (MsgB) from the gNB to UE, see Figure 3.13. Furthermore, for unlicensed spectrum, reducing the number of messages transmitted from the UE and the gNB, reduces the number of LBT (Listen Before Talk) attempts.

Design targets for two-step RACH:

  • A common design for the three main uses of 5G, i.e. eMBB, URLLC and mMTC in licensed and unlicensed spectrum.
  • Operation in any cell size supported in Release 15, and with or without a valid uplink time alignment (TA).
  • Applicable to different RRC states, i.e. RRC_INACTIVE, RRC_CONNECTED and RRC_IDLE states.
  • All triggers for four-step RACH apply to two-step RACH including, Msg3-based SI request and contention-based beam failure recovery (CB BFR).

As described earlier, MsgA consists of a PRACH preamble and a PUSCH transmission, known as MsgA PRACH and MsgA PUSCH respectively. The MsgA PRACH preambles are separate from the four-step RACH preambles, but can be transmitted in the same PRACH Occasions (ROs) as the preambles of fourstep RACH, or in separate ROs. The PUSCH transmissions are organized into PUSCH Occasions (POs) which span multiple symbols and PRBs with optional guard periods and guard bands between consecutive POs. Each PO consists of multiple DMRS ports and DMRS sequences, with each DMRS port/DMRS sequence pair known as PUSCH resource unit (PRU). two-step RACH supports at least one-to-one and multiple-to-one mapping between the preambles and PRUs.

After the UE transmits MsgA, it waits for the MsgB response from the gNB. There are three possible outcomes:

  1. gNB doesn’t detect the MsgA PRACH ➡ No response is sent back to the UE ➡ The UE retransmits MsgA or falls back to four-step RACH starting with a Msg1 transmission.
  2. gNB detects MsgA preamble but fails to successful decode MsgA PUSCH ➡ gNB sends back a fallbackRAR to the UE with the RAPID (random-access preamble ID) and an uplink grant for the MsgA PUSCH retransmission ➡ The UE upon receiving the fallbackRAR, falls back to four-step RACH with a transmission of Msg3 (retransmission of the MsgA PUSCH).
  3. gNB detects MsgA and successfully decodes MsgA PUSCH ➡ gNB sends back a successRAR to the UE with the contention resolution ID of MsgA ➡ The reception of the successRAR successfully completes the two-step RACH procedure.

As described earlier, MsgB consists of the random-access response and the contention-resolution message. The random-access response is sent when the gNB detects a preamble but cannot successfully decode the corresponding PUSCH transmission. The contention resolution message is sent after the gNB successfully decodes the PUSCH transmission. MsgB can contain backoff indication, fallbackRAR and/or successRAR. A single MsgB can contain the successRAR of one or more UEs. The fallbackRAR consists of the RAPID: an uplink grant to retransmit the MsgA PUSCH payload and time-advance command. The successRAR consists of at least the contention resolution ID, the C-RNTI and the TA command.

For more details on this feature, see 3GPP RP-190711, “2-step RACH for NR” (Work-item description)

Tuesday 14 January 2020

EN-DC SRB3 Demystified


3GPP 37.340 says that it is up the secondary node to establish "SRB3", but what exactly does this mean and how is it done?

Simple answer: The establishment of a signaling radio bearer (SRB) 3 in EN-DC mode means that RRC Measurement Reports for NR quality can be sent directly to the SgNB. This enables the 5G node to make intra-SgNB handover decisions and start the handover execution without involving the master eNodeB of the connection.

To prevent confusion the figure below shows a simplified scenario in which the Complete/Acknowledgement messages are not mentioned although they will be seen in the message flow.

A prerequisite is the successful addition of 5G radio resources as described in an earlier blog post. After this is completed the UE in the example transmits user plane information over the NR cell with the physical cell ID (PCI) = 12. In the transport network this cell is identified by NR CGI = xxxx52 (where „xxxx“ stands for a valid PLMN-ID and gNodeB-ID).

In the figure below the SgNB sends a X2AP SgNB Modification Required message that carries an embedded NR RRC cG-Config message. This cG-Config message is transparently forwarded by the MeNB to the UE. When arriving at the UE it activates CSI reference signal measurements on the 5G frequency including the serving 5G cell as well as its neighbors. It shall be noticed that here the concept of the Special Cell (SpCell) applies as it was defined for LTE-A CoMP scenarios. 

Instead of the X2AP SgNB Modification Required message the information for activating the CSI reference signal measurements can alternatively transported using the X2AP SgNB Addition Request Acknowledge or X2AP SgNB Change Required message.

In step 2 the UE sends a NR RRC (3GPP 38.331) Measurement Report that indicates a stronger 5G cell (the neighbor cell with PCI = 11) was measured. It might be a vendor-specific implementation to send this NR RRC Measurement Report simultaneously over uplink channels of the LTE radio link where it is carried by the LTE RRC Uplink Information Transfer MRDC (Multi-RAT Dual Connectivity) as well as over NR radio links where it is forwarded by the SgNB to the MeNB embedded in a X2AP RRC Transfer message.

Indeed, it is the SgNB that makes the handover decision, but since the MeNB is in charge of the signaling connection the handover command (here: another NR RRC cG-Config message that orders to switch the 5G radio link to the cell with PCI = 11) must be transmitted to the MeNB by using another X2AP SgNB Modification Required message.

After the UE received the NR CC cG-Config message sent by the SgNB the HO is executed and the 5G cell with PCI = 11 becomes the new primary secondary cell of the EN-DC connection.


Figure: Measurement Configuration, Reporting and Execution for intra-SgNB  Handover 

Wednesday 4 December 2019

Challenges of 5G Inter-Node Handovers

In all mobile communication networks handovers are the most complex signaling procedures, because multiple network elements (or network functions) are involved. Thus, it is logical that dual connectivity with two different base stations contributing to the radio connection simultaneously are even more complicated. And in EN-DC these two base stations are often covering different footprints using different carrier frequencies.This leads to a situation where we have more options for performing a handover in detail compared with plain LTE handover scenarios before.

The two signaling scenarios presented below illustrate in which different ways a change of the LTE master eNodeB can be performed during an ongoing EN-DC radio connection by using the X2 interface. In a very similar way it is also possible to perform S1 handover from old to new MeNB.

The pros and cons of these options have been discussed already by Martin Sauter in his Wireless Moves blog.

Inter-MeNB Handover without 5G Inter-Site Anchor

Figure 1 shows the easiest way of handing over the signaling connection from one MeNB to another one. Here it is up to the new MeNB to decide if and how the 5G part of the radio connection is continued.

Figure 1: X2 Handoverof EN-DC connection without 5G inter-site anchor

The handover is triggered when the UE sends a RRC Measurement Report (step 1) indicating that a stronger 4G cell than the currently used primary cell was measured. From its neighbor list the current MeNB detects that this better cell belongs to a neighbor eNB.

To provide both, the the Master Cell Group (MCG) and Secondary Cell Group (SCG) parameters to this neighbor eNB the old MeNB queries the SCG configuration parameters from the old SgNB by performing the X2AP SgNB Modification procedure (step 2+3).

Then it sends the X2AP Handover Request message to the target MeNB (step 4) including all information necessary to continue the 5G radio link in case the target MeNB decides to go for this option.

However, what comes back from the target MeNB is a plain LTE handover command (LTE RRC Connection Reconfiguration message [step 6]) embedded in the X2AP Handover Request Acknowledge message (step 5).

Due to this the old MeNB releases all 5G resources and the UE context in the SgNB (steps 7 + 10).

After the UE  successfully connected via radio interface with the target cell in the new MeNB the S1AP Path Switch procedure is executed to re-route the GTP/IP-Tunnels on S1-U (step 8) and releases the X2 UE context in the old MeNB (step 9)

The new MeNB then waits for a new inter-RAT measurement event B1 (step 11) before starting a new SgNB addition procedure (step 12).  Once the SgNB addition is successfully completed including all necessary reconfigurations/modifications on RRC and S1 the payload transmission over 5G resources is continued.

Inter-MeNB Handover with 5G Inter-Site Anchor

Now figure 2 shows what happens when the new MeNB decides to keep the existing UE context in the SgNB while the RRC measurement results and parameters are identical with what was presented above. 
Figure 2: X2 Handoverof EN-DC connection with 5G inter-site anchor

The difference in the call flow starts at step 5 when the new MeNB after receiving the X2AP Handover Request (step 4) starts the X2AP SgNB Addition procedure towards the SgNB (old = new!). The SgNB-UE-X2AP-ID earlier requested in step 2+3 acts as the reference number for the existing context that is going to be continued.

After adding the SgNB UE context successfully the new MeNB sends the X2AP Handover Request Acknowledge message including an UE Context Kept = "true" flag and the Handover Command (step 8).

After the UE successfully connected to the target cell of the new MeNB the S1AP Path Switch procedure is performed and the temporary X2 UE context between old and new MeNB is released (step 10).

The big advantage of handling the handover in this way: The duration of the interruption of the payload transmission over 5G radio resources is minimalized and subscriber experience is significantly better compared to the scenario in figure 1.

Friday 22 November 2019

5G Call Drops in EN-DC: A Thread for Service Quality?

As explained in the post about EN-DC setup the addition of 5G NR radio resources to an ongoing LTE connection provides additional bandwidth for user plane data transmission. And it seems to be fair to say that at least in social media today 5G speed test results, especially throughput measurements, are treated as the benchmark for EN-DC service performance. Hence, it is also logical that a loss of the physical 5G radio link (5G drop) could have a serious impact on user experience.

I write "could", because as a matter of fact many 5G drops will not be recognized by subscribers using non-realtime services including HTTP streaming.

Due to the dual connectivity of LTE Master eNodeB (MeNB) and Secondary gNodeB (SgNB) the signaling trigger points indicating a 5G drop are also a bit more complex compared to what we know from LTE. Indeed, both network nodes are able to release 5G radio resources abnormally using three different X2AP message flow scenarios as shown in figure 1.

Figure 1: Three Basic Signaling Flows for Abnormal Release of 5G Radio Resources

Which of these individual message flows will be found in the trace data depends on which of the two base stations is the first one that detects a problem on the 5G radio link.

A particular case that is seen quite often in live networks is illustrated in figure 2.

Figure 2: 5G Drop due to SGC Failure in UE

Here the trigger is a LTE RRC SCG Failure Information NR message sent by the UE to the MeNB. Thus, the MeNB requests the release of 5G radio resources, which is acknowledged and executed by the SgNB.

In addition (not show in the figures) also the GTP/IP-Tunnel for user plane transport between S-GW and gNB is released by the MeNB after successful completion of the X2AP SgNB Release procedure.

For the UE the 5G drop is not as serious as a drop of the LTE radio connection would be. It is just a fallback on plain LTE, so to say. And after the switching the GTP/IP-Tunnel back to a downlink endpoint at the eNB 4G payload transmission continues.

The longer the overall duration of the radio connection the higher is the risk that the 5G radio resources are lost during an EN-DC call. One of my favorite cases is a subscriber with a radio connection that last a bit more than two and a half hours - see figure 3.

Figure 3: Location Session Record of a Single Subscriber indicating a total number 340 SgNB Drops over 2:33 Hours

Thanks to the smart algorithms of NETSCOUT's TrueCall geolocation engine there is high confidence that she or he sits in an indoor environment, but is served by an outdoor 5G cell. Thus, the penetration loss of the 5G signal is significant. Due to the higher frequency the path loss has also higher impact on the 5G than on the 4G radio signal. This seems to be the main reason why the 5G radio link drops as often as 340 times, which leads to an overall 5G (SgNB) Drop Rate of 83% for this connection.

However, the impact on the subscriber experience might not be a serious one as a different KPI, the 5G EN-DC Duration Rate indicates. According to the Duration Rate 99.99% of all the time 5G radio resources have been available for the subscriber. This is possible, because as also shown in figure 2 within a relatively short time new 5G radio resources are allocated again to this connection. Even if the subscriber is watching e.g. a Netflix video the buffering of already downloaded data on the end user device should be sufficient to conceal the short interruption of the data transfer over 5G resources.

With rising amount of EN-DC traffic it might be rather problematic for the network to handle the additional signaling load originating from the frequent 5G additions and releases. In extreme cases this may even lead to congestion due to CPU overload in RAN nodes or virtual network functions.

For realtime services like Voice over New Radio (VoNR) the entire situation changes. Here even short interruptions of the user plane radio transmission can be perceived by subscribers so that the above discussed 5G Duration Rate KPI will become insufficient to estimate the service quality. Hence, this will drive the demand for a fully integrated view of 5G RAN and Core KPIs covering both, signaling and application quality. 

Monday 7 October 2019

Exploiting Possible 5G Vulnerabilities


The standards can try their best to ensure that the next generation of protocols is more secure than the previous one but there is always some way in which the protocols can be exploited. This is where researchers play an important role in finding such vulnerabilities before they can be exploited by hackers. Frankly I am quite sure that only a handful of these vulnerabilities are found and hackers always have something that may never be found.

In the recent HITBSecConf or the Hack In The Box Security Conference Altaf Shaik presented "4G to 5G: New Attacks". He along with Ravishankar Borgaonkar has been working to find out issues with security in cellular networks. In fact in the GSMA Mobile Security Hall of Fame, they both appear twice, individually.

From the talk narrative:

5G raises the security bar a level above 4G. Although IMSI exposure is prevented in 5G, we found new vulnerabilities to attack devices and subscribers. In this talk we expose a set of vulnerabilities in the 5G/4G protocols that are found in network operators equipment and also consumer devices such as phones, routers, latest IoT sensors, and even car modems. Our vulnerabilities affect several commercial applications and use cases that are active in 4G networks and are expected to take off in 5G networks. We developed automated tools to exploit the exposed cellular information and share some of our research traces and data sets to the community. We demonstrate a new class of hijacking, bidding down and battery draining attacks using low cost hardware and software tools. We did a rigorous testing worldwide to estimate the number of affected base stations and are surprised by the results. Finally our interactions with various vendors and standard bodies and easy fixes to prevent our attacks are discussed.

Slides and Video is embedded below






Slides and Whitepaper can be downloaded from here.

Further Reading:

Tuesday 24 September 2019

When does your 5G NSA Device Show 5G Icon?


After I wrote about the 5G Icon Display back in February, I received lots of other useful and related materials, mostly from 3GPP standards delegates. Based on this updated information, I created a presentation and video called 'The 5G Icon Story'. Only recently did I realize that I didn't add it to the blog. So here it is.

And for people who are impatient and directly want to jump to the main point, it's UpperLayerIndication in SIB 2 as can be seen above.

The slides and video is embedded below.





Related Posts:



Thursday 12 September 2019

How the Addition of 5G Radio Resources Increases the Complexity of LTE Signaling Procedures


While everybody is excited about the growing number of 5G deployments and speed test results it is easy to forget that a highly reliable LTE core and radio access network is the prerequisite for 5G non-standalone (NSA) data transmission.

Indeed, the 5G radio resources are just added to the ongoing LTE connection to provide higher bandwidth that enables in turn higher throughput. In other words: the current 5G deployments are designed for and limited to the needs of enhanced Mobile Broadband (eMBB) traffic.

To boost the user experience a 4G and a 5G base station cooperate and bundle there joint resources in one radio connection. The whole scenario is known as E-UTRA-NR Dual Connectivity (EN-DC) and as a matter of fact this dual connectivity increases the complexity of the RAN signaling tremendously.

The figure below shows the two base stations involved in the radio connection. On the left side is the Master eNodeB (MeNB) that controls the entire signaling connection. On the right side sits the en-gNB, also called Secondary gNodeB (SgNB). The inconsistency of acronyms originates from 3GPP specs. 3GPP 37.340 "E-UTRA and NR Multi-connectivity" can be seen as an umbrella document that originally coined "MeNB" and "SgNB". However, when standarizing more details these acronyms have been replaced with Master Node (MN) and Secondary Node (SN) and the latter is named "en-gNB" when used in EN-DC scenarios. (Sure this spec has a lot more terms to offer an is a must-read for every acroynm enthusiast.)

However, these naming conventions defined in 3GPP 37.340 have not made it into the protocol specs, especially not into 3GPP 36.423 "X2 Application Part" that names its message set for enabling EN-DC consequently "SgNB ...." - as also shown in the figure.

By the way the SgNB should also not be imagined as a single network element. On the 5G side often a virtual RAN architecture is already deployed. In such a VRAN a gNB central unit (CU) controls several gNB distributed units (DUs) and multiple remote radio heads (RRHs) including the 5G antennas can be connected to each DU.



5G Radio Resource Addition in EN-DC Mode

Before 5G radio resources can be added to the connection a LTE RRC connection and at least a default bearer for the user plane including its GTP/IP-Tunnel between S-GW and eNB must have been successfully established.

The trigger for adding 5G resources to this call is mostly an inter-RAT measurement event B1 (not shown in the figure). However, also blind addition of a 5G cells have been observed in some cases where the 5G cell coverage is expected to overlap exactly the footprint of the LTE master cell. 

All in all, there can be a 1:1 mappig between 4G and 5G cells when antennas are mounted very close to each other and pointing into the same direction. However, it is also possible that several 5G small cells (especially when using FR2 frequency bands) are deployed to cover the footprint of a 4G macro cell. 

The end-to-end signaling that adds 5G resources to the connection starts with the X2AP SgNB Addition Request message (1). It contains information about the active E-RABs of the connection, UE NR capabilities and often the singal strenght of the 5G cell as measured before is included as well. The message triggers allocation of 5G radio resources in the SgNB.

Similar to a X2 handover procedure the X2AP SgNB Addition Request Acknowledge message (2) is used to transport a NR RRC CG-Config message (3) back to the MeNB where it is "translated" into NR RRC Connection Reconfiguration and NR RRC Radio Bearer Config messages that are sent to the UE enclosed in a LTE RRC Connection Reconfiguration message. In these messages beside the Cell Group ID the 5G PCI and the absolute SSB frequency (a synonym for NR ARFCN) are found. Both, 5G PCI and SSB frequency in combination represent the identity of a 5G cell "visible" for the UE on the physical 5G radio interface. 

To keep the figure more simple I have spared the "translation" process in MeNB and show instead as next step the combined LTE/NR RRC Connection Reconfiguration Complete (4) that is send by the UE back to the MeNB to confim activation of the 5G radio link. 

After this the UE and the SgNB are ready to the 5G resources for radio transmission. However, one important component is still missing: a new GTP/IP-Tunnel for transporting the payload from the core network's serving gateway (S-GW) to the SgNB. 

The gNB downlink transport layer address (gNB DL TLA) and its appropriate GTP Tunnel Endpoint Identifier (TEID) have been already to the MeNB in step (2). Indeed, there are some more TLAs and TEIDs found in this X2AP message, especially for data forwarding across the X2 user plane interface (not shown in figure).

The MeNB forwards the gNB DL TLA/TEID to the MME (6) where it is forwarded to the S-GW using GTP-C signaling in case the two core network elements are connected over S11 reference point. The uplink TLA/TEID on the S-GW side remain the same as assigned before during establishement of the E-RAB (not shown in figure). So the new tunnel is now ready to be used (7) and transmission of payload packet starts immediately. 

In step (8) the MME confirms the successful tunnel establishment to the MeNB.

To total duration of the entire procedure from step (1) to (8) sums up to slightly more than 100 ms under lab conditions and typically around 300 ms in the live network. 

This delay does not have a direct impact on user plane latency in the initial 5G setup phase. However, the subscriber experience might be different when it comes to inter-MeNB handover, because there is no direct handover between 5G neighbor cells. 

Changing the MeNB due to subscriber mobility means: release all 5G resources on the source (M)eNB side, perform intra-LTE handover to the target (M)eNB and add new 5G resources after handover is successfully completed. 

Monday 27 May 2019

Bandwidth Part (BWP) in 5G New Radio (NR)


I made a short tutorial explaining the concept of Bandwidth Part in 5G a while back. Slides and video embedded below.







Further Reading:

Sunday 19 May 2019

VoLTE Hacking


The 10th Annual HITB Security Conference took place from the 6th till the 10th of May 2019 in The Netherlands. The theme for the conference this year is 'The Hacks of Future Past'. One of the presentations was on the topic 'VoLTE Phreaking' by Ralph Moonen, Technical Director at Secura.

The talk covered variety of topics:

  • A little history of telephony hacking (in NL/EU)
  • The landscape now
  • Intercepting communications in 2019
  • Vulnerabilities discovered: some new, some old
  • An app to monitor traffic on a phone

The talk provides details on how VoLTE can potentially be hacked. In a lot of instances it is some or the other misconfigurations that makes VoLTE less secure. One of the slides that caught my attention was the differences in VoLTE signaling from different operators (probably due to different vendors) as shown above.

Anyway, I am not going into more details here. The presentation is available here.


The thread in the Tweet above also provided some good references on VoLTE hacking. They are as follows:



Related Posts:


Sunday 17 February 2019

Displaying 5G Network Status Icon on Smartphones and Other Devices

A more updated presentation & video on this topic is available on 3G4G '5G Training' page here.
Who thought displaying of network status icon on 5G devices would be so much fun. Typically the network icons are more of:
2G - Gsm, G, G+, E
3G - 3G, H, H+
4G - 4G, 4G+

Back in 2017, Samsung devices started displaying 4G+ icon. Samsung told mybroadband:

that by default its devices require a network to support Category 6 LTE, and for the total combined bandwidth to exceed 20MHz, before they will display the “4G+” icon.

Networks in South Africa frequently don’t have over 20MHz of aggregated bandwidth available, though.

As a result, one network asked Samsung to reduce the combined bandwidth requirement for the 4G+ icon to display to 15MHz, which Samsung approved.

“Samsung’s global policy regarding the display of the LTE/LTE-A/4G/4G+ network icon is that the network icon display is operator-configurable upon official request and Samsung approval,” it said.

The reason this is interesting is because LTE is really 3.9G but generally called 4G. LTE-A is supposed to be 4G because in theory it meets IMT-Advanced criteria. Then we have LTE-Advanced Pro, which is known as 4.5G. While in majority of the operators display 4.5G as 4G or 4G+, couple of operators has decided to become a bit innovative.

AT&T started by updating the network icons of some of their devices to 5GE, which is their way of saying 4.5G. E stands for Evolution. Or as some people joked, it stands for economy (or value) version, as opposed to premium version.


Brazilian operator Claro, decided to use the 4.5G icon but the 5 is much larger font compared to 4 (see the pic above). Some people call this as dishonest attempt by them.

I see a few people asking how can devices decide if they are on 4G or 4.5G. There is no standard procedure for this and is UE specific. One way is to look at RRC messages. If the system information messages contain optional IE's for 3GPP Release-13, then the network supports LTE-A Pro and if the device supports the features for LTE-A Pro, it can display 4.5G or 5GE, etc. Another approach is the optional IEs present in NAS Attach Accept message. As this comes slightly later in the registration process, the device displays 4G first and once the registration is complete, 4.5G. Note there is no requirement from standards point of  view about displaying of the network status indication icon up to 4G/4.5G.

To avoid such confusion in 5G, 3GPP submitted the first Liaison statement S2-175303. In this, 3GPP said:

With this number of System and Radio access options available, one or more new status icons are expected to appear on the User Interface of future (mobile) devices. A user should expect consistency across devices and networks as to what icons actually mean (i.e. what services might be expected when an icon is displayed).

While 3GPP specifications are not expected to define or discuss Service or RAT indicators in the User Interface themselves, 3GPP should provide the necessary tools in EPS and 5GS to enable them. It is therefore necessary to understand the conditions required for displaying these icons and with which granularity so we can identify what information ought to be available in/made available to the device.

SA2 understands that Status Icons related to 5G might be displayed for example on a UE display taking into account all or some combinations of these items (other items may exist):
- Access Restriction Data in subscription (with the potential exception of emergency access); 
- UE CN registration (i.e. is UE EPC- and/or 5GC-registered?);
- UE capabilities; 
- Network capabilities; 
- UE is camping on a cell of NG-RAN supporting NR only, E-UTRA only or, the ability to activate dual connectivity with another RAT (NR or E-UTRA);
- UE is camping on a cell of E-UTRAN (connected to EPC) with the ability to activate dual connectivity with NR as secondary cell;
- UE is in connected mode using NR, E-UTRA (in 5GS) or dual connectivity between E-UTRA and NR.

Given the above, SA2 would like to kindly ask for any feedback from GSMA FNW and NGMN on requirements and granularity for Service indicators and/or RAT indicators related to 5G.

GSMA responded in R2-1713952. 6 cases have been identified (see the first picture on top) :

The configurations consist of the following states and are as described in Table 1:

  1. EPS NR NSA (EN-DC) capable UE attached to EPC and currently in IDLE state under or in RRC_connected state connected to E-UTRAN cell not supporting LTE-NR dual connectivity 
  2. EPS NR NSA (EN-DC) capable UE attached to EPC and currently in IDLE state under or in RRC_Connected state connected to AND active on LTE for uplink and downlink on only E-UTRAN cell supporting LTE-NR dual connectivity and has not detected NR coverage (i.e. UE is not under NR coverage and/or not configured to make NR measurements)
  3. EPS NR NSA (EN-DC) capable UE attached to EPC and currently in RRC_Connected state connected to E-UTRAN cell (supporting dual connectivity) and active on LTE for uplink and downlink only and has detected NR coverage (i.e. UE is under NR coverage and has been configured to make NR measurements) 
  4. EPS NR NSA (EN-DC) capable UE attached to EPC and currently in IDLE state under E-UTRAN cell supporting LTE-NR dual connectivity and has detected NR coverage (i.e. UE is under NR coverage and has been configured to make NR measurements)
  5. EPS NR NSA (EN-DC) capable UE attached to EPC and currently in RRC_Connected state connected to E-UTRAN cell (supporting dual connectivity) and active on LTE and NR for uplink and/or downlink
  6. 5GS capable UE attached to 5GC and currently in IDLE state under or in RRC_Connected state connected to NG-RAN (eLTE (option 5 or 7) or NR (option 2 or 4) cell)

As there is no consensus on a single preferred configuration, it is desirable to make the display of 5G status icon in the UE configurable such that the display of 5G status icon can be made depending on operator preference. 

This proposal by GSMA was noted by 3GPP in R2-1803949.

RAN WG2 would like to inform GSMA and SA2 that, according to GSMA and SA2 recommendations (LSs R2-1713952 and S2-175270, respectively), RAN WG2 introduced 1 bit indication per PLMN called “upperLayerIndication” within LTE SIB 2. 

This bit enables the realization of the configurations based on UE states as per recommendation from GSMA (e.g. RRC_IDLE UE as for State 2 in LS R2-1713952 from GSMA)”. 

For idle mode UEs this is the only mechanism agreed. 

Actions: RAN WG2 would like to ask GSMA and SA2 to take the information above into account. 

Hopefully there will be less confusion when 5G is rolled out about the status icons. In the meantime we might see some more 4.5G icon innovations.

Friday 14 September 2018

End-to-end Network Slicing in 5G

I recently realised that I have never written a post just on Network slicing. So here is one on the topic. So the first question asked is, why do we even need Network Slicing? Alan Carlton from Interdigital wrote a good article on this topic. Below is what I think is interesting:

Network slicing is a specific form of virtualization that allows multiple logical networks to run on top of a shared physical network infrastructure. The key benefit of the network slicing concept is that it provides an end-to-end virtual network encompassing not just networking but compute and storage functions too. The objective is to allow a physical mobile network operator to partition its network resources to allow for very different users, so-called tenants, to multiplex over a single physical infrastructure. The most commonly cited example in 5G discussions is sharing of a given physical network to simultaneously run Internet of Things (IoT), Mobile Broadband (MBB), and very low-latency (e.g. vehicular communications) applications. These applications obviously have very different transmission characteristics. For example, IoT will typically have a very large number of devices, but each device may have very low throughput. MBB has nearly the opposite properties since it will have a much smaller number of devices, but each one will be transmitting or receiving very high bandwidth content. The intent of network slicing is to be able to partition the physical network at an end-to-end level to allow optimum grouping of traffic, isolation from other tenants, and configuring of resources at a macro level.

Source: ITU presentation, see below

The key differentiator of the network slicing approach is that it provides a holistic end-to-end virtual network for a given tenant. No existing QoS-based solution can offer anything like this. For example, DiffServ, which is the most widely deployed QoS solution, can discriminate VoIP traffic from other types of traffic such as HD video and web browsing. However, DiffServ cannot discriminate and differentially treat the same type of traffic (e.g. VoIP traffic) coming from different tenants.

Also, DiffServ does not have the ability to perform traffic isolation at all. For example, IoT traffic from a health monitoring network (e.g. connecting hospitals and outpatients) typically have strict privacy and security requirements including where the data can be stored and who can access it. This cannot be accomplished by DiffServ as it does not have any features dealing with the compute and storage aspects of the network. All these identified shortfalls of DiffServ will be handled by the features being developed for network slicing.

I came across this presentation by Peter Ashwood-Smith from Huawei Technologies who presented '5G End to-end network slicing Demo' at ITU-T Focus Group IMT-2020 Workshop and Demo Day on 7 December 2016. Its a great presentation, I wish a video of this was available as well. Anyway, the presentation is embedded below and the PPT can be downloaded from here.



The European Telecommunications Standards Institute (ETSI) has established a new Industry Specification Group (ISG) on Zero touch network and Service Management (ZSM) that is working to produce a set of technical specifications on fully automated network and service management with, ideally, zero human intervention. ZSM is targeted for 5G, particularly in network slice deployment. NTT Technical review article on this is available here.

Finally, here is a presentation by Sridhar Bhaskaran of Cellular Insights blog on this topic. Unfortunately, not available for download.


Related Posts:

Monday 25 June 2018

Free Apps for Field Testing - Part 2

The last time I wrote about the free apps for field testing, many people came back and suggested additional apps that are much more commonly used. In fact we got the following comment when 3G4G re-posted this

As I have used both these apps frequently, here is a small summary on them.

Network Signal Guru: This is surprisingly very popular and is quite useful. The only issue is that you need to have a rooted phone with Qualcomm chipset. I know many testers have their favourite phones and quite a few testers buy the latest phones, root them and start testing using NSG (Network Signal Guru).

I prefer using Motorola Moto Gx series phones. They are cheap, not too difficult to root (YouTube have quite a few tutorials and Google search works too) and I find that their receivers are better than others. Have detected cells that other phones cant and have even camped and speed tested on them too.

So what can NSG do?

It can provide lots of useful information on the physical layer, cell configurations, neighbor cell lists, MIMO, etc.
You can even RAT lock to LTE / WCDMA / GSM and band lock to use a specific band. It can be very useful during surveys when you want to check if you can see particular frequency anywhere in an area. You can also see Codecs, RACH information, Data information, etc.

Finally, one of the best things I find is the signalling information. Some of the details are only available for purchased option, its nevertheless very useful. Just in case you are wondering how much does it cost, its roughly £50 per month license in UK.


Cell Mapper: I find this much more helpful as it can be used without rooting. CellMapper is a crowd-sourced cellular tower and coverage mapping service. Its simple and only used for basic testing but nevertheless very useful. To give you an idea, the other day I was camped on a cell with very good signal quality but very poor data rates and there weren't many people so congestion didn't seem like a factor. On investigation I found out that I was camped on 800MHz band that has limited bandwidth per operator and there was no CA.

Cell mapper, as you can see provides information about the cell you are camped on, the cell tower location, what other sectors and frequencies are there, etc.


Do you have a favorite testing app that I missed? Let me know in comments.