Enforce N_PRB=2^x3^y5^z in SC-FDMA uplink scheduler #247
Conversation
|
CI Build: #570 | Failed on the following stages: |
PC-OC
force-pushed
the
scfdma-uplink-scheduler-rbsize
branch
from
cb94c6c to
8aca922
Compare
Looks fine, here some replays from SC-FDMA to check we were not simply lucky: |
|
CI Build: #581 | Failed on the following stages: |
|
one more thing, there is old code that we should remove or rework: |
PC-OC
force-pushed
the
scfdma-uplink-scheduler-rbsize
branch
from
8aca922 to
f37f4c1
Compare
|
Hi @rorsc, I have been told that some code enforcing it was already existing. After checking at pre-existing code I found out some cases were not treated so I dealt with them. I let what was done previously as a second safeguard but could be removed if needed. |
do you refer to the patch that I shared with you here? #247 (comment) or what do you mean with "some code"? the way it was dealt with is obviously not sufficient. So still, I suggest you remove what was there, and reimplement it anew. The old code makes the binary search function also more complicated. |
|
For the case of using min_rb as rbSize, I have done another LUT. One question has been raised. For the values 271, 272, 273 they do not fit 2^x3^y5^z. So I chose to let the value 270 but in this case we will have rbSize < rb_min. |
Making rb_min=273 is simply fundamentally incompatible with SC-FDMA, because you can't have that number of RBs. So either we simply override, or we assert. I am ok with either behavior, and have the only remark that the earlier we stop, the better. |
Sorry for the imprecision, I was speaking about the |
|
CI Build: #608 | Failed on the following stages: |
PC-OC
force-pushed
the
scfdma-uplink-scheduler-rbsize
branch
2 times, most recently
from
2530497 to
1b8560c
Compare
PC-OC
force-pushed
the
scfdma-uplink-scheduler-rbsize
branch
from
1b8560c to
a333e1c
Compare
|
CI Build: #615 | Failed on the following stages: |
|
CI Build: #616 | Failed on the following stages: |
PC-OC
force-pushed
the
scfdma-uplink-scheduler-rbsize
branch
from
a333e1c to
20add78
Compare
|
CI Build: #620 | Failed on the following stages: |
PC-OC
force-pushed
the
scfdma-uplink-scheduler-rbsize
branch
from
20add78 to
69cde6c
Compare
…nto integration_2026_w27 Enforce N_PRB=2^x3^y5^z in SC-FDMA uplink scheduler (#247) With SC-FDMA, the scheduler in uplink needs to schedule N_PRB=2^x3^y5^z. Not enforcing it may lead to unwanted UE behavior like retransmissions and re-establishments. TS38.211 - 6.3.1.4 Reviewed-by: Robert Schmidt <robert.schmidt@openairinterface.org>
| int check_sc_fdma_rbsize(long transform_precoding, uint16_t rb) | ||
| { | ||
| if (transform_precoding == NR_PUSCH_Config__transformPrecoder_enabled) { | ||
| return rb < 274 ? NR_TRANSFORM_PRECODE_RB_LUT[rb] : NR_TRANSFORM_PRECODE_RB_LUT[273]; |
There was a problem hiding this comment.
Not sure if it makes sense to check RB < 274 since the max BWP is 273 RBs. I would have rather put an assertion. But it's not a blocking point.
|
CI Build: #622 | Failed on the following stages: |
|
there is a segfault in the beginning, something is not right, please check |
*scc->uplinkConfigCommon->initialUplinkBWP->rach_ConfigCommon->choice.setup->msg3_transformPrecoder can have a null pointer |
PC-OC
force-pushed
the
scfdma-uplink-scheduler-rbsize
branch
from
69cde6c to
cc697c5
Compare
Signed-off-by: Calvin Peyron <calvin.peyron@open-cells.com>
Signed-off-by: Calvin Peyron <calvin.peyron@open-cells.com>
PC-OC
force-pushed
the
scfdma-uplink-scheduler-rbsize
branch
from
cc697c5 to
ce95a4d
Compare
|
CI Build: #639 | Failed on the following stages: |
0.803 fatal: unable to access '': The requested URL returned error: 502 |
|
CI Build: #636 | Failed on the following stages: |
| else | ||
| ul_bler_options->harq_round_max = *gpd(params, np, MACRLC_UL_HARQ_ROUND_MAX)->u8ptr; | ||
| RC.nrmac[j]->min_grant_prb = *gpd(params, np, MACRLC_MIN_GRANT_PRB)->u16ptr; | ||
| long uses_sc_fdma = 0; |
There was a problem hiding this comment.
that's exactly wrong. check_sc_fdma_rbsize() uses NR_PUSCH_Config__transformPrecoder_enabled to check if SC-FDMA is enabled. that constant is 0, so here, by default and if msg3_transformPrecoder is not set, will be set to enabled when it should be disabled.
please fix
There was a problem hiding this comment.
IOW, initialize with NR_PUSCH_Config__transformPrecoder_disabled
| } | ||
| int new_min = check_sc_fdma_rbsize(uses_sc_fdma, RC.nrmac[j]->min_grant_prb); | ||
| // NR_PUSCH_Config__transformPrecoder_enabled = 0 | NR_PUSCH_Config__transformPrecoder_disabled = 1, so !uses_sc_fdma should be used | ||
| if (!uses_sc_fdma && RC.nrmac[j]->min_grant_prb != new_min) { |
There was a problem hiding this comment.
i know that you have that comment, but it's really confusing that !uses_sc_fdma means "we have SC-FDMA"
one suggestion I have is to rename the variable and check
sc_fdma == NR_PUSCH_Config__transformPrecoder_enabled
then it's clear and the 0/1 confusion is not visible
4 participants
With SC-FDMA, the scheduler in uplink needs to schedule N_PRB=2^x3^y5^z. Not enforcing it may lead to unwanted UE behavior like retransmissions and re-establishments.
TS38.211 - 6.3.1.4