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.

Page History

RevAuthorComment
9/7/17Peter LCopied text from the v4 document, must check the v5 document for additional parts
9/14/17Peter LRewrite 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 in "Steps" and "Proposed out of scope".


Introduction

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.

These services have very different requirements on latency, reliability, availability, mobility, and bandwidth.  Deploying multiple separate networks to support these varying requirements is not practical.  End to End network slicing as defined by 3GPP provides specifications for efficient creation of multiple logical networks[PL1]  sharing a common network infrastructure while meeting the specified service levels for each of the services.  ONAP must support the complete lifecycle management of such network slicing.

Automated Configuration:  Automated configuration of a slice during the instantiation, configuration, and activation phases, a newly created set of identifying parameters automatically configured

Automated reconfiguration. Automated reconfiguration happens during run-time e.g. an active slice can be reconfigured automatically because of a change in the service requirements or service conditions.

Here are some of the network elements participating in E2E Slicing:

Comment: (Vladimir Y.) Aligned to the terms defined in 3GPP (TS 38.401 v0.2.0, TS 23.501 v1.3.0)


In order to enable both an e2e service view and re-usable services from the different segments/domains in the network, the design must be done in such a way as to support:

In order simplify the use case, a network plan containing as few as possible of the above listed participating elements should be used.

Service and Slice concepts according to 3GPP TR 28.801v2.0.1 (2017-09)    (was: 1.3.0)


A service is the business entity that connects properties of the intended function with guaranties (SLA) and other business-related concepts. The term “service” and "service instance" is used interchangeable in the literature – sometimes to denote the blue-print or descriptor for how to create instances of that service, and sometimes to denote a particular instance (the word “instance” is simply omitted).

Comment: (Vladimir Y.) There is no definition of service in 28.801v1.3.0. So this is a new definition which is not really in the scope. Suggest to remove this part. 
Comment (Peter): In both the 1.3.0 and 2.0.1 the sections 4.7 (High-level functional model of business roles) and 4.8 (Types of communication services) attempts at providing some notion of what a "service" can be, including specializations such as a "communication service". My current proposal summary is that we use the word "service" to mean the buisiness agreement, and use other words for describing the realization or implementation of such a service (such as the NSI, NSSI or NFs, or even fractions of a NF...)

A service instance is realized by one or more network slice instances (NSIs), that in turn may consits of network slice subnet instances (NSSIs).

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.


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

 


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

Question (Peter L): Why would these terms be misleading? Why could not the RAN and CN components relate to two separate PLMNs? If we do not discriminate based on PLMN it will become much harder to find RAN products to use to demonstrate this UC. Could you please suggest an alternative for which there exists support in at least some existing RAN and CN implementation?

Comment: (Vladimir Y.) Here is the list:

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

Post Conditions


Steps


Proposed Out of Scope for R2:

The following details are proposed to be out of scope:


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

Comment (Peter L): Do you agree to my color coding below: Green: covered above/resolved   Blue: out of scope/not applicable  Red:remains to be resolved/discussed

Comment: (Vladimir Y.) Sorry, but no. Please refer to the red marks above. In some cases it is difficult to understand the text. 

Goal

Comment (Vladimir Y.) We need to decide what is the genre of this section: is it like Use Case in 3GPP (pre-condition, then steps, then post-condition) or it's Requirements. Currently it's sort of both.

Peter: A Use Case is a format for describing a functional requirement (at least that's the intention from our side when using it here). The use case can be extremely simple (pre- and post conditions and the step "do it") where it is up to the implementation (the use case realization) to decide "how to do it" - or the use case can outline in rough steps how it shall be done - in which case that sequence of rough steps is part of the requirement. Hence, we should not make the use case description too detailed.

Comment (Vladimir Y.) It's not a question of being more detailed or less detailed. Use Cases are expected to use narrative language ("X does A, then Y does B, ...") while requirements are using shall/should type of language ("Z shall be able to do C").

A request from the order handling system (the Service Management Function in OSS/BSS) is received by ONAP. ONAP instantiates the slice without any manual operator interaction. ONAP start actively monitoring the slice.
Question (Peter L): Is this realistic? Won't it be a parameterized request that must match a prepared slice template, and if not all parameters for that template are provided the onap operator would need to fill that in? How do we distinguish the NS-MF and NSS-MF from other "functions" implemented by ONAP?

Comment (Shekar S): I might have rephrased the goal as "Slice-related requests from a system upstream of ONAP (e.g. Ordering system, Operator GUI) is received by ONAP. ONAP performs the slice-related request; upon successful completion of the request, ONAP starts or continues to monitor the Slice. It is assumed that the request contains all of the required information necessary for completing the request (based on the design specification)". I used the phrase "Slice-related request" because there could be many types of requests (e.g. Initial creation of a slice, Modification of an existing Slice, etc.)


Comment (Vladimir Y.) I agree with Shekar: it can be any authorized caller. We can say "A request (for example, from ...) is received ...". The syntax of the request can be as in IFA013 (Instantiate NS operation with reference to NSD plus reference to NS DF).

Comment (Peter L): I expect there is or will be some form of mapping from such a request to e.g. a TOSCA description of how to fulfill the request, and that the parameters sent must populate all input variables mandated by that description. The fact that it is a slicing request could be totally unknown to the ONAP system - or we could consider it beneficial to name or classify some TOSCA descriptors as e.g. "slicing" or whatever categories the operator sees fit to use.

Comment (Vladimir Y.) Need a link to the reference model (TMN?). In 3GPP reference model there is no Service Management Function (yet).

Use Case 1: Design slice template

Use Case 2: Instantiate slice automatic trigger by request from BSS system

Use Case 3: Manage the slice SLA/SLO

Comment (Vladimir Y.) These "use cases" (maybe better call it "scenarios"? We already have Use Cases) need clarification. How #2 is different from #1?

If we already  refer to 28.801, there is description of network slice LCM operations: create (instantiate), activate, de-activate etc. 

Comment (Vladimir Y.) This part below is in the format of requirements, not fully in line with previous

The ONAP Design Studio (SDC) must support the following capabilities

Comment (Vladimir Y.) I have a general comment to this part. We already have a reference to NSSI concept in 28.801. Network Slice Instance (NSI) is in fact a particular case of the NSSI. The concept of the NSSI  can easily be mapped onto the "Network Service" (NS) in ETSI NFV. If we agree to go over this path, we will be able to "copy" where reasonable, the concepts, operations and structures defined in ETSI and accommodated in 3GPP. This includes also E2E vs. RAN-only slicing. If the group is OK with such direction, I can provide the text.

Comment (Peter L): Please go ahead.
What I think we also need to figure out is how the RAN concept of a signle radio cell should be described (several of those appear as we instantiate an eNB - regardles of physical or partially virtualized) and how such cells can be shared between multipple slices (with or without guaranties for sertain capacity share within the cell) or divided between them, all depending on levels of isolation expected and what type of sharing and resource guaranties can be offered by the eNB. At the end, those capabilities sometimes vary between vendors and models of the eNB. For NR it seems we will not have radio cells in the same sense in active mode and thus we (presently, at least I) cannot propose any formulations about how to share or divide resources for a NR system - apart from the very simple examples with separate frequency bands.

Comment (Vladimir Y.) The most common RAN slicing technique probably will be that all RAN nodes belong to all slices ("shared" nodes) and are provisioned with certain slicing-aware policy of Radio resource allocation. Allocation of frequency channels to particular slices is possible, but probably will not be very common. I don't see any difference between 4G and NR with this regard. 

The ONAP execution framework should support the following activities.

Note: ONAP also needs to be able to instantiate the required ONAP components to support the slice.


-          <<<<<< Lets work on a figure to put here to help the understanding.  This would be good to describe RAN scope vs E2E scope (and EPC scope, etc.). >>>>>>