...
- Abstraction of the services offered by the different domains/segments
- Ability to tie the services offered by the different domains/segments into an e2e service.
- Support the network to provide isolation between the slices (to the extent that is reasonable according to the networks capabilities).
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 if of the intended function with guaranties (SLA) and other business-related concepts. The term “service” is 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.) 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...
| Gliffy Diagram | ||||
|---|---|---|---|---|
|
...
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 extgremely simple (pre- and post conditions and the step "do it") where it is up to the implementation (the use case realization) to dicide "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.
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 (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).
...
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.
- 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
...