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:

• The 3G4G Blog: Everything you need to know about 5G Security
• 3G4G: Security in 2G, 3G, 4G & 5G Mobile Networks
• The 3G4G Blog: 5G Roaming with SEPP (Security Edge Protection Proxy)
• The 3G4G Blog: Evolution of Security from 4G to 5G

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:

Intermediate: Mobile Initiated Connection Only (MICO) from 3G4G

Related Posts:

• The 3G4G Blog: A Technical Introduction to 5G NR RRC Inactive State
• The 3G4G Blog: Anritsu Webinar on 'Evolution of 5G from 3GPP Rel-15 to Rel-17 and Testing Challenges'
• 3G4G: 3GPP 5G Specifications
• 3G4G: 5G (IMT-2020) Wireless

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

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

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

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

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

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

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

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

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

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

Related Posts:

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

Anritsu Webinar on 'Evolution of 5G from 3GPP Rel-15 to Rel-17 and Testing Challenges'

At the TSG#88e Plenary meetings that ended on 03 July 2020, Release 16 was completed with both the Stage 3 freeze and the ASN.1 and OpenAPI specification freeze being approved. The 3GPP Release-16 page has more details on timelines but they may shift. See at the bottom of this post.

Anritsu have uploaded a short presentation on their channel that I am embedding below. I have skipped the beginning part but of you feel like you want to listen, jump to the beginning.




Meanwhile in the recently concluded TSG#88e Plenary meetings, there is a discussion on some of the timelines for Release-17 and Rel-18 moving. This graph below is from SP-200606.

In another piece of 3GPP news, RAN Working Group 6 (WG6 or RAN6) – responsible for the GERAN and UTRAN radio and protocol work - was formally closed.  No new features but specs will be maintained as necessary, of course.

Finally, here is a short video interview by 3GPP in which Balazs Bertenyi looks back at the recent TSG RAN Plenary e-meeting. He talks about the challenges, about IMT-2020, Rel-16 being just on time & the prospects for Rel-17.

Release 16 - RAN progress from 3GPPlive on Vimeo.


Related Posts:

• 3G4G: 3GPP 5G Specifications
• 3G4G: 5G Health & Safety
• 3G4G: 5G (IMT-2020) Wireless
• The 3G4G Blog: A Technical Introduction to 5G NR RRC Inactive State
• The 3G4G Blog: An Introduction to Vehicle to Everything (V2X) and Cellular V2X (C-V2X)
• The 3G4G Blog: A Look into 5G Virtual/Open RAN - Part 6: Inter-gNB CU Handover involving Xn
• The 3G4G Blog: Carrier Aggregation (CA) and Dual Connectivity (DC)
• The 3G4G Blog: 5G Roaming with SEPP (Security Edge Protection Proxy)
• The 3G4G Blog: Embedded SIM (eSIM) and Integrated SIM (iSIM)

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.

Advanced: 5G NR RRC Inactive State from 3G4G

Related Posts:

• The 3G4G Blog: Comparison Layer 2 Measurements LTE vs. 5G NR
• The 3G4G Blog: A Look into 5G Virtual/Open RAN - Part 3: Connection Release and Suspend
• The 3G4G Blog: How LTE RRC (4G) and NR RRC (5G) Protocols are used in Parallel in EN-DC (5G NSA)
• The 3G4G Blog: EPS Fallback in 5G Standalone Deployments
• The 3G4G Blog: RRC states in 5G

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

We have a new section on 3G4G homepage - Vehicle to Everything (V2X) - https://t.co/enOdeIcLE5#3G4G5G #V2V #V2X #V2I #V2P #V2N #CAVs #ConnectedCars #AutonomousCars #3GPP #Specifications #Standards #Whitepapers #Webinars

— 3G4G (@3g4gUK) June 28, 2020

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.

Intermediate: Vehicle to Everything (V2X) Introduction from 3G4G

Related Posts:

• Connectivity Technology Blog: Introduction to Connected and Autonomous Vehicles (CAVs)
• 3G4G: Vehicle to Everything (V2X)
• The 3G4G Blog: 3GPP Sidelink and its proposed extensions
• The 3G4G Blog: 5G New Radio Standards and other Presentations

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

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

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

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

(click image to enlarge)

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

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

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

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

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

Related Posts:

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

Comparison Layer 2 Measurements LTE vs. 5G NR

Yesterday (2020-06-22) 3GPP uploaded the version 1.0 of TS 38.314 "Layer 2 Measurements" for 5G New Radio Rel. 16.

I was wondering about the difference compared to the same LTE standard defined in 3GPP TS 36.314.

The initial look at the table of contents shows significantly less measurements in the NR spec, but a new counter for the number of stored inactive UE contexts. This is due to the introduction of RRC Inactive state in NR RRC specified in 3GPP TS 38.331)

All other differences in the NR standard are related to chapter number 4.2.1.6 "Other measurements defined in TS 28.552".

Here one finds the references to Data Volume, Average Throughput Measurement per UE and DRB as well as PRB usage measurements.

Adding these additional measurements to the list we see in the table of contents it emerges that indeed the number of stored inactive UE contexts is the only major difference in comparison with the LTE standard. 

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.

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

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

The figure below shows the message flow:

(Click on the image to enlarge)

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

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

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

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

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

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

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

Related Posts:

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