JP5194114B2

JP5194114B2 - メディア独立ハンドオーバのためのデータ型符号化

Info

Publication number: JP5194114B2
Application number: JP2010508391A
Authority: JP
Inventors: 義洋大場; ダス、サビア; チェン、ユー−ヘン・アリス; タウイル、ミリアム; 謙一谷内
Original assignee: Toshiba Corp
Current assignee: Toshiba Corp
Priority date: 2007-05-11
Filing date: 2008-05-12
Publication date: 2013-05-08
Anticipated expiration: 2028-05-12
Also published as: JP2010527218A; CN101690317B; WO2008140817A3; EP2151132A4; US20090047959A1; WO2008140817A2; CN101690317A; US9526040B2; CA2686625A1; EP2151132A2; CA2686625C

Description

関連出願

本出願は、その開示内容全体が参照によりここに組み込まれているＹ．Ｏｂａらによる２００７年５月１１日出願の米国仮出願第６０／９１７，５４９号に対する優先権を主張する。

背景出願：
本出願はまた、背景参照のために下記の特許出願すべての全開示内容を参照によりここに組み入れている：
１）Ｋ．Ｔａｎｉｕｃｈｉらによる２００７年２月２３日出願の米国仮出願第６０／８９１，３４９号
２）Ｙ．Ａ．Ｃｈｅｎｇらによる２００６年９月１３日出願の米国仮出願第６０／８２５，５６７号
３）Ｙ．Ｏｂａらによる２００６年１２月５日出願の米国出願第１１／５６７，１３４号
４）Ｙ．Ｏｂａらによる２００６年１１月２３日出願の米国出願第１１／５６３，０００号
５）Ｙ．Ｏｂａらによる２００６年１１月１２日出願の米国出願第１１／５５８，９２２号
６）Ｙ．Ｏｂａらによる２００６年７月２７日出願の米国出願第１１／４６０，６１６号
７）ＦｒａｍｅｗｏｒｋＯｆＭｅｄｉａ−ＩｎｄｅｐｅｎｄｅｎｔＰｒｅ−ＡｕｔｈｅｎｔｉｃａｔｉｏｎＩｍｐｒｏｖｅｍｅｎｔｓ（メディア独立事前認証改善のフレームワーク）と題するＡ．Ｄｕｔｔａらによる２００６年４月１４日出願の米国出願第１１／２７９，８５６号
８）ＩｎｃｌｕｄｉｎｇＣｏｎｓｉｄｅｒａｔｉｏｎｓＦｏｒＦａｉｌｅｄＳｗｉｔｃｈｉｎｇＡｎｄＳｗｉｔｃｈｂａｃｋ（不成功スイッチングおよびスイッチバックに関する考察を含む）
９）ＦｒａｍｅｗｏｒｋＯｆＭｅｄｉａＩｎｄｅｐｅｎｄｅｎｔＰｒｅ−ＡｕｔｈｅｎｔｉｃａｔｉｏｎＳｕｐｐｏｒｔｆｏｒＰＡＮＡ（ＰＡＮＡのためのメディア独立事前認証サポートのフレームワーク）と題するＹ．Ｏｂａらによる２００６年３月９日出願の米国出願第１１／３０８，１７５号
１０）ＡＦｒａｍｅｗｏｒｋｏｆＭｅｄｉａ−ＩｎｄｅｐｅｎｄｅｎｔＰｒｅ−ａｕｔｈｅｎｔｉｃａｔｉｏｎ（メディア独立事前認証のフレームワーク）と題するＡ．Ｄｕｔｔａらによる２００６年２月出願の米国出願第１１／３０７，３６２号。

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

ＩＰ（インターネットプロトコル）に関して、これは、ネットワーク上である装置（電話機、ＰＤＡ［携帯情報端末］、コンピュータなど）から別の装置にデータを送るためのプロトコルである。今日、ＩＰｖ４、ＩＰｖ６などを含めて、様々なＩＰのバージョンがある。ネットワーク上の各ホスト装置は、独自の一意の識別子である少なくとも１つのＩＰアドレスを有する。

ＩＰはコネクションレス型プロトコルである。通信時の端点間接続は連続的ではない。ユーザーがデータまたはメッセージを送信し、または受信するとき、データまたはメッセージは、パケットと呼ばれる構成要素に分割される。各パケットは、独立のデータ単位として扱われる。

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

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

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

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

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

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

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

無線ネットワーク機器には、それだけに限らないが、ブルートゥース機器、複数インタフェース機器（ＭＩＤ）、８０２．１１ｘ機器（８０２．１１ａ、８０２．１１ｂ、８０２．１１ｇ機器などを含む、ＩＥＥＥ８０２．１１機器）、ＨｏｍｅＲＦ（家庭内無線周波数）機器、Ｗｉ−Ｆｉ（ＷｉｒｅｌｅｓｓＦｉｄｅｌｉｔｙ）機器、ＧＰＲＳ（汎用パケット無線システム）機器、３Ｇセルラ機器、２．５Ｇセルラ機器、ＧＳＭ（移動通信用グローバルシステム）機器、ＥＤＧＥ（ＥｎｈａｎｃｅｄＤａｔａｆｏｒＧＳＭＥｖｏｌｕｔｉｏｎ）機器、ＴＤＭＡ型（時分割多重接続）機器、またはＣＤＭＡ２０００を含むＣＤＭＡ型（符号分割多重接続）機器が含めることができる。各ネットワーク機器は、それだけに限らないが、ＩＰアドレス、ブルートゥース機器アドレス、ブルートゥース共通名、ブルートゥースＩＰアドレス、ブルートゥースＩＰ共通名、８０２．１１ＩＰアドレス、８０２．１１ＩＰ共通名、ＩＥＥＥＭＡＣアドレスを含む、様々な種類のアドレスを含むことができる。

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

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

メディア独立ハンドオーバサービス：
ＤｒａｆｔＩＥＥＥＳｔａｎｄａｒｄｆｏｒＬｏｃａｌａｎｄＭｅｔｒｏｐｏｌｉｔａｎＡｒｅａＮｅｔｗｏｒｋｓ：ＭｅｄｉａＩｎｄｅｐｅｎｄｅｎｔＨａｎｄｏｖｅｒＳｅｒｖｉｃｅｓ（地元地域および大都市圏のネットワークのためのドラフトＩＥＥＥ規格：メディア独立ハンドオーバサービス）と題する２００６年９月のＩＥＥＥ．Ｐ８０２．２１／Ｄ．０１．０９において、特にこの文書は８０２システムとセルラーシステムとの間のハンドオーバを最適化する８０２メディアアクセス独立機構を明記している。ＩＥＥＥ８０２．２１規格は、異種８０２システム間のハンドオーバの最適化を可能にし、また８０２システムとセルラーシステムとの間のハンドオーバを容易にし得る、拡張可能なメディアアクセス独立機構を定義している。

ＩＥＥＥ８０２．２１（メディア独立ハンドオーバ）規格の範囲は、異種メディア間のハンドオーバを最適化するためにリンク層情報および他の関連ネットワーク情報を上位層に供給する仕様を開発することである。これは、３ＧＰＰと、３ＧＰＰ２と、ＩＥＥＥ８０２ファミリーの規格における有線および無線メディア両者と、によって指定されるリンクを含む。この文書では「メディア」は、他に注記されていなければ、通信の感覚的態様（例えばオーディオ、ビデオなど）とは対照的に、電気通信システムにアクセスする方法／モード（例えばケーブル、無線通信、衛星など）を指す。文書の全内容がこの特許出願書にその一部として組み込まれているＤｒａｆｔＩＥＥＥＳｔａｎｄａｒｄｆｏｒＬｏｃａｌａｎｄＭｅｔｒｏｐｏｌｉｔａｎＡｒｅａＮｅｔｗｏｒｋｓ：ＭｅｄｉａＩｎｄｅｐｅｎｄｅｎｔＨａｎｄｏｖｅｒＳｅｒｖｉｃｅｓ（地元地域および大都市圏のネットワークのためのドラフトＩＥＥＥ規格：メディア独立ハンドオーバサービス）と題する２００６年９月のＩ．Ｅ．Ｅ．Ｅ．Ｐ８０２．２１／Ｄ．０１．０９の１．１を参照されたい。更に、ここで優先権が主張されている仮出願はまた、上記の規格のドラフト０５（ここではＤ０５と呼ばれる）を組み込んでおり、Ｄ０５の全内容は再び参照によりここに組み込まれている−すなわち、例えばＩ．Ｅ．Ｅ．Ｅ．コンピュータ学会のＬＡＮＭＡＮ規格委員会によって後援されているＤｒａｆｔＳｔａｎｄａｒｄｆｏｒＬｏｃａｌａｎｄＭｅｔｒｏｐｏｌｉｔａｎＡｒｅａＮｅｔｗｏｒｋｓ：ＭｅｄｉａＩｎｄｅｐｅｎｄｅｎｔＨａｎｄｏｖｅｒＳｅｒｖｉｃｅｓ（地元地域および大都市圏のネットワークのためのドラフト規格：メディア独立ハンドオーバサービス）と題する２００７年４月のＩ．Ｅ．Ｅ．Ｅ．Ｐ８０２．２１／Ｄ０５．００を参照されたい。

一般的アーキテクチャ：
序論：
ＩＥＥＥ８０２．２１規格は、種々のハンドオーバ方法を容易にするように意図されている。このような方法は一般に、移動ノードとネットワークとの間のデータパケットの交換をサポートするデータトランスポート（データ搬送）ファシリティーに関して、ハンドオーバ手順が「メーク前ブレーク(break before make）」または「ブレーク前メーク（make before break）」であるかどうかによって「ハード」または「ソフト」として分類される。

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

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

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

ｂ）ＭＩＨＦは、より上位の層に抽象サービスを提供する。この観点からＭＩＨＦは、上位層に統一的インタフェースを提供する。この統一インタフェースによってあらわになるサービスプリミティブは、異なるアクセスネットワークの技術固有プロトコルエンティティに基づいている。ＭＩＨＦは、技術固有インタフェースを介してモビリティ管理プロトコルスタックの下位層と通信する。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

このモデルは、ある緩やかな連続した仕方でコアネットワーク（オペレータ１―３コア）に接続されたアクセスネットワークを示す。また、よりタイトに相互接続または連結されたアクセスネットワーク（アクセスネットワーク・３）も描かれている。オペレータ１―３コアは各々、サービスプロバイダ、企業イントラネットプロバイダあるいはビジテッドアクセス（visited access）またはホームアクセスの単なる他の一部、あるいはコアネットワークを表す可能性がある。このモデルではサービス提供するプロバイダは、Ｒ１を介して１つのコア（ビジテッド／ホームコア・ネットワークとラベル付けされた）に連結されたアクセスネットワーク・３を運用している。用語ビジテッド（Visited）およびホーム（Home）はサービス提供するサービスプロバイダまたは企業を示すために使用される。図示のネットワークのいかなるものも、ＭＮのサービス提供業者とのオペレータの関係に依存してビジテッドまたはホームネットワークの両方になり得る。ネットワークプロバイダは、自身のネットワークへのハンドオーバを容易にするために自身のアクセスネットワーク（アクセスネットワーク・１―４）においてＭＩＨサービスを提供する。各アクセス技術は、そのＭＩＨ能力を宣伝するか、あるいはＭＩＨサービス発見に応答する。アクセスネットワークに関する各サービスプロバイダは、１つ以上のＭＩＨサービスポイント（ＰｏＳ、通信モデルと比較すること）へのアクセスを可能にする。これらのＰｏＳは、ＭＩＨ能力発見時に決定されたＭＩＨサービスの一部または全部を提供し得る。ＭＩＨＰｏＳの位置またはノードは、規格によって固定されない。ＰｏＳ位置は、オペレータの配置シナリオと技術固有ＭＩＨアーキテクチャとに基づいて変化し得る。

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

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

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

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

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

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

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

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

ＭＩＨサービスを使用する移動ノードは、イベントサービスのような非同期動作のためにリンク層からの指示を受信するであろう。コマンドサービスおよび情報サービスとの相互作用は、機構の同期クエリーおよび応答型を介して行われるであろう。ＭＩＨＦはまた、同じメディア型のネットワークエンティティとホストエンティティとの間の情報交換のための機能を提供するであろう。もしこのような情報交換のための機構が所定のメディア型をもって（例えばある幾つかのセルラーメディア型をもって）既に存在するならば、ＭＩＨＦはいつでも可能なときに既存の機構を利用するであろうことに留意されたい。

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

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

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

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

メディア独立情報サービス：
序論：
メディア独立情報サービス（ＭＩＩＳ）は、移動ノードおよびネットワーク両者におけるＭＩＨＦがハンドオーバを容易にするためにある地理的領域内のネットワーク情報を発見して取得し得るフレームワークを提供する。その目的は、これらのネットワークに亘ってローミングするときにシームレスハンドオーバを容易にするためにこの領域内のＭＮに関連するすべての異種ネットワークのグローバルなビューを取得することである。

メディア独立情報サービスは、種々の情報要素（ＩＥ）のサポートを含む。情報要素は、ネットワークセレクタが知的ハンドオーバ意思決定を行うために本質的である情報を提供する。

ハンドオーバを実行するためには、モビリティの型に依存して種々の型の情報要素のサポートが必要となり得る。例えば同じアクセスネットワークの異なるＰｏＡに亘る水平ハンドオーバの場合には、アクセスネットワークの下位リンク層からの利用可能な情報で十分である可能性がある。このような場合、イントラテクノロジ近隣レポートのような情報要素およびハンドオーバ時に必要とされる他のリンク層情報は、アクセスネットワークから直接利用可能である。このような場合、ネットワークによって提供される上位層サービスの利用可能性は、異なるネットワーク所属ポイントに亘って目立つほどには変化しない可能性がある。

他方、垂直ハンドオーバ時には、アクティブなユーザーアプリケーションに関してサービスおよびセッションの連続性を可能にするために最適なリンク層接続性ならびに適切な上位層サービスの利用可能性の両者に基づいて新しいネットワーク内で適当なＰｏＡを選択する必要がある。

メディア独立情報サービス（ＭＩＩＳ）は、ハンドオーバのために必要な情報を取得するための能力を提供する。これは、近隣マップおよび他のリンク層パラメータといった下位層に関する情報ならびにインターネット接続性、ＶＰＮサービスの利用可能性などといった利用可能な上位層サービスに関する情報を含む。ＭＩＩＳによって提供される異なる上位層サービスのセットは、絶え間なく進化することができる。同時に、ＭＩＩＳによってサポートされるアクセスネットワークのリストも進化し得る。そのようなものとして、ＭＩＩＳが異なる情報要素のサポートを提供する仕方には、柔軟性および拡張可能性の必要性が存在する。この目的のためにＭＩＩＳは、あるスキーマを定義する。このスキーマは、ＭＩＩＳのクライアントがＭＩＩＳの能力を発見し、また特定の実現形態によってサポートされる異なるアクセスネットワークとＩＥとのセット全体を発見するのを助ける。スキーマ表現はまた、移動ノードがより柔軟で効率的な仕方で情報を問い合わせることを可能にする。このスキーマを定義することの一部としてＭＩＩＳはまた、ＭＩＩＳの異なる実現形態のコア機能を定義し得る１セットの基本的情報要素を識別し得る。他の情報要素は、それらが追加されると、ＭＩＩＳ能力の拡張されたセットの一部になり得る。

ＭＩＩＳは、８０２ネットワーク、３ＧＰＰネットワークおよび３ＧＰＰ２ネットワークといった異なるアクセスネットワークに関する情報を提供する。ＭＩＩＳはまた、この収集された情報がいかなる単一のネットワークからでもアクセスされることを可能にする。

したがって例えば８０２．１１アクセスネットワークを使用して、特定の地域内の他のすべての８０２ネットワークに関する情報ばかりでなく３ＧＰＰおよび３ＧＰＰ２ネットワークの情報も取得することが可能であり得る。同様に３ＧＰＰ２インタフェースを使用して、所定の地域内のすべての８０２および３ＧＰＰネットワークに関する情報を利用することが可能であり得る。この能力は、移動ノードがその現在アクティブなアクセスネットワークを使用し、またある地理的地域内の他の利用可能なアクセスネットワークに関してスキャンすることを可能にする。このようにして移動ノードは、それの個別の無線通信の各々に電力供給し、そして異種ネットワーク情報にアクセスするという目的のためにネットワーク接続性を確立するという負担から解放される。ＭＩＩＳは、いかなる地理的領域においても異種ネットワーク情報を検索するための均一な仕方を提供することによって、すべての利用可能なアクセスネットワークに亘ってこの機能を使用可能にする。

情報サービス要素：
情報サービスの背後にある主要目標は、移動ノードとネットワークエンティティとがハンドオーバ時の適当なネットワークの選択に影響を及ぼし得る情報を発見することを可能にすることである。この情報は、この情報に基づいて効果的なハンドオーバ意思決定を行い得る方策エンジンエンティティによって主に使用されるように意図されている。この情報サービスは、ネットワーク構成の変更が明らかにされなくてはならないにもかかわらず、大抵の静止型の情報を提供するように期待されている。現在利用可能なリソースレベル、状態パラメータ、動態統計などといった異なるアクセスネットワークに関する他の動的情報は、それぞれのアクセスネットワークから直接取得されるべきである。この情報サービスの背後にある主要な動機の幾つかは次の通りである：
１）ある地理的領域におけるアクセスネットワークの利用可能性に関する情報を提供する。更にこの情報は、任意の無線ネットワークを使用して検索され得るであろう、例えば近隣のＷｉＦｉホットスポットに関する情報は、要求／応答シグナリングによるか、あるいはこれらのセルラーネットワーク上で明確にまたは暗示的にブロードキャストされる情報によるかによって、ＧＳＭ、ＣＤＭＡ、または他の何らかのセルラーネットワークを使用して取得され得るであろう。代替としてこの情報は、ＭＮによって内部データベースに維持され得るであろう。

２）適当なアクセスネットワークを選択する際に移動デバイスを援助し得る静的リンク層情報パラメータを提供する。例えば、セキュリティおよびＱｏＳがある特定のアクセスネットワーク上でサポートされているかどうかの知識は、ハンドオーバ時にこのようなアクセスネットワークを選択するための意思決定に影響を与え得る。

３）近隣レポートからなるリンク層情報および異なるＰｏＡの能力に関する情報もまた、利用可能な／選択されたアクセスネットワークに接続するために無線通信を最適に構成する際に助けとなり得るであろう。例えば異なるＰｏＡによってサポートされたチャネルに関する知識は、スキャン、ビーコンなどとは対照的に最適にチャネルを構成する際に、またこの情報を発見する際に助けとなり得る。しかしながらほとんどの部分に関して、アクセスネットワークとの直接的相互作用に基づいて動的リンク層パラメータが取得または選択されなければならず、またこれに関してこの情報サービスはあまり助けとなり得ない可能性がある。

４）異なるアクセスネットワークによってサポートされる上位層サービスの指示とハンドオーバ意思決定時に助けとなり得る他の関連情報とを提供する。このような情報は、特定のアクセスネットワークのＭＡＣ／ＰＨＹ層から直接利用可能でない可能性がある（あるいは利用可能にされ得ない）が、情報サービスの一部として提供され得るであろう。例えばある幾つかの場合には、公共、企業、家庭、その他などといったカテゴリへの異なるネットワークの分類は、ハンドオーバ意思決定に影響を与え得る。ここでの他の情報は事実上、より販売業者／ネットワーク固有である可能性があり、またこの形式で指定され得るであろう。

情報サービス要素は、３つのグループに分類される：
１）一般的アクセスネットワーク情報：これらの情報要素は、利用可能なネットワークおよびそれらの関連オペレータのリストといったある領域内のカバレッジを与える異なるネットワークと、異なるオペレータ間のローミング契約と、ネットワークへの接続のコストと、ネットワークセキュリティおよびサービス品質の能力と、の一般的概要を与える。

２）所属ポイントに関する情報：これらの情報要素は、利用可能なアクセスネットワークの各々のための異なるＰｏＡに関する情報を提供する。これらのＩＥは、ＰｏＡアドレス指定情報、ＰｏＡ位置、サポートされるデータ転送速度、ＰＨＹおよびＭＡＣ層の型、およびリンク層接続性を最適化するための任意のチャネルパラメータを含む。これはまた、上位層サービスと異なるＰｏＡの個別能力とを含む。

３）他の情報は、販売業者／ネットワーク固有である可能性があり、また適切に指定され得る。

メディア独立ハンドオーバプロトコル：
序論：
ＭＩＨは、下位層および上位層に関して明確なＳＡＰを介して非同期および同期サービスを提供する。提供されるサービスは、イベントサービス（ＥＳ）、コマンドサービス（ＣＳ）および情報サービス（ＩＳ）を含む。ＭＩＨサービスに関する詳細説明は、８０２．２１ドラフト文書に見出される。ＭＩＨＳＡＰは、種々のＭＩＨＦサービスへのアクセスを取得するためにＭＩＨのユーザーによって使用されるＭＩＨ上位層ＳＡＰと、種々のメディア依存下位層リソースのアクセスと制御とを取得するためにＭＩＨＦによって使用されるＭＩＨ下位層ＳＡＰとを含む。

ＭＩＨプロトコルは、ピアＭＩＨＦエンティティ間でメッセージを交換するためのフレームフォーマットを定義する。これらのメッセージは、メディア独立イベントサービス、メディア独立コマンドサービスおよびメディア独立情報サービスの一部であるプリミティブに基づいている。ＩＥＥＥ８０２．２１は、移動ノードおよびネットワークにおけるメディア独立ハンドオーバ機能をサポートする。ＭＩＨプロトコルは、ピアＭＩＨＦエンティティが互いに相互作用することを可能にする。

移動ノードのＭＩＨＦエンティティがＭＩＨプロトコル手順を開始するために移動ノードのＭＩＨＦエンティティは、それのピアリモートＭＩＨＦエンティティを発見できる。ピアリモートＭＩＨＦエンティティは、移動ノードのＭＩＨＦがＭＩＨプロトコルメッセージを交換する対応するＭＩＨＦエンティティである。ピアリモートＭＩＨＦエンティティはネットワークのどこかに常駐しているので、移動ノードのＭＩＨＦエンティティはＭＩＨプロトコル手順を開始する前にネットワーク内のＭＩＨＦエンティティを発見できる。これは、ＭＩＨ機能発見手順を介して行われる。

ＭＩＨ機能発見は、レイヤー２またはレイヤー３のいずれかにおいて行われ得る。しかしながらこの文書は、両方のＭＩＨ機能が同じブロードキャストドメイン内に位置しているときにＭＩＨＦ機能発見がどのようにしてレイヤー２において実行されるかを指定しているだけである。ＭＩＨ機能発見は、ＭＩＨプロトコルを介して（すなわちＬＬＣといったＬ２カプセル化を使用して）またはメディア固有レイヤー２ブロードキャストメッセージ（すなわち８０２．１１ビーコン、８０２．１６ＤＣＤ）を介して実行され得る。レイヤー３におけるＭＩＨ機能発見は、８０２．２１の範囲外である。

ひとたびピアＭＩＨＦが発見されるとＭＮは、ピアＭＩＨＦの能力を発見できる。これは、ＭＩＨ能力発見手順を介して行われる。ＭＩＨ能力発見は、ＭＩＨプロトコルを介して、またはメディア固有レイヤー２ブロードキャストメッセージ（すなわち８０２．１１ビーコン、８０２．１６ＤＣＤ）を介して実行され得る。

ピアＭＩＨＦがＭＮと同じブロードキャストドメイン内に常駐しているとき、ＭＩＨ機能発見はＭＩＨ能力発見だけを使用して実行され得る。

プロトコルの説明：
メディア独立ハンドオーバプロトコルは、下記のサービスを提供する：
１）ＭＩＨＦ発見（レイヤー２のみ）：移動ノードまたはネットワークにおけるＭＩＨＦは、アクセスネットワーク内のどのエンティティがＭＩＨＦをサポートしているかを発見する。

２）ＭＩＨ能力発見：ＭＩＨＦエンティティは、サポートされているイベントおよびコマンド、ならびに情報サービスのためにサポートされているクエリー型のリストを発見する。

３）ＭＩＨリモート登録：異なるエンティティにおけるリモートＭＩＨＦは、新しいＭＩＨセッションを確立するために互いを登録できる。

４）ＭＩＨイベント加入：関心のあるエンティティは、所定のＭＩＨ可能エンティティから特定の１セットのイベントへの加入を希望することができる。

５）ＭＩＨメッセージ交換：リモートＭＩＨＦは、ＭＩＨペイロードと適切なトランスポート上のＭＩＨプロトコルとを使用してＭＩＨメッセージを交換できる。メッセージ交換の一部としてピアＭＩＨ機能エンティティは、効果的なハンドオーバのためにＭＩＥＳ、ＭＩＣＳおよびＭＩＩＳを使用できる。

この規格は、メディア独立方式でのハンドオーバを容易にするためにＭＩＨフレームフォーマットとメッセージフォーマットとＭＩＨメッセージ交換用手順とを説明している。しかしながらハンドオーバ方策およびハンドオーバ意思決定は、この規格の範囲外である。

ＭＩＨプロトコル・フレームフォーマット：
ＭＩＨプロトコルメッセージではすべてのＴＬＶ定義は常にオクテット境界上に整列させられており、したがってパディングは必要とされない。図１１は、ＭＩＨプロトコルフレームの構成要素を示す。

メッセージパラメータＴＬＶ符号化：
図１２に示されたＴＬＶ符号化は、ＭＩＨプロトコルメッセージ内のすべてのパラメータのために使用される。これに関してＴｙｐｅ（型）フィールドは１オクテット２であるものとし、Ｌｅｎｇｔｈ（長さ）は下記のルールで符号化されるものとする（従属節６．５．６．２から引き継がれる）。更にＴＬＶＴｙｐｅ（型）値は、ＭＩＨプロトコル内では一意であるものとする。ＴＬＶ符号化は１から始まり、後続のいかなる値も昇順に割り当てられる。

従属節６．５．６．２に関してＭＩＩＳは、情報要素を表すための２つの方法：２進表現およびＲＤＦ表現を定義している（Ｗ３Ｃ勧告「リソース記述フレームワーク（ＲＤＦ）−概念および抽象構文」およびＷ３Ｃ勧告「ＲＤＦ／ＸＭＬ構文仕様」を参照されたい）。ＭＩＩＳはまた、２つのクエリー方法も定義している。２進表現を使用する要求のためにＴＬＶクエリー方法が定義されている。この２進表現方法では情報要素は図１０に示されたＴｙｐｅ−Ｌｅｎｇｔｈ−Ｖａｌｕｅ（型・長さ・値）形式で表現されて符号化される。これに関してＬｅｎｇｔｈ（長さ）フィールドは下記のように解釈される。

ケース１：もしＶａｌｕｅ（値）フィールドによって占められたオクテットの数が１２８より小さければ、Ｌｅｎｇｔｈフィールドのサイズは常に１オクテットであって、このオクテットのＭＳＢは値「０」にセットされる。このオクテットの他の７ビットの値はＶａｌｕｅフィールドの実際の長さを示す。

ケース２：もしＶａｌｕｅフィールドによって占められたオクテットの数がちょうど１２８であれば、Ｌｅｎｇｔｈフィールドのサイズは１オクテットである。このＬｅｎｇｔｈオクテットのＭＳＢは値「１」にセットされ、このオクテットの他の７ビットはすべて値「０」にセットされる。

ケース３：もしＶａｌｕｅフィールドによって占められたオクテットの数が１２８より大きければ、Ｌｅｎｇｔｈフィールドは常に１オクテットより大きい。Ｌｅｎｇｔｈフィールドの第１のオクテットのＭＳＢは値「１」にセットされ、第１のオクテットの残り７ビットは更に付加されるオクテットの数を示す。Ｌｅｎｇｔｈフィールドの第２および後続のオクテットによって表される数は１２８に加算されたときＶａｌｕｅフィールドの全サイズをオクテット単位で示す。

例示的アーキテクチャ：
図１３は、クライアントデバイスが通信する無線アクセスポイントを含むある幾つかの例示的かつ非限定的な実装に使用され得る、ある幾つかの例示的アーキテクチャ構成要素を示す。これに関して図１３は、一般に２１で示された無線ローカルエリアネットワーク（ＷＬＡＮ）に接続された例示的有線ネットワーク２０を示す。ＷＬＡＮ２１は、アクセスポイント（ＡＰ）２２と多数のユーザー局２３、２４とを含む。例えば有線ネットワーク２０は、インターネットまたは企業内データ処理ネットワークを含み得る。例えばアクセスポイント２２は無線ルータであることが可能であり、ユーザー局２３、２４は例えば携帯型コンピュータ、卓上型パソコン、ＰＤＡ、ＶｏＩＰ携帯電話および／または他のデバイスであり得る。アクセスポイント２２は、有線ネットワーク２１にリンクされたネットワークインタフェース２５と、ユーザー局２３、２４と通信する無線トランシーバと、を有する。例えば無線トランシーバ２６は、ユーザー局２３、２５との通信のための無線周波数用またはマイクロ波周波数用のアンテナ２７を含み得る。アクセスポイント２２はまた、プロセッサ２８とプログラムメモリ２９とランダムアクセスメモリ３１とを有する。ユーザー局２３は、アクセスポイント局２２との通信のためのアンテナ３６を含む無線トランシーバ３５を有する。同様にユーザー局２４は、アクセスポイント２２との通信のための無線トランシーバ３８とアンテナ３９とを有する。例としてある幾つかの実施形態では、このようなアクセスポイント（ＡＰ）内ではオーセンティケータが使用され得る、および／または移動ノードあるいはユーザー局内ではサプリカントまたはピアが使用され得るであろう。

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

本発明の好適な実施形態は、上記および他の背景技術を改善する。

本発明の好適な実施形態の一態様によれば、データ型とそれらの符号化ルールは共通の場所で定義される。好適な実施形態の一態様によれば、ＩＥ、ＴＬＶおよびプリミティブはこのようなデータ型を使用して定義される。

好適な実施形態の態様は、例えばａ）二重のフォーマット定義が回避され得る、ｂ）８０２．２１仕様がより読み取り易くなり得る（例えば主要セクションには詳細な型定義が存在しない）といった種々の利点を提供する。更に本発明の好適な実施形態の態様は、例えばａ）矛盾を除去するためにＩＥ、プリミティブおよびＴＬＶに関する二重のデータ型定義をなくすことができ、ｂ）抽象的データ型と符号化ルールとを明確に分離でき（例えばプリミティブパラメータの明確な分離を達成するためにＴＬＶ−ｉｎ−ＴＬＶ（ＴＬＶ内ＴＬＶ）の使用は困難である）、ｃ）数本のメッセージ（例えばＰｒｅｆｅｒｒｅｄＣａｎｄｉｄａｔｅＬｉｎｋ１・・・ｋ）における反復性ＴＬＶに対する順序付け問題を解決できる。

ある幾つかの実施形態によれば、ＩＥＥＥ８０２．２１規格で使用されるデータ型を定義する、付加された符号化ルールを有する規範的付属文書が提供される。好適には本明細書内のいかなる可変長データ型も、データの終端を決定するのに必要な情報を含む。好適にはアクセスネットワークコンテナとＰｏＡコンテナとに含まれる構成要素ＩＥに関するＴＬＶは、この付属文書において定義される。

好適な実施形態では、新規な符号化ルールがデータ型に適用され、上記の付属文書で説明されている。データ型のカテゴリは、一般的または基本的データ型と派生データ型とを含む。データ型のカテゴリは、下記で更に論じられる。

ある幾つかの実施形態によれば、少なくともあるデータ型に、長さ値なしでデータの終端を決定するのに必要な情報だけを搬送させることを備える、メディア独立ハンドオーバのための符号化スキームを使用する方法が提供される。ある幾つかの実施形態では、長さを決定するために型が定義される。ある幾つかの実施形態では、データ型は８０２．２１メディア独立ハンドオーバを実行するノード間でのメッセージ交換時に搬送される。ある幾つかの実施形態では、本方法は更に、データ型がＭＩＨプロトコルメッセージで搬送されるときに２進符号化ルールを使用することを含む。

ある幾つかの例では本方法は更に、ＳＥＱＵＥＮＣＥデータ型に関して下記の２進符号化ルール：「各データ型がそのデータ型用の符号化ルールを使用して符号化される場合にＤＡＴＡＴＹＰＥ１、ＤＡＴＡＴＹＰＥ２、［、・・・］は出現順に符号化される」という符号化ルールを使用することを含む。

ある幾つかの例では本方法は更に、ＣＨＯＩＣＥデータ型に関して下記の２進符号化ルール：「１オクテット・セレクタフィールドに可変長Ｖａｌｕｅフィールドが続き、この場合、Ｓｅｌｅｃｔｏｒ値はデータ型を決定し、またもしＳｅｌｅｃｔｏｒ＝＝ｉであればデータ型ＤＡＴＡＴＹＰＥ１、ＤＡＴＡＴＹＰＥ２、［、・・・］のリスト内の第（ｉ＋１）番目のデータ型が選択され、Ｖａｌｕｅフィールドは選択されたデータ型のための符号化ルールを使用して符号化される」という符号化ルールを使用することを含む。

ある幾つかの例では本方法は更に、ＢＩＴＭＡＰデータ型に関して下記の２進符号化ルール：「ＢＩＴＭＡＰ（Ｎ）値［Ｎ＝８^＊ｉ，ｉ＝１，２，・・・］の各ビットは、重み順にＮ／８オクテット値として符号化される」という符号化ルールを使用することを含む。

ある幾つかの例では本方法は更に、ＩＮＴＥＧＥＲデータ型に関して下記の２進符号化ルール：「ＩＮＴＥＧＥＲ（Ｎ）値［Ｎ＝１，２，・・・］の各オクテットは、ネットワークバイト順にＮオクテットフィールドに符号化される」という符号化ルールを使用することを含む。

ある幾つかの例では本方法は更に、ＣＨＡＲデータ型に関して下記の２進符号化ルール：「各文字の各ビットが重み順に符号化される場合に各文字は出現順に符号化される」という符号化ルールを使用することを含む。

ある幾つかの例では本方法は更に、ＵＮＳＩＧＮＥＤＩＮＴＥＧＥＲデータ型に関して下記の２進符号化ルール：「ＵＮＳＩＧＮＥＤ＿ＩＮＴ（Ｎ）値［Ｎ＝１，２，・・・］の各オクテットは、ネットワークバイト順にＮオクテットフィールドに符号化される」という符号化ルールを使用することを含む。

ある幾つかの例では本方法は更に、ＬＩＳＴ（ＤＡＴＡＴＹＰＥ）データ型に関して下記の２進符号化ルール：可変長Ｌｅｎｇｔｈフィールドに可変長Ｖａｌｕｅフィールドが続き、この場合、Ｌｅｎｇｔｈフィールド値はこのリスト内のリスト要素の数に関連している」という符号化ルールを使用することを含む。

種々の実施形態の上記および／または他の態様、特徴および／または利点は、添付の図に関連して下記の説明を考慮することによって更に理解されるであろう。種々の実施形態は、適用可能の場合に、異なる態様、特徴および／または利点を含み得る、および／または除外し得る。更に種々の実施形態は、適用可能の場合に他の実施形態の１つ以上の態様または特徴を組み合わせることができる。特定の実施形態の態様、特徴および／または利点の説明は、他の実施形態または特許請求の範囲を限定するものと解釈されるべきではない。

本発明の好適な実施形態は、限定的にではなく例として下記の添付図に示されている：
図１は、本発明のある幾つかの好適な実施形態による基本的データ型を表す例示的チャートである。図２は、ある幾つかの例示的実施形態による符号化された２つの要素を有する型ＬＩＳＴ（ＬＩＮＫ−ＩＤ）の属性を示す例示的図である。図３は、ある幾つかの実施形態による汎用の派生データ型を表す例示的チャートである。図４は、ある幾つかの実施形態によるアドレス派生データ型を表す例示的チャートである。図５は、ある幾つかの実施形態によるリンク識別派生データ型を表す例示的チャートである。図６は、ある幾つかの実施形態による例示的ＩＥ定義を表す例示的チャートである。図７は、ある幾つかの実施形態による例示的ＴＬＶ定義を表す例示的チャートである。図８は、背景および教育目的のために８０２．２１に示された例示的背景技術による例示的ＭＩＨ通信モデルを示す図である。図９は、背景および教育目的のために８０２．２１に示された例示的背景技術によるＭＩＨ通信基準点の説明のためのＭＩＨサービスを含む、例示的ネットワークモデルである。図１０は、２進表現方法においてＴｙｐｅ−Ｌｅｎｇｔｈ−Ｖａｌｕｅ形式で表現されて符号化された情報要素を示す図である。図１１は、ＭＩＨプロトコルフレームの構成要素を示す図である。図１２は、ＭＩＨプロトコルメッセージ内のすべてのパラメータのために使用されるＴＬＶ符号化を示す図である。図１３は、ある幾つかの例によるシステムアーキテクチャの例示的構成要素を明示する例示的アーキテクチャの図である。図１４は、ある幾つかの実施形態において例えばアクセスポイント、ユーザー局、送信元ノードまたは宛て先ノードといったデバイスによって実行されるコンピュータ化されたプロセスステップを実行するために使用され得る、例示的コンピュータまたは制御ユニットによる特徴を示す図である。

本発明は多くの異なる形で具現され得るが、本開示が本発明の原理の例を提供するものと考えられるべきであることと、このような例が本発明を本明細書に説明された、および／または本明細書に図解された好適な実施形態に限定するようには意図されていないということとの理解の下で、多数の例示的実施形態が本明細書において説明される。

本出願は、例えば８０２．２１における既存のデータ型符号化についての問題と進展とに対するある幾つかのソリューション（解決策）を説明する。

情報サービス符号化に関する用語は、作成される種々のデータ型が存在する（これらはすべてＴＬＶとして符号化されるのであるが）ので、幅広く考えられ得る。更にＭＩＨプロトコルの他の部分はＴＬＶで符号化されるが、ＩＳには関連していない。情報要素に関してこれらは、ＴＬＶクエリー方法が２進クエリー方法と呼ばれ得るように、「ＴＬＶ」の代わりに用語「２進符号化」を使用することと呼ばれ得るであろう。下記の考え方およびデータ型は、ＭＩＨプロトコルメッセージがＴＬＶを搬送する、情報サービス情報要素が２進符号化され得る、「コンテナ」が１グループのＩＥを保持し得る、および「リスト」が１つの順序付きグループの「コンテナ」を保持し得る、と理解されるべきである。

序論：
８０２．２１規格文書の背景草案には、例えばａ）セクション６．４．６．１．１の表９にリンク識別子ＴＬＶ値が定義されている、ｂ）６．４．６．３．２にロケーション（位置）ＴＬＶ値が定義されている、ｃ）リンクパラメータ値リストが「一般リンクパラメータ」を指している、およびｄ）セクション６．４．６．２．６でこれらのパラメータが定義されている、といったように、ある幾つかのＴＬＶに関する値符号化ルールがＩＥ定義で定義されている（一方、その他はＴＬＶ定義で定義されている）。更に例えばａ）ＳｕｐｐｐｏｒｔｅｄＭＩＨＣｏｍｍａｎｄＬｉｓｔ（サポートされたＭＩＨコマンドリスト）ビットマップがセクション７．４．１．２．２、７．４．１．３．１、７．４．１．４．２および８．５．２で定義されている、ｂ）ＬｉｎｋＡｃｔｉｏｎ（リンクアクション）がセクション７．３．１５．１２および８．５．２７で定義されている、ｃ）その他、といったように、プリミティブ定義およびＴＬＶ定義には多数の二重の値割当てが存在していた。

提案されたアプローチ：
本発明の好適な実施形態の一態様によれば、データ型およびそれらの符号化ルールは、共通の場所で定義される。これに関してこれは例えば、前の８０２．２１ドラフト規格の表２２を付加的符号化ルールを有する規範的付属文書に移すことを含んでいた。

好適な実施形態の一態様によれば、ＩＥ、ＴＬＶおよびプリミティブはこのようなデータ型を使用して定義される。

好適な実施形態の態様は、例えばａ）二重のフォーマット定義が回避され得る、ｂ）８０２．２１仕様がより読み易くなり得る（例えば主要なセクションに詳細な型定義が存在しない）、といった種々の利点を提供する。更に本発明の好適な実施形態の態様は、例えばａ）矛盾をなくすためにＩＥ、プリミティブおよびＴＬＶに関する二重のデータ型定義を除去し得る、ｂ）抽象的データ型と符号化ルールとを明確に分離し得る（例えばプリミティブパラメータの明確な分離を達成するためにＴＬＶ−ｉｎ−ＴＬＶ（ＴＬＶ内ＴＬＶ）の使用は困難である）、ｃ）数個のメッセージ内の反復性ＴＬＶについての順序付け問題を解決し得る（例えばＰｒｅｆｅｒｒｅｄＣａｎｄｉｄａｔｅＬｉｎｋ１・・・ｋ）。

ある幾つかの実施形態によれば、ＩＥＥＥ８０２．２１規格で使用されたデータ型を定義する、追加の符号化ルールを有する規範的付属文書が提供される。好適には、本明細書におけるいかなる可変長データ型も、データの終端を決定するのに必要な情報を含む。好適には、アクセスネットワークコンテナとＰｏＡコンテナとに含まれる構成要素ＩＥのためのＴＬＶはこの付属文書で定義される。

データ型のカテゴリ化：
好適な実施形態では、新規の符号化ルールがデータ型に適用され、また上記の付属文書で説明される。データ型のカテゴリは、一般的または基本的データ型と派生データ型とを含む。データ型カテゴリは更に下記で論じられる。

基本的／一般的データ型：
基本的データ型は、例えば汎用であるデータ型を含む他のいかなるデータ型からも派生されないデータ型を含む。

参考のために図１は、基本的データ型を説明する例示的付属文書部分を示す。好適には、このセクションで定義された基本的データ型は、他の任意のデータ型を定義するための基礎として使用される。好適にはすべての基本的データ型は汎用である。右の欄に描かれている「２進符号化ルール」は、データ型がＭＩＨプロトコルメッセージで搬送されるときに使用される符号化ルールを説明している。図１に示されたＭ．１．１におけるＬＩＳＴ（ＤＡＴＡＴＹＰＥ）データ型の符号化ルールに関して、好適にはＬＩＳＴ（ＤＡＴＡＴＹＰＥ）データ型のために下記の符号化が使用される。

可変長Ｌｅｎｇｔｈフィールドには可変長Ｖａｌｕｅフィールドが続く。Ｌｅｎｇｔｈフィールド値は、このリスト内のリスト要素の数に関連している。Ｌｅｎｇｔｈフィールドのフォーマットは次のように定義される。特にもしＶａｌｕｅフィールド内のリスト要素の実際の数が１２７より小さいか等しければ：
・Ｌｅｎｇｔｈフィールドは１オクテットを占めるものとする
・ＬｅｎｇｔｈフィールドのＭＳＢは０にセットされるものとする、そして
・Ｌｅｎｇｔｈフィールドの他の７ビットは、リスト要素の数におけるＶａｌｕｅフィールドの実際の長さを示すために使用されるものとする。

もしＶａｌｕｅフィールドのリスト要素の数がちょうど１２８であれば：
・Ｌｅｎｇｔｈフィールドは１オクテットを占めるものとする
・ＬｅｎｇｔｈフィールドのＭＳＢは値「１」にセットされるものとする、そして
・Ｌｅｎｇｔｈフィールドの他の７ビットはすべて値「０」にセットされるものとする。

もしＶａｌｕｅフィールドのリスト要素の数が１２７より大きければ：
・Ｌｅｎｇｔｈフィールドは１オクテットより多くを占めるものとする
・Ｌｅｎｇｔｈフィールドの第１のオクテットのＭＳＢは１にセットされるものとする。

・Ｌｅｎｇｔｈフィールドの第１のオクテットの他の７ビットは、Ｌｅｎｇｔｈフィールドの更なるオクテット（すなわち第１のオクテットを除く）の数を示すために使用されるものとする、そして
・Ｌｅｎｇｔｈフィールドの残りオクテット（すなわち第１のオクテットを除く）の値は１２８に加えられたときに、リスト要素の数におけるＶａｌｕｅフィールドの実際の長さを示すために使用されるものとする。

・リスト要素の各々は出現順にＶａｌｕｅフィールドにおいて符号化される。

・もしリスト要素が存在しなければＶａｌｕｅフィールドは符号化されない。

例えば２つのリスト要素を有する型ＬＩＳＴ（ＬＩＮＫＩＤ）の属性は図２に描かれた仕方で符号化され得る（ＬＩＮＫＩＤはＭ．２．３で定義される）。

図１に示されたように、このシステムは、ＳＥＱＵＥＮＣＥデータ型に関して下記の２進符号化ルール：「ＤＡＴＡＴＹＰＥ１、ＤＡＴＡＴＹＰＥ２、［、・・・］は出現順に符号化され、その場合、各データ型はそのデータ型のための符号化ルールを使用して符号化される」という符号化ルールを使用し得る。

図１に示されたように本システムはまた、ＣＨＯＩＣＥデータ型に関して下記の２進符号化ルール：「１オクテット・セレクタフィールドには可変長Ｖａｌｕｅフィールドが続き、ここでＳｅｌｅｃｔｏｒ値はデータ型を決定し、またもしＳｅｌｅｃｔｏｒ＝＝ｉであれば、データ型ＤＡＴＡＴＹＰＥ１、ＤＡＴＡＴＹＰＥ２、［、・・・］のリスト内の第（ｉ＋１）番目のデータ型が選択されて、Ｖａｌｕｅフィールドは選択されたデータ型のための符号化ルールを使用して符号化される」という符号化ルールを使用し得る。

図１に示されたように本システムはまた、ＢＩＴＭＡＰデータ型に関して下記の２進符号化ルール：「ＢＩＴＭＡＰ（Ｎ）値［Ｎ＝８^＊ｉ，ｉ＝１，２，・・・］の各ビットは重み順にＮ／８オクテット値として符号化される」という符号化ルールを使用し得る。ある幾つかの実施形態ではＢＩＴＭＡＰ符号化ルールは、ＢＩＴＭＡＰ（Ｎ）として定義され得る。ここでＮは多数のＮ／８オクテット値でなければならず、またネットワークバイト順に符号化されなければならない。注：このデータ型はしばしばＩＤのリストを表すために使用され得る。

図１に示されたように本システムはまた、ＩＮＴＥＧＥＲデータ型に関して下記の２進符号化ルール：「ＩＮＴＥＧＥＲ（Ｎ）値［Ｎ＝１，２，・・・］の各オクテットはネットワークバイト順にＮオクテットフィールドに符号化される」という符号化ルールを使用し得る。ある幾つかの実施形態では第１のオクテットの最上位ビットは符号ビットである。好適には、もしこの符号ビットがセットされれば、これは負の整数を示す。そうでなければ、これは好適には負でない整数を示す。負の整数は好適には２の補数として符号化される。

図１に示されたように本システムはまた、ＣＨＡＲデータ型に関して下記の２進符号化ルール：「各文字の各ビットが重み順に符号化される場合に各文字は出現順に符号化される」という符号化ルールを使用し得る。ある幾つかの実施形態ではＣＨＡＲデータ型は、文字がネットワークバイト順に符号化されるように符号化される。

図１に示されたように本システムはまた、ＵＮＳＩＧＮＥＤＩＮＴＥＧＥＲデータ型に関して下記の２進符号化ルール：「ＵＮＳＩＧＮＥＤ＿ＩＮＴ（Ｎ）値［Ｎ＝１，２，・・・］の各オクテットはネットワークバイト順にＮオクテットフィールドに符号化される」という符号化ルールを使用し得る。

派生データ型：
派生データ型は、他のデータ型から（例えば一般データ型から）派生したデータ型を含む。例えば派生データ型は、他のデータ型または親データ型から派生したデータ型を含む。派生データ型は例えば：
・汎用データ型（例えば図３に示された例示的派生型、汎用を参照）
・アドレス用データ型（例えば図４に示された例示的派生型、アドレスを参照）
・リンク識別および操作用データ型（例えば図５に示された例示的派生型、リンク識別を参照）
・ＱｏＳ用データ型
・位置用データ型
・ＩＰ構成用データ型
・情報要素によって使用されるデータ型
を含む親データ型と同じ符号化を使用する。

参考のために下記のセクションは、例えばある幾つかの好適な実施形態による派生データ型の幾つかの例示的事例に関して更なる詳細を説明する。

汎用データ型：
このセクションで定義される派生データ型は汎用である。

アドレス用データ型：
このセクションで定義されるデータ型はネットワーク要素のアドレスに関連する。

リンク識別および操作のためのデータ型：
このセクションで定義されるデータ型はリンクの識別および操作のための属性を表すために使用される。

ＱｏＳのためのデータ型：
このセクションで定義されるデータ型はＱｏＳに関する。

位置に関するデータ型：
このセクションで定義されるデータ型は位置に関する。

表Ｍ４：ＧＥＯＳＰＡＴＩＡＬ＿ＬＯＣＡＴＩＯＮの有効範囲
［ここにＤ０５の表１７を移動］
ＩＰ構成のためのデータ型：
このセクションで定義されるデータ型はＩＰ構成に関する。

情報サービスのために使用されるデータ型：
情報要素によって使用されるデータ型：
このセクションで定義されるデータ型はＩＥだけによって使用される。

表Ｍ５：ＮＥＴＷＯＲＫ＿ＴＹＰＥの有効範囲
［Ｄ０５の表９をここに移動］

情報サービスクエリー用のデータ型：

ＮＥＴＷＯＲＫ＿ＴＹＰＥ＿ＩＮＣＬＵＳＩＯＮは、もしクエリーで与えられれば、クエリアーが応答に含ませたいと思っている近隣ネットワーク型を示すために使用される。クエリアーは、対応するビットを「１」にセットすることによってクエリアーがクエリー応答に含ませたいネットワーク型を指示する。もし与えられなければ、情報サーバは、すべての利用可能なネットワーク型をクエリー応答に含ませるべきである。

ＮＥＴＷＯＲＫ＿ＩＮＣＬＵＳＩＯＮは、もしクエリーで与えられれば、クエリアーがクエリー応答に含ませたい特定のアクセスネットワークを示すために使用される。もし与えられなければ、情報サーバは、すべての利用可能なアクセスネットワークをクエリー応答に含ませるべきである。

ＲＥＰＯＲＴＩＮＧ＿ＴＥＭＰＬＡＴＥは、もし存在すれば、情報応答に含まれるべきＩＥのリストのテンプレートを情報サーバに指示する。

ＲＥＰＯＲＴＩＮＧ＿ＴＥＭＰＬＡＴＥを使用するためのルール。

１）もしＲＥＰＯＲＴＩＮＧ＿ＴＥＭＰＬＡＴＥが存在しなければ、近隣ネットワークコンテナの全リストは応答で返されるものとする。

２）もしコンテナがその構成要素ＩＥのいかなるものも持たずにリストアップされれば、コンテナ全体が応答で返されるものとする。例えば、ＴＹＰＥ＿ＩＥ＿ＣＯＮＴＡＩＮＥＲ＿ＰＯＡの包含は単に、それらすべての構成要素ＩＥを有するＰｏＡコンテナのリストを返す。

３）もしコンテナがそれの構成要素ＩＥの１つ以上を持ってリストアップされれば、リストアップされた構成要素ＩＥだけを有するコンテナが返されるものとする。例えば、ＴＹＰＥ＿ＩＥ＿ＣＯＮＴＡＩＮＥＲ＿ＮＥＴＷＯＲＫ、ＴＹＰＥ＿ＩＥ＿ＮＥＴＷＯＲＫ＿ＴＹＰＥおよびＴＹＰＥ＿ＩＥ＿ＯＰＥＲＡＴＯＲ＿ＩＤＥＮＴＩＦＩＥＲの包含は単に、各々がネットワーク型とオペレータＩＤだけを含むネットワークコンテナのリストを返す。

４）もし構成要素ＩＥがその親コンテナを持たずにリストアップされれば、リストアップされた構成要素ＩＥは個別ＩＥとして返されるものとする。例えばＴＹＰＥ＿ＩＥ＿ＮＥＴＷＯＲＫ＿ＴＹＰＥとＴＹＰＥ＿ＩＥ＿ＣＯＳＴの包含は単に、ネットワーク型のリストとコストのリストとを返す。注：これらの関係からの個別ＩＥのリストは、極めて限定された有用さを有し得る。これはレポートテンプレートの柔軟な使用を示すための単なる一例である。

返されるＩＥを生成するためのルール：
２進クエリーの受信時に情報サーバは：
１）所定の位置に関する近隣アクセスネットワーク情報のリストを作成するであろう。

・もしクエリーでＮＥＴＷＯＲＫ＿ＴＹＰＥ＿ＩＮＣＬＵＳＩＯＮが与えられれば、このＮＥＴＷＯＲＫ＿ＴＹＰＥ＿ＩＮＣＬＵＳＩＯＮに示されたネットワーク型の近隣アクセスネットワークの情報だけを含む。そうでなければ所定の位置に関する利用可能なすべての近隣アクセスネットワークの情報を含む。

・もしクエリーでＮＥＴＷＯＲＫ＿ＩＮＣＬＵＳＩＯＮが与えられれば、このＮＥＴＷＯＲＫ＿ＩＮＣＬＵＳＩＯＮに示された近隣アクセスネットワークの情報だけを含む。そうでなければ所定の位置に関する利用可能なすべての近隣アクセスネットワークの情報を含むであろう。

２）もしクエリーでＲＥＰＯＲＴＩＮＧ＿ＴＥＭＰＬＡＴＥが与えられなければ、情報応答において近隣アクセスネットワークコンテナのリスト内の近隣アクセスネットワーク情報のリストを送る。

３）もしクエリーでＲＥＰＯＲＴＩＮＧ＿ＲＥＳＰＯＮＳＥが与えられれば、上記のＲＥＰＯＲＴＩＮＧ＿ＴＥＭＰＬＡＴＥ処理ルールを使用して近隣アクセスネットワーク情報のリストから要求されたＩＥ／コンテナを抽出してこれらを情報応答で送信するであろう。

ＭＩＨＦ識別のためのデータ型：

イベント加入識別のためのデータ型：

ＭＩＨ能力のためのデータ型：

ＭＩＨ登録のためのデータ型：

ハンドオーバ動作のためのデータ型：

ＭＩＨ＿ＮＥＴＳＡＰプリミティブのためのデータ型：

ＭＩＨ＿ＮＭＳＳＡＰプリミティブのためのデータ型：
これは、本開示に基づいて当業者によって確立され得る。

未定義のデータ型；
本開示に基づいて当業者によって定義され得る。

８０２．２１ドラフト文書のセクション８の変更
ある幾つかの実施形態では上記８０２．２１ドラフト文書のセクション８は、ＴＬＶ型値への参照をＴＬＶ型名への参照に置き換えるために修正され得る。例えばＭＩＨ＿Ｃａｐａｂｉｌｉｔｙ＿Ｄｉｓｃｏｖｅｒ要求メッセージフォーマットは、下記のように見えるべきである：

参考のために、ＭＩＨメッセージフォーマットの属性名と実際のＴＬＶ型名との間のマッピングが下記に与えられる。

ＴＬＶ表のための新しい付属文書：
ある幾つかの実施形態によればＴＬＶのリストのための新しい付属文書が次のように提供され得る。

８０２．２１によってサポートされる情報要素：
参考のために図６は、ＩＥＥＥ８０２．２１規格によってサポートされ得る情報要素の部分的リストを示す。各情報要素の値は、注記の付属文書にセマンティックスと２進符号化が定義されている抽象的データ型を有する。これらの情報要素のＴＬＶ表現は、８０２．２１ドラフト文書のセクション６．４．６に説明されている。ＲＤＦを使用してこれらのＩＥを表すもう１つの方法は、８０２．２１ドラフト文書の６．４．７．１に説明されている。これらのＩＥは、ＴＬＶを使用して、またはリソース記述フレームワーク（ＲＤＦ）ベースのクエリー機構を使用して検索され得る。

ＳＡＰプリミティブおよびパラメータ型：
ＳＡＰは、１セットのプリミティブとして定義される。総合すればプリミティブはサービスを定義する。各プリミティブの定義には許容可能なパラメータの表が存在する。各パラメータは、抽象的データ型を使用して定義される。これらの型は、このパラメータの意味値を示す。特定のプリミティブに関する文節内で定義されたパラメータは、このプリミティブによって生成または消費される。抽象的データ型の幾つかは、多数のプリミティブ定義で使用される。各抽象的データ型定義には、この型に適用された種々の名前がリストアップされている。プリミティブの大部分は、対応するＭＩＨプロトコルメッセージを有する。これらのメッセージには、プロトコル内にプリミティブパラメータ抽象データ型を実現するＴＬＶ符号化パラメータが存在する。これらの例示の各々に関する完全な２進符号化の定義は、付属文書に説明されている。

ある幾つかの実施形態では、８０２．２１ドラフト規格における「サービスプリミティブのセマンティックス」のセクションは、各プリミティブ定義セクションが下記に説明されるように変更される：
７．３．１．１．２サービスプリミティブのセマンティックス
プリミティブパラメータは次の通りである：
Link_Event_Subscribe.request (
RequestedLinkEventList
)
パラメータ：

７．３．１．２．２サービスプリミティブのセマンティックス
プリミティブパラメータは次の通りである：
Link_Event_Subscribe.confirm (
ResponseLinkEventList,
Status
)
パラメータ：

７．３．２．１．２サービスプリミティブのセマンティックス
プリミティブパラメータは次の通りである：
Link_Event_Unsubscribe.request (
RequestedLinkEventList
)
パラメータ：

７．３．１．２．２サービスプリミティブのセマンティックス
プリミティブパラメータは次の通りである：
Link_Event_Unsubscribe.confirm (
ResponseLinkEventList,
Status
)
パラメータ：

７．３．３．１．２サービスプリミティブのセマンティックス
プリミティブパラメータは次の通りである：
Link_Configure_Thresholds.request (
LinkConfigureParameterList
)
パラメータ：

７．３．３．２．２サービスプリミティブのセマンティックス
プリミティブパラメータは次の通りである：
Link_Configure_Thresholds.confirm (
LinkConfigureStatusList,
Status
)
パラメータ：

７．３．４．２サービスプリミティブのセマンティックス
プリミティブパラメータは次の通りである：
Link_Up.indication (
LinkIdentifier,
MacOldAccessRouter,
MacNewAccessRouter,
IPRenewalFlag,
Mobility Management Support
)
パラメータ：

７．３．５．２サービスプリミティブのセマンティックス
Link_Down.indication (
LinkIdentifier,
MacOldAccessRouter,
ReasonCode
)
パラメータ：

７．３．６．２サービスプリミティブのセマンティックス
Link_Going_Down.indication (
LinkIdentifier,
TimeInterval,
ConfidenceLevel,
LinkGoingDownReason,
UniqueEventIdentifier
)
パラメータ：

７．３．７．２サービスプリミティブのセマンティックス
プリミティブパラメータは次の通りである：
Link_Event_Rollback.indication (
LinkIdentifier,
UniqueEventIdentifier
)
パラメータ：

７．３．８．２サービスプリミティブのセマンティックス
プリミティブパラメータは次の通りである：
Link_Detected.indication (
LinkIdentifier,
MIHCapabilityFlag
)
パラメータ：

７．３．９．２サービスプリミティブのセマンティックス
Link_Parameters_Report.indication(
LinkIdentifier,
LinkParametersReportList
)
パラメータ：

７．３．１０．２サービスプリミティブのセマンティックス
プリミティブパラメータは次の通りである：
Link_PDU_Transmit_Status.indication (
LinkIdentifier,
PacketIdentifier,
TransmissionStatus
)
パラメータ：

７．３．１１．２サービスプリミティブのセマンティックス
プリミティブパラメータは次の通りである：
Link_Handover_Imminent.indication (
LinkIdentifier,
MacOldAccessRouter,
MacNewAccessRouter
)
パラメータ：

７．３．１３．２．２サービスプリミティブのセマンティックス
プリミティブパラメータは次の通りである：
Link_Capability_Discover.confirm (
SupportedLinkEventList,
SupportedLinkCommandList,
Status
)
パラメータ：

７．３．１４．１．２サービスプリミティブのセマンティックス
プリミティブパラメータは次の通りである：
Link_Get_Parameters.request (
LinkParametersRequest
)
パラメータ：

７．３．１４．２．２サービスプリミティブのセマンティックス
プリミティブパラメータは次の通りである：
Link_Get_Parameters.confirm (
LinkParametersStatusList,
Status
)
パラメータ：

７．３．１５．１．２サービスプリミティブのセマンティックス
サービスプリミティブのパラメータは次の通りである：
Link_Action.request (
LinkIdentifier
LinkAction
ExecutionTime
)
パラメータ：

７．３．１５．２．２サービスプリミティブのセマンティックス
サービスプリミティブのパラメータは次の通りである：
Link_Action.confirm (
ScanResponseSet,
Status
)

７．４．１．１．２サービスプリミティブのセマンティックス
MIH_Capability_Discover.request (
DestinationIdentifier,
SupportedMihEventList,
SupportedMihCommandList,
SupportedIsQueryTypeList,
SupportedTransportList
)

７．４．１．２．２サービスプリミティブのセマンティックス
MIH_Capability_Discover.indication (
SourceIdentifier,
SupportedMihEventList,
SupportedMihCommandList,
SupportedIsQueryTypeList,
SupportedTransportList
)

７．４．１．３．１サービスプリミティブのセマンティックス
MIH_Capability_Discover.response(
DestinationIdentifier,
SupportedMihEventList,
SupportedMihCommandList,
SupportedIsQueryTypeList,
SupportedTransportList,
Status
)

７．４．１．４．２サービスプリミティブのセマンティックス
MIH_Capability_Discover.confirm (
SourceIdentifier,
SupportedMihEventList,
SupportedMihCommandList,
SupportedIsQueryTypeList,
SupportedTransportList,
Status
)

７．４．２．１．２サービスプリミティブのセマンティックス
MIH_Register.request (
DestinationIdentifier,
RequestCode
)

７．４．２．２．２サービスプリミティブのセマンティックス
MIH_Register.indication (
SourceIdentifier,
RequestCode
)

７．４．２．３．２サービスプリミティブのセマンティックス
MIH_Register.response (
Destination Identifier,
ValidityTime,
Status
)

７．４．２．４．２サービスプリミティブのセマンティックス
MIH_Register.confirm (
SourceIdentifier,
ValidityTime,
Status
)

７．４．３．２．２サービスプリミティブのセマンティックス
MIH_DeRegister.indication(
SourceIdentifier
)

MIH_DeRegister.response (
DestinationIdentifier,
Status
)

７．４．３．４．２サービスプリミティブのセマンティックス
MIH_DeRegister.confirm (
SourceIdentifier,
Status
)

７．４．４．１．２サービスプリミティブのセマンティックス
プリミティブパラメータは次の通りである：
MIH_Event_Subscribe.request (
DestinationIdentifier,
LinkIdentifier,
RequestedMihEventList
)

７．４．４．２．２サービスプリミティブのセマンティックス
プリミティブパラメータは次の通りである：
The primitive parameters are as follows:
MIH_Event_Subscribe.confirm (
SourceIdentifier
LinkIdentifier,
ResponseMihEventList,
Status
)

７．４．５．１．２サービスプリミティブのセマンティックス
プリミティブパラメータは次の通りである：
MIH_Event_Unsubscribe.request (
DestinationIdentifier,
LinkIdentifier,
RequestedMihEventList
)

７．４．５．２．２サービスプリミティブのセマンティックス
プリミティブパラメータは次の通りである：
MIH_Event_Unsubscribe.confirm (
SourceIdentifier,
LinkIdentifier,
ResponseMihEventList,
Status
)

７．４．１０．１．２サービスプリミティブのセマンティックス
プリミティブパラメータは次の通りである：
MIH_Link_Parameters_Report.indication (
SourceIdentifier,
LinkIdentifier,
LinkParametersStatusList
)

７．４．１３．１．２サービスプリミティブのセマンティックス
プリミティブパラメータは次の通りである：
MIH_Link_Handover_Imminent.indication (
SourceIdentifier,
Old Link Identifier,
New Link Identifier,
HO_Type,
MacOldAccessRouter,
MacNewAccessRouter
)

プリミティブパラメータは次の通りである：
MIH_Link_Handover_Complete.indication (
SourceIdentifier,
OldLinkIdentifier,
NewLinkIdentifier,
MacOldAccessRouter,
MacNewAccessRouter
)

７．４．１５．１．２サービスプリミティブのセマンティックス
プリミティブのパラメータは次の通りである：
MIH_Get_Link_Parameters.request (
DestinationIdentifier,
LinkIdentifierList,
GetStatusRequestSet
)

７．４．１５．２．２サービスプリミティブのセマンティックス
プリミティブのパラメータは次の通りである：
MIH_Get_Link_Parameters.confirm (
SourceIdentifier,
GetStatusResponseList,
Status
)

７．４．１６．１．２サービスプリミティブのセマンティックス
プリミティブのパラメータは次の通りである：
MIH_Configure_Link.request (
DestinationIdentifier,
LinkIdentifier,
ConfigurationRequestsList
)

７．４．１６．２．２サービスプリミティブのセマンティックス
プリミティブのパラメータは次の通りである：
MIH_Configure_Link.confirm (
SourceIdentifier,
LinkIdentifier,
ConfigurationResponseList,
Status
)

７．４．１７．１．２サービスプリミティブのセマンティックス
プリミティブのパラメータは次の通りである：
MIH_Scan.request (
DestinationIdentifier,
ScanLinkIdentifier
)

７．４．１７．２．２サービスプリミティブのセマンティックス
プリミティブのパラメータは次の通りである：
MIH_Scan.confirm (
SourceIdentifier,
ScanLinkIdentifier,
ScanResponseSets,
Status
)

７．４．１８．１．２サービスプリミティブのセマンティックス
プリミティブのパラメータは次の通りである：
MIH_Net_HO_Candidate_Query.request (
DestinationIdentifier,
SuggestedNewLinkList,
HandoverMode,
OldLinkAction,
QueryResourceList
)

７．４．１８．２．２サービスプリミティブのセマンティックス
プリミティブのパラメータは次の通りである：
MIH_Net_HO_Candidate_Query.indication (
SourceIdentifier,
SuggestedNewLinkList,
HandoverMode,
OldLinkAction,
QueryResourceList
)

７．４．１８．３．２サービスプリミティブのセマンティックス
プリミティブのパラメータは次の通りである：
MIH_Net_HO_Candidate_Query.response (
DestinationIdentifier,
CurrentLinkIdentifier,
HandoverAck,
PreferredLinkList,
RequestedResourceSet,
ErrorCode,
Status
)

７．４．１８．４．２サービスプリミティブのセマンティックス
プリミティブのパラメータは次の通りである：
MIH_Net_HO_Candidate_Query.confirm (
SourceIdentifier,
CurrentLinkIdentifier,
HandoverAck,
PreferredLinkList,
RequestedResourceSet,
ErrorCode,
Status
)

７．４．１９．１．２サービスプリミティブのセマンティックス
プリミティブのパラメータは次の通りである：
MIH_MN_HO_Candidate_Query.request (
DestinationIdentifier,
CurrentLinkIdentifier,
CandidateLinkList,
QueryResourceList,
IPConfigurationMethod,
DHCPServerAddress,
FAAddress,
AccessRouterAddress
)

７．４．１９．２．２サービスプリミティブのセマンティックス
プリミティブのパラメータは次の通りである：
MIH_MN_HO_Candidate_Query.indication (
SourceIdentifier,
CurrentLinkIdentifier,
CandidateLinkList,
QueryResourceList,
IPConfigurationMethod,
DHCPServerAddress,
FAAddress,
AccessRouterAddress
)

７．４．１９．３．２サービスプリミティブのセマンティックス
プリミティブのパラメータは次の通りである：
MIH_MN_HO_Candidate_Query.response (
DestinationIdentifier,
CurrentLinkIdentifier,
PreferredCandidateLinkList,
AvailableResourceSet,
IPConfigurationMethod,
DHCPServerAddress,
FAAddress,
AccessRouterAddress,
IPAddressInformationStatus,
Status
)

７．４．１９．４．２サービスプリミティブのセマンティックス
プリミティブのパラメータは次の通りである：
MIH_MN_HO_Candidate_Query.confirm (
SourceIdentifier,
CurrentLinkIdentifier,
PreferredCandidateLinkList,
AvailableResourceSet,
IPConfigurationMethod,
DHCPServerAddress,
FAAddress,
AccessRouterAddress,
IP Address Information Status,
Status
)

７．４．２０．１．２サービスプリミティブのセマンティックス
プリミティブのパラメータは次の通りである：
MIH_N2N_HO_Query_Resources.request (
DestinationIdentifier,
QueryResourceList,
IPConfigurationMethod,
DHCPServerAddress,
FAAddress,
AccessRouterAddress
)

７．４．２０．２．２サービスプリミティブのセマンティックス
プリミティブのパラメータは次の通りである：
MIH_N2N_HO_Query_Resources.indication (
SourceIdentifier,
QueryResourceList,
IPConfigurationMethod,
DHCPServerAddress,
FAAddress,
AccessRouterAddress
)

７．４．２０．３．２サービスプリミティブのセマンティックス
プリミティブのパラメータは次の通りである：
MIH_N2N_HO_Query_Resources.response (
DestinationIdentifier,
ResourceStatus,
AvailableResourceSet,
IPConfigurationMethod,
DHCPServerAddress,
FAAddress,
AccessRouterAddress,
IPAddressInformationStatus,
Status
)

プリミティブのパラメータは次の通りである：
MIH_N2N_HO_Query_Resources.confirm (
SourceIdentifier,
ResourceStatus,
AvailableResourceSet,
IPConfigurationMethod,
DHCPServerAddress,
FAAddress,
AccessRouterAddress,
IPAddressInformationStatus,
Status
)

７．４．２１．１．２サービスプリミティブのセマンティックス
プリミティブのパラメータは次の通りである：
MIH_Net_HO_Commit.request (
DestinationIdentifier,
HandoverCommitParameterList
)

７．４．２１．２．２サービスプリミティブのセマンティックス
プリミティブのパラメータは次の通りである：
MIH_Net_HO_Commit.indication (
LinkActionSetList
)

７．４．２１．３．２サービスプリミティブのセマンティックス
プリミティブのパラメータは次の通りである：
MIH_Net_HO_Commit.response (
DestinationIdentifier,
LinkActionRespList,
Status
)

７．４．２１．４．２サービスプリミティブのセマンティックス
プリミティブのパラメータは次の通りである：
MIH_Net_HO_Commit.confirm (
SourceIdentifier,
HandoverResultParameterList,
Status
)

７．４．２２．１．２サービスプリミティブのセマンティックス
プリミティブのパラメータは次の通りである：
MIH_MN_HO_Commit.request (
DestinationIdentifier,
CurrentLinkIdentifier,
TargetLinkIdentifier,
OldLinkActions
)

７．４．２２．２．２サービスプリミティブのセマンティックス
プリミティブのパラメータは次の通りである：
MIH_MN_HO_Commit.indication (
SourceIdentifier,
CurrentLinkIdentifier,
TargetLinkIdentifier,
OldLinkActions
)

７．４．２２．３．２サービスプリミティブのセマンティックス
プリミティブのパラメータは次の通りである：
MIH_MN_HO_Commit.response (
DestinationIdentifier,
CurrentLinkIdentifier,
Status
)

７．４．２２．４．２サービスプリミティブのセマンティックス
プリミティブのパラメータは次の通りである：
MIH_MN_HO_Commit.confirm (
SourceIdentifier,
CurrentLinkIdentifier,
Status
)

プリミティブのパラメータは次の通りである：
MIH_MN_HO_Complete.request (
DestinationIdentifier,
LinkIdentifier,
HandoverResult
)

７．４．２３．２．２サービスプリミティブのセマンティックス
プリミティブのパラメータは次の通りである：
MIH_MN_HO_Complete.indication (
SourceIdentifier,
LinkIdentifier,
HandoverResult
)

７．４．２３．３．２サービスプリミティブのセマンティックス
プリミティブのパラメータは次の通りである：
MIH_MN_HO_Complete.response (
DestinationIdentifier,
CurrentLinkIdentifier,
Status
)

７．４．２３．４．２サービスプリミティブのセマンティックス
プリミティブのパラメータは次の通りである：
MIH_MN_HO_Complete.confirm (
SourceIdentifier,
CurrentLinkIdentifier,
Status
)

７．４．２４．１．２サービスプリミティブのセマンティックス
プリミティブのパラメータは次の通りである：
MIH_N2N_HO_Complete.request (
DestinationIdentifier,
CurrentLinkIdentifier,
HandoverResult
)

７．４．２４．２．２サービスプリミティブのセマンティックス
プリミティブのパラメータは次の通りである：
MIH_N2N_HO_Complete.indication(
SourceIdentifier,
CurrentLinkIdentifier,
HandoverResult
)

７．４．２４．３．２サービスプリミティブのセマンティックス
プリミティブのパラメータは次の通りである：
MIH_N2N_HO_Complete.response (
DestinationIdentifier,
CurrentLinkIdentifier,
ResourceStatus,
Status
)

７．４．２４．４．２サービスプリミティブのセマンティックス
プリミティブのパラメータは次の通りである：
MIH_N2N_HO_Complete.confirm (
SourceIdentifier,
CurrentLinkIdentifier,
ResourceStatus,
Status
)

７．４．２５．１．２サービスプリミティブのセマンティックス
プリミティブのパラメータは次の通りである：
MIH_Get_Information.request (
DestinationIdentifier,
InfoQueryBinaryDataList,
InfoQueryRDFDataList,
InfoQueryRDFSchemaURL,
InfoQueryRDFSchemaList,
MaxResponseSize
)

７．４．２５．２．２サービスプリミティブのセマンティックス
プリミティブのパラメータは次の通りである：
MIH_Get_Information.indication (
SourceIdentifier,
InfoQueryBinaryDataList,
InfoQueryRDFDataList,
InfoQueryRDFSchemaURL,
InfoQueryRDFSchemaList,
MaxResponseSize
)

７．４．２５．３．２サービスプリミティブのセマンティックス
プリミティブのパラメータは次の通りである：
MIH_Get_Information.response (
DestinationIdentifier,
InfoRespBinaryDataList,
InfoRespRDFDataList,
InfoRespRDFSchemaURL,
InfoRespRDFSchemaList,
Status
)

７．４．２５．３．２サービスプリミティブのセマンティックス
プリミティブのパラメータは次の通りである：
MIH_Get_Information.confirm (
SourceIdentifier,
InfoRespBinaryDataList,
InfoRespRDFDataList,
InfoRespRDFSchemaURL,
InfoRespRDFSchemaList,
Status
)

７．６．１．１．２セマンティックス
プリミティブは次のようにパラメータを与えるものとする：
MIH_TP_Connect.request (
TransportType,
SourceAddress,
DestinationAddress
)

７．６．１．２．２セマンティックス
プリミティブは次のようにパラメータを与えるものとする：
MIH_TP_Connect.indication (
TransportType,
SourceAddress,
DestinationAddress
)

７．６．１．３．２セマンティックス
プリミティブは次のようにパラメータを与えるものとする：
MIH_TP_Connect.response (
TransportType,
SourceAddress,
DestinationAddress,
Status
)

７．６．１．４．２セマンティックス
プリミティブは次のようにパラメータを与えるものとする：
MIH_TP_Connect.confirm (
TransportType,
SourceAddress,
DestinationAddress,
Status
)

７．６．２．１．２セマンティックス
プリミティブは次のようにパラメータを与えるものとする：
MIH_TP_Disconnect.request (
TransportType,
SourceAddress,
DestinationAddress
)

７．６．２．２．２セマンティックス
プリミティブは次のようにパラメータを与えるものとする：
MIH_TP_Disconnect.indication (
TransportType,
SourceAddress,
DestinationAddress
)

７．６．３．１．２セマンティックス
プリミティブは次のようにパラメータを与えるものとする：
MIH_TP_Reset.request (
TransportType,
SourceAddress,
DestinationAddress
)

７．６．３．２．２セマンティックス
プリミティブは次のようにパラメータを与えるものとする：
MIH_TP_Reset.indication (
TransportType,
SourceAddress,
DestinationAddress
)

７．６．３．３．２セマンティックス
プリミティブは次のようにパラメータを与えるものとする：
MIH_TP_Reset.response (
TransportType,
SourceAddress,
DestinationAddress,
Status
)

７．６．３．４．２セマンティックス
プリミティブは次のようにパラメータを与えるものとする：
MIH_TP_Reset.confirm (
TransportType,
SourceAddress,
DestinationAddress,
Status
)

７．６．４．１．２セマンティックス
プリミティブは次のようにパラメータを与えるものとする：
プリミティブのパラメータは次の通りである：
MIH_TP_Data.request (
TransportType,
SourceAddress,
DestinationAddress,
ReliableDeliveryFlag,
MIHProtocolPDU
)

７．６．４．２．２セマンティックス
プリミティブは次のようにパラメータを与えるものとする：
プリミティブのパラメータは次の通りである：
MIH_TP_Data.indication (
TransportType,
SourceAddress,
DestinationAddress,
ReliableDeliveryFlag,
MIHProtocolPDU
)

７．６．４．３．２セマンティックス
プリミティブは次のようにパラメータを与えるものとする：
MIH_TP_Data.response (
TransportType,
SourceAddress,
DestinationAddress,
Status
)

７．６．４．４．２セマンティックス
プリミティブは次のようにパラメータを与えるものとする：
MIH_TP_Data.confirm (
TransportType,
SourceAddress,
DestinationAddress,
Status
)

７．７．１．２．２セマンティックス
プリミティブのパラメータは次の通りである：
MIH_NMS_Initialize.confirm (
Status
)

７．７．２．１．２セマンティックス
プリミティブのパラメータは次の通りである：
プリミティブのパラメータは次の通りである：
MIH_NMS_Get_State.request (
StateInformationRequestList
)

７．７．２．２．２セマンティックス
プリミティブのパラメータは次の通りである：
MIH_NMS_Get_State.confirm (
StateInformationResponseList,
Status
)

７．７．３．２．２セマンティックス
プリミティブのパラメータは次の通りである：
MIH_NMS_Get_State.confirm (
StateInformationResponseList,
Status
)

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

Claims

第１のアクセスネットワークに接続された移動ノードの、第２の異種のアクセスネットワークへのメディア独立ハンドオーバのための符号化スキームを使用する方法であって、
前記第１のアクセスネットワークに接続された前記移動ノードと、前記第２の異種のアクセスネットワークにおけるネットワークノード内のメディア独立ハンドオーバエンティティとの間でメディア独立ハンドオーバプロトコルメッセージを伝送することを備え、
前記第１のアクセスネットワークはＩ．Ｅ．Ｅ．Ｅ．８０２ネットワークおよびセルラーネットワークのいずれか一方であって、前記第２の異種のアクセスネットワークはＩ．Ｅ．Ｅ．Ｅ．８０２ネットワークおよびセルラーネットワークのいずれか他方であり、
前記メディア独立ハンドオーバプロトコルメッセージは、少なくともあるデータ型のためのフィールドを持ち、該フィールドは、前記フィールド内に長さ値を含めることなく符号化ルールに基づいてデータの終端を決定するのに必要な情報だけを含む、方法。
前記データ型に基づき前記符号化ルールを用いて長さを決定することをさらに含み、長さを決定するために前記データ型が定義される請求項１に記載の方法。
前記データ型は８０２．２１メディア独立ハンドオーバを実行するノード間のメッセージ交換時に搬送される請求項１に記載の方法。
前記データ型は８０２．２１メディア独立ハンドオーバ情報要素（ＩＥ）を定義するために使用される請求項３に記載の方法。
前記ＩＥを移動ノードから送信することを更に含む請求項４に記載の方法。
前記データ型はＴＬＶを定義するために使用される請求項３に記載の方法。
前記ＴＬＶを移動ノードから送信することを更に含む請求項４に記載の方法。
前記データ型はプリミティブを定義するために使用される請求項３に記載の方法。
前記プリミティブは同じノード内のプロトコルスタックの異なる層間で伝送される請求項８に記載の方法。
前記データ型がＩ．Ｅ．Ｅ．Ｅ．８０２．２１メディア独立ハンドオーバ（ＭＩＨ）プロトコルメッセージで搬送され、２進符号化ルールを使用することを更に含む請求項１に記載の方法。
ＳＥＱＵＥＮＣＥデータ型に関して下記の２進符号化ルール：「各データ型が前記データ型についての前記符号化ルールを使用して符号化される場合にＤＡＴＡＴＹＰＥ１、ＤＡＴＡＴＹＰＥ２、［・・・］は出現順に符号化される」という符号化ルールを使用することを更に含む請求項１０に記載の方法。
ＣＨＯＩＣＥデータ型に関して下記の２進符号化ルール：「１オクテット・セレクタフィールドに可変長Ｖａｌｕｅフィールドが続き、セレクタ値はデータ型を決定し、もしＳｅｌｅｃｔｏｒ（セレクタ）＝＝ｉであればデータ型ＤＡＴＡＴＹＰＥ１、ＤＡＴＡＴＹＰＥ２、［、・・・］のリスト内の第（ｉ＋１）番目のデータ型が選択され、前記Ｖａｌｕｅフィールドは前記選択されたデータ型についての符号化ルールを使用して符号化される」という符号化ルールを使用することを更に含む請求項１０に記載の方法。
ＢＩＴＭＡＰデータ型に関して下記の２進符号化ルール：「ＢＩＴＭＡＰ（Ｎ）値［Ｎ＝８＊ｉ，ｉ＝１，２，・・・］の各ビットが重み順にＮ／８オクテット値として符号化される」というルールを使用することを更に含む請求項１０に記載の方法。
ＩＮＴＥＧＥＲデータ型に関して下記の２進符号化ルール：「ＩＮＴＥＧＥＲ（Ｎ）値［Ｎ＝１，２，・・・］の各オクテットがネットワークバイト順にＮオクテットフィールドに符号化される」というルールを使用することを更に含む請求項１０に記載の方法。
ＣＨＡＲデータ型に関して下記の２進符号化ルール：「各文字の各ビットが重み順に符号化される場合に各文字が出現順に符号化される」というルールを使用することを更に含む請求項１０に記載の方法。
ＵＮＳＩＧＮＥＤＩＮＴＥＧＥＲデータ型に関して下記の２進符号化ルール：「ＵＮＳＩＧＮＥＤ＿ＩＮＴ（Ｎ）値［Ｎ＝１，２，・・・］の各オクテットがネットワークバイト順にＮオクテットフィールドに符号化される」というルールを使用することを更に含む請求項１０に記載の方法。
ＬＩＳＴ（ＤＡＴＡＴＹＰＥ）データ型に関して下記の符号化：「可変長Ｌｅｎｇｔｈフィールドに可変長Ｖａｌｕｅフィールドが続き、ここで前記Ｌｅｎｇｔｈフィールド値は前記リスト内のリスト要素の数に関連している」という符号化を使用することを更に含む請求項１０に記載の方法。
Ｌｅｎｇｔｈフィールドのフォーマットが次のように：すなわち、
もし前記Ｖａｌｕｅフィールド内のリスト要素の実際の数が１２７以下であれば：・前記Ｌｅｎｇｔｈフィールドは１オクテットを占めるものとし、
・前記ＬｅｎｇｔｈフィールドのＭＢＳは０にセットされるものとし、
・前記Ｌｅｎｇｔｈフィールドの他の７ビットは前記Ｖａｌｕｅフィールドの実際の長さをリスト要素の数で示すために使用されるものとし、また
もし前記Ｖａｌｕｅフィールドのリスト要素の数がちょうど１２８であれば：・前記Ｌｅｎｇｔｈフィールドは１オクテットを占めるものとし、
・前記ＬｅｎｇｔｈフィールドのＭＢＳは値「１」にセットされるものとし、・前記Ｌｅｎｇｔｈフィールドの他の７ビットはすべて値「０」にセットされるものとし、そして
もし前記Ｖａｌｕｅフィールドのリスト要素の数が１２７より大きければ：
・前記Ｌｅｎｇｔｈフィールドは１オクテットより多くを占めるものとし、
・前記Ｌｅｎｇｔｈフィールドの第１のオクテットのＭＢＳは１にセットされるものとし、
・前記Ｌｅｎｇｔｈフィールドの第１のオクテットの他の７ビットは前記Ｌｅｎｇｔｈフィールドの更なるオクテットの数を示すために使用されるものとし、
・前記Ｌｅｎｇｔｈフィールドの残りオクテットの値は１２８に加算されるとき、Ｖａｌｕｅフィールドの実際の長さをリスト要素の数で示すために使用されるものとする、というように定義されることを更に含む請求項１７に記載の方法。
ＴＬＶ内においてデータがＴＬＶスタイルの符号化を使用せずに符号化されるＴＬＶをメッセージに搬送させることを備える方法。
トップレベルでは順序は任意であり得るが、トップレベルの内側では順序付け制限が課せられる請求項１０に記載の方法。
第１のアクセスネットワークに接続された移動ノードの、第２の異種のアクセスネットワークへのメディア独立ハンドオーバのための符号化スキームを使用する方法であって、
前記第１のアクセスネットワークに接続された前記移動ノードと、前記第２の異種のアクセスネットワークにおけるネットワークノード内のメディア独立ハンドオーバエンティティとの間でＩ．Ｅ．Ｅ．Ｅ．８０２．２１メディア独立ハンドオーバプロトコルメッセージを伝送することを備え、
前記第１のアクセスネットワークはＩ．Ｅ．Ｅ．Ｅ．８０２ネットワークおよびセルラーネットワークのいずれか一方であって、前記第２の異種のアクセスネットワークはＩ．Ｅ．Ｅ．Ｅ．８０２ネットワークおよびセルラーネットワークのいずれか他方であり、
前記Ｉ．Ｅ．Ｅ．Ｅ．８０２．２１メディア独立ハンドオーバプロトコルメッセージは、Ｔｙｐｅ、ＬｅｎｇｔｈおよびＶａｌｕｅのうちの少なくとも１つに関する値を持たないデータ型のフィールドを有し、前記Ｉ．Ｅ．Ｅ．Ｅ．８０２．２１メッセージ内にＴＬＶデータ構造を符号化する方法。