[srslte-users] Optional SIB decoding

[Tomcsányi Domonkos]

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> í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/20160908/98079fac/attachment.htm>