For any new technology—even one as promising as the Internet of Things (IoT)—to be considered successful, it must generate revenue for the enterprise. So while CTOs are busy experimenting with the puzzle of network elements and protocols needed for IoT integration, the main worry for the CIO of any telco is IoT monetization.
A key consideration in that regard, is whether the B/OSS (Business and Operation Support System) is the appropriate tool for the job—and if so, what changes in the system may be required. In the telecom world, the “IoT effect” will impact the B/OSS domain in four ways:
- There will be a fundamental qualitative shift due to the sheer number of entities (individual devices, interconnections, security permissions, etc.) requiring management.
- Provisioning and control for services will be different.
- Data management requirements will increase dramatically.
- And finally, the inevitable introduction of Software Defined Networks (SDN) will bring a need for a new level of network awareness.
IoT will impact not only the volume of data coming from customers, devices, and transactions, but also the volatility. For example, if a new IoT device—say, a super-cool version of the Amazon Dash Button—becomes available next week, in a month you might have a totally unexpected surge of network elements as each customer installs five, ten or twenty of these “it” devices. To handle this kind of random event, a cloud-based B/OSS with massive parallel processing and easy scalability will be a virtual necessity.
Trouble is, the old way of connecting new devices to telco networks just doesn’t cut it in the IoT era. In the past, when a customer wanted to connect another computer to the local network, it was his responsibility. All the telco had to do was provide Internet access. As IoT devices proliferate, however, this paradigm will no longer hold up. Customers lack the experience to self-provision these devices—and considering that most IoT devices don’t even have a console screen, telcos will lack both the access and the tools to perform remote troubleshooting.
Another problem is security. Leaving device management to the customer basically results in, “I prefer to use the default security settings.” This situation leads precisely to the security mega-problems everyone is so concerned about.
The way out of these problems is to build a software-defined network (SDN) and transfer as much logic as possible to the telco side, in order to simplify provisioning and increase security. Now, instead giving customers a WiFi router equipped with the default access password “admin” and outdated firmware, the device benefits from a virtual, cloud-based Customer Premises Equipment (CPE) process that is automatically configured, constantly monitored, and frequently updated.
But SDNs provide other benefits as well. Instead fighting a network wherein all devices—including some hacker’s laptop—communicate unchecked, each IP flow is verified by an SDN controller. And instead of asking the customer to connect a cable to the IoT-enabled refrigerator and then read through pages of cryptic log messages, helpdesk is there to redirect all the traffic from that device to their side for analysis.
For an SDN to work properly, B/OSS must be capable of automatically and almost instantly delivering service configuration information to the various entities involved: virtual CPE, Network Functions Virtualization (NFV) appliances, SDN controllers, authorization repositories, etc. But imagine trying to organize a task so that it can be seamlessly completed by a large team of strangers from different backgrounds, and speaking different languages—not an easy proposition.
The solution calls for vastly flexible provisioning and data collection capabilities by B/OSS, along with an open framework capable of adding provisioning for new elements. With such a system in place, a telecom operator doesn’t have to wait ten months until the next version of B/OSS is released, just to be able to provision a new NFV appliance that customers are demanding right now. Traditional approaches with separate “operation” and “business development” teams won’t do; they must be replaced by a “DevOps” style team that can natively handle integrations and interconnections.
There’s another factor to address as well. The customer-facing business logic layer speaks in terms of services (e.g., “John has a 30Mb link with unlimited IPTV streaming for his TV, firewall protection for his PC, parental controls for his child’s iPad, and restricted access for his espresso maker to order coffee delivery”), while network elements such as the SDN controller do not know (and do not wish to know) about “John” at all. These elements need configurations to be expressed in terms of IP addresses, flows, and so on.
To resolve this, an additional middleware layer is required that will combine the service information from B/OSS with network topology information, then transform that combined data into the format understood by SDN controllers, NFV appliances and other parts. This layer must either be a part of B/OSS or tightly linked to it, since B/OSS is the telco’s “point of stability”; that is, there may be dozens of independent network elements, but there is only one master repository for critical customer information such as product data and account balances.
Having an appropriate middleware layer in place enables a “software telco” approach wherein an operator’s only real asset is its customer data (in B/OSS), along with the ability to deploy the configuration to services that run in a cloud. Moreover, the telco’s network backbone becomes a commodity resource, leased on demand – and the only remaining competitive differentiators among operators are directly linked to B/OSS capabilities:
- Supported NFV appliances and devices, which define the service portfolio
- Speed with which network applications are added
- Operational efficiency, in terms of service activation and troubleshooting
The bar is clearly set high for IoT B/OSS. It not only has to handle large, volatile volumes of data, but also be capable of scaling easily—something many B/OSS vendors don’t typically accommodate, due to license terms that limit total numbers of customers or objects. It should support automated provisioning to a variety of network elements, and offer open architecture for easy and quick integration with new ones. Finally, it must provide the expanded logic for combining customer service data and network topology information into the actual configuration.
Evolving B/OSS is much more than an exercise in technology. Its adaptation to the world of IoT will increase customer satisfaction, provide competitive advantage and, ultimately, increase revenue and profits. The jump to the IoT era will be most successful if the correct infrastructure is in place; for telcos as well as many other types of businesses, B/OSS should be at the center of the discussion.