(57)【要約】  本発明は、ＩＥＥＥ８０２．２１標準によって定義される既存のメディア独立ハンドオーバー（ＭＩＨ）機能（ＭＩＨＦ）フレームフォーマットを変更する。１つの実施形態において、ＭＩＨＦフレームの可変ロードは、ＭＩＨＦ識別（ＩＤ）フィールドおよびセッションＩＤフィールドをＭＩＨＦ固定ヘッダの固定フィールドとして定義することにより、ＭＩＨＦ可変ヘッダを取り除くように変更される。したがって、ＭＩＨＦ可変ロードは、ＭＩＨＦペイロードのみで構成される。もう１つの実施形態において、情報要素（ＩＥ）、ヘッダ、あるいはコマンドまたはイベントのようなＭＩＨサービスデータなどのフィールドは、タイプフィールド、長さフィールドおよび値フィールド（ＴＬＶ）により表される。値フィールドの長さは正確に１２８オクテットであり、長さフィールドは１オクテットしか占有しない。
2009540749.tif 000002
【特許請求の範囲】
【請求項１】
第１の送受信機および第２の送受信機を含む通信システムにおいて、メディア独立ハンドオーバー（ＭＩＨ）メッセージを通信する方法であって、
前記第１の送受信機がＭＩＨ機能（ＭＩＨＦ）リクエストフレームを前記第２の送受信機に送信することであって、前記ＭＩＨＦリクエストフレームが固定ヘッダおよび可変ロードを含み、前記可変ロードは可変ヘッダを含まないことと、
前記第２の送受信機が前記ＭＩＨＦリクエストフレームを受信することに応答してＭＩＨＦレスポンスフレームを前記第１の送受信機に送信することと
を備えることを特徴とする方法。
【請求項２】
前記固定ヘッダは、ＭＩＨＦ識別（ＩＤ）フィールドを含むことを特徴とする請求項１に記載の方法。
【請求項３】
前記固定ヘッダは、セッション識別（ＩＤ）フィールドを含むことを特徴とする請求項１に記載の方法。
【請求項４】
前記固定ヘッダは、フラグフィールドを含むことを特徴とする請求項１に記載の方法。
【請求項５】
前記フラグフィールドを１に設定して、ペイロードを含む前記ＭＩＨＦリクエストフレームに結合された肯定応答があることを示すことをさらに備えることを特徴とする請求項４に記載の方法。
【請求項６】
前記フラグフィールドを０に設定して、可変ペイロードフィールドにペイロードがないことを示すことをさらに備えることを特徴とする請求項４に記載の方法。
【請求項７】
前記可変ロードは、タイプフィールド、長さフィールドおよび値フィールドを含むことを特徴とする請求項１に記載の方法。
【請求項８】
前記値フィールドは、オペレータのリストを取得するための特定のリンクタイプを含むことを特徴とする請求項７に記載の方法。
【請求項９】
前記通信システムは、無線通信システムであり、前記第１の送受信機は、無線送信／受信ユニット（ＷＴＲＵ）であり、前記第２の送受信機は、基地局であることを特徴とする請求項１に記載の方法。
【請求項１０】
前記通信システムは、無線通信システムであり、前記第１の送受信機は、基地局であり、前記第２の送受信機は、無線送信／受信ユニット（ＷＴＲＵ）であることを特徴とする請求項１に記載の方法。
【請求項１１】
前記通信システムは、イーサネット（登録商標）を使用して物理接続を提供する有線通信システムであることを特徴とする請求項１に記載の方法。
【請求項１２】
第１の送受信機および第２の送受信機を含む通信システムにおいて、メディア独立ハンドオーバー（ＭＩＨ）メッセージを通信する方法であって、
前記第１の送受信機がＭＩＨ機能（ＭＩＨＦ）リクエストフレームを前記第２の送受信機に送信することと、
前記第２の送受信機が前記ＭＩＨＦリクエストフレームを受信することに応答してＭＩＨＦレスポンスフレームを前記第１の送受信機に送信することであって、前記ＭＩＨＦレスポンスフレームが固定ヘッダおよび可変ロードを含み、前記可変ロードは可変ヘッダを含まないことと
を備えることを特徴とする方法。
【請求項１３】
前記固定ヘッダは、ＭＩＨＦ識別（ＩＤ）フィールドを含むことを特徴とする請求項１２に記載の方法。
【請求項１４】
前記固定ヘッダは、セッション識別（ＩＤ）フィールドを含むことを特徴とする請求項１２に記載の方法。
【請求項１５】
前記固定ヘッダは、フラグフィールドを含むことを特徴とする請求項１２に記載の方法。
【請求項１６】
前記フラグフィールドを１に設定して、前記可変ロードがデータを含むことを示すことをさらに備えることを特徴とする請求項１５に記載の方法。
【請求項１７】
前記フラグフィールドを０に設定して、前記可変ロードがデータを含まないことを示すことをさらに備えることを特徴とする請求項１５に記載の方法。
【請求項１８】
前記可変ロードは、タイプフィールド、長さフィールドおよび値フィールドを含むことを特徴とする請求項１２に記載の方法。
【請求項１９】
前記値フィールドは、オペレータのリストを取得するための特定のリンクタイプを含むことを特徴とする請求項１８に記載の方法。
【請求項２０】
前記通信システムは、無線通信システムであり、前記第１の送受信機は、無線送信／受信ユニット（ＷＴＲＵ）であり、前記第２の送受信機は、基地局であることを特徴とする請求項１２に記載の方法。
【請求項２１】
前記通信システムは、無線通信システムであり、前記第１の送受信機は、基地局であり、前記第２の送受信機は、無線送信／受信ユニット（ＷＴＲＵ）であることを特徴とする請求項１２に記載の方法。
【請求項２２】
前記通信システムは、イーサネット（登録商標）を使用して物理接続を提供する有線通信システムであることを特徴とする請求項１２に記載の方法。
【請求項２３】
第１の送受信機および第２の送受信機を含む通信システムにおいて、メディア独立ハンドオーバー（ＭＩＨ）メッセージを通信する方法であって、
前記第１の送受信機がＭＩＨサービスデータ、またはタイプフィールド、長さフィールドおよび値フィールドによって表される可変ヘッダを含むＭＩＨ機能（ＭＩＨＦ）フレームを生成することであって、前記値フィールドの長さは正確に１２８オクテットであり、前記長さフィールドは１オクテットのみを占有することと、
前記第１の送受信機が前記ＭＩＨＦフレームを前記第２の送受信機に送信することと
を備えることを特徴とする方法。
【請求項２４】
前記長さフィールドによって占有される前記オクテットの最上位ビット（ＭＳＢ）は、１の値に設定され、前記ＭＳＢに続く前記長さフィールドによって占有される前記オクテットの７つの残りのビットは、０の値に設定されることを特徴とする請求項２３に記載の方法。
【請求項２５】
受信機と、
送信機と、
前記受信機および前記送信機に結合されたプロセッサであって、前記プロセッサがメディア独立ハンドオーバー機能（ＭＩＨＦ）リクエストフレームを生成するように構成され、前記ＭＩＨＦリクエストフレームが固定ヘッダおよび可変ロードを含み、前記可変ロードは可変ヘッダを含まず、前記送信機は前記プロセッサによって生成された前記ＭＩＨＦリクエストフレームを送信するプロセッサと
を備えたことを特徴とする送受信機。
【請求項２６】
前記固定ヘッダは、ＭＩＨＦ識別（ＩＤ）フィールドを含むことを特徴とする請求項２５に記載の送受信機。
【請求項２７】
前記固定ヘッダは、セッション識別（ＩＤ）フィールドを含むことを特徴とする請求項２５に記載の送受信機。
【請求項２８】
前記固定ヘッダは、フラグフィールドを含むことを特徴とする請求項２５に記載の送受信機。
【請求項２９】
前記プロセッサは、前記フラグフィールドを１に設定して、ペイロードを含む前記ＭＩＨＦリクエストフレームにピギーバックされた肯定応答があることを示すことを特徴とする請求項２８に記載の送受信機。
【請求項３０】
前記プロセッサは、前記フラグフィールドを０に設定して、可変ペイロードフィールドにペイロードがないことを示すことを特徴とする請求項２８に記載の送受信機。
【請求項３１】
前記可変ロードは、タイプフィールド、長さフィールドおよび値フィールドを含むことを特徴とする請求項２５に記載の送受信機。
【請求項３２】
前記値フィールドは、オペレータのリストを取得するための特定のリンクタイプを含むことを特徴とする請求項３１に記載の送受信機。
【請求項３３】
前記送受信機は、無線送信／受信ユニット（ＷＴＲＵ）であることを特徴とする請求項２５に記載の送受信機。
【請求項３４】
前記送受信機は、有線送信／受信ユニットであることを特徴とする請求項２５に記載の送受信機。
【請求項３５】
前記送受信機は、基地局であることを特徴とする請求項２５に記載の送受信機。
【請求項３６】
メディア独立ハンドオーバー機能（ＭＩＨＦ）リクエストフレームを受信するように構成された受信機と、
送信機と、
前記受信機および前記送信機に結合されたプロセッサであって、前記プロセッサは前記受信機がＭＩＨＦリクエストフレームを受信することに応答して前記ＭＩＨＦレスポンスフレームを生成するように構成され、前記ＭＩＨＦレスポンスフレームが固定ヘッダおよび可変ロードを含み、前記可変ロードは可変ヘッダを含まず、前記送信機は前記プロセッサによって生成された前記ＭＩＨＦレスポンスフレームを送信するプロセッサと
を備えたことを特徴とする送受信機。
【請求項３７】
前記固定ヘッダは、ＭＩＨＦ識別（ＩＤ）フィールドを含むことを特徴とする請求項３６に記載の送受信機。
【請求項３８】
前記固定ヘッダは、セッション識別（ＩＤ）フィールドを含むことを特徴とする請求項３６に記載の送受信機。
【請求項３９】
前記固定ヘッダは、フラグフィールドを含むことを特徴とする請求項３６に記載の送受信機。
【請求項４０】
前記プロセッサは、前記フラグフィールドを１に設定して、ペイロードを含む前記ＭＩＨＦリクエストフレームに結合された肯定応答があることを示すことを特徴とする請求項３９に記載の送受信機。
【請求項４１】
前記プロセッサは、前記フラグフィールドを０に設定して、可変ペイロードフィールドにペイロードがないことを示すことを特徴とする請求項３９に記載の送受信機。
【請求項４２】
前記可変ロードは、タイプフィールド、長さフィールドおよび値フィールドを含むことを特徴とする請求項３６に記載の送受信機。
【請求項４３】
前記値フィールドは、オペレータのリストを取得するための特定のリンクタイプを含むことを特徴とする請求項４２に記載の送受信機。
【請求項４４】
前記送受信機は、無線送信／受信ユニット（ＷＴＲＵ）であることを特徴とする請求項３６に記載の送受信機。
【請求項４５】
前記送受信機は、有線送信／受信ユニットであることを特徴とする請求項３６に記載の送受信機。
【請求項４６】
前記送受信機は、基地局であることを特徴とする請求項３６に記載の送受信機。
【請求項４７】
受信機と、
送信機と、
前記受信機および前記送信機に結合されたプロセッサであって、前記プロセッサがサービスデータ、またはタイプフィールド、長さフィールドおよび値フィールドによって表される可変ヘッダを含むメディア独立ハンドオーバー機能（ＭＩＨＦ）フレームを生成するように構成され、前記値フィールドの長さは正確に１２８オクテットであり、前記長さフィールドは１オクテットのみを占有し、前記送信機は、前記プロセッサによって生成された前記ＭＩＨフレームを送信するプロセッサと
を備えたことを特徴とする送受信機。
【請求項４８】
前記長さフィールドによって占有される前記オクテットの最上位ビット（ＭＳＢ）は、１の値に設定され、前記ＭＳＢに続く前記長さフィールドによって占有される前記オクテットの７つの残りのビットは、０の値に設定されることを特徴とする請求項４７に記載の送受信機。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、無線通信に関する。さらに詳細には、本発明は、メディア独立ハンドオーバー（ＭＩＨ）メッセージを無線で送信および受信するために使用されるメディア独立ハンドオーバー機能（ＭＩＨＦ）フレームフォーマットに関する。
【背景技術】
【０００２】
図１は、ＩＥＥＥ８０２．２１標準によって規定されている、タイプフィールド１０５、長さフィールド１１０、および値フィールド１１５を含むＩＥ１００の現在のタイプ−長さ−値（ＴＬＶ）表現を示している。代替として、ＴＬＶフィールドは、ヘッダのような他のフィールド、あるいはコマンドまたはイベントのようなＭＩＨサービスデータを表すこともある。
【０００３】
ＩＥＥＥ８０２．２１標準において、タイプフィールド１０５はＩＥのタイプを示し、定義された識別（ＩＤ）値を有する。値フィールド１１５は、ＩＥ１００のペイロードまたは値を含む。第１のシナリオにおいて、値フィールド１１５によって占有されるオクテットの数が１２７以下である場合、長さフィールド１１０のサイズは常に１オクテットであり、オクテットの最上位ビット（ＭＳＢ）１２０は値「０」に設定される。第２のシナリオにおいて、値フィールド１１５によって占有されるオクテットの数が１２７よりも大きい場合、長さフィールド１１０のサイズは少なくとも「ｘ」オクテットであり、ここで「ｘ」は２以上である。この場合、長さフィールド１１０の第１のオクテットのＭＳＢ１２５は値「１」に設定され、第１のオクテットの残りの７ビットは、第１のオクテットに付加される追加のオクテットの数を示す。長さフィールド１１０の第２のオクテットによって表される数は、値フィールド１１５の合計サイズを示す。
【発明の概要】
【発明が解決しようとする課題】
【０００４】
ＩＥＥＥ８０２．２１に規定されている長さフィールドの説明には問題がある。具体的には、長さフィールドの解釈の第２のシナリオにおいて、ＩＥＥＥ８０２．２１標準は、長さフィールドの第２のオクテットによって表される数が値フィールドの合計サイズを示すことを規定している。第２のオクテットによって表される数は値フィールドの長さを示していないので、これは不正確である。代わりに、第２のオクテットから始まる追加の付加されたオクテットによって表される数は、値フィールドの長さを示す。加えて、追加のオクテットの値は、ビットとは対照的に、オクテットで値フィールドの長さを表すべきである。したがって、長さフィールドは効率的に使用されていない。
【０００５】
図２は、ＩＥＥＥ８０２．２１標準によって規定されているＭＩＨＦフレーム２００の現在のフォーマットを示している。ＩＥＥＥ８０２．２１標準は、ＭＩＨＦフレーム２００がＭＩＨＦ固定ヘッダ２０５およびＭＩＨＦ可変ロード２１０で構成されることを規定している。ＭＩＨＦ可変ロード２１０は、ＭＩＨＦ可変ヘッダ２１５およびＭＩＨＦペイロード２２０で構成される。
【０００６】
ＩＥＥＥ８０２．２１標準は、ＭＩＨＦ固定ヘッダ２０５が必須であることを規定している。以下の表１は、ＩＥＥＥ８０２．２１によって規定されているＭＩＨＦ固定ヘッダ２０５の内容を示している。
【０００７】
【表１】
2009540749.tif 000003
【０００８】
ＩＥＥＥ８０２．２１で現在規定されているように、ＭＩＨＦ可変ヘッダ２１５は、埋め込まれているペイロードの分析および調整に役立つ追加の識別子を含む。これらの識別子はまた、ＴＬＶフォーマットでも表される。ＩＥＥＥ８０２．２１で規定されているこれらの識別子の（ＴＬＶの）タイプフィールドのいくつかの可能な値は、（リクエストとレスポンスをマッチさせる）トランザクションＩＤ、（通信ピアを識別する）ＭＩＨ機能ＩＤ／セッションＩＤ、および（受信したメッセージのタイムスタンプを識別する）同期情報を含む。
【０００９】
ＭＩＨＦペイロードフィールド２２０は、メッセージのペイロードとして機能するサービス固有のＴＬＶを含む。図２（ＭＩＨＦフレームフォーマット）のＭＩＨＦ固定ヘッダ２０５と表１（ＭＩＨＦ固定ヘッダの説明）のそのフィールドの説明を比較すると、表１に示される「Ｎｕｍｂｅｒ  ｏｆ  Ａｄｄｉｔｉｏｎａｌ  Ｈｅａｄｅｒ  Ｉｄｅｎｔｉｆｉｅｒｓ（追加ヘッダ識別子の数）」フィールドが、図２のＭＩＨＦフレーム２００に存在しないことに留意されたい。
【００１０】
ＭＩＨＦ固定ヘッダ２０５の可変ロード長さフィールド２２５は、１６ビットによって表される。（ＩＥＥＥ８０２．２１に規定されている）可変ロード長さフィールド２２５は、ＭＩＨＦフレーム２００に埋め込まれている可変ロードの合計長さがＭＩＨＦ可変ヘッダ２１５の長さとＭＩＨＦペイロード２２０の長さの合計であることを示している。ＭＩＨＦ固定ヘッダ２０５の長さは含まれない。
【００１１】
ＭＩＨＦ可変ヘッダ２１０の長さは計算することができ、その表現に使用される１６ビットは節減すべきであるため、可変ロード長さフィールド２２５は必要ではない。
【００１２】
ＭＩＨＦ固定ヘッダ２０５は、肯定応答をリクエストする肯定応答リクエスト（ＡＣＫ−ｒｅｑ）フィールド２３０、およびメッセージの受信を確認する肯定応答レスポンス（ＡＣＫ−ｒｓｐ）フィールド２３５を定義する。ＩＥＥＥ８０２．２１に規定されているように、肯定応答メッセージは、添付される（「ピギーバックされる」）か、またはレスポンスパケットで単独で送られる。しかし、ＩＥＥＥ８０２．２１標準は、レスポンスフレームが何らペイロードを持たず、肯定応答としてのみ機能することを示す方法を規定していない。したがって、ピアは、ＡＣＫ−ｒｓｐビットを「１」に設定されたメッセージを受信した場合、ペイロードがあるかどうかを確認する必要があるであろう。ペイロードがない場合、ＭＩＨＦ可変ロードフィールド２１０は、受信機によって有効ビットとして解釈される可能性のあるダミービットを含むことになるので、これは効率的ではない。したがって、純粋な肯定応答メッセージを識別するフィールドを有することが必要であり、ＭＩＨＦフレーム２００はＭＩＨＦ可変ロードフィールド２１０を有するべきではない。現在、そのようなフィールドは定義されていない。
【００１３】
ＩＥＥＥ８０２．２１標準は、ＭＩＨＦ  ＩＤ、セッションＩＤ、およびトランザクションＩＤ２４０を含む３つのＭＩＨＦプロトコル識別子を定義する。ＭＩＨＦ  ＩＤは、ＭＩＨＦフレーム２００が由来する送り側を識別する。セッションＩＤは、セッションの由来元によって生成された一意の識別子である。トランザクションＩＤ２４０は、リクエストとレスポンスをマッチさせるためにも、リクエスト、レスポンス、指示をＡＣＫにマッチさせるためにも使用される（上記の表１を参照）。
【００１４】
したがって、３つのＭＩＨＦプロトコル識別子のすべては（共に）ＭＩＨＦフレーム（またはメッセージ）を一意に識別する。しかし、トランザクションＩＤ２４０のみがＭＩＨＦ固定ヘッダ２０５に示されているが、ＭＩＨＦ  ＩＤ、セッションＩＤ、およびトランザクションＩＤ２４０は、ＴＬＶフォーマットで表されることになっており、（ＭＩＨＦ可変ロード２１０の一部である）ＭＩＨＦ可変ヘッダ２１５に存するように規定されている。問題は、ＴＬＶを使用してＭＩＨＦ  ＩＤおよびセッションＩＤの各々を表すことにより、ビットを浪費し、ＭＩＨＦフレーム２００のデコーディングを複雑にすることになることである。加えて、トランザクションＩＤ２４０はすでに、ＭＩＨＦ固定ヘッダ２０５内の固定フィールドを付与されており、ＭＩＨＦ可変ヘッダ２１５においてＴＬＶフォーマットでこれを再表現する必要はない。
【課題を解決するための手段】
【００１５】
本発明は、ＩＥＥＥ８０２．２１標準の既存のＭＩＨＦフレームフォーマットに対する一組の変更を含む。本発明は、ＩＥＥＥ８０２．２１標準によって定義されている既存のＭＩＨＦフレームフォーマットを変更する。１つの実施形態において、ＭＩＨＦフレームの可変ロードは、ＭＩＨＦ  ＩＤフィールドおよびセッションＩＤフィールドをＭＩＨＦ固定ヘッダ中の固定フィールドとして定義することにより、ＭＩＨＦ可変ヘッダを取り除くように変更される。したがって、ＭＩＨＦ可変ロードは、ＭＩＨＦペイロードのみで構成される。別の実施形態において、ＩＥ、コマンド、またはヘッダのようなフィールドは、タイプフィールド、長さフィールド、および値フィールド（ＴＬＶ）により表される。値フィールドの長さは正確に１２８オクテットであり、長さフィールドは１オクテットしか占有しない。
【００１６】
本発明のさらに詳細な理解は、例として示され、添付の図面と併せて理解される、以下の好ましい実施形態の説明から得ることができる。
【図面の簡単な説明】
【００１７】
【図１】ＩＥＥＥ８０２．２１標準によって規定されているＩＥの現在のＴＬＶフォーマット表現を示す図である。
【図２】現在のＩＥＥＥ８０２．２１のＭＩＨＦフレームフォーマットを示す図である。
【図３】ＩＥＥＥ８０２．２１によって規定されている現在のＴＬＶフォーマットを示す図である。
【図４】１２８オクテットよりも大きい長さを有する値フィールドを持つＴＬＶフレームを示す図である。
【図５】本発明による正確に１２８オクテットの長さを有する値フィールドを持つＴＬＶフレームを示す図である。
【図６】本発明による構成されたＭＩＨＦフレームフォーマットを示す図である。
【図７】本発明によるＩＥをリクエストするための例示的なＭＩＨＦリクエストフレームを示す図である。
【図８】本発明によるＭＩＨＦリクエストフレームに応答してＩＥを提供する例示的なＭＩＨＦレスポンスフレームを示す図である。
【図９】本発明によるオペレータ識別子ＩＥの例示的なＴＬＶ表現を示す図である。
【図１０】本発明による肯定応答メッセージを持つＭＩＨＦフレームを示す図である。
【図１１】本発明による構成された通信システムを示す図である。
【発明を実施するための形態】
【００１８】
これ以降、用語「無線送信／受信ユニット（ＷＴＲＵ）」はユーザ機器（ＵＥ）、移動局、固定または移動加入者ユニット、ページャー、携帯電話、パーソナルデジタル端末（ＰＤＡ）、コンピュータ、または無線環境において動作することのできる他の任意のタイプのユーザデバイスを含むが、これらに限定されない。これ以降、用語「基地局」はＮｏｄｅ  Ｂ、サイトコントローラ、アクセスポイント（ＡＰ）、または無線環境において動作することのできる他の任意のタイプのインターフェイス接続デバイスを含むが、これらに限定されない。
【００１９】
図３は、図１に示されるＩＥ１００のフォーマットと同様のＩＥＥＥ８０２．２１で定義されているＩＥの現在のＴＬＶフォーマット表現を示している。本発明は、値フィールドの長さが１２７オクテットよりも大きいとき、ＴＬＶの長さフィールドの解釈に適用可能である。
【００２０】
図４によって詳細に示されるように、値フィールドによって占有されるオクテットの数が１２８オクテットよりも大きい場合、長さフィールドの最初のオクテットのＭＳＢは「１」に設定される。７ビットの残りの部分は、（長さフィールドの）最初のオクテットにさらに付加される（新しい長さフィールドの）オクテットの数を示す。それで、値フィールドの長さは、１２８に、第２のオクテットから始まるその他の付加された長さフィールドのオクテットによって表される数値を加えたものである。
【００２１】
本発明は、図５に示されるように、値フィールドの長さが正確に１２８オクテットであるときに適用する第３のケースを定義する。値フィールドの長さが正確に１２８オクテットである場合、長さフィールドのＭＳＢは「１」に設定され、残りの７ビットは「０」に設定される。現在のＩＥＥＥ８０２．２１標準によれば、図１に示されるように、長さが１２７オクテットよりも大きい場合、値フィールドの長さを完全に示すために予備のオクテット「ｘ」が追加されなければならない。たとえ長さが正確に１２８オクテットであっても、現在のＩＥＥＥ８０２．２１標準は、１２８オクテットの正確な値を満たすために予備オクテットを要する。したがって、予備オクテットの無駄がある。本発明は、値フィールドの長さが正確に１２８オクテットである場合、値フィールドの長さをオクテットで示す追加のオクテットを要しない。
【００２２】
図６は、本発明に従って構成されたＭＩＨＦフレームフォーマット６００を示している。ＭＩＨＦフレームフォーマット６００は、ＭＩＨＦ固定ヘッダ６０５およびＭＩＨＦ可変ロード６１０を含む。しかし、（現在のＩＥＥＥ８０２．２１ＭＩＨＦフレームのＭＩＨＦ可変ロードの一部である）ＭＩＨＦ可変ヘッダは、除去されている。これは、以前ＴＬＶで表されており、ＭＩＨＦ可変ヘッダに含まれていたＭＩＨＦ  ＩＤおよびセッションＩＤが、いまは本発明によりＭＩＨＦ固定ヘッダ６０５の固定フィールドとして定義されているためである。したがって、ＭＩＨＦ可変ロード６１０は、ＭＩＨＦペイロードのみで構成される。
【００２３】
図６に示されるＭＩＨＦ固定ヘッダ６０５のフィールド名は、本発明に従って定義される新しいフィールド、または変更された古いフィールドのいずれかである。
【００２４】
予約フィールド６１５は、変更されている。これは当初、１０ビットにより表されていたが、いまは９ビットにより表されるべきである。その他のビットは、本発明に従って「フラグ」フィールド６２０を定義するために使用される。このフィールドをどのように使用することができるかについて２つのシナリオがある。
【００２５】
第１のシナリオにおいて、（ＭＩＨＦフレームの）ＭＩＨＦ可変ペイロードフィールドにペイロードがあるとき、フラグフィールド６２０は「１」に設定される。このシナリオにおいて、ＭＩＨＦフレームの合計長さは、｛［ＭＩＨＦ固定ヘッダの長さ（常に１５オクテット）］+［ＭＩＨＦ可変ロードの長さ］｝オクテット＝｛１５＋［タイプフィールドの長さ（常に４オクテット）］＋［長さフィールドを表すために使用されるオクテットの数］＋［長さフィールドによって示される値フィールドの長さ］｝オクテットとなる。これは、以前受信したメッセージの肯定応答を添付（「ピギーバック」）するために使用することができる。したがって、ペイロードも含むフレームに「ピギーバックされた」肯定応答があるという指示は、ＡＣＫ−ｒｓｐおよびフラグビットが「１」に設定されているときに生じる。
【００２６】
第２のシナリオにおいて、（ＭＩＨＦフレームの）ＭＩＨＦ可変ペイロードフィールドにペイロードがないとき、フラグフィールド６２０は「０」に設定される。この場合、ＭＩＨＦフレームの合計長さは、［ＭＩＨＦ固定ヘッダの長さ（常に１５オクテット）］となる。これは、ピアが肯定応答メッセージのみを含むＭＩＨＦフレームを送信する必要がある場合に特に有用である。
【００２７】
現在のＩＥＥＥ８０２．２１標準は、単独の肯定応答メッセージを区別していない。代わりに、現在のＩＥＥＥ８０２．２１標準は常に、添付された（「ピギーバックされた」）肯定応答メッセージングを使用する。したがって、ピアが、肯定応答メッセージのみを含むＭＩＨＦフレームを送る場合、ＡＣＫ−ｒｓｐは「１」に設定され、フラグビットは「０」に設定される。このシナリオにおいて、ＭＩＨＦ可変ロードはデータを搬送せず、したがって存在しない。そのため、ＭＩＨＦフレームはＭＩＨＦ固定ヘッダのみを含み、受信機は何らかのペイロードについて確認しようと試みない。
【００２８】
ＭＩＨＦ  ＩＤフィールド６２５は、ＭＩＨＦフレームが由来する送り側のＭＩＨＦ  ＩＤという、ＩＥＥＥ８０２．２１ですでに規定されているのと同じ役割を果たす。しかし、このフィールドは、ＩＥＥＥ８０２．２１の現在のＭＩＨＦ固定ヘッダには含まれていない。このヘッダにこのフィールドを有することの意義は、送信されるあらゆるメッセージの一意の識別に常に必要とされるであろうことである。したがって、ＴＬＶフォーマットで表される場合、これは他の目的のために使用することができる予備のビットを占有することになる。加えて、そのＴＬＶ表現は、メッセージのデコーディング中にさらに多くの手間とオーバーヘッドをもたらすことになろう。
【００２９】
セッションＩＤ６３０は、セッションの由来元によって生成された一意の識別子という、ＩＥＥＥ８０２．２１ですでに規定されているのと同じ機能を有する。しかし、メッセージの送り側を一意に定義するために、セッションＩＤが必要となる。同様に、このＩＤをＭＩＨＦ固定ヘッダに有することにより、ＴＬＶフォーマットで表現するのとは対照的に、ビットを節減し、メッセージのデコーディングを増進する。
【００３０】
可変ロード長さフィールドは、ＭＩＨＦ固定ヘッダから除去される。このフィールドの役割は、ＭＩＨＦ可変ペイロードフィールドの長さを示すことであり、１６ビットで構成されていた。しかし、たとえ可変ロード長さが存在しない場合であっても、ＭＩＨＦ可変ペイロードフィールドの長さは依然として次のように計算することができる｛［タイプフィールドの長さ（常に４オクテット）］+［長さフィールドを表すために使用されるオクテットの数］＋［長さフィールドによって示される値フィールドの長さ］｝オクテット。したがって、ＭＩＨＦ可変ペイロードの長さのような情報を失うことなく、１６ビットを節減することができる。ＭＩＨＦ固定ヘッダの残りのフィールドは、上記の表１により説明される。
【００３１】
ＭＩＨＦフレームフォーマットのＭＩＨＦ可変ロード部分は、サービス固有ＴＬＶのみを含む。これはもはや、ＭＩＨＦ可変ヘッダを含まない。以下は、本発明のＭＩＨＦフレームの例示的な実装形態である。
【００３２】
特定のＩＥを取り出すために、たとえば、クライアントは、情報リクエスト（すなわち、クエリ）をＭＩＨサービスポイント（ＰｏＳ）に送る。情報リクエストは、ＩＥに対するクエリを含む。ＭＩＨ  ＰｏＳは、情報リクエストのレスポンスを含む情報レスポンスをクライアントに送り返す。
【００３３】
図７は、ＩＥをリクエストするための例示的なＭＩＨＦリクエストフレーム７００を示している。ＩＥＥＥ８０２．２１対応のエンティティは、（たとえば、ＴＹＰＥ＿ＩＥ＿ＬＩＳＴ＿ＯＦ＿ＯＰＥＲＡＴＯＲＳ＿ＲＥＱＵＥＳＴを使用して）オペレータのリストのような特定のＩＥをリクエストする。ＭＩＨＦリクエストフレーム７００は、ＭＩＨＦ固定ヘッダ７０５およびＭＩＨＦ可変ロード７１０を含む。
【００３４】
図７に示されるＭＩＨＦリクエストフレーム７００のＭＩＨＦ固定ヘッダ７０５のフィールドにより含まれている「ｘｘｘ」は、単に、リクエストフレーム７００の実施形態に影響を及ぼすことなくビットが任意の値を有することができることを暗示している。ＭＩＨメッセージＩＤフィールド７１５は、サービスＩＤフィールド７２０、オペレーションコード（ｏｐｃｏｄｅ）フィールド７２５、およびアクションＩＤフィールド７３０の組合せである。
【００３５】
サービスＩＤフィールド７２０は、異なるＭＩＨサービスを識別し、以下の値を有する。
１＝Ｓｙｓｔｅｍ Ｍａｎａｇｅｍｅｎｔ（システム管理）
２＝Ｅｖｅｎｔ  Ｓｅｒｖｉｃｅ（イベントサービス）
３＝Ｃｏｍｍａｎｄ  Ｓｅｒｖｉｃｅ（コマンドサービス）
４＝Ｉｎｆｏｒｍａｔｉｏｎ  Ｓｅｒｖｉｃｅ（情報サービス）
【００３６】
図７に示されているように、サービスＩＤフィールド７２０は、バイナリビット「０１００」で表される４の１０進値を有する。この値は、ＭＩＨＦ可変ロード７１０で搬送されるペイロードが情報サービスに関連することを示す。
【００３７】
オペレーションコード（ｏｐｃｏｄｅ）フィールド７２５は、サービスＩＤ７２０に関して行われるべきオペレーションのタイプを示し、以下の値を有する。
１＝Ｒｅｑｕｅｓｔ（リクエスト）
２＝Ｒｅｓｐｏｎｄ（レスポンス）
３＝Ｉｎｄｉｃａｔｉｏｎ（指示）
【００３８】
図示されているように、オペレーションコード（ｏｐｃｏｄｅ）フィールド７２５は、１の値によって表され、ペイロードが問題となっているサービスＩＤのリクエストであることを示す。
【００３９】
アクションＩＤフィールド７３０は、サービスＩＤフィールド７２０に関して取られるべきアクションを示す。
【００４０】
図示されているフラグフィールド７３５は、ＭＩＨＦ可変ロードがデータを含むことを示す「１」に設定される。
【００４１】
ＭＩＨＦフレーム７００のリクエストメッセージ部分のＭＩＨＦ可変ロード７１０は、タイプフィールド７４０、長さフィールド７４５、および値フィールド７５０によって定義されたＩＥリクエストのＴＬＶ表現を含む。
【００４２】
タイプフィールド７４０は、ＩＥのタイプの値を含む。図７に示される例において、タイプフィールド７４０は、ＩＥＥＥ８０２．２１で規定され、「０×１００００００３」（４オクテット）の値を持つ１６進法で表される。これは、問題となっているＩＥのタイプが、特定のリンクタイプのオペレータのリストであることを意味し、これはＴＬＶの値フィールドで指定される（「ｘｘｘ．．．」）。
【００４３】
長さフィールド７４５は、そのＭＳＢを値フィールドの長さが１２８オクテットよりも小さいことを意味する「０」に設定されている。値フィールドの正確な長さは、４の１０進値を有する残りの７ビットによって表される。そのため、値フィールドの長さは４オクテットである。
【００４４】
値フィールド７５０は、オペレータのリストを取得することが要求される特定のリンクタイプを含む。値フィールド７５０は、問題となっているＩＥに応じて、固定または可変の長さにすることができる。この例の場合、このフィールドの長さが４オクテットに固定されることがＩＥＥＥ８０２．２１で規定されている。これは、任意の定義された値を表すことができるので、「ｘｘｘ．．．」によって表される。
【００４５】
図８は、ＭＩＨＦリクエストフレーム７００に応答してＩＥを提供する例示的なＭＩＨＦレスポンスフレーム８００を示している。リクエストメッセージの受信機がそれに応じてＭＩＨＦフレームをデコードし、（たとえば、ＴＹＰＥ＿ＩＥ＿ＬＩＳＴ＿ＯＦ＿ＯＰＥＲＡＴＯＲＳ＿ＲＥＳＰＯＮＳＥを使用して）応答することが仮定される。ＭＩＨＦレスポンスフレーム８００は、ＭＩＨＦ固定ヘッダ８０５およびＭＩＨＦ可変ロード８１０を含む。ＭＩＨＦレスポンスフレーム８００は、（特定のリンクタイプの）オペレータＩＥのリストのリクエストに対するレスポンスを示す。
【００４６】
図８に示されるＭＩＨＦレスポンスフレーム８００のＭＩＨＦ固定ヘッダ８０５のフィールドにより含まれている「ｘｘｘ」は、単に、レスポンスフレーム８００の実装形態に影響を及ぼすことなくビットが任意の値を有することができることを暗示している。ＭＩＨメッセージＩＤフィールド８１５は、サービスＩＤフィールド８２０、オペレーションコード（ｏｐｃｏｄｅ）フィールド８２５、およびアクションＩＤフィールド８３０の組合せである。
【００４７】
ＡＣＫ−ｒｅｑフィールド８３５は、（ＩＥＥＥ８０２．２１で規定されているように）ピアがこのメッセージの受信を肯定応答すべきことを示す「１」に設定されたビットを有する。
【００４８】
フラグフィールド８４０は、ＭＩＨＦ可変ロードがデータを含むことを示す「１」に設定されたビットを有する。
【００４９】
サービスＩＤビット８２０は、ビットで表される４の１０進値を有する。この値は、ＭＩＨＦフレームで搬送されるペイロードが情報サービスに関連することを示す。
【００５０】
オペレーションコード（ｏｐｃｏｄｅ）フィールド８２５は、２の１０進値によって表されて、ペイロードが問題となっているサービスＩＤのレスポンスであることを示す。
【００５１】
アクションＩＤフィールド８３０は、サービスＩＤフィールド８２０に関して取られるべきアクションを示す。
【００５２】
レスポンスメッセージフィールドのＭＩＨＦ可変ロード８１０は、以下で説明される３つのフィールドを有する。
【００５３】
タイプフィールド８４５は、ＩＥのタイプの値を含む。この例において、ＩＥＥＥ８０２．２１で規定されているように、「０ｘ１００００００３」（４オクテット）の値を持つ１６進法で表される。これは、問題となっているＩＥのタイプが、（リクエストメッセージのＴＬＶの値フィールドで指定された）特定のリンクタイプのオペレータのリストであることを意味する。
【００５４】
長さフィールド８５０は、そのＭＳＢを値フィールドの長さが１２８オクテットよりも大きいことを意味する「１」に設定されている。このフィールドの第１のオクテットの残りの７ビットは、２つの長さフィールドのオクテットがさらに付加される（１６ビット）ことを示す。これらの１６ビットによって表される１０進値は４０３である。そのため、値フィールドの合計長さは１２８＋４０３＝５３１オクテットである。
【００５５】
値フィールド８５５は、ペイロードを含む。ＩＥＥＥ８０２．２１の仕様によれば、このフィールドは、２つの部分で構成される。すなわち、（特定のリンクタイプの）オペレータの数に続いてオペレータ識別子となる。
【００５６】
オペレータの数フィールド８６０は、ＩＥＥＥ８０２．２１によって規定されているように４オクテットによって表される。この例のために、問題となっているリンクタイプのオペレータの数は、２となるように選ばれる。この値は、図９に示されるＭＩＨＦ可変ロードの値フィールド９１５の最初の４つのオクテットとして示される。
【００５７】
オペレータ識別子は、ＴＬＶフォーマットで表される。各々は、最初に構築されてから、オペレータ識別子の数の後の値フィールドに追加される別個のＩＥとして取り扱われる。したがって、２つの独立したオペレータ識別子ＴＬＶ８６５および８７０が存在する。ＴＬＶ８６５および８７０は、構造は同様であるが、内容および長さは異なり得る。オペレータ名がまだ定義されていないので、これは仮定されていることに留意されたい。２つのＴＬＶ８６５および８７０は、（ＭＩＨＦ可変ロード８１０にある）値フィールド８５５のオペレータの数に付加される。各ＴＬＶ８６５および８７０は、タイプフィールドに同じ値を有するが、長さフィールドおよび値フィールドは異なり得る。したがって、付加されたＴＬＶ８６５および８７０のタイプフィールドが除去されるよう示唆される可能性があろう。したがって、レスポンスフレーム８００の値フィールド８５５は、このためオペレータの数の４オクテット、第１のオペレータ識別子ＴＬＶ８６５の長さフィールドに続いてその値フィールド、および第２のオペレータ識別子ＴＬＶ８７０の長さフィールドに続いて値フィールドを含むであろう。ときに付加されるべきＴＬＶが異なり、そのためそのタイプフィールドが要求されるので、すべてのＩＥリクエストまたはレスポンスについて、これを行うことができるわけではないことに留意されたい。
【００５８】
図９は、オペレータ識別子ＩＥ９００の例示的なＴＬＶ表現を示している。タイプフィールド９０５は、ＩＥのタイプの値を含む。この例において、ＩＥＥＥ８０２．２１で規定されているように、「０ｘ１００００００４」（４オクテット）の値を持つ１６進法で表される。これは、問題となっているＩＥのタイプがオペレータ識別子であることを意味する。長さフィールド９１０は、そのＭＳＢを値フィールド９１５の長さが１２８オクテットよりも大きいことを示す「１」に設定されている。長さフィールド９１０の第１のオクテットの残りの７ビットは、１つの長さフィールドのオクテットがさらに付加される（８ビット）ことを示す。これらの８ビットによって表される１０進値は１２６である。そのため、値フィールド９１５の合計長さは１２８＋１２６＝２５４オクテットである。
【００５９】
値フィールド９１５は、オペレータネームスペースフィールド９２０に続いてオペレータ名前フィールド９２５を含む。オペレータネームスペースフィールド９２０は、ＩＥＥＥ８０２．２１で規定されているように１オクテットの長さを有する。オペレータ名前フィールド９２５は、問題となっているオペレータの名前の値を含む。オペレータ名前フィールド９２５は、（ＩＥＥＥ８０２．２１標準によって規定されているように）長さが２５３オクテットを超えないものとする非ヌルの終端ストリングである。フィールド９２５は「ｘｘ．．．．ｘｘ」を含むように示されており、可能な値はＩＥＥＥ８０２．２１標準でまだ定義されていないので、これは任意の値を表すために使用される。したがって、オペレータ名前フィールド９２５は、まさにこの例のために、最大長さ、すなわち２５３オクテットを有するものと仮定されている。
【００６０】
受信機がＭＩＨＦレスポンスメッセージを受信したとき、受信機はそれに応じてフレームをデコードし、ＡＣＫ−ｒｅｑビットがピアによって「１」に設定されたことを認識する。本発明によれば、次いで受信機は、図１０に示されるように、肯定応答メッセージ１０００を含むフレームを送信し、これはＭＩＨＦ固定ヘッダ１００５のみを含む。ＭＩＨＦ固定ヘッダ１００５において、ＡＣＫ−ｒｓｐビット１０１０は、このフレームが以前のメッセージの肯定応答を含むことを示す「１」に設定される。さらに、フラグビット１０１５は、ＭＩＨＦ可変ロードにペイロードがない（つまり不在）ことを示す「０」に設定される。したがって、このフレームは肯定応答メッセージのみを含む。
【００６１】
残りのフィールド、およびそれらが含むべき値は、ＩＥＥＥ８０２．２１標準により規定される。したがって、受信機は、フラグビット１０１５を確認することにより、純粋な肯定応答メッセージを区別することができる。
【００６２】
図１１は、本発明による構成された第１の送受信機１１０５および第２の送受信機１１１０を含む無線通信システム１１００を示している。第１の送受信機１１０５および第２の送受信機１１１０は、無線送信／受信ユニット（ＷＴＲＵ）、基地局などにすることができる。代替として、たとえば、物理接続としてイーサネット（登録商標）を使用して、有線通信システムを実装することができる。
【００６３】
図１１に示されているように、第１の送受信機１１０５は第１のアンテナ１１１５を含み、第２の送受信機１１１０は第２のアンテナ１１２０を含む。第１の送受信機１１０５は、第１のアンテナ１１１５を介して、ＭＩＨＦリクエストフレーム１１２５を第２の送受信機１１１０に送る。ＭＩＨＦリクエストフレーム１１２５は、ＭＩＨＦ固定ヘッダおよびＭＩＨＦ可変ロードを含む。ＭＩＨＦリクエストフレーム１１２５のＭＩＨＦ可変ロードは、ＭＩＨＦ可変ヘッダを含まない。第２の送受信機１１１０は、ＭＩＨＦリクエストフレーム１１２５を受信することに応答して、第２のアンテナ１１２０を介して、ＭＩＨＦレスポンスフレーム１１３０を第１の送受信機１１０５に送る。ＭＩＨＦレスポンスフレーム１１３０は、ＭＩＨＦ固定ヘッダおよびＭＩＨＦ可変ロードを含む。ＭＩＨＦレスポンスフレーム１１３０のＭＩＨＦ可変ロードは、ＭＩＨＦ可変ヘッダを含まない。
【００６４】
送受信機１１０５はさらに、ＭＩＨＦリクエストフレーム１１２５およびＭＩＨＦレスポンスフレーム１１３０を送信するための送信機１１３５、ＭＩＨＦリクエストフレーム１１２５およびＭＩＨＦレスポンスフレーム１１３０を受信するための受信機１１４０、およびＭＩＨＦリクエストフレーム１１２５およびＭＩＨＦレスポンスフレーム１１３０を生成するためのプロセッサ１１４５を含む。
【００６５】
送受信機１１１０はさらに、ＭＩＨＦリクエストフレーム１１２５およびＭＩＨＦレスポンスフレーム１１３０を送信するための送信機１１５０、ＭＩＨＦリクエストフレーム１１２５およびＭＩＨＦレスポンスフレーム１１３０を受信するための受信機１１５５、およびＭＩＨＦリクエストフレーム１１２５およびＭＩＨＦレスポンスフレーム１１３０を生成するためのプロセッサ１１６０を含む。
【００６６】
（実施形態）
１．  第１の送受信機および第２の送受信機を含む通信システムにおいて、第１の送受信機がＭＩＨ機能（ＭＩＨＦ）リクエストフレームを第２の送受信機に送信することを備える、メディア独立ハンドオーバー（ＭＩＨ）メッセージを通信する方法であって、ＭＩＨＦリクエストフレームが固定ヘッダおよび可変ロードを含み、可変ロードは可変ヘッダを含まないことを特徴とする方法。
２．  第２の送受信機がＭＩＨＦリクエストフレームを受信することに応答してＭＩＨＦレスポンスフレームを第１の送受信機に送ることをさらに備えることを特徴とする実施形態１に記載の方法。
３．  固定ヘッダは、ＭＩＨＦ識別（ＩＤ）フィールドを含むことを特徴とする実施形態１および２のいずれかに記載の方法。
４．  固定ヘッダは、セッション識別（ＩＤ）フィールドを含むことを特徴とする実施形態１〜３のいずれかに記載の方法。
５．  固定ヘッダは、フラグフィールドを含むことを特徴とする実施形態１〜４のいずれかに記載の方法。
６．  フラグフィールドを１に設定して、ペイロードを含むＭＩＨＦリクエストフレームにピギーバックされた肯定応答があることを示すことをさらに備えることを特徴とする実施形態５に記載の方法。
７．  フラグフィールドを０に設定して、可変ペイロードフィールドにペイロードがないことを示すことをさらに備えることを特徴とする実施形態５に記載の方法。
８．  可変ロードは、タイプフィールド、長さフィールドおよび値フィールドを含むことを特徴とする実施形態１〜７のいずれかに記載の方法。
９．  値フィールドは、オペレータのリストを取得するための特定のリンクタイプを含むことを特徴とする実施形態８に記載の方法。
１０．  通信システムは、無線通信システムであり、第１の送受信機は、無線送信／受信ユニット（ＷＴＲＵ）であり、第２の送受信機は、基地局であることを特徴とする実施形態１〜９のいずれかに記載の方法。
１１．  通信システムは、無線通信システムであり、第１の送受信機は、基地局であり、第２の送受信機は、無線送信／受信ユニット（ＷＴＲＵ）であることを特徴とする実施形態１〜１０のいずれかに記載の方法。
１２．  通信システムは、イーサネット（登録商標）を使用して物理接続を提供する有線通信システムであることを特徴とする実施形態１〜１０のいずれかに記載の方法。
１３．  第１の送受信機および第２の送受信機を含む通信システムにおいて、メディア独立ハンドオーバー（ＭＩＨ）メッセージを通信する方法であって、
第１の送受信機がＭＩＨ機能（ＭＩＨＦ）リクエストフレームを第２の送受信機に送ることと、
第２の送受信機がＭＩＨＦリクエストフレームを受信することに応答してＭＩＨＦレスポンスフレームを第１の送受信機に送ることであって、ＭＩＨＦレスポンスフレームが固定ヘッダおよび可変ロードを含み、可変ロードは可変ヘッダを含まないことと
を備えることを特徴とする方法。
１４．  固定ヘッダは、ＭＩＨＦ識別（ＩＤ）フィールドを含むことを特徴とする実施形態１３に記載の方法。
１５．  固定ヘッダは、セッション識別（ＩＤ）フィールドを含むことを特徴とする実施形態１３および１４のいずれかに記載の方法。
１６．  固定ヘッダは、フラグフィールドを含むことを特徴とする実施形態１３〜１５のいずれかに記載の方法。
１７．  フラグフィールドを１に設定して、可変ロードがデータを含むことを示すことをさらに備えることを特徴とする実施形態１６に記載の方法。
１８．  フラグフィールドを０に設定して、可変ロードがデータを含まないことを示すことをさらに備えることを特徴とする実施形態１６に記載の方法。
１９．  可変ロードは、タイプフィールド、長さフィールドおよび値フィールドを含むことを特徴とする実施形態１３〜１８のいずれかに記載の方法。
２０．  値フィールドは、オペレータのリストを取得するための特定のリンクタイプを含むことを特徴とする実施形態１９に記載の方法。
２１．  通信システムは、無線通信システムであり、第１の送受信機は、無線送信／受信ユニット（ＷＴＲＵ）であり、第２の送受信機は、基地局であることを特徴とする実施形態１３〜２０のいずれかに記載の方法。
２２．  通信システムは、無線通信システムであり、第１の送受信機は、基地局であり、第２の送受信機は、無線送信／受信ユニット（ＷＴＲＵ）であることを特徴とする実施形態１３〜２０のいずれかに記載の方法。
２３．  通信システムは、イーサネット（登録商標）を使用して物理接続を提供する有線通信システムであることを特徴とする実施形態１３〜２０のいずれかに記載の方法。
２４．  第１の送受信機および第２の送受信機を含む通信システムにおいて、メディア独立ハンドオーバー（ＭＩＨ）メッセージを通信する方法であって、第１の送受信機がＭＩＨサービスデータ、またはタイプフィールド、長さフィールドおよび値フィールドによって表される可変ヘッダを含むＭＩＨ機能（ＭＩＨＦ）フレームを生成することであって、値フィールドの長さは正確に１２８オクテットであり、長さフィールドは１オクテットのみを占有することと、
第１の送受信機がＭＩＨＦフレームを第２の送受信機に送信することと
を備えることを特徴とする方法。
２５．  長さフィールドによって占有されるオクテットの最上位ビット（ＭＳＢ）は、１の値に設定され、ＭＳＢに続く長さフィールドによって占有されるオクテットの７つの残りのビットは、０の値に設定されることを特徴とする実施形態２４に記載の方法。
２６．  受信機と、
送信機と、
受信機および送信機に結合されたプロセッサであって、プロセッサがメディア独立ハンドオーバー機能（ＭＩＨＦ）リクエストフレームを生成するように構成され、ＭＩＨＦリクエストフレームが固定ヘッダおよび可変ロードを含み、可変ロードは可変ヘッダを含まず、送信機はプロセッサによって生成されたＭＩＨＦリクエストフレームを送信するプロセッサと
を備えたことを特徴とする送受信機。
２７．  固定ヘッダは、ＭＩＨＦ識別（ＩＤ）フィールドを含むことを特徴とする実施形態２６に記載の送受信機。
２８．  固定ヘッダは、セッション識別（ＩＤ）フィールドを含むことを特徴とする実施形態２６および２７のいずれかに記載の送受信機。
２９．  固定ヘッダは、フラグフィールドを含むことを特徴とする実施形態２６〜２８のいずれかに記載の送受信機。
３０．  プロセッサは、フラグフィールドを１に設定して、ペイロードを含むＭＩＨＦリクエストフレームにピギーバックされた肯定応答があることを示すことを特徴とする実施形態２９に記載の送受信機。
３１．  プロセッサは、フラグフィールドを０に設定して、可変ペイロードフィールドにペイロードがないことを示すことを特徴とする実施形態２６〜３０のいずれかに記載の送受信機。
３２．  可変ロードは、タイプフィールド、長さフィールドおよび値フィールドを含むことを特徴とする実施形態２６〜３１のいずれかに記載の送受信機。
３３．  値フィールドは、オペレータのリストを取得するための特定のリンクタイプを含むことを特徴とする実施形態３２に記載の送受信機。
３４．  送受信機は、無線送信／受信ユニット（ＷＴＲＵ）であることを特徴とする実施形態２６〜３３のいずれかに記載の送受信機。
３５．  送受信機は、有線送信／受信ユニットであることを特徴とする実施形態２６〜３３のいずれかに記載の送受信機。
３６．  送受信機は、基地局であることを特徴とする実施形態２６〜３３のいずれかに記載の送受信機。
３７．  メディア独立ハンドオーバー機能（ＭＩＨＦ）リクエストフレームを受信するように構成された受信機と、
送信機と、
受信機および送信機に結合されたプロセッサであって、プロセッサは受信機がＭＩＨＦリクエストフレームを受信することに応答してＭＩＨＦレスポンスフレームを生成するように構成され、ＭＩＨＦレスポンスフレームが固定ヘッダおよび可変ロードを含み、可変ロードは可変ヘッダを含まず、送信機はプロセッサによって生成されたＭＩＨＦレスポンスフレームを送信するプロセッサと
を備えたことを特徴とする送受信機。
３８．  固定ヘッダは、ＭＩＨＦ識別（ＩＤ）フィールドを含むことを特徴とする実施形態３７に記載の送受信機。
３９．  固定ヘッダは、セッション識別（ＩＤ）フィールドを含むことを特徴とする実施形態３７から３８のいずれかに記載の送受信機。
４０．  固定ヘッダは、フラグフィールドを含むことを特徴とする実施形態３７〜３９のいずれかに記載の送受信機。
４１．  プロセッサは、フラグフィールドを１に設定して、ペイロードを含むＭＩＨＦリクエストフレームにピギーバックされた肯定応答があることを示すことを特徴とする実施形態４０に記載の送受信機。
４２．  プロセッサは、フラグフィールドを０に設定して、可変ペイロードフィールドにペイロードがないことを示すことを特徴とする実施形態４１に記載の送受信機。
４３．  可変ロードは、タイプフィールド、長さフィールドおよび値フィールドを含むことを特徴とする実施形態３７〜４２のいずれかに記載の送受信機。
４４．  値フィールドは、オペレータのリストを取得するための特定のリンクタイプを含むことを特徴とする実施形態４３に記載の送受信機。
４５．  送受信機は、無線送信／受信ユニット（ＷＴＲＵ）であることを特徴とする実施形態３７〜４４のいずれかに記載の送受信機。
４６．  送受信機は、有線送信／受信ユニットであることを特徴とする実施形態３７〜４４のいずれかに記載の送受信機。
４７．  送受信機は、基地局であることを特徴とする実施形態３７〜４４のいずれかに記載の送受信機。
４８．  受信機と、
送信機と、
受信機および送信機に結合されたプロセッサであって、プロセッサはサービスデータ、またはタイプフィールド、長さフィールドおよび値フィールドによって表される可変ヘッダを含むメディア独立ハンドオーバー機能（ＭＩＨＦ）フレームを生成するように構成され、値フィールドの長さは正確に１２８オクテットであり、長さフィールドは１オクテットのみを占有し、送信機はプロセッサによって生成されたＭＩＨＦフレームを送信するプロセッサと
を備えたことを特徴とする送受信機。
４９．  長さフィールドによって占有されるオクテットの最上位ビット（ＭＳＢ）は、１の値に設定され、ＭＳＢに続く長さフィールドによって占有されるオクテットの７つの残りのビットは、０の値に設定されることを特徴とする実施形態４８に記載の送受信機。
【００６７】
本発明の特徴および要素は特定の組合せで好ましい実施形態において説明されるが、各特徴または要素は、好ましい実施形態の他の特徴および要素なしで単独で使用するか、または本発明のその他の特徴および要素のあるなしにかかわらずさまざまな組合せで使用することができる。本発明において提供される方法または流れ図は、汎用コンピュータまたはプロセッサによって実行されるためにコンピュータ可読記憶媒体で明確に具体化されたコンピュータプログラム、ソフトウェア、またはファームウェアにおいて実装することができる。コンピュータ可読記憶媒体の例は、読み取り専用メモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、レジスタ、キャッシュメモリ、半導体メモリデバイス、内蔵ハードディスクおよび取り外し可能ディスクなどの磁気媒体、磁気光学媒体、ＣＤ−ＲＯＭディスクなどの光媒体、およびデジタル多用途ディスク（ＤＶＤ）を含む。
【００６８】
適切なプロセッサは、例として、汎用プロセッサ、特殊用途プロセッサ、標準的なプロセッサ、デジタルシグナルプロセッサ（ＤＳＰ）、複数のマイクロプロセッサ、ＤＳＰコアと関連する１つまたは複数のマイクロプロセッサ、コントローラ、マイクロコントローラ、特殊用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）回路、任意の他のタイプの集積回路（ＩＣ）および／またはステートマシンを含む。
【００６９】
ソフトウェアと関連するプロセッサは、無線送受信ユニット（ＷＴＲＵ）、ユーザ機器（ＵＥ）、端末、基地局、無線ネットワークコントローラ（ＲＮＣ）、または任意のホストコンピュータにおける使用のために無線周波数送受信機を実装するのに使用することができる。ＷＴＲＵは、カメラ、ビデオカメラモジュール、テレビ電話、スピーカーフォン、振動デバイス、スピーカー、マイクロフォン、テレビ送受信機、ハンドフリーヘッドセット、キーボード、ブルートゥース（登録商標）モジュール、周波数変調（ＦＭ）無線ユニット、液晶ディスプレイ（ＬＣＤ）表示ユニット、有機発光ダイオード（ＯＬＥＤ；ｏｒｇａｎｉｃ  ｌｉｇｈｔ−ｅｍｉｔｔｉｎｇ  ｄｉｏｄｅ）表示ユニット、デジタル音楽プレイヤー、メディアプレイヤー、テレビゲームプレイヤーモジュール、インターネットブラウザ、および／または任意の無線ローカルエリアネットワーク（ＷＬＡＮ）モジュールなど、ハードウェアおよび／またはソフトウェアに実装されるモジュールと共に使用することができる。
【図１】
2009540749.tif 000004
【図２】
2009540749.tif 000005
【図３】
2009540749.tif 000006
【図４】
2009540749.tif 000007
【図５】
2009540749.tif 000008
【図６】
2009540749.tif 000009
【図７】
2009540749.tif 000010
【図８】
2009540749.tif 000011
【図９】
2009540749.tif 000012
【図１０】
2009540749.tif 000013
【図１１】
2009540749.tif 000014
【手続補正書】
【提出日】平成20年5月12日(2008.5.12)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
メディア独立ハンドオーバー（ＭＩＨ）メッセージを通信する方法であって、
ＭＩＨサービスデータ、またはタイプフィールド、長さフィールドおよび値フィールドによって表される可変ヘッダを含むＭＩＨ（ＭＩＨ）フレームを生成することであって、
前記値フィールドは正確に１２８オクテットであり、前記長さフィールドは１オクテットであり、前記長さフィールドの最上位ビット（ＭＳＢ）は１の値に設定され、前記ＭＳＢに続く前記長さフィールドの７つの残りのビットは０の値に設定されることと、
前記ＭＩＨフレームを送信することと
を備えることを特徴とする方法。
【請求項２】
サービスデータ、またはタイプフィールド、長さフィールドおよび値フィールドによって表される可変ヘッダを含むメディア独立ハンドオーバー（ＭＩＨ）フレームを生成するように構成されたプロセッサであって、前記値フィールドの長さは正確に１２８オクテットであり、前記長さフィールドは１オクテットのみを占有し、前記長さフィールドによって占有される前記オクテットの最上位ビット（ＭＳＢ）は１の値に設定され、前記ＭＳＢに続く前記長さフィールドによって占有される前記オクテットの７つの残りのビットは０の値に設定されるプロセッサと、
前記プロセッサによって生成された前記ＭＩＨフレームを送信するように構成された送信機と
を備えたことを特徴とする無線送信／受信ユニット（ＷＴＲＵ）。
【請求項３】
タイプフィールド、長さフィールドおよび値フィールドを有するメディア独立ハンドオーバー（ＭＩＨ）情報要素（ＩＥ）を作成する方法であって、
前記ＩＥの前記値フィールドに含まれるべきデータのオクテットの数を判定することと、
前記ＩＥの前記長さフィールドを設定することであって、
データのオクテットの前記数が１２８オクテットよりも少ないとき、前記長さフィールドは１オクテットの長さであり、前記長さフィールドの最上位ビット（ＭＳＢ）は０の値に設定され、前記ＭＳＢに続く前記長さフィールドの７つの残りのビットは前記ＩＥの前記値フィールドのデータのオクテットの前記数を示し、
データのオクテットの前記数が正確に１２８オクテットであるとき、前記長さフィールドは１オクテットの長さであり、前記長さフィールドの前記ＭＳＢは１の値に設定され、前記ＭＳＢに続く前記長さフィールドの７つの残りのビットは０の値に設定され、
データのオクテットの前記数が１２８オクテットよりも大きいとき、前記長さフィールドは１オクテットよりも大きく、前記長さフィールドの第１のオクテットの前記ＭＳＢは１の値に設定され、前記長さフィールドの前記第１のオクテットの７つの残りのビットは前記長さフィールドの追加のオクテットの数を示し、前記長さフィールドの前記追加のオクテットは、１２８の値に追加されるとき、前記ＩＥの前記値フィールドのデータのオクテットの前記数を示すことと
を備えることを特徴とする方法。
【請求項４】
データのオクテットの前記数が１２８オクテットよりも小さいとき、メディア独立ハンドオーバー（ＭＩＨ）情報要素（ＩＥ）長さフィールドを１オクテットの長さに設定し、前記長さフィールドの最上位ビット（ＭＳＢ）を０の値に設定し、前記ＭＳＢに続く前記長さフィールドの７つの残りのビットは前記ＩＥの値フィールドのデータのオクテットの数を示し、
データのオクテットの前記数が正確に１２８オクテットであるとき、前記ＭＩＨ  ＩＥ長さフィールドを１オクテットの長さに設定し、前記長さフィールドの前記ＭＳＢを１の値に設定し、前記ＭＳＢに続く前記長さフィールドの７つの残りのビットを０の値に設定し、
データのオクテットの前記数が１２８オクテットよりも大きいとき、前記ＭＩＨ  ＩＥ長さフィールドを１オクテットよりも大きく設定し、前記長さフィールドの第１のオクテットの前記ＭＳＢを１の値に設定し、前記長さフィールドの前記第１のオクテットの７つの残りのビットは前記長さフィールドの追加のオクテットの数を示し、前記長さフィールドの前記追加のオクテットは、１２８の値に追加されるとき、前記ＩＥの前記値フィールドのデータのオクテットの前記数を示すように設定されたプロセッサを備えたことを特徴とする無線送信／受信ユニット。
【請求項５】
前記プロセッサに結合され、前記ＭＩＨ  ＩＥを送信するように構成された送信機をさらに備えたことを特徴とする請求項４に記載のＷＴＲＵ。
【国際調査報告】
2009540749.tif 000015
2009540749.tif 000016
2009540749.tif 000017
2009540749.tif 000018
2009540749.tif 000019