TM Forum Community

Maybe this isn’t an either or question?

ETSI MANO approach appears to accommodate both requirements and is coming from bottom up and a traditional detailed management approach.

The TM Forum Catalyst report IG1128 Dynamic Control Architecture for Managing a Virtualized Eco-System R16.0.1 concluded that to handle volume, velocity of management for virtualization that one needs to move to an intent / network service (NS) based management approach using autonomic computing techniques that using closed control loop methods to achieve defined NS SLAs targets.

The ZOOM project approach is clearly defined in TR262 Hybrid Network Management Platform Blueprint R16.5.0 which leverages our Open APIs and DPRA/DSRA Platform approach.

This is defining a set of abstracted intent based network services (horizontally layered and vertically segmented) that can be realised internally in different ways thus allowing vendor innovation be supported. The current focus is to enhance the Information and data model of existing Open APIs to support these deployment scenarios.

This aligns with the SP challenge stated in the AW Lisbon presentation by Lester Thomas on Vodafone Ocean slide #5 and #8.

My understanding of ECOMP is that it realizes the NFVO Functionality and intends to directly connect to VNFM and VIM managers, so that favours option 2.

The key question is what the North bound OSS functionality of the exposed management interfaces to NFV should be and how this is is integrated with other technologies including legacy ( where there are already deployed solutions that won’t change but could be wrapped using the DPRA/DRSA Open API platform approach -which is what several SPs have already done.

It would be good if you could join the ZOOM HIP team calls on Wednesdays 14:00-16:00 GMT as your implementation insights would be most valuable to progressing this practical work.

In our experience of this discussion with Service Providers, I think that Dave's comment that this isn't an "either or question" is correct. It depends very much on the provider’s current status/approach. For example, we’ve delivered services that are purely virtual, with no interaction to legacy equipment but we also have the conversation that talks to “ring-fencing” legacy tools to allow the transition to a completely new OSS toolset. The first approach treats the management question almost as a greenfield site, whereas the second acknowledges a transition period/ approach.

We generally see that SPs have a current OSS stack that can address current operational models, but cannot adapt to the volume and velocity of the virtualised world for new services (to Dave’s point in his second paragraph). Delivering a closed loop automation requires that the OSS toolset for the virtual environment (vOSS?) operates a near real-time assurance model, taking and understanding data from the virtualised infrastructure and automatically interacting with provisioning and configuration tools within the virtualised environment to address actions required to support the service (addressing component failure, performance degradation and so on). This vOSS can then interact with the traditional OSS that is still managing the classic physical infrastructure at a speed that the traditional tools can accommodate (which generates the question in Dave’s his last but one paragraph).

It could be said that the diagram represents a purely virtual environment, with the box labelled OSS/ BSS actually representing the vOSS (containing unified assurance functions such as event/ FM, PM, topology, e2e SLM and automation) while there is another, legacy OSS sitting outside this diagram managing the legacy i/f, which will remain but reduce in relative scale, as we transition over the coming years.