SCF229.0.1 5G FAPI Operations Administration and Maintenance OAM Protocol For Inline High-PHY

DECEMBER 2022
5G FAPI: RF
5G FAPI Operations,
and Digital
Administration and
Frontend
Maintenance (OAM)
Control API
Protocol
Month Year
for Inline
High-PHY
DOCUMENT 229.0.1
www.smallcellforum.org
Credits
Author Company
Nithin Kumar Mavenir
Tim Carrey Qualcomm Technologies, Inc
Douglas Knisely Qualcomm Technologies, Inc
Andrei Radulescu [also rapporteur] Qualcomm Technologies, Inc
Reviewer Company
Neil Piercy Mavenir
Martin Lysejko Picocom
Faiyaz Baxamusa Qualcomm Technologies, Inc
Kalyan Kuppuswamy Qualcomm Technologies, Inc
Ganesh Shenbagaraman Radisys
Vikas Dixit Reliance Jio
Report title: SCF229 5G FAPI Operations, Administration and Maintenance (OAM) Protocol for Inline High-PHY
Issue date: 19 December 2022
Version: 229.0.1
Scope
A main goal of this specification is to document a simplified API that allows:
• access to YANG modules defined outside SCF

• hosting of these YANG modules as YANG data trees in L1
• a minimally essential set of operation APIs for reading and writing YANG
modules, constituting a subset of NETCONF [2]
For 5G, the FAPI suite comprises five specification documents covering the following
APIs:
• ‘5G FAPI: PHY API’ – main data path (P7) and PHY mode control (P5)
interface [SCF222]
• ‘5G FAPI: RF and Digital Front End Control API’ – (P19) for Frontend Unit
control [SCF223]
• ‘Network Monitor Mode API’ – (P4) for 2G/3G/4G/5G [SCF224]
• ‘5G nFAPI Specification’ [SCF225]
• ‘SCF229 5G FAPI Operations, Administration and Maintenance (OAM) Protocol
for Inline High-PHY [SCF-229]
• The YANG server residing in L1 hosts:
• YANG modules pertaining to the O-RU associated with each PHY.

• YANG modules characterizing to the High-PHY termination of the open
fronthaul interface
RAN Internal Architecture

L2/L3 – application software
Control Cell RF/DFE/
Client MAC
SON Config ABF Config
P4 P5 P9 P7 P19
Server
PHY
FEU
(RF/DFE/ABF)
NMM
L1 – platform hardware
SON (Self Organizing Networks), MAC (Medium Access Control), NMM (Network Monitor Mode), FEU
(Front End Unit), including DFE (Digital Front End) and ABF (Analog Beam Forming)
Version: 229.0.1
5G PHY API executive summary
This document provides the 5G data model transport functional API specification for an
application platform interface (API) between the L2/L3 and L1 protocols within a 5G
distributed unit. This functional application platform interface (FAPI) is an internal
interface within the distributed unit.
Features relevant to multiple split architectures (e.g. 7.2x, in addition to 6) are also
supported:
• Reading and writing, by a L2/L3 client, of YANG data trees hosted by a L1

server across the interface between L2/L3 and L1
This specification defines a transport interface (P9) for transporting instances of data
models between the L1 and L2/L3 protocol layers. The document is structured as
follows:
• Introduction: This section provides the high-level overview and governing

principles of the API
• Procedures: This section details procedures for accessing YANG modules
• Messages: This section defines the FAPI specific messages and structures to
implement these procedures
Version: 229.0.1
Contents
1. Introduction .................................................................1
1.1 Data Tree ....................................................................... 1
1.2 L2/L3 as Client ................................................................ 1
1.3 L1 as Server ................................................................... 2
1.4 Other Servers ................................................................. 2
1.5 Non-YANG Data............................................................... 2
2. Data Model Procedures .................................................3
2.1 Read Procedure ............................................................... 3
2.2 Write Procedure .............................................................. 3
3. Data Model Transfer API Messages ..............................5
3.1 General Message Format .................................................. 5
3.1.1 Message Header .............................................................. 5
3.1.2 Message Body ................................................................. 6
3.2 Pipelining ....................................................................... 6
3.3 Request and Response Messages ....................................... 6
3.3.1 Get Message ................................................................... 7
3.3.2 GetResp Message ............................................................ 7
3.3.3 EditConfig Message .......................................................... 8
3.3.4 EditConfigResp Message ................................................... 8
3.3.5 Status and Error Messages ............................................... 9
4. YANG Modules ............................................................10
4.1 YANG Modules describing the O-RU.................................. 10
4.2 YANG Modules describing the O-RAN Fronthaul termination at
the ODU ....................................................................... 10
References ............................................................................11
Figures
Figure 1-1 Client server architecture for data model access .............................1
Figure 2-1 Read procedure ..........................................................................3
Figure 2-2 Write procedure ..........................................................................4
Figure 3-1 General P9 message format .........................................................5
Figure 3-2 P9 interface message header ........................................................6
Figure 3-3 P9 interface message body ..........................................................6
Figure 3-4 P9 interface request and response messages ..................................7
Figure 3-5 P9 interface get message .............................................................7
Figure 3-6 P9 interface GetResp message......................................................8
Figure 3-7 P9 interface EditConfig message ...................................................8
Version: 229.0.1
Figure 3-8 P9 interface EditConfigResp message ............................................9
Figure 3-9 P9 interface Status and Error messages .........................................9
Version: 229.0.1
1. Introduction
1.1 Data Tree
Many modern network nodes are parametrized by capability and configuration

parameters modelled in YANG, a data modelling language defined in RFC 7950 [1].
For this specification, data refers to a YANG instance defined using YANG modules and
organized as a data tree, as defined in [1]; the data is available from the server
hosted by L1 and accessible (via read and write operations) to the client in L2/L3.
L1 Data Operations L2/L3

Server
YANG
Data
Tree
Client
Figure 1-1 Client server architecture for data model access
The means whereby the server or client obtain access to the data to be hosted in the
L1 server are not relevant to this specification.
Data read/write accesses are contextualized by PHY ID (as defined in SCF-222), for
each virtual function 1. It is the responsibility of the server to present data to the client
0F
scoped (e.g., filtered) per the PHY ID.
Furthermore, the data presented to a client may be specific to the PHY’s TRP. It is the
responsibility of the L2/L3 client to indicate the TRP ID, as defined in SCF-222, context
that pertains to data that is written to or requested from the L1 server. For instance,
read/write accesses to YANG data tree nodes pertaining a TRP’s antenna panels or
spatial streams shall be contextualized by the L2/L3 client with that TRP’s trp_id in the
request’s header message.
1.2 L2/L3 as Client
The L2/L3, from the point of view of FAPI [3], play the role of a client towards a
server hosted in L1. A L2/L3 client initiates data access requests, as detailed in
section 2.
As an example salient to this specification, data organized according to the O-RU

YANG data tree [5] is written by L2/L3 client to the L1 server, describing O-RU(s)
paired to each L1 PHY, as relevant to PHY’s baseband operation in an O-DU node [4].
The means whereby the L2/L3 client obtains the data to write to the L1 server are
outside the scope of this specification and may, for instance, involve NETCONF [2] M-
plane [5] operations terminated between L2/L3 and the relevant O-RU nodes or other
nodes.
As another example salient to this specification, data [5] parametrizing O-RAN

fronthaul [6] network interfaces and S-plane for O-RU is also relevant to O-RAN
1
All PHY ID contexts are specific to the Virtual Function, including for PHY ID 0, as detailed in SCF-222. It is
understood in this specification that a PHY ID context is specific to the virtual function.
Version: 229.0.1 1
Fronthaul termination at the O-DU node [4] and is read by L2/L3 client from the L1
Server.
1.3 L1 as Server
The L1, from the point of view of FAPI [3], plays the role of a server towards L2/L3
clients. The L1 server stores data organized as YANG data trees, and terminates data
access requests, as detailed in section 2.
In the L1 server, the YANG data trees describing the O-RAN fronthaul termination at
the O-DU node can be polled in any PHY State.
The YANG data trees describing the O-RU(s) associated with each PHY are specific to
each [PHY, O-RU] tuple. The content of these YANG data trees is reset in PHY IDLE
and readable/writeable in PHY CONFIG and PHY RUNNING states.
1.4 Other Servers
This specification is only concerned with data accesses over the interface between
L2/L3 client and L1 server, for YANG data trees stored in the L1 server. 5G RAN nodes
making use of FAPI [3] may access YANG data trees over other interfaces using other
protocols, for example NETCONF.
1.5 Non-YANG Data
The existence of this specification does not imply that all capability and configuration
parameters for FAPI are modelled according to a YANG data tree; for instance, generic
baseband capability and configuration parameters are modelled as FAPI TLVs, which
are subject to FAPI protocol over the P5 interface, as specified in SCF-222 [3].
Version: 229.0.1 2
2. Data Model Procedures
This section gives an overview of the procedures which use the YANG data tree
Transfer API.
Note: The data operations captured in this document are a subset of the ones in
NETCONF [2], with the aim of facilitating interworking with NETCONF-based
exchanges used to access to the YANG data tree(s).
2.1 Read Procedure
The read procedures allow a L2/L3 client to access a YANG data tree stored on a L1
server via the Get/GetResp/Error messages.
L2/L3 Client L1 Server
Get ([filter])
alt get outcomes

GetResp(data)
Successful Data
Read
GetResp Error(type, severity, ...)

Data Read
Failure
Figure 2-1 Read procedure
2.2 Write Procedure
The write procedures allows a L2/L3 client to access a YANG data tree stored on a L1
server via the EditConfig/Status/Error messages.
Version: 229.0.1 3
L2/L3 Client L1 Server
EditConfig( deltaConfig )
alt edit-config
outcomes
EditConfigResp Status(ok)
Successful Data
Write
EditConfigResp Error(type, severity, ...)

Data Write
Failure
Figure 2-2 Write procedure
Version: 229.0.1 4
3. Data Model Transfer API Messages
This section provides a description of the data model transfer API message formats. It
defines the message header and bodies associated with the API, making use of the
protocol buffers [7] mechanism for representing messages and their structure.
3.1 General Message Format
The messages used on the interface are comprised of a header and a body. The
information in the header is common to all messages and each message within the
body has its own set of attributes that comprise the request or response message.
syntax = "proto3";
package p9_message.v1;
message Msg {
Header header = 1;
Body body = 2;
} // Vendor extensions begin at 1001
Figure 3-1 General P9 message format
P9 messages provide the capability to extend the message with additional vendor
specific fields. The vendor specific field identifiers begin at 1001 for all P9 messages.
3.1.1 Message Header
The message header is comprised of mandatory and optional fields in the protocol.
• The msg_id field is a mandatory field used by the sending and receiving
managed entity to correlate requests with responses. Likewise, the receiving
managed entity can use the msg_id field to identify notifications sent by the
client.
• The oru_name field is an optional field that provides the name of object or
resource that is the subject of the message. This field contains the identifier
of the O-RU, if the message conveys information characterizing an O-RU, or
shall be absent, otherwise.
• The vf_id field is a mandatory field that provides the value of the VF id, per
SCF-222 [3]. All messages are specific [vf_id, phy_id] tuple.
• The phy_id field is a mandatory field that provides the value of the PHY id,
per SCF-222 [3]. All messages are specific [vf_id, phy_id] tuple.
• The trp_id is an optional field that provides the identity of the PHY TRP to
which the message applies. This field is only unique for each PHY id. Its
absence implies that the message is not specific to a PHY’s TRP,but applies to
the entire PHY indicated by the phy_id field.
Version: 229.0.1 5
message Header {
string msg_id = 1; // Message identifier to
// 1) Identify requests and notifications
// 2) Correlate requests and response
optional string oru_name = 2; // The name (identifier) of the O-RU,
// if present.
int32 vf_id = 3; // The identifier for the FAPI VF ID
int32 phy_id = 4; // The identifier for the FAPI PHY ID
optional int32 trp_id = 5; // The identifier PHY’s TRP, if any
}
Figure 3-2 P9 interface message header
3.1.2 Message Body
The body of the P9 interface message can be a request or response message.
message Body {
oneof msg_body {
Request request = 1;
Response response = 2;
}
Figure 3-3 P9 interface message body
3.2 Pipelining
Pipelining of P9 messages shall conform to Section 4.5 of RFC 6241 [2], with P9
messages instead of <rpc> operations.
3.3 Request and Response Messages
Request messages originated from the client are directed to the server. Response
messages originated from the server are directed to the client that originated the
Request message.
Version: 229.0.1 6
message Request {
oneof req_type {
Get get = 1;
EditConfig edit_config = 2;
}
message Response {
oneof resp_type {
GetResp get_resp = 1;
EditConfigResp edit_config_resp = 2;
}
Figure 3-4 P9 interface request and response messages
3.3.1 Get Message
The Get message is used to retrieve the capability and configuration state information
for the entity identified by the oru_name of the request message header, for the PHY
id context.
The filter field in the Get request message is used to scope the request to specific
elements. Each filter instance contains an expression that represents a NETCONF
subtree or xpath filter. This field shall be encoded the same way as the contents in the
<filter> tag inside the <get> tag in NETCONF [2] specification.
message Get {
repeated bytes filter = 1;
Figure 3-5 P9 interface get message
3.3.2 GetResp Message
The GetResp message returns data subset corresponding to the filter in a Get request
message, for the entity identified by the oru_name of the response message header,
for the PHY id context.
The status_response field in the GetResp message is used to convey the status of the
message along with any error codes if the request failed for any reason.
The data field shall be encoded the same way as the contents in the <data> tag in
NETCONF [2] specification.
Version: 229.0.1 7
message GetResp {
Status status_resp = 1;
bytes data = 2;
}
Figure 3-6 P9 interface GetResp message
3.3.3 EditConfig Message
The EditConfig message is used to update the requested part of the configuration of
the entity identified by the oru_name of the request message header, for the PHY id
context.
The delta_config field contains a list of changes for nodes within the client.
Additionally, each node contains a NETCONF operation to apply to the node. In this
release, the only operation supported is the NETCONF merge operation.
The delta_config field shall be encoded the same way as the contents in the <edit-
config> tag in NETCONF [2] specification.
message EditConfig {
bytes delta_config = 1; // List of Node changes with the
// associated operation to apply to
// the node
}
Figure 3-7 P9 interface EditConfig message
The operation of EditConfig on the YANG data tree shall follow the <edit-config>
operation, as documented in section 7.2 of RFC 6241 [2], with the following
limitations:
• “operation” attribute: only merge

• “target” parameter: only <running>
• “default-operation” parameter: only merge
• “test-option”: not supported
• “error-option”: only stop-on-error
3.3.4 EditConfigResp Message
The EditConfigResp message is used to return the status of an EditConfig request

message, for the entity identified by the oru_name of the response message header,
for the PHY id context.
The status_response field in the EditConfigResp response message is used to convey
the status of the message along with any error codes if the request failed for any
reason.
Version: 229.0.1 8
message EditConfigResp {
Status status_resp = 1;
}
Figure 3-8 P9 interface EditConfigResp message
3.3.5 Status and Error Messages
The Status message permits sever to respond to request messages. The status_code
field in the message indicates if the request was successful or if there was an error. If
there was an error with the request, the status message contains one or more Error
messages in the error field of the status message. The error message is based on
NETCONF rpcErrorType defined in Appendix B of RFC 6241
message Error { // Type of error as defined in RFC 6241 section 4.3

string error_type = 1; // Error type defined in RFC 6241
// Appendix B
string error_tag = 2; // Error tag defined in RFC 6241
// Appendix B
string error_severity = 3; // Error severity defined in RFC 6241
// Appendix B
string error_app_tag = 4; // Error app tag defined in RFC 6241
// Appendix B
string error_path = 5; // Error path defined in RFC 6241
// Appendix B
string error_message = 6; // Error message defined in RFC 6241
// Appendix B
}
message Status {
enum StatusCode {
OK = 0;
ERROR_GENERAL = 1;
}
StatusCode status_code = 1;
repeated Error error = 2; //Optional: Error information
}
Figure 3-9 P9 interface Status and Error messages
Version: 229.0.1 9
4. YANG Modules
In this specification version, only the following YANG modules are supported with L1
adopting the server role, as described in section 1.
4.1 YANG Modules describing the O-RU
The following YANG modules are supported:
• all the YANG modules listed in the O-RU WG4 M-plane specification [5],
Annex D.
Notes:
• this document does not make any assumption on how L2/L3 accesses YANG
data tree organized according to the YANG modules.
• A non-exhaustive option is for L2/L3 to make use of NETCONF to access such
YANG data accessible in another node, according to one of the architectures
in section 5.1.2 of [5].
4.2 YANG Modules describing the O-RAN Fronthaul termination at the

ODU
The following YANG modules are supported:
• o-ran-interfaces, as listed in the O-RU WG4 M-Plane Specification [5].

• o-ran-sync, as listed in the O-RU WG4 M-Plane Specification [5].
YANG Data organized according to these YANG modules describe the configuration and
capabilities pertaining to network interfaces, respectively S-plane for the O-DU
termination of the O-RAN FH Interface [6].
Version: 229.0.1 10
References
[1] RFC 6020, YANG - A Data Modeling Language for the Network Configuration
Protocol (NETCONF)
[2] RFC 6241, Network Configuration Protocol (NETCONF)
[3] SCF-222, 5G FAPI: PHY API Specification v6.0
[4] O-RAN.WG1.O-RAN-Architecture-Description-v07.00; O-RAN Architecture
Description 7.0
[5] O-RAN.WG4.MP.0-v10.00; O-RAN Management Plane Specification 10.0
[6] O-RAN.WG4.CUS.0-v10.00; O-RAN Control, User and Synchronization Plane
Specification 10.0
[7] Protocol Buffers, https://developers.google.com/protocol-buffers, Current
November 21, 2022
Version: 229.0.1 11

SCF229.0.1 5G FAPI Operations Administration and Maintenance OAM Protocol For Inline High-PHY

Uploaded by

Copyright:

Available Formats

You might also like

SCF229.0.1 5G FAPI Operations Administration and Maintenance OAM Protocol For Inline High-PHY

Uploaded by

Document Information

Original Description:

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

SCF229.0.1 5G FAPI Operations Administration and Maintenance OAM Protocol For Inline High-PHY

Uploaded by

Copyright:

Available Formats

DECEMBER 2022

• access to YANG modules defined outside SCF

• YANG modules pertaining to the O-RU associated with each PHY.

RAN Internal Architecture

• Reading and writing, by a L2/L3 client, of YANG data trees hosted by a L1

• Introduction: This section provides the high-level overview and governing

1.1 Data Tree

Many modern network nodes are parametrized by capability and configuration

L1 Data Operations L2/L3

Figure 1-1 Client server architecture for data model access

scoped (e.g., filtered) per the PHY ID.

1.2 L2/L3 as Client

As an example salient to this specification, data organized according to the O-RU

As another example salient to this specification, data [5] parametrizing O-RAN

1.4 Other Servers

1.5 Non-YANG Data

2.1 Read Procedure

L2/L3 Client L1 Server

alt get outcomes

GetResp Error(type, severity, ...)

Figure 2-1 Read procedure

2.2 Write Procedure

EditConfigResp Error(type, severity, ...)

Figure 2-2 Write procedure

3.1 General Message Format

Figure 3-1 General P9 message format

3.1.1 Message Header

Figure 3-2 P9 interface message header

3.1.2 Message Body

The body of the P9 interface message can be a request or response message.

Figure 3-3 P9 interface message body

3.3 Request and Response Messages

Figure 3-4 P9 interface request and response messages

3.3.1 Get Message

Figure 3-5 P9 interface get message

3.3.2 GetResp Message

Figure 3-6 P9 interface GetResp message

3.3.3 EditConfig Message

Figure 3-7 P9 interface EditConfig message

• “operation” attribute: only merge

3.3.4 EditConfigResp Message

The EditConfigResp message is used to return the status of an EditConfig request

Figure 3-8 P9 interface EditConfigResp message

3.3.5 Status and Error Messages

message Error { // Type of error as defined in RFC 6241 section 4.3

Figure 3-9 P9 interface Status and Error messages

4.1 YANG Modules describing the O-RU

The following YANG modules are supported:

4.2 YANG Modules describing the O-RAN Fronthaul termination at the

The following YANG modules are supported:

• o-ran-interfaces, as listed in the O-RU WG4 M-Plane Specification [5].

You might also like