5G NR support

[Bjørn Mork]

Reinhard Speyerer <rspmn at arcor.de> writes:

>         Custom Data Class: 5G UWB
>
> It would be interesting to see whether this is also set for 5G-NSA networks
> or whether other means (e.g. AT+COPS? <AcT> = 13) have to be used there
> to identify them. As can be seen from
> https://forums.quectel.com/t/rg500q-gl-no-nr-or-5g-supported/3521/8
> QMI NASGetServingSystem only reports RAT LTE for 5G-NSA networks.

Thanks a lot for the very useful example.

IMHO it would be very confusing if device capabilities depended on the
selected network. So I hope it doesn't.  But I know these 5G device are
going to be confusing me...

I see that the device also sets one bit here in addition to the custom
class:

            .... .... .... .... 0000 0000 01.. .... = Reserved for future GSM classes: Supported


Microsoft defines two new classes using these bits in
"MBIM_CID_MS_DEVICE_CAPS_V2":

 MBIMDataClass5G_NSA 	40h
 MBIMDataClass5G_SA 	80h


So it looks like this device claims 5G_NSA support, but not 5G_SA.
That's not a good sign.

> Please refer to the attached .pcap for the MBIM device services
> (Wireshark: Edit -> Preferences -> Protocols -> DLT_USER: Decode User DLT 5
> as mbim.control).


My Wireshark doesn't know the newer Microsoft CIDs, but I see that the
device supports CID 15, which is "MBIM_CID_VERSION":
        
        Device Service Element #14
            Device Service Id: UUID_BASIC_CONNECT_EXTENSIONS (3d01dcc5-fef5-4d05-0d3a-bef7058e9aaf)
            DSS Payload: 0x00000000
                .... .... .... .... .... .... .... ...0 = Host To Device: Not supported
                .... .... .... .... .... .... .... ..0. = Device To Host: Not supported
            Max DSS Instances: 0
            CID Count: 13
            CID: MS_PROVISIONED_CONTEXT_V2 (1)
            CID: MS_LTE_ATTACH_CONFIG (3)
            CID: MS_LTE_ATTACH_STATUS (4)
            CID: MS_SYS_CAPS (5)
            CID: MS_DEVICE_CAPS_V2 (6)
            CID: MS_DEVICE_SLOT_MAPPINGS (7)
            CID: MS_SLOT_INFO_STATUS (8)
            CID: MBIM_CID_PCO (9)
            CID: MS_DEVICE_RESET (10)
            CID: MBIM_CID_BASE_STATIONS_INFO (11)
            CID: MBIM_CID_LOCATION_INFO_STATUS (12)
            CID: Unknown (14)
            CID: Unknown (15)



I guess that means that the behaviour of MBIM_CID_REGISTER_STATE,
MBIM_CID_PACKET_SERVICE and MBIM_CID_SIGNAL_STATE changes when the host
has MBIMEx version 2.0 support.  It would be nice if libmbim supported
that.

Someone with hardware should probably look into this...


Bjørn