RFC2636 日本語訳
2636 Wireless Device Configuration (OTASP/OTAPA) via ACAP. R. Gellens. July 1999. (Format: TXT=65288, PS=1120860, PDF=173655 bytes) (Obsoletes RFC2604) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group R. Gellens Request for Comments: 2636 Qualcomm Obsoletes: 2604 July 1999 Category: Informational
Gellensがコメントのために要求するワーキンググループR.をネットワークでつないでください: 2636 クアルコムは以下を時代遅れにします。 2604 1999年7月のカテゴリ: 情報
Wireless Device Configuration (OTASP/OTAPA) via ACAP
ACAPを通した無線電信Device Configuration(OTASP/OTAPA)
Status of this Memo
この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)インターネット協会(1999)。 All rights reserved。
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/を購入することである、-、683A、(過剰、空気、Spread Spectrum Systemsのモバイル駅のService Provisioning) 設備。 この費用は、キャリヤーが代替の解決策を求めるように導きました。 提供するための非常に実行可能な手段、過剰、空気、初公開に投機するために(OTA)の食糧を供給するのがある、-707である、データは展開の途中に設備を調整します。 この紙がOTAへのそれに食糧を供給すると展開が利用されるアプローチを提示する、-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.
-707である、データサービスで提供するいくつかの方法が利用可能になる、過剰、空気、食糧を供給するのとパラメタアップデート。 インターネットを利用するオープンスタンダードメカニズムを利用する考え抜かれたアプローチは一層のキャリヤーサービス提供、バックエンドサービスの中の高められた相互運用性、および業者独立に広げることができるプラットホームを供給できます。
This paper describes a viable and attractive means to provide OTASP/OTAPA via IS-707, using the ACAP [ACAP] protocol.
を通してこの論文がOTASP/OTAPAを提供する実行可能で魅力的な手段を説明する、-707である、ACAP[ACAP]プロトコルを使用します。
Gellens Informational [Page 1] RFC 2636 OTASP/OTAPA via ACAP July 1999
ACAP1999年7月を通したGellens Informational[1ページ]RFC2636OTASP/OTAPA
Table of Contents
目次
1. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Feature Descriptions . . . . . . . . . . . . . . . . . . . 6
2.1. OTASP Feature Description . . . . . . . . . . . . . . . 6
2.2. OTAPA Feature Description . . . . . . . . . . . . . . . 6
3. Operation . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1. Initial Provisioning Activity . . . . . . . . . . . . . 7
3.2. OTASP for Authorized Users . . . . . . . . . . . . . . . 8
3.3. OTAPA Activity . . . . . . . . . . . . . . . . . . . . 8
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1. General Requirements . . . . . . . . . . . . . . . . . 9
4.2. OTASP Requirements . . . . . . . . . . . . . . . . . . . 9
4.3. OTAPA Requirements . . . . . . . . . . . . . . . . . . 10
4.4. Provisioning Server Requirements . . . . . . . . . . . . 10
4.5. Security Requirements . . . . . . . . . . . . . . . . . 11
5. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 11
5.1. ACAP over TCP/IP . . . . . . . . . . . . . . . . . . . 11
5.1.1. Mobile Authentication and A-Key Generation . . . . . 12
5.1.2. Mobile Identification . . . . . . . . . . . . . . . 12
5.1.3. ACAP Server . . . . . . . . . . . . . . . . . . . . 12
5.1.4. Overview of ACAP Structure . . . . . . . . . . . . 13
5.1.5. Data Organization and Capabilities . . . . . . . . . 13
5.1.5.1. Structure . . . . . . . . . . . . . . . . . . . 14
5.1.5.2. Conventions . . . . . . . . . . . . . . . . . . 15
5.1.5.3. Dataset . . . . . . . . . . . . . . . . . . . . 15
5.1.5.4. Entries and Attributes . . . . . . . . . . . . . 15
5.1.5.5. NAM Records . . . . . . . . . . . . . . . . . . 16
5.1.5.6. Server Roaming Lists . . . . . . . . . . . . . . 17
5.1.5.7. Requested-Data Record . . . . . . . . . . . . . 18
5.1.5.8. Sample Server Entry . . . . . . . . . . . . . . 18
5.1.6. Administrative Client . . . . . . . . . . . . . . . 19
5.1.7. Mobile Client . . . . . . . . . . . . . . . . . . . 20
5.2. WAP with ACAP . . . . . . . . . . . . . . . . . . . . . 22
5.3. Network-Resident vs. Configuration Data . . . . . . . . 23
5.4. Intellectual Property Issues . . . . . . . . . . . . . 23
6. Handset Protocol Suites . . . . . . . . . . . . . . . . . . 23
6.1. ACAP over TCP/IP . . . . . . . . . . . . . . . . . . . 23
7. IS-683A Compatibility . . . . . . . . . . . . . . . . . . . 24
7.1. OTASP Operations . . . . . . . . . . . . . . . . . . . 24
7.2. OTASP Call Flow . . . . . . . . . . . . . . . . . . . . 24
7.3. OTAPA Operations . . . . . . . . . . . . . . . . . . . 24
7.4. OTAPA Call Flow . . . . . . . . . . . . . . . . . . . . 25
8. Alternative Methods . . . . . . . . . . . . . . . . . . . . 25
8.1. IS-683A over TCP/IP . . . . . . . . . . . . . . . . . . 25
8.1.1. OTAF Server . . . . . . . . . . . . . . . . . . . . 25
8.1.2. Interface Application . . . . . . . . . . . . . . . 26
8.1.3. Protocol Handset Suite . . . . . . . . . . . . . . 26
1. 用語. . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2。 記述. . . . . . . . . . . . . . . . . . . 6 2.1を特徴としてください。 OTASPは記述. . . . . . . . . . . . . . . 6 2.2を特徴とします。 OTAPAは記述. . . . . . . . . . . . . . . 6 3を特徴とします。 操作. . . . . . . . . . . . . . . . . . . . . . . . . 7 3.1。 食糧を供給する活動. . . . . . . . . . . . . 7 3.2に頭文字をつけてください。 認定ユーザ. . . . . . . . . . . . . . . 8 3.3のためのOTASP。 OTAPA活動. . . . . . . . . . . . . . . . . . . . 8 4。 要件. . . . . . . . . . . . . . . . . . . . . . . . 9 4.1。 一般要件. . . . . . . . . . . . . . . . . 9 4.2。 OTASP要件. . . . . . . . . . . . . . . . . . . 9 4.3。 OTAPA要件. . . . . . . . . . . . . . . . . . 10 4.4。 サーバ要件. . . . . . . . . . . . 10 4.5に食糧を供給します。 セキュリティ要件. . . . . . . . . . . . . . . . . 11 5。 構造. . . . . . . . . . . . . . . . . . . . . . . . 11 5.1。 TCP/IP. . . . . . . . . . . . . . . . . . . 11 5.1.1の上のACAP モバイル認証と1人のキー生成の.125.1、.2 モバイル識別. . . . . . . . . . . . . . . 12 5.1.3。 ACAPサーバ. . . . . . . . . . . . . . . . . . . . 12 5.1.4。 ACAP構造. . . . . . . . . . . . 13 5.1.5の概観。 データ編成と能力. . . . . . . . . 13 5.1.5、.1 .145.1に.2に.5を構造化してください。 コンベンション、.155.1 .5 .3。 データセット、.155.1 .5 .4。 エントリー、.155.1に、.5に.5を結果と考えます。 NAM記録. . . . . . . . . . . . . . . . . . 16 5.1.5.6。 サーバローミングリスト. . . . . . . . . . . . . . 17 5.1.5.7。 要求されたデータレコード.185.1、.5 .8。 サーバエントリー. . . . . . . . . . . . . . 18 5.1.6を抽出してください。 管理クライアント. . . . . . . . . . . . . . . 19 5.1.7。 モバイルクライアント. . . . . . . . . . . . . . . . . . . 20 5.2。 ACAP. . . . . . . . . . . . . . . . . . . . . 22 5.3とWAP。 コンフィギュレーション・データ. . . . . . . . 23 5.4に対してネットワーク固有です。 知的所有権問題. . . . . . . . . . . . . 23 6。 受話器プロトコル群. . . . . . . . . . . . . . . . . . 23 6.1。 TCP/IP. . . . . . . . . . . . . . . . . . . 23 7の上のACAP。 -、683A、互換性. . . . . . . . . . . . . . . . . . . 24 7.1 OTASP操作. . . . . . . . . . . . . . . . . . . 24 7.2。 OTASPは、流れ. . . . . . . . . . . . . . . . . . . . 24 7.3と呼びます。 OTAPA操作. . . . . . . . . . . . . . . . . . . 24 7.4。 OTAPAは、流れ. . . . . . . . . . . . . . . . . . . . 25 8と呼びます。 別法. . . . . . . . . . . . . . . . . . . . 25 8.1。 -、683A、TCP/IP. . . . . . . . . . . . . . . . . . 25 8.1.1 OTAFサーバ. . . . . . . . . . . . . . . . . . . . 25 8.1.2。 アプリケーション. . . . . . . . . . . . . . . 26 8.1.3を連結してください。 プロトコル受話器スイート. . . . . . . . . . . . . . 26
Gellens Informational [Page 2] RFC 2636 OTASP/OTAPA via ACAP July 1999
ACAP1999年7月を通したGellens Informational[2ページ]RFC2636OTASP/OTAPA
8.2. Browser-Based Forms . . . . . . . . . . . . . . . . . . 26
9. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . 27
10. References . . . . . . . . . . . . . . . . . . . . . . . . 28
11. Security Considerations . . . . . . . . . . . . . . . . . 28
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 28
13. Author's Address . . . . . . . . . . . . . . . . . . . . 28
14. Full Copyright Statement . . . . . . . . . . . . . . . . . 29
8.2. ブラウザベースのフォーム. . . . . . . . . . . . . . . . . . 26 9。 結論. . . . . . . . . . . . . . . . . . . . . . . . 27 10。 参照. . . . . . . . . . . . . . . . . . . . . . . . 28 11。 セキュリティ問題. . . . . . . . . . . . . . . . . 28 12。 承認. . . . . . . . . . . . . . . . . . . . . 28 13。 作者のアドレス. . . . . . . . . . . . . . . . . . . . 28 14。 完全な著作権宣言文. . . . . . . . . . . . . . . . . 29
1. Terms
1. 用語
Application Configuration Access Protocol (ACAP) -- An Internet protocol (RFC-2244) that provides remote storage and access of configuration and preference information.
アプリケーションConfiguration Accessプロトコル(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.
認証Key(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.
セルService Provider--Cellular Radiotelephone Serviceを提供するのが認可された責任政府代理店(連邦通信委員会の米国のa免許所有者の)の免許所有者。
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.
Message Digest5(CRAM-MD5)を使用する挑戦/応答Authentication Mechanism--実行するのが簡単であり、再生を含む様々な攻撃に対して手頃なセキュリティを提供する認証機構。 さまざまなインターネットプロトコルでは、支持されます。 ACAPの基線メカニズムとして、指定されています。 CRAM-MD5はRFC2195として発行されます。
Gellens Informational [Page 3] RFC 2636 OTASP/OTAPA via ACAP July 1999
ACAP1999年7月を通したGellens Informational[3ページ]RFC2636OTASP/OTAPA
Code Division Multiple Access -- A technique for spread-spectrum multiple-access digital communications that creates channels through the use of unique code sequences.
事業部Multiple Accessをコード化してください--普及スペクトル複数のアクセスディジタル通信のためのユニークなコード系列の使用でチャンネルを創造するテクニック。
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.
Customer Service代表--顧客サービスセンターを中心に活動して、ユーザ・サポートと加入者に対する支援を提供する人。
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.
ディフィー-ヘルマンAlgorithm--秘密鍵を交換するための公開カギ暗号アルゴリズム。 方程式を使用します。そこでは、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.
電子Serial Number(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.
ホームLocation Registry(HLR)--MINが記録の目的で加入者情報などのように割り当てられる位置のレジスタかデータベース。
Message Digest 5 (MD5) -- A one-way cryptographic hash function. Widely deployed in Internet protocols. Published as RFC 1321.
メッセージDigest5(MD5)--片道暗号のハッシュ関数。 インターネットプロトコルで広く配備されています。 RFC1321として、発行されます。
Mobile Identification Number (MIN) -- The 10-digit number that represents a mobile station's directory number.
モバイルIdentification 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.
モバイルSwitchingセンター(MSC)--セル無線電話機サービスを提供する設備の構成。
Mobile Terminal Authorizing System (MTAS) -- A control system that provides the capability to load the CDMA network HLR with mobile station profile information.
モバイルTerminal Authorizing System(MTAS)--CDMAネットワークHLRに移動局プロフィール情報を積む能力を提供する制御システム。
Gellens Informational [Page 4] RFC 2636 OTASP/OTAPA via ACAP July 1999
ACAP1999年7月を通したGellens Informational[4ページ]RFC2636OTASP/OTAPA
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.
数のAssignment Module(NAM)--可動のステーションはMINと他の加入者特有のパラメタが格納される電子記憶モジュールです。 マルチNAMの特徴を持っている移動局が数個の異なった市場で各位置に市内番号とともに記名することによって彼らのユニットを使用するオプションをユーザに提供します。
Over-the-air Service Provisioning Function (OTAF) -- A configuration of network equipment that controls OTASP functionality and messaging protocol.
過剰、空気、Service Provisioning Function(OTAF)--コントロールOTASPの機能性とメッセージングが議定書の中で述べるネットワーク装置の構成。
Over-the-air Parameter Administration (OTAPA) -- Network initiated OTASP process of provisioning mobile station operational parameters over the air interface.
過剰、空気、Parameter政権(OTAPA)--ネットワークは空気インタフェースの上で移動局の操作上のパラメタに食糧を供給するOTASPの過程に着手しました。
Over-the-air Service Provisioning (OTASP) -- A process of provisioning mobile station operational parameters over the air interface.
過剰、空気、Service Provisioning(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.
クィックNetは接続します(QNC)--、-707である、IPベースのインターネットにAsync Data Service Option番号を利用しますが、ダイレクト接続のためにモデム接続を迂回させるデータサービス能力。
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.
簡単なAuthenticationと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.
サービスProvider--会社、組織、売れているビジネスなどは、サービスを管理して、維持して、課金します。 サービスプロバイダーはネットワークのプロバイダーであるかもしれません。
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.
共有されたSecret Data(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)--データグラムを含む1セットのネットワークとアプリケーション・プロトコルがワイヤレス機器がウェブリソースにアクセスするのを可能にするのにキャリヤーベースのゲートウェイを使用する(WDP)、Transport Layer Security(WTLS)、Transactionプロトコル(WTP)、Sessionプロトコル(WSP)、およびApplication Environment(WAE)について議定書の中で述べます。 仕様と詳細に関して<http://www.wapforum.org>を見てください。
Gellens Informational [Page 5] RFC 2636 OTASP/OTAPA via ACAP July 1999
ACAP1999年7月を通したGellens Informational[5ページ]RFC2636OTASP/OTAPA
2. Feature Descriptions
2. 特徴記述
2.1. OTASP Feature Description
2.1. OTASP特徴記述
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:
Air Service Provisioning(OTASP)が特集するOverは、潜在的無線電信便加入者が新しい無線電信便を起動するのを許容して、既存の無線の加入者が第三者の介入なしでサービスを変化にするのを許容します。 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
* 「過剰、空気、」 任意にDataオプションパラメタを含むNumber Assignment Module(NAM)、IMSI、およびRoaming Listsのプログラミング、サービスプロバイダーまたはメーカーの特定のパラメタ
(e.g., lock code, call timer).
(例えば、コードをロックしてください、そして、タイマに電話をしてください。)
* An Authentication Key (A-key) Generation procedure.
* Authentication Key(A主要な)世代手順。
* A-key storage
* 1キーの格納
2.2. OTAPA Feature Description
2.2. OTAPA特徴記述
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.
Over空気Parameter政権(OTAPA)機能で、無線サービスプロバイダは離れて第三者の介入のない移動局でNAM、IMSI、およびRoaming List情報をアップデートできます。 この能力は、あらゆる受話器に影響する質量変化率にかかわるキャリヤーのために、柔軟性を高めて、コストを削減します、市外局番股割りなどのように。
OTAPA includes the following:
OTAPAは以下を含んでいます:
* Update a user's Number Assignment Module (NAM)
* ユーザのNumber Assignment Moduleをアップデートしてください。(NAM)
* Update Data option parameters
* アップデートDataオプションパラメタ
* Update service provider or manufacturer specific parameters (e.g.,
Server address(es), lock code, call timer).
* サービスプロバイダーかメーカーの特定のパラメタをアップデートしてください(例えば、Serverアドレス(es)、ロック・コードは、タイマと呼びます)。
* Update roaming lists
* アップデートローミングリスト
Gellens Informational [Page 6] RFC 2636 OTASP/OTAPA via ACAP July 1999
ACAP1999年7月を通したGellens Informational[6ページ]RFC2636OTASP/OTAPA
3. Operation
3. 操作
3.1. Initial Provisioning Activity
3.1. 導入準備作業活動
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).
声のシナリオ--顧客ケア代表は声の会話の間、信用情報を集めます。 この呼び出しが異なった電話(例えば、通信社)から作られるか、開始している使用である、存在、683A OTASPダイヤルする計画(すなわち、*228xx)。
Once the user has been authorized, the customer care representative
creates a record in the CDMA network HLR, thus allowing use of the
CDMA network. In addition, a limited-time N-digit password is
created which is tied to the ESN. The choice of N (how many digits)
is up to the carrier (as a trade-off between security and user
inconvenience). All required provisioning information (including
the limited-time password) is loaded into the provisioning server.
ユーザがいったん権限を与えられると、顧客ケア代表はCDMAネットワークHLRでの記録を作成します、その結果、CDMAネットワークの使用を許します。 さらに、ESNに結ばれる期間限定N-ケタパスワードは作成されます。 N(いくつのケタ)の選択はキャリヤー(セキュリティとユーザ不便の間のトレードオフとしての)次第であるか。 すべてが、(期間限定パスワードを含んでいます)が食糧を供給するサーバにロードされるという情報に食糧を供給するのを必要としました。
The user is then told to hang up and call a special number, of the
form *228 XX <N-digit password> SEND (the XX code is the same as
used in the initial voice call). This causes the mobile station to
initiate a provisioning session.
そして、>SENDにフォーム*228XX<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操作は始まります。 さもなければ、音声通話は顧客ケア代表に作られています。
Gellens Informational [Page 7] RFC 2636 OTASP/OTAPA via ACAP July 1999
ACAP1999年7月を通したGellens Informational[7ページ]RFC2636OTASP/OTAPA
Desktop scenario -- The subscriber uses a desktop (or in-store
kiosk) web browser to contact the carrier, and enters the usual
personal information.
デスクトップシナリオ、--、加入者がデスクトップを使用する(用意して、キオスク) ウェブブラウザ、運送業者に連絡して、普通の個人情報を入力します。
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操作は始まります。 さもなければ、ユーザが声を顧客ケア代表に呼びかけさせるように頼まれます。
3.2. OTASP for Authorized Users
3.2. 認定ユーザのための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ネットワークの使用のために既に権限を与えられたユーザは食糧を供給する活動を開始できます。 これはCustomer Care代表でそうするよう電話の会話かメール通知で指示された後に、起こることができました。 このタイプの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活動の心に浮かびます。 同様に、移動局は新しい食糧を供給する情報をダウンロードします。
3.3 OTAPA Activity
3.3 OTAPA活動
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か特別な発信者番号を通した)まで列に並ばせることによって、これを達成できます。 移動局がキャリヤーのネットワークで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.
あるいはまた、aがセットの間隔を再確認する包含でOTAPAを扱うことができます。データは支給に移動局を使用しました。 ACAPなどの低いオーバーヘッドプロトコル[ACAP]を使用するとき、移動局を何か変化したかどうかを見るために定期的にチェックインさせるのは、妥当です。 食糧を供給するデータにそのようなものが再確認されるのが起こるべきである週の時刻、そして/または、曜日を含むことができました。
OTAPA activity can be terminated at any time due to user call
activity.
いつでも、ユーザ呼び出し活動のためOTAPA活動を終えることができます。
Gellens Informational [Page 8] RFC 2636 OTASP/OTAPA via ACAP July 1999
ACAP1999年7月を通したGellens Informational[8ページ]RFC2636OTASP/OTAPA
4. Requirements
4. 要件
4.1. General Requirements
4.1. 一般要件
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).
そして、-、683A OTASP、操作がa移動局の間に起こる、過剰、航空便、機能(OTAF)使用に食糧を供給する、-、95A、トラフィックチャンネルデータはメッセージを押し破きました。 サービスが必要とするデータを通したCDMAキャリヤーが持っているOTASP/OTAPA、-707である、できるサービスがネットワークでつなぐデータ。 -707である、サービス、Packet Data Serviceでなければならない、(-707.5である、)、または、クィックNetは接続しています(QNC)。
The mobile station must support:
移動局は以下をサポートしなければなりません。
* IS-707 Data Service capability
* -707である、Data Service能力
* Packet/QNC RLP protocol
* パケット/QNC RLPプロトコル
* PPP protocol to peer to the IS-707 IWF
* PPPがじっと見るために議定書を作る、-707である、IWF
* IP protocol to provide the network layer for routing to the
provisioning server
* 食糧を供給するサーバへのルーティングにネットワーク層を提供するIPプロトコル
* A transport layer for end-to-end communication (such as TCP)
* エンド・ツー・エンド通信のためのトランスポート層(TCPなどの)
* Authentication and optionally encryption
* 認証、任意に、暗号化
* Application software to handle the provisioning protocol and
memory access.
* 食糧を供給するプロトコルとメモリアクセサリーを扱うアプリケーション・ソフト
* Domain Name System (DNS) query capabilities sufficient to obtain
the (IP) address of the provisioning server (or the provisioning
server's address could be provided during PPP negotiation).
* ドメインネームシステム(DNS)は食糧を供給するサーバの(IP)アドレスを得ることができるくらいの能力について質問します(PPP交渉の間、食糧を供給するサーバのアドレスを提供できました)。
Lastly, the ability must exist for the mobile to make a data call
(optionally) a voice call without a MIN.
最後に、モバイルがMINなしでデータ電話(任意に)を音声通話にかけるように、能力は存在しなければなりません。
4.2. OTASP Requirements
4.2. OTASP要件
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機能が、移動局が起因するのを必要とする、存在、完全に非食糧を供給された移動局を使用する707データ呼び出しと(任意に)音声通話。 CDMAネットワークはこの能力をサポートしなければなりません。
OTASP via data services uses a provisioning server that contains the
parameter information for mobile stations. The authorizing agent
(or software) at the customer care center must be able to add user
and mobile station information into both the CDMA network HLR and
データサービスを通したOTASPは移動局にパラメタ情報を含む食糧を供給するサーバを使用します。 そして顧客サービスセンターの権限を与えているエージェント(または、ソフトウェア)が両方へのユーザを加えることができて移動局情報がCDMAネットワークHLRであったならそうしなければならない。
Gellens Informational [Page 9] RFC 2636 OTASP/OTAPA via ACAP July 1999
ACAP1999年7月を通したGellens Informational[9ページ]RFC2636OTASP/OTAPA
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.
初期の認可プロセスの間の食糧を供給するサーバ。 記録が作成されるとすぐに、食糧を供給するサーバはモバイルを修理できなければなりません。
4.3. OTAPA Requirements
4.3. OTAPA要件
IS-683A OTAPA is performed by a mobile-terminated call that
downloads parameters to the mobile station. OTAPA calls occur
without user interaction.
-、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メッセージ内容は移動局によって必要とされた情報を含むことができます。 移動局はいつ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活動を開始するのに使うことができる代替の手段があります。 例えば、専門化している電話番号を使用する発信者番号とのモバイルで終えられた音声通話。 別の代替手段は移動局がアップデートされた情報がないかどうかチェックするために定期的に食糧を供給するサーバでチェックインされることです。 例えばACAPはそのようなモデルのために設計されています。 間隔を再確認して、時刻と同じくらいよく、週のそのようなチェックが食糧を供給することの一部がデータであるかもしれないなら使用される曜日間、移動局に送ります。
4.4. Provisioning Server Requirements
4.4. サーバ要件に食糧を供給します。
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
-、683A、利用、過剰、航空便、活動に食糧を供給するネットワーク側を実行するために機能(OTAF)に食糧を供給します。 データサービスを通したOTASP/OTAPAはOTAFを食糧を供給するサーバに取り替えます。食糧を供給するサーバはキャリヤーの制御境界の中のIPネットワークにあります。 食糧を供給するサーバはOTAFが提供するすべてのサービスの食糧を供給するのとパラメタ管理機能を実行しなければなりません。 また、食糧を供給するサーバはキャリヤーのモバイルTerminal Authorizing System(MTAS)にインタフェースを持たなければなりません。 このインタフェースは、食糧を供給するサーバをMTASの情報と同期させるのに役立ちます。 このインタフェースに関する決められた一定の要求はキャリヤーの顧客サービスセンターシステムの能力とインタフェースによります。 食糧を供給するサーバは、MTASからダイナミックなアップデートを受けることができて、すぐに、食糧を供給する情報を持たなければなりません。
Gellens Informational [Page 10] RFC 2636 OTASP/OTAPA via ACAP July 1999
ACAP1999年7月を通したGellens Informational[10ページ]RFC2636OTASP/OTAPA
available for downloading into the chosen mobile station. A
standard ACAP server provides an excellent means to meet these
requirements.
選ばれた移動局にダウンロードするのに、利用可能です。 標準のACAPサーバはこれらの必要条件を満たす素晴らしい手段を提供します。
The provisioning server must be capable of performing an
authentication procedure with the mobile station. This
authentication mechanism must be capable of authenticating both the
mobile station and the provisioning server.
食糧を供給するサーバは認証手順を移動局に実行できなければなりません。 この認証機構は移動局と食糧を供給するサーバの両方を認証できなければなりません。
4.5. Security Requirements
4.5. セキュリティ要件
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
* ディフィー-ヘルマンメカニズムを使用するOTAF A-キー生成
Or:
または、:
* Receiving A-keys from the carrier network.
* キャリヤーネットワークからA-キーを受けます。
Since data OTASP/OTAPA operates over IP within the carrier's
network, end-to-end encryption between the mobile station and the
provisioning server should be considered as a future enhancement.
End-to-end encryption protects against attacks from within a
carrier's network, and safeguards the provisioning data (for
example, roaming lists).
データOTASP/OTAPAがキャリヤーのネットワークの中でIPの上で作動するので、移動局と食糧を供給するサーバの間の終端間暗号化は今後の増進であるとみなされるべきです。 終端間暗号化は、キャリヤーのネットワークから攻撃から守って、食糧を供給するデータを保護しています(例えば、ローミングは記載します)。
5. Architecture
5. アーキテクチャ
5.1. ACAP over TCP/IP
5.1. TCP/IPの上のACAP
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は、どれが、Application Configuration Accessがプロトコル(ACAP、RFC2244)であるとサポートするかをキャリヤーのイントラネットにおける食糧を供給するサーバに示します。 顧客ケアドメインの管理クライアントは、ACAPを使用することでこのサーバをアップデートします。 受話器は、小さいACAPクライアントを使用することで食糧を供給されて、構成されます。
[Figure 1 -- see PostScript version]
[図1--ポストスクリプトバージョンを見ます]
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は特に認証機構、専門化している属性取り扱い、およびデータ管理に高度合いの伸展性を供給します。
Gellens Informational [Page 11] RFC 2636 OTASP/OTAPA via ACAP July 1999
ACAP1999年7月を通したGellens Informational[11ページ]RFC2636OTASP/OTAPA
5.1.1. Mobile Authentication and A-Key Generation
5.1.1. モバイル認証と1キーの世代
The mobile client authenticates with the ACAP server prior to
performing any activities. Authentication uses the mobile's ESN and
a shared secret. Provisioned mobiles derive the shared secret from
the A-Key; unprovisioned mobiles use a limited-time password as the
secret.
モバイルクライアントは実行の前にACAPサーバによるどんな活動も認証します。 認証はモバイルのESNと共有秘密キーを使用します。 食糧を供給されたモバイルが共有秘密キーにA-キーに由来しています。 非食糧を供給されたモバイルは秘密として期間限定パスワードを使用します。
The limited-time password is provided to the user by the Customer
Care representative during the initial call (as instructions to dial
a specific number). This code is N digits long. The carrier
selects the number of digits, as a trade-off between security and
user convenience.
期間限定パスワードは初期の要求(特定の番号にダイヤルする指示としての)の間、Customer Care代表によってユーザに提供されます。 長い間、このコードは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)に入力されるようにサーバから共有秘密キーと無作為の挑戦を使用します。 これが存在に類似している、-、683A、無作為の挑戦とCAVEアルゴリズムを使用する認証機構。
An A-Key is generated using a Diffie-Hellman exchange, as is done in
IS-683A.
するようにディフィー-ヘルマンの交換を使用するのがA-キーに生成される、-、683A
5.1.2. Mobile Identification
5.1.2. モバイル識別
Provisioning records are identified using the ESN and the current
NAM in use.
食糧を供給する記録は、使用中のESNと現在のNAMを使用することで特定されます。
5.1.3. ACAP Server
5.1.3. ACAPサーバ
As a standard ACAP server, the provisioning server includes
configurable datasets and dataset inheritance for the management of
the data stores.
標準のACAPサーバとして、食糧を供給するサーバはデータ・ストアの管理のための構成可能なデータセットとデータセット継承を含んでいます。
The administrative client can use the same simple ACAP protocol to
load and modify the ACAP server as the mobile stations uses for
provisioning. While any implementation-specific mechanisms
available from the server vendor could instead be used for this
purpose, the ability to use ACAP can greatly simplify the
administrative client, as well as make it independent of the server.
管理クライアントは、食糧を供給することへの移動局用途としてACAPサーバをロードして、変更するのに同じ簡単なACAPプロトコルを使用できます。 代わりにこのためにサーバベンダーから利用可能などんな実装特有のメカニズムも使用できた間、ACAPを使用する能力は、管理クライアントを大いに簡素化して、サーバの如何にかかわらずそれを作ることができます。
ACAP includes an authentication framework (Simple Authentication and
Security Layer, SASL, RFC 2222)[SASL]. SASL allows any standard or
custom authentication and encryption mechanism to be used. One of
the most important features of SASL is that it is designed for a
world in which what is "good enough" security today isn't good
enough tomorrow. As the threat model changes, SASL allows higher-
strength mechanisms to be easily added while supporting already
ACAPが認証フレームワークを含んでいる、(RFC2222) 簡単なAuthenticationとSecurity Layer、SASL、[SASL。] SASLは、どんな標準の、または、カスタムの認証と暗号化メカニズムも使用されるのを許容します。 SASLの最も重要な特徴の1つはそれが今日「十分良い」セキュリティであることが明日十分良くない世界に設計されているということです。 脅威モデルが変化するとき、既にサポートしている間、SASLは、より高い強さメカニズムを容易に加えさせます。
Gellens Informational [Page 12] RFC 2636 OTASP/OTAPA via ACAP July 1999
ACAP1999年7月を通したGellens Informational[12ページ]RFC2636OTASP/OTAPA
deployed clients and servers. SASL is achieving widespread
deployment in a number of Internet protocols.
クライアントとサーバであると配布されます。 SASLは多くのインターネットプロトコルにおける広範囲の展開を達成しています。
Strongpoints: Since the ACAP protocol was designed for precisely
this type of provisioning activity, its adoption can greatly reduce
the cost, time to market, and support required for the provisioning
server. Additionally, the ACAP protocol provides an open standard
method for mobile stations and other systems to access the
provisioning server. Commercial ACAP servers are being developed by
numerous companies. The ACAP client code is very small and simple,
and thus can be incorporated into virtually any mobile device at
minimal cost. As an open standard, the ACAP protocol has benefited
from years of review and experience.
防御拠点: ACAPプロトコルが正確に活動に食糧を供給するこのタイプのために設計されたので、採用はコスト、売り出す時間、および食糧を供給するサーバに必要であるサポートを大いに削減できます。さらに、ACAPプロトコルは移動局と他のシステムが食糧を供給するサーバにアクセスするオープンスタンダードメソッドを提供します。市販のACAPサーバは多数の会社によって開発されています。 ACAPクライアントコードは、非常に小さくて、簡単であり、その結果、最小量の費用で実際にはどんなモバイル機器にも組み入れることができます。 オープンスタンダードとして、ACAPプロトコルは何年ものレビューと経験の利益を得ました。
5.1.4. Overview of ACAP Structure
5.1.4. 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.
例えば、人の接触のための名前、Eメールアドレス、電話番号、および関連する情報を保持するように設計されたACAP addressbookデータセットのクラスを考えてください。 与えられたユーザには、1つ以上のaddressbookデータセットがあるかもしれません。 各エントリーは1つの人か実体の情報を保持します。 エントリーにおける属性は情報の特定の項目を保持します、名、姓、様々なEメールアドレス、電話番号などなどのように。 エントリーが人々(人々のメーリングリストか特定のグループなどの)のリストであるなら、それは「副-データセット」です、それ自身のエントリーを含んでいて。 属性の部分集合だけを見るクライアントもいるかもしれません。 例えば、移動体端末ACAPクライアントはそれぞれのエントリーの別名(あだ名)、名前、プライマリ電話番号、およびEメールアドレスだけをダウンロードするかもしれません、デスクトップクライアントはすべての属性にアクセスするかもしれませんが。
5.1.5. Data Organization and Capabilities
5.1.5. データ編成と能力
ACAP provides custom hierarchical datasets. Server data can be
organized to fit the needs of the applications using the dataset.
ACAPはカスタム階層的なデータセットを提供します。 データセットを使用することでサーバデータがアプリケーションの必要性に合うのを組織化できます。
Gellens Informational [Page 13] RFC 2636 OTASP/OTAPA via ACAP July 1999
ACAP1999年7月を通したGellens Informational[13ページ]RFC2636OTASP/OTAPA
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能力を利用して、サーバに関するデータがそれが同じである項目を使用するのが組織化される、-、683A、再利用を考慮する、-、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.
データセットはユーザ、グループ、およびホスト階層構造の中に存在しています。 ユーザ階層構造は個々のユーザのものであるデータセットを保持します。 グループ階層構造はグループ(例えば、.6. グループが中で5.1に区分する「領域」.3Server Roaming Lists)に属すデータセットを保持します。 ホスト階層構造は特定のマシンかシステムのためのものであるデータセットを保持します。
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はいくつかの標準のデータセットをすべてのクライアントに提供します。 一般に、特定のクライアントにとって、利用可能なカスタム機能性と拡張機能の上、または、サイトに情報を保管している能力データセットがあります。 これはそれがサポートするどんなプロトコル拡大も広告を出すサーバ、専門化している属性取り扱い、または他の強化機能を許容します。 その結果、これらの特徴を使用する必要があるクライアントは、それらを使用しようとする前に何が利用可能であるかを容易に決心できます。
5.1.5.1. Structure
5.1.5.1. 構造
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の品目と要求されたデータ項目は含んでいます。集団項目(都合のよいローミングリストなどの)はどんなモバイル機器にも特定ではありません。 集団項目は、それら自身のデータセットに物理的に存在していますが、クライアントデータセットに継承を通して論理的に現れます。
Gellens Informational [Page 14] RFC 2636 OTASP/OTAPA via ACAP July 1999
ACAP1999年7月を通したGellens Informational[14ページ]RFC2636OTASP/OTAPA
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.
移動局は、エントリーに食糧を供給するのでいつもデータを読んで、属国エントリーにデータを書きます。 この構造で、モバイルクライアントとサーバ構成の両方が大規模な習慣と診断能力を考慮している間、簡単で簡単になります。
5.1.5.2. Conventions
5.1.5.2. コンベンション
"" 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プロトコルの一部です。
5.1.5.3. Dataset
5.1.5.3. データセット
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"属性は項目値を含んでいます。 この構造は1項目あたり1個のベースに関する変更届出書を可能にします。
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.
項目の部分的なリストは従います。
5.1.5.4. Entries and Attributes
5.1.5.4. エントリーと属性
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属性です。 存在している、「「各データセットの中のエントリー(空の名前によるエントリー)。」
Gellens Informational [Page 15] RFC 2636 OTASP/OTAPA via ACAP July 1999
ACAP1999年7月を通したGellens Informational[15ページ]RFC2636OTASP/OTAPA
5.1.5.5. NAM Records
5.1.5.5. NAM記録
The OTAP dataset class contains an entry for each provisioned
mobile. The standard location for provisioning records is:
OTAPデータセットのクラスはそれぞれの食糧を供給されたモバイルのためのエントリーを含みます。 記録に食糧を供給するための標準の位置は以下の通りです。
/OTAP/USER/<esn>/<nam>/
/OTAP/USER/<esn>/<nam>/
This tree format allows multiple NAMs per ESN. The specific entries
contain data in IS-683A parameter block types.
この木の形式は複数の1ESNあたりのNAMsを許容します。 特定のエントリーがデータを含んでいる、-、683A、パラメタゴシック体。
For example, the CDMA NAM would be stored in an entry called:
例えば、CDMA NAMは呼ばれるエントリーに保存されるでしょう:
/OTAP/USER/<esn>/<nam>/Provision.CDMA-NAM/
/OTAP/USER/<esn>/<nam>/Provision.CDMA-NAM/
The entries below show how NAM records would be organized on the
ACAP server:
以下でのエントリーはNAM記録がACAPサーバでどう組織化されるだろうかを示しています:
CDMA/Analog NAM
CDMA/アナログNAM
Entry-Path: /OTAP/USER/<esn>/<nam>/Provision.CDMA-AMPS-NAM/
エントリー経路: /OTAP/USER/<esn>/<nam Provision.CDMA増幅器>/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).
CDMA/アナログNAMエントリー、-、683A、(4.5に少なくとも.1が)成る.2を129情報ビット区分してください、SID NIDリストエントリーの数によって。 これはバイナリ・データの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".
モバイルディレクトリNumber、-、683A、電話番号を表すBCDによってコード化されたケタを含んでいます。 これは10ASCIIケタ以上、例えば、一連の「6195551212」として保存されます。
CDMA NAM
CDMA NAM
Entry-Path: /OTAP/USER/<esn>/<nam>/ Provision.CDMA-NAM/
エントリー経路: /OTAP/USER/<esn>/<nam>/ Provision.CDMA-NAM/
OTAP.Value: {13} xx xx xx ... xx
OTAP.Value: 13 xx xx xx…xx
Gellens Informational [Page 16] RFC 2636 OTASP/OTAPA via ACAP July 1999
ACAP1999年7月を通したGellens Informational[16ページ]RFC2636OTASP/OTAPA
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).
CDMA-NAMエントリー、-、683A、(4.5に少なくとも.3が)成る.2を100情報ビット区分してください、SID-NIDリストエントリーの数によって。 これはバイナリ・データの13(さらに)の八重奏として保存されます(詰め物は整数の八重奏を確実にするのに使用されます)。
IMSI_T
IMSI_T
Entry-Path: /OTAP/USER/<esn>/<nam>/ Provision.IMSI_T/
エントリー経路: /OTAP/USER/<esn>/<nam>/Provision.IMSI_T/
OTAP.Value: {7} xx xx xx xx xx xx xx
OTAP.Value: 7 xx xx xx xx xx xx xx
The IMSI_T entry from IS-683A (section 4.5.2.4) consists of 55
bits of information in five fields. This is stored left-
justified in 7 octets of binary data.
IMSI_Tエントリー、-、683A、(セクション4.5 .2 .4は)5つの分野で55ビットの情報から成ります。 これは左にバイナリ・データの7つの八重奏で正当な状態で保存されます。
5.1.5.6. Server Roaming Lists
5.1.5.6. サーバローミングリスト
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 Serverには、キャリヤーのためのそれぞれの異なったローミングリスト構成のためのエントリーがあるでしょう。 1セットの自由なNVRAMあたりのローミングリストが各領域に存在するモバイル自由なNVRAM Itショーの層が及ぶので、以下の例は、区画分譲地でローミングリストのための必要な分化が地理的であると仮定します。 キャリヤーが、単にデータセット木であって割り当てにされるのを変えるのによる異なるかさらなる分化(例えば、電話ベンダーか製品タイプによる)が適切な値であると容易に食糧を供給する記録の"dataset.inherit"属性に実装することができることに注意してください。
/OTAP/GROUP/region.NorthEast/free-nv.128-512/
preferred.roaming.list/OTAP.Value
/OTAP/GROUP/region.NorthEast/free-nv.512-1024/
preferred.roaming.list/OTAP.Value
/OTAP/GROUP/region.SouthEast/free-nv.128-512/
preferred.roaming.list/OTAP.Value
/OTAP/GROUP/region.SouthEast/free-nv.512-1024/
preferred.roaming.list/OTAP.Value
/OTAP/GROUP/region.NorthWest/free-nv.128-512/
preferred.roaming.list/OTAP.Value
/OTAP/GROUP/region.NorthWest/free-nv.512-1024/
preferred.roaming.list/OTAP.Value
/OTAP/GROUP/region.SouthWest/free-nv.128-512/
preferred.roaming.list/OTAP.Value
/OTAP/GROUP/region.SouthWest/free-nv.512-1024/
preferred.roaming.list/OTAP.Value
自由な自由な自由な/OTAP/GROUP/region.NorthEast/free-nv.128-512/preferred.roaming.list/OTAP.Value/OTAP/グループ/region.NorthEast/nv.512-1024/preferred.roaming.list/OTAP.Value/OTAP/グループ/region.SouthEast/nv.128-512/preferred.roaming.list/OTAP.Value/OTAP/グループ/region.SouthEast/nv.512-1024/preferred.roaming.list/OTAP; 自由な自由な自由な値の/OTAP/GROUP/region.NorthWest/free-nv.128-512/preferred.roaming.list/OTAP.Value/OTAP/グループ/region.NorthWest/nv.512-1024/preferred.roaming.list/OTAP.Value/OTAP/グループ/region.SouthWest/nv.128-512/preferred.roaming.list/OTAP.Value/OTAP/グループ/region.SouthWest/nv.512-1024/preferred.roaming.list/OTAP.Value
Gellens Informational [Page 17] RFC 2636 OTASP/OTAPA via ACAP July 1999
ACAP1999年7月を通したGellens Informational[17ページ]RFC2636OTASP/OTAPA
5.1.5.7. Requested-Data Record
5.1.5.7. 要求されたデータレコード
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.
名前によるエントリーが「Provision.Requested-データ」であるというOTAPデータセットで。(それは、「OTAP.Requested-データ」と呼ばれる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クライアントは「Provision.Requested-データ」エントリーの「OTAP.Requested-データ」属性の値を検索する検索命令を発行します。 クライアントは、「クライアント」エントリーに1つ以上の属性をはめ込むストアコマンドを発行することによって、戻り値(もしあれば)を処理します。 項目が存在していないか、またはモバイルで未知であるなら、それぞれの属性の値は、対応するモバイル値(項目に値が全くないなら、空のストリングであるかもしれない)か「[なし]」という特別な値のどちらかです。
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セットの都合のよいローミングリストデータか別のものが使用されることを引き起こすように設定できました。 また、他の状況(診断理由で完全なモバイル設定パラメータを検索するようなもの)でこのメカニズムを使用できます。
5.1.5.8. Sample Server Entry
5.1.5.8. サンプルサーバエントリー
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とNAM1を使用するESNがある単一の移動局へのサンプル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/"
エントリーが等しい、「「dataset.inheritは「/OTAP/GROUP/region.NorthEast/ free-nv.128-512/preferred.roaming.list/ OTAP.Value/」と等しいです」。
entry = "Provision.Requested-Data"
OTAP.Requested-Data = ("Phone-Make" "Phone-Model" "SW-Rev"
"Free-NVRAM")
エントリーは「Provision.Requested-データ」OTAP.Requested-データ=と等しいです。(「電話モデル」「SW-回転」「自由な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"
エントリー=「クライアント」は=「クアルコム」OTAP.Phone-モデル=を"pdQ1900"OTAP.SW-回転=「001.030に、0.0908インチのOTAP.Free-NVRAMは「65536」OTAP.Last-Modtime=「199812181703」と等しく」OTAP.Phoneします。
Gellens Informational [Page 18] RFC 2636 OTASP/OTAPA via ACAP July 1999
ACAP1999年7月を通したGellens Informational[18ページ]RFC2636OTASP/OTAPA
entry = "Provision.Mobile-DN"
OTAP.Value = {10} 619 555 1234
"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は13xx 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.
このデータセットは、移動局にダウンロードされたデータだけではなく、サーバによって要求されたクライアントデータの項目(Requested-データ属性)とそれらの項目の値(「クライアント」エントリー)にも食糧を供給しながら、目立っています。 また、それは、モバイルクライアントが首尾よくmodtime「199812181703」に関連している値を保存したのを示します。 さらに、それは、このクライアントが「北東」の領域からデータ(すなわち、ローミングリスト)を引き継ぐのを示します。
5.1.6. Administrative Client
5.1.6. 管理クライアント
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.
管理クライアントは一般的なブラウズと編集能力をユーザ記録に提供できます。
Gellens Informational [Page 19] RFC 2636 OTASP/OTAPA via ACAP July 1999
ACAP1999年7月を通したGellens Informational[19ページ]RFC2636OTASP/OTAPA
* 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アップデート手順に依存する、(例えば、CLID的、そして、周期的なSMS、再確認、)、管理クライアントは活動を開始するのにかかわるかもしれません。 これは食糧を供給するサーバにインタフェースを使用するかもしれません。
5.1.7. Mobile Client
5.1.7. モバイルクライアント
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のモバイルクライアントがそれが同等物を実行する州のマシンとして実装される、-、683A、パラメタ情報交換と非揮発性メモリーストレージに食糧を供給します。 ACAP Client州のマシンダイヤグラム(図2)と記述が以下にあります。
[Figure 2 -- see PostScript version]
[図2--ポストスクリプトバージョンを見ます]
* 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--ポストスクリプトバージョンを見ます]
Gellens Informational [Page 20] RFC 2636 OTASP/OTAPA via ACAP July 1999
ACAP1999年7月を通したGellens Informational[20ページ]RFC2636OTASP/OTAPA
* 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-データ」を返すようにサーバに頼む検索命令を発行します。
* 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つ以上の値でRequested-データ検索に対応して属性を保存するようクライアントに命令します。
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-データ」は4つの値を含むかもしれません: 「電話造」、「SW-回転」の、そして、「自由なNVRAM」の「電話モデル。」
* STORE attribute list
* ストア属性リスト
If the response to the requested-data SEARCH returns any
values, the client issues a STORE command. Each attribute in
the STORE command corresponds to one item of requested-data.
If the client does not recognize an item, it stores the string
"[n/a]".
要求されたデータ検索への応答が何か値を返すなら、クライアントはストアコマンドを発行します。 ストアコマンドにおける各属性は要求されたデータの1つの項目に対応しています。 クライアントが項目を認めないなら、それは「[なし]」というストリングを保存します。
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-データの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作る」、「クアルコム--=を「OTAP.Phoneモデル化する」、「pdQ1900、--「OTAP.SW-回転」が「001.030に、"OTAP.Free-NVRAM"は「65536」と何0.0908インチも、等しいこと」と等しい
* 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クライアントは最後にチェックインして以来(初期のセッションのときにデータに食糧を供給しながら、すべてを検索します)変化している食糧を供給するデータのどんな項目も検索する検索命令を発行します。
Gellens Informational [Page 21] RFC 2636 OTASP/OTAPA via ACAP July 1999
ACAP1999年7月を通したGellens Informational[21ページ]RFC2636OTASP/OTAPA
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つの入口名と人がそれぞれ値を結果と考えるとき、サーバは商品を食糧を供給するのに返します。 検索命令へのサーバ応答は返された最新のエントリーの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.
クライアントはLOGOUTコマンドを発行します。
* Close transport layer
* トランスポート層を閉じてください。
The client closes the TCP connection.
クライアントはTCP接続を終えます。
* End call
* 終わりの呼び出し
The data call is terminated.
データ呼び出しは終えられます。
5.2. WAP with ACAP
5.2. ACAPとWAP
An advantage of the ACAP solution is that is can easily coexist with
a WAP-based mechanism, giving carriers more options.
ACAPソリューションの利点はそうです、すなわち、容易に、より多くのオプションをキャリヤーに与えて、WAPベースのメカニズムと共存できます。
A carrier can deploy handsets into its service area which use WAP-
based provisioning, if desired, alongside those which use ACAP
provisioning. All that is required is that the WAP server contain a
small ACAP client (or an interface to an ACAP server).
キャリヤーはサービスエリアへのWAPのベースの食糧を供給することを使用する受話器を配布することができます、望まれているなら、ACAPの食糧を供給することを使用するものと並んで。 必要であるすべてはWAPサーバが小さいACAPクライアント(または、ACAPサーバへのインタフェース)を含むということです。
Figure 4 shows how mobile stations can be configured using a WAP
browser. By using an ACAP server for provisioning, carriers are
free to simultaneously deploy mobile stations that use either WAP or
ACAP, as desired. In either case, the ACAP server is the source for
provisioning data.
図4はWAPブラウザを使用することでどう移動局を構成できるかを示しています。 食糧を供給するのにACAPサーバを使用することによって、キャリヤーは同時に無料でWAPかACAPのどちらかを使用する移動局を配布することができます、望まれているように。 どちらかの場合では、ACAPサーバは、データに食糧を供給するためのソースです。
Gellens Informational [Page 22] RFC 2636 OTASP/OTAPA via ACAP July 1999
ACAP1999年7月を通したGellens Informational[22ページ]RFC2636OTASP/OTAPA
[Figure 4 -- see PostScript version]
[図4--ポストスクリプトバージョンを見ます]
5.3. Network-Resident vs. Configuration Data
5.3. コンフィギュレーション・データに対してネットワーク固有です。
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.
ネットワーク固有のデータ・アクセスのために、当然の選択はウェブです。 ウェブブラウザに妥当なソリューションを作って、データは、非常に対話的、そして、異形を調節します。 どんな適切なウェブブラウザも使用できます。 ウェブブラウザがディスプレイを含んでいる、ユーザ相互作用ができるワイヤレス機器にある多くのもっともな理由があります。
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つのタイプに関するデータが基本的に異なるので、それぞれのために最適のコードとプロトコルを選択するのは、良いエンジニアリング方式です。
5.4. Intellectual Property Issues
5.4. 知的所有権問題
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クライアントとサーバを開発しています。
6. Handset Protocol Suites
6. 受話器プロトコル群
6.1. ACAP over TCP/IP
6.1. TCP/IPの上のACAP
Figure 5 depicts the mobile station protocol suite for the ACAP over
TCP/IP solution. The mobile station is capable of supporting both
IS-683A OTASP and OTASP over ACAP.
図5はACAPのためにTCP/IP解決の上に移動局プロトコル群について表現します。 移動局が両方をサポートすることができる、-、683A OTASP、そして、ACAPの上のOTASP。
[Figure 5 -- see PostScript version]
[図5--ポストスクリプトバージョンを見ます]
Gellens Informational [Page 23] RFC 2636 OTASP/OTAPA via ACAP July 1999
ACAP1999年7月を通したGellens Informational[23ページ]RFC2636OTASP/OTAPA
7. IS-683A Compatibility
7. -、683A、互換性
7.1. OTASP Operations
7.1. OTASP操作
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.
互換性を最大にして、再利用を考慮する、-、683A、受話器コード、ACAPの上のOTASPで使用されるデータ形式が中で使用されたものと同じである、-、683A セクション5.1 .5 Data OrganizationとCapabilitiesはさらに詳細にこれについて議論します。
OTASP via IS-683A requires custom design and development for the
specific CDMA infrastructure used by a carrier. This can greatly
limit the data management capabilities and significantly reduces the
extensibility of the solution. Conversely, OTASP over data can be
implemented on a generic IP network using an Internet standards-
based capability that provides extensible provisioning activities
for carriers.
を通してOTASP、-、683A、キャリヤーによって使用された特定のCDMAインフラストラクチャのためのカスタムデザインと開発を必要とします。 これは、データ管理能力を大いに制限できて、ソリューションの伸展性をかなり減少させます。 逆に、ジェネリックIPネットワークで広げることができる食糧を供給する活動をキャリヤーに供給するインターネット規格に基づいている能力を使用することでデータの上のOTASPを実装することができます。
OTASP over data uses a traffic channel whereas IS-683A OTASP runs
over the limited-bandwidth signaling channel.
ところが、データの上のOTASPがトラフィックチャンネルを使用する、-、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.
-、683A OTASP、操作は、本来の同時の声とデータです。 これで、顧客ケア代表はユーザと話している間、移動局から情報を抜粋できます。 データサービスの上のOTASPはデータだけ解決(少なくとも当分)です。 これで、OTASP操作はわずかに連続して潜在的に問題が多くなります。 同時の声とデータはこの問題を軽減するでしょう。
7.2 OTASP Call Flow
7.2 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)が典型的にaのためのメッセージ系列と操作について表現する、-、683A OTASP、(食糧を供給します) 電話をしてください。 どんなデータ-OTASPソリューションもすべての機能を実行しなければならない、-、683A OTASP、電話をしてください。 提案されたソリューションはこれらの必要条件を満たします。
[Figure 6 -- see PostScript version]
[図6--ポストスクリプトバージョンを見ます]
7.3. OTAPA Operations
7.3. OTAPA操作
Data-OTAPA requires the ability to instruct mobiles to originate a
data call to the provisioning server. Several viable approaches are
discussed in sections 3.3 OTAPA Activity and 4.3 OTAPA
Requirements.
データ-OTAPAは食糧を供給するサーバにデータ呼び出しを溯源するようモバイルに命令する能力を必要とします。セクション3.3OTAPA Activityと4.3OTAPA 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を使用することで移動局にダウンロードされる必要があります。
Gellens Informational [Page 24] RFC 2636 OTASP/OTAPA via ACAP July 1999
ACAP1999年7月を通したGellens Informational[24ページ]RFC2636OTASP/OTAPA
7.4. OTAPA Call Flow
7.4. 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)がメッセージ系列について表現する、a典型的である、-、683A OTAPA、操作 どんなデータ-OTAPAソリューションもすべての機能を実行しなければならない、-、683A OTAPA、電話をしてください。 提案されたソリューションはこれらの必要条件を満たします。
[Figure 7 -- see PostScript version]
[図7--ポストスクリプトバージョンを見ます]
8. Alternative Methods
8. 別法
8.1. IS-683A over TCP/IP
8.1. -、683A、TCP/IP
One alternative is to port IS-683A to TCP, remaining as close as
possible to the IS-683A protocol exchange.
ポートには1つの選択肢がある、-、683A、できるだけ近くに残っているTCP、-、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.
を通してエイト環がOTASP/OTAPAをサポートするためにアーキテクチャとコミュニケーションバックボーンについて表現する、-707である、ベースの食糧を供給するサーバがオンのデータサービス、-、683A OTAF、機能。
[Figure 8 -- see PostScript version]
[エイト環--ポストスクリプトバージョンを見ます]
8.1.1. OTAF Server
8.1.1. OTAFサーバ
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.
この食糧を供給するサーバが倣われる、-、683A OTAF OTAFサーバが特定の操作とメッセージングを実行する、存在、683A OTAF。 これはA主要な再認証手順を含んでいます。
Strongpoints:
防御拠点:
(1) OTAF and mobile station behavior mirrors IS-683A (reduced
duplicate software in mobile station). Nearly all procedures fully
defined.
(1)OTAFと移動局の振舞いが映す、-、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) まだ完全なセキュリティに必要である終端間暗号化体系。
Gellens Informational [Page 25] RFC 2636 OTASP/OTAPA via ACAP July 1999
ACAP1999年7月を通したGellens Informational[25ページ]RFC2636OTASP/OTAPA
8.1.2. Interface Application
8.1.2. インタフェースアプリケーション
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サーバまですべての必要な食糧を供給する関連の情報をロードします。これはトランザクションとデータに食糧を供給することの列を作りを含んでいます。
8.1.3. Protocol Handset Suite
8.1.3. プロトコル受話器スイート
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が移動局プロトコル群について表現する、-、683A、TCP/IP解決の上で。 OTASPクライアントが両方をサポートすることができる、-、683A OTASP、データ伝送の上の活動かOTASP活動。
[Figure 9 -- see PostScript version]
[図9--ポストスクリプトバージョンを見ます]
8.2. Browser-Based Forms
8.2. ブラウザベースのフォーム
Another alternative is to use forms embedded in web pages.
別の代替手段はウェブページに埋め込まれたフォームを使用することです。
Encapsulating the provisioning data into custom tags embedded in a
web form is an idea that at first seems attractive. There are a lot
of advantages in having a browser in the handset, web servers are
very widely deployed, and everyone is familiar on some level with
the web.
ウェブフォームに埋め込まれたカスタムタグへのデータを食糧を供給するのにカプセル化するのは、初めに魅力的に見える考えです。 ブラウザが受話器にあるのにおいて多くの利点があります、そして、ウェブサーバーは非常に広く配布されます、そして、皆は何らかのレベルでウェブに詳しいです。
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.
ウェブもまた、機能上異なっているので、高いレベルのキャリヤーサイド改造が必要でしょう、減少しているベンダー選択と増強された展開コストに通じて。
Gellens Informational [Page 26] RFC 2636 OTASP/OTAPA via ACAP July 1999
ACAP1999年7月を通したGellens Informational[26ページ]RFC2636OTASP/OTAPA
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が非常に簡単なプロトコルであるので、わずかの費用でさまざまなアプリケーションにそれを追加できます。 これで、モバイル機器における増加する数のアプリケーションがデスクトップアプリケーションと同様にサーバと情報を共有できます。
9. Conclusion
9. 結論
ACAP provides a high degree of extensibility, especially in
authentication mechanisms, custom attribute handling, and data
management. By using an Internet standard protocol,
interoperability and integration with a variety of equipment is
possible, and carriers are not locked into any vendor. It is also
easier to add new levels of service and capabilities, especially
integration with future subscriber devices and applications (e.g.,
email).
ACAPは特に認証機構、カスタム属性取り扱い、およびデータ管理に高度合いの伸展性を供給します。 インターネットを使用することによって、さまざまな設備による標準プロトコル、相互運用性、および統合は可能です、そして、キャリヤーはどんなベンダーにもロックされません。 また、将来の加入者デバイスとアプリケーションによる新しいレベルのサービスと能力、特に統合を加えるのも、より簡単です(例えば、メールしてください)。
Since an ACAP client is so small, it can be incorporated into
virtually any device, even low-end ones without displays, and can be
added without sacrificing other features. The simplicity of the
client and protocol directly translate to shorter development cycles
and faster time-to-market.
ACAPクライアントが非常に小さいので、他の特徴を犠牲にしないで、それをディスプレイなしで実際にはどんなデバイス、ローエンドものにさえも組み入れることができて、加えることができます。 クライアントとプロトコルの簡単さは、より短い開発サイクルと売り出すより速い時間まで直接翻訳されます。
Because the ACAP protocol was designed for precisely this type of
provisioning activity, its adoption can greatly reduce the cost,
time to market, and support required for the provisioning server as
well as the handsets. As an open standard, the ACAP protocol has
benefited from years of review and experience.
ACAPプロトコルが正確に活動に食糧を供給するこのタイプのために設計されたので、採用はコスト、売り出す時間、および受話器と同様に食糧を供給するサーバに必要であるサポートを大いに削減できます。 オープンスタンダードとして、ACAPプロトコルは何年ものレビューと経験の利益を得ました。
Another advantage of the ACAP solution is that is can easily coexist
with a WAP-based mechanism, giving carriers more options and
reducing the minimal requirement burden on mobile devices.
ACAPソリューションの別の利点はそうです、すなわち、容易にWAPベースのメカニズムと共存できます、より多くのオプションをキャリヤーに与えて、モバイル機器で最小量の要件負担を変えて。
A carrier can deploy handsets into its service area which use WAP-
based provisioning, if desired, alongside those which use ACAP
provisioning. By using an ACAP server for provisioning, carriers
are free to simultaneously deploy mobile stations that use either
WAP or ACAP, as desired.
キャリヤーはサービスエリアへのWAPのベースの食糧を供給することを使用する受話器を配布することができます、望まれているなら、ACAPの食糧を供給することを使用するものと並んで。 食糧を供給するのにACAPサーバを使用することによって、キャリヤーは同時に無料でWAPかACAPのどちらかを使用する移動局を配布することができます、望まれているように。
The lack of intellectual-property issues further adds to ACAP's
appeal.
知的所有権問題の不足はさらにACAPの上告の一助となります。
Gellens Informational [Page 27] RFC 2636 OTASP/OTAPA via ACAP July 1999
ACAP1999年7月を通したGellens Informational[27ページ]RFC2636OTASP/OTAPA
10. References
10. 参照
[ACAP] Newman, C. and J. Myers, "ACAP -- Application
Configuration Access Protocol", RFC 2244, November 1997.
[ACAP] ニューマン、C.、およびJ.マイアーズ、「ACAP--アプリケーション構成アクセスは議定書を作る」、RFC2244、11月1997日
[CRAM-MD5] Klensin, J., Catoe, R. and P. Krumviede, "IMAP/POP
AUTHorize Extension for Simple Challenge/Response", RFC
2195, September 1997.
[一夜漬け-MD5] KlensinとJ.とCatoeとR.とP.Krumviede、「/が飛び出させるIMAPは簡単な挑戦/応答のための拡大を認可する」RFC2195、1997年9月。
[SASL] Myers, J., "Simple Authentication and Security Layer
(SASL)", RFC 2222, October 1997.
[SASL] マイアーズ、J.、「簡易認証とセキュリティは(SASL)を層にする」RFC2222、1997年10月。
11. Security Considerations
11. セキュリティ問題
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.
このドキュメントの多くのセクションでセキュリティについて議論します。 特に、必要性と受話器の権限のないアップデートに用心するメソッド(新たに作成されたアカウントの強奪)は受話器セキュリティ値で妥協します、そして、キャリヤーの独占データと受話器パラメタの公開はカバーされています。
12. Acknowledgments
12. 承認
Jim Willkie and Marc Phillips contributed greatly to this document. Their help is very much appreciated.
ジム・ウィルキーとマークフィリップスはこのドキュメントに大いに貢献しました。 彼らの助けにたいへん感謝します。
13. Author's Address
13. 作者のアドレス
Randall Gellens QUALCOMM Incorporated 6455 Lusk Boulevard San Diego, CA 92121-2779
ランドル・Gellensのクアルコムの法人組織の6455ラスク・Boulevardサンディエゴ、カリフォルニア92121-2779
Phone: +1 619 651 5115 EMail: randy@qualcomm.com
以下に電話をしてください。 +1 5115年の619 651メール: randy@qualcomm.com
Gellens Informational [Page 28] RFC 2636 OTASP/OTAPA via ACAP July 1999
ACAP1999年7月を通したGellens Informational[28ページ]RFC2636OTASP/OTAPA
14. Full Copyright Statement
14. 完全な著作権宣言文
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright(C)インターネット協会(1999)。 All rights reserved。
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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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機能のための基金は現在、インターネット協会によって提供されます。
Gellens Informational [Page 29]
Gellens情報です。[29ページ]
一覧
スポンサーリンク
