[srslte-users] Issue on SI / SIB messages

Tue Mar 2 11:42:18 UTC 2021

Hello Cedric Roux,

I understand what you are saying and thank you for your help.

But in the first paragraph in 5.2.1.1 of TS 36.331, a clear difference is made between SI (full message) and SIB messages. So it seems weird for us that this limit on SIB messages impacts the maximum size of the SI messages. 
Maybe we are misunderstanding something but do you think that this TBS limit imposed by the DCI format on the physical layer should not be higher due to the confusion between SI and SIB?

Also, in our case, we have to send multiple posSIBs (same as SIBs) with long assistance information data content coming from an E-SMLC within an LPPa / LPP message (see an example in lppa_message_example.txt file and in the protocol stacks scheme attached). 
Thereby, how can we transmit this amount of information if there is a limit imposed by the physical layer? 
Or maybe do you know if there is another way or if we are wrong in our way to do ?

Thank you again for your help,

Simon Taillefer

-----Message d'origine-----
De : Cedric Roux <cedric.roux at eurecom.fr> 
Envoyé : lundi 1 mars 2021 16:21
À : Taillefer Simon <simon.taillefer at telespazio.com>; srslte-users at lists.softwareradiosystems.com
Cc : Arzel Laurent <laurent.arzel at telespazio.com>; Ayachi Soufian <soufian.ayachi at telespazio.com>
Objet : Re: [srslte-users] Issue on SI / SIB messages

If you look at table 7.1.7.2.3-1 in 36.213 (which is the one to use for DCI format 1C for SI) you see that TBS max is 1736.

For DCI format 1A we have in 36.212:
"- TPC command for PUCCH - 2 bits as defined in section 5.1.2.1 of [3]
    - If the format 1A CRC is scrambled by RA-RNTI, P-RNTI, or SI-RNTI:
      - The most significant bit of the TPC command is reserved.
                                                                   1A
      - The least significant bit of the TPC command indicates column N PRB of the TBS table defined of [3].
                                         1A             1A
       - If least significant bit is 0 then N PRB = 2 else N PRB = 3."

So you can only use 2 or 3 RBs, which means max TBS 2216 (table 7.1.7.2.1-1 of 36.213).

So I think it's the full message that must fit in this, not individual ones. You will need to schedule for SIBs in more than one message I would say.

On 2021-03-01 16:00, Taillefer Simon wrote:
> Hello Cedric Roux,
> 
> We understood these lines as like a SIB (SIB1, SIB2, SIB7 and etc.) have a maximum size of 277 bytes but not the full message (called SI message) that contains all these SIBs. Please find attached an example of what I am trying to explain.
> 
> Our issue is that it is this full SI message that have the maximum size of 277 bytes and not the SIB content as we thought.
> 
> Thank you for your help,
> 
> Simon Taillefer
> 
> -----Message d'origine-----
> De : Cedric Roux <cedric.roux at eurecom.fr> Envoyé : lundi 1 mars 2021 
> 13:56 À : Taillefer Simon <simon.taillefer at telespazio.com>; 
> srslte-users at lists.softwareradiosystems.com
> Objet : Re: [srslte-users] Issue on SI / SIB messages
> 
> see 3gpp document 36.331, 5.2.1.1, they say:
> "NOTE 1: The physical layer imposes a limit to the maximum size a SIB can take. When DCI format 1C is used the
>           maximum allowed by the physical layer is 1736 bits (217 bytes) while for format 1A the limit is 2216 bits
>           (277 bytes), see TS 36.212 [22] and TS 36.213 [23]. For BL UEs and UEs in CE, the maximum SIB and
>           SI message size is 936 bits, see TS 36.213 [23]. For NB-IoT, the maximum SIB and SI message size is
>           680 bits, see TS 36.213 [23]."
> 
> On 2021-02-22 18:23, Taillefer Simon wrote:
>> Hello srsLTE team,
>>
>> Basically, we are encountering an issue on the RRC protocol. We want 
>> to send long SI / SIB messages but when the size is higher than 277 
>> bytes, some errors are raised.
>>
>> More precisely, the errors are:
>>
>> -Error("Computing DL grant\n"); from
>> /srsLTE/srsenb/src/phy/cc_worker.cc
>> /file, around line 519 (depending on the srsLTE version and added 
>> code on our side)
>>
>> -ERROR("Configuring TB Info\n"); from 
>> /srsLTE/lib/src/phy/phch/ra_dl.c /file, around line 627.
>>
>> We found that these errors are coming from the 
>> /grants[i].dci.tb[0].mcs_idx/ variable which has a value of -1
>> (4294967295exactly) instead of an unsigned integer. Then, we suppose 
>> that the size of the corresponding transport block cannot be found in 
>> the tbs_table (/srsLTE/lib/src/phy/phch/tbs_tables.h/file, line 38) 
>> and this is why we have errors raised.
>>
>> So our questions are:
>>
>> -How this /grants[i].dci.tb[0].mcs_idx/variable is calculated?
>>
>> -Do you know why its value is -1 (4294967295) when the size of the SI 
>> / SIB messages is longer than 277 bytes?
>>
>> -Maybe we are on the wrong way so do you know how it is possible to 
>> send long SI / SIB messages?
>>
>> Thank you for your help,
>>
>> *Simon Taillefer***
>>
>>
>>
>>
>> -WARNING: This message contains confidential and/or proprietary 
>> information which may be subject to privilege or immunity and which 
>> is intended for the use of its addressee only.
>> Should you receive this message in error, you are kindly requested to 
>> inform the sender and to definitively remove it from any paper or 
>> electronic format.
>> Any other use of this e-mail is strictly forbidden. Thank you in 
>> advance for your cooperation.
>>
>> Please consider the environment before printing this e-mail.
>>
>> _______________________________________________
>> srslte-users mailing list
>> srslte-users at lists.softwareradiosystems.com
>> http://www.softwareradiosystems.com/mailman/listinfo/srslte-users
>>
> 
> 
> 
> -WARNING: This message contains confidential and/or proprietary information which may be subject to privilege or immunity and which is intended for the use of its addressee only.
> Should you receive this message in error, you are kindly requested to inform the sender and to definitively remove it from any paper or electronic format.
> Any other use of this e-mail is strictly forbidden. Thank you in advance for your cooperation.
> 
> Please consider the environment before printing this e-mail.
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: protocol_stacks.png
Type: image/png
Size: 28715 bytes
Desc: protocol_stacks.png
URL: <https://lists.srsran.com/pipermail/srsran-users/attachments/20210302/832ea909/attachment.png>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: lppa_message_example.txt
URL: <https://lists.srsran.com/pipermail/srsran-users/attachments/20210302/832ea909/attachment.txt>