The case for 5G hinges as much on the promise of low latency as on high capacity and support for massive numbers of devices, yet some operators and vendors have been playing down its significance.
There is a view that the value of ultra-low latency (ULL) has been overblown, and that what matters is that delay should be low enough for each given use case. This is obviously correct and it is true that many use cases, including even live video streaming, do not require sub-millisecond latency. It is also true that such low latencies can, in any case, only be delivered over relatively short distances, given that even at the speed of light a signal can only travel 300 kilometers in 1ms.
But such low latencies are required for some of the compelling use cases that 5G either promises to make possible for the first time, or can support wirelessly, where previously only wireline connections would have worked. Such use cases, in the immediate future, will be confined almost entirely to enterprise and industrial sectors, with consumers only standing to benefit later on, for example when extreme applications of augmented reality (AR) get going.
In the short term, operators stand to gain little in the way of additional revenues from 5G in the consumer sector in any case, with opportunities mostly confined to industrial and enterprise for the foreseeable future. What is true though, is that 5G use cases across the board will call for a range of latencies, from below 1ms for some industrial control and robotic applications to say 5ms for live video streaming, and considerably more being acceptable for non-real time processes.
Among the most demanding applications are robotic motion control, where sub-2ms latency is critical, and sometimes sub-1ms. There is also an emerging field known as cobotics, where humans and robots work in tandem on often critical real time processes, aided by machine vision systems where feedback has to be almost instantaneous.
Wired Ethernet systems such as Profinet, EtherCAT and Sercos already deliver the required latency, but the presence of cables has hindered their deployment and imposed high levels of maintenance, while being unsuitable for some flexible manufacturing configurations where equipment is often moved and redeployed.
Both 4G/LTE and WiFi have been tried for such applications but have been unable to cut latency sufficiently, while also being too susceptible to jitter, which can cause failures by pushing delays too high sporadically. 5G promises to avoid cables while meeting the demand for consistently low latency.
Critics are right to point out that reducing latency to the bone for all use cases would incur unnecessary costs, just as increasing network availability to ‘6 9s’, equating to just 30 seconds downtime a year, or even ‘7 9s’ at three seconds, is overkill in most cases. 5G will, to some extent, cater for differing requirements for latency and availability through network slicing, where some services can be allocated higher performance and reliability guarantees than others. But as the total latency budget is made up of components right across the protocol stack, some of these use cases will also require mechanisms to be employed at the application level above the physical, network and transport layers covered by 5G. All 5G can do is make sure those layers are properly addressed.
Rather than laboriously breaking latency down by protocol layers though it is clearer to distinguish between the contributing factors on the basis more of where they come along the overall transmission path. There are four main contributors, insertion, propagation, processing, and queuing.
Insertion delay, sometimes referred to somewhat misleadingly as transmission, is the time taken to feed a data packet from its source into the communication medium, such as the 5G RAN. Processing is the time taken for switching or routing, taken up mainly by reading a packet header and determining the best route on the basis of factors such as congestion in the network. Propagation is the time taken to transmit the packet from one end of a network to the other, determined by the laws of physics governing signal speed in the given medium. Then queuing is the time spent in a buffer waiting for insertion into the medium to occur.
These four stages can occur multiple times during a packet’s overall transport between two communicating mobile elements, such as in the RAN, backhaul, core and content delivery network (CDN).
Of the four, queuing has historically usually accounted for the majority of the latency budget, but that has changed somewhat in the light of efforts to reduce its impact. Indeed, propagation, previously of the least concern, is now the constraining factor for ultra-low latency over long distance links since signals take up 150ms to traverse networks to opposite sides of the world. That is why ULL can only be available locally, and why some applications such as gaming again have to be confined regionally. Fortunately, this does not matter for many of the use cases, such as the Industrial IoT and autonomous driving.
For 5G, a major focus has been on squeezing the queuing delay further through improvements in the core network architecture, as well as operation at both the physical and media access control (MAC) layers. The MAC has had to be revised to optimize access times to the medium to make best use of new physical transmission mechanisms, including Massive MIMO and full duplex antennas that communicate in both directions simultaneously.
Some of the new techniques come at the expense of higher IP packet loss or error rates, so attention has to be paid to data correction. Indeed, error correction could be said to be a fifth contributing factor to latency, even though it belongs to the application level, because the need for it varies with use case.
It is vital for high quality video, especially on demand where time is not critical, while being less important for conferencing where keeping latency low is the main requirement. At the same time though the need for error correction depends on the robustness of the underlying network and transport mechanisms, so it is disingenuous to regard these as completely distinct.
In the case of 5G, the URLCC group of use cases is naturally where the focus of work on low latency has been and particularly attempts to minimize the impact of packet re-transmission to cater for errors. This work began under LTE and was continued with 5G NR (New Radio) through methods such as automatic repeat request (HARQ) and partial re-transmission (RTX) of the error packet.
These, however, proved not quite good enough for the most time-critical applications, leading to development of three mechanisms to combine the required low latency and quality without excessive over provisioning of network bandwidth. Firstly, efforts were made to ensure that resource allocation was optimized as far as possible to achieve the required level of latency and QoS, to avoid unnecessary cost. Secondly, efforts were made to reduce the probability of packet errors so as to minimize the amount of re-transmission needed. Thirdly, transmission of URLCC packets can be prioritized over packets generated by other services at a given time.
This last part is perhaps most critical and has received greatest attention, not least because of the obvious desire to avoid prioritization of URLCC imposing too great a handicap on other services. The 3GPP defined two scheduling schemes to suit different levels of URLCC urgency – instant scheduling, and reservation-based scheduling. Instant scheduling immediately interrupts any ongoing data transmission to transmit URLCC packets, with the risk of seriously degradation to other services. Reservation-based scheduling is far less disruptive and is divided into two options, semi-static and dynamic reservation, both using a dedicated frame to help facilitate the booking. This can be a good compromise, but imposes overhead and risks wasting a reserved slot if the URLCC data is not transmitted for some reason.
For applications to meet their latency budgets they must dovetail with these underlying mechanisms that come with 5G. This is a two-way street because the higher level mechanisms can impact operation of 5G, especially need for packet re-transmission. This is often the case with the WebRTC protocol, developed to minimize latency for web-based interactive streaming applications such as conferencing and gaming, where low delays are desirable. It enables delivery and playback via standard web browsers without need for plug-ins or dedicated video players.
WebRTC differs from protocols developed around the Internet TCP protocol for on-demand video services that are less time-critical. This is the case for Subscription VoD services from the likes of Netflix and Hulu that buffer video a few seconds to avoid video freezing in the event of network congestion or excessive numbers of errors. TCP corrects for dropped or corrupted packets by re-transmitting them upon receipt of a request indicating they did not arrive at their destination correctly.
Various video streaming protocols, notably SRT (Secure Reliable Transport) and RIST (Reliable Internet Stream Transport), evolved to improve on TCP in various ways, such as imposing time limits for arrival of resent packets. These reduce latency sufficiently for live video streaming but still rely on re-transmission to correct errors and so are not fast enough for the most demanding interactive applications dependent on fast two-way communications. That is where WebRTC comes in, although that has been deployed by some service and network providers for general video transmission.
CDN provider Limelight Networks, for example, uses WebRTC for streaming live video with the aim of minimizing delay associated with its network, but this is probably overkill for one-way streaming. However, it enables Limelight to address use cases such as interactive advertising and gaming, possibly also e-sports streaming, involving two-way communications, where WebRTC comes into its own. The aim here is to address a variety of use cases for varying levels of low latency with a single platform. MNOs may find this would involve unacceptable levels of overprovisioning and so want to deploy flexible networks that cater for different use cases with varying latency needs.