O-RAN WG4 IOT 0-v04 00

O-RAN.WG4.IOT.0-v04.
00
Technical Specification
O-RAN Fronthaul Working Group
Fronthaul Interoperability Test Specification (IOT)
Copyright © 2021 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
Copyright © 2021 by the O-RAN ALLIANCE e.V.

Your use is subject to the terms of the O-RAN Adopter License Agreement in Annex ZZZ 1
O-RAN.WG4.IOT.0-v04.00
1 Revision History
Date Revision Description
2019.09.05 01.00 First published version for Fronthaul Interoperability Test Specification (IOT)
2020.03.13 02.00 Second published version for Fronthaul Interoperability Test Specification (IOT)
2020.11.5 03.00 Implement change requests

CIS_2020 10 13-oRAN-WG4 IoT CR CIS-16 SSHv2 ciphers (3)
Update mandated ciphers in the M-Plane IOT profiles
O-RAN.WG4.IOT.v2.00_FM_RVG3
Update the names of the M-Plane IOT profiles to reflect their content following
CUS plane approach.
Minor editorials to text and Figures
Slave replaced by subordinate
Includes text mandating both the IOT Profile and the Spec version are nominated to
ensure the appropriate parameter values are referenced.
Update some references to Release not specific version
Minor updates to title pages.
2021.03.10 04.00 Rename Profiles as Profile Test Configurations NOK-0052
M-Plane correction NEC-0009 rev1
M-Plane system recovery action for S-Plane degraded conditions NEC-0010
Update eaxc_id to align with M-Plane and CUS-Plane description

Update eaxc_id to eaxc-id to align with M-Plane Specification
Include mMIMO IOT profile and associated test equipment update
mMIMO Profile Test Configurations and FFS
________________________________________________________________________________________________
1 Contents
2 Revision History ................................................................................................................................................. 2
3 Chapter 1 Introductory Material ......................................................................................................................... 5
4 1.1 Foreword ............................................................................................................................................................ 5
5 1.2 Scope ................................................................................................................................................................. 5
6 1.2.1 General ......................................................................................................................................................... 5
7 1.2.2 Summary of Test Scenarios.......................................................................................................................... 5
8 1.2.3 Future Enhancements ................................................................................................................................... 6
9 1.3 References.......................................................................................................................................................... 6
10 1.4 Definitions and Abbreviations ........................................................................................................................... 7
11 1.4.1 Definitions .................................................................................................................................................... 7
12 1.4.2 Abbreviations ............................................................................................................................................... 8
13 1.5 Introduction...................................................................................................................................................... 10
14 1.5.1 General ....................................................................................................................................................... 10
15 1.5.2 Fronthaul M-Plane Architectural options ................................................................................................... 10
16 1.5.3 Fronthaul Synchronization options ............................................................................................................ 10
17 Chapter 2 Interoperability Measurements ........................................................................................................ 12
18 2.1 Interoperability Standard Test Definitions ...................................................................................................... 12
19 2.1.1 Standard Test Configurations ..................................................................................................................... 12
20 2.1.1.1 Device Under Test (DUT) .................................................................................................................... 12
21 2.1.1.2 Network Management System (NMS) ................................................................................................. 13
22 2.1.1.3 Testing Tools ........................................................................................................................................ 13
23 2.1.1.4 Time Synchronization........................................................................................................................... 16
24 2.1.1.5 Assumptions ......................................................................................................................................... 16
25 2.1.1.6 Specifications to be used for testing ..................................................................................................... 16
26 2.1.1.7 Interoperability (IOT) Test Profiles ...................................................................................................... 17
27 2.1.1.8 Measurements of interest ...................................................................................................................... 17
28 2.1.2 Standard Test Data Configurations ............................................................................................................ 17
29 2.1.3 Standard Test Execution............................................................................................................................. 17
30 2.2 Interoperability Test Cases .............................................................................................................................. 17
31 2.2.1 M-Plane IOT Test ...................................................................................................................................... 18
32 2.2.1.1 Start-up in hierarchical mode................................................................................................................ 18
33 2.2.1.2 Start-up in hybrid mode ........................................................................................................................ 23
34 2.2.2 S-Plane IOT Test ........................................................................................................................................ 26
35 2.2.2.1 Functional test of O-DU + O-RU using ITU-T G.8275.1 profile (LLS-C1) ........................................ 29
36 2.2.2.2 Functional test of O-DU + bridged network + O-RU using ITU-T G.8275.1 profile (LLS-C2) .......... 31
38 2.2.2.4 Functional test of O-DU + O-RU using ITU-T G.8275.2 profile (LLS-C1) ........................................ 36
41 2.2.2.7 Functional test of O-DU + bridged network + O-RU (LLS-C4) .......................................................... 36
42 2.2.2.8 Performance test of O-DU + Two O-RUs using ITU-T G.8275.1 profile (LLS-C1) ........................... 36
43 2.2.2.9 Performance test of O-DU + bridged network + Two O-RUs using ITU-T G.8275.1 profile
44 (LLS-C2) .............................................................................................................................................. 37
46 (LLS-C3) .............................................................................................................................................. 39
47 2.2.2.11 Performance test of O-DU + Two O-RUs using ITU-T G.8275.2 profile (LLS-C1) ........................... 40
49 ((LLS-C2) ............................................................................................................................................. 40
51 (LLS-C3) .............................................................................................................................................. 40
52 2.2.2.14 Performance test of O-DU + bridged network + Two O-RUs (LLS-C4) ............................................. 40
53 2.2.3 C/U-Plane IOT Test ................................................................................................................................... 40
54 2.2.3.1 Radio Layer 3 C-Plane establishment and Initial Radio U-Plane data transfer .................................... 40
55 2.2.3.2 Radio U-Plane downlink data transfer (Downlink throughput performance) ....................................... 42
56 2.2.3.3 Radio U-Plane uplink data transfer (Uplink throughput performance) ................................................ 44
57 2.2.4 C/U-Plane Delay Management IOT Test ................................................................................................... 46
________________________________________________________________________________________________
1 2.2.4.1 Test environment .................................................................................................................................. 47

2 2.2.4.2 Timing accuracy definition ................................................................................................................... 48
3 2.2.4.3 Delay Management #1, minimum fronthaul latency ............................................................................ 48
4 2.2.4.4 Delay Management #2, maximum fronthaul latency ............................................................................ 49
5 2.2.4.5 Delay Management #3, normal fronthaul latency................................................................................. 50
6 2.2.4.6 Delay Management #4, larger fronthaul latency then supported .......................................................... 52
7 Annex A Profiles used for Interoperability Testing ....................................................................................... 53
8 A.1 M-Plane IOT Profile ........................................................................................................................................ 53
9 A.1.1 M-Plane IOT Profile 1................................................................................................................................ 53
10 A.1.2 M-Plane IOT Profile 2................................................................................................................................ 55
11 A.2 CUS-Plane IOT Profiles .................................................................................................................................. 57
12 A.2.1 NR TDD ..................................................................................................................................................... 57
13 A.2.1.1 NR TDD IOT Profile 1 - NR-TDD-FR1-CAT-A-NoBF ...................................................................... 57
14 A.2.1.2 NR TDD IOT Profile 2 - NR-TDD-FR1-CAT-A-DBF ........................................................................ 61
15 A.2.1.3 NR TDD IOT Profile 3 - NR-TDD-FR2-CAT-A-ABF ........................................................................ 65
16 A.2.1.4 NR TDD IOT M-MIMO Profile 1 - NR-TDD-FR1-CAT-B-mMIMO-RTWeights-BFP .................... 70
17 A.2.1.5 NR TDD IOT M-MIMO Profile 2 - NR-TDD-FR1-CAT-B-mMIMO-RTWeights-ModComp .......... 75
18 A.2.1.6 NR TDD IOT M-MIMO Profile 3 - NR-TDD-FR1-CAT-B-mMIMO-ChInfo-BFP ........................... 79
19 A.2.1.7 NR TDD IOT M-MIMO Profile 4 - NR-TDD-FR1-CAT-B-mMIMO-ChInfo-ModComp ................. 83
20 A.2.2 NR FDD ..................................................................................................................................................... 88
21 A.2.2.1 NR FDD IOT Profile 1 - NR-FDD-FR1(15kHzSCS)-CAT-B-DBF .................................................... 88
22 A.2.2.2 NR FDD IOT Profile 2 - NR-FDD-FR1-CAT-B-DBF......................................................................... 93
23 A.2.2.3 NR FDD IOT Profile 3 - NR-FDD-FR1-CAT-A-NoBF ...................................................................... 97
24 A.2.2.4 NR FDD IOT Profile 4 - NR-FDD-FR1(15kHzSCS)-CAT-A-NoBF ................................................ 100
25 A.2.3 LTE FDD ................................................................................................................................................. 105
26 A.2.3.1 LTE FDD IOT Profile 1 - LTE-FDD-FR1-CAT-B-DBF ................................................................... 105
27 A.2.3.2 LTE FDD IOT Profile 2 - LTE-FDD-FR1-CAT-A-NoBF ................................................................. 109
28 A.2.4 LTE TDD ................................................................................................................................................. 114
29 A.2.4.1 LTE TDD IOT Profile 1 - LTE-TDD-FR1-CAT-A-DBF .................................................................. 114
30 Annex ZZZ: O-RAN Adopter License Agreement ........................................................................................ 120
31 Section 1: DEFINITIONS .............................................................................................................................................. 120
32 Section 2: COPYRIGHT LICENSE ............................................................................................................................... 120
33 Section 3: FRAND LICENSE ........................................................................................................................................ 120
34 Section 4: TERM AND TERMINATION ...................................................................................................................... 121
35 Section 5: CONFIDENTIALITY ................................................................................................................................... 121
36 Section 6: INDEMNIFICATION ................................................................................................................................... 121
37 Section 7: LIMITATIONS ON LIABILITY; NO WARRANTY .................................................................................. 122
38 Section 8: ASSIGNMENT ............................................................................................................................................. 122
39 Section 9: THIRD-PARTY BENEFICIARY RIGHTS .................................................................................................. 122
40 Section 10: BINDING ON AFFILIATES ...................................................................................................................... 122
41 Section 11: GENERAL................................................................................................................................................... 122
42
43
________________________________________________________________________________________________
1 Chapter 1 Introductory Material
2 1.1 Foreword
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 x.y.z
8 where:
9 x the first digit is incremented for all changes of substance, ie, technical enhancements, corrections, updates,
10 etc. (the initial approved document will have x=01).
11 y the second digit is incremented when editorial only changes have been incorporated in the document.
12 z the third digit included only in working versions of the document indicating incremental changes during the
13 editing process.
14 1.2 Scope
15 1.2.1 General
16 The present document specifies the interoperability testing (IOT) for O-DU and O-RU from different vendors connected
17 using the O-RAN fronthaul (FH) interface. It is noted however that the same content can be utilized for the IOT for O-
18 DU and O-RU from the same vendor connected using the O-RAN FH interface.
19 A guiding principle defining the tests in this document shall be that any test must exercise the fronthaul interface to a
20 greater extent than the test prerequisite so that the test is a proper test of some fronthaul functionality or performance.
21 All tests focus on testing the fronthaul interface, but due to the non-intrusive nature of the tests, system-level aspects of
22 the O-DU and O-RU are inevitably part of the interoperability tests too. Because of this, it is recognized that positive
23 test outcomes indicate successful interoperability, but negative results may not be attributed solely to problems in the
24 FH interface and additional investigation may be required.
25 It is also noted that additional test scenarios are required for comprehensive testing of the FH interface functionality and
26 performance, which shall be considered in future WG4 test specification versions.
27 In general, unless otherwise stated, the tests cover LTE (Stand-Alone), NR Non-Stand-Alone (NSA) and NR Stand-
28 Alone (SA). The tests shall be executed using whichever IOT profile(s) are appropriate for the DUTs. See Annex A for
29 details on the IOT profiles.
30 1.2.2 Summary of Test Scenarios

31 The following set of interoperability test cases are defined for the current version of WG4 FH IOT specification.
32 • FH tests focused on the M-Plane:
33 o Start-up (O-RU start-up from the power-on of O-RU to the availability of service)
34 • FH tests focused on the S-Plane:
35 o Synchronization status detection
36 o Frequency and time error (performance)
37 • FH tests focused on the C/U-Planes:
38 o Radio Layer 3 C-Plane establishment and Initial Radio U-Plane data transfer
________________________________________________________________________________________________
1 o Radio downlink U-Plane data transfer (Downlink throughput performance)
2 o Radio uplink U-Plane data transfer (Uplink throughput performance)
3 • FH tests focused on the C/U-Plane Delay Management
4 o Test with minimum, intermediate, maximum, and excess latency.
5 1.2.3 Future Enhancements

6 Additional test cases are under consideration for the future versions of this specification. A non-exhaustive list of
7 candidate test cases for future versions is provided below:
8 • FH tests focused on the M-Plane:
9 o Software management (O-RU software update)
10 o Fault management
11 o File management
12 • FH tests focused on the C/U-Plane:
13 o Beamforming (testing the actual characteristics of the radiated/received signals at O-RU)
14 o Compression (testing different compression methods and IQ bitwidth and validating expected
15 performance)
16 Note: beamforming and compression are tested as part of the IOT cases already specified in Chapter 2.2
17 and the relevant IOT profiles (refer to Annex A for more details). The test cases above extend the
18 capability to test the fronthaul interface in respect of these features.
19 o Multiple O-RUs
20 o Multiple UEs
21 1.3 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.
29 - The versions of the ITU-T documents reflect their publication dates at the time of the writing. For the most
30 recent version, please refer to ITU-T https://www.itu.int/rec/T-REC-G/e.
31
32 [1] 3GPP TR 21.905, “Vocabulary for 3GPP Specifications”
33 [2] O-RAN WG4 Control, User and Synchronization Specification Version 5, January 2021
34 [3] O-RAN WG4 Management Plane Specification Version 5, January 2021
35 [4] O-RAN Management Plane Yang Models Version 5, January 2021
36 [5] ITU-T G.8275.1, Precision time protocol telecom profile for phase/time synchronization with full
37 timing support from the network, ITU, March 2020
38 [6] ITU-T G.8275.2, Precision time protocol telecom profile for phase/time synchronization with
39 partial timing support from the network, ITU, March 2020
________________________________________________________________________________________________
1 [7] ITU-T G.8271.1 “Network limits for time synchronization in packet networks”, ITU, March 2020
2 [8] ITU-T G.8271.2 “Network limits for time synchronization in packet networks with partial timing
3 support from the network”, ITU, Aug 2017
4 [9] ITU-T G.8273 “Framework of phase and time clocks”, March 2018
5 [10] ITU-T G.8261. “Timing and synchronization aspects in packet networks”, August 2019
6 [11] eCPRI Specification v1.0 “Common Public Radio Interface: eCPRI Interface Specification”,
7 August 2017
8 [12] 3GPP TS 36.104, “Evolved Universal Terrestrial Radio Access (E-UTRA); Base Station (BS)
9 radio transmission and reception”
10 [13] 3GPP TS 38.104, “NR; Base Station (BS) radio transmission and reception”
11 [14] 3GPP TS 36.211, “Evolved Universal Terrestrial Radio Access (E-UTRA); Physical channels and
12 modulation”
13 [15] 3GPP TS 38.211, “NR; Physical channels and modulation”, 3GPP, (Release 15.8.0)
14 [16] 3GPP TS 36.331, “Evolved Universal Terrestrial Radio Access (E-UTRA); Radio Resource
15 Control (RRC)”
16 [17] 3GPP TS 38.331, “NR; Radio Resource Control (RRC); Protocol specification”
17 [18] 3GPP TS 36.141, “Evolved Universal Terrestrial Radio Access (E-UTRA); Base Station (BS)
18 conformance testing”, 3GPP, (Release 15.10.0)
19 [19] 3GPP TS 38.141-2, “NR; Base Station (BS) conformance testing Part 2: Radiated conformance
20 testing”, 3GPP, (Release 15.7.0)
21 [20] 3GPP TS 23.401, “General Packet Radio Service (GPRS) enhancements for Evolved Universal
22 Terrestrial Radio Access Network (E-UTRAN) access”, 3GPP, (Release 15.12.0)
23 [21] 3GPP TS 23.502, “Procedures for the 5G System (5GS)”, 3GPP, (Release 15.11.0)
24 [22] 3GPP TS 37.340, “Evolved Universal Terrestrial Radio Access (E-UTRA) and NR; Multi-
25 connectivity”, 3GPP, (Release 15.10.0)
26 [23] 3GPP TS 38.214, “NR; Physical layer procedures for data”, 3GPP, (Release 15.11.0)
27 [24] O-RAN Fronthaul Working Group, Conformance Test Specification Version 2, January 2021
28
29
30 1.4 Definitions and Abbreviations

31 1.4.1 Definitions
32 For the purposes of the present document, the terms and definitions given in 3GPP TR 21.905 [1] and the following
33 apply. A term defined in the present document takes precedence over the definition of the same term, if any, in 3GPP
34 TR 21.905 [1].
35 C-Plane Control Plane: refers specifically to real-time control between O-DU and O-RU, and should not be
36 confused with the UE’s control plane
37 DL DownLink: data flow towards the radiating antenna
38 eNB eNodeB (applies to LTE) <E-UTRAN NodeB / Evolved NodeB>
39 fm-pm Fault Management, Performance Management role
40 gNB gNodeB (applies to NR) <Next Generation NodeB>
41 M-Plane Management Plane: refers to non-real-time management operations between the O-DU and the O-
42 RU
________________________________________________________________________________________________
1 NETCONF Network Configuration Protocol. For details see RFC 6241, “Network Configuration Protocol
2 (NETCONF)”, IETF, June 2011
3 NMS A Network Management System dedicated to O-RU operations
4 NSA Non-Stand-Alone network mode that supports operation of SgNB attached to MeNB
5 O-CU O-RAN Central Unit – a logical node hosting PDCP, RRC, SDAP and other control functions
6 O-DU O-RAN Distributed Unit: a logical node hosting RLC/MAC/High-PHY layers based on a lower
7 layer functional split. O-DU in addition hosts an M-Plane instance.
8 O-RU O-RAN Radio Unit <O-RAN Radio Unit: a logical node hosting Low-PHY layer and RF
9 processing based on a lower layer functional split. This is similar to 3GPP’s “TRP” or “RRH” but
10 more specific in including the Low-PHY layer (FFT/iFFT, PRACH extraction).>. O-RU in
11 addition hosts M-Plane instance.
12 PTP Precision Time Protocol (PTP) is a protocol for distributing precise time and frequency over
13 packet networks. PTP is defined in the IEEE Standard 1588.
14 PDCCH Physical Downlink Control Channel applies for LTE and NR air interface
15 PBCH Physical Broadcast Channel applies for LTE and NR air interface
16 SA Stand-Alone network mode that supports operation of gNB attached to a 5G Core Network
17 SCS OFDM Sub Carrier Spacing
18 SSB Synchronization Signal Block, in 5G PBCH and synchronization signal are packaged as a single
19 block
20 sudo Super-User Do role
21 subordinate The term “subordinate” is used as a replacement for “slave” and is consistent with its use in CUS
22 specification. When consensus emerges on how to eliminate the use of the term “slave” in the
23 referenced standards organization, that approach will be applied to this specification
24 S-Plane Synchronization Plane: Data flow for synchronization and timing information between nodes
25 SyncE Synchronous Ethernet, is an ITU-T standard for computer networking that facilitates distribution
26 of clock signals over the Ethernet physical layer
27 T-BC Telecom Boundary Clock
28 TWAMP Two-Way Active Measurement Protocol
29 UDP User Datagram Protocol
30 UE User Equipment terminology for a mobile device in LTE and NR
31 UL UpLink: data flow from the UE towards the core network, that is from the O-RU towards in the O-
32 DU in a Fronthaul context.
33 U-Plane User Plane: refers to IQ sample data transferred between O-DU and O-RU
34
35 1.4.2 Abbreviations
36 For the purposes of the present document, the abbreviations given in 3GPP TR 21.905 [1] and the following apply. An
37 abbreviation defined in the present document takes precedence over the definition of the same abbreviation, if any, in
38 3GPP TR 21.905 [1].
39 5GS 5G System, comprises the access network, core network and user equipment
40 ARFCN Absolute Radio Frequency Channel Number
41 CC Component Carrier
42 CN Core Network
43 C/U-Plane C-Plane and U-Plane
44 DHCP Dynamic Host Configuration Protocol
________________________________________________________________________________________________
1 DL DownLink
2 DUT Device Under Test
3 eNB eNodeB
4 EARFCN E-UTRA ARFCN
5 EVM Error Vector Magnitude
6 FH Fronthaul
7 fm-pm Fault Management, Performance Management role
8 GSCN Global Synchronization Channel Number
9 gNB gNodeB
10 MeNB Master eNB
11 MIMO Multiple Input Multiple Output
12 M-MIMO Massive MIMO
13 mMIMO M-MIMO
14 NETCONF Network Configuration Protocol
15 NMS Network Management System
16 nms NMS role
17 NSA Non-Stand-Alone
18 O-CU O-RAN Central Unit
19 O-DU O-RAN Distributed Unit
20 O-RU O-RAN Radio Unit
21 OTA Over the Air
22 PBCH Physical Broadcast Channel
23 PCI Physical Cell Identity
24 PRTC Primary Reference Time Clock
25 RF Radio Frequency
26 RSRP Reference Signal Received Power
27 SA Stand-Alone
28 SCS Sub Carrier Spacing
29 SDAP Service Data Adaptation Protocol
30 SgNB Secondary gNB
31 SSB Synchronization Signal Block
32 sudo Super User Do role
33 swm Software fault management role
34 UE User Equipment
35 UL UpLink
36 U-Plane User Plane
37
________________________________________________________________________________________________
1 1.5 Introduction
2 1.5.1 General
3 O-RAN WG4 has specified and published the O-RAN FH interface specifications (CUS-Plane [2] and M-Plane [3])
4 with the objective to enable interoperability of O-DU and O-RU from different vendors. The aim of this document is to
5 further facilitate such multi-vendor IOT using the O-RAN FH interface by defining standard test configurations, IOT
6 profiles and interoperability test cases.
7 It shall be possible to perform interoperability testing in a non-intrusive manner; that is, in a manner in which the
8 network elements under test are not required to support any functionality or mode of operation beyond that required for
9 normal operation in a telecommunication network. However, making the endpoints of the FH interface between the O-
10 DU and O-RU visible would require definition of new interfaces which may entail caching and transport of data.
11 Furthermore, and more importantly, operators require that the total radio system function and perform adequately when
12 integrating O-DU and O-RU from different vendors. Consequentially, this specification approaches interoperability
13 testing by means of system level testing.
14 FH interoperability testing by way of system test involves creation of a stimulus in the O-DU to O-RU direction using
15 an actual or emulated O-CU, potentially with CN support/emulation, and measurement of the result at the output of the
16 O-RU in the RF domain by an actual or emulated UE together with an RF signal/spectrum analyzer as required.
17 Likewise, in the reverse direction, the stimulus to probe the FH in the O-RU to O-DU direction is provided by an actual
18 or emulated UE and is measured at the output of the O-DU by an actual or emulated O-CU with CN support/emulation
19 as required.
20 Inasmuch as the interoperability testing by way of system test involves configuring and collecting results from the O-
21 RU it shall be effected by means of the M-Plane FH interface. For elements that fall outside of this scope, such as the
22 O-DU, the configuration and collection of data and status information for testing purposes may be accomplished by
23 NMS.
24 Interoperability involves testing the FH interface in terms of M-Plane, S-Plane, C-Plane and U-Plane. Some aspects of
25 these planes may be tested independently. However, some tests, such as those that require the devices to be brought into
26 service and a call established entail simultaneous activity across multiple planes.
27 1.5.2 Fronthaul M-Plane Architectural options

28 As described in the “O-RAN WG4 Management Plane Specification” [3], two architectural models are supported,
29 namely a “hierarchical” and a “hybrid” model. As a general guideline the following apply,
30 1. Hierarchical model. The O-RU is entirely managed by one O-DU (sudo) using a NETCONF based M-Plane
31 interface.
32 2. Hybrid model: The architecture allows one or more direct logical interface(s) between management system(s)
33 (performing different roles, nms, fm-pm, swm, etc) and O-RU in addition to a logical interface between O-DU
34 (sudo role) and the O-RU.
35 1.5.3 Fronthaul Synchronization options

36 Various synchronization options have been defined in the O-RAN WG4 CUS-Plane Specification [2] (LLS-C1, LLS-
37 C2, LLS-C3 and LLS-C4). Depending on the specific O-RAN deployment being considered, not all of them might be
38 relevant. When testing the S-Plane, the System Integrator shall identify which of the test cases are relevant depending
39 on the specific deployment scenarios addressed. As a general guideline the following applies:
40 1. Direct connection between O-DU and O-RU:
41 LLS-C1 is generally the main sync option to be validated
42 LLS-C4 may be considered as an alternative or as a complement to LLS-C1
43 2. Bridged network between O-DU and O-RU
________________________________________________________________________________________________
1 LLS-C2 for cases where the synchronization is delivered to the O-RU via the O-DU and over the bridged
2 network. In this case the PRTC/PRC may be embedded in the O-DU or may be located anywhere in the
3 network (connected via backhaul or FH transport).
4 LLS-C3 for cases when the synchronization is distributed to the O-RU without involving the O-DU In this case
5 the PRTC/PRC may be located anywhere in the network (connected via backhaul or FH transport) and may
6 also be co-located with the O-DU.
7 LLS-C4 may be considered as alternative or as a complement to LLS-C2/LLS-C3. LLS-C4 is considered for

8 future versions of the specification.
9 The FH focused tests for S-Plane for the current version of this specification covers LLS-C1, LLS-C2 and LLS-C3
10 using the ITU-T G.8275.1 [5] profile (Full Timing Support). FH focused tests for S-Plane for LLS-C1, LLS-C2 and
11 LLS-C3 using the ITU-T G.8275.2 [6] profile (Partial Timing Support), and LLS-C4 are for future study.
12
________________________________________________________________________________________________
1 Chapter 2 Interoperability Measurements
2 2.1 Interoperability Standard Test Definitions

3 2.1.1 Standard Test Configurations
4 Interoperability testing is performed to prove that the end-to-end functionality between the O-DU and O-RU is as
5 required by the O-RAN FH CUS-Plane [2] and M-Plane [3] specifications on which these components are based. This
6 requires system level testing with O-DU and O-RU as an integrated system.
7 2.1.1.1 Device Under Test (DUT)

8 The case where the O-DU and O-RU are provided by different vendors is the focus of this document, but the case where
9 both are from the same vendor is also valid.
10 The O-DU and O-RU, with their interconnecting FH, is considered as the DUT. This is the same whether the O-CU and
11 O-DU are implemented as a combined node, or as stand-alone nodes.
12 For simplicity and without prejudice the tests in the following sections are defined with reference to a stand-alone O-
13 DU. However, the tests apply equally when the O-DU is replaced by the O-DU functionality of a combined O-CU/O-
14 DU and where the Layer 2 and Layer 3 radio processing on the network side is provided by the O-CU functionality of
15 the combined-node. Any differences to the test due to replacement of the stand-alone O-DU with a combined O-CU/O-
16 DU are detailed as they arise.
17 The simplest test configuration involves a single O-DU and a single O-RU. In this configuration, the O-DU and O-RU
18 are labelled as DUT1(O-DU) and DUT1(O-RU) respectively.
19 More advanced test configurations will involve defining the cardinality between the 1…M O-DU(s) and 1…N O-RU(s)
20 as part of the test scenario which will determine the configuration required.
21 An example of such test configuration is to have a single O-DU connected to multiple N O-RUs. In this example, the O-
22 DU is labelled as DUT1(O-DU) and the O-RU(s) are labelled as DUT1(O-RU) ... DUTN(O-RU) accordingly.
23 A second example is to have multiple M O-DUs connected to multiple N O-RUs. In this second example, the O-DUs
24 are labelled as DUT1(O-DU) … DUTM(O-DU) and the O-RU(s) are labelled as DUT1(O-RU) ... DUTN(O-RU)
25 accordingly. However, deployment scenarios where a single O-RU is managed and used by more than one O-DU is not
26 addressed in this version of the WG4 FH IOT Specification.
27 External physical and or logical connection between the O-DUs and O-RUs are to be specified in the IOT profiles (eg.
28 number of 10/25/40GE, physical medium eg. fiber), see Annex A for details.
29 IOT test cases defined in the following sections of this specification shall be executed using whichever IOT profile(s)
30 that are appropriate for the DUTs. See Annex A for more details on the IOT profiles.
31
32 Figure 2-1: The simplest DUT configuration
________________________________________________________________________________________________
1 2.1.1.2 Network Management System (NMS)

2 Network Management System (NMS) is required to support M-Plane testing particularly in the Hybrid architecture
3 model as the O-RU has logical connection with the NMS [3]. In the hierarchical model, the NMS manages the O-DU
4 and the O-DU manages the O-RU respectively.
5 External physical and or logical connection between the NMS and O-DUs and O-RUs are to be specified in the IOT
6 profiles (eg. number of 10/25/40GE, physical medium eg. fiber), see Annex A for details.
8 Figure 2-2: The relationship between DUT and NMS (hybrid mode connection to O-RU shown dashed)
9 2.1.1.3 Testing Tools

10 One of the key objectives of interoperability testing is to validate the functionality of production grade DUTs. Hence it
11 is important to ensure that the DUTs are not negatively impacted with the utilization of internal functions solely to
12 support interoperability testing. ie, DUTs are not expected to be testing tools when deployed in production networks and
13 therefore DUTs should not be used as testing tools during interoperability tests.
14 Interoperability tests are performed with a set of testing tools which are used to both apply active stimulus and as well
15 as passive monitoring and measurements of the DUTs.
16 The test is applicable to deployment scenarios where the O-CU and O-DU are implemented as separate nodes connected
17 by an F1 interface and scenarios where they are implemented as a combined node without an accessible F1 interface.
18 The deployment scenario where the 4G LTE eNB is implemented as separate 4G O-CU and 4G O-DU nodes connected
19 by a W1 interface is considered for future versions of the WG4 FH IOT Specification when 3GPP standardization work
20 for the W1 interface is complete.
21 Active stimulus testing tools
22 • 5G NR O-CU or O-CU emulator either as a separate node or as a combined node with O-DUs (DUT):
23 used to provide Layer 2 and Layer 3 radio processing on the network side. In case of stand-alone nodes,
24 terminates the 3GPP 5G F1 interface with the O-DU (DUT).
25 o O-CU and O-CU emulator can be connected to either a real Core network or emulated Core. An
26 emulated Core can be simpler to deploy for interoperability testing purposes.
27 o External physical and or logical connection between the O-CU or O-CU emulator with the O-DU
28 (DUT), if any, will be lab setup dependent either through physical or wireless medium
29 • 4G LTE MeNB or MeNB emulator: used to terminate the 3GPP EN-DC X2 interface with the 5G NR
30 O-CU or O-CU emulator
31 o Required when the DUTs (O-DU and O-RU) are configured to operate 5G NR NSA option 3/3a/3x.
________________________________________________________________________________________________
1 o 4G LTE MeNB or MeNB emulator can either have physical or logical connection with the Test UE or
2 UE emulator. RF connection between the 4G LTE MeNB or MeNB emulator with the Test UE or UE
3 emulator will be either through cabled connection or Over the Air (OTA).
4 • Test UEs and/or UEs emulator and optional beamforming network (for MIMO tests): used to
5 generate stateful device connections and traffic to validate the O-DU and O-RU implementation of the O-
6 RAN FH interface protocols as these are stimulated by the 3GPP upper layer protocols. The beamforming
7 network (BFN), for example a Butler Matrix, is used to generate a static RF channel with rank not lower
8 than the number of spatial streams required for the MIMO IOT test profile.
9 o Required so that the O-RU which is the DUT does not need to be put into a “test mode” which does
10 not happen in live deployments.
11 o Test UEs will require SIM cards which are pre-provisioned with subscriber profiles. UEs used for
12 testing can be simpler to setup but given that these Test UEs are designed to be commercial UEs with
13 possibly certain diagnostic functions enabled for logging purposes, they are limited in terms of
14 configurability.
15 o UEs emulator will require SIM profile configuration with the subscriber’s profiles. UEs emulator can
16 be used in test scenarios which require multiple UEs’ sessions, more flexibility and configurability to
17 help drive test scenarios.
18 o RF connection between the Test UEs or UEs emulator with the O-RU (DUT) will be either through
19 cabled connection or OTA. However, in case BFN is used, the RF connection between the Test UEs
20 or UEs emulator and the BFN is via cable and the RF connection between BFN and O-RU (DUT) is
21 also via cable. The use of OTA for MIMO tests is FFS.
22
23
24 Figure 2-3: Test set-up for stand-alone (left) and combined (right)
25
26 Passive monitoring and measurements testing tools
27 • Test UEs and/or UEs emulator: used to produce measurements and logs
28 o Measurements and KPIs logs for test case validation and reporting
29 o Diagnostics logs for troubleshooting purposes which can help with test setup validation and root cause
30 analysis for failed test cases
________________________________________________________________________________________________
1 o Diagnostics mode must be enabled on the Test UEs for diagnostic logging purposes. Device logging
2 tools must be connected to the Test UEs for logging purposes.
3 o UEs used for testing can be simpler to setup but given that given that these Test UEs are designed to
4 be commercial UEs, they are limited in terms of diagnostic logging capabilities due to limited
5 processing and buffer space.
6 o UEs emulator can be used in test scenarios which require extensive diagnostics capabilities.
7 • Application Test Server: An endpoint application test traffic emulator which can be used to generate
8 and/terminate various traffic streams to or from the Test UEs/UEs emulator respectively. May provide one
9 or more of these options,
10 o Stateful traffic, eg. TCP, TWAMP
11 o Stateless traffic eg. UDP
12 o Required to place traffic load on the DUT
13 o External physical and or logical connection between Application Test Server and O-CU/O-CU
14 emulator is out of scope of the specification
15 • Test results and KPIs reporting which can be provided through one or more of these options
16 o UE logging tools which are connected to the Test UEs
17 o Device emulator reporting dashboards typically built in as part of the Device emulator solution
18 o External dashboard and reporting applications
19 • FH Protocol Analyzer: used for protocol analysis of O-RAN FH protocols to achieve the following
20 o Test case validation and troubleshooting purposes which can help with test setup validation and root
21 cause analysis for test cases which fail
22 o Decode and validation of M-Plane flow sequencing prior to SSH secure connection establishment
23 o Monitoring traffic from the O-RAN FH typically through a tap or span port. Taps are typically
24 preferred as span ports are less reliable but can be used if taps are not readily available in the test lab.
25 Connectivity specifics (eg. number of 10/25/40GE) are to be specified in the IOT profiles (see Annex
26 A for details).
27 • RF Spectrum and Beam Signal Analyzer: used for RF and Beam power and quality analysis for,
28 o Test case validation and troubleshooting which can help with test setup validation and root cause
29 analysis for test cases which fail
30 Eg. the Beam Signal Analyzer can be used to validate that the O-RUs (DUT) are in-service,
31 configured and operating correctly, which in case of 5G, includes validating that the SS/PBCH blocks
32 (SSB) are configured with the correct Sub Carrier Spacing (SCS), transmitted at the correct frequency
33 locations (can be offset from the center frequency), and in case of both 4G and 5G, burst periods with
34 the correct Physical Cell Identities (PCI), Beam Identifiers and, expected power and quality.
35 o RF Spectrum and Beam Signal Analyzer performs OTA RF measurements and signal analysis
36 • O-CU or O-CU emulator
37 • MeNB or MeNB emulator
38 • Core or Core emulator
39 o Used to produce measurements and diagnostics logs for troubleshooting purposes which can help with
40 test setup validation and root cause analysis for test cases which fail
41
________________________________________________________________________________________________
1
2 Figure 2-4: Test set-up for stand-alone (left) and combined (right)
3 2.1.1.4 Time Synchronization

4 All the components including the DUTs (O-DUs and O-RUs) and the Testing Tools are required to be synchronized to a
5 common system time and master time source unless otherwise stated.
6 Synchronization Plane (S-Plane) configuration for the DUTs is specified in the IOT profiles (see Annex A for details).
7 Test tools shall be time synchronized to the master timing source with PTP.
8 2.1.1.5 Assumptions
9 In this version of the WG4 FH IOT specifications, the following assumptions apply
10 • All wireline transport interfaces and the air interface are assumed to conform to ideal conditions (no
11 impairments).
12 • All wireless connection assumed to adopt 3GPP approaches for “ideal” RF environment for test setup.
13 • O-DU and O-RU comply to the same version of the O-RAN FH interface specifications.
14 • All elements in the interoperability test and the supporting test environment, where 3GPP support is
15 relevant, comply to the same version of the 3GPP Specification.
16 • All O-RUs involved in a test are of the same category; all A or all B.
17 2.1.1.6 Specifications to be used for testing

18 In this version of the WG4 FH IOT specifications, the following sets of specifications and releases/versions shall be
19 supported
20 • O-RAN FH
21 o Control, User and Synchronization Plane Specification [2]
22 o Management Plane Specification [3]
23 o Management Plane Yang Models [4]
24 • eCPRI
________________________________________________________________________________________________
1 o eCPRI Specification V1.0 “Common Public Radio Interface: eCPRI Interface Specification” [11]
2 It is important to ensure that all DUTs (O-DU and O-RU) and Testing Tools use compatible
3 release/version of the O-RAN FH and eCPRI specifications [11] which in this version of the WG4 FH
4 IOT Specification is ensured by use of the same version.
5 • 3GPP
6 o Release 15 December 2018 and later versions specifications
7 It is important to ensure that all DUTs (O-DU and O-RU) and Testing Tools use compatible
8 release/version of the 3GPP specifications, which in this version of the WG4 FH IOT Specification is
9 ensured by use of the same version.
10 2.1.1.7 Interoperability (IOT) Test Profiles

11 The IOT Profiles are included in Annex A. Additional Profiles will be added in future releases of WG4 FH IOT
12 Specification.
13 2.1.1.8 Measurements of interest

14 • Availability (eg. are the DUTs in service)
15 • Accessibility (eg. can the device connect to the network)
16 • Retainability (eg. can the device connection be maintained)
17 • Mobility (eg. moving between two O-RUs)
18 • Integrity (eg. data transfers between the device and the network)
19 2.1.2 Standard Test Data Configurations

20 The test data configurations are defined as part of the IOT profiles in Annex A.
21 2.1.3 Standard Test Execution

22 Most interoperability tests will follow a standard execution plan although individual tests are expected to deviate from
23 this in some way. By defining the standard execution plan an understanding of how tests are arranged can be gained,
24 thereafter examining individual tests can reveal how deviations from the standard execution plan may be defined.
25 2.2 Interoperability Test Cases

26 As stated in the introduction, interoperability involves testing the FH interface in terms of M-Plane, S-Plane, C-Plane
27 and U-Plane. Some aspects of these planes may be tested independently. However, some tests, such as those that require
28 the devices to be brought into service and a call established entail simultaneous activity across multiple planes
29 Each interoperability test provides 1) test description and applicability, 2) the minimum requirements and prerequisites
30 listing required testing tools as required, 3) test purpose and scope, 4) testability requirements imposed on the O-RU
31 and O-DU, 5) test methodology with procedural description as required, 7) the test requirement and expected test result.
32 Failure conditions are not addressed.
33 The following set of IOT cases are defined in this document.
34 M-Plane IOT Test
35 1. Startup Installation: O-DU and O-RU getting in Service
36 S-Plane IOT Tests
________________________________________________________________________________________________
1 1. Functional test of O-DU + O-RU using ITU-T G.8275.1 profile (LLS-C1)
2 2. Functional test of O-DU + bridged network + O-RU using ITU-T G.8275.1 profile (LLS-C2)
3 3. Functional test of O-DU + bridged network + O-RU using ITU-T G.8275.1 profile (LLS-C3)
4 4. Performance test of O-DU + Two O-RUs using ITU-T G.8275.1 profile (LLS-C1)
5 5. Performance test of O-DU + bridged network + Two O-RUs using ITU-T G.8275.1 profile (LLS-C2)
6 6. Performance test of O-DU + bridged network + Two O-RUs using ITU-T G.8275.1 profile (LLS-C3)
7 C/U-Plane IOT Tests
8 1. Radio Layer 3 C-Plane establishment and Initial Radio U-Plane data transfer
9 2. Radio U-Plane downlink data transfer (Downlink throughput performance)
10 3. Radio U-Plane uplink data transfer (Uplink throughput performance)
11 C/U-Plane Delay Management Test
12 1. Test with minimum fronthaul latency
13 2. Test with maximum fronthaul latency
14 3. Test with a fronthaul latency value between maximum and minimum
15 4. Test larger fronthaul latency then supported
16 2.2.1 M-Plane IOT Test

17 The M-Plane IOT test for hierarchical mode is described in Section 2.2.1.1 and the respective test for hybrid mode is
18 described in Section 2.2.1.2. Separate IOT profiles are defined for each mode. In this version of the specification NMS
19 operation in hybrid mode is limited to read-only operation.
20 2.2.1.1 Start-up in hierarchical mode
21 2.2.1.1.1 Test Description and Applicability

22 This scenario is MANDATORY.
23 The DUT is composed of single O-DU and single O-RU.
24 Test scenario refers to Chapter 3 “Start-up” in hierarchical architecture for M-Plane [3].
25 2.2.1.1.2 Minimum Requirements (Prerequisites)

26 Single O-DU (DUT1(O-DU)) and a single O-RU (DUT1(O-RU))
27 • Must be connected through the O-RAN FH
28 Assumptions which are required for this test scenario
29 1. DHCP server is configured for test purposes (either function served by O-DU or external DHCP server with O-
30 DU or router as relay – that should have no impact on test scenario). In case of external DHCP server -
31 Configuration of DHCP server and DHCP procedures are excluded from validation of IOT.
32 2. As IPv6 support is optional, only IPv4 transport connection for M-Plane is used in this test.
33 3. A combination of VLAN identity and MAC address is only used for C/U- Plane connectivity.
34 4. Network between O-DU and O-RU allows for connectivity between actors.
________________________________________________________________________________________________
1 5. O-RU has account configured with sudo access privilege. O-DU knows credentials of sudo account available
2 at O-RU.
3 6. Appropriate software file for O-RU is pre-installed in O-RU and corresponding manifest.xml is located in O-
4 DU. No software upgrade is required during startup test sequence of O-RU for this IOT test case.
5 Testing tools which are required for this test scenario
6 1. FH Protocol Analyzer monitoring traffic between O-DU and O-RU is used for validation of M-Plane
7 procedural flows and contents of messages prior to the establishment of the SSH connection for M-Plane and
8 when certain procedures do not use encryption (eg., loopback messages and responses of IEEE 802.1Q).
9 2.2.1.1.3 Test Purpose and Scope

10 Purpose of this test is to validate the startup sequence of O-RU and the interface to DHCP server and NETCONF client
11 in O-DU for the start-up scenario.
12 The detailed steps outlined in this test case are for informational purposes and can be useful for troubleshooting
13 purposes in the event that the test case fails. Procedures which are not encrypted with SSH can be observed with the FH
14 Protocol Analyzer for validation of the test progress.
15 Notwithstanding this being an M-Plane test, correct evaluation of the success of the M-Plane operation requires also
16 that the fronthaul C-Plane and U-Plane also be operational, at least in the DL direction.
17 2.2.1.1.4 Testability requirements imposed on O-RU and O-DU

18 The appropriate software runs on the O-RU and O-DU for the test purpose.
19 2.2.1.1.5 Methodology and Initial Conditions

20 1. There is physical connectivity between O-RU and O-DU
21 2. O-DU is powered up and in service or running
22 3. DHCP server is connected and available
23 4. O-RU is powered up for this start-up test scenario
24 5. The credential information (default username and password) is commonly pre-installed in O-DU and O-RU as
25 one of test assumptions in 2.2.1.1.2.
26 2.2.1.1.6 Procedure: M-Plane start up test
27 2.2.1.1.6.1 Step: Transport layer initialization
28 1. Depending on initial condition – either power-on to O-RU or physical network connection is enabled between
29 O-RU and O-DU.
30 2. FH Protocol Analyzer observation: DHCP Discovery coming from O-RU’s MAC address
31 Note: message is sent as part of VLAN scan procedure, hence it can be in serial sequence “VID after VID with
32 timer in between” or in parallel sequence “burst to subset of VIDs, timer, another burst to different subset of
33 VIDs”. FH Protocol Analyzer confirms that the O-RU includes vendor class (option 60) or vendor-identifying
34 vendor class (option 124) in the DHCP DISCOVER.
35 3. FH Protocol Analyzer observation: VLAN scan continues until response from DHCP server is received.
36 4. FH Protocol Analyzer observation: O-RU continues DHCP procedure using only the VID on which response
37 from DHCP server has been received.
38 5. FH Protocol Analyzer observation: DHCP procedure is finished by DHCP Acknowledgement message sent
39 towards O-RU. As a result of DHCP procedure, O-RU obtains its own IP details plus IP (option 43) or FDQN
40 of corresponding NETCONF Client in O-DU.
________________________________________________________________________________________________
1 2.2.1.1.6.2 Step: RU calls home to NETCONF client (TCP connection establishment)
2 1. FH Protocol Analyzer observes Call Home – a TCP session establishment initiated by O-RU towards O-DU
3 2.2.1.1.6.3 Step: SSH Secure connection establishment
4 1. SSH session establishment initiated by O-DU towards O-RU.
5 2.2.1.1.6.4 Step: NETCONF Capability discovery
6 1. NETCONF Hello message sent by O-RU towards O-DU. The message exposes capability of ietf-yang-library
7 2. NETCONF Hello message sent by O-DU towards O-RU
8 3. <rpc><get> message sent by O-DU to O-RU. The <rpc><get> has <modules-state xlsnm =
9 “urn:ietf:params:xml:ns:yang:ietf-yang-library”> subtree filter imposed
10 4. <rpc><reply> message sent by O-RU to O-DU. The message contains content of leaf “modules-state” of ietf-
11 yang-library.yang module
12 2.2.1.1.6.5 Step: Optional provisioning of new management accounts
13 Note: this step is intentionally omitted as pre-provisioned O-RU is expected for IOT (meaning: no need to perform
14 optional step and configure supplementary management accounts).
15 2.2.1.1.6.6 Step: Initial process of NETCONF Subscribe for each stream
16 1. NETCONF “create-subscription” RPC message(s) sent by O-DU towards O-RU. Number of NETCONF
17 subscriptions is up to O-DU.
18 Note: O-DU can subscribe itself to default event stream or to specific streams of events. In case no subscription
19 to default stream is performed, then O-DU shall subscribe itself at least to event streams “supervision-
20 notification” and “alarm-notif”. Subscription to other streams is optional, however not prohibited.
21 2. NETCONF “create-subscription” RPC Reply messages sent by O-RU for each RPC message
22 2.2.1.1.6.7 Step: Supervision of NETCONF connection
23 1. Periodic sequence of NETCONF messages:
24 a. supervision-notification sent by O-RU towards O-DU
25 b. RPC supervision-watchdog-reset sent by O-DU towards O-RU
26 c. RPC reply sent by O-RU towards O-DU
27 Note: in above sequence following timers shall be respected: “supervision-notification-interval”, “guard-timer-

28 overhead” sent as parameters in RPC supervision-watchdog-reset (O-DU -> O-RU) and “next-update-at” sent as
29 parameter in RPC reply (O-RU -> O-DU).
30 2.2.1.1.6.8 Step: Retrieval of O-RU information and Additional configuration
31 1. O-DU sends <rpc><get><filter=”subtree”> to get each yang module listed in ietf-yang-library.yang in O-RU,
32 for example
33 o ietf-hardware augmented by o-ran-hardware
34 o ietf-interface augmented by o-ran-interfaces
35 o o-ran-operations
36 o o-ran-transceiver
37 o o-ran-sync
________________________________________________________________________________________________
1 o o-ran-mplane-int
2 o o-ran-lbm
3 o o-ran-performance-management
4 o o-ran-delay-management
5 o o-ran-module-cap
6 o o-ran-alarm-id
7 o o-ran-fan
8 o o-ran-supervision
9 o o-ran-user mgmt
10 2. O-RU responds with <rpc-reply><data> for each yang module per <rpc><get>
11 3. O-DU sends <rpc><edit-config> to each configurable yang module for additional configuration to O-RU
12 whenever it is necessary
13 4. O-RU responds with <rpc-reply><ok/>
14 Note: The configurable yang modules are o-ran-sync, o-ran-lbm, o-ran-operations and others (up to O-DU
15 implementation) except o-ran-uplane-conf, o-ran-processing-element, ietf-interface augmented by o-ran-
16 interfaces. Additional configuration of step 3 and 4 can be examined between Chapters 2.2.1.1.6.9 and
17 2.2.1.1.6.10.
18 2.2.1.1.6.9 Step: Software management
19 1. O-DU sends <rpc><get><filter=”subtree”> to get o-ran-software-management.yang
20 2. O-RU responds with <rpc-reply><data> for <software-inventory>< software-slot>. At least 2 slots are
21 contained in software-inventory
22 Note: software update is not applied as the pre-condition that appropriate software file for O-RU is pre-
23 installed in O-RU and corresponding manifest.xml is located in O-DU.
24 2.2.1.1.6.10 Step: C/U-Plane transport connectivity check between O-DU and O-RU
25 1. O-DU configures by <rpc><edit-config> vlan-id for the usage of C/U-Plane in ietf-interface augmented by o-
26 ran-interfaces to O-RU. O-RU responds with <rpc-reply><ok/>
27 2. O-DU sends loopback message to O-RU with MAC address and vlan-id periodically. The O-RU MAC address
28 and vlan-id used in LBM is same as the one that set in ietf-interface augmented by o-ran-interfaces.
29 3. O-RU sends loopback response to O-DU per received loopback message respectively
30 2.2.1.1.6.11 Step: U-Plane configuration between O-DU and O-RU
31 1. O-DU sends <rpc><get><user-plane-configuration> to determine the presence of following instances: multiple

32 static-low-level-[tr]x-endpoints, multiple [tr]x-arrays and the relations between them. O-RU replies <rpc-
33 reply><data> including key information on number of endpoints, band number, number of arrays and
34 polarization.
35 2. O-DU sends <rpc><edit-config> to create low-level-[tr]x-endpoints, with the same name as static-low-level-
36 [tr]x-endpoints. The NETCONF Client is responsible for assigning unique values to the "eaxc-id" addresses of
37 all low-level-rx-endpoint elements and low-level-tx-endpoint elements, within the O-RU when operating in the
38 same direction (Tx or Rx), even when these operate across different named interfaces of the O-RU. Number of
39 instances of low-level-[tr]x-endpoints depend on contents of selected test profile eg. for number of CCs. It may
40 be less than number of instances of static-low-level-[tr]x-endpoints. O-RU replies <rpc-reply><ok/></rpc-
41 reply>.
________________________________________________________________________________________________
1 3. O-DU sends <rpc><edit-config> to create [tr]x-array-carriers. Number of created instances of [tr]x-array-

2 carriers is equivalent to number of CCs times number of arrays, where number of CCs is defined by operator.
3 Appropriate values are configured to absolute-frequency-center, channel-bandwidth, gain, and so on. In
4 provided configuration the value of leaf “active” is set as ‘INACTIVE’ (or leaf is omitted in configuration and
5 O-RU uses its default value 'INACTIVE') for all just created [tr]x-array-carriers. O-RU replies <rpc-
6 reply><ok/></rpc-reply>.
7 4. O-DU sends <rpc><edit-config> to create processing-elements related to interfaces offering access to desired
8 endpoints. The key information such as MAC address is configured according to selected transport flow, eg. o-
9 ru-mac-address, o-du-mac-address and vlan-id for C/U-Plane in case of Ethernet flow. O-RU replies <rpc-
10 reply><ok/></rpc-reply>.
11 5. O-DU sends <rpc><edit-config> to create low-level-[tr]x-link(s) to make relationship between low-level-[tr]x-

12 endpoint(s), [tr]x-array-carriers and processing elements belonging to transport. The number of instance(s) for
13 low-level-[tr]x-links is equivalent to that of instance(s) of low-level-[tr]x-endpoints.
14 2.2.1.1.6.12 Step: Fault Management activation
15 1. O-DU sends <rpc><get><filter=”subtree”> to get o-ran-fm.yang
16 2. O-RU responds with <rpc-reply><data> for <active-alarm-list><active-alarms>
17 Note: subscription to NETCONF default event stream fulfils the condition to signal notification alarm-notif
18 when O-RU detects any alarm.
19 2.2.1.1.6.13 Step: Performance measurement activation (if required at start-up timing)
20 Note: Step for Retrieval of O-RU information may cover the configuration of o-ran-performance-management.yang if it
21 is required at start-up installation timing.
22 2.2.1.1.6.14 Step: Retrieval of O-RU state, including synchronization information, from O-RU
23 If O-DU already knows at the moment this step is going to be performed (e.g. from notification “synchronization-state-
24 change”), that “sync-state” of O-RU is ‘LOCKED’, O-DU may skip this step.
25 S-Plane has to be operational.
26 1. O-DU sends <rpc><get><sync> to O-RU
27 2. S-Plane in O-RU has been locked, sends <rpc-reply><data> <sync-status><sync-state> LOCKED
28 2.2.1.1.6.15 Step: Configuring the O-RU operational parameters: carrier activation
29 S-Plane has to be operational (sync-state != FREERUN, preferable sync-state = LOCKED) prior to running this step
30 1. O-DU sends <rpc><edit-config> to perform activation by setting the value of the parameter “active” at [tr]x-
31 array-carriers to “ACTIVE”. O-RU sends <rpc-reply><ok/>
32 2. O-RU sends notification [tr]x-array-carriers-state-change that indicates all [tr]x-array-carriers’ names with
33 “state” = “READY”
34 Note: C/U-Plane service is available at this step.
35 2.2.1.1.7 Test Requirement (expected result)

36 Observe that both the O-DU and O-RU get in service successfully by monitoring correct transmission of
37 synchronization signals and broadcast channel (ie, PSS/SSS and PBCH for LTE and SSB for NR).
38 Record downlink carrier frequency (EARFCN for LTE as defined in 3GPP TS 36.104 [12] and GSCN/NR-ARFCN for
39 NR as defined in 3GPP TS 38.104 [13]), cell (PCI for LTE and for NR as defined in 3GPP TS 36.211 [14] and TS
40 38.211 [15], respectively) and system information (MIB for LTE and NR as specified in 3GPP TS 36.331 [16] and TS
41 38.331 [17], respectively). In case that beam sweeping is applied to SSB, system information should be recorded for
42 each of the SSB indices detected.
________________________________________________________________________________________________
1 The parameter values for downlink carrier frequency, cell, system information and SSB indices are part of the radio test
2 setup configuration. This test is considered successful if the recorded measurements values match up with the values
3 which are used for the radio test setup configuration.
4 2.2.1.1.8 Test Report (Failure)

5 If the test case fails, vendor specific methods will be relied on to assist with troubleshooting the root cause(s) which led
6 to the failure. The steps outlined in this test case can be used to guide the troubleshooting process.
7 2.2.1.2 Start-up in hybrid mode

10 The DUT is composed of single O-DU, a single O-RU and a single NMS.
11 Test scenario refers to Chapter 2 “M-Plane Architectural Model” and Chapter 3 “Start-up” in hybrid architecture for M-
12 Plane [3]. As per M-Plane Chapter 2, all compliant O-RUs shall be able to support both hierarchical and hybrid
13 deployment. The testing of hybrid use case shall therefore include being able to demonstrate that an O-RU is able to
14 support simultaneous NETCONF sessions to the O-DU and NMS. In order to ensure limited impacts to the baseline
15 hierarchical O-DU to NMS configuration management tasks, in this test the second NETCONF client associated with
16 “nms” user privileges is limited to demonstrating that it is able to retrieve the configuration and operational state from
17 an O-RU which has been configured by an O-DU.
18 2.2.1.2.2 Minimum Requirements

19 Single O-DU (DUT1(O-DU)), a single O-RU (DUT1(O-RU)) and a single NMS (DUT1(NMS).
20 Must be connected through the O-RAN FH
21 Assumptions which are required for this test scenario
22 1. DHCP server is configured for test purposes (either function served by O-DU or external DHCP server with O-
23 DU or router as relay – that should have no impact on test scenario). In case of external DHCP server -
24 Configuration of DHCP server and DHCP procedures are excluded from validation of IOT.
25 2. As IPv6 support is optional, only IPv4 transport connection for M-Plane is used in this test.
26 3. A combination of VLAN identity and MAC address is used for C/U- Plane connectivity.
27 4. A common VLAN is used for M-Plane connectivity between the O-RU and O-DU and between the O-RU and
28 the NMS.
29 5. Network between O-DU and O-RU and between NMS and O-RU allows for connectivity between actors.
30 6. An account user-name has been configured for group “nms” access control privileges in a previous O-DU/O-
31 RU testing step as defined in sub-section 2.2.1.1.6.5.
32 7. O-RU has two accounts configured. One account has sudo access privilege with credentials used by the O-DU.
33 The other account has nms access privilege and the credentials used by the NMS.
34 8. Appropriate software file for O-RU is pre-installed in O-RU and corresponding manifest.xml is located in O-
35 DU. No software upgrade is required during startup test sequence of O-RU for this IOT test case.
36 9. An NMS is configured for supporting NETCONF Call Home functionality.
38 1. FH Protocol Analyzer monitoring traffic between O-DU and O-RU and between NMS and O-RU is used for
39 validation of M-Plane procedural flows and contents of messages prior to the establishment of the SSH
40 connection for M-Plane and when certain procedures do not use encryption (eg., loopback messages and
41 responses of IEEE 802.1Q).
________________________________________________________________________________________________
1 2.2.1.2.3 Test Purpose

2 Purpose of this test is to validate the startup sequence of O-RU and the interface to DHCP server and NETCONF clients
3 in the O-DU and NMS for the start-up scenario. As described in [3], all O-RUs supporting the M-Plane specification
4 shall support multiple NETCONF sessions, and hence all compliant O-RUs shall be able to support both hierarchical
5 and hybrid deployment.
6 The detailed steps outlined in this test case are for informational purposes and can be useful for troubleshooting
7 purposes in the event that the test case fails. Procedures which are not encrypted with SSH can be observed with the FH
8 Protocol Analyzer for validation of the test progress.
9 Notwithstanding this being an M-Plane test, correct evaluation of the success of the M-Plane operation requires also
10 that the fronthaul C-Plane and U-Plane also be operational, at least in the DL direction.
11 2.2.1.2.4 Testability requirements imposed on O-RU, O-DU and NMS

12 The appropriate software runs on the O-RU, O-DU and NMS for the test purpose.
13 2.2.1.2.5 Initial Conditions

14 1. There is physical and or logical connectivity between O-RU and O-DU and between the O-RU and NMS
15 2. O-DU and NMS are powered up and in service or running
16 3. DHCP server is connected and available
17 4. O-RU is powered up for this start-up test scenario
18 5. The credential information (sudo username and password together with nms username and password) is
19 configured on the O-RU according to one of test assumptions listed in in 2.2.1.2.2.
20 2.2.1.2.6 Procedure: M-Plane start up test
21 2.2.1.2.6.1 Step: Transport layer initialization
22 1. Depending on initial condition – either power-on to O-RU or physical or logical network connection is enabled
23 between O-RU and O-DU/NMS.
24 2. FH Protocol Analyzer observation: DHCP Discovery coming from O-RU’s MAC address
25 3. Note: message is sent as part of VLAN scan procedure, hence it can be in serial sequence “VID after VID with
26 timer in between” or in parallel sequence “burst to subset of VIDs, timer, another burst to different subset of
27 VIDs”. FH Protocol Analyzer confirms that the O-RU includes vendor class (option 60) or vendor-identifying
28 vendor class (option 124) in the DHCP DISCOVER.
29 4. FH Protocol Analyzer observation: VLAN scan continues until response from DHCP server is received.
30 5. FH Protocol Analyzer observation: O-RU continues DHCP procedure using only the VID on which response
31 from DHCP server has been received.
32 6. FH Protocol Analyzer observation: DHCP procedure is finished by DHCP Acknowledgement message sent
33 towards O-RU. As a result of DHCP procedure, O-RU obtains its own IP details plus an DHCP option 43
34 carrying either IP or FDQN of corresponding NETCONF Clients in O-DU and in NMS.
35 2.2.1.2.6.2 Step: RU calls home to discovered NETCONF client (TCP connection establishment)
36 1. FH Protocol Analyzer observes Call Home – a TCP session establishment initiated by O-RU towards O-DU
37 2. FH Protocol Analyzer observes Call Home – a TCP session establishment initiated by O-RU towards NMS
38 2.2.1.2.6.3 Step: SSH Secure connection establishment
39 1. SSH session establishment initiated by O-DU towards O-RU using sudo account privilege.
________________________________________________________________________________________________
1 2. SSH session establishment initiated by NMS towards O-RU using nms account privilege.
2 2.2.1.2.6.4 Step: NETCONF Capability discovery
3 1. NETCONF Hello message sent by O-RU towards NETCONF clients (O-DU and NMS). The message exposes
4 capability of ietf-yang-library
5 2. NETCONF Hello message sent by NETCONF clients (O-DU and NMS) towards O-RU.
6 3. <rpc><get> message sent by NETCONF clients (O-DU and NMS) to O-RU. The <rpc><get> has <modules-
7 state xlsnm = “urn:ietf:params:xml:ns:yang:ietf-yang-library”> subtree filter imposed
8 4. <rpc><reply> message sent by O-RU to NETCONF Clients (O-DU and NMS). The message contains content
9 of leaf “modules-state” of ietf-yang-library.yang module
10 2.2.1.2.6.5 Step: Optional provisioning of new management accounts
11 Note: this step is intentionally omitted as pre-provisioned O-RU is expected for IOT (meaning: no need to perform
12 optional step and configure supplementary management accounts).
13 2.2.1.2.6.6 Step: Initial process of NETCONF Subscribe for each stream
14 1. NETCONF “create-subscription” RPC message(s) sent by O-DU towards O-RU. Number of NETCONF
15 subscriptions is up to O-DU.
16 Note: O-DU can subscribe itself to default event stream or to specific streams of events. In case no subscription
17 to default stream is performed, then O-DU shall subscribe itself at least to event streams “supervision-
18 notification” and “alarm-notif”. Subscription to other streams is optional, however not prohibited.
19 2. NETCONF “create-subscription” RPC Reply messages sent by O-RU for each RPC message
20 Note: subsequent steps use the NMS to retrieve the configuration and operational state of the O-RU and are performed
21 after step 2.2.1.1.6.7 through 2.2.1.1.6.15 that complete O-RU start-up.
22 2.2.1.2.6.7 Step: NMS retrieval of O-RU information and Additional configuration
23 1. NMS sends <rpc><get><filter=”subtree”> to get each yang module listed in ietf-yang-library.yang in O-RU,
24 with the exception of o-ran-usermgmt and o-ran-supervision, for example
25 ietf-hardware augmented by o-ran-hardware
26 ietf-interface augmented by o-ran-interfaces
27 o-ran-operations
28 o-ran-transceiver
29 o-ran-sync
30 o-ran-mplane-int
31 o-ran-lbm
32 o-ran-performance-management
33 o-ran-delay-management
34 o-ran-module-cap
35 o-ran-uplane-conf
36 o-ran-alarm-id
37 o-ran-fan
________________________________________________________________________________________________
1 2. O-RU responds with <rpc-reply><data> for each yang module per <rpc><get>

3 Observe that the O-RU calls home to both the O-DU and NMS and then is able to establish simultaneous NETCONF
4 sessions between the O-RU and O-DU and between the O-RU and NMS.
5 Observe that the NMS is able to retrieve configuration and operational state from models to which it does have NACM
6 read privileges.
7 2.2.1.2.9 Test Report (Failure)

8 If the test case fails, vendor specific methods will be relied on to assist with troubleshooting the root cause(s) which led
9 to the failure. The steps outlined in this test case can be used to guide the troubleshooting process.
10 2.2.1.2.10 Supplementary test: NETCONF Access Control (Failure)

11 This is a supplementary test to verify correct handling of NMS read attempt with incorrect privilege per 2.2.1.2.6.7.
12 1. The NETCONF client in the NMS attempts to read user accounts provisioned on the O-RU. The NMS sends
13 <rpc><get><filter=”subtree”> to get the configuration and operational state for the o-ran-usermgmt yang
14 module.
15 2. O-RU responds with <rpc-error> response with “access-denied”.
16 Expected result is to that an O-RU will deny access to an NMS that tries to read configuration and/or operational state
17 from models to which it does not have NACM privileges.
18 If the test case fails, that is access is granted, vendor specific methods will be relied on to assist with troubleshooting the
19 root cause(s) which led to the failure.
20 2.2.2 S-Plane IOT Test

21 This Section describes system level tests that are used to validate both S-Plane functionality and S-Plane performance
22 between O-DU and O-RU from different vendors connected using the O-RAN WG4 FH interface defined in [2] and the
23 O-RAN WG4 M-Plane interface defined in [3].
24 S-Plane functionality is determined by retrieval of the O-DU and O-RU synchronization state using the M-Plane or
25 NMS as appropriate, whereas, S-Plane performance is determined by over-the-air (OTA) measurements or conductive
26 (i.e. a cabled electrical connection to the DUT’s radio interface) measurements of O-RU synchronization signal.
27 This Section provides a common high-level list of the items that are expected to be covered in order to validate
28 interoperability with the relevant standard, both functional and performance aspects are addressed:
29 • The tests apply to both 4G(LTE) and 5G(NR) and are applicable to all O-RAN IOT profiles listed in
30 Annex A
31 • The CUS-Plane Specification [2] Section validated is §9.3.2
32 • SyncE Master test case is optional and only valid when the SyncE clock (eg. Implemented in the O-RU)
33 takes advantage of it. Therefore, the related SyncE Master test cases are optional
34 • Several test cases involve configuring the O-DU or O-RU
35 • M-Plane connection must be established, meaning whole protocol stack ETH/IP/TCP/SSH is up and
36 running, Capabilities are exchanged between NETCONF Client and Server, Subscriptions to notifications
37 are created
38 o Several test cases involve the configuration and collection of status of T-BC. However, as this is not
39 defined in the Management Plane Specification [3], the parts of the tests below that require such
40 functionality are FFS in this release of the specification
________________________________________________________________________________________________
1 o Further work needs to be done to align and refine the definition of the states in the CUS [2] and M-
2 Plane [3] specifications for the next releases
3 The following bulleted notes apply specifically to IOT functional tests in addition to the general notes above,
4 • Tests shall be done in the lab at constant temperature
5 • Test equipment is needed to generate a reference S-Plane signal
6 • For validation of synchronization information, use the FH M-Plane interface for the O-RU, and other
7 interfaces such as NMS for O-DU
8 • Retrieving sync-state of O-DU using the NMS is FFS in this version of the specification
9 • O-RU reports over M-Plane the degraded received clock-class and clock-accuracy as well as locked state;
10 details are for further study
11 • With the exception of lls-C1, that doesn't include any T-BC in the fronthaul link, the test configuration
12 shall use from 1 up to the maximum number of T-BCs specified for performance test, as set out in the
13 performance test specific notes set out below, according to the preference of the tester
14 The following bulleted notes apply specifically to IOT performance tests in addition to the general notes above,
15 • All tests should be done in lab under constant and variable C/U plane profile. The variable C/U-Plane
16 profile (for example similar to the test case 13 shown in figure VI.11 of ITU-T G.8261 [10]) must be
17 defined for this test
18 • The previous version of this document (v 1.00) contained a requirement to perform the IOT performance
19 tests under variable temperature conditions. That requirement was removed in this version, and instead
20 replaced with the following text that was also used in the Conformance Test specification [24]: The
21 thermal profile is not defined. The tests are defined to be run at a constant temperature, but the thermal
22 profile choice and range is left as a decision for the vendor
23 • Not all cases are mandatory, a vendor or network operator may test either all or any of them
24 • Use the maximum number of T-BC devices as shown in CUS-Plane specification [2] in Annex H
25 Note: Annex H includes example deployment cases that capture the influence of factors including, target end-
26 to-end timing error requirement, clock type used in the network, and characteristics of the O-RU clock.
27 Additional cases are for further study including, addressing O-RUs with different levels of clock performance,
28 and different noise accumulation models etc
29 • The acceptance criterion for the tests is to satisfy the 3GPP OTA TAE limits specified in 3GPP TS 36.141
30 [18] for 4G(LTE) and 38.141-2 [19] for 5G(NR), and summarized in eCPRI [11] and ITU-T G.8271 [7].
31 The particular conditions applicable to each test are set out in the relevant sections below
32 To perform the IOT S-Pane tests, following test set ups (Figure 2.5, 2.6 and 2.7) are proposed. The selection of the
33 test setup is dependent on the configuration mode lls-C1, lls-C2, or lls-C3. This version of the document does not
34 cover lls-C4:
35 • Each diagram covers both functional test and conformance test of the respective synchronization
36 configuration mode. The main difference between the setups for functional and performance test is the
37 need for a measurement equipment at the radio interface for performance test as indicated in previous
38 paragraphs.
39 • Each setup gives the option to select different types of S-Plane signals for the input of the O-DU. The
40 selection of the option depends on the capability of the O-DU and operator’s synchronization architecture.
41 In lls-C3 mode, the O-DU has the option of selecting a master through its fronthaul interface or directly
42 connecting to a T-GM.
43 • T-GM via a midhaul network (for ls-C1 or lls-C2) or a fronthaul network (for lls-C3) over an Ethernet
44 interface with PTP and SyncE (if applicable)
45 • T-GM over an Ethernet interface with PTP and SyncE (if applicable)
________________________________________________________________________________________________
1 • PRTC: 1pps according to ITU-T G.703, 10MHz, and ToD according to G.8271 Annex A or any other
2 proprietary ToD decoding specification supported by the O-DU
3 • GNSS: RF input directly from an antenna used for GNSS signal reception
4 • The measurement equipment has to be synchronized with the DUT, thus the need for a line arriving at the
5 measurement equipment.
6 • The arrows in these diagrams represent the direction of S-Plane messages (from master to subordinate), or
7 from any source synchronization signal to the receiver.
9
10 Figure 2-5: Test setup for lls-C1
11
12
14
15
17
________________________________________________________________________________________________
1 2.2.2.1 Functional test of O-DU + O-RU using ITU-T G.8275.1 profile (LLS-C1)

3 This test validates that O-RU is synchronizing from an O-DU that incorporates a PTP grand master and SyncE Master
4 with ITU-T G.8275.1 [5] profile and is traceable to a PRTC.
5 This test involves one O-DU and one O-RU.

7 1. O-RU is connected to O-DU via direct fiber O-RAN links.
8 2. The O-DU is connected to a PRTC traceable time source, directly (GNSS Receiver either embedded or
9 connected to the O-DU) or via PTP, as described in Conformance Test Specification 2.00 [24].
10 2.2.2.1.3 Purpose and Scope

11 The O-RU is synchronizing from the O-DU with the ITU-T G.8275.1 [5] profile. This test case validates the correct
12 synchronization status of the O-RU.
13 2.2.2.1.4 Testability Requirements imposed on O-RU and O-DU

14 Requirements for M-Plane: must be properly operating (as defined in 2.2.1.1).
15 Synchronization requirement: O-DU must be connected to a local or remote PRTC.
16 2.2.2.1.5 Test Methodology

17 These tests use the O-RAN M-Plane and O-DU NMS features.
18 The O-DU must act as a PTP master compliant with the ITU-T G.8275.1 [5] profile.
19 Three conditions must be covered:
20 • startup
21 • nominal
22 • degraded
23 2.2.2.1.5.1 Procedure: Startup conditions
24 1. Not yet configured.
25 External frequency and time source are available to the O-DU and deliver nominal status
26 O-DU is not yet configured to select the time source and align its frequency and time to it
27 O-DU not yet configured to act as PTP master on the FH ports
28 2. Configured.
29 O-DU is configured to align to the selected frequency and time source
30 3. Until disciplining
31 Until O-DU disciplining of the frequency and time to the selected source has completed, Startup conditions
32 persists
33 The O-RUs are configured to synchronize from PTP in ITU-T G.8275.1 [5] profile and report their status
________________________________________________________________________________________________
1 2.2.2.1.5.2 Procedure: Nominal conditions
2 1. O-DU is configured to start acting as a PTP master compliant with the ITU-T G.8275.1 [5] profile on selected
3 FH ports.
4 2. O-DU acts as a PTP grand master or as a boundary clock with ports towards the FH interface in Master state,
5 compliant with the ITU-T G.8275.1 [5] profile advertising “nominal” status.
6 3. O-DU reports status, acting as PTP master clock towards the FH interface.
7 2.2.2.1.5.3 Procedure: Degraded conditions
8 1. O-DU is configured to enter HOLDOVER based on local oscillator frequency.
9 2. O-DU acts as configured clock, with PTP ports in master state, compliant to ITU-T G.8275.1 profile
10 advertising HOLDOVER status with degraded clockClass and clockAccuracy as specified by ITU-T G.8275.1
11 [5].
12 3. O-DU is configured to exit HOLDOVER and resumes normal frequency and phase disciplining using the
13 source.
14 4. O-DU acts as configured clock, with PTP ports towards the FH interface in master state compliant to ITU-T
15 G.8275.1 [5] in “nominal” status.
16 2.2.2.1.6 Test Requirements (expected results)
17 2.2.2.1.6.1 Startup conditions
18 The acceptance criterion is that the following status is observed for steps 1 to 3 (2.2.2.1.5.1 above):
19 • the FREERUN sync-state of the O-RU using the M-Plane
20 • the UNLOCKED PTP lock-state of the O-RU using the M-Plane
21 • the UNLOCKED SyncE lock-state of the O-RU using the M-Plane (optional)
22 • the FREERUN sync-state of the O-DU using the NMS
23 2.2.2.1.6.2 Nominal conditions
25 • the LOCKED sync-state of the O-DU using the NMS
26 • the received PTP clockClass level of the O-RU using the M-Plane
27 • the received SyncE SSM level of the O-RU using the M-Plane (optional)
28 • the LOCKED sync-state of the O-RU using the M-Plane
29 • the LOCKED PTP lock-state and PARENT PTP state of the O-RU using the M-Plane
30 • the LOCKED SyncE lock-state and OK or PARENT SyncE state of the O-RU using the M-Plane
31 (optional)
32 2.2.2.1.6.3 Degraded conditions
33 The acceptance criterion is that the following status is observed for all steps 1 to 2 (2.2.2.1.5.3 above) (for steps 3 and 4,
34 same criterion as “Nominal conditions” apply):
35 • the HOLDOVER sync-state of the O-DU using the NMS
________________________________________________________________________________________________
1 • the received SyncE SSM level of the O-RU using the M-Plane (optional). Note that if SyncE state is NOK,
2 it is also permitted that the local default SSM level is reported using the M-Plane.
3 • the sync-state of the O-RU using the M-Plane is LOCKED if the received clockClass (or optional SSM
4 QL) value matches the configured list of accepted values, otherwise HOLDOVER or FREERUN
5 • the PTP lock-state of the O-RU using the M-Plane is LOCKED,

6 and the PTP state of the O-RU using the M-Plane is PARENT if the received clockClass matches the
7 configured list of accepted values, otherwise NOK.
8 • the SyncE lock-state (optional) of the O-RU using the M-Plane is LOCKED or OK,
9 and the SyncE state of the O-RU using the M-Plane is PARENT or OK if the received SSM matches the
10 configured list of accepted values, otherwise NOK.
11 Note: If the NETCONF client triggers a reset procedure of the O-RU by FREERUN of the sync-state at these degraded
12 conditions, the status observation using M-plane is not available for NETCONF client. It is observed that the alarm-
13 notification is sent from the O-RU using M-Plane and the regular start-up procedures is performed.
14 2.2.2.2 Functional test of O-DU + bridged network + O-RU using ITU-T G.8275.1 profile
15 (LLS-C2)

17 This test validates that O-RU is synchronizing from an O-DU via a chain of T-BC using ITU-T G.8275.1 [5] profile.
18 This test involves one O-DU, one O-RU and multiple T-BCs.
19 The configuration, management, and retrieval of status of the T-BC will be considered for a future release.

21 1. O-RU is connected to O-DU via a chain of T-BCs.
22 2. The T-BCs are class B. The subordinate port of the first T-BC is connected to O-DU. The master clock of the
23 last T-BC is connected to the O-RU.
24 3. The O-DU is connected to a PRTC traceable time source, directly (GNSS Receiver connected to the O-DU) or
25 via PTP.

27 The O-RU is synchronizing from the O-DU with the ITU-T G.8275.1 [5] profile over a bridged network that can deploy
28 several T-BCs. This test case validates the correct synchronization status of the O-RU.

30 Requirements for M-Plane: must be properly operating (as defined in 2.2.1.1).
31 Synchronization requirement: O-DU must be connected to a local PRTC/source traceable to PRTC.

35 • startup
36 • nominal
37 • degraded
________________________________________________________________________________________________
3 External frequency and time source are available to the O-DU and deliver nominal status.
4 O-DU is not yet configured to select the time source and align its frequency and time to it.
5 O-DU not yet configured to act as PTP master on the FH ports.
6 2. Configured.
7 O-DU is configured to align to the selected frequency and time source.
9 Until O-DU disciplining of the frequency and time to the selected source has completed, Startup conditions
10 persists.
11 The O-RUs are configured to synchronize from PTP in ITU-T G.8275.1 [5] profile and report their status.
13 1. O-DU is configured to start acting as a PTP master compliant with the ITU-T G.8275.1 [5] profile on selected
14 FH ports.
15 2. O-DU acts as a PTP grand master or as a boundary clock with ports towards the FH interface in Master state,
16 compliant with the ITU-T G.8275.1 [5] profile advertising “nominal” status.
17 3. O-DU reports status, acting as PTP master clock towards the FH interface.
19 1. O-DU is configured to enter HOLDOVER based on local oscillator frequency.
20 2. O-DU acts as configured clock, with PTP ports in master state, compliant to ITU-T G.8275.1 profile
22 [5].
23 3. O-DU is configured to exit HOLDOVER and resumes normal frequency and phase disciplining using the
24 source.
25 4. O-DU acts as configured clock, with PTP ports towards the FH interface in master state compliant to ITU-T
26 G.8275.1 [5] in “nominal” status.
36 • the LOCKED sync state of the O-DU using the NMS
________________________________________________________________________________________________
1 • the LOCKED PTP lock-state of the O-DU using the NMS
2 • the “Master Enabled” SyncE status of the O-DU using the NMS (optional)
4 • the received SyncE SSM level of the O-RU using the M-Plane (optional)
8 (optional)
9 • the synchronization status of the deployed T-BC using the respective NMS
11 The acceptance criterion is that the following status is observed for all steps 1 to 2 (2.2.2.2.5.3 above) (for steps 3 and 4,
12 same acceptance criterion as “Nominal conditions” apply)
16 it is also permitted that the local default SSM level is reported using the M-Plane.
17 • the sync-state of the O-RU using the M-Plane is LOCKED if the received clockClass (or optional SSM
18 QL) value matches the configured list of accepted values, otherwise HOLDOVER or FREERUN

20 and the PTP state of the O-RU using the M-Plane is PARENT or OK if the received SSM matches the
21 configured list of accepted values, otherwise NOK
29 (LLS-C3)

31 This test validates that both the O-DU and O-RU are synchronizing from a common PRTC via a chain of T-BCs using
32 ITU-T G.8275.1 [5] profile.
33 This test involves one O-DU, one O-RU, a PRTC/T-GM and multiple T-BCs.
34 The configuration, management, and retrieval of status of the T-BC will be considered for a future release of the
35 specification.

37 1. Both O-RU and O-DU are connected to a common PRTC via a chain of T-BCs that are either directly
38 connected to a PRTC/T-GM in the FH network or are connected to another T-BC that is traceable to a PRTC.
39 2. The T-BCs are class B. The subordinate port of the first T-BC is connected to a PRTC/T-GM. The O-DU and
40 O-RU are connected to master ports of either the same T-BC or different ones.
________________________________________________________________________________________________

2 Both O-DU and O-RU are synchronized via a chain of T-BC from a common PRTC/T-GM located in the FH networks
3 using ITU-T G.8275.1 [5] profile. This test case validates the correct synchronization status of the O-RU and O-DU.
4 2.2.2.3.4 Testability Requirements imposed on O-RU, O-DU and bridged network

5 Requirements for M-Plane: shall be properly operating (as defined in 2.2.1.1)
6 Synchronization requirement: The T-BC must be connected to a local PRTC or to another T-BC that is traceable to a
7 PRTC.

11 • startup
12 • nominal
13 • degraded
16 External frequency and time source are available to the PRTC/T-GM and deliver nominal status.
17 PRTC/T-GM is not yet configured to select the time source and align its frequency and time to it.
18 PRTC/T-GM not yet configured to act as PTP master on the FH ports.
19 2. Configured.
20 PRTC/T-GM is configured (eg. via proprietary) interface to align to the selected frequency and time
21 source.
23 Until PRTC/T-GM disciplining of the frequency and time to the selected source has completed, Startup
24 conditions persists.
25 The O-RUs are configured to synchronize from PTP in ITU-T G.8275.1 [5] profile and report their status.
27 1. PRTC/T-GM is configured to start acting as a PTP master compliant with the ITU-T G.8275.1 [5] profile on
28 selected FH ports.
29 2. PRTC/T-GM acts as a PTP grand master towards the FH interface in Master state, compliant with the ITU-T
30 G.8275.1 [5] profile advertising “nominal” status.
31 3. PRTC/T-GM reports status, acting as PTP master clock towards the FH interface.
33 1. PRTC/T-GM is configured to enter HOLDOVER based on local oscillator frequency.
34 2. PRTC/T-GM acts as configured clock, with PTP ports in master state, compliant to ITU-T G.8275.1 profile
36 [5].
________________________________________________________________________________________________
1 3. PRTC/T-GM is configured to exit HOLDOVER and resumes normal frequency and phase disciplining using
2 the source.
3 4. PRTC/T-GM acts as configured clock, with PTP ports towards the FH interface in master state compliant to
4 ITU-T G.8275.1 [5] in “nominal” status.
7 The validation is done by checking the correct synchronization state is observed for steps 1 to 3 (2.2.2.3.5.1 above):
9 • the UNLOCKED PTP lock-state of the O-DU using the NMS
10 • the UNLOCKED SyncE lock-state of the O-DU using the NMS (optional)
16 The validation is done by checking the correct synchronization state is observed for steps 1 to 3 (2.2.2.3.5.2 above):
17 • the LOCKED sync-state of the O-DU using the NMS
18 • the LOCKED PTP lock-state of the O-DU using the NMS
19 • the “Master Enabled” SyncE status of the O-DU using the NMS (optional)
21 • the received SyncE SSM level of the O-RU using the M-Plane (optional).
25 (optional)
28 The validation is done by checking the correct synchronization state is observed for all steps 1 to 2 (2.2.2.3.5.3 above)
29 (for steps 3 and 4, same acceptance criterion as “Nominal conditions” apply):
31 • the received PTP clockClass level of the O-DU using the NMS
32 • the received SyncE SSM level of the O-DU using the NMS (optional)
35 it is also permitted that the local default SSM level is reported using the M-Plane
________________________________________________________________________________________________
1 • the synchronization status of the deployed T-BC using the respective NMS - the sync-state of the O-RU
2 using the M-Plane is LOCKED if the received clockClass (or optional SSM QL) value matches the
3 configured list of accepted values, otherwise HOLDOVER or FREERUN

5 and the PTP state of the O-RU using the M-Plane is PARENT if the received clockClass matches the
13 2.2.2.4 Functional test of O-DU + O-RU using ITU-T G.8275.2 profile (LLS-C1)
14 This test is For Further Study.
16 (LLS-C2)
19 (LLS-C3)
21 2.2.2.7 Functional test of O-DU + bridged network + O-RU (LLS-C4)

22 This test case is For Further Study.
23 2.2.2.8 Performance test of O-DU + Two O-RUs using ITU-T G.8275.1 profile (LLS-C1)
24 2.2.2.8.1 Test Description and applicability

25 This test validates that the two O-RUs meet the 3GPP limits at their air interface, when
26 • the O-DU gets its synchronization from a PRTC using either a local or remote PRTC as specified in the
27 Conformance tests 2.00 [24], under either ideal or normal conditions,
28 • and is connected to two O-RUs via direct FH links,
29 • and distributes frequency and time to these O-RUs using the ITU-T G.8275.1 (SyncE + PTP) profile

31 1. IOT Functional test 2.2.2.1 is successfully passed and all O-DU, bridged network elements and O-RUs report
32 LOCKED status.
33 2. O-RUs are connected to the O-DU via direct fiber O-RAN links.
34 3. O-RUs are suitable for Case 1.1 or 1.2 as defined in eCPRI [11].
35 2.2.2.8.3 Purpose and scope

36 The O-DU synchronize the O-RUs with the ITU-T G.8275.1 profile [5]. This test validates that the frequency and time
37 error on the O-RU air interfaces are within the limits of the 3GPP, in both constant and variable temperature and traffic
38 load conditions.
________________________________________________________________________________________________
1 Only LOCKED state is tested; HOLDOVER state test is For Further Study.

3 Both O-DU and O-RU are running nominal software.
4 Requirements for M-Plane: must be “up and running.”
5 Synchronization requirement: O-DU and test equipment must be connected to a local PRTC or source traceable to
6 PRTC.
7 Test 2.2.2.1.6.2 is successfully passed and both O-DU and O-RUs report LOCKED status.

9 After O-DU and O-RUs are frequency and phase locked to their PRTC synchronization source using the LLS-C1
10 configuration, the frequency and phase errors are measured on the O-RUs air interface using a test equipment
11 referenced to the same PRTC.
12 The O-DU input time error on the O-DU is as specified in the Conformance Test 2.00 [24],
13 - Either “ideal” with zero value

14 - Or “normal”, with configured values with standard masks

16 For both constant and variable conditions tests, the acceptance criterion is to measure with the test equipment:
17 • ±50 ppb maximum frequency error at the air interface
18 • ITU-T Level 4, eCPRI Cat C (mandatory): ± 1500ns maximum absolute time error at the O-RU air
19 interface.
20 • ITU-T Level 6A, eCPRI Cat B (optional): ± 260ns maximum relative time error between the two O-RUs
21 air interfaces.
22 Note: This level of accuracy assumes an O-RU implementation suitable for Case 1.1 and case 1.2 as
23 defined in eCPRI [11].
24 • ITU-T Level 6B, eCPRI Cat A (optional) ± 130ns maximum relative time error between the two O-RUs
25 air interfaces.
26 Note: This level of accuracy assumes an O-RU implementation suitable for Case 1.2 as defined in eCPRI
27 [11]. It also assumes co-location of the O-RUs and O-DU.
28 2.2.2.9 Performance test of O-DU + bridged network + Two O-RUs using ITU-T G.8275.1
29 profile (LLS-C2)

31 This test validates that the two O-RUs are meeting the 3GPP limits at their air interface, when:
32 • the O-DU gets its synchronization from a PRTC using a local or remote PRTC as specified in the
33 Conformance tests 2.00 [24], under either ideal or normal conditions,
34 • and is connected to two O-RUs via eCPRI FH links via bridged network elements acting as class B T-BCs,
35 • and distributes frequency and time to these O-RUs using the ITU-T G.8275.1 (SyncE + PTP) profile [5]

37 1. IOT Functional Test 2.2.2.2 is successfully passed and all O-DU, bridged network elements and O-RUs report
38 LOCKED status.
________________________________________________________________________________________________
1 2. O-RUs are connected to O-DU via bridged network elements acting as ITU-T G.8275.1 class B T-BCs using
2 O-RAN links [5].

5 The O-DU synchronizes the O-RUs with the ITU-T G.8275.1 [5] profile via the bridged network elements.
6 This test validates that the frequency and time error on the O-RU air interfaces are within the limits of the 3GPP, in both
7 constant and variable temperature and traffic load conditions.

11 Requirements for M-Plane: must be “up and running”
12 Synchronization requirement: O-DU and test equipment must be connected to a local PRTC or source traceable to
13 PRTC.

17 configuration, the frequency and phase errors are measured on the O-RUs air interface using a test equipment
18 referenced to the same PRTC.
19 The O-DU input time error on the O-DU is as specified in the Conformance Test 2.00 [24],

21 - Or “normal”, with configured values with standard masks.

24 • ±50 ppb maximum frequency error
26 interface.
28 air interfaces.
29 Note: This level of accuracy assumes up to 1 (respectively 2) class B T-BC on the path between the
30 branching one and each O-RU implementation suitable for case 1.1 (respectively case 1.2) as defined in
31 eCPRI [11].
33 air interfaces.
34 Note: This level of accuracy assumes direct fiber link between the branching class B T-BC and each O-RU
35 implementation suitable case 1.2 as defined in eCPRI [11] (not supported by case 1.1). It also assumes co-
36 location of the O-RUs and O-DU.
________________________________________________________________________________________________
1 2.2.2.10 Performance test of O-DU + bridged network + Two O-RUs using ITU-T
2 G.8275.1 profile (LLS-C3)

4 This test validates that the two O-RUs are meeting the 3GPP limits at their air interface, and the O-DU is meeting time
5 error limits defined in CUS-Plane specification [2] when
6 • both O-DU and O-RUs get their synchronization from a PRTC using SyncE + PTP over a Full Timing
7 Support network (ITU-T G.8275.1 profile [5], ITU-T G.8271.1 network limits [7])

9 1. IOT Functional Test 2.2.2.3 is successfully passed and all O-DU, bridged network elements and O-RUs report
10 LOCKED status.
11 2. O-RUs and O-DU are connected to bridged network elements acting as ITU-T G.8275.1 class B T-BCs using
12 O-RAN links [5]. This FH network has a local PRTC distributing SyncE and PTP to both O-DU and O-RUs.
14 2.2.2.10.3 Purpose and scope

15 The FH network synchronizes all O-DU and O-RUs with the ITU-T G.8275.1 [5] profile via the bridged network
16 elements.
17 This test validates that the frequency and time error on the O-RU air interfaces and O-DU are within the limits of the
18 3GPP, in both constant and variable temperature and traffic load conditions.

22 Requirements for M-Plane: must be “up and running”
23 Synchronization requirement: FH network and test equipment must be connected to a local PRTC or source traceable to
24 PRTC.

28 configuration, the frequency and phase errors are measured at the O-RUs air interface using a test equipment referenced
29 to the same PRTC.
30 The PRTC output time error on the O-DU is as specified in the Conformance Test 2.00 [24],

32 - Or “normal”, with configured values with standard masks.

35 • ±50 ppb maximum frequency error (mandatory): at the O-RU air interface
37 interface and at the O-DU output test signal (for example 1PPS).
________________________________________________________________________________________________
2 air interfaces.
3 Note: This level of accuracy assumes up to 1 (respectively 2) class B T-BC on the path between the
4 branching one and each O-RU implementation suitable for case 1.1 (respectively case 1.2) as defined in
5 eCPRI [11].
7 air interfaces.
8 Note: This level of accuracy assumes direct fiber link between the branching class B T-BC and each O-RU
9 implementation suitable case 1.2 as defined in eCPRI [11] (not supported by case 1.1). It also assumes co-
10 location of the O-RUs and O-DU.
11 2.2.2.11 Performance test of O-DU + Two O-RUs using ITU-T G.8275.2 profile (LLS-C1)
14 G.8275.2 profile ((LLS-C2)
17 G.8275.2 profile (LLS-C3)
19 2.2.2.14 Performance test of O-DU + bridged network + Two O-RUs (LLS-C4)

21 2.2.3 C/U-Plane IOT Test
22 2.2.3.1 Radio Layer 3 C-Plane establishment and Initial Radio U-Plane data transfer

24 This is a Radio system level test which is used to validate the radio system functionalities, performance and multi-
25 vendor interoperability of the O-DU and O-RU from different vendors connected using the O-RAN WG4 specified FH
26 interface [2], [3].
27 This test validates if a UE can perform Radio Layer 3 C-Plane establishment and initial Radio U-Plane data transfer
28 procedures with the network which includes the O-DU and O-RU as an integrated system under test in this test setup.
29 Although there is no FH focused testing for C/U-Plane in this test, it is still possible to observe successful
30 interoperability via positive test outcomes for this test. ie, if radio system level test passes, it can be assumed that O-
31 RAN WG4 specified FH interface C/U-Plane is successfully working.
33 The DUTs are a single O-DU (DUT1(O-DU)) and a single O-RU (DUT1(O-RU)).
34 This test shall be executed using whichever IOT profile(s) are appropriate for the DUTs. See Annex A for details on the
35 IOT profiles.

________________________________________________________________________________________________
1 • Must be synchronized with the common S-Plane configuration
3 • Single Test UE or UE emulator: used to perform Radio Layer 3 C-Plane establishment and Radio U-Plane
4 data transfers with the network
5 • O-CU or O-CU emulator either as a separate node or as a combined node with the O-DU(s) (DUT): used
6 to provide Layer 2 and Layer 3 radio processing on the network side. In case of separate node, terminates
7 the 3GPP 5G F1 interface with the O-DU(s) (DUT)
8 • 4G Core network or 4G Core network emulator: used to terminate UEs (emulator) NAS protocol in NSA
9 mode
10 • 4G MeNB or 4G MeNB emulator: used to terminate the 3GPP EN-DC X2 interface with 5G CU in NSA
11 mode
12 • 5G Core Network or 5G Core Network emulator: used to terminate UEs (emulator) NAS protocol in SA
13 mode
14 • Application test server: used to generate and terminate application layer traffic (eg. UDP, TWAMP, etc)
15 and provide application layer processing on the network side.
16 Testing tools which can be useful for this test scenario particularly for validating that the DUTs are configured and
17 operating correctly during the test, troubleshooting and detailed validation purposes
18 • FH Protocol Analyzer: used for protocol analysis of O-RAN FH protocols in this specific test scenario,
19 C/U-Plane procedural flows and contents
20 • RF Spectrum and Beam Signal Analyzer: used for RF and Beam power and quality analysis ensuring that
21 the O-RU (DUT1(O-RU)) is transmitting correctly on the configured broadcast and synchronization
22 signals on the downlink

24 Purpose of this test is to validate key radio operation after M-Plane startup, ie, Radio Layer 3 C-Plane establishment and
25 initial Radio U-Plane data transfer on system level with integration of O-DU and O-RU from different vendors.
26 Note that this test requires both Downlink and Uplink Radio Layer 3 C-Plane message. This means that this test also
27 validates both transfer of Downlink and Uplink FH U-Plane message and related Downlink FH C-Plane messages.

29 Nominal software runs on the O-RU and O-DU.
31 2.2.3.1.5.1 Initial Conditions
32 1. O-RU and O-DU are both in service, ie, M-Plane start-up procedure is completed, and broadcast channels are
33 being transmitted
34 2. Test UE or UE emulator has not yet been registered with the network
35 2.2.3.1.5.2 Procedure: Nominal test
36 Performs Radio Layer 3 C-Plane establishment procedure using the Test UE or UE emulator. Note that Radio Layer 3
37 C-Plane establishment procedure depends on the 5G NR operation mode. In the case when the DUTs are operating in
38 NSA mode, Radio Layer 3 C-Plane establishment procedure includes Attach procedure and/or service request procedure
39 specified in 3GPP TS 23.401 [20] and EN-DC setup procedure specified in 3GPP TS 37.340 [22]. In the case when the
40 DUTs are operating in SA mode, Radio Layer 3 C-Plane establishment procedure includes Registration procedure and
41 service request procedure specified in 3GPP TS 23.502 [21].
________________________________________________________________________________________________
1 Performs data transfer from the application test server to the Test UE or UE emulator. The application test server
2 generates and transmits 10 IP packets with each packet 32 bytes in size.
3 Note that data transfer depends on the operation mode. In the case when the DUTs are operating in NSA mode, data
4 transfers can be performed over Default EPS bearer using SN terminated split bearer specified in 3GPP TS 37.340 [22].
5 In case when the DUTs are operating in SA mode, data transfers can be performed over PDU Session and QoS flow
6 specified in 3GPP TS 23.502 [21].
7 This test case does not specify the test data pattern generated by the application test server, but it is recommended that
8 the test data pattern should include some level of randomness (ie, avoiding all zeros).

10 Observe the Test UE or emulated UE can perform Radio Layer 3 C-Plane establishment successfully and can perform
11 data transfers over the network particularly through the O-DU and O-RU.
12 Record Test UE or UE emulator logs that the Radio Layer 3 (eg. RRC/NAS) message flows are per 3GPP TS 23.401
13 [20] Sections 5.3.4, 5.4 and 3GPP TS 37.340 [22] in NSA mode and 3GPP TS 23.502 [21] Sections 4.2.3, 4.3 in SA
14 mode.
15 Record Test UE or UE emulator Radio U-Plane logs that the data packets transferred by application test server (ie, 10 IP
16 packets of 32 bytes) are received correctly.
17 2.2.3.2 Radio U-Plane downlink data transfer (Downlink throughput performance)

21 This scenario allows to test if a UE can perform Radio U-Plane data transfers with the network through O-DU and O-
22 RU from different vendors.
24 IOT profiles.

27 1. Must be connected through the O-RAN FH
28 2. Must be synchronized with the common S-Plane configuration
30 • Single Test UE or UE emulator: used to perform Radio U-Plane data transfers with the network
33 the 3GPP 5G F1 interface with the O-DU(s) (DUT).
35 mode
37 mode
39 mode
________________________________________________________________________________________________
1 • Application test server: used to generate and terminate application layer traffic (eg UDP, TWAMP, etc)
5 • FH Protocol Analyzer: used for protocol analysis of O-RAN FH protocols in this specific test scenario, FH

11 Purpose of this test is to validate key radio operation after Radio Layer 3 C-Plane establishment and initial Radio U-
12 Plane data transfer, the Radio U-Plane data transfer including throughput performance on system level with integration
13 of O-DU and O-RU from different venders.
14 Note that this test requires Maximum Layer 1 Radio data rate (with some margin). This means that this test also
15 validates transfer of Downlink FH C/U-Plane message with higher MIMO layers and higher order modulation schemes.

20 1. O-RU and O-DU are both in service, ie, M-Plane start-up procedure has been completed and broadcast
21 channels are being transmitted.
22 2. Test UE or UE emulator has registered to the network, ie, Radio Layer 3 C-Plane establishment procedure is
23 completed. Note that Radio Layer 3 C-Plane establishment procedure depends on operation mode. In case
24 when the of DUTs are operating in NSA mode, Radio Layer 3 C-Plane establishment procedure includes
25 means Attach procedure and/or service request procedure specified in 3GPP TS 23.401 [20] and EN-DC setup
26 procedure specified in 3GPP TS 37.340 [22]. In case when the of DUTs are operating in SA mode, Radio
27 Layer 3 C-Plane establishment procedure includes means Registration procedure and service request procedure
30 Performs downlink data transfer from application test server to the Test UE or UE emulator. The application test server
31 generates and transmits downlink data with data size large enough to achieve the maximum Layer 1 Radio data rate,
32 which is specified in 2.2.4.2.6, for the duration of the test. The duration of the test is 20 seconds.
33 Note that data transfer depends on the operation mode. In case when the DUTs are operating in NSA mode, data
37 This test case does not specify the test data pattern generated by the application test server, but it is recommended that
38 the test data pattern should include some level of randomness (ie, avoiding all zeros).

40 Observe that the Test UE or emulated UE can perform Radio U-Plane data transfers over the network particularly
41 through the O-DU and O-RU at the target data rate.
________________________________________________________________________________________________
1 Record the Test UE or UE emulator Radio U-Plane logs and determine that they contain measurements such as the
2 measured Radio U-Plane data rates during the test. The acceptance criterion is that Radio U-Plane data rate on average
3 during the test duration achieves the performance level defined as follows
4 Performance level
5 Target data rate = Maximum Layer 1 Radio data rate * (1 - Ratio of Radio resource overhead) * Margin,
6 where
7 Maximum Layer 1 Radio data rate is calculated based on 3GPP TS 38. 211 [15] and TS 38.214 [23] by using RAN
8 parameters, ie, Total channel bandwidth, TDD configuration (when TDD), number of spatial/antenna streams,
9 modulation order and coding rate. Note that these RAN parameters are defined in the IOT profiles (see Annex A for
10 details).
11 Ratio of Radio resource overhead is calculated based on 3GPP TS 38.211 [15] by using Radio physical layer
12 channel configurations, eg, PDCCH resource mapping, Reference signal resource mapping, and so on, assumed in
13 the IOT setup. Note that the physical layer channel configurations are part of the radio test setup configuration.
14 Margin is assumed in order to account for issues other than the FH. The value of Margin is 0.8.
15 2.2.3.3 Radio U-Plane uplink data transfer (Uplink throughput performance)

19 This scenario allows to test if a UE can perform Radio U-Plane data transfers with the network through O-DU and O-
20 RU from different vendors.
22 IOT profiles.

25 1. Must be connected through the O-RAN FH
26 2. Must be synchronized with the common S-Plane configuration
28 • Single Test UE or UE emulator: used to perform Radio U-Plane data transfers with the network
31 the 3GPP 5G F1 interface with the O-DU(s) (DUT).
33 mode
35 mode
37 mode
38 • Application test server: used to generate and terminate application layer traffic (eg UDP, TWAMP, etc)
________________________________________________________________________________________________
3 • FH Protocol Analyzer: used for protocol analysis of O-RAN FH protocols in this specific test scenario, FH

9 Purpose of this test is to validate key radio operation after Radio Layer 3 C-Plane establishment and initial Radio U-
10 Plane data transfer, the Radio U-Plane data transfer including throughput performance on system level with integration
11 of O-DU and O-RU from different venders.
12 Note that this test requires Maximum Layer 1 Radio data rate (with some margin). This means that this test also
13 validates transfer of Uplink FH C/U-Plane message with higher MIMO layers and higher order modulation schemes.

18 1. O-RU and O-DU are both in service, ie, M-Plane start-up procedure has been completed and broadcast channels
19 are being transmitted.
20 2. Test UE or UE emulator has registered to the network, ie, Radio Layer 3 C-Plane establishment procedure is
21 completed. Note that Radio Layer 3 C-Plane establishment procedure depends on operation mode. In case when
22 the of DUTs are operating in NSA mode, Radio Layer 3 C-Plane establishment procedure includes means
23 Attach procedure and/or service request procedure specified in 3GPP TS 23.401 [20] and EN-DC setup
24 procedure specified in 3GPP TS 37.340 [22]. In case when the of DUTs are operating in SA mode, Radio Layer
25 3 C-Plane establishment procedure includes means Registration procedure and service request procedure
28 Performs uplink data transfer from the Test UE or UE emulator to application test server on the network side. Either the
29 Test UE or UE emulator, or application test server connected with UE generates and transmits uplink data with data size
30 large enough to achieve the maximum Layer 1 Radio data rate, which is specified in 2.2.3.3.6, for the duration of the
31 test. The Test UE or UE emulator transmits the uplink data. The duration of the test is 20 seconds.
32 Note that data transfer depends on the operation mode. In case when the DUTs are operating in NSA mode, data
36 This test case does not specify the test data pattern generated by either the Test UE or UE emulator, or application test
37 server connected with UE, but it is recommended that the test data pattern should include some level of randomness (ie,
38 avoiding all zeros).

40 Observe that the Test UE or emulated UE can perform Radio U-Plane data transfers over the network particularly
41 through the O-DU and O-RU at the target data rate.
________________________________________________________________________________________________
1 Record the Test UE or UE emulator Radio U-Plane logs and determine that they contain measurements such as the
2 measured Radio U-Plane data rates during the test. The acceptance criterion is that Radio U-Plane data rate on average
3 during the test duration achieves the performance level defined as follows
4 Performance level
5 Target data rate = Maximum Layer 1 Radio data rate * (1 - Ratio of Radio resource overhead) * Margin,
6 where
7 Maximum Layer 1 Radio data rate is calculated based on 3GPP TS 38. 211 [15] and TS 38.214 [23] by using RAN
8 parameters, ie, Total channel bandwidth, TDD configuration (when TDD), number of spatial/antenna streams,
9 modulation order and coding rate. Note that these RAN parameters are defined in the IOT profiles (see Annex A for
10 details).
11 Ratio of Radio resource overhead is calculated based on 3GPP TS 38.211 [15] by using Radio physical layer
12 channel configurations, eg, PUCCH resource mapping, Reference signal resource mapping, and so on, assumed in
13 the IOT setup. Note that the physical layer channel configurations are part of the radio test setup configuration.
14 Margin is assumed in order to account for issues other than the FH. The value of Margin is 0.8.
15 2.2.4 C/U-Plane Delay Management IOT Test

16 The test cases defined in this section will validate that the transmitted Control- and User-data packets sent from the O-
17 DU are received within the reception windows at the O-RU by checking that the frame timing on the air interface is
18 correct.
19 The same is applicable for uplink direction, i.e. that the User-data packets sent from the O-RU are received within the
20 reception window on the O-DU, this is done by checking that it is possible for a test UE to attach and send data.
21 For all currently defined IOT Profiles the O-DU timing advance type is ‘Fixed Timing Advance’. The Figure below is
22 copied from the CUS-Specification section 2.3.5 “Latency Categories for O-DU with fixed timing advance”.
23
24 Figure 2-8: CUS-Specification section 2.3.5 “Latency Categories for O-DU with fixed timing advance”.
25 The Figure shows the downlink timing when fixed timing is used, the point TX DL_Start is a fixed point in relation to the
26 “OTA transmission” point.
27 The O-DU needs only to be configured with T12max, T12min and Tcp_adv_dl the values are taken from the profile that is used
28 when running these test cases. The Tcp_adv_dl value is the time in advance the O-RU needs the C-Plane messages before
29 the U-Plane information is received by the O-RU. These test cases assume a symmetric latency in the Fronthaul
30 Network, i.e. T12=T34.
________________________________________________________________________________________________
1 These test cases assume that the difference between “fixed timing advance” and “dynamic timing advance” is that for
2 “fixed timing advance” the O-DU will advance the transmission of downlink data the same amount of time for all
3 connected O-RUs regardless of the individual fronthaul latency, for “dynamic timing advance” the advancement could
4 be different per O-RU and thus e.g. T12max must be configured per O-RU.
5 An O-DU running in “Fixed Timing Advance”-mode is an O-DU that has the ability to handle a specific value for T1a
6 (sum of fronthaul latency T12 and O-RU processing delay T2a). The O-DU will set the TXDL_Start to this fixed value
7 independent on actual T12_max value.
8 TXmaxlls-CU will vary due to different line-rates of the fronthaul interface and amount of data (control+user) that is sent
9 for a specific symbol.
10 2.2.4.1 Test environment

11 Testing tools which are required for the delay management test cases.
12 • Single Test UE or UE emulator: used to perform Radio Layer 3 C-Plane establishment and Radio U-Plane
13 data transfers with the network
16 the 3GPP 5G F1 interface with the O-DU(s) (DUT)
18 mode
20 mode
22 mode
23 • Application test server: used to generate and terminate application layer traffic (eg. UDP, TWAMP, etc)
27 • FH Protocol Analyzer: used for protocol analysis of O-RAN FH protocols in this specific test scenario,
32
________________________________________________________________________________________________
1 Figure 2-9: Delay-management test environment
2 2.2.4.2 Timing accuracy definition

3 When in “Test Requirement (expected result)” it is stated “… timing accuracy at the antenna reference point is
4 according to requirement” the following is applicable.
5 In ORAN WG4 CUS-specification section 9.2.5.4 “Air interface maximum time error”, tables 9-1 and 9-2 lists the
6 3GPP air interface timing accuracy for different LTE and 5G features. The timing accuracy requirements are divided
7 into 2 alternatives, relative or absolute time errors.
8 Depending on what 3GPP features that are to be supported by a specific IOT-profile different timing accuracy
9 requirement is thus applicable.
10 2.2.4.3 Delay Management #1, minimum fronthaul latency

15 This test validates that the O-RU will transmit the user data at correct point in time and with correct content during
16 different conditions related to the fronthaul interface latency between the O-DU and the O-RU.

________________________________________________________________________________________________

3 Purpose of this test is to validate that correct timing is achieved on the air interface regardless of the actual fronthaul
4 latency and O-RU processing time.

9 1. The fronthaul latency should be at a minimum for this test case. The T12_min in current IOT-Profiles is 0µs.
10 0µs is not possible to achieve in reality, instead the shortest possible fronthaul latency with existing test
11 equipment is sufficient for this initial condition.
12 2. O-RU and O-DU are both in service, i.e. M-Plane start-up procedure is completed and broadcast channels are
14 3. Test UE or UE emulator has registered to the network, i.e. Radio Layer 3 C-Plane establishment procedure is
15 completed.
17 Performs downlink and uplink data transfer to/from the test UE.

19 Observe that:
20 1. With Fronthaul Protocol Analyzer (connected at the O-DU-end of fronthaul interface), observe that the
21 fronthaul C- and U-Plane messages transmitted by the O-DU are transmitted within respective plane’s
22 transmission windows.
23 2. With Fronthaul Protocol Analyzer (connected at the O-RU-end of fronthaul interface), observe that the
24 fronthaul C- and U-Plane messages in downlink direction are received within respective plane’s reception
25 window by the O-RU.
26 3. With the RF Spectrum Analyzer, observe that the air interface transmission timing accuracy at the antenna
27 reference point is according to requirements as specified in section 2.2.4.2. Also observe that frame numbering,
28 slot and symbol timing is according to section 9.7.2 “System Frame Number Calculation from GPS Time” in
29 CUS-Specification.
30 4. With Fronthaul Protocol Analyzer (connected at the O-RU-end of fronthaul interface), observe that the U-Plane
31 messages transmitted by the O-RU (uplink direction) are transmitted within the O-RU’s transmission window.
32 2.2.4.4 Delay Management #2, maximum fronthaul latency

38 different conditions related to the fronthaul interface between the O-DU and the O-RU.
________________________________________________________________________________________________



12 1. The fronthaul latency should be at a maximum for this test case. The T12_max in current IOT-Profiles is 160µs.
16 completed.

20 Observe that:
28 reference point is according to requirements as specified in section 2.2.4.2. Also observe that frame numbering,
29 slot and symbol timing is according to section 9.7.2 “System Frame Number Calculation from GPS Time” in
30 CUS-Specification.
31 4. With Fronthaul Protocol Analyzer (connected at the O-RU-end of fronthaul interface), observe that the U-Plane
32 messages transmitted by the O-RU (uplink direction) are transmitted within the O-RU’s transmission window.
33 2.2.4.5 Delay Management #3, normal fronthaul latency

________________________________________________________________________________________________
2 different conditions related to the fronthaul interface between the O-DU and the O-RU.



14 1. The fronthaul latency should be set to an arbitrary value between 0 and 160µs e.g. 75µs.
18 completed.

22 Observe that:
30 reference point is according to requirements as specified in section 2.2.4.2. Also observe that frame
31 numbering, slot and symbol timing is according to section 9.7.2 “System Frame Number Calculation from
32 GPS Time” in CUS-Specification.
33 4. With Fronthaul Protocol Analyzer (connected at the O-RU-end of fronthaul interface), observe that the U-
34 Plane messages transmitted by the O-RU (uplink direction) are transmitted within the O-RU’s transmission
35 window.
________________________________________________________________________________________________
1 2.2.4.6 Delay Management #4, larger fronthaul latency then supported

6 This test validates that the O-RU will not transmit anything on the air interface when the latency in the fronthaul
7 network is larger than is supported by the O-RU, i.e. the C- and U-Plane messages will be received too late on the O-
8 RU (outside its reception window) and thus be dropped by the O-RU.



20 1. The fronthaul latency should be set to a value that is larger than the O-DU’s category specifies.
22 -

24 Observe that the no cell is being transmitted by the O-RU over the air interface.
________________________________________________________________________________________________
1 Annex A Profiles used for Interoperability Testing

2 This section contains the interoperability testing profiles.
3 Sometimes the value of existing IOT profile parameter will change from one version of the specification to the next. Therefore, it is necessary to refer to both the IOT profile
4 name and the particular version of the WG4 IOT specification to ensure that the appropriate set of profile parameters are referenced. Where such change has occurred from one
5 release to the next the change is called out with a footnote.
6 A.1 M-Plane IOT Profile

7 A.1.1 M-Plane IOT Profile 1
8 Table A.1.1-1: Hierarchical-sudo1
Category Item Related O-RAN specification and section
Architectural models 2.1.2 M-Plane architecture model Hierarchical model

High Level IP version 2.1.3 Transport Network IPv4
Description Hash algorithm for data integrity 2.4 Security HMAC-SHA2-2562
Cyphering algorithm 2.4 Security AES128-CTR3
O-RU identification by DHCP option 3.1.1 O-RU identification in DHCP DHCPv4(Option: 60)
3.1.2 Management Plane VLAN Discovery
“Start up” VLAN Discovery support VLAN SCAN
Aspects
installation
3.1.3 O-RU Management Plane IP Address
IP address assignment IPv4 configuration using DHCPv4
Assignment
1 The profile name in the previous specification is "M-Plane IOT profile 1"
2 The parameter in the previous specification version is SHA1
3 The parameter in the previous specification version is 3DES-CBC
______________________________________________________________________________________________________________________________________________

O-RU controller discovery 3.1.4 O-RU Controller Discovery DHCPv4 option 43
DHCP format of O-RU controller discovery 3.1.4 O-RU Controller Discovery O-RU Controller IP Address
3.2 NETCONF Call Home to O-RU

NETCONF Call Home call home(port4334)
Controller(s)
SSH Connection Establishment 3.3 SSH Connection Establishment password-based authentication
TCP port for SSH establishment (for test
3.3.1 NETCONF Security Default (port 830)
purpose)
NETCONF Authentication 3.3.2 NETCONF Authentication password-based authentication
User Account Provisioning 3.3.3 User Account Provisioning default sudo

sudo 3.4 NETCONF Access Control used
nms 3.4 NETCONF Access Control not used
fm-pm 3.4 NETCONF Access Control not used
swm 3.4 NETCONF Access Control not used
yang-library,
Writable-running Capability,
NETCONF capability 3.5 NETCONF capability discovery XPATH capability,
Notifications,
Interleave capability
Watchdog timer 3.6 Monitoring NETCONF connectivity used

VLAN tagging for C/U/M-Plane Aspects used for C/U/M-Plane
4.3 C/U Plane VLAN Configuration
O-RU to O-DU C/U Plane IP Address Assignment 4.4 O-RU C/U Plane IP Address Assignment not used
Interface
Management Definition of processing elements 4.5 Definition of processing elements a combination of VLAN identity and MAC address
4.6 Verifying C/U Plane Transport

C/U Plane Transport Connectivity Loop-back Protocol (LB/LBM)
Connectivity
______________________________________________________________________________________________________________________________________________

O-RU Monitoring of C/U Plane 4.10 O-RU Monitoring of C/U Plane
not used
Connectivity Connectivity
Configuration
Baseline configuration 6.1 Baseline configuration 2 phases
Management
Fault Management subscribe notification 8.2 Manage Alarms Request default stream
Synchronization
Sync Capability Object 10.2 Sync Capability Object CLASS_B
Aspects
Details of O-RU
Activation, deactivation and sleep 12.3.2 Activation, deactivation and sleep used
Operations
1
2 A.1.2 M-Plane IOT Profile 2

3 Table A.1.2-1: Hybrid-sudo+nms4

Architectural models 2.1.2 M-Plane architecture model Hybrid model
High Level IP version 2.1.3 Transport Network IPv4
Description Hash algorithm for data integrity 2.4 Security HMAC-SHA2-2565
Cyphering algorithm 2.4 Security AES128-CTR6
O-RU identification by DHCP option 3.1.1 O-RU identification in DHCP DHCPv4(Option: 60)
“Start up” installation 3.1.2 Management Plane VLAN Discovery
VLAN Discovery support VLAN SCAN
Aspects
4 The profile name in the previous specification is "M-Plane IOT Profile 2"
5 The parameter in the previous specification version is SHA1
6 The parameter in the previous specification version is 3DES-CBC
______________________________________________________________________________________________________________________________________________

3.1.3 O-RU Management Plane IP Address
IP address assignment IPv4 configuration using DHCPv4
Assignment
O-RU controller discovery 3.1.4 O-RU Controller Discovery DHCPv4 option 43
DHCP format of O-RU controller discovery 3.1.4 O-RU Controller Discovery O-RU Controller IP Address
3.2 NETCONF Call Home to O-RU

NETCONF Call Home call home(port4334)
Controller(s)
SSH Connection Establishment 3.3 SSH Connection Establishment password-based authentication
TCP port for SSH establishment (for test
3.3.1 NETCONF Security Default (port 830)
purpose)
NETCONF Authentication 3.3.2 NETCONF Authentication password-based authentication
User Account Provisioning 3.3.3 User Account Provisioning default sudo

sudo 3.4 NETCONF Access Control used
nms 3.4 NETCONF Access Control used
fm-pm 3.4 NETCONF Access Control not used
swm 3.4 NETCONF Access Control not used
yang-library,
Writable-running Capability,
NETCONF capability 3.5 NETCONF capability discovery XPATH capability,
Notifications,
Interleave capability
Watchdog timer 3.6 Monitoring NETCONF connectivity used

VLAN tagging for C/U/M-Plane Aspects used for C/U/M-Plane
O-RU to O-DU 4.3 C/U Plane VLAN Configuration
Interface
C/U Plane IP Address Assignment 4.4 O-RU C/U Plane IP Address Assignment not used
Management
Definition of processing elements 4.5 Definition of processing elements a combination of VLAN identity and MAC address
______________________________________________________________________________________________________________________________________________

4.6 Verifying C/U Plane Transport
C/U Plane Transport Connectivity Loop-back Protocol (LBM/LBR)
Connectivity
O-RU Monitoring of C/U Plane 4.10 O-RU Monitoring of C/U Plane
not used
Connectivity Connectivity
Configuration
Baseline configuration 6.1 Baseline configuration 2 phases
Management
Fault Management subscribe notification 8.2 Manage Alarms Request default stream
Synchronization
Sync Capability Object 10.2 Sync Capability Object CLASS_B
Aspects
Details of O-RU not used
Activation, deactivation and sleep 12.3.2 Activation, deactivation and sleep
Operations
1
2 A.2 CUS-Plane IOT Profiles

3 A.2.1 NR TDD
4 A.2.1.1 NR TDD IOT Profile 1 - NR-TDD-FR1-CAT-A-NoBF

5 Profile Test Configurations
6 • NR-TDD-FR1-CAT-A-NoBF_[25Gbpsx1lane-PRACHB4-eAxCID2644]
7 • NR-TDD-FR1-CAT-A-NoBF_[10Gbpsx2lane-PRACHC2-eAxCID4246]
8 Table A.2.1.1-1: NR TDD IOT Profile 1 - NR-TDD-FR1-CAT-A-NoBF
Related O-RAN fronthaul specification

Category Item
and section
Radio access technology - NR TDD
General pattern1{
TDD configuration - dl-UL-TransmissionPeriodicity ms3
nrofDownlinkSlots 3
______________________________________________________________________________________________________________________________________________

Category Item
and section
nrofDownlinkSymbols 6
nrofUplinkSlots 2
nrofUplinkSymbols 4}
pattern2{
dl-UL-TransmissionPeriodicity ms2
nrofDownlinkSlots 4
nrofUplinkSlots 0
Nominal sub-carrier spacing - 30 kHz
SSB sub-carrier spacing - 30 kHz
Nominal FFT size - 4096
Total channel bandwidth - 100MHz x 1CC
Number of spatial/antenna streams - 4
Entry1: 25Gbps x 1lane
Fronthaul Ethernet link -
Entry2: 10Gbps x 2lane
Entry1: B4
PRACH preamble format -
Entry2: C2
RU category ORAN-WG4.CUS.0-v05.00 section 2.1 Category A
LAA - FALSE
Network delay determination ORAN-WG4.CUS.0-v05.00 section 2.3.3 Defined Transport Method
RU adaptation of delay profile information
(based on O-DU delay profile and transport ORAN-WG4.CUS.0-v05.00 section 2.3.3.2 FALSE
delay)
ORAN-WG4.CUS.0-v05.00 section 2.3.4-
Delay O-DU timing advance type Fixed Timing Advance
2.3.5, Annex B
management ORAN-WG4.CUS.0-v05.00 section 2.3,
T1a_max_up Less than or equal to 345us
Annex B
ORAN-WG4.CUS.0-v05.00 section 2.3,
T1a_min_up More than or equal to 294us
Annex B
T2a_max_up More than or equal to 345us
Annex B
______________________________________________________________________________________________________________________________________________

Category Item
and section
T2a_min_up Less than or equal to 134us
Annex B
ORAN-WG4.CUS.0-v05.00 section 2.3.2,
Tcp_adv_dl 125 us
Annex B
Ta3_max_up Less than or equal to 171us
Annex B
Ta3_min_up More than or equal to 50us
Annex B
Ta4_max_up More than or equal to 331us
Annex B
Ta4_min_up Less than or equal to 50us
Annex B
T1a_max_cp_ul Less than or equal to 336us
2.3.3, Annex B
T1a_min_cp_ul More than or equal to 285us
2.3.3, Annex B
T2a_max_cp_ul More than or equal to 336us
2.3.3, Annex B
T2a_min_cp_ul Less than or equal to 125us
2.3.3, Annex B
T12_max 160 us
Annex B
T12_min 0 us
Annex B
T34_max 160 us
Annex B
T34_min 0 us
Annex B
Non-delay managed U-Plane traffic ORAN-WG4.CUS.0-v05.00 section 2.3.6 FALSE
Transport encapsulation Ethernet
3.1.2
C/U-Plane Jumbo frames ORAN-WG4.CUS.0-v05.00 section 3.1.2 FALSE
transport
Transport header ORAN-WG4.CUS.0-v05.00 section 3.1.3 eCPRI
eCPRI concatenation ORAN-WG4.CUS.0-v05.00 section 3.1.3.1 FALSE
______________________________________________________________________________________________________________________________________________

Category Item
and section
Entry1: 2
eAxC ID DU_Port_ID bitwidth ORAN-WG4.CUS.0-v05.00 section 3.1.3.1.6
Entry2: 4
Entry1: 6
eAxC ID BandSector_ID bitwidth ORAN-WG4.CUS.0-v05.00 section 3.1.3.1.6
Entry2: 2
eAxC ID CC_ID bitwidth ORAN-WG4.CUS.0-v05.00 section 3.1.3.1.6 4
Entry1: 4
eAxC ID RU_Port_ID bitwidth ORAN-WG4.CUS.0-v05.00 section 3.1.3.1.6
Entry2: 6
Fragmentation ORAN-WG4.CUS.0-v05.00 section 3.5 Application layer fragmentation
Transport prioritization across C/U/S/M-
ORAN-WG4.CUS.0-v05.00 section 3.3 Default L2 CoS priority
Plane
Transport prioritization within U-Plane ORAN-WG4.CUS.0-v05.00 section 3.3 False (Default U-Plane priority applies)
Separation of C/U-Plane and M-Plane

ORAN-WG4.CUS.0-v05.00 section 3.4 VLAN ID
traffic
Transport-based separation within C/U-
ORAN-WG4.CUS.0-v05.00 section 3.4 FALSE
Plane traffic
Digital Power
UL gain_correction ORAN-WG4.CUS.0-v05.00 section 6.1.3.2 0dB
Scaling
RU beamforming type ORAN-WG4.CUS.0-v05.00 section 2.1 No beamforming

Beamforming
Beamforming control method Beamforming ID based (always "0")
Annex J
ORAN-WG4.CUS.0-v05.00 section 6, Annex
U-Plane data compression method Block floating point
A
IQ compression U-Plane data IQ bitwidth 14
D
IQ data frame format not including
ORAN-WG4.CUS.0-v05.00 section 6.3.3.13 TRUE
udCompHdr field
Section Type 0 ORAN-WG4.CUS.0-v05.00 section 5.4.2 TRUE
C-Plane Section Type 1 ORAN-WG4.CUS.0-v05.00 section 5.4.2 TRUE
______________________________________________________________________________________________________________________________________________

Category Item
and section
Section Type 5 ORAN-WG4.CUS.0-v05.00 section 5.4.2 FALSE
"symInc" flag ORAN-WG4.CUS.0-v05.00 section 5.4.5.3 FALSE (always set to '0')
C-Plane for PRACH formats with preamble
ORAN-WG4.CUS.0-v05.00 section 5.3.2 Single C-Plane message
repetition
Section extension 1 ORAN-WG4.CUS.0-v05.00 section 5.4.6 FALSE
G.8275.1 ORAN-WG4.CUS.0-v05.00 section 3.2.3, 9 TRUE
G.8275.2 ORAN-WG4.CUS.0-v05.00 section 3.2.3, 9 FALSE
S-Plane GNSS based sync ORAN-WG4.CUS.0-v05.00 section 3.2.3, 9 FALSE
SyncE TRUE
H
Topology configuration ORAN-WG4.CUS.0-v05.00 section 9.2.2 lls-C1 (can also apply lls-C2)
1
2 A.2.1.2 NR TDD IOT Profile 2 - NR-TDD-FR1-CAT-A-DBF

4 • NR-TDD-FR1-CAT-A-DBF_[100MHz-llsC1C2]
5 • NR-TDD-FR1-CAT-A-DBF_[80MHz-llsC3]
6 Table A.2.1.2-1: NR TDD IOT Profile 2 - NR-TDD-FR1-CAT-A-DBF

Category Item
and section
General Radio access technology - NR TDD
______________________________________________________________________________________________________________________________________________

Category Item
and section
pattern1{
nrofDownlinkSlots 3
nrofUplinkSlots 2
TDD configuration -
pattern2{
nrofDownlinkSlots 4
nrofUplinkSlots 0

Entry1: 100MHz x 1CC
Total channel bandwidth -
Entry2: 80MHz x 1CC
Fronthaul Ethernet link - 25Gbps x 1lane
PRACH preamble format - B4
LAA - FALSE
Delay delay)
management ORAN-WG4.CUS.0-v05.00 section 2.3.4-
O-DU timing advance type Fixed Timing Advance
2.3.5, Annex B
Annex B
______________________________________________________________________________________________________________________________________________

Category Item
and section
Annex B
Annex B
Annex B
Tcp_adv_dl 125 us
Annex B
Annex B
Annex B
Annex B
Annex B
2.3.3, Annex B
2.3.3, Annex B
2.3.3, Annex B
2.3.3, Annex B
T12_max 160 us
Annex B
T12_min 0 us
Annex B
T34_max 160 us
Annex B
T34_min 0 us
Annex B
C/U-Plane Transport encapsulation Ethernet
3.1.2
transport
Jumbo frames ORAN-WG4.CUS.0-v05.00 section 3.1.2 FALSE
______________________________________________________________________________________________________________________________________________

Category Item
and section
eAxC ID DU_Port_ID bitwidth ORAN-WG4.CUS.0-v05.00 section 3.1.3.1.6 2
eAxC ID BandSector_ID bitwidth ORAN-WG4.CUS.0-v05.00 section 3.1.3.1.6 6
eAxC ID RU_Port_ID bitwidth ORAN-WG4.CUS.0-v05.00 section 3.1.3.1.6 4
Plane

traffic
Plane traffic
Digital Power
Scaling
RU beamforming type ORAN-WG4.CUS.0-v05.00 section 2.1 Digital beamforming

Beamforming
Beamforming control method Beamforming ID based
Annex J
A
D
udCompHdr field
______________________________________________________________________________________________________________________________________________

Category Item
and section
repetition
GNSS based sync ORAN-WG4.CUS.0-v05.00 section 3.2.3, 9 FALSE
S-Plane
SyncE TRUE
H
Entry1: lls-C1 (can also apply lls-C2)
Topology configuration ORAN-WG4.CUS.0-v05.00 section 9.2.2
Entry2: lls-C3
1
2 A.2.1.3 NR TDD IOT Profile 3 - NR-TDD-FR2-CAT-A-ABF

4 • NR-TDD-FR2-CAT-A-ABF_[100MHz-SSB240kHz&PRACHC0-eAxCID2644-llsC1C2]
9 • NR-TDD-FR2-CAT-A-ABF_[100MHz-SSB120kHz&PRACHA3-eAxCID2644-llsC1C2]
______________________________________________________________________________________________________________________________________________
10
11 • NR-TDD-FR2-CAT-A-ABF_[200MHz-SSB120kHz&PRACHA3-eAxCID2644-llsC3]
15
16 Table A.2.1.3-1: NR TDD IOT Profile 3 - NR-TDD-FR2-CAT-A-ABF

Category Item
and section
dl-UL-TransmissionPeriodicity: ms0p625
nrofDownlinkSlots: 3
General TDD configuration - nrofDownlinkSymbols: 10
nrofUplinkSlots: 1
nrofUplinkSymbols: 2
______________________________________________________________________________________________________________________________________________

Category Item
and section
Entry1: 240kHz
SSB sub-carrier spacing -
Entry2: 120KHz
25Gbps x 1lane for 100MHz x 1,2,3,4CC,
25Gbps x 2lane for 100MHz x 6,8CC
Entry1: C0
PRACH preamble format - Entry2: A3
Entry3: C2
LAA - FALSE
delay)
2.3.5, Annex B
Delay T1a_max_up Less than or equal to 264us
Annex B
management ORAN-WG4.CUS.0-v05.00 section 2.3,
Annex B
Annex B
Annex B
Tcp_adv_dl 63 us
Annex B
______________________________________________________________________________________________________________________________________________

Category Item
and section
Annex B
Annex B
Annex B
Annex B
2.3.3, Annex B
2.3.3, Annex B
2.3.3, Annex B
2.3.3, Annex B
T12_max 160 us
Annex B
T12_min 0 us
Annex B
T34_max 160 us
Annex B
T34_min 0 us
Annex B
3.1.2
C/U-Plane eCPRI concatenation ORAN-WG4.CUS.0-v05.00 section 3.1.3.1 FALSE
transport
Entry1: 2
Entry2: 4
Entry1: 6
eAxC ID BandSector_ID bitwidth ORAN-WG4.CUS.0-v05.00 section 3.1.3.1.6
Entry2: 2
______________________________________________________________________________________________________________________________________________

Category Item
and section
Entry1: 4
eAxC ID RU_Port_ID bitwidth ORAN-WG4.CUS.0-v05.00 section 3.1.3.1.6
Entry2: 6
Plane
traffic
Plane traffic
Digital Power
Scaling
RU beamforming type ORAN-WG4.CUS.0-v05.00 section 2.1 Analog beamforming

Beamforming
Annex J
A
D
udCompHdr field
C-Plane Section Type 6 ORAN-WG4.CUS.0-v05.00 section 5.4.2 FALSE
repetition
______________________________________________________________________________________________________________________________________________

Category Item
and section
S-Plane
SyncE TRUE
H
Entry2: lls-C3
1
2 A.2.1.4 NR TDD IOT M-MIMO Profile 1 - NR-TDD-FR1-CAT-B-mMIMO-RTWeights-BFP

3 Profile Test Configurations:
4 Specific Profile Test Configurations associated with this profile are FFS; it is expected that a subset will be selected from the possible total set of permutations. In addition,
5 "TBD" entries will be provided in the next specification version.
6 Table A.2.1.4-1: NR TDD IOT M-MIMO Profile 1 - NR-TDD-FR1-CAT-B-mMIMO-RTWeights-BFP
Category Item Related O-RAN fronthaul specification and section

Entry1: DDDFUUDDDD
TDD configuration -
Entry2: DDDFU
General Nominal sub-carrier spacing - 30kHz
SSB sub-carrier spacing - 30kHz
Nominal FFT size - 4096(100MHz_BW)
Total channel bandwidth - 100MHz x 1 CC
______________________________________________________________________________________________________________________________________________
Entry1: 8L (DL), 8 streams (UL)

Number of spatial/antenna streams - Entry2: 16L (DL), 16 streams
(UL)
Fronthaul Ethernet link - 25Gbps x 2 lane (16L, 1CC)
Entry1: Long preamble F0
PRACH preamble format - Entry2: B4
Entry3: C2
RU category ORAN-WG4.CUS.0-v05.00 section 2.1 Category B
LAA - FALSE
RU adaptation of delay profile
information
ORAN-WG4.CUS.0-v05.00 section 2.3.3.2 FALSE
(based on O-DU delay profile and
transport delay)
ORAN-WG4.CUS.0-v05.00 section 2.3.4-2.3.5, Annex
O-DU timing advance type Fixed timing Advance
B
T1a_max_up ORAN-WG4.CUS.0-v05.00 section 2.3, Annex B Less than or equal to 345us
T1a_min_up ORAN-WG4.CUS.0-v05.00 section 2.3, Annex B More than or equal to 294us
T1a_max_cp_dl ORAN-WG4.CUS.0-v05.00 section 2.3, Annex B Less than or equal to 669us
T1a_min_cp_dl ORAN-WG4.CUS.0-v05.00 section 2.3, Annex B More than or equal to 419us
Delay
management T2a_max_up ORAN-WG4.CUS.0-v05.00 section 2.3, Annex B More than or equal to 345us
T2a_min_up ORAN-WG4.CUS.0-v05.00 section 2.3, Annex B Less than or equal to 134us
T2a_max_cp_dl ORAN-WG4.CUS.0-v05.00 section 2.3.2, Annex B More than or equal to 669us
T2a_min_cp_dl ORAN-WG4.CUS.0-v05.00 section 2.3, Annex B Less than or equal to 259us
Tcp_adv_dl ORAN-WG4.CUS.0-v05.00 section 2.3, Annex B 125us
Ta3_max_up ORAN-WG4.CUS.0-v05.00 section 2.3, Annex B Less than or equal to 171us
Ta3_min_up ORAN-WG4.CUS.0-v05.00 section 2.3, Annex B More than or equal to 50us
Ta4_max_up ORAN-WG4.CUS.0-v05.00 section 2.3, Annex B More than or equal to 331us
Ta4_min_up ORAN-WG4.CUS.0-v05.00 section 2.3, Annex B Less than or equal to 50us
Ta3_max_up (scs=1.25kHz) ORAN-WG4.CUS.0-v05.00 section 2.3, Annex B TBD
______________________________________________________________________________________________________________________________________________
Ta3_min_up (scs=1.25kHz) ORAN-WG4.CUS.0-v05.00 section 2.3, Annex B TBD

Ta4_max_up (scs=1.25kHz) TBD
B
Ta4_min_up (scs=1.25kHz) TBD
B
B
B
T2a_max_cp_ul ORAN-WG4.CUS.0-v05.00 section 2.3, Annex B More than or equal to 535us
T2a_min_cp_ul ORAN-WG4.CUS.0-v05.00 section 2.3, Annex B Less than or equal to 125us
T12_max ORAN-WG4.CUS.0-v05.00 section 2.3, Annex B 160us
T12_min ORAN-WG4.CUS.0-v05.00 section 2.3, Annex B 0us
Non-delay managed U-Plane traffic ORAN-WG4.CUS.0-v05.00 section 2.3.6 Support
Transport encapsulation ORAN-WG4.CUS.0-v05.00 section 3.1.1-3.1.2 Ethernet
Entry1: TRUE
Jumbo frames ORAN-WG4.CUS.0-v05.00 section 3.1.2
Entry2: FALSE
C/U-Plane
transport
ORAN-WG4.CUS.0-v05.00 section 3.3 Default L2 CoS Priority
Plane
Transport prioritization within U-Plane ORAN-WG4.CUS.0-v05.00 section 3.3 TRUE
______________________________________________________________________________________________________________________________________________
Seperation of C/U-Plane and M-Plane

traffic
Plane traffic
Digital Power
UL gain_correction ORAN-WG4.CUS.0-v05.00 section 6.1.3.2 0 dB
Scaling
O-RU beamforming type ORAN-WG4.CUS.0-v05.00 section 2.1 Digital beamforming
Beamforming control method ORAN-WG4.CUS.0-v05.00 section 5.4, Annex J RT Weights (Frequency Domain)
Beamforming
Entry 1 : Fixed Point, 12-bit
BFW IQ ORAN-WG4.CUS.0-v05.00 section 5.4, Annex J
Entry 2 : BFP, 9-bit
U-Plane data compression method ORAN-WG4.CUS.0-v05.00 section 6, Annex A BFP
U-Plane (DL/UL) data IQ bitwidth ORAN-WG4.CUS.0-v05.00 section 6, Annex D 9
IQ compression
udCompHdr field
"symInc" flag ORAN-WG4.CUS.0-v05.00 section 5.4.5.3 FALSE (always set to "0")
C-Plane
C-Plane for PRACH formats with
preamble repetition
Section extension 1 (beamforming
ORAN-WG4.CUS.0-v05.00 section 5.4.6 TRUE
weights)
ORAN-WG4.CUS.0-v05.00 section 5.4.6 FALSE
attributes)
Section extension 3 (DL Precoding
configuration parameters and ORAN-WG4.CUS.0-v05.00 section 5.4.6 FALSE
indications)
______________________________________________________________________________________________________________________________________________
Section extension 4 (modulation compr.

params)
Section extension 5 (modulation
compression additional scaling ORAN-WG4.CUS.0-v05.00 section 5.4.6 FALSE
parameters)
Section extension 6 (Non-contiguous
PRB allocation)
Section extension 7 (Multiple-eAxC
designation)
Section extension 8 (regularization
factor)
Section extension 9 (Dynamic Spectrum
Sharing parameters)
Section extension 10 (Multiple ports
grouping)
Section extension 11 (Flexible BF
weights)
PTP Full Timing Support (G.8275.1) ORAN-WG4.CUS.0-v05.00 section 3.2.3, 9 TRUE
PTP Partial Timing Support (G.8275.2) ORAN-WG4.CUS.0-v05.00 section 3.2.3, 9 FALSE
S-Plane Entry 1) lls-C1 (can also apply
lls-C2)
ORAN-WG4.CUS.0-v05.00 section 9.2.2
Topology configuration Entry 2) lls-C1 (PLFS not
ORAN-WG4.CUS.0-v05.00 section 8, 9.2.3 (for PLFS)
required by O-RU)
Entry 3) lls-C3
1
______________________________________________________________________________________________________________________________________________
1 A.2.1.5 NR TDD IOT M-MIMO Profile 2 - NR-TDD-FR1-CAT-B-mMIMO-RTWeights-ModComp

5 Table A.2.1.5-1: NR TDD IOT M-MIMO Profile 2 - NR-TDD-FR1-CAT-B-mMIMO-RTWeights-ModComp

Entry1: DDDFUUDDDD
TDD configuration -
Entry2: DDDFU
Nominal sub-carrier spacing - 30kHz
Entry1: 100MHz x 1 CC
Entry2: 100 MHz x 2 CC
General Entry1: 8L (DL), 8 streams (UL)
Number of spatial/antenna streams -
Entry1: 25Gbps x 2 lane (16L, 1CC)
Entry3: C2
O-RU category ORAN-WG4.CUS.0-v05.00 section 2.1 Category B
LAA - FALSE
O-RU adaptation of delay profile
Delay information (based on lls-CU delay ORAN-WG4.CUS.0-v05.00 section 2.3.3.2 FALSE
management profile and transport delay)
B
______________________________________________________________________________________________________________________________________________

T2a_max_up ORAN-WG4.CUS.0-v05.00 section 2.3, Annex B More than or equal to 345us
B
B
B
B
______________________________________________________________________________________________________________________________________________

Entry1: TRUE
Entry2: FALSE
C/U-Plane eAxC ID CC_ID bitwidth ORAN-WG4.CUS.0-v05.00 section 3.1.3.1.6 2

transport eAxC ID RU_Port_ID bitwidth ORAN-WG4.CUS.0-v05.00 section 3.1.3.1.6 8
Plane
traffic
Plane traffic
Digital Power
Scaling
Beamforming control method ORAN-WG4.CUS.0-v05.00 section 5.4, Annex J RT Weights (Frequency Domain)
Beamforming
Entry 1 : Fixed Point, 12-bit
BFW IQ ORAN-WG4.CUS.0-v05.00 section 5.4, Annex J
Entry 2 : BFP, 9-bit
U-Plane data compression method ORAN-WG4.CUS.0-v05.00 section 6, Annex A DL : Mod COMP, UL : BFP
DL: Mod COMP, 4 bits (max) + BFP,
U-Plane (DL/UL) data IQ bitwidth ORAN-WG4.CUS.0-v05.00 section 6, Annex D 9bits (only for sync signals)
IQ compression
UL: BFP, 9 bits
udCompHdr field
______________________________________________________________________________________________________________________________________________

preamble repetition
weights)
attributes)
C-Plane indications)
params)
compression additional scaling ORAN-WG4.CUS.0-v05.00 section 5.4.6 TRUE
parameters)
PRB allocation)
designation)
factor)
Sharing parameters)
grouping)
weights)
______________________________________________________________________________________________________________________________________________

S-Plane
Entry 1) lls-C1 (can also apply lls-C2)
ORAN-WG4.CUS.0-v05.00 section 9.2.2 Entry 2) lls-C1 (PLFS not required by
Topology configuration
ORAN-WG4.CUS.0-v05.00 section 8, 9.2.3 (for PLFS) O-RU)
Entry 3) lls-C3
1
2 A.2.1.6 NR TDD IOT M-MIMO Profile 3 - NR-TDD-FR1-CAT-B-mMIMO-ChInfo-BFP

7 Table A.2.1.6-1: NR TDD IOT M-MIMO Profile 3 - NR-TDD-FR1(30kHzSRS)-CAT-B-mMIMO-ChInfo-BFP

Entry1: DDDFUUDDDD
TDD configuration -
General Entry2: DDDFU
______________________________________________________________________________________________________________________________________________

Total channel bandwidth - 100MHz x 1 CC
Fronthaul Ethernet link - 25Gbps x 2 lane (16L, 1CC)
Entry3: C2
LAA - FALSE
information (based on lls-CU delay ORAN-WG4.CUS.0-v05.00 section 2.3.3.2 FALSE
profile and transport delay)
B
Delay T1a_min_cp_dl ORAN-WG4.CUS.0-v05.00 section 2.3, Annex B More than or equal to 769us
management T2a_max_up ORAN-WG4.CUS.0-v05.00 section 2.3, Annex B More than or equal to 345us
______________________________________________________________________________________________________________________________________________

B
B
B
B
Entry1: TRUE
Entry2: FALSE
C/U-Plane
transport
Plane
______________________________________________________________________________________________________________________________________________

traffic
Plane traffic
Digital Power
Scaling
Beamforming Beamforming control method ORAN-WG4.CUS.0-v05.00 section 5.4, Annex J Chan Info (Frequency Domain)
BFW IQ ORAN-WG4.CUS.0-v05.00 section 5.4, Annex J NA
U-Plane data compression method ORAN-WG4.CUS.0-v05.00 section 6, Annex A BFP
U-Plane (DL/UL) data IQ bitwidth ORAN-WG4.CUS.0-v05.00 section 6, Annex D 9
IQ compression
udCompHdr field
C-Plane C-Plane for PRACH formats with

preamble repetition
weights)
attributes)
indications)
params)
______________________________________________________________________________________________________________________________________________

compression additional scaling ORAN-WG4.CUS.0-v05.00 section 5.4.6 FALSE
parameters)
PRB allocation)
designation)
factor)
Sharing parameters)
grouping)
weights)
Section extension 16 ORAN-WG4.CUS.0-v05.00 section 5.4.7 TRUE
S-Plane
Entry 3) lls-C3
1
2 A.2.1.7 NR TDD IOT M-MIMO Profile 4 - NR-TDD-FR1-CAT-B-mMIMO-ChInfo-ModComp

______________________________________________________________________________________________________________________________________________
4 Table A.2.1.7-1: NR TDD IOT M-MIMO Profile 4 - NR-TDD-FR1-CAT-B-mMIMO-ChInfo-ModComp

Entry1: DDDFUUDDDD
TDD configuration -
Entry2: DDDFU
Entry1: 100MHz x 1 CC
Entry2: 100 MHz x 2 CC
General
Entry3: C2
LAA - FALSE
information (based on lls-CU delay ORAN-WG4.CUS.0-v05.00 section 2.3.3.2 FALSE
Delay
profile and transport delay)
management
B
______________________________________________________________________________________________________________________________________________

T2a_max_up ORAN-WG4.CUS.0-v05.00 section 2.3, Annex B More than or equal to 345us
B
B
B
B
______________________________________________________________________________________________________________________________________________

Entry1: TRUE
Entry2: FALSE

Plane
traffic
Plane traffic
Digital Power
Scaling
Beamforming Beamforming control method ORAN-WG4.CUS.0-v05.00 section 5.4, Annex J Chan Info (Frequency Domain)
BFW IQ ORAN-WG4.CUS.0-v05.00 section 5.4, Annex J NA
U-Plane data compression method ORAN-WG4.CUS.0-v05.00 section 6, Annex A DL : Mod COMP, UL : BFP
DL: Mod COMP, 4 bits (max) + BFP,
U-Plane (DL/UL) data IQ bitwidth ORAN-WG4.CUS.0-v05.00 section 6, Annex D 9bits (only for sync signals)
IQ compression
UL: BFP, 9 bits
udCompHdr field
C-Plane
______________________________________________________________________________________________________________________________________________

preamble repetition
weights)
attributes)
indications)
params)
compression additional scaling ORAN-WG4.CUS.0-v05.00 section 5.4.6 TRUE
parameters)
PRB allocation)
designation)
factor)
Sharing parameters)
grouping)
weights)
______________________________________________________________________________________________________________________________________________

S-Plane
Entry 3) lls-C3
1
2 A.2.2 NR FDD
3 A.2.2.1 NR FDD IOT Profile 1 - NR-FDD-FR1(15kHzSCS)-CAT-B-DBF

5 • NR-FDD-FR1(15kHzSCS)-CAT-B-DBF_[20MHz-8SS-PRACH0-9bitIQ-llsC2]
10 • NR-FDD-FR1(15kHzSCS)-CAT-B-DBF_[20MHz-8SS-PRACHC2-9bitIQ-llsC2]
______________________________________________________________________________________________________________________________________________
11
12 Table A2.2.1-1: NR FDD IOT Profile 1 - NR-FDD-FR1(15kHzSCS)-CAT-B-DBF

Category Item
and section
Radio access technology - NR FDD
TDD configuration - NA
General Entry1: 20MHz
Entry2: 20MHz+10MHz
Entry1: 8
Entry2: 16
25Gbps x 1lane for 8 spatial streams,
25Gbps x 2lane for 16 spatial streams
______________________________________________________________________________________________________________________________________________

Category Item
and section
Entry1: 0
PRACH preamble format -
Entry2: C2
LAA - FALSE
delay)
2.3.5, Annex B
Annex B
Annex B
Annex B
Annex B
Delay ORAN-WG4.CUS.0-v05.00 section 2.3.2,
management Tcp_adv_dl 125 us
Annex B
Annex B
Annex B
Annex B
Annex B
2.3.3, Annex B
2.3.3, Annex B
2.3.3, Annex B
______________________________________________________________________________________________________________________________________________

Category Item
and section
2.3.3, Annex B
T12_max 160 us
Annex B
T12_min 0 us
Annex B
T34_max 160 us
Annex B
T34_min 0 us
Annex B
3.1.2
Plane
traffic
Plane traffic
Digital Power
Scaling
Beamforming RU beamforming type ORAN-WG4.CUS.0-v05.00 section 2.1 Digital beamforming
______________________________________________________________________________________________________________________________________________

Category Item
and section
Annex J
A
ORAN-WG4.CUS.0-v05.00 section 6, Annex Entry1: 9
IQ compression U-Plane data IQ bitwidth
D Entry2: 12
udCompHdr field
C-Plane "symInc" flag ORAN-WG4.CUS.0-v05.00 section 5.4.5.3 FALSE (always set to '0')
repetition
S-Plane ORAN-WG4.CUS.0-v05.00 section 9, Annex
SyncE TRUE
H
Entry1: lls-C2
Entry2: lls-C3
1
______________________________________________________________________________________________________________________________________________
1 A.2.2.2 NR FDD IOT Profile 2 - NR-FDD-FR1-CAT-B-DBF

3 • NR-FDD-FR1-CAT-B-DBF_[20MHz-8SS-9bitIQ-llsC2]
12
13 Table A. 2.2.2-1: NR FDD IOT Profile 2 - NR-FDD-FR1-CAT-B-DBF

Category Item
and section
General Nominal FFT size - 1024
Entry1: 20MHz
Entry2: 20MHz+10MHz
Entry1: 8
Entry2: 16
______________________________________________________________________________________________________________________________________________

Category Item
and section
PRACH preamble format - 0
LAA - FALSE
delay)
2.3.5, Annex B
Annex B
Annex B
Annex B
Annex B
Delay ORAN-WG4.CUS.0-v05.00 section 2.3.2,
management Tcp_adv_dl 125 us
Annex B
Annex B
Annex B
Annex B
Annex B
2.3.3, Annex B
2.3.3, Annex B
2.3.3, Annex B
______________________________________________________________________________________________________________________________________________

Category Item
and section
2.3.3, Annex B
T12_max 160 us
Annex B
T12_min 0 us
Annex B
T34_max 160 us
Annex B
T34_min 0 us
Annex B
3.1.2
Plane
traffic
Plane traffic
Digital Power
Scaling
Beamforming RU beamforming type ORAN-WG4.CUS.0-v05.00 section 2.1 Digital beamforming
______________________________________________________________________________________________________________________________________________

Category Item
and section
Annex J
A
D Entry2: 12
udCompHdr field
repetition
SyncE TRUE
H
Entry1: lls-C2
Entry2: lls-C3
1
______________________________________________________________________________________________________________________________________________
1 A.2.2.3 NR FDD IOT Profile 3 - NR-FDD-FR1-CAT-A-NoBF

3 • NR-FDD-FR1-CAT-A-NoBF_[20MHz-9bitIQ-llsC2]
8 Table A2.2.3-1: NR FDD IOT Profile 3 - NR-FDD-FR1-CAT-A-NoBF

Category Item
and section
Entry1: 20MHz
General Total channel bandwidth -
Entry2: 20MHz+10MHz
Fronthaul Ethernet link - 10Gbps x 1 lane
LAA - FALSE
Delay (based on O-DU delay profile and transport ORAN-WG4.CUS.0-v05.00 section 2.3.3.2 FALSE
management delay)
2.3.5, Annex B
______________________________________________________________________________________________________________________________________________

Category Item
and section
Annex B
Annex B
Annex B
Annex B
Tcp_adv_dl 125 us
Annex B
Annex B
Annex B
Annex B
Annex B
2.3.3, Annex B
2.3.3, Annex B
2.3.3, Annex B
2.3.3, Annex B
T12_max 160 us
Annex B
T12_min 0 us
Annex B
T34_max 160 us
Annex B
T34_min 0 us
Annex B
______________________________________________________________________________________________________________________________________________

Category Item
and section
3.1.2
Plane
traffic
Plane traffic
Digital Power
Scaling
Beamforming ORAN-WG4.CUS.0-v05.00 section 5.4,
Annex J
A
D Entry2: 12
udCompHdr field
______________________________________________________________________________________________________________________________________________

Category Item
and section
repetition
SyncE TRUE
H
Entry1: lls-C2
Entry2: lls-C3
1
2 A.2.2.4 NR FDD IOT Profile 4 - NR-FDD-FR1(15kHzSCS)-CAT-A-NoBF

4 • NR-FDD-FR1(15kHzSCS)-CAT-A-NoBF_[10MHz-4SS-9bitIQ-llsC2]
______________________________________________________________________________________________________________________________________________
10
15
16 Table A2.2.4-1: NR FDD IOT Profile 4 - NR-FDD-FR1(15kHzSCS)-CAT-A-NoBF

Category Item
and section
General Nominal sub-carrier spacing - 15 kHz
Nominal FFT size - 1024 for 10MHz BW, 2048 for 20MHz BW
______________________________________________________________________________________________________________________________________________

Category Item
and section
Entry1: 10MHz
Entry2: 20MHz
Entry1: 4
Entry2: 2
Fronthaul Ethernet link - 10Gbps x 1 lane
LAA - FALSE
delay)
2.3.5, Annex B
Annex B
Annex B
Annex B
Delay ORAN-WG4.CUS.0-v05.00 section 2.3,
management T2a_min_up Less than or equal to 206us
Annex B
Tcp_adv_dl 125 us
Annex B
Annex B
Annex B
Annex B
Annex B
2.3.3, Annex B
______________________________________________________________________________________________________________________________________________

Category Item
and section
2.3.3, Annex B
2.3.3, Annex B
2.3.3, Annex B
T12_max 160 us
Annex B
T12_min 0 us
Annex B
T34_max 160 us
Annex B
T34_min 0 us
Annex B
3.1.2
Plane
traffic
Plane traffic
______________________________________________________________________________________________________________________________________________

Category Item
and section
Digital Power
Scaling
Annex J
A
D Entry2: 12
udCompHdr field
repetition
S-Plane GNSS based sync ORAN-WG4.CUS.0-v05.00 section 3.2.3, 9 FALSE
SyncE TRUE
H
______________________________________________________________________________________________________________________________________________

Category Item
and section
Entry1: lls-C2
Entry2: lls-C3
1
2 A.2.3 LTE FDD
3 A.2.3.1 LTE FDD IOT Profile 1 - LTE-FDD-FR1-CAT-B-DBF

5 • LTE-FDD-FR1-CAT-B-DBF_[20MHz-8SS-9bitIQ-llsC2]
14
15 Table A.2.3.1-1: LTE FDD IOT Profile 1 - LTE-FDD-FR1-CAT-B-DBF

Category Item
and section
Radio access technology - LTE FDD
General TDD configuration - NA
______________________________________________________________________________________________________________________________________________

Category Item
and section
SSB sub-carrier spacing - NA
Entry1: 20MHz
Entry2: 20MHz+10MHz
Entry1: 8
Entry2: 16
LAA - FALSE
delay)
2.3.5, Annex B
Annex B
Annex B
management T2a_max_up More than or equal to 437us
Annex B
Annex B
Tcp_adv_dl 125 us
Annex B
Annex B
Annex B
Annex B
______________________________________________________________________________________________________________________________________________

Category Item
and section
Annex B
2.3.3, Annex B
2.3.3, Annex B
2.3.3, Annex B
2.3.3, Annex B
T12_max 160 us
Annex B
T12_min 0 us
Annex B
T34_max 160 us
Annex B
T34_min 0 us
Annex B
3.1.2
C/U-Plane
transport
Plane
______________________________________________________________________________________________________________________________________________

Category Item
and section
traffic
Plane traffic
Digital Power
Scaling
Annex J
A
D Entry2: 12
udCompHdr field
repetition
S-Plane
______________________________________________________________________________________________________________________________________________

Category Item
and section
SyncE TRUE
H
Entry1: lls-C2
Entry2: lls-C3
1
2 A.2.3.2 LTE FDD IOT Profile 2 - LTE-FDD-FR1-CAT-A-NoBF

4 • LTE-FDD-FR1-CAT-A-NoBF_[10MHz-2SS-9bitIQ-llsC1C2]
9 • LTE-FDD-FR1-CAT-A-NoBF_[10MHz-4SS-9bitIQ-llsC3]
13
______________________________________________________________________________________________________________________________________________
4 • LTE-FDD-FR1-CAT-A-NoBF_[20MHz-4SS-12bitIQ-llsC1C2-Jumbo]
5 • LTE-FDD-FR1-CAT-A-NoBF_[20MHz-2SS-12bitIQ-llsC3-Jumbo]
10 • LTE-FDD-FR1-CAT-A-NoBF_[60MHz-4SS-16bitIQ-llsC1C2-Jumbo]
11
12 Table A.2.3.2-1: LTE FDD IOT Profile 2 - LTE-FDD-FR1-CAT-A-NoBF

Category Item
and section
Radio access technology - LTE FDD
1024 for 10MHz BW, 1536 for 15MHz BW, 2048 for
Nominal FFT size -
General 20MHz BW
Entry1: 5MHz
Entry2: 10MHz
Entry3: 15MHz
Entry4: 20MHz
Entry5: 20MHz+20MHz
Entry6: 20MHz+20MHz+20MHz
______________________________________________________________________________________________________________________________________________

Category Item
and section
Entry1: 2
Entry2: 4
Fronthaul Ethernet link - 10Gbps x 1lane

LAA - FALSE
delay)
2.3.5, Annex B
Annex B
Annex B
Annex B
management T2a_min_up Less than or equal to 206us
Annex B
Tcp_adv_dl 125 us
Annex B
Annex B
Annex B
Annex B
Annex B
2.3.3, Annex B
______________________________________________________________________________________________________________________________________________

Category Item
and section
2.3.3, Annex B
2.3.3, Annex B
2.3.3, Annex B
T12_max 160 us
Annex B
T12_min 0 us
Annex B
T34_max 160 us
Annex B
T34_min 0 us
Annex B
3.1.2
Entry1: FALSE
Entry2: TRUE
transport
Plane
traffic
Plane traffic
______________________________________________________________________________________________________________________________________________

Category Item
and section
Digital Power
Scaling
Annex J
ORAN-WG4.CUS.0-v05.00 section 6, Annex Entry1: Block floating point
U-Plane data compression method
A Entry2: No compression
For Block floating point:
IQ compression ORAN-WG4.CUS.0-v05.00 section 6, Annex Entry1: 9
U-Plane data IQ bitwidth
D Entry2: 12
For No compression: 16
udCompHdr field
repetition
S-Plane G.8275.2 ORAN-WG4.CUS.0-v05.00 section 3.2.3, 9 FALSE
______________________________________________________________________________________________________________________________________________

Category Item
and section
SyncE TRUE
H
Entry2: lls-C3
1
2 A.2.4 LTE TDD
3 A.2.4.1 LTE TDD IOT Profile 1 - LTE-TDD-FR1-CAT-A-DBF

5 • LTE-TDD-FR1-CAT-A-DBF_[20MHz-9bitIQ-llsC2]
12
16
______________________________________________________________________________________________________________________________________________
______________________________________________________________________________________________________________________________________________
1 Table A.2.4.1-1: LTE TDD IOT Profile 1 - LTE-TDD-FR1-CAT-A-DBF

Category Item
and section
Radio access technology - LTE TDD
TDD configuration - subframeAssignment sa2
Nominal FFT size - 1024 for 10MHz BW, 2048 for 20MHz BW
Entry1: 20MHz
Total channel bandwidth - Entry2: 20MHz+10MHz
General Entry3: 20MHz+20MHz
8
10Gbps x 1 lane for 20MHz

10Gbps x 2 lane for 20MHz+10MHz, 20MHz+20MHz
LAA - FALSE
RU adaptation of delay profile information FALSE
(based on O-DU delay profile and transport ORAN-WG4.CUS.0-v05.00 section 2.3.3.2
delay)
ORAN-WG4.CUS.0-v05.00 section 2.3.4- Fixed Timing Advance
O-DU timing advance type
2.3.5, Annex B
ORAN-WG4.CUS.0-v05.00 section 2.3, Less than or equal to 437us
Delay T1a_max_up
Annex B
management ORAN-WG4.CUS.0-v05.00 section 2.3, More than or equal to 366us
T1a_min_up
Annex B
ORAN-WG4.CUS.0-v05.00 section 2.3, More than or equal to 437us
T2a_max_up
Annex B
T2a_min_up
Annex B
ORAN-WG4.CUS.0-v05.00 section 2.3.2, 125 us
Tcp_adv_dl
Annex B
______________________________________________________________________________________________________________________________________________

Category Item
and section
Ta3_max_up
Annex B
Ta3_min_up
Annex B
Ta4_max_up
Annex B
Ta4_min_up
Annex B
ORAN-WG4.CUS.0-v05.00 section 2.3.2- Less than or equal to 356us
T1a_max_cp_ul
2.3.3, Annex B
ORAN-WG4.CUS.0-v05.00 section 2.3.2- More than or equal to 285us
T1a_min_cp_ul
2.3.3, Annex B
ORAN-WG4.CUS.0-v05.00 section 2.3.2- More than or equal to 356us
T2a_max_cp_ul
2.3.3, Annex B
ORAN-WG4.CUS.0-v05.00 section 2.3.2- Less than or equal to 125us
T2a_min_cp_ul
2.3.3, Annex B
ORAN-WG4.CUS.0-v05.00 section 2.3, 160 us
T12_max
Annex B
T12_min
Annex B
T34_max
Annex B
T34_min
Annex B
ORAN-WG4.CUS.0-v05.00 section 3.1.1- Ethernet
Transport encapsulation
3.1.2
C/U-Plane eCPRI concatenation ORAN-WG4.CUS.0-v05.00 section 3.1.3.1 FALSE
transport 4
______________________________________________________________________________________________________________________________________________

Category Item
and section
Transport prioritization across C/U/S/M- Default L2 CoS priority
ORAN-WG4.CUS.0-v05.00 section 3.3
Plane
Transport prioritization within U-Plane ORAN-WG4.CUS.0-v05.00 section 3.3 False (Default U-Plane priority applies)-Plane
Separation of C/U-Plane and M-Plane VLAN ID
traffic
Transport-based separation within C/U- FALSE
Plane traffic
Digital Power 0dB
UL gain_correction ORAN-WG4.CUS.0-v05.00 section 6.1.3.2
Scaling
Beamforming ORAN-WG4.CUS.0-v05.00 section 5.4, Beamforming weight based
Beamforming control method
Annex J
ORAN-WG4.CUS.0-v05.00 section 6, Annex Entry1: Block floating point
U-Plane data compression method
A Entry2: No compression
ORAN-WG4.CUS.0-v05.00 section 6, Annex 9 for Block floating point, 16 for No compression
D
IQ data frame format not including TRUE
ORAN-WG4.CUS.0-v05.00 section 6.3.3.13
udCompHdr field
C-Plane
C-Plane for PRACH formats with preamble Single C-Plane message
ORAN-WG4.CUS.0-v05.00 section 5.3.2
repetition
______________________________________________________________________________________________________________________________________________

Category Item
and section
ORAN-WG4.CUS.0-v05.00CUS.0-v05.00 FALSE
Section extension 4
section 5.4.6
S-Plane
ORAN-WG4.CUS.0-v05.00 section 9, Annex TRUE
SyncE
H
Entry1: lls-C2
Entry2: lls-C3
______________________________________________________________________________________________________________________________________________
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.
40 2.2 Adopter shall not use O-RAN Specifications except as expressly set forth in this Agreement or in a separate written
41 agreement with O-RAN Alliance.
42 Section 3: FRAND LICENSE

43 3.1 Members, Contributors and Academic Contributors and their Affiliates are prepared to grant based on a separate
44 Patent License Agreement to each Adopter under Fair Reasonable And Non- Discriminatory (FRAND) terms and
45 conditions with or without compensation (royalties) a nonexclusive, non-transferable, irrevocable (but subject to
46 Defensive Suspension), non-sublicensable, worldwide patent license under their Necessary Claims to make, have made,
47 use, import, offer to sell, lease, sell and otherwise distribute Compliant Implementations; provided, however, that such
________________________________________________________________________________________________
1 license shall not extend: (a) to any part or function of a product in which a Compliant Implementation is incorporated
2 that is not itself part of the Compliant Implementation; or (b) to any Adopter if that Adopter is not making a reciprocal
3 grant to Members, Contributors and Academic Contributors, as set forth in Section 3.3. For the avoidance of doubt, the
4 foregoing licensing commitment includes the distribution by the Adopter’s distributors and the use by the Adopter’s
5 customers of such licensed Compliant Implementations.
6 3.2 Notwithstanding the above, if any Member, Contributor or Academic Contributor, Adopter or their Affiliates has
7 reserved the right to charge a FRAND royalty or other fee for its license of Necessary Claims to Adopter, then Adopter
8 is entitled to charge a FRAND royalty or other fee to such Member, Contributor or Academic Contributor, Adopter and
9 its Affiliates for its license of Necessary Claims to its licensees.
10 3.3 Adopter, on behalf of itself and its Affiliates, shall be prepared to grant based on a separate Patent License
11 Agreement to each Members, Contributors, Academic Contributors, Adopters and their Affiliates under Fair
12 Reasonable And Non-Discriminatory (FRAND) terms and conditions with or without compensation (royalties) a
13 nonexclusive, non-transferable, irrevocable (but subject to Defensive Suspension), non-sublicensable, worldwide patent
14 license under their Necessary Claims to make, have made, use, import, offer to sell, lease, sell and otherwise distribute
15 Compliant Implementations; provided, however, that such license will not extend: (a) to any part or function of a
16 product in which a Compliant Implementation is incorporated that is not itself part of the Compliant Implementation; or
17 (b) to any Members, Contributors, Academic Contributors, Adopters and their Affiliates that is not making a reciprocal
18 grant to Adopter, as set forth in Section 3.1. For the avoidance of doubt, the foregoing licensing commitment includes
19 the distribution by the Members’, Contributors’, Academic Contributors’, Adopters’ and their Affiliates’ distributors
20 and the use by the Members’, Contributors’, Academic Contributors’, Adopters’ and their Affiliates’ customers of such
21 licensed Compliant Implementations.
22 Section 4: TERM AND TERMINATION

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

2 EXCEPT FOR BREACH OF CONFIDENTIALITY, ADOPTER’S BREACH OF SECTION 3, AND ADOPTER’S
3 INDEMNIFICATION OBLIGATIONS, IN NO EVENT SHALL ANY PARTY BE LIABLE TO ANY OTHER
4 PARTY OR THIRD PARTY FOR ANY INDIRECT, SPECIAL, INCIDENTAL, PUNITIVE OR CONSEQUENTIAL
5 DAMAGES RESULTING FROM ITS PERFORMANCE OR NON-PERFORMANCE UNDER THIS AGREEMENT,
6 IN EACH CASE WHETHER UNDER CONTRACT, TORT, WARRANTY, OR OTHERWISE, AND WHETHER OR
7 NOT SUCH PARTY HAD ADVANCE NOTICE OF THE POSSIBILITY OF SUCH DAMAGES. O-RAN
8 SPECIFICATIONS ARE PROVIDED “AS IS” WITH NO WARRANTIES OR CONDITIONS WHATSOEVER,
9 WHETHER EXPRESS, IMPLIED, STATUTORY, OR OTHERWISE. THE O-RAN ALLIANCE AND THE
10 MEMBERS, CONTRIBUTORS OR ACADEMIC CONTRIBUTORS EXPRESSLY DISCLAIM ANY WARRANTY
11 OR CONDITION OF MERCHANTABILITY, SECURITY, SATISFACTORY QUALITY, NONINFRINGEMENT,
12 FITNESS FOR ANY PARTICULAR PURPOSE, ERROR-FREE OPERATION, OR ANY WARRANTY OR
13 CONDITION FOR O-RAN SPECIFICATIONS.
14 Section 8: ASSIGNMENT
15 Adopter may not assign the Agreement or any of its rights or obligations under this Agreement or make any grants or
16 other sublicenses to this Agreement, except as expressly authorized hereunder, without having first received the prior,
17 written consent of the O-RAN Alliance, which consent may be withheld in O-RAN Alliance’s sole discretion. O-RAN
18 Alliance may freely assign this Agreement.
19 Section 9: THIRD-PARTY BENEFICIARY RIGHTS

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

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

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

O-RAN WG4 IOT 0-v04 00

Uploaded by

Copyright:

Available Formats

O-RAN WG4 IOT 0-v04 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 WG4 IOT 0-v04 00

Uploaded by

Copyright:

Available Formats

O-RAN.WG4.IOT.0-v04.

O-RAN Fronthaul Working Group

Fronthaul Interoperability Test Specification (IOT)

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

O-RAN ALLIANCE e.V.

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

2020.11.5 03.00 Implement change requests

2021.03.10 04.00 Rename Profiles as Profile Test Configurations NOK-0052

M-Plane correction NEC-0009 rev1

M-Plane system recovery action for S-Plane degraded conditions NEC-0010

Update eaxc_id to align with M-Plane and CUS-Plane description

Include mMIMO IOT profile and associated test equipment update

mMIMO Profile Test Configurations and FFS

1 2.2.4.1 Test environment .................................................................................................................................. 47

1 Chapter 1 Introductory Material

30 1.2.2 Summary of Test Scenarios

32 • FH tests focused on the M-Plane:

34 • FH tests focused on the S-Plane:

35 o Synchronization status detection

36 o Frequency and time error (performance)

37 • FH tests focused on the C/U-Planes:

1 o Radio downlink U-Plane data transfer (Downlink throughput performance)

2 o Radio uplink U-Plane data transfer (Uplink throughput performance)

3 • FH tests focused on the C/U-Plane Delay Management

4 o Test with minimum, intermediate, maximum, and excess latency.

5 1.2.3 Future Enhancements

8 • FH tests focused on the M-Plane:

9 o Software management (O-RU software update)

12 • FH tests focused on the C/U-Plane:

13 o Beamforming (testing the actual characteristics of the radiated/received signals at O-RU)

30 1.4 Definitions and Abbreviations

27 1.5.2 Fronthaul M-Plane Architectural options

35 1.5.3 Fronthaul Synchronization options

40 1. Direct connection between O-DU and O-RU:

41 LLS-C1 is generally the main sync option to be validated

42 LLS-C4 may be considered as an alternative or as a complement to LLS-C1

43 2. Bridged network between O-DU and O-RU

7 LLS-C4 may be considered as alternative or as a complement to LLS-C2/LLS-C3. LLS-C4 is considered for

1 Chapter 2 Interoperability Measurements

2 2.1 Interoperability Standard Test Definitions

7 2.1.1.1 Device Under Test (DUT)

1 2.1.1.2 Network Management System (NMS)

9 2.1.1.3 Testing Tools

21 Active stimulus testing tools

26 Passive monitoring and measurements testing tools

10 o Stateful traffic, eg. TCP, TWAMP

11 o Stateless traffic eg. UDP

12 o Required to place traffic load on the DUT

16 o UE logging tools which are connected to the Test UEs

18 o External dashboard and reporting applications

36 • O-CU or O-CU emulator

37 • MeNB or MeNB emulator

38 • Core or Core emulator

3 2.1.1.4 Time Synchronization

17 2.1.1.6 Specifications to be used for testing

21 o Control, User and Synchronization Plane Specification [2]

22 o Management Plane Specification [3]

23 o Management Plane Yang Models [4]

6 o Release 15 December 2018 and later versions specifications