Supporting Low Latency Enterprise Applications with 5G on Public Clouds
Painfully clichéd though it is, I have to admit that the first thing that popped into my head as I set out to study the topic of ultra-reliable low latency communications (URLLC) with 5G networks was the phrase “Remember that time is money.” Rather than simply moving past it like a normal person, however, my particular psychological hang-up led me to dig a little deeper into the origin of the expression which interestingly (for me at least) is actually attributed to one of America’s founding fathers.
Benjamin Franklin wrote that infamous aphorism in 1748 in an essay entitled “Advice to a Young Tradesman”. While it was intended to convey the literal cost of individual idleness, we now employ the phrase as an idiom for the price of inaction. But dithering isn’t always in the physical domain. In the internetworking arena, we are increasingly equating it to the potential loss of productivity as a direct consequence of delays in data processing. This came to the forefront in the first decade of the 21st century as global stock markets moved to algorithmic trading paradigms and millisecond advantages resulted in literal profits. As we pass into the third decade, a more consequential shift is occurring. Somewhat accelerated by the global pandemic, we are rapidly entering the fourth industrial revolution (Industry 4.0), where the need for real-time data processing has a far broader applicability to the fiscal consequences of inefficiency.
In 2015 the ITU-R published M.2083, which outlines the framework and objectives for the development of international mobile telecommunications for 2020 and beyond. Considering the premise of this piece, I should note that this initiative is typically abbreviated to simply IMT-2020 Vision. It is clear from the very first paragraph of the body of this recommendation that the primary requirements for the next generation of mobile technology are in supporting “…applications requiring very high data rate communications, a large number of connected devices, and ultra-low latency and high reliability.” Maintaining the traditional chain of custody, these demands have been acted on by the GMSA’s (increasingly inappropriately named) 3GPP, forming the basis of Release 15, 16 and 17 specifications. When it comes to supporting ultra-reliable low latency communications in the radio frequency domain, the 3GPP’s answer is outlined within technical specification (TS) 38.912, a study on new radio (NR) access technology. This work will flow into the standards-track specifications, such as TS 38.201-202 and TS 38.2011-215, which detail the physical channels and modulation techniques employed within a 5G frame structure.
The 5G frame structure is the first to support multi-numerology, a word which if you happened to Google would lead you to believe I’ve either made a neck breaking hard turn from reality to mythology or left an egregious typo in this text. While it’s hard to believe half the things I say are real and there are undoubtedly numerous typos in this post, numerology isn’t one of them.
Unlike 4G/LTE, NR is designed to be deployed across frequencies ranging from low band to high band. To ensure efficient transmissions across the entire spectrum, 5G specifications define a range of orthogonal frequency division multiplexing (OFDM) subcarrier spacing. Wider subcarrier spacing is important as frequencies increase because higher bands experience more inter-carrier interferences as a result of the doppler effect, a pertinent problem when endpoints are in motion. In OFDM, wider subcarrier spacing means transmission slots are shorter and therefore increase in number. There are five fixed OFDM (subcarrier spacing) numerologies in 5G, the first (0) enables coexistence with current 4G/LTE radio and all of which can be mixed at the transmitter for further flexibility. Using the classic definition of numerology, the subcarrier spacing parameter can be directly correlated to the deployment event. A 700MHz macro cell using 15 kHz spacing for broad coverage, for example, or a 28 GHz mmWave micro cell using 120 kHz spacing for delivering enhanced mobile broadband (eMBB).
5G New Radio Numerology
If all this talk of numerology led you to predict that I’d now get back to the topic of latency, you’d be right. New radio allows for a variable transmission time interval (TTI) which can scale from 1ms, the (compatible) setting fixed in LTE, down to ~140 microseconds, depending on whether spectral efficiency (eMBB) or low latency (URLLC) is the goal. The maximum number of retransmissions can also be set according to traffic type (e.g. 2 for URLLC and 4 for eMBB). Plus, as a bonus, NR permits the multiplexing of different TTI’s on the same frequency, so spectrum can be shared without delay sensitive traffic being stuck waiting for slower transmissions to conclude. The techniques employed to enable MIMO antenna arrays also support advancements in lowing latencies, specifically the self-contained integrated subframe where transmissions from the RF antenna and acknowledgements from the user equipment occur on the same subframe.
There is one other modification to the NR frame structure, described within TS 38.912, that contributes significantly to delivering on URLLC. Regardless of the aforementioned subcarrier spacing numerology, each slot comprises 14 OFDM symbols. Each OFDM symbol represents an individual bitstream employing quadrature phase-shift keying (QPSK / 4-QAM) or 16, 64 or 128 quadrature amplitude modulation (QAM) constellations. With numerologies employing wider subcarriers and higher QAM modulation orders, the 5G specifications allow us to create a mini-slot from a sub-set (e.g. 2 or 4) of the individual OFDM Symbols. This affords us the ability to service critical traffic flows with fine scheduling granularity to reduce transmission latency. The lower the transmission speed, the smaller subcarrier spacing becomes and the fewer mini-slots per slot we can create. While that dependency on mmWaves might have 5G naysayers questioning the value of mini-slots, the majority of early URLLC applications will originate within controlled enterprise manufacturing environments where utilization of the higher bands will be easier and therefore more prevalent.
If you’ve just skipped to this paragraph, the point of the post thus far is that a lot of work has gone into enabling support of industrial IoT applications that comprise a high density of control endpoints requiring reliable, low-latency, network access. This is all for nothing if the control systems, these endpoints depend on, induce excessive processing delays. That would not be an effect of the actual artificial intelligence (AI) being applied by even the most complex machine learning (ML) software but more a consequence of the physical location from which it is applied. The low latency race in the algorithmic (stock) trading arena was won by the financial entity who’s compute engines were closest to the market (i.e. NASDAQ) and connected by the highest bandwidth speeds. For the type of pioneering Industry 4.0 enterprises who would find URLLC most attractive, this would mean co-locating compute resources within the same facility or campus as the endpoints.
领英推荐
Campus compute with 5G user plane dramatically reduces data processing delays
Furthermore, a network engineer would ideally architect a solution that features the fewest number of network hops and packet encapsulations - all of which would induce a degree of additional latency while inherently reducing reliability. That’s not to say there are not techniques to mitigate such overheads. I have detailed options like deterministic networking (DetNet) at layer 3, time-sensitive networking (TSN) at layer 2 and layer 3 alternatives to layer 2 VPN fabrics within data center fabrics in several previous posts. While these options are relevant for service provider multi-access edge compute (MEC) architectures, many enterprises have an additional mandate: Keep critical operational data securely in-house.
Ultimately, the solution imposes added demands on even the most highly skilled enterprise IT infrastructure engineers in that they need to become familiar with mobile network functions that have historically been embedded within the operator domain. If business must peel-off (steer) NR traffic for local processing, the 5G Core User Plane Function (UPF) must also reside there. Not only that, it should preferably reside with the same compute platform as the IoT application itself. The physical nature of such network functions prior to the inception of 5G would have rendered that impossible but, like most modern applications, 5G network functions are required to be pure software elements employing cloud native design patterns. Building the incredibly efficient, high performance, packet processing engines required to enable these new operational implementations, however, is no easy feat.
We achieved it by developing a 5G Core UPF that employs a unique Composable Network Application Processor (CNAP) engine. This allows us to instantiate a UPF on an edge compute platform while leaving plenty of CPU capacity for enterprise applications. The solution is incredibly lightweight, requiring just a couple of CPU cores in instances with minimal traffic flows. In industrial IoT environments, where the 5G infrastructure is serving a sensor grid, this is a likely scenario and enables a significant portion of a platform’s compute capacity to be targeted at returning rapid control requests and responses to the networked devices. The dynamic nature of CNAP enables our UPF implementation to scale-up as packet rates increase, bumping lower priority functions to secondary service platforms or simply assigning less computational cycles to the enterprise application. CNAP achieves this performance without consuming any GPU cycles so, if present, this specialized silicon is exclusively available for data processing.
CNAP delivers a high-performance but lightweight 5G UPF
While an enterprise could deploy this solution on any private compute environment, that approach is increasingly going against the trend towards utilizing public clouds. Employing public cloud architectures for private 5G enables businesses to realize the same fiscal and operational benefits of Infrastructure, Platform and Software as a Service (IaaS /PaaS and SaaS) that has encouraged the broader move towards these options for other enterprise applications. Abstracting much of the complexity around implementing and maintaining highly distributed, interconnected, compute platforms, a public cloud can dramatically simplify deployments. Orchestrated instantiation and automated configuration of network functions minimizes ongoing management issues while providing the perfect stage for practicing modern DevOps methodologies.
Yet, being centrally located, large public compute clouds typically have a distinct disadvantage when it comes to meeting the strict latency demands of any real-time communications service that lack the luxury of punting endpoints over point-to-point (P2P) connections. And P2P certainly isn’t applicable to operator or enterprise services where data must be acted on for interworking and it certainly can’t be employed where multi-input ML or AI algorithms must be quickly applied to data streams. Solutions such as Microsoft’s Azure Stack Edge platform and complementary Azure Edge Zones software packages are solving this problem by extending the Azure public compute cloud and all its intrinsic benefits to small form factor offerings that are ideal for the customer premise or campus. In the case of 5G, this is key to providing enterprise IT specialists a simplified package which includes the ability to instantiate critical NR network functions that comprise not only the UPF but also open radio access network (O-RAN) elements such as the centralized and distributed units (CU/DU). Furthermore, Azure Edge Zones contains common networking and security functionality, like VPN, SD-WAN and firewalls plus specialized IoT features.
If you’ve just skipped to the last paragraph, the main point of this post was that Ben Franklin imparted incredible words or wisdom we still apply today. According to sales mythology, he would have also closed the deal on employing public compute clouds to support URLLC using private 5G by making a list of pros and cons. As a marketing guy I’d have to take a long shower if I suggested such a thing. Nevertheless, the reality is that the demands of industrial automation and communications technology are converging to a point where widespread enterprise 5G adoption is not only a distinct possibility but an absolute necessity. So, we should get a move on. Remember that time is money.