1. OPEN-O Use Case Design Residential Scenario

2. Consumer Story  Kaylin is a residential broadband subscriber of CMCC.  Her boy is 8 years old, and begins surfing on the Internet frequently. Kaylin has a concern that the uncontrolled access to Internet content, including some violent content will harm her boy. So, she visits CMCC’s broadband service website and looks for help.  She finds a “parental control” service on the shelf, which can block harmful Internet content to specified end user devices for children. She applies the service without hesitation.  The newly requested service becomes available in minutes. Kaylin then logins in the service portal and configures the service, including the information about the child’s device to be protected (e.g. MAC), allowed accessing time, control level, other special rules, etc.  Now, parental control is activated. Kaylin feels at ease. parental control

3. Operator Story Access Network VM vLB VM vFW VM vNAT TIC Edge Resident home  CMCC deployed Open-O for its next generation SDN/NFV network.  Now in order to launch the broadband service to the home subscribers from a new residential quarter, the operator only needs to compose and initiate a basic network service BB including BRAS by Open-O, which is expected to be available for the consumer in several minutes.  Open-O also complements the DevOps environment for CP/SP to provide various third party applications. Corp. GreenSky delivered to CMCC the parental control service (as a VNF), which has been onboarded successfully to the OPEN-O VNF catalog, but not included in the default network service BB.  Until explicitly requested by the first subscriber, the OPEN-O begins deploying the VNF into a value added service function chain vCPE in response. The same VNF instances or SFC instances can be shared by subsequent subscribers requesting similar value-added services.  Open-O orchestrates the VNFs for vCPE to be deployed to the nearest TIC Edge to the requesting subscriber’s home. According to the service configuration specified by the subscriber, Open-O also installs new SFC classification rules to the network so that the flow destined to the specified device will be processed by the vFW component of the service. QOS DHCP pCPE vCPE

4. Terminology TIC: Telecom Integrated Cloud which provides telecom network function based on cloud technology. – TIC Core: TIC deployed at the core of operator network, for the centralization of control plane functionalities. – TIC Edge: TIC deployed at the edge of operator network, for the decentralization and localization of data plane functionalities and media traffic. SDN Controller – SFC Controller ： Implemented on ODL by NBI, parse and install SFC configuration from OPEN-O (NFV-O) to the Classifier (i.e. the pBRAS) and the SFF (a VM in DC currently) – DC Controller ： Based on ODL and control pBRAS(Vxlan GW), OVS vxlan in TIC – Super Controller ： Interconnection with multiple domain controller for E2E service – Domain Controller ： Specific SDN controller for special vendor’s network VNFM – S-VNFM: commonly refers to (vendor) Specific VNFM, that comes from VNF vendors and is specific to vendor's VNF(s) – G-VNFM: G-VNFM stands for the Generic VNFM, that is not specific to any VNF, such as JUJU. CPE – pCPE: physical CPE deployed in home, such as HGU or SFU. – vCPE: virtual CPE deployed in Cloud/PoP, as a collection of VNFs BRAS – pBRAS(DP): BRAS Data Plane deployed at the TIC Edge as a physical device and controlled by vBRAS(CP) remotely. – vBRAS(CP): virtual BRAS control plane deployed in TIC Core as a VNF on COTS servers.

5. 5 Residence 2 Internet Component Selection OPEN-O S-VNFM VIM G-VNFM SDN Controller S-VNFM G-VNFM SDN Controller VIM Data Flow OLT pCPE SPTN OS vBRAS(CP ) pBRAS(DP) Internet (WAN) Metro CoreTIC-EdgeTIC-CoreResidenceBuilding OS vFW OS vNAT vCPE Control Flow OS vLB GWGW VLAN MPLS-TP L3VPN VLAN to WAN VXLA N VXLAN (SFC) Overlay Underlay

6. 6 Operator Service Deployment Flow Chart GSOSDN-ONFV-O VNFM (ZTE) VIM (TIC Core) SDN Controller 1. Create vBras NS Request 1.2. Create vBras CP 1.2.3 Create vBras CP binding to the external VL 1.2.1 Create external VL 1.1. Create a connection service between DP and TIC core GW WAN SDNC 1.1.1 Create VL from DP to Vlan in TIC core GW Response 1.2.3.1 Deploy VM 1.2.1.1 Create VL 1.2.2 Create vxlan from TIC core GW to external VL Note: 1-1.1 The operator needs to provice VLAN id (result of manual configuration) as input parameters to the NS request to GSO and SDN-O. The automation of Step 1.2.2 by NFV-O is a stretch goal of release 1. Otherwise, it needs manual configuration. Portal

7. 7 Comsumer Service Modification Flow Chart NFV-O VNFM (ZTE\JUJU) VIM (TIC Edge) SDN Controller (TIC Edge) SFC Controller pBRAS (DP) SFF 1.2 Create VNFs binding to the external VLs 1.3.2 configure SFF 1.3 Create Service Function Chain Response 1.3.1 Configure BRAS-DP Classiffier 1.2.1 Create internal VLs and VMs in a VNF instance 1.1 Create external VLs among VNFs and SFF WAN SDNC 1. Create vCPE NS Request 1.1.1 Create external VLs 1.2.1.1Create internal VLs Note: SFC Controller and SFF are part of the TIC infrastructure and deployed independently from the service initiation procedure. Portal

8. 8 NFVO Functional flow example (“Create vCPE NS Instance) NFV-O VIM VNFM Catalog Lifecycle Management (LCM) Portal NBI API NFV.Res.Mgr DependencyRel 1 Scope SBI VIM Driver VNFM Driver API Parser SDNC SDNC Driver Model Design Monitor API Workflow 1.Consumer uses Portal to select a NSD from the Catalog, submits request to NFV-O. 2.NBI receives request (Catalog reference + parameters), and passes the request to Lifecycle Management(LCM). 3.LCM gets the NSD and creation plan from Catalog. 4.LCM submits a request to parser, and gets in response a graph of NSD, and checks whether the NSD and Parameters are valid. 5.LCM create a new service instance with the status “Creating”. 6.LCM submits a request to workflow engine with the creation plan. 7.Workflow engine executes the correspondent actions specified in the creation plan, and makes use of various NFV SBI drivers and micro-services (NFV. Res. Mgr,…. ) via LCM. a.VIM driver renders each VL to be created into a JSON, sends a RESTful request to VIM, parses the response from VIM, and returns the output parameters to the Workflow executor via LCM. b.VNFM driver renders each vCPE VNF to be created into a JSON, sends a RESTful request to VNFM, parses the response from VNFM, and returns the output parameters to the Workflow executor via LCM. c.SDNC(SFC) driver renders the SFC to be created into a JSON, sends a RESTful request to SDNC(SFC), parses the response from SDNC, and returns the output parameters to the Workflow executor via LCM. 8.LCM updates the service instance status into “Created”.

9. Thanks for your advice