0% found this document useful (0 votes)

406 views75 pages

O RAN - WG1.Slicing Architecture R003 v13.00

ORAN Slicing Architecture v13 full document

Uploaded by

Gaurav Jain

We take content rights seriously. If you suspect this is your content, claim it here.

Available Formats

Download as PDF, TXT or read online on Scribd

0% found this document useful (0 votes)

406 views75 pages

O RAN - WG1.Slicing Architecture R003 v13.00

ORAN Slicing Architecture v13 full document

Uploaded by

Gaurav Jain

We take content rights seriously. If you suspect this is your content, claim it here.

Available Formats

Download as PDF, TXT or read online on Scribd

O-RAN.WG1.Slicing-Architecture-R003-v13.

00
Technical Specification

O-RAN Work Group 1 (Use Cases and Overall Architecture)

Slicing Architecture

Copyright © 2024 by the O-RAN ALLIANCE e.V.

The copying or incorporation into any other work of part or all of the material available in this specification in any form
without the prior written permission of O-RAN ALLIANCE e.V. is prohibited, save that you may print or download extracts
of the material of this specification for your personal use, or copy the material of this specification for the purpose of sending
to individual third parties for their information provided that you acknowledge O-RAN ALLIANCE as the source of the
material and that you inform the third party that these conditions apply to them and that they must comply with them.

O-RAN ALLIANCE e.V., Buschkauler Weg 27, 53347 Alfter, Germany

Register of Associations, Bonn VR 11238, VAT ID DE321720189

O-RAN.WG1.Slicing-Architecture-R003-v13.00

Contents
Foreword............................................................................................................................................................. 4
Modal verbs terminology ................................................................................................................................... 4
1 Scope ........................................................................................................................................................ 5
2 References ................................................................................................................................................ 5
2.1 Normative references ......................................................................................................................................... 5
2.2 Informative references ....................................................................................................................................... 6
3 Definition of terms, symbols and abbreviations ....................................................................................... 7
3.1 Terms ................................................................................................................................................................. 7
3.2 Symbols ............................................................................................................................................................. 8
3.3 Abbreviations..................................................................................................................................................... 8
4 Slicing Overview ...................................................................................................................................... 9
5 High-Level O-RAN Slicing Use Cases .................................................................................................. 10
5.1 O-RAN Slicing Use Cases ............................................................................................................................... 10
5.2 O-RAN Slice Subnet Management and Provisioning Use Cases .................................................................... 10
5.2.1 O-RAN Slice Subnet Instance Creation ..................................................................................................... 11
5.2.2 O-RAN Slice Subnet Instance Activation .................................................................................................. 12
5.2.3 O-RAN Slice Subnet Instance Modification .............................................................................................. 15
5.2.4 O-RAN Slice Subnet Instance Deactivation ............................................................................................... 16
5.2.5 O-RAN Slice Subnet Instance Termination ............................................................................................... 18
5.2.6 O-RAN Slice Subnet Instance Configuration............................................................................................. 19
5.2.7 O-RAN Slice Subnet Feasibility Check ..................................................................................................... 20
5.3 O-RAN Slicing Use Cases ............................................................................................................................... 22
5.3.1 Use Case 1: RAN Slice SLA Assurance .................................................................................................... 22
5.3.2 Use Case 2: Multi-Vendor Slices ............................................................................................................... 23
5.3.3 Use Case 3: NSSI Resource Allocation Optimization................................................................................ 24
6 O-RAN Slicing Principles and Requirements ........................................................................................ 27
6.1 General Principles ............................................................................................................................................ 27
6.2 Slicing Requirements ....................................................................................................................................... 27
6.2.1 Functional Requirements............................................................................................................................ 27
6.2.2 Non-Functional Requirements ................................................................................................................... 30
7 O-RAN Reference Slicing Architecture ................................................................................................. 31
7.1 O-RAN Reference Slicing Architecture .......................................................................................................... 31
7.2 Non-RT RIC .................................................................................................................................................... 31
7.3 Near-RT RIC ................................................................................................................................................... 32
7.4 O-RAN Central Unit (O-CU-CP, O-CU-UP) .................................................................................................. 32
7.5 O-RAN Distributed Unit (O-DU) .................................................................................................................... 32
7.6 A1 Interface ..................................................................................................................................................... 33
7.7 E2 Interface ...................................................................................................................................................... 33
7.8 O1 Interface ..................................................................................................................................................... 33
7.9 O2 Interface ..................................................................................................................................................... 33
7.10 Transport Network Slicing ............................................................................................................................... 34
8 O-RAN Slice Subnet Provisioning Procedures ...................................................................................... 36
8.1 O-RAN Slice Subnet Instance (O-NSSI) Allocation Procedure ...................................................................... 36
8.2 O-RAN Slice Subnet Instance (O-NSSI) Modification Procedure .................................................................. 39
8.3 O-RAN Slice Subnet Instance (O-NSSI) Deallocation Procedure ................................................................... 41
8.4 O-RAN Slice Subnet Instance (O-NSSI) Feasibility Check and Reservation Procedure ................................ 44
8.4.1 Introduction ................................................................................................................................................ 44
Annex A (informative): Implementation Options ............................................................................................ 44
A.1 Implementation Options .................................................................................................................................. 44
A.1.1 3GPP and ETSI NFV-MANO based O-RAN Slicing Architecture Implementation Option ..................... 44

________________________________________________________________________________________________
© 2024 by the O-RAN ALLIANCE e.V. Your use is subject to the copyright statement on the cover page of this specification. 2
O-RAN.WG1.Slicing-Architecture-R003-v13.00

A.1.2 ONAP based O-RAN Slicing Architecture Implementation Option .......................................................... 46

Annex B (informative): Transport Network Slicing......................................................................................... 47
B.1 Transport Network Slicing Use Cases ............................................................................................................. 47
Annex C (informative): Slicing Terminology .................................................................................................. 55
C.1 Slicing and 3GPP Slice Modeling Terminology Awareness ........................................................................... 55
C.1.1 Conceptual Differences Between 3GPP SA2 and SA5 .............................................................................. 55
C.1.2 Name Containment Limitation ................................................................................................................... 55
C.1.3 Network Slice Subnet is a Purposeful Generic Collection ......................................................................... 56
C.1.4 Slicing Instance Example ........................................................................................................................... 57
C.1.5 NSSI Slice Profile and PLMNInfo ............................................................................................................. 58
C.1.6 Managed Functions Have a List of PLMNInfo .......................................................................................... 59
C.1.7 Single Network Slice Selection Assistance Information (S-NSSAI) ......................................................... 59
Annex D (informative): Multi-Operator Slice RAN Management Services Exposure .................................... 60
D.1 RAN Management Services Exposure for Multi-Operator Slice ..................................................................... 60
D.1.1 Management Services Exposure for Multi-Operator Slice - Relevant Standards....................................... 61
D.1.2 Concepts of Management Services Exposure for Multi-Operator Slice..................................................... 62
D.1.3 Management Aspects of External Exposure of MnS Related to RAN Slicing ........................................... 63
D.1.4 Multi-Operator Slice: High Level Use Cases and Potential Requirements for Exposure fo MnS
Related to RAN Slicing .............................................................................................................................. 65
Annex (informative): Revision history ............................................................................................................. 74
Annex (informative): History ........................................................................................................................... 75

Foreword
This Technical Specification (TS) has been produced by O-RAN Alliance.

The content of the present document is subject to continuing work within O-RAN and may change following formal O-
RAN approval. Should the O-RAN Alliance modify the contents of the present document, it will be re-released by O-
RAN with an identifying change of version date and an increase in version number as follows:

version xx.yy.zz

where:

xx: the first digit-group is incremented for all changes of substance, i.e. technical enhancements, corrections,
updates, etc. (the initial approved document will have xx=01). Always 2 digits with leading zero if needed.

yy: the second digit-group is incremented when editorial only changes have been incorporated in the document.
Always 2 digits with leading zero if needed.

zz: the third digit-group included only in working versions of the document indicating incremental changes during
the editing process. External versions never include the third digit-group. Always 2 digits with leading zero if
needed.

Modal verbs terminology

In the present document "shall", "shall not", "should", "should not", "may", "need not", "will", "will not", "can" and
"cannot" are to be interpreted as described in clause 3.2 of the O-RAN Drafting Rules (Verbal forms for the expression
of provisions).

"must" and "must not" are NOT allowed in O-RAN deliverables except when used in direct citation.

1 Scope
The present document specifies the high level O-RAN slicing related use cases, requirements and architecture. While
some of the requirements are derived from use cases, some of the relevant SDO requirements are captured as they have
impact on O-RAN functions. Along with requirements and reference slicing architecture, slicing related impact to O-RAN
functions and interfaces are captured as well.

2 References

2.1 Normative references

References are either specific (identified by date of publication and/or edition number or version number) or non-specific.
For specific references, only the cited version applies. For non-specific references, the latest version of the referenced
document (including any amendments) applies.

NOTE: While any hyperlinks included in this clause were valid at the time of publication, O-RAN cannot guarantee
their long term validity.

The following referenced documents are necessary for the application of the present document.

[1] 3GPP TS 22.261: Technical Specification Group Services and System Aspects; Service requirements
for the 5G system; Stage 1, Release 16, December 2019

[2] 3GPP TS 23.501: Technical Specification Group Services and System Aspects; System Architecture
for the 5G System; Stage 2, Release 16, December 2019

[3] 3GPP TS 28.526: Technical Specification Group Services and System Aspects; Telecommunication
management; Life Cycle Management (LCM) for mobile networks that include virtualized network
functions; Procedures, Release 15, December 2018

[4] 3GPP TS 28.531: Management and orchestration; Provisioning, Release 16, March 2020.

[5] 3GPP TS 28.532: Management and orchestration; Generic Management Services, Release 16, April
2021

[6] Void

[7] 3GPP TS 28.541: Management and orchestration; 5G Network Resource Model (NRM); Stage 2
and stage 3, Release 16, January 2020

[8] 3GPP TS 28.552: Technical Specification Group Services and System Aspects; Management and
orchestration; 5G performance measurements, Release 16, January 2020

[9] 3GPP TS 32.300: Technical Specification Group Services and System Aspects; Telecommunication
management; Configuration Management (CM); Name convention for managed objects, Release
16, July 2020

[10] 3GPP TS 38.300: NR and NG-RAN Overall Description, Release 16, January 2020.

[11] ETSI GS NFV 003: Network Functions Virtualisation (NFV); Terminology for Main Concepts in
NFV, 1.4.1, August 2018

[12] Void

[13] O-RAN.WG1.O1-Interface.0-v04.00: O-RAN Operations and Maintenance Interface Specification

[14] Void

[15] Void

[16] Void

[17] Void

[18] O-RAN.WG6.ORCH-USE-CASES-v04.00: Orchestration Use Cases and Requirements for O-RAN

Virtualized RAN

[19] Void

[20] Void

[21] Void

[22] 3GPP TS 23.501: System architecture for the 5G System (5GS), Release 17, June 2022

[23] 3GPP TS 28.530: Management and orchestration; Concepts, use cases and requirements, Release
17, September 2022

[24] O-RAN.WG11.Security-Protocols-Specification: “O-RAN Working Group 11 (Security Working

Group) Security Protocols Specifications”

2.2 Informative references

NOTE: While any hyperlinks included in this clause were valid at the time of publication, O-RAN cannot guarantee
their long term validity.

The following referenced documents are not necessary for the application of the present document but they assist the user
with regard to a particular subject area.

[i.1] 3GPP TR 21.905: “Vocabulary for 3GPP Specifications”.

[i.2] 3GPP TS 23.003: “Technical Specification Group Core Network and Terminals; Numbering,
addressing and identification”, Release 16, June 2021.

[i.3] 3GPP TR 28.801: “Study on management and orchestration of network slicing for next generation
network”, Release 15, January 2018.

[i.4] O-RAN_Study_ORAN_Slicing_Technical_Report.v02.00: “Study on O-RAN Slicing”, Technical

Report.

[i.5] 3GPP TS 23.222: “Functional architecture and information flows to support Common API
Framework for 3GPP Northbound APIs; Stage 2”, Release 17, June 2021.

[i.6] 3GPP TS 29.222: “Common API Framework for 3GPP Northbound APIs”, Release 17, December
2021.

[i.7] 3GPP TR 28.824: “Study on network slice management capability exposure”, Release 17, July 2022.

[i.8] 3GPP TR 28.811: “Management and orchestration; Study on Network Slice Management
Enhancement”, Release 17, December 2021.

[i.9] 3GPP TR 23.700-99: “Study on Network Slice Capability Exposure for Application Layer
Enablement”, Release 18, September 2022.

[i.10] Slicenet, https://5g-ppp.eu/slicenet/.

[i.11] NGMN Alliance: “5G P1 Requirements & Architecture “Description of Network Slicing Concept”,
Version 1.0.8, September 2016.

[i.12] O-RAN.WG1.OAM-Architecture-v04.00: “O-RAN WG1 Operations and Maintenance

Architecture”.

[i.13] O-RAN.WG2.A1.GA&P-v01.00: “O-RAN Working Group 2; (A1 interface: General Aspects and
Principles)”.

[i.14] O-RAN.WG3.E2GAP-v01.00: “O-RAN Working Group 3; Near-Real-time RAN Intelligent

Controller Architecture & E2 General Aspects and Principles”.

[i.15] O-RAN.WG6.CAD-V02.01: “Cloud Architecture and Deployment Scenarios for O-RAN

Virtualized RAN”.

[i.16] O-RAN.WG9.XPSAAS-v01.00: “O-RAN Open Transport Working Group 9 Xhaul Packet Switched
Architectures and Solutions”.

[i.17] O-RAN.WG9.XTRP-REQ-v01.00: “O-RAN Open Xhaul Transport Working Group 9 Xhaul

Transport Network Requirements”.

[i.18] 3GPP TS 28.533: “Management and orchestration; Architecture framework”, Release 17, March
2022.

[i.19] O-RAN.WG9.XTRP-MGT.0-v04.00: “O-RAN Open X-haul Transport Working Group

Management interfaces for Transport Network Elements”

3 Definition of terms, symbols and abbreviations

3.1 Terms
For the purposes of the present document, the terms and definitions [given in [i.1] and the following] apply. A term defined
in the present document takes precedence over the definition of the same term, if any, in [i.1].

A1: Interface between Non-RT RIC and Near-RT RIC to enable policy-driven guidance of Near-RT RIC
applications/functions, and support AI/ML workflow.

A1 policy: Type of declarative policies expressed using formal statements that enable the Non-RT RIC function in the
SMO to guide the Near-RT RIC function, and hence the RAN, towards better fulfilment of the RAN intent.

A1 enrichment information: Information utilized by Near-RT RIC that is collected or derived at SMO/Non-RT RIC
either from non-network data sources or from network functions themselves.

E2: Interface connecting the Near-RT RIC and one or more O-CU-CPs, one or more O-CU-UPs, and one or more O-
DUs.

E2 Node: A logical node terminating E2 interface. In the present document, O-RAN nodes terminating E2 interface are:

- for NR access: O-CU-CP, O-CU-UP, O-DU or any combination.

- for E-UTRA access: O-eNB.

FCAPS: Fault, Configuration, Accounting, Performance, Security.

Near-RT RIC: O-RAN Near-Real-Time RAN Intelligent Controller: A logical function that enables near-real-time
control and optimization of RAN elements and resources via fine-grained data collection and actions over E2 interface.

Non-RT RIC: O-RAN Non-Real-Time RAN Intelligent Controller: A logical function that enables non-real-time control
and optimization of RAN elements and resources, AI/ML workflow including model training and updates, and policy-
based guidance of applications/features in Near-RT RIC.

NMS: A Network Management System.

Network Service: Composition of network function(s) and/or network service(s), as specified in ETSI GS NFV 003 [11].

Network Slice: A network slice is a set of run-time network functions, and resources to run these network functions,
forming a complete instantiated logical network to meet certain network characteristics required by the service instance(s).
See reference NGMN 5G P1 Description of a Network Slice [i.11].

Network Slice Instance (NSI): A set of network functions and the resources for these network functions which are
arranged and configured, forming a complete logical network to meet certain network characteristics as specified in 3GPP
TS 23.501 [2].

NetworkSliceSubnet MOI (NSSI): A generic recursive collection or set allowing non-restricted grouping of managed
functions and EP_Transport endpoint(s). Non-restricted means that it is not bound by name-containment rules, as
specified in 3GPP TS 32.300 [9]. Each collection can have a “purpose” represented by the sliceProfile(s) associated with
the collection (3GPP TS 28.541 [7], figure 6.2.1-1).

O-CU-CP: O-RAN Central Unit – Control Plane: A logical node hosting the RRC and the control plane part of the PDCP
protocol.

O-CU-UP: O-RAN Central Unit – User Plane: A logical node hosting the user plane part of the PDCP protocol and the
SDAP protocol.

O-DU: O-RAN Distributed Unit: A logical node hosting RLC/MAC/High-PHY layers based on a lower layer functional
split.

O-RU: O-RAN Radio Unit: A logical node hosting Low-PHY layer and RF processing based on a lower layer functional
split.

O1: Interface between the Service Management and Orchestration framework and O-RAN managed elements

O2: Interface between the Service Management and Orchestration framework and the O-Cloud

RAN: Generally referred as Radio Access Network. In terms of this document, any component below Near-RT RIC per
O-RAN architecture, including O-CU-CP/O-CU-UP/O-DU/O-RU.

Resource isolation: Regime of resource management when a resource used by one network slice instance cannot be
shared with another network slice instance. See 3GPP TR 28.801 [i.3].

Single Network Slice Selection Assistance Information (S-NSSAI): An S-NSSAI is comprised of an SST (Slice/Service
type) and an optional SD (Slice Differentiator) field (3GPP TS 28.541 [7], clause 4.3.37).

3.2 Symbols
Void

3.3 Abbreviations
For the purposes of the present document, the abbreviations [given in [i.1] and the following] apply. An abbreviation
defined in the present document takes precedence over the definition of the same abbreviation, if any, in [i.1].

eNB eNodeB (applies to LTE)

gNB gNodeB (applies to NR)

KPI Key Performance Indicator

KQI Key Quality Indicator

Near-RT RIC O-RAN Near-Real-Time RIC

NFMF Network Function Management Function

Non-RT RIC O-RAN Non-Real-Time RIC

NS Network Service

NSMF Network Slice Management Function

NSSMF Network Slice Subnet Management Function

O-DU O-RAN Distributed Unit

O-RU O-RAN Radio Unit

PNF Physical Network Function

PRB Physical Resource Block

RIC O-RAN RAN Intelligent Controller

RRM Radio Resource Management

SD Slice Differentiator

SDO Standards Developing Organizations (For ex: 3GPP, ETSI, ONAP, O-RAN)

SMO Service and Management Orchestration

SST Slice/Service Type

VNF Virtual Network Function

4 Slicing Overview
Network slicing is expected to play a critical role in 5G networks because of various use cases and services 5G will
support. It allows a network operator to provide services tailored to customers’ requirements. Network slice is defined as
a logical network with a bundle of specified network services over a common network infrastructure. A single physical
network is sliced into multiple virtual networks that may support different service types over a single RAN. 3GPP has
standardized 4 different service types: eMBB, URLLC, MIoT and V2X [i.2].

3GPP defined 5G architecture and procedures containing network slicing and related concepts in Release 15. Furthermore,
management and orchestration of 5G networks featuring slicing was defined in the 3GPP specifications. Other standard
groups e.g. GSMA, ETSI NFV-MANO, ETSI ZSM and ONAP focus on the different aspects of network slicing. Further
information regarding network slicing and other SDO’s contributions was discussed in the Study on O-RAN Slicing
Technical Report [i.4].

An example RAN slicing deployment of O-RAN network functions based on the select initial deployment option, option
B as described in [i.15], is shown in figure 4-1, with some of the network functions shared between RAN slice subnets
(such as O-CU-CP, O-DU, O-RU) and some network functions dedicated to a particular RAN slice subnet (such as O-
CU-UP).

Figure 4-1: Example O-RAN slicing deployment

5 High-Level O-RAN Slicing Use Cases

5.1 O-RAN Slicing Use Cases

This clause contains high-level O-RAN slicing use cases that O-RAN is expected to support. Slicing requirements are
derived from the specified use cases.

5.2 O-RAN Slice Subnet Management and Provisioning Use

Cases
Network slicing is conceived to be an end-to-end feature that includes the core network, transport network, and the RAN.
Although 3GPP has started defining network slicing support with Release 15, slicing in O-RAN needs to be further
addressed in line with 3GPP to achieve deployable network slicing in an open RAN environment.

Management aspects of network slicing such as Network Slice Instances (NSI) and Network Slice Subnet Instances
(NSSI) are specified in 3GPP TS 28.531 [4]. While NSI refers to an end-to-end network slice, NSSI refers to a part of an
end-to-end network slice as a RAN slice subnet. The provisioning of network slicing includes the four phases which are
preparation, commissioning, operation, and decommissioning. The NSI/NSSI provisioning operations shall include:

- Create an NSI/NSSI;

- Activate an NSI/NSSI;

- De-active an NSI/NSSI;

- Modify an NSI/NSSI;

- Terminate an NSI/NSSI.

Please refer to 3GPP TS 28.531 [4], clause 4.1 for further details of NSI and NSSI lifecycle management and provisioning.

The following clauses define the use cases and procedures necessary for O-RAN slice subnet management that is in-line
with 3GPP slice management framework. For this purpose, use cases such as slice subnet creation, activation,
modification, deactivation, termination, configuration, and feasibility check are utilized by O-RAN architecture.

5.2.1 O-RAN Slice Subnet Instance Creation

The context of the O-RAN slice subnet instance creation use case is captured in table 5.2.1-1.

Table 5.2.1-1: O-RAN slice subnet instance creation use case

<<Uses>>
Use Case Stage Evolution / Specification
Related use

Creation of a new O-RAN network slice subnet instance (O-NSSI) or use an

Goal existing O-NSSI to satisfy the RAN slice subnet related requirements (3GPP TS
28.531 [4], clause 5.1.2).

NSSMS_C, such as NSMF, who acts as the network slice subnet management
service consumer.

NSSMS_P, such as NSSMF, who acts as the network slice subnet management
service provider.

NFMS_P, such as SMO OAM functions or NFMF, who acts as the network
Actors and Roles function management service provider.

O-Cloud M&O, who acts as the O-Cloud management and orchestration

provider within SMO.

Non-RT RIC

O-RAN Network Functions: NFs such as Near-RT RIC, O-CU-CP, O-CU-UP, O-

DU and O-RU.

NSSMS_P has the knowledge of O-Cloud M&O to manage the lifecycle of VNFs
Assumptions
and interconnection between the VNFs and PNFs.

VNF packages for virtualized O-RAN network functions to be included in the O-

Pre-conditions
RAN slice subnet instance have been already on-boarded.

NSSMS_P receives request for a network slice subnet instance. The request
Begins when
contains network slice subnet related requirements.

NSSMS_P checks the feasibility of the request, based on the received network O-RAN slice
Step 1 (M) slice subnet related requirements. subnet feasibility
check

Step 2 (M) NSSMS_P decides to create a new O-NSSI or use an existing O-NSSI.

If an existing O-NSSI is decided to be used, NSSMS_P should trigger

modification of the existing O-NSSI to satisfy the network slice subnet related O-RAN slice
requirements. subnet instance
Step 3 (M)
modification use
Go to “Step 11”.
case
Otherwise, NSSMS_P triggers creation of a new O-NSSI, continue with Step 4

Step 4 (M) NSSMS_P derives the requirements for the constituent NSSI(s).

<<Uses>>
Use Case Stage Evolution / Specification
Related use

(O-RAN) slice
If the required O-NSSI contains constituent NSSI(s) managed by other subnet instance
NSSMS_P(s), NSSMS_P may trigger creation of respective constituent creation use case
NSSI(s) through other NSSMS_P(s) which manages the constituent NSSI(s). (to create
Step 5 (O)
In that case, NSSMS_P receives the constituent NSSI information from the constituent
other NSSMS_P(s) and associates the constituent NSSI(s) with the required O- (O-)NSSI(s)
NSSI. managed by other
NSSMS_P(s))

NSSMS_P determines the service-related requirements and triggers a service

request to O-Cloud M&O for instantiation of virtual O-RAN network functions
Step 6 (M) and virtual links within the determined O-Cloud(s).

Based on the service request, O-Cloud M&O performs corresponding NF

instantiation procedures and virtual link establishment.

NSSMS_P associates the service response received from O-Cloud M&O with
Step 7 (M)
the corresponding O-NSSI.

NSSMS_P uses (O-RAN) NF provisioning service exposed by NFMS_P to

Step 8 (M)
configure (O-)NSSI constituents.

NSSMS_P configures the O-NSSI MOI with each constituent (O-)NSSI MOI
Step 9 (M)
identifier.

NSSMS_P triggers O-RAN TN manager coordination procedure to establish

Step 10 (M)
necessary links such as for A1, E2, and midhaul and fronthaul connectivity.

NSSMS_P notifies Non-RT RIC with network slice subnet requirements and
Step 11 (M)
respective O-NSSI information.

NSSMS_P notifies NSSMS_C with the resulting status of this process and
Step 12 (M)
relevant O-NSSI information.

O-RAN O-NSSI and relevant O-RAN NFs are created, and Non-RT RIC is
Ends when
configured with slice requirements and O-NSSI information.

Exceptions One of the steps identified above fails.

Post Conditions O-NSSI is ready to satisfy the network slice subnet related requirements.

Traceability REQ-SL-FUN14, REQ-SL-FUN20 - REQ-SL-FUN27

5.2.2 O-RAN Slice Subnet Instance Activation

The context of the O-RAN slice subnet instance activation use case is captured in table 5.2.2-1.

Table 5.2.2-1: O-RAN slice subnet instance activation use case

<<Uses>>
Use Case Stage Evolution / Specification
Related use

Activation of an O-RAN network slice subnet instance (O-NSSI) (3GPP TS

Goal
28.531 [4], clause 5.1.10).

<<Uses>>
Use Case Stage Evolution / Specification
Related use

NSSMS_C, such as NSMF, who acts as the network slice subnet management
service consumer.

NSSMS_P, such as NSSMF, who acts as the network slice subnet management
service provider.
Actors and Roles
NFMS_P, such as SMO OAM functions or NFMF, who acts as the network
function management service provider.

O-RAN network functions: NFs such as Near-RT RIC, O-CU-CP, O-CU-UP, O-

DU and O-RU.

Assumptions NSSMS_P is providing services to authorized consumers.

An O-NSSI has already been created and it is inactive.

As an example, the O-NSSI may contain inactive O-RAN NFs:- Near-RT

RIC is installed and active

- O-CU-CP installed (i.e. operationalState = enabled), but not yet

activated (i.e. administrativeState = locked).

- O-CU-UP installed (i.e. operationalState = enabled), but not yet

Pre-conditions activated (i.e. administrativeState = locked).

- O-DU installed (i.e. operationalState = enabled), but not yet activated

(i.e. administrativeState = locked) (3GPP TS 28.541 [7], figure
B.2.2).

- O-RU physically installed (i.e. operationalState = enabled), but not

yet activated (i.e. administrativeState = locked).

See NOTE 1.

NSSMS_P decides to activate the O-NSSI based on the received network slice
Begins when
subnet related request from its authorized consumer NSSMS_C.

NSSMS_P receives a request from NSSMS_C to activate the O-NSSI (via NSSI
Step 1 (M) provisioning service with operation modifyMOIAttributes (3GPP TS 28.531 [4],
table 6.2-1) to change administrativeState of the O-NSSI to unlocked.)

NSSMS_P identifies the inactive constituents within the O-NSSI and decides to
activate those constituents which can be NFs or NSSI.

As an example, NSSMS_P activates the following inactive O-RAN NF

constituents:

- the O-CU-CP NF constituent, and invokes NF provisioning service with

Step 2 (M) operation modifyMOIAttributes (3GPP TS 28.531 [4], table 6.3-1) to
request NFMS_P to activate the O-CU-CP by changing the
administrativeState of the O-CU-CP to unlocked.

See NOTE 2.

- the O-CU-UP NF constituent, and invokes NF provisioning service with

operation modifyMOIAttributes (3GPP TS 28.531 [4], table 6.3-1) to

<<Uses>>
Use Case Stage Evolution / Specification
Related use

request NFMS_P to activate the O-CU-UP by changing the

administrativeState of the O-CU-UP to unlocked.

See NOTE 3, NOTE 4.

- the O-DU NF constituent, and invokes NF provisioning service with

operation modifyMOIAttributes (3GPP TS 28.531 [4], table 6.3-1) to
request NFMS_P to activate the O-DU by changing the
administrativeState of the O-DU to unlocked.

See NOTE 5, NOTE 6.

- the O-RU NF constituent, and invokes NF provisioning service with

operation modifyMOIAttributes (3GPP TS 28.531 [4], table 6.3-1) to
request NFMS_P to activate the O-RU by changing the
administrativeState of the O-RU to unlocked.

See NOTE 7.

NSSMS_P receives notifications indicating that all inactive NSSI constituents

are activated. (NSSMS_P is notified by respective NFMS_P(s) through NF
Step 3 (M) provisioning data report service with notification
notifyMOIAttributeValueChanges (3GPP TS 28.531 [4], table 6.3-1) that the O-
CU-CP, O-CU-UP, O-DU and O-RU have been activated.)

NSSMS_P changes administrativeState of the O-NSSI to unlocked, and

invokes NSSI provisioning data report service with notification
Step 4 (M)
notifyMOIAttributeValueChanges (3GPP TS 28.531 [4], table 6.2-1) to notify
NSSMS_C that the O-NSSI has been activated.

Ends when O-RAN O-NSSI is activated.

Exceptions One of the steps identified above fails.

Post Conditions O-NSSI is in operation.

Traceability REQ-SL-FUN25, REQ-SL-FUN28

NOTE 1: The O-CU-CP, O-CU-UP, O-DU and O-RU are not shared by other O-NSSI, since they are not yet activated.
Near-RT RIC has already been activated for other services.

NOTE 2: O-CU-CP triggers establishment of the E2 interface connection with Near-RT RIC.

NOTE 3: O-CU-UP triggers establishment of the E2 interface connection with Near-RT RIC.

NOTE 4: E1 interface connection will be established between O-CU-CP and O-CU-UP.

NOTE 5: O-DU triggers establishment of the F1 interface connection with O-CU-CP and O-CU-UP, (3GPP TS 28.541
[7], Annex A.1).

NOTE 6: O-DU triggers establishment of the E2 interface connection with Near-RT RIC.

NOTE 7: O-RU triggers establishment of the M plane interface connection with O-DU (O-RAN.WG1.O1-Interface.0-
v04.00 [13]).

5.2.3 O-RAN Slice Subnet Instance Modification

The context of the O-RAN slice subnet instance modification use case is captured in table 5.2.3-1.

Table 5.2.3-1: O-RAN slice subnet instance modification use case

<<Uses>>
Use Case Stage Evolution / Specification
Related use

Modification of an existing O-NSSI to satisfy O-RAN slice subnet related

Goal
requirements (3GPP TS 28.531 [4], clause 5.1.9).

NSSMS_C, such as NSMF, who acts as the network slice subnet management
service consumer.

NSSMS_P, such as NSSMF, who acts as the network slice subnet management
service provider.

NFMS_P, such as SMO OAM functions or NFMF, who acts as the network
Actors and Roles function management service provider.

O-Cloud M&O, who acts as the O-Cloud management and orchestration

provider within SMO.

Non-RT RIC

O-RAN network functions: NFs such as Near-RT RIC, O-CU-CP, O-CU-UP, O-

DU and O-RU.

NSSMS_P has the knowledge of O-Cloud M&O to manage the lifecycle of VNFs
Assumptions
and interconnection between the VNFs and PNFs.

VNF packages for virtualized O-RAN network functions to be included in the O-

Pre-conditions
RAN slice subnet instance have been already on-boarded.

NSSMS_P receives request for a modification of an existing O-NSSI. The

Begins when
request contains new network slice subnet related requirements.

NSSMS_P checks the feasibility of the request, based on the received network O-RAN slice
Step 1 (M) slice subnet related modification requirements. If the modification requirements subnet
can be satisfied, go to step 2, else go to step 8. feasibility check

NSSMS_P decomposes the O-NSSI modification request into modification

Step 2 (M)
requests for each (O-)NSSI constituent.

(O-RAN) slice
If the required O-NSSI contains constituent (O-)NSSI(s) managed by other subnet instance
NSSMS_P(s), NSSMS_P may trigger modification of respective constituent modification use
(O-)NSSI(s) through other NSSMS_P(s) which manages the constituent case (to modify
Step 3 (O) (O-)NSSI(s). constituent
In that case, NSSMS_P receives the constituent (O-)NSSI information from the (O-)NSSI(s)
other NSSMS_P(s) and associates the constituent (O-)NSSI(s) with the managed by
required O-NSSI. other
NSSMS_P(s))

If the O-NSSI contains virtualized part(s), NSSMS_P triggers a service

modification request to O-Cloud M&O for scaling, updating, instantiation etc. of
Step 4 (O)
virtual O-RAN network functions and virtual links within the determined O-
Cloud(s).

If the O-NSSI consists of NF instances, NSSMS_P uses NF provisioning service

Step 5 (O)
exposed by NFMS_P to (re-)configure (O-)NSSI constituents.

<<Uses>>
Use Case Stage Evolution / Specification
Related use

If the NSSI contains TN part, NSSMS_P triggers O-RAN TN manager

Step 6 (O) coordination procedure to establish/modify necessary links such as for A1, E2,
midhaul and fronthaul connectivity.

NSSMS_P notifies Non-RT RIC with the updated network slice subnet
Step 7 (M)
requirements and respective O-NSSI information.

NSSMS_P notifies NSSMS_C with the resulting status of this process and
Step 8 (M)
relevant O-NSSI information.

O-RAN O-NSSI and relevant O-RAN NFs are modified, and Non-RT RIC is
Ends when
configured with modified slice requirements and O-NSSI information.

Exceptions One of the steps identified above fails.

O-NSSI is ready to satisfy the updated network slice subnet related

Post Conditions
requirements.

Traceability REQ-SL-FUN24 - REQ-SL-FUN27, REQ-SL-FUN29, REQ-SL-FUN30

5.2.4 O-RAN Slice Subnet Instance Deactivation

The context of the O-RAN slice subnet instance deactivation use case is captured in table 5.2.4-1.

Table 5.2.4-1: O-RAN slice subnet instance deactivation use case

<<Uses>>
Use Case Stage Evolution / Specification
Related use

Deactivation of an O-RAN network slice subnet instance (O-NSSI) (3GPP TS

Goal
28.531 [4], clause 5.1.11).

NSSMS_C, such as NSMF, who acts as the network slice subnet management
service consumer.

O-RAN network functions: NFs such as Near-RT RIC, O-CU-CP, O-CU-UP, O-

DU and O-RU.

Assumptions NSSMS_P is providing services to authorized consumers.

An O-NSSI has already and it is in active state.

Pre-conditions As an example, the existing O-NSSI includes active O-CU-CP, O-CU-UP, O-DU
and O-RU O-RAN NFs, where the administrativeState is unlocked (3GPP
TS 28.541 [7], figure B.2.2). See NOTE 1.

NSSMS_C decides to deactivate the O-NSSI based on the received network

Begins when
slice subnet related request from its authorized consumer NSSMS_C.

Step 1 (M) NSSMS_P receives a request from NSSMS_C to deactivate the O-NSSI (via
NSSI provisioning service with operation modifyMOIAttributes (3GPP TS

<<Uses>>
Use Case Stage Evolution / Specification
Related use

28.531 [4], table 6.2-1) to request NSSMS_P to deactivate the O-NSSI that is
to change administrativeState of the O-NSSI to locked).

NSSMS_P identifies active constituents (e.g. NSSI, NF) of the NSSI and
decides to deactivate those constituents.

As an example, NSSMS_P finds that the O-NSSI contains active non-shared O-

RAN NFs:

- the O-CU-CP NF constituent, and invokes NF provisioning service with

operation modifyMOIAttributes (3GPP TS 28.531 [4], table 6.3-1) to
request NFMS_P to deactivate the O-CU-CP by changing the
administrativeState of the O-CU-CP to locked.

See NOTE 2, NOTE 3.

- the O-CU-UP NF constituent, and invokes NF provisioning service with

operation modifyMOIAttributes (3GPP TS 28.531 [4], table 6.3-1) to
request NFMS_P to deactivate the O-CU-UP by changing the
administrativeState of the O-CU-UP to locked.
Step 2 (M)
See NOTE 4.

- the O-DU NF constituent, and invokes NF provisioning service with

operation modifyMOIAttributes (3GPP TS 28.531 [4], table 6.3-1) to
request NFMS_P to deactivate the O-DU by changing the
administrativeState of the O-DU to locked.

See NOTE 5, NOTE 6.

- the O-RU constituent, and invokes NF provisioning service with operation

modifyMOIAttributes (3GPP TS 28.531 [4], table 6.3-1) to request
NFMS_P to deactivate the O-RU by changing the
administrativeState of the O-RU to locked.

See NOTE 7.

NSSMS_P receives notifications indicating that all active non-shared NSSI

constituents are deactivated.

Step 3 (M) (NSSMS_P is notified by respective NFMS_P(s) which invoke NF provisioning

data report service with notification notifyMOIAttributeValueChanges (3GPP TS
28.531 [4], table 6.3-1) to notify that the O-CU-CP, O-CU-UP, O-DU and O-RU
have been deactivated.)

NSSMS_P changes administrativeState of the O-NSSI to locked, and

invokes NSSI provisioning data report service with notification
Step 4 (M)
notifyMOIAttributeValueChanges (3GPP TS 28.531 [4], table 6.2-1) to notify
NSSMS_C that the O-NSSI has been deactivated.

Ends when O-RAN O-NSSI is deactivated.

Exceptions One of the steps identified above fails.

<<Uses>>
Use Case Stage Evolution / Specification
Related use

Post Conditions O-NSSI is inactive.

Traceability REQ-SL-FUN25, REQ-SL-FUN31

NOTE 1: The O-CU-CP, O-CU-UP, O-DU and O-RU are not shared by other O-NSSI.

NOTE 2: O-CU-CP triggers termination of the E2 interface connection with Near-RT RIC.

NOTE 3: E1 interface connection will be released between O-CU-CP and O-CU-UP.

NOTE 4: O-CU-UP triggers termination of the E2 interface connection with Near-RT RIC.

NOTE 5: O-DU triggers termination of the F1 interface connection with O-CU-CP and O-CU-UP (3GPP TS 28.541 [7],
Annex A.1).

NOTE 6: O-DU triggers termination of the E2 interface connection with Near-RT RIC.

NOTE 7: O-RU triggers termination of the M plane interface connection with O-DU (O-RAN.WG1.O1-Interface.0-
v04.00 [13]).

5.2.5 O-RAN Slice Subnet Instance Termination

The context of the O-RAN slice subnet instance termination use case is captured in table 5.2.5-1.

Table 5.2.5-1: O-RAN slice subnet instance termination use case

<<Uses>>
Use Case Stage Evolution / Specification
Related use

Termination or disassociation of an existing O-RAN network slice subnet

Goal
instance (O-NSSI) (3GPP TS 28.531 [4], clause 5.1.4).

NSSMS_C, such as NSMF, who acts as the network slice subnet management
service consumer.

NSSMS_P, such as NSSMF, who acts as the network slice subnet management
service provider.

Actors and Roles O-Cloud M&O, who acts as the O-Cloud management and orchestration
provider within SMO.

Non-RT RIC

O-RAN network functions: NFs such as Near-RT RIC, O-CU-CP, O-CU-UP, O-

DU and O-RU.

NSSMS_P has the knowledge of O-Cloud M&O to manage the lifecycle of VNFs
Assumptions
and interconnection between the VNFs and PNFs.

Pre-conditions O-NSSI exists, and it is in inactive state.

NSSMS_P receives a request for an O-RAN network slice subnet instance

Begins when indicating that the O-NSSI is no longer needed. The request contains network
slice subnet identifier.

NSSMS_P checks whether the O-NSSI is a shared network slice subnet O-RAN slice
Step 1 (M)
instance. subnet instance

<<Uses>>
Use Case Stage Evolution / Specification
Related use

modification use
case
If the O-NSSI is shared, O-NSSI shall be disassociated via O-NSSI slice subnet
instance modification use case. Go to step 5.

If the O-NSSI is not shared, O-NSSI shall be terminated. Go to step 2.

O-RAN slice
If the O-NSSI consists of constituent NSSIs that are not managed directly by
subnet instance
Step 2 (M) the NSSMS_P, it sends a request to other NSSMS_P(s) indicating that the
termination use
constituent NSSIs are no longer needed for the O-NSSI.
case

NSSMS_P may trigger a service termination request to O-Cloud M&O for

Step 3 (O)
removal of non-shared virtual O-RAN network functions.

If the O-NSSI includes constituent transport links, NSSMS_P may trigger O-

Step 4 (O)
RAN TN manager coordination procedure.

Step 5 (M) NSSMS_P notifies Non-RT RIC that the O-NSSI has been terminated.

NSSMS_P notifies NSSMS_C with the resulting status of this process and
Step 6 (M)
relevant O-NSSI information.

Ends when All the steps identified above are successfully completed.

Exceptions One of the steps identified above fails.

Post Conditions O-NSSI has been terminated or disassociated and Non-RT RIC is notified.

REQ-SL-FUN21, REQ-SL-FUN23, REQ-SL-FUN27, REQ-SL-FUN32 - REQ-

Traceability
SL-FUN34

5.2.6 O-RAN Slice Subnet Instance Configuration

The context of the O-RAN slice subnet instance configuration use case is captured in table 5.2.6-1.

Table 5.2.6-1: O-RAN slice subnet instance configuration use case

<<Uses>>
Use Case Stage Evolution / Specification
Related use

Goal Configuration of an O-NSSI (3GPP TS 28.531 [4], clause 5.1.13).

NSSMS_C, such as NSMF, who acts as the network slice subnet management
service consumer.

O-RAN network functions: NFs such as Near-RT RIC, O-CU-CP, O-CU-UP, O-

DU and O-RU.

<<Uses>>
Use Case Stage Evolution / Specification
Related use

NSSMS_P is providing services to authorized consumers.

Assumptions NSSMS_P has the knowledge of the respective NSSMS_P(s) and NFMS_P(s)
which manages the constituent NSSI(s) and NF(s).

Pre-conditions The O-NSSI exists.

Begins when NSSMS_C triggers the (re-)configuration of an O-NSSI and its constituents.

NSSMS_P receives a request from NSSMS_C with slice subnet

Step 1 (M)
(re-)configuration information for (re-)configuration of an O-NSSI.

NSSMS_P decomposes the received slice subnet configuration information and

Step 2 (M)
prepares CM requests for each constituent if necessary and applicable.

NSSMS_P configures the constituent O-NSSI(s) if it is managed directly by the

Step 3 (O)
NSSMS_P.

(O-RAN) slice
If the O-NSSI contains constituent NSSI(s) managed by other NSSMS_P(s),
subnet
Step 4 (O) NSSMS_P triggers configuration of respective constituent NSSI(s) through
configuration
NSSMS_P(s) which manages the constituent NSSI(s).
use case

If the required O-NSSI contains constituent O-RAN NF(s) managed by

NFMS_P(s), NSSMS_P may trigger configuration requests with corresponding
Step 5 (O)
slice subnet configuration information through NFMS_P(s) which manages the
constituent O-RAN NF(s).

NSSMS_P sends the configuration result to the NSSMS_C which may be based
Step 6 (M)
on results received from other CM service providers.

Ends when All the steps identified above are successfully completed.

Exceptions One of the steps identified above fails.

The required (re-)configuration is accomplished at the corresponding

Post Conditions
constituent(s).

Traceability REQ-SL-FUN24, REQ-SL-FUN25

5.2.7 O-RAN Slice Subnet Feasibility Check

The context of the O-RAN slice subnet feasibility check is captured in table 5.2.7-1.

Table 5.2.7-1: O-RAN slice subnet feasibility check

<<Uses>>
Use Case Stage Evolution / Specification
Related use

To check the feasibility of provisioning an O-RAN network slice subnet instance

Goal (O-NSSI) to determine whether the O-NSSI requirements can be satisfied (e.g.,
in terms of resources) (3GPP TS 28.531 [4], clause 5.1.21).

NSSMS_C, such as NSMF, who acts as the network slice subnet management
Actors and Roles
service consumer.

<<Uses>>
Use Case Stage Evolution / Specification
Related use

NSSMS_P, such as NSSMF, who acts as the network slice subnet management
service provider.

NFMS_P, such as SMO OAM functions or NFMF, who acts as the network
function management service provider.

O-Cloud M&O, who acts as the O-Cloud management and orchestration

provider within SMO.

Non-RT RIC

O-RAN network functions: NFs such as Near-RT RIC, O-CU-CP, O-CU-UP, O-

DU and O-RU.

NSSMS_C has decided to check the feasibility of provisioning an O-NSSI based

Assumptions
on, for example, internal decision or an external service request.

Network slice subnet requirements have been derived or received by network

Pre-conditions
slice subnet management service consumer NSSMS_C.

O-RAN slice
subnet instance
NSSMS_P receives the request to evaluate the feasibility of an O-NSSI creation, O-
Begins when
according to the network slice subnet requirements. RAN slice
subnet instance
modification

NSSMS_P identifies the network slice subnet constituents according to the

Step 1 (M)
requirements, e.g., network services to be requested from O-Cloud M&O.

For the purpose of checking the feasibility of provisioning an O-NSSI,

NSSMS_P may obtain information from the SMO and Non-RT RIC (e.g., load
Step 2 (O)
level information, resource usage information from management data analytics
services).

NSSMS_P sends enquiries with reservation requests to O-Cloud M&O to

Step 3 (M) determine availability of network constituents, e.g., network services, network
functions.

For the purpose of checking the feasibility of transport network links, NSSMS_P
Step 4 (O)
may obtain information from TN manager.

NSSMS_P provides feasibility check results to NSSMS_C. If provisioning of O-

Ends when NSSI is feasible, the information about reserved resources may also be
provided.

Exceptions One of the mandatory steps fails.

Post Conditions N/A

Traceability REQ-SL-FUN35 - REQ-SL-FUN37

5.3 O-RAN Slicing Use Cases

5.3.1 Use Case 1: RAN Slice SLA Assurance

In the 5G era, network slicing is a prominent feature which provides end-to-end connectivity and data processing tailored
to specific business requirements. These requirements include customizable network capabilities such as the support of
very high data rates, traffic densities, service availability and very low latency. According to 5G standardization efforts,
the 5G system can support the needs of the business through the specification of several service needs such as data rate,
traffic capacity, user density, latency, reliability, and availability. These capabilities are always provided based on a Service
Level Agreement (SLA) between the mobile operator and the business customer, which brought up interest for
mechanisms to ensure slice SLAs and prevent its possible violations. O-RAN’s open interfaces and AI/ML based
architecture will enable such challenging mechanisms to be implemented and help pave the way for operators to realize
the opportunities of network slicing in an efficient manner.

RAN slice SLA assurance scenario involves Non-RT RIC, Near-RT RIC, E2 Nodes and SMO interaction. The scenario
starts with the retrieval of RAN specific slice SLA/requirements (possibly within SMO or from NSSMF depending on
operator deployment options). Based on slice specific performance measurements from E2 Nodes, Non-RT RIC and Near-
RT RIC can fine-tune RAN behavior aligned with O-RAN architectural roles to assure RAN slice SLAs. Non-RT RIC
monitors long-term trends and patterns for RAN slice subnets’ performance and employs AI/ML methods to perform
corrective actions through SMO (e.g. reconfiguration via O1) or via creation of A1 policies. Non-RT RIC can also
construct/train relevant AI/ML models that will be deployed at Near-RT RIC. A1 policies possibly include scope
identifiers (e.g. S-NSSAI) and statements such as KPI targets. On the other hand, Near-RT RIC enables optimized RAN
actions through execution of deployed AI/ML models in near-real-time by considering both O1 configuration (e.g. static
RRM policies) and received A1 policies, as well as received slice specific E2 measurements.

An overview of RAN slice SLA assurance use case is given in figure 5.3.1-1.

Figure 5.3.1-1: RAN slice SLA assurance use case overview

The more detailed functions provided by the entities for RAN slice SLA assurance are listed as below:

1) SMO:
a) Provides information about slice topology and SLA associated with the slice to the Non-RT RIC
2) Non-RT RIC:
a) Retrieve RAN slice SLA target from respective entities such as SMO, NSSMF
b) Long term monitoring of RAN slice subnet performance measurements
c) Training of potential ML models that will be deployed in Near-RT RIC for optimized slice assurance
d) Support deployment and update of AI/ML models into Near-RT RIC
e) Send A1 policies and enrichment information to Near-RT RIC to drive slice assurance
f) Send O1 reconfiguration requests to SMO for slow-loop slice assurance

3) Near-RT RIC:
a) Near-real-time monitoring of slice specific RAN performance measurements
b) Support deployment and execution of the AI/ML models from Non-RT RIC
c) Support interpretation and execution of policies from Non-RT RIC
d) Perform optimized RAN (E2) actions to achieve RAN slice subnet requirements based on O1 configuration,
A1 policy, and E2 reports
4) E2 Nodes (O-CU-CP, O-CU-UP, O-DU):
a) Support slice assurance actions such as slice-aware resource allocation, prioritization, etc.
b) Support slice specific performance measurements through O1
c) Support slice specific performance reports through E2

5.3.2 Use Case 2: Multi-Vendor Slices

This use case enables multiple slices with functions provided by multi-vendors, such as slice #1, composed of DU(s) and
CU(s), provided by vendor B and slice #2, composed of DU(s) and CU(s), provided by vendor C (see figure 5.3.2-1).

Figure 5.3.2-1: Multi-vendor slices

When providing multiple slices, it is assumed that suitable virtualized O-DU (vO-DU)/scheduler and virtualized O-CU-
CP and virtualized O-CU-UP treat each slice respectively. A vendor who provides vO-DU and vO-CU-UP function may
include a customized scheduler for a certain service, with advantages for optimized functionality. With accomplishment
of multi-vendor circumstances, following benefits may be expected:

1) More flexible and time to market deployment

Operators can maximize options to choose suitable vO-DU/scheduler and vO-CU-CP and vO-CU-UP to offer
various slices. For example, some vendors may have an optimized scheduler for eMBB services and the other may
have an optimized scheduler for URLLC services. Or, vendor A can provide vO-DU/scheduler and vO-CU-CP and
vO-CU-UP suitable for URLLC earlier than vendor B, therefore operators can choose vO-DU and vO-CU-CP and
vO-CU-UP functions from vendor A to meet their service requirements.

Also, when an operator wants to add a new service/slice, new functions from a new vendor can be introduced with
less consideration for existing vendors if multi-vendor circumstance was realized. This can help expand vendor’s
business opportunities rapidly.

2) Flexible deployment when sharing RAN equipment among operators

When operators want to share RAN equipment and resources, RAN vendors and their placement of each RAN
functions can be different. If multi-vendor circumstance was introduced, then it can relax restrictions among
operators to share RAN equipment and resources. This can help expanded opportunities for reaching agreements of
RAN sharing among operators. With expansion of RAN sharing, operators CAPEX and OPEX can be optimized,
helping with additional investment opportunities.

3) Reducing supply chain risk

If an existing vendor providing a certain pair of vO-DU and vO-CU-CP and vO-CU-UP functions withdraws of the
market due to business reasons, operators can deploy new vO-DU and vO-CU-CP and vO-CU-UP functions

alternatively from other vendors under this multi-vendor circumstance. This can reduce the risk for operators’
business continuity.

To realise multi-vendor slices, some coordination between vO-DU/vO-CU-CP/v-O-CU-UPs is required since radio
resources shall be assigned properly and without any conflicts. Depending on different service goals and the potential
impact on O-RAN architecture, a required coordination scheme needs to be determined. The possible cases are:

1) Loose coordination through O1/E2/A1 interface (case 1 shown in figure 5.3.2-2)

2) Moderate coordination through X2/F1 interface (case 2 shown in figure 5.3.2-2)
3) Tight coordination through a new interface between vO-DUs (case 3 shown in figure 5.3.2-2)

Figure 5.3.2-2: Multi-vendor slices coordination scheme options

In case 1, a resource allocation between slices or vO-DU/vO-CU-CP/vO-CU-UPs shall be provisioned through O1/A1/E2
interface, and each pair of vO-DU and vO-CU will allocate radio resources to each customer within radio resources
allocated by Near-RT RIC and/or Non-RT RIC.

In case 2, a resource allocation may be negotiated between slices or vO-DU/vO-CU-CP/vO-CU-UPs through X2 and F1
after provisioned through O1/E2/A1 interface. Negotiation period will be several seconds due to periodicity of X2 and F1
message exchange between vO-CU-CP(s).

If a more adaptive radio resource allocation is needed (case 3), more frequent negotiation would be required. This may
potentially be achieved via an interface or API extension between vO-DU(s).

5.3.3 Use Case 3: NSSI Resource Allocation Optimization

5G networks are becoming increasingly complex with the densification of millimeter wave small cells, and various new
services, such as eMBB (enhanced Mobile Broadband), URLLC (Ultra Reliable Low Latency Communications), and
mMTC (massive Machine Type Communications) that are characterized by high speed high data volume, low speed ultra-
low latency, and infrequent transmitting low data volume from huge number of emerging smart devices, respectively. It
is a challenging task for 5G networks to allocate resources dynamically and efficiently among multiple network nodes to
support various services. However, eMBB, URLLC, and mMTC services in 5G are typically realized as NSI(s) (Network
Slice instance(s)). Therefore, the resources allocated to NSSI (Network Slice Subnet Instance) to support the O-RAN
nodes can be optimized according to the service requirements.

As the new 5G services have different characteristics, the network traffic tends to be sporadic, where there can be different
usage pattern in terms of time, location, UE distribution, and types of applications. For example, most IoT sensor
applications may run during off-peak hours or weekends. Special events, such as sport games, concerts, can cause traffic
demand to shoot up at certain times and locations. Therefore, NSSI resource allocation optimization function trains the
AI/ML model, based on the huge volume of performance data collected over days, weeks, months from O-RAN nodes.
It then uses the AI/ML model to predict the traffic demand patterns of 5G networks in different times and locations for
each network slice subnet, and automatically re-allocates the network resources ahead of the network issues surfaced.

The resource quota policies associated with RAN NFs (E2 Nodes) included in the respective NSSIs enable 5G network
providers to optimize or prioritize the utilization of the RAN resources across slices and supports the flexibility to share
resources optimally across critical service slices during resource surplus or scarcity. For example, an NSSI allocated for
premium service can receive a major share of the resources compared to a slice allocated for a standard/best-effort service.
Another such example is the scenario of additional resource allocation for emergency services. An important consideration
here is that the NSSI resource quota policies focuses on maximization of resource utilization across the NSSIs. The
resource quota policies can be used as a constraint for resource allocation that defines the range of resources that can be
allocated per slice. One use case for applying such a constraint is the analysis and decision based on history of resource
allocation failure that may be reflected in the RAN node measurements. Here resource quota policy can be provisioned
to control the minimum, maximum and dedicated resources that need to be allocated based on the historical pattern. The
NSSI resource allocation optimization on the Non-RT RIC is shown in figure 5.3.3-1 shows, and may consist of the
following steps:

1. Monitoring: monitor the radio network(s) by collecting data via the O1 interface, including the following
performance measurements that are measured per S-NSSAI (3GPP TS 28.552 [8] shall apply):

- DL PRB used for data traffic (3GPP TS 28.552 [8], clause 5.1.1.2.5 shall apply)

- UL PRB used for data traffic (3GPP TS 28.552 [8], clause 5.1.1.2.7 shall apply)

- Average DL UE throughput in gNB (3GPP TS 28.552 [8], clause 5.1.1.3.1 shall apply)

- Average UL UE throughput in gNB (3GPP TS 28.552 [8], clause 5.1.1.3.3 shall apply)

- Number of PDU sessions requested to setup (3GPP TS 28.552 [8], clause 5.1.1.5.1 shall apply)

- Number of PDU sessions successfully setup (3GPP TS 28.552 [8], clause 5.1.1.5.2 shall apply)

- Distribution of DL UE throughput in gNB (3GPP TS 28.552 [8], clause 5.1.1.3.2 shall apply)

- Distribution of UL UE throughput in gNB (3GPP TS 28.552 [8], clause 5.1.1.3.4 shall apply)

- Number of DRBs successfully setup (3GPP TS 28.552 [8], clause 5.1.1.10.2 shall apply)

2. Analysis & Decision: consisting of the following steps:

o Utilize AI/ML models to analyze the measurements and predict the future traffic demand, including the
RRMPolicyRatio IOC limits, for each NSSI for a given time and location.
o Determine the actions needed to add or reduce the resources (e.g. capacity, VNF resources, slice subnet
attributes (3GPP TS 28.541 [7] shall apply), etc.) for the RAN NFs (E2 Nodes) included in the
respective NSSI at the given time, and location.
3. Execution: execute the following actions to reallocate the NSSI resources:

3a. Re-configure the NSSI attributes, including RRMPolicyRatio IOCs (3GPP TS 28.541 [7] shall apply) via the
OAM functions in SMO which uses O1 interface to configure the E2 Nodes.

3b. Update the cloud resources via the O2 interface

Service management & Orchestration Framework

Non-RT RIC
NSSI Resource
Allocation Optimization
O-Cloud
2. analysis & decision 1. monitoring
M&O

O2 A1 3.a. execution

O1
Near-RT RIC

E2 E2

Network functions
O-CU- O-CU-
UP E1 CP

E2
F1-U F1-C
O-DU
Open Fronthaul interface

O-RU

O-Cloud

Figure 5.3.3-1: The realization of NSSI resource allocation optimization over Non-Real Time RIC

The more detailed functions provided by the entities for NSSI resource optimization are listed as follows:

1) SMO:
a) Pre-provision the default NSSI resource quota policy as constraint for NSSI resource allocation optimization.
This information is optionally used by the Non-RT RIC in case the resource quota that needs to be allocated
per slice is not specified during the slice creation and for conflict resolution at the time of resource scarcity.
2) Non-RT RIC:
a) Collect the performance measurements related to NSSI resource usage from the O-RAN nodes via the O1
interface.
b) Train the AI/ML model based on the analysis of historical performance measurements, to predict of the traffic
demand patterns of NSSI at different times and locations.
c) Determine the time/date and locations (i.e. which O-RAN nodes) to add or reduce the resources (e.g. capacity,
VNF resources, slice subnet attributes (3GPP TS 28.541 [7]), RRMPolicyRatio IOC, etc.) for a given NSSI
based on inference.
d) Perform the following action(s) to optimize the NSSI resource allocation, at the time determined by the model
i. Re-configure the NSSI attributes via the O1 interface.
ii. Update the cloud resources via the O2 interface.
3) E2 Nodes (O-CU-CP, O-CU-UP, O-DU, and O-RU):
a) Support the performance measurement collection with required granularity over O1 interface.
b) Support the configuration related to the NSSI resource allocation update over O1 interface.

6 O-RAN Slicing Principles and Requirements

6.1 General Principles

This clause contains general O-RAN slicing architecture principles as described below:

• O-RAN slicing architecture and interface specifications shall be consistent with 3GPP architecture and interface
specifications to the extent possible

• O-RAN slicing architecture shall provide standardized management service interfaces for RAN slicing
management services

• O-RAN slicing architecture shall enable multi-vendor interoperability

• O-RAN slicing architecture shall support multiple different network operator deployment options

• O-RAN slicing architecture shall support management of RAN slice subnets in multi-operator scenarios

6.2 Slicing Requirements

6.2.1 Functional Requirements

Initial set of O-RAN slicing functional requirements based on the use cases defined in the present document is captured
in table 6.2.1-1.

Table 6.2.1-1: O-RAN slicing functional requirements

REQ Description Note

O-RAN slicing architecture and interfaces shall support network

ORAN OAM Specification
[REQ-SL-FUN1] slicing, where an instance of O-RAN network function may be
v02.00
associated with one or more slices.

O-RAN slicing architecture shall support differentiated handling of

[REQ-SL-FUN2] 3GPP TS 38.300
traffic for different RAN slice subnets.

O-RAN slicing architecture shall support resource isolation between

[REQ-SL-FUN3] 3GPP TS 38.300
slices.

O-RAN slicing architecture shall enable traffic and services in one

[REQ-SL-FUN4] RAN slice subnet having no impact on traffic and services in other 3GPP TS 22.261
RAN slice subnets in the same network.

O-RAN slicing architecture shall enable mechanisms to avoid

[REQ-SL-FUN5] shortage of shared resources in one slice breaking the service level 3GPP TS 38.300
agreement for another slice.

O-RAN slicing architecture shall enable defining a priority order

[REQ-SL-FUN6] between different RAN slice subnets in case multiple slices compete 3GPP TS 22.261
for resources on the same RAN.

O-RAN slicing architecture shall apply policies at S-NSSAI level

[REQ-SL-FUN7] -
according to the SLA required by the network slice.

O-RAN slicing architecture shall support means by which the

[REQ-SL-FUN8] operator can differentiate policy control, functionality and 3GPP TS 22.261
performance provided in different RAN slice subnets.

REQ Description Note

O-RAN slicing architecture shall support QoS differentiation within a

[REQ-SL-FUN9] 3GPP TS 38.300
slice.

O-RAN slicing architecture shall enable slice aware radio resource

[REQ-SL-FUN10] management strategies (such as admission control, congestion 3GPP TS 38.300
control, handover preparation).

O-RAN slicing architecture shall allow creation, modification, and

[REQ-SL-FUN11] 3GPP TS 28.531
deletion of a RAN slice subnet.

O-RAN slicing architecture shall support interaction between the RAN slice SLA assurance
SMO framework and Non-RT RIC to consume provisioning use case, NSSI resource
[REQ-SL-FUN12]
management services exposed by each O-RAN managed element allocation optimization use
to configure RAN slice subnets through the O1 interface. case

O-RAN slicing architecture shall support the interaction between the RAN slice SLA assurance
SMO framework and Non-RT RIC to consume management of slice use case, NSSI resource
[REQ-SL-FUN13]
specific PM jobs, PM data collection/storage/query/statistical allocation optimization use
reports from O-RAN network functions through the O1 interface. case

RAN slice SLA assurance

O-RAN slicing architecture shall support interaction between the
use case, O-RAN slice
[REQ-SL-FUN14] SMO framework and Non-RT RIC to retrieve/notify RAN slice subnet
subnet instance creation
requirements (SLA) along with O-NSSI information.
use case

RAN slice SLA assurance

O-RAN slicing architecture shall support provisioning, generation,
use case, NSSI resource
[REQ-SL-FUN15] and monitoring of slice specific RAN performance metrics through
allocation optimization use
O1 interface.
case

RAN slice SLA assurance

O-RAN slicing architecture shall support training, deployment, and use case, NSSI resource
[REQ-SL-FUN16] execution of AI/ML models for slice SLA assurance and NSSI allocation optimization use
resource allocation optimization. case

O-RAN slicing architecture shall support slice specific policy RAN slice SLA assurance
[REQ-SL-FUN17]
guidance, enrichment information and policy feedback. use case

O-RAN slicing architecture shall support provisioning, generation, RAN slice SLA assurance
[REQ-SL-FUN18] and monitoring of slice specific RAN performance data through E2 use case
interface.
O-RAN slicing architecture shall support reconfiguration of slice RAN slice SLA assurance
[REQ-SL-FUN19]
specific RAN parameters and resources for slice SLA assurance. use case

O-RAN slicing architecture shall enable creation of O-RAN network O-RAN slice subnet
[REQ-SL-FUN20] slice subnet instances as O-RAN network service (NS) instance(s) instance creation use case
within O-Cloud(s).
O-RAN slice subnet
O-RAN slicing architecture shall enable association and instance creation use case,
[REQ-SL-FUN21] disassociation of O-Cloud NS instances with corresponding O- O-RAN slice subnet
NSSIs. instance termination use
case

O-RAN slicing architecture shall enable creation of O-RAN network O-RAN slice subnet
[REQ-SL-FUN22] slice subnet instances as O-RAN network function (NF) instance(s) instance creation use case
within O-Cloud(s).
O-RAN slicing architecture shall enable association and O-RAN slice subnet
[REQ-SL-FUN23] disassociation of O-Cloud NF instances with corresponding O- instance creation use case,
NSSIs. O-RAN slice subnet

REQ Description Note

instance termination use

case

O-RAN slice subnet

instance creation use case,
O-RAN slicing architecture shall support (re-)configuration of an O- O-RAN slice subnet
[REQ-SL-FUN24]
NSSI’s constituent network functions through the O1 interface. modification use case, O-
RAN slice subnet
configuration use case

O-RAN slice subnet

instance creation /
[REQ-SL-FUN25] O-RAN slicing architecture shall support (re-)configuration of an O- activation / modification /
RAN network slice subnet instance (O-NSSI) attributes. deactivation / configuration
use case

O-RAN slice subnet

O-RAN slicing architecture shall have the capability for the instance creation use case,
[REQ-SL-FUN26] establishment of required transport network connectivity between O-RAN slice subnet
O-RAN NFs during provisioning of O-RAN network slice subnet instance modification use
instances. case

O-RAN slice subnet

instance creation use case,
O-RAN slicing architecture shall enable Non-RT RIC to be notified O-RAN slice subnet
[REQ-SL-FUN27] when an O-NSSI has been created, activated, modified, deactivated instance modification use
and terminated. case, O-RAN slice subnet
instance termination use
case

O-RAN slicing architecture shall support the capability to activate O-RAN slice subnet
[REQ-SL-FUN28] the constituent physical network functions such as O-DU and O-RU instance activation use
within an O-NSSI. case

O-RAN slicing architecture shall enable modification of O-RAN O-RAN slice subnet
[REQ-SL-FUN29] network slice subnet instances through modification (such as instance modification use
scaling, updating, instantiation, etc.) of O-RAN network service (NS) case
instance(s) within O-Cloud(s).
O-RAN slicing architecture shall enable modification of O-RAN O-RAN slice subnet
[REQ-SL-FUN30] network slice subnet instances through modification (such as instance modification use
scaling, updating, instantiation, etc.) of O-RAN network function case
(NF) instance(s) within O-Cloud(s).
O-RAN slicing architecture shall support the capability to deactivate O-RAN slice subnet
[REQ-SL-FUN31] the constituent physical network functions such as O-DU and O-RU instance deactivation use
within an O-NSSI. case

O-RAN slicing architecture shall enable removal of constituent O- O-RAN slice subnet
[REQ-SL-FUN32] RAN network service (NS) instance(s) that were functioning within instance termination use
O-Cloud(s) and were associated to O-RAN network slice subnet case
instance(s).
O-RAN slicing architecture shall enable removal of constituent O- O-RAN slice subnet
[REQ-SL-FUN33] RAN network function (NF) instance(s) that were functioning within instance termination use
O-Cloud(s) and were associated to O-RAN network slice subnet case
instance(s).
O-RAN slicing architecture shall have the capability for the removal O-RAN slice subnet
[REQ-SL-FUN34] of non-shared transport network connectivity between O-RAN NFs instance termination use
during termination of O-RAN network slice subnet instances. case

O-RAN slicing architecture shall enable reservation of O-RAN O-RAN slice subnet
[REQ-SL-FUN35]
network service (NS) instance(s) within O-Cloud(s). feasibility check

REQ Description Note

O-RAN slicing architecture shall enable reservation of O-RAN O-RAN slice subnet
[REQ-SL-FUN36]
network service (NF) instance(s) within O-Cloud(s). feasibility check

O-RAN slicing architecture shall enable retrieval of network

utilization information from the SMO and Non-RT RIC (e.g., load O-RAN slice subnet
[REQ-SL-FUN37]
level information, resource usage information from management feasibility check
data analytics services).
RAN slice SLA assurance
O-RAN slicing architecture shall support interaction between the use case, NSSI resource
[REQ-SL-FUN38] SMO framework and Non-RT RIC to consume O-Cloud allocation optimization use
management and orchestration services through the O2 interface. case

O-RAN slicing architecture shall enable provisioning and Multi-vendor slices use
[REQ-SL-FUN39]
management of multiple slices on O-RU. case

O-RAN slicing architecture shall enable O-RU to route per slice user Multi-vendor slices use
[REQ-SL-FUN40]
plane traffic to one or more O-Dus. case

6.2.2 Non-Functional Requirements

Initial set of O-RAN slicing non-functional requirements based on the use cases defined in the present document is
captured in table 6.2.2-1.

Table 6.2.2-1: O-RAN slicing non-functional requirements

REQ Description Note

O-RAN slicing architecture shall support use of AI/ML to support RAN slicing
[REQ-SL-NFUN1]
use cases.

7 O-RAN Reference Slicing Architecture

7.1 O-RAN Reference Slicing Architecture

This clause provides O-RAN reference slicing architecture (see figure 7.1-1) along with the high-level roles and
responsibilities of O-RAN network functions.

Figure 7.1-1: O-RAN reference slicing architecture

O-RAN reference slicing architecture includes slice management functions along with O-RAN architectural components.
As O-RAN’s general principle is to be as compliant as possible with 3GPP architecture, these slice management functions
are 3GPP-defined NSMF and NSSMF with extensions defined for O-RAN network functions. Various deployment
options for the location of NSMF(s) and NSSMF(s) are included in [i.4]. Detailed architectural implementation options
for SMOs including NFV-MANO and ONAP are being presented in Appendix A of this document.

7.2 Non-RT RIC

The fundamental role of the Non-RT RIC in O-RAN slicing architecture is to gather long term slice related data through
interaction with the SMO framework and apply AI/ML based approaches interworking with the Near-RT RIC to provide
innovative RAN slicing use cases. For this purpose, Non-RT RIC shall have the knowledge of RAN slice subnets and
their respective SLA(s) through SMO. In addition, Non-RT RIC may retrieve enrichment information from 3 rd party
applications and use that information for RAN slice SLA assurance purposes.

In order to construct AI/ML models to be deployed in the Near-RT RIC, Non-RT RIC shall retrieve slice specific
performance metrics, configuration parameters and required attributes of the RAN slice subnets from the SMO framework.
The output of these algorithms may lead non-real-time optimization of the slice specific parameters of Near-RT RIC, O-
CU-CP, O-CU-UP and O-DU over O1 interface through SMO interaction. Moreover, these performance, configuration
and other slice related data are used to generate policy guidance and assist Near-RT RIC over A1 to provide closed loop

slice optimization. Applying such slice optimizations in the Near-RT RIC may be used for SLA assurance and prevent
SLA violations between the slices as well.

7.3 Near-RT RIC

Near-RT RIC enables near-real-time RAN slice subnet optimization through execution of slicing-related xApps and
communicating necessary parameters to O-CU-CP, O-CU-UP and O-DU through E2 interface. Deployed xApps may
utilize either AI/ML based models or non-AI/ML algorithms which may further be guided by A1 policies that are
generated by Non-RT RIC.

In order to drive sliced RAN resources properly, Near-RT RIC shall have the knowledge of existing RAN slice subnets
as well as their SLA requirements. This information will be received through O1 interface during provisioning of RAN
slice subnets. Therefore, similar to Non-RT RIC, Near-RT RIC will be aware of RAN slice subnets through O-RAN
specific information models and provisioning procedures.

In O-RAN slicing architecture, configuration of slice resources on E2 nodes can be achieved through slow loop with O1
configuration and through fast loop with E2 configuration. This architecture enables advanced slicing use cases such as
RAN slice SLA assurance and further enhances 3GPP slicing capability without misalignment. In the context of the RAN,
the SLA assurance parameters sent over the A1 interface assist the Near-RT RIC guide the behavior of the E2 Nodes (O-
CU-UP, O-CU-CP, O-DU). While Near-RT RIC is capable for fast-loop configuration, slicing related O1 configuration,
such as RRM policy information sent to O-CU-CP, O-CU-UP and O-DU configured by the SMO framework will be taken
into account. Moreover, slice-specific near-real-time performance data shall be monitored through E2 interface which
needs proper PM mechanisms between E2 nodes and Near-RT RIC as well.

7.4 O-RAN Central Unit (O-CU-CP, O-CU-UP)

O-CU-CP and O-CU-UP need to support slicing features as defined by 3GPP. Depending on slice requirements, O-CU-
UP may be shared across slices or a specific instance of O-CU-UP may be instantiated per slice. On top of 3GPP slicing
features, O-RAN further enhances slicing through the utilization of E2 interface and the assistance of Near-RT RIC
dynamic slice optimizations along with the enhanced O1 interface to support additional slice configuration parameters.

O-CU-CP and O-CU-UP stacks, which are the upper layer protocols of the RAN stack, shall be slice aware and execute
slice specific resource allocation and isolation strategies. These stacks are initially configured through O1 interface based
on the slice specific requirements and then dynamically updated through E2 interface via Near-RT RIC for various slicing
use cases.

Based on the PM requests from SMO and Near-RT RIC, O-CU-CP and O-CU-UP shall generate and send specific PMs
through O1 and E2 interfaces respectively, where the PMs may be used for slice performance monitoring and slice SLA
assurance purposes.

7.5 O-RAN Distributed Unit (O-DU)

O-DU, which runs the lower layer protocols of RAN stack, shall support slice specific resource allocation strategies as
well. Based on the initial O1 configuration of PRB allocation levels along with O-CU-CP and O-CU-UP directives over
F1 interface and the dynamic guidance received from Near-RT RIC over E2 interface, MAC layer needs to allocate and
isolate relevant PRBs to specific slices.

Based on the PM requests from SMO and Near-RT RIC, O-DU shall generate and send specific PMs through O1 and E2
interfaces respectively, where the PMs may be used for slice performance monitoring and slice SLA assurance purposes.

7.6 A1 Interface
A1, which is the interface between the Non-RT RIC and the Near-RT RIC, supports policy management, ML model
management and enrichment information services [i.13]. These three services will be utilized for various slicing use cases,
such as slice SLA assurance. Policy management will be used by Non-RT RIC to send slice specific (e.g. S-NSSAI based)
policies to guide Near-RT RIC with slice resource allocations and slice specific control activities, as well as to receive
slice specific policy feedback for the policies deployed on the Near-RT RIC.

For the use cases that make use of external enrichment data or where Non-RT RIC produces enrichment information, A1
enrichment interface will be used to send slice specific enrichment data to Near-RT RIC.

It should be noted that slice specific A1 policies are not persistent (do not survive the restart of Near-RT RIC) and while
they may take precedence over O1 slice specific configurations, they should be aligned and not deviate significantly from
O1 configurations.

7.7 E2 Interface
E2, which is the interface between the Near-RT RIC and the E2 nodes, supports E2 primitives (report, insert, control and
policy) to control the services exposed by E2 nodes [i.14]. These primitives will be used by slice specific applications
(xApps) to drive E2 nodes’ slice configurations and slice specific behaviour, such as slice based radio resource
management, radio resource allocations, MAC scheduling policies and other configuration parameters used by various
RAN protocol stacks.

E2 will be used to configure and receive slice specific reports and performance data from E2 nodes. These reports may
include 3GPP defined slice specific PMs (such as PRB utilization, average delay, etc. 3GPP TS 28.552 [8]) and new PMs
that may be defined by O-RAN to support various slicing use cases.

7.8 O1 Interface
O1, which is the interface between O-RAN managed elements and the management entity shall be used as specified in
O-RAN.WG1.O1-Interface.0-v04.00 [13], to configure slice specific parameters of O-RAN nodes based on the service
requirements of the slice. Some of the slice specific information models have been specified in 3GPP TS 28.541 [7],
including the RRM policy attributes to provide the ratio of PRBs and the split of these PRBs among slices. To support O-
RAN slicing use cases and their requirements, 3GPP information models may be extended and additional information
models may be defined to capture slice profiles and slice specific configuration parameters, which will be carried over
O1 interface as well.

O1 will also be used to configure and gather slice specific performance metrics and slice specific faults from O-RAN
nodes.

7.9 O2 Interface
O2, which is the interface between the SMO and O-Cloud as introduced in [i.15], shall be used for life cycle management
of virtual O-RAN network functions. As part of RAN NSSI creation and provisioning, RAN NSSMF, in interaction with
SMO, triggers the instantiation of necessary O-RAN functions (such as Near-RT RIC, O-CU-CP, O-CU-UP and O-DU)
based on slice requirements. After the creation of RAN NSSI, NSSMF in interaction with SMO may execute NSSI
modification and NSSI deletion procedures.

Since Non-RT RIC is part of SMO and would be instantiated along with other SMO functions, O2 is not expected to be
used for lifecycle management of Non-RT RIC.

7.10 Transport Network Slicing

As RAN slice subnet is composed of not only the O-RAN NFs but also the transport network components; Fronthaul
interface (FH) between O-RU and O-DU and the Midhaul interface (MH) between the O-DU and O-CU, transport slicing
aspects needs to be considered and incorporated into the overall O-RAN slicing architecture.

There are different emerging approaches for defining transport network slicing that can meet 5G requirements, which
mobile interfaces (fronthaul and midhaul in RAN slice subnet, backhaul between RAN slice subnet and core slice subnet,
and between core slice subnet and the PDN) may and need to be sliced, what form they will take and the number of slices
required at the transport layer [i.16].

This clause aims to capture the transport network slicing aspects for fronthaul and midhaul links and provide references
to relevant O-RAN specifications (related to fronthaul, intra-DC virtual links, inter-DC links). Given the current state and
progress in these WGs, this version of the O-RAN Slicing Architecture Specification will focus only on transport network
aspects, with the scope of the network segments covered by O-RAN as shown in figure 7.10-1. The area inside the dotted
green line characterizes the transport networks composed of a number of Transport Network Elements (TNE) deployed
among different components defined in other O-RAN WGs. O-RAN does not define the interfaces along the dotted green
line.

Figure 7.10-1: Xhaul transport network overview (ref: Figure 3-1 [i.16])

Packet switched transport network slicing:

O-RAN has defined the architecture and the best practices for an open Xhaul transport network based on an end-to-end
packet switching architecture in “Xhaul Packet Switched Architectures and Solutions specification” [i.16] that may
support the requirements outlined in O-RAN.WG9.XTRP-REQ-v01.00 [i.17]. While the “Xhaul Packet Switched
Architectures and Solutions specification” [i.16] describes the best practices for O-RAN transport based on end-to-end
packet switching technology, it is recognized that other solutions, not based on packet switching, could be utilized, or
mixed with a packet switching solution as well.

As indicated in clause 17 [i.16] the terms hard and soft slicing has emerged for transport networks, referring to the level
of isolation between different slices:

• Hard slicing: Transport resources are dedicated to a specific “Network Slice Instance” (NSI) and cannot be shared
with other slices.

• Soft slicing: Transport resources are shared and may be re-used by other slices.

A packet switched infrastructure, as described in [i.16], has an extensive toolset, consisting of underlay forwarding
solutions, Quality of Service (QoS) and VPNs that allows an operator to scalable partition the transport network to cater
for both hard and soft slices. Transport slice requirements and associated toolset are shown in figure 7.10-2.

Figure 7.10-2: Packet switched toolset for transport level slicing (ref: Figure 17-2 [i.16])

Further details of transport network slicing based on packet switching technology is captured in clause 17 and clause
18.10 of [i.16], including packet-switched underlay networks, transport network quality of service, 5G service and slices
and a transport slicing scenario on a packet switched Xhaul network.

8 O-RAN Slice Subnet Provisioning Procedures

8.1 O-RAN Slice Subnet Instance (O-NSSI) Allocation

Procedure
The procedure for allocation of an O-RAN slice subnet instance to satisfy the O-NSSI requirements is given in figure 8.1-
1.

Figure 8.1-1: O-NSSI allocation procedure

1) Slice subnet management function receives an allocate O-NSSI request (AllocateNssi operation specified in 3GPP
TS 28.531 [4], clause 6.5.2 shall apply) with network slice subnet related requirements (network slice subnet related
requirements specified in SliceProfile in 3GPP TS 28.541 [7], clause 6.3.4 shall be used).

2) Slice subnet management function checks the feasibility of O-RAN slice subnet related requirements utilizing O-
NSSI feasibility check procedure. If the network slice subnet related requirements can be satisfied, the following
steps are needed, else go to step 15.

3) Based on the O-RAN slice subnet related requirements slice subnet management function decides whether to use
an existing O-NSSI or create a new O-NSSI.

4) If using an existing O-NSSI and the existing O-NSSI needs to be modified, slice subnet management function
invokes the O-NSSI modification procedure.

5) If creating a new O-NSSI, slice subnet management function creates the MOI for the O-NSSI to be created and then
derives the corresponding O-RAN slice subnet constituent (i.e. O-RAN NF, constituent O-NSSI) related
requirements and transport network related requirements from the received network slice subnet related
requirements.

For each required O-NSSI constituent, steps 6-11 are needed:

6) If the required O-NSSI constituent is constituent O-NSSI, slice subnet management function invokes O-NSSI
allocation procedure (clause 8.1).

If the required O-NSSI constituent is a virtual O-RAN NF instance, steps 7-8 are needed:

7) Slice subnet management function derives O-Cloud requirements for O-RAN NF.

8) If the O-RAN NF is a virtual NF, slice subnet management function establishes virtual intra-Cloud links, allocates
slice tags (i.e., VLAN ID) and optionally instantiates NF on O-Cloud by executing network slice creation as
specified in O-RAN.WG6.ORCH-USE-CASES-v4.00 [18], clause 3.10.1. If an existing O-RAN virtual NF instance
needs to be modified, slice subnet management function may execute Scale Out of NF as specified in O-
RAN.WG6.ORCH-USE-CASES-v4.00 [18], clause 3.2.2, Scale In of NF as specified in O-RAN.WG6.ORCH-
USE-CASES-v4.00 [18], clause 3.2.3.

9) Slice subnet management function derives CM requirements for O-RAN NF.

10) Slice subnet management function executes provisioning management services as specified in O-RAN.WG1.O1-
Interface.0-v4.00 [13], clause 2.1.

11) Slice subnet management function configures the O-NSSI MOI.

For each transport network requirement, step 12 is needed:

12) If the transport link is a physical link that needs to be established across clouds, slice subnet management function
request transport link establishment from TN management functions.

13) If Non-RT RIC has subscribed for O-NSSI allocation event notifications, slice subnet management function notifies
Non-RT RIC with O-NSSI information.

14) Slice subnet management function returns appropriate O-NSSI allocation result (AllocateNssi operation specified
in 3GPP TS 28.531 [4], clause 6.5.2 shall apply). If the O-NSSI is created successfully, the result includes the
relevant constituent network slice subnet instance information (NetworkSliceSubnet IOC specified in 3GPP TS
28.541 [7], clause 6.3.2 shall apply).

8.2 O-RAN Slice Subnet Instance (O-NSSI) Modification

Procedure
The procedure for modification of an O-RAN slice subnet instance to satisfy the O-NSSI requirements is given in figure
8.2-1.

Figure 8.2-1: O-NSSI modification procedure

1) Slice subnet management function receives a modify O-NSSI request (modifyMOIAttributes operation specified
in 3GPP TS 28.532 [5], clause 11.1.1.3 shall apply).

2) Based on the modification request, slice subnet management function derives modification requirements for the
O-NSSI that may involve its constituents and transport network.

3) If required, slice subnet management function checks the feasibility of modification requirements utilizing O-
NSSI feasibility check procedure. If the network slice subnet modification requirements can be satisfied, the
following steps are needed, else go to step 11.

For each O-NSSI constituent that needs modification, steps 4-9 are needed:

4) If the constituent is an O-NSSI constituent that needs to be modified, slice subnet management function invokes
O-NSSI modification procedure (clause 8.2).

If the constituent is an O-RAN network function, steps 5 and 6 are needed:

5) If the constituent network function is an O-RAN virtual network function that needs to be instantiated / modified
/ deleted, slice subnet management function realizes the following use cases as specified in O-RAN.WG6.ORCH-
USE-CASES-v4.00 [18] depending on the modification requirements:

a. O-RAN.WG6.ORCH-USE-CASES-v4.00 [18], clause 3.2.1 Instantiate NF On O-Cloud

b. O-RAN.WG6.ORCH-USE-CASES-v4.00 [18], clause 3.2.2 Scale Out of NF

c. O-RAN.WG6.ORCH-USE-CASES-v4.00 [18], clause 3.2.3 Scale In of NF

d. O-RAN.WG6.ORCH-USE-CASES-v4.00 [18], clause 3.2.5 Terminate NF on O-Cloud

6) If the constituent network function needs configuration changes, slice subnet management function executes
provisioning management services as specified in O-RAN.WG1.O1-Interface.0-v4.00 [13], clause 2.1.

If O-NSSI constituent has TN part that needs to be modified, for each transport network requirement, steps 7-8
are needed:

7) If the transport link is within a cloud, slice subnet management function requests virtual link modification within
respective O-Cloud from NFO. Details of this request are not defined in the present document.

8) If the transport link is a physical link that is established across clouds, slice subnet management function requests
transport link modification from TN management functions. Details of this request are not defined in the present
document.

9) If O-NSSI MOI needs to be modified, slice subnet management function reconfigures the O-NSSI MOI.

10) If Non-RT RIC has subscribed for O-NSSI modification event notifications, slice subnet management function
notifies Non-RT RIC with modified O-NSSI information. Details of event notification between slice subnet
management function and Non-RT RIC are not defined in the present document.

11) Slice subnet management function returns O-NSSI modification result (modifyMOIAttributes operation specified
in 3GPP TS 28.532 [5], clause 11.1.1.3 shall apply).

8.3 O-RAN Slice Subnet Instance (O-NSSI) Deallocation

Procedure
The procedure for deallocation of an O-RAN slice subnet instance to satisfy the O-NSSI requirements is given in figure
8.3-1.

Figure 8.3-1: O-NSSI deallocation procedure

1) Slice subnet management function receives a deallocate O-NSSI request (DeallocateNssi operation specified in
3GPP TS 28.531 [4], clause 6.5.4 shall apply).

Slice subnet management function decides whether the O-RAN slice subnet instance needs to be modified or
terminated. If the O-NSSI needs to be modified, go to step 2 and then step 13, else steps 3-13 are needed.

2) Slice subnet management function invokes the O-NSSI modification procedure.

For each O-NSSI constituent, steps 3-9 are needed:

3) If the constituent is an O-NSSI constituent, slice subnet management function invokes O-NSSI deallocation
procedure (clause 8.3). Then go to step 13.

If the constituent is an O-RAN NF, steps 4-9 are needed:

If O-RAN NF needs to be terminated and is a virtual NF, steps 4-5 are needed, else if O-RAN NF needs to be
modified go to step 6.

4) Slice subnet management function derives the O-Cloud requirements for O-RAN NF termination to terminate the
NF within the respective O-Cloud.

5) Slice subnet management function removes virtual intra-Cloud links, optionally deallocates slice tags (i.e., VLAN
ID) and terminates NF on O-Cloud utilizing steps as specified in network slice deletion use case in O-
RAN.WG6.ORCH-USE-CASES-v4.00 [18], clause 3.10.2.

If O-RAN NF is a virtual NF that needs to be modified, steps 6-7 are needed, else go to step 8:

6) Slice subnet management function derives the requirements for O-RAN NF modification request to modify the NF
within the respective O-Cloud.

7) Slice subnet management function invokes Scale In of NF use case as specified in O-RAN.WG6.ORCH-USE-
CASES-v4.00 [18], clause 3.2.3.

If O-RAN NF needs to be reconfigured, steps 8-9 are needed, else go to step 10:

8) Slice subnet management function derives the CM requirements for the O-RAN NF.

9) Slice subnet management function invokes provisioning management services as specified in O-RAN.WG1.O1-
Interface.0-v4.00 [13], clause 2.1.

For each transport network requirement, step 10 is needed:

10) If the transport link is a physical link that needs to be modified/terminated across clouds, slice subnet management
function request transport link modification/termination from TN management functions.

11) If Non-RT RIC has subscribed for O-NSSI deallocation event notifications, slice subnet management function
notifies Non-RT RIC with O-NSSI deallocation.

12) Slice subnet management function returns appropriate O-NSSI deallocation result (DeallocateNssi operation
specified in 3GPP TS 28.531 [4], clause 6.5.4 shall apply).

8.4 O-RAN Slice Subnet Instance (O-NSSI) Feasibility Check

and Reservation Procedure

8.4.1 Introduction
The feasibility check and reservation procedure enables a service consumer to perform feasibility check and request
reservation for O-NSSIs. The reservation request is optional. The procedure determines if adequate resources are available
to support the O-RAN network slice subnet related requirements provided in the request. The procedure also allows a
service consumer to request the reservation of those resources for a period of time.

Annex A (informative): Implementation Options

A.1 Implementation Options

This clause presents example deployment options for various SMO options.

A.1.1 3GPP and ETSI NFV-MANO based O-RAN Slicing Architecture

Implementation Option

Figure A.1.1-1: O-RAN slicing reference architecture (ETSI NFV-MANO based example)

A 3GPP – ETSI NFV-MANO based example of O-RAN slicing reference architecture and interfaces is shown in figure
A.1.1-1 to describe the relationship between 3GPP defined slice management functions (NSMF, NSSMF), 3GPP defined
management functions (3GPP TS 28.531 [4], Network Function Management Function (NFMF) and O-RAN network
functions in terms of slice lifecycle management and slice configuration procedures. Life Cycle Management (LCM)
procedures for mobile networks that include Virtualized Network Functions (VNFs) as well as addition of Physical
Network Functions (PNFs) to Network Service (NS) instances are specified in 3GPP TS 28.526 [3].

A.1.2 ONAP based O-RAN Slicing Architecture Implementation Option

Figure A.1.2-1: Example architecture depiction for ONAP based O-RAN slicing support

Current version of ONAP - O-RAN slicing reference architecture is shown in figure A.1.2-1 (based on ONAP G-release).
In this architecture, one option is RAN NSSMF being located within SMO and is responsible for the entire RAN subnet,
including the O-RAN NFs and the related O-RAN transport network components; Fronthaul interface (FH) between O-
RU and O-DU and Midhaul interface (MH) between O-DU and O-CU. RAN NSSMF determines slice specific
configuration of O-RAN NFs based on SliceProfile received from NSMF and determines the necessary slice specific
requirements for FH and MH interface triggering Transport Network Management Domain (TN MD) to execute the actual
configuration of FH and MH interface. ETSI ZSM based management domain approach is adopted for TN management.

Annex B (informative): Transport Network Slicing

B.1 Transport Network Slicing Use Cases

This clause describes the ORAN transport network slicing related use cases and per-slice configuration of O-RAN
transport network instances, phases of transport network slicing definition process and the corresponding scope of work
for the relevant O-RAN WGs, considering the projected progress.

Transport network slicing use cases are built based on the definitions of slicing in O-RAN WG1 Slicing Architecture
Specification, WG6.CAD Scenario C.1 and C.2, WG4 O-RU Slicing with support of RAN-Sharing (WG4 Use Case 7
and Use Case 10).

Transport network slicing use cases are grouped into phases to incrementally extend the scope of work in relevant O-
RAN WGs.

Brief definition of phases:

Phase 1: Slicing as specified in 3GPP TS 22.261 [1], [i.2] and 3GPP TS 23.501 [2]. Slicing appears on the N3 (NG)
interface. Number of slices are limited. UPF is centrally located.

Phase 2: Phase 1 is augmented with per-slice QoS characteristics. Slices are multiple with multiple exit-points and local
break-outs.

Phase 3 and beyond are not defined in the present document.

For the current version of transport network slicing use cases the following scope and constrains are assumed, based on
mutual discussions and agreements between WG1, WG6, WG9:

• Delineation of slices in O-RAN CUPS user plane interfaces for current phases 1-5 is based on physical or
VLAN+IP separation. For this delineation, procedures for coordination between TN<>O-RAN and TN<>5GC
provisioning VLAN, IP and corresponding TN service instances are expected.

• Fronthaul – connectivity driven domain, providing traffic differentiation and prioritization according to open
fronthaul interface definition, given in O-RAN.WG4.CUS.0-v06.00. No need to support slicing in phases 1 to 4.
The support for multi-vendor slicing in the fronthaul is expected to be introduced in phase 5.

• Midhaul – connectivity driven domain, providing traffic differentiation and prioritization according to 5QI model
of F1 interface, defined in TS38.474. No need to support slicing in phases 1 to 3. DDoS prevention and traffic
control are expected to protect O-DUs from O-CU-UPs, which in future phases may belong and be controlled
by 3rd parties. From phase 3 and beyond, midhaul is slicing aware domain, serving communication of O-CU-
UP<>O-DU with slicing. For that O-CU-UP and O-DU are expected to perform marking of F1AP with DSCP
and attach VLAN .1q tag and assign IP for slice delineation.

• Backhaul – slicing aware domain, serving communication of UPF <> O-CU-UP with slicing. O-CU-UP and UPF
are expected to perform marking of N3 interface according to 5QI<>DSCP marking and push .1q tag and assign
IP for slice delineation.

• Based on shared O-RU feature progress (WG4 Use Case 7 and Use Case 10), single O-RU are expected to serve
multiple slices and multiple O-DUs, so the expectation is to have capability to maintain mapping of PLMN ID
information to corresponding VLAN+ optional IP pair on C/U Plane of open fronthaul interface.

• O-DU is expected to support multiple slices. Single O-DU, serving multiple slices, supposed to have capability
to maintain mapping of O-NSSI information to corresponding VLAN+IP pair on F1 interface and 5QI to DSCP
mapping. This assumes progress of WG5 effort on definition upstream DU > CU_UP F1_U 5QI<>DSCP
mapping capabilities.

• O-CU-UP is expected to support multiple slices. Single O-CU-UP, serving multiple slices, supposed to have
capability to maintain mapping of O-NSSI information to corresponding VLAN+IP pair on F1 interface, however
in current phases 1-5 it is assumed that cluster of O-CU-UPs will serve single O-NSSI, as it is shown in figure
B.1-1.

Figure B.1-1: Assumption of mapping functions of O-DU and O-CU-UP to slices

From O-RAN perspective, a single network slice may start from O-DU and may have multiple distributed O-CU-UPs and
UPFs, connecting a certain slice in data network with multiple N6 interfaces and multiple local breakouts.

In TN domain TNEs with attachment circuits to O-RU, O-DU and O-CU-CP and O-CU-UP maintain corresponding QoS
schemes and transport network slice profiles as shown in figure B.1-2 and in figure B.1-3.

Figure B.1-2: Types of slicing in various O-RAN scenarios

Figure B.1.-3: Types of attachment circuits in TNE

The assumptions of slicing capabilities on the core and O-RAN for the option 1 which are mapped to the phase 1 are
given in figure B.1-4.

The option 2 depicts the expectation of the target capabilities of the systems, including capabilities on the option 1.

Figure B.1-4: Options for slicing, demapping orthogonal plane of 5QI per slice in option 1 and
multiple planes of 5QI as attribute per planes of slices

For phase 1 following constrains are assumed (see figure B.1.5):

1) Single operator with one O-NSSI MBB, one O-NSSI mMTC, one O-NSSI NB-IoT slice.

2) Fix mapping of slices inter to intra – DC.

3) Flat mapping of standards based 5QI (3GPP TS 23.501 [2], table 5.7.4-1) <> DSCP <> QoS in TN domain.

Figure B.1-5: Diagram of network location of O-RAN instances with relevant domains for use cases

As an outcome of the following mapping, it is expected capability of TN domain to accommodate all domains with
relevant QoS profiles and slices in each TNE, as shown in figure B.1.6 below:

Figure B.1-6: Diagram of O-RAN flows to be accomodated in each TNE

Table B.1-1 captures assumptions of TN slicing capabilities in each interface for the phase 1.

Table B.1-1: Scope of the capabilities of O-RAN elements in phase 1

ORAN Stream Queue Slicing Differentiated QoS

direction VLAN behavior per slice
interface

Fronthaul C/U Any EF (HP) No No

Fronthaul M-pane, Any AF No No

ORAN Stream Queue Slicing Differentiated QoS

direction VLAN behavior per slice
interface

E1, E2, F1_c, O2, A1,

Xn_c, N2, N4

F1_U DU > CU-UP AF* or 5QI<>DSCP No No

mapped**

F1_U CU-UP > DU 5QI<>DSCP No No

mapped**

N3 (NG) CU-UP > UPF 5QI<>DSCP Yes No

mapped**

N3 UPF > CU-UP 5QI<>DSCP Yes No

mapped**

Xn_U Any 5QI<>DSCP mapped No No

(as per TS 38.424)

* Based on current 3GPP TS38.474, clause 5.4 definition of 5QI<>DSCP capability of F1_U for the link DU > CU-UP
may be limited. If this is the case, for the phase 1 the mapping of F1_U is recommended to a bandwidth queue.

** 5QI QoS identifiers, the priority level (if explicitly signaled), and other NG-RAN traffic parameters (e.g., ARP) in O-
RAN and core domains mapped to DSCP and ToS or CoS parameters, aligned with TN domain with accordance to NRM
as specified in 3GPP TS 28.541 [7], with the flow shown in figure B.1-7 below:

Figure B.1-7: Diagram of profiles information model parameters mapped to the domains to form a
slice

According to these parameters, the relation of RANSliceSubnetProfile and RANSliceSubnetProfile with VLAN and IP
mapping could be established with corresponding EP_Transport VLAN and IP mapping, allowing TN domain to perform
separation allocation of resources per slice.

Definition of 3GPP IM/DM in 3GPP TS 28.541 [7] TN domain is out of scope, and network slice parameters of the RAN
and CN are existing in the corresponding fields of the IM/DM. More details in of 3GPP IM/DM in regard for network
slicing can be found in O-RAN.WG9.XTRP-MGT.0-v04.00 [i.19], clause 9.1.

Phase 2 assumes the following constrains (see figure B.1-8):

1) Single operator with enterprise slices use case.

2) Number of slices: many.

3) Multiple exit points and multiple UPFs.

4) Per-slice (tenant) 5QI<>DSCP<>QoS model in TN domain.

Figure B.1-8: Scope of the capabilities of O-RAN elements in phase 2

* 5QI QoS identifiers, the priority level (if explicitly signaled), and other NG-RAN traffic parameters (e.g., ARP) in O-
RAN and core domains mapped to DSCP and ToS or CoS parameters, aligned with TN domain with accordance to NRM
as specified in 3GPP TS 28.541 [7], with the flow shown in figure B.1-9 below:

Phase 2 and 3:

Figure B.1-9 Diagram of use cases for phase 2 and 3

Table B.1-2 captures assumptions of TN slicing capabilities in each interface for the phase 2 and later.

Table B.1-2: Scope of the capabilities of O-RAN elements in phase 2 and later

ORAN Stream Queue in 4Queue model Slicing Differentiated

direction VLAN QoS behavior
interface per slice

Fronthaul C/U any EF (HP) no no

Fronthaul M-pane, any AF no no

E1, E2, F1_C, O2, A1,

Xn_c, N2, N4

F1_U DU > CU-UP 5QI<>DSCP mapped* yes** no

F1_U CU-UP > DU 5QI<>DSCP mapped yes** no

N3 (NG) CU-UP > UPF 5QI<>DSCP mapped*** yes no

N3 UPF > CU-UP 5QI<>DSCP mapped*** yes no

Xn_U any AF no no

*Based on assumption on WG5 and WG6 effort on definition upstream DU > CU_UP F1_U 5QI<>DSCP mapping
capabilities.

**Based on assumption on WG5 and WG6 effort on definition F1_U slicing capabilities (inter-DC risk of missing the
March train).

***More on Mapping recommendation in WG9 “RBBN-TFCA-QoS mapping” contribution.

After this analysis and discussions within ORAN WG9 the conclusion is that NRM as specified in 3GPP TS 28.541 [7]
does not provide enough data to create valid transport network slice.

However, since some of the parameters required to create transport network slice may be extracted from NRM as specified
in 3GPP TS 28.541 [7] and some may be translated from SMO expectations, the following scope of work for WG9 and
WG10 is proposed:

- Collect missing parameters in 3GPP TS 28.541 [7] for TN slice creation.

- Propose enhancements of 3GPP TS 28.541 [7] to include OpenModelClass TNSliceSubnet to link EP_Transport
to TN and add options for linking 3GPP subsystems to TN subsystems.

- File ORAN liaison to SA5 in order to augment 3GPP TS 28.541 [7] with missing information and proposed
items.

- Align with IETF TN network slice abstraction.

- Define information flows.

- Align ORAN WG1, WG9 and WG10.

Annex C (informative): Slicing Terminology

C.1 Slicing and 3GPP Slice Modeling Terminology Awareness

This clause intends to provide further information and clarified awareness for some of the fundamental network slicing
concepts and 3GPP modeling aspects.

C.1.1 Conceptual Differences Between 3GPP SA2 and SA5

(System Architecture) Network Slice (3GPP SA2): Even though this is a system architecture group, the RAN architecture
is out of the scope of SA2. RAN3 owns the RAN architecture. SA2 service-based architecture (SBA) is a functional
architecture with mostly service-based interfaces.

(Management Aspect) Network Slice (3GPP SA5): SA5 describes all the management aspects of a network, which is
modular, and model driven. It is a service-based management architecture (SBMA), using service-based API allowing
implementations to pick and choose appropriate API and compliance per API. See 3GPP TS 28.533 [i.18].

A Network Slice Instance (NSI), a SA2 term, is a set of functions. SA2 also introduced the concept of an instance because
there would be more than one slice of the same type for the purpose of scaling. What is managed by an operator is a group
of functions (an NSI).

A NetworkSlice Managed Object Instance (MOI), a SA5 usage, is an object exposing to an external consumer. Once an
operator builds a something to satisfy expectations, it needs to build something that is exposed to an external consumer
which is a NetworkSlice MOI. Scale in/Scale out is an operation within life cycle management which is under the purview
of SA5. In the context of SA5, a NSI is just an attribute carrying signaling “NSI” value semantic. From a management
perspective, the abbreviation NSI is sometimes used as a replacement of the proper term NetworkSlice MOI. However,
this is just an improper use of terminology.

A NetworkSliceSubnet MOI is sometimes called an NSSI. However, in SA5, any occurrences of the term NSSI should
be perceived as a NetworkSliceSubnet MOI.

C.1.2 Name Containment Limitation

NSSI stands for NetworkSliceSubnet Instance a.k.a. Managed Object Instance (MOI) of the NetworkSliceSubnet
Information Object Class (IOC).

NetworkSliceSubnet IOC has been introduced to group instances (of any IOC) in a way that is not restricted by the Name
Containment (DN) rules. Those name containment rules are specified in 3GPP TS 32.300 [9]. Name containment defines
a managing hierarchy. This is ok; however, it restricts the flexibility needed for network slice management (especially for
shared network functions).

This shortcoming of the 3GPP TS 32.300 [9] is addressed by the NetworkSliceSubnet which allows for multiple views or
“overlays” to augment the management hierarchies. This grouping is independent of how the network is managed and
structured via distinguished names. Note that the NetworkSliceSubnet inherits from the top IOC (3GPP TS 28.541 [7],
clause 6.2.2).

This is illustrated in the following diagram given in figure C.1.2-1:

Figure C.1.2-1: Multi-parent inheritance supported from network slice subnet instance

C.1.3 Network Slice Subnet is a Purposeful Generic Collection

The definitions and diagrams that follow are driven from 3GPP 5G NRM specifications in 3GPP TS 28.541 [7]. The 3GPP
5G NRM serves as a foundation for ORAN specification development, and modeling work from which ORAN
development aligns to. For further details, please refer to O-RAN WG5 and WG10 specifications. The diagrams in this
document utilize elements from the 3GPP 5G NRM but should be fully applicable to the ORAN IM.

The NetworkSliceSubnet is a purposeful generic collection of objects. The NetworkSliceSubnet can be comprised of a
number of managedfunctions, networkservices and EP_Transport endpoints as shown in the diagram below inspired from
the 3GPP TS 28.541 [7], clause 6.

Three key points that the diagram illustrates is that:

1. Generic Collection: The NetworkSliceSubnet is a purposeful generic collection of objects shown in the diagram.

2. Recursive:The NetworkSliceSubnet is a recursive structure which may self-reference NetworkSliceSubnets

3. Purposeful: The “purpose” of that generic collection of objects is defined in the SliceProfile.

NOTE 1: The cardinality between NetworkSliceSubnet and SliceProfile which is written as 1…* could be an
empty list: 1…0 which would imply there is no SliceProfile. You could group a set of objects without a profile.
Profiles are derived from the SLS.

NOTE 2: It is stated that it is under consideration in 3GPP that the SliceProfile can become an IOC.

These points are highlighted in the following diagram given in figure C.1.3-1:

Figure C.1.3-1: NetworkSliceSubnet is a purposeful generic collection

C.1.4 Slicing Instance Example

The following diagram given in figure C.1.4-1 shows an example instance of a NetworkSliceSubnet.

Figure C.1.4-1: Slicing instance example

As a concrete example given in figure C.1.4-1, the above diagram shows instances of managed functions and network
slice subnets. Depicted are two network slices (NS1, NS2), with their associated NetworkSliceSubnets, core and RAN
managed function components. The picture illustrates that NetworkSliceSubnets are generic groupings of objects. These
relationships are indicated by the <<groups>> tag. This diagram shows two eMBB network slices that are providing two
different services with different throughput SLA requirements within the network of the same service provider (PLMN-
A).

Notice that the NetworkSliceSubnets have SliceProfiles associated with them in this example. The illustration also
highlights how some name containment relationships (3GPP TS 32.300 [9]). These are indicated by the <<names>> tag.
Notice that NSS2 (NetworkSliceSubnet #2) is a collection of 5G core components (UPF1, AMF1, SMF1); and that NSS1
is a collection of 5G RAN components (DU1, CUCP1, CUUP1, NRCellDU1, NRCellCU1). NSS3 and NSS4 are the
NetworkSliceSubnets that expose the “stitched” groupings. The NSS3/NSS4 will have a slice profile that reflects the
entire SLA/SLS represented by the service profile. While NSS1/NSS2 will have portions of the entire SLS pertaining to
the corresponding (e.g. transport, RAN, core) parts of the slice. This illustrates that the “stitching” occurs at the OSS /
network management layer not at the BSS layer where slice orchestration happens. Slice instances at the BSS, the subnets
are handled as the management layers.

C.1.5 NSSI Slice Profile and PLMNInfo

The “purpose” of the NetworkSliceSubnet MOI is given in the SliceProfile which is associated with it. It may be
associated with a particular network slice or a group of network slices. The association is accomplished through the
pLMNInfoList attribute of the SliceProfile. The Slice Profile is a data type that represents the requirements or purpose
of the generic collection instance that may support one or more NetworkSliceSubnet instances. For an end-to-end Network
Slice to exist, it is expected that it would have an associated slice profile containing a pLMNInfoList.

NOTE: A NetworkSliceSubnet may be just a generic collection of objects not associated with an End-to-End Network
Slice. In this case, there may not be a slice profile associated with NetworkSliceSubnet.

Both 3GPP Release 16 and 3GPP Release 17 5G NRM have the SliceProfile, therefore 3GPP TS 28.541 [7] shall be used
for further details. This is illustrated in the following diagram given in figure C.1.5-1:

Figure C.1.5-1: Slice Profile contains a List of PLMNInfo

C.1.6 Managed Functions Have a List of PLMNInfo

The concrete managed functions, notably the gNBCUUPFunction, NRCellCU and NRCellDU each can have a list of
PLMNInfo attributes. Concrete managed functions are configured with the slice information via the pLMNInfoList
attribute. It is mainly used for signaling. Additionally, the concrete managed function becomes associated with a network
slice.

There are two possible error scenarios:

First, a managed function can be configured with a particular entry in the pLMNInfoList but it is not member of any
network slice subnets associated with profiles containing the same entry in their pLMNInfoList (signaling configured,
management association missing).

Second, a managed function cannot be configured with a particular entry in the pLMNInfoList but is a member of a
network slice subnet associated with profiles containing this particular entry (management association present, signaling
configuration missing).

This is illustrated in the following diagram given in figure C.1.6-1:

Figure C.1.6-1: Managed functions have a list of PLMNInfo

C.1.7 Single Network Slice Selection Assistance Information (S-NSSAI)

A Single Network Slice Selection Assistance Information (S-NSSAI) is used to define a slice. It is a 32-bit number defined
by 3GPP TS 23.003 [i.2], clause 28.4.1. S-NSSAI is comprised of Slice / Service Type (SST) and Slice Differentiator
(SD). SST have values 0 to 127 standards reserved and 128 values are operator defined. These are specified in 3GPP TS
23.501 [2]. The standardized SST values are specified in 3GPP TS 23.501 [2], clause 5.15.2.2.

Annex D (informative): Multi-Operator Slice RAN

Management Services Exposure

D.1 RAN Management Services Exposure for Multi-Operator

Slice
Sharing of RAN resources is one of the key requirements for Mobile Network Operators (MNO) to reduce the RAN
infrastructure cost and increase profitability, while enhancing the coverage. Currently O-RAN drives the RAN sharing
models and associated considerations through WG1 Use Cases Detailed Specification Use Case 7: RAN Sharing which
focus on the MORAN (Multi Operator RAN) scenario and sharing computing resources (for more details 3GPP TS 22.261
[1] shall be used). The goal of the existing RAN Sharing use case is to enable multiple operators to share the same O-
RAN infrastructure wherein each operator utilizes a separate carrier, while allowing them to remotely configure and
control the shared resources via a remote O1, O2 and E2 interface.

While the RAN Sharing use case set the premise for sharing the infrastructure and extending the management interfaces,
the use case does not clearly depict the network slicing scenarios especially offering and usage of RAN objects related to
network slicing in context of relation between multiple operators. The need for such a slice usage consumption /offering
scenario is depicted in 3GPP specification 3GPP TR 28.824 [i.7], 3GPP TR 28.801 [i.3], 3GPP TS 28.530 [23] and other
industry initiatives like 5GPPP Slicenet [i.10] project. Specifically, 3GPP TR 28.824 [i.7] depicts the management
capability exposure across multiple operators, especially Network Operator (NOP) role played by multiple operator
organizations – one offering RAN objects related to network slicing and other using the RAN objects related to network
slicing to establish an end-to-end slice. Few examples of business use cases are depicted below:

- Cross MNO Model of offering and usage of RAN objects related to network slicing

• Two MNOs get into agreement in a scenario where one of the MNOs do not have spectrum or coverage in a
particular region (such as foreign country, remote areas, out of service area) to share RAN resources. The arrived
solution to share RAN is to utilize RAN objects related to network slicing to fix coverage gaps. E.g., network
slice consisting of core objects belonging to MNO1, and RAN objects belonging to MNO2.

• Many MNOs form a consortium and share RAN resource through bulk provisioning of RAN objects related to
network slicing that can be offered on demand for subscription to address the needs of consortium participating
MNOs (for example to address the emergency, disaster response).

• MVNO relying on multiple MNOs. Each MNO offers its RAN resources as RAN objects related to network
slicing.

- MNO and Hyperscale Public Cloud Provider slice consumption offering model

• There is a market trend of collaboration between Hyperscale Public Cloud companies and MNOs in which
Hyperscalers count on access network infrastructure owned by MNO, while utilizing the edge and core network
services using their own or partner services. In this model the RAN objects related to network slicing is offered
to the Hyperscalers and integrated to offer a unified service.

Considering that standards, related marketing trends and described cases with multiple parties involved, there is a great
value to streamline parties’ interaction with respective O-RAN specification activities.

From an O-RAN standardization perspective following three aspects need to be considered in context of these use case
models:

• Exposure of management services providing lifecycle management, CM, FM, PM, performance analytics and
other management capabilities of RAN logical instances (as a collected group of RAN objects related to network
slicing) for usage of RAN objects related to network slicing in context of relation between multiple operators

• Exchange and mapping of resource identifiers corresponding to a collected group of RAN objects related to
network slicing for it to be composed into an end-to-end slice.

• Governance of the exposed RAN slice subnet management services for them to be made available externally in
a secured and manageable manner.

NOTE 1: Logical instances as collected group of RAN objects related to network slicing implies representation of a
group of logical components within each RAN node that collectively provide required characteristics of network slice
at RAN part which is commonly called in the O-RAN Slicing Architecture Specification as O-RAN slice subnet.

NOTE 2: Direct SMO exposure to external slice management systems across MNOs assumes prior business agreement
(contract) between parties.

NOTE 3: Correct interpretation of FM and PM data may require prior interface agreements with exchange of related
data (e.g., specifications of PM, FM problem types, MIB files).

NOTE 4: “Multi-Operator slice” is a term used to represent a concept of end-to-end network slice that uses RAN slice
subnet instances (collected group of RAN objects related to network slicing) provided by MNO in shared RAN
resources. As needed, the partner operator would define its PLMN specific network slice (as per 3GPP TS 23.501 [2],
slice is identified by S-NSSAI within a specific PLMN ID but not multiple PLMN IDs) in that end-to-end slice.

D.1.1 Management Services Exposure for Multi-Operator Slice - Relevant

Standards
• 3GPP TS 28.530 [23], clause 4.1.6 Network Slice as a Service (NSaaS): Explains the concept of NSaaS offered
by CSP to CSC and the ability of the CSC to manage the network slice as manager via management interface
exposed by the CSP. Further, the CSC is also allowed to offer their own services (e.g., communication services)
on top of the network slice obtained from the CSP.

• 3GPP TS 28.533 [i.18], clause A.3 Utilization of management services by Exposure Governance Management
Function (EGMF): Explains the management capability of EGMF, especially exposure governance and also
depicts an example of exposing the Management Function (MnF) capability through the EGMF to MnF from
another operator or to 3rd Party. The standardization of EGMF in 3GPP is not mature and require further
elaboration.

• 3GPP TS 28.824 [i.7]: Focused study on network slice management capability exposure. Highlights the general
concept of exposure of management service (e.g., via BSS, without going through BSS), the roles related to
network management capability exposure, types of interfaces for exposure of network slice. Further, the study
item also highlights a use cases and scenario of exposure of network slice as a service, wherein RAN slice is
offered as a product to CSP. This informative clause reuses the concepts defined in 3GPP 28.824 [i.7] and
investigate the O-RAN specific impacts.

• 3GPP TR 28.811 [i.8]: Study on the network slice management enhancements. This study item covers potential
enhancements to slice management such as multi-operator relationships in network slice management, concepts
like roaming, network slice isolation, edge computing, network slice specific authentication, management data
isolation for different Network Slice Consumers (NSCs). One relevant scenario considered in the study item is
network slice using multiple networks scenario which highlights two potential options – a) Solution based on
Network Slice as a Service (NSaaS) – enhancements to NetworkSlice IOC or new ExternalNetworkSlice IOC
and b) Solution based on Network Slice Subnet as a Service (NSSaaS) - enhancements to NetworkSliceSubnet
IOC or new ExternalNetworkSliceSubnet IOC.

• 3GPP TR 28.801 [i.3]: Study on management and orchestration of network slicing for next generation network.
Clause 5.1.8.2 describes the scenario of creating an end-to-end network slice instance across multiple operators.
Similarly, clause 5.1.9 describes a scenario of limited level of management exposure for multiple network slice
instances.

• 3GPP TR 23.700-99 [i.9]: Study on Network Slice Capability Exposure for Application Layer Enablement
(NSCALE). This study identifies key issues, solutions, and potential requirements to enable exposure of network
slice management capabilities applied to vertical industries (exposure to application function). This study item
highlights some key requirements that may be relevant for the external management of RAN slice subnet – such
as the ones described in clause 4.1.1 [i.9] - The application enablement layer should support interaction with
3GPP network management system to consume network slice management service.

D.1.2 Concepts of Management Services Exposure for Multi-Operator

Slice
This clause summarizes the key concepts related to management services exposure for multi-operator slice. These
concepts build on those already defined in 3GPP TR 28.824 [i.7].

• exposed Management Service (eMnS): The SMO has a certain set of capabilities. Some of the capabilities of the
SMO need to be exposed northbound.

• eMnS producer: The logical function of SMO that provides management service that can be consumed by an
eMnS consumer.

• eMnS consumer: The logical entity outside the administrative and trust boundaries of SMO that consumes
exposed management service.

• MnS producer: The logical function of SMO that provides management service(s) that can be discovered and
consumed within a MNO's administrative and trust boundaries.

• eMnS exposure: Set of procedures that make available management service in SMO for external consumer. This
can include registration of service producers in external exposure functions, publishing of a management service
for external exposure, authentication, and authorization of eMnS consumer, discovery of required eMnS based on
selection criteria defined by eMnS consumer.

• eMnS discovery: Discovery of the eMnS producer management services by an eMnS consumer based on its
selection criteria.

• SMO external exposure functions: Abstract notion to be used in use cases and scenarios description consolidating
SMO services providing capabilities to support eMnS exposure and potentially other similar services. SMO
external exposure function is used as an example to logically represent this set of capabilities.

NOTE 1: The discovery service can be realized using either an existing service discovery functions in SMO or to be
defined new SMO external exposure functions or a gateway function as defined in 3GPP 28.533 [i.18] like EGMF. The
exposure of eMnS capabilities may also adopt the approach in 3GPP TR 23.700-99 [i.9] leveraging the Network Slice
Capability Enablement Server (NSCE-S) in combination with EGMF.

NOTE 2: Since SMO external exposure function is not limited to eMnSs related to RAN network slicing, it is assumed
to be addressed within the scope of WG1 Architecture work and is not supposed to be formally defined in this
specification. An extensive functional description is beyond the scope of this specification. Some potential references for
realizing the functionality of SMO external exposure functions are – CAPIF (3GPP TS 23.222 [i.5], 29.222 [i.6]), EGMF
(3GPP 28.533 [i.18]) etc.

• Operator business roles:

o Managed Network Operator (MNO): provides or consumes management services related to RAN slicing.

o E_NSSMS_C (External consumer of MnS related to RAN slicing): Operator who discovers and
consumes eMnSs related to RAN slicing.

o E_NSSMS_P (Provider of external MnS related to RAN slicing): Operator who is exposes and provides
eMnSs related to RAN slicing.

D.1.3 Management Aspects of External Exposure of MnS Related to RAN

Slicing

D.1.3.1 General
External exposure of MnS related to RAN slicing may be treated as a particular case of the generic service exposure
existing in the industry and covered in standard specifications like 3GPP Common API Framework [i.5], [i.6]. Therefore,
many aspects related to generic exposure architecture may be applicable to the the external exposure of MnS related to
RAN slicing case as well.

According to 3GPP CAPIF framework, clear separation of registry specific aspects and service specific aspects is
recommended in functional model, architecture, and procedures. In CAPIF architecture the CAPIF core function
consolidates all registry specific aspects and enable service APIs from both the MNO trust domain and the 3rd party trust
domain having business relationship with MNO, while service specific aspects are covered by API provider functions
(API Exposing Function (AEF), API Publishing Function (APF) and API Management Function (AMF)).

Similarly, management of external exposure of MnS related to RAN slicing would include two categories of aspects:

- related to service specific aspects (i.e., actual processing of service requests to exposed management services
(eMnSs) from E_NSSMS_C e.g., service endpoint termination, throttling, translation between external and
internal information, re-exposure of service operations and events, topology hiding, routing, etc.)

- related to registry and catalog specific aspects (i.e., capabilities to manage various data records and profiles to
support registration, discovery, publishing, identity management, authentication, authorization, access policies,
data translation rules, topology hiding policies etc.)

While the CAPIF framework helps to reuse registry specific capabilities for various API exposure scenarios, it presumes
decomposed architecture with additional interactions between CAPIF Core Function (CCF) and API provider functions
(AEF, APF, AMF) which adds more complexity and need not to be always preferred.

With regards to possible impact on capabilities of SMO management services, at least two alternative options can be
considered for management of external exposure of MnS related to RAN slicing:

- Option 1: Consolidation of exposure capabilities (see figure D.1.3.1-1). Internal SMO management services are
off-loaded from capabilities of external exposure as much as possible, i.e., service-related aspects are as well
managed by dedicated category of SMO external exposure services.

E_NSSMS_C
External consumer of MnS related to RAN slicing

Authentication,
discovery,… Operations

SMO/
SMO external exposure functions
E_NSSMS_P
Registry service specific
SMO external
Capabilities aspects
exposure services
capabilities

Capabilities of SMO Capabilities of SMO

external exposure Management Services
services

SMO Functions
SMO
Management
Services

Services producing Services consuming

Figure D.1.3.1-1: Option 1: Consolidation of exposure capabilities

- Option 2: Decomposition of exposure capabilities (see figure D.1.3.1-2). Internal SMO management services are
aware of exposure and enriched with at least service specific aspects to proceed requests from external consumer
of MnS related to RAN slicing following identity and policy information managed in SMO external exposure
services responsible for registry specific aspects.

E_NSSMS_C
External consumer of MnS related to RAN slicing

Authentication,
discovery,…

SMO/
SMO external exposure functions
E_NSSMS_P

SMO external Registry Operations

exposure services Capabilities

Capabilities of SMO Capabilities of SMO

external exposure Management Services
services

SMO Functions
SMO service specific
Management aspects
Services capabilities

Services producing Services consuming

Figure D.1.3.1-2: Option 2: Decomposition of exposure capabilities

NOTE: CAPIF is originated out of 3GPP SA6 WG (application enablement and critical communication applications group
for vertical markets) and 3GPP CT WG3 (design and specification of the Northbound APIs between the vertical
application servers and the core network) which are not dedicated to management specifications design. Management
specifications design is in responsibility of 3GPP SA5 WG (Management, Orchestration and Charging for 3GPP systems)

SA5 WG gives high level definition [i.18] of Exposure Governance Management Function (EGMF) as a management
function with the role of management service exposure governance (i.e., abstraction, simplification, filtering, etc.).
Functional model and requirements are not yet defined for EGMF. 3GPP conducts the study ([i.7] not yet finalized)
suggesting possible roles of EGMF and possible solutions for combined CAPIF/EGMF architecture applied to

management domain. One of the considered architectures is where EGMF consolidates the registry specific functions
(CAPIF core function) and API provider domain functions.

D.1.4 Multi-Operator Slice: High Level Use Cases and Potential

Requirements for Exposure fo MnS Related to RAN Slicing
As noted above, the term “multi-operator slice” is used here to represent a concept of end-to-end network slice that uses
RAN slice subnet instances (collected group of RAN objects related to network slicing) provided by MNO in shared RAN
resources. As needed, the partner operator would define its PLMN specific network slice (as per 3GPP TS 23.501 [2],
slice is identified by S-NSSAI within specific PLMN ID but not multiple PLMN IDs) in that end-to-end slice.

This clause provides the high-level use cases and potential requirements for controlled external exposure of of MnS related
to RAN slicing.

D.1.4.1 Registration of Producers of MnSs Related to RAN Slicing for External Exposure

D.1.4.1.1 Background and Goal of the Use Case

In order to expose MnS related to RAN slicing externally SMO functions responsible for external exposure (SMO external
exposure functions) need to be aware of producer of these services in SMO. This can be achieved by registering producers
of respective MnSs in SMO external exposure functions.

D.1.4.1.2 Description
Pre-condition

• There are existing trust relations between SMO external exposure functions and SMOF that is a producer of MnS
related to RAN slicing.

• SMOF can reach SMO external exposure services (as one of the possibilities, SMOF gets informed of SMO
external exposure services capabilities and service end-points through preliminary registration of SMO external
exposure functions as a producer of SMO external exposure services in SMOF responsible for service
registration and management).

NOTE: SMOF responsible for service registration and management is not yet formally defined in SMO architecture.

• SMOF playing a role of a producer of MnS related to RAN slicing determines its MnSs are required to be
exposed externally.

• SMO function responsible for external exposure does not have information about the producer of MnSs related
to RAN slicing.

High level procedure (see figure D.1.4.1.2-1)

1. SMOF playing a role of a producer of MnS related to RAN slicing requests SMO external exposure services to
register its MnSs.

2. SMO external exposure services producer creates registry record for the producer of MnSs related to RAN slicing
containing data about available MnSs and additional data (e.g., id, end-point URIs, MnS producer profile with
supported MnSs, load level, heartbeat etc).

3. SMO external exposure services producer acknowledges the successful registration or failure. SMO external
exposure function may subscribe to SMOF status or SMOF sets pushing status heartbeat.

SMO/
SMO external exposure functions
E_NSSMS_P
Registry
SMO external
exposure services
Capabilities
2
No Record Record created
0

1 3
SMO Functions
producer of MnS MnS MnS MnS
related to RAN slicing

Figure D.1.4.1.2-1. Flow of registration of MnS related to RAN slicing for external exposure

Post-condition

SMO external exposure services producer has created the registry record for a producer of MnS related to RAN slicing.

D.1.4.1.3 Potential Requirements

REQ-SL-EXP-FUNxx SMO should support a capability to register MnSs that are required to be exposed externally.

REQ-SL-EXP-FUNxx SMO should support a capability to discover the MnS of the function that provides registration for
MnSs that are required to be exposed externally.

REQ-SL-EXP-FUNxx SMO should support a capability to store, query, update, and deliver information about producer
of MnSs that can be exposed externally.

Editor’s note: The above requirements are intentionally not yet numbered and will be numbered if/when they become
normative requirements.

D.1.4.2 Discovery of Producers of MnS Related to RAN Slicing for External Exposure

D.1.4.2.1 Background and Goal of the Use Case

In order to expose capabilities of MnS related to RAN slicing externally SMO external exposure functions need to be
aware of producer of these services in SMO. This can be achieved by discovering producers of respective MnSs by
querying SMOF responsible for service registration and management and providing common registration service to
MnSs).

NOTE: SMOF responsible for service registration and management is not yet formally defined in SMO architecture.

D.1.4.2.2 Description
Pre-condition

• There are existing trust relations between SMO external exposure function and SMOF responsible for service
registration and management.

• SMO external exposure function can reach SMOF responsible for service registration and management.

• SMOF playing the role of a producer of MnS related to RAN slicing registered its MnSs in SMOF responsible
for service registration and management.

• SMO external exposure function determines MnSs that are required to be exposed externally.

• SMO external exposure function does not have information of the producer of MnSs that are required to be
exposed externally.

High level procedure (see figure D.1.4.2.2-1)

1. SMO external exposure function requests SMOF responsible for service registration and management to discover
a producer of specific MnSs by providing filter criteria.

2. SMOF responsible for service registration and management applies filter criteria to the existing registry records
for MnS producers.

3. SMOF responsible for service registration and management provides response with details on producers of
matching MnSs.

SMO/
SMO external exposure functions
E_NSSMS_P
Registry
Capabilities
3
No Record Record created
0

1 2
SMO Functions
producer of MnS MnS MnS service registration and
related to RAN slicing management SMOF
MnS 0 Record exists

Figure D.1.4.2.2-1: Flow of discovery of MnS related to RAN slicing for external exposure

Post-condition

SMO external exposure function has obtained the registry records for a producer of the MnSs that are required to be
exposed externally as per requested filter criteria.

D.1.4.2.3 Potential Requirements

REQ-SL-EXP-FUNxx SMO should support a capability for an authorized SMOF to discover MnSs that are required to
be exposed externally.

REQ-SL-EXP-FUNxx SMO should support a capability for an authorized SMOF to obtain information about MnSs that
are required to be exposed externally based on criteria specified by that SMOF.

Editor’s note: The above requirements are intentionally not yet numbered and will be numbered if/when they become
normative requirements.

D.1.4.3 Registration of eMnS Consumer

D.1.4.3.1 Background and Goal of the Use Case

A consumer outside the trust and administrative boundary of the SMO needs to be authenticated and authorized using the
identity data of the consumer in order to allow acess to exposed management services. Consumer identity data needs to
be registered at SMO. Traditionally, in the industry, registration is performed manually at producer side. It may also be
performed automatically. Automatic registration presumes mechanisms for secured communication, for instance,
certificate check and ecryption based on server (SMO) certificate. Registration capabilities also presume management of

records containing consumer account data including but not limited to consumer credentials, consumer roles and rights it
is authorized to.

NOTE: In case of manual registration, consumer details corresponding to the registration are created through SMO
operational procedures initiated by a human operator. By completion of registration procedures exposed management
services consumer is provided with credentials and is aware of authentication method and access rights.

D.1.4.3.2 Description
Pre-condition

• eMnS consumer can reach SMO external exposure.

• SMO function responsible for external exposure does not have consumer account data record for eMnS consumer.

High level procedure (see figure D.1.4.3.2-1)

1. eMnS consumer requests SMO external exposure services to register itself and provides information about
intended scope of management services to consume.

2. SMO external exposure services producer performs eligibility check based on provided by eMnS consumer
information and makes a descision on request approval.

3. In case of positive result, SMO external exposure services producer creates registry record for the eMnS consumer
containing data about intended and authorized management services to consume, credentials and authentication
method.

4. SMO external exposure services producer acknowledges the successful registration and provide credentials data
to eMnS. eMnS consumer may subscribe to status of SMO external exposure function or SMO external exposure
function sets pushing status heartbeat.

E_NSSMS_C
External consumer of MnS related to RAN slicing

1 4
SMO/
SMO external exposure functions
E_NSSMS_P
Eligibility check
SMO external
Registry 2 passed
Capabilities
exposure services
No Record 3 Record created
0

SMO Functions
producer of MnS MnS MnS MnS
related to RAN slicing

Figure D.1.4.3.2-1: Flow of registration of consumer of eMnS related to RAN slicing

Post-condition

SMO external exposure function has created the consumer account data record for the eMnS consumer and eMnS
consumer has received registration confirmation with required data.

D.1.4.3.3 Potential Requirements

REQ-SL-EXP-FUNxx SMO should support a capability to register a consumer of exposed management services.

REQ-SL-EXP-FUNxx SMO should support a capability to manage lifecycle of account data record (creation,
modification, deletion) of a consumer of exposed management services.

REQ-SL-EXP-FUNxx SMO should support a capability to manage credentials, related roles, and authorized access rights
of a consumer of exposed management services.

REQ-SL-EXP-FUNxx SMO should support a capability for an authorized SMOF to store, query, update, and deliver
information about consumer of exposed management services.

Editor’s note: The above requirements are intentionally not yet numbered and will be numbered if/when they become
normative requirements.

D.1.4.4 Authentication and Authorization of eMnS Consumer

D.1.4.4.1 Background and Goal of the Use Case

In order consumer of exposed management services be authenticated and authorized to consume intended scope of MnSs,
SMO external exposure functions need to support authentication and authorization processes capabilities relying on
identity and authorized rights for the eMnS consumer created during its registration.

NOTE: Authentication procedures shall comply with all the security requirements as specified in O-RAN.WG11.Security-
Protocols-Specification [24].

D.1.4.4.2 Description
Pre-condition

• There are existing trust relations between SMO external exposure functions and eMnS consumer.

• eMnS consumer can reach SMO external exposure.

• SMO function responsible for external exposure has consumer account data record for eMnS consumer including
credentials, roles, and authorized access rights.

High level procedure (see figure D.1.4.4.2-1)

1. eMnS consumer initiates authentication by providing its credentials and information on security capabilities to
SMO external exposure function.

2. SMO external exposure function selects security method and performs mutual authentication with eMnS
consumer.

3. After receiving successful authentication response eMnS consumer may request for permission to access certain
exposed management services (otherwise decision on access permission is made based on previously stored data)

4. SMO external exposure function checks access rights in registry record for eMnS consumer and sends
authorization response containg access token and scope defining allowed for eMnS consumer exposed
management services.

E_NSSMS_C
External consumer of MnS related to RAN slicing

1 2 3 4
SMO/
SMO external exposure functions
E_NSSMS_P

SMO external
Registry 4 access rights
check
Capabilities
exposure services

SMO Functions
producer of MnS MnS MnS MnS
related to RAN slicing

Figure D.1.4.4.2-1: Flow of authentication and authorization of eMnS consumer

Post-condition

SMO external exposure function has authenticated and authorized eMnS consumer to access allowed scope of exposed
management services.

D.1.4.4.3 Potential Requirements

REQ-SL-EXP-FUNxx SMO should support a capability for mutual authentication between SMO and consumer of
exposed management services.

REQ-SL-EXP-FUNxx SMO should support a capability for authorization of consumer of exposed management services.

REQ-SL-EXP-FUNxx SMO should support internal to SMO capability to create, read, update, and delete authorization
policies related to exposed management services.

Editor’s note: The above requirements are intentionally not yet numbered and will be numbered if/when they become
normative requirements.

D.1.4.5 Publishing of eMnS

D.1.4.5.1 Background and Goal of the Use Case

For an eMnS consumer to consume eMnS, the eMnS needs to be defined, created, and activated in SMO as available for
requests from outside the administrative and trust boundaries of SMO. It is also necessary to implement and apply access
constraint policies (e.g. access rights, requests rate limitations) to eMnS in accordance with the previous business
agreement between E_NSSMS_C and E_NSSMS_P.

The eMnS definition relies on the capabilities of MnSs related to RAN slicing that are registered in SMO external
exposure services. The definition includes sufficient information for eMnS consuming (e.g. public endpoint URI, version,
metadata, protocol, authentication method, resource URIs, operations and their parameters, data format).

Depending on the use case eMnS may be associated with MnS either directly or indirectly. In case of indirect association
eMnS may be an aggregation of a set of MnSs, of a subset of MnS capabilities or group of several MnS subsets.

eMnS may also be an abstraction formed by transformation to specific external data models, mapping, filtering and
enrichment for data and operations of supporting MnSs, in that case publishing may also cover how eMnS is formed.

NOTE: For the given use case direct association of eMnS to MnS is assumed.

In general, service publishing includes manual activities that may be streamlined using various DevOps automation tools
in conjunction with workflow management systems.

D.1.4.5.2 Description
Pre-condition

• Business agreement between E_NSSMS_C and E_NSSMS_P exists.

• SMO external exposure function uses account information of eMnS consumer to authenticate and authorize it.

• SMO external exposure function has information about scope of management services eMnS consumer intends
to consume.

• SMO external exposure function has the registry records for producers of MnS related to RAN slicing that may
be exposed externally.

High level procedure

1. SMO administrator gets a task to make a new eMnS available for the E_NSSMS_C.

2. SMO administrator using various DevOps automation tools defines and create eMnS deployment package within
SMO external exposure functions.

3. SMO administrator following business agreement information, information in eMnS consumer account data
record and eMnS consumer intended scope of consumed management services defines and stores within SMO
external exposure function access constraint policies to be applied to the eMnS consumer for the newly created
eMnS.

4. SMO administrator deploys and activates an instance of eMnS for it to be available for for the requests from the
outside the administrative and trust boundaries of SMO and task of eMnS publishing is reported as completed.

Post-condition

• eMnS deployment package is prepared and created within SMO external exposure functions.

• Access constraint policies to be applied to the eMnS consumer for the newly created eMnS are prepared and
created within SMO external exposure functions.

• An instance of eMnS based on eMnS definition package is deployed and activated within SMO and is available
for the consumption by the eMnS consumer from the outside of the administrative and trust boundaries of SMO.

NOTE: Depending on the progress of De-Coupled SMO or specific implementation need, these capabilities may reside
in one of the SMO functions or realized with support of rApps.

D.1.4.5.3 Potential Requirements

REQ-SL-EXP-FUNxx SMO should support a capability to manage lifecycle (creation, modification, deletion) of the
exposed management service deployment package that includes sufficient information for consuming that exposed
management service (e.g. including but not limited to public endpoint URI, version, metadata, protocol, authentication
method, resource URIs, operations and their parameters, data format).

REQ-SL-EXP-FUNxx SMO should support a capability to manage lifecycle of the access constraint policies (access
rights, requests rate limits and other) to be applied to the exposed management service consumer for the exposed
management service consumption.

REQ-SL-EXP-FUNxx SMO should support a capability to manage lifecycle (creation, modification, deletion) of the
exposed management service instance.

Editor’s note: The above requirements are intentionally not yet numbered and will be numbered if/when they become
normative requirements.

D.1.4.6 Discovery of eMnS

D.1.4.6.1 Background and Goal of the Use Case

For the consumer of exposed management services to be aware of eMnS that are available for consumption, the external
exposure function of the SMO needs to be able to support the capability and process of eMnS discovery. For eMnS to be
discovered it needs first to be published. Discovery is provided to the authorized consumers of exposed management
services.

Upon discovery, the consumer of exposed management services obtains information on producers and available instances
of eMnSs, including service access information for each producer. It may also contain specific instructions on how
requests data are expected to be secured and formatted.

A consumer of exposed management may discover available eMnS with a specific query containing filter criteria to SMO
external exposure function or by getting a notification from SMO external exposure function on available eMnS matching
notification subscription criteria.

NOTE: Access to discovery capabilities of SMO may be in itself a subject for the access constraint policies.

D.1.4.6.2 Description
Pre-condition

• There are existing trust relations between SMO external exposure function and eMnS consumer.

• eMnS consumer can reach SMO external exposure.

• SMO external exposure function has consumer account data record for eMnS consumer including credentials,
roles, and authorized access rights.

• eMnS instances are published.

• eMnS consumer does not have information about published eMnS instances or deems the previously stored
information needs to be updated.

High level procedure (see figure D.1.4.6.2-1)

1. eMnS consumer requests SMO external exposure function to discover a producer of specific eMnSs by providing
filter criteria.

2. SMO external exposure function applies filter criteria to the existing instances of eMnSs and its producers.

3. SMO external exposure function provides a response with information on producers of matching eMnSs and
available instances of eMnSs.

E_NSSMS_C
External consumer of MnS related to RAN slicing
No Record/ Record created /
0 Obsolete updated

1 3
SMO/
SMO external exposure functions
E_NSSMS_P

SMO external
Registry 2
Capabilities
exposure services
0 Record exists

SMO Functions
producer of MnS MnS MnS MnS
related to RAN slicing

Figure D.1.4.6.2-1: Flow of discovery of eMnS by eMnS consumer

Post-condition

eMnS consumer has an updated information about published eMnS instances it is able to consume.

D.1.4.6.3 Potential Requirements

REQ-SL-EXP-FUNxx SMO should support a capability for an authorized consumer of exposed management services to
discover published exposed management services.

REQ-SL-EXP-FUNxx SMO should support a capability for an authorized consumer of exposed management services to
obtain information about published exposed management services based on criteria specified by that consumer of exposed
management services.

REQ-SL-EXP-FUNxx SMO may support capability for an authorized consumer of exposed management services to
subscribe to discovery events, get notifications (for example: update, removal, or creation of exposed management service
instance in the scope of subscription) and to request health check.

Editor’s note: The above requirements are intentionally not yet numbered and will be numbered if/when they become
normative requirements.

Annex (informative): Revision history

Date Revision Description

2023.12.07 12.00.01 Removed v12.00 history

Initial version towards v13.00, starting with v12.00.01 per O-RAN specification revision
numbering process.

Addition of CR:

- JNPR-2023.12.05-WG1-CR-0048-O-RAN-Slicing-Arch-ODR-Clauses-
Text_Modifications-Editorial_Corrections-v03

2024.01.29 12.00.02 Addition of CR:

- JNPR-2023.12.27-WG1-CR-0049-O-RAN-Slicing-Arch-ODR-Capital_Letters-
Editorial_Changes-v01
2024.03.22 12.00.03 Addition of CR:

- NOK.AO-2024.03.12-WG1-CR-0007-ReservationFeasibilityCheck_v01.01

2024.03.22 12.00.04 Clean version for WG1 approval

2024.03.31 12.00.05 WG1 review comments are addressed, and approval is completed.

2024.03.31 12.00.06 All changes accepted, clean version.

2024.03.31 13.00 Final version ready for TSC approval and publication.

Annex (informative): History

Date Revision Description

2023.11.16 12.00 v12.00 publication

2023.07.30 11.00 v11.00 publication

2023.03.24 10.00 v10.00 publication

2022.11.18 09.00 v09.00 publication

2022.08.01 08.00 v08.00 publication

2022.04.04 07.00 v07.00 publication

2021.11.23 06.00 v06.00 publication

2021.07.19 05.00 v05.00 publication

2021.03.13 04.00 v04.00 publication

2020.11.13 03.00 v03.00 publication

2020.07.16 02.00 v02.00 publication

2020.03.11 01.00 v01.00 publication

Common questions

SMO external exposure functions serve to consolidate SMO services providing capabilities to support the exposure of management services for external consumption. These functions include service registration, authentication and authorization of eMnS consumers, and the publication of management services for external exposure, effectively allowing external entities to discover and consume SMO management services .

NSSMS_P manages the lifecycle of VNFs by leveraging knowledge of O-Cloud M&O to manage VNF instantiation, configuration, and interconnection. This involves associating service responses from O-Cloud M&O with the respective O-NSSI and using NFMS_P provisioning services for configuring the NSSI constituents, thereby ensuring each network function supports the overall network slice requirements .

The SMO function registry is significant as it holds records of managed network services related to RAN slicing. It ensures these services can be authenticated, authorized, and accessed by the correct eMnS consumers, facilitating secure collaboration and service consumption across multiple network operators .

Key steps include: notifying other NSSMS_P(s) about the discontinuation of constituent NSSIs, sending service termination requests to O-Cloud M&O for removal of non-shared virtual O-RAN network functions, and notifying Non-RT RIC about the termination. The post-termination condition is that O-NSSI is terminated or disassociated, with Non-RT RIC informed of the changes .

It is critical for NSSMS_P to notify other NSSMS_Ps in scenarios of constituent NSSI management because constituent NSSIs may be managed by different NSSMS_Ps. Communication and coordination are necessary to trigger the creation or modification of these NSSIs, ensuring the requirements of the O-NSSI are satisfied effectively across different providers .

The registration of eMnS consumers involves creating a registry record containing data about the consumer's intended management services, credentials, and authentication methods. The SMO external exposure services producer performs eligibility checks based on the provided information before approving the registration and supplying credentials, ensuring secure and authorized access to management services .

The primary goal of creating a new O-RAN network slice subnet instance (O-NSSI) is to satisfy the RAN slice subnet related requirements, by either creating a new O-NSSI or using an existing one, according to the conditions specified in 3GPP TS 28.531 [4], clause 5.1.2 .

Indirect association involves aggregating multiple MnS capabilities or subsets, creating eMnS as an abstract layer. This abstraction is achieved through transformation to specific external data models, filtering, and enrichment of data and operations. This requires detailed definition and execution within the SMO, involving state-of-the-art automation tools and exhaustive coordination, ensuring flexibility and scalability in delivering tailored management service solutions .

NSSMS_P determines the feasibility of an O-RAN slice subnet instance creation request by checking the received network slice subnet related requirements. This involves assessing both the viability of creating a new O-NSSI and the possibility of using an existing O-NSSI to meet the requirements .

Business agreements between E_NSSMS_C and E_NSSMS_P are crucial as they define the scope and limitations of eMnS capabilities exposed by SMO. These agreements guide the SMO administrator in defining and storing access constraint policies for eMnS consumers, ensuring that only authorized operations and data are exposed according to the agreed terms .

A Comprehensive Tutorial and Survey of O-RAN Exploring Slicing-Aware Architecture Deployment Options Use Cases and Challenges
No ratings yet
A Comprehensive Tutorial and Survey of O-RAN Exploring Slicing-Aware Architecture Deployment Options Use Cases and Challenges
40 pages
O-RAN WG3 E2GAP-R003-v04 01
No ratings yet
O-RAN WG3 E2GAP-R003-v04 01
49 pages
O RAN - WG1.Use Cases Detailed Specification R003 v14.00
No ratings yet
O RAN - WG1.Use Cases Detailed Specification R003 v14.00
243 pages
What Is A DHCP Relay Agent (En)
No ratings yet
What Is A DHCP Relay Agent (En)
3 pages
Chapter 2-Data Communications
No ratings yet
Chapter 2-Data Communications
36 pages
O-RAN With ML in Ns-3
No ratings yet
O-RAN With ML in Ns-3
9 pages
Mod 4
No ratings yet
Mod 4
70 pages
Chapter 9: Multiarea OSPF: CCNA Routing and Switching Scaling Networks v6.0
No ratings yet
Chapter 9: Multiarea OSPF: CCNA Routing and Switching Scaling Networks v6.0
31 pages
Netmanias.2014.06.18.Part 2. Packet Forwarding by IP Router (En)
No ratings yet
Netmanias.2014.06.18.Part 2. Packet Forwarding by IP Router (En)
8 pages
E2E Network Slicing Overview
No ratings yet
E2E Network Slicing Overview
35 pages
Cloud 02
No ratings yet
Cloud 02
37 pages
Review of Routing Protocols in Networks
No ratings yet
Review of Routing Protocols in Networks
11 pages
Self Organising Networks (SON) : Phaniteja K RNO Huawei
No ratings yet
Self Organising Networks (SON) : Phaniteja K RNO Huawei
8 pages
Ghana Internet Exchange Impact
No ratings yet
Ghana Internet Exchange Impact
20 pages
Nso 25
No ratings yet
Nso 25
54 pages
Tshoot Chapter1 Solution
40% (5)
Tshoot Chapter1 Solution
7 pages
Using Zero Touch Provisioning
No ratings yet
Using Zero Touch Provisioning
6 pages
Cloud 01
No ratings yet
Cloud 01
32 pages
Burp Scanner Report
No ratings yet
Burp Scanner Report
3 pages
5G Architecture White Paper
No ratings yet
5G Architecture White Paper
113 pages
Slicing 5G Networks - An Architectural Survey - in - Wiley 5G Ref Online
No ratings yet
Slicing 5G Networks - An Architectural Survey - in - Wiley 5G Ref Online
42 pages
Cloud Migration Strategies and Planning
No ratings yet
Cloud Migration Strategies and Planning
58 pages
Wi-Fi 6: High Performance, Next Generation Wi-Fi
No ratings yet
Wi-Fi 6: High Performance, Next Generation Wi-Fi
9 pages
5G Network in Telecommunications
No ratings yet
5G Network in Telecommunications
9 pages
P.I.Son: P.I.SON Is A Centralized Automated Network Optimization Solution. Automated Configuration Management and
No ratings yet
P.I.Son: P.I.SON Is A Centralized Automated Network Optimization Solution. Automated Configuration Management and
2 pages
RAN20.0 Feature List 01 20170710
No ratings yet
RAN20.0 Feature List 01 20170710
15 pages
FortiGate Routing Guide
No ratings yet
FortiGate Routing Guide
26 pages
BSC6900 GSM V900R011C00SPC720 Parameter Reference
No ratings yet
BSC6900 GSM V900R011C00SPC720 Parameter Reference
4,299 pages
ONAP Beijing Architecture TSC v2.0.3
No ratings yet
ONAP Beijing Architecture TSC v2.0.3
54 pages
QoS Based Traffic Engineering in Software Defined Networking
No ratings yet
QoS Based Traffic Engineering in Software Defined Networking
144 pages
Hidden Costs of Untrusted 5G Vendors in France
No ratings yet
Hidden Costs of Untrusted 5G Vendors in France
46 pages
Mobile Backhaul Options PDF
100% (1)
Mobile Backhaul Options PDF
86 pages
On The RAN: The State of Next Generation RAN Transformations
No ratings yet
On The RAN: The State of Next Generation RAN Transformations
22 pages
Sustainable Mobility in 6G Networks
No ratings yet
Sustainable Mobility in 6G Networks
14 pages
GNSS Survey Analysis at Nile University
No ratings yet
GNSS Survey Analysis at Nile University
16 pages
PTCL Internship Report: Networking & Services
100% (2)
PTCL Internship Report: Networking & Services
9 pages
Nokia 2G Counters
No ratings yet
Nokia 2G Counters
1,609 pages
6G Fundamentals
No ratings yet
6G Fundamentals
45 pages
FGT1 06 Basic IPsec VPN V2 PDF
No ratings yet
FGT1 06 Basic IPsec VPN V2 PDF
32 pages
n10-008-08 - Explaining Network Topologies and Types
No ratings yet
n10-008-08 - Explaining Network Topologies and Types
27 pages
Mod5 Review
No ratings yet
Mod5 Review
28 pages
Internetworking or Network Layer
No ratings yet
Internetworking or Network Layer
94 pages
TV Policies in Asia
No ratings yet
TV Policies in Asia
36 pages
Open RAN Overview by Moniem Tech
100% (1)
Open RAN Overview by Moniem Tech
11 pages
SDN/NFV in 5G Networks Tutorial
No ratings yet
SDN/NFV in 5G Networks Tutorial
124 pages
Notes 5G
No ratings yet
Notes 5G
27 pages
Edge Computing in 5G Networks
No ratings yet
Edge Computing in 5G Networks
16 pages
Rijal Almaa Microwave Project Plan
No ratings yet
Rijal Almaa Microwave Project Plan
61 pages
Autonomous Networks
No ratings yet
Autonomous Networks
37 pages
Standardization Progress of SON in 3GPP
No ratings yet
Standardization Progress of SON in 3GPP
29 pages
Sfps and Data Cables: Datasheet
No ratings yet
Sfps and Data Cables: Datasheet
6 pages
5g and Smart Manufacturing 190220100244
No ratings yet
5g and Smart Manufacturing 190220100244
12 pages
O RAN - WG1.Slicing Architecture R003 v10.00
No ratings yet
O RAN - WG1.Slicing Architecture R003 v10.00
70 pages
O RAN - wg1.TS - Slicing Architecture R004 v14.00
No ratings yet
O RAN - wg1.TS - Slicing Architecture R004 v14.00
82 pages
O RAN - Wg1.slicing Architecture v05.00
No ratings yet
O RAN - Wg1.slicing Architecture v05.00
53 pages
O RAN - Wg1.slicing Architecture v07.00
No ratings yet
O RAN - Wg1.slicing Architecture v07.00
61 pages
O Ran - wg10.Ts - Oam Architecture r004 v14.00
No ratings yet
O Ran - wg10.Ts - Oam Architecture r004 v14.00
86 pages
O RAN - Wg1.o RAN Architecture Description v02.00
No ratings yet
O RAN - Wg1.o RAN Architecture Description v02.00
28 pages
O RAN - Wg1.network Energy Savings Technical Report R003 v02.00
No ratings yet
O RAN - Wg1.network Energy Savings Technical Report R003 v02.00
105 pages
O-RAN - WG1.OAD-R003-v10.00: O-RAN Work Group 1 (Use Cases and Overall Architecture) O-RAN Architecture Description
No ratings yet
O-RAN - WG1.OAD-R003-v10.00: O-RAN Work Group 1 (Use Cases and Overall Architecture) O-RAN Architecture Description
41 pages
Process Control Interview Questions and Expert Answers For Experienced Candidates
No ratings yet
Process Control Interview Questions and Expert Answers For Experienced Candidates
10 pages
BRD Finance - SAMPLE
No ratings yet
BRD Finance - SAMPLE
11 pages
Citra Log - Txt.old
No ratings yet
Citra Log - Txt.old
6 pages
Coderz - Robotic Web Based Software
No ratings yet
Coderz - Robotic Web Based Software
8 pages
Wireless Mobile Charger Project Report
No ratings yet
Wireless Mobile Charger Project Report
10 pages
DSE4510 MKII DSE4520 MKII Installation Instructions
100% (1)
DSE4510 MKII DSE4520 MKII Installation Instructions
2 pages
IOT Module 1 Ch1 PG Maya Final
No ratings yet
IOT Module 1 Ch1 PG Maya Final
74 pages
Pexip Infinity VMware Installation Guide V33.a
No ratings yet
Pexip Infinity VMware Installation Guide V33.a
22 pages
First Year Diploma ICT Project For Submission
No ratings yet
First Year Diploma ICT Project For Submission
4 pages
Manual Vissim 410
100% (1)
Manual Vissim 410
310 pages
Ecommerce Docs
No ratings yet
Ecommerce Docs
6 pages
Motos CDI
100% (2)
Motos CDI
145 pages
Antivirus Adv & Disadvantage
No ratings yet
Antivirus Adv & Disadvantage
11 pages
SSV Report Presentation
100% (1)
SSV Report Presentation
17 pages
18 - Decrypting Innovation - A Practical Approach - Francesco Fazio - Doblin
100% (1)
18 - Decrypting Innovation - A Practical Approach - Francesco Fazio - Doblin
61 pages
Ethics and AI - Question Bank For IA1
No ratings yet
Ethics and AI - Question Bank For IA1
4 pages
Zara Tahir
No ratings yet
Zara Tahir
1 page
Getting Started With Pcloud PDF
No ratings yet
Getting Started With Pcloud PDF
17 pages
NIST SP 800-161r1-Draft
No ratings yet
NIST SP 800-161r1-Draft
278 pages
Inventory Management User Manual ECC 6.0
No ratings yet
Inventory Management User Manual ECC 6.0
50 pages
Neo-Evolutionism in Anthropology
No ratings yet
Neo-Evolutionism in Anthropology
13 pages
An Introduction About IC Reball
No ratings yet
An Introduction About IC Reball
9 pages
Hydrostatic Motor (Eaton) - (S - N 514424999 & Below, 514524999 & Below, 514624999 & Below) - 863
No ratings yet
Hydrostatic Motor (Eaton) - (S - N 514424999 & Below, 514524999 & Below, 514624999 & Below) - 863
3 pages
Power Dissipation in Clock Distribution
No ratings yet
Power Dissipation in Clock Distribution
66 pages
DP 100 Datasheet
No ratings yet
DP 100 Datasheet
28 pages
Manual 41-752 - GB
No ratings yet
Manual 41-752 - GB
4 pages
CV - Saket
No ratings yet
CV - Saket
1 page
Ericsson Mobile Phones Overview
No ratings yet
Ericsson Mobile Phones Overview
57 pages
4.1 Introduction To Object-Oriented Method
No ratings yet
4.1 Introduction To Object-Oriented Method
4 pages
A Comparative Analysis of Strategies and
100% (3)
A Comparative Analysis of Strategies and
15 pages