Versions Compared

Old Version 22

changes.mady.by.user Peter Loborg

Saved on

compared with

New Version 23

changes.mady.by.user Peter Loborg

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • The slice separation is based on PLMN-ID, using the symbolic PLMN-ID "NORMAL" for the existing CN "NSSI:Normal" and "PREMIUM" for the new CN "NSSI:Premium"
  • It is known from ONAP R1 how to instantiate and deploy a minmal minimal viable CN and the VLAN tagging to use for transport between RAN and that CN.
  • The RAN consist of a set of VNFs and PNFs (together forming a set of distributed, physical 3GPP eNodeB nodes), 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.

...

  • 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 VLAN to be used for control and user data within an NSI
    • Per CN node type: Create yet another node connected to the proper VLAN
    • 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.
      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 MSO 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 MSO appies theparameters to the NSI template and executes the request.
      Question: Any improv,ments needed in the interaction between the external part and the MSO 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.
  • Definition of slice related closed loop activities via the ONAP runtime – this functionality is generic regardless if a slice is involved or not, and thus it does not belong in a use case targeting slice management.
    Exception: If the functionality is already in place, but we only lack the capability to focus selected automation on data and resources related to a specific slice only – in that case it’s viable to include the extension of existing automation functionality to also become slice aware.

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


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. 

  • Define model/attributes for slice and its relationship to underlying VNF/Resources
  • Design parameters needed for use by ONAP Optimization Framework (HAS) for decomposition and placement of resources needed for the slice

  • Design recipes/models for instantiating slices, modifying / expanding / shrinking slices, etc.

  • Design recipes/models for instantiating dedicated resources (e.g. AR / VR server)
    Question (Stephen Terrill): what constitutes a dedicated resource?  I agree we need to do this, but how to treat e.g. transport tin this context.
    Comment (Shekar S): I would assume that the upfront planning/design specifies what is dedicated and what is shared (part of the slice definition)

    Comment (Vladimir Y.) There is no explanation in NGMN and 3GPP what "dedicated resources" (for the slice) are. I suggest that we either explain what "dedicated resources"are or remove the notion of "dedicated resources"
    Comment (Peter L) Whatever VNFs we decide to include in the CN NSSI would include such special-purpose VNFs - i.e. I can't see how it differs from any other VNF?

  • Create an abstracted view of the services provided by the RAN, Transport, Core network functions, and create configuration parameters for these
  • Author policy definitions and their  enforcement points (VNF, Controllers, DCAE / SO, etc.)
  • Specify fault, performance and log data collection, Analytics, thresholds for violations, and associated corrective action

...