OpenSource Access Manager is a vendor agnostic operation suite for managing consumer broadband network elements and capabilities disaggregated from proprietary monolithic Access Network hardware and Element Management Systems (EMS).
A key component to simplify multi-vendor support is a mediation layer currently under development called VOLTHA (ONF open source project). VOLTHA uses low-level abstraction of the network device to provide a simplified approach to higher level management and analytics. Currently xPON and G.FAST are the initial products under active development in collaboration with ONF.
For Casablanca, OSAM will showcase the management of the Access Peripheral POD (located in Telco Central Offices) as a PNF. Should provide monitoring capability and support 100’s of thousands of Access Peripheral POD deployment in Telco office.
Subscriber management/activation will be contained within the POD and outside the scope of ONAP.
OpenSource Access Manager module for ONAP consisting of the OA&M User interface flows, web services and microservices in support of virtualized multi-access network for consumer broadband services. At a high level, it divides into global and localized functions to operate at large scale and performance for edge networks. The major components of Access Module that do not exist in ONAP today are the user interface (UI). Access specific data models, services, and flows will be built on existing ONAP components and may feed additional requirements. The infrastructure elements, services, flows, data collection processes will be utilized and existing or planned feature sets should not be impacted.
Below are the functions of access network needed on top of the infrastructure services that are already provided as part of ONAP. The requirements for Access will be isolated to the Access Module to not impact the core ONAP capabilities and deliverables.
OSAM
A work effort in ONAP for bridging the Open Networking Foundation (ONF) work into ONAP. Part of this was to create a higher order UI for the Access Network, Service Models, Work Flows, Policies, etc. The goal of the project is to build out dependencies for future support of 3rd party virtualized network services for the access network.
OSAM use case will use the similar approach to 5g use-case. OSAM consists of three components which are OSAM Gateway, OSAM Core, and SEBA. OSAM Gateway and OSAM Core and SEBA will be onboard as a service to ONAP.
ONAP will perform the following functions for OSAM use-case which are;
Users and Benefit:
Operators benefit from OSAM use case in the following aspects:
It currently has 5 main modules which are SEBA, ONAP, OSS/BSS, OSAM Gateway and OSAM Core.
OSAM is addressed as PNF model of 5G use case. In 5G use case, CU and DU pairs are used. In our OSAM case, we are going to use the similar approach. SEBA is going to be mapped as DU. OSAM GW(Gateway) is going to be mapped as CU.
OSAM core will be designed as a VNF. It consists of
OSAM Core is responsible for taking the required actions from OSAM UI or OSS/BSS inputs. These actions are related to technology profile management, ONT/OLT management, topology management, fcaps and subscriber management. OSAM core applies set of actions to SEBA through OSAM GW.
Technology profile management, subscriber information, service activation for the subscriber, alarm/event monitoring, ONT/OLT management and monitoring are applied from UI. OSAM UI has fully interacted with Portal Service Layer which provides PNF information and data such as technology profiles, subscribers information, ONT devices information, and OSAM network topology. In other words, Portal Service Layer provides a backend for OSAM UI with its API and callback interfaces.
OSAM DB is responsible for storing OSAM related data such as:
Portal Framework is the backend for the OSAM UI and OSS/BSS. Provides APIs and callbacks to OSAM UI and OSS/BSS. Technology profile management, ONT/OLT management, subscriber management and subscriber's service purchase operations are conveyed from Portal Framework to Service Flow Manager. PNFs(SEBAs) information and their relation with OSAM gateways are collected from GW Locator to show on OSAM UI.
Service Flow Manager is the coordinator module for OSAM Core. Service Flow Manager can be triggered by Portal Framework or OSAM Gateway. It decides how the incoming/outgoing requests are going to be applied or conveyed. It applies requested set of actions to OSAM DB or OSAM GW Adaptor layer. Service Flow Manager uses OSAM DB for storing information or configurations related to subscriber, ont/olt or technology profile and creating the relationship between subscriber information and pnfId. OSAM GW Adaptor layer is used for sending the information to PNF.
GW Locator is responsible for locating PNFs of OSAM gateway. PNFId plays a critical role for Service Flow Manager. Also, PNF information and its relation with OSAM gateway are saved by GW Locator. PnfId, OSAM Gateway ip address and user credentials for authentication plays a mandatory role for PNF storage in OSAM DB. OSAM GW Adaptor Layer can callback to GW Locator to store OSAM Gateway and connected PNFs relation.
OSAM GW Adapter Layer is the communication layer between OSAM Core and OSAM Gateway. It interacts with GW locator and OSAM GW API services. The interaction between OSAM Gateway and Adapter Layer needs to be bidirectional. GRPC protocol is a good candidate for this purpose. Adapter Layer conveys registered technology profiles, subscriber information and ont registration. (Can be expanded more) to OSAM Gateway from Service Flow Manager. Osam Gateway Adapter layer learns osam gateway ip address from GW Locator using pnfId.
OSAM Gateway is another VNF running near the SEBA pods that can be implemented within the POD as a local OSAM function. OSAM Gateway is a bridge between SEBA and OSAM core.
In OSAM use case, every SEBA(PNF) pod must be matched with OSAM Gateway. OSAM Gateway can connect to multiple SEBA pods. SEBA's bridge gateway(OSAM GW) will be decided by ONAP side. OOF module chooses OSAM Gateway according to location input parameters in ONAP runtime.
Provides a northbound interface to OSAM Core.
API interfaces should provide the following:
The callback should provide the following:
The coordinator is responsible to deliver NEM Adaptor requests to OSAM Core adaptor and vice versa. Moreover, it decides the callback action for PM requests(etc) from NEM adaptor Layer. Such as, if telemetry data is received from SEBA. It sends to Ves Agent. If SEBA register request is received, it stores the request in distributed cache and conveys the request to OSAM core via OSAM Core Adaptor Layer. Addition to that if any request is received from OSAM Core Adaptor Layer, converts to SEBA's GRPC
format and delivers the message to SEBA pod.
Delivers telemetry data to ONAP from Ves Agent. This module is also responsible for sending telemetry data for connected SEBA pods(PNFs) as well.
Connection point to SEBAs. It provides a GRPC callback and APIs to communicate with multiple SEBAs.
SEBA api interface should provide the following APIs:
SEBA callback interface should provide the following:
Caches the PNFId, location and Ip address information. In any OSAM GW failure can recover each other by using distributed cache.
Technology service order for a user is done from OSS/BSS.
| Component | Effort | Project Impacts |
|---|---|---|
| Active and Available Inventory (AAI) | Maybe some model will be kept here | TBD |
| Application Authorization Framework | Define application roles and access | No Impacts |
| Application Controller (AAP-C) | Directed Graphs | No Core APP-C Impacts |
| Closed Loop Automation Management Platform (CLAMP) | CLAMP will be utilized to view and manage the automation flows Interface CLAMP from OSAM-UI (Future Release) | No Core CLAMP Impacts |
| Command Line Interface | No Impacts | |
| Common Controller Developer Kit (CCDK) | Used by SDNC and APPC | No Core CCDK Changes |
| Data Collection Analytics and Events (DCAE) | OSAM Core, OSAM GW and SEBA alerts and events will be sent to DCAE | No Core Impacts to DCAE |
| Data Movement as a Platform (DMaaP) | Topic and Partition Creation | No Core DMaaP Impacts |
| Documentation | ||
| External API Framework | TBD | |
| Holmes | Existing Structure might be reused. | No Impact |
| Integration | No Impact | |
| Logging Enhancements Project | No Impact | |
| Microservices Bus | Not Used | No Impact |
| Modeling | OSAM specific models may be needed | Small impact for models |
| Multi-Cloud (VIM) | Used for installation of OSAM GW and OSAM Core | No Impacts |
| ONAP Operations Manager (OOM) | Docker/Kubernetes Container Management for ONAP | No Impacts |
| Optimization Framework | Will be utilized to select OSAM GW for SEBA pod | TBD |
| Policy Framework | Existing structure will be used | No Impacts |
| Portal Platform | Portal Interface to the DSC and Hardware Abstraction utilizing the Portal SDK | TBD |
| Service Design and Creation (SDC) | Development of the Rules, Recipes, Flows, Models, Policies and Services for virtualized Access OSAM team will attend SDC planned training. | No expected impacts to the SDC Project itself in Beijing. |
| Virtual Infrastructure Deployment (VID) | VID will be utilized for the management of applications. Interface VID from OSAM-UI | No VID Impacts |
| SDNC | Existing 5G use case flow will be reused. | No Core SDNC Impacts |
| Service Orchestration (SO) | Orchestration of Access Device and Service instantiation and updates | No Core Impacts |
Since the OSAM use-case is similar to 5G use-case, most impacts will be common. However, some specific design materials (such as PNFD, VNFD, configuration ) will be different due to the nature of OSAM.
Provide OSAM Core, OSAM Gateway, and SEBA specific models
Modeling will need to be added to describe how OSAM Core and OSAM Gateway VNFs are to be instantiated, removed, healed (restart, rebuild), scaled, how metrics related are gathered, how events are received.
Modeling will need to be added to describe the connection between OSAM Gateway and SEBA, plus OSAM Gateway and OSAM Core.
Design OSAM Gateway, OSAM Core and SEBA network service, TOSCA based. VNF and PNF templates will be provided by OSAM community
Design Auto-healing policy for OSAM Core and OSAM Gateway
Design or provide ansible script for PNF
Outlook Contact List
VCF Contact List
Committers:
| Name | Company | |
|---|---|---|
| BAINBRIDGE, DAVID | DBAINBRI.CIENA@GMAIL.COM | CIENA |
| BAVIER, ANDY | ANDY@OPENNETWORKING.ORG | ONF |
| CHAWKI, JAMIL | JAMIL.CHAWKI@ORANGE.COM | ORANGE |
| ELIACIK, BORA | BORA.ELIACIK@NETSIA.COM | NETSIA |
| KOLBE, HANS-JORG | HANS-JOERG.KOLBE@TELEKOM.DE | DT |
| BHOJAN, SUMITHRA | SB4846@ATT.COM | AT&T |
| PETERSON, LARRY | LLP@OPENNETWORKING.ORG | ONF |
| SLOBODRIAN, SERGIO | SSLOBODR@CIENA.COM | CIENA |
| SOYTURK, MESUT | MESUT.SOYTURK@ARGELA.COM.TR | ARGELA |
Contributors: