Skip to end of metadata
Go to start of metadata

MSO High-level System Architecture

See the attached presentation for an explanation of the system architecture of MSO, and its interaction with other ONAP components: MSO High-level Design.

MSO Overview

ONAP orchestration arranges, sequences, and implements tasks based on rules and policies to coordinate the creation, modification, or removal of logical and physical resources in the managed environment. The Master Service Orchestrator (MSO) manages orchestration at the top level and facilitates additional orchestration that takes place within underlying controllers. It also marshals data between the various controllers so that the process steps and components required for execution of a task or service are available when needed.

The MSO's primary function is the automation of end-to-end service instance provisioning activities. MSO is responsible for the instantiation and release, and subsequent migration and relocation of VNFs in support of overall end-to-end service instantiation, operations and management. MSO executes well-defined processes to complete its objectives and is typically triggered by the receipt of service requests generated by other ONAP components or by Order Lifecycle Management in the BSS layer. The orchestration procedure is obtained from the Service Design and Creation (SDC) component of ONAP, where all service designs are created and exposed/distributed for consumption.

MSO runs autonomously within ONAP.  

The orchestration engine is a reusable service. Any component of the architecture can execute process workflows. Orchestration services can consume a process workflow and execute it. The service model maintains consistency and reusability across all orchestration activities and ensures consistent methods, structure and version of the workflow execution environment.

Orchestration processes interact with other platform components or external systems via standard and well-defined APIs.

Controllers (Network and Application) participate in service instantiation and are the primary players in ongoing service management; for example, control loop actions, service migration and scaling, service configuration, and service management activities. Each controller instance supports some form of orchestration to manage operations within its scope.

Figure 1 shows the two major domains that use orchestration: service orchestration, which is embodied in MSO and service control, which is embodied in the Application and Network Controllers. Although the objectives and scope of the domains vary, they both follow a consistent model for the definition and execution of orchestration activities.

Figure 1. Orchestration

Depending on the scope of a network issue, MSO may delegate, or a controller may assume, some of the activities identified in Figure 1.  For new services, this may involve determination of service placement and identification of existing controllers that meet the Service Request parameters and have the required capacity. If existing controllers do not exist or do not have capacity, MSO will obtain a procedure for instantiation of a new controller under which the requested service can be placed.

In future releases Orchestration process flows will be defined in the Service Design and Creation subsystem (SDC). These process flows start with a template that may include common functions such as homing determination, selection of Infrastructure, network and application controllers, consultation of policies and interrogation of Active and Available Inventory (AAI) to obtain information needed to guide the process flows. MSO does not provide any process-based functionality without a workflow for the requested activity (in the current release the process flows are designed directly in MSO using BPMN flows).

MSO interrogates AAI to obtain information regarding existing Network and Application Controllers to support a service request. AAI provides the addresses of candidate controllers that are able to support the service request. MSO may then interrogate the controller to validate its continued available capacity. MSO and the controllers report reference information back to AAI upon completion of a service request to be used in subsequent operations.

Application, Network, and Infrastructure Orchestration

As previously stated, orchestration is performed by various components, primarily the MSO and the Application and Network Controllers.  Each will perform orchestration for:

  •  Service delivery or changes to an existing service
  •  Service scaling, optimization, or migration
  •  Controller instantiation
  •  Capacity management

For infrastructure orchestration, ONAP interfaces with the cloud provider's infrastructure control interface. Regardless of the focus of the orchestration, all workflows must include steps to update AAI with configuration information, identifiers and IP Addresses.

Network Controller Orchestration

Network Controllers are constructed and operate in much the same manner as Application Controllers. New service requests will be associated with an overall procedure for instantiation of that service. MSO obtains compatible Network Controller information from AAI and in turn requests LAN or WAN connectivity to be established and configured. This may be done by requesting the Network Controller to obtain its resource procedure from SDC. It is the responsibility of MSO to request (virtual) network connectivity between the components and to ensure that the selected Network Controller successfully completes the network configuration workflow. A service may have LAN, WAN and access requirements, each of which must be included in the procedure and configured to meet the instance specific customer or service requirements at each level. Physical access might need to be provisioned in the legacy provisioning systems prior to requesting MSO to instantiate the service.

Application Controller Orchestration

MSO sends requests to Application Controllers to obtain the application-specific component of the service procedure from SDC and execute the orchestration workflow. MSO ensures that the Application Controller successfully completes its resource configuration as defined by the procedure.  As with Network Controllers, all workflows, whether focused on Instantiation, configuration or scaling, will be obtained or originate from SDC. In addition, workflows also report their actions to AAI as well as to MSO.

Note that not all changes in network or service behavior are the result of orchestration.  Policies and rules (in the Policy subsystem) inform the controller such that the Controller can enable service behavior changes.

  • No labels


  1. Does the MSO configure the instantiated VNF?  Are the VNF configurations stored anywhere? 

  2. "MSO sends requests to Application Controllers to obtain the application-specific component of the service procedure from SDC and execute the orchestration workflow." — Where is the code for this ? App-C adapter in MSO is commented in pom.xml. Is there any other flow for this ?

  3. There is currently no flow that requires any communication between MSO and APPC.

  4. The feature, MSO VNF configuration via APP-C,  was push out of MSO development plan and deferred to a future release.

  5. Hi Sébastien and Gervais-Martial - what do you mean by "no flow that requires any communication between MSO and APPC"? If a VNF needs to be configured automatically, what happens in the current code? I am sure such automation exists in AT&T ECOMP?

  6. "no flow" means "no flow as part of initial requirement feature" at the time of the current MSO release. There is no automatic VNF configuration as part of MSO orchestration. in the current form the VNF configuration would be triggered manually (or automatically by the entity which triggered MSO orchestration).

  7. Hi Gervais-Martial, to my understanding, MSO and APP-C communication will be done through the APP-C adapter. It is not clear which one needs to be implemented for supporting the communication. Is it because there is no MSO workflow for VNF configuration or no APP-C adapter yet? What is the reason it was pushed out and deferred to a future release? 

  8. I am trying to understand where the network connectivity data model resides, whether in MSO, SDC or else. What i am referring to is not just the directed networking graph across the VFCs and VNFs but also the network connectivity data model to external WAN . Where to look for it ?

  9. Working on onap 1.0 - I serve Robot health checks, and the MSO Health check fails on the GET request  (Http status 503 (service unavailable))

    I've tried to investigate it, and tried to navigate to the hard coded MSO_HEALTH_CHECK_PATH argument (as below):

    *** Variables ***
    ${MSO_HEALTH_CHECK_PATH}    /ecomp/mso/infra/globalhealthcheck

    But couldn’t find 'globalhealthcheck' at all, not under the MSO or Robot containers.

    Below is the log I got from the Robot framework

    Any idea?


  10. Hi,

    Is MSO still part of ONAP or is it replaced with Open-O?