ip based over-the-air device management (iota- dm) for cdma2000

3GPP2 C.S0064-0

Version 2.0

Date: January 2011

IP Based Over-the-Air Device Management (IOTA-DM) for cdma2000 Systems

© 2011 3GPP2

3GPP2 and its Organizational Partners claim copyright in this document and individual

Organizational Partners may copyright and issue documents or standards publications in

individual Organizational Partner’s name based on this document. Requests for reproduction of this document should be directed to the 3GPP2 Secretariat at

[email protected]. Requests to reproduce individual Organizational Partner’s

documents should be directed to that Organizational Partner. See www.3gpp2.org for more information.

3GPP2 C.S0064-0 v2.0

Revision History

Revision Description Date

C.S0064-0 v1.0 Initial Release September 2005

C.S0064-0 v2.0 Point Release for CDMA MO January 2011

3GPP2 C.S0064-0 v2.0

i

CONTENTS 1

Foreword .............................................................................................................................. vi 2

1 INTRODUCTION ...........................................................................................................1-1 3

1.1 Scope......................................................................................................................1-2 4

1.2 Requirements Language ........................................................................................1-2 5

1.3 References..............................................................................................................1-2 6

1.4 Definitions..............................................................................................................1-3 7

1.5 General Requirements ...........................................................................................1-7 8

1.6 Protocol Requirements ...........................................................................................1-8 9

2 ARCHITECTURE............................................................................................................2-1 10

3 INTRODUCTION TO DM PROTOCOL ..........................................................................3-1 11

3.1 Management Tree ..................................................................................................3-1 12

3.2 Device Description .................................................................................................3-1 13

3.3 Bootstrap Mechanism.............................................................................................3-1 14

3.4 OMA DM Packages and Messages ..........................................................................3-2 15

3.5 OMA DM Commands ..............................................................................................3-2 16

3.6 Notification Message ..............................................................................................3-3 17

4 CDMA DEVICE MANAGEMENT......................................................................................4-1 18

4.1 Communication with the Mobile Station ...............................................................4-1 19

4.2 IOTA-DM content...................................................................................................4-1 20

4.2.1 Command Set ...................................................................................................4-1 21

4.2.2 XML Specification for OMA DM ........................................................................4-1 22

4.2.3 OMA DM DTD...................................................................................................4-1 23

4.2.4 OMA DM DTD Elements ...................................................................................4-1 24

4.3 MIME Types and HTTP Headers .............................................................................4-2 25

4.3.1 MIME Types ......................................................................................................4-2 26

4.3.2 Accept Headers for Supported MIME Types ......................................................4-2 27

4.3.3 HTTP Bindings..................................................................................................4-2 28

4.3.4 Other Transport Bindings ................................................................................4-3 29

4.4 Network Initiated Scenario.....................................................................................4-3 30

4.5 MS Initiated Scenario.............................................................................................4-5 31

5 CDMA MANAGEMENT TREE.........................................................................................5-1 32

3GPP2 C.S0064-0 v2.0

ii

5.1 CDMA DevInfo ........................................................................................................5-1 1

5.1.1 DevId ................................................................................................................5-1 2

5.1.2 CDMAProtPref ...................................................................................................5-2 3

5.1.3 CDMAProtCap...................................................................................................5-2 4

5.1.4 CDMABandModCap ..........................................................................................5-2 5

5.2 CDMA Operational Parameters ..............................................................................5-3 6

5.2.1 CDMA ...............................................................................................................5-3 7

5.2.2 CMDA OpParam................................................................................................5-4 8

5.2.3 ./CDMA/CDMAOpParam/MobDirNum MobDirNum ........................................5-4 9

5.2.4 ./CDMA/CDMAOpParam/AmpsNam ................................................................5-4 10

5.2.5 ./CDMA/CDMAOpParam/CdmaNam ................................................................5-4 11

5.2.6 ./CDMA/CDMAOpParam/CDMANAM/y+ .........................................................5-5 12

5.2.7 ./CDMA/CDMAOpParam/ImsiT .......................................................................5-5 13

5.2.8 ./CDMA/CDMAOpParam/SSPR .......................................................................5-5 14

5.2.9 ./CDMA/CDMAOpParam/PrefRoamList ...........................................................5-5 15

5.2.10 ./CDMA/CDMAOpParam/PrefRoamListDim...................................................5-6 16

5.2.11 ./CDMA/CDMAOpParam/ExPrefRoamList .....................................................5-6 17

5.2.12 ./CDMA/CDMAOpParam/ExPrefRoamListDim...............................................5-6 18

5.2.13 ./CDMA/CDMAOpParam/PUZL ......................................................................5-6 19

5.2.14 ./CDMA/CDMAOpParam/SysTag ...................................................................5-7 20

5.3 MOID for CDMA MO ...............................................................................................5-7 21

5.4 CDMA Packet Data Objects ....................................................................................5-7 22

5.4.1 CDMAAP ...........................................................................................................5-8 23

5.4.2 ./CDMAAP/3GPD..............................................................................................5-9 24

5.4.2.1 ./CDMAAP/3GPD/3GPDOCP......................................................................5-9 25

5.4.2.2 ./CDMAAP/3GPD/3GPDOMP .....................................................................5-9 26

5.4.2.3 ./CDMAAP/3GPD/SIP...............................................................................5-10 27

5.4.2.4 ./CDMAAP/3GPD/MIP..............................................................................5-10 28

5.4.2.5 ./CDMAAP/3GPD/HRPD...........................................................................5-10 29

5.5 CDMA MMD Management Object.........................................................................5-10 30

5.5.1 ./CDMA/MMD ................................................................................................5-11 31

5.5.2 ./CDMA/MMD/IMPILength ............................................................................5-11 32

3GPP2 C.S0064-0 v2.0

iii

5.5.3 ./CDMA/MMD/IMPI........................................................................................5-12 1

5.5.4 ./CDMA/MMD/NumIMPU...............................................................................5-12 2

5.5.5 ./CDMA/MMD/ImpuEntryIndex+ ...................................................................5-12 3

5.5.6 ./CDMA/MMD/ImpuEntryIndex+/IMPU..........................................................5-12 4

5.5.7 ./CDMA/MMD/SIPURILength.........................................................................5-13 5

5.5.8 ./CDMA/MMD/SIPDomainURI .......................................................................5-13 6

5.5.9 ./CDMA/MMD/NumPCSCF ............................................................................5-13 7

5.5.10 ./CDMA/MMD/PCSCFEntryIndex+ ...............................................................5-13 8

5.5.11 ./CDMA/MMD/PCSCFEntryIndex+/PCSCFAdd.............................................5-14 9

5.6 CDMA System Tag Management Object...............................................................5-14 10

5.6.1 ./CDMA/SysTag/HomeSysTag .......................................................................5-14 11

5.6.2 ./CDMA/SysTag/GroupTagListDim................................................................5-15 12

5.6.3 ./CDMA/SysTag/GroupTagList ......................................................................5-15 13

5.6.4 ./CDMA/SysTag/SpecificTagListDim .............................................................5-15 14

5.6.5 ./CDMA/SysTag/SpecificTagList....................................................................5-15 15

5.6.6 ./CDMA/SysTag/CallPromptListDim..............................................................5-16 16

5.6.7 ./CDMA/SysTag/CallPromptList ....................................................................5-16 17

5.7 CDMA MMS Management Object .........................................................................5-16 18

5.7.1 ./CDMA/MMS.................................................................................................5-17 19

5.7.2 ./CDMA/MMS/NumMMSURI..........................................................................5-17 20

5.7.3 ./CDMA/MMS/MMSURIEntryIndex+ ..............................................................5-18 21

5.7.4 ./CDMA/MMS/MMSURIEntryIndex+/MMSURI...............................................5-18 22

5.7.5 ./CDMA/MMS/MMSCap/...............................................................................5-18 23

5.7.6 ./CDMA/MMS/MMSCap/MaxNumMMSURI ...................................................5-18 24

5.7.7 ./CDMA/MMS/MMSCap/MaxMMSURILength ...............................................5-19 25

6 IOTA-DM SECURITY.....................................................................................................6-1 26

6.1 Access Control and Security...................................................................................6-1 27

6.2 OTA Update of A-Key and other Critical Parameters..............................................6-1 28

6.2.1 A-Key and Root Key Generation.......................................................................6-1 29

6.2.2 Service Key Generation ....................................................................................6-5 30

6.2.3 SSD Update ......................................................................................................6-6 31

6.2.4 Establishing A-Key using DM when OTASP/OTAPA support exists.................6-6 32

3GPP2 C.S0064-0 v2.0

iv

6.3 Secure Mode Operation .........................................................................................6-9 1

7 HANDLING OF OTASP/OTAPA MESSAGES.................................................................7-1 2

8 IOTA-DM FIRMWARE UPDATE OVER-THE-AIR ............................................................8-1 3

8.1 CDMA Specific Security Mechanisms for FOTA......................................................8-1 4

ANNEX A DDF DESCRIPTION OF DEVINFO.................................................................... A-1 5

6

3GPP2 C.S0064-0 v2.0

v

FIGURES 1

Figure 2-1 Network Architecture....................................................................................... 2-1 2

Figure 2-2 End-to-End Architecture for Device Management ........................................... 2-2 3

Figure 3.4-1 OMA DM Message ......................................................................................... 3-2 4

Figure 4.4-1 Network Initiated Scenario ........................................................................... 4-4 5

Figure 4.5-1 Client Initiated Scenario............................................................................... 4-5 6

Figure 5.1-1 CDMA DevInfo Subtree ................................................................................. 5-1 7

Figure 5.2-1 CDMA Operational Parameters Management Objects.................................. 5-3 8

Figure 5.3-1 CDMA Packet Data Management Objects..................................................... 5-8 9

Figure 5.4-1 CDMA MMD Management Objects.............................................................. 5-11 10

Figure 5.5-1 CDMA System Tag Management Objects.................................................... 5-14 11

Figure 5.6-1 CDMA MMS Management Objects .............................................................. 5-17 12

Figure 6.2.1-1 Key Generation using DM Protocol ............................................................ 6-2 13

Figure 6.2.1-2 Command in Package #2 ............................................................................ 6-4 14

Figure 6.2.1-3 Example of Results Command in Package #3 ............................................. 6-4 15

Figure 6.2.1-4 Commands in Package #4........................................................................... 6-5 16

Figure 6.2.1-5 Example of Results Command.................................................................... 6-5 17

Figure 6.2.2-1 Command for Service Key Generation ....................................................... 6-6 18

Figure 6.2.4-1 Flow Diagram for A-Key Establishment ...................................................... 6-7 19

Figure 7-1 Representation of OTASP/OTAPA Message .................................................... 7-1 20

Figure 7-2 Message Flow for Handling OTASP/OTAPA Message. .................................... 7-2 21

22

3GPP2 C.S0064-0 v2.0

vi

FOREWORD 1

(This foreword is not part of this specification.) 2

This specification was prepared by 3GPP2 TSG-C Working Group 1. 3

3GPP2 C.S0064-0 v2.0

vii

NOTES 1

1. Compatibility, as used in connection with cdma2000®1, is understood to mean: 2

any cdma2000 mobile station is able to place and receive calls in cdma2000 and 3

IS-95 systems. Conversely, any cdma2000 system is able to place and receive calls 4

for cdma2000 and IS-95 mobile stations. 5

2. The following verbal forms are used: “Shall” and “shall not” identify requirements 6

to be followed strictly to conform to the standard and from which no deviation is 7

permitted. “Should” and “should not” indicate that one of several possibilities is 8

recommended as particularly suitable, without mentioning or excluding others; 9

that a certain course of action is preferred but not necessarily required; or that 10

(in the negative form) a certain possibility or course of action is discouraged but 11

not prohibited. “May” and “need not” indicate a course of action permissible 12

within the limits of the standard. “Can” and “cannot” are used for statements of 13

possibility and capability, whether material, physical, or causal. 14

3. Footnotes appear at various points in this specification to elaborate and to 15

further clarify items discussed in the body of the specification. 16

4. Unless indicated otherwise, this document presents numbers in decimal form. 17

Binary numbers are distinguished in the text by the use of single quotation 18

marks. In some tables, binary values may appear without single quotation marks 19

if table notation clearly specifies that values are binary. The character ‘x’ is used 20

to represent a binary bit of unspecified value. For example ‘xxx00010’ represents 21

any 8-bit binary value such that the least significant five bits equal ‘00010’. 22

Hexadecimal numbers (base 16) are distinguished in the text by use of the form 23

0xh…h where h…h represents a string of hexadecimal digits. For example, 24

0x2fa1 represents a number whose binary value is ‘0010111110100001’ and 25

whose decimal value is 12193. Note that the exact number of bits in the binary 26

representation of a hexadecimal number strictly depends on the implementation 27

requirements for the variable being represented. 28

5. “Base station” refers to the functions performed on the fixed network, which are 29

typically distributed among a cell, a sector of a cell, and a mobile communications 30

switching center. 31

1 “cdma2000® is the trademark for the technical nomenclature for certain specifications and standards of the Organizational Partners (OPs) of 3GPP2. Geographically (and as of the date of publication), cdma2000® is a registered trademark of the Telecommunications Industry Association (TIA-USA) in the United States.”

3GPP2 C.S0064-0 v2.0

viii

REFERENCES 1

The following standards are referenced in this text. At the time of publication, the 2

editions indicated were valid. All standards are subject to revision, and parties to 3

agreements based upon this document are encouraged to investigate the possibility of 4

applying the most recent editions of the standards indicated below. ANSI and TIA 5

maintain registers of currently valid national standards published by them. 6

- Normative References: 7

21.3GPP2 C.S0015-B v1.0, Short Message Services for Wideband Spread Spectrum 8

Systems, June 2004. 9

21.3GPP2 C.S0016-C v1.0, Over-the-Air Service Provisioning of Mobile Stations in Spread 10

Spectrum Systems, November 2004. 11

21.3GPP2 C.S0040-0 v1.0, IP Based Over-the-Air Handset Configuration Management, 12

July 2003. 13

21.3GPP2 S.R0101-0 1 IOTA Device Management for cdma2000 Systems – Stage-1 14

requirements, version 1.0, April 22 2004. 15

21.OMA Device Management Protocol, version 1.2, OMA, June 2005. URL 16

http://www.openmobilealliance.org/release_program/dm_v12.html 17

21.OMA DM Representation Protocol, version 1.2, OMA, June 2005. 18

21.OMA DM Tree and Descriptions, version 1.2, OMA, June 2005. 19

21.OMA DM Bootstrap, version 1.2, OMA, June 2005. 20

21.OMA DM Notification Initiated Session, version 1.2, OMA, June 2005. 21

21.OMA DM Security, version 1.2, OMA, June 2005. 22

21.OMA DM DDF DTD (OMA-DM-DDF-V1_2_0-20050118-D.dtd), version 1.2, OMA, June 23

2005. 24

21.OMA SyncML HTTP Binding, Version 1.2,OMA, June 2005. 25

21.OMA SyncML OBEX Binding, version 1.2, OMA, June 2005. 26

21.OMA SyncML WSP Binding, version 1.2, OMA, June 2005. 27

21.OMA Firmware Update Management Object, Draft Version 1.0, May 2005. 28

http://member.openmobilealliance.org/ftp/Public_documents/DM/Permanent_docum29

ents/OMA-TS-DM-FUMO-V1_0-20050518-D.zip 30

21.W3C Extensible Markup Language (XML) 1.0 (Second Edition), W3C Recommendation, 31

Version 6, October 2000. 32

21.IETF RFC 2396, Uniform Resource Identifiers (URI): Generic Syntax, August 1998. 33

21.IETF RFC 2045, Multipurpose Internet Mail Extensions (MIME) Part One: Format of 34

Internet Message Bodies, November 1996. 35

21.IETF RFC 2246, The TLS Protocol, Version 1.0, January 1999. 36

3GPP2 C.S0064-0 v2.0

ix

21.IETF RFC 2616: “HTTP 1.1”. 1

21.IETF RFC 2543, SIP: Session Initiation Protocol, March 1999. 2

3

3GPP2 C.S0064-0 v2.0

x

This page intentionally left blank. 1

3GPP2 C.S0064-0 v2.0

1-1

1 INTRODUCTION 1

As the functionality of mobile devices grows at an increasing rate, configuring and 2

maintaining the services and features on the devices becomes a complex and time-3

consuming task. For instance, enabling WAP, CDMA, and data connectivity requires 4

configuration of multiple settings. Even with limited features of today, many customers 5

have difficulty in configuring their mobile devices. Operators should ensure that phone 6

configuration is quick and easy for the customer. Another use case is over-the-air (OTA) 7

provisioning and management of new services to mobile devices. Advanced mobile 8

services such as browsing, multimedia messaging, mobile e-mail, and calendar 9

synchronization requires accurate mobile phone settings. The process of remotely 10

managing device settings and applications is called Device Management. 11

Device Management will help the widespread adoption of mobile services, as it provides a 12

mechanism for the users to easily subscribe to new services. For the operators this 13

enables a fast and easy way to introduce new services and manage provisioned services, 14

by dynamically adjusting to changes and ensuring a certain level of quality of service. 15

In June, 2003 OMA released the OMA Device Management (OMA DM) version 1.1.2 16

standard based on SyncML DM [5-15]. OMA DM provides an integrated and extensible 17

framework for the OTA management needs of 3G mobile devices and beyond. The 18

standard includes the OMA DM protocol specification, which is based on the SyncML DM 19

protocol [5]. The protocol is optimized for OTA management - basic consideration being 20

the resource and bandwidth limitations of mobile devices. 21

OMA DM, as a mechanism, is very versatile and can be used to manage different types of 22

data objects. Some of the data objects are simple numeric or textual parameters, while 23

others are binary. Numeric objects may include connectivity parameters, such as access 24

point addresses and proxy configurations. Binary objects may be security keys, blocks of 25

data or software modules. 26

The protocol leverages OMA DM bootstrap [8] for initial provisioning and the set of DM 27

protocol specifications [5-15] for continuous management after the initial provisioning. 28

OMA DM does not define network dependent aspects of OTA management, as this has to 29

be defined in respective forums or standard bodies addressing specific network and air 30

interface aspects. 31

A method for updating firmware over the air (FOTA) based on OMA DM is also specified 32

[15]. 33

The purpose of this document is to describe OTA management of Mobile Stations in 34

CDMA systems using OMA DM protocol. OMA DM can be adapted to meet CDMA IP based 35

over-the-air management (IOTA) requirements [4] and OTA firmware update to CDMA 36

mobile stations; hence bringing interoperability to IOTA management of CDMA devices. 37

3GPP2 C.S0064-0 v2.0

1-2

1.1 Scope 1

This document describes IP based Over-the-Air Device Management of mobile stations 2

compliant with cdma2000®2 standards. 3

1.2 Requirements Language 4

“Shall” and “shall not” identify requirements to be followed strictly to conform to this 5

document and from which no deviation is permitted. “Should” and “should not” indicate 6

that one of several possibilities is recommended as particularly suitable, without 7

mentioning or excluding others, that a certain course of action is preferred but not 8

necessarily required, or that (in the negative form) a certain possibility or course of action 9

is discouraged but not prohibited. “May” and “need not” indicate a course of action 10

permissible within the limits of the document. “Can” and “cannot” are used for statements 11

of possibility and capability, whether material, physical or causal. 12

1.3 References 13

The following standards are referenced in this text. At the time of publication, the 14

editions indicated were valid. All standards are subject to revision, and parties to 15

agreements based upon this document are encouraged to investigate the possibility of 16

applying the most recent editions of the standards indicated below. ANSI and TIA 17

maintain registers of currently valid national standards published by them. 18

- Normative References: 19

1. 3GPP2 C.S0015-B v2.0, Short Message Services for Wideband Spread Spectrum 20

Systems, September 2005. 21

2. 3GPP2 C.S0016-C v2.0, Over-the-Air Service Provisioning of Mobile Stations in Spread 22

Spectrum Standards, October 2008. 23

3. 3GPP2 C.S0040-0 v1.0, IP Based Over-the-Air Handset Configuration Management 24

(IOTA-HCM), July 2003. 25

4. 3GPP2 S.R0101-0 v1.0, IOTA Device Management for cdma2000 Systems – Stage-1 26

requirements, version 1.0, April 2004. 27

5. OMA Device Management Protocol, version 1.2.1, OMA, June 2008. 28

6. OMA Device Management Representation Protocol, version 1.2.1, OMA, June 2008. 29

7. OMA Device Management Tree and Descriptions, version 1.2.1, OMA, June 2008. 30

8. OMA Device Management Bootstrap, version 1.2.1, OMA, June 2008. 31

9. OMA Device Management Notification Initiated Session, version 1.2.1, OMA, June 32

2008. 33

2 “cdma2000® is the trademark for the technical nomenclature for certain specifications and standards of the Organizational Partners (OPs) of 3GPP2. Geographically (and as of the date of publication), cdma2000® is a registered trademark of the Telecommunications Industry Association (TIA-USA) in the United States.”

3GPP2 C.S0064-0 v2.0

1-3

10. OMA Device Management Security, version 1.2.1, OMA, June 2008. 1

11. OMA DM DDF DTD (OMA-SUP-dtd_dm_ddf-V1_2-20070209-A.dtd), version 1.2.1, OMA, 2

June 2008. 3

12. OMA SyncML HTTP Binding, version 1.2.2,OMA, July 2009. 4

13. OMA SyncML OBEX Binding, version 1.2.2, OMA, July 2009 5

14. OMA SyncML WSP Binding, version 1.2.2, OMA, July 2009 6

15. OMA Firmware Update Management Object, Draft Version 1.0, August 2009. 7

16. W3C Extensible Markup Language (XML) 1.0 (Second Edition), W3C Recommendation, 8

Version 6, October 2000. 9

17. IETF RFC 2396, Uniform Resource Identifiers (URI): Generic Syntax, August 1998. 10

18. IETF RFC 2045, Multipurpose Internet Mail Extensions (MIME) Part One: Format of 11

Internet Message Bodies, November 1996. 12

19. IETF RFC 2246, The TLS Protocol, Version 1.0, January 1999. 13

20. IETF RFC 2616: “HTTP 1.1”. 14

21. IETF RFC 2543, SIP: Session Initiation Protocol, March 1999. 15

Note, OMA Device Management documents can be found with the following URL: 16

http://www.openmobilealliance.org/Technical/release_program/dm_v1_2.aspx 17

OMA SyncML documents can be found with the following URL 18

http://www.openmobilealliance.org/Technical/release_program/SyncML_v1_2_2.aspx 19

1.21.4 Definitions 20

Base Stations (BS). A fixed station used for communicating with mobile stations. 21

Depending upon the context, the term base station may refer to a cell, a sector within a 22

cell, an MSC, an OTAF, or other part of the wireless system. (See also MSC and OTAF.) 23

BS. See Base Station. 24

CSC. See Customer Service Center. 25

CSD. Circuit Switched Data. 26

Customer Service Center (CSC). An entity in a wireless carrier’s network that receives 27

service requests from the end users and acts on such requests. 28

Device Management. Method for remotely managing devices as defined in [5]. 29

DM. See Device Management. 30

Electronic Serial Number (ESN). A 32-bit number assigned by the mobile station 31

manufacturer, uniquely identifying the mobile station equipment. 32

ESN. See Electronic Serial Number. 33

Extensible Markup Language (XML). See [16]. 34

3GPP2 C.S0064-0 v2.0

1-4

Firmware Update Over-the-Air. Refers to the mechanism of updating mobile station 1

firmware over-the-air. 2

FOTA. See Firmware Over-the-Air. 3

Handset Configuration Management (HCM). Refers to the process of updating and 4

managing mobile stations configuration. See [3]. 5

HCM. See Handset Configuration Management. 6

HRPD. High Rate Packet Data. 7

Hypertext Transfer Protocol (HTTP). Refers to a protocol used by web browsers to 8

communicate with the web servers. See [20]. 9

HTTP. See Hyper Text Transfer Protocol. 10

IMSI. See International Mobile Station Identity. 11

International Mobile Subscriber Identity (IMSI). A method of identifying stations in 12

the land mobile service as specified in ITU-T Recommendation E.212. 13

IOTA-DM Client. An agent in the MS that is an extension of the OMA DM Client to 14

support CDMA requirements as specified in this document. 15

IOTA-DM Server. A DM Server that can handle the CDMA procedures described in this 16

document. 17

IOTA-HCM. See IP-based Over-The-Air Handset Configuration Management. 18

IP-based Over-The-Air Handset Configuration Management (IOTA-HCM). Refers to 19

the protocol as defined by this document to perform over-the-air mobile station 20

configuration management operations. 21

MC. See Messaging Center. 22

MEID. See Mobile Equipment Identifier. 23

Messaging Center (MC). Refers to an entity in the wireless network that is responsible 24

for delivering SMS (see [1]) messages to the mobile station. 25

MIN. See Mobile Identification Number. 26

MIP. Mobile IP. 27

M MC. See Mobile Management Command. 28

M MD. Multimedia Domain. 29

M MS. Multimedia Messaging Service. 30

Mobile Equipment Identifier (MEID). A 56-bit equipment identifier as a replacement for 31

32-bit ESN. 32

Mobile Identification Number (MIN). The 34-bit number that is a digital 33

representation of the 10-digit number assigned to a mobile station. 34

Mobile Switching Center (MSC). A configuration of equipment that provides wireless 35

radio telephone service. Also called the Mobile Telephone Switching Office (MTSO). 36

3GPP2 C.S0064-0 v2.0

1-5

Mobile Station (MS). A station, fixed or mobile, which serves as the end user’s wireless 1

communication link with the base station. Mobile stations include portable units (e.g., 2

hand-held personal units) and units installed in vehicles. 3

MS. See Mobile Station. 4

MSC. See Mobile Switching Center. 5

NAM. See Number Assignment Module. 6

Number Assignment Module (NAM). A set of MIN/IMSI-related parameters stored in the 7

mobile station. 8

Object Exchange Protocol (OBEX). Protocol defined for exchanging contents in 9

bluetooth. 10

OMA DM. See OMA Device Management. 11

OMA DM Client. See the description in [5]. 12

OMA DM Server. See the description in [5]. 13

OMA Device Management (OMA DM). Refers to the set of specifications developed by 14

Open Mobile Alliance for Device Management (DM). See 15

http://www.openmobilealliance.org. 16

OMNA. Open Mobile Naming Authority. Open Mobile AllianceTM. 17

OMNA DM Management Object Registry. See 18

http://www.openmobilealliance.org/Tech/omna/omna-dm_mo-registry.aspx. 19

OTAF. See Over-the-Air Function. 20

OTAPA. See Over-The-Air Parameter Administration. 21

OTASP. See Over-The-Air Service Provisioning. 22

Over-the-Air Function (OTAF). A configuration of network equipment that controls 23

OTASP functionality and messaging protocol. 24

Over-The-Air Parameter Administration (OTAPA). Network initiated OTASP process of 25

provisioning mobile station operational parameters over the air interface. 26

Over-The-Air Service Provisioning (OTASP). A process of provisioning mobile station 27

operational parameters over the air interface. 28

Preferred Roaming List (PRL). Mobile station parameter that controls the process of 29

acquiring a wireless system. 30

PRL. See Preferred Roaming List. 31

Request For Comment (RFC). Refers to type of specifications document released by 32

Internet Engineering Task Force (IETF). 33

RFC. See Request For Comment. 34

R-UIM. Removable User Identity Module. 35

Short Message Service (SMS). See [1]. 36

3GPP2 C.S0064-0 v2.0

1-6

SIP. Simple IP. 1

SMS. See Short Message Service. 2

SPASM. See Subscriber Parameter Administration Mechanism. 3

SPL. See Service Programming Lock. 4

Service Programming Lock (SPL). A protection provided for preventing the over-the-air 5

provisioning of certain mobile station parameters by unauthorized network entity by way 6

of verifying the Service Programming Code (SPC). 7

Subscriber Parameter Administration Mechanism (SPASM). Security mechanism 8

protecting parameters and indicators of active NAM from programming by an unauthorized 9

network entity during the OTAPA session. 10

SyncML. See Synchronization Mark-up Language. 11

Synchronization Mark-up Language. A common language for exchanging information 12

between mobile devices and the network. Open specifications for SyncML are published 13

by OMA. 14

SyncML DM. See SyncML Device Management. 15

SyncML Device Management. SyncML Device Management is a protocol based on 16

SyncML, and optimised for remotely managing mobile devices over-the-air. Open 17

specifications for SyncML DM are published by OMA, and are called OMA DM 18

specifications. See [5-15]. 19

TLS. See Transport Layer Security. 20

TPD. See Trusted Provisioning Domain. 21

TPS. See Trusted Provisioning Server. 22

Transport Layer Security (TLS). A security protocol. See [19]. 23

Trusted Provisioning Domain (TPD). Refers to an Internet domain that is trusted by 24

the mobile stations and thus is permitted to perform provisioning and other management 25

operations. 26

Trusted Provisioning Server (TPS). Refers to server within the TPD that is trusted by 27

the mobile stations and thus is permitted to perform provisioning and other management 28

operations. 29

UIM. The User Identity Module is a low power processor that contains secure memory. 30

The User Identity Module may be a Removable-UIM (R-UIM), or part of the Mobile Station 31

itself. 32

Uniform Resource Indicator (URI). Refers to a unique identifier of an entity or a 33

resource in a communications network. See [17]. 34

Uniform Resource Locator (URL). Refers to the unique address of an entity or a 35

resource in a communications network. See [17]. 36

URI. See Uniform Resource Indicator. 37

3GPP2 C.S0064-0 v2.0

1-7

URL. See Uniform Resource Locator. 1

Visitor Location Register (VLR). 2

VLR. See Visitor Location Register. 3

WAP. See Wireless Application Protocol. 4

WBXML. See Wireless Binary Extensible Markup Language. 5

Wireless Application Protocol. Refers to set of protocols developed by Open Mobile 6

Alliance. See http://www.openmobilealliance.org. 7

Wireless Binary Extensible Markup Language. See [5]. 8

W ML. See Wireless Markup Language. 9

Wireless Markup Language. Refers to specific mark up language developed by Open 10

Mobile Alliance for wireless devices. See http://www.openmobilealliance.org. 11

XML. See Extensible Markup Language. 12

1.31.5 General Requirements 13

• An IOTA-DM Client in an MS SHALL be capable of receiving and processing OMA 14

DM commands as defined in [5] from one or more IOTA-DM Servers. 15

• The MS SHALL be capable of receiving and processing management commands 16

from an authorized IOTA-DM Server. 17

• The MS SHALL support the OMA DM tree defined in [7] with CDMA extensions 18

specified in this document. 19

• The MS SHALL be able to receive, process and send OMA DM commands. 20

• The IOTA-DM Management Server SHALL be able to initiate an IOTA-DM 21

Management session. 22

• The MS SHALL be able to initiate an IOTA-DM Management session. The IOTA-23

DM Client SHALL send device information at the beginning of a management 24

session so that the IOTA-DM Server can tailor the contents and operations to 25

suite the capabilities of the MS. 26

• The IOTA DM Server SHALL support the initial provisioning of MSs as defined in 27

OTASP/OTAPA standard [2] or later revisions. 28

• The IOTA DM Server SHALL support the management of MS parameters defined in 29

OTASP/OTAPA standard [2] or later revisions in an IOTA-DM Client equipped MS. 30

• The IOTA-DM Server introducing new parameters MAY NOT be same as the IOTA-31

DM Server managing these parameters. 32

• The IOTA-DM Server SHALL be able to support modification, deletion, and 33

addition of parameters in the MS, e.g., as a result of the user subscribing to a new 34

service offered by an Operator or Service Provider. 35

3GPP2 C.S0064-0 v2.0

1-8

1.41.6 Protocol Requirements 1

Following are the basic requirements for facilitating IOTA management using OMA DM 2

protocol. 3

• Mobile Station SHALL support IP Protocol. 4

• Mobile Station SHALL support HTTP 1.1. 5

• The Mobile Station equipped with IOTA-DM Client and the IOTA-DM Server shall 6

support OMA DM 1.2 or later versions. 7

• The IOTA-DM Client and IOTA-DM Server interface SHALL use OMA DM 1.2 8

protocol or its later revisions. 9

• For backward compatibility with OTASP/OTAPA [2], the mobile and the server shall 10

support converting IOTA-DM data to OTASP/OTAPA data. 11

• Security Mechanism: The security mechanism as defined in [10] shall be followed 12

in addition to transport layer security [TLS] for IP network. 13

14

15

3GPP2 C.S0064-0 v2.0

2-1

2 ARCHITECTURE 1

Figure 2-1 shows the network architecture for DM in CDMA network. Though only the 2

CDMA interface is shown here, the OMA DM specifications support DM over local access 3

technologies, such as Bluetooth, IrDA etc. 4

5

N/ W

(ANSI-41 )IP n/w

HAOTAF

BSC/ PCF

ME/ UIM/ IOTA-DM Client

PDSNMSC/ VLR

MC AAAH

DM Database

HLR

CDMA

OTASP/ OTAPA

CDMA Air interface

AAAV

Service

Management

Configuration

Management

Enterprise

Management

Software

Management

IOTA-DM

Server

6

7

Figure 2-1 Network Architecture 8

9

3GPP2 C.S0064-0 v2.0

2-2

Figure 2-2 shows the end-to-end architecture for IOTA-DM. 1

IOTA-DM

Client /

FOTA Download

Agent

HTTP/ WSP/OBEX/ SMS

CDMA/ Bluetooth

AppsManagement

Objects

MS

HTTP/ WSP/OBEX/ SMS

CDMA/ Bluetooth

IOTA-DM

Server

DDF

2

Figure 2-2 End-to-End Architecture for Device Management 3

IOTA-DM Client: See the description of IOTA-DM Client in the Definitions. 4

Management Object: Management Object is a collection of logically related nodes in a 5

management tree. Refer to the definition in [7]. 6

IOTA-DM Server: See the description of IOTA-DM Server in the Definitions. 7

DDF: See the definition of Device Description Framework in [11]. 8

3GPP2 C.S0064-0 v2.0

3-1

3 INTRODUCTION TO DM PROTOCOL 1

The OMA DM Protocol [5] defines a management framework and a protocol for various 2

management procedures. This section describes briefly the core components of OMA DM 3

architecture. 4

3.1 Management Tree 5

Every MS that supports OMA DM shall contain a management tree. All available 6

management objects are logically grouped in the MS as a hierarchical tree structure called 7

the management tree. Thus, the management of a service or application in the DM 8

framework requires accessing nodes in the management tree corresponding to the service 9

or application. 10

The management tree is structured on the basis of services, and applications. Each node 11

in the management tree is addressed with a URI as described in the OMA DM Tree and 12

Descriptions specification [7]. 13

Using the DDF [11] of the management tree, described in section 3.2, and the Tree 14

exchange mechanism [7], the management server knows the URI [17] of the location to be 15

referenced for a specific management action. 16

In the management tree, CDMA objects would be specific subtrees. Similarly application 17

objects form other subtrees of the management tree. Section 5 describes the CDMA 18

management tree. In the case R-UIM is present in the MS, the IOTA-DM parameters 19

updated to the R-UIM shall be considered in priority. 20

3.2 Device Description 21

The management objects in the management tree are made known to the management 22

server through the DDF (Device Description Framework) description of the MS. The DDF 23

description is an XML document [16], which is made available to the management server. 24

The DDF DTD specified in [11] is used to describe the management syntax and semantics 25

for a particular MS. 26

The DDF description gives the properties, such as type, format, description etc of each 27

object, and their relative location in the management tree. The server learns about the 28

management objects and how to manage the objects from the DDF description. 29

The DDF framework provides a flexible mechanism, allowing management of customized 30

and new features in the device. 31

Features common to a class of mobile devices can be standardized for interoperability. 32

The management tree for CDMA objects described in section 5 of this document can be 33

represented using the DDF DTD. 34

3.3 Bootstrap Mechanism 35

OMA DM uses the WAP bootstrap for initial provisioning. The bootstrap mechanism is 36

defined in the OMA DM Bootstrap specification [8]. 37

3GPP2 C.S0064-0 v2.0

3-2

3.4 OMA DM Packages and Messages 1

In OMA DM, set of messages, exchanged between the DM client and the management 2

server, are conceptually combined in to a package. In most situations a package 3

corresponds to a single message, but when large objects are involved in the transfer, each 4

package is sent over multiple DM messages. A DM message is a well-formed XML 5

document with header and body. The XML specification for OMA DM is described in the 6

protocol specifications [6]. 7

Limitations on package size, message boundaries etc. are defined in OMA DM 8

representation protocol [6]. An example of a DM message is shown below. 9

<SyncML xmlns=’SYNCML:SYNCML1.1’>

<SyncHdr>

<!---header information, credentials>

</SyncHdr>

<SyncBody>

<!--- Message body – commands, alerts>

<Final/>

</SyncBody>

</SyncML>

10

Figure 3.4-1 OMA DM Message 11

12

The Syncbody carries one or more OMA DM commands. 13

3.5 OMA DM Commands 14

OMA DM protocol allows commands to be executed on a node in the management tree, 15

resulting in a specific management action. Management action can be create, read, 16

update, delete etc. OMA DM Management commands are used to represent the 17

management actions and associated data elements that are transferred between the DM 18

client and the management server. 19

OMA DM commands are in XML form. See OMA DM Representation Protocol [6]. 20

3GPP2 C.S0064-0 v2.0

3-3

3.6 Notification Message 1

The DM notification message causes the client to initiate a connection to the 2

management server and begin a management session. The notification is a signed 3

message, which the client can authenticate. There are several fields in the notification 4

message, for example the UI-mode field is used for specifying user interaction when the 5

client receives the notification. 6

Notification message can also originate within the device, thus triggering the 7

establishment of a session, for example when a timer expires. 8

The format and security mechanism for OMA DM notification message are described in the 9

OMA DM Notification Initiated Session [9]. 10

11

3GPP2 C.S0064-0 v2.0

3-4

No textThis page intentionally left blank. 1

3GPP2 C.S0064-0 v2.0

4-1

4 CDMA DEVICE MANAGEMENT 1

A typical management session has two phases: 1) setup phase 2) management phase. In 2

the setup phase, credentials and device information (DevInfo) are exchanged. DevInfo is a 3

standardized subtree in the management tree [7], which provides information about the 4

capabilities of the device. This helps the management server to tailor the contents to 5

meet device capabilities. In the management phase, the client and the server shall 6

interact to carry out one or more management tasks. It may consist of a number of 7

protocol iterations. Details of establishing a management session and interaction 8

between DM client and management server are described in the OMA DM Protocol [5]. 9

4.1 Communication with the Mobile Station 10

The management commands and data can be exchanged using HTTP [20] [12] or WAP 11

WSP [14]. Next sections describe how the content shall be represented and the transport 12

bindings. 13

4.2 IOTA-DM content 14

This section describes how the contents exchanged between the mobile station and the 15

network is represented. Management data and commands exchanged over-the-air shall be 16

represented using OMA DM Representation Protocol [6]. 17

4.2.1 Command Set 18

Following commands Add, Alert, Atomic, Copy, Delete, Exec, Get, Replace, 19

Results, and Sequence as described in [6] shall be used to manage parameters in the 20

mobile station represented using the management tree as described in section 5. 21

4.2.2 XML Specification for OMA DM 22

4.2.3 OMA DM DTD 23

The DTD for OMA DM usage is specified in [6]. 24

4.2.4 OMA DM DTD Elements 25

The elements used in OMA DM messages to represent management data and commands 26

are specified in [6]. The elements are classified in to the following groups: 27

• Common use elements: Archive, Chal, Cmd, CmdID, CmdRef, Cred, 28

Final, Lang, LocName, LocURI, MoreData, MsgID, MsgRef, NoResp, 29

NoResults, NumberOfChanges, RespURI, SessionID, SftDel, 30

Source, SourceRef, Target, TargetRef, VerDTD, VerProto. 31

• Message container elements: SyncML, SyncHdr, SyncBody. 32

• Date description elements: Data, Item, Meta. 33

• Protocol management elements: Status. 34

3GPP2 C.S0064-0 v2.0

4-2

• Protocol command elements: Add, Alert, Atomic, Copy, Delete, 1

Exec, Get, Replace, Results, Sequence. 2

The protocol command elements shall be used to read and update values of parameters 3

represented as objects in the management tree of the mobile station. The use of the 4

above elements and how they are used to access the management tree in the mobile 5

station, to perform management operations, are described in [6]. The Sequence element 6

allows several commands to be specified in the same message. The Atomic element is 7

similar to sequence, except that all specified commands are executed as a set or not at all 8

[6]. 9

4.3 MIME Types and HTTP Headers 10

4.3.1 MIME Types 11

The XML Content-Type for SyncML must be specified to be one of the following: 12

• application/vnd.syncml.dm+xml: For textual SyncML DM document 13

• application/vnd.syncml.dm+wbxml: For WBXML encoded SyncML DM document 14

In the above, application/vnd.syncml.dm+xml identifies clear text XML representation 15

of OMA DM message and application/vnd.syncml.dm+wbxml identifies WBXML binary 16

encoded form of the OMA DM message. 17

One of these MIME types are used to identify OMA DM messages within transport and 18

session layer protocols. 19

The binary encoding and XML representation are described in the OMA DM specifications. 20

4.3.2 Accept Headers for Supported MIME Types 21

While performing HTTP requests to the IOTA-DM Server, IOTA-DM client must add OMA 22

DM content types accepted by the client in the HTTP accept headers. 23

For the MMC documents sent in XML (uncompiled) format, following MIME type shall be 24

used: 25

• Content-Type: application/vnd.syncml.dm+xml 26

For the MMC documents compiled using WBXML as specified in this document, following 27

MIME type shall be used: 28

• Content-Type: application/vnd.syncml.dm+wbxml 29

4.3.3 HTTP Bindings 30

When OMA DM messages are sent over HTTP protocol [20], the HTTP headers should 31

include information about the OMD DM protocol and security parameters. The OMA 32

HTTP bindings specification [12] describes the HTTP header for OTA messaging using 33

OMA DM. 34

3GPP2 C.S0064-0 v2.0

4-3

4.3.4 Other Transport Bindings 1

The bindings for other IP based protocols such as Wireless Session Protocol (WSP) and 2

Object Exchange Protocol (OBEX) are given in the specifications [14] and [13] respectively. 3

4.4 Network Initiated Scenario 4

Figure 4.4-1 shows interaction between various components in a typical network initiated 5

management session. 6

In this scenario, the bootstrap provisioning is completed and the client and server are 7

configured to establish a management session. 8

9

3GPP2 C.S0064-0 v2.0

4-4

1

Package #1: Credentials and CDMA

DevInfo

Package #2: Server Credentials and

Initial Management Actions

Package #3: Client Responses

Package #4: More Management

Actions

Management

DatabaseIOTA-DM ServerNetworkIOTA-DM ClientMS Management TreeUser

Notification Message

User Interaction

User Interaction

RRC, Network Connection

Setup phase

Management phase

2

Figure 4.4-1 Network Initiated Scenario 3

Network-initiated management session begins with a trigger message, which is the OMA 4

DM Package #0 message originating from the IOTA-DM Server. This trigger is an XML 5

document sent over mobile terminated SMS described in section 3.6. On receiving the 6

trigger, the IOTA-DM Client may require user interaction. Network connection is 7

established if a connection does not exist. The IOTA-DM Client responds to the trigger 8

with OMD DM Package #1 message, which includes credentials of the Client and the 9

CDMADevInfo described in section 5.1 in addition to the OMA DevInfo [7]. The 10

management session shall continue with IOTA-DM Server sending OMA DM Package #2 11

with the credentials of the server and initial management actions. A management action 12

can result in reading, writing, replacing, or creating a management object, node or subtree 13

of the MS Management tree. The sequence of messages exchanged between the IOTA-14

DM Server and IOTA-DM Client during the management phase shall follow the same 15

procedure as in OMA DM Protocol [5], except that the management objects referenced in 16

the commands should be the CDMA Management Objects specified in section 5 of this 17

3GPP2 C.S0064-0 v2.0

4-5

document. All phases of a management session requires the IOTA-DM Client to access 1

the MS Management Tree. The MS Management Tree shall contain the CDMA 2

management objects described in section 5 as a subtree. The CDMA Management objects 3

shall be addressed using the URI names specified in section 5 of this document. 4

As an example, in order to create, update or read the CDMA PRL stored in the MS, 5

corresponding command originating from the IOTA-DM Server uses the URI name specified 6

in section 5.2.7 to address the CDMA PRL. 7

4.5 MS Initiated Scenario 8

In the MS-initiated session, either the user or an internal trigger can initiate a connection 9

to the server. An internal application or service can trigger a notification message, which 10

acts similar to a notification originating from the server. Another example is trigger based 11

on a timer expiry. 12

Package #3: Client Responses

Package #4: More Management

Actions

Management

DatabaseIOTA-DM ServerNetworkIOTA-DM ClientMS Management TreeUser

Package #1: Credentials and CDMA

DevInfo

Internal Trigger

User Interaction

Package #2: Server Credentials and

Initial Management Actions

RRC, Network Connection

User Interaction

Setup Phase

Management Phase

13

14

Figure 4.5-1 Client Initiated Scenario 15

3GPP2 C.S0064-0 v2.0

4-6

1

User interaction or trigger should cause the IOTA-DM Client to start a management 2

session. This results in establishing a data connection to the network if a connection 3

does not exist. The session should begin with the IOTA-DM Client sending OMA DM 4

Package #1message to the IOTA-DM Server. The Package #1 message should include 5

CDMADevInfo Management Object in addition to the Management Objects required for an 6

OMA DM Session as described in [5] and [7]. The setup phase and management phase in 7

the figure 4.5-1 should follows the same procedures as the network initiated scenario 8

described in section 4.4. 9

3GPP2 C.S0064-0 v2.0

5-1

5 CDMA MANAGEMENT TREE 1

This section defines the management tree that shall be used for managing CDMA mobile 2

stations using IOTA-DM. 3

5.1 CDMA DevInfo 4

A typical OTA management session has two phases, the initial setup phase and the 5

management phase. In the setup phase, the client should send the credentials and 6

DevInfo to the server. This enables the server to authenticate the client and tailor the 7

contents to meet the device requirements. 8

The DevInfo tree defines the device information [7], which is a set of parameters 9

describing the capabilities of the device. The mobile station shall send CDMA DevInfo to 10

the server at the beginning of an IOTA-DM session. The server learns the capabilities of 11

the device through CDMA DevInfo. The generic structure of DevInfo for OMA DM is 12

specified in [7]. This section describes only the CDMA specific delta. CDMA DevInfo 13

should include information about OTA protocols supported. The CDMA DevInfo subtree 14

should be placed under the DevInfo node of the Management Tree [7]. 15

The management tree structure for CDMA objects in DevInfo is shown in figure 5.1-1. 16

DevInfo DevId

Bearer

CDMAProtPref

CDMAProtCap

CDMABandModCap

CDMADevInfo

17

Figure 5.1-1 CDMA DevInfo Subtree 18

19

5.1.1 DevId 20

URI: ./DevInfo/DevId 21

3GPP2 C.S0064-0 v2.0

5-2

Description: Fixed Identifier of the Device. This can be 32 bit Electronic Serial 1

Number (ESN) or other CDMA device identifiers like Mobile Equipment Identity 2

(MEID). 3

Occurrence: One 4

Scope: Permanent 5

Access Type: Get 6

Format: char 7

5.1.2 CDMAProtPref 8

URI: ./DevInfo/Bearer/CDMA/CDMAProtPref 9

Description: Specifies the protocol preference. For management using Meta 10

element in the OMA DM Representation protocol, as specified in section 7, the 11

CDMAProtPref is set to ‘0’. Otherwise CDMAProtPref is set to ‘1’. This parameter 12

provides backward compatibility in systems that support features (e.g. already 13

deployed Over the Air Function (OTAF) equipment mentioned in the standards) as 14

specified in [2]. Using this parameter will enable the server to decide the mode of 15

management currently preferred in the device for managing CDMA settings. 16

Occurrence: One 17

Scope: Permanent 18

Access Type: Get, Replace 19

Format: Bool 20

5.1.3 CDMAProtCap 21

URI: ./DevInfo/Bearer/CDMA/CDMAProtCap 22

Description: This node specifies the OTASP/OTAPA features supported by the 23

MS. Refer to section 3.5.1.7-1 of [2]. 24

This object is included to provide backward compatibility with the CDMA standards. 25

Occurrence: One 26

Scope: Permanent 27


Format: b64 29

5.1.4 CDMABandModCap 30

URI: ./DevInfo/Bearer/CDMA/CDMABandModCap 31

Description: The mobile device shall set this field to indicate band and mode 32

capabilities supported by the mobile device. Refer to Table 3.5.1.7-2 of [2]. The 33

object value has size 8 bits. 34

Occurrence: One 35

3GPP2 C.S0064-0 v2.0

5-3

Scope: Permanent 1


Format: b64 3

5.2 CDMA Operational Parameters 4

These parameters are required for the provisioning and management of service in CDMA 5

mobile stations. The CDMA node shall represent the root node for all CDMA 6

parameters.7

AmpsNam

ID:<Y>

ID:<X>

CdmaNam

CDMAOpParamCDMA

AcqRecTab AcqRecEntry

SysRecEntrySysRecTab

PrefRoamList

SSPR PrefRoamDim

ExPrefRoamDim

ExAcqRecTab ExAcqRecEntry

ExSysRecEntryExSysRecTab

ExPrefRoamList

MobDirNum

ImsiT

ComSubnetTabPUZL

SysTag

8

9

Figure 5.2-1 CDMA Operational Parameters Management Objects 10

11

5.2.1 CDMA 12

Description: This interior node groups together parameters for cdma2000 systems. This 13

node acts as the root node for all parameters described in subsequent sections in this 14

specification. The type of this node MUST be the IOTA-DM Management Object Identifier 15

(MOI) ' urn:oma:mo:ext-3gpp2-iotadm:1.0’. 16

3GPP2 C.S0064-0 v2.0

5-4

Occurrence: One 1

Scope: Permanent 2

Access Type: Get 3

Format: node 4

5.2.15.2.2 CMDA OpParam 5

6

Description: CDMA OpParam (CDMA Operational Parameters) node is a parent to 7

all CDMA Operational settings. 8

Occurrence: One 9

Scope: Permanent 10

Access Type: Get 11

Format: Node 12

5.2.25.2.3 ./CDMA/CDMAOpParam/MobDirNum 13

14

MobDirNum 15

MDN node is a parent to all CDMA Mobile Directory Number (MDN) settings 16

Description: This node is a parent to all CDMA MDN objects 17

Occurrence: One 18

Scope: Permanent 19


Format: b64 21

5.2.35.2.4 ./CDMA/CDMAOpParam/AmpsNam 22

AmpsNam 23

Description: AmpsNam node is used to define the NAM for Analog mode. 24

Occurrence: One 25

Scope: Permanent 26


Format: b64 28

5.2.45.2.5 ./CDMA/CDMAOpParam/CdmaNam 29

CdmaNam 30

Description: CdmaNam node is used to define the Number Assignment Module for 31

CDMA mode. The format of the parameter block is defined in section 3.5.2.3 of [2] 32

Occurrence: One 33

Scope: Permanent 34

3GPP2 C.S0064-0 v2.0

5-5

Access Type: Get 1

Format: Node 2

5.2.55.2.6 ./CDMA/CDMAOpParam/CDMANAM/y+ 3

CDMANAM/y+ 4

Description: y+ stands for the instance of Object defined under it. There can be 5

one or more CDMA NAM settings in a CDMA device. NAM settings in CDMA devices 6

are defined in section 3.5.2 of [2]. 7

Occurrence: One or more 8

Scope: Dynamic 9


Format: Node 11

5.2.65.2.7 ./CDMA/CDMAOpParam/ImsiT 12

ImsiT 13

Description: The IMSI_T parameter is defined in section 3.5.2.4 of [2]. 14

Occurrence: One 15

Scope: Permanent 16

Access Type Get, Replace 17

Format: b64 18

5.2.75.2.8 ./CDMA/CDMAOpParam/SSPR 19

Description: The SSPR is the parent node common to all System Selection and 20

Preferred Roaming Management Objects defined in section 3.5.3 of [2]. SSPR node 21

carries the management objects for Preferred Roaming List and Extended Preferred 22

Roaming List. 23

Occurrence: One 24

Scope: Permanent 25


Format: Node 27

5.2.85.2.9 ./CDMA/CDMAOpParam/PrefRoamList 28

Description: The preferred roaming list (PRL) contains information to assist the 29

mobile station system selection and acquisition process, particularly when the 30

mobile station is roaming. The server creates this object and sets the values of 31

parameters in this object. Section 3.5.5 of [2] defines the PRL and the parameters 32

in the PRL block. 33

Occurrence: One 34

3GPP2 C.S0064-0 v2.0

5-6

Scope: Permanent 1


Format: b64 3

5.2.95.2.10 ./CDMA/CDMAOpParam/PrefRoamListDim 4

Description: This management object represents the dimensions of the Preferred 5

Roaming List as specified in section 3.5.5 of [2]. 6

Occurrence: One 7

Scope: Permanent 8


Format: b64 10

5.2.105.2.11 ./CDMA/CDMAOpParam/ExPrefRoamList 11

Description: The Extended Preferred Roaming list corresponds to SSPR_P_REV 12

greater than or equal to ‘00000010’ as defined in Section 3.5.5 of [2]. 13

Occurrence: One 14

Scope: Permanent 15


Format: b64 17

5.2.115.2.12 ./CDMA/CDMAOpParam/ExPrefRoamListDim 18

Description: This management object represents the dimensions of the Extended 19

Preferred Roaming List as specified in section 3.5.5 of [2]. 20

Occurrence: One 21

Scope: Permanent 22


Format: b64 24

5.2.125.2.13 ./CDMA/CDMAOpParam/PUZL 25

Description: Management Object representing Preferred User Zone List (PUZL) as 26

specified in Section 3.5.6 of [2]. 27

Occurrence: One 28

Scope: Permanent 29


Format: b64 31

3GPP2 C.S0064-0 v2.0

5-7

5.2.135.2.14 ./CDMA/CDMAOpParam/SysTag 1

Description: Management Object representing System Tag Parameter Block as 2

specified in Section 3.5.10 of [2]. 3

Occurrence: One 4

Scope: Permanent 5


Format: b64 7

5.3 MOID for CDMA MO 8

A Management Object Identifier or MOID uniquely identifies a Management Object. The 9

rules for forming an MOID are described in section 7.7.7.2 of [7]. 10

The MOID for the CDMA MO shall be: urn:oma:mo:ext-3gpp2-iotadm:1.0. 11

This MOID is defined in OMNA DM Management Object website. 12

5.35.4 CDMA Packet Data Objects 13

This section describes the management objects used for managing packet data service. 14

3GPP2 C.S0064-0 v2.0

5-8

ID:<NAI>

CDMAAP 3GPDOPC

3GPDOPM

SIP SIPCAP

SIPSP

3GPD

SIPUPP

SIPPSS

SIPCSS

MIP MIPCAP

MIPSP

MIPUPP

MIPSS

ID:<NAI>

SIPUPPS

MIPUPPS

CDMA

1

3GPDCDMA CDMAAP

HRPDAACHAP

HRPDAAUPPHRPD

2

Figure 5.3-1 CDMA Packet Data Management Objects 3

4

5.3.15.4.1 CDMAAP 5

Description: CDMAAP (CDMA Access Point) node is a parent to all CDMA objects for 6

data services. 7

3GPP2 C.S0064-0 v2.0

5-9

Occurrence: One 1

Scope: Permanent 2

Access Type: Get 3

Format: Node 4

5.3.25.4.2 ./CDMAAP/3GPD 5

3GPD 6

Description: 3GPD node is a parent to all CDMA Packet Switched Data objects 7

defined in [2]. 8

Occurrence: One 9

Scope: Permanent 10

Access Type: Get 11

Format: Node 12

5.3.2.15.4.2.1 ./CDMAAP/3GPD/3GPDOCP 13

./3GPDOCP 14

Description: 3GPDOCP node is a parent to all 3GPD Operation Capability 15

Parameter objects. Operation Mode Bitmap to indicate which operation modes are 16

supported by the mobile station. The mobile device shall use the table in section 17

3.5.8.1 of [2]. 18

Occurrence: One 19

Scope: Permanent 20

Access Type: Get 21

Format: Node 22

5.3.2.25.4.2.2 ./CDMAAP/3GPD/3GPDOMP 23

./3GPDOMP 24

Description: 3GPDOMP node is a parent to all 3GPD Operation Mode Parameter 25

objects. This can be one of Mobile IP, Simple IP, Mobile IP with Simple IP fall back. 26

The mobile station shall set this field to the active operation mode in the mobile 27

station as specified in Table 3.5.8.2-1 of [2]. 28

Occurrence: One 29

Scope: Permanent 30

Access Type: Get 31

Format: Node 32

3GPP2 C.S0064-0 v2.0

5-10

5.3.2.35.4.2.3 ./CDMAAP/3GPD/SIP 1

SIP 2

Description: Parent to all Simple IP objects. 3

Occurrence: One 4

Scope: Permanent 5

Access Type: Get 6

Format: Node 7

5.3.2.45.4.2.4 ./CDMAAP/3GPD/MIP 8

MIP 9

Description: Parent to all Mobile IP objects. 10

Occurrence: One 11

Scope: Permanent 12

Access Type: Get 13

Format: Node 14

5.3.2.55.4.2.5 ./CDMAAP/3GPD/HRPD 15

Description: Parent to all HRPD objects. 16

Occurrence: One 17

Scope: Permanent 18

Access Type: Get 19

Format: Node 20

5.45.5 CDMA MMD Management Object 21

This section defines the MMD management object. 22

3GPP2 C.S0064-0 v2.0

5-11

IMPILength

IMPI

MMDCDMA

ID:<IMPUEntryIndex>

NumIMPU

IMPU

SIPURILength

ID:<PCSCFEntryIndex> PCSCFAdd

SIPDomainURI

NumPCSCF

1

2

Figure 5.4-1 CDMA MMD Management Object 3

4

5.4.15.5.1 ./CDMA/MMD 5

MMD 6

Description: Parent node for all MMD management objects based on MMD 7

parameters specified in [2]. 8

Occurrence: One 9

Scope: Permanent 10


Format: Node 12

5.4.25.5.2 ./CDMA/MMD/IMPILength 13

IMPILength 14

Description: IMS Private Identity Length 15

Occurrence: One 16

3GPP2 C.S0064-0 v2.0

5-12

Scope: Permanent 1


Format: b64 3

5.4.35.5.3 ./CDMA/MMD/IMPI 4

IMPI 5

Description: IMS Private Identity. 6

Occurrence: One 7

Scope: Permanent 8


Format: b64 10

5.4.45.5.4 ./CDMA/MMD/NumIMPU 11

NumIMPU 12

Description: Number of IMS public entries. 13

Occurrence: One 14

Scope: Permanent 15

Access Type: Get 16

Format: Node 17

5.4.55.5.5 ./CDMA/MMD/ImpuEntryIndex+ 18

ImpuEntryIndex+ 19

Description: ImpuEntryIndex+ stands for the instance of Object defined under it. 20

There can be one or more IMS Public Identity Entry. 21


Scope: Dynamic 23

Access Type: Get, Replace, Delete 24

Format: Node 25

5.4.65.5.6 ./CDMA/MMD/ImpuEntryIndex+/IMPU 26

IMPU 27

Description: IMS Public Identity. 28

Occurrence: One 29

Scope: Permanent 30

Access Type Get, Replace, Delete 31

3GPP2 C.S0064-0 v2.0

5-13

Format: b64 1

5.4.75.5.7 ./CDMA/MMD/SIPURILength 2

SIPURILength 3

Description: SIP Domain URI Length. 4

Occurrence: One 5

Scope: Permanent 6


Format: b64 8

5.4.85.5.8 ./CDMA/MMD/SIPDomainURI 9

SIPDomainURI 10

Description: SIP Domain URI. 11

Occurrence: One 12

Scope: Permanent 13


Format: b64 15

5.4.95.5.9 ./CDMA/MMD/NumPCSCF 16

NumPCSCF 17

Description: Number of PCSCF Entries. 18

Occurrence: One 19

Scope: Permanent 20

Access Type: Get, replace 21

Format: Node 22

5.4.105.5.10 ./CDMA/MMD/PCSCFEntryIndex+ 23

PCSCFEntryIndex+ 24

Description: PCSCFEntryIndex+ stands for the instance of Object defined under it. 25

There can be one or more PCSCF Entry. 26


Scope: Dynamic 28


Format: Node 30

3GPP2 C.S0064-0 v2.0

5-14

5.4.115.5.11 ./CDMA/MMD/PCSCFEntryIndex+/PCSCFAdd 1

PCSCFAdd 2

Description: PCSCF address entry. 3

Occurrence: One 4

Scope: Permanent 5


Format: b64 7

5.55.6 CDMA System Tag Management Object 8

This section defines the System Tag management object. 9

HomeSysTag

GroupTagListDim

SysTagCDMA

GroupTagList

SpecificTagListDim

CallPromtList

SpecificTagList

CallPromtListDim

10

11

Figure 5.5-1 CDMA System Tag Management Object 12

5.5.15.6.1 ./CDMA/SysTag/HomeSysTag 13

HomeSysTag 14

Description: Home System Tag block as specified in [2]. 15

3GPP2 C.S0064-0 v2.0

5-15

Occurrence: One 1

Scope: Permanent 2


Format: b64 4

5.5.25.6.2 ./CDMA/SysTag/GroupTagListDim 5

GroupTagListDim 6

Description: Group Tag List Dimensions Paramater block as specified in [2]. 7

Occurrence: One 8

Scope: Permanent 9


Format: b64 11

5.5.35.6.3 ./CDMA/SysTag/GroupTagList 12

GroupTagList 13

Description: Group Tag List block as specified in [2]. 14

Occurrence: One 15

Scope: Permanent 16


Format: b64 18

5.5.45.6.4 ./CDMA/SysTag/SpecificTagListDim 19

SpecificTagListDim 20

Description: Specific Tag List Dimensions block as specified in [2]. 21

Occurrence: One 22

Scope: Permanent 23


Format: b64 25

5.5.55.6.5 ./CDMA/SysTag/SpecificTagList 26

SpecificTagList 27

Description: Specific Tag List as specified in [2]. 28

Occurrence: One 29

Scope: Permanent 30


3GPP2 C.S0064-0 v2.0

5-16

Format: b64 1

5.5.65.6.6 ./CDMA/SysTag/CallPromptListDim 2

CallPromptListDim 3

Description: Call Prompt Tag List Dimensions block as specified in [2]. 4

Occurrence: One 5

Scope: Permanent 6


Format: b64 8

5.5.75.6.7 ./CDMA/SysTag/CallPromptList 9

CallPromptList 10

Description: Call Prompt List block as specified in [2]. 11

Occurrence: One 12

Scope: Permanent 13


Format: b64 15

16

5.65.7 CDMA MMS Management Object 17

This section describes the management object used for managing MMS. 18

3GPP2 C.S0064-0 v2.0

5-17

NumMMSURIMMSCDMA

ID:<MMSURIEntryIndex> MMSURI

MMSCap MaxNumMMSURI

MaxMMSURILength

1

2

Figure 5.6-1 CDMA MMS Management Object 3

5.6.15.7.1 ./CDMA/MMS 4

MMS 5

Description: Parent node for all MMS management objects based on MMS 6

parameters specified in [2]. 7

Occurrence: One 8

Scope: Permanent 9


Format: Node 11

5.6.25.7.2 ./CDMA/MMS/NumMMSURI 12

NumMMSURI 13

Description: Number of MMS URI Entries. 14

Occurrence: One 15

Scope: Permanent 16

3GPP2 C.S0064-0 v2.0

5-18


Format: b64 2

5.6.35.7.3 ./CDMA/MMS/MMSURIEntryIndex+ 3

MMSURIEntryIndex+ 4

Description: MMSURIEntryIndex+ stands for the instance of Object defined under 5

it. There can be one or more MMS URI entries. 6


Scope: Dynamic 8


Format: Node 10

5.6.45.7.4 ./CDMA/MMS/MMSURIEntryIndex+/MMSURI 11

MMSURI 12

Description: MMS URI Entry. 13

Occurrence: One 14

Scope: Dynamic 15


Format: b64 17

5.6.55.7.5 ./CDMA/MMS/MMSCap/ 18

MMSCap 19

Description: MMS Capabilities node. 20

Occurrence: One 21

Scope: Permanent 22


Format: Node 24

5.6.65.7.6 ./CDMA/MMS/MMSCap/MaxNumMMSURI 25

MaxNumMMSURI 26

Description: Maximum Number of MMS URI Entries. 27

Occurrence: One 28

Scope: Permanent 29


Format: b64 31

3GPP2 C.S0064-0 v2.0

5-19

5.6.75.7.7 ./CDMA/MMS/MMSCap/MaxMMSURILength 1

MaxMMSURILength 2

Description: Maximum MMS URI Length. 3

Occurrence: One 4

Scope: Permanent 5


Format: b64 7

8

3GPP2 C.S0064-0 v2.0

5-20

This page intentionally left blank. 1

3GPP2 C.S0064-0 v2.0

6-1

6 IOTA-DM SECURITY 1

This section describes the security mechanism in the DM framework and the updating of 2

CDMA specific security parameters. 3

6.1 Access Control and Security 4

OMA DM framework provides security at several levels: 5

• Access control mechanism to control the access to management objects 6

• Protocol security mechanism to ensure confidentiality of data 7

• Ensuring the integrity of the data 8

• Authentication between the mobile device and the management server. 9

The access control mechanism defined in OMA DM standards controls access to 10

parameters and management objects in the mobile device. Only the management server 11

with appropriate rights shall modify the management objects. Since the management 12

objects are organized as a tree, it is possible to define access control list (ACL) to the node 13

and leaf objects in the management tree to describe who has the access to e.g. modify or 14

delete an object in the management tree. The ACL applies on a per-command basis to 15

any node or leaf in the management tree. 16

Confidentiality ensures that only the intended recipient can interpret the contents of a 17

management message. Authentication is achieved through the exchange of credentials in 18

a secure way. Either the client or the server may send credentials to each other or 19

challenge the other to send them. 20

Integrity of management data transferred between the device and the server is important, 21

since deliberate or accidental corruption data can occur. Integrity of OMA DM data is 22

achieved using a hashed message authentication code used on each message. 23

OMA DM security mechanism is defined in the Security specification [10] shall be followed 24

for IOTA-DM Security. 25

6.2 OTA Update of A-Key and other Critical Parameters 26

In CDMA mobile stations, the A-Key is established using OTASP/OTAPA. This section 27

describes the method for updating A-Key in CDMA mobile stations using the DM 28

framework. The approach should be followed for the updating of other critical parameters 29

in the MS, which are not accessible using normal methods. A-Key is a critical parameter 30

which is known only to the Authentication Center (AC) and the mobile station. 31

6.2.1 A-Key and Root Key Generation 32

This approach shall be followed for A-Key and Root Key establishment using DM protocol. 33

The message flow explained in this section assumes that the server knows the A-Key 34

version [2]. The “Exec” command is executed on a special node in the MS Management 35

Tree. This node corresponds to the A-Key in the MS. Since A-Key is stored only in the MS 36

permanent storage or in the R-UIM/UICC, this node in the management tree is a dummy 37

3GPP2 C.S0064-0 v2.0

6-2

node, which need not store the value of A-Key, but points to process which the “Exec” 1

command should execute upon receiving the “IOTA-DM Key Generation Request 2

Message”. When OTASP/OTAPA as specified in [2] is supported, this process is a client 3

running in the MS for handling the protocol specified in [2]. The data in the “Key Request 4

Message” received at the IOTA-DM Client can be stored in a temporary leaf node of the A-5

Key node, from where the invoked A-Key client can access it. 6

The sequence below explains how the A-Key is established through IOTA-DM messages. 7

8

MS Mgmt

Tree

IOTA-DM

ServerIOTA-DM Client

14. Permanent Storage

3. Package #2: Key Request Msg

15. Package #3:Commit Response

1. Package #0: Notification

2. Package #1: MS Capability Msg

6. Computes MS_RESULT

7. Computes BS_RESULT8. Package #4: Key Gen. Request Msg

6. Package #3: Key Response Msg

11. Package #3: Key Gen. Response Msg

12. Computes A-Key

13. Package #4: Commit

MS A-Key

Client

4. Executes the Command

in Step 35. Access the node, invoke process.

10. Computes A-KEY

9. Pass BS_RESULT

9

10

Figure 6.2.1-1 Key Generation using DM Protocol 11

12

1. The IOTA-DM server shall begin a notification-initiated session by sending a 13

standard package #0 notification message. 14

2. The IOTA-DM client shall respond with package #1 carrying the MS capability 15

information. 16

3. The IOTA-DM server shall create a package #2 message, which includes the IOTA-17

DM Server capabilities and a command with ’cdma/a-key/keyreq’ as the target 18

node. The message includes the input parameter block used in Key Request 19

message specified in section 4.5.1.3 of [2]. This block should start at the 20

3GPP2 C.S0064-0 v2.0

6-3

OTASP_MSG_TYPE and end at PARAM_G as specified in section 4.5.1.3 of [2]. The 1

input parameter is included in the data element of the command as b64 encoded 2

binary data. Figure 6.2.1-2 shows an example of the package #2 message. 3

4. On receiving the package #2, the IOTA-DM client shall invoke the mobile station 4

A-key client. The mobile station A-key client is shown in figure 6.2.1-1 is only for 5

explaining the sequence. In an implementation it can be a function integrated to 6

the IOTA-DM Client. The parameters from the message received in step 3 shall be 7

provided as input parameters to the A-key client. 8

5. The A-key client shall compute the MS_RESULT parameter following the methods 9

specified in section 5 of [2] based on the A_KEY_P_REV received in step 4. 10

6. The fixed length binary data specified in 3.5.1.3 of [2], which includes 11

OTASP_MSG_TYPE and result code specified in section 3.5.1.2-1 of [2], shall be 12

sent in the data element of package #3 as a response to the package #2 message 13

in step 3 following normal OMA DM procedure (see figure 6.2.1-3). This shall be the 14

standard OMA DM Results command with source URI specified as ‘cdma/a-15

key/keyreq’. The Status Element in the DM Response shall be 200 when the 16

command in step 3 is completed successfully. Otherwise appropriate status code 17

defined in [21] shall be used. 18

7. On receiving the status and result code from the IOTA-DM Client, the IOTA-DM 19

Server shall compute the BS_RESULT (see the base station procedures in section 5 20

of [2]). 21

8. The IOTA-DM Server shall send the BS_RESULT to the IOTA-DM client in package 22

#4 message including it in the data element of the command. The fixed format 23

binary data beginning with OTASP_MSG_TYPE and ending with BS_RESULT, as 24

specified in section 4.5.1.4 of [2] shall be included in the data element in b64 25

encoded form. The target URI for the command shall be ‘cdma/a-key/keygen’. The 26

same message shall include a command to request the MS_RESULT. An example is 27

shown in figure 6.2.1-4. 28

9. The IOTA-DM client shall pass the parameters to the A-Key Client in the MS. 29

10. The A-Key client in the MS shall compute the A-KEY or Root Key following the 30

mobile station procedures described in section 5 of [2], based on input parameters 31

in step 4 and the BS_RESULT from step 8. The value can be stored in a temporary 32

location in the A-Key node of the management tree. 33

11. The IOTA-DM client shall send the MS_RESULT computed in step 5 to the IOTA-34

DM Server in a new package #3 message as a response to the Package #4 message 35

in step 8. The fixed format binary data specified in section 3.5.1.4 of [2], which 36

includes MS_RESULT, shall be sent in the data element of the DM Results 37

command. Example of DM Results command is shown in figure 6.2.1-5. 38

12. On receiving the MS_RESULT, the IOTA-DM Server shall compute the A-Key or 39

Root Key based on the MS_RESULT, following the base station procedures in 40

section 5 of [2]. 41

3GPP2 C.S0064-0 v2.0

6-4

13. The DM Server shall send a package #4 message to the IOTA-DM Client as a 1

response to the command in step 11 with status code set to 200 indicating 2

completion. 3

14. On receipt of the status code, the IOTA-DM client shall store the A-Key stored in 4

temporary node of the management tree to the permanent memory and removes 5

the A-Key and intermediate values from temporary storage in nodes. 6

15. The IOTA-DM client shall send the status in a response message. 7

8

<Exec>

<MsgRef><!-message ref></MsgRef><CmdRef><!-command ref></CmdRef><CmdID><!-command id></CmdID> <Meta>

<Format xmlns="syncml:metinf">b64</Format> <Type xmlns="syncml:metinf">bin</Type>

</Meta> <Item>

<Target> <LocURI>./cdma/a-key/keyreq</LocURI>

</Target> <Data><!--data block from Key Request message specified in section 4.5.1.3 of [2]></Data>

</Item> </Exec>

Figure 6.2.1-2 Command in Package #2 9

10

<Results>



</Meta> <Item>

<Source> <LocURI>./cdma/a-key/keyreq</LocURI>

</Source> <Data><!-b64 encoded RESULT data></Data>

</Item> </Results>

Figure 6.2.1-3 Example of Results Command in Package #3 11

12

13

<Replace>

<MsgRef><!-message ref></MsgRef><CmdRef><!-command ref></CmdRef><CmdID><!-command id></CmdID>

3GPP2 C.S0064-0 v2.0

6-5

<Meta> <Format xmlns="syncml:metinf">b64</Format>

<Type xmlns="syncml:metinf">bin</Type> </Meta> <Item>

<Target> <LocURI>./cdma/a-key/keygen/bs-result</LocURI>

</Target> <Data><!---include BS_RESULT data here></Data>

</Item> </Replace>

1

<Get>

<MsgRef><!-message ref></MsgRef><CmdRef><!-command ref></CmdRef><CmdID><!-command id></CmdID> <Item>

<Target> <LocURI>./cdma/a-key/keygen/ms-result</LocURI>

</Target> </Item>

</Get>

Figure 6.2.1-4 Commands in Package #4 2

3

4

<Results>



</Meta> <Item>

<Source> <LocURI>./cdma/a-key/keygen/ms-result</LocURI>

</Source> <Data><!-b64 encoded MS_RESULT data></Data>

</Item> </Results>

Figure 6.2.1-5 Example of Results Command 5

6.2.2 Service Key Generation 6

The IOTA-DM Server shall send the command shown in figure 6.2.2-1 to request Service 7

Key generation. The data in the command is the KEY ID specified in section 4.5.1.22 of [2], 8

which is in the form of a bitmap based on table 4.5.1.22-1 of [2]. The mobile station shall 9

generate the Service Key following the procedures specified in section 3.3.9 of [2] for each 10

KEY ID requested. The IOTA-DM Client shall send normal DM response to the IOTA-DM 11

server. 12

3GPP2 C.S0064-0 v2.0

6-6

1

<Exec>



</Meta> <Item>

<Target> <LocURI>./cdma/service-key</LocURI>

</Target> <Data><!--KEY ID specified in section 4.5.1.22 of [2]></Data>

</Item> </Exec>

Figure 6.2.2-1 Command for Service Key Generation 2

3

When the CDMAProtPref defined in section 5.1.2 is set to ‘0’ (OTASP/OTAPA [2] over 4

IOTA-DM mode), Service Keys specified in [2] shall be managed using the method 5

described in section 6.2.4. 6

6.2.3 SSD Update 7

The mobile station shall perform SSD update after step 12 of the procedure in section 8

6.2.1. The procedure specified in section 3.3.2 of [2] shall be followed for SSD update. 9

Steps 13 to 15 are performed and the A_Key is stored in permanent memory after 10

successful SSD update. 11

6.2.4 Establishing A-Key using DM when OTASP/OTAPA support exists 12

This approach may be followed when OTASP/OTAPA [2] client and server exists. In this 13

approach, the A-Key should be represented by a node in the management tree, but the 14

node need not store the actual value of A-Key, and can point to a client in the MS for 15

handling messages as specified in [2]. The Exec command in DM should be used to invoke 16

the OTASP/OTAPA process for this client. 17

18

3GPP2 C.S0064-0 v2.0

6-7

MS Mgmt

Tree

IOTA DM

Server

Wireless Network/

OTASP/OTAPA

Server

MS

IOTA-DM Client

2. Notification: A-KEY GEN

3. MS Capability Msg

12. Computes BS_RESULT

19. Computes A-Key

A-Key/

OTASP/OTAPA Client

5. Executes the Exec Command

1. Key Request Msg

6. Invokes OTASP/OTAPA Client

7. Computes MS_RESULT

8. Key Response Msg 10. Key Response Msg

11. Key Gen. Request Msg

13. Invokes OTASP/OTAPA Client

15. Key Gen. Response Msg

18. Commit

23. Commit Response

4. IOTA-DM Key Request Message

9. IOTA-DM Key Response Message

12. IOTA-DM Key Gen. Request Message

16. IOTA-DM Key Gen. Response Message17. Key Gen. Response Msg

19. IOTA-DM Commit

22. IOTA-DM Commit Response21. Commit Response

Executes the Exec Command

20. Invokes OTASP/OTAPA Client Executes the Exec Command

14. Computes A-KEY

Setup Phase

1

2

Figure 6.2.4-1 Flow Diagram for A-Key Establishment 3

The message flow explained below assumes that the server knows the A-Key version and 4

the version of the OTASP/OTAPA protocol [2]. 5

The Server in the network should initiate the A-Key update procedure by issuing a “Key 6

Request Message” as described in [2]. The sequence described below should be followed. 7

The OTA-DM Server intercepts the message. The Server then sends a notification to the 8

DM client in the MS. This message is the package #0 in the DM protocol, which acts as a 9

trigger in the setup phase of a DM session. This trigger can carry the identification “A-KEY 10

GEN”, by which the MS DM Client identifies it as a trigger to begin the updating of A-Key. 11

The MS DM Client responds with “MS Capability Message”. This is a standard package #1 12

message in the DM protocol, but for the specific purpose of A-Key update, this message 13

may carry parameters to identify the CDMA capabilities of the MS as specified in DevInfo in 14

section 5.1. For example, the CDMAProtPref parameter in Devinfo. 15

On receiving the “MS Capability Message”, the IOTA-DM server knows which scenario to 16

be followed, i.e. whether the MS supports OTASP/OTAPA processes as specified in [2]. 17

The IOTA-DM Server creates a new message “IOTA-DM Key Request Message by 18

encapsulating the “Key Request message” originated from the server as well as additional 19

commands specific to DM usage. 20

3GPP2 C.S0064-0 v2.0

6-8

One additional command is the standard “Exec” command in the DM protocol. But here 1

the “Exec” command is executed on a special node in the MS Management Tree. This 2

node corresponds to the A-Key in the MS. Since A-Key is stored only in the MS permanent 3

storage or in the R-UIM/UICC, this node in the management tree is a dummy node, which 4

need not store the value of A-Key, but points to process which the “Exec” command 5

should execute upon receiving the “IOTA-DM Key Generation Request Message”. When 6

OTASP/OTAPA as specified in [2] is supported, this process is a client running in the MS 7

for handling the protocol specified in [2]. The data in the “Key Request Message” received 8

at the IOTA-DM Client can be stored in a temporary leaf node of the A-Key node, from 9

where the invoked MS client can access it. 10

On receiving the “IOTA-DM Key Request Message” the MS DM Client executes the 11

commands specified in the message. This involves executing the “Exec” command on the 12

A-Key node in the Management Tree, which results in invoking and passing the 13

encapsulated “Key Generation Request Message” to the MS Client. 14

The MS Client calculates the MS_RESULT parameter based on the input parameters in 15

the encapsulated message. The algorithm described in section 5.1 of [2] is followed for 16

calculating MS_RESULT. 17

The MS Client sends the “Key Response Message” which includes the status of the 18

MS_RESULT calculation. If an error occurred, the error code is sent in the response as 19

described in [2]. 20

The “Key Response Message” is intercepted by the IOTA-DM Client and encapsulated in a 21

DM protocol message called “IOTA-DM Key Gen. Response” Message. One way is to store 22

the “Key Response Message” in a temporary leaf node associated with the A-Key node in 23

the management tree from where the IOTA-DM client can access it for encapsulation. 24

The IOTA-DM Client sends the encapsulated “IOTA-DM Key Response Message” to the 25

IOTA-DM Server. 26

The IOTA-DM server forwards the encapsulated message to the Server. 27

The Server calculates the BS_RESULT following the algorithm in section 5.2 of [2] and 28

sends it to the MS in the “Key Generation Request message”. 29

The IOTA-DM Server encapsulates the “Key Generation Request Message” in a DM 30

Protocol message and sends it to the MS IOTA-DM Client in the “IOTA-DM Key 31

Generation Request”. This message also carries the “Exec” command to invoke the MS 32

client. 33

Executing the “Exec” command results in invoking the MS client process. 34

The OTASP/OTAPA MS client calculates the A-Key from the BS_RESULT. 35

The MS Client now sends the MS_RESULT calculated in step 6 in the “Key Generation 36

Response Message. The message is encapsulated in the IOTA-DM message. This can be 37

achieved through the MS client first storing the message in a temporary leaf node of the 38

A-Key node and then the IOTA-DM client accessing it. 39

The IOTA-DM server forwards the MS_RESULT to the Server. 40

3GPP2 C.S0064-0 v2.0

6-9

The server computes the A-Key. 1

The server issues a commit message. 2

The IOTA-DM server directs the commit message to the MS IOTA-DM client. 3

The MS IOTA-DM client invokes the MS client. On receiving the commit the MS Client 4

stores the A-Key in a permanent memory. 5

The MS client now sends a “Commit Response”. 6

The commit response is encapsulated in the “IOTA-DM Commit Response”. 7

The IOTA-DM server forwards the encapsulated message to the server. 8

6.3 Secure Mode Operation 9

When the CDMAProtPref defined in section 5.1.2 is set to ‘0’ (OTASP/OTAPA over IOTA-10

DM mode), secure mode as specified in [2] shall be enabled using the method described in 11

section 7. 12

13

3GPP2 C.S0064-0 v2.0

6-10

This page intentionally left blankNo text. 1

3GPP2 C.S0064-0 v2.0

7-1

7 HANDLING OF OTASP/OTAPA MESSAGES 1

This section describes how OTASP/OTAPA messages as defined in [2] shall be handled in 2

the IOTA-DM framework when the CDMAProtPref defined in section 5.1.2 is set to ‘0’. 3

The OTASP/OTAPA messaging should be handled using the Meta element of OMA DM 4

representation protocol [6]. 5

<Meta>

<Type xmlns=‘syncmlns’>syncml:cdma-is683</Type>

<Format xmlns=‘syncmlns’>b64</Format>

<Target><LocURI>./root/../cdma/is683</LocURI></Target>

<Data>IS-683 Message</Data>

</Meta>

6

Figure 7-1 Representation of OTASP/OTAPA Message 7

Figure 7-1 shows how OTASP/OTAPA message is represented using Meta element in the 8

OMA DM protocol. The XML content type is described by the Type element as 9

‘syncml:cdma-is683’ and the format is described as b64 using the Format Element. The 10

usage of Meta, Type, Format and other elements are described in OMA DM representation 11

protocol [6]. 12

The end-to-end messaging is shown in figure 7-2 shall be followed. 13

3GPP2 C.S0064-0 v2.0

7-2

OTASP/OTAPA Server/

OTAFIOTA-DM ServerWireless NetworkIOTA-DM ClientMS Client

OTASP/OTAPA Request Message

OMA DM

Representation

Using Meta

IOTA-DM Message

Extracts

Meta

Passes Meta data

OMA DM

Representation

Using Meta

OTASP/OTAPA Response

IOTA-DM Message

Extracts

Meta

OTASP/OTAPA Response Message

Management Tree

Access Management

Objects

1

Figure 7-2 Message Flow for Handling OTASP/OTAPA Message. 2

3

1. The IOTA-DM server intercepts the OTAPA message and encapsulates the 4

message in the OMA DM message using the Meta element described above. 5

2. The IOTA-DM client receives the message and identifies the Meta Type as 6

OTAPA message content. The content encoding can be specified in Meta using 7

the Format element. 8

3. The IOTA-DM client invokes the client in the MS and passes the Meta content 9

to the MS client. 10

4. The MS client processes the OTAPA message and sends the response. 11

5. The MS client can access the management tree to update the management 12

objects, which are the objects described in the management tree in section 5. 13

6. The response from MS Client, which is the OTAPA response is encapsulated 14

using Meta element and sent to the IOTA-DM server using OMA DM protocol. 15

7. The IOTA-DM server extracts the Meta content and deliver it to the OTAPA 16

server or the OTAF. 17

18

In step 3 above, the OTASP/OTAPA client can be invoked by specifying an ‘Exec’ command 19

[see section 3.5] in the OMA DM message, specifying the target of the command as a node 20

3GPP2 C.S0064-0 v2.0

7-3

in the management tree. The node name can be specified as the URI: ‘./root/…cdma/is-1

683’, which points to the MS client. 2

3

3GPP2 C.S0064-0 v2.0

7-4

This page intentionally left blankNo text. 1

3GPP2 C.S0064-0 v2.0

8-1

8 IOTA-DM FIRMWARE UPDATE OVER-THE-AIR 1

Firmware over-the-air (FOTA) is the process of updating mobile station firmware over-the-2

air. Primary use of firmware update capability is to rectify critical defects, that may 3

compromise the end user safety, through updating the firmware. It may be used to update 4

new version of firmware to the mobile station. 5

When firmware update capability is supported, the mobile station shall comply with the 6

specification [15] for managing the update. In addition, mobile station shall support CDMA 7

specific security mechanisms specified in section 8.1 of this document. 8

8.1 CDMA Specific Security Mechanisms for FOTA 9

In order to ensure consistency with the OTASP and OTAPA security mechanisms as 10

defined in [2], while updating the firmware or OTASP and OTAPA parameters, the mobile 11

station can use the following security mechanisms in addition to the requirements 12

specified in section 5.5 of this document. 13

• Mobile stations shall use Service Programming Lock (SPL) as specified in section 14

3.3.6 of [2]. 15

• Mobile stations shall use Subscriber Parameter Administration Security 16

Mechanism (SPASM) as specified in section 3.3.7 of [2] to protect the firmware. 17

18

19

3GPP2 C.S0064-0 v2.0

8-2

This page intentionally left blank.No Text.1

3GPP2 C.S0064-0 v2.0

A-1

ANNEX A DDF DESCRIPTION OF DEVINFO 1

The management tree and objects can be represented using the Device Description 2

Framework (DDF) [2]. As an example, the representation for CDMA DevInfo tree and 3

objects shown in Figure 5.1-1 is given below. 4

<MgmtTree> 5

<Node> 6

<NodeName>DevInfo</NodeName> 7

<DFProperties>…</DFProperties> 8

<Node> 9

<NodeName>DevId</NodeName> 10

<DFProperties> 11

<AccessType> </Get> </AccessType> 12

<DFormat>chr</DFormat> 13

<DFTitle>Unique Device Id</DFTitle> 14

</DFProperties> 15

<Value>…</Value> 16

</Node> 17

<Node> 18

<NodeName>Bearer</NodeName> 19

<DFProperties> 20


<DFTitle>Bearer Specific DevInfo</DFTitle> 22

</DFProperties> 23

<Node> 24

<NodeName>CDMA</NodeName> 25

<DFProperties> 26


<DFTitle>CDMA Specific DevInfo</DFTitle> 28

</DFProperties> 29

<Node> 30

<NodeName>CDMAProtPref</NodeName> 31

<DFProperties> 32

3GPP2 C.S0064-0 v2.0

A-2

<AccessType> </Get> <Replace/> </AccessType> 1

<DFormat>char</DFormat> 2

<DFTitle>Protocol Preference</DFTitle> 3

</DFProperties> 4


</Node> 6

<Node> 7

<NodeName>CDMAProvCap</NodeName> 8

<DFProperties> 9

<AccessType> </Get> </Replace> </AccessType> 10

<DFormat>b64</DFormat> 11

<DFTitle>Provisioning Capability</DFTitle> 12

</DFProperties> 13


</Node> 15

<Node> 16

<NodeName>CDMABanModCap</NodeName> 17

<DFProperties> 18

<AccessType> </Get> </Replace> </AccessType> 19

<DFormat>char</DFormat> 20

<DFTitle>Band Mode Capability</DFTitle> 21

</DFProperties> 22


</Node> 24

</Node> 25

</Node> 26

</Node> 27

</MgmtTree> 28

29

ip based over-the-air device management (iota- dm) for cdma2000

Documents