Network Working Group R. Gellens
Request for Comments: 2604 Qualcomm
Category: Informational June 1999
Wireless Device Configuration (OTASP/OTAPA) via ACAP
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.6. Dataset . . . . . . . . . . . . . . . . . . . . . . 15
5.1.6.1. Entries and Attributes . . . . . . . . . . . . . 15
5.1.6.2. NAM Records . . . . . . . . . . . . . . . . . . 16
5.1.6.3. Server Roaming Lists . . . . . . . . . . . . . . 17
5.1.6.4. Requested-Data Record . . . . . . . . . . . . . 18
5.1.6.5. Sample Server Entry . . . . . . . . . . . . . . 18
5.1.7. Administrative Client . . . . . . . . . . . . . . . 19
5.1.8. 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
Application Configuration Access Protocol (ACAP) -- An Internet
protocol (RFC-2244) that provides remote storage and access of
configuration and preference information.
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
実装が容易であり、かつ再生を含む種々の攻撃に対する合理的なセキュリティを提供する認証メカニズム - メッセージダイジェスト5（CRAM-MD5）を使用して、チャレンジ/レスポンス認証メカニズム。インターネットプロトコルの様々なサポートされています。 ACAPのベースラインメカニズムとして指定されました。 CRAM-MD5は、以下のように公開されています
RFC 2195.
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） - 非同期データサービスオプション番号を利用しますが、IPベースのインターネットに直接接続するためのモデム接続をバイパスIS-707データサービス機能。
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:
* 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-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 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:
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ネットワークの使用を可能にする、CDMAネットワークHLRにレコードを作成します。また、期間限定のN桁のパスワードは、ESNに結ばれた作成されます。 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.
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.
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).
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).
*プロビジョニングサーバーの（IP）アドレス取得するのに十分なドメインネームシステム（DNS）クエリ機能（またはプロビジョニングサーバーのアドレスは、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 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 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.
データサービスを介したOTASPは、移動局のためのパラメータ情報が含まれているプロビジョニングサーバーを使用しています。カスタマーケアセンターの許可を与えるエージェント（またはソフトウェア）は、最初の認可プロセス中にCDMAネットワークのHLRとプロビジョニング・サーバーの両方にユーザーと移動局の情報を追加することができなければなりません。プロビジョニングサーバはすぐにそのレコードが作成されると、モバイルにサービスを提供することが可能でなければなりません。
IS-683A OTAPA is performed by a mobile-terminated call that
downloads parameters to the mobile station. OTAPA calls occur
without user interaction.
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メッセージの内容は、移動局が必要とする情報を含むことができます。 OTAPAコールを発信する際に、通常のSMSメッセージ処理とは対照的に、移動局は、知るために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活動を開始するために使用することができる代替手段があります。例えば、発信者IDを持つモバイルで終了する音声通話は、専門の電話番号を使用して。移動局は定期的に更新情報をチェックするプロビジョニング・サーバーにチェックインするために別の選択肢です。 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 available for downloading into the chosen mobile station. A
standard ACAP server provides an excellent means to meet these
requirements.
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.
The provisioning server must be capable of either:
プロビジョニング・サーバーは、いずれかのことが可能でなければなりません。
* OTAF A-key generation using a Diffie-Hellman mechanism
* OTAFのDiffie-Hellmanメカニズムを使用してA-鍵生成
Or:
または：
* Receiving A-keys from the carrier network.
*キャリアネットワークから、鍵を受け取ります。
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.
[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は、コンフィギュレーションおよび関連データへのクライアントアクセスの問題を解決するために設計されたオープンなインターネットプロトコルです。その主な目標の中で、プロトコルシンプルさ、シンクライアントのサポート、および限られた帯域幅での操作のしやすさです。 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.
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認証メカニズムは、共有秘密プラス一方向暗号ハッシュ関数（具体的には、キー入力-MD5）への入力としてサーバからランダムチャレンジを使用します。これは、ランダムチャレンジとCAVEアルゴリズムを使用して、既存のIS-683Aの認証機構に類似しています。
An A-Key is generated using a Diffie-Hellman exchange, as is done in IS-683A.
IS-683Aで行われるようにA-Keyが、Diffie-Hellman交換を使用して生成されます。
Provisioning records are identified using the ESN and the current
NAM in use.
As a standard ACAP server, the provisioning server includes
configurable datasets and dataset inheritance for the management of
the data stores.
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 deployed clients and servers. SASL is achieving widespread deployment in a number of Internet protocols.
ACAPは、認証フレームワーク（簡易認証とセキュリティレイヤ、SASL、RFC 2222）[SASL]を含みます。 SASLは、任意の標準またはカスタム認証と暗号化メカニズムを使用することができます。 SASLの最も重要な特徴の1つは、それが「十分に良い」セキュリティ今日は何である世界のために設計されていることであることは明日十分ではありません。脅威モデルが変化すると、SASLは、すでに展開され、クライアントとサーバーをサポートしながら、より高強度の仕組みを簡単に追加することができます。 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.
Strongpoints：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.
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のアドレス帳データセットクラスを、検討してください。与えられたユーザは、1つのまたは複数のアドレス帳のデータセットを有することができます。各エントリには、1人またはエンティティに関する情報を保持しています。エントリ内の属性は、このような等々、指定された名前、姓、さまざまな電子メールアドレス、電話番号などの情報の特定の項目を、保持します。エントリが（例えばメーリングリストや人々の特定のグループのような）人のリストである場合、それは自身のエントリを含む、サブデータセットです。一部のクライアントは、属性のサブセットのみを見てもよいです。デスクトップクライアントは、すべての属性にアクセスすることができる。一方、例えば、携帯電話のACAPクライアントは、唯一の別名（ニックネーム）、名、プライマリ電話番号と、各エントリの電子メールアドレスをダウンロードすることができます。
ACAP provides custom hierarchical datasets. Server data can be
organized to fit the needs of the applications using the dataset.
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.
ACAPオーバーOTASP / OTAPAでは、サーバー上のデータは、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.
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.
〜これは、「ユーザー/ <ユーザーID>」の省略形です。それは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.
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.
私たちは、さまざまな操作を簡素化する「引当金」と「クライアント」の名前を選びました。例えば、モバイルクライアントは、簡単に名前「引当金」で始まり、そのMODTIMEクライアントがデータを取得した最後の時間よりも大きいすべてのエントリの「OTAP.VALUE」属性を返す検索を実行することにより、変更されたすべてのプロビジョニングアイテムをダウンロードすることができます。管理クライアントは、簡単にその「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/USER/<esn>/<nam>/
/ OTAP / USER / <ESN> / <ナム> /
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/
／おたＰ／うせＲ／＜えｓん＞／＜なｍ＞／Ｐろゔぃしおん。ＣＤまーなＭ／
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/
入場パス：/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エントリがSID NIDリストエントリの数に応じて、少なくとも129個の情報ビットから成ります。これは、（パディングオクテットの整数を確実にするために使用される）は、バイナリデータの17（またはそれ以上）のオクテットとして記憶されます。
Mobile Directory Number
モバイルディレクトリ番号
Entry-Path: /OTAP/USER/<esn>/<nam>/Provision.MOBILE-DN/
入場パス：/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/
入場パス：/ OTAP / USER / <ESN> / <南> / 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エントリは、SID、NIDリストのエントリの数に応じて、少なくとも100個の情報ビットから成ります。これは、（パディングオクテットの整数を確実にするために使用される）は、バイナリデータの13（またはそれ以上）のオクテットとして記憶されます。
IMSI_T
IMSI_T
Entry-Path: /OTAP/USER/<esn>/<nam>/ Provision.IMSI_T/
入場パス：/ OTAP / USER / <ESN> / <南> / 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エントリは5つのフィールド内の情報の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.
/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.
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・データ」のエントリの「OTAP.Requested-data」属性の値を取得するために、SEARCHコマンドを発行します。クライアントは、「クライアント」エントリに1つ以上の属性を設定するには、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:
/OTAP/USER/FB9876E/1/
/ OTAP / USER / FB9876E / 1 /
entry = "" dataset.inherit = "/OTAP/GROUP/region.NorthEast/ free-nv.128-512/preferred.roaming.list/ OTAP.Value/"
エントリ= "" dataset.inherit = "/OTAP/GROUP/region.NorthEast/自由nv.128-512 / preferred.roaming.list / OTAP.Value /"
entry = "Provision.Requested-Data" OTAP.Requested-Data = ("Phone-Make" "Phone-Model" "SW-Rev" "Free-NVRAM")
エントリ= "Provision.Requested-データ" OTAP.Requested-データ=（ "電話メイク" "電話・モデル"、 "SW-REV" "フリー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 = "Provision.Mobile-DN" OTAP.Value = {10} 619 555 1234
エントリ= "クライアント" OTAP.Phone-メイク= "クアルコム" OTAP.Phone-モデル= "pdQ1900" OTAP.SW-REV = "001.030.0908" OTAP.Free-NVRAM = "65536" OTAP.Last-MODTIME = " 199812181703" エントリ= "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
エントリ= "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.
* 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.
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.
[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認証機構を示しています。プロビジョニングされた携帯電話の場合、共有秘密は、代わりにプロビジョニングされていないデバイスのために使用される限られた時間N桁のコードで、A-鍵から導出されます。
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.
それは、シンプルな実装が容易であるため、基本的なACAP認証の使用は、データOTASPの初期の実装のために好ましい、そしてすべての手順および方法は、所定の位置にあります。強い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".
* 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".
「電話メイク」、「携帯電話・モデル」、「SW-REV」、および「フリーNVRAM」：例えば、「要求 - データを」エントリに「 - データOTAP.Requested」属性には4つの値が含まれる可能性があります。
* STORE attribute list
* STORE属性リスト
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]".
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.
私たちの例を続けると、クライアントは、「クライアント」エントリに4つの属性を記述するために、この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メイク" = "クアルコム - "OTAP.Phone-モデル"=" pdQ1900 - "OTAP.SW-REV" = "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).
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).
この検索コマンドは名前で始まるすべてのエントリの「OTAP.Value」属性を返すようにサーバに要求する「規定を。」 （大文字と小文字を区別しない）、そのMODTIME（プロビジョニングされていないモバイルゼロ）された値よりも大きいです。
* Receive provisioning data and modtime
*レシーブプロビジョニングデータと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.
* Save values
*保存値
The mobile writes the returned values into NVRAM.
モバイルはNVRAMに返された値を書き込みます。
* STORE modtime
* BIG MODTIME
The ACAP client stores the returned modtime on the server as an
acknowledgement that the data was received and NVRAM updated.
* LOGOUT
* ログアウト
The client issues the LOGOUT command.
クライアントはLOGOUTコマンドを発行します。
* 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.
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).
所望であれば、キャリアは、ACAPプロビジョニングを使用したものと一緒に、WAPベースのプロビジョニングを使用してそのサービスエリア内に携帯電話を展開することができます。必要とされるすべては、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ブラウザを有するために多くの良い理由があります。
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.
両方のタイプのデータに対して同じアクセス方式を使用しようとすると、必要以上に増加し、設計、開発、およびデバッグ時間と費用につながるソリューションを複雑にします。それはより困難な低コストのデバイスを提供することができます。データの2種類が根本的に異なりますので、それぞれに最適なコードとプロトコルを選択するために、優れた技術的手法です。
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.
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.
[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.
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.
IS-683Aを介したOTASPは、キャリアによって使用される特定のCDMAインフラのためのカスタム設計と開発を必要とします。これは、大幅にデータ管理機能を制限し、大幅ソリューションの拡張性を減らすことができます。逆に、データ上OTASPは、キャリアのための拡張可能なプロビジョニング活動を提供するインターネット標準ベースの機能を使用して、一般的なIPネットワーク上で実現することができます。
OTASP over data uses a traffic channel whereas IS-683A OTASP runs over the limited-bandwidth signaling channel.
IS-683A OTASPは、限られた帯域幅のシグナリングチャネルを介して実行されます一方、データオーバー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は（少なくとも今のところ）のデータのみのソリューションです。これは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.
[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 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は、移動局に新しい情報をダウンロードするためにはるかに少ないチャネルのリソースを必要とする可能性を秘めています。 ACAPサーバは、本質的にのみこれだけ変更された情報は、ACAPを介してデータ上でOTAPAを使用して移動局にダウンロードする必要があり、クライアントへの変更を伝達します。
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.
[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.
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-683A OTAF関数に基づいてプロビジョニング・サーバーとIS-707データ・サービスを介して、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.
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.
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.
[Figure 9 -- see PostScript version]
[図9 - PostScript版を参照]
Another alternative is to use forms embedded in web pages.
別の方法としては、Webページに埋め込まれたフォームを使用することです。
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サーバーが非常に広く展開している、と誰もがウェブと、いくつかのレベルでよく知られています。
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).
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.
所望であれば、キャリアは、ACAPプロビジョニングを使用したものと一緒に、WAPベースのプロビジョニングを使用してそのサービスエリア内に携帯電話を展開することができます。プロビジョニング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.
[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 2195、1997年9月。
[SASL] Myers, J., "Simple Authentication and Security Layer (SASL)", RFC 2222, October 1997.
[SASL]マイヤーズ、J.、 "簡易認証セキュリティー層（SASL）"、RFC 2222、1997年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.
Randall Gellens QUALCOMM Incorporated 6455 Lusk Boulevard San Diego, CA 92121-2779
ランドールGellens QUALCOMM Incorporatedの6455ラスク大通りサンディエゴ、CA 92121から2779
Phone: +1 619 651 5115 EMail: randy@qualcomm.com
電話：+1 619 651 5115 Eメール：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 Editor機能のための基金は現在、インターネット協会によって提供されます。