The LSO Operational Thread describes the user stories of LSO behavior as well as the series of interactions among management entities, helping to express the vision of the LSO capabilities.

High level Operational Threads describe the user stories of LSO behavior as well as the series of interactions among LSO management entities, helping to express the vision of the LSO capabilities. The interactions described within each Operational Thread address the detailed involvement of the Interface Reference Points in the LSO Reference Architecture.


Designing and Launching a New Product Offering

The Service Provider identifies the need to introduce a new Product Offering. The requirements of the new Product Offering are determined and associated Product Specifications defining the product details are created. The Product Offering is mapped into the supporting Service Specifications. New Service Specifications are also created if needed. The Product Offering is added to the Product Catalog and made available for potential Customers.

Partner On-boarding

The Service Provider begins a business relationship with Partner providers. The Product Offering capabilities of each Partner are shared with the Service Provider, along with any associated billing information and quality objectives. Rules guiding the business arrangement with the Partner may be codified within Policies. The Service Provider may also map Service Specifications for Service Components to the Product Offerings available from the Partner.

Product Ordering and Service Activation Orchestration

This Operational Thread addresses the orchestration of activities associated with product ordering and service activation within LSO for a Connectivity Service within the Provider domain and also addressing any Partner domain provided portion of the Product Instance. The Customer browses the Product Catalog and selects a Product Offering to order. LSO fulfills the order by selecting, assigning, configuring and activating the appropriate Services and associated resources that support the ordered Product Instance. Service activation testing may be performed to verify proper configuration.

Controlling a Service Instance

The Customer initiates a request to dynamic control a permitted aspect of its Service (e.g. bandwidth change or implementing traffic filtering controls, etc.). In the Service Provider domain, LSO uses the defined service constraints and policies to determine if the dynamic control request is permitted. If the dynamic control request needs to be supported by a Service Component within a Partner domain, LSO coordinates the changes needed to support the request with the Partner. In addition, LSO effects the necessary changes within its own domain to service the request. The Customer is also informed about the status of the request.

Customer Viewing of Performance and Fault Reports and Metrics

The Customer wishes to view performance and fault information related to its Product Instances and associated Services. In the Service Provider domain, LSO may receive fault and performance related information about each Service Component. This information is used to determine the overall performance and status associated with the Customer’s Services and Product Instances. LSO gathers the information requested by the Customer and assembles it into a report. The Customer may also request that reports be generated on a scheduled or exception basis.

Placing and Tracking Trouble Reports

Trouble Reports related with the Customer’s Product Instances and Services may be placed by the Customer. In the Service Provider, LSO gathers and uses trouble and fault information related to the Customer’s Product Instances and Services and associates it to the Trouble Report. LSO would also attempt to remedy the reported trouble by reconfiguring, reassigning, and / or rerouting aspects of the Service. LSO also indicates if manual intervention is required to resolve the trouble, and tracks the status of any associated repair activities to help determine trouble resolution status. The status of trouble resolution is reported back to the Customer.

Assessing Service Quality Based on SLS

The Service Provider needs to determine if the SLS for a Service is being met. Service quality is analyzed by gathering the necessary service performance related measurement and comparing these service performance metrics with the service quality objectives described in the SLS.

Collection and Reporting of Billing and Usage

The Service Provider gathers relevant usage measurements and usage events in order to generate and provide a bill to the Customer. LSO collects usage measurements, traffic measurements, and service-related usage events (e.g., customer initiated changes in service bandwidth, etc.) describing the usage of Service Components and associated resources. This information is correlated to specific Services and Product Instances. The appropriate business applications perform rating and billing based on the usage information and business rules. Where Service Components have been used beyond their SLS commitments, exception reports may be generated. Note: Partner domains may also be involved in reporting usage and generation of billing information.

Securing Management and Control Mechanisms

The Service Provider needs to provide security for its management and control mechanisms. In this Operational Thread, LSO manages controlled access to management and control capabilities, including authentication, authorization, and auditing within LSO and with Partner and Customer domains.

Providing Cloud NaaS Services

The Customer Application Coordinator in the Customer domain manages the various service needs of the cloud based applications it is supporting. It may determine that additional capacity is needed between two data centers in order to provide for the demands of the applications. The Customer Application Coordinator interacts with the Service Provider to control the bandwidth of the Connectivity Services between these two data centers.

Related and Further Reading






Source(s) and Reference(s)