Versions Compared

Old Version 87

changes.mady.by.user Gil Bullard

Saved on

compared with

New Version 88

changes.mady.by.user Gil Bullard

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Note: All detailed flows (with diagrams) are for R1. Flows planned for subsequent releases are tagged as "aspiration" and are only mentioned, details will be added later.


Onboarding of vCPE VNFs



Service Instantiation Flow

Generic Run Time Flows

For "simple" Services which include only simple networks and VNFs (e.g., with no multi-data instances that map to different VF Modules), there exists an SO “Generic Service” flow (“top level flow”) that spawns Resource Level VNF and/or Network sub-flows that are themselves "Generic".  By "Generic" we mean that the SO flows were built with no particular Service, VNF, or Network in mind, but are rather implemented in such a way to support many different Service, VNF, and Network types.  The SDC model drives which particular sub-flows to spawn and of which type, as well as driving the specific behavior of the Service level and Resource level flows. 

...

Generic Resource Level Flow for VNFs

...


Use Case Order of Operations

The assumed order of operations for the run time use case experience is as follows:

  1. Via VID, user will request ONAP to create an instance of the vCpeCoreInfra_X Service (HEAT or TOSCA based)
  2. Via VID, user will request ONAP to create an instance of the BNG_MUX Service.
  3. Via Robot, request ONAP to create an instance of the vGMuxInfra Service.
  4. Via VID, user will request ONAP to create an instance of the vBngInfra Service.
  5. Via Robot, request ONAP to create an instance of the BRG emulator, the BRG_EMU Service.  The associated BRG-emulating VNF will come online and start behaving like a BRG, among other things initiating a sequence of events that will result in the BRG being inventoried in A&AI, which in turn results in A&AI generating another event that is intercepted by Robot.
  6. Robot, now acting as a BSS emulator, upon receipt of the A&AI event, will request ONAP to create an instance of the vCpeResCust Service.

The diagram below shows more detail of step 5 in the above sequence.  Note that only the "No BRG PNF Object" alternative flow is in scope for Release 1.  (I.e., in Release 1 the assumption is that the BRG PNF (emulated) will always be "plugged in" prior to the "customer service request" being released to ONAP.) 

Image Added


For more details on the instantiation flows described at a high level above, see the attached PDF.

Other Flows

...


    • Aspiration goal: Cut service
    • Aspiration goal: Per service activation ( connectivity to Internet, IMS VoIP, IPTV)
    • Aspiration goal: Wholesale access (future)

    • Self-service
    • Aspiration goal: Tiered bandwidth
    • Aspiration goal: Bandwidth on Demand
    • Aspiration goal: Change internet access bandwidth

    • Software management
    • Aspiration goal: Upgrade service
    • Aspiration goal: Upgrade a specific element (VNF) of the service
    • Aspiration goal: Delete service

    • Scaling
    • Aspiration goal: Storage (future)

    • Auto-healing
      • Automatic reboot/restart


      • Aspiration goal: Rebuild
      • Aspiration goal: Migrate/evacuate to different CO Re-architected as DC (future)
      • Aspiration goal: Reconnect over an alternative path?

...