JP5639141B2 - 複数ｍｉｈユーザのためのアーキテクチャ - Google Patents

Description

本願は、８０２．２１エンティティの複数ＭＩＨユーザのためのアーキテクチャに関する。

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

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

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

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

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

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

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

Ｉ．Ｅ．Ｅ．Ｅ．規格であるＩ．Ｅ．Ｅ．Ｅ．８０２．１１は、無線ＬＡＮおよび機器の技術の仕様を定める。

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

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

無線ネットワーク機器は、ブルートゥース機器、複数インタフェース機器（ＭＩＤ）、８０２．１１ｘ機器（８０２．１１ａ、８０２．１１ｂ、８０２．１１ｇ機器などを含む、Ｉ．Ｅ．Ｅ．Ｅ．８０２．１１機器）、ＨｏｍｅＲＦ（家庭内無線周波数）機器、Ｗｉ−Ｆｉ（Ｗｉｒｅｌｅｓｓ Ｆｉｄｅｌｉｔｙ）機器、ＧＰＲＳ（汎用パケット無線システム）機器、３Ｇセルラ機器、２．５Ｇセルラ機器、ＧＳＭ（登録商標）（移動通信用グローバルシステム）機器、ＥＤＧＥ（Ｅｎｈａｎｃｅｄ Ｄａｔａ ｆｏｒ ＧＳＭ Ｅｖｏｌｕｔｉｏｎ）機器、ＴＤＭＡ型（時分割多重接続）機器、またはＣＤＭＡ２０００を含むＣＤＭＡ型（符号分割多重接続）機器を含み得るが、これらには限定されない。各ネットワーク機器は、それだけに限らないが、ＩＰアドレス、ブルートゥース機器アドレス、ブルートゥース共通名、ブルートゥースＩＰアドレス、ブルートゥースＩＰ共通名、８０２．１１ＩＰアドレス、８０２．１１ＩＰ共通名、Ｉ．Ｅ．Ｅ．Ｅ．ＭＡＣアドレスを含む、様々な種類のアドレスを含むことができる。また、無線ネットワークは、例えば、モバイルＩＰ（インターネットプロトコル）システム、ＰＣＳシステム、および他のモバイルネットワークシステムにおいて見られる方法およびプロトコルも関与できる。モバイルＩＰでは、これに、インターネット技術標準化委員会（Ｉ．Ｅ．Ｔ．Ｆ．）によって作成された標準通信プロトコルが関与する。モバイルＩＰでは、モバイル機器ユーザは、これらの一旦割り当てられたＩＰアドレスを維持しつつ、各ネットワークにまたがって移動することができる。コメント要求（ＲＦＣ）３３４４を参照されたい。（注：ＲＦＣはインターネット技術標準化委員会（ＩＥＴＦ）の公式文書である。）
モバイルＩＰは、インターネットプロトコル（ＩＰ）を拡張し、モバイル機器のホームネットワーク外部に接続するときに、モバイル機器にインターネットトラフィックを転送する手段を付加する。モバイルＩＰは、各モバイルノードに、これのホームネットワーク上のホームアドレスと、ネットワークおよびこれのサブネット内の機器の現在位置を識別する気付アドレス（ＣｏＡ）を割り当てる。機器が異なるネットワークに移動すると、機器は、新しい気付アドレスを受け取る。ホームネットワーク上のモビリティエージェントは、各ホームアドレスを、これの気付アドレスと関連付けることができる。モバイルノードは、インターネット制御メッセージプロトコル（ＩＣＭＰ）などを使って、これの気付アドレスを変更する都度ホームエージェントにバインディング更新を送ることができる。

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

異種網間ハンドオーバ（例えばＩ．Ｅ．Ｅ．Ｅ．８０２．２１）：
Ｉ．Ｅ．Ｅ．Ｅ．８０２．２１規格の目的は、異種網間ハンドオーバをサポートすることによりモバイルデバイスのユーザエクスペリエンスを向上することである。この規格では、メディア独立ハンドオーバの要件を満たすための規格が述べられている。この規格は、モバイルユーザおよび固定ユーザの両者について、ハンドオーバのサポートに対処している。モバイルユーザについては、無線リンク状態の変化によりハンドオーバが発生し得る。またハンドオーバは、モバイルノードの移動の結果として生じるサービングリンクまたはターゲットリンクの無線状態の変化によって発生し得る。固定ユーザについては、周囲環境が変化し、あるネットワークが他よりも魅力的になると、ハンドオーバが差し迫った状況になる。別の可能性としては、ユーザが、例えば大きなデータファイルのダウンロードの際に、より高いデータレートチャネルへのハンドオーバを要するアプリケーションを選択する場合があるということである。いかなる場合でも、ハンドオーバの際のサービス連続性は最大化されるべきである。一例として、通話中にネットワーク遷移をする場合、ハンドオーバ手順は、サービスの知覚可能な割込を最小化するために、会話の休止中に実行されるべきである。Ｉ．Ｅ．Ｅ．Ｅ．８０２．２１規格は、ネットワークインフラ内およびモバイル端末で利用可能な情報の共同使用をサポートする。モバイルノードは、利用可能なネットワークを検出するのに好ましい位置にいる。ネットワークインフラは、近隣セルリスト、モバイルデバイスのロケーション、利用可能な上位層サービスといった全体のネットワーク情報を記憶するのに好適である。モバイルノードおよびネットワークは、双方ともに、接続性に関する判定を下すことができる。一般に、モバイルノード、ならびに基地局およびアクセスポイントのようなネットワーク接続ポイントは、双方ともにマルチモーダルであり得る（つまり、複数の無線規格をサポートし、同時に複数の無線インタフェースのコネクションをサポートすることができる。）。全体のネットワークは、Ｉ．Ｅ．Ｅ．Ｅ．８０２．１５のようなピコセル、ＩＥＥＥ８０２．１１のようなマイクロセル、および（３ＧＰＰ、３ＧＰＰ２またはＩ．Ｅ．Ｅ．Ｅ．８０２．１６カバレッジのような）一般に交差するマクロセルを含んでも良い。ハンドオーバ手順は、モバイルノード上のリンクレイヤによって供給される測定およびトリガーによって調節され得る。この測定は、ハンドオーバアルゴリズムにおいて典型的に用いられる信号品質、同期時差および伝送エラーレートのようなメトリクスを伝える。具体的には、この規格は次の要素を含んでいる。

ａ） モバイルノード（ＭＮ）がヘテロジニアスなリンクレイヤ技術間で切り替わる間にシームレスなサービス連続性を可能にするフレームワーク。このフレームワークは、ハンドオーバをサポートするネットワークエレメント内のモビリティ管理プロトコルスタックの識別に依存する。このフレームワークの記述は実装詳細には触れておらず、Ｉ．Ｅ．Ｅ．Ｅ．８０２．２１規格の好ましい実装を示すものではない。このフレームワークは、異なるリンクレイヤ技術のためのメディア独立ハンドオーバ（ＭＩＨ）参照モデルを示す。

ｂ） ネットワークエレメントのプロトコルスタック内における一連のハンドオーバ実現機能、およびそこで生成される、ＭＩＨ機能（ＭＩＨＦ）と呼ばれる新規のエンティティ
ｃ） （ＭＩＨ＿ＳＡＰと呼ばれる）メディア独立サービスアクセスポイントおよび関連するプリミティブは、ＭＩＨユーザに対し、ＭＩＨＦのサービスへのアクセスを提供するように定義される。（注：ＭＩＨユーザはＭＩＨＦによって提供されるサービスを利用するエンティティである。ＭＩＨユーザは、ＭＩＨＦと情報をやりとりするためにＭＩＨ＿ＳＡＰを用いる。）ＭＩＨＦは次のサービスを提供する。

１） メディア独立イベントサービスは、イベントを検出し、ローカルインタフェースならびにリモートインタフェースの両者からのトリガを伝える。

２） メディア独立コマンドサービスは、ＭＩＨユーザが、ハンドオーバ関連リンク状態を制御するための一連のコマンドを提供する。

３） メディア独立情報サービスサービスは、クエリーと応答のための情報モデルを提供し、これにより異種網を横断する効果的なハンドオーバ意思決定を可能にする。

ｄ） 各メディア固有技術の新規のリンクレイヤＳＡＰおよび関連するプリミティブ定義。新たなプリミティブは、ＭＩＨＦがリンク情報を収集し、ハンドオーバ中のリンクビヘイビアを制御するのを支援する。妥当な場合、新規ＳＡＰは、それぞれのメディア固有技術規格への修正として勧告されるかも知れない。

メディア独立ハンドオーバサービス：
例えばＤｒａｆｔ ＩＥＥＥ Ｓｔａｎｄａｒｄ ｆｏｒ Ｌｏｃａｌ ａｎｄ Ｍｅｔｒｏｐｏｌｉｔａｎ Ａｒｅａ Ｎｅｔｗｏｒｋｓと名称付けられた、２００６年９月の Ｉ．Ｅ．Ｅ．Ｅ．Ｐ８０２．２１／Ｄ．０１．０９、即ち、メディア独立ハンドオーバサービス（その全開示は参照によりここに援用される）において、特に、該文献は８０２方式とセルラー方式との間のハンドオーバを最適化する８０２メディアアクセス独立機構の仕様を定めている。Ｉ．Ｅ．Ｅ．Ｅ．８０２．２１規格は異種８０２方式間のハンドオーバの最適化を可能にし、８０２方式とセルラー方式との間のハンドオーバを容易化する拡張メディアアクセス独立機構を定義している。

ＩＥＥＥ ８０２．２１（メディア独立ハンドオーバ）規格の範囲は異種メディア間のハンドオーバを最適化するためリンクレイヤ情報および上位レイヤに関連する他のネットワーク情報を提供する仕様を作り上げることである。これは３ＧＰＰ，３ＧＰＰ２により規定されるリンクおよびＩ．Ｅ．Ｅ．Ｅ．８０２規格ファミリにおける有線および無線メディアの両方を含む。この文献では、特に断りない限り、「メディア」とは、知覚イメージの伝達（例えば、オーディオ、ビデオなど）ではなく、電気通信システム（例えば、ケーブル、無線、衛星など）をアクセスする方法／モードのことを指す。例えば、Ｄｒａｆｔ ＩＥＥＥ Ｓｔａｎｄａｒｄ ｆｏｒ Ｌｏｃａｌ ａｎｄ Ｍｅｔｒｏｐｏｌｉｔａｎ Ａｒｅａ Ｎｅｔｗｏｒｋｓ： Ｍｅｄｉａ Ｉｎｄｅｐｅｎｄｅｎｔ Ｈａｎｄｏｖｅｒ Ｓｅｒｖｉｃｅｓと題された２００６年９月のＩ．Ｅ．Ｅ．Ｅ．Ｐ８０２．２１／Ｄ．０１．０９のセクション１．１を参照されたい。Ｉ．Ｅ．Ｅ．Ｅ．８０２．２１規格は、種々のハンドオーバ方法を容易にするように意図されている。このような方法は一般に、移動ノードとネットワークとの間のデータパケットの交換をサポートするデータトランスポート（データ搬送）ファシリティーに関して、ハンドオーバ手順が「メーク前ブレーク（ｂｒｅａｋ ｂｅｆｏｒｅ ｍａｋｅ）」または「ブレーク前メーク（ｍａｋｅ ｂｅｆｏｒｅ ｂｒｅａｋ）」であるかどうかによって「ハード」または「ソフト」として分類される。

一般にハンドオーバは、ネットワークオペレータとエンドユーザのニーズを満足させるために移動ノードとネットワークインフラストラクチャの両者の協力的使用にかかわる。ハンドオーバ意思決定に関連するハンドオーバ制御、ハンドオーバ方策および他のアルゴリズムは一般に、Ｉ．Ｅ．Ｅ．Ｅ．８０２．２１規格の範囲に入らない通信システム要素によって取り扱われる。しかしながら、全ハンドオーバプロセスにおけるＭＩＨイベントサービス、ＭＩＨコマンドサービス、ＭＩＨ情報サービスおよびＭＩＨＦの役割と目的が明らかになるように全ハンドオーバ手順のいくつかの態様を説明することは有益である。

一般的設計原理：
Ｉ．Ｅ．Ｅ．Ｅ．８０２．２１規格は、下記の一般的設計原理に基づいている。

ａ）ＭＩＨ機能は、ハンドオーバ意思決定を助けて容易にする論理的エンティティである。上位層は、ＭＩＨからの入力と前後関係とに基づいてハンドオーバ意思決定とリンク選択とを行う。ハンドオーバが行われるべきであるという認識を容易にすることは、ＭＩＨＦの主要な目標の１つである。効果的なハンドオーバ意思決定を行う方法に関する情報の発見もまた主要構成要素である。

ｂ）ＭＩＨＦは、より上位の層に抽象サービスを提供する。（注：上位層は、ＭＩＨＦによってサービスの使用が提供させるレイヤを含んでおり、したがって、ＭＩＨユーザと称されることがある。上位層の例は、インターネットプロトコル（ＩＰ）、Ｍｏｂｉｌｅ ＩＰ、ＳＩＰ、伝送制御プロトコル（ＴＣＰ）、ユーザデータグラムプロトコル（ＵＤＰ）およびアプリケーション層である。）この観点からＭＩＨＦは、上位層に統一的インタフェースを提供する。この統一インタフェースによってあらわになるサービスプリミティブは、異なるアクセスネットワークの技術固有プロトコルエンティティに基づいている。ＭＩＨＦは、技術固有インタフェースを介してモビリティ管理プロトコルスタックの下位層と通信する。

下位層とのＭＩＨＦインタフェースの仕様は、一般にこの規格の範囲内に入らない。このようなインタフェースは既に、Ｉ．Ｅ．Ｅ．Ｅ．８０２．１、Ｉ．Ｅ．Ｅ．Ｅ．８０２．３、Ｉ．Ｅ．Ｅ．Ｅ．８０２．１１、Ｉ．Ｅ．Ｅ．Ｅ．８０２．１６、３ＧＰＰおよび３ＧＰＰ２といったそれぞれのアクセス技術に関連する規格内のサービスアクセスポイント（ＳＡＰ）として仕様が定められているかもしれない。この規格は、下位層インタフェースの修正がＭＩＨＦ機能を利用可能にし得る、または改善し得るときに既存のアクセス技術固有規格を修正するための勧告を含み得る。

ｃ）ハンドオーバシグナリング（ハンドオーバ実行および後続の更新の一部としての）は、この規格の一部でない可能性がある。異なるアクセスネットワークは、（移動体起動、ネットワーク起動などの）水平ハンドオーバ機構をサポートする。ハンドオーバ起動トリガは、同種方式のように行われないときに異種ハンドオーバにおいて有用であり得る。

ｄ）ＭＩＨＦは、ＭＡＣ／ＰＨＹトリガおよび他の関連ローカルイベントについて更なる処理を行い得る。この処理の定義は、この規格の範囲外である。この規格は、リモートイベントに関してもサポートを与えるであろう。イベントは実際はアドバイザリである。これらのイベントに基づいてハンドオーバを引き起こすべきか否かの決定は、この規格の範囲外である。

ｅ）この規格は、ＭＮ起動、ＭＮ制御、ネットワーク起動およびネットワーク制御のハンドオーバをサポートするための機構を指定するであろう。

ｆ）本規格は、レガシー装置とのトランスペアレントな相互作用をサポートし得る。したがってＩ．Ｅ．Ｅ．Ｅ．８０２．２１準拠の装置は、レガシー非Ｉ．Ｅ．Ｅ．Ｅ．８０２．２１準拠装置と共存し得るであろう。

メディア独立ハンドオーバ基準フレームワーク：
下記のセクションは、クライアントデバイス（ＭＮ）およびそのネットワークにおける、異なるＭＩＨＦエンティティ間の通信に関する要点を説明する。

ＭＩＨＦ機能は、種々の目的のために互いに通信する。クライアントデバイス（移動ノード）は、そのＭＩＨサービスポイントとの間でＭＩＨ情報を交換する。いかなるネットワークエンティティにおけるＭＩＨＦでもＭＮベースのＭＩＨＦと直接通信するときにはＭＩＨ ＰｏＳになる。ＭＩＨネットワークエンティティは、ＭＮとの直接接続を有しない可能性があり、したがってこの特定のＭＮのためのＭＩＨ ＰｏＳを構成しない。同じＭＩＨネットワークエンティティが異なるＭＮのためのＭＩＨ ＰｏＳとして、なお動作する可能性がある。ＭＩＨＦ通信は、ＭＩＨ可能ＭＮのすべてのＬ２インタフェース上で起こり得るわけではない。一例として、３つのＬ２インタフェースすなわち８０２．１１、８０２．１６および８０２．３を有するＭＩＨ可能ＭＮ上で、８０２．３インタフェースはシステム管理および保守作業のためだけに使用され得るが、８０２．１１および８０２．１６インタフェースはＭＩＨＦサービスの提供に携わり得る。ＭＮは、そのネットワークＰｏＡと同じネットワークエンティティ内に常駐するＭＩＨ ＰｏＳとＭＩＨ情報を交換するためにＬ２トランスポートを使用し得る。ＭＮは、そのネットワークＰｏＡと同じネットワークエンティティ内に常駐しない可能性のあるＭＩＨ ＰｏＳとＭＩＨ情報を交換するためにＬ３トランスポートを使用し得る。このフレームワークは、ＭＩＨネットワークエンティティ間の通信のためにＬ２またはＬ３いずれかの機構の使用をサポートする。

図４は、例示的ＭＩＨ通信モデルを示す。このモデルは、異なる独自の役割を有するＭＩＨＦとそれらの間の通信関係とを示す。図４に示された通信関係は、ＭＩＨＦにだけ適用される。この通信モデルにおける通信関係の各々が特定のトランスポート機構を意味しないことに注目することが重要である。むしろ通信関係は、２つの独自ＭＩＨＦ間でＭＩＨＦ関連情報交換が可能であることを示すように意図されているだけである。更には１）ＭＮ上のＭＩＨＦ、２）ＭＮのサービングＰｏＡを含むネットワークエンティティ上のＭＩＨ ＰｏＳ、３）ＭＮのための候補ＰｏＡ（候補ＰｏＡはＭＮがそれに気づいてはいるが現在それに所属していないＰｏＡであって、この候補ＰｏＡはハンドオーバが最終的に起こった場合にターゲットＰｏＡになる）を含むネットワークエンティティ上のＭＩＨ ＰｏＳ、４）ＭＮのためのＰｏＡを含まないネットワークエンティティ上のＭＩＨ ＰｏＳ、５）ＭＮのためのＰｏＡを含まないネットワークエンティティ上のＭＩＨ 非ＰｏＳである。

この通信モデルはまた、ＭＩＨＦの異なる事例間の下記の通信基準点を識別する。

１）通信基準点Ｒ１：基準点Ｒ１は、ＭＮ上のＭＩＨＦとサービングＰｏＡのネットワークエンティティ上のＭＩＨ ＰｏＳとの間のＭＩＨＦ手順を指す。Ｒ１はＬ２、Ｌ３両者とそれ以上との上の通信インタフェースを包含し得る。Ｒ１上を通ったＭＩＨＦコンテンツはＭＩＩＳ、ＭＩＥＳまたはＭＩＣＳに関連している可能性がある。

２）通信基準点Ｒ２：基準点Ｒ２は、ＭＮ上のＭＩＨＦと候補ＰｏＡのネットワークエンティティ上のＭＩＨ ＰｏＳとの間のＭＩＨＦ手順を指す。Ｒ２はＬ２、Ｌ３両者とそれ以上との上の通信インタフェースを包含し得る。Ｒ２上を通ったＭＩＨＦコンテンツはＭＩＩＳ、ＭＩＥＳまたはＭＩＣＳに関連している可能性がある。

３）通信基準点Ｒ３：基準点Ｒ３は、ＭＮ上のＭＩＨＦと非ＰｏＡネットワークエンティティ上のＭＩＨ ＰｏＳとの間のＭＩＨＦ手順を指す。Ｒ３はＬ３とそれ以上と、またおそらくはイーサネット（登録商標）ブリッジ、ＭＰＬＳなどのようなＬ２トランスポートプロトコルとの上の通信インタフェースを包含し得る。Ｒ３上を通ったＭＩＨＦコンテンツはＭＩＩＳ、ＭＩＥＳまたはＭＩＣＳに関連している可能性がある。

４）通信基準点Ｒ４：基準点Ｒ４は、ネットワークエンティティ内のＭＩＨ ＰｏＳともう１つのネットワークエンティティ内のＭＩＨ 非ＰｏＳ事例との間のＭＩＨＦ手順を指す。Ｒ４はＬ３とそれ以上との上の通信インタフェースを包含し得る。Ｒ４上を通ったＭＩＨＦコンテンツはＭＩＩＳ、ＭＩＥＳまたはＭＩＣＳに関連している可能性がある。

５）通信基準点Ｒ５：基準点Ｒ５は、異なるネットワークエンティティ内の２つのＭＩＨＰｏＳ事例間のＭＩＨＦ手順を指す。Ｒ５はＬ３とそれ以上との上の通信インタフェースを包含し得る。Ｒ５上を通ったＭＩＨＦコンテンツはＭＩＩＳ、ＭＩＥＳまたはＭＩＣＳに関連している可能性がある。

ＭＩＨ通信モデルの説明図：
ＭＩＨ通信基準点のより大きな説明図のために、ＭＩＨサービスを含むネットワークモデルが図５に示されている。右から左へ移って行くと、このモデルは、多数の有線および無線アクセス技術オプションをサポートするＭＩＨ可能移動ノード（ＭＮ、一番右）を含む。このモデルは、プロビジョニングサービスプロバイダが多数のアクセス技術を運用している、あるいは相互作用をサポートするＳＬＡが確立されているときにこのサービスプロバイダのユーザが他のネットワークにローミングすることを可能にすることを想定している。ＭＮは、特定のＭＩＨクエリーを送信することを可能にするＭＩＨＦを実現している。ＭＮはある程度内部的に実現された情報サービスを有し得る。

このモデルは、ある緩やかな連続した仕方でコアネットワーク（オペレータ１−３コア）に接続されたアクセスネットワークを示す。よりタイトに相互接続または連結されたアクセスネットワーク（アクセスネットワーク−３）も示される。オペレータ１−３コアは各々、サービスプロバイダ、企業イントラネットプロバイダあるいはビジテッドアクセス（ｖｉｓｉｔｅｄ ａｃｃｅｓｓ）またはホームアクセスの単なる他の一部、あるいはコアネットワークを表す可能性がある。このモデルでは、サービス提供するプロバイダは、Ｒ１を介して１つのコア（ビジテッド／ホームコア・ネットワークとラベル付けされた）に連結されたアクセスネットワーク−３を運用している。用語ビジテッド（Ｖｉｓｉｔｅｄ）およびホーム（Ｈｏｍｅ）はサービス提供するサービスプロバイダまたは企業を示すために使用される。図示のネットワークのいかなるものも、ＭＮのサービス提供業者とのオペレータの関係に依存してビジテッドまたはホームネットワークの両方になり得る。

ネットワークプロバイダは、自身のネットワークへのハンドオーバを容易にするために自身のアクセスネットワーク（アクセスネットワーク−１〜４）においてＭＩＨサービスを提供する。各アクセス技術は、そのＭＩＨ能力を宣伝するか、あるいはＭＩＨサービス発見に応答する。アクセスネットワークに関する各サービスプロバイダは、１つ以上のＭＩＨサービスポイント（ＰｏＳ、通信モデルと比較すること）へのアクセスを可能にする。これらのＰｏＳは、ＭＩＨ能力発見時に決定されたＭＩＨサービスの一部または全部を提供し得る。ＭＩＨ ＰｏＳの位置またはノードは、規格によって固定されない。ＰｏＳ位置は、オペレータの配置シナリオと技術固有ＭＩＨアーキテクチャとに基づいて変化し得る。

ＭＩＨ ＰｏＳは、アクセスネットワーク（アクセスネットワーク１、２、４が典型的である）内の接続ポイント（ｐｏｉｎｔ ｏｆ ａｔｔａｃｈｍｅｎｔ）（ＰｏＡ）の隣に常駐し得るか、あるいはＰｏＡと同一場所配置（ｃｏ−ｌｏｃａｔｅｄ）され得る。代替としてＰｏＳは、アクセスまたはコアネットワーク（アクセスネットワーク３が典型的である）の内部深くに常駐し得る。ＭＮ内のＭＩＨエンティティは、任意のアクセスネットワーク上のＲ１、Ｒ２またはＲ３のいずれかによってＭＩＨネットワークエンティティと通信する。サービングアクセスネットワーク内のＰｏＡが同一場所配置されたＭＩＨ機能を有する場合、Ｒ１基準接続はＰｏＳでもあるＰｏＡで終了する（このモデルのアクセスネットワーク１、２、４へのＭＮはすべてＲ１であり得る）。この場合、Ｒ３基準接続は、任意の非ＰｏＡ（アクセスネットワーク１、２、４へのＭＮによって示された）で終端されるであろう。ＭＩＨイベントはアクティブなＲ１リンクの両側から発生し得る。ＭＮは典型的にはこれらのイベントに反応する第１のノードである。

ビジテッドネットワークとホームネットワークとの相互作用は、制御および管理目的またはデータトランスポート目的のいずれかのためであり得る。ローミング同意またはＳＬＡ同意によって、ＭＮがビジテッドネットワークを介して公衆のインターネットに直接アクセスすることをホームネットワークが可能にし得ることも可能である。図示のように２つのＭＩＨネットワークエンティティは、Ｒ４またはＲ５基準接続を介して互いに通信し得る。ＭＩＨ可能ＰｏＡはまた、Ｒ３およびＲ４基準点を介して他のＭＩＨネットワークエンティティと通信できる。ＭＩＨ可能ＭＮは、候補ネットワークについての情報サービスを取得するためにＲ２基準点を介しての候補アクセスネットワーク内の他のＰｏＡとのＭＩＨ通信を有し得るであろう。

ＭＩＨ情報サービス（ＭＩＩＳ）に関してプロバイダは、ＭＩＨ ＰｏＳノード（上部左端）に位置する自身の情報サーバへのアクセスを提供する。オペレータは、新しいローミングリスト、コスト、プロバイダ識別情報、プロバイダサービス、優先順位、およびサービスを選択して利用することを可能にする他の任意の情報を含むが、これらに限定されない関連情報を取得できるように、移動ノードにＭＩＩＳを提供する。図示のように移動ノードがプロバイダによってＭＩＩＳデータを事前提供されることは可能である。

また移動ノードが、情報サービスのプロバイダの任意のアクセスネットワークからＭＩＨ情報サービスを取得することも可能である。ＭＩＩＳはまた、このネットワークのＭＩＩＳサービスポイントを使用してもう１つのオーバーラップしているネットワーク、または近隣のネットワークから利用可能であり得る。サービス提供業者のネットワーク（ここではアクセスネットワーク３と連結されているように描かれている）は、サービス提供業者の、あるいはビジテッドネットワークのＭＩＨ情報サーバのような他のＭＩＨエンティティにアクセスするためにＲ３およびＲ４インタフェースを利用し得る。

ＭＩＨコマンドサービス（ＭＩＣＳ）に関して情報データベースのいかなるものも、コマンドサービスＰｏＳとして使用され得る。ＭＮ ＭＩＨＦは典型的には、レイヤー３トランスポートを使用してこのサーバと通信する。

ＭＩＨＦサービス：
ＭＩＨＦは、リンク層およびＭＩＨユーザのために明確なＳＡＰを介して非同期および同期サービスを提供する。任意の型の多数のネットワークインタフェースを有するシステムの場合に上位層は、基礎に在るインタフェースの状態を管理、決定および制御するためにＭＩＨによって提供されるイベントサービス、コマンドサービスおよび情報サービスを使用し得る。

ＭＩＨによって提供されるこれらのサービスは、サービスの連続性の維持、変化するサービス品質へのサービス適応、バッテリ寿命保全、ネットワーク発見およびリンク選択において上位層を支援する。８０２型およびセルラー３ＧＰＰ、３ＧＰＰ２型の異種網インタフェースを含むシステムでは、メディア独立ハンドオーバ機能は、異種網インタフェースに亘ってサービスを連結するために上位層が効率的な手順を実現するのを助け得る。上位層は、異種網間ハンドオーバ動作のために必要とされるリソースの問合せ（クエリー）を行うために異なるエンティティに亘ってＭＩＨＦによって提供されるサービスを利用し得る。

移動デバイスにおけるＭＩＨサービスは、異種網間でのシームレスハンドオーバを容易にする。モビリティ管理プロトコル（例示的Ｍｏｂｉｌｅ ＩＰ）といったＭＩＨユーザは、ハンドオーバおよびシームレスセッション連続性のためにサポートされ得る。これは、ハンドオーバを最適化するためにＭＩＨサービスを利用することから、Ｍｏｂｉｌｅ ＩＰおよび他の上位層に加えて他のプロトコルを除外しないであろう。

ＭＩＨサービスを使用する移動ノードは、イベントサービスのような非同期動作のためにリンク層からの指示を受信するであろう。コマンドサービスおよび情報サービスとの相互作用は、機構の同期クエリーおよび応答型を介して行われるであろう。

ＭＩＨＦはまた、同じメディア型のネットワークエンティティとホストエンティティとの間の情報交換のための機能を提供するであろう。もしこのような情報交換のための機構が所定のメディア型をもって（例えばあるいくつかのセルラーメディア型をもって）既に存在するならば、ＭＩＨＦはいつでも可能なときに既存の機構を利用するであろうことに留意されたい。

ＭＩＨプロトコル：
Ｉ．Ｅ．Ｅ．Ｅ．８０２．２１規格は、メディア独立イベントサービス、メディア独立コマンドサービスおよびメディア独立情報サービスをサポートする。ＭＩＨプロトコルは、リモートＭＩＨＦエンティティとメッセージの送達をサポートするトランスポート機構との間で交換されるメッセージのフォーマット（すなわち、ヘッダとペイロードとを有するＭＩＨＦパケット）を定義する。トランスポート機構の選択は、ＭＮをネットワークとＭＩＨＰｏＳの位置とに接続するアクセス技術に依存する。

これらのサービスのためのパケットペイロードは、Ｌ２管理フレーム、Ｌ２データフレームまたは他の上位層プロトコル上で搬送され得る。８０２．１１および８０２．１６といった無線ネットワークは、管理プレーンを有しており、上記のペイロードを搬送するために適当に改善され得る管理フレームをサポートする。しかしながら、有線イーサネットネットワークは管理プレーンを有さず、またデータフレームだけで上記ペイロードを搬送し得る。

Ｉ．Ｅ．Ｅ．Ｅ．８０２．２１規格は、標準ＴＬＶフォーマットにおいてメディア独立方式でパケットフォーマットおよびペイロードを定義する。この後にこれらのパケットは、ペイロードがイーサネットの場合のように正常なデータフレーム上で送られる必要があるときにＭＩＨＦイーサ型を使用してＬ２ＭＩＨプロトコル内にカプセル化され得る。他の場合には、ＴＬＶベースのメッセージおよびペイロードは、メディア固有管理フレームに直接カプセル化され得る。代替としてＭＩＨプロトコルメッセージは、下位層（Ｌ２）または上位層（Ｌ３以上）トランスポートを使用してカプセル化され得る。

Ｉ．Ｅ．Ｅ．Ｅ．８０２．２１規格は、ＭＩＨプロトコルデータユニット（ＰＤＵ）ヘッダおよびペイロードのフォーマットを定義する。標準ＴＬＶフォーマットは、ＰＤＵペイロードコンテンツのためにメディア独立表現を提供する。ＭＩＨＦ ＰＤＵは、８０２リンク上でＭＩＨＦイーサ型を有するデータフレーム内にカプセル化される。８０２．１１および８０２．１６リンクに関して、ＭＩＨメッセージを搬送するためにメディア固有管理フレームの拡張が推奨される。この規格ではＬ２における３ＧＰＰおよび３ＧＰＰ２アクセスリンク上でのＭＩＨメッセージのトランスポートに関して、何らの仮定も行われていない。

実例アーチテクチャ：
図６は、クライアントデバイスが通信する無線アクセスポイントを含むいくつかの具体的および限定されない実装に採用できるアーチテクチャコンポーネントを示す。これに関して図６は、一般に２１で示された無線ローカルエリアネットワーク（ＷＬＡＮ）に接続された例示的有線ネットワーク２０を示す。ＷＬＡＮ２１はアクセスポイント（ＡＰ）２２および複数のユーザ局２３，２４を含む。例えば、有線ネットワーク２０はインターネット（登録商標）または企業データ処理ネットワークを含んでもよい。例えば、アクセスポイント２２は無線ルータであってもよく、ユーザ局２３，２４は例えば、ポータブル・コンピューター、パーソナルデスクトップコンピュータ、ＰＤＡ、ポータブルのボイス・オーバーＩＰ電話および／または他のデバイスであってもよい。アクセスポイント２２は有線ネットワーク２１にリンクされたネットワークインタフェース２５およびユーザ局２３，２５と通信する無線トランシーバを有する。例えば、無線トランシーバ２６はユーザ局２３，２５との無線またはマイクロ波周波数通信のためのアンテナ２７を含むことができる。アクセスポイント２２はプロセッサ２８、プログラムメモリ２９およびランダムアクセスメモリ３１も有する。ユーザ局２３はアクセスポイント局２２と通信するためのアンテナ３６を含む無線トランシーバ３５を有する。同様に、ユーザ局２４は無線トランシーバ３８とアクセスポイント２２に対して通信するためのアンテナ３９を有する。例としてあるいくつかの実施形態では、このようなアクセスポイント（ＡＰ）内ではオーセンティケータが使用され得る、および／または移動ノードあるいはユーザ局内ではサプリカントまたはピアが使用され得るであろう。

図７は、いくつかの実施形態において、例えばアクセスポイント、オーセンティケータ、ユーザ局、モバイルノードまたは他のノードのようなデバイスによって実行されるコンピュータ化されたプロセスステップを実装するために使用できる、具体的コンピュータまたは制御ユニットを示す。あるいくつかの実施形態ではコンピュータあるいは制御ユニットは、バス３２６上で１セットの入力／出力（Ｉ／Ｏ）デバイス３２４と通信し得る中央演算処理装置（ＣＰＵ）３２２を含む。Ｉ／Ｏデバイス３２４は、例えばキーボード、モニターおよび／または他のデバイスを含み得る。ＣＰＵ３２２は、バス３２６上でコンピュータ可読媒体（例えば従来の揮発性または不揮発性データ記憶デバイス）３２８（以下、「メモリ３２８」）と通信できる。ＣＰＵ３２２、Ｉ／Ｏデバイス３２４、バス３２６およびメモリ３２８間の相互作用は、当技術において周知のものと同様である。メモリ３２８は、例えばデータ３３０を含み得る。メモリ３２８は、ソフトウェア３３８も記憶できる。ソフトウェア３３８はプロセスのステップを実行するための複数のモジュール３４０を含むことができる。一般的プログラミング技術がこれらのモジュールを実施するために使用できる。メモリ３２８は上記および／または他のデータファイルも記憶できる。いくつかの実施形態では、ここに記載されている種々の方法はコンピュータシステムとともに用いられるコンピュータプログラム製品によって実装され得る。この実現形態は、例えばコンピュータ可読媒体（例えばディスケット、ＣＤ−ＲＯＭ、ＲＯＭなど）に記憶された、あるいはモデムなどといったインタフェースデバイスを介してコンピュータシステムに伝送可能な一連のコンピュータ命令を含み得る。通信媒体は実質的に有形（例えば、通信ライン）および／または実質的に無形（例えば、マイクロ波、光、赤外線などを用いた無線媒体）であってもよい。コンピュータ命令は、種々のプログラミング言語で書かれ得る、および／または半導体デバイス（例えばチップまたは回路）、磁気デバイス、光デバイスおよび／または他のメモリデバイスといったメモリデバイスに記憶され得る。種々の実施形態において伝送手段は、適当ないかなる通信技術でも使用できる。

本発明の好ましい実施形態は、既存のシステムおよび／または方法を改善する。

いくつかの実施形態によれば、ある期間中にあるリンクの状態を変更可能であるのは一のＭＩＨユーザのみであるという制約の下、単一のＭＩＨ機能によって複数のＭＩＨユーザをサポートすることを含む方法が提供される。いくつかの実施形態において、この方法は、前記ＭＩＨ機能にリンク所有スキームを導入することによって、複数のＭＩＨユーザの共存を提供することをさらに含む。いくつかの実施形態において、この方法は、前記リンク所有スキームが、あるリンクの状態を変更する送信リクエストプリミティブを送るための独占権を伴うことをさらに含む。いくつかの実施形態において、この方法は、ＭＩＨユーザからのリンク所有要求を受け取る前記ＭＩＨ機能内でリンク所有マネージャエンティティを用いることをさらに含む。いくつかの実施例において、この方法は、ＭＩＨユーザが利用可能なリンクを前記リンク所有マネージャエンティティに割り当てさせることさらに含む。いくつかの実施形態において、この方法は、利用可能なリンクとは、他のＭＩＨユーザが、特定のリンクについて要求プリミティブを送るための独占権を持っていないことを意味することを包含する。いくつかの実施形態において、この方法は、前記リンク所有マネージャエンティティに、リンクのマッピングを維持させ、前記リンクを所有するＭＩＨユーザを維持させることをさらに含む。いくつかの実施例において、この方法は、リモートＭＩＨユーザにローカルリンクを制御させることを含む。いくつかの実施例において、この方法は、前記リモートＭＩＨユーザにハンドオーバ手順を制御させることを含む。いくつかの実施例において、この方法は、ハンドオーバを行なうために、前記リモートユーザに、ローカルノード上のローカルリンクへのコンフリクト要求を送らせることをさらに含む。いくつかの実施例において、この方法は、前記ローカルノード上のローカルＭＩＨユーザに、ＭＩＨ登録要求プリミティブのデスティネーションＭＩＨＦ識別子パラメータとしてネットワークノード上のリモートＭＩＨＦ識別子を指定するとともに前記プリミティブを発行させることをさらに含む。いくつかの実施例において、前記ＭＩＨ登録要求プリミティブは、所有されたリンクセットのパラメータを含む。いくつかの実施例において、この方法は、前記所有されたリンクセットのパラメータは、リモートユーザが所有することのできるローカルリンクを表わすリンクＩＤのリストを含むことを包含する。いくつかの実施例において、この方法は、ローカルＭＩＨユーザに、リモートＭＩＨユーザに代ってリンク所有を要求させることをさらに含む。いくつかの実施例において、この方法は、リンク所有マネージャエンティティを通じて、前記ローカルＭＩＨユーザに、前記リモートＭＩＨユーザに代ってリンク所有を要求させることをさらに含む。

いくつかの実施形態によれば、ＭＩＨ機能にリンク所有スキームを導入することによって、複数のＭＩＨユーザの共存を提供することを含む方法が提供される。いくつかの実施例において、この方法は、ネットワーク上のリモートＭＩＨユーザに一連の割り当てられたリンクを伝えるようプリミティブを変更することにより、前記ネットワークノードによってモバイルノードのリンクの状態を変更することをさらに含む。いくつかの実施例において、この方法は、前記プリミティブに、Ｉ．Ｅ．Ｅ．Ｅ．８０２．２１規格ＭＩＨ＿Ｒｅｇｉｓｔｅｒプリミティブを含ませることを含む。

いくつかの実施形態によれば、登録手続中にローカル・メディア独立ハンドオーバ機能によってサポートされるリンクセットを識別する、リモートノードへのメッセージをローカルノードに送信させることを含む方法が提供される。いくつかの実施例において、この方法は、前記ローカルＭＩＨユーザが前記リモートＭＩＨユーザに、割り当てられたリンクを通知するように、前記メッセージに、所有されたリンクセットを識別するパラメータを含ませることをさらに含む。いくつかの実施例において、この方法は、登録成功によって、前記所有されたリンクセットにおいて存在するリンクへのコンフリクト要求をリモートＭＩＨユーザが送ることが可能になることをさらに含む。いくつかの実施例において、この方法は、前記リモートＭＩＨユーザが用いることのできるリンクセットを更新するための再登録をローカルＭＩＨユーザに行わせることをさらに含む。いくつかの実施例において、この方法は、前記ローカルノードの登録手続中に広告されたリンクセットは、リモートノードを事前構成するために用いられることをさらに含む。

いくつかの実施形態によれば、リンクセットを識別するパラメータを維持するように構成されたＭＩＨ機能を具備するシステムが提供される。いくつかの実施例において、このシステムは、ローカルリンクを表わすリンクＩＤのリストを前記リンクセットが含むことを包含する。いくつかの実施例によれば、このシステムは、前記リンクセットを識別する前記パラメータに基づいて、ローカルＭＩＨユーザがリモートＭＩＨユーザにリンクを通知するように構成される。

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

図１は、いくつかの例示的実施形態に従い、リンク所有による複数ＭＩＨユーザ割り当てを示す図である。 図２は、いくつかの例示的実施形態に従い、リモートリンク所有割り当てを示す図である。 図３は、いくつかの例示的実施形態に従い、登録解除プリミティブによるリモートリンク所有割り当て解除を示す図である。 図４は、８０２．２１規格に基づく例示のＭＩＨＦ通信モデルを表す図である。 図５は、８０２．２１規格に基づく例示の論理ネットワーク参照モデルを表す図である。 図６は、クライアントデバイスが通信する無線アクセスポイントを含むいくつかの具体的および限定されない実装に採用できるアーチテクチャコンポーネントを示す図である。 図７は、いくつかの実施形態において、例えばアクセスポイント、オーセンティケータ、ユーザ局、モバイルノードまたは他のノードのようなデバイスによって実行されるコンピュータ化されたプロセスステップを実装するために使用できる、具体的コンピュータまたは制御ユニットを示す図である。

本発明の好ましい実施形態は、添付の図面において、限定ではない実施例によって示される。

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

序論：
現在、Ｉ．Ｅ．Ｅ．Ｅ．８０２．２１規格は、単一のＭＩＨ機能における複数のＭＩＨ（メディア独立ハンドオーバ）ユーザを可能にしている。参考のために、次の文献全体が参照することにより本明細書に組み込まれる。Ｉ．Ｅ．Ｅ．Ｅ．８０２．２１／Ｄ０６．００，Ｄｒａｆｔ ｆｏｒ Ｌｏｃａｌ ａｎｄ Ｍｅｔｒｏｐｏｌｉｔａｎ ＡｒｅａＮｅｔｗｏｒｋｓ： Ｍｅｄｉａ Ｉｎｄｅｐｅｎｄｅｎｔ Ｈａｎｄｏｖｅｒ Ｓｅｒｖｉｃｅ，２００７年６月（以下、参考文献［１］）。

しかし、この規格は、とりわけ、特定の期間中に特定のリンクの状態を変更させることが許される一のＭＩＨユーザのみが存在するという制約の下で、複数のＭＩＨユーザが単一のＭＩＨＦ（ＭＩＨ機能）によってどのようにサポートされるかについては提言していない。

特に、本願は、ＭＩＨＦ（ＭＩＨ機能）にリンク所有スキームを導入することによって、複数ＭＩＨユーザの共存を考慮に入れるアーキテクチャを提供する。好ましい実施形態において、提案のリンク所有スキームは、ネットワーク上のリモートＭＩＨユーザに一連の割り当てられたリンクを伝えるようにＩ．Ｅ．Ｅ．Ｅ．８０２．２１規格におけるＭＩＨ＿Ｒｅｇｉｓｔｅｒプリミティブを変更することによって、モバイルノードのリンクの状態がネットワークノードによって変更されるというシナリオをサポートする。

課題の概要：
現在、Ｉ．Ｅ．Ｅ．Ｅ．８０２．２１規格（参照文献［１］を参照）は、参照文献［１］の図１１に示すように、単一のＭＩＨ機能における複数のＭＩＨ（メディア独立ハンドオーバ）ユーザを可能にしている。

しかし、この規格は、とりわけ、ある条件の下で特定のリンクの状態を変更させることが許される一のＭＩＨユーザのみが存在するという制約の下で、複数のＭＩＨユーザが単一のＭＩＨＦ（ＭＩＨ機能）によってどのようにサポートされるかについては言及も示唆もしていない。上記の条件は、互いとは別個に作用する複数のＭＩＨユーザが、リンクを同時に制御し、かつ／またはアクセスすることを試みるとき、すなわち競合状態のときに存在する。この問題は、さらに次の例を用いて説明することができる。

・８０２．２１可能デバイスのＭＩＨＦ上に二人のＭＩＨユーザＡおよびＢが存在する。

・８０２．２１可能デバイスはＷＬＡＮ（無線ＬＡＮ）リンク（あるいはインタフェース）を持つ。ＷＬＡＮリンクの状態は現在「完全動作」である。

・ＭＩＨユーザＡが、ＷＬＡＮリンクの状態を「ターンオフ」に変更するローカルコマンドＡを発行する。

・同時に、ＭＩＨユーザＢは、ＷＬＡＮの状態を「省電力」に変更するローカルコマンドＢを発行する。

ローカルコマンドＡがローカルコマンドＢの前に実行されれば、ＷＬＡＮリンクの最終状態は、ユーザＡの期待（すなわち「ターンオフ」）とは異なる「省電力」になる。一方、ローカルコマンドＡがローカルコマンドＢの後に実行されれば、ＷＬＡＮリンクの最終状態は、ユーザＢの期待（すなわち「省電力」）とは異なる「ターンオフ」になる。

８０２．２１の規格は、リモートＭＩＨユーザがローカルＭＩＨ機能にアクセスすることも可能である。同様に、この問題の一例は下のように説明される。

・８０２．２１可能デバイスのＭＩＨＦ上にＭＩＨユーザＡがいる。ネットワークノードのＭＩＨＦ上にＭＩＨユーザＢがいる。

・８０２．２１可能デバイスはＷＬＡＮ（無線ＬＡＮ）リンク（あるいはインタフェース）を持つ。ＷＬＡＮリンクの状態は現在「完全動作」である。

・ＭＩＨユーザＡが、ＷＬＡＮリンクの状態を「ターンオフ」に変更するローカルコマンドＡを発行する。

・同時に、ＭＩＨユーザＢは、ＷＬＡＮの状態を「省電力」に変更するリモートコマンドＢを発行する。

ローカルコマンドＡがリモートコマンドＢの前に実行されれば、ＷＬＡＮリンクの最終状態は、ユーザＡの期待（すなわち「ターンオフ」）とは異なる「省電力」になる。一方、ローカルコマンドＡがリモートコマンドＢの後に実行されれば、ＷＬＡＮリンクの最終状態は、ユーザＢの期待（すなわち「省電力」）とは異なる「ターンオフ」になる。

上記の２つの例において、ローカルコマンドＡおよびローカル／リモートコマンドＢは、特定の期間において実行されたときに、それらがリンク状態の不整合性を引き起こす点で互いに矛盾している。上記の状態不整合性を回避するために、特定期間において、あるリンクについて一のＭＩＨユーザだけが上記コマンドを発行することを排他的に可能にするための機構が必要である。しかし、上記の機構は、現行の８０２．２１規格では説明されていない。

競合状態の可能性に加え、目下、Ｉ．Ｅ．Ｅ．Ｅ．８０２．２１［１］規格は、登録手続中に、ローカルＭＩＨＦによりサポートされ、存在するリンクセットをローカルノードがリモートノードに伝えるための効率的な方法を定義していない。リモートノードは、ＭＩＨ＿Ｇｅｔ＿Ｌｉｎｋ＿Ｐａｒａｍｅｔｅｒｓ要求を通じて上記の情報を得ることにより追加のシグナリングを完了する必要がある。しかしながら、複数のＭＩＨユーザを考慮に入れる次のセクションでの提案は、この問題を解決する。

また、リモートノードが、ローカルノード上に存在するリンクセットによってあらかじめ構成される場合がある。静的な構成シナリオは一般的ではないが、本明細書において示されるスキームは、上記の構成が呈する良く知られた問題を軽減する。ローカルノード登録手続中に広告されたリンクセットは、静的事前構成リンクセットをオーバーライドし、変更し、または更新するのに使用することができ、ならびに、それらのリンクのアベイラビリティをアナウンスするのに使用することができる。

好ましい実施形態：
本願は、前述の、および／または他の既存の問題を解決することができ、Ｉ．Ｅ．Ｅ．Ｅ．８０２．２１規格（参考文献［１］参照）には存在しない新規の概念を提供する。これらの概念は、例えば以下を含んでいる。

１．新しいリンク所有スキーム
２．例えばＭＩＨ＿Ｒｅｇｉｓｔｅｒ．ｒｅｑｕｅｓｔプリミティブによる、新しいリモートリンク所有の割り当て。これらの概念を実施するための好ましい実施形態が下記に述べられる。

１．リンク所有スキーム
リソース所有の一般的な概念は、種々のシステムにおいて見出される。ほとんどのシナリオでは、所有権（ｏｗｎｅｒｓｈｉｐ）は、リソースの状態またはコンテンツを排他的に変更する特権−例えば、リソースの書き込み特権を対象とする。Ｉ．Ｅ．Ｅ．Ｅ．８０２．２１および複数ＭＩＨユーザの場合、リソースとはリンクであり、リンク所有とは、例えばＭＩＨ＿Ｃｏｎｆｉｇｕｒｅ＿Ｌｉｎｋのような特定のリンクの状態を変更することができる要求プリミティブを送る独占権である。これらの要求プリミティブは、本明細書において「コンフリクト要求」と称する。他のＭＩＨユーザは、非コンフリクト要求を送ることができてもよく、それらが所有しないリンクに関するイベントをサブスクライブすることができてもよい。一方、リンクを所有するＭＩＨユーザだけが、所有するリンクに対するコンフリクト要求を送ることができる。現在、ＭＩＨ＿ＳＡＰのために定義されたコンフリクト要求プリミティブ（すなわちＭＩＨユーザとＭＩＨＦの間の、定義されたＩ．Ｅ．Ｅ．Ｅ．８０２．２１サービスアクセスポイント）は以下を含んでいる。

１．ＭＩＨ＿Ｃｏｎｆｉｇｕｒｅ＿Ｌｉｎｋ．ｒｅｑｕｅｓｔ
２．ＭＩＨ＿ＭＮ＿ＨＯ＿Ｃｏｍｍｉｔ．ｒｅｑｕｅｓｔ、および
３ ＭＩＨ＿Ｎｅｔ＿ＨＯ＿Ｃｏｍｍｉｔ．ｒｅｑｕｅｓｔ
また、現在の非コンフリクト要求プリミティブは以下を含んでいる。

１．ＭＩＨ＿Ｃａｐａｂｉｌｉｔｙ＿Ｄｉｓｃｏｖｅｒｙ．ｒｅｑｕｅｓｔ
２．ＭＩＨ＿Ｒｅｇｉｓｔｅｒ．ｒｅｑｕｅｓｔ
３．ＭＩＨ＿ＤｅＲｅｇｉｓｔｅｒ．ｒｅｑｕｅｓｔ
４．ＭＩＨ＿Ｅｖｅｎｔ＿Ｓｕｂｓｃｒｉｂｅ．ｒｅｑｕｅｓｔ
５．ＭＩＨ＿Ｅｖｅｎｔ＿ＵｎＳｕｂｓｃｒｉｂｅ．ｒｅｑｕｅｓｔ
６．ＭＩＨ＿Ｇｅｔ＿Ｌｉｎｋ＿Ｐａｒａｍｅｔｅｒｓ．ｒｅｑｕｅｓｔ
７．ＭＩＨ＿Ｓｃａｎ．ｒｅｑｕｅｓｔ
８．ＭＩＨ＿ＭＮ＿ＨＯ＿Ｃａｎｄｉｄａｔｅ＿Ｑｕｅｒｙ．ｒｅｑｕｅｓｔ
９．ＭＩＨ＿Ｎｅｔ＿ＨＯ＿Ｃａｎｄｉｄａｔｅ＿Ｑｕｅｒｙ．ｒｅｑｕｅｓｔ
１０．ＭＩＨ＿Ｎ２Ｎ＿ＨＯ＿Ｑｕｅｒｙ＿Ｒｅｓｏｕｒｃｅｓ．ｒｅｑｕｅｓｔ
１１．ＭＩＨ＿ＭＮ＿ＨＯ＿Ｃｏｍｐｌｅｔｅ．ｒｅｑｕｅｓｔ
１２．ＭＩＨ＿Ｎ２Ｎ＿ＨＯ＿Ｃｏｍｐｌｅｔｅ．ｒｅｑｕｅｓｔ
１３．ＭＩＨ＿Ｃｏｎｆｉｇｕｒｅ＿Ｌｉｎｋ．ｒｅｑｕｅｓｔ、および
１４．ＭＩＨ＿Ｇｅｔ＿Ｉｎｆｏｒｍａｔｉｏｎ．ｒｅｑｕｅｓｔ
リンク所有の管理を提供するために、本明細書は、ＭＩＨＦの内のリンク所有マネージャ（ＬＯＭ）エンティティを導入する。ＬＯＭは、ＭＩＨユーザからのリンク所有要求の受け取りを担う。ＬＯＭは、ＭＩＨユーザに「利用可能な」リンクを割り当てる。本件の場合、利用可能とは、他のＭＩＨユーザが、特定のリンクに関してコンフリクト要求を送るための独占権を主張しない、ことを意味する。またＬＯＭは、リンクと、これを所有するＭＩＨユーザのマッピングに関与する。

要約するために、いくつかの好ましい実施形態に従って、ローカルＭＩＨユーザのための基本的なリンク所有スキームが図１に示される。同図は、リンク所有を通じた複数のＭＩＨユーザ割り当てを示している。

図１において、各ＭＩＨユーザは、ＭＩＨ＿ＳＡＰを通じて特定のリンクの所有割り当てを要求する。例えば、ＭＩＨユーザＡは、ローカルＭＩＨＦへのＡＰＩ関数呼び出しによりＷＬＡＮ ＬＩＮＫの所有権を要求する。同ＭＩＨユーザは、もはやコンフリクト要求を送る必要はないと判定する場合、所有するリンクの所有権の解放を別のＡＰＩ関数呼び出しを用いることにより要求することができる。このＡＰＩは、ＭＩＨＦに対してローカルであることから、実装特有（各ＭＩＨユーザがＭＩＨＦによって識別される態様を含む）であって、この開示に基づいた当業者であれば、目前の状況に従って構成することができる。本明細書で説明されるいくつかの実施形態において、ＬＯＭが従う割り当てポリシーは、先着順（Ｆ．Ｉ．Ｆ．Ｏ．）であるが、代替の、または付加的なポリシーを実装に依存して実行してもよい。

２．ＭＩＨ＿Ｒｅｇｉｓｔｅｒ要求プリミティブによるリモートリンク所有
前のセクションは、ローカルＭＩＨユーザがリンク所有をローカルで要求することができる方法を説明している。しかし、Ｉ．Ｅ．Ｅ．Ｅ．８０２．２１（上記参考文献［１］参照）は、リモートＭＩＨユーザがローカルリンクを監視し、かつ／または制御することができる方法について述べている。これは、例えば、リモートＭＩＨユーザがハンドオーバ手順に対する制御を持つ場合に有用である。したがって、このシナリオでは、リモートユーザが、ローカルの８０２．２１可能デバイスのローカルリンクにコンフリクト要求を送ってハンドオーバを終えることができる。好ましくは、８０２．２１可能デバイスのローカルＭＩＨユーザは、プリミティブのデスティネーションＭＩＨＦ識別子パラメータとしてのネットワーク上のリモートＭＩＨＦの識別子を指定するとともにＭＩＨ＿Ｒｅｇｉｓｔｅｒ．ｒｅｑｕｅｓｔプリミティブを発行することによりこれを認可する。ＭＩＨ＿Ｒｅｇｉｓｔｅｒ．ｒｅｑｕｅｓｔプリミティブを受け取る際、ローカルＭＩＨＦは、リモートＭＩＨＦにＭＩＨ＿Ｒｅｇｉｓｔｅｒ ＭＩＨプロトコルメッセージを送る。リモートＭＩＨＦはこのメッセージを受け取り、適切なリモートＭＩＨユーザ（例えば、ネットワーク制御のハンドオーバを実行するリモートＭＩＨユーザ）に対してＭＩＨ＿Ｒｅｇｉｓｔｅｒ．ｉｎｄｉｃａｔｉｏｎプリミティブを生成する。

ローカルＭＩＨユーザは、このリモートＭＩＨユーザに代ってリンク所有を要求するであろう。セクション３に示された同じスキームを用いて、ローカルＭＩＨユーザは、同じローカルＡＰＩセットを用いるＬＯＭにより１つまたは複数のリンクのリンク所有を要求する。その後、ローカルＭＩＨユーザは、該ユーザが得たリンクセットをリモートＭＩＨユーザに伝えるために、ＭＩＨ＿Ｒｅｇｉｓｔｅｒ．ｒｅｑｕｅｓｔプリミティブを用いる。このことは、割り当てられたリンクセットを含めるための、ＭＩＨ＿Ｒｅｇｉｓｔｅｒ要求プリミティブへの変更を導入する。この変更は、好ましくは以下のとおりである。

ＭＩＨ＿Ｒｅｇｉｓｔｅｒ．ｒｅｑｕｅｓｔ（ＤｅｓｔｉｎａｔｉｏｎＩｄ，ＳｅｔＯｆＯｗｎｅｄＬｉｎｋｓ，ＲｅｑｕｅｓｔＣｏｄｅ）
ただし、
ＤｅｓｔｉｎａｔｉｏｎＩｄ−（例えばＩ．Ｅ．Ｅ．Ｅ．８０２．２１（上記参考文献［１］参照）のセクション７．４．２において定義されるようなＭＩＨＦ ＩＤ）
ＳｅｔＯｆＯｗｎｅｄＬｉｎｋｓ（注：これは新しく追加のパラメータである。）−リモートユーザが所有することのできるローカルリンクを表わすＬＩＮＫ ＩＤのリスト ＲｅｑｕｅｓｔＣｏｄｅ−（例えばＩ．Ｅ．Ｅ．Ｅ．８０２．２１（上記参考文献［１］参照）のセクション７．４．２において定義されるような要求コード）
パラメータＳｅｔＯｆＯｗｎｅｄＬｉｎｋｓを加えることにより、ローカルＭＩＨユーザは、リモートＭＩＨユーザの代わりに割り当てたリンクを該リモートＭＩＨユーザに通知することが可能となる。登録の成功により、リモートＭＩＨユーザがＳｅｔＯｆＯｗｎｅｄＬｉｎｋｓにおけるリンクに対するコンフリクト要求を送ることができるようになる。現在のＩ．Ｅ．Ｅ．Ｅ．８０２．２１（上記参考文献［１］参照）規格は、ＲｅｑｕｅｓｔＣｏｄｅパラメータ−−例えば、１に等しいＲｅｑｕｅｓｔＣｏｄｅを通じた再登録をサポートする。これは一般的ではないが、リモートＭＩＨユーザが用いることができるリンクセットを更新するために、ローカルＭＩＨユーザは再登録機能を利用することができる。この場合、再登録は、リモートＭＩＨユーザの新規のリンクセットを含むことができる。

登録手続の成功には、リモートＭＩＨユーザがＭＩＨ＿Ｇｅｔ＿Ｌｉｎｋ＿Ｐａｒａｍｅｔｅｒｓを送り、そこからイベントをサブスクライブすることのできるリンクセットを得る必要がなくなるという付加的な利益がある。このことは、ローカルＭＩＨユーザとリモートＭＩＨユーザとの間のより効率的なシグナリングを推進する。参考のために、図２は、いくつかの実施形態に従って提案されたリモートリンク所有スキームの要約を示す。

これに関連し、図２は、いくつかの実施例に従ってリモートＭＩＨユーザがローカルリンクセットの所有権をどのように割り当てられるかについての基本的で段階的な手順を示す。これに関連し、図２は、ローカルＭＩＨＦにおけるローカルＭＩＨユーザおよびリモートＭＩＨＦにおけるリモートＭＩＨユーザを示す。上述し、図１の１に示すように、ローカルＭＩＨユーザはＭＩＨ＿Ｒｅｇｉｓｔｅｒ．ｒｅｑｕｅｓｔプリミティブ（ＤｅｓｔｉｎａｔｉｏｎＩＤ，ＳｅｔｏｆＯｗｎｅｄＬｉｎｋｓ，ＲｅｑｕｅｓｔＣｏｄｅ）をローカルＭＩＨＦに送る。次いで、ローカルＭＩＨＦは、ＭＩＨ＿Ｒｅｇｉｓｔｅｒ ＭＩＨプロトコルメッセージをリモートＭＩＨＦに送信する（図２における矢印Ａを参照）。次に、図２の２に示すように、リモートＭＩＨＦは適切なリモートＭＩＨユーザに対するＭＩＨ＿Ｒｅｇｉｓｔｅｒ．ｉｎｄｉｃａｔｉｏｎプリミティブ（ＤｅｓｔｉｎａｔｉｏｎＩＤ，ＳｅｔｏｆＯｗｎｅｄＬｉｎｋｓ，ＲｅｑｕｅｓｔＣｏｄｅ）を生成する。３に示されるように、リモートＭＩＨユーザは、リモートＭＩＨＦに対してＭＩＨ＿Ｒｅｇｉｓｔｅｒ．ｒｅｓｐｏｎｓｅプリミティブ（ｓｒｃ、インターバル、ステータス）を生成する。次いで、図２の４に示すように、ローカルＭＩＨＦは、ローカルＭＩＨユーザに対してＭＩＨ＿Ｒｅｇｉｓｔｅｒ．ｃｏｎｆｉｒｍプリミティブ（ｓｒｃＩＤ，ｉｎｔｅｒｖａｌ，ｓｔａｔｕｓ）を生成する。所有権を解放するには、このローカルＭＩＨユーザは、ＭＩＨ＿ＤｅＲｅｇｉｓｔｅｒ要求プリミティブを送る。これは、リモートＭＩＨユーザに対して、受信した最新のＳｅｔＯｆＯｗｎｅｄＬｉｎｋｓにおけるリンクを、もはや所有することができないことを伝える。しかしながらこの場合、ＭＩＨ＿ＤｅＲｅｇｉｓｔｅｒ要求プリミティブにおける変更は必要でない。

参考のために、図３は、いくつかの例示の実施形態に従って、登録解除プリミティブによるリモートリンク所有割り当て解除を示す。要約すると、１に示すように、ローカルＭＩＨユーザは、ＭＩＨ＿ＤｅＲｅｇｉｓｔｅｒ．ｒｅｑｕｅｓｔプリミティブの発行によりこれを開始する。その後、図３に示すように、ステップ２、３および４を実行する。

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

Claims (7)

1. ハンドオーバ手順におけるリンクの割り当て登録手続中に、ローカルノード上のローカルＭＩＨユーザが、ローカル・メディア独立ハンドオーバ機能によってサポートされる、所有されたリンクセットを識別するメッセージをリモートノード上のリモートＭＩＨユーザに送信すること、を具備し、
   前記メッセージは、ローカルＭＩＨユーザが、割り当てられたリンクをリモートＭＩＨユーザに通知するように、前記所有されたリンクセットを識別するパラメータを含む方法。
2. 前記登録の成功によって、前記リモートＭＩＨユーザが、前記所有されたリンクセットに存在するリンクに対するコンフリクト要求を送ることが可能になることをさらに含む請求項１の方法。
3. ローカルＭＩＨユーザに、前記リモートＭＩＨユーザが用いることのできるリンクセットを更新するための再登録を行わせることをさらに含む請求項１の方法。
4. 前記ローカルノードの前記登録手続中に広告されたリンクセットは、リモートノードを事前構成するために用いられることをさらに含む請求項１の方法。
5. ハンドオーバ手順におけるリンクの割り当て登録手続中に、メディア独立ハンドオーバ（ＭＩＨ）機能によってサポートされる、所有されたリンクセットを識別するパラメータを維持し、リモートＭＩＨユーザに割り当て可能なリンクを通知するように前記リンクセットを識別する前記パラメータを備えるメッセージを前記リモートＭＩＨユーザに送信し、前記リンクセットにおけるリンクの割り当てに関するコンフリクト要求を前記リモートＭＩＨユーザから受信するように構成された、ローカルのＭＩＨ機能を具備するシステム。
6. 前記リンクセットは、ローカルリンクを表わすリンクＩＤのリストを含む請求項５のシステム。
7. ローカルＭＩＨユーザは、前記リンクセットを識別する前記パラメータに基づいて、リンクを前記リモートＭＩＨユーザに通知するように構成される請求項６のシステム。

Images