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
