ModemManager RAT definitions, etc.

[Alexey Orishko]

Hi,

> What <Act> values are given in +COPS? for those?
...
> I assume you're saying we could have separate MMModemAccessTechnology
> values for the COPS <Act> equivalents of numbers 8 (EC-GSM-IoT (A/Gb
> mode)) and 9 (E-UTRAN (NB-S1)) at least?

Latest 3GPP TS 27.007 version 17.5.0  "+COPS" command describes "access
technology selected" as
0 GSM
1 GSM Compact
2 UTRAN
3 GSM w/EGPRS (see NOTE 1)
4 UTRAN w/HSDPA (see NOTE 2)
5 UTRAN w/HSUPA (see NOTE 2)
6 UTRAN w/HSDPA and HSUPA
7 E-UTRAN
8 EC-GSM-IoT (A/Gb mode)
9 E-UTRAN (NB-S1 mode)
10 E-UTRA connected to a 5GCN
11 NR connected to a 5GCN
12 NG-RAN
13 E-UTRA-NR dual connectivity

A few vendors use #7 as eMTC (Cat-M), while others use #8. All modems
I know use
#9 for E-UTRAN (NB-S1 mode) which is LTE Cat-NB or NB IoT.
"Cat-M" tag could possibly be determined by additional probing in
corresponding plugin. For example, some modems explicitly return a string
"eMTC service cell" while querying NW info.

Related to this, in addition to RAT preference (like GSM vs LTE), there is
a need for yet an additional preference between LPWA technologies.
Modem could be configured to connect to either Cat-M or Cat-NB, or both
with preference of one these:
 0 CAT-M1
 1 NB-IoT
 2 CAT-M1 (preferred) and NB-IoT
 3 CAT-M1 and NB-IoT (preferred)
For example, it could be a global LPWA enum definition, where Cat-M would
be related to 27.007 #7 and Cat-NB to #9 (mapped in a helper function).
Modems with different Cat-M number in +COPS response could redefine a
mapping in its plugin.

> Which list of new AcTs would you add? Could you include in this discussion
> the actual list of values given by the 3GPP specs?
A bit different angle on RAT types is provided in 3GPP TS 29.274 v16.5.0.
See "Table 8.17-1: RAT Type values":
1    UTRAN
2    GERAN
3    WLAN
4    GAN
5    HSPA Evolution
6    EUTRAN (WB-E-UTRAN)
7    Virtual
8    EUTRAN-NB-IoT
9    LTE-M
10  NR
11-255 <spare>

> > #2 Related to topic above, currently LPWA modem identified as HSPA
> > (3G), however in reality 3G is not supported. Changing the way how RAT
> > is identified, would most likely ruin support for old modems in
> > plugin. Maybe some folks already faced a problem with command
> > incompatibility among  different modems in the same plugin.
> > - What approach would be preferable in solving AT command collision
problem?
> >
> Can you describe with detail which is the actual collision? Is the
> modem reporting a 3G AcT?

For example, function cnmp_query_ready() in
plugins/simtech/mm-broadband-modem-simtech.c
In automatic mode (+CNMP=0) MM_MODEM_MODE_* defined by result of +CNAOP
kept in ctx->acqord.
SIM70x0 modems do not support such a command and mode should be:
(MM_MODEM_MODE_2G | MM_MODEM_MODE_4G);
So even for the same vendor, there are modems with quite a different AT
command set and updating a legacy code is just a challenge. I don't have
access to old modems and can't check if something broken after changes. Open
for suggestion on such a topic.

> > #3 related to above. Approx 10 years ago AT*CNTI was introduced to
> > check access tech in a generic code. it is a proprietary command not
> > supported by a many modems.
> > - Could it be moved to relevant plugins only? (especially in the light
> > of 3G sunset)
> >
> Not sure I understand what your suggestion is.

Since AT*CNTI is a proprietary command, should it be moved to relevant
plugins from a generic code?

Regards,
Alexey
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/modemmanager-devel/attachments/20220722/5951280a/attachment.htm>