Telit CE910D OMA-DM issues and cert testing using ModemManager

[Rowan Hamilton]

On Tue, Sep 19, 2017 at 11:12 AM Aleksander Morgado <
aleksander at aleksander.es> wrote:

> 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
> https://aleksander.es



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?

> <https://aleksander.es>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/modemmanager-devel/attachments/20170919/e7b7efff/attachment.html>