[srslte-users] Optional SIB decoding

Tue Sep 13 09:15:49 UTC 2016

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/upper/rrc.cc#L264

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 well).

Let me know what you see, also if you could send some PCAP files it would be great.

Cheers,
Domi

> 2016. szept. 11. dátummal, 16:41 időpontban altaf sk <altaf329 at gmail.com> írta:
> 
> Hi,
> 
> 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 warning.
> 
> 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.
> 
> Regards,
> ALT
> 
> On Sat, Sep 10, 2016 at 10:00 PM, Tomcsányi, Domonkos <domi at tomcsanyi.net <mailto:domi at tomcsanyi.net>> wrote:
> 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 SIBs?
> 
> Others: please send some feedback as Altaf did if it works for you :)
> 
> Cheers,
> Domi
> 
> From: "altaf sk" <altaf329 at gmail.com <mailto:altaf329 at gmail.com>>
> To: "Tomcsányi, Domonkos" <domi at tomcsanyi.net <mailto:domi at tomcsanyi.net>>
> Cc: "dummys1337" <dummys1337 at gmail.com <mailto:dummys1337 at gmail.com>>, "srslte-users" <srslte-users at lists.softwareradiosystems.com <mailto:srslte-users at lists.softwareradiosystems.com>>
> Sent: Saturday, September 10, 2016 9:35:47 PM
> 
> Subject: Re: [srslte-users] Optional SIB decoding
> Great.!
> It works perfectly on my machine.. I am able to decode other sib's too
> 
> Thanks
> 
> Sent from my iPhone
> 
> On 09 Sep 2016, at 12:16, Tomcsányi, Domonkos <domi at tomcsanyi.net <mailto:domi at tomcsanyi.net>> wrote:
> 
> Hi all,
> 
> Just pushed this to github:
> https://github.com/domi007/srsUE <https://github.com/domi007/srsUE>
> 
> 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.
> 
> Cheers,
> Domi
> 
> From: dummys1337 at gmail.com <mailto:dummys1337 at gmail.com>
> To: "Tomcsányi Domonkos" <domi at tomcsanyi.net <mailto:domi at tomcsanyi.net>>, "altaf sk" <altaf329 at gmail.com <mailto:altaf329 at gmail.com>>
> Cc: "srslte-users" <srslte-users at lists.softwareradiosystems.com <mailto:srslte-users at lists.softwareradiosystems.com>>
> Sent: Thursday, September 8, 2016 10:03:48 PM
> Subject: Re: [srslte-users] Optional SIB decoding
> Hi, 
> I will be interested in your version as well. 
> thanks. 
> Cheers, 
> Jon
> 
> Sent from my mobile device
> 
> 
> 
> On Thu, Sep 8, 2016 at 9:51 PM +0200, "Tomcsányi Domonkos" <domi at tomcsanyi.net <mailto: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.
> 
> Cheers,
> Domi
> 
> 
> 2016. szept. 8. dátummal, 16:59 időpontban altaf sk <altaf329 at gmail.com <mailto:altaf329 at gmail.com>> írta:
> 
> Can you please tell if the decoding of SIB3 to SIB8 is available in srslte.
> 
> regards,
> Altaf 
> 
> 
> On Tue, Aug 16, 2016 at 1:16 PM, Ismael Gomez <ismael.gomez at softwareradiosystems.com <mailto: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. 
> 
> cheers, 
> Ismael
> 
> On Mon, 15 Aug 2016 at 13:51 Tomcsányi, <domi at tomcsanyi.net <mailto: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 mentioned:
> 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?
> 
> Cheers,
> Domi
> _______________________________________________
> srslte-users mailing list
> srslte-users at lists.softwareradiosystems.com <mailto:srslte-users at lists.softwareradiosystems.com>
> http://www.softwareradiosystems.com/mailman/listinfo/srslte-users <http://www.softwareradiosystems.com/mailman/listinfo/srslte-users>
> 
> _______________________________________________
> srslte-users mailing list
> srslte-users at lists.softwareradiosystems.com <mailto:srslte-users at lists.softwareradiosystems.com>
> http://www.softwareradiosystems.com/mailman/listinfo/srslte-users <http://www.softwareradiosystems.com/mailman/listinfo/srslte-users>
> 
> 
> 
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.srsran.com/pipermail/srsran-users/attachments/20160913/b25cee56/attachment.htm>