TBS Mismatch in 5G-LENA Schedulers Due to Wideband vs. Subband MCS Usage

[SUDARSANAN A K]

In 5G-LENA (ns-3), my understanding is that built-in schedulers (e.g., RR, PF) use a wideband MCS to pre-calculate RB/RBG requirements per UE based on BSR in each slot, then refine the MCS post-allocation using subband CQIs averaged over assigned RBGs. This can lead to a TBS mismatch, causing incomplete buffer draining or excess capacity. Can someone confirm this behavior? 

Could this TBS mismatch cause issues (e.g., latency or throughput variability) for application traffic?

Thanks.

Sudarsanan

[Gabriel Ferreira]

Need an example that reproduces the issue. I haven't observed it. 

[Kent Huns]

>>  refine the MCS post-allocation using subband CQIs

I wonder if it's possible for DCI to make UE send PUSCH/receive PDSCH with different MCSs on a single layer, rather than using SU-MIMO or carrier aggregation.

Maybe this scheduling performs like preemption "for the same UE".

If that's the case, HARQ retransmission of the overwritten(pre-calculated) RB is always required, resulting in poor performance.

--
Posting to this group should follow these guidelines https://www.nsnam.org/wiki/Ns-3-users-guidelines-for-posting
---
You received this message because you are subscribed to the Google Groups "ns-3-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ns-3-users+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/ns-3-users/d0120961-909c-4acf-ba84-45ed060023b7n%40googlegroups.com.

[Gabriel Ferreira]

What the schedulers do now is instead of using plain wideband MCS, it will use a MCS estimate based on average sub-band CQI of allocated RBGs.
That same MCS estimate is used for TBS computation and goes into the TB. Then a txop is done to select the data to actually transmit.

>I wonder if it's possible for DCI to make UE send PUSCH/receive PDSCH with different MCSs on a single layer, rather than using SU-MIMO or carrier aggregation.

This is what we are currently doing. Sub-band scheduling is only affecting PDSCH.

>Maybe this scheduling performs like preemption "for the same UE".

I don't understand what you mean.

>If that's the case, HARQ retransmission of the overwritten(pre-calculated) RB is always required, resulting in poor performance.

The number of allocated RBGs and MCS must be same during HARQ retransmissions because of the error modeling.
What we started doing in nr-4.1 is reshaping the HARQ allocation to try to improve average CQI of RBGs (e.g. by avoiding interference if possible),

thus increasing the chance of success in decoding.

[SUDARSANAN A K]

Thanks for all the responses!

>> What the schedulers do now is instead of using plain wideband MCS, it will use a MCS estimate based on average sub-band CQI of allocated RBGs.
That same MCS estimate is used for TBS computation and goes into the TB. Then a txop is done to select the data to actually transmit.

What I understand is that in the built-in schedulers, the wideband MCS, derived from the wideband CQI via "NrAmc::GetMcsFromCqi", is used in "NrMacSchedulerNs3::DoScheduleDlData" to pre-calculate RB/RBG requirements for each UE based on BSR, using "NrAmc::CalculateTbSize" for TBS estimation. Since no RBGs are assigned ("m_dlRBG" is empty), "NrMacSchedulerUeInfo::GetDlMcs" returns this wideband MCS ("m_dlMcs"), set by "NrMacSchedulerCQIManagement::DlCqiReported". These estimates guide RBG allocation in methods like "AssignDLRBG", assigning up to the estimated RBGs per the scheduler’s policy. Post-allocation, if subband CQIs are available and "McsCsiSource" is set to "AVG_MCS", "AVG_SPEC_EFF", or "AVG_SINR", "GetDlMcs" refines the MCS by averaging over assigned RBGs’ subbands (using "m_dlSbMcsInfo" and "m_rbgToSb"). This refined MCS, used for final TBS in "CreateDlDci", may differ from the pre-allocation estimate, potentially causing a TBS mismatch. Is this behavior correct?

Thanks.

[Gabriel Ferreira]

>What I understand is that in the built-in schedulers, the wideband MCS, derived from the wideband CQI via "NrAmc::GetMcsFromCqi", is used in "NrMacSchedulerNs3::DoScheduleDlData" to pre-calculate RB/RBG requirements for each UE based on BSR, using "NrAmc::CalculateTbSize" for TBS estimation.

Where?

>Since no RBGs are assigned ("m_dlRBG" is empty), "NrMacSchedulerUeInfo::GetDlMcs" returns this wideband MCS ("m_dlMcs"), set by "NrMacSchedulerCQIManagement::DlCqiReported".

That is correct. At least initially.

>These estimates guide RBG allocation in methods like "AssignDLRBG", assigning up to the estimated RBGs per the scheduler’s policy. Post-allocation, if subband CQIs are available and "McsCsiSource" is set to "AVG_MCS", "AVG_SPEC_EFF", or "AVG_SINR", "GetDlMcs" refines the MCS by averaging over assigned RBGs’ subbands (using "m_dlSbMcsInfo" and "m_rbgToSb").

This is partially correct. This MCS estimate is done during allocation (AssignDLRBG). The m_dlRBG list get populated at this time.

>This refined MCS, used for final TBS in "CreateDlDci", may differ from the pre-allocation estimate, potentially causing a TBS mismatch.

I have no idea what pre-allocation estimate you are talking about. But yes, during CreateDlDci, this MCS estimate is used instead of the wideband MCS.

[SUDARSANAN A K]

Thank you, Gabriel, for the clarification.

> Where?

This was my understanding based on my interpretation of the codebase, though I acknowledge I may have misunderstood some parts.

> That is correct. At least initially.

Just to confirm, does this mean that during the allocation process, the MCS estimate is iteratively updated. i.e., averaged across the allocated RBs or RBGs as each one is assigned?

> This is partially correct. This MCS estimate is done during allocation (AssignDLRBG). The m_dlRBG list get populated at this time.

Could you please elaborate on how this process works? Specifically, as the m_dlRBG list is populated during allocation, is the m_dlMcs updated at each step by averaging the CQIs of the RBGs allocated so far?

> I have no idea what pre-allocation estimate you are talking about. But yes, during CreateDlDci, this MCS estimate is used instead of the wideband MCS.

I realize now that my earlier assumption about a separate pre-calculation of RB/RBG requirements using BSR and MCS to limit allocations per UE was incorrect.

Thanks once again for your time and patience!

[Gabriel Ferreira]

>  Just to confirm, does this mean that during the allocation process, the MCS estimate is iteratively updated. i.e., averaged across the allocated RBs or RBGs as each one is assigned?

Correct.

> Could you please elaborate on how this process works? Specifically, as the m_dlRBG list is populated during allocation, is the m_dlMcs updated at each step by averaging the CQIs of the RBGs allocated so far?

NrMacSchedulerUeInfo::m_dlMcs is only updated by a new CSI feedback. However, NrMacSchedulerUeInfo::GetDlMcs() recomputes the MCS estimate based on sub-band CQI and allocated RBGs, or uses the wideband mcs (m_dlMcs) in case user wants to use the wideband MCS, or there is no sub-band feedback yet, or there are currently no scheduled DL RBGs.
New RBGs are added via NrMacSchedulerOfdma::AllocateCurrentResourceToUe.

[Kent Huns]

Thank you for your explanation, Gabriel. I misunderstood the feature properly.

>>Maybe this scheduling performs like preemption "for the same UE".

>I don't understand what you mean.

Preemption is a scheduling method for URLLC. It overwrites a resource map that already determined (by RR/PF) and re-allocates for the other latency-critical UEs.

I associated it with this topic, but I hope you won't mind.

(The cons of preemption are significant as mentioned above.)