IEEE Future Directions
Related Articles
Re-balancing of control between the terminal and the network
The availability of several bands allocated to different frequencies can be leveraged in parallel thanks to the increased processing capability at the terminal side. This capability can allow a dynamic management of the available bands within a single communication stream (more transport links within a single communication sessions). Part of the information stream within a communication session might take place on a band (with its own coding scheme and transport protocol) whilst a different part may flow on a different band with different coding schemes and protocols.
As an example, a car in a urban area might receive information through LiFi (data modulated on the light emitted by LED used to illuminate the road) and use as upstream channel a band at 3.5GHz towards an LTE antenna at a certain location, switching to (or in parallel using) a 95GHz communication towards a vehicle driving in a parallel lane and using it as a network node to further propagate the communication link.
Interesting to notice that the role of band manager can be shifted to the terminal, with the network playing a passive role. As a matter of fact, the terminal is no longer a “terminal”, rather it is becoming a node in the overall network, network that is made up through a variety of sub-networks, each one owned by players independent of one another.
Notice as well that looking down the lane the terminal/node can enact an autonomous choice of resources to set up a call, on the bases of the resources under its control and visibility, with part of them being what we would consider today as network resources.
On this side we have technology enablers that go under the name of SDN/NFV, or in a 5G lingo “Network Slicing”. The goal is to let the terminal, the application, select among the many resources available, both locally and in the network(s), the ones that best fit the criteria (and needs) for the execution of that specific activity. The control shifts from the network to the terminal/application.
In a 5G system the terminal may play a significant role in this selection/allocation of resources, differently from today’s situation where all resources, including the radio ones are allocated by the Operator that controls the access, the transport and the session (OSI Level 4 and 5). Notice that latency, one of the big point in marketing 5G, is not really an issue related to the radio link. In 4G the latency on the radio link can be as short as 3ms, whilst the promised “best” latency for radio link in 5G is 2.5ms. Not a big deal! Latency is the result of several localised latencies through the network(s) that adds up, on average to some 80ms in the 4G system (but it can be as low as 30ms). A gain of 0.5 ms on the radio link over an average latency of 80 ms is just good for marketing … The electromagnetic field propagates at a speed that is independent of the way we are using it… (300,000 km/s, roughly speaking), hence the latency on the radio part and the wired part is only dependent on distance (a transmission between London and New York takes 18ms in terms of propagation of the electromagnetic field, and there is nothing you can do to go beyond this latency…) . A different story is the speed of data transfer, which is what matter to us, and that is dependent on the time it takes to code and decode the data at the various points where data is manipulated in their journey from A to B. Of course this adds up onto the electromagnetic field physical latency and this is where a different architecture may decrease latency.
Hence, a revision of the network overall architecture and more importantly the possibility of network slicing to select those resources and network paths that can have lower latency, could indeed bring down the latency to a few tens of ms (on top of the latency induced by the electromagnetic field propagation).
When marketeers enthusiastically speak of latency below 1ms they tend to forget physics. Working on the architecture and decreasing the number of hops and conversion (particulalry optical/electrical) would surely help. Ensuring a latency below 1ms for vehicle to vehicle communications requires the set up of a network directly connecting one vehicle to the others, getting rid of the need to use a backbone. This latter would introduce delays for the handover of the data from one part of the network to another that immediately will exceed the 1ms. Similarly in the control of robots in a manufacturing plant (assuming that you have to have this short latency) communications will have to be as direct as possible.
