c.s0064-0 v1.0 050907

8/8/2019 C.S0064-0 v1.0 050907

1/64

3GPP2 C.S0064-0

Version 1.0

Date: September 06, 2005

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

1

2

3

4

Release 0

COPYRIGHT3GPP2 and its Organizational Partners claim copyright in this document and individualOrganizational Partners may copyright and issue documents or standards publications inindividual Organizational Partners name based on this document. Requests forreproduction of this document should be directed to the 3GPP2 Secretariat [email protected]. Requests to reproduce individual Organizational Partnersdocuments should be directed to that Organizational Partner. See www.3gpp2.org for moreinformation.

5

8/8/2019 C.S0064-0 v1.0 050907

2/64

Revision History1

2

Revision Description Date

C.S0064-0 Release 0 September, 2005

3

4

2005 3GPP2.

8/8/2019 C.S0064-0 v1.0 050907

3/64

3GPP2 C.S0064-0 v1.0

CONTENTS1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

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

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

1.2 Definitions ........................................................................................................ 1-2

1.3 General Requirements....................................................................................... 1-5

1.4 Protocol Requirements ......................................................................................1-6

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

4.4 Network Initiated Scenario ................................................................................ 4-34.5 MS Initiated Scenario........................................................................................ 4-5

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

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

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

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

iii

8/8/2019 C.S0064-0 v1.0 050907

4/64

3GPP2 C.S0064-0 v1.0

5.1.3 CDMAProtCap .......................................................................................... 5-21

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

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

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

5.2.1 CMDAOpParam........................................................................................ 5-3

5.2.2 ./CDMA/CDMAOpParam/MobDirNum MobDirNum................................5-4

5.2.3 ./CDMA/CDMAOpParam/AmpsNam........................................................ 5-4

5.2.4 ./CDMA/CDMAOpParam/CdmaNam........................................................ 5-4

5.2.5 ./CDMA/CDMAOpParam/CDMANAM/y+................................................. 5-4

5.2.6 ./CDMA/CDMAOpParam/ImsiT ............................................................... 5-5

5.2.7 ./CDMA/CDMAOpParam/SSPR............................................................... 5-5

5.2.8 ./CDMA/CDMAOpParam/PrefRoamList ................................................... 5-5

5.2.9 ./CDMA/CDMAOpParam/PrefRoamListDim............................................. 5-55.2.10 ./CDMA/CDMAOpParam/ExPrefRoamList ............................................... 5-6

5.2.11 ./CDMA/CDMAOpParam/ExPrefRoamListDim......................................... 5-6

5.2.12 ./CDMA/CDMAOpParam/PUZL ...............................................................5-6

5.2.13 ./CDMA/CDMAOpParam/SysTag.............................................................5-6

5.3 CDMA Packet Data Objects............................................................................... 5-7

5.3.1 CDMAAP................................................................................................... 5-8

5.3.2 ./CDMAAP/3GPD.....................................................................................5-8

5.3.2.1 ./CDMAAP/3GPD/3GPDOCP................................................................... 5-8

5.3.2.2 ./CDMAAP/3GPD/3GPDOMP.................................................................. 5-8

5.3.2.3 ./CDMAAP/3GPD/SIP .............................................................................5-9

5.3.2.4 ./CDMAAP/3GPD/MIP............................................................................. 5-9

5.3.2.5 ./CDMAAP/3GPD/HRPD .........................................................................5-9

5.4 CDMA MMD Management Object ...................................................................... 5-9

5.4.1 ./CDMA/MMD........................................................................................5-10

5.4.2 ./CDMA/MMD/IMPILength.................................................................... 5-10

5.4.3 ./CDMA/MMD/IMPI............................................................................... 5-11

5.4.4 ./CDMA/MMD/NumIMPU...................................................................... 5-11

5.4.5 ./CDMA/MMD/ImpuEntryIndex+............................................................ 5-11

5.4.6 ./CDMA/MMD/ImpuEntryIndex+/IMPU ................................................. 5-11

5.4.7 ./CDMA/MMD/SIPURILength ................................................................5-12

iv

8/8/2019 C.S0064-0 v1.0 050907

5/64

3GPP2 C.S0064-0 v1.0

5.4.8 ./CDMA/MMD/SIPDomainURI............................................................... 5-121

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

5.4.9 ./CDMA/MMD/NumPCSCF ................................................................... 5-12

5.4.10 ./CDMA/MMD/PCSCFEntryIndex+......................................................... 5-12

5.4.11 ./CDMA/MMD/PCSCFEntryIndex+/PCSCFAdd ...................................... 5-13

5.5 CDMA System Tag Management Object........................................................... 5-13

5.5.1 ./CDMA/SysTag/HomeSysTag ............................................................... 5-13

5.5.2 ./CDMA/SysTag/GroupTagListDim........................................................ 5-14

5.5.3 ./CDMA/SysTag/GroupTagList .............................................................. 5-14

5.5.4 ./CDMA/SysTag/SpecificTagListDim...................................................... 5-14

5.5.5 ./CDMA/SysTag/SpecificTagList ............................................................ 5-14

5.5.6 ./CDMA/SysTag/CallPromptListDim...................................................... 5-15

5.5.7 ./CDMA/SysTag/CallPromptList ............................................................ 5-155.6 CDMA MMS Management Object .................................................................... 5-15

5.6.1 ./CDMA/MMS........................................................................................5-16

5.6.2 ./CDMA/MMS/NumMMSURI.................................................................5-16

5.6.3 ./CDMA/MMS/MMSURIEntryIndex+....................................................... 5-17

5.6.4 ./CDMA/MMS/MMSURIEntryIndex+/MMSURI ....................................... 5-17

5.6.5 ./CDMA/MMS/MMSCap/ ...................................................................... 5-17

5.6.6 ./CDMA/MMS/MMSCap/MaxNumMMSURI........................................... 5-17

5.6.7 ./CDMA/MMS/MMSCap/MaxMMSURILength ....................................... 5-18

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

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

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

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

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

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

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

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

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

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

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

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

v

8/8/2019 C.S0064-0 v1.0 050907

6/64

3GPP2 C.S0064-0 v1.0

FIGURES1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

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

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

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

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

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

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

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

Figure 5.3-1 CDMA Packet Data Management Objects ....................................................5-7

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

Figure 5.5-1 CDMA System Tag Management Objects ...................................................5-13

Figure 5.6-1 CDMA MMS Management Objects .............................................................5-16

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

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

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

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

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

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

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

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

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

vi

8/8/2019 C.S0064-0 v1.0 050907

7/64

3GPP2 C.S0064-0 v1.0

NOTES1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

1. Compatibility, as used in connection with cdma20001, is understood to mean:

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

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

calls for cdma2000 and IS-95 mobile stations.2. The following verbal forms are used: Shall and shall not identify requirements

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

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

recommended as particularly suitable, without mentioning or excluding others;

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

the negative form) a certain possibility or course of action is discouraged but not

prohibited. May and need not indicate a course of action permissible within

the limits of the standard. Can and cannot are used for statements of

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

3. Footnotes appear at various points in this specification to elaborate and to furtherclarify items discussed in the body of the specification.

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

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

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

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

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

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

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

0xhh where hh represents a string of hexadecimal digits. For example, 0x2fa1

represents a number whose binary value is 0010111110100001 and whosedecimal value is 12193. Note that the exact number of bits in the binary

representation of a hexadecimal number strictly depends on the implementation

requirements for the variable being represented.

1cdma2000 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.

vii

8/8/2019 C.S0064-0 v1.0 050907

8/64

3GPP2 C.S0064-0 v1.0

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

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

switching center.

1

2

3

viii

8/8/2019 C.S0064-0 v1.0 050907

9/64

3GPP2 C.S0064-0 v1.0

REFERENCES1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

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

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

based upon this document are encouraged to investigate the possibility of applying the

most recent editions of the standards indicated below. ANSI and TIA maintain registers ofcurrently valid national standards published by them.

- Normative References:

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

Systems, June 2004.

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

Spectrum Systems, November 2004.

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

July 2003.

4. 3GPP2 S.R0101-0 1 IOTA Device Management for cdma2000 Systems Stage-1requirements, version 1.0, April 22 2004.

5. OMA Device Management Protocol, version 1.2, OMA, June 2005. URL

http://www.openmobilealliance.org/release_program/dm_v12.html17

18

19

20

21

22

23

24

25

26

27

28

6. OMA DM Representation Protocol, version 1.2, OMA, June 2005.

7. OMA DM Tree and Descriptions, version 1.2, OMA, June 2005.

8. OMA DM Bootstrap, version 1.2, OMA, June 2005.

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

10. OMA DM Security, version 1.2, OMA, June 2005.

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

2005.

12. OMA SyncML HTTP Binding, Version 1.2,OMA, June 2005.

13. OMA SyncML OBEX Binding, version 1.2, OMA, June 2005.

14. OMA SyncML WSP Binding, version 1.2, OMA, June 2005.

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

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

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

29

30

31

32

33

34

35

36

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

Version 6, October 2000.

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

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

Internet Message Bodies, November 1996.

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

ix
http://member.openmobilealliance.org/ftp/Public_documents/DM/Permanent_documents/http://member.openmobilealliance.org/ftp/Public_documents/DM/Permanent_documents/http://member.openmobilealliance.org/ftp/Public_documents/DM/Permanent_documents/http://member.openmobilealliance.org/ftp/Public_documents/DM/Permanent_documents/http://member.openmobilealliance.org/ftp/Public_documents/DM/Permanent_documents/http://member.openmobilealliance.org/ftp/Public_documents/DM/Permanent_documents/

8/8/2019 C.S0064-0 v1.0 050907

10/64

3GPP2 C.S0064-0 v1.0

20. IETF RFC 2616: HTTP 1.1.1

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

x

8/8/2019 C.S0064-0 v1.0 050907

11/64

3GPP2 C.S0064-0 v1.0

1 INTRODUCTION1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

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

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

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

configuration of multiple settings. Even with limited features of today, many customershave difficulty in configuring their mobile devices. Operators should ensure that phone

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

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

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

requires accurate mobile phone settings. The process of remotely managing device settings

and applications is called Device Management.

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

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

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

dynamically adjusting to changes and ensuring a certain level of quality of service.In June, 2003 OMA released the OMA Device Management (OMA DM) version 1.1.2

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

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

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

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

and bandwidth limitations of mobile devices.

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

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

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

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

data or software modules.

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

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

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

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

interface aspects.

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

[15].

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

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

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

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

1-1

8/8/2019 C.S0064-0 v1.0 050907

12/64

3GPP2 C.S0064-0 v1.0

1.1 Scope1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

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

compliant with cdma20002

standards.

1.2 Definitions

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

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

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

BS. See Base Station.

CSC. See Customer Service Center.

CSD. Circuit Switched Data.

Customer Service Center (CSC). An entity in a wireless carriers network that receives

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

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

DM. See Device Management.

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

manufacturer, uniquely identifying the mobile station equipment.

ESN. See Electronic Serial Number.

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

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

firmware over-the-air.

FOTA. See Firmware Over-the-Air.

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

managing mobile stations configuration. See [3].

HCM. See Handset Configuration Management.

HRPD. High Rate Packet Data.

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

communicate with the web servers. See [20].

HTTP. See Hyper Text Transfer Protocol.

IMSI. See International Mobile Station Identity.

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

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

2cdma2000 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.

1-2

8/8/2019 C.S0064-0 v1.0 050907

13/64

3GPP2 C.S0064-0 v1.0

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

CDMA requirements as specified in this document.

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

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

document.

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

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

management operations.

MC. See Messaging Center.

MEID. See Mobile Equipment Identifier.

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

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

MIN. See Mobile Identification Number.

MIP. Mobile IP.

MMC. See Mobile Management Command.

MMD. Multimedia Domain.

MMS. Multimedia Messaging Service.

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

32-bit ESN.

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

the 10-digit number assigned to a mobile station.

Mobile Switching Center (MSC). A configuration of equipment that provides wirelessradio telephone service. Also called the Mobile Telephone Switching Office (MTSO).

Mobile Station (MS). A station, fixed or mobile, which serves as the end users wireless

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

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

MS. See Mobile Station.

MSC. See Mobile Switching Center.

NAM. See Number Assignment Module.

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

mobile station.

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

OMA DM. See OMA Device Management.

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

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

1-3

8/8/2019 C.S0064-0 v1.0 050907

14/64

3GPP2 C.S0064-0 v1.0

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

Open Mobile Alliance for Device Management (DM). See

http://www.openmobilealliance.org.

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

OTAF. See Over-the-Air Function.

OTAPA. See Over-The-Air Parameter Administration.OTASP. See Over-The-Air Service Provisioning.

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

OTASP functionality and messaging protocol.

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

provisioning mobile station operational parameters over the air interface.

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

operational parameters over the air interface.

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

acquiring a wireless system.

PRL. See Preferred Roaming List.

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

Internet Engineering Task Force (IETF).

RFC. See Request For Comment.

R-UIM. Removable User Identity Module.

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

SIP. Simple IP.

SMS. See Short Message Service.

SPASM. See Subscriber Parameter Administration Mechanism.

SPL. See Service Programming Lock.

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

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

verifying the Service Programming Code (SPC).

Subscriber Parameter Administration Mechanism (SPASM). Security mechanism

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

network entity during the OTAPA session.

SyncML. See Synchronization Mark-up Language.

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

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

OMA.

SyncML DM. See SyncML Device Management.

1-4

8/8/2019 C.S0064-0 v1.0 050907

15/64

3GPP2 C.S0064-0 v1.0

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

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

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

specifications. See [5-15].

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

TLS. See Transport Layer Security.

TPD. See Trusted Provisioning Domain.

TPS. See Trusted Provisioning Server.

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

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

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

operations.

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

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

operations.

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

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

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

in a communications network. See [17].

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

in a communications network. See [17].

URI. See Uniform Resource Indicator.

URL. See Uniform Resource Locator.

Visitor Location Register (VLR).

VLR. See Visitor Location Register.

WAP. See Wireless Application Protocol.

WBXML. See Wireless Binary Extensible Markup Language.

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

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

Wireless Binary Extensible Markup Language. See [5].

WML. See Wireless Markup Language.

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

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

XML. See Extensible Markup Language.

1.3 General Requirements

An IOTA-DM Client in an MS SHALL be capable of receiving and processing OMADM commands as defined in [5] from one or more IOTA-DM Servers.

1-5

8/8/2019 C.S0064-0 v1.0 050907

16/64

3GPP2 C.S0064-0 v1.0

The MS SHALL be capable of receiving and processing management commandsfrom an authorized IOTA-DM Server.

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

The MS SHALL support the OMA DM tree defined in [7] with CDMA extensionsspecified in this document.

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

The IOTA-DM Management Server SHALL be able to initiate an IOTA-DMManagement session.

The MS SHALL be able to initiate an IOTA-DM Management session. The IOTA-DMClient SHALL send device information at the beginning of a management session so

that the IOTA-DM Server can tailor the contents and operations to suite thecapabilities of the MS.

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

OTASP/OTAPA standard [2] or later revisions.

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

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

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

DM Server managing these parameters.

The IOTA-DM Server SHALL be able to support modification, deletion, and additionof parameters in the MS, e.g., as a result of the user subscribing to a new service

offered by an Operator or Service Provider.

1.4 Protocol Requirements

Following are the basic requirements for facilitating IOTA management using OMA DMprotocol.

Mobile Station SHALL support IP Protocol.

Mobile Station SHALL support HTTP 1.1.

The Mobile Station equipped with IOTA-DM Client and the IOTA-DM Server shallsupport OMA DM 1.2 or later versions.

The IOTA-DM Client and IOTA-DM Server interface SHALL use OMA DM 1.2protocol or its later revisions.

For backward compatibility with OTASP/OTAPA [2], the mobile and the server shallsupport converting IOTA-DM data to OTASP/OTAPA data.

Security Mechanism: The security mechanism as defined in [10] shall be followed inaddition to transport layer security [TLS] for IP network.

1-6

8/8/2019 C.S0064-0 v1.0 050907

17/64

3GPP2 C.S0064-0 v1.0

2 ARCHITECTURE1

2

3

4

5

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

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

technologies, such as Bluetooth, IrDA etc.

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

8

9

Figure 2-1 Network Architecture

2-1

8/8/2019 C.S0064-0 v1.0 050907

18/64

3GPP2 C.S0064-0 v1.0

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

3

4

5

6

7

8

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

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

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

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

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

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

2-2

8/8/2019 C.S0064-0 v1.0 050907

19/64

3GPP2 C.S0064-0 v1.0

3 INTRODUCTION TO DM PROTOCOL1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

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

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

architecture.

3.1 Management Tree

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

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

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

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

or application.

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

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

Descriptions specification [7].

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

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

referenced for a specific management action.

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

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

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

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

3.2 Device Description

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

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

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

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

for a particular MS.

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

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

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

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

and new features in the device.

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

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

represented using the DDF DTD.

3.3 Bootstrap Mechanism

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

defined in the OMA DM Bootstrap specification [8].

3-1

8/8/2019 C.S0064-0 v1.0 050907

20/64

3GPP2 C.S0064-0 v1.0

3.4 OMA DM Packages and Messages1

2

3

4

5

6

7

8

9

10

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

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

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

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

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

protocol specifications [6].

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

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

8/8/2019 C.S0064-0 v1.0 050907

21/64

3GPP2 C.S0064-0 v1.0

3.6 Notification Message1

2

3

4

5

6

7

8

9

10

11

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

server and begin a management session. The notification is a signed message, which the

client can authenticate. There are several fields in the notification message, for example

the UI-mode field is used for specifying user interaction when the client receives the

notification.

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

of a session, for example when a timer expires.

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

OMA DM Notification Initiated Session [9].

3-3

8/8/2019 C.S0064-0 v1.0 050907

22/64

3GPP2 C.S0064-0 v1.0

No text.1

3-4

8/8/2019 C.S0064-0 v1.0 050907

23/64

3GPP2 C.S0064-0 v1.0

4 CDMA DEVICE MANAGEMENT1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

3031

32

33

34

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

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

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

capabilities of the device. This helps the management server to tailor the contents to meetdevice capabilities. In the management phase, the client and the server shall interact to

carry out one or more management tasks. It may consist of a number of protocol

iterations. Details of establishing a management session and interaction between DM

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

4.1 Communication with the Mobile Station

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

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

bindings.

4.2 IOTA-DM content

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

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

represented using OMA DM Representation Protocol [6].

4.2.1 Command Set

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

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

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

4.2.2 XML Specification for OMA DM

4.2.3 OMA DM DTD

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

4.2.4 OMA DM DTD Elements

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

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

Common use elements: Archive, Chal, Cmd, CmdID, CmdRef, Cred,Final, Lang, LocName, LocURI, MoreData, MsgID, MsgRef, NoResp,

NoResults, NumberOfChanges, RespURI, SessionID, SftDel, Source,SourceRef, Target, TargetRef, VerDTD, VerProto.

Message container elements: SyncML, SyncHdr, SyncBody.

Date description elements: Data, Item, Meta.

Protocol management elements: Status.

4-1

8/8/2019 C.S0064-0 v1.0 050907

24/64

3GPP2 C.S0064-0 v1.0

Protocol command elements: Add, Alert, Atomic, Copy, Delete,Exec, Get, Replace, Results, Sequence.

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

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

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

elements and how they are used to access the management tree in the mobile station, to

perform management operations, are described in [6]. The Sequence element allows several

commands to be specified in the same message. The Atomic element is similar to sequence,

except that all specified commands are executed as a set or not at all [6].

4.3 MIME Types and HTTP Headers

4.3.1 MIME Types

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

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

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

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

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

encoded form of the OMA DM message.

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

session layer protocols.

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

4.3.2 Accept Headers for Supported MIME Types

While performing HTTP requests to the IOTA-DM Server, IOTA-DM client must add OMADM content types accepted by the client in the HTTP accept headers.

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

used:

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

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

MIME type shall be used:

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

4.3.3 HTTP Bindings

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

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

bindings specification [12] describes the HTTP header for OTA messaging using OMA DM.

4-2

8/8/2019 C.S0064-0 v1.0 050907

25/64

3GPP2 C.S0064-0 v1.0

4.3.4 Other Transport Bindings1

2

3

4

5

6

7

8

9

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

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

4.4 Network Initiated Scenario

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

management session.

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

configured to establish a management session.

4-3

8/8/2019 C.S0064-0 v1.0 050907

26/64

3GPP2 C.S0064-0 v1.0

1

Package #1: Credentials and CDMA

DevInfo

Package #2: Server Credentials and

Initial Management Actions

Package #3: Client Responses

Package #4: More Management

Actions

Managem

DatabasIOTA-DM ServerNetworkIOTA-DM ClientMS Management TreeUser

Notification Message

User Interaction

User Interaction

RRC, Network Connection

Setup phase

Management phase

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

Figure 4.4-1 Network Initiated Scenario

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

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

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

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

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

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

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

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

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

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

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

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

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

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

4-4

8/8/2019 C.S0064-0 v1.0 050907

27/64

3GPP2 C.S0064-0 v1.0

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

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

objects described in section 5 as a subtree. The CDMA Management objects shall be

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

1

2

3

4

5

6

7

8

9

10

11

12

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

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

in section 5.2.7 to address the CDMA PRL.

4.5 MS Initiated Scenario

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

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

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

on a timer expiry.

Package #3: Client Responses

Package #4: More Management

Actions

Managem

Databa

IOTA-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

15 Figure 4.5-1 Client Initiated Scenario

4-5

8/8/2019 C.S0064-0 v1.0 050907

28/64

3GPP2 C.S0064-0 v1.0

1

2

3

4

5

6

7

8

9

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

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

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

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

Management Object in addition to the Management Objects required for an OMA DM

Session as described in [5] and [7]. The setup phase and management phase in the figure

4.5-1 should follows the same procedures as the network initiated scenario described in

section 4.4.

4-6

8/8/2019 C.S0064-0 v1.0 050907

29/64

8/8/2019 C.S0064-0 v1.0 050907

30/64

3GPP2 C.S0064-0 v1.0

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

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

(MEID).

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

Occurrence: One

Scope: PermanentAccess Type: Get

Format: char

5.1.2 CDMAProtPref

URI: ./DevInfo/Bearer/CDMA/CDMAProtPref

Description: Specifies the protocol preference. For management using Meta

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

CDMAProtPref is set to 0. Otherwise CDMAProtPref is set to 1. This parameter

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

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

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

management currently preferred in the device for managing CDMA settings.

Occurrence: One

Scope: Permanent

Access Type: Get, Replace

Format: Bool

5.1.3 CDMAProtCap

URI: ./DevInfo/Bearer/CDMA/CDMAProtCap

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

Refer to section 3.5.1.7-1 of [2].

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

Occurrence: One

Scope: Permanent


Format: b64

5.1.4 CDMABandModCap

URI: ./DevInfo/Bearer/CDMA/CDMABandModCap

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

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

object value has size 8 bits.

5-2

8/8/2019 C.S0064-0 v1.0 050907

31/64

3GPP2 C.S0064-0 v1.0

Occurrence: One1

2

3

4

5

6

7

8

Scope: Permanent


Format: b64

5.2 CDMA Operational Parameters

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

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

parameters.

AmpsNam

ID:

ID:

CdmaNam

CDMAOpParamCDMA

AcqRecTab AcqRecEntry

SysRecEntrySysRecTab

PrefRoamList

SSPR PrefRoamDim

ExPrefRoamDim

ExAcqRecTab ExAcqRecEntry

ExSysRecEntryExSysRecTab

ExPrefRoamList

MobDirNum

ImsiT

ComSubnetTabPUZL

SysTag

9

10

11

12

13

14

15

16

17

Figure 5.2-1 CDMA Operational Parameters Management Objects

5.2.1 CMDAOpParam

Description: CDMAOpParam (CDMA Operational Parameters) node is a parent to all

CDMA Operational settings.

Occurrence: One

5-3

8/8/2019 C.S0064-0 v1.0 050907

32/64

3GPP2 C.S0064-0 v1.0

Scope: Permanent1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

Access Type: Get

Format: Node

5.2.2 ./CDMA/CDMAOpParam/MobDirNum

MobDirNum

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

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

Occurrence: One

Scope: Permanent


Format: b64

5.2.3 ./CDMA/CDMAOpParam/AmpsNam

AmpsNam

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

Occurrence: One

Scope: Permanent


Format: b64

5.2.4 ./CDMA/CDMAOpParam/CdmaNam

CdmaNam

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

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

Occurrence: One

Scope: Permanent

Access Type: Get

Format: Node

5.2.5 ./CDMA/CDMAOpParam/CDMANAM/y+

CDMANAM/y+

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

or more CDMA NAM settings in a CDMA device. NAM settings in CDMA devices are

defined in section 3.5.2 of [2].

5-4

8/8/2019 C.S0064-0 v1.0 050907

33/64

3GPP2 C.S0064-0 v1.0

Occurrence: One or more1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

Scope: Dynamic


Format: Node

5.2.6 ./CDMA/CDMAOpParam/ImsiT

ImsiT

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

Occurrence: One

Scope: Permanent

Access Type Get, Replace

Format: b64

5.2.7 ./CDMA/CDMAOpParam/SSPR

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

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

carries the management objects for Preferred Roaming List and Extended Preferred

Roaming List.

Occurrence: One

Scope: Permanent


Format: Node

5.2.8 ./CDMA/CDMAOpParam/PrefRoamList

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

mobile station system selection and acquisition process, particularly when the

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

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

in the PRL block.

Occurrence: One

Scope: Permanent


Format: b64

5.2.9 ./CDMA/CDMAOpParam/PrefRoamListDim

Description: This management object represents the dimensions of the Preferred

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

5-5

8/8/2019 C.S0064-0 v1.0 050907

34/64

3GPP2 C.S0064-0 v1.0

Occurrence: One1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

Scope: Permanent


Format: b64

5.2.10 ./CDMA/CDMAOpParam/ExPrefRoamList

Description: The Extended Preferred Roaming list corresponds to SSPR_P_REV

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

Occurrence: One

Scope: Permanent


Format: b64

5.2.11 ./CDMA/CDMAOpParam/ExPrefRoamListDim

Description: This management object represents the dimensions of the Extended

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

Occurrence: One

Scope: Permanent


Format: b64

5.2.12 ./CDMA/CDMAOpParam/PUZL

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

specified in Section 3.5.6 of [2].

Occurrence: One

Scope: Permanent


Format: b64

5.2.13 ./CDMA/CDMAOpParam/SysTag

Description: Management Object representing System Tag Parameter Block asspecified in Section 3.5.10 of [2].

Occurrence: One

Scope: Permanent


Format: b64

5-6

8/8/2019 C.S0064-0 v1.0 050907

35/64

3GPP2 C.S0064-0 v1.0

5.3 CDMA Packet Data Objects1

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

ID:

CDMAAP 3GPDOPC

3GPDOPM

SIP SIPCAP

SIPSP

3GPD

SIPUPP

SIPPSS

SIPCSS

MIP MIPCAP

MIPSP

MIPUPP

MIPSS

ID:

SIPUPPS

MIPUPPS

CDMA

3

3GPDCDMA CDMAAP

HRPDAACHAP

HRPDAAUPPHRPD

4

5

6

Figure 5.3-1 CDMA Packet Data Management Objects

5-7

8/8/2019 C.S0064-0 v1.0 050907

36/64

3GPP2 C.S0064-0 v1.0

5.3.1 CDMAAP1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

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

data services.

Occurrence: One

Scope: Permanent

Access Type: Get

Format: Node

5.3.2 ./CDMAAP/3GPD

3GPD

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

defined in [2].

Occurrence: One

Scope: Permanent

Access Type: Get

Format: Node

5.3.2.1 ./CDMAAP/3GPD/3GPDOCP

./3GPDOCP

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

objects. Operation Mode Bitmap to indicate which operation modes are supported

by the mobile station. The mobile device shall use the table in section 3.5.8.1 of [2].

Occurrence: One

Scope: Permanent

Access Type: Get

Format: Node

5.3.2.2 ./CDMAAP/3GPD/3GPDOMP

./3GPDOMP

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

objects. This can be one of Mobile IP, Simple IP, Mobile IP with Simple IP fall back.The mobile station shall set this field to the active operation mode in the mobile

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

Occurrence: One

Scope: Permanent

Access Type: Get

5-8

8/8/2019 C.S0064-0 v1.0 050907

37/64

3GPP2 C.S0064-0 v1.0

Format: Node1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

5.3.2.3 ./CDMAAP/3GPD/SIP

SIP

Description: Parent to all Simple IP objects.Occurrence: One

Scope: Permanent

Access Type: Get

Format: Node

5.3.2.4 ./CDMAAP/3GPD/MIP

MIP

Description: Parent to all Mobile IP objects.

Occurrence: One

Scope: Permanent

Access Type: Get

Format: Node

5.3.2.5 ./CDMAAP/3GPD/HRPD

Description: Parent to all HRPD objects.

Occurrence: One

Scope: Permanent

Access Type: Get

Format: Node

5.4 CDMA MMD Management Object

This section defines the MMD management object.

5-9

8/8/2019 C.S0064-0 v1.0 050907

38/64

3GPP2 C.S0064-0 v1.0

IMPILength

IMPI

MMDCDMA

ID:

NumIMPU

IMPU

SIPURILength

ID: PCSCFAdd

SIPDomainURI

NumPCSCF

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

Figure 5.4-1 CDMA MMD Management Object

5.4.1 ./CDMA/MMD

MMD

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

parameters specified in [2].

Occurrence: One

Scope: Permanent


Format: Node

5.4.2 ./CDMA/MMD/IMPILength

IMPILength

Description: IMS Private Identity Length

Occurrence: One

5-10

8/8/2019 C.S0064-0 v1.0 050907

39/64

3GPP2 C.S0064-0 v1.0

Scope: Permanent1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31


Format: b64

5.4.3 ./CDMA/MMD/IMPI

IMPI

Description: IMS Private Identity.

Occurrence: One

Scope: Permanent


Format: b64

5.4.4 ./CDMA/MMD/NumIMPU

NumIMPU

Description: Number of IMS public entries.

Occurrence: One

Scope: Permanent

Access Type: Get

Format: Node

5.4.5 ./CDMA/MMD/ImpuEntryIndex+

ImpuEntryIndex+

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

There can be one or more IMS Public Identity Entry.

Occurrence: One or more

Scope: Dynamic

Access Type: Get, Replace, Delete

Format: Node

5.4.6 ./CDMA/MMD/ImpuEntryIndex+/IMPU

IMPU

Description: IMS Public Identity.

Occurrence: One

Scope: Permanent

Access Type Get, Replace, Delete

5-11

8/8/2019 C.S0064-0 v1.0 050907

40/64

3GPP2 C.S0064-0 v1.0

Format: b641

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

5.4.7 ./CDMA/MMD/SIPURILength

SIPURILength

Description: SIP Domain URI Length.

Occurrence: One

Scope: Permanent


Format: b64

5.4.8 ./CDMA/MMD/SIPDomainURI

SIPDomainURI

Description: SIP Domain URI.

Occurrence: One

Scope: Permanent


Format: b64

5.4.9 ./CDMA/MMD/NumPCSCF

NumPCSCF

Description: Number of PCSCF Entries.

Occurrence: One

Scope: Permanent

Access Type: Get, replace

Format: Node

5.4.10 ./CDMA/MMD/PCSCFEntryIndex+

PCSCFEntryIndex+

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

There can be one or more PCSCF Entry.


Scope: Dynamic


Format: Node

5-12

8/8/2019 C.S0064-0 v1.0 050907

41/64

3GPP2 C.S0064-0 v1.0

5.4.11 ./CDMA/MMD/PCSCFEntryIndex+/PCSCFAdd1

2

3

4

5

6

7

8

9

PCSCFAdd

Description: PCSCF address entry.

Occurrence: One

Scope: Permanent


Format: b64

5.5 CDMA System Tag Management Object

This section defines the System Tag management object.

HomeSysTag

GroupTagListDim

SysTagCDMA

GroupTagList

SpecificTagListDim

CallPromtList

SpecificTagList

CallPromtListDim

10

11

12

13

14

15

Figure 5.5-1 CDMA System Tag Management Object

5.5.1 ./CDMA/SysTag/HomeSysTag

HomeSysTag

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

5-13

8/8/2019 C.S0064-0 v1.0 050907

42/64

3GPP2 C.S0064-0 v1.0

Occurrence: One1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

Scope: Permanent


Format: b64

5.5.2 ./CDMA/SysTag/GroupTagListDim

GroupTagListDim

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

Occurrence: One

Scope: Permanent


Format: b64

5.5.3 ./CDMA/SysTag/GroupTagList

GroupTagList

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

Occurrence: One

Scope: Permanent


Format: b64

5.5.4 ./CDMA/SysTag/SpecificTagListDim

SpecificTagListDim

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

Occurrence: One

Scope: Permanent


Format: b64

5.5.5 ./CDMA/SysTag/SpecificTagList

SpecificTagList

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

Occurrence: One

Scope: Permanent


5-14

8/8/2019 C.S0064-0 v1.0 050907

43/64

3GPP2 C.S0064-0 v1.0

Format: b641

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

5.5.6 ./CDMA/SysTag/CallPromptListDim

CallPromptListDim

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

Scope: Permanent


Format: b64

5.5.7 ./CDMA/SysTag/CallPromptList

CallPromptList

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

Occurrence: One

Scope: Permanent


Format: b64

5.6 CDMA MMS Management Object

This section describes the management object used for managing MMS.

5-15

8/8/2019 C.S0064-0 v1.0 050907

44/64

3GPP2 C.S0064-0 v1.0

NumMMSURIMMSCDMA

ID: MMSURI

MMSCap MaxNumMMSURI

MaxMMSURILength

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

Figure 5.6-1 CDMA MMS Management Object

5.6.1 ./CDMA/MMS

MMS

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

parameters specified in [2].

Occurrence: One

Scope: Permanent


Format: Node

5.6.2 ./CDMA/MMS/NumMMSURI

NumMMSURI

Description: Number of MMS URI Entries.

Occurrence: One

Scope: Permanent

5-16

8/8/2019 C.S0064-0 v1.0 050907

45/64

3GPP2 C.S0064-0 v1.0

Access Type: Get, Replace1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

Format: b64

5.6.3 ./CDMA/MMS/MMSURIEntryIndex+

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

There can be one or more MMS URI entries.


Scope: Dynamic


Format: Node

5.6.4 ./CDMA/MMS/MMSURIEntryIndex+/MMSURI

MMSURI

Description: MMS URI Entry.

Occurrence: One

Scope: Dynamic


Format: b64

5.6.5 ./CDMA/MMS/MMSCap/

MMSCap

Description: MMS Capabilities node.

Occurrence: One

Scope: Permanent


Format: Node

5.6.6 ./CDMA/MMS/MMSCap/MaxNumMMSURI

MaxNumMMSURI

Description: Maximum Number of MMS URI Entries.

Occurrence: One

Scope: Permanent


Format: b64

5-17

8/8/2019 C.S0064-0 v1.0 050907

46/64

3GPP2 C.S0064-0 v1.0

5.6.7 ./CDMA/MMS/MMSCap/MaxMMSURILength1

2

3

4

5

6

7

8

MaxMMSURILength

Description: Maximum MMS URI Length.

Occurrence: One

Scope: Permanent


Format: b64

5-18

8/8/2019 C.S0064-0 v1.0 050907

47/64

3GPP2 C.S0064-0 v1.0

6 IOTA-DM SECURITY1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

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

CDMA specific security parameters.

6.1 Access Control and Security

OMA DM framework provides security at several levels:

Access control mechanism to control the access to management objects

Protocol security mechanism to ensure confidentiality of data

Ensuring the integrity of the data

Authentication between the mobile device and the management server.

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

parameters and management objects in the mobile device. Only the management server with appropriate rights shall modify the management objects. Since the management

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

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

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

node or leaf in the management tree.

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

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

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

the other to send them.

Integrity of management data transferred between the device and the server is important,since deliberate or accidental corruption data can occur. Integrity of OMA DM data is

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

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

for IOTA-DM Security.

6.2 OTA Update of A-Key and other Critical Parameters

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

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

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

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

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

6.2.1 A-Key and Root Key Generation

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

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

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

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

6-1

8/8/2019 C.S0064-0 v1.0 050907

48/64

3GPP2 C.S0064-0 v1.0

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

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

command should execute upon receiving the IOTA-DM Key Generation Request Message.

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

MS for handling the protocol specified in [2]. The data in the Key Request Message

received at the IOTA-DM Client can be stored in a temporary leaf node of the A-Key node,from where the invoked A-Key client can access it.

1

2

3

4

5

6

7

8

9

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

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 CapabilityMsg

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, invokeprocess.

10. Computes A-KEY

9. Pass BS_RESULT

10

11

12

13

14

15

16

17

18

19

20

Figure 6.2.1-1 Key Generation using DM Protocol

1. The IOTA-DM server shall begin a notification-initiated session by sending astandardpackage #0notification message.

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

information.

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

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

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

6-2

8/8/2019 C.S0064-0 v1.0 050907

49/64

3GPP2 C.S0064-0 v1.0

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

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

input parameter is included in the dataelement of the command as b64 encoded

binary data. Figure 6.2.1-2 shows an example of thepackage #2message.

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

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

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

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

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

provided as input parameters to the A-key client.

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

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

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

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

in the dataelement ofpackage #3as a response to thepackage #2message in step

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

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

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

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

defined in [21] shall be used.

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

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

of [2]).

8. The IOTA-DM Server shall send the BS_RESULT to the IOTA-DM client inpackage

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

binary data beginning with OTASP_MSG_TYPE and ending with BS_RESULT, as

specified in section 4.5.1.4 of [2] shall be included in the data element in b64encoded form. The targetURI for the command shall be cdma/a-key/keygen. The

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

shown in figure 6.2.1-4.

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

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

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

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

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

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

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

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

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

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

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

Key based on the MS_RESULT, following the base station procedures in section 5 of

[2].

6-3

8/8/2019 C.S0064-0 v1.0 050907

50/64

3GPP2 C.S0064-0 v1.0

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

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

completion.

1

2

3

4

5

6

7

8

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

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

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

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

b64bin

./cdma/a-key/keyreq

8/8/2019 C.S0064-0 v1.0 050907

51/64

3GPP2 C.S0064-0 v1.0

b64bin

./cdma/a-key/keygen/bs-result

8/8/2019 C.S0064-0 v1.0 050907

52/64

3GPP2 C.S0064-0 v1.0

b64bin

./cdma/service-key

8/8/2019 C.S0064-0 v1.0 050907

53/64

8/8/2019 C.S0064-0 v1.0 050907

54/64

3GPP2 C.S0064-0 v1.0

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

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

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

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

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

execute upon receiving the IOTA-DM Key Generation Request Message. WhenOTASP/OTAPA as specified in [2] is supported, this process is a client running in the MS

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

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

the invoked MS client can access it.

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

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

commands specified in the message. This involves executing the Exec command on the A-

Key node in the Management Tree, which results in invoking and passing the encapsulated

Key Generation Request Message to the MS Client.

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

encapsulated message. The algorithm described in section 5.1 of [2] is followed forcalculating MS_RESULT.

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

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

described in [2].

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

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

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

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

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

IOTA-DM Server.

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

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

sends it to the MS in the Key Generation Request message.

The IOTA-DM Server encapsulates the Key Generation Request Message in a DM Protocol

message and sends it to the MS IOTA-DM Client in the IOTA-DM Key Generation Request.

This message also carries the Exec command to invoke the MS client.

Executing the Exec command results in invoking the MS client process.

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

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

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

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

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

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

The server computes the A-Key.

6-8

8/8/2019 C.S0064-0 v1.0 050907

55/64

3GPP2 C.S0064-0 v1.0

The server issues a commit message.1

2

3

4

5

6

7

8

9

10

11

12

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

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

stores the A-Key in a permanent memory.

The MS client now sends a Commit Response.

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

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

6.3 Secure Mode Operation

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

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

section 7.

6-9

8/8/2019 C.S0064-0 v1.0 050907

56/64

3GPP2 C.S0064-0 v1.0

No text.1

6-10

8/8/2019 C.S0064-0 v1.0 050907

57/64

3GPP2 C.S0064-0 v1.0

7 HANDLING OF OTASP/OTAPA MESSAGES1

2

3

4

5

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

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

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

representation protocol [6].

syncml:cdma-is683

b64

./root/../cdma/is683

IS-683 Message

6

7

8

9

10

c.s0064-0 v1.0 050907

Documents