By Mark Gibson, Amdocs
Metro-Ethernet activation involves much more than just turning up the connectivity – it’s also about turning up the support and active-monitoring functions of the service (such as fault management) to ensure MSOs can track and monitor the service over time once it’s live – and that’s not something that’s easily performed manually.
Activating a service on DOCSIS might not be simple but at least it offers a standard interface. On the other hand, Ethernet – partly due to its ubiquity – shows up across a range of equipment type, from optical switches to edge routers, each offering a variety of provisioning techniques.
It used to be a choice of TL1 or command line interfaces, but now these are augmented by YANG, XML/SOAP, MTOSI and a plethora of other methods, each aligned to a domain-specific standards organization. And as if this weren’t enough, modern Ethernet services are expected to come with active reporting on the health of the connection, giving in-life updates. In fact, frequent configuration of the monitoring actually results in more commands than the service itself.
If a network is to operate flexibly and support the rate of rapid service change that MSOs want to offer customers, automation is crucial. In a world where customers can press a button to change their service bandwidth, it’s unacceptable that this should result in a network engineer typing commands.
This paper shows how activation must be driven from a service design that reflects both the connection, monitoring, and operational KPIs for the service so that the whole life cycle is activated.
It also shows how linking a service design to command generation enables quick command generation and removes human error.
Referencing a variety of customer use cases, the paper explains the required features of an Ethernet activation system for a digital customer experience, and also shares Amdocs’ new initiatives in MEF to harmonize network provisioning and reporting.