JP2008519507A - 単純化したビーコンを特徴とするメディア非依存ハンドオーバ（ｍｉｈ）の方法 - Google Patents

Abstract

１つ以上の異種ネットワーク及び非異種ネットワーク（１０，９０）の間にメディア非依存ハンドオーバ（ＭＩＨ）サービスを実装する方法に関する。この方法は、１つ以上のネットワーク（Ｎｅｔ）（１８２）又はモバイルノード（ＭＮ）（１８６，１８８，１９０）からＭＩＨビーコン（１９２）を提供する工程と、別のネットワーク（Ｎｅｔ）又はモバイルノードによるＭＩＨビーコンの受信を認識する工程と、認識した受信に応答して、また、１つ以上のネットワーク（Ｎｅｔ）又はモバイルノードから続いて提供されるＭＩＨビーコンメッセージに応答して、ハンドオーバ（ＨＯ）サービスを実施する工程と、からなる。一実施形態では、ＭＩＨビーコンは第１状態及び第２状態のうちの一方を有する１つ以上のＭＩＨ性能（ＭＩＨＣ）フラグを含む。

Description

本開示はハンドオーバ機構に関する。より詳細には、本開示はメディア非依存ハンドオーバ（ＭＩＨ）サービス用の単純化したビーコンに関する。

ＩＥＥＥ ８０２は、ローカルエリアネットワーク及び都市域ネットワーク用の一群のＩＥＥＥ標準規格を指す。ＩＥＥＥ ８０２において指定されるサービス及びプロトコルは、７層開放型システム間相互接続（ＯＳＩ）ネットワーク参照モデルにおける下位の２つの層へマッピングされている。この下位の２つの層は、データリンク層及び物理（ＰＨＹ）層に相当する。さらにデータリンク層は、論理リンク制御（ＬＬＣ）及びメディアアクセス制御（ＭＡＣ）に相当する２つの副層へ分割されている。

新たな標準規格として、ＩＥＥＥ ８０２．２１では、同じタイプのネットワーク間のシームレスなハンドオーバに加え、異なるタイプのネットワーク間のハンドオーバが提供される。したがって、ＩＥＥＥ ８０２．２１では、マルチメディア非依存ハンドオーバ又はメディア非依存ハンドオーバ（ＭＩＨ）標準規格が参照される。この標準規格によって、セルラー（ＧＳＭ、ＧＰＲＳ、ＥＤＧＥ、Ｗ−ＣＤＭＡ、ＣＤＭＡ、ＣＤＭＡ２０００）、ＩＥＥＥ ８０２．１１（Ｗｉ−Ｆｉ）、Ｂｌｕｅｔｏｏｔｈ（登録商標）及びＩＥＥＥ ８０２．１６（ＷｉＭＡＸ）のネットワーク間のハンドオーバが可能となる。この新たなＩＥＥＥ ８０２．２１標準規格は、以下を考慮して必要となった。セルラーネットワーク及び８０２．１１のネットワークには同じネットワーク内のハンドオーバ用のハンドオーバ機構が採用されており、モバイルＩＰには同じタイプである異なるネットワークを通じるハンドオーバ用のハンドオーバ機構が採用されている。しかしながら、現行のＩＥＥＥ ８０２標準規格では、異なるタイプのネットワーク間のハンドオーバはサポートされていない。また、既存のＩＥＥＥ ８０２標準規格では、ネットワークアクセスポイントを検出及び選択するための機構が提供されるが、ネットワークタイプに依存しない手法によってネットワークアクセスポイントを検出及び選択することは不可能である。

上述に加え、無線通信システムの技術分野には様々な問題が存在する。この問題には、次のうちの１つ以上が含まれ得る。１）マルチプロトコル可能ノード間の高速、高信頼性、かつ、一般に認知されているハンドオーバ（ＨＯ）機構が存在しないこと、２）異種ネットワーク間のＨＯサービスは複雑、かつ、低速であること、３）ＨＯサービスに関連して要求されるネットワークオーバヘッドが過剰であること、４）移動加入者に新たな付加サービスを提供しているときに、無線ネットワークの効率及びキャパシティが欠如していること。

したがって、当該技術分野における上述の問題を克服するため、改良された方法及び装置の必要が存在する。

本開示の実施形態では、本明細書に開示されるようなＭＩＨビーコンを提供することによって、異なる無線ネットワークプロトコル及び有線ネットワークプロトコルの間に標準化されたフォーマットを生じ、ＭＩＨサービスを可能とするための高速、高信頼性、かつ、最適な方法の確立を支援する。また、本開示はシームレスなモビリティ技術に対しても適用され得る。

詳細には、本開示の実施形態では、メディア非依存ハンドオーバ（ＭＩＨ）サービス用の単純化したビーコンを提供する。さらに、この実施形態では、マルチプロトコル可能ノード間の高速、高信頼性、かつ、一般に認知されるハンドオーバ（ＨＯ）機構を提供し、異種ネットワーク間のＨＯサービスの単純化及び高速化、ＨＯサービスに関連して要求されるネットワークオーバヘッドの減少、並びに、移動加入者に新たな付加サービスを提供しているときの無線ネットワークの効率及びキャパシティの増大を提供する。

図１は、異種ネットワーク１０に関する概略ブロック図である。異種ネットワーク１０は、モバイルノード（ＭＮ）１２によって横断される。モバイルノード（ＭＮ）１２では、無線カバレッジの断絶を生じるモバイルノード（ＭＮ）１２の移動に基づき、デバイスハンドオーバ（ＨＯ）が発生し得る。デバイスハンドオーバ（ＨＯ）の発生は、図１の参照符号１，２，３，４によって示される。デバイスハンドオーバ（ＨＯ）は、無線リンク状態の変化のために発生する場合もある。図１の例では、異種ネットワーク１０はＧＳＭセルラーネットワーク１４、ＩＥＥＥ ８０２．１６モバイル及び固定ネットワーク１６、無線ローカルエリアネットワーク（ＷＬＡＮ）１８、並びにＣＤＭＡセルラーネットワーク２０を含む。ネットワーク１４，１６，１８，２０は各々イーサネット（登録商標）２２へ接続している。参照符号１によって示す点では、ＧＳＭセルラーネットワーク１４とＩＥＥＥ ８０２．１６モバイル及び固定ネットワーク１６との間でモバイルノード（ＭＮ）１２のデバイスハンドオーバ（ＨＯ）が発生する。参照符号２によって示す点では、ＩＥＥＥ ８０２．１６モバイル及び固定ネットワーク１６と無線ローカルエリアネットワーク（ＷＬＡＮ）１８との間でモバイルノード（ＭＮ）１２のデバイスハンドオーバ（ＨＯ）が発生する。点３では、無線ローカルエリアネットワーク（ＷＬＡＮ）１８とＩＥＥＥ ８０２．１６モバイル及び固定ネットワーク１６との間でモバイルノード（ＭＮ）１２のデバイスハンドオーバ（ＨＯ）が発生する。点４では、ＩＥＥＥ ８０２．１６モバイル及び固定ネットワーク１６とＣＤＭＡセルラーネットワーク２０との間でモバイルノード（ＭＮ）１２のデバイスハンドオーバ（ＨＯ）が発生する。

図２は、本開示の一実施形態による局機能エンティティ３２とネットワーク機能エンティティ３４との間でＭＩＨ機能イベントを交換するために用いられる任意の適切なネットワークプロトコルに関する概略ブロック図３０である。局機能エンティティ３２とネットワーク機能エンティティ３４との間の接続には、参照符号３６によって示すような物理層シグナリングと、参照符号３８によって示すようなＭＩＨシグナリングとが含まれる。局機能エンティティ３２は、少なくとも物理層機能（ＰＨＹ機能（８０２．ｘｘ））ブロック４０と、データリンク層機能ブロック４２，４４とを備える。詳細には、データリンク層機能ブロックは、メディアアクセス制御（ＭＡＣ）機能（ＭＡＣ機能（８０２．ｘｘ））ブロック４２と、論理リンク制御（ＬＬＣ）機能（ＬＬＣ機能）ブロック４４とを含む。ＰＨＹ，ＭＡＣ，ＬＬＣ機能ブロックのうちのそれぞれのブロックとの間の通信は、参照符号４１，４３によって示される。また、参照符号４５によって示されるように、ＬＬＣ機能ブロック４４は７レベルＯＳＩモデルにおいてデータに相当する次のレベルと通信を行い、そのレベルからデータを受信する。

さらに、局機能エンティティ３２はメディア非依存ハンドオーバ機能（ＭＩＨ機能）ブロック４６を備える。ＰＨＹ，ＭＡＣ，ＭＩＨ機能ブロックのうちのそれぞれのブロックとの間の通信は、参照符号４８，５０によって示される。また、参照符号５２，５４，５６によって示されるように、ＭＩＨ機能ブロック４６は７レベルＯＳＩモデルにおいてそれぞれ管理、第３層及びアプリケーションのレベルの情報に相当する他の層と通信を行い、その層からデータを受信する。

ネットワーク機能エンティティ３４は、少なくとも物理層機能（ＰＨＹ機能（８０２．ｘｘ））ブロック６０と、データリンク層機能ブロック６２，６４とを備える。詳細には、データリンク層機能ブロックは、メディアアクセス制御（ＭＡＣ）機能（ＭＡＣ機能（８０２．ｘｘ））ブロック６２と、論理リンク制御（ＬＬＣ）機能（ＬＬＣ機能）ブロック６４とを含む。ＰＨＹ，ＭＡＣ，ＬＬＣ機能ブロックのうちのそれぞれのブロックとの間の通信は、参照符号６１，６３によって示される。また、ＬＬＣ機能ブロック４４は７レベルＯＳＩモデルにおいてデータに相当する次のレベル（図示せず）と通信を行い、そのレベルからデータを受信する。

さらに、ネットワーク機能エンティティ３４はメディア非依存ハンドオーバ機能（ＭＩＨ機能）ブロック６６を備える。ＰＨＹ，ＭＡＣ，ＭＩＨ機能ブロックのうちのそれぞれのブロックとの間の通信は、参照符号６８，７０によって示される。また、参照符号７２，７４，７６によって示されるように、ＭＩＨ機能ブロック６６は７レベルＯＳＩモデルにおいてそれぞれ管理、第３層及びアプリケーションのレベルの情報に相当する他の層と通信を行い、その層からデータを受信する。

図３は、本開示の一実施形態による（ｉ）ＭＩＨ可能なモバイルユニット及び（ｉｉ）ＭＩＨ不可能なモバイルユニット、並びに（ｉ）ＭＩＨ可能なネットワークコントローラ及び（ｉｉ）ＭＩＨ不可能なネットワークコントローラにおいて起こり得るハンドオーバ（ＨＯ）シナリオに関する分類テーブル８０である。図３に示すように、「ＭＮ」は任意の適切なモバイルノードを表し、「ネットワークコントローラ」は任意の適切なネットワークコントローラ、例えば、アクセスポイント（ＡＰ）、基地局コントローラ（ＢＳＣ）、トランシーバ基地局（ＢＴＳ）などを表す。参照符号８２によって示す第１の分類では、モバイルノード及びネットワークコントローラの両方がＭＩＨ可能である。したがって、分類１は、モバイルノード及びネットワークコントローラの両方における完全なハンドオーバ（ＨＯ）性能を表す。即ち、可能であるか又は必要とされるとき、推奨されるように、ＭＩＨハンドオーバ（ＨＯ）手続が続く、可能性の高いシナリオである。参照符号８４によって示す第２の分類では、モバイルノードはＭＩＨ可能であり、ネットワークコントローラはＭＩＨ不可能である。したがって、分類２はモバイルノードのみにおけるハンドオーバ（ＨＯ）性能を表す。即ち、適用可能な場合、デバイス始動のＭＩＨハンドオーバ（ＨＯ）を開始する、より可能性の高いシナリオである。参照符号８６によって示す第３の分類では、ネットワークコントローラはＭＩＨ可能であるが、モバイルノードはＭＩＨ不可能である。したがって、分類３はネットワークコントローラのみにおけるハンドオーバ（ＨＯ）性能を表す。即ち、適用可能な場合、ネットワーク始動のＭＩＨハンドオーバ（ＨＯ）を開始する、より可能性の高いシナリオである。参照符号８８によって示す第４の分類では、モバイルノード及びネットワークコントローラの両方がＭＩＨ不可能である。したがって、分類４はＭＩＨハンドオーバ（ＨＯ）性能を有しない既存のレガシーシステムを表す。

一実施形態では、この方法は、次の重要なモビリティイネイブラ又はコンポーネントによるモビリティ及びハンドオーバ（ＨＯ）の属性を含む。１つのコンポーネントは、修正されたビーコンの形態によるネットワーク性能ＩＤを含む。本明細書では、このビーコンをＭＩＨビーコンと呼ぶ。別のコンポーネントはネイティブプロトコルにおける最良適合の使用である。ネイティブプロトコルにおける最良適合は、既存のプロトコルに適合するブロードキャストモードに制御チャンネルコンセプトを実装することを含み、また、配置によって１つのプロトコルから別のプロトコルへ変化してもよい。さらに別のコンポーネントは、プロトコル影響を最小化するように最適化されたチャネル及びスペクトル効率を利用することを含む。モバイルノードデバイス始動のＭＩＨハンドオーバ（ＨＯ）では、この方法はリンクメトリック（Ｌ３）と、レベル１，２（Ｌ１−Ｌ２）報告を用いる。また、この方法はレガシーシステムに依存しておらず、ＭＩＨハンドオーバが成功裡に実行され得る。換言すると、このＭＩＨハンドオーバの方法は、レガシーシステムによっても機能する。さらに、この方法は、既存のプロトコルについての請求額、料金、サービス品質（ＱｏＳ）など他のプロトコル要素を、それぞれのプロトコルを変化させることなく考慮に含める。さらに、この方法はリンクセキュリティや上位レベルの保護など、既存のセキュリティ手段を利用する。リンクセキュリティは、ＡＡＡ、証明、信頼機構などを含むことが可能であり、上位層の保護はＤＲＭ（コンテンツ保護）を含むことが可能である。また、この方法は、例えば、バッテリー効率的なネット走査、低電力モードなど、電力節約（ＰＳ）モードを利用してもよい。

図４は、既存のプロトコルをネイティブモードとして用いる様々な接続を示す、別の異種ネットワーク９０に関する概略ブロック図である。示すように、ネットワーク９０はイーサネット９２、インターネット９４、パブリックドメイン交換ネットワーク（ＰＤＳＮ）９６、アクセスノード（ＡＮ）９８、及びセルラートランシーバ基地局（ＢＴＳ）１００を含む。セルラーＢＴＳ １００はモバイルノード（ＭＮ）１０２，１０４，１０６と通信を行う。ＡＮ ９８は、ＰＤＳＮ ９６、セルラーＢＴＳ １００、及び基地局コントローラ（ＢＳＣ）１０８との間に接続されている。インターネット９４は、イーサネット９２、ＰＤＳＮ ９６、ハイパーテキストトランスポートプロトコル（ＨＴＴＰ）サーバ１１０、ファイルトランスポートプロトコル（ＦＴＰ）サーバ１１２、及びビデオサーバ１１４との間に接続されている。インターネット９４は、図４に示すように、一連のドット「．．．」によって表現されるような追加のサーバへ接続されている。また、参照符号１１８，１２０，１２２によって示される一連のアクセスポイント（ＡＰ−１，ＡＰ−２，．．．，ＡＰ−ｎ）１１６は、イーサネット９２へ接続されている。各アクセスポイント（ＡＰ−１，ＡＰ−２，．．．，ＡＰ−ｎ）は、それぞれ一連の局ＳＴＡ−１，ＳＴＡ−２，．．．，ＳＴＡ−ｎへ接続されている。また、参照符号１２６，１２８，１３０によって示される一連の基地局コントローラ（ＢＳＣ−１，ＢＳＣ−２，．．．，ＢＳＣ−ｎ）１２４は、イーサネット９２へ接続されている。本開示の一実施形態では、この方法は、既存のプロトコルをネイティブモードとして用いること、わずか２つの新たな要素（即ち、ＭＩＨ性能（ＭＩＨＣ）フラグを含むＭＩＨビーコンと、ＭＩＨビーコンメッセージと）を導入すること、及び、モバイルインターネットプロトコルｖ６（ＭｏＩＰｖ６）を導入すること、に基づく。また、本開示の実施形態による方法は、サービスエンジンが実装に固有であるという点で既存のネット／リンクセキュリティ機構によっているので、異種ネットワークにおける他の要素の変化は不要である。さらに、図４には、異種ネットワークの一例しか示していない。例えば、ネットワークタイプ、局タイプなどに関して、他の構成が可能である。

図５は、論理ハンドオーバ（ＨＯ）に関するブロック図１４０である。論理ＨＯの図１４０では、全てのトラフィックタイプ及びペイロードはイーサネットレベル１４２に集中しており、ホームアドレス（Ｈｏｍｅ−Ａｄｒ）、気付アドレス（ｃ／ｏ−Ａｄｒ）、サブネットフィールドなど、ＭｏＩＰｖ６のルールに従う。例えば、関連するネットワークデバイス（図示せず）の層のペア（ＭＡＣ−ｘｘ １４４とＰＨＹ−ｘｘ １４６）、（ＭＡＣ−ｙｙ １４８とＰＨＹ−ｙｙ １５０）、（ＭＡＣ−ｚｚ １５２とＰＨＹ−ｚｚ １５４）はイーサネット１４２に集中している。また、サービスエンジンは、高速ＨＯにおいて重要な役割を担い、ネイティブトラフィックフロー及び非ネイティブトラフィックフローを可能とするので、必要とされるとき、関連するネットコントローラが調和することが可能である。

本開示の実施形態では、ＭＩＨビーコンを提供する方法は、（ｉ）ＭＩＨビーコンをブロードキャストするように構成されているネットワーク及びモバイルノード（ＭＮ）、（ｉｉ）バックグラウンドでネットワークを走査するように構成されているモバイルノード（ＭＮ）、（ｉｉｉ）近隣のネットワークを広告するように構成されているモバイルノード、のうちの１つ以上を含む。ＭＩＨビーコンをブロードキャストするように構成されているネットワーク及びモバイルノード（ＭＮ）の実施形態に関して、ブロードキャストは定期的なブロードキャストを含む。ビーコンは、ネットワークのＭＩＨ性能及びモバイルノードのＭＩＨ性能を含む。これに代えて、別の実施形態では、ネットワークはＭＩＨ性能フラグのみをブロードキャストするように構成されている。この実施形態では、ＭＮは、ネットワークがＭＩＨ可能であることを認識するように構成されている。ネットワークがＭＩＨ可能であると認識することに応じて、ＭＮは詳細なＭＩＨ性能についてネットワークに問い合せを行う。さらになお、反対にＭＮにおいてもこの実施形態が実行され得る。その場合、ＭＮはＭＩＨ性能フラグのみをブロードキャストするようになど、構成されている。

別の実施形態では、モバイルノード（ＭＮ）はバックグラウンドでネットワークを走査するように構成されている。この実施形態では、ＭＮは、そのＭＮが新たなネットワーク上にローミングを行うことを望む時を決定する。ＭＮは登録中に新たなネットワークと基本性能を交換するが、ＭＮと新たなネットワークとの両方のＭＩＨ性能は登録処理中に交換される。

別の実施形態では、モバイルノード（ＭＮ）は近隣のネットワークを広告するように構成されている。この実施形態では、ＭＮは、そのＭＮが聴取したネットワークの定期的なブロードキャストを実行する。

一実施形態では、ＭＩＨビーコンを用いる方法は、ＭＩＨビーコンをブロードキャストするようにネットワークを構成することを含む。詳細には、ネットワークはＭＩＨビーコンを定期的にブロードキャストするように構成される。ＭＩＨビーコンは、ブロードキャストネットワークのＭＩＨ性能を含む。この実施形態では、既存のプロトコルに対する様々な修正が必要である。新たな管理メッセージ、又は他の適切なフレームは、ＭＩＨビーコンを示すため、また、ネットワークのＭＩＨ性能を通信するために用いられる。また、ＭＩＨ性能を定義するために新たなデータタイプが提供される。

本開示の一実施形態では、ＭＩＨネットワーク選択シナリオは次を含み得る。１）電源投入（又は関連の）イベント時に、ＭＮがＭＩＨビーコンの存在を走査する。この走査には、例えば、最初にＭＮネイティブモードで走査し、次いで、所与の電源投入イベント又は関連のイベントに適切であるように、他のモードへ移ることが含まれ得る。ＭＩＨビーコンの存在の検出に応答して、利用可能な場合、ＭＮは即座にネイティブモードで登録を行う。２）ＭＮは、複数のネットワークからＭＩＨビーコンを受信する場合、ネットワークタイプを判定及び記録し、サービスエンジンなどによる影響を用いる。３）さらにＭＮは一次機能を判定するように構成されている。この一次機能は（ｉ）サービスエンジンルールを順守してネットワーク選択を判定すること、及び（ｉｉ）関連付ける又は関連付けないという決定に影響を与えるリンクメトリック、を含み得る。４）リンクメトリックに基づくネットワーク選択及び決定を判定し、所与のネットワークと関連付けることに応答して、ＭＮが相当するネットワークに登録する。

図６は、本開示の一実施形態による方法において用いられるＭＩＨビーコンメッセージコンテンツ１６０に関するブロック図である。ＭＩＨビーコンメッセージコンテンツ１６０は、ＭＡＣヘッダ１６２、サービス品質（ＱｏＳ）レベル１６４（４ビット）、アプリケーションクラス１６６（４ビット）、ネットワークタイプ（ＮＥＴ−ＴＹＰＥ）１６８（４ビット）、キャリア識別１７０（キャリアＩＤ）（３２ビット）、信頼レベル１７２（４ビット）、キャパシティ１７４（４ビット）、拡張サービス１７６（４ビット）、及び巡回冗長検査（ＣＲＣ）１７８のうちの１つ以上を含む、幾つかのフィールドを含む。

さらに、ＭＩＨビーコンはＭＩＨ性能（ＭＩＨＣ）フラグを含む。このフラグは、任意の所与の時間において、２つの状態のうちの１つを含むことが可能である。例えば、ＭＩＨＣフラグは、ＴＲＵＥ状態及びＦＡＬＳＥ状態のうちのいずれかを表す、単一ビットを含む。したがって、そのようなＭＩＨＣフラグによって、スペクトル的に最も効率的なオプションが提供される。一実施形態では、ＭＩＨＣフラグは、ＭＩＨビーコンをブロードキャストすることの一代替案であり、より少ないオーバヘッド（１ビット対多ビット）しか必要とせず、拡張の余地の制限されている既存のプロトコルによって、より良好に機能する。ＭＩＨＣフラグは、通常の方式で送信される事実上任意のパケット（又はパケットヘッダ）に挿入され得る。この場合、ＭＩＨＣフラグは、ネットワーク及びＭＮの両方に認識されている所定の位置に配置される。ＭＩＨＣフラグを受信すると、ＭＮは以下の段落に記載の手続にしたがって、ネットワークの正確なＭＩＨ性能を判定する。

一実施形態では、ＭＩＨＣフラグがセットされている場合、即ち、ＴＲＵＥである場合、幾つかのオプションが実装される。それらのオプションは、例えば、次のうちの１つ以上を含む。（ｉ）ＭＮは追加の詳細をネットワークに問い合わせ、その性能情報をネットワークと共有する、（ｉｉ）実装の一例として、フレキシブルエクステンシブルマークアップランゲージ（ＸＭＬ）及びパーミッションの適切な形態によって、性能情報サービス（ＩＳ）も共有される、（ｉｉｉ）サービスエンジンは参照を実行し、例えば、デコード用の参照テーブルへマッピングされている各フィールドなど、適切なＭＩＨ詳細を得る。

また、ＭＩＨＣフラグがセットされていない場合、即ち、ＦＡＬＳＥである場合にも、ＭＮは、ルーティング情報と共にＭＮの訪問中のネットワークの情報（ネット情報）をＭＮのネイティブネットワーク（ネット）へ送信することによって、ネットワークに登録する。サービスエンジンは、所与のハンドオーバに適切であるように、関連又は他のオプションを判定する。

ＭＩＨフィールドコンテンツには、ＭＩＨ性能情報フィールド又はサービス（ＩＳ）が含まれ得る。ＭＩＨ性能情報フィールド又はサービス（ＩＳ）は、必須のＩＳ又は随意のＩＳであり得る。必須のフィールド及び随意のフィールドを含むことによって、柔軟な拡張の提供が可能となる。必須分類は、例えば、Ｎｅｔタイプ、ＱｏＳ分類、料金／無料、キャリアＩＤ、信頼レベル、キャパシティ、拡張サービス及びリンクメトリックのうちの１つ以上を含むことが可能である。随意のフィールドは、例えば、拡張Ｎｅｔタイプ、データレート、キャパシティ、拡張サービスサポート、ホームＮｅｔメンバ、セキュリティグレード、ノマディックサポートなどのうちの１つ以上を含むことが可能である。さらに、一実施形態は、ＭＩＨ用のフィールドコンテンツの共通セットを採用することを含む。

図７は、本開示の一実施形態による方法において実行されるハンドオーバ（ＨＯ）のプローブ／レスポンスフローに関する図１８０である。示すように、ハンドオーバはＡｌｔ−Ｎｅｔ １８２、Ｎｅｔ−ｘｘネットワークコントローラ１８４、Ｎｅｔ−ｘｘ ＭＮ（１）１８６、Ｎｅｔ−ｘｘ ＭＮ（２）１８８，．．．，Ｎｅｔ−ｘｘ ＭＮ（ｎ）１９０のうちの１つ以上を伴い得る。この図では、Ａｌｔ−Ｎｅｔ １８２がＭＩＨビーコン１９２をブロードキャストする。ＭＩＨビーコン１９２に応答して、参照符号１９４，２０６，２１０によって示すように、Ｎｅｔ−ｘｘネットワークコントローラ１８４はＭＮへＮｅｔコントローラ問い合せを出力する。Ｎｅｔコントローラ問い合せ１９４，２０６，２１０に応答して、それぞれＭＮ １９０，１８８，１８６はＮｅｔコントローラ１８４に適切なＭＮ応答を提供する。この実施例では、ＭＮレスポンス１９６に応答して、参照符号１９８によって示すように、ネットワークコントローラ１８４はＭＮ １９０とハンドオーバについて交渉する。２００にて、ＭＮ １９０はネットワークコントローラ１８４へ応答する。次いで、参照符号２０２によって示すように、ネットワークコントローラ１８４はＡｌｔ−Ｎｅｔ １８２とのハンドシェイクを実行する。次いで、参照符号２０４によって示すように、ＭＮがＡｌｔ−Ｎｅｔ １８２とのハンドシェイクを行う。

さらに、図７の例に関連して、本開示の実施形態は、次のようなハンドオーバ（ＨＯ）におけるコンセプトの工程を含み得る。（１）ネットワークによる共通の基準を用いるＭＩＨ性能の広告、（２）Ｌ２による関連するＬ１へのリンクメトリックについての問い合せ、（３）Ｌ１による関連パラメータの報告、（４）２つのオプションを含め、Ｌ２（又は他の上位エンティティ）によるＨＯの適切さの判定、及び（５）ＨＯ及び最終的な転送の交渉。

一工程では、ネットワークによる共通の基準を用いるＭＩＨ性能の広告には、例えば、（ａ）ネットワークがリンク情報システム（ＩＳ）を用いるＭＩＨビーコンに基づき広告すること、（ｂ）サービスエンジン要件を満たす又はサービスエンジン要件を強化するネットワーク広告、が含まれ得る。別の工程では、Ｌ２による関連するＬ１へのリンクメトリックについての問い合せには、例えば、（ａ）Ｌ２による関連サービス／好適なサービスの認識、（ｂ）Ｌ２によるキーピングタブなどからサービス中のＨＯの区別、（ｃ）Ｌ２の問い合せは全てサービスエンジンによって始動されること、が含まれ得る。別の工程では、Ｌ１による関連パラメータの報告には、例えば、（ａ）Ｌ１によるリンク品質及び接続タイプの報告、（ｂ）Ｌ２による合意済みリストについてのメトリックの報告、（ｃ）特定のＨＯシナリオに適切であるような、連続的、定期的、又は必要とされる時のＬ２による報告、が含まれ得る。さらに別の工程では、２つのオプションを含め、Ｌ２（又は他の上位エンティティ）によるＨＯの適切さの判定には、（ａ）デバイスがＨＯをリクエストすること（ユーザ始動）、（ｂ）ネットワークがＨＯをリクエストすること（キャリア始動）が含まれ得る。別の工程では、ＨＯ及び最終的な転送の交渉には、例えば、（ａ）サービス及び関連する性能の維持、（ｂ）適切なサービス等級、請求額合意などの維持、などが含まれ得る。さらに、このＨＯについて多くのオプションが開発され得る。図７には、代替のネットワークを含むＭＩＨ Ｎｅｔコントローラ、ＭＮなどへの例示的なプローブ／レスポンスフローを示す。

また、さらに別の実施形態では、メディア非依存ハンドオーバ（ＭＩＨ）サービスを実装する方法は、合意済みルールへの準拠の表示としてのＭＩＨＣフラグの処置を含み得る。この合意済みルールでは、ＭＩＨ性能情報は無線接続を通じて送信されず（即ち、セキュリティの理由のため）、その代わりに、ＭＮを認証しＭＩＨ性能情報を返す、登録データベース又はサービスエンジンへの有線（イーサネット）接続を開始することが指定されてもよい。

リンクメトリックの例は、リンク品質のインジケータを含み得る。リンク品質のインジケータは、次のうちの１つ以上を含む。ＰＨＹ／ＭＡＣパラメータの組合せ、ＲＳＳＩ、ＳＮＲ、ＰＥＲ／ＢＥＲ、ＲＴＳ／ＣＴＳ、サポートされる最大ＰＨＹデータレート、パワーマネージメントモード、ＲＴＳしきい値、サービス優先度、フレームサイズ及び間隔、断片化状態、未ＡＣＫフレームの再試行、管理及び制御フレーム、キャパシティ又はポピュレーション（ＭＮの数）に関するメトリック、ＰＨＹタイプ、公称ビーコン区間など。また、一部のリンクインジケータはアプリケーション又はサービスと正規化されてもよい。全てのネットワークタイプを通じて必ずしも全ての要素が報告に利用可能である、又は適切であるとは限らない。換言すると、必須であるリンク品質インジケータからなる幾つかの基本セットが存在し他のセットはサービスエンジン固有、かつ、随意であり得る。さらに、一般にサービスエンジンが最終的な判定を行うので、報告されるリンクメトリックは、何であれＭＩＨの一因子に過ぎない。

本開示の実施形態では、（ａ）残りのリンクに対する据置アドレスと、（ｂ）別のフィールドの後部のネットワーク（などの）詳細との続く最小の情報量を用いてＭＩＨシグナリングを可能とする、スペクトル効率的なＭＩＨビーコンを提供する。この方法では、（ａ）チャネルのオーバーヘッド及び（ｂ）リンクトラフィックのうちの一方又は双方を最小化し、ＨＯ対象の／ＨＯ可能なＭＮによって、さらに細かい詳細を参照することのみを可能とすることが意図される。これらのタイプの節約（即ち、チャネルオーバーヘッド又はリンクトラフィックの最小化）の効果は、このタイプのビーコンの周波数や長さに依存して変化し、また、チャネル状態、例えば、ノイズ、信号強度及び全ポピュレーション、並びにメンバがネットワークコントローラと関連解除又は再関連付けする頻度に依存する。また、この方法は、ＭＩＨシグナリングに伴う様々なプロトコルに対する影響を最小化する。

本開示の実施形態の目標は、ＩＥＥＥ ８０２．２１ワーキンググループ（ＷＧ）の要件を厳守しつつ、複数のプロトコルをサポート可能なモバイルノード及びネットワークにおいてＭＩＨサービスを実施することである。本開示の実施形態は、以下の使用によって評価され得る。各ＭＮはＭＩＨ可能なマルチモードＭＮを含み得る。第２層（Ｌ２）を通じてサポートされる機能は、以下を含む。ネット検出、ネット選択及びシームレスＨＯ。アプリケーション分類は適切な分類システムに基づく。

上述において、明細書では、様々な実施形態に関連して開示を行った。しかしながら、添付の特許請求の範囲に記載の本発明の実施形態の範囲から逸脱することなく、様々な修正及び変更がなされ得ることが、当業者には認識される。したがって、明細書及び図面は限定的な意味ではなく、例示的な意味を有すると見なされるものであり、そうした修正は全て、本発明の実施形態の範囲に包含されることが意図される。したがって、本開示の実施形態では、異なる無線ネットワークプロトコル及び有線ネットワークプロトコルの間に標準化されたフォーマットを生じることによって、ＭＩＨサービスを可能とするための高速、高信頼性、かつ、最適な方法の確立を支援する。さらに、本開示の実施形態はＩＥＥＥ ８０２．２１に関して説明されているが、実施形態は、例えば、無認可モバイルアクセス（ＵＭＡ）、固定−モバイル収束アライアンス（ＦＭＣＡ）、デジタルリビングネットワークアライアンス（ＤＬＮＡ）及び他の類似の標準規格を含む、ＩＥＥＥ ８０２．２１以外の標準規格にも適用可能である。

異種ネットワークに関する概略ブロック図。 本開示の一実施形態による局機能エンティティとネットワーク機能エンティティとの間でＭＩＨ機能イベントを交換するために用いられる任意の適切なトランスポートプロトコルに関する概略ブロック図。 本開示の一実施形態による（ｉ）ＭＩＨ可能なモバイルユニット及び（ｉｉ）ＭＩＨ不可能なモバイルユニット並びに（ｉ）ＭＩＨ可能なネットワークコントローラ及び（ｉｉ）ＭＩＨ不可能なネットワークコントローラにおいて起こり得るハンドオーバ（ＨＯ）シナリオに関する分類テーブル。 既存のプロトコルをネイティブモードとして用いる様々な接続を示す、別の異種ネットワークに関する概略ブロック図。 論理ハンドオーバ（ＨＯ）に関するブロック図。 本開示の一実施形態による方法において用いられるＭＩＨビーコンメッセージコンテンツに関するブロック図。 本開示の一実施形態による方法において実行されるハンドオーバ（ＨＯ）のプローブ／レスポンスフローに関する図。

Claims (20)

1. １つ以上の異種ネットワーク及び非異種ネットワークの間にメディア非依存ハンドオーバ（ＭＩＨ）サービスを実装する方法であって、
   １つ以上のネットワーク（Ｎｅｔ）又はモバイルノード（ＭＮ）からＭＩＨビーコンを提供する工程と、
   別のネットワーク（Ｎｅｔ）又はモバイルノードによるＭＩＨビーコンの受信を認識する工程と、
   認識した受信に応答して、また、１つ以上のネットワーク（Ｎｅｔ）又はモバイルノード（ＭＮ）から続いて提供されるＭＩＨビーコンメッセージに応答して、ハンドオーバ（ＨＯ）サービスを実施する工程と、からなる方法。
2. ネットワークはネットワークコントローラ（Ｎｅｔコントローラ）を含む請求項１に記載の方法。
3. ハンドオーバ（ＨＯ）はネットワーク始動ハンドオーバである請求項１に記載の方法。
4. ハンドオーバ（ＨＯ）はモバイルノード始動ハンドオーバである請求項１に記載の方法。
5. ネットワーク（Ｎｅｔ）及びモバイルノード（ＭＮ）の両方はＭＩＨ可能であり、ハンドオーバ手続は必要に応じてネットワーク始動又はモバイルノード始動である請求項１に記載の方法。
6. ネットワーク（Ｎｅｔ）はＭＩＨ不可能であり、モバイルノード（ＭＮ）はＭＩＨ可能であり、ハンドオーバ手続は必要に応じてモバイルノード始動である請求項１に記載の方法。
7. ネットワーク（Ｎｅｔ）はＭＩＨ可能であり、モバイルノード（ＭＮ）はＭＩＨ不可能であり、ハンドオーバ手続は必要に応じてネットワーク始動である請求項１に記載の方法。
8. ＭＩＨビーコン及びＭＩＨビーコンメッセージはＨＯサービスに関連して要求されるネットワークオーバヘッドを減少させる請求項１に記載の方法。
9. ＭＩＨビーコンは第１状態及び第２状態のうちの一方を有する１つ以上のＭＩＨ性能（ＭＩＨＣ）フラグを含む請求項１に記載の方法。
10. 第１状態及び第２状態のうちの一方はＴＲＵＥを表し、第１状態及び第２状態のうちの他方はＦＡＬＳＥを表す請求項９に記載の方法。
11. ＭＩＨＣフラグは単一ビットを含む請求項９に記載の方法。
12. ＭＩＨＣフラグが第１状態であることはＭＩＨＣフラグがセットされていることを表す請求項９に記載の方法。
13. ＭＩＨＣフラグが第１状態であることに応答して、１つ以上の第１状態ＨＯオプションを実装する工程を含む請求項９に記載の方法。
14. １つ以上の第１状態ＨＯオプションはＭＮが追加の詳細についてネットワークに問い合せを行うこと又はＭＮがネットワークと性能情報を共有することを含む請求項１３に記載の方法。
15. 性能情報を共有することはフレキシブルＸＭＬ及びパーミッションの形態を共有することを含む請求項１４に記載の方法。
16. １つ以上の第１状態ＨＯオプションはサービスエンジンが参照を実行してＭＩＨ詳細を読み出すことを含むことと、規定のフィールドは相当するデコード用の参照テーブルへマッピングされていることと、を含む請求項１３に記載の方法。
17. ＭＩＨＣフラグが第２状態であることはＭＩＨＣフラグがセットされていないことを表す請求項９に記載の方法。
18. ＭＩＨＣフラグが第２状態であることに応答して、１つ以上の第２状態ＨＯオプションを実装する工程を含む請求項１７に記載の方法。
19. １つ以上の第２ＨＯオプションは（ｉ）ＭＮがネットワークに登録すること、（ｉｉ）ＭＮがそのＭＮのネイティブネットワークへ（ａ）訪問中のネットワークの情報及び（ｂ）ルーティング情報を送信すること、並びに、（ｉｉｉ）サービスエンジンが（ａ）ＭＮと訪問中のネットワークとの間の関連又は（ｂ）他の代替オプションを判定することを含む請求項１８に記載の方法。
20. 異なる無線ネットワークプロトコルと有線ネットワークプロトコルとの間のメディア非依存ハンドオーバ（ＭＩＨ）サービスを可能とする方法であって、
    １つ以上のネットワーク（Ｎｅｔ）又はモバイルノード（ＭＮ）からＭＩＨビーコンを提供する工程と、
    別のネットワーク（Ｎｅｔ）又はモバイルノードによるＭＩＨビーコンの受信を認識する工程と、
    認識した受信に応答して、また、１つ以上のネットワーク（Ｎｅｔ）から続いて提供されるＭＩＨビーコンメッセージに応答して、ハンドオーバ（ＨＯ）サービスを実施する工程と、
    ＭＩＨビーコンは第１状態及び第２状態のうちの一方を有する１つ以上のＭＩＨ性能（ＭＩＨＣ）フラグを含むことと、
    ＭＩＨＣフラグが第１状態であることに応答して、
    １つ以上の第１状態ＨＯオプションを実装する工程と、１つ以上の第１状態ＨＯオプションは（ａ）ＭＮが追加の詳細についてネットワークに問い合わせを行うこと若しくはＭＮがネットワークと性能情報を共有すること、又は（ｂ）モバイルノード若しくはサービスエンジンが参照を実行してＭＩＨ詳細を読み出すことを含むことと、規定のフィールドは相当するデコード用の参照テーブルへマッピングされていることと、
    ＭＩＨＣフラグが第２状態であることに応答して、
    １つ以上の第２状態ＨＯオプションを実装する工程と、１つ以上の第２状態ＨＯオプションは（ｉ）ＭＮがネットワークに登録すること、（ｉｉ）ＭＮがそのＭＮのネイティブネットワークへ（ａ）訪問中のネットワークの情報及び（ｂ）ルーティング情報を送信すること、並びに（ｉｉｉ）サービスエンジンが（ａ）ＭＮと訪問中のネットワークとの間の関連又は（ｂ）他の代替オプションを判定することを含むことと、からなる方法。

Images