(57)【要約】【課題】モバイル機器のネットワーク探索における問い合わせおよび／または応答のためのＸＭＬとＴＬＶの統合を提供する。【解決手段】ネットワーク探索などの用途における問い合わせおよび／または応答などで使用するために、ＸＭＬデータをＴＬＶ形式に変換する方法が提供される。【選択図】なし
2008535286.tif 000002
【特許請求の範囲】
【請求項１】
モバイル機器のためのネットワーク探索方法であって、バイナリ符号化を伴うスキーマベースの意味問い合わせを使って、モバイル機器と接続点の間でネットワーク探索の問い合わせおよび／または応答を行うことを含む方法。
【請求項２】
ＸＭＬを使ってスキーマベースの意味問い合わせを行い、ＴＬＶを使ってバイナリ符号化を行うことをさらに含む、請求項１に記載の方法。
【請求項３】
ＸＭＬデータをＴＬＶ形式に変換することをさらに含む、請求項２に記載の方法。
【請求項４】
ＴＬＶをＳＰＡＲＱＬ最適化と共に用いることを含む、請求項１に記載の方法。
【請求項５】
ＸＭＬバイナリ表現を用いることをさらに含む、請求項１に記載の方法。
【請求項６】
エイリアスベースの方法を使ってＸＭＬデータを変換することをさらに含む、請求項５に記載の方法。
【請求項７】
ａ）ＸＭＬ名前空間名を整数に変換することと、ｂ）ＸＭＬタグ名を整数に変換することと、ｃ）ＸＭＬ属性名を整数に変換することと、および／またはｄ）ＥＮＴＲＹ名を整数に変換することとをさらに含む、請求項６に記載の方法。
【請求項８】
整数マッピングを用いることをさらに含む、請求項７に記載の方法。
【請求項９】
前記整数マッピングは静的マッピングを含む、請求項８に記載の方法。
【請求項１０】
前記整数マッピングは動的マッピングを含む、請求項８に記載の方法。
【請求項１１】
前記動的マッピングは送信されるデータと共に搬送される、請求項１０に記載の方法。
【請求項１２】
事前定義のタグおよび／または属性に静的マッピングを用いることをさらに含む、請求項８に記載の方法。
【請求項１３】
他のタグ、属性および／または名前空間に動的マッピングを用いることをさらに含む、請求項１２に記載の方法。
【請求項１４】
意味的バンドリングを用いてＸＭＬデータを変換することをさらに含む、請求項１に記載の方法。
【請求項１５】
特定の問い合わせ言語に適用可能であり、２つ以上の意味的に関連するＸＭＬタグを単一の整数にマップすることと、および前記特定の問い合わせ言語の構文の知識を利用することとをさらに含む、請求項１４に記載の方法。
【請求項１６】
構成問い合わせ、選択問い合わせおよび／または論理問い合わせを含むＸＭＬベースの問い合わせ言語を用いることをさらに含む、請求項１に記載の方法。
【請求項１７】
構成問い合わせを用いて隣接接続点のＩＥを獲得することをさらに含む、請求項１６に記載の方法。
【請求項１８】
選択問い合わせを用いて隣接接続点を獲得することをさらに含む、請求項１６に記載の方法。
【請求項１９】
論理問い合わせを用いて、隣接接続点が特定の種類のネットワークのものであるかどうか問い合わせることをさらに含む、請求項１６に記載の方法。
【請求項２０】
論理問い合わせを用いて、隣接接続点が８０２．１１接続点であるかどうか問い合わることをさらに含む、請求項１６に記載の方法。
【請求項２１】
構成問い合わせでは、ＸＭＬのＲＤＦの３部分が返されることをさらに含む、請求項１６に記載の方法。
【請求項２２】
選択問い合わせでは、選択バインディングが返されることをさらに含む、請求項１６に記載の方法。
【請求項２３】
論理問い合わせでは、ＹＥＳまたはＮＯの値が返されることをさらに含む、請求項１６に記載の方法。
【請求項２４】
ネットワークにおけるモバイル機器と接続点の問い合わせと応答をサポートする方法であって、問い合わせ結果に含まれるＸＭＬデータをＴＬＶに変換することにより、スキーマベースの意味問い合わせにＸＭＬを使用し、バイナリ符号化にＴＬＶを使用することを含む方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本出願は、特に、無線ネットワークでのネットワーク探索および／またはメディア独立ハンドオーバのためのＸＭＬとＴＬＶの統合に関する。
【背景技術】
【０００２】
ネットワーク及びインターネット（登録商標）プロトコル
多様なコンピュータネットワークがあり、インターネットは最も有名である。インターネットは、コンピュータネットワークの世界規模のネットワークである。今日、インターネットは、何百万人ものユーザが利用可能な、公衆の自律的ネットワークである。インターネットは、ＴＣＰ／ＩＰ（すなわち、伝送制御プロトコル／インターネットプロトコル）と呼ばれる１組の通信プロトコルを使って各ホストを接続する。インターネットは、インターネットバックボーンとして呼ばれる通信インフラストラクチャを有する。インターネットバックボーンへのアクセスは大部分企業及び個人へのアクセスを再販するインターネットサービスプロバイダ（ＩＳＰ）によって制御される。
【０００３】
ＩＰ（インターネットプロトコル）に関して、これは、ネットワーク上である装置（電話機、ＰＤＡ［携帯情報端末］、コンピュータなど）から別の装置にデータを送るためのプロトコルである。今日、ＩＰｖ４、ＩＰｖ６などを含めて、様々なＩＰのバージョンがある。ネットワーク上の各ホスト装置は、独自の一意の識別子である少なくとも１つのＩＰアドレスを有する。
【０００４】
ＩＰはコネクションレス型プロトコルである。通信時の端点間接続は連続的ではない。ユーザがデータ又はメッセージを送信し、又は受信するとき、データ又はメッセージは、パケットと呼ばれる構成要素に分割される。各パケットは、独立のデータ単位として扱われる。
【０００５】
インターネットなどのネットワークを介した各点間の伝送を標準化するために、ＯＳＩ（開放型システム間相互接続）モデルが確立された。ＯＳＩモデルは、ネットワーク中の２点間の通信プロセスを７つの階層に分け、各層（レイヤ）は独自の機能セットを付加する。各装置は、送信側端点では各層を通る下方への流れがあり、受信側端点では各層を通る上方への流れがあるようにメッセージを処理する。７つの機能層を提供するプログラミング及び／又はハードウェアは、通常、デバイスオペレーティングシステム、アプリケーションソフトウェア、ＴＣＰ／ＩＰ及び／又は他のトランスポート及びネットワークプロトコル、ならびに他のソフトウェア及びハードウェアの組み合わせである。
【０００６】
通常、上位４層は、メッセージがユーザから、又はユーザへ渡されるときに使用され、下位３層は、メッセージが装置（ＩＰホスト装置など）を通過するときに使用される。ＩＰホストは、サーバ、ルータ、ワークステーションなど、ＩＰパケットを送受信することのできるネットワーク上の任意の装置である。他の何らかのホストに向けられているメッセージは、各上位層には渡されず、この他のホストに転送される。ＯＳＩモデルの各層を以下に列記する。第７層（すなわち、アプリケーション層）は、例えば、通信相手が識別され、サービス品質が識別され、ユーザ認証及びプライバシが考慮され、データ構文に対する制約条件が識別される層である。第６層（すなわち、プレゼンテーション層）は、例えば、着信及び発信データをあるプレゼンテーション形式から別の形式に変換する層である。第５層（すなわち、セッション層）は、例えば、アプリケーション間の会話、交換及びダイアログをセットアップし、調整し、終了させる層である。第４層（すなわち、トランスポート層）は、例えば、エンドツーエンド制御及び誤りチェックなどを管理する層である。第３層（すなわち、ネットワーク層）は、例えば、経路指定や転送などを処理する層である。第２層（すなわち、データリンク層）は、例えば、物理レベルでの同期を提供し、ビットスタッフィングを行い、伝送プロトコルの知識及び管理などを提供する層である。米国電気電子技術者協会（ＩＥＥＥ）では、データリンク層を、物理層との間のデータ転送を制御するＭＡＣ（媒体アクセス制御）層と、ネットワーク層とのインターフェースを取り、コマンドを解釈し、誤り回復を行うＬＬＣ（論理リンク制御）層という、２つのさらなる副層（サブレイヤ）に細分する。第１層（すなわち、物理層）は、例えば、物理レベルにおいてネットワークを介してビットストリームを伝達する層である。ＩＥＥＥでは、物理層を、ＰＬＣＰ（物理層収束手順）副層とＰＭＤ（物理媒体依存）副層とに細分する。
【０００７】
無線ネットワーク：
無線ネットワークは、例えば、セルラ及び無線電話機、ＰＣ（パーソナルコンピュータ）、ラップトップコンピュータ、装着型コンピュータ、コードレス電話機、ポケットベル、ヘッドセット、プリンタ、ＰＤＡなど、多種多様なモバイル機器を組み込むことができる。例えば、モバイル機器は、音声及び／又はデータの高速無線伝送を確保するデジタルシステムを含むことができる。典型的なモバイル機器は、次の構成要素の一部又は全部、即ち送受信機（すなわち、例えば、送信機、受信機及び、必要に応じて、他の機能が統合されたシングルチップ送受信機などを含む、送信機及び受信機）、アンテナ、プロセッサ、１つ又は複数の音声変換器（例えば、音声通信用機器でのスピーカやマイクロホンなど）、電磁データ記憶（データ処理が提供される機器の場合などでの、ＲＯＭ、ＲＡＭ、デジタルデータ記憶など）、メモリ、フラッシュメモリ、フルチップセット又は集積回路、インターフェース（ＵＳＢ、ＣＯＤＥＣ、ＵＡＲＴ、ＰＣＭなど）及び／又は同種のものを含む。
【０００８】
モバイルユーザが無線接続を介してローカルエリアネットワーク（ＬＡＮ）に接続することのできる無線ＬＡＮ（ＷＬＡＮ）が、無線通信に用いられ得る。無線通信には、例えば、光、赤外線、電波、マイクロ波などの電磁波を介して伝搬する通信などが含まれ得る。現在、ブルートゥース（登録商標）、ＩＥＥＥ８０２．１１、ＨｏｍｅＲＦなど、様々なＷＬＡＮ標準が存在する。
【０００９】
一例として、ブルートゥース製品は、モバイルコンピュータ、モバイル電話機、携帯式ハンドヘルド機器、携帯情報端末（ＰＤＡ）、及び他のモバイル機器の間のリンク、ならびにインターネットへの接続を提供するのに使用できる。ブルートゥースは、モバイル機器が、短距離無線接続を使って、相互に、また非モバイル機器と、どのようにして容易に相互接続し合うことができるかを詳述するコンピュータ及び電気通信業界仕様である。ブルートゥースは、ある機器と別の機器との間でデータを同期させ、整合させ続けることを必要とする、様々なモバイル機器の普及から生じるエンドユーザ問題に対処して、異なるベンダからの装置を相互にシームレスに動作させるデジタル無線プロトコルを作成する。ブルートゥース機器は、共通の命名概念に従って命名できる。例えば、ブルートゥース機器は、ブルートゥース機器名（ＢＤＮ）又は一意のブルートゥース機器アドレス（ＢＤＡ）に関連付けられた名前を持ち得る。また、ブルートゥース機器は、インターネットプロトコル（ＩＰ）ネットワークに参加することもできる。ブルートゥース機器がＩＰネットワーク上で機能する場合、この機器は、ＩＰアドレス及びＩＰ（ネットワーク）名を備え得る。よって、ＩＰネットワークに参加するように構成されたブルートゥース機器は、ＢＤＮ、ＢＤＡ、ＩＰアドレス及びＩＰ名などを含むことができる。「ＩＰ名」という用語は、インターフェースのＩＰアドレスに対応する名前を指す。
【００１０】
ＩＥＥＥ標準であるＩＥＥＥ８０２．１１は、無線ＬＡＮ及び機器の技術の仕様を定める。８０２．１１を使えば、各単一基地局がいくつかの機器をサポートする無線ネットワークが実現できる。いくつかの例では、機器に無線ハードウェアが事前装備されていることもあり、ユーザが、アンテナを含み得る、カードなどの別個のハードウェアをインストールすることもできる。例えば、８０２．１１で使用される機器は、通常、機器がアクセスポイント（ＡＰ）であるか、移動局（ＳＴＡ）であるか、ブリッジであるか、ＰＣＭＣＩＡカードであるか、それとも別の機器であるか否かを問わず、無線送受信機、アンテナ、及びネットワークにおける各点間のパケットの流れを制御するＭＡＣ（媒体アクセス制御）層という３つの注目すべき要素を含む。
【００１１】
更に、いくつかの無線ネットワークでは、複数インターフェース機器（ＭＩＤ）が利用できる。ＭＩＤは、ブルートゥースインターフェースと８０２．１１インターフェースなど、２つの独立のネットワークインターフェースを含むことができ、よって、ＭＩＤが２つの別個のネットワーク上に参加すると同時に、ブルートゥース機器ともインターフェースすることが可能になる。ＭＩＤは、ＩＰアドレス、及びＩＰアドレスに関連付けられた共通ＩＰ（ネットワーク）名を持つことができる。
【００１２】
無線ネットワーク機器には、それだけに限らないが、ブルートゥース機器、複数インターフェース機器（ＭＩＤ）、８０２．１１ｘ機器（８０２．１１ａ、８０２．１１ｂ、８０２．１１ｇ機器などを含む、ＩＥＥＥ８０２．１１機器）、ＨｏｍｅＲＦ（家庭内無線周波数）機器、Ｗｉ−Ｆｉ（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.
【発明の開示】
【発明が解決しようとする課題】
【００１７】
本発明は、上記他の背景技術および／または背景技術の問題を改良する。
【課題を解決するための手段】
【００１８】
問い合わせと応答を最も費用効果的にサポートするためには、拡張可能性、柔軟性および効率性を備えることが望ましい。これに関しての２つの可能な解決法の候補として、例えば、ＸＭＬとＴＬＶが含まれる。この場合、ＸＭＬは、スキーマベースの意味問い合わせを与えるが、固有のＸＭＬ１．０形式などを使用する場合には、無線を介してより多くのビットを送信する必要がある。他方、ＴＬＶは、バイナリ符号化を行うが、意味問い合わせのための標準問い合わせ言語を提供しない。
【００１９】
いくつかの手法では、ＸＭＬとＴＬＶを統合するために、ＸＭＬデータがＴＬＶに変換される。以下で述べるいくつかの説明例では、２つの方法を説明する。これに関して、第１の方法（方法Ａなど）は、任意のＸＭＬデータに適用することができ、第２の方法（方法Ｂなど）は、特定の問い合わせ言語に適用することができる。これに関して、ＸＭＬベースの問い合わせ言語は、通常、３種類の問い合わせ、例えば、構成問い合わせ、選択問い合わせおよび論理問い合わせなどを有する。
【００２０】
いくつかの実施形態によれば、ネットワークにおけるモバイル機器と接続点の問い合わせと応答をサポートする方法は、問い合わせ結果に含まれるＸＭＬデータをＴＬＶに変換することによって、スキーマベースの意味問い合わせにＸＭＬを使用し、バイナリ符号化にＴＬＶを使用することを備える。
【００２１】
いくつかの実施形態によれば、モバイル機器のためのネットワーク探索の方法は、バイナリ符号化を伴うスキーマベースの意味問い合わせを使って、モバイル機器と接続点の間でネットワーク探索の問い合わせおよび／または応答を行うことを含む。いくつかの実施形態では、この方法は、ＸＭＬを使ってスキーマベースの意味問い合わせを与え、ＴＬＶを使ってバイナリ符号化を行うことを含む。いくつかの実施形態では、この方法は、ＸＭＬデータをＴＬＶ形式に変換することを含む。いくつかの実施形態では、この方法は、ＴＬＶをＳＰＡＲＱＬ最適化と共に用いることを含む。
【００２２】
いくつかの実施形態では、この方法は、エイリアスベースの方法を使ってＸＭＬデータを変換することを含む。いくつかの実施形態では、この方法は、ａ）ＸＭＬネームスペース名を整数に変換すること、ｂ）ＸＭＬタグ名を整数に変換すること、ｃ）ＸＭＬ属性名を整数に変換すること、および／またはｄ）ＥＮＴＲＹ名を整数に変換すること、をさらに含む。いくつかの例では、この方法は、静的および／または動的マッピングなどの整数マッピングを用いることをさらに含む。場合によっては、動的マッピングが送信されるデータと共に搬送される。
【００２３】
いくつかの実施形態では、この方法は、意味的バンドリングを用いてＸＭＬデータを変換することをさらに含む。いくつかの例では、この方法は、特定の問い合わせ言語に適用可能であり、２つ以上の意味的に関連するＸＭＬタグを単一の整数にマップすること、および特定の問い合わせ言語構文の知識を利用することをさらに含む。いくつかの例では、この方法は、構成問い合わせ、選択問い合わせおよび／または論理問い合わせを含む、ＸＭＬベースの問い合わせ言語を用いることを含む。いくつかの例では、この方法は、構成問い合わせを用いて隣接接続点のＩＥを獲得すること、選択問い合わせを用いて隣接接続点を獲得すること、および／または論理問い合わせを用いて、隣接接続点が、８０２．１１接続点などの特定の種類のネットワークのものであるかどうか問い合わせることを含む。
【００２４】
様々な実施形態の上記他の態様、特徴および／または利点は、以下の説明を添付の図と併せて考察すればさらに理解されるであろう。様々な実施形態は、妥当な場合には、異なる態様、特徴および／または利点を含み、かつ／または除外することができる。加えて、様々な実施形態は、妥当な場合には、別の実施形態の１つまたは複数の態様または特徴を組み合わせることもできる。個々の実施形態の態様、特徴および／または利点の記述は、別の実施形態または特許請求の範囲を限定するものと解釈すべきではない。
【発明を実施するための最良の形態】
【００２５】
本発明の好ましい実施形態を、限定としてではなく例として、添付の図に示す。
【００２６】
本発明は、多くの異なる形で実施できるが、本明細書では、本開示が、本発明の原理の例を提供するものとみなされるべきであり、かかる例は、本発明を、本明細書で説明し、かつ／または本明細書で図示する好ましい実施形態だけに限定するためのものではないという了解の下で、いくつかの例示的実施形態について説明する。
【００２７】
序論
無線ＬＡＮ（ローカルエリアネットワーク）とセルラ技術に基づく無線ネットワーキングの発展の中、モビリティサービスが普及し、人々がますますモバイルを使用するようになるにつれて、モバイル機器が、時宜を得た、正確で効率のよいやり方で、アプリケーション要件とモバイルの特性を満たす、適切なネットワーク接続点を探し出すことができることがより重要になっている。かかる機能をネットワーク探索と呼ぶ。
【００２８】
本明細書で論じるネットワーク探索問題は、モバイルが任意の場所からＩＰネットワークに接続されるときに、１組の基準に基づき、所与の場所の近傍において指定のネットワーク情報を獲得することとして定式化される。ここで、
・ネットワーク情報は、モバイルがネットワークにアクセスするのに使用する任意の情報とすることができる。かかる情報には、例えば、ネットワーク接続点識別（Ｌ２アドレスおよび／またはアクセスポイントの地理的アドレスなど）、アクセスポイントのＭＡＣの種類（「ＩＥＥＥ８０２．１１ｇ」など）、アクセスポイントによってサポートされるセキュリティの種類（「ＷＰＡ」や「ＰＡＮＡおよびＩＰｓｅｃ」など）、第３層の種類（「ＩＰｖ４のみ」や「ＩＰｖ４／ｖ６デュアルスタック」など）、プロバイダ名、あるいはサーバまたはエージェント（ＰＡＮＡ認証エージェント、アクセスルータ、ＳＩＰサーバおよびモバイルＩＰホームエージェントなど）のアドレスが含まれる。
【００２９】
・モバイルの場所またはモバイルがこれに関する情報を探し出そうとする場所は、様々なやり方で識別（表現）できる。例えば、これは、地理的位置によって、ネットワークの識別によって、あるいはネットワーク内の無線アクセスポイントまたはＩＰアクセスルータのアドレスによって識別できる。
【００３０】
ネットワーク情報を探索する機能を使えば、モビリティおよびモバイルサービスがより適切にサポートできる。例えば、ハンドオフ時の実行中のアプリケーションセッションの中断を低減するために、モバイル機器は、目標ネットワークへのハンドオフを開始する前に、目標ネットワークと事前認証を行うことができる。このためには、モバイルは、モバイルが目標ネットワークに移動する前に、目標ネットワーク内の認証サーバのアドレスなど、隣接ネットワークに関する情報を必要とする。モバイルがこれの隣接ネットワークに関する情報を探索するプロセスを、ネットワーク隣接探索と呼ぶ。
【００３１】
ネットワーク探索における重要な問題が、探索データベース構築問題、すなわち、ネットワーク情報のデータベースを、自動化された、動的で効率のよいやり方でどのように構築すべきかである。この問題を解決することは、ネットワークプロバイダが、自社の加入者には、よりよいサービスのために独自のネットワークの詳細なネットワーク情報を提供するが、このプロバイダと競合する他のネットワークプロバイダには、独自のネットワークのどんなネットワーク情報も進んで開示しようとしないこともある複数プロバイダの環境においては、おろそかにできない問題である。しかしながら、これまでは、この問題を解決する実際的な解決法がなかった。
【００３２】
サービス探索のために設計された複数のプロトコルがある。しかしながら、これらのプロトコルのいずれも、
・隣接ネットワークに関する情報を探索すること、
・探索データベースの動的構築、および
・どんな情報を収集し、モバイルに提供すべきかを決定すること
をサポートしていない。
【００３３】
代わりに、既存のサービス探索機構は、データベースにすでにある情報をどのようにして取り出すべきかに焦点を合わせるものである。これらは、全ローカルネットワークプロバイダを利用してサービス情報サーバを実施するが、これは、公衆ネットワークにおいて展開するには厳しすぎる。
【００３４】
本明細書では、探索データベース構築問題を解決する方法、およびモバイルが隣接ネットワークに関する情報を探索する方法を含む、ネットワーク探索をサポートする新しいアーキテクチャについて説明する。このアーキテクチャを、情報サービスのためのアプリケーション層機構（ＡＩＳ）という。ＡＩＳは、モバイルによって必要とするかもしれない、現在および将来のネットワーク情報の種類をサポートするのに充分な拡張可能性を有するように設計される。ＡＩＳは、できる限り既存のプロトコルを利用する。ネットワーク要素に関する情報には複数の使用法が有り得るが、本明細書では、モバイルが事前対応型ハンドオフと保護された事前認証を可能にするのに使用できる情報を探索することに焦点を合わせ、これらの情報を使って、保護された事前対応型ハンドオフがどのようにサポートできるかを論じる。
【００３５】
ＡＩＳアーキテクチャ
情報構築プロセス、情報検索方法、情報サーバに格納される情報の形式が、探索アーキテクチャを設計する際に調べる必要のある重要な設計要因の一部である。
【００３６】
ＡＩＳのためにいくつかのアーキテクチャが設計されている。これらは、大まかに、２つの主要カテゴリ、すなわち、ネットワーク支援型とモバイル支援型とに分類できる。以下の各項では、これらのアーキテクチャ、および異なる機能要素がどのようにして相互に対話し合うことができるかについて述べる。これらのアーキテクチャ選択肢のそれぞれにおいて、モバイルは、ＡＩＳサーバまたはピアモバイルに問い合わせて、隣接ネットワーク内のネットワーキング要素に関する情報を探し出す。情報データベースを構築する方法は、アーキテクチャごとに異なる。ネットワーク支援型アーキテクチャは、分散型と集中型両方のモデルに従うことができる。ＡＩＳサーバは、隣接ネットワーク内のネットワーク要素に関する情報を保持し、モバイルからの問い合わせを取得した後でこの情報を提供する。集中型モデルでは、各ネットワーク内の報告エージェントが、ＳＮＭＰ  ＭＩＢ（簡易ネットワーク管理プロトコル管理情報ベース）を使ってネットワーク内のネットワーキング要素に関する情報を報告する。モバイル支援型モデルは、事実上常に分散されており、各エンドノードが、これらが現在在圏しているネットワークに関する情報を報告する。情報が各モバイルによってＡＩＳサーバから検索されるやり方は、両手法に共通である。
【００３７】
ピアツーピアベースのモデルは、各モバイルが情報サーバとして働き、他のモバイルに情報を提供する別のモバイル支援型モデルである。
【００３８】
情報サーバベースのアーキテクチャ：探索データベース構築
情報サーバベースのアーキテクチャは、モバイル支援型またはネットワーク支援型とすることができる。以下の各項では、ネットワーク情報データベースを構築する、エンドノード支援型とネットワーク支援型両方の手法について述べる。
【００３９】
モバイル支援型の手法
ローカルサービスおよびネットワーキング能力を収集し、維持し、探索する新しいパラダイム（paradigm）を提案する。この新しいパラダイムは、関連する機構の項で述べた既存の手法の限界を克服するものである。この手法は、以下の主要原理を使用する。
【００４０】
・各モバイルユーザは、自分が利用可能な任意の適切な手段を使って、在圏ネットワークで利用可能なネットワーク情報を探索することができる。しばしば、ユーザは、単に、後続のモバイルが在圏ネットワークに関して必要とし得る情報を探索するだけのために、在圏ネットワークから特別な支援を受けなくてもよくなる。例えば、モバイルは、在圏ネットワークに接続するとき、これの在圏ネットワークに接続する通常のプロセスの一部として、在圏ネットワーク内のアクセスルータと認証エージェントのアドレスを知ることになる。かかる情報は、モバイルのＡＩＳサーバに報告され、ＡＩＳサーバは、さらに、後続のモバイルがこの情報を取り出すことができるように、後続のモバイルがこの在圏ネットワークに移動する前に後続のモバイルにこの情報を提供することができる。また、利用可能なホットスポットネットワークとこれのログオン要件の探索のために、ローカルネットワークプロバイダに、特別な支援を提供するよう求める必要もない。
【００４１】
・各モバイルユーザは、在圏ネットワークで探索する情報をこれのＡＩＳサーバに報告する。モバイルのＡＩＳサーバは、モバイルが現在在圏しているネットワークとのどんな信頼関係もなくてよい。
【００４２】
・モバイルユーザのＡＩＳサーバは、様々なネットワークに関してこれの加入者から受け取られるネットワーク情報に関する情報を維持する役割を果たす。
【００４３】
・後続のモバイルがある在圏ネットワークに移動すると、このモバイルは、これのＡＩＳサーバに、必要なローカル情報を問い合わせてもよい。
【００４４】
この手法は、既存の手法に優る以下の主要な利点を有する。
【００４５】
・情報マイニングおよび探索のために、ローカルネットワークプロバイダに頼って、ネットワーク情報の提供に使用される情報サーバを提供することがなくなる。
【００４６】
・モバイルユーザがどこにいるか、およびモバイルユーザが現在どのローカルネットワークを使用しているかを問わず、モバイルは、常に、単一のプロトコルを使って、ネットワーク情報を検索するためにこれのＡＩＳサーバとやりとりする。
【００４７】
・ＡＩＳサーバは、自己の加入者が関心を有する情報を維持するだけでよい。さらに、ＡＩＳサーバは、自己の加入者が移動する場所に関する情報を維持するだけでよい。このため、提案するパラダイムは高度にスケーラブルなものとなり得る。
【００４８】
提案の協働による探索パラダイムの例の基本動作を、図１に示す。図１には、モバイルがどのようにしてネットワーク間を移動し、ネットワークの集合によって一般に共用されるロケーションサーバに対して、ネットワーク要素に関する情報をどのようにして更新することができるかが示されている。この情報は、特定の形式を使ってロケーションサーバに格納される。図１に関しては、ローカルサービスとネットワーク能力の協働による探索を説明する図である。
【００４９】
ネットワーク支援型情報探索
ネットワーク支援型情報探索は、３つの異なる方法を定義する。これらの方法とは、
１．報告エージェント（ＲＡ）支援手法、
２．ＡＡＡ支援手法、
３．ＤＮＳベース手法
である。
【００５０】
報告エージェント支援手法
報告エージェント（ＲＡ）は、各ネットワーク内にあるネットワークエージェントである。これらは、ＳＮＭＰ対応であり、ＳＮＭＰ  ＭＩＢを調べることによってネットワーク要素に関する情報を収集することができる。これらの報告エージェント（ＲＡ）は、個々のドメイン内の情報を収集し、特定の区域のロケーションサーバデータベースに取り込む。この情報は、能力セット、ＩＰアドレス、個々のネットワーク要素の地理座標などを含み得る。特定のネットワーク要素が、あるドメイン内で接続され、または動作状態になると、この要素の情報が報告エージェント（ＲＡ）上にプッシュされ、さらに、ＡＩＳサーバに送られる。よって、この手法は、前述のエンドシステム支援型の手法と比べて、ＡＩＳサーバデータベースにデータを取り込む半集中型の方法を提供するものである。セキュリティ問題は、この場合、あまり大きな問題ではない。というのは、データベース更新が、エンドクライアントによってではなく、特定のネットワーキングエージェントによって提供され、ＲＡと情報サーバの間に事前に確立されるセキュリティアソシエーションがあるからである。
【００５１】
図２に関しては、報告エージェント（ＲＡ）によって報告される情報を使ってデータベースにデータを取り込む例を示す図である。言い換えると、報告エージェント支援データベースが構築される。
【００５２】
ＡＡＡサーバ支援手法
ＡＡＡサーバ支援情報構築は、別のネットワークサーバ支援手法である。各モバイルの情報プロファイルが、ＡＡＡサーバにも保存できる。ＲＡＤＩＵＳおよびＤｉａｍｅｔｅｒなど、任意のＡＡＡプロトコルを使って、ＡＡＡクライアントがモバイルのアドレスとＡＡＡクライアントのアドレスの組をＡＡＡサーバに送るというやり方で、ネットワーク探索データベースにデータを取り込むことができる。この組は、ＲＡＤＩＵＳおよびＤｉａｍｅｔｅｒプロトコルの発呼局ＩＤと被呼局ＩＤ属性として運ばれる。ＡＡＡサーバは、ＡＡＡクライアントから報告される情報を収集し、モバイルの（ＡＡＡクライアントのアドレス、モバイルがＡＡＡクライアントと関連付けられた時刻、モバイルがＡＡＡクライアントから分離された時刻）のタプルのリストを記録することによって、モバイルのモビリティパターンを追跡することができる。次いで、このリストは、モバイルがハンドオフを行うことのできる隣接ネットワークのデータベースを構築するのに使用される。
【００５３】
この手法は、サービスプロバイダが、これのトポロジデータベースを他の競合するサービスプロバイダに開示しようとしないことのある、複数プロバイダの場合には適用できないこともあることに留意する。
【００５４】
ＤＮＳサーバベース手法
また、これらのネットワーク要素のリストを探し出すのに、ＡＩＳサーバを使用するのではなく、ＤＮＳ  ＳＲＶレコードを使用することもできる。ＤＮＳは、常に、ＤＮＳのＬＯＣレコードを使って、ネットワーク要素（ルータ、ＡＰ）およびこれらに関連する地理座標と関連付けられたサービスを取り込むことができる。よって、ＤＮＳサーバに問い合わせ、特定のドメインと地理座標の範囲でのサービスのリストを与え、これらのサービスを提供するネットワーク要素のリストを取得することができる。一般的な問い合わせは次のようなものである。１組の地理座標（Ｒ１−Ｒ２）が与えられたものとして、経路指定、ＩＥＥＥ８０２．１１、ＡＡＡなど、特定のサービスの集合を提供するサーバの集合を探し出す。ＤＮＳ「ＳＲＶ」レコードと地理的場所レコードの組み合わせが、近傍のサーバの集合を突き止めるのに役立つ。
【００５５】
この手法は、任意の構造化ネットワーク情報データベースを形成するためのものではないことに留意されたい。
【００５６】
探索データベースの問い合わせ
保護された事前認証、事前対応型ＩＰアドレス取得などの操作の多くが、モバイルの、ドメイン間、ドメイン内のサブネット間の移動中に必要となる可能性がある。普通、モバイルがサブネットに移動した後で行われるこれらの操作が、前もってなされれば、高速ハンドオフを行うのに役立つであろう。これらの操作を前のドメイン／サブネットにいる間に行うためには、モバイルは、移動が終わる前に次のホップルータおよびサーバとやりとりする必要がある。よって、モバイルは、近隣ネットワークに移動する前に、ＡＰ、ルータ、ＤＨＣＰサーバ、およびＰＡＮＡ認証エージェントなどいくつかの認証エージェント、ならびに、場合によってはＳＩＰサーバを含む隣接情報を探索することが必要になる。ネットワーク探索によるこの情報は、モバイルが、事前認証や事前対応型ＩＰアドレス割り当てなど数種類の操作を、前もって行うのに役立つ。以下で、モバイルが隣接ネットワーク要素を探索するのに役立つ１つの機構について述べる。ＤＮＳ「ＳＲＶ」機構は、隣接ドメイン内のかかるネットワーク要素のリストを提供する別の手法を提供する。
【００５７】
最初に、モバイルが、起動し、ＩＰアドレスを獲得し、デフォルトのゲートウェイなど他のネットワークパラメータ、およびいくつかのサーバパラメータなどでモバイル自体を構成する。モバイルは、対応するホストとの通信を開始し、あるポリシに基づくこれの通信中のある時点において、モバイルが移動するものと判断する。よって、モバイルは、いくつかの異なるやり方でＡＩＳプロセスを開始する。モバイルは、問い合わせを行うとき、常に、これの場所情報をルックアップキーとして使用することができる。場所情報は、アクセスポイントのＭＡＣアドレス、地理的アドレスまたは他の任意の都市アドレスとすることができる。アクセスポイントのＭＡＣアドレスがルックアップキーとして使用されるとき、モバイルは、（ｉ）モバイルがアクセスポイントの無線到達範囲内にある場合にはビーコンフレームをリッスンすることによって、または（ｉｉ）再帰が、方法（ｉ）に基づいてモバイルに知られているアクセスポイントのＭＡＣアドレスを指定することから開始する問い合わせ手順を再帰的に行うことによって、ＭＡＣアドレスを獲得することができる。
【００５８】
サーバは問い合わせを取得し、問い合わせの種類に基づいて求められた属性のリストの報告を返す。クライアントがＧＰＳを装備している場合、クライアントは、常に、自己の場所を見出し、どこに移動しようとするが判定し、よって、情報ルックアップの一部として範囲を提供し、所望のネットワーク情報を獲得することができる。
【００５９】
図３に関しては、ネットワーク探索、問い合わせおよび応答のための動作のプロトコルの交換と順序を示す図である。
【００６０】
図４Ａおよび４Ｂには、モバイルが、そこに移動する可能性を有する隣接サーバとルータのアドレスを取得することができるように、前もって隣接サーバ／ルータを探索するクライアントのいくつかの例示的シナリオが示されている。図４Ａと図４Ｂでは、それぞれ、モバイルの地理座標の範囲とアクセスポイントのＭＡＣアドレスが、問い合わせのルックアップキーとして使用される。ネットワーク探索プロセスは、前もって、隣接サーバ、ルータおよびアクセスポイントを探索するのに役立つ。前もってサーバを探索することによって、事前認証を行うことができ、よって、移動時のハンドオフ時間が早まる。モバイルは、目下、アクセスポイントＡＰ０に接続しており、モバイルがそこに移動する可能性を有する３つの隣接ネットワークＤ１、Ｄ２およびＤ３がある。よって、モバイルは、特定のキーを用いてＡＩＳサーバに問い合わせることができ、保護されたハンドオフを準備するためにやりとりすることのできるドメインＤ１、Ｄ２およびＤ３内の隣接ＡＰ、サーバおよびルータに関する情報を取得することができる。以下の段落に、モバイルが起動した後の動作シーケンスを示す。
【００６１】
１）モバイルが起動し、特定のアクセスポイントに接続する。モバイルは、ＤＨＣＰやＰＰＰなどを介し、ＩＰアドレス構成手順によってＩＰアドレスを獲得する。ＤＨＣＰサーバまたはＰＰＰサーバは、様々なＩＰアドレスを有し得る。地理座標がルックアップキーとして使用されるときには、地理座標の範囲がこれらのＩＰアドレスと関連付けられ、ＩＰアドレス構成手順においてＩＰアドレスと一緒にモバイルに配信される。ありとあらゆるモバイルがＧＰＳを装備しているとは限らないことが想定される。モバイルが自己の地理座標（Ｒ０）を知っており、地理座標がルックアップキーとして使用される場合には、モバイルは、これの地理座標をルックアップキーとして使用することもできる。特定の区域のＡＩＳサーバのＩＰアドレスは、ＩＰアドレス構成手順の間に、またはＤＮＳを使って提供され得る。
【００６２】
２）また、隣接セルが異なるドメインに属することもあり得る。ＤＨＣＰ構成から、モバイルは、これの現在のドメイン（「ａｔｔ．ｃｏｍ」や「ｓｐｒｉｎｔ．ｃｏｍ」など）を探し出すことができる。また、獲得されたネットワーク要素のＩＰアドレスから、逆ＤＮＳルックアップを使って隣接領域のドメイン名を探し出すこともできる。
【００６３】
３）モバイルは、これの現在接続されているＡＰとアクセスルータを使って、例えば以下のように、ＡＩＳサーバに要求を出すことができる。
【００６４】
ａ．要求は、モバイルが、条件（地理範囲［Ｒ１−Ｒ２］内や「１マイル以内」など）を指定して、特定の場所（地理的場所Ｒ０やＡＰ０のＭＡＣアドレスなど）について検索しようとするネットワーク情報の種類（ｔｙｐｅ＝”ＰＡＮＡ認証サーバ”、”ルータ”など）のリストを含む。条件は、モバイルの速度またはモビリティパターンに基づいて決定できる。
【００６５】
ｂ．ＡＩＳサーバは、別個にデータが取り込まれている独自のデータベースに問い合わせることによって、要求で指定された条件を満たすネットワーク情報（サーバとルータのＩＰアドレス、ＡＰのＭＡＣアドレスなど）のリストを返す。
【００６６】
ｃ．この情報から、モバイルは、モバイルが移動する可能性が高いネットワークのリストを有し、よって、時間制約の事前認証および／または事前対応型ＩＰアドレス獲得を行う。
【００６７】
図４Ａに関しては、地理座標ベースのネットワークサービス探索の例を示す図であり、図４Ｂに関しては、ＡＰのＭＡＣアドレスベースのネットワークサービス探索の例、すなわち、情報問い合わせの例を示す図である。
【００６８】
ＡＩＳが提供することのできる、データベース問い合わせのさらに別の機能がある。例えば、モバイルに提供されるべきネットワーク情報を選択するのに使用される基準は、モバイルによって指定されても、ＡＩＳサーバによって指定されても、両方のエンティティによって指定されてもよい。ＡＩＳサーバが基準を指定すると、モバイルのプロファイルが基準として使用できる。この場合、ＡＩＳは、高級のＡＩＳサービスに加入しているモバイルに、低級のＡＩＳサービスに加入しているモバイルよりも詳細なネットワーク情報を提供してもよい。
【００６９】
ピアツーピアモデル
ピアツーピアモデルは、情報格納と検索のための情報サーバに依存しない。代わりに、各モバイル端末が情報サーバとして働く。本明細書では、事前対応型ブロードキャストや設定範囲マルチキャストなど、２つのピアツーピアベースモデルについて述べる。
【００７０】
提案するピアツーピアモデルでは、
・ネットワーク間を移動する各モバイルが、在圏したばかりのネットワークに関する情報を、特定の期間にわたってこれのローカルキャッシュに保持する。
【００７１】
・モバイルの各隣接機器は、隣接ネットワークに関する異なる情報を有する。
【００７２】
セキュアな事前認証への適用可能性
ここで述べるネットワーク探索機構は、例えば、以下のシナリオを含む、異なるアクセスネットワーク間でのこの種のハンドオーバすべてに役立ち得る。
【００７３】
・８０２．１１ネットワークと８０２．３ネットワークの間のハンドオーバ
・８０２．３ネットワークと８０２．１６ネットワークの間のハンドオーバ
・８０２．１１ネットワークと８０２．１６ネットワークの間のハンドオーバ
・８０２．１１ネットワークと８０２．１１ネットワークの間の、ＥＳＳをまたぐハンドオーバ
・８０２．３ネットワークとセルラネットワークの間のハンドオーバ
・８０２．１１ネットワークとセルラネットワークの間のハンドオーバ、および／または
・８０２．１６ネットワークとセルラネットワークの間のハンドオーバ
好ましい実施形態では、探索手法は、異種混交と同種両方のハンドオフシナリオに適用することができる。
【００７４】
・同種のシステム間の移動
-単一インターフェース（８０２．１１、ＥＥＳ間など）
-複数インターフェース（８０２．１１、ＥＥＳ間など）
・異種混交ネットワーキングシステム間の移動は常にデュアルモードである。
【００７５】
-８０２．３、８０２．１１
-８０２．１１、ＣＤＭＡ／ＧＳＭ（セルラ）
-セルラネットワーク間（ＣＤＭＡ、ＧＳＭ）
-８０２．１１、８０２．１６、８０２．２０
-８０２．１１、回路交換
例として、図５Ａに、単一無線インターフェースのローミングシナリオが示されている、移動ノードのドメイン内とドメイン間のハンドオフの例を示し、図５Ｂに、複数無線インターフェースのローミングシナリオが示されている、セルラ環境とＷＬＡＮ環境の間のハンドオフの例を示す。
【００７６】
８０２．２１の下でのＭＩＨ機能
ＭＩＨ機能の主な役割は、ハンドオフを円滑に行わせ、他の規格または独自の実現形態によって記述されるハンドオーバ決定の責任を負うネットワーク選択エンティティまたはモビリティ管理エンティティにインテリジェンスを提供することである。ＭＩＨ機能は、イベントサービス、コマンドサービスおよび情報サービスの助けを借りて、ネットワーク選択エンティティを支援する。ネットワーク選択エンティティおよびハンドオーバを制御するハンドオーバポリシは、ＭＩＨ機能の適用範囲外である。特定のハンドオーバポリシの記述およびネットワーク選択エンティティの詳細もまた、８０２．２１規格の適用範囲外である。
【００７７】
ＩＥＥＥ８０２．２１規格は、異種混交アクセスリンク間のハンドオーバを強化するサービスを定義する。これは、ハンドオーバ検出、ハンドオーバ開始およびＭＩＨユーザによる候補リンク選択に関連するリンク層インテリジェンスを提供することにより、ハンドオーバプロセスを円滑化することを通じて達成される。
【００７８】
・メディア独立のイベントサービス（ＭＩＥＳ）は、リンク特性、リンク状況およびリンク品質の動的変更に対応するイベント分類、イベントフィルタリングおよびイベント報告を提供する。
【００７９】
・メディア独立のコマンドサービス（ＭＩＣＳ）は、ＭＩＨユーザがハンドオーバとモビリティに関連するリンク挙動を管理し、制御することができるようにする。
【００８０】
・メディア独立の情報サービス（ＭＩＩＳ）は、サービス提供する、周辺のネットワークによって提供される特性とサービスに関する詳細を提供する。この情報は、効果的なシステムアクセスおよび効果的なハンドオーバ決定を可能にする。
【００８１】
・上記のサービスは、ＭＩＨユーザのモビリティ管理とハンドオーバプロセスを円滑に行わせるために、メディア独立のハンドオーバ機能（ＭＩＨＦ）によってサポートされる。ＭＩＨ機能は、複数の異種混交アクセス技術からのリンク層状態情報を、モビリティ管理プロトコルスタックの上位層への統一された表示に収束させる。
【００８２】
８０２．２１規格案は、特に、以下の一般設計原理に基づくものである。
【００８３】
・メディア独立のハンドオーバ（ＭＩＨ）機能は、モバイルノードと、モビリティサポートを提供するネットワーク要素の両方のモビリティ管理プロトコルスタックにおけるシム層（shim layer）として論理的に定義される。ＭＩＨは、ハンドオーバ決定に役立つ支援促進機能である。上位層が、ＭＩＨからの入力とコンテキストに基づいて、ハンドオーバ決定とリンク選択を行う。ハンドオーバが行われるべきであるという認識を容易にすることが、ＭＩＨ機能の主要な目標の１つである。また、どのようにして効果的なハンドオーバ決定を行うべきかに関する情報の探索も、重要な構成要素である。
【００８４】
・ＭＩＨ機能は、上位層に抽象化されたサービスを提供する。この意味で、ＭＩＨは、上位層への統一インターフェースを提供する。この統一インターフェースによって公開されるサービスプリミティブは、異なるアクセスネットワークの技術特有のプロトコルエンティティから独立である。ＭＩＨ機能は、技術特有のインターフェースを介してモビリティ管理プロトコルスタックの下位層とやりとりする。下位層とのＭＩＨインターフェースの規格は、一般に、８０２．２１の適用範囲内に含まれない。かかるインターフェースは、すでに、ＩＥＥＥ８０２．１、ＩＥＥＥ８０２．３、ＩＥＥＥ８０２．１１、ＩＥＥＥ８０２．１６、３ＧＰＰ、３ＧＰＰ２といった、個々のアクセス技術に付随する規格内でサービスアクセスポイント（ＳＡＰ）として規定されている。
【００８５】
メディア独立の情報サービス（ＭＩＩＳ）は、ＭＩＨＦ（メディア独立のハンドオーバ機能）エンティティが、ハンドオーバを円滑化するために地理的領域内に存在するネットワーク情報を探索し、獲得するためのフレームワークと対応する機構を提供する。ＭＩＩＳは、主に、情報要素（ＩＥ）の集合、情報構造およびこれの表現、ならびに情報転送の機構の問い合わせ／応答の種類を提供する。これは、イベントサービスのための情報転送の非同期プッシュモデルと対照をなす。情報は、ＭＩＨ機能（ＭＩＨＦ）エンティティ内に格納されてもよく、局内のＭＩＨがそこから情報にアクセスすることのできる何らかの情報サーバ内にあってもよい。
【００８６】
情報は、上位層のみならず、下位層を介しても利用可能にすることができる。情報は、セキュアなポートとセキュアでないポートの両方を介してＬ２で利用可能にすることができる。スキーマの構造と定義は、ＸＭＬなどの高水準言語で表現できる。
【００８７】
また、情報サービスは、隣接機器報告など、静的情報へのアクセスも可能にする。この情報は、ネットワーク探索に役立つ。また、このサービスは、異なるネットワークとのリンク層接続を最適化できる動的情報へのアクセスも可能にする。これには、チャネル情報、ＭＡＣアドレス、セキュリティ情報などのリンク層パラメータが含まれ得る。また、ネットワーク内の利用可能な上位層サービスに関する情報も、モバイル端末が実際に任意の特定のネットワークに接続する前に、より効果的なハンドオーバ決定を行うのに役立つことができる。
【００８８】
メディア独立の情報サービスは、ＸＭＬやＡＳＮ．１などの標準化形式を使って、異なる技術にまたがってこの情報を表す共通の（またはメディア独立の）方法を指定する。
【００８９】
ＭＩＩＳは、８０２．２１ＭＩＩＳサービスがどのようにして実施されるかに応じて、任意の単一Ｌ２ネットワークから、ある地理的領域内のすべての異種混交ネットワークに関するこの情報にアクセスさせることができる。ＭＩＩＳは、既存のアクセスメディア特有のトランスポートとセキュリティ機構、またはＬ３トランスポートとＬ３セキュリティ機構を利用して、情報へのアクセスを可能にする。通常、複数の種類のメディアで構成される異種混交ネットワークでは、異なる種類のメディアから情報を収集し、メディア間ハンドオーバ決定を円滑化するための統合されたビューを組み立てるのは、ハンドオーバ決定モジュールまたは上位層モビリティ管理である。
【００９０】
セルラネットワークなどいくつかのネットワークは、すでに、ブロードキャスト制御チャネルを介して、ある領域の近傍内にある隣接基地局のリストを検出する既存の手段を有する。他のＩＥＥＥグループは、類似の手段を定義し、ビーコン送信によって、またはＭＡＣ管理メッセージのブロードキャストによって、クライアントがある領域の近傍内の隣接アクセスポイントのリストを検出するのをサポートする。メディア独立の情報サービス（ＭＩＩＳ）は、異種混交ネットワーク環境全体の上位層モビリティプロトコル（ＨＬＭＰ）が、クライアントによる、地理的領域内に存在する複数の種類のネットワークの探索と選択を円滑に行わせるのに役立つ、統一フレームワークを提供する。より大きな視野での大きな目的は、上位層モビリティプロトコルが、異種混交ネットワークの全体的視野を獲得して、これらのネットワークにまたがるローミング時のシームレスなハンドオーバを円滑に行わせるのを支援することである。
【００９１】
スキーマ設計
ＡＩＳは、ルータとアクセスポイントのどんな変更も行わずに、アクセスポイントとルータの既存の規格を使用するフレームワークを提供する。いくつかの実施形態では、データベーススキーマは、ＸＭＬ、ＲＤＦおよびＳＯＡＰを使用する。ＲＤＦデータベースは、多数のネットワークまで拡張することができるように分散方式で構築できる。また、ＬＤＡＰはツリーベースのデータ構造だけを扱うが、ＲＤＦは、任意の相互接続されたデータ構造も扱うことができる。ＲＤＦは、データ自体のみならず、問い合わせスキーマも提供することができる。
【００９２】
情報サービススキーマ
スキーマは情報の構造を定義する。スキーマは、８０２．２１情報サービスで、各情報要素の構造、ならびに、サポートされる異なる情報要素間の関係を定義するのに使用される。８０２．２１情報サービススキーマは、柔軟で効率的な情報問い合わせをサポートするためにＭＩＩＳを実施するあらゆるＭＩＨ機能によってサポートされる必要がある。８０２．２１情報サービスは、様々な情報要素とこれらの構造を定義する。様々なＩＥは、ネットワークスタックの下位層に関する情報、ならびに、異なるアクセスネットワークで利用可能な上位層サービスに関する情報を表す。スキーマは、１つの言語で定義され、複数の方法で表すことができる。例としては、ＸＭＬ、８０２ＭＩＢで使用されるＡＳＮ．１、バリアント、あるいは異なる情報要素の単純なＴＬＶ表現などに基づくリソース記述フレームワーク（ＲＤＦ）が含まれる。
【００９３】
ＭＩＩＳスキーマは、２つの主要カテゴリに分類される。これらは、サポートすべきあらゆるＭＩＨに不可欠な基本スキーマと、任意選択で、ベンダ特有とすることのできる拡張スキーマである。
【００９４】
ＲＤＦスキーマ表現
本項では、リソース記述フレームワーク（ＲＤＦ）を使ったスキーマの例を示す。3GPP TS23.234、「3GPP system to Wireless Local Area Network (WLAN) inter-working; System description」（参照文献［８］）を参照されたい。ＲＤＦは、情報を問い合わせるための問い合わせ言語として、SPARQL(3GPP TS23.060「General Packet Radio Service (GPRS); Service Description; Stage 2」（参照文献［７］）参照）を使用する。ＲＤＦスキーマもＳＰＡＲＱＬもＸＭＬで表される。ＲＤＦスキーマは、式の集合の構造を定義し、任意の式の基礎構造は、それぞれが、主部、述部、目的部の３部分からなるものの集合体である。ＲＤＦ／ＸＭＬというＲＤＦのＸＭＬ構文が、GPP TR43.901「Feasibility Study on Generic Access to A/Gb interface」（参照文献［９］）で定義されている。
【００９５】
ＲＤＦには、例えば、以下の利点がある。即ち、
・階層と非階層両方の情報構造をサポートする。
【００９６】
・柔軟なデータ問い合わせを可能にする。
【００９７】
・分散スキーマ定義を可能にする。
【００９８】
・スキーマ定義を変更するのがより容易な方法である。
【００９９】
以下で論じるように、ＭＩＩＳのＲＤＦスキーマ定義は、２つの部分、すなわち、基本スキーマと拡張スキーマを有する。基本スキーマは、更新されないものとされる。ＭＩＨエンティティには、通常、スキーマベースの問い合わせを実施しやすいように、基本スキーマが予め用意されている。基本スキーマが予め用意されていないシナリオでは、ＤＮＳ問い合わせなどの方法を使って、基本スキーマの場所（ＦＱＤＮ）にアクセスされてもよい。
【０１００】
基本スキーマとは異なり、拡張スキーマは、周期的に、例えば、新しいリンク層技術が導入されるときなどに更新されることが期待される。拡張スキーマは、かかる拡張スキーマが事前に用意されていなくても、「IEEE802.21 Media Independent Handover Services21-05-xxxx-00-0000-One_Proposal_Draft_Text」のセクション８．５．３に記載されているスキーマ問い合わせ機能を使い、ＩＥＥＥ８０２．２１情報サービスを介して、指定のＵＲＬから検索できる。また、拡張スキーマのＵＲＬも、上記セクション８．５．３に記載されているスキーマＵＲＬ問い合わせ機能を介して獲得できる。代替として、ＤＮＳ問い合わせを使って、拡張スキーマの場所（ＦＱＤＮ部分）を探し出してもよい。拡張スキーマは、基本スキーマの拡張として定義され、メディア特有の、または上位層の情報のデータ構造と関係を含む。この意味で、拡張スキーマは、基本スキーマを補完するものである。
【０１０１】
ＩＥＥＥ８０２．２１情報サービスのためのＲＤＦ／ＸＭＬスキーマ定義
ＩＥＥＥ８０２．２１情報サービスのためのＲＤＦ／ＸＭＬスキーマ定義は、２つの部分、すなわち、基本スキーマと拡張スキーマを有する。あらゆるＭＩＨエンティティには、基本スキーマが予め用意されている必要がある。基本スキーマは、更新されないものとされる。ＲＤＦ／ＸＭＬスキーマの残りは、拡張スキーマである。基本スキーマとは異なり、拡張スキーマは、例えば、新しいリンク層技術が導入されるときなどの、更新がサポートされており、ＭＩＨエンティティには、拡張スキーマが予め用意されていなくてもよい。代わりに、拡張スキーマは、上記参照により本明細書に組み込まれている先の特許出願に記載されているスキーマ問い合わせ機能などを使って、情報サービスを介して検索できる。
【０１０２】
ＸＭＬとＴＬＶを統合する好ましい実施形態
いくつかの好ましい実施形態では、ＸＭＬとＴＬＶ両方の形式が情報探索に使用される。ＲＤＱＬによって獲得される問い合わせと応答のサイズは、ＴＬＶの問い合わせと応答のサイズよりはるかに大きい。しかしながら、基本スキーマがより平坦な構造に変更されれば、問い合わせと応答のサイズは縮小される。他方、ＸＭＬベースの問い合わせは、より大きな拡張可能性と柔軟性を提供する。
【０１０３】
（無線などによって）送信されるバイト数などを減らすために、ＸＭＬの圧縮バージョン（gunzipなど）が使用できる。ＸＭＬの圧縮バージョンを使用することによって、情報問い合わせ時に、探索時間がある程度まで短縮できる。以下で、ＸＭＬとＴＬＶの統合を使用するいくつかの例について説明する。
【０１０４】
最も費用効果的に問い合わせと応答をサポートするためには、拡張可能性、柔軟性および効率性を備えることが望ましい。これに関しての２つの可能な解決法の候補として、例えば、ＸＭＬとＴＬＶが含まれる。この場合、ＸＭＬは、スキーマベースの意味問い合わせを提供するが、固有のＸＭＬ１．０形式などを使用する場合には、無線でより多くのビットを送る必要がある。他方、ＴＬＶは、バイナリ符号化を行うが、意味問い合わせのための標準問い合わせ言語を提供しない。
【０１０５】
いくつかの手法では、ＸＭＬとＴＬＶを統合するために、ＸＭＬデータがＴＬＶに変換される。以下で述べるいくつかの説明例では、２つの方法を説明する。これに関して、第１の方法（方法Ａなど）は、任意のＸＭＬデータに適用することができ、第２の方法（方法Ｂなど）は、特定の問い合わせ言語に適用することができる。これに関して、ＸＭＬベースの問い合わせ言語は、通常、３種類の問い合わせ、例えば、構成問い合わせ、選択問い合わせおよび論理問い合わせなどを有する。
【０１０６】
これらの問い合わせに関して、構成問い合わせは、サブパラグラフを取り出すのに使用され、選択問い合わせは、選択バインディングに使用され、論理問い合わせは、「ＹＥＳ」または「ＮＯ」に使用される。
【０１０７】
前述のように、本発明の好ましい実施形態によれば、ＸＭＬデータ（ＸＭＬ１．０データなど）をＴＬＶ形式に変換する２つの方法が提供される。以下の考察では、これら２つの方法とＸＭＬ１．０を、前述の３種類の典型的な問い合わせでの符号化オクテット数と処理時間に関して比較する。
【０１０８】
情報サービスプロパティ
いくつかの好ましい実施形態によれば、情報サービス表現および情報問い合わせ／交換は、好ましくは、以下の特徴を有する（トランスポート／プロトコル要件を除く、ＩＳ要件など）。即ち、
・拡張可能である。即ち、
・この仕様は、好ましくは、既存のＰＨＹ／ＭＡＣ技術のみならず任意の将来のＰＨＹ／ＭＡＣ技術もサポートすることができ、新しいＰＨＹ／ＭＡＣ技術が考案されるたびに８０２．２１仕様自体を変更しないものとする。
【０１０９】
・柔軟である。即ち、
・この仕様は、好ましくは、異なるハンドオーバ機構、プロトコル、アルゴリズムおよびポリシに役立つ様々な種類の問い合わせをサポートすることができるものとする。
【０１１０】
・効率的である。即ち、
・この仕様は、好ましくは、（ａ）不要な情報問い合わせ／交換を回避し（問い合わせ効率）、（ｂ）より少ない情報符号化オーバーヘッドを有する（符号化効率）。
【０１１１】
好ましい実施形態によれば、以下のように、バイナリ符号化を伴うスキーマベースの意味問い合わせが関与する有利な手法が提供される。
【０１１２】
・好ましい実施形態では、このスキーマは、拡張可能性を提供する。
【０１１３】
・好ましい実施形態では、この意味問い合わせは、柔軟性と問い合わせ効率を提供する。
【０１１４】
・好ましい実施形態では、このバイナリ符号化は、符号化効率を提供する。
【０１１５】
好ましい実施形態では、これらの機能は、ＸＭＬとＴＬＶを、各解決法の最善を達成するように統合することによって実現できる。
【０１１６】
これに関して、いくつかの実施形態では、各解決法は、以下を伴う。
【０１１７】
・ＸＭＬは、スキーマベースの意味問い合わせを提供する。しかしながら、ＸＭＬは、例えば、固有のＸＭＬ１．０形式などを使用する場合には、無線でより多くのビットを送る必要がある（注：８０２．２１草案における解決案には、ＲＤＦ／ＸＭＬ＋ＳＰＡＲＱＬが関与する）。
【０１１８】
・ＴＬＶは、バイナリ符号化を提供する。しかしながら、ＴＬＶは、意味問い合わせのための標準問い合わせ言語を提供しない。
【０１１９】
いくつかの好ましい実施形態では、ＸＭＬとＴＬＶは、以下のように統合できる。特に、いくつかの実施形態によれば、可能な手法には、ＸＭＬバイナリ表現が関与する。かかる可能な手法によれば、問い合わせ結果に含まれるＸＭＬデータは、ＴＬＶに変換される。
【０１２０】
いくつかの好ましい実施形態では、ＸＭＬデータを変換するために、エイリアスベースの（簡単で軽量な）方法が用いられ、この方法は、例えば、ａ）ＸＭＬネームスペース名を整数に変換すること、ｂ）ＸＭＬタグ名を整数に変換すること、ｃ）ＸＭＬ属性名を整数に変換すること、およびｄ）ＥＮＴＲＹ名を整数に変換することを含む。
【０１２１】
いくつかの好ましい実施形態では、静的または動的な整数マッピングが使用できる。例えば、静的マッピングは、事前定義タグおよび／または属性などに使用できる。他方、動的マッピングは、他のタグ、属性および／またはネームスペースなどに使用できる。いくつかの実施形態では、動的マッピングが、データと共に搬送され、かつ／または帯域外機構を介して提供できる。
【０１２２】
好ましい実施形態のいくつかでは、２つの例示的変換方法（以下の方法Ａと方法Ｂなど）が、以下で述べるように使用できる。
【０１２３】
・方法Ａ：第１の、すなわち、任意のＸＭＬデータなどに適用可能な方法では、好ましくは、以下のステップが用いられる。
【０１２４】
・第１のステップでは、
・ＸＭＬ名前空間名を整数に変換すること、
・ＸＭＬタグ名を整数に変換すること、
・ＸＭＬ属性名を整数に変換すること、
・ＥＮＴＲＹ名を整数に変換すること
を含む、エイリアスベースの変換が行われる。
【０１２５】
・第２のステップでは、
・好ましくは、データと共に伝えられるマッピング
を含む動的整数マッピングが行われる。
【０１２６】
・方法Ｂ：例えば、特定の問い合わせ言語に適用可能な第２の方法では、好ましくは、以下のステップが用いられる。
【０１２７】
・第１のステップでは、
・さらなる最適化のために、２つ以上の意味的に関連するＸＭＬタグを単一の整数にマップすること、
・問い合わせ言語構文の知識を利用すること
を含む意味的バンドリングが行われる。
【０１２８】
・第２のステップでは、別の操作に方法Ａを適用する。
【０１２９】
いくつかの例示的、非限定的実施形態による、方法Ａの実施に関連するいくつかの態様を図６Ａ乃至６Ｒに示す。
【０１３０】
図６Ａには、ＸＭＬバイナリ符号化のためのＴＬＶ形式を示し、図６Ｂには、ＳＴＲ  ＴＬＶ（値フィールドはオクテットストリングを含む）を示す。図６Ｃには、ＳＴＲＡＬＤＥＦ  ＴＬＶ（値フィールド：ストリングエイリアス番号およびオクテットストリング）を示す。図６Ｅには、＜？ｘｍｌ  ｖｅｒｓｉｏｎ＝”．．．”＞タグに対応するＸＭＬＶＥＲ  ＴＬＶを示す。値フィールドは、バージョンストリングを含む。＜？ｘｍｌ  ｖｅｒｓｉｏｎ＝”１．０”＞の場合、ＸＭＬＶＥＲ  ＴＬＶは省略できる。図６Ｆには、＜！ＤＯＣＴＹＰＥ  ｄｏｃｕｍｅｎｔ＿ｔｙｐｅ＞コメントタグに対応するＤＯＣＴＹＰＥ  ＴＬＶを示す。値フィールドは、ｄｏｃｕｍｅｎｔ＿ｔｙｐｅストリングを含む。図６Ｇには、＜！ＥＮＴＲＹ  ｅｎｔｒｙ＿ｎａｍｅ  ｅｎｔｒｙ＿ｖａｌｕｅ＞に対応するＥＮＴＤＥＦ  ＴＬＶを示す。図６Ｈには、第１の非コメントタグに対応するＤＯＣ  ＴＬＶを示す。図６Ｉには、「ｘｍｌｎｓ：ｎａｍｅｓｐａｃｅ＿ｎａｍｅ」属性に対応するＮＳＤＥＦ  ＴＬＶを示す。図６Ｊには、「ｘｍｌｎ：ｂａｓｅ」属性に対応するＢＡＳＥ  ＴＬＶを示す。図６Ｋには、第１の非コメントタグを除く非コメントタグに対応するＴＡＧＤＥＦ  ＴＬＶを示す。明示的ネームスペースがない場合には、ＮＳ番号値は０である。図６Ｌには、事前定義タグ番号（１．．．９９９）を示す。図６Ｍには、非コメントタグに対応するＴＡＧ  ＲＬＶを示す。図６Ｎには、タグ内のａｔｔｒｉｂｕｔｅ＿ｎａｍｅ＝ａｔｔｒｉｂｕｔｅ＿ｖａｌｕｅ部分に対応するＡＴＲＤＥＦ  ＴＬＶを示す。図６Ｏには、事前定義属性番号（１．．．９９９）を示す。図６Ｐには、タグ内のａｔｔｒｉｂｕｔｅ＿ｎａｍｅ＝ａｔｔｒｉｂｕｔｅ＿ｖａｌｕｅ部分に対応するＡＴＲ  ＴＬＶを示す。明示的エントリがない場合には、エントリ番号値は０である。図６Ｑには、ＥＮＴ  ＴＬＶを示す。図６Ｒには、ＮＳ  ＴＬＶを示す。
【０１３１】
ＸＭＬで使用される問い合わせの種類に関して、ＳＰＡＲＱＬなど、ＸＭＬベースの問い合わせ言語は、３種類の問い合わせ、すなわち、構成問い合わせ、選択問い合わせおよび論理問い合わせを有する。特に、これらの問い合わせの種類に応じて、ＳＰＡＲＱＬ問い合わせ結果などに含まれるＸＭＬデータには２種類のＸＭＬデータがある。
【０１３２】
・構成問い合わせ：部分グラフ取り出しに使用される。
【０１３３】
・構成問い合わせでは、ＸＭＬのＲＤＦの３部分が返される。
【０１３４】
・選択問い合わせ：選択バインディングに使用される。
【０１３５】
・選択問い合わせでは、ＸＭＬの選択バインディング（変数名と値の対など）が含まれ、返される。
【０１３６】
・論理問い合わせ：バイナリの応答に使用される。
【０１３７】
・論理問い合わせでは、ＸＭＬの「ＹＥＳ」または「ＮＯ」が含まれ、返される。
【０１３８】
参考のために、図７Ａに、構成問い合わせの説明例を示す。これに関して、この問い合わせは、例えば、隣接接続点（ＰｏＡ）のＩＥを獲得するものとすることができる。加えて、図７Ｂ（１）と７Ｂ（２）に、図の左側にＸＭＬ１．０の問い合わせ結果が示され、図の右側にＴＬＶのＸＭＬバイナリの問い合わせ結果が示されている、構成問い合わせ結果の説明例も示す。
【０１３９】
参考のために、図７Ｃに、選択問い合わせの説明例を示す。これに関して、この問い合わせは、例えば、隣接接続点（ＰｏＡ）を獲得するものとすることができる。加えて、図７Ｄに、図の左側にＸＭＬ１．０の問い合わせ結果が示され、図の右側にＴＬＶのＸＭＬバイナリの問い合わせ結果が示されている、選択問い合わせ結果の説明例も示す。
【０１４０】
参考のために、図７Ｅに、論理問い合わせの説明例を示す。これに関して、この問い合わせは、例えば、隣接ＰｏＡが８０２．１１などであるかどうか尋ねるものとすることができる。加えて、図７Ｆに、図の左側にＸＭＬ１．０の問い合わせ結果が示され、図の右側にＴＬＶのＸＭＬバイナリの問い合わせ結果が示されている、論理問い合わせ結果の説明例も示す。
【０１４１】
方法Ｂに関しては、別の手法が、ＸＭＬではなく、ＳＰＡＲＱＬについて最適化できる。これに関して、ＳＰＡＲＱＬの結果の特性は以下の通りである。
【０１４２】
−（部分グラフ取り出しなどに使用される）構成問い合わせでは、結果は、ＲＤＦの３部分（主部、述部、目的部など）のシーケンスなどである。
【０１４３】
−選択問い合わせでは、結果は、変数と値の表などである。
【０１４４】
−論理問い合わせでは、結果は、「ＹＥＳ」または「ＮＯ」などである。
【０１４５】
いくつかの例示的、非限定的実施形態による、方法Ｂの実施に関連するいくつかの態様を、図８Ａから８Ｆに示す。
【０１４６】
図８Ａには、ＹＥＳ  ＴＬＶが示され、図８Ｂには、ＮＯ  ＴＬＶが示され、図８Ｃには、ＢＬＡＮＫＮＯＤＥ  ＴＬＶが示され、図８Ｄには、ＲＤＦＴＲＩＰＬＥＳ  ＴＬＶが示され、図８Ｅには、ＶＡＲＩＡＢＬＥ  ＴＬＶが示され、図８Ｆには、ＲＥＳＵＬＴ  ＴＬＶが示されている。
【０１４７】
図８Ａを参照すると、いくつかの説明例では、以下のＹＥＳ  ＴＬＶ態様が使用できる。
【０１４８】
・値フィールド：ヌル。
【０１４９】
・このＴＬＶは、ＳＰＡＲＱＬの論理問い合わせでの「ＹＥＳ」の結果などを符号化するのに使用できる。
【０１５０】
・好ましくは、このＴＬＶが搬送されるとき、同じ問い合わせ結果で搬送される他のＴＬＶは省略できる。
【０１５１】
・好ましくは、このＴＬＶを受け取る受信側ネットワーク機器が、これを、対応するＳＰＡＲＱＬ問い合わせ結果の適切なＸＭＬ形式に復号化する。
【０１５２】
図８Ｂを参照すると、いくつかの説明例では、以下のＮＯ  ＴＬＶ態様が使用できる。
【０１５３】
・値フィールド：ヌル。
【０１５４】
・このＴＬＶは、ＳＰＡＲＱＬの論理問い合わせでの「ＮＯ」の結果などを符号化するのに使用できる。
【０１５５】
・好ましくは、このＴＬＶが搬送されるとき、同じ問い合わせ結果で搬送される他のＴＬＶは省略できる。
【０１５６】
・好ましくは、このＴＬＶを受信する受信側ネットワーク機器が、これを、対応するＳＰＡＲＱＬ問い合わせ結果の適切なＸＭＬ形式に復号化する。
【０１５７】
図９Ａ（１）から９Ａ（２）に、いくつかの実施形態による、ＳＰＡＲＱＬ最適化を伴う構成問い合わせ結果の例を示す。
【０１５８】
さらに、図９Ｂに、いくつかの実施形態によるＳＰＡＲＱＬ最適化を用いた選択問い合わせ結果の例を示す。
【０１５９】
加えて、図９Ｃに、いくつかの実施形態によるＳＰＡＲＱＬ最適化を用いた論理問い合わせ結果の例を示す。
【０１６０】
加えて、図１０に、いくつかの説明的、非限定的な例による各形式のいくつかの比較を表すグラフを示す。
【０１６１】
加えて、図１１は、バイナリデータから内部データへの、直接変換と３段階変換を含む、何種類かの変換を示す図である。
【０１６２】
さらに、図１２は、方法Ａ、Ｂおよびgunzip法での、直接変換と３段階変換による統合手法を使った構成問い合わせに関連するデータ変換時間のいくつかの説明例を示す表である。これに関して、この表には、ＸＭＬとＴＬＶの組み合わせを使用することによって、またはＸＭＬの圧縮バージョン（gunzip）を使用することによって、いかに問い合わせが短縮され得るかを示すいくつかの結果例が示されている。同様に、選択問い合わせ時間と論理問い合わせ時間も、ＸＭＬとＴＬＶの組み合わせを使用することによって短縮される。平均して、選択問い合わせは、構成問い合わせと同様の遅延を生じるが、論理問い合わせの時間は、これのバイト数により、他の２つの問い合わせよりはるかに短い。これに関して、いくつかの実施形態では、論理問い合わせのバイトサイズは、選択問い合わせのバイトサイズの約１０分の１であり、構成問い合わせのバイトサイズの約８分の１である。
【０１６３】
図１３には、ＰＣ上で測定された方法Ａでのデータ変換時間を示す。
【０１６４】
（本発明の広い範囲）
本明細書では、本発明の例示的実施形態を説明しているが、本発明は、本明細書で説明した様々な好ましい実施形態だけに限定されず、本開示に基づけば当分野の技術者によって理解されるはずの、等価の要素、改変、省略、（様々な実施形態にまたがる態様などの）組合せ、適合及び／又は変更を有するありとあらゆる実施形態を含むものである。特許請求の範囲における限定は、特許請求の範囲で用いられる言葉に基づいて幅広く解釈されるべきであり、本明細書において、又は本出願の出願中において記述される例だけに限定されず、これらの例は、非排他的であると解釈されるべきである。例えば、本開示において、「好ましくは」という用語は、非排他的であり、「それだけに限らないが、好ましくは」を意味する。本開示において、かつ本出願の出願中において、手段プラス機能又はステッププラス機能限定は、特定のクレーム限定について、この限定において、ａ）「〜の手段」又は「〜のステップ」が明記されている、ｂ）対応する機能が明記されている、及びｃ）構造、材料又はこの構造をサポートする動作が記載されていないという条件すべてが存在する場合に限り用いられる。本開示において、かつ本出願の出願中において、「本発明」又は「発明」という用語は、本開示内の１つ又は複数の態様を指すものとして使用され得る。本発明又は発明という言葉は、誤って重要度の識別と解釈されるべきではなく、誤ってすべての態様又は実施形態にわたって適用されるものと解釈されるべきではなく（すなわち、本発明はいくつかの態様及び実施形態を有すると理解されるべきであり）、また、誤って本出願又は特許請求の範囲を限定するものと解釈されるべきではない。本開示において、かつ本出願の出願中において、「実施形態」という用語は、任意の態様、特徴、プロセス又はステップ、これらの任意の組合せ、及び／又はこれらの任意の部分などを記述するのに使用され得る。いくつかの例では、様々な実施形態が重なり合う特徴を含み得る。本開示では、「例えば」を意味する「ｅ．ｇ．」という省略用語が用いられ得る。
【図面の簡単な説明】
【０１６５】
【図１】ローカルサービスとネットワーク能力の協働による探索を示す説明図である。
【図２】報告エージェント（ＲＡ）を使ったデータベースへのデータ取り込みを示す説明図である。
【図３】ネットワークサービス探索のプロトコルの流れを示す説明図である。
【図４Ａ】地理座標ベースのネットワークサービス探索アーキテクチャの一例を示す例示的概略図である。
【図４Ｂ】ＡＰのＭＡＣアドレスベースのネットワークサービス探索の一例を示す例示的概略図である。
【図５Ａ】単一無線インターフェースのローミングシナリオを示す、移動ノードのドメイン内とドメイン間のハンドオフの例を示す図である。
【図５Ｂ】複数無線インターフェースのローミングシナリオを示す、セルラ環境とＷＬＡＮ環境の間のハンドオフの例を示す図である。
【図６Ａ】本発明のいくつかの好ましい実施形態による第１の方法の実施に関連する態様を示す図である。
【図６Ｂ】本発明のいくつかの好ましい実施形態による第１の方法の実施に関連する態様を示す図である。
【図６Ｃ】本発明のいくつかの好ましい実施形態による第１の方法の実施に関連する態様を示す図である。
【図６Ｄ】本発明のいくつかの好ましい実施形態による第１の方法の実施に関連する態様を示す図である。
【図６Ｅ】本発明のいくつかの好ましい実施形態による第１の方法の実施に関連する態様を示す図である。
【図６Ｆ】本発明のいくつかの好ましい実施形態による第１の方法の実施に関連する態様を示す図である。
【図６Ｇ】本発明のいくつかの好ましい実施形態による第１の方法の実施に関連する態様を示す図である。
【図６Ｈ】本発明のいくつかの好ましい実施形態による第１の方法の実施に関連する態様を示す図である。
【図６Ｉ】本発明のいくつかの好ましい実施形態による第１の方法の実施に関連する態様を示す図である。
【図６Ｊ】本発明のいくつかの好ましい実施形態による第１の方法の実施に関連する態様を示す図である。
【図６Ｋ】本発明のいくつかの好ましい実施形態による第１の方法の実施に関連する態様を示す図である。
【図６Ｌ】本発明のいくつかの好ましい実施形態による第１の方法の実施に関連する態様を示す図である。
【図６Ｍ】本発明のいくつかの好ましい実施形態による第１の方法の実施に関連する態様を示す図である。
【図６Ｎ】本発明のいくつかの好ましい実施形態による第１の方法の実施に関連する態様を示す図である。
【図６Ｏ】本発明のいくつかの好ましい実施形態による第１の方法の実施に関連する態様を示す図である。
【図６Ｐ】本発明のいくつかの好ましい実施形態による第１の方法の実施に関連する態様を示す図である。
【図６Ｑ】本発明のいくつかの好ましい実施形態による第１の方法の実施に関連する態様を示す図である。
【図６Ｒ】本発明のいくつかの好ましい実施形態による第１の方法の実施に関連する態様を示す図である。
【図７Ａ】近隣のネットワーク接続点の情報要素（ＩＥ）を獲得するなどの構成問い合わせの一例を示す概略図である。
【図７Ｂ（１）】構成問い合わせ結果の例を示す概略図（すなわち、同じ図の部分（１））である。
【図７Ｂ（２）】構成問い合わせ結果の例を示す概略図（すなわち、同じ図の部分（２））である。
【図７Ｃ】近隣の接続点を獲得するなどの選択問い合わせの一例を示す概略図である。
【図７Ｄ】選択問い合わせ結果の例を示す概略図である。
【図７Ｅ】例えば、近隣の接続点に８０２．１１が関与するかどうか尋ねる論理問い合わせの一例を示す概略図である。
【図７Ｆ】論理問い合わせ結果の例を示す概略図である。
【図８Ａ】本発明のいくつかの好ましい実施形態による第２の方法の実施に関連する態様を示す図である。
【図８Ｂ】本発明のいくつかの好ましい実施形態による第２の方法の実施に関連する態様を示す図である。
【図８Ｃ】本発明のいくつかの好ましい実施形態による第２の方法の実施に関連する態様を示す図である。
【図８Ｄ】本発明のいくつかの好ましい実施形態による第２の方法の実施に関連する態様を示す図である。
【図８Ｅ】本発明のいくつかの好ましい実施形態による第２の方法の実施に関連する態様を示す図である。
【図８Ｆ】本発明のいくつかの好ましい実施形態による第２の方法の実施に関連する態様を示す図である。
【図９Ａ（１）】ＳＰＡＲＱＬ最適化を伴う構成問い合わせ結果の例を示す概略図（すなわち、同じ図の部分（１））である。
【図９Ａ（２）】ＳＰＡＲＱＬ最適化を伴う構成問い合わせ結果の例を示す概略図（すなわち、同じ図の部分（２））である。
【図９Ｂ】ＳＰＡＲＱＬ最適化を伴う選択問い合わせ結果の例を示す概略図である。
【図９Ｃ】ＳＰＡＲＱＬ最適化を伴う論理問い合わせ結果の例を示す概略図である。
【図１０】いくつかの説明例による形式の比較を説明する試験結果を示す図である。
【図１１】いくつかの例による、バイナリデータから内部データへの直接変換と３段階変換を含む変換の種類を示す概略図である。
【図１２】いくつかの説明例による統合手法を使った構成問い合わせに関連する試験結果の例を示す説明のための表である。
【図１３】本発明のいくつかの実施形態による、第１の方法によるいくつかの例示的用途でのデータ変換時間の例を示す図である。
【図１】
2008535286.tif 000003
【図２】
2008535286.tif 000004
【図３】
2008535286.tif 000005
【図４Ａ】
2008535286.tif 000006
【図４Ｂ】
2008535286.tif 000007
【図５Ａ】
2008535286.tif 000008
【図５Ｂ】
2008535286.tif 000009
【図６Ａ】
2008535286.tif 000010
【図６Ｂ】
2008535286.tif 000011
【図６Ｃ】
2008535286.tif 000012
【図６Ｄ】
2008535286.tif 000013
【図６Ｅ】
2008535286.tif 000014
【図６Ｆ】
2008535286.tif 000015
【図６Ｇ】
2008535286.tif 000016
【図６Ｈ】
2008535286.tif 000017
【図６Ｉ】
2008535286.tif 000018
【図６Ｊ】
2008535286.tif 000019
【図６Ｋ】
2008535286.tif 000020
【図６Ｌ】
2008535286.tif 000021
【図６Ｍ】
2008535286.tif 000022
【図６Ｎ】
2008535286.tif 000023
【図６Ｏ】
2008535286.tif 000024
【図６Ｐ】
2008535286.tif 000025
【図６Ｑ】
2008535286.tif 000026
【図６Ｒ】
2008535286.tif 000027
【図７Ａ】
2008535286.tif 000028
【図７Ｂ（１）】
2008535286.tif 000029
【図７Ｂ（２）】
2008535286.tif 000030
【図７Ｃ】
2008535286.tif 000031
【図７Ｄ】
2008535286.tif 000032
【図７Ｅ】
2008535286.tif 000033
【図７Ｆ】
2008535286.tif 000034
【図８Ａ】
2008535286.tif 000035
【図８Ｂ】
2008535286.tif 000036
【図８Ｃ】
2008535286.tif 000037
【図８Ｄ】
2008535286.tif 000038
【図８Ｅ】
2008535286.tif 000039
【図８Ｆ】
2008535286.tif 000040
【図９Ａ（１）】
2008535286.tif 000041
【図９Ａ（２）】
2008535286.tif 000042
【図９Ｂ】
2008535286.tif 000043
【図９Ｃ】
2008535286.tif 000044
【図１０】
2008535286.tif 000045
【図１１】
2008535286.tif 000046
【図１２】
2008535286.tif 000047
【図１３】
2008535286.tif 000048
【国際調査報告】
2008535286.tif 000049
2008535286.tif 000050
2008535286.tif 000051