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.
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”
For multi cells operation, L2 can signal the L2Adapter in 2 ways:
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.
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
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 20ms to complete. 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.
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.
When testing dynamic OAM using aerial_cell_ctrl_cmd.py script, cuBB should be built with -DENABLE_L2_SLT_RSP=ON in cmake command. This build flag will be enabled by default in the future release.
Aerial supports only single section per packet in the UL.
When running E2E test using
cuphycontroller_P5G_SCF_E2E.yaml
, the default 7905 TV is for 2 antennas. In order to test 4 antennas, change the config file to use 7202 TV.
The nvidia-peermem included in CUDA driver doesn’t work with MOFED driver container. The workaround is to install MOFED on the host instead of running MOFED driver container.
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.
UCI indication in Multi-UE per TTI is not handled properly when UL TTI request contains multiple PUCCH formats. This causes wrong UCI indication sent to L2.
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] ...
There is a known issue to run launch_pattern_F08_8C_24d_X2.yaml to change the PRACH parameters and DST/MAC address at once for 4C using script. This feature will work if L2 changs the cell one by one.
F13 4C has intermittent failure on R750 server.
Cell crash when 4UE started to attach. This only happens for the first run/test with a fresh build.
The following test cases are not passing. They could be functionality issues or test framework issues:
Channel
Test Cases
Feature
PUSCH 7351 UciOnPusch DTX 7352 UciOnPusch CRC error 7344 noiseVardB mismatch PUCCH 6637, 6645 timing mismatch 6637-6639, 6646,6647 harq_crc mismatch PDSCH 3332 PDSCH overlap with CSIRS 3271 nCdm = 1 mSlot_mCell 90021 HARQ 90023 empty slot