In a recent article on SDxCentral.com they talked about OSS/BSS being the main challenge to successfully implementing NFV and SDN solutions in your network. This is so true, and one of the primary drivers of what we at Itential are trying to achieve with our Application Platform.
Traditional OSS is built around the idea of a very static network, with very static services, built on top of legacy equipment that happily hums along within that paradigm. SDN and NFV introduce a level of dynamic flexibility that I truly believe it is going to turn the OSS/BSS vendors on their heads. If they aren’t already figuring out how to survive this they may be in trouble. The industry is working feverishly away at answering these challenges. Most are struggling with how to introduce a new way of looking at OSS that is counter to how they have approached it in the past. The fact that some are seeing the need to change is a good sign, however many are also just trying to jam the new technologies into their existing systems and declare the battle won. This is just not going to work.
Traditional OSS Inventory, for example, has trouble keeping up with knowing what is installed, what is available for use, which customers or network facing services are assigned to which static entity in the network, and doing so with more than about a 70% accuracy rate. Legacy network changes are much slower than what you will see with the SDN/NFV networks of the future, yet they still cause OSS headaches with traditional solutions. What will happen when your network is constantly changing, services are constantly changing, and customers have control of those changes, meaning they can happen as often and as many times as a customer wants?
We like to talk about Real-Time OSS where you maintain a physical inventory of the network, because those items aren’t going away, and federate that with more dynamic views of what the network looks like from tools like SDN Controllers, NFV Orchestrators and VNF Managers in the SDN/NFV domain, as well as other tools that maintain a more dynamic view of physical elements…including EMSs if necessary. This approach extends beyond a traditional inventory view and into Service Inventories and the associated Service Function Chains that may be defined, both available and in service. As the network becomes “Real-Time” in its ability to adapt and change the OSS has to as well, or risk falling flat on its face.
The answer to not cannibalizing the vendor’s existing revenue streams is not to just cram these dynamic elements into legacy systems, though you could attempt to do that and meet some level of success if you are willing to hire people to keep the system accurate enough to be of any use. Instead, it is to implement this Real-Time OSS layer over those legacy systems, leveraging what they do well, and thereby extending the life of some of those system which are already getting long in the tooth. Consumption of those traditional OSS APIs and then introducing a Real-Time OSS application layer above that to introduce real-time functionality will equal SDN/NFV success.
Similar challenges are going to appear in the BSS domain as well, such as how do you maintain the ability to bill for a service that may not go through a traditional ordering process? How do you maintain billing for services that can be morphed into 5-10 different flavors of what you have now depending on what virtualized functions the customer chooses from an online portal? Does it mean a totally new way of billing? Lots of challenges to be met here based on what the SDN/NFV technology will allow Service Providers to do. This isn’t my area, however, so I’ll leave “Real-Time BSS” up to someone else.
Tags: NetOps