Network Working Group R. Gellens
Request for Comments: 2636 Qualcomm
Obsoletes: 2604 July 1999
Category: Informational
Network Working Group R. Gellens
Request for Comments: 2636 Qualcomm
Obsoletes: 2604 July 1999
Category: Informational
Wireless Device Configuration (OTASP/OTAPA) via ACAP
通过ACAP进行无线设备配置（OTASP/OTAPA）
Status of this Memo
本备忘录的状况
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (1999). All Rights Reserved.
版权所有（C）互联网协会（1999年）。版权所有。
Abstract
摘要
Wireless carriers today are faced with creating more efficient distribution channels, increasing customer satisfaction, while also improving margin and profitability. Industry trends are pushing the sale of handsets further into the retail channel. The cost and effort of provisioning handsets, activating users, and updating handset parameters can be greatly reduced by using over-the-air activation mechanisms. A comprehensive and extensible means for over-the-air provisioning and handset parameter updating is required.
如今，无线运营商面临着创建更高效的分销渠道、提高客户满意度、同时提高利润率和盈利能力的问题。行业趋势正在推动手机销售进一步进入零售渠道。通过使用空中激活机制，可以大大降低配置手机、激活用户和更新手机参数的成本和工作量。需要一种全面且可扩展的无线资源调配和手机参数更新方法。
One approach is to purchase EIA/TIA/IS-683A (Over-the-air Service Provisioning of Mobile Stations in Spread Spectrum Systems) equipment. The cost of this has led carriers to seek alternative solutions. A very viable means for providing over-the-air (OTA) provisioning is to leverage the rollout of IS-707 data services equipment, which most carriers are in the process of deploying. This paper presents an approach to OTA provisioning that utilizes the deployment of IS-707 to deliver OTA provisioning and parameter upgrading.
一种方法是购买EIA/TIA/is-683A（扩频系统中移动站的空中服务供应）设备。这一成本导致运营商寻求替代解决方案。提供空中传送（OTA）资源调配的一个非常可行的方法是利用is-707数据服务设备的推出，大多数运营商正在部署该设备。本文介绍了一种OTA配置方法，该方法利用IS-707的部署来提供OTA配置和参数升级。
IS-707 data services makes available several methods of providing over-the-air provisioning and parameter updating. A well thought-out approach utilizing Internet-based open standard mechanisms can provide an extensible platform for further carrier service offerings, enhanced interoperability among back-end services, and vendor independence.
IS-707数据服务提供了几种提供空中资源调配和参数更新的方法。利用基于互联网的开放标准机制的深思熟虑的方法可以为进一步的运营商服务提供一个可扩展的平台，增强后端服务之间的互操作性和供应商独立性。
This paper describes a viable and attractive means to provide OTASP/OTAPA via IS-707, using the ACAP [ACAP] protocol.
本文介绍了一种可行且有吸引力的方法，使用ACAP[ACAP]协议，通过IS-707提供OTASP/OTAPA。
Table of Contents
目录
1. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Feature Descriptions . . . . . . . . . . . . . . . . . . . 6
2.1. OTASP Feature Description . . . . . . . . . . . . . . . 6
2.2. OTAPA Feature Description . . . . . . . . . . . . . . . 6
3. Operation . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1. Initial Provisioning Activity . . . . . . . . . . . . . 7
3.2. OTASP for Authorized Users . . . . . . . . . . . . . . . 8
3.3. OTAPA Activity . . . . . . . . . . . . . . . . . . . . 8
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1. General Requirements . . . . . . . . . . . . . . . . . 9
4.2. OTASP Requirements . . . . . . . . . . . . . . . . . . . 9
4.3. OTAPA Requirements . . . . . . . . . . . . . . . . . . 10
4.4. Provisioning Server Requirements . . . . . . . . . . . . 10
4.5. Security Requirements . . . . . . . . . . . . . . . . . 11
5. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 11
5.1. ACAP over TCP/IP . . . . . . . . . . . . . . . . . . . 11
5.1.1. Mobile Authentication and A-Key Generation . . . . . 12
5.1.2. Mobile Identification . . . . . . . . . . . . . . . 12
5.1.3. ACAP Server . . . . . . . . . . . . . . . . . . . . 12
5.1.4. Overview of ACAP Structure . . . . . . . . . . . . 13
5.1.5. Data Organization and Capabilities . . . . . . . . . 13
5.1.5.1. Structure . . . . . . . . . . . . . . . . . . . 14
5.1.5.2. Conventions . . . . . . . . . . . . . . . . . . 15
5.1.5.3. Dataset . . . . . . . . . . . . . . . . . . . . 15
5.1.5.4. Entries and Attributes . . . . . . . . . . . . . 15
5.1.5.5. NAM Records . . . . . . . . . . . . . . . . . . 16
5.1.5.6. Server Roaming Lists . . . . . . . . . . . . . . 17
5.1.5.7. Requested-Data Record . . . . . . . . . . . . . 18
5.1.5.8. Sample Server Entry . . . . . . . . . . . . . . 18
5.1.6. Administrative Client . . . . . . . . . . . . . . . 19
5.1.7. Mobile Client . . . . . . . . . . . . . . . . . . . 20
5.2. WAP with ACAP . . . . . . . . . . . . . . . . . . . . . 22
5.3. Network-Resident vs. Configuration Data . . . . . . . . 23
5.4. Intellectual Property Issues . . . . . . . . . . . . . 23
6. Handset Protocol Suites . . . . . . . . . . . . . . . . . . 23
6.1. ACAP over TCP/IP . . . . . . . . . . . . . . . . . . . 23
7. IS-683A Compatibility . . . . . . . . . . . . . . . . . . . 24
7.1. OTASP Operations . . . . . . . . . . . . . . . . . . . 24
7.2. OTASP Call Flow . . . . . . . . . . . . . . . . . . . . 24
7.3. OTAPA Operations . . . . . . . . . . . . . . . . . . . 24
7.4. OTAPA Call Flow . . . . . . . . . . . . . . . . . . . . 25
8. Alternative Methods . . . . . . . . . . . . . . . . . . . . 25
8.1. IS-683A over TCP/IP . . . . . . . . . . . . . . . . . . 25
8.1.1. OTAF Server . . . . . . . . . . . . . . . . . . . . 25
8.1.2. Interface Application . . . . . . . . . . . . . . . 26
8.1.3. Protocol Handset Suite . . . . . . . . . . . . . . 26
1. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Feature Descriptions . . . . . . . . . . . . . . . . . . . 6
2.1. OTASP Feature Description . . . . . . . . . . . . . . . 6
2.2. OTAPA Feature Description . . . . . . . . . . . . . . . 6
3. Operation . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1. Initial Provisioning Activity . . . . . . . . . . . . . 7
3.2. OTASP for Authorized Users . . . . . . . . . . . . . . . 8
3.3. OTAPA Activity . . . . . . . . . . . . . . . . . . . . 8
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1. General Requirements . . . . . . . . . . . . . . . . . 9
4.2. OTASP Requirements . . . . . . . . . . . . . . . . . . . 9
4.3. OTAPA Requirements . . . . . . . . . . . . . . . . . . 10
4.4. Provisioning Server Requirements . . . . . . . . . . . . 10
4.5. Security Requirements . . . . . . . . . . . . . . . . . 11
5. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 11
5.1. ACAP over TCP/IP . . . . . . . . . . . . . . . . . . . 11
5.1.1. Mobile Authentication and A-Key Generation . . . . . 12
5.1.2. Mobile Identification . . . . . . . . . . . . . . . 12
5.1.3. ACAP Server . . . . . . . . . . . . . . . . . . . . 12
5.1.4. Overview of ACAP Structure . . . . . . . . . . . . 13
5.1.5. Data Organization and Capabilities . . . . . . . . . 13
5.1.5.1. Structure . . . . . . . . . . . . . . . . . . . 14
5.1.5.2. Conventions . . . . . . . . . . . . . . . . . . 15
5.1.5.3. Dataset . . . . . . . . . . . . . . . . . . . . 15
5.1.5.4. Entries and Attributes . . . . . . . . . . . . . 15
5.1.5.5. NAM Records . . . . . . . . . . . . . . . . . . 16
5.1.5.6. Server Roaming Lists . . . . . . . . . . . . . . 17
5.1.5.7. Requested-Data Record . . . . . . . . . . . . . 18
5.1.5.8. Sample Server Entry . . . . . . . . . . . . . . 18
5.1.6. Administrative Client . . . . . . . . . . . . . . . 19
5.1.7. Mobile Client . . . . . . . . . . . . . . . . . . . 20
5.2. WAP with ACAP . . . . . . . . . . . . . . . . . . . . . 22
5.3. Network-Resident vs. Configuration Data . . . . . . . . 23
5.4. Intellectual Property Issues . . . . . . . . . . . . . 23
6. Handset Protocol Suites . . . . . . . . . . . . . . . . . . 23
6.1. ACAP over TCP/IP . . . . . . . . . . . . . . . . . . . 23
7. IS-683A Compatibility . . . . . . . . . . . . . . . . . . . 24
7.1. OTASP Operations . . . . . . . . . . . . . . . . . . . 24
7.2. OTASP Call Flow . . . . . . . . . . . . . . . . . . . . 24
7.3. OTAPA Operations . . . . . . . . . . . . . . . . . . . 24
7.4. OTAPA Call Flow . . . . . . . . . . . . . . . . . . . . 25
8. Alternative Methods . . . . . . . . . . . . . . . . . . . . 25
8.1. IS-683A over TCP/IP . . . . . . . . . . . . . . . . . . 25
8.1.1. OTAF Server . . . . . . . . . . . . . . . . . . . . 25
8.1.2. Interface Application . . . . . . . . . . . . . . . 26
8.1.3. Protocol Handset Suite . . . . . . . . . . . . . . 26
8.2. Browser-Based Forms . . . . . . . . . . . . . . . . . . 26
9. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . 27
10. References . . . . . . . . . . . . . . . . . . . . . . . . 28
11. Security Considerations . . . . . . . . . . . . . . . . . 28
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 28
13. Author's Address . . . . . . . . . . . . . . . . . . . . 28
14. Full Copyright Statement . . . . . . . . . . . . . . . . . 29
8.2. Browser-Based Forms . . . . . . . . . . . . . . . . . . 26
9. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . 27
10. References . . . . . . . . . . . . . . . . . . . . . . . . 28
11. Security Considerations . . . . . . . . . . . . . . . . . 28
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 28
13. Author's Address . . . . . . . . . . . . . . . . . . . . 28
14. Full Copyright Statement . . . . . . . . . . . . . . . . . 29
Application Configuration Access Protocol (ACAP) -- An Internet protocol (RFC-2244) that provides remote storage and access of configuration and preference information.
应用程序配置访问协议（ACAP）——一种Internet协议（RFC-2244），提供配置和首选项信息的远程存储和访问。
Activation -- A process in which a mobile station and network become programmed so that a mobile station becomes operable and can be used for cellular service once authorized by the service provider.
激活——一种过程，其中移动台和网络被编程，以便移动台在服务提供商授权后可操作并可用于蜂窝服务。
Authentication -- A procedure used to validate a mobile station's identity.
身份验证——用于验证移动台身份的过程。
Authentication Center -- An entity that manages the authentication information related to the mobile station.
认证中心——管理与移动台相关的认证信息的实体。
Authentication Key (A-key) -- A secret 64-bit pattern stored in the mobile station. It is used to generate and update the mobile station's shared secret data. The A-key is used in the authentication process.
身份验证密钥（A密钥）——存储在移动台中的64位秘密模式。它用于生成和更新移动台的共享秘密数据。A密钥用于身份验证过程。
Authorization -- An action by a service provider to make cellular service available to a subscriber.
授权——服务提供商为用户提供蜂窝服务而采取的行动。
Call -- A temporary communication between telecommunications users for the purpose of exchanging information. A call includes the sequence of events that allocates and assigns resources and signaling channels required to establish a communications connection.
呼叫——电信用户之间为了交换信息而进行的临时通信。呼叫包括分配和分配建立通信连接所需的资源和信令信道的事件序列。
Cellular Service Provider -- A licensee of the responsible government agency (in the U.S. a licensee of the Federal Communications Commission) authorized to provide Cellular Radiotelephone Service.
蜂窝服务提供商——负责提供蜂窝无线电话服务的政府机构（在美国是联邦通信委员会的许可证持有人）的许可证持有人。
Challenge/Response Authentication Mechanism using Message Digest 5 (CRAM-MD5) -- An authentication mechanism which is easy to implement, and provides reasonable security against various attacks, including replay. Supported in a variety of Internet protocols. Specified as baseline mechanism in ACAP. CRAM-MD5 is published as RFC 2195.
使用消息摘要5的质询/响应身份验证机制（CRAM-MD5）——一种易于实现的身份验证机制，可针对各种攻击（包括重播）提供合理的安全性。支持多种互联网协议。在ACAP中指定为基线机制。CRAM-MD5作为RFC 2195出版。
Code Division Multiple Access -- A technique for spread-spectrum multiple-access digital communications that creates channels through the use of unique code sequences.
码分多址——一种扩频多址数字通信技术，通过使用唯一的码序列创建信道。
Customer Service Center -- An entity of a service provider that provides user support and assistance to subscribers.
客户服务中心——为订户提供用户支持和帮助的服务提供商实体。
Customer Service Representative -- A person that operates from a customer service center and provides user support and assistance to subscribers.
客户服务代表——在客户服务中心工作并向订户提供用户支持和帮助的人员。
Diffie-Hellman Algorithm -- A public-key cryptography algorithm for exchanging secret keys. Uses the equation , where k is the secret key. The equation is executed by each party of the session based on the exchange of independently generated public values.
Diffie-Hellman算法——一种用于交换密钥的公钥密码算法。使用公式，其中k是密钥。该等式由会话各方根据独立生成的公共值的交换来执行。
Digits -- Digits consist of the decimal integers 0,1,2,3,4,5,6,7,8, and 9.
数字——数字由十进制整数0、1、2、3、4、5、6、7、8和9组成。
Dual-mode Mobile Station -- A mobile station capable of both analog and digital operation.
双模移动台——一种能够进行模拟和数字操作的移动台。
Electronic Serial Number (ESN) -- A 32-bit number assigned by the mobile station manufacturer used to identify a mobile station. The ESN is unique for each legitimate mobile station.
电子序列号（ESN）——由移动台制造商分配的用于识别移动台的32位数字。ESN对于每个合法移动站都是唯一的。
Home Location Registry (HLR) -- The location register or database to which a MIN is assigned for record purposes such as subscriber information.
主位置注册表（HLR）--为记录用户信息等目的而向其分配MIN的位置寄存器或数据库。
Message Digest 5 (MD5) -- A one-way cryptographic hash function. Widely deployed in Internet protocols. Published as RFC 1321.
消息摘要5（MD5）——一个单向加密哈希函数。广泛部署在互联网协议中。作为RFC 1321出版。
Mobile Identification Number (MIN) -- The 10-digit number that represents a mobile station's directory number.
移动标识号（MIN）——表示移动台目录号的10位数字。
Mobile Station (MS) -- A station, fixed or mobile, which serves as the end user's wireless communications link with the base station. Mobile stations include portable units (e.g., hand-held personal units) and units installed in vehicles.
移动站（MS）——作为终端用户与基站的无线通信链路的固定或移动站。移动站包括便携式装置（例如，手持个人装置）和安装在车辆上的装置。
Mobile Switching Center (MSC) -- A configuration of equipment that provides cellular radiotelephone service.
移动交换中心（MSC）——提供蜂窝无线电话服务的设备配置。
Mobile Terminal Authorizing System (MTAS) -- A control system that provides the capability to load the CDMA network HLR with mobile station profile information.
移动终端授权系统（MTAS）——一种能够向CDMA网络HLR加载移动站配置文件信息的控制系统。
Number Assignment Module (NAM) -- The mobile station's electronic memory module where the MIN and other subscriber-specific parameters are stored. Mobile stations that have multi-NAM features offer users the option of using their units in several different markets by registering with a local number in each location.
号码分配模块（NAM）——移动台的电子存储模块，其中存储MIN和其他用户特定参数。具有多NAM功能的移动台为用户提供了在多个不同市场使用其设备的选项，方法是在每个位置注册本地号码。
Over-the-air Service Provisioning Function (OTAF) -- A configuration of network equipment that controls OTASP functionality and messaging protocol.
空中服务供应功能（OTAF）——控制OTASP功能和消息传递协议的网络设备配置。
Over-the-air Parameter Administration (OTAPA) -- Network initiated OTASP process of provisioning mobile station operational parameters over the air interface.
空中参数管理（OTAPA）——网络启动的OTASP通过空中接口提供移动站运行参数的过程。
Over-the-air Service Provisioning (OTASP) -- A process of provisioning mobile station operational parameters over the air interface.
空中服务供应（OTASP）——通过空中接口供应移动站运行参数的过程。
Quick-Net-Connect (QNC) -- An IS-707 data service capability that utilizes the Async Data Service Option number but bypasses the modem connection for a direct connection to an IP-based internet.
快速网络连接（QNC）——IS-707数据服务功能，利用异步数据服务选项号，但绕过调制解调器连接，直接连接到基于IP的互联网。
Roamer -- A mobile station operating in a cellular system or network other than the one from which service was subscribed.
漫游者——在蜂窝系统或网络中运行的移动台，而不是订阅服务的移动台。
Simple Authentication and Security Layer (SASL) -- An Internet protocol (RFC-2222) that provides a framework for negotiating authentication and encryption mechanisms.
简单身份验证和安全层（SASL）——一种互联网协议（RFC-2222），它提供了协商身份验证和加密机制的框架。
Service Provider -- A company, organization, business, etc. which sells, administers, maintains, and charges for the service. The service provider may or may not be the provider of the network.
服务提供者——销售、管理、维护和收取服务费用的公司、组织、企业等。服务提供商可能是也可能不是网络提供商。
Shared Secret Data (SSD) -- A 128-bit pattern stored in the mobile station (in semi-permanent memory) and known by the network. The A-key is used to generate the SSD at the network and in the mobile station for comparison.
共享秘密数据（SSD）——存储在移动台（在半永久存储器中）并被网络知晓的128位模式。A键用于在网络和移动站中生成SSD以进行比较。
Wireless Application Protocol (WAP) -- A set of network and application protocols including a datagram protocol (WDP), Transport Layer Security (WTLS), Transaction Protocol (WTP), Session Protocol (WSP), and Application Environment (WAE), which use carrier-based gateways to enable wireless devices to access Web resources. See <http://www.wapforum.org> for specifications and details.
无线应用协议（WAP）——一组网络和应用协议，包括数据报协议（WDP）、传输层安全协议（WTLS）、事务协议（WTP）、会话协议（WSP）和应用程序环境（WAE），它们使用基于载波的网关使无线设备能够访问Web资源。看<http://www.wapforum.org>关于规格和细节。
The Over the Air Service Provisioning (OTASP) feature allows a potential wireless service subscriber to activate new wireless services, and allows an existing wireless subscriber to make services changes without the intervention of a third party. OTASP includes the following:
空中服务供应（OTASP）功能允许潜在的无线服务订户激活新的无线服务，并允许现有无线订户在无需第三方干预的情况下更改服务。OTASP包括以下内容：
* A way to establish a user profile.
* 一种建立用户配置文件的方法。
* "Over-The-Air" programming of a Number Assignment Module (NAM), IMSI and Roaming Lists, including Data option parameters, and optionally, service provider or manufacturer specific parameters
* 数字分配模块（NAM）、IMSI和漫游列表的“空中”编程，包括数据选项参数，以及可选的服务提供商或制造商特定参数
(e.g., lock code, call timer).
（例如，锁定代码、呼叫计时器）。
* An Authentication Key (A-key) Generation procedure.
* 身份验证密钥（A密钥）生成过程。
* A-key storage
* A键存储器
The Over-the-Air Parameter Administration (OTAPA) feature allows wireless service providers to update a NAM, IMSI, and Roaming List information in the mobile station remotely without the intervention of a third party. This capability increases flexibility and reduces costs for carriers involved with mass changes that affect every handset, such as area-code splits.
空中参数管理（OTAPA）功能允许无线服务提供商远程更新移动台中的NAM、IMSI和漫游列表信息，而无需第三方的干预。这一功能增加了运营商的灵活性，并降低了运营商的成本，因为运营商面临着影响每部手机的大规模变化，例如区号拆分。
OTAPA includes the following:
OTAPA包括以下内容：
* Update a user's Number Assignment Module (NAM)
* 更新用户的号码分配模块（NAM）
* Update Data option parameters
* 更新数据选项参数
* Update service provider or manufacturer specific parameters (e.g., Server address(es), lock code, call timer).
* 更新服务提供商或制造商的特定参数（例如，服务器地址、锁码、呼叫计时器）。
* Update roaming lists
* 更新漫游列表
A new subscriber needs to give the intended service provider sufficient information (e.g., name, address, etc.) to prove credit-worthiness and establish a record within the service provider's billing system. In addition, the ESN of the mobile station needs to be given to the provider. This may occur in three ways:
新订户需要向预期服务提供商提供足够的信息（如姓名、地址等），以证明其信用价值，并在服务提供商的计费系统中建立记录。此外，需要将移动站的ESN提供给提供商。这可能以三种方式发生：
Voice scenario -- A customer care representative collects credit information during a voice conversation. This call is made from a different phone (e.g., wired service) or is initiated using the IS-683A OTASP dialing scheme (i.e., *228xx).
语音场景——客户服务代表在语音对话中收集信用信息。此呼叫由不同的电话（如有线服务）拨打，或使用is-683A OTASP拨号方案（即*228xx）发起。
Once the user has been authorized, the customer care representative creates a record in the CDMA network HLR, thus allowing use of the CDMA network. In addition, a limited-time N-digit password is created which is tied to the ESN. The choice of N (how many digits) is up to the carrier (as a trade-off between security and user inconvenience). All required provisioning information (including the limited-time password) is loaded into the provisioning server.
一旦用户获得授权，客户服务代表将在CDMA网络HLR中创建一个记录，从而允许使用CDMA网络。此外，将创建一个与ESN绑定的有限时间N位密码。N（多少位数）的选择取决于运营商（作为安全性和用户不便之间的权衡）。所有必需的配置信息（包括限时密码）都将加载到配置服务器中。
The user is then told to hang up and call a special number, of the form *228 XX <N-digit password> SEND (the XX code is the same as used in the initial voice call). This causes the mobile station to initiate a provisioning session.
然后，用户被告知挂断并拨打一个特殊号码，其形式为*228 XX<N位密码>发送（XX代码与初始语音通话中使用的代码相同）。这导致移动站启动供应会话。
The mobile station and the provisioning server authenticate, and all required provisioning information is downloaded into the mobile station. The user receives some form of notification once the activity is complete. This notification can be an audible tone or a text message on the mobile station display. (The form and content of this notification can be part of the provisioning data downloaded by the mobile station.) Once this initial provisioning activity is complete the user has a fully authorized mobile station ready for use.
移动站和供应服务器进行身份验证，所有需要的供应信息都下载到移动站中。一旦活动完成，用户将收到某种形式的通知。此通知可以是移动台显示屏上的音频或文本消息。（此通知的形式和内容可以是移动站下载的配置数据的一部分。）一旦此初始配置活动完成，用户就有一个完全授权的移动站可供使用。
Forms scenario -- An interactive user interface is presented via a browser on the mobile station. The subscriber fills in the requested information. (Note that entering non-numeric data presents some user interface challenges on many mobile devices.)
表单场景——通过移动台上的浏览器呈现交互式用户界面。订户填写请求的信息。（请注意，在许多移动设备上输入非数字数据会带来一些用户界面挑战。）
A back-end server validates the information, and if possible, the customer is authorized, a limited-time password is generated, HLR and provisioning server records are created and the actual OTASP operation begins. Otherwise, a voice call is made to a customer care representative.
后端服务器验证信息，如果可能，授权客户，生成限时密码，创建HLR和供应服务器记录，并开始实际的OTASP操作。否则，会向客户服务代表拨打语音电话。
Desktop scenario -- The subscriber uses a desktop (or in-store kiosk) web browser to contact the carrier, and enters the usual personal information.
桌面场景——订户使用桌面（或店内信息亭）web浏览器与运营商联系，并输入常用的个人信息。
The carrier's server validates the information, and if possible, the customer is authorized, a limited-time password is generated, HLR and provisioning server records are created, and the subscriber is told to dial a special number on the handset. Once this code is entered, the actual OTASP operation begins. Otherwise, the user is asked to make a voice call to a customer care representative.
运营商的服务器验证信息，如果可能，授权客户，生成限时密码，创建HLR和供应服务器记录，并告知订户拨打手机上的特殊号码。输入此代码后，实际的OTASP操作开始。否则，将要求用户向客户服务代表拨打语音电话。
Users already authorized for use of the CDMA network can also initiate provisioning activity. This could happen after being directed to do so by a Customer Care representative, either from a phone conversation or via mail notification. This type of OTASP activity is needed in cases where the carrier desires to upgrade CDMA parameters in the mobile stations or in cases where mobile station troubleshooting is needed.
已经授权使用CDMA网络的用户也可以启动供应活动。这可能发生在客户服务代表通过电话交谈或邮件通知发出指示后。在载波希望升级移动台中的CDMA参数或需要移动台故障排除的情况下，需要这种类型的OTASP活动。
This type of OTASP occurs in similar fashion to the initial OTASP activity. The mobile station downloads the new provisioning information in the same way.
此类OTASP的发生方式与初始OTASP活动类似。移动站以相同的方式下载新的供应信息。
Typical OTAPA capability involves upgrading a large number of mobile stations. OTAPA activity needs to be performed in a manner that does not impose on revenue bearing CDMA network activity. OTAPA operations are initiated at the customer care center. This can be accomplished by queuing a notification to the mobile station (via 1-way SMS or special caller-ID) after the provisioning server has the updated configuration data. OTAPA activity will not occur until the mobile station has acquired CDMA service on the carrier's network and the notification has reached the mobile station.
典型的OTAPA功能包括升级大量移动台。OTAPA活动的执行方式必须不影响产生收入的CDMA网络活动。OTAPA运营在客户服务中心启动。这可以通过在供应服务器具有更新的配置数据之后将通知排队到移动站（通过单向SMS或特殊呼叫者ID）来实现。在移动台在运营商网络上获得CDMA服务并且通知到达移动台之前，OTAPA活动不会发生。
Alternatively, OTAPA can be handled by including a recheck interval in the set of data used to provision the mobile station. When using a low-overhead protocol, such as ACAP [ACAP], it is reasonable to have a mobile station check in periodically to see if anything has changed. The time of day and/or day of week that such rechecks should occur could be included in the provisioning data.
或者，可以通过在用于提供移动站的数据集中包括重新检查间隔来处理OTAPA。当使用诸如ACAP[ACAP]之类的低开销协议时，有理由让移动站定期检入以查看是否有任何变化。应进行此类重新检查的时间和/或星期几可包含在供应数据中。
OTAPA activity can be terminated at any time due to user call activity.
由于用户呼叫活动，OTAPA活动可以随时终止。
IS-683A OTASP operations occur between a mobile station and an over-the-air service provisioning function (OTAF) using IS-95A traffic channel data burst messages. OTASP/OTAPA via data services require that the CDMA carrier have an IS-707 data services capable network. The IS-707 service must be either Packet Data Service (IS-707.5) or Quick-Net-Connect (QNC).
IS-683A OTASP操作使用IS-95A业务信道数据突发消息在移动站和空中服务供应功能（OTAF）之间进行。通过数据服务的OTASP/OTAPA要求CDMA运营商拥有支持IS-707数据服务的网络。IS-707服务必须是分组数据服务（IS-707.5）或快速网络连接（QNC）。
The mobile station must support:
移动站必须支持：
* IS-707 Data Service capability
* IS-707数据服务能力
* Packet/QNC RLP protocol
* 分组/QNC-RLP协议
* PPP protocol to peer to the IS-707 IWF
* 对等于IS-707 IWF的PPP协议
* IP protocol to provide the network layer for routing to the provisioning server
* IP协议提供网络层，用于路由到供应服务器
* A transport layer for end-to-end communication (such as TCP)
* 用于端到端通信（如TCP）的传输层
* Authentication and optionally encryption
* 身份验证和可选加密
* Application software to handle the provisioning protocol and memory access.
* 用于处理配置协议和内存访问的应用程序软件。
* Domain Name System (DNS) query capabilities sufficient to obtain the (IP) address of the provisioning server (or the provisioning server's address could be provided during PPP negotiation).
* 域名系统（DNS）查询功能足以获取配置服务器的（IP）地址（或者可以在PPP协商期间提供配置服务器的地址）。
Lastly, the ability must exist for the mobile to make a data call (optionally) a voice call without a MIN.
最后，移动设备必须具备在不使用MIN的情况下进行数据呼叫（可选）语音呼叫的能力。
The OTASP function requires the mobile station to originate an IS-707 data call and (optionally) a voice call using a completely unprovisioned mobile station. The CDMA network must support this capability.
OTASP功能要求移动台使用完全未配置的移动台发起IS-707数据呼叫和（可选）语音呼叫。CDMA网络必须支持这种能力。
OTASP via data services uses a provisioning server that contains the parameter information for mobile stations. The authorizing agent (or software) at the customer care center must be able to add user and mobile station information into both the CDMA network HLR and
OTASP via data services使用包含移动台参数信息的配置服务器。客户服务中心的授权代理（或软件）必须能够将用户和移动站信息添加到CDMA网络HLR和HLR中
the provisioning server during the initial authorizing process. The provisioning server must be capable of servicing a mobile as soon as its record is created.
在初始授权过程中配置服务器。设置服务器必须能够在创建移动设备记录后立即为其提供服务。
IS-683A OTAPA is performed by a mobile-terminated call that downloads parameters to the mobile station. OTAPA calls occur without user interaction.
IS-683A OTAPA由移动终端呼叫执行，该呼叫将参数下载到移动站。OTAPA调用在没有用户交互的情况下发生。
In order to perform OTAPA via data services the network needs to direct the mobile station to initiate a special-purpose data call. Several existing methods can be used to implement this capability, for example, a mobile-terminated one-way SMS message. The SMS message content can contain any information required by the mobile station. The mobile station would need a simple parser of SMS messages in order to know when to originate an OTAPA call, as opposed to normal SMS message processing. The OTAPA call would be performed in similar fashion to a registration call. More specifically, the user would not be informed of the call activity.
为了通过数据服务执行OTAPA，网络需要指示移动站发起专用数据呼叫。可以使用几种现有方法来实现此功能，例如，以移动方式终止的单向SMS消息。SMS消息内容可以包含移动站所需的任何信息。移动台需要一个简单的SMS消息解析器，以便知道何时发起OTAPA呼叫，而不是正常的SMS消息处理。OTAPA呼叫将以与注册呼叫类似的方式执行。更具体地说，用户不会被告知呼叫活动。
There are alternative means that can be employed to initiate OTAPA activity; for example, a mobile-terminated voice call with caller-ID using a specialized telephone number. Another alternative is for mobile stations to periodically check in with the provisioning server to check for updated information. ACAP, for example, is designed for such a model. The recheck interval, as well as the time of day and/or day of week that such checks should be used, can be part of the provisioning data sent to the mobile stations.
有其他方法可用于启动OTAPA活动；例如，使用专用电话号码进行来电显示的移动终端语音呼叫。另一种选择是移动站定期向供应服务器签入以检查更新的信息。例如，ACAP就是为这种模型设计的。重新检查间隔以及应使用此类检查的时间和/或星期几可以是发送到移动站的供应数据的一部分。
IS-683A utilizes an over-the-air service provisioning function (OTAF) to perform the network-side provisioning activity. OTASP/OTAPA via data services replaces the OTAF with a provisioning server. The provisioning server resides on an IP network within the controlled confines of the carrier. The provisioning server must perform all the service provisioning and parameter administration functions that the OTAF provides. The provisioning server must also have an interface to the carrier's Mobile Terminal Authorizing System (MTAS). This interface serves to synchronize the provisioning server with the information in the MTAS. The specific requirements of this interface depend on the capabilities and interfaces of the carrier's customer care center system(s). The provisioning server must be capable of receiving dynamic updates from the MTAS and have the provisioning information immediately
IS-683A利用空中服务供应功能（OTAF）执行网络端供应活动。通过数据服务的OTASP/OTAPA将OTAF替换为资源调配服务器。供应服务器位于运营商控制范围内的IP网络上。配置服务器必须执行OTAF提供的所有服务配置和参数管理功能。供应服务器还必须具有与运营商移动终端授权系统（MTAS）的接口。此接口用于将调配服务器与MTA中的信息同步。该接口的具体要求取决于运营商客户服务中心系统的功能和接口。设置服务器必须能够从MTA接收动态更新，并立即获取设置信息
available for downloading into the chosen mobile station. A standard ACAP server provides an excellent means to meet these requirements.
可下载到所选移动站。标准ACAP服务器为满足这些要求提供了极好的方法。
The provisioning server must be capable of performing an authentication procedure with the mobile station. This authentication mechanism must be capable of authenticating both the mobile station and the provisioning server.
配置服务器必须能够对移动站执行身份验证过程。此身份验证机制必须能够对移动站和供应服务器进行身份验证。
OTASP requires that an authentication procedure be performed to validate the mobile station to the provisioning server, while OTAPA requires a mechanism where the mobile validates the server.
OTASP要求执行身份验证过程，以验证移动站与供应服务器的连接，而OTAPA要求移动设备验证服务器的机制。
The provisioning server must be capable of either:
配置服务器必须能够执行以下操作之一：
* OTAF A-key generation using a Diffie-Hellman mechanism
* 使用Diffie-Hellman机制生成OTAF A密钥
Or:
或：
* Receiving A-keys from the carrier network.
* 从运营商网络接收A密钥。
Since data OTASP/OTAPA operates over IP within the carrier's network, end-to-end encryption between the mobile station and the provisioning server should be considered as a future enhancement. End-to-end encryption protects against attacks from within a carrier's network, and safeguards the provisioning data (for example, roaming lists).
由于数据OTASP/OTAPA在运营商网络内通过IP运行，因此移动站和供应服务器之间的端到端加密应被视为未来的增强。端到端加密可防止来自运营商网络内的攻击，并保护供应数据（例如，漫游列表）。
Figure 1 shows a provisioning server in the carrier's intranet which supports the Application Configuration Access Protocol (ACAP, RFC 2244). An administrative client in the customer care domain updates this server using ACAP. Handsets are provisioned and configured using a small ACAP client.
图1显示了运营商内部网中支持应用程序配置访问协议（ACAP、RFC 2244）的供应服务器。客户服务域中的管理客户端使用ACAP更新此服务器。使用小型ACAP客户端配置和配置手机。
[Figure 1 -- see PostScript version]
[图1——参见PostScript版本]
ACAP is an open Internet protocol designed to solve the problem of client access to configuration and related data. Among its primary goals are protocol simplicity, support for thin clients, and ease of operation over limited bandwidth. ACAP provides a high degree of extensibility, especially in authentication mechanisms, specialized attribute handling, and data management.
ACAP是一种开放式Internet协议，旨在解决客户端访问配置和相关数据的问题。它的主要目标包括协议简单性、对瘦客户机的支持以及在有限带宽上的易操作性。ACAP提供了高度的可扩展性，特别是在身份验证机制、专用属性处理和数据管理方面。
The mobile client authenticates with the ACAP server prior to performing any activities. Authentication uses the mobile's ESN and a shared secret. Provisioned mobiles derive the shared secret from the A-Key; unprovisioned mobiles use a limited-time password as the secret.
在执行任何活动之前，移动客户端通过ACAP服务器进行身份验证。身份验证使用移动设备的ESN和共享密钥。配置的移动设备从A密钥派生共享密钥；未设置密码的手机使用有限时间密码作为密码。
The limited-time password is provided to the user by the Customer Care representative during the initial call (as instructions to dial a specific number). This code is N digits long. The carrier selects the number of digits, as a trade-off between security and user convenience.
限时密码由客户服务代表在初次通话期间提供给用户（作为拨打特定号码的说明）。这个代码有N个数字长。运营商选择位数，作为安全性和用户便利性之间的权衡。
The baseline ACAP authentication mechanism uses the shared secret plus a random challenge from the server as input to a one-way cryptographic hash function (specifically, keyed-MD5). This is analogous to the existing IS-683A authentication mechanism which uses a random challenge and the CAVE algorithm.
基线ACAP身份验证机制使用共享密钥加上来自服务器的随机质询作为单向加密哈希函数（特别是keyed-MD5）的输入。这类似于现有is-683A认证机制，该机制使用随机质询和CAVE算法。
An A-Key is generated using a Diffie-Hellman exchange, as is done in IS-683A.
使用Diffie-Hellman交换生成A密钥，如is-683A中所述。
Provisioning records are identified using the ESN and the current NAM in use.
使用ESN和当前使用的NAM来识别供应记录。
As a standard ACAP server, the provisioning server includes configurable datasets and dataset inheritance for the management of the data stores.
作为标准的ACAP服务器，配置服务器包括用于管理数据存储的可配置数据集和数据集继承。
The administrative client can use the same simple ACAP protocol to load and modify the ACAP server as the mobile stations uses for provisioning. While any implementation-specific mechanisms available from the server vendor could instead be used for this purpose, the ability to use ACAP can greatly simplify the administrative client, as well as make it independent of the server.
管理客户端可以使用与移动台用于资源调配相同的简单ACAP协议来加载和修改ACAP服务器。虽然服务器供应商提供的任何特定于实现的机制都可以用于此目的，但使用ACAP的能力可以大大简化管理客户端，并使其独立于服务器。
ACAP includes an authentication framework (Simple Authentication and Security Layer, SASL, RFC 2222)[SASL]. SASL allows any standard or custom authentication and encryption mechanism to be used. One of the most important features of SASL is that it is designed for a world in which what is "good enough" security today isn't good enough tomorrow. As the threat model changes, SASL allows higher-strength mechanisms to be easily added while supporting already
ACAP包括一个身份验证框架（简单身份验证和安全层，SASL，RFC2222）[SASL]。SASL允许使用任何标准或自定义的身份验证和加密机制。SASL最重要的特性之一是，它是为一个当今“足够好”的安全性在未来还不够好的世界而设计的。随着威胁模型的变化，SASL允许更高强度的机制轻松添加，同时支持
deployed clients and servers. SASL is achieving widespread deployment in a number of Internet protocols.
已部署客户端和服务器。SASL正在许多互联网协议中实现广泛部署。
Strongpoints: Since the ACAP protocol was designed for precisely this type of provisioning activity, its adoption can greatly reduce the cost, time to market, and support required for the provisioning server. Additionally, the ACAP protocol provides an open standard method for mobile stations and other systems to access the provisioning server. Commercial ACAP servers are being developed by numerous companies. The ACAP client code is very small and simple, and thus can be incorporated into virtually any mobile device at minimal cost. As an open standard, the ACAP protocol has benefited from years of review and experience.
优点：由于ACAP协议正是为这种类型的资源调配活动而设计的，因此采用它可以大大减少资源调配服务器所需的成本、上市时间和支持。此外，ACAP协议为移动站和其他系统访问资源调配服务器提供了一种开放的标准方法。许多公司正在开发商用ACAP服务器。ACAP客户端代码非常小且简单，因此可以以最低的成本整合到几乎任何移动设备中。作为一项开放标准，ACAP协议得益于多年的审查和经验。
ACAP organizes data by datasets. The structure of a dataset is defined by the dataset class. Generally, ACAP servers do not have knowledge of dataset classes. This allows the dataset to be expanded without modifying the server in any way. A dataset is an instantiation of the dataset class, which is a logical definition of what is in a dataset, and how it is used.
ACAP按数据集组织数据。数据集的结构由dataset类定义。通常，ACAP服务器不了解数据集类。这允许在不以任何方式修改服务器的情况下扩展数据集。dataset是dataset类的实例化，dataset类是dataset中的内容及其使用方式的逻辑定义。
Datasets contain entries. Entries contain attributes and values. Attributes and values are actually metadata, such as name, length, and value. Any entry can also be a dataset (datasets are hierarchical).
数据集包含条目。条目包含属性和值。属性和值实际上是元数据，例如名称、长度和值。任何条目也可以是数据集（数据集是分层的）。
For example, consider the ACAP addressbook dataset class, designed to hold names, email addresses, phone numbers, and related information for a person's contacts. A given user may have one or more addressbook datasets. Each entry holds information about one person or entity. Attributes in the entry hold specific items of information, such as the given name, surname, various email addresses, phone numbers, and so forth. If an entry is a list of people (such as a mailing list or specific group of people), it is a subdataset, containing its own entries. Some clients may look at only a subset of the attributes. For example, a mobile handset ACAP client may download only the alias (nickname), name, primary phone number and email address of each entry, while a desktop client may access all attributes.
例如，考虑ACAP AddisSooDataSet类，设计用于保存姓名、电子邮件地址、电话号码以及有关个人联系人的相关信息。给定用户可能有一个或多个地址簿数据集。每个条目保存关于一个人或实体的信息。条目中的属性包含特定的信息项，例如给定的姓名、姓氏、各种电子邮件地址、电话号码等。如果条目是人员列表（例如邮件列表或特定人员组），则它是一个子数据集，包含自己的条目。有些客户端可能只查看属性的一个子集。例如，手机ACAP客户端可能只下载每个条目的别名（昵称）、姓名、主要电话号码和电子邮件地址，而桌面客户端可能访问所有属性。
ACAP provides custom hierarchical datasets. Server data can be organized to fit the needs of the applications using the dataset.
ACAP提供定制的分层数据集。可以使用数据集组织服务器数据以满足应用程序的需要。
In OTASP/OTAPA over ACAP, data on the server is organized to both take advantage of ACAP capabilities and to use items that are identical to IS-683A, allowing for reuse of IS-683A handset engines.
在OTASP/OTAPA over ACAP中，服务器上的数据被组织为既利用ACAP功能，又使用与is-683A相同的项目，从而允许重用is-683A手机引擎。
ACAP servers also support data inheritance. All data items which are physically in the inherited dataset and not in the inheriting dataset logically also exist in the inheriting dataset. This is recursive, as the inherited dataset can itself inherit from another dataset. This powerful concept allows potentially large groups of mobile stations to inherit items from a single common entity. For example, preferred roaming lists can be stored in datasets based on geographic areas, and automatically inherited by an individual mobile station in that area. The roaming lists could be further subdivided, for example based on tiers of free NVRAM in the mobile. The mobile client need not be aware of this; it happens entirely on the server.
ACAP服务器还支持数据继承。所有物理上在继承数据集中而逻辑上不在继承数据集中的数据项也存在于继承数据集中。这是递归的，因为继承的数据集本身可以从另一个数据集继承。这个强大的概念允许潜在的大型移动站组从单个公共实体继承项目。例如，首选漫游列表可以存储在基于地理区域的数据集中，并由该区域的单个移动站自动继承。漫游列表可以进一步细分，例如基于移动设备中的免费NVRAM层。移动客户端不需要知道这一点；它完全发生在服务器上。
ACAP uses trees to provide the data hierarchy. These data trees can be viewed as similar to the directory/file structure used with all common operating systems. The built-in inheritance mechanism, together with the hierarchical structure, makes it extremely easy to update general data without disturbing specific data.
ACAP使用树来提供数据层次结构。可以将这些数据树视为与所有通用操作系统使用的目录/文件结构相似。内置的继承机制，加上层次结构，使得在不干扰特定数据的情况下非常容易地更新常规数据。
Datasets exist within the user, group, and host hierarchies. The user hierarchy holds datasets which belong to individual users. The group hierarchy holds datasets which belong to groups (for example, the "Region." groups in section 5.1.6.3 Server Roaming Lists). The host hierarchy holds datasets which are for specific machines or systems.
数据集存在于用户、组和主机层次结构中。用户层次结构保存属于单个用户的数据集。组层次结构保存属于组的数据集（例如，第5.1.6.3节“服务器漫游列表”中的“区域”组）。主机层次结构包含用于特定机器或系统的数据集。
In addition to providing customizable data trees, ACAP also provides several standard datasets for all clients. There is a capabilities dataset that contains information on custom functionality and enhanced features available to a specific client or at the site generally. This allows a server to advertise any protocol extensions, specialized attribute handling, or other enhanced functionality it supports. A client that needs to use these features can thus easily determine what is available before trying to use them.
除了提供可定制的数据树之外，ACAP还为所有客户端提供了多个标准数据集。有一个功能数据集，其中包含特定客户端或站点上可用的自定义功能和增强功能的信息。这允许服务器公布任何协议扩展、专用属性处理或其支持的其他增强功能。因此，需要使用这些功能的客户端可以在尝试使用它们之前轻松确定可用的功能。
We divide the data accessed by the client into provisioning items, group items, and client state items. Provisioning data contains NAM items and requested-data items. Group items (such as preferred roaming lists), are not specific to any mobile device. Group items physically exist in their own datasets, but through inheritance logically appear in client datasets.
我们将客户机访问的数据划分为配置项、组项和客户机状态项。设置数据包含NAM项和请求的数据项。组项目（如首选漫游列表）并非特定于任何移动设备。组项物理上存在于它们自己的数据集中，但通过继承逻辑上出现在客户机数据集中。
The mobile stations always read data from provisioning entries and write data to client state entries. This structure makes both mobile clients and server configuration easy and simple, while allowing for extensive custom and diagnostic capabilities.
移动站总是从供应条目读取数据，并将数据写入客户端状态条目。这种结构使移动客户端和服务器配置变得简单方便，同时允许广泛的自定义和诊断功能。
"" This signifies the empty string (used here for ACAP entries).
“”这表示空字符串（此处用于ACAP条目）。
~ This is shorthand for "user/<userid>". It is part of the ACAP protocol.
~这是“user/<userid>”的缩写。它是ACAP协议的一部分。
Provisioning information is located in the "OTAP" dataset class. (The full specification of this dataset will be published in a subsequent document.) The prefix "Provision." is used for items that are to be downloaded to the mobile, and the prefix "Client." is used for items which the client stores on the server.
配置信息位于“OTAP”数据集中类中。（此数据集的完整规范将在后续文档中发布。）前缀“Provision.”用于下载到手机上的项目，前缀“Client.”用于客户端存储在服务器上的项目。
Provisioning data within the OTAP dataset is organized as a series of items, each of which is stored in its own entry. The entry name is the item name, and the "OTAP.VALUE" attribute contains the item value. This structure permits change notification on a per-item basis.
OTAP数据集中的供应数据被组织为一系列项，每个项都存储在自己的条目中。条目名称是项目名称，“OTAP.VALUE”属性包含项目值。该结构允许按项目发出变更通知。
We chose the "Provision" and "Client" names to simplify various operations. For example, the mobile client can easily download all changed provisioning items by performing a search which returns the "OTAP.VALUE" attribute of all entries whose name begins with "Provision" and whose modtime is greater than the last time the client retrieved data. An administrative client can easily generate a report of all clients which have not received the most recent update by searching for all entries named "Client" whose "OTAP.modtime" attribute is less than the desired value.
我们选择了“供应”和“客户”名称以简化各种操作。例如，移动客户端可以通过执行搜索轻松下载所有更改的配置项，该搜索返回名称以“Provision”开头且modtime大于客户端上次检索数据的所有条目的“OTAP.VALUE”属性。通过搜索名为“client”且其“OTAP.modtime”属性小于所需值的所有条目，管理客户端可以轻松生成所有未收到最新更新的客户端的报告。
A partial list of items follows.
下面是部分项目列表。
dataset.inherit
dataset.inherit
This is a standard ACAP attribute that identifies the location of inherited data. It exists in the "" entry (the entry with the empty name) within each dataset.
这是一个标准ACAP属性，用于标识继承数据的位置。它存在于每个数据集中的“”条目（名称为空的条目）中。
The OTAP dataset class contains an entry for each provisioned mobile. The standard location for provisioning records is:
OTAP数据集类包含每个已配置移动设备的条目。设置记录的标准位置是：
/OTAP/USER/<esn>/<nam>/
/OTAP/USER/<esn>/<nam>/
This tree format allows multiple NAMs per ESN. The specific entries contain data in IS-683A parameter block types.
此树格式允许每个ESN有多个NAM。特定条目包含IS-683A参数块类型中的数据。
For example, the CDMA NAM would be stored in an entry called:
例如，CDMA NAM将存储在名为：
/OTAP/USER/<esn>/<nam>/Provision.CDMA-NAM/
/OTAP/USER/<esn>/<nam>/Provision.CDMA-NAM/
The entries below show how NAM records would be organized on the ACAP server:
以下条目显示了NAM记录在ACAP服务器上的组织方式：
CDMA/Analog NAM
CDMA/模拟NAM
Entry-Path: /OTAP/USER/<esn>/<nam>/Provision.CDMA-AMPS-NAM/
Entry-Path: /OTAP/USER/<esn>/<nam>/Provision.CDMA-AMPS-NAM/
OTAP.Value: {17} xx xx xx ... xx
OTAP.Value: {17} xx xx xx ... xx
The CDMA/Analog NAM entry from IS-683A (section 4.5.2.1) consists of at least 129 information bits, depending on the number of SID NID list entries. This is stored as 17 (or more) octets of binary data (padding is used to ensure an integral number of octets).
IS-683A（第4.5.2.1节）中的CDMA/模拟NAM条目由至少129个信息位组成，具体取决于SID NID列表条目的数量。这存储为17（或更多）个八位字节的二进制数据（填充用于确保八位字节的整数）。
Mobile Directory Number
移动电话号码
Entry-Path: /OTAP/USER/<esn>/<nam>/Provision.MOBILE-DN/
Entry-Path: /OTAP/USER/<esn>/<nam>/Provision.MOBILE-DN/
OTAP.Value: {10} nnnnnnnnnn
OTAP.Value: {10} nnnnnnnnnn
The Mobile Directory Number from IS-683A contains BCD-encoded digits representing the phone number. This is stored as a string of 10 or more ASCII digits, e.g., "6195551212".
IS-683A中的移动电话号码包含代表电话号码的BCD编码数字。它存储为10个或更多ASCII数字的字符串，例如“6195551212”。
CDMA NAM
CDMA NAM
Entry-Path: /OTAP/USER/<esn>/<nam>/ Provision.CDMA-NAM/
Entry-Path: /OTAP/USER/<esn>/<nam>/ Provision.CDMA-NAM/
OTAP.Value: {13} xx xx xx ... xx
OTAP.Value: {13} xx xx xx ... xx
The CDMA-NAM entry from IS-683A (section 4.5.2.3) consists of at least 100 information bits, depending on the number of SID-NID list entries. This is stored as 13 (or more) octets of binary data (padding is used to ensure an integral number of octets).
IS-683A（第4.5.2.3节）中的CDMA-NAM条目由至少100个信息位组成，具体取决于SID-NID列表条目的数量。这存储为13（或更多）个八位字节的二进制数据（填充用于确保八位字节的整数）。
IMSI_T
IMSI_T
Entry-Path: /OTAP/USER/<esn>/<nam>/ Provision.IMSI_T/
Entry-Path: /OTAP/USER/<esn>/<nam>/ Provision.IMSI_T/
OTAP.Value: {7} xx xx xx xx xx xx xx
OTAP.Value: {7} xx xx xx xx xx xx xx
The IMSI_T entry from IS-683A (section 4.5.2.4) consists of 55 bits of information in five fields. This is stored left-justified in 7 octets of binary data.
IS-683A（第4.5.2.4节）的IMSI_T条目由五个字段中的55位信息组成。它存储在7个八位字节的二进制数据中，左对齐。
The ACAP Server will have an entry for each different roaming list configuration for a carrier. The example below assumes that the desired differentiation for the roaming list is geographic, with subdivisions for tiers of mobile free NVRAM It shows that for each region there exists a set of roaming lists per free NVRAM range. Note that a carrier can easily implement different or further differentiation (e.g., by phone vendor or product type) by simply changing the dataset tree and assigned the appropriate value to the "dataset.inherit" attribute in the provisioning records.
ACAP服务器将为运营商的每个不同漫游列表配置提供一个条目。下面的示例假设漫游列表所需的区分是地理上的，并对移动免费NVRAM层进行了细分。它表明，对于每个区域，每个免费NVRAM范围都存在一组漫游列表。请注意，运营商只需更改数据集树并将适当的值分配给供应记录中的“dataset.inherit”属性，即可轻松实现不同或进一步的差异化（例如，按电话供应商或产品类型）。
/OTAP/GROUP/region.NorthEast/free-nv.128-512/
preferred.roaming.list/OTAP.Value
/OTAP/GROUP/region.NorthEast/free-nv.512-1024/
preferred.roaming.list/OTAP.Value
/OTAP/GROUP/region.SouthEast/free-nv.128-512/
preferred.roaming.list/OTAP.Value
/OTAP/GROUP/region.SouthEast/free-nv.512-1024/
preferred.roaming.list/OTAP.Value
/OTAP/GROUP/region.NorthWest/free-nv.128-512/
preferred.roaming.list/OTAP.Value
/OTAP/GROUP/region.NorthWest/free-nv.512-1024/
preferred.roaming.list/OTAP.Value
/OTAP/GROUP/region.SouthWest/free-nv.128-512/
preferred.roaming.list/OTAP.Value
/OTAP/GROUP/region.SouthWest/free-nv.512-1024/
preferred.roaming.list/OTAP.Value
/OTAP/GROUP/region.NorthEast/free-nv.128-512/
preferred.roaming.list/OTAP.Value
/OTAP/GROUP/region.NorthEast/free-nv.512-1024/
preferred.roaming.list/OTAP.Value
/OTAP/GROUP/region.SouthEast/free-nv.128-512/
preferred.roaming.list/OTAP.Value
/OTAP/GROUP/region.SouthEast/free-nv.512-1024/
preferred.roaming.list/OTAP.Value
/OTAP/GROUP/region.NorthWest/free-nv.128-512/
preferred.roaming.list/OTAP.Value
/OTAP/GROUP/region.NorthWest/free-nv.512-1024/
preferred.roaming.list/OTAP.Value
/OTAP/GROUP/region.SouthWest/free-nv.128-512/
preferred.roaming.list/OTAP.Value
/OTAP/GROUP/region.SouthWest/free-nv.512-1024/
preferred.roaming.list/OTAP.Value
Inside the OTAP dataset is an entry with the name "Provision.Requested-Data", which contains one attribute called "OTAP.Requested-Data". This attribute is multi-valued. It is either NIL or contains a list of strings. Each string is the name of one element of data that the server requests the client to supply.
在OTAP数据集中有一个名为“Provision.Requested Data”的条目，其中包含一个名为“OTAP.Requested Data”的属性。此属性是多值的。它要么为NIL，要么包含字符串列表。每个字符串是服务器请求客户端提供的一个数据元素的名称。
After authenticating, the ACAP client issues a SEARCH command to retrieve the values of the "OTAP.Requested-Data" attribute of the "Provision.Requested-Data" entry. The client processes the returned values (if any) by issuing a STORE command to set one or more attributes in the "Client" entry. The value of each attribute is either the corresponding mobile value (which may be an empty string if the item has no value), or the special value "[N/A]" if the item does not exist or is unknown on the mobile.
验证后，ACAP客户端发出搜索命令，以检索“Provision.Requested Data”条目的“OTAP.Requested Data”属性的值。客户机通过发出STORE命令来处理返回的值（如果有），以在“客户机”条目中设置一个或多个属性。每个属性的值要么是相应的移动值（如果项目没有值，则可能是空字符串），要么是特殊值“[N/A]”（如果项目在移动设备上不存在或未知）。
This mechanism is quite general, and can be used in the normal OTASP case to modify the mobile's dataset as appropriate for the condition of the mobile. For example, the inheritance could be set based on the amount of NVRAM available, to cause one set of preferred roaming list data or another to be used. This mechanism can also be used in other situations, such as to retrieve a complete set of mobile configuration parameters for diagnostic reasons.
此机制非常通用，可在正常OTASP情况下使用，以根据移动设备的状况修改移动设备的数据集。例如，可以根据可用NVRAM的数量设置继承，以使用一组首选漫游列表数据或另一组。此机制也可用于其他情况，例如出于诊断原因检索一整套移动配置参数。
The entry below is an excerpt of a sample ACAP server dataset entry for a single mobile station, with an ESN of FB9876E and using NAM 1:
以下条目摘录了单个移动站的ACAP服务器数据集条目示例，ESN为FB9876E，使用NAM 1：
/OTAP/USER/FB9876E/1/
/OTAP/USER/FB9876E/1/
entry = ""
dataset.inherit = "/OTAP/GROUP/region.NorthEast/
free-nv.128-512/preferred.roaming.list/
OTAP.Value/"
entry = ""
dataset.inherit = "/OTAP/GROUP/region.NorthEast/
free-nv.128-512/preferred.roaming.list/
OTAP.Value/"
entry = "Provision.Requested-Data"
OTAP.Requested-Data = ("Phone-Make" "Phone-Model" "SW-Rev"
"Free-NVRAM")
entry = "Provision.Requested-Data"
OTAP.Requested-Data = ("Phone-Make" "Phone-Model" "SW-Rev"
"Free-NVRAM")
entry = "Client" OTAP.Phone-Make = "Qualcomm" OTAP.Phone-Model = "pdQ1900" OTAP.SW-Rev = "001.030.0908" OTAP.Free-NVRAM = "65536" OTAP.Last-Modtime = "199812181703"
entry=“Client”OTAP.Phone-Make=“Qualcomm”OTAP.Phone-Model=“pdQ1900”OTAP.SW-Rev=“001.030.0908”OTAP.Free-NVRAM=“65536”OTAP.Last-Modtime=“199812181703”
entry = "Provision.Mobile-DN"
OTAP.Value = {10} 619 555 1234
entry = "Provision.Mobile-DN"
OTAP.Value = {10} 619 555 1234
entry = "Provision.CDMA-NAM"
OTAP.Value = {13} xx xx xx xx xx xx xx xx xx xx xx
xx xx
entry = "Provision.CDMA-NAM"
OTAP.Value = {13} xx xx xx xx xx xx xx xx xx xx xx
xx xx
This dataset shows not only provisioning data which was downloaded into the mobile station, but also the items of client data requested by the server (the Requested-Data attribute) and the values of those items (the "Client" entry). It also indicates that the mobile client successfully stored the values associated with the modtime "199812181703". In addition, it shows that this client inherits data (i.e., roaming lists) from the "NorthEast" region.
该数据集不仅显示下载到移动站的供应数据，还显示服务器请求的客户端数据项（请求的数据属性）和这些项的值（“客户端”条目）。它还表示移动客户端成功存储了与modtime“199812181703”相关联的值。此外，它还显示该客户端从“东北”地区继承数据（即漫游列表）。
The administrative client loads initial provisioning information into the server, including specifying the roaming list to inherit. The administrative client also updates provisioning server records as needed, and retrieves data for reports (such as a list of clients which have not yet been updated).
管理客户端将初始设置信息加载到服务器中，包括指定要继承的漫游列表。管理客户端还根据需要更新配置服务器记录，并检索报告的数据（例如尚未更新的客户端列表）。
Data is loaded into provisioning records by using the ACAP STORE command. The administrative client authenticates to the ACAP server using credentials that permit access to datasets for mobiles.
使用ACAP STORE命令将数据加载到配置记录中。管理客户端使用允许访问移动设备数据集的凭据向ACAP服务器进行身份验证。
When a new mobile is authorized for service, the administrative client creates the dataset by storing into it values that are specific for the device. It also sets the "dataset.inherit" attribute so that values which are not tied to the specific mobile are inherited as appropriate.
当新移动设备被授权提供服务时，管理客户端通过将特定于该设备的值存储到数据集中来创建数据集。它还设置“dataset.inherit”属性，以便根据需要继承未绑定到特定移动设备的值。
* Updates to user records
* 更新用户记录
Existing user records may need updating from time to time. For example, a user may change service plans or purchase an additional or replacement mobile device, or the carrier may need to modify some aspect of provisioned data.
现有用户记录可能需要不时更新。例如，用户可以更改服务计划或购买附加的或替换的移动设备，或者运营商可能需要修改所提供数据的某些方面。
* Perusal and editing of provisioning records
* 查阅和编辑供应记录
The administrative client can provide general browse and edit capability for user records.
管理客户端可以提供用户记录的一般浏览和编辑功能。
* Report generation
* 报告生成
The administrative client can extract data from the ACAP server in order to generate reports. For example, after OTAPA activity, a carrier may wish to identify those mobiles which have not yet been updated.
管理客户端可以从ACAP服务器提取数据以生成报告。例如，在OTAPA活动之后，运营商可能希望识别那些尚未更新的手机。
* Queuing of OTAPA sessions
* OTAPA会话的排队
Depending on the OTAPA update procedures chosen (e.g., SMS, CLID, periodic recheck), the administrative client may be involved in initiating the activity. This may or may not use an interface to the provisioning server.
根据所选择的OTAPA更新程序（例如SMS、CLID、定期复查），管理客户端可能参与启动活动。这可能会也可能不会使用到配置服务器的接口。
The ACAP mobile client is implemented as a state machine that performs the equivalent of IS-683A provisioning parameter information exchange and non-volatile memory storage. The ACAP Client state machine diagram (Figure 2) and descriptions are below.
ACAP移动客户端实现为一个状态机，执行is-683A配置参数信息交换和非易失性内存存储的等效功能。ACAP客户端状态机图（图2）和说明如下。
[Figure 2 -- see PostScript version]
[图2——参见PostScript版本]
* Establish Transport Layer/Authenticate
* 建立传输层/身份验证
Authentication and/or encryption can occur at the application layer and/or at the network/transport layer.
身份验证和/或加密可以发生在应用层和/或网络/传输层。
Basic ACAP authentication occurs in the application layer (i.e., within the ACAP session), and in its baseline form uses the CRAM-MD5[CRAM-MD5] mechanism. If desired, other mechanisms can be used which provide more protection and encryption. This occurs after the transport layer is established, as shown in the client state machine diagram above
基本ACAP身份验证发生在应用层（即，在ACAP会话中），其基线形式使用CRAM-MD5[CRAM-MD5]机制。如果需要，可以使用提供更多保护和加密的其他机制。这发生在传输层建立之后，如上面的客户机状态机图所示
Figure 3 shows the CRAM-MD5 authentication mechanism for an unprovisioned mobile. In the case of provisioned mobiles, the shared secret is derived from the A-Key, instead of the limited-time N-digit code used for unprovisioned devices.
图3显示了未配置移动设备的CRAM-MD5身份验证机制。对于已配置的移动设备，共享密钥来自A密钥，而不是用于未配置设备的有限时间N位代码。
Use of basic ACAP authentication is preferred for initial implementations of data-OTASP because it is simple, easy to implement, and all procedures and methods are in place. Stronger SASL mechanisms and/or IPSec can be rolled out in the future without disrupting the deployed base.
对于数据OTASP的初始实现，首选使用基本ACAP身份验证，因为它简单、易于实现，并且所有过程和方法都已准备就绪。将来可以推出更强大的SASL机制和/或IPSec，而不会中断已部署的基础。
[Figure 3 -- see PostScript version]
[图3——参见PostScript版本]
* Requested-data SEARCH
* 请求的数据搜索
The mobile ACAP client issues a search command asking the server to return the attribute "OTAP.Requested-Data" in the entry "Requested-Data".
移动ACAP客户端发出搜索命令，要求服务器返回条目“Requested Data”中的属性“OTAP.Requested Data”。
* Receive requested-data values
* 接收请求的数据值
The server instructs the client to store attributes by returning one or more values of requested-data in response to the Requested-Data SEARCH.
服务器通过返回请求数据的一个或多个值来指示客户端存储属性，以响应请求的数据搜索。
For example, the attribute "OTAP.Requested-Data" in the entry "Requested-Data" might contain four values: "phone-make", "phone-model", "SW-Rev", and "Free-NVRAM".
例如，“请求的数据”条目中的属性“OTAP.Requested Data”可能包含四个值：“手机品牌”、“手机型号”、“软件版本”和“免费NVRAM”。
* STORE attribute list
* 存储属性列表
If the response to the requested-data SEARCH returns any values, the client issues a STORE command. Each attribute in the STORE command corresponds to one item of requested-data. If the client does not recognize an item, it stores the string "[n/a]".
如果对请求的数据搜索的响应返回任何值，客户机将发出STORE命令。STORE命令中的每个属性对应于一项请求的数据。如果客户端无法识别某个项目，则会存储字符串“[n/a]”。
Continuing with our example, the client uses this STORE command to write four attributes into the "Client" entry. Each attribute name is identical to one value of the OTAP.Requested-Data" attribute (with the prefix "OTAP." added). Each attribute value is determined by the respective mobile value.
继续我们的示例，客户机使用这个STORE命令将四个属性写入“客户机”条目。每个属性名称与“OTAP.Requested Data”属性的一个值相同（添加前缀“OTAP.”）。每个属性值由相应的移动值确定。
In our example, this STORE command sets the following attributes and values:
在我们的示例中，此STORE命令设置以下属性和值：
- "OTAP.Phone-Make" = "Qualcomm - "OTAP.Phone-Model" = "pdQ1900 - "OTAP.SW-Rev" = "001.030.0908" - "OTAP.Free-NVRAM" = "65536"
- “OTAP.Phone Make”=“高通公司-”OTAP.Phone型号”=“pdQ1900-”OTAP.SW版本”=“001.030.0908”-“OTAP.Free NVRAM”=“65536”
* Provisioning data SEARCH
* 资源调配数据搜索
The mobile ACAP client issues a search command to retrieve any items of provisioning data that have changed since it last checked in (which in the initial session retrieves all provisioning data).
移动ACAP客户端发出搜索命令，以检索自上次签入以来已更改的任何配置数据项（在初始会话中检索所有配置数据）。
This SEARCH command asks the server to return the "OTAP.Value" attribute of any entries whose name starts with "provision." (case-insensitive) and whose modtime is greater than the supplied value (which is zero for an unprovisioned mobile).
此搜索命令要求服务器返回名称以“provision.”（不区分大小写）开头且modtime大于提供值（对于未设置移动设备为零）的任何条目的“OTAP.Value”属性。
* Receive provisioning data and modtime
* 接收资源调配数据和时间
The server returns the provisioning items, each as one entry name and one attribute value. The server response to the SEARCH command includes the modtime of the latest entry returned.
服务器返回设置项，每个项作为一个条目名和一个属性值。服务器对SEARCH命令的响应包括返回的最新条目的modtime。
* Save values
* 保存值
The mobile writes the returned values into NVRAM.
手机将返回的值写入NVRAM。
* STORE modtime
* 存储时间
The ACAP client stores the returned modtime on the server as an acknowledgement that the data was received and NVRAM updated.
ACAP客户端将返回的modtime存储在服务器上，作为接收到数据并更新NVRAM的确认。
* LOGOUT
* 注销
The client issues the LOGOUT command.
客户端发出注销命令。
* Close transport layer
* 封闭传输层
The client closes the TCP connection.
客户端关闭TCP连接。
* End call
* 结束通话
The data call is terminated.
数据调用被终止。
An advantage of the ACAP solution is that is can easily coexist with a WAP-based mechanism, giving carriers more options.
ACAP解决方案的一个优点是，它可以轻松地与基于WAP的机制共存，为运营商提供更多选择。
A carrier can deploy handsets into its service area which use WAP-based provisioning, if desired, alongside those which use ACAP provisioning. All that is required is that the WAP server contain a small ACAP client (or an interface to an ACAP server).
如果需要，运营商可以将使用基于WAP的资源调配的手机与使用ACAP资源调配的手机一起部署到其服务区域。所需的只是WAP服务器包含一个小型ACAP客户端（或到ACAP服务器的接口）。
Figure 4 shows how mobile stations can be configured using a WAP browser. By using an ACAP server for provisioning, carriers are free to simultaneously deploy mobile stations that use either WAP or ACAP, as desired. In either case, the ACAP server is the source for provisioning data.
图4显示了如何使用WAP浏览器配置移动台。通过使用ACAP服务器进行资源调配，运营商可以根据需要免费同时部署使用WAP或ACAP的移动台。无论哪种情况，ACAP服务器都是提供数据的源。
[Figure 4 -- see PostScript version]
[图4——参见PostScript版本]
It is useful to recognize that wireless devices access two different types of carrier-provided data: network-resident and configuration. Network-resident data exists primarily within the carrier's network. Examples include account status, billing detail, service plan options, etc. While mobiles may access this information for user display, it resides in the network. Configuration data, in contrast, affects the operation of the handset, is usually not shown to the user, and must persist in the device.
认识到无线设备访问两种不同类型的运营商提供的数据很有用：网络驻留数据和配置数据。网络驻留数据主要存在于运营商的网络中。示例包括帐户状态、账单详细信息、服务计划选项等。虽然手机可以访问此信息以供用户显示，但它驻留在网络中。相反，配置数据会影响手机的操作，通常不会显示给用户，并且必须保存在设备中。
For network-resident data access, the obvious choice is the web. The data is highly interactive and time-variant, making web browsers a reasonable solution. Any appropriate web browser can be used. There are many good reasons for having a web browser in a wireless device which contains a display and is capable of user interaction.
对于网络常驻数据访问，显而易见的选择是web。这些数据具有高度的交互性和时变性，使得web浏览器成为一个合理的解决方案。可以使用任何适当的web浏览器。在包含显示器且能够进行用户交互的无线设备中使用web浏览器有很多很好的理由。
For configuration data, the best solution is to use ACAP. ACAP is optimized for the job, can be implemented quickly, requires a very small amount of memory, and does not depend on a display or any user interaction capability.
对于配置数据，最好的解决方案是使用ACAP。ACAP针对作业进行了优化，可以快速实现，需要非常少的内存，并且不依赖于显示器或任何用户交互功能。
Trying to use the same access method for both types of data unnecessarily complicates the solution, leading to increased design, development, and debug time and expense. It makes it more difficult to offer low-cost devices. Since the two types of data fundamentally differ, it is good engineering practice to select optimal code and protocols for each.
尝试对这两种类型的数据使用相同的访问方法会使解决方案不必要地复杂化，从而增加设计、开发和调试的时间和费用。这使得提供低成本设备变得更加困难。由于这两种类型的数据从根本上是不同的，因此为每种数据选择最佳的代码和协议是一种良好的工程实践。
There are no known intellectual property issues with the ACAP solution. The ACAP specification was developed within the IETF, and no ownership, patent, or other IP claims have been asserted. Multiple independent vendors are developing ACAP clients and servers, in addition to the existing usage in deployed products.
ACAP解决方案不存在已知的知识产权问题。ACAP规范是在IETF中开发的，没有任何所有权、专利或其他IP权利要求。除了已部署产品中的现有用途外，多家独立供应商正在开发ACAP客户端和服务器。
Figure 5 depicts the mobile station protocol suite for the ACAP over TCP/IP solution. The mobile station is capable of supporting both IS-683A OTASP and OTASP over ACAP.
图5描述了ACAP over TCP/IP解决方案的移动站协议套件。移动站能够通过ACAP支持is-683A OTASP和OTASP。
[Figure 5 -- see PostScript version]
[图5——参见PostScript版本]
To maximize compatibility and allow for reuse of IS-683A handset code, the data formats used in OTASP over ACAP are identical to those used in IS-683A. Section 5.1.5 Data Organization and Capabilities discusses this in more detail.
为了最大限度地提高兼容性并允许重用IS-683A手机代码，OTASP over ACAP中使用的数据格式与IS-683A中使用的数据格式相同。第5.1.5节“数据组织和能力”对此进行了更详细的讨论。
OTASP via IS-683A requires custom design and development for the specific CDMA infrastructure used by a carrier. This can greatly limit the data management capabilities and significantly reduces the extensibility of the solution. Conversely, OTASP over data can be implemented on a generic IP network using an Internet standards-based capability that provides extensible provisioning activities for carriers.
OTASP via IS-683A需要针对运营商使用的特定CDMA基础设施进行定制设计和开发。这会极大地限制数据管理功能，并显著降低解决方案的可扩展性。相反，OTASP over data可以使用基于Internet标准的功能在通用IP网络上实现，该功能为运营商提供可扩展的资源调配活动。
OTASP over data uses a traffic channel whereas IS-683A OTASP runs over the limited-bandwidth signaling channel.
数据上的OTASP使用流量信道，而IS-683A OTASP通过有限带宽的信令信道运行。
IS-683A OTASP operations are inherently simultaneous voice and data. This allows the customer care representative to extract information from the mobile station while conversing with the user. OTASP over data services is a data-only solution (at least for now). This makes OTASP operations slightly more sequential and potentially problematic. Simultaneous voice and data will alleviate this issue.
IS-683A OTASP操作本质上是同时进行语音和数据。这允许客户服务代表在与用户交谈时从移动台提取信息。OTASP over data services是一个仅数据的解决方案（至少目前是这样）。这使得OTASP操作的顺序稍有增加，并可能出现问题。同时使用语音和数据将缓解这一问题。
The call flow diagram (Figure 6) depicts the message sequence and operations for a typical IS-683A OTASP (provisioning) call. Any data-OTASP solution must perform all the functions of the IS-683A OTASP call. The proposed solution meets these requirements.
调用流程图（图6）描述了典型IS-683A OTASP（配置）调用的消息序列和操作。任何数据OTASP解决方案都必须执行IS-683A OTASP调用的所有功能。建议的解决方案满足这些要求。
[Figure 6 -- see PostScript version]
[图6——参见PostScript版本]
Data-OTAPA requires the ability to instruct mobiles to originate a data call to the provisioning server. Several viable approaches are discussed in sections 3.3 OTAPA Activity and 4.3 OTAPA Requirements.
数据OTAPA需要能够指示移动设备发起对资源调配服务器的数据调用。第3.3节OTAPA活动和第4.3节OTAPA要求中讨论了几种可行的方法。
OTAPA over data has the potential to require far less channel resources to download new information to mobile stations. The ACAP server inherently only communicates changes to the clients, thus only changed information needs to be downloaded to the mobile stations using OTAPA over data via ACAP.
OTAPA over data有可能需要更少的频道资源将新信息下载到移动台。ACAP服务器本质上只向客户端传送更改，因此仅需要使用OTAPA通过ACAP通过数据将更改的信息下载到移动站。
The call flow diagram (Figure 7) depicts the message sequence for a typical IS-683A OTAPA operation. Any data-OTAPA solution must perform all the functions of the IS-683A OTAPA call. The proposed solution meets these requirements.
调用流程图（图7）描述了典型IS-683A OTAPA操作的消息序列。任何数据OTAPA解决方案都必须执行IS-683A OTAPA调用的所有功能。建议的解决方案满足这些要求。
[Figure 7 -- see PostScript version]
[图7——参见PostScript版本]
One alternative is to port IS-683A to TCP, remaining as close as possible to the IS-683A protocol exchange.
一种选择是将is-683A端口连接到TCP，尽可能靠近is-683A协议交换。
Figure 8 depicts the architecture and communications backbone to support OTASP/OTAPA via IS-707 data services with a provisioning server based on the IS-683A OTAF function.
图8描述了通过IS-707数据服务和基于IS-683A OTAF功能的供应服务器支持OTASP/OTAPA的体系结构和通信主干。
[Figure 8 -- see PostScript version]
[图8——参见PostScript版本]
This provisioning server is modeled after the IS-683A OTAF. The OTAF server performs the specific operations and messaging of IS-683A OTAF. This includes A-key reauthentication procedures.
此资源调配服务器以is-683A OTAF为模型。OTAF服务器执行IS-683A OTAF的特定操作和消息传递。这包括密钥重新验证过程。
Strongpoints:
优点：
(1) OTAF and mobile station behavior mirrors IS-683A (reduced duplicate software in mobile station). Nearly all procedures fully defined.
(1) OTAF和移动台行为镜像IS-683A（减少移动台中的重复软件）。几乎所有程序都已完全定义。
Drawbacks:
缺点：
(1) The OTAF server would need to be custom-designed and built.
(1) OTAF服务器需要定制设计和构建。
(2) No inherent data manipulation capabilities in the OTAF server. All required or desired data management activities would have to be built from scratch.
(2) OTAF服务器中没有固有的数据操作功能。所有必需或期望的数据管理活动都必须从头开始构建。
(3) Interface application would require a non-standard interface (and therefore proprietary) to OTAF server.
(3) 接口应用程序需要OTAF服务器的非标准接口（因此是专有的）。
(4) End-to-end encryption scheme still needed for full security.
(4) 仍然需要端到端加密方案以实现完全安全性。
This function loads all required provisioning-related information from the CDMA network information system to the OTAF server. This includes the queuing of provisioning transactions and data.
此功能将所有必需的供应相关信息从CDMA网络信息系统加载到OTAF服务器。这包括供应事务和数据的排队。
Figure 9 depicts the mobile station protocol suite for the IS-683A over TCP/IP solution. The OTASP client is capable of supporting both IS-683A OTASP activities or OTASP activities over the data transport.
图9描述了IS-683A over TCP/IP解决方案的移动站协议套件。OTASP客户端能够通过数据传输支持is-683A OTASP活动或OTASP活动。
[Figure 9 -- see PostScript version]
[图9——参见PostScript版本]
Another alternative is to use forms embedded in web pages.
另一种选择是使用嵌入网页中的表单。
Encapsulating the provisioning data into custom tags embedded in a web form is an idea that at first seems attractive. There are a lot of advantages in having a browser in the handset, web servers are very widely deployed, and everyone is familiar on some level with the web.
将供应数据封装到web表单中嵌入的自定义标记中，这一想法起初似乎很有吸引力。在手机中安装浏览器有很多优点，web服务器的部署非常广泛，每个人都在一定程度上熟悉web。
However, a meta-protocol for this would need to be designed, and a fully detailed specification produced. This solution requires custom software on the provider side to handle the meta-protocol. It additionally requires handset vendors to add custom software in the handset browser to handle this protocol.
然而，需要为此设计一个元协议，并生成一个完全详细的规范。此解决方案需要提供者端的自定义软件来处理元协议。它还要求手机供应商在手机浏览器中添加自定义软件来处理此协议。
This solution would require a provisioning-capable browser in every phone. While it may be desirable to have a browser, the decision to require it needs to be considered carefully, especially in light of the memory requirements it would impose on all devices.
此解决方案需要在每部手机中都安装支持资源调配的浏览器。虽然可能希望有一个浏览器，但需要它的决定需要仔细考虑，特别是考虑到它对所有设备的内存要求。
This solution would complicate the handset browser, by requiring it to handle provisioning as well as browsing. As provisioning and browsing are functionally dissimilar, this code is not a natural fit within the browser. Implementing this solution would require a significant increase in development and debug resources, and thus negatively impact time-to-market and cost.
此解决方案将使手机浏览器复杂化，因为它需要处理资源调配和浏览。由于资源调配和浏览在功能上不同，因此此代码在浏览器中并不适合。实现此解决方案将需要显著增加开发和调试资源，从而对上市时间和成本产生负面影响。
Also because the web is functionally dissimilar, a high level of carrier-side customization would be needed, leading to reduced vendor choice and increased deployment costs.
此外，由于网络功能不同，因此需要高水平的运营商端定制，从而减少供应商选择，增加部署成本。
This approach would layer custom data on top of a standard protocol. This would require design work, and would not have much time for open review before deployment, greatly increasing the risk. By contrast, ACAP has had years of open review and refinement.
这种方法将自定义数据分层到标准协议之上。这将需要设计工作，并且在部署之前没有太多时间进行公开审查，从而大大增加了风险。相比之下，ACAP经过多年的公开审查和完善。
This approach also limits the extensibility of the solution. ACAP, conversely, is very extensible. Because ACAP is such a simple protocol, it can be added to a wide variety of applications at low cost. This allows increasing numbers of applications on the mobile device to share information with servers as well as desktop applications.
这种方法还限制了解决方案的可扩展性。相反，ACAP是非常可扩展的。因为ACAP是这样一个简单的协议，它可以以低成本添加到各种各样的应用程序中。这使得移动设备上越来越多的应用程序能够与服务器以及桌面应用程序共享信息。
ACAP provides a high degree of extensibility, especially in authentication mechanisms, custom attribute handling, and data management. By using an Internet standard protocol, interoperability and integration with a variety of equipment is possible, and carriers are not locked into any vendor. It is also easier to add new levels of service and capabilities, especially integration with future subscriber devices and applications (e.g., email).
ACAP提供了高度的可扩展性，特别是在身份验证机制、自定义属性处理和数据管理方面。通过使用互联网标准协议，可以实现与各种设备的互操作性和集成，并且运营商不受任何供应商的限制。添加新级别的服务和功能也更容易，特别是与未来的订户设备和应用程序（如电子邮件）的集成。
Since an ACAP client is so small, it can be incorporated into virtually any device, even low-end ones without displays, and can be added without sacrificing other features. The simplicity of the client and protocol directly translate to shorter development cycles and faster time-to-market.
由于ACAP客户端非常小，它几乎可以集成到任何设备中，即使是没有显示器的低端设备，也可以在不牺牲其他功能的情况下添加。客户端和协议的简单性直接转化为更短的开发周期和更快的上市时间。
Because the ACAP protocol was designed for precisely this type of provisioning activity, its adoption can greatly reduce the cost, time to market, and support required for the provisioning server as well as the handsets. As an open standard, the ACAP protocol has benefited from years of review and experience.
由于ACAP协议正是为这类资源调配活动而设计的，因此采用它可以大大降低资源调配服务器和手机所需的成本、上市时间和支持。作为一项开放标准，ACAP协议得益于多年的审查和经验。
Another advantage of the ACAP solution is that is can easily coexist with a WAP-based mechanism, giving carriers more options and reducing the minimal requirement burden on mobile devices.
ACAP解决方案的另一个优点是，它可以轻松地与基于WAP的机制共存，为运营商提供更多选择，并减少移动设备的最低需求负担。
A carrier can deploy handsets into its service area which use WAP-based provisioning, if desired, alongside those which use ACAP provisioning. By using an ACAP server for provisioning, carriers are free to simultaneously deploy mobile stations that use either WAP or ACAP, as desired.
如果需要，运营商可以将使用基于WAP的资源调配的手机与使用ACAP资源调配的手机一起部署到其服务区域。通过使用ACAP服务器进行资源调配，运营商可以根据需要免费同时部署使用WAP或ACAP的移动台。
The lack of intellectual-property issues further adds to ACAP's appeal.
缺乏知识产权问题进一步增加了ACAP的吸引力。
[ACAP] Newman, C. and J. Myers, "ACAP -- Application Configuration Access Protocol", RFC 2244, November 1997.
[ACAP]Newman，C.和J.Myers，“ACAP——应用程序配置访问协议”，RFC22441997年11月。
[CRAM-MD5] Klensin, J., Catoe, R. and P. Krumviede, "IMAP/POP AUTHorize Extension for Simple Challenge/Response", RFC 2195, September 1997.
[CRAM-MD5]Klensin，J.，Catoe，R.和P.Krumviede，“简单质询/响应的IMAP/POP授权扩展”，RFC 21951997年9月。
[SASL] Myers, J., "Simple Authentication and Security Layer (SASL)", RFC 2222, October 1997.
[SASL]迈尔斯，J.，“简单认证和安全层（SASL）”，RFC22221997年10月。
Security is discussed in many sections of this document. In particular, the need and methods to guard against unauthorized updating of handsets, usurpation of newly-created accounts, compromise of handset security values, and disclosure of carrier proprietary data and handset parameters is covered.
本文档的许多部分都讨论了安全性。特别是，涵盖了防止未经授权更新手机、盗用新创建的帐户、危害手机安全值以及披露运营商专有数据和手机参数的需要和方法。
Jim Willkie and Marc Phillips contributed greatly to this document. Their help is very much appreciated.
吉姆·威尔基（Jim Willkie）和马克·菲利普斯（Marc Phillips）对这份文件做出了巨大贡献。非常感谢他们的帮助。
Randall Gellens QUALCOMM Incorporated 6455 Lusk Boulevard San Diego, CA 92121-2779
Randall Gellens高通公司，加利福尼亚州圣地亚哥路6455号，邮编92121-2779
Phone: +1 619 651 5115
EMail: randy@qualcomm.com
Phone: +1 619 651 5115
EMail: randy@qualcomm.com
Copyright (C) The Internet Society (1999). All Rights Reserved.
版权所有（C）互联网协会（1999年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。