In the evolution of mobile networks from 4G to 5G, a key aspect is the separation between control plane and user plane. This separation, called CUPS (Control and User Plane Separation), is supported by the strict definition by 3GPP of a set of Network Functions and interfaces within the Core Network (CN) and the radio access (RAN) of a 5G network. In this article we will focus on some less-known functions with regard to the principal ones widely discussed in the literature and technical papers online, dealing both with the user plane and control plane protocol stacks for the non-3GPP access.
|5G-RG||5G Residential Gateway|
|AMF||Access and Mobility Management Function|
|FN-RG||Fixed Network Residential Gateway|
|N3IWF||Non-3GPPP Inter-Working Function|
|N5CW-UE||Non-5G-Capable over WLAN UE|
|NR||New Radio (5G)|
|PCF||Policy Control Function|
|SMF||Session Management Function|
|TNAN||Trusted Non-3GPP Access Network|
|TNAP||Trusted Non-3GPP Access Point|
|TNGF||Trusted Non-3GPP Gateway Function|
|TWIF||Trusted WLAN Inter-Working Function|
|W-5GAN||Wireline 5G Access network|
|W-AGF||Wireline Access Gateway Function|
Reference 3GPP release 15 5G Standalone Architecture and UE interfaces
We report the well-known service based view of a 5G network as extracted by .
Figure 1: Non roaming service based 5G architecture – rel 15 
Each functional block is interconnected with other ones via a specific interface, called reference point, which is realized by a specific protocol stack. In the upper part of the architecture (northbound) we have control plane functions, which are connected via N1, N2 and N4 reference points to downards functions involved in the handling of user traffic (data plane). Focusing on the data plane, traffic between User Equipment (UE) and Data Network (DN) goes across RAN and one or more UPFs. Between UE and RAN we can assume the use of the New Radio Air Interface (NR-Uu), while between RAN and UPF N3 reference point is defined. In case of passing through several UPFs, these are connected via the N9 reference point (which is similar to N3), and finally via N6 reference point to the DN (i.e., the Internet).
If simplifying the 5G network by considering only functions and interfaces from the UE perspective, assuming a single UPF and a single gNB for RAN (without any CU/DU splitting), we obtain the following architecture in figure. N1 is the control plane interface with AMF, whose messages are delivered via NR-Uu and N2 interfaces through the gNB. N3 is delivering user data to the UPF and then to the DN via N6.
Figure 2: UE point-of-view – control and user plane
As reference, we report for completeness the whole protocol stack for these interfaces with the identification of the protocols in use (even though thanks to 5G flexibility several options and different protocols can be employed at different layers according to the configuration). First, the control plane interfaces protocol stack, with N1 delivering control messages (including authentication) between UE and AMF, via NR-Uu (air interface) and N2 interface. NG Application Protocol (NG-AP) is used in N2 to transport Non-Access-Stratum (NAS) N1 signalling.
Figure 3: N1 and N2 protocol stack (Control Plane)
Next, the user plane interfaces protocol stack is reported, assuming the delivery of user Application PDUs between UE and UPF using IP, and with TCP or UDP as transport. Instead of IP (either IPv4 or IPv6), also Ethernet and Unstructured PDUs can be used as alternative. Note that N6 corresponds in all cases to the classic Internet TCP/IP stack.
Figure 4: N3 and N6 protocol stack (User Plane)
Untrusted non-3GPP access: N3IWF
In 3GPP release 15 of 5G , the support for non-3GPP access to the Core Network (i.e., avoiding the RAN part and using other types of access) is described, defining the Non-3GPP Inter-Working Function (N3IWF) component. More specifically, untrusted Wi-Fi (802.11) access is considered, since the large majority of UEs have both 3GPP radio interface and Wi-Fi interface. N3IWF is in charge to “adapt” access and authentication protocols of the non-3GPP WiFi section towards the 5G CN.
Untrusted refers to the fact that non-3GPP access (i.e., the WiFi Access Point) is assumed not managed by the same operator of the 5G network: as an example an hotspot into an airport, or the domestic Wi-Fi router. For this reason an end-to-end security association between UE and N3IWF shall be established, regardless of the one established in the access at layer 2 (i.e., WPA2).
Please note that non-3GPP untrusted access was already available in LTE networks, via the ePDG component defined during the evolution of 4G networks, using a different approach with regard to 5G and resulting somewhat of limited applicability in real networks. The goal of 3GPP is to define for 5G since the beginning an interoperable, straightforward and reliable non-3GPP access mechanism which will most likely be adopted on a wider scale. The resulting architecture is shown in figure, remarking that the UE can simultaneously enable the NR-Uu access via gNB, or have WiFi as unique access method. In either cases 3GPP credentials to initiate the access (i.e., USIM/eUICC) are always required.
Figure 5: N3IWF architecture
N3IWF mainly provides a secure gateway to operator’s 5G network for non-3GPP access. The interface NWu between UE and N3IWF is based on IPSec/IKE to establish a secure tunnel, by-passing the security mechanisms enforced by the Access Point (if any). As UE is expected to communicate with AMF over the NAS interface, N3IWF has a N2 interface connecting with AMF to enable N1. Then, N3 interface to interact with UPF is included as well in N3IWF.
N3IWF is responsible for setting up the IPSec connection to be used by control plane traffic directed to AMF, as well as the traffic directed to the UPF for the user plane. As a consequence UE and N3IWF need to establish two IPSec Security Associations (SAs):
- Signalling (control plane) IPSec SA – it transports NAS messages destined to AMF
- User plane IPSec SA – it transports packets destined to DN
In the first step of control plane operations, UE and N3IWF must establish a signalling IPSec SA, which is used to securely exchange NAS messages between UE and AMF. The NAS interface is further leveraged to register UE in the 5G system. Figure 6 presents a control plane protocol’s stack used to establish signalling IPSec SA. IKEv2 protocol is used to setup security associations.
Figure 6: N3IWF protocol stack before SA establishment – control plane
When the signalling IPSec SA is established, the IPSec tunnel (i.e., ESP in tunnel mode) can deliver EAP-5G (or 5G AKA) messages, used to encapsulate NAS messages between UE and N3IWF (3GPP specification says that EAP-5G is “vendor-specific”). At this stage, UE can communicate with AMF to perform end-to-end NAS signalling as presented in Figure 7. Note that the IPsec layer includes as well the “Inner IP” header, required to establish the IPSec tunnel.
Figure 7: N3IWF protocol stack after SA Establishment – control plane
Once UE is registered in the 5G system (via NAS interface) it can establish a new child IPSec SA (called user plane IPSec SA) to communicate with the Data Networks. The user plane protocol’s stack is depicted in Figure 8. A GRE (Generic Routing Encapsulation) protocol is used to carry user PDU (IP) between UE and N3IWF. GRE allows in particular to implement a flow-based QoS model as specified in TS 23.501, carrying QFI (QoS Flow Identifier) associated with user data packets as defined by 3GPP specifications. GRE is also supporting the other types of PDU foreseen (i.e, Ethernet). The user plane IPSec tunnel as well includes an “Inner IP” header.
The adaptation of WLAN to access a 3GPP network is then requiring a relatively higher overhead with regard to direct use of the same technology by the UE: 2 independent IP layers, plus 1 GRE header plus 1 IPSec header with inner IP header (for ESP in tunnel mode) instead than a single IP header.
Figure 8: N3IWF protocol stack after SA Establishment – user plane
Note that current implementations of 5G networks are based on rel-15 and on a legacy LTE Core Network (i.e., Non-Stand-Alone, NSA) configuration, therefore the N3IWF is normally neither available in the core network nor available in COTS UEs as of today.
Trusted non-3GPP access
Starting from 3GPP release 16 , additional non-3GPP access mechanisms are defined, and specifically “trusted” ones. Trusted means that the operator of the 5G Core Network is also in charge of operating and managing the non-3GPP access which, in addition to WiFi, is also extended to terrestrial fixed access. These updates in rel-16 open to 4 new scenarios:
- Scenario 1
- Mobile 5G UE devices that can register, access and exploit Core Network services both by 3GPP New Radio access and trusted WiFi. This is similar to what already allowed by N3IWF with the difference that WiFi access points are coordinated and under the control of the same 5G network operator (also in terms of QoS). This scenario can be called Mobile Wireless Access (MWA).
- Scenario 2
- Mobile UE devices which do not support 5G capabilities (i.e., NAS protocol for N1 and NR-Uu) but have 3GPP credentials (USIM/eUICC), accessing exclusively to the CN via a trusted WiFi.
- Scenario 3
- Fixed 5G UE devices, called 5G Residential Gateway (5G-RG) which combine 3GPP NR access with fixed access (specifications for DOCSIS are available, and more are under definition) to the same CN. This scenario is called Fixed Wireless Access (FWA).
- Scenario 4
- Fixed UE devices, called Fixed Network Residential Gateway (FN-RG), which do not support 5G capabilities but have 3GPP credentials, accessing exclusively to the CN via fixed network (i.e., DOCSIS or Broadband fixed modem).
Untrusted fixed access is not of practical interest, therefore not considered at all.
In all the above cases, the key difference with regard to the untrusted WiFi access (i.e., N3IWF) is that security can be enabled directly on non-3GPP access layers, such as IEEE 802.11, and not as part of IKEv2 establishment. Nonetheless, it was decided to maintain the same UE protocol stack, with the use of IPSec “VPN” but without encryption (NULL): this allows to develop in the UE the same protocol stack regardless on trusted or non-trusted access.
In all these new 4 scenarios, a dedicated access/gateway component is introduced (logically equivalent to N3IWF), required to enable northbound N2 and N3 interfaces needed to integrate the user terminal within the CN. Other than this, a significant difference exist for scenarios 2) and 4): N1 interface shall be terminated and managed by the gateway function, which then becomes to all effects a 5G UE on behalf of the end user.
In the 4 different scenarios, the access functions have a different name and are described below. Once a non-3GPP access is implemented in a 5G CN, if also the 3GPP access is available, it is possible to enable also the ATSSS option for traffic steering, switching and splitting.
Mobile Wireless Access: TNGF
In the first scenario of trusted WiFi, the access function is called Trusted Non-3GPP Access Network (TNAN). TNAN is split in two parts, the Trusted Non-3GPP Access Point Function (TNAP) and Trusted Non-3GPP Gateway Function (TNGF), as shown in figure. Please note that a similar configuration for non-3GPP WiFi trusted access was also defined for LTE networks, by using instead the Trusted WLAN Access Network (TWAN) and Trusted WLAN Access Gateway (TWAG) components respectively. In TNAN, Ta represents the interface between the trusted Access Point and the TNGF, within the CN. In rel-16 there are no indications on how an AP can be considered trusted (so “promoted” to TNAP) and which trust associations and additional interfaces with the CN are required (e.g., a modified EAP-5G protocol, interfaces with AAA, etc.).
Figure 9: TNAN architecture scenario 1 (TNGF)
From the protocol stack point of view, TNGF it is in practice equivalent to N3IWF, with the exception of using an IPSec tunnel with no encryption (lowering UE CPU load), while lower layers WLAN security mechanisms are enforced. As an example, the User Plane protocol stack is reported in figure. In this scenario, UE can of course access to the CN via 3GPP as well.
Figure 10: TNGF User Plane protocol stack
Non-3GPP Mobile Wireless Access: TWIF
As specified in  for scenario 2, UEs that do not support 5G CN NAS signalling over WLAN (N1) are referred to as “Non-5G-Capable over WLAN”, or N5CW. Even though a N5CW UE might not support N1 reference point, however, it may be capable to operate as a 5G UE with the introduction of a dedicated gateway function. The role of TNGF is therefore replaced by the Trusted WLAN Interworking Function (TWIF), with the main difference that TWIF terminates the N1 NAS interface and behaves as a 5G UE in regard to the Core Network.
Figure 11: TNAN architecture scenario 2 (TWIF)
In this case we have no NWu/NWt equivalent interfaces, since authentication is carried out individually on Yt’ and Yw. TNAP shall relay authentication credentials towards TWIF, which shall support 3GPP authentication and enabling NAS signalling with the CN on behalf of the N5CW UE.
As a consequence of how N5CW are defined, they do not support 3GPP access via New Radio; therefore WLAN can be considered the exclusive access method to the CN. A possible access without 3GPP credentials (i.e., USIM), which a device without 3GPP access is likely not to have, is not yet defined and shall be further refined in rel-17.
Figure 12: TWIF Control Plane protocol stack
Fixed Wireless Access: 5G-RG W-AGF
Starting from rel-16 other types of access different from WiFi have been defined, with particular reference to fixed access represented by domestic broadband modems (such as DOCSIS – Internet via Cable – widespread in the USA). The same approach in line of principle could be extended to other fixed access technologies, including satellite-based ones, and are subject to further discussion in rel-17. In this third scenario a new Wireline 5G Access network (W-5GAN) gateway function is defined in the CN. W-5GAN includes the Wireline Access Gateway Function (W-AGF), which is equivalent to TNGF for what concerns its functionalities and interfaces/relation with the CN. W-AGF is part of the landline core ISP infrastructure and connected to the CN enabling N2/N3 interfaces. The 5G-RG can as well access via 3GPP to the Core Network, as for the first scenario (i.e., a DSL modem with 3GPP NR-Uu access).
Figure 13: W-5GAN architecture scenario 3
Please note that a 5G-RG might only have 3GPP access: in that case it becomes a standard UE in the 5G architecture and it requires no adaptation gateway functions.
Non-3GPP Fixed Wireless Access: FN-RG W-AGF
Finally, for fixed access without 3GPP N1/NAS support, a similar architecture with regard to scenario 3 is defined, with N1 managed by the W-AGF on behalf of FN-RG in such a way as it was performed by the TWIF.
Figure 14: W-5GAN architecture scenario 4
Possible implementations of W-5GAN
In case of modems using DOCSIS, the W-5GAN element is defined in  and renamed W-5GCAN (where a “C” is added to mean Cable). W-5GAN functions are performed via the DOCSIS Wireline Access Network (AN) by W-AGF functions divided in User Plane and Control Plane.
In relation to scenario 3 the device at the user’s premises is called 5G Cable Residential Gateway, or 5G-CRG and the following architecture (extracted directly by ) is proposed.
Figure 15: Cable Labs integration architecture for Cable 5G Residential Gateways 
In relation to scenario 4, the end device at the user premises is called instead Fixed Network-Cable Residential Gateway (FN-CRG), and the difference with the previous architecture relies substantially in the management of N1 within the W-AGF-CP block directly.
Figure 16: Cable Labs integration architecture for Fixed “Cable-only” Residential Gateways 
In case instead of broadband devices compliant to Broadband Forum (BBF) specifications , 5G convergence is described in , for both 5G-RG (with also 3GPP NR access) and FN-RG (without 3GPP NR access), by introducing the specification of the Access Gateway Function (AGF), i.e., the Wireline Access Gateway Function W-AGF mentioned in 3GPP specs. The overall converged architectures possible, as extracted from  are showed in figure. The first architecture represents a 3GPP only home device (i.e., an UE); the second architecture can be aligned with the scenario 3 discussed before. The third architecture is associated to the scenario 4.
As alternative from AGF-mediated access, another access mechanism is defined by BBF for legacy devices (i.e., non 5G aware), in which a Broadband Network Gateway (BNG) and a Fixed Mobile Interworking Function (FMIF) functional blocks are defined. BBF also foresees a direct by-pass of the Core Network accessing directly to the DN via the BNG. These are the architectures 4 and 5 in figure, at present not described in 3GPP specifications. Please note that BNG and FMIF function specification are still under finalization.
Figure 17: 5G Fixed Mobile Convergence scenarios 
Access to a 5G network and its associated guaranteed-quality services via a non 3GPP access opens to the definition of new value-added services extended towards a larger group of end-user devices and use-cases. At present Wi-Fi/WLAN and cable specifications were defined, and more extensions can be proposed in future 5G releases, with particular reference to Satellite based non-3GPP access. Satellite could in particular enable large-coverage and mobility cross-the-border applications, where satellite-based access can be used as complementary link (failover, redundancy and resilience) or as supplementary link leveraging its broadcasting nature (best suitable for live IPTV services). Once both 3GPP and non-3GPP access is established to the CN, it is possible to enforce multi-access strategies in the newly defined rel-16 ATSSS (Access Traffic Steering, Switching and Splitting).
 System Architecture for the 5G System (3GPP TS 23.501 version 15.3.0 Release 15)
 System Architecture for the 5G System (3GPP TS 23.501 version 16.6.0 Release 16)
 5G Wireless Wireline Converged Core Architecture Technical Report WR-TR-5WWC-ARCH-V01-190820 Cable Labs, 2019
 BBF TR-124 issue 5: “Functional Requirements for Broadband Residential Gateway Devices”
 BBF TR-456 issue 1 “AGF Functional Requirements”, Aug. 2020
 TIM, NotiziarioTecnico, “5G Network convergence and orchestration initiatives by BBF, ONF, LF EDGE, TM FORUM and ETSI”, 2019.
© RomARS – Francesco Zampognaro