[srsran-users] RAR scheduling with mbsfn enabled release 2021_10

Mon Nov 15 20:05:36 UTC 2021

On 11/15/21 13:17, Justin Tallon wrote:
> Hey Joe,
>
> Nice work on the investigation!
Hey Thanks !
>
> Just to clarify, is this with the HEAD of the release or at the commit 
> I previously recommended.
It is the HEAD, it would take me quite a bit to merge our changes in.
>
> In any case, the subframe allocation works as follows:
>
> Subframes 1,2,3 6,7,8 are possible for mbms.
>
> The number provided is a bit mask for these subframes, so 63 is 111 
> 111 meaning all 6 possible subframes are scheduled for mbms.
>
> 33 would be 100001 so only 1 and 8 are scheduled for mbms.
>
> It's likley that the RAR is in subframes 2,3 6 or 7 and thats why 
> freeing them up fixed the issues, try using a prach config that would 
> result in the RAR landing on a non mbms subframe ie 0, 4, 5 or 9 and 
> try again with 63.
>
So I set the prach_config_index to 4 and now the response comes back at 
sf 9 which is what zmq seems to use with the default pcarch_config_index 
of 3.

Its interesting that zmq always seems to pick 9, maybe the timing 
advance or some other phenomena of streaming IQ vs msg passing.

19:52:29.395065 [PHY    ] [I] [ 5426] PDCCH:enb_dl_put_dl_pdcch_i: cc=0, 
cellId 1, rnti 0x5, pdcch_seqnum 2931, type DL
19:52:29.395069 [PHY0   ] [I] [ 5425] PDCCH_DL: cc=0, rnti=0x5, f=1A, 
cce= 0, L=2, riv=100, pid=0, mcs={1}, ndi={0}, tpc_pucch=0, tti_tx_dl=5429
19:52:29.395080 [PHY    ] [I] [ 5426] PDSCH:enb_dl_put_dl_pdsch_i: cc=0, 
cellId 1, rnti 0x5, pdsch_seqnum 2924
19:52:29.395083 [PHY0   ] [I] [ 5425] PDSCH: cc=0, rnti=0x5, nof_prb=3, 
nof_re=450, tbs={11}, mod={2}, rv={0}, tti_tx_dl=5429

 From what I understand the response can come back in a window, which I 
believe is set to 10ms, so Im not sure that this will work every time 
even if I trim it down a bit can I force RAR in say sf 4 or 5 ?

This is first time we are seeing this on our end.

Thanks for the help and super quick response.

Joe

>
> Regards,
> Justin
>
>
>
>
>
> On Mon, 15 Nov 2021, 18:25 J Giovatto, <jgiovatto at adjacentlink.com> wrote:
>
>     Hi Folks,
>
>     In our emulation environment I have seen some issue where the ue's
>     can not connect. It is random but reproducible
>
>     only in our emulation environment and not using zmq, though all of
>     the config is essentially the same and in line with what is in the
>     release, with 1 excpetion is we use 1 phythread.
>
>     With the default sib mbsn subframe allocation default setting of
>     63, we will see illustrated below (log changes attached) where the
>     enb will schedule
>
>     what I believe is the RAR (rnti 0x2) on an mbsfn subframe.
>
>     Below is a 2 ue connect snapshot ...
>
>     17:00:30.392495 [MAC    ] [I] [  901] SCHED: Added user rnti=0x46
>
>     17:00:30.392501 [MAC    ] [I] [  901] SCHED: rnti=0x46, new lcid
>     configuration: [{lcid=0, mode=bi-dir, prio=1, lcg=0}]
>     17:00:30.392502 [MAC    ] [I] [  901] SCHED: Resetting rnti=0x46,
>     cc=0 HARQs and feedback state
>     17:00:30.392502 [MAC    ] [I] [  901] SCHED: rnti=0x46 PCell is
>     now enb_cc_idx=0
>     17:00:30.392549 [RRC    ] [I] Setting RLF timer for rnti=0x46 to
>     4000ms
>     17:00:30.392559 [RLC    ] [I] Added LTE radio bearer with LCID 0
>     in Transparent Mode
>     17:00:30.392562 [RRC    ] [I] Added new user rnti=0x46
>     17:00:30.392563 [MAC    ] [I] [  902] SCHED: New PRACH tti=901,
>     preamble=18, temp_crnti=0x46, ta_cmd=0, msg3_size=7
>     17:00:30.392563 [MAC    ] [I] [  902] RACH:  tti=901, cc=0,
>     preamble=18, offset=0, temp_crnti=0x46
>     17:00:30.392570 [MAC    ] [I] [  902] rach_tprof: {mean, max,
>     min}={343.2, 343, 343} usec, nof_samples=1
>     17:00:30.393051 [MAC    ] [I] [  903] SCHED: RAR, ra-rnti=2,
>     rbgs=[0, 1), dci=(2,0), msg3 grants=[{c-rnti=0x46, rba=103, mcs=0}]
>     17:00:30.393068 [PHY    ] [I] [  904] PDCCH:enb_dl_put_dl_pdcch_i:
>     cc=0, cellId 1, rnti 0x2, pdcch_seqnum 1338, type DL
>     17:00:30.393076 [PHY0   ] [I] [  903] PDCCH_DL: cc=0, f=1A, cce=
>     0, L=2, riv=100, pid=0, mcs={1}, ndi={0}, tpc_pucch=0, tti_tx_dl=907
>     17:00:30.393090 [PHY    ] [I] [  904] PDSCH:enb_dl_put_dl_pdsch_i:
>     cc=0, cellId 1, rnti 0x2, pdsch_seqnum 1338
>     17:00:30.393093 [PHY0   ] [I] [  903] PDSCH: cc=0, rnti=0x2,
>     nof_prb=3, nof_re=450, tbs={11}, mod={2}, rv={0}, tti_tx_dl=907
>     17:00:30.395050 [MAC    ] [I] [  905] SCHED: Msg3 tx rnti=0x46,
>     cc=0, pid=1, dci=(0,0), prb=[3, 6), n_rtx=0, cfi=1, tbs=7, bsr=0 (0-7)
>
>     ue-02/var/log/ue.log:17:00:30.392178 [PHY0   ] [W] [ 902]
>     work_dl_mbsfn calling decode_pdcch_dl
>     ue-02/var/log/ue.log:17:00:30.393170 [PHY0   ] [W] [ 903]
>     work_dl_mbsfn calling decode_pdcch_dl
>     ue-02/var/log/ue.log:17:00:30.396182 [PHY0   ] [W] [ 906]
>     work_dl_mbsfn calling decode_pdcch_dl
>     ue-02/var/log/ue.log:17:00:30.397505 [PHY0   ] [W] [ 907]
>     work_dl_mbsfn calling decode_pdcch_dl
>     ue-02/var/log/ue.log:17:00:30.398182 [PHY0   ] [W] [ 908]
>     work_dl_mbsfn calling decode_pdcch_dl
>     ue-02/var/log/ue.log:17:00:30.401166 [PHY0   ] [W] [ 911]
>     work_dl_mbsfn calling decode_pdcch_dl
>     ue-02/var/log/ue.log:17:00:30.402172 [PHY0   ] [W] [ 912]
>     work_dl_mbsfn calling decode_pdcch_dl
>     ue-02/var/log/ue.log:17:00:30.403175 [PHY0   ] [W] [ 913]
>     work_dl_mbsfn calling decode_pdcch_dl
>
>
>
>     17:00:30.411465 [MAC    ] [I] [  921] SCHED: Added user rnti=0x47
>     17:00:30.411471 [MAC    ] [I] [  921] SCHED: rnti=0x47, new lcid
>     configuration: [{lcid=0, mode=bi-dir, prio=1, lcg=0}]
>     17:00:30.411472 [MAC    ] [I] [  921] SCHED: Resetting rnti=0x47,
>     cc=0 HARQs and feedback state
>     17:00:30.411472 [MAC    ] [I] [  921] SCHED: rnti=0x47 PCell is
>     now enb_cc_idx=0
>     17:00:30.411496 [RRC    ] [I] Setting RLF timer for rnti=0x47 to
>     4000ms
>     17:00:30.411505 [RLC    ] [I] Added LTE radio bearer with LCID 0
>     in Transparent Mode
>     17:00:30.411508 [RRC    ] [I] Added new user rnti=0x47
>     17:00:30.411509 [MAC    ] [I] [  921] SCHED: New PRACH tti=921,
>     preamble=21, temp_crnti=0x47, ta_cmd=0, msg3_size=7
>     17:00:30.411509 [MAC    ] [I] [  921] RACH:  tti=921, cc=0,
>     preamble=21, offset=0, temp_crnti=0x47
>     17:00:30.411514 [MAC    ] [I] [  921] rach_tprof: {mean, max,
>     min}={282.2, 343, 221} usec, nof_samples=2
>     17:00:30.412053 [MAC    ] [I] [  922] SCHED: RAR, ra-rnti=2,
>     rbgs=[0, 1), dci=(2,0), msg3 grants=[{c-rnti=0x47, rba=103, mcs=0}]
>     17:00:30.412072 [PHY    ] [I] [  923] PDCCH:enb_dl_put_dl_pdcch_i:
>     cc=0, cellId 1, rnti 0x2, pdcch_seqnum 1341, type DL
>     17:00:30.412076 [PHY0   ] [I] [  922] PDCCH_DL: cc=0, f=1A, cce=
>     0, L=2, riv=100, pid=0, mcs={1}, ndi={0}, tpc_pucch=0,tti_tx_dl=926
>     17:00:30.412086 [PHY    ] [I] [  923] PDSCH:enb_dl_put_dl_pdsch_i:
>     cc=0, cellId 1, rnti 0x2, pdsch_seqnum 1340
>     17:00:30.412088 [PHY0   ] [I] [  922] PDSCH: cc=0, rnti=0x2,
>     nof_prb=3, nof_re=450, tbs={11}, mod={2}, rv={0}, tti_tx_dl=926
>     17:00:30.414046 [MAC    ] [I] [  924] SCHED: Msg3 tx rnti=0x47,
>     cc=0, pid=4, dci=(0,0), prb=[3, 6), n_rtx=0, cfi=1, tbs=7, bsr=0 (0-7)
>
>
>     ue-02/var/log/ue.log:17:00:30.408188 [PHY0   ] [W] [ 918]
>     work_dl_mbsfn calling decode_pdcch_dl
>     ue-02/var/log/ue.log:17:00:30.411181 [PHY0   ] [W] [ 921]
>     work_dl_mbsfn calling decode_pdcch_dl
>     ue-02/var/log/ue.log:17:00:30.412181 [PHY0   ] [W] [ 922]
>     work_dl_mbsfn calling decode_pdcch_dl
>     ue-02/var/log/ue.log:17:00:30.413166 [PHY0   ] [W] [ 923]
>     work_dl_mbsfn calling decode_pdcch_dl
>     ue-02/var/log/ue.log:17:00:30.416494 [PHY0   ] [W] [ 926]
>     work_dl_mbsfn calling decode_pdcch_dl
>     ue-02/var/log/ue.log:17:00:30.417181 [PHY0   ] [W] [ 927]
>     work_dl_mbsfn calling decode_pdcch_dl
>     ue-02/var/log/ue.log:17:00:30.418170 [PHY0   ] [W] [ 928]
>     work_dl_mbsfn calling decode_pdcch_dl
>     ue-02/var/log/ue.log:17:00:30.421175 [PHY0   ] [W] [ 931]
>     work_dl_mbsfn calling decode_pdcch_dl
>
>     If I change the subframe allocation to say (33) the problem goes
>     away as far as I can tell.
>
>     Can you guide to where the decision of the subframe is done and/or
>     provide some suggestions ?
>
>     Thanks
>
>     Joe
>
>     _______________________________________________
>     srsran-users mailing list
>     srsran-users at lists.srsran.com
>     https://lists.srsran.com/mailman/listinfo/srsran-users
>     <https://lists.srsran.com/mailman/listinfo/srsran-users>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.srsran.com/pipermail/srsran-users/attachments/20211115/2b4ea669/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <https://lists.srsran.com/pipermail/srsran-users/attachments/20211115/2b4ea669/attachment-0001.sig>