[要約] RFC 2636は、ACAPを介してワイヤレスデバイスの設定（OTASP/OTAPA）を行うためのプロトコルを定義しています。このRFCの目的は、ワイヤレスデバイスの設定を効率的かつ安全に行うための標準化を提供することです。
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.
Copyright（c）The Internet Society（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.
1つのアプローチは、EIA/TIA/IS-683A（Spread Spectrum Systemsのモバイルステーションの航空サービスプロビジョニング）機器を購入することです。このコストにより、キャリアは代替ソリューションを求めました。オーバーザエア（OTA）プロビジョニングを提供するための非常に実行可能な手段は、IS-707データサービス機器のロールアウトを活用することです。これは、ほとんどのキャリアが展開中です。このペーパーでは、IS-707の展開を利用してOTAプロビジョニングとパラメーターアップグレードを提供する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 Data Servicesは、オーバーザエアプロビジョニングとパラメーターの更新を提供するいくつかの方法を利用可能にします。インターネットベースのオープン標準メカニズムを利用するよく考え抜かれたアプローチは、より多くのキャリアサービスの提供、バックエンドサービス間の相互運用性の向上、およびベンダーの独立性のための拡張可能なプラットフォームを提供できます。
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
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） - 構成情報と優先情報のリモートストレージとアクセスを提供するインターネットプロトコル（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-Key） - モバイルステーションに保存されている秘密の64ビットパターン。これは、モバイルステーションの共有秘密データを生成および更新するために使用されます。A-Keyは認証プロセスで使用されます。
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.
Cellular Service Provider - 携帯電話ラジオテレフォンサービスを提供することを許可された責任ある政府機関（米国では、連邦通信委員会のライセンシー）のライセンシー。
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.
数字 - 数字は、10桁の整数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.
Home Location Registry（HLR） - サブスクライバー情報などの記録的な目的で最小を割り当てる場所レジスタまたはデータベース。
Message Digest 5 (MD5) -- A one-way cryptographic hash function. Widely deployed in Internet protocols. Published as RFC 1321.
Message Digest 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およびその他のサブスクライバー固有のパラメーターが保存されているモバイルステーションの電子メモリモジュール。マルチナム機能を備えたモバイルステーションは、各場所のローカル番号に登録することにより、いくつかの異なる市場でユニットを使用するオプションをユーザーに提供します。
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.
Quick-Net-Connect（QNC） - 非同期データサービスオプション番号を使用しますが、IPベースのインターネットへの直接接続のモデム接続をバイパスするIS-707データサービス機能。
Roamer -- A mobile station operating in a cellular system or network other than the one from which service was subscribed.
Roamer-サービスがサブスクライブされたもの以外の携帯電話システムまたはネットワークで動作するモバイルステーション。
Simple Authentication and Security Layer (SASL) -- An Internet protocol (RFC-2222) that provides a framework for negotiating authentication and encryption mechanisms.
Simple Authentication and Security Layer（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.
Shared Secret Data（SSD） - モバイルステーション（半多数メモリ）に保存され、ネットワークで知られている128ビットパターン。A-Keyは、比較のためにネットワークとモバイルステーションで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:
Over the Air Service Provisioning（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-Key）生成手順。
* A-key storage
* A-Keyストレージ
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).
* サービスプロバイダーまたはメーカー固有のパラメーター（例：サーバーアドレス（ES）、ロックコード、コールタイマー）を更新します。
* 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をプロバイダーに指定する必要があります。これは3つの方法で発生する場合があります。
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-digitパスワードが作成されます。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-digitパスワード>送信（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ネットワークの使用が許可されているユーザーは、プロビジョニングアクティビティを開始することもできます。これは、電話での会話やメール通知によるカスタマーケア担当者によってそうするように指示された後に発生する可能性があります。このタイプのOTASPアクティビティは、キャリアがモバイルステーションのCDMAパラメーターをアップグレードしたい場合、またはモバイルステーションのトラブルシューティングが必要な場合に必要です。
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運用は、カスタマーケアセンターで開始されます。これは、プロビジョニングサーバーに更新された構成データがある後に（1ウェイ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.
または、オタパは、モバイルステーションのプロビジョニングに使用されるデータのセットに、再確認間隔を含めることで処理できます。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）または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).
* ドメイン名システム（DNS）プロビジョニングサーバーの（IP）アドレスを取得するのに十分なクエリ機能（または、PPPの交渉中にプロビジョニングサーバーのアドレスが提供される可能性があります）。
Lastly, the ability must exist for the mobile to make a data call (optionally) a voice call without a 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 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.
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活動を開始するために使用できる代替手段があります。たとえば、専門の電話番号を使用したCaller-IDを使用したモバイル終了音声コール。もう1つの選択肢は、モバイルステーションがプロビジョニングサーバーに定期的にチェックインして、更新された情報を確認することです。たとえば、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.
IS-683Aは、オーバーザエアサービスプロビジョニング機能（OTAF）を利用して、ネットワーク側のプロビジョニングアクティビティを実行します。データサービスを介してOTASP/OTAPAは、OTAFをプロビジョニングサーバーに置き換えます。プロビジョニングサーバーは、キャリアの制御された範囲内のIPネットワークに住んでいます。プロビジョニングサーバーは、OTAFが提供するすべてのサービスプロビジョニングおよびパラメーター管理機能を実行する必要があります。プロビジョニングサーバーには、キャリアのモバイルターミナル承認システム（MTA）へのインターフェイスも必要です。このインターフェイスは、MTAの情報とプロビジョニングサーバーを同期するのに役立ちます。このインターフェイスの特定の要件は、キャリアのカスタマーケアセンターシステムの機能とインターフェイスに依存します。プロビジョニングサーバーは、MTAから動的な更新を受信し、選択したモバイルステーションにダウンロードするためにプロビジョニング情報をすぐに利用できるようにする必要があります。標準の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-Key Generation
Or:
または：
* Receiving A-keys from the carrier network.
* キャリアネットワークからA-KEYを受信します。
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は、構成および関連データへのクライアントアクセスの問題を解決するために設計されたオープンなインターネットプロトコルです。その主な目標の中には、プロトコルのシンプルさ、薄いクライアントのサポート、限られた帯域幅に対する運用の容易さがあります。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-Keyから共有秘密を導き出します。未確認の携帯電話は、限られた時間のパスワードを秘密として使用します。
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）への入力としてサーバーからのランダムな課題を使用します。これは、ランダムチャレンジと洞窟アルゴリズムを使用する既存のIS-683A認証メカニズムに類似しています。
An A-Key is generated using a Diffie-Hellman exchange, as is done in IS-683A.
IS-683Aで行われるように、A-KeyはDiffie-Hellman Exchangeを使用して生成されます。
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 deployed clients and servers. SASL is achieving widespread deployment in a number of Internet protocols.
ACAPには、認証フレームワーク（Simple認証およびセキュリティレイヤー、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.
ストロングポイント：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はデータセットでデータを整理します。データセットの構造は、データセットクラスによって定義されます。一般に、ACAPサーバーにはデータセットクラスの知識がありません。これにより、サーバーを何らかの形で変更せずにデータセットを拡張できます。データセットは、データセットクラスのインスタンス化であり、データセットにあるものと使用方法の論理的な定義です。
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人またはエンティティに関する情報が保持されます。エントリの属性には、指定された名前、姓、さまざまな電子メールアドレス、電話番号など、特定の情報項目が保持されます。エントリが人々のリスト（メーリングリストや特定の人々のグループなど）である場合、それは独自のエントリを含むsubdatasetです。一部のクライアントは、属性のサブセットのみを見ることができます。たとえば、モバイルハンドセット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.
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.
クライアントがアクセスしたデータをプロビジョニングアイテム、グループアイテム、およびクライアント状態アイテムに分割します。プロビジョニングデータには、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」データセットクラスにあります。（このデータセットの完全な仕様は、後続のドキュメントに公開されます。）プレフィックス「プロビジョニング」。モバイルにダウンロードされるアイテムとプレフィックス「クライアント」に使用されます。クライアントがサーバーに保存するアイテムに使用されます。
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データセットクラスには、プロビジョニングされたモバイルごとのエントリが含まれています。プロビジョニングレコードの標準的な場所は次のとおりです。
/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/
The entries below show how NAM records would be organized on the ACAP server:
以下のエントリは、ACAPサーバーでNAMレコードがどのように整理されるかを示しています。
CDMA/Analog NAM
CDMA/アナログNAM
Entry-Path: /OTAP/USER/<esn>/<nam>/Provision.CDMA-AMPS-NAM/
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.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エンコードの数字が含まれています。これは、「6195551212」などの10以上のASCII桁の文字列として保存されます。
CDMA NAM
CDMAナム
Entry-Path: /OTAP/USER/<esn>/<nam>/ Provision.CDMA-NAM/
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).
OTAP.VALUE：{13} XX XX XX ... XX 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.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.
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
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データセットの内部には、「depribe.requested-data」という名前のエントリがあり、「otap.requested-data」と呼ばれる1つの属性が含まれています。この属性は多値です。NILまたは文字列のリストが含まれています。各文字列は、サーバーがクライアントに供給を要求するデータの1つの要素の名前です。
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クライアントは検索コマンドを発行して、「OTAP.Requested-Data」属性の値を「Provision.Requested-Data」エントリを取得します。クライアントは、「クライアント」エントリに1つ以上の属性を設定するためにストアコマンドを発行することにより、返された値（もしあれば）を処理します。各属性の値は、対応するモバイル値（アイテムに値がない場合は空の文字列になる可能性があります）、またはアイテムが存在しないか、モバイルに不明の場合は特別な値「[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の量に基づいて設定して、1つのセットの優先ローミングリストデータまたは別のセットを使用することができます。このメカニズムは、診断上の理由でモバイル構成パラメーターの完全なセットを取得するなど、他の状況でも使用できます。
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:
以下のエントリは、FB9876EのESNとNAM 1を使用した、単一のモバイルステーションのサンプルACAPサーバーデータセットエントリの抜粋です。
/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 = "/tap/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 = "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.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.
新しいモバイルがサービスを許可されている場合、管理クライアントは、デバイスに固有のIT値に保存することにより、データセットを作成します。また、特定のモバイルに関連付けられていない値が必要に応じて継承されるように、「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認証メカニズムを示しています。プロビジョニングされた携帯電話の場合、共有された秘密は、未確認のデバイスに使用される限られた時間n-digitコードの代わりに、A-Keyから派生しています。
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認証の使用は、単純で簡単に実装でき、すべての手順と方法が整っているため、Data-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".
モバイルACAPクライアントは、エントリ「要求されたデータ」の属性「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.
サーバーは、要求されたデータ検索に応じて、要求されたデータの1つ以上の値を返すことにより、属性を保存するようにクライアントに指示します。
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」には、「電話メーキ」、「電話 - モデル」、「SW-REV」、「Free-NVRAM」の4つの値が含まれる場合があります。
* 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]".
要求されたDATA検索への応答が値を返す場合、クライアントはストアコマンドを発行します。Storeコマンドの各属性は、要求されたデータの1つの項目に対応します。クライアントがアイテムを認識していない場合、文字列「[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つの属性を書き込みます。各属性名は、OTAP.requested-data "属性の1つの値と同一です（プレフィックス" OTAP。 "を追加）。各属性値は、それぞれのモバイル値によって決定されます。
In our example, this STORE command sets the following attributes and values:
この例では、このストアコマンドは次の属性と値を設定します。
- "OTAP.Phone-Make" = "Qualcomm - "OTAP.Phone-Model" = "pdQ1900 - "OTAP.SW-Rev" = "001.030.0908" - "OTAP.Free-NVRAM" = "65536"
- "otap.phone-make" = "qualcomm-" otap.phone-model "=" 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).
モバイル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).
この検索コマンドは、名前が「プロビジョニング」から始まるエントリの「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.
サーバーは、それぞれが1つのエントリ名と1つの属性値としてプロビジョニングアイテムを返します。検索コマンドへのサーバーの応答には、返された最新のエントリのmodtimeが含まれます。
* Save values
* 値を保存します
The mobile writes the returned values into NVRAM.
モバイルは、返された値をNVRAMに書き込みます。
* STORE modtime
* modtimeを保存します
The ACAP client stores the returned modtime on the server as an acknowledgement that the data was received and NVRAM updated.
ACAPクライアントは、データが受信され、NVRAMが更新されたという認識として、サーバー上に返されたmodtimeを保存します。
* 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).
キャリアは、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-ポストスクリプトバージョンを参照]
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.
ワイヤレスデバイスは、ネットワーク居住者と構成という2つの異なるタイプのキャリアが提供するデータにアクセスすることを認識することが役立ちます。ネットワークレジデントデータは、主にキャリアのネットワーク内に存在します。例には、アカウントのステータス、請求の詳細、サービスプランオプションなどが含まれます。モバイルはユーザーディスプレイのこの情報にアクセスする場合がありますが、ネットワークに存在します。対照的に、構成データは携帯電話の操作に影響し、通常はユーザーには表示されず、デバイスに持続する必要があります。
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.
両方のタイプのデータに同じアクセス方法を使用しようとすると、ソリューションが不必要に複雑になり、設計、開発、デバッグの時間と費用が増加します。低コストのデバイスを提供することがより困難になります。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.
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は、TCP/IPソリューションのACAPのモバイルステーションプロトコルスイートを示しています。モバイルステーションは、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ハンドセットコードの再利用を可能にするために、ACAPを介してOTASPで使用されるデータ形式は、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.
IS-683Aを介してOTASPには、キャリアが使用する特定のCDMAインフラストラクチャのカスタム設計と開発が必要です。これにより、データ管理機能が大幅に制限され、ソリューションの拡張性が大幅に低下します。逆に、OTASPオーバーデータは、キャリアに拡張可能なプロビジョニングアクティビティを提供するインターネット標準ベースの機能を使用して、一般的な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（プロビジョニング）コールのメッセージシーケンスと操作を示しています。Data-OTASPソリューションは、IS-683A OTASPコールのすべての機能を実行する必要があります。提案されたソリューションは、これらの要件を満たしています。
[Figure 6 -- see PostScript version]
[図6-ポストスクリプトバージョンを参照]
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.
Data-Otapaには、Mobilesにプロビジョニングサーバーへのデータコールを発信するように指示する機能が必要です。いくつかの実行可能なアプローチについては、セクション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サーバーは本質的にクライアントへの変更のみを通知するため、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.
コールフロー図（図7）は、典型的なIS-683A OTAPA操作のメッセージシーケンスを示しています。Data-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.
1つの選択肢は、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-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.
このプロビジョニングサーバーは、IS-683A OTAFの後にモデル化されます。OTAFサーバーは、IS-683A OTAFの特定の操作とメッセージングを実行します。これには、A-Keyの再認証手順が含まれます。
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は、TCP/IPソリューションを介したIS-683Aのモバイルステーションプロトコルスイートを示しています。OTASPクライアントは、データトランスポートを介したIS-683A OTASPアクティビティまたはOTASPアクティビティの両方をサポートできます。
[Figure 9 -- see PostScript version]
[図9- PostScriptバージョンを参照]
Another alternative is to use forms embedded in web pages.
もう1つの選択肢は、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サーバーは非常に広く展開されており、誰もが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.
ただし、このためのメタプロトコルを設計する必要があり、完全に詳細な仕様を作成する必要があります。このソリューションでは、Meta-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.
また、Webは機能的に異なるため、高レベルのキャリア側のカスタマイズが必要になり、ベンダーの選択の削減と展開コストの増加につながります。
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ソリューションのもう1つの利点は、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.
[ACAP] Newman、C。and J. Myers、「ACAP-アプリケーション構成アクセスプロトコル」、RFC 2244、1997年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は、Simple Challenge/Responseの拡張を承認します」、RFC 2195、1997年9月。
[SASL] Myers, J., "Simple Authentication and Security Layer (SASL)", RFC 2222, October 1997.
[SASL] Myers、J。、「Simple Authentication and Security Layer（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
ランドール・ゲレンズ・クアルコム・インコーポレーション6455ラスク・ブルバード・サンディエゴ、カリフォルニア州92121-2779
Phone: +1 619 651 5115
EMail: randy@qualcomm.com
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。