“Architecture is destiny” is one way of looking at the ways networks are able to support--or not support--particular use cases. Coverage, latency and capacity always are key issues. So one reason low earth orbit satellite constellations are important is that such constellations potentially change architecture, changing latency and capacity constraints that traditionally have been architectural constraints for use of satellite networks as point-to-point networks.
On the other hand, one-to-many use cases are the classic advantage of broadcast networks (TV, radio, satellite broadcasting), in terms of efficient use of capacity. It is hard to beat the cost per delivered bit advantage of any multicast (broadcast) network that is optimized for one-to-many broadcast use cases.
On the other hand, architecture also shapes other potential use cases, beyond the matter of bandwidth efficiency.
Geosynchronous satellite networks have round-trip latency of about 500 milliseconds. That means geosynchronous satellites are not appropriate for real-time apps that require low latency (less than 100 milliseconds).
Where neither latency nor bandwidth is a particular concern, however, most two-way networks could find roles in supporting sensor communications, which are almost-exclusively many-to-one (point-to-point, or sensor to server).
In other words, most two-way networks (not TV or radio broadcast networks or simple bent-pipe uplink networks, including satellite networks supporting TV distribution) can theoretically support some internet of things and machine-to-machine sensor networks.
Many of those apps are not latency dependent, nor do they require lots of bandwidth. Instead, the key real-world constraints are likely to be sensor network element cost and bandwidth cost (cost to move Mbytes).
That, in fact, is the battleground for mobile and low-power wide area networks. The argument has been that LPWANs could move sensor data at far lower cost than mobile networks, in addition to having a transponder cost advantage. Some note that is likely to change over time, with cost differentials narrowing substantially, if not completely.
One way to describe the unique role for 5G is to say that 5G will have unique advantages for real-time apps requiring ultra-low latency or ultra-high bandwidth. Autonomous driving is a good example of the former use case, while augmented reality and virtual reality apps are good examples of the latter, requiring both ultra-low latency and ultra-high bandwidth.
Mobile cloud-based enterprise apps might be an example of new use cases where ultra-high bandwidth is a requirement.
The point is that 5G and IoT use cases will hinge--as all apps running at scale do--on the architectural capabilities of various networks and the cost of communicating over those networks.
Non-real-time apps of any bandwidth can be handled by any number of networks. Content distribution arguably can be supported by both point-to-point and multicast (broadcast) networks.
But ultra-low-latency apps or ultra-high-bandwidth apps arguably require 5G (advanced 4G might work as well).
Low-bandwidth sensor networks arguably can be supported by almost any two-way network in a technology sense, but might vary based on cost-to-deploy and cost-to-use dimensions.
High bandwidth uplinks will work best on bi-directional networks with lots of capacity in the upstream direction, when such networks operate at scale. So long as actual demand is low or highly distributed, more networks could work.
No comments:
Post a Comment