The best place for open networking is where it was never closed. Any network initiative that requires a write-down of existing technology, retraining of staff, and acceptance of new risks, faces considerable executive skepticism. That’s why we may be seeing the dawn of real open networking in two different developments, one relating to O-RAN and the other to open IoT.
O-RAN stands for “open RAN”, of course, and it reflects the common operator fear that vendors will create closed ecosystems to support new services, locking them in for the long term. The solution to that is to mandate technology that’s componentized and connected via standardized APIs and interfaces, which is what O-RAN offers.
From a vendor perspective, of course, it’s hard to beat a good, closed, ecosystem—unless your competitor is the one who has it. It’s therefore not surprising that the first major 5G vendor to offer an O-RAN product suite is Nokia.
Nokia today is the end result of the consolidation of three companies, Nokia, Lucent, and Alcatel. Anyone who’s ever studied large-company M&A, particularly in a highly conservative technology market, knows that the restructuring of organizations and personnel takes years, and that many of the best and most innovative people are lost, having decided to seek their fortunes elsewhere. In fact, one of my long-standing friends, still at Nokia, says that “consolidation made three conservative organizations into one more conservative organization, when it was conservatism that drove the need for consolidation in the first place.”
The point is that Nokia isn’t the leader in 5G and isn’t going to overtake the firms ahead of it (Ericsson and Huawei) unless it does something radical. The obvious radical thing would be to bust open the 5G ecosystems of competitors by promoting an open model. It’s hard for operators to argue for proprietary in the face of openness, and even if Nokia’s competitors argue they use/have open technology, it’s hard to argue that in the face of a specific O-RAN commitment.
Which Nokia has now made. I don’t agree with the point the story makes about operators and governments “demanding” O-RAN, but there’s certainly that long-standing fear or lock-in, and certainly a value in exploiting it. Since there is absolutely no reason why an O-RAN network wouldn’t be as functional as that of another model, openness is a benefit that brings no cost, providing that there are alternative vendors for the open framework. There are plenty of vendors in the O-RAN alliance, including all the major network vendors (outside the mobile space!) and the major IT players, but that doesn’t guarantee the availability of alternative vendors. There are three problems that concern operators.
The first problem is that an “open RAN” isn’t the same as “open 5G”. O-RAN can break a proprietary RAN logjam for operators, but there’s still the question of the rest of the 5G infrastructure, and in particular, 5G Core. Nevertheless, it’s clear to operators that there will be many sources for 5G Core implementation, and so they think it’s the RAN that keeps them from creating a fully open framework.
The second problem is implementation within O-RAN. Operators tell me that fewer than a third of the vendors in the alliance actually offer an O-RAN-compatible element. Many of the vendors in O-RAN are there to promote broader competition and participation in 5G, supporting the initiative financially and with technical resources, but not actually committing to implement an element of the architecture. It’s therefore difficult to say, at the moment, just how many O-RAN elements will have multiple sources. Operators hope this will change over time.
The final issue is integration. All open strategies tend to founder, at least to a degree, on the rocks of integration of the open elements into a cohesive system. “Someone to watch over me” should be the official theme song of the operator community; a single vendor is a single point of responsibility, but a community of vendors is an invitation to a circular firing squad. Better get an integrator, but who should that be?
Nokia likely sees themselves as being a candidate. Right now, its O-RAN strategy is to build a Nokia 5G RAN on O-RAN interfaces, not to include any of the small number of potential partners it could draw from the alliance. In the long term, that’s not going to fly, and Nokia knows it. What it’s working to do, so I hear, is to sign up partners and build use cases that will both validate the open claims and protect Nokia’s own products. The future of O-RAN may depend on how Nokia does at this complex juggling.
The other open initiative comes from the operator side, from Deutsche Telekom, and it claims to be the world’s first open IoT network. The central concepts are the IoT Hub, which is just what the name suggests, and the Cloud of Things, a platform for the execution of IoT applications.
The hub provides a central integrating piece that provides for workflow through the various and diverse elements of an IoT ecosystem. The goal is to make access to IoT information as device-independent as possible, and to allow easy integration of data processing and application components to the device framework.
The Cloud of Things is the potential revolution here, but just how revolutionary it might be is hard to assess at this point. My problem with the way it seems to be aimed is that where IoT should be based on an “information-as-a-service” concept, the Cloud of Things seems to focus instead on the “things”, making it device-centric. Even if you presume that the devices are “virtualized” and mapped (via the IoT Hub) to a standard information exchange framework, you’re still diddling with devices.
There are certainly some IoT applications that require specific device awareness. If you want to open a gate when an access sensor is triggered, you obviously have to know which sensor is associated with which gate. In general, I think, “private” IoT applications can almost always be made to work effectively with at least a modified form of a device-centric approach.
The problem comes when you want to collectivize. The broader the scope of distribution of sensor data, the less likely it is that the exchange should be made directly between sensor and user. There’s a problem of overloading sensors with access requests, a problem with security, and a problem with duplication of interpretive logic. The latter means that if there are five applications that need sensor information, it’s likely all five would perform similar analysis on the data before actually doing something with the results.
IoT information-as-a-service (IoTaaS) would create a kind of middleware layer between sensors and applications, exposing not the direct sensor information but relevant IoT information that might be collected from multiple sensors, interpreted in various contexts (correlation of different sensor trends, historical analysis of a single sensor trendline, etc.). Applications would generally consume the IoTaaS services, enhancing sensor isolation and security.
I think the Cloud of Things could build this kind of framework, but there doesn’t seem to be any expressed intent to do that. The questions, then, would be whether a service-centric vision is needed, and whether it could be added later on.
I’ve said many times that I do not believe IoT can succeed if it doesn’t convert sensor and controller behaviors into services, abstracting the information and capabilities from the actual devices. The problems with IoT security and governance are almost insurmountable where direct sensor/controller access is provided, particularly where sensors are shared among a community of users. I also think that since IoT is in its infancy, it’s hard to predict how far it might evolve, and how fast. Abstraction could protect application components from changes in the hardware.
Without service-centricity, the Cloud of Things isn’t really much different from the Internet of Things, as far as the “things” are concerned. It would then be left to DT to somehow validate their platform to developers based on a much narrower value proposition, and a greater risk to regulatory intervention based on privacy concerns or sensor manipulations.
The question of whether Cloud of Things could become “Service of Things” is more complicated, because it seems likely that an application ecosystem or framework like that would require broad industry acceptance. At the high level, then, the question is whether DT would have the influence to drive the market toward any sort standard. The next question would be whether a Service of Things standard driven by DT (an operator) would end up the same place that things like NFV have. A five-year slog to indifferent acceptance isn’t going to look attractive to software companies.
It may be that the best outcome for the Deutsch Telekom initiative is that it drives competitive efforts, particularly from the open-source community. A Dell/VMware or IBM/Red Hat could breathe some fresh air into the concept, and as a bonus would surely align it with broader cloud initiatives. A Cloud of Things has to be a cloud, before the “things” will matter much.
I think these open initiatives demonstrate two things. First, there is an inherent appeal to open approaches to new technologies and opportunities. People want to believe that they’re not being locked in or gouged for excess profits. Second, wishing won’t make it so. If broad appeal is the driver for openness, then blowing kisses and erecting attractive billboards will do wonders for those who want to claim the benefits.
An open field is probably essential for the growth of open networking, but it’s a necessary condition not a sufficient condition. Effective exploitation is still needed. The real opportunities in these spaces exist, the real values are clear. The real winners may still be waiting in the wings.