Limitations

Aerial SDK 23-1
  • 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.

  • CSI-RS is not supported with Foxconn 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:

    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:

    Copy
    Copied!
                

    # 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.

  • Aerial supports only single section per packet in the UL.

  • The nvlog_observer and nvlog_collect are deprecated in 23-1.

  • 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:

    Copy
    Copied!
                

    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.

  • RU emulator reports “PDCCH_DL Complete Cell 0 3GPP slot … validation error” in P5G case.

  • F13 2C, 3C, 4C has intermittent failure.

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

    Channel

    Test Cases

    Feature

    CSIRS 4060 16/32 CSIRS PDUs
    PDSCH 3332 PDSCH overlap with CSIRS
    3271 nCdm = 1
    PUCCH 6248, 6253 24-UE tests for format 2
    PUSCH 7416 big RX signal
    mSlot_mCell 90052 mixed PDSCH + CSIRS cells
    90053 2-cell with S-slot
    90054 ul_gain_calibration
    90055 pusch_prb_stride, max_amp_ul
    90502 TestModel 2 PDSCH + 1 PDCCH
    90503 PDSCH + ZP-CSIRS + NZP-CSIRS
Previous SCF FAPI Support
Next Acknowledgements
© Copyright 2022-2023, NVIDIA.. Last updated on Apr 20, 2024.