Telit CE910D OMA-DM issues and cert testing using ModemManager

[Rowan Hamilton]

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.




Failed Test results for Sprint OMA-DM Testing using ModemManager:

HFA Retry: HFA retries seem to be working but the device is making a
cellular connection with the device when not active.
So the device gets an IP but it’s to the provisioning server not Sprint
public internet network and that never dies off.
Expected Result: HFA Retries should start. There should be only 5 retry
attempts during activation then it should stop. There should be 60 seconds
between retries.

NI PRL - Native State: Device seems to ignore network initiated updates
while in production mode.
Expected Result: The NI PRL should successfully complete, such that the
device loads/uses the new PRL and successfully updates its PRL version.

NI DC - Native State: Device seems to ignore network initiated updates
while in production mode.
Expected Result: The NI DC should generate and successfully complete all
related requests on the OMA server.

NI FUMO - Native State: Device seems to ignore network initiated updates
while in production mode.
Expected Result: The NI FUMO should successfully complete, such that the
device updates itself using the new firmware and successfully updates its
firmware version.

NI PRL - 8k: Device seems to ignore network initiated updates while in
production mode.
Expected Result: The NI PRL should successfully complete, such that the
device loads/uses the new PRL and successfully updates its PRL version.

NI PRL - Over 8k: Device seems to ignore network initiated updates while in
production mode.
Expected Result: The NI PRL should successfully complete, such that the
device loads/uses the new PRL and successfully updates its PRL version.

NI PRL - 16k (OMA-DM Specification version 2.1 or higher): Device seems to
ignore network initiated updates while in production mode.
Expected Result: The NI "Test 16k 1xRTT PRL for Device Certification" or
"Test 16k EVDO PRL for Device Certification" PRL should complete, validate
on the device. Also validate on OMA server by making sure that all
transactions have been completed successfully.

NI PRL - While connected in Active Data Session: Unable to determine if the
device is actively pushing data through a data session, device seems to
ignore network initiated updates while in production mode.
Expected Result: The NI PRL should successfully complete after the initial
data session goes dormant, such that the device loads/uses the new PRL and
successfully updates its PRL version.

NI PRL - Device in Dormant State/Sleep for 60 min: Device seems to ignore
network initiated updates while in production mode.
Expected Results: The NI PRL should successfully complete, such that the
device loads/uses the new PRL and successfully updates its PRL version.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/modemmanager-devel/attachments/20170919/76f3187f/attachment.html>