“I feel the need. The need for speed.”
You’re probably already familiar with the link and quote above. This famous line comes from Tom Cruise’s character, Maverick, in the movie, Top Gun. However, the line also represents the sense of urgency that carriers expect from their modern OSS and BSS solutions. Speed is an important factor for telcos, whether relating to the network performance, the delivery of new products to market, the activation of customer services and more.
The speed of change in the networks
There’s a change underway in the OSS market that relates to speed too. In the past, networks were much more of a set-and-forget proposition than they are today. Once you physically connected a customer, not much changed over the course of a day / week / month. Whether it was a POTS (Plain Old Telephony Service) or ISDN for voice circuits or PDH, SDH / SONET, etc for data circuits, once it was set up, it stayed up.
The speed of change in these networks was relatively slow. The network inventory tools of the time were great at supporting that speed of change. Therefore, the speed of reconciliation, to ensure the inventory’s data accuracy, was also relatively slow. Those OSS / Inventory tools only needed to poll the network once a day or once a week and we’d still be fairly confident that it would be suitably up-to-date to support what it needed to do.
And what these tools needed to do were:
- Network design and planning – for adds, changes and deletes on the network
- Capacity planning – for right-sizing the network to find the right balance between customer expectations and minimising invested capital
- Fulfilment activities – for querying, reserving and allocating available capacity to customer (or network) services
- Assurance activities – for enriching, correlating and identifying impacts that would help network operators to predict, identify and overcome any degradations in the health of the network
Active network tracking
They still need to perform the same tasks. However, there have been a few slight twists in terms of the speed in which they need to operate. Rather than being a once-a-day/week/month reconciliation, there are some aspects of modern networks that require a greater speed of tracking. It’s now considered to be a three-speed reconciliation, being:
- Slow-speed (e.g. the physical network) – there are a constant stream of activities and updates occurring on a carrier’s physical network. Network build-outs, cable replacements, equipment upgrades, “fibre-deeper” modernisations, customer connections, new sites, new resilient links, etc. This passive infrastructure can’t be polled via an API, so reconciliation can only happen via site surveys or design activities (which don’t occur regularly). But that’s largely okay. Despite the volume of change, once the updates are done, each change instance tends to remain in place for months or years without intervention. This is still supported by the inventory solutions of old
- Mid-speed (e.g. the core network infrastructure) – this speed caters for the active network components, the physical network functions (PNFs) like routers, multiplexers and such. Their location, chassis, cards, ports, rack-position, etc don’t change very frequently. However, since these types of assets do tend to have APIs, they are subject to greater configuration change. They support updates to the logical network across use-cases such as customer activations, quality of service configurations, private network setups, and more. The inventory solutions of old can still mostly keep up with this speed of change, largely via once-a-day reconciliation / discovery processes
- Fast-speed (e.g. virtualised networks and infrastructure) – this is where network change becomes far more dynamic. Modern virtualisation techniques spin resources (e.g. virtual machines or virtual network functions – VM / VNF) up / down and perform constant re-balancing of utilisation to ensure greater optimisation of performance versus invested capital. Not only that, but customer services and consumption models are far more adaptive too, with bandwidth on demand and customer usage patterns introducing larger utilisation spikes. Because utilisation is more transient, inventory tools need to be much more aware of current-state, particularly across the fulfilment and assurance activities mentioned earlier. The inventory solution needs to be aware of current resource allocation before suggesting available resources to service orchestrators (fulfilment use-cases). It also needs to be aware of the current hierarchy of resource dependencies to support root-cause, self-healing and other investigations (assurance use-cases). Once-daily discovery / reconciliation doesn’t suffice in this situation. It requires the virtualised network / infrastructure managers to be notifying the inventory platform in near-real-time.
This is where the inventory solutions of old tend to struggle – they struggle with the speed of change, the modelling of virtualised infrastructure and the deeply-entwined, dynamic support of assurance and fulfilment use-cases. This explains why the rise of active inventory is so important.
If your network has the need for speed and you’d like to discuss how SunVizion’s modern suite of inventory and related products can support that need, then please book a consultation with us today.
