O-RAN - wg2.R1 Use Cases and Requirements.v01.00

O-RAN.WG2.R1 Use Cases and Requirements-v01.
00
Technical Specification
O-RAN Working Group 2(Non-RT RIC and A1 interface WG)
R1 Use Cases and Requirements
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.WG2.R1 Use Cases and Requirements-v01.00
Technical Specification
O-RAN Working Group 2(Non-RT RIC and A1 interface WG)
R1 Use Cases and Requirements
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 the 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. Your use is subject to the terms of the O-RAN Adopter License Agreement in the Annex ZZZ 1
O-RAN.WG2.R1-Use Cases& Requirements-v01.00
1 Revision History
Date Revision Author Description
14-09-2021 01.00.00 N. Vidyadhar Blank skeleton

(Ericsson)
07-10-2021 01.00.01 N. Vidyadhar Skeleton with Editorial changes
(Ericsson)
17-03-2022 01.00.02 N. Vidyadhar Implemented CR 0057, CR0058, CR0060 and CR0064
(Ericsson)
01-04-2022 01.00 N. Vidyadhar Spec renamed to 01.00 for publication after addressing the
(Ericsson) editorial comments from Ericsson, Jio, AT&T and Nokia.
________________________________________________________________________________________________
© 2022 O-RAN ALLIANCE e.V. Your use is subject to the terms of the O-RAN Adopter License Agreement in the Annex
ZZZ 2
1 Contents
2 Revision History..................................................................................................................................................2
3 1 Introduction ...............................................................................................................................................5
4 1.1 Scope ...................................................................................................................................................................5
5 1.2 References ...........................................................................................................................................................5
6 1.3 Definitions and Abbreviations .............................................................................................................................5
7 1.3.1 Definitions......................................................................................................................................................5
8 1.3.2 Abbreviations .................................................................................................................................................6
9 2 General ......................................................................................................................................................6
10 3 Requirements ............................................................................................................................................6
11 4 Use cases for Service Management and Exposure ...................................................................................6
12 4.1 Use case 1: Registration and Bootstrap ...............................................................................................................6
13 4.1.1 Overview ........................................................................................................................................................6
14 4.1.2 Background and goal of the use case .............................................................................................................6
15 4.1.3 Entities/resources involved in the use case ....................................................................................................6
16 4.1.4 Solutions ........................................................................................................................................................7
17 4.1.5 Required data .................................................................................................................................................8
18 4.2 Use case 2: Manage Service Registration............................................................................................................8
19 4.2.1 Overview ........................................................................................................................................................8
20 4.2.2 Background and goal of the use case .............................................................................................................8
21 4.2.3 Entities/resources involved in the use case ....................................................................................................9
22 4.2.4 Solutions ........................................................................................................................................................9
23 4.2.5 Required data ...............................................................................................................................................13
24 4.3 Use case 3: Discovery of services .....................................................................................................................13
25 4.3.1 Overview ......................................................................................................................................................13
26 4.3.2 Background and goal of the use case ...........................................................................................................13
27 4.3.3 Entities/resources involved in the use case ..................................................................................................13
28 4.3.4 Solutions ......................................................................................................................................................14
29 4.3.5 Required data ...............................................................................................................................................15
30 4.4 Use case 4: Subscribe service availability .........................................................................................................15
31 4.4.1 Overview ......................................................................................................................................................15
32 4.4.2 Background and goal of the use case ...........................................................................................................15
________________________________________________________________________________________________
ZZZ 3
1 4.4.3 Entities/resources involved in the use case ..................................................................................................15
2 4.4.4 Solutions ......................................................................................................................................................16
3 4.4.5 Required data ...............................................................................................................................................19
4 5 Use cases for Data Management and Exposure Services .......................................................................19

5 6 Use cases for O1-Related Services .........................................................................................................19
6 7 Use cases for O2-Related Services .........................................................................................................19
7 8 Use cases for A1-Related Services .........................................................................................................19
8 9 Use cases for A/ML Workflow Services ................................................................................................20
9 Annex ZZZ: O-RAN Adopter License Agreement ...........................................................................................21
10 Section 1: DEFINITIONS ..................................................................................................................................................21
11 Section 2: COPYRIGHT LICENSE ...................................................................................................................................21
12 Section 3: FRAND LICENSE ............................................................................................................................................22
13 Section 4: TERM AND TERMINATION..........................................................................................................................22
14 Section 5: CONFIDENTIALITY .......................................................................................................................................22
15 Section 6: INDEMNIFICATION .......................................................................................................................................23
16 Section 7: LIMITATIONS ON LIABILITY; NO WARRANTY ......................................................................................23
17 Section 8: ASSIGNMENT .................................................................................................................................................23
18 Section 9: THIRD-PARTY BENEFICIARY RIGHTS......................................................................................................23
19 Section 10: BINDING ON AFFILIATES ..........................................................................................................................23
20 Section 11: GENERAL.......................................................................................................................................................24
21
22
________________________________________________________________________________________________
ZZZ 4
1 1 Introduction
2 1.1 Scope
3 This Technical Specification has been produced by the O-RAN Alliance.
4 The contents of the present document are subject to continuing work within O-RAN and may change following formal
5 O-RAN approval. Should the O-RAN Alliance modify the contents of the present document, it will be re-released by O-
6 RAN with an identifying change of release date and an increase in version number as follows:
7 Release xx.yy.zz
8 where:
9 xx the first two-digit value is incremented for all changes of substance, i.e. technical enhancements, corrections,
10 updates, etc. (the initial approved document shall have xx=01).
11 yy the second two-digit value is incremented when editorial only changes have been incorporated in the
12 document.
13 zz the third two-digit value is included only in working versions of the document indicating incremental
14 changes during the editing process; externally published documents never have this third two-digit value
15 included.
16 The present document specifies the R1 Use cases and Requirements. It is part of a TS-family covering the WG2: R1
17 Interface Specifications.
18 1.2 References
19 The following documents contain provisions which, through reference in this text, constitute provisions of the present
20 document.
21 - References are either specific (identified by date of publication, edition number, version number, etc.) or
22 non-specific.
23 - For a specific reference, subsequent revisions do not apply.
24 - For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including
25 a GSM document), a non-specific reference implicitly refers to the latest version of that document.
26 [1] 3GPP TR 21.905: "3rd Generation Partnership Project; Technical Specification Group Services and System
27 Aspects; Vocabulary for 3GPP Specifications"
28 [2] O-RAN WG2: "R1 General Aspects and Principles"
29 1.3 Definitions and Abbreviations
30 1.3.1 Definitions
31 For the purposes of the present document, the terms and definitions given in 3GPP TR 21.905 [1] and the following apply.
32 A term defined in the present document takes precedence over the definition of the same term, if any, in 3GPP TR 21.905
33 [1].
34 Non-RT RIC: O-RAN non-real-time RAN Intelligent Controller: a logical function in the SMO framework that enables
35 non-real-time control and optimization of RAN elements and resources, AI/ML workflow including model training and
36 updates, and policy-based guidance of applications/features in Near-RT RIC. The Non-RT RIC is comprised of the Non-
37 RT RIC framework and Non-RT RIC applications (rApps).
38 Non-RT RIC framework: Functionality internal to the SMO framework that logically terminates the A1 interface and
39 provides the R1services to rApps through the R1 interface.
________________________________________________________________________________________________
ZZZ 5
1 rApp: Non-RT RIC application: an application designed to consume and/or produce R1 Services.
2 NOTE: rApp’s can leverage the functionality provided by the SMO and Non-RT RIC framework to deliver value
3 added services related to intelligent RAN optimization and operation.
4 1.3.2 Abbreviations
5 For the purposes of the present document, the following abbreviations apply.
6 AuthN Authentication
7 AuthZ Authorization
8 SME Service Management and Exposure
9 2 General
10 The R1 interface is defined between the rApps and the Non-RT RIC framework, as defined in R1 interface: General
11 Aspects and Principles [2].
12 In the use case sequence flows, solid lines shall be used for the message interactions which are defined in O-RAN
13 specifications. The dashed lines shall be used to represent the messages interactions that are not specified in O-RAN
14 specifications or can be implementation specific interactions.
15 3 Requirements
16 NOTE: The Requirements for R1 Interface will be FFS.
17 4 Use cases for Service Management and Exposure
18 4.1 Use case 1: Registration and Bootstrap
19 4.1.1 Overview
20 This use case provides the description and requirements for registering an rApp with the Non-RT RIC/SMO framework.
21 4.1.2 Background and goal of the use case
22 The rApp registration procedure registers the rApp to the Non-RT RIC/SMO framework. It may use the bootstrap
23 service to discover the rApp registration API. To register an rApp, rApp may pass relevant info that may include the
24 rApp name, vendor, software version, and other information needed by the Non-RT RIC/SMO framework.
25 4.1.3 Entities/resources involved in the use case
26 1) SME services Producer

27 a. supports functionality that allows the rApp to retrieve the bootstrap information that enables it
28 to discover the SME services,
29 b. supports functionality to authenticate the rApp,
30 c. assigns the rApp with an ID.
31 2) rApp
________________________________________________________________________________________________
ZZZ 6
1 a. to retrieves the bootstrap information that enables it to discover the SME services,
2 b. initiates the procedure of rApp registration.
3 4.1.4 Solutions
<<Uses>>
Use Case Stage Evolution / Specification
Related use
1) Find the SME service endpoints (Optional),
Goal 2) Register the rApp to the SME services Producer in Non-RT
RIC/SMO framework.
- rApp: entity that requests the rApp registration.
- SME services Producer: entity that handles the registration
Actors and Roles
related messages from/to rApp and optionally handles the
discover bootstrap message.
Assumptions n/a
Preconditions The rApp is instantiated.
Begins when The rApp is instantiated and ready for registration.
Step 1 (O) The rApp will initiate a bootstrap request to find the SME endpoints.
The SME services Producer should responds with the details of the
Step 2 (O)
service endpoints
The rApp sends Registration request to SME services Producer in the Non-
Step 3 (M)
RT RIC/SMO framework passing relevant information needed
Step 4 (M) The SME services Producer processes the rApp registration request that
may include
- performing authentication
- if rApp is authenticated, rApp ID will be assigned to rApp
Step 5 (M) Response to the Registration request along with the rApp ID
Ends when The rApp is allocated with an rAppID
Exceptions n/a
The rApp is registered with the Non-RT RIC /SMO Framework and an
Post Conditions
rApp ID is allocated to the rApp
Traceability
4 Table 4.1.4-1: rApp registration and Bootstrap use case
5 @startuml
6 'https://plantuml.com/sequence-diagram
7 skinparam ParticipantPadding 5
8 skinparam BoxPadding 10
9 skinparam defaultFontSize 12
10 skinparam lifelineStrategy solid
11 autonumber
12 participant rApp as rApp
13 box Non-RT RIC / SMO Framework
14 participant "SME services Producer" as SEF
15 endbox
16 ==bootstrap ==
17 opt
18 rApp -> SEF :<<R1>>bootstrap request
19 SEF -> rApp :<<R1>>bootstrap response
20 end
21 ==rApp registration ==
________________________________________________________________________________________________
ZZZ 7
1 rApp -> SEF:<<R1>>Registration request

2 SEF-> SEF : AuthN
3 note right
4 registration processing
5 assign rAppID
6 end note
7 SEF -> rApp :<<R1>>Registration response (rApp ID)
8 @enduml
9
10
11 Figure 4.1.4-1: Register service use case flow
12 4.1.5 Required data
13 For registering an rApp needs to provide the SME services Producer the security credentials along with e.g., rApp
14 name, vendor, software version, certificates etc. and the role of an rApp is trying to register (Service Producer and /or
15 Service Consumer).
16 The response to the rApp registration includes the status of registration i.e., success or failure, in case of successful rApp
17 registration, the response will also include the rAppID.
18 rApp may obtain information about the SME services endpoints from the producer of bootstrap service.
19 4.2 Use case 2: Manage Service Registration
20 4.2.1 Overview
21 This use case allows an rApp as Service Producer to register its produced services, update a registered service,
22 deregister a registered service as specified in R1 General Aspects and Principles [2].
24 An rApp as a Service Producer can register a new service, rApp that are Service Consumer can discover the services.
25 After an rApp as a Service Producer has successfully registered the services it produces, it can update and/or deregister
26 the registered services.
________________________________________________________________________________________________
ZZZ 8

3 a. supports functionality to register a service produced by an rApp,
4 b. supports authorization of an rApp to determine whether an rApp can register a service, update a registered
5 service, and deregister a registered service,
6 c. supports validation of the new service produced by an rApp that includes determining whether there are
7 conflicts with services registered earlier,
8 d. provides the response of success or failure result to Register service request, Update service registration
9 request and Deregister service request.
10 2) rApp
11 a. supports to initiate the procedure to register a service it produces, update a registered service, and
12 deregister a registered service.
13 4.2.4 Solutions
14 Register Service
<<Uses>>
Related use
Goal The rApp successfully registers a service.
- rApp: entity in the Service Producer role that requests service
registration.
Actors and Roles
- SME services Producer: entity in SMO/Non-RT RIC framework that
handles the service registration.
Assumptions n/a
The rApp is deployed, registered as Service Producer with the SME
Preconditions
services Producer, and optionally has the bootstrap info.
The rApp determines the need to register a service with the SME services
Begins when
Producer.
The rApp will request the SME services Producer to register a service by
Step 1 (M)
providing the rApp ID and service profile.
The SME services Producer checks whether the rApp is authorized to
Step 2 (M)
register a service.
The SME services Producer validates the information about the new service
Step 3 (M) produced by the rApp, that includes determining whether there are conflicts
with services registered earlier.
Step 4 (M) The SME services Producer registers the service and makes the service
endpoint available for discovery.
Step 5 (M) The SME services Producer responds to the rApp with a success result
along with a service identifier.
Ends when The rApp was able to register a service.
n/a
Exceptions
The rApp will be able to update and de-register the registered services with
Post Conditions
the SME services Producer.
Traceability
15 Table 4.2.4.1-1: Register Service use case
16 @startuml
17 'https://plantuml.com/sequence-diagram
18
________________________________________________________________________________________________
ZZZ 9
4
5 autonumber
6
9 participant "SME services Producer" as SME
10 endbox
11
12 ==Register==
13 rApp->SME:<<R1>>Register service request (rAppID,service profile)
14 activate SME
15 SME -> SME : Check AuthZ
16 SME --> SME : Validate
17 SME --> SME : register service
18 SME ->rApp:<<R1>>Register service response (service identifier)
19 deactivate SME
20 @enduml
21
22
23 Figure 4.2.4.1-1: Register service use case flow
________________________________________________________________________________________________
ZZZ 10
1 Update service registration
2
<<Uses>>
Related use
Goal The rApp successfully updates a service registration.
- rApp: entity in the Service Producer role that requests updating a
registered service.
Actors and Roles
handles the update to registered service.
Assumptions n/a
Preconditions The rApp has registered a service to the SME services Producer
The rApp determines the need to update a registered service with the SME
Begins when
services Producer.
The rApp requests the SME services Producer to update a service
Step 1 (M) registration by providing rAppID, service identifier and delta service
profile.
Step 2 (M)
update a registered service
Step 3 (M) The SME services Producer updates the service information and make the
updated service end point available for discovery
Step 4 (M) The SME services Producer responds to rApp with successful result
Ends when The rApp was able to update service registration
Exceptions n/a
The rApp will be able to de-register the registered service in the SME
Post Conditions
services Producer
Traceability
3 Table 4.2.4.2-1: Update service registration use case
4 @startuml
5 'https://plantuml.com/sequence-diagramskinparam ParticipantPadding 5
9 autonumber
13 endbox
14 rApp -> SME : <<R1>>Update service registration request (rApp ID,service identifier, service profile)
15 activate SME
17 SME --> SME : service update
18 SME -> rApp :<<R1>>Update service registration response
19 deactivate SME
20 @enduml
________________________________________________________________________________________________
ZZZ 11
2 Figure 4.2.4.2-1: Update service registration use case flow
3 Deregister Service
4
<<Uses>>
Related use
Goal The rApp successfully deregister a service.
- rApp: entity in the Service Producer role that requests service
deregistration.
Actors and Roles
handles the service deregistration.
Assumptions n/a
Preconditions The rApp has previously registered a service to the SME services Producer.
The rApp determines the need to deregister a registered service with the
Begins when
SME services Producer.
The rApp requests the SME services Producer to deregister a service by
Step 1 (M)
providing with rApp ID and service identifier.
The SME services Producer checks if rApp is authorized to deregister a
Step 2 (M)
service.
Step 3 (M) The SME services Producer removes the service profile..
Step 4 (M) The SME services Producer responds to rApp with success result..
Ends when The rApp was able to deregister a service.
Exceptions n/a
The rApp has deregistered a registered service in the SME services
Post Conditions
Producer, service end point will be no longer available for rApp discovery.
Traceability
5 Table 4.2.4.3-1: Deregister service use case
6 @startuml
11 autonumber
13 box Non-RT RIC /SMO Framework
15 endbox
16 rApp -> SME : <<R1>>Deregister service request (rApp ID,service identifier)
17 activate SME
19 SME --> SME : Remove service profile
________________________________________________________________________________________________
ZZZ 12
1 SME -> rApp :<<R1>>Deregister service response

2 deactivate SME
3 @enduml
5 Figure 4.2.4.3-1: Deregister service use case flow
7 The service profile information includes e.g. the name of the service, service type, communication mechanism, interface
8 endpoint details (such as IP address, port number, URI, protocol), version number, and data format.
9 For registering a service, the rApp needs to provide the rApp ID and the service profile. On successful registration, the
10 SME services Producer assigns a service identifier for the newly registered service and returns it to the rApp.
11 For updating a registered service, the rApp needs to provide the rApp ID, the service identifier and the delta information
12 that needs to be changed in the service profile.
13 For de-registering a registered service, the rApp needs to provide the rApp ID and the service identifier.
14 NOTE: it is up to the design of the authorization mechanism whether the rAppID will be passed as a separate piece
15 of information or will be embedded in or implied by the authorization information.
16 4.3 Use case 3: Discovery of services
17 4.3.1 Overview
18 This use case allows an rApp as a Service Consumer to discover the available services.
20 The Discovery of services is specified as part of Service management and exposure services in R1 General Aspects and
21 Principles [2].
22 An rApp in the role of Service Consumer will be able to discover the available services.

25 a. supports functionality to discover the list of available services,
26 b. supports authorization of an rApp to determine which services an rApp can discover,
________________________________________________________________________________________________
ZZZ 13
1 c. retrieves the stored service information and performs filtering of available services based on selection
2 criteria that may be provided by the rApp,
3 d. provides response of success or failure to Discover service request.
4 2) rApp
5 a. supports initiating the procedure to discover available services, optionally providing selection criteria.
6 4.3.4 Solutions
7 Discover the services
8
<<Uses>>
Use Case Stage Evolution / Specification Related
use
Goal The rApp discovers the available services.
- rApp: entity in the Service Consumer role that request to discover
the available services.
Actors and Roles
- SME services Producer: entity in SMO/Non-RT RIC framework
that handles the discovery of available services.
Assumptions n/a
To discover the available services, the rApp has to be registered with a Service
Preconditions Consumer role.
Begins when The rApp determines the need to discover the available services.
The rApp requests the SME services Producer to discover available services
Step 1 (M)
based on the rAppID and optional selection criteria.
The SME services Producer checks which services the rApp is authorized to
Step 2 (M)
discover.
The SME services Producer responds with the list of available services and
their service identifier/s. The list contains only those available services that
Step 3 (M)
match the selection criteria if those were provided by the rApp, or all available
services otherwise.
Ends when The rApp was able to discover the available services.
Exceptions n/a
Post Conditions The rApp is able to request access to the available services.
Traceability
9
10 Table4.3.4.1-1: Discover service use case
11 startuml
16 autonumber
18 box Non-RT RIC /SMO Framework
20 endbox
21 rApp -> SME : <<R1>>Discover service request(rApp ID)
22 activate SME
23 SME -> SME : CHECK AuthZ
24 SME -> rApp :<<R1>> Discover service response(list of services)
25 deactivate SME
________________________________________________________________________________________________
ZZZ 14
1 @enduml
2
4 Figure 4.3.4.1-1: Discover service use case flow
6 For discovering a service rApp needs to provide the rApp ID and optional selection criteria information such as e.g., name
7 of the service, service type, and capabilities. The SME services Producer responds with a list of services which includes
8 e.g. endpoint information and service identifiers.
9 NOTE: It is FFS whether an rApp may be allowed to discover services for which it is currently not authorized but
10 might be able to obtain authorization later.
11 4.4 Use case 4: Subscribe service availability
12 4.4.1 Overview
13 This use case allows an rApp as Service Consumer to subscribe to notifications and unsubscribe from notifications
14 regarding changes in service availability.
16 The subscribe service availability and unsubscribe service availability procedures are defined as part of Service
17 management and exposure services in R1 GAP [2].
18 The rApp in the role of Service Consumer can subscribe to notifications and unsubscribe from notifications regarding
19 changes in the availability of services.
20

23 a) Supports functionality to subscribe to and unsubscribe from service availability notifications by an rApp,
24 b) Supports notifying the rApp regarding the changes in the availability of services,
25 c) Provides response of success or failure to subscribe service availability request and unsubscribe service
26 availability request.
27 2) rApp
________________________________________________________________________________________________
ZZZ 15
1 a) Supports to initiate requests to subscribe to and unsubscribe from service availability notifications,
2 b) Supports to accept notifications of the changes in service availability from the SME services Producer.
3 4.4.4 Solutions
4 Subscribe to service availability notifications.
<<Uses>>
use
The rApp subscribes to notifications about changes of the availability of
Goal
services.
- rApp: entity in the Service Consumer role that requests subscription
Actors and Roles to service availability notifications.
- SME services Producer: entity that handles the subscription requests.
Assumptions n/a
Preconditions n/a
The rApp determines to subscribe to notifications, regarding changes in the
Begins when
availability of services.
The rApp requests the SME services Producer to subscribe to notifications
Step 1 (M) regarding changes in the available services with rAppID and optional service
identifier/s.
The SME services Producer checks whether the rApp is authorized to send a
Step 2 (M)
subscription request.
Step 3 (M) The SME services Producer responds with subscription identifier.
Ends when The rApp was able to subscribe to notifications.
Exceptions n/a
1. The rApp can receive notifications when there are any changes in the
Post Conditions services availability.
2. The rApp can unsubscribe from service availability notifications.
Traceability
5 Table 4.4.4.1-1: Subscribe to service availability notifications
6 @startuml
7
8 skinparam sequenceArrowThickness 1
11
15 endbox
16 autonumber
17 rApp -> SME : <<R1>> Subscribe service availability request(rApp ID)
18 activate SME
19 SME -> SME : Checks AuthZ
20 SME -> rApp : <<R1>> Subscribe service availability response (subscription identifier)
21 deactivate SME
22 @enduml
________________________________________________________________________________________________
ZZZ 16
1
2 Figure 4.4.4.1-1: Subscribe to of services availability notifications use case flow diagram
3 Notify service availability changes
<<Uses>>
use
Goal The rApp receives notifications about changes in the available services.
- Rapp: entity in the Service Consumer role that receives notifications
on service availability changes.
Actors and Roles
- SME services Producer: entity that sends notifications on service
availability changes.
Assumptions n/a
Pre conditions The rApp has subscribed to notifications on service availability changes.
The SME services Producer determines to send notifications, regarding
Begins when
changes in the available service/s to subscribed rApp.
The SME services Producer detects changes in service/s availability (due to
Step 1 (M) service registration, service update, service de-registration and heartbeat
failure).
The SME services Producer send notifications regarding the changes to be
Step 2 (M) subscribed rApp with subscription identifier and information about service
changes.
Step 3(M) The rApp processes the changes.
Ends when The rApp was able to process the changes in the available service.
Exceptions n/a
Post Conditions n/a
Traceability
4 Table 4.4.4.2-1: Notify service availability changes use case
5
6 @startuml
7
11
12 participant rApp1 as rApp1
13
16 endbox
17
18 autonumber
19 SME --> SME : Trigger changes in the service/s
20 SME -> rApp1 : <<R1>> notify changes \n(subscription identifier, service identifier/s)
21 rApp1 --> rApp1 : Process the changes {Runtime}
22
________________________________________________________________________________________________
ZZZ 17
1 @enduml
2
4 Figure 4.4.4.2-1: Notify service availability changes use case flow diagram
5 4.4.4.3 Unsubscribe from service availability notifications
<<Uses>>
use
Goal The rApp unsubscribes from service availability notifications.
- rApp: entity in the Service Consumer role that request unsubscribe
from service availability notifications.
Actors and Roles
- SME services Producer: entity that process the unsubscribe service
availability request.
Assumptions n/a
Pre conditions The rApp has subscribed to notification changes.
Begins when The rApp determines to unsubscribe from service availability notifications.
The rApp requests the SME services Producer to unsubscribe from service
Step 1 (M)
availability notifications with rAppID, and subscription identifier.
Step 2 (M)
unsubscribe.
Step 3 (M) The SME services Producer sends as a response.
Ends when The rApp was able to unsubscribe from notifications.
Exceptions n/a
Post Conditions The rApp determines is not subscribed to service availability notifications.
Traceability
6 Table 4.4.4.3-1: Unsubscribe from service availability notifications
7 @startuml
8
12
14
17 endbox
________________________________________________________________________________________________
ZZZ 18
1
2 autonumber
3
4 rApp -> SME : <<R1>> Unsubscribe from service availability notifications request(subscription identifier)
5 activate SME
7 SME -> rApp : <<R1>> Unsubscribe from service availability notifications response
8 deactivate SME
9
10 @enduml
11
12
13 Fig 4.4.4.3-1: Unsubscribe service availability use case
15 To receive notifications regarding changes in service availability, The rApp as Service Consumer subscribes to
16 notifications by providing rAppID, and optional service identifier/s. When the SME services Producer successfully has
17 processed the request, it responds on success by providing a subscription identifier.
18 The SME services Producer sends notifications to the subscribed rApp when there are changes in availability for the
19 services by providing subscription identifier, service identifier/s and information about the changes.
20 For unsubscribing from notifications, a subscribed rApp needs to provide subscription identifier,
21 5 Use cases for Data Management and Exposure Services

22 NOTE: Use cases for Data management and exposure services are FFS.
23 6 Use cases for O1-Related Services

24 NOTE: Use cases for O1-Related services are FFS.
25 7 Use cases for O2-Related Services

26 NOTE: Use cases for O2-Related services are FFS.
27 8 Use cases for A1-Related Services

28 Note: Use cases for A1-Related services are FFS.
________________________________________________________________________________________________
ZZZ 19
1 9 Use cases for A/ML Workflow Services

2 Note: Use cases for AI/ML Workflow services are FFS.
________________________________________________________________________________________________
ZZZ 20
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
5 entity 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 1.1 “Affiliate” means an entity that directly or indirectly controls, is controlled by, or is under common control with
9 another entity, so long as such control exists. For the purpose of this Section, “Control” means beneficial ownership of
10 fifty (50%) percent or more of the voting stock or equity in an entity.
11 1.2 “Compliant Implementation” means any system, device, method or operation (whether implemented in hardware,
12 software or combinations thereof) that fully conforms to a Final Specification.
13 1.3 “Adopter(s)” means all entities, who are not Members, Contributors or Academic Contributors, including their
14 Affiliates, who wish to download, use or otherwise access O-RAN Specifications.
15 1.4 “Minor Update” means an update or revision to an O-RAN Specification published by O-RAN Alliance that does
16 not add any significant new features or functionality and remains interoperable with the prior version of an O-RAN
17 Specification. The term “O-RAN Specifications” includes Minor Updates.
18 1.5 “Necessary Claims” means those claims of all present and future patents and patent applications, other than design
19 patents and design registrations, throughout the world, which (i) are owned or otherwise licensable by a Member,
20 Contributor or Academic Contributor during the term of its Member, Contributor or Academic Contributorship; (ii)
21 such Member, Contributor or Academic Contributor has the right to grant a license without the payment of
22 consideration to a third party; and (iii) are necessarily infringed by a Compliant Implementation (without considering
23 any Contributions not included in the Final Specification). A claim is necessarily infringed only when it is not possible
24 on technical (but not commercial) grounds, taking into account normal technical practice and the state of the art
25 generally available at the date any Final Specification was published by the O-RAN Alliance or the date the patent
26 claim first came into existence, whichever last occurred, to make, sell, lease, otherwise dispose of, repair, use or operate
27 a Compliant Implementation without infringing that claim. For the avoidance of doubt in exceptional cases where a
28 Final Specification can only be implemented by technical solutions, all of which infringe patent claims, all such patent
29 claims shall be considered Necessary Claims.
30 1.6 “Defensive Suspension” means for the purposes of any license grant pursuant to Section 3, Member, Contributor,
31 Academic Contributor, Adopter, or any of their Affiliates, may have the discretion to include in their license a term
32 allowing the licensor to suspend the license against a licensee who brings a patent infringement suit against the
33 licensing Member, Contributor, Academic Contributor, Adopter, or any of their Affiliates.
34 Section 2: COPYRIGHT LICENSE
35 2.1 Subject to the terms and conditions of this Agreement, O-RAN Alliance hereby grants to Adopter a nonexclusive,
36 nontransferable, irrevocable, non-sublicensable, worldwide copyright license to obtain, use and modify O-RAN
37 Specifications, but not to further distribute such O-RAN specification in any modified or unmodified way, solely in
38 furtherance of implementations of an O-RAN
39 Specification.
________________________________________________________________________________________________
ZZZ 21
1 2.2 Adopter shall not use O-RAN Specifications except as expressly set forth in this Agreement or in a separate written
2 agreement with O-RAN Alliance.
3 Section 3: FRAND LICENSE
4 3.1 Members, Contributors and Academic Contributors and their Affiliates are prepared to grant based on a separate
5 Patent License Agreement to each Adopter under Fair Reasonable And Non- Discriminatory (FRAND) terms and
6 conditions with or without compensation (royalties) a nonexclusive, non-transferable, irrevocable (but subject to
7 Defensive Suspension), non-sublicensable, worldwide patent license under their Necessary Claims to make, have made,
8 use, import, offer to sell, lease, sell and otherwise distribute Compliant Implementations; provided, however, that such
9 license shall not extend: (a) to any part or function of a product in which a Compliant Implementation is incorporated
10 that is not itself part of the Compliant Implementation; or (b) to any Adopter if that Adopter is not making a reciprocal
11 grant to Members, Contributors and Academic Contributors, as set forth in Section 3.3. For the avoidance of doubt, the
12 foregoing licensing commitment includes the distribution by the Adopter’s distributors and the use by the Adopter’s
13 customers of such licensed Compliant Implementations.
14 3.2 Notwithstanding the above, if any Member, Contributor or Academic Contributor, Adopter or their Affiliates has
15 reserved the right to charge a FRAND royalty or other fee for its license of Necessary Claims to Adopter, then Adopter
16 is entitled to charge a FRAND royalty or other fee to such Member, Contributor or Academic Contributor, Adopter and
17 its Affiliates for its license of Necessary Claims to its licensees.
18 3.3 Adopter, on behalf of itself and its Affiliates, shall be prepared to grant based on a separate Patent License
19 Agreement to each Members, Contributors, Academic Contributors, Adopters and their Affiliates under Fair
20 Reasonable And Non-Discriminatory (FRAND) terms and conditions with or without compensation (royalties) a
21 nonexclusive, non-transferable, irrevocable (but subject to Defensive Suspension), non-sublicensable, worldwide patent
22 license under their Necessary Claims to make, have made, use, import, offer to sell, lease, sell and otherwise distribute
23 Compliant Implementations; provided, however, that such license will not extend: (a) to any part or function of a
24 product in which a Compliant Implementation is incorporated that is not itself part of the Compliant Implementation; or
25 (b) to any Members, Contributors, Academic Contributors, Adopters and their Affiliates that is not making a reciprocal
26 grant to Adopter, as set forth in Section 3.1. For the avoidance of doubt, the foregoing licensing commitment includes
27 the distribution by the Members’, Contributors’, Academic Contributors’, Adopters’ and their Affiliates’ distributors
28 and the use by the Members’, Contributors’, Academic Contributors’, Adopters’ and their Affiliates’ customers of such
29 licensed Compliant Implementations.
30 Section 4: TERM AND TERMINATION
31 4.1 This Agreement shall remain in force, unless early terminated according to this Section 4.
32 4.2 O-RAN Alliance on behalf of its Members, Contributors and Academic Contributors may terminate this Agreement
33 if Adopter materially breaches this Agreement and does not cure or is not capable of curing such breach within thirty
34 (30) days after being given notice specifying the breach.
35 4.3 Sections 1, 3, 5 - 11 of this Agreement shall survive any termination of this Agreement. Under surviving Section 3,
36 after termination of this Agreement, Adopter will continue to grant licenses (a) to entities who become Adopters after
37 the date of termination; and (b) for future versions of O-RAN Specifications that are backwards compatible with the
38 version that was current as of the date of termination.
39 Section 5: CONFIDENTIALITY
40 Adopter will use the same care and discretion to avoid disclosure, publication, and dissemination of O-RAN
41 Specifications to third parties, as Adopter employs with its own confidential information, but no less than reasonable
42 care. Any disclosure by Adopter to its Affiliates, contractors and consultants should be subject to an obligation of
43 confidentiality at least as restrictive as those contained in this Section. The foregoing obligation shall not apply to any
________________________________________________________________________________________________
ZZZ 22
1 information which is: (1) rightfully known by Adopter without any limitation on use or disclosure prior to disclosure;
2 (2) publicly available through no fault of Adopter; (3) rightfully received without a duty of confidentiality; (4) disclosed
3 by O-RAN Alliance or a Member, Contributor or Academic Contributor to a third party without a duty of
4 confidentiality on such third party; (5) independently developed by Adopter; (6) disclosed pursuant to the order of a
5 court or other authorized governmental body, or as required by law, provided that Adopter provides reasonable prior
6 written notice to O-RAN Alliance, and cooperates with O-RAN Alliance and/or the applicable Member, Contributor or
7 Academic Contributor to have the opportunity to oppose any such order; or (7) disclosed by Adopter with O-RAN
8 Alliance’s prior written approval.
9 Section 6: INDEMNIFICATION
10 Adopter shall indemnify, defend, and hold harmless the O-RAN Alliance, its Members, Contributors or Academic
11 Contributors, and their employees, and agents and their respective successors, heirs and assigns (the “Indemnitees”),
12 against any liability, damage, loss, or expense (including reasonable attorneys’ fees and expenses) incurred by or
13 imposed upon any of the Indemnitees in connection with any claims, suits, investigations, actions, demands or
14 judgments arising out of Adopter’s use of the licensed O-RAN Specifications or Adopter’s commercialization of
15 products that comply with O-RAN Specifications.
16 Section 7: LIMITATIONS ON LIABILITY; NO WARRANTY
17 EXCEPT FOR BREACH OF CONFIDENTIALITY, ADOPTER’S BREACH OF SECTION 3, AND ADOPTER’S

18 INDEMNIFICATION OBLIGATIONS, IN NO EVENT SHALL ANY PARTY BE LIABLE TO ANY OTHER
19 PARTY OR THIRD PARTY FOR ANY INDIRECT, SPECIAL, INCIDENTAL, PUNITIVE OR CONSEQUENTIAL
20 DAMAGES RESULTING FROM ITS PERFORMANCE OR NON-PERFORMANCE UNDER THIS AGREEMENT,
21 IN EACH CASE WHETHER UNDER CONTRACT, TORT, WARRANTY, OR OTHERWISE, AND WHETHER OR
22 NOT SUCH PARTY HAD ADVANCE NOTICE OF THE POSSIBILITY OF SUCH DAMAGES. O-RAN
23 SPECIFICATIONS ARE PROVIDED “AS IS” WITH NO WARRANTIES OR CONDITIONS WHATSOEVER,
24 WHETHER EXPRESS, IMPLIED, STATUTORY, OR OTHERWISE. THE O-RAN ALLIANCE AND THE
25 MEMBERS, CONTRIBUTORS OR ACADEMIC CONTRIBUTORS EXPRESSLY DISCLAIM ANY WARRANTY
26 OR CONDITION OF MERCHANTABILITY, SECURITY, SATISFACTORY QUALITY, NONINFRINGEMENT,
27 FITNESS FOR ANY PARTICULAR PURPOSE, ERROR-FREE OPERATION, OR ANY WARRANTY OR
28 CONDITION FOR O-RAN SPECIFICATIONS.
29 Section 8: ASSIGNMENT
30 Adopter may not assign the Agreement or any of its rights or obligations under this Agreement or make any grants or
31 other sublicenses to this Agreement, except as expressly authorized hereunder, without having first received the prior,
32 written consent of the O-RAN Alliance, which consent may be withheld in O-RAN Alliance’s sole discretion. O-RAN
33 Alliance may freely assign this Agreement.
34 Section 9: THIRD-PARTY BENEFICIARY RIGHTS
35 Adopter acknowledges and agrees that Members, Contributors and Academic Contributors (including future Members,
36 Contributors and Academic Contributors) are entitled to rights as a third-party beneficiary under this Agreement,
37 including as licensees under Section 3.
38 Section 10: BINDING ON AFFILIATES
39 Execution of this Agreement by Adopter in its capacity as a legal entity or association constitutes that legal entity’s or
40 association’s agreement that its Affiliates are likewise bound to the obligations that are applicable to Adopter hereunder
41 and are also entitled to the benefits of the rights of Adopter hereunder.
________________________________________________________________________________________________
ZZZ 23
1 Section 11: GENERAL
2 This Agreement is governed by the laws of Germany without regard to its conflict or choice of law provisions.
3 This Agreement constitutes the entire agreement between the parties as to its express subject matter and expressly
4 supersedes and replaces any prior or contemporaneous agreements between the parties, whether written or oral, relating
5 to the subject matter of this Agreement.
6 Adopter, on behalf of itself and its Affiliates, agrees to comply at all times with all applicable laws, rules and
7 regulations with respect to its and its Affiliates’ performance under this Agreement, including without limitation, export
8 control and antitrust laws. Without limiting the generality of the foregoing, Adopter acknowledges that this Agreement
9 prohibits any communication that would violate the antitrust laws.
10 By execution hereof, no form of any partnership, joint venture or other special relationship is created between Adopter,
11 or O-RAN Alliance or its Members, Contributors or Academic Contributors. Except as expressly set forth in this
12 Agreement, no party is authorized to make any commitment on behalf of Adopter, or O-RAN Alliance or its Members,
13 Contributors or Academic Contributors.
14 In the event that any provision of this Agreement conflicts with governing law or if any provision is held to be null,
15 void or otherwise ineffective or invalid by a court of competent jurisdiction, (i) such provisions will be deemed stricken
16 from the contract, and (ii) the remaining terms, provisions, covenants and restrictions of this Agreement will remain in
17 full force and effect.
18 Any failure by a party or third party beneficiary to insist upon or enforce performance by another party of any of the
19 provisions of this Agreement or to exercise any rights or remedies under this Agreement or otherwise by law shall not
20 be construed as a waiver or relinquishment to any extent of the other parties’ or third party beneficiary’s right to assert
21 or rely upon any such provision, right or remedy in that or any other instance; rather the same shall be and remain in full
22 force and effect.
________________________________________________________________________________________________
ZZZ 24

O-RAN - wg2.R1 Use Cases and Requirements.v01.00

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

O-RAN - wg2.R1 Use Cases and Requirements.v01.00

Uploaded by

Copyright:

Available Formats

O-RAN.WG2.R1 Use Cases and Requirements-v01.

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

R1 Use Cases and Requirements

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

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

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

R1 Use Cases and Requirements

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

O-RAN ALLIANCE e.V.

Date Revision Author Description

14-09-2021 01.00.00 N. Vidyadhar Blank skeleton

5 1.2 References ...........................................................................................................................................................5

6 1.3 Definitions and Abbreviations .............................................................................................................................5

8 1.3.2 Abbreviations .................................................................................................................................................6

13 4.1.1 Overview ........................................................................................................................................................6

14 4.1.2 Background and goal of the use case .............................................................................................................6

15 4.1.3 Entities/resources involved in the use case ....................................................................................................6

16 4.1.4 Solutions ........................................................................................................................................................7

17 4.1.5 Required data .................................................................................................................................................8

18 4.2 Use case 2: Manage Service Registration............................................................................................................8

19 4.2.1 Overview ........................................................................................................................................................8

20 4.2.2 Background and goal of the use case .............................................................................................................8

21 4.2.3 Entities/resources involved in the use case ....................................................................................................9

22 4.2.4 Solutions ........................................................................................................................................................9

23 4.2.5 Required data ...............................................................................................................................................13

24 4.3 Use case 3: Discovery of services .....................................................................................................................13

25 4.3.1 Overview ......................................................................................................................................................13

26 4.3.2 Background and goal of the use case ...........................................................................................................13

27 4.3.3 Entities/resources involved in the use case ..................................................................................................13

28 4.3.4 Solutions ......................................................................................................................................................14

29 4.3.5 Required data ...............................................................................................................................................15

30 4.4 Use case 4: Subscribe service availability .........................................................................................................15

31 4.4.1 Overview ......................................................................................................................................................15

32 4.4.2 Background and goal of the use case ...........................................................................................................15

1 4.4.3 Entities/resources involved in the use case ..................................................................................................15

2 4.4.4 Solutions ......................................................................................................................................................16

3 4.4.5 Required data ...............................................................................................................................................19

4 5 Use cases for Data Management and Exposure Services .......................................................................19

11 Section 2: COPYRIGHT LICENSE ...................................................................................................................................21

12 Section 3: FRAND LICENSE ............................................................................................................................................22

13 Section 4: TERM AND TERMINATION..........................................................................................................................22

14 Section 5: CONFIDENTIALITY .......................................................................................................................................22

15 Section 6: INDEMNIFICATION .......................................................................................................................................23

16 Section 7: LIMITATIONS ON LIABILITY; NO WARRANTY ......................................................................................23

17 Section 8: ASSIGNMENT .................................................................................................................................................23

18 Section 9: THIRD-PARTY BENEFICIARY RIGHTS......................................................................................................23

19 Section 10: BINDING ON AFFILIATES ..........................................................................................................................23

20 Section 11: GENERAL.......................................................................................................................................................24

29 1.3 Definitions and Abbreviations

8 SME Service Management and Exposure

17 4 Use cases for Service Management and Exposure

18 4.1 Use case 1: Registration and Bootstrap

21 4.1.2 Background and goal of the use case

25 4.1.3 Entities/resources involved in the use case

26 1) SME services Producer

1 rApp -> SEF:<<R1>>Registration request

11 Figure 4.1.4-1: Register service use case flow

12 4.1.5 Required data

19 4.2 Use case 2: Manage Service Registration

23 4.2.2 Background and goal of the use case

1 4.2.3 Entities/resources involved in the use case

2 1) SME services Producer

23 Figure 4.2.4.1-1: Register service use case flow