The trend towards hosted services and the return of the intelligent network create risks of dependency even if well-intentioned.

It’s all Cloudy

I’m happy to have the option of buying services. It’s easier to eat at a restaurant than to do my own cooking, and I’m happy to pay for a ride rather than fighting traffic on my own. However, I’m not happy if I don’t have the option of cooking for myself or of taking a stroll.

I used to be willing to pay for all of my phone calls but today I know that, thanks to VoIP, there is no need to. But the phone companies are attempting to wrest back control with their wider 5G agenda. 5G may have started as a project to save money on last mile cable but has morphed into a wider political agenda.

This effort to force me to buy services is why I was concerned when I got this response from a company making components which I could use to turn devices on and off:

“As our API is for non-end consumer and supposed to be used by commercial purposes, due to the burden added to the server, we had to charge an annual fee for API requests for our server maintenance and enhancement.

If you are not comfortable with such charge, you may just use the app as an end consumer which costs you nothing at all.”

They followed up by explaining that they had to charge because of the cost of the cloud services. Cloud services? Just to turn on a light inside my house? It doesn’t make sense to have a separate app for each device. Nor should I depend on a third party to integrate the various devices in the way they choose. I should have a say but, more to the point, I don’t want a third party to have to capture the value they are adding—especially when that value is negative.

More to the point, such efforts inevitably fall short. IEEE-1394 (Firewire) is a strong example. I watched as it unfolded and collapsed as it became a victim of its own design limitations.

DLNA is another example. The site says “13 YEARS AND FOUR BILLION DEVICES LATER” but, in practice, few people actually use DLNA to view content. The copyright on the site is stuck in 2017. It’s not that the people designing it weren’t trying their best. It’s that there was no process for people to contribute and share their innovations.

What struck me about the API response was the assumption that services had to be in “The Cloud.” After all, doesn’t it? Of course not. The cloud is the ability to provide resources on demand. The idea is not new—half a century ago it was called timesharing.

The cloud has another purpose. The limitations of IPv4 meant that all the devices in a home share a single IP address. One technique for making them accessible from outside the house is to have an outbound tunnel to a server which can then connect back to the device. This is a workaround in the absence of IPv6. It’s an expedient engineering kludge that has turned into an opportunity for recurring revenue. It’s similar to how the NAT (Network Address Translator) has become the firewall because it created addresses that weren’t publicly visible.

I was thinking about this in reading the March 2019 issue of IEEE CE Magazine and coming across an article on 5G.

I’ve written about 5G in the past. 5G is what I refer to as marketecture—it’s like systems architecture in engineering but is more about marketing than engineering. We see this when the cloud is treated as a given that one possible engineering solution or service platform.

The article itself is a perfectly valid technical article about a particular radio technology, but that technology is presented in the context of a broader agenda of clawing value back from our devices into the network. As I wrote in “From Broadband to Infrastructure”, we actually create these services in our own devices.

The article comments that “MBOFDM efficiently manages limited bandwidth and has become the most useful signaling technique for this purpose.” That’s like saying there are a limited number of inches.

The article then goes on to present a rationale for this approach by presenting applications such as vehicle to vehicle communications. This is part of the larger 5G marketecture justified by the supposed need for very low latency connections for remote virtual reality as one example.

There is an interplay between real engineering and marketecture. The engineering is typically done in the context of a product requirement. Broadband connections to the home were seen as a way to enable cable and phone companies to offer a bevy of valuable services such as e-commerce, interactive TV and even access to the new World Wide Web.

It’s all about Context

Engineering is about context. We need to be careful to avoid confusing our abstract models with context. Claude Shannon’s theoretic models are a very good example of what can go wrong when we ignore context.

Shannon used the term “information” in describing the carrying capacity of channels measured in bits per second. He did the research in the context of a phone company that was transitioning from analog signaling over a wire to digital encoding. This made it seem as if he was describing a limit to how much information you can communicate over a given band of spectrum (a virtual channel). However, his use of “information” has nothing to do with the day-to-day sense of information as “meaning.” This becomes obvious when we try to measure the amount of information in a pause or, more to the point a pregnant pause. No bits are being transmitted yet there is a world of meaning, and they are two different kinds of pauses.

It is in effect a mistranslation that underlies today’s public policy. It puts a third party in the middle of every conversation. At the time of the Communications Act of 1934, it seemed necessary to allocate an analog channel, AKA, a wire, to each conversation. Later this was emulated in the intelligent network (SS7) that pre-allocated a path to assure that each conversation had a clear channel.

Voice over IP is a counterexample. It works very well without pre-allocating a channel but instead takes advantage of any available opportunity. The meaning, and thus, the value of the conversation, is entirely outside the network. It also means there is no inherent scarcity because we’re not pre-allocating resources but instead adapting dynamically to what resources are available.

Communications engineers need to be aware of the context. Improving the capabilities of radios is very useful, but the term “5G” has a lot of baggage beyond radio technology. In order to fulfill the promises of guaranteed capacity over any distance, we need a provider who can pre-allocate channels. This means that a provider can charge for reserving network capacity. The full 5G vision includes concepts like sharding (selling off capacity to the highest bidder).

Amazon’s AWS, Microsoft Azure and many other services share the common Internet. But 5G embraces concepts like Network Virtual Functions. NVF which is based on the idea that services should be hosted inside the network. Such hosting comes at a price and limits innovation.

Network engineers need to be aware of this broader context and be careful about confusing the marketing and business agenda of their radio technology with the effort to capture value in the network.

In the same way, those doing IoT or “Internet of Things” devices need to recognize that the traditional embedded system designs that depend on their own network are missing the “I” in IoT. The power of the Internet comes from the ability to use any available path between two endpoints and the ability to adapt to capacity available including, at times, no connection between the endpoints. Any capacity added, benefits all applications.

Which brings us back to the cloud. Having abundant server capacity available is wonderful, but it makes no sense to have simple local functions fail. For example, when turning on a porch light, it makes no sense to have the light switch fail if someone doesn’t renew a subscription or if a distant server fails.

This is not a theoretical concern. Circuit City DivX DVDs required a license to play. Your player would connect to their services to authorize each play. When the company went out of business, the discs stopped playing.

Rediscovering Local

I was about to type “edge” but the edge of what? There is no well-defined “network” but rather the facilities we use to interconnect.

Sound engineering starts with assuring that local devices can continue to operate even if other services aren’t available. We can enhance capabilities using services such as those cloud servers, but your doorbell and HVAC need to work even if you’re disconnected.

Local can still be powerful. For example, I’ve been using light bulbs and switches from a Bulgarian company. Their switches and even light bulbs have built-in web servers. Using their cloud is an option but not required. It is local-first and easy to connect.

Yes, I know the company is not local. What is important is that the devices don’t depend on connecting to their services.

Feeding Back

Figure 1: The Shelly SwitchFigure 2: The Web page inside the switchOne kind of engineer just implements as specified and doesn’t ask questions. But context matters.

When I was doing home networking, I had an idea for how to use the phone wires to do networking. When I asked an engineering company to implement it, they listened to what I was asking for and gave me a different approach that did a better job in achieving my goal.

5G’s mmWave radios are a case in point. In themselves, they are a fine technology. But in the context of 5G, they are problematic when used as part of a broader agenda to push back on the Internet’s threat to the revenue streams of today’s phone companies, AKA telecommunications providers.

Scientists and engineers need to present applications scenarios in order to get funding. They need to be aware of how these stories are used in the context of justifying business practices and public policies.

Consumer Electronics and IoT

Today interconnecting things with computing capabilities, AKA, the Internet of Things, is very exciting and powerful going far beyond the old days of component Hi-Fi. But we won’t be able to get the full benefit if we accept the idea that they will only work if we have remote services and communications providers.

Today’s regulatory system has given telecommunications companies control of the paths between distant endpoints. While they once prided themselves on being stewards of our vital ability to communicate, today they are businesses who see the open connectivity as a threat. We must be wary of any efforts to disadvantage WiFi as a way to encourage, and sometimes require, the use of their billable services.

It’s not enough to understand the engineering. Context matters especially when used to justify public policies that limit our ability to innovate.

A version of this post was originally published in the IEEE journal.