JP5038406B2 - 効率的なメディア独立ハンドオーバープロトコルオペレーションの拡張 - Google Patents

Description

本発明は、無線通信に関する。さらに詳細には、本発明は、メディア独立ハンドオーバー（ＭＩＨ）メッセージを無線で送信および受信するために使用されるメディア独立ハンドオーバー機能（ＭＩＨＦ）フレームフォーマットに関する。

図１は、ＩＥＥＥ８０２．２１標準によって規定されている、タイプフィールド１０５、長さフィールド１１０、および値フィールド１１５を含むＩＥ１００の現在のタイプ−長さ−値（ＴＬＶ）表現を示している。代替として、ＴＬＶフィールドは、ヘッダのような他のフィールド、あるいはコマンドまたはイベントのようなＭＩＨサービスデータを表すこともある。

ＩＥＥＥ８０２．２１標準において、タイプフィールド１０５はＩＥのタイプを示し、定義された識別（ＩＤ）値を有する。値フィールド１１５は、ＩＥ１００のペイロードまたは値を含む。第１のシナリオにおいて、値フィールド１１５によって占有されるオクテットの数が１２７以下である場合、長さフィールド１１０のサイズは常に１オクテットであり、オクテットの最上位ビット（ＭＳＢ）１２０は値「０」に設定される。第２のシナリオにおいて、値フィールド１１５によって占有されるオクテットの数が１２７よりも大きい場合、長さフィールド１１０のサイズは少なくとも「ｘ」オクテットであり、ここで「ｘ」は２以上である。この場合、長さフィールド１１０の第１のオクテットのＭＳＢ１２５は値「１」に設定され、第１のオクテットの残りの７ビットは、第１のオクテットに付加される追加のオクテットの数を示す。長さフィールド１１０の第２のオクテットによって表される数は、値フィールド１１５の合計サイズを示す。

ＩＥＥＥ８０２．２１に規定されている長さフィールドの説明には問題がある。具体的には、長さフィールドの解釈の第２のシナリオにおいて、ＩＥＥＥ８０２．２１標準は、長さフィールドの第２のオクテットによって表される数が値フィールドの合計サイズを示すことを規定している。第２のオクテットによって表される数は値フィールドの長さを示していないので、これは不正確である。代わりに、第２のオクテットから始まる追加の付加されたオクテットによって表される数は、値フィールドの長さを示す。加えて、追加のオクテットの値は、ビットとは対照的に、オクテットで値フィールドの長さを表すべきである。したがって、長さフィールドは効率的に使用されていない。

図２は、ＩＥＥＥ８０２．２１標準によって規定されているＭＩＨＦフレーム２００の現在のフォーマットを示している。ＩＥＥＥ８０２．２１標準は、ＭＩＨＦフレーム２００がＭＩＨＦ固定ヘッダ２０５およびＭＩＨＦ可変ロード２１０で構成されることを規定している。ＭＩＨＦ可変ロード２１０は、ＭＩＨＦ可変ヘッダ２１５およびＭＩＨＦペイロード２２０で構成される。

ＩＥＥＥ８０２．２１標準は、ＭＩＨＦ固定ヘッダ２０５が必須であることを規定している。以下の表１は、ＩＥＥＥ８０２．２１によって規定されているＭＩＨＦ固定ヘッダ２０５の内容を示している。

ＩＥＥＥ８０２．２１で現在規定されているように、ＭＩＨＦ可変ヘッダ２１５は、埋め込まれているペイロードの分析および調整に役立つ追加の識別子を含む。これらの識別子はまた、ＴＬＶフォーマットでも表される。ＩＥＥＥ８０２．２１で規定されているこれらの識別子の（ＴＬＶの）タイプフィールドのいくつかの可能な値は、（リクエストとレスポンスをマッチさせる）トランザクションＩＤ、（通信ピアを識別する）ＭＩＨ機能ＩＤ／セッションＩＤ、および（受信したメッセージのタイムスタンプを識別する）同期情報を含む。

ＭＩＨＦペイロードフィールド２２０は、メッセージのペイロードとして機能するサービス固有のＴＬＶを含む。図２（ＭＩＨＦフレームフォーマット）のＭＩＨＦ固定ヘッダ２０５と表１（ＭＩＨＦ固定ヘッダの説明）のそのフィールドの説明を比較すると、表１に示される「Ｎｕｍｂｅｒ ｏｆ Ａｄｄｉｔｉｏｎａｌ Ｈｅａｄｅｒ Ｉｄｅｎｔｉｆｉｅｒｓ（追加ヘッダ識別子の数）」フィールドが、図２のＭＩＨＦフレーム２００に存在しないことに留意されたい。

ＭＩＨＦ固定ヘッダ２０５の可変ロード長さフィールド２２５は、１６ビットによって表される。（ＩＥＥＥ８０２．２１に規定されている）可変ロード長さフィールド２２５は、ＭＩＨＦフレーム２００に埋め込まれている可変ロードの合計長さがＭＩＨＦ可変ヘッダ２１５の長さとＭＩＨＦペイロード２２０の長さの合計であることを示している。ＭＩＨＦ固定ヘッダ２０５の長さは含まれない。

ＭＩＨＦ可変ヘッダ２１０の長さは計算することができ、その表現に使用される１６ビットは節減すべきであるため、可変ロード長さフィールド２２５は必要ではない。

ＭＩＨＦ固定ヘッダ２０５は、肯定応答をリクエストする肯定応答リクエスト（ＡＣＫ−ｒｅｑ）フィールド２３０、およびメッセージの受信を確認する肯定応答レスポンス（ＡＣＫ−ｒｓｐ）フィールド２３５を定義する。ＩＥＥＥ８０２．２１に規定されているように、肯定応答メッセージは、添付される（「ピギーバックされる」）か、またはレスポンスパケットで単独で送られる。しかし、ＩＥＥＥ８０２．２１標準は、レスポンスフレームが何らペイロードを持たず、肯定応答としてのみ機能することを示す方法を規定していない。したがって、ピアは、ＡＣＫ−ｒｓｐビットを「１」に設定されたメッセージを受信した場合、ペイロードがあるかどうかを確認する必要があるであろう。ペイロードがない場合、ＭＩＨＦ可変ロードフィールド２１０は、受信機によって有効ビットとして解釈される可能性のあるダミービットを含むことになるので、これは効率的ではない。したがって、純粋な肯定応答メッセージを識別するフィールドを有することが必要であり、ＭＩＨＦフレーム２００はＭＩＨＦ可変ロードフィールド２１０を有するべきではない。現在、そのようなフィールドは定義されていない。

ＩＥＥＥ８０２．２１標準は、ＭＩＨＦ ＩＤ、セッションＩＤ、およびトランザクションＩＤ２４０を含む３つのＭＩＨＦプロトコル識別子を定義する。ＭＩＨＦ ＩＤは、ＭＩＨＦフレーム２００が由来する送り側を識別する。セッションＩＤは、セッションの由来元によって生成された一意の識別子である。トランザクションＩＤ２４０は、リクエストとレスポンスをマッチさせるためにも、リクエスト、レスポンス、指示をＡＣＫにマッチさせるためにも使用される（上記の表１を参照）。

したがって、３つのＭＩＨＦプロトコル識別子のすべては（共に）ＭＩＨＦフレーム（またはメッセージ）を一意に識別する。しかし、トランザクションＩＤ２４０のみがＭＩＨＦ固定ヘッダ２０５に示されているが、ＭＩＨＦ ＩＤ、セッションＩＤ、およびトランザクションＩＤ２４０は、ＴＬＶフォーマットで表されることになっており、（ＭＩＨＦ可変ロード２１０の一部である）ＭＩＨＦ可変ヘッダ２１５に存するように規定されている。問題は、ＴＬＶを使用してＭＩＨＦ ＩＤおよびセッションＩＤの各々を表すことにより、ビットを浪費し、ＭＩＨＦフレーム２００のデコーディングを複雑にすることになることである。加えて、トランザクションＩＤ２４０はすでに、ＭＩＨＦ固定ヘッダ２０５内の固定フィールドを付与されており、ＭＩＨＦ可変ヘッダ２１５においてＴＬＶフォーマットでこれを再表現する必要はない。

本発明は、ＩＥＥＥ８０２．２１標準の既存のＭＩＨＦフレームフォーマットに対する一組の変更を含む。本発明は、ＩＥＥＥ８０２．２１標準によって定義されている既存のＭＩＨＦフレームフォーマットを変更する。１つの実施形態において、ＭＩＨＦフレームの可変ロードは、ＭＩＨＦ ＩＤフィールドおよびセッションＩＤフィールドをＭＩＨＦ固定ヘッダ中の固定フィールドとして定義することにより、ＭＩＨＦ可変ヘッダを取り除くように変更される。したがって、ＭＩＨＦ可変ロードは、ＭＩＨＦペイロードのみで構成される。別の実施形態において、ＩＥ、コマンド、またはヘッダのようなフィールドは、タイプフィールド、長さフィールド、および値フィールド（ＴＬＶ）により表される。値フィールドの長さは正確に１２８オクテットであり、長さフィールドは１オクテットしか占有しない。

本発明のさらに詳細な理解は、例として示され、添付の図面と併せて理解される、以下の好ましい実施形態の説明から得ることができる。

ＩＥＥＥ８０２．２１標準によって規定されているＩＥの現在のＴＬＶフォーマット表現を示す図である。 現在のＩＥＥＥ８０２．２１のＭＩＨＦフレームフォーマットを示す図である。 ＩＥＥＥ８０２．２１によって規定されている現在のＴＬＶフォーマットを示す図である。 １２８オクテットよりも大きい長さを有する値フィールドを持つＴＬＶフレームを示す図である。 本発明による正確に１２８オクテットの長さを有する値フィールドを持つＴＬＶフレームを示す図である。 本発明による構成されたＭＩＨＦフレームフォーマットを示す図である。 本発明によるＩＥをリクエストするための例示的なＭＩＨＦリクエストフレームを示す図である。 本発明によるＭＩＨＦリクエストフレームに応答してＩＥを提供する例示的なＭＩＨＦレスポンスフレームを示す図である。 本発明によるオペレータ識別子ＩＥの例示的なＴＬＶ表現を示す図である。 本発明による肯定応答メッセージを持つＭＩＨＦフレームを示す図である。 本発明による構成された通信システムを示す図である。

これ以降、用語「無線送信／受信ユニット（ＷＴＲＵ）」はユーザ機器（ＵＥ）、移動局、固定または移動加入者ユニット、ページャー、携帯電話、パーソナルデジタル端末（ＰＤＡ）、コンピュータ、または無線環境において動作することのできる他の任意のタイプのユーザデバイスを含むが、これらに限定されない。これ以降、用語「基地局」はＮｏｄｅ Ｂ、サイトコントローラ、アクセスポイント（ＡＰ）、または無線環境において動作することのできる他の任意のタイプのインターフェイス接続デバイスを含むが、これらに限定されない。

図３は、図１に示されるＩＥ１００のフォーマットと同様のＩＥＥＥ８０２．２１で定義されているＩＥの現在のＴＬＶフォーマット表現を示している。本発明は、値フィールドの長さが１２７オクテットよりも大きいとき、ＴＬＶの長さフィールドの解釈に適用可能である。

図４によって詳細に示されるように、値フィールドによって占有されるオクテットの数が１２８オクテットよりも大きい場合、長さフィールドの最初のオクテットのＭＳＢは「１」に設定される。７ビットの残りの部分は、（長さフィールドの）最初のオクテットにさらに付加される（新しい長さフィールドの）オクテットの数を示す。それで、値フィールドの長さは、１２８に、第２のオクテットから始まるその他の付加された長さフィールドのオクテットによって表される数値を加えたものである。

本発明は、図５に示されるように、値フィールドの長さが正確に１２８オクテットであるときに適用する第３のケースを定義する。値フィールドの長さが正確に１２８オクテットである場合、長さフィールドのＭＳＢは「１」に設定され、残りの７ビットは「０」に設定される。現在のＩＥＥＥ８０２．２１標準によれば、図１に示されるように、長さが１２７オクテットよりも大きい場合、値フィールドの長さを完全に示すために予備のオクテット「ｘ」が追加されなければならない。たとえ長さが正確に１２８オクテットであっても、現在のＩＥＥＥ８０２．２１標準は、１２８オクテットの正確な値を満たすために予備オクテットを要する。したがって、予備オクテットの無駄がある。本発明は、値フィールドの長さが正確に１２８オクテットである場合、値フィールドの長さをオクテットで示す追加のオクテットを要しない。

図６は、本発明に従って構成されたＭＩＨＦフレームフォーマット６００を示している。ＭＩＨＦフレームフォーマット６００は、ＭＩＨＦ固定ヘッダ６０５およびＭＩＨＦ可変ロード６１０を含む。しかし、（現在のＩＥＥＥ８０２．２１ＭＩＨＦフレームのＭＩＨＦ可変ロードの一部である）ＭＩＨＦ可変ヘッダは、除去されている。これは、以前ＴＬＶで表されており、ＭＩＨＦ可変ヘッダに含まれていたＭＩＨＦ ＩＤおよびセッションＩＤが、いまは本発明によりＭＩＨＦ固定ヘッダ６０５の固定フィールドとして定義されているためである。したがって、ＭＩＨＦ可変ロード６１０は、ＭＩＨＦペイロードのみで構成される。

図６に示されるＭＩＨＦ固定ヘッダ６０５のフィールド名は、本発明に従って定義される新しいフィールド、または変更された古いフィールドのいずれかである。

予約フィールド６１５は、変更されている。これは当初、１０ビットにより表されていたが、いまは９ビットにより表されるべきである。その他のビットは、本発明に従って「フラグ」フィールド６２０を定義するために使用される。このフィールドをどのように使用することができるかについて２つのシナリオがある。

第１のシナリオにおいて、（ＭＩＨＦフレームの）ＭＩＨＦ可変ペイロードフィールドにペイロードがあるとき、フラグフィールド６２０は「１」に設定される。このシナリオにおいて、ＭＩＨＦフレームの合計長さは、｛［ＭＩＨＦ固定ヘッダの長さ（常に１５オクテット）］+［ＭＩＨＦ可変ロードの長さ］｝オクテット＝｛１５＋［タイプフィールドの長さ（常に４オクテット）］＋［長さフィールドを表すために使用されるオクテットの数］＋［長さフィールドによって示される値フィールドの長さ］｝オクテットとなる。これは、以前受信したメッセージの肯定応答を添付（「ピギーバック」）するために使用することができる。したがって、ペイロードも含むフレームに「ピギーバックされた」肯定応答があるという指示は、ＡＣＫ−ｒｓｐおよびフラグビットが「１」に設定されているときに生じる。

第２のシナリオにおいて、（ＭＩＨＦフレームの）ＭＩＨＦ可変ペイロードフィールドにペイロードがないとき、フラグフィールド６２０は「０」に設定される。この場合、ＭＩＨＦフレームの合計長さは、［ＭＩＨＦ固定ヘッダの長さ（常に１５オクテット）］となる。これは、ピアが肯定応答メッセージのみを含むＭＩＨＦフレームを送信する必要がある場合に特に有用である。

現在のＩＥＥＥ８０２．２１標準は、単独の肯定応答メッセージを区別していない。代わりに、現在のＩＥＥＥ８０２．２１標準は常に、添付された（「ピギーバックされた」）肯定応答メッセージングを使用する。したがって、ピアが、肯定応答メッセージのみを含むＭＩＨＦフレームを送る場合、ＡＣＫ−ｒｓｐは「１」に設定され、フラグビットは「０」に設定される。このシナリオにおいて、ＭＩＨＦ可変ロードはデータを搬送せず、したがって存在しない。そのため、ＭＩＨＦフレームはＭＩＨＦ固定ヘッダのみを含み、受信機は何らかのペイロードについて確認しようと試みない。

ＭＩＨＦ ＩＤフィールド６２５は、ＭＩＨＦフレームが由来する送り側のＭＩＨＦ ＩＤという、ＩＥＥＥ８０２．２１ですでに規定されているのと同じ役割を果たす。しかし、このフィールドは、ＩＥＥＥ８０２．２１の現在のＭＩＨＦ固定ヘッダには含まれていない。このヘッダにこのフィールドを有することの意義は、送信されるあらゆるメッセージの一意の識別に常に必要とされるであろうことである。したがって、ＴＬＶフォーマットで表される場合、これは他の目的のために使用することができる予備のビットを占有することになる。加えて、そのＴＬＶ表現は、メッセージのデコーディング中にさらに多くの手間とオーバーヘッドをもたらすことになろう。

セッションＩＤ６３０は、セッションの由来元によって生成された一意の識別子という、ＩＥＥＥ８０２．２１ですでに規定されているのと同じ機能を有する。しかし、メッセージの送り側を一意に定義するために、セッションＩＤが必要となる。同様に、このＩＤをＭＩＨＦ固定ヘッダに有することにより、ＴＬＶフォーマットで表現するのとは対照的に、ビットを節減し、メッセージのデコーディングを増進する。

可変ロード長さフィールドは、ＭＩＨＦ固定ヘッダから除去される。このフィールドの役割は、ＭＩＨＦ可変ペイロードフィールドの長さを示すことであり、１６ビットで構成されていた。しかし、たとえ可変ロード長さが存在しない場合であっても、ＭＩＨＦ可変ペイロードフィールドの長さは依然として次のように計算することができる｛［タイプフィールドの長さ（常に４オクテット）］+［長さフィールドを表すために使用されるオクテットの数］＋［長さフィールドによって示される値フィールドの長さ］｝オクテット。したがって、ＭＩＨＦ可変ペイロードの長さのような情報を失うことなく、１６ビットを節減することができる。ＭＩＨＦ固定ヘッダの残りのフィールドは、上記の表１により説明される。

ＭＩＨＦフレームフォーマットのＭＩＨＦ可変ロード部分は、サービス固有ＴＬＶのみを含む。これはもはや、ＭＩＨＦ可変ヘッダを含まない。以下は、本発明のＭＩＨＦフレームの例示的な実装形態である。

特定のＩＥを取り出すために、たとえば、クライアントは、情報リクエスト（すなわち、クエリ）をＭＩＨサービスポイント（ＰｏＳ）に送る。情報リクエストは、ＩＥに対するクエリを含む。ＭＩＨ ＰｏＳは、情報リクエストのレスポンスを含む情報レスポンスをクライアントに送り返す。

図７は、ＩＥをリクエストするための例示的なＭＩＨＦリクエストフレーム７００を示している。ＩＥＥＥ８０２．２１対応のエンティティは、（たとえば、ＴＹＰＥ＿ＩＥ＿ＬＩＳＴ＿ＯＦ＿ＯＰＥＲＡＴＯＲＳ＿ＲＥＱＵＥＳＴを使用して）オペレータのリストのような特定のＩＥをリクエストする。ＭＩＨＦリクエストフレーム７００は、ＭＩＨＦ固定ヘッダ７０５およびＭＩＨＦ可変ロード７１０を含む。

図７に示されるＭＩＨＦリクエストフレーム７００のＭＩＨＦ固定ヘッダ７０５のフィールドにより含まれている「ｘｘｘ」は、単に、リクエストフレーム７００の実施形態に影響を及ぼすことなくビットが任意の値を有することができることを暗示している。ＭＩＨメッセージＩＤフィールド７１５は、サービスＩＤフィールド７２０、オペレーションコード（ｏｐｃｏｄｅ）フィールド７２５、およびアクションＩＤフィールド７３０の組合せである。

サービスＩＤフィールド７２０は、異なるＭＩＨサービスを識別し、以下の値を有する。
１＝Ｓｙｓｔｅｍ Ｍａｎａｇｅｍｅｎｔ（システム管理）
２＝Ｅｖｅｎｔ Ｓｅｒｖｉｃｅ（イベントサービス）
３＝Ｃｏｍｍａｎｄ Ｓｅｒｖｉｃｅ（コマンドサービス）
４＝Ｉｎｆｏｒｍａｔｉｏｎ Ｓｅｒｖｉｃｅ（情報サービス）

図７に示されているように、サービスＩＤフィールド７２０は、バイナリビット「０１００」で表される４の１０進値を有する。この値は、ＭＩＨＦ可変ロード７１０で搬送されるペイロードが情報サービスに関連することを示す。

オペレーションコード（ｏｐｃｏｄｅ）フィールド７２５は、サービスＩＤ７２０に関して行われるべきオペレーションのタイプを示し、以下の値を有する。
１＝Ｒｅｑｕｅｓｔ（リクエスト）
２＝Ｒｅｓｐｏｎｄ（レスポンス）
３＝Ｉｎｄｉｃａｔｉｏｎ（指示）

図示されているように、オペレーションコード（ｏｐｃｏｄｅ）フィールド７２５は、１の値によって表され、ペイロードが問題となっているサービスＩＤのリクエストであることを示す。

アクションＩＤフィールド７３０は、サービスＩＤフィールド７２０に関して取られるべきアクションを示す。

図示されているフラグフィールド７３５は、ＭＩＨＦ可変ロードがデータを含むことを示す「１」に設定される。

ＭＩＨＦフレーム７００のリクエストメッセージ部分のＭＩＨＦ可変ロード７１０は、タイプフィールド７４０、長さフィールド７４５、および値フィールド７５０によって定義されたＩＥリクエストのＴＬＶ表現を含む。

タイプフィールド７４０は、ＩＥのタイプの値を含む。図７に示される例において、タイプフィールド７４０は、ＩＥＥＥ８０２．２１で規定され、「０×１００００００３」（４オクテット）の値を持つ１６進法で表される。これは、問題となっているＩＥのタイプが、特定のリンクタイプのオペレータのリストであることを意味し、これはＴＬＶの値フィールドで指定される（「ｘｘｘ．．．」）。

長さフィールド７４５は、そのＭＳＢを値フィールドの長さが１２８オクテットよりも小さいことを意味する「０」に設定されている。値フィールドの正確な長さは、４の１０進値を有する残りの７ビットによって表される。そのため、値フィールドの長さは４オクテットである。

値フィールド７５０は、オペレータのリストを取得することが要求される特定のリンクタイプを含む。値フィールド７５０は、問題となっているＩＥに応じて、固定または可変の長さにすることができる。この例の場合、このフィールドの長さが４オクテットに固定されることがＩＥＥＥ８０２．２１で規定されている。これは、任意の定義された値を表すことができるので、「ｘｘｘ．．．」によって表される。

図８は、ＭＩＨＦリクエストフレーム７００に応答してＩＥを提供する例示的なＭＩＨＦレスポンスフレーム８００を示している。リクエストメッセージの受信機がそれに応じてＭＩＨＦフレームをデコードし、（たとえば、ＴＹＰＥ＿ＩＥ＿ＬＩＳＴ＿ＯＦ＿ＯＰＥＲＡＴＯＲＳ＿ＲＥＳＰＯＮＳＥを使用して）応答することが仮定される。ＭＩＨＦレスポンスフレーム８００は、ＭＩＨＦ固定ヘッダ８０５およびＭＩＨＦ可変ロード８１０を含む。ＭＩＨＦレスポンスフレーム８００は、（特定のリンクタイプの）オペレータＩＥのリストのリクエストに対するレスポンスを示す。

図８に示されるＭＩＨＦレスポンスフレーム８００のＭＩＨＦ固定ヘッダ８０５のフィールドにより含まれている「ｘｘｘ」は、単に、レスポンスフレーム８００の実装形態に影響を及ぼすことなくビットが任意の値を有することができることを暗示している。ＭＩＨメッセージＩＤフィールド８１５は、サービスＩＤフィールド８２０、オペレーションコード（ｏｐｃｏｄｅ）フィールド８２５、およびアクションＩＤフィールド８３０の組合せである。

ＡＣＫ−ｒｅｑフィールド８３５は、（ＩＥＥＥ８０２．２１で規定されているように）ピアがこのメッセージの受信を肯定応答すべきことを示す「１」に設定されたビットを有する。

フラグフィールド８４０は、ＭＩＨＦ可変ロードがデータを含むことを示す「１」に設定されたビットを有する。

サービスＩＤビット８２０は、ビットで表される４の１０進値を有する。この値は、ＭＩＨＦフレームで搬送されるペイロードが情報サービスに関連することを示す。

オペレーションコード（ｏｐｃｏｄｅ）フィールド８２５は、２の１０進値によって表されて、ペイロードが問題となっているサービスＩＤのレスポンスであることを示す。

アクションＩＤフィールド８３０は、サービスＩＤフィールド８２０に関して取られるべきアクションを示す。

レスポンスメッセージフィールドのＭＩＨＦ可変ロード８１０は、以下で説明される３つのフィールドを有する。

タイプフィールド８４５は、ＩＥのタイプの値を含む。この例において、ＩＥＥＥ８０２．２１で規定されているように、「０ｘ１００００００３」（４オクテット）の値を持つ１６進法で表される。これは、問題となっているＩＥのタイプが、（リクエストメッセージのＴＬＶの値フィールドで指定された）特定のリンクタイプのオペレータのリストであることを意味する。

長さフィールド８５０は、そのＭＳＢを値フィールドの長さが１２８オクテットよりも大きいことを意味する「１」に設定されている。このフィールドの第１のオクテットの残りの７ビットは、２つの長さフィールドのオクテットがさらに付加される（１６ビット）ことを示す。これらの１６ビットによって表される１０進値は４０３である。そのため、値フィールドの合計長さは１２８＋４０３＝５３１オクテットである。

値フィールド８５５は、ペイロードを含む。ＩＥＥＥ８０２．２１の仕様によれば、このフィールドは、２つの部分で構成される。すなわち、（特定のリンクタイプの）オペレータの数に続いてオペレータ識別子となる。

オペレータの数フィールド８６０は、ＩＥＥＥ８０２．２１によって規定されているように４オクテットによって表される。この例のために、問題となっているリンクタイプのオペレータの数は、２となるように選ばれる。この値は、図９に示されるＭＩＨＦ可変ロードの値フィールド９１５の最初の４つのオクテットとして示される。

オペレータ識別子は、ＴＬＶフォーマットで表される。各々は、最初に構築されてから、オペレータ識別子の数の後の値フィールドに追加される別個のＩＥとして取り扱われる。したがって、２つの独立したオペレータ識別子ＴＬＶ８６５および８７０が存在する。ＴＬＶ８６５および８７０は、構造は同様であるが、内容および長さは異なり得る。オペレータ名がまだ定義されていないので、これは仮定されていることに留意されたい。２つのＴＬＶ８６５および８７０は、（ＭＩＨＦ可変ロード８１０にある）値フィールド８５５のオペレータの数に付加される。各ＴＬＶ８６５および８７０は、タイプフィールドに同じ値を有するが、長さフィールドおよび値フィールドは異なり得る。したがって、付加されたＴＬＶ８６５および８７０のタイプフィールドが除去されるよう示唆される可能性があろう。したがって、レスポンスフレーム８００の値フィールド８５５は、このためオペレータの数の４オクテット、第１のオペレータ識別子ＴＬＶ８６５の長さフィールドに続いてその値フィールド、および第２のオペレータ識別子ＴＬＶ８７０の長さフィールドに続いて値フィールドを含むであろう。ときに付加されるべきＴＬＶが異なり、そのためそのタイプフィールドが要求されるので、すべてのＩＥリクエストまたはレスポンスについて、これを行うことができるわけではないことに留意されたい。

図９は、オペレータ識別子ＩＥ９００の例示的なＴＬＶ表現を示している。タイプフィールド９０５は、ＩＥのタイプの値を含む。この例において、ＩＥＥＥ８０２．２１で規定されているように、「０ｘ１００００００４」（４オクテット）の値を持つ１６進法で表される。これは、問題となっているＩＥのタイプがオペレータ識別子であることを意味する。長さフィールド９１０は、そのＭＳＢを値フィールド９１５の長さが１２８オクテットよりも大きいことを示す「１」に設定されている。長さフィールド９１０の第１のオクテットの残りの７ビットは、１つの長さフィールドのオクテットがさらに付加される（８ビット）ことを示す。これらの８ビットによって表される１０進値は１２６である。そのため、値フィールド９１５の合計長さは１２８＋１２６＝２５４オクテットである。

値フィールド９１５は、オペレータネームスペースフィールド９２０に続いてオペレータ名前フィールド９２５を含む。オペレータネームスペースフィールド９２０は、ＩＥＥＥ８０２．２１で規定されているように１オクテットの長さを有する。オペレータ名前フィールド９２５は、問題となっているオペレータの名前の値を含む。オペレータ名前フィールド９２５は、（ＩＥＥＥ８０２．２１標準によって規定されているように）長さが２５３オクテットを超えないものとする非ヌルの終端ストリングである。フィールド９２５は「ｘｘ．．．．ｘｘ」を含むように示されており、可能な値はＩＥＥＥ８０２．２１標準でまだ定義されていないので、これは任意の値を表すために使用される。したがって、オペレータ名前フィールド９２５は、まさにこの例のために、最大長さ、すなわち２５３オクテットを有するものと仮定されている。

受信機がＭＩＨＦレスポンスメッセージを受信したとき、受信機はそれに応じてフレームをデコードし、ＡＣＫ−ｒｅｑビットがピアによって「１」に設定されたことを認識する。本発明によれば、次いで受信機は、図１０に示されるように、肯定応答メッセージ１０００を含むフレームを送信し、これはＭＩＨＦ固定ヘッダ１００５のみを含む。ＭＩＨＦ固定ヘッダ１００５において、ＡＣＫ−ｒｓｐビット１０１０は、このフレームが以前のメッセージの肯定応答を含むことを示す「１」に設定される。さらに、フラグビット１０１５は、ＭＩＨＦ可変ロードにペイロードがない（つまり不在）ことを示す「０」に設定される。したがって、このフレームは肯定応答メッセージのみを含む。

残りのフィールド、およびそれらが含むべき値は、ＩＥＥＥ８０２．２１標準により規定される。したがって、受信機は、フラグビット１０１５を確認することにより、純粋な肯定応答メッセージを区別することができる。

図１１は、本発明による構成された第１の送受信機１１０５および第２の送受信機１１１０を含む無線通信システム１１００を示している。第１の送受信機１１０５および第２の送受信機１１１０は、無線送信／受信ユニット（ＷＴＲＵ）、基地局などにすることができる。代替として、たとえば、物理接続としてイーサネット（登録商標）を使用して、有線通信システムを実装することができる。

図１１に示されているように、第１の送受信機１１０５は第１のアンテナ１１１５を含み、第２の送受信機１１１０は第２のアンテナ１１２０を含む。第１の送受信機１１０５は、第１のアンテナ１１１５を介して、ＭＩＨＦリクエストフレーム１１２５を第２の送受信機１１１０に送る。ＭＩＨＦリクエストフレーム１１２５は、ＭＩＨＦ固定ヘッダおよびＭＩＨＦ可変ロードを含む。ＭＩＨＦリクエストフレーム１１２５のＭＩＨＦ可変ロードは、ＭＩＨＦ可変ヘッダを含まない。第２の送受信機１１１０は、ＭＩＨＦリクエストフレーム１１２５を受信することに応答して、第２のアンテナ１１２０を介して、ＭＩＨＦレスポンスフレーム１１３０を第１の送受信機１１０５に送る。ＭＩＨＦレスポンスフレーム１１３０は、ＭＩＨＦ固定ヘッダおよびＭＩＨＦ可変ロードを含む。ＭＩＨＦレスポンスフレーム１１３０のＭＩＨＦ可変ロードは、ＭＩＨＦ可変ヘッダを含まない。

送受信機１１０５はさらに、ＭＩＨＦリクエストフレーム１１２５およびＭＩＨＦレスポンスフレーム１１３０を送信するための送信機１１３５、ＭＩＨＦリクエストフレーム１１２５およびＭＩＨＦレスポンスフレーム１１３０を受信するための受信機１１４０、およびＭＩＨＦリクエストフレーム１１２５およびＭＩＨＦレスポンスフレーム１１３０を生成するためのプロセッサ１１４５を含む。

送受信機１１１０はさらに、ＭＩＨＦリクエストフレーム１１２５およびＭＩＨＦレスポンスフレーム１１３０を送信するための送信機１１５０、ＭＩＨＦリクエストフレーム１１２５およびＭＩＨＦレスポンスフレーム１１３０を受信するための受信機１１５５、およびＭＩＨＦリクエストフレーム１１２５およびＭＩＨＦレスポンスフレーム１１３０を生成するためのプロセッサ１１６０を含む。

（実施形態）
１． 第１の送受信機および第２の送受信機を含む通信システムにおいて、第１の送受信機がＭＩＨ機能（ＭＩＨＦ）リクエストフレームを第２の送受信機に送信することを備える、メディア独立ハンドオーバー（ＭＩＨ）メッセージを通信する方法であって、ＭＩＨＦリクエストフレームが固定ヘッダおよび可変ロードを含み、可変ロードは可変ヘッダを含まないことを特徴とする方法。
２． 第２の送受信機がＭＩＨＦリクエストフレームを受信することに応答してＭＩＨＦレスポンスフレームを第１の送受信機に送ることをさらに備えることを特徴とする実施形態１に記載の方法。
３． 固定ヘッダは、ＭＩＨＦ識別（ＩＤ）フィールドを含むことを特徴とする実施形態１および２のいずれかに記載の方法。
４． 固定ヘッダは、セッション識別（ＩＤ）フィールドを含むことを特徴とする実施形態１〜３のいずれかに記載の方法。
５． 固定ヘッダは、フラグフィールドを含むことを特徴とする実施形態１〜４のいずれかに記載の方法。
６． フラグフィールドを１に設定して、ペイロードを含むＭＩＨＦリクエストフレームにピギーバックされた肯定応答があることを示すことをさらに備えることを特徴とする実施形態５に記載の方法。
７． フラグフィールドを０に設定して、可変ペイロードフィールドにペイロードがないことを示すことをさらに備えることを特徴とする実施形態５に記載の方法。
８． 可変ロードは、タイプフィールド、長さフィールドおよび値フィールドを含むことを特徴とする実施形態１〜７のいずれかに記載の方法。
９． 値フィールドは、オペレータのリストを取得するための特定のリンクタイプを含むことを特徴とする実施形態８に記載の方法。
１０． 通信システムは、無線通信システムであり、第１の送受信機は、無線送信／受信ユニット（ＷＴＲＵ）であり、第２の送受信機は、基地局であることを特徴とする実施形態１〜９のいずれかに記載の方法。
１１． 通信システムは、無線通信システムであり、第１の送受信機は、基地局であり、第２の送受信機は、無線送信／受信ユニット（ＷＴＲＵ）であることを特徴とする実施形態１〜１０のいずれかに記載の方法。
１２． 通信システムは、イーサネット（登録商標）を使用して物理接続を提供する有線通信システムであることを特徴とする実施形態１〜１０のいずれかに記載の方法。
１３． 第１の送受信機および第２の送受信機を含む通信システムにおいて、メディア独立ハンドオーバー（ＭＩＨ）メッセージを通信する方法であって、
第１の送受信機がＭＩＨ機能（ＭＩＨＦ）リクエストフレームを第２の送受信機に送ることと、
第２の送受信機がＭＩＨＦリクエストフレームを受信することに応答してＭＩＨＦレスポンスフレームを第１の送受信機に送ることであって、ＭＩＨＦレスポンスフレームが固定ヘッダおよび可変ロードを含み、可変ロードは可変ヘッダを含まないことと
を備えることを特徴とする方法。
１４． 固定ヘッダは、ＭＩＨＦ識別（ＩＤ）フィールドを含むことを特徴とする実施形態１３に記載の方法。
１５． 固定ヘッダは、セッション識別（ＩＤ）フィールドを含むことを特徴とする実施形態１３および１４のいずれかに記載の方法。
１６． 固定ヘッダは、フラグフィールドを含むことを特徴とする実施形態１３〜１５のいずれかに記載の方法。
１７． フラグフィールドを１に設定して、可変ロードがデータを含むことを示すことをさらに備えることを特徴とする実施形態１６に記載の方法。
１８． フラグフィールドを０に設定して、可変ロードがデータを含まないことを示すことをさらに備えることを特徴とする実施形態１６に記載の方法。
１９． 可変ロードは、タイプフィールド、長さフィールドおよび値フィールドを含むことを特徴とする実施形態１３〜１８のいずれかに記載の方法。
２０． 値フィールドは、オペレータのリストを取得するための特定のリンクタイプを含むことを特徴とする実施形態１９に記載の方法。
２１． 通信システムは、無線通信システムであり、第１の送受信機は、無線送信／受信ユニット（ＷＴＲＵ）であり、第２の送受信機は、基地局であることを特徴とする実施形態１３〜２０のいずれかに記載の方法。
２２． 通信システムは、無線通信システムであり、第１の送受信機は、基地局であり、第２の送受信機は、無線送信／受信ユニット（ＷＴＲＵ）であることを特徴とする実施形態１３〜２０のいずれかに記載の方法。
２３． 通信システムは、イーサネット（登録商標）を使用して物理接続を提供する有線通信システムであることを特徴とする実施形態１３〜２０のいずれかに記載の方法。
２４． 第１の送受信機および第２の送受信機を含む通信システムにおいて、メディア独立ハンドオーバー（ＭＩＨ）メッセージを通信する方法であって、第１の送受信機がＭＩＨサービスデータ、またはタイプフィールド、長さフィールドおよび値フィールドによって表される可変ヘッダを含むＭＩＨ機能（ＭＩＨＦ）フレームを生成することであって、値フィールドの長さは正確に１２８オクテットであり、長さフィールドは１オクテットのみを占有することと、
第１の送受信機がＭＩＨＦフレームを第２の送受信機に送信することと
を備えることを特徴とする方法。
２５． 長さフィールドによって占有されるオクテットの最上位ビット（ＭＳＢ）は、１の値に設定され、ＭＳＢに続く長さフィールドによって占有されるオクテットの７つの残りのビットは、０の値に設定されることを特徴とする実施形態２４に記載の方法。
２６． 受信機と、
送信機と、
受信機および送信機に結合されたプロセッサであって、プロセッサがメディア独立ハンドオーバー機能（ＭＩＨＦ）リクエストフレームを生成するように構成され、ＭＩＨＦリクエストフレームが固定ヘッダおよび可変ロードを含み、可変ロードは可変ヘッダを含まず、送信機はプロセッサによって生成されたＭＩＨＦリクエストフレームを送信するプロセッサと
を備えたことを特徴とする送受信機。
２７． 固定ヘッダは、ＭＩＨＦ識別（ＩＤ）フィールドを含むことを特徴とする実施形態２６に記載の送受信機。
２８． 固定ヘッダは、セッション識別（ＩＤ）フィールドを含むことを特徴とする実施形態２６および２７のいずれかに記載の送受信機。
２９． 固定ヘッダは、フラグフィールドを含むことを特徴とする実施形態２６〜２８のいずれかに記載の送受信機。
３０． プロセッサは、フラグフィールドを１に設定して、ペイロードを含むＭＩＨＦリクエストフレームにピギーバックされた肯定応答があることを示すことを特徴とする実施形態２９に記載の送受信機。
３１． プロセッサは、フラグフィールドを０に設定して、可変ペイロードフィールドにペイロードがないことを示すことを特徴とする実施形態２６〜３０のいずれかに記載の送受信機。
３２． 可変ロードは、タイプフィールド、長さフィールドおよび値フィールドを含むことを特徴とする実施形態２６〜３１のいずれかに記載の送受信機。
３３． 値フィールドは、オペレータのリストを取得するための特定のリンクタイプを含むことを特徴とする実施形態３２に記載の送受信機。
３４． 送受信機は、無線送信／受信ユニット（ＷＴＲＵ）であることを特徴とする実施形態２６〜３３のいずれかに記載の送受信機。
３５． 送受信機は、有線送信／受信ユニットであることを特徴とする実施形態２６〜３３のいずれかに記載の送受信機。
３６． 送受信機は、基地局であることを特徴とする実施形態２６〜３３のいずれかに記載の送受信機。
３７． メディア独立ハンドオーバー機能（ＭＩＨＦ）リクエストフレームを受信するように構成された受信機と、
送信機と、
受信機および送信機に結合されたプロセッサであって、プロセッサは受信機がＭＩＨＦリクエストフレームを受信することに応答してＭＩＨＦレスポンスフレームを生成するように構成され、ＭＩＨＦレスポンスフレームが固定ヘッダおよび可変ロードを含み、可変ロードは可変ヘッダを含まず、送信機はプロセッサによって生成されたＭＩＨＦレスポンスフレームを送信するプロセッサと
を備えたことを特徴とする送受信機。
３８． 固定ヘッダは、ＭＩＨＦ識別（ＩＤ）フィールドを含むことを特徴とする実施形態３７に記載の送受信機。
３９． 固定ヘッダは、セッション識別（ＩＤ）フィールドを含むことを特徴とする実施形態３７から３８のいずれかに記載の送受信機。
４０． 固定ヘッダは、フラグフィールドを含むことを特徴とする実施形態３７〜３９のいずれかに記載の送受信機。
４１． プロセッサは、フラグフィールドを１に設定して、ペイロードを含むＭＩＨＦリクエストフレームにピギーバックされた肯定応答があることを示すことを特徴とする実施形態４０に記載の送受信機。
４２． プロセッサは、フラグフィールドを０に設定して、可変ペイロードフィールドにペイロードがないことを示すことを特徴とする実施形態４１に記載の送受信機。
４３． 可変ロードは、タイプフィールド、長さフィールドおよび値フィールドを含むことを特徴とする実施形態３７〜４２のいずれかに記載の送受信機。
４４． 値フィールドは、オペレータのリストを取得するための特定のリンクタイプを含むことを特徴とする実施形態４３に記載の送受信機。
４５． 送受信機は、無線送信／受信ユニット（ＷＴＲＵ）であることを特徴とする実施形態３７〜４４のいずれかに記載の送受信機。
４６． 送受信機は、有線送信／受信ユニットであることを特徴とする実施形態３７〜４４のいずれかに記載の送受信機。
４７． 送受信機は、基地局であることを特徴とする実施形態３７〜４４のいずれかに記載の送受信機。
４８． 受信機と、
送信機と、
受信機および送信機に結合されたプロセッサであって、プロセッサはサービスデータ、またはタイプフィールド、長さフィールドおよび値フィールドによって表される可変ヘッダを含むメディア独立ハンドオーバー機能（ＭＩＨＦ）フレームを生成するように構成され、値フィールドの長さは正確に１２８オクテットであり、長さフィールドは１オクテットのみを占有し、送信機はプロセッサによって生成されたＭＩＨＦフレームを送信するプロセッサと
を備えたことを特徴とする送受信機。
４９． 長さフィールドによって占有されるオクテットの最上位ビット（ＭＳＢ）は、１の値に設定され、ＭＳＢに続く長さフィールドによって占有されるオクテットの７つの残りのビットは、０の値に設定されることを特徴とする実施形態４８に記載の送受信機。

本発明の特徴および要素は特定の組合せで好ましい実施形態において説明されるが、各特徴または要素は、好ましい実施形態の他の特徴および要素なしで単独で使用するか、または本発明のその他の特徴および要素のあるなしにかかわらずさまざまな組合せで使用することができる。本発明において提供される方法または流れ図は、汎用コンピュータまたはプロセッサによって実行されるためにコンピュータ可読記憶媒体で明確に具体化されたコンピュータプログラム、ソフトウェア、またはファームウェアにおいて実装することができる。コンピュータ可読記憶媒体の例は、読み取り専用メモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、レジスタ、キャッシュメモリ、半導体メモリデバイス、内蔵ハードディスクおよび取り外し可能ディスクなどの磁気媒体、磁気光学媒体、ＣＤ−ＲＯＭディスクなどの光媒体、およびデジタル多用途ディスク（ＤＶＤ）を含む。

適切なプロセッサは、例として、汎用プロセッサ、特殊用途プロセッサ、標準的なプロセッサ、デジタルシグナルプロセッサ（ＤＳＰ）、複数のマイクロプロセッサ、ＤＳＰコアと関連する１つまたは複数のマイクロプロセッサ、コントローラ、マイクロコントローラ、特殊用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）回路、任意の他のタイプの集積回路（ＩＣ）および／またはステートマシンを含む。

ソフトウェアと関連するプロセッサは、無線送受信ユニット（ＷＴＲＵ）、ユーザ機器（ＵＥ）、端末、基地局、無線ネットワークコントローラ（ＲＮＣ）、または任意のホストコンピュータにおける使用のために無線周波数送受信機を実装するのに使用することができる。ＷＴＲＵは、カメラ、ビデオカメラモジュール、テレビ電話、スピーカーフォン、振動デバイス、スピーカー、マイクロフォン、テレビ送受信機、ハンドフリーヘッドセット、キーボード、ブルートゥース（登録商標）モジュール、周波数変調（ＦＭ）無線ユニット、液晶ディスプレイ（ＬＣＤ）表示ユニット、有機発光ダイオード（ＯＬＥＤ；ｏｒｇａｎｉｃ ｌｉｇｈｔ−ｅｍｉｔｔｉｎｇ ｄｉｏｄｅ）表示ユニット、デジタル音楽プレイヤー、メディアプレイヤー、テレビゲームプレイヤーモジュール、インターネットブラウザ、および／または任意の無線ローカルエリアネットワーク（ＷＬＡＮ）モジュールなど、ハードウェアおよび／またはソフトウェアに実装されるモジュールと共に使用することができる。

Claims (10)

1. 無線通信装置に用いる方法であって、
   前記方法は、タイプ−長さ−値（ＴＬＶ）パラメータ含むフレームを生成することを含み、
   前記ＴＬＶパラメータはタイプフィールド、長さフィールドおよび値フィールドと含み、
   前記長さフィールドは前記値フィールドの長さを示し、かつ
   前記値フィールドの長さが１２８オクテット未満であるという条件で、
   前記長さフィールドは１オクテットの長さであり、
   前記長さフィールドの最上位ビット（ＭＳＢ）は０の値に設定され、かつ
   前記長さフィールドの７つの残りの有意ビットは前記値フィールドの長さを示し、
   前記値フィールドの長さが正確に１２８オクテットであるという条件で、
   前記長さフィールドは１オクテットの長さであり、
   前記長さフィールドの前記ＭＳＢは１の値に設定され、かつ
   前記長さフィールドの７つの残りの有意ビットは０の値に設定され、
   前記値フィールドの長さが１２８オクテットよりも大きいという条件で、
   前記長さフィールドは、第１のオクテッドと、１または複数の追加のオクテッドを含む、２以上のオクテットを含み、
   前記第１のオクテットの前記ＭＳＢは１の値に設定され、
   前記長さフィールドの前記第１のオクテットの７つの残りの有効ビットは、１または複数の追加のオクテットの長さを示し、
   前記１または複数の追加のオクテットの値は、１２８の値に追加されたときに、前記値フィールドの長さを示し、かつ
   前記方法は、前記フレームを送信することを含むことを特徴とする方法。
2. 前記フレームはメディア独立ハンドオーバー（ＭＩＨ）フレームであり、
   前記フレームはＭＩＨヘッダとペイロードとを含み、
   前記ＴＬＶパラメータは前記ペイロードに含まれ、かつ
   前記ＭＩＨヘッダは、バージョンフィールド、肯定応答リクエスト（Ａｃｋ−Ｒｅｑ）フィールド、肯定応答レスポンス（Ａｃｋ−Ｒｓｐ）フィールド、ＭＩＨメッセージＩＤフィールド、およびトランザクションＩＤフィールドを含む
   ことを特徴とする請求項１に記載の方法。
3. 前記無線通信装置は無線送信／受信ユニット（ＷＴＲＵ）であることを特徴とする請求項１に記載の方法。
4. 前記無線通信装置はユーザー装置であることを特徴とする請求項１に記載の方法。
5. 前記無線通信装置は基地局であることを特徴とする請求項１に記載の方法。
6. 無線通信装置であって、
   前記無線通信装置は、タイプ−長さ−値（ＴＬＶ）パラメータ含むフレームを生成するように構成されたプロセッサを備え、
   前記ＴＬＶパラメータはタイプフィールド、長さフィールドおよび値フィールドと含み、
   前記長さフィールドは前記値フィールドの長さを示し、かつ
   前記値フィールドの長さが１２８オクテット未満であるという条件で、
   前記長さフィールドは１オクテットの長さであり、
   前記長さフィールドの最上位ビット（ＭＳＢ）は０の値に設定され、かつ
   前記長さフィールドの７つの残りの有意ビットは前記値フィールドの長さを示し、
   前記値フィールドの長さが正確に１２８オクテットであるという条件で、
   前記長さフィールドは１オクテットの長さであり、
   前記長さフィールドの前記ＭＳＢは１の値に設定され、かつ
   前記長さフィールドの７つの残りの有意ビットは０の値に設定され、
   前記値フィールドの長さが１２８オクテットよりも大きいという条件で、
   前記長さフィールドは、第１のオクテッドと、１または複数の追加のオクテッドを含む、２以上のオクテットを含み、
   前記第１のオクテットの前記ＭＳＢは１の値に設定され、
   前記長さフィールドの前記第１のオクテットの７つの残りの有効ビットは、１または複数の追加のオクテットの長さを示し、
   前記１または複数の追加のオクテットの値は、１２８の値に追加されたときに、前記値フィールドの長さを示し、かつ
   前記無線通信装置は、前記フレームを送信するように構成された送信機を備えたことを特徴とする無線通信装置。
7. 前記フレームはメディア独立ハンドオーバー（ＭＩＨ）フレームであり、
   前記フレームはＭＩＨヘッダとペイロードとを含み、
   前記ＴＬＶパラメータは前記ペイロードに含まれ、かつ
   前記ＭＩＨヘッダは、バージョンフィールド、肯定応答リクエスト（Ａｃｋ−Ｒｅｑ）フィールド、肯定応答レスポンス（Ａｃｋ−Ｒｓｐ）フィールド、ＭＩＨメッセージＩＤフィールド、およびトランザクションＩＤフィールドを含む
   ことを特徴とする請求項６に記載の無線通信装置。
8. 前記無線通信装置は無線送信／受信ユニット（ＷＴＲＵ）であることを特徴とする請求項６に記載の無線通信装置。
9. 前記無線通信装置はユーザー装置であることを特徴とする請求項６に記載の無線通信装置。
10. 前記無線通信装置は基地局であることを特徴とする請求項６に記載の無線通信装置。

Images