The PDSCH dmrs port and CDM group may not match

[lpg-delete]

Issue Description

void srsran::dmrs_pdsch_processor_impl::map(resource_grid_mapper& mapper, const config_t& config) unsigned nof_cdm_groups = divide_ceil(nof_dmrs_ports, cdm_group_size);

The number of CMD groups occupied by dmrs ports can be obtained by querying dmrs ports and 38211Table 7.4.1.1.2-1 Table 7.4.1.1.2-2.

For example: downlink scheduling double-layer, dmrs ports are assigned 0 and 1, they are a CDM group, but assigned 0 and 2, they are not a CMD group

Expected Behavior

According to dmrs_port in PDSCH PDU in fapi message DL_TTI_request

srsRAN_Project\include\srsran\fapi\messages.h struct dl_pdsch_pdu { uint16_t dmrs_ports; }

[xavierarteaga]

Hi @lpg-delete, You are right. The DM-RS generator assumes that the ports are consecutive and uses a single CDM group. In addition, the gNb's MAC always schedules the DL DCIs with ports 0 and 1.

I don't have a use case for selecting the DM-RS ports dynamically; hence, it is neither supported by the physical layer nor MAC. So, this is not a defect/issue but a missing feature in the physical and MAC layers.

Perhaps if you could share your use case for using different CDM groups for each port, we could consider supporting this feature.

[xavierarteaga]

In addition to my previous comment, we decided to fix the PDSCH to the lowest number of CDM groups for using the REs between DM-RS for data. This gives the gNodeB slightly more throughput.

[lpg-delete]

In addition to my previous comment, we decided to fix the PDSCH to the lowest number of CDM groups for using the REs between DM-RS for data. This gives the gNodeB slightly more throughput.

Thank you for your reply. Yes, fewer DMRS CDM groups will make more RE to carry PDSCH data.

[lpg-delete]

Hi @lpg-delete, You are right. The DM-RS generator assumes that the ports are consecutive and uses a single CDM group. In addition, the gNb's MAC always schedules the DL DCIs with ports 0 and 1.

I don't have a use case for selecting the DM-RS ports dynamically; hence, it is neither supported by the physical layer nor MAC. So, this is not a defect/issue but a missing feature in the physical and MAC layers.

Perhaps if you could share your use case for using different CDM groups for each port, we could consider supporting this feature.

Since I see 8-layer transmission as a feature of the future, there are some issues with calculating the number of code blocks using this(unsigned nof_cdm_groups = divide_ceil(nof_dmrs_ports, cdm_group_size);) when 8 ports are selected