[srslte-users] Optional SIB decoding
altaf329 at gmail.com
Fri Nov 18 08:33:53 UTC 2016
I was playing a bit more and found that,
SIB5 and SIB6 and SIB7 have same periodicity but I could only decode SIB5
but not 6 and 7 (I could see all SIB5 6 7 as a singe message in wireshark).
If SIB5 and 6 has a different periodicity then I could decode both of them.
Can you please provide any tweaks in the code to also decode sib6.
On Tue, Sep 13, 2016 at 11:15 AM, Tomcsányi Domonkos <domi at tomcsanyi.net>
> Hi Altaf,
> That’s weird. I’m not sure how this could happen, because SIB3 is usually
> the first element in the schedulingList, meaning it has the same
> periodicity as SIB2 - so in theory there should be no situation where SIB2
> is decoded but SIB3 isn’t, because SIB2 is never included in the
> schedulingList (SIB2’s periodicity is determined by the periodicity of the
> first element in the schedulingList as you probably know). I didn’t write
> the SIB2 decoding part of the code, so I’ll need to have a second look at
> it. Meanwhile you can try to modify i to go from 0 instead of 1 here and
> see if that helps: https://github.com/domi007/srsUE/blob/master/ue/src/
> In my captures SIB3 was always shown as one packet in Wireshark and it was
> decode by Wireshark fine.
> I was wrong to ask about SIB10, because that is implemented in the code
> :). I should have said something not implemented, SIB11 - but I think
> that’s not decodable yet (only if you wrote some openLTE code for it as
> Let me know what you see, also if you could send some PCAP files it would
> be great.
> 2016. szept. 11. dátummal, 16:41 időpontban altaf sk <altaf329 at gmail.com>
> Yes, I was able to decode sib10.
> On commercial nets I could not see sib3 being decoded. rest sib4 5 6 are
> decoded. But sib8 and 10 are not sent usually. No CDMA and sib 10 is for
> With openlte enodeB, I sent sib10 and i see sib10 getting decoded (sib2 3
> and 10 are sent, again sib 3 not decoded).
> However, when I send sib 2 3 4 and 10, i see only 2 and 4 getting
> decoded. Periodicity is 0 for all. something is wrong with periodicity here.
> On Sat, Sep 10, 2016 at 10:00 PM, Tomcsányi, Domonkos <domi at tomcsanyi.net>
>> I'm glad you could make it work.
>> When you say: "I am able to deccde other sibs too" - Do you mean you can
>> decode SIB10 for example? Or just that it works for you for the implemented
>> Others: please send some feedback as Altaf did if it works for you :)
>> *From: *"altaf sk" <altaf329 at gmail.com>
>> *To: *"Tomcsányi, Domonkos" <domi at tomcsanyi.net>
>> *Cc: *"dummys1337" <dummys1337 at gmail.com>, "srslte-users" <
>> srslte-users at lists.softwareradiosystems.com>
>> *Sent: *Saturday, September 10, 2016 9:35:47 PM
>> *Subject: *Re: [srslte-users] Optional SIB decoding
>> It works perfectly on my machine.. I am able to decode other sib's too
>> Sent from my iPhone
>> On 09 Sep 2016, at 12:16, Tomcsányi, Domonkos <domi at tomcsanyi.net> wrote:
>> Hi all,
>> Just pushed this to github:
>> Don't forget to use the latest srsLTE library when compiling because
>> there were some changes in the past 2 weeks (first my code wouldn't compile
>> because of them since I created this a month ago).
>> After you compiled it enable PCAP output in ue.conf and run the ue
>> program as usual. If there are any optional SIBs broadcasted by the network
>> you are connecting to it'll automatically decode all of them.
>> Later you can check them out by opening the pcap file in wireshark.
>> Let me know if you encounter any issues.
>> *From: *dummys1337 at gmail.com
>> *To: *"Tomcsányi Domonkos" <domi at tomcsanyi.net>, "altaf sk" <
>> altaf329 at gmail.com>
>> *Cc: *"srslte-users" <srslte-users at lists.softwareradiosystems.com>
>> *Sent: *Thursday, September 8, 2016 10:03:48 PM
>> *Subject: *Re: [srslte-users] Optional SIB decoding
>> I will be interested in your version as well.
>> Sent from my mobile device
>> On Thu, Sep 8, 2016 at 9:51 PM +0200, "Tomcsányi Domonkos" <
>> domi at tomcsanyi.net> wrote:
>> Hello Altaf,
>>> I have such a version of srsUE (so I haven’t modified the examples of
>>> srsLTE instead I implemented the decoding in srsUE), but I haven’t sent in
>>> a patch or created a pull request yet. It needs more testing, because I saw
>>> some weird issue with it once when trying to decode a commercial tower’s
>>> SIB. Maybe the best would be to publish it and then people can just test it
>>> themselves giving me a lot more test coverage of the code.
>>> I think I’ll upload it to my github repository and I’ll send you and the
>>> list the link tomorrow, or maybe during the weekend.
>>> 2016. szept. 8. dátummal, 16:59 időpontban altaf sk <altaf329 at gmail.com>
>>> Can you please tell if the decoding of SIB3 to SIB8 is available in
>>> On Tue, Aug 16, 2016 at 1:16 PM, Ismael Gomez <
>>> ismael.gomez at softwareradiosystems.com> wrote:
>>>> Hi Domi.
>>>> Good job decoding those SIBs. Regarding the ID offsets, I think that
>>>> adding 1 to the value in the implementation side as you did is better than
>>>> modifying the openLTE headers.
>>>> On Mon, 15 Aug 2016 at 13:51 Tomcsányi, <domi at tomcsanyi.net> wrote:
>>>>> Hi all,
>>>>> I've extended srsUE with the capability of decoding optional System
>>>>> Information Blocks (SIB3-SIB8 and SIB 13 because only these are implemented
>>>>> in openLTE's lte_rrc.h). I'll hopefully be able to push a patch/pull
>>>>> request towards you via GitHub after I'm done with testing it.
>>>>> While doing that I found a strange thing which I think need to be
>>>>> SIB1 contains a list of all optional SIBs in an item called
>>>>> schedulingInfoList. According to the specs SIB2 is not in this list,
>>>>> because by default it needs be transmitted with the same periodicity as
>>>>> Item0 of the list. So let's say Item0 of the schedulingInfoList is SIB3
>>>>> with periodicity 1 - this means SIB2 will be broadcasted with periodicity 1
>>>>> as well. What this means though is that in the schedulingInfoList the
>>>>> sibType enum's first item (essentially the number 0) will be SIB3, not
>>>>> SIB2. This of course is in contrary with the actual SIB2 message in which
>>>>> sibType 0 indicates SIB2.
>>>>> So the problem is that in lte_rrc.h the defined sibType enum defines
>>>>> SIB2 as 0, SIB3 as 1 etc. leading to a false list of SIBs while parsing the
>>>>> schedulingInfoList (the list would be off by one). I was able to catch this
>>>>> thanks to Wireshark which decodes the messages correctly. I solved this
>>>>> from the implementation side by simply adding 1 to the value of the sibType
>>>>> coming from the schedulingInfoList, but maybe it should be solved in an
>>>>> other way. I can imagine two sibType enums for example, one for decoding
>>>>> the schedulingInfoList (starting from SIB3 - 0, SIB4 - 1 etc.) and the
>>>>> other for decoding the actual messages (SIB2 - 0, SIB3 - 1 etc.), although
>>>>> I'm not sure whether or not this would cause unnecessary confusion.
>>>>> I'll probably send a copy of this message to the openLTE mailing list
>>>>> as well, because as far as I can see lte_rrc.h is part of openLTE, right?
>>>>> srslte-users mailing list
>>>>> srslte-users at lists.softwareradiosystems.com
>>>> srslte-users mailing list
>>>> srslte-users at lists.softwareradiosystems.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the srslte-users