The ultra-low latency group of 5G use cases, collected under the banner of URLLC (ultra-reliable low latency communications) has been depicted as a catching-up exercise for wireless communications against wired options, especially fiber.
But it is more than that, because it opens up use cases in autonomous driving and robotics that cannot be served by wired communications anyway. Beyond that, the low latencies in these mobile scenarios will create new possibilities that will require addressing delay bottlenecks elsewhere in the line of processing, especially in data analytics.
This will also play into sectors such as robotics and autonomous driving where almost instant decisions relating to safety have to be made under exceptional circumstances, sometimes in compliance with regulations. In the driving scenario it could be a child stepping out in front of an autonomous vehicle, requiring emergency braking. Alternatively, a robotic cutter might be about to cause injury as a result of human error and require instant shutdown.
Such actions can only be executed quickly enough if latency is also taken out of the data processing and analysis loop, not just the link delay. In theory, 5G will enable latencies down to 1ms with the help of edge compute, and in practice, levels down to around 5ms have already been achieved in trials or early deployments.
The vast majority of industrial applications of cellular to date are based on LTE rather than 5G, but those are rarely cases where the lowest latencies are required – they use latencies down to perhaps 30ms at best, often closer to 100ms. It is true that few processes will require latencies shaved right down to 1ms and evidence so far is that 5G will struggle to deliver it, but ratings of 5-7ms are being achieved in deployments so far by the likes of German airline Lufthansa.
Overall latency of a process or application has many components that can be shaved to varying degrees, but one ultimate barrier lies in the signal transmission time. That can be improved by minimizing the number of nodes along the path where data is processed or forwarded and adopting the fastest medium propagating the electromagnetic waves upon which signals are modulated.
The latter is usually optical fiber but even that imposes a delay of about 1ms per 20 kilometers. The actual total is usually several times that when accounting for amplification, switching and termination, so to deliver ultra-low latencies in the real world, relevant computation has to be distributed close to the edge and certainly cannot be performed in distant data centers a country or even a continent away.
But then the bottleneck is transferred to the application, with an ultimate constraint there being the time to read, write and analyze relevant data that has often just been collected. This is boosting the field of in-memory database processing, avoiding the need to access slower disks. It is true that solid state drives (SSDs), which are becoming increasingly prevalent in servers, are far faster than traditional hard drives that have the higher seek times imposed by a spinning medium. But they are still slower than in-memory processing, because of the access and transfer time.
Access times are typically 5-10ms for hard drives and only 25-50ms, or 200 times less, for SSDs. But there is also channel transfer and caching time to take into account, so even SSDs can make significant contribution to latency for some data-intensive processes. More to the point, in the case of many emerging industrial and other IoT applications the devices requiring rapid processing of data will often be too small to house an SSD, yet require rapid actions to be taken on the basis of data collected and processed locally.
This is spawning database implementations tailored to in-memory execution in resource-constrained devices, an example being the Raima Database Manager (RDM). This is an embedded relational database optimized to run on IoT edge devices where real time response is needed. The company claims that this can serve data for intelligent decisions to be made at the device level within microseconds, fitting in with that sub-1ms latency target.
Such in-memory database processing and analytics has become possible with the sustained rapid decrease in cost of DRAM over many years, leading to a spate of products. There are now well over 200 in-memory database products, ranging from adaptations of long-established relational systems from the big names, to emerging dedicated vendors.
SAP, Microsoft, IBM and Oracle are among examples of the former, along with Altibase, whose hybrid relational open source database management system is worthy of mention. The company’s hybrid approach allows access to both memory-resident and disk-resident tables via a single interface, making it useful for enterprises wanting a single system for mixed workloads and during migration.
It also employs an implementation of multiversion concurrency control (MVCC), which is commonly used to ensure that data reading and writing is consistent within a given time window. The original aim was to avoid someone accessing, say, their bank account viewing a transaction such as a debit while it was still taking place and only half done. But now with parallel processing the objective is also to ensure that the separate read and write processes do not slow one another down more than absolutely necessary, which is essential for in-memory processing.
There are a number of processes that have been developed specifically to accelerate database performance with in-memory implementation in mind. IBM was among the pioneers on this front having developed its BLU Acceleration, a collection of technologies that are still evolving for analytical database workloads, some years ago. Among technologies in this collection are techniques for processing columns of data rapidly with so-called actionable compression to pack data more, CPU acceleration to exploit parallel vector processing, and data skipping to ignore data irrelevant to the workload that is currently active.
Such techniques provide the foundation for ultra-low latency applications that rely on some form of data analytics, as the great majority will. But it will still be incumbent on software developers to ensure that implementations do not impose unnecessary latency that would blow all those gains made along the way out of the water.