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.
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 | N | N | N | |
| 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 | SRS | N | N | N |
| 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.
RX_DATA.indication FAPI message does not contain the MAC PDU. MAC PDU (TB data) is delivered separatly in NVIPC message. Hence PDU data and FAPI message are populated in two different buffers.
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 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 → 65535Change 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]:
Current implementation supports multi bit SR over PUCCH format 2, 3 and 4. Because the SCF FAPI 10.02 doesn’t provide any field explicitly suggesting bit length of SR in PUCCH_PDU of UL_TTI.request, use the field SRFlag to provide bit length of SR. For eg. if desired bit length of SR is 3, set SRFlag = 3.
A new vendor specific message “SLOT.response” was added since 22-4 release. Before 22-4 release, L2 has to set an event using nvIPC’s notify function to inform L1 about “EOM” after sending the last FAPI message. This works fine for single cell and when all FAPI messages are on time. L1 also uses 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:
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 having no scheduling)
“Dummy” or empty DL/UL TTI are optional/not-required
Notify event from L2 is optional/not-required
The “SLOT.response message” format is as below:
/************************************************
* 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:
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 SLOT.response
Enable this feature by enabling the flag “ENABLE_L2_SLT_RSP” in the cmake command:
cmake .. -DENABLE_L2_SLT_RSP=ON
“SLOT.response” will be enabled by default in 23-1 release. L2 is required to send this vendor specific message in the way described above.
Once the feature is enabled:
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
“Dummy” DL/UL TTI messages in empty slots are optional
Notify event after sending all FAPI messages is optional
ipc_sync_mode in L2 Adapter config file is deprecated
L1 will continue to send a Notify event after all FAPI messages to minimize impact on L2