Last time, we discussed the promise and challenge of content-centric networks. Current events – the WannaCry worm in particular – make one CCN feature especially important: CCNs have heightened security because they can recognize anomalous traffic. This feature is used in some infrastructure networks today to provide an additional layer of security. The key is understanding what normal traffic looks like and intervening when network monitoring detects a departure from the pattern.

WannaCry, for all its scope, appears to be a financial failure. While other ransomware attacks have taken in millions of dollars, estimates of WannaCry payoffs are less than $100,000; it part because it was very poorly coded and well publicized.

Next time may be different, but except for UK’s National Health Service, we dodged a bullet this time. Regardless, security is one of many unsolved problems for the Internet; time-sensitive networking is another.

Time-Sensitive Networks Satisfy a Real Need

The Internet is great at transferring lots of data from any device to any other device at low cost. This is because it shares resources dynamically. Instead of each device holding exclusive access to a narrowband circuit, the Internet pools communication resources.

This means that devices have access to wideband channels on the assumption that they use full capacity on an occasional basis. The key to “fast and cheap” is the episodic use characteristic of web browsing: you load a page and you read the page. While you’re reading, someone else is loading and vice versa.

Video streaming is also episodic: Netflix sends you a clump of traffic, and you play it out. Towards the end of the clump, they send you another clump. And so on.

Networks provision capacity according to typical use, so the network is generally very fast. But network performance on today’s Internet is more prediction than than guarantee. It works well most of the time, but sometimes it doesn’t.

The tolerance to higher-than normal delay is part of the bargain. Unfortunately, high delay doesn’t work for all applications. That’s where time-sensitive networking comes in: it ensures that applications that need low delay can get it all the time.

What Applications Need TSN?

Many Internet of Things applications are time-sensitive, especially transportation systems in Smart Cities:

We live in a world with self-driving automobiles, and reusable self-landing rockets.   Such complex systems of multiple sensors, computers, and actuators form a Cyber-Physical System (CPS).  Some CPSs will operate at scales that will challenge comprehension.  From autonomous platooning vehicle convoys communicating with each other and highway infrastructure, to Smart Cities coordinating resources (avoiding traffic congestion, coordinating parking, reducing emissions and power consumption), to Smart national power grids and beyond.

Just as CCN coordinates consumers of common, replicable information with each other, TSN coordinates users of time-sensitive information that can’t be replicated. Rather than spreading the pain of congestion as today’s Internet does, TSNs prevent congestion by organizing the activities that lead to congestion when they’re unmanaged.

TSN Isn’t End-to-End Networking

The current Internet, with some significant exceptions, is fairly stupid. The network is generally transparent to applications. It manages congestion by randomly discarding packets when congested, counting on applications to slow down as they lose information.

This works well for the web, email, video streaming, and backups. It doesn’t work well for communications and for real-time sensors. TSN requires the ability to immunize certain applications from packet loss and high delay.

This requires two capabilities that have not been parts of the traditional Internet: pre-emption inside the network (immunization) and signalling between the application and the network to identify the need for pre-emption.  Pre-emption and signaling get the job done on private networks without an additional step.

But these features have costs for public networks because low delay is a scarce quantity even in high-capacity networks. One way we allocate scarce resources is to assign a price to them.

Low Delay is Worth Something

Enablers for Critical Control of Remote Devices source: Ericsson

While the ordinary, delay-tolerant application would not be willing to pay for delay immunity on a short time span, other applications are different. High-Definition voice is one such application, and smart transportation is another.

These are both cyber-physical systems. HD voice is driven by requirements of the ear and brain that can’t be changed by the way we code applications. The network has to adapt to the use case.

5G standards are organized around use cases that today’s networks don’t support well, if at all. Perhaps the most challenging is “critical control of remote devices”. CCRD includes remote control of heavy machinery, factory automation, real-time monitoring, smart grids, and remote surgery.

The applications include large, heavy, physical systems that take time to adjust and realign. So the network can’t have too many of its own limitation since the application is so challenging.

Regulation Without Exceptions

In today’s communication landscape, this applications will use separate communications channels, so they would quality as “non-BIAS data services” under the Wheeler Open Internet rules. Splitting applications off Internet pipes in order to satisfy their security or performance characteristics puts us on the wrong side of the thing that makes the Internet special: it takes the application out of the common pool and gives it a dedicated circuit.

Segregating applications from each other is probably always going to be necessary in special cases, but it’s desirable to limit the practice. So here’s a challenge to regulators: let’s work toward reforming our Internet regulations so that 5G uses cases and run over the same facilities as the traditional web, governed by the same regulations as the rest of the Internet.

I think we need the ability to offer virtual services that use software-defined networking to merge and coordinate diverse applications like CCN and TSN over the common Internet resource pool. But the regulatory problem needs to be solved by Congress and the FCC before the new services can become real.