Network Slicing in Action

Smarter Node Selection for Low Latency Mobile Services

Written by Humberto La Roche, Bob Smith, and Tim Stammers

One particular aspect of mobile network evolution that deserves attention is the idea of reducing round-trip time (RTT) between consumers of a service and the service source itself. So much so that in 5G, this concept has acquired its own unique 3GPP term: URLLC which is an acronym for Ultra-Reliable Low Latency Communications. Cisco envisions, as does AT&T among other leading carriers (see [1, 2])  that low latency communications will enable a new class of network services characterized by tight control loops involving Augmented Reality (AR), Virtual reality (VR) and even haptic communications triggered by the immediate network response to a touch event. Cisco is excited about these possibilities and is pursuing an aggressive mobile network evolution strategy designed to deliver an end-to-end system architecture enabling low latency capabilities. But amidst all of this, it is probably worth unpacking the basics so that we can develop an understanding of what is truly needed and how we can help carriers realize the end-game.

Perhaps the most relevant control loop today is the one that keeps the venerable TCP protocol operating well in networks. The TCP congestion control algorithm brilliantly introduced by Van Jacobson and others [3]  defines a method whereby a channel can signal performance to a sender, in real time, to adjust its streaming rate to the end-to-end congestion state. It is understood empirically that in most regimes and most TCP versions, the TCP throughput performance is inversely proportional to RTT or some power of RTT between 1 and 2 [4] . And why is this important? Well, notwithstanding the introduction of QUIC [5], this observation is very important because most traffic delivered, over 90% by volume, is carried by TCP protocol! And this includes consumer video whether managed by the operator or streamed by an over-the-top content publisher. And the network can help reduce RTT latency by allowing for content servers in the form of content delivery network (CDN) caches to be deployed close to the consumer of the TCP traffic. Reducing the latency to enhance performance is hugely important for video traffic which today is primarily delivered over TCP. And even QUIC itself uses TCP-style congestion control to rate limit itself and so the dependency on RTT is still present as a consequence.

But most mobile core networks are not designed to assign a geographically appropriate IP address, one based on the location of the user, to the mobile device. In fact, the conventional wisdom up until now has been that an operator would not ever want to do that! Why? Well, the reason is very basic: mobile networks are designed with the principle of IP address continuity in mind: a mobile device preserves its IP address no matter where located in the mobile network. In a nationwide network, a user can in principle travel thousands of miles, adding significant transport latency, and still use an IP address that has no relationship at all to the location. And this, up until now, has been considered a good thing.

But something changed along the way. Mobile application designers started to build resiliency to underlying IP address changes into their apps. For example, a video streaming app might play from a buffer while it silently restores TCP connectivity to the server when an underlying IP address change occurs.

Or, a mobile application designed might build an app using a protocol stack designed from the outset to not care about underlying IP address changes. The aforementioned QUIC protocol from Google has this feature and new protocols in the ICN/NDN family [6]  also do. Network-hosted mobility is becoming less important!

Putting it all together, a priority for mobile network architects should be to figure out precisely how to do a geography-based selection of anchor points so that low latency services can be maintained despite user mobility. This is a traffic management function which Cisco has achieved in a manner entirely compatible with existing mobile device features and with emerging 3GPP R14 and 5G architectural principles.  The key concept is the disaggregation of the mobile core called “Control and User Plane Separation”, or CUPS in 3GPP specifications [7-10]. In CUPS, the mobile core is decomposed into a centralized control plane supporting session management, policy and charging, as well as regulatory features and User (or bearer) Plane entities that can literally be deployed anywhere the IP network allows. In Cisco’s micro-services-based Cloud Native Mobile Core solution, the core also includes an intelligent EPC node selection function that allows for the dynamic selection and re-selection of these User Plane entities so that they are geographically appropriate at any point in time and for a specified subscriber and specified Access Point Name (APN). In this way, the IMS APN or any other APN which is required to be always anchored and for which RTT is a lesser consideration, can remain so but any other selected APN such as a video APN, a specialized low latency APN, or even an Internet APN, can be locally anchored with geographic specificity to the location of a user, and based on the Subscriber’s profile.

Such intelligent and dynamic node selection is but one of the many capabilities of Cisco’s Node Selection and Load Balancing (NSLB) product which was unveiled at MWC 2017. Cisco’s NSLB is a leading Cloud Native virtualized software application in the overall Cisco Mobility packet core portfolio. In both 4G and 5G cores, Cisco’s NSLB enables Node and Slice selection, Node/Slice load balancing, and bearer traffic steering at high scale, in a more dynamic, flexible and cost-effective manner than classic DNS techniques can enable.

Through its dynamic analysis of session signaling, and select real-time network interactions, Cisco’s NSLB product enables carriers to implement a truly Cloud Native DevOps service and network operations model over NFV-based EPC and 5G core architectures, by enabling the activation and deactivation of specific core nodes and slices linked to new services, new capabilities, and / or new core capacity. In support of such DevOps operations, NSLB also enables the carrier to dynamically add/remove candidate EPC node types, and slices as a basis for performing subscriber impacting maintenance activities or changes – again without the need to manipulate or distribute new DNS zone files and without the need for MME or DNS system feature upgrades.

Cisco’s NSLB is a pre-5G version of the 3GPP/5G-defined NRF and NSSF elements [10] that works in the LTE networks deployed today. While Node and Slice selection is an embedded defined function in 3GPP’s 5G architecture, today’s leading carriers aren’t waiting for 5G to reap the operational benefits of intelligent node selection, and are working today with Cisco on innovative use cases such as the mobile low latency services described above.

Low-latency mobile session processing, in conjunction with dynamic geographically-based core node selection is a powerful feature combination. It enables consistent delivery of low latency services in the presence of mobility, and allows for a highly scalable mobile network supporting video traffic delivered over TCP (or other protocols for which RTT is a consideration). Dynamic management of proximity on a per-APN and per-subscriber basis might actually be the elusive standards-based feature that delivers the promise of edge computing!

If you have a question or would like more information please email: mobilecloud@cisco.com

References

1. Lightreading. (2017). For AT&T Mobile ‘Edge,’ Clouds Connect the Car & More to 5G.
2. Lightreading. AT&T Promises Edge Computing Push.
3. V. Jacobson and M. J. Karels, “Congestion Avoidance and Control,” in SIGCOMM ’88, Stanford, CA, 1988: ACM, 1988.
4. T. V. Lakshman and U. Madhow, “The performance of TCP/IP for networks with high bandwidth-delay products and random loss,” IEEE/ACM Transactions on Networking, vol. 5, no. 3, pp. 336-350, 1997.
5. R. Hamilton, J. Iyengar, I. Swett, and A. Wilk. QUIC: A UDP-Based Secure and Reliable Transport for HTTP/2. 
6. L. Zhang; et al., “Named Data Networking (NDN) Project,” October 30, 2010.
7. TR 23.714, Study on control and user plane separation of EPC nodes (Release 14), 2016.
8. 3rd Generation Partnership Project (3GPP). TS 23.214, Architecture enhancements for control and user plane separation of EPC nodes (Release 14).
9. 3rd Generation Partnership Project (3GPP). TS 29.244, Interface between the Control Plane and the User Plane of EPC Nodes (Release 14).
10. 3rd Generation Partnership Project (3GPP). TS 23.501, System Architecture for the 5G System (Release 15).