5G, the fifth and latest generation of cellular network standards, is attracting plenty of attention within the Internet realm, in particular, the increased bandwidth, greater connectivity, stability and lower latency the technology will provide mobile applications.
With an expected release date of September 2018, the first release of 5G still has a lot of areas to be studied, including how 5G mobile technology interacts with IP networking. Our work has been looking at how to simplify the data path of mobility management.
Mobility management is complex
Currently, mobility management is executed through GTP (GPRS Tunnelling Protocol), which consists of control-plane and user-plane parts. The control-plane signals movements of a mobile node and establishes user-plane data-paths using tunnels between the mobile node and anchor node over IP-based backhaul and core networks.
The control-plane is a very important and complicated system that handles all mobility events on a mobile device. The GTP user-plane (GTP-U) assists with reducing this complexity: it is an overlay tunnelling protocol, which means the control-plane doesn’t need to communicate with or understand underlay networks.
Underlay networks are also complex. They include wavelengths multiplexed in fibres, MPLS label-switched paths (LSPs) deployed on the wavelengths, pseudo-wires on the LSPs, VLANs on the pseudo-wires, MPLS LSPs again on the VLANs, L3VPNs on the LSPs, the GTP-U on the L3VPN and the IP layer, which mobile devices are accommodated on. These are all required for real deployment of mobile networks in terms of capacity, reliability, quality, and isolation of the control-plane and O&M networks from the user-plane.
Figure 1: Protocol stack in mobile networks
The 5G system has to be aware of these underlay networks to provide applications various network slices so that the user-plane can meet the requirements of the applications running on the 5G network.
Virtualization technologies can help a lot with deploying these slices, however, such technology cannot optimize this to the point that awareness about underlay topologies and characteristics is not required.
Figure 2: Network slicing concept. Source NGMN
As such, there are fears that virtualization technology will introduce additional complications and costs, which would slow the deployment of 5G and could be a dilemma for the providers who want to provide services with 5G advantages as soon as possible.
Instead of virtualization, the 5G control-plane has been transformed into a modular, pluggable-functions architecture, which enables operators to introduce additional features to mobile networks easier. In this scenario, the user-plane and control-plane would be flexible in terms of function deployment. That said, the user-plane complication that I described above, could still be an obstacle.
Figure 3: 3GPP 5G Ph-1 Architecture. Source: 3GPP TS23.501 (V15.0.0)
Possible solutions to mobile user plane with underlying layers integration
There are two possible solutions to the problem of multi-layer complexity:
- Continue to cope with the complexity.
- Simplify the network.
The first option, requires allowing the 5G control-plane to manipulate each underlying layer. In this option, the mobile user-plane layer doesn’t need to modify anything but the control-plane needs to provide some underlay network paths, such as LSP for traffic engineering, for example.
An important thing to note about this option is that it introduces multi-layer handling complications to the control-plane in addition to its mobility management tasks. No matter what SDN solutions can help to automate provisioning workloads, this compounding of complexity could prevent network coverage and capacity growth.
The second option, is to simplify the network by integrating the user-plane into a layer that forwards packets through requested data-paths. This option would eliminate control-plane multi-layer complications and allow it to focus on managing mobility tasks based on the received requirements from apps to the user-plane. However, because of existing user-plane protocols, GTP-U is not able to do this.
If we choose the second option, we need to decide which single network layer is able to integrate all required functions into it. The simple answer to choosing that layer is to adopt an inevitable layer for all communication, which must consist of an end-to-end IP layer. If we can leverage all things into that layer and its protocol, that should be the simplest scenario.
There has been a significant rise in IPv6-enabled apps in the past year that adds further weight to the argument that we choose the second option. The ‘limitless’ amount of IPv6 address space available allows for global uniqueness, which would mean there would be no additional costs for multiplexing mobile sessions to be identified between tunnel endpoints of the user-plane.
IPv6 could provide the key
This IPv6 layer is now able to provide features not only for address space but also allow for integrating network functions into it. On this point, it’s worth mentioning the IETF’s work on Segment Routing IPv6 (SRv6), which enables any possible forwarding functions represented as IPv6 addresses.
SRv6 network programming defines various types of forwarding functions, which are encapsulation/decapsulation and routing/cross-connect on a table that comprise traffic engineering, VPNs, and service chaining features.
The segment routing concept also enables networks to be able to source routing for traffic engineering without the heavy workloads of signalling and states in the nodes using IDs of either the MPLS label or IPv6. Beyond that, SRv6 leverages IPv6 address space to provide a kind of network programmability to compose data-paths in the end-to-end IPv6 layer that integrates all required features into it.
Segment routing with MPLS labels are able to do this as well but they have a limited ID space of 20-bits (equivalent size with IPv4 class-B private address space), and an incremental number of stacked layers in addition to the end-to-end layer.
Figure 4: Integrating features of the protocol stack into the end-to-end IPv6 layer
Leveraging the SRv6 concept, the IETF is working on a SRv6 mobile user-plane that enables any functions required for the mobile user-plane within SRv6. What this means is that mobile applications will only need one IPv6 layer to run on. That’s the most simplified user-plane to realize various requirements for applications.
Network resources, even a wavelength in a DWDM system dedicated to broadband service, could be represented as an IPv6 address if operators implemented underlying fibre networks in SRv6. It could also represent optimized paths for low-latency and with high reliability for other types of applications. Once those resources are abstracted as IPv6 IDs, the control-plane could comprise of slices with them as nodes of the user-plane function (UPF), and deploy required data-paths for mobile applications on them.
Figure 5 shows that user-planes that are programmed by Session Management Function (SMF) compared to the cases where the user-planes are GTP-U and SRv6. Tunnels are increased session by session with no path differentiation in the GTP-U case. While the SRv6 user-plane reduces the number of states in the middle of the nodes by using IPv6 SIDs (Segment ID) of represented resources, the SIDs enable SMF to program data-paths and handle sessions along with the application’s requirements.
Figure 5: User plane comparison between GTP-U and SRv6 in 5G architecture
The 3GPP has officially initiated a new study item ‘Study on User Plane Protocol in 5GC’ to seek possible candidates for next user-plane protocols for Release 16 of 5G phase 2. SRv6 could be a possible candidate protocol if it is well developed during that study period. We still have a lot of work to do to make sure of this.
With IPv6, I think we are on the right track to overcoming the complexities that could potentially impact the speeds that 5G promises. Converging 5G features into the end-to-end IPv6 layer is the key to embodying 5G in simple architecture.
Satoru will be presenting this work at the upcoming MPLS/SDN/NFV World Congress 2018.
Satoru Matsushima is a Deputy Director in SoftBank’s Network Division.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.
the separation of control plane and data plane is very nice for reducing latency and application acceleration.
generally you used sdn(software defined network).