Comment: (Vladimir Y.) The whole text is about E2E slicing, not RAN slicing. See e.g. the diagram
This page contains work in progress! |
|---|
Questions and comments are inserted in the text as needed, prefix them with "Question:" or "Comment:". Text below the line "----temporary text ----" is a placeholder for text that may or may not be used later on. |
...
| Rev | Author | Comment |
|---|---|---|
| 9/7/17 | Peter L | Copied text from the v4 document, must check the v5 document for additional parts |
| 9/14/17 | Peter L | Rewrite of the central parts - old comments and text moved to the end until we agree that all comments are properly covered. |
| 9/25/17 | Peter L | Modified Fig1 as discussed during meeting 9/21/17, added a second figure to illustrate the RAN part of the concepts used and a few clarification is in "Steps" and "Proposed out of scope". |
...
I can continue, but prefer to stop at this point. I think we should follow the concepts clearly defined and agreed in the relevant SDOs. It would be bad idea to deviate from 3GPP / NGMN definitions and/or invent our own definitions.
(Peter L) The point here is not to invent any new definitions at all - the point is to describe a slice related management use case using the RAN, CN and TN technologies we already have, in order to expand the capabilities of ONAP (or show that they are already sufficient). We are not here to develop the CN, TN or RAN, right?
However, as ONAP has a slightly different structure and functional composition than what is described by NGNM or 3GPP, we effectively do work with ONAP specific definitions in some management areas.
Gliffy name Cell Planning
Goal for this Use Case:
To show that ONAP can be used to desgn and deploy the Service Comment: (Vladimir Y.) The text under the figure says that the blue cells are shared between NSSI RAN1 and RAN2. On the figure itself, blue is marked as RAN1 and red as RAN2, i.e. blue is not shared between RAN1 and RAN2. Which one is right?
Peter: Thanks, fixed to make it consistent. Question remains, though - do we prefere the definition as it is written now, or a definition where all cells are part of NSSI RAN2 and the blue cells are also part of NSSI RAN1? The result will be the same, it is only a question if some cells are to be shared between NSSIs, or if the division into NSSIs shall be unique and the sharing is betwen NSIs. There might exist limitations or capabilities in e.g. what can be described using TOSCA that makes one of these alternatives more favourable than the other?
Goal for this Use Case:
To show that ONAP can be used to desgn and deploy the Service 2 in a new CN and selected portion of a RAN currently providing Service 1 using NSI A, see Figure 1 and Figure 2.
The steps described below will cover both the design (or preparation) and the lifecycle management (instantiation, configuration, activation, monitoring, modification & decommissioning) of the slice as described, for example, in the 3GPP TR 28.801 V15.0.0 (2017-09) document.
Please note that we use the LTE network and the RAN sharing concepts to illustrate the management problem to be solved by ONAP.
...
- The ONAP Service Designer define TOSCA templates for the reusable tasks, examples could be:
- Create a suitably isolated transport network for connecting the RBSes to each core network, possibly using VLAN/VXLAN within the RBS and VPN from the RBS and onwards
(old text: VLAN to be used for control and user data within an NSI) - Per CN node type: Create yet another node connected to the proper transport network
- Per RAN resource to be shared (e.g. the EUtranCell): Reconfigure to use yet another PLMN and a specific VLAN for that PLMN
Question: How do we address the EUtranCell – do we need to model that entity and include all provided cells in e.g. the AAI? - Create a CN NSSI using provided VLAN tags and PLMNI-ID value with a specified “capacity” (the “capacity” value to be used to select number of CN nodes to spin up).
This also includes filtering or aggregation rules for DCAE to produce NSSI related FM/PM/Event data. - Create a RAN NSSI template using provided VLAN tags and PLMN-ID covering a specified set of cells. This also includes filtering or aggregation rules for DCAE to produce NSSI related FM/PM/Event data.
- Create a Service NSI used to instantiate, modify, and remove “Service 2”. This also includes filtering or aggregation rules for DCAE to produce NSI related FM/PM/Event data, aggregating that data into KPI values for SLA evaluation.
- Create a suitably isolated transport network for connecting the RBSes to each core network, possibly using VLAN/VXLAN within the RBS and VPN from the RBS and onwards
- The Service/Network Operator adds (or removes) a NSI in the production environment:
- The Service/Network Operator uses the ONAP Portal to add (or activate) a NSI
- The ONAP Service Designer (or the Service/Network operator using the portal) publish the availability of a NSI for usage over the ONAP NBI.<Does the Service Designer create NSI = Network Slice Instance?>
Question: What functionality do we have in e.g. AAI to control visibility of service templates, e.g. our NSI description for access over NBI?
Question: What functionality do we have in SO to execute service instantiation requests originating from NBI?
Question: How does an external application figure out what service templates are available and what data are needed when using them? (assuming we should not ship the entire service template over NBI…) - An NSI related request is received over ONAP NBI (e.g. from an ordering system or operator GUI), the SO applies the parameters to the NSI template and executes the request.
Question: Any improvments needed in the interaction between the external part and the SO for starting such requests, monitor the progress of the request and reciving the result?
- The Service/Network Operator verifies reception of NSI related KPI data using the ONAP Portal.
...