Scf222!02!5g-Fapi Phy Spi Spec-Mar20

DOCUMENT
222.10.02
5G PHY FAPI
Specification
March 2020
www.smallcellforum.org
SCF
RELEASE 10.0 scf.io
Small Cell Forum develops the technical and commercial enablers to

accelerate small cell adoption and drive wide-scale densification.
Broad roll-out of small cells will make high-grade mobile connectivity accessible
and affordable for industries, enterprises and for rural and urban communities.
That, in turn, will drive new business opportunities for a widening ecosystem of
service providers.
Those service providers are central to our work program. Our operator
members establish the requirements that drive the activities and outputs of
our technical groups.
We have driven the standardization of key elements of small cell technology

including Iuh, FAPI, nFAPI, SON, services APIs, TR-069 evolution and the
enhancement of the X2 interface. These specifications enable an open,
multivendor platform and lower barriers to densification for all stakeholders.
Today our members are driving solutions that include:

• 5G Components, Products, Networks
• Dis-aggregated 5G Small Cells
• Planning, Management and Automation
• 5G regulation & safety
• Neutral Hosts & Multi-operator
• Private and Public Network coexistence
• Edge compute with Small Cell Blueprint
• End to end orchestration
The Small Cell Forum Release Program has now established business cases
and market drivers for all the main use cases, clarifying market needs and
addressing barriers to deployment for residential, enterprise, rural & remote,
and urban small cells. It has also established initiatives relating to both public
and private (MNO) coordination. The Small Cell Forum Release Program
website can be found here: www.scf.io
If you would like more information about Small Cell Forum or would
like to be included on our mailing list, please contact:
Email info@smallcellforum.org
Post Small Cell Forum, PO Box 23, GL11 5WA UK
Member Services memberservices@smallcellforum.org

Credits
Author Company
Clare Somerville Intel
Samel Celebi Qualcomm
Jianwei Wu, Vicky Messer Picocom
Zahi Zaltzman Airspan
Reviewer Company
Tom Berko Airspan
N Sreenivas Nokia
Martin Lysejko Picocom
Francois Periard Open Air Interface
Scope
The functional application platform interface (FAPI) is an initiative within the small cell
industry released by the Small Cell Forum, which establishes interoperability and
innovation among suppliers of platform hardware, platform software and application
software by providing a common API around which suppliers can create a competitive
ecosystem. In doing this, we support a long and distinguished engineering tradition of
providing an ‘interchangeability of parts’ to ensure that the systems vendors can take
advantage of the latest innovations in silicon and software with minimum barriers to
entry, and the least amount of custom re-engineering. Hence the specification helps
support an innovative and competitive ecosystem for vendors of 5G small cell
hardware, software and equipment.
For 5G, the FAPI suite comprises three 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] (this document)
The 5G FAPI defines internal interfaces and is agnostic to RAN architecture.
A separate 5G nFAPI specification [SCF225] is currently being developed for the

disaggregated RAN architecture where the split is at the PHY-MAC layer (option 6).
Historical placeholder APIs P1, P2, P3, P6 and M1 are outside the scope of this
document.
The table below summarises all of SCF’s FAPI API specifications, covering 5G, 4G, 3G
and 2G radio access technologies (RATs).
New for 5G
SCF FAPI Support
Small cell
Network RF /
3GPP RAT Type network FAPI (PNF/RU)
Brand name PHY API Monitor Digital
[TS29.274] PHY/MAC split management
Mode Front End
model
2G GSM GERAN [SCF224]
3G UMTS UTRAN [SCF048] [SCF224]
3G HSPA HSPA Evolution [SCF048] [SCF224]
EUTRAN
4G LTE [SCF082] [SCF224] [SCF082] [SCF082] [SCF167]
(WB-E-UTRAN)
4G LTE-NB-IoT EUTRAN-NB-IoT [SCF082] [SCF224] [SCF082] [SCF082] [SCF167]
4G LTE-M LTE-M [SCF082] [SCF224] [SCF082] [SCF082] [SCF167]
5G 5G NR NR [SCF222] [SCF224] [SCF223] [SCF225]* [SCF239]*
*currently under development
SCF FAPI support for different radio access technologies

5G PHY API Executive summary
This document provides the 5G PHY API specification for an application platform
interface (API) between the MAC and PHY protocol layers within the small cell
ecosystem. This functional application platform interface (FAPI) is an internal interface
within an integrated or disaggregated small cell.
This version is for release 15 of 3GPP specification.
The 5G PHY API specification defines a control interface (P5) and a user plane or data
path interface (P7) with the document structured as follows:
Introduction: This section provides the high-level overview and governing principles
of the API.
PHY API Procedures: This section details procedures to configure and control a PHY
entity.
PHY API Messages: This section defines the FAPI specific messages and structures
to implement these procedures
Contents
1. Introduction .................................................................1
1.1 5G NR ............................................................................ 1
1.2 PHY API.......................................................................... 2
2. PHY API Procedures .....................................................4
2.1 Configuration Procedures.................................................. 4
2.1.1 Initialization .................................................................... 4
2.1.2 Termination .................................................................... 9
2.1.3 Restart ......................................................................... 10
2.1.4 Reset ........................................................................... 11
2.1.5 Reconfigure .................................................................. 11
2.1.6 Query .......................................................................... 13
2.1.7 Notification ................................................................... 13
2.2 Slot Procedures ............................................................. 14
2.2.1 SLOT signal .................................................................. 14
2.2.2 SFN/SL Synchronization ................................................. 15
2.2.3 API message order ........................................................ 20
2.2.4 Downlink ...................................................................... 23
2.2.5 Uplink .......................................................................... 32
2.2.6 Precoding and Beamforming ........................................... 38
2.2.7 Error sequences ............................................................ 40
3. PHY API Messages ......................................................43
3.1 General Message Format ................................................ 43
3.2 Message Types .............................................................. 44
3.3 Configuration Messages .................................................. 45
3.3.1 PARAM ......................................................................... 45
3.3.2 CONFIG ........................................................................ 54
3.3.3 Vendor TLVs ................................................................. 61
3.3.4 START .......................................................................... 61
3.3.5 STOP ........................................................................... 62
3.3.6 PHY Notifications ........................................................... 62
3.3.7 Storing Precoding and Beamforming Tables ...................... 63
3.4 Slot Messages ............................................................... 64
3.4.1 Slot.indication ............................................................... 64
3.4.2 DL_TTI.request ............................................................. 65
3.4.3 UL_TTI.request ............................................................. 78
3.4.4 UL_DCI.request ............................................................. 94
3.4.5 SLOT errors .................................................................. 95
3.4.6 Tx_Data.request............................................................ 95
3.4.7 Rx_Data.indication ........................................................ 97
3.4.8 CRC.indication............................................................... 98
3.4.9 UCI.indication ............................................................... 99
3.4.10 SRS.indication ............................................................. 105
3.4.11 RACH.indication .......................................................... 106
References .......................................................................... 108
Tables
Table 2-1 PHY API configuration messages valid in each PHY state ..................4
Table 2-2 Information returned by the PHY during a PARAM message exchange 5
Table 3-1 General PHY API message format................................................ 43
Table 3-2 PHY API message header ........................................................... 43
Table 3-3 General PHY API message structure ............................................ 43
Table 3-4 PHY API message types ............................................................. 44
Table 3-5 PARAM.response message body .................................................. 45
Table 3-6 Error codes for PARAM.response ................................................. 45
Table 3-7 TLV format ............................................................................... 46
Table 3-8 PARAM TLVs ............................................................................. 46
Table 3-9 Cell parameters ........................................................................ 47
Table 3-10 Carrier parameters.................................................................... 49
Table 3-11 PDCCH parameters ................................................................... 49
Table 3-12 PUCCH parameters ................................................................... 50
Table 3-13 PDSCH parameters ................................................................... 51
Table 3-14 PUSCH parameters.................................................................... 52
Table 3-15 PRACH parameters .................................................................... 53
Table 3-16 Measurement parameters .......................................................... 54
Table 3-17 CONFIG.request message body .................................................. 54
Table 3-18 CONFIG.response message body ................................................ 55
Table 3-19 Error codes for CONFIG.response ............................................... 56
Table 3-20 CONFIG TLVs ........................................................................... 56
Table 3-21 Carrier configuration ................................................................. 57
Table 3-22 Cell configuration ...................................................................... 57
Table 3-23 SSB configuration ..................................................................... 58
Table 3-24 PRACH configuration ................................................................. 59
Table 3-25 SSB Table ................................................................................ 60
Table 3-26 TDD table ................................................................................ 61
Table 3-27 Measurement Config ................................................................. 61
Table 3-28 Error codes for START.request ................................................... 62
Table 3-29 Error codes for STOP.request .................................................... 62
Table 3-30 ERROR.indication message body .............................................. 63
Table 3-31 PHY API error codes .................................................................. 63
Table 3-32 Digital Beam Table (DBT) PDU .................................................... 64
Table 3-33 Precoding Matrix (PM) PDU ........................................................ 64
Table 3-34 Slot indication message body ..................................................... 65
Table 3-35 DL_TTI.request message body .................................................. 66
Table 3-36 PDCCH PDU.............................................................................. 68
Table 3-37 DL DCI PDU ............................................................................. 69
Table 3-38 DLSCH PDU .............................................................................. 74
Table 3-39 CSI-RS PDU ............................................................................. 75
Table 3-40 SSB/PBCH PDU ......................................................................... 76
Table 3-41 MAC generated MIB PDU ............................................................ 77
Table 3-42 PHY generated MIB PDU ............................................................ 77
Table 3-43 Tx Precoding and Beamforming PDU ........................................... 78
Table 3-44 UL_TTI.request message body .................................................. 79
Table 3-45 PRACH PDU .............................................................................. 80
Table 3-46 PUSCH PDU .............................................................................. 84
Table 3-47 Optional puschData information .................................................. 85
Table 3-48 Optional puschUci information .................................................... 86
Table 3-49 Optional puschPtrs information ................................................... 87
Table 3-50 Optional dftsOfdm information .................................................... 87
Table 3-51 PUCCH PDU .............................................................................. 91
Table 3-52 SRS PDU.................................................................................. 93
Table 3-53 Rx Beamforming PDU ................................................................ 94
Table 3-54 UL_DCI.request message body .................................................. 94
Table 3-55 Error codes for ERROR.indication generated by DL_TTI.request . 95
Table 3-56 Error codes for ERROR.indication generated by UL_TTI.request . 95
Table 3-57 Error codes for ERROR.indication generated by UL_DCI.request . 95
Table 3-58 TxData.request message ......................................................... 96
Table 3-59 TLV structure ........................................................................... 96
Table 3-60 Error codes for ERROR.indication .............................................. 97
Table 3-61 RX_Data.indication message body ........................................... 98
Table 3-62 CRC.indication message body .................................................. 99
Table 3-63 UCI.indication message body ................................................ 100
Table 3-64 UCI PUSCH PDU...................................................................... 101
Table 3-65 UCI PUCCH Format 0 or 1 PDU ................................................. 102
Table 3-66 UCI PUCCH Format 2, 3 or 4 PDU.............................................. 103
Table 3-67 SR PDU for Format 0 or 1 ........................................................ 103
Table 3-68 HARQ PDU for Format 0 or 1 .................................................... 104
Table 3-69 SR PDU for Format 2, 3 or 4 ..................................................... 104
Table 3-70 HARQ PDU for Format 2, 3 or 4 ................................................ 104
Table 3-71 CSI Part1 PDU ........................................................................ 105
Table 3-72 CSI Part2 PDU ........................................................................ 105
Table 3-73 SRS.indication message body ................................................ 106
Table 3-74 RACH.indication message body .............................................. 107
Figures
Figure 1-1 5G Architecture ..........................................................................1

Figure 1-2 5G FAPI Architecture ...................................................................2
Figure 1-3 5G RAN protocol model................................................................3
Figure 1-4 PHY API interactions ....................................................................3
Figure 2-1 PHY layer state transactions on PHY API configuration messages ......4
Figure 2-2 Initialization procedure ................................................................5
Figure 2-3 PARAM message exchange ...........................................................7
Figure 2-4 CONFIG message exchange .........................................................8
Figure 2-5 START message exchange ...........................................................9
Figure 2-6 Termination procedure .............................................................. 10
Figure 2-7 Restart procedure ..................................................................... 10
Figure 2-8 Reset procedure ....................................................................... 11
Figure 2-9 Major reconfiguration procedure ................................................. 12
Figure 2-10 Minor reconfigure procedure ....................................................... 13
Figure 2-11 Query procedure ....................................................................... 13
Figure 2-12 Notification procedures .............................................................. 14
Figure 2-13 Periodicity of SLOT.indication messages ................................... 15
Figure 2-14 SFN/SL synchronization start-up with L2/L3 master ...................... 16
Figure 2-15 SFN/SL synchronization with L2/L3 master................................... 17
Figure 2-16 SFN/SL synchronization start-up with L1 master ........................... 18
Figure 2-17 SFN/SL synchronization with L1 master ....................................... 19
Figure 2-18 DL message order ..................................................................... 21
Figure 2-19 UL message order ..................................................................... 23
Figure 2-20 Time and frequency structure of the Synchronization Signal Block
(SSB) ...................................................................................... 24
Figure 2-21 Possible SS Block Locations for FR1 (sub6 GHz) deployments ......... 25
Figure 2-22 Possible SS Block locations for FR2 deployments........................... 25
Figure 2-23 PCH procedure ......................................................................... 26
Figure 2-24 DLSCH procedure ..................................................................... 27
Figure 2-25 2-layer DLSCH procedure........................................................... 28
Figure 2-26 Multi-slot DL-SCH procedure ...................................................... 29
Figure 2-27 Downlink reference signals ......................................................... 31
Figure 2-28 Transmit Power Levels ............................................................... 32
Figure 2-29 RACH procedure ....................................................................... 33
Figure 2-30 ULSCH procedure ...................................................................... 34
Figure 2-31 Multi-slot UL-SCH procedure ...................................................... 35
Figure 2-32 SRS procedure ......................................................................... 35
Figure 2-33 CSI procedure .......................................................................... 36
Figure 2-34 SR procedure ........................................................................... 37
Figure 2-35 Uplink reference signals ............................................................. 38
Figure 2-36 Precoding and digital beamforming flow ....................................... 39
Figure 2-37 Overview of digital beam table (DBT) .......................................... 39
Figure 2-38 UL_TTI.request error sequence ................................................. 40
Figure 2-39 DL_TTI.request error sequence ................................................. 41
Figure 2-40 UL_DCI.request error sequence ................................................. 41
Figure 2-41 TX_Data.request error sequence ............................................... 42
1. Introduction
1.1 5G NR
5G NR is standardized by 3GPP (http://www.3gpp.org) and designed as an evolution

to the current 4G LTE wireless network. Requirements for 5G include higher
bandwidth, lower latency, improved reliability and increased density of users; although
not necessarily all at the same time. Instead, three service types are defined
enhanced mobile broadband (eMBB), ultra-reliable low latency (URLLC) and massive
internet of things (mIoT). This wide range of use cases results in flexibility being a key
feature of 5G.
Figure 1-1 shows the architecture of a 5G network. It consists of only two elements;
the 5G Core consisting of the access and mobility function (AMF) and user plane
function (UPF) and the 5G Node B (gNB). The 5G FAPI resides within the gNB element.
The standardized interfaces in 5G network are called NG, Xn and F1. The L1 is not
involved in these interfaces, and they are out of scope for this document.
AMF/UPF
NG NG
gNB
gNB
Xn gNB-CU
F1 F1
gNB- gNB-
DU DU
Figure 1-1 5G Architecture
For 5G FAPI the MAC and PHY reside is a single element resulting in FAPI existing as
an internal interface within the gNB, as shown in Figure 1-2.
Report title: 5G PHY FAPI Specification

Issue date: 11 March 2020
Version: 1.0.5 1
gNB
MAC
5G P19 P7 P5
FAPI
vendor ext
data PHY ctrl
PHY
incl. digital
frontend beam forming
ctrl
FrontEnd
Incl. DFE & RF
Figure 1-2 5G FAPI Architecture
The introduction of 5G nFAPI for split 6 with MAC and PHY residing in different physical
locations, a central unit (S-CU) and distributed unit (S-RU), is outside the scope of this
document version.
1.2 PHY API
The 5G FAPI PHY API, defined in this document, resides within the gNB component
with Figure 1-3 showing the protocol model for the gNB defined in the 5G-RAN
architectural standard [TS38.401]. It highlights the separation of control- and data-
plane information, which is maintained throughout the 5G NR network. Both control-
and data-plane information is passed through the PHY API, however, each API
message contains either control- or data-plane information, but never both.

Version: 1.0.5 2
Radio
Control Plane Data Plane
Network
Application
Layer Protocol
F1 F1
Transport
Signalling Data
Network Bearers Bearers
Layer
PHY API
PHY
Figure 1-3 5G RAN protocol model
Figure 1-4 provides an example of how the different L2/L3 protocol layers will interact
with the PHY API. In this example, a PHY control entity is responsible for configuration
procedures (P5). The MAC layer is responsible for the exchange of data-plane
messages with the PHY (P7). The PHY configuration sent over the P5 interface may be
determined using SON techniques, information model parameters sent from an OAM
system, or a combination of both methods. If carrier aggregation is supported then
one instance of the PHY API exists for each component carrier as defined in
[TS38.104].
RRC
PHY
PDCP
Control
RLC
L2/L3
Scheduler MAC
Software
P5 P7
PHY API
PHY
PHY
PHY
Figure 1-4 PHY API interactions

Version: 1.0.5 3
2. PHY API Procedures
This section gives an overview of the procedures which use the PHY API. These
procedures are split into three groups, namely, configuration procedures, slot
procedures and beamforming/RF procedures. Configuration procedures handle the
management of the PHY layer and are expected to occur infrequently. Slot procedures
determine the structure of each slot and operate with a periodicity based on the
subcarrier spacing numerology, namely 125us, 250us, 500us or 1ms periodicity.
2.1 Configuration Procedures
The configuration procedures supported by the PHY API are:
• Initialization
• Termination
• Restart
• Reset
• Error notification
These procedures will move the PHY layer through the IDLE, CONFIGURED and
RUNNING states, as shown in Figure 2-1. A list of the PHY API configuration messages
which are valid in each state is given in Table 2-1 .
CONFIG.request
CONFIG.request
IDLE CONFIGURED
PARAM.request
START.request STOP.request
PARAM.request
RUNNING
CONFIG.request
Figure 2-1 PHY layer state transactions on PHY API configuration messages
Idle State Configured State Running State

PARAM.request PARAM.request CONFIG.request
CONFIG.request CONFIG.request STOP.request
START.request
Table 2-1 PHY API configuration messages valid in each PHY state
2.1.1 Initialization
The initialization procedure moves the PHY from the IDLE state to the RUNNING state,
via the CONFIGURED state. An overview of this procedure is given in Figure 2-2, the
different stages are:

Version: 1.0.5 4
• The PARAM message exchange procedure
• The CONFIG message exchange procedure
• The START message exchange procedure
The initialization procedure is completed when the PHY sends the L2/L3 software a
SLOT.indication message.
The remainder of this section describes the PARAM, CONFIG and START message
exchange procedures.
Figure 2-2 Initialization procedure
The PARAM message exchange procedure is shown in Figure 2-3. Its purpose is to
allow the L2/L3 software to collect information about the PHY configuration and
current state. The information returned by the PHY depends on its state, and is
described in Table 2-2. The PARAM message exchange is optional.
PHY state Information returned by PHY
IDLE The PHY indicates which capabilities it supports
CONFIGURED The PHY returns its current configuration
RUNNING The PHY returns invalid state
Table 2-2 Information returned by the PHY during a PARAM message exchange
From Figure 2-3 it can be seen that the PARAM message exchange procedure is
initiated by the L2/L3 software sending a PARAM.request message to the PHY. It is
recommended that the L2/L3 software starts a guard timer to wait for the response
from the PHY. If the PHY is operating correctly it will return a PARAM.response
message. In the IDLE and CONFIGURED states this message will include the current
PHY state and a list of configuration information, as described in Table 2-2. In the
RUNNING state this message will indicate an INVALID_STATE error, to determine the

Version: 1.0.5 5
PHY capabilities it must be moved to the CONFIGURED state using the termination
procedure. If the guard timer expires before the PHY responds this indicates the PHY is
not operating correctly. This must be rectified before further PHY API commands are
used; the rectification method is outside the scope of this document.
The CONFIG message exchange procedure is shown in Figure 2-4. Its purpose is to
allow the L2/L3 software to configure the PHY. It can be used when the PHY is in any
state. The procedure has slight differences depending on the PHY state, for clarity
each case is described separately.
If the PHY is in the IDLE state the CONFIG.request message, sent by the L2/L3
software, must include all mandatory TLVs. The mandatory TLVs are indicated by the
PHY in the PARAM.response message. If all mandatory TLVs are included, and set to
values supported by the PHY, L1 will return a CONFIG.response message indicating it
is successfully configured and has moved to the CONFIGURED state. If the
CONFIG.request message has missing mandatory TLVs, invalid TLVs, or unsupported
TLVs, the PHY will return a CONFIG.response message indicating an incorrect
configuration. In this case, it will remain in the IDLE state and all received TLVs will be
ignored.

Version: 1.0.5 6
Figure 2-3 PARAM message exchange
If the PHY is in the CONFIGURED state the CONFIG.request message, sent by the
L2/L3 software, may include only the TLVs that are required to change the PHY to a
new configuration. If the PHY supports these new values, it will return a
CONFIG.response message indicating it has been successfully configured. However, if
the CONFIG.request message includes invalid TLVs, or unsupported TLVs, the PHY will
return a CONFIG.response message indicating an incorrect configuration. In this case
all received TLVs will be ignored and the PHY will continue with its previous
configuration. In both cases, if the PHY receives a CONFIG.request while in the
CONFIGURED state it will remain in the CONFIGURED state.
If the PHY is in the RUNNING state then a limited subset of CONFIG TLVs may be sent
in a CONFIG.request message. The permitted TLVs are indicated by the PHY in
PARAM.response. If the CONFIG.request message has invalid TLVs, or TLVs which
must not be reconfigured in the RUNNING state, the PHY will return a

Version: 1.0.5 7
CONFIG.response message indicating an incorrect configuration. In this case, it will
remain in the RUNNING state and all received TLVs will be ignored.
Figure 2-4 CONFIG message exchange
The START message exchange procedure is shown in Figure 2-5. Its purpose is to
instruct a configured PHY to start transmitting as a gNB. The L2/L3 software initiates
this procedure by sending a START.request message to the PHY. If the PHY is in the
CONFIGURED state, it will issue a SLOT indication. After the PHY has sent its first
SLOT.indication message it enters the RUNNING state.
If the PHY receives a START.request in either the IDLE or RUNNING state it will return
an ERROR.indication including an INVALID_STATE error.

Version: 1.0.5 8
Figure 2-5 START message exchange
2.1.2 Termination
The termination procedure is used to move the PHY from the RUNNING state to the
CONFIGURED state. This stops the PHY transmitting as a gNB. The termination
procedure is shown in Figure 2-6 and initiated by the L2/L3 software sending a
STOP.request message.
If the STOP.request message is received by the PHY while operating in the RUNNING
state, it will stop all TX and RX operations and return to the CONFIGURED state. When
the PHY has completed its stop procedure a STOP.indication message is sent to the
L2/L3 software.
If the STOP.request message was received by the PHY while in the IDLE or
CONFIGURED state, it will return an ERROR.indication message including an
INVALID_STATE error. However, in this case the PHY was already stopped.

Version: 1.0.5 9
Figure 2-6 Termination procedure
2.1.3 Restart
The restart procedure is shown in Figure 2-7. It can be used by the L2/L3 software
when it needs to stop transmitting, but later wants to restart transmission using the
same configuration. To complete this procedure the L2/L3 software can follow the
STOP message exchange shown in Figure 2-6. This moves the PHY to the
CONFIGURED state. To restart transmission it should follow the START message
exchange, shown in Figure 2-5, moving the PHY back to the RUNNING state.
Figure 2-7 Restart procedure

Version: 1.0.5 10
2.1.4 Reset
The reset procedure is shown in Figure 2-8. This procedure is used when the L2/L3
software wants to return the PHY to the IDLE state. This can only be achieved by
terminating the PHY (as shown in Figure 2-6) and then resetting the PHY. The method
for resetting the PHY will be implementation specific and is outside the scope of this
document.
Figure 2-8 Reset procedure
2.1.5 Reconfigure
Two methods of reconfiguration are supported by the PHY. A major reconfiguration

where the PHY is stopped, and a minor reconfiguration where the PHY continues
running.
The major reconfigure procedure is shown in Figure 2-9. It is used when the L2/L3
software wants to make significant changes to the configuration of the PHY. The STOP
message exchange, shown in Figure 2-6, is followed to halt the PHY and move it to the
CONFIGURED state. The CONFIG message exchange, shown in Figure 2-4, is used to
reconfigure the PHY. Finally, the START message exchange, shown in Figure 2-5, is
followed to start the PHY and return it to the RUNNING state.

Version: 1.0.5 11
Figure 2-9 Major reconfiguration procedure
The minor reconfiguration procedure is shown in Figure 2-10. It is typically used in

conjunction with a RRC system information update.
In the slot where the L2/L3 software requires the configuration change it sends the
CONFIG.request message to the PHY. Only a limited subset of CONFIG TLVs may be
sent, these are indicated by the PHY in PARAM.response. TLVs included in the
CONFIG.request message for slot N will be applied at the SFN/SL given in the
CONFIG.request message. Reconfiguring the PHY while in the RUNNING state has a
further restriction, the CONFIG.request message must be sent before the
DL_TTI.request and UL_TTI.request message.

Version: 1.0.5 12
Figure 2-10 Minor reconfigure procedure
2.1.6 Query
The query procedure is shown in Figure 2-11. It is used by the L2/L3 software to
determine the configuration and operational status of the PHY. The PARAM message
exchange, shown in Figure 2-3, is used. This signalling sequence can be followed when
the PHY is stopped, in the IDLE state and, optionally, the CONFIGURED state.
Figure 2-11 Query procedure
2.1.7 Notification
The notification procedure is shown in Figure 2-12. The PHY sends a notification
message when it has an event of interest for the L2/L3 software. Currently, there is
one notification message called ERROR.indication.

Version: 1.0.5 13
The ERROR.indication message has already been mentioned in multiple procedures.
It is used by the PHY to indicate that the L2/L3 software has sent invalid information
to the PHY.
L1 PHY
L2/L3 software
alt Notification type

[PHY has detected error]
ERROR.indication()
(from Actors)
Figure 2-12 Notification procedures
2.2 Slot Procedures
The slot procedures have two purposes. Firstly, they are used to control the DL and UL
frame structures. Secondly, they are used to transfer the slot data between the L2/L3
software and PHY. The slot procedures supported by the PHY API are:
• Transmission of a 125us, 250us, 500us or 1ms SLOT message

• Synchronization of SFN/SLot between the L2/L3 software and PHY
• Transmission of the BCH transport channel
• Transmission of the PCH transport channel
• Transmission of the DL-SCH transport channel
• Transmission of the downlink control information (DCI)
• Transmission of the CSI reference signal
• Reception of the RACH transport channel
• Reception of the UL-SCH transport channel
• Reception of the uplink control information (UCI)
• Reception of the sounding reference signal
2.2.1 SLOT signal
A SLOT.indication message is sent from the PHY, to the L2/L3 software, indicating
the start of a slot.
The periodicity of the SLOT.indication message is dependent on the numerology and

shown in Figure 2-13 where the number of SLOT.indication messages per subframe
is highlighted.

Version: 1.0.5 14
Subcarrier
Spacing
Numerology
SLOT.indication
SLOT.indication
SLOT.indication
SLOT.indication
SLOT.indication
SLOT.indication
SLOT.indication
SLOT.indication
0 1 2 3 4 5 6 7 u=3
SLOT.indication
SLOT.indication
SLOT.indication
SLOT.indication
0 1 2 3 u=2
SLOT.indication
SLOT.indication
0 1 u=1
SLOT.indication
0
u=0
N+0 N+1 N+2 N+3 N+4 N+5 N+6 N+7 N+8 N+9
Subframe 1ms
Radio Frame 10ms
Figure 2-13 Periodicity of SLOT.indication messages
2.2.2 SFN/SL Synchronization
The SFN/SL synchronization procedure is used to maintain a consistent SFN/SL value

between the L2/L3 software and PHY. Maintaining this synchronization is important
since different subframes and slots have different structures.
Two options are provided by the PHY API; the first option configures the PHY to use
the SFN/SL value provided by the L2/L3 software. The second option configures the
PHY to initialize the SFN/SL and ensure the L2/L3 software remains synchronous. The
synchronization option is selected at compile time. For each option two procedures
are described, the initial start-up synchronization and the maintenance of the
synchronization.
2.2.2.1 L2/L3 software is master
The SFN/SL synchronization start-up procedure, where the L2/L3 software is master,
is given in Figure 2-14. The start-up procedure followed is:
• After successful configuration the L2/L3 software sends a START.request

message to move the PHY to the RUNNING state
• When the L2/L3 software is configured as master the initial PHY SFN/SL = M,
where M could be any value. In the SLOT.indication message, SFN/SL = M
• The L2/L3 software sends a DL_TTI.request message to the PHY containing
the correct SFN/SL = N
• The PHY uses the SFN/SL received from the L2/L3 software. It changes its
internal SFN/SL to match the value provided by the L2/L3 software

Version: 1.0.5 15
Figure 2-14 SFN/SL synchronization start-up with L2/L3 master
The SFN/SL synchronization maintenance procedure is shown in Figure 2-15. In this

example the L1 PHY is expecting the next DL_TTI.request to contain information
regarding frame M. The procedure followed is:
• The PHY sends the SLOT.indication message with SFN/SL = M.

• The L2/L3 software sends a DL_TTI.request or UL_TTI.request message to
the PHY containing SFN/SL = N
• If SFN/SL M = N
• The PHY received the SFN/SL it was expecting. No SFN/SL

synchronization is required
• If SFN/SL M ≠ N
• The PHY received a different SFN/SL from the expected value. SFN/SL
• The PHY uses the SFN/SL received from the L2/L3 software. It changes
its internal SFN/SL to match the value provided by the L2/L3 software
• The PHY returns an ERROR.indication message indicating the mismatch
This SFN/SL synchronization procedure assumes the L2/L3 software is always correct.
However, it's possible the SFN/SL synchronization was unintended, and due to a L2/L3
software issue. The generation of an ERROR.indication message, with expected and
received SFN/SL values, should allow the L2/L3 software to perform a correction with
a further SFN/SL synchronization.

Version: 1.0.5 16
Figure 2-15 SFN/SL synchronization with L2/L3 master
2.2.2.2 L1 PHY is master
The SFN/SL synchronization start-up procedure, where the L1 software is master, is

given in Figure 2-16. The start-up procedure followed is:
• After successful configuration the L2/L3 software sends a START.request

message to move the PHY to the RUNNING state

Version: 1.0.5 17
• If the L1 software is configured as master the initial PHY SFN/SL = M. The
value of M is not deterministic, and could have been set by an external
mechanism, such as GPS. The PHY sends a SLOT.indication message to the
L2/L3 software, with SFN/SL = M. The L2/L3 software uses the SFN/SL
received from the PHY. It changes its internal SFN/SL to match the value
provided by the PHY
the PHY containing SFN/SL = M
Figure 2-16 SFN/SL synchronization start-up with L1 master
The SFN/SL synchronization maintenance procedure is shown in Figure 2-17. In this

example, the L1 PHY is expecting the next DL_TTI.request or UL_TTI.request to
contain information regarding frame M. The procedure followed is:
• The PHY sends a SLOT.indication message to the L2/L3 software, with

SFN/SL = M
the PHY containing SFN/SL = N
• If SFN/SL M = N
• The PHY received the SFN/SL it was expecting. No SFN/SL

• If SFN/SL M ≠ N

Version: 1.0.5 18
• The PHY received a different SFN/SL from the expected value. SFN/SL
• The PHY discards the received DL_TTI.request or UL_TTI.request
message
• The PHY returns an ERROR.indication message indicating the mismatch
This SFN/SL synchronization procedure will continue to discard DL_TTI.request

request or UL_TTI.request messages and emit ERROR.indication messages until
the L2/L3 software corrects its SFN/SL value.
Figure 2-17 SFN/SL synchronization with L1 master

Version: 1.0.5 19
2.2.3 API message order
The PHY API has constraints of when certain messages can be sent, or will be
received, by the L2/L3 software.
The downlink API message constraints are shown in Figure 2-18:
• The SFN/SL included in the SLOT.indication message is expected in the

corresponding DL_TTI.request
• If the PHY is being reconfigured using the CONFIG.request message, this
must be the first message for the slot.
• If the Skip_blank_DL_CONFIG option is indicated during the PARAM
procedure, DL_TTI.request can be optionally skipped when there is nothing
to schedule. Otherwise, DL_TTI.request must be sent for every downlink
slot and must be the next message.
• If the Skip_blank_UL_CONFIG option is indicated during the PARAM
procedure, UL_TTI.request can be optionally skipped when there is nothing
to schedule. Otherwise, UL_TTI.request must be sent for every uplink slot
and must be the next message
• The TX_Data.request and UL_DCI.request messages are optional. It is not
a requirement that they are sent in every downlink slot.
• There must be only 1 DL_TTI.request, 1 UL_TTI.request and 1
UL_DCI.request for a slot.
• There can be more than one instance of the TX_Data.request if mini-slot is
used. This allows the PHY to minimize latency.

Version: 1.0.5 20
Figure 2-18 DL message order
The uplink API message constraints are shown in Figure 2-19:
• The UL API messages are optional. It is not a requirement that they are sent
in every slot.

Version: 1.0.5 21
• If present, the messages can be in any order
• The CRC.indication message is included if uplink data PDUs were

expected in the slot.
• The RX_Data.indication message is included if uplink data PDUs were
expected in the slot.
• The UCI.indication message is included if UCI PDUs were expected in
the slot.
• The RACH.indication message is included if any RACH preambles were
detected in the slot
• The SRS.indication message is included if any sounding reference
symbol information is expected in the slot.
• There is only one instance of the CRC.indication, RX_Data.indication,

UCI.indication, RACH.indication, and SRS.indication messages per slot
and subcarrier-spacing.
• There can be more than one instance of the CRC.indication,
RX_Data.indication, UCI.indication, RACH.indication, and
SRS.indication messages if more than one subcarrier spacing finishes in
the same slot. As an example, from Figure 2-13, slot 7 for u=3 completes at
the same time as slot 1 for u=1.
• There can be more than one instance of the CRC.indication and
RX_Data.indication if mini-slot is used. This allows the PHY to minimize
latency.

Version: 1.0.5 22
Figure 2-19 UL message order
2.2.4 Downlink
The procedures relating to downlink transmission are described in this Section.

Version: 1.0.5 23
2.2.4.1 BCH
The BCH transport channel is used to transmit the Master Information Block (MIB)
information to the UE [TS38.331]. It has a periodicity of 80ms. BCH payload is carried
using the PBCH physical channel. Together with the PSS and the SSS synchronization
signals PBCH forms the Synchronization Signal Block (SSB) as shown in Figure 2-20
[TS38.300].
Figure 2-20 Time and frequency structure of the Synchronization Signal Block (SSB)
SS blocks can be transmitted in different beams in a time-multiplexed fashion. The set

of SS blocks within a beam-sweep is called an SS burst
The periodicity of the SS burst set varies from 5 to 160ms. All SS blocks in an SS
burst set needs to be transmitted within 5ms. The SS blocks can be transmitted only
in predetermined time slots. Depending on the band of deployment the location of the
SSB allowed slots vary as shown in Figure 2-21 and Figure 2-22.

Version: 1.0.5 24
Figure 2-21 Possible SS Block Locations for FR1 (sub6 GHz) deployments
Figure 2-22 Possible SS Block locations for FR2 deployments
2.2.4.2 PCH
The PCH transport channel is used to transmit paging messages to the UE. The UE has
specific paging occasions where it listens for paging information Figure 2-23. The
L2/L3 software is responsible for calculating the correct paging occasion for a UE. The
PHY is only responsible for transmitting PCH PDUs when instructed by the
DL_TTI.request message.
The PCH procedure is shown in Figure 2-23. To transmit a PCH PDU the L2/L3
software must provide the following information:
• In DL_TTI.request a PDSCH PDU and PDCCH PDU are included.

Version: 1.0.5 25
• In TX_Data.request a MAC PDU containing the paging message is included.
Figure 2-23 PCH procedure
2.2.4.3 DL-SCH
The DL-SCH transport channel is used to send data from the gNB to a single UE. HARQ
is always applied on the DL-SCH transport channel. Therefore, together with
scheduling downlink transmissions the L2/L3 software must schedule uplink bandwidth
for the UE to return an ACK/NACK response.
The procedure for the DL-SCH transport channel is shown in Figure 2-24.To transmit a
DL-SCH PDU the L2/L3 software must provide the following information:
• In DL_TTI.request a PDSCH PDU and PDCCH PDU are included. The PDCCH
PDU contains control regarding the DL frame transmission
• In TX_Data.request a MAC PDU containing the data is included
• At the expected slot UCI HARQ information is included in a later
UL_TTI.request, where the timing of this message is variable. The HARQ can
be sent on the PUSCH or PUCCH, therefore, the information of the HARQ
response on the uplink is sent in either:
• PUSCH PDU – is used if the UE is scheduled to transmit data and the

ACK/NACK response
• PUCCH PDU – is used if the UE is just scheduled to transmit the
ACK/NACK response
• The PHY will return the ACK/NACK response information in the

UCI.indication message

Version: 1.0.5 26
Figure 2-24 DLSCH procedure
With DCI Format 1-1 the DL SCH channel can send two data transport blocks to a UE,
this requires a single PDCCH (DCI) PDU, a single PDSCH PDU and two MAC PDUs. The
procedure is shown in Figure 2-25. To initiate a transmission of two data transport
blocks the L2/L3 software must provide the following information:
• In the first transmission slot in the DL_TTI.request a PDSCH and PDCCH

(DCI) PDU is included. The PDCCH PDU contains control regarding the DL
frame transmission. A PDSCH PDU includes two codewords, one for each
transport block specified in the DCI PDU.
• In TX_Data.request two MAC PDUs containing the data are included.
(The remaining behaviour is identical to single-layer transmission.)

Version: 1.0.5 27
Figure 2-25 2-layer DLSCH procedure
Multi-slot transmission is also an option for the DL-SCH, where the same MAC PDU is
transmitted for N slots. The procedure is shown in Figure 2-26, and the L2/L3 must
provide the following information:
• In DL_TTI.request a PDSCH PDU and PDCCH (DCI) PDU is included. The

PDCCH PDU contains control regarding the DL frame transmission and the UE
will have previously been configured to be aware that multi-slot transmission
is used.
• In TX_Data.request a MAC PDUs containing the data is included.
• The multi-slot transmission can be over 2,4 or 8 slots and for the remaining
slots the L2/L3 software must provide the following information:
• In DL_TTI.request a PDSCH PDU is included. The PDSCH PDU contains

the information for this slot, for example, in multi-slot transmission the
incremental redundancy version changes per slot.
• In TX_Data.request a MAC PDUs containing the data is included
(The remaining behaviour is identical to single-layer transmission.)

Version: 1.0.5 28
Figure 2-26 Multi-slot DL-SCH procedure
2.2.4.4 Downlink Reference Signals
The downlink includes several reference signals:
• DMRS for PDSCH and PDCCH

• PTRS for PDSCH
• CSI-RS
The reference signals transmitted for either PDSCH or PDCCH are included in the
DL_TTI.request PDSCH or PDCCH PDUs, respectively. However, to transmit a CSI-RS
the DL_TTI.request includes a CSI-RS PDU. This behaviour is shown below in Figure
2-27, where:
• For a DL data transmission DMRS is included for both PDSCH and PDCCH

Version: 1.0.5 29
• In DL_TTI.request the PDSCH and PDCCH PDUs are included, these
PDUs include DMRS information.
• A TX_Data.request is sent to the PHY including the MAC PDU
• The MAC PDU is sent to the UE with DMRS in both the PDSCH and
PDCCH transmission.
• For a DL data transmission optionally PTRS can be enabled
• In DL_TTI.request the PDSCH and PDCCH PDUs are included. The

PDSCH PDUs will indicate that optional PTRS is included and both PDUs
include DMRS information.
• A TX_Data.request is sent to the PHY including the MAC PDU
• The MAC PDU is sent to the UE with PTRS in the PDSCH transmission and
DMRS in both the PDSCH and PDCCH transmission.
• CSI-RS transmission is not dependent on PDSCH transmission, instead it can

be sent to a UE in the same slot as a PDSCH transmission, or in a slot with no
PDSCH transmission for the UE.
• In DL_TTI.request the CSI-RS PDU is included. This results in a CSI-RS

transmission to the UE.

Version: 1.0.5 30
Figure 2-27 Downlink reference signals
2.2.4.5 Transmit Power Levels
The transmit power levels are included in the DL_TTI.request message (PDSCH,
PDCCH, CSI-RS and SSB) PDUs and shown in Figure 2-28. The PDUs and respective
power offset values included are:
• PDCCH PDU
• βPDCCH_0_1 (beta_PDCCH_1_0)
• powerControlOffsetSS
• PDSCH PDU
• powerControlOffset
• βDMRS (numDmrsCdmGrpsNoData and dmrsConfigType)
• CSI-RS PDU

Version: 1.0.5 31
• powerControlOffset
• SSB PDU
• βPSS - (betaPSS)
NZP CSI_RS,
PDCCH & PDDCH DMRS
powerControlOffset
PDCCH & PDCCH DMRS for format1_0

SI_RNTI, P-RNTI, RA-RNTI PDSCH
powerControlOffsetSS
βDMRS
PDSCH DMRS
βPDCCH_1_0
PSS
βPSS
SSS/PBCH/PBCH DMRS
Figure 2-28 Transmit Power Levels
2.2.5 Uplink
The procedures relating to uplink reception are described in this Section.
2.2.5.1 RACH
The RACH transport channel is used by the UE to send data to the gNB when it has no
scheduled resources. Also, the L2/L3 software can indicate to the UE that it should
initiate a RACH procedure.
In the scope of the PHY API, the RACH procedure begins when the PHY receives an
UL_TTI.request message indicating the presence of a RACH.
The RACH procedure is shown in Figure 2-29. To configure a RACH procedure the
L2/L3 software must provide the following information:
• The UL_TTI.request is sent to the PHY including a RACH PDU.

• If a UE decides to RACH, and a preamble is detected by the PHY:
• The PHY will include 1 RACH PDU for each FD occasion in the
RACH.indication message. This RACH PDU includes all detected
preambles
• If no RACH preamble is detected by the PHY, then no RACH.indication

message is sent

Version: 1.0.5 32
Figure 2-29 RACH procedure
2.2.5.2 UL-SCH
The UL-SCH transport channel is used to send data from the UE to the gNB. HARQ is
always applied on the UL-SCH transport channel and the ACK/NACK value is indicated
when the next transmission for the HARQ process is scheduled via DCI. Therefore,
included in the next iteration of this procedure.
The procedure for the UL-SCH transport channel is shown in Figure 2-30. To transmit
an UL-SCH PDU the L2/L3 software must provide the following information:
• Within the UL_DCI.request for slot N a DCI PDU is included. The DCI PDU
contains control information regarding the UL frame transmission being
scheduled and indicates new data or retransmission for a specified HARQ
process.
• In UL_TTI.request for slot N+K1 an ULSCH PDU is included, where the
value of K1 is variable.
• The PHY will return CRC information for the received data in a the
CRC.indication message
• The PHY will return the received uplink data in the RX_Data.indication
message.
• If UCI information was expected in the uplink slot, the PHY will return the
UCI.indication message.

Version: 1.0.5 33
Figure 2-30 ULSCH procedure
Multi-slot transmission is also an option for the UL-SCH with configured grant, where
the same MAC PDU is transmitted for N slots. The procedure is shown in Figure 2-31,
and the L2/L3 must provide the following information:
• For each slot in the PUSCH transmission
• In UL_TTI.request for slot N+M a PUSCH PDU is included, the UE will

have previously been configured to be aware that multi-slot transmission
is used.
• The PHY will return CRC information for the received data in a the
CRC.indication message
• The PHY will return the received uplink data in the RX_Data.indication
message.

Version: 1.0.5 34
Figure 2-31 Multi-slot UL-SCH procedure
2.2.5.3 SRS
The sounding reference signal (SRS) is used by L2/L3 software to determine the
quality of the uplink channel. The SRS procedure is shown in Figure 2-32. To schedule
a SRS the L2/L3 software must provide the following information:
• In UL_TTI.request a SRS PDU is included.

• The PHY will return the SRS response to the L2/L3 software in the
SRS.indication message
Figure 2-32 SRS procedure

Version: 1.0.5 35
2.2.5.4 CSI
The CSI reporting mechanism is used by the L2/L3 software to determine the quality
of the downlink channel. The CSI reporting procedure is shown in Figure 2-33. To
schedule a CSI report the L2/L3 software must provide the following information:
• For an aperiodic report the PDCCH PDU is included in the UL_DCI.request.

This instructs the UE to send a CSI report. For periodic CSI report no explicit
DCI information is sent.
• In the UL_TTI.request, where the L2/L3 software is expecting a CSI report:
• If a PUSCH is scheduled for UCI then a PUSCH PDU is included with the
CSI configuration information.
• Otherwise, a PUCCH is scheduled with the CSI configuration information.
• The PHY will return the CSI report to the L2/L3 software in the
UCI.indication message
Figure 2-33 CSI procedure
2.2.5.5 SR
The scheduling request (SR) procedure is used by the UE to request additional uplink
bandwidth. The L2/L3 software configures the SR procedure during the RRC

Version: 1.0.5 36
connection procedure. The SR procedure is shown in Figure 2-34. To schedule a SR
the L2/L3 software must provide the following information:
• In UL_TTI.request a PUCCH PDU is included.

• The PHY will return the SR to the L2/L3 software in the UCI.indication
message.
Figure 2-34 SR procedure
2.2.5.6 Uplink Reference Signals
The downlink includes several reference signals:
• DMRS for PUSCH and PUCCH

• PTRS for PUSCH
• SRS
The reference signals transmitted for either PUSCH or PUCCH are included in the
UL_TTI.request PUSCH or PUCCH PDUs, respectively. However, to transmit a SRS
the UL_TTI.request includes a SRS PDU. The SRS PDU is described in Section
2.2.5.3, while the other uplink reference signals are described below in Figure 2-35,
where:
• For a UL data transmission DMRS is included for PUSCH
• In UL_TTI.request the PUSCH PDU is included, this PDU includes DMRS

information.
• The MAC PDU is sent from the UE with DMRS.
• For a UL data transmission optionally PTRS can be enabled
• In UL_TTI.request the PUSCH PDUs will indicate that optional PTRS is

included and DMRS is included.
• The MAC PDU is sent from the UE with PTRS and DMRS.
• For a UL UCI transmission DMRS is included for PUCCH

Version: 1.0.5 37
• In UL_TTI.request the PUCCH PDU is included, this PDU includes DMRS
information.
• The UCI is sent from the UE with DMRS.
Figure 2-35 Uplink reference signals
2.2.6 Precoding and Beamforming
The precoding and beamforming parameters are defined to be flexible and support
varying levels of sophistication.
The precoding and beamforming is defined in tables loaded into the PHY at
configuration time. In slot messages a precoding index and/or beamforming index is
included in each PDU.
Precoding and digital beamforming can be viewed as a cascade of two matrix

multiplications PM and DB as depicted in Figure 2-36. For precoding operation an
index to a pre-stored precoding matrix PM(idx) is specified in the message. Digital
beamforming is represented by a matrix DB. For efficient messaging columns of DB
are picked from a pre-stored digital beamforming table (DBT) as illustrated in Figure
2-37. It suffices to specify the index of the beam to be applied for each input port in
the message. Baseband ports shown in Figure 2-36 are logical entities that may be
further processed by a digital frontend (DFE) unit. Within the context of 5GNR a
baseband port typically corresponds to component carrier that is handled by a specific
RF path (i.e. TXRU).

Version: 1.0.5 38
Figure 2-36 Precoding and digital beamforming flow
X: precoder input vector of size (L×1)

Y: precoder output vector of size (P×1)
Z: digital beamformer output vector of size (M×1)
PM: Precoding matrix of size (P×L)
DB: digital beam forming matrix of size (M×P)
Y = PM × X
Z = DB × Y
Figure 2-37 Overview of digital beam table (DBT)

Version: 1.0.5 39
2.2.7 Error sequences
The error sequences used for each slot procedure are shown in Figure 2-38 to Figure
2-41. In all slot procedures errors that are detected by the PHY are reported using the
ERROR.indication message. In Section 3, the PHY API message definitions include a
list of error codes applicable for each message.
The DL_TTI.request, UL_TTI.request, UL_DCI.request and TX_Data.request

messages include information destined for multiple UEs. An error in information
destined for one UE can affect a transmission destined for a different UE. For each
message the ERROR.indication sent by the PHY will return the first error it
encountered.
If the L2/L3 software receives an ERROR.indication message for DL_TTI.request,

UL_TTI.request, UL_DCI.request or TX_Data.request, it should assume that the UE
did not receive data and control sent in this slot. This is similar to the UE experiencing
interference on the air-interface and 5G mechanisms, such as, HARQ and ARQ, will
enable the L2/L3 software to recover.
Figure 2-38 UL_TTI.request error sequence

Version: 1.0.5 40
Figure 2-39 DL_TTI.request error sequence
Figure 2-40 UL_DCI.request error sequence

Version: 1.0.5 41
Figure 2-41 TX_Data.request error sequence

Version: 1.0.5 42
3. PHY API Messages
This section provides a description of the PHY API message formats. It defines the PHY
API message header, the message bodies and the error codes associated with the PHY
API.
3.1 General Message Format
The general message format of the PHY API is shown in Table 3-1, where it can be
seen that there is a top structure of 1 or more PHY API messages. This permits the
optional bundling of messages and the inclusion of vendor specific messages.
Description
PHY API Message Header (see Table 3-2)
PHY API Message1 (see Table 3-3)
PHY API MessageLAST
Vendor-specific message
Table 3-1 General PHY API message format
Type Description
uint8_t Number of messages included in PHY API message
uint8_t An opaque handle (purpose not defined, however, usages

may include a PHY ID or Carrier ID)
Table 3-2 PHY API message header
Each PHY API message consists of a generic header followed by a message body, as
shown in Table 3-3 and consists of a message type ID, a length field and a message
body.
Type Description
uint16_t Message type ID
uint32_t Length of message body (bytes)
Message body
Table 3-3 General PHY API message structure
The current list of message types is given in Table 3-4. The PHY API messages follow a
standard naming convention where:
• All .request messages are sent from the L2/L3 software to the PHY.
• All .response messages are sent from the PHY to the L2/L3 software. These
are sent in response to a .request.
• All .indication messages are sent from the PHY to the L2/L3 software.
These are sent asynchronously.
The message body is different for each message type; however, each message body
obeys the following rules:
• The first field in each response message is an error code. For each message it
is indicated which error codes can be returned. A full list of error codes is
given in Section 3.3.6.1.

Version: 1.0.5 43
A full description of each message body is given in the remainder of Section 3.
The API mechanism can use either little-endian byte order, or big-endian byte order.
The selection of byte ordering is implementation specific. However, the LSB of the bit
stream shall be the LSB of the field defined in the API. For example, the location of a
12-bit bitstream within a 16-bit value would be:
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
msb bitstream lsb
This document assumes that the API messages are transferred using a reliable in-
order delivery mechanism.
3.2 Message Types
The messages in the 5G PHY API are given in Table 3-4.
Message Value Message Body Definition

PARAM.request 0x00 See Section 3.3.1.1
PARAM.response 0x01 See Section 3.3.1.2
CONFIG.request 0x02 See Section 3.3.2.1
CONFIG.response 0x03 See Section 3.3.2.2
START.request 0x04 See Section 3.3.4.1
STOP.request 0x05 See Section 3.3.5.1
STOP.indication 0x06 See Section 3.3.5.2
ERROR.indication 0x07 See Section 3.3.6.1
RESERVED 0x08-0x7f
DL_TTI.request 0x80 See Section 3.4.2
UL_TTI.request 0x81 See Section 3.4.3
SLOT.indication 0x82 See Section 3.4.1
UL_DCI.request 0x83 See Section 3.4.4
TX_Data.request 0x84 See Section 3.4.6
Rx_Data.indication 0x85 See Section 3.4.7
CRC.indication 0x86 See Section 3.4.8
UCI.indication 0x87 See Section 3.4.9
SRS.indication 0x88 See Section 3.4.10
RACH.indication 0x89 See Section 3.4.11
RESERVED 0x8a-0xff
Table 3-4 PHY API message types

Version: 1.0.5 44
3.3 Configuration Messages
The configuration messages are used by the L2/L3 software to control and configure
the PHY.
3.3.1 PARAM
The PARAM message exchange was described in Figure 2-3.
3.3.1.1 PARAM.request
This message can be sent by the L2/L3 when the PHY is in the IDLE state and,
optionally, the CONFIGURED state. If it is sent when the PHY is in the RUNNING state,
a MSG_INVALID_STATE error is returned in PARAM.response. No message body is
defined for PARAM.request. The message length in the generic header = 0.
3.3.1.2 PARAM.response
The PARAM.response message is given in Table 3-5. From this table it can be seen
that PARAM.response contains a list of TLVs providing information about the PHY.
When the PHY is in the IDLE state this information relates to the PHY’s overall
capability. When the PHY is in the CONFIGURED state this information relates to the
current configuration.
The full list of PARAM TLVs is given in Section 3.3.1.4, with the following requirements
on the PHY in terms of reporting:
• There is no requirement for every TLV to be reported

• There is no requirement for L1 to provide the TLVs in the order specified in
the Tables
Field Type Description
Error Code uint8_t See Table 3-6
Number of TLVs uint8_t Number of TLVs contained in the message

body.
TLVs Variable See Table 3-8.
Table 3-5 PARAM.response message body
3.3.1.3 PARAM errors
The error codes that can be returned in PARAM.response are given in Table 3-6.
Error code Description
MSG_OK Message is OK.
MSG_INVALID_STATE The PARAM.request was received when the

PHY was in the RUNNING state.
Table 3-6 Error codes for PARAM.response

Version: 1.0.5 45
3.3.1.4 PARAM TLVs
PARAM and CONFIG TLVs are used in the PARAM and CONFIG message exchanges,
respectively. For both the PARAM and CONFIG TLVs the TLV format is given in Table
3-7. Each TLV consists of;
• Tag parameter of 2 bytes

• Length parameter of 2 bytes
• Value parameter
The length of the Value parameter ensures the complete TLV is a multiple of 4-bytes
(32-bits).
The TLVs for the PARAM message exchange are given in this Section 3.3.1.4 and for
the CONFIG message exchange in Section 3.3.2.4.
Type Description
uint16_t Tag.
uint16_t Length (in bytes)
variable Value
Table 3-7 TLV format
PARAM TLVs used in the PARAM message exchange are given in Table 3-8.

Cell Param struct See Table 3-9
Carrier Param struct See Table 3-10
PDCCH Param struct See Table 3-11
PUCCH Param struct See Table 3-12
PDSCH Param struct See Table 3-13
PUSCH Param struct See Table 3-14
PRACH Param struct See Table 3-15
Measurement Param struct See Table 3-16
Table 3-8 PARAM TLVs
To aid additions of future TLVs in later versions of this API the highest value tag in the
Tables below is 0x0036.
Tag Field Type Description

This table contains the top-level configuration parameters relating to the cell.
0x0001 Release capability uint16_t Bitmap indicating which release the PHY
supports
For each bit:

0= not supported
1 = supported
Bits:
0 = Release15

Version: 1.0.5 46
0x0002 PHY state uint16_t Indicates the current operational state of the
PHY.
Value:
0 = IDLE
1 = CONFIGURED
2 = RUNNING
0x0003 Skip_blank_DL_CONFIG uint8_t Indicates if the PHY requires a
DL_TTI.request message every DL slot or if
the message can be skipped if there is
nothing to schedule
Value:
0 = not supported
1 = supported
0x0004 Skip_blank_UL_CONFIG uint8_t Indicates if the PHY requires a
UL_TTI.request message every UL slot or if
the message can be skipped if there is
nothing to schedule
Value:
0 = not supported
1 = supported
0x0005 NumConfigTLVsToReport uint16_t Indicates the number of CONFIG TLVs which
will be reported. For each CONFIG TLV it is
indicated if they are optional or mandatory in
each PHY state
For NumConfigTLVsToReport {
Tag uint16_t Tag value of CONFIG TLV, see Table 3-20 for
possible values
Length uint8_t Length of value field
Value: 1
Value uint8_t Provides information of optional and
mandatory status for each TLV
Value:
0 = Idle state only, optional
1 = Idle state only, mandatory
2 = Idle and Configured states, optional
3 = Idle state mandatory, Configured state
optional
4 = Idle, Configured and Running states
optional
5 = Idle state mandatory, Configured and
Running states optional
}
Table 3-9 Cell parameters
This table contains the parameters relating to carrier configuration.

0x0006 cyclicPrefix uint8_t Bitmap indicating support.
For each bit:
0= not supported

Version: 1.0.5 47
1 = supported
Bits:
0 = Normal
1 = Extended
0x0007 supportedSubcarrierSpacingsDl uint8_t Bitmap indicating support.
For each bit:
0= not supported
1 = supported
Bits:
0 = 15KHz
1 = 30KHz
2 = 60KHz
3 = 120KHz
0x0008 supportedBandwidthDl uint16_t Bitmap indicating support format.

For each bit:
0= not supported
1 = supported
Bits:
0 = 5MHz
1 = 10MHz
2 = 15MHz
3 = 20MHz
4 = 25MHz
5 = 40MHz
6 = 50MHz
7 = 60MHz
8 = 70MHz
9 = 80MHz
10 = 90MHz
11 = 100MHz
12 = 200MHz
13 = 400MHz
0x0009 supportedSubcarrierSpacingsUl uint8_t Bitmap indicating support format.
For each bit:
0= not supported
1 = supported
Bits:
0 = 15KHz
1 = 30KHz
2 = 60KHz
3 = 120KHz
0x000A supportedBandwidthUl uint16_t Bitmap indicating support format.
For each bit:
0= not supported
1 = supported
Bits:
0 = 5MHz
1 = 10MHz

Version: 1.0.5 48
2 = 15MHz
3 = 20MHz
4 = 25MHz
5 = 40MHz
6 = 50MHz
7 = 60MHz
8 = 70MHz
9 = 80MHz
10 = 90MHz
11 = 100MHz
12 = 200MHz
13 = 400MHz
Table 3-10 Carrier parameters
This table contains the configuration parameters relating PDCCH configuration.

0x000B cceMappingType uint8_t Bitmap indicating support format.
For each bit:
0= not supported
1 = supported
Bits:
0 = Interleaved
1 = Non-interleaved
0x000C coresetOutsideFirst3OfdmSymsOfSlot uint8_t 0 = not supported
1 = supported
0x000D precoderGranularityCoreset uint8_t 0 = not supported
1 = supported
0x000E pdcchMuMimo uint8_t 0 = not supported
1 = supported
0x000F pdcchPrecoderCycling uint8_t 0 = not supported
1 = supported
0x0010 maxPdcchsPerSlot uint8_t Value 1->255
Table 3-11 PDCCH parameters
This table contains the configuration parameters relating PUCCH configuration.
0x0011 pucchFormats uint8_t Bitmap indicating support format.

For each bit:
0= not supported
1 = supported
Bits:
0 = Format 0
1 = Format 1
2 = Format 2
3 = Format 3
4 = Format 4

Version: 1.0.5 49
0x0012 maxPucchsPerSlot uint8_t Value 1->255
Table 3-12 PUCCH parameters
This table contains the configuration parameters relating PDSCH configuration.

0x0013 pdschMappingType uint8_t Bitmap indicating support format.
For each bit:
0= not supported
1 = supported
Bits:
0 = Type A
1 = Type B
0x0014 pdschAllocationTypes uint8_t Bitmap indicating support format.
For each bit:
0= not supported
1 = supported
Bits:
0 = Type 0
1 = Type 1
0x0015 pdschVrbToPrbMapping uint8_t Bitmap indicating support format.
For each bit:
0= not supported
1 = supported
Bits:
0 = Non-interleaved
1 = Interleaved
0x0016 pdschCbg uint8_t 0 = not supported
1 = supported
0x0017 pdschDmrsConfigTypes uint8_t Bitmap indicating support format.
For each bit:
0= not supported
1 = supported
Bits:
0 = Type 1
1 = Type 2
0x0018 pdschDmrsMaxLength uint8_t 0 = Length 1
1 = Length 2
0x0019 pdschDmrsAdditionalPos uint8_t Bitmap indicating support format.
For each bit:
0= not supported
1 = supported
Bits:
0 = pos0 (1+0)
1 = pos1 (1+1)
2 = pos2 (1+1+1)
3 = pos3 (1+1+1+1)

Version: 1.0.5 50
0x001A maxPdschsTBsPerSlot uint8_t Value: 1->255
0x001B maxNumberMimoLayersPdsch uint8_t Value: 1->2

0x001C supportedMaxModulationOrderDl uint8_t Value:
0 = QPSK
1 = 16 QAM
2 = 64 QAM
3 = 256 QAM
0x001D maxMuMimoUsersDl uint8_t Value: 1 ->255
0x001E pdschDataInDmrsSymbols uint8_t 0 = not supported
1 = supported
0x001F premptionSupport uint8_t 0 = not supported
1 = supported
0x0020 pdschNonSlotSupport uint8_t 0 = not supported
1 = supported
Table 3-13 PDSCH parameters
This table contains the configuration parameters relating PUSCH configuration.

0x0021 uciMuxUlschInPusch uint8_t 0 = not supported
1 = supported
0x0022 uciOnlyPusch uint8_t 0 = not supported
1 = supported
0x0023 puschFrequencyHopping uint8_t 0 = not supported
1 = supported
0x0024 puschDmrsConfigTypes uint8_t Bitmap indicating support format.
For each bit:
0= not supported
1 = supported
Bits:
0 = Type 1
1 = Type 2
0x0025 puschDmrsMaxLen uint8_t 0 = Length 1
1 = Length 2
0x0026 puschDmrsAdditionalPos uint8_t Bitmap indicating support format.
For each bit:
0= not supported
1 = supported
Bits:
0 = pos0 (1+0)
1 = pos1 (1+1)
2 = pos2 (1+1+1)
3 = pos3 (1+1+1+1)
0x0027 puschCbg uint8_t 0 = not supported
1 = supported

Version: 1.0.5 51
0x0028 puschMappingType uint8_t Bitmap indicating support format.

For each bit:
0= not supported
1 = supported
Bits:
0 = Type A
1 = Type B
0x0029 puschAllocationTypes uint8_t Bitmap indicating support format.
For each bit:
0= not supported
1 = supported
Bits:
0 = Type 0
1 = Type 1
0x002A puschVrbToPrbMapping uint8_t Bitmap indicating support format.
For each bit:
0= not supported
1 = supported
Bits:
0 = Non-interleaved
1 = Interleaved
0x002B puschMaxPtrsPorts uint8_t Value = 0,1,2
0x002C maxPduschsTBsPerSlot uint8_t Value 1->255
0x002D maxNumberMimoLayersNonCbPusch uint8_t Value: 1
0x002E supportedModulationOrderUl uint8_t Value:
0 = QPSK
1 = 16 QAM
2 = 64 QAM
3 = 256 QAM
0x002F maxMuMimoUsersUl uint8_t Value: 1 ->255
0x0030 dftsOfdmSupport uint8_t 0 = not supported
1 = supported
0x0031 puschAggregationFactor uint8_t Bitmap indicating support for
different aggregation factors.
For each bit:
0= not supported
1 = supported
Bits:
0 = aggregation factor 1
Table 3-14 PUSCH parameters

Version: 1.0.5 52
This table contains the parameters relating PRACH configuration
0x0032 prachLongFormats uint8_t Bitmap indicating support format.
For each bit:
0= not supported
1 = supported
Bits:
0 = Format 0
1 = Format 1
2 = Format 2
3 = Format 3
0x0033 prachShortFormats uint16_t Bitmap indicating support format.
For each bit:
0= not supported
1 = supported
Bits:
0 = Format A1
1 = Format A2
2 = Format A3
3 = Format B1
4 = Format B2
5 = Format B3
6 = Format B4
7 = Format C0
8 = Format C2
0x0034 prachRestrictedSets uint8_t Value:
0 = not supported
1 = supported
0x0035 maxPrachFdOccasionsInASlot uint8_t Value:
0=1
1=2
2=4
3=8
Table 3-15 PRACH parameters

Version: 1.0.5 53
This table contains the parameters relating Measurement reporting
0x0036 RssiMeasurementSupport uint8_t Indicates if RSSI measurement is supported
and what units can be used for reporting.
The RSSI reported will be total received power
summed across all antennas. RSSI includes all
noise and interference contributions.
Bitmap indicating support.

For each bit:
0= not supported
1 = supported
Bits:
0 = RSSI reporting in dBm
1 = RSSI reporting in dBFS
Table 3-16 Measurement parameters
3.3.2 CONFIG
The CONFIG message exchange was described in Figure 2-4.
3.3.2.1 CONFIG.request
The CONFIG.request message is given in Table 3-17. From this table it can be seen
that CONFIG.request contains a list of TLVs describing how the PHY should be
configured. This message may be sent by the L2/L3 software when the PHY is in any
state.
The full list of CONFIG TLVs is given in Section 3.3.2.4 and the PARAM message
provided L2/L3 a list of supported CONFIG TLVs and states where these TLVs are
valid.
There is no requirement for the L2/L3 software to provide the TLVs in the order
specified in the Tables.
Number of TLVs uint8_t Number of TLVs contained in the message

body.
TLVs Variable See Table 3-20
Table 3-17 CONFIG.request message body
3.3.2.2 CONFIG.response
The CONFIG.response message is given in Table 3-18. If the configuration procedure

was successful then the error code returned will be MSG_OK and no TLV tags will be
included. If the configuration procedure was unsuccessful then MSG_INVALID_CONFIG
will be returned, together with a list of TLVs identifying the problem.

Version: 1.0.5 54
Error Code uint8_t See Table 3-19.
Number of Invalid uint8_t Number of invalid or unsupported TLVs

or Unsupported contained in the message body.
TLVs
Value: 0->255
Number of invalid uint8_t Number of TLVs contained in the message

TLVs that can only body, which are valid in IDLE state but not in
be configured in this PHY state. If PHY is in IDLE state this will
IDLE always be 0.
Value: 0->255
Number of invalid uint8_t Number of TLVs contained in the message

TLVs that can only body, which are valid in RUNNING state but
be configured in not in this PHY state. If PHY is in RUNNING
RUNNING state this will always be 0.
Value: 0->255
Number of Missing uint8_t Number of missing TLVs contained in the

TLVs message body. If the PHY is in the
CONFIGURED state this will always be 0.
Value: 0->255
A list of invalid or unsupported TLVs – each TLV is presented in its entirety.
TLV Variable Complete TLVs
A list of invalid TLVs that can only be configured in IDLE – each TLV is presented in its entirety
A list of invalid TLVs that can only be configured in RUNNING – each TLV is presented in its
entirety
A list of missing TLVs – each TLV is presented in its entirety
Table 3-18 CONFIG.response message body

Version: 1.0.5 55
3.3.2.3 CONFIG errors
The error codes that can be returned in CONFIG.response are given in Table 3-19.
MSG_OK Message is OK.
MSG_INVALID_CONFIG The configuration provided has missing

mandatory TLVs, or TLVs that are invalid or
unsupported in this state.
Table 3-19 Error codes for CONFIG.response
3.3.2.4 CONFIG TLVs
PARAM and CONFIG TLVs are used in the PARAM and CONFIG message exchanges,
respectively. For both the PARAM and CONFIG TLVs the TLV format is given in Table
3-7.
The TLVs for the CONFIG message exchange are given in this Section 3.3.2.4 and for
the PARAM message exchange in Section 3.3.1.4.
CONFIG TLVs used in the CONFIG message exchange are given in Table 3-20.

Carrier Config struct See Table 3-21
Cell Config struct See Table 3-22
SSB Config struct See Table 3-23
PRACH Config struct See Table 3-24
SSB Table struct See Table 3-25
TDD Table struct See Table 3-26
Measurement Config struct See Table 3-27
Beamforming Table struct See Table 3-32
Precoding Table struct See Table 3-33
Table 3-20 CONFIG TLVs
To aid additions of future TLVs in later versions of this API the highest value tag in the
Tables below is 0x1029.
This table contains the configuration parameters relating carrier configuration. The
PARAM.response message will have indicated which of these parameters is supported by the
PHY and in which PHY states these parameters are mandatory or optional.
0x1001 dlBandwidth uint16_t Carrier bandwidth for DL in MHz [38.104, sec
5.3.2]
Values: 5, 10, 15, 20, 25, 30, 40,50, 60, 70,
80,90,100,200,400
0x1002 dlFrequency uint32_t Absolute frequency of DL point A in KHz
[38.104, sec5.2 and 38.211 sec 4.4.4.2]
Value: 450000 -> 52600000

Version: 1.0.5 56
𝜇𝜇
0x1003 dlk0 uint16_t 𝑘𝑘0 for each of the numerologies [38.211, sec
[5] 5.3.1]
Value: 0 ->23699
0x1004 dlGridSize uint16_t 𝑠𝑠𝑖𝑖𝑧𝑧𝑧𝑧,𝜇𝜇
Grid size 𝑁𝑁𝑔𝑔𝑔𝑔𝑔𝑔𝑔𝑔 for each of the numerologies
[5] [38.211, sec 4.4.2]
Value: 0->275
0 = this numerology not used
0x1005 numTxAnt uint16_t Number of Tx antennas
Value: 0 ->65355
0x1006 uplinkBandwidth uint16_t Carrier bandwidth for UL in MHz. [38.104, sec
5.3.2]
Values: 5, 10, 15, 20, 25, 30, 40,50, 60, 70,
80,90,100,200,400
0x1007 uplinkFrequency uint32_t Absolute frequency of UL point A in KHz
[38.104, sec5.2 and 38.211 sec 4.4.4.2]
Value: 450000 -> 52600000
𝜇𝜇
0x1008 ulk0 uint16_t 𝑘𝑘0 for each of the numerologies [38.211, sec
[5] 5.3.1]
Value: : 0 ->23699
0x1009 ulGridSize uint16_t 𝑠𝑠𝑠𝑠𝑠𝑠𝑠𝑠,𝜇𝜇
Grid size 𝑁𝑁𝑔𝑔𝑔𝑔𝑔𝑔𝑔𝑔 for each of the numerologies
[5] [38.211, sec 4.4.2].
Value: 0->275
0 = this numerology not used
0x100A numRxAnt uint16_t Number of Rx antennas
Value: 0 ->65355
0x100B FrequencyShift7p5KHz uint8_t Indicates presence of 7.5KHz frequency shift.
Value:
0 = false
1 = true
Table 3-21 Carrier configuration
This table contains the configuration parameters relating cell configuration. The
PHY and in which PHY states these parameters are mandatory or optional.
0x100C phyCellId uint16_t 𝑐𝑐𝑐𝑐𝑐𝑐𝑐𝑐

Physical Cell ID, 𝑁𝑁𝐼𝐼𝐼𝐼 [38.211, sec 7.4.2.1]
Value: 0 ->1007
0x100D FrameDuplexType uint8_t Frame duplex type

Value:
0 = FDD
1 = TDD
Table 3-22 Cell configuration

Version: 1.0.5 57
This table contains the configuration parameters relating SSB/PBCH configuration. The
PHY and in which PHY states these parameters are mandatory or optional
0x100E ssPbchPower uint32_t SSB Block Power

Value: TBD (-60..50 dBm)
0x100F BchPayload uint8_t Defines option selected for generation of BCH

payload, see Table 3-13 (v0.0.011
Value:
0: MAC generates the full PBCH payload
1: PHY generates the timing PBCH bits
2: PHY generates the full PBCH payload
0x1010 ScsCommon uint8_t subcarrierSpacing for common, used for initial access
and broadcast message. [38.211 sec 4.2]
Value:0->3
Table 3-23 SSB configuration

0x1011 prachSequenceLength uint8_t RACH sequence length. Long or Short
sequence length. Only short sequence
length is supported for FR2. [38.211,
sec 6.3.3.1]
Value:
0 = Long sequence
1 = Short sequence
0x1012 prachSubCSpacing uint8_t Subcarrier spacing of PRACH. [38.211
Tables 6.3.3.1-2 and 6.3.3.1-7]
Value:0->3
0x1013 restrictedSetConfig uint8_t PRACH restricted set config
Value:
0: unrestricted
1: restricted set type A
2: restricted set type B
0x1014 numPrachFdOccasions uint8_t Number of RACH frequency domain
occasions. Corresponds to the
parameter 𝑀𝑀 in [38.211, sec 6.3.3.2]
which equals the higher layer
parameter msg1FDM
Value: 1,2,4,8
0x1029 prachConfigIndex uint8_t PRACH configuration index.
Value: from 0 to 255
For numPRACHFdOccasions {
0x1015 prachRootSequenceIndex uint16_t Starting logical root sequence index, 𝑖𝑖,
equivalent to higher layer parameter
prach-RootSequenceIndex [38.211, sec
6.3.3.1]
Value: 0 -> 837
0x1016 numRootSequences uint8_t Number of root sequences for a
particular FD occasion that are required

Version: 1.0.5 58
to generate the necessary number of
preambles
0x1017 k1 uint16_t Frequency offset (from UL bandwidth
part) for each FD. [38.211, sec 6.3.3.2]
Value: from 0 to 272
0x1018 prachZeroCorrConf uint8_t PRACH Zero CorrelationZone Config
which is used to dervive 𝑁𝑁𝑐𝑐𝑐𝑐 [38.211,
sec 6.3.3.1]
Value: from 0 to 15
0x1019 numUnusedRootSequences uint16_t Number of unused sequences available

for noise estimation per FD occasion. At
least one unused root sequence is
required per FD occasion.
For numUnusedRootSequences {
0x101A unusedRootSequences uint16_t Unused root sequence or
sequences per FD occasion.
Required for noise estimation.
0x101B SsbPerRach uint8_t SSB-per-RACH-occasion

Value:
0: 1/8
1:1/4,
2:1/2
3:1
4:2
5:4,
6:8
7:16
0x101C prachMultipleCarriersInABand uint8_t 0 = disabled
1 = enabled
Table 3-24 PRACH configuration
This table contains the configuration parameters used for storing an SSB transmission pattern
(up to 63 SSB) in the PHY, which the PHY can then auto-generate. The PARAM.response
message will have indicated which of these parameters is supported by the PHY and in which
PHY states these parameters are mandatory or optional
0x101D SsbOffsetPointA uint16_t Offset of lowest subcarrier of lowest
resource block used for SS/PBCH block.
Given in PRB [38.211, section 4.4.4.2]
Value: 0->2199
0x101E betaPss uint8_t PSS EPRE to SSS EPRE in a SS/PBCH
block [38.213, sec 4.1]
Values:
0 = 0dB

Version: 1.0.5 59
1 = 3dB
0x101F SsbPeriod uint8_t SSB periodicity in msec
Value:
0: ms5
1: ms10
2: ms20
3: ms40
4: ms80
5: ms160
0x1020 SsbSubcarrierOffset uint8_t ssbSubcarrierOffset or 𝑘𝑘𝑆𝑆𝑆𝑆𝑆𝑆 (38.211,
section 7.4.3.1)
Value: 0->31
0x1021 MIB uint32_t MIB payload, where the 24 MSB are
used and represent the MIB in [38.331
MIB IE] and represent
a0 , a1 , a2 , a3 ,..., a A −1 [38.212, sec
7.1.1]
For ssbMaskSize = 2 { (If included there must be two instances of this TLV
0x1022 SsbMask uint32_t Bitmap for actually transmitted SSB.
MSB->LSB of first 32 bit number
corresponds to SSB 0 to SSB 31
MSB->LSB of second 32 bit number
corresponds to SSB 32 to SSB 63
Value for each bit:
0: not transmitted
1: transmitted
}
For ssbMaskSize = 64 { (If included there must be 64 instances of this TLV)
0x1023 BeamId[64] uint8_t BeamID for each SSB in SsbMask. For
example, if SSB mask bit 26 is set to 1,
then BeamId[26] will be used to
indicate beam ID of SSB 26.
Value: from 0 to 63
}
0x1024 ssPbchMultipleCarriersInABand uint8_t 0 = disabled
1 = enabled
0x1025 multipleCellsSsPbchInACarrier uint8_t Indicates that multiple cells will be
supported in a single carrier
0 = disabled
1 = enabled
Table 3-25 SSB Table
This table contains the configuration parameters used for storing a TDD pattern (up to 63
SSB) in the PHY. The PARAM.response message will have indicated which of these parameters
is supported by the PHY and in which PHY states these parameters are mandatory or optional
0x1026 TddPeriod uint8_t DL UL Transmission Periodicity
Value:

Version: 1.0.5 60
0: ms0p5
1: ms0p625
2: ms1
3: ms1p25
4: ms2
5: ms2p5
6: ms5
7: ms10
For MAX_TDD_PERIODICITY {
For MAX_NUM_OF_SYMBOL_PER_SLOT {
0x1027 SlotConfig uint8_t For each symbol in each slot a uint8_t value is
provided indicating:
0: DL slot
1: UL slot
2: Guard slot
}
}
Table 3-26 TDD table
This table contains the configuration parameters relating Measuerment configuration. The
PHY and in which PHY states these parameters are mandatory or optional
0x1028 RssiMeasurement uint8_t RSSI measurement unit. See Table 3-16 for RSSI
definition.
Value:
0: Do not report RSSI
1: dBm
2: dBFS
Table 3-27 Measurement Config
3.3.3 Vendor TLVs
The range 0xA000 – 0xAFFF are reserved for vendor-specific TLVs. These TLVs can be
either CONFIG or PARAM TLVs.
3.3.4 START
The START message exchange was described in Figure 2-5.
3.3.4.1 START.request
This message can be sent by the L2/L3 when the PHY is in the CONFIGURED state. If
it is sent when the PHY is in the IDLE, or RUNNING state an ERROR.indication
message will be sent by the PHY. No message body is defined for START.request. The
message length in the generic header = 0.

Version: 1.0.5 61
3.3.4.2 START errors
The error codes returned in an ERROR.indication generated by the START.request

message are given in Table 3-28.
MSG_INVALID_STATE The START.request was received when the

PHY was in the IDLE or RUNNING state.
Table 3-28 Error codes for START.request
3.3.5 STOP
The STOP message exchange was described in Figure 2-6.
3.3.5.1 STOP.request
This message can be sent by the L2/L3 when the PHY is in the RUNNING state. If it is
sent when the PHY is in the IDLE, or CONFIGURED, state an ERROR.indication
message will be sent by the PHY. No message body is defined for STOP.request. The
message length in the generic header = 0.
3.3.5.2 STOP. Indication
This message is sent by the PHY to indicate that it has successfully stopped and
returned to the CONFIGURED state. No message body is defined for
STOP.indication. The message length in the generic header = 0.
3.3.5.3 STOP errors
The error codes returned in an ERROR.indication generated by the STOP.request

MSG_INVALID_STATE The STOP.request was received when the

PHY was in the IDLE or CONFIGURED state.
Table 3-29 Error codes for STOP.request
3.3.6 PHY Notifications
The PHY notification messages are used by the PHY to inform the L2/L3 software of an
event which occurred.
3.3.6.1 ERROR.indication
This message is used to report an error to the L2/L3 software. These errors all relate
to API message exchanges. The format of ERROR.indication is given in Table 3-30

SFN
SFN uint16_t
Value: 0 -> 1023

Version: 1.0.5 62
Slot
Slot uint16_t
Value: 0 ->159
Message ID uint8_t Indicate which message received by the PHY has an
error. Values taken from Table 3-4.
Error code uint8_t The error code, see Section 3.3.6.2 for values
Table 3-30 ERROR.indication message body
3.3.6.2 Error Codes
The list of possible error codes returned in either .response messages or the
ERROR.indication message is given in Table 3-31.
Value Error code Description
0x0 MSG_OK Message is OK.
0x1 MSG_INVALID_STATE The received message is not valid in the

PHY's current state.
0x2 MSG_INVALID_CONFIG The configuration provided in the request

message was invalid
0x3 SFN_OUT_OF_SYNC The DL_TTI.request was received with a

different SFN than the PHY expected.
0x4 MSG_SLOT_ERR The DL_TTI.request or UL_TTI.request had

an invalid format.
0x5 MSG_BCH_MISSING A SSB PDU was expected in the

DL_TTI.request message for this subframe.
However, it was not present.
0x6 MSG_INVALID_SFN The received UL_DCI.request or

TX_Data.request message included a
SFN/SL value which was not expected. The
message has been ignored.
0x7 MSG_UL_DCI_ERR The UL_DCI_DCI.request. had an invalid

format
0x8 MSG_TX_ERR The TX_Data.request had an invalid format.
Table 3-31 PHY API error codes
3.3.7 Storing Precoding and Beamforming Tables
The format of the beamforming table is given in Table 3-32 and the format of the
precoding table is given in Table 3-33.

Number of digital beams
numDigBeams uint16_t
Value: 0->65535
Number of ports at the digital beamformer output.
numTXRUs uint16_t

Version: 1.0.5 63
Value: 0->65535
for each digBeam {
beamIdx uint16_t Identifying number for the beam index
Value: 0->65535
for each TXRU {
digBeamWeightRe int16_t Real part of the digital beam weight
digBeamWeightIm int16_t Imag part of the digital beam weight
}
}
Table 3-32 Digital Beam Table (DBT) PDU

PMidx uint16_t Index which uniquely identifies the precoding matrix
(PM). PMidx = 0 is reserved for identity matrix.
Value: 0->65535
numLayers uint16_t Number of ports at the precoder input
Value: 0->65535
numAntPorts uint16_t Number of ports at the precoder output
Value: 0->65535
For numLayers {
For numAntPorts {
precoderWeightRe int16_t Real part of the precoder weight
precoderWeightIm int16_t Imag part of the precoder weight
}
}
Table 3-33 Precoding Matrix (PM) PDU
3.4 Slot Messages
The slot messages are used by the L2/L3 software to control the data transmitted, or
received, every slot.
3.4.1 Slot.indication
The SLOT.indication message is given in Table 3-34, and is sent from the PHY with a
periodicity based on the CONFIG.request message sent to the PHY. Specifically, the
CONFIG.request message includes carrier configuration TLVs which provide values for
different numerologies, including options to indicate a numerology is not used. The
SLOT.indication message is sent from the PHY based on the highest-value
numerology configured in CONFIG.request. If the highest numerology configured is:
• 0 – then SLOT.indication is provided every 1ms

• 1 – then SLOT.indication is provided every 500us

Version: 1.0.5 64

SFN uint16_t SFN
Value: 0 -> 1023

Slot uint16_t Slot
Value: 0 ->159
Table 3-34 Slot indication message body
3.4.2 DL_TTI.request
The format of the DL_TTI.request message is shown in Table 3-35. A

DL_TTI.request message indicates the SFN/Slot it contains information for and this
control information is for a downlink slot.
sent when the PHY is in the IDLE or CONFIGURED state an ERROR.indication
message will be sent by the PHY.
The following combinations of PDUs are required:
• A SSB PDU does not have an associated DCI PDU

• A PDSCH PDU allocated with Configured Grant Scheduling may not have an
associated DCI (PDCCH) PDU
• A PDSCH for a unique RNTI requires an associated DCI (PDCCH) PDU.
• A CSI-RS PDU does not have an associated DCI PDU
• A PDCCH PDU includes 1 or more DCI PDUs
The PDUs included in this structure have no ordering requirements.

SFN uint16_t SFN
Value: 0 -> 1023

Slot uint16_t Slot
Value: 0 ->159
nPDUs uint8_t Number of PDUs that are included in this message. All
PDUs in the message are numbered in order.
Value 0 -> 255

nGroup uint8_t Number of UE Groups included in this message.
Value 0 -> 255

For Number of PDUs {
PDUType uint16_t 0: PDCCH PDU, see Section 3.4.2.1
1: PDSCH PDU, see Section 3.4.2.2
2: CSI-RS PDU, see Section 3.4.2.3
3: SSB PDU, see Section 3.4.2.4

Version: 1.0.5 65
PDUSize uint16_t Size of the PDU control information (in bytes). This
length value includes the 4 bytes required for the PDU
type and PDU size parameters.
Value 0 -> 65535

DL PDU structure See Sections 3.4.2.1 to 3.4.2.4
Configuration
}
In this message, if nGroup > 0 then for each group {
nUe uint8_t Number of UE in this group
For SU-MIMO, one group includes one UE only. For
MU-MIMO, one group includes up to 12 UEs.
Value 1 -> 12
In the group, for each UE {
PduIdx uint8_t This value is an index for number of PDU identified by
nPDU in this message
Value: 0 -> 255

}
}
Table 3-35 DL_TTI.request message body
3.4.2.1 PDCCH PDU
The format of a PDCCH PDU is shown in Table 3-36. Each PDCCH PDU contains 1
CORESET and 1 or more DL DCI PDUs.
Each DL DCI PDU includes the information that the L2/L3 software must provide the
PHY so it can transmit the DCI described in [TS38.212, section 7.3.1], however, the
L2/L3 constructs the DCI message.
Each CORESET is related to a specific BWP and there can be more than 1 CORESET
per BWP. If there is more than 1 CORESET per BWP then multiple PDCCH PDUs should
be included in the DL_TTI.request.

BWP [TS38.213 sec 12]
BWPSize uint16_t Bandwidth part size [TS38.213 sec12]. Number of
contiguous PRBs allocated to the BWP
Value: 1->275
BWPStart uint16_t bandwidth part start RB index from reference CRB
[TS38.213 sec 12]
Value: 0->274
SubcarrierSpacing uint8_t subcarrierSpacing [TS38.211 sec 4.2]
Value:0->4
CyclicPrefix uint8_t Cyclic prefix type [TS38.211 sec 4.2]
0: Normal; 1: Extended

Version: 1.0.5 66
Coreset [TS38.211 sec 7.3.2.2]

StartSymbolIndex uint8_t Starting OFDM symbol for the CORESET
Value: 0->13
DurationSymbols uint8_t Contiguous time duration of the CORESET in number of
𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶
symbols. Corresponds to L1 parameter 𝑁𝑁𝑠𝑠𝑠𝑠𝑠𝑠𝑠𝑠
[TS38.211 sec 7.3.2.2]
Value: 1,2,3
FreqDomainResource uint8_t[6] Frequency domain resources. This is a bitmap defining
non-overlapping groups of 6 PRBs in ascending order.
[TS38.213 10.1]. Also, corresponds to L1 parameter
CORESET
N RB [TS38.211 sec 7.3.2.2]
Bitmap of uint8 array. 46 bits.

CceRegMappingType uint8_t CORESET-CCE-to-REG-mapping-type [TS38.211 sec
7.3.2.2]
0: non-interleaved
1: interleaved
RegBundleSize uint8_t The number of REGs in a bundle. Must be 6 for
cceRegMappingType = nonInterleaved. For
cceRegMappingType = interleaved, must belong to
{2,6} if duration = 1,2 and must belong to {3,6} if
duration = 3. Corresponds to parameter L. [TS38.211
sec 7.3.2.2]
Value: 2,3,6
InterleaverSize uint8_t The interleaver size. For interleaved mapping belongs
to {2,3,6} and for non-interleaved mapping is NA.
Corresponds to parameter R. [TS38.211 sec 7.3.2.2]
Value: 2,3,6
CoreSetType uint8_t [TS38.211 sec 7.3.2.2 and sec 7.4.1.3.2]
0: CORESET is configured by the PBCH or SIB1

(subcarrier 0 of CRB0 for DMRS mapping)
1: otherwise (subcarrier 0 of CORESET)
ShiftIndex uint16_t [TS38.211 sec 7.3.2.2]
Not applicable for non-interleaved mapping.
For interleaved mapping and a PDCCH transmitted in a
CORESET configured by the PBCH or SIB1 this should
be set to phy cell ID.
Value: 10 bits
Otherwise, for interleaved mapping this is set to 0->
max num of PRBs.
Value 0-> 275
precoderGranularity uint8_t Granularity of precoding [TS38.211 sec 7.3.2.2]
0: sameAsRegBundle

Version: 1.0.5 67
1: allContiguousRBs
numDlDci uint16_t Number of DCIs in this CORESET.
Value: 0->MaxDciPerSlot
For number of DL DCIs {
DlDci structure See Table 3-37
}
Table 3-36 PDCCH PDU

RNTI uint16_t The RNTI used for identifying the UE when receiving
the PDU
Value: 1 -> 65535.

ScramblingId uint16_t For a UE-specific search space it equals the higher-
layer parameter PDCCH-DMRS-Scrambling-ID if
configured, otherwise it should be set to the phy cell
ID. [TS38.211, sec 7.3.2.3]
Value: 0->65535
ScramblingRNTI uint16_t For a UE-specific search space where PDCCH-DMRS-
Scrambling-ID is configured
This param equals the CRNTI. Otherwise, it should
be set to 0. [TS38.211, sec 7.3.2.3]
Value: 0 -> 65535

CceIndex uint8_t CCE start Index used to send the DCI
Value: 0->135
AggregationLevel uint8_t Aggregation level used [TS38.211, sec 7.3.2.1]
Value: 1,2,4,8,16
Beamforming info
Precoding and structure See Table 3-43
Beamforming
Tx Power info
beta_PDCCH_1_0 uint8_t PDCCH power value used for PDCCH Format 1_0 with
CRC scrambled by SI-RNTI, PI-RNTI or RA-RNTI. This
is ratio of SSB/PBCH EPRE to PDCCH and PDCCH
DMRS EPRE [TS38.213, sec 4.1]
Value :0->17
representing -8 to 8 dB in 1dB steps
powerControlOffsetSS uint8_t PDCCH power value used for all other PDCCH
Formats. This is ratio of SSB/PBCH block EPRE to
PDCCH and PDCCH DMRS EPRE [TS38.214, sec 4.1]
Values:
0: -3dB,
1: 0dB,
2: 3dB,
3: 6dB

Version: 1.0.5 68
PayloadSizeBits uint16_t The total DCI length (in bits) including padding bits
[TS38.212 sec 7.3.1]
Range 0-> DCI_PAYLOAD_BTYE_LEN*8

Payload uint8_t[DCI_ DCI payload, where the actual size is defined by
PAYLOAD_BT PayloadSizeBits.
YE_LEN]
The bit order is as following
bit0-bit7 are mapped to first byte of MSB - LSB
Table 3-37 DL DCI PDU
3.4.2.2 PDSCH PDU
The format of the PDSCH PDU is shown in Table 3-38.
The PDSCH PDU includes both mandatory and optional parameters, where the
presence of the optional elements is defined in the parameter pduBitmap. The
presence of these optional elements is included based on the following:
• puschPtrs is included if PTRS are included in the uplink transmission
• cbgReTxCtrl is included if CBG is supported and retransmit is used.
(It should be noted that some parameters are only applicable for certain modes/types
etc. These are still included but their value is ignored by the PHY).
pduBitmap uint16_t Bitmap indicating presence of optional PDUs
Bit 0: pdschPtrs - Indicates PTRS included (FR2)
Bit 1:cbgRetxCtrl (Present when CBG based
retransmit is used)
All other bits reserved
the PDU
Value: 1 -> 65535
pduIndex uint16_t PDU index incremented for each PDSCH PDU sent in
TX control message. This is used to associate control
information to data and is reset every slot.
Value: 0 -> 65535

BWP [TS38.213 sec 12]
Value: 1->275
[TS38.213 sec 12]
Value: 0->274
Value:0->4

Version: 1.0.5 69
Codeword information
NrOfCodewords uint8_t Number of code words for this RNTI (UE)
Value: 1 -> 2
For each codeword {
targetCodeRate uint16_t Target coding rate [TS38.212 sec 5.4.2.1 and 38.214
sec 5.1.3.1]. This is the number of information bits
per 1024 coded bits expressed in 0.1 bit units
qamModOrder uint8_t QAM modulation [TS38.212 sec 5.4.2.1 and 38.214
sec 5.1.3.1]
Value: 2,4,6,8
mcsIndex uint8_t MCS index [TS38.214, sec 5.1.3.1], should match
value sent in DCI
Value : 0->31
mcsTable uint8_t MCS-Table-PDSCH [TS38.214, sec 5.1.3.1]
0: notqam256
1: qam256
2: qam64LowSE
rvIndex uint8_t Redundancy version index [TS38.212, Table 5.4.2.1-
2 and 38.214, Table 5.1.2.1-2], should match value
sent in DCI
Value : 0->3
TBSize uint32_t Transmit block size (in bytes) [TS38.214 sec 5.1.3.2]
Value: 0->65535
}
dataScramblingId uint16_t dataScramblingIdentityPdsch [TS38.211, sec

7.3.1.1]
It equals the higher-layer parameter Data-
scrambling-Identity if configured and the RNTI
equals the C-RNTI, otherwise L2 needs to set it to
physical cell id.
Value: 0->65535
nrOfLayers uint8_t Number of layers [TS38.211, sec 7.3.1.3]
Value : 1->8
transmissionScheme uint8_t PDSCH transmission schemes [TS38.214, sec 5.1.1]
0: Up to 8 transmission layers
refPoint uint8_t Reference point for

Version: 1.0.5 70
PDSCH DMRS "k" - used for tone mapping
[TS38.211, sec 7.4.1.1.2]
Resource block bundles [TS38.211, sec 7.3.1.6]
Value: 0 -> 1
If 0, the 0 reference point for PDSCH DMRS is at
Point A [TS38.211 sec 4.4.4.2].
Resource block bundles generated per sub-bullets 2
and 3 in [TS38.211, sec 7.3.1.6]. For sub-bullet 2,
the start of bandwidth part must be set to the start
of actual bandwidth part +NstartCORESET and the
bandwidth of the bandwidth part must be set to the
bandwidth of the initial bandwidth part.
If 1, the DMRS reference point is at the lowest
VRB/PRB of the allocation.
Resource block bundles generated per sub-bullets 1
[TS38.211, sec 7.3.1.6]
DMRS [TS38.211 sec 7.4.1.1]
dlDmrsSymbPos uint16_t DMRS symbol positions [TS38.211, sec 7.4.1.1.2 and

Tables 7.4.1.1.2-3 and 7.4.1.1.2-4]
Bitmap occupying the 14 LSBs

with:
bit 0: first symbol
and for each bit
0: no DMRS
1: DMRS
dmrsConfigType uint8_t DL DMRS config type [TS38.211, sec 7.4.1.1.2]
0: type 1
1: type 2
dlDmrsScramblingId uint16_t DL-DMRS-Scrambling-ID [TS38.211, sec 7.4.1.1.2 ]
If provided by the higher-layer and the PDSCH is
scheduled by PDCCH with CRC scrambled by C-RNTI
or CS-RNTI, otherwise, L2 should set this to physical
cell id.
Value: 0->65535
SCID uint8_t DMRS sequence initialization [TS38.211, sec
7.4.1.1.2]. Should match what is sent in DCI 1_1,
otherwise set to 0.
Value : 0->1
numDmrsCdmGrpsNo uint8_t Number of DM-RS CDM groups without data
Data [TS38.212 sec 7.3.1.2.2] [TS38.214 Table 4.1-1] it
determines the ratio of PDSCH EPRE to DM-RS EPRE.
Value: 1->3
dmrsPorts uint16_t DMRS ports. [TS38.212 7.3.1.2.2] provides
description between DCI 1-1 content and DMRS
ports.

Version: 1.0.5 71

with:
bit 0: antenna port 1000
and for each bit
0: DMRS port not used
1: DMRS port used
Pdsch Allocation in frequency domain [TS38.214, sec 5.1.2.2]

resourceAlloc uint8_t Resource Allocation Type [TS38.214, sec 5.1.2.2]
0: Type 0
1: Type 1
rbBitmap uint8_t[36] For resource alloc type 0.
TS 38.212 V15.0.x, 7.3.1.2.2 bitmap of RBs, 273
rounded up to multiple of 32. This bitmap is in units
of VRBs. LSB of byte 0 of the bitmap represents the
first RB of the bwp
rbStart uint16_t For resource allocation type 1. [TS38.214, sec
5.1.2.2.2]
The starting resource block within the BWP for this
PDSCH.
Value: 0->274
rbSize uint16_t For resource allocation type 1. [TS38.214, sec
5.1.2.2.2]
The number of resource block within for this PDSCH.
Value: 1->275
VRBtoPRBMapping uint8_t VRB-to-PRB-mapping [TS38.211, sec 7.3.1.6]
0: non-interleaved
1: interleaved with RB size 2
2: Interleaved with RB size 4
Resource Allocation in time domain [TS38.214, sec 5.1.2.1]

StartSymbolIndex uint8_t Start symbol index of PDSCH mapping from the start
of the slot, S. [TS38.214, Table 5.1.2.1-1]
Value: 0->13
NrOfSymbols uint8_t PDSCH duration in symbols, L [TS38.214, Table
5.1.2.1-1]
Value: 1->14
PTRS [TS38.214, sec 5.1.6.3]

PTRSPortIndex uint8_t PT-RS antenna ports [TS38.214, sec 5.1.6.3]
[TS38.211, table 7.4.1.2.2-1]

with:

Version: 1.0.5 72
and for each bit
0: PTRS port not used
1: PTRS port used
PTRSTimeDensity uint8_t PT-RS time density [TS38.214, table 5.1.6.3-1]
0: 1
1: 2
2: 4
PTRSFreqDensity uint8_t PT-RS frequency density [TS38.214, table 5.1.6.3-2]
0: 2
1: 4
PTRSReOffset uint8_t PT-RS resource element offset [TS38.211, table
7.4.1.2.2-1]
Value: 0->3
nEpreRatioOfPDSCHT uint8_t PT-RS-to-PDSCH EPRE ratio
oPTRS [TS38.214, table 4.1-2]
Value :0->3
Beamforming
Beamforming
Tx Power info
powerControlOffset uint8_t Ratio of PDSCH EPRE to NZP CSI-RSEPRE [TS38.214,
sec 5.2.2.3.1]
Value :0->23
powerControlOffsetSS uint8_t Ratio of SSB/PBCH block EPRE to NZP CSI-RS EPRES
[TS38.214, sec 5.2.2.3.1]
Values:
0: -3dB,
1: 0dB,
2: 3dB,
3: 6dB
CBG fields
IsLastCbPresent uint8_t Indicates whether last CB is present in the CBG
retransmission
0: CBG retransmission does not include last CB
1: CBG retransmission includes last CB
If CBG Re-Tx includes last CB, L1 will add the TB
CRC to the last CB in the payload before it is read
into the LDPC HW unit
isInlineTbCrc uint8_t Indicates whether TB CRC is part of data payload or
control message

Version: 1.0.5 73
0: TB CRC is part of data payload
1: TB CRC is part of control message
dlTbCrc uint32_t TB CRC: to be used in the last CB, applicable only if
last CB is present
Table 3-38 DLSCH PDU
3.4.2.3 CSI-RS PDU
The format of the CSI-RS PDU is shown in Table 3-39.

BWP [TS38.213 sec 12]
Value: 1->275
[TS38.213 sec 12]
Value: 0->274
Value:0->4
StartRB uint16_t PRB where this CSI resource starts related to common
resource block #0 (CRB#0). Only multiples of 4 are
allowed. [TS38.331, sec 6.3.2 parameter CSI-
FrequencyOccupation]
Value: 0 ->274
NrOfRBs uint16_t Number of PRBs across which this CSI resource spans.
[TS38.331, sec 6.3.2 parameter CSI-
FrequencyOccupation]
Value: 1 -> BWPSize

CSIType uint8_t CSI Type [TS38.211, sec 7.4.1.5]
Value:
0:TRS
1:CSI-RS NZP
2:CSI-RS ZP
Row uint8_t Row entry into the CSI Resource location table.
[TS38.211, sec 7.4.1.5.3 and table 7.4.1.5.3-1]
Value: 1-18
FreqDomain uint16_t Bitmap defining the frequencyDomainAllocation
[TS38.211, sec 7.4.1.5.3] [TS38.331 CSI-Resource
Mapping]

Version: 1.0.5 74
Value: Up to the 12 LSBs, actual size is determined by

the Row parameter
SymbL0 uint8_t The time domain location l0 and
firstOFDMSymbolInTimeDomain [TS38.211, sec
7.4.1.5.3]
Value: 0->13
SymbL1 uint8_t The time domain location l1 and
firstOFDMSymbolInTimeDomain2 [TS38.211, sec
7.4.1.5.3]
Value: 2->12
CDMType uint8_t The cdm-Type field [TS38.211, sec 7.4.1.5.3 and table
7.4.1.5.3-1]
Value:
0: noCDM,
1: fd-CDM2,
2: cdm4-FD2-TD2,
3: cdm8-FD2-TD4
FreqDensity uint8_t The density field, p and comb offset (for dot5).
[TS38.211, sec 7.4.1.5.3 and table 7.4.1.5.3-1]
Value:
0: dot5 (even RB),
1: dot5 (odd RB),
2: one,
3: three
ScrambId uint16_t ScramblingID of the CSI-RS [TS38.214, sec 5.2.2.3.1]
Value: 0->1023
Tx Power Info
powerControlOffset uint8_t Ratio of PDSCH EPRE to NZP CSI-RSEPRE [TS38.214,
sec 5.2.2.3.1]
Value :0->23
powerControlOffsetSS uint8_t Ratio of SSB/PBCH block EPRE to NZP CSI-RS EPRES
[TS38.214, sec 5.2.2.3.1]
Values:
0: -3dB,
1: 0dB,
2: 3dB,
3: 6dB
Beamforming
Beamforming
Table 3-39 CSI-RS PDU

Version: 1.0.5 75
3.4.2.4 SSB PDU
The format of the SSB/BCH PDU is shown in Table 3-40.
The SSB/BCH PDU has several options for the payload length and contents these are:
• If the MAC generates the full PBCH payload, the payload length is 31 bits and
Table 3-41 defines payload
• If the PHY generates the timing PBCH information, the payload length is 24
bits and Table 3-41 defines payload
• If the PHY generates the full PBCH payload, Table 3-42 defines the payload
• The choice of PBCH payload generation will be determined when the PHY is
configured.

physCellId uint16_t 𝑐𝑐𝑐𝑐𝑐𝑐𝑐𝑐
Physical cell ID. [TS38.211 sec 7.4.2.1] 𝑁𝑁𝐼𝐼𝐼𝐼
Value: 0->1007
betaPss uint8_t PSS EPRE to SSS EPRE in a SS/PBCH block [TS38.213,
sec 4.1]
Values:
0 = 0dB
1 = 3dB
ssbBlockIndex uint8_t SS/PBCH block index within a SSB burst set
[TS38.211, section 7.3.3.1]. Required for PBCH DMRS
scrambling.
Value: 0->63 (Lmax)
ssbSubcarrierOffset uint8_t ssbSubcarrierOffset or 𝑘𝑘𝑆𝑆𝑆𝑆𝑆𝑆 (TS38.211, section 7.4.3.1)
Value: 0->31
SsbOffsetPointA uint16_t Offset of lowest subcarrier of lowest resource block
used for SS/PBCH block. Given in PRB [TS38.211,
section 4.4.4.2]
Value: 0->2199
bchPayloadFlag uint8_t A value indicating how the BCH payload is generated.
This should match the PARAM/CONFIG TLVs.
Value:
0: MAC generates the full PBCH payload, see Table
3-41, where bchPayload has 31 bits
1: PHY generates the timing PBCH bits, see Table 3-41,
where the bchPayload has 24 bits
2: PHY generates the full PBCH payload, see Table
3-42.
bchPayload struct See Table 3-41 and Table 3-42
Beamforming
Beamforming
Table 3-40 SSB/PBCH PDU

bchPayload uint32_t BCH payload. The valid bits are indicated in the
PARAM/CONFIG TLVs.

Version: 1.0.5 76
If PARAM/CONFIG TLVs indicate MAC generates full
bchPayload then the payload length is 31 bits with the 8
LSB bits being
(SFN, half-radio frame bit, SS/PBCH block idx)
[TS38.212 sec 7.1.1]
Otherwise timing PBCH bits are generated by the PHY.

And for bchPayload the 24 LSB are used.
Table 3-41 MAC generated MIB PDU

DmrsTypeAPosition uint8_t The position of the first DM-RS for downlink and uplink.
Value: 0 -> 1
PdcchConfigSib1 uint8_t The parameter PDCCH-ConfigSIB1 that determines a
common ControlResourceSet (CORESET) a common
search space and necessary PDCCH parameters.
Value: 0 -> 255

CellBarred uint8_t The flag to indicate whether the cell is barred
Value: 0 -> 1
IntraFreqReselection uint8_t The flag to controls cell selection/reselection to intra-
frequency cells when the highest ranked cell is barred,
or treated as barred by the UE.
Value: 0 -> 1
Table 3-42 PHY generated MIB PDU
3.4.2.5 Tx Precoding and Beamforming PDU
The precoding and beamforming PDU is included in the PDCCH, PDSCH, CSI-RS and
SSB PDUs. The format is shown in Table 3-43.

numPRGs uint16_t Number of PRGs spanning this allocation.
Value : 1->275
prgSize uint16_t Size in RBs of a precoding resource block group (PRG) –
to which same precoding and digital beamforming gets
applied.
Value: 1->275
digBFInterfaces uint8_t Number of STD ant ports (parallel streams) feeding into
the digBF
Value: 0->255
For number of PRGs {
PMidx uint16_t Index to precoding matrix (PM) pre-stored at cell
configuration.

Version: 1.0.5 77
Note: If precoding is not used this parameter should be
set to 0.
Value: 0->65535.
for each digBFInterface {
beamIdx uint16_t Index of the digital beam weight vector pre-stored at
cell configuration. The vector maps this input port to
output TXRUs.
Value: 0->65535
}
}
Table 3-43 Tx Precoding and Beamforming PDU
3.4.3 UL_TTI.request
The format of the UL_TTI.request message is shown in Table 3-44. An

UL_TTI.request message indicates the SFN and slot it contains information for. This
control information is for an uplink slot.
sent when the PHY is in the IDLE or CONFIGURED state an ERROR.indication
The following combinations of PDUs are required:
• In order to support PRACH in the subframe, the RACH present field must be
true
• The PUSCH PDU is present when a UE has been instructed to send uplink
data and/or control data on the PUSCH
• The PUCCH PDU is present when a UE has been instructed to send control
data on the PUCCH
• The PRACH PDU is present when a UE may transmit RACH.
• The SRS PDU is present when a UE has been instructed to send SRS.
The PDUs included in this structure have no ordering requirements.

SFN uint16_t SFN
Value: 0 -> 1023

Slot uint16_t Slot
Value: 0 ->159
nPDUs uint8_t Number of PDUs that are included in this message. All
PDUs in the message are numbered in order.
Value: 0 -> 255

RachPresent uint8_t Indicates if a RACH PDU will be included in this
message.

Version: 1.0.5 78
0: no RACH in this slot
1: RACH in this slot
nULSCH uint8_t Number of ULSCH PDUs that are included in this
message.
Value: 0 -> 255

nULCCH uint8_t Number of ULCCH PDUs that are included in this
message.
Value: 0 -> 255

nGroup uint8_t Number of UE Groups included in this message.
Value: 0 -> 8

PDUType uint16_t 0: PRACH PDU, see Section 3.4.3.1
1: PUSCH PDU, see Section 3.4.3.2
2: PUCCH PDU, see Section 3.4.3.3
3: SRS PDU, see Section 3.4.3.4
Value: 0 -> 65535

UL PDU structure See Sections 3.4.3.1 to 3.4.3.4
Configuration
}
In this message, if nGroup > 0 then for each group {
nUe uint8_t Number of UE in this group
For SU-MIMO, one group includes one UE only. For MU-
MIMO, one group includes up to 12 UEs.
Value: 1->6
In the group, for each UE {
PduIdx uint8_t This value is an index for number of PDU identified by
nPDU in this message.
Value: 0->255
}
}
Table 3-44 UL_TTI.request message body
3.4.3.1 PRACH PDU
The format of the PRACH PDU is shown in Table 3-45.

𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶
physCellID uint16_t 10 bits corresponding to 𝑁𝑁𝐼𝐼𝐼𝐼 .
Value: 0 ->1007

Version: 1.0.5 79
NumPrachOcas uint8_t Number of time-domain PRACH occasions within a
PRACH slot, 𝑁𝑁𝑡𝑡𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅 [38.211, sec 6.3.3.2]
Value: 1->7
prachFormat uint8_t RACH format information for the current FD occasion.
This corresponds to one of the supported formats i.e.,
A1, A2, A3, B1, B4, C0, C2, A1/B1, A2/B2 or A3/B3.
[38.211, sec 6.3.3.2]
Values:
0=0
1=1
2=2
3=3
4 = A1
5 = A2
6 = A3
7 = B1
8 = B4
9 = C0
10 = C2
11 = A1/B1
12 = A2/B2
13 = A3/B3
numRa uint8_t Frequency domain occasion index 𝑛𝑛 ∈ {0,1,.., 𝑀𝑀 − 1},
where 𝑀𝑀 equals the higher-layer parameter msg1-FDM
which can take values {1,2,4,8} [38.211, sec 6.3.3.2]
Values: 0->7
prachStartSymbol uint8_t Starting symbol for the first PRACH TD occasion in the
current
PRACH FD occasion. Corresponds to the parameter.
[38.211, sec 6.3.3.2 and Tables 6.3.3.2-2 to 6.3.3.2-4]
Values: 0->13
numCs uint16_t Zero-correlation zone configuration number (RRC
parameter zeroCorrelationZoneConfig). Corresponds to
the L1 parameter 𝑁𝑁cs. [TS38.211, sec 6.3.3.1 and Table
6.3.3.1-5, 6.3.3.1-6 and 6.3.3.1-7]
Value: 0->419
Beamforming
Beamforming structure See Table 3-53
Table 3-45 PRACH PDU
3.4.3.2 PUSCH PDU
The format of the PUSCH PDU is given in Table 3-46.

The PUSCH PDU includes both mandatory and optional parameters, where the
presence of the optional elements is defined in the parameter pduBitmap. The
presence of these optional elements is included based on the following:

Version: 1.0.5 80
• puschData is set if an ULSCH transmission is expected from the UE
• puschData and puschUCI are both set if ULSCH and UCI transmission on
PUSCH is expected from the UE
• puschUCI is set and puschData is not set if UCI information is expected on
PUSCH, but ULSCH is not expected
• puschPtrs is included if PTRS are included in the uplink transmission
• dftsOfdm is included for DFT S-OFDM transmission
Only parameters signalled by pduBitmap are optional, all other parameters are
mandatory (It should be noted that some parameters are only applicable for certain
modes etc. These are still included but their value is ignored by the PHY).
pduBitmap uint16_t Bitmap indicating presence of optional PDUs
Bit 0: puschData (Indicates data is expected on the
PUSCH)
Bit 1:puschUci (Indicates UCI is expected on the
PUSCH)
Bit 2: puschPtrs (Indicates PTRS included (FR2))
Bit 3: dftsOfdm (Indicates DFT S-OFDM transmission)
All other bits reserved

the PDU
Value: 1 -> 65535
Handle uint32_t An opaque handling returned in the RxData.indication

and/or UCI.indication message
BWP [TS38.213 sec 12]

Value: 1->275
[TS38.213 sec 12]
Value: 0->274
Value:0->4
PUSCH information always included

targetCodeRate uint16_t Target coding rate [TS38.214 sec 6.1.4.1]. This is the
number of information bits per 1024 coded bits
expressed in 0.1 bit units
qamModOrder uint8_t QAM modulation [TS38.214 sec 6.1.4.1]

Version: 1.0.5 81
Value: 2,4,6,8 if transform precoding is disabled
Value: 1,2,4,6,8 if transform precoding is enabled
mcsIndex uint8_t MCS index [TS38.214, sec 6.1.4.1], should match
value sent in DCI
Value : 0->31
mcsTable uint8_t MCS-Table-PUSCH [TS38.214, sec 6.1.4.1]
Value:
0: notqam256 [TS38.214, table 5.1.3.1-1]
1: qam256 [TS38.214, table 5.1.3.1-2]
2: qam64LowSE [TS38.214, table 5.1.3.1-3]
3: notqam256-withTransformPrecoding [TS38.214,
table 6.1.4.1-1]
4: qam64LowSE-withTransformPrecoding [TS38.214,
table 6.1.4.1-2]
TransformPrecoding uint8_t Indicates if transform precoding is enabled or disabled
[TS38.214, sec 6.1.4.1] [TS38.211 6.3.1.4]
Value:
0: enabled
1: disabled
dataScramblingId uint16_t dataScramblingIdentityPdsch [TS38.211, sec 6.3.1.1]
It equals the higher-layer parameter Data-scrambling-
Identity if configured and the RNTI equals the C-RNTI,
otherwise L2 needs to set it to physical cell id.
Value: 0->65535
nrOfLayers uint8_t Number of layers [TS38.211, sec 6.3.1.3]
Value : 1->4
DMRS [TS38.211 sec 6.4.1.1]
ulDmrsSymbPos uint16_t DMRS symbol positions [TS38.211, sec 6.4.1.1.3 and
Tables 6.4.1.1.3-3 and 6.4.1.1.3-4]

with:
bit 0: first symbol
and for each bit
0: no DMRS
1: DMRS
dmrsConfigType uint8_t UL DMRS config type [TS38.211, sec 6.4.1.1.3]
0: type 1
1: type 2
ulDmrsScramblingId uint16_t UL-DMRS-Scrambling-ID [TS38.211, sec 6.4.1.1.1 ]
If provided and the PUSCH is not a msg3 PUSCH,
otherwise, L2 should set this to physical cell id.
Value: 0->65535

Version: 1.0.5 82
puschIdentity uint16_t PUSCH-ID [TS38.211, sec 6.4.1.1.2 ]
If provided and the PUSCH is not a msg3 PUSCH,
otherwise, L2 should set this to physical cell id.
Value: 0->1007
SCID uint8_t DMRS sequence initialization [TS38.211, sec
6.4.1.1.1]. Should match what is sent in DCI 0_1,
otherwise set to 0.
Value : 0->1
numDmrsCdmGrpsN uint8_t Number of DM-RS CDM groups without data [TS38.212
oData sec 7.3.1.1]
Value: 1->3
dmrsPorts uint16_t DMRS ports. [TS38.212 7.3.1.1.2] provides description
between DCI 0-1 content and DMRS ports.

with:
and for each bit
0: DMRS port not used
1: DMRS port used
Pusch Allocation in frequency domain [TS38.214, sec 6.1.2.2]
resourceAlloc uint8_t Resource Allocation Type [TS38.214, sec 6.1.2.2]
0: Type 0
1: Type 1
rbBitmap uint8_t[36] For resource alloc type 0.
[TS38.214, sec 6.1.2.2.1] [TS 38.212, 7.3.1.1.2]
bitmap of RBs, 273 rounded up to multiple of 32. This
bitmap is in units of VRBs. LSB of byte 0 of the bitmap
represents the first RB of the BWP
rbStart uint16_t For resource allocation type 1. [TS38.214, sec
6.1.2.2.2]
The starting resource block within the BWP for this
PUSCH.
Value: 0->274
rbSize uint16_t For resource allocation type 1. [TS38.214, sec
6.1.2.2.2]
The number of resource block within for this PUSCH.
Value: 1->275
VRBtoPRBMapping uint8_t VRB-to-PRB-mapping [TS38.211, sec 6.3.1.7]
Value:
0: non-interleaved

Version: 1.0.5 83
FrequencyHopping uint8_t For resource allocation type 1. [TS38.212, sec 7.3.1.1]
[TS38.214, sec 6.3] Indicates if frequency hopping is
enabled
Value:
0: disabled
1: enabled
txDirectCurrentLocat uint16_t The uplink Tx Direct Current location for the carrier.
ion Only values in the value range of this field between 0
and 3299, which indicate the subcarrier index within
the carrier corresponding to the numerology of the
corresponding uplink BWP and value 3300, which
indicates "Outside the carrier" and value 3301, which
indicates "Undetermined position within the carrier"
are used. [TS38.331, UplinkTxDirectCurrentBWP IE]
Value: 0->4095
uplinkFrequencyShift uint8_t Indicates whether there is 7.5 kHz shift or not.
7p5khz [TS38.331, UplinkTxDirectCurrentBWP IE]
Value:
0: false
1: true
Resource Allocation in time domain [TS38.214, sec 5.1.2.1]

StartSymbolIndex uint8_t Start symbol index of PUSCH mapping from the start
of the slot, S. [TS38.214, Table 6.1.2.1-1]
Value: 0->13
NrOfSymbols uint8_t PUSCH duration in symbols, L [TS38.214, Table
6.1.2.1-1]
Value: 1->14
Optional Data only included if indicated in pduBitmap
puschData structure See Table 3-47
puschUci structure See Table 3-48
puschPtrs structure See Table 3-49
dftsOfdm structure See Table 3-50
Beamforming
Table 3-46 PUSCH PDU

rvIndex uint8_t Redundancy version index [TS38.214, sec
6.1.4], it should match value sent in DCI
Value : 0->3
harqProcessID uint8_t HARQ process number
[TS38.212, sec 7.3.1.1], it should match
value sent in DCI

Version: 1.0.5 84
Value: 0 ->15
newDataIndicator uint8_t Indicates if this new data or a retransmission
[TS38.212, sec 7.3.1.1]
Value:
0: retransmission
1: new data
TBSize uint32_t Transmit block size (in bytes) [TS38.214 sec
6.1.4.2]
Value: 0->65535
numCb uint16_t Number of CBs in the TB (could be more than
the number of CBs in this PUSCH
transmission). Should be set to zero in any of
the following conditions: 1) CBG is not
supported 2) isReTx=0 (new transmission) 3)
tbSize=0
cbPresentAndPositi uint8_t[ceil(numCb/8)] Each bit represents if the corresponding CB is

on present in the current retx of the PUSCH.
1=PRESENT, 0=NOT PRESENT.
Table 3-47 Optional puschData information

harqAckBitLength uint16_t Number of HARQ-ACK bits [TS38.212, section 6.3.2.4]
Value:
0 -> 11 (Small block length)
12 ->1706 (Polar)
Note: Does not include CRC bits
csiPart1BitLength uint16_t Number of CSI part1 bits [TS38.212, section 6.3.2.4
Value:
12 ->1706 (Polar)
csiPart2BitLength uint16_t Number of CSI part2 bits [TS38.212, section 6.3.2.4]
Value:
12 ->1706 (Polar)
AlphaScaling uint8_t Alpha parameter, α , used to calculate number of coded
modulation symbols per layer. [TS38.212, section
6.3.2.4].
Value:
0 = 0.5
1 = 0.65
2 = 0.8
3=1

Version: 1.0.5 85
betaOffsetHarqAck uint8_t Beta Offset for HARQ-ACK bits. [TS38.212, section
6.3.2.4] [TS38.213, Table 9.3-1]
Value: 0->15
betaOffsetCsi1 uint8_t Beta Offset for CSI-part1 bits.
[TS38.212, section 6.3.2.4] [TS38.213, Table 9.3-2]
Value: 0->18
betaOffsetCsi2 uint8_t Beta Offset for CSI-part2 bits.
[TS38.212, section 6.3.2.4] [TS38.213, Table 9.3-2]
Value: 0->18
Table 3-48 Optional puschUci information

numPtrsPorts uint8_t Number of UL PTRS ports [TS38.212, sec 7.3.1.1.2]
Value: 1->2
For numPtrsPorts {
PTRSPortIndex uint16_t PT-RS antenna ports [TS38.214, sec6.2.3.1 and
38.212, section 7.3.1.1.2]

with:
and for each bit
0: PTRS port not used
1: PTRS port used
PTRSDmrsPort uint8_t DMRS port corresponding to PTRS.
Value: 0->11
PTRSReOffset uint8_t PT-RS resource element offset value taken from
[TS38.211, table 6.4.1.2.2-1]
Value: 0->11
}
PTRSTimeDensity uint8_t PT-RS time density [TS38.214, table 6.2.3.1-1]
Value:
0: 1
1: 2
2: 4
PTRSFreqDensity uint8_t PT-RS frequency density [TS38.214, table 6.2.3.1-2]
Value:
0: 2
1: 4

Version: 1.0.5 86
Intel: Follow DLSCH PDU
ulPTRSPower uint8_t PUSCH to PT-RS power ratio per layer per RE
[TS38.214, table 6.2.3.1-3]
Value:
0: 0dB
1: 3dB
2: 4.77dB
3: 6dB
Table 3-49 Optional puschPtrs information

lowPaprGroupNumber uint8_t Group number for Low PAPR sequence
generation. [TS38.211, sec 5.2.2] For
DFT-S-OFDM.
Value: 0->29
lowPaprSequenceNumber uint16_t [TS38.211, sec 5.2.2] For DFT-S-OFDM.
ulPtrsSampleDensity uint8_t Number of PTRS groups. [TS38.214, sec

6.2.3.2]
Value: 1->8
ulPtrsTimeDensityTransformPrecoding uint8_t Number of samples per PTRS group.
[TS38.214, sec 6.2.3.2] [TS38.211, sec
6.4.1.2.2].
Value: 1->4
Table 3-50 Optional dftsOfdm information
3.4.3.3 PUCCH PDU
The format of the PUCCH PDU is given in Table 3-51.
The PUCH PDU includes information regarding SR, HARQ and CSI and the valid data
varies depending on whether it is PUCCH format 0, 1, 2, 3 or 4.

the PDU
Value: 1 -> 65535
Handle uint32_t An opaque handling returned in the UCI.indication

message
BWP [38.213 sec 12

Version: 1.0.5 87
BWPSize uint16_t Bandwidth part size [38.213 sec12]. Number of
Value: 1->275
BWPStart uint16_t Bandwidth part start RB index from reference CRB
[38.213 sec 12]
Value: 0->274
SubcarrierSpacing uint8_t subcarrierSpacing [38.211 sec 4.2]
Value:0->4
CyclicPrefix uint8_t Cyclic prefix type [38.211 sec 4.2]
FormatType uint8_t PUCCH Format Type [38.211, sec 6.3.2.1]
Value: 0 ->4
multiSlotTxIndicator uint8_t This field is to flush, keep or combine the buffer
used for multiple-slot PUCCH transmissions [38.213,
sec 9.2.6]
Value:
0: No multi slot transmission
1: Multi slot transmission starts
2: Multi slot transmission continues
3: Multi slot transmission ends
This filed being ‘0’ or ‘1’ indicates the previous
pucch transmission for this UE (RNTI) is ended incase
L2 doesn’t send ‘3’ for the previous ongoing multi-slot
transmission.
pi2Bpsk uint8_t When enabled, indicates that the UE uses pi/2 BPSK for
UCI symbols instead of QPSK for PUCCH.
[TS 38.213, sec 9.2.5]
Value: 0: disabled, 1: enabled

Pucch Allocation in frequency domain [38.213, sec 9.2.1]
prbStart uint16_t offset

The starting PRB RB BWP within the BWP for this PUCCH,
or first PRB prior to hopping [38.213, sec 9.2.1].
Valid for all formats
Value: 0->274
prbSize uint16_t The number of PRBs within this PUCCH.
Valid for all formats.
Value: 1 -> 16
Pucch Allocation in time domain

Version: 1.0.5 88
StartSymbolIndex uint8_t Start symbol index of PUCCH from the start of the slot,
S. [38.213, sec 9.2.2].
Valid for all formats
Value: 0->13
NrOfSymbols uint8_t PUCCH duration in symbols [38.213, sec 9.2.2]
Values:
1 -2: Valid for formats 0,2
4->14: Valid for formats 1,3,4
Hopping information [38.211, sec 6.3.2.2.1]
freqHopFlag uint8_t Frequency hopping for a PUCCH resource [38.211, sec

6.3.2.2.1]. Valid for all formats
Value:
0: disabled
1: enabled
secondHopPRB uint16_t Index of the first PRB after frequency hopping.
Value:0->274
groupHopFlag uint8_t Flag for group hopping. [38.211, sec 6.3.2.2.1].
Valid for formats 0, 1, 3 and 4.
Value:
0: disabled
1: enabled
sequenceHopFlag uint8_t Flag for sequence hopping. [38.211, sec 6.3.2.2.1]
Value:
0: disabled
1: enabled
hoppingId uint16_t Cell-Specific scrambling ID for group hopping and
sequence hopping. [38.211, sec 6.3.2.2.1]
Value: 0->1023
InitialCyclicShift uint16_t Initial cyclic shift (M0) used as part of frequency
hopping. [38.213, sec 9.2.1 and 38.211, sec
6.3.2.2.2].
Valid for formats 0, 1, 3 and 4
Value: 0->11
dataScramblingId uint16_t dataScramblingIdentityPdsch [38.211, sec 6.3.2.5.1]

Version: 1.0.5 89
It equals the higher-layer parameter Data-scrambling-
Identity if configured and the RNTI equals the C-RNTI,
otherwise L2 needs to set it to physical cell id.
Valid for format 2, 3 and 4.
Value: 0->1023
TimeDomainOccIdx uint8_t An index of an orthogonal cover code [38.211, sec
6.3.2.4.1].
Valid for format 1.
Value: 0->6
PreDftOccIdx uint8_t An index of an orthogonal cover code. [38.211, sec
6.3.2.6.3].
Valid for format 4.
Value: 0->3
PreDftOccLen uint8_t A length of an orthogonal cover code. [38.211, sec
6.3.2.6.3].
Valid for format 4.
Value: 2 or 4
DMRS [38.211 sec 6.4.1.3]
AddDmrsFlag uint8_t Flag for additional DMRS. [38.213, sec 9.2.2].

Valid for formats 3 and 4.
Value:
0 = disabled
1 = enabled
DmrsScramblingId uint16_t Scrambling-ID-0 [38.211, sec 6.4.1.1.1 ]
If provided otherwise, L2 should set this to physical cell
id.
Valid for formats 2,
Value: 0->65535
DMRScyclicshift uint8_t Cyclic shift index for DMRS, M0 [38.211, sec
6.4.1.3.3.1]
Valid for formats 4.
Value: 0 ->9
SRFlag uint8_t Indicates whether there is an SR opportunity in the

UCI.
Valid for format 0 and 1
Value:
0 = no SR
1 = SR opportunity
BitLenHarq uint16_t Bit length of HARQ payload

Version: 1.0.5 90
Value:
0 = no HARQ bits
1->2 = Valid for Formats 0 and 1
2 -> 1706 = Valid for Formats 2, 3 and 4
BitLenCsiPart1 uint16_t Bit length of CSI part 1 payload.
Valid for formats 2, 3 and 4.
Value:
0 = no CSI bits
1 -> 1706
BitLenCsiPart2 uint16_t Bit length of CSI part 2 payload.
Valid for formats 2, 3 and 4.
Value:
0 = no CSI bits
1 -> 1706
Beamforming
Table 3-51 PUCCH PDU
3.4.3.4 SRS PDU
The format of the SRS PDU is shown in Table 3-52.

RNTI uint16_t UE RNTI
Value: 1->65535
Handle uint32_t An opaque handling returned in the
SRS.indication
BWP [TS38.213 sec 12]

Value: 1->275
BWPStart uint16_t Bandwidth part start RB index from reference CRB
[TS38.213 sec 12]
Value: 0->274
Value:0->4

Version: 1.0.5 91
numAntPorts uint8_t Number of antenna ports 𝑁𝑁ap
SRS
[TS38.211, Sec
6.4.1.4.1]
Value:
0 = 1 port
1 = 2 ports
2 = 4 ports
numSymbols uint8_t SRS
Number of symbols 𝑁𝑁symb [TS 38.211, Sec
6.4.1.4.1]
Value:
0 = 1 symbol
1 = 2 symbols
2 = 4 symbols
numRepetitions uint8_t Repetition factor 𝑅𝑅 [TS38.211, Sec 6.4.1.4.3]
Value:
0=1
1=2
2=4
timeStartPosition uint8_t Starting position in the time domain 𝑙𝑙0 [ TS38.211,
Sec 6.4.1.4.1]
Note: the MAC undertakes the translation from
startPosition to 𝑙𝑙0
Value: 0  13
configIndex uint8_t SRS bandwidth config index 𝐶𝐶SRS [TS38.211, Sec
6.4.1.4.3]
Value: 0  63
sequenceId uint16_t SRS
SRS sequence ID 𝑛𝑛ID [TS38.211, Sec 6.4.1.4.2]
Value: 0  1023
bandwidthIndex uint8_t SRS bandwidth index 𝐵𝐵SRS [TS38.211, Sec
6.4.1.4.3]
Value: 0  3
combSize uint8_t Transmission comb size 𝐾𝐾TC [TS38.211, Sec
6.4.1.4.2]
Value:
0 = comb size 2
1 = comb size 4
combOffset uint8_t Transmission comb offset 𝑘𝑘̄TC [TS38.211, Sec
6.4.1.4.3]
Value: 0  1 (combSize = 0)
cs
cyclicShift uint8_t Cyclic shift 𝑛𝑛SRS [TS 38.211, Sec 6.4.1.4.2]
frequencyPosition uint8_t Frequency domain position 𝑛𝑛RRC [TS 38.211, Sec
6.4.1.4.3]

Version: 1.0.5 92
Value: 0  67
frequencyShift uint16_t Frequency domain shift 𝑛𝑛shift [TS38.211, Sec
6.4.1.4.3]
Value: 0  268
frequencyHopping uint8_t Frequency hopping 𝑏𝑏hop [TS38.211, Sec 6.4.1.4.3]
Value: 0  3
groupOrSequenceHopping uint8_t Group or sequence hopping configuration (RRC
parameter groupOrSequenceHopping in SRS-
Resource IE)
Value:
0 = No hopping
1 = Group hopping
groupOrSequenceHopping
2 = Sequence hopping
resourceType uint8_t Type of SRS resource allocation [TS38.211, Sec
6.4.1.4.3]
Value:
0: aperiodic
1: semi-persistent
2: periodic
Tsrs uint16_t SRS-Periodicity in slots [TS38.211 Sec 6.4.1.4.4]
Value:
1,2,3,4,5,8,10,16,20,32,40,64,80,160,320,640,128
0,2560
Toffset uint16_t Slot offset value [TS38.211, Sec 6.4.1.4.3]
Value:0->2559
Beamforming
Table 3-52 SRS PDU
3.4.3.5 Rx Beamforming PDU
The beamforming PDU is included in the PUCCH, PUSCH, PRACH and SRS PDUs. The
format is shown in Table 3-53.

numPRGs uint16_t Number of PRGs spanning this allocation.
Value : 1->275
prgSize uint16_t Size in RBs of a precoding resource block group (PRG) –
to which the same digital beamforming gets applied.

Version: 1.0.5 93
Value: 1->275
digBFInterface uint8_t Number of STD ant ports (parallel streams) feeding into
the digBF
Value: 0->255
For number of PRGs {
for each digBFInterface {
beamIdx uint16_t Index of the digital beam weight vector pre-stored at
cell configuration. The vector maps this input port to
RXRUs.
Value: 0->65535
}
}
Table 3-53 Rx Beamforming PDU
3.4.4 UL_DCI.request
The UL_DCI.request message includes DCI content used for the scheduling of PUSCH
and the message format is shown in Table 3-54.
The separation of DL and UL DCIs introduces greater flexibility into the design and
implementation of the MAC scheduler. Specifically, it permits separate DL (generates
DL DCI) and UL (generates UL DCI) scheduling and removes the requirement to
integrate the UL relevant information with the DL control in DL_TTI.request.

SFN uint16_t SFN
Value: 0 -> 1023

Slot uint16_t Slot
Value: 0 ->159
numPDUs uint8_t Number of PDCCH PDUs that are included in this
message.
Value 0 -> 255
PDUType uint16_t 0: PDCCH PDU
Value 0 -> 65535

PDCCH PDU structure See Section 3.4.2.1
Configuration
}
Table 3-54 UL_DCI.request message body

Version: 1.0.5 94
3.4.5 SLOT errors
The error codes returned in an ERROR.indication generated by the DL_TTI.request

MSG_INVALID_STATE The DL_TTI.request was received when the PHY was in the IDLE
or CONFIGURED state.
SFN_OUT_OF_SYNC The DL_TTI.request was received with a different SFN/SF than

the PHY expected. The PHY has followed the SFN/SF sync
process, see Section 2.2.2.
MSG_BCH_MISSING A SSB PDU was expected in the DL_TTI.request message for

this subframe.
MSG_SLOT_ERR The DL_TTI.request had an invalid format.
Table 3-55 Error codes for ERROR.indication generated by DL_TTI.request
The error codes returned in an ERROR.indication generate by the UL_TTI.request

MSG_INVALID_STATE The UL_TTI.request was received when the PHY was in the IDLE
MSG_SLOT_ERR The UL_TTI.request had an invalid format.
Table 3-56 Error codes for ERROR.indication generated by UL_TTI.request
The error codes returned in an ERROR.indication generate by the UL_DCI.request

MSG_INVALID_STATE The UL_DCI.request was received when the PHY was in the IDLE
MSG_INVALID_SFN The UL_DCI.request message received in subframe N included a

SFN/SF value which was not N-1. The message has been ignored.
MSG_UL_DCI_ERR The UL_DCI.request had an invalid format.
Table 3-57 Error codes for ERROR.indication generated by UL_DCI.request
3.4.6 Tx_Data.request
The format of the TX_Data.request message is described in Table 3-58. This message
contains the MAC PDU data for transmission over the air interface. The PDUs described
in this message must follow the same order as DL_TTI.request.
sent when the PHY is in the IDLE, or CONFIGURED, state an ERROR.indication

Version: 1.0.5 95
SFN
SFN uint16_t
Value: 0 -> 1023
Slot
Slot uint16_t
Value: 0 ->159
Number of PDUs uint16_t Number of PDUs included in this message.
Value 0-> MaxDlPDUsPerSlot

For each PDU {
PDU length uint16_t The total length (in bytes) of the PDU description and
PDU data, without the padding bytes.
Value: 0 → 65535
PDU index uint16_t Used to correlate the MAC PDU with the DL_TTI
PDSCH PDU
Value: 0 → 65535
numTLV uint32_t The number of TLVs describing the data of the
transport block.
Value: 0 -> MaxTLVs
TLVs TLV[numTLV] Always a multiple of 32-bits. See Table 3-59
}
Table 3-58 TxData.request message
tag uint16_t Value: 0 -> 1

0: Payload is carried directly in the value field
1: Pointer to payload is in the value field
length uint16_t Length of the actual payload in bytes, without the

padding bytes
Value: 0 → 65535
value Variable or Always a multiple of 32-bits.

uint32_t Tag=0: Only the most significant bytes of the size
indicated by ‘length’ field are valid. Remaining bytes are
zero padded to the nearest 32-bit boundary
Tag=1: Pointer to the payload. Occupies 32-bits
Tag =2 Offset from the “first address” to the payload is
in the value field. Where the first address is a predefined
value. Occupies 32-bits.
Table 3-59 TLV structure
3.4.6.1 Downlink Data Errors
The error codes returned in an ERROR.indication generate by the TX_Data.request


Version: 1.0.5 96
MSG_INVALID_STATE The TX_Data.request was received when the PHY was in the
IDLE or CONFIGURED state.
MSG_INVALID_SFN The TX_Data.request message received in subframe N included

a SFN/SF value which was not N. The message has been ignored.
MSG_TX_ERR The TX_Data.request had an invalid format.
Table 3-60 Error codes for ERROR.indication
3.4.7 Rx_Data.indication
The format of the RX_Data.indication message is shown in Table 3-61.

SFN uint16_t SFN
Value: 0 -> 1023

Slot uint16_t Slot
Value: 0 ->159
Range 0-> MaxULPDUsPerSlot

For each PDU {
Handle uint32_t The handle passed to the PHY in an UL_TTI.request
PUSCH PDU.
RNTI uint16_t The RNTI passed to the PHY in an UL_TTI.request
PUSCH PDU.
Value: 1 → 65535.
HarqID uint8_t HARQ process ID
Value: 0->15
PDU Length uint16_t Length of PDU in bytes. A length of 0 indicates a CRC or
decoding error.
Value: 0 → 65535
UL_CQI uint8_t SNR
Value: 0-255, representing -64dB to 63dB, with 0.5dB

step size.
0xff should be set if this field is invalid.
Timing advance uint16_t Timing advance 𝑇𝑇𝐴𝐴 measured for the UE [TS 38.213,
Section 4.2]
NTA_new = NTA_old + (TA − 31) ⋅ 16 ⋅ 64⁄2μ
Value: 0  63
0xffff should be set if this field is invalid
RSSI uint16_t RSSI. See Table 3-16 for RSSI definition.

Version: 1.0.5 97
If RSSI is reported in dBFS (see PARAM and CONFIG
measurement TLVs) then this value represents -
128dBFs to 0dBFS with a step size of 0.1dB
If RSSI is reported in dBm (see PARAM and CONFIG
128dBm to 0dB, with a step size of 0.1dB
Value: 0-1280
PDU Variable Contents of PDU. This will be a MAC PDU.
}
Table 3-61 RX_Data.indication message body
3.4.8 CRC.indication
The format of the CRC.indication message is shown in Table 3-62. There can be
more than one CRC.indication messages per slot.

SFN uint16_t SFN
Value: 0 -> 1023

Slot uint16_t Slot
Value: 0 ->159
NumCRCs uint16_t Number of CRCs (PDUs) with status indication
included in this message.
Range 0-> MaxULPDUsPerSlot

For each CRC {
Handle uint32_t The handle passed to the PHY in an
UL_TTI.request PUSCH PDU
PUSCH PDU.
Value: 1 → 65535
HarqID uint8_t HARQ process ID
Value: 0->15
TbCrcStatus uint8_t Indicates CRC result on TB data.
Value:
0 = pass
1 = fail
NumCb uint16_t If CBG is not used this parameter can be set to
zero. Otherwise the number of CBs in the TB.
Value: 0->65535

Version: 1.0.5 98
CbCrcStatus uint8_t[ceil(NumCb/8)] If NumCb=0 this field is not present.
Otherwise each bit ondicates CRC result on CB
data.
Value:
0 = pass
1 = fail
UL_CQI uint8_t SNR
Value: 0-255, representing -64dB to 63dB, with

0.5dB step size.
Timing uint16_t Timing advance 𝑇𝑇𝐴𝐴 measured for the UE
advance [TS38.213, Section 4.2.]
Value: 0  63
If RSSI is reported in dBFS (see PARAM and
CONFIG measurement TLVs) then this value
represents -128dBFs to 0dBFS with a step size of
0.1dB
If RSSI is reported in dBm (see PARAM and
CONFIG measurement TLVs) then this value
represents -128dBm to 0dB, with a step size of
0.1dB
Value: 0-1280
}
Table 3-62 CRC.indication message body
3.4.9 UCI.indication
The format of the UCI.indication message is shown in Table 3-63.
The UCI.indication message includes optional parameters and the same message is
used for UCI received on both PUSCH and PUCCH. There can be more than 1
UCI.indication message per slot.
The format of the UCI.indication message is dependent on whether the UCI is

transmitted on:
• PUSCH
• PUCCH Format 0 or 1
• PUCCH Format 2,3 or 4
The optional parameters are included based on information expected on UCI.
• SR parameters are included if a PUCCH PDU included as SR opportunity

• HARQ parameters are included if PUCCH or PUSCH PDU included HARQ

Version: 1.0.5 99
• CSI part 1 parameters are included if PUCCH or PUSCH PDU included CSI
CSI part 2 parameters are included if PUCCH or PUSCH PDU included CSI part 2

SFN
SFN uint16_t
Value: 0 -> 1023
Slot
Slot uint16_t
Value: 0 ->159
NumUCIs uint16_t Number of UCIs included in this message.
Range 0-> MaxUCIsPerSlot

For each UCI {
0: UCI indication PDU carried on PUSCH, see Section

3.4.9.1.
PDUType uint16_t 1: UCI indication PDU carried on PUCCH Format 0 or 1,
see Section 3.4.9.2.
2: UCI indication PDU carried on PUCCH Format 2, 3 or
4, see Section 3.4.9.3.
Size of the PDU information (in bytes). This length
value includes the 4 bytes required for the PDU type
PDUSize uint16_t and PDU size parameters.
Value 0 -> 65535

UCI PDU
structure See Sections 3.4.9.1 to 3.4.9.3.
Information
}
Table 3-63 UCI.indication message body
3.4.9.1 PUSCH PDU
The format of a PUSCH PDU is shown in Table 3-64 and used for UCI received on the
PUSCH.

pduBitmap uint8_t Bitmap indicating presence of optional PDUs.
Value: 0 = not present, 1 = present
Bit 0: not used

Bit 1: HARQ
Bit 2: CSI Part 1
Bit 3: CSI Part 2
PUSCH PDU.
PUSCH PDU.
Value: 1 → 65535.
UL_CQI uint8_t SNR

Version: 1.0.5 100

step size.
Section 4.2]
Value: 0  63
Value: 0-1280
HARQ information structure Included if indicated by pduBitmap. See Table 3-70 for
details
CSI part1 structure Included if indicated by pduBitmap. See Table 3-71 for
information details
information details
Table 3-64 UCI PUSCH PDU
3.4.9.2 PUCCH PDU Format 0/1
The format of a PUCCH PDU Format 0/1 is shown in Table 3-65 and used for UCI
received on the PUCCH with either Format 0 or 1.

Bit 0: SR
Bit 1: HARQ

PUCCH PDU.
PUCCH PDU.
Value: 1 → 65535.
PUCCH format
PucchFormat uint8_t Value: 0 -> 1

0: PUCCH Format0
1: PUCCH Format1
UL_CQI uint8_t SNR

Version: 1.0.5 101

step size.
Section 4.2]
Value: 0  63
Value: 0-1280
SR information structure Included if indicated by pduBitmap. See Table 3-67 for
details
details
Table 3-65 UCI PUCCH Format 0 or 1 PDU
3.4.9.3 PUCCH PDU Format 2/3/4
The format of a PUCCH PDU Format 2/3/4 is shown in Table 3-66 and used for UCI
received on the PUCCH with either Format 2, 3 or 4.

Bit 0: SR
Bit 1: HARQ
Bit 2: CSI Part 1
Bit 3: CSI Part 2
PUCCH PDU.
PUCCH PDU.
Value: 1 → 65535.
PUCCH format
Value: 0 -> 2
PucchFormat uint8_t 0: PUCCH Format2
1: PUCCH Format3
2: PUCCH Format4
UL_CQI uint8_t SNR

Version: 1.0.5 102

step size.
Section 4.2]
Value: 0  63
Value: 0-1280
SR information structure Included if indicated by pduBitmap. See Table 3-69 for
details
details
information details
information details
Table 3-66 UCI PUCCH Format 2, 3 or 4 PDU
3.4.9.4 SR, HARQ and CSI Part 1/ 2 PDUs
The UCI tables for the SR, HARQ, CSI Part 1 and CSI Part 2 are provide in this
Section.

SRindication uint8_t Indicates if an SR was detected.
Value:
0 = SR not detected
1 = SR detected
SRconfidenceLevel uint8_t Confidence level of detected SR
Indicates the likelihood that the decoded output for this
PDU are is correct.
Value:
0 = Good
1 = Bad
0xff should be set if this field is invalid
Table 3-67 SR PDU for Format 0 or 1

Version: 1.0.5 103
NumHarq uint8_t Number of HARQ bits present in UCI
Value: 1->2
HarqconfidenceLevel uint8_t Confidence level of detected HARQ.
Indicates the likelihood that the decoded output for this
PDU are is correct.
Value:
0 = Good
1 = Bad
0xff should be set if this field is invalid
For NumHarq {
Indicates result on HARQ data.
Value:
HarqValue uint8_t
0 = pass
1 = fail
2 = not present
}
Table 3-68 HARQ PDU for Format 0 or 1

SrBitLen uint16_t Length of SR payload in bits
Value: 1 -> 8
SrPayload uint8_t[ceil(SrBitLen/8)] Contents of SR
Table 3-69 SR PDU for Format 2, 3 or 4

HarqCrc uint8_t Indicates CRC result on HARQ data.
Value:
0 = pass
1 = fail
2 = not present
HarqBitLen uint16_t Length of Harq payload in bits
Value: 1 -> 1706

HarqPayload uint8_t[ceil(HarqBitLen/8)] Contents of HARQ
Table 3-70 HARQ PDU for Format 2, 3 or 4

CsiPart1Crc uint8_t Indicates CRC result on CSI Part1 data.

Version: 1.0.5 104
Value:
0 = pass
1 = fail
2 = not present
CsiPart1BitLen uint16_t Length of CSI payload in bits
Value: 1 ->1706
CsiPart1Payload uint8_t[ceil(csiPart1BitLen/8)] Contents of CSI. This will be raw data
matching CSI payload built by UE.
Table 3-71 CSI Part1 PDU

Indicates CRC result on CSI Part2 data.
Value:
CsiPart2Crc uint8_t 0 = pass
1 = fail
2 = not present
CsiPart2BitLen uint16_t Length of CSI payload in bits
Value: 1 ->1706
CsiPart2Payload uint8_t[ceil(csiPart2BitLen/8)] Contents of CSI. This will be raw data
matching CSI payload built by UE.
Table 3-72 CSI Part2 PDU
3.4.10 SRS.indication
The format of the SRS.indication message is given in Table 3-73.

SFN uint16_t SFN
Value: 0 -> 1023
Slot uint16_t Slot
Value: 0 ->159
Value: 0-> 255

For each SRS PDU {
Handle uint32_t The handle passed to the PHY in the the
UL_TTI.request SRS PDU.
RNTI uint16_t The RNTI passed to the PHY in the UL_TTI.request
SRS PDU.
Value: 1 → 65535.

Version: 1.0.5 105
Timing Advance uint16_t Timing advance 𝑇𝑇𝐴𝐴 measured for the UE [TS38.213,
Section 4.2]
Value: 0  63
0xffff will be set if this field is invalid
numSymbols uint8_t Number of symbols for SRS
Value: 1 -> 4
If a PHY does not report for individual symbols then
this parameter should be set to 1.
wideBandSNR uint8_t SNR value in dB measured within configured SRS
bandwidth on each symbols,
Value: 0  255 representing -64 dB to 63 dB with a

step size 0.5 dB
0xff will be set if this field is invalid
numReportedSymbols uint8_t Number of symbols reported in this message. This
allows PHY to report individual symbols or aggregated
symbols where this field will be set to 1.
Value: 1->4
For each reported symbol {
numRBs uint16_t Number of PRBs to be reported for this SRS PDU.
Value: 0-> 272

For each resource block {
rbSNR uint8_t SNR value in dB.
Value: 0  255 representing -64 dB to 63 dB with a

step size 0.5 dB
0xff will be set if this field is invalid
}
}
}
Table 3-73 SRS.indication message body
3.4.11 RACH.indication
The format of the RACH.indication message is given in Table 3-74. There can be
more than one RACH.indication message per slot.

SFN uint16_t SFN
Value: 0 -> 1023
Slot uint16_t Slot
Value: 0 ->159

Version: 1.0.5 106
Value: 0-> 255
For each PRACH PDU:
physCellID uint16_t This should match value given in PRACH PDU.
Value: 0 ->1007
SymbolIndex uint8_t The index of first symbol of the PRACH TD occasion.
[38.211, sec 6.3.3.2 and Tables 6.3.3.2-2 to 6.3.3.2-4]
Value: 0->13
SlotIndex uint8_t The index of first slot of the PRACH TD occasion in a
system frame
Value: 0->79
FreqIndex uint8_t The index of the received PRACH frequency domain
occasion. [38.211, sec 6.3.3.2]
Value: 0->7
avgRssi uint8_t Average value of RSSI in dB
Value: 0  254 representing -64 dB to 63 dB with a step

size 0.5 dB.
avgSnr uint8_t Average value of SNR in dB
Value: 0  254 representing -64 dB to 63 dB with a step

size 0.5 dB.
numPreamble uint8_t Number of detected preambles in the PRACH occasion.
Value: 0->63
For each preamble
preambleIndex uint8_t Preamble Index.
Value: 0-> 63
Timing uint16_t Timing advance for PRACH. [38.213, sec 4.2]

advance
Value:0 -> 3846
0xffff should be set if this field is invalid.
PreamblePwr uint32_t Received power
Value: 0->170000 representing -140dBM to 30dBM with a

step size of 0.001dB
0xffffffff should be set if this field is invalid
Table 3-74 RACH.indication message body

Version: 1.0.5 107
References
[1] 3GPP TS38.401 NG-RAN Architecture Description v15.4.0
[2] 3GPP TS38.211 NR Physical Channel and Modulation v15.4.0
[3] 3GPP TS38.212 NR Multiplexing and Channel Coding v15.4.0
[4] 3GPP TS38.213 NR Physical Layer Procedures for Control v15.4.0
[5] 3GPP TS38.214 NR Physical Layer Procedures for Data v15.4.0
[6] 3GPP TS38.331 NR Radio Resource Control (RRC) Protocol Specification v15.4.0
[7] 3GPP TS38.104 NR Base-station (BS) Radio Transmission and Reception v15.4.0
[8] 3GPP TS38.300 NR Overall Description Stage-2 v15.4.0
[9] SCF 222 5G Frontend API Specification

Version: 1.0.5 108

Scf222!02!5g-Fapi Phy Spi Spec-Mar20

Uploaded by

Copyright:

Available Formats

Scf222!02!5g-Fapi Phy Spi Spec-Mar20

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

Scf222!02!5g-Fapi Phy Spi Spec-Mar20

Uploaded by

Copyright:

Available Formats

DOCUMENT

RELEASE 10.0 scf.io

Small Cell Forum develops the technical and commercial enablers to

We have driven the standardization of key elements of small cell technology

Today our members are driving solutions that include:

Post Small Cell Forum, PO Box 23, GL11 5WA UK

Member Services memberservices@smallcellforum.org

The 5G FAPI defines internal interfaces and is agnostic to RAN architecture.

A separate 5G nFAPI specification [SCF225] is currently being developed for the

SCF FAPI Support

2G GSM GERAN [SCF224]

3G UMTS UTRAN [SCF048] [SCF224]

3G HSPA HSPA Evolution [SCF048] [SCF224]

4G LTE-NB-IoT EUTRAN-NB-IoT [SCF082] [SCF224] [SCF082] [SCF082] [SCF167]

4G LTE-M LTE-M [SCF082] [SCF224] [SCF082] [SCF082] [SCF167]

5G 5G NR NR [SCF222] [SCF224] [SCF223] [SCF225]* [SCF239]*

*currently under development

SCF FAPI support for different radio access technologies

This version is for release 15 of 3GPP specification.

Figure 1-1 5G Architecture ..........................................................................1

5G NR is standardized by 3GPP (http://www.3gpp.org) and designed as an evolution

Figure 1-1 5G Architecture

Report title: 5G PHY FAPI Specification

data PHY ctrl

Figure 1-2 5G FAPI Architecture

1.2 PHY API

Report title: 5G PHY FAPI Specification

Figure 1-3 5G RAN protocol model

Figure 1-4 PHY API interactions

Report title: 5G PHY FAPI Specification

2.1 Configuration Procedures

The configuration procedures supported by the PHY API are:

Idle State Configured State Running State

CONFIG.request CONFIG.request STOP.request

Report title: 5G PHY FAPI Specification

Figure 2-2 Initialization procedure

PHY state Information returned by PHY

IDLE The PHY indicates which capabilities it supports

CONFIGURED The PHY returns its current configuration

RUNNING The PHY returns invalid state

Report title: 5G PHY FAPI Specification

Report title: 5G PHY FAPI Specification

Report title: 5G PHY FAPI Specification

Figure 2-4 CONFIG message exchange

Report title: 5G PHY FAPI Specification

Report title: 5G PHY FAPI Specification

Figure 2-7 Restart procedure

Report title: 5G PHY FAPI Specification

Figure 2-8 Reset procedure

Two methods of reconfiguration are supported by the PHY. A major reconfiguration

Report title: 5G PHY FAPI Specification

The minor reconfiguration procedure is shown in Figure 2-10. It is typically used in

Report title: 5G PHY FAPI Specification

Figure 2-11 Query procedure

Report title: 5G PHY FAPI Specification

alt Notification type

Figure 2-12 Notification procedures

2.2 Slot Procedures

• Transmission of a 125us, 250us, 500us or 1ms SLOT message