Name of Use Case:       

Residential Broadband vCPE

Use Case Authors:

Amdocs, AT&T, Intel, Orange, Wind River

Description:

Technical Report 317 (TR-317) from the Broadband Forum specifies a "Network Enhanced Residential Gateway" (NERG) that can be used by service providers (SP) to deploy residential broadband services including High Speed Internet access, IPTV and VoIP services. A new device type named BRG (Bridged Residential Gateway) is defined, as well as a functionality split between what it would run and what a virtual function instantiated in the SP's cloud, called vG, will run. This functionality split allows for the introduction of new services not possible with the existing whole-physical residential gateway. It also saves operational cost in that less changes / truck roll in and to the customer residence would be needed. 

Key for this use case is:

• ONAP will be used to instantiate, configure and manage the required vCPE service as a cloud service that may be collocated with other subscriber services such as vSTB, cloud DVR and VoD-streaming vCDN.
• SDN is used to configure the connectivity with the first mile network, the IP subscriber management and service edge networking. Potentially in the future, dynamic service chaining to value-add services (e.g. security, parental control, home automation IoT).

The full details for this this new residential gateway can be found in the BBF report. For ONAP Release 1 (Dec 2017) a subset of the full functionality of TR-317 will be included in the VNFs implementing the vCPE use case; but the ONAP behavior for the use case will be mostly what will be expected from ONAP in a production network.

The diagram above depicts the R1 vCPE use case (with the exception of the home networks on the left which will not be part of the tested use case). The IP addresses and VLAN numbers are for illustration purposes, the actual values may be different in the final set up. In particular, IPv6 addresses may be used in place of IPv4 10.x.x.x in the above.

Users and Benefit:

• Residential users benefit from subscriber specific cloud services and automation that does not need truck roll installation, local configuration and management of LAN/NAT/WAN/VPN networking.
• Authenticated subscribers may access similar broadband services outside the home residence using other wireline or wireless access networks.
• SPs benefit from a more flexible platform to evolve residential broadband services that do not depend on the lifecycles of provided home devices (e.g. STB, WiFi access router, modem etc…)

R1 Use Case Flows

Basic flow for establishment of the LSL (Logical Subscriber Link):

• BRG Emulator comes up and issues a DHCP Discover request for its WAP i/f
  • The request contains option 125 (BBF) with sub-option NERG Device Type (24) with string "BRG"
  • For the demo - the request will include option 82 as if entered by an AN
• vBNG intercepts the DHCP request, stores it, and issues a Radius Access-Request with the DHCP request options to vAAA
• vAAA sends  the Access-Accept back to vBNG
• Upon receiving the accept vBNG restores the DHCP request and relays to vDHCP
• vDHCP sends a DHCP Offer with the BRG WAN IP
• BRG Emulator sends a DHCP rquest with its WAN IP address
• vBNG snoops the request and relays it to vDHCP|
• vDHCP sends a DHCP Ack to BRG
• ONAP configured BRG Emulator with the address of vG-MUX for tunneling at stand-up time

Network Function:

Aspiration goal:

Monitoring of metrics and alarms of the BRG and automated action. Example policy based on monitoring:

-       Automatic reboot of the BRG because of high load (CPU).

Virtual Network Function / VNF:

NFVI+VIM:

ONAP Flows:

The vCPE use case consists of two types of VNFs / services:

1. Infrastructure services - deployed prior to any customer request for a vCPE service, assumed to be up and running and ready to provide their services when a customer order is received.

2. Customer service - consisting of the BRG_Emulator and vG VNFs, deployed on a per customer order basis, utilizing the various infrastructure services.

The Infrastructure service are further sub-categorized:

1.1 General infrastructure - consisting of functions which are required by the vCPE use case but in real life will be used for/by many other services.vDHCP, vAAA, and vDNS belong here.

1.2 Specific infrastructure - functions required and used solely by the vCPE customer service. vBNG and vG_MUX belong here.

The specific infrastructure functions will be implemented as two separate services: one for vBNG, another for vG_MUX, in order to allow (not in R1) to scale each separately, and also to enable one vBNG to connect to multiple vG_MUXs as well as one vG_MUX to connect to multiple vBNGs - thus supporting different deployment scenarios of these two functions.

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
      
      
      

• Infrastructure instantiation
  
  
  • General infrastructure instantiation (vDHCP, vDNS, vAAA)
    
    
    
  • Specific infrastructure instantiation 1 (vBNG)
    
    
  
  
  • Specific infrastructure instantiation 2 (vG_MUX)
    
    
    
• Customer ordering
  
  
  • New vG ordering, instantiation and activation
    
    
  • 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?

Project Impact:

• Modeling
  
  
  
• SDC
  Add logic to use the new modeling when designing the service, and then distribute the resulting artifacts.
  
  
• CLAMP
  Framework for policy design and distribution 
  
  
• SO
  Add logic to understand the new artifacts; orchestrate/manage changes according to it.
  
  
• SDNC
  Add logic to create the chaining, configuration, healing, etc.
  
  
• DCAE
  Support statistics collection and receipt of events as per the new model; monitor connectivity and livelihood of the BRG_Emulator.
  
  
• APPC, VF-C, and DCAE
  Support more complex control loops.
  
  
• A&AI
  Support the new data model.
  
  
• Policy
  Support new policy related to the service + the connectivity to the BRG_Emulator.
  
  
• VNF SDK
  Support the ONAP VNF guidelines (blend from ECOMP and OPEN-O)
  
  
• Integration
  Integrate, produce test cases, run the tests, verify the use case with the selected VNFs

Work Commitment:

Note: Work commitment items indicate which ONAP Members have expressed interest and commitment to working on individual items. More than one ONAP Member is welcomed to provide support and work on each of the items.

Meetings:

• Jun 28, 2017 Meeting: Use Case Walk Through
  - Recorded meeting: https://zoom.us/recording/play/DgJBQbqOZaSKHxmOmlDXcU9_zTKNrRAa9Y3TTkCw3T9Hi-ekUBGVmf-ev8uU_TP9
  - Yoav walked through the use case flows so that people from different project can understand the details and subsequently identify impact/requirements/issues related to their respective projects.
  
  

• Jun 30, 2017 Meeting: Closed Loop Control

  - Recorded meeting: https://zoom.us/recording/play/KG9scmJ1aaeV8ozDWaVhK9wPifYkCaF9qodXsyVOhM8z8Ld9PiKFD3K0IU2zl_rz

  - Yoav presented the flow on automatic reboot/restart.
  - One question was whether we want to restart VNF or VM. The answer is to restart VM.
  - Data collection vG_MUX --> DCAE: What needs to be worked out is the VES version and payload to be supported by vG_MUX. DCAE would like to have sample data from the VNF. Yoav will bring these requirements to Danny Lin.
  - Events DCAE --> Policy: The content of the events should be well defined.
  - Control Policy --> APPC: The detailed interface definition needs to be worked out.
  - Mapping from VNF ID to VM ID: The current flow shows that APPC will query AAI to perform the mapping. Further discussion is needed to decide where to do it: APPC or Policy.

• Jun 30, 2017 Meeting: Design Time
  - Recorded meeting: https://zoom.us/recording/play/T7E79ekw4OaHRZCIf4dXF0Cq0PNVkA9bgyYsG2HKZqDhHCMFVGi6_gA3m_y5HSC0
  - Yoav presented the VNF onboarding process
  - VxLAN is preferred for the tunnels between BRG and vG MUX. Tunnels from different home networks will share the same VNI but are differentiated using the BRG IP addresses.
  - Ron Shacham explained that CLAMP will create a blutprint template that will be used to instantiate a DCAE instance for the use case. CLAMP is not responsible for the development of the DCAE analytics program.
  - It is determined that the infrastructure service and per customer service should be created individually.
  - Yang Xu from Integration pointed out that VNF address assignment/management (including OAM IP and port IP) needs further discussions. Yoav will update the use case architecture diagram to include OAM IP addresses.
  - It is realized that service design is complicated and needs more discussions. Yoav will follow up on these topic and schedule meetings.
  - Micheal Lando mentioned that a new version of SDC is being set up in AT&T. Daniel will check whether the community can get access to it.

  
  

• Jun 30, 2017 Meeting: Design Time
  - Recorded meeting: