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

Tuesday, 12 October 2021

Friday, 5 March 2021

How to Identify Network Slices in NG RAN

In my last post I described how NG RAN resources can be divided into network slices. 

Now I would like to show how these network slices and the traffic they carry can be identified. 

The key to this is a parameter from the NG Application Protocol (NGAP) called the Single Network Slice Selection Assistance Information (S-NSSAI). When configuring virtual network functions in NG RAN there are lists of S-NSSAI exchanged, e.g. between gNB-CU CP and AMF during NGAP Setup procedure, to negotiate which network slices have to be supported in general. 

When it comes to connection establishment starting with NGAP Initial Context Setup for each PDU session that is established its individual S-NSSAI is signaled. 

The S-NSSAI - as show in the figure below - consists of two parameters, the Slice/Service Type (SST - 8 bit) and the optional Slice Differentiator (SD - 24 bit). The exact format and numbering ranges are defined in 3GPP 23.003.

3GPP 23.501 defines a set of default values for SST as listed in the following table:

Slice/Service type

SST value

Characteristics

eMBB

 

1

Slice suitable for the handling of 5G enhanced Mobile Broadband.

URLLC

2

Slice suitable for the handling of ultra- reliable low latency communications.

MIoT

3

Slice suitable for the handling of massive IoT.

V2X

4

Slice suitable for the handling of V2X services.

So when looking back at the figure it emerges that for each subscriber represented by an IMSI the SST allows to identify which services are running. 

On the other hand allows to see if in which virtual network the subscriber is active. In my example I have defined that the resources are shared among a Public MNO that I consider the owner of the network hardware and two different private (campus) networks. While IMSI 1 and IMSI 2 are not allowed to use any other network slice the IMSI 3 is allowed to "roam" betweent the public slice and the two private network slices. This explains why a slice-specific authentication functionality as defined in Rel. 16 is necessary. 

Related Posts:

Friday, 15 January 2021

UE Radio Capability Signaling Optimization (RACS) in Rel. 16

The data volume of UE Radio Capability Information defined in 3GPP 38.306 is already high and will further increase starting with Rel. 16 due to additional supported bands and other features.

Due to this 3GPP has standardized in Release 16 what is called UE Radio Capability Signaling Optimization (RACS) for both, E-UTRAN/EPS and NG RAN/NGC networks. 

Release 16 RACS does not apply to NB-IoT.

The first key element of this feature set is the introduction of a new UE Radio Capability ID that is structured as defined in 3GPP 23.003 and shown in figure 1 below:

UE Radio Capability ID
Figure 1: UE Radio Capability ID according to 3GPP 23.003

The components of this new ID are:

  •    TF - Type Field (TF): identifies the type of UE radio capability ID.
            Type = 0 -> manufacturer-assigned UE radio capability ID
            Type = 1 -> network-assigned UE radio capability ID

  •  The Version ID configured by the UE Capability Management Function (UCMF) that is part of the EPS/5GC. The Version ID value makes it possible to detect whether a UE Radio Capability ID is current or outdated.

·      The Radio Configuration Identifier (RCI) identifies the UE radio configuration.

The PLMN-assigned UE Radio Capability ID is assigned to the UE using the Non-Access Stratum UE Configuration Update Command or Registration Accept message (figure 2).

Figure 2: PLMN-assigned UE Radio Capability Update according to 3GPP 23.743

The new UCMF (UE radio Capability Management Function) stores All UE Radio Capability ID mappings in a PLMN and is responsible for assigning every PLMN-assigned UE Radio Capability ID.

Due to introduction of the UMCM in the core networks the new Nucmf service-based interface is defined for the 5GC and new S17 reference point is defined for the EPS as shown in figure 3.

Figure 3: Network Architecture with UCMF according to 3GPP 21.916

Each UE Radio Capability ID stored in the UCMF can be associated to one or both UE radio capabilities formats specified in 3GPP TS 36.331 [LTE RRC] and 3GPP TS 38.331 [NR RRC]. The AMF must only be able ot handle the NR RRC format while the MME uses the LTE RRC format. Which format is required by the UCMF is configurable.

If at any time the AMF/MME has neither a valid UE Radio Capability ID nor any stored UE radio capabilities for the UE, the AMF/MME may trigger the RAN to provide the UE Radio Capability information and subsequently request the UCMF to allocate a UE Radio Capability ID.

In NG RAN the UE Capability Request can be requested by the AMF as a flag in any NGAP Downlink NAS Transport message or by sending a NGAP UE Radio Capability Check Request (for checking compatibility of IMS voice capabilities). This triggers a NR RRC UE Capability Transfer procedure and subsequently NGAP UE Radio Capability Info Indication or NGAP UE Radio Capability Check Response (for IMS voice support parameters).

Using the NGAP UE Capability ID Mapping procedure the NG RAN node is able to request the most recent UE Capability ID mapping information from the core network functions AMF/UCMF. The same functionality is implemented in S1AP for signaling between eNB and MME/UCMF.

If the volume of the LTE/NR RRC UE Capability to be sent by the UE is larger than the maximum supported size of a PDCP SDU (specified in 3GPP 38.323) then the UE Capability Info can be transported in LTE/NR RRC using a chain of UL Dedicated Message Segment messages.

Figure 4: RRC UL Dedicated Segment Message transporting UE Radio Capability Information according to 3GPP 36.331 and 38.331

Each of these message will have a dedicated segment number and the last one has the rrc-MessageSegmentType =  “lastSegment”, which triggers reassembly of the orignal UE Capabability information in the receiving entity.

Thursday, 17 December 2020

Conditional Handover (Rel. 16) Explained

Although a couple of SON mobility robustness features have been introduced in LTE radio networks it is still a common problem in some network areas that a high number of handover failures leads to higher drop rates and large numbers of RRC Re-Establishments.

Often these problems occur due to quickly changing radio conditions in the handover preparation phase or after handover execution attempt. 

SON algorithms cannot cope with these dynamic changes of the environment, but improvement is possible if the UE itself is enabled to constantly monitor the radio quality during the handover procedure and finally select the best possible target cell from a list of candidate neighbors. This new feature defined in 3GPP Release 16 for both, NG RAN (5G SA NR) as well as E-UTRAN (LTE), is called "Conditional Handover". The figure below illustrates how it works.

(click on the picture to enlarge)

Step 1 is the RRC Measurement Report indicating that handover to a neighbor cell is required. However, this message contains a list of candidate neighbor cells.

In the figure it is assumed that each of these candidate cells is controlled by a different gNB. Hence, 3 XnAP Handover Preparation procedures are performed and each potential target gNB allocates radio resources for the UE and provides a handover command (NR RRC Reconfiguration message) that is sent back to the source gNB (step 2).

In step 3 the source gNB builds the conditional handover command, which is a NR RRC Reconfiguration message that contains a list of conditional reconfiguration options plus additional RRC measurement configurations that enable the UE to find out which of the possible target cells is the best fit. 

In step 4 the UE makes its handover decision and moves to the cell controlled by target gNB 1.

Here it sends in step 5 the NR RRC Reconfiguration Complete message. 

The target gNB 1 detects the handover completion based on the reception of the NR RRC Reconfiguration Complete message, performs NGAP Path Switch procedure (not shown in figure) and triggers the release of the UE context in source gNB on behalf of sending the XnAP UE Context Release message (step 6).

With this information the source gNB also detects the successful handover completion and orders in step 7 the release of the radio resources provided by target gNB 2 and 3 to which it sends the new XnAP Conditional Handover Cancel message.

As mentioned before the conditional handover is also possible for LTE radio connections. In this case X2AP is used instead of XnAP and LTE RRC instead of NR RRC.

The conditional handover can be performed for all kind of intra-eNB/gNB handover and X2/Xn handover. However, S1/N2 (NG-C) conditional handover is not allowed.


Tuesday, 17 November 2020

5G Non IP Data Delivery and Lightweight M2M (LwM2M) over NIDD

Earlier this year, MediaTek had announced that its MT2625 NB-IoT chip has been validated for LwM2M over NIDD on SoftBank Corp.’s cellular network across Japan. This achievement marks the first global commercial readiness of LwM2M over NIDD; a secure, ultra-efficient IoT communications technique that is being adopted by operators worldwide. The benefits of LwM2M over NIDD include security improvements, cost-efficient scalability and reduced power consumption.

LwM2M over NIDD is a combination of the communication technology "NIDD (Non-IP Data Delivery)" that does not use an IP address in LTE communication NB-IoT for IoT and the device management protocol "LwM2M (Lightweight M2M)" advocated by the Open Mobile Alliance. It's been a while since I wrote about Open Mobile Alliance on this blog. OMA SpecWorks is the successor brand to the Open Mobile Alliance. You can read all about it here.


OMA SpecWorks’ LightweightM2M is a device management protocol designed for sensor networks and the demands of a machine-to-machine (M2M) environment. With LwM2M, OMA  SpecWorks has responded to demand in the market for a common standard for managing lightweight and low power devices on a variety of networks necessary to realize the potential of IoT. The LwM2M protocol, designed for remote management of M2M devices and related service enablement, features a modern architectural design based on REST, defines an extensible resource and data model and builds on an efficient secure data transfer standard called the Constrained Application Protocol (CoAP). LwM2M has been specified by a group of industry experts at the OMA SpecWorks Device Management Working Group and is based on protocol and security standards from the IETF.

You can get all the LwM2M resources here and the basic specs of 'Lightweight M2M 1.1: Managing Non-IP Devices in Cellular IoT Networks' here.
The 5G Americas whitepaper 'Wireless Technology Evolution Towards 5G: 3GPP Release 13 to Release 15 and Beyond' details how Current Architecture for 3GPP Systems for IOT Service Provision and Connectivity to External Application Servers. It also talks about Rel-13 Cellular IoT EPS Optimizations which provide improved support of small data transfer over control plane and user plane. Control Plane CIoT EPS Optimization transports user data (measurements, ID, status, etc.) via MME by encapsulating user data in NAS PDUs and reduces the total number of control plane messages when handling a short data transaction. Control Plane CIoT EPS optimization, designed for small infrequent data packets, can also be used for larger data bursts depending in UE Radio capability.

User data transported using the Control Plane CIoT EPS Optimization, has special characteristics, as different mobility anchor and termination nodes.

Therefore, the Preferred Network Behavior signaling must include information on:
  • Whether Control Plane CIoT EPS optimization is supported
  • Whether User Plane CIoT EPS optimization is supported
  • Whether Control Plane CIoT EPS optimization is preferred or whether User Plane CIoT EPS optimization is preferred
These optimizations have enabled:
  • Non-IP Data Delivery (NIDD) for both: mobile originated and mobile terminated communications, by using SCEF (Service Capability Exposure Function) or SGi tunneling. However, it has to be taken into account that Non-IP PDUs may be lost and its sequence is not guaranteed
  • For IP data, the UE and MME may perform header compression based on Robust Header Compression (ROHC) framework
  • NB-IoT UE can attach but not activate any PDN connection
  • High latency communication handled by the buffering of downlink data (in the Serving GW or the MME)
  • SMS transfer
  • EPS Attach, TA Update and EPS Detach procedures for NB-IoT only UEs, with SMS service request
  • Procedures for connection suspend and resume are added
  • Support for transfer of user plane data without the need for using the Service Request procedure to establish Access Stratum context in the serving eNodeB and UE
When selecting an MME for a UE that is using the NB-IoT RAT, and/or for a UE that signals support for CIoT EPS Optimizations in RRC signaling, the eNodeB’s MME selection algorithm shall select an MME taking into account its Release 13 NAS signaling protocol.

Mpirical has a nice short video explaining 5G Non IP Data Delivery. It is embedded below.

IoT has not taken off as expected and prophesised for years. While the OMASpecWorks is doing some fantastic work by defining simplified approach for IoT deployment, its current member list doesn't have enough operators to drive the uptake required for its spec adoption. They would argue that it doesn't matter how many members there are as the NIDD approach is completely optional and over-the-top. Let's wait and see how it progresses.

Related Posts:

Wednesday, 7 October 2020

Understanding the Dual Active Protocol Stack (DAPS) Handover in 5G


In this video I explain the principles and signaling procedures related to the DAPS handover.

The DAPS handover is a new feature for URLLC services defined by 3GPP in Rel. 16.

Thursday, 3 September 2020

Two Types of SMS in 5G


GSMA recently published updated "5G Implementation Guidelines: SA Option 2". It explains the two types of SMS in 5G, the same way there were 2 types of SMS in LTE.

Within 5GC, SMS Function (SMSF) supports SMS over NAS (SMSoNAS) defined in 3GPP TS 23.501. Besides, SMSoIP can also be considered as IMS based SMS solution under 5G network. SMSoIP can be deployed simultaneously with voice service over IMS to provide both voice and short message service. It is recommended to use SMSoNAS solution if voice services over IMS is not supported or for a 5G data card/Machine Type Communications (MTC)/Non-IMS device without voice service. The network architecture of SMSoIP and SMSoNAS is shown in Figure.
Mpirical explains it in the video as embedded below:


You may also find "5G SMS is Very Real and Here to Stay" by William Dudley useful. It covers a lot of technical details and signalling. It's available here.

Related  posts:

Monday, 27 July 2020

Key Technology Aspects of 5G Security by Rohde & Schwarz


The 3G4G page contains a lot of useful papers and links to security here but we have also looked at evolution of security from 4G to 5G here. Rohde & Schwarz has a short 8-minute video in which wireless technology manager, Reiner Stuhlfauth, explains the key technology aspects ensuring 5G security. The video is embedded below.



Related Links:

Sunday, 19 July 2020

Mobile Initiated Connection Only (MICO) mode in 5G System


Mobile Initiated Connection Only (MICO) mode is designed for IoT devices that send small amounts of data and do not need to be paged. An example of this could be a smart bin that sends a message to the waste collection company saying it is 50% full, etc. This way the bin emptying lorry can plan to empty it in the next collection round. Here there is no reason to page the bin as there is no mobile terminated data that would be required.

MICO mode has to be negotiated between the device and AMF in 5GC. A device in MICO mode cannot be paged as it would not listen to paging to conserve battery power. This extreme power saving mode can ensure that the battery can last for very long time, ideally years thereby making this vision of billions of connected IoT devices a reality.


In an earlier post on RRC Inactive state, we looked at NAS states, along with RRC states. When the UE is in MICO mode, the AMF in 5GC will consider the UE to be unreachable when it is in CM-IDLE state. In addition, a periodic registration timer is also allocated to the MICO mode UEs. The UE has to confirm the MICO mode again during registration update.

The video and presentation are embedded below:





Related Posts:

Friday, 17 July 2020

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:

Monday, 6 July 2020

A Technical Introduction to 5G NR RRC Inactive State


I looked at the RRC Inactive state back in 2017, but the standards were not completely defined. In the meantime standards have evolved and commercial 5G networks are rolling out left, right and centre. I made a short technical introduction to the RRC_INACTIVE state, comparing it with the 4G states in RRC and NAS. I also looked at some basic signalling examples and there are lots of relevant references at the end. Video and slides embedded below.






Related Posts:

Saturday, 4 July 2020

An Introduction to Vehicle to Everything (V2X) and Cellular V2X (C-V2X)


We made an introductory tutorial explaining vehicle to everything. There are 2 different favours of V2X as shown in this tweet below


One is based on IEEE 802.11p (802.11bd in future). It is known by different names, DSRC, ITS-G5, etc. The other is the cellular V2X or C-V2X. It started as basic D2D but has evolved over the time. The slides and video are embedded below but this topic will need revisiting with more details.







Related Posts:

Tuesday, 30 June 2020

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:

Monday, 22 June 2020

Carrier Aggregation (CA) and Dual Connectivity (DC)


This topic keeps coming up every few months with either someone asking me for clarifications or someone asking us to make a video. While I don't think I will mange to get round to making a video sometime soon, there are some excellent resources available that should help a new starter. Here they are in an order I think works best



The first resource that I think also works best is this webinar / training from Award Solutions. It covers this topic well and the image at the top of the post is a god summary for someone who already understands the technology.


It may also help to understand that in the 5G NSA can have 4G carrier aggregation as well as 5G carrier aggregation in addition to dual connectivity.


If you saw the video earlier, you noticed that DC actually came as part of LTE in Release-12. We covered it in our Telecom Infrastructure blog here. NTT Docomo Technical journal had a detailed article on 'Carrier Aggregation Enhancement and Dual Connectivity Promising Higher Throughput and Capacity' that covered DC in a lot more technical detail, albeit from LTE point of view only. The article is available here. A WWRF whitepaper from the same era can also provide more details on LTE Small Cell Enhancement by Dual Connectivity. An archived copy of the paper is available here.

Another fantastic resource is this presentation by Rapeepat Ratasuk and Amitava Ghosh from Mobile Radio Research Lab, Nokia Bell Labs. The presentation is available here and details the MCG (Master Cell Group) Split Bearer and SCG (Secondary Cell Group) Split Bearer, etc. This article from Ericsson also provides more detail on this topic while ShareTechNote takes it one level even deeper with technical details and signalling here and here.

So hopefully this is a good detailed starting point on this topic, until we manage to make a simple video someday.

Friday, 12 June 2020

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:

Tuesday, 9 June 2020

5G Roaming with SEPP (Security Edge Protection Proxy)

SEPP (Security Edge Protection Proxy) is part of the roaming security architecture as shown in the figure above. Ericsson's article, "An overview of the 3GPP 5G security standard" describes the use of SEPP as follows:

The use of SBA has also pushed for protection at higher protocol layers (i.e. transport and application), in addition to protection of the communication between core network entities at the internet protocol (IP) layer (typically by IPsec). Therefore, the 5G core network functions support state-of-the-art security protocols like TLS 1.2 and 1.3 to protect the communication at the transport layer and the OAuth 2.0 framework at the application layer to ensure that only authorized network functions are granted access to a service offered by another function.

The improvement provided by 3GPP SA3 to the interconnect security (i.e. security between different operator networks) consists of three building blocks:

  • Firstly, a new network function called security edge protection proxy (SEPP) was introduced in the 5G architecture (as shown in figure 2). All signaling traffic across operator networks is expected to transit through these security proxies
  • Secondly, authentication between SEPPs is required. This enables effective filtering of traffic coming from the interconnect
  • Thirdly, a new application layer security solution on the N32 interface between the SEPPs was designed to provide protection of sensitive data attributes while still allowing mediation services throughout the interconnect

The main components of SBA security are authentication and transport protection between network functions using TLS, authorization framework using OAuth2, and improved interconnect security using a new security protocol designed by 3GPP.

NG.113 5G Roaming Guidelines v2.0 clarifies:

4.2 Inter PLMN (N32) Interface

The Inter-PLMN specification 3GPP TS 29.573 has been produced by 3GPP to specify the protocol definitions and message flows, and also the APIs for the procedures on the PLMN (Public Land Mobile Network) interconnection interface (i.e. N32)

As stated in 3GPP TS 29.573 the N32 interface is used between the SEPPs of a VPLMN and a HPLMN in roaming scenarios. Furthermore, 3GPP has specified N32 to be considered as two separate interfaces: N32-c and N32-f.

N32-c is the Control Plane interface between the SEPPs for performing the initial handshake and negotiating the parameters to be applied for the actual N32 message forwarding. See section 4.2.2 of 3GPP TS 29.573.

Once the initial HTTP/2 handshake is completed the N32-c connection is torn down. This connection is End-to-End between SEPPs and does not involve IPX to intercept the HTTP/2 connection; although the IPX may be involved for IP level routing.

N32-f is the Forwarding interface between the SEPPs, that is used for forwarding the communication between the Network Function (NF) service consumer and the NF service producer after applying the application level security protection. See section 4.2.3 of 3GPP TS 29.573.

N32-f can provide Application Level Security (ALS) as specified in 3GPP TS 33.501 between SEPPs, if negotiated using N32-c. ALS provides the following protection functionalities: -

  • Message protection of the information exchanged between NF service consumer and producer
  • Forwarding of the application layer protected message from a SEPP in one PLMN to another PLMN by way of using IPX providers on the path. The IPX providers on the path may involve the insertion of content modification instructions which the receiving SEPP applies after verifying the integrity of such modification instructions.

The HTTP/2 connection used on N32-f is long lived; and when a SEPP establishes a connection towards another PLMN via IPX, the HTTP/2 connection from a SEPP terminates at the next hop IPX.

N32-f makes use of the HTTP/2 connection management requirements specified in 3GPP TS 29.500. Confidentiality protection shall apply to all IE’s for the JOSE protected message forwarding procedure, such that hop-by-hop security between SEPP and the IPXs should be established using an IPSec or TLS VPN.

If an IPX is not in the path between SEPPs, then an IPSec of Transport Layer Security, TLS VPN will be established directly.

Note: N32-f shall use “http” connections generated by a SEPP, and not “https”

The SEPP will act as a non-transparent Proxy for the NF’s when service based interfaces are used across PLMNs, however inside IPX service providers, an HTTP proxy may also be used to modify information elements (IE’s) inside the HTTP/2 request and response messages.

Acting in a similar manner to the IPX Diameter Proxy used in EPC roaming, the HTTP/2 Proxy can be used for inspection of messages, and modification of parameters. 


The picture in the tweet above shows how SEPP will play a role in Local Break Out (LBO) roaming as well as Home Routed (HR) roaming.

Related Posts:

Friday, 29 May 2020

Visualisation of Intra-gNB Handover in an End-to-End Monitoring Tool


In my last blog post I described the message flow of an intra-gNB-DU handover.

Today I want show how such a handover can be visualized using a ladder diagram in an end-to-end passive monitoring tool. The tool shown in the figure below is the NETSCOUT nGenious Session Analyzer (nSA).

The data source is a cell trace feed according to 3GPP 32.421/32.423. Unfortunately F1AP and E1AP messages are missing in the trace so that we cannot distinguish if this is an intra- or inter-gNB DU handover.

(click to enlarge)

Nevertheless the tool offers the great advantage to find the handover procedure quickly within all the other messages of the trace. It also links the outgoing (source) and incoming (target) side in case that different feeds from different cells need to be combined.

For the NR RRC messages are send/received by the UE, but there is a good reason to show the icon "Cell" on top the ladder diagram. With this approach it is possible to spot immediately the changing cell location of the UE and NR RRC Reconfiguration procedure that is used to execute the handover. So the icon does not represent a cell, but an UE within a cell - and with a bit imagination you can recognize this in the icon graphic itself.

Selecting the handover message it is possible to open the Inline Decode tab and browse through the bits and bytes of NR RRC. As expected beside many other parameters the new UE Identity (new C-RNTI) to be used by the UE after arriving in the target cell is one of the most important information elements and confirms that this particular NR RRC Reconfiguration message is indeed the command for executing the intra-gNB handover.

Thursday, 14 May 2020

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:

Thursday, 7 May 2020

How the A6 Measurement Event triggers Secondary Cell Change in LTE Carrier Aggregation Calls


Last week I read in Martin Sauter's blog about the LTE RRC A6 measurement event.

Although I am quite interested in RRC measurements I have never seen the A6 event in action. Rather the eNB vendors have implemented carrier aggregation in a way that the UE provides its capabilities and according to the this the maximum possible numbers of component carriers is added to the connection. There is no RRC measurement report before adding secondary LTE cells to the connection. So what is the A6 event good for and is it used at all?

Surprisingly I needed only 2 attempts to find an example of using the A6 event in a live network configuration. It is used when more component carriers are available than the UE can simultaneously handle. E.g. if there are 4 or more cells with different carrier frequencies available in the same antenna sector the A6 event ensures after the initial CA configuration that the cells with the best radio conditions are selected as secondary cells.

Let's have a look at this scenario in detail. Figure 1 shows the report configuration for the A6 event. Keep the reportConfigId = 3 in mind.


Figure 1: Report Configuration for Event A6

The next step is the configuration of the Measurement ID as shown in figure 2. Here the reportConfigId is combined with a measObjectId that represents the carrier frequency of the potential SCell.

Figure 2: Measurement ID for Event A6
Now, if the event A6 is triggered in the UE a RRC Measurement Report with this measId = 3 is sent to the eNB as shown in Figure 3.

Figure 3: RRC Measurement Report for Event A6
There we see the RSRP and RSRQ of the primary cell (PCell) and of the currently serving secondary cells (SCells). By the way the servFreqId stands for the sCellIndex value that was linked to the physical cell ID (PCI) when this SCell was added in a previous RRC Connection Reconfiguration procedure. 

And as one can see the neighbor cell with PCI = 470 has significantly better RSRP and RSRQ to offer than both currently used SCell. 

Consequently the eNB decides to replace the SCell with sCellIndex value 1 with the better cell (PCI 470). This is again done with a RRC Connection Reconfiguration procedure as shown in figure 4. And this is the way how the A6 event is used.


Figure 4: Change of SCell
  

Tuesday, 28 April 2020

Comparing S1AP and NGAP UE Context Release


As an addition to my blog post about the 5G RAN Release procedure I would like to have an in-depth view at the details of NGAP UE Context Release Complete message.

Indeed, the S1AP (known from E-UTRAN) and the NGAP are very similar protocols and when reading the 3GPP specs it is obvious that many message names are identical and the procedures fulfill the same purpose when looking at call scenarios.

However, the difference is visible in the details as one can see when looking at the figure below.

While the S1AP UE Context Release Complete message does not contain any additional information we find in the NGAP UE Context Release Complete the identity of the last serving 5G cell, represented by the NR-CGI, the last visited Tracking Area Identity (TAI) and a list with the IDs of the PDU sessions (E-RABs) that have been terminated when the UE context was released.

This additional information in very valuable for network troubleshooting, since in LTE (S1AP) only the ID (ECGI) of the initial serving cell or a new serving cell ID at inter-node handover was signaled. And if you wanted to know how many E-RABs have been terminated with a S1AP UE Context Release procedure it was necessary to look back into the full sequence of call-related S1AP messages starting with the messages for Initial Context Setup.

All in all, with 5G NGAP trace analysis and the life of RAN engineers becomes easier. Thank you, 3GPP! 

Comparision of S1AP and NGAP UE Context Release Complete Messages