Sponsors

Swisscom    HuaweiNokia

Overview

This use case proposes using ONAP for the design, provisioning, life-cycle management and assurance of broadband services. In a first step, multi-Gigabit Internet Connectivity services based on PON (Passive Optical Network) access technology will be considered. The use case covers new scenarios, such as nomadic ONT (Optical Network Terminal) and service subscription plan changes.

BBS use case shows the extensibility of the ONAP platform in supporting the orchestration of services across different locations (e.g., Central Office, Core) and technology domains (e.g., Access, Edge) within the locations.

In a joint collaboration with BBF (Broadband Forum) members, BBS implements/tests some of the specifications defined in the architectural framework of CloudCO (Cloud Central Office), Technical Report TR-384, among others. CloudCO aims at re-architecting the broadband network using SDN and NFV technologies and a cloud-like infrastructure deployed at Central Offices.

The definition of External API capabilities supporting this use case will be performed in collaboration with TM Forum and MEF LSO.

Dublin Goals

  1. Establishment of a subscriber's HSIA (High Speed Internet Access) service from an ONT to the Internet drain

    1. The HSIA service is designed and deployed using ONAP's design and deployment capabilities

    2. The HSIA service activation is initiated via ONAP's External APIs and orchestrated and controlled using ONAP orchestration and control capabilities. The control capabilities leverage a 3rd party controller to implement the requested action within the technology domain/location represented by the domain specific SDN management and control function.

  2. Change of location for ONT devices (Nomadic ONT devices)
    1. PNF (Re-)Registration for an ONT
      1. Subscriber association to an ONT via ONAP's External APIs
      2. ONT association with a expected Access UNI (PON port) when a HSIA service is created/deployed for a subscriber
      3. PNF (Re-)Registration using ONAP's PNF registration capabilities
    2. Service location modification that is detected by ONAP's analytic and initiated via the closed loop capabilities
      1. The closed loop capabilities invoke a HSIA location change service that is orchestrated and controlled using ONAP capabilities and 3rd party controllers 
  3. HSIA service subscription plan changes (R5)
    1. The HSIA service modification (e.g. upgrade bandwidth plan) is initiated via ONAP's External APIs and orchestrated using ONAP.
  4. HSIA service assurance (R5)
    1. The HSIA service health is monitored via ONAP's data collection, analytic and closed-loop capabilities



Business Requirements

  • Service providers need a flexible platform that integrates Broadband services using standardized APIs towards domain specific management and control systems, e.g. Access domain controller/orchestrator. 
  • Equipment vendors and systems integrators benefit from well defined, standardized APIs to which they can develop products and services.
  • By closely collaborating with Industry consortiums, such as BBF, the BBS use case outcomes will serve as a basis for the definition of new standard interfaces and the evaluation and refinement of existing specifications.

BBS Documentation

Documentation on how to set up the use case: 

Demo videos: BBS Documentation (Dublin)#BBSServiceConfiguration


BBS Use Case Presentations

BBS Use Case Team Meetings

Weekly Meeting

Day: Thursday

Time: UTC 1200 / China 2000 / Eastern 0800 / Pacific 0500

Duration: 1.5 hours

URL:  https://zoom.us/j/735324492

Meeting Minutes

Impacts

The BBS Use Case for Dublin will have impacts on the following projects: AAI, DCAE, External API, SDNC, SO

See Impacts page

Project Commitments

ProjectPTLCommitmentNotes
AAI

COMMITTED

AAI-1990 - Getting issue details... STATUS / AAI-2154 - Getting issue details... STATUS

CLAMP

TEST

CLAMP-270 - Getting issue details... STATUS

Setup of Control Loop for Location change:

  • configure DCAE µS that detects location change
  • configure policy that trigger re-config 
DCAE

COMMITTED

DCAEGEN2-1057 - Getting issue details... STATUS

Must have:

  • Restconf2VES mapper (TechM commitment)
  • Restconf collector microservice (Huawei commitment)
  • RG activation microservice (Nokia commitment)


  • PRH microservice needs to trigger policy (Nokia commitment)
External API

COMMITTED

Nice to Have: Support for TMF 638 ServiceStateChangeNotification or ServiceAttributeValueChangeNotifications

Note - EXTAPI-98 - Getting issue details... STATUS This EPIC was previously raised to support Service Inventory Notifications with relevant support from A&AI.

Policy

TEST

  1. APEX modification to support CLAMP at control loop design time;
  2. Support BBS/ONT Nomadic ONT policy modeling at design time
  3. Apex policy distribution, deployment execution.
SDNC

COMMITTED

SDNC-614 - Getting issue details... STATUS

Updates to SDNC DG repository to onboard new DGs developed by BBS team


SO

COMMITTED

Dependency: 5G Use Case to develop PNF discovery

SO to use SDN-C GR-API for resource creation/deletion

SO-1392 - Getting issue details... STATUS

Scope

The work leverages the CloudCO reference architectural framework (TR-384) by implementing the organization's work for integration of CloudCO to ONAP as defined in Cloud-CO-APPN-015: Cloud-CO-APPN-446: ONAP Integration for HSIA Service (Access) Integration for HSIA Service (Access). The scope of this use case for the Dublin release includes the implementation of this application note and will demonstrate modification of a subscribers subscription plan. As the Broadband Forum develops additional Broadband Service application notes that are applicable for integration with ONAP, this use case will be extended over time to incorporate the new application notes.

Priorities

Dublin will focus on Broadband Service CFS (Customer Facing Service) design, creation and activation, with support for nomadic ONT. If possible we will also implement the subscription plan change scenario (CFS "modify" action). Enabling CFS service assurance is a stretch goal for Dublin.

Action Phases

  • Phase 1: CFS creation and activation [priority for Dublin]
  • Phase 2: Nomadic ONT (PNF re-registration) [priority for Dublin]
  • Phase 3: CFS change / reconfiguration (subscription plan change) [stretch goal for Dublin]
  • Phase 4: CFS assurance [stretch goal for Dublin] 

Sub-Use Cases

  • 3rd party controller registration, RFS catalog discovery / abstract topology discovery (Phase 1)
  • CFS design and RFS onboarding (Phase 1)
  • CFS reconfiguration after PNF relocation (Phase 2)
  • CFS reconfiguration after service change order from BSS (Phase 3) [stretch goal for Dublin]
  • CFS termination [stretch goal for Dublin]
  • CFS assurance (fault detection and self-healing) [stretch goal for Dublin] 


System topology

BBS - Arch Overview BBS - CFS HSIA Model

See BBS Modeling 


Full System Context

BBS - SystemContext

InterfaceDescription
BSS ↔ External APIAdvertise service catalog to external systems, e.g. BSS, service instance ordering and order status tracking, and service instance state change notifications to external systems.
External API AAI

This interface provides for notification of service instance state changes

External API SDC/SOThis interface provides invocation for the service catalog, LCM operations on the CFS HSIA instances, event notification on service instance order status
Policy ↔ DCAEThis interface provides closed loop policies for activation of the CFS HSIA and relocation of ONT
Policy ↔ SDN-CThis interface supports RFS re-configuration triggered by ONT relocation as well as device PnP
Policy ↔ AAIThis interface supports CFS re-configuration triggered by ONT relocation as well as device PnP
SO → SDN-C

This interface provides orchestration of the CFS HSIA into requisite network services for Access and Edge. The interface also provides a relocation of ONT network service.

DCAE ← Domain Specific SDN M&CThis interface provides event collection for Service and ONT health as well as notification of an ONT registration to a new Access attachment interface.
SDN-C → Domain Specific SDN M&CThis interface provides the resource facing HSIA services for Access and Edge elements. In addition ONT application layer configuration is provided.



Work Commitment

Work Item

ONAP Member Committed to work on BBS

Modeling

Nokia (Stavros Kanarakis, Tim Carey - epics), Huawei (Victor Gao - epics), Swisscom

SDC

Nokia, Huawei

SO

Nokia (Tamas Lendvay - epics), Huawei (Victor Gao - epics)

SDN-C

Nokia (Stavros Kanarakis - epics), Huawei (Victor Gao - epics)

UUI


DCAE

Nokia (Tamas Lendvay - epics), Huawei (Xin Miao - epics), Swisscom

PolicyNokia (Tamas Lendvay - epics), Huawei (Xin Miao - epics)

VF-C/APP-C


A&AI

Huawei, Nokia (Stavros Kanarakis - epics)

External API

Huawei (Adrian O'Sullivan - epics)



13 Comments

  1.  Does the Subscription Plan Change  call  Edge SDN M&C only?then AAA? No need for Access SDN M&C, where does the Service info configuration end up? thank you

    1. Service profile with internet speed is configured in AAA and fetched by BNG from there. BNG does the traffic shaping based on that profile. In principle, we don't do shaping in the Access so I think we don't need to call the Access SDN M&C

      1. David,


        Actually it is not unusual for the Access network to shape. It could be as you noted SP that simply treat the access as an under subscribed pipe but it also is the case where the Access network is oversubscribed. We should make the call and let the Access M&C figure out if they need to adjust the TCONTs, GEM ports, etc.

        1. I agree. We should not discard the option where shaping is done at the Access.

  2. in Topology Discovery case? ONAP queries from Access SDN M&C by sync topo command? can you specify what nodes, links, terminal points are, such as ONT, OLT, P2P link, TP and others? thanks.

  3. For the ONT Nomadic Service Notification to OSS/BSS for location changes that are inprogress/success, could this functionality be achieved by leveraging the Service Inventory API with ServiceStateChangeNotification or ServiceAttributeValueChangeNotifications?. In the ONAP External API Framework project there is already a TMF 638 based Service Inventory API. It currently does not have notification support for Service Inventory state/attributes changes, but if the Service Instance state or attribute was to change in A&AI ( triggered by the Policy to SO on ONT registration  ) , we could potentially notify registered OSS/BSS listeners from External API that the Service State has Changed or that a Service Location Attribute has changed via the External Service Inventory API. Or is there a plan to introduce a totally new External API for ONT Location Change notifications externally from ONAP to the OSS/BSS?. 

    1. Hi Adrian, we would like to leverage on the existing ONAP External API framework for service state change notifications (including ONT location change). We can use TMF 638 for this. We may also need TMF 641 for service ordering, activation and modification (e.g. subscription plan change)

      1. Hi David, that is great that we utilize the existing APIs. The BBS use case will require some enhancements to the existing Service Inventory and Service Order APIs but I think these enhancements will be good changes for the community to have. ONAP External APIs do not currently support TMF 638 ServiceStateChangeNotification or ServiceAttributeValueChangeNotifications in Casablanca. We may need support from A&AI team to allow External API to register a listener,  so that when the "orchestration-status", "service-instance-location-id", "input-params" for a Service Instance changes that ExtAPI can be notified  i.e. so External API Framework does not need to poll A&AI. Also the current implementation of Service Order TMF 641 for action "modify" is limited, in that it currently first deletes and then recreates the service-instance with a new service-instance-id. It would be better to improve this to at least use the same service-instance-id as we have asked to modify a service-instance , not recreate it. This enhancement will be good to explore in the ONAP External API Framework project in collaboration with SO team.   

        1. Hi Adrian OSullivan,

          We may need support from A&AI team to allow External API to register a listener,  so that when the "orchestration-status", "service-instance-location-id", "input-params" for a Service Instance changes that ExtAPI can be notified  i.e. so External API Framework does not need to poll A&AI.

          I don't think that the AAI/ESR has a concept for "listeners", but AAI does have precedent for publishing events to DMaaP, so perhaps that is a better way forward? Can ExtAPI consume messages from DMaaP?


          1. Hi Keong Lim, I think this is a very good suggestion. Currently External API does not consume events from DMaaP but there is no reason why we cannot add this capability in Dublin release. External API would just need to agree on the topic naming conventions for subscribing to the A&AI service instance  events pushed to DMaaP by A&AI.  

            1. OK, I am collating new AAI proposals in this wiki page AAI-BBS Proposals for Dublin Release


  4. 5G Use Case (R4 Dublin)

    This is the link to the 5G use case.The comment tim made is that Ben has done alot of great work with folks on how to support PNFs including PnP. So even though it was focused on 5G, it really generalized for PNFs in general.

    So go through this in depth get a feel for how we can re-use some of their concepts for our use case


  5. Started going through this more and think we should start listing the NFVi/VIM, VNF and PNFs we are going to use and the vendors providing it or at least state it is already provided.

    David, I think you should identify the NFVi/VIM, VNFs and PNFs which you already have and what you may still need.

    I also  should just have the high level as well as low level milestones documented on the wiki to we have all info in one place. Victor, I think you are creating this?