Many of us have come to expect constant connectivity.
I don’t mean we necessarily want to be online 24/7, with a screen in front of our face around-the-clock. But, we want to be able to be connected whenever we want, wherever we happen to be.
Constant connectivity.
Most of us have phones that are effectively able to serve as mobile offices, equipped with word processing and other business apps. Personally, I find spreadsheets painful to navigate on my 5-inch screen, but I frequently edit blog posts and documents from waiting rooms or restaurants. We have tablets, computers, smart TVs, smart speakers, thermostats all connected to our home internet. As I write this, my home router reports 33 devices are connected. (I don’t have many of the “smart home” devices that are increasingly commonplace).
On our mobile networks, in addition to our smartphones, we have metering and other forms of telemetry. With home security and health applications, we increase the need for reliability, often using wireless backup for wireline connections. There are many working groups talking about connected autonomous vehicles.
This state of constant connectivity carries with it a variety of implications.
Many applications can be designed to tolerate hiccups in their connections. For example, by their very nature, email messages are transmitted on a ‘store and forward’ basis. A delay measured in tens of seconds or even minutes or hours is somewhat meaningless for most messages. It is silly to be concerned about a sub-second delay for emails or most text messaging. Most streaming video applications are designed to buffer the signal, storing multiple seconds of content on your device in anticipation of possible interruptions. But, what about voice and two way video calling? Delays (latency) of more than a few hundred milliseconds can be challenging for many who are used to virtually instantaneous responses in a normal conversation. We can witness the uncomfortable user experience when foreign news correspondents are having on-air communications with anchors using satellite connections.
What about performance issues with applications requiring non-stop high performance connectivity, such as remote surgery?
Connected vehicles is a category that enables us to understand a wide range of performance requirements, just in connecting a car. What kind of network performance should be anticipated by developers of connected car applications? The performance characteristics will vary based on whether the connectivity is used for navigation, entertainment, diagnostics, accident avoidance, or telemetry for vehicle maintenance (among other applications).
For many applications, constant connectivity may not have to be quite so constant.
Over the past few years, I have frequently referred to the tension between quality, coverage and price in architecting networks. Increases in coverage, or improvements in performance are always possible, but there is a cost associated with each. That cost ultimately would need to be recovered.
Do regulation and policy recognize that not all bits need to be treated the same?
How should variances in technical requirements receive consideration when examining network resilience from a regulatory perspective?
How do we ensure that appropriate incentives are in place to encourage continued investment in networks for improved reach, robust network resilience, increased capacity and more advanced capabilities?