Qualcomm 5G NR Support

[dylangerdaly]

Hi,

What's required to port 5G NR Parsing Support from QXDM?

Would like to add 5G NR NSA/SA modes to this, I'm not sure if gsmtap even supports 5G NR yet.

[peremen]

There are three major issues:

• Enabling 5G NR RRC/NAS/ML1/... information during DIAG initialization. init_diag function of qualcommparser.py needs to be updated. I am aware of item IDs, but don't know how to activate them yet.
• Parser of the said items. This should be implemented as diagnrlogparser.py in parsers/qualcomm directory. As long as DIAG items are known then it could be implemented rather easily.
• GSMTAP. Currently GSMTAP do not support 5G NR RRC/NAS. Although I can use some private constants for those until 5G NR is implemented within RRC, but this would be just a jugaad fix in current GSMTAP v2 header structure (too narrow bits for ARFCN - already a problem in LTE too, lack of 3/4/5G specific radio parameters, etc.). I will propose GSMTAP v3 in regard of that. See also: http://lists.osmocom.org/pipermail/openbsc/2017-November/011493.html

[handymenny]

An interesting thing is that on devices that have 855 + x50 there are two diag interfaces, the first one used for the x24 modem (4G/3G/2G) and the second one for the x50 modem, while those with 855 + x55 still have two diag interfaces but only that of the x55 modem is used for "mobile networks"

[dylangerdaly]

This will be a little more difficult, I think they've gated 5G Parsing from QXDM.

GSMTAP should get some love soon with SDR gNodeB's slowly becoming a thing, hopefully anyway

An interesting thing is that on devices that have 855 + x50 there are two diag interfaces

Are you sure? I have diag on an SDM855 and it's only enumerating one diag interface.

[handymenny]

Are you sure? I have diag on an SDM855 and it's only enumerating one diag interface.

The second diag is diag_mdm, as you can see from the screen below. In fact if you use the internal logkit (available at least on Oneplus/Oppo/Realme, Xiaomi, LG and HMD), two qmdl logs are saved, one from the x24 modem, the other from the x50 (or x55) modem.

[dylangerdaly]

Huh, that's cool, I'll give that a go, thank you.

I'd guess NV Commands write to the same modemst? Or do these modems have separate NV?

[handymenny]

I don't know much about modemst, but the two modems have separate EFS (accessible with QPST). Another particular thing is that the "5G" qmdl has many DIAG_TS_F (0x1D) messages, I guess they are used to synchronize the qmdl logs

[peremen]

Hm, that's interesting. Back in the earlier Qualcomm LTE days, some configuration (Galaxy S4 LTE GT-I9505) also showed 2 DIAG ports, one for MSM and another for dedicated MDM (but only MDM was relevant). Running two separate SCAT instances for each two interfaces should not be a problem though, but reading simultaneously from two USB interfaces is currently not supported (and will be much more tricky to implement).

This will be a little more difficult, I think they've gated 5G Parsing from QXDM.

Hope that they didn't encrypted the DIAG log packet itself. If that is the case then we are screwed up.

[dylangerdaly]

When I say gated I mean they don't give you the 5G Parsing Libs when you install, I don't think they've encrypted anything.

The specific networks I have access to here in Australia is 5G NR NSA, so it's using LTE's Control Plane, so parsing both would be desirable.

ViewSB will be helpful with decoding, I've used usbmon with Wireshark previously.

Interesting they've totally separated the Modems, I'd like to understand the reasoning behind this, perhaps the Hexagon Cores are clocked differently? Or maybe 5G requires it's own core.

[handymenny]

When I say gated I mean they don't give you the 5G Parsing Libs when you install, I don't think they've encrypted anything.

It is the same with QCAT. However, other professional tools can decode NR, so I don't think they have encrypted anything

Interesting they've totally separated the Modems, I'd like to understand the reasoning behind this, perhaps the Hexagon Cores are clocked differently? Or maybe 5G requires it's own core.

simply some soc (855, 865) have an external 5G modem, others have an integrated 5G modem (752). The problem arises only with the 855 + x50, which show 4G and 5G on separate interfaces. Running two instances of scat might be a nice solution

[peremen]

Returning back to this problem, now 5G SA is being deployed in some parts of the world and I need to also cover this use case. I can continue using my hackish GSMTAPv3 implementation, or propose a proper GSMTAPv3 also containing 5G NR. I think the latter is future-proof way, but also have to consider how it is used currently in libosmocore. Argh.

[p1-mmr]

@peremen Hello,

I am the author of QCSuper. I would like to know whether you have reached Osmocom about updating GSMTAP in order to include support for NR since your last message, and if yes, which was the outcome?

Thank you!

[peremen]

@p1-mmr Well, I consider it is in hiatus as I was not able to see the NR RRC messages by myself. I have mentioned GSMTAPv3 4 years ago but then it went to oblivion: http://lists.osmocom.org/pipermail/openbsc/2017-November/011493.html

I think, as current GSMTAP headers are not suitable for storing enough NR metadata (NARFCN is more than 16 bits afaik, also band indicator is required) so I was thinking proposing GSMTAPv3 with TLV structure for header extension (similar to what Harald suggested there) but never made a proposal. As soon as me or someone else comes with GSMTAPv3, I am happy to continue this work.

[p1-mmr]

Hello,

Thank you for your answer. Regarding the availability of samples of NR RRC OTA messages, I have sent a message about this on the Keybase messaging app (not sure if you're using it).

Regards

[peremen]

Acked.

Regarding the NR-RRC/5GS-NAS support, I will revive and polish my GSMTAPv3 proposal from 2017 and try to publish it soon-ish.

[domi007]

Hi All,

I'm trying to bring this topic out of its hiatus, I hope you don't mind. As posted here https://github.com/P1sec/QCSuper/issues/53#issuecomment-875365743 it is possible to have Wireshark decode the actual messages, however that would still yield a bit limited output, e.g. missing frequency information. Me personally would be more than happy with just the content of the messages, however I do understand that you might wish to implement this properly, e.g. via GSMTAP v3. Is there any way one could help you finishing the proposal and trying to push it towards Osmocom guys?

Thanks.

[valentfr]

Hello,

I would like to ask if there are some positive news about NR-RRC/NAS-5GS message support?

Regards

[peremen]

Currently, 5G RRC/NAS message itself could be decoded, but unfortunately the required GSMTAP extension is yet to be implemented. I did not continued the discussion in the openbsc mailing list for my internal reasons back then. Technically I can "hack" GSMTAP by using reserved payload types, but due to the limitation of GSMTAP itself, it cannot reliably store metadata including LTE EARFCN/5G NR-ARFCN, PCI, band indicator. The 5G feature will come after the needed GSMTAP extension is implemented.

Other implementations such as srsRAN/OAI is not affected as they are sending LTE/NR MAC PDUs containing RRC/NAS PDU, which is lower layer and I am not going to hack into that direction.

[valentfr]

Dear Sir,

Thank you for detailed feedback. Is there any roadmap(with timeline) for GSMTAP extension delivery?

Regards.

[peremen]

"When I have enough resource", I would say in this moment. The matter is rather organizatorial than technical.

[valentfr]

"When I have enough resource", I would say in this moment. The matter is rather organizatorial than technical.

Hi Mr. Park, trying to reach you via LinkedIn. Could you please check or leave any contact to continue in our discussion. Thank you.

[Ali-Shbeeb]

Hi,

Why should you wait for GSMTAP to be more mature? Why not changing the entire logic and moving to Wireshark "Exported PDU" by changing the encapsulation type of PCAP file like this:

Regards

[peremen]

I know about User DLTs, but that is not possible when you want to read the data real-time as that is not an IP packet, and may collide with other applications using user DLTs for their own purpose. Also that method will not carry any useful metadata, e.g. NR-ARFCN and PCI.

[laf0rge]

I would very much appreciate any re-vamped discussion about a GSMTAP v3. Once we have agreement on the format, I'm happy to write + submit the wireshark dissector.

[domi007]

I'd vote to do something flexible, similar to what 3GPP ASN.1 specs do, meaning adding optional extensions always, which maintains backward compatibility while also allowing just adding new features without a brand new version. I'd even consider writing it in ASN.1, since we are mostly telco people, but that might be off-putting for newbies...or not, IDK

[shark-fi]

I know there's issues with wireshark that are harder to solve as stated above. That said, how difficult would it be to edit the diagnrlogparser.py parser to just output at least some of the 5G information to the terminal like the current diagltelogparser.py does? That would give us at least some insight into the 5G traffic. This may be a stop gap and less of a lift than building the wireshark side.

[Ali-Shbeeb]

I know about User DLTs, but that is not possible when you want to read the data real-time as that is not an IP packet, and may collide with other applications using user DLTs for their own purpose. Also that method will not carry any useful metadata, e.g. NR-ARFCN and PCI.

I'm proposing to change the encapsulation type of the pcap into "Encapsulation type: Wireshark Upper PDU export (155)", so no DLT settings will be modified and there will be no DLT collision. This still needs to specify a DLT formatted dissector in the tag field of the "Exported PDU" header .. but after all DLT settings are not gonna be changed.

When it comes to metadata, I think they are less important that the real L3 signalling. They can be printed in the terminal or displayed on a Gui maybe. Dependency on GSMTAP v3 means delays. Using GSMTAP v2 now in LTE is inaccurate too:

[NeutrinoLiu]

Fantastic clean work, especially considering mobileinsight has been out of maintenance for a while. Just like @cartster has mentioned, before we solve the problem of GSMTAP packaging, will it be a better idea that temporarily we directly output the 5G packet decode result in the format of XML/JSON to a specific file path.

[peremen]

Please test release 1.1.0, which will print out NR RRC/NAS packets to stdout in this moment. As soon as GSMTAP v3 is ready I will switch to that.

[Rashed97]

@peremen Do you have information or links to any current discussions around GSMTAP v3? The organizations I work with have significant sway and would be able to push to have this implemented. Please feel free to reach out over if you’d like to discuss more.