Limitations

The cuPHY library and binaries are intended for the Linux environment on x86 host machines only.

The supported configurations are currently limited to those listed above. Other configurations are not supported and may not perform well.

Only homogeneous configurations supported for multiple cells.

The configurable YAML parameters enable_h2d_copy_thread, h2d_copy_thread_cpu_affinity, and h2d_copy_thread_sched_priority are optional in the cuphycontroller YAML file. If these parameters are not present, the code will use the default values and throw the exception “YAML invalid key:” on the cuphycontroller console. This exception message has no impact on the functionality and can be disregarded.

GPU Initiated Comms for DL (gpu_init_comms_dl flag in the cuphycontroller config yaml) is required to be enabled by default from 22-2.4 release onwards. The flag enables the feature within Aerial L1 to engage GPU kernels to prepare and send U-Plane packets on the DL as opposed to CPU Initiated Comms (gpu_init_comms_dl=0) which exercises CPU code/consumes CPU cycles to prepare/send U-plane packets on the DL.

No simultaneous DL and UL scheduling in S-slot. However, DL-only s-slot is supported in E2E test with O-RU.

When the FAPI messages for a given cell are sent via nvipc, L1 expects an explicit notify (once per cell) via nvipc. In case of multiple cells, multiple explicit notify API be called from L2. When a cell doesn’t have any messages for a given slot, L1 expects dummy DL_TTI and/or UL_TTI.request i.e (nPDU = 0) to be sent “per cell”. If Slot Response feature is enabled by compiling Aerial with -DENABLE_L2_SLT_RSP=ON, this step is optional.

For multi cells operation, L2 can signal the L2Adapter in 2 ways:

1. Single event per slot which contains SCF FAPI messages for all cells. The single event is raised by calling nvipc notify(1) once per slot after the messages for all the cells are sent.

2. Single event for per cell which is signaled by L2 after all FAPI messages for a given cell are sent. It is expected that multiple nvipc notify(1) are called for multiple cells. The number of times that notify being called should be the number of active cells. A cell is marked active once START.req is received from L2. In this case, L1 expects dummy DL_TTI and UL_TTI described above. This is the default behavior.

To select the operation mode, set the ipc_sync_mode in yaml:

            

            
# Option 1: Sync per slot
ipc_sync_mode: 0
# Option 2: Sync per active cell
ipc_sync_mode: 1
        

If Slot Response feature is enabled by compiling Aerial with -DENABLE_L2_SLT_RSP=ON, this setting is a no-op as L1 does not expect any event from L2

Cell life cycle management:

• All cells have to be configured before any cell start.

• No In-service configuration update.

• CONFIG.request received in CONFIGURED (Out-of-Service) state can be used to change PCI and the supported PRACH parameters specified in dynamic PRACH section in cuBB quickstart guide only. PHY will ignore any other TLVs received in CONFIG.request. If CONFIG.response indicates success, then only PCI and supported PRACH parameters are changed. All other parameters remain as in the initial CONFIG.request received for the cell.

• PHY reconfiguration of a cell in CONFIGURED (Out-of-Service) state can take upto 40ms to complete (details below). Another CONFIG.request for any cell during this time (around 20ms) which is before receiving CONFIG.response will return CONFIG.response with error code “MSG_INVALID_STATE”. ERROR.indication will NOT be sent for this error. L2 needs to wait for receiving CONFIG.response before sending CONFIG.request for another cell in CONFIGURED state.

  1. If Aerial is configured for 4 cells and 3 cells are In-service with data running, reconfiguration of 1 cell (Out-of-Service) can take around 40ms to complete

  2. If Aerial is configured for 4 cells and 3 cells are In-service with no data running, reconfiguration of 1 cell (O-RU) can take around 20 ms to complete

• If CONFIG.response is received with error code “MSG_INVALID_CONFIG”, then reconfiguration was unsuccessful and the cell is still with the configuration received in initial CONFIG.request.

• No UE attach allowed in all cells during the reconfiguration time.

Dynamic M-plane parameters:

• When OAM sends gRPC message to change MAC address in M-plane, it must be a valid O-RU MAC address.

Aerial supports only single section per packet in the UL.

The nvlog_observer and nvlog_collect are deprecated in 23-1.

F13 test cases are deprecated in 23-2.

All SRS PDUs in a UL_TTI.requst have to use same Csrs index from the SRS bandwidth configuration table (3GPP TS 38.211: 6.4.1.4.3-1) i.e. have the same PRB range (start Prb & num Prb). Number of Symbols can still be varied across SRS PDU’s in UL TTI but are limited to max 4 symbols.

Early HARQ in UCI.indication: - This feature is supported only for single cell and for UCI-on-PUSCH only.

• UCI.Indication with early HARQ will not have any measurement values.

• If only HARQ is scheduled on PUSCH then with this feature enabled, no UCI.indication will be sent to L2 after full slot processing of PUSCH. Consequently no measurements for that slot will be reported to L2.

• If CSI reports are also scheduled on PUSCH along with HARQ then UCI.Indication with early HARQ will not have any measurement values. But the UCI.indication sent after full slot processing of PUSCH will have the measurements

• A constraint to enable early-HARQ is that these HARQ bits should be fully resident in OFDM symbols 0-3. So HARQ bits resident in OFDM symbols 0-3 will be in the 1st UCI.indication (i.e. early-HARQ indication) and all other HARQ bits in the subsequent UCI.indication (i.e. after full slot PUSCH processing completes).

The support for CPU Initiated Comms (gpu_init_comms_dl=0) mode is no longer available from 22-2.4 release onwards and it is recommended this mode is not enabled for any testing purposes.

Support up to 8 DMRS ports if the allocations are contiguous in PDSCH and PUSCH.

Some DOCA error messages are not real error. For example, the following messages are debug info:

            

            
E [FH.QUEUE] Doca RxQ created!  ...
[DOCA][ERR][DOCA_GPU::mlx5:1229] ...
        

Changing shm_log_level to 6 or 7 in nvlog_config.yaml causes crash in msg_processing thread.

SCHED_FIFO + 100% CPU poll thread causes system hang on 5.4.0-65-lowlatency kernel. The solution is either one of below two:

• Configure kernel option CONFIG_RCU_NOCB_CPU=y, recompile and install the kernel.

• Upgrade host system to 5.15.0-71-lowlatency or later.

The cuphycontroller prints error and aborts while running F08_8C_59_BFP14 over 2 100Gbps ports. The workaround is to downgrade the CX6-DX NIC FW to 22.35.1012 on the RU emulator server.

The following test cases are not passing. They could be functionality issues or test framework issues: