SCF FAPI Support - NVIDIA Docs

Overview

The cuBB SDK supports the 5G FAPI 222.10.02 defined by the Small Cell Forum. This release supports most of the control interface (P5) and data path interface (P7) SCF messages.

SCF FAPI Messages Supported

5G FAPI 222.10.04 is used for SRS PDU in UL_TTI.request and SRS.indication. Version 222.10.02 is not supported for SRS PDU and indication.

The table below summarizes the status of the SCF FAPI messages supported.

SCF messages	PDU types	SCF L2 adapter	SCF TestMAC	E2E with SCF TestMAC and RU emulator
DL_TTI.request	PDCCH	Y	Y	Y
	PDSCH	Y	Y	Y
	CSI-RS	Y	Y	Y^[3]
	SSB	Y	Y	Y
UL_TTI.request	PRACH	Y	Y	Y
	PUSCH	Y	Y	Y
	PUCCH	Y	Y	Y
	SRS^[5]	Y	Y	Y
UL_DCI.request	PDCCH	Y	Y	Y
SLOT errors		N	N	N
TX_Data.request^[1]	PDSCH	Y	Y	Y
Rx_Data.indication^[1]	PUSCH (also contains RNTI, HARQ Id, UL_CQI, Timing adv, RSSI)	Y	Y	Y
CRC.indication	CRC	Y	Y	Y
UCI.indiaction	PUSCH	Y	Y	Y
	PUCCH format 0,1	Y	Y	Y
	PUCCH format 2,3,4	Y	Y	PF2 and PF3 only
	SR for format 0,1	Y	Y	Y
	SR for format 2,3,4	Y	Y	Y^[4]
	HARQ for format 0,1	Y	Y	Y
	HARQ for format 2,3,4	Y	Y	PF2 and PF3 only
	CSI part 1	Y	Y	Y
	CSI part 2	Y	Y	PUSCH only
	RSSI and UL SINR metrics	Y	Y	PUSCH, UCI on PUSCH and PF0,1,2,3
SRS.indication^[5]	SRS	Y	Y	Y
RACH.indication	PRACH	Y	Y	Y
Config.request^[2]		Y	Y
Config.response		Y	Y
Start.request		Y	Y
Stop.request		Y	Y
Stop.indication		Y	Y
Error.indication		Y	Y
Param.request		N	N
Param.response		N	N

Note[1]: The SCF implementation is based on SCF_222.10.02 but with the following exceptions:

PDU Length of TX_DATA.request and RX_DATA.indication are changed to 32-bits. This is defined in SCF_222.10.03.
The current implementation only supports multiple UE per TTI when the TLV tag is 2 in each PDU. However, the offset value in the TLV is ignored and L1 assumes all TBs in that slot placed in a flat buffer one after the other.

The RX_DATA.indication FAPI message contains the MAC PDU (TB data) in the data_buf of the NVIPC message.

Field	Type	Description
TX_DATA.request PDU Length	uint16_t	The total length (in bytes) of the PDU description and PDU data, without the padding bytes. Value: 0 → 65535 Change type to uint32_t, value range is: 0 ~ 2^32 -1 [NVIDIA change]: Use it as the PDU data (TB data) size without the PDU description.
RX_DATA.Indication PDU Length	uint16_t	The length of PDU in bytes. A length of 0 indicates a CRC or decoding error. Value: 0 → 65535 Change type to uint32_t, value range is: 0 ~ 2^32 -1
RX_DATA.Indication PDU	Variable	The contents of PDU. This will be a MAC PDU. [NVIDIA workaround]: Removed this field, do not parse it in wireshark dissector. For SCF_222.10.04, although the tag value is set to 1, the MAC PDU is still delivered in a separate NVIPC buffer.
UL_TTI.request SRFlag	uint8_t	Indicates SR. Only valid for format 0 and 1. [NVIDIA workaround]: Enhance to use it as BitLenSr for format 2, 3, 4.

Note[2]: Precoding Matrix (Table 3-33) with vendor tag 0xA011 is supported. Digital beam table (Table 3-32) is not supported.

Note[3]: For NZP CSI-RS, only 4 antennas and single CSI-RS PDU.

Note[4]: The current implementation supports multi-bit SR over PUCCH format 2, 3 and 1. Because SCF FAPI 10.02 doesn’t provide any field explicitly suggesting the bit length of the SR in the PUCCH_PDU of UL_TTI.request, use the SRFlag field to provide the SR bit length. For example, if the desired SR bit length is 3, set SRFlag = 3.

Note[5]: SRS.indication and SRS PDU in UL_TTI.request are supported only according to SCF FAPI 222.10.04, which needs to be enabled with the “-DSCF_FAPI_10_04=ON” build option, as described in Running cuBB End-to-End.

The format of the SRS.indication message is given in SCF FAPI 222.10.04 Table 3-129; the report TLV is defined in Table 3-130.
Currently, the only supported report type is Normalized Channel I/Q Matrix defined in Table 3.132 for codebook or nonCodebook SRS usage.
The SRS Report TVL tag is 2 (customized value), the length is the actual report size in bytes without padding, the value is not populated. The report data is placed in the data_buf portion of the NVIPC message for all SRS PDUs.

Vendor Specific Message

A new vendor specific message SLOT.response was added since the 22-4 release. Before the 22-4 release, L2 has to set an event using the nvIPC notify function to inform L1 about “EOM” after sending the last FAPI message. This works well for single cell and when all FAPI messages are on time. L1 also uses the nvIPC notify function to set an event after sending each message.

The new SLOT.response FAPI message is used by L2 as the last FAPI message for each cell in each slot. It has the following advantages:

It works as “EOM” for each cell in each slot.
Each cell sends a SLOT.response as the last FAPI message of each slot.
L2 should send SLOT.response even in empty slots (i.e. slots that have no scheduling).
A “Dummy” or empty DL/UL TTI are optional/not-required.
The notify event from L2 is optional/not-required.

The SLOT.response message format is shown below:

Copy
Copied!

            
            /************************************************
*   Slot.response
***********************************************/

typedef struct

{
        scf_fapi_body_header_t msg_hdr;
        uint16_t sfn;
        uint16_t slot;
} __attribute__ ((__packed__)) scf_fapi_slot_rsp_t;

Message-id 0x8F is used for this message
{ …
SCF_FAPI_RX_PRACH_INTEFERNCE_INDICATION = 0x8E,
        SCF_FAPI_SLOT_RESPONSE      = 0x8F,
        SCF_FAPI_RESV_2_END         = 0xFF,
} scf_fapi_message_id_e;

L1 will continue to send a notify event after all FAPI messages to L2 to minimize impact on L2.

Message Sequence

An example message sequence is shown below:

Note

On receiving the first SLOT.indication, L2 is unable to send SLOT.response for 2-3 slots since it has a slot advance of 3.

Impact of Late Messages

All messages are late for a cell (DL_TTI+TX_DATA+UL_DCI or UL_TTI)
- All messages are dropped for the said cell. No impact on other cells.
DL_TTI arrived on time but TX_DATA.request is late for a cell
- This is considered as a partial slot. Due to cell grouping, PDSCH & DL-PDCCH is dropped for all cells.
UL_TTI is late for a cell
- ULSCH is not processed for the said cell. No impact on other cells.
UL_DCI is late for a cell
- UL-PDCCH is not processed for the said cell. No impact on other cells.
SLOT.response is late for a cell
- All FAPI messages received in time will be processed for the cell.

How to Enable or Disable SLOT.response

This feature is enabled by default in L1 since the 23-1 release. When integrating with L2, L2 is required to send this vendor-specific message in the manner described above.

If L2 doesn’t support the SLOT.response message, disable this feature by setting the “-ENABLE_L2_SLT_RSP=OFF” flag in the cmake command:

Copy
Copied!

            
            cmake .. -DENABLE_L2_SLT_RSP=OFF

Once the feature is enabled, the following is true:

L2 has to send a vendor-specific SLOT.response message as the last FAPI message for each cell.
- L2 to send this message even in empty slot (where nothing is scheduled).
allowed_fapi_latency is deprecated and presumed to be 0.
- L2 to complete sending all FAPI messages within the 500 us time-budget marked by SLOT.indication from L1.
- Late FAPI messages will be dropped.
A “Dummy” DL/UL TTI messages in empty slots is optional.
A notify event after sending all FAPI messages is optional.
- ipc_sync_mode in the L2 Adapter config file is deprecated.
L1 will continue to send a Notify event after all FAPI messages to minimize impact on L2.