0% found this document useful (0 votes)

164 views89 pages

O RAN - Wg1.use Cases Detailed Specification v08.00

Uploaded by

surajk66

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)

164 views89 pages

O RAN - Wg1.use Cases Detailed Specification v08.00

Uploaded by

surajk66

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

You are on page 1/ 89

O-RAN.WG1.Use-Cases-Detailed-Specification-v08.

00
Technical Specification

O-RAN Working Group 1

Use Cases Detailed Specification

This is a re-published version of the attached final specification.

For this re-published version, the prior versions of the IPR Policy will apply, except that the previous
requirement for Adopters (as defined in the earlier IPR Policy) to agree to an O-RAN Adopter License
Agreement to access and use Final Specifications shall no longer apply or be required for these Final
Specifications after 1st July 2022.

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 on this site for your personal use, or copy
the material on this site 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.

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

Your use is subject to the copyright statement on the cover page of this specification.
O-RAN.WG1.Use-Cases-Detailed-Specification-v08.00
Technical Specification

O-RAN Working Group 1

Use Cases Detailed Specification

Copyright © 2022 by O-RAN ALLIANCE e.V.

By using, accessing or downloading any part of this O-RAN specification document, including by copying, saving,
distributing, displaying or preparing derivatives of, you agree to be and are bound to the terms of the O-RAN
Adopter License Agreement contained in Annex ZZZ of this specification. All other rights reserved.

O-RAN ALLIANCE e.V.

Buschkauler Weg 27, 53347 Alfter, Germany
Register of Associations, Bonn VR 11238
VAT ID DE321720189

© 2022 O-RAN ALLIANCE e.V. All Rights Reserved

O-RAN.WG1.Use-Cases-Detailed-Specification-v08.00

1 Revision History

Date Revision Author Description

2019.10.17 01.00 Arda Akman v01.00 publication
(Netsia)
2020.03.11 02.00 Arda Akman v02.00 publication
(Netsia)
2020.07.16 03.00 Arda Akman v03.00 publication
(Netsia)
2020.11.13 04.00 Arda Akman v04.00 publication
(Netsia)
2021.03.13 05.00 Arda Akman v05.00 publication
(Juniper
Networks)
2021.07.19 06.00 Arda Akman v06.00 publication
(Juniper
Networks)
2021.11.23 07.00 Arda Akman v07.00 publication
(Juniper
Networks)
2022.03.27 07.00.06 Arda Akman Removed v07.00 history
(Juniper
Adopted new spec revision numbering per O-RAN Work Procedures
Networks)
Initial version towards v08.00, starting with v07.00.06 per new revision
numbering
2022.03.27 07.00.07 Arda Akman Addition of CR:
(Juniper - CMCC-2022.1.13-WG1-CR-0001-
Networks) UseCasesDetailedSpecification-QOE-Optimization-v3.0
2022.03.27 07.00.08 Arda Akman Addition of CR:
(Juniper - CMCC-2022.03.10-WG1-CR-0001-
Networks) UseCasesDetailedSpecification-Local-Indoor-Positioning-in-
RAN-v1
2022.03.27 07.00.09 Arda Akman Addition of placeholders for new use cases added to Use Case Analysis
(Juniper Rreport
Networks) - Use Case 20: Lower Layer Split Multi Node Support (Shared
O-RU)
- Use Case 21: Energy Saving
2022.03.27 07.00.10 Arda Akman Changes accepted from v07.00.09
(Juniper
Baseline for WG1 approval
Networks)
2022.04.04 08.00 Arda Akman Spec renamed to v08.00 for publication
(Juniper
Networks)
2

________________________________________________________________________________________________
Copyright © 2022 by the O-RAN ALLIANCE e.V. Your use is subject to the terms of the O-RAN Adopter License Agreement in Annex ZZZ 2
O-RAN.WG1.Use-Cases-Detailed-Specification-v08.00

1 Contents
2 Revision History ................................................................................................................................................. 2
3 Chapter 1 Introduction ........................................................................................................................................ 5
4 1.1 Scope ................................................................................................................................................................. 5
5 1.2 References.......................................................................................................................................................... 5
6 1.3 Definitions and Abbreviations ........................................................................................................................... 6
7 1.3.1 Definitions .................................................................................................................................................... 6
8 1.3.2 Abbreviations ............................................................................................................................................... 7
9 Chapter 2 Objective ............................................................................................................................................ 9
10 Chapter 3 Use cases .......................................................................................................................................... 10
11 3.1 Use case 1: Context-Based Dynamic HO Management for V2X .................................................................... 10
12 3.1.1 Background and goal of the use case ......................................................................................................... 10
13 3.1.2 Entities/resources involved in the use case ................................................................................................ 10
14 3.1.3 Solutions..................................................................................................................................................... 11
15 3.1.4 Required data ............................................................................................................................................. 12
16 3.2 Use case 2: Flight Path Based Dynamic UAV Radio Resource Allocation ..................................................... 12
17 3.2.1 Background and goal of the use case ......................................................................................................... 13
18 3.2.2 Entities/resources involved in the use case ................................................................................................ 14
19 3.2.3 Solutions..................................................................................................................................................... 15
20 3.2.4 Required data ............................................................................................................................................. 16
21 3.3 Use case 3: Radio Resource Allocation for UAV Application Scenario ......................................................... 16
22 3.3.1 Background and goal of the use case ......................................................................................................... 16
23 3.3.2 Entities/resources involved in the use case ................................................................................................ 18
24 3.3.3 Solutions..................................................................................................................................................... 19
25 3.3.4 Required data ............................................................................................................................................. 19
26 3.4 Use case 4: QoE Optimization ......................................................................................................................... 20
27 3.4.1 Background and goal of the use case ......................................................................................................... 20
28 3.4.2 Entities/resources involved in the use case ................................................................................................ 20
29 3.4.3 Solutions..................................................................................................................................................... 21
30 3.4.4 Required data ............................................................................................................................................. 25
31 3.5 Use case 5: Traffic Steering ............................................................................................................................. 26
32 3.5.1 Background and goal of the use case ......................................................................................................... 26
33 3.5.2 Entities/resources involved in the use case ................................................................................................ 27
34 3.5.3 Solutions..................................................................................................................................................... 28
35 3.5.4 Required data ............................................................................................................................................. 29
36 3.6 Use case 6: Massive MIMO Beamforming Optimization ................................................................................ 29
37 3.6.1 Background and goal of the use case ......................................................................................................... 30
38 3.6.2 Entities/resources involved in the use case ................................................................................................ 30
39 3.6.3 Solutions..................................................................................................................................................... 32
40 3.6.4 Required data ............................................................................................................................................. 36
41 3.7 Use case 7: RAN Sharing ................................................................................................................................ 37
42 3.7.1 Background and goal of the use case ......................................................................................................... 37
43 3.7.2 Entities/resources involved in the use case ................................................................................................ 38
44 3.7.3 Solutions..................................................................................................................................................... 39
45 3.7.4 Required data ............................................................................................................................................. 40
46 3.8 Use case 8: QoS Based Resource Optimization ............................................................................................... 41
47 3.8.1 Background and goal of the use case ......................................................................................................... 41
48 3.8.2 Entities/resources involved in the use case ................................................................................................ 42

________________________________________________________________________________________________
Copyright © 2022 by the O-RAN ALLIANCE e.V. Your use is subject to the terms of the O-RAN Adopter License Agreement in Annex ZZZ 3
O-RAN.WG1.Use-Cases-Detailed-Specification-v08.00

1 3.8.3 Solutions..................................................................................................................................................... 43
2 3.8.4 Required data ............................................................................................................................................. 44
3 3.9 Use case 9: RAN Slice SLA Assurance ........................................................................................................... 44
4 3.9.1 Background and goal of the use case ......................................................................................................... 45
5 3.9.2 Entities/resources involved in the use case ................................................................................................ 45
6 3.9.3 Solutions..................................................................................................................................................... 46
7 3.9.4 Required data ............................................................................................................................................. 51
8 3.10 Use case 10: Multi-vendor Slices .................................................................................................................... 52
9 3.10.1 Background and goal of the use case ......................................................................................................... 52
10 3.10.2 Entities/resources involved in the use case ................................................................................................ 53
11 3.10.3 Solutions..................................................................................................................................................... 53
12 3.10.4 Required data ............................................................................................................................................. 58
13 3.11 Use case 11: Dynamic Spectrum Sharing ........................................................................................................ 58
14 3.11.1 Background and goal of the use case ......................................................................................................... 59
15 3.11.2 Entities/resources involved in the use case ................................................................................................ 61
16 3.11.3 Solutions..................................................................................................................................................... 62
17 3.11.4 Required data ............................................................................................................................................. 63
18 3.12 Use case 12: NSSI Resource Allocation Optimization .................................................................................... 64
19 3.12.1 Background and goal of the use case ......................................................................................................... 64
20 3.12.2 Entities/resources involved in the use case ................................................................................................ 66
21 3.12.3 Solutions..................................................................................................................................................... 68
22 3.12.4 Required data ............................................................................................................................................. 69
23 3.13 Use case 13: Local Indoor Positioning in RAN ............................................................................................... 70
24 3.13.1 Background and goal of the use case ......................................................................................................... 70
25 3.13.2 Entities/resources involved in the use case ................................................................................................ 70
26 3.13.3 Solutions..................................................................................................................................................... 71
27 3.13.4 Required data ............................................................................................................................................. 73
28 3.13.5 RAN Analytics Information ....................................................................................................................... 73
29 3.14 Use case 14: Massive SU/MU-MIMO Grouping Optimization ....................................................................... 73
30 3.15 Use case 15: O-RAN Signalling Storm Protection .......................................................................................... 73
31 3.15.1 Background and goal of the use case ......................................................................................................... 73
32 3.15.2 Entities/resources involved in the use case ................................................................................................ 74
33 3.15.3 Solutions..................................................................................................................................................... 75
34 3.15.4 Required data ............................................................................................................................................. 80
35 3.16 Use case 16: Congestion Prediction and Management .................................................................................... 80
36 3.17 Use case 17: Industrial IoT Optimization ........................................................................................................ 81
37 3.18 Use case 18: BBU Pooling to achieve RAN Elasticity .................................................................................... 81
38 3.19 Use case 19: Integrated SON Function ............................................................................................................ 81
39 3.20 Use case 19: Lower Layer Split Multi Node Support ...................................................................................... 81
40 3.21 Use case 21: Energy Saving ............................................................................................................................. 81
41 Annex A (informative): Additional Information .............................................................................................. 82
42 A.1 Traffic Steering use case A1 interface usage example ..................................................................................... 82
43 Annex ZZZ O-RAN Adopter License Agreement ........................................................................................... 84

________________________________________________________________________________________________
Copyright © 2022 by the O-RAN ALLIANCE e.V. Your use is subject to the terms of the O-RAN Adopter License Agreement in Annex ZZZ 4
O-RAN.WG1.Use-Cases-Detailed-Specification-v08.00

1 Chapter 1 Introduction

2 1.1 Scope
3 This Technical Specification has been produced by O-RAN Alliance.
4 The contents of the present document are subject to continuing work within O-RAN WG1 and may change following
5 formal O-RAN approval. In the event that O-RAN Alliance decides to modify the contents of the present document, it
6 will be re-released by O-RAN Alliance with an identifying change of release date and an increase in version number as
7 follows:
8 Release x.y.z
9 where:
10 x the first digit is incremented for all changes of substance, i.e. technical enhancements, corrections, updates,
11 etc. (the initial approved document will have x=01).
12 y the second digit is incremented when editorial only changes have been incorporated in the document.
13 z the third digit included only in working versions of the document indicating incremental changes during the
14 editing process.
15 The current document describes the top level use cases as defined by O-RAN WG1 UCTG (Use Case Task Group). For
16 each use case, the document describes the motivation, resources, steps involved, and the data requirements. These top
17 level use cases are further detailed in relevant WGs along with the requirements for O-RAN components and their
18 interfaces.

19 1.2 References
20 The following documents contain provisions which, through reference in this text, constitute provisions of the present
21 document.
22 - References are either specific (identified by date of publication, edition number, version number, etc.) or
23 non-specific.
24 - For a specific reference, subsequent revisions do not apply.
25 - For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including
26 a GSM document), a non-specific reference implicitly refers to the latest version of that document in Release 16.
27 [1] 3GPP TR 21.905: “Vocabulary for 3GPP Specifications”

28 [2] 3GPP TS 22.261: “Service requirements for the 5G system; Stage 1”, Release 16, March 2020

29 [3] 3GPP TS 23.501: “System Architecture for the 5G System (5GS); Stage 2”, Release 16, March 2020

30 [4] 3GPP TS 28.530: “Management and orchestration; Concepts, use cases and requirements”, Release 16,
31 January 2020

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

34 [6] 3GPP TS 28.552: “3rd Generation Partnership Project; Technical Specification Group Services and
35 System Aspects; Management and orchestration; 5G performance measurements”, Release 16, March
36 2020

________________________________________________________________________________________________
Copyright © 2022 by the O-RAN ALLIANCE e.V. Your use is subject to the terms of the O-RAN Adopter License Agreement in Annex ZZZ 5
O-RAN.WG1.Use-Cases-Detailed-Specification-v08.00

1 [7] 3GPP TS 28.554: “3rd Generation Partnership Project; Technical Specification Group Services and
2 System Aspects; Management and orchestration; 5G end to end Key Performance Indicators (KPI)”,
3 Release 16, March 2020

4 [8] 3GPP TS 28.622: “Telecommunication management; Generic Network Resource Model (NRM)
5 Integration Reference Point (IRP); Information Service (IS)” Release 16, June 2021

6 [9] 3GPP TS 32.404: “Telecommunication management; Performance Management (PM); Performance

7 measurements; Definitions and template”, Release 16, July 2020

8 [10] 3GPP TS 37.340 "E-UTRA and NR; Multi-connectivity", Release 16, April 2020

9 [11] 3GPP TS 38.211: "Physical channels and modulation", Release 15, March 2019

10 [12] 3GPP TS 38.213: "Physical layer procedures for control ", Release 15, March 2019
11 [13] 3GPP TR 38.889 "Study on NR-based access to unlicensed spectrum", Release 16, December 2018
12 [14] ETSI EN 302 637-2: “Intelligent Transport Systems (ITS); Vehicular Communications; Basic Set of
13 Applications; Part 2: Specification of Cooperative Awareness Basic Service”, Release 1, November
14 2010
15 [15] ETSI EN 302 637-3: “Intelligent Transport Systems (ITS); Vehicular Communications; Basic Set of
16 Applications; Part 3: Specifications of Decentralized Environmental Notification Basic Service”,
17 Release 1, November 2014

18 [16] ETSI TS 102 637-3: “Intelligent Transport Systems (ITS); Vehicular Communications; Basic Set of
19 Applications; Part 3: Specifications of Decentralized Environmental Notification Basic Service”,
20 Release 1, November 2010
21 [17] GSMA NG.116: “Generic Network Slice Template”, Version 2.0, October 2019

22 1.3 Definitions and Abbreviations

23 1.3.1 Definitions
24 For the purposes of the present document, the terms and definitions given in 3GPP TR 21.905 [1] and the following apply.
25 A term defined in the present document takes precedence over the definition of the same term, if any, in 3GPP TR 21.905
26 [1].
27 A1: Interface between non-RT RIC and Near-RT RIC to enable policy-driven guidance of Near-RT RIC
28 applications/functions, and support AI/ML workflow.
29 A1 policy: Type of declarative policies expressed using formal statements that enable the non-RT RIC function in the
30 SMO to guide the near-RT RIC function, and hence the RAN, towards better fulfilment of the RAN intent.

31 A1 Enrichment information: Information utilized by near-RT RIC that is collected or derived at SMO/non-RT RIC
32 either from non-network data sources or from network functions themselves.

33 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-
34 DUs.
35 E2 Node: a logical node terminating E2 interface. In this version of the specification, O-RAN nodes terminating E2
36 interface are:

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

________________________________________________________________________________________________
Copyright © 2022 by the O-RAN ALLIANCE e.V. Your use is subject to the terms of the O-RAN Adopter License Agreement in Annex ZZZ 6
O-RAN.WG1.Use-Cases-Detailed-Specification-v08.00

1 - for E-UTRA access: O-eNB.

2 FCAPS: Fault, Configuration, Accounting, Performance, Security.
3 Intents: A declarative policy to steer or guide the behavior of RAN functions, allowing the RAN function to calculate the
4 optimal result to achieve stated objective.
5 Near-RT RIC: O-RAN near-real-time RAN Intelligent Controller: a logical function that enables near-real-time control
6 and optimization of RAN elements and resources via fine-grained data collection and actions over E2 interface.
7 Non-RT RIC: O-RAN non-real-time RAN Intelligent Controller: a logical function that enables non-real-time control
8 and optimization of RAN elements and resources, AI/ML workflow including model training and updates, and policy-
9 based guidance of applications/features in near-RT RIC.
10 O-CU: O-RAN Central Unit: a logical node hosting O-CU-CP and O-CU-UP
11 O-CU-CP: O-RAN Central Unit – Control Plane: a logical node hosting the RRC and the control plane part of the PDCP
12 protocol.
13 O-CU-UP: O-RAN Central Unit – User Plane: a logical node hosting the user plane part of the PDCP protocol and the
14 SDAP protocol.
15 O-DU: O-RAN Distributed Unit: a logical node hosting RLC/MAC/High-PHY layers based on a lower layer functional
16 split.
17 O-RU: O-RAN Radio Unit: a logical node hosting Low-PHY layer and RF processing based on a lower layer functional
18 split. This is similar to 3GPP’s “TRP” or “RRH” but more specific in including the Low-PHY layer (FFT/iFFT, PRACH
19 extraction).
20 O1: Interface between management entities (SMO/EMS/MANO) and O-RAN managed elements, for operation and
21 management, by which FCAPS management, Software management, File management shall be achieved.

22 O2: Interface between management entities and the O-Cloud for supporting O-RAN virtual network functions.
23 RAN: Generally referred as Radio Access Network. In terms of this document, any component below near-RT RIC per
24 O-RAN architecture, including O-CU/O-DU/O-RU.

25 1.3.2 Abbreviations
26 For the purposes of the present document, the abbreviations given in 3GPP TR 21.905 [1] and the following apply. An
27 abbreviation defined in the present document takes precedence over the definition of the same abbreviation, if any, in
28 3GPP TR 21.905 [1].
29 AI/ML Artificial Intelligence/Machine Learning
30 CAM Cooperative Awareness Message
31 DENM Decentralized Environmental Notification Message
32 eNB eNodeB (applies to LTE)
33 gNB gNodeB (applies to NR)
34 KPI Key Performance Indicator
35 MIMO Multiple Input, Multiple Output
36 NRT Neighbor Relation Table
37 O-CU O-RAN Central Unit
38 O-DU O-RAN Distributed Unit

________________________________________________________________________________________________
Copyright © 2022 by the O-RAN ALLIANCE e.V. Your use is subject to the terms of the O-RAN Adopter License Agreement in Annex ZZZ 7
O-RAN.WG1.Use-Cases-Detailed-Specification-v08.00

1 O-RU O-RAN Radio Unit

2 PRB Physical Resource Block
3 QoE Quality of Experience
4 RAN Radio Access Network
5 RIC O-RAN RAN Intelligent Controller
6 SINR Signal-to-Interference-plus-Noise Ratio
7 SMO Service Management and Orchestration.
8 UAV Unmanned Aerial Vehicle
9 V2X Vehicle to Everything
10

________________________________________________________________________________________________
Copyright © 2022 by the O-RAN ALLIANCE e.V. Your use is subject to the terms of the O-RAN Adopter License Agreement in Annex ZZZ 8
O-RAN.WG1.Use-Cases-Detailed-Specification-v08.00

1 Chapter 2 Objective
2 This document provides O-RAN WG1 detailed use case descriptions. Any multi-WG use case defined in O-RAN is
3 expected to be documented in “O-RAN WG1 Use Case Analysis Report” and if the use case is to be studied further, it
4 will be covered in this document in detail, and then in relevant WGs. It should be noted that not all of the use cases
5 presented here are currently supported by O-RAN specifications and these use cases will be addressed in future O-RAN
6 work.

________________________________________________________________________________________________
Copyright © 2022 by the O-RAN ALLIANCE e.V. Your use is subject to the terms of the O-RAN Adopter License Agreement in Annex ZZZ 9
O-RAN.WG1.Use-Cases-Detailed-Specification-v08.00

1 Chapter 3 Use cases

2 3.1 Use case 1: Context-Based Dynamic HO Management for V2X

3 This use case provides the background, motivation, and requirements for the Context-based Dynamic HO
4 Management for V2X use case, allowing operators to adjust radio resource allocation policies through the O-RAN
5 architecture, reducing latency and improving radio resource utilization.

6 3.1.1 Background and goal of the use case

7 V2X communication allows for numerous potential benefits such as increasing the overall road safety, reducing
8 emissions, and saving time. Part of the V2X architecture is the V2X UE (SIM + device attached to vehicle) which
9 communicates with the V2X Application Server (V2X AS). The exchanged information comprises Cooperative
10 Awareness Messages (CAMs), (from UE to V2X AS) [14], radio cell IDs, connection IDs, and basic radio measurements
11 (RSRP, RSPQ, etc.)

12 As vehicles traverse along a highway, due to their high speed and the heterogeneous natural environment V2X UE-s are
13 handed over frequently, at times in a suboptimal way, which may cause handover (HO) anomalies: e.g., short stay, ping-
14 pong, and remote cell. Such suboptimal HO sequences substantially impair the functionality of V2X applications. Since
15 HO sequences are mainly determined by the Neighbour Relation Tables (NRTs), maintained by the xNBs, there is hardly
16 room for UE-level customization.

17 This UC aims to present a method to avoid and/or resolve problematic HO scenarios by using past navigation and radio
18 statistics in order to customize HO sequences on a UE level. To this end, the AI/ML functionality that is enabled by the
19 Near-RT RIC is employed.

20 3.1.2 Entities/resources involved in the use case

21 1) Non-RT RIC:
22 a) Retrieve necessary performance, configuration, and other data for constructing/training relevant AI/ML models
23 that will be deployed in Near-RT RIC to assist in the V2X HO management function. For example, this could
24 be a clustering algorithm that classifies traffic situations and radio conditions that (probably) do or do not lead
25 to HO anomalies.
26 b) Support deployment and update of AI/ML models into Near-RT RIC xApp.
27 c) Support communication of intents and policies (system-level and UE-level) from non-RT RIC to Near-RT RIC.
28 d) Support communication of non-RAN data to enrich control functions in Near-RT RIC (enrichment data).
29 2) Near-RT RIC:
30 a) Support update of AI/ML models retrieved from Non-RT RIC.
31 b) Support interpretation and execution of intents and policies from Non-RT RIC.
32 c) Support necessary performance, configuration, and other data for defining and updating intents and policies for
33 tuning relevant AI/ML models.
34 d) Support communication of configuration parameters to RAN.
35 3) RAN:
36 a) Support data collection with required granularity to SMO over O1 interface.
37 b) Support near-real-time configuration-based optimization of HO parameters over E2 interface.

________________________________________________________________________________________________
Copyright © 2022 by the O-RAN ALLIANCE e.V. Your use is subject to the terms of the O-RAN Adopter License Agreement in Annex ZZZ 10
O-RAN.WG1.Use-Cases-Detailed-Specification-v08.00

1 c) Report necessary performance, configuration, and other data for performing real-time V2X HO optimization
2 in the Near-RT RIC over E2 interface.
3 4) V2X Application Server
4 a) Support data collection with required granularity from V2X UE over V1 interface.
5 b) Support communication of real-time traffic related data about V2X UE to non-RT RIC as enrichment data.

6 3.1.3 Solutions

7 3.1.3.1 Context-based Dynamic Handover Management for V2X

<<Uses>>
Use Case Stage Evolution / Specification
Related use
Drive V2X UE HOs in RAN according to defined intents, policies, and
Goal
configuration while enabling AI/ML-based solutions.
Non-RT RIC: RAN policy control function.
Near-RT RIC: RAN policy enforcement function.
Actors and Roles RAN: policy enforcement for configuration updates.
SMO: termination point for O1 interface.
V2X AS: termination point for V1 interface and enrichment data provider.
All relevant functions and components are instantiated.
Assumptions
A1, O1, E2 interface connectivity is established.
Network is operational.
SMO has established the data collection and sharing process, and Non-RT RIC
has access to this data.
Pre conditions Non-RT RIC analyzes the historical data from RAN and V2X AS for training the
relevant AI/ML models to be deployed or updated in the Near-RT RIC, as well
as AI/ML models required for real-time optimization of configuration and
policies.
Begins when Operator specified trigger condition or event is detected.
Non-RT RIC deploys/updates the AI/ML model in the Near-RT RIC via O1 or
Step 1 (M)
Non-RT RIC assigns/update the AI/ML model for the Near-RT RIC xApp via A1.
Non-RT RIC communicates relevant policies/intents and enrichment data to the
Near-RT RIC over the A1 interface. The enrichment data from the non-RAN
Step 2 (M)
data may include V2X UE location, trajectory, navigation information, GPS data,
CAMs, DENMs.
The Near-RT RIC receives the relevant info from the non-RT RIC over the A1
Step 3 (M) interface and from the RAN over the E2 interface, interprets the policies and
updates the AI/ML models.
The Near-RT RIC infers optimal RAN configuration (UE-specific NRTs)
Step 4 (M) according to the trained AI/ML models and communicates the result to the RAN
over E2 interface.
RAN deploys the configuration received from the Near-RT RIC over the E2
Step 5 (M)
interface.
If required, Non-RT RIC can configure specific performance measurement data
to be collected from RAN to assess the performance of the V2X HO
Step 4
management function in Near-RT RIC, or to assess the outcome of the applied
policies and configuration.
Ends when Operator specified trigger condition or event is satisfied.
Exceptions None identified.
Non-RT RIC monitors the performance of the V2X HO related function in Near-
RT RIC by collecting and monitoring the relevant performance KPIs and
Post Conditions
counters from the RAN and the V2X AS.

8 Table 3.1.3-1: Context-based Dynamic Handover Management for V2X

________________________________________________________________________________________________
Copyright © 2022 by the O-RAN ALLIANCE e.V. Your use is subject to the terms of the O-RAN Adopter License Agreement in Annex ZZZ 11
O-RAN.WG1.Use-Cases-Detailed-Specification-v08.00

2 Figure 3.1.3-1: Context-based Dynamic Handover Management for V2X flow diagram

3 3.1.4 Required data

4 The measurement counters and KPIs (as defined by 3GPP) should be appropriately aggregated by cell, QoS type, slice,
5 etc.

6 1) Measurement reports with RSRP/RSRQ/CQI information for serving and neighboring cells.

7 2) UE connection and mobility/handover statistics with indication of successful and failed handovers and error codes
8 etc.

9 3) V2X related data: position, velocity, direction, navigation data, CAMs, DENMs [15][16].

10 3.2 Use case 2: Flight Path Based Dynamic UAV Radio Resource
11 Allocation
12 This use case provides the background, motivation, and requirements for the support the use case of flight path based
13 dynamic UAV Radio Resource Allocation, allowing operators to adjust radio resource allocation policies through the O-
14 RAN architecture, reducing unnecessary handover and improving radio resource utilization.

________________________________________________________________________________________________
Copyright © 2022 by the O-RAN ALLIANCE e.V. Your use is subject to the terms of the O-RAN Adopter License Agreement in Annex ZZZ 12
O-RAN.WG1.Use-Cases-Detailed-Specification-v08.00

1 3.2.1 Background and goal of the use case

2 The field trials’ results show that the coverage for low altitude is good and can provide various services for terrestrial UEs
3 with good performance. However, since the site along the flight is mainly for terrestrial UEs, the altitude of the UAV is
4 always not within the main lobe of the ground station antenna. And the side lobes give rise to the phenomenon of scattered
5 cell associations particularly noticeable in the sky. The cell association pattern on the ground is ideally contiguous area
6 where the best cell is most often the one closest to the UE. As the UE move up in height, the antenna side lobes start to
7 be visible, and the best cell may no longer be the closest one. The cell association pattern in this particular scenario
8 becomes fragmented especially at the height of 300m and above. Hence, at higher altitudes, several challenges that lead
9 to a different radio environment are:

10 a) LOS propagation/uplink interference

11 b) Poor KPI caused by antenna side lobes for base stations
12 c) Sudden drop in signal strength
13
14 These challenges directly impact on the mobility performance of the drone and the service experience of the user. Hence,
15 we would like to support the use case of flight path based dynamic UAV Radio Resource Allocation to resolve the above
16 issues.

17 Non-Real time RIC can retrieve necessary of Aerial Vehicles related measurement metrics from network based on UE’s
18 measurement report and SMO, and flight path information of Aerial vehicle, climate information, flight
19 forbidden/limitation area information and Space Load information etc. from application, e.g. UTM(Unmanned Traffic
20 Management) for constructing/training relevant AI/ML model that will be deployed in RAN. For example, this could be
21 UL/DL interference from/to Aerial vehicles, the detection of Aerial Vehicle UEs, and available radio resource (e.g.
22 frequency, cell, beam, BWP, numerology) prediction. And the Near-Real time RIC can support deployment and execution
23 of AI/ML models from non-RT RIC. Based on this, the Near-Real time RIC can perform the radio resource allocation for
24 on-demand coverage for UAV considering the radio channel condition, flight path information and other application
25 information.

28 Figure 3.2.1-1: Use case of flight path based dynamic UAV Radio Resource Allocation

29 Since there is no effective functional module in current eNB/gNB to retrieve the application information, perform machine
30 learning and training based on both the acquired application information and radio environment information, and execute
31 AI/ML models based on above information. And in the O-RAN architecture, the flight path based dynamic UAV Radio

________________________________________________________________________________________________
Copyright © 2022 by the O-RAN ALLIANCE e.V. Your use is subject to the terms of the O-RAN Adopter License Agreement in Annex ZZZ 13
O-RAN.WG1.Use-Cases-Detailed-Specification-v08.00

1 Resource Allocation mechanism can be supported by the RIC function module, i.e. non-real time RIC and near-real time
2 RIC. Therefore, we provide the description of O-RAN support use case for flight path based dynamic UAV Radio
3 Resource.

4 3.2.2 Entities/resources involved in the use case

5 1) Non-RT RIC:
6 a) Retrieve necessary of O-RAN Support for Aerial Vehicles related measurement metrics from network level
7 measurement report and SMO (may acquire data from application) for constructing/training relevant AI/ML
8 model that will be deployed in Near-RT RIC to assist in the O-RAN Support for Aerial Vehicles function. For
9 example, this could be UL/DL interference from/to Aerial vehicles, the detection of Aerial Vehicle UEs, and
10 available radio resource (e.g. frequency, cell, beam, BWP, numerology) prediction.
11 b) Training of potential ML models for O-RAN Support for Aerial Vehicles, which may respectively
12 autonomously control UL/DL interference from/to Aerial vehicles, detect the UE of Aerial Vehicles, and
13 predict available radio resource (e.g. frequency, cell, beam, BWP, numerology) for Aerial Vehicles.
14 c) Send policies/intents to Near-RT RIC to drive the O-RAN Support for Aerial Vehicles at RAN level in terms
15 of expected behavior.
16 2) Near-RT RIC:
17 a) Support update of AI/ML models from Non-RT RIC.
18 b) Support execution of the AI/ML models from Non-RT RIC.
19 c) Support interpretation and execution of intents and policies from Non-RT RIC to derive O-RAN Support for
20 Aerial Vehicles at RAN level in terms of expected behavior.
21 d) Support perform the radio resource allocation for on-demand coverage for UAV considering the radio channel
22 condition, flight path information and other application information via the AI/ML models from non-RT RIC.
23 e) Sending Aerial Vehicles performance report to Non-RT RIC for evaluation and optimization.
24 3) RAN:
25 a) Support data collection with UE performance report over O1 interface.
26 b) Support non-real-time optimization of radio resources allocation parameters over O1 interface.
27 4) Application server:
28 a) Provide application information, e.g. flight path information of Aerial vehicle, climate information, flight
29 forbidden/limitation area information and Space Load information.

________________________________________________________________________________________________
Copyright © 2022 by the O-RAN ALLIANCE e.V. Your use is subject to the terms of the O-RAN Adopter License Agreement in Annex ZZZ 14
O-RAN.WG1.Use-Cases-Detailed-Specification-v08.00

1 3.2.3 Solutions

2 3.2.3.1 Flight path based dynamic UAV Radio Resource Allocation

<<Uses>>
Use Case Stage Evolution / Specification
Related use
In the O-RAN architecture, the flight path based dynamic UAV Radio Resource
Allocation mechanism can be supported, which can perform the radio resource
Goal
allocation for on-demand coverage for UAV considering the radio channel
condition, flight path information and other application information.
Non-RT RIC: RAN policy control function
Near-RT RIC: RAN policy enforcement function
Actors and Roles
RAN: Implementation of updated configuration parameters
Application Server: generate RAN side UE-level policies
All relevant functions and components are instantiated.
Assumptions
A1/O1 interface connectivity is established with non-RT RIC.
Near-RT RIC and Non-RT RIC are instantiated with A1 interface connectivity
being established between them.
A certificate is shared between Near-RT RIC and Non-RT RIC for model
Pre conditions
related data exchange.
E2 interface is established between Near-RT RIC and CU/DU.

Begins when Operator specified trigger condition or event is detected.

Step 1 (M) Application Server sends the application data to Non-RT RIC.
Non-RT RIC deploys/updates AI/ML models in the Near-RT RIC via O1 or Non-
Step 2 (M)
RT RIC assigns/update the AI/ML model for the near-RT RIC xApp via A1.
Non-RT RIC sends relevant policies/intents and enrichment data to the near-RT
Step 3 (M)
RIC over the A1 interface.
The Near-RT RIC receives the relevant info from the Non-RT RIC over the A1
interface and from the RAN over the E2 interface, interprets the policies and
Step 4 (M) updates the AI/ML models.
And the Near-RT RIC converts policy to specific configuration parameter
commands.
RAN executes the command to modify the configuration parameters RAN
Step 5 (M)
executes the command to modify the configuration parameters.
Ends when Operator specified trigger condition or event is satisfied
Exceptions FFS
Non-RT RIC collects relevant performance data from eNB / gNB, to observe the
Post Conditions data transmission performance improvement brought by the wireless resource
configuration optimization policy.
3 Table 3.2.3-1: Flight path based dynamic UAV Radio Resource Allocation

________________________________________________________________________________________________
Copyright © 2022 by the O-RAN ALLIANCE e.V. Your use is subject to the terms of the O-RAN Adopter License Agreement in Annex ZZZ 15
O-RAN.WG1.Use-Cases-Detailed-Specification-v08.00

1
2 Figure 3.2.3-1: Use case of flight path based dynamic UAV Radio Resource Allocation flow diagram

3 3.2.4 Required data

4 Multi-dimensional data are expected to be retrieved for AI/ML model training and policies generation.
5 1) Network level measurement report, including
6 a) UE level radio channel information, mobility related metrics
7 b) UE level location information
8 2) Aerial Vehicles related measurement metrics collected from SMO (may acquire data from application or network,
9 e.g. flight path information of Aerial vehicle, climate information, flight forbidden/limitation area information and
10 Space Load information).

11 3.3 Use case 3: Radio Resource Allocation for UAV Application

12 Scenario
13 This use case provides the background, motivation, and requirements for the UAV control vehicle use case, allowing
14 operators to adjust radio resource allocation policies through the O-RAN architecture, reducing latency and improving
15 radio resource utilization.

16 3.3.1 Background and goal of the use case

17 As shown in Figure 3.3.1-1, this scenario refers to a Rotor UAV flying at low altitude and low speed, and carrying
18 cameras, sensors and other devices mounted. The Operation terminals work in the 5.8GHz to remote control the UAV for
19 border/forest inspection, high voltage/base station inspection, field mapping, pollution sampling, and HD live broadcast.
20 At the same time, the UAV mobile control stations and the anti-UAV weapons jointly provide the service of fighting
21 against illegal UAVs to ensure low-altitude safety in special areas. The UAV Operation terminals, the anti-UAV weapons,
22 and the UAV mobile control stations are connected with the UAV Control Vehicle using 5G network.

________________________________________________________________________________________________
Copyright © 2022 by the O-RAN ALLIANCE e.V. Your use is subject to the terms of the O-RAN Adopter License Agreement in Annex ZZZ 16
O-RAN.WG1.Use-Cases-Detailed-Specification-v08.00

2 Figure 3.3.1-1: UAV Control Vehicle Application scenario

3 UAV Control Vehicle deploys network equipment, including O-CU, O-DU, the Non-RT RIC function modules and
4 Application Server (In this use case it is an Edge computing Service Platform) to provide reliable network services through
5 5G networks. The data transmitted over the network includes control data and application data. The control data includes
6 navigation commands, configuration changes, flight status data reporting, etc. Control data requires low latency and low
7 bandwidth requirements. The application data includes 4K high-definition video data, which has obvious uplink and
8 downlink service asymmetry, and the uplink has high requirements on network bandwidth. The UAV Control Vehicle
9 deploys edge computing services on the 5G gNB side to implement local processing of video and control information. At
10 the same time, real-time data services can be provided with the third-party applications by a video server. The Near RT
11 RIC function module provides radio resource management functions of the gNB side.

14 Figure 3.3.1-2: Network architecture for UAV Control Vehicle Application scenario

15 The 5G network supports real-time high-definition video transmission and remote low-latency control of UAV, and
16 finally provides various industry services such as inspection, security, surveying and mapping. In the UAV Control
17 Vehicle Application scenario, there are a small amount of control data interaction requirements between the terminal and
18 the network interaction, as well as the large bandwidth requirements for uploading HD video.

________________________________________________________________________________________________
Copyright © 2022 by the O-RAN ALLIANCE e.V. Your use is subject to the terms of the O-RAN Adopter License Agreement in Annex ZZZ 17
O-RAN.WG1.Use-Cases-Detailed-Specification-v08.00

1 The service asymmetry raises new requirements for resource allocation of the gNB. At the same time, the existing network
2 operation and maintenance management platform (OSS system) can only optimize the parameters of a specific group of
3 UEs, but not individual users. In the O-RAN architecture, the radio resource requirements for different terminals are sent
4 to the gNB for execution by means of the RIC function module.

5 The UAV control vehicle has flexible layout features. In this use case, the application service and content is deployed on
6 the edge computing platform instead of the core network; the RIC function module is used to schedule radio resources
7 instead of the core network's QoS mechanism. In this way, the load and overhead of the core network can be reduced, the
8 forwarding and processing time of data transmission can be reduced.

9 As shown in Figure 3.3.1-2, this scenario involves two options of network architecture. Option A is that gNB and Near-
10 RT RIC are deployed on the Control Vehicle, Non-RT RIC and core network are deployed on the central cloud. The
11 Control Vehicle is connected to the core network and NON RT RIC via fiber optics. Option B is a private network, all
12 the modules, including the gNB, Near-RT RIC, Non-RT RIC and the necessary core network function modules, are
13 deployed in the Control Vehicle.

14 3.3.2 Entities/resources involved in the use case

15 1) Non-RT RIC:
16 a) Support sending resource allocation requirements to Near-RT RIC.
17 b) Support receiving UE-level radio resource adjustment requirements from the Application Server.
18 c) Support communication between Non-RT RIC and near-RT RIC with UE-level policies.
19 2) Near-RT RIC:
20 a) Support for receiving resource allocation requests from Non-RT RIC.
21 b) Support for the interpretation and execution of the resource allocation policies received from Non-RT RIC.
22 c) Support communication with RAN of configuration parameters.
23 3) RAN:
24 a) Support resource allocation requests from the Near-RT RIC.
25 b) Support sending terminal registration information to RAN Application Server and Near-RT RIC.
26 c) Support non-real-time optimization of radio resources allocation parameters over O1 interface.
27 d) Support for adjustment of the resource configuration parameters for a specific UE.
28 4) Application Server
29 a) Support receiving terminal registration information from E2 nodes via SMO.
30 b) Support collection of user plane data uploaded from RAN.
31 c) Support sending UE-level radio resource adjustment requirements to Non-RT RIC

________________________________________________________________________________________________
Copyright © 2022 by the O-RAN ALLIANCE e.V. Your use is subject to the terms of the O-RAN Adopter License Agreement in Annex ZZZ 18
O-RAN.WG1.Use-Cases-Detailed-Specification-v08.00

1 3.3.3 Solutions

2 3.3.3.1 UAV Control Vehicle

<<Uses>>
Use Case Stage Evolution / Specification
Related use
In the UAV control vehicle scenario, the UE-level radio resource configuration
Goal optimization is achieved through the delivery of policies and configuration
parameters.
Non-RT RIC: RAN policy control function
Near-RT RIC: RAN policy enforcement function
Actors and Roles
RAN: Implementation of updated configuration parameters
Application Server: generate UE-level resource allocation requirements.
All relevant functions and components are instantiated.
Assumptions
A1/O1 interface connectivity is established with non-RT RIC.
The Non-RT RIC sends an instruction through the interface, informing the RAN
to allocate the default resource, and establish the cell.
Pre conditions
The RAN notifies the Near-RT RIC and Application Server of the accessed
terminal (UE) information.
Begins when Operator specified trigger condition or event is detected.
Application Server sends requirements of radio resource allocation adjustment
Step 1 (M) to Non-RT RIC.
This request can be sent at any time, or it can be sent at regular intervals.
Non-RT RIC converts the requirements to resource adjustment policy, and
Step 2 (M)
distributes the policy to the Near-RT RIC.
Step 3 (M) Near-RT RIC converts policy to specific configuration parameter commands.
Step 4 (M) RAN executes the command to modify the configuration parameters.
Step 5 (M) The specified UE adjusts the uplink rate
Ends when Operator specified trigger condition or event is satisfied
Exceptions FFS
Post Conditions The RAN operates using the newly deployed parameters/models
3 Table 3.3.3-1: UAV control vehicle

5
6 Figure 3.3.3-1: UAV control vehicle

7 3.3.4 Required data

8 Multi-dimensional data are expected to be retrieved for policy generation and performance improvements brought by the
9 policy:

________________________________________________________________________________________________
Copyright © 2022 by the O-RAN ALLIANCE e.V. Your use is subject to the terms of the O-RAN Adopter License Agreement in Annex ZZZ 19
O-RAN.WG1.Use-Cases-Detailed-Specification-v08.00

1 1) The number of terminals accessed, the identification information such as an UE ID that distinguishes each UAV
2 connected with UAV the control vehicle), and the resource information assigned by default;

3 2) UE-level radio resource allocation information, such as the number of PRB resources used in PDSCH/PUSCH
4 scheduling;

5 3.4 Use case 4: QoE Optimization

6 This use case provides the background and motivation for the O-RAN architecture to support real-time QoE optimization.
7 Moreover, some high-level description and requirements over Non-RT RIC, A1 and E2 interfaces are introduced.

8 3.4.1 Background and goal of the use case

9 The highly demanding 5G native applications like Cloud VR are both bandwidth consuming and latency sensitive.
10 However, for such traffic-intensive and highly interactive applications, current semi-static QoS framework can’t
11 efficiently satisfy diversified QoE requirements especially taking into account potentially significant fluctuation of radio
12 transmission capability. It is expected that QoE estimation/prediction from application level can help deal with such
13 uncertainty and improve the efficiency of radio resources, and eventually improve user experience. RAN analytics
14 information as RAN service can be exposed to an external application or MEC. It is envisioned to be helpful for the
15 application to improve the user experience.

16 The main objective is to ensure QoE optimization be supported within the O-RAN architecture and its open interfaces.
17 Multi-dimensional data, e.g., user traffic data, QoE measurements, network measurement report, can be acquired and
18 processed via ML algorithms to support traffic recognition, QoE prediction, QoS enforcement decisions. ML models can
19 be trained offline and model inference will be executed in a real-time manner. Focus should be on a general solution that
20 would support any specific QoE use case (e.g. Cloud VR, video, etc.).

21 3.4.2 Entities/resources involved in the use case

22 1) Non-RT RIC:
23 a) Retrieve necessary QoE related measurement metrics from network level measurement report and SMO (may
24 acquire data from application) for constructing/training relevant AI/ML model that will be deployed in Near-
25 RT RIC to assist in the QoE Optimization function. For example, this could be application classification, QoE
26 prediction, and available bandwidth prediction.
27 b) Training of potential ML models for predictive QoE optimization, which may respectively autonomously
28 recognize traffic types, predict quality of experience, or predict available radio bandwidth.
29 c) Send policies/intents to Near-RT RIC to drive the QoE optimization at RAN level in terms of expected behavior.
30 2) Near-RT RIC:
31 a) Support update of AI/ML models from Non-RT RIC.
32 b) Support execution of the AI/ML models from Non-RT RIC, e.g. application classification, QoE prediction, and
33 available bandwidth prediction.
34 c) Support interpretation and execution of intents and policies from Non-RT RIC to derive the QoE optimization
35 at RAN level in terms of expected behavior.
36 d) Sending QoE performance report to Non-RT RIC for evaluation and optimization
37 3) RAN:
38 a) Support network state and UE performance report with required granularity to SMO over O1 interface.
39 b) Support QoS enforcement based on messages from A1/E2, which are expected to influence RRM behavior.

1 4) Application Server/MEC:
2 a) Request/subscribe RAN analytics information from Near-RT RIC.

3 3.4.3 Solutions

4 3.4.3.1 AI/ML Model training and distribution

<<Uses>>
Use Case Stage Evolution / Specification
Related use
Goal Model training and Distribution
Actors and Roles Non-RT RIC, near-RT RIC, SMO, application server
All relevant functions and components are instantiated.
Assumptions
A1/O1 interface connectivity is established with Non-RT RIC.
Near-RT RIC and Non-RT RIC are instantiated with A1 interface
connectivity being established between them.
A certificate is shared between Near-RT RIC and Non-RT RIC for model
Pre conditions
related data exchange.
Editor’s Note: security related procedure is FFS.

Begins when Operator specified trigger condition or event is detected

QoE related measurement metrics from SMO (may acquire data from
Step 1 (M) application) and network level measurement report either for instantiating
training of a new ML model or modifying existing ML model.
Non-RT RIC does the model training, obtains QoE related models, and
may deploy QoE policy model internally. An example of QoE-related
models that can be used at the Near-RT RIC is provided as follows:

a) Application Classification Model (optional and may refer to 3rd

Step 2 (M) party’s existing functionality)
b) QoE Prediction Model
c) QoE policy Model
d) Available BW Prediction Model

Non-RT RIC deploys/updates the AI/ML model in the Near-RT RIC via
Step 3 (M) O1 or Non-RT RIC assigns/update the AI/ML model for the Near-RT RIC
xApp via A1.
Near-RT RIC stores the received QoE related ML models in the ML
Step 4 (M)
Model inference platform and based on requirements of ML models,
If required, Non-RT RIC can configure specific performance
measurement data to be collected from RAN to assess the performance
Step 5 (O)
of AI/ML models and update the AI/ML model in Near-RT RIC based on
the performance evaluation and model retraining.
Ends when Operator specified trigger condition or event is satisfied
Exceptions FFS
Near-RT RIC stores the received QoE related ML models in the ML
Post Conditions
Model inference platform and execute the model for QoE optimization
function in Near-RT RIC.
5 Table 3.4.3-1: Model training and distribution

2 Figure 3.4.3-1: Model training and distribution flow diagram

1 3.4.3.2 Policy generation and performance evaluation

<<Uses>>
Use Case Stage Evolution / Specification
Related use
Goal Policy generation and performance evaluation
Actors and Roles Non-RT RIC, near-RT RIC, SMO
All relevant functions and components are instantiated.
Assumptions
A1/O1 interface connectivity is established with Non-RT RIC.
QoE related models have been deployed in Non-RT RIC and Near-RT RIC
Pre conditions
respectively.
The network operator/manager want to generate QoE policy or optimize
Begins when
QoE related AI/ML models.
Non-RT RIC evaluates the collected data and generates the appropriate
Step 1 (M)
QoE optimization policy.
Non-RT RIC sends the QoE optimization policy to Near-RT RIC via A1
Step 2 (M)
interface.
Near-RT RIC receives the policy from the Non-RT RIC over the A1
interface and from the RAN over the E2 interface. And the Near-RT RIC
Step 3 (M)
inferences the QoE related AI/ML models and converts policy to specific
E2 control or policy commands.
Near-RT RIC sends the E2 control or policy commands towards RAN for
Step 4 (M)
QoE optimization.
RAN enforces the received control or policy from the near-RT RIC over the
Step 5 (M)
E2 interface.
If required, Non-RT RIC can configure specific performance measurement
data to be collected from RAN to assess the performance of the QoE
Step 6 (O)
optimization function in near-RT RIC, or to assess the outcome of the
applied A1 policies. And then update A1 policy and E2 control or policy.
Ends when Operator specified trigger condition or event is satisfied
Exceptions FFS
Non-RT RIC monitors the performance of the QoE optimization related
Post Conditions function in Near-RT RIC by collecting and monitoring the relevant
performance KPIs and counters from RAN.
2 Table 3.4.3-2: Policy generation and performance evaluation

1
2 Figure 3.4.3-2: Policy generation and performance evaluation flow diagram

1 3.4.3.3 RAN Performance Analytics

<<Uses>>
Use Case Stage Evolution / Specification
Related use
Goal Expose RAN analytics information to external applications or MEC.
Actors and Roles Non-RT RIC, near-RT RIC, SMO, application server/MEC
All relevant functions and components are instantiated.
Assumptions
A1/O1 interface connectivity is established with Non-RT RIC.
QoE related models have been deployed in Non-RT RIC and Near-RT RIC
Pre conditions respectively.
Editor’s Note: Security related procedure is FFS.
The application server or MEC wants to request/subscribe RAN analytics
Begins when
information
Application server or MEC sends RAN analytics information request to
Step 1 (M) Near-RT RIC or subscribes RAN analytics information from Near-RT RIC
to get periodic or event triggered RAN performance.
Near-RT RIC receives the request or subscription from application server
or MEC. Upon the request, the Near-RT RIC subscribes and receives the
measurement data from O-CU/O-DU. Based on it, with QoE related AI/ML
Step 2 (M) models, the Near-RT RIC infers the RAN analytics information, and
exposes it to application server or MEC via the response or notification
command. Such information, e.g.performance analytics could be used for
QoE optimization.
Application server gets response or sends subscription deletion toward the
Ends when
Near-RT RIC.
Exceptions FFS
Post Conditions Application server executes logic control, e.g., TCP transmission window
adjustment, video coding rate selection to improve QoE.
2 Table 3.4.3-x: RAN Performance Analytics

5 Figure 3.4.3.3-1: RAN Performance Analytics flow diagram

6 3.4.4 Required data

7 Multi-dimensional data are expected to be retrieved by Non-RT RIC for AI/ML model training and policies/intents
8 generation. Network level measurement data from O-CU/O-DU are also expected to report to Near-RT RIC for RAN
9 analytics information inference.
10 1) Network level measurement report, including

1 c) UE level radio channel information, mobility related metrics, e.g., CQI, SINR, MCS
2 d) L2 measurement report related to traffic pattern, e.g., throughput, latency, packets per-second, inter frame arrival
3 time
4 e) RAN protocol stack status: e.g. PDCP buffer status
5 f) Cell level information: e.g. DL/UL PRB occupation rate
6 2) QoE related measurement metrics collected from SMO (may acquire data from application or network).

7 3) User traffic data, which may be obtained via a proprietary interface from existing data collection equipment and is
8 currently out of the scope of A1 or E2.

10 RAN Analytics Information:

11 RAN analytics information exposed by Near-RT RIC to application server includes but is not limited to,

12 1) UE level information, e.g.,

13 a) Predicted RAN performance, e.g., maximum/average traffic rate, maximum/average latency, average packet
14 loss rate

15 b) Prediction related information, e.g., confidence, validity period

16 2) Cell level information.

18 3.5 Use case 5: Traffic Steering

19 This use case provides the motivation, description, and requirements for traffic steering use case, allowing operators to
20 specify different objectives for traffic management such as optimizing the network/UE performance, or achieving
21 balanced cell load.

22 3.5.1 Background and goal of the use case

23 5G systems will support many different combinations of access technologies namely; LTE (licensed band), NR (licensed
24 band), NR-U (unlicensed band), Wi-Fi (unlicensed band) [13]. Several different multi-access deployment scenarios are
25 possible with 5GC to support wide variety of applications and satisfy the spectrum requirements of different service
26 providers;
27 - Carrier aggregation between licensed band NR (Primary Cell) and NR-U (Secondary Cell)
28 - Dual connectivity between licensed band NR (Primary Cell) and NR-U (Secondary Cell)
29 - Dual connectivity between licensed band LTE (Primary Cell) and NR-U (Secondary Cell)
30 - Dual connectivity between licensed band NR (Primary Cell) and Wi-Fi (Secondary Cell)
31 Note: The scenario of dual connectivity between NR and Wi-Fi is for future study

32 The rapid traffic growth and multiple frequency bands utilized in a commercial network make it challenging to steer the
33 traffic in a balanced distribution. Further in a multi-access system there is need to switch the traffic across access
34 technologies based on changes in radio environment and application requirements and even split the traffic across multiple
35 access technologies to satisfy performance requirements. The different types of traffic and frequency bands in a
36 commercial network make it challenging to handle the complex QoS aspects, bearer selection (Master Cell Group (MCG)
37 bearer, Secondary Cell Group (SCG) bearer, Split bearer), bearer type change for load balancing, achieving low latency
38 and best in class throughput in a multi-access scenario with 5GC networks [10]. Typical controls are limited to adjusting
39 the cell reselection and handover parameters; modifying load calculations and cell priorities; and are largely static in
40 nature when selecting the type of bearers and QoS attributes.

1 Further, the RRM (Radio Resource Management) features in the existing cellular network are all cell-centric. Even in
2 different areas of within a cell, there are variations in radio environment, such as neighboring cell coverage, signal
3 strength, interference status, etc. However, base stations based on traditional control strategies treat all UEs in a similar
4 way and are usually focused on average cell-centric performance, rather than UE-centric.

5 Such current solutions suffer from following limitations:

6  It is hard to adapt the RRM control to diversified scenarios including multi-access deployments and optimization
7 objectives.
8  The traffic management strategy is usually passive, rarely taking advantage of capabilities to predict network and
9 UE performance. The strategy needs to consider aspects of steering, switching and splitting traffic across different
10 access technologies in a multi-access scenario.
11  Non-optimal traffic management, with slow response time, due to various factors such as inability to select the
12 right set of UEs for control action. This further results in non-optimal system and UE performance, such as
13 suboptimal spectrum utilization, reduced throughput and increased handover failures.
14
15 Based on the above reasons, the main objective of this use case is to allow operators to flexibly configure the desired
16 optimization policies, utilize the right performance criteria, and leverage machine learning to enable intelligent and
17 proactive traffic management.

18 3.5.2 Entities/resources involved in the use case

19 1) Non-RT RIC:
20 a) Retrieve necessary performance, configuration, and other data for defining and updating policies to guide the
21 behavior of traffic management function in Near-RT RIC. For example, the policy could relate to specifying
22 different optimization objectives to guide the carrier/band preferences at per-UE or group of UE granularity.
23 b) Support communication of policies to near-RT RIC.
24 c) Support communication of measurement configuration parameters to RAN.
25 2) Near-RT RIC:
26 a) Support interpretation and enforcement of policies from Non-RT RIC.
27 3) E2 nodes:
28 a) Support data collection with required granularity to SMO over O1 interface.

1 3.5.3 Solutions

2 3.5.3.1 Traffic steering

<<Uses>>
Use Case Stage Evolution / Specification
Related use
Drive traffic management in RAN in accordance with defined intents, policies,
Goal
and configuration.
Non-RT RIC: RAN policy control function
Near-RT RIC: RAN policy enforcement function
Actors and Roles
E2 nodes: Control plane and user plane functions
SMO/Collection & Control: termination point for O1 interface.
All relevant functions and components are instantiated.
Assumptions A1 interface connectivity is established with Non-RT RIC.
O1 interface connectivity is established with SMO/ Collection & Control
Network is operational.
SMO/ Collection & Control has established the data collection and sharing
Pre conditions process, and Non-RT RIC has access to this data.
Non-RT RIC monitors the performance by collecting the relevant performance
events and counters from E2 nodes via SMO/ Collection & Control.
Begins when Operator specified trigger condition or event is detected
If required, Non-RT RIC configures additional, more specific, performance
Step 1 (O) measurement data to be collected from E2 nodes to assess the performance.
Non-RT RIC decides an action and communicates relevant policies to near-RT
RIC over A1. The example policies may include:

a) QoS targets;
Step 2(M) b) Preferences on which cells to allocate control plane and user plane
c) Bearer handling aspects including bearer selection, bearer type
change

The near-RT RIC receives the relevant info from Non-RT RIC over A1 interface,
Step 3 (M)
interprets the policies and enforces them.
Step 4 (M) Non-RT RIC decides that conditions to continue the policy is no longer valid.
Ends when Non-RT RIC deletes the policy.
Exceptions None identified
Non-RT RIC monitors the performance by collecting the relevant performance
Post Conditions
events and counters from E2 nodes via SMO.
3 Table 3.5.3-1: Traffic steering

1
2 Figure 3.5.3-1: Traffic steering use case flow diagram

3 3.5.4 Required data

4 The measurement counters and KPIs (as defined by 3GPP and will be extended for O-RAN use cases) should be
5 appropriately aggregated by cell, QoS type, slice, etc.

6 1) Measurement reports with RSRP/RSRQ/CQI information for serving and neighboring cells. In multi-access scenarios
7 this will also include intra-RAT and inter-RAT measurement reports, cell quality thresholds, CGI reports and
8 measurement gaps on per-UE or per-frequency.

9 2) UE connection and mobility/handover statistics with indication of successful and failed handovers etc.

10 3) Cell load statistics such as information in the form of number of active users or connections, number of scheduled
11 active users per TTI, PRB utilization, and CCE utilization.

12 4) Per user performance statistics such as PDCP throughput, RLC or MAC layer latency, etc.

13 3.6 Use case 6: Massive MIMO Beamforming Optimization

14 This use case provides the motivation, description, and requirements for Non-RT and Near-RT loop Massive MIMO
15 beamforming optimization use case. Massive MIMO system configuration can allow operators to optimize the network
16 performance and QoS by e.g. Non-RT and Near-RT loop balancing cell loads or reducing inter-cell interference and
17 control electromagnetic (EM) emissions.

1 3.6.1 Background and goal of the use case

2 Massive MIMO (mMIMO) is among the key levers to increase performance and QoS in 5G networks. Capacity
3 enhancement is obtained by means of beamforming of the transmitted signals, and by spatially multiplexing data streams
4 for both single user (SU) and for multi user (MU) MIMO. Beamforming increases the received signal power, while
5 decreasing the interference generated on other users, hence resulting in higher SINR and user throughputs. Beamforming
6 can be codebook based (mainly for FDD), or non-codebook based (TDD). Grid of Beams (GoB) with the corresponding
7 beam sweeping [11][12] has been introduced to allow beamforming the control channels used during initial access, mainly
8 for high frequency (but can be used also for the sub-6 GHz band) MIMO operation. The codebook and the GoB define
9 the span of the beams, namely the horizontal and vertical aperture in which beamforming is supported, and therefore the
10 coverage area and the shape of the cell. Massive MIMO can be deployed in 5G macro-cells as well as in heterogeneous
11 network, where macro-cells and 3D-MIMO small cells co-exist and complement each other for better aggregated capacity
12 and coverage. In order to obtain an optimal beamforming and cell resources (Tx power, PRB) configuration, one will
13 have to look at a multi-cell environment instead of a single cell. Moreover, different vendors may have different
14 implementations in terms of the number of beams, the horizontal/vertical beam widths, azimuth and elevation range, to
15 achieve the desired coverage. In a multi node/multi-vendor scenario, centralized monitoring and control is required to
16 offer optimal coverage, capacity and mobility performance as well as control over EM emissions in order to comply with
17 regulatory requirements. Additionally, the number of such combinations of adjustable parameters is in the thousands,
18 hence it is prohibitive for the traditional human expert system to work out the optimal configuration, and a new method
19 is in need.

20 State of the art solutions suffer from the following problems:

21 mMIMO macro- and small-cells benefit from a flexible way of serving users in their coverage area thanks to
22 beamforming. However the coverage area itself is defined by (vendor specific) fixed mMIMO system parameters such as
23 the azimuth and elevation angle range, or the GoB parameters. Hence due to user and traffic distribution and terrain
24 topology, the mMIMO cell may suffer from e.g.

25 1) High inter-cell interference

26 2) Unbalanced traffic between neighboring cells
27 3) Low performance of cell edge users
28 4) Poor handover performance

29 Moreover, load balancing functions may be activated in the network nodes, e.g. gNB adapting mobility parameters in
30 order to distribute load between the beams of the neighbor cells, relying on load information exchange over network
31 interfaces. This approach however is partly limited by the cell footprint statically fixed at the initial configuration.

32 The objective of this use case is to allow the operator to flexibly configure a mMIMO system parameters by means of
33 policies and configuration assisted by machine learning techniques, according to objectives defined by the operator.

34 3.6.2 Entities/resources involved in the use case

35 3.6.2.1 Non-RT Massive MIMO GoB Beam Forming Optimization

36 1) Non-RT RIC:
37 a) Retrieve necessary configurations, performance indicators, measurement reports, user activity information and
38 other data from SMO and RAN directly for the purpose of constructing/training relevant AI/ML models that
39 will be deployed in Non-RT RIC to assist in the massive MIMO optimization function.

________________________________________________________________________________________________
Copyright © 2022 by the O-RAN ALLIANCE e.V. Your use is subject to the terms of the O-RAN Adopter License Agreement in Annex ZZZ 30
O-RAN.WG1.Use-Cases-Detailed-Specification-v08.00

1 b) Retrieve necessary user location related information, e.g. GPS coordinates, from the application layer for the
2 purpose of constructing/training relevant AI/ML models.
3 c) Use the trained AI/ML model to infer the user distribution and traffic distribution of multiple cells and predict
4 the optimal configuration of Massive MIMO parameters for each cell/beam according to a global optimization
5 objective designed by the operator. The Massive MIMO configurable parameters includes horizontal beam
6 width, vertical beam width, beam azimuth and downtilt, maximum and average transmitted power per
7 beam/direction [5].
8 d) Send the optimal beam pattern configuration to SMO configuration components
9 e) Retrain the AI/ML model and Re-optimize the beam pattern configurations based on the monitored
10 performance
11 f) Execute the control loop periodically or event-triggered
12 2) SMO
13 a) Collect the necessary configurations, performance indicators, and measurement reports data from RAN nodes
14 triggered by Non-RT RIC if required.
15 b) Configure the optimized beam parameters via O1 interface.
16 c) Monitor the performance of all the cells; when the optimization objective fails, initiate fall back procedure;
17 meanwhile, trigger the AI/ML model re-training, data analytics and optimization in Non-RT RIC.
18 3) E2 nodes
19 a) Collect and report to SMO and/or to Near-RT RIC KPI related to user activity, traffic load, coverage and QoS
20 performance, per beam/area, handover and beam failures statistics.
21 b) Collect and report to SMO and/or to Near-RT RIC information about beam and resource utilization
22 c) Apply beam management strategies following SMO and Near-RT RIC configuration and constraints

23 3.6.2.2 Near-RT Beam-based Mobility Robustness Optimization

24 1) SMO
25 a) Trigger bMRO configuration. (O)
26 b) Send bMRO configuration target to Near-RT RIC.
27 c) Send GoB Beam Pattern related information (Beam Pattern configuration, Beam Pattern configuration list,
28 Beam Pattern configuration switch timing/condition, Beam Pattern identifier etc.) to the Near-RT RIC.
29 2) Near-RT RIC
30 a) Retrieve necessary configurations, performance indicators, measurement reports and other data from E2 nodes
31 for the purpose of training of relevant AI/ML models.
32 b) Use the trained AI/ML models to infer the correlation between the Grid-of-Beam configuration, handover, and
33 beam failure statistics of multiple cells and beams, and to predict the optimal configuration of mobility
34 parameters (e.g., beam individual offsets for beam mobility) for each cell/beam pair optionally according to a
35 global optimization objective designed by the operator and retrieved from the SMO.
36 c) Send the optimal beam mobility parameter configurations to E2 nodes [5].
37 d) Monitor the performance of the AI/ML model based on configurations, performance indicators, and
38 measurement reports received from the RAN.
39 e) Retrain the AI/ML model and re-optimize the beam mobility configurations based on the monitored
40 performance and/or based on a switch of the Grid-of-Beam configuration.
41 f) Execute the control loop periodically or event-triggered.
42 g) Retrieve GoB Beam Pattern related information from the SMO.

________________________________________________________________________________________________
Copyright © 2022 by the O-RAN ALLIANCE e.V. Your use is subject to the terms of the O-RAN Adopter License Agreement in Annex ZZZ 31
O-RAN.WG1.Use-Cases-Detailed-Specification-v08.00

1 3) E2 nodes
2 a) Collect and report to Near-RT RIC KPIs related to Grid-of-Beam configuration, handover and beam failure
3 statistics.
4 b) Apply L3 beam mobility parameter configuration following Near-RT RIC configuration [5].
5 c) Send GoB Beam Pattern related information to the Near-RT RIC.

6 3.6.3 Solutions

7 3.6.3.1 Non-RT Massive MIMO GoB Beam Forming optimization

<<Uses>>
Use Case Stage Evolution / Specification
Related use
Enable flexible optimization of the multi-cell M-MIMO beamforming
performance (capacity and coverage) by means of configuration
Goal
parameter change with operator-defined objectives, and allow for AI/ML-
based solutions.
Non-RT RIC acting as Massive MIMO beamforming configuration
optimization decision making function.
Actors and Roles SMO acting as the RAN data collection and parameter configuration
function.
RAN acting as configuration enforcement function.
O1 interface connectivity is established between RAN and SMO.
Assumptions
Network is operational.
SMO has processed the collected data and non-RT RIC has access to
Pre conditions
this data.
Begins when Operator specified trigger condition or event is detected
If required, SMO can initiate the specific measurement data collection
Step 1 (O) request towards RAN for AI/ML model training or to assess the outcome
of the applied configuration.
Non-RT RIC retrieve the data from SMO components and trains the
AI/ML model with the collected data from the application, the RAN
Step 2 (M) nodes. Trained AI/ML models are deployed and inferenced for long-term
configuration parameters optimization.

Upon trigger from Non-RT RIC with the optimized beam parameters,
SMO configures the parameters towards the RAN via O1 interface. The
relevant parameters may include:
Step 3 (M) a) horizontal beam width, vertical beam width, beam azimuth and
downtilt
b) maximum and average transmitted power per beam/direction
SMO monitors the network performance. If the algorithm performance is
unsatisfactory in terms of predefined objective/requirement, SMO
Step 4 (M) initiates fallback mechanism to restore previous configuration, It can also
gather necessary information and data to retrain and update the AI/ML
model or trigger the optimization in Non-RT RIC.
Ends when Operator specified trigger condition or event is satisfied
Exceptions FFS
Post Conditions The RAN operates using the newly deployed parameters/models
8 Table 3.6.3-1: Massive MIMO GoB Beam Forming optimization

________________________________________________________________________________________________
Copyright © 2022 by the O-RAN ALLIANCE e.V. Your use is subject to the terms of the O-RAN Adopter License Agreement in Annex ZZZ 32
O-RAN.WG1.Use-Cases-Detailed-Specification-v08.00

1
2 Figure 3.6.3-1: Massive MIMO beamforming optimization flow diagram

________________________________________________________________________________________________
Copyright © 2022 by the O-RAN ALLIANCE e.V. Your use is subject to the terms of the O-RAN Adopter License Agreement in Annex ZZZ 33
O-RAN.WG1.Use-Cases-Detailed-Specification-v08.00

1 3.6.3.2 Near-RT Massive MIMO Beam-based Mobility Robustness Optimization

<<Uses>>
Use Case Stage Evolution / Specification
Related use
Enable flexible optimization of the Beam-based Mobility Robustness
Goal Optimization by means of configuration parameter change with
operator-defined objectives, and allow for AI/ML-based solutions.
Near-RT RIC acting as bMRO function, data collection function, and
Actors and Roles AI/ML model training function.
E2 Nodes acting as configuration enforcement function.
E2 connectivity is established between Near-RT RIC and E2 Nodes. O1
Assumptions connectivity is established between Near-RT RIC and SMO. Network is
operational.
Pre conditions Active Grid-of-Beams beam pattern is defined.
Operator specified trigger condition is set or event is detected or
Begins when
periodically.
Near-RT RIC collects necessary data from E2 Nodes and related GoB
Beam Pattern Information and trains the AI/ML model with the collected
Step 1 (M)
data.

Trained AI/ML models are executed in Near-RT RIC and infer for
Step 2 (M) configuration parameter optimization based on the operator target.

Continuously or upon trigger (e.g., change in the mMIMO Beam Pattern

Step 3 (M) configuration, manual trigger etc.), Near-RT RIC configures optimized
parameters in E2 Nodes (e.g., bCIO-s).
Near-RT RIC monitors the network performance. If the algorithm
performance is unsatisfactory in terms of predefined
objective/requirement, Near-RT RIC initiates fallback mechanism to
Step 4 (M)
restore previous/default configuration. It can also gather necessary
information and data to retrain and update the AI/ML model or trigger
the optimization.
Ends when Operator specified trigger condition or event is satisfied
Exceptions FFS
Post Conditions The E2 Nodes operate using the newly deployed parameters.
2 Table 3.6.3-2: Beam-based Mobility Robustness Optimization

________________________________________________________________________________________________
Copyright © 2022 by the O-RAN ALLIANCE e.V. Your use is subject to the terms of the O-RAN Adopter License Agreement in Annex ZZZ 34
O-RAN.WG1.Use-Cases-Detailed-Specification-v08.00

1
2 Figure 3.6.3-2: Massive MIMO Beam-based Mobility Robustness Optimization flow

________________________________________________________________________________________________
Copyright © 2022 by the O-RAN ALLIANCE e.V. Your use is subject to the terms of the O-RAN Adopter License Agreement in Annex ZZZ 35
O-RAN.WG1.Use-Cases-Detailed-Specification-v08.00

2 Notes on , :

3 One of the necessary inputs for training and inference of the bMRO function is the (current) GoB Beam Pattern (or
4 alternative beam pattern) that is determined externally (in the SMO, in the Non-RT RIC, in the E2 Nodes, or in the Near-
5 RT RIC by another function). The relevant GoB Beam Pattern Information must be made available to the Near-RT RIC
6 bMRO function both for training and inference. Depending on implementation, this can be achieved by transmission from
7 the SMO (over O1), or by transmission from the E2 Nodes (over E2), or by combined transmission from the SMO and
8 the E2 Nodes (or by communication between two Near-RT RIC functions). Moreover, depending how the relevant GoB
9 Beam Pattern Information is defined, the necessary information may be even transmitted separately and asynchronously
10 (e.g., SMO transmits a list of GoB Beam Patterns for the next, longer time period, while the E2 Nodes transmit the exact
11 times of Beam Pattern change and indicate the ID of the Beam Pattern in the list).

12 3.6.4 Required data

13 3.6.4.1 Non-RT Massive MIMO GoB Beam Forming optimization

14 There are different types of data that are required from different parts of the network, and the following list summarizes
15 with some examples:

16 1) Environment data: Cell site information (location), inter-site distance, BS system configuration, (e.g. operating
17 frequency, bandwidth, frame structure, transmit power, default beam weight configuration); complete set of Massive-
18 MIMO configurations, i.e. Horizontal beamwidth adjustable range, Vertical beamwidth adjustable range, Azimuth
19 angle adjustable range, Elevation angle adjustable range.

20 2) From RAN to SMO and/or Near-RT RIC

21 a) Measurement reports with RSRP/RSRQ/CQI/SINR per beam information for the UEs in cells of interest; the
22 time granularity of data collection should be configurable and satisfy the requirement of the AI/ML model

23 b) Network KPIs: e.g. cell downlink/uplink traffic load, RRC connection attempts, average RRC connected UE,
24 maximum RRC connected UE, average active connections (downlink/uplink), DL/UL throughput, DL/UL
25 spectral efficiency, NI (Noise interference); beam resource usage (transmitted power per beam/directions and
26 associated PRB usage), beam based handover and beam failure statistics

27 3) From Application to SMO

28 a) user location related information, e.g. GPS coordinates for the purpose of constructing/training relevant AI/ML
29 models

30 3.6.4.2 Near-RT Massive MIMO Beam-based Mobility Robustness Optimization

31 1) Beam-specific handover related KPMs [6][8][9] from E2 Nodes similar to:

32 a) Too Early Handovers

33 b) Too Late Handovers
34 c) Attempted Handovers
35 d) Successful Handovers
36 e) Failed Handovers

________________________________________________________________________________________________
Copyright © 2022 by the O-RAN ALLIANCE e.V. Your use is subject to the terms of the O-RAN Adopter License Agreement in Annex ZZZ 36
O-RAN.WG1.Use-Cases-Detailed-Specification-v08.00

1 f) The time granularity is an integer multiple of 1 second [8].

2 2) Beam Pattern Information supplied externally: FFS

4 3.7 Use case 7: RAN Sharing

5 This use case provides the motivation, description, and requirements for RAN sharing use case. The goal of this use case
6 is to enable multiple operators to share the same O-RAN infrastructure, while allowing them to remotely configure and
7 control the shared resources via a remote O1, O2 and E2 interface.

8 3.7.1 Background and goal of the use case

9 RAN sharing is envisioned as an efficient and sustainable way to reduce the network deployment costs, while increasing
10 network capacity and coverage. Among the different RAN sharing models that have been experimented so far, a special
11 focus is put here on the evaluation of the compatibility of the “Geographical Split” RAN sharing model with the O-RAN
12 architecture. In such a model, a coverage area is split between two or more operators; each operator manages the RAN in
13 a specific area, while sharing its RAN infrastructure and computing resources with its partner operators.

14 Specifically, this use case analyzes the Multi Operator RAN (MORAN) sharing scenario, wherein each operator utilizes
15 a separate carrier in order to achieve more freedom and independency on the control of the radio resources. Accordingly,
16 the goal of this use case is to propose a sharing-compliant O-RAN architecture that lets operators to configure the shared
17 network resources independently from configuration and operating strategies of the other sharing operators. Specifically,
18 it is proposed that a Home Operator (Operator A) makes available its O-RAN infrastructure and computing resources to
19 host the virtual RAN functions (VNF) of a second operator (Operator B), allowing it to configure and control such remote
20 VNFs via a remote O1, O2 and E2 interface.

22 Figure 3.7.1-1: MORAN Use-Case in O-RAN

23 Figure 3.7.1-1 describes the logic architecture of the proposed MORAN use case. It is assumed that Operator A owns the
24 site A and shares the PHY Layer (LOW) with Operator B (Shared O-RU). Indeed, multiple PLMN IDs are broadcasted,

________________________________________________________________________________________________
Copyright © 2022 by the O-RAN ALLIANCE e.V. Your use is subject to the terms of the O-RAN Adopter License Agreement in Annex ZZZ 37
O-RAN.WG1.Use-Cases-Detailed-Specification-v08.00

1 while each operator operates in a different carrier. Moreover, the computing resources of the site A are shared among
2 multiple VNFs, belonging to Operator A and Operator B, respectively.

3 Each VNF represents a logic implementation of the O-DU and O-CU functionalities and is controlled by each partner
4 operator in an independent manner. While Operator A can directly orchestrate and configure its VNFs, Operator B needs
5 to control its VNFs in a remoted manner. The challenge here is to enable Operator B to configure and control resources
6 in an infrastructure that is owned by another operator.

7 Accordingly, it is assumed that Operator B can monitor and control the remote radio resources via the RIC node of site
8 B, using an “E2 remote” interface. Note that in the proposed architecture, the RIC nodes are not shared and kept
9 independent at the site A and B respectively.

10 However, it is assumed that Operator B cannot directly orchestrate its VNFs in site A, but it is allowed to communicate
11 the desired initial VNF configuration via an extended O1, O2 interface, hereafter referred to as “O1, O2 + SLA” interface
12 (O1, O2 remote). Note that the O1, O2 nomenclature is used hereafter to refer to both O1 and O2 messages.

13 The “O1, O2 remote” interface is connected to a specific “sharing orchestration application”, referred to as “SMO-Sharing
14 APP”, that is located at the Service Management & Orchestration Framework of each operator. Specifically the “SMO-
15 Sharing APP” at site A acts as an SLA (Service Level Agreement) monitoring and filter entity: it checks that O1, O2
16 requests coming from Operator B are in line with a predefined SLA and finally configures the VNF of Operator B,
17 according to the initial O1, O2 request.

18 3.7.2 Entities/resources involved in the use case

19 1) SMO-Sharing APP (site A) :
20 a) SLA Monitoring: checks that orchestration/management requests sent by Operator B are in line with the SLA.
21 b) Remote provisioning and initial VNF deployment: asks the IMF to instantiate the VNFs for Operator B.
22 c) Remote management operations via “O1, O2 remote”: configures the VNF of Operator B via the Orchestrator,
23 according to “O1, O2 remote” requests sent by Operator B.
24 d) Forwards RAN related data, collected from the hosted VNFs, to the SMO-Sharing APP (site B) over the “O1, O2
25 remote” interface.
26 2) SMO-Sharing APP (site B) :
27 a) Detects the “SMO-Sharing-APP” in site A towards which to forward “O1, O2 remote” requests.
28 b) Sends “O1, O2 remote” commands for initial deployment and configuration of remote VNFs.
29 c) Forwards RAN related data of Operator B, collected in site A, to the Non-RT RIC.
30 3) IMF (Site A): Creates VNFs for Operator B in site A on initial request of the SMO-Sharing APP (site A).

31 4) RAN (site A):

32 a) Supports data collection from the hosted VNFs with radio state report over “E2 remote” interface.
33 b) Supports data collection from hosted VNFs with UE KPI report over “O1, O2 remote” interface.
34
35 5) Non-RT RIC (site B):
36 a) Configures the initial network policy template, e.g., default scheduling policy, of the remote VNFs.
37 b) Elaborates RAN data collected by “SMO-Sharing APP”, e.g., scheduling performance metrics, and sends A1
38 policy/intentions to the remote virtual O-DU/O-CU (VNF_B) via the near-RT RIC.
39 6) Near-RT RIC (site B):
40 a) Monitors and collects E2-related parameters from the remote VNFs.
41 b) Detects the “E2 remote” interface towards the VNFs hosted in site A.
42

________________________________________________________________________________________________
Copyright © 2022 by the O-RAN ALLIANCE e.V. Your use is subject to the terms of the O-RAN Adopter License Agreement in Annex ZZZ 38
O-RAN.WG1.Use-Cases-Detailed-Specification-v08.00

1 3.7.3 Solutions

2 3.7.3.1 RAN sharing

<<Uses>>
Use Case Stage Evolution / Specification
Related use
Enable two operators to share the same O-RAN infrastructure, while allowing
Goal them to remotely configure and control the shared resources via a remote “O1”,
“O2” and “E2” interface.
Sharing-SMO APP handles remote orchestration operations via “O1, O2
remote” interface. Non-RT RIC (Operator B): updates configuration of VNFs
Actors and Roles hosted in site A. Near-RT RIC (Op. B): execute remote E2 commands via “E2
remote” interface. RAN (Site A): collects and reports RAN statistics to the RIC
of Operator B (RIC_B) for its VNFs hosted in site A.
All relevant functions and components are instantiated.
A1, O1, O2, E2 interface connectivity is established with local SMO, Non-RT
RIC and near-RT RIC, respectively.
“O1, O2 remote” and “E2 remote” end-to-end connectivity is established with
Assumptions remote SMO and remote near-RT RIC, respectively. The remote interfaces
have been secured through appropriate end-to-end security mechanisms
(security configuration details are out of scope of this use case).
Non-RT RIC_B and near-RT RIC_B are aware of the presence of O-DU_B and
O-CU_B in the site A. Near-RT RIC_B is aware of the “E2 remote” interface, to
be used to control the remote VNFs hosted in site A.
An SLA sharing agreement is established between the home (Operator A) and
host operator (Operator B). The SLA defines the amount of physical resources
(CPU, memory, etc.), that can be allocated to the host operator and the type of
Pre conditions
admissible orchestration operations that can be remotely executed by the host
operator. Such SLA is translated in appropriate SLA monitoring-check controls
to be executed by the SMO-Sharing APP.
Phase 1-2: Host Operator (Operator B) asks to provision and instantiate an O-
DU_B and O-CU_B in the site of the Home Operator (Operator A).
Begins when
Phase 3: Host Operator wants to send a new instruction to the shared RAN over
the “E2 remote” interface.
SMO-Sharing APP_B sends a request to SMO-sharing-APP_A for provisioning
Step 1 (M)
and deploying a remote virtual O-DU_B and O-CU_B in the site A.
SMO-Sharing APP_A checks that the request is in line with the predefined SLA
Step 2 (M) and ask the IMF (via the Orchestrator) to instantiate the VNFs for the O-CU_B
and O-DU_B.
IMF creates VNF for Operator B in site A as for the request of the SMO-Sharing
Step 3 (O)
APP_A.
SMO-Sharing APP_B notifies SMO-Sharing APP_A the request to install a
Step 4 (M)
default network policy template, e.g., RB scheduling policy, in the remote VNFs.
SMO-Sharing APP_A checks that Operator B request is in line with the SLA and
Step 5 (M) configures (via the Orchestrator) the O-DU_B/ O-CU_B via an O1 configuration
command.
RAN related data from VNF_B in site A are collected at SMO Collector and
Step 6 (M) forwarded to the SMO-Sharing APP_A, which in turns forwards them to the Non-
RT RIC_B, via the SMO-Sharing APP_B.
Non-RT RIC_B decides to update the default network policy of the remote
Step 7 VNFs, e.g., scheduling policy of O-DU_B/O-CU_B and sends an A1 update
policy request to the near-RT RIC_B.
Near-RT RIC_B configures the remote O-DU_B/O-CU_B accordingly, over the
Step 8
“E2 remote” interface.
The VNFs of Operator B in site A are instantiated with success and no update-
Ends when
requests are sent by the Host Operator (Operator B).
Exceptions None identified.
RIC of Operator B monitors relevant radio KPI from the remote O-CU_B and O-
Post Conditions
DU_B and decides to reconfigure the scheduling policy as for Step 7.

________________________________________________________________________________________________
Copyright © 2022 by the O-RAN ALLIANCE e.V. Your use is subject to the terms of the O-RAN Adopter License Agreement in Annex ZZZ 39
O-RAN.WG1.Use-Cases-Detailed-Specification-v08.00

1 Table 3.7.3-1: RAN Sharing Use Case

2
3 Figure 3.7.3-1: VNF configuration procedure for VNF_B hosted in site A

4 3.7.4 Required data

5 Multi-dimensional data are expected to be handled by the SMO-Sharing APP:

6 1) SLA data needs to be converted in a set of condition steps to be matched for each request of the Host Operator
7 (Operator B).
8 2) SMO needs to handle O1, O2 messages sent by the Host Operator, converting them in local O1, O2 commands.
9
10 The RAN of the home operator needs to report to the RIC_B the network state of the served UEs that belong to the host
11 operator.

________________________________________________________________________________________________
Copyright © 2022 by the O-RAN ALLIANCE e.V. Your use is subject to the terms of the O-RAN Adopter License Agreement in Annex ZZZ 40
O-RAN.WG1.Use-Cases-Detailed-Specification-v08.00

1 3.8 Use case 8: QoS Based Resource Optimization

2 This use case provides the background and motivation for the O-RAN architecture to support RAN QoS based resource
3 optimization. Moreover, some high-level description and requirements over Non-RT RIC and A1 interfaces are
4 introduced.

5 3.8.1 Background and goal of the use case

6 QoS based resource optimization can used when the network has been configured to provide some kind of preferential
7 QoS for certain users. One such scenario can be related to when the network has been configured to support e2e slices. In
8 this case, the network has functionality that ensures resource isolation between slices as well as functionality to monitor
9 that slice Service Level Specifications (SLS) are fulfilled.

10 In RAN, it is the scheduler that ensures that Physical Resource Block (PRB) resources are isolated between slices in the
11 best possible way and also that the PRB resources are used in an optimal way to best fulfill the SLS for different slices.
12 The desired default RAN behavior for slices is configured over O1. For example, the ratio of physical resources (PRBs)
13 reserved for a slice is configured at slice creation (instantiation) over O1. Also, QoS can be configured to guide the RAN
14 scheduler how to (in real-time) allocate PRB resources to different users to best fulfill the SLS of a specific slice. In the
15 NR NRM this is described by the resource partition attribute.

16 Instantiation of a RAN sub-slice will be prepared by rigorous planning to understand to what extent deployed RAN
17 resources will be able to support RAN sub-slice SLS. Part of this procedure is to configure RAN functionality according
18 to above. With this, a default behavior of RAN is obtained that will be able to fulfill slice SLSs for most situations.
19 However, even through rigorous planning, there will be times and places where the RAN resources are not enough to
20 fulfill SLS given the default configuration. To understand how often (and where) this happens, the performance of a RAN
21 slice will continuously be monitored by SMO. When SMO detects a situation when RAN SLS cannot be fulfilled, Non-
22 RT RIC can use A1 policies to improve the situation. To understand how to utilize A1 policies and how to resolve the
23 situation, the non RT-RIC will use additional information available in SMO.

24 Take an emergency service as an example of a slice tenant. For this example, it is understood (at slice instantiation) that
25 50% of the PRBs in an area should be enough to support the emergency traffic under normal circumstances. Therefore,
26 the ratio of PRBs for the emergency users is configured to 50% as default behavior for the pre-defined group of users
27 belonging to the emergency slice. Also, QoS is also configured in CN and RAN so that video cameras of emergency users
28 get a minimum bitrate of 500 kbps.

29 Now, suppose a large fire is ongoing and emergency users are on duty. Some of the personnel capture the fire on video
30 on site. The video streams are available to the Emergency Control Command. Because of the high traffic demand in the
31 area from several emergency users (belonging to the same slice), the resources available for the Emergency slice is not
32 enough to support all the traffic. In this situation, the operator has several possibilities to mitigate the situation. Depending
33 on SLAs towards the Emergency slice compared to SLAs for other slices, the operator could reconfigure the amount of
34 PRB reserved to Emergency slice at the expense of other slices. However, there is always a risk that Emergency video
35 quality is not good enough irrespective if all resources are used for Emergency users. It might be that no video shows
36 sufficient resolution due to resource limitations around the emergency site.

37 In this situation, the Emergency Control Command decides, based on the video content, to focus on a selected video
38 stream to improve the resolution. The Emergency Control System gives the information about which users to up- and
39 down-prioritized to the e2e slice assurance function (through e.g. an Edge API) of the mobile network to increase
40 bandwidth for selected video stream(s). Given this additional information, the Non-RT RIC can influence how RAN
41 resources are allocated to different users through a QoS target statement in an A1 policy. By good usage of the A1 policy,
42 the Emergency Control Command can ensure that dynamically defined group of UEs provides the video resolution that
43 is needed.

________________________________________________________________________________________________
Copyright © 2022 by the O-RAN ALLIANCE e.V. Your use is subject to the terms of the O-RAN Adopter License Agreement in Annex ZZZ 41
O-RAN.WG1.Use-Cases-Detailed-Specification-v08.00

1 3.8.2 Entities/resources involved in the use case

2 1) Non-RT RIC:
3 a) Monitor necessary QoS related metrics from network function and other SMO functions
4 b) Send policies to near-RT RIC to drive QoS based resource optimization at RAN level in terms of expected
5 behavior.
6 2) Near-RT RIC:
7 a) Support interpretation and execution of A1 policies for QoS based resource optimization.
8 3) RAN:
9 a) Support network state and UE performance report with required granularity to SMO over O1 interface.
10 b) Support QoS enforcement based on messages from E2, which are expected to influence RRM behavior.

________________________________________________________________________________________________
Copyright © 2022 by the O-RAN ALLIANCE e.V. Your use is subject to the terms of the O-RAN Adopter License Agreement in Annex ZZZ 42
O-RAN.WG1.Use-Cases-Detailed-Specification-v08.00

1 3.8.3 Solutions

2 3.8.3.1 QoS based resource optimization

<<Uses>>
Use Case Stage Evolution / Specification
Related use
Drive QoS based resource optimization in RAN in accordance with defined
Goal
policies and configuration.
Non-RT RIC: Creates A1 policies
Near-RT RIC: Enforces A1 policies
Actors and Roles
RAN: policy enforcement
SMO: termination point for O1 interface.
All relevant functions and components are instantiated and configured
according wanted default behavior.
Assumptions A1 interface connectivity is established with Non-RT RIC.
O1 interface connectivity is established with SMO.
The default configuration will handle most situations
Network is operational with default configuration
SMO has established the data collection and sharing process, and Non-RT RIC
Pre conditions has access to this data.
Non-RT RIC analyzes the data from RAN to understand the current resource
consumption
Begins when Non-RT RIC observes that resources are close to congestion in a certain area
If needed, Non-RT RIC orders additional RAN observability, SMO configures
Step 1 (O)
additional observability over O1
Non-RT RIC evaluates RAN resource utilization for all users in a slice in specific
Step 2
area.
Non-RT RIC asks for additional information from additional SMO functionality,
Step 3
e.g. e2e slice assurance function
Non-RT RIC determines dynamic group of users for which QoS target should
Step 4
be changed
Non-RT issues A1 policy/policies with QoS target based on information from
Step 5
other SMO functionality
Non-RT RIC (through O1 observability) understands that situation of resource
Ends when constraints within the slice is resolved and the deployed policies are deleted
over A1
Exceptions FFS
Post Conditions
3 Table 3.8.3-1: QoS based resource optimization

________________________________________________________________________________________________
Copyright © 2022 by the O-RAN ALLIANCE e.V. Your use is subject to the terms of the O-RAN Adopter License Agreement in Annex ZZZ 43
O-RAN.WG1.Use-Cases-Detailed-Specification-v08.00

1
2 Figure 3.8.3-1: Flow diagram, QoS based resource optimization

3 3.8.4 Required data

4 For this use case, different kind of observability need to be reported to Non-RT RIC. First Non-RT RIC should monitor
5 resource consumption in the area. As long as resource consumption is low, the RAN scheduler will be able to give all
6 users in an area the needed resources. When resource consumption in an area increases above a threshold, the risk of that
7 the default configuration of RAN will not be enough to fulfil the requirements. At this point, the Non-RT RIC need to be
8 able to configure more detailed reporting for individual UEs that the Non-RT RIC is interested in. This detailed
9 observability should provide the Non RT RIC better insight in performance for specific users and therefore includes
10 observability of e.g. user throughput and delay. With this more detailed observability, the Non-RT RIC can understand
11 when pre-configured priorities are not enough for the scheduler to solve the problem and when additional (Non RAN)
12 information to solve the prioritization is needed.

14 3.9 Use case 9: RAN Slice SLA Assurance

15 The 3GPP standards architected a sliceable 5G infrastructure which allows creation and management of customized
16 networks to meet specific service requirements that may be demanded by future applications, services and business
17 verticals. Such a flexible architecture needs different requirements to be specified in terms of functionality, performance
18 and group of users which may greatly vary from one service to the other. The 5G standardization efforts have gone into
19 defining specific slices and their Service Level Agreements (SLAs) based on application/service type [3]. Since network
20 slicing is conceived to be an end-to-end feature that includes the core network, the transport network and the radio access
21 network (RAN), these requirements should be met at any slice subnet during the life-time of a network slice [4], especially
22 in RAN side. Exemplary slice performance requirements are defined in terms of throughput, energy efficiency, latency
23 and reliability at a high level in SDOs such as 3GPP [2] and GSMA [17]. These requirements are defined as a reference
24 for SLA/contractual agreements for each slice, which individually need proper handling in NG-RAN.

________________________________________________________________________________________________
Copyright © 2022 by the O-RAN ALLIANCE e.V. Your use is subject to the terms of the O-RAN Adopter License Agreement in Annex ZZZ 44
O-RAN.WG1.Use-Cases-Detailed-Specification-v08.00

1 Although network slicing support is started to be defined with 3GPP Release 15, slice assurance mechanisms in RAN
2 needs to be further addressed to achieve deployable network slicing in an open RAN environment. It is necessary to assure
3 the SLAs by dynamically controlling slice configurations based on slice specific performance information. Existing RAN
4 performance measurements [6] and information model definitions [5] are not enough to support RAN slice SLA assurance
5 use cases. This use case is intended to clarify necessary mechanisms and parameters for RAN slice SLA assurance.

6 3.9.1 Background and goal of the use case

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

16 3.9.2 Entities/resources involved in the use case

17 1) Non-RT RIC:
18 a) Retrieve RAN slice SLA target from respective entities such as SMO, NSSMF
19 b) Long term monitoring of RAN slice performance measurements
20 c) Training of potential ML models that will be deployed in Non-RT RIC for slow loop optimization and/or Near-
21 RT RIC for fast loop optimization.
22 d) Support deployment and update of AI/ML models into Near-RT RIC
23 e) Receive slice control/slice SLA assurance xApps from SMO
24 f) Create A1 policies based on RAN intent A1 feedback.
25 g) Send A1 policies and enrichment information to Near-RT RIC to drive slice assurance
26 h) Send O1 reconfiguration requests to SMO for slow-loop slice assurance
27 2) Near-RT RIC:
28 a) Near real-time monitoring of slice specific RAN performance measurements
29 b) Support deployment and execution of the AI/ML models from Non-RT RIC
30 c) Receive slice SLA assurance xApps from SMO
31 d) Support interpretation and execution of policies from Non-RT RIC
32 e) Perform optimized RAN (E2) actions to achieve RAN slice requirements based on O1 configuration, A1 policy,
33 and E2 reports
34 3) RAN:
35 a) Support slice assurance actions such as slice-aware resource allocation, prioritization, etc.
36 b) Support slice specific performance measurements through O1
37 c) Support slice specific performance reports through E2

________________________________________________________________________________________________
Copyright © 2022 by the O-RAN ALLIANCE e.V. Your use is subject to the terms of the O-RAN Adopter License Agreement in Annex ZZZ 45
O-RAN.WG1.Use-Cases-Detailed-Specification-v08.00

1 3.9.3 Solutions

2 3.9.3.1 Creation and deployment of RAN slice SLA assurance models and control apps

<<Uses>>
Use Case Stage Evolution / Specification
Related use
Goal Training and distribution of the model, or distribution of control apps
Actors and Roles Non-RT RIC, Near-RT RIC, SMO
All relevant functions and components are instantiated.
Assumptions
A1, O1 interface connectivity is established.
Near-RT RIC and Non-RT RIC are instantiated with A1 interface and
Pre conditions connectivity has been established between them.
O1 interface has been established between SMO and Near-RT RIC.
Begins when A RAN slice is activated.
Step 1 (M) Non-RT RIC retrieves a RAN slice SLA from SMO (NSSMF).
Non-RT RIC starts to collect performance measurements (PMs) via O1. Step 2 and 3
Examples of the PMs are CSI, PRB usage, L2 throughput, RAN latency, etc. are mandatory
Step 2a Applicable PMs are defined in [6]. in case of using
the AI/ML
model
Non-RT RIC starts to collect enrichment information (EIs) from external
applications. Examples of the external applications are public safety
Step 2b (O)
application triggering slice priority during an emergency event, or location-
based enrichment information, etc.
Non-RT RIC analyzes collected PMs and/or EIs for long term monitoring,
Step 2c
such as during the day or over the weekend.
Non-RT RIC does the model training using the collected data in step 2 and
Step 3
obtains RAN slice SLA assurance models.
In case of using the AI/ML model, Non-RT RIC deploys the trained model
Step 4a or 4b is
Step 4a internally for slow loop optimization and/or distributes it to the Near-RT RIC
Mandatory
via O2 for fast loop optimization.
In case of using the control app, the control app is deployed by SMO to Non-
Step 4b RT RIC for slow loop optimization and/or Near-RT RIC via O2 for fast loop
optimization.
Non-RT RIC receives feedback internally or from Near-RT RIC via A1 to
Step 5 (M)
update the model or control apps based on it.
Ends when A RAN slice is deactivated
Exceptions FFS
Post Conditions FFS
3 Table 3.9.3-1: Creation and deployment of RAN slice SLA assurance models and control apps

________________________________________________________________________________________________
Copyright © 2022 by the O-RAN ALLIANCE e.V. Your use is subject to the terms of the O-RAN Adopter License Agreement in Annex ZZZ 46
O-RAN.WG1.Use-Cases-Detailed-Specification-v08.00

2 Figure 3.9.3-1: Flow diagram, Creation and deployment of RAN slice SLA assurance models and control apps

________________________________________________________________________________________________
Copyright © 2022 by the O-RAN ALLIANCE e.V. Your use is subject to the terms of the O-RAN Adopter License Agreement in Annex ZZZ 47
O-RAN.WG1.Use-Cases-Detailed-Specification-v08.00

1 3.9.3.2 Slow loop RAN Slice SLA optimization

<<Uses>>
Use Case Stage Evolution / Specification
Related use
Goal Slow loop RAN Slice SLA optimization
Actors and Roles Non-RT RIC, Near-RT RIC, SMO, RAN
All relevant functions and components are instantiated.
Assumptions
A1, O1, E2 interface connectivity is established.
Near-RT RIC and Non-RT RIC are instantiated with A1 interface
connectivity being established between them.
O1 interfaces are established between SMO and Near-RT RIC, and SMO
Pre conditions
and RAN nodes.
RAN slice SLA assurance models or control apps have been deployed in
Non-RT RIC and Near-RT RIC respectively.
Begins when A RAN slice is activated
Non-RT RIC decides that RAN should be reconfigured based on long term Config update
Step 1a trends collected via O1 using PMs and/or EIs. Step 1a or 1b is
Examples of the PMs are layer 2 throughput, PRB usage, CSI, RAN latency mandatory
Non-RT RIC decides to create slice specific A1 policies based on RAN slice
SLA requirements and/or operator-defined RAN intents, A1 feedback from
Step 1b Near-RT RIC, EI from external app server and O1 based long term trends. Policy update
The policies include scope identifiers (e.g. S-NSSAI, Flow ID, Cell ID) and/or
policy statements (e.g. slice specific KPI targets).
The model or control app in Non-RT RIC requests SMO to update slice Config request
Step 2a
configuration of Near-RT RIC and/or RAN nodes through O1.
SMO sends the updated slice configuration to Near-RT RIC and/or RAN Config delivery
Step 2b nodes via O1. Examples of the slice configuration are the number of Step 2b or 2c is
allocated PRBs, number of flows, slice priorities. mandatory
Step 2c Non-RT RIC sends the updated A1 policies to Near-RT RIC. Policy delivery
Near-RT RIC and RAN nodes process and execute the updated slice Config
configuration. execution
Step 3a
Step 3a or 3b is
mandatory
Near-RT RIC receives the updated A1 policy, controls RAN nodes based on Policy
Step 3b
the A1 policy and sends the feedback to Non-RT RIC via A1. execution
Ends when A RAN slice is deactivated
Exceptions FFS
Post Conditions FFS
2 Table 3.9.3-2: Slow loop RAN Slice SLA optimization

________________________________________________________________________________________________
Copyright © 2022 by the O-RAN ALLIANCE e.V. Your use is subject to the terms of the O-RAN Adopter License Agreement in Annex ZZZ 48
O-RAN.WG1.Use-Cases-Detailed-Specification-v08.00

3 Figure 3.9.3-2: Flow diagram, Slow loop RAN Slice SLA optimization

________________________________________________________________________________________________
Copyright © 2022 by the O-RAN ALLIANCE e.V. Your use is subject to the terms of the O-RAN Adopter License Agreement in Annex ZZZ 49
O-RAN.WG1.Use-Cases-Detailed-Specification-v08.00

1 3.9.3.3 Fast loop RAN Slice SLA optimization

<<Uses>>
Use Case Stage Evolution / Specification
Related use
Goal Fast loop RAN Slice SLA optimization
Actors and Roles Non-RT RIC, Near-RT RIC, SMO, RAN
All relevant functions and components are instantiated.
Assumptions
A1, O1, E2 interface connectivity is established.
Near-RT RIC and Non-RT RIC are instantiated with A1 interface
connectivity being established between them.
O1 interfaces are established between SMO and Near-RT RIC, and SMO
Pre conditions
and RAN nodes.
RAN slice SLA assurance models or control apps have been deployed in
Near-RT RIC.
Begins when A RAN slice is activated
Non-RT RIC decides to generate a policy for Near-RT RIC slice SLA
assurance based on RAN slice SLA requirements and/or operator-defined
Step 1
RAN intents, A1 feedback from Near-RT RIC, EI from external app server
and O1 based long term trends.
Near-RT RIC receives slice specific O1 configuration and A1 policies from
SMO and Non-RT RIC respectively. The former is static and default, the
latter is dynamic, optimized and converted from slice SLA. The policies
Step 2 consist of scope identifiers (e.g. S-NSSAI, Flow ID, Cell ID) and policy
statements (e.g. slice specific KPI targets).
In case of using EIs, Near-RT RIC also receives the EIs from Non-RT RIC
via A1-EI interface.
Near-RT RIC starts to collect PMs via E2. Examples of the PMs are CSI,
Step 3 PRB usage, L2 throughput, RAN latency, etc. Applicable PMs are defined
in [6].
The model or control app in Near-RT RIC analyzes collected PMs, A1
Step 4 policies from Non-RT RIC (and optionally EIs from A1-EI interface) to guide
RAN nodes via E2 to meet the slice SLA.
Step 5 Near-RT RIC sends A1 feedback to Non-RT RIC.
A RAN slice is deactivated
FFS
FFS
2 Table 3.9.3-3: Fast loop RAN Slice SLA optimization

________________________________________________________________________________________________
Copyright © 2022 by the O-RAN ALLIANCE e.V. Your use is subject to the terms of the O-RAN Adopter License Agreement in Annex ZZZ 50
O-RAN.WG1.Use-Cases-Detailed-Specification-v08.00

1
2 Figure 3.9.3-3: Flow diagram, Fast loop RAN Slice SLA optimization

3 3.9.4 Required data

4 The measurement counters and KPIs (as defined by 3GPP and will be extended for O-RAN use cases) should be
5 appropriately aggregated by cell, QoS type, slice, etc.

6 1) Per-UE CSI

7 2) Per slice performance statistics such as PDCP throughput, PRB usage

________________________________________________________________________________________________
Copyright © 2022 by the O-RAN ALLIANCE e.V. Your use is subject to the terms of the O-RAN Adopter License Agreement in Annex ZZZ 51
O-RAN.WG1.Use-Cases-Detailed-Specification-v08.00

1 3.10 Use case 10: Multi-vendor Slices

2 This use case “Multi-vendor slices” is a case that vO-DU and vO-CU functions composing each slice is provided from
3 different vendor. In this sub section, concept, motivation and benefits of introducing “Multi-vendor slices” are explained
4 and candidate solutions are studied.

5 3.10.1 Background and goal of the use case

6 Proposed use case enables multiple slices with functions provided from multi- vendors, such as slice #1 is composed with
7 DU and CU provided from vendor A and slice #2 is composed with DU and CU provided from vendor B.

9 Figure 3.10.1-1: Multi-vendor Slices

11 When providing multiple slices, it is assumed that suitable vO-DU/scheduler and vO-CU treat each slice respectively. A
12 vendor who providing vO-DU and vO-CU function may have a strength of a customized scheduler for a certain service.
13 With accomplishment of multi-vendor circumstances, following benefits can be expected.

14 1) More flexible and time to market deployment

15 Operator can maximize options to choose suitable vO-DU/scheduler and vO-CU to offer various slice. For example,
16 some vendor has a strength of a scheduler for eMBB service and the other has a strength of scheduler for URLLC
17 service. Or, vendor A can provide vO-DU/scheduler and vO-CU suitable for URLLC earlier than vendor B,
18 therefore operator can choose vO-DU and vO-CU functions from vendor A to meet their service requirement.
19
20 Also, when operator will add a new service/slice, new functions from a new vendor can be introduced with less
21 consideration for existing vendor if multi-vendor circumstance was realized. This may lead to expand vendor’s
22 business opportunities rapidly.
23
24 2) Flexible deployment when sharing RAN equipment among operators
25 When operators want to share RAN equipment and resources, RAN vendors and their placement of each RAN
26 functions may be different. If multi-vendor circumstance was introduced, then it can relax restrictions among
27 operators to share RAN equipment and resources. This may lead to expand opportunity reaching agreement of
28 RAN sharing among operators. With expansion of RAN sharing, CAPEX and OPEX by operator will be optimized
29 and additional investment can be done more.
30
31 3) Reducing supply chain risk

32 If existing vendor providing a certain pair of vO-DU and vO-CU functions would withdraw of their market due to
33 business reason, operator can deploy new vO-DU and vO-CU functions alternatively from other vendor under this
34 multi-vendor circumstance. This can reduce a risk for operators’ business continuity.

________________________________________________________________________________________________
Copyright © 2022 by the O-RAN ALLIANCE e.V. Your use is subject to the terms of the O-RAN Adopter License Agreement in Annex ZZZ 52
O-RAN.WG1.Use-Cases-Detailed-Specification-v08.00

1 3.10.2 Entities/resources involved in the use case

2 1) SMO Multi-vendor Slice App:

3 a) Configures vO-DU and vO-CU
4 b) Configures O-RU to connect to vO-DU
5 2) Near-RT RIC:
6 a) Shares MAC related data unique for UE among vO-DUs.
7 b) Support communication of configuration parameters to RAN
8 3) E2 Nodes (vO-CU, vO-DU, O-RU):
9 a) Primary vO-DU processes SRB (Signalling Radio Bearer), DRB (Data Radio Bearer) and other vO-DU related
10 functions. Secondary vO-DU processes only DRB related functions. Note that vO-DU and vO-CU are created
11 as part of network slice creation procedure.

12 3.10.3 Solutions

13 3.10.3.1 Data transmission call flow example for Multi-vendor slices use case

<<Uses>>
Use Case Stage Evolution / Specification
Related use
Goal UE communicates on slice #1 and #2 respectively

- SMO Multi-vendor Slice App configures vO-DU and v-O-CU with radio
resource assignment (via Orchestrator) and collects KPI data.

- Near-RT RIC configures vO-DU and vO-CU for resource assignment and
Actors and Roles shares MAC related information unique for UE among vO-DUs.

- Primary vO-DU processes SRB (Signalling Radio Bearer), DRB (Data

Radio Bearer). Secondary vO-DU processes only DRB.

- All relevant functions and components are instantiated.

- Slice #1 is created over primary vO-DU and vO-CU with Logical Channel
ID #1 and #2, and slice #2 is created over secondary vO-DU and vO-CU
with Logical Channel ID #3.

Assumptions - O-RU is shared between primary vO-DU and secondary vO-DU with one
component carrier.
- CU-CP is shared between primary vO-CU-UP and secondary vO-CU-UP.
- TDD operation is assumed.
- UE tries to transmit data on slice #1 and #2.
- Slice #1 and #2 are created and activated on primary vO-DU, vO-CU and
secondary vO-DU, vO-CU respectively
- Slice #1 is tied with Scheduling Request Resource 1 and Logical Channel
ID #1 and #2, and slice #2 is tied with Scheduling Request Resource 2
Pre conditions and Logical Channel ID #3
- Primary vO-DU and secondary vO-DU know which timing/resource block
they can utilize on for slice #1 and #2 respectively by direction from SMO
via O1 interface.
- UE has already performed RACH procedure with primary vO-DU.
UE tries to perform registration procedure with RRC Connection Request
Begins when
message.
Step 1 (M) [UE performs registration procedure]

________________________________________________________________________________________________
Copyright © 2022 by the O-RAN ALLIANCE e.V. Your use is subject to the terms of the O-RAN Adopter License Agreement in Annex ZZZ 53
O-RAN.WG1.Use-Cases-Detailed-Specification-v08.00

UE sends RRC Connection Request message to primary vO-DU and vO-CU

through O-RU. Primary vO-CU and vO-DU responds with RRC Connection
Setup. UE sends RRC connection Setup Complete message.
Primary vO-DU sends initial RRC message and shared information such as C-
RNTI to near RT-RIC. Near RT-RIC determines to transfer it to secondary vO-
DU over E2 interface. Other registration procedure is performed.

[PDU session establishment]

UE starts PDU session establishment procedure with PDU session
establishment request message with primary vO-DU and vO-CU.
Step 2 (M)
UE initiates PDU session establishment procedure with S-NSSAI 2 for Slice #2
via primary vO-DU. UE Context Modification is made at secondary vO-DU.

[U-plane data transmission between primary vO-DU and O-RU] ORAN-

At allocated timing/resources, primary vO-DU sends Scheduling Command WG4.CUS.0-
message to O-RU to start transfer and receive DL and UL Data. v02.00
UE sends Scheduling Request message on PUCCH with Scheduling Request “Figure 6‑5: C-
Step 3 (M) Resource 1 to primary vO-DU over Open fronthaul. Plane and U-
Primary vO-DU responds with UL Grant message to the UE. Plane message
transfer
procedure (DL &
UL shown)”
[Buffer notification and transmission user data]
UE notices buffer with Buffer Status Request message to primary vO-DU.
Primary vO-DU acknowledges with UL Grant message.
Step 4 (M)
UE sends user data on PUSCH with Logical Channel ID #1 and #2
Primary vO-DU acknowledges with Ack or Nack.
UE repeats step 3 until buffer becomes empty.
[U-plane data transmission between secondary vO-DU and O-RU] ORAN-
At allocated timing/resources, secondary vO-DU sends Scheduling Command WG4.CUS.0-
message to O-RU to start transfer and receive DL and UL Data. v02.00
UE sends Scheduling Request message on PUCCH with Scheduling Request “Figure 6‑5: C-
Step 5 (M) Resource 2 to secondary vO-DU over Open fronthaul. Secondary vO-DU Plane and U-
responds with UL Grant message to the UE. Plane message
transfer
procedure (DL &
UL shown)”
[Buffer notification and transmission user data]
UE notices buffer with Buffer Status Request message to secondary vO-DU.
Secondary vO-DU acknowledges with UL Grant message.
Step 6 (M)
UE sends user data on PUSCH with Logical Channel ID #3.
Secondary vO-DU acknowledges with Ack or Nack.
UE repeats step 5 until buffer becomes empty.
[Collect Data]
Step 7 (M) RAN related data from RAN nodes are collected at SMO Collector via O1
interface.
Ends when UE finishes data transmission until buffer becomes empty.
Exceptions None identified.
Post Conditions None identified
1 Table 3.10.3.1-1: Data transmission call flow example for Multi-vendor slices use case

________________________________________________________________________________________________
Copyright © 2022 by the O-RAN ALLIANCE e.V. Your use is subject to the terms of the O-RAN Adopter License Agreement in Annex ZZZ 54
O-RAN.WG1.Use-Cases-Detailed-Specification-v08.00

1
2 Figure 3.10.3.1-1: Data transmission call flow example for Multi-vendor slices use case – Part 1 of 2

________________________________________________________________________________________________
Copyright © 2022 by the O-RAN ALLIANCE e.V. Your use is subject to the terms of the O-RAN Adopter License Agreement in Annex ZZZ 55
O-RAN.WG1.Use-Cases-Detailed-Specification-v08.00

1
2 Figure 3.10.3.1-2: Data transmission call flow example for Multi-vendor slices use case – Part 2 of 2

3 3.10.3.2 Data transmission call flow example for RAN sharing use case

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

________________________________________________________________________________________________
Copyright © 2022 by the O-RAN ALLIANCE e.V. Your use is subject to the terms of the O-RAN Adopter License Agreement in Annex ZZZ 56
O-RAN.WG1.Use-Cases-Detailed-Specification-v08.00

Goal UE communicates on secondary vO-DU and vO-CU with PLMN #2

- SMO Multi-vendor Slice App configures vO-DU and v-O-CU with radio
resource assignment (via Orchestrator) and collects KPI data

- Near-RT RIC configures vO-DU and vO-CU for resource assignment and
Actors and Roles shares MAC related information unique for UE among vO-DUs.

- Primary vO-DU processes SRB (Signalling Radio Bearer), DRB (Data

Radio Bearer). Secondary vO-DU processes only DRB.

- All relevant functions and components are instantiated.

- PLMN #1 is assigned to primary vO-DU and vO-CU, and PLMN #2 is
assigned to secondary vO-DU and vO-CU respectively.
- O-RU is shared between primary vO-DU and secondary vO-DU with one
Assumptions component carrier.
- CU-CP is shared between primary vO-CU-UP and secondary vO-CU-UP.
- TDD operation is assumed.
- UE tries to transmit data with PLMN #2.
- PLMN #1 and #2 are assigned to primary vO-DU, vO-CU and secondary
vO-DU, vO-CU respectively
- Primary vO-DU and vO-CU advertise PLMN #1 and #2 over the air.
Pre conditions - Primary vO-DU and secondary vO-DU know which timing/resource block
they can utilize on for PLMN #1 and #2 respectively by direction from SMO
via O1 interface.
- UE has already performed RACH procedure with primary vO-DU.
UE tries to perform registration procedure with RRC Connection Request
Begins when
message.
[UE performs registration procedure with PLMN #2]
UE sends RRC Connection Request message to primary vO-DU and vO-CU
through O-RU. Primary vO-CU and vO-DU responds with RRC Connection
Setup. UE sends RRC connection Setup Complete message with PLMN#2 in
selected PLMN-Identity.
Step 1 (M)
Primary vO-DU sends initial RRC message with PLMN-Identity and shared
information such as C-RNTI to near RT-RIC. Near RT-RIC determines to
transfer it to secondary vO-DU over E2 interface. Other registration procedure
is performed through secondary vO-DU.

[PDU session establishment]

UE starts PDU session establishment procedure with PDU session
Step 2 (M)
establishment request message through secondary vO-DU and vO-CU.

[U-plane data transmission between secondary vO-DU and O-RU] ORAN-

At allocated timing/resources, secondary vO-DU sends Scheduling Command WG4.CUS.0-
message to O-RU to start transfer and receive DL and UL Data. v02.00
UE sends Scheduling Request message on PUCCH with Scheduling Request “Figure 6‑5 : C-
Step 3 (M) Resource 2 to secondary vO-DU over Open fronthaul. Plane and U-
Secondary vO-DU responds with UL Grant message to the UE. Plane message
transfer
procedure (DL &
UL shown)”
[Buffer notification and transmission user data]
UE notices buffer with Buffer Status Request message to secondary vO-DU.
Secondary vO-DU acknowledges with UL Grant message.
Step 4 (M)
UE sends user data on PUSCH with Logical Channel ID #2.
Secondary vO-DU acknowledges with Ack or Nack.
UE repeats step 3 until buffer becomes empty.
[Collect Data]
Step 5 (M) RAN related data from RAN nodes are collected at SMO Collector via O1
interface.
Ends when UE finishes data transmission until buffer becomes empty.

________________________________________________________________________________________________
Copyright © 2022 by the O-RAN ALLIANCE e.V. Your use is subject to the terms of the O-RAN Adopter License Agreement in Annex ZZZ 57
O-RAN.WG1.Use-Cases-Detailed-Specification-v08.00

Exceptions None identified.

Post Conditions None identified
1 Table 3.10.3.2-1: Data transmission call flow example for RAN sharing use case

3 Figure 3.10.3.2-1: Data transmission call flow example for RAN sharing use case

4 3.10.4 Required data

5 The measurement counters and KPIs (as defined by 3GPP and will be extended for O-RAN use cases) should be
6 appropriately aggregated by cell, QoS type, slice, etc.

7 1) Per-UE CSI
8 2) Per slice performance statistics such as PDCP throughput, PRB usage

9 3.11 Use case 11: Dynamic Spectrum Sharing

10 This use case provides the background, motivation, and requirements to realize Dynamic Spectrum Sharing (DSS) over
11 the ORAN architecture. This is to enable operators to adapt radio resource allocation policies and control to dynamically
12 share radio spectrum between 4G and 5G networks.

________________________________________________________________________________________________
Copyright © 2022 by the O-RAN ALLIANCE e.V. Your use is subject to the terms of the O-RAN Adopter License Agreement in Annex ZZZ 58
O-RAN.WG1.Use-Cases-Detailed-Specification-v08.00

1 3.11.1 Background and goal of the use case

2 As we transition from 4G to 5G, the spectral resources used for 5G deployment is a key consideration and this situation
3 varies from one operator to another. Though, new C-band resources between 3-6 GHz and mmWave bands have been
4 acquired by operators, these bands suffer from great propagation and penetration loss, limiting their coverage to those
5 users close to the cell, this situation worsens in the UL as the UE device is power constrained. A cost-effective way to
6 address this is the 5G deployment on lower bands (i.e., below 2GHz), which are also used in 4G LTE deployments today.
7 Operating on lower bands along with non-standalone mode of 5G deployment helps to cover large geography, enables
8 seamless mobility between 4G and 5G while being sensitive to overall cost of deployment. In addition, DSS offers the
9 advantage of dynamically sharing the available spectrum adapting to the varying workloads of the 4G and 5G network.

10 DSS is compelling considering the need for operators to dynamically share already deployed spectral resources between
11 LTE and NR devices without degrading the QoE of the current 4G subscribers while offering the same level of coverage
12 and necessary QoS to NR devices, under the assumption that the two networks will co-exist in the near term. The objective
13 of this use case is to propose DSS in the context of the ORAN architecture, specifically to realize it as an application in
14 the RIC framework.

15 This would particularly benefit vRAN implementations when the 4G/5G CU/DU are from different vendors and one could
16 leverage RAN data over O-RAN’s framework for traffic prediction, DSS related resource management and conduct
17 control functions. Towards this, the intelligent control functions are identified, which can be realized as a DSS application
18 to augment the L3/L2/L1 control functions defined as part of LTE-NR coexistence in Rel-15/16 [3][10].

19 In Figure 3.11.1-1, the architectural context is set for this discussion. DSS enables 4G and 5G UEs to operate over the
20 same spectrum identified as X (typically low band), while 5G itself could operate on new bands Y (typically high band)
21 not used by current 4G deployment. In a typical setting, Y would offer higher capacity, low latency and smaller coverage,
22 while X would be used to offer reasonable capacity along with larger coverage. 3GPP specifications offers DSS support
23 over X2/Xn interface to enable dynamic sharing of the spectrum resource in addition to the L2/L1 adaptation for 5G-NR
24 to co-exist with LTE.

25 Considering the scenario of incremental deployment - in the 5G NSA mode, the 5G UE is required to have dual
26 connectivity capability and be able to connect to eNBs on LTE bands for control plane requirements and user plane
27 connectivity towards the LTE and/or 5G depending on deployment requirements. In the scenario where gNB only operates
28 on 5G C or mmWave bands, the sharing of the LTE frequency band between 4G and 5G UEs can be solely fulfilled by
29 eNB MAC scheduler, as the UE is expected to be dual stacked. While, if the gNB is required to operate on lower LTE
30 bands as well, then spectral sharing needs to be coordinated between the LTE and 5G schedulers.

31 When DSS is enabled in the SA mode, 5G UE would be capable of operating on lower LTE bands (below 2GHz), C and
32 mmWave bands and connects only to the gNBs. The sharing of the LTE bands between LTE and 5G data channels are
33 achieved by both 4G scheduler and 5G scheduler using resource management and interference mitigation functions in the
34 RIC between them.

35 The use case proposes to conduct DSS related policy, configuration, resource management and control functions using
36 the non-RT and near-RT functions over open interfaces proposed by ORAN.

37 An abstracted view of how DSS application can be realized using the Non-Real Time and Near-Real Time RIC
38 components is shown in Figure 3.11.1-2. The DSS over RIC can be realized as multiple applications considering its
39 multiple optimization and operational objectives. One possible logical breakdown is as a traffic prediction and resource
40 management application (DSS-App) managing the shared spectrum resource adapting to dynamic 4G and 5G specific
41 workload requirements in various local contexts, and another application (RAT-App) to configure, control and monitor
42 DSS related functions in the CU/DU corresponding to the LTE and 5G cells. The DSS-App engineers at the non-RT RIC
43 level translates the global DSS policies based on workload requirements for a region and time-of-day to spectrum sharing
44 policies such as max/min bandwidth threshold at a local level (e.g. edge or central office). The RAT-App at the non-RT
45 RIC level also translates the DSS-App’s resource policies to RAT specific configuration and policies at the near-RT RIC

________________________________________________________________________________________________
Copyright © 2022 by the O-RAN ALLIANCE e.V. Your use is subject to the terms of the O-RAN Adopter License Agreement in Annex ZZZ 59
O-RAN.WG1.Use-Cases-Detailed-Specification-v08.00

1 and the CU/DU entities. The DSS-App at the near-RT RIC uses the data collected by the RAT-app to make dynamic
2 resource sharing decisions that are enforced by the RAT-app using the E2 control APIs.

5 Figure 3.11.1-1: RIC Based DSS Architecture

7 Figure 3.11.1-2: RIC Based DSS Realization

9 The main goal of the non-RT DSS-App is to provide long-term scheduling policy to 4G and 5G scheduler considering
10 business, user, spatial and temporal workload factors.

11 The main functionality of non-RT RAT-App is to translate the global DSS policies from non-RT DSS-App to RAT
12 specific policies to the RAT-App in the near-RT RIC over A1.

13 The main functionalities of the near-RT DSS-App include policy translation between non-RT DSS-App to RAT specific
14 configuration to the near-RT RAT-App. Furthermore, it is actively involved in closed loop decision using the KPIs from
15 the RAN adapting to the needs of the 4G and 5G cells.

16 The main functionality of near-RT RAT-App is to perform RAT specific configuration, control and data subscription over
17 E2 interface with RAN (CU/DU components).

________________________________________________________________________________________________
Copyright © 2022 by the O-RAN ALLIANCE e.V. Your use is subject to the terms of the O-RAN Adopter License Agreement in Annex ZZZ 60
O-RAN.WG1.Use-Cases-Detailed-Specification-v08.00

1 3.11.2 Entities/resources involved in the use case

2 1) Non-RT RIC:
3 a) Receive SMO’s DSS specific service requirement for the RAN and translate them into resource sharing policies.
4 b) Provide long-term policies in terms of scheduling guidance to 4G and 5G scheduler over A1 to near-RT RIC,
5 considering business, user, spatial and temporal workload factors, policies related to expected performance and
6 actions when it deviates based on KPIs from the 4G and 5G network.
7 c) Develop and train AI/ML models with the help of SMO functions for the near-RT RIC to predict the short-
8 term traffic demand for 4G and 5G network based on near real time metrics from RAN. Deployment of these
9 ML model over O1 and xApps over O2 to the near-RT RIC.
10 d) Receive policy feedback from near-RT RIC and update policy and re-train ML models whenever required.
11 2) Near-RT RIC:
12 a) Support deployment, execution and ability to update DSS xApps from non-RT RIC.
13 b) Support interpretation of policies related to RAT specific resource allocation.
14 c) Translate RAT specific SLA policy to configuration, control and data subscription over E2 interface to E2
15 Nodes (O-CU, O-DU).
16 d) Share resource allocation performance and policy feedback report with non-RT RIC for further evaluation and
17 optimization over O1/A1.
18 3) RAN:
19 a) Support discovery of DSS related configuration of E2 nodes over E2 interface.
20 b) Share the data collection over O1 interface.
21 c) Support resource management related metrics collection over E2 interface.
22 d) Support control and policy enforcement from near-RT RIC over E2 interface.

________________________________________________________________________________________________
Copyright © 2022 by the O-RAN ALLIANCE e.V. Your use is subject to the terms of the O-RAN Adopter License Agreement in Annex ZZZ 61
O-RAN.WG1.Use-Cases-Detailed-Specification-v08.00

1 3.11.3 Solutions

2 3.11.3.1 Dynamic Spectrum Sharing for 4G and 5G

<<Uses>>
Use Case Stage Evolution / Specification
Related use
Enable operators to dynamically share spectrum in the existing 4G deployment
Goal with 5G systems, based on the dynamic loads of both networks and resource
sharing policies.
Non-RT RIC: spectrum resource sharing policy function
Near-RT RIC: executes resource sharing models and algorithms, translating
RAT specific policy to configuration, control and data subscription over E2
Actors and Roles
interface with RAN
RAN: executes resource sharing enforcement rules and policies, collects and
reports RAN statistics and performance over E2 and O1
All relevant functions and components are instantiated. DSS xApps are
deployed over O1 with initial configuration
Assumptions A1, E2 interface connectivity is established with non-RT RIC and RAN
respectively.
Data report, policy and control subscription established on E2 interface
Network is operational.
SMO has established the data collection and sharing interface with non-RT RIC.
Pre conditions Non-RT RIC analyzes the historical data from RAN, develops, trains with help
of SMO functions and deploys the relevant AI/ML models or algorithm as xApps
to the near-RT RIC
Begins when Operator specified trigger condition or event is detected.
Near-RT RIC collects DSS related RAN function capabilities and configuration
Step 1 (M)
parameters from RAN over E2 interface
Non-RT RIC communicates DSS relevant policies to the near-RT RIC over the
Step 2 (M)
A1 interface.
Near-RT RIC communicates RAT specific DSS relevant configuration, control
Step 3 (M)
policies to RAN over the E2 interface.
RAN deploys the configuration and control policies received from the near-RT
Step 4 (M)
RIC over the E2 interface.
Near-RT RIC collects relevant observability data from RAN, executes xApp and
Step 5 (M) outputs the optimal resource allocation and cell level resource scheduling
decisions to RAN over E2 and policy feedback to non-RT RIC over A1
RAN deploys the updated control policies received from the near-RT RIC over
Step 6 (M) the E2 interface and continues reporting data to SMO over O1 and E2 as
configured
Non-RT RIC adjusts the policy based on PM data from SMO and feedback from
Step 7 (M)
near-RT RIC
Step 8 (M) Non-RT RIC updates the resource sharing policy to near-RT RIC over A1
Step 9 (O)
Non-RT RIC re-trains/updates the AI/ML model with new data and performance,
and deploys the new model or new model configurations to near-RT RIC
Ends when Operator specified trigger condition or event is satisfied
Exceptions None identified
Non-RT RIC monitors loads and relevant KPI performance metrics of
eNB/gNB to observe the resource sharing efficiency and sets up new policies
based on the metrics and business needs.
Post Conditions
Near-RT RIC executes the resource sharing model or algorithm. RAN operates
with the scheduling guidance from RIC and reports performance data to RIC
3 Table 3.11.3-1: Dynamic Spectrum Sharing for 4G and 5G

________________________________________________________________________________________________
Copyright © 2022 by the O-RAN ALLIANCE e.V. Your use is subject to the terms of the O-RAN Adopter License Agreement in Annex ZZZ 62
O-RAN.WG1.Use-Cases-Detailed-Specification-v08.00

1
2 Figure 3.11.3-1: Flow diagram, Dynamic Spectrum Sharing for 4G and 5G

4 3.11.4 Required data

5 Multiple observability data from RAN need to be reported to SMO, non-RT RIC and near-RT RIC for DSS to operate.

Category Parameters/Measurements RAT Source/Inte Reference

rface

4G/5G DSS Geography location (e.g., cell site) 4G/5G External TBD
configuration and server
operation parameters

DSS modality (static, semi-static (MBSFN), 4G/5G E2 TS 38.211

dynamic (sub-frame level) )
TS 38.213

Cell configuration information (e.g., 4G/5G E2 TS 36.423

FDD/TDD, Band, Signaling/RS Allocation TS 38.211
Bitmap) TS 38.213

4G/5G scheduling Physical resource block 4G/5G E2 TS 36.423

information used/reserved/requested/blocked Bitmap
information

4G/5G cell load Number of active UEs (total, UL/DL, per 4G E2 and O1 TS 36.314
statistics QCI)

________________________________________________________________________________________________
Copyright © 2022 by the O-RAN ALLIANCE e.V. Your use is subject to the terms of the O-RAN Adopter License Agreement in Annex ZZZ 63
O-RAN.WG1.Use-Cases-Detailed-Specification-v08.00

Mean/Max number of Active UEs (DL/UL, 5G E2 and O1 TS 38.314

total, per DRB(mapped 5QI)) TS 32.425

Traffic demand/buffer size (Total, per 4G/5G E2 and O1 TBD

QCI/5QI)

PRB usage (DL, UL, Total, per QCI/5QI) 4G/5G E2 and O1 TS 36.314
TS 36.423
TS 28.552

PDCCH CCE usage 4G/5G E2 and O1 TS 36.423

RRC connection number 5G E2 and O1 TS 28.552

TS 32.425

4G/5G QoS QoS Classes 4G/5G E2 TS 23.501 (5G)

configuration and
parameters TS 36.300,
TS 23.401,

TS 23.203(4G)

Slice types 5G E2 TS 23.501

UE performance Scheduled IP Throughput (DL, UL, per QCI) 4G E2 and O1 TS 36.314

statistics

Data Volume (DL/UL per CQI) 4G E2 and O1 TS 36.314

UL/DL PDCP SDU Data Volume 5G E2 and O1 TS 28.552

PDCP Packet Delay DL/UL per CQI/QCI 4G/5G E2 and O1 TS 36.314(4G),

5G(TBD)

UE mobility RSRP/RSRQ/SINR/RSSI 4G/5G E2 and O1 TS 36.214

statistics TS 36.331

UE Location Information 45/5G External TBD

Server

UE Capability 4G/5G E2 and O1 TS 36.331

1 Table 3.11.4-1: Required data for DSS use case

3 3.12 Use case 12: NSSI Resource Allocation Optimization

4 This use case provides the background, motivation, description, and requirements for the NSSI resource allocation
5 optimization use case, allowing operators to optimize the allocation resources to NSSI(s) with wide range service
6 requirements.

7 3.12.1 Background and goal of the use case

8 5G networks are becoming increasingly complex with the densification of millimeter wave small cells, and various new
9 services, such as eMBB (enhanced Mobile Broadband), URLLC (Ultra Reliable Low Latency Communications), and
10 mMTC (massive Machine Type Communications) that are characterized by high speed high data volume, low speed ultra-
11 low latency, and infrequent transmitting low data volume from huge number of emerging smart devices, respectively. It
12 is a challenging task for 5G networks to allocate resources dynamically and efficiently among multiple network nodes to

________________________________________________________________________________________________
Copyright © 2022 by the O-RAN ALLIANCE e.V. Your use is subject to the terms of the O-RAN Adopter License Agreement in Annex ZZZ 64
O-RAN.WG1.Use-Cases-Detailed-Specification-v08.00

1 support the various services. However, as eMBB, URLLC, and mMTC services in 5G are typically realized as NSI
2 (Network Slice instance). Therefore, the resources allocated to NSSI (Network Slice Subnet Instance) to support the O-
3 RAN nodes can be optimized according the service requirements.

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

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

22 Figure 3.12.1-1 shows the NSSI resource allocation Optimization on the Non-RT RIC, and may consist of the following
23 steps:

24 1) Monitoring: monitor the radio network(s) by collecting data via the O1 interface, for example including the following
25 performance measurements that are measured on per S-NSSAI (TS 28.552 [6]):
26 - DL PRB used for data traffic (TS 28.552 [6] Clause 5.1.1.2.5)
27 - UL PRB used for data traffic (TS 28.552 [6] Clause 5.1.1.2.7)
28 - Average DL UE throughput in gNB (TS 28.552 [6] Clause 5.1.1.3.1)
29 - Average UL UE throughput in gNB (TS 28.552 [6] Clause 5.1.1.3.3)
30 - Number of PDU Sessions requested to setup (TS 28.552 [6] Clause 5.1.1.5.1)
31 - Number of PDU Sessions successfully setup (TS 28.552 [6] Clause 5.1.1.5.2)
32 - Distribution of DL UE throughput in gNB (TS 28.552 [6] Clause 5.1.1.3.2)
33 - Distribution of DL UE throughput in gNB (TS 28.552 [6] Clause 5.1.1.3.4)
34 - Number of DRBs successfully setup (TS 28.552 [6] Clause 5.1.1.10.2)
35 Note 1: The above measurements are indicative and are subject to change based on the progress of this use case
36 in O-RAN
37 Note 2: Monitoring of the measurements related to O-Cloud (or transport network) that may be required for
38 NSSI resource optimization is FFS

39 2) Analysis & Decision: consisting of the following steps:

40 2a. Utilize AI/ML models to analyze the measurements and predict the future traffic demand, including the
41 RRMPolicyRatio IOC limits, for each NSSI for a given time and location.

________________________________________________________________________________________________
Copyright © 2022 by the O-RAN ALLIANCE e.V. Your use is subject to the terms of the O-RAN Adopter License Agreement in Annex ZZZ 65
O-RAN.WG1.Use-Cases-Detailed-Specification-v08.00

1 2b. Determine the actions needed to add or reduce the resources (e.g. capacity, VNF resources, slice subnet
2 attributes (TS 28.541 [5], etc.) for the RAN NFs (E2 Nodes included in the respective NSSI at the given time,
3 and location
4 3) Execution: execute the actions to reallocate the NSSI resources that include:

5 3a. Re-configure the NSSI attributes, including RRMPolicyRatio IOC (TS 28.541 [5]) via the OAM Functions
6 in SMO which uses O1 interface to configure the E2 Nodes.
7 3b. Update the cloud resources via the O2 interface
8

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
9
10 Figure 3.12.1-1: The realization of NSSI resource allocatıon optimization over Non-RT RIC

11 For association of resource quota policies for the RAN NFs (E2 Nodes) per NSSI or group of NSSIs, currently 3GPP
12 28.541 [5] defines RRMPolicyRatio IOC (realization of abstract IoC RRMPolicy_) which allows definition of maximum,
13 minimum and dedicated values for the percentage of resources to be used per RRMPolicyMemberList – that is group of
14 members with specific plmnID and sNSSAI (applied at NRCellDU, NRCellCU, GNBDUFunction, GNBCUCPFunction
15 or in GNBCUUPFunction) via RRMPolicyManagedEntity.

16 3.12.2 Entities/resources involved in the use case

17 1) SMO:

18 a) Pre-provision the default NSSI resource quota policy as constraint for NSSI resource allocation optimization.
19 This information is optionally used by the Non-RT RIC in case the resource quota that needs to be allocated
20 per slice is not specified during the slice creation and for conflict resolution at the time of resource scarcity,
21 2) Non-RT RIC:
22 a) Collect the performance measurements related to NSSI resource usage from the O-RAN nodes via the O1
23 interface.
24 b) Train the AI/ML model based on the analysis of historical performance measurements, to predict of the traffic
25 demand patterns of NSSI at different times and locations.

________________________________________________________________________________________________
Copyright © 2022 by the O-RAN ALLIANCE e.V. Your use is subject to the terms of the O-RAN Adopter License Agreement in Annex ZZZ 66
O-RAN.WG1.Use-Cases-Detailed-Specification-v08.00

1 c) Determine the time/date and locations (i.e. which O-RAN nodes) to add or reduce the resources (e.g. capacity,
2 VNF resources, slice subnet attributes (TS 28.541 [5]), RRMPolicyRatio IOC, etc.) for a given NSSI based on
3 inference.
4 d) Perform the following action(s) to optimize the NSSI resource allocation, at the time determined by the model.
5 i. Re-configure the NSSI attributes via the O1 interface
6 ii. Update the cloud resources via the O2 interface
7 3) RAN Nodes (O-CU-CP, O-CU-UP, O-DU, O-RU):
8 a) Support the performance measurement collection with required granularity over O1 interface.
9 b) Support the configuration related to the NSSI resource allocation update over O1 interface.

________________________________________________________________________________________________
Copyright © 2022 by the O-RAN ALLIANCE e.V. Your use is subject to the terms of the O-RAN Adopter License Agreement in Annex ZZZ 67
O-RAN.WG1.Use-Cases-Detailed-Specification-v08.00

1 3.12.3 Solutions

2 3.12.3.1 NSSI Resource Allocation Optimization

<<Uses>>
Use Case stage Evolution/Specification
Related use
Goal To automatically optimize the NSSI resource allocation by leveraging the AI/ML
model that was trained via the analysis of performance measurements collected
from the RAN nodes.
Actors and Roles SMO : Pre-Provision the default resource quota policy as constraint for resource
allocation optimization and monitor runtime context change
Non-RT RIC: analysis of performance measurements and AI/ML model training
RAN nodes (O-CU-CP, O-CU-UP, O-DU, O-RU): performance measurements
collection and configuration changes execution
O-Cloud M&O: the cloud resources modification via the O2 interface
OAM Functions: Part of SMO which manages the O1 based OAM functionality
O-Cloud : Manages virtualization infrastructure and virtualized resources
Assumptions - All relevant functions and components are instantiated.
- Non-RT RIC is able to receive performance measurements from RAN nodes via
the O1 interface.
Pre-conditions - RAN is operational.
- OAM Function is pre-provisioned with default NSSI resource quota policy - Non-
RT RIC has been collecting the RAN performance measurements from RAN nodes.
Begins when An AI/ML model has been trained based on the analysis of performance
measurements predict of the traffic demand patterns of NSSI at different times and
locations, resource quora per slice.
Step 1 (M) Non-RT RIC collects the RAN performance measurements from RAN nodes
Step 2 (M) i. Non-RT RIC utilizes the AI/ML models to analyze the measurements and predict
future the traffic demand for each NSSI for a given time and location.

ii. Non-RT RIC determines the action based on model inference to update the NSSI
resources that may include the following information:
a) the time/date,
b) locations (e.g. gNB ID),
c) NSSI ID,
d) slice subnet attributes,
e) VNF resources update (e.g. scaling in/out)
f) NSSI resource quota policy to be enforced per slice over O1 interface
Step 3 (M) Non-RT RIC executes the action at the time determined by the model inference by
performing the following operations:
a) re-configure the slice subnet attributes, including RRMPolicyRatio IOC (TS
28.541 [5]) via the OAM Functions in SMO which uses O1 interface to configure
the E2 Nodes
b) request O-Cloud M&O to update the O-Cloud resources via the O2 interface.

The execution of these steps is carried out by SMO based on the recommendation
of the Non-RT RIC
Ends when All the steps identified above are successfully completed.
Exceptions One of the steps identified above fails.
Post-conditions Near-RT RIC continues monitoring the NSSI resource usages.
3 Table 3.12.3-1: NSSI Resource Allocation Optimization

________________________________________________________________________________________________
Copyright © 2022 by the O-RAN ALLIANCE e.V. Your use is subject to the terms of the O-RAN Adopter License Agreement in Annex ZZZ 68
O-RAN.WG1.Use-Cases-Detailed-Specification-v08.00

2 Figure 3.12.3-1: Flow diagram, NSSI Resource Allocation Optimization

3 3.12.4 Required data

4 The measurement counters, as defined by 3GPP TS 28.552 [6], which are measured on per S-NSSAI include:

5 - DL PRB used for data traffic (TS 28.552 [6] Clause 5.1.1.2.5)
6 - UL PRB used for data traffic (TS 28.552 [6] Clause 5.1.1.2.7)
7 - Average DL UE throughput in gNB (TS 28.552 [6] Clause 5.1.1.3.1)
8 - Average UL UE throughput in gNB (TS 28.552 [6] Clause 5.1.1.3.3)
9 - Number of PDU Sessions requested to setup (TS 28.552 [6] Clause 5.1.1.5.1)
10 - Number of PDU Sessions successfully setup (TS 28.552 [6] Clause 5.1.1.5.2)
11 - Distribution of DL UE throughput in gNB (TS 28.552 [6] Clause 5.1.1.3.2)
12 - Distribution of DL UE throughput in gNB (TS 28.552 [6] Clause 5.1.1.3.4)
13 - Number of DRBs successfully setup (TS 28.552 [6] Clause 5.1.1.10.2)

________________________________________________________________________________________________
Copyright © 2022 by the O-RAN ALLIANCE e.V. Your use is subject to the terms of the O-RAN Adopter License Agreement in Annex ZZZ 69
O-RAN.WG1.Use-Cases-Detailed-Specification-v08.00

1 Note: The above measurements are indicative and are subject to change based on the progress of this use case
2 in O-RAN. The Monitoring of the measurements related to O-Cloud (or transport network) that may be required
3 for NSSI resource optimization is FFS
4

5 3.13 Use case 13: Local Indoor Positioning in RAN

6 This use case provides the background and motivation for the O-RAN architecture to support local indoor positioning.

7 3.13.1 Background and goal of the use case

8 Real-time indoor positioning based on cellular network has aroused attention with the development of 5G vertical
9 industries, individuals and operators. NR positioning is introduced by 3GPP Rel.16. The location management function
10 (LMF) resides in core network request the NG-RAN node to report positioning measurements, which is used by LMF to
11 compute the location of UE. The messages between LMF and the NG-RAN need the AMF to route transparently. However,
12 this long route messages between the NG-RAN node and centralized LMF may suffer network jitters and leads to un-
13 real-time UE location results.

14 The main objective is to ensure local positioning be supported within the O-RAN architecture and its open interfaces. In
15 the context of O-RAN architecture, the positioning function can be deployed as a positioning xApp in the Near-RT RIC.
16 The positioning xApp computes the UE location and optional velocity based on the positioning measurement obtained
17 via the E2 interface. The local indoor positioning results can be acquired via positioning xApp to support positioning
18 applications (e.g., indoor navigation, electric security fence, etc.).

19 3.13.2 Entities/resources involved in the use case

20 5) Non-RT RIC:
21 a) Retrieve necessary positioning-related indicators (e.g. RSSI, labeled user location by manual or by minimal
22 drive test, etc.) from positioning measurement report or network level measurement report or enrichment
23 information from SMO (may acquire data from application). The data is for constructing/training relevant
24 AI/ML model that will be deployed in Near-RT RIC to assist in the Position Computation function.
25 b) Training of potential ML models for real-time positioning optimization, which may be used to compute the
26 position, correct positioning errors, and predict motion.
27 c) Send policies/intents to Near-RT RIC to drive the positioning optimization at RAN level.
28 6) Near-RT RIC:
29 a) Support selection of positioning algorithms (e.g., according to QoS requirements, etc.).
30 b) Support the calculation of positioning results based on the measurements from RAN.
31 c) Support update of AI/ML models from Non-RT RIC.
32 d) Support execution of the AI/ML models from Non-RT RIC, e.g., positioning result calculation.
33 e) Sending positioning results to Non-RT RIC for evaluation and optimization.
34 7) RAN:
35 a) Support positioning related measurement report over E2 interface.
36 b) Support positioning related measurement report over O1 interface.
37 8) Application Server:
38 a) Request/subscribe RAN analytics information from Near-RT RIC.

________________________________________________________________________________________________
Copyright © 2022 by the O-RAN ALLIANCE e.V. Your use is subject to the terms of the O-RAN Adopter License Agreement in Annex ZZZ 70
O-RAN.WG1.Use-Cases-Detailed-Specification-v08.00

1 b) Support positioning related enrichment information (e.g. labeled user location by manual or by minimal drive
2 test, etc.) to SMO.

3 3.13.3 Solutions

4 3.13.3.1 Local Indoor Positioning in RAN (1)

<<Uses>>
Use Case Stage Evolution / Specification
Related use
Goal Expose positioning results to external applications.
Actors and Roles Near-RT RIC, SMO, application server
Assumptions All relevant functions and components are instantiated.
Pre conditions Editor’s Note: security related procedure is FFS.
The application server wants to request/subscribe RAN positioning
Begins when
results of target UE
Application server sends positioning request of target UE to Near-RT
Step 1 (M) RIC, or subscribes positioning results from Near-RT RIC to get periodic
or event triggered position reporting.
Near-RT RIC receives the request or subscription from application
server, and requests or subscribes measurements to RAN through E2
Step 2 (M)
interface. The Near-RT RIC selects the positioning algorithm based on
the request or the measurement data from RAN.
RAN reports the measurements to Near-RT RIC according to the request
Step 3 (M)
or subscription.
Near-RT RIC calculates the positioning results based on the
Step 4 (M)
measurement report from RAN, using the selected positoning algorithm.
Near-RT RIC sends the response or notification command to expose
Step 5 (M)
radio performance analytics towards application server.
Application server gets response, or sends subscription deletion toward
Ends when
the Near-RT RIC.
Exceptions FFS
5 Table 3.13.3.1-1: Local Indoor Positioning in RAN (1)

7 Figure 3.13.3.1-1: Local Indoor Positioning in RAN (1) flow diagram

________________________________________________________________________________________________
Copyright © 2022 by the O-RAN ALLIANCE e.V. Your use is subject to the terms of the O-RAN Adopter License Agreement in Annex ZZZ 71
O-RAN.WG1.Use-Cases-Detailed-Specification-v08.00

1 3.13.3.2 Local Indoor Positioning in RAN (2)

<<Uses>>
Use Case Stage Evolution / Specification
Related use
Goal Expose positioning results to external applications.
Actors and Roles Non-RT RIC, near-RT RIC, SMO, application server
All relevant functions and components are instantiated.
Assumptions
A1/O1 interface connectivity is established with Non-RT RIC.
Positioning related models have been deployed in Non-RT RIC and Near-
Pre conditions RT RIC respectively.
Editor’s Note: security related procedure is FFS.
The application server wants to request/subscribe RAN positioning results
Begins when
of target UE
Application server sends positioning request of target UE to Near-RT RIC
Step 1 (M) or subscribes positioning results from Near-RT RIC to get periodic or event
triggered position reporting.
Near-RT RIC receives the request or subscription from application server
and requests or subscribes measurements to RAN through E2 interface.
Step 2 (M) The Near-RT RIC selects the positioning algorithm based on the request
or the measurement data from RAN and may update the positioning
related models from Non-RT RIC.
RAN reports the measurements to Near-RT RIC according to the request
Step 3 (M)
or subscription.
Near-RT RIC calculates the positioning results based on the positiong
Step 4 (M)
report from RAN, usingthe selected positoning algorithm.
Near-RT RIC sends the response or notification command to expose radio
Step 5 (M) performance analytics towards application server. Near-RT RIC may also
pass the positioning results to the Non-RT RIC for further analysis.
Application server gets response or sends subscription deletion toward the
Ends when
Near-RT RIC.
Exceptions FFS
2 Table 3.13.3.2-1: Local Indoor Positioning in RAN (2)

4 Figure 3.13.3.2-1: Local Indoor Positioning in RAN (2) flow diagram

________________________________________________________________________________________________
Copyright © 2022 by the O-RAN ALLIANCE e.V. Your use is subject to the terms of the O-RAN Adopter License Agreement in Annex ZZZ 72
O-RAN.WG1.Use-Cases-Detailed-Specification-v08.00

1 3.13.4 Required data

2 Multi-dimensional data are expected to be retrieved by Non-RT RIC for AI/ML model training and policies/intents
3 generation.
4 1) Network level measurement report, including UE level radio channel information, mobility related metrics, e.g.,
5 RSRP, RSSI, etc.
6 2) Positioning measurement report, including UE level E-CID, OTDOA, UTDOA, TOA, RSSI, AOA, etc.
7 3) Enrichment information (optional) collected from SMO (may acquire data from application), may including labeled
8 user location by manual or by minimal drive test, etc.
9
10 Near-RT RIC required data to select the positioning algorithm and calculate the positioning results.
11 1) Positioning measurement report, including UE level E-CID, OTDOA, UTDOA, TOA, RSSI, AOA, etc.
12 2) Performance requirements in positioning requests (optional) such as QoS.
13

14 3.13.5 RAN Analytics Information

15 Radio performance analytics data are expected to be exposed by Near-RT RIC to application server.
16 1) UE positioning results, including location coordinates, coordinate system, position methods used (in the case of
17 success indication provided), failure cause (in the case of failure indication provided), achieved location QoS
18 accuracy (optional).
19 2) Velocity estimation (optional).
20

21 3.14 Use case 14: Massive SU/MU-MIMO Grouping Optimization

22 FFS
23

24 3.15 Use case 15: O-RAN Signalling Storm Protection

25 This use case provides the background, motivation, and requirements for the O-RAN Signaling Storm Protection use case,
26 allowing protecting the mobility network against signaling storms initiated by devices.

27 3.15.1 Background and goal of the use case

28 Society is increasingly dependent on network connectivity at any time and in any place and increasing diversity of device
29 types ranging from complex devices such as smart phone to very simple and low-cost IoT devices are connecting to the
30 network. The sheer number of connected devices, as well as the wide range of device types, makes the mobility network
31 subject to accidental or intentional attacks that may disrupt the regular usage of the network. Given that life-critical
32 applications are moving to wireless networks, such network disruptions are not only an inconvenience but may have
33 impact on life and health of individuals. The O-RAN architecture offers an opportunity to address such security challenges
34 in customizable and creative ways by utilizing the near-RT RIC xApps and non-RT RIC rApps.

35 Currently, the main defense mechanism standardized in 3GPP against attacks coming from the devices toward the network
36 is based on configuration of the devices themselves and trust that the devices will indeed comply with restrictions defined
37 by mobility standards. One such defense mechanism is the back-off timer that restricts the number of repeated device
38 registrations, thus preventing devices from overloading the network with attaches. If this trust is breached there are no

________________________________________________________________________________________________
Copyright © 2022 by the O-RAN ALLIANCE e.V. Your use is subject to the terms of the O-RAN Adopter License Agreement in Annex ZZZ 73
O-RAN.WG1.Use-Cases-Detailed-Specification-v08.00

1 other options for defending the network rather than rejecting (denying service) randomly to both benign and malicious
2 devices, a state which is equivalent to DDoS. Unfortunately, even today the network has few hundreds of device types
3 that under certain conditions accidently breach this trust and allow devices to aggressively attach to the network in a rate
4 of few thousand times per hour (the maximum allowed number by standard is less than 20 attaches per hour). An attacker
5 that finds a way to manipulate vulnerabilities in a large set of these devices remotely can cause an attach storm that could
6 lead to a long outage of large parts of the network. Furthermore, this attacker can continue this attack over many hours,
7 each time picking few thousand of devices from a large pool of millions of vulnerable devices connected to the same
8 carrier network; the network carrier will not be able to stop this attack without intelligent and fine-grained controls to act
9 against a certain patterns of behavior.

10 Fortunately detecting these aggressive devices is possible as their behavior is very different from the other devices in the
11 network. What the network really needs is to apply dynamic restriction over these devices to prevent them from
12 overloading the control plane of the network. This restriction should be smart enough to still allow benign devices to
13 register to the network without interruption. Having smart security control at the RAN can stop such attack and without
14 overloading deeper parts of the network in the core.

15 The goal of this use case is utilize O-RAN to detect and mitigate signaling storms DDoS quick and as close to the network
16 edge, thus minimizing affected network nodes. The near-RT RIC would detect these signaling storms by analyzing
17 signaling events from RAN nodes it controls. When such a storm is detected the near-RT RIC creates fine grained filters,
18 which cover the aggressive UEs that cause the storm. These UEs registration requests will then be blocked/throttled while
19 the behaving UEs will continue to get service as usual. In some cases the attack may be spread across many locations. It
20 could be that the volume of signaling per location has not crossed a critical threshold but the moderate increase in many
21 locations do cause an overload of central nodes such as the network core elements. In this case a network-wide view is
22 required; thus the non-RT performs the network-wide analysis and in the case of a network signaling storm, it pushes
23 policies to the local near-RT RIC to adjust detection parameters to reduce the moderate increase of signaling from a set
24 of one or more E2 Nodes. This combined view of both non-RT RIC and near-RT RIC ensures quick reaction to local
25 signaling storms as well as response to widely distributed attacks.

26 While flows in this use case focus on the signaling storm scenario, they could be easily extend to include other attack
27 scenarios both in terms of detection and mitigation. For example, the scenario where rogue devices report false CQI
28 measurements that indicate high values while the real channel quality is poor. When exploited by attackers and applied
29 to large set of devices this attack can cause to waste of radio resources and eventually to DoS. Detection of the attack may
30 be achieved by analyzing anomalous CQI reports or abnormal volume of NACK messages based on signaling messages.
31 For mitigation actions either rejecting the rogue devices or limiting radio resources can be applied.

32 3.15.2 Entities/resources involved in the use case

33 1) Non-RT RIC in SMO domain:

34 a) Maintains overall view of network wide phenomenon of signaling storms using Signaling Storm Detection
35 rApp. The detection of distributed signaling storms that spread over many geographical locations and are more
36 difficult to be observed locally. This overall view is broken down by location and corresponding policies are
37 pushed to specific instances of near-RT RIC to respond to abnormal signaling activity in affected geographical
38 areas, over the A1 interface.
39 b) Uses enrichment data from non-RAN source (i.e. 5G core or probing framework) to maintain global view and
40 support more accurate detection and classification of attacks.
41 c) Utilizes AI/ML models in the Signaling Storm Detection rApp that monitor network-level signaling behavior
42 to support signaling anomalies detection.
43 2) Near-RT RIC in RAN domain:
44 a) Monitors E2 interface for connection establishment messages and identifies abnormal levels of signaling
45 activity using the Signaling Storm Detection xApp.

________________________________________________________________________________________________
Copyright © 2022 by the O-RAN ALLIANCE e.V. Your use is subject to the terms of the O-RAN Adopter License Agreement in Annex ZZZ 74
O-RAN.WG1.Use-Cases-Detailed-Specification-v08.00

1 b) Signaling Storm Mitigation xApp utilizes policies over E2 to enforce appropriate mitigation action (e.g. reject,
2 throttle, alert) over misbehaving UEs connection establishment.
3 c) Signaling Storm Detection xApp utilizes AI/ML models that monitor cell-level signaling behavior to support
4 signaling anomalies detection.
5 d) Applies appropriate detection policy based on policies received from non-RT RIC (e.g. false-positive levels,
6 UE thresholds, throttling ratios).
7 3) E2 Nodes in RAN domain:
8 a) Support sending connection establishment messages over the E2 interface.
9 b) Support control and policy enforcement from near-RT RIC over E2 interface

10 3.15.3 Solutions

11 3.15.3.1 Mode 1 – Local Signaling Storm Protection Policy

<<Uses>>
Use Case Stage Evolution / Specification
Related use
Detect localized signaling storms based on “default parameters” and apply
Goal
policy to mitigate the attack.
Near-RT RIC: detection of local cell-level signaling storms; execution of
mitigation policies and controls, maintenance of cell-level normal behavior
Actors and Roles models
E2 Nodes: execute mitigation policies, collects and reports RAN signaling
events and policy specific statistics over E2
All relevant functions and components are instantiated. Signaling Storms
Detection and Signaling Storm Mitigation xApps are deployed over E2 with
Assumptions initial configuration
E2 interface connectivity is established with non-RT RIC and RAN respectively.
Data report, policy and control subscription established on E2 interface
Network is operational.
SMO has established the data collection and sharing interface with non-RT
RIC.
Near-RT RIC already established relevant detection mechanisms of normal
Pre conditions
signaling behavior and adjusted detection parameters accordingly. Non RT-
RIC analyzes the historical data from RAN, develops, trains with help of SMO
functions and deploys the models or algorithm as part of the Signaling Storm
Detection xApp to the near-RT RIC
Begins when Network is in normal state (attack is described later on)
Signaling Storm Detection xApp subscribes on connection establishment
Step 1 (M)
signaling messages report from the RAN over the E2 interface.
Step 2 (M) E2 Node sends report to Signaling Storm Detection xApp.
Near-RT RIC Signaling Storm Detection xApp monitors reports to detect
Step 3 (M)
aggressive UEs that act with abnormal signaling
UEs send establish connection messages and E2 Node accepts these
Steps 4-7 (M)
requests
Step 8 (M) E2 Node sends a connection establishment reports
Step 9 (M) Signaling Storm Detection xApp detects aggressive activity
Step 10 (M) Signaling Storm Detection xApp updates Signaling Storm Mitigation xApp.
Near-RT RIC Signaling Storm Mitigation xApp creates a filter to block/throttle
signaling messages from the aggressive UEs. Filter is applied in the E2 Nodes
Step 11 (M)
as POLICY + REPORT to track filter activity. Near-RT RIC should notify the
Non-RT RIC to avoid conflicts.
Step 12 (M) Aggressive UE sends connection establishment message
Step 13 (M) E2 Node evaluate policy with respect to the connection establishment message
Step 14 (M) E2 Node rejects/throttles connection establishment request
Near-RT RIC Signaling Storm Mitigation xApp receives relevant signaling
Step 15 (M)
messages that the POLICY filter blocked/ throttled to track changes in attack

________________________________________________________________________________________________
Copyright © 2022 by the O-RAN ALLIANCE e.V. Your use is subject to the terms of the O-RAN Adopter License Agreement in Annex ZZZ 75
O-RAN.WG1.Use-Cases-Detailed-Specification-v08.00

status and aggressive devices (list of UEs blocked, blocked signaling volume,
trend)
Near-RT RIC Signaling Storm Mitigation xApp is finds that some devices are
Step 16 (M) no longer aggressive or no longer present. It decides to update filter by
updating the E2 Node POLICY.
Near-RT RIC Signaling Storm Detection xApp detects a new set of aggressive
Step 17-19 (M) devices and updates the Signaling Storm Mitigation xApp, which updates the
filter by updating the E2 Node POLICY.
Near-RT RIC Signaling Storm Mitigation xApp evaluates signaling level and
Step 20-21 (M) decides that there is no more aggressive UE activity. The xApp removes the
E2 Node policy.
Ends when Attack is over and signaling messages level is back to normal.
Exceptions None identified
Post Conditions Return to normal signaling activity monitoring (Step 1)
1 Table 3.15.3-1: Local Signaling Storm Protection Policy

3
4 Figure 3.15.3-1: Local Signaling Storm Protection Policy flow diagram

5 3.15.3.2 Mode 1 – Local Signaling Storm Protection Insert-Control (Optional)

<<Uses>>
Use Case Stage Evolution / Specification
Related use
Detect localized signaling storms based on “default parameters” and apply
Goal
control to mitigate the attack.

________________________________________________________________________________________________
Copyright © 2022 by the O-RAN ALLIANCE e.V. Your use is subject to the terms of the O-RAN Adopter License Agreement in Annex ZZZ 76
O-RAN.WG1.Use-Cases-Detailed-Specification-v08.00

Near-RT RIC: detection of local cell-level signaling storms; execution of

mitigation policies and controls, maintenance of cell-level normal behavior
Actors and Roles models
E2 Nodes: execute UE level mitigation policies, collects and reports RAN
signaling events and policy specific statistics over E2
All relevant functions and components are instantiated. Signaling Storms
Detection and Signaling Storm Mitigation xApps are deployed over E2 with
Assumptions initial configuration
E2 interface connectivity is established with non-RT RIC and RAN respectively.
Data report, policy and control subscription established on E2 interface
Network is operational.
SMO has established the data collection and sharing interface with non-RT
RIC.
Near-RT RIC already established relevant detection mechanisms of normal
Pre conditions
signaling behavior and adjusted detection parameters accordingly. Non RT-
RIC analyzes the historical data from RAN, develops, trains with help of SMO
functions and deploys the models or algorithm as part of the Signaling Storm
Detection xApp to the near-RT RIC
Begins when Network is in normal state (attack is described later on)
Signaling Storm Detection xApp subscribes on connection establishment
Step 1 (M)
signaling messages report from the RAN over the E2 interface.
Step 2 (M) E2 Node sends report to Signaling Storm Detection xApp.
Near-RT RIC Signaling Storm Detection xApp monitors reports to detect
Step 3 (M)
aggressive UEs that act with abnormal signaling
UEs send establish connection messages and E2 Node accepts these
Steps 4-7 (M)
requests
Step 8 (M) E2 Node sends a report indicating aggressive devices behavior
Step 9 (M) Signaling Storm Detection xApp detects aggressive activity
Step 10 (M) Signaling Storm Detection xApp updates Signaling Storm Mitigation xApp.
Signaling Storm Mitigation xApp updates subscription to INSERT-CONTROL.
Step 11 (M) Use control filter to block/throttle aggressive UEs by rejecting some of the
messages.
Step 12 (M) E2 Node receives another connection establishment from an aggressive UE.
Step 13 (M) E2 Node forwards the message to the Signaling Storm Mitigation xApp
Signaling Storm Mitigation xApp determines that message is from an
Step 14 (M)
aggressive device
Signaling Storm Mitigation xApp sends a reject/throttle message to the E2
Step 15 (M)
Node.
Step 16 (M) E2 Node rejects/throttles connection establishment request
Step 17 (M) Signaling Storm Mitigation xApp continues to monitor its control filter
Near-RT RIC DDoS Mitigation xApp evaluates signaling level and decides that
Step 18 (M) there is no more aggressive UE activity. The xApp updates subscription back
to REPORT.
Ends when Attack is over and signaling messages level is back to normal.
Exceptions None identified
1 Table 3.15.3-2: Local Signaling Storm Protection Insert-Control

________________________________________________________________________________________________
Copyright © 2022 by the O-RAN ALLIANCE e.V. Your use is subject to the terms of the O-RAN Adopter License Agreement in Annex ZZZ 77
O-RAN.WG1.Use-Cases-Detailed-Specification-v08.00

1
2 Figure 3.15.3-2: Local Signaling Storm Protection Insert-Control flow diagram

3 3.15.3.3 Mode 2 – Distributed Signaling Storm Protection

<<Uses>>
Use Case Stage Evolution / Specification
Related use
Detect distributed signaling using Non-RT RIC and A1 policy initiates Mode 2
Goal
handling in Near-RT RIC with “stricter parameters” mitigation.
Non-RT RIC: detection of network-level distributed signaling storms,
maintenance of cell-level, network slice level and node level normal behavior
models.
Near-RT RIC: detection of local cell-level signaling storms; execution of
Actors and Roles
mitigation policies and controls, maintenance of cell-level normal behavior
models
RAN: executes UE level or network slice level mitigation policies, collects and
reports RAN signaling events and policy specific statistics over E2
All relevant functions and components are instantiated. Signaling Storms
Detection and Signaling Storms Mitigation xApps are deployed over E2 with
initial configuration
Assumptions
A1, E2 interface connectivity is established with non-RT RIC and RAN
respectively.
Data report, policy and control subscription established on E2 interface
Network is operational.
SMO has established the data collection and sharing interface with non-RT
RIC.
Non-RT RIC and near-RT RIC already established relevant detection
Pre conditions
mechanisms of normal signaling behavior and adjusted detection parameters
accordingly. Non-RT RIC analyzes the historical data from RAN, develops,
trains with help of SMO functions and deploys the models or algorithm as
xApps to the near-RT RIC
Begins when Network is in normal state when (attack is described later on)
OAM Functions start to collect enrichment information (EIs) from external
Step 1 (M)
sources (e.g. network core probing framework).
Step 2 (M) OAM Functions start to collect alarms & metrics from E2 Nodes.

________________________________________________________________________________________________
Copyright © 2022 by the O-RAN ALLIANCE e.V. Your use is subject to the terms of the O-RAN Adopter License Agreement in Annex ZZZ 78
O-RAN.WG1.Use-Cases-Detailed-Specification-v08.00

OAM Functions sends signaling statistics based on collected information to

Step 3 (M)
Non-RT RIC.
Non-RT RIC uses AI/ML model to analyze overall network signaling activity
Step 4 (M)
levels based on signaling statistics.
Non-RT RIC applies initial configurations to all near-RT RIC elements
regarding detection and mitigation parameters, including: accepted signaling
Step 5 (M)
volume thresholds, throttle/block ratio, accepted false negative levels, filter
pause periods, etc.
Non-RT RIC detects distributed signaling storm activity originated from a list of
Step 6 (M)
locations.
Non-RT RIC updates configuration to a stricter one in the relevant near-RT RIC
Step 7 (M)
locations over A1 interface.
Near-RT RIC performs detection and mitigation as described in 3.15.3.1 or
Step 8 (M)
3.15.3.2 with stricter configuration (e.g. lower thresholds).
Non-RT RIC determines that distributed signaling storm attack is over based
Step 9 (M)
on signaling statistics information.
Non-RT RIC updates Near-RT RICs back to initial configuration parameters
Step 10 (M)
over the A1 interface.
Near-RT RIC Signaling Storm Detection xApp observed aggressive behavior
Step 11 (M)
where temporal identifiers cannot be correlated with the underlying devices.
Step 12 (M) Near RT RIC alarms the OAM Functions over O1.
Step 13 (M) OAM Functions report suspicious behavior to Non-RT RIC.
Non-RT RIC sends Enrichment Information to near-RT RIC over A1-EI to
Step 14 (M)
support detection of aggressive devices.
Near-RT RIC performs detection and mitigation as described in 3.15.3.1 or
Step 15 (M)
3.15.3.2 with stricter configuration (e.g. lower thresholds).
Non-RT RIC evaluates data and decides that there is no more distributed
Step 16 (M)
signaling storm activity.
Non-RT updates configuration of relevant near-RT RICs over the A1 back to
Step 17 (M)
normal.
Ends when Attack is over and signaling messages level is back to normal.
Exceptions None identified
Non-RT RIC monitors network-level signaling messages statistics
Post Conditions
Near-RT RIC monitors cell-level signaling messages statistics
1 Table 3.15.3-1: Distributed Signaling Storm Protection

________________________________________________________________________________________________
Copyright © 2022 by the O-RAN ALLIANCE e.V. Your use is subject to the terms of the O-RAN Adopter License Agreement in Annex ZZZ 79
O-RAN.WG1.Use-Cases-Detailed-Specification-v08.00

2 Figure 3.15.3-1: Distributed Signaling Storm Protection flow diagram

3 3.15.4 Required data

4 The measurement counters, Detection within the near-RT RIC is based upon analyzing per UE connection establishment
5 messages events that include the following data:

6 1) Basic registration event parameters: timestamp, cell ID, temporary ID (e.g. C-RNTI, 5G-GUTI)
7 2) RAN parameters to correlate between a UE and registration events: e.g. RSRP/RSRQ, Timing Advance, Beam ID
8 Tracking status of ongoing attack by monitoring statistics of active filters that include the following data:

9 3) Number of UEs in the filter, number of requests blocked, trend (change over last x periods of time).

10 Enrichment information from a non-RAN source regarding network-wide DDoS information:

11 4) Overloaded regions, overloaded sites, severity (% above normal)

13 3.16 Use case 16: Congestion Prediction and Management

14 FFS
15

________________________________________________________________________________________________
Copyright © 2022 by the O-RAN ALLIANCE e.V. Your use is subject to the terms of the O-RAN Adopter License Agreement in Annex ZZZ 80
O-RAN.WG1.Use-Cases-Detailed-Specification-v08.00

1 3.17 Use case 17: Industrial IoT Optimization

2 FFS
3

4 3.18 Use case 18: BBU Pooling to achieve RAN Elasticity

5 FFS
6

7 3.19 Use case 19: Integrated SON Function

8 FFS
9

10 3.20 Use case 19: Lower Layer Split Multi Node Support
11 FFS
12

13 3.21 Use case 21: Energy Saving

14 FFS
15
16
17

________________________________________________________________________________________________
Copyright © 2022 by the O-RAN ALLIANCE e.V. Your use is subject to the terms of the O-RAN Adopter License Agreement in Annex ZZZ 81
O-RAN.WG1.Use-Cases-Detailed-Specification-v08.00

1 Annex A (informative): Additional Information

2 A.1 Traffic Steering use case A1 interface usage example

3 Note: Please refer to WG2 Use Cases and Requirements Specification for more details and up to date definitions of this
4 use case A1 interface usage examples.
5 An example scenario is here used to describe the use of A1 for traffic steering, implying the Non-RT RIC sending policies
6 for allocation of the control plane (RRC) and the user plane for different services, identified by their 5QI.
7 In the scenario a UE with UEid=1, belonging to a subnet slice identified by S-NSSAI=1, having a Voice (5QI=1) and an
8 MBB (5QI=9) connection established, enters an area covered by four frequency bands. The Non-RT RIC understands the
9 requirements and characteristics of the services and decides to let the Voice and RRC connection reside on the low band
10 (here covered by a macro cell B becoming the PCell), while the MBB connection should preferably use the higher band
11 (here provided by a smaller cell C and D becoming the SCells) and avoid the low band if possible. Cell A is used for
12 MBB if required for coverage reasons.
13 Policies are sent to any cell of concern, e.g. where the UE resides and may move.

14
15 Figure A.1-1 Desired use of the cells

16 Two policies over A1 are needed to accomplish the desired behavior, described in JSON format below. Note that as part
17 of the scope, the cell_id is optional, and if omitted it is up to the Near-RT RIC to locate the UE and there enforce the
18 policy.
19 {
20 "policy_id": "1",
21 "scope": {
22 "ue_id": "1",
23 "slice_id": "1",
24 "qos_id": "1",
25 “cell_id”: ”X” // Policy for Cell X, where X is one of A, B, C or D
26 },
27 "statement": {
28 "cell_id_list": "B",
29 "preference": "Shall",
30 "primary": true // Control plane on Cell B (becoming PCell)

________________________________________________________________________________________________
Copyright © 2022 by the O-RAN ALLIANCE e.V. Your use is subject to the terms of the O-RAN Adopter License Agreement in Annex ZZZ 82
O-RAN.WG1.Use-Cases-Detailed-Specification-v08.00

1 },
2 "statement": {
3 "cell_id_list ": "B",
4 "preference": "Shall",
5 "primary": false // Voice on Cell B
6 }
7 }
8
9 {
10 "policy_id": "2",
11 "scope": {
12 "ue_id": "1",
13 "slice_id": "1",
14 "qos_id": "9",
15 “cell_id”: ”X” // Policy for Cell X, where X is one of A, B, C or D
16 },
17 "statement": {
18 "cell_id_list ": {"B", “A”},
19 "preference": "Avoid",
20 "primary": false // Avoid MBB on Cell A and Cell B
21 },
22 "statement": {
23 "cell_id_list": {“C”, “D”},
24 "preference": "Prefer",
25 "primary": false // Prefer MBB on Cell C and Cell D
26 }
27 }

________________________________________________________________________________________________
Copyright © 2022 by the O-RAN ALLIANCE e.V. Your use is subject to the terms of the O-RAN Adopter License Agreement in Annex ZZZ 83
O-RAN.WG1.Use-Cases-Detailed-Specification-v08.00

1 Annex ZZZ O-RAN Adopter License Agreement

2 BY DOWNLOADING, USING OR OTHERWISE ACCESSING ANY O-RAN SPECIFICATION, ADOPTER
3 AGREES TO THE TERMS OF THIS AGREEMENT.

4 This O-RAN Adopter License Agreement (the “Agreement”) is made by and between the O-RAN Alliance and the entity
5 that downloads, uses or otherwise accesses any O-RAN Specification, including its Affiliates (the “Adopter”).

6 This is a license agreement for entities who wish to adopt any O-RAN Specification.

7 SECTION 1: DEFINITIONS
8

9 1.1 “Affiliate” means an entity that directly or indirectly controls, is controlled by, or is under common
10 control with another entity, so long as such control exists. For the purpose of this Section, “Control” means
11 beneficial ownership of fifty (50%) percent or more of the voting stock or equity in an entity.
12
13 1.2 “Compliant Portion” means only those specific portions of products (hardware, software or
14 combinations thereof) that implement any O-RAN Specification.
15
16 1.3 “Adopter(s)” means all entities, who are not Members, Contributors or Academic Contributors,
17 including their Affiliates, who wish to download, use or otherwise access O-RAN Specifications.
18
19 1.4 “Minor Update” means an update or revision to an O-RAN Specification published by O-RAN Alliance
20 that does not add any significant new features or functionality and remains interoperable with the prior
21 version of an O-RAN Specification. The term “O-RAN Specifications” includes Minor Updates.
22
23 1.5 “Necessary Claims” means those claims of all present and future patents and patent applications, other
24 than design patents and design registrations, throughout the world, which (i) are owned or otherwise
25 licensable by a Member, Contributor or Academic Contributor during the term of its Member, Contributor
26 or Academic Contributorship; (ii) such Member, Contributor or Academic Contributor has the right to grant
27 a license without the payment of consideration to a third party; and (iii) are necessarily infringed by
28 implementation of a Final Specification (without considering any Contributions not included in the Final
29 Specification). A claim is necessarily infringed only when it is not possible on technical (but not
30 commercial) grounds, taking into account normal technical practice and the state of the art generally
31 available at the date any Final Specification was published by the O-RAN Alliance or the date the patent
32 claim first came into existence, whichever last occurred, to make, sell, lease, otherwise dispose of, repair,
33 use or operate an implementation which complies with a Final Specification without infringing that claim.
34 For the avoidance of doubt in exceptional cases where a Final Specification can only be implemented by
35 technical solutions, all of which infringe patent claims, all such patent claims shall be considered Necessary
36 Claims.
37
38 1.6 “Defensive Suspension” means for the purposes of any license grant pursuant to Section 3, Member,
39 Contributor, Academic Contributor, Adopter, or any of their Affiliates, may have the discretion to include
40 in their license a term allowing the licensor to suspend the license against a licensee who brings a patent
41 infringement suit against the licensing Member, Contributor, Academic Contributor, Adopter, or any of
42 their Affiliates.

43
44 SECTION 2: COPYRIGHT LICENSE
45

________________________________________________________________________________________________
Copyright © 2022 by the O-RAN ALLIANCE e.V. Your use is subject to the terms of the O-RAN Adopter License Agreement in Annex ZZZ 84
O-RAN.WG1.Use-Cases-Detailed-Specification-v08.00

1 2.1 Subject to the terms and conditions of this Agreement, O-RAN Alliance hereby grants to Adopter a
2 nonexclusive, nontransferable, irrevocable, non-sublicensable, worldwide copyright license to obtain, use
3 and modify O-RAN Specifications, but not to further distribute such O-RAN Specification in any modified
4 or unmodified way, solely in furtherance of implementations of an O-RAN Specification.
5
6 2.2 Adopter shall not use O-RAN Specifications except as expressly set forth in this Agreement or in a
7 separate written agreement with O-RAN Alliance.

8
9 SECTION 3: FRAND LICENSE
10

11 3.1 Members, Contributors and Academic Contributors and their Affiliates are prepared to grant based on
12 a separate Patent License Agreement to each Adopter under Fair, Reasonable And Non-Discriminatory
13 (FRAND) terms and conditions with or without compensation (royalties) a nonexclusive, non-transferable,
14 irrevocable (but subject to Defensive Suspension), non-sublicensable, worldwide license under their
15 Necessary Claims to make, have made, use, import, offer to sell, lease, sell and otherwise distribute
16 Compliant Portions; provided, however, that such license shall not extend: (a) to any part or function of a
17 product in which a Compliant Portion is incorporated that is not itself part of the Compliant Portion; or (b)
18 to any Adopter if that Adopter is not making a reciprocal grant to Members, Contributors and Academic
19 Contributors, as set forth in Section 3.3. For the avoidance of doubt, the foregoing license includes the
20 distribution by the Adopter’s distributors and the use by the Adopter’s customers of such licensed
21 Compliant Portions.
22
23 3.2 Notwithstanding the above, if any Member, Contributor or Academic Contributor, Adopter or their
24 Affiliates has reserved the right to charge a FRAND royalty or other fee for its license of Necessary Claims
25 to Adopter, then Adopter is entitled to charge a FRAND royalty or other fee to such Member, Contributor
26 or Academic Contributor, Adopter and its Affiliates for its license of Necessary Claims to its licensees.

27 3.3 Adopter, on behalf of itself and its Affiliates, shall be prepared to grant based on a separate Patent
28 License Agreement to each Members, Contributors, Academic Contributors, Adopters and their Affiliates
29 under FRAND terms and conditions with or without compensation (royalties) a nonexclusive, non-
30 transferable, irrevocable (but subject to Defensive Suspension), non-sublicensable, worldwide license
31 under their Necessary Claims to make, have made, use, import, offer to sell, lease, sell and otherwise
32 distribute Compliant Portions; provided, however, that such license will not extend: (a) to any part or
33 function of a product in which a Compliant Portion is incorporated that is not itself part of the Compliant
34 Portion; or (b) to any Members, Contributors, Academic Contributors, Adopters and their Affiliates that is
35 not making a reciprocal grant to Adopter, as set forth in Section 3.1. For the avoidance of doubt, the
36 foregoing license includes the distribution by the Members’, Contributors’, Academic Contributors’,
37 Adopters’ and their Affiliates’ distributors and the use by the Members’, Contributors’, Academic
38 Contributors’, Adopters’ and their Affiliates’ customers of such licensed Compliant Portions.

40 SECTION 4: TERM AND TERMINATION

42 4.1 This Agreement shall remain in force, unless early terminated according to this Section 4.
43

44 4.2 O-RAN Alliance on behalf of its Members, Contributors and Academic Contributors may terminate
45 this Agreement if Adopter materially breaches this Agreement and does not cure or is not capable of curing
46 such breach within thirty (30) days after being given notice specifying the breach.
47

________________________________________________________________________________________________
Copyright © 2022 by the O-RAN ALLIANCE e.V. Your use is subject to the terms of the O-RAN Adopter License Agreement in Annex ZZZ 85
O-RAN.WG1.Use-Cases-Detailed-Specification-v08.00

1 4.3 Sections 1, 3, 5 - 11 of this Agreement shall survive any termination of this Agreement. Under surviving
2 Section 3, after termination of this Agreement, Adopter will continue to grant licenses (a) to entities who
3 become Adopters after the date of termination; and (b) for future versions of O-RAN Specifications that
4 are backwards compatible with the version that was current as of the date of termination.

5
6 SECTION 5: CONFIDENTIALITY
7

8 Adopter will use the same care and discretion to avoid disclosure, publication, and dissemination of O-
9 RAN Specifications to third parties, as Adopter employs with its own confidential information, but no less
10 than reasonable care. Any disclosure by Adopter to its Affiliates, contractors and consultants should be
11 subject to an obligation of confidentiality at least as restrictive as those contained in this Section. The
12 foregoing obligation shall not apply to any information which is: (1) rightfully known by Adopter without
13 any limitation on use or disclosure prior to disclosure; (2) publicly available through no fault of Adopter;
14 (3) rightfully received without a duty of confidentiality; (4) disclosed by O-RAN Alliance or a Member,
15 Contributor or Academic Contributor to a third party without a duty of confidentiality on such third party;
16 (5) independently developed by Adopter; (6) disclosed pursuant to the order of a court or other authorized
17 governmental body, or as required by law, provided that Adopter provides reasonable prior written notice
18 to O-RAN Alliance, and cooperates with O-RAN Alliance and/or the applicable Member, Contributor or
19 Academic Contributor to have the opportunity to oppose any such order; or (7) disclosed by Adopter with
20 O-RAN Alliance’s prior written approval.

22 SECTION 6: INDEMNIFICATION
23

24 Adopter shall indemnify, defend, and hold harmless the O-RAN Alliance, its Members, Contributors or
25 Academic Contributors, and their employees, and agents and their respective successors, heirs and assigns
26 (the “Indemnitees”), against any liability, damage, loss, or expense (including reasonable attorneys’ fees
27 and expenses) incurred by or imposed upon any of the Indemnitees in connection with any claims, suits,
28 investigations, actions, demands or judgments arising out of Adopter’s use of the licensed O-RAN
29 Specifications or Adopter’s commercialization of products that comply with O-RAN Specifications.

31 SECTION 7: LIMITATIONS ON LIABILITY; NO WARRANTY

33 EXCEPT FOR BREACH OF CONFIDENTIALITY, ADOPTER’S BREACH OF SECTION 3, AND

34 ADOPTER’S INDEMNIFICATION OBLIGATIONS, IN NO EVENT SHALL ANY PARTY BE
35 LIABLE TO ANY OTHER PARTY OR THIRD PARTY FOR ANY INDIRECT, SPECIAL,
36 INCIDENTAL, PUNITIVE OR CONSEQUENTIAL DAMAGES RESULTING FROM ITS
37 PERFORMANCE OR NON-PERFORMANCE UNDER THIS AGREEMENT, IN EACH CASE
38 WHETHER UNDER CONTRACT, TORT, WARRANTY, OR OTHERWISE, AND WHETHER OR
39 NOT SUCH PARTY HAD ADVANCE NOTICE OF THE POSSIBILITY OF SUCH DAMAGES.

41 O-RAN SPECIFICATIONS ARE PROVIDED “AS IS” WITH NO WARRANTIES OR CONDITIONS

42 WHATSOEVER, WHETHER EXPRESS, IMPLIED, STATUTORY, OR OTHERWISE. THE O-RAN
43 ALLIANCE AND THE MEMBERS, CONTRIBUTORS OR ACADEMIC CONTRIBUTORS
44 EXPRESSLY DISCLAIM ANY WARRANTY OR CONDITION OF MERCHANTABILITY,
45 SECURITY, SATISFACTORY QUALITY, NONINFRINGEMENT, FITNESS FOR ANY

________________________________________________________________________________________________
Copyright © 2022 by the O-RAN ALLIANCE e.V. Your use is subject to the terms of the O-RAN Adopter License Agreement in Annex ZZZ 86
O-RAN.WG1.Use-Cases-Detailed-Specification-v08.00

1 PARTICULAR PURPOSE, ERROR-FREE OPERATION, OR ANY WARRANTY OR CONDITION

2 FOR O-RAN SPECIFICATIONS.

4 SECTION 8: ASSIGNMENT
5

6 Adopter may not assign the Agreement or any of its rights or obligations under this Agreement or make
7 any grants or other sublicenses to this Agreement, except as expressly authorized hereunder, without having
8 first received the prior, written consent of the O-RAN Alliance, which consent may be withheld in O-RAN
9 Alliance’s sole discretion. O-RAN Alliance may freely assign this Agreement.

11 SECTION 9: THIRD-PARTY BENEFICIARY RIGHTS

13 Adopter acknowledges and agrees that Members, Contributors and Academic Contributors (including
14 future Members, Contributors and Academic Contributors) are entitled to rights as a third-party beneficiary
15 under this Agreement, including as licensees under Section 3.

17 SECTION 10: BINDING ON AFFILIATES

19 Execution of this Agreement by Adopter in its capacity as a legal entity or association constitutes that legal
20 entity’s or association’s agreement that its Affiliates are likewise bound to the obligations that are applicable
21 to Adopter hereunder and are also entitled to the benefits of the rights of Adopter hereunder.

23 SECTION 11: GENERAL

25 This Agreement is governed by the laws of Germany without regard to its conflict or choice of law
26 provisions.

27 This Agreement constitutes the entire agreement between the parties as to its express subject matter and
28 expressly supersedes and replaces any prior or contemporaneous agreements between the parties, whether
29 written or oral, relating to the subject matter of this Agreement.

30 Adopter, on behalf of itself and its Affiliates, agrees to comply at all times with all applicable laws, rules
31 and regulations with respect to its and its Affiliates’ performance under this Agreement, including without
32 limitation, export control and antitrust laws. Without limiting the generality of the foregoing, Adopter
33 acknowledges that this Agreement prohibits any communication that would violate the antitrust laws.

34 By execution hereof, no form of any partnership, joint venture or other special relationship is created
35 between Adopter, or O-RAN Alliance or its Members, Contributors or Academic Contributors. Except as
36 expressly set forth in this Agreement, no party is authorized to make any commitment on behalf of Adopter,
37 or O-RAN Alliance or its Members, Contributors or Academic Contributors.

39 In the event that any provision of this Agreement conflicts with governing law or if any provision is held
40 to be null, void or otherwise ineffective or invalid by a court of competent jurisdiction, (i) such provisions

________________________________________________________________________________________________
Copyright © 2022 by the O-RAN ALLIANCE e.V. Your use is subject to the terms of the O-RAN Adopter License Agreement in Annex ZZZ 87
O-RAN.WG1.Use-Cases-Detailed-Specification-v08.00

1 will be deemed stricken from the contract, and (ii) the remaining terms, provisions, covenants and
2 restrictions of this Agreement will remain in full force and effect.

3 Any failure by a party or third party beneficiary to insist upon or enforce performance by another party of
4 any of the provisions of this Agreement or to exercise any rights or remedies under this Agreement or
5 otherwise by law shall not be construed as a waiver or relinquishment to any extent of the other parties’ or
6 third party beneficiary’s right to assert or rely upon any such provision, right or remedy in that or any other
7 instance; rather the same shall be and remain in full force and effect.

O RAN - WG3.E2SM RC R003 v04.00
No ratings yet
O RAN - WG3.E2SM RC R003 v04.00
413 pages
O RAN - WG1.Use Cases Analysis Report R003 v14.00
No ratings yet
O RAN - WG1.Use Cases Analysis Report R003 v14.00
90 pages
Cloud Platform Reference Design For Deployment Scenario B
100% (1)
Cloud Platform Reference Design For Deployment Scenario B
36 pages
O-RAN - WG5.IOT.0-v07.00: O-RAN Open F1/W1/E1/X2/Xn Interface Working Group Interoperability Test Specification (IOT)
No ratings yet
O-RAN - WG5.IOT.0-v07.00: O-RAN Open F1/W1/E1/X2/Xn Interface Working Group Interoperability Test Specification (IOT)
213 pages
O-RAN TIFG E2ETSTFWK 0-v01 00
No ratings yet
O-RAN TIFG E2ETSTFWK 0-v01 00
69 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
Script For A Better Malaysia - DSAI
No ratings yet
Script For A Better Malaysia - DSAI
186 pages
O-RAN WG7 OMC-HAR 0-v01 00
No ratings yet
O-RAN WG7 OMC-HAR 0-v01 00
39 pages
Training - Last Session - O-RAN-WG6.CAD-V01.00.00 PDF
No ratings yet
Training - Last Session - O-RAN-WG6.CAD-V01.00.00 PDF
46 pages
Pricelistwef1 8 19
No ratings yet
Pricelistwef1 8 19
141 pages
O-RAN - wg2.R1 Use Cases and Requirements.v01.00
No ratings yet
O-RAN - wg2.R1 Use Cases and Requirements.v01.00
25 pages
O RAN - wg1.TS - Use Cases Detailed Specification R004 v16.00
No ratings yet
O RAN - wg1.TS - Use Cases Detailed Specification R004 v16.00
264 pages
O RAN - WG1.mMIMO Use Cases TR v01.00
No ratings yet
O RAN - WG1.mMIMO Use Cases TR v01.00
133 pages
O RAN - Wg1.use Cases Analysis Report v02.00
No ratings yet
O RAN - Wg1.use Cases Analysis Report v02.00
28 pages
O RAN - Wg1.use Cases Analysis Report v03.00
No ratings yet
O RAN - Wg1.use Cases Analysis Report v03.00
39 pages
O RAN - Wg1.use Cases Analysis Report v09.00
No ratings yet
O RAN - Wg1.use Cases Analysis Report v09.00
65 pages
O-RAN WG10 TE&IV-UCR 0-R004-v03 00
No ratings yet
O-RAN WG10 TE&IV-UCR 0-R004-v03 00
37 pages
O RAN - Wg1.slicing Architecture v07.00
No ratings yet
O RAN - Wg1.slicing Architecture v07.00
61 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
O RAN - WG1.TS - Use Cases Detailed Specification R004 v15.00
No ratings yet
O RAN - WG1.TS - Use Cases Detailed Specification R004 v15.00
359 pages
O-RAN WG7 OMAC-HAR 0-v01 00
No ratings yet
O-RAN WG7 OMAC-HAR 0-v01 00
36 pages
O RAN - WG1.Use Cases Detailed Specification R003 v11.00
100% (1)
O RAN - WG1.Use Cases Detailed Specification R003 v11.00
189 pages
O RAN - WG11.Security Requirements Specification.O R003 v09.00
No ratings yet
O RAN - WG11.Security Requirements Specification.O R003 v09.00
96 pages
O-RAN WG7 DSC 0-v03 00
No ratings yet
O-RAN WG7 DSC 0-v03 00
29 pages
Training Architecture ORAN-WG2.UsecaseRequirements.v01.00 PDF
No ratings yet
Training Architecture ORAN-WG2.UsecaseRequirements.v01.00 PDF
29 pages
ORAN WG3 E2SM v01 00 Copy 5
No ratings yet
ORAN WG3 E2SM v01 00 Copy 5
28 pages
O RAN - WG1.O RAN Architecture Description v04.00
100% (1)
O RAN - WG1.O RAN Architecture Description v04.00
34 pages
O-RAN WG2 A1UCR-R003-v01 01
No ratings yet
O-RAN WG2 A1UCR-R003-v01 01
40 pages
O-RAN - WG7 DSC 0-v01 00 PDF
No ratings yet
O-RAN - WG7 DSC 0-v01 00 PDF
23 pages
O RAN - WG1.Slicing Architecture R003 v10.00
No ratings yet
O RAN - WG1.Slicing Architecture R003 v10.00
70 pages
O-RAN WG10 TS O1NRM 0-R004-v02 00
No ratings yet
O-RAN WG10 TS O1NRM 0-R004-v02 00
21 pages
O RAN - Wg1.slicing Architecture v05.00
No ratings yet
O RAN - Wg1.slicing Architecture v05.00
53 pages
O Ran - wg10.Ts - Oam Architecture r004 v14.00
No ratings yet
O Ran - wg10.Ts - Oam Architecture r004 v14.00
86 pages
ORAN-WG5.MP.0-v01.00: O-RAN Alliance Working Group 5 O1 Interface Specification For O-DU
No ratings yet
ORAN-WG5.MP.0-v01.00: O-RAN Alliance Working Group 5 O1 Interface Specification For O-DU
136 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 WG4 IOT 0-v04 00
No ratings yet
O-RAN WG4 IOT 0-v04 00
122 pages
O RAN - WG1.Slicing Architecture R003 v13.00
No ratings yet
O RAN - WG1.Slicing Architecture R003 v13.00
75 pages
O RAN - WG11.Security Requirements Specification.O R003 v06.00
No ratings yet
O RAN - WG11.Security Requirements Specification.O R003 v06.00
72 pages
ORAN WG3 TS E2SM-RC-R004-v07 00
No ratings yet
ORAN WG3 TS E2SM-RC-R004-v07 00
385 pages
O RAN - WG1.O RAN Architecture Description v06.00 (78361)
No ratings yet
O RAN - WG1.O RAN Architecture Description v06.00 (78361)
38 pages
O-RAN WG3 E2SM-R003-v04 00
No ratings yet
O-RAN WG3 E2SM-R003-v04 00
36 pages
O-RAN - WG2.A1TP v02.00
No ratings yet
O-RAN - WG2.A1TP v02.00
9 pages
What Is Working Group "WG" in ORAN
No ratings yet
What Is Working Group "WG" in ORAN
6 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
O RAN - WG1.Use Cases Analysis Report R003 v11.00
No ratings yet
O RAN - WG1.Use Cases Analysis Report R003 v11.00
83 pages
O-RAN WG3 E2AP-R003-v04 00
No ratings yet
O-RAN WG3 E2AP-R003-v04 00
128 pages
O-RAN - WG1.OAD-R003-v09.00: O-RAN Working Group 1 (Use Cases and Overall Architecture) O-RAN Architecture Description
No ratings yet
O-RAN - WG1.OAD-R003-v09.00: O-RAN Working Group 1 (Use Cases and Overall Architecture) O-RAN Architecture Description
40 pages
O Ran PDF
No ratings yet
O Ran PDF
21 pages
O RAN - WG6.O2DMS INTERFACE ETSI NFV PROFILE R004 v08.00
No ratings yet
O RAN - WG6.O2DMS INTERFACE ETSI NFV PROFILE R004 v08.00
108 pages
O-RAN WG3 E2GAP-R003-v04 01
No ratings yet
O-RAN WG3 E2GAP-R003-v04 01
49 pages
O RAN WG3.RICAPI R003 v01.00
No ratings yet
O RAN WG3.RICAPI R003 v01.00
107 pages
O-RAN WG10 TS TE&IV-DM 0-R004-v01 00
No ratings yet
O-RAN WG10 TS TE&IV-DM 0-R004-v01 00
11 pages
Autodesk Fusion 360 PCB Black Book (V 2.0.18719)
From Everand
Autodesk Fusion 360 PCB Black Book (V 2.0.18719)
Gaurav Verma
No ratings yet
AZ-801 Exam Prep: Configuring Windows Server Hybrid Services
From Everand
AZ-801 Exam Prep: Configuring Windows Server Hybrid Services
Steve Brown
No ratings yet
O Ran - wg9.Xtrp Syn.0 v03.00
No ratings yet
O Ran - wg9.Xtrp Syn.0 v03.00
115 pages
Basics of Autodesk Inventor Nastran 2024
From Everand
Basics of Autodesk Inventor Nastran 2024
Gaurav Verma
No ratings yet
Basics of Autodesk Inventor Nastran 2025
From Everand
Basics of Autodesk Inventor Nastran 2025
Gaurav Verma
No ratings yet
Open ROADM MSA Specification Ver 3 01
No ratings yet
Open ROADM MSA Specification Ver 3 01
91 pages
O-RAN WG10 TS O1-Interface 0-R004-v15 00
No ratings yet
O-RAN WG10 TS O1-Interface 0-R004-v15 00
81 pages
Data Poisoning Attackes
No ratings yet
Data Poisoning Attackes
9 pages
O-RAN WG2 A1GAP-R003-v03 01
No ratings yet
O-RAN WG2 A1GAP-R003-v03 01
21 pages
O RAN - WG11.Security Test Specifications.0 R003 v07.00
No ratings yet
O RAN - WG11.Security Test Specifications.0 R003 v07.00
330 pages
Topics: Conjugal Partnership of Gains, Conjugal Properties
No ratings yet
Topics: Conjugal Partnership of Gains, Conjugal Properties
3 pages
3CX Installation 2
No ratings yet
3CX Installation 2
2 pages
Affidavit of Poseur-Buyer
0% (1)
Affidavit of Poseur-Buyer
1 page
Consumable Cost Departement Wise APR@2021
No ratings yet
Consumable Cost Departement Wise APR@2021
4 pages
Tubeo, Lush Ishi E. (BSN-1D) LM-2
No ratings yet
Tubeo, Lush Ishi E. (BSN-1D) LM-2
8 pages
TQM MCQs
100% (2)
TQM MCQs
8 pages
List of Foreign Correspondents in The Spanish Civil War - Wikipedia
No ratings yet
List of Foreign Correspondents in The Spanish Civil War - Wikipedia
7 pages
LMC Reviewer Ateneo
No ratings yet
LMC Reviewer Ateneo
102 pages
(I09) Intermediate Nine-UNIT 01
No ratings yet
(I09) Intermediate Nine-UNIT 01
13 pages
Forex Made Easy - 20250724 - 033014 - 0000
No ratings yet
Forex Made Easy - 20250724 - 033014 - 0000
6 pages
Pamphlet Stitch Bookbinding Class Handout
No ratings yet
Pamphlet Stitch Bookbinding Class Handout
6 pages
Saurav Updated Resume
No ratings yet
Saurav Updated Resume
1 page
3A Bitmap Texture User Guide PDF
No ratings yet
3A Bitmap Texture User Guide PDF
1 page
Basic Principles Lecture
No ratings yet
Basic Principles Lecture
7 pages
1.11 Geometry Pagenumber
No ratings yet
1.11 Geometry Pagenumber
22 pages
Possible Threats
No ratings yet
Possible Threats
3 pages
Arabsat Frequency List PDF: Downloadarabsat Frequency List Pdf. Free PDF Download Zeal - Increased Damage Above Level 4
No ratings yet
Arabsat Frequency List PDF: Downloadarabsat Frequency List Pdf. Free PDF Download Zeal - Increased Damage Above Level 4
5 pages
Anime
No ratings yet
Anime
5 pages
26.06.23 - 02.07.23 (Aashiana)
No ratings yet
26.06.23 - 02.07.23 (Aashiana)
7 pages
Consensus - Nih.gov 2010 Lactosestatement
No ratings yet
Consensus - Nih.gov 2010 Lactosestatement
16 pages
Diy Survival Containers From Co2 Cartige: Technology Workshop Craft Home Food Play Outside Costumes
No ratings yet
Diy Survival Containers From Co2 Cartige: Technology Workshop Craft Home Food Play Outside Costumes
6 pages
College of Engineering and Technology, Bikaner Time Table - Revised B. Tech. II Semester Session 2013-14
No ratings yet
College of Engineering and Technology, Bikaner Time Table - Revised B. Tech. II Semester Session 2013-14
6 pages
Managing Heat Stress As Singapore Gets Warmer
No ratings yet
Managing Heat Stress As Singapore Gets Warmer
4 pages
Weekly Safety Report - STDL - 12 Nov. - 18 Nov. 2024
No ratings yet
Weekly Safety Report - STDL - 12 Nov. - 18 Nov. 2024
5 pages
Reviewer For UCSP
No ratings yet
Reviewer For UCSP
8 pages
Anger Thesis
100% (1)
Anger Thesis
8 pages
File
No ratings yet
File
3 pages
TSM Form 096 - Hot Work Permit (16 Jul 2021)
No ratings yet
TSM Form 096 - Hot Work Permit (16 Jul 2021)
4 pages

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.