A summary of 3GPP Release 16, 5G phase 2: Security and RAN

The saying goes that “satisfaction lies in the effort, not in the attainment”. But as we wrapped up Release 16, we can say that we were satisfied with both our efforts and attainments. Let us take you through this journey.
In our earlier blog post, we gave an overview of the 3GPP 5G security standard in Release 15, called 5G Phase 1. While Release 15, completed back in 2018, laid the foundations for 5G architecture and security, Release 16 was dedicated to additional use cases and therefore many features were added or enhanced. Non-Public Networks, Edge Computing, Positioning Services, Cellular Internet of Things (IoT), and Ultra-Reliable Low Latency Communications (URLLC) are just few examples. It’s no overstatement to say that Release 16 elevated the 5G system’s suitability and reliability for a wide range of industries including transportation, automated factories, and several others. The 5G system's role as an industry-grade communication fabric is even more clear.
We would love to talk at length about all the Release 16 features, but in this blog post we focus on security, specifically, the security of new features directly related to the Radio Access Network (RAN) part of the 5G system. RAN is the entry point to the network which makes RAN security extra important.
Let us take a look at the key points of four main features that have a major impact on RAN security:
(a) full rate User Plane integrity protection
(b) cellular IoT data security
(c) wireless backhaul security
(d) industrial IoT data redundancy.

Figure 1: New RAN security features in Rel-16.
Full rate User Plane integrity protection
Integrity protection is a security feature that allows a receiver to determine that the received messages were not tampered with by an attacker. While integrity protection has been available since 3G to the messages used for the management of resources called Control Plane messages, it was only in 5G Release 15 that the messages used for carrying user traffic called User Plane messages were enhanced with integrity protection as well.
Nevertheless, in Release 15, it was deemed necessary by the industry to allow a certain degree of flexibility for the cellular devices to support User Plane integrity protection either at a reduced data transfer rate of 64 Kbps (Kilobits Per Second), or with no rate limitation, i.e., full rate. What has happened since then, and deep in the work on Release 16 is that the industry has decided to drop the flexibility in favor of the full rate. From Release 16 onwards, support for full rate User Plane integrity protection is mandatory in cellular devices. It means that cellular devices must be able to handle integrity protection of User Plane messages at any possible data transfer rate.
Technically, it works like this. As shown in figure 2 below, the cellular device includes an information element called "Integrity protection maximum data rate" in Protocol Data Unit (PDU) Establishment/Modification Request messages. These messages belong to 5G Session Management (5GSM) messages which are handled by Session Management Function (SMF). They are tunneled inside a Non-Access Stratum (NAS) message, which belongs to 5G Mobility Management (5GMM) messages handled by Access and Mobility Management Function (AMF). AMF and SMF belong to 5G Core (5GC). The NAS messages are in turn tunneled inside Radio Resource Control (RRC) messages handled by RAN – in this case offering New Radio (NR).

Figure 2: Full rate User Plane integrity protection indication.
That information element is 3 octets long and contains indications of the maximum data rate for User Plane integrity protection for uplink and downlink that are supported by the User Equipment (UE).
Octet 1 | IE type |
Octet 2 | Uplink maximum data rate for user plane integrity protection |
Octet 3 |
Downlink maximum data rate for user plane integrity protection |
Octets 2 and 3 can have following values. Note that 0xFF is mandatory – and only – for NR connected to 5GC.
0x00 |
64 kbps. This value is only allowed for pre-Release 16 UEs. |
0x01 |
NULL. This value is only allowed for UEs that do not have proper user plane support. |
0xFF | Full data rate. This value is mandatory for Release 16 UEs supporting standalone deployment with NR connected to 5GC. |
Others | These values are forbidden to be used, and if used are treated as 0x00. |
Cellular IoT data security
Most people now know about the Internet of Things. Cellular IoT (CIoT) is simply those IoT devices that can connect to a cellular network. In the near future, 5G systems are expected to provide connectivity to millions, if not billions of such devices. There are no limits to the number of use cases, and as such, devices can range from smart meters to any kind of sensor. However, CIoT devices are constrained by nature. Think of tiny devices that, due to size constraints, must minimize battery consumption. These devices can only engage in low volume data transfer, often referred to as ‘small data’.
Standards for CIoT data already existed in 4G but were not available in 5G Release 15. Now in Release 16, existing mechanisms for CIoT data and its security in 4G have been adopted for the 5G system too. In 5G, CIoT has been introduced over the LTE radio access (E-UTRA) but not over NR radio access.
There are two different optimizations in CIoT within 5G: the Control Plane optimization and the User Plane optimization. In the 5G Control Plane optimization, the CIoT data is piggybacked in Control Plane messages. It means that the CIoT data is included in Non-Access-Stratum (NAS) signaling messages between the 5G CIoT device and the 5G core network, which are security protected by the NAS security established between the UE and the Access and Mobility Management Function (AMF) in the 5G core network. The security of CIoT data is provided by algorithms and 5G NAS security context in use between the UE and the AMF.
Fig 3: Security for Control Plane optimization and User Plane optimization
In the 5G User Plane optimization, CIoT data is transferred in User Plane messages. The uplink CIoT data can, as an option, be sent as Early Data Transmission (EDT) when its multiplexed with the Radio Resource Control (RRC) message or it can be sent as plain user data. The security of CIoT data is provided by the algorithms and the Access Stratum (AS) security context in use between the UE and the E-UTRA radio.
An additional requirement in Release 16 is the protection of the UE capability transfer in the AS layer. The base station should activate security in the AS layer before running the RRC UE capability transfer procedure. Otherwise the base station should not store these UE capabilities locally for later use and should not send them to other network nodes as these UE capabilities could be tampered with over the air interface.
Wireless backhaul security
In a service provider’s network, the backhaul is the link between a remote site – where radio equipment such as cell towers is located – and a central site containing the management nodes. In the standards, it is the interface between the RAN and the Core Network (CN). These are high speed lines, and for that reason backhaul interfaces have been typically wired based on fiber.
In 5G Release 16, wireless backhaul — by the name Integrated Access and Backhaul (IAB)— has been standardized. IAB is useful for RAN sites where it is not feasible to use fibre, for example, because of unavailability or due to high cost. IAB also aims to be a flexible and scalable backhaul option that could temporarily serve large events or emergency situations.
There are two new nodes in the IAB architecture.
Fig 4: Integrated Access Backhaul architecture.
The node named IAB donor is a gNB that provides network access to UEs via a network of backhaul and access links. The node simply called IAB node consists of a gNB-DU function and a UE function (referred to as IAB-UE). The IAB-UE function in the IAB node reuses the UE procedures. The gNB-DU function in the IAB node supports NR backhaul links to child nodes. An NR backhaul link is an NR link used for backhauling between an IAB node and an IAB donor-gNB, and between IAB nodes in case of multi-hop backhauling.
The security aspects in the new architecture for IAB are summarized below:
- Before operating as an IAB node, the IAB-UE function is required to get registered and authorized by the 5G core network.
- Mutual authentication between the IAB-UE function and the 5G core network can use EAP-TLS, 5G AKA, or EAP-AKA’.
- Use of EAP-TLS requires that certificates have been pre-installed in the IAB node and the 5G core network. 5G-AKA and EAP-AKA’ requires that a USIM is installed in the IAB node.
- A logical F1 interface between the IAB donor and the IAB node is protected using DTLS/IPsec for F1-C and IPsec for F1-U. Additionally, IKEv2 PSK authentication is supported and a dynamic pre-shared key computation (based on AS keys) may be used.
Industrial IoT data redundancy
Industrial IoT (IIoT) has very strict demands on data transmission. The foundation for meeting these demands were laid in Release 15, and it has been further developed in Release 16. The support for Ultra-Reliable and Low Latency (URLLC) communication is significantly enhanced by improvements both in the RAN and the core network . One feature of particular interest for the security context is redundancy of data paths.

Figure 5: Industrial IoT data redundancy
Assume that in a factory, one or several robots with a critical function need to report or receive data reliably and with low latency to/from a real-time application. Redundant user data is sent on multiple User Plane data paths between the RAN and the robot(s) to ensure that the data for URLLC services reaches the receiver. Security of redundant data paths inherits the security mechanism for Dual Connectivity (DC) specified in Release 15, meaning that a consistent User Plane security policy and separate security keys are used for the protection of redundant data paths.
Takeaway and further readings
There are new security features introduced for RAN in 5G Release 16. Some features are improvements on security itself and others target new use cases. We shortly discussed four of them: full rate User Plane integrity protection, Cellular IoT data security, wireless backhaul security, and Industrial IoT data redundancy.
Of course, amidst this, the pandemic hit the world. COVID-19 forced the 3GPP organization to replace face-to-face meetings with emails and online meetings. It is immensely applaudable that 3GPP delegates spread all over the world handled the stress arising from time zone differences, extended meeting times, and never-ending emails. That is also the reason why Release 16 will be in our memories for a long time.
3GPP references
Read more
5G security - enabling a trustworthy 5G system
An overview of the 3GPP 5G security standard
5G evolution: 3GPP releases 16 & 17 overview
Read more about Core network
RELATED CONTENT
Like what you’re reading? Please sign up for email updates on your favorite topics.
Subscribe nowAt the Ericsson Blog, we provide insight to make complex ideas on technology, innovation and business simple.