Versions Compared

Key

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

...

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.

Comment (Vladimir Y.) The definition of NSSI in 28.801 is different: includes recurrence.

...

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.

Gliffy Diagram
nameServices and Network Slice Instances

...

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

  • 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

...