1 3GPP2 C.S0040 2 Version 1.0 3 Date: July 18, 2003 4 5
6 IP Based Over-the-Air 7 Handset Configuration Management (IOTA-HCM)
8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 COPYRIGHT 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. 23 24 3GPP2 C.S0040
1 No text. 2
ii 3GPP2 C.S0040 CONTENTS
1 2 FOREWORD...... vii 3 NOTES ...... viii 4 REFERENCES...... ix 5 1. Introduction ...... 11 6 1.1. Scope ...... 11 7 1.2. Definitions...... 11 8 2. General Requirements ...... 17 9 2.1 Operations ...... 17 10 2.2 Protocol Requirements...... 18 11 2.3 Architecture ...... 18 12 2.3.1 Trusted Provisioning Server (TPS) ...... 18 13 2.3.2 Communication with the Mobile Station...... 19 14 2.3.2.1 Provisioning Transaction Agent...... 19 15 2.3.2.2 Provisioning Service Agent...... 20 16 2.3.2.3 Bootstrap Service Agent...... 20 17 2.3.3 Security Mechanisms ...... 20 18 2.3.3.1 The Trusted Provisioning Domain (TPD)...... 20 19 2.3.3.2 Subscriber Parameter Administration Security Mechanism (SPASM)...... 20 20 2.3.3.3 Service Programming Lock (SPL)...... 20 21 2.3.3.4 Bootstrap Security...... 20 22 2.3.3.5 NAI Authentication for cdma2000 Mobile Stations ...... 21 23 2.3.3.6 Session Security ...... 21 24 3. Provisioning ...... 22 25 3.1 The Provisioning Processes...... 22 26 3.1.1 Initiation ...... 22 27 3.1.2 Mobile Station Rendezvous...... 22 28 3.1.3 Provisioning Message Exchanges...... 22 29 3.1.4 Bootstrap Mechanism...... 22 30 3.1.5 Provisioning Activation (PA) Code ...... 23 31 3.2 Provisioning Content ...... 23 32 3.2.1 Overall Approach...... 23 33 3.2.2 Major Elements of MMC ...... 23 34 3.3 XML specifications of MMC...... 23 35 3.3.1 MMC DTD ...... 23 36 3.3.2 MMC DTD Elements...... 24 37 3.3.2.1 The ‘mmc’ Element ...... 24 38 3.3.2.2 The ‘status’ Element...... 25 39 3.3.2.3 The ‘detail’ Element...... 25 40 3.3.2.4 The ‘method’ Element...... 26 41 3.4 MIME Types and HTTP Headers ...... 28 42 3.4.1 MIME Types ...... 28 43 3.4.2 Accept Headers for Supported MIME Content Types ...... 29 44 3.4.3 Including IOTA Version in the HTTP Headers...... 29 45 3.5 Example IOTA Commands...... 29 46 3.5.1 Opening a Session...... 29 47 3.5.1.1 Request (Server to Client) ...... 29 48 3.5.1.2 Response (Client to Server) ...... 30 49 3.5.2 OTASP and OTAPA Tunneling...... 30 50 3.5.2.1 Request (Server to Client) ...... 30 51 3.5.2.2 Response (Client to Server) ...... 31 52 3.5.3 Arbitrary Binary Object Download ...... 31 53 3.5.3.1 Request (Server to Client) ...... 31 54 3.5.3.2 Response (Client to Server) ...... 32 55 3.5.4 Disconnect ...... 33
iii 3GPP2 C.S0040 CONTENTS
1 3.5.4.1 Request (Server to Client) ...... 33 2 3.5.4.2 Response (Client to Server) ...... 33 3 3.6 Use of HTTP and WSP Methods ...... 33 4 3.7 The Provisioning Multipart ...... 34 5 3.7.1 Example of Provisioning Multipart...... 34 6 3.7.2 The Provisioning Multipart Response...... 35 7 4. Encoding Based on WBXML ...... 37 8 5. IOTA Objects ...... 40 9 6. OTASP and OTAPA Tunneling...... 40 10 7. IOTA Bootstrap Message...... 40 11 8. IOTA Error Codes ...... 41 12 9. IOTA Trigger Message ...... 42 13 10. Handling User Interrupts during IOTA Sessions ...... 42 14 Appendix A. IOTA-HCM Message Flows...... 43 15 A.1 Bootstrapping Message Flow Examples...... 43 16 A.1.1 Voice-Call Assisted Bootstrapping of Un-programmed Mobile Station (Default IMSI) – 17 Mobile Station is Pre-loaded into HLR...... 43 18 A.1.2 Voice-call Assisted Bootstrapping of Un-programmed Mobile Station (Default IMSI) – 19 Mobile Station is Not Pre-loaded into HLR ...... 46 20 A.1.3 Automated Bootstrapping After Power-up ...... 49 21 A.1.4 Mobile Station Initiated Session – No Voice Call...... 52 22 A.1.5 Network Initiated Session – No Voice Call ...... 53 23 A.2 Provisioning Message Flow Examples ...... 54 24 A.2.1 OTAPA Call Flow - PRL Update ...... 54 25 Appendix B. Standardized IOTA Objects...... 56 26 B.1 IOTA Security Settings ...... 56 27 B.2 User Prompt Objects ...... 57 28 B.3 Mobile Station Settings...... 60 29 B.4 Mobile Station Diagnostics ...... 61 30 B.5 Mobile Station Capabilities ...... 61 31 B.6 Browser Settings ...... 62 32 B.7 CDMA Settings ...... 63 33 Appendix C. WAP Bootstrap Parameter to IOTA Object Mapping ...... 65 34 C.1 PXLOGICAL Characteristics ...... 65 35 C.2 PXLOGICAL.PXAUTHINFO Characteristics ...... 65 36 C.3 PXLOGICAL.PORT Characteristics...... 65 37 C.4 PXLOGICAL.PXPHYSICAL Characteristics ...... 65 38 C.5 PXLOGICAL.PXPHYSICAL.PORT Characteristics...... 66 39 C.6 NAPDEF Characteristics...... 66 40 C.7 NAPDEF.NAPAUTHINFO Characteristics ...... 67 41 C.8 NAPDEF.VALIDITY Characteristics ...... 67 42 C.9 BOOTSTRAP Characteristics ...... 67 43 C.10 CLIENTIDENTITY Characteristics ...... 68 44 C.11 VENDORCONFIG Characteristics ...... 68 45 C.12 3GPP2 Specific Parameters...... 68 46 47
iv 3GPP2 C.S0040 FIGURES
1 2 Figure 2.2-1 IOTA HCM Entities and Protocols ...... 18 3 Figure 2.3.2-1 IOTA Handset Configuration Management Architecture...... 19 4 Figure A.1.1-1 Voice-call Assisted Bootstrapping of Un-programmed Mobile Station (Default 5 IMSI) – Mobile Station is Pre-loaded into HLR...... 44 6 Figure A.1.2-1 Voice-call Assisted Bootstrapping of Un-programmed Mobile Station (Default 7 IMSI) – Mobile Station is Not Pre-loaded into HLR ...... 47 8 Figure A.1.3-1 Automated Bootstrapping After Power-up...... 50 9 Figure A.1.4-1 Mobile Station Initiated Session – No Voice Call ...... 52 10 Figure A.1.5-1 Network Initiated Session – No Voice Call ...... 53 11 Figure A.2.1-1 OTAPA Call Flow - PRL Update...... 54 12 12
v
3GPP2 C.S0040 TABLES
1 2 Table 5-1 IOTA Object Naming Convention...... 40 3 Table 8-1 IOTA Error Codes...... 41 4 Table B.1-1 IOTA Security Settings...... 57 5 Table B.2-1 User Prompt Objects...... 60 6 Table B.3-1 Mobile Station Settings...... 61 7 Table B.4-1 Mobile Station Diagnostics ...... 61 8 Table B.5-1 Mobile Station Capabilities ...... 62 9 Table B.6-1 Browser Settings ...... 63 10 Table B.7-1 CDMA Settings ...... 64 11 Table C.1-1 PXLOGICAL Characteristics...... 65 12 Table C.2-1 PXLOGICAL.PXAUTHINFO Characteristics ...... 65 13 Table C.3-1 PXLOGICAL.PORT Characteristics...... 65 14 Table C.4-1 PXLOGICAL.PXPHYSICAL Characteristics ...... 66 15 Table C.5-1 PXLOGICAL.PXPHYSICAL.PORT Characteristics...... 66 16 Table C.6-1 NAPDEF Characteristics...... 67 17 Table C.7-1 NAPDEF.NAPAUTHINFO Characteristics...... 67 18 Table C.8-1 NAPDEF.VALIDITY Characteristics ...... 67 19 Table C.9-1 BOOTSTRAP Characteristics ...... 68 20 Table C.10-1 CLIENTIDENTITY Characteristics ...... 68 21 Table C.11-1 VENDORCONFIG Characteristics ...... 68 22 Table C.12-1 3GPP2 Specific Parameters...... 68 23 23
vi
3GPP2 C.S0040
1 FOREWORD
2 (This foreword is not part of this Standard) 3 4 These technical requirements form a standard for Over-the-Air Service Provisioning of 5 mobile stations using Internet Protocol (IP). 6 7 A mobile station that is IP capable and is operating in either the analog or the spread 8 spectrum (CDMA) mode conforming to various versions of the CDMA standards. This 9 standard can be activated over-the-air in any system conforming to these standards. 10 11 The scope of this standard covers over-the-air provisioning of: 12 • Mobile station operational parameters such as PRL, NAM, SPC, A-key, SSD, 3GPD, 13 root key, and PUZL as defined in [10] over the IP transport – instead of CDMA 14 transport protocol (Data Burst Message). 15 • Arbitrary parameters that are defined by the vendors or carriers to enable new data 16 applications such as email, instant messaging, games, etc. 17 18 This standard does not address the quality or reliability of Over-the-Air Service 19 Provisioning, nor does it cover equipment performance or measurement procedures. 20
vii 3GPP2 C.S0040
1 NOTES
2 1. The following verbal forms are used: “Shall” and “shall not” identify requirements to 3 be followed strictly to conform to the standard and from which no deviation is 4 permitted. “Should” and “should not” indicate that one of several possibilities is 5 recommended as particularly suitable, without mentioning or excluding others; that 6 a certain course of action is preferred but not necessarily required; or that (in the 7 negative form) a certain possibility or course of action is discouraged but not 8 prohibited. “May” and “need not” indicate a course of action permissible within the 9 limits of the standard. “Can” and “cannot” are used for statements of possibility 10 and capability, whether material, physical, or causal. 11 2. Footnotes appear at various points in this specification to elaborate and further 12 clarify items discussed in the body of the specification. 13 3. Unless indicated otherwise, this document presents numbers in decimal form. 14 Binary numbers are distinguished in the text by the use of single quotation marks. 15 In some tables, binary values may appear without single quotation marks if table 16 notation clearly specifies that values are binary. The character ‘x’ is used to 17 represent a binary bit of unspecified value. For example ‘xxx00010’ represents any 18 8-bit binary value such that the least significant five bits equal ‘00010’. 19 4. Hexadecimal numbers (base 16) are distinguished in the text by use of the form 20 0xhh where hh represents a string of hexadecimal digits. For example, 0x2fa1 21 represents a number whose binary value is ‘0010111110100001’ and whose 22 decimal value is 12193. Note that the exact number of bits in the binary 23 representation of a hexadecimal number strictly depends on the implementation 24 requirements for the variable being represented. 25
viii
3GPP2 C.S0040
1 REFERENCES
2 The following standards contain provisions, which, through reference in this text, 3 constitute provisions of this Standard. At the time of publication, the editions indicated 4 were valid. All standards are subject to revision, and parties to agreements based upon this 5 Standard are encouraged to investigate the possibility of applying the most recent editions 6 of the standards indicated below. ANSI and TIA maintain registers of currently valid 7 national standards published by them. All 3GPP2 specifications are maintained by the 8 responsible technical specification groups (TSGs) under 3GPP2.
9 [1] RFC 2104: “HMAC: Keyed-Hashing for Message Authentication”, H. Krawczyk, M. 10 Bellare, R. Canetti.
11 [2] RFC 1945: “HTTP 1.0”
12 [3] RFC 2616: “HTTP 1.1”
13 [4] C.S0015, IS-637-A, Short Message Service (SMS) for Spread Spectrum Systems, 3GPP2
14 [5] Provisioning Content, WAP-183, Version 24-July-2001, Open Mobile Alliance.
15 [6] Specification Information Note, WAP-183_003-PROVCONT-20010912-a, Version 12- 16 Sept-2001, Open Mobile Alliance
17 [7] Provisioning Bootstrap, WAP-184, Version 14-March-2001, Open Mobile Alliance.
18 [8] Provisioning User Agent Behavior, WAP-185, Version 14-March-2001, Open Mobile 19 Alliance.
20 [9] WAP Provisioning Smart Card, WAP-186-PROVSC-20010710-a, Version 10-July-2001, 21 Open Mobile Alliance.
22 [10] C.S0016, IS-683-C, Over-the-Air Service Provisioning of Mobile Stations in Spread 23 Spectrum Systems, -March-2003, 3GPP2.
24 [11] Wireless Application Protocol Architecture Specification, WAP-210, Version 12-July- 25 2001, Open Mobile Alliance
26 [12] Binary XML Content Format Specification, WAP-192, 25 July 2001, Open Mobile 27 Alliance.
28 [13] Extensible Markup Language (XML) 1.0 (Second Edition)
29 W3C Recommendation, Version 6-October-2000, World Wide Web Consortium
30 [14] Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message 31 Bodies, RFC 2045, Version November-1996, IETF
32 [15] Wireless Session Protocol Specification, WAP-230, Version 5-July-2001, Open Mobile 33 Alliance
ix 3GPP2 C.S0040
1 [16] N.S0011, IS-725-A, IS-41-D Enhancements for Over-the-Air-Service-Provisioning 2 (OTASP) and Parameter Administration (OTAPA). March 1999. 3GPP2
3 [17] Push Access Protocol Specification, WAP-247-PAP-20010429-a, Version 29-April-2001, 4 Open Mobile Alliance
5 [18] RFC 791, Internet Protocol, DARPA Internet Program Protocol Specification, September 6 1981
7 [19] RFC 2617, Authentication: Basic and Digest Access Authentication, June 1999, IETF.
8 [20] RFC 2246, The TLS Protocol, Version 1.0, January 1999, IETF.
9 [21] X.P0013, “ALL-IP Multimedia Domain”, March 2003, 3GPP2
10 [22] RFC 2486, The Network Access Identifier, January 1999, IETF.
11 [23] RFC 3261, SIP: Session Initiation Protocol, June 2002, IETF.
12 [24] RFC 2806, URLs for Telephone Calls, April 2000, IETF.
13 [25] RFC 2396, Uniform Resource Identifiers (URI): Generic Syntax, August 1998, IETF.
14 [26] RFC 2543, SIP: Session Initiation Protocol, March 1999, IETF.
15 [27] RFC 2373, IP Version 6 Addressing Architecture, July 1998, IETF.
16 [28] S.S0073, “Internet Over-the-Air Handset Configuration Management, Stage-1, July 17 2002, 3GPP2
18 [29] RFC 2387, The MIME Multipart/Related Content-type, August 1998, IETF.
19 Following references are provided for informational purposes only: 20 • SyncML Device Management Protocol, version 1.1.1, October 2002, Open Mobile 21 Alliance. 22
x
3GPP2 C.S0040
1 1. Introduction
2 The purpose of this specification is to identify the operations for cdmaOne and 3 cdma2000®1 mobile stations and systems to support IP-based Over-the-Air Handset 4 Configuration Management (IOTA-HCM). The complexity and effort of provisioning 5 mobile stations and activating users can be greatly reduced using over-the-air service 6 provisioning (OTASP) mechanisms. Carriers also have the need to periodically update 7 CDMA parameters stored in the mobile stations. The capability to update these 8 parameters using over-the-air mechanisms (i.e., over-the-air parameter administration 9 (OTAPA)) will reduce the hardship to the customers and the costs to the operators of 10 having mobile stations brought into service centers for reprogramming. 11 12 An alternate approach is using the SyncML Device Management (DM) protocol, but at 13 present, the version 1.1.1 of the SyncML DM specifications does not address the 14 requirements for Over-the-Air management of CDMA mobile stations. 15 16 IOTA-HCM uses OTASP and OTAPA mechanisms as defined in [10]. In addition to 17 supporting the mobile station parameters defined in [10], IOTA-HCM supports any 18 generic parameters required to administer new generation mobile stations and mobile 19 station resident applications. 20 21 For IOTA-HCM enabled mobile stations, IOTA-HCM server may subsume Over-the-Air 22 Function (OTAF) – as defined in [16].
23 1.1. Scope
24 This standard covers IP-based Over-the-Air provisioning of operational parameters for 25 cdmaOne and cdma2000 compliant mobile stations and systems including preferred 26 roaming list administration and other service and feature affecting parameters.
27 1.2. Definitions
28 AC. See Authentication Center. 29 30 Authentication Center (AC). Refers to network element that performs authentication 31 of mobile stations. 32 33 Base Station, Mobile Switching Center, Inter-Working Function (BMI). Refers to 34 combined network consisting of Base station (BS), Mobile Switching Center (MSC), 35 Inter-Working Function (IWF). 36 37 Base Stations (BS). A fixed station used for communicating with mobile stations. 38 Depending upon the context, the term base station may refer to a cell, a sector within a 39 cell, an MSC, an OTAF, or other part of the wireless system. (See also MSC and OTAF). 40 41 BS. See Base Station. 42 43 BMI. See Base Station (BS), Mobile Switching Center (MSC), Inter-Working Function 44 (IWF).
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. 11
3GPP2 C.S0040
1 2 CSC. See Customer Service Center. 3 4 Customer Service Center (CSC). An entity in a wireless carrier’s network that receives 5 service requests from the end users and acts on such requests. 6 7 Data Type Definition (DTD). Refers to a document that defines XML schema in a 8 standardized manner. 9 10 DTD. See Data Type Definition. 11 12 Electronic Serial Number (ESN). A 32-bit number assigned by the mobile station 13 manufacturer, uniquely identifying the mobile station equipment. 14 15 ESN. See Electronic Serial Number. 16 17 Extensible Markup Language (XML). See [13]. 18 19 HA. See Home Agent. 20 21 Handset Configuration Management (HCM). Refers to the process of updating and 22 managing mobile stations configuration. 23 24 HCM. See Handset Configuration Manager. 25 26 HLR. See Home Location Register. 27 28 Home Agent (HA). Refers to network element in the mobile IP network. 29 30 Home Location Register (HLR). The location register to which a MIN/IMSI is assigned 31 for record purposes such as subscriber information. 32 33 HTML. See Hyper Text Markup Language. 34 35 HTTP. See Hyper Text Transfer Protocol. 36 37 Hyper Text Markup Language (HTML). Refers to a content type used by web 38 browsers. 39 40 Hyper Text Transport Protocol (HTTP). Refers to a protocol used by web browsers to 41 communicate with the web servers. See [3]. 42 43 IMSI. See International Mobile Station Identity. 44 45 International Mobile Station Identity (IMSI). A method of identifying stations in the 46 land mobile service as specified in ITU-T Recommendation E.212. 47 48 IOTA-HCM. See IP-based Over-The-Air Handset Configuration Management. 49 50 Inter-Working Function (IWF). Refers to an entity in the second-generation wireless 51 network that connects the wireless network to data network. 52 53 Internet Protocol (IP). See [18]. 54 55 IP. See Internet Protocol. 12
3GPP2 C.S0040
1 2 IP-based Over-The-Air Handset Configuration Management (IOTA-HCM). Refers to 3 the protocol as defined by this document to perform over-the-air mobile station 4 configuration and management operations. 5 6 IWF. See Inter-Working Function. 7 8 MC. See Messaging Center. 9 10 Messaging Center (MC). Refers to an entity in the wireless network that is responsible 11 for delivering WAP Push (see [17]) or SMS (see [4]) messages to the mobile station. 12 13 MIN. See Mobile Identification Number. 14 15 MMC. See Mobile Management Command. 16 17 Mobile Identification Number (MIN). The 34-bit number that is a digital 18 representation of the 10-digit number assigned to a mobile station. 19 20 Mobile Management Command (MMC). Refers to the XML document that 21 encapsulates IOTA messages. 22 23 Mobile Switching Center (MSC). A configuration of equipment that provides wireless 24 radio telephone service. Also called the Mobile Telephone Switching Office (MTSO). 25 26 Mobile Station (MS). A station, fixed or mobile, which serves as the end user’s wireless 27 communication link with the base station. Mobile stations include portable units (e.g., 28 hand-held personal units) and units installed in vehicles. 29 30 MS. See Mobile Station. 31 32 MSC. See Mobile Switching Center. 33 34 NAM. See Number Assignment Module. 35 36 NAP. See Network Access Point. 37 38 Network Access Point (NAP). Refers to the network side entity such as Inter-Working 39 Function (IWF) or Packet Data Switching Network (PDSN) or Home Agent (HA) in the 40 second and third generation wireless network that is responsible for connecting mobile 41 station to the data network. 42 43 Number Assignment Module (NAM). A set of MIN/IMSI-related parameters stored in 44 the mobile station. 45 46 OTAF. See Over-the-Air Function. 47 48 OTAPA. See Over-The-Air Parameter Administration. 49 50 OTASP. See Over-The-Air Service Provisioning. 51 52 Over-the-Air Function (OTAF). A configuration of network equipment that controls 53 OTASP functionality and messaging protocol. 54
13
3GPP2 C.S0040
1 Over-The-Air Parameter Administration (OTAPA). Network initiated OTASP process 2 of provisioning mobile station operational parameters over-the-air interface. 3 4 Over-The-Air Service Provisioning (OTASP). A process of provisioning mobile station 5 operational parameters over-the-air interface. 6 7 PA. See Provisioning Agent. 8 9 Packet Data Serving Node (PDSN). A network element that links RAN to IP network. 10 11 PAP. See Push Access Protocol. 12 13 PDSN. See Packet Data Serving Node. 14 15 Personal Identification Number (PIN). A shared secret code used for authenticating 16 participating entities in a transaction. 17 18 PIN. See Personal Identification Number. 19 20 Point-to-Point Protocol (PPP). Refers to link layer protocol defined by IETF in RFC 21 1661. 22 23 PPP. See Point-to-Point Protocol. 24 25 Preferred Roaming List (PRL). Mobile station parameter that controls the process of 26 acquiring a wireless system. 27 28 PRL. See Preferred Roaming List. 29 30 Provisioning Agent (PA). Refers to the client side implementation of IOTA. 31 32 Push Access Protocol (PAP). Refers to the protocol between push initiator and the 33 push proxy gateway. See [17]. 34 35 Radio Access Network (RAN). Refers to the radio network infrastructure. 36 37 RAN. See Radio Access Network. 38 39 Request For Comment (RFC). Refers to type of specifications document released by 40 Internet Engineering Task Force (IETF). 41 42 RFC. See Request For Comment. 43 44 SAP. See Service Access Point. 45 46 Service Access Point (SAP). Refers to an addressable interface in the wireless 47 providers network that enables access to a service. 48 49 Service Programming Code (SPC). A secret code assigned to the mobile station and 50 known to the authorized network entity. 51 52 Service Programming Lock (SPL). A protection provided for preventing the over-the- 53 air provisioning of certain mobile station parameters by unauthorized network entity by 54 way of verifying the Service Programming Code (SPC). 55 14
3GPP2 C.S0040
1 Shared Secret Data (SSD). A 128-bit pattern stored in the mobile station (in semi- 2 permanent memory) and known by the base station. SSD is a concatenation of two 64- 3 bit subsets: SSD_A, which is used to support the authentication procedures, and 4 SSD_B, which serves as one of the inputs to the process generating the encryption 5 mask and private long code. 6 7 Short Message Service (SMS). See [4]. 8 9 SMS. See Short Message Service. 10 11 SPC. See Service Programming Code. 12 13 SPASM. See Subscriber Parameter Administration Mechanism. 14 15 SPC. See Service Programming Code. 16 17 SPL. See Service Programming Lock. 18 19 SSD. See Shared Secret Data. 20 21 Subscriber Parameter Administration Mechanism (SPASM). Security mechanism 22 protecting parameters and indicators of active NAM from programming by an 23 unauthorized network entity during the OTAPA session. 24 25 TLS. See Transport Layer Security. 26 27 TPD. See Trusted Provisioning Domain. 28 29 TPS. See Trusted Provisioning Server. 30 31 Transport Layer Security (TLS). A security protocol. See [20]. 32 33 Trusted Provisioning Domain (TPD). Refers to an Internet domain that is trusted by 34 the mobile stations and thus is permitted to perform provisioning and other 35 management operations. 36 37 Trusted Provisioning Server (TPS). Refers to server within the TPD that is trusted by 38 the mobile stations and thus is permitted to perform provisioning and other 39 management operations. 40 41 42 Uniform Resource Indicator (URI). Refers to a unique identifier of an entity or a 43 resource in a communications network. See [25]. 44 45 Uniform Resource Locator (URL). Refers to the unique address of an entity or a 46 resource in a communications network. See [25]. 47 48 URI. See Uniform Resource Indicator. 49 50 URL. See Uniform Resource Locator. 51 52 Visitor Location Register (VLR). A network element that acts as a proxy of HLR in the 53 visiting network for visiting mobile stations. 54 55 VLR. See Visitor Location Register. 15
3GPP2 C.S0040
1 2 WAP. See Wireless Application Protocol. 3 4 WBXML. See Wireless Binary Extensible Markup Language. 5 6 Wireless Application Protocol (WAP). Refers to set of protocols developed by Open 7 Mobile Alliance. See http://www.openmobilealliance.org. 8 9 Wireless Binary Extensible Markup Language (WBXML). See [12]. 10 11 WML. See Wireless Markup Language. 12 13 Wireless Markup Language (WML). Refers to specific mark up language developed by 14 Open Mobile Alliance for wireless devices. See http://www.openmobilealliance.org. 15 16 Wireless Session Protocol (WSP). Refers to session layer protocol defined by OMA. See 17 [15]. 18 19 WSP. See Wireless Session Protocol. 20 21 XML. See Extensible Markup Language.
22 23
16
3GPP2 C.S0040
1 2. General Requirements
2 2.1 Operations
3 • IOTA-HCM system shall be bearer independent and will work with any of the 4 following data communication services: 5 o Packet data link 6 o Circuit data link 7 • IOTA-HCM system shall support following provisioning scenarios: 8 o Network initiated 9 o Mobile station initiated 10 • The mobile station must have a facility (i.e., IOTA client) which can 11 communicate with a Trusted Provisioning Server (TPS) using an HTTP 12 connection for the purpose of facilitating the provisioning process. This facility 13 may be a WAP or a HTTP browser. WSP protocol is not required to support IOTA- 14 HCM. 15 • IOTA-HCM system shall support two (2) primary applications as indicated below: 16 o To provision a mobile station that does not have basic service 17 parameters. 18 o To provision a mobile station that have basic service parameters. 19 • In the case of the network initiated scenario, since the mobile station does not 20 normally have an IP address that is known to the network, the network must 21 send a transaction process trigger to the mobile station to notify the terminal 22 that provisioning is required. 23 o This trigger shall be sent as a mobile terminated SMS message as defined 24 in [4]. Teleservice identifier of the SMS message shall be set to WAP 25 teleservice identifier. 26 o When the mobile station receives this trigger, the mobile station shall 27 then initiate a provisioning request to the TPS by establishing a data 28 session using an available data service option and performing a HTTP 29 GET request to the TPS URL. 30 o WAP teleservice is used in segmentation/reassembly of content is sent 31 over multiple SMS messages. 32 o IOTA-HCM shall allow controlling end user messaging i.e. silent session 33 versus those that require user confirmation. 34 • The provisioning process shall consist of three (3) distinct steps, as indicated 35 below: 36 o During a bootstrap and/or trigger process, the mobile station shall be 37 provided with an indication that provisioning is required and with 38 knowledge regarding the access to the TPS. 39 o The mobile station shall then uses its knowledge of the TPS to access 40 that server, negotiate the parameters for the actual provisioning data 41 transfer, and establish a data session to facilitate the provisioning 42 process. This negotiation of a provisioning process may also occur when 43 the mobile station accesses the TPS via a normal browsing sequence (i.e., 44 rendezvous application). 45 o Provisioning data shall then be transferred between the server and the 46 mobile station. This transfer shall not be considered complete by the 47 TPS until the mobile station confirms the receipt of all provisioning data. 48 In order to simplify mobile station implementation, the protocol need not 49 support “transaction rollback” (i.e., cancellation or reversal of previously 50 confirmed provisioning data. Transaction rollback may be performed by
17
3GPP2 C.S0040
1 an additional provisioning session that updates the mobile station 2 provisioning in a manner that accomplishes the rollback requirement.
3 2.2 Protocol Requirements
4 The IOTA-HCM provisioning client and server shall conform to the following: 5 • Support circuit-switched data or packet switched data. 6 • Internet Protocol (IP) [18]. 7 • Minimum client support for HTTP 1.0 [2], preferably HTTP 1.1 [3]. 8 • OTASP and OTAPA [10]. 9 • Server/Proxy support for HTTP 1.1 [3]. 10 11 Also, the IOTA-HCM provisioning client and server should conform to the following: 12 • When A-Key exchange and SSD update procedures are desired, the server 13 should support [16] to interface with HLR/AC. 14 • When bootstrap or network initiated sessions are desired, server should support 15 Push Access Protocol [17] to interface with Push Gateway (or Message Center). 16 • When transport layer security is desired, client and server should support 17 Transport Layer Security (TLS) [20]. 18 19 IOTA-HCM shall use protocols as specified by [10] and [16] without any changes to the 20 protocol. 21 22 Figure 2.2-1 illustrates protocols between various entities in the IOTA-HCM network.
MS OTASP/ Parameter IOTA Push IOTA OTAPA RAN PDSN HA HLR/AC Storage Client Stack Gateway Server Data Service Option PPP
Mobile IP (optional) WAP Push WAP PAP HTTP
IOTA
Propreitary OTASP/OTAPA (tunneled over IOTA) IS-725-A 23 24 Figure 2.2-1 IOTA HCM Entities and Protocols
25 2.3 Architecture
26 2.3.1 Trusted Provisioning Server (TPS)
27 The overall control of the IOTA Handset Configuration Management system and all 28 programmed/program data shall be maintained on a Trusted Provisioning Server (TPS). 29 This server shall be IP-based. 30 31 The TPS must also have an interface to the carrier’s back-end and billing system. This 32 interface serves to synchronize the TPS to the information in the back-end systems and 33 account records. The specific requirements of this interface are not the subject of this 34 document. The TPS receives dynamic updates from the back-end system. 35
18
3GPP2 C.S0040
1 For OTASP and OTAPA functions, the TPS is very similar in functionality to the OTAF 2 (over-the-air function) specified in [16] and referenced in [10].
3 2.3.2 Communication with the Mobile Station
4 The following requirements apply to communication with the mobile: 5 • Programming operations shall use any data connection supported by the air 6 interface. If a service provider already has data transport services, no changes to 7 the core network infrastructure shall be required to support IOTA. IOTA shall 8 only impact the mobile station and the TPS. 9 • The use of mobile-terminated SMS per [4] shall be required. 10 • This system shall support network initiated programming operations. 11 • The mobile station shall be able to manage and interpret URLs. 12 • When network initiated IOTA operation is desired, both the MC and the mobile 13 station should support WAP teleservice identifier to enable WAP Push based 14 bootstrap and IOTA triggers. 15 16 The recommended architecture for the IOTA Handset Configuration Management 17 platform is illustrated in Figure 2.3.2-1:
18 19
Provisioning Server Client WAP Push
Bootstrap SAP Prov Bootstrap Data Service Agent Bootstrap System Specific Billing backend Provisioning Provisioning Protocol Interface Protocols Provisioning Service Agent(s) OTA OTA Customer Service SAP SAP Provisioning Admin Provisioning TA Data Other Client Provisioning Transaction Protocol HTTP/WSP
20 Figure 2.3.2-1 IOTA Handset Configuration Management Architecture
21 2.3.2.1 Provisioning Transaction Agent
22 The Provisioning Transaction Agent manages the transport mechanism by which 23 provisioning information can be exchanged between the TPS and the MS. It uses 24 functionality of HTTP [3] or WSP [15]. The client creates a session and the provisioning 25 information is downloaded (pushed or requested) within that session. The session may 26 be secure.
19
3GPP2 C.S0040
1 2.3.2.2 Provisioning Service Agent
2 The Provisioning Service Agent manages specific provisioning and configuration tasks. 3 This includes handling specific provisioning content, validating the provisioning request 4 and store (if required), and generation of the status indications to the TPS.
5 2.3.2.3 Bootstrap Service Agent
6 The Bootstrap Service Agent manages the receipt and programming of the initial contact 7 parameters for IOTA based provisioning. The Bootstrap Service Agent is used only to 8 program the initial set of parameters required to reach the TPS. In this architecture, 9 the wireless network provides the conduit through which the mobile station and the 10 TPS can communicate HCM requests and responses.
11 2.3.3 Security Mechanisms
12 There are several functional processes in the IOTA HCM provisioning mechanisms. 13 Each of these processes has specific and definable security requirements. To ensure the 14 requirements for each functional process are met, the IOTA HCM includes several 15 security mechanisms, each designed to secure a specific function of the provisioning 16 process that, when layered provide a robust and secure provisioning environment. 17 18 These security mechanisms are as follows: 19 • Trusted Provisioning Domain 20 • Subscriber Parameter Administration Security Mechanism (SPASM) 21 • Service Programming Lock 22 • TPS Authentication during Bootstrap (i.e. Bootstrap Hash or User PIN) 23 • NAI based authentication for cdma2000 capable mobile stations 24 • Session Security
25 2.3.3.1 The Trusted Provisioning Domain (TPD)
26 TPD is the domain name and protocol identifying the trusted provisioning server(s). The 27 TPD allows the carrier to define a controllable domain and the TPS from which all 28 provisioning content (e.g. the provisioning control document) must originate. The mobile 29 station shall ignore provisioning requests that originate outside this domain. 30 31 The TPD shall take the form of a Universal Resource Identifier (URI), as defined in [25]. 32 The TPD shall be communicated to the client during the bootstrap process.
33 2.3.3.2 Subscriber Parameter Administration Security Mechanism (SPASM)
34 See Section 3.3.7 in [10].
35 2.3.3.3 Service Programming Lock (SPL)
36 See Section 3.3.6 of [10].
37 2.3.3.4 Bootstrap Security
38 See Section 6.2 and 7.3 of [7].
20
3GPP2 C.S0040
1 2.3.3.5 NAI Authentication for cdma2000 Mobile Stations
2 cdma2000 mobile stations shall use NAI and AAA shared-secret associated with the 3 Mobile IP or Simple IP profiles as defined in [10] that have NAI_ENTRY_INDEX set to 4 0x00 to authenticate itself with the network and the TPS. For authenticating with the 5 TPS, mobile station shall support one of the following authentication mechanisms [19]: 6 • HTTP Digest. 7 8 Minimum of one Mobile IP or Simple IP profiles with NAI_ENTRY_INDEX set to 0x00 9 shall be programmed in the mobile station memory using one of the following methods: 10 • Pre-programmed at the factory or the shop. 11 • Bootstrapped over-the-air. See Section 7. 12
13 2.3.3.6 Session Security
14 IOTA sessions may be secured to protect sensitive data. To facilitate this, IOTA Client 15 shall support TLS [20]. 16 17 Secure sessions require root security certificates. These certificates are provisioned into 18 the mobile station at the time of manufacturing. 19 20 Mobile station shall use root certificate to authenticate identity of the IOTA-HCM server. 21
21
3GPP2 C.S0040
1 3. Provisioning
2 3.1 The Provisioning Processes
3 3.1.1 Initiation
4 Provisioning shall be initiated by one of the following triggers: 5 1. Network initiated trigger, where a push message from the network starts the 6 provisioning process. The trigger notifies the mobile station it needs to be (re-) 7 provisioned by initiating a request to the TPS. Optionally, included in this trigger 8 is the URL of the TPS, which is used to establish a session with the provisioning 9 server. If the TPS-URL is not defined in the trigger message, then the URL 10 defined in the phone:bootstrap...provurl (see Appendix B.1) object during 11 bootstrap is used. 12 2. Mobile station initiated, where the mobile station initiates a data call and 13 performs a HTTP request to the TPS-URL. For example, the mobile station 14 detects that it lacks necessary configurations and automatically initiates re- 15 provisioning.
16 3.1.2 Mobile Station Rendezvous
17 If the mobile station does not have an active data call or session with the TPS, one is 18 established (it is assumed that the address of the provisioning SAP or proxy was already 19 known to the mobile station). Optionally, depending on the desired security level, this 20 may involve the establishment of a secure session. The mobile station initiates an HTTP 21 request to the provisioning URL.
22 3.1.3 Provisioning Message Exchanges
23 1. The provisioning SAP or proxy delivers the HTTP request to the provisioning 24 server. 25 2. The provisioning server replies with content. 26 3. The provisioning SAP or proxy delivers the content to the mobile station. 27 4. The mobile station processes the content from the provisioning server as part of 28 the standard browsing model - there is no special processing model as all 29 provisioning content is clearly identified in the response. 30 5. The content from the provisioning server may contain both content intended for 31 provisioning in the mobile station and standard browsing content (e.g., WML, , 32 HTML, etc.). Browsing content is included when end user messaging or 33 interaction is involved. 34 6. Additional content may be provisioned by automatically requesting additional 35 URLs from the provisioning server. 36
37 3.1.4 Bootstrap Mechanism
38 The bootstrap process consists of supplying the mobile station with information 39 necessary to contact the TPS. Additionally, security mechanisms shall be employed to 40 ensure the trust relationship between the TPS and the mobile station.
22
3GPP2 C.S0040
1 3.1.5 Provisioning Activation (PA) Code
2 The user may direct the mobile station to initiate programming procedures by entering 3 a PA code. The mobile station shall allow the user to enter a choice of service provider 4 as part of the bootstrap procedure. The user may manually enter the PA code (star code) 5 for the selected system using the following dial-string sequence: 6 • *PA(D or V) + XX 7 • *PAV – Provisioning Activation-Voice (*728). This dial-string indicates to the 8 base station that the call type is IOTA-HCM with a voice call to the CSC. 9 • *PAD – Provisioning Activation-Data (*723). This dial-string indicates to the 10 base station that the call type is IOTA-HCM with a data call to the TPS. 11 • XX – System selection code. This code indicates the system selected by the user. 12 See Table 3.2-1 of [10] for list of system selection codes. 13 14 In order to initiate a data call, the mobile station should be preprovisioned with the 15 connectivity parameters at the factory, at the shop, or over-the-air using bootstrap.
16 3.2 Provisioning Content
17 3.2.1 Overall Approach
18 IOTA provisioning commands and the data are exchanged over-the-air using Mobile 19 Management Command (MMC) documents. MMC document is an XML document and is 20 specified in textual XML and optionally in binary XML. This document specifies a set of 21 registers or elements to be read or written from/into the memory of the MS, or a series 22 of provisioning commands/operations to be executed by a Provisioning Service Agent. 23 Each MMC document contains one or more operations or requests. 24
25 3.2.2 Major Elements of MMC
26 The MMC document describes the provisioning and mobile-management related 27 operations. It consists of three (3) major elements: 28 1. ‘mmc’ is the overall container of the specification. 29 2. ‘method’ element is used to invoke a specific operation, such as updating a 30 mobile station specific parameter or register. 31 3. ‘status’ element is used to communicate status from the mobile station to the 32 TPS. Status is reported for the overall operation, and optionally for each 33 operation invoked by an MMC method. 34 4. ‘detail’ element contains explicit status detail of a methodical operation specified 35 in a MMC document.
36 3.3 XML specifications of MMC
37 3.3.1 MMC DTD
38 42 43 44 23
3GPP2 C.S0040
1 5 6 7 8 13 14 15 16 24 25 26 27
39 3.3.2 MMC DTD Elements
40 3.3.2.1 The ‘mmc’ Element
41 The mmc element specifies a list of functions, their parameters, and control information 42 required to perform the specified operation. The mmc element may contain one or more 43 methods or status reports. The operations contained within the mmc element are 44 processed in the order encountered. Status reports are sent only from the mobile 45 station to the TPS. 46 47 XML DTD 48 49
3GPP2 C.S0040
1 > 2 3 Attributes 4 mmcID=nmtoken 5 The mmcID contains the MMC session ID assigned by the client following an 6 MMC session open request. The only time this attribute is optional is if the MMC 7 document contains an OPEN request. If the mmcID does not match the current 8 MMC session ID the client shall reject the MMC document. 9 10 status-uri=cdata 11 The status-uri attribute is required to be sent from the server to the client and 12 specifics the resource to which status will be posted. If a URL is specified, it 13 must be an absolute URL.
14 3.3.2.2 The ‘status’ Element
15 The status element provides the overall status for a set of operations contained in the 16 MMC document. The status element may contain zero or more detail elements. 17 18 XML DTD 19 20 21 25 26 Attributes 27 mmcID=nmtoken 28 The mmcID attribute contains the MMC session ID for this request. If this status 29 message is posted in responses to a MMC session open request, this value 30 contains the ID for the current MMC session. 31 32 mmc=cdata 33 The mmc attribute provides the overall status of all operations specified in an 34 mmc document. If all operations succeed and no method requires a detailed 35 status, the status message does not need to be sent (e.g. it is sent for failures 36 only or when a specific method requests a status detail).
37 3.3.2.3 The ‘detail’ Element
38 The detail element contains explicit status detail of a methodical operation specified in 39 an mmc document. A detail element is included for each read function unconditionally, 40 and every function that indicates detail is required with the reportstatus attribute. For 41 read operations, the returned result can be either referenced via a URI using the 42 valueref attribute or be a well-known token value via the value attribute. 43 44 XML DTD 45 46 47
3GPP2 C.S0040
1 valueref CDATA #IMPLIED 2 result CDATA #IMPLIED 3 > 4 5 Attributes 6 id=nmtoken 7 The id attribute associates the detail elements in the response with the method 8 element in the request. 9 10 name=( open|read|write|commit|disconnect) 11 The name attribute specifies the operation that was executed. 12 13 object=cdata 14 The object attribute specifies the parameter it affects. The object attribute may 15 either be a semi-well known or mobile station specific tag that identifies the 16 specific register to be accessed. The object attribute takes the form of a URI. If 17 the URI is an absolute URL, the operation should be performed on the mobile 18 station cache memory. Section 5 contains a list of known object attributes. 19 20 value= cdata 21 The value attribute may be included to specify the returned result. The value 22 attribute is used for specifying simple values such as “ENABLE”, “ON”, 23 “DISABLE”, “OFF”, or simple text strings. 24 25 valueref=cdata 26 The valueref attribute may be included to specify a link to the value that is to be 27 returned as a result of the operation. The content type of the data referenced will 28 be mobile station dependent. If the content type is unknown it shall be returned 29 as application/octet-stream and it will be the responsibility of the Provisioning 30 Service Agent to understand and process the content. It is intended that the URI 31 shall contain a link pointing to another element within a multipart/related using 32 the cid: scheme as defined in [29]. 33 34 result= cdata 35 Contains the status result and reason code of the requested operation.
36 3.3.2.4 The ‘method’ Element
37 The method element defines the operation, parameter, and value data to be used in an 38 operation on a specific register in the mobile station. The value data can be either 39 referenced via a URI using the valueref attribute or be a well-known token value via the 40 value attribute. 41 42 XML DTD 43 44 45
3GPP2 C.S0040
1 retryheader NMTOKEN #IMPLIED 2 retryvalue NMTOKEN #IMPLIED 3 > 4 5 Attributes 6 id=nmtoken 7 The id attribute provides a unique identifier for the operation specified. The id 8 must be unique only within a single MMC document. The server assigns the id. 9 10 name=( open|read|write|commit|retry|disconnect) 11 The name attribute specifies the function or operation to execute. 12 13 Where, 14 open: 15 Indicates the start of an MMC session. Only one MMC session is 16 allowed at a time. A disconnect (explicit or implicit) or a retry 17 method alone can end an MMC session. If a server requests a new 18 MMC session with a current session open, the client shall reject 19 the request. If the session is accepted, the client shall assign an 20 MMC session ID and report this session ID in the status detail 21 posted in the MMC response. All further MMC documents must 22 include this session ID in the mmcID field. 23 24 read: 25 Read a parameter or block of data. 26 27 write: 28 Writes the parameter value or a block of data reference by 29 valueref into temporary storage. 30 31 commit: 32 Transfers any parameters from temporary storage into permanent 33 memory associated with a provisioning session. 34 35 retry: 36 Clears any information in temporary memory associated with a 37 provisioning session and disconnects the MMC session and 38 causes the client to retry the last method that resulted in an 39 MMC context switch (for example, “HTTP GET 40 http://home.carrier.com/”). If included, the retryheader and 41 retryvalue attributes shall be appended by the client to the retried 42 request. The client shall retry the request using the same 43 methods and parameter (except as noted above) as the original 44 request. 45 46 disconnect: 47 Clears any information in temporary memory associated with a 48 provisioning session and disconnects the session and, if required, 49 the bearer associated with the provisioning session. 50 51 object=cdata 52 The object attribute specifies the parameter or registers to operate on. The object 53 attribute may either be a semi-well known or mobile station specific tag that 54 identifies the specific register to be accessed. The object attribute takes the form 55 of a URI. If the URI is an absolute URL, the operation should be performed on 27
3GPP2 C.S0040
1 the mobile station cache memory. Section 5 contains a list of standardized object 2 attributes. 3 4 value= cdata 5 The value attribute may be included to specify the value that is to be written into 6 the parameter. The value attribute is used for specifying simple values such as 7 “ENABLE”, “ON”, “DISABLE”, “OFF”, or simple text strings. The value attribute 8 applies only to the write method. 9 10 valueref=cdata 11 The valueref attribute may be included to specify a link to the value that is to be 12 stored in the register. The content type of the data referenced is parameter 13 specific. It is the responsibility of the Provisioning Service Agent to understand 14 and process the content. If a URL is specified, it must be an absolute URL. Any 15 URI may be specified however, it is intended that the URI shall contain link 16 pointing to another element within a multipart/related using the cid: scheme as 17 defined in [29]. 18 19 offset=nmtoken 20 The offset attribute specifies the offset of the block of data in octets, relative to 21 the start of the overall object being stored. 22 23 size=nmtoken 24 The size attribute specifies the size of the object to be read or written in octets. 25 Using both offset and size attributes allows for the transfer of partial objects. 26 27 reportstatus=(true|false) 28 The reportstatus attribute is used to request an explicit status detail for the 29 requested method. Note that in all cases a read operation will generate a status 30 detail regardless of the value of the status attribute. 31 32 retryheader=cdata 33 If the mmc retry method is specified, this attribute contains an optional 34 HTTP/WSP header to include with the retried request. Applicable to MMC retry 35 method only. 36 37 retryvalue=cdata 38 If the retry method is specified, it shall contain value (or data) of the retryheader 39 to be included with retried request. Applicable to MMC retry method only.
40 3.4 MIME Types and HTTP Headers
41 3.4.1 MIME Types
42 The MIME content format and the use of the MIME Content-ID header field and the 43 MIME Multipart/Related content-type is defined in [28]. This specification shall be 44 supported by mobile station and the TPS in order to understand MMC XML MIME 45 documents. 46 47 The MMC XML Content-Type shall be specified to be one of the following: 48 • application/iota.mmc-xml: For textual XML MMC documents. 49 • application/iota.mmc-wbxml: For WBXML encoded MMC documents. 50
28
3GPP2 C.S0040
1 The MMC XML document is able to reference other parts in a multipart/related 2 document by specifying the content ID in the valueref attribute of a method. The other 3 parts that the MMC document reference can be any valid content type that the browser 4 is able to process (such as WML decks and HTML).
5 3.4.2 Accept Headers for Supported MIME Content Types
6 While performing HTTP requests to the TPS, IOTA client shall add IOTA client content 7 types accepted by the client in the HTTP accept headers. 8 9 For the MMC documents sent in XML (uncompiled) format, following MIME type shall 10 be used: 11 12 • Content-Type: application/iota.mmc-xml 13 14 For the MMC documents compiled using WBXML as specified in this document, 15 following MIME type shall be used: 16 17 • Content-Type: application/iota.mmc-wbxml
18 3.4.3 Including IOTA Version in the HTTP Headers
19 While performing HTTP requests to the TPS, IOTA client must add IOTA version 20 supported in the HTTP headers in the form of IOTA/
25 3.5 Example IOTA Commands
26 3.5.1 Opening a Session
27 3.5.1.1 Request (Server to Client)
28 -- 29 Content-Type: application/iota.mmc-xml 30 Cache-Control: No-cache 31 32 33 35 36
29
3GPP2 C.S0040
1 3.5.1.2 Response (Client to Server)
2 --- 3 Content-ID:
20 3.5.2 OTASP and OTAPA Tunneling
21 3.5.2.1 Request (Server to Client)
22 -- 23 Content-Type: application/iota.mmc-xml 24 Cache-Control: No-cache 25 26 27 29 30 3GPP2 C.S0040 1 reportstatus="true" 2 object="phone:cdma.is683.result" /> 3
9 3.5.2.2 Response (Client to Server)
10 --- 11 Content-ID:
34 3.5.3 Arbitrary Binary Object Download
35 3.5.3.1 Request (Server to Client)
36 -- 37 Content-Type: application/iota.mmc-xml 38 Cache-Control: No-cache 39 40 41 43 44 3GPP2 C.S0040 1 name="write" 2 reportstatus="true" 3 object="phone:arbitrary" 4 value="" /> 5 6
19 3.5.3.2 Response (Client to Server)
20 --- 21 Content-ID:
32
3GPP2 C.S0040
1 3.5.4 Disconnect
2 3.5.4.1 Request (Server to Client)
3 --- 4 Content-ID:
32 3.5.4.2 Response (Client to Server)
33 No response is received for the above request since reportstatus is set to FALSE for all 34 commands and the document contains disconnect method. 35
36 3.6 Use of HTTP and WSP Methods
37 IOTA shall use following HTTP or WSP methods: 38 • GET method, for initial request to TPS URL from the client. 39 • POST method, to post results of the IOTA operations to the TPS. 40 41 The mobile station begins a provisioning transaction by requesting content at a 42 particular URL in response to a trigger event (i.e. network-initiated SMS message). The 43 mobile station establishes an HTTP session with the TPS and performs a GET method 44 with the requested URL. Included in the GET method is some collection of HTTP 45 headers. 46 47 In addition to tailoring the returned provisioning content based on the ACCEPT list 48 contained in the HTTP header, TPS should be capable of tailoring the returned 33
3GPP2 C.S0040
1 provisioning content according to the identification of the requesting entity in the HTTP 2 headers. For this reason, it is required that the requesting entity includes the User- 3 Agent HTTP header, in every GET request. The User-Agent header must include a single 4 Product field. The Product field must consist of two or more Tokens where the first 5 Token represents the Manufacturer and Version number of the provisioning agent (or 6 browser, if applicable) and the second Token represents the Manufacturer and Version 7 number of the MS. Both fields must be present even if there is redundant information 8 (e.g. the manufacturer for the mobile station and the provisioning agent are the same) 9 in order to afford the maximum granularity in selecting the correct provisioning 10 information for a particular mobile station. 11 12 In addition, client shall support headers specified in Sections 3.4.2 and 3.4.3. 13 14 The GET Request HTTP headers should also carry the client authorization credentials, if 15 such credentials have been received during bootstrap.
16 3.7 The Provisioning Multipart
17 The TPS conveys to the mobile station at least one multipart/related content type 18 containing content and information that is intended for use in the provisioning process. 19 The provisioning multipart/related entity has the following characteristics: 20 • The first body part of the entity must have a content type of 21 application/iota.mmc-xml. The format of this body part is as specified in the 22 DTD, including a status URI. When all of the subsequent body parts of the 23 multipart/related entity have been processed, a status message will be posted 24 from the mobile station to this URI. 25 • The entire entity must originate from a TPS in a trusted provisioning domain 26 (TPD). 27 • The mobile station processes the subsequent body parts within the 28 multipart/related only if they are referenced with in the MMC document. 29 • Provisioning multipart/related entities may be nested, i.e. a provisioning 30 multipart/related entity may contain another multipart used in the provisioning 31 scheme.
32 3.7.1 Example of Provisioning Multipart
33 When the MMC content type is transported it is treated as one message in the 34 provisioning process. The type parameter of the multipart/related conveys the content 35 type of the entire operation. This allows the IOTA client to manage the entire entity as 36 one object. The type parameter shall be set to application/iota.mmc-xml. 37 38 -- 39 Content-Type: application/iota.mmc-xml 40 Cache-Control: No-cache 41 42 43 45 3GPP2 C.S0040 1 reportstatus="false" 2 object="phone:cdma.is683" 3 value="" /> 4 5
23 3.7.2 The Provisioning Multipart Response
24 Upon completion of the processing and storage of the provisioning information in the 25 provisioning multipart, the ME initiates an HTTP POST operation with status 26 information to the status URI, defined in the first body application/iota.mmc-xml. 27 Status is reported for all call functions in the provisioning multipart. Status information 28 for each failed (and succeeded) call function is identified according to the identifier 29 defined in the provisioning request. Both successful and failed installations are 30 reported. 31 32 The status report is done with the following characteristics: 33 • HTTP POST to the status URI, with content-type of multipart/related 34 • There is a detail element in the first body part (Provisioning-operation) for each 35 call function in the provisioning request. Each detail element might reference a 36 body part in the multipart related. If a body part in the original provisioning 37 multipart entity is itself an embedded multipart it is treated as a single entity for 38 the purpose of reporting status. 39 • The call function element is identified by an id. Each status element associated 40 with each call function is recognized based on this common identifier. The 41 status element returns a normalized status. The referenced part can provide a 42 response that is dependent on the provisioning content type. 43 44 Replies that contain long binary data will be sent as a multipart/related. 45 --- 46 Content-ID:
3GPP2 C.S0040
1
36
3GPP2 C.S0040
1 4. Encoding Based on WBXML
2 3 5 6
3GPP2 C.S0040
1
38
3GPP2 C.S0040
1
39
3GPP2 C.S0040
1 5. IOTA Objects
2 Over-the-air parameters are defined as IOTA objects. Object names shall comply with 3 the following format: 4 Object Naming Convention Object Types browser:
Example, browser:ssl..0.cert browser:ssl..1.cert 5 Table 5-1 IOTA Object Naming Convention 6 7 IOTA object names are case insensitive. IOTA compliant mobile station and the server 8 shall support standardized objects as specified in Appendix B.
9 6. OTASP and OTAPA Tunneling
10 In order to use protocol capabilities and security features defined in [10] and also to 11 enable interoperability with [10], IOTA shall support OTASP and OTAPA tunneling as 12 specified in this section. 13 14 Tunneling is a process where the OTASP or the OTAPA messages are exchanged over 15 HTTP or WSP transports using the IOTA messages. In the OTASP and OTAPA 16 specifications [10], such messages are exchanged over-the-air as data-burst messages. 17 18 All requirements, except transport requirements defined in [10] for processing, storing 19 and securing OTASP and OTAPA messages and parameter blocks shall apply when 20 OTASP or OTAPA is tunneled over IOTA. OTASP and OTAPA request messages are sent 21 (from server to the client) by writing the binary content in the format specified by [10] in 22 to phone:cdma.is683 object (see Appendix B.7). 23 24 OTASP and OTAPA response messages are received by reading the binary content in the 25 format specified by [10] protocols using phone:cdma.is683.result object (see Appendix 26 B.7). 27 28 Operations performed using IOTA shall be consistent with OTASP and OTAPA 29 operations defined in [10].
30 7. IOTA Bootstrap Message
31 IOTA compliant mobile stations shall implement the WAP2.0 bootstrap specifications as 32 specified in the following: 33 • WAP Provisioning Content; See [5], 34 • WAP Provisioning Bootstrap; See [7]. 35 Mobile stations shall accept WAP2.0 bootstrap content and store them in the IOTA 36 objects as specified in Appendix C. Once bootstrapped, mobile station shall connect to
40
3GPP2 C.S0040
1 URL specified by “CALLBACK-URL” (if any) in the bootstrap document. This will trigger 2 MMC based IOTA provisioning of PRL, NAM, etc. 3 4 Mobile station shall only use bootstrap data to connect to the network in order to 5 download permanent settings using IOTA. Bootstrap data shall not be stored for 6 permanent use. 7 8 Note that mapping between the WAP bootstrap parameters and IOTA objects alone are 9 specified in Appendix C. For specifications of the bootstrap parameters, please see [5].
10 8. IOTA Error Codes
11 IOTA client must support returning error codes specified in Table 8-1. Error strings are 12 case insensitive. IOTA error codes shall be used for mmc attribute in the status element 13 and result attribute in the detail element 14 Error string Comment Critical or Warning Ok IOTA operation is successful. Normal. InvalidValueRef The URI specified for valueref is not Critical Error an absolute URI. UnknownObject Could not find the element requested. Warning InvalidContent The content type is not allowed. Critical Error Currently this happens if a display message or confirmation has a value other than text. UserDenied The user selected No to a Critical Error confirmation dialog or navigated off the confirm deck. BadValue The value is out of range or missing Critical Error (currently browser:psa.idletime returns this. See Appendix B.1). Timeout The browser:psa.idletime (see Critical Error Appendix B.1)has expired. NewDocArrived A new IOTA message arrived while Critical Error another document was being processed. The current document was interrupted. DeleteFailed Unable to delete the item. (Currently, Critical Error this happens if a cache item is in use). BadData The referenced entity could not be Critical Error processed, either there is an error in the data or the client does not handle the data type received. DisplayDisabled Message was not displayed because Critical Error the browser does not have control of the display. WriteOnly The given object cannot be read, only Critical Error written. Abort The IOTA operation was aborted. A N/A previous IOTA operation returned a critical error. 15 Table 8-1 IOTA Error Codes 41
3GPP2 C.S0040
1 9. IOTA Trigger Message
2 IOTA server may trigger an IOTA session by sending one of the following: 3 • By setting CALLBACK-URL bootstrap message as per Section 7, 4 • By sending a WAP Push Service Load message with URL pointing to the IOTA 5 server, 6 • By sending WAP Push Service Indication message with URL pointing to the IOTA 7 server. 8 In order to reduce the mobile station processing and memory requirements, IOTA 9 triggers including the Bootstrap content (as specified in Section 7) must be sent using 10 WAP connectionless, unconfirmed, unsecured push message. Such push messages are 11 delivered to mobile station as segmented plain-text SMS messages with WAP teleservice 12 identifier set. 13 14 Push does not require a full-fledged WAP protocol stack in the client and hence mobile 15 station requirements are minimal.
16 10. Handling User Interrupts during IOTA Sessions
17 If the programming session is initiated by the network, and the mobile station is 18 directed by the user to initiate a call during the IOTA session, and both the mobile 19 station and the base station support concurrent service, the mobile station may initiate 20 the call by sending an Enhanced Origination Message. Otherwise, the mobile station 21 shall terminate the IOTA session and release the IOTA call prior to proceeding with the 22 origination procedure 23
42
3GPP2 C.S0040
1 Appendix A. IOTA-HCM Message Flows
2 A.1 Bootstrapping Message Flow Examples
3 The following message flow examples assume that the user is activating the mobile 4 station in the home service area. The message flows in Appendices A.1.1, A.1.2 and 5 A.1.3 are various options for the bootstrap process.
6 A.1.1 Voice-Call Assisted Bootstrapping of Un-programmed Mobile Station 7 (Default IMSI) – Mobile Station is Pre-loaded into HLR
8 In this scenario, the mobile station has a default IMSI (which is generated as defined in 9 Section 3.1 of [10]) pre-programmed at manufacturing time. The mobile station 10 (identified by default IMSI and ESN) is pre-loaded into the carrier’s HLR. As part of this 11 pre-loading the carrier will give the mobile station a “restricted services” profile that 12 limits services to customer services and emergency services. The subscriber uses the 13 mobile station to initiate the provisioning process. The process is illustrated in Figure 14 A1.1-1.
43
3GPP2 C.S0040
Serving System
MS MSC/ HLR TPS VLR MC
Registration a
REGNOT [MIN, ESN, SMSADDR,..] b
regnot RR [Profile,…] c
Voice Dialog between MS user and CSC Operator d
Bootstrap Msg [Data, …] e
SMS [Bootstrap Msg,..] f
Ack g
IOTA Server authentication
IOTA Provisioning Session h
1 2 Figure A.1.1-1 Voice-call Assisted Bootstrapping of Un-programmed Mobile Station (Default IMSI) – 3 Mobile Station is Pre-loaded into HLR 4 a. The user powers on the mobile station. A registration request is sent to the serving 5 MSC/VLR. 6 b. The MSC/VLR forwards a standard REGNOT Invoke (see [16)] to the HLR node 7 where the un-programmed mobile station is pre-loaded. 8 c. The HLR returns a standard regnot return result (see [16]) to the serving MSC. The 9 HLR restricts call originations to emergency services and to a set of predetermined 10 numbers (e.g. the CSC 800 number, IOTA access point). 11 d. The user dials the activation *FC code. The MSC may hot-wire the voice call to the 12 CSC. The user enters a dialogue with the service provider’s customer service
44
3GPP2 C.S0040
1 representative. The customer service representative collects subscriber details as 2 part of the carrier’s subscription process. 3 e. The subscriber is optionally provisioned in all the necessary systems (e.g. HLR, 4 Billing, etc.). The customer service representative disconnects the voice call with the 5 subscriber. The TPS node then sends a Bootstrap message to the MC node. The 6 Bootstrap message identifies the mobile station using the default IMSI (see Section 7 3.1 of [10] ) that is currently programmed in the mobile station and that is also 8 provisioned at the HLR. 9 f. The MC recognizes the Bootstrap message to be that for a mobile station with a 10 valid HLR provisioned record. The MC forwards bootstrap message to the serving 11 MSC as SMS message. The serving MSC forwards the Bootstrap message to the 12 mobile station as bearer data in the SMS Point-to-Point transport message [4]. 13 g. The mobile station returns an SMS transport acknowledgement to the serving MSC. 14 The serving MSC returns an acknowledgement to the MC. 15 h. Provided that the IOTA trigger was set in the Bootstrap message and authentication 16 of the TPS succeeded, the mobile station initiates an IOTA provisioning session with 17 the TPS (see Section 3.6). This action is an implicit acknowledgement of a 18 successful bootstrap. If required, the mobile station authenticates the TPS using the 19 authentication mechanism (see [7]). If authentication fails, the mobile station does 20 not update its memory with the downloaded TPS configuration. 21
22
45
3GPP2 C.S0040
1 A.1.2 Voice-call Assisted Bootstrapping of Un-programmed Mobile Station 2 (Default IMSI) – Mobile Station is Not Pre-loaded into HLR
3 In this scenario, the mobile station only has a default NAM programmed as defined in 4 [10], i.e. the IMSI is a default one generated by mobile stations (see [10] Section 3.1)) to 5 be used solely for activation procedures. The mobile station is not pre-loaded into the 6 carrier’s HLR. The subscriber uses the mobile station to initiate the provisioning 7 process. The process is illustrated in Figure A.1.2-1. 8
46
3GPP2 C.S0040
1
Serving System
MS MSC/ TPS VLR MC
Registration (TEMP_MIN) a
REGNOT [MIN, ESN, SMSADDR,..] b
regnot RR [ Digits (Destination), Profile c
Dialog between MS user and CSC Operator d
Bootstrap Msg [ESN, Bootstrap ] e
SMS [Bootstrap Msg] f
Ack g IOTA Server authentication
IOTA Provisioning Session h
2
3 Figure A.1.2-1 Voice-call Assisted Bootstrapping of Un-programmed Mobile Station (Default IMSI) – 4 Mobile Station is Not Pre-loaded into HLR 5 a. The user powers on the mobile station. A registration request is sent to the serving 6 MSC/VLR. 7 b. The MIN to HLR translation table at the MSC/VLR is data-filled to send registrations 8 for default IMSIs (generated by mobile as defined by Section 3.1 of [10]) to the SS7 9 point code of the MC node in the home network. The MSC/VLR forwards a standard 10 REGNOT Invoke (see [16]) to the MC node.
47
3GPP2 C.S0040
1 c. The MC recognizes the REGNOT Invoke to be that for a mobile station to be 2 bootstrapped using default IMSI. The MC stores the registration for the mobile 3 station (identified by ESN/default IMSI pair). A regnot Return Result is returned to 4 the MSC. The MC instructs the MSC to restrict originations to a set of numbers (i.e. 5 that of the customer service center and emergency services). 6 d. The user dials the activation *FC code. The MSC may hot-wire the voice call to the 7 CSC. The user enters a dialogue with the service provider’s customer service 8 representative. The customer service representative collects subscriber details as 9 part of the carrier’s subscription process. The user communicates via voice the ESN 10 of the mobile station. 11 e. The subscriber is optionally provisioned in all the necessary systems (e.g. HLR, 12 Billing, etc.). If the carrier’s network only supports mobile-terminated SMS over the 13 paging channel, the customer service representative disconnects the voice call with 14 the subscriber. The TPS node then sends a Bootstrap message to the MC node for 15 transmission via SMS. The Bootstrap message identifies the mobile station using 16 the ESN communicated in step d. 17 f. The MC recognizes the Bootstrap message to be that for an un-programmed mobile 18 station without a valid HLR record. It locates the registration record of the mobile 19 station (identified by ESN) as stored during step c. Included in the registration 20 record is the current serving MSC address and default IMSI of the mobile station. 21 The MC forwards the Bootstrap message to the serving MSC as SMS message. The 22 serving MSC forwards the Bootstrap message to the mobile station as bearer data in 23 the SMS Point-to-Point transport message [4]. 24 g. The mobile station returns an SMS transport acknowledgement to the serving MSC. 25 The serving MSC returns an acknowledgement to the MC. 26 h. Provided that the IOTA trigger was set in the Bootstrap message and authentication 27 of the TPS was successful, the mobile station initiates an IOTA provisioning session 28 with the TPS. This action is an implicit acknowledgement of a successful bootstrap. 29 If required, the mobile station authenticates the TPS using the authentication 30 mechanism (see [7]). If authentication fails, the mobile station does not update its 31 memory with the downloaded TPS configuration. 32
48
3GPP2 C.S0040
1 A.1.3 Automated Bootstrapping After Power-up
2 In this scenario, a user purchases a phone/service plan from a carrier via a web page or 3 a landline voice call to the CSC. 4 5 When the user eventually receives the mobile station, it may be preprogrammed with 6 varying amounts of bootstrap data from none to complete. In this case there is no 7 bootstrap data and only a temporary activation MIN. Note that prior to mobile station 8 power-up (step c), the CSC sends a bootstrap message to the MC destined for the 9 mobile's ESN. The process is illustrated in Figure A.1.3-1.
49
3GPP2 C.S0040
Serving System
MSC/ MS MC TPS VLR
off-line subscription a
Bootstrap [ESN, Bootstrap Data] b
Registration Order (TEMP_MIN) c
REGNOT [MIN, ESN, SMSADDR,..] d
regnot RR [ Digits (Destination), Profile] e
SMS [MIN ESN, Bootstrap Msg] f
Ack g
IOTA Server authentication
IOTA Provisioning Session h
1 2 Figure A.1.3-1 Automated Bootstrapping After Power-up 3 4 a. The customer subscribes for service in an off-line manner (e.g. via a web-page 5 interface, using a land-line, etc). The new subscriber is provisioned in all the 6 necessary business and network systems (e.g. HLR, Billing, etc.). 7 b. The TPS node within the CSC then sends a Bootstrap message to the MC node for 8 transmission via SMS. The Bootstrap message identifies the mobile station using 9 the ESN 10 c. Some time later, the customer receives the mobile station and powers it on. The 11 mobile station registers on the network with its default IMSI.
50
3GPP2 C.S0040
1 d. The IMSI to HLR translation table at the MSC/VLR is data-filled to send 2 registrations for default IMSIs with NPA’s = 000 to the SS7 point code of the MC 3 node in the home network. The MSC/VLR forwards a standard REGNOT Invoke (see 4 [16]) to the MC node 5 e. The MC recognizes the REGNOT Invoke to be that for a mobile station to be 6 bootstrapped by virtue of the IMSI parameter containing a default IMSI. A regnot 7 Return Result is returned to the MSC. The MC instructs the MSC to restrict 8 originations to a set of numbers (i.e. that of the customer service center and 9 emergency services). 10 f. The MC sends the bootstrap message to the mobile station using mobile-terminated 11 SMS. 12 g. The mobile station returns an SMS transport level acknowledgment to the MC. 13 h. If TPS authentication is successful and provided that the IOTA trigger is set in the 14 Bootstrap message, the mobile station initiates an IOTA provisioning session with 15 the TPS. This action is an implicit acknowledgement of a successful bootstrap. 16
51
3GPP2 C.S0040
1 A.1.4 Mobile Station Initiated Session – No Voice Call
2 In this scenario, user accesses a web site to request update of mobile station 3 parameters over-the-air – for example downloading latest PRL. The process is illustrated 4 in Figure A.1.4-1.
Serving System
PDSN MS RAN /HA TPS
User requests provisioning a
Data Session b
HTTP GET (TPS URL) c
IOTA Provisioning Session d
5 6 Figure A.1.4-1 Mobile Station Initiated Session – No Voice Call 7 8 a. User requests over-the-air provisioning, for example, using a mobile station menu 9 b. If the mobile station has no data connection with the network, it establishes data 10 connection using one of the available data service options. Mobile station may 11 optionally establish a Mobile IP session with the Home Agent (HA). 12 c. Once the IP data connection is available, the mobile station performs a HTTP GET 13 request to the TPS. TPS URL is made available to the mobile station by 14 preprogramming or bootstrapping the MS. 15 d. In response to HTTP GET request, TPS initiates IOTA session to update the mobile 16 station parameters.
17 18
52
3GPP2 C.S0040
1 A.1.5 Network Initiated Session – No Voice Call
2 In this scenario, carrier initiates mobile station parameter updates - for example to 3 download latest PRL. The process is illustrated in Figure A.1.5-1.
Serving System
PDSN MS RAN /HA MC TPS
Operator requests provisioning a
SMS [WAP Push Trigger (TPS_URL, …)] b
Data Session c
HTTP GET (TPS URL) d
IOTA Provisioning Session e
4 5 Figure A.1.5-1 Network Initiated Session – No Voice Call 6 7 a. Operator requests over-the-air provisioning through the TPS interface 8 b. TPS sends a network-initiated trigger using WAP Push message through the MC. 9 The WAP Push contains the TPS URL. 10 c. Mobile station receives the message. If the mobile station has no data connection 11 with the network, it establishes data connection using one of the available data 12 service options. Mobile station may optionally establish a Mobile IP session with the 13 Home Agent (HA). 14 d. Once the IP data connection is available, the mobile station performs a HTTP GET 15 request to the TPS URL provided in the WAP Push message. 16 e. In response to HTTP GET request, TPS initiates IOTA session to update the mobile 17 station parameters. 18
53
3GPP2 C.S0040
1 A.2 Provisioning Message Flow Examples
2 A.2.1 OTAPA Call Flow - PRL Update
3 In this scenario, network-initiated (OTAPA) update of the PRL list in a mobile station 4 that is already properly provisioned. The process is illustrated in Figure A.2.1-1.
MS BMI TPS
IOTA Trigger a
HTTP/WSP GET Request b
HTTP/WSP Reply, PRL data c
MS sends results of PRL update d
HTTP/WSP Reply, verifying PRL Update success & IOTA commit e
Results of Commit Request – HTTP/WSP POST f
Disconnect Request to Client g
Terminate Data Connection h h
update of PRL version attribute in subscriber record at the HLR (optional) i
5 6 Figure A.2.1-1 OTAPA Call Flow - PRL Update
54
3GPP2 C.S0040
1 a. The TPS sends an IOTA trigger message to the mobile station via SMS with the URL 2 of the OTAPA request. 3 b. On receipt of the IOTA trigger message, the mobile station establishes a data call 4 (via IS-835, IS-707, etc. procedures) and performs an HTTP/WSP GET session to the 5 URL identified in step a. When the link is established the IOTA client performs an 6 HTTP/WSP GET request for the provisioning information. 7 c. The TPS authenticates the client and sends an IOTA message to update the PRL list 8 data using OTASP and OTAPA tunneling (see Section 6). 9 d. The IOTA client executes the command to update the list and sends the result of the 10 operation to the TPS using HTTP/WSP POST. 11 e. The TPS verifies successful update, then formulates a Commit Request message as 12 defined in [10] and sends this to the IOTA client as a HTTP/WSP reply. Note: The 13 originating network element should be able to request the TPS report intermediate 14 results. This facilitates management of the provisioning logic by existing network 15 elements. 16 f. The IOTA client executes the commit request and sends the result of the operation to 17 the TPS using HTTP/WSP POST. 18 g. The TPS replies with a disconnect method to the IOTA client. 19 h. The IOTA client terminates the session and data connection. 20 i. Optionally, the TPS updates the PRL version attribute in subscriber record at the 21 HLR. 22
55
3GPP2 C.S0040
1
2 Appendix B. Standardized IOTA Objects
3 Standardizing names of the mobile station parameters is essential for ensuring 4 interoperability in a multi-vendor MS/server environment. Following specifies 5 standardized IOTA object names for the mobile station parameters. When such 6 parameters are implemented, the mobile station and server must comply with the object 7 names in this appendix and Appendix C. 8 9 Note: Implicit commit means that changes to the object values are effective immediately.
10 B.1 IOTA Security Settings
IOTA Object Name Description Type Size R/W Implicit Commit phone:prov.network.pin Network-based PIN. Text 4 RW No For CDMA, the last 4 hexa-decimal digits of ESN or carrier specified number. phone:prov.network.pin.verify Verifies Network-based Text 4 WO N/A PIN written to this object against that stored in the client.
When network PIN is set in the client, first command in any MMC session must be verify Network PIN.
For CDMA, the last 4 hexa-decimal digits of ESN or carrier specified number. phone:bootstrap...provurl Trusted domain that Text 128 R/W No browser uses to authenticate provisioning (MMC) content. Any provisioning content that is received from out-side of the trusted domain must be discarded.
This object also doubles as provisioning URL that mobile station might access to trigger IOTA session for downloading mobile station configuration.
56
3GPP2 C.S0040
IOTA Object Name Description Type Size R/W Implicit Commit browser:psa.idletime Sets timeout for how Text 4 RW No long it processes an IOTA message before terminating the operation.
The browser:psa.idletime object may be used to alter the default timeout of a provisioning session.
The unit for browser:psa.idletime is seconds and the range is 0 (off = disable the timeout) to 900 seconds (15 minutes). Its default value is 900 seconds.
If the timeout expires before the IOTA client has completed all methods of the document then all remaining methods are given a result of timeout and processing completes. 1 Table B.1-1 IOTA Security Settings
2 B.2 User Prompt Objects
IOTA Object Name Description Type Size R/W Implicit Commit Phone:beep This parameter is written to, Text 9 WO Yes client generates an audible tone. Possible values are: TONE, SUCCESS, FAIL, CONN_LOST, NONE.
When TONE is specified, phone will play a pre- configured single tone for number of times specified by phone:count.
Pre-configured tones are played for SUCCESS, FAIL and CONN_LOST.
57
3GPP2 C.S0040
IOTA Object Name Description Type Size R/W Implicit Commit Exact tone frequency and cadence will be mobile station dependent. phone:beep.count A string representing number Text 2 WO Yes of audio beeps to be played by the mobile station to alert the user. This can be a value of 1 to 9. browser:display.message The object Text 4K WO Yes browser:display.message is used to display a passive message on the screen during the provisioning process (such as during IOTA message processing). The first time the object is used within an IOTA session, the IOTA CLIENT displays the message to the subscriber. If the browser UI is inactive, the client signals to the mobile station to activate it. For each successive use of the browser:display.message object, the client updates the screen, replacing the old message with the new one.
The object browser:display.message can be used only as a parameter to the write function. The value attribute contains a simple text string that is displayed to the subscriber. This message remains displayed until it is overwritten or until the provisioning session is terminated, either by timeout or by receipt of a disconnect method.
Setting browser:display.message to an empty string clears the display. If a large text message is to be displayed, a URI can be provided using the valueref attribute. If the URI references a document with a content type that is
58
3GPP2 C.S0040
IOTA Object Name Description Type Size R/W Implicit Commit not understood by the mobile station or MMC Processor (the mobile station knows which content types it supports and can declare them to the browser), the browser:display.message object is ignored, and an error is returned in the status message, if requested. browser:display.confirm The object Text 4K WO Yes browser:display.confirm is used to display a confirmation message on the screen during the provisioning process (such as during the IOTA message processing). The first time the object is used within an MMC session, the client displays the confirmation to the subscriber. If the browser UI is inactive, the client signals to the mobile station to activate it. For each successive use of the browser:display.confirm object, the IOTA CLIENT updates the old confirmation message with the new one.
The object browser:display.confirm can be used only as a parameter to the write function. The value attribute contains a simple text string that is displayed to the subscriber, and the subscriber is requested to confirm or deny the message using mobile station keys. This confirmation message remains displayed until overwritten with another browser:display.confirm object, a browser:display.message object, or the provisioning session is terminated, either by timeout or by receipt of a disconnect method.
59
3GPP2 C.S0040
IOTA Object Name Description Type Size R/W Implicit Commit
If the subscriber denies the request by choosing No, the IOTA client processing stops processing the IOTA message and reports a status to the Provisioning Manager. If the subscriber confirms the message by choosing Yes, the IOTA processing continues to process the IOTA message and includes the user confirmation status, if requested, upon completion of the IOTA message processing.
If a large text message is to be displayed, a URI can be provided using the valueref attribute. If the URI references a document with a content type that is not understood by the mobile station or MMC Processor, the browser:display.confirm function is ignored and an error is returned in the status message, if requested.
1 Table B.2-1 User Prompt Objects
2 B.3 Mobile Station Settings
IOTA Object Name Description Type Size R/W Implicit Commit phone:date.format Date format. Default value is Text 16 R/W No mm/dd/yy (i.e. the US format). Any combination of the following conversion specifications can be used to create the date format: %d day of the month (01-31) %m month (01-12) %y year without century (00- 99) %Y year with century (4 digit) If a zero-length format is set, the browser uses the default date format value. Formats containing unknown conversion specifications are 60
3GPP2 C.S0040
IOTA Object Name Description Type Size R/W Implicit Commit not illegal Examples of date format are: mm/dd/yy e.g. 01/31/89 mm-dd-yy e.g. 01-31-89 dd/mm/yy e.g. 31/01/89 yyyy. Mm. dd. e.g. 1989. 01. 31. yy. mm. dd e.g. 89. 01. 31 yy.mm.dd e.g. 89.01.31 yy mm dd e.g. 89 01 31 dd-mm-yy e.g. 31-01-89 dd.mm.yy. e.g. 31.01.89 dd.mm.yyyy e.g. 31.01.1989 yy.dd.mm e.g. 89.31.01
1 Table B.3-1 Mobile Station Settings
2 B.4 Mobile Station Diagnostics
IOTA Object Name Description Type Size R/W Implicit Commit phone:rssi Receive signal strength in Text 6 RO N/A dBm, example “-105”. phone:battery.level A string representing the Text 4 RO N/A current battery level, expressed in percentage. “100” represents fully charged. 3 Table B.4-1 Mobile Station Diagnostics
4 B.5 Mobile Station Capabilities
IOTA Object Name Description Type Size R/W Implicit Commit phone:model A string that Text 17 RO N/A represents the model ID for the MS.
This object returns the value stored in MOB_MODELp as defined in [10].
Value is encoded ASCII encoded hexadecimal string. For example, “0x12”.
61
3GPP2 C.S0040
IOTA Object Name Description Type Size R/W Implicit Commit phone:oem A string that Text 65 RO N/A represents the name of the manufacturer. phone:psa.version A string that Text 17 RO N/A represents the version of the provisioning service agent. phone:version.software A string Text 17 RO N/A representing the version of system software of the MS.
This object returns the value stored in MOB_FORM_RE Vp as defined in [10].
Value is encoded ASCII encoded hexadecimal string. For example, “0x1234”. 1 Table B.5-1 Mobile Station Capabilities
2 B.6 Browser Settings
IOTA Object Name Description Type Size R/W Implicit Commit phone:tls.x509.rootcert.. Up to four Application/octet- 4K R No objects are stream (binary) used to store root certificates for SSL or TLS. Writes performed to a specific array overwrites any previous data. Client must support "DER encoded binary X.509 (.CER)" format. could be
62
3GPP2 C.S0040
IOTA Object Name Description Type Size R/W Implicit Commit 0 to 15. Minimum of four certificates must be supported. 1 Table B.6-1 Browser Settings
2 B.7 CDMA Settings
IOTA Object Name Description Type Size R/W Implicit Commit phone:cdma.base.lat CDMA Base Latitude Text 22 RO N/A Base station latitude as a string using decimal digits and an optional sign character.
This object returns, base station latitude as received by the mobile station in the system parameters message. phone:cdma.base.long CDMA Base Longitude Text 23 RO N/A Base station longitude as a string using decimal digits and an optional sign character.
This object returns, base station longitude as received by the mobile station in the system parameters message. phone:cdma.is683 Used in tunneling Application/octet- 64K WO Yes OTASP and OTAPA stream (binary) request messages as defined in [10] using IOTA. Values must conform to binary format as specified in [10]. phone:cdma.is683.result Used in tunneling Application/octet- 64K RO No OTASP and OTAPA stream (binary) response messages as define in [10] using IOTA. Values must conform to binary format as specified in [10]. phone:cdma.nam.select A string representing Text 2 RW No
63
3GPP2 C.S0040
IOTA Object Name Description Type Size R/W Implicit Commit the current NAM identifier (ID) selected for provisioning via IS683a. IS683A does not support NAM selection, so the value of this parameter selects the NAM that subsequent IOTA transactions refers to via MMC access of phone:cdma.is683. Example values are "1" and "2". The default value for this parameter should be “1”. phone:cdma.nam.user A string representing Text 2 RO N/A the NAM identifier (ID), which the user has manually set as the current NAM. Example values are "1" and "2". phone:cdma.sid.current A string representing Text 5 RO N/A the current SID between 0000-FFFF 1 Table B.7-1 CDMA Settings 2
64
3GPP2 C.S0040
1 Appendix C. WAP Bootstrap Parameter to IOTA Object Mapping
2 This section defines mapping between WAP bootstrap parameters as defined in [5] and 3 equivalent IOTA objects.
4 C.1 PXLOGICAL Characteristics
WAP Provisioning IOTA Object PROXY-ID browser:pxlogical...proxy-id PROXY-PW browser:pxlogical...proxy-pw PPGAUTH-TYPE browser:pxlogical...ppgauth-type PROXY-PROVIDER-ID browser:pxlogical...proxy-provider-id NAME browser:pxlogical...name DOMAIN browser:pxlogical...domain.. TRUST browser:pxlogical...trust MASTER browser:pxlogical...master STARTPAGE browser:pxlogical...startpage BASAUTH-ID browser:pxlogical...basauth-id BASAUTH-PW browser:pxlogical...basauth-pw WSP-VERSION browser:pxlogical...wsp-version PUSHENABLED browser:pxlogical...pushenabled PULLENABLED browser:pxlogical...pullenabled 5 Table C.1-1 PXLOGICAL Characteristics
6 C.2 PXLOGICAL.PXAUTHINFO Characteristics
WAP Provisioning IOTA Object PXAUTH-TYPE browser:pxlogical...pxauthinfo...pxauth-type PXAUTH-ID browser:pxlogical...pxauthinfo...pxauth-id PXAUTH-PW browser:pxlogical...pxauthinfo...pxauth-pw 7 Table C.2-1 PXLOGICAL.PXAUTHINFO Characteristics
8 C.3 PXLOGICAL.PORT Characteristics
WAP Provisioning IOTA Object PORTNBR browser:pxlogical...port...portnbr SERVICE * browser:pxlogical...port...service..
11 C.4 PXLOGICAL.PXPHYSICAL Characteristics
WAP Provisioning IOTA Object PXPHYSICAL-PROXY-ID browser:pxlogical...pxphysical...physical-proxy-id DOMAIN browser:pxlogical...pxphysical...domain..
65
3GPP2 C.S0040
WAP Provisioning IOTA Object TO-NAP-ID browser:pxlogical...pxphysical...to-nap-id 1 Table C.4-1 PXLOGICAL.PXPHYSICAL Characteristics
2 C.5 PXLOGICAL.PXPHYSICAL.PORT Characteristics
WAP Provisioning IOTA Object PORTNBR browser:pxlogical...pxphysical...port..
SERVICE browser:pxlogical...pxphysical...port..
4 C.6 NAPDEF Characteristics
WAP Provisioning IOTA Object NAPID phone:napdef...napid BEARER phone:napdef...bearer.. NAME phone:napdef...name INTERNET phone:napdef...internet NAP-ADDRESS phone:napdef...nap-address NAP-ADDRTYPE phone:napdef...nap-addrtype DNS-ADDR phone:napdef...dns-addr CALLTYPE phone:napdef...calltype LOCAL-ADDR phone:napdef...local-addr LOCAL-ADDRTYPE phone:napdef...local-addrtype LINKSPEED phone:napdef...linkspeed DNLINKSPEED phone:napdef...dnlinkspeed LINGER phone:napdef...linger DELIVERY-ERR-SDU phone:napdef...delivery-err-sdu DELIVERY-ORDER phone:napdef...delivery-order TRAFFIC-CLASS phone:napdef...traffic-class MAX-SDU-SIZE phone:napdef...max-sdu-size MAX-BITRATE-UPLINK phone:napdef...max-bitrate-uplink MAX-BITRATE-DNLINK phone:napdef...max-bitrate-dnlink RESIDUAL-BER phone:napdef...residual-ber SDU-ERROR-RATIO phone:napdef...sdu-error-ratio TRAFFIC-HANDL-PRIO phone:napdef...traffic-handl-prio TRANSFER-DELAY phone:napdef...transfer-delay GURANTEED-BITRATE-UPLINK phone:napdef...guranteed-bitrate-uplink GURANTEED-BITRATE-DNLINK phone:napdef...guranteed-bitrate-dnlink phone:napdef...max-num-retry
For cdma2000 NAP, this parameter is equal to MAX- NUM_RETRY parameter defined in Section 3.5.8.6 of MAX-NUM-RETRY [10]. phone:napdef...first-retry-timeout
For cdma2000 NAP, this parameter is equal to FIRST- RETRY-TIMEOUT parameter defined in Section 3.5.8.6 FIRST-RETRY-TIMEOUT of [10]. phone:napdef...rereg-threshold
REREG-THRESHOLD For cdma2000 NAP, this parameter is equal to REREG- 66
3GPP2 C.S0040
WAP Provisioning IOTA Object THRESHOLD parameter defined in Section 3.5.8.6 of [10]. phone:napdef...t-bit
For cdma2000 NAP, this parameter is equal to T-BIT T-BIT parameter defined in Section 3.5.8.6 of [10]. 1 Table C.6-1 NAPDEF Characteristics
2 C.7 NAPDEF.NAPAUTHINFO Characteristics
WAP Provisioning IOTA Object phone:napdef...napauthinfo...authtype
For cdma2000 NAP, this parameter is equivalent to AUTH_ALGORITHM, MN-AAA_AUTH_ALGORITHM and MN- HA_AUTH_ALGORITHM parameters defined in Sections AUTHTYPE 3.5.8.5 and 3.5.8.6 of [10]. phone:napdef...napauthinfo...authname
AUTHNAME For cdma2000 NAP, this parameter is equivalent to NAI parameter defined in Sections 3.5.8.5 and 3.5.8.6 of [10]. phone:napdef...napauthinfo...authsecret
For cdma2000 NAP, this parameter is equivalent to SS AUTHSECRET parameters defined in Sections 3.5.8.9 and 3.5.8.10 of [10]. phone:napdef...napauthinfo...auth-entity
For cdma2000 NAP, this parameter should be set to “AAA” or “HA” to link the authentication credentials defined in an AUTH-ENTITY instance of this characteristics to either AAA or HA. phone:napdef...napauthinfo...spi
For cdma2000 NAP, this parameter is equal to MN-AAA_SPI and MN-HA_SPI parameters defined in Section 3.5.8.6 of SPI [10]. 3 Table C.7-1 NAPDEF.NAPAUTHINFO Characteristics
4 C.8 NAPDEF.VALIDITY Characteristics
WAP Provisioning IOTA Object COUNTRY phone:napdef...validity...country NETWORK phone:napdef...validity...network SID phone:napdef...validity...sid SOC phone:napdef...validity...soc VALIDUNTIL phone:napdef...validity...validuntil 5 Table C.8-1 NAPDEF.VALIDITY Characteristics
6 C.9 BOOTSTRAP Characteristics
WAP Provisioning IOTA Object NAME phone:bootstrap...name NETWORK phone:bootstrap...network.. COUNTRY phone:bootstrap...country 67
3GPP2 C.S0040
WAP Provisioning IOTA Object PROXY-ID phone:bootstrap...proxy-id.. PROV-URL phone:bootstrap...provurl CONTEXT-ALLOW phone:bootstrap...context-allow 1 Table C.9-1 BOOTSTRAP Characteristics
2 C.10 CLIENTIDENTITY Characteristics
WAP Provisioning IOTA Object CLIENT-ID phone:clientidentity.client-id 3 Table C.10-1 CLIENTIDENTITY Characteristics
4 C.11 VENDORCONFIG Characteristics
WAP Provisioning IOTA Object NAME phone:vendorconfig.name
Where ‘NAME’ and ‘name’ represent vendor specified arbitrary string that uniquely identifies the vendor specific parameter. 5 Table C.11-1 VENDORCONFIG Characteristics
6 C.12 3GPP2 Specific Parameters
7 Following parameters are sent using VENDORCONFIG. WAP Provisioning IOTA Object CALLBACK-URL -
This parameter is transient and is never stored in the MS. Hence, equivalent IOTA object is not required.
URL to callback upon successfully processing the bootstrap document.
Client must invoke a HTTP or a WSP GET method on the specified URL – which is an implicit acknowledgement indicating successful bootstrap. CSC-PHONE-NUMBER phone:vendorconfig.3gpp2.iota.csc-ph-num
Phone number for the CSC. Mobile station may store it and may make this available from mobile station menu or address-book to enable the end-user to request customer support. 8 Table C.12-1 3GPP2 Specific Parameters
68