Thank you to everyone who joined SDxCentral for its latest webinar featuring Oracle and the Rayno Report on lifecycle service orchestration. Attendees were able to learn from Oracle’s design and solution approach for lifecycle service orchestration (LSO.) A network functions virtualization (NFV)-capable and incrementally deployable end-to-end solution was also showcased in the context of business transformations. Following the presentation on lifecycle service orchestration, Jennifer Faulkner and Scott Raynovich kindly responded to questions from the audience that can be found below.
What other organizations involved in developing LSO standards is Oracle working with?
Oracle: The MEF is leading efforts to drive standards for LSO in collaboration with other standards-setting organizations such as the TM Forum, European Telecommunications Standard Institute (ETSI), NFV and ATIS OBF. Standards for LSO are being driven by the business requirements of MEF’s 130 global service providers members with software and network vendors members also providing expertise. Oracle Communications is actively involved in these efforts and is providing expertise in business operations system (BSS)/Operations support system (OSS) as well as standards alignment between different industry organizations.
What’s the difference between LSO and a service provider’s BSS/OSS?
Oracle: While there are many differences between LSO and existing BSS/OSS and operations practices, the key ones to emphasize are:
- With LSO, all activities and systems are “orchestrated”, as opposed to manually coordinated across multiple groups within the service provider, and also with other operators
- LSO is focused on adopting business-to-business API standardization which will allow seamless orchestration of end-to-end carrier ethernet services across multi-technology and multi-operator networks
- LSO is more focused on business agility requirements by providing a more flexible architecture that enables service providers to quickly adjust to new business and technical requirements compared to current 9-month BSS/OSS cycles to support new product offerings
What are some of the potential pitfalls in moving to an LSO architecture?
Oracle: The biggest pitfall for service providers is to attempt to flash-cut to a pure and fully automated LSO implementation in a big bang implementation approach. The danger is that such a project will never achieve business value. Service providers need to carefully think through the right practical migration approach that is most likely to deliver continuous business value over multiple phases.
As a first LSO implementation step, service providers should look at deploying a new core orchestration capability that can orchestrate both existing manual and automated activities. Service providers don’t have to take on unnecessary risk by replacing all systems and automate everything day one.
Oracle: NFV and SDN only promise increased “network” agility. If you don’t significantly increase business and service operations agility, service providers are no better off than before. For example, even though a service provider deploys SDN/NFV, it will take them about 9 months or more to operationalize the addition of each new network functions as they get deployed despite extensive network trails and testing.
Successful LSO deployments will also provide greater business agility, allowing service providers to rapidly deliver new offerings to their market and/or to operationalize new network technologies. It will be important for service providers to understand how to evaluate LSO offers beyond the traditional features and functions review, and automation proofs of concept to ensure business agility use cases are also supported.
What are some of the customer experience use cases that an LSO architecture can enable?
Oracle: The LSO architecture enables several key enhancements in the enterprise customer experience for network-as-a-service, including:
- A seamless experience for all connectivity sites, including those within their service provider’s reach and beyond thereby providing an increased feeling of reach.
- Full order visibility in terms of order deliver status for various components. Order visibility is no longer a black box of engineering
- On-demand network connectivity services leveraging automated processes and on-demand feature/ function modification leveraging NFV.
Perhaps a basic question, but how does LSO fit in with NFV MANO?
Oracle: LSO and NFV MANO are complementary. NFV MANO primarily deals with orchestration for network agility. LSO primarily deals with orchestration for business agility. NFV MANO will often work in a closed loop with the network for managing network functions (NF) across IT cloud infrastructures, performing policy-based scale-up/scale-down of the virtual network functions (VNFs) or services, in support of customer services managed by LSO. NFV MANO may also be triggered by LSO when a new VNF resource (ex: vCPE) or NFV network service (ex: firewall + anti-virus running off of the vCPE) must be instantiated to support a customer order.
How does Network Planning fit into the LSO model ?
Oracle: MEF has not determined this yet. Network Planning is a Network & Resource Management process. Therefore, does it belong within the boundaries of an LSO architecture, or is it part of the LSO ecosystem? Certainly, in the NFV world, the NFV Orchestrator has a key role to play in network planning, a function which, after initial resource deployment, can be handled in a dynamic/automated way (elasticity – resource/service scale-up and down). Lifecycle service orchestration has a different focus than network planning although the two are related given increases or decreases in service demand drives network planning.
I wanted to qualify network planning as both route planning and synthesis. What are your thoughts on that?
Oracle: If route planning is done for establishing a network, it falls in the Network & Resource Management process eluded to earlier. If path computation is implied for customer “services”, then this is the role of LSO and sub-tender domain controllers, depending on the service abstraction layer of concern. For example, LSO would calculate a high level service path identifying the many network domains (which may be internal and cross-operator) that need to be involved to deliver the end-to-end customer service. A Domain Controller would do path computation over a Metro Ethernet access network across all its switches and ports.
Who are some of Oracle’s LSO competitors?
Oracle: Primary competitors fit in 3 tiers:
- Large BSS/OSS software vendors (including network vendors playing in BSS/OSS areas), often encumbered with non-agile legacy technologies, challenged with the new NaaS, NFV and SDN world, but with functional breadth covering all aspects of service providers’ business processes.
- Smaller niche software vendors, good and agile for technical-level service orchestration and usually specialized in specific domains or network technologies. Service providers still need to connect niche solution into an overall cross-domain agile business and service orchestration framework to achieve overall business agility.
- Open source, which effectively relies on service provider internal do-it-yourself leverage/build/delivery/support methodology, versus exploiting commercial carrier-grade agile and configurable platforms.