<div> <div class="gmail_quote"><div dir="auto">On Tue, Sep 19, 2017 at 11:12 AM Aleksander Morgado <<a href="mailto:aleksander@aleksander.es">aleksander@aleksander.es</a>> wrote: </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hey Rowan, > I feel like this information is good for the community to have. I have used > ModemManager in our project up until this point, where we are faced with a > challenge of OMA-DM (Open Mobile Alliance [OMA] Device Management [DM]). > Some background: Each time you want to put a product on a carrier you have > to do some testing, to make sure it works the exact way they want and that > no unintended behaviors are present. Currently we are using a Telit CE910-D > CDMA with the Telit plugin module for ModemManager, > I do not believe that there is any OMA-DM support for this Modem directly in > ModemManager. I do see that some other modems do support this though and I > am curious as to how go about adding support for this. I think it important > to share these failure > points with OMA-DM and ModemManager and how it pertains to our particular > setup. > > mmcli: v1.4.0 > > Additional Info: > OMA-DM (Open Mobile Alliance [OMA] Device Management [DM]) is used for most > of Sprint over the air provisioning, with the exception of SIM OTA. > The OMA-DM platform for 3G only devices like the CE/DE910 consists of Device > Configuration (DC includes PTN, MSID, NAI and many other provisioning data > points), > Preferred Roaming List (PRL is continuously updated to provide better > coverage), and Firmware Update Management Object (FUMO is over the air modem > firmware update, similar to Firmware Over the Air[FOTA]). > > The majority of Sprint’s M2M OMA-DM test plan is designed to test the > ability to receive provisioning updates while the device is in customers > hands, > these updates are known as Network Initiated(NI). The current 8 issues that > we have with the device are all related this and all seem to point to the > modem manager interrupting the modems ability to perform these updates. > > To test this requires the device to be in a powered up in “production” mode. > The unit is left in an idle condition for the entire tests. From the OMA-DM > server. > The handling of these updates above is handled in the lab as follows. The > tester logs into the OMA-DM server and clicks “PSE Roaming Update” (for this > example we will use PRL) button. > The OMA-DM server starts the update process by sending an alert to Sprint > Short Message Service Center (SMSC) for processing. The SMSC sends WAP > message, which is a hidden SMS for the OMA-DM device client, > it is coded as a 1226 alert. This message includes instructions for the > devices OMA-DM client to reach out the Sprint OMA-DM server. The update are > queued up would last for 24 hours in production and 1 hour in the lab, > however it is an unstated rule that in the lab if it has not done its update > within 15 minutes it more than likely would not complete. > This is where we saw that your device is not responding within this window. > This testing would continue following Sprint test cases that are outlined > which would include a total of 6 – PRL updates, 1 – DC, and 1 – FUMO update. > ModemManager supports OMA-DM for QMI modems. The support we give is an API so that upper layers can manage the OMA-DM process (e.g. reporting when a Network Initiated OMA-DM session is started, or things like that). Other than that, ModemManager is really transparent to the whole OMA-DM process. Have you seen these issues with the same module in another OS, like Windows? I'm tempted to say that ModemManager has nothing to do with this issues, and that they should be transparently be managed and processed by the Telit firmware itself. -- Aleksander <a href="https://aleksander.es" rel="noreferrer" target="_blank">https://aleksander.es</a></blockquote><div dir="auto"> </div><div dir="auto"> </div><div dir="auto">Interesting, in the testing lab they noticed that they only saw this being a problem when ModemManager was running. But if your telling me that it’s related to the modules firmware... Can you think of anything in Modem Manager that could be conflicting with the carrier messages going to the module? </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><a href="https://aleksander.es" rel="noreferrer" target="_blank"></a> </blockquote></div></div>