Training Architecture ORAN-WG2.UsecaseRequirements.v01.00 PDF

ORAN-WG2.Use Case Requirements v01.
00
Technical Specification
O-RAN Working Group 2 (Non-RT RIC & A1 interface)
Prepared by the O-RAN Alliance e.V. Copyright © 2019 by the 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 the Annex B of this specification. All other rights reserved.
Copyright © 2019 by the O-RAN Alliance.

Your use is subject to the terms of the O-RAN Adopter License Agreement in Annex B 1
ORAN-WG2.Use Case Requirements v01.00
1 Revision History
Date Revision Author Description
2019.02.08 01.00.01 Qi Sun, Dhruv G. Draft for template
2019.03.12 01.00.02 Dhruv Gupta (AT&T) First draft with Scope, references, acronyms
2019.03.20 01.00.03 Arda Akman (Netsia) Initial addition of use case contributions:
- Traffic Steering use case for development of Non-RT
RIC functionality and A1 interface use case
- QoE use case
2019.04.10 01.00.04 Arda Akman (Netsia) Addition of CRs:
- Traffic steering use case
- QoE Optimization use case
- 3D-MIMO beamforming optimization use case
2019.04.12 01.00.05 Arda Akman (Netsia) Addition of CRs:
- 2019-04-08-CMCC-ATT-CR-A1-O1 description-
revision
- 2019-04-03-CMCC-CR -Add Recommended
requirements for Near-RT RIC and E2 in UCR Annex
2019.04.15 01.00.06 Arda Akman (Netsia) Updates throughout the document based on the editorial and co-
chair team review.
Addition of CRs:
- 2019_04_14_O-RAN.WG2
UsecaseRequirement.DraftSpec-CR-form-CMCC-
Orange-TIM_v2.00
- 2019-04-03-CMCC-ATT-CR -Add Recommended
requirements for Near-RT RIC and E2 in UCR Annex
v2-minor revision
- 2019-04-11-ATT-CMCC-UCR-
TrafficSteeringA1.PlantUMLSource
- 2019-04-11-ATT-CMCC-UCR-
E2Annex.PlantUMLSource
Addition of requirements to traceability section of use case
tables.
Addition of REQ-Non-RT RIC-FUN9 for Non-RT RIC fallback

mechanism.
2019.04.18 01.00.07 Arda Akman (Netsia) Addition of CR:

- 2019-04-18-CMCC-ATT-Netsia-CR-Modifications to
A1 and O1 related requirements
2019.04.26 01.00.08 Arda Akman (Netsia) Addition of CR:
- 2019-04-22-ATT-CR -Requirements Consolidation for
UCR doc v1 clean
2019.04.27 01.00.09 Arda Akman (Netsia) Editorial fixes (reference issues, upper case/lower case fixes,
etc.)
2019.05.01 01.00.10 Arda Akman (Netsia) Updating the traceability section of uses case to reflect the
consolidated requirements
2019.05.06 01.00 Arda Akman (Netsia) Spec renamed to 01.00 for publishing (per O-RAN guidelines)
_______________________________________________________________________________________________
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 ............................................................................................................................................... 6
9 Chapter 2 Objective ............................................................................................................................................ 7

10 Chapter 3 Use cases ............................................................................................................................................ 7
11 3.1 Use case 1: Traffic steering use case ............................................................................................................................ 7
12 3.1.1 Background and Goal of the use case ........................................................................................................................ 7
13 3.1.2 Entities/Resources involved in the use case ............................................................................................................... 8
14 3.1.3 Solutions .................................................................................................................................................................... 9
15 3.1.3.1 Traffic steering ........................................................................................................................................................ 9
16 3.1.4 Required data ........................................................................................................................................................... 10
17 3.2 Use case 2: QoE use case ............................................................................................................................................ 11
18 3.2.1 Background and Goal of the use case ...................................................................................................................... 11
19 3.2.2 Entities/Resources involved in the use case ............................................................................................................. 11
20 3.2.3 Solutions .................................................................................................................................................................. 12
21 3.2.3.1 Model training and distribution ............................................................................................................................ 12
22 3.2.3.2 Policy generation and performance evaluation ..................................................................................................... 13
23 3.2.4 Required data ........................................................................................................................................................... 14
24 3.3 Use case 3: 3D-MIMO beamforming optimization use case ...................................................................................... 14
25 3.3.1 Background and Goal of the use case ...................................................................................................................... 15
26 3.3.2 Entities/Resources involved in the use case ............................................................................................................. 15
27 3.3.3 Solutions .................................................................................................................................................................. 17
28 3.3.3.1 3D-MIMO beamforming optimization ................................................................................................................. 17
29 3.3.4 Required data ........................................................................................................................................................... 18
30 Chapter 4 Requirements ................................................................................................................................... 19
31 4.1 Functional Requirements ............................................................................................................................................ 19
32 4.1.1 Non-RT RIC Functional Requirements ................................................................................................................... 19
33 4.1.2 A1 Interface Functional Requirements .................................................................................................................... 19
34 4.2 Non-Functional Requirements .................................................................................................................................... 20
35 4.2.1 Non-RT RIC Non-Functional Requirements ........................................................................................................... 20
36 4.2.2 A1 Interface Non-Functional Requirements ............................................................................................................ 20
37 Annex A (informative): Near-RT RIC and O1 Requirements ................................................................... 21

38 A.1 Functional Requirements ........................................................................................................................................... 21
39 A.1.1 Near-RT RIC Functional Requirements.................................................................................................................. 22
40 A.1.2 E2 Interface Functional Requirements .................................................................................................................... 22
41 A.1.3 O1 Interface Functional Requirements ................................................................................................................... 23
42 A.2 Non-Functional Requirements ................................................................................................................................... 23
43 A.2.1 Near-RT RIC Non-Functional Requirements ......................................................................................................... 23
44 A.2.2 E2 Interface Non-Functional Requirements ............................................................................................................ 23
45 A.2.3 O1 Interface Non-Functional Requirements ........................................................................................................... 24
_______________________________________________________________________________________________
1 Annex B O-RAN Adopter License Agreement ............................................................................................ 25

2
_______________________________________________________________________________________________
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 WG2 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 RAN optimization and control related initial use cases that have been approved within
16 O-RAN WG2. The purpose of the use cases is to help identify requirements for O-RAN defined interfaces and functions,
17 eventually leading to formal drafting of interface specifications. For each use case, the document describes the motivation,
18 resources, steps involved, and data requirements. Finally, the requirements section details the functional and non-
19 functional requirements derived from these use cases.
20
21 1.2 References
22 The following documents contain provisions which, through reference in this text, constitute provisions of the present
23 document.
24 - References are either specific (identified by date of publication, edition number, version number, etc.) or
25 non-specific.
26 - For a specific reference, subsequent revisions do not apply.
27 - For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including
28 a GSM document), a non-specific reference implicitly refers to the latest version of that document in Release 15.
29 [1] 3GPP TR 21.905: “Vocabulary for 3GPP Specifications”
30 [2] 3GPP TS 38.211: "Physical channels and modulation", Release 15, March 2019.
31 [3] 3GPP TS 38.213: "Physical layer procedures for control ", Release 15, March 2019.
32
33
34
_______________________________________________________________________________________________
1 1.3 Definitions and Abbreviations
2 1.3.1 Definitions
3 For the purposes of the present document, the terms and definitions given in 3GPP TR 21.905 [1] and the following apply.
4 A term defined in the present document takes precedence over the definition of the same term, if any, in 3GPP
5 TR 21.905 [1].
6
7 A1: Interface between Orchestration/NMS layer containing Non-RT RIC and eNB/gNB containing Near-RT RIC.
8 E2: Interface between near-RT RIC and the Multi-RAT CU protocol stack and the underlying RAN DU.
9 FCAPS: Fault, Configuration, Accounting, Performance, Security.
10 Intents: A declarative policy to steer or guide the behavior of RAN functions, allowing the RAN function to calculate the
11 optimal result to achieve stated objective.
12 near-RT RIC: O-RAN near-real-time RAN Intelligent Controller: a logical function that enables near-real-time control
13 and optimization of RAN elements and resources via fine-grained data collection and actions over E2 interface.
14 non-RT RIC: O-RAN non-real-time RAN Intelligent Controller: a logical function that enables non-real-time control
15 and optimization of RAN elements and resources, AI/ML workflow including model training and updates, and policy-
16 based guidance of applications/features in near-RT RIC.
17 NMS: A Network Management System.
18 O-DU: O-RAN Distributed Unit: a logical node hosting RLC/MAC/High-PHY layers based on the 7-2x fronthaul split
19 (https://oranalliance.atlassian.net/wiki/spaces/FHWG/pages/99352591/CUS-
20 Plane+v01.00?preview=/99352591/120521474/ORAN-WG4.CUS.0-v01.00.pdf) defined by O-RAN WG4.
21 O-RU: O-RAN Radio Unit: a logical node hosting Low-PHY layer and RF processing based on the 7-2x fronthaul split
22 defined by O-RAN WG4.
23 O1: Interface between management entities (NMS/EMS/MANO) and O-RAN managed elements, for operation and
24 management, by which FCAPS management, Software management, File management shall be achieved.
25 RAN: Generally referred as Radio Access Network. In terms of this document, any component below near-RT RIC per
26 O-RAN architecture, including O-CU/O-DU/O-RU.
27
28 1.3.2 Abbreviations
29 For the purposes of the present document, the abbreviations given in 3GPP TR 21.905 [1] and the following apply. An
30 abbreviation defined in the present document takes precedence over the definition of the same abbreviation, if any, in
31 3GPP TR 21.905 [1].
32
33 eNB eNodeB (applies to LTE)
34 gNB gNodeB (applies to NR)
35 KPI Key Performance Indicator
36 KQI Key Quality Indicator
_______________________________________________________________________________________________
1 Non-RT RIC Non-Real-Time RIC

2 Near-RT RIC Near-RT RIC
3 O-CU O-RAN Central Unit
4 O-DU O-RAN Distributed Unit
5 O-RU O-RAN Radio Unit
6 QoE Quality of Experience
7 RIC O-RAN RAN Intelligent Controller
8 SINR Signal-to-Interference-plus-Noise Ratio
9
10 Chapter 2 Objective
11 This document provides O-RAN WG2 Non-RT RIC Use Cases and Requirements, including A1 interface.
12
13 Chapter 3 Use cases
14 3.1 Use case 1: Traffic steering use case

15 This use case provides the motivation, description, and requirements for traffic steering use case, allowing operators to
16 specify different objectives for traffic management such as optimizing the network/UE performance, or achieving
17 balanced cell load.
18 3.1.1 Background and Goal of the use case

19 The rapid traffic growth and multiple frequency bands utilized in a commercial network make it challenging to steer the
20 traffic in a balanced distribution. Typical controls are limited to adjusting the cell reselection and handover parameters;
21 and modifying load calculations and cell priorities.
22 Further, the RRM (Radio Resource Management) features in the existing cellular network are all cell-centric. Even in
23 different areas of within a cell, there are variations in radio environment, such as neighboring cell coverage, signal
24 strength, interference status, etc. However, base stations based on traditional control strategies treat all UEs in a similar
25 way and are usually focused on average cell-centric performance, rather than UE-centric.
26 Such current solutions suffer from following limitations:
27 1) It is hard to adapt the RRM control to diversified scenarios and optimization objectives.
28 2) The traffic steering/management strategy is usually passive, rarely taking advantage of capabilities to predict
29 network and UE performance.
30 3) Non-optimal traffic management, with slow response time, due to various factors such as inability to select the
31 right set of UEs for control action. This further results in non-optimal system and UE performance, such as reduced
32 throughput and increased handover failures.
_______________________________________________________________________________________________
1 Based on the above reasons, the main objective of this use case is to allow operators to flexibly configure the desired
2 optimization policies, utilize the right performance criteria, and leverage machine learning to enable intelligent and
3 proactive traffic steering control.
5 3.1.2 Entities/Resources involved in the use case
6 1) Non-RT RIC:
7 a) Retrieve necessary performance, configuration, and other data for constructing/training relevant AI/ML models
8 that will be deployed in near-RT RIC to assist in the traffic steering function. For example, this could be a
9 clustering algorithm to create RF fingerprint database based on UE signal quality features.
10 b) Retrieve necessary performance, configuration, and other data for training models for non-real-time
11 optimization of configuration parameters related to traffic steering and mobility management in RAN (over O1
12 interface).
13 c) Retrieve necessary performance, configuration, and other data for defining and updating intents and policies to
14 guide the behavior of traffic steering function in near-RT RIC. For example, the policy could relate to
15 specifying different optimization objectives (UE signal quality versus cell load), or to guide the carrier/band
16 preferences at per-UE or group of UE granularity.
17 d) Support deployment and update of AI/ML models into near-RT RIC xApp.
18 e) Support communication of intents and policies (system-level and UE-level) from non-RT RIC to near-RT RIC.
19 f) Support communication of configuration parameters to RAN.
20 g) Support communication of non-RAN data to enrich control functions in near-RT RIC.
21 2) Near-RT RIC:
22 a) Support update of AI/ML models from non-RT RIC.
23 b) Support interpretation and execution of intents and policies from non-RT RIC.
24 c) Support necessary performance, configuration, and other data for defining and updating intents and policies for
25 tuning relevant AI/ML models
26 3) RAN:
27 a) Support data collection with required granularity to NMS over O1 interface.
28 b) Support non-real-time configuration-based optimization of traffic steering parameters over O1 interface.
29
_______________________________________________________________________________________________
1 3.1.3 Solutions
2 3.1.3.1 Traffic steering
3 Table 3.1.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 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
NMS: termination point for O1 interface.
- All relevant functions and components are instantiated.
Assumptions
- A1 and O1 interface connectivity is established with non-RT RIC.
- Network is operational.
- NMS 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 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 non-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 near-RT RIC via O1 or Non-
Step 1 (M) RT RIC assigns/update the AI/ML model for near-RT RIC xApp via A1.
Non-RT RIC communicates relevant policies/intents and enrichment data to
near-RT RIC over A1. The example policies/intents may include:
a) KPI objectives or SLAs, e.g., balancing the maximum PRB utilization,

balancing the number of UE;
b) Cell/band priority or blacklist, UE priority or blacklist for traffic steering; Step 2a or 2b is
Step 2a
Mandatory
c) threshold, e.g. UE RSRP decline threshold, high load judgement
threshold and criterion (e.g., user number, PRB utilization ratio);
The enrichment data from non-RAN data may include UE location or trajectory
information from GPS data.
Step 2a or 2b is
Step 2b Non-RT RIC performs relevant configuration updates in RAN over O1 interface.
Mandatory
The near-RT RIC receives the relevant info from non-RT RIC over A1 interface
Step 3 (M)
and interprets the policies and updates the AI/ML models.
If required, non-RT RIC can configure specific performance measurement data
to be collected from RAN to assess the performance of traffic steering function
Step 4 (O)
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 traffic steering related function in
Post Conditions Near-RT RIC by collecting and monitoring the relevant performance KPIs and
counters from eNB/gNB.
- REQ-Non-RT-RIC-FUN1, REQ-Non-RT-RIC-FUN2, REQ-Non-RT-RIC-
FUN3, REQ-Non-RT-RIC-FUN4, REQ-Non-RT-RIC-FUN5
- REQ-A1-FUN1, REQ-A1-FUN2, REQ-A1-FUN3
- REQ-Non-RT-RIC-NonFUN1, REQ-Non-RT-RIC-NonFUN2
Informative:
Traceability
- REQ-Near-RT-RIC-FUN1, REQ-Near-RT-RIC-FUN2, REQ-Near-RT-RIC-
FUN4, REQ-Near-RT-RIC-FUN5
- REQ-E2-FUN1, REQ-E2-FUN2, REQ-E2-FUN3, REQ-E2-FUN4, REQ-E2-
FUN5, REQ-E2-FUN6
- REQ-O1-FUN1, REQ-O1-FUN2
_______________________________________________________________________________________________
2 Figure 3.1.3-1: Traffic steering use case flow diagram illustrates the overall procedure for the traffic steering use case.
3
4 Figure 3.1.3-1: Traffic steering use case flow diagram
6 3.1.4 Required data

7 The measurement counters and KPIs (as defined by 3GPP and will be extended for O-RAN use cases) should be
8 appropriately aggregated by cell, QoS type, slice, etc.
9 1) Measurement reports with RSRP/RSRQ/CQI information for serving and neighboring cells.
10 2) UE connection and mobility/handover statistics with indication of successful and failed handovers etc.
11 3) Cell load statistics such as information in the form of number of active users or connections, number of scheduled
12 active users per TTI, PRB utilization, and CCE utilization.
13 4) Per user performance statistics such as PDCP throughput, RLC or MAC layer latency, etc.
_______________________________________________________________________________________________
1 3.2 Use case 2: QoE use case

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

5 The highly demanding 5G native applications like Cloud VR are both bandwidth consuming and latency sensitive.
6 However, for such traffic-intensive and highly interactive applications, current semi-static QoS framework can’t
7 efficiently satisfy diversified QoE requirements especially taking into account potentially significant fluctuation of radio
8 transmission capability. It is expected that QoE estimation/prediction from application level can help deal with such
9 uncertainty and improve the efficiency of radio resources, and eventually improve user experience.
10 The main objective is to ensure QoE optimization be supported within the O-RAN architecture and its open interfaces.
11 Multi-dimensional data, e.g., user traffic data, QoE measurements, network measurement report, can be acquired and
12 processed via ML algorithms to support traffic recognition, QoE prediction, QoS enforcement decisions. ML models can
13 be trained offline and model inference will be executed in a real-time manner. Focus should be on a general solution that
14 would support any specific QoE use case (e.g. Cloud VR, video, etc.).
16 1) Non-RT RIC:
17 a) Retrieve necessary QoE related measurement metrics from network level measurement report and NMS (may
18 acquire data from application) for constructing/training relevant AI/ML model that will be deployed in near-
19 RT RIC to assist in the QoE Optimization function. For example, this could be application classification, QoE
20 prediction, and available bandwidth prediction.
21 b) Training of potential ML models for predictive QoE optimization, which may respectively autonomously
22 recognize traffic types, predict quality of experience, or predict available radio bandwidth.
23 c) Send policies/intents to near-RT RIC to drive the QoE optimization at RAN level in terms of expected behavior.
24 2) Near-RT RIC:
25 a) Support update of AI/ML models from non-RT RIC.
26 b) Support execution of the AI/ML models from non-RT RIC, e.g. application classification, QoE prediction, and
27 available bandwidth prediction.
28 c) Support interpretation and execution of intents and policies from non-RT RIC to derive the QoE optimization
29 at RAN level in terms of expected behavior.
30 d) Sending QoE performance report to Non-RT RIC for evaluation and optimization
31 3) RAN:
32 a) Support network state and UE performance report with required granularity to NMS over O1 interface.
33 b) Support QoS enforcement based on messages from A1/E2, which are expected to influence RRM behavior.
34
_______________________________________________________________________________________________
1 3.2.3 Solutions
2 3.2.3.1 Model training and distribution
3 Table 3.2.3-1: Model training and distribution
<<Uses>>
Related use
Goal Model training and Distribution
Actors and Roles Non-RT RIC, near-RT RIC, NMS, application server
Assumptions
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.

QoE related measurement metrics from NMS (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
Step 3 (M) Non-RT RIC distributes the model to the Near-RT RIC.
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,
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.
- REQ-Non-RT-RIC-FUN1, REQ-Non-RT-RIC-FUN3, REQ-Non-RT-
RIC-FUN4, REQ-Non-RT-RIC-FUN5
Informative:
Traceability - REQ-Near-RT-RIC-FUN1, REQ-Near-RT-RIC-FUN3, REQ-Near-RT-
RIC-FUN4, REQ-Near-RT-RIC-FUN5
- REQ-E2-FUN1, REQ-E2-FUN2, REQ-E2-FUN3, REQ-E2-FUN4,
REQ-E2-FUN5, REQ-E2-FUN6
4
_______________________________________________________________________________________________
2 Figure 3.2.3-1: Model training and distribution flow diagram
3 3.2.3.2 Policy generation and performance evaluation
4 Table 3.2.3-2: Policy generation and performance evaluation
<<Uses>>
Related use
Goal Policy generation and performance evaluation
Actors and Roles Non-RT RIC, near-RT RIC, NMS
Assumptions
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.
Step 2 (M) Non-RT RIC sends the QoE optimization policy to Near-RT RIC
Step 3 (M) Non-RT RIC collects QoE optimization report from NMS.
Non-RT RIC performs evaluation and may trigger AI/ML model
Step 4 (M)
optimization.
Ends when FFS
Exceptions FFS
Post Conditions FFS
RIC-FUN4, REQ-Non-RT-RIC-FUN5
Informative:
Traceability - REQ-Near-RT-RIC-FUN1, REQ-Near-RT-RIC-FUN3, REQ-Near-RT-
RIC-FUN4, REQ-Near-RT-RIC-FUN5
- REQ-E2-FUN1, REQ-E2-FUN2, REQ-E2-FUN3, REQ-E2-FUN4,
REQ-E2-FUN5, REQ-E2-FUN6
5
_______________________________________________________________________________________________
2 Figure 3.2.3-2: Policy generation and performance evaluation flow diagram

5 Multi-dimensional data are expected to be retrieved by non-RT RIC for AI/ML model training and policies/intents
6 generation.
7 1) Network level measurement report, including
8 - UE level radio channel information, mobility related metrics
9 - L2 measurement report related to traffic pattern, e.g., throughput, latency, packets per-second, inter frame
10 arrival time
11 - RAN protocol stack status: e.g. PDCP buffer status
12 - Cell level information: e.g. DL/UL PRB occupation rate
13 2) QoE related measurement metrics collected from NMS (may acquire data from application or network).
14 3) User traffic data, which may be obtained via a proprietary interface from existing data collection equipment and is
15 currently out of the scope of A1 or E2.
16
17 3.3 Use case 3: 3D-MIMO beamforming optimization use case

18 This use case provides the motivation, description, and requirements for 3D-MIMO beamforming long term optimization
19 use case. 3D-MIMO system configuration can allow operators to optimize the network performance and QoS by e.g.
20 balancing cell loads or reducing inter-cell interference.
_______________________________________________________________________________________________

2 Massive-MIMO (M-MIMO) 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 [2], [3] 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 configuration, one will have to look at a multi-cell environment
13 instead of a single cell. Moreover, different vendors may have different implementations in terms of the number of beams,
14 the horizontal/vertical beam widths, azimuth and elevation range, to achieve the desired coverage. In multi-vendor
15 scenario, close cooperation between vendors’ RAN equipment is required to offer optimal coverage and capacity.
16 Additionally, the number of such combination of adjustable parameters is in the thousands, hence it is prohibitive for the
17 traditional human expert system to work out the optimal configuration, and new method is in need.
18 State of the art solutions suffer from the following problems:
19 An M-MIMO macro- or small-cells benefit from a flexible way of serving users in their coverage area thanks to
20 beamforming. However the coverage area itself is defined by (vendor specific) fixed M-MIMO system parameters such
21 as the azimuth and elevation angle range, or the GoB parameters. Hence due to traffic distribution and terrain topology,
22 the M-MIMO cell may suffer from e.g.
23 1) High inter-cell interference

24 2) Unbalanced traffic between neighboring cells
25 3) Low performance of cell edge users
26 4) Poor handover performance
27 The objective of this use case is to allow the operator to flexibly configure M-MIMO system parameters by means of
28 policies, configuration or machine learning techniques, according to objectives defined by the operator.
29
31 1) Non-RT RIC:
32 a) Retrieve necessary configurations, performance indicators, measurement reports and other data from NMS and
33 RAN directly for the purpose of constructing/training relevant AI/ML models that will run in Non-RT RIC.
34 b) Retrieve necessary user location related information, e.g. GPS coordinates, from the application layer for the
35 purpose of constructing/training relevant AI/ML models that will run in Non-RT RIC.
36 c) Retrieve necessary user context information, e.g. mobility pattern prediction, from the near-RT RIC for the
37 purpose of constructing/training relevant AI/ML models that will run in Non-RT RIC.
38 d) The trained AI/ML model to infer the user distribution of multiple cells, and predict the optimal configuration
39 of M-MIMO parameters for each cell according to a global optimization objective designed by the operator
_______________________________________________________________________________________________
1 e) Send the optimal beam pattern configuration and/or policy to NMS for update; which sends the control
2 messages in terms of configuration change directly to the respective CU/DU/RRU, this control loop could be
3 done periodically or be event-triggered
4 f) Monitor the performance of all the cells; when the optimization objective fails, initiate fall back procedure;
5 meanwhile, the AI/ML model should be retrained according to the new feedback and input data, and the old
6 model updated.
_______________________________________________________________________________________________
1 3.3.3 Solutions
2 3.3.3.1 3D-MIMO beamforming optimization
3 Table 3.3.3-1: 3D-MIMO beamforming optimization
<<Uses>>
Related use
Enable flexible optimization of the multi-cell M-MIMO beamforming
performance (capacity and coverage) by means of policy and
Goal
configuration parameter change with operator-defined objectives, and
allow for AI/ML-based solutions.
Non-RT RIC acting as RAN policy control function and RAN
Actors and Roles
policy/configuration enforcement function
Non-RT RIC is instantiated, A1/O1 interface connectivity is established
Assumptions
with near-RT RIC, RAN and NMS. Network is operational.
Non-RT RIC has analyzed the collected data and designed the relevant
Pre conditions models for M-MIMO beam pattern configuration optimization;
AI/ML model generation function is operational.
Non-RT RIC train the AI/ML model with the collected data from the
application, the NMS, RAN and the near-RT RIC. Trained AI/ML models
Step 1 (M)
are deployed/updated in the non-RT RIC, for long-term optimization by
means of configuration changes and policy enforcement.
Non-RT RIC communicates relevant policies to NMS, and/or makes
direct configuration updates in the RAN. The relevant policies may
include:
a) M-MIMO configuration changes with the corresponding
Step 2 (M) conditions to be triggered
b) Handover policy for UEs, especially at the cell edge, e.g.
defining HO threshold configurations with the corresponding
conditions to be triggered
If the non-RT RIC M-MIMO beam pattern optimization algorithm requires
Step 3 (M) any UE context information or prediction from near RT RIC, it will provide
this data over O1 interface.
If required, non-RT RIC can configure specific measurement data to be
Step 4 (M) collected from the RAN to train the AI/ML model in non-RT RIC, or to
assess the outcome of the applied policies and configuration.
Non-RT RIC will initiate fallback mechanism to restore previous policy
Step 5 (O)
or configuration in case performance degradation is observed.
If the algorithm performance is unsatisfactory in terms of predefined
Step 6 (M) objective/requirement, non-RT RIC should gather necessary information
and data to retrain and update the AI/ML model locally
Exceptions FFS
Post Conditions The RAN operates using the newly deployed parameters/models
RIC-FUN3, REQ-Non-RT-RIC-FUN5, REQ-Non-RT-RIC-FUN6
- REQ-A1-FUN5
Traceability Informative:
- REQ-Near-RT-RIC-FUN6, REQ-Near-RT-RIC-FUN7
- REQ-E2-FUN7
4
5 Figure 3.3.3-1: 3D-MIMO beamforming optimization flow diagram illustrates the overall procedure.
_______________________________________________________________________________________________
2 Figure 3.3.3-1: 3D-MIMO beamforming optimization flow diagram

5 There are different types of data that are required from different parts of the network, and the following list summarizes
6 with some examples:
7 1) Measurement reports with RSRP/RSRQ/CQI information for all the cells of interest; the time granularity of data
8 collection should be configurable and satisfy the requirement of the AI/ML model
9 2) Complete set of M-MIMO configurations, i.e. Horizontal beamwidth adjustable range, Vertical beamwidth adjustable
10 range, Azimuth angle adjustable range, Elevation angle adjustable range
11 3) Network KPIs: e.g. cell downlink/uplink traffic load (GB, RRC connection attempts, average RRC connected UE,
12 maximum RRC connected UE, average active connections (downlink/uplink), DL/UL throughput, DL/UL spectral
13 efficiency, NI (Noise interference) )
14 4) Handover success ratio (inter-RAT, intra-cell, inter-cell)
15 5) Environment data: cell site information (location), inter-site distance, BS system configuration, (e.g. operating
16 frequency, bandwidth, frame structure, transmit power, default beam weight configuration)
17 6) User specific information: e.g. DL SINR, beam ID, and Mobility prediction
18
_______________________________________________________________________________________________
1 Chapter 4 Requirements
2 4.1 Functional Requirements
3 4.1.1 Non-RT RIC Functional Requirements

4
5 Table 4.1.1-1 Non-RT RIC Functional Requirements
REQ Description Note
Non-RT RIC shall support data retrieval and analysis; the data may
include performance, configuration or other data related to the
REQ-Non-RT-RIC-FUN1
application (recommended data shown in required data section for
different use cases).
Non-RT RIC shall support relevant AI/ML model training based on the
data in [REQ-Non-RT-RIC-FUN1] for non-real-time optimization of
REQ-Non-RT-RIC-FUN2
configuration parameters in RAN or near-RT RIC, as applicable for
the use case.
Non-RT RIC shall support relevant AI/ML model training based on the
data in [REQ-Non-RT-RIC-FUN1] for generating/optimizing policies
REQ-Non-RT-RIC-FUN3
and intents to guide the behavior of applications in near-RT RIC or
RAN, as applicable for the use case.
Non-RT RIC shall support training of relevant AI/ML models based on
REQ-Non-RT-RIC-FUN4 the data in [REQ-Non-RT-RIC-FUN1] to be deployed/updated in near-
RT RIC as required by the applications.
REQ-Non-RT-RIC-FUN5 Non-RT RIC shall support performance monitoring and evaluation.
Non-RT RIC shall support a fallback mechanism to prevent drastic
REQ-Non-RT RIC-FUN6 degradation/fluctuation of performance, e.g. to restore to the previous
policy or configuration.
6
7 4.1.2 A1 Interface Functional Requirements
9 Table 4.1.2-1 A1 Interface Functional Requirements
A1 interface shall support communication of policies/intents from

REQ-A1-FUN1
Non-RT RIC to Near-RT RIC.
A1 interface shall support AI/ML model deployment and update from
REQ-A1-FUN2
Non-RT RIC to Near-RT RIC.
A1 interface shall support communication of enrichment information
REQ-A1-FUN3
from Non-RT RIC to Near-RT RIC.
A1 interface shall support feedback from near-RT RIC for monitoring
REQ-A1-FUN4
AI/ML model performance.
A1 interface shall support the policy/intents feedback from Near-RT
REQ-A1-FUN5
RIC to non-RT RIC
10
_______________________________________________________________________________________________
1 4.2 Non-Functional Requirements
2 4.2.1 Non-RT RIC Non-Functional Requirements

3
4 Table 4.2.1-1 Non-RT RIC Non-Functional Requirements
Non-RT RIC shall not update the same policy or configuration

REQ-Non-RT-RIC-NON-FUN1 parameter for a given near-RT RIC or RAN function more often
than once per second
Non-RT RIC shall be able to update policies in several near-
REQ-Non-RT-RIC-NON-FUN2
RT RICs.
5
6 4.2.2 A1 Interface Non-Functional Requirements

7
8 Table 4.2.2-1 A1 Interface Non-Functional Requirements
_______________________________________________________________________________________________
2 Annex A (informative): Near-RT RIC and O1 Requirements
3 A.1 Functional Requirements

4 The following section expands upon the call flows presented in Section X.Y by incorporating the flows between near-
5 RT RIC and underlying RAN components over E2 interface. The intention is to outline the end to end view of the use
6 case and use these requirements and call flows as the starting point for defining detailed requirements for E2 interface
7 and near-RT RIC.
9 Fig.A.1-1 shows end-to-end call flow for traffic steering and QoE optimization, including E2 and near-RT RIC
10
11
12 Figure A.1-1: Traffic steering and QoE optimization end-to-end flow diagram
13
_______________________________________________________________________________________________
1 A.1.1 Near-RT RIC Functional Requirements
3 Table A.1.1-1 Near-RT RIC Functional Requirements
REQ-Near-RT-RIC-FUN1 Near-RT RIC shall support deployment and execution of AI/ML

models from non-RT RIC.
REQ-Near-RT-RIC-FUN2 Near-RT RIC shall support interpreting the policies/intents in [REQ-
A1-FUN1].
REQ-Near-RT-RIC-FUN3 Near-RT RIC shall support AI/ML model performance feedback and
intent/policy feedback to Non-RT RIC.
Near-RT RIC platform should provide an up to date, consistent, and
REQ-Near-RT-RIC-FUN4 query-able view of UE and RAN config, context, state, and
performance data to xApps running in the RIC.
Near-RT RIC platform should support xApp execution with input data,
REQ-Near-RT-RIC-FUN5 ML model inference, and policy execution, to generate the
corresponding RRM enforcement decisions.
Near-RT RIC shall support maintaining UE level measurements and
REQ-Near-RT RIC-FUN6 context information, to be used by algorithms (AI/ML or others) to
provide new knowledge, e.g. mobility prediction, traffic prediction, etc.
REQ-Near-RT RIC-FUN7 Near-RT RIC shall support common data format for UE level
knowledge to be shared with Non-RT RIC
4
5 A.1.2 E2 Interface Functional Requirements

6
7 Table A.1.2-1: E2 Interface Functional Requirements
Support collection of UE and RAN configuration, context, and state

REQ-E2-FUN1 information within a desired latency from when a
described/subscribed event occurs (e.g. UE attach, bearer
setup/modification, handover, etc.).
Support real-time collection of UE and RAN performance
REQ-E2-FUN2 measurements/counters as described in required data section from
O-CU and O-DU/O-RU, within a desired latency, and with
configurable periodicity.
REQ-E2-FUN3 Support per-UE level hand-over control command to O-CU to initiate
handover of UE from source to target node.
Support per-UE level SN change control command (for DC scenario
REQ-E2-FUN4 only) to O-CU to initiate secondary node change of UE from source
node to target node.
Support per-UE level hand over control guidance, e.g., candidate
REQ-E2-FUN5 target cell list, to O-CU to guide the handoff of UE from source to
target node.
REQ-E2-FUN6 Support per-UE level RRM enforcement decisions e.g., per-UE Near-
RT QoS change, dynamic resource allocation change.
REQ-E2-FUN7 Support data collection from RAN to Near-RT RIC, and the time
granularity should be a configurable parameter.
8
_______________________________________________________________________________________________
1 A.1.3 O1 Interface Functional Requirements
3 Table A.1.3-1 O1 Interface Functional Requirements
O1 interface shall support data collection from the RAN and near-RT RIC to
REQ-O1-FUN1 NMS, in the form of performance measurement counters and KPIs (as defined
by 3GPP and will be extended for O-RAN use cases) with time resolution
configurable down to 1 second, and with required aggregation.
REQ-O1-FUN2 O1 interface shall support AI/ML model deployment from Non-RT RIC to Near-
RT RIC.
REQ-O1-FUN3 O1 interface shall support communication of RAN configuration parameters
from Non-RT RIC to NMS.
4
5 A.2 Non-Functional Requirements
6 A.2.1 Near-RT RIC Non-Functional Requirements

7
8 Table A.2.1-1 Near-RT RIC Non-Functional Requirements
REQ-Near-RT-RIC-NON-FUN1 Near-RT RIC should be able to support E2 interface to multiple

O-CUs and DUs.
Near-RT RIC platform should be able to meet the necessary
REQ-Near-RT-RIC-NON-FUN2 latency requirements for xApp execution, including model
inference etc.
Non-RT RIC shall not be critical to the functioning of near-RT
REQ-Near-RT-RIC-NON-FUN3 RIC, which should continue operation in case of non-RT RIC
failure or disconnection of interface.
9
10 A.2.2 E2 Interface Non-Functional Requirements

11
12 Table A.2.2-1: E2 Interface Non-Functional Requirements
REQ-E2-NON-FUN1 Support communication of control commands within desired

latency so as to avoid impacting system stability or SLAs.
13
14
_______________________________________________________________________________________________
1 A.2.3 O1 Interface Non-Functional Requirements
3 Table A.2.3-1 O1 Interface Non-Functional Requirements
_______________________________________________________________________________________________
1 Annex B 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.
8 SECTION 1: DEFINITIONS
9
10 1.1 “Affiliate” means an entity that directly or indirectly controls, is controlled by, or is under common
11 control with another entity, so long as such control exists. For the purpose of this Section, “Control” means
12 beneficial ownership of fifty (50%) percent or more of the voting stock or equity in an entity.
13
14 1.2 “Compliant Portion” means only those specific portions of products (hardware, software or
15 combinations thereof) that implement any O-RAN Specification.
16
17 1.3 “Adopter(s)” means all entities, who are not Members, Contributors or Academic Contributors,
18 including their Affiliates, who wish to download, use or otherwise access O-RAN Specifications.
19
20 1.4 “Minor Update” means an update or revision to an O-RAN Specification published by O-RAN Alliance
21 that does not add any significant new features or functionality and remains interoperable with the prior
22 version of an O-RAN Specification. The term “O-RAN Specifications” includes Minor Updates.
23
24 1.5 “Necessary Claims” means those claims of all present and future patents and patent applications, other
25 than design patents and design registrations, throughout the world, which (i) are owned or otherwise
26 licensable by a Member, Contributor or Academic Contributor during the term of its Member, Contributor
27 or Academic Contributorship; (ii) such Member, Contributor or Academic Contributor has the right to grant
28 a license without the payment of consideration to a third party; and (iii) are necessarily infringed by
29 implementation of a Final Specification (without considering any Contributions not included in the Final
30 Specification). A claim is necessarily infringed only when it is not possible on technical (but not
31 commercial) grounds, taking into account normal technical practice and the state of the art generally
32 available at the date any Final Specification was published by the O-RAN Alliance or the date the patent
33 claim first came into existence, whichever last occurred, to make, sell, lease, otherwise dispose of, repair,
34 use or operate an implementation which complies with a Final Specification without infringing that claim.
35 For the avoidance of doubt in exceptional cases where a Final Specification can only be implemented by
36 technical solutions, all of which infringe patent claims, all such patent claims shall be considered Necessary
37 Claims.
38
39 1.6 “Defensive Suspension” means for the purposes of any license grant pursuant to Section 3, Member,
40 Contributor, Academic Contributor, Adopter, or any of their Affiliates, may have the discretion to include
41 in their license a term allowing the licensor to suspend the license against a licensee who brings a patent
42 infringement suit against the licensing Member, Contributor, Academic Contributor, Adopter, or any of
43 their Affiliates.
44
45 SECTION 2: COPYRIGHT LICENSE
_______________________________________________________________________________________________
2 2.1 Subject to the terms and conditions of this Agreement, O-RAN Alliance hereby grants to Adopter a
3 nonexclusive, nontransferable, irrevocable, non-sublicensable, worldwide copyright license to obtain, use
4 and modify O-RAN Specifications, but not to further distribute such O-RAN Specification in any modified
5 or unmodified way, solely in furtherance of implementations of an O-RAN Specification.
6
7 2.2 Adopter shall not use O-RAN Specifications except as expressly set forth in this Agreement or in a
8 separate written agreement with O-RAN Alliance.
9
10 SECTION 3: FRAND LICENSE
11
12 3.1 Members, Contributors and Academic Contributors and their Affiliates are prepared to grant based on
13 a separate Patent License Agreement to each Adopter under Fair, Reasonable And Non-Discriminatory
14 (FRAND) terms and conditions with or without compensation (royalties) a nonexclusive, non-transferable,
15 irrevocable (but subject to Defensive Suspension), non-sublicensable, worldwide license under their
16 Necessary Claims to make, have made, use, import, offer to sell, lease, sell and otherwise distribute
17 Compliant Portions; provided, however, that such license shall not extend: (a) to any part or function of a
18 product in which a Compliant Portion is incorporated that is not itself part of the Compliant Portion; or (b)
19 to any Adopter if that Adopter is not making a reciprocal grant to Members, Contributors and Academic
20 Contributors, as set forth in Section 3.3. For the avoidance of doubt, the foregoing license includes the
21 distribution by the Adopter’s distributors and the use by the Adopter’s customers of such licensed
22 Compliant Portions.
23
24 3.2 Notwithstanding the above, if any Member, Contributor or Academic Contributor, Adopter or their
25 Affiliates has reserved the right to charge a FRAND royalty or other fee for its license of Necessary Claims
26 to Adopter, then Adopter is entitled to charge a FRAND royalty or other fee to such Member, Contributor
27 or Academic Contributor, Adopter and its Affiliates for its license of Necessary Claims to its licensees.
28 3.3 Adopter, on behalf of itself and its Affiliates, shall be prepared to grant based on a separate Patent
29 License Agreement to each Members, Contributors, Academic Contributors, Adopters and their Affiliates
30 under FRAND terms and conditions with or without compensation (royalties) a nonexclusive, non-
31 transferable, irrevocable (but subject to Defensive Suspension), non-sublicensable, worldwide license
32 under their Necessary Claims to make, have made, use, import, offer to sell, lease, sell and otherwise
33 distribute Compliant Portions; provided, however, that such license will not extend: (a) to any part or
34 function of a product in which a Compliant Portion is incorporated that is not itself part of the Compliant
35 Portion; or (b) to any Members, Contributors, Academic Contributors, Adopters and their Affiliates that is
36 not making a reciprocal grant to Adopter, as set forth in Section 3.1. For the avoidance of doubt, the
37 foregoing license includes the distribution by the Members’, Contributors’, Academic Contributors’,
38 Adopters’ and their Affiliates’ distributors and the use by the Members’, Contributors’, Academic
39 Contributors’, Adopters’ and their Affiliates’ customers of such licensed Compliant Portions.
40
41 SECTION 4: TERM AND TERMINATION

42
43 4.1 This Agreement shall remain in force, unless early terminated according to this Section 4.
44
_______________________________________________________________________________________________
1 4.2 O-RAN Alliance on behalf of its Members, Contributors and Academic Contributors may terminate
2 this Agreement if Adopter materially breaches this Agreement and does not cure or is not capable of curing
3 such breach within thirty (30) days after being given notice specifying the breach.
4
5 4.3 Sections 1, 3, 5 - 11 of this Agreement shall survive any termination of this Agreement. Under surviving
6 Section 3, after termination of this Agreement, Adopter will continue to grant licenses (a) to entities who
7 become Adopters after the date of termination; and (b) for future versions of O-RAN Specifications that
8 are backwards compatible with the version that was current as of the date of termination.
9
10 SECTION 5: CONFIDENTIALITY
11
12 Adopter will use the same care and discretion to avoid disclosure, publication, and dissemination of O-
13 RAN Specifications to third parties, as Adopter employs with its own confidential information, but no less
14 than reasonable care. Any disclosure by Adopter to its Affiliates, contractors and consultants should be
15 subject to an obligation of confidentiality at least as restrictive as those contained in this Section. The
16 foregoing obligation shall not apply to any information which is: (1) rightfully known by Adopter without
17 any limitation on use or disclosure prior to disclosure; (2) publicly available through no fault of Adopter;
18 (3) rightfully received without a duty of confidentiality; (4) disclosed by O-RAN Alliance or a Member,
19 Contributor or Academic Contributor to a third party without a duty of confidentiality on such third party;
20 (5) independently developed by Adopter; (6) disclosed pursuant to the order of a court or other authorized
21 governmental body, or as required by law, provided that Adopter provides reasonable prior written notice
22 to O-RAN Alliance, and cooperates with O-RAN Alliance and/or the applicable Member, Contributor or
23 Academic Contributor to have the opportunity to oppose any such order; or (7) disclosed by Adopter with
24 O-RAN Alliance’s prior written approval.
25
26 SECTION 6: INDEMNIFICATION
27
28 Adopter shall indemnify, defend, and hold harmless the O-RAN Alliance, its Members, Contributors or
29 Academic Contributors, and their employees, and agents and their respective successors, heirs and assigns
30 (the “Indemnitees”), against any liability, damage, loss, or expense (including reasonable attorneys’ fees
31 and expenses) incurred by or imposed upon any of the Indemnitees in connection with any claims, suits,
32 investigations, actions, demands or judgments arising out of Adopter’s use of the licensed O-RAN
33 Specifications or Adopter’s commercialization of products that comply with O-RAN Specifications.
34
35 SECTION 7: LIMITATIONS ON LIABILITY; NO WARRANTY

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

38 ADOPTER’S INDEMNIFICATION OBLIGATIONS, IN NO EVENT SHALL ANY PARTY BE
39 LIABLE TO ANY OTHER PARTY OR THIRD PARTY FOR ANY INDIRECT, SPECIAL,
40 INCIDENTAL, PUNITIVE OR CONSEQUENTIAL DAMAGES RESULTING FROM ITS
41 PERFORMANCE OR NON-PERFORMANCE UNDER THIS AGREEMENT, IN EACH CASE
42 WHETHER UNDER CONTRACT, TORT, WARRANTY, OR OTHERWISE, AND WHETHER OR
43 NOT SUCH PARTY HAD ADVANCE NOTICE OF THE POSSIBILITY OF SUCH DAMAGES.
44
_______________________________________________________________________________________________
1 O-RAN SPECIFICATIONS ARE PROVIDED “AS IS” WITH NO WARRANTIES OR CONDITIONS

2 WHATSOEVER, WHETHER EXPRESS, IMPLIED, STATUTORY, OR OTHERWISE. THE O-RAN
3 ALLIANCE AND THE MEMBERS, CONTRIBUTORS OR ACADEMIC CONTRIBUTORS
4 EXPRESSLY DISCLAIM ANY WARRANTY OR CONDITION OF MERCHANTABILITY,
5 SECURITY, SATISFACTORY QUALITY, NONINFRINGEMENT, FITNESS FOR ANY
6 PARTICULAR PURPOSE, ERROR-FREE OPERATION, OR ANY WARRANTY OR CONDITION
7 FOR O-RAN SPECIFICATIONS.
9 SECTION 8: ASSIGNMENT
10
11 Adopter may not assign the Agreement or any of its rights or obligations under this Agreement or make
12 any grants or other sublicenses to this Agreement, except as expressly authorized hereunder, without having
13 first received the prior, written consent of the O-RAN Alliance, which consent may be withheld in O-RAN
14 Alliance’s sole discretion. O-RAN Alliance may freely assign this Agreement.
15
16 SECTION 9: THIRD-PARTY BENEFICIARY RIGHTS

17
18 Adopter acknowledges and agrees that Members, Contributors and Academic Contributors (including
19 future Members, Contributors and Academic Contributors) are entitled to rights as a third-party beneficiary
20 under this Agreement, including as licensees under Section 3.
21
22 SECTION 10: BINDING ON AFFILIATES

23
24 Execution of this Agreement by Adopter in its capacity as a legal entity or association constitutes that legal
25 entity’s or association’s agreement that its Affiliates are likewise bound to the obligations that are applicable
26 to Adopter hereunder and are also entitled to the benefits of the rights of Adopter hereunder.
27
28 SECTION 11: GENERAL

29
30 This Agreement is governed by the laws of Germany without regard to its conflict or choice of law
31 provisions.
32 This Agreement constitutes the entire agreement between the parties as to its express subject matter and
33 expressly supersedes and replaces any prior or contemporaneous agreements between the parties, whether
34 written or oral, relating to the subject matter of this Agreement.
35 Adopter, on behalf of itself and its Affiliates, agrees to comply at all times with all applicable laws, rules
36 and regulations with respect to its and its Affiliates’ performance under this Agreement, including without
37 limitation, export control and antitrust laws. Without limiting the generality of the foregoing, Adopter
38 acknowledges that this Agreement prohibits any communication that would violate the antitrust laws.
39 By execution hereof, no form of any partnership, joint venture or other special relationship is created
40 between Adopter, or O-RAN Alliance or its Members, Contributors or Academic Contributors. Except as
41 expressly set forth in this Agreement, no party is authorized to make any commitment on behalf of Adopter,
42 or O-RAN Alliance or its Members, Contributors or Academic Contributors.
_______________________________________________________________________________________________
2 In the event that any provision of this Agreement conflicts with governing law or if any provision is held
3 to be null, void or otherwise ineffective or invalid by a court of competent jurisdiction, (i) such provisions
4 will be deemed stricken from the contract, and (ii) the remaining terms, provisions, covenants and
5 restrictions of this Agreement will remain in full force and effect.
6 Any failure by a party or third party beneficiary to insist upon or enforce performance by another party of
7 any of the provisions of this Agreement or to exercise any rights or remedies under this Agreement or
8 otherwise by law shall not be construed as a waiver or relinquishment to any extent of the other parties’ or
9 third party beneficiary’s right to assert or rely upon any such provision, right or remedy in that or any other
10 instance; rather the same shall be and remain in full force and effect.
11
12 ….
13
14
15
_______________________________________________________________________________________________

Training Architecture ORAN-WG2.UsecaseRequirements.v01.00 PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Training Architecture ORAN-WG2.UsecaseRequirements.v01.00 PDF

Uploaded by

Copyright:

Available Formats

ORAN-WG2.Use Case Requirements v01.

O-RAN Working Group 2 (Non-RT RIC & A1 interface)

Copyright © 2019 by the O-RAN Alliance.

Addition of REQ-Non-RT RIC-FUN9 for Non-RT RIC fallback

2019.04.18 01.00.07 Arda Akman (Netsia) Addition of CR:

9 Chapter 2 Objective ............................................................................................................................................ 7

37 Annex A (informative): Near-RT RIC and O1 Requirements ................................................................... 21

1 Annex B O-RAN Adopter License Agreement ............................................................................................ 25

1 1.3 Definitions and Abbreviations

1 Non-RT RIC Non-Real-Time RIC

13 Chapter 3 Use cases

14 3.1 Use case 1: Traffic steering use case

18 3.1.1 Background and Goal of the use case

26 Such current solutions suffer from following limitations:

5 3.1.2 Entities/Resources involved in the use case

2 3.1.3.1 Traffic steering

3 Table 3.1.3-1: Traffic steering

a) KPI objectives or SLAs, e.g., balancing the maximum PRB utilization,

6 3.1.4 Required data

1 3.2 Use case 2: QoE use case

4 3.2.1 Background and Goal of the use case

15 3.2.2 Entities/Resources involved in the use case

2 3.2.3.1 Model training and distribution

3 Table 3.2.3-1: Model training and distribution

Begins when Operator specified trigger condition or event is detected

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

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

3 3.2.3.2 Policy generation and performance evaluation

4 Table 3.2.3-2: Policy generation and performance evaluation

2 Figure 3.2.3-2: Policy generation and performance evaluation flow diagram

4 3.2.4 Required data

17 3.3 Use case 3: 3D-MIMO beamforming optimization use case

1 3.3.1 Background and Goal of the use case

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

23 1) High inter-cell interference

30 3.3.2 Entities/Resources involved in the use case

2 3.3.3.1 3D-MIMO beamforming optimization

3 Table 3.3.3-1: 3D-MIMO beamforming optimization

2 Figure 3.3.3-1: 3D-MIMO beamforming optimization flow diagram

4 3.3.4 Required data

14 4) Handover success ratio (inter-RAT, intra-cell, inter-cell)

2 4.1 Functional Requirements

3 4.1.1 Non-RT RIC Functional Requirements

5 Table 4.1.1-1 Non-RT RIC Functional Requirements

REQ Description Note

7 4.1.2 A1 Interface Functional Requirements

9 Table 4.1.2-1 A1 Interface Functional Requirements

REQ Description Note

A1 interface shall support communication of policies/intents from

1 4.2 Non-Functional Requirements

2 4.2.1 Non-RT RIC Non-Functional Requirements

4 Table 4.2.1-1 Non-RT RIC Non-Functional Requirements

REQ Description Note

Non-RT RIC shall not update the same policy or configuration

6 4.2.2 A1 Interface Non-Functional Requirements

8 Table 4.2.2-1 A1 Interface Non-Functional Requirements

REQ Description Note

2 Annex A (informative): Near-RT RIC and O1 Requirements

3 A.1 Functional Requirements

1 A.1.1 Near-RT RIC Functional Requirements

3 Table A.1.1-1 Near-RT RIC Functional Requirements

REQ Description Note

REQ-Near-RT-RIC-FUN1 Near-RT RIC shall support deployment and execution of AI/ML