ORAN-WG5.MP.0-v01.00: O-RAN Alliance Working Group 5 O1 Interface Specification For O-DU

ORAN-WG5.MP.0-v01.
00
Technical Specification
1
O-RAN Alliance Working Group 5
O1 Interface specification for O-DU
Prepared by the O-RAN Alliance. Copyright © 2020 by the O-RAN Alliance.

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

Your use is subject to the terms of the O-RAN Adopter License Agreement in Annex ZZZ 1
ORAN-WG5.MP.0-v01.00
1 Revision History
Date Revision Author Description
2020.09.25 01.00 O-RAN-WG5 First published version based on contributions and review by
O-RAN members
2

1 Contents
2 Revision History ................................................................................................................................................. 2
3 Contents .............................................................................................................................................................. 3
4 List of Figures..................................................................................................................................................... 8
5 List of Tables ...................................................................................................................................................... 8
6 Chapter 1 Introductory Material ......................................................................................................................... 9
7 1.1 Scope 9
8 1.2 References .................................................................................................................................................................... 9
9 1.3 Definitions and Abbreviations .................................................................................................................................... 10
10 1.3.1 Definitions ............................................................................................................................................................... 10
11 1.3.2 Abbreviations ........................................................................................................................................................... 11
12 1.4 Conventions ................................................................................................................................................................ 12
13 1.5 Topics for Future Specification Versions ................................................................................................................... 12
14 Chapter 2 High Level Description .................................................................................................................... 13
15 2.1 Top level functional description, terminology, including hybrid, hierarchical ........................................................... 13
16 2.1.1 Architecture for O-RAN WG5 functional split........................................................................................................ 13
17 2.1.2 O1 interface for O-DU architecture model .............................................................................................................. 13
18 2.1.3 Transport Network ................................................................................................................................................... 13
19 2.2 Interfaces .................................................................................................................................................................... 14
20 2.3 YANG Module Introduction ....................................................................................................................................... 14
21 Chapter 3 Startup and Registration Management ............................................................................................. 16
22 3.1 O1 Interface Transport aspects ................................................................................................................................... 18
23 3.1.1 O-DU identification in DHCP ................................................................................................................................. 20
24 3.1.2 Management Plane VLAN Discovery Aspects ........................................................................................................ 20
25 3.1.3 O-DU IP Address Assignment used for O1 signalling ............................................................................................ 21
26 3.1.4 NETCONF Client Discovery ................................................................................................................................... 21
27 3.1.5 CA/RA Discovery .................................................................................................................................................... 21
28 3.1.6 SMO/MnS Consumer Discovery ............................................................................................................................. 22
29 3.2 Certificate Enrolment.................................................................................................................................................. 22
30 3.3 PNF Registration ........................................................................................................................................................ 23
31 3.3.1 Monitoring SMO/MnS Consumer Connectivity ...................................................................................................... 23
32 3.4 NETCONF Connection Establishment ....................................................................................................................... 24
33 3.4.1 NETCONF Security ................................................................................................................................................. 24
34 3.4.2 NETCONF Authentication ...................................................................................................................................... 24
35 3.4.3 User Account Provisioning ...................................................................................................................................... 24
36 3.5 NETCONF Access Control ........................................................................................................................................ 24
37 3.6 NETCONF Protocol Aspects ...................................................................................................................................... 25
38 3.6.1 NETCONF Capability Discovery ............................................................................................................................ 25
39 3.6.2 Framework for optional feature handling ................................................................................................................ 25
40 3.6.3 Closing a NETCONF Session .................................................................................................................................. 26
41 Chapter 4 Heartbeat Management Services...................................................................................................... 26
42 4.1 Heartbeat Notification................................................................................................................................................. 26
43 4.2 Heartbeat Control........................................................................................................................................................ 26
44 Chapter 5 PNF Software Management ............................................................................................................. 26
45 5.1 O-DU Software Management ..................................................................................................................................... 26
46 5.2 O-RU Software Management ..................................................................................................................................... 26
47 5.2.1 Hierarchical Model .................................................................................................................................................. 26
48 5.2.2 Hybrid Model........................................................................................................................................................... 31
49 Chapter 6 Performance Assurance Management .............................................................................................. 31
50 6.1 Performance Data File Reporting ............................................................................................................................... 31
51 6.1.1 PM File Content ....................................................................................................................................................... 31
52 6.1.2 PM File Naming ...................................................................................................................................................... 31
53 6.1.3 PM File XML Format .............................................................................................................................................. 31

1 6.2 Performance Data Streaming ...................................................................................................................................... 31

2 6.3 Performance Assurance Control ................................................................................................................................. 31
3 6.3.1 Performance Assurance Control for O-RU performance counters .......................................................................... 32
4 Chapter 7 Fault Supervision Management ....................................................................................................... 32
5 7.1 General........................................................................................................................................................................ 32
6 7.2 Definition of the Operations for Fault Events ............................................................................................................. 32
7 7.2.1 Request for getAlarmList......................................................................................................................................... 33
8 7.2.2 Request for clearAlarms .......................................................................................................................................... 33
9 7.2.3 Request for acknowledgeAlarms ............................................................................................................................. 33
10 7.3 Definition of Notifications as Fault Events................................................................................................................. 33
11 7.3.1 Notification notifyNewAlarm .................................................................................................................................. 33
12 7.3.2 Notification notifyChangedAlarm ........................................................................................................................... 33
13 7.3.3 Notification notifyClearedAlarm ............................................................................................................................. 33
14 7.4 Message Format for Fault Events ............................................................................................................................... 33
15 7.5 O-RU Alarms Management by O-DU in Hierarchical Model .................................................................................... 33
16 Chapter 8 File Management ............................................................................................................................. 35
17 8.1 File Structure .............................................................................................................................................................. 35
18 8.2 Notification notifyFileReady ...................................................................................................................................... 36
19 8.3 File Management Operation: listAvailableFiles ......................................................................................................... 36
20 8.4 File Management Operation: retriveveFileList ........................................................................................................... 37
21 8.5 File Management Operation: transferFile ................................................................................................................... 38
22 8.6 File Management Operation: downloadFile ............................................................................................................... 38
23 Chapter 9 Synchronization Aspects .................................................................................................................. 38
24 9.1 Synchronization .......................................................................................................................................................... 38
25 9.1.1 Synchronization status ............................................................................................................................................. 38
26 9.1.2 Synchronization capabilities .................................................................................................................................... 39
27 9.1.3 Synchronization configuration ................................................................................................................................. 39
28 9.1.4 PTP configuration .................................................................................................................................................... 40
29 9.1.5 PTP status ................................................................................................................................................................ 40
30 9.1.6 SyncE configuration ................................................................................................................................................ 41
31 9.1.7 SyncE status ............................................................................................................................................................. 41
32 9.1.8 GNSS Configuration ................................................................................................................................................ 41
33 9.1.9 GNSS Status ............................................................................................................................................................ 42
34 9.2 Synchronization master............................................................................................................................................... 42
35 9.2.1 Synchronization master capabilities ........................................................................................................................ 42
36 9.2.2 Synchronization master configuration ..................................................................................................................... 43
37 9.2.3 Master PTP status .................................................................................................................................................... 43
38 9.3 O-DU and O-RU synchronization relation with cell and carrier activation / in-activation ......................................... 43
39 9.3.1 Cell and carrier activation ........................................................................................................................................ 43
40 9.3.2 Cell and carrier in-activation ................................................................................................................................... 44
41 Chapter 10 Provisioning Management ............................................................................................................. 44
42 10.1 Configuration for Hierarchical Model ...................................................................................................................... 44
43 10.1.1 Configuration Step ................................................................................................................................................. 44
44 10.1.2 Aggregation model for configuration to O-RU via SMO ...................................................................................... 45
45 10.2 Configuration for Hybrid model ............................................................................................................................... 47
46 10.3 Cell Activation .......................................................................................................................................................... 47
47 10.3.1 Hierarchical Model ................................................................................................................................................ 47
48 10.3.2 Hybrid Model......................................................................................................................................................... 48
49 10.4 Notification aspect in hierarchical model ................................................................................................................. 48
50 10.4.1 Subscribing for O-RU notification from SMO ...................................................................................................... 49
51 10.4.2 Forwarding the notification from O-RU via O-DU ............................................................................................... 49
52 Chapter 11 Fronthaul Delay Management Support .......................................................................................... 50
53 Annex A Counter definition ............................................................................................................................. 54
54 [Editors note: taken from “NEC-2020.06.09-WG5-ORAN-WG5.MP.0-v00.00.03-section-6-PM-v0.5.docx”] .............. 54
55 A.1 NR F1 Interface performance counters ...................................................................................................................... 54
56 A.1.1 UL PDCP PDUs transmitted via F1-U UL GTP-U tunnel...................................................................................... 54
57 A.1.2 UL PDCP PDU volume transmitted via F1-U UL GTP-U tunnel ....................................................................... 54

1 A.1.3 Maximum UL PDCP PDU volume transmitted via F1-U UL GTP-U tunnel ......................................................... 55
2 A.1.4 Minimum UL PDCP PDU volume transmitted via F1-U UL GTP-U tunnel .......................................................... 55
3 A.1.5 DL PDCP PDUs received via F1-U DL GTP-U tunnel .......................................................................................... 56
4 A.1.6 DL PDCP PDU volume received via F1-U DL GTP-U tunnel ............................................................................... 56
5 A.1.7 Maximum DL PDCP PDU volume received via F1-U DL GTP-U tunnel.............................................................. 57
6 A.1.8 Minimum DL PDCP PDU volume received via F1-U DL GTP-U tunnel .............................................................. 57
7 A.1.9 Transmitted F1-C messages .................................................................................................................................... 58
8 A.1.10 Received F1-C messages ...................................................................................................................................... 58
9 A.1.11 DL F1-U packets discarded due to NR U-Plane protocol error ............................................................................ 58
10 A.1.12 DL F1-U packet loss rate ...................................................................................................................................... 59
11 A.1.13 DL Packet Drop Rate in gNB-DU......................................................................................................................... 59
12 A.1.14 UL PDCP PDU volume transmitted via F1-U UL GTP-U tunnel ......................................................................... 60
13 A.1.15 DL PDCP PDU volume received via F1-U DL GTP-U tunnel ............................................................................. 60
14 A.2 NR RLC performance counters ................................................................................................................................. 61
15 A.2.1 Received UL RLC PDUs ........................................................................................................................................ 61
16 A.2.2 Received UL RLC PDU volume ............................................................................................................................. 61
17 A.2.3 Request for UL RLC PDUs retransmission ............................................................................................................ 61
18 A.2.4 Transmitted DL RLC PDUs .................................................................................................................................... 62
19 A.2.5 Transmitted DL RLC PDU volume ........................................................................................................................ 62
20 A.2.6 Retransmitted DL RLC PDUs................................................................................................................................. 63
21 A.2.7 Retransmitted DL RLC PDU volume ..................................................................................................................... 63
22 A.2.8 UL RLC PDUs discarded due to bearer release ...................................................................................................... 64
23 A.2.9 UL RLC PDU volume discarded due to bearer release .......................................................................................... 64
24 A.2.10 UL RLC PDUs discarded due to RLC re-establishment ....................................................................................... 65
25 A.2.11 UL RLC PDU volume discarded due to RLC re-establishment ........................................................................... 65
26 A.2.12 UL RLC PDUs discarded due to other causes ...................................................................................................... 65
27 A.2.13 UL RLC PDU volume discarded due to other causes ........................................................................................... 66
28 A.2.14 DL RLC PDUs discarded due to bearer release .................................................................................................... 66
29 A.2.15 DL RLC PDU volume discarded due to bearer release......................................................................................... 67
30 A.2.16 DL RLC PDUs discarded due to RLC re-establishment ....................................................................................... 67
31 A.2.17 DL RLC PDU volume discarded due to RLC re-establishment ........................................................................... 68
32 A.2.18 DL RLC PDUs discarded due to full buffer .......................................................................................................... 68
33 A.2.19 DL RLC PDU volume discarded due to full buffer .............................................................................................. 69
34 A.2.20 The number of exceeding maximum RLC retransmissions .................................................................................. 69
35 A.2.21 Average delay DL in gNB-DU ............................................................................................................................. 70
36 A.2.22 IP Latency DL in gNB-DU ................................................................................................................................... 70
37 A.3 NR MAC performance counters ................................................................................................................................ 71
38 A.3.1 Received UL MAC PDU volume ........................................................................................................................... 71
39 A.3.2 Transmitted DL MAC PDU volume ...................................................................................................................... 71
40 A.3.3 Average delay DL air-interface ........................................................................................................................... 72
41 A.4 NR UL HARQ performance counters ........................................................................................................................ 72
42 A.4.1 Distribution of PUSCH per MCS (initial transmission) ...................................................................................... 72
43 A.4.2 Distribution of PUSCH per MCS (initial transmission/CRC OK) ....................................................................... 73
44 A.4.3 Distribution of PUSCH per MCS (any/CRC OK) ................................................................................................. 73
45 A.4.4 Distribution of PUSCH per MCS (exceeding HARQ retransmission) .............................................................. 74
46 A.5 NR DL HARQ performance counters ........................................................................................................................ 75
47 A.5.1 Distribution of PDSCH per MCS (initial transmission) ...................................................................................... 75
48 A.5.2 Distribution of PDSCH per MCS (initial transmission/ACK) ............................................................................. 76
49 A.5.3 Distribution of PDSCH per MCS (any/ACK) ....................................................................................................... 76
50 A.5.4 Distribution of PDSCH per MCS (exceeding HARQ retransmission) .............................................................. 77
51 A.5.5 Distribution of PDSCH per MCS (MU-MIMO/initial transmission) ................................................................... 78
52 A.5.6 Distribution of PDSCH per MCS (MU-MIMO/initial transmission/ACK) .......................................................... 79
53 A.6 NR UL Signal Quality Level performance counters .................................................................................................. 79
54 A.6.1 Distribution of PUSCH per MCS (Rank1) ........................................................................................................... 79
55 A.6.2 Distribution of PUSCH per MCS (Rank2) ........................................................................................................... 80
56 A.6.3 Distribution of PUSCH per SSB beam (Rank1) ................................................................................................. 81
57 A.6.4 Distribution of PUSCH per SSB beam (Rank2) ................................................................................................. 81
58 A.6.5 PUSCH received power ........................................................................................................................................ 82
59 A.6.6 PUSCH RSSI........................................................................................................................................................... 83
60 A.6.7 PUSCH SINR .......................................................................................................................................................... 83

1 A.6.8 PUCCH RSSI .......................................................................................................................................................... 84

2 A.6.9 PUCCH SINR .......................................................................................................................................................... 85
3 A.6.10 PRACH preamble correlation value .................................................................................................................. 86
4 A.6.11 RSSI of PRACH transmission occasion ............................................................................................................. 87
5 A.6.12 Distribution of path loss for FR1 ....................................................................................................................... 87
6 A.6.13 Path loss for FR2................................................................................................................................................. 88
7 A.6.14 Detection of UL out-of-sync. ............................................................................................................................. 89
8 A.7 NR DL Signal Quality Level performance counters .................................................................................................. 89
9 A.7.1 Distribution of PDSCH per MCS (Rank1) ........................................................................................................... 89
13 A.7.5 Distribution of PDSCH per SSB beam (Rank1) ................................................................................................. 92
17 A.7.9 Distribution of Wideband CQI for FR1 ............................................................................................................... 94
18 A.7.10 Wideband CQI for FR2 ....................................................................................................................................... 94
19 A.7.11 PDCCH transmission power ............................................................................................................................... 95
20 A.8 NR Beamforming performance counters ................................................................................................................... 96
21 A.8.1 Distribution of UEs per beam index ................................................................................................................... 96
22 A.8.2 Best and Second Best Beam distribution .......................................................................................................... 97
23 A.8.3 UE reported differential L1-RSRP of second best beam ........................................................................................ 97
24 A.9 NR RACH Usage performance counters ................................................................................................................... 98
25 A.9.1 Received preambles in group A .......................................................................................................................... 98
26 A.9.2 The number of received dedicated preamble ................................................................................................... 98
27 A.9.3 Transmitted RARs for preamble in group A ...................................................................................................... 99
28 A.9.4 Transmitted RARs for dedicated preamble ....................................................................................................... 99
29 A.9.5 Failures at assignment of dedicated preamble ............................................................................................... 100
30 A.9.6 Occasions for dedicated preamble reception .................................................................................................. 100
31 A.10 NR Timing Advance performance counters .......................................................................................................... 101
32 A.10.1 Distribution of NTA value of RAR message .................................................................................................... 101
33 A.11 NR Cell Utilization performance counters (Type A) ............................................................................................. 101
34 A.11.1 Slots at which PDCCH resource shortage occurred ..................................................................................... 101
35 A.11.2 Canceled DCI due to PDCCH resource shortage .......................................................................................... 102
36 A.11.3 Maximum UEs buffering UL/DL data .............................................................................................................. 102
37 A.11.4 Maximum UEs buffering UL data .................................................................................................................... 103
38 A.11.5 Maximum UEs buffering DL data .................................................................................................................... 103
39 A.11.6 Multiplexed transmissions of PUSCH .............................................................................................................. 104
40 A.11.7 Multiplexed receptions of PDSCH ................................................................................................................... 104
41 A.11.8 Maximum DRX inactive UEs ............................................................................................................................ 105
42 A.11.9 Maximum DRX active UEs ............................................................................................................................... 105
43 A.11.10 Distribution of trafficInactivityTimer ............................................................................................................ 105
44 A.11.11 Slots in which scheduler assigned as mini slot ........................................................................................... 106
45 A.11.12 Mini slots in which PUSCH was received ..................................................................................................... 106
46 A.11.13 UEs in the cell using this cell as PSCell or having activated SCell in DL ................................................. 107
47 A.11.14 UEs in the cell using this cell as PSCell or having activated SCell in UL ................................................. 107
48 A.11.15 Distribution of PSCell UEs with X activated SCells in UL ........................................................................... 107
49 A.11.16 Distribution of PSCell UEs with X activated SCells in DL ........................................................................... 108
50 A.11.17 Maximum amount of PSCell UEs (UL).......................................................................................................... 108
51 A.11.18 Minimum amount of PSCell UEs (UL) .......................................................................................................... 109
52 A.11.19 Maximum amount of PSCell UEs (DL) ......................................................................................................... 109
53 A.11.20 Minimum amount of PSCell UEs (DL) .......................................................................................................... 110
54 A.11.21 Activation/Deactivation MAC CE (SCell Active) ........................................................................................... 110
55 A.11.22 Activation/Deactivation MAC CE (SCell Deactive) ...................................................................................... 111
56 A.11.23 Distribution of DL Total PRB Usage ............................................................................................................. 111
57 A.11.24 Distribution of UL Total PRB Usage.............................................................................................................. 112
58 A.11.25 Average DL Cell throughput .......................................................................................................................... 113

1 A.11.26 Average UL Cell throughput .......................................................................................................................... 113

2 A.11.27 Average DL Beam throughput ...................................................................................................................... 113
3 A.11.28 Average UL Beam throughput ...................................................................................................................... 114
4 A.11.29 Average DL active DRB .................................................................................................................................. 115
5 A.11.30 Maximum DL active DRB ............................................................................................................................... 115
6 A.12 NR Cell Utilization performance counters (Type B) ............................................................................................. 115
7 A.12.1 PUSCH slots ....................................................................................................................................................... 115
8 A.12.2 PDSCH slots ....................................................................................................................................................... 116
9 A.12.3 PDCCH slots ....................................................................................................................................................... 116
10 A.12.4 CCE utilization rate ........................................................................................................................................... 116
11 A.12.5 UEs buffering UL/DL data ................................................................................................................................ 117
12 A.12.6 UEs buffering UL data ...................................................................................................................................... 117
13 A.12.7 UEs buffering DL data ...................................................................................................................................... 118
14 A.12.8 DRX inactive UEs .............................................................................................................................................. 118
15 A.12.9 DRX active UEs ................................................................................................................................................. 119
16 A.13 O-RU Performance counters measured at O-DU ................................................................................................... 119
17 A.13.1 Uplink data and control frames received in total ......................................................................................... 119
18 A.13.2 Uplink data frames received on Time ............................................................................................................ 119
19 A.13.3 Uplink data frames received too early ........................................................................................................... 120
20 A.13.4 Uplink data frames received too late ............................................................................................................. 120
21 A.13.5 Uplink control frames received on Time ........................................................................................................ 120
22 A.13.6 Uplink control frames received too early....................................................................................................... 121
23 A.13.7 Uplink control frames received too late ......................................................................................................... 121
24 A.13.8 Uplink data frames with detecting sequence identifier error ..................................................................... 122
25 A.13.9 Uplink control frames with detecting sequence identifier error ................................................................. 122
26 A.13.10 Uplink frames with corrupt contents ............................................................................................................ 122
27 A.13.11 Uplink frames dropped and discarded. ........................................................................................................ 123
28 A.13.12 Downlink control and data frames transmitted .......................................................................................... 123
29 A.13.13 Downlink control frames transmitted to O-RU in total at O-DU .............................................................. 124
30 A.14 O-RU Performance counters measured at O-RU ................................................................................................... 124
31 Annex B Optional Multi-Vendor Functionality ............................................................................................. 124
32 B.1: Optional Namespace Exposed Using O-RAN WG5 Models .................................................................................. 124
33 B.2: Optional Namespace Exposed Using O-RAN WG4 Models .................................................................................. 124
34 B.3: Optional YANG Features Exposed Using O-RAN WG5 Models .......................................................................... 125
35 B.4: Optional YANG Features Exposed Using O-RAN WG4 Models .......................................................................... 125
36 B.5: Optional YANG Features Exposed Using Common Models .................................................................................. 126
37 B.6: Optional Capabilities Exposed Using O-RAN WG5 Models ................................................................................. 126
38 B.7: Optional Capabilities Exposed Using O-RAN WG4 Models ................................................................................. 127
39 B.8: Optional Capabilities Exposed Using Common Models ......................................................................................... 129
40 Annex C YANG Module Graphical Representation ...................................................................................... 129
41 C.1 Additional configuration folder ................................................................................................................................ 129
42 C.2 Common Models folder ........................................................................................................................................... 129
43 C.2.1 o-ran-dhcp.yang Module ....................................................................................................................................... 129
44 C.2.2 o-ran-synchronization.yang Module ..................................................................................................................... 130
45 C.2.3 o-ran-wg5-delay-management Module ................................................................................................................. 131
46 C.3 DU Specific Models folder ...................................................................................................................................... 132
47 C.3.1 o-ran-aggregation-base.yang Module.................................................................................................................... 132
48 C.4 Provisioning folder ................................................................................................................................................... 132
49 Annex D WG4 instance categories in Hierarchical Model ............................................................................ 132
50 Annex ZZZ O-RAN Adopter License Agreement ......................................................................................... 133
51 Section 1: DEFINITIONS .............................................................................................................................................. 133
52 Section 2: COPYRIGHT LICENSE ............................................................................................................................... 134
53 Section 3: FRAND LICENSE ........................................................................................................................................ 134
54 Section 4: TERM AND TERMINATION ...................................................................................................................... 134
55 Section 5: CONFIDENTIALITY ................................................................................................................................... 134
56 Section 6: INDEMNIFICATION ................................................................................................................................... 135
57 Section 7: LIMITATIONS ON LIABILITY; NO WARRANTY .................................................................................. 135

1 Section 8: ASSIGNMENT ............................................................................................................................................. 135

2 Section 9: THIRD-PARTY BENEFICIARY RIGHTS .................................................................................................. 135
3 Section 10: BINDING ON AFFILIATES ...................................................................................................................... 135
4 Section 11: GENERAL................................................................................................................................................... 136
5
6 List of Figures
7 Figure 1: O1 interface protocol stack................................................................................................................................ 14
8 Figure 2: Details of Configuration Data Bases (CDB) ..................................................................................................... 15
9 Figure 3: Overall of Start-Up Installation ......................................................................................................................... 18
10 Figure 4: Transport Layer Establishment for M-plane ..................................................................................................... 19
11 Figure 5: Certificate Enrolment ........................................................................................................................................ 23
12 Figure 6: Software Inventory ............................................................................................................................................ 28
13 Figure 7: Software Download ........................................................................................................................................... 29
14 Figure 8: Software Activate .............................................................................................................................................. 30
15 Figure 9: Operation to merge O-RU Alarms by O-DU..................................................................................................... 34
16 Figure 10: File Ready Notification ................................................................................................................................... 36
17 Figure 11: List Available Files ......................................................................................................................................... 37
18 Figure 12: Retrieve File List ............................................................................................................................................. 37
19 Figure 13: Allowed sync state transitions ......................................................................................................................... 39
20 Figure 14: Cell activation procedure................................................................................................................................. 48
21 Figure 15: Notification to the SMO preceded by the O-RU notification .......................................................................... 49
22 Figure 16: Notification to the SMO preceded by the O-DU <get> operation................................................................... 50
23 Figure 17: Delay Management Configuration Procedure ................................................................................................. 53
24
25 List of Tables
26 Table 1: Mapping of account groupings to O-DU module privileges ............................................................................... 25
27 Table 2: Mapping of O-RU NETCONF based fault notification to ONAP VES in ‘fault3gppFields’ ............................. 35
28 Table 3: Parameters list for Notification notifyFileReady ................................................................................................ 36
29 Table 5: Optional O-RAN WG5 Namespace .................................................................................................................. 124
30 Table 6: Optional O-RAN WG4 Namespace .................................................................................................................. 125
31 Table 7: Optional O-RAN WG5 defined feature support ............................................................................................... 125
32 Table 8: Optional O-RAN WG4 defined feature support ............................................................................................... 126
33 Table 9: Optional feature support in common models .................................................................................................... 126
34 Table 10: Optional capabilities in O-RAN WG5 defined YANG models ...................................................................... 127
35 Table 11: Optional capabilities in O-RAN WG4 defined YANG models ...................................................................... 128
36 Table 12: Optional capabilities in common YANG models ........................................................................................... 129
37 Table 13: Categories for YANG parameters .................................................................................................................. 133
38
39

1 Chapter 1 Introductory Material
2 1.1 Scope
3 This Technical Specification has been produced by the O-RAN.org.
4 The contents of the present document are subject to continuing work within O-RAN WG5 and may change following
5 formal O-RAN approval. Should the O-RAN.org modify the contents of the present document, it will be re-released by
6 O-RAN Alliance 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, i.e. 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 The present document specifies the O1 Interface specification for O-DU used over the interface linking the O-DU (O-
15 RAN Distributed Unit) with other management plane entities, that may include the O-CU (O-RAN Centralized Unit) as
16 well as Service Management and Orchestration (SMO).
17 1.2 References
18 The following documents contain provisions which, through reference in this text, constitute provisions of the present
19 document.
20 - References are either specific (identified by date of publication, edition number, version number, etc.) or
21 non-specific.
22 - For a specific reference, subsequent revisions do not apply.
23 - For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including
24 a GSM document), a non-specific reference implicitly refers to the latest version of that document.
25 [1] 3GPP TR 21.905: “Vocabulary for 3GPP Specifications”
26 [2] ORAN-WG5.C.1-v01.00 “Control Plane Specification”, O-RAN Alliance, Working Group 5
27 [3] ORAN-WG5.U.0-v01.00 “User Plane Specification”, O-RAN Alliance, Working Group 5
28 [4] ORAN-WG4.MP.0-v03.00 “Management Plane Specification”, O-RAN Alliance, Working Group
29 4
30 [5] RFC 6241, “Network Configuration Protocol (NETCONF)”, IETF, June 2011
31 [6] RFC 7950, “The YANG 1.1 Data Modeling Language”, IETF, August 2016
32 [7] RFC 6187, “X.509v3 Certificates for Secure Shell Authentication”, IETF, March 2011
33 [8] RFC 4361, Node-specific Client Identifiers for Dynamic Host Configuration Protocol Version Four
34 (DHCPv4), IETF, February 2006
35 [9] RFC 4253, “The Secure Shell (SSH) Transport Layer Protocol”, IETF, January 2006
36 [10] RFC 2132, “DHCP Options and BOOTP Vendor Extensions”, IETF, March 1997
37 [11] RFC 3925, “Vendor-Identifying Vendor Options for Dynamic Host Configuration Protocol version
38 4 (DHCPv4)”, IETF, October 2004
39 [12] RFC 2131, “Dynamic Host Configuration Protocol”, IETF, March 1997
40 [13] RFC 4862, “IPv6 Stateless Address Autoconfiguration”, IETF, September 2007
41 [14] RFC 3315, “Dynamic Host Configuration Protocol for IPv6 (DHCPv6)”, IETF, July 2003

1 [15] RFC 3736, “Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6”, IETF, April
2 2004
3 [16] RFC 7895, “YANG Model Library”, IETF, June 2016
4 [17] RFC 8071, “NETCONF Call Home and RESTCONF Call Home”, IETF, February 2017
5 [18] G.8275.1, “Precision time protocol telecom profile for phase/time synchronization with full timing
6 support from the network”, ITU, June 2016
7 [19] G.8275.2, “Precision time protocol telecom profile for phase/time synchronization with partial
8 timing support from the network”, ITU, March 2020
9 [20] G.810, “Definitions and terminology for synchronization networks”, ITU, August 1996
10 [21] 1588v2-2008, “IEEE Standard for a Precision Clock Synchronization Protocol for Networked
11 Measurement and Control Systems”, IEEE, 2008
12 [22] O-RAN-WG1.OAM-Architecture-v03.00, O-RAN Alliance, Working Group 1
13 [23] O-RAN.WG1.O1-Interface.0-v03.00, “O-RAN Operations and Maintenance Interface
14 Specification”, O-RAN Alliance, Working Group 1
15 [24] 3GPP 28.532, “Management and orchestration; Generic management services”, 3GPP
16 [25] 3GPP 28.545, “Management and orchestration; Fault Supervision (FS)”, 3GPP
17 [26] G.8261, “Timing and synchronization aspects in packet networks”, ITU, August 2019
18 [27] 3GPP 28.541, “Management and orchestration; 5G Network Resource Model (NRM)”, 3GPP
19 [28] ORAN-WG4.CUS.0-v02.00 “Control, User and Synchronization Plane Specification”, O-RAN
20 Alliance, Working Group 4
21 [29] 3GPP 32.342, “File Transfer (FT); Integration Reference Point (IRP)”, 3GPP
22 [30] 3GPP 32.302, “Configuration Management (CM); Notification Integration Reference Point (IRP)”,
23 3GPP
24
25 1.3 Definitions and Abbreviations

26 1.3.1 Definitions
27 For the purposes of the present document, the terms and definitions given in 3GPP TR 21.905 [1] and the following apply.
28 A term defined in the present document takes precedence over the definition of the same term, if any, in 3GPP
29 TR 21.905 [1].
30 Antenna Line: connection between O-RU and antenna
31 C-Plane: Control Plane: refers specifically to real-time control between O-DU and O-RU, and should not be confused
32 with the UE’s control plane
33 c_eAxC: component eAxC: a portion of an eAxC flow assigned to a specific O-DU processing element.
34 DL: DownLink: data flow towards the radiating antenna (generally on the LLS interface)
35 DU: Distributed Unit: a logical node hosting PDCP/RLC/MAC/High-PHY/Low-PHY layers and RF processing layers
36 based on a higher layer functional split for integrated model
37 eAxC: extended Antenna-Carrier: a data flow for a single antenna (or spatial stream) for a single carrier in a single sector.
38 FFT/iFFT: Fast Fourier Transform/inverse Fast Fourier Transform: an algorithm that computes discrete Fourier transform
39 or its inverse.
40 High-PHY: those portions of the PHY processing on the O-DU side of the fronthaul interface, including FEC
41 encode/decode, scrambling, and modulation/demodulation.
42 HLS: Higher Layer Split: logical interface between O-CU and O-DU when using a higher layer functional split

1 LLS: Lower Layer Split: logical interface between O-DU and O-RU when using a lower layer (intra-PHY based)
2 functional split.
3 LLS-C: Lower Layer Split Control-plane: logical interface between O-DU and O-RU when using a lower layer functional
4 split.
5 Low-PHY: those portions of the PHY processing on the O-RU side of the fronthaul interface, including FFT/iFFT, digital
6 beamforming, and PRACH extraction and filtering.
7 M-Plane: Management Plane: refers to non-real-time management operations between the O-DU and the O-RU
8 Port: End of a transport link – in most cases this is an optical port
9 Port Number: A number which identifies a port (see Port). In case of SFP/SFP+ port, port number value is 0 to N-1
10 where N is number of ports in the device. Numbers 0 to N-1 are assigned to ports in order following order of labels on
11 the device (labels for ports are not necessarily numbers starting from zero)
12 O-CU: O-RAN Centralized Unit: a logical node hosting RRC layer based on a higher layer functional split.
13 O-DU: O-RAN Distributed Unit — A logical node hosting PDCP/RLC/MAC/High-PHY layers based on a lower layer
14 functional split.
15 O-RU: O-RAN Radio Unit: a logical node hosting Low-PHY layer and RF processing based on a higher layer functional
16 split in 3-box model. This is similar to 3GPP’s “TRP” or “RRH” but more specific in including the Low-PHY layer
17 (FFT/iFFT, PRACH extraction).
18 S-Plane: Synchronization Plane: refers to traffic between the O-RU or O-DU to a synchronization controller which is
19 generally an IEEE-1588 Grand Master (however, Grand Master functionality may be embedded in the O-DU).
20 Spatial stream: the data flow on the DL associated with precoded data (may be same as layers or different if there is
21 expansion in the precoding), and on UL associated with the number of outputs from the digital beamforming (sometimes
22 called “beams”).
23 SSM: Synchronization Status Message: part of ITU G.781 and G.8264 standards.
24 U-Plane: User Plane: refers to IQ sample data
25 UL: UpLink: data flow away from the radiating antenna (generally on the LLS interface)
26 1.3.2 Abbreviations
27 For the purposes of the present document, the abbreviations given in 3GPP TR 21.905 [1] and the following apply. An
28 abbreviation defined in the present document takes precedence over the definition of the same abbreviation, if any, in
29 3GPP TR 21.905 [1].
30 ALD Antenna Line Device
31 AVP Average Power
32 BCN BTS Clock Number
33 CRC Cyclic Redundancy Check
34 CUS Control/User/Synchronization
35 CU-CP Centralized Unit Control Plane
36 CU-UP Centralized Unic User Plane
37 DHCP Dynamic Host Configuration Protocol
38 DMTC DRS Measurement Timing Configuration
39 DRS Discovery Reference Signal
40 DSCP Differentiated Services Code Point
41 DU Distributed Unit
42 HDLC High-Level Data Link Control
43 lls-M Lower Layer Split Management plane
44 LAA Licensed Assisted Access

1 LBM Loop-Back Message

2 LBR Loop Back Reply
3 LBT Listen Before Talk
4 ME Maintenance Entity
5 MEP Maintenance association End Point
6 NAT Network Address Translation
7 NETCONF Network Configuration Protocol
8 NMS Network Management System
9 O-CU O-RAN Centralized Unit
10 O-DU O-RAN Distributed Unit
11 O-RU O-RAN Radio Unit
12 OMA Optical Modulation Amplitude
13 SMO Service Management and Orchestration
14 PDV Packet Delay Variation
15 PNF Physical Network Function
16 QoS Quality of Service
17 RET Remote Electrical Tilt
18 RPC Remote Procedure Call
19 SFP Small Form-factor Pluggable
20 sFTP Secure File Transfer Protocol or SSH File Transfer Protocol
21 SLAAC Stateless Address Auto Configuration
22 SSH Secure Shell
23 VLAN Virtual LAN
24 YANG Yet Another Next Generation
25
26 1.4 Conventions
27 This management plane specification includes cross references to a set of associated YANG models. Text may reference
28 particular YANG leafs, notifications and remote procedure calls (RPCs). In order to assist in readability, all cross
29 references to YANG defined elements will keep the identical case format as defined in the corresponding YANG model,
30 with the font-weight set to bold. This convention applies only to text and not to YANG elements embedded into figures.
31 If there is any conflict between the YANG models and the accompanying text description in this specification, the
32 definition of the YANG models shall take precedence.
33 1.5 Topics for Future Specification Versions

34 This version of the O1 Interface specification for O-DU is primarily aimed at providing support those mandatory and
35 optional features defined in version 1.0 of the C-Plane, U-Plane and S-Plane specification.
36 The following topics are to be considered for future versions of the specification:
37 1. Adding Trace support according to O1 Interface [23] Chapter 2.4

38 2. Adding ALD support
39 3. Configuration parameters specified in this version of the specification allow for NSA mode support only. L1
40 configuration for NSA will be added to YANG models in the next version. O-DU configuration parameters are
41 subject to evolution in the next version to allow for SA and NR-DC modes support.

1
2
3 Extensions to this version of the O1 Interface specification for O-DU together with corrected errors will be included in
4 the future versions of this document.
5
6 The revision statement in the YANG models will be used to describe future revisions to the models that are backwards
7 compatible. Backwards incompatible changes will be addressed by incrementing the number used as part of the model
8 name and namespace, effectively creating a new YANG model. The format of the namespace used in all O-RAN YANG
9 models is “urn:o-ran:”<model-name>“:”<model-number>, where the initial <model-number> used in a newly defined
10 YANG model is “1.0”. Where this document makes reference to models, irrespective of their backward compatibity, a
11 generic <model-number> of “x.y” is used to enable reference to all versions of the namespace for a particular <model-
12 name>.
13
14 The revision statement in all YANG models includes a reference statement used to cross-reference to the first version of
15 this document where the corresponding description was introduced. For example, the reference in all revision statements
16 for the initial O-RAN models include cross-reference to “ORAN-WG5.MP.0-v01.00”.
17
18 The revision statement of the YANG models also includes a description which is used to track the versioning of the
19 YANG model. All revision statement descriptions will begin with “version ”<a>“.”<b>“.”<c>, where <a>, <b> and <c>
20 are used to reflect the version of the YANG model, where
21
22 <a> corresponds to the first digit of the O-RAN WG5 management plane specification version where the
23 corresponding description was first introduced, corresponding to <x> in sub-section 1.1
24 <b> is incremented when errors in the YANG model have been corrected
25 <c> is incremented only in working versions of the the YANG model indicating incremental changes during the
26 editing process
27
28
29 Chapter 2 High Level Description
30 2.1 Top level functional description, terminology, including hybrid,

31 hierarchical
32 2.1.1 Architecture for O-RAN WG5 functional split
33 This O1 interface facilitates the initialization, configuration and management of the O-DU to support the functional split.
34 Please refer to O-RAN OAM Architecture [22] for more details on architecture and functional split.
35 2.1.2 O1 interface for O-DU architecture model

36 O1 interface for O-DU is used for supporting the management features including “start up” installation, software
37 management, configuration management, performance management, fault management and file management towards the
38 O-DU.
39 2.1.3 Transport Network

40 Based on the transport topology, various modes of network connectivity are possible between O-DU and O-CU and SMO.
41 The basic requirement for O1 interface for O-DU is to have end to end IP connectivity between the O-DU and the elements
42 managing it. IPv4 shall be supported as a mandatory transport protocol for O1 interface for O-DU and IPv6 support is
43 optional.
44 This version of the O1 interface for O-DU has not been defined to be able to operate in the presence of any Network
45 Address Translation (NAT) between the O-DU and elements managing it.

1 2.2 Interfaces
2 This interface is defined between the management system and the O-DU. The protocol stack of the interface is shown in
3 Figure 1. The transport network layer is built on IP transport and TCP/TLS is used to carry the messages between the
4 management system and the O-DU.
5
6 Figure 1: O1 interface protocol stack
7 2.3 YANG Module Introduction

8 The data models representing the O1 interface are organized as a set of reusable YANG modules, defined according to
9 [6]. The YANG modules need to be able to support a variety of deployment scenarios, including
10 i) where the O-RU functionality is co-located with corresponding O-DU functionality, in a classical 3GPP
11 “DU” approach,
12 ii) where the O-RU is deployed using O-RAN WG4 defined hierarchical approach where the O-DU is used to
13 manage all aspects of the remote O-RU connected using the WG4 defined fronthaul interface, and
14 iii) where the O-RU is deployed using O-RAN WG4 defined hybrid approach where the SMO and O-DU in
15 combination are used to manage the remote O-RU connected using the WG4 defined fronthaul interface.
16 In all of the above scenarios, the O-RAN WG4 Management Plane Specification [4] YANG models will be re-used for
17 configuring the O-RU functionality. Because an O-DU managed function will likely support multiple O-RU functions,
18 the O-RAN O1 Interface specification for O-DU defines new models which are used to aggregate the configuration of
19 individual O-RU instances. Figure 2 illustrates how the SMO is responsible for aggregating the individual configuration
20 databases for separate O-RU instances and how the O-DU is responsible for de-aggregating the configuration prior to
21 configuring individual O-RU instances.
22 Refer to the various chapters, Annex C and the repository of YANG models for more details on each of these modules.
23

1
2
3 Figure 2: Details of Configuration Data Bases (CDB)

1 Chapter 3 Startup and Registration Management

2 This chapter provides the overall start-up mechanism from the power-on of O-DU to being ready to be configured.
3 Pre-condition:
4 O-DU is physically installed
5 Power-ON for O-DU/NETCONF Server or O-DU restart operation.
6 Power-ON for NETCONF Client(s).
7 Physical interface(s) is(are) connected.
8 Post-condition:
9 The SMO is able to determine whether the configuration of the O-RU occurs using hybrid or hierarchical approach.
10 Via the connection to the SMO, the O-DU can receive further configuration to enable it to support NETCONF client
11 functionality to enable hierarchical configuration of independent O-RU(s).
12 SMO can determine the O-RU instance identifiers that may be provisioned via the O-DU.


1 Figure 3: Overall of Start-Up Installation
2 3.1 O1 Interface Transport aspects

3 This sub-section provides the O1 interface transport establishment scenario, e.g., between O-DU and SMO. The transport
4 layer address of O1 interface is only the target in this section. Transport aspects of the C-Plane and U-Plane are covered
5 in Chapter 10.
6 Pre-condition:
7 - Physical interface is connected.
8 Post-condition:
9 - The SMO/MnS Consumer has been correctly discovered by the O-DU
10 - Transport Layer address(es) for O1 are known to the O-DU and SMO.
11 - The O-DU is aware of the physical port(s) for O1 interface, e.g., if there are multiple ports supported by the O-DU.
12 - The O-DU is aware of the VLAN(s) to be used for O1 interface, e.g., if VLANs are used in the transport network.
13 - Then O-DU is ready to accept inbound NETCONF sessions from the SMO.
14 For the transport establishment, there are the following alternatives:
15 a) Manual transport layer address configuration in O-DU. This configuration contains the addresses for O-DU and
16 SMO/MnS Consumer(s). The method to manually configure the O-DU is out of scope of this specification. Assuming
17 manual configuration is successful, the NETCONF server shall be able to recover this configured information and use the
18 o-ran-mplane-int.yang model to communicate this operational-state to a NETCONF client.
19 b) DHCP server provides O-DU’s transport layer address information together with the identity of the SMO/MnS
20 Consumer(s). This identity encodes either the transport layer address or FQDN of the SMO/MnS Consumer. If an FQDN
21 is signaled, the O-DU shall use the DNS server address provided by the DHCP server to recover the IP address
22 corresponding to FQDN of the SMO/MnS Consumer.
23 c) If IPv6 is supported, Stateless Address Auto-Configuration (SLAAC) is used to configure the O-DU’s transport
24 address with the DHCP server providing the identity of the SMO/MnS Consumer. This identity encodes either the
25 transport layer address or FQDN of the SMO/MnS Consumer. If an FQDN is signaled, the O-DU shall use the DNS server
26 address provided by the DHCP server to recover the IP address corresponding to FQDN of the SMO/MnS Consumer.
27 Note, a NETCONF client can determine whether an O-DU supports IPv6 by using the get rpc to recover the list of
28 interfaces supported by the O-DU and using the presence of the augmented ipv6 container in the o-ran-interfaces module
29 to indicate IPv6 is supported.
30 The O-DU uses the o-ran-dhcp.yang model to be able to expose information signaled by the DHCP server.

1
2 Figure 4: Transport Layer Establishment for M-plane
4 Transport Layer interface related information for O1 interface contains at least the physical port number, the hardware
5 address of the Ethernet port, VLAN-ID, local IP address, remote IP address, Default Gateway address and Subnet mask.

1 In the case of option b) and c), the following subsections are used:
2 - O-DU identification in DHCP messages from O-DU.
3 - VLAN discovery aspect for O1 interface.
4 - IP address assignment to O-DU.
5 - Discovery of address information of SMO/MnS Consumer(s).
6 3.1.1 O-DU identification in DHCP

7 The O-DU shall identify itself to DHCP servers by using DHCP option(s) using the vendor-class-data string within the
8 o-ran-dhcp YANG model. For DHCPv4, there are two alternatives. One uses option 60 Vendor Class Identifier, RFC2132
9 [10]. The other uses option 124 Vendor Identifying Vendor Class Option, RFC3925 [11]. The O-DU shall support at least
10 one of these options. If the O-DU supports IPv6, then it shall identify itself using the DHCPv6 Vendor Class Option.
11 DHCPv4 Vendor Class Option:
12 • Option: 60
13 • Vendor Class Identifier Option 60: string
14 The format of the vendor class string shall be configured to one of the following three options, and where
15 <ManagedElementType> corresponds to “o-ran-du”:
16 1. <optionalMvPnC/><ManagedElementType>/<vendor>, e.g., “MvPnC/o-ran-du/vendorA”
17 2. <optionalMvPnC/><ManagedElementType>/<vendor>/<product-code>, e.g.,
18 “MvPnC/o-ran-du/vendorA/ODU100”
19 3. <optionalMvPnC/><ManagedElementType>/<vendor>/<product-code>/<serial-number>, e.g.,
20 “MvPnC/o-ran-du/vendorA/ODU100/GS1921020222”
21 DHCPv4 Vendor-Identifying Vendor Class Option:
22 • Option: 124
23 • Enterprise number: O-RAN-alliance 53148
24 • Vendor-Class-Data: the format of the string shall follow the rules defined for the DHCPv4 Vendor Class Option
25
26 DHCPv6 Vendor Class Option:
27 • Option: 16
28 • Enterprise number: O-RAN-alliance 53148
29 • Vendor-Class-Data: the format of the string shall follow the rules defined for the DHCPv4 Vendor Class Option
30
31 The DHCP Server may use this information when allocating IP addresses or when configuring O1 interface SMO/MnS
32 Consumer information in the O-DU.
33 3.1.2 Management Plane VLAN Discovery Aspects

34 The O-DU will be connected to one or more Ethernet ports. The transport systems may be realized such that these Ethernet
35 ports may be configured either as an access port, where untagged Ethernet frames are used, or as a trunk port, where
36 multiple VLANs are configured. At start up, the O-DU will typically not be able to immediately determine whether its
37 ports are attached to remote transport equipment configured for access or trunk mode operation.

1 Once an O-DU completes its boot-up sequence and Ethernet connectivity is detected on at least one of its Ethernet
2 interfaces, the O-DU starts management plane connection establishment.
3 The O-DU needs to determine whether it is connected to an access port or a trunk port. In particular, when connected to
4 a trunk port, the O-DU needs to additionally determine the VLAN identity/ies used to support the management plane
5 communication(s). The VLAN(s) used to support management plane communications can be identified by the DHCP
6 server replying to the DHCP DISCOVER message, as described in section 3.1.4.
7 Note, an O-DU which supports IPv6 may infer that a VLAN is not used to support management plane communications if
8 it receives an IPv6 Router Advertisement without either the “managed address configuration” or “other configuration”
9 bits set.
10 An O-DU may have been previously configured with management plane VLAN information, for example storing the last
11 VLAN(s) used for management plane connectivity, and/or being previously configured with a range of management plane
12 VLANs by a NETCONF client that has been stored in reset-persistent memory. The O-DU may use this information to
13 optimize its discovery of the VLAN ID(s) used for management plane connectivity.
14 If the O-DU does not have previously configured management plane VLAN information, the O-DU shall attempt to
15 discover DHCP servers on all of its Ethernet ports using untagged Ethernet frames.
16 If the O-DU does not receive a DHCP OFFER from a DHCP server using untagged frames, or previously configured
17 VLANs, the O_DU should attempt to contact a DHCP server using individual VLANs on all of its Ethernet ports.
18 3.1.3 O-DU IP Address Assignment used for O1 signalling

19 Automatic IP address assignment for the O-DU management plane can be achieved using different techniques:
20 1. IPv4 configuration using DHCPv4, RFC2131 [12] enables DHCP servers to configure IPv4 network address(es) on
21 the O-DU. An O-DU shall support the behavior specified in RFC 4361 [8], using stable DHCPv4 node identifiers in their
22 dhcp-client-identifier option.
23 Note: a network realized with multiple DHCP servers should ensure that their configurations are co-ordinated to ensure
24 a common default gateway is provisioned in an O-DU which receives multiple DHCPv4 responses, e.g., when received
25 over different interfaces.
26 Note: an O-DU may indicate that it supports configuration of routing information using RFC 3442, enabling static routes
27 to be used by the O-DU when determining how to route uplink packets, e.g., when the O-DU supports multiple interfaces.
28 For O-DUs that support IPv6, both stateful and stateless address assignment procedures are supported:
29 2. IPv6 Stateless Address Auto-Configuration (SLAAC), RFC4862 [13] enables the O-DU to generate link-local and
30 global addresses.
31 Note: a network realized with multiple IPv6-enabled routers that support dynamic address assignment is expected to use
32 RFC 4191 to configure the preference of the default route prefixes learnt by the O-DU using SLAAC.
33 3. IPv6 State-full address configuration uses DHCPv6, RFC3315 [14] and enables DHCP servers to configure IPv6
34 network address(es) on the O-DU. DHCPv6 is transported using UDP, using the link-local address on the O-DU and a
35 link-scoped multicast address on the DHCP server.
36 The DHCP server should operate using static bindings, i.e., ensuring a O-DU identified by a particular client hardware
37 address will be re-allocated the same management plane IP address, e.g., after performing a reset procedure.
38 3.1.4 NETCONF Client Discovery

39 In contrast to the WG4 defined O-RU M-Plane interface, the O-DU is NOT responsible for discovery of NETCONF
40 client(s) and establishing NETCONF connectivity using the NETCONF call home procedure as defeined in [17].
41 Nevertheless, it is still responsible for discovery of MnS Consumer. For more details please refer to Chapter 3.1.6
42 SMO/MnS Consumer Discovery
43 3.1.5 CA/RA Discovery

44 This section describes how to automatically discover the Certificate Authority server/Registration Authority server.

1 As described in Chapter 3.2 Certificate Enrolment, an O-DU shall support certificate enrollment using CMPv2. 3GPP
2 32.509 specifies how the O-DU can discover the IP address or FQDN of one or more Certification Authority (CA/RA)
3 servers using DHCP Option 43.
4 In addition to the DHCPv4 encoding using Option 43, an O-DU supporting IPv6 shall additionally support the signaling
5 of vendor specific options using DHCPv6 option 17. The format of the DHCPv6 option 17 follows the format of the
6 DHCPv4 encoding, with the additional inclusion of an Enterprise Number prior to the TLV option data. The IANA
7 allocated private enterprise number to be used with DHCPv6 option 17 is 53148 (as allocated by IANA to O-RAN
8 Alliance).
9 An O-DU shall report any discovered multi-vendor plug-and-play servers using the o-ran-dhcp YANG model.
10 3.1.6 SMO/MnS Consumer Discovery

11 This section describes how an O-DU automatically discovers the SMO/MnS Consumer to which it shall send its
12 PNFRegistration event.
13 O-DUs that have obtained their IPv6 addresses by stateless address auto-configuration, shall use stateless DHCPv6,
14 RFC3736 [15], to obtain SMO/MnS Consumer information.
15 Other O-DUs operating using stateful IPv4 or IPv6 address allocations shall obtain SMO/MnS Consumer information
16 during IP address allocation.
17 The O-DU shall be able to recover SMO/MnS Consumer information using O-RAN defined vendor specific option to
18 signal SMO/MnS Consumer information to the O-DU using option 43 for DHCPv4 and option 17 for DHCPv6. Multiple
19 instances of the SMO/MnS Consumer information may be signaled, encoded as a sequence of type/length/value fields.
20 The definition of the types used within the DHCPv4 option 43/DHCPv6 Option 17 are as follows:
21 Type: 0x83 – SMO/MnS Consumer IP Address
22 Type: 0x84 – SMO/MnS Consumer Fully Qualified Domain Name
23 In both cases, the Type is followed by the length, which is the hexadecimal encoding of length of value field in octets,
24 and the Value.
25 When Type corresponds to an SMO/MnS Consumer IP Address, the value encodes IPv4 address(es) in hexadecimal
26 format. For example, an SMO/MnS Consumer with IPv4 address 198.185.159.144 will be encoded in an option 43 TLV
27 as
28 Type 0x83
29 Length: 0x04
30 Value: C6 B9 9F 90
31 When Type corresponds to an SMO/MnS Consumer Fully Qualified Domain Name, this encodes the string representation
32 of domain name, using ACSII encoding (i.e., following for encoding used for the domain name in the Host Name DHCP
33 Option 12). For example, a server with FQDN “collector.operator.com” will be encoded in an option 43 TLV as
34 Type 0x84
35 Length: 0x17
36 Value: 63 6fF6C 6C 65 63 74 6F 72 2E 6F 70 65 72 61 74 6F 72 2E 63 6F 6D
37 The format of the DHCPv6 option 17 follows the format of the DHCPv4 encoding, with the additional inclusion of an
38 Enterprise Number prior to the TLV option data. The IANA allocated private enterprise number to be used with DHCPv6
39 option 17 is 53148.
40 3.2 Certificate Enrolment

41 3GPP 33.310 specifies the use of CMPv2 used by base stations to obtain an operator-signed certificate using a secured
42 communication based on the vendor-signed certificate in the base station and a vendor root certificate pre-installed in the

1 CMPv2 server. While the approach has been defined for provisioning certificates for use in establishing the security
2 association to an IPSec Security Gateway, the same technique is used here to obtain an operator-signed certificate for use
3 in securing the NETCONF connection between the O-DU and the NETCONF client in the SMO as well as securing the
4 JSON/HTTPS connection between the O-DU and the SMO/MnS Consumer.
5 After enrollment has been performed, the O-DU can use the operator-signed certificate to authenticate itself to the SMO
6 NETCONF client, which is pre-installed with the operator root certificate. The O-DU then authenticates the NETCONF
7 client using the operator root certificate.
9
10 Figure 5: Certificate Enrolment
11
12 3.3 PNF Registration

13 An O-DU realized as a Physical Network Function (PNF) is required to perform a PNF Registration. The pnfRegistration
14 notification is a JSON encoded VES event sent from the O-DU to the discovered SMO/MnS Consumer using
15 REST/HTTPS. When performing PNF Registrartion, the O-DU shall send the pnfRegistration notification to all
16 discovered SMO/MnS Consumers.
17 The pnfRegistration notification shall include the IP address information necessary for a NETCONF client to establish
18 IP connectivity to the NETCONF Server in the O-DU, i.e., shall include the field oamV4IpAddress when the O-DU has
19 a configured IPv4 interface and/or the field oamV6IpAddress when the O-DU has a configured IPv6 interface.
20 3.3.1 Monitoring SMO/MnS Consumer Connectivity

21 When required, the Heartbeat notification type can be used to confirm continued connectivity between the O-DU and
22 the SMO/MnS Consumer.

1 3.4 NETCONF Connection Establishment

2 The identity of the TLS server (O-DU) shall be verified and authenticated by the TLS client (NETCONF client) according
3 to local policy before password-based authentication data or any configuration or state data is sent to or received from the
4 TLS server.
5 3.4.1 NETCONF Security

6 In this version of O1 Interface Specification, the security of the NETCONF protocol is realized using TLS (RFC 5539).
7 As the default, the NETCONF Server in the O-DU shall provide access to the NETCONF subsystem only when using
8 TLS established using the IANA-assigned TCP port 6513 [Ref: RFC 5539]. The O-DU may be configured to additionally
9 allow access to the NETCONF subsystem over other ports.
10 If multiple NETCONF sessions are established to an O-DU, those sessions shall be established over separate TLS tunnels.
11 3.4.2 NETCONF Authentication

12 This version of the O1 Specification uses mutual authentication based on X.509 certificates [7].
13 Mutual Public key-based client/server authentication shall be used for authenticating the server (RFC 4253 [9]) by the
14 clients. and authenticating the client by the server.
15 For the purposes of NETCONF user authentication, the mapping between certificates and user-names is provided by the
16 SubjectAltName field of the X.509 certificate [7], which means that the user name is coded in the subjectAltName. The
17 username is determined from the subjectAltName using the rules defined in RFC 7589.
18 3.4.3 User Account Provisioning

19 The vendor will pre-provision a set of user-names in the O-DU together with corresponding access control groups and
20 will provide these details to the operator to then enable these to be included in appropriately operator singed certificates
21 used by the NECTONF clients when authenticating themselves to the NETCONF server in the O-DU.
22 A NETCONF client, with appropriate privileges, may be used to provision new user-names and associated access control
23 group(s) in the O-DU.
24 3.5 NETCONF Access Control

25 This subsection provides the access control for NETCONF client. Its motivation is when multiple NETCONF clients
26 (users) exist, access control mechanism allows to limit some operation for one client but full access for the other client.
27 In order to support interoperable access control management, the NETCONF Server shall use the IETF NETCONF Access
28 Control Model [RFC8341].
29 Currently four access control groups are defined per TLS session: “sudo”, “smo”, “fm-pm”, and “swm”. The table below
30 maps the group name to different privileges. Privileges are defined per namespace for read “R”, write “W” and execute
31 “X” rpc operations or subscribe to Notifications.
32

Module Rules sudo smo fm-pm swm

"urn:o-ran:hardware:x.y" RWX RWX --- ---
"urn:ietf:params:xml:ns:yang:ietf-hardware" RWX RWX R-X ---
“urn:ietf:params:xml:ns:yang:iana-hardware” RWX RWX R-X ---
"urn:ietf:params:xml:ns:yang:ietf-ip" RW- RW- R-- ---
"urn:ietf:params:xml:ns:yang:ietf-interfaces" RW- RW- R-- ---
“urn:ietf:params:xml:ns:yang:ietf-netconf-acm” RW- R-- R-- R--
"urn:ietf:params:xml:ns:yang:ietf-yang-library" R-X R-X R-X R-X
“urn:ietf:params:xml:ns:yang:ietf-netconf-monitoring” R-X R-X R-X R-X
"urn:o-ran:user-mgmt:x.y" RWX note1
--- --- ---
"urn:o-ran:synchronization: x.y " RWX RWX R-- ---
Note1: The rule list for "urn:o-ran:user-mgmt:1.0” shall additionally deny reading of the password leaf by any NETCONF client
1 Table 1: Mapping of account groupings to O-DU module privileges
3 This mapping shall be encoded in the rule list in ietf-netconf-acm.yang model. This rule list shall be unmodifiable by
4 any NETCONF client.
5 The same model is responsible for configuring the mapping between different user-names and groups.
6 For Aggregated YANG data models access control please refer to Chapter 3.4 of [4].
7 3.6 NETCONF Protocol Aspects

8 This section covers of aspects of NETCONF protocol usage by the O-DU. For full list of supported services please refer
9 to Chapter 2.1 of [23].
10 3.6.1 NETCONF Capability Discovery

11 The O-DU advertises its NETCONF capabilities in the NETCONF Hello message. The Hello message provides an
12 indication of support for standard features defined in NETCONF RFCs [5] as well as support for specific namespaces.
13 NETCONF capabilities are exchanged between the O-DU and the NETCONF client(s).
14 For full list of supported operations and capabilities please refer to Chapter 2.1.1. from [23]
15 3.6.2 Framework for optional feature handling

16 This section describes the common and optional features supported by O-DU.
17 An O-DU may have some features which are not supported by other O-DUs, i.e. optional feature(s). In this case, the O-
18 DU needs to inform the SMO which features the O-DU can provide, and this can be achieved by exchanging NETCONF
19 capabilities.
20 Some of the YANG models are optional for the O-DU to support. Mandatory models may define optional feature
21 capabilities that particular O-DU supports.
22 The O-DU shall use the ietf-yang-library model (RFC 7895) [16] to list the namespace of the models supported by the
23 Server. If an O-DU does not return the namespace associated with an optional YANG model, the SMO determines that
24 the O-DU does not support the optional capability associated with the model.
25 In addition, for each supported schema, the ietf-yang-library lists the YANG feature names from this module that are
26 supported by the server. The details of optional models and features are defined in Annex B.
27

1 3.6.3 Closing a NETCONF Session

2 A NETCONF client closes an existing NETCONF session by issuing the RPC close-session command. The O-DU shall
3 respond and close the TLS session.
4 Chapter 4 Heartbeat Management Services
5 4.1 Heartbeat Notification

6 Heartbeat Notification for O-DU is aligned with [23], Chapter 2.6.1 Heartbeat Notification.
7 4.2 Heartbeat Control

8 Heartbeat Control for O-DU is aligned with [23], Chapter 2.6.2 Heartbeat Control.
10 Chapter 5 PNF Software Management

11 The PNF Software Management Services specified in O1 Interface Specification [23] is adapted to the software
12 management for O-DU. Please refer section 2.8 of [23]. This chapter describes the behaviour of O-DU in the software
13 management process between the SMO, O-DU and O-RU.
14 In the hybrid architecture for O-RU, this chapter is not applicable if O-DU is not responsible for the SW management of
15 O-RU. In such case, the SMO performes the software management of O-DU by [23], and the software management of
16 O-RU by O-RAN WG4 Management Plane Specification [4]. The SMO may perform the software management of O-
17 RU by O1 Interface Specification [23] if O-RU supports [23] for its management.
18 5.1 O-DU Software Management

19 Please refer to section 2.8 of [23].
20 5.2 O-RU Software Management

21 5.2.1 Hierarchical Model
22 5.2.1.1 Preparation
23 5.2.1.1.1 Aggregated YANG data model

24 O-DU provides the software inventory information of each connected O-RU to the SMO by o-ran-agg-software-
25 management.yang that has a mount point. To mount the software-inventory instance in o-ran-software-
26 management.yang defined in [23] under the mount point, O-DU shall prepare the ietf-yang-schema-mount.yang with
27 appropriate configuration as shown in the following example.
28 Example: configuration of the ietf-yang-schema-mount.yang in xml format for software management.

29 <schema-mounts>
30 <namespace>
31 <prefix>o-ran-swm</prefix>
32 <uri>urn:o-ran:software-management:1.0</uri>
33 </namespace>
34 <mount-point>
35 <module>o-ran-agg-software-management</module>

1 <label>swm-root</label>
2 <config>false</config>
3 <inline></inline>
4 </mount-point>
5 </schema-mounts>
6
7 In this case, building the data tree such as following image, which is not created or validated by a tool (e.g. pyang), is
8 expected and the SMO will retrieve it from O-DU.
9 module: o-ran-aggregation-base
10 +--rw aggregated-o-ru
11 +--ro recovered-ru-instance-ids* [ru-instance-id]
12 | +--ro ru-instance-id ru-ref
13 +--rw aggregation* [ru-instance]
14 +--rw ru-instance -> /aggregated-o-ru/recovered-ru-instance-ids/ru-instance-id
15 +--rw or-agg-swm:software-management-model
16 +--mp swm-root
17 +--ro software-inventory
18 +--ro software-slot* [name]
19 +--ro name string
20 +--ro status enumeration
21 +--ro active? boolean
22 +--ro running? boolean
23 +--ro access? enumeration
24 +--ro product-code? -> /hw:hardware/component/o-ran-hw:product-code
25 +--ro vendor-code? string
26 +--ro build-id? string
27 +--ro build-name? string
28 +--ro build-version? string
29 +--ro files* [name]
30 +--ro name string
31 +--ro version? string
32 +--ro local-path string
33 +--ro integrity? enumeration
34 5.2.1.2 Software inventory
35 5.2.1.2.1 Description
36 The SMO retrieves the software inventory information of O-RU by using the aggregated yang data model.
37 5.2.1.2.2 Procedures
38 Precondition:
39 - O-DU has the software inventory information of connected O-RUs, which is retrieved in startup with O-RU.
40

1
2 Figure 6: Software Inventory
3 1. SMO establishes NETCONF session with O-DU.

4 2. O-DU receives NETCONF <rpc><get><filter> from SMO where software aggregated model is indicated to retrieve
5 information of software slot of O-RU.
6 3. O-DU returns requested data in NETCONF <rpc-reply> response.
7 4. SMO terminates NETCONF session with O-DU.
8
9 5.2.1.3 Software Download
11 The SMO triggers the software download to O-RU by sending software download rpc defined in [23] with ru-instance-
12 id which identifies a target O-RU. After software download for O-RU, O-DU performs the software install to O-RU
13 according to [4].
15

1
2 Figure 7: Software Download

4 2. SMO sends NETCONF <rpc><software-download><remote-file-path><softwarePackage> with ru-instance-id to
5 trigger a download of the software and to identify the target O-RU.
6 a. O-DU validates the request.
7 3. O-DU returns NETCONF <rpc-reply><software-download-status>.
9 Altanative 1: O-RU directly downloads the slotware package from sotware server
10 5. O-DU sends <rpc><software-download> toward O-RU with remote-file-path.
11 6. O-RU returns <rpc-reply><software-download>.
12 7. O-RU downloads the software package.
13 Altanative 2: O-RU indirectly downloads the slotware package from sotware server
14 8. O-DU downloads software package of O-RU form software server and temporarily stores in the storage on itself.
15 NOTE: storing SW package in O-DU may be removed after step 14.
16 b. O-DU decides whether download is needed or not by comparing manifest file and information of slotware
17 slot.
18 9. O-DU sends <rpc><software-download> toward O-RU with remote-file-path.
19 10. O-RU returns <rpc-reply><software-download>.
20 11. O-RU downloads the software package.
21 12. O-RU sends <notification><download-event> to notify the result of download process.

1 13. O-DU sends <rpc><software-install> to perform the software install for O-RU. O-DU selects an install slot based
2 on [4].
3 14. O-RU returns <rpc-reply><software-install>.
4 15. O-RU sends <notification><install-event> to notify the result of install process.
5 16. When download operation is completed, O-DU sends download-event NETCONF downloadFile notification to
6 SMO with the final status of the download (success or the reason for failure).
7
9 5.2.1.5 SW activate
11 When O-DU receives NETCONF <rpc><software-activate><softwarePackage> with ru-instance-id from the SMO, O-
12 DU executes the software activation mechanism to O-RU indicated by ru-instance-id.
14
15 Figure 8: Software Activate
16
18 2. SMO sends NETCONF <rpc><software-activate><softwarePackage> with ru-instance-id to trigger an activation
19 of the software slot on O-RU.
20 a. O-DU validates the request.
21 3. O-DU returns status to the SMO in the NETCONF <rpc-reply> response.
23 5. O-DU sends <rpc><software-activation> to activate the software slot on O-RU. The most recentory used slot to
24 install is selected.
25 6. O-RU returns status into <rpc-reply>.
26 7. O-DU recieves <notificatoin><activation-event>.

1 8. O-DU sends <rpc><reset> toward O-RU to apply the newly installed and activated software.
2 9. O-RU returns <rpc-reply>.
3 a. O-RU starts reset process.
4 10. When O-DU retrieves software inventory information of all reset O-RU in the startup, O-DU sends a
5 softwareActivate notification to SMO with the final status of the software activate and O-RU reset results.
6
7 5.2.2 Hybrid Model

8 Please refer to O-RAN WG4 Management Plane Specification [4].
9 Chapter 6 Performance Assurance Management
10 6.1 Performance Data File Reporting

11 Performance Data File Reporting function for O-DU is aligned with O1 Interface Specification [23] except following
12 part.
13 O-RU performance counters measured at O-RU:
14 In the hierarchical architecture of O-RAN WG4 Management Plane Specification [4], O-DU as NETCONF client will
15 control the performance measurement of O-RU as NETCONF server. The information to be collected in O-RU is also
16 controlled by SMO via O-DU by [4]. They are defined in Annex A.14.
17 The measured result file created by O-RU will be periodically uploaded to O-DU’s internal storage aligned with [4] and
18 O-DU will handle it by Performance Data File Reporting function aligned with O1 interface spec [23]. As the
19 alternative way, the measured result file created by O-RU will be forwarded to the FTP server configured by O-DU. For
20 the latter case, Performance Assurance MnS Consumer shall provide the remote-SFTP-upload-path and its credential to
21 O-RU that can upload the PM data file directly.
22 6.1.1 PM File Content

23 The measType and definitions for performance counters are described in Annex A.
24 6.1.2 PM File Naming

25 PM file naming is specified in [23] section 2.3.1.7.
26 6.1.3 PM File XML Format

27 PM file XML format is specified in [23] section 2.3.1.8.
28 6.2 Performance Data Streaming

29 Performance Data Streaming for O-DU is aligned with [23]
30 6.3 Performance Assurance Control

31 Performance Assurance Control for “O1 interface for O-DU” is aligned with [23].
32 In addition to the parameters defined in Measurement Control, the following two parameters are additionally defined for
33 O1 interface spec.
34 - pm-count-list-drb: indicates the QoS group specific to performance assurance control for qci-index. Each entry
35 contains qci-index [0…255] and corresponding pm-count-group [0…17]. The multiple entries with different qci-

1 index can map to same pm-count-group to combine the measurement result for them. Value 0 for pm-count-
2 group means that there is no need to collect measurement for the qci-index.
3 - pm-count-list-srb: indicates the QoS group specific to performance assurance control for srb-index. Each entry
4 contains srb-index [SRB1S, SRB2S, SRB3] and corresponding pm-count-group [0…17]. Value 0 for pm-count-
5 group means that there is no need to collect measurement for the srb-index.
7 6.3.1 Performance Assurance Control for O-RU performance counters

8 O-RU performance counters measured at O-DU:
9 In the hierarchical architecture of O-RAN WG4 Management Plane Specification [4], O-DU as NETCONF client will
10 measure the performance counters defined in Annex A.13. The measurementTypes and gPs for O-RU performance
11 counters measured at O-DU are defined in aggregation model. A part of yang tree structure related to this subsection is
12 shown as follows.
19 +--ro or-agg-pm:measurementsList* [idx]
20 | +--ro or-agg-pm:idx uint32
21 | +--ro or-agg-pm:measurementTypes* string
22 | +--ro or-agg-pm:gPs* uint32
23 On the other hand, the measurement control such as selecting the counters to be reported is performed using SA5 data
24 model in the same way as other measurement counters for O-DU.
25
26 O-RU performance counters measured at O-RU:
27 The measurement activation and de-activation of O-RU are controlled by SMO by aggregation model according to [4]
28 section 7.1. The details of configuration method of aggregation model are described in chapter 10.
29
30 Chapter 7 Fault Supervision Management

31 Fault Supervision Management allows a managed element to provide asynchronous Fault notification to the authorized
32 manager of the managed element. O-DU should have a capability to send fault notifications and corresponding
33 authorized manager should have a capability to receive and handle the fault notifications for managed element.
34 The requirement of Fault Supervision Management is based on the the Fault Supervision Management Services of O1
35 interface specification [47] that contains 3GPP TS 28.545 [25] such as the requirement of fault notification and control.
36 This chapter describes the fault supervision management for O-DU specific aspects.
37 7.1 General
38 General architecture of Fault Supervision Management is aligned with the Fault Supervision Management Services of
39 O1 interface specification [47].
40 7.2 Definition of the Operations for Fault Events

41 Dedicated operations for management services are aligned with 2.2.2 Fault Supervision Control in O1 interface
42 specification [47].
43 AlarmList IOC definition is specified in TS 28.622 [48] section 4.3.26 and 4.3.27 with attribute definitions in section
44 4.4.1.

1 YANG solution set for AlarmList IOC is provided in TS 28.623 [49] appendix D.2.9.
2 7.2.1 Request for getAlarmList

3 The authorized consumer invokes this operation to request the service provider to provide the complete or filtered list of
4 active alarms. The O-DU as Fault Supervision MnS Provider is responsible for managing the “getAlarmList” of O-DU.
5 When Fault Supervision MnS Consumer performs request to get AlarmList, O-DU responses AlarmList including
6 AlarmRecords.
8 7.2.2 Request for clearAlarms

9 The O-DU as Fault Supervision MnS Provider is responsible for managing the “clearAlarms” of O-DU. clearAlarms is
10 only for ADMC (Automatically Detected, Manually Cleared) alarms. If the Service Provider supports ADMC alarms,
11 then this operation should be supported. Otherwise, it is not required.
12
13 7.2.3 Request for acknowledgeAlarms

14 The O-DU as Fault Supervision MnS Provider is responsible for managing the “acknowledgeAlarms” of O-DU.
15 However, there is no use case in O1 interface specification [47] to satisfy the request to acknowledge one or multiple
16 alarms and report acknowledgement state change notifications of a MnS Provider. If use cases are defined for
17 acknowledgeAlarms in O1 interface specification [47], then this Fault Supervision Management chapter will be
18 updated.
19 7.3 Definition of Notifications as Fault Events

20 O-DU as for Fault Supervision Data Report service producer notifies the JSON encoded asynchronous notifications to
21 Fault Supervision MnS Consumer using REST/HTTPS. In order to align with O1 interface specification [47], this
22 chapter describes mandatory notification types excluding optional notification types among 3GPP fault notifications
23 specified in TS 28.532 [24].
24 7.3.1 Notification notifyNewAlarm

25 The Fault Supervision Data Report management service producer notifies the new alarms to the authorized consumer.
26 7.3.2 Notification notifyChangedAlarm

27 The Fault Supervision Data Report management service producer notifies the changed alarms to the authorized
28 consumer.
29 7.3.3 Notification notifyClearedAlarm

30 The Fault Supervision Data Report management service producer notifies the cleared alarms to the authorized
31 consumer.
32 7.4 Message Format for Fault Events

33 An O-RAN fault notification is specified in section 2.2.1.4 of O1 interface specification [47].
34 7.5 O-RU Alarms Management by O-DU in Hierarchical Model

35 In hierarchical model, O-DU is responsible for managing AlarmRecords in the AlarmList, including O-DU alarms and
36 O-RU alarms. O-DU receives NETCONF based alarm notification from the O-RU, converts NETCONF based alarm

1 notification to O-RAN fault notification, updates AlarmRecords and delivers it to SMO. O-DU alarms and O-RU
2 alarms may have the same alarm-id, they are distinguished using nfcNamingCode in the VES common event header.
4
5 Figure 9: Operation to merge O-RU Alarms by O-DU
7 The field mapping between NETCONF based alarm notification and VES based Fault3gpp notification is as in the
8 following table:
O-RU NETCONF SQ ONAP VES common ONAP VES event SQ Remark

based fault event header field parameter name
notification name in ‘fault3gppFields’
fault-id M - alarmId O
fault-source M - additionalInformation O
affected-objects
M - additionalInformation O
- name
fault-severity M - If is-cleared is TRUE, perceivedSeverity

shall be updated with "Cleared".
perceivedSeverity M
If is-cleared is FALSE, notificationType
is-cleared M - shall be updated with fault-severity.
fault-text O - additionalInformation O
If is-cleared is TRUE, event-time shall
be mapped to lastEpochMicrosec.
startEpochMicrosec
event-time M - M If is-cleared is FALSE, event-time shall
lastEpochMicrosec
be mapped to both startEpochMicrosec
and lastEpochMicrosec.

1 Table 2: Mapping of O-RU NETCONF based fault notification to ONAP VES in ‘fault3gppFields’
2
3
4 Chapter 8 File Management

5
6 This chapter illustrate File Management between the O-DU and the SMO/OAM. The File Management Service is
7 applied to manage file transfer for different types of data file such as Bulk CM file, Cell and UE trace file, Performance
8 Measurement result file, etc. The following file management use cases are supported for the O-DU:
9 • List available files
10 • Transfer file
11 • Download file
12 • File ready notification
13 The detailed description of the use cases including file management operations and procedures as well as sequence
14 diagram can be found in the O1 Interface Specification [23], chapter 2.5.
15 This chapter shall describe the handling of files that are stored in the O-DU which are generated by the O-DU itself or
16 transferred from another server like O-RU(s). One scenario would be that files stored in the O-DU file repository are
17 transferred from the O-RU or from some other file servers. The files handling between O-DU and O-RU are defined in
18 the O-RAN WG4 Management Plane Specification [4].
19 The data files that are stored in the O-DU shall follow Chapter 8.1 of this specification.
20 Note: File Management for O-CU shall be illustrated in the future.
21 8.1 File Structure

22 The file system structure for the O-DU is defined as for file management procedures defined in the rest of this chapter. If
23 the O-DU’s physical file structure differs from the logical file structure defined below, the O-DU shall perform the
24 mapping related files into defined structure.
25 The O-DU shall support the standized folders for files generated by the O-DU itself and files transferred from O-RUs.
26 The following standardized folers are defined:
27 › O-RAN/O-DU/PM/ for performance data files
28 › O-RAN/O-DU/CM/ for configuration files (except inventory),
29 › O-RAN/O-DU/NL/ for notification log file
30 › O-RAN/O-DU/CT/ for call trace files
31 › O-RAN/O-DU/OT/ for other files
32 › O-RAN/O-DU/O-RU<RC>/ for files from O-RU which shall follow [4] logical file structure. The RC parameter
33 is a running count, starting with the value of "1", and shall be appended only if the filename is not unique, i.e.
34 more than one file is generated, and all other parameters of the file name are identical.
35 › The O-DU may additionally support vendor defined folders which are out of scope of this specification.

1 8.2 Notification notifyFileReady

2 The file ready notification is applied when the management data files have been prepared in the O-DU. The O-DU will
3 send notification using notifyFileReady VES event to subscribed SMO/OAM in order to notify the availability of the
4 file(s) as defined in [23].
5 The following input parameters are provided by the file ready notification (see also 3GPP TS 32.342[29]):
objectClass Notification header – see 3GPP TS 32.302[30].
It shall carry the FTIRP class name.
objectInstance Notification header - see 3GPP TS 32.302[30].
It shall carry the DN of the FTIRP.
notificationId Notification header - see 3GPP TS 32.302[30].
eventTime Notification header - see 3GPP TS 32.302[30].
systemDN Notification header - see 3GPP TS 32.302[30].
notificationType Notification header – see 3GPP TS 32.302[30].
fileInfoList It specifies the information of the available file.
additionalText It carries vendor-specific semantics not defined
in the present document.
6 Table 3: Parameters list for Notification notifyFileReady
8 When a file is available, the O-DU sends a notifyFileReady notification to the SMO using HTTP/TLS as defined in
9 [23].
10
11 Figure 10: File Ready Notification
12
13 8.3 File Management Operation: listAvailableFiles

14 This listAvailableFiles operation for the SMO/OAM is applied to obtain the available file list with files location and type
15 from the O-DU by reading the AvailableFileList IOC as specified in [29]. SMO/OAM may read the O-RU available files
16 which are already stored in the O-DU and can be represented with AvailableFileList IOC as specified in [29].
17 The following rpc is used for listAvailableFiles operation.
18 -rpc: list-available-files
19 - input
20 - name of AvailableFileList IOC on O-DU
21 - Filter: the content which is intereting from SMO/OAM (* is allowed as wild-card)
22 - output
23 - data: whether O-DU accepted with the contents of the AvailableFileList.IOC or

1 - reject-reason: the human readable reason why O-DU rejects the request (only applicable if status is rejected)
3
4 Figure 11: List Available Files
5 8.4 File Management Operation: retriveveFileList

6 This retriveveFileList operation for the SMO/OAM is applied to retrieve the file list from the O-DU by given related file
7 path. Especially for the O-RU files which are already stored in the O-DU specific file path, the SMO/OAM can retrieve
8 the list with this operation. One or multiple files information can be retrieved by one operation (use of wildcard is allowed).
9 The SMO/OAM triggers the operation to the O-DU.
10 The following rpc is used for retriveveFileList operation.
11 -rpc: retrieve-file-list
12 - input
13 - logical path: the logical path of files to be retrieved as specified below (* is allowed as wild-card)
14 - file-name- filter: the files which has the “file name filter” in the file name (* is allowed as wild-card)
15 - output
16 - file list
17 - status: whether O-DU accepted or rejected the retrieve file list request or
18 - reject-reason: the human readable reason why O-DU rejects the request (only applicable if status is rejected)
19
20
21 Figure 12: Retrieve File List
22

1 8.5 File Management Operation: transferFile

2 The Transfer File Service provides the capability for the SMO/OAM to transfer files from or to the O-DU. The
3 SMO/OAM may perform this action as a result of a FileReady notification from the O-DU informing SMO/OAM that a
4 file is now available to transfer. In any case, the file transfer is performed using a secure file transfer protocol (SFTP or
5 FTPeS) from or to the location provided by the O-DU. The SMO/OAM triggers file transfer operation to the O-DU.
6 Detailed procedure can be found in Chapter 2.5.3 of [23].
7 8.6 File Management Operation: downloadFile

8 The Download File Service provides the capability for the SMO/OAM to request the O-DU to download the file(s)
9 when the SMO/OAM has a file that needs to be downloaded. In any case, the file download is performed using a secure
10 file transfer protocol (SFTP or FTPeS) from the location provided by the SMO/OAM. The O-DU replies to the
11 SMO/OAM with the result of the download procedure. Detailed procedure can be found in Chapter 2.5.4 of [23]
12 Chapter 9 Synchronization Aspects

13 This chapter provides the Management Plane’s interactions with various aspects of the time synchronization of the O-
14 DU. In general, the O-DU is responsible for managing its synchronization status, to select one or more synchronization
15 input source(s) in the LLS-C1/LLS-C2/LLS-C3 deployments and act as synchronization master in LLS-C1/LLS-C2
16 deployments.
17 Synchronization deployment options are defined in the [28].
18 O-RU synchronization is defined by WG4, refer for details to the [4].
19 Refer to ITU-T recommendations [26], [20], [18], [19] for details of synchronization.
20 Prerequisite is that the O-DU synchronization parameters have been provisioned to the O-DU;
21 - Before O-DU can start to synchronize its internal clock by external timing source.
22 - Before O-DU begins its function as master clock.
23 9.1 Synchronization
24 Following chapters contain main parameters required for O-DU when it is receiving synchronization from external timing
25 source. All parameters are defined in o-ran-synchronization.yang, which shall be read together with this document.
26 9.1.1 Synchronization status

27 The read-only sync-state indicates O-DU synchronization status:
28 - LOCKED: O-DU clock timing is phase-locked to a reference timing signal. Refer also to [20] definition.
29
30 - HOLDOVER: O-DU clock has lost its controlling reference input and is using stored data, acquired while in locked
31 operation, to control its output. Refer also to [20] definition.
32 Note: HOLDOVER state is optional.

33
34 - FREERUN: O-DU clock has lost its controlling reference input and the output frequency accuracy is outside of
35 required accuracy. Refer also to [20] definition.
36

1 When state of O-DU synchronization change, O-DU shall send notifyMOIAttributeValueChange notification VES event
2 about change.
4 O-DU shall raise appropriate alarm in case state change to HOLDOVER or FREERUN. O-DU shall cancel alarm when
5 state change back to LOCKED.
7 O-DU shall update information which timing source(s) O-DU is using to synchronize its own clock. O-DU shall update
8 this to ptp-status, synce-status and gnss-status containers described in following chapters.
10
11 Figure 13: Allowed sync state transitions
12 Note: HOLDOVER mode is optional and depends on internal O-DU design.
13
14 9.1.2 Synchronization capabilities

15 The read-only container sync-capability tells which timing source type(s) O-DU is capable to support.
16 9.1.3 Synchronization configuration

17 The container sync-config contains:
18 Configurable list sync-priority-config, which is priority order list to control O-DU to select timing source(s).
19 Timing source types:

1 • GNSS
2 • PTP
3 • SYNCE
4 Because SyncE only provides a frequency signal, it can only be used in combination with another timing source
5 providing phase synchronization. Specific configurable parameter synce-enabled is used to control SyncE usage.
6 9.1.4 PTP configuration

7 The container ptp-config contains:
8 - needed parameters for G.8275.1 and G.8275.2 configuration.
9 • domain-number. This indicates Domain Number for PTP announce messages.
10 • accepted-clock-classes. This is list of PTP acceptable Clock Classes
11 • delay-asymmetry. The parameter defines static phase error in the recovered PTP timing signal to be
12 compensated at the device
13 • local-priority. The parameter defines local priority.
14 PTP profile selection of G.8275.1 or G.8275.2
15 The container g-8275-1-config contains
16 - multicast-mac-address. The parameter defines the destination MAC address, used by the O-DU in the egress PTP
17 messages. Allowed values:
18 • FORWARDABLE (means that PTP shall use 01-1B-19-00-00-00 destination MAC address)
19 • NONFORWARDABLE (means that PTP shall use 01-80-C2-00-00-0E destination MAC address)
20 The container g-8275-2-config contains
21 - list master-ip-configuration. Defines list of ip configuration of devices acting as ptp signal source.
22 - ip-address. The parameter defines master IP address.
23
24 9.1.5 PTP status

25 Container ptp-status contains:
26 - reporting-period, which defines minimum time between ptp-status VES notification reports sent by O-DU.
27 - sync-source-status, which contains status of PTP as timing source;
28 • IN_USE - Indicates that this source is the current master clock, i.e. the clock, which the clock, controlled by
29 the device, is synchronized to.
30 • USABLE - Indicates that this source is an alternate master, which the clock, controlled by the device, can
31 potentially synchronize to, i.e. clock class and priority, announced by the master clock is lower, compared to
32 those of the clock, controlled by the device, and the clock class is accepted.
33 • NOT_USABLE - Indicates that this source is an alternate master, which the clock, controlled by the device,
34 has an operational connection to, but the class or priority of the master clock is higher or equal to those of
35 the clock, controlled by the device, or the clock class is not accepted.
36 • NOT_IN_USE - Indicates that this source is an alternate master, which the clock controlled by the device,
37 has no operational connection to.

1 - clock-class, which contains clock class of the clock, controlled by the O-DU
2 - clock-identity, which is received form the PTP source
3 - sources, which contains list of PTP sources per local-port-number.
4 - steps-removed, which value is received PTP Announce message stepsRemoved attribute +1.
5 - other attributes from the PTP Announce messages.
7 9.1.6 SyncE configuration

8 The container synce-config contains configuration parameters for the SyncE:
9 - acceptance-list-of-ssm, which defines SyncE SSM values acceptable.
10 - ssm-timeout, maximum duration in seconds for which the actual SSM value may be different than configured
11 values.
12 9.1.7 SyncE status

13 Container synce-status contains:
14 - reporting-period, which defines minimum time between synce-status VES notification reports sent by O-DU.
15 - sync-source-status, which contains status of SyncE as timing source;
19 potentially synchronize to, i.e. when the clock quality of the primary SyncE signal (SSM value) is lower,
20 when compared to the alternate master, controlled by the device, and the SSM value is accepted.
22 has an operational connection to, but the SSM value is not accepted (i.e clock quality is not in the acceptable
23 range).
24 • NOT_IN_USE - Indicates that this source is an alternate SyncE clock, which the clock controlled by the
25 device, has no operational connection to.
26 Note, master identity is not generally available unless ESMC is in use.
27 - sources, which contains list of SyncE sources per local-port-number, as reference to source MAC address, from
28 which the SyncE signal is received.
29 9.1.8 GNSS Configuration

30 If O-DU Yang if-feature GNSS is true and O-DU is connected to GNSS RX (e.g. having some specific non radio
31 interface, which is an example of local PRTC), then container gnss-config contains configuration parameters for the
32 GNSS:
33 - enable, which defines if GNSS receiver shall be enabled or not
34 - satellite-constellation-list, which defines list of constellations to be used to acquire synchronization;
35 • GLONASS
36 • GALILEO
37 • BEIDOU

1 • GPS
2 9.1.9 GNSS Status

3 If O-DU supports GNSS feature, then container gnss-status contains GNSS status parameters:
4 - reporting-period, which defines minimum time between gnss-status VES notification reports sent by O-DU.
5 - sync-source-status, which contains status of GNSS as timing source;
9 potentially synchronize to, i.e. clock class and priority, announced by the master clock is lower, compared to
10 those of the clock, controlled by the device, and the SSM value is accepted.
12 has an operational connection to, but the class or priority of the master clock is higher or equal to those of
13 the clock, controlled by the device, or the SSM value is not accepted.
14 • NOT_IN_USE - Indicates that this source is an alternate master, which the clock controlled by the device,
15 has no operational connection to.
16 - gnss-sync-status
17 • SYNCHRONIZED - Indicates that GNSS functionality is synchronized.
18 • ACQUIRING-SYNC - Indicates that GNSS functionality is acquiring sync.
19 • ANTENNA-DISCONNECTED - Indicates that GNSS functionality has its antenna disconnected.
20 • BOOTING - Indicates that GNSS functionality is booting.
21 • ANTENNA-SHORT-CIRCUIT - Indicates that GNSS functionality has an antenna short circuit.
22
23 9.2 Synchronization master

24 O-DU act as synchronization master for fronthaul in LLS-C1/LLS-C2 deployments. Synchronization deployment
25 options are defined in the [28].
26 Prerequisite for O-DU to act as synchronization master is that O-DU´s sync-state is LOCKED.
27 Container sync-master-capabilities contains information of O-DU capability to act as a synchronization master and
28 needed configuration parameters.
29 Following chapters contain main parameters required for O-DU acting as synchronization master. All parameters are
30 defined in o-ran-synchronization.yang, which shall be read together with this document.
31 9.2.1 Synchronization master capabilities

32 Container sync-master-capabilities contains information of O-DU capability to act as a synchronization master:
33 - ptp-sync-master-capabilities contains:
34 • ptp-sync-master-supported:
35 TRUE – O-DU can serve as PTP synchronization master.
36 FALSE – O-DU cannot serve as PTP synchronization master.

1 - synce-sync-master-capabilities contains:
2 • synce-sync-master-supported:
3 TRUE – O-DU can serve as SyncE synchronization master.
4 FALSE – O-DU cannot serve as SyncE synchronization master.
6 Note: [28] considers only SyncE + PTP.
7 9.2.2 Synchronization master configuration

8 Container sync-master-configuration contain configuration parameters for O-DU to act as a synchronization master.
9 - ptp-master-configuration contains configuration for PTP master:
10 • ptp-master-enabled-local-port-numbers. This is reference to portNumber of ExternalEthernetPort to identify

11 the port, where the PTP is provided.
12 • domain-number. This parameter indicates Domain Number for PTP announce messages.
13 • multicast-mac-address. This parameter indicates Ethernet MAC address to be used as destination address
14 (forwardable, nonforwardable)
15 • priority2. This parameter reflects value of the priority2 attribute in PTP Announce messages.
16 - synce-master-configuration contains configuration for SyncE master:
17 • synce-master-enabled-local-port-numbers. This is reference to portNumber of ExternalEthernetPort to

18 identify the port, where the SyncE is provided.
19 Note! If configuration change is applied during O-DU run time, i.e. transmission to air is ongoing, configuration change
20 may cause service interruption.
21 9.2.3 Master PTP status

22 Container ptp-master-status contains
23 - reporting-period, which defines minimum time between ptp-master-status VES notification reports sent by O-DU.
24 - ptp-status containing PTP status and PTP message attributes. Refer to [18], [21] and o-ran-synchronization.yang. In
25 case O-DU is synchronized using PTP, O-DU will forward PTP message attributes received from the sync-source
26 to master port. In case O-DU is synchronized from GNSS, O-DU shall compute locally PTP message attributes to
27 be sent on the PTP master port.
28
29 9.3 O-DU and O-RU synchronization relation with cell and carrier
30 activation / in-activation
31 9.3.1 Cell and carrier activation
32 O-DU sync-state and O-RU sync-state shall be LOCKED before O-DU is allowed to send gNB-DU Configuration
33 Update to CU, because it contains Served NR Cells To Add/Modify/Delete IE indicating cells which O-CU can activate.
34 When O-DU receives GNB-CU CONFIGURATION UPDATE including Cells to be Activated List Item IE from CU,
35 O-DU shall check that O-DU sync-state and O-RU sync-state are LOCKED before O-DU configures to O-RU the value
36 of the parameter “active” at tx-array-carrier element / rx-array-carrier element to “ACTIVE” for the carriers serving the
37 cell(s) requested to be activated.

1 If O-DU sync-state is not LOCKED, then O-DU shall not activate any cells from Cells to be Activated List Item IE. O-
2 DU shall report back to CU Cells failed to be activated list IE.
3 If O-RU(s) sync-state is not LOCKED, then O-DU shall not activate carriers related to Cells to be Activated List Item
4 IE, to those O-RU(s) which sync-state is not LOCKED. O-DU shall report back to CU Cells failed to be activated list
5 IE for cells that O-DU did not activate carrier(s) to O-RU(s).
6 9.3.2 Cell and carrier in-activation

7 When O-DU sync-state transits to FREERUN state, O-DU shall disable all carriers in all O-RUs and report to CU in
8 gNB-DU Configuration update Cells Status IE all O-DU cells as inactive.
9 When O-DU receives notification from O-RU that O-RU sync-state transit to FREERUN, O-DU shall disable all
10 carriers in that O-RU and report to CU in gNB-DU Configuration update Cells Status IE all affected cells as inactive.
11 Refer to the [28] chapter 9.4.1.3 and [4] chapter 12.3.3 for more details.
12
13 Chapter 10 Provisioning Management

14 The requirement of Provisioning Management is descirebed in Chapter2.1 Provisioning Management Services of O1
15 Interface Specification [23]. This chapter decribes the Provisioning Management for O-DU specific aspects in addition
16 to [23].
17 There are 2 models to be considered for configuration of O-DU
18 A) Hierarchical model
19 ➢ SMO configures O-DU with all instances which are necessary for O-DU and each O-RU under O-DU.
20 These instances are based on 3GPP SA5 data model specified in 3GPP TS28.541[27] and O-RAN WG4
21 Management Plane Specification [4] YANG data model.
22 Note: This spec focuses on the model as the first step.
23 B) Hybrid model
24 ➢ SMO configures O-DU with all instances which are necessary for O-DU and some O-RAN WG4
25 Management Plane Specification [4] data model instances which are necessary for each O-RU under O-
26 DU to be configured by O-DU(not by SMO). In such case, SMO configures O-RUs directly using
27 remaining [4] data model instances which don’t need to be configured via O-DU.
28 Note: The categorize of [4] data model instances (either via O-DU or not) is for further study, and this
29 spec will reflect the agreement in future relase.
30
31 10.1 Configuration for Hierarchical Model

32 10.1.1 Configuration Step
33
34 Conifiguration steps for hierarchical model are following;
35
36 Step1: SMO configures the instances to O-DU
37 Regarding the data model configured from SMO, there are 4 types;

1 1. SA5 data model
2 Following modules are necessary since these are related to O-DU. See TS28.541[27]
3 - _3gpp-common-managed-element.yang
4 - _3gpp-nr-nrm-gnbdufunction.yang
5 - _3gpp-nr-nrm-nrcelldu.yang
6 - _3gpp-nr-nrm-ep.yang
7 - _3gpp-nr-nrm-nrsectorcarrier.yang
8 - _3gpp-nr-nrm-bwp.yang
9 - _3gpp-nr-nrm-beam.yang
10 - _3gpp-nr-nrm-commonbeamformingfunction.yang
11 2. O-RAN WG5 modified model based on SA5
12 These are added prefix “o-ran-“ to the module name of SA5.
13 Note: Additional instances should be expected to be proposed to 3GPP for having alignment between 3GPP
14 and O-RAN WG5. Study on the model will be included in the next version of this specification.
15 3. O-RAN WG4 data model
16 O-RAN WG4 data model instances which cannot be mapped from SA5 data model and cannot be created by
17 O-DU’s internal logic, needs to be set from SMO to O-DU by aggregation model based on O-RAN WG4
18 data model. Which parameters needs to be configured from SMO is described in Annex D
19 4. O-RAN WG5 original data model
20 O-RAN WG5 introduces original data model in order to configure instances which are related to fronthaul
21 operation at O-DU side (such as O-DU transmission/reception window). 3GPP does not assume non
22 integrated O-DU, so O-RAN WG5 introduces original model for supporting franthaul operations.
23 Note: These modules are not expected to be proposed to 3GPP since these are for fronthaul management
24 operation and 3GPP does not assume fronthaul management. This version includes o-ran-wg5-delay-
25 management.yang. Whether other modules are necessary or not will be studied in the next version of this
26 specification.
27
28
29 Step2: O-DU configures to O-RU
30 O-DU configures to O-RU by several ways;
31 1. Mapping SA5 parameters to WG4 parameters.
32 2. Creating WG4 parameters by internal logic
33 3. Configuring based on aggregation model
34
35 These categories are specified in AnnexD.
36
37 10.1.2 Aggregation model for configuration to O-RU via SMO

38

1 In order to configure WG4 data model to O-RU via O-DU from SMO, aggregation model which has a mount point is
2 used. The following is an example of o-ran-uplane-conf.yang;
4 Aggregation model: o-ran-agg-uplane-conf.yang is prepared

5 module o-ran-agg-uplane-conf {
6 yang-version 1.1;
7 namespace "urn:o-ran:agg-uplane-conf:1.0";
8 prefix "o-ran-agg-uplane-conf";
9
10 import o-ran-aggregation-base {
11 prefix "agg";
12 }
13
14 import ietf-yang-schema-mount {
15 prefix "yangmnt";
16 }
17
18 organization "O-RAN Alliance";
19
20 contact
21 "www.o-ran.org";
22
23 description
24 "This module defines the augmentation of the base aggregation module to configure o-ran-uplane-conf.yang instances to O-RUs.
25
26 ==omitted==
27
28 augment "/agg:aggregated-o-ru/agg:aggregation" {
29 container uplane-conf-model {
30 yangmnt:mount-point "uplane-conf-root" {
31 description
32 "Root for o-ran-uplane-conf.yang model supported per O-RU instance";
33 }
34 }
35 }
36 }
37
38 SMO configures ietf-yang-schema-mount.yang in xml format for uplane configuration.
39
40 <schema-mounts>
41 <namespace>
42 <prefix> o-ran-uplane-conf</prefix>
43 <uri> urn:o-ran:uplane-conf:1.0</uri>
44 </namespace>
45 <mount-point>
46 <module> o-ran-agg-uplane-conf</module>
47 <label>uplane-conf-root</label>
48 <config>true</config>
49 <inline></inline>
50 </mount-point>
51 </schema-mounts>
52
53 SMO configures O-DU for each O-RU by using o-ran-aggregation-base.yang as below. ru-instance indicates O-RU to
54 be configured, with provided aggregated yang module.
55 <rpc xmlns=”urn:ietf:params:xml:ns:netconf:base:1.0”…>
56 <edit-config>
57 <config>
58 <aggregated-o-ru xmlns="urn:o-ran:agg-uplane-conf:1.0">
59 <aggregation>
60 <ru-instance>(mfg-name)_(model-name)_(serial-num)</ru-instance>
61 <uplane-conf-model xmlns=”urn:o-ran:agg-uplane-conf:1.0”>
62 <uplane-conf-root>
63 <user-plane-configuration xmlns=”urn:o-ran:uplane-conf:1.0”>
64 <low-level-tx-links>
65 <name>low-level-tx-links1</name>
66 …

1 </rpc>
2
3
4 id in NRCellDU should be equal to ru-instance-id of O-RU which the NRCellDU belongs to in order to link between
5 NRCelDU and O-RU.
6 After configuring from SMO, O-DU configures to each O-RU based on configured instances from SMO. O-DU
7 distinguish which O-RU to be configured by ru-instance at above xml from SMO.
9 10.2 Configuration for Hybrid model

10 This section will be described in the next version of this specification.
11 Note: This subsection will follow O-RAN WG4 O1 Alignment WI output.
12
13 10.3 Cell Activation

14 10.3.1 Hierarchical Model
15 After cell configuration and carrier configuration which are described at 10.1, SMO activates cells as
16

1 Figure 14.
3
4 Figure 14: Cell activation procedure
5 10.3.2 Hybrid Model

6 This section will be described at the next version.
7 Note: This subsection will follow O-RAN WG4 O1 Alignment WI output.
9 10.4 Notification aspect in hierarchical model

10 There are 2 topics to be specified in this specification on notification aspect;
11 - Subscribing for the O-RU notification from the SMO
12 ➢ Subscription for the O-RU notification specified in WG4 M-Plane specification [4] shall be done
13 by the O-DU and corresponding parameters values shall be stored in the aggregated model of the
14 O-RU. The SMO shall subscribe for parameters of interest changes from the O-RU aggregated
15 model.

1 - Forwarding the notification from O-RU via O-DU
2 ➢ Some of the O-RU notification specified in WG4 M-Plane specification [4] should be forwarded to
3 the SMO via the O-DU. In such case the SMO will receive notifications from the O-DU, after
4 subscribing to the parameters of interest from the O-RU aggregated model.
5 Note: Some of the notifications are not necessary to be forwarded to the SMO via the O-DU since
6 it is enough to be noticed by the O-DU. In such case it is not needed for the SMO to make
7 subscription to those parameters in the O-RU aggregated model.
9 Note: In Hybrid model, no additional description is necessary in this spec since O-RU can send notification to SMO
10 directly (no need to send notification via O-DU).
11
12 10.4.1 Subscribing for O-RU notification from SMO

13 The O-DU is responsible for representing parameters of the O-RU using aggregated YANG model. The SMO is
14 responsible of subscribing to the parameters of interest from aggregated model using subscription mechanism described
15 in O1 Interface specification [36] Chapter 2.1.9 Subscription Control.
16 10.4.2 Forwarding the notification from O-RU via O-DU

17 Once the SMO is subscribed to the parametrs of interest as described in Chapter 11.4.1 of this specification, the SMO
18 will receive notification about each value change of parameter(s) in the O-DU.
19
20 Figure 15: Notification to the SMO preceded by the O-RU notification
21

1
2 Figure 16: Notification to the SMO preceded by the O-DU <get> operation
6 Chapter 11 Fronthaul Delay Management Support

7 O-RAN WG4 [4] specifies delay management between O-DU and O-RU, where transmission of data over fronthaul is
8 governed by O-DU transmission/reception window and O-RU transmission/reception window. WG5 M-Plane needs to
9 support the function. O-RU transmission/reception window is decided by O-RU itself, and the relevant procedures and
10 data models are specified in WG4 spec [4]. This chapter addresses how O-DU transmission/reception window can be
11 determined and the relevant procedures and data models.
12
13 WG4 spec [4] does not define how O-DU transmission/reception window is determined, but this spec assumes the
14 below 2 ways.
15 A) Not Configured by M-Plane
16 ➢ O-DU determines O-DU transmission/reception window. How O-DU determines the window is up to O-
17 DU, it may be hardcoded value at O-DU, or calculated from O-RU transmission/reception window and
18 FH delay based on O-RAN WG4 CUS specification [4]
19 Note: WG4 IOT profile describes O-DU transmission/reception window values. O-DU
20 transmission/reception window can be hardcoded based on these values.

1 ➢ There is no impact to WG5 M-Plane spec since O-DU transmission/reception window is determined at
2 O-DU.
3 B) Configured by M-Plane
4 ➢ SMO configures parameters that control the O-DU transmission/reception windowby M-Plane. The SMO
5 configured parameters should be taken by the O-DU as the maximum or minimum allowed values for the
6 respective transmission/reception window parameters. Having the SMO configure maximum or
7 minimum allowed values instead of the exact value, provides necessary flexibility for the O-DU
8 implementation. SMO may take into account O-RU reported window and FH delay to determine O-DU
9 transmission/reception window. FH delay is pre-defined (Defined Transport Method) or measured
10 (Measured Transport Method).
11 ➢ There is impact to WG5 M-Plane spec where the details are described below.
12
13 Note: This version focuses on hierarchical model. Next version will include hybrid model since this scheme can be
14 extended to hybrid model.
15
16 Pre-condition
17 - M-Plane connection is established between SMO - O-DU / O-DU - O-RU
18 Post -condition
19 - Delay management between O-DU and O-RU is operational
20
21 Steps of Fronthaul delay management support are followings;
22 1. SMO sends <rpc><get><window-determine-capability> to O-DU for getting the capability of O-DU
23 2. O-DU replies the rpc with O-DU’s capability. There are 3 capabiities;
24 Not-Configured: O-DU transmission/reception window can be determined by O-DU
25 Configured: O-DU transmission/reception window can be determined by configured value from SMO
26 Both: O-DU has both capabilities, Not-Configured and Configured
27 3. SMO decides the method how O-DU transmission/reception window is determined from capability supported
28 by O-DU
29 4. SMO sends <rpc><edit-config><window-determine-method> based on the decision of step3.
30 5. In parallel with step1,2,3, O-DU gets O-RU transmission/reception window based on O-RAN WG4
31 specification [4]
32 6. If SMO directs Not-Configured as window-determine-method to O-DU at step4, O-DU

33 transmission/reception window is determined by O-DU. How O-DU determines the window is up to O-DU, it
34 may be hardcoded value at O-DU, or calculated from O-RU transmission/reception window and FH delay
35 based on O-RAN WG4 CUS spec [4]. If SMO has pre-configured FH delay, SMO sends it in rpc window-
36 determine-method for O-DU to calculate O-DU transmission/reception window.
37 7. If SMO directs Configured as window-determine-method to O-DU at step4,
38 1. SMO sends <rpc><get><o-ru-window> and/or <measured-transport-delay> to O-DU as necessary

39 (SMO may have such information apriori and may not need to get them from O-DU).
40 2. SMO determines O-DU transmission/reception window taking into account the following WG4
41 instances
42 • FH delay (pre-defined or measured)

1 - t12-min, t12-max,
2 - t34-min, t-34max
3 • O-RU transmission/reception window
4 - t2a-min-up, t2a-max-up
5 - t2a-min-cp-dl, t2a-max-cp-dl
6 - tcp-adv-dl
7 - ta3-min, ta3-max
8 - t2a-min-cp-ul, t2a-max-cp-ul
9 SMO determines the following parameters for O-DU transmission/reception window
10 • maximum-t1a-max-up:
11 ➢ the maximum allowed value of T1a_max_up
12 • minimum-t1a-min-up:
13 ➢ the minimum allowed value of T1a_min_up
14 • maximum-t1a-max-cp-dl:
15 ➢ the maximum allowed value of T1a_max_cp_dl
16 • minimum-t1a-min-cp-dl:
17 ➢ the minimum allowed value of T1a_min_cp_dl
18 • maximum-t1a-max-cp-ul:
19 ➢ the maximum allowed value of T1a_max_cp_ul
20 • minimum-t1a-min-cp-ul :
21 ➢ the minimum allowed value of T1a_min_cp_ul
22 • maximum-ta4-max:
23 ➢ the minimum allowed value of Ta4_max
24 • minimum-ta4-min:
25 ➢ the maximum allowed value of Ta4_min
26 Note: The above maximum or minimum allowed values for the respective O-DU transmission/reception
27 window parameters that the SMO determines should satisfy the relations specifed in 2.3.2 U-Plane/ C-
28 Plane Timing in O-RAN WG4 CUS-Plane Specification [4].
29 3. SMO sends <rpc><edit-config><o-du-window> with determined maximum or minimum allowed

30 values for the respective O-DU transmission/reception window parameters at the previous step.
31 4. O-DU sets O-DU transmission/reception window based on o-du-window from SMO.
32 8. If O-RU has the capability to set O-RU transmission/reception window adaptively as specified at 4.8 O-RU
33 Adaptive Delay Capability in O-RAN WG4 M-Plane spec, O-DU sends O-DU transmission/reception window
34 and FH delay to O-RU. O-RU may set O-RU transmission/reception window adaptively based on O-DU
35 transmission/reception window and FH delay.
36 9. Delay management between O-DU and O-RU is operational
37

3
4 Figure 17: Delay Management Configuration Procedure

2 Annex A Counter definition

3 [Editors note: taken from “NEC-2020.06.09-WG5-ORAN-WG5.MP.0-v00.00.03-section-6-PM-v0.5.docx”]
4 A.1 NR F1 Interface performance counters

5 A.1.1 UL PDCP PDUs transmitted via F1-U UL GTP-U tunnel
6 A.1.1.1 Performance Counter Table

Measurement Name OR.F1.UlPdcpPduTxF1UUl
Description This counter provides the number of the UL PDCP PDUs transmitted via
F1-U UL GTP-U tunnel.
It is optional counter for O-DU.
Collection Method CC (Cumulative Counter)
Condition Measurement subcounter is incremented by 1 whenever the UL PDCP
PDU is transmitted via F1 U UL GTP-u tunnel when the QCI of the UL
PDCP PDU is group of subcounter.Pmgroup.
Measurement Result Integer number (U32)
Measurement Type OR.F1.UlPdcpPduTxF1UUl.Pmgroup where
PmGroup is PmCountGroup number:
0: #0
1: #1
…
19: #19
Measurement Object Class gNBDUFunction
Switching Technology Packet Switched
Generation 5GS
Purpose Network Operator’s Traffic Engineering Community
7
8 A.1.2 UL PDCP PDU volume transmitted via F1-U UL GTP-U tunnel

Measurement Name OR.F1.UlPdcpPduVolTxF1UUl
Description This counter provides the UL PDCP PDU volume transmitted via F1-U
UL GTP-U tunnel.
NOTE: Measurement Object Class, gNBDUFunction, is different to
A.1.14.
Condition Measurement subcounter is accumulated by the volume of UL PDCP
PDU whenever the UL PDCP PDU is transmitted via F1 U UL GTP-u
tunnel when the QCI of the UL PDCP PDU is group of
subcounter.Pmgroup.
Measurement Result kilobyte (U32)
Measurement Type OR.F1.UlPdcpPduVolTxF1UUl.Pmgroup where
0: #0
1: #1
…
19: #19


Generation 5GS
1
2 A.1.3 Maximum UL PDCP PDU volume transmitted via F1-U UL GTP-U

3 tunnel

Measurement Name OR.F1.MaxUlPdcpPduVolTxF1UUl
Description This counter provides the maximum UL PDCP PDU volume transmitted
during 1s via F1-U UL GTP-U tunnel.
Collection Method SI (Status Inspection)
Condition Measurement subcounter is the maximum value of x when the QCI of
the UL PDCP PDU is group of subcounter.Pmgroup. It is assigned with
period of 1s by the volume x, if x is bigger than previously counted
volume.
x is the volume of UL PDCP PDU for every 1 second. x is incremented
by the volume of UL PDCP PDU whenever the UL PDCP PDU is
transmitted via F1 U UL GTP-u tunnel for a period of 1 second.
Measurement Type OR.F1.MaxUlPdcpPduVolTxF1UUl.Pmgroup where
0: #0
1: #1
…
19: #19
Generation 5GS
5
6 A.1.4 Minimum UL PDCP PDU volume transmitted via F1-U UL GTP-U tunnel

Measurement Name OR.F1.MinUlPdcpPduVolTxF1U
Description This counter provides the minimum UL PDCP PDU volume transmitted
during 1s via F1-U UL GTP-U tunnel.
Condition Measurement subcounter is the minimum value of x when the QCI of the
UL PDCP PDU is group of subcounter.Pmgroup. It is assigned with
period of 1s by the volume x, if x is smaller than previously counted
volume.
x is the volume of UL PDCP PDU for every 1 second. x is incremented
by the volume of UL PDCP PDU whenever the UL PDCP PDU is
transmitted via F1 U UL GTP-u tunnel for a period of 1 second.
Measurement Type OR.F1.MinUlPdcpPduVolTxF1U.Pmgroup where
0: #0
1: #1

…
19: #19
Generation 5GS
1
2 A.1.5 DL PDCP PDUs received via F1-U DL GTP-U tunnel

Measurement Name OR.F1.DlPdcpPduRxF1UDl
Description This counter provides the number of the DL PDCP PDUs received via
F1-U DL GTP-U tunnel.
Condition Measurement subcounter is incremented by 1 whenever the DL PDCP
PDU is received via F1 U DL GTP-u tunnel when the QCI of the DL
PDCP PDU is group of subcounter.Pmgroup.
Measurement Type OR.F1.DlPdcpPduRxF1UDl.Pmgroup where
0: #0
1: #1
…
19: #19
Generation 5GS
4
5 A.1.6 DL PDCP PDU volume received via F1-U DL GTP-U tunnel

Measurement Name OR.F1.DlPdcpPduVolRxF1UDl
Description This counter provides the DL PDCP PDU volume received via F1-U DL
GTP-U tunnel.
NOTE: Measurement Object Class, gNBDUFunction, is different to
A.1.15.
Condition Measurement subcounter is accumulated by the volume of DL PDCP
PDU whenever the DL PDCP PDU is received via F1 U DL GTP-u
tunnel when the QCI of the DL PDCP PDU is group of
subcounter.Pmgroup.
Measurement Type OR.F1.DlPdcpPduVolRxF1UDl.Pmgroup where
0: #0
1: #1
…
19: #19

Generation 5GS
1
2 A.1.7 Maximum DL PDCP PDU volume received via F1-U DL GTP-U tunnel

Measurement Name OR.F1.MaxDlPdcpPduVolRxF1UDl
Description This counter provides the maximum DL PDCP PDU volume received
during 1s via F1-U DL GTP-U tunnel.
Condition Measurement subcounter is the maximum value of x when the QCI of
the DL PDCP PDU is group of subcounter.Pmgroup. It is assigned with
period of 1s by the volume x, if x is bigger than previously counted
volume.
x is the volume of DL PDCP PDU for every 1 second. x is incremented
by the volume of DL PDCP PDU whenever the DL PDCP PDU is
received via F1 U DL GTP-u tunnel for a period of 1 second.
Measurement Type OR.F1.MaxDlPdcpPduVolRxF1UDl.Pmgroup where
0: #0
1: #1
…
19: #19
Generation 5GS
4
5 A.1.8 Minimum DL PDCP PDU volume received via F1-U DL GTP-U tunnel

Measurement Name OR.F1.MinDlPdcpPduVolRxF1UDl
Description This counter provides the minimum DL PDCP PDU volume received
during 1s via F1-U DL GTP-U tunnel.
Condition Measurement subcounter is the minimum value of x when the QCI of the
DL PDCP PDU is group of subcounter.Pmgroup. It is assigned with
period of 1s by the volume x, if x is smaller than previously counted
volume.
x is the volume of DL PDCP PDU for every 1 second. x is incremented
by the volume of DL PDCP PDU whenever the DL PDCP PDU is
received via F1 U DL GTP-u tunnel for a period of 1 second.
Measurement Type OR.F1.MinDlPdcpPduVolRxF1UDl.Pmgroup where
0: #0
1: #1
…
19: #19

Generation 5GS
1
2 A.1.9 Transmitted F1-C messages

Measurement Name OR.F1.TxF1CMes
Description This counter provides the number of the transmitted F1-C messages per
signal type that is non UE-associated or UE-associated signaling.
Condition Measurement subcounter is incremented by 1 whenever the F1 C-plane
message is transmitted per the signal type of the F1 C-plane message:
non UE-associated or UE-associated as subcounter.Sigtype.
Measurement Type OR.F1.TxF1CMes.Sigtype where
Sigtype is the signal type:
0: non UE-associated
1: UE-associated
Generation 5GS
4
5 A.1.10 Received F1-C messages

Measurement Name OR.F1.RxF1CMes
Description This counter provides the number of the received F1-C SCTP messages
per signal type that is non UE-associated or UE-associated signaling.
Condition Measurement subcounter is incremented by 1 whenever the F1 C-plane
message is received per the signal type of the F1 C-plane message: non
UE-associated or UE-associated as subcounter.Sigtype.
Measurement Type OR.F1.RxF1CMes.Sigtype where
Sigtype is the signal type:
0: non UE-associated
1: UE-associated
Generation 5GS
7
8 A.1.11 DL F1-U packets discarded due to NR U-Plane protocol error

Measurement Name OR.F1.DlF1UDiscardNRUProtocolError

Description This counter provides the number of the DL F1-U packets discarded due
to NR U-Plane protocol error.
It is recommended to support for O-DU.
Condition The measurement counter is incremented by 1 whenever the DL F1-U
plane packet is discarded due to NR U-plane protocol error.
Measurement Type OR.F1.DlF1UDiscardNRUProtocolError
Generation 5GS
1
2 A.1.12 DL F1-U packet loss rate

Measurement Name OR.F1.DRB.F1UPacketLossRateDl
Description This counter provides the DL F1-U packet loss rate, which is same with
TS 28.552 [x].
Condition See TS 28.552 [x]. Note that subcounter per QoS level should be
regarded as subcounter per PmGroup, and the subcounter should be
calculated per subcounter.Pmgroup.
This subcounter is calculate by Number of missing DL GTP sequence
numbers divided by Total number of DL GTP sequence numbers.
These numbers is accumulated in the measurement period.
NOTE: includes also “A.1.13 DL Packet Drop Rate in gNB-DU”
Measurement Type OR.F1.DRB.F1UPacketLossRateDl.Pmgroup where
0: #0
1: #1
…
19: #19
Generation 5GS
4
5 A.1.13 DL Packet Drop Rate in gNB-DU

Measurement Name OR.F1.DRB.RlcPacketDropRateDl
Description This counter provides the DL packet drop rate in gNB-DU, which is
same with TS 28.552 [x].
calculated per subcounter.Pmgroup.
This subcounter is calculate by Number of DL packets, for which no part
has been transmitted over the air, of a data radio bearer, that are

discarded in the gNB-DU divided by Number of DL packets for data

radio bearers that were received from gNB-CU-UP.
These numbers is accumulated in the measurement period.
Measurement Type OR.F1.DRB.RlcPacketDropRateDl.Pmgroup where
0: #0
1: #1
…
19: #19
Generation 5GS
1
2 A.1.14 UL PDCP PDU volume transmitted via F1-U UL GTP-U tunnel

Measurement Name OR.F1.UlPdcpPduCellVolTxF1UUl
Description This counter provides the UL PDCP PDU volume of the cell transmitted
via F1-U UL GTP-U tunnel.
NOTE: Measurement Object Class, NRCellDU, is different to A.1.2.
Condition Measurement counter is accumulated by the volume of UL PDCP PDU
whenever the UL PDCP PDU is transmitted from the Cell via F1 U UL
GTP-u tunnel.
Measurement Type OR.F1.UlPdcpPduCellVolTxF1UUl
Measurement Object Class NRCellDU
Generation 5GS
4
5 A.1.15 DL PDCP PDU volume received via F1-U DL GTP-U tunnel

Measurement Name OR.F1.DlPdcpPduCellVolRxF1UDl
Description This counter provides the DL PDCP PDU volume of the cell received via
F1-U DL GTP-U tunnel.
NOTE: Measurement Object Class, NRCellDU, is different to A.1.6.
Condition Measurement counter is accumulated by the volume of DL PDCP PDU
whenever the DL PDCP PDU is received to the Cell via F1 U DL GTP-u
tunnel.
Measurement Type OR.F1.DlPdcpPduCellVolRxF1UDl
Generation 5GS
7

1 A.2 NR RLC performance counters
2 A.2.1 Received UL RLC PDUs

Measurement Name OR.RLC.RxUlRlcPdu
Description This counter provides the number of the received UL RLC PDUs.
Condition Measurement subcounter is incremented by 1 whenever the UL RLC
PDU is received when the QCI of the UL RLC PDU is group of
subcounter.Pmgroup.
Measurement Type OR.RLC.RxUlRlcPdu.Pmgroup where Pmgroup is PmCountGroup
number:
0: #0
1: #1
…
19: #19
Measurement Object Class gNBDUFuncton
Generation 5GS
4
5 A.2.2 Received UL RLC PDU volume

Measurement Name OR.RLC.RxUlRlcPduVol
Description This counter provides the received UL RLC PDU volume.
Condition Measurement subcounter is incremented by the volume of the UL RLC
PDU whenever the UL RLC PDU is received when the QCI of the UL
RLC PDU is group of subcounter.Pmgroup.
Measurement Type OR.RLC.RxUlRlcPduVol.Pmgroup where Pmgroup is PmCountGroup
number:
0: #0
1: #1
…
19: #19
Generation 5GS
7
8 A.2.3 Request for UL RLC PDUs retransmission

Measurement Name OR.RLC.ReqUlRlcPduRetrans

Description This counter provides the number of the requests for UL RLC PDUs
retransmission.
PDU is received when the QCI of the UL RLC PDU is group of
subcounter.Pmgroup.
Measurement Type OR.RLC.ReqUlRlcPduRetrans.Pmgroup where Pmgroup is
PmCountGroup number:
0: #0
1: #1
…
19: #19
Generation 5GS
1
2 A.2.4 Transmitted DL RLC PDUs

Measurement Name OR.RLC.TxDlRlcPdu
Description This counter provides the number of the transmitted DL RLC PDUs.
Condition Measurement subcounter is incremented by 1 whenever the DL RLC
PDU is transmitted when the QCI of the DL RLC PDU is group of
subcounter.Pmgroup.
Measurement Type OR.RLC.TxDlRlcPdu.Pmgroup where Pmgroup is PmCountGroup
number:
0: #0
1: #1
…
19: #19
Generation 5GS
4
5 A.2.5 Transmitted DL RLC PDU volume

Measurement Name OR.RLC.TxDlRlcPduVol
Description This counter provides the transmitted DL RLC PDU volume.
It is recommendedf to support for O-DU.
Condition Measurement subcounter is incremented by the volume of the DL RLC
PDU whenever the DL RLC PDU is transmitted when the QCI of the DL

Measurement Type OR.RLC.TxDlRlcPduVol.Pmgroup where Pmgroup is PmCountGroup

number:
0: #0
1: #1
…
19: #19
Generation 5GS
1
2 A.2.6 Retransmitted DL RLC PDUs

Measurement Name OR.RLC.RxDlRlcPdu
Description This counter provides the number of the DL RLC PDUs retransmitted in
RLC layer.
PDU is retransmitted in RLC layer when the QCI of the DL RLC PDU is
group of subcounter.Pmgroup.
Measurement Type OR.RLC.RxDlRlcPdu.Pmgroup where Pmgroup is PmCountGroup
number:
0: #0
1: #1
…
19: #19
Generation 5GS
4
5 A.2.7 Retransmitted DL RLC PDU volume

Measurement Name OR.RLC.RxDlRlcPduVol
Description This counter provides the DL RLC PDU volume retransmitted in RLC
layer.
PDU whenever the DL RLC PDU is retransmitted in RLC layer when
the QCI of the DL RLC PDU is group of subcounter.Pmgroup.
Measurement Type OR.RLC.RxDlRlcPduVol.Pmgroup where Pmgroup is PmCountGroup
number:
0: #0
1: #1
…
19: #19


Generation 5GS
1
2 A.2.8 UL RLC PDUs discarded due to bearer release

Measurement Name OR.RLC.UlRlcPduDiscardBearerRel
Description This counter provides the number of the UL RLC PDUs discarded due to
bearer release.
PDU is discarded due to bearer release when the QCI of the UL RLC
PDU is group of subcounter.Pmgroup.
Measurement Type OR.RLC.UlRlcPduDiscardBearerRel.Pmgroup where Pmgroup is
0: #0
1: #1
…
19: #19
Generation 5GS
4
5 A.2.9 UL RLC PDU volume discarded due to bearer release

Measurement Name OR.RLC.UlRlcPduVolDiscardBearerRel
Description This counter provides the UL RLC PDU volume discarded due to bearer
release.
PDU whenever the DL RLC PDU is discarded due to bearer release
when the QCI of the DL RLC PDU is group of subcounter.Pmgroup.
Measurement Type OR.RLC.UlRlcPduVolDiscardBearerRel.Pmgroup where Pmgroup is
0: #0
1: #1
…
19: #19
Generation 5GS
7

1 A.2.10 UL RLC PDUs discarded due to RLC re-establishment

Measurement Name OR.RLC.UlRlcPduDiscardRlcReest
RLC re-establishment.
PDU is discarded due to RLC re-establishment when the QCI of the UL
Measurement Type OR.RLC.UlRlcPduDiscardRlcReest.Pmgroup where Pmgroup is
0: #0
1: #1
…
19: #19
Generation 5GS
3
4 A.2.11 UL RLC PDU volume discarded due to RLC re-establishment

Measurement Name OR.RLC.UlRlcPduVolDiscardRlcReest
Description This counter provides the UL RLC PDU volume discarded due to RLC
re-establishment.
PDU whenever the UL RLC PDU is discarded due to RLC re-
establishment when the QCI of the DL RLC PDU is group of
subcounter.Pmgroup.
Measurement Type OR.RLC.UlRlcPduVolDiscardRlcReest.Pmgroup where Pmgroup is
0: #0
1: #1
…
19: #19
Generation 5GS
6
7 A.2.12 UL RLC PDUs discarded due to other causes

Measurement Name OR.RLC.RlcPduDiscardOther

other causes.
PDU is discarded for reason other than bearer release and RLC re-
establishment when the QCI of the UL RLC PDU is group of
subcounter.Pmgroup.
Measurement Type OR.RLC.RlcPduDiscardOther.Pmgroup where Pmgroup is
0: #0
1: #1
…
19: #19
Generation 5GS
1
2 A.2.13 UL RLC PDU volume discarded due to other causes

Measurement Name OR.RLC.UlRlcPduVolDiscardOther
Description This counter provides the UL RLC PDU volume discarded due to other
causes.
PDU whenever the UL RLC PDU is discarded for reason other than
bearer release and RLC re-establishment when the QCI of the UL RLC
Measurement Type OR.RLC.UlRlcPduVolDiscardOther.Pmgroup where Pmgroup is
0: #0
1: #1
…
19: #19
Generation 5GS
4
5 A.2.14 DL RLC PDUs discarded due to bearer release

Measurement Name OR.RLC.DlRlcPduDiscardBearerRel
Description This counter provides the number of DL RLC PDUs discarded due to
bearer release. This counter includes DL RLC PDUs which has
transmitted or not lower layer.


PDU is discarded due to bearer release when the QCI of the DL RLC
Measurement Type OR.RLC.DlRlcPduDiscardBearerRel.Pmgroup where Pmgroup is
0: #0
1: #1
…
19: #19
Generation 5GS
1
2 A.2.15 DL RLC PDU volume discarded due to bearer release

Measurement Name OR.RLC.DlRlcduVolDiscardBearerRel
Description This counter provides the DL RLC PDU volume discarded due to bearer
release. This counter includes DL RLC PDUs which has transmitted or
not lower layer.
PDU whenever the DL RLC PDU is discarded due to bearer release
when the QCI of the DL RLC PDU is group of subcounter.Pmgroup.
Measurement Type OR.RLC.DlRlcduVolDiscardBearerRel.Pmgroup where Pmgroup is
0: #0
1: #1
…
19: #19
Generation 5GS
4
5 A.2.16 DL RLC PDUs discarded due to RLC re-establishment

Measurement Name OR.RLC.DlRlcPduDiscardRlcReest
Description This counter provides the number of the DL RLC PDUs discarded due to
RLC re-establishment. This counter includes DL RLC PDUs which has
PDU is discarded due to RLC re-establishment when the QCI of the DL

Measurement Type OR.RLC.DlRlcPduDiscardRlcReest.Pmgroup where Pmgroup is

0: #0
1: #1
…
19: #19
Generation 5GS
1
2 A.2.17 DL RLC PDU volume discarded due to RLC re-establishment

Measurement Name OR.RLC.DlRlcPduVolDiscardRlcReest
Description This counter provides the DL RLC PDU volume discarded due to RLC
re-establishment. This counter includes DL RLC PDUs which has
PDU whenever the DL RLC PDU is discarded due to RLC re-
establishment when the QCI of the DL RLC PDU is group of
subcounter.Pmgroup.
Measurement Type OR.RLC.DlRlcPduVolDiscardRlcReest.Pmgroup where Pmgroup is
0: #0
1: #1
…
19: #19
Generation 5GS
4
5 A.2.18 DL RLC PDUs discarded due to full buffer

Measurement Name OR.RLC.DlRlcSduDiscardFullBuffer
Description This counter provides the number of the DL RLC PDUs discarded due to
full buffer. This counter includes DL RLC PDUs which has transmitted
or not lower layer.
PDU is discarded due to full buffer when the QCI of the DL RLC PDU
is group of subcounter.Pmgroup.
Measurement Type OR.RLC.DlRlcSduDiscardFullBuffer.Pmgroup where Pmgroup is
0: #0
1: #1

…
19: #19
Generation 5GS
1
2 A.2.19 DL RLC PDU volume discarded due to full buffer

Measurement Name OR.RLC.DlRlcSduVolDiscardFullBuffer
Description This counter provides the DL RLC PDU volume discarded due to full
buffer. This counter includes DL RLC PDUs which has transmitted or
not lower layer.
PDU whenever the DL RLC PDU is discarded due to full buffer when
the QCI of the DL RLC PDU is group of subcounter.Pmgroup.
Measurement Type OR.RLC.DlRlcSduVolDiscardFullBuffer.Pmgroup where Pmgroup is
0: #0
1: #1
…
19: #19
Generation 5GS
4
5 A.2.20 The number of exceeding maximum RLC retransmissions

Measurement Name OR.RLC.NumExceedMaxRlcRetrans
Description This counter provides the number of received NACK for the final
retransmission in RLC layer.
Condition Measurement subcounter is incremented by 1 whenever RLC status
report including NACK for the final retransmission is received when the
QCI of the DL RLC PDU is group of subcounter.Pmgroup.
Measurement Type OR.RLC.NumExceedMaxRlcRetrans.Pmgroup where Pmgroup is
0: #0
1: #1
…
19: #19
Generation 5GS

2 A.2.21 Average delay DL in gNB-DU

Measurement Name OR.RLC.DRB.RlcSduDelayDl
Description This counter provides the average delay DL in gNB-DU, which is same
with TS 28.552 [x].
Collection Method DER (n=1)
accumulated per subcounter.Pmgroup.
Measurement Result microsecond (U32)
Measurement Type OR.RLC.DRB.RlcSduDelayDl.Pmgroup where Pmgroup is
0: #0
1: #1
…
19: #19
Generation 5GS
4
5 A.2.22 IP Latency DL in gNB-DU

Measurement Name OR.RLC.DRB.RlcSduLatencyDl
Description This counter provides the IP latency DL in gNB-DU, which is same with
TS 28.552 [x].
Measurement Type OR.RLC.DRB.RlcSduLatencyDl.Pmgroup where Pmgroup is
0: #0
1: #1
…
19: #19
Generation 5GS
7

1 A.3 NR MAC performance counters
2 A.3.1 Received UL MAC PDU volume

Measurement Name OR.MAC.RxUlMacPduVol
Description This counter provides the UL MAC PDU volume received as initial
transmission or retransmission in MAC layer.
Condition Measurement subcounter is incremented by the volume of the UL MAC
PDU whenever the UL MAC PDU is received as initial transmission or
retransmission when the SSB beam for PUSCH is the group of
subcounter.SSBBeam.
Measurement Type OR.MAC.RxUlMacPduVol.SSBBeam where SSBBeam is the SSB beam
index:
0: #0
1: #1
…
63: #63
Generation 5GS
4
5 A.3.2 Transmitted DL MAC PDU volume

Measurement Name OR.MAC.TxDlMacPduVol
Description This counter provides the DL MAC PDU volume transmitted as initial
transmission or retransmission in MAC layer.
Condition Measurement subcounter is incremented by the volume of the DL MAC
PDU whenever the DL MAC PDU is transmitted as initial transmission
or retransmission when the SSB beam for PDSCH is the group of
subcounter.SSBBeam.
Measurement Type OR.MAC.TxDlMacPduVol.SSBBeam where SSBBeam is the SSB beam
index:
0: #0
1: #1
…
63: #63
Generation 5GS
7

1 A.3.3 Average delay DL air-interface

Measurement Name OR.MAC.DRB.AirIfDelayDl
Description This counter provides the average delay DL air-interface, which is same
with TS 28.552 [x].
Measurement Type OR.MAC.DRB.AirIfDelayDl.Pmgroup where Pmgroup is
0: #0
1: #1
…
19: #19
Generation 5GS
3
4 A.4 NR UL HARQ performance counters
5 A.4.1 Distribution of PUSCH per MCS (initial transmission)

Measurement Name OR.ULHARQ.DistPuschMcsInitial
Description This counter provides the distributions of PUSCH at the initial
transmission per MCS.
Condition Measurement subcounter is incremented by 1 whenever PUSCH is
received for initial transmission when the MCS table of the PUSCH is
group of subcounter.MCSTable and when the MCS index of the PUSCH
is group of subcounter.MCSInitial.
Measurement Type OR.ULHARQ.DistPuschMcsInitial.MCSInitial.MCSTable where
MCSInitial is the MCS index for initial transmission:
0: IMCS = 0
1: IMCS = 1
…
27: IMCS = 27
MCSTable is the MCS table:
0: MCS index table 1 for PDSCH/PUSCH without transform
precoding
precoding
precoding
3: MCS index table for PUSCH with transform precoding and 64QAM
(q=1)

(q=2)
5: MCS index table 2 for PUSCH with transform precoding and
64QAM(q=1)
64QAM (q=2)
Generation 5GS
1
2 A.4.2 Distribution of PUSCH per MCS (initial transmission/CRC OK)

Measurement Name OR.ULHARQ.DistPuschMcsInitialTxCRC
Description This counter provides the distributions of the number of CRC succeeded
for PUSCH at initial transmission per MCS.
Condition Measurement subcounter is incremented by 1 whenever PUSCH of
which CRC is OK is received for initial transmission when the MCS
table of the PUSCH is group of subcounter.MCSTable and when the
MCS index of the PUSCH is group of subcounter.MCSInitial.
Measurement Type OR.ULHARQ.DistPuschMcsInitialTxCRC.MCSInitial.MCSTable where
0: IMCS = 0
1: IMCS = 1
…
27: IMCS = 27
precoding
precoding
precoding
(q=1)
(q=2)
64QAM(q=1)
64QAM (q=2)
Generation 5GS
4
5 A.4.3 Distribution of PUSCH per MCS (any/CRC OK)

Measurement Name OR.ULHARQ.DistPuschMcsAny

Description This counter provides the distributions of PUSCH at initial transmission

or retransmission per MCS.
which CRC is OK is received for initial transmission or retransmission
when the MCS table of the PUSCH is group of subcounter.MCSTable
and when the MCS index of the PUSCH is group of
subcounter.MCSRetx.
Measurement Type OR.ULHARQ.DistPuschMcsAny.MCSRetx.MCSTable where MCSRetx
is the MCS index for initial transmission:
0: IMCS = 0
1: IMCS = 1
…
31: IMCS = 31
precoding
precoding
precoding
(q=1)
(q=2)
64QAM(q=1)
64QAM (q=2)
Generation 5GS
1
2 A.4.4 Distribution of PUSCH per MCS (exceeding HARQ retransmission)

Measurement Name OR.ULHARQ.DistPuschMcsExceedHarqRetrans
Description This counter provides the distributions of the number of CRC failure for
PUSCH at final retransmission per MCS.
which CRC is NG is received for final retransmission when the MCS
table of the PUSCH is group of subcounter.MCSTable and when the
MCS index of the PUSCH is group of subcounter.MCSRetx.
Measurement Type OR.ULHARQ.DistPuschMcsExceedHarqRetrans.MCSRetx.MCSTable
where MCSRetxis the MCS index for initial transmission:
0: IMCS = 0
1: IMCS = 1
…
31: IMCS = 31


precoding
precoding
precoding
(q=1)
(q=2)
64QAM(q=1)
64QAM (q=2)
Generation 5GS
1
2 A.5 NR DL HARQ performance counters
3 A.5.1 Distribution of PDSCH per MCS (initial transmission)

Measurement Name OR.DLHARQ.DistPdschMcsInitial
Description This counter provides the distributions of PDSCH at initial transmission.
This counter excludes MU-MIMO usage.
Condition Measurement subcounter is incremented by 1 whenever PDSCH is
transmitted (except for MU-MIMO usage) for initial transmission when
the MCS table of the PDSCH is group of subcounter.MCSTable and
when the MCS index of the PDSCH is group of subcounter.MCSInitial.
Measurement Type OR.DLHARQ.DistPdschMcsInitial.MCSInitial.MCSTable where
0: IMCS = 0
1: IMCS = 1
…
27: IMCS = 27
precoding
precoding
precoding
(q=1)
(q=2)
64QAM(q=1)
64QAM (q=2)


Generation 5GS
1
2 A.5.2 Distribution of PDSCH per MCS (initial transmission/ACK)

Measurement Name OR.DLHARQ.DistPdschMcsInitialTxAck
Description This counter provides the distributions of the number of HARQ-ACK for
PDSCH at initial transmission per MCS. This counter excludes MU-
MIMO usage.
Condition Measurement subcounter is incremented by 1 whenever PDSCH (except
for MU-MIMO usage) of which CRC is OK is transmitted for initial
transmission when the MCS table of the PDSCH is group of
subcounter.MCSTable and when the MCS index of the PDSCH is group
of subcounter.MCSInitial.
Measurement Type OR.DLHARQ.DistPdschMcsInitialTxAck.MCSInitial.MCSTable where
0: IMCS = 0
1: IMCS = 1
…
27: IMCS = 27
precoding
precoding
precoding
(q=1)
(q=2)
64QAM(q=1)
64QAM (q=2)
Generation 5GS
4
5 A.5.3 Distribution of PDSCH per MCS (any/ACK)

Measurement Name OR.DLHARQ.DistPdschMcsAny
PDSCH at initial transmission or retransmission per MCS. This counter
excludes MU-MIMO usage.

Condition Measurement subcounter is incremented by 1 whenever PDSCH of

which CRC is OK is received (except for MU-MIMO usage) for initial
transmission or retransmission when the MCS table of the PDSCH is
group of subcounter.MCSTable and when the MCS index of the PDSCH
is group of subcounter.MCSRetx.
Measurement Type OR.DLHARQ.DistPdschMcsAny.MCSRetx.MCSTable where MCSRetx
0: IMCS = 0
1: IMCS = 1
…
31: IMCS = 31
precoding
precoding
precoding
(q=1)
(q=2)
64QAM(q=1)
64QAM (q=2)
Generation 5GS
1
2 A.5.4 Distribution of PDSCH per MCS (exceeding HARQ retransmission)

Measurement Name OR.DLHARQ.DistPdschMcsExceedHarqRetrans
Description This counter provides the distributions of the number of HARQ-NACK
for PUSCH at final retransmission per MCS. This counter excludes MU-
MIMO usage.
Condition Measurement subcounter is incremented by 1 whenever PDSCH of
which CRC is NG is transmitted (except for MU-MIMO usage) for final
of subcounter.MCSRetx.
Measurement Type OR.DLHARQ.DistPdschMcsExceedHarqRetrans.MCSRetx.MCSTable
where MCSRetx is the MCS index for initial transmission:
0: IMCS = 0
1: IMCS = 1
…
31: IMCS = 31
precoding

precoding
precoding
(q=1)
(q=2)
64QAM(q=1)
64QAM (q=2)
Generation 5GS
1
2 A.5.5 Distribution of PDSCH per MCS (MU-MIMO/initial transmission)

Measurement Name OR.DLHARQ.DistPdschMcsMuMimoInitialTx
Description This counter provides the distributions of PDSCH at initial transmission
in MU-MIMO usage per MCS.
transmitted (including MU-MIMO usage) for initial transmission when
the MCS table of the PDSCH is group of subcounter.MCSTable and
when the MCS index of the PDSCH is group of subcounter.MCSInitial.
Measurement Type OR.DLHARQ.DistPdschMcsMuMimoInitialTx.MCSInitial.MCSTable
where MCSInitial is the MCS index for initial transmission:
0: IMCS = 0
1: IMCS = 1
…
27: IMCS = 27
precoding
precoding
precoding
(q=1)
(q=2)
64QAM(q=1)
64QAM (q=2)
Generation 5GS
4

1 A.5.6 Distribution of PDSCH per MCS (MU-MIMO/initial transmission/ACK)

Measurement Name OR.DLHARQ.DistPdschMcsMuMimoInitialTxAck
PDSCH at initial transmission in MU-MIMO usage per MCS.
Condition Measurement subcounter is incremented by 1 whenever PDSCH is which
of CRC is OK is transmitted (including MU-MIMO usage) for initial
subcounter.MCSTable and when the MCS index of the PDSCH is group of
subcounter.MCSInitial.
Measurement Type OR.DLHARQ.DistPdschMcsMuMimoInitialTxAck.MCSInitial.MCSTable
where MCSInitial is the MCS index for initial transmission:
0: IMCS = 0
1: IMCS = 1
…
27: IMCS = 27
0: MCS index table 1 for PDSCH/PUSCH without transform precoding
(q=1)
(q=2)
64QAM(q=1)
64QAM (q=2)
Measurement Object NRCellDU
Class
Generation 5GS
3
4 A.6 NR UL Signal Quality Level performance counters
5 A.6.1 Distribution of PUSCH per MCS (Rank1)

Measurement Name OR.ULSQL.DistPuschMcsRank1
Description This counter provides the distributions of PUSCH transmitted with rank
1 per MCS.
received with Rank 1 when the MCS table of the PUSCH is group of
subcounter.MCSTable and when the MCS index of the PUSCH is group

Measurement Type OR.ULSQL.DistPuschMcsRank1.MCSRetx.MCSTable where MCSRetx

0: IMCS = 0
1: IMCS = 1
…
31: IMCS = 31
precoding
precoding
precoding
(q=1)
(q=2)
64QAM(q=1)
64QAM (q=2)
Generation 5GS
1
2 A.6.2 Distribution of PUSCH per MCS (Rank2)

Measurement Name OR.ULSQL.DistPuschMcsRank2
2 per MCS.
received with Rank 2 when the MCS table of the PUSCH is group of
subcounter.MCSTable and when the MCS index of the PUSCH is group
Measurement Type OR.ULSQL.DistPuschMcsRank2.MCSRetx.MCSTable where MCSRetx
0: IMCS = 0
1: IMCS = 1
…
31: IMCS = 31
precoding
precoding
precoding
(q=1)
(q=2)

64QAM(q=1)
64QAM (q=2)
Generation 5GS
1
2 A.6.3 Distribution of PUSCH per SSB beam (Rank1)

Measurement Name OR.ULSQL.DistPuschSsbBeamRank1
1 per SSB beam.
received with Rank 1 when the SSB beam used for the PUSCH is group
of subcounter.SSBBeam.
Measurement Type OR.ULSQL.DistPuschSsbBeamRank1.SSBBeam where SSBBeam is the
SSB beam index:
0: #0
1: #1
…
63: #63
Generation 5GS
4
5 A.6.4 Distribution of PUSCH per SSB beam (Rank2)

Measurement Name OR.ULSQL.DistPuschSsbBeamRank2
2 per SSB beam.
received with Rank 2 when the SSB beam used for the PUSCH is group
of subcounter.SSBBeam.
Measurement Type OR.ULSQL.DistPuschSsbBeamRank2.SSBBeam where SSBBeam is the
SSB beam index:
0: #0
1: #1
…
63: #63
Generation 5GS

2 A.6.5 PUSCH received power

Measurement Name OR.ULSQL.PuschRxPower
Description This counter measures the following x and provides round(x, 2)･102. x is
the statistics of received power of FL DMRS of PUSCH. This counter
obtains the power for every slot or mini slot in which PUSCH reception
is expected. The power is normalized by PRB and antenna port. If Rx
beam is created by some antenna ports, this counter is calculated with the
power of only the antenna ports used to create Rx beam.
Condition Measurement subcounter of subcounter.statistic(avg.) is calculated by
round(x/y, 2) * 102, where:
x is incremented by the volume of power of front loaded DMRS of

PUSCH whenever PUSCH reception is expected when SSB beam
used for PUSCH is group of subcounter.SSBBeam. The power is
normalized by PRB and antenna port. If Rx beam is created by
some antenna ports, this counter is calculated with the power of
only the antenna ports used to create Rx beam.
y is incremented by 1 whenever PUSCH reception is expected when
SSB beam used for PUSCH is group of subcounter.SSBBeam.
Measurement subcounter of subcounter.statistic(max/min) is

maximum/minimum number of round(z, 2) * 10 2 . It is assigned
whenever z is updated by the volume round(z, 2) * 102, if round(z, 2) *
102 is bigger/smaller than previously counted volume, where:
z is the volume of power of front loaded DMRS of PUSCH whenever

PUSCH reception is expected when SSB beam used for PUSCH is
group of subcounter.SSBBeam. The power is normalized by PRB and
antenna port. If Rx beam is created by some antenna ports, this
counter is calculated with the power of only the antenna ports used to
create Rx beam.
Measurement Result dBm/102 (S16)

Measurement Type OR.ULSQL.PuschRxPower.SSBBeam.statistic where SSBBeam is the
SSB beam index:
0: #0
1: #1
…
63: #63
statistic is
0: average
1: maximum
2: minimum
Generation 5GS
4

1 A.6.6 PUSCH RSSI

Measurement Name OR.ULSQL.PuschRssi
the statistic of the power of the REs in which PUSCH DMRS reception
is expected.
x is incremented by the volume of power of the RE which PUSCH

DMRS reception is expected whenever PUSCH reception is
expected when SSB beam used for PUSCH is group of
subcounter.SSBBeam.
y is incremented by 1 whenever PUSCH reception is expected when
SSB beam used for PUSCH is group of subcounter.SSBBeam.

maximum/minimum number of round(z, 2) * 10 2. It is assigned
z is the volume of power of the RE which PUSCH DMRS

reception is expected whenever PUSCH reception is expected
when SSB beam used for PUSCH is group of
subcounter.SSBBeam.
Measurement Type OR.ULSQL.PuschRssi.SSBBeam.statistic where SSBBeam is the SSB
beam index:
0: #0
1: #1
…
63: #63
statistic is
0: average
1: maximum
2: minimum
Generation 5GS
3
4 A.6.7 PUSCH SINR

Measurement Name OR.ULSQL.PuschSinr
the statistics of PUSCH with 2 dB bin of SINR of UE specific PUSCH.


x is incremented by the volume of SINR of the UE specific

PUSCH when SSB beam used for PUSCH is group of
subcounter.SSBBeam and when MIMO layer of the PUSCH is
group of subcounter.MIMO.
y is incremented by 1 whenever PUSCH which power detection check
is OK is received when SSB beam used for PUSCH is group of
subcounter.SSBBeam and when MIMO layer of the PUSCH is
group of subcounter.MIMO.
z is the volume of SINR of the UE specific PUSCH when SSB

beam used for PUSCH is group of subcounter.SSBBeam and when
MIMO layer of the PUSCH is group of subcounter.MIMO.
Measurement Result dB/102 (S16)
Measurement Type OR.ULSQL.PuschSinr.SSBBeam.MIMO.statistic where SSBBeam is the
SSB beam index:
0: #0
1: #1
…
63: #63
MIMO is the number of MIMO layer:

0: 1 layer
1: 2 layer
…
7: 8 layer
statistic is
0: average
1: maximum
2: minimum

Generation 5GS
1
2 A.6.8 PUCCH RSSI

Measurement Name OR.ULSQL.PucchRssi
the statistics of the power of the REs in which PUCCH DMRS reception
is expected.

x is incremented by the volume of power of the RE which PUCCH

DMRS reception is expected whenever PUCCH reception is
expected when SSB beam used for PUCCH is group of
subcounter.SSBBeam.
y is incremented by 1 whenever PUCCH reception is expected when
SSB beam used for PUCCH is group of subcounter.SSBBeam.

z is the volume of power of the RE which PUCCH DMRS

reception is expected whenever PUCCH reception is expected
when SSB beam used for PUCCH is group of
subcounter.SSBBeam.

Measurement Type OR.ULSQL.PucchRssi.SSBBeam.statistic where SSBBeam is the SSB
beam index:
0: #0
1: #1
…
63: #63
statistic is
0: average
1: maximum
2: minimum
Generation 5GS
1
2 A.6.9 PUCCH SINR

Measurement Name OR.ULSQL.PucchSinr
the statistics of SINR of UE specific PUCCH.
x is incremented by the volume of SINR of the UE specific

PUCCH when SSB beam used for PUCCH is group of
subcounter.SSBBeam.
y is incremented by 1 whenever PUCCH which power detection check
is OK is received when SSB beam used for PUCCH is group of
subcounter.SSBBeam.

z is the volume of SINR of the UE specific PUCCH when SSB

beam used for PUCCH is group of subcounter.SSBBeam.
Measurement Type OR.ULSQL.PucchSinr.SSBBeam.statistic where SSBBeam is the SSB
beam index:
0: #0
1: #1
…
63: #63
statistic is
0: average
1: maximum
2: minimum
Generation 5GS
1
2 A.6.10 PRACH preamble correlation value

Measurement Name OR.ULSQL.PrachPreambleCorrelationValue
Description This counter measures the following x and provides round(x, 2) ･102. x
is the statistics of the correlation value among preambles of the PRB
where PRACH preabmble is detected. This counter normalized by PRB.
x is incremented by the correlation volume among preambles of

the PRB whenever PRACH preamble is detected when SSB beam
used for PRACH is group of subcounter.SSBBeam.
y is incremented by 1 whenever PRACH preamble is detected when
SSB beam used for PRACH is group of subcounter.SSBBeam.
z is the correlation volume among preambles of the PRB whenever

PRACH preamble is detected when SSB beam used for PRACH is
group of subcounter.SSBBeam.

Measurement Type OR.ULSQL.PrachPreambleCorrelationValue.SSBBeam.statistic where
SSBBeam is the SSB beam index:
0: #0
1: #1
…
63: #63
statistic is
0: average
1: maximum
2: minimum


Generation 5GS
1
2 A.6.11 RSSI of PRACH transmission occasion

Measurement Name OR.ULSQL.RssiPrachTxOccasion
is the statistics of the RACH occasion RSSI. This counter is normalized
by PRB.
x is incremented by the volume of RSSI at every PRACH occasion

when SSB beam used for PRACH is group of
subcounter.SSBBeam.
y is incremented by 1 at every PRACH occasion when SSB beam
used for PRACH is group of subcounter.SSBBeam.
z is the volume of RSSI at every PRACH occasion when SSB

beam used for PRACH is group of subcounter.SSBBeam.
Measurement Type OR.ULSQL.RssiPrachTxOccasion.SSBBeam.statistic where SSBBeam is
the SSB beam index:
0: #0
1: #1
…
63: #63
statistic is
0: average
1: maximum
2: minimum
Generation 5GS
4
5 A.6.12 Distribution of path loss for FR1

Measurement Name OR.ULSQL.DistPathlossFr1
Description This counter provides the distributions of PUSCH including PHR with a
certain bin of the pathloss. This counter is for FR1.


Condition This subcounter is measured only when the cell uses FR1.
Measurement subcounter is incremented by 1 whenever PHR is received
when the SSB beam used for the PUSCH is group of
subcounter.SSBBeam and when the pathloss calculated with the PHR is
group of subcounter.binX.
Measurement Type OR.ULSQL.DistPathlossFr1.SSBBeam.binX where SSBBeam is the SSB
beam index:
0: #0
1: #1
…
63: #63
binX is the bin of the pathloss, x.
Bin1: 0 dB ≤ x < 40 dB
Bin2: 40 dB ≤ x < 45 dB
Bin3: 45 dB ≤ x < 50 dB
…
Bin25: 155 dB ≤ x
Generation 5GS
1
2 A.6.13 Path loss for FR2

Measurement Name OR.ULSQL.PathlossFr2
the statistics of the pathloss. This counter is for FR2.
Measurement subcounter of subcounter.statistic(avg.) is calculated by

x is incremented by the volume of the pathloss calculated with PHR

whenever PHR is received when the SSB beam used for the PUSCH is
y is incremented by 1 whenever PHR is received when the SSB beam

used for the PUSCH is group of subcounter.SSBBeam

z is the volume of the pathloss calculated with PHR whenever PHR is

received when the SSB beam used for the PUSCH is group of
subcounter.SSBBeam.

Measurement Type OR.ULSQL.PathlossFr2.SSBBeam.statistic where SSBBeam is the SSB
beam index:

0: #0
1: #1
…
63: #63
statistic is
0: average
1: maximum
2: minimum
Generation 5GS
1
2 A.6.14 Detection of UL out-of-sync.

Measurement Name OR.ULSQL.DetectUlOutSync
Description This counter provides the number of the detection of UL out-of-sync for
bearer type change from SN terminated split bearer to SN terminated
MCG bearer or SgNB release.
Condition Measurement subcounter is incremented by 1 whenever the UL out-of-
sync is detected per SSB beam index of the UE: #0, #1, …, #63 as
subcounter.SSBBeam.
Measurement Type OR.ULSQL.DetectUlOutSync.SSBBeam where SSBBeam is the SSB
beam index:
0: #0
1: #1
…
63: #63
Generation 5GS
4
5 A.7 NR DL Signal Quality Level performance counters
6 A.7.1 Distribution of PDSCH per MCS (Rank1)

Measurement Name OR.DLSQL.DistPdschMcsRank1
Description This counter provides the distributions of PDSCH transmitted with rank
1 per MCS.
transmitted with Rank 1 when the MCS table of the PDSCH is group of

Measurement Type OR.DLSQL.DistPdschMcsRank1.MCSRetx.MCSTable where MCSRetx

0: IMCS = 0
1: IMCS = 1
…
31: IMCS = 31
precoding
precoding
precoding
(q=1)
(q=2)
64QAM(q=1)
64QAM (q=2)
Generation 5GS
1

2 per MCS.
0: IMCS = 0
1: IMCS = 1
…
31: IMCS = 31
precoding
precoding
precoding
(q=1)
(q=2)

64QAM(q=1)
64QAM (q=2)
Generation 5GS
1

3 per MCS.
0: IMCS = 0
1: IMCS = 1
…
31: IMCS = 31
precoding
precoding
precoding
3: MCS index table for PUSCH with transform precoding and
Generation 5GS
4

4 per MCS.


0: IMCS = 0
1: IMCS = 1
…
31: IMCS = 31
precoding
precoding
precoding
3: MCS index table for PUSCH with transform precoding and
Generation 5GS
1
2 A.7.5 Distribution of PDSCH per SSB beam (Rank1)

Measurement Name OR.DLSQL.DistPdschSsbBeamRank1
1 per SSB beam.
transmitted with Rank 1 when the SSB beam used for the PDSCH is
Measurement Type OR.DLSQL.DistPdschSsbBeamRank1.SSBBeam where SSBBeam is the
SSB beam index:
0: #0
1: #1
…
63: #63
Generation 5GS
4

2 per SSB beam.


SSB beam index:
0: #0
1: #1
…
63: #63
Generation 5GS
1

3 per SSB beam.
SSB beam index:
0: #0
1: #1
…
63: #63
Generation 5GS
4

4 per SSB beam.
SSB beam index:
0: #0
1: #1
…
63: #63


Generation 5GS
1
2 A.7.9 Distribution of Wideband CQI for FR1

Measurement Name OR.DLSQL.DistWidebandCqiFR1
Description This counter provides the distributions of the wideband CQI reports.
Measurement subcounter is incremented by 1 whenever CQI report is
received when the SSB beam index used for the CQI report is group of
subcounter.SSBBeam, when the CQI table of the CQI report is group of
subcounter.CQITable and when the CQI is group of subcounter.CQI.
Measurement Type OR.DLSQL.DistWidebandCqiFR1.SSBBeam.CQITable.CQI where
0: #0
1: #1
…
63: #63
CQITable is the CQI table:
0: table 1
1: table 2
CQI is the CQI index:
0: CQI index 0
1: CQI index 1
…
15: CQI index 15
Generation 5GS
4
5 A.7.10 Wideband CQI for FR2

Measurement Name OR.DLSQL.WidebandCqiFR2
the statistics of linear value of the wideband CQI reports.
Measurement subcounter of subcounter.statistic(avg.) is calculated by

x is incremented by the volume of CQI whenever CQI report is

received when the SSB beam index used for the CQI report is group of

subcounter.SSBBeam and when the CQI table of the CQI report is

group of subcounter.CQITable.
y is incremented by 1 whenever CQI report is received when the SSB

beam index used for the CQI report is group of subcounter.SSBBeam
and when the CQI table of the CQI report is group of
subcounter.CQITable.

z is the volume of CQI whenever CQI report is received when the

SSB beam index used for the CQI report is group of
subcounter.SSBBeam and when the CQI table of the CQI report is
group of subcounter.CQITable.
Measurement Result CQI/102 (S16)

Measurement Type OR.DLSQL.WidebandCqiFR2.SSBBeam.CQITable.statistic where
0: #0
1: #1
…
63: #63
CQITable is the CQI table:
0: table 1
1: table 2
statistic is
0: average
1: maximum
2: minimum
Generation 5GS
1
2 A.7.11 PDCCH transmission power

Measurement Name OR.DLSQL.PdcchTxPower
is the statistics of transmission power determined by outer-loop TPC of
UE specific PDCCH. If PDCCH is transmitted within some OFDM
symbols with same SSB beam in one slot, this counter counts 1 sample
and calculates power as linear average within OFDM symbols. If
PDCCH is transmitted with different SSB beam each OFDM symbols in
the one slot, this counter counts the PDCCH for each SSB beam, and
doesn't calculate power as average within OFDM symbols.
x is incremented by the volume of transmission power of PDCCH

whenever PDCCH is transmitted when SSB beam used for
PDCCH is group of subcounter.SSBBeam and when the DCI

format of transmitted DCI is group of subcounter.DCI. If PDCCH is

transmitted within plural OFDM symbols with same SSB beam in one
slot, the volume is linear average within the OFDM symbols. If
PDCCH is transmitted with different SSB beam in each OFDM
symbols in the one slot, x is incremented for each one.
y is incremented by 1 whenever PDCCH is transmitted when SSB
beam used for PDCCH is group of subcounter.SSBBeam and when
the DCI format of transmitted DCI is group of subcounter.DCI. If
PDCCH is transmitted within plural OFDM symbols with same SSB
beam in one slot, y is only incremented once per slot. If PDCCH is
transmitted with different SSB beam in each OFDM symbols in the
one slot, y is incremented once per OFDM symbol.
maximum/minimum number of round(z, 2) * 102. It is assigned
z is the volume of transmission power of PDCCH whenever

PDCCH is transmitted when SSB beam used for PDCCH is group
of subcounter.SSBBeam and when the DCI format of transmitted
DCI is group of subcounter.DCI. If PDCCH is transmitted within
plural OFDM symbols with same SSB beam in one slot, the volume is
linear average within OFDM symbols. If PDCCH is transmitted with
different SSB beam in each OFDM symbols in the one slot, z is once
per OFDM symbol.

Measurement Type OR.DLSQL.PdcchTxPower.SSBBeam.DCI.statistic where SSBBeam is
the SSB beam index:
0: #0
1: #1
…
63: #63
DCI is the DCI format:
0: 0_0
1: 0_1
2: 1_0
3: 1_1
statistic is
0: average
1: maximum
2: minimum
Generation 5GS
1
3 A.8 NR Beamforming performance counters
4 A.8.1 Distribution of UEs per beam index

Measurement Name OR.BF.DistUeBeamIndex

Description This counter provides distribution of the UEs with beam index. This
counter obtains the number of the UEs every 100 ms.
This is recommended to support for O-DU.
Condition Measurement subcounter is incremented by the number of the UEs per
SSB beam index of the UE: #0, #1, …, #63 as subcounter.SSBBeam.
The number is acquired as an instantaneous value at every 100ms.
Measurement Type OR.BF.DistUeBeamIndex.SSBBeam where
0: #0
1: #1
..
63: #63
Generation 5GS
1
2 A.8.2 Best and Second Best Beam distribution

Measurement Name OR.BF.BestSecondBestBeamDist
Description This counter provides the distribution of Best and Second best beams.
This counter is only updated when number of SSB beam is 8 or less.
This is optional counter for O-DU.
Condition Measurement subcounter is incremented by the number of the UEs per
the best and second best SSB beam index of the UE: best beam #0 and
second beam #0, best beam #1 and second beam #0, …, best beam#7 and
second beam#7 as subcounter.binX.
The value for a given bin shall be incremented when either best or
second best beam is changed for any reason.
Measurement Type OR.BF.BestSecondBestBeamDist.binX where
Bin1 is best beam #0 and second beam #0.
Bin2 is best beam #1 and second beam #0.
:
BinX is best beam #a and second beam #b. :X = a+8b+1
:
Bin64 is best beam#7 and second beam#7.
Generation 5GS
4
5 A.8.3 UE reported differential L1-RSRP of second best beam

Measurement Name OR.BF.UeReportedDisffL1RsrpSecondBestBeam
Description This counter provides the distribution of the UE reported differential L1-
RSRP of second best beam.


Condition Measurement subcounter is incremented by 1 whenever L1-RSRP report
is received when the differential L1-RSRP of second best beam is group
of subcounter.bin.
Measurement Type OR.BF.UeReportedDisffL1RsrpSecondBestBeam.binX where binX
corresponds to the UE reported differential L1-RSRP, x, of second best
beam
Bin1: 0 ≤ x < 2 dB
Bin2: 2 dB ≤ x < 4 dB
...
Bin16: 30 dB ≤ x
Generation 5GS
1
2 A.9 NR RACH Usage performance counters
3 A.9.1 Received preambles in group A

Measurement Name OR.RACH.RxPreamblesGroupA
Description This counter provides the number of the received random preambles of
group A.
Condition Measurement subcounter is incremented by 1 whenever random
preamble of group A is received when the SSB beam which is used for
preamble transmission is group of subcounter.SSBBeam.
Measurement Type OR.RACH.RxPreamblesGroupA.SSBBeam where SSBBeam is the SSB
beam index:
0: #0
1: #1
…
63: #63
Generation 5GS
5
6 A.9.2 The number of received dedicated preamble

Measurement Name OR.RACH.NumRxDedictedPreamble
Description This counter provides the number of the received dedicated preambles.
Condition Measurement subcounter is incremented by 1 whenever dedicated
preamble is received when the SSB beam which is used for preamble
transmission is group of subcounter.SSBBeam.


Measurement Type OR.RACH.NumRxDedictedPreamble.SSBBeam where SSBBeam is the
SSB beam index:
0: #0
1: #1
…
63: #63
Generation 5GS
1
2 A.9.3 Transmitted RARs for preamble in group A

Measurement Name OR.RACH.TxRarPreambleGroupA
Description This counter provides the number of the transmitted RAR for preambles
of group A.
Condition Measurement subcounter is incremented by 1 whenever RAR for
preamble of group A is transmitted when the SSB beam which is used
for RAR transmission is group of subcounter.SSBBeam.
Measurement Type OR.RACH.TxRarPreambleGroupA.SSBBeam where SSBBeam is the
SSB beam index:
0: #0
1: #1
…
63: #63
Generation 5GS
4
5 A.9.4 Transmitted RARs for dedicated preamble

Measurement Name OR.RACH.TxRarDedicatedPreamble
Description This counter provides the number of the transmitted RAR for dedicated
preambles.
Condition Measurement subcounter is incremented by 1 whenever RAR for
dedicated preamble is transmitted when the SSB beam which is used for
RAR transmission is group of subcounter.SSBBeam.
Measurement Type OR.RACH.TxRarDedicatedPreamble.SSBBeam where SSBBeam is the
SSB beam index:
0: #0
1: #1
…
63: #63


Generation 5GS
1
2 A.9.5 Failures at assignment of dedicated preamble

Measurement Name OR.RACH.FailAssignmentDedicatedPreamble
Description This counter provides the number of indicating to use random preamble
due to NG of dedicated preamble delivery.
Condition Measurement subcounter is incremented by 1 whenever RA procedure
using random preamble is triggered due to NG of dedicated preamble
assignment when the SSB beam which is used for random preamble
transmission is group of subcounter.SSBBeam.
Measurement Type OR.RACH.FailAssignmentDedicatedPreamble.SSBBeam where
0: #0
1: #1
…
63: #63
Generation 5GS
4
5 A.9.6 Occasions for dedicated preamble reception

Measurement Name OR.RACH.OccasionDedicatedPreambleRx
Description This counter provides the number of the occasions for dedicated
preamble. If multiple dedicated preambles are assigned, this counter
calculated as the number of assigned preambles.
Condition Measurement subcounter is incremented by the number of assigned
preambles whenever dedicated preamble(s) are expected to be received
when the SSB beam which is used for random preamble transmission is
Measurement Type OR.RACH.OccasionDedicatedPreambleRx.SSBBeam where SSBBeam is
the SSB beam index:
0: #0
1: #1
…
63: #63
Generation 5GS

2 A.10 NR Timing Advance performance counters
3 A.10.1 Distribution of NTA value of RAR message

Measurement Name OR.TA.DistNtaRarMessage
Description This counter provides the distributions of RARs with the bin of N TA
value described the following. The bin type is selected corresponding to
CellSize.
Condition Measurement subcounter is incremented by 1 whenever RAR is
transmitted when the SSB beam index used for the RAR is group of
subcounter.SSBBeam and when the NTA is group of subcounter.binX.
Measurement Type OR.TA.DistNtaRarMessage.SSBBeam.binX where
0: #0
1: #1
..
63: #63
binX depends on cellSize below:
CellSize = large:
bin1: 0 ≤ NTA < 72765
bin2: 72765 ≤ NTA < 145530
...
bin10: 654885 ≤ NTA
CellSize = middle:
bin1: 0 ≤ NTA < 29106
bin2: 29106 ≤ NTA < 58212
...
bin10: 261954 ≤ NTA
CellSize = small:
bin1: 0 ≤ NTA < 728
bin2: 728 ≤ NTA < 1456
...
bin10: 6552 ≤ NTA
CellSize = Very small:
Reserved
Generation 5GS
5
6 A.11 NR Cell Utilization performance counters (Type A)
7 A.11.1 Slots at which PDCCH resource shortage occurred

Measurement Name OR.CellUA.SlotPdcchResourceShortageOccurred

Description This counter provides the number of the slots when PDCCH shortage
occurred.
Condition Measurement subcounter is incremented by 1 at every slot in whcih CCE
resource shortage restricts the multiplexing number of PDCCH at least
once.
Measurement Type OR.CellUA.SlotPdcchResourceShortageOccurred
Generation 5GS
1
2 A.11.2 Canceled DCI due to PDCCH resource shortage

Measurement Name OR.CellUA.CancelDciPdcchResourceShortage
Description This counter provides the number of the cancels of DCI transmission due
to PDCCH resource shortage.
Condition Measurement subcounter is incremented by the number of DCI which is
canceled due to CCE resource shortage whenever CCE resource shortage
restricts the multiplexing number of PDCCH.
Measurement Type OR.CellUA.CancelDciPdcchResourceShortage
Generation 5GS
4
5 A.11.3 Maximum UEs buffering UL/DL data

Measurement Name OR.CellUA.MaxUeBufferUlDlData
Description This counter obtains the number of UEs buffering UL/DL data every 100
ms and provides the maximum number of each 100 ms.
Condition Measurement subcounter is the maximum number of x. It is assigned
with period of 100ms by the volume x, if x is bigger than previously
counted volume.
x is the number of the UEs which have UL and/or DL data which is
group of subcounter.Pmgroup. x is acquired as an instantaneous value at
every 100ms.
Measurement Type OR.CellUA.MaxUeBufferUlDlData.Pmgroup where Pmgroup is
0: #0
1: #1
…
19: #19


Generation 5GS
1
2 A.11.4 Maximum UEs buffering UL data

Measurement Name OR.CellUA.MaxUeBufferUlData
Description This counter obtains the number of UEs buffering UL data every 100 ms
and provides the maximum number of each 100 ms.
counted volume.
x is the number of UEs which has UL data with subcounter.Pmgroup. x
is and is acquired as an instantaneous value at every 100ms.
Measurement Type OR.CellUA.MaxUeBufferUlData.Pmgroup where Pmgroup is
0: #0
1: #1
…
19: #19
Generation 5GS
4
5 A.11.5 Maximum UEs buffering DL data

Measurement Name OR.CellUA.MaxUeBufferDlData
Description This counter obtains the number of UEs buffering DL data every 100 ms
counted volume.
x is the number of UEs which has DL data with subcounter.Pmgroup. x
is acquired as an instantaneous value at every 100ms.
Measurement Type OR.CellUA.MaxUeBufferDlData.Pmgroup where Pmgroup is
0: #0
1: #1
…
19: #19
Generation 5GS


1
2 A.11.6 Multiplexed transmissions of PUSCH

Measurement Name OR.CellUA.MultiplexTxPusch
Description This counter provides the accumulated number of the multiplication
number of PUSCH.
Condition Measurement subcounter is incremented by 1 at every slot in which
PDSCH is recieved when the multiplexed number in frequency domain
is group of subcounter.mux.
Measurement Type OR.CellUA.MultiplexTxPusch.mux where mux is the number of
multiplex:
0: 1 multiplex
1: 2 multiplex to 5 multiplex
3: more than 12 multiplex
Generation 5GS
4
5 A.11.7 Multiplexed receptions of PDSCH

Measurement Name OR.CellUA.MultiplexRxPdsch
Description This counter provides the accumulated number of the multiplication
number of PDSCH.
Condition Measurement subcounter is incremented by 1 when PDSCH is recieved
when the multiplexed number in frequency domain is group of
subcounter.mux.
Measurement Type OR.CellUA.MultiplexRxPdsch.mux where mux is the number of
multiplex:
0: 1 multiplex
3: more than 12 multiplex
Generation 5GS
7

1 A.11.8 Maximum DRX inactive UEs

Measurement Name OR.CellUA.MaxDrxInactiveUe
Description This counter obtains the number of UEs configured as DRX inactive
every 100 ms and provides the maximum number of each 100 ms.
Condition Measurement subcounter is the minimum number of x. It is assigned
counted volume.
x is the number of UEs of which drx-InactibityTimer is assumed to be
running. x is acquired as an instantaneous value at every 100ms.
Measurement Type OR.CellUA.MaxDrxInactiveUe
Generation 5GS
3
4 A.11.9 Maximum DRX active UEs

Measurement Name OR.CellUA.MaxDrxActiveUe
Description This counter obtains the number of UEs configured as DRX active every
100 ms and provides the maximum number of each 100 ms.
counted volume.
x is the number of UEs which is configured drx-confing and of which
drx-InactibityTimer is assumed not to be running. x is acquired as an
instantaneous value at every 100ms.
Measurement Type OR.CellUA.MaxDrxActiveUe
Generation 5GS
6
7 A.11.10 Distribution of trafficInactivityTimer

Measurement Name OR.CellUA.DistTrafficInactiveTimer
Description This counter provides the distribution of the UEs whose
trafficInactivityTimer is running with 1 s bin of the
trafficInactivityTimer. trafficInactivityTimer measures the consecutive
time when no UL/DL data for the UE is available. This counter obtains
the number of UEs every 1 m.


Condition Measurement subcounter is incremented by the number of UEs whose
trafficInactivityTimer is in the value of the subcounter.binX.
The number is acquired as an instantaneous value at every 1 minutes.
Measurement Type OR.CellUA.DistTrafficInactiveTimer.binX where
bin 1: 0 s ≤ trafficInactivityTimer< 1 s
bin 9: 128 s ≤ trafficInactivityTimer
Generation 5GS
1
2 A.11.11 Slots in which scheduler assigned as mini slot

Measurement Name OR.CellUA.SlotSchedulerAssignMiniSlot
Description This counter provides the number of slots with mini slot scheduling. This
counter is for FR2.
Condition Measurement subcounter is incremented by 1 at every slot in which
PDSCH which is multiplexed in time domain in a slot is assigned.
Measurement Type OR.CellUA.SlotSchedulerAssignMiniSlot
Generation 5GS
4
5 A.11.12 Mini slots in which PUSCH was received

Measurement Name OR.CellUA.MiniSlotsPuschRx
Description This counter provides the number of mini slots when PUSCH is
received.
Condition Measurement subcounter is incremented by 1 when PUSCH which is
multiplexed in time domain in a slot is assigned.
Measurement Type OR.CellUA.MiniSlotsPuschRx
Generation 5GS

2 A.11.13 UEs in the cell using this cell as PSCell or having activated SCell in DL

Measurement Name OR.CellUA.UeCellPscellActiveScellDl
Description This counter provides the accumulated number of the UEs in the cell
using this cell as PSCell or having activated SCell in DL. This counter
obtains the number of the UEs every 100 ms.
Condition Measurement subcounter is incremented by the number of the UEs
which using this cell as PSCell or activate SCell in DL.
Measurement Type OR.CellUA.UeCellPscellActiveScellDl
Generation 5GS
4
5 A.11.14 UEs in the cell using this cell as PSCell or having activated SCell in UL

Measurement Name OR.CellUA.UeCellPscellActiveScellUl
Description This counter provides the accumulated number of the UEs in the cell
using this cell as PSCell or having activated SCell in UL. This counter
obtains the number of the UEs every 100 ms.
which using this cell as PSCell or activate SCell in UL.
Measurement Type OR.CellUA.UeCellPscellActiveScellUl
Generation 5GS
7
8 A.11.15 Distribution of PSCell UEs with X activated SCells in UL

Measurement Name OR.CellUA.DistPscellUeXactiveScellUl
Description This counter provides the distribution of the PSCell UE with the number
of activated SCell in UL. This counter obtains the number of the UEs
every 100 ms.

Condition Measurement subcounter is incremented by the number of the UE

configured this cell as PSCell per the number of activated SCell in UL: 1
active SCell,, 2 active SCell, …, 31 active SCell as subcounter.SCell.
Measurement Type OR.CellUA.DistPscellUeXactiveScellUl.NumScell where NumScell is
the number of active SCell:
0: 1 active SCell
1: 2 active SCell
…
30: 31 active SCell
Generation 5GS
1
2 A.11.16 Distribution of PSCell UEs with X activated SCells in DL

Measurement Name OR.CellUA.DistPscellUeXactiveScellDl
Description This counter provides the distribution of the PSCell UEs with the
number of activated SCell in DL. This counter obtains the number of the
UEs every 100 ms.
Condition Measurement subcounter is incremented by the number of the UE
configured this cell as PSCell per the number of activated SCell in DL: 1
active SCell,, 2 active SCell, …, 31 active SCell as subcounter.SCell.
Measurement Type OR.CellUA.DistPscellUeXactiveScellDl.NumScell where NumScell is
the number of active SCell:
0: 1 active SCell
1: 2 active SCell
…
30: 31 active SCell
Generation 5GS
4
5 A.11.17 Maximum amount of PSCell UEs (UL)

Measurement Name OR.CellUA.MaxPscellUeUl
Description This counter obtains the number of the PSCell UEs for UL every 100 ms
counted volume.

x is the number of UE configured this cell as PSCell per the number of

activated SCell in UL: 1 active SCell,, 2 active SCell, …, 31 active SCell
as subcounter.SCell. x is acquired as an instantaneous value at every
100ms.
Measurement Type OR.CellUA.MaxPscellUeUl.NumScell where NumScell is the number of
active SCell:
0: 1 active SCell
1: 2 active SCell
…
30: 31 active SCell
Generation 5GS
1
2 A.11.18 Minimum amount of PSCell UEs (UL)

Measurement Name OR.CellUA.MinPscellUeUl
Description This counter obtains the number of the PSCell UEs for UL every 100 ms
and provides the minimum number of each 100 ms.
with period of 100ms by the volume x, if x is smaller than previously
counted volume.
x is the number of the UE configured this cell as PSCell per the number
of activated SCell in UL: 1 active SCell,, 2 active SCell, …, 31 active
SCell as subcounter.SCell. x is acquired as an instantaneous value at
every 100ms.
Measurement Type OR.CellUA.MinPscellUeUl.NumScell where NumScell is the number of
active SCell:
0: 1 active SCell
1: 2 active SCell
…
30: 31 active SCell
Generation 5GS
4
5 A.11.19 Maximum amount of PSCell UEs (DL)

Measurement Name OR.CellUA.MaxPscellUeDl
Description This counter obtains the number of the PSCell UEs for DL every 100 ms


counted volume.
of activated SCell in DL: 1 active SCell,, 2 active SCell, …, 31 active
every 100ms.
Measurement Type OR.CellUA.MaxPscellUeDl.NumScell where NumScell is the number of
active SCell:
0: 1 active SCell
1: 2 active SCell
…
30: 31 active SCell
Generation 5GS
1
2 A.11.20 Minimum amount of PSCell UEs (DL)

Measurement Name OR.CellUA.MinPscellUeDl
Description This counter obtains the number of the PSCell UEs for DL every 100 ms
and provides the minimum number of each 100 ms.
with period of 100ms by the volume x, if x is smaller than previously
counted volume.
of activated SCell in DL: 1 active SCell,, 2 active SCell, …, 31 active
every 100ms.
Measurement Type OR.CellUA.MinPscellUeDl.NumScell where NumScell is the number of
active SCell:
0: 1 active SCell
1: 2 active SCell
…
30: 31 active SCell
Generation 5GS
4
5 A.11.21 Activation/Deactivation MAC CE (SCell Active)

Measurement Name OR.CellUA.ActDeactMacCeScellAct
Description This counter provides the number of the Activation/Deactivation MAC
CEs transmitted for SCell activation.


Condition Measurement subcounter is the incremented by 1 whenever
Activation/Deactivatoin MAC CEs is transmitted for SCell activation.
Measurement Type OR.CellUA.ActDeactMacCeScellAct
Generation 5GS
1
2 A.11.22 Activation/Deactivation MAC CE (SCell Deactive)

Measurement Name OR.CellUA.ActDeactMacCeScellDeact
Description This counter provides the number of the Activation/Deactivation MAC
CEs transmitted for SCell deactivation. If Activation/Deactivation MAC
CE isn't transmitted when sCellDeactivationTimer expires, this counter
includes the number of sCellDeactivationTimer expiry.
Condition Measurement subcounter is the incremented by 1 whenever
Activation/Deactivatoin MAC CEs is transmitted for SCell deactivation
or whenever sCellDeactivationTimer managed at O-DU expires.
Measurement Type OR.CellUA.ActDeactMacCeScellDeact
Generation 5GS
4
5 A.11.23 Distribution of DL Total PRB Usage

Measurement Name OR.CellUA.RRU.PrbTotDlDist.BinX
Description This counter provides the distribution of DL total PRB usage, which is
same with TS 28.552 [x]. The averaged during time period t n is 1s.
bin 1: 0 % ≤ PRB usage < 5 %
bin 2: 5 % ≤ PRB usage < 10 %
bin 3: 10 % ≤ PRB usage < 15 %
bin 4: 15 % ≤ PRB usage < 20 %
bin 5: 20 % ≤ PRB usage < 25 %
bin 6: 25 % ≤ PRB usage < 30 %
bin 7: 30 % ≤ PRB usage < 35 %
bin 8: 35 % ≤ PRB usage < 40 %
bin 9: 40 % ≤ PRB usage < 45 %
bin 10: 45 % ≤ PRB usage < 50 %
bin 11: 50 % ≤ PRB usage < 55 %
bin 12: 55 % ≤ PRB usage < 60 %
bin 13: 60 % ≤ PRB usage < 65 %
bin 14: 65 % ≤ PRB usage < 70 %
bin 15: 70 % ≤ PRB usage < 75 %
bin 16: 75 % ≤ PRB usage < 80 %
bin 17: 80 % ≤ PRB usage < 85 %

bin 18: 85 % ≤ PRB usage < 90 %

bin 19: 90 % ≤ PRB usage < 95 %
bin 20: 95 % ≤ PRB usage < 100 %
Condition See TS 28.552 [x]. Note that duration period T should be set as100 ms
and the bin defined in description should be used.
Measurement Type OR.CellUA.RRU.PrbTotDlDist.BinX
Generation 5GS
1
2 A.11.24 Distribution of UL Total PRB Usage

Measurement Name OR.CellUA.RRU.PrbTotUlDist.BinX
Description This counter provides the distribution of UL total PRB usage, which is
same with TS 28.552 [x]. The averaged during time period t n is 1s.
bin 1: 0 % ≤ PRB usage < 5 %
bin 2: 5 % ≤ PRB usage < 10 %
bin 3: 10 % ≤ PRB usage < 15 %
bin 4: 15 % ≤ PRB usage < 20 %
bin 5: 20 % ≤ PRB usage < 25 %
bin 6: 25 % ≤ PRB usage < 30 %
bin 7: 30 % ≤ PRB usage < 35 %
bin 8: 35 % ≤ PRB usage < 40 %
bin 9: 40 % ≤ PRB usage < 45 %
bin 10: 45 % ≤ PRB usage < 50 %
bin 11: 50 % ≤ PRB usage < 55 %
bin 12: 55 % ≤ PRB usage < 60 %
bin 13: 60 % ≤ PRB usage < 65 %
bin 14: 65 % ≤ PRB usage < 70 %
bin 15: 70 % ≤ PRB usage < 75 %
bin 16: 75 % ≤ PRB usage < 80 %
bin 17: 80 % ≤ PRB usage < 85 %
bin 18: 85 % ≤ PRB usage < 90 %
bin 19: 90 % ≤ PRB usage < 95 %
bin 20: 95 % ≤ PRB usage < 100 %
Condition See TS 28.552 [x]. Note that duration period T should be set as100 ms
and the bin defined in description should be used.
Measurement Type OR.CellUA.RRU.PrbTotUlDist.BinX
Generation 5GS
4

1 A.11.25 Average DL Cell throughput

Measurement Name OR.CellUA.AveDlCellThroughput
Description This counter provides the Average DL Cell throughput of MAC. This
counter is obtained by accumulating the MAC level volume of a data,
and then dividing by the scheduled time per cell. The measurement is
performed at the MAC level.
Condition Measurement subcounter is calculated by x/y.
x is incremented by the volume of DL MAC PDU whenever the
successfully delivery of DL MAC PDU is confirmed.
y is incremented by the transmission period (e.g. 0.5ms or 0.125ms)
for the PDU whenever DL MAC PDU is transmitted (i.e. including
HARQ retransmission) .
Measurement Result kbps (U32)
Measurement Type OR.CellUA.AveDlCellThroughput
Generation 5GS
3
4 A.11.26 Average UL Cell throughput

Measurement Name OR.CellUA.AveUlCellThroughput
Description This counter provides the Average UL Cell throughput of MAC. This
and then dividing by the scheduled time per cell. The measurement is
performed at the MAC level.
x is incremented by the volume of UL MAC PDU whenever UL MAC
PDU is successfully received.
y is incremented by the transmission period whenever the UL MAC
PDU is received (i.e. including HARQ retransmission) .
Measurement Type OR.CellUA.AveUlCellThroughput
Generation 5GS
6
7 A.11.27 Average DL Beam throughput

Measurement Name OR.CellUA.AveDlBeamThroughput
Description This counter provides the Average DL Beam throughput of MAC. This

and then dividing by the scheduled time per SSB beam index. The
measurement is performed at the MAC level.
x is incremented by the volume of DL MAC PDU whenever DL MAC
PDU is confirmed the successfully delivery when the SSB beam used
for PDSCH is the group of subcounter.SSBBeam.
y is incremented by the transmission period whenever the DL MAC
PDU is transmitted (i.e. including HARQ retransmission) when the SSB
beam used for PDSCH is the group of subcounter.SSBBeam..
Measurement Type OR.CellUA.AveDlBeamThroughput.SSBBeam where SSBBeam is the
SSB beam index:
0: #0
1: #1
…
63: #63
Generation 5GS
1
2 A.11.28 Average UL Beam throughput

Measurement Name OR.CellUA.AveUlBeamThroughput
Description This counter provides the Average UL Beam throughput of MAC. This
and then dividing by the scheduled time per SSB beam index. The
measurement is performed at the MAC level.
x is incremented by the volume of UL MAC PDU whenever UL MAC
PDU is successfully received when the SSB beam used for PUSCH is
the group of subcounter.SSBBeam..
y is incremented by the transmission period whenever the UL MAC
PDU is received (i.e. including HARQ retransmission) when the SSB
beam used for PUSCH is the group of subcounter.SSBBeam.
Measurement Type OR.CellUA.AveUlBeamThroughput.SSBBeam where SSBBeam is the
SSB beam index:
0: #0
1: #1
…
63: #63
Generation 5GS
4

1 A.11.29 Average DL active DRB

Measurement Name OR.CellUA.AveDlActDrb
Description This counter provides the average number of DL active DRB. This
counter is obtained by averaging the number of the active DRB which
has data in MAC/RLC buffer during measurement time per cell.
x is incremented by the number of the DRB which has DL data in
MAC/RLC buffer at every 100 ms.
y is calculated by measurement period divided by 100 ms.
Measurement Type OR.CellUA.AveDlActDrb
Generation 5GS
3
4 A.11.30 Maximum DL active DRB

Measurement Name OR.CellUA.MaxDlActDrb
Description This counter provides the maximum number of DL active DRB. This
counter is obtained by providing the maximum number of the active
DRB which has data in MAC/RLC buffer during measurement time per
cell.
counted volume.
x is the number of the DRB which has UL data in MAC/RLC buffer. x is
acquired as an instantaneous value at every 100ms.
Measurement Type measT OR.CellUA.MaxDlActDrb
Generation 5GS
6
7 A.12 NR Cell Utilization performance counters (Type B)
8 A.12.1 PUSCH slots

Measurement Name OR.CellUB.PuschSlot
Description This counter provides the number of the slots when PUSCH was
received.


received.
Measurement Type OR.CellUB.PuschSlot
Generation 5GS
1
2 A.12.2 PDSCH slots

Measurement Name OR.CellUB.PdschSlot
Description This counter provides the number of the slots when PDSCH was
transmitted.
transmitted.
Measurement Type OR.CellUB.PdschSlot
Generation 5GS
4
5 A.12.3 PDCCH slots

Measurement Name OR.CellUB.PdcchSlot
Description This counter provides the number of the slots when PDCCH was
transmitted.
Condition Measurement subcounter is incremented by 1 whenever PDCCH is
transmitted.
Measurement Type OR.CellUB.PdcchSlot
Generation 5GS
7
8 A.12.4 CCE utilization rate

Measurement Name OR.CellUB.CceUtiliationRate

Description This counter measures the following x in the report period and provides
round(x, 2)･102. x is the usage rate of CCE.
Condition Measurement subcounter is round(x/y, 2)*10^2.
x is incremented by the number of CCEs which are used to transmit
DCI whenever PDCCH is transmitted.
y is incremented by the number of CCEs which can be used whenever
PDCCH is transmitted.
Measurement Result Percentage/102 (U16)
Measurement Type OR.CellUB.CceUtiliationRate
Generation 5GS
1
2 A.12.5 UEs buffering UL/DL data

Measurement Name OR.CellUB.UeBufferingUlDlData
Description This counter provides the accumulated number of the UEs buffering
UL/DL data. This counter obtains the number of the UEs every 100 ms.
which have UL and/or DL data which is group of subcounter.Pmgroup.
Measurement Type OR.CellUB.UeBufferingUlDlData.Pmgroup where Pmgroup is
0: #0
1: #1
…
19: #19
Generation 5GS
4
5 A.12.6 UEs buffering UL data

Measurement Name OR.CellUB.UeBufferingUlData
Description This counter provides the accumulated number of the UEs buffering UL
data. This counter obtains the number of the UEs every 100 ms.
which have UL data which is group of subcounter.Pmgroup.
Measurement Type OR.CellUB.UeBufferingUlData.Pmgroup where Pmgroup is

0: #0
1: #1
…
19: #19
Generation 5GS
1
2 A.12.7 UEs buffering DL data

Measurement Name OR.CellUB.UeBufferingDlData.Pmgroup
Description This counter provides the accumulated number of the UEs buffering DL
data. This counter obtains the number of the UEs every 100 ms.
which have DL data which is group of subcounter.Pmgroup.
Measurement Type OR.CellUB.UeBufferingDlData.Pmgroup where Pmgroup is
0: #0
1: #1
…
19: #19
Generation 5GS
4
5 A.12.8 DRX inactive UEs

Measurement Name OR.CellUB.DrxInactUe
Description This counter provides the accumulated number of the UEs configured as
DRX inactive. This counter obtains the number of the UEs every 100 ms.
Condition Measurement subcounter is incremented by the number of UEs of which
drx-InactibityTimer is assumed to be running.
Measurement Type OR.CellUB.DrxInactUe
Generation 5GS
7

1 A.12.9 DRX active UEs

Measurement Name OR.CellUB.DrxActUe
Description This counter provides the accumulated number of the UEs configured as
DRX active. This counter obtains the number of the UEs every 100 ms.
Condition Measurement subcounter is incremented by the number of UEs which is
configured drx-confing and of which drx-InactibityTimer is assumed not
to be running.
Measurement Type OR.CellUB.DrxActUe
Generation 5GS
3
4 A.13 O-RU Performance counters measured at O-DU
5 A.13.1 Uplink data and control frames received in total

Measurement Name OR.ORU.RX.Total
Description The total number of control/user plane messages received.
Condition The total number of control/user plane eCPRI or 1914.3 messages
received. This counter is the sum of all valid and errored messages
received.
Measurement Type OR.ORU.RX.Total
Measurement Object Class aggregation (O-RU)
Generation 5GS
7
8 A.13.2 Uplink data frames received on Time

Measurement Name OR.ORU.RXData.OnTime
Description The number of inbound user plane messages that arrived within the
specified time window.
Condition The number of inbound user plane (ecpri type 0) messages that arrived
within the specified time window. Some “on time” messages may have
sequence number errors or corruption errors but as long as they arrived
within specified window time, this counter should include them. If the

received message has been transport-fragmented, the full message shall

be reassembled before checking its arrival window.
Measurement Type OR.ORU.RXData.OnTime
Generation 5GS
1
2 A.13.3 Uplink data frames received too early

Measurement Name OR.ORU.RXData.TooEarly
Description The number of inbound user plane messages which were detected to
have arrived before the start of their designated receive window time.
Condition The number of inbound user plane messages which were detected to
Measurement Type OR.ORU.RXData.TooEarly
Generation 5GS
4
5 A.13.4 Uplink data frames received too late

Measurement Name OR.ORU.RXData.TooLate
have arrived after the end of their designated receive window time.
Condition The number of inbound user plane messages which were detected to
Measurement Type OR.ORU.RXData.TooLate
Generation 5GS
7
8 A.13.5 Uplink control frames received on Time

Measurement Name OR.ORU.RXControl.OnTime
Description The number of inbound control plane messages which were detected to


Condition The number of valid inbound control plane (ecpri type 2) messages that
arrived within the specified time window. Some “on time” messages
may have sequence number errors or corruption errors but as long as
they arrived within specified window time, this counter should count
them.
Measurement Type OR.ORU.RXControl.OnTime
Generation 5GS
1
2 A.13.6 Uplink control frames received too early

Measurement Name OR.ORU.RXControl.TooEarly
Description The number of inbound control plane messages which were detected to
Condition The number of inbound control plane messages which were detected to
Measurement Type OR.ORU.RXControl.TooEarly
Generation 5GS
4
5 A.13.7 Uplink control frames received too late

Measurement Name OR.ORU.RXControl.TooLate
Condition The number of inbound control plane messages which were detected to
Measurement Type OR.ORU.RXControl.TooLate
Generation 5GS
7

1 A.13.8 Uplink data frames with detecting sequence identifier error

Measurement Name OR.ORU.RXData.SeqidErr
Description The number of inbound on time user plane messages in which a
sequence identifier number error is detected.
Condition The number of inbound on time user plane messages in which a
sequence identifier number error is detected.
This error occurs when the ecpriSeqId field does not increment. Both the
Sequence ID, and Subsequence ID fields must be checked if transport
fragmentation is supported otherwise only the Sequence ID field may be
checked.
In addition to identifying a sending equipment sequencing error, this
counter can increment when packets are dropped prior to reception by
the RU, or when packets reordered by the network exceed the receiving
device’s capabilities.
Measurement Type OR.ORU.RXData.SeqidErr
Generation 5GS
3
4 A.13.9 Uplink control frames with detecting sequence identifier error

Measurement Name OR.ORU.RXControl.SeqidErr
Description The number of inbound on time control messages in which a sequence
identifier number error is detected.
Condition The number of inbound on time control messages in which a sequence
identifier number error is detected.
This counter increments under the same conditions as the
rx_seqid_num_err except for control plane messages.
Measurement Type OR.ORU.RXControl.SeqidErr
Generation 5GS
6
7 A.13.10 Uplink frames with corrupt contents

Measurement Name OR.ORU.RX.Corrupt
Description The number of inbound on time messages with a correct ecpriSeqId (no
sequence number error) which are dropped by the terminating entity due
to the message containing one or more eCPRI/1914.3 or ORAN protocol
errors.


Condition The number of inbound on time messages with a correct ecpriSeqId (no
sequence number error) which are dropped by the terminating entity due
to the message containing one or more eCPRI/1914.3 or ORAN protocol
errors.
Protocol errors are defined as when eCPRI/1914.3/ORAN defined fields
contain invalid values or indicate unsupported capabilities. Some
examples of this are:
1. PcId or section Id number which has not been configured.
2. Unexpected use of C bit,
3. Unconfigured or Unsupported udCompHdr setting.
4. Unsupported section extension.
5. Wrong ecpriVersion and/or payloadVersion information
6. ecpriMessage field does not contain 0, 2, or 5.
Measurement Type OR.ORU.RX.Corrupt
Generation 5GS
1
2 A.13.11 Uplink frames dropped and discarded.

Measurement Name OR.ORU.RX.ErrDrop
Description The total number of inbound messages which are discarded by the
receiving O-RAN entity for any reason.
Condition The total number of inbound messages which are discarded by the
receiving O-RAN entity for any reason.
Measurement Type OR.ORU.RX.ErrDrop
Generation 5GS
4
5 A.13.12 Downlink control and data frames transmitted

Measurement Name OR.ORU.TX.Total
Description The number of valid outbound control/user plane messages.
Condition The number of valid outbound control/user plane messages.
Measurement Type OR.ORU.TX.Total
Generation 5GS

2 A.13.13 Downlink control frames transmitted to O-RU in total at O-DU

Measurement Name OR.ORU.TXControl.Total
Description The number of valid outbound control plane messages. This counter is
required only if RU supports LAA/LBT capabilities.
Condition The number of valid outbound control plane messages. This counter is
required only if RU supports LAA/LBT capabilities.
Measurement Type OR.ORU.TXControl.Total
Generation 5GS
4
5 A.14 O-RU Performance counters measured at O-RU

6 Please see [4].
7
8
9 Annex B Optional Multi-Vendor Functionality

10 B.1: Optional Namespace Exposed Using O-RAN WG5 Models
11 Some of the O-RAN WG5 defined YANG models are optional for the O-DU to support. In this version of the management
12 plane specification, the following O-RAN WG5 defined YANG models are optional to support. If an O-DU/NETCONF
13 server does not return the namespace associated with an optional O-RAN WG5 defined YANG model, the NETCONF
14 client can infer that the O-DU does not support the optional capability associated with the model.
No Optional Functionality Reference Namespace
15 Table 4: Optional O-RAN WG5 Namespace
16 B.2: Optional Namespace Exposed Using O-RAN WG4 Models

17 Some of the O-RAN WG4 defined YANG models are optional to support. If a device does not return the namespace
18 associated with an optional O-RAN WG4 defined YANG model, the NETCONF client can infer that the device does not
19 support the optional capability associated with the model.
No Optional Functionality Reference Namespace
1 Antenna Line Device O-RAN CU plane specification "urn:o-ran:ald-port:x.y"

[4], Chapter 11.3
"urn:o-ran:ald: x.y "

2 External IO Port O-RAN CU plane specification "urn:o-ran:external-io:x.y "

[4], Chapter 11.4
3 eCPRI delay measurement O-RAN CU plane specification "urn:o-ran:message5:x.y "

[4], Chapter 4.7
4 UDP Echo functionality for IP O-RAN CU plane specification "urn:o-ran:udpecho:x.y "

based transport verification [4], Chapter 4.6
5 Beamforming O-RAN CU plane specification "urn:o-ran:beamforming:x.y "

[4], Chapter 12.4
6 FAN - “urn:o-ran:fan:x.y”
7 LAA O-RAN CU plane specification "urn:o-ran:laa:x.y "

[4], Chapter 13
"urn:o-ran:laa-operations:x.y "
1 Table 5: Optional O-RAN WG4 Namespace
3 B.3: Optional YANG Features Exposed Using O-RAN WG5 Models

4 Some of the O-RAN WG5 defined YANG models define optional feature support. The optional multi-vendor features
5 defined in the O-RAN WG5 defined YANG models are shown below.
No Optional Feature Namespace Feature name
6 Table 6: Optional O-RAN WG5 defined feature support
7 B.4: Optional YANG Features Exposed Using O-RAN WG4 Models

8 Some of the O-RAN WG4 defined YANG models define optional feature support. The optional multi-vendor features
9 defined in the O-RAN WG4 defined YANG models are shown below.
1 Adaptive O-RU delay profile "urn:o-ran:delay:x.y " ADAPTIVE-RU-PROFILE
2 O-RU Energy saving "urn:o-ran:hardware:x.y " ENERGYSAVING
3 Alias MAC address based C/U "urn:o-ran:interfaces:x.y " ALIASMAC-BASED-CU-PLANE

transport
4 UDP/IP based C/U Transport "urn:o-ran:interfaces:x.y " UDPIP-BASED-CU-PLANE
5 Dynamic Beamforming "urn:o-ran:beamforming:x.y MODIFY-BF-CONFIG

Configuration
"
6 GNSS Support "urn:o-ran:sync:x.y " GNSS
7 ALD overcurrent reporting "urn:o-ran:ald-port:x.y " OVERCURRENT-SUPPORTED

8 TRANSPORT in rx-window- "urn:o-ran:performance- GRANULARITY-TRANSPORT-

measurement
management:x.y " MEASUREMENT
9 EAXC_ID in rx-window- "urn:o-ran:performance- GRANULARITY-EAXC-ID-

measurement
management:x.y " MEASUREMENT
10 LAA Support "urn:o-ran: module-cap " LAA
11 Transport Fragmentation "urn:o-ran:module-cap:x.y " TRANSPORT-FRAGMENTATION
12 GNSS Anti Jamming "urn:o-ran:sync:x.y " ANTI-JAM
13 Tiliting pre-defined beams "urn:o-ran:beamforming:x.y" BEAM-TILT
1 Table 7: Optional O-RAN WG4 defined feature support
2 B.5: Optional YANG Features Exposed Using Common Models

3 Some of the O-RAN defined YANG models augment existing YANG models which have optional features defined. The
4 optional features defined in these “common” models are shown in the table below.
1 RFC 6933: Entity MIB "urn:ietf:params:xml:ns:yang:ietf- entity-mib

hardware"
2 RFC 4268: Entity State MIB "urn:ietf:params:xml:ns:yang:ietf- hardware-state

hardware"
3 RFC 3433: Entity Sensor "urn:ietf:params:xml:ns:yang:ietf- hardware-sensor

Management Information Base hardware"
4 O-RU allows user-controlled "urn:ietf:params:xml:ns:yang:ietf- arbitrary-names

interfaces to be named arbitrarily interfaces"
5 O-RU supports pre-provisioning "urn:ietf:params:xml:ns:yang:ietf- pre-provisioning

of interface configuration, i.e., it interfaces"
is possible to configure an
interface whose physical interface
hardware is not present on the
device
6 RFC 2863: The Interfaces Group "urn:ietf:params:xml:ns:yang:ietf- if-mib

MIB interfaces"
7 O-RU supports configuring non- "urn:ietf:params:xml:ns:yang:ietf- ipv4-non-contiguous-netmasks

contiguous subnet masks ip"
8 O-RU supports privacy "urn:ietf:params:xml:ns:yang:ietf- ipv6-privacy-autoconf

extensions for stateless address ip"
autoconfiguration in IPv6
5 Table 8: Optional feature support in common models
6 B.6: Optional Capabilities Exposed Using O-RAN WG5 Models

7 In addition to optional namespaces and optional features within supported namespaces, certain O-RAN WG5 defined
8 YANG models are used to be able to expose support for certain optional capabilities by the O-DU.

No Optional Feature Namespace Leaf
1 Table 9: Optional capabilities in O-RAN WG5 defined YANG models
2 B.7: Optional Capabilities Exposed Using O-RAN WG4 Models

3 In addition to optional namespaces and optional features within supported namespaces, certain O-RAN WG4 defined
4 YANG models are used to be able to expose support for certain optional capabilities by the O-RU.

1 Type of synchronization source "urn:o-ran:sync:x.y " / sync/:sync-status/supported-

supported by O-RU reference-types
2 O-RU supports extended Category "urn:o-ran:module-cap:x.y " /module-capability/ru-capabilities/

A operation – more than 8 spatial ru-supported-category and
streams
/module-capability/ru-capabilities/
number-of-spatial-streams
3 O-RU supports Category B "urn:o-ran:module-cap:x.y " /module-capability/ru-capabilities/

operation – precoding in the O-RU ru-supported-category
4 O-RU supports the capability to "urn:o-ran:beamforming:x.y /beamforming-configuration/

apply the modified beamforming " operational-properties/update-bf-
configuration by using rpc non-delete
activate-beamforming-config
without deletion of tx-array-
carriers and rx-array-carriers
5 O-RU supports the capability to "urn:o-ran:beamforming:x.y /beamforming-configuration/

store the modified beamforming " operational-properties/persistent-bf-
configuration file in the reset files
persistent memory
6 Optional VLAN optimized "urn:o-ran:mplane- /mplane-info/searchable-mplane-

searching interfaces:x.y " access-vlans-info
7 Configurable CoS marking for C, "urn:o-ran:interfaces:x.y " augmented /if:interfaces/if:interface:

U and M-Plane with u-plane-marking c-plane-
marking and m-plane-marking
8 Configurable DSCP marking for "urn:o-ran:interfaces:x.y " augmented /if:interfaces/if:interface:

C, U and M-Plane with u-plane-marking c-plane-
marking and m-plane-marking
9 Ethernet Frame MTU "urn:o-ran:interfaces:x.y” augmented /if:interfaces/if:interface:

with l2-mtu
10 VLAN Tagging "urn:o-ran:interfaces:x.y” augmented /if:interfaces/if:interface:

with vlan-tagging
11 IEEE 1914.3 header support "urn:o-ran:operations:x.y " /operational-info/o-ran-

split/optional-header-support
12 eCPRI Concatenation support "urn:o-ran:operations:x.y " /operational-info/o-ran-split/ecpri-

concatenation-support
13 O-RU local management of the "urn:o-ran:module-cap:x.y " /module-capability/band-

LAA contention window capabilities/sub-band-info/self-
configure
14 O-RU supports LAA ending in "urn:o-ran:laa:x.y” /laa-config/ laa-ending-dwpts-

Downlink Pilot Time Slot supported
(DwPTS)
15 O-RU supports configurable timer "urn:o-ran: supervision:x.y” /supervision/cu-plane-monitoring

for C/U plane monitoring
1 Table 10: Optional capabilities in O-RAN WG4 defined YANG models

1 B.8: Optional Capabilities Exposed Using Common Models

2 When O-RAN defines augmentation of existing YANG models, these models may expose support for certain optional
3 capabilities by the O-RU.
1 IPv6 Supported by O-RU "urn:ietf:params:xml:ns:yang:ietf- augmented /if:interfaces/if:interface:

ip" with ipv6
5 Table 11: Optional capabilities in common YANG models
6 Annex C YANG Module Graphical Representation

7 The different released version of the set of YANG modules for the O-DU can be downloaded from O-RAN’s website
8 http://www.o-ran.org/resources/. The YANG models are available in a zip file, whose name is used to represent the
9 version of the YANG model and follows the numerical format defined in subsection 1.1 with the periods replaced with
10 “-”, i.e., YANG models for release 1.0.0 of the O1 interface specification are availabile in the file 1-0-0.zip. This zip file
11 includes all published revisions of the YANG models supporting a particular release of the O1 interface specification.
12 This Annex provides a set of “tree-views” of the modules to provide a simplified graphical representation of the data
13 models. These trees have been automatically generated using the pyang YANG validator tool. If there are any
14 inconsistencies between the tree representation in this Annex and the yang models, the yang models shall take precedence.
15 For WG4 YANG modules please refer to ORAN-WG4.MP.0-v01 [4] Annex D.
16 C.1 Additional configuration folder

17 Currently no module can be represented in tree view as all of modules in this folder are augmentations of 3GPP
18 modules.
19 C.2 Common Models folder

20 C.2.1 o-ran-dhcp.yang Module
21 module: o-ran-dhcp
22 +--ro dhcp
23 +--ro interfaces* [interface]
24 | +--ro interface if:interface-ref
25 | +--ro dhcpv4
26 | | +--ro client-id? string
27 | | +--ro dhcp-server-identifier? inet:ip-address
28 | | +--ro domain-name? string
29 | | +--ro domain-name-servers* inet:ip-address
30 | | +--ro interface-mtu? uint32
31 | | +--ro default-gateways* inet:ip-address
32 | | +--ro netconf-clients* [client]
33 | | | +--ro client netconf-client-id
34 | | | +--ro optional-port? inet:port-number
35 | | +--ro ca-ra-servers* [servers]
36 | | | +--ro servers ca-ra-server-id
37 | | | +--ro optional-port? inet:port-number
38 | | | +--ro ca-ra-path? string
39 | | | +--ro subject-name? string
40 | | | +--ro protocol? enumeration
41 | | +--ro segw* [gateways]
42 | | +--ro gateways segw-id
43 | +--ro dhcpv6
44 | +--ro dhcp-client-identifier
45 | +--ro dhcp-server-identifier
46 | +--ro domain-name? string

1 | +--ro domain-name-servers* inet:ip-address

2 | +--ro netconf-clients* [client]
3 | | +--ro client netconf-client-id
4 | | +--ro optional-port? inet:port-number
5 | +--ro ca-ra-servers* [servers]
6 | | +--ro servers ca-ra-server-id
7 | | +--ro optional-port? inet:port-number
8 | | +--ro ca-ra-path? string
9 | | +--ro subject-name? string
10 | | +--ro protocol? enumeration
11 | +--ro segw* [gateways]
12 | +--ro gateways segw-id
13 +--ro m-plane-dhcp
14 +--ro private-enterprise-number? uint16
15 +--ro vendor-class-data? string
16
17 C.2.2 o-ran-synchronization.yang Module

18 module: o-ran-synchronization
19 +--rw sync
20 +--rw sync-functions
21 | +--ro sync-state enumeration
22 | +--ro sync-capability
23 | | +--ro partial-timing-supported? boolean
24 | | +--ro supported-reference-types* [sync-source]
25 | | +--ro sync-source enumeration
26 | +--rw sync-config
27 | | +--rw sync-priority-config* [sync-source]
28 | | | +--rw sync-source enumeration
29 | | +--rw synce-enabled? boolean
30 | +--rw ptp-config
31 | | +--rw domain-number? uint8
32 | | +--rw accepted-clock-classes* [clock-classes]
33 | | | +--rw clock-classes uint8
34 | | +--rw delay-asymmetry? int16
35 | | +--rw ptp-profile? enumeration
36 | | +--rw g-8275-1-config
37 | | | +--rw multicast-mac-address? enumeration
38 | | +--rw g-8275-2-config
39 | | +--rw local-ip-port? -> /if:interfaces/interface/name
40 | | +--rw master-ip-configuration* [local-priority]
41 | | | +--rw local-priority uint8
42 | | | +--rw ip-address? string
43 | | +--rw log-inter-sync-interval? int8
44 | | +--rw log-inter-announce-interval? int8
45 | +--rw ptp-status
46 | | +--rw reporting-period? uint8
47 | | +--ro clock-class? uint8
48 | | +--ro clock-identity? string
49 | | +--ro sources* [source-clock-identity]
50 | | +--ro sync-source-status? enumeration
51 | | +--ro clock-class? uint8
52 | | +--ro clock-accuracy? uint8
53 | | +--ro offset-scaled-log-variance? uint16
54 | | +--ro priority1? uint8
55 | | +--ro priority2? uint8
56 | | +--ro grandmaster-clock-identity? string
57 | | +--ro source-clock-identity string
58 | | +--ro source-port-number? uint16
59 | | +--ro steps-removed? uint16
60 | | +--ro local-port-number? -> /if:interfaces/interface/o-ran-int:port-reference/port-number
61 | | +--ro ptp-timescale? boolean
62 | | +--ro time-source? uint8
63 | | +--ro time-traceable? boolean
64 | | +--ro frequency-traceable? boolean
65 | | +--ro current-utc-offset? int16
66 | | +--ro current-utc-offset-valid? boolean
67 | | +--ro leap61? boolean
68 | | +--ro leap59? boolean
69 | | +--ro two-step-flag? boolean
70 | +--rw synce-config
71 | | +--rw acceptance-list-of-ssm* enumeration
72 | | +--rw ssm-timeout? uint16
73 | +--rw synce-status

1 | | +--rw reporting-period? uint8

2 | | +--ro sources* [source-clock-identity]
3 | | +--ro source-clock-identity string
4 | | +--ro sync-source-status? enumeration
5 | | +--ro quality-level? uint8
6 | +--rw gnss-config {GNSS}?
7 | | +--rw enable? boolean
8 | | +--rw satellite-constellation-list* enumeration
9 | | +--rw polarity? enumeration
10 | | +--rw cable-delay? uint16
11 | | +--rw anti-jam-enable? boolean {ANTI-JAM}?
12 | +--rw gnss-status {GNSS}?
13 | +--rw reporting-period? uint8
14 | +--ro name? string
15 | +--rw sync-source-status? enumeration
16 | +--ro gnss-sync-status? enumeration
17 | +--ro gnss-data
18 | +--ro satellites-tracked? uint8
19 | +--ro location
20 | +--ro altitude? int64
21 | +--ro latitude? geographic-coordinate-degree
22 | +--ro longitude? geographic-coordinate-degree
23 +--rw sync-master-functions
24 +--ro sync-master-capabilities
25 | +--ro ptp-sync-master-capabilities
26 | | +--ro ptp-sync-master-supported? boolean
27 | +--ro synce-sync-master-capabilities
28 | +--ro synce-sync-master-supported? boolean
29 +--rw sync-master-configuration
30 +--rw ptp-master-configuration
31 | +--rw ptp-master-enabled-local-port-numbers* -> /if:interfaces/interface/o-ran-int:port-reference/port-number
32 | +--rw domain-number? uint8
33 | +--rw multicast-mac-address? enumeration
34 | +--ro clock-identity? string
35 | +--rw priority2? uint8
36 +--rw ptp-status
37 | +--rw reporting-period? uint8
38 | +--ro clock-class? uint8
39 | +--ro clock-identity? string
40 | +--ro sources* [source-clock-identity]
41 | +--ro sync-source-status? enumeration
42 | +--ro clock-class? uint8
43 | +--ro clock-accuracy? uint8
44 | +--ro offset-scaled-log-variance? uint16
45 | +--ro priority1? uint8
46 | +--ro priority2? uint8
47 | +--ro grandmaster-clock-identity? string
48 | +--ro source-clock-identity string
49 | +--ro source-port-number? uint16
50 | +--ro steps-removed? uint16
51 | +--ro local-port-number? -> /if:interfaces/interface/o-ran-int:port-reference/port-number
52 | +--ro ptp-timescale? boolean
53 | +--ro time-source? uint8
54 | +--ro time-traceable? boolean
55 | +--ro frequency-traceable? boolean
56 | +--ro current-utc-offset? int16
57 | +--ro current-utc-offset-valid? boolean
58 | +--ro leap61? boolean
59 | +--ro leap59? boolean
60 | +--ro two-step-flag? boolean
61 +--rw synce-master-configuration
62 +--rw synce-master-enabled-local-port-numbers* -> /if:interfaces/interface/o-ran-int:port-reference/port-number
63
64 C.2.3 o-ran-wg5-delay-management Module

65 module: o-ran-wg5-delay-management
66 +--rw wg5-delay-management
67 +--ro window-determine-capability enumeration
68 +--rw window-determine-method
69 | +--rw method enumeration
70 | +--rw configuration-status -> /wg5-delay-management/window-determine-capability
71 | +--rw pre-configured-transport-delay* [ru-instance-id]
72 | +--rw ru-instance-id ru-ref
73 | +--rw t12-min uint32

1 | +--rw t12-max uint32

2 | +--rw t34-min uint32
3 | +--rw t34-max uint32
4 +--rw o-du-window* [ru-instance-id bandwidth subcarrier-spacing]
5 | +--rw ru-instance-id ru-ref
6 | +--rw bandwidth bandwidth
7 | +--rw subcarrier-spacing uint32
8 | +--rw ta4-min uint32
9 | +--rw ta4-max uint32
10 | +--rw t1a-min-cp-dl uint32
11 | +--rw t1a-min-cp-ul uint32
12 | +--rw t1a-min-up uint32
13 | +--rw t1a-max-cp-dl uint32
14 | +--rw t1a-max-cp-ul uint32
15 | +--rw t1a-max-up uint32
16 +--ro o-ru-window* [ru-instance-id bandwidth subcarrier-spacing]
18 | +--ro bandwidth bandwidth
19 | +--ro subcarrier-spacing uint32
20 | +--ro t2a-min-up uint32
21 | +--ro t2a-max-up uint32
22 | +--ro t2a-min-cp-dl uint32
23 | +--ro t2a-max-cp-dl uint32
24 | +--ro tcp-adv-dl uint32
25 | +--ro ta3-min uint32
26 | +--ro ta3-max uint32
27 | +--ro t2a-min-cp-ul uint32
28 | +--ro t2a-max-cp-ul uint32
29 +--ro measured-transport-delay* [ru-instance-id]
30 +--ro ru-instance-id ru-ref
31 +--ro t12-min uint32
32 +--ro t12-max uint32
33 +--ro t34-min uint32
34 +--ro t34-max uint32
35
36 C.3 DU Specific Models folder

37 C.3.1 o-ran-aggregation-base.yang Module
44 +--rw or-agg-ops:operations-model
45 +--rw or-agg-pm:performance-management-model
46 +--rw or-agg-swm:software-management-model
47
48 C.4 Provisioning folder

49 Currently no module can be represented in tree view as all of modules in this folder are augmentations of o-ran-
50 aggregation-base module.
51
52 Annex D WG4 instance categories in Hierarchical Model

53 In the spreadsheet attached to this specification you can find categories of WG4 YANG data model instances
54 Note: Yellow parts in above spreadsheet means that those parameters are not categorized yet.
55 All instances are categorized by the following Legend.

Category Legend definition

M Mapping from SA5 parameter
rw I Creating by O-DU internal logic
A Configuring by Aggregatin model
M Mapping to SA5 parameter
ro N No need to notify to SMO
A Get by Aggregation model
1 Table 12: Categories for YANG parameters
3 Annex ZZZ O-RAN Adopter License Agreement

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

1 Section 2: COPYRIGHT LICENSE

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

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

36 4.1 This Agreement shall remain in force, unless early terminated according to this Section 4.
37 4.2 O-RAN Alliance on behalf of its Members, Contributors and Academic Contributors may terminate this Agreement
38 if Adopter materially breaches this Agreement and does not cure or is not capable of curing such breach within thirty
39 (30) days after being given notice specifying the breach.
40 4.3 Sections 1, 3, 5 - 11 of this Agreement shall survive any termination of this Agreement. Under surviving Section 3,
41 after termination of this Agreement, Adopter will continue to grant licenses (a) to entities who become Adopters after
42 the date of termination; and (b) for future versions of ORAN Specifications that are backwards compatible with the
43 version that was current as of the date of termination.
44 Section 5: CONFIDENTIALITY
45 Adopter will use the same care and discretion to avoid disclosure, publication, and dissemination of O-RAN
46 Specifications to third parties, as Adopter employs with its own confidential information, but no less than reasonable
47 care. Any disclosure by Adopter to its Affiliates, contractors and consultants should be subject to an obligation of

1 confidentiality at least as restrictive as those contained in this Section. The foregoing obligation shall not apply to any
2 information which is: (1) rightfully known by Adopter without any limitation on use or disclosure prior to disclosure;
3 (2) publicly available through no fault of Adopter; (3) rightfully received without a duty of confidentiality; (4) disclosed
4 by O-RAN Alliance or a Member, Contributor or Academic Contributor to a third party without a duty of
5 confidentiality on such third party; (5) independently developed by Adopter; (6) disclosed pursuant to the order of a
6 court or other authorized governmental body, or as required by law, provided that Adopter provides reasonable prior
7 written notice to O-RAN Alliance, and cooperates with O-RAN Alliance and/or the applicable Member, Contributor or
8 Academic Contributor to have the opportunity to oppose any such order; or (7) disclosed by Adopter with O-RAN
9 Alliance’s prior written approval.
10 Section 6: INDEMNIFICATION
11 Adopter shall indemnify, defend, and hold harmless the O-RAN Alliance, its Members, Contributors or Academic
12 Contributors, and their employees, and agents and their respective successors, heirs and assigns (the “Indemnitees”),
13 against any liability, damage, loss, or expense (including reasonable attorneys’ fees and expenses) incurred by or
14 imposed upon any of the Indemnitees in connection with any claims, suits, investigations, actions, demands or
15 judgments arising out of Adopter’s use of the licensed O-RAN Specifications or Adopter’s commercialization of
16 products that comply with O-RAN Specifications.
17 Section 7: LIMITATIONS ON LIABILITY; NO WARRANTY

18 EXCEPT FOR BREACH OF CONFIDENTIALITY, ADOPTER’S BREACH OF SECTION 3, AND ADOPTER’S
19 INDEMNIFICATION OBLIGATIONS, IN NO EVENT SHALL ANY PARTY BE LIABLE TO ANY OTHER
20 PARTY OR THIRD PARTY FOR ANY INDIRECT, SPECIAL, INCIDENTAL, PUNITIVE OR CONSEQUENTIAL
21 DAMAGES RESULTING FROM ITS PERFORMANCE OR NON-PERFORMANCE UNDER THIS AGREEMENT,
22 IN EACH CASE WHETHER UNDER CONTRACT, TORT, WARRANTY, OR OTHERWISE, AND WHETHER OR
23 NOT SUCH PARTY HAD ADVANCE NOTICE OF THE POSSIBILITY OF SUCH DAMAGES.
24 O-RAN SPECIFICATIONS ARE PROVIDED “AS IS” WITH NO WARRANTIES OR CONDITIONS

25 WHATSOEVER, WHETHER EXPRESS, IMPLIED, STATUTORY, OR OTHERWISE. THE O-RAN ALLIANCE
26 AND THE MEMBERS, CONTRIBUTORS OR ACADEMIC CONTRIBUTORS EXPRESSLY DISCLAIM ANY
27 WARRANTY OR CONDITION OF MERCHANTABILITY, SECURITY, SATISFACTORY QUALITY,
28 NONINFRINGEMENT, FITNESS FOR ANY PARTICULAR PURPOSE, ERROR-FREE OPERATION, OR ANY
29 WARRANTY OR CONDITION FOR O-RAN SPECIFICATIONS.
30 Section 8: ASSIGNMENT
31 Adopter may not assign the Agreement or any of its rights or obligations under this Agreement or make any grants or
32 other sublicenses to this Agreement, except as expressly authorized hereunder, without having first received the prior,
33 written consent of the O-RAN Alliance, which consent may be withheld in O-RAN Alliance’s sole discretion. O-RAN
34 Alliance may freely assign this Agreement.
35 Section 9: THIRD-PARTY BENEFICIARY RIGHTS

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

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

1 Section 11: GENERAL

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


ORAN-WG5.MP.0-v01.00: O-RAN Alliance Working Group 5 O1 Interface Specification For O-DU

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

ORAN-WG5.MP.0-v01.00: O-RAN Alliance Working Group 5 O1 Interface Specification For O-DU

Uploaded by

Copyright:

Available Formats

ORAN-WG5.MP.0-v01.

O-RAN Alliance Working Group 5

O1 Interface specification for O-DU

Prepared by the O-RAN Alliance. Copyright © 2020 by the O-RAN Alliance.

Copyright © 2020 by the O-RAN Alliance.

Copyright © 2020 by the O-RAN Alliance.

Copyright © 2020 by the O-RAN Alliance.

1 6.2 Performance Data Streaming ...................................................................................................................................... 31

Copyright © 2020 by the O-RAN Alliance.

Copyright © 2020 by the O-RAN Alliance.

1 A.6.8 PUCCH RSSI .......................................................................................................................................................... 84

Copyright © 2020 by the O-RAN Alliance.

1 A.11.26 Average UL Cell throughput .......................................................................................................................... 113

Copyright © 2020 by the O-RAN Alliance.

1 Section 8: ASSIGNMENT ............................................................................................................................................. 135

Copyright © 2020 by the O-RAN Alliance.

1 Chapter 1 Introductory Material

Copyright © 2020 by the O-RAN Alliance.

25 1.3 Definitions and Abbreviations

Copyright © 2020 by the O-RAN Alliance.

Copyright © 2020 by the O-RAN Alliance.

1 LBM Loop-Back Message

33 1.5 Topics for Future Specification Versions

37 1. Adding Trace support according to O1 Interface [23] Chapter 2.4

Copyright © 2020 by the O-RAN Alliance.

29 Chapter 2 High Level Description

30 2.1 Top level functional description, terminology, including hybrid,

35 2.1.2 O1 interface for O-DU architecture model

39 2.1.3 Transport Network

Copyright © 2020 by the O-RAN Alliance.

7 2.3 YANG Module Introduction

Copyright © 2020 by the O-RAN Alliance.

3 Figure 2: Details of Configuration Data Bases (CDB)

Copyright © 2020 by the O-RAN Alliance.

1 Chapter 3 Startup and Registration Management

4 O-DU is physically installed

5 Power-ON for O-DU/NETCONF Server or O-DU restart operation.

6 Power-ON for NETCONF Client(s).

7 Physical interface(s) is(are) connected.

Copyright © 2020 by the O-RAN Alliance.

Copyright © 2020 by the O-RAN Alliance.

1 Figure 3: Overall of Start-Up Installation

2 3.1 O1 Interface Transport aspects

7 - Physical interface is connected.

9 - The SMO/MnS Consumer has been correctly discovered by the O-DU

14 For the transport establishment, there are the following alternatives:

Copyright © 2020 by the O-RAN Alliance.

Copyright © 2020 by the O-RAN Alliance.

2 - O-DU identification in DHCP messages from O-DU.

3 - VLAN discovery aspect for O1 interface.

4 - IP address assignment to O-DU.

5 - Discovery of address information of SMO/MnS Consumer(s).

6 3.1.1 O-DU identification in DHCP

11 DHCPv4 Vendor Class Option:

13 • Vendor Class Identifier Option 60: string

16 1. <optionalMvPnC/><ManagedElementType>/<vendor>, e.g., “MvPnC/o-ran-du/vendorA”

21 DHCPv4 Vendor-Identifying Vendor Class Option:

23 • Enterprise number: O-RAN-alliance 53148

26 DHCPv6 Vendor Class Option:

28 • Enterprise number: O-RAN-alliance 53148

33 3.1.2 Management Plane VLAN Discovery Aspects

Copyright © 2020 by the O-RAN Alliance.

18 3.1.3 O-DU IP Address Assignment used for O1 signalling