<div><div class="gmail_quote"><div><span style="font-family:Calibri;font-size:11pt">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]).</span><br></div><div><font face="Calibri" size="2"><span style="font-size:11pt">
<div>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,</div>
<div>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</div>
<div>points with OMA-DM and ModemManager and how it pertains to our particular setup.</div>
<div> </div>
<div> mmcli: v1.4.0</div><div dir="auto"><br></div>
<div>Additional Info:</div>
<div>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. </div>
<div>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), </div>
<div>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]). </div>
<div> </div>
<div>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, </div>
<div>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. </div>
<div> </div>
<div>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. </div>
<div>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. </div>
<div>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, </div>
<div>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, </div>
<div>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. </div>
<div>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. </div>
<div> </div>
<div> </div>
<div> </div>
<div> </div>
<div>Failed Test results for Sprint OMA-DM Testing using ModemManager:</div>
<div> </div>
<div>HFA Retry: HFA retries seem to be working but the device is making a cellular connection with the device when not active. </div>
<div>So the device gets an IP but it’s to the provisioning server not Sprint public internet network and that never dies off. </div>
<div>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.  </div>
<div> </div>
<div>NI PRL - Native State: Device seems to ignore network initiated updates while in production mode. </div>
<div>Expected Result: The NI PRL should successfully complete, such that the device loads/uses the new PRL and successfully updates its PRL version.</div>
<div> </div>
<div>NI DC - Native State: Device seems to ignore network initiated updates while in production mode. </div>
<div>Expected Result: The NI DC should generate and successfully complete all related requests on the OMA server.</div>
<div> </div>
<div>NI FUMO - Native State: Device seems to ignore network initiated updates while in production mode. </div>
<div>Expected Result: The NI FUMO should successfully complete, such that the device updates itself using the new firmware and successfully updates its firmware version.</div>
<div> </div>
<div>NI PRL - 8k: Device seems to ignore network initiated updates while in production mode. </div>
<div>Expected Result: The NI PRL should successfully complete, such that the device loads/uses the new PRL and successfully updates its PRL version.</div>
<div> </div>
<div>NI PRL - Over 8k: Device seems to ignore network initiated updates while in production mode. </div>
<div>Expected Result: The NI PRL should successfully complete, such that the device loads/uses the new PRL and successfully updates its PRL version.</div>
<div> </div>
<div>NI PRL - 16k (OMA-DM Specification version 2.1 or higher): Device seems to ignore network initiated updates while in production mode. </div>
<div>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.</div>
<div> </div>
<div>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. </div>
<div>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.</div>
<div> </div>
<div>NI PRL - Device in Dormant State/Sleep for 60 min: Device seems to ignore network initiated updates while in production mode. </div>
<div>Expected Results: The NI PRL should successfully complete, such that the device loads/uses the new PRL and successfully updates its PRL version.</div>
<div> </div>
</span></font>
</div>

</div></div>