Page History

Comment: (Vladimir Y.) The whole text is about E2E slicing, not RAN slicing. See e.g. the diagram

...

Introduction

Introduction

Each Service Provider (SP) needs to support a rich set of advanced Each Service Provider (SP) needs to support a rich set of advanced 5G wireless services, such as enhanced Mobile Broad Band (eMBB), massive Internet of Things (mIoT), and Ultra-Reliable, Low-latency Communications (URLLC ), for mission critical communications.

...

Comment: (Vladimir Y.) Being an active contributor to 28.801, I'd agree that there were attempts to provide some notion of what a "service" can be e.g. classification of services, such as B2B, B2C etc. However there is no definition of service. My point is that this group is not right place to develop such definition. It's a business of 3GPP, and we are here not to fill the gaps left in 3GPP specifications.Comment (Vladimir Y.) The definition of NSSI in 28.801 is different: includes recurrence.

A network slice subnet instance (NSSI) constituent may include NF(s) and other NSSI(s).

Comment (Vladimir Y.) How is the right hand side of the diagram relevant to the document?
Peter: It's an overview of the management layers described in section 4.10, and I included it in anticipation of a need to relate to these 3GPP specified management functions and their interfaces in our ONAP based realization. If we need it while writing this use case is yet to be decided... 

Comment (Vladimir Y.) These are not "layers", simply interconnection between CSMF, NSMF and NSSMF which is not that important. If we want to address these functions in ONAP, some text is needed saying exactly that.

...

Comment (Peter L): Re-writing this section, trying to catch the commens. Old text available at the end.

Comment: (Vladimir Y.) Some of terms and concepts used in the text below are

...

Comment (Peter L): Re-writing this section, trying to catch the commens. Old text available at the end.

Comment: (Vladimir Y.) Some of terms and concepts used in the text below are not defined in 3GPP or assume too specific implementation or cannot be easily interpreted (marked by red). They should be replaced with terms / concepts defined in 3GPP and/or generalized. The terms "PLMN" and the label "PLMN-ID" are misleading as slice instances and their RAN or CN components are not separated PLMNs

...

1. PLMN-ID in 3GPP is not used to identify the slice (certainly it is used to identify the PLMN)
3GPP did not develop (yet?) the concept of how two slice instances can relate to two different PLMNs. I personally like this idea, but ...

2. "Existing CN" and "new CN" literally mean that there are two Core Networks. Probably the point is that there are two NSSIs that consist of CN NFs.

(Peter L): Correct - and we don't say that 3GPP does. We propose here to re-use the RAN sharing support for multipple PLMNs as if each such PLMN represent a slice of its own. As many products support this RAN sharing scenario (including transport separation based on PLMN) we obtain a scenario that from a management point of view is expected to be similar to working with slice support as we may find in a 5G CN and RAN.

2. "Existing CN" and "new CN" literally mean that there are two Core Networks. Probably the point is that there are two NSSIs that consist of CN NFs.
(Peter L): Correct.

3. "It is known from ONAP R1 how to instantiate and deploy a minimal viable CN" - probably means that 3. "It is known from ONAP R1 how to instantiate and deploy a minimal viable CN" - probably means that R1 ONAP will have sufficient functionality to support deployment of 3GPP Core Network. If this is the statement, it needs some explanation. For example, probably LCM of VNFs will be supported. The LCM of NSs (in terms of ETSI NFV) - I don't know; will appreciate reference that confirms. Same question about support of signaling transfer, about OAM functionality. Many questions probably cannot be answered simply because R1 is not sufficiently documented.
(Peter L): I agree to that - it is slightly problematic, but if the R2 use cases cannot build on top of already delivered functionality demonstrated as R1 use cases, the we do have a problem. This has to be checked.

4. Use of VLAN tagging on backhaul 4. Use of VLAN tagging on backhaul connections needs at least explanation or reference. VLAN tagging after all is a LAN technique while backhaul typically is WAN.
(Peter L): Yes, we  need to rephrase that to include whatever transport network separation technique suitable (any combination of VLAN, VXLAN, VPN or other).

5. Relation between slicing support and RAN sharing is 5. Relation between slicing support and RAN sharing is not defined in 3GPP. There is a reference in 28.801 to RAN sharing as an example of B2B2X type of service, but relation of that to slicing is not defined. 

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. 

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.

Precondition and assumptions

• The slice separation is based on PLMN-ID <concept not used in 3GPP> (see 3GPP TS 23.251 for an overview), using the symbolic PLMN-ID "NORMAL" for the existing CN "NSSI:Normal" and "PREMIUM" for the new CN "NSSI:Premium" <probably there are two CN components of the NSSI, not two CNs >
• It is known from ONAP R1 how to instantiate and deploy a minimal viable CN and the VLAN tagging (suitable transport netwqork isolation technique, including vLAN/vxLAN/VPN) to use for transport between RAN and that CN. 
• The RAN consist of a set of VNFs and PNFs (together forming a set of 3GPP eNodeB), already integrated and in service as part of PLMN-ID "NORMAL" (the primary PLMN-ID).
• The RAN sharing for the part of the RAN that is to be shared (a sub-set of the cells) is unconstrained, only controlled by the QCI settings provided by the respective CN for each UE and radio bearer.

Post Conditions

• The "Service 2" is operational in all radio cells selected to support this service
• ONAP has knowledge about what resources (VNFs, PNFs and the services provided by these as relevant) are used by NSI A, NSI B or both.
• Some of the observability (PM/FM/events) as produced by DCAE for consumption within ONAP and above is available per NSI

Steps

...

(Peter L): As above, that does not stop us from experimenting with the concept of managing the adding of a CN and PLMN to make the RAN becomming shared between two PLMNs? From a management point of view that is the closest we can get to the use case "add a new slice" in an LTE RAN without waiting for comming standards and implementations?

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.

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.

Precondition and assumptions

• The slice separation is based on PLMN-ID <concept not used in 3GPP> (see 3GPP TS 23.251 for an overview), using the symbolic PLMN-ID "NORMAL" for the existing CN "NSSI:Normal" and "PREMIUM" for the new CN "NSSI:Premium" <probably there are two CN components of the NSSI, not two CNs >
• It is known from ONAP R1 how to instantiate and deploy a minimal viable CN and the VLAN tagging (suitable transport netwqork isolation technique, including vLAN/vxLAN/VPN) to use for transport between RAN and that CN. 
• The RAN consist of a set of VNFs and PNFs (together forming a set of 3GPP eNodeB), already integrated and in service as part of PLMN-ID "NORMAL" (the primary PLMN-ID).
• The RAN sharing for the part of the RAN that is to be shared (a sub-set of the cells) is unconstrained, only controlled by the QCI settings provided by the respective CN for each UE and radio bearer.

Post Conditions

• The "Service 2" is operational in all radio cells selected to support this service
• ONAP has knowledge about what resources (VNFs, PNFs and the services provided by these as relevant) are used by NSI A, NSI B or both.
• Some of the observability (PM/FM/events) as produced by DCAE for consumption within ONAP and above is available per NSI

Steps

• 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.
    
    
• 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.

Proposed Out of Scope for R2:

The following details are proposed to be out of scope:

• How an external application, when requesting a slice (NSI), can also request KPI/SLA stats to be propagated back to the external application.
• For a network with two services beeing provided, how to install new equipment (e.g new RBSes with cells) and include these in the allready existing NSSIs RAN1 and RAN2.
  Is that a special workflow, or can the same workflow be used when extending a service as was used when deploying the service?
• For a network with a service beeing provided, how to selectively remove resorces (example: a few cells or a complete RBS) from that service

...

Proposed Out of Scope for R2:

The following details are proposed to be out of scope:

• How an external application, when requesting a slice (NSI), can also request KPI/SLA stats to be propagated back to the external application.

-------- Temporary Text / Old Text ----------

...