While public clouds delivered the flexibility and liberty enterprises required to execute DevOps, telecoms have, in the past, relegated network admins to static carrier services, preventing the latter from scaling connectivity to meet real-time application demands.
Thankfully, more telecoms deliver software-defined networking and network function virtualization solutions today than they did several years ago. While these technologies give DevOps participants the control they desire, the manner in which telecoms structure SDN and NFV services doesn't complement modern consumption habits.
For the most part, telecoms' OSS and BSS functions aren't designed to support the flexibility SDN and NFV provide. How can they adapt their customer-facing operations to do so?
Restructuring the customer service
Effectively delivering SDN and NFV services requires a comprehensive, detailed view of each customer's network consumption activity. This perspective operates as a two-way portal: While enterprise users can control their network and network service functions, telecoms track those actions to keep their OSS/BSS informed.
Think of this viewpoint as a two-way "Pane of Glass" system. From the customer's perspective, network administrators can see all of the services the telecom offers and scale consumption according to operational demands.
For example, suppose a developer added a function to an application hosted in Azure. The funciton allows remote factory devices to send more data to the cloud. After adding a few more servers to handle more data frames, the developers log into the SDN/NFV portal to add network capacity, thereby reducing latency.
Adapting OSS/BSS to SDN/NFV workloads
Enabling enterprise customers to scale northbound resources as needed compels telecoms to restructure their OSS/BSS capabilities accordingly. Below the "Pane of Glass" lies an API engine that:
- Logs dynamic carrier inventory.
- Monitors tickets and service alerts.
- Assigns prices for each service.
- Automates billing by correlating consumption levels with inventory prices.
- Enforces workflow rules and engines.
- Logs events.
- Manages persistent messaging.
Let's revisit the developer working on the factory device application. Once he expands network capacity to accommodate added traffic, the API engine generates a bill that correlates with the customer's consumption rate. On the back end, the engine authorizes and authenticates customer usage based on contractual rules.
Delivering Multi-Domain and -Service Orchestration
Sitting under the engine is a "Conductor" which orchestrates the services across the SDN/NFV system. The Conductor enables the system to utilize multiple OSS/BSS funcitons without confusing those utilizing network resources. This layer delivers the following functions, among others:
- Network service chaining for programming customer-facing SDN/NFV services.
- Service cataloging that enables telecom personnel to create services across multiple domains and providers.
- Data analysis which tracks historical and real-time customer behaviors.
- Policy management for determining how customers consume SDN/NFV services based on enterprise-defined thresholds and protocols.
The Conductor is compatible with a variety of SDN controllers and technologies. For example, customers can use Cisco IWAN, Citrix CloudBridge, CloudGenex or other systems to configure their WAN settings. Overall, the Conductor must be vendor agnostic to empower whichever users they want.
Revisiting the bigger picture, the three-layered approach described here enables telecoms to deliver flexible services without obstructing their billing and management operations. Ultimately, the solution allows enterprise-side DevOps to operate with the liberty they require.
