<div dir="ltr">Hi,<br><br>> What <Act> values are given in +COPS? for those?<br><div style="font-family:monospace" class="gmail_default">...</div>> I assume you're saying we could have separate MMModemAccessTechnology<br>> values for the COPS <Act> equivalents of numbers 8 (EC-GSM-IoT (A/Gb<br><div>> mode)) and 9 (E-UTRAN (NB-S1)) at least?</div><br>Latest 3GPP TS 27.007 version 17.5.0  "+COPS" command describes "access technology selected" as<br>0 GSM<br>1 GSM Compact<br>2 UTRAN<br>3 GSM w/EGPRS (see NOTE 1)<br>4 UTRAN w/HSDPA (see NOTE 2)<br>5 UTRAN w/HSUPA (see NOTE 2)<br>6 UTRAN w/HSDPA and HSUPA<br>7 E-UTRAN<br>8 EC-GSM-IoT (A/Gb mode)<br>9 E-UTRAN (NB-S1 mode)<br>10 E-UTRA connected to a 5GCN<br>11 NR connected to a 5GCN<br>12 NG-RAN<br>13 E-UTRA-NR dual connectivity<br><br>A few vendors use #7 as eMTC (Cat-M), while others use #8. All <span class="gmail_default" style="font-family:monospace"></span>modems<span class="gmail_default" style="font-family:monospace"> </span><span class="gmail_default" style="font-family:monospace"></span>I know<span class="gmail_default" style="font-family:monospace"> </span>use #9 for E-UTRAN (NB-S1 mode) <span class="gmail_default" style="font-family:monospace"></span>which is<span class="gmail_default" style="font-family:monospace"> </span>LTE<span class="gmail_default" style="font-family:monospace"> </span>Cat-NB or NB IoT.<br>"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.<br><div></div><div><br></div>Related to this, in addition to RAT preference (like GSM vs LTE), there is a need for yet an additional preference between LPWA technologies.<br>Modem could be configured to connect to either Cat-M or Cat-NB, or both with preference of one these<span class="gmail_default" style="font-family:monospace">:</span><br> 0 CAT-M1<br> 1 NB-IoT<br> 2 CAT-M1 (preferred) and NB-IoT<br> 3 CAT-M1 and NB-IoT (preferred)<br><div><span class="gmail_default" style="font-family:monospace"></span></div><div>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.<span class="gmail_default" style="font-family:monospace"><br></span></div><div><span class="gmail_default" style="font-family:monospace"><br></span></div><div><span class="gmail_default" style="font-family:monospace"></span></div>> <span class="gmail_default" style="font-family:monospace"><span class="gmail_default" style="font-family:monospace"></span>Which </span>list of new AcTs would you add? Could you include in this discussion<br><div>> the actual list of values given by the 3GPP specs?</div><div></div><div><span class="gmail_default" style="font-family:monospace"></span></div><div>A bit different angle on RAT types is provided in<span class="gmail_default" style="font-family:monospace"></span><span style="font-family:arial,sans-serif"><span class="gmail_default" style="font-family:monospace"> </span>3GPP TS 29.274<span class="gmail_default" style="font-family:monospace"> <span style="font-family:arial,sans-serif">v16.5.0</span></span><span class="gmail_default" style="font-family:monospace">.</span></span></div><div>See<span style="font-family:arial,sans-serif"> </span><span class="gmail_default" style="font-family:monospace"><span style="font-family:arial,sans-serif">"Table 8.17-1: RAT Type values":</span></span></div>1    UTRAN<br>2    GERAN<br>3    WLAN<br>4    GAN<br>5    HSPA Evolution<br>6    EUTRAN (WB-E-UTRAN)<br>7    Virtual<br>8    EUTRAN-NB-IoT<br>9    LTE-M<br><div>10  NR</div><div><div class="gmail_default"><span style="font-family:arial,sans-serif">11-255 <span class="gmail_default"><spare></span></span></div></div><div><br></div><div></div>> > #2 Related to topic above, currently LPWA modem identified as HSPA<br>> > (3G), however in reality 3G is not supported. Changing the way how RAT<br>> > is identified, would most likely ruin support for old modems in<br>> > plugin. Maybe some folks already faced a problem with command<br>> > incompatibility among  different modems in the same plugin.<br>> > - What approach would be preferable in solving AT command collision problem?<br>> ><br>> Can you describe with detail which is the actual collision? Is the<br><div>> modem reporting a 3G AcT?</div><div><br></div>For example, function cnmp_query_ready() in plugins/simtech/mm-broadband-modem-simtech.c<br>In automatic mode (+CNMP=0) MM_MODEM_MODE_* defined by result of +CNAOP kept in ctx->acqord.<br>SIM70x0 modems do not support such a command and mode should be:<br>(MM_MODEM_MODE_2G | MM_MODEM_MODE_4G);<br><div>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.<span class="gmail_default" style="font-family:monospace"> </span>Open for suggestion on such a<span class="gmail_default" style="font-family:monospace"> </span>topic.</div><div><br></div>> > #3 related to above. Approx 10 years ago <span class="gmail_default" style="font-family:monospace"></span>AT*CNTI was introduced to<br>> > check access tech in a generic code. it is a proprietary command not<br>> > supported by a many modems.<br>> > - Could it be moved to relevant plugins only? (especially in the light<br>> > of 3G sunset)<br>> ><br><div>> Not sure I understand what your suggestion is. </div><div><br></div><div><div style="font-family:monospace" class="gmail_default"><span style="font-family:arial,sans-serif">Since AT*CNTI is a proprietary command, should it be moved to relevant plugins from a generic code?</span><br></div><br></div><div style="font-family:monospace" class="gmail_default">Regards,</div><div style="font-family:monospace" class="gmail_default">Alexey</div><br><br></div>