In UMTS I can decode single sibs from scanner using Tshark and a protocol specifier like rrc.si.sib7. It looks like there aren't simular protocol specifiers for lte. I can wrap the data in a BCCH-DL-SCH message but this is error-prone because you have to create the right PER bits. Did I miss an option in tshark to decode these lte sibs or would it make sense to write a feature request? cu
Hi, this was required for UMTS as SIBs can be fragmented, which is not the case for LTE. I would prefer if we could avoid unnecessary new dissectors in lte-rrc family, as there is plenty of them already.
You are right there are plenty of dissectors in the lte-rrc but most of them are top level so they are not embedded in other dissectors. To reach them a dissector is needed. This is not the case for SystemInformation. But scanners quite often just deliver data of single SIBs together with an identifier about the sib type.
I 'm not familiar with the wireshark code but I would expect you need a small wrapper dissect_ funtion for each existing sib dissector and the registration function (i would expect this code could be generated from the asn.1 by providing some additional info to the asn.1 code generator, but no idea about this part of the code).
If the amount is a problem (and we are talking about around 40 additional dissectors (25 LTE and 15 NBIoT)) then I would ask you to think about to split the lte-rrc ...
Given that NB-IoT depends on definitions from EUTRA, splitting the file would make things more complex / painful to maintain, so for sure I will not make such change. So far I have never seen any tool dumping the SIBs and not the BCCH DL-SCH PDU instead (and I have practiced quite a lot). Which device / equipment does this? Could you share more information?
A little bit. I.e Rohde&Schwarz Scanners together with ROMES..Just recently I got files with scanner frames containing NBIoT SIBs. It is the same for 5GNR scanner data (but the specs just define MIB and SIB1 in the moment, we have to wait for the results of RAN#81). By the way the nr-rrc uses a pre release spec, which is no longer valid. Wireshark 2.6.3). There are also Mobile chipsets providing single SIBs in some state. You could know them.
You are right that nbiot-rrc imports some basic eutra-rrc definitions but not because there is a real link to lte. But as I said I have no idea how your asn.1 code generator works. For me it would be a logical cut. More a design question than in any way an important issue. LTE-M is part of E-UTRA but NBIoT is different on Layer3 level ...
For NR, please use the master branch (2.9 development tree) that is compliant with all the June R15 specifications (it will never make into the 2.6.x releases that are bugfixes only). I really wonder why those equipments extract the SIBs, it makes no sense. I will think about it but not convinced to do such a change (while the bits for DL-SCH encapsulation can be added externally or within a plug-in).
Sure (as I said in the beginning) I can wrap the SIBs but then after decoding I have to remove the top of the tree. The reason for separating the SIBs may be that filtering is easier for a specific sib in post processing. BCCH-DL-SCH is just a container for multiple sibs and doesn't carry additional information. If NR is not maintained in 2.6 then the nr-rrc dissector should be removed. Thanks for your time.
Asked: 2018-09-11 13:56:58 +0000
Seen: 1,548 times
Last updated: Sep 13 '18
