Telstra's Networks for the Future
James Crawshaw, Senior Analyst – Service Provider IT and Automation, Heavy Reading
Telstra is an unusual incumbent operator in that it is in the process of transferring its legacy copper and HFC networks to an Australian government-funded wholesale access provider, National Broadband Network (NBN). While Telstra appears to be doing a good job of retaining customers as they move off its access network to NBN, margins and customer stickiness will be lower. At the same time, Telstra's mobile franchise is threatened by TPG, an MVNO which is now building its own network, competing with Telstra, Optus and Vodafone. (See Australia's TPG Rattles Telstra With $1.4B Mobile Move.)
Understandably, Telstra is actively trying to reinvent itself, preparing for technological change with a focus on five key themes: networks for the future, digitization, customer experience, productivity, and culture & capability. In its half-year results statement in February, group CEO Andrew Penn noted Telstra's "Next Generation OSS platform which is a key element of our network transformation build and we are continuing to invest in this important capability to deliver real-time customer experience monitoring and impact assessment and recovery capability."
We received a briefing from Telstra about its "Networks for the Future" strategy incorporating network-as-a-service (NaaS), which involves a radical redesign of how OSS/BSS communicates with network domains. Telstra's new NaaS architecture provides a master service directory, a selected list of TMF APIs and defines network domains (e.g., transport, IP, access, media, etc.), managed by network and service management platforms, as service capabilities. Alternatively, as Guy Lupo, head of NaaS, Network 2020 Transformation puts it: "The NaaS is an API gateway concept that exposes the capabilities of the network, as a service."
Network management architecture rethink required
Today large CSPs like Telstra have a mish-mash of BSS and OSS systems supporting separate business lines (consumer, enterprise, wholesale, etc.) and technology domains (wireless, transport, media, IP, etc.). Gary Traver, director of Network 2020 Architecture notes, "The complexity of multiple OSS/BSS systems affects both service agility and the traditionally high cost of maintaining OSS/BSS. Simplification enables agility and lowers cost of maintenance."
Much as telcos would like to retire their legacy OSS/BSS, each network resource is so entrenched in these systems that they cannot exit products, services or resources for fear of breaking something. Tight point-to-point coupling between resources (physical and virtual) and management platforms (OSS/BSS) cause increased time to market and exorbitant costs for any addition, modification, or exit of resource, service or supplier.
With virtualization, SDN, cloud and AI, the domain management platforms are becoming more autonomous and less reliant on legacy OSS/BSS. However, telco services are still created with a "what resources need configuring?" approach and operations are still using open loops to manage them. Johanne Mayer, global evangelist for NaaS 2020, argues that "the telecom industry needs a rethink of its management architecture if we want to obtain the level of agility, costs and time to market customers expect us to deliver."
The Network of the Future
According to Lupo, the Networks for the Future architecture will introduce a NaaS gateway function between the OSS/BSS and network service domains. The network service domains are responsible for managing the end-to-end lifecycle of their services supported by both physical and virtual resources, and including service assurance through closed-controlled loops. The domains are also exposing their capabilities and operational functions through TM Forum APIs which are used to communicate northbound with the OSS/BSS. Similarly, they will be used to communicate with third-party ecosystem services (e.g. AWS, Azure) and other service providers exposing their NaaS. Each domain-specific management system must expose its capabilities via a suite of unified interfaces (e.g. configuration & activation, service catalog, service inventory) to achieve a "zero-touch" level of automation. This requires alignment with suppliers of all domains (transport, core, access, etc.) so they expose their capabilities in a uniform way.
The network service domains will take greater responsibility for their own autonomous management, reducing the dependency on the legacy OSS. This includes fulfillment and assurance so that VNFs can self-heal, enabling closed-loop automation. Network service domains will have their own real-time inventory, license and policy management. They will hide their internal complexity from northbound systems through the use of templates (TOSCA, Heat) and modeling languages (YANG).
A win-win for CSPs and suppliers
Traver sees the move to a more programmatic network as a win-win for operators and suppliers. Suppliers can focus on selling innovation and not integration taxes. CSP network teams will benefit from a standardized list of functions they can deliver that are domain independent and reusable for IT or third-party partners. CSP IT teams should benefit from simplified integration and greater agility thanks to the loose coupling between OSS and domains. This could enable easier customization of products and bundles.
Mayer sees the NaaS initiative as a catalyst for change within the company. "Telstra is giving TMF API training to a large number of its engineers so that they know how they need to design, model and expose as a service."
Telstra is not alone in this future network vision. Other operators such as Orange and BT have similar strategies. However, Mayer notes operators cannot bring about this change in isolation but need the support of the entire ecosystem. "We need the telecom suppliers to expose these capabilities in their management platforms. This will enable automation and free up capex dollars from integration taxes to innovation, something the industry desperately needs to stay relevant in the cloud computing era."
For its part, Telstra is contributing to the TMF its NaaS API component suite which spans prospect to order, order to activate, usage to cash and trouble to resolution. Telstra is also contributing its NaaS APIs to ETSI's ZSM industry standards group to enable greater automation between IT and network domains, across network domains and within each network domain.
— James Crawshaw, Senior Analyst, Heavy Reading