Versions Compared

Old Version 26

changes.mady.by.user Peter Loborg

Saved on

compared with

New Version 27

changes.mady.by.user Vladimir Yanover

Saved on

Key

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

...

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.

...

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)

  • gNB
  • gNB-CU
  • gNB-DU
  • CU-C
  • CU-U
  • DU
  • UPF
  • PCF
  • 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.
    Comment: (Vladimir Y.) The text of the bullet below aligned to the terms defined in 3GPP (TS 38.401 v0.2.0 and TR 28.801 v2.0.1)
  • Support the network to provide isolation of physical resources and between the slices (to the extent that is reasonable according to the networks capabilities).

...

Comment (Peter L): Re-writing this section, trying to catch the commens. Old text available at the end.

Goal for this Use Case:


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. Use of the label "PLMN-ID" is misleading as slice instances and their RAN or CN components are not separated PLMNs

Goal for this Use Case:

To show that ONAP 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.

Precondition and assumptions

  • The slice separation is is based on PLMN-ID <concept not used in 3GPP>, using the symbolic PLMN-ID "NORMAL" for the existing CN "NSSI:Normal" and "PREMIUM" for the new CN "NSSI:Premium" <probably there are two CN components of the NSSI, not two CNs >
  • It is known from ONAP R1 how to instantiate and deploy a 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 3GPP eNodeB), 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.

Post Conditions

  • 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

...