Comment (Vladimir Y.) The whole text is about E2E slicing, not RAN slicing. See e.g. the diagram
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
| Rev | Author | Comment |
|---|---|---|
| 9/7/17 | Peter L | Copied text from the v4 document, must check the v5 document for additional parts |
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 vertical 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:
- Distributed Radio Element
- Distributed BBU
- Centralized BBU and nrt-L2 function (CU-UP)
- Centralized Radio Control Unit (CU-CP)
- Layer 3 Transport Elements
- NG S/P Gateway
- NG PCRF
- Etc.
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:
- 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.801v1.3.0
A service is the business entity that connects properties if the intended function with guaranties (SLA) and other business-related concepts. The term “service” 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.
A service instance is realized by one or more network slice instances (NSIs).
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).
Goal
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.)
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
The ONAP Design Studio (SDC) must support the following capabilities
- 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)- 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
The ONAP execution framework should support the following activities.
- The Orchestrator executes the E2E Slice creation / modification recipe
- Instantiate any new VNF needed for the slice
- Pass configuration specifications, as per abstraction standards, to the RAN controller for radio slice creation, and packet core for core slice creation
- Pass QoS, bandwidth, resiliency requirements for transport network to SDN-Controller
- Configure the vEPC using App-C, orchestrated by EPC resource and service orchestration
- Start data collection and service monitoring at the relevant DCAE locations
- Track inventory/topology of slices and their states with AAI
- Collect data and perform the needed analytics about the various slices
- Trigger corrective / remedial actions for detected network impairments and service level violations
- Closed loop action initiated using SO and / or controllers
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.). >>>>>>
Post-Condition
The Network slice instance is operational. ONAP is actively collecting measurement information for the slice. All related Policies are deployed and active across the ONAP components.