“Those parts of the system that you can hit with a hammer are called hardware; those program instructions that you can only curse at are called software.”
Virtualisation of the network (read SDN, NFV, etc) is a game changer for OSS. To follow the anonymous quote above, most current OSS are great at managing anything that can be hit with a hammer.
Let’s take inventory as the example. OSS are generally good at managing physical devices, physical cards and physical ports. They’re even usually good at managing physical circuits (ie cables). They can also usually manage logical circuits within a single domain, where the hierarchy of logical circuits is known in the way it ties back to a physical circuit. An example is SDH. But the challenge gets greater when circuits go cross-domain (eg an Ethernet service carried over an SDH circuit). The challenge gets even bigger once the network is connectionless and packet-switching predominates.
The challenge gets greater again with virtualisation. Let’s take the example of a set of virtual machines such as virtual routers on a physical router that are running a uniquely customised routing protocol).
There are a few aspects of this scenario that are very difficult for the current OSS to handle:
- Customer “connections” need to be real-time (as opposed to the one-time OSS mapping of nailed up circuits in SDH)
- Traditional OSS rely on fixed objects with fixed hierarchies (eg a device has cards, which have ports) but virtualisation allows operators to build whatever network and object models they wish
- Your network assets are now virtualised so you can no longer rely on reconciliation with physical asset lists like Fixed Asset Registers so the OSS has to support real-time auto-discovery of assets, both physical and virtual
- Network knowledge, and provisioning thereof, must be on a whole-of-network approach, not just domain by domain. Cross-domain tends to equal extremely challenging
- Network operators become programmers so the whole organisation structure of Network / IT / OSS / NMS groups becomes more complex, perhaps converged
- The virtualisation construct supports cloud models (SaaS, IaaS, etc) so the abstraction of the network means that the OSS will need to support access by abstraction levels. An example might be segregating admin access of the CSP’s virtual router from their customer’s cloud-based virtual routers. Slicing and dicing of data sets to manage operator permissions would appear to get harder in a cloud model
- Virtualisation represents fractional use of assets so depending on the product / billing constructs developed by your CSP, your BSS might have related challenges