End-to-End Ordering and Activation Thread

Owned by Andy Mayer
Last updated: Feb 14, 2018
4 min read

Based on MEF LSO Operational Thread (see: Amendment to MEF 55 – Operational Threads):

For the ONAP Beijing Release: EXTAPI will be mapping to the SDC Catalog API and the SO Service Instantiation API as defined by those ONAP projects. As a stretch goal, EXTAPI will map to A&AI’s Service Inventory API.

Design Time:

  1. VNF Package with VNFD is On-Boarded into ONAP

  2. ONAP designs a service using the VNFD. Design includes Service Descriptor and Service Recipes

  3. Service Recipes are distributed to ONAP components (i.e. SO)

  4. Service Descriptors are made available via the ONAP Service Catalog

  5. BSS/OSS retrieves Service Descriptors from the Catalog: BSS/OSSs -> LEGATO -> ONAP

  6. BSS/OSS builds Products based on Service Descriptors and creates Product to Service mappings



Instantiation Time:

  1. Customer orders Product: Customer -> CANTATA -> BSS/OSSs

  2. BSS/OSSs perform Product to Service mapping

  3. BSS/OSSs analyze Partner footprint aspect of the ordered Product and places the appropriate Product Orders with Partners (and receives Partner commitments): BSS/OSS-sp -> SONATA -> BSS/OSS-partner

  4. Based on a Product Order, BSS/OSS requests Service instantiation (i.e. Service Order) based on Service Descriptor for the Services within the SP footprint: BSS/OSSs -> LEGATO -> ONAP

  5. ONAP uses Service Parameters from the Service Order and corresponding Service Recipe to instantiate the Service.

  6. ONAP designs the Service Components within the SP footprint (some may exist, some may need to be designed and created) including forwarding constructs across forwarding domains and associated interfaces as well as network functions to support the Service, including identification of the External Providers (e.g., access providers) for any additional forwarding constructs and network functions within the Partner footprint. 
    [Note: Determination of Service Components within the Partner footprint may be determined by the BSS/OSSs before the service request is placed or via Partner domain discovery at Service level]
    [Note: ONAP might need to initiate the installation request for hardware (e.g., CPE) and be aware of scheduling and lifecycle of all service components]

  7. ONAP requests configuration and activation of interfaces, forwarding constructs and network functions:

    1. ONAP requests configuration and activation of network functions and forwarding constructs across each internal forwarding domain

    2. ONAP requests fulfillment of Product Orders or Service Requests to Partner for connectivity services including components such as network functions, interfaces, and forwarding constructs across each external forwarding domain. There are two options for such interactions between the Service Provider and the Partner:

      1. ONAP-sp -> INTERLUDE -> ONAP-partner(Guided by policy rules with the service definition)

      2. ONAP-sp -> LEGATO -> BSS/OSS-sp -> SONATA -> BSS/OSS-partner

  8. Each ONAP Controller determines the elements involved and controls the activation of the network functions and forwarding construct across each element: ONAP -> ADAGIO- > Resources

  9. Once the Service Components supporting the Service are successfully configured and activated, ONAP orchestrates Service Activation Testing (Note: can be staggered when more than 2 sites): with each involved ONAP controller (also ONAP-sp -> INTERLUDE -> ONAP-partner for partner components)

  10. When the end-to-end testing is successful:

    1. ONAP synchronizes and activates proactive performance monitoring for the service and components (can be staggered when more than 2 sites)
      [Note: It is possible to address testing failures with policy driven closed loop control]

  11. When all testing is completed (can be staggered when more than 2 sites), the ONAP performs the state change for the Service (per order component) and informs the BSS/OSSs that the service is now active. (note: state changes will be tracked and made available to the customer throughout ordering and activation): ONAP -> LEGATO -> BSS/OSSs

  12. The customer is notified that the Product Instance is ready to use: BSS/OSSs -> CANTATA  -> Customer

  13. Customer performs testing and accepts the Product Instance: Customer -> CANTATA -> BSS/OSSs

    1. E.g., Billing capability for the product assets (note: testing can be staggered); Billing commences





  1. Customer orders connectivity Product: Customer -> CANTATA -> BSS/OSSs

  2. BSS/OSSs perform Product to Service mapping

  3.  BSS/OSSs analyze Partner footprint aspect of the ordered Product and places the appropriate Product Orders with Partners (and receives Partner commitments): BSS/OSS-sp -> SONATA -> BSS/OSS-partner

  4. BSS/OSSs requests fulfillment of the connectivity Service(s) within the SP footprint: BSS/OSSs -> LEGATO -> ONAP

  5. ONAP designs the Service Components within the SP footprint (some may exist, some may need to be designed and created) including forwarding constructs across forwarding domains and associated interfaces as well as network functions to support the Service, including identification of the External Providers (e.g., access providers) for any additional forwarding constructs and network functions within the Partner footprint.
    [Note: Determination of Service Components within the Partner footprint may be determined by the BSS/OSSs before the service request is placed or via Partner domain discovery at Service level]
    [Note: ONAP might need to initiate the installation request for hardware (e.g., CPE) and be aware of scheduling and lifecycle of all service components]

  6. ONAP requests configuration and activation of interfaces, forwarding constructs and network functions:

a)     ONAP requests configuration and activation of network functions and forwarding constructs across each internal forwarding domain

b)    ONAP requests fulfillment of Product Orders or Service Requests to Partner for connectivity services including components such as network functions, interfaces, and forwarding constructs across each external forwarding domain. There are two options for such interactions between the Service Provider and the Partner:

a.     ONAP-sp -> INTERLUDE -> ONAP-partner(Guided by policy rules with the service definition)

b.    ONAP-sp -> LEGATO -> BSS/OSS-sp -> SONATA -> BSS/OSS-partner

  1. Each ONAP Controller determines the elements involved and controls the activation of the network functions and forwarding construct across each element: ONAP -> ADAGIO- > Resources

  2. Once the Service Components supporting the Service are successfully configured and activated, ONAP orchestrates Service Activation Testing (Note: can be staggered when more than 2 sites): with each involved ONAP controller (also ONAP-sp -> INTERLUDE -> ONAP-partner for partner components)

  3. When the end-to-end testing is successful:
    a)       ONAP synchronizes and activates proactive performance monitoring for the service and components (can be staggered when more than 2 sites)
    [Note: It is possible to address testing failures with policy driven closed loop control]

  4. When all testing is completed (can be staggered when more than 2 sites), the ONAP performs the state change for the Service (per order component) and informs the BSS/OSSs that the service is now active. (note: state changes will be tracked and made available to the customer throughout ordering and activation): ONAP -> LEGATO -> BSS/OSSs

  5. The customer is notified that the Product Instance is ready to use: BSS/OSSs -> CANTATA  -> Customer

  6. Customer performs testing and accepts the Product Instance: Customer -> CANTATA -> BSS/OSSs

a)       E.g., Billing capability for the product assets (can be staggered); Billing commences