JP4703657B2 - ネットワーク探索方法 - Google Patents

Description

本願は、特に、セキュアな高速ハンドオフなどのためのネットワーク探索機構の方法などを含む、ネットワーク探索機構の方法に関する。本願は、１）２００４年１１月５日に出願された、「セキュアな高速ハンドオフのためのネットワーク探索機構（Network Discovery Mechanism For Secure Fast Handoff）」という名称の米国仮特許出願第６０／６２５，１０６号明細書、２）２００５年１月９日に出願された、「ネットワーク探索機構（Network Discovery Mechanisms）」という名称の米国仮特許出願第６０／５９３，３７７号明細書、３）２００５年４月１３日に出願された、「ネットワーク探索機構（Network Discovery Mechanisms）」という名称の米国仮特許出願第６０／６７０，６５５号明細書、および４）２００５年７月１１日に出願された、「８０２．１基本文書のためのＲＤＦスキーマ更新（RDF Schema Update for 802.1 Baseline Document）」という名称の米国仮特許出願第６０／６９７，５８９号明細書のそれぞれの、米国特許法第１１９条による優先権を主張するものであり、優先権を主張する以上４つの仮特許出願のそれぞれの開示全体を、本明細書に組み込むものである。加えて、本願譲受人の同時係属の特許出願である、２００４年１月２２日に出願された、「事前認証、事前構成および／または仮想ソフトハンドオフを使ったモビリティアーキテクチャ（Mobility Architecture Using Pre-Authentication, Pre-Configuration and/or Virtual Soft-Handoff）」という名称の米国特許出願第１０／７６１，２４３号明細書の開示全体も、背景として、参照により本明細書に組み込むものである。

ネットワークおよびインターネット（登録商標）プロトコル
多様なコンピュータネットワークがあり、中でも代表的なのがインターネットである。インターネットは、コンピュータネットワークの世界規模のネットワークである。今日、インターネットは、何百万人ものユーザが利用可能な、公共の自己持続的ネットワークである。インターネットは、ＴＣＰ／ＩＰ（すなわち、伝送制御プロトコル／インターネットプロトコル）と呼ばれる１組の通信プロトコルを使って各ホストを接続する。インターネットは、インターネットバックボーンと呼ばれる通信インフラストラクチャを有する。インターネットバックボーンへの接続の大部分は、企業および個人に接続を再販するインターネットサービスプロバイダ（ＩＳＰ）によって制御される。

ＩＰ（インターネットプロトコル）に関して、これは、ネットワーク上である機器（例えば、電話機、ＰＤＡ［携帯情報端末］、コンピュータなど）から別の機器にデータを送るためのプロトコルである。今日、ＩＰｖ４、ＩＰｖ６などを含めて、様々なバージョンのＩＰがある。ネットワーク上の各ホスト機器は、各機器の独自の一意の識別子である、少なくとも１つのＩＰアドレスを有する。ＩＰは、コネクションレス型プロトコルである。通信時の端点間接続は連続的ではない。ユーザがデータまたはメッセージを送信し、または受信するとき、データまたはメッセージは、パケットと呼ばれる構成要素に分割される。あらゆるパケットは、独立のデータ単位として扱われる。

インターネットなどのネットワークを介した各点間の伝送を標準化するために、ＯＳＩ（開放型システム間相互接続）モデルが確立された。ＯＳＩモデルは、ネットワーク内の２点間の通信プロセスを７つの階層に分け、各層は独自の機能セットを付加する。各機器は、送信側端点では各層を通る下方への流れがあり、受信側端点では各層を通る上方への流れがあるようにメッセージを処理する。７つの機能層を提供するプログラミングおよび／またはハードウェアは、通常、デバイスオペレーティングシステムと、アプリケーションソフトウェアと、ＴＣＰ／ＩＰおよび／または他のトランスポートおよびネットワークプロトコルと、その他のソフトウェアおよびハードウェアとの組み合わせである。

通常、上位４層は、メッセージがユーザから、またはユーザに渡されるときに使用され、下位３層は、メッセージが機器（ＩＰホスト機器など）を通過するときに使用される。ＩＰホストは、サーバ、ルータ、ワークステーションなど、ＩＰパケットを送受信することのできるネットワーク上の任意の機器である。他の何らかのホストに向けられているメッセージは、各上位層には渡されず、この他のホストに転送される。以下に、ＯＳＩモデルの各層を列記する。第７層（すなわち、アプリケーション層）は、例えば、通信相手が識別され、サービス品質が識別され、ユーザ認証およびプライバシが考慮され、データ構文に対する制約条件が識別される層である。第６層（すなわち、プレゼンテーション層）は、例えば、着信および発信データをあるプレゼンテーション形式から別の形式に変換する層である。第５層（すなわち、セッション層）は、例えば、アプリケーション間の会話、交換およびダイアログをセットアップし、調整し、終了させる層である。第４層（すなわち、トランスポート層）は、例えば、エンドツーエンド制御および誤りチェックなどを管理する層である。第３層（すなわち、ネットワーク層）は、例えば、経路指定や転送などを処理する層である。第２層（すなわち、データリンク層）は、例えば、物理レベルでの同期を提供し、ビットスタッフィングを行い、伝送プロトコルの知識および管理などを提供する層である。米国電気電子技術者協会（ＩＥＥＥ）では、データリンク層を、物理層との間のデータ転送を制御するＭＡＣ（媒体アクセス制御）層と、ネットワーク層とのインターフェースを取り、コマンドを解釈し、誤り回復を行うＬＬＣ（論理リンク制御）層という、２つのさらなる副層に細分している。第１層（すなわち、物理層）は、例えば、物理レベルでネットワークを介してビットストリームを伝達する層である。ＩＥＥＥでは、物理層を、ＰＬＣＰ（物理層収束手順）副層とＰＭＤ（物理媒体依存）副層とに細分している。

無線ネットワーク
無線ネットワークは、例えば、セルラおよび無線電話機、ＰＣ（パーソナルコンピュータ）、ラップトップコンピュータ、装着型コンピュータ、コードレス電話機、ページャ、ヘッドセット、プリンタ、ＰＤＡなど、多種多様なモバイル機器を組み込むことができる。例えば、モバイル機器には、音声および／またはデータの高速無線伝送を確保するディジタルシステムが含まれ得る。典型的なモバイル機器は、送受信機（すなわち、例えば、送信機、受信機および、必要に応じて、他の機能が統合されたシングルチップ送受信機などを含む、送信機および受信機）、アンテナ、プロセッサ、１つ以上の音声変換器（例えば、音声通信用機器でのスピーカやマイクロホンなど）、電磁データ記憶（データ処理が提供される機器の場合などでの、ＲＯＭ、ＲＡＭ、ディジタルデータ記憶など）、メモリ、フラッシュメモリ、フルチップセットまたは集積回路、インターフェース（ＵＳＢ、ＣＯＤＥＣ、ＵＡＲＴ、ＰＣＭなど）といった構成要素の一部または全部を含む。

モバイルユーザが無線接続を介してローカルエリアネットワーク（ＬＡＮ）に接続することのできる無線ＬＡＮ（ＷＬＡＮ）が、無線通信に用いられてもよい。無線通信には、例えば、光、赤外線、電波、マイクロ波などの電磁波を介して伝搬する通信などが含まれ得る。今あるＷＬＡＮ規格には、ブルートゥース（登録商標）、ＩＥＥＥ８０２．１１、ＨｏｍｅＲＦなど、様々なものがある。

例えば、ブルートゥース製品は、モバイルコンピュータ、モバイル電話機、携帯式ハンドヘルド機器、携帯情報端末（ＰＤＡ）、ならびに他のモバイル機器およびインターネットへの接続を提供するのに使用され得る。ブルートゥースは、モバイル機器が、短距離無線接続を使って、相互に、また非モバイル機器と、どのようにして容易に相互接続し合うことができるかを明示するコンピュータおよび電気通信業界仕様である。ブルートゥースは、ある機器と別の機器との間でデータの同期と整合性を保ち続けることを必要とする様々なモバイル機器の普及から生じるエンドユーザ問題に対処して、異なるベンダからの装置が相互にシームレスに動作することを可能にするディジタル無線プロトコルを作成する。ブルートゥース機器は、共通の命名概念に従って命名できる。例えば、ブルートゥース機器は、ブルートゥース機器名（ＢＤＮ）または一意のブルートゥース機器アドレス（ＢＤＡ）に関連付けられた名称を持ち得る。また、ブルートゥース機器は、インターネットプロトコル（ＩＰ）ネットワークに参加することもできる。ブルートゥース機器がＩＰネットワーク上で機能する場合、この機器には、ＩＰアドレスおよびＩＰ（ネットワーク）名を与えることができる。よって、ＩＰネットワークに参加するように構成されたブルートゥース機器は、ＢＤＮ、ＢＤＡ、ＩＰアドレスおよびＩＰ名などを含むことができる。「ＩＰ名」という用語は、インターフェースのＩＰアドレスに対応する名称を指すものである。

ＩＥＥＥ規格であるＩＥＥＥ８０２．１１は、無線ＬＡＮおよび機器の技術の仕様を定める。８０２．１１を使えば、各単一基地局がいくつかの機器をサポートする無線ネットワークが実現できる。場合によって、機器に無線ハードウェアが事前装備されていることもあり、ユーザが、アンテナを含むことができる、カードなどの別個のハードウェアをインストールしてもよい。例えば、８０２．１１で使用される機器は、通常、機器がアクセスポイント（ＡＰ）であれ、移動局（ＳＴＡ）であれ、ブリッジであれ、ＰＣＭＣＩＡカードであれ、あるいは別の機器であれ、無線送受信機、アンテナ、およびネットワークにおける各点間のパケットの流れを制御するＭＡＣ（媒体アクセス制御）層という３つの注目すべき要素を含む。

加えて、いくつかの無線ネットワークでは、複数インターフェース機器（ＭＩＤ）も利用できる。ＭＩＤは、ブルートゥースインターフェースと８０２．１１インターフェースなど、２つの独立のネットワークインターフェースを含んでいてもよく、よって、ＭＩＤが２つの別個のネットワーク上に参加すると同時に、ブルートゥース機器ともインターフェースすることが可能になる。ＭＩＤは、ＩＰアドレスと、ＩＰアドレスに関連付けられた共通ＩＰ（ネットワーク）名を有することができる。

無線ネットワーク機器には、それだけに限らないが、ブルートゥース機器、複数インターフェース機器（ＭＩＤ）、８０２．１１ｘ機器（８０２．１１ａ、８０２．１１ｂ、８０２．１１ｇ機器などを含む、ＩＥＥＥ８０２．１１機器）、ＨｏｍｅＲＦ（家庭内無線周波数）機器、Ｗｉ-Ｆｉ（Wireless Fidelity）機器、ＧＰＲＳ（汎用パケット無線システム）機器、３Ｇセルラ機器、２．５Ｇセルラ機器、ＧＳＭ（移動通信用グローバルシステム）機器、ＥＤＧＥ（Enhanced Data for GSM Evolution）機器、ＴＤＭＡ型（時分割多重接続）機器、またはＣＤＭＡ２０００を含むＣＤＭＡ型（符号分割多重接続）機器が含まれ得る。各ネットワーク機器は、それだけに限らないが、ＩＰアドレス、ブルートゥース機器アドレス、ブルートゥース共通名、ブルートゥースＩＰアドレス、ブルートゥースＩＰ共通名、８０２．１１ＩＰアドレス、８０２．１１ＩＰ共通名、ＩＥＥＥ ＭＡＣアドレスを含む、様々な種類のアドレスを含んでいてもよい。

また、無線ネットワークには、例えば、モバイルＩＰ（インターネットプロトコル）システム、ＰＣＳシステム、および他のモバイルネットワークシステムにおいて見られる方法およびプロトコルも関与し得る。モバイルＩＰに関して、これには、インターネット技術標準化委員会（ＩＥＴＦ）によって作成された標準通信プロトコルが関与する。モバイルＩＰでは、モバイル機器ユーザは、各ユーザに一旦割り当てられたＩＰアドレスを維持しつつ、各ネットワークにまたがって移動することができる。コメント要求（ＲＦＣ）３３４４を参照されたい。（注：ＲＦＣはインターネット技術標準化委員会（ＩＥＴＦ）の公式文書である。）モバイルＩＰは、インターネットプロトコル（ＩＰ）を拡張し、モバイル機器のホームネットワーク外部に接続するときに、モバイル機器にインターネットトラフィックを転送する手段を付加する。モバイルＩＰは、各モバイルノードに、モバイルノードのホームネットワーク上のホームアドレスと、ネットワークおよびネットワークのサブネット内における機器の現在位置を識別する気付アドレス（ＣｏＡ）とを割り当てる。機器が異なるネットワークに移動すると、機器は、新しい気付アドレスを受け取る。ホームネットワーク上のモビリティエージェントは、各ホームアドレスを、これの気付アドレスと関連付けることができる。モバイルノードは、インターネット制御メッセージプロトコル（ＩＣＭＰ）などを使って、モバイルノードが気付アドレスを変更する都度、ホームエージェントにバインディング更新を送ることができる。

基本的なＩＰ経路指定(ルーティング)では（例えば、モバイルＩＰ外部では）、経路指定機構は、各ネットワークノードが、常に、インターネットなどへの一定の接続点を有し、かつ各ノードのＩＰアドレスが、各ノードが接続されているネットワークリンクを識別するという想定に依拠している。本明細書において、「ノード」という用語は、例えば、データ伝送のための再配信点や端点などを含むことができ、他のノードへの通信を認識し、処理し、かつ／または転送することのできる接続点を含む。例えば、インターネットルータは、機器のネットワークを識別するＩＰアドレスプレフィックスなどを調べることができる。次いで、ネットワークレベルにおいて、ルータは、特定のサブネットを識別するビットセットなどを調べることができる。次いで、サブネットレベルにおいて、ルータは、特定の機器を識別するビットセットなどを調べることができる。典型的なモバイルＩＰ通信の場合、ユーザが、例えば、インターネットなどからモバイル機器を切断し、これを新しいサブネットで再接続しようとする場合、機器は、新しいＩＰアドレス、適正なネットマスクおよびデフォルトのルータを用いて再構成される必要がある。そうでなければ、経路指定プロトコルは、パケットを適正に配信することができないはずである。

好ましい実施形態は、参照によりそれぞれが全体として本明細書に組み込まれる、以下の参照文献に記載されている技術を改善するものである。

* [1] Sun Microsystems, .Jini Connection Technology,. http://www.sun.com/ jinni.
* [2] Sun Microsystems, .Jini Community Resources: Jini Technology Architectural Overview,. January 1999. http://www.sun.com/jini /whitepapers/architecture.html.
* [3] Sun Microsystems, .Jini Community Resources: Jini Specification v1.0.1,. www.sun.com/jini/specs.
* [4] W. Keith Edwards, Core JINI, The Sun Microsystems Press Java (登録商標) Series, Prentice Hall, 1999.
* [5] Microsoft Corporation, .Universal Plug and Play: Background, http://www.upnp.org/resources/UpnPbkgnd.htm.
* [6] Microsoft Corporation, .Universal Plug and Play Device Architecture Version 1.0,. June 8, 2000. http://www.upnp.org/UpnPDevice_ Architecture_1.0.htm.
* [7] Yaron Y. Goland, Ting Cai, Paul Leach, Ye Gu, and Shivaun Albright, .Simple Service Discovery Protocol,. IETF Draft draft-cai-ssdp-v1-03.txt, October 28, 1999. http://www.ietf.org/internetdrafts/draft-cai-ssdp-v1-03.txt.
* [8] Salutation Consortium, .Salutation Architecture Specification Version 2.0c . Part 1,. The Salutation Consortium, June 1, 1999. http://www.salutation.org.
* [9] Salutation Consortium, .Salutation Architecture Specification Version 2.0c . Part 2,. The Salutation Consorium, June 1, 1999. http://www.salutation.org.
* [10] Bob Pascoe, .Salutation-Lite: Find-and-Bind Technologies for Mobile Devices,. Salutation.
* Consortium, June 6, 1999. http://www.salutation.org/whitepaper/Sal-Lite.PDF.
* [11] Brent Miller, .Mapping Salutation Architecture APIs to Bluetooth (登録商標) Service Discovery Layer. Bluetooth Consortium 1.C.118/1.0, July 1, 1999.
* [12] Bob Pascoe, .Salutation Architectures and the newly defined service discovery protocols from Microsoft and Sun, Salutation Consortium, June 6, 1999. http://www.salutation.org/whitepaper/Jini-UPnP.PDF.
* [13] Ryan Troll, .Automatically Choosing an IP Address in an Ad-Hoc IPv4 Network,. IETF Draft draftietf-dhc-ipv4-autoconfig-05.txt, March 2, 2000. http://www.ietf.org/internet-drafts/draft-ietf-dhcipv4-autoconfig-05.txt.
* [14] Bluetooth Consortium, .Specification of the Bluetooth System Core Version 1.0 B: Part E, Service Discovery Protocol (SDP), Nov 29, 1999. http://www.bluetooth.com/developer/specification/specification.asp.
* [15] Bluetooth Consortium, .Specification of the Bluetooth System Profiles Version 1.0 B: Part K:2, Service Discovery Application Profile,. Dec 1, 1999. http://www.bluetooth.com/developer/specification/specification.asp.
* [16] IETF SVRLOC Working Group, .Service Location Protocol Home Page,. http://www.srvloc.org.
* [17] E. Guttman, C. Perkins, J. Veizades, and M. Day, .Service Location Protocol, Version 2,. IETF RFC 2608, June 1999. http://www.ietf.org/rfc/rfc2608.txt.
* [18] E. Guttman, C. Perkins, and J. Kempf, .Service Templates and Service: Schemes,. IETF RFC 2609, June 1999. http://www.ietf.org/rfc/rfc2609.txt.
* [19] Rekesh John, .UPnP, Jini and Salutation . A look at some popular coordination frameworks for future networked devices, California Software Labs, June 17, 1999. http://www.cswl.com/whiteppr/tech/ upnp.html.
* [20] IETF ZEROCONF Working Group, .Zero Configuration Networking (zeroconf), http://www.ietf.org/html.charters/zeroconf-charter.html.
* [21] INS: Intentional Naming System, http://wind.lcs.mit.edu/projects/ins.
* [22] The Berkeley Service Discovery Service, http://www.cs.berkeley.edu/ ~caerwin/sds-project.html.
* [23] R. Droms, .Dynamic Host Configuration Protocol,. IETF RFC 2131, March 1997. http://www.ietf.org/rfc/rfc2131.txt.
* [24] Sun Microsystems, .Java 2 Platform Midcro Edition (J2ME) Technology for Creating Mobile Devices, White Paper, May 19, 2000. http://java.sun.com/products/cldc/wp/KVMwp.pdf.
* [25] World Wide Web Consortium, .Extensible Markup Language (XML)., http://www.w3.org/XML.
* [26] Marco Liebsch and Ajoy Singh (editors), “Candidate Access Router Discovery”, Internet Draft draft-ietf-seamoby-card-protocol-06.txt, Internet Engineering Task Force, June 2004.
* [27] J. Hodges and R. Morgan, “Lightweight Directory Access Protocol (v3): Technical Specification”, IETF RFC 3377, September 2002.
* [28] M. Liebsch, A. Singh, H. Chaskar, D. Funato and E. Shim, "Candidate Access Router Discovery," Internet-Draft, work in progress, June 2004.
* [29] K. Arabshian and H. Schulzrinne, "GloServ: Global Service Discovery Architecture," First International Conference on Mobile and Ubiquitous Systems: Networking and Services.

本発明は、上記および／または他の背景技術および／または背景技術における問題を改善するものである。

好ましい実施形態のいくつかによれば、例えば、同種または異種混交のアクセスネットワーク間でのリアルタイムのセキュアなローミング／ハンドオフにおける遅延および一時的データ喪失を低減するために、セキュアな事前認証などの事前対応型ハンドオフ機構が使用され得る。事前認証には、例えば、モバイルがネットワークに移動する前にネットワークと認証を行うことが伴う。目標近隣ネットワークとセキュアな事前認証を達成するために、モバイルは、まだ目標ネットワーク外部にあるときに、目標ネットワークからＩＰアドレスなどの情報を獲得し、次いで、例えば、目標ネットワーク内の認証エージェント（ＰＡＮＡ認証エージェントなど）とセキュリティアソシエーションを確立する必要がある。このために、モバイルは、前もって目標ネットワーク内の様々なネットワーク要素のパラメータを探索し、モバイルが、これらのネットワーク要素とやりとりして、事前対応型のセキュリティアソシエーションを確立することができるようにする必要がある。本明細書では、特に、モバイルが、目標ネットワークに移動する前に、目標ネットワーク内のネットワーク要素を探索するいくつかの手法について述べる。また、本明細書では、特に、ネットワーク探索が、どのようにして、セキュアな事前認証と事前対応型ＩＰアドレス獲得を使った高速ハンドオフを実現するのに役立ち得るかについて述べる。

いくつかの実施形態によれば、ＩＰネットワーク内の複数のアクセスネットワークの少なくとも１つを使用するモバイル機器のネットワーク探索の方法は、モバイルが任意の場所からＩＰネットワークに接続されるときに、１組の基準に基づき、所与の場所の近傍において指定のネットワーク情報を獲得することを含む。

いくつかの例では、ネットワーク情報は、モバイルによってアクセスネットワークにアクセスするのに使用される情報を含む。いくつかの例では、この情報は、アクセスポイントのネットワーク接続点識別を含む。いくつかの例では、この情報は、アクセスポイントによってサポートされるセキュリティの種類を含む。いくつかの例では、この情報は、第３層の種類を含む。いくつかの例では、この情報は、プロバイダ名を含む。いくつかの例では、この情報は、サーバまたはエージェントのアドレスを含む。いくつかの例では、この情報は、認証エージェントのアドレスを含む。いくつかの例では、この情報は、アクセスルータのアドレスを含む。

いくつかの実施形態によれば、モバイル機器による目標ネットワークのネットワーク情報の探索の方法は、ａ）ネットワーク情報の少なくとも１つの探索データベースを動的に構築することと、ｂ）少なくとも１つの探索データベースを使って、モバイル機器が目標ネットワークに接続される前に、目標ネットワークに関するネットワーク情報を提供することとを含む。

いくつかの例では、方法は、情報サービスのためのアプリケーション層機構（ＡＩＳ）を用いる。いくつかの例では、この方法は、モバイル機器によりハンドオフと事前認証のために使用される情報を探索するのに使用される。いくつかの例では、この方法は、第２層から独立したＡＩＳを用いる。いくつかの例では、この方法は、ネットワーク支援型探索機構を使用する。いくつかの例では、この方法は、モバイル支援型探索機構を使用する。いくつかの例では、この方法は、ネットワーク支援型機構を使ってデータベースを構築する。いくつかの例では、この方法は、モバイル支援型機構を使ってデータベースを構築する。いくつかの例では、モバイルは、ＡＩＳサーバまたはピアモバイルに問合せして、目標ネットワーク内のネットワーキング要素に関する情報を獲得する。いくつかの例では、この方法は、報告エージェント（ＲＡ）を使って情報を獲得することをさらに含む。いくつかの例では、この方法は、ＡＡＡサーバを使って情報を獲得することをさらに含む。いくつかの例では、この方法は、ＤＮＳサーバを使って情報を獲得することをさらに含む。いくつかの例では、この方法は、モバイル機器が情報サーバとして働くピアツーピア型モデルを用いる。いくつかの例では、この方法は、設定範囲マルチキャスト手法を用いる。いくつかの例では、この方法は、再帰的ブロードキャスト手法を用いる。

様々な実施形態の上記および／または他の態様、特徴、および／または利点は、以下の説明を添付の図と併せて考察すればさらに理解されるであろう。様々な実施形態は、該当する場合には、異なる態様、特徴、および／または利点を含み、かつ／または除外することができる。加えて、様々な実施形態は、該当する場合には、他の実施形態の１つまたは複数の態様または特徴を組み合わせることもできる。個々の実施形態の態様、特徴および／または利点の説明は、他の実施形態または特許請求の範囲を限定するものと解釈されるべきではない。

本発明の好ましい実施形態を、限定としてではなく例として、添付の図に示す。

本発明は、多くの異なる形で実施できるが、本明細書では、本開示は本発明の原理の例を提供するものとみなされるべきであり、かかる例は、本発明を、本明細書で説明し、かつ／または図示する好ましい実施形態だけに限定するためのものではないという了解の下で、いくつかの説明的実施形態について述べる。

３ 概要
無線ＬＡＮ（ローカルエリアネットワーク）とセルラ技術に基づく無線ネットワーキングの発展の中、モビリティサービスが普及し、人々がますますモバイルを使用するようになるにつれて、モバイル機器が、時宜を得た、正確で効率のよいやり方で、アプリケーション要件とモバイルの特性を満たす、適切なネットワーク接続点を探し出すことができることがより重要になっている。かかる機能をネットワーク探索と呼ぶ。

本明細書で論じるネットワーク探索問題は、モバイルが任意の場所からＩＰネットワークに接続されるときに、１組の基準に基づき、所与の場所の近傍において指定のネットワーク情報を獲得することとして定式化される。ここで、
ネットワーク情報は、モバイルがネットワークにアクセスするのに使用する任意の情報とすることができる。かかる情報には、例えば、ネットワーク接続点識別（Ｌ２アドレスおよび／またはアクセスポイントの地理的アドレスなど）、アクセスポイントのＭＡＣの種類（「ＩＥＥＥ８０２．１１ｇ」など）、アクセスポイントによってサポートされるセキュリティの種類（「ＷＰＡ」や「ＰＡＮＡおよびＩＰｓｅｃ」など）、第３層の種類（「ＩＰｖ４のみ」や「ＩＰｖ４／ｖ６デュアルスタック」など）、プロバイダ名、あるいはサーバまたはエージェント（ＰＡＮＡ認証エージェント、アクセスルータ、ＳＩＰサーバおよびモバイルＩＰホームエージェントなど）のアドレスが含まれる。

モバイルの場所またはモバイルがこれに関する情報を探し出そうとする場所は、様々なやり方で識別（表現）できる。例えば、これは、地理的位置によって、ネットワークの識別によって、あるいはネットワーク内の無線アクセスポイントまたはＩＰアクセスルータのアドレスによって識別できる。

ネットワーク情報を探索する機能を使えば、モビリティおよびモバイルサービスがより適切にサポートできる。例えば、ハンドオフ時の実行中のアプリケーションセッションの中断を低減するために、モバイル機器は、目標ネットワークへのハンドオフを開始する前に、目標ネットワークと事前認証を行うことができる。このためには、モバイルは、モバイルが目標ネットワークに移動する前に、目標ネットワーク内の認証サーバのアドレスなど、近隣ネットワークに関する情報を必要とする。モバイルがこれの近隣ネットワークに関する情報を探索するプロセスを、ネットワーク近隣探索と呼ぶ。

ネットワーク探索における重要な問題が、探索データベース構築問題、すなわち、ネットワーク情報のデータベースを、自動化された、動的で効率のよいやり方でどのように構築すべきかである。この問題を解決することは、ネットワークプロバイダが、このプロバイダの加入者には、よりよいサービスのために独自のネットワークの詳細なネットワーク情報を提供できるが、このプロバイダと競合する他のネットワークプロバイダには、独自のネットワークのどんなネットワーク情報も進んで開示しようとしないことのある、複数プロバイダの環境においては、些細な問題とは言えない。しかしながら、この問題を解決する実際的な解決法はまだない。

サービス探索のために設計された多くのプロトコルがある（第２項参照）。しかしながら、これらのプロトコルのうちのいずれも、
近隣ネットワークに関する情報を探索すること、
探索データベースの動的構築、および
どんな情報を収集し、モバイルに提供すべきか決定すること
をサポートしていない。

代わりに、既存のサービス探索機構は、データベースにすでにある情報をどのようにして取り出すべきかに焦点を合わせるものである。これらは、全ローカルネットワークプロバイダを利用して、サービス情報サーバを実施するが、これは、公衆ネットワークにおいて展開するには厳しすぎる。

本明細書では、探索データベース構築問題を解決する方法、およびモバイルが近隣ネットワークに関する情報を探索する方法を含む、ネットワーク探索をサポートする新しいアーキテクチャについて説明する。提案するアーキテクチャを、情報サービスのためのアプリケーション層機構（ＡＩＳ）という。ＡＩＳは、モバイルによって必要となり得る、現在および将来のネットワーク情報の種類をサポートするのに充分な拡張可能性を有するように設計される。ＡＩＳは、できる限り既存のプロトコルを利用する。ネットワーク要素に関する情報には複数の使用法が有り得るが、本明細書では、モバイルが事前対応型ハンドオフと保護された事前認証を可能にするのに使用できる情報を探索することに焦点を合わせ、これらの情報を使って、保護された事前対応型ハンドオフがどのようにサポートできるかを論じる。

４ 関連する機構
目下、ＳＬＰ、ＪＩＮＩ、ＵＰｎＰ、サリュテーション（salutation）、およびＬＤＡＰを含めて、いくつかのサービス探索プロトコルおよびアーキテクチャが存在する。しかしながら、これらの大部分は、ユーザが、サービス関連情報を、この情報がすでにデータベースに用意されているものと仮定して、どのように検索するかに焦点を合わせたものである。サービス関連情報、したがって、この情報をホスティングするのに使用されるサーバは、例えば、インターネットドメイン名システム（ＤＮＳ）に類似したやり方で、階層として編成できる。サービス関連情報は、事前構成され、またはサーバ上で動的に構成できる。次いで、この情報は、人間の管理者によって、または、相互に更新を交換し合うサーバ自体によって自動的に更新できる。

ネットワークサイズおよびユーザ人口が増大すると、告知すべき情報を事前構成することは、告知されるのがサービス関連情報であるか、それともネットワーク情報であるかを問わず、スケーラブルな解決法ではなくなる。また、サーバにネットワーク情報を自動的に取り込み、更新するよう要求することにも、以下を含むいくつかの制限がある。

各モバイル機器が知ろうとするネットワーク情報は、モバイル機器の能力と用途に応じて大きく異なり得る。例えば、モバイル機器の中には、ＤＨＣＰサーバのアドレスまたは近隣ネットワーク内の認証サーバのアドレスを知って、近隣ネットワークへのハンドオフが必要になる前に、モバイルが近隣ネットワークからＩＰアドレスを獲得し、近隣ネットワークと事前認証を行うことができるようにしようとするものもある。他のモバイルユーザの中には、利用可能なローカルサービスだけを知ろうとするものもある。ネットワークプロバイダが、どんな情報が多数の多様な現在および将来のユーザによって必要とされるか予見することは難しい。結果として、ネットワークプロバイダが、どんな情報を情報サーバに維持すべきか決定することが難しくなる。

モバイルユーザは、ローカルネットワークプロバイダを利用して情報サーバを提供することが必要になる。すべてのネットワークプロバイダが、世界中のあらゆる場所で、かかる情報サーバを提供することを期待するのは難しい。さらに、提供しようとする情報セットがネットワークプロバイダによって異なることもある。

今日利用可能な多くのサービス探索プロトコルのどれも、モバイルユーザによって必要とされる、多様で、変化するサービスおよびネットワーク情報を処理するのに充分な柔軟性を有することに関して明確に成功を収めているようには思われない。結果として、ネットワークプロバイダによって異なるサービス探索プロトコルを使用することになり得る。これは、ユーザが、異なるネットワークでは異なるサービス探索プロトコルを使用する必要があり得ることを意味し、ユーザにとっては重い負担である。

近年、特に、ネットワーク近隣探索をサポートするのに使用される探索プロトコルを設計しようとするいくつかの取り組みが行われている。代表的な例が、アクセスルータ候補探索（ＣＡＲＤ）プロトコル［２８］である。アクセスルータ候補とは、モバイル機器がそこに移動できる近隣ネットワーク内のアクセスルータである。ＣＡＲＤは、シームレスなＩＰ層ハンドオフをサポートするために、モバイルが近隣ネットワークへのＩＰ層ハンドオフを実行する前に、モバイルによってアクセスルータ候補を探索するのに使用されるように設計される。ＣＡＲＤを用いる場合、モバイルは、ＩＰ層ハンドオフに関する決定を行う前に、近隣ネットワーク内の無線アクセスポイント（ＡＰ）からのＩＥＥＥ８０２．１１ ＢＳＳＩＤブロードキャストなどの第２層識別子をリッスンする。次いで、モバイルは、これらの第２層識別子を、これの現在のネットワーク内のアクセスルータに送り、現在のネットワーク内のアクセスルータが、さらに、これらの第２層識別子を、近隣ネットワーク内のアクセスルータ候補のＩＰアドレスにマップし、次いで、ルータ候補アドレスをモバイルに送り返す。ＣＡＲＤを使ったネットワーク近隣探索のサポートは、以下の限界をもたらす。

ＣＡＲＤは、近隣アクセスルータ同士が相互にやりとりして、能力情報を動的に交換し合うことを必要とする。これは、通常、近隣ネットワークが異なるネットワークプロバイダに属するときには不可能である。

目標アクセスルータを探索するために、モバイルは、ＣＡＲＤを使ってこれの現在のアクセスルータとやりとりする必要がある。世界中のすべてのアクセスネットワークがＣＡＲＤを実施することを期待するのは難しい。

ユーザがＣＡＲＤを使って探索することのできる情報は、ローカルネットワークプロバイダが、これのＣＡＲＤプロトコルを、どんな情報を提供するように構成するかに左右され、ネットワークごとに大きく異なり得る。さらに、前述のように、ネットワークプロバイダは、モバイルが必要とする適切な情報を提供しないこともあり得る。というのは、ネットワークプロバイダは、あらゆるモバイル機器上のネットワークソフトウェアおよびアプリケーションの多様で、変化する必要性を容易に予見することができないからである。

最近では、ＩＥＥＥ８０２．１１ＴＧｕ（タスクグループＵ）が、第２層ビーコンの一部としてより上位層の情報を提供するための方法を研究している。このように、モバイルは、近隣ネットワークからのビーコンを受動的に監視する。すなわち、モバイルは、他の第３層情報を判定することができる。しかし、最大伝送単位のサイズ限界のために、第３層情報すべてが、第２層ビーコンの一部として収容できるとは限らない。また、複数の異種混交アクセス技術をサポートするのが難しいこともある。よって、第２層不可知であり、複数の異種混交アクセスにわたって動作し得る解決法を有することが重要である。この提案の一部として、発明者らは、近隣ネットワークのＩＰアドレス、ＱｏＳ（サービス品質）、セキュリティパラメータなど、異なるパラメータを探し出すアプリケーション層ネットワーク近隣探索プロセスを考案した。

４．２ 既存のサービス探索機構の概要
無線アドホックネットワークの出現と共に、特殊化情報機器が、技術展望を引き継ぐ。これらの情報機器は、本質的に、モビリティ、したがってこれら情報機器間の協働をサポートすることを目的として生まれたものである。というのは、協働は、従来の完全性能のコンピュータ機器と比べて、モバイル機器に欠けているいくつかの部分を補完する不可欠な機能だからである。この協働のために、いくつかのサービス探索プロトコル（ＳＤＰ）が、単純で、シームレスで、スケーラブルな機器相互運用性を究極目的とした機器間対話を保証する協調アーキテクチャの部分として提案されている。台頭しつつあるＳＤＰの間では、Ｊｉｎｉ、ユニバーサルプラグアンドプレイ、サリュテーション、およびＳＬＰが目立っている。

３．３．１ ＪＩＮＩ接続技術
Ｊｉｎｉアーキテクチャの目的は、機器とソフトウェアコンポーネントのグループを単一の、動的分散システムに統合することである［２］。Ｊｉｎｉシステムは、分散システムにおけるサービス構築、ルックアップ、通信および使用のための機構を提供する。サービスの例には、プリンタ、ディスプレイ、ディスクなどの機器、アプリケーションやユーティリティなどのソフトウェア、データベースやファイルなどの情報、およびシステムのユーザが含まれる。

Ｊｉｎｉシステムの中心は、ディスカバリ（discovery、発見）、ジョイン（join、参加）、およびルックアップ（lookup、検索）と呼ばれる３つのプロトコルである［２］。これらのプロトコルのうちの２つ、すなわち、ディスカバリとジョインは、機器が接続されるときに実行される。ディスカバリは、サービスが、登録すべきルックアップサービスを探しているときに実行される。ジョインは、サービスがルックアップサービスを探し出し、これに参加しようとするときに実行される。ルックアップは、クライアントまたはユーザが、（Ｊａｖａプログラミング言語で書かれた）これのインターフェースの種類と、おそらく、他の属性によって記述されるサービスを探し当て、呼び出す必要のあるときに実行される。以下のステップに、Ｊｉｎｉコミュニティにおいてクライアントによって使用されるべきサービスのために、クライアントと、サービスプロバイダと、ルックアップサービスの間でどんな対話が必要とされるかを示す［２］［１］。

１）サービスプロバイダが、ローカルネットワーク上で要求をマルチキャストすることによってルックアップサービスを探し出し、または予め分かっているリモートルックアップサービスを探し出す。

２）サービスプロバイダは、サービスオブジェクトとこれのサービス属性を、ルックアップサービスに登録する。このサービスオブジェクトは、ユーザとアプリケーションが、他の任意の記述属性と共にこのサービスを実行するため呼び出すことになるメソッドを含む、サービスのＪａｖａプログラミング言語インターフェースを含む。

３）クライアントが、Ｊａｖａの種類と、おそらく、他のサービス属性によってサービスを要求する。サービスオブジェクトのコピーがクライアントに移動され、クライアントがサービスと対話するのに使用される。

４）次いで、クライアントは、サービスオブジェクトを介してサービスプロバイダと直接対話する。

Ｊｉｎｉ接続技術は、機器が、当座のコミュニティを形成するために相互にどのようにして接続し合うかの基本的問題に対処するインフラストラクチャとプログラミングモデルからなる。図１に示すＪａｖａ技術［１］、［２］に基づき、Ｊｉｎｉ技術は、Ｊａｖａリモートメソッド呼び出しプロトコルを使って、ネットワークの周りでコードを移動させる。ネットワークサービスが、Ｊｉｎｉソフトウェアアーキテクチャの上で実行される。これに関して、図１に、Ｊｉｎｉ接続技術のアーキテクチャが示されている。

ａ．ルックアップサービス
ルックアップサービスは、サービスがこれを介して探し出され、解決されるという点で、ディレクトリサービスとみなすことができる。Ｊｉｎｉコミュニティにおいて、サービスは、ディスカバリおよびジョインプロセスを介して、サービスのプロキシオブジェクトをルックアップサービスに登録し、クライアントは、ルックアップサービスに問い合わせてクライアントが求めるサービスを探し出す。Ｊｉｎｉは、異なる状況で役立つ、３つの関連するディスカバリプロトコルを使用する［３］、［４］。マルチキャスト要求プロトコルは、アプリケーションまたはサービスが最初に活動化され、近傍のルックアップサービスを探し出すことが必要になるときに使用される。マルチキャスト告知プロトコルは、ルックアップサービスが、コミュニティに関与できるサービスにルックアップサービスの存在を告知するのに使用される。ユニキャスト探索プロトコルは、広域ネットワークを介して事前に分かっている特定のルックアップサービスとの通信を確立するのに使用される。

しかし、Ｊｉｎｉルックアップサービスは、単なるネームサーバ以上のことを行う。クライアントは、クライアントがサービスを実行するために他の任意の記述属性と共に呼び出すメソッドを含むインターフェースとしてサービスを見る。ルックアップサービスは、クライアントから見えるインターフェースを、サービスプロキシオブジェクト（service proxy objects）の集合にマップする。クライアントは、実際には、サーバとやりとりできるＲＭＩスタブであるサービスプロキシをダウンロードする。このプロキシオブジェクトは、クライアントが、サービスについて何も知らずにサービスを使用することができるようにする。したがって、デバイスドライバシナリオの必要がない。サービスプロキシオブジェクトは、サービス呼び出し、すなわち、ＲＭＩメソッド呼び出し（RMI method invocation）を介してサービスにアクセスする典型的なシナリオであるが、ダウンロードされるサービスオブジェクトは、サービス自体、または任意の専用通信プロトコルを話すことのできるスマートオブジェクトとすることもできる。

ｂ．リース
Ｊｉｎｉシステムのサービスへのアクセスは、リースベースで付与される。すなわち、サービスが、サービスユーザとプロバイダの間で、ある期間について要求され、次いで、折衝された期間について付与される。このリースは、これの期間満了前に更新されなければならない。さもなければ、サービスに関連付けられたリソースが解放される。例えば、ルックアップサービスは、サービス登録へのリースを付与し、サービスは、このリースを更新し続ける必要がある。機器は、コミュニティをそのままにしておくこともでき、登録を取り消す機会を得ずに急に停止することもできる。このため、Ｊｉｎｉシステムが堅固で保守不要な状態に保たれることを可能にするのは、リースである。

ｃ．リモートイベントおよびトランザクション
基本のサービスディスカバリ／ジョインおよびルックアップ機構以外に、Ｊｉｎｉは、プログラマが、信頼性の高い、スケーラブルなやり方で分散プログラムを書くのに役立つリモートイベントおよびトランザクションをサポートする。リモートイベントは、システムで所望の変更が行われるときに、オブジェクトに通知されることを可能にする。これらのイベントは、新しくパブリッシュされたサービスまたはサービスの何らかの状態変化によってトリガできる。例えば、プリンタへの関与を登録したＪｉｎｉパームトップ機には、プリンタが利用可能になったときに、ルックアップサービスによって通知できる。また、Ｊｉｎｉは、２相コミット（２ＰＣ）プロトコルもサポートする。本来、Ｊｉｎｉは、信頼性と堅固さが、部分的な障害と回復によって損なわれる可能性の高い分散システムを構築するのに使用される。しかし、Ｊｉｎｉ２ＰＣは、これが、このプロトコルに厳密に従うよう強制しないという点で、柔軟性を許容するものである。むしろ、アプリケーション論理によって意図される必要な処置を実施することは、アプリケーション（トランザクション参加者）に委ねられている。

３．３．１ ＵＰｎＰ（ユニバーサルプラグアンドプレイ）
ユニバーサルプラグアンドプレイ（ＵＰｎＰ）［６］は、インテリジェント機器、無線機器、およびあらゆる形状因子のＰＣの広範囲にわたるピアツーピア型ネットワーク接続のアーキテクチャである。ＵＰｎＰは、プラグアンドプレイ周辺モデルの拡張として導入されるが、ＵＰｎＰは、プラグアンドプレイの単純な拡張以上のものである。ＵＰｎＰにおいて、機器は、動的にネットワークに参加し、ＩＰアドレスを獲得し、要求に応じてこれの能力を伝達し、他の機器の存在と能力に関して知ることができる。最後に、機器は、どんな不要な状態も後に残すことなく、スムーズに、自動的にネットワークを去ることができる［６］。ユニバーサルプラグアンドプレイは、ＴＣＰ／ＩＰと、ＩＰ、ＴＣＰ、ＵＤＰ、ＨＴＴＰおよびＸＭＬを含むＷｅｂ技術を利用して、家庭とオフィスにおけるネットワークで接続された機器間の、制御とデータ転送に加えて、シームレスな近接ネットワーキングをも可能にする。

ＵＰｎＰは、サービス探索にシンプルサービス探索プロトコル（ＳＳＤＰ）［７］を使用する。このプロトコルは、他の機器またはサービスを探索するのみならず、機器の存在を他の機器に告知するのにも使用される。したがって、ＳＳＤＰは、Ｊｉｎｉの３つのプロトコル、すなわちディスカバリ、ジョイン、およびルックアップに類似したものである。ＳＳＤＰは、それぞれ、ＨＴＴＰＭＵとＨＴＴＰＵと呼ばれる、マルチキャストとユニキャストのＵＤＰを介してＨＴＴＰを使用する。

参加する機器は、制御点にこれのサービスを告知する告知（ssdp:alive）マルチキャストメッセージを送出する。これらは、機器に組み込まれたサービスの潜在的クライアントである。Ｊｉｎｉとは対照的に、ＵＰｎＰには中央サービスレジストリがない。ＳＳＤＰの他方のメッセージは、新しい制御点がネットワークに追加されたときに送られるサーチ（ssdp:discover）マルチキャストメッセージである。このマルチキャストを聞く任意の機器は、これに、ユニキャスト応答メッセージで応答する必要がある。

機器の機能と能力を記述するのにＸＭＬが使用される。前述の告知メッセージは、ネットワーク内の、ＵＰｎＰ機器の能力を記述するＸＭＬファイルを指し示すＵＲＬを含む。したがって、他の機器は、このＸＭＬファイルを検索することによって、この機器の機能を検査し、目的に適するかどうか決定することができる。このＸＭＬ記述は、Ｊｉｎｉの簡単なサービス属性とは対照的に、機器能力の複雑で、効果的な記述を可能にする。

図２に、説明のためのＵＰｎＰプロトコルスタックを示す。機器間の通信で、ＵＰｎＰは、図２に示すプロトコルスタックを使用する［６］。最新の仕様［６］によれば、ＵＰｎＰ機能は、以下の５つのステップとして要約され得る。

探索：ＵＰｎＰ探索プロトコルはＳＳＤＰに基づくものである。機器がネットワークに追加されると、機器は、これのサービスをネットワーク上の制御点に告知する。同様に、制御点がネットワークに追加されると、ＵＰｎＰは、この制御点が、ネットワーク上で当該の機器をサーチすることができるようにする。どちらの場合も基本的なやりとりは、機器の種類、識別子、より詳細な情報を指し示すポインタなど、機器または機器のサービスの１つに関する少数の不可欠な細目を含む探索メッセージである。

記述：制御点が機器を発見した後でも、制御点は、依然として、この機器についてほとんど知らない。制御点が機器と機器の能力についてさらに知るため、または機器とやりとりするためには、制御点は、機器によって探索メッセージで提供されるＵＲＬから機器の記述を検索しなければならない。機器のＵＰｎＰ記述は、ＸＭＬで表され、制御、イベント発行、および表示のためのＵＲＬに加えて、任意の組み込み機器またはサービスのリストも含む。

制御：制御点は、機器の記述を検索した後で、機器のサービスに処置を送ることができる。このために、制御点は、サービスの制御ＵＲＬに、適切な制御メッセージを送る。また、制御メッセージも、簡易オブジェクトアクセスプロトコル（ＳＯＡＰ）を使ってＸＭＬで表される。機能呼び出しと同様に、制御メッセージに応答して、サービスは、任意の処置特有の値を返す。

イベント発行：サービスのＵＰｎＰ記述は、サービスが応答する処置のリストと、実行時のサービスの状態をモデル化する変数のリストを含む。サービスは、これらの変数が変化するときに更新をパブリッシュし、制御点は、この情報を受け取るようサブスクライブできる。サービスは、イベントメッセージを送ることによって更新をパブリッシュする。イベントメッセージは、１つ以上の状態変数の名称と、これらの変数の現在値を含む。また、これらのメッセージも、ＸＭＬで表され、一般イベント通知アーキテクチャ（ＧＥＮＡ）を使ってフォーマット設定される。

表示：機器が表示用ＵＲＬを有する場合、制御点は、このＵＲＬからページを検索し、このページをブラウザにロードし、ページの機能に応じて、ユーザに、機器を制御させ、かつ／または機器状況を閲覧させることができる。

ＵＰｎＰの別の重要な機能が、プラグインされているＩＰアドレスの自動構成である。この目的で導入されている、ＡｕｔｏＩＰ［１３］は、どんな明示的管理もなしで、機器がネットワークに参加することを可能にする。機器は、ネットワークに接続されると、ネットワーク上のＤＨＣＰサーバからＩＰアドレスを獲得しようとする。しかし、ＤＨＣＰサーバがない場合には、ＩＰアドレスが、ローカルネットワーク使用のための予約範囲から自動的に請求される。このため、これをＡｕｔｏＩＰという。機器は、予約範囲内のアドレスをランダムに選択し、次いで、他の誰かがすでにこのアドレスを請求しているかどうか調べるよう求めるＡＲＰ要求を出すことによってアドレスを請求する。

３．３．１ サリュテーション
サリュテーションは、広く普及している接続性とモビリティの環境における、幅広い機器および装置の間のサービス探索および利用の問題を解決するためにサリュテーションコンソーシアム（Salutation Consortium）によって開発されている、別の主要な協働アーキテクチャである。対象機器の多様な性質を想定し、サリュテーションは、プロセッサ、オペレーティングシステムおよび通信プロトコルから独立のものである。このアーキテクチャは、アプリケーション、サービスおよび機器が、これらの能力を記述し、他のアプリケーション、サービスおよび機器に告知する標準的方法を提供する。また、このアーキテクチャは、アプリケーション、サービスおよび機器が、特定の能力を求めて他のアプリケーション、サービスまたは機器をサーチし、これらの能力を利用するために、これらとの相互運用可能なセッションを要求し、確立することも可能にする［８］［９］。

図３［８］に示すように、サリュテーションアーキテクチャは、２つの主要コンポーネント、サリュテーションマネージャ（Salutation Manager）とトランスポートマネージャ（Transport Manager）からなる。サリュテーションマネージャは、このアーキテクチャの核であり、Ｊｉｎｉにおけるルックアップサービスに類似したものである。これは、サービスブローカとして定義される。すなわち、サービスプロバイダが、これの能力をサリュテーションマネージャに登録する。クライアントがこれのローカルサリュテーションマネージャに、サービスサーチを求めると、このサーチは、サリュテーションマネージャ間の協調によって行われる。次いで、クライアントは、返されるサービスを使用することができる。サリュテーションマネージャは、基礎をなすネットワークトランスポートが何であるかを問わず、信頼性の高い通信チャネルを提供するトランスポートマネージャの上に位置する。

サリュテーションマネージャは、サーバおよびクライアントアプリケーションへのトランスポート独立のインターフェースを提供する。このインターフェース（ＳＬＭ−ＡＰＩ）は、サービス登録、サービス探索、およびサービスアクセス機能を含む。

サリュテーションアーキテクチャの通信プロトコルの独立性は、サリュテーションマネージャとトランスポートマネージャの間のインターフェース（ＳＬＭＴＩ）によって達成される。トランスポートマネージャは、これがサポートするネットワークトランスポートに依存するエンティティである。サリュテーションマネージャは、これが、複数の、物理的に異なるネットワークに接続されている場合には、複数のトランスポートマネージャを有し得る。しかし、サリュテーションマネージャは、トランスポート独立のインターフェース（ＳＬＭ−ＴＩ）を介してこれの基礎をなすトランスポートを見る。

図３を参照すると、この図には、サリュテーションマネージャのモデルが示されている。サリュテーションマネージャによって提供される主要タスクは、以下のように要約できる。

サービスレジストリ（Service Registry）：サリュテーションマネージャは、サービスに関する情報を保持するレジストリを含む。クライアントが、クライアント自体を登録または非登録とする。すべての登録が、ローカルサリュテーションマネージャ、またはクライアントに接続された近くのサリュテーションマネージャに対して行われる。これは、Ｊｉｎｉにおけるルックアップサービスに対応するものである。

サービス探索（Service Discovery）：サリュテーションマネージャは、他のサリュテーションマネージャとこれらに登録されているサービスを探索する。リモートサービスが、ローカルサリュテーションマネージャによって指定される（１つ以上の）種類と属性の集合をマッチさせることによって探索される。このサリュテーションマネージャ間の通信プロトコルを、Ｓｕｎ社のＯＮＣ ＲＰＣを使ったサリュテーションマネージャプロトコルという。能力交換と呼ばれるこの独自の機能が必要とされるのは、サービスが、基本的に、同じ装置内のローカルサリュテーションマネージャに登録されるからである。サリュテーションマネージャ間のこの協働は、概念的には、Ｊｉｎｉが行うのと同じだが、ネットワーク全体に分散されたルックアップサービスを形成する。

サービス利用可能性（Service Availability）：クライアントアプリケーションは、ローカルサリュテーションマネージャに、サービスの利用可能性を周期的にチェックするよう求めることができる。このチェックは、ローカルマネージャと対応するマネージャの間で行われる。これは、Ｊｉｎｉのリモートイベント概念の限定バージョンである。

サービスセッション管理（Service Session Management）：このセッション管理は、サリュテーションのサービス呼び出しの側面に対処する。クライアントが、サービス探索によって発見されたサービスを使おうとすると、サービスセッションが確立される。サービスセッションは、３つの異なるモード、すなわち固有モード、エミュレートモード、およびサリュテーションモードの１つで操作される。サリュテーションマネージャは、モードに応じて、サービスセッションにおけるメッセージ交換に関与することもしないこともある。固有モードでは、メッセージが、固有プロトコルを介して交換され、サリュテーションマネージャは、メッセージ交換には決して関与しない。エミュレートモード（emulated mode）では、サリュテーションマネージャプロトコルを使って、クライアントとサービスの間でメッセージが運ばれるが、サリュテーションマネージャは、内容を検査しない。サリュテーションモードでは、サリュテーションマネージャは、メッセージを運ぶだけでなく、セッションで使用されるべきメッセージ形式も定義する。

サリュテーションアーキテクチャにおける基本構成単位として機能単位が定義される。言い換えると、これは、クライアントまたはサービスを構成する最小限の有意味の機能である。機能単位の集合体が、サービスレコードを定義する。例えば、ファックスサービスは、［印刷］、［スキャン］、および［ファックスデータ送信］機能単位によって定義できる。各機能単位は、記述属性レコードで構成される。これらのサービス／機能単位／属性レコードは、ＩＳＯ８８２４ＡＳＮ．１を用いて規定される。また、ここでサリュテーション−ライト（Salutation-Lite）［１０］について触れておいてもよいであろう。サリュテーション−ライトは、省スペースの機器を対象としたサリュテーションアーキテクチャの縮小バージョンである。サリュテーションコンソーシアムでは、サリュテーション−ライトが、パームサイズやハンドヘルドコンピュータ（すなわち、ＰａｌｍおよびＷｉｎＣＥ機器）などの小型情報機器への計り知れないほどの適用可能性を有すると考えている。また、サリュテーション−ライトは、ＩＲやブルートゥースなどの低帯域幅ネットワークにも適している。

３．３．１ ＳＬＰ（サービスロケーションプロトコル）他
サービスロケーション探索（ＳＬＰ）［１７］は、サービス探索プロトコルのＩＥＴＦバージョンであるが、他のサービス探索プロトコルと同様に、独自の背景、目標領域、および特徴を有するものである。ＳＬＰは、サイト内のサービス探索のための、分散化され、軽量で、スケーラブルで、拡張可能なプロトコルである［１６］。ＳＬＰは、サービスの種類とサービスのアドレスを定義するサービスＵＲＬを定義する。例えば、「service:printer:lpr://hostname」は、ホスト名において利用可能なラインプリンタサービスのサービスＵＲＬである。このサービスＵＲＬに基づき、ユーザは、これのサイトで利用可能なサービスをブラウズし、選択されたサービスを利用してユーザの必要を満たす。例えば、ユーザ（アプリケーション）は、ＳＬＰを使って、同じフロアにある任意のカラープリンタを探し出す。

ＳＬＰには、ユーザエージェント（ＵＡ）、サービスエージェント（ＳＡ）、ディレクトリエージェント（ＤＡ）という３つのエージェントがある。ＵＡは、ユーザアプリケーションに代わってサービス探索要求を送るソフトウェアエンティティである。ＳＡは、サービスに代わってサービスを告知するエンティティである。中央サービス情報リポジトリ（centralized service information repository）として、ＤＡは、ＳＡからの告知をキャッシュし、後で、ＵＡからの要求に応答する。ＳＡは、ＤＡに登録することによって、これ自体を告知する。この登録メッセージは、告知されるサービスのＵＲＬ、サービスの存続期間、およびサービスの記述属性の集合を含む。ＳＡは、これの期限が切れる前に、ＤＡとの登録を周期的に更新する必要がある。この存続期間は、ネットワークが過渡的な状態のままに置かれるのを防ぐためのものであり、類似の概念は、ＪｉｎｉやＵＰｎＰなど、他のサービス探索プロトコルでも見られる。ＤＡは、登録をキャッシュし、ＳＡに確認メッセージを送る。ＵＡは、ＤＡに、サービスの場所を要求するサービス要求メッセージを送る。次いで、ＤＡは、ＵＡの必要性と突き合わせされたサービスのＵＲＬを含むサービス応答メッセージで応答する。これで、ＵＡは、返されたＵＲＬによって指し示されるサービスにアクセスすることができる。ＳＬＰでは、ＤＡは任意選択である。小規模ネットワークではＤＡがなくてもよい。この場合、ＵＡのサービス要求メッセージは、ＳＡに直接送られる。

ＳＬＰは、サービスブラウジングと、サービス属性の文字列問い合わせ（string-based query）をサポートし、これらは、ＵＡが、ネットワーク上のサービスの中から最も適切なサービスを選択することを可能にする。ＵＡは、ＡＮＤ、ＯＲ、比較演算子（＝、＜、≦、＞、≧）、従属文字列整合（substring matching）などの問い合わせ演算子を要求することができる。これは、他のものよりも強力である。例えば、Ｊｉｎｉでは、サービス属性整合は、等しいものだけについてしか行われ得ない。

最後に、ＳＬＰは、イントラネットサービス探索の必要性への解決法であるといわれているが、より大規模なネットワークにもうまく適合する。このスケーラビリティは、マルチキャストメッセージの最小限の使用、適用範囲概念、複数のＤＡなど、様々な特徴によってサポートされる。

また、ブルートゥースプロトコルスタックも、サービス探索のためのＳＤＰ［１４］を含む。ブルートゥースＳＤＰは、ブルートゥース環境専用に設計されているため、他のサービス探索プロトコルと比べて、限られた機能だけしかサポートしない。基本的に、ＳＤＰは、サービスクラスによるサーチ、サービス属性によるサーチ、およびサービスブラウジングをサポートする。サービスブラウジングは、クライアントが、クライアントの近傍で利用可能なサービスに関して事前知識を持たないときに使用される。サービス探索アプリケーションプロファイル［１５］が、サービス探索アプリケーションによって、他の機器のサービスを探し出すのに使用されるプロトコルと手順を定義する。ブルートゥースＳＤＰは、Ｌ２ＣＡＰの事前定義されたコネクション型チャネル上で実行される。

ブルートゥースＳＤＰは、あまり複雑ではないブルートゥース機器用に最適化されている。よって、ブルートゥースＳＤＰは、主に、サービス探索問題に対処するものである。ブルートゥースＳＤＰは、サービスへのアクセスも、サービスの仲介も、サービス告知も、サービス登録も提供しない。サービスが利用できなくなったときのイベント通知はない。したがって、これらの不足を補うために、他のサービス探索プロトコルが使用されてもよい。例えば、ブルートゥースＳＤＰの上でサリュテーションが使用できる。かかるマッピング［１１］は、サリュテーションのトランスポート独立のアーキテクチャのために、簡潔に見える。

この分野には、ゼロ構成ネットワーキング（zeroconf）［２０］、ＭＩＴのＩＮＳ（Intentional Naming System（意図的命名システム））［２１］、およびバークリーサービス探索サービス［２２］という競合する他の機構もある。これらは、それぞれ、異なる目的で、他と異なる手法を用いる。結果として、これらは、他のプロトコルと比較して、いくつかの強みと弱みを有する。

近年、ネットワーク近隣探索をサポートする探索プロトコルを設計しようとする取り組みが行われている。代表的な例が、ＩＥＴＦによって標準化されているアクセスルータ候補探索（ＣＡＲＤ）［２６］プロトコルである。アクセスルータ候補とは、モバイル機器がそこに移動できる近隣ネットワーク内のアクセスルータである。ＣＡＲＤは、モバイルによって、モバイルが近隣ネットワークへのＩＰ層ハンドオフを行う前に、アクセスルータ候補を探索するのに使用できるプロトコルである。ＣＡＲＤを用いる場合、モバイルは、ＩＰ層ハンドオフに関する決定を行う前に、近隣ネットワーク内の無線アクセスポイント（ＡＰ）からの第２層ＩＤをリッスンする。次いで、モバイルは、ＣＡＲＤプロトコルを使って、これらの第２層ＩＤを、これの現在のネットワーク内のアクセスルータに送り、現在のアクセスルータは、さらに、これらの第２層ＩＤを、近隣ネットワーク内のアクセスルータ候補のＩＰアドレスにマップし、次いで、候補ルータアドレスをモバイルに送り返す。ＣＡＲＤには以下の限界がある。

ＣＡＲＤは、近隣のアクセスルータが、ＣＡＲＤプロトコルを使ってネットワーク情報を動的に交換することを必要とし、これは、通常、近隣ネットワークが異なるネットワークプロバイダに属するときには不可能である。結果として、ＣＡＲＤは、例えば、異なるネットワークプロバイダに属する、セルラネットワークと無線ホットスポットネットワークの間など、異種混交無線システムにまたがってモビリティをサポートするのには使用できないことになる。

また、ＣＡＲＤは、すべてのアクセスルータが、モバイルユーザとやりとりするためにＣＡＲＤプロトコルを実施することも必要とし、これは、難しい問題である。

モバイル機器がＣＡＲＤを介して探索することのできる情報は、個々のローカルネットワークプロバイダが、これのＣＡＲＤプロトコルを、どんな情報を提供するように構成するかに左右され、これは、ネットワークごとに大きく異なり得る。各モバイル機器が知ろうとするネットワーキング能力は、モバイル機器のネットワーキング能力と用途に応じて大きく異なり、時間が経つにつれて変化し得る。ネットワークプロバイダが、モバイル機器によってどんな情報が必要とされるか予見することは困難である。例えば、事前認証を行うことのできるモバイル機器は、近隣ネットワークへのハンドオフが必要になる前に近隣ネットワークとの事前認証を行うことができるように、近隣ネットワーク内の認証サーバのアドレスを知ろうとする。他のモバイル機器は、例えば、近隣ネットワーク内のＳＩＰサーバ／プロキシまたはＤＨＣＰサーバのアドレスだけを知ろうとする。

ＬＤＡＰ（軽量ディレクトリアクセスプロトコル）［ＬＤＡＰ］は、一般のディレクトリルックアッププロトコルであり、ディレクトリ更新操作を可能にし、よって、モバイルからデータを収集するのに使用され得る。しかしながら、ＬＤＡＰは、基本的なネットワーク探索問題に適した解決法ではない。というのは、（ｉ）ＬＤＡＰは、階層的に構築されたデータベースのルックアップだけをサポートするが、ネットワーク情報データベースの構造は、単なるツリーにとどまらない（すなわちグラフである）こともあり、（ｉｉ）ＬＤＡＰは、新しいネットワーキング技術が展開されるにつれて頻繁に変化する可能性の高い問い合わせデータベーススキーマをサポートしないからである。

３．３．１ Gloserv
Gloserv［２９］は、イベント、場所ベースのサービス、通信およびＷｅｂサービスを含み得る数種類のサービスを提供するサービス探索アーキテクチャである。Gloservアーキテクチャは、ＤＮＡに似ており、情報サービスを管理するルートネームサーバと権限ネームサーバを含む。Gloservアーキテクチャは、イベント、サービス、人々、場所といった、ネームサーバのためのいくつかのハイレベルカテゴリを有し得る。Gloservアーキテクチャは、これのサービスを告知することのできる登録機能や、ローカルユーザエージェントに、サーバからのある一定のサービスの集合を問い合わせることのできる機能などのサービスの集合を提供する。Gloservは、ＲＤＦスキーマを使ってサービスの集合を定義し、Sesameを使ってＲＤＦレコードを作成し、格納する。Sesameは、これの問い合わせ機構の一部として、ＨＴＴＰ、Ｊａｖａ ＲＭＩまたはＳＯＡＰを使用することができる。

他方、ＡＩＳベースの情報探索機構は、Gloservによって提供される、最も近くのレストラン、最近の、コンサートなどある種のイベントといった、場所ベースのサービスとは異なり、（ＱｏＳ、アクセスポイント、ルータ、ＳＩＰサーバ、ＰＡＮＡ認証エージェント）といったいくつかの種類の特性を有する近隣ネットワーク内のネットワーク要素を探索するのに使用される。Gloservサービスアーキテクチャによって提供される情報は、高速ハンドオフを提供するのに必要な情報を提供するのに十分なものではない。ＡＩＳベースのサービス探索方式は、データベース構造としてＲＤＦを使用するが、付随的プロトコルとしてＳＯＡＰ、ＨＴＴＰ、ＸＭＬ、ＷＳＤＬ、ＪＥＮＡを使って、スカウト、報告エージェントによるデータベースへのデータ取り込み、およびモバイルによる情報問い合わせのための適切なトランスポート機構を提供する。よって、ＡＩＳベースのサービス探索方式は、通常は、Gloservなど他の探索機構の範囲外である、前もって近隣要素内のＡＰ、ルータ、ＳＩＰサーバ、ＰＡＮＡサーバといったネットワーク要素を探索することによって、保護された事前認証をセットアップしようとするモバイルユーザにより適している。

３．３．１ 既存のサービス探索機構間の比較
最小限の管理と人間の介在で、機器／サービス間の動的協働を円滑に行わせるいくつかのサービス探索プロトコルが提案されている。当座のコミュニティをサポートすることができるように、これらのプロトコルは、これの存在をネットワークに告知し、近隣のサービスを探索し、サービスにアクセスするための手段を提供する必要がある。基本的に、Ｊｉｎｉ、ＵＰｎＰ、サリュテーション、およびＳＬＰは、すべて、これらの側面に対処するが、異なる観点でのものである。これらは、前述の機能に対する重点の置き方が異なるため、直接の比較は回避すべきである。とは言うものの、本明細書でかかる比較を試みようとするのは、比較が、これらの機構それぞれを理解するのに役立つはずだからである。表１には、主要なサービス探索プロトコルの特徴が要約されている。

ＪｉｎｉとＵＰｎＰは、一般的なコンピューティング環境がこれらの解決法によって使用可能とされることを想定しているが、サリュテーションとＳＬＰは、主に、サービス探索問題を扱うものである。Ｊｉｎｉは、ネットワークサービスの展開を助けるために２ＰＣトランザクションおよびJavaSpaceを提供することに留意されたい［３］。ＵＰｎＰのＳＳＤＰは、ＵＰｎＰ仕様の一部にすぎない。Ｊｉｎｉと、ＵＰｎＰと、サリュテーションの間の適切な比較が［１９］に示されている。

Ｊｉｎｉは、Ｊａｖａに依存してこれのすべての約束を可能にする。Ｊｉｎｉは、Ｊｉｎｉプロキシがリソースの乏しい機器のクラスタに使用できる場合でさえも、機器がＪａｖａ仮想マシンをサポートするものと想定する。しかも、Ｊｉｎｉ／ＲＭＩは、携帯電話、ページャ、ＰＯＳといった小型情報機器のためにＪ２ＭＥ ＣＬＤＣ（接続された限定された機器構成）構成によってサポートされていない［２４］。

Ｊｉｎｉのサービスプロキシ概念は、他では見られない最強の特徴の１つである。しかし、このドライバ不要シナリオは、標準インターフェースを備えるＪｉｎｉ機器がすでにネットワークで利用可能であることを仮定している。これは言われているほど簡単ではない。というのは、これは、ある特定の機器の種類のすべての製造者が標準インターフェースに同意しなければならないことを意味するからである。最初に、プリンタおよび記憶装置インターフェースの標準化は、製造者のコンソーシアム（consortia）によって進められている。

ＵＰｎＰは、既存のＩＰおよびＷｅｂ技術を利用する。ＵＰｎＰは、これがサービス／機器記述にＸＭＬを使用するという点で独自に見える。ＸＭＬは、機器能力、機器に発行される制御コマンド、機器からのイベントの効果的な記述を可能にする。ＵＰｎＰは、ＡｕｔｏＩＰとＤＨＣＰを利用する自己構成のための新しい機能を導入しているが、これらの機能は、ＩＰｖ６でも見られる［１９］。

サリュテーションは、明確に定義されているが、サービス探索プロトコルとセッション管理だけに限定される。したがって、サリュテーションは、分散環境では疑いなく有用な、リモートイベント通知のような機能に対処しない。トランスポートプロトコルについては、Ｊｉｎｉ、ＵＰｎＰ／ＳＳＤＰ、およびＳＬＰによってＩＰが最優先とされる。サリュテーションは、ＩＰなど任意のネットワーク層プロトコルと、ＩＲおよびＩＥＥＥ８０２．１１無線ＬＡＮを含む任意の物理／リンク層技術上で動作することができる。このトランスポート独立性は、サリュテーションの最強の特徴である。

企業ネットワークでは、ＤＡが、単一障害点になるため、複数のＳＬＰ ＤＡが展開される可能性が高い。これらのＤＡは、よりよい性能を実現するために、階層として編成できる。また、信頼性を実現するために、これらのＤＡの組織／部署の範囲が若干重なり合うこともある。性能と信頼性のためのＤＡ間のこの対話または協働が、ＳＬＰ研究者らによって考察されている。ＳＬＰｖ２は、ＳＬＰメッセージに認証情報を含めることによって、ＳＬＰメッセージの保全性と信頼性を保証することができる。ＳＬＰｖ２は、セキュリティ問題を直接扱うが、他のプロトコルは、他のセキュリティプロトコルを利用する必要がある。

主要サービス探索プロトコルとＡＩＳの比較表
関連する機構：Ｊｉｎｉ、ＳＬＰ、ＵＰｎＰ、サリュテーション、Ｇｌｏｓｅｒｖ

５ ＡＩＳの記述
５．２ ＡＩＳと既存のサービス探索機構の間の差異の概要
Ｊｉｎｉ、ＳＬＰ、ＵＰｎＰ、およびサリュテーションは、ネットワーク近隣情報を探索することができない。Ｇｌｏｓｅｒｖは、いくつかのサービスパラメータを用いて近隣ネットワーク内のネットワーク要素を探索する方法を記述していない。

以下の特徴は、本発明の解決法を独自のものとする。

ＡＩＳは、モバイルが現在接続しているネットワークに関する情報に加えて、近隣ネットワークに関する情報探索のサポートも提供する。

ＡＩＳは、どんな情報を収集すべきか、およびどのようにして情報を提供すべきか判定するのが容易である（既存のサービス探索プロトコルは、すでにデータベース内にある情報をどのようにして検索すべきかに焦点を合わせるものである）。

公衆ネットワークで展開されるときに障害となり得る、ローカルネットワークプロバイダに依拠してサービス情報サーバを実施することがない。

ＡＩＳは、第２層から独立（ＣＤＭＡ、ＩＥＥＥ８０２．１１、ＧＰＲＳなどから独立）である。

ＡＩＳは、ネットワーク支援型とモバイル支援型両方の探索機構を含む。

ＡＩＳは、ネットワーク情報データベースを構築する、ネットワーク支援型とモバイル支援型両方の機構を含む。

５．３ ＡＩＳアーキテクチャ
探索アーキテクチャを設計する間に調べる必要のある重要な設計要因の一部が、情報構築プロセス、情報検索法、情報サーバに格納される情報の形式である。

発明者らはＡＩＳのためにいくつかのアーキテクチャを設計している。これらは、大きくは、２つの主要カテゴリ、すなわち、ネットワーク支援型とモバイル支援型とに分類され得る。以下の各項では、これらのアーキテクチャ、および異なる機能要素がどのようにして相互に対話し合うことができるかについて述べる。これらのアーキテクチャ選択肢のそれぞれにおいて、モバイルは、ＡＩＳサーバまたはピアモバイルに問い合わせて、近隣ネットワーク内のネットワーキング要素に関する情報を探し出す。情報データベースを構築する方法は、アーキテクチャごとに異なる。ネットワーク支援型アーキテクチャは、分散型と集中型両方のモデルに従うことができる。ＡＩＳサーバは、近隣ネットワーク内のネットワーク要素に関する情報を保持し、モバイルからの問い合わせを取得した後でこの情報を提供する。集中型モデルでは、各ネットワーク内の報告エージェントが、ＳＮＭＰ ＭＩＢ（簡易ネットワーク管理プロトコル管理情報ベース）を使ってネットワーク内のネットワーキング要素に関する情報を報告する。モバイル支援型モデルは、事実上常に分散されており、各エンドノードが、これらが現在在圏しているネットワークに関する情報を報告する。情報が各モバイルによってＡＩＳサーバから検索されるやり方は、両手法で共通である。

ピアツーピアベースのモードは、各モバイルが情報サーバとして働き、他のモバイルに情報を提供する別のモバイル支援型モデルである。

３．３ 情報サーバベースのアーキテクチャ
３．３．１ 探索データベース構築
情報サーバベースのアーキテクチャは、モバイル支援型またはネットワーク支援型とすることができる。以下の各項では、ネットワーク情報データベースを構築する、エンドノード支援型とネットワーク支援型両方の手法について述べる。

３．３．１．１． モバイル支援型の手法
本発明は、ローカルサービスおよびネットワーキング能力を収集し、維持し、探索する新しいパラダイム（paradigm）を提案する。この新しいパラダイムは、関連する機構の項で述べた既存の手法の限界を克服するものである。提案する手法は、以下の主要原理を使用する。

各モバイルユーザは、自分が利用可能な任意の適切な手段を使って、在圏ネットワークで利用可能なネットワーク情報を探索することができる。しばしば、ユーザは、後続のモバイルが在圏ネットワークに関して必要とし得る情報を単に探索するためだけに、在圏ネットワークからのどんな特別な支援も受けなくてよくなる。例えば、モバイルは、在圏ネットワークに接続するとき、これの在圏ネットワークに接続する通常のプロセスの一部として、在圏ネットワーク内のアクセスルータと認証エージェントのアドレスを知ることになる。かかる情報は、モバイルのＡＩＳサーバに報告され、ＡＩＳサーバが、さらに、後続のモバイルがこの情報を取り出すことができるように、後続のモバイルがこの在圏ネットワークに移動する前にこの情報をこれらのモバイルに提供することができる。また、利用可能なホットスポットネットワークとこれのログオン要件の探索のために、ローカルネットワークプロバイダに、特別な支援を提供するよう求める必要もない。

各モバイルユーザは、在圏ネットワークで探索する情報をこれのＡＩＳサーバに報告する。モバイルのＡＩＳサーバは、モバイルが現在在圏しているネットワークとのどんな信頼関係もなくてよい。

モバイルユーザのＡＩＳサーバは、様々なネットワークに関してこれの加入者から受け取られるネットワーク情報に関する情報を維持する役割を果たす。

後続のモバイルがある在圏ネットワークに移動すると、このモバイルは、これのＡＩＳサーバに、必要なローカル情報を問い合わせてもよい。

提案する手法は、既存の手法に優る以下の主要な利点を有する。

情報マイニングおよび探索のために、ローカルネットワークプロバイダに頼って、ネットワーク情報の提供に使用される情報サーバを提供することがなくなる。

モバイルユーザがどこにいるか、およびモバイルユーザが現在どのローカルネットワークを使用しているかを問わず、モバイルは、常に、単一のプロトコルを使って、ネットワーク情報を検索するためにこれのＡＩＳサーバとやりとりする。

ＡＩＳサーバは、自己の加入者が関心を有する情報を維持するだけでよい。さらに、ＡＩＳサーバは、自己の加入者が移動する場所に関する情報を維持するだけでよい。このため、提案するパラダイムは高度にスケーラブルなものとなり得る。

提案の協働による探索パラダイムの基本動作を、図４に示す。図４には、モバイルがどのようにしてネットワーク間を移動し、ネットワークの集合によって一般に共用されるロケーションサーバに対して、ネットワーク要素に関する情報を更新することができるかが示されている。この情報は、特定の形式を使ってロケーションサーバに格納される。図４に関しては、ローカルサービスとネットワーク能力の協働による探索を説明する図である。

３．３．１．２．ネットワーク支援型情報探索
ネットワーク支援型情報探索は、３つの異なる方法を定義する。これらの方法とは、
１．報告エージェント（ＲＡ）支援型、
２．ＡＡＡ支援型、
３．ＤＮＳベースの手法
である。

３．３．１．２．１ 報告エージェント支援型
報告エージェント（ＲＡ）は、各ネットワーク内にあるネットワークエージェントである。これらは、ＳＮＭＰ対応であり、ＳＮＭＰ ＭＩＢを調べることによってネットワーク要素に関する情報を収集することができる。これらの報告エージェント（ＲＡ）は、個々のドメイン内の情報を収集し、特定の区域のロケーションサーバデータベースに取り込む。この情報は、能力セット、ＩＰアドレス、個々のネットワーク要素の地理座標などを含み得る。特定のネットワーク要素が、あるドメイン内で接続され、または動作可能になると、この要素の情報が報告エージェント（ＲＡ）上にプッシュされ、さらに、ＡＩＳサーバに送られる。よって、この手法は、前述のエンドシステム支援型の手法と比べて、ＡＩＳサーバデータベースにデータを取り込む半集中型の方法を提供するものである。セキュリティ問題は、この場合、あまり大きな問題ではない。というのは、データベース更新が、エンドクライアントによってではなく、特定のネットワーキングエージェントによって提供され、ＲＡと情報サーバの間に事前に確立されたセキュリティアソシエーションがあるからである。

図５に関しては、報告エージェント（ＲＡ）によって報告される情報を使ってデータベースにデータを取り込む例を示す図である。

３．３．１．３ ＡＡＡサーバ支援型
ＡＡＡサーバ支援型の情報構築は、別のネットワークサーバ支援型の手法である。各モバイルの情報プロファイルが、ＡＡＡサーバにも保存できる。ＲＡＤＩＵＳおよびＤｉａｍｅｔｅｒなど、任意のＡＡＡプロトコルを使って、ＡＡＡクライアントがモバイルのアドレスとＡＡＡクライアントのアドレスの組をＡＡＡサーバに送るというやり方で、ネットワーク探索データベースにデータを取り込むことができる。この組は、ＲＡＤＩＵＳおよびＤｉａｍｅｔｅｒプロトコルの発呼局ＩＤと被呼局ＩＤ属性として運ばれる。ＡＡＡサーバは、ＡＡＡクライアントから報告される情報を収集し、モバイルの（ＡＡＡクライアントのアドレス、モバイルがＡＡＡクライアントと関連付けられた時刻、モバイルがＡＡＡクライアントから分離された時刻）のタプルのリストを記録することによって、モバイルのモビリティパターンを追跡することができる。次いで、このリストは、モバイルがハンドオフを行うことのできる近隣ネットワークのデータベースを構築するのに使用される。

この手法は、サービスプロバイダが、これのトポロジデータベースを他の競合するサービスプロバイダに開示しようとしないことのある、複数プロバイダの場合には適用できないこともあることに留意する。

３．３．１．４ ＤＮＳサーバベースの手法
また、これらのネットワーク要素のリストを探し出すのに、ＡＩＳサーバを使用するのではなく、ＤＮＳ ＳＲＶレコードを使用することもできる。ＤＮＳは、常に、ＤＮＳのＬＯＣレコードを使って、ネットワーク要素（ルータ、ＡＰ）とこれらに関連する地理座標に関連付けられたサービスを取り込むことができる。よって、ＤＮＳサーバに問い合わせ、特定のドメインと地理座標の範囲でのサービスのリストを与え、これらのサービスを提供するネットワーク要素のリストを取得することができる。一般的な問い合わせは次のように見える。１組の地理座標（Ｒ１−Ｒ２）が与えられたとして、経路指定、ＩＥＥＥ８０２．１１、ＡＡＡなど、特定のサービスの集合を提供するサーバの集合を探し出す。ＤＮＳ「ＳＲＶ」レコードと地理的場所レコードの組み合わせが、近傍のサーバの集合を突き止めるのに役立つ。

この手法は、任意の構造化ネットワーク情報データベースを形成するためのものではないことに留意されたい。

３．３．２ 探索データベースの問い合わせ
保護された事前認証、事前対応型ＩＰアドレス取得などの操作の多くが、モバイルの、ドメイン間、ドメイン内のサブネット間の移動中に必要とされ得る。普通、モバイルがサブネットに移動した後で行われるこれらの操作が、前もってなされれば、高速ハンドオフを提供するのに役立つ。これらの操作を前のドメイン／サブネットにいる間に行うためには、モバイルは、移動が終わる前に次のホップルータおよびサーバとやりとりする必要がある。よって、モバイルは、近隣ネットワークに移動する前に、ＡＰ、ルータ、ＤＨＣＰサーバ、およびＰＡＮＡ認証エージェントなどいくつかの認証エージェント、ならびに、場合によってはＳＩＰサーバを含む近隣情報を探索することが必要になる。ネットワーク探索によるこの情報は、モバイルが、事前認証や事前対応型ＩＰアドレス割り当てなど数種類の操作を、前もって行うのに役立つ。以下で、モバイルが近隣ネットワーク要素を探索するのに役立つ１つの機構について述べる。ＤＮＳ「ＳＲＶ」機構は、近隣ドメイン内のかかるネットワーク要素のリストを提供する別の手法を提供する。

最初に、モバイルが、起動し、ＩＰアドレスを獲得し、デフォルトのゲートウェイなど他のネットワークパラメータ、およびいくつかのサーバパラメータなどでモバイル自体を構成する。モバイルは、対応するホストとの通信を開始し、あるポリシに基づくこれの通信中のある時点において、モバイルが移動するものと判断する。よって、モバイルは、いくつかの異なるやり方でＡＩＳプロセスを開始する。モバイルは、問い合わせを行うとき、常に、これの場所情報をルックアップキーとして使用する。場所情報は、アクセスポイントのＭＡＣアドレス、地理的アドレスまたは他の任意の都市アドレスとすることができる。アクセスポイントのＭＡＣアドレスがルックアップキーとして使用されるとき、モバイルは、（ｉ）モバイルがアクセスポイントの無線到達範囲内にある場合にはビーコンフレームをリッスンすることによって、または（ｉｉ）再帰が、方法（ｉ）に基づいてモバイルに知られているアクセスポイントのＭＡＣアドレスを指定することから開始する問い合わせ手順を再帰的に行うことによって、ＭＡＣアドレスを獲得することができる。

サーバは問い合わせを取得し、問い合わせの種類に基づいて求められた属性のリストの報告を返す。クライアントがＧＰＳを装備している場合、クライアントは、常に、所望のネットワーク情報を検索し、獲得するための情報の一部として、自己の場所を見出し、どこに移動しようとするか判定し、よって、範囲を提供することができる。

図６に関しては、ネットワーク探索、問い合わせおよび応答のための動作のプロトコル交換と順序を示す図である。

図７および８には、モバイルが、そこに移動する可能性を有する近隣のサーバとルータのアドレスを取得することができるように、前もって近隣のサーバ／ルータを探索するクライアントのシナリオが示されている。図７と図８では、それぞれ、モバイルの地理座標の範囲とアクセスポイントのＭＡＣアドレスが、問い合わせのルックアップキーとして使用される。ネットワーク探索プロセスは、前もって、近隣のサーバ、ルータおよびアクセスポイントを探索するのに役立つ。前もってサーバを探索することによって、事前認証を行うことができ、よって、移動時のハンドオフ時間が速まる。モバイルは、目下、アクセスポイントＡＰ０に接続されており、モバイルがそこに移動する可能性を有する３つの近隣ネットワークＤ１、Ｄ２およびＤ３を有する。よって、モバイルは、特定のキーを用いてＡＩＳサーバに問い合わせることができ、保護されたハンドオフを準備するためにやりとりすることのできるドメインＤ１、Ｄ２およびＤ３内の近隣のＡＰ、サーバおよびルータに関する情報を取得することができる。以下の段落に、モバイルが起動した後の動作シーケンスを示す。

１）モバイルが起動し、特定のアクセスポイントに接続する。モバイルは、ＤＨＣＰやＰＰＰなどを介し、ＩＰアドレス構成手順によってＩＰアドレスを獲得する。ＤＨＣＰサーバまたはＰＰＰサーバは、様々なＩＰアドレスを有し得る。地理座標がルックアップキーとして使用されるときには、地理座標の範囲がこれらのＩＰアドレスと関連付けられ、ＩＰアドレス構成手順においてＩＰアドレスと一緒にモバイルに配信される。ありとあらゆるモバイルがＧＰＳを装備しているとは限らないことが想定される。モバイルが自己の地理座標（Ｒ０）を知っており、地理座標がルックアップキーとして使用される場合には、モバイルは、これの地理座標をルックアップキーとして使用することもできる。特定の区域のＡＩＳサーバのＩＰアドレスは、ＩＰアドレス構成手順の間に、またはＤＮＳを使って提供できる。

２）また、近隣のセルが異なるドメインに属することもあり得る。ＤＨＣＰ構成から、モバイルは、これの現在のドメイン（「att.com」や「sprint.com」など）を探し出すことができる。また、獲得されたネットワーク要素のＩＰアドレスから、逆ＤＮＳルックアップを使って近隣領域のドメイン名を探し出すこともできる。

３）モバイルは、これの現在接続されているＡＰとアクセスルータを使って、例えば以下のように、ＡＩＳサーバに要求を出すことができる。

ａ．要求は、モバイルが、条件（地理範囲［Ｒ１−Ｒ２］内や「１マイル以内」など）を指定して、特定の場所（地理的場所Ｒ０やＡＰ０のＭＡＣアドレスなど）について検索しようとするネットワーク情報の種類（ｔｙｐｅ＝“ＰＡＮＡ認証サーバ”、“ルータ”など）のリストを含む。条件は、モバイルの速度またはモビリティパターンに基づいて決定できる。

ｂ．ＡＩＳサーバは、別個にデータが取り込まれている独自のデータベースに問い合わせることによって、要求で指定された条件を満たすネットワーク情報（サーバとルータのＩＰアドレス、ＡＰのＭＡＣアドレスなど）のリストを返す。

ｃ．この情報から、モバイルは、モバイルが移動する可能性が高いネットワークのリストを有し、よって、時間制約の事前認証および／または事前対応型ＩＰアドレス獲得を行う。

図７に関しては、地理座標ベースのネットワークサービス探索の例を示す図であり、図８に関しては、ＡＰのＭＡＣアドレスベースのネットワークサービス探索の例を示す図である。

ＡＩＳが提供することのできる、データベース問い合わせのさらに別の機能がある。例えば、モバイルに提供されるべきネットワーク情報を選択するのに使用される基準は、モバイルによって指定されても、ＡＩＳサーバによって指定されても、両方のエンティティによって指定されてもよい。ＡＩＳサーバが基準を指定すると、モバイルのプロファイルが基準として使用できる。この場合、ＡＩＳは、高級のＡＩＳサービスに加入しているモバイルに、低級のＡＩＳサービスに加入しているモバイルよりも詳細なネットワーク情報を提供してもよい。

３．３．３ ピアツーピア型モデル
ピアツーピア型モデルは、情報格納と検索のための情報サーバに依存しない。代わりに、各モバイル端末が情報サーバとして働く。本明細書では、事前対応型ブロードキャストや設定範囲マルチキャストなど、２つのピアツーピアベースのモデルについて述べる。

提案するピアツーピア型モデルでは、
ネットワーク間を移動する各モバイルが、在圏したネットワークに関する情報を、特定の期間にわたってこれのローカルキャッシュに保持する。

モバイルの各近隣機器は、近隣ネットワークに関する異なる情報を有する。

以下に２つの手法を示す。

設定範囲マルチキャスト手法
各スカウトが、これらの局地的なマルチキャストアドレスＭに関する在圏ネットワークの知識を、ある設定範囲と、各スカウトがこれをキャッシュに保持しようとする時間量と共に告知する。

ネットワークの近接度と移動の確率に基づき、モバイルは、指定されたピアとやりとりしてネットワークの詳細を取得する。

注：いくつかの例では、スカウトは、このスカウト自体に情報を与えることもあり、情報を有する別のスカウトを指し示すこともある。

再帰的ブロードキャスト手法
各モバイルが再帰的にブロードキャストを行って、ネットワーク内の特定のネットワークに関する情報を探し出す。

ブロードキャストは、自己のサブネットを超えて行うことができる。

図９に関しては、ピアツーピア型に基づくネットワーク探索機構の例を示す図である。このアーキテクチャには情報サーバがなく、モバイルは、ネットワーク内のピアに問い合わせることによってこの他のネットワークに関して探索を行うことができる。これは、モバイルが他のネットワークに関する多くの情報を運び、これを、特定の期間にわたってキャッシュに保持するという前提に基づいて動作する。モバイルは、他のネットワークに移動しようと決定し、他のネットワークに関する情報を獲得する際に、先回りしてこの情報を問い合わせることができる。モバイルは、モバイルが、これのピアとやりとりし、この情報を抽出することができるという前提に基づいて動作する。場合によっては、モバイルとこれのピアの間である種のセキュリティアソシエーションを確立する必要もあり得る。

図１０に関しては、設定範囲ベースのマルチキャストシステムを示す図である。他方、図１１に関しては、再帰的ブロードキャストシステムを示す図である。

３．３．４ セキュアな事前認証への適用可能性
本明細書で述べるネットワーク探索機構は、例えば、以下のシナリオを含む、異なるアクセスネットワーク間でのこの種のハンドオーバすべてに役立ち得る。

８０２．１１ネットワークと８０２．３ネットワークの間のハンドオーバ
８０２．３ネットワークと８０２．１６ネットワークの間のハンドオーバ
８０２．１１ネットワークと８０２．１６ネットワークの間のハンドオーバ
８０２．１１ネットワークと８０２．１１ネットワークの間の、ＥＳＳをまたぐハンドオーバ
８０２．３ネットワークとセルラネットワークの間のハンドオーバ
８０２．１１ネットワークとセルラネットワークの間のハンドオーバ、および／または
８０２．１６ネットワークとセルラネットワークの間のハンドオーバ
好ましい実施形態では、探索手法は、異種混交と同種両方のハンドオフシナリオに適用することができる。

同種のシステム間の移動
単一インターフェース（８０２．１１、ＥＥＳ間など）
複数インターフェース（８０２．１１、ＥＥＳ間など）
異種混交ネットワーキングシステム間の移動は常にデュアルモードである。

８０２．３、８０２．１１
８０２．１１、ＣＤＭＡ／ＧＳＭ（セルラ）
セルラネットワーク間（ＣＤＭＡ、ＧＳＭ）
８０２．１１、８０２．１６、８０２．２０
８０２．１１、回路交換
以下の項では、ネットワーク探索が、どのようにして、事前対応型ハンドオフと保護された事前認証の機構に役立つように統合できるかを示す具体的なシナリオについて論じる。図１２は、２つの状態、すなわち近隣ネットワークの探索とシームレスなハンドオフの間のリンクを示す図である。具体的には、図１２には、ネットワーク探索とセキュアでシームレスなハンドオフの統合が示されている。

事前認証機構との統合：
図１３に関しては、統合された流れ（ネットワーク探索＋事前認証）の例を示す図である。

モバイルがネットワーク間を移動する際、事前対応型ハンドオフのプロセスは、主に、２つの段階を含む。第１段階は、モバイルが移動しようとしているネットワーク内の次のホップルータ、ＤＨＣＰサーバ、ＰＡＮＡ認証エージェント、ＡＡＡサーバなどの近隣要素を探索することを伴い、第２段階は、近隣ネットワーク内のＰＡＮＡ認証エージェントとの、保護された事前認証に基づくセキュリティアソシエーションをセットアップすることを伴う。また、この保護された事前認証の間に、モバイルは、次のサブネット内のＤＨＣＰサーバからアドレスを獲得することもできる（これは、複数のＩＰホップにわたってＤＨＣＰを実行することを意味しない）。保護された事前認証を有することによって、モバイルは、新しいサブネットに移動した後で、セキュリティアソシエーションのセットアップに時間を費やす必要がなくなる。また、ローカルで利用可能な次のサブネットのＩＰアドレスを有することによって、モバイルは、標準のＤＨＣＰプロセスを使ってアドレスを取得するのに要する時間も回避できるが、ＤＨＣＰ ＩＮＦＯＲＭを使って他のすべての構成パラメータを獲得してもよい。ローカルで利用可能なＩＰアドレスを有することによって、ＡＲＰチェックを含むＤＨＣＰプロセスに要する時間が回避される。

３．４ ネットワーク探索プロセス
このデータベースは、集中型とすることも、分散型とすることも、ピアツーピア型とすることもできる。本発明では、このデータベースにデータを取り込むいくつかのやり方を定式化している。このデータベース構造は、例えば、ＲＤＦ形式とする。モバイルは、ＳＯＡＰ／ＨＴＴＰ機構を使って、データベースから特定のサービスを提供するある種のネットワーク要素を問い合わせる。例えば、モバイルは、特定のアクセスポイントが接続されているサブネット内のルーティングサービスまたはＰＡＮＡサービスを提供するネットワーク要素のリストを取得するよう求める問い合わせを行うことができる。特定のアクセスポイントは、これのＭＡＣアドレスによって識別され得る。第２層リンクの品質、保護能力、インデックスのように機能し得るローミング契約など、他の種類の情報があってもよい。集中型データベースモデルでは、報告エージェントベース、ＡＡＡベース、エンドシステムベースなど、３つの異なる手法を使用することを予定している。報告エージェントベースの手法では、各報告エージェントが、ＳＮＭＰ ＭＩＢを使って、必要な情報を集中型データベースに特定の形式で取り込むことができる。各ドメインのＡＡＡクライアントは、モバイルとＡＡＡサーバにアクセスすることができるため、データベースサーバに必要な情報を適切に取り込むことができる。エンドシステム支援型の手法は、モバイルがネットワーク間を移動する間に構築される知識を利用する。モバイルは、あるネットワークから別のネットワークに移動する際、ネットワーキング要素に関する情報を収集し、集中型データベースに報告する。ピアツーピア型モデルでは、集中型データベースはないが、各モバイルが、最近在圏したばかりのネットワーク要素のリストを特定の期間にわたって保持し、設定範囲ベースのマルチキャストでこれらの能力と知識をパブリッシュする。あるネットワーク内のモバイルは、この能力を問い合わせ、必要な情報を有する特定の近隣機器とやりとりすることができる。

保護された事前認証は、モバイルと次のサブネット内のＰＡＮＡサーバの間でセキュリティアソシエーションを確立し、次のサブネットからＩＰアドレスを獲得することを伴う。図１３に、アクセスネットワーク間の遷移時の様々な要素間のプロトコル対話を示す。モバイルは、アクセスネットワークＡからアクセスネットワークＢへの移動を行う。アクセスネットワークＡとＢは、２つの異なる管理ドメインに存在し得る。最初に、モバイルＭＮは、これに割り当てられたアドレスＩＰ０を有する。モバイルは、移動しようとする際に、近隣のＡＰからいくつかのビーコンを受動的にリッスンする。これらのＡＰのビーコンは、近隣ネットワーク内のＡＰのＭＡＣアドレスを含む。モバイルは、アクセスポイントのＭＡＣアドレスを識別子として使って、近隣アクセスネットワーク内のネットワーク要素を探索する。これは、ＡＩＳサーバと対話する、ＳＯＡＰやＨＴＴＰなどのアプリケーション層プロトコルを使って、モバイルが、普通は、近隣のアクセスネットワークまたは目標アクセスネットワークの１つに移動した後で対話するはずのネットワーク要素のＩＰアドレスを突き止めることによって達成される。これらのネットワーク要素には、近隣ネットワーク内のアクセスルータ、ＰＡＮＡ認証エージェントが含まれる。保護されたハンドオフを行うために、モバイルは、普通は、近隣のアクセスネットワーク内の目標アクセスルータ（ＴＡＲ）と同じ場所に位置するＰＡＮＡ認証エージェントに、ＰＡＮＡメッセージを送る。この時点において、ＴＡＲとモバイルの間にＩＰｓｅｃトンネルをセットアップするためにＩＫＥシグナリングが行われる。このトンネルがセットアップされるのは、データがトンネリングされ、保護されるようにするためである。トンネルセットアップの一部として、目標アクセスネットワーク内にあるＤＨＣＰサーバからＩＰアドレスが獲得される。ＤＨＣＰサーバは、これのＩＰアドレスプールからＩＰアドレス（ＩＰ１など）を分配する。ＤＨＣＰサーバは、ＴＡＲがモバイルのプロキシＤＨＣＰクライアントとして働くＩＫＥｖ２を介してモバイルにＩＰアドレスを渡す前に、ＡＲＰを実行しようとしてもよい。このＤＨＣＰを介してＴＡＲに渡されるＩＰアドレスは、次いで、ＩＫＥｖ２の構成ペイロードとして運ばれ、最終的に、ＩＰｓｅｃトンネル内部アドレスとしてモバイルに割り当てられる。この時、モバイルは、２つのＩＰアドレス、すなわちＩＰ０とＩＰ１を有する。このモバイルにおいてＩＰｓｅｃトンネルが論理トンネルインターフェース（すなわちｉｐｓｅｃ０）として実施されるとき、モバイルは、２つのアドレス、すなわち物理インターフェースのＩＰ０（すなわちｅｔｈ０）と論理トンネルインターフェースのＩＰ１を有する。このとき、モバイルは、対応するホスト（ＣＨ）またはホームエージェントに、対応付け更新を送る。ＣＨまたはホームエージェントは、新しいデータをモバイルの新しいＩＰアドレスＩＰ１に送る。ＣＨからＩＰ１に向けられた新しいデータは、ＴＡＲによって取り込まれ、確立されたばかりのＩＰｓｅｃトンネルによってトンネリングされる。次に、モバイルは、横断して新しいアクセスポイントＡＰ２に接続する際、旧いＩＰｓｅｃトンネルを切断し、新しいアドレスＩＰ１をこれの物理インターフェース（すなわちｅｔｈ０）に割り当てるイベントトリガを取得する。

モバイルは、ローカルで割り当てられ得るＩＰアドレス獲得しているにすぎないため、モバイルは、新しいネットワークに移動する際に、ＤＮＳサーバ、ＤＨＣＰサーバといった他のサーバパラメータを構成することができるようにＤＨＣＰ ＩＮＦＯＲＭを行ってもよい。別の選択肢として、これらのパラメータは、モバイルが目標アクセスネットワークに移動する前に、モバイルとＴＡＲの間でＩＰｓｅｃトンネルを確立するＩＫＥｖ２シグナリングによって獲得されていてもよい。別の選択肢は、ＡＩＳを介してパラメータを獲得し、これらをモバイルのキャッシュに格納するものである。

よって、モバイルが前のサブネットにあり、トンネルがセットアップされるときに、モバイルには、以下のような２つのアドレスが割り当てられている。

ｅｔｈ０：ＩＰ０
Ｉｐｓｅｃ０：ＩＰ１（トンネルインターフェース）
ＩＰ０は現在のネットワークにおけるアドレスであり、ＩＰ１は、近隣ネットワークからのアドレスである。

注：ＩＰｓｅｃトンネルがモバイルで論理トンネルインターフェースとして実施されないとき、ＩＰ１は、ＩＰｓｅｃ ＳＡＤ（セキュリティアソシエーションデータベース）にバインドされるはずである。

モバイルは、目標アクセスネットワークに移動した後で、以下のようなアドレス割り当てを有することになる。

ｅｔｈ０：ＩＰ１
よって、本発明では、ローカルプロセスを使って、ＩＰアドレスＩＰ１をインターフェースｅｔｈ０に設定する。

考慮事項
本開示に基づけば、当分野の技術者は、特に、以下の各項を考慮に入れたシステムを実施することができる。

１．モバイルが目標アクセスネットワークに移動する際に必要とされる種類のトリガ機構。

２．モバイルが目標アクセスネットワークに移動する際に既存のトンネルをどのようにして分離すべきか。

３．複数のＩＰホップにわたるＰＡＮＡ認証をどのようにして処理すべきか。

ａ）複数ＩＰホップにわたって実行されるようにＰＡＮＡを変更する。

ｂ）保護されないＩＰトンネルを介してＰＡＮＡを実行する。

４．モバイルが、ネットワークを変更しようとする際に、いつネットワーク探索プロセスを開始すべきか。

５．ＤＨＣＰを使ってＩＰｓｅｃトンネル内部アドレスをどのようにして動的に割り当てるべきか（ＤＨＣＰサーバとＩＰｓｅｃゲートウェイの間の詳細な対話が定義されなければならない）。

図１４に関しては、モバイルに関連付けられる様々なモジュールを示す流れ図である。図１４には、ネットワーク探索と事前認証の流れ図が示されている。いくつかの実施形態では、ネットワーク探索と事前認証が、事実上、以下のようにして、複数のインターフェースを有するモバイルに使用できる。

モバイルは、常に、複数のインターフェースのうち１つだけを活動化する。他のインターフェースは、電池の節約などのために非活動化される。無線条件および／または他の基準に応じて、モバイルは、あるインターフェースから別のインターフェースに切り換わり、これは、モバイルが活動化インターフェースから切り換わる非活動化インターフェースのための第２層接続点を動的に探索することを必要とする。

非活動化インターフェースは、これらの第２層接続点を探索するのに使用できないため、これらの接続点を探索するＡＩＳ手順は、現在活動化されているインターフェースを介して行われる。また、これらの接続点と関連付けられている上位層ネットワーク要素に関する情報も、ＡＩＳ手順で探索される。

これらの接続点と関連付けられる上位層ネットワーク要素が発見された後で、モバイルは、活動化インターフェースを介して非活動化インターフェースの事前認証手順を行って、非活動化インターフェースを活動化する前に、モバイルと第２層接続点の間のセキュリティアソシエーションを確立し、ＩＰアドレスなど必要な構成パラメータを事前構成することができる。

非活動化インターフェースが活動化されると、必要なブートストラップ手順の大部分が、インターフェースを活動化する前に完了しているため、インターフェースを活動化するブートストラップ手順が速まる。

複数のインターフェースを有するモバイルのネットワーク探索の別の使用法は以下の通りである。

モバイルは、無線ＬＡＮインターフェースとセルラインターフェースを有する。モバイルは、常に、セルラインターフェースを活動化しており、セルラインターフェースを介したＩＰ接続を有する。無線ＬＡＮインターフェースは、常に活動化されていても、モバイルのユーザによる要求に応じて活動化されてもよい。

無線ＬＡＮインターフェースは、（１つ以上の）アクセスポイントを見つけると、この（これらの）アクセスポイントを介して接続されるネットワークに関する詳細情報を獲得するためにセルラインターフェースを介してＡＩＳ手順を行うことができる。獲得された情報は、モバイルによって、接続すべきアクセスポイントを選択するのに使用できる。

４．スキーマ設計
ＡＩＳは、ルータとアクセスポイントのどんな変更も行う必要なしに、アクセスポイントとルータの既存の規格を使用するフレームワークを提供する。本発明のデータベーススキーマは、ＸＭＬ、ＲＤＦおよびＳＯＡＰを使用する。ＲＤＦデータベースは、多数のネットワークまで拡張することのできるように分散方式で構築できる。また、ＬＤＡＰはツリーベースのデータ構造だけを扱うが、ＲＤＦは、任意の相互接続されたデータ構造を扱うことができる。ＲＤＦは、データ自体のみならず、問い合わせスキーマも提供することができる。

図１５に、ネットワーク探索の様々なコンポーネントとコンポーネント間の対話を示す。特に、図１５には、データベースエンジンの様々なコンポーネント間の対話が示されている。

図１７（１）から１７（１０）までを参照して、ＸＭＬ形式を使用するネットワーク探索のＲＤＦスキーマを説明する。

５．デモシナリオ
本項では、説明のためのネットワーク想定とデモシナリオについて述べる。以下は、単に、いくつかの説明的、非限定的試験例を示すものにすぎない。

ネットワーク想定
４つの異なるサブネットを作成する（４つの異なるネットワークを想定する）。

４つの異なるエッジルータ（ＥＲ）を関連付ける。

４つの異なるアクセスポイント（ＡＰ）。

４つの異なるＰＡＮＡサーバ（ルータと共存していてもよい）。

モビリティサーバを定義する。

各ネットワーク要素が、これに関連付けられた特定の地理座標を有する。

モビリティサーバ上のデータベースへのデータ取り込み、即ち
各ネットワークにＳＮＭＰ問い合わせエージェント（ＲＡ）を有する。

各ＲＡがネットワーク要素を問い合わせ、これらの情報をモビリティサーバ（Ｓ）にプッシュする：
モビリティサーバは特定の形式でデータベースを保持する、即ち
ネットワークに従う
サービスの種類
地理座標範囲［ｒ１、ｈ１］
代替として、データベースに、以前これらのネットワークに在圏したモバイルによってデータが取り込まれてもよい。

モビリティサーバ上のデータベースの問い合わせ：
モバイルに電源が投入され、ＤＨＣＰサーバからアドレスを取得する。

ＤＨＣＰサーバから自己位置（ｒ０，ｈ０）を探し出す。

ＤＮＳに対して自己を更新する。

ＤＨＣＰからまたは事前に用意されたモビリティサーバアドレスを知る。

ある特定の種類のサービスを用いて問い合わせを行い、範囲を提供する。

サーバのリストを取得し、移動しようとする際に、各サーバと時間制約の事前認証を行う。

高速ハンドオフがしかるべく行われる。

図１６（Ａ）〜（Ｃ）に関しては、かかるデモラボ内で実施される説明のためのデモセットアップを示す図である。

６．結論
本開示では、例として、特に、少数のアーキテクチャと、ネットワーク探索プロセスのためのアプリケーション層方式を提示する。また、本開示では、特に、これらの技法が、モバイルが異種混交アクセスネットワーク間を移動する間に事前対応型の保護されたハンドオフを提供するのにどのように役立ち得るかについても述べる。

８０２．２１の下でのＭＩＨ機能
ＭＩＨ機能の主な役割は、ハンドオフを円滑に行わせ、他の規格または独自の実現形態によって記述されるハンドオーバ決定の責任を負うネットワーク選択エンティティまたはモビリティ管理エンティティにインテリジェンスを提供することである。ＭＩＨ機能は、イベントサービス、コマンドサービスおよび情報サービスの助けを借りて、ネットワーク選択エンティティを支援する。ネットワーク選択エンティティおよびハンドオーバを制御するハンドオーバポリシは、ＭＩＨ機能の適用範囲外である。特定のハンドオーバポリシの記述およびネットワーク選択エンティティの詳細もまた、８０２．２１規格の適用範囲外である。

ＩＥＥＥ８０２．２１規格は、異種混交アクセスリンク間のハンドオーバを強化するサービスを定義する。これは、ハンドオーバ検出、ハンドオーバ開始およびＭＩＨユーザによる候補リンク選択に関連するリンク層インテリジェンスを提供することにより、ハンドオーバプロセスを円滑化することを通じて達成される。

メディア独立のイベントサービス（ＭＩＥＳ）は、リンク特性、リンク状況およびリンク品質の動的変更に対応するイベント分類、イベントフィルタリングおよびイベント報告を提供する。

メディア独立のコマンドサービス（ＭＩＣＳ）は、ＭＩＨユーザがハンドオーバとモビリティに関連するリンク挙動を管理し、制御することができるようにする。

メディア独立の情報サービス（ＭＩＩＳ）は、サービス提供する、周辺のネットワークによって提供される特性とサービスに関する詳細を提供する。この情報は、効果的なシステムアクセスおよび効果的なハンドオーバ決定を可能にする。

上記のサービスは、ＭＩＨユーザのモビリティ管理とハンドオーバプロセスを円滑に行わせるために、メディア独立のハンドオーバ機能（ＭＩＨＦ）によってサポートされる。ＭＩＨ機能は、複数の異種混交アクセス技術からのリンク層状態情報を、モビリティ管理プロトコルスタックの上位層への統一された表示に収束させる。

８０２．２１規格案は、特に、以下の一般設計原理に基づくものである。

メディア独立のハンドオーバ（ＭＩＨ）機能は、モバイルノードと、モビリティサポートを提供するネットワーク要素両方のモビリティ管理プロトコルスタックにおけるシム層として論理的に定義される。ＭＩＨは、ハンドオーバ決定に役立つ支援促進機能である。上位層はＭＩＨからの入力とコンテキストに基づいて、ハンドオーバ決定とリンク選択を行う。ハンドオーバが行われるべきであるという認識を容易にすることが、ＭＩＨ機能の主要な目標の１つである。また、どのようにして効果的なハンドオーバ決定を行うべきかに関する情報の探索も、重要な構成要素である。

ＭＩＨ機能は、上位層に抽象化されたサービスを提供する。この意味で、ＭＩＨは、上位層への統一インターフェースを提供する。この統一インターフェースによって公開されるサービスプリミティブは、異なるアクセスネットワークの技術特有のプロトコルエンティティから独立である。ＭＩＨ機能は、技術特有のインターフェースを介してモビリティ管理プロトコルスタックの下位層とやりとりする。下位層とのＭＩＨインターフェースの規格は、一般に、８０２．２１の適用範囲内に含まれない。かかるインターフェースは、すでに、ＩＥＥＥ８０２．１、ＩＥＥＥ８０２．３、ＩＥＥＥ８０２．１１、ＩＥＥＥ８０２．１６、３ＧＰＰ、３ＧＰＰ２といった、個々のアクセス技術に関する規格内でサービスアクセスポイント（ＳＡＰ）として規定されている。

メディア独立の情報サービス（ＭＩＩＳ）は、ＭＩＨＦ（メディア独立のハンドオーバ機能）エンティティが、ハンドオーバを円滑化するために地理的領域内に存在するネットワーク情報を探索し、獲得するためのフレームワークと対応する機構を提供する。ＭＩＩＳは、主に、情報要素（ＩＥ）の集合、情報構造およびこれの表現、ならびに情報転送の機構の問い合わせ／応答の種類を提供する。これは、イベントサービスのための情報転送の非同期プッシュモデルと対照をなす。情報は、ＭＩＨ機能（ＭＩＨＦ）エンティティ内に格納されてもよく、局内のＭＩＨがそこから情報にアクセスすることのできる何らかの情報サーバ内にあってもよい。

情報は、上位層のみならず、下位層を介しても利用可能とされ得る。情報は、セキュアなポートとセキュアでないポートの両方を介してＬ２で利用可能となる。スキーマの構造と定義は、ＸＭＬなどの高水準言語で表され得る。

また、情報サービスは、近隣機器報告など、静的情報へのアクセスも可能にする。この情報は、ネットワーク探索に役立つ。また、サービスは、異なるネットワークとのリンク層接続を最適化できる動的情報へのアクセスも可能となる。これには、チャネル情報、ＭＡＣアドレス、セキュリティ情報などのリンク層パラメータが含まれ得る。また、ネットワーク内の利用可能な上位層サービスに関する情報も、モバイル端末が実際に任意の特定のネットワークに接続する前に、より効果的なハンドオーバ決定を行うのに役立ち得る。

メディア独立の情報サービスは、ＸＭＬやＡＳＮ．１などの標準化形式を使って、異なる技術にまたがってこの情報を表す共通の（またはメディア独立の）方法を指定する。

ＭＩＩＳは、８０２．２１ＭＩＩＳサービスがどのようにして実施されるかに応じて、任意の単一Ｌ２ネットワークから、ある地理的領域内のすべての異種混交ネットワークに関するこの情報にアクセスさせることができる。ＭＩＩＳは、既存のアクセスメディア特有のトランスポートとセキュリティ機構、またはＬ３トランスポートとＬ３セキュリティ機構を利用して、情報へのアクセスを可能にする。通常、複数の種類のメディアで構成される異種混交ネットワークでは、異なる種類のメディアから情報を収集し、メディア間ハンドオーバ決定を円滑化するための統合されたビューを組み立てるのは、ハンドオーバ決定モジュールまたは上位層モビリティ管理である。

セルラネットワークなどいくつかのネットワークは、すでに、ブロードキャスト制御チャネルを介して、ある領域の近傍内にある近隣基地局のリストを検出する既存の手段を有する。他のＩＥＥＥグループは、類似の手段を定義し、クライアントが、ビーコン送信によって、またはＭＡＣ管理メッセージのブロードキャストによって、ある領域の近傍内の近隣アクセスポイントのリストを検出するのをサポートする。メディア独立の情報サービス（ＭＩＩＳ）は、異種混交ネットワーク環境全体の上位層モビリティプロトコル（ＨＬＭＰ）が、クライアントによる、地理的領域内に存在する複数の種類のネットワークの探索と選択を円滑に行わせるのに役立つ、統一フレームワークを提供する。より大きな視野での大きな目的は、上位層モビリティプロトコルが異種混交ネットワークの全体的視野を獲得して、これらのネットワークにまたがるローミング時のシームレスなハンドオーバを円滑に行わせるのを支援することである。

サービスアクセスポイント（ＳＡＰ）の定義と呼び出しの流れ：
図１８（１）から１８（１２）を参照すると、これらの図には、サービスアクセスポイント（ＳＡＰ）の定義と呼び出しの流れに関連するいくつかの説明的実施形態および態様が示されている。これに関して、図１８（１）から１８（１２）には、以下のものを示す複数の図が含まれる。

ａ）メディア独立のハンドオーバ（ＭＩＨ）の動作の流れ（図１８（１））、
ｂ）ＳＡＰを有するＭＩＨ機能モデル（図１８（２））、
ｃ）下位層（下位ＳＡＰ）からのローカルトリガ（図１８（３））、
ｄ）下位層（下位ＳＡＰ）へ／からの機能プリミティブ（図１８（４））、
ｅ）上位層（上位ＳＡＰ）へ／からの機能プリミティブ（図１８（５））、
ｆ）（ネットワークへ／からの）リモート機能プリミティブ（図１８（６））、
ｇ）８０２．Ｘから８０２．Ｘへ（単一Ｉ／Ｆ）のハンドオーバ呼び出しの流れ（図１８（７）から１８（８））、
ｈ）セルラ／８０２．Ｙと８０２．Ｘの間のハンドオーバ呼び出しの流れ（図１８（９）から１８（１０））、
ｉ）ＭＩＨ機能と３ＧＰＰプリミティブの間のマッピング（図１８（１１））、および
ｊ）ＭＩＨ機能と８０２．１１プリミティブの間のマッピング（図１８（１２））。

図１８（１）から１８（１２）に示す実施形態の様々な特徴と態様、ならびに様々な潜在的変更および／または適応は、本開示に基づけば、当分野の技術者には評価され、理解されるはずである。また、参照により、これの開示全体が、あたかも本明細書に全部が引用されたかのごとく本明細書に組み込まれる、２００４年１１月８日に提出されたように見受けられる、Yogesh Bhatt、Ajoy Singh、Nat Natarajan、Madjid Nakhjiri、Alistair Buttar、Lach Hong-Yon、「ＩＥＥＥ８０２．２１メディア独立のハンドオーバ、ＤＣＮ：２１−０４−０１７０−００−００００、表題：ＩＥＥＥ８０２．２１ メディア独立のハンドオーバ解決法提案（IEEE802.21 MEDIA INDEPENDENT HANDOVER, DCN:21-04-0170-00-0000, Title:IEEE802.21 Media Independent Handover Solution Proposal）」も参照されたい。また、参照により、これの開示全体が本明細書に組み込まれる、２００４年１１月１７日に提出されたように見受けられる、Xiaoyu Liu、Youn-Hee Han、Vivek Gupta、Soo-Hong Park、Sungjin Lee、Hyungkyu Lim、Chihyun Park、Chongwon Kim、「ＩＥＥＥ８０２．２１メディア独立のハンドオーバ、ＤＣＮ：２１−０４−０１７１−０１−００００、表題：サムスンからのＩＥＥＥ８０２．２１への最初の提案（IEEE802.21 MEDIA INDEPENDENT HANDOVER, DCN:21-04-0171-01-0000, Title:Initial Proposal to IEEE802.21 from SAMSUNG）」も参照されたい。

ＭＩＨ機能と情報サービスのための説明的提案：
図１９（１）〜１９（１３）は、２００５年１１月５日に出願された前述の仮出願の添付書類Ａに記載されているメディア独立のハンドオーバ（ＭＩＨ）機能と情報サービスに関連するいくつかの説明のための実施形態と態様を示す図である。これに関して、この情報を以下に組み込む。

提案の範囲：
図１９（１）〜１９（１３）は、８０２．２１要件文書による提案の一部に関連するものである。

以下の２つの重要な機能をカバーする。

ＭＩＨ機能
情報サービス
特定のハンドオーバシナリオを記述する。

提案の概要：
ブートストラップ問題：
機器が起動するとき。

機器がいくつのインターフェースを有するかに左右され得る。

ＭＩＨ機能：
汎用ＭＩＨプリミティブ
セキュアでシームレスなハンドオーバのためのプリミティブおよびこれらの上位層とのマッピング
セキュアなハンドオーバ解決法
情報サービス：
探索、検出および選択：
機器がハンドオーバ最適化のために必要とする情報。

情報サービスモデル。

前提およびシナリオ：
前提：
異種混交ネットワークのための複数の無線インターフェース。

同種ネットワークのための単一の、または複数の（１１ａ／ｂ／ｇ）インターフェース。

本例で対処されるシナリオ：
８０２．１１からセルラへ。

８０２．１１から８０２．３／ＷｉＭＡＸへ。

８０２．１１から８０２．１１へ。

単一無線インターフェースシナリオ：
単一のＩＥＥＥ８０２．ｘｘインターフェースを有するモバイルノードが、複数のサブネットと複数の管理ドメインの間でローミングを行い得る。

Ｌ２だけを介して獲得される情報に基づくＭＩＨには限界がある。

ＭＩＨは、上位層からの情報を必要とし得る。

可能な効率的サブネット間およびドメイン間ハンドオフ。

単一無線インターフェースローミングシナリオ：
図１９（１）を参照すると、単一無線インターフェースローミングシナリオが示されている。

複数無線インターフェースシナリオ：
複数のインターフェースを有するモバイルノードが、不使用のインターフェースを非活動化しようとし得る。

モバイルノードが移動する際に、無線条件に応じて、非活動化インターフェースが活動化される必要が生じ得る。

非活動化インターフェース自体は、これらのアクセスポイント／基地局を探索することができない。

非活動化インターフェースだけに依存する情報サービスにはいくつかの限界がある。

ＭＩＨは、さらに、非活動化インターフェースを、現在活動化されているインターフェースから切り換わる対象となる候補とみなし得る。

高速インターフェース活動化が、ＭＩＨの要件となり得る。

複数無線インターフェースローミングシナリオ：
図１９（２）を参照すると、複数無線インターフェースローミングシナリオが示されている。

ブートストラップのシナリオ、問題および要件：
ブートストラップのシナリオ：
機器の電源が投入され、インターフェースがネットワークの有無を検出する。

以下の２つの異なる場合：
機器がある在圏ネットワークで最初に起動する。

機器が再起動する。

前に接続があった（ネットワークの先験的知識）。

複数のプロバイダの存在：
類似のネットワーク（ＷＬＡＮネットワークのみなど）。

異なるネットワーク（ＷＬＡＮ、３Ｇなど）
いくつかのブートストラップの問題：
アクセスが許可されなければ、機器にネットワークに関して限られた情報しかないこともある。

機器に、在圏ネットワークの事前知識が全くないこともある。

複数のネットワークが、特定の区域内で有効範囲を持たないこともある。

上位層情報がキャッシュされ、または事前構成されない限り、機器に上位層情報がないこともある。

機器に、ネットワークに接続するための適切なセキュリティパラメータがないこともある。

ブートストラップ解決法要件：
アーキテクチャ構成要素が、別個にブートストラップに対処する必要がある。

各提案の損得が、セキュリティ要求に基づいて評価される必要がある。

この解決法の例の能力：
提案する解決法の例は、ブートストラップ問題に対処しない。

ＭＩＨ機能：
ネットワーク探索。

セキュリティ。

モビリティ／ハンドオーバ。

サービス品質。

電力管理。

その他。

汎用ＭＩＨ機能モデル：
図１９（３）に汎用ＭＩＨ機能モデルを示す。

ＭＩＨ機能モデル（情報サービス、モビリティおよびセキュリティ）：
図１９（４）にＭＩＨ機能モデル（情報サービス、モビリティおよびセキュリティ）を示す。

汎用ＭＩＨプリミティブ：
ネットワーク探索プリミティブ：
ネットワーク名。

ＩＰアドレス（ネットワーク要素、ＤＮＳ、ＳＩＰサーバ．．．、場所）。

ネットワーク／リンクの種類。

帯域幅。

ネットワークを使用するコスト。

セキュリティプリミティブ：
セキュリティ能力。

セキュリティパラメータ（キー、ＳＡ、．．．）。

アクセス特権。

ＱｏＳプリミティブ：
リンクの種類。

ＱｏＳレベル／マッピング。

帯域幅。

モビリティ／ハンドオーバ管理：
サポートされるモビリティ機能。

プロトコル、速度、リアルタイム非リアルタイム、．．．
ハンドオーバの種類。

ソフトハンドオフ、ハードハンドオフ、．．．
電力管理：
休眠時間、起動時間．．．
電力バジェット
ＭＩＨ動作の流れ：
図１９（５）にＭＩＨ動作の流れを示す。

ＭＩＨ機能：例：
ネットワーク探索。

getNetworkName()。

getIPaddress()。

gettypeofserver()。

getBandwidth()。

セキュリティ：
getkeyinformation()。

getsecurityprotocol()。

getauthenticationserver()．
セキュアでシームレスなハンドオーバ解決法：
この解決法は、事前認証（ＰＡ）の概念に基づくものであり、例えば、以下のように定義できる。

セッションとサービスのハンドオーバの前に、認証および許可を行うために、事前に上位層情報を獲得するモバイル支援型認証方式。

ＭＩＨ機能は、モバイルユーザに代わってこのプロセスを行う。

ＭＩＨ事前認証（ＭＰＡ）：
ＭＩＨ事前認証：
以下のために機能する、セキュアでシームレスなモビリティ最適化を提供する。

サブネット間ハンドオフ。

ドメイン間ハンドオフ。

技術間ハンドオフ。

複数のインターフェースの使用。

上位層（ネットワークなど）で新しい機構を定義する。

ＩＰアドレス変更をサポートする（ＭＡＣアドレスが変化しない第２層（Ｌ２）事前認証と異なる）。

ＭＰＡの機能構成要素：
１）事前認証
モバイルとモバイルがそこに移動し得るネットワークの間のセキュリティアソシエーション（ＳＡ）を確立するのに使用される。

また、確立されたＳＡに基づいてＬ２事前認証も使用可能となる。

２）事前許可
モバイルがそこに移動するネットワークに特有のコンテキストを確立するのに使用される。

（１）で作成されるＳＡは、許可手順をセキュリティ保護するのに使用される。

３）仮想ソフトハンドオフ（ＶＳＨ）
現在のネットワークのコンテキストを使い、事前許可されたコンテキストに基づいてＩＰパケットを送信／受信するのに使用される。

期待される結果：
図１９（６）に、いくつかの実施形態による、説明のための期待される結果の図を示す。

事前認証：
図１９（７）は、いくつかの説明のための実施形態における事前認証を示す概略図である。

事前許可：
図１９（８）は、いくつかの説明のための実施形態における事前許可を示す概略図である。

仮想ソフトハンドオフ（ＶＳＨ）：開始フェーズ：
図１９（９）は、いくつかの説明のための実施形態における仮想ソフトハンドオフの初期フェーズを示す概略図である。

ＶＳＨ：トンネリングフェーズ：
図１９（１０）は、いくつかの説明のための実施形態における仮想ソフトハンドオフのトンネリングフェーズを示す概略図である。

ＶＳＨ：完了フェーズ：
図１９（１１）は、いくつかの説明のための実施形態における仮想ソフトハンドオフの完了フェーズを示す概略図である。

情報サービス：
情報サービスとは何か？
情報サービスは、例えば、以下の様に定義できる：
ネットワーク探索：
機器が（１つ以上の）ネットワークに関する情報を収集するためのプロセス。

ネットワーク検出：
機器がネットワークに接続し、情報を収集するためのプロセス。

ネットワーク選択：
機器が（探索および検出によって収集された情報などから）適切なネットワークを選択するプロセス。

情報サービス解決法：
情報サービスのためのアプリケーション層機構（ＡＩＳ）：
ネットワーク探索は、ＸＭＬベースの技術を使って定義される。

Ｌ２およびＬ３トポロジ情報を検索する柔軟な方法。

情報サービスのためのアプリケーション層機構（ＡＩＳ）：
近隣ネットワークのネットワーキング要素に関する情報を提供するのに役立つアプリケーション層プロトコル。

情報は、例えば以下のような様々な層のネットワーキング要素に関するパラメータで構成できる。

アクセスポイントのＭＡＣアドレス、アクセスルータのＩＰアドレス、セキュリティモデル、ＱｏＳ。

情報は、場所情報をルックアップキーとして使って問い合わせできる。

場所情報は、アクセスポイント識別子、地理的アドレス、都市アドレスなどとすることができる。

情報は、ＭＩＨ事前認証（ＭＰＡ）を補強する。

リンク層不可知解決法を提供する。

管理ドメイン間を移動することができるようにする。

どんな変更も行わずにアクセスポイントとルータの既存の規格を使用するフレームワークを提供する。

ＸＭＬ、ＲＤＦ、ＳＯＡＰを使ったモジュール式の柔軟なデータベースを提供する。

ＲＤＦデータベースは、多数のネットワークにまで拡張される分散方式で構築できる。

ＬＤＡＰは、ツリーベースのデータ構造だけを扱うが、ＲＤＦは、任意の相互接続されたデータ構造を扱うことができる。

ＲＤＦは、データ自体のみならず問い合わせスキーマも提供する。

ネットワーク情報は、ネットワーキング技術が発展するに従って、これのデータ構造を頻繁に変更し得る。

情報サービスデータベース構築のための２つの基本的手法：
ネットワーク支援型データベース構築モデル。

モバイル支援型データベース構築モデル。

ＡＩＳとＬ２情報サービスの比較：
Ｌ２における情報サービスは、最初にＩＰ接続が利用できない初期ネットワーク接続に必要とされる。

Ｌ２における情報サービスにはいくつかの限界がある。

情報がビーコンでブロードキャストされる場合、情報は、多くの帯域幅を消費する。

モバイルは、情報サービスを提供するＡＰの無線到達範囲内にいる必要がある。

高速で移動するモバイルは、ネットワークの無線到達範囲に入る前にこの情報を必要とし得る。

複数インターフェースのモバイルは、活動中のインターフェースを介して非活動化インターフェースのＡＰを探索しようとし得る。

いくつかのリンク２プロトコル（８０２．３など）では、断片化がないために、サイズの大きいデータを処理するのが難しい。

ＡＩＳは、かかる限界を克服することができる。

ＡＩＳ支援型の保護されたシームレスなハンドオフ：
ＭＰＡを用いた保護されたシームレスなハンドオフは、以下のような近隣ネットワーキング要素から検索される情報に基づくものである。

ルータ、ＳＩＰサーバ、ＰＡＮＡ認証エージェントなど。

ネットワーク探索とセキュアでシームレスなハンドオフの統合を示す図１２も参照されたい。

情報問い合わせ例：
説明のための情報問い合わせ例を示す図１２を参照されたい。

ＡＩＳのためのＲＤＦスキーマ（部分図）：
図１９（１２）に、このスキーマの説明グラフを示す。

ＡＩＳのためのＲＤＦスキーマ（詳細図）：
図１９（１３）に、このスキーマの詳細な説明グラフを示す。

ハンドオーバシナリオ：
８０２．１１ネットワークからセルラネットワークへのハンドオーバ。

８０２．１１ネットワークから８０２．１１ネットワークへのハンドオーバ。

８０２．１１ネットワークから８０２．３ネットワークへのハンドオーバ。

情報サービススキーマの概要：
スキーマは情報の構造を定義する。スキーマは、８０２．２１情報サービスで、各情報要素の構造、ならびに、サポートされる異なる情報要素間の関係を定義するのに使用される。８０２．２１情報サービススキーマは、柔軟で効率的な情報問い合わせをサポートするためにＭＩＩＳを実施するあらゆるＭＩＨ機能によってサポートされる必要がある。８０２．２１情報サービスは、様々な情報要素とこれらの構造を定義する。様々なＩＥは、ネットワークスタックの下位層に関する情報、ならびに、異なるアクセスネットワークで利用可能な上位層サービスに関する情報を表す。スキーマは、１つの言語で定義され、複数の方法で表され得る。例としては、例えば、ＸＭＬ、８０２ＭＩＢで使用されるＡＳＮ．１、バリアント、あるいは異なる情報要素の単純なＴＬＶ表現などに基づくリソース記述フレームワーク（ＲＤＦ）が含まれる。

ＭＩＩＳスキーマは、２つの主要カテゴリに分類される。これらは、サポートすべきあらゆるＭＩＨに不可欠な基本スキーマと、任意選択で、ベンダ特有とすることのできる拡張スキーマである。

ＲＤＦスキーマ表現：
本項では、リソース記述フレームワーク（ＲＤＦ）を使ったスキーマの例を示す。３ＧＰＰＴＳ２３．２３４、「３ＧＰＰシステムから無線ローカルエリアネットワーク（ＷＬＡＮ）への相互接続；システム記述（3GPP system to Wireless Local Area Network (WLAN) inter-working; System description）」（参照文献［８］）も参照されたい。ＲＤＦは、情報を問い合わせるための問い合わせ言語として、ＳＰＡＲＱＬ（３ＧＰＰＴＳ２３．０６０「汎用パケット無線サービス（ＧＰＲＳ）；サービス記述；第２段階（General Packet Radio Service (GPRS); Service Description; Stage 2）」（参照文献［７］）参照）を使用する。ＲＤＦスキーマもＳＰＡＲＱＬもＸＭＬで表される。ＲＤＦスキーマは、式の集合の構造を定義し、任意の式の基礎構造は、それぞれが、主部、述部、目的部の３つからなるものの集合体である。ＲＤＦ／ＸＭＬというＲＤＦのＸＭＬ構文が、ＧＰＰ ＴＲ４３．９０１「Ａ／Ｇｂインターフェースへの汎用アクセスに関する実現可能性調査（Feasibility Study on Generic Access to A/Gb interface）」（参照文献［９］）で定義されている。

ＲＤＦには、例えば、以下の利点がある：
階層と非階層両方の情報構造をサポートする。

柔軟なデータ問い合わせを可能にする。

分散スキーマ定義を可能にする。

スキーマ定義を変更するのがより容易である。

以下で論じるように、ＭＩＩＳのＲＤＦスキーマ定義は、２つの部分、すなわち、基本スキーマと拡張スキーマを有する。基本スキーマは、更新がサポートされていない。ＭＩＨエンティティには、通常、スキーマベースの問い合わせを実施しやすいように、基本スキーマが予め用意されている。基本スキーマが予め用意されていないシナリオでは、ＤＮＳ問い合わせなどの方法を使って、基本スキーマの場所（ＦＱＤＮ）にアクセスされてもよい。

基本スキーマとは異なり、拡張スキーマは、周期的に、例えば、新しいリンク層技術が導入されるときなどに更新されることが期待される。拡張スキーマは、かかる拡張スキーマが事前に用意されていなくても、ＩＥＥＥ８０２．２１、メディア独立のハンドオーバサービス（IEEE802.21 Media Independent Handover Services）21-05-xxxx-00-0000-One_Proposal_Draft_Textのセクション８．５．３に記載されているスキーマ問い合わせ機能を使い、ＩＥＥＥ８０２．２１情報サービスにより、指定のＵＲＬから検索され得る。また、拡張スキーマのＵＲＬも、上記セクション８．５．３に記載されているスキーマＵＲＬ問い合わせ機能を介して獲得され得る。代替として、ＤＮＳ問い合わせを使って、拡張スキーマの場所（ＦＱＤＮ部分）を探し出してもよい。拡張スキーマは、基本スキーマの拡張として定義され、メディア特有の、または上位層の情報のデータ構造と関係を含む。この意味で、拡張スキーマは、基本スキーマを補完するものである。

ＩＥＥＥ８０２．２１情報サービスにおけるＲＤＦ／ＸＭＬスキーマのサポート：
１．概要
本明細書の本項は、（１）ＩＥＥＥ８０２．２１情報サービスのためのＲＤＦ／ＸＭＬスキーマ定義、（２）ＲＤＦ／ＸＭＬベースのＩＥＥＥ８０２．２１情報サービスをサポートするための、（２００５年４月１３日に出願された上記優先権仮出願に添付されている）参照文献［１］に記載されている情報サービスプリミティブへの必要な変更、および（３）ＲＤＦ／ＸＭＬベースのＩＥＥＥ８０２．２１情報サービスを使ったプリミティブの使用例を含む。

２．ＩＥＥＥ８０２．２１情報サービスのためのＲＤＦ／ＸＭＬスキーマ定義
ＩＥＥＥ８０２．２１情報サービスのためのＲＤＦ／ＸＭＬスキーマ定義は、２つの部分、すなわち、基本スキーマと拡張スキーマを有する。あらゆるＭＩＨエンティティには、基本スキーマが予め用意されていなければならない。基本スキーマは、更新がサポートされていない。ＲＤＦ／ＸＭＬスキーマの残りは、拡張スキーマである。基本スキーマとは異なり、拡張スキーマは、例えば、新しいリンク層技術が導入されるときなどの、更新がサポートされており、ＭＩＨエンティティには、拡張スキーマが予め用意されていなくてもよい。代わりに、拡張スキーマは、以下の第３部で述べるスキーマ問い合わせ機能などを使って、情報サービスを介して検索され得る。

図２０に、現在定義されているＲＤＦ／ＸＭＬスキーマのグラフを示す。

２．１．基本スキーマ
基本スキーマは、図２１（１）〜２１（２）に示すように、ＲＤＦ／ＸＭＬ形式で表される。

２．２．拡張スキーマ
拡張スキーマは、図２１（３）〜２１（１２）に示すように、ＲＤＦ／ＸＭＬ形式で表される。

３．ＲＤＦ／ＸＭＬスキーマをサポートする情報サービスプリミティブ
［１］では、ＩＥＥＥ８０２．２１情報サービスの２つのプリミティブ、すなわち、MIH_information.requestとMIH_information.responseが、以下のように定義されている。

ＲＤＦ／ＸＭＬスキーマに基づく情報サービスをサポートするために、情報サービスプリミティブに以下の変更が加えられる。

３．１．近隣グラフ問い合わせ
新しいInfoQueryFilter型「FILTER_INFO_NEIGHBOR_NETWORKS」が定義される。このInfoQueryFilter型が指定されるとき、InfoQueryParametersは、ＳＰＡＲＱＬ問い合わせが、近隣グラフを獲得する適切な問い合わせを含むことになっている、ＳＰＡＲＱＬ問い合わせ［２］を含むストリングでなければならない。対応するMIH_information.responseのMIH_REPORTは、ＳＰＡＲＱＬ問い合わせ結果［３］を含むストリングでなければならない。

FILTER_INFO_NEIGHBOR_NETWORKSがInfoQueryFilterとして指定されるときの問い合わせ要求と応答の例を以下に示す。

MIH_Information.request (FILTER_INFO_NEIGHBOR_NETWORKS,
"PREFIX ndext:
<http://www.networkdiscovery.org/2005/04/rdf-extended-schema/>
SELECT ?z1
WHERE (?x1 ndext:802.11-neighboring-bssid ?z1)
(?x1 ndext:802.11-bssid, "12:34:56:78:9a:bc")", 123)

MIH_Information.response(FILTER_INFO_NEIGHBOR_NETWORKS,
"<?xml version="1.0"?>
<sparql xmlns="http://www.w3.org/2001/sw/DataAccess/rf1/result">
<head>
<variable name="802.11-neighboring-bssid"/>
</head>
<results>
<result>
<802.11-neighboring-bssid>aa:bb:cc:dd:ee:ff</802.11-neighboring-bssid>
</result>
<result>
<802.11-neighboring-bssid>00:11:22:33:44:55</802.11-neighboring-bssid>
<result>
</result>
<802.11-neighboring-bssid>01:23:45:67:89:ab</802.11-neighboring-bssid>
<result>
</results>
</sparql>",
123)

３．２ 一般的なＲＤＦ／ＸＭＬデータ問い合わせ
新しいInfoQueryFilter型「ＦＩＬＴＥＲ＿ＩＮＦＯ＿ＤＡＴＡ」が定義される。このInfoQueryFilter型が指定されるとき、InfoQueryParametersは、ＳＰＡＲＱＬ問い合わせが、期待されるＲＤＦ／ＸＭＬデータを獲得する適切な問い合わせを含むことになっているＳＰＡＲＱＬ問い合わせ［２］を含むストリングでなければならない。対応するMIH_information.responseのMIH_REPORTは、ＳＰＡＲＱＬ問い合わせ結果［３］を含むストリングでなければならない。

FILTER_INFO_DATAがInfoQueryFilterとして指定されるときの問い合わせ要求と応答の例を以下に示す。

MIH_Information.request (FILTER_INFO_DATA,
"PREFIX ndext:<http://www/networkdiscovery.org/2005/04/rdf-extended-schema/>
SELECT ?z
WHERE (?x, ndext:dhcp_server_address, ?z)
(?x ndext:router_address, 12.34.56.1)",
123)
MIH_Information.response(FILTER_INFO_DATA
"<?xml version="1.0"?>
<sparql xmlns="http://www.w3.org/2001/sw/DataAccess/rf1/result">
<head>
<variable name="dhcp_server_address"/>
</head>
<results>
<result>
<dhcp_server_address>12.34.56.78</dhcp_server_address>
</result>
</results>
</sparql>",
123)
３．３ ＲＤＦ／ＸＭＬスキーマＵＲＬ問い合わせ
新しいInfoQueryFilter型「FILTER_INFO_SCHEMA_URL」が定義される。このInfoQueryFilter型が指定されるとき、InfoQueryParametersは、ヌルストリングでなければならない。対応するMIH_information.responseのMIH_REPORTは、拡張スキーマのＵＲＬを含むストリングでなければならない。獲得されたＵＲＬからどのようにして拡張スキーマを取り出すかは、実施に委ねられる。

FILTER_INFO_SCHEMA_URLがInfoQueryFilterとして指定されるときの問い合わせ要求と応答の例を以下に示す。

MIH_Information.request(FILTER_INFO_SCHEMA_URL, “” , 123)

MIH_Information.response(FILTER_INFO_SCHEMA_URL,
"http://www.networkdiscovery.org/2005/04/rdf-extended-schema/",123)

３．４ ＲＤＦ／ＸＭＬスキーマ問い合わせ
新しいInfoQueryFilter型「FILTER_INFO_SCHEMA」が定義される。このInfoQueryFilter型が定義されるとき、InfoQueryParametersは、当該のＸＭＬ形式のＲＤＦ主部と、任意選択で、スキーマグラフでのサーチの深さを指定する整数を含むストリングでなければならない。デフォルトの深さ値は、サーチの深さに制限がないことを表すゼロ（０）である。ＲＤＦ主部パラメータに加えて深さパラメータが指定されるときには、２つのパラメータの区切りとしてコンマ（「，」）が使用される。対応するMIH_information.responseのMIH_REPORTは、獲得されたＲＤＦ／ＸＭＬスキーマを含むストリングでなければならない。

FILTER_INFO_SCHEMAがInfoQueryFilterとして指定されるときの問い合わせ要求と応答の例を以下に示す。

MIH_Information.request(FILTER_INFO_SCHEMA,
"<rdfs:Class rdf:about="http://www.networkdiscovery.org/2005/04/rdf-basic-schema/Network">,0", 123)

MIH_Information.response(FILTER_INFO_SCHEMA,
"<rdf:RDF xml:lang="en"
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
xmlns:nd="http://www.networkdiscovery.org/2005/04/rdf-basic-schema/">
<rdfs:Class rdf:about="http://www.networkdiscovery.org/2005/04/rdf-basic-schema/Network">
<rdfs:subClassOf rdf:resource="http://www.w3.org/2000/01/rdf-schema#Resource"/>
</rdfs:Class>
<rdfs:Class rdf:about="http://www.networkdiscovery.org/2005/04/rdf-basic-schema/L2info">
<rdfs:subClassOf rdf:resource="http://www.networkdiscovery.org/2005/04/rdf-basic-schema/Network"/>
</rdfs:Class>

....

<rdfs:Class rdf:about="http://www.networkdiscovery.org/2005/04/rdf-basic-schema/IPv4">
<rdfs:subClassOf rdf:resource="http://www.networkdiscovery.org/2005/04/rdf-schema/L3info"/>
</rdfs:Class>

<rdfs:Class rdf:about="http://www.networkdiscovery.org/2005/04/rdf-basic-schema/IPv6">
<rdfs:subClassOf rdf:resource="http://www.networkdiscovery.org/2005/04/rdf-schema/L3info"/>
</rdfs:Class>
</rdf:RDF>",123)
４．参照文献
参照により、以下の参照文献全体を本明細書に組み込む。

[1] “MEDIA INDEPENDENT HANDOVER”, 21-05-0240-01-0000-Joint_MIH_Proposal_Draft_Text-07 （参照により全体が本明細書に組み込まれる、２００５年４月１３日に出願された上記の優先権仮出願の付録Ａ参照）.
[2] “SPARQL Query Language for RDF”, http://www.w3.org/TR/rdf-sparql-query/.
[3] "SPARQL Variable Binding Results XML Foramt",
http://www.w3.org/TR/2004/WD-rdf-sparql-XMLres-20041221/.

８０２．２１基本文書のためのＲＤＦスキーマ更新：
１．概要
本願の本項は、21-05-0271-00-0000-One_Proposal_Draft_Text（８０２．２１基本文書）で定義されているＲＤＦスキーマにおける変更案を含む。付録Ａの２００５年７月１１日に出願された上記の仮特許出願を参照されたい。

基本文書のＲＤＦスキーマは、クラスおよび特性、ならびにこれらの間の関係を定義している。しかしながら、各特性の詳細なデータ型も基数も欠如している。このレベルの詳細を定義しなければ、８０２．２１情報サービスによって使用される特性が、実現形態により異なって符号化される可能性が高い。

本願の本項では、特に、ワールドワイドウェブコンソーシアムでＲＤＦおよびＲＤＦスキーマと共に定義されているＯＷＬ（Ｗｅｂオントロジ言語）を使って、８０２．２１の基本スキーマと拡張スキーマの各特性ごとの詳細なデータ型と基数を定義する。

「ＲＤＦスキーマの各情報要素を厳密に定義するために、スキーマは、Ｗｅｂオントロジ言語（ＯＷＬ）［１４］を用いて増強される。

ＯＷＬとはＷｅｂオントロジ言語である。ＯＷＬは、命名のためのＵＲＩ（ユニフォームリソース識別子）とＲＤＦ（リソース記述フレームワーク）によって提供される記述フレームワークの両方を使って、オントロジに以下の能力を付加する。

多くのシステムにまたがって分散され得ること
スケーラビリティ
アクセス可能性と国際化のための他のＷｅｂ規格との互換性
開放性と拡張可能性
ＯＷＬは、ＲＤＦとＲＤＦスキーマに基づいて構築され、特性とクラス、特に、クラス間の関係（分離性など）、基数（「厳密に１」など）、等しいこと、特性のより豊富な類別、特性の特徴（対称性など）、および列挙クラスを記述するためのより多くの語彙を付加する。

図２２に、「ネットワーク」「Ｌ２」、「Ｌ３」、「場所」、「ＩＰｖ４」、「ＩＰｖ６」、「リンクの種類」、「ＰｏＡ」、「都市アドレス」「地理座標」がクラスとして表され、他すべてがクラスの特性である、８０２．２１ＭＩＩＳ基本スキーマのグラフ例を示す。線は、クラスの特性または下位クラスの範囲またはドメインを示す。具体的には、「ｒ」は、特性の範囲を表し、「ｄ」は、特性のドメインを表す。「ドメイン」は、個々の特性が属するクラスを定義し、「範囲」は、個々の特性の種類を定義する。各ＰｏＡごとに「ネットワーク」クラスの互いに異なるインスタンスが割り振られる。

発明の一般的な適用範囲：
本明細書では、本発明の説明的実施形態について述べているが、本発明は、本明細書で述べる様々な好ましい実施形態だけに限定されるものではなく、本開示に基づき、当分野の技術者によって理解されるはずの同等の要素、改変、省略、（様々な実施形態にまたがる態様などの）組み合わせ、適応および／または変更を有するありとあらゆる実施形態を含むものである。（後で追加されるべきものなどを含む）特許請求の範囲における限定は、特許請求の範囲で用いられている言語に基づいて幅広く解釈されるべきであり、本明細書で、または本願の出願中に示される例だけに限定されるものではなく、これらの例は、非排他的であると解釈されるべきである。例えば、本開示において、「好ましくは」という用語は、非排他的であり、「好ましくは、しかしそれだけに限らないが、」を意味するものである。本開示および本願の出願手続中において、手段プラス機能限定またはステッププラス機能限定は、特定の請求項限定について、この限定に、ａ）「〜の手段」または「〜のステップ」が明示的に記載されている、ｂ）対応する機能が明示的に記載されている、およびｃ）構造、材料またはこの構造を支持する動作が記載されていないという条件すべてが存在する場合に限って用いられる。本開示および本願の出願手続中において、「本発明」または「発明」という用語は、本開示内の１つ以上の態様を言及するものとして使用され得る。本発明または発明という言葉は、重要度を識別するものであると不適切に解釈されるべきではなく、すべての態様または実施形態にまたがって適用されるものであると不適切に解釈されるべきでなく（すなわち、本発明はいくつかの態様と実施形態を有すると理解されるべきであり）、本願または特許請求の範囲を限定するものであると不適切に解釈されるべきではない。本開示および本願の出願手続中において、「実施形態」という用語は、任意の態様、機能、プロセスまたはステップ、これらの任意の組み合わせ、および／またはこれらの任意の部分などを示すのに使用され得る。いくつかの例では、様々な実施形態が、重なり合う機能を含むことがある。本開示では、「例えば」を意味する「ｅ．ｇ．」、および「注意せよ」を意味する「ＮＢ」という省略用語が用いられることがある。

特に、Ｊｉｎｉ接続技術のアーキテクチャを示す図である。 ＵＰｎＰプロトコルスタックを示す図である。 サリュテーションマネージャのモデルを示す図である。 ローカルサービスおよびネットワーク能力の協働による探索を示す図である。 報告エージェント（ＲＡ）を使ったデータベースへのデータ取り込みを示す図である。 ネットワークサービス探索のためのプロトコルの流れを示す図である。 地理座標ベースのネットワークサービス探索の例を示す図である。 ＡＰのＭＡＣアドレスベースのネットワークサービス探索の例を示す図である。 ピアツーピアベースのネットワーク探索を示す図である。 設定範囲ベースのマルチキャストを示す図である。 再帰的ブロードキャストを示す図である。 ネットワーク探索とセキュアでシームレスなハンドオフの統合を示す図である。 統合された流れ（ネットワーク探索＋事前認証）の例を示す図である。 ネットワーク探索と事前認証の流れを示す流れ図である。 データベースエンジンの異なるコンポーネント間の対話を示す図である。 デモシステムに関連する図である。 デモシステムに関連する図である。 デモシステムに関連する図である。 ＸＭＬ形式を使用するネットワーク探索の、説明的、非限定的ＲＤＦスキーマを示す図である。 ＸＭＬ形式を使用するネットワーク探索の、説明的、非限定的ＲＤＦスキーマを示す図である。 ＸＭＬ形式を使用するネットワーク探索の、説明的、非限定的ＲＤＦスキーマを示す図である。 ＸＭＬ形式を使用するネットワーク探索の、説明的、非限定的ＲＤＦスキーマを示す図である。 ＸＭＬ形式を使用するネットワーク探索の、説明的、非限定的ＲＤＦスキーマを示す図である。 ＸＭＬ形式を使用するネットワーク探索の、説明的、非限定的ＲＤＦスキーマを示す図である。 ＸＭＬ形式を使用するネットワーク探索の、説明的、非限定的ＲＤＦスキーマを示す図である。 ＸＭＬ形式を使用するネットワーク探索の、説明的、非限定的ＲＤＦスキーマを示す図である。 ＸＭＬ形式を使用するネットワーク探索の、説明的、非限定的ＲＤＦスキーマを示す図である。 ＸＭＬ形式を使用するネットワーク探索の、説明的、非限定的ＲＤＦスキーマを示す図である。 サービスアクセスポイント（ＳＡＰ）の定義と呼び出しの流れに関連する説明的実施形態および態様を示す図である。 サービスアクセスポイント（ＳＡＰ）の定義と呼び出しの流れに関連する説明的実施形態および態様を示す図である。 サービスアクセスポイント（ＳＡＰ）の定義と呼び出しの流れに関連する説明的実施形態および態様を示す図である。 サービスアクセスポイント（ＳＡＰ）の定義と呼び出しの流れに関連する説明的実施形態および態様を示す図である。 サービスアクセスポイント（ＳＡＰ）の定義と呼び出しの流れに関連する説明的実施形態および態様を示す図である。 サービスアクセスポイント（ＳＡＰ）の定義と呼び出しの流れに関連する説明的実施形態および態様を示す図である。 サービスアクセスポイント（ＳＡＰ）の定義と呼び出しの流れに関連する説明的実施形態および態様を示す図である。 サービスアクセスポイント（ＳＡＰ）の定義と呼び出しの流れに関連する説明的実施形態および態様を示す図である。 サービスアクセスポイント（ＳＡＰ）の定義と呼び出しの流れに関連する説明的実施形態および態様を示す図である。 サービスアクセスポイント（ＳＡＰ）の定義と呼び出しの流れに関連する説明的実施形態および態様を示す図である。 サービスアクセスポイント（ＳＡＰ）の定義と呼び出しの流れに関連する説明的実施形態および態様を示す図である。 サービスアクセスポイント（ＳＡＰ）の定義と呼び出しの流れに関連する説明的実施形態および態様を示す図である。 上記の２００５年１１月５日に出願された第１の仮出願の添付文書Ａに記載されているＭＩＨ機能および情報サービスに関連する説明的実施形態および態様を示す図である。 上記の２００５年１１月５日に出願された第１の仮出願の添付文書Ａに記載されているＭＩＨ機能および情報サービスに関連する説明的実施形態および態様を示す図である。 上記の２００５年１１月５日に出願された第１の仮出願の添付文書Ａに記載されているＭＩＨ機能および情報サービスに関連する説明的実施形態および態様を示す図である。 上記の２００５年１１月５日に出願された第１の仮出願の添付文書Ａに記載されているＭＩＨ機能および情報サービスに関連する説明的実施形態および態様を示す図である。 上記の２００５年１１月５日に出願された第１の仮出願の添付文書Ａに記載されているＭＩＨ機能および情報サービスに関連する説明的実施形態および態様を示す図である。 上記の２００５年１１月５日に出願された第１の仮出願の添付文書Ａに記載されているＭＩＨ機能および情報サービスに関連する説明的実施形態および態様を示す図である。 上記の２００５年１１月５日に出願された第１の仮出願の添付文書Ａに記載されているＭＩＨ機能および情報サービスに関連する説明的実施形態および態様を示す図である。 上記の２００５年１１月５日に出願された第１の仮出願の添付文書Ａに記載されているＭＩＨ機能および情報サービスに関連する説明的実施形態および態様を示す図である。 上記の２００５年１１月５日に出願された第１の仮出願の添付文書Ａに記載されているＭＩＨ機能および情報サービスに関連する説明的実施形態および態様を示す図である。 上記の２００５年１１月５日に出願された第１の仮出願の添付文書Ａに記載されているＭＩＨ機能および情報サービスに関連する説明的実施形態および態様を示す図である。 上記の２００５年１１月５日に出願された第１の仮出願の添付文書Ａに記載されているＭＩＨ機能および情報サービスに関連する説明的実施形態および態様を示す図である。 上記の２００５年１１月５日に出願された第１の仮出願の添付文書Ａに記載されているＭＩＨ機能および情報サービスに関連する説明的実施形態および態様を示す図である。 上記の２００５年１１月５日に出願された第１の仮出願の添付文書Ａに記載されているＭＩＨ機能および情報サービスに関連する説明的実施形態および態様を示す図である。 現在定義されているＲＤＦ／ＸＭＬスキーマを示すグラフである。 ＲＤＦ／ＸＭＬ形式で表した基本スキーマを示す図である。 ＲＤＦ／ＸＭＬ形式で表した基本スキーマを示す図である。 ＲＤＦ／ＸＭＬ形式で表した拡張スキーマを示す図である。 ＲＤＦ／ＸＭＬ形式で表した拡張スキーマを示す図である。 ＲＤＦ／ＸＭＬ形式で表した拡張スキーマを示す図である。 ＲＤＦ／ＸＭＬ形式で表した拡張スキーマを示す図である。 ＲＤＦ／ＸＭＬ形式で表した拡張スキーマを示す図である。 ＲＤＦ／ＸＭＬ形式で表した拡張スキーマを示す図である。 ＲＤＦ／ＸＭＬ形式で表した拡張スキーマを示す図である。 ＲＤＦ／ＸＭＬ形式で表した拡張スキーマを示す図である。 ＲＤＦ／ＸＭＬ形式で表した拡張スキーマを示す図である。 ＲＤＦ／ＸＭＬ形式で表した拡張スキーマを示す図である。 「ネットワーク」、「Ｌ２」、「Ｌ３」、「場所」、「ＩＰｖ４」、「ＩＰｖ６」、「リンクの種類」、「ＰｏＡ」、「都市アドレス」、「地理座標」がクラスとして表され、他すべてがクラスの特性である、８０２．２１ ＭＩＩＳ基本スキーマのグラフ例である。

Claims (12)

1. ＩＰネットワーク内の複数のアクセスネットワークの少なくとも１つを使用するモバイル機器のネットワーク探索の方法であって、
   条件に基づいて特定の場所の近傍における指定のネットワーク情報を前記モバイル機器から要求し、
   前記要求で指定された条件を満たし、前記特定の場所の近傍におけるネットワーク情報を前記モバイル機器に提供することを含むネットワーク探索方法。
2. 前記ネットワーク情報は、前記モバイルによって前記アクセスネットワークにアクセスするのに使用される情報を含む、請求項１に記載のネットワーク探索方法。
3. 前記特定の場所は、前記モバイル機器の位置であることを特徴とする請求項１記載のネットワーク探索方法。
4. 前記特定の場所は、提供された前記ネットワーク情報に基づいて指定された場所であることを特徴とする請求項１記載のネットワーク探索方法。
5. 前記ネットワーク情報は、アクセスポイントのネットワーク接続点識別子を含む、請求項１に記載のネットワーク探索方法。
6. 前記ネットワーク情報は、アクセスポイントのＭＡＣの種類を含む、請求項１に記載のネットワーク探索方法。
7. 前記ネットワーク情報は、アクセスポイントによってサポートされるセキュリティの種類を含む、請求項２に記載のネットワーク探索方法。
8. 前記ネットワーク情報は、第３層の種類を含む、請求項２に記載のネットワーク探索方法。
9. 前記ネットワーク情報はプロバイダ名を含む、請求項２に記載のネットワーク探索方法。
10. 前記ネットワーク情報は、サーバまたはエージェントのアドレスを含む、請求項２に記載のネットワーク探索方法。
11. 前記ネットワーク情報は、認証エージェントのアドレスを含む、請求項２に記載のネットワーク探索方法。
12. 前記ネットワーク情報は、アクセスルータのアドレスを含む、請求項２に記載のネットワーク探索方法。

Images