Based on MEF LSO Operational Thread (see: D00135_001_Amend MEF55-OperationalThreads AD 1_Mayer.pdf):

Steps

1. Customer browses BSS Level Product catalog and existing Product assets (e.g., existing service locations, existing UNIs, existing Product Instances, etc.): Customer -> CANTATA -> BSS/OSS

2. Customer selects, specifies parameters and gets serviceability and a quote for the connectivity Product: Customer -> CANTATA -> BSS/OSS

3. BSS/OSSs decompose the product into its services and ONAP decomposes the services into its service components
   
   

   a)     BSS/OSSs begin determination of the Product serviceability (e.g., interacts with Billing, selection of Partner products, etc.)

   b)    BSS/OSSs request that ONAP use its topology information to determine components of the service within the SP footprint and within the Partner footprint. BSS/OSS-sp -> LEGATO -> ONAP

   1. An alternative is for the BSS/OSSs to lookup Partnering service options using a Product Catalog instead of topology information.

   c)     BSS/OSSs inquire the SP footprint aspects of serviceability BSS/OSS-sp -> LEGATO -> ONAP

   d)    BSS/OSSs inquire the Partner footprint aspects of the service and interrogate the Partner for Serviceability and quotes BSS/OSS-sp -> SO    NATA -> BSS/OSS-partner

   e)     BSS/OSSs generate the quote for the Customer: BSS/OSSs -> CANTATA -> Customer

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

5. BSS/OSSs perform Product to Service mapping

6.  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

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

8. 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]

9. 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

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

11. 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)

12. 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]

13. 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

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

15. 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