Automated BSS and OSS models needed for new network operations

Modernizing BSSes and OSSes to transform networks operations would be faster than changing the network itself and would save money before SDN and NFV savings start kicking in.

Editor's note: Part two of our three-part series on the network of the future looks at the need for changes in...

network operations, specifically for upgrading traditional BSS and OSS. Part one of our series looked at the need for changes in network infrastructure, including the possibility of running traffic over virtual wires. Coming soon, part three will address the benefits and challenges of standards in the networking hardware-to-software transition.

What builds a network? Fiber optics, switches, routers -- everything that makes up the equipment foundation, and the future includes more software, servers and data centers. But what really builds a network is money, and the network of the future will be built by generating revenue or creating savings.

While equipment can contribute to both revenue and savings, there's good reason to think the fastest path to the future doesn't lie in equipment. Operations and business support systems are the business foundations of network operators, and BSS and OSS could be the foundation of the network of the future. In a way, network transformation can be considered a network operations transformation instead.

Networks in the future

For more information on how networks of the future could evolve, check out part one of this series, which covers Tom Nolle's views on the future of network infrastructure.

The two main goals for transforming network operations have existed for about a decade:

  1. Create event-driven OSS/BSSes. This means network operators' BSS and OSS could respond automatically to service and resource events. Current OSS/BSSes retain a strong "workflow" orientation that comes from their history of supporting human processes -- the very processes that efficient operations have to swap out for network service automation.
  2. Eliminate service-specific silos at the operations level. Since IP convergence, competition has forced operators to introduce new services faster than operators could modernize the basic design of OSS/BSS systems. As a result, they created specialized operations tools for many of their new services, including databases. The overlap and conflict among these tools are now hampering agility and efficiency.

Agility and efficiency are the keys here, and operators report their current operations tools are neither. Network operators report that they spend an average of 27 cents of each revenue dollar on "process Opex." This means operations processes primarily driven by the relationship between IT tools and workers cost more than capital expenses for equipment take from revenues. Operators also report that new services can take months or years to plan and weeks to deploy -- a disadvantage when Over-the-top providers that don't own and operate networks can plan services in weeks and deploy them in minutes.

Because changing OSS/BSS would be so much cheaper than changing the network, it could proceed faster and at lower risk.

One measure of the importance of OSS/BSS in network transformation is the potential savings in operations expense that reinventing BSS and OSS could drive. Because changing OSS/BSS would be much cheaper than changing the network, it could proceed faster and at lower risk. If the network transformation includes software-defined networking (SDN) and network functions virtualization (NFV), and an OSS/BSS transformation both started this year, the OSS/BSS process would create as much as three times the savings in the early years, while the network transformation wouldn't catch up until 2021. Even then, much of the Opex reduction would come from extending SDN/NFV orchestration and management principles to OSS/BSS.

Envisioning an operations-driven transformation

Think of what an operations-driven next-gen network transformation would look like in four steps.

  1. Services and resources would both be wrapped in software to create abstractions, which are generalized models that are defined not by what's inside them but by what they offer outside. This is called intent modeling.
  2. The abstractions would first be connected to the management interfaces of current network equipment. Plans for this step have already been announced by a number of operators, including Verizon.
  3. Services would be automated by building software tools to manage the abstractions, and through them the legacy devices. This would deliver considerable up-front savings without requiring network changes early on.
  4. Over time, as network equipment ages, it would be replaced with modern SDN/NFV technology that would be even easier to operationalize and more agile to respond to changes.

Inside this abstraction-based modernization technology is the concept of both services and infrastructure as a set of hierarchical models built using a cloud-friendly technology like the OASIS TOSCA (Topology and Orchestration Specification for Cloud Applications) standard. Operators would build services by building models, and service lifecycles would be linked to operations processes through the models as well. As technology changes, the models would simply be linked to a new implementation suitable for the new technologies. This is already part of the ETSI NFV ISG specification, where virtual infrastructure managers bind resources to service elements.

Using models to automate network operations

Modeling is the biggest issue in operations-driven network transformation. Cloud computing suggests two possible ways to automate the lifecycle of software processes: scripts that describe what steps to take and models (intent models) that describe the results you expect. While it's more difficult to create intent models because you have to describe how the intent is realized, script-based models create what's called a "brittle" structure where specific references to lower level resources make it difficult or impossible to create high-level descriptions that won't break whenever technologies, or even vendors, make changes.

New theories are essential in framing the operations transformation, but in the end, networks are changed by product offerings. Vendors have two possible paths to an operations-driven network transformation. One is that BSS and OSS vendors would modernize their offerings to adopt the model-and-event-driven approach. The other is that NFV would extend itself upward and envelop the OSS/BSS processes, since NFV has its own models, lifecycle-and-event-handling, and orchestration of elements. OSS/BSS vendors like Amdocs propose an orchestrated model of operations, while NFV vendors like ADVA, Ciena, Hewlett Packard Enterprise, Huawei and Oracle promise to include operations in their software modeling of services.

As much as it's appealing to think of next-gen networks in terms of next-generation infrastructure, an operations-driven approach offers profound benefits. The first benefit is the low implementation cost already noted. An operations-driven transformation would have a very high return on investment, making it an appealing approach for CFOs. It would solidify service and operations practices quickly, letting operators change infrastructure at their own pace. It would also accommodate continued changes in service and network automation as technology changed. It would forever free operators from service- or resource-specific silos and make the network of the future about services and software, which is probably how it should have been all along.

Next Steps

Using big data to pinpoint potential network problems

How Network monitoring tools provide performance data

OSS/BSS moves toward a software-based model, focusing on user's quality of experience

This was last published in March 2016

Dig Deeper on Telecommunication networking