Software Integration Application Notes For Sprint OMA-DM - Rev2

Mini Card Software Integration Application Notes for Sprint OMA-DM
Proprietary and Confidential
2170012 Rev 2
S o f t wa r e I n t e g r a t i o n A p p l i c a t i o n N o t e s f o r S p r i n t O MA - D M
Preface
Limitation of liability
The information in this manual is subject to change without notice and does not represent a commitment on the part of Sierra Wireless. SIERRA WIRELESS AND ITS AFFILIATES SPECIFICALLY DISCLAIM LIABILITY FOR ANY AND ALL DIRECT, INDIRECT, SPECIAL, GENERAL, INCIDENTAL, CONSEQUENTIAL, PUNITIVE OR EXEMPLARY DAMAGES INCLUDING, BUT NOT LIMITED TO, LOSS OF PROFITS OR REVENUE OR ANTICIPATED PROFITS OR REVENUE ARISING OUT OF THE USE OR INABILITY TO USE ANY SIERRA WIRELESS PRODUCT, EVEN IF SIERRA WIRELESS AND/OR ITS AFFILIATES HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES OR THEY ARE FORESEEABLE OR FOR CLAIMS BY ANY THIRD PARTY. Notwithstanding the foregoing, in no event shall Sierra Wireless and/or its affiliates aggregate liability arising under or in connection with the Sierra Wireless product, regardless of the number of events, occurrences, or claims giving rise to liability, be in excess of the price paid by the purchaser for the Sierra Wireless product.
Patents
This product may contain technology developed by or for Sierra Wireless Inc. This product includes technology licensed from QUALCOMM. This product is manufactured or sold by Sierra Wireless Inc. or its affiliates under one or more patents licensed from InterDigital Group.
Copyright
2012 Sierra Wireless. All rights reserved.
Trademarks
AirCard is a registered trademark of Sierra Wireless. Sierra Wireless, AirPrime, AirLink, AirVantage, Watcher and the Sierra Wireless logo are trademarks of Sierra Wireless. Windows and Windows Vista are registered trademarks of Microsoft Corporation. Macintosh and Mac OS are registered trademarks of Apple Inc., registered in the U.S. and other countries. QUALCOMM is a registered trademark of QUALCOMM Incorporated. Used under license. Other trademarks are the property of the respective owners.
Proprietary and confidential
2170012
Preface
Contact Information
Sales Desk: Phone: Hours: E-mail: Technical Support: 1-604-232-1488 8:00 am to 5:00 pm Pacific Time
sales@sierrawireless.com
Included with the purchase of the Development Kit you receive five hours of tier 3 engineering integration support. You will have received instructions by e-mail on how to access the OEM Customer Support web site. For more details, please contact your account manager, or the Sierra Wireless sales desk (see above).
RMA Support: Post:
repairs@sierrawireless.com
Sierra Wireless 13811 Wireless Way Richmond, BC Canada V6V 3A4 1-604-231-1109
Fax: Web:
www.sierrawireless.com
For up-to-date product descriptions, documentation, application notes, firmware upgrades, troubleshooting tips, and press releases, consult our website: www.sierrawireless.com
Re v 2 A u g - 1 2
Table of Contents
About This Guide..................................................................................... 8 Introduction .................................................................................. 8 Scope .......................................................................................... 8 Glossary of terms ......................................................................... 9 References .................................................................................10 Revision history ..........................................................................11 Integration overview ...............................................................................12 CnS required support ..................................................................12 AT required support ....................................................................12 Sierra Wireless SDK required support.........................................12 Comprehensive sequences ....................................................................14 DC / PRL ....................................................................................14 HFA ............................................................................................16 Scenarios ...............................................................................................17 CI DC Successful update ..........................................................17 CI DC Failure Empty session ..................................................18 CI DC Failure user cancellation ...............................................19 CI DC Failure Generic .............................................................20 NI (Idle) DC Successful update .................................................20 NI (Idle) DC Failure empty session..........................................21 NI (Idle) DC Failure User cancellation .....................................22 NI (Idle) DC Failure Generic ....................................................23 NI (Dormant / Active) DC Accept ...............................................24 NI (Dormant / Active) DC Reject................................................25 CI PRL Successful update ........................................................26 CI PRL No PRL candidate.........................................................26 CI PRL Failure User cancelled ................................................27 CI PRL Failure Generic ...........................................................28 NI (Idle) PRL Successful update ...............................................29
4 Proprietary and confidential 2170012
Ta b l e o f C o n t e n t s
NI (Idle) PRL No PRL candidate................................................30 NI (Idle) PRL Failure User cancelled .......................................31 NI (Idle) PRL Failure Generic ..................................................32 NI (Dormant) PRL Accept .........................................................33 NI (Dormant) PRL Reject ..........................................................34 HFA Successful 1st try ...............................................................35 HFA Successful after retry ........................................................35 HFA Failure Generic ...............................................................36 Appendix A: CI vs. NI Idle vs. NI Dormant/Active User Experience .........37 Appendix B: UI Text................................................................................38 Preparing services ......................................................................38 Profile update success ................................................................38 Profile empty error ......................................................................38 Profile update failed Generic .....................................................38 Profile update prompt ..................................................................38 PRL checking..............................................................................38 PRL updating ..............................................................................38 PRL no candidate .......................................................................38 PRL success ...............................................................................38 PRL update prompt .....................................................................38 HFA initiation ..............................................................................39 HFA success...............................................................................39 HFA retry ....................................................................................39 HFA failure ..................................................................................39 Aborted .......................................................................................39 Appendix C: Frequently Asked Questions ..............................................40
Re v 2 A u g - 1 2
List of Figures
Figure 1: DC / PRL ................................................................................15 Figure 2: HFA ........................................................................................16 Figure 3: CI DC Successful update ......................................................17 Figure 4: CI DC Failure empty session ..............................................18 Figure 5: CI DC Failure user cancellation ..........................................19 Figure 6: CI DC Failure Generic.........................................................20 Figure 7: NI (Idle) DC Successful update .............................................21 Figure 8: NI (Idle) DC Failure empty session .....................................21 Figure 9: NI (Idle) DC Failure User cancellation .................................22 Figure 10: NI (Idle) DC Failure Generic..............................................23 Figure 11: NI (Dormant / Active) DC Accept.........................................24 Figure 12: NI (Dormant / Active) DC Reject .........................................25 Figure 13: CI PRL Successful update ..................................................26 Figure 14: CI PRL No PRL candidate ..................................................26 Figure 15: CI PRL Failure User cancelled ..........................................27 Figure 16: CI PRL Failure Generic .....................................................28 Figure 17: NI (Idle) PRL Successful update .........................................29 Figure 18: NI (Idle) PRL No PRL candidate .........................................30 Figure 19: NI (Idle) PRL Failure User cancelled .................................31 Figure 20: NI (Idle) PRL Failure Generic ............................................32 Figure 21: NI (Dormant) PRL Accept ...................................................33 Figure 22: NI (Dormant) PRL Reject ....................................................34 Figure 23: HFA Successful 1st try.........................................................35 Figure 24: HFA Successful after retry ..................................................35 Figure 25: HFA Failure Generic .........................................................36
2170012
L i s t o f Ta b l e s
List of Tables
Table 1: Acronyms.................................................................................. 9 Table 2: CnS messages that must be supported ...................................12
Re v 2 A u g - 1 2
About This Guide

Introduction
This document describes and illustrates the most common hostdevice message exchanges that occur in standard OMA-DM operations on the Sprint network. This document is intended to act as an addendum to the Sprint OMA-DM Functional Requirements document [R-1] and the Sierra Wireless CnS Reference Guide [R4]. This documents does not cover FOTA/FUMO operations. These can be found in the Sprint FOTA Integration Guide [R-2].
Note: You can view this guide online or print it to keep on hand. If you're viewing it online, simply click a topic in the Table of Contents or any section reference. (Most text that is blue is a clickable link.) The PDF automatically displays the appropriate page.
Scope
This document targets CDMA devices on the Sprint Nextel network that are compliant with version 1.4.5 of the Sprint OMADM spec [R-1] and are operating with a host connection manager that also supports this messaging. It is suggested that you review the Sprint OMA-DM spec and the Sierra Wireless CnS Reference Guide before reading through the current document.
2170012
A b o u t Th i s G u i d e
Glossary of terms
Table 1: Acronyms
Acronym/term Description AT A set of modem commands, preceded by AT, originally developed by Hayes, Inc. for their modems. The structure (but not the specific commands, which vary greatly from manufacturer to manufacturer) is a de facto modem industry standard. For a detailed description of the AT commands supported by the modem, see the AT Command Reference document from Sierra Wireless (document 2130620). Code Division Multiple AccessA wideband spread spectrum technique used in digital cellular, personal communications services, and other wireless networks. Wide channels (1.25 MHz) are obtained through spread spectrum transmissions, thus allowing many active users to share the same channel. Each user is assigned a unique digital code, which differentiates the individual conversations on the same channel. Client-Initiated Client-Initiated Device Configuration Connection Manager (software) Control and Status (language)a proprietary protocol for managing the control and status of the modem. CnS is described in detail in the CnS Reference document from Sierra Wireless (document 2130754). Device Configuration Device Management The network switches a 3G (1X or 1xEV-DO) high-speed data connection into a dormant mode if there is no traffic on the connection for some time. This allows the modem, if it supports voice, to make and receive voice calls while the data connection is idle. When you resume data traffic, the high-speed data connection becomes active. Software stored in ROM or EEPROM; essential programs that remain even when the system is turned off. Firmware is easier to change than hardware, but more permanent than software stored on disk. Firmware Update Over The Aira feature included in OMA Device Management (OMA-DM). Firmware Update Management Object. Related to FOTA (Firmware Update Over The Air)a feature included in OMA Device Management (OMA-DM). Hands Free Activation
CDMA
CI CIDC CM CnS
DC DM dormant
firmware
FOTA FUMO
HFA
Re v 2 A u g - 1 2
Acronym/term Description NI NIA NIDC NIFUMO NIPRL notification Network-Initiated Network-Initiated Alert Network-Initiated Device Configuration Network-Initiated Firmware Update Management Object Network-Initiated PRL Update A mechanism to send unsolicited data from either side (host; modem) of the interface; used when no reply or return data is required from the receiver (or conversations do not require stopand-wait flow control) Open Mobile Alliance Open Mobile Alliance - Device Management. A device management (DM) protocol specified by the Open Mobile Alliance (OMA) Device Management Working Group and the Data Synchronization (DS) Working Group. Product Release Instructionsa file that contains the settings used to configure wireless products for a particular service provider, customer, or purpose. Preferred Roaming Listan account configuration item set by the users service provider. It controls the radio channels/network carrier used by the modem.
OMA OMA-DM
PRI
PRL
References
Ref. # R-1 R-2 R-3 R-4 Document title Sprint_OMADM_Client_Functional_Requirements_v1.5.1_080908.pdf Sprint FOTA Integration Guide, Sierra Wireless CDMA API Reference, Sierra Wireless CDMA 1xEV-DO CnS Reference, Sierra Wireless Doc. # N/a 2131025 2130593 2130754
10
2170012
A b o u t Th i s G u i d e
Revision history
Version 0.1 0.2 1.0 Date 28aug08 22sep08 29sep08 Summary of changes Initial draft. Incorporated review suggestions. Added Profile, PRL Update Prompts and Aborted message to Appendix B UI Text. Updated NI Dormant PRL Reject to include <Aborted> message. Added FAQ section and minor notes/updates. Updated doc to FileHold format and added to FileHold System. Used the Technical Publications layout. Changed CnS object names to match what the CnS Reference uses. Removed products that have reached end-of-life (MC5727). New template. Changes to the patents section.
1.1 1.2 1.3
19jan09 27jan09 Apr09
Aug12
Re v 2 A u g - 1 2
11
Integration overview
The OMA-DM feature covered in this document is a standardized protocol through which devices may be remotely administered by the network. This guide aims to cover integration of OMA-DM, particularly the Device Configuration (DC), PRL update, and Hands Free Activation (HFA) features per Sprints requirements. The diagrams cover modem-to-SDK communication vis-a-vis CnS messages and the SDK-to-Application communication vis-a-vis Sierra Wireless API calls.
CnS required support

The following table shows the CnS messages that must be supported, to implement OMA-DM at the CnS level. Table 2: CnS messages that must be supported
Object ID 0x0E00 0x0E01 0x0E02 0x0E03 Set Get Notification
DM Configuration Start DM Session Cancel DM Session DM Session State
Network-Initiated Alert 0x0E04
AT required support
At the time of publication of this document, AT-based implementation of OMA-DM is not supported.
Sierra Wireless SDK required support

Implementing OMA-DM at the Sierra Wireless SDK level requires support of the following APIs and notification objects: Sierra Wireless SDK APIs:
SwiGetOMADMConfig SwiStartOMADMSession SwiCancelOMADMSession SwiSetOMADMNIAlertResponse
12
2170012
I n t e g r a t i o n o ve r vi e w
Notifications:
SWI_NOTIFY_OMADM_State SWI_NOTIFY_OMADM_NI_Alert
The above two notifications must be enabled in order to support OMA-DM. These notifications should be registered as part of the host client (that is, connection manager) initiation sequence. For details on the Sierra Wireless SDK APIs and Sierra Wireless SDK Notification objects, see the CDMA API Reference guide [R3] and the header files accompanying the SDK.
Re v 2 A u g - 1 2
13
Comprehensive sequences
DC / PRL
Figure 1 on page 15 illustrates standard alternative messages that may occur in a Sprint OMA-DM DC or PRL session. An important subtle characteristic that should be noted is that an OMA-DM session may have multiple initiations messages (DM Session State [0x0E03] with state = Active) within a single session. This is a result of the auto-retry requirement, which specifies that, if a Network Initiated OMA-DM session fails to establish for reasons other than authentication failure or no-job, the device should retry up to five times.
Note: These flows assume that the CM has already properly registered for notifications for the OMA-DM CnS objects (see Table 2 on page 12). Prompts / host UI messages are not presented in this sectionthe UI experience varies depending between PRL/DC sessions and Idle/Dormant/Active states.
14
2170012
Comprehensive sequences
Figure 1: DC / PRL
sd Generic OMA-DM Sequence SWI Modem alt CNS_DM_NI_ALERT
<UI Mode>, <PRL/DC>
SDK / Host
SDK Client
[Network Initiated] SWI_NOTIFY_OMADM_NI_Alert [Client Initiated] CNS_DM_SESSION_START

<PRL/DC>
SwiStartOMADMSession() Return
CNS_DM_SESSION_START
Success
loop
[If NI then retry up to 5 times upon soft establishment failures] CNS_DM_SESSION_STATE SWI_NOTIFY_OMADM_State
Active, <NI/CI>, <PRL/DC>
OMA-DM Session alt CNS_DM_SESSION_STATE

Not Active, <NI/CI>, <PRL/DC>, Success, Updated
[Successful] SWI_NOTIFY_OMADM_State
[Failure] opt CNS_DM_SESSION_CANCEL CNS_DM_SESSION_CANCEL

Success
SwiCancelOMADMSession() Return
Cancel
CNS_DM_SESSION_STATE
Not Active,<NI/CI>, <PRL/DC>, <ERROR>, Not Updated ,
SWI_NOTIFY_OMADM_State
Re v 2 A u g - 1 2
15
HFA
Figure 2 illustrates standard alternative messages that may occur in a Sprint HFA session.
Note: The HFA attempted flag is now obsolete.
Figure 2: HFA
sd HFA Sequence
SWI Modem CNS_DM_SESSION_STATE HFA Session loop

Active, HFA, D-CI
SDK / Host SWI_NOTIFY_OMADM_State
SDK Client
<HFA Initiation>
[While not successful and retries <=5] CNS_DM_SESSION_STATE

HFA Retry Pending, , TTR, D-CI, HFA, Unspecified Error
<HFA Retry>
alt
[HFA Successful] CNS_DM_SESSION_STATE

Not Active, D-CI, HFA, Success, Updated
<HFA Success>
[HFA Not Successful] CNS_DM_SESSION_STATE

Not Active, D-CI, HFA, Unspecified Error, Not Updated
<HFA Failure>
16
2170012
Scenarios
Scenarios
This section describes and illustrates the expected messaging sequences for OMA-DM DC, PRL and HFA scenarios described in the Sprint OMA-DM requirements document [R-1].
Note: Prompts or host UI messages referenced via bracket notation in the message flows are later described in Appendix B: UI Texton page 38.
CI DC Successful update
User selects to perform a CI DC update, and it completes successfully. Figure 3: CI DC Successful update
sd CI DC - Successful
SWI Modem
SDK / Host (1) CNS_DM_SESSION_START

Device Configuration
SDK Client SwiStartOMADMSession() Return <Preparing services>
(2) CNS_DM_SESSION_START
Success
(3) CNS_DM_SESSION_STATE CI DC Session

Active, Device Configuration, U-CI
SWI_NOTIFY_OMADM_State SWI_NOTIFY_OMADM_State <Profile Update Success>
(4) CNS_DM_SESSION_STATE
Not Active, U-CI, Dev Conf, Success, Updated
Steps: (1) (2) (3) (4) Host requests the Modem to initiate a User Client Initiated (U-CI) Device Configuration session. Modem acknowledges the request. Modem notifies the Host that the Device Configuration Session has begun. Modem notifies the Host that the Device Configuration Session has completed successfully.
Re v 2 A u g - 1 2
17
CI DC Failure Empty session

User selects to perform a CI DC update, and the network erroneously sends an empty profile. Figure 4: CI DC Failure empty session
sd CI DC Failure Empty Session
SWI Modem (1) CNS_DM_SESSION_START

SDK / Host SwiStartOMADMSession() Return
SDK Client
Success
<Preparing services>
(3) CNS_DM_SESSION_STATE CI DC Session

SWI_NOTIFY_OMADM_State SWI_NOTIFY_OMADM_State
Not Active, Dev Conf, U-CI, No Op, Not Updated
<Profile Empty Error>
Steps: (1) (2) (3) (4) Host requests the Modem to initiate a User Client Initiated (U-CI) Device Configuration session. Modem acknowledges the request. Modem notifies the Host that the Device Configuration Session has begun. Modem notifies the Host that the Device Configuration Session has completed, and that no operations were conducted and thus the configuration has not been updated.
18
2170012
Scenarios
CI DC Failure user cancellation

User selects to perform a CI DC update and cancels the session midway. Figure 5: CI DC Failure user cancellation
sd CI DC Failure User Cancellation

SDK Client
Success
SWI_NOTIFY_OMADM_State Cancel
CI DC Session
(4) CNS_DM_SESSION_CANCEL (5) CNS_DM_SESSION_CANCEL

Success
Not Active, Dev Conf, U-CI, User Aborted, Not Updated
<Aborted>
Steps: (1) (2) (3) (4) (5) (6) Host requests the Modem to initiate a User Client Initiated (U-CI) Device Configuration session. Modem acknowledges the request. Modem notifies the Host that the Device Configuration Session has begun. Host requests the Modem to cancel the Device Configuration session. Modem responds to the Host indicating that the request was successfully received. Modem notifies the Host that the Device Configuration Session has aborted per the users request.
Re v 2 A u g - 1 2
19
CI DC Failure Generic
User selects to perform a CI DC update, and it fails due to a generic error. Figure 6: CI DC Failure Generic
sd CI DC Failure Generic

SDK Client
Success
CI DC Session
Not Active, Dev Conf, U-CI, Unspecified Error, Not Updated
<Profile Generic Error>
Steps: (1) (2) (3) (4) Host requests the Modem to initiate a User Client Initiated (U-CI) Device Configuration session. Modem acknowledges the request. Modem notifies the Host that the Device Configuration Session has begun. Modem notifies the Host that the Device Configuration Session has erroneously ended for an unknown reason.
NI (Idle) DC Successful update

Network pushes a NI update while the device is Idle, and it completes successfully. Scenario prerequisite: Modem is in Idle Modethere are no packet data connections active/dormant or circuit switched calls active (for example, voice call).
20
2170012
Scenarios
Figure 7: NI (Idle) DC Successful update

sd NI (Idle) DC Successful
SWI Modem (1) CNS_DM_NI_ALERT

Informative, Device Conf
SDK / Host
SDK Client SWI_NOTIFY_OMADM_NI_Alert
Active, NI, Device Configuration
SWI_NOTIFY_OMADM_State SWI_NOTIFY_OMADM_State <Profile Update Success>
NI DC Session
Not Active, NI, Dev Conf, Success, Updated
Steps: (1) Modem notifies the Host that a Network Initiated (NI) Device Configuration request was received. Since this is an informative session, the host should display the status to the user. Modem notifies the Host that the Device Configuration Session has begun. Modem notifies the Host that the Device Configuration Session has completed successfully.
(2) (3)
NI (Idle) DC Failure empty session

Network pushes a NI update while the device is Idle and erroneously sends an empty profile. Scenario prerequisite: Modem is in Idle Modethere are no packet data connections active/dormant or circuit switched calls active (for example, voice call). Figure 8: NI (Idle) DC Failure empty session
sd NI (Idle) DC Failure Empty Session

SDK / Host
SDK Client <Preparing services>
SWI_NOTIFY_OMADM_NI_Alert
Active, Device Configuration, NI
NI DC Session
Not Active, Dev Conf, NI, No Op, Not Updated
<Profile Empty Error>
Re v 2 A u g - 1 2
21
Steps: (1) Modem notifies the Host that a Network Initiated (NI) Device Configuration request was received. Since this is an informative session, the host should display the status to the user. Modem notifies the Host that the Device Configuration Session has begun. Modem notifies the Host that the Device Configuration Session has completed, no operations were conducted and thus the configuration has not been updated.
(2) (3)
NI (Idle) DC Failure User cancellation

Network pushes a NI update while the device is Idle, and the user cancels the session midway. Scenario prerequisite: Modem is in Idle Modethere are no packet data connections active/dormant or circuit switched calls active (for example, voice call). Figure 9: NI (Idle) DC Failure User cancellation
sd NI (Idle) DC Failure User Cancellation

SDK / Host SWI_NOTIFY_OMADM_NI_Alert
SDK Client <Preparing services>
SWI_NOTIFY_OMADM_State Cancel
NI DC Session

Success
Not Active, Dev Conf, NI, User Aborted, Not Updated
SWI_NOTIFY_OMADM_State <Aborted>
Steps: (1) Modem notifies the Host that a Network Initiated (NI) Device Configuration request was received. Since this is an informative session, the host should display the status to the user. Modem notifies the Host that the Device Configuration Session has begun. Host requests the Modem to cancel the Device Configuration session.
Proprietary and confidential 2170012
(2) (3)
22
Scenarios
(4) (5)
Modem responds to the Host indicating that the request was successfully received. Modem notifies the Host that the Device Configuration Session has aborted per the users request.
NI (Idle) DC Failure Generic

Network pushes a NI update while the device is Idle and it fails due to a generic error. Scenario prerequisite: Modem is in Idle Modethere are no packet data connections active/dormant or circuit switched calls active (for example, voice call). Figure 10: NI (Idle) DC Failure Generic
sd NI (Idle) DC Failure Generic

SDK / Host SWI_NOTIFY_OMADM_NI_Alert
SDK Client
SWI_NOTIFY_OMADM_State SWI_NOTIFY_OMADM_State SWI_NOTIFY_OMADM_State SWI_NOTIFY_OMADM_State SWI_NOTIFY_OMADM_State SWI_NOTIFY_OMADM_State SWI_NOTIFY_OMADM_State <Profile Generic Error>
NI DC Session
Not Active, Dev Conf, NI, Unspecified Error, Not Updated
Steps: (1) Modem notifies the Host that a Network Initiated (NI) Device Configuration request was received. Since this is an informative session, the host should display the status to the user. Modem notifies the Host that the Device Configuration Session has begun. Because the modem is experiencing a generic error with the network, it will retry five times. Modem notifies the Host that the Device Configuration Session has erroneously ended for an unknown reason.
(2)
(3)
Re v 2 A u g - 1 2
23
NI (Dormant / Active) DC Accept

Network pushes NI update while device is Dormant, and the user elects to update the profile. Scenario prerequisite: Modem is in a dormant or active packet data connection. If the network pushes a NI update while the device is active (active data call or active circuit switch call), the modem queues the request until it becomes dormant. Once the notification is sent to the host, the connection will not necessarily still be dormant. It is suggested that the host handle NI sessions in the same manner for both active and dormant scenarios. Figure 11: NI (Dormant / Active) DC Accept
sd NI (Dormant/Active) DC Accept
SWI Modem
SDK / Host
SDK Client
Device active or dormant (1) CNS_DM_NI_ALERT

SWI_NOTIFY_OMADM_NI_Alert Yes
<Profile Update Prompt>
ref
(2) Disconnect Data Session SwiSetOMADMNIAlertResponse() Return
(3) CNS_DM_NI_ALERT
Yes
(4) CNS_DM_NI_ALERT
Success
ref
(5) NI DC Session
Steps: (1) Modem notifies the Host that a Network Initiated Device Configuration request was received. Since the device is dormant (connected but not active) when this notification is received the Modem will wait until it is dormant and notify the Host that it should interrupt the user and request permission to continue. As a result of the user selecting to continue with the OMADM session, the Host disconnects the current data session. Host sends a message to the Modem to indicate that it wants to interrupt the current data connection and perform a device configuration session. Modem acknowledges receipt of the message.
(2) (3)
(4)
24
2170012
Scenarios
(5)
Subsequent messages follow the same flow as NI (Idle) DC Scenarios (see pages 20 through 23).
NI (Dormant / Active) DC Reject

Network pushes NI update while device is dormant; the user elects to not interrupt their current session and thus not update the profile. Scenario prerequisite: Modem is in a dormant or active packet data connection. If the network pushes a NI update while the device is active (active data call or active circuit switch call), the modem queues the request until it becomes dormant. Once the notification is sent to the host, the connection will not necessarily still be dormant. It is suggested that the host handle NI sessions in the same manner for both active and dormant scenarios. Figure 12: NI (Dormant / Active) DC Reject
sd NI (Dormant) DC Reject
SWI Modem Device active or dormant (1) CNS_DM_NI_ALERT

SDK / Host
SDK Client
SWI_NOTIFY_OMADM_NI_Alert SwiSetOMADMNIAlertResponse() Return No
<Profile Update Prompt>
(2) CNS_DM_NI_ALERT
No
(3) CNS_DM_NI_ALERT
Success
<Aborted>
Steps: (1) Modem notifies the Host that a Network Initiated Device Configuration request was received. Since the device is Dormant (connected but not active) when this notification is received, the Modem notifies the Host that it should interrupt the user and request permission to continue. Host messages the Modem to indicate that it does not want to interrupt the current data connection with a DC session. Modem acknowledges receipt of the message.
(2) (3)
Re v 2 A u g - 1 2
25
CI PRL Successful update

User selects to perform a CI PRL update and it completes successfully. Figure 13: CI PRL Successful update
sd CI PRL Successful

PRL
SDK Client
Success
<PRL Checking>
Active, PRL, U-CI
SWI_NOTIFY_OMADM_State SWI_NOTIFY_OMADM_State <PRL Success>
CI PRL Session
Not Active, U-CI, PRL, Success, Updated
Steps: (1) (2) (3) (4) Host requests the Modem to initiate a User Client Initiated (U-CI) PRL update session. Modem acknowledges the request. Modem notifies the Host that the PRL Session has begun. Modem notifies the Host that the PRL Session has completed successfully.
CI PRL No PRL candidate

User selects to perform a CI PRL update, but the network does not have an update available. Figure 14: CI PRL No PRL candidate
sd CI PRL No PRL Candidate
SWI Modem
SDK Client
PRL
Success
<PRL Checking>
Active, PRL, U-CI
CI PRL Session
Not Active, PRL, U-CI, No Op, Not Updated
<PRL No Candidate>
26
2170012
Scenarios
Steps: (1) (2) (3) (4) Host requests the Modem to initiate a User Client Initiated (U-CI) PRL session. Modem acknowledges the request. Modem notifies the Host that the PRL Session has begun. Modem notifies the Host that the PRL Session has ended with no operations completed and thus no updates.
CI PRL Failure User cancelled

User selects to perform a CI PRL update and then cancels the session midway. Figure 15: CI PRL Failure User cancelled
sd CI PRL User Cancellation
SWI Modem
SDK Client
PRL
Success
<PRL Checking>
Active, PRL, U-CI
SWI_NOTIFY_OMADM_State SwiCancelOMADMSession() Return Cancel
CI PRL Session

Success
Not Active, PRL, U-CI, User Aborted, Not Updated
<Aborted>
Steps: (1) (2) (3) (4) (5) (6) Host requests the Modem to initiate a User Client Initiated (U-CI) PRL session. Modem acknowledges the request. Modem notifies the Host that the PRL Session has begun. Host requests the Modem to cancel the PRL session in an effort to stop the update process. Modem responds to the Host indicating that the request was successfully received. Modem notifies the Host that the PRL Session has aborted per the users request.
Re v 2 A u g - 1 2
27
CI PRL Failure Generic

User selects to perform a CI PRL update and it fails due to a generic error. Figure 16: CI PRL Failure Generic
sd CI PRL Failure Generic

PRL
SDK Client
Success
<PRL Checking>
Active, PRL, U-CI
CI PRL Session
Not Active, PRL, U-CI, Unspecified Error, Not Updated
<PRL Generic Error>
Steps: (1) (2) (3) (4) Host requests the Modem to initiate a User Client Initiated (U-CI) PRL session. Modem acknowledges the request. Modem notifies the Host that the PRL Session has begun. Modem notifies the Host that the PRL Session has erroneously ended for an unknown reason.
28
2170012
Scenarios
NI (Idle) PRL Successful update

Network pushes a NI PRL session while the device is Idle and it completes successfully. Scenario prerequisite: Modem is in Idle Modethere are no packet data connections active/dormant or circuit switched calls active (for example, voice call). Figure 17: NI (Idle) PRL Successful update
sd NI (Idle) PRL Successful

Background, PRL
SDK / Host
SDK Client
SWI_NOTIFY_OMADM_ NI_Alert
Active, PRL, NI
NI PRL Session
Not Active, NI, PRL, Success, Updated
Steps: (1) Modem notifies the Host that a Network Initiated (NI) PRL request was received. Since this is a background session, the host should hide this session from the user unless the user interrupts the session. Modem notifies the Host that the PRL Session has begun. Modem notifies the Host that the PRL Session has completed successfully.
(2) (3)
Re v 2 A u g - 1 2
29
NI (Idle) PRL No PRL candidate

Network pushes a NI PRL session while the device is Idle, and the network does not have an update available. Scenario prerequisite: Modem is in Idle Modethere are no packet data connections active/dormant or circuit switched calls active (for example, voice call). Figure 18: NI (Idle) PRL No PRL candidate
sd NI (Idle) PRL No PRL Candidate

Background, PRL
SDK / Host
SDK Client
SWI_NOTIFY_OMADM_ NI_Alert
Active, PRL, NI
NI PRL Session
Not Active, NI, PRL, No Op, Not Updated
Steps: (1) Modem notifies the Host that a Network Initiated (NI) PRL request was received. Since this is a background session, the host should hide this session from the user unless the user interrupts the session. Modem notifies the Host that the PRL Session has begun. Modem notifies the Host that the PRL Session has ended with no operations completed and thus no updates.
(2) (3)
30
2170012
Scenarios
NI (Idle) PRL Failure User cancelled

Network pushes a NI PRL session while the device is Idle and then cancels the session midway. Scenario prerequisite: Modem is in Idle Modethere are no packet data connections active/dormant or circuit switched calls active (for example, voice call). Figure 19: NI (Idle) PRL Failure User cancelled
sd NI (Idle) PRL Failure User Cancellation

Background, PRL
SDK / Host SWI_NOTIFY_OMADM_ NI_Alert
SDK Client
Active, PRL, NI
SWI_NOTIFY_OMADM_State User actions interrupt process <PRL Updating> SwiCancelOMADMSession() Return Cancel
NI PRL Session

Success
Not Active, PRL, U-CI, User Aborted, Not Updated
SWI_NOTIFY_OMADM_State <Aborted>
Steps: (1) Modem notifies the Host that a Network Initiated (NI) PRL request was received. Since this is a background session, the host should hide this session from the user unless the user interrupts the session. Modem notifies the Host that the PRL Session has begun. Host requests the Modem to cancel the PRL session in an effort to stop the update process. Modem responds to the Host indicating that the request was successfully received. Modem notifies the Host that the PRL Session has aborted per the users request.
(2) (3) (4) (5)
Re v 2 A u g - 1 2
31
NI (Idle) PRL Failure Generic

Network pushes a NI PRL session while the device is Idle and it fails due to a generic error. Scenario prerequisite: Modem is in Idle Modethere are no packet data connections active/dormant or circuit switched calls active (for example, voice call). Figure 20: NI (Idle) PRL Failure Generic
sd NI (Idle) PRL Failure Generic

Background, PRL
SDK / Host SWI_NOTIFY_OMADM_ NI_Alert SWI_NOTIFY_OMADM_State SWI_NOTIFY_OMADM_State SWI_NOTIFY_OMADM_State SWI_NOTIFY_OMADM_State SWI_NOTIFY_OMADM_State SWI_NOTIFY_OMADM_State SWI_NOTIFY_OMADM_State
SDK Client
Active, PRL, NI
NI PRL Session
Active, PRL, NI
Active, PRL, NI
Active, PRL, NI
Active, PRL, NI
Active, PRL, NI
Not Active, NI, PRL, Unspecified Error, Not Updated
Steps: (1) Modem notifies the Host that a Network Initiated (NI) PRL request was received. Since this is a background session, the host should hide this session from the user unless the user interrupts the session. Modem notifies the Host that the PRL Session has begun. Modem notifies the Host that the PRL Session has erroneously ended for an unknown reason.
(2) (3)
32
2170012
Scenarios
NI (Dormant) PRL Accept

Network pushes NI PRL update while device is dormant, and the user elects to proceed. Scenario prerequisite: Modem is in a dormant or active packet data connection. If the network pushes a NI update while the device is active (active data call or active circuit switch call) the modem queues the request until it becomes dormant. Once the notification is sent to the host, the connection will not necessarily still be dormant. It is suggested that the host handle NI sessions in the same manner for both active and dormant scenarios. Figure 21: NI (Dormant) PRL Accept
sd NI (Dormant) PRL Accept
SWI Modem
SDK / Host
SDK Client

Background, PRL
SWI_NOTIFY_OMADM_ NI_Alert Yes
<PRL Update Prompt>
ref
(2) Disconnect Data Session
(3) CNS_DM_NI_ALERT
Yes
SwiSetOMADMNIAlertResponse() Return
(4) CNS_DM_NI_ALERT
Success
ref
(5) NI PRL Session
Steps: (1) Modem notifies the Host that a Network Initiated (NI) PRL request was received. Since the device is dormant (connected but not active) when this notification is received, the Modem notifies the Host that it should interrupt the user and request permission to continue. As a result of the user selecting to continue with the OMADM session, the Host disconnects the current data session. Host messages the Modem to indicate that it does want to interrupt the current data connection and perform a device configuration session. Modem acknowledges receipt of the message.
(2) (3)
(4)
Re v 2 A u g - 1 2
33
(5)
Subsequent message follow same flow as NI (Idle) PRL Scenarios. Note: In the subsequent flows the UI should not treat this as a background session; instead, it should treat this as an informative session and inform the user of the progress.
NI (Dormant) PRL Reject

Network pushes NI PRL update while device is dormant and the user elects to not interrupt their current session and thus not update the PRL. Scenario prerequisite: Modem is in a dormant or active packet data connection. If the network pushes a NI update while the device is active (active data call or active circuit switch call), the modem queues the request until it becomes dormant. Once the notification is sent to the host, the connection will not necessarily still be dormant. It is suggested that the host handle NI sessions in the same manner for both active and dormant scenarios. Figure 22: NI (Dormant) PRL Reject
sd NI (Dormant) PRL Reject
SWI Modem
SDK / Host
SDK Client

Background, PRL
SWI_NOTIFY_OMADM_ NI_Alert SwiSetOMADMNIAlertResponse() Return No
<PRL Update Prompt>
(2) CNS_DM_NI_ALERT
No
(3) CNS_DM_NI_ALERT
Success
<Aborted>
Steps: (1) Modem notifies the Host that a Network Initiated (NI) PRL request was received. Since the device is Dormant (connected but not active) when this notification is received, the Modem notifies the Host that it should interrupt the user and request permission to continue. Host messages the Modem to indicate that it does not want to interrupt the current data connection with a PRL session. Modem acknowledges receipt of the message.
(2) (3)
34
2170012
Scenarios
HFA Successful 1st try

The modem automatically attempts Hands Free Activation, which completes successfully upon the first attempt. Figure 23: HFA Successful 1st try
sd HFA 1st Try Successful
SWI Modem (1) CNS_DM_SESSION_STATE

Active, HFA, D-CI
SDK / Host SWI_NOTIFY_OMADM_State SWI_NOTIFY_OMADM_State
SDK Client
<HFA Initiation> <HFA Success>
HFA Session
Steps: (1) Modem notifies the Host that the modem has initiated a Device-Client Initiated (D-CI) Hand Free Activation (HFA) session. Modem notifies the Host that the HFA session has completed successfully.
(2)
HFA Successful after retry

The modem automatically attempts Hands Free Activation, which completes successfully on the third attempt.
Note: HFA Retry occurs only if the error is no operation was performed.
Figure 24: HFA Successful after retry

sd HFA Retry Successful
SWI Modem (1) CNS_DM_SESSION_STATE HFA Session

Active, HFA, D-CI
SDK / Host
SDK Client
<HFA Initiation> <HFA Retry>
HFA Retry Pending, TTR, D-CI, HFA, No Op, Not Updated
Active, HFA, D-CI
<HFA Initiation> <HFA Retry>
HFA Retry Pending, TTR, D-CI, HFA, No Op, Not Updated
Active, HFA, D-CI
<HFA Initiation> <HFA Success>
Re v 2 A u g - 1 2
35
Steps: (1) Modem notifies the Host that the modem has initiated a Device-Client Initiated (D-CI) Hand Free Activation (HFA) session. Modem notifies the Host of a failed HFA attempt. Modem notifies the Host that the modem has re-initiated a Device-Client Initiated (D-CI) Hand Free Activation (HFA) session. Modem notifies the Host of a failed HFA attempt. Modem notifies the Host that the modem has re-initiated a Device-Client Initiated (D-CI) Hand Free Activation (HFA) session. Modem notifies the Host that the HFA session has completed successfully.
(2) (3)
(4) (5)
(6)
HFA Failure Generic

Device automatically attempts Hands Free Activation and fails for unspecified reason. Figure 25: HFA Failure Generic
sd HFA Failure Generic
SWI Modem (1) CNS_DM_SESSION_STATE HFA Session

Active, HFA, D-CI
SDK / Host
SDK Client
<HFA Initiation>
Not Active, D-CI, HFA, Unspecified Error, Not Updated
<HFA Failure>
Steps: (1) Modem notifies the Host that the modem has initiated a Device-Client Initiated (D-CI) Hand Free Activation (HFA) session. Modem notifies the Host that the HFA session has failed.
(2)
36
2170012
A p p e n d i x A : C I v s . N I I d l e v s . N I D o r m a n t / A c t i v e U s e r E xp e r i e n c e
Appendix A: CI vs. NI Idle vs. NI Dormant/Active User Experience

The CI, NI Idle, and NI Dormant OMA-DM sessions have message flows that are very similar with only subtle parameter and UI experience differences. It is important to understand these differences in order to ensure compliance with Sprints OMA-DM specification [R-1]. A CI OMA-DM session requires the Host to display status of the entire OMA-DM session, regardless of the reported UI mode. A Network Initiated (NI) Device Configuration (DC) session will report a standard UI mode of informative, which requires that the Host keep the user informed of the session status regardless of whether it was started in Dormant mode or in Idle mode. A Network Initiated (NI) PRL session will report a standard UI mode of background. In this scenario the Host does not inform the user of the session unless interrupted by the user. If the user interrupts a NI Idle PRL session, then the Host shall display the status of the session so that the user is informed and may cancel the operation. If a session is network initiated while the device is dormant or active, the host shall prompt the user to determine whether they wish to continue their data session or perform the update. If they choose to continue, the Host shall first disconnect the data session, send the Alert Response message and then continue to display the status of the session. If the prompt is not responded to and the device goes idle, the device may automatically continue with the NI session.
Note: Your application should ignore the Special UI mode parameter.
Re v 2 A u g - 1 2
37
Appendix B: UI Text
Preparing services
The network is preparing your services. Please wait
Profile update success Profile empty error

The profile update could not be completed. Please try again later. If the problem persists, you may need to contact Customer Service.
Profile update failed Generic

Error Code: XXX
Profile update prompt

The purpose of this prompt is to inform the user that a device configuration update is available and ask them if they wish to end their current data session in order to perform the update. The Sprint requirements do not dictate specific text to be displayed.
PRL checking
Checking for PRL update
PRL updating
The network is updating your PRL. Please wait
PRL no candidate
No PRL update available
PRL success
PRL updated.
PRL update prompt

The purpose of this prompt is to inform the user that a PRL update is available and ask them if they wish to end their current data session in order to perform the update.
38 Proprietary and confidential 2170012
A p p e n d i x B : U I Te xt
The Sprint requirements do not dictate specific text to be displayed.
HFA initiation
Hands Free Activation Contacting network
HFA success
Your device has been activated.
HFA retry
Hands Free Activation Waiting for retry in xx seconds
HFA failure
Hands Free Activation Your activation could not be completed. Please try again later. If the problem persists, you may need to contact Customer Service.
Aborted
This message indicates that the update was explicitly canceled by the user. The Sprint requirements do not dictate specific text to be displayed.
Re v 2 A u g - 1 2
39
Appendix C: Frequently Asked Questions

Q: If the host receives an interactive/forced interruption NI Alert indication and does not respond with an interactive response to the modem (for example, NIA-DC), does the modem resend the same indication to the host periodically or is there only one notification? A: For any given NIA received from the network the NetworkInitiated Alert message (0x0E04) is sent only once. Q: How many pending NIAs can the modem store (that is, if the host does not respond to a NIA-DC and the network pushes a NIA-PRL Update)? What happens if the modem's NIA queue overflows? A: If a NIA is received when the modem has an older NIA pending a response from the host, the newer NIA is queued until the previous NIA has been answered. Once the previous NIA has been answered, the queued NIA is sent to the host. Up to 6 NIAs can be queued. Once the queue is full, the subsequent NIAs are dropped. Queued NIAs are also cleared on power-cycle. Q: For interactive/forced-interruption-on-dormancy NI sessions, the modem expects the host to respond with allow or deny. For adapter products, the decision is the responsibility of the end-user, however many embedded solutions are autonomous and do not have the ability to interact with a user; how should autonomous systems act? What is Sprint's requirement? Can the system always "allow" the NI alert session? What happens in this case when call is in dormant state? Will it be disconnected? A: This is a decision that the customer needs to make. The purpose of the prompt is to give the host the ability to choose whether or not it wants to interrupt its current data session to perform the OMA-DM session. If the customers device can support the data session being randomly dropped when an NIA comes in, then it should always allow the NI alert session. Otherwise it is the responsibility of the customer to implement the logic to determine when is a good time to perform an OMA-DM session. Q: How many OMA-DM accounts does a Sierra Wireless device support? A: Sierra Wireless devices currently support only one OMADM account per device.
40
2170012
Q: Please explain the steps the modem goes through when doing an HFA session to provision the MDN and/or MSID. How does the modem get account information overthe-air when the modem is not even activated? Is this over the data channel? A flow diagram will help a lot. A: Upon power-up the modem initiates HFA if any one of the three parameters (MSID, MDN and MIP1) are not provisioned. An unprovisioned modem is able to connect with the OMA-DM server through a MIP slot0 connection that is provisioned at the factory. More information on OMA-DM can be found at: http://www.openmobilealliance.org/Technical/DM.aspx. Q: What happens if HFA fails after retries? Will UCIDeviceConfiguration also provision all the account information and profile update over-the-air, similar to HFA? A: If HFA fails after all retries (if any), the modem will try again the next time the modem is powered up (that is, the modem continues to attempt HFA until it is fully provisioned).
Note: The initial deployment of Sprint Compass 597 USB modems would not retry after the first set of attempts.
Q: In addition to OMA-DM, is manual activation supported in the MC5728V Mini Card? A: Yes Q: If yes, should the host support manual activation on a Sprint MC5728V Mini Card in addition to OMA-DM? A: No Q: Is the OMA-DM server address carrier-specific? If so, should it be set in the PRI? How is the modem provisioned with the OMA-DM server address? A: At this point we support only Sprint OMA-DM requirements and don't support the provisioning of the OMA server address. If and when we support OMA-DM for other carriers, we will need to update the firmware and/or dmtree file at that point. Q: The DM Configuration reply indicates the maximum number of DM accounts supported. Is this same as the DMTLV Account node name in Start DM Session (0x0E01)? A: Currently we support only one DM account, and the DMTLV account node name is not used. Q: Is there a plan to support more than one DM account in the future, as indicated by Start DM Session? A: Currently there are no plans to support more than one DM account. It may happen in the future for dual-mode devices (for example, CDMA and WiMax) but not for the MC5728V Mini Card.
Re v 2 A u g - 1 2
41
Q: What happens if the host sends a DM account name that is not supported? Does the modem respond with an error message? Do the current configuration and PRL remain valid? A: The firmware ignores the DM account name field so it does not make any difference. Q: What can an OMA-DM Device Configuration session change? What happens when a client initiated session occurs? A: An OMA-DM device configuration session can update MIP profile 1, MSID and MDN. The Sprint OMA server normally reprograms all parameters (MIP1, MDN & MSID) with the same values (but we've seen cases where the server performs only a partial or no provisioning). Q: What MIP profiles are used when performing an OMADM session, what about afterwards? A: The active MIP profile when in an OMA-DM session is profile 0. Once the session is completed, the active data profile is changed to profile 1. Q: How can the host query the status of a specific DM account? A: The DM Session State object (0x0E03) returns whether the device is in a DM session state or not, and, if not, whether it is pending HFA retry. On a related note, the Activation Status object (0x1009) returns whether or not the device has been activated. Q: Are the last session result codes for the DM Session State standardized? A: No; they are Sierra Wireless proprietary. Q: At any point in time, can there be more than one active DM session? For example, the host sends Start DM Session (0x0E01) for CI-DeviceConfiguration and this DM session is in active state. Is it valid for the host to send Start DM Session (0x0E01) for CI-PRL update when previous one is still active? If it is not valid, does the modem respond with error? A: Only one DM session can be active at a time. The modem responds with error if a new DM request is made while a session is active. Q: If the modem has an HFA retry pending and also has indicated NI alert for NI DC or NI PRL, when the host sends a cancel DM session to modem, are all the above cancelled or only the last session? A: It will only cancel the HFA.
42
2170012
Q: If the host does not respond to an alert, is the current Device Configuration/PRL/Firmware still valid, or is it overwritten with the new one? A: The current parameters will still be valid (NIA itself does not contain the valuesinstead, it only has a URI to server). Q: Is a simulator available to test some of the cases like NI Alert and failure cases indicated in Sprint-OMA-DM integration guide? How does Sierra Wireless test all of the corner cases? A: As of the publication date of this document, Sierra Wireless is not aware of a commercially-available OMA-DM simulator. Sierra Wireless generated its own simulation and test code, but they are not supported in the released code. Sierra Wireless staff spent a considerable amount of time at Sprints STIC lab and has used sandbox accounts for Sprint production OMA server.
Re v 2 A u g - 1 2
43

Software Integration Application Notes For Sprint OMA-DM - Rev2

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Software Integration Application Notes For Sprint OMA-DM - Rev2

Uploaded by

Copyright:

Available Formats

Mini Card Software Integration Application Notes for Sprint OMA-DM

Proprietary and Confidential

Proprietary and confidential

RMA Support: Post:

Proprietary and confidential

Proprietary and confidential

Proprietary and confidential

Proprietary and confidential

About This Guide

Proprietary and confidential

Proprietary and confidential

Proprietary and confidential

1.1 1.2 1.3

19jan09 27jan09 Apr09

Proprietary and confidential

CnS required support

DM Configuration Start DM Session Cancel DM Session DM Session State

Network-Initiated Alert 0x0E04

Sierra Wireless SDK required support

Proprietary and confidential

Proprietary and confidential

Proprietary and confidential

[Network Initiated] SWI_NOTIFY_OMADM_NI_Alert [Client Initiated] CNS_DM_SESSION_START

OMA-DM Session alt CNS_DM_SESSION_STATE

[Failure] opt CNS_DM_SESSION_CANCEL CNS_DM_SESSION_CANCEL

Proprietary and confidential

SWI Modem CNS_DM_SESSION_STATE HFA Session loop

SDK / Host SWI_NOTIFY_OMADM_State

[While not successful and retries <=5] CNS_DM_SESSION_STATE

[HFA Successful] CNS_DM_SESSION_STATE

[HFA Not Successful] CNS_DM_SESSION_STATE

Proprietary and confidential

SDK / Host (1) CNS_DM_SESSION_START

SDK Client SwiStartOMADMSession() Return <Preparing services>

(3) CNS_DM_SESSION_STATE CI DC Session

SWI_NOTIFY_OMADM_State SWI_NOTIFY_OMADM_State <Profile Update Success>

Proprietary and confidential

CI DC Failure Empty session

SWI Modem (1) CNS_DM_SESSION_START

SDK / Host SwiStartOMADMSession() Return

(3) CNS_DM_SESSION_STATE CI DC Session

<Profile Empty Error>

Proprietary and confidential

CI DC Failure user cancellation

SWI Modem (1) CNS_DM_SESSION_START

SDK / Host SwiStartOMADMSession() Return

(4) CNS_DM_SESSION_CANCEL (5) CNS_DM_SESSION_CANCEL

Proprietary and confidential

SWI Modem (1) CNS_DM_SESSION_START

SDK / Host SwiStartOMADMSession() Return

<Profile Generic Error>

NI (Idle) DC Successful update

Proprietary and confidential

Figure 7: NI (Idle) DC Successful update

SWI Modem (1) CNS_DM_NI_ALERT

SDK Client SWI_NOTIFY_OMADM_NI_Alert

SWI_NOTIFY_OMADM_State SWI_NOTIFY_OMADM_State <Profile Update Success>

NI (Idle) DC Failure empty session

SWI Modem (1) CNS_DM_NI_ALERT

SDK Client <Preparing services>

<Profile Empty Error>

Proprietary and confidential