Uplink bit is not set fot LTE RRC packets (qualcomm parser)

[rtommy]

SUMMARY
For LTE RRC packets the qualcomm diagltelogparser does not consider setting Uplink/Downlink bit.

STEPS TO REPRODUCE
Every SCAT execution with diagltelogparser.

EXPECTED and ACTUAL RESULT
The Uplink/Downlink bit should be properly set in diagltelogparser for LTE RRC packets.

ENVIRONMENT

• OS: Windows
• SCAT version: 1.3.0
• Python version: 3.12
• Cellular device: Galaxy S22 (SM-S901U)
• Baseband type: Qualcomm
• DIAG method: USB or serial

ADDITIONAL INFORMATION
Solution is straight forward, Pull request will be created for this to help.

in parse_lte_rrc()

        uplink = gsmtap_subtype in (
            util.gsmtap_lte_rrc_types.UL_CCCH,
            util.gsmtap_lte_rrc_types.UL_DCCH,
            util.gsmtap_lte_rrc_types.UL_CCCH_NB,
            util.gsmtap_lte_rrc_types.UL_DCCH_NB,
        )

        arfcn = (int(uplink) << 14) + item.earfcn

        gsmtap_hdr = util.create_gsmtap_header(
            version = 2,
            payload_type = util.gsmtap_type.LTE_RRC,
            arfcn = earfcn,
            frame_number = sfn,
            sub_type = gsmtap_subtype,
            sub_slot = subfn,
            device_sec = ts_sec,
            device_usec = ts_usec)

[peremen]

Thanks for the comment. I am aware of this limitations quite long ago, but GSMTAPv2's limitation really hits in this case. For 2G and 3G, 14 bits of ARFCN field is enough to encode the whole range of (U)ARFCNs being used. For 4G, the current design is somewhat inadequate: for FDD-LTE bands up to 32 DL EARFCNs fit into 14 bits of integer but there are other problems.

• When a cell has different DL/UL uplink bandwidth then EARFCN's are not simply calculatable by adding/subtracting 18000.
• For TDD-LTE the EARFCN already crosses 36000, which is smaller than what 14 bits of integer can store.
• LTE band 65 and above has EARFCNs bigger than 65535, which GSMTAPv2 allocates for the EARFCN when ignoring Uplink and PCS band indicator.

The upcoming GSMTAPv3 will address this use case.

[rtommy]

I appreciate the detailed explanation. I'm not a deep expert in RAN (Radio Access Network) and I made my assumptions based on Wireshark interpretation and source code.

Do you know a when GSMTAPv3 might be released?

According to this osmocom git you had the last commit 6 months ago...