JP7620092B2 - 無線ｌａｎシステムにおける送信ｍｌｄ内のａｐに対する部分情報を要求する方法及び装置 - Google Patents

Description

本明細書は無線ＬＡＮシステムにおいて多重リンク動作に関するものであり、より具体的には、送信ＭＬＤ内のＡＰに対する部分情報を要求する方法及び装置に関するものである。

ＷＬＡＮ（ｗｉｒｅｌｅｓｓ ｌｏｃａｌ ａｒｅａ ｎｅｔｗｏｒｋ）は様々な方法で改善されてきた。例えば、ＩＥＥＥ８０２．１１ａｘ規格はＯＦＤＭＡ（ｏｒｔｈｏｇｏｎａｌ ｆｒｅｑｕｅｎｃｙ ｄｉｖｉｓｉｏｎ ｍｕｌｔｉｐｌｅ ａｃｃｅｓｓ）及びＤＬ ＭＵ ＭＩＭＯ（ｄｏｗｎｌｉｎｋ ｍｕｌｔｉ－ｕｓｅｒ ｍｕｌｔｉｐｌｅ ｉｎｐｕｔ，ｍｕｌｔｉｐｌｅ ｏｕｔｐｕｔ）技術を用いて、改善された通信環境を提案した。

本明細書は新しい通信規格において活用できる技術的な特徴を提案する。例えば、新しい通信規格は最近議論になっているＥＨＴ（Ｅｘｔｒｅｍｅ ｈｉｇｈ ｔｈｒｏｕｇｈｐｕｔ）規格である。ＥＨＴ規格は新しく提案された帯域幅の増加、改善されたＰＰＤＵ（ＰＨＹ ｌａｙｅｒ ｐｒｏｔｏｃｏｌ ｄａｔａ ｕｎｉｔ）構造、改善されたシーケンス、ＨＡＲＱ（Ｈｙｂｒｉｄ ａｕｔｏｍａｔｉｃ ｒｅｐｅａｔ ｒｅｑｕｅｓｔ）技術などを使用できる。ＥＨＴ規格はＩＥＥＥ８０２．１１ｂｅ規格と呼べる。

新しい無線ＬＡＮ規格では増加された個数の空間ストリームが用いられる。この場合、増加された個数の空間ストリームを適切に使用するために無線ＬＡＮシステム内でのシグナリング技術を改善する必要がある。

本明細書は無線ＬＡＮシステムにおいて送信ＭＬＤ内のＡＰに対する部分情報を要求する方法及び装置を提案する。

本明細書の一例は送信ＭＬＤ内のＡＰに対する部分情報を要求する方法を提案する。

本実施形態は、次世代無線ＬＡＮシステム（ＩＥＥＥ８０２．１１ｂｅ又はＥＨＴ無線ＬＡＮシステム）がサポートされるネットワーク環境において実行される。前記次世代無線ＬＡＮシステムは８０２．１１ａｘシステムを改善した無線ＬＡＮシステムとして８０２．１１ａｘシステムと下位互換性（ｂａｃｋｗａｒｄｃｏｍｐａｔｉｂｉｌｉｔｙ）を満たすことができる。

本実施形態はＭＬＤ通信においてｎｏｎ－ＡＰ ＳＴＡがプローブ要求フレームを介してｐｅｅｒ ＡＰではない別のＡＰに対する部分情報を要求する場合、前記プローブ要求フレームの多重リンク要素に要求要素（Ｒｅｑｕｅｓｔ ｅｌｅｍｅｎｔ）を含め、前記要求要素に基づいて特定のＡＰに対する部分情報を要求する方法及び装置を提案する。ここで、送信ＭＬＤはＡＰ ＭＬＤに対応し、受信ＭＬＤはｎｏｎ－ＡＰ ＭＬＤに対応する。ｎｏｎ－ＡＰ ＳＴＡが第１受信ＳＴＡだとすれば、前記第１受信ＳＴＡと第１リンクに接続された第１送信ＳＴＡがｐｅｅｒ ＡＰであると言うことができ、別のリンクに接続された第２及び第３送信ＳＴＡは別のＡＰであると言うことができる。

受信ＭＬＤ（Ｍｕｌｔｉ－ｌｉｎｋ Ｄｅｖｉｃｅ）は送信ＭＬＤに第１リンクを介してプローブ要求フレームを送信する。

前記受信ＭＬＤは前記送信ＭＬＤから前記第１リンクを介してプローブ応答フレームを受信する。

前記送信ＭＬＤは前記第１リンクにおいて動作する第１送信ＳＴＡ（ｓｔａｔｉｏｎ）及び第２リンクにおいて動作する第２送信ＳＴＡを含む。前記受信ＭＬＤは前記第１リンクにおいて動作する第１受信ＳＴＡ及び前記第２リンクにおいて動作する第２受信ＳＴＡを含む。

前記プローブ要求フレームは前記第２受信ＳＴＡのプロファイルフィールドを含む。前記第２受信ＳＴＡのプロファイルフィールドは第１全体情報プロファイルサブフィールドを含む。

前記第１受信ＳＴＡが前記第２リンクに対する部分情報を要求する場合、前記第１全体情報プロファイルサブフィールドの値は０に設定される。前記第２受信ＳＴＡのプロファイルフィールドは第１要求要素（Ｒｅｑｕｅｓｔ ｅｌｅｍｅｎｔ）をさらに含む。このとき、前記第２リンクに対する部分情報は前記第１要求要素に基づいて要求される。

本明細書において提案された実施形態によれば、多重リンク要素に含まれた各受信ＳＴＡのプロファイルフィールドに要求要素を含めるか否かに対するインジケーターを設定し、前記要求要素に基づいて特定のＡＰに対する部分情報を要求する方法を提案することで、ｎｏｎ－ＡＰ ＭＬＤが別のリンクに対して常に全体情報ではない部分情報を要求することができ、そのためフレームオーバーヘッドを減らせる効果がある。

本明細書の送信装置及び／または受信装置の一例を示す。 無線ＬＡＮ（ＷＬＡＮ）の構造を示した概念図である。 通常のリンク設定（ｌｉｎｋ ｓｅｔｕｐ）過程を説明する図面である。 ＩＥＥＥ規格において用いられるＰＰＤＵの一例を示した図面である。 ＵＬ－ＭＵに係る動作を示す。 トリガーフレームの一例を示す。 トリガーフレームの共通情報（ｃｏｍｍｏｎ ｉｎｆｏｒｍａｔｉｏｎ）フィールドの一例を示す。 ユーザ情報（ｐｅｒ ｕｓｅｒ ｉｎｆｏｒｍａｔｉｏｎ）フィールドに含まれているサブフィールドの一例を示す。 ＵＯＲＡ技術の技術的な特徴を説明する。 本明細書に用いられるＰＰＤＵの一例を示す。 本明細書の送信装置及び／又は受信装置の変形例を示す。 非ＡＰ ＭＬＤの構造の例を示す。 Ｌｉｎｋ ｓｅｔｕｐプロセスを介してＡＰ ＭＬＤ及び非ＡＰ ＭＬＤが接続される例を示す。 Ｌｉｎｋが変更又は再接続される例を示す。 Ｌｉｎｋが変更又は再接続される具体的な例を示す。 ｌｉｎｋ変更又は再接続のためのＡＰ ＭＬＤ及び非ＡＰ ＭＬＤの動作を示す。 ｌｉｎｋ変更又は再接続のためのＡＰ ＭＬＤ及び非ＡＰ ＭＬＤの動作を示す。 ｌｉｎｋ変更又は再接続のためのＡＰ ＭＬＤ及び非ＡＰ ＭＬＤの動作を示す。 ｌｉｎｋ変更又は再接続のためのＡＰ ＭＬＤ及び非ＡＰ ＭＬＤの動作を示す。 ｏｔｈｅｒ ＡＰに関する情報を要求するための非ＡＰ ＭＬＤの動作を示す。 ＳＴＡ ｒａｔｉｏ ｐｅｒ Ｌｉｎｋの具体的な例を示す。 ｌｉｎｋ変更又は再接続のためのＡＰ ＭＬＤ及び非ＡＰ ＭＬＤの動作を示す。 ｌｉｎｋ変更又は再接続のためのＡＰ ＭＬＤ及び非ＡＰ ＭＬＤの動作を示す。 ｌｉｎｋ変更又は再接続のためのＡＰ ＭＬＤ及び非ＡＰ ＭＬＤの動作を示す。 Ｐｒｏｂｅ ｒｅｑｕｅｓｔ内に追加されたｍｕｌｔｉ－ｌｉｎｋ ｅｌｅｍｅｎｔの一例を示す。 ｍｕｌｔｉ－ｌｉｎｋ ｅｌｅｍｅｎｔにおいてＬｉｎｋ ｒａｎｇｅ ｆｉｅｌｄを使用する一例を示す。 Ｌｉｎｋの変更及び再接続を指示するために新しく提案したフィールドの一例を示す。 Ｒｅｑｕｅｓｔ ＩＥフォーマットの一例を示す。 Ｅｘｔｅｎｄｅｄ Ｒｅｑｕｅｓｔ ＩＥフォーマットの一例を示す。 ＰＶ １ Ｐｒｏｂｅ Ｒｅｓｐｏｎｓｅ Ｏｐｔｉｏｎ ｅｌｅｍｅｎｔフォーマットの一例を示す。 ＭＬＤ Ｒｅｑｕｅｓｔ ｅｌｅｍｅｎｔの一例を示す。 ＭＬＤ Ｒｅｑｕｅｓｔ ｅｌｅｍｅｎｔの他の例を示す。 ＭＬＤ Ｒｅｑｕｅｓｔ ｅｌｅｍｅｎｔに基づいて新規ｅｌｅｍｅｎｔを定義した一例を示す。 ＭＬＤ Ｒｅｑｕｅｓｔ ｅｌｅｍｅｎｔの他の例を示す。 ＭＬＤ Ｒｅｑｕｅｓｔ ｅｌｅｍｅｎｔの他の例を示す。 ＭＬＤ Ｒｅｑｕｅｓｔ ｅｌｅｍｅｎｔの他の例を示す。 ＭＬＤ Ｒｅｑｕｅｓｔ ｅｌｅｍｅｎｔの他の例を示す。 Ｃｏｍｍｏｎ情報を要求するフィールドの一例を示す。 ８０２．１１ｂｅで定義されたＭＬ ＩＥフォーマットの一例を示す。 ｍｕｌｔｉ－ｌｉｎｋ ｅｌｅｍｅｎｔフォーマットとＭｕｌｔｉ－ｌｉｎｋ Ｃｏｎｔｒｏｌ ｆｉｅｌｄフォーマットの一例を示す。 Ｍｕｌｔｉ－ｌｉｎｋ Ｃｏｎｔｒｏｌ ｆｉｅｌｄフォーマットの一例を示す。 ＭＬ ＩＥフォーマットの一例を示す。 ＭＬ ＩＥフォーマットの他の例を示す。 ＭＬ ＩＥフォーマットの他の例を示す。 ＭＬ ＩＥフォーマットの他の例を示す。 ＭＬ ＩＥフォーマットを含むＰｒｏｂｅ ｒｅｑｕｅｓｔ ｆｒａｍｅの一例を示す。 ＭＬ ＩＥフォーマットを含むＰｒｏｂｅ ｒｅｑｕｅｓｔ ｆｒａｍｅの他の例を示す。 ＭＬ ＩＥフォーマットを含むＰｒｏｂｅ ｒｅｑｕｅｓｔ ｆｒａｍｅの他の例を示す。 ＭＬ ＩＥフォーマットを含むＰｒｏｂｅ ｒｅｑｕｅｓｔ ｆｒａｍｅの他の例を示す。 Ｍｕｌｔｉ－ｌｉｎｋ Ｃｏｎｔｒｏｌ ｆｉｅｌｄフォーマットの一例を示す。 ＭＬ ＩＥフォーマットにＣｒｉｔｉｃａｌ ｕｐｄａｔｅ ｒｅｑｕｅｓｔ ｆｉｅｌｄが含まれる一例を示す。 Ｃｒｉｔｉｃａｌ ｕｐｄａｔｅ情報を要求する時、Ｃｈａｎｇｅ ｓｅｑｕｅｎｃｅ ｅｌｅｍｅｎｔを使用するＭＬＤ Ｐｒｏｂｅ ｒｅｑｕｅｓｔの一例を示す。 Ｃｒｉｔｉｃａｌ ｕｐｄａｔｅ情報を要求する時、Ｃｈａｎｇｅ ｓｅｑｕｅｎｃｅ ｅｌｅｍｅｎｔを使用するＭＬＤ Ｐｒｏｂｅ ｒｅｑｕｅｓｔの他の例を示す。 ＭＬ ＩＥフォーマットにＣｒｉｔｉｃａｌ ｕｐｄａｔｅ ｒｅｑｕｅｓｔ ｆｉｅｌｄが含まれる一例を示す。 ＭＬ ＩＥフォーマットにＣｈａｎｇｅ ｓｅｑｕｅｎｃｅ ｅｌｅｍｅｎｔが含まれる一例を示す。 ＭＬＤ Ｃｈａｎｇｅ Ｓｅｑｕｅｎｃｅフォーマットの一例を示す。 ＭＬＤ Ｃｈａｎｇｅ Ｓｅｑｕｅｎｃｅフォーマットの他の例を示す。 ＭＬＤ Ｃｈａｎｇｅ ｓｅｑｕｅｎｃｅ ｅｌｅｍｅｎｔの一例を示す。 既存の規格においてのＣｈａｎｇｅ ｓｅｑｕｅｎｃｅ ｅｌｅｍｅｎｔの一例を示す。 ＭＬ ＩＥフォーマットにＣｈａｎｇｅ ｓｅｑｕｅｎｃｅ ｅｌｅｍｅｎｔが含まれる他の例を示す。 Ｃｒｉｔｉｃａｌ ｕｐｄａｔｅ情報の要求のためのＰｒｏｂｅ ｒｅｑｕｅｓｔ ｆｒａｍｅの一例を示す。 Ｃｒｉｔｉｃａｌ ｕｐｄａｔｅ情報の要求のためのＰｒｏｂｅ ｒｅｑｕｅｓｔ ｆｒａｍｅの他の例を示す。 Ｃｒｉｔｉｃａｌ ｕｐｄａｔｅ情報の要求のためのＰｒｏｂｅ ｒｅｑｕｅｓｔ ｆｒａｍｅの他の例を示す。 Ｃｒｉｔｉｃａｌ ｕｐｄａｔｅ情報の要求のためのＰｒｏｂｅ ｒｅｑｕｅｓｔ ｆｒａｍｅの他の例を示す。 本実施形態に係る送信ＭＬＤが受信ＭＬＤにプローブ応答フレームに基づいて部分情報を提供する手順を示したフロー図である。 本実施形態に係る受信ＭＬＤが送信ＭＬＤにプローブ要求フレームに基づいて部分情報を要求する手順を示したフロー図である。

本明細書において「ＡまたはＢ（Ａ ｏｒ Ｂ）」は「ただＡ」、「ただＢ」または「ＡとＢの両方とも」を意味することができる。また、本明細書において「ＡまたはＢ（Ａ ｏｒ Ｂ）」は「Ａ及び／またはＢ（Ａ ａｎｄ／ｏｒ Ｂ）」と解釈されることができる。例えば、本明細書において「Ａ、ＢまたはＣ（Ａ、Ｂ ｏｒ Ｃ）」は「ただＡ」、「ただＢ」、「ただＣ」、または「Ａ、Ｂ及びＣの任意の全ての組み合わせ（ａｎｙ ｃｏｍｂｉｎａｔｉｏｎ ｏｆ Ａ、Ｂ ａｎｄ Ｃ）」を意味することができる。

本明細書で使われるスラッシュ（／）や読点（ｃｏｍｍａ）は「及び／または（ａｎｄ／ｏｒ）」を意味することができる。例えば、「Ａ／Ｂ」は「Ａ及び／またはＢ」を意味することができる。それによって、「Ａ／Ｂ」は「ただＡ」、「ただＢ」、または「ＡとＢの両方とも」を意味することができる。例えば、「Ａ、Ｂ、Ｃ」は「Ａ、ＢまたはＣ」を意味することができる。

本明細書において「少なくとも一つのＡ及びＢ（ａｔ ｌｅａｓｔ ｏｎｅ ｏｆ Ａ ａｎｄ Ｂ）」は、「ただＡ」、「ただＢ」または「ＡとＢの両方とも」を意味することができる。また、本明細書において「少なくとも一つのＡまたはＢ（ａｔ ｌｅａｓｔ ｏｎｅ ｏｆ Ａ ｏｒ Ｂ）」や「少なくとも一つのＡ及び／またはＢ（ａｔ ｌｅａｓｔ ｏｎｅ ｏｆ Ａ ａｎｄ／ｏｒ Ｂ）」という表現は「少なくとも一つのＡ及びＢ（ａｔ ｌｅａｓｔ ｏｎｅ ｏｆ Ａ ａｎｄ Ｂ）」と同様に解釈されることができる。

また、本明細書において「少なくとも一つのＡ、Ｂ及びＣ（ａｔ ｌｅａｓｔ ｏｎｅ ｏｆ Ａ、Ｂ ａｎｄ Ｃ）」は、「ただＡ」、「ただＢ」、「ただＣ」、または「Ａ、Ｂ及びＣの任意の全ての組み合わせ（ａｎｙ ｃｏｍｂｉｎａｔｉｏｎ ｏｆ Ａ、Ｂ ａｎｄ Ｃ）」を意味することができる。また、「少なくとも一つのＡ、ＢまたはＣ（ａｔ ｌｅａｓｔ ｏｎｅ ｏｆ Ａ、Ｂ ｏｒ Ｃ）」や「少なくとも一つのＡ、Ｂ及び／またはＣ（ａｔ ｌｅａｓｔ ｏｎｅ ｏｆ Ａ、Ｂ ａｎｄ／ｏｒ Ｃ）」は「少なくとも一つのＡ、Ｂ及びＣ（ａｔ ｌｅａｓｔ ｏｎｅ ｏｆ Ａ、Ｂ ａｎｄ Ｃ）」を意味することができる。

また、本明細書で使われる括弧は「例えば（ｆｏｒ ｅｘａｍｐｌｅ）」を意味することができる。具体的には、「制御情報（ＰＤＣＣＨ）」で表示された場合、「制御情報」の一例として「ＰＤＣＣＨ」が提案されたものである。また、本明細書の「制御情報」は「ＰＤＣＣＨ」に制限（ｌｉｍｉｔ）されずに、「ＰＤＤＣＨ」が「制御情報」の一例として提案されたものである。また、「制御情報（即ち、ＰＤＣＣＨ）」で表示された場合も、「制御情報」の一例として「ＰＤＣＣＨ」が提案されたものである。

本明細書において、一つの図面内で個別的に説明される技術的特徴は、個別的に具現されることもでき、同時に具現されることもできる。

本明細書の以下の一例は様々な無線通信システムに適用される。例えば、本明細書の以下の一例は無線ＬＡＮ（ｗｉｒｅｌｅｓｓ ｌｏｃａｌ ａｒｅａ ｎｅｔｗｏｒｋ，ＷＬＡＮ）システムに適用される。例えば、本明細書はＩＥＥＥ８０２．１１ａ／ｇ／ｎ／ａｃの規格や、ＩＥＥＥ８０２．１１ａｘ規格に適用される。また、本明細書は新しく提案されるＥＨＴ規格またはＩＥＥＥ８０２．１１ｂｅ規格にも適用される。また、本明細書の一例はＥＨＴ規格またはＩＥＥＥ８０２．１１ｂｅを改善（ｅｎｈａｎｃｅ）した新しい無線ＬＡＮ規格にも適用される。また、本明細書の一例は移動通信システムに適用される。例えば、３ＧＰＰ（登録商標）（３ｒｄ Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒｓｈｉｐ Ｐｒｏｊｅｃｔ）規格に基づくＬＴＥ（Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ）及びその進化（ｅｖｏｌｕａｔｉｏｎ）に基づく移動通信システムに適用される。また、本明細書の一例は３ＧＰＰ規格に基づく５ＧＮＲ規格の通信システムに適用される。

以下、本明細書の技術的な特徴を説明するために本明細書が適用される技術的な特徴を説明する。

図１は本明細書の送信装置及び／または受信装置の一例を示す。

図１の一例は以下で説明される様々な技術的な特徴を実行することができる。図１は少なくとも一つのＳＴＡ（ｓｔａｔｉｏｎ）に関連する。例えば、本明細書のＳＴＡ（１１０、１２０）は移動端末（ｍｏｂｉｌｅ ｔｅｒｍｉｎａｌ）、無線機器（ｗｉｒｅｌｅｓｓ ｄｅｖｉｃｅ）、無線送受信ユニット（Ｗｉｒｅｌｅｓｓ Ｔｒａｎｓｍｉｔ／Ｒｅｃｅｉｖｅ Ｕｎｉｔ；ＷＴＲＵ）、ユーザ装置（Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔ；ＵＥ）、移動局（Ｍｏｂｉｌｅ Ｓｔａｔｉｏｎ；ＭＳ）、移動加入者ユニット（Ｍｏｂｉｌｅ Ｓｕｂｓｃｒｉｂｅｒ Ｕｎｉｔ）または単にユーザ（ｕｓｅｒ）などの様々な名称として呼ばれる。本明細書のＳＴＡ（１１０、１２０）はネットワーク、基地局（Ｂａｓｅ Ｓｔａｔｉｏｎ）、Ｎｏｄｅ－Ｂ、ＡＰ（Ａｃｃｅｓｓ Ｐｏｉｎｔ）、リピータ、ルータ、リレーなどの様々な名称で呼ばれる。本明細書のＳＴＡ（１１０、１２０）は受信装置、送信装置、受信ＳＴＡ、送信ＳＴＡ、受信Ｄｅｖｉｃｅ、送信Ｄｅｖｉｃｅなど様々な名称で呼ばれる。

例えば、ＳＴＡ（１１０、１２０）はＡＰ（Ａｃｃｅｓｓ Ｐｏｉｎｔ）役割を実行するかｎｏｎ－ＡＰ役割を実行することができる。すなわち、本明細書のＳＴＡ（１１０、１２０）はＡＰ及び／またはｎｏｎ－ＡＰの機能を実行することができる。本明細書においてＡＰはＡＰ ＳＴＡとも表示できる。

本明細書のＳＴＡ（１１０、１２０）はＩＥＥＥ８０２．１１規格以外の様々な通信規格をともにサポートすることができる。例えば、３ＧＰＰ規格に係る通信規格（例えば、ＬＴＥ、ＬＴＥ－Ａ、５ＧＮＲ規格）などをサポートすることができる。また、本明細書のＳＴＡは携帯電話、車両（ｖｅｈｉｃｌｅ）、パーソナルコンピューターなどの様々な装置に実装される。また、本明細書のＳＴＡは音声通話、ビデオ通話、データ通信、自動走行（Ｓｅｌｆ－Ｄｒｉｖｉｎｇ，Ａｕｔｏｎｏｍｏｕｓ－Ｄｒｉｖｉｎｇ）などの様々な通信サービスのための通信をサポートすることができる。

本明細書においてＳＴＡ（１１０、１２０）はＩＥＥＥ８０２．１１規格の規定に従う媒体アクセス制御（ｍｅｄｉｕｍ ａｃｃｅｓｓ ｃｏｎｔｒｏｌ，ＭＡＣ）と無線媒体に対する物理層（Ｐｈｙｓｉｃａｌ Ｌａｙｅｒ）インターフェースを含むことができる。

図１（ａ）に基づいてＳＴＡ（１１０、１２０）を説明すると以下の通りである。

第１ＳＴＡ（１１０）はプロセッサ（１１１）、メモリ（１１２）及びトランシーバ（１１３）を含む。示されたプロセッサ、メモリ及びトランシーバはそれぞれ別のチップとして実装されるか、少なくとも二つ以上のブロック／機能が一つのチップを介して実装される。

第１ＳＴＡのトランシーバ（１１３）は信号の送受信動作を実行する。具体的には、ＩＥＥＥ８０２．１１パケット（例えば、ＩＥＥＥ８０２．１１ａ／ｂ／ｇ／ｎ／ａｃ／ａｘ／ｂｅなど）を送受信することができる。

例えば、第１ＳＴＡ（１１０）はＡＰの意図された動作を実行することができる。例えば、ＡＰのプロセッサ（１１１）はトランシーバ（１１３）を介して信号を受信し、受信信号を処理し、送信信号を生成し、信号送信のための制御を実行することができる。ＡＰのメモリ（１１２）はトランシーバ（１１３）を介して受信された信号（すなわち、受信信号）を格納することができ、トランシーバを介して送信される信号（すなわち、送信信号）を格納することができる。

例えば、第２ＳＴＡ（１２０）はＮｏｎ－ＡＰ ＳＴＡの意図された動作を実行することができる。例えば、ｎｏｎ－ＡＰのトランシーバ（１２３）は信号の送受信動作を実行する。具体的には、ＩＥＥＥ８０２．１１パケット（例えば、ＩＥＥＥ８０２．１１ａ／ｂ／ｇ／ｎ／ａｃ／ａｘ／ｂｅなど）を送受信することができる。

例えば、Ｎｏｎ－ＡＰ ＳＴＡのプロセッサ（１２１）はトランシーバ（１２３）を介して信号を受信し、受信信号を処理し、送信信号を生成し、信号送信のための制御を実行することができる。Ｎｏｎ－ＡＰ ＳＴＡのメモリ（１２２）はトランシーバ（１２３）を介して受信された信号（すなわち、受信信号）を格納することができ、トランシーバを介して送信される信号（すなわち、送信信号）を格納することができる。

例えば、以下の明細書においてＡＰと表示された装置の動作は第１ＳＴＡ（１１０）または第２ＳＴＡ（１２０）において実行される。例えば第１ＳＴＡ（１１０）がＡＰである場合、ＡＰと表示された装置の動作は第１ＳＴＡ（１１０）のプロセッサ（１１１）によって制御され、第１ＳＴＡ（１１０）のプロセッサ（１１１）によって制御されるトランシーバ（１１３）を介して関連する信号が送信されるか受信される。また、ＡＰの動作に関連する制御情報やＡＰの送信／受信信号は第１ＳＴＡ（１１０）のメモリ（１１２）に格納される。また、第２ＳＴＡ（１１０）がＡＰである場合、ＡＰと表示された装置の動作は第２ＳＴＡ（１２０）のプロセッサ（１２１）によって制御され、第２ＳＴＡ（１２０）のプロセッサ（１２１）によって制御されるトランシーバ（１２３）を介して関連する信号が送信されるか受信される。また、ＡＰの動作に関連する制御情報やＡＰの送信／受信信号は第２ＳＴＡ（１１０）のメモリ（１２２）に格納される。

例えば、以下の明細書においてｎｏｎ－ＡＰ（またはＵｓｅｒ－ＳＴＡ）と表示された装置の動作は第１ＳＴＡ（１１０）または第２ＳＴＡ（１２０）において実行される。例えば、第２ＳＴＡ（１２０）がｎｏｎ－ＡＰである場合、ｎｏｎ－ＡＰと表示された装置の動作は第２ＳＴＡ（１２０）のプロセッサ（１２１）によって制御され、第２ＳＴＡ（１２０）のプロセッサ（１２１）によって制御されるトランシーバ（１２３）を介して関連する信号が送信されるか受信される。また、ｎｏｎ－ＡＰの動作に関連する制御情報やＡＰの送信／受信信号は第２ＳＴＡ（１２０）のメモリ（１２２）に格納される。例えば、第１ＳＴＡ（１１０）がｎｏｎ－ＡＰである場合、ｎｏｎ－ＡＰと表示された装置の動作は第１ＳＴＡ（１１０）のプロセッサ（１１１）によって制御され、第１ＳＴＡ（１２０）のプロセッサ（１１１）によって制御されるトランシーバ（１１３）を介して関連する信号が送信されるか受信される。また、ｎｏｎ－ＡＰの動作に関連する制御情報やＡＰの送信／受信信号は第１ＳＴＡ（１１０）のメモリ（１１２）に格納される。

以下の明細書において（送信／受信）ＳＴＡ、第１ＳＴＡ、第２ＳＴＡ、ＳＴＡ１、ＳＴＡ２、ＡＰ、第１ＡＰ、第２ＡＰ、ＡＰ１、ＡＰ２、（送信／受信）Ｔｅｒｍｉｎａｌ、（送信／受信）Ｄｅｖｉｃｅ、（送信／受信）ａｐｐａｒａｔｕｓ、ネットワークなどと呼ばれる装置は図１のＳＴＡ（１１０、１２０）を意味する。例えば、具体的な符号なしに（送信／受信）ＳＴＡ、第１ＳＴＡ、第２ＳＴＡ、ＳＴＡ１、ＳＴＡ２、ＡＰ、第１ＡＰ、第２ＡＰ、ＡＰ１、ＡＰ２、（送信／受信）Ｔｅｒｍｉｎａｌ、（送信／受信）Ｄｅｖｉｃｅ、（送信／受信）ａｐｐａｒａｔｕｓ、ネットワークなどと表示された装置も図１のＳＴＡ（１１０、１２０）を意味する。例えば、以下の一例において様々なＳＴＡが信号（例えば、ＰＰＰＤＵ）を送受信する動作は図１のトランシーバ（１１３、１２３）において実行される場合がある。また、以下の一例において、様々なＳＴＡが送受信信号を生成するか送受信信号のために事前にデータ処理や演算を実行する動作は図１のプロセッサ（１１１、１２１）において実行される場合がある。例えば、送受信信号を生成するか送受信信号のために事前にデータ処理や演算を実行する動作の一例は、１）ＰＰＤＵ内に含まれるサブフィールド（ＳＩＧ，ＳＴＦ，ＬＴＦ，Ｄａｔａ）フィールドのビット情報を決定／獲得／構成／演算／デコード／エンコードする動作、２）ＰＰＤＵ内に含まれるサブフィールド（ＳＩＧ，ＳＴＦ，ＬＴＦ，Ｄａｔａ）フィールドのために用いられる時間リソースや周波数リソース（例えば、サブキャリアリソース）などを決定／構成／獲得する動作、３）ＰＰＤＵ内に含まれるサブフィールド（ＳＩＧ，ＳＴＦ，ＬＴＦ，Ｄａｔａ）フィールドのために用いられる特定のシーケンス（例えば、パイロットシーケンス、ＳＴＦ／ＬＴＦシーケンス、ＳＩＧに適用されるエクストラシーケンス）などを決定／構成／獲得する動作、４）ＳＴＡに対して適用される電力制御動作及び／または省電力動作、５）ＡＣＫ信号の決定／獲得／構成／演算／デコード／エンコードなどに関連する動作を含むことができる。また、以下の一例において様々なＳＴＡが送受信信号の決定／獲得／構成／演算／デコード／エンコードのために使用する様々な情報（例えば、フィールド／サブフィールド／制御フィールド／パラメータ／パワーなどに関連する情報）は図１のメモリ（１１２、１２２）に格納される。

上述した図１（ａ）の装置／ＳＴＡは図１（ｂ）のように変形される。以下の図１（ｂ）に基づいて、本明細書のＳＴＡ（１１０、１２０）を説明する。

例えば、図１（ｂ）に示されたトランシーバ（１１３、１２３）は上述した図１（ａ）に示されたトランシーバと同じ機能を実行することができる。例えば、図１（ｂ）に示されたプロセシングチップ（１１４、１２４）はプロセッサ（１１１、１２１）及びメモリ（１１２、１２２）を含むことができる。図１（ｂ）に示されたプロセッサ（１１１、１２１）及びメモリ（１１２、１２２）は上述した図１（ａ）に示されたプロセッサ（１１１、１２１）及びメモリ（１１２、１２２）と同じ機能を実行することができる。

以下で説明される、移動端末（ｍｏｂｉｌｅ ｔｅｒｍｉｎａｌ）、無線機器（ｗｉｒｅｌｅｓｓ ｄｅｖｉｃｅ）、無線送受信ユニット（Ｗｉｒｅｌｅｓｓ Ｔｒａｎｓｍｉｔ／Ｒｅｃｅｉｖｅ Ｕｎｉｔ；ＷＴＲＵ）、ユーザ装置（Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔ；ＵＥ）、移動局（Ｍｏｂｉｌｅ Ｓｔａｔｉｏｎ；ＭＳ）、移動加入者ユニット（Ｍｏｂｉｌｅ Ｓｕｂｓｃｒｉｂｅｒ Ｕｎｉｔ）、ユーザ（ｕｓｅｒ）、ユーザＳＴＡ、ネットワーク、基地局（Ｂａｓｅ Ｓｔａｔｉｏｎ）、Ｎｏｄｅ－Ｂ、ＡＰ（Ａｃｃｅｓｓ Ｐｏｉｎｔ）、リピータ、ルータ、リレー、受信装置、送信装置、受信ＳＴＡ、送信ＳＴＡ、受信Ｄｅｖｉｃｅ、送信Ｄｅｖｉｃｅ、受信Ａｐｐａｒａｔｕｓ、及び／または送信Ａｐｐａｒａｔｕｓは、図１（ａ）／（ｂ）に示されたＳＴＡ（１１０、１２０）を意味するか、図１（ｂ）に示されたプロセシングチップ（１１４、１２４）を意味する。すなわち、本明細書の技術的な特徴は、図１（ａ）／（ｂ）に示されたＳＴＡ（１１０、１２０）に実行できるか、図１（ｂ）に示されたプロセシングチップ（１１４、１２４）でのみ実行される場合がある。例えば、送信ＳＴＡが制御信号を送信する技術的な特徴は、図１（ａ）／（ｂ）に示されたプロセッサ（１１１、１２１）において生成された制御信号が図１（ａ）／（ｂ）に示されたトランシーバ（１１３、１２３）を介して送信される技術的な特徴として理解できる。または、送信ＳＴＡが制御信号を送信する技術的な特徴は、図１（ｂ）に示されたプロセシングチップ（１１４、１２４）においてトランシーバ（１１３、１２３）に伝送される制御信号が生成される技術的な特徴として理解できる。

例えば、受信ＳＴＡが制御信号を受信する技術的な特徴は、図１（ａ）に示されたトランシーバ（１１３、１２３）によって制御信号が受信される技術的な特徴として理解できる。または、受信ＳＴＡが制御信号を受信する技術的な特徴は、図１（ａ）に示されたトランシーバ（１１３、１２３）に受信された制御信号が図１（ａ）に示されたプロセッサ（１１１、１２１）によって獲得される技術的な特徴として理解できる。または、受信ＳＴＡが制御信号を受信する技術的な特徴は、図１（ｂ）に示されたトランシーバ（１１３、１２３）に受信された制御信号が図１（ｂ）に示されたプロセシングチップ（１１４、１２４）によって獲得される技術的な特徴として理解できる。

図１（ｂ）を参照すると、メモリ（１１２、１２２）内にソフトウェアコード（１１５、１２５）が含まれる。ソフトウェアコード（１１５、１２５）はプロセッサ（１１１、１２１）の動作を制御するｉｎｓｔｒｕｃｔｉｏｎが含まれる。ソフトウェアコード（１１５、１２５）は様々なプログラミング言語で含まれる。

図１に示されたプロセッサ（１１１、１２１）またはプロセシングチップ（１１４、１２４）はＡＳＩＣ（ａｐｐｌｉｃａｔｉｏｎ－ｓｐｅｃｉｆｉｃ ｉｎｔｅｇｒａｔｅｄ ｃｉｒｃｕｉｔ）、他のチップセット、論理回路及び／またはデータ処理装置を含むことができる。プロセッサはＡＰ（ａｐｐｌｉｃａｔｉｏｎ ｐｒｏｃｅｓｓｏｒ）である。例えば、図１に示されたプロセッサ（１１１、１２１）またはプロセシングチップ（１１４、１２４）はＤＳＰ（ｄｉｇｉｔａｌ ｓｉｇｎａｌ ｐｒｏｃｅｓｓｏｒ）、ＣＰＵ（ｃｅｎｔｒａｌ ｐｒｏｃｅｓｓｉｎｇ ｕｎｉｔ）、ＧＰＵ（ｇｒａｐｈｉｃｓ ｐｒｏｃｅｓｓｉｎｇ ｕｎｉｔ）、モデム（Ｍｏｄｅｍ；ｍｏｄｕｌａｔｏｒ ａｎｄ ｄｅｍｏｄｕｌａｔｏｒ）のうち、少なくとも一つを含むことができる。例えば、図１に示されたプロセッサ（１１１、１２１）またはプロセシングチップ（１１４、１２４）はＱｕａｌｃｏｍｍ（登録商標）によって製造されたＳＮＡＰＤＲＡＧＯＮ^ＴＭシリーズプロセッサ、Ｓａｍｓｕｎｇ（登録商標）によって製造されたＥＸＹＮＯＳ^ＴＭシリーズプロセッサ、Ａｐｐｌｅ（登録商標）によって製造されたＡシリーズプロセッサ、ＭｅｄｉａＴｅｋ（登録商標）によって製造されたＨＥＬＩＯ^ＴＭシリーズプロセッサ、ＩＮＴＥＬ（登録商標）によって製造されたＡＴＯＭ^ＴＭシリーズプロセッサまたはこれを改善（ｅｎｈａｎｃｅ）したプロセッサである。

本明細書においてアップリンクはｎｏｎ－ＡＰ ＳＴＡからＡＰ ＳＴＡへの通信のためのリンクを意味し、アップリンクを介してアップリンクＰＰＤＵ／パケット／信号などが送信される。また、本明細書においてダウンリンクはＡＰ ＳＴＡからｎｏｎ－ＡＰ ＳＴＡへの通信のためのリンクを意味し、ダウンリンクを介してダウンリンクＰＰＤＵ／パケット／信号などが送信される。

図２は無線ＬＡＮ（ＷＬＡＮ）の構造を示した概念図である。

図２の上部はＩＥＥＥ（ｉｎｓｔｉｔｕｔｅ ｏｆ ｅｌｅｃｔｒｉｃａｌ ａｎｄ ｅｌｅｔｒｏｎｉｃ ｅｎｇｉｎｅｅｒｓ）８０２．１１のインフラストラクチャーＢＳＳ（ｂａｓｉｃ ｓｅｒｖｉｃｅ ｓｅｔ）の構造を示す。

図２の上部を参照すると、無線ＬＡＮシステムは一つまたはそれ以上のインフラストラクチャーＢＳＳ（２００、２０５）（以下、ＢＳＳ）を含むことができる。ＢＳＳ（２００、２０５）は正常に同期を行って互いに通信できるＡＰ（ａｃｃｅｓｓ ｐｏｉｎｔ，２２５）及びＳＴＡ１（Ｓｔａｔｉｏｎ，２００－１）のようなＡＰとＳＴＡのセットとして、特定の領域を指す概念ではない。ＢＳＳ（２０５）は一つのＡＰ（２３０）に一つ以上の結合可能なＳＴＡ（２０５－１、２０５－２）を含めることができる。

ＢＳＳは少なくとも一つのＳＴＡ、配信サービス（ｄｉｓｔｒｉｂｕｔｉｏｎ Ｓｅｒｖｉｃｅ）を提供するＡＰ（２２５、２３０）及び多数のＡＰを繋げる配信システム（ｄｉｓｔｒｉｂｕｔｉｏｎ Ｓｙｓｔｅｍ，ＤＳ，２１０）を含むことができる。

配信システム（２１０）は複数のＢＳＳ（２００、２０５）を接続して拡張サービスセットであるＥＳＳ（ｅｘｔｅｎｄｅｄ ｓｅｒｖｉｃｅ ｓｅｔ，２４０）を実装することができる。ＥＳＳ（２４０）は一つまたは複数個のＡＰが配信システム（２１０）を介して接続されてできた一つのネットワークを指示する用語として使用される。一つのＥＳＳ（２４０）に含まれるＡＰは同じＳＳＩＤ（ｓｅｒｖｉｃｅ ｓｅｔ ｉｄｅｎｔｉｆｉｃａｔｉｏｎ）を持つ。

ポータル（ｐｏｒｔａｌ，２２０）は無線ＬＡＮネットワーク（ＩＥＥＥ８０２．１１）と他のネットワーク（例えば、８０２．Ｘ）との接続を実行するブリッジ役割を実行することができる。

図２の上部のようなＢＳＳではＡＰ（２２５、２３０）の間のネットワーク及びＡＰ（２２５、２３０）とＳＴＡ（２００－１、２０５－１、２０５－２）の間のネットワークが実装される。しかし、ＡＰ（２２５、２３０）なしにＳＴＡ間でもネットワークを設定して通信を行うこともできる。ＡＰ（２２５、２３０）なしにＳＴＡ間でもネットワークを設定して通信を行うネットワークをアドホックネットワーク（Ａｄ－Ｈｏｃ ｎｅｔｗｏｒｋ）または独立ＢＳＳ（ｉｎｄｅｐｅｎｄｅｎｔ ｂａｓｉｃ ｓｅｒｖｉｃｅ ｓｅｔ，ＩＢＳＳ）と定義する。

図２の下部はＩＢＳＳを示した概念図である。

図２の下部を参照すると、ＩＢＳＳはアドホックモードに動作するＢＳＳである。ＩＢＳＳはＡＰを含まないため中央において管理機能を実行するエンティティ（ｃｅｎｔｒａｌｉｚｅｄ ｍａｎａｇｅｍｅｎｔ ｅｎｔｉｔｙ）がない。すなわち、ＩＢＳＳにおいてＳＴＡ（２５０－１、２５０－２、２５０－３、２５５－４、２５５－５）は分散方法（ｄｉｓｔｒｉｂｕｔｅｄ ｍａｎｎｅｒ）で管理される。ＩＢＳＳでは全てのＳＴＡ（２５０－１、２５０－２、２５０－３、２５５－４、２５５－５）が移動ＳＴＡで構成され、配信システムへの接続が許可されず自己完備ネットワーク（ｓｅｌｆ－ｃｏｎｔａｉｎｅｄ ｎｅｔｗｏｒｋ）を構成する。

図３は通常のリンク設定（ｌｉｎｋ ｓｅｔｕｐ）過程を説明する図面である。

示されたＳ３１０ステップにおいてＳＴＡはネットワークを見つける動作を実行することができる。ネットワークを見つける動作はＳＴＡのスキャニング（ｓｃａｎｎｉｎｇ）動作を含むことができる。すなわち、ＳＴＡがネットワークにアクセスするためには参加可能なネットワークを見つける必要がある。ＳＴＡは無線ネットワークに参加する前に互換性のあるネットワークを識別する必要があるが、特定の領域に存在するネットワークの識別過程をスキャニングという。スキャニング方法にはアクティブスキャン（ａｃｔｉｖｅ ｓｃａｎｎｉｎｇ）とパシップスキャン（ｐａｓｓｉｖｅ ｓｃａｎｎｉｎｇ）がある。

図３では例示的に、アクティブスキャン過程を含むネットワークを見つける動作を示す。アクティブスキャンにおいてスキャニングを行うＳＴＡはチャネルを移動させ周辺にどのＡＰが存在するか探索するためにプローブ要求フレーム（ｐｒｏｂｅ ｒｅｑｕｅｓｔ ｆｒａｍｅ）を送信しこれに対する応答を待つ。応答者（ｒｅｓｐｏｎｄｅｒ）はプローブ要求フレームを送信したＳＴＡへプローブ要求フレームに対する応答にプローブ応答フレーム（ｐｒｏｂｅ ｒｅｓｐｏｎｓｅ ｆｒａｍｅ）を送信する。ここで、応答者はスキャニングされているチャネルのＢＳＳにおいて最後にビーコンフレーム（ｂｅａｃｏｎ ｆｒａｍｅ）を送信したＳＴＡである。ＢＳＳではＡＰがビーコンフレームを送信するためＡＰが応答者になり、ＩＢＳＳではＩＢＳＳ内のＳＴＡが戻ってビーコンフレームを送信するため、応答者が一定ではない。例えば、１番チャネルにおいてプローブ要求フレームを送信し１番チャネルにおいてプローブ応答フレームを受信したＳＴＡは、受信したプローブ応答フレームに含まれたＢＳＳ関連情報を格納し次のチャネル（例えば、２番チャネル）に移動して同じ方法にスキャニング（すなわち、２番チャネル上においてプローブ要求／応答送受信）を実行することができる。

図３の一例と表示されてはいないが、スキャニング動作はパシップスキャン方法で実行される場合もある。パシップスキャンに基づいてスキャニングを行うＳＴＡはチャネルを移動しながらビーコンフレームを待つことができる。ビーコンフレームはＩＥＥＥ８０２．１１において管理フレーム（ｍａｎａｇｅｍｅｎｔ ｆｒａｍｅ）のうちの一つとして、無線ネットワークの存在を知らせ、スキャニングを行うＳＴＡに無線ネットワークを見つけて、無線ネットワークに参加できるように周期的に送信される。ＢＳＳにおいてＡＰがビーコンフレームを周期的に送信する役割を実行し、ＩＢＳＳではＩＢＳＳ内のＳＴＡが戻ってビーコンフレームを送信する。スキャニングを行うＳＴＡはビーコンフレームを受信すればビーコンフレームに含まれたＢＳＳに対する情報を格納し、他のチャネルに移動しながら各チャネルにおいてビーコンフレーム情報を記録する。ビーコンフレームを受信したＳＴＡは、受信したビーコンフレームに含まれたＢＳＳ関連情報を格納し、次のチャネルに移動して同じ方法で次のチャネルにおいてスキャニングを行うことができる。

ネットワークを発見したＳＴＡは、ステップＳ３２０を介して認証過程を実行することができる。このような認証過程は後述するステップＳ３４０のセキュリティ設定動作と明確に区分するために第１認証（ｆｉｒｓｔ ａｕｔｈｅｎｔｉｃａｔｉｏｎ）過程と称する。Ｓ３２０の認証過程は、ＳＴＡが認証要求フレーム（ａｕｔｈｅｎｔｉｃａｔｉｏｎ ｒｅｑｕｅｓｔ ｆｒａｍｅ）をＡＰへ送信し、これに応答してＡＰが認証応答フレーム（ａｕｔｈｅｎｔｉｃａｔｉｏｎ ｒｅｓｐｏｎｓｅ ｆｒａｍｅ）をＳＴＡへ送信する過程を含むことができる。認証要求／応答に用いられる認証フレーム（ａｕｔｈｅｎｔｉｃａｔｉｏｎ ｆｒａｍｅ）は管理フレームに該当する。

認証フレームは認証アルゴリズム番号（ａｕｔｈｅｎｔｉｃａｔｉｏｎ ａｌｇｏｒｉｔｈｍ ｎｕｍｂｅｒ）、認証取引シーケンス番号（ａｕｔｈｅｎｔｉｃａｔｉｏｎ ｔｒａｎｓａｃｔｉｏｎ ｓｅｑｕｅｎｃｅ ｎｕｍｂｅｒ）、ステータスコード（ｓｔａｔｕｓ ｃｏｄｅ）、チャレンジテキスト（ｃｈａｌｌｅｎｇｅ ｔｅｘｔ）、ＲＳＮ（Ｒｏｂｕｓｔ Ｓｅｃｕｒｉｔｙ Ｎｅｔｗｏｒｋ）、有限巡回群（Ｆｉｎｉｔｅ Ｃｙｃｌｉｃ Ｇｒｏｕｐ）などに対する情報を含むことができる。

ＳＴＡは認証要求フレームをＡＰへ送信することができる。ＡＰは受信された認証要求フレームに含まれた情報に基づいて、該当ＳＴＡに対する認証を許可するか否かを決定することができる。ＡＰは認証処理の結果を認証応答フレームを介してＳＴＡに提供することができる。

正常に認証されたＳＴＡはステップＳ３３０に基づいて接続過程を実行することができる。接続過程はＳＴＡが接続要求フレーム（ａｓｓｏｃｉａｔｉｏｎ ｒｅｑｕｅｓｔ ｆｒａｍｅ）をＡＰへ送信し、これに応答してＡＰが接続応答フレーム（ａｓｓｏｃｉａｔｉｏｎ ｒｅｓｐｏｎｓｅ ｆｒａｍｅ）をＳＴＡへ送信する過程を含む。例えば、接続要求フレームは様々な能力（ｃａｐａｂｉｌｌｉｔｙ）に関連する情報、ビーコンリスンインターバル（ｌｉｓｔｅｎ ｉｎｔｅｒｖａｌ）、ＳＳＩＤ（ｓｅｒｖｉｃｅ ｓｅｔ ｉｄｅｎｔｉｆｉｅｒ）、サポートレート（ｓｕｐｐｏｒｔｅｄ ｒａｔｅｓ）、サポートチャネル（ｓｕｐｐｏｒｔｅｄ ｃｈａｎｎｅｌｓ）、ＲＳＮ、移動性ドメイン、サポートオペレーティングクラス（ｓｕｐｐｏｒｔｅｄ ｏｐｅｒａｔｉｎｇ ｃｌａｓｓｅｓ）、ＴＩＭ放送要求（Ｔｒａｆｆｉｃ Ｉｎｄｉｃａｔｉｏｎ Ｍａｐ Ｂｒｏａｄｃａｓｔ ｒｅｑｕｅｓｔ）、相互動作（ｉｎｔｅｒ ｗｏｒｋｉｎｇ）サービス能力などに対する情報を含むことができる。例えば、接続応答フレームは様々な能力に関連する情報、ステータスコード、ＡＩＤ（Ａｓｓｏｃｉａｔｉｏｎ ＩＤ）、サポートレート、ＥＤＣＡ（Ｅｎｈａｎｃｅｄ Ｄｉｓｔｒｉｂｕｔｅｄ Ｃｈａｎｎｅｌ Ａｃｃｅｓｓ）パラメータセット、ＲＣＰＩ（Ｒｅｃｅｉｖｅｄ Ｃｈａｎｎｅｌ Ｐｏｗｅｒ Ｉｎｄｉｃａｔｏｒ）、ＲＳＮＩ（Ｒｅｃｅｉｖｅｄ Ｓｉｇｎａｌ ｔｏ Ｎｏｉｓｅ Ｉｎｄｉｃａｔｏｒ）、移動性ドメイン、タイムアウトインターバル（アソシエーションカムバック時間（ａｓｓｏｃｉａｔｉｏｎ ｃｏｍｅｂａｃｋ ｔｉｍｅ））、重複（ｏｖｅｒｌａｐｐｉｎｇ）ＢＳＳスキャンパラメータ、ＴＩＭ放送応答、ＱｏＳマップなどの情報を含むことができる。

以後、Ｓ３４０ステップにおいて、ＳＴＡはセキュリティ設定過程を実行することができる。ステップＳ３４０のセキュリティ設定過程は、例えば、ＥＡＰＯＬ（Ｅｘｔｅｓｉｂｌｅ Ａｕｔｈｎｔｉｃａｔｉｏｎ Ｐｒｏｔｏｃｏｌ ｏｖｅｒ ＬＡＮ）フレームを介した４ウェイ（ｗａｙ）ハンドシェイクを介して、プライベートキー設定（ｐｒｉｖａｔｅ ｋｅｙ ｓｅｔｕｐ）をする過程を含むことができる。

図４はＩＥＥＥ規格において用いられるＰＰＤＵの一例を示した図面である。

示されたように、ＩＥＥＥａ／ｇ／ｎ／ａｃなどの規格では様々な形のＰＰＤＵ（ＰＨＹ ｐｒｏｔｏｃｏｌ ｄａｔａ ｕｎｉｔ）が使用される。具体的には、ＬＴＦ、ＳＴＦフィールドはトレーニング信号を含み、ＳＩＧ－Ａ、ＳＩＧ－Ｂには受信ステーションのための制御情報が含まれ、データフィールドにはＰＳＤＵ（ＭＡＣ ＰＤＵ／Ａｇｇｒｅｇａｔｅｄ ＭＡＣ ＰＤＵ）に相応するユーザデータが含まれた。

また、図４はＩＥＥＥ８０２．１１ａｘ規格のＨＥ ＰＰＤＵの一例も含む。図４に係るＨＥ ＰＰＤＵは多重ユーザのためのＰＰＤＵの一例として、ＨＥ－ＳＩＧ－Ｂは多重ユーザのための場合にのみ含まれ、単一ユーザのためのＰＰＤＵには該当ＨＥ－ＳＩＧ－Ｂが省略される。

示されたように、多重ユーザ（Ｍｕｌｔｉｐｌｅ Ｕｓｅｒ；ＭＵ）のためのＨＥ－ＰＰＤＵはＬ－ＳＴＦ（ｌｅｇａｃｙ－ｓｈｏｒｔ ｔｒａｉｎｉｎｇ ｆｉｅｌｄ）、Ｌ－ＬＴＦ（ｌｅｇａｃｙ－ｌｏｎｇ ｔｒａｉｎｉｎｇ ｆｉｅｌｄ）、Ｌ－ＳＩＧ（ｌｅｇａｃｙ－ｓｉｇｎａｌ）、ＨＥ－ＳＩＧ－Ａ（ｈｉｇｈ ｅｆｆｉｃｉｅｎｃｙ－ｓｉｇｎａｌ Ａ）、ＨＥ－ＳＩＧ－Ｂ（ｈｉｇｈ ｅｆｆｉｃｉｅｎｃｙ－ｓｉｇｎａｌ－Ｂ）、ＨＥ－ＳＴＦ（ｈｉｇｈ ｅｆｆｉｃｉｅｎｃｙ－ｓｈｏｒｔ ｔｒａｉｎｉｎｇ ｆｉｅｌｄ）、ＨＥ－ＬＴＦ（ｈｉｇｈ ｅｆｆｉｃｉｅｎｃｙ－ｌｏｎｇ ｔｒａｉｎｉｎｇ ｆｉｅｌｄ）、データフィールド（またはＭＡＣペイロード）及びＰＥ（Ｐａｃｋｅｔ Ｅｘｔｅｎｓｉｏｎ）フィールドを含むことができる。それぞれのフィールドは示された時間区間（すなわち、４または８μｓなど）の間に送信される。

以下のように、ＰＰＤＵにおいて用いられるリソースユニット（ＲＵ）を説明する。リソースユニットは複数個のサブキャリア（またはトーン）を含むことができる。リソースユニットはＯＦＤＭＡ技術に基づいて多数のＳＴＡへ信号を送信する場合に使用される。また、一つのＳＴＡへ信号を送信する場合にもリソースユニットが定義される。リソースユニットはＳＴＦ、ＬＴＦ、データフィールドなどのために使用される。

本明細書において説明されたＲＵはＵＬ（Ｕｐｌｉｎｋ）通信及びＤＬ（Ｄｏｗｎｌｉｎｋ）通信に用いられる。例えば、Ｔｒｉｇｇｅｒ ｆｒａｍｅによってｓｏｌｉｃｉｔされるＵＬ－ＭＵ通信が行われる場合、送信ＳＴＡ（例えば、ＡＰ）はＴｒｉｇｇｅｒ ｆｒａｍｅを介して第１ＳＴＡには第１ＲＵ（例えば、２６／５２／１０６／２４２－ＲＵなど）を割り当て、第２ＳＴＡには第２ＲＵ（例えば、２６／５２／１０６／２４２－ＲＵなど）を割り当てることができる。以降、第１ＳＴＡは第１ＲＵに基づいて第１Ｔｒｉｇｇｅｒ－ｂａｓｅｄ ＰＰＤＵを送信することができ、第２ＳＴＡは第２ＲＵに基づいて第２Ｔｒｉｇｇｅｒ－ｂａｓｅｄ ＰＰＤＵを送信することができる。第１／第２Ｔｒｉｇｇｅｒ－ｂａｓｅｄ ＰＰＤＵは同じ時間区間にＡＰに送信される。

例えば、ＤＬ ＭＵ ＰＰＤＵが構成される場合、送信ＳＴＡ（例えば、ＡＰ）は第１ＳＴＡには第１ＲＵ（例えば、２６／５２／１０６／２４２－ＲＵなど）を割り当て、第２ＳＴＡには第２ＲＵ（例えば、２６／５２／１０６／２４２－ＲＵなど）を割り当てることができる。すなわち、送信ＳＴＡ（例えば、ＡＰ）は１つのＭＵ ＰＰＤＵ内で第１ＲＵを介して第１ＳＴＡのためのＨＥ－ＳＴＦ、ＨＥ－ＬＴＦ、Ｄａｔａフィールドを送信することができ、第２ＲＵを介して第２ＳＴＡのためのＨＥ－ＳＴＦ、ＨＥ－ＬＴＦ、Ｄａｔａフィールドを送信することができる。

図５はＵＬ－ＭＵに係る動作を示す。示されているように、送信ＳＴＡ（例えば、ＡＰ）はｃｏｎｔｅｎｄｉｎｇ（すなわち、Ｂａｃｋｏｆｆ動作）を介してチャネル接続を実行し、Ｔｒｉｇｇｅｒ ｆｒａｍｅ１０３０を送信することができる。すなわち、送信ＳＴＡ（例えば、ＡＰ）はＴｒｉｇｇｅｒ ｆｒａｍｅ１３３０が含まれたＰＰＤＵを送信することができる。Ｔｒｉｇｇｅｒ ｆｒａｍｅが含まれたＰＰＤＵが受信されればＳＩＦＳだけのｄｅｌａｙ以降、ＴＢ（ｔｒｉｇｇｅｒ－ｂａｓｅｄ）ＰＰＤＵが送信される。

ＴＢ ＰＰＤＵ１０４１、１０４２は同じ時間帯に送信され、Ｔｒｉｇｇｅｒ ｆｒａｍｅ１０３０内にＡＩＤが表示された複数のＳＴＡ（例えば、Ｕｓｅｒ ＳＴＡ）から送信される。ＴＢ ＰＰＤＵに対するＡＣＫフレーム１０５０は様々な形で実装される。

トリガーフレームの具体的な特徴は図６から図８を介して説明される。ＵＬ－ＭＵ通信が用いられる場合も、ＯＦＤＭＡ（Ｏｒｔｈｏｇｏｎａｌ Ｆｒｅｑｕｅｎｃｙ Ｄｉｖｉｓｉｏｎ Ｍｕｌｔｉｐｌｅ Ａｃｃｅｓｓ）技術又はＭＵ ＭＩＭＯ技術が用いられ、ＯＦＤＭＡ及びＭＵ ＭＩＭＯ技術が同時に用いられる。

図６はトリガーフレームの一例を示す。図６のトリガーフレームはアップリンクＭＵ送信（Ｕｐｌｉｎｋ Ｍｕｌｔｉｐｌｅ－Ｕｓｅｒ ｔｒａｎｓｍｉｓｓｉｏｎ）のためのリソースを割り当て、例えばＡＰから送信される。トリガーフレームはＭＡＣフレームで構成され、ＰＰＤＵに含まれる。

図６に示したそれぞれのフィールドは一部省略することができ、別のフィールドが追加される。また、フィールドそれぞれの長さは示されたことと異なるように変化する。

図６のフレームコントロール（ｆｒａｍｅ ｃｏｎｔｒｏｌ）フィールド１１１０はＭＡＣプロトコルのバージョンに関する情報及びその他の追加的な制御情報が含まれ、デュレーションフィールド１１２０はＮＡＶ設定のための時間情報やＳＴＡの識別子（例えば、ＡＩＤ）に関する情報が含まれる。

また、ＲＡフィールド１１３０は当該トリガーフレームの受信ＳＴＡのアドレス情報が含まれ、必要によって省略することができる。ＴＡフィールド１１４０は当該トリガーフレームを送信するＳＴＡ（例えば、ＡＰ）のアドレス情報が含まれ、共通情報（ｃｏｍｍｏｎ ｉｎｆｏｒｍａｔｉｏｎ）フィールド１１５０は当該トリガーフレームを受信する受信ＳＴＡに適用される共通制御情報を含む。例えば、当該トリガーフレームに対応して送信されるアップＰＰＤＵのＬ－ＳＩＧフィールドの長さを指示するフィールドや、当該トリガーフレームに対応して送信されるアップＰＰＤＵのＳＩＧ－Ａフィールド（すなわち、ＨＥ－ＳＩＧ－Ａフィールド）の内容（ｃｏｎｔｅｎｔ）を制御する情報が含まれる。また、共通制御情報として、当該トリガーフレームに対応して送信されるアップＰＰＤＵのＣＰの長さに関する情報やＬＴＦフィールドの長さに関する情報が含まれる。

また、図６のトリガーフレームを受信する受信ＳＴＡの数に対応する個別ユーザ情報（ｐｅｒ ｕｓｅｒ ｉｎｆｏｒｍａｔｉｏｎ）フィールド（１１６０＃１から１１６０＃Ｎ）を含むことが望ましい。前記個別ユーザ情報フィールドは、「割り当てフィールド」とも呼ぶことができる。

また、図６のトリガーフレームはパディングフィールド１１７０と、フレームチェックシーケンスフィールド１１８０を含むことができる。

図６に示した、個別ユーザ情報（ｐｅｒ ｕｓｅｒ ｉｎｆｏｒｍａｔｉｏｎ）フィールド（１１６０＃１から１１６０＃Ｎ）それぞれは再び多数のサブフィールドを含むことができる。

図７はトリガーフレームの共通情報（ｃｏｍｍｏｎ ｉｎｆｏｒｍａｔｉｏｎ）フィールドの一例を示す。図７のサブフィールドのうち、一部は省略することができ、その他のサブフィールドが追加される。また、示されたサブフィールドそれぞれの長さは変形することができる。

示された長さフィールド１２１０は当該トリガーフレームに対応して送信されるアップＰＰＤＵのＬ－ＳＩＧフィールドの長さフィールドと同じ値を持ち、アップＰＰＤＵのＬ－ＳＩＧフィールドの長さフィールドはアップＰＰＤＵの長さを示す。結果的にトリガーフレームの長さフィールド１２１０は対応するアップリンクＰＰＤＵの長さを指示するのに用いられる。

また、カスケード指示子フィールド１２２０はカスケード動作が実行されるか否かを指示する。カスケード動作は同じＴＸＯＰ内にダウンリンクＭＵ送信とアップリンクＭＵ送信がともに実行されることを意味する。すなわち、ダウンリンクＭＵ送信が実行された以降、既に設定された時間（例えば、ＳＩＦＳ）以降、アップリンクＭＵ送信が実行されることを意味する。カスケード動作の中にはダウンリンク通信を行う送信装置（例えば、ＡＰ）は１つのみ存在し、アップリンク通信を行う送信装置（例えば、ｎｏｎ－ＡＰ）は複数存在することができる。

ＣＳ要求フィールド１２３０は当該トリガーフレームを受信した受信装置が対応するアップリンクＰＰＤＵを送信する状況において無線媒体の状態やＮＡＶなどを考慮する必要があるかどうかを指示する。

ＨＥ－ＳＩＧ－Ａ情報フィールド１２４０は当該トリガーフレームに対応して送信されるアップＰＰＤＵのＳＩＧ－Ａフィールド（すなわち、ＨＥ－ＳＩＧ－Ａフィールド）の内容（ｃｏｎｔｅｎｔ）を制御する情報が含まれる。

ＣＰ及びＬＴＦタイプフィールド１２５０は当該トリガーフレームに対応して送信されるアップＰＰＤＵのＬＴＦの長さ及びＣＰ長さに関する情報を含むことができる。トリガータイプフィールド１０６０は当該トリガーフレームが用いられる目的、例えば通常のトリガー、ビームフォーミングのためのトリガー、Ｂｌｏｃｋ Ａｃｋ／ＮＡＣＫに対する要求などを指示することができる。

本明細書においてトリガーフレームのトリガータイプフィールド１２６０は通常のトリガーのための基本（Ｂａｓｉｃ）タイプのトリガーフレームを指示すると仮定することができる。例えば、基本（Ｂａｓｉｃ）タイプのトリガーフレームは基本トリガーフレームと言及される。

図８はユーザ情報（ｐｅｒ ｕｓｅｒ ｉｎｆｏｒｍａｔｉｏｎ）フィールドに含まれているサブフィールドの一例を示す。図８のユーザ情報フィールド１３００は前記の図６において言及された個別ユーザ情報フィールド（１１６０＃１～１１６０＃Ｎ）のうち、いずれか１つとして理解される。図８のユーザ情報フィールド１３００に含まれたサブフィールドのうち、一部は省略することができ、その他のサブフィールドが追加される。また、示されたサブフィールドそれぞれの長さは変形することができる。

図８のユーザ識別子（Ｕｓｅｒ Ｉｄｅｎｔｉｆｉｅｒ）フィールド１３１０は個別ユーザ情報（ｐｅｒ ｕｓｅｒ ｉｎｆｏｒｍａｔｉｏｎ）に対応するＳＴＡ（すなわち、受信ＳＴＡ）の識別子を示すことで、識別子の一例は受信ＳＴＡのＡＩＤ（ａｓｓｏｃｉａｔｉｏｎ ｉｄｅｎｔｉｆｉｅｒ）値の全部又は一部になる。

また、ＲＵ割り当て（ＲＵ Ａｌｌｏｃａｔｉｏｎ）フィールド１３２０が含まれる。すなわち、ユーザ識別子フィールド１３１０として識別された受信ＳＴＡが、トリガーフレームに対応してＴＢ ＰＰＤＵを送信する場合、ＲＵ割り当てフィールド１３２０が指示したＲＵを介してＴＢ ＰＰＤＵを送信する。

図８のサブフィールドはコーディングタイプフィールド１３３０を含むことができる。コーディングタイプフィールド１３３０はＴＢ ＰＰＤＵのコーディングタイプを指示することができる。例えば、前記ＴＢ ＰＰＤＵにＢＣＣコーディングが適用される場合、前記コーディングタイプフィールド１３３０は「１」に設定され、ＬＤＰＣコーディングが適用される場合、前記コーディングタイプフィールド１３３０は「０」として設定される。

また、図８のサブフィールドはＭＣＳフィールド１３４０を含むことができる。ＭＣＳフィールド１３４０はＴＢ ＰＰＤＵに適用されるＭＣＳ技術を指示することができる。例えば、前記ＴＢ ＰＰＤＵにＢＣＣコーディングが適用される場合、前記コーディングタイプフィールド１３３０は「１」に設定され、ＬＤＰＣコーディングが適用される場合、前記コーディングタイプフィールド１３３０は「０」として設定される。

以下のＵＯＲＡ（ＵＬ ＯＦＤＭＡ－ｂａｓｅｄ Ｒａｎｄｏｍ Ａｃｃｅｓｓ）技術に対して説明する。

図９はＵＯＲＡ技術の技術的な特徴を説明する。

送信ＳＴＡ（例えば、ＡＰ）はトリガーフレームを介して図９に示しているように６個のＲＵリソースを割り当てることができる。具体的には、ＡＰは第１ＲＵリソース（ＡＩＤ ０、ＲＵ １）、第２ＲＵリソース（ＡＩＤ ０、ＲＵ ２）、第３ＲＵリソース（ＡＩＤ ０、ＲＵ ３）、第４ＲＵリソース（ＡＩＤ ２０４５、ＲＵ ４）、第５ＲＵリソース（ＡＩＤ ２０４５、ＲＵ ５）、第６ＲＵリソース（ＡＩＤ ３、ＲＵ ６）を割り当てることができる。ＡＩＤ ０、ＡＩＤ ３、又はＡＩＤ ２０４５に関する情報は、例えば、図８のユーザ識別フィールド１３１０に含まれる。ＲＵ １からＲＵ ６に関する情報は、例えば図８のＲＵ割り当てフィールド１３２０に含まれる。ＡＩＤ＝０は接続された（ａｓｓｏｃｉａｔｅｄ）ＳＴＡのためのＵＯＲＡリソースを意味し、ＡＩＤ＝２０４５は非接続された（ｕｎ－ａｓｓｏｃｉａｔｅｄ）ＳＴＡのためのＵＯＲＡリソースを意味する。これに応じて、図９の第１から第３ＲＵリソースは接続された（ａｓｓｏｃｉａｔｅｄ）ＳＴＡのためのＵＯＲＡリソースとして用いられ、図９の第４から第５ＲＵリソースは非接続された（ｕｎ－ａｓｓｏｃｉａｔｅｄ）ＳＴＡのためのＵＯＲＡリソースとして用いられ、図９の第６ＲＵリソースは通常のＵＬ ＭＵのためのリソースとして用いられる。

図９の一例においてはＳＴＡ１のＯＢＯ（ＯＦＤＭＡ ｒａｎｄｏｍ ａｃｃｅｓｓ Ｂａｃｋ Ｏｆｆ）カウンターが０に減少して、ＳＴＡ１が第２ＲＵリソース（ＡＩＤ ０、ＲＵ ２）をランダムに選択する。また、ＳＴＡ２／３のＯＢＯカウンターは０より大きいため、ＳＴＡ２／３にはアップリンクリソースが割り当てられなかった。また、図９においてＳＴＡ４はトリガーフレーム内に自身のＡＩＤ（すなわち、ＡＩＤ＝３）が含まれたため、バックオフなしにＲＵ ６のリソースが割り当てられた。

具体的には、図９のＳＴＡ１は接続された（ａｓｓｏｃｉａｔｅｄ）ＳＴＡであるためＳＴＡ１のためのｅｌｉｇｉｂｌｅ ＲＡ ＲＵは合計３個（ＲＵ １、ＲＵ ２、ＲＵ ３）であり、これに応じてＳＴＡ１はＯＢＯカウンターを３だけ減らしＯＢＯカウンターが０になった。また、図９のＳＴＡ２は接続された（ａｓｓｏｃｉａｔｅｄ）ＳＴＡであるためＳＴＡ２のためのｅｌｉｇｉｂｌｅ ＲＡ ＲＵは合計３個（ＲＵ １、ＲＵ ２、ＲＵ ３）であり、これに応じてＳＴＡ２はＯＢＯカウンターを３だけ減らせたがＯＢＯカウンターが０より大きい状態である。また、図９のＳＴＡ３は非接続された（ｕｎ－ａｓｓｏｃｉａｔｅｄ）ＳＴＡであるためＳＴＡ３のためのｅｌｉｇｉｂｌｅ ＲＡ ＲＵは合計２個（ＲＵ ４、ＲＵ ５）であり、これに応じてＳＴＡ３はＯＢＯカウンターを２だけ減らせたがＯＢＯカウンターが０より大きい状態である。

以下の通り、本明細書のＳＴＡにおいて送信／受信されるＰＰＤＵが説明される。

図１０は本明細書に用いられるＰＰＤＵの一例を示す。

図１０のＰＰＤＵはＥＨＴ ＰＰＤＵ、送信ＰＰＤＵ、受信ＰＰＤＵ、第１タイプ又は第ＮタイプＰＰＤＵなどの様々な名称で呼ぶことができる。例えば、本明細書においてＰＰＤＵ又はＥＨＴ ＰＰＤＵは、送信ＰＰＤＵ、受信ＰＰＤＵ、第１タイプ又は第ＮタイプＰＰＤＵなどの様々な名称で呼ぶことができる。また、ＥＨＴ ＰＰＵはＥＨＴシステム及び／又はＥＨＴシステムを改善した新しい無線ＬＡＮシステムにおいて用いられる。

図１０のＰＰＤＵはＥＨＴシステムにおいて用いられるＰＰＤＵタイプのうち、一部又は全部を示すことができる。例えば、図１０の一例はＳＵ（ｓｉｎｇｌｅ－ｕｓｅｒ）モード及びＭＵ（ｍｕｌｔｉ－ｕｓｅｒ）モード全てのために用いられる。別の言い方をすると、図１０のＰＰＤＵは１つの受信ＳＴＡ又は複数の受信ＳＴＡのためのＰＰＤＵであり得る。図１０のＰＰＤＵがＴＢ（Ｔｒｉｇｇｅｒ－ｂａｓｅｄ）モードのために用いられる場合、図１０のＥＨＴ－ＳＩＧは省略することができる。別の言い方をするとＵＬ－ＭＵ（Ｕｐｌｉｎｋ－ＭＵ）通信のためのＴｒｉｇｇｅｒ ｆｒａｍｅを受信したＳＴＡは、図１０の一例においてＥＨＴ－ＳＩＧが省略されたＰＰＤＵを送信することができる。

図１０においてＬ－ＳＴＦからＥＨＴ－ＬＴＦはプリアンブル（ｐｒｅａｍｂｌｅ）又は物理プリアンブル（ｐｈｙｓｉｃａｌ ｐｒｅａｍｂｌｅ）と呼ぶことができ、物理層において生成／送信／受信／獲得／デコーディングされる。

図１０のＬ－ＳＴＦ、Ｌ－ＬＴＦ、Ｌ－ＳＩＧ、ＲＬ－ＳＩＧ、Ｕ－ＳＩＧ、ＥＨＴ－ＳＩＧフィールドのｓｕｂｃａｒｒｉｅｒ ｓｐａｃｉｎｇは３１２．５ｋＨｚに設定され、ＥＨＴ－ＳＴＦ、ＥＨＴ－ＬＴＦ、Ｄａｔａフィールドのｓｕｂｃａｒｒｉｅｒ ｓｐａｃｉｎｇは７８．１２５ｋＨｚに設定される。すなわち、Ｌ－ＳＴＦ、Ｌ－ＬＴＦ、Ｌ－ＳＩＧ、ＲＬ－ＳＩＧ、Ｕ－ＳＩＧ、ＥＨＴ－ＳＩＧフィールドのｔｏｎｅ ｉｎｄｅｘ（又はｓｕｂｃａｒｒｉｅｒ ｉｎｄｅｘ）は３１２．５ｋＨｚ単位で表示され、ＥＨＴ－ＳＴＦ、ＥＨＴ－ＬＴＦ、Ｄａｔａフィールドのｔｏｎｅ ｉｎｄｅｘ（又はｓｕｂｃａｒｒｉｅｒ ｉｎｄｅｘ）は７８．１２５ｋＨｚ単位で表すことができる。

図１０のＰＰＤＵはＬ－ＬＴＦ及びＬ－ＳＴＦは従来のフィールドと同じであり得る。

図１０のＬ－ＳＩＧフィールドは例えば２４ビットのビット情報を含むことができる。例えば、２４ビット情報は４ビットのＲａｔｅフィールド、１ビットのＲｅｓｅｒｖｅｄビット、１２ビットのＬｅｎｇｔｈフィールド、１ビットのＰａｒｉｔｙビット及び、６ビットのＴａｉｌビットを含むことができる。例えば、１２ビットのＬｅｎｇｔｈフィールドはＰＰＤＵの長さ又はｔｉｍｅ ｄｕｒａｔｉｏｎに関する情報を含むことができる。例えば、１２ビットＬｅｎｇｔｈフィールドの値はＰＰＤＵのタイプに基づいて決定される。例えば、ＰＰＤＵがｎｏｎ－ＨＴ、ＨＴ、ＶＨＴ ＰＰＤＵであるかＥＨＴ ＰＰＤＵである場合、Ｌｅｎｇｔｈフィールドの値は３の倍数で決定される。例えば、ＰＰＤＵがＨＥ ＰＰＤＵである場合、Ｌｅｎｇｔｈフィールドの値は「３の倍数＋１」又は「３の倍数＋２」で決定される。別の言い方をすると、ｎｏｎ－ＨＴ、ＨＴ、ＶＨＴ ＰＰＤＵであるかＥＨＴ ＰＰＤＵのためにＬｅｎｇｔｈフィールドの値は３の倍数で決定することができ、ＨＥ ＰＰＤＵのためにＬｅｎｇｔｈフィールドの値は「３の倍数＋１」又は「３の倍数＋２」で決定される。

例えば、送信ＳＴＡはＬ－ＳＩＧフィールドの２４ビット情報に対して１／２の符号化率（ｃｏｄｅ ｒａｔｅ）の基づいたＢＣＣであるコーディングを適用することができる。以降、送信ＳＴＡは４８ビットのＢＣＣ符号化ビットを獲得することができる。４８ビットの符号化ビットに対してはＢＰＳＫ変調が適用され４８個のＢＰＳＫシンボルが生成される。送信ＳＴＡは４８個のＢＰＳＫシンボルを、パイロットサブキャリア｛サブキャリアインデクス－２１、－７、＋７、＋２１｝及びＤＣサブキャリア｛サブキャリアインデクス０｝を除いた位置にマッピングすることができる。結果的に４８個のＢＰＳＫシンボルはサブキャリアインデクス－２６から－２２、－２０から－８、－６から－１、＋１から＋６、＋８から＋２０、及び＋２２から＋２６にマッピングされる。送信ＳＴＡはサブキャリアインデクス｛－２８、－２７、＋２７、２８｝に｛－１、－１、－１、１｝の信号をさらにマッピングすることができる。上記の信号は｛－２８、－２７、＋２７、２８｝に対応する周波数領域に対するチャネル推定のために用いられる。

送信ＳＴＡはＬ－ＳＩＧと同じく生成されるＲＬ－ＳＩＧを生成することができる。ＲＬ－ＳＩＧに対してはＢＰＳＫ変調が適用される。受信ＳＴＡはＲＬ－ＳＩＧの存在に基づいて受信ＰＰＤＵがＨＥ ＰＰＤＵ又はＥＨＴ ＰＰＤＵであることがわかる。

図１０のＲＬ－ＳＩＧ以降はＵ－ＳＩＧ（Ｕｎｉｖｅｒｓａｌ ＳＩＧ）が挿入される。Ｕ－ＳＩＧは第１ＳＩＧフィールド、第１ＳＩＧ、第１タイプＳＩＧ、制御信号、制御信号フィールド、第１（タイプ）制御信号などの様々な名称で呼ぶことができる。

Ｕ－ＳＩＧはＮビットの情報を含むことができ、ＥＨＴ ＰＰＤＵのタイプを識別するための情報を含むことができる。例えば、Ｕ－ＳＩＧは２つのシンボル（例えば、連続の２つのＯＦＤＭシンボル）に基づいて構成される。Ｕ－ＳＩＧのための各シンボル（例えば、ＯＦＤＭシンボル）は４ ｕｓのｄｕｒａｔｉｏｎを持つことができる。Ｕ－ＳＩＧの各シンボルは２６ビット情報を送信するために用いられる。例えばＵ－ＳＩＧの各シンボルは５２個のデータトーンと４個のパイロットトーンに基づいて送受信される。

Ｕ－ＳＩＧ（又はＵ－ＳＩＧフィールド）を介しては例えばＡビット情報（例えば、５２ ｕｎ－ｃｏｄｅｄ ｂｉｔ）が送信され、Ｕ－ＳＩＧの第１シンボルは総Ａビット情報のうち、最初のＸビット情報（例えば、２６ ｕｎ－ｃｏｄｅｄ ｂｉｔ）を送信し、Ｕ－ＳＩＧの第２シンボルは総Ａビット情報のうち、残りのＹビット情報（例えば、２６ ｕｎ－ｃｏｄｅｄ ｂｉｔ）を送信することができる。例えば、送信ＳＴＡは各Ｕ－ＳＩＧシンボルに含まれる２６ ｕｎ－ｃｏｄｅｄ ｂｉｔを獲得することができる。送信ＳＴＡはＲ＝１／２のｒａｔｅに基づいてｃｏｎｖｏｌｕｔｉｏｎａｌ ｅｎｃｏｄｉｎｇ（すなわち、ＢＣＣであるコーディング）を実行して５２－ｃｏｄｅｄ ｂｉｔを生成し、５２－ｃｏｄｅｄ ｂｉｔに対するインターリーブを実行することができる。送信ＳＴＡはインターリーブされた５２－ｃｏｄｅｄ ｂｉｔに対してＢＰＳＫ変調を実行して各Ｕ－ＳＩＧシンボルに割り当てられる５２個のＢＰＳＫシンボルを生成することができる。１つのＵ－ＳＩＧシンボルはＤＣインデクス０を除いて、サブキャリアインデクス－２８からサブキャリアインデクス＋２８までの５６個のトーン（サブキャリア）に基づいて送信される。送信ＳＴＡが生成した５２個のＢＰＳＫシンボルはパイロットトーンである－２１、－７、＋７、＋２１トーンを除いた残りのトーン（サブキャリア）に基づいて送信される。

例えば、Ｕ－ＳＩＧによって送信されるＡビット情報（例えば、５２ ｕｎ－ｃｏｄｅｄ ｂｉｔ）はＣＲＣフィールド（例えば４ビット長さのフィールド）及びテールフィールド（例えば６ビット長さのフィールド）を含むことができる。前記ＣＲＣフィールド及びテールフィールドはＵ－ＳＩＧの第２シンボルを介して送信される。前記ＣＲＣフィールドはＵ－ＳＩＧの第１シンボルに割り当てられる２６ビットと第２シンボル内で前記ＣＲＣ／テールフィールドを除いた残りの１６ビットに基づいて生成され、従来のＣＲＣ ｃａｌｃｕｌａｔｉｏｎアルゴリズムに基づいて生成される。また、前記テールフィールドはｃｏｎｖｏｌｕｔｉｏｎａｌ ｄｅｃｏｄｅｒのｔｒｅｌｌｉｓをｔｅｒｍｉｎａｔｅするために用いられ、例えば「００００００」と設定される。

Ｕ－ＳＩＧ（又はＵ－ＳＩＧフィールド）によって送信されるＡビット情報（例えば、５２ ｕｎ－ｃｏｄｅｄ ｂｉｔ）はｖｅｒｓｉｏｎ－ｉｎｄｅｐｅｎｄｅｎｔ ｂｉｔｓとｖｅｒｓｉｏｎ－ｄｅｐｅｎｄｅｎｔ ｂｉｔｓで分けることができる。例えば、ｖｅｒｓｉｏｎ－ｉｎｄｅｐｅｎｄｅｎｔ ｂｉｔｓのサイズは固定的であるか可変的であり得る。例えば、ｖｅｒｓｉｏｎ－ｉｎｄｅｐｅｎｄｅｎｔ ｂｉｔｓはＵ－ＳＩＧの第１シンボルにのみ割り当てられるか、ｖｅｒｓｉｏｎ－ｉｎｄｅｐｅｎｄｅｎｔ ｂｉｔｓはＵ－ＳＩＧの第１シンボル及び第２シンボル全てに割り当てられる。例えば、ｖｅｒｓｉｏｎ－ｉｎｄｅｐｅｎｄｅｎｔ ｂｉｔｓとｖｅｒｓｉｏｎ－ｄｅｐｅｎｄｅｎｔ ｂｉｔｓは第１制御ビット及び第２制御ビットなどの様々な名称で呼ぶことができる。

例えば、Ｕ－ＳＩＧのｖｅｒｓｉｏｎ－ｉｎｄｅｐｅｎｄｅｎｔ ｂｉｔｓは３ビットのＰＨＹ ｖｅｒｓｉｏｎ ｉｄｅｎｔｉｆｉｅｒを含むことができる。例えば、３ビットのＰＨＹ ｖｅｒｓｉｏｎ ｉｄｅｎｔｉｆｉｅｒは送受信ＰＰＤＵのＰＨＹ ｖｅｒｓｉｏｎに関連する情報を含むことができる。例えば、３ビットのＰＨＹ ｖｅｒｓｉｏｎ ｉｄｅｎｔｉｆｉｅｒの第１値は送受信ＰＰＤＵがＥＨＴ ＰＰＤＵであることを指示することができる。別の言い方をすると、送信ＳＴＡはＥＨＴ ＰＰＤＵを送信する場合、３ビットのＰＨＹ ｖｅｒｓｉｏｎ ｉｄｅｎｔｉｆｉｅｒを第１値として設定することができる。別の言い方をすると、受信ＳＴＡは第１値を持つＰＨＹ ｖｅｒｓｉｏｎ ｉｄｅｎｔｉｆｉｅｒに基づいて、受信ＰＰＤＵがＥＨＴ ＰＰＤＵであることを判断することができる。

例えば、Ｕ－ＳＩＧのｖｅｒｓｉｏｎ－ｉｎｄｅｐｅｎｄｅｎｔ ｂｉｔｓは１ビットのＵＬ／ＤＬ ｆｌａｇフィールドを含むことができる。１ビットのＵＬ／ＤＬ ｆｌａｇフィールドの第１値はＵＬ通信に関連し、ＵＬ／ＤＬ ｆｌａｇフィールドの第２値はＤＬ通信に関連する。

例えば、Ｕ－ＳＩＧのｖｅｒｓｉｏｎ－ｉｎｄｅｐｅｎｄｅｎｔ ｂｉｔｓはＴＸＯＰの長さに関する情報、ＢＳＳ ｃｏｌｏｒ ＩＤに関する情報を含むことができる。

例えばＥＨＴ ＰＰＤＵが様々なタイプ（例えば、ＳＵモードに関連するＥＨＴ ＰＰＤＵ、ＭＵモードに関連するＥＨＴ ＰＰＤＵ、ＴＢモードに関連するＥＨＴ ＰＰＤＵ、Ｅｘｔｅｎｄｅｄ Ｒａｎｇｅ送信に関連するＥＨＴ ＰＰＤＵなどの様々なタイプ）で分けられる場合、ＥＨＴ ＰＰＤＵのタイプに関する情報はＵ－ＳＩＧのｖｅｒｓｉｏｎ－ｄｅｐｅｎｄｅｎｔ ｂｉｔｓに含まれる。

例えば、Ｕ－ＳＩＧは１）帯域幅に関する情報を含む帯域幅フィールド、２）ＥＨＴ－ＳＩＧに適用されるＭＣＳ技術に関する情報を含むフィールド、３）ＥＨＴ－ＳＩＧにデュアル副搬送波変調（ｄｕａｌ ｓｕｂｃａｒｒｉｅｒ ｍｏｄｕｌａｔｉｏｎ，ＤＣＭ）技術が適用されるか否かに関連する情報を含む指示フィールド、４）ＥＨＴ－ＳＩＧのために用いられるシンボルの数に関する情報を含むフィールド、５）ＥＨＴ－ＳＩＧが全帯域にわたって生成されるか否かに関する情報を含むフィールド、６）ＥＨＴ－ＬＴＦ／ＳＴＦのタイプに関する情報を含むフィールド、７）ＥＨＴ－ＬＴＦの長さ及びＣＰ長さを指示するフィールドに関する情報を含むことができる。

以下の一例において（送信／受信／アップ／ダウン）信号、（送信／受信／アップ／ダウン）フレーム、（送信／受信／アップ／ダウン）パケット、（送信／受信／アップ／ダウン）データユニット、（送信／受信／アップ／ダウン）データなどで表示される信号は図１０のＰＰＤＵに基づいて送受信される信号であり得る。図１０のＰＰＤＵは様々なタイプのフレームを送受信するために用いられる。例えば、図１０のＰＰＤＵは制御フレーム（ｃｏｎｔｒｏｌ ｆｒａｍｅ）のために用いられる。制御フレームの一例は、ＲＴＳ（ｒｅｑｕｅｓｔ ｔｏ ｓｅｎｄ）、ＣＴＳ（ｃｌｅａｒ ｔｏ ｓｅｎｄ）、ＰＳ－Ｐｏｌｌ（Ｐｏｗｅｒ Ｓａｖｅ－Ｐｏｌｌ）、Ｂｌｏｃｋ ＡＣＫ Ｒｅｑ、Ｂｌｏｃｋ Ａｃｋ、ＮＤＰ（Ｎｕｌｌ Ｄａｔａ Ｐａｃｋｅｔ）ａｎｎｏｕｎｃｅｍｅｎｔ、Ｔｒｉｇｇｅｒ ｆｒａｍｅを含むことができる。例えば、図１８のＰＰＤＵは管理フレーム（ｍａｎａｇｅｍｅｎｔ ｆｒａｍｅ）のために用いられる。ｍａｎａｇｅｍｅｎｔ ｆｒａｍｅの一例は、Ｂｅａｃｏｎ ｆｒａｍｅ、（Ｒｅ－）Ａｓｓｏｃｉａｔｉｏｎ Ｒｅｑｕｅｓｔ ｆｒａｍｅ、（Ｒｅ－）Ａｓｓｏｃｉａｔｉｏｎ Ｒｅｓｐｏｎｓｅ ｆｒａｍｅ、Ｐｒｏｂｅ Ｒｅｑｕｅｓｔ ｆｒａｍｅ、Ｐｒｏｂｅ Ｒｅｓｐｏｎｓｅ ｆｒａｍｅを含むことができる。例えば、図１０のＰＰＤＵはデータフレームのために用いられる。例えば、図１０のＰＰＤＵは制御フレーム、管理フレーム、及びデータフレームのうち、少なくとも２つ以上を同時に送信するためにも用いられる。

図１１は本明細書の送信装置及び／又は受信装置の変形例を示す。

図１の（ａ）／（ｂ）の各装置／ＳＴＡは図１１のように変形することができる。図１１の送受信機６３０は図１の送受信機１１３、１２３と同じであり得る。図１１の送受信機６３０は受信機（ｒｅｃｅｉｖｅｒ）及び送信機（ｔｒａｎｓｍｉｔｔｅｒ）を含むことができる。

図１１のプロセッサ６１０は図１のプロセッサ１１１、１２１と同じであり得る。又は、図１１のプロセッサ６１０は図１の処理チップ１１４、１２４と同じであり得る。

図１１のメモリ１５０は図１のメモリ１１２、１２２と同じであり得る。又は、図１１のメモリ１５０は図１のメモリ１１２、１２２とは異なる別途の外部メモリであり得る。

図１１を参照すると、電力管理モジュール６１１はプロセッサ６１０及び／又は送受信機６３０に対する電力を管理する。バッテリー６１２は電力管理モジュール６１１に電力を供給する。ディスプレイ６１３はプロセッサ６１０によって処理された結果を出力する。キーパッド６１４はプロセッサ６１０によって用いられる入力を受信する。キーパッド６１４はディスプレイ６１３上に表すことができる。ＳＩＭカード６１５は携帯電話及びコンピューターのような携帯電話装置において加入者を識別して認証するのに用いられるＩＭＳＩ（ｉｎｔｅｒｎａｔｉｏｎａｌ ｍｏｂｉｌｅ ｓｕｂｓｃｒｉｂｅｒ ｉｄｅｎｔｉｔｙ）及びそれに関連するキーを安全に格納するために用いられる集積回路であり得る。

図１１を参照すると、スピーカー６４０はプロセッサ６１０によって処理された音関連結果を出力することができる。マイク６４１はプロセッサ６１０によって用いられる音関連入力を受信することができる。

以下の本明細書のＳＴＡがサポートするマルチリンク（Ｍｕｌｔｉ－ｌｉｎｋ；ＭＬ）に対する技術的な特徴が説明される。

本明細書のＳＴＡ（ＡＰ及び／又はｎｏｎ－ＡＰ ＳＴＡ）はマルチリンク（ＭｕｌｔｉＬｉｎｋ；ＭＬ）通信をサポートすることができる。ＭＬ通信は複数のリンク（Ｌｉｎｋ）をサポートする通信を意味する。ＭＬ通信に関連するリンクは２．４ＧＨｚバンド、５ＧＨｚバンド、６ＧＨｚバンドのチャネル（例えば、２０／４０／８０／１６０／２４０／３２０ＭＨｚチャネル）を含むことができる。

ＭＬ通信のために用いられる複数のリンク（ｌｉｎｋ）は多様に設定される。例えば、ＭＬ通信のために１つのＳＴＡにサポートされる複数のリンク（ｌｉｎｋ）は２．４ＧＨｚバンド内の複数のチャネル、５ＧＨｚバンド内の複数のチャネル、６ＧＨｚバンド内の複数のチャネルであり得る。又は、ＭＬ通信のために１つのＳＴＡにサポートされる複数のリンク（ｌｉｎｋ）は２．４ＧＨｚバンド（又は５ＧＨｚ／６ＧＨｚバンド）内の少なくとも１つのチャネルと５ＧＨｚバンド（又は２．４ＧＨｚ／６ＧＨｚバンド）内の少なくとも１つのチャネルの組み合わせであり得る。その一方で、ＭＬ通信のために１つのＳＴＡにサポートされる複数のリンク（ｌｉｎｋ）のうち、少なくとも１つはプリアンブルパンクチャリングが適用されるチャネルであり得る。

ＳＴＡはＭＬ通信を行うためにＭＬ設定（ｓｅｔｕｐ）を実行することができる。ＭＬ設定（ｓｅｔｕｐ）はＢｅａｃｏｎ、Ｐｒｏｂｅ Ｒｅｑｕｅｓｔ／Ｒｅｓｐｏｎｓｅ、Ａｓｓｏｃｉａｔｉｏｎ Ｒｅｑｕｅｓｔ／Ｒｅｓｐｏｎｓｅなどのｍａｎａｇｅｍｅｎｔ ｆｒａｍｅやｃｏｎｔｒｏｌ ｆｒａｍｅに基づいて実行することができる。例えば、ＭＬ設定に関する情報はＢｅａｃｏｎ、Ｐｒｏｂｅ Ｒｅｑｕｅｓｔ／Ｒｅｓｐｏｎｓｅ、Ａｓｓｏｃｉａｔｉｏｎ Ｒｅｑｕｅｓｔ／Ｒｅｓｐｏｎｓｅ内に含まれるｅｌｅｍｅｎｔフィールド内に含まれる。

ＭＬ設定（ｓｅｔｕｐ）が完了されればＭＬ通信のためのｅｎａｂｌｅｄ ｌｉｎｋが決定される。ＳＴＡはｅｎａｂｌｅｄ ｌｉｎｋで決定された複数のリンクのうち、少なくとも１つを介してフレーム交換（ｆｒａｍｅ ｅｘｃｈａｎｇｅ）を実行することができる。例えば、ｅｎａｂｌｅｄ ｌｉｎｋはｍａｎａｇｅｍｅｎｔ ｆｒａｍｅ、ｃｏｎｔｒｏｌ ｆｒａｍｅ及びｄａｔａ ｆｒａｍｅのうち、少なくとも１つのために用いられる。

１つのＳＴＡが複数のＬｉｎｋをサポートする場合、各Ｌｉｎｋをサポートする送受信装置は１つの論理ＳＴＡのように動作することができる。例えば、２個のＬｉｎｋをサポートする１つのＳＴＡは、第１Ｌｉｎｋのための第１ＳＴＡと第２ｌｉｎｋのための第２ＳＴＡを含む１つのＭＬデバイス（Ｍｕｌｔｉ Ｌｉｎｋ Ｄｅｖｉｃｅ；ＭＬＤ）で表すことができる。例えば、２個のＬｉｎｋをサポートする１つのＡＰは、第１Ｌｉｎｋのための第１ＡＰと第２ｌｉｎｋのための第２ＡＰを含む１つのＡＰ ＭＬＤで表すことができる。また、２個のＬｉｎｋをサポートする１つのｎｏｎ－ＡＰは、第１Ｌｉｎｋのための第１ＳＴＡと第２ｌｉｎｋのための第２ＳＴＡを含む１つの非ＡＰ ＭＬＤで表すことができる。

以下の通り、ＭＬ設定（ｓｅｔｕｐ）に関するより具体的な特徴が説明される。

ＭＬＤ（ＡＰ ＭＬＤ及び／又は非ＡＰ ＭＬＤ）はＭＬ設定（ｓｅｔｕｐ）を介して、当該ＭＬＤがサポートできるリンクに関する情報を送信することができる。リンクに関する情報は多様に構成される。例えば、リンクに関する情報は１）ＭＬＤ（又はＳＴＡ）がｓｉｍｕｌｔａｎｅｏｕｓ ＲＸ／ＴＸ ｏｐｅｒａｔｉｏｎをサポートするか否かに関する情報、２）ＭＬＤ（又はＳＴＡ）がサポートするｕｐｌｉｎｋ／ｄｏｗｎｌｉｎｋ Ｌｉｎｋの数／上限に関する情報、３）ＭＬＤ（又はＳＴＡ）がサポートするｕｐｌｉｎｋ／ｄｏｗｎｌｉｎｋ Ｌｉｎｋの位置／帯域／リソースに関する情報、４）少なくとも１つのｕｐｌｉｎｋ／ｄｏｗｎｌｉｎｋ Ｌｉｎｋにおいて使用可能な又は優先されるｆｒａｍｅのｔｙｐｅ（ｍａｎａｇｅｍｅｎｔ、ｃｏｎｔｒｏｌ、ｄａｔａなど）に関する情報、５）少なくとも１つのｕｐｌｉｎｋ／ｄｏｗｎｌｉｎｋ Ｌｉｎｋにおいて使用可能な又は優先されるＡＣＫ ｐｏｌｉｃｙ情報、及び６）少なくとも１つのｕｐｌｉｎｋ／ｄｏｗｎｌｉｎｋ Ｌｉｎｋにおいて使用可能な又は優先されるＴＩＤ（ｔｒａｆｆｉｃ ｉｄｅｎｔｉｆｉｅｒ）に関する情報のうち、少なくとも１つを含むことができる。ＴＩＤはトラフィックデータの優先順位（ｐｒｉｏｒｉｔｙ）に関連することで従来無線ＬＡＮ規格によって８種類の値で表現される。すなわち、従来無線ＬＡＮ規格に係る４個のアクセスカテゴリー（ａｃｃｅｓｓ ｃａｔｅｇｏｒｙ；ＡＣ）（ＡＣ＿ＢＫ（ｂａｃｋｇｒｏｕｎｄ）、ＡＣ＿ＢＥ（ｂｅｓｔ ｅｆｆｏｒｔ）、ＡＣ＿ＶＩ（ｖｉｄｅｏ）、ＡＣ＿ＶＯ（ｖｏｉｃｅ））に対応される８個のＴＩＤ値が定義される。

例えば、ｕｐｌｉｎｋ／ｄｏｗｎｌｉｎｋ Ｌｉｎｋに対して全てのＴＩＤがマッピング（ｍａｐｐｉｎｇ）されることで事前に設定される。具体的には、ＭＬ設定（ｓｅｔｕｐ）を介して交渉が行われなかった場合は全てのＴＩＤがＭＬ通信のために使用され、追加的なＭＬ設定を介してｕｐｌｉｎｋ／ｄｏｗｎｌｉｎｋ ＬｉｎｋとＴＩＤ間のマッピングが交渉される場合、交渉されたＴＩＤがＭＬ通信のために用いられる。

ＭＬ設定（ｓｅｔｕｐ）を介してＭＬ通信に関連する送信ＭＬＤ及び受信ＭＬＤが使用できる複数のＬｉｎｋが設定され、これを「ｅｎａｂｌｅｄ ｌｉｎｋ」と呼ぶことができる。「ｅｎａｂｌｅｄ ｌｉｎｋ」は様々な表現で呼ぶことができる。例えば、第１Ｌｉｎｋ、第２Ｌｉｎｋ、送信Ｌｉｎｋ、受信Ｌｉｎｋなどの様々な表現で呼ぶことができる。

ＭＬ設定（ｓｅｔｕｐ）が完了した以降、ＭＬＤはＭＬ設定（ｓｅｔｕｐ）を更新することができる。例えば、ＭＬＤはリンクに関する情報に対する更新が必要な場合、新しいリンクに関する情報を送信することができる。新しいリンクに関する情報はｍａｎａｇｅｍｅｎｔ ｆｒａｍｅ、ｃｏｎｔｒｏｌ ｆｒａｍｅ及びｄａｔａ ｆｒａｍｅのうち、少なくとも１つに基づいて送信される。

以下において説明されるデバイスは図１及び／又は図１１の装置であり、ＰＰＤＵは図１０のＰＰＤＵであり得る。デバイスはＡＰ又はｎｏｎ－ＡＰ ＳＴＡであり得る。以下において説明されるデバイスはマルチリンクをサポートするＡＰ ＭＬＤ（ｍｕｌｔｉ－ｌｉｎｋ Ｄｅｖｉｃｅ）又はｎｏｎ－ＡＰ ＳＴＡ ＭＬＤであり得る。

８０２．１１ａｘ以降、議論されている標準であるＥＨＴ（Ｅｘｔｒｅｍｅｌｙ Ｈｉｇｈ Ｔｈｒｏｕｇｈｐｕｔ）においては１つ以上の帯域を同時に使用するマルチリンク環境が考慮されている。デバイスがマルチリンクをサポートするようになれば、デバイスは１つ以上の帯域（例えば、２．４ＧＨｚ、５ＧＨｚ、６ＧＨｚ、６０ＧＨｚなど）を同時又は交互に使用することができる。

以下の明細書において、ＭＬＤはｍｕｌｔｉ－ｌｉｎｋ Ｄｅｖｉｃｅを意味する。ＭＬＤは１つ以上の接続されたＳＴＡを持っており上位リンク層（Ｌｏｇｉｃａｌ Ｌｉｎｋ Ｃｏｎｔｒｏｌ，ＬＬＣ）へ通じる１つのＭＡＣ ＳＡＰ（ｓｅｒｖｉｃｅ ａｃｃｅｓｓ ｐｏｉｎｔ）を持っている。ＭＬＤは物理機器を意味するか論理機器を意味する。以下においてデバイスはＭＬＤを意味する。

以下の明細書において、送信デバイス及び受信デバイスはＭＬＤを意味する。受信／送信デバイスの第１リンクは前記受信／送信デバイスに含まれた、第１リンクを介して信号送受信を実行する端末（例えば、ＳＴＡ又はＡＰ）であり得る。受信／送信デバイスの第２リンクは前記受信／送信デバイスに含まれた、第２リンクを介して信号送受信を実行する端末（例えば、ＳＴＡ又はＡＰ）であり得る。

ＩＥＥＥ ８０２．１１ｂｅにおいては大きく２種類のマルチリンク動作をサポートすることができる。例えばＳＴＲ（ｓｉｍｕｌｔａｎｅｏｕｓ ｔｒａｎｓｍｉｔ ａｎｄ ｒｅｃｅｉｖｅ）及びｎｏｎ－ＳＴＲ動作が考慮される。例えば、ＳＴＲは非同期マルチリンク動作（ａｓｙｎｃｈｒｏｎｏｕｓ ｍｕｌｔｉ－ｌｉｎｋ ｏｐｅｒａｔｉｏｎ）と呼ぶことができ、ｎｏｎ－ＳＴＲは同期マルチリンク動作（ｓｙｎｃｈｒｏｎｏｕｓ ｍｕｌｔｉ－ｌｉｎｋ ｏｐｅｒａｔｉｏｎ）と呼ぶことができる。マルチリンクはマルチバンドを含むことができる。すなわち、マルチリンクは複数周波数バンドに含まれたリンクを意味し、１つの周波数バンド内に含まれた複数のリンクを意味することもできる。

ＥＨＴ（１１ｂｅ）においてはｍｕｌｔｉ－ｌｉｎｋ技術を考慮しており、ここでｍｕｌｔｉ－ｌｉｎｋはｍｕｌｔｉ－ｂａｎｄを含むことができる。すなわち、ｍｕｌｔｉ－ｌｉｎｋは複数ｂａｎｄのｌｉｎｋを示すことができる同時に１つのｂａｎｄ内の複数のｍｕｌｔｉ－ｌｉｎｋを示すことができる。大きく２種類のｍｕｌｔｉ－ｌｉｎｋ ｏｐｅｒａｔｉｏｎが考慮されている。複数のｌｉｎｋにおいて同時にＴＸ／ＲＸをできるようにするＡｓｙｎｃｈｒｏｎｏｕｓ ｏｐｅｒａｔｉｏｎと可能でないＳｙｎｃｈｒｏｎｏｕｓ ｏｐｅｒａｔｉｏｎを考慮している。以下においては複数のｌｉｎｋにおいて受信と送信が同時にできるようにするｃａｐａｂｉｌｉｔｙをＳＴＲ（ｓｉｍｕｌｔａｎｅｏｕｓ ｔｒａｎｓｍｉｔ ａｎｄ ｒｅｃｅｉｖｅ）といい、ＳＴＲ ｃａｐａｂｉｌｉｔｙを持つＳＴＡをＳＴＲ ＭＬＤ（ｍｕｌｔｉ－ｌｉｎｋ Ｄｅｖｉｃｅ）、ＳＴＲ ｃａｐａｂｉｌｉｔｙを持っていないＳＴＡをｎｏｎ－ＳＴＲ ＭＬＤという。

以下の明細書においては説明の便宜上、ＭＬＤ（又はＭＬＤのプロセッサ）が少なくとも１つのＳＴＡを制御することで説明されるが、これに限られるものではない。上述した通り、前記少なくとも１つのＳＴＡはＭＬＤと関係なく独立して信号を送受信することもできる。

一実施形態によれば、ＡＰ ＭＬＤ又は非ＡＰ ＭＬＤは複数のリンクを持つ構造で構成される。別の言い方をすると、非ＡＰ ＭＬＤは複数のリンクをサポートすることができる。非ＡＰ ＭＬＤは複数のＳＴＡを含むことができる。複数のＳＴＡは各ＳＴＡ別にＬｉｎｋを持つことができる。

ＥＨＴ規格（８０２．１１ｂｅ規格）においては１つのＡＰ／非ＡＰ ＭＬＤが複数のＬｉｎｋをサポートするＭＬＤ（Ｍｕｌｔｉ－Ｌｉｎｋ Ｄｅｖｉｃｅ）構造を主要技術に考慮している。非ＡＰ ＭＬＤに含まれたＳＴＡは１つのＬｉｎｋを介して非ＡＰ ＭＬＤ内の別のＳＴＡに対する情報をともに転送することができる。従って、フレーム交換のオーバーヘッドが減る効果がある。また、ＳＴＡのリンク使用効率を増加させ消費電力を減らせる効果がある。

図１２は非ＡＰ ＭＬＤの構造の例を示す。

図１２を参照すると、非ＡＰ ＭＬＤは複数のリンクを持つ構造で構成される。別の言い方をすると、非ＡＰ ＭＬＤは複数のリンクをサポートすることができる。非ＡＰ ＭＬＤは複数のＳＴＡを含むことができる。複数のＳＴＡは各ＳＴＡ別にＬｉｎｋを持つことができる。図１２は非ＡＰ ＭＬＤ構造の一例を示したが、ＡＰ ＭＬＤの構造も図１２において示された非ＡＰ ＭＬＤの構造の一例と同じく構成される。

例えば、非ＡＰ ＭＬＤはＳＴＡ１、ＳＴＡ２及びＳＴＡ３を含むことができる。ＳＴＡ１はＬｉｎｋ １において動作することができる。Ｌｉｎｋ １は５ＧＨｚバンド内に含まれる。ＳＴＡ２はｌｉｎｋ２において動作することができる。ｌｉｎｋ２は６ＧＨｚバンド内に含まれる。ＳＴＡ３はｌｉｎｋ３において動作することができる。ｌｉｎｋ３は６ＧＨｚバンド内に含まれる。Ｌｉｎｋ １／２／３が含まれるバンドは例示的なことであり、２．４、５、及び６ＧＨｚ内に含まれる。

このように、Ｍｕｌｔｉ－ｌｉｎｋをサポートするＡＰ／非ＡＰ ＭＬＤの場合、ＡＰ ＭＬＤの各ＡＰと非ＡＰ ＭＬＤの各ＳＴＡがＬｉｎｋ ｓｅｔｕｐプロセスを介してそれぞれのＬｉｎｋに接続される。そしてこのとき接続されたＬｉｎｋは状況によってＡＰ ＭＬＤ又は非ＡＰ ＭＬＤによって別のＬｉｎｋに変更又は再接続される。

また、ＥＨＴ規格においては消費電力減少のために、ＬｉｎｋがＡｎｃｈｏｒｅｄ ｌｉｎｋ又はｎｏｎ－Ａｎｃｈｏｒｅｄ ｌｉｎｋで分けることができる。Ａｎｃｈｏｒｅｄ ｌｉｎｋ又はｎｏｎ－Ａｎｃｈｏｒｅｄ ｌｉｎｋは多様に呼ぶことができる。例えば、Ａｎｃｈｏｒｅｄ ｌｉｎｋはＰｒｉｍａｒｙ Ｌｉｎｋと呼ぶことができる。ｎｏｎ－Ａｎｃｈｏｒｅｄ ｌｉｎｋはＳｅｃｏｎｄａｒｙ ｌｉｎｋと呼ぶことができる。

一実施形態によれば、Ｍｕｌｔｉ－ｌｉｎｋをサポートするＡＰ ＭＬＤは各ＬｉｎｋをＡｎｃｈｏｒｅｄ ｌｉｎｋ又はｎｏｎ－Ａｎｃｈｏｒｅｄ Ｌｉｎｋに指定することで管理することができる。ＡＰ ＭＬＤは複数のＬｉｎｋのうち、１つ以上のＬｉｎｋをＡｎｃｈｏｒｅｄ ｌｉｎｋにサポートすることができる。非ＡＰ ＭＬＤはＡｎｃｈｏｒｅｄ ｌｉｎｋ Ｌｉｓｔ（ＡＰ ＭＬＤがサポートするＡｎｃｈｏｒｅｄ ｌｉｎｋリスト）のうち、自身のＡｎｃｈｏｒｅｄ ｌｉｎｋを１つ又は１つ以上を選択することで使用することができる。

例えば、Ａｎｃｈｏｒｅｄ ｌｉｎｋはｓｙｎｃｈｒｏｎｉｚａｔｉｏｎのためのｆｒａｍｅ ｅｘｃｈａｎｇｅだけでなく、ｎｏｎ－ｄａｔａ ｆｒａｍｅ ｅｘｃｈａｎｇｅ（ｉ．ｅ．Ｂｅａｃｏｎ及びＭａｎａｇｅｍｅｎｔ ｆｒａｍｅ）のために用いられる。また、ｎｏｎ－Ａｎｃｈｏｒｅｄ ｌｉｎｋはｄａｔａ ｆｒａｍｅ ｅｘｃｈａｎｇｅのみのために用いられる。

非ＡＰ ＭＬＤはｉｄｌｅ期間の間Ｂｅａｃｏｎ及びＭａｎａｇｅｍｅｎｔ ｆｒａｍｅ受信のために Ａｎｃｈｏｒｅｄ ｌｉｎｋに対してのみモニタリング（又はｍｏｎｉｔｏｒ）することができる。そのため、非ＡＰ ＭＬＤの場合、Ｂｅａｃｏｎ及びｍａｎａｇｅｍｅｎｔ ｆｒａｍｅ受信のために最小１つ以上のＡｎｃｈｏｒｅｄ ｌｉｎｋと接続される必要がある。前記１つ以上のＡｎｃｈｏｒｅｄ ｌｉｎｋは常にｅｎａｂｌｅ状態を維持する必要がある。これとは違って、ｎｏｎ－Ａｎｃｈｏｒｅｄ ｌｉｎｋは ｄａｔａ ｆｒａｍｅ ｅｘｃｈａｎｇｅのみのために使用される。従って、ｎｏｎ－Ａｎｃｈｏｒｅｄ ｌｉｎｋに該当するＳＴＡ（又はｎｏｎ－Ａｎｃｈｏｒｅｄ ｌｉｎｋに接続されたＳＴＡ）はｃｈａｎｎｅｌ／ｌｉｎｋを使用しないｉｄｌｅ期間の間ｄｏｚｅに進入することができる。これを介して消費電力を減らせる効果がある。

従って、以下の明細書においては効率的なＬｉｎｋ接続のために状況によってダイナミックにＡＰ ＭＬＤ又は非ＡＰ ＭＬＤがＬｉｎｋ再接続を推奨又は要求するプロトコルが提案される。また、以下の明細書においては、通常のＬｉｎｋだけでなく電力減少を目的で使用するＡｎｃｈｏｒｅｄ ｌｉｎｋの特性を考慮したＡｎｃｈｏｒｅｄ ｌｉｎｋ再接続プロトコルがさらに提案される。

Ｌｉｎｋ変更及び再接続のための実施形態

一実施形態によれば、ＡＰ ＭＬＤ及び非ＡＰ ＭＬＤ間の各ＬｉｎｋはＡｓｓｏｃｉａｔｉｏｎ又は（ｒｅ）Ａｓｓｏｃｉａｔｉｏｎプロセスにおいて決定される。このとき接続されたＬｉｎｋを介してＡＰ ＭＬＤ及び非ＡＰ ＭＬＤはｆｒａｍｅ ｅｘｃｈａｎｇｅを実行することができる。Ｌｉｎｋ ｓｅｔｕｐプロセスを介してＡＰ ＭＬＤ及び非ＡＰ ＭＬＤが接続される具体的な実施形態が図１３を介して説明される。

図１３はＬｉｎｋ ｓｅｔｕｐプロセスを介してＡＰ ＭＬＤ及び非ＡＰ ＭＬＤが接続される例を示す。

図１３を参照すると、ＡＰ ＭＬＤはＡＰ１、ＡＰ２及びＡＰ３を含むことができる。非ＡＰ ＭＬＤはＳＴＡ１及びＳＴＡ２を含むことができる。ＡＰ１及びＳＴＡ１はＬｉｎｋ １を介して接続される。ＡＰ２及びＳＴＡ２はｌｉｎｋ２を介して接続される。

例えば、ＡＰ１及びＳＴＡ１は第１Ｌｉｎｋ ｓｅｔｕｐプロセスを介してＬｉｎｋ １を介して接続される。ＡＰ２及びＳＴＡ２は第２Ｌｉｎｋ ｓｅｔｕｐプロセスを介してｌｉｎｋ２を介して接続される。別の例では、ＡＰ ＭＬＤ及び非ＡＰ ＭＬＤは１回のＬｉｎｋ ｓｅｔｕｐプロセスを介して接続される。別の言い方をすると、ＡＰ ＭＬＤ及び非ＡＰ ＭＬＤは１回のＬｉｎｋ ｓｅｔｕｐプロセスに基づいて、Ｌｉｎｋ １及びｌｉｎｋ２を介して接続される。

上述した通り、それぞれのＡＰ及びＳＴＡは接続されたＬｉｎｋを介してｆｒａｍｅ ｅｘｃｈａｎｇｅを実行することができる。また、１つのＬｉｎｋを介して他のｌｉｎｋに関するｏｔｈｅｒ ＡＰ又は他のｌｉｎｋに関するｏｔｈｅｒ ＳＴＡの情報が送受信される。

しかし、このようなＬｉｎｋ ｓｅｔｕｐプロセス以降、状況／環境によってさらに効率的なｆｒａｍｅ ｅｘｃｈａｎｇｅ（例えば、Ｌｏａｄ ｂａｌａｎｃｉｎｇ又はｉｎｔｅｒｆｅｒｅｎｃｅ ａｖｏｉｄｉｎｇなど）のためにＡＰ ＭＬＤ又は非ＡＰ ＭＬＤはＬｉｎｋ変更又は再接続を要求することができる。

Ｌｉｎｋ変更又は再接続に関する実施形態が図１４を介して説明される。

図１４はＬｉｎｋが変更又は再接続される例を示す。

図１４を参照すると、既存ではＳＴＡ２がＡＰ２に接続されている。以降、ＡＰ２のＤａｔａ ｌｏａｄが過渡に発生することができる。比較的Ｄａｔａ ｌｏａｄが少ないＡＰ３にＳＴＡ２が再接続される。この場合、ＡＰ ＭＬＤ及び非ＡＰ ＭＬＤが効率的なデータ交換を実行できる効果がある。

図１５はＬｉｎｋが変更又は再接続される具体的な例を示す。

図１５を参照すると、ＡＰ ＭＬＤのＡＰ１は非ＡＰ ＭＬＤのＳＴＡ１とＬｉｎｋ １を介して接続される。ＡＰ ＭＬＤのＡＰ２は非ＡＰ ＭＬＤのＳＴＡ２とｌｉｎｋ２を介して接続される。以降、ＳＴＡ２はｌｉｎｋ変更又は再接続を介してＡＰ３と接続を試み／要求することができ、ＳＴＡ２は前記ｌｉｎｋ変更又は再接続に基づいて、ＡＰ３とｌｉｎｋ２を介して接続される。

一実施形態によれば、非ＡＰ ＭＬＤとＡＰ ＭＬＤは性能向上のためにＬｉｎｋ ｔｒａｎｓｉｔｉｏｎを要求することができる。ＡＰ ＭＬＤ及び非ＡＰ ＭＬＤは現在Ｌｉｎｋ別様々な情報及びｌｉｎｋ状態（ｓｔａｔｅ）に関する情報を送受信／交換することができる。従って、ＡＰ ＭＬＤ及び非ＡＰ ＭＬＤは現在Ｌｉｎｋ別様々な情報及びｌｉｎｋ状態（ｓｔａｔｅ）に基づいて、信号を送受信するためにさらに適したｌｉｎｋを選択することができ、選択をサポートするために上述した情報を送信することができる。例えば、現在Ｌｉｎｋ別様々な情報は各Ｌｉｎｋ別Ｄａｔａ ｔｒａｆｆｉｃ ｌｏａｄ、Ｌｉｎｋ間Ｃｈａｎｎｅｌ ａｃｃｅｓｓ ｃａｐａｂｉｌｉｔｙに関する情報を含むことができる。例えば、ｌｉｎｋ状態（ｓｔａｔｅ）はｄｉｓａｂｌｅ又はｅｎａｂｌｅなどとして設定される。

以下の明細書においては、ＡＰ ＭＬＤ／非ＡＰ ＭＬＤが性能を高めるために接続されたＬｉｎｋではない別のＬｉｎｋに変更又は再接続を要求するために非ＡＰ ＭＬＤ／ＡＰ ＭＬＤと交渉するプロセスが「Ｌｉｎｋ ｓｗｉｔｃｈｉｎｇ ｎｅｇｏｔｉａｔｉｏｎ」と呼ばれる。前記「Ｌｉｎｋ ｓｗｉｔｃｈｉｎｇ ｎｅｇｏｔｉａｔｉｏｎ」の名称は多様に呼ぶことができ、これは変更できる。

Ｌｉｎｋ ｓｗｉｔｃｈｉｎｇ ｎｅｇｏｔｉａｔｉｏｎプロセスにおいて非ＡＰ ＭＬＤ（又はＡＰ ＭＬＤ）は特定のＳＴＡに接続されたＬｉｎｋを別のＬｉｎｋに変更するように要求し、この要求に対してＡＰ ＭＬＤ（又は非ＡＰ ＭＬＤ）は要求承認又は拒否メッセージを介して応答することができる。

一例として、図１５に示しているように、Ｌｉｎｋ ｓｗｉｔｃｈｉｎｇ ｎｅｇｏｔｉａｔｉｏｎを介してＬｉｎｋ変更が合意された場合、ＳＴＡは既存のＬｉｎｋをＡＰ２においてＡＰ３に変更して再接続されるＬｉｎｋ ｒｅ－ｓｅｔｕｐプロセスを実行することができる。

以下においてはＬｉｎｋ変更又は再接続プロセスがＡＰ ＭＬＤが要求する場合、及び非ＡＰ ＭＬＤが要求する場合に分けて説明される。

ＡＰ ＭＬＤがＬｉｎｋ変更又は再接続を要求する実施形態

一実施形態によれば、ＡＰ ＭＬＤは効率的なデータ送信のために非ＡＰ ＭＬＤにＬｉｎｋ変更又は再接続を要求することができる。例えば、Ｌｏａｄ ｂａｌａｎｃｉｎｇのために各ＡＰのＤａｔａ ｔｒａｆｆｉｃに基づいて、ＡＰ ＭＬＤはＳＴＡにさらに効率的なＬｉｎｋに変更又は再接続を要求することができる。

例えば、ＡＰ ＭＬＤは各ＡＰ別Ｄａｔａ ｔｒａｆｆｉｃ ｌｏａｄ情報及び／又は各Ｌｉｎｋ間Ｃｈａｎｎｅｌ ａｃｃｅｓｓ ｃａｐａｂｉｌｉｔｙ情報（例えば、ＳＴＲ（Ｓｉｍｕｌｔａｎｅｏｕｓ ＴＸ／ＲＸ）ｃａｐａｂｉｌｉｔｙに関する情報など）などに基づいて、非ＡＰ ＭＬＤのＳＴＡに適したＬｉｎｋを計算／確認／確定することができる。以降、ＡＰ ＭＬＤは各ＡＰ別Ｄａｔａ ｔｒａｆｆｉｃ ｌｏａｄ情報及び／又は各Ｌｉｎｋ間Ｃｈａｎｎｅｌ ａｃｃｅｓｓ ｃａｐａｂｉｌｉｔｙ情報などに基づいて、ＳＴＡ（又は非ＡＰ ＭＬＤ）にｌｉｎｋ変更又は再接続を要求することができる。

上述した通り、Ｌｉｎｋ変更要求時、ＡＰ ＭＬＤは要求メッセージを介して最も適すると考えるＬｉｎｋ情報を非ＡＰ ＭＬＤに送信することができる。例えば、前記要求メッセージはＢｅａｃｏｎ又はｍａｎａｇｅｍｅｎｔ ｆｒａｍｅなどを含むことができる。

上述した実施形態に関連して、最も適すると考えるＬｉｎｋ情報が含まれたｅｌｅｍｅｎｔ又はｆｉｅｌｄが新しく提案される。新しく提案されたｅｌｅｍｅｎｔ又はｆｉｅｌｄが「ｒｅｃｏｍｍｅｎｄｅｄ ｌｉｎｋ」と定義される。「ｒｅｃｏｍｍｅｎｄｅｄ ｌｉｎｋ」は例示的なことであり、具体的なｅｌｅｍｅｎｔ又はｆｉｅｌｄの名称は変更できる。

ｒｅｃｏｍｍｅｎｄ ｌｉｎｋ（ｅｌｅｍｅｎｔ／ｆｉｅｌｄ）：ＡＰ ＭＬＤが各Ｌｉｎｋ別様々な情報（例えば、Ｌｉｎｋ別ｄａｔａ ｌｏａｄなど）に基づいて、非ＡＰ ＭＬＤのＳＴＡに最も適したＬｉｎｋを推奨するためのｅｌｅｍｅｎｔ又はｆｉｅｌｄ。例えば、ｒｅｃｏｍｍｅｎｄ ｌｉｎｋ（ｅｌｅｍｅｎｔ／ｆｉｅｌｄ）はＡＰ ＭＬＤのＬｉｎｋ ＩＤ情報又はＡＰ ＢＳＳ情報などで指示される。別の言い方をすると、ｒｅｃｏｍｍｅｎｄ ｌｉｎｋ（ｅｌｅｍｅｎｔ／ｆｉｅｌｄ）はＡＰ ＭＬＤのＬｉｎｋ ＩＤ情報又はＡＰ ＢＳＳ情報などを含むことができる。

一実施形態によれば、前記ｒｅｃｏｍｍｅｎｄ ｌｉｎｋ（ｅｌｅｍｅｎｔ／ｆｉｅｌｄ）はｏｐｔｉｏｎａｌにＬｉｎｋ ｓｗｉｔｃｈｉｎｇ Ｒｅｓｐｏｎｓｅに含まれ送信される。例えば、ＳＴＡは前記ｅｌｅｍｅｎｔ／ｆｉｅｌｄ（すなわち、ｒｅｃｏｍｍｅｎｄ ｌｉｎｋ）に基づいて、ＡＰが推奨したＬｉｎｋに接続を確立することができる。別の例では、ＳＴＡは前記ｅｌｅｍｅｎｔ／ｆｉｅｌｄ（すなわち、ｒｅｃｏｍｍｅｎｄ ｌｉｎｋ）及び自身が持った追加情報に基づいて、指示されたＬｉｎｋと別のＬｉｎｋに接続要求を実行することもできる。

上述した実施形態に係るＡＰ ＭＬＤ及び非ＡＰ ＭＬＤの具体的な信号交換プロセスが図１６を介して説明される。

図１６はｌｉｎｋ変更又は再接続のためのＡＰ ＭＬＤ及び非ＡＰ ＭＬＤの動作を示す。

図１６を参照すると、ＳＴＡ２がｌｉｎｋ２を介してＡＰ２と接続された状況において、ＡＰ２に多くのＤａｔａ ｔｒａｆｆｉｃが集中する可能性がある。別の言い方をすると、ＳＴＡ２がｌｉｎｋ２を介してＡＰ２と接続された状況において、ＡＰ２に多くのＤａｔａ ｔｒａｆｆｉｃが発生する。

ＡＰ ＭＬＤ（又はＡＰ２）は比較的ＳＴＡの接続が少ないＡＰ３に再接続することを非ＡＰ ＭＬＤ（又はＳＴＡ２）に要求することができる。通常再接続を要求するためのメッセージは再接続を希望するＳＴＡ（すなわち、ＳＴＡ２）に送信するが、状況（例えば、チャネル状況又はリンク状態）によって、どんなＳＴＡ（すなわち、ｏｔｈｅｒ ＳＴＡ）にも送信される。別の言い方をすると、チャネル状況又はリンク状態に基づいて、再接続を要求するための要求メッセージ（例えば、Ｌｉｎｋ ｓｗｉｔｃｈｉｎｇ ｒｅｑｕｅｓｔ ｆｒａｍｅ）が送信されるＳＴＡが変更できる。

例えば、前記再接続を要求するための要求メッセージを受信したＳＴＡ（すなわち、ＳＴＡ２）はこの要求を承認する場合、「承認（Ａｃｃｅｐｔ）」の応答メッセージ（例えば、Ｌｉｎｋ ｓｗｉｔｃｈｉｎｇ Ｒｅｓｐｏｎｓｅ ｆｒａｍｅ）を送信することができる。別の例では、前記ＳＴＡ（すなわち、ＳＴＡ２）はこの要求を拒否する場合、「拒否（Ｄｅｃｌｉｎｅ）」の応答メッセージを送信することができる。

通常再接続を承認するＳＴＡ（すなわち、ＳＴＡ２）が既存のＬｉｎｋ（再接続以前接続Ｌｉｎｋ）に応答メッセージを送信するが、前記応答メッセージはｍｕｌｔｉ－ｌｉｎｋの特性を用いてどのＬｉｎｋ（すなわち、別のＳＴＡ）を介しても送信される。

もし、ＳＴＡ２がｌｉｎｋ再接続要求を承認する場合、応答メッセージ送信以降、ＳＴＡ２は既存のＡＰ２との接続を切断しＡＰ３に対してＬｉｎｋ再接続を要求することができる。このとき、再接続要求プロセスが既存のＭＬＤ間のＬｉｎｋ ｓｅｔｕｐプロセスと同じく実行することができる。ＡＰ３及びＳＴＡ２間のＬｉｎｋ ｓｅｔｕｐプロセスが完了した後、ＳＴＡ２はＬｉｎｋ２を介してＡＰ３とＦｒａｍｅ ｅｘｃｈａｎｇｅを実行することができる。

逆に、ＳＴＡ２がｌｉｎｋ再接続要求を拒否する場合、ＳＴＡ２及びＡＰ２は既存の接続されたＬｉｎｋ（すなわち、ｌｉｎｋ２）をそのまま使用することができる。

一実施形態によれば、ＡＰがＳＴＡにリンク変更を要求するとき、適したＬｉｎｋを推奨した場合、ＳＴＡは推奨されたＬｉｎｋにｌｉｎｋを変更することもでき、変更しない場合もある。例えば、ＡＰがＳＴＡに適したｌｉｎｋを推奨するために上述したｒｅｃｏｍｍｅｎｄ ｌｉｎｋが用いられる。

例えば、ＳＴＡはＡＰの再接続を要求するための要求メッセージに対する応答メッセージでＬｉｎｋ変更を承認することができる。ＳＴＡは推奨Ｌｉｎｋにｌｉｎｋ変更を承認／確認することができ、前記要求メッセージに含まれた情報以外の別の情報に基づいて、別のＬｉｎｋ変更をＡＰに要求することもできる。

従って、ＡＰは前記応答メッセージに対する承認可否をＳＴＡに知らせる必要がある。このためＡＰはＳＴＡの応答メッセージ（例えば、Ｌｉｎｋ ｓｗｉｔｃｈｉｎｇ Ｒｅｓｐｏｎｓｅ ｆｒａｍｅ）に対するＣｏｎｆｉｒｍａｔｉｏｎメッセージ（例えば、ｌｉｎｋ ｓｗｉｔｃｈｉｎｇ ｃｏｎｆｉｒｍａｔｉｏｎ ｆｒａｍｅ）をＳＴＡに送信することができる。

上述した実施形態のＡＰ ＭＬＤ及び非ＡＰ ＭＬＤの具体的な動作が図１７を介して説明される。

図１７はｌｉｎｋ変更又は再接続のためのＡＰ ＭＬＤ及び非ＡＰ ＭＬＤの動作を示す。

図１７を参照すると、ＡＰ２は推奨リンク情報を含めてＳＴＡ２にリンク変更を要求することができる。別の言い方をすると、ＡＰ２は推奨リンク情報を含むＬｉｎｋ ｓｗｉｔｃｈｉｎｇ ｒｅｑｕｅｓｔ ｆｒａｍｅをＳＴＡ２に送信することができる。

ＳＴＡ２はリンク要求承認可否をＬｉｎｋ ｓｗｉｔｃｈｉｎｇ Ｒｅｓｐｏｎｓｅ ｆｒａｍｅを介して送信することができる。

例えば、Ｌｉｎｋ ｓｗｉｔｃｈｉｎｇを承認した場合、ＳＴＡ２はＬｉｎｋ ｓｗｉｔｃｈｉｎｇ Ｒｅｓｐｏｎｓｅ ｆｒａｍｅに変更するＬｉｎｋ情報を含めて送信することができる。このとき、変更するＬｉｎｋ情報は推奨リンクと同じであるか同じではない場合もある。

別の例では、ＳＴＡ２がＡＰ２が提供した推奨リンクではない別のリンクを選択してＬｉｎｋ ｓｗｉｔｃｈｉｎｇ Ｒｅｓｐｏｎｓｅ ｆｒａｍｅで応答した場合、ＡＰはこれに対する最終承認可否に対するメッセージをＳＴＡに送信することができる。前記メッセージはＬｉｎｋ ｓｗｉｔｃｈｉｎｇ ｃｏｎｆｉｒｍａｔｉｏｎ ｆｒａｍｅで呼ぶことができる。

一例として、ＡＰ２はＬｉｎｋ ｓｗｉｔｃｈｉｎｇ ｃｏｎｆｉｒｍａｔｉｏｎ ｆｒａｍｅを介して、ＳＴＡ２が決めたＬｉｎｋにｌｉｎｋ変更することを承認することができる。ＳＴＡ２はＬｉｎｋ ｓｗｉｔｃｈｉｎｇ ｃｏｎｆｉｒｍａｔｉｏｎ ｆｒａｍｅに基づいて、自身が指定したＬｉｎｋにｌｉｎｋ変更を試みすることができる。

別の一例として、ＡＰ２はＬｉｎｋ ｓｗｉｔｃｈｉｎｇ ｃｏｎｆｉｒｍａｔｉｏｎ ｆｒａｍｅを介して、ＳＴＡ２が決めたＬｉｎｋにｌｉｎｋ変更することを拒否することができる。ＳＴＡ２及びＡＰ２はｌｉｎｋ変更なしに既存に接続されたＬｉｎｋとの接続を維持することができる。

図１７において示された実施形態はＡＰがＬｉｎｋ ｓｗｉｔｃｈｉｎｇ ｒｅｑｕｅｓｔ ｆｒａｍｅに推奨リンク情報を含まず送信した場合も適用される。例えば、ＡＰ（例えば、ＡＰ２）がＳＴＡ（例えば、ＳＴＡ２）に推奨リンク情報なしにＬｉｎｋ ｓｗｉｔｃｈｉｎｇ ｒｅｑｕｅｓｔ ｆｒａｍｅを送信した場合、ＳＴＡは自身が持った情報に基づいて、直接変更Ｌｉｎｋを指定した後、ＡＰにＬｉｎｋ ｓｗｉｔｃｈｉｎｇ Ｒｅｓｐｏｎｓｅ ｆｒａｍｅを介して応答することができる。この場合もＡＰは最終的に承認に対するＬｉｎｋ ｓｗｉｔｃｈｉｎｇ ｃｏｎｆｉｒｍａｔｉｏｎ ｆｒａｍｅを送信する必要がある。従って、Ｌｉｎｋ ｓｗｉｔｃｈｉｎｇ ｒｅｑｕｅｓｔ ｆｒａｍｅに推奨リンク情報が含まれない場合もＡＰがＬｉｎｋ ｓｗｉｔｃｈｉｎｇ ｃｏｎｆｉｒｍａｔｉｏｎ ｆｒａｍｅを送信する実施形態が適用される。

非ＡＰ ＭＬＤがＬｉｎｋ変更又は再接続を要求する実施形態

一実施形態によれば、非ＡＰ ＭＬＤは効率的なデータ送信のためにＡＰ ＭＬＤにＬｉｎｋ変更又は再接続を要求することができる。例えば、データ送信時ＳＴＲ ｃａｐａｂｉｌｉｔｙを使用するために、非ＡＰ ＭＬＤがＡＰ ＭＬＤに接続Ｌｉｎｋ変更又は再接続を要求することができる。

図１８はｌｉｎｋ変更又は再接続のためのＡＰ ＭＬＤ及び非ＡＰ ＭＬＤの動作を示す。

図１８を参照すると、ＡＰ ＭＬＤ及び非ＡＰ ＭＬＤはＬｉｎｋ ｓｗｉｔｃｈｉｎｇ ｎｅｇｏｔｉａｔｉｏｎを実行することができる。非ＡＰ ＭＬＤのＳＴＡ２はＬｉｎｋ ｓｗｉｔｃｈｉｎｇ ｒｅｑｕｅｓｔ ｆｒａｍｅをＡＰ ＭＬＤのＡＰ２に送信することができる。ＡＰ ＭＬＤのＡＰ２は前記Ｌｉｎｋ ｓｗｉｔｃｈｉｎｇ ｒｅｑｕｅｓｔ ｆｒａｍｅに応答して、Ｌｉｎｋ ｓｗｉｔｃｈｉｎｇ Ｒｅｓｐｏｎｓｅ ｆｒａｍｅを非ＡＰ ＭＬＤのＳＴＡ２に送信することができる。Ｌｉｎｋ ｓｗｉｔｃｈｉｎｇ ｒｅｑｕｅｓｔ ｆｒａｍｅ又はＬｉｎｋ ｓｗｉｔｃｈｉｎｇ Ｒｅｓｐｏｎｓｅ ｆｒａｍｅは変更対象になるｌｉｎｋを介して送受信されるが、これに限られるものではない。Ｌｉｎｋ ｓｗｉｔｃｈｉｎｇ ｒｅｑｕｅｓｔ ｆｒａｍｅ又はＬｉｎｋ ｓｗｉｔｃｈｉｎｇ Ｒｅｓｐｏｎｓｅ ｆｒａｍｅは変更対象になるｌｉｎｋだけでなく様々なｌｉｎｋを介して送受信される。

非ＡＰ ＭＬＤは様々な方法を介してＬｉｎｋ変更又は再接続を要求することができる。以下においては非ＡＰ ＭＬＤがＬｉｎｋ変更又は再接続を要求する３つの方法が提案される。具体的には、前記３つの方法はＳｏｌｉｃｉｔｅｄ方法、Ｕｎｓｏｌｉｃｉｔｅｄ方法、及びＧｅｎｅｒａｌ方法が順番に説明される。

１）Ｓｏｌｉｃｉｔｅｄ方法：非ＡＰ ＭＬＤがＡＰ ＭＬＤにＬｉｎｋ（ｒｅ）ｓｅｌｅｃｔｉｏｎのための様々な情報を要求し、これを介して様々な情報を受信する方法。例えば、様々な情報はｃａｐａｂｉｌｉｔｙ、ｏｐｅｒａｔｉｏｎ ｅｌｅｍｅｎｔ、ＢＳＳ Ｐａｒａｍｅｔｅｒｓに関する情報を含むことができる。

一実施形態によれば、ＳＴＡが接続ＡＰ ＭＬＤのｏｔｈｅｒ ＡＰｓの情報を要求する方法はｌｉｎｋを再設定する場合だけでなく、様々な場合に用いられる。例えば、ｍｕｌｔｉ－Ｌｉｎｋ ｓｅｔｕｐ以降、ＳＴＡはＬｉｎｋ ｓｗｉｔｃｈｉｎｇのためにｏｔｈｅｒ ＡＰのＢＳＳ ｐａｒａｍｅｔｅｒ情報を要求し、受信した情報に基づいてｂｅｓｔｌｉｎｋを選択することができる。又はｄｉｓｃｏｖｅｒｙプロセスにおいてＳＴＡはＡＰ ＭＬＤに各ＡＰのＢＳＳ ｌｏａｄ情報を要求し、受信した情報に基づいてＬｉｎｋ ｓｅｔｕｐを実行するｌｉｎｋを選択することができる。（但し、非ＡＰ ＭＬＤのＳＴＡ数よりＡＰ ＭＬＤのＡＰ数が多い場合を仮定する。）

従って、情報要求メッセージを受信したＡＰはＡＰ ＭＬＤ内の全てのＡＰに対するＣａｐａｂｉｌｉｔｙ情報、ＢＳＳ ｐａｒａｍｅｔｅｒ情報、ｃｒｉｔｉｃａｌ ｐａｒａｍｅｔｅｒｓ、及び／又はＯｐｅｒａｔｉｏｎ ｅｌｅｍｅｎｔ情報などどの情報でも送信することができる。上述した例は以下において説明される実施形態に全て適用される。

２）Ｕｎｓｏｌｉｃｉｔｅｄ方法：非ＡＰ ＭＬＤの別途の情報要求なしに、ＡＰがＬｉｎｋ（ｒｅ）ｓｅｌｅｃｔｉｏｎのための様々な情報を送信する方法。ＳＴＡは受信した情報を様々な状況において活用することができる。一実施形態によれば、ＳＴＡの別途の情報要求なしに、ＡＰ ＭＬＤのＡＰがｏｔｈｅｒ ＡＰｓの情報を送信する方法はｌｉｎｋを再設定する場合だけでなく、様々な場合に用いられる。従って、情報要求メッセージを受信したＡＰはＡＰ ＭＬＤ内の全てのＡＰに対するＣａｐａｂｉｌｉｔｙ情報、ＢＳＳ ｐａｒａｍｅｔｅｒ情報、ｃｒｉｔｉｃａｌ ｐａｒａｍｅｔｅｒｓ、及び／又はＯｐｅｒａｔｉｏｎ ｅｌｅｍｅｎｔ情報など、どの情報でも送信することができる。上述した例は以下において説明される実施形態に全て適用される。

３）Ｇｅｎｅｒａｌ方法：非ＡＰ ＭＬＤが以前Ｂｅａｃｏｎ ｆｒａｍｅなどを介して獲得した情報に基づいて追加情報なしにＬｉｎｋ（ｒｅ）ｓｅｌｅｃｔｉｏｎを要求する方法

１）Ｓｏｌｉｃｉｔｅｄ方法

以下においては先ず上述したｓｏｌｉｃｉｔｅｄ方法に関する実施形態が説明される。

一実施形態によれば、非ＡＰ ＭＬＤはＬｉｎｋ変更又は再接続前にＡＰ ＭＬＤに適したＬｉｎｋを選択するための情報を要求することができる。ＳＴＡは適したＬｉｎｋを選択するために各ＡＰ別Ｄａｔａ ｌｏａｄ情報又は各ＬｉｎｋのＣａｐａｂｉｌｉｔｙ情報（又はｏｔｈｅｒ ｌｉｎｋの情報）などを活用することができる。

例えば、前記各Ｌｉｎｋ別Ｃａｐａｂｉｌｉｔｙ情報はＢｅａｃｏｎ ｆｒａｍｅなどに含まれ周期的に送信される。

別の例では、Ｌｉｎｋ別Ｃａｐａｂｉｌｉｔｙ情報はｏｐｔｉｏｎａｌ情報として周期ごとに送信されるＢｅａｃｏｎ ｆｒａｍｅに含まれない場合もある。又は、フレームオーバーヘッドを減らせるためにＳＴＡが接続されたリンク又は関連した一部のリンクの情報のみ受信される。又は、非ＡＰ ＭＬＤの特性（例えば、低電力デバイス）のためにＢｅａｃｏｎ受信周期が長い場合、非ＡＰ ＭＬＤはさらに適したＬｉｎｋ選択のためのＬｉｎｋ別Ｃａｐａｂｉｌｉｔｙ情報を受信できない場合がある。

上述した場合、において、非ＡＰ ＭＬＤはＬｉｎｋ別ｃａｐａｂｉｌｉｔｙ情報及びＡＰ ＭＬＤの各Ｌｉｎｋ別情報（例えば、ＢＳＳ ｐａｒａｍｅｔｅｒ情報又はＯｐｅｒａｔｉｏｎ ｅｌｅｍｅｎｔ情報など）の最新情報を要求することができる。前記ｌｉｎｋ別ｃａｐａｂｉｌｉｔｙ情報及び各Ｌｉｎｋ別情報のｌｉｎｋは送受信されるｌｉｎｋだけでなく、ｏｔｈｅｒ ｌｉｎｋも含むことができる。例えば、ＱｏＳ ｄａｔａ ｆｒａｍｅのｆｉｅｌｄ（１１ａｘ規格のＡ－Ｃｏｎｔｒｏｌ ｆｉｅｌｄ）、ｍａｎａｇｅｍｅｎｔ ｆｒａｍｅ、Ｐｒｏｂｅ ｒｅｓｐｏｎｓｅ／ｒｅｑｕｅｓｔ ｆｒａｍｅ、ＰＳ－Ｐｏｌｌフレーム又はＮｕｌｌ ｆｒａｍｅなどが最新情報を要求／送信するために用いられる。又は、最新情報を要求／送信するために、別途の新規フレームが定義される。

一実施形態によれば、Ｌｉｎｋ別ｃａｐａｂｉｌｉｔｙ情報及びＡＰ ＭＬＤの各Ｌｉｎｋ別情報の最新情報を要求するために、ＳＴＡはＡＰにＬｉｎｋ再選択のために必要な情報を要求する要求メッセージを送信することができる。例えば、前記要求メッセージのために従来に定義されたＰｒｏｂｅ Ｒｅｑｕｅｓｔ ｆｒａｍｅが再利用される。別の例では、前記要求メッセージのための新規フレームが定義される。

一実施形態によれば、前記要求メッセージを介して、ＳＴＡは必要な特定の情報を指定してＡＰに要求することもできる。指定できる特定の情報は状況によって変更できる。すなわち、ＳＴＡは特定のＬｉｎｋに該当する情報のみを要求するか、特定のＣａｐａｂｉｌｉｔｙに該当する情報のみを要求することもできる。例えば、特定のｌｉｎｋに該当する情報は特定のｌｉｎｋのＢＳＳ ｌｏａｄ／ｐａｒａｍｅｔｅｒｓに関する情報を含むことができる。また、Ｃａｐａｂｉｌｉｔｙに該当する情報は全てのｌｉｎｋ（ａｌｌ ｌｉｎｋ）のＢＳＳ ｌｏａｄ情報又は特定のｌｉｎｋのＢＳＳ ｌｏａｄ情報を含むことができる。この場合、ＡＰは応答メッセージを介してＳＴＡが指定した情報のみを送信することができる。特定の情報要求及び応答に関する具体的な実施形態がＩＯＭ定義及び動作に関する実施形態を介して説明される。

別の一例として、ＳＴＡは前記要求メッセージを介してＡＰ ＭＬＤが現在持った全てのＣａｐａｂｉｌｉｔｙ情報（ｅ．ｇ．ｏｔｈｅｒ ｌｉｎｋの情報も含む）を要求することもできる。

上述した例のようにＡＰが持った全ての情報を送信するための実施形態又はＳＴＡが指定した特定の情報のみを送信するための実施形態は多様に定義／設定される。例えば、ＡＰは特定の情報のみを指示（又は送信）するために別途のｆｉｅｌｄ又はｂｉｔｍａｐなどに基づいて、全ての情報又は指定された情報を送信することができる。

通常ＡＰ ＭＬＤに情報を要求するメッセージは再接続を希望するＳＴＡを介して送信されるが、状況によって（チャネル状況又はリンク状態）、どんなＳＴＡ（すなわち、ｏｔｈｅｒ ＳＴＡ）にも送信される。

前記要求メッセージを受信したＡＰ ＭＬＤはＳＴＡが要求した情報（例えば、Ｌｉｎｋ別ｄａｔａ ｌｏａｄ情報、Ｌｉｎｋ間ＳＴＲ ｃａｐａｂｉｌｉｔｙ情報など）を含めた応答メッセージ（すなわち、ｉｎｆｏｒｍａｔｉｏｎ ｍｅｓｓａｇｅ）を非ＡＰ ＭＬＤに送信することができる。例えば、前記要求メッセージのために従来規格のＰｒｏｂｅ Ｒｅｑｕｅｓｔ ｆｒａｍｅが再利用される場合、ＡＰ（又はＡＰ ＭＬＤ）は前記応答メッセージでＰｒｏｂｅ Ｒｅｓｐｏｎｓｅ ｆｒａｍｅを用いて応答する必要がある。

前記応答メッセージも通常Ｒｅｑｕｅｓｔ ｍｅｓｓａｇｅを受信したＡＰを介して送信されるが、ｍｕｌｔｉ－ｌｉｎｋの特性を用いてどんなＡＰ（すなわち、ｏｔｈｅｒ ＡＰ）にも送信される。

選択的に、ＡＰ ＭＬＤはＳＴＡに適したＬｉｎｋを推奨する「ｒｅｃｏｍｍｅｎｄ ｌｉｎｋ」ｅｌｅｍｅｎｔを上述した複数情報（例えば、Ｌｉｎｋ再選択のために必要な最新情報）を含む応答メッセージを介してともに送信することができる。

本明細書において、ｎｏｎ－ＡＰ ＭＬＤのＳＴＡがＯｔｈｅｒ ＡＰの情報を要求する場合に対して詳しく定義する。

Ｎｏｎ－ＡＰ ＭＬＤのＳＴＡがｐｅｅｒ ＡＰにＯｔｈｅｒ ＡＰの全体情報を要求するためにＭＬＤ Ｐｒｏｂｅ ｒｅｑｕｅｓｔ ｆｒａｍｅを送信する場合、ｐｅｅｒ ＡＰはＳＴＡが要求したＡＰに対する全体情報を含むＭＬＤ Ｐｒｏｂｅ Ｒｅｓｐｏｎｓｅ ｆｒａｍｅを応答することである。この場合、ｐｅｅｒ ＡＰはこれに対するＭＬＤ Ｐｒｏｂｅ Ｒｅｓｐｏｎｓｅ ｆｒａｍｅに要求したＡＰに対する全体情報を次のように応答することができる。

１－１）ＳＴＡがＯｔｈｅｒ ＡＰに対する全体情報を要求する時、ＭＬＤ Ｐｒｏｂｅ ＲｅｓｐｏｎｓｅにＰｅｅｒ ＡＰの全体情報をｍａｎｄａｔｏｒｙに含める方法

この方法はＳＴＡがＰｅｅｒ ＡＰを除いた同じＡＰ ＭＬＤのＯｔｈｅｒ ＡＰの全体情報を要求した場合でもＰｅｅｒ ＡＰの全体情報をともに入れる方法である。現在８０２．１１ｂｅではＭＬＤ Ｐｒｏｂｅ Ｒｅｓｐｏｎｓｅのオーバーヘッドを減らすためにｉｎｈｅｒｉｔａｎｃｅ ｍｏｄｅｌを使用する。したがって、ＳＴＡがＯｔｈｅｒ ＡＰの全体情報を要求する時、ＡＰはＰｅｅｒ ＡＰ全体情報を常に含む場合、ｉｎｈｅｒｉｔａｎｃｅ ｍｏｄｅｌを適用することができる。つまり、ＡＰ ＭＬＤが特定のＡＰに対する全体情報の要求に応答する時、Ｐｅｅｒ ＡＰの情報を含む場合、同じＭＬＤ内で共通する値はＭＬ ＩＥ内のＣｏｍｍｏｎ ｉｎｆｏに含めＡＰ別に異なる情報はＭＬ ＩＥ内Ｐｅｒ－ＳＴＡ Ｐｒｏｆｉｌｅ内のｎｏｎ－ｉｎｈｅｒｉｔａｎｃｅ ｅｌｅｍｅｎｔとして各ＡＰ別に異なる情報を含むことができる。ＳＴＡが複数のＯｔｈｅｒ ＡＰに対する全体情報を要求する場合は同じく存在する情報に対してはＣｏｍｍｏｎ ｉｎｆｏとして１回のみ構成させることで全体的なＭＬＤ Ｐｒｏｂｅ Ｒｅｓｐｏｎｓｅ ｆｒａｍｅのオーバーヘッドを減らすことができる。但し、この場合、ＳＴＡがＰｅｅｒ ＡＰに対する全体情報を要求しない場合は、Ｐｅｅｒ ＡＰに対する要求しない情報も含まれるため多少オーバーヘッドが存在するが、複数のＯｔｈｅｒ ＡＰに対する情報を要求する場合はｉｎｈｅｒｉｔａｎｃｅ ｍｏｄｅｌを使用して減らせるオーバーヘッドがさらに大きい場合があるため便利に使用することができる。

１－２）ＳＴＡがＯｔｈｅｒ ＡＰに対する全体情報を要求する時、ＭＬＤ Ｐｒｏｂｅ ＲｅｓｐｏｎｓｅにＰｅｅｒ ＡＰの全体情報をｍａｎｄａｔｏｒｙに含めない方法（すなわち、要求したＯｔｈｅｒ ＡＰの全体情報のみ含めて送信する方法）

この方法はＳＴＡがＰｅｅｒ ＡＰにＯｔｈｅｒ ＡＰに対する全体情報を要求する場合、要求したＡＰに対する全体情報のみをＭＬＤ Ｐｒｏｂｅ Ｒｅｓｐｏｎｓｅに含めて送信する方法である。当該の方法はＳＴＡがＰｅｅｒ ＡＰに対する情報をともに要求する場合はｉｎｈｅｒｉｔａｎｃｅ ｍｏｄｅｌを適用してオーバーヘッドを減らすことができるが、もしＳＴＡがＰｅｅｒ ＡＰに対する情報を除いた同じＡＰ ＭＬＤのＯｔｈｅｒ ＡＰに対する情報のみを要求する場合はｉｎｈｅｒｉｔａｎｃｅ ｍｏｄｅｌを適用することができない。したがって、Ｐｅｅｒ ＡＰに対する情報が含まれない場合はｉｎｈｅｒｉｔａｎｃｅ ｍｏｄｅｌを適用しないため多少オーバーヘッドが増加する可能性はあるが、ＳＴＡが複数のＡＰではない特定のＡＰに対してのみ全体情報を要求する場合は不要なＰｅｅｒ ＡＰの情報を含まないためかえってオーバーヘッドが少ない可能性がある。ＳＴＡが要求したＡＰの情報のみを含めて応答する方法が１つ目のＭａｎｄａｔｏｒｙ方法に比べて多少単純であるが、ＳＴＡが全体情報を要求する同じＡＰ ＭＬＤ内のＯｔｈｅｒ ＡＰの数が増加するほどｉｎｈｅｒｉｔａｎｃｅ ｍｏｄｅｌを使用する１つ目のｍａｎｄａｔｏｒｙ方法がより効率的である。

１－３）Ｐｅｅｒ ＡＰが場合によってオーバーヘッドが少ない側に構成して全体情報を送信する方法

当該の方法はＡＰが、ＳＴＡが要求したＡＰのＣｏｍｍｏｎ ｉｎｆｏ情報に係るＭＬＤ Ｐｒｏｂｅ Ｒｅｓｐｏｎｓｅ ｆｒａｍｅの構成によって１つ目の場合（ＳＴＡがＰｅｅｒ ＡＰに対する情報をともに要求しない場合、ＲｅｓｐｏｎｓｅにＰｅｅｒ ＡＰの情報をｍａｎｄａｔｏｒｙに含める方法）と２つ目の場合（ＳＴＡがＰｅｅｒ ＡＰに対する情報をともに要求しない場合、ＲｅｓｐｏｎｓｅにＰｅｅｒ ＡＰの情報をｍａｎｄａｔｏｒｙに含めない方法）に発生するｆｒａｍｅ ｏｖｅｒｈｅａｄを比較して、効率的なほうにＭＬＤ Ｐｒｏｂｅ Ｒｅｓｐｏｎｓｅを構成して送信する方法である。つまり、ＳＴＡが要求するＡＰの情報によってＩｎｈｅｒｉｔａｎｃｅ ｍｏｄｅｌを適用の効率性を比較してよりオーバーヘッドが少ないフォーマットを構成して応答する。但し、この方法において２つの場合を比較して効率的であると考える基準はＡＰの実装によって決定することができる。

上記説明した複数のオプションに対する方法はＳＴＡがＯｔｈｅｒ ＡＰの全体情報を要求する場合に対する方法でＳＴＡがＯｔｈｅｒ ＡＰに対する部分情報を要求した場合は特定のＩＥに対する情報を要求するため適用されない場合がある。但し、ＳＴＡが１つのＭＬＤ Ｐｒｏｂｅ ｒｅｑｕｅｓｔ ｆｒａｍｅで一部のＡＰに対して全体情報を要求して一部のＡＰに対して部分情報を要求する場合、Ｉｎｈｅｒｉｔａｎｃｅ ｍｏｄｅｌが適用することができるため上記で言及した３つの方法を使用することができる。

上述したｓｏｌｉｃｉｔｅｄ方法はｎｏｎ－ＡＰ ＭＬＤのＳＴＡにおいてＬｉｎｋの変更又は再接続のために使用することができる。例えば、ｎｏｎ－ＡＰ ＭＬＤのＳＴＡがＬｉｎｋ ｃｏｎｇｅｓｔｉｏｎのためＬｉｎｋ再選択を希望する場合、ｎｏｎ－ＡＰ ＭＬＤのＳＴＡはＳｏｌｉｃｉｔｅｄ ｍｅｔｈｏｄを介して接続されたＡＰ ＭＬＤの各リンク別のＢＳＳ ｌｏａｄ情報及びＢＳＳ ｐａｒａｍｅｔｅｒ情報を要求することができる。この要求メッセージを受信したＡＰはＳＴＡが指示したリンク及び情報を応答メッセージに含め送信することができる。

以下では、上述した要求メッセージ及び応答メッセージはＬｉｎｋの変更のための要求メッセージ及びＬｉｎｋの変更のための応答メッセージと区分するために情報の要求メッセージ及び情報応答メッセージとして説明される。

上述した情報応答メッセージに含まれた情報に基づいて、ＳＴＡは適したＬｉｎｋを再選択してＡＰ ＭＬＤにＬｉｎｋの変更又は再接続をＬｉｎｋの変更のための要求メッセージを介して要求することができる。前記Ｌｉｎｋの変更のための要求メッセージは自身が再接続するＡＰ情報とＬｉｎｋ情報を含むことができる。

前記要求メッセージを受信したＡＰ ＭＬＤは要求を承認する場合「承認（Ａｃｃｅｐｔ）」の応答メッセージを送信することができる。ＡＰ ＭＬＤは要求を拒否する場合「拒否（Ｄｅｃｌｉｎｅ）」の応答メッセージを送信することができる。

もし要求を承認する場合、ＡＰは応答メッセージ送信以降からは再選択されたＡＰのＬｉｎｋを介したｆｒａｍｅ ｅｘｃｈａｎｇｅに基づいて、Ｌｉｎｋ（ｒｅ）ｓｅｔｕｐを実行することができる。逆に要求を拒否する場合、ＳＴＡは既存のＬｉｎｋをそのまま使用することができる。

Ｓｏｌｉｃｉｔｅｄ方法に係る具体的なＡＰ ＭＬＤ及びｎｏｎ－ＡＰ ＭＬＤの動作の例が図１９において説明される。

図１９はＬｉｎｋの変更又は再接続のためのＡＰ ＭＬＤ及びｎｏｎ－ＡＰ ＭＬＤの動作を示している。

図１９を参照すれば、ｎｏｎ－ＡＰ ＭＬＤのＳＴＡ２が接続されたＬｉｎｋを再選択したいとき、ＳＴＡ２はＡＰ ＭＬＤにＬｉｎｋ２を介してＩｎｆｏ要求メッセージを送信することができる。これを受信したＡＰ ＭＬＤはｎｏｎ－ＡＰ ＭＬＤのＬｉｎｋ再選択のために必要な情報を含んだＩｎｆｏ応答メッセージを送信することができる。上述したＩｎｆｏ応答メッセージに含まれた情報に基づいて、ｎｏｎ－ＡＰ ＭＬＤのＳＴＡ２はＬｉｎｋの変更のための要求メッセージ（すなわち、ｌｉｎｋ ｓｗｉｔｃｈｉｎｇ ｒｅｑｕｅｓｔ ｆｒａｍｅ）をＡＰ ＭＬＤのＡＰ２に送信することができる。以降、ＳＴＡ２はＬｉｎｋの変更のための応答メッセージ（すなわち、ｌｉｎｋ ｓｗｉｔｃｈｉｎｇ ｒｅｑｕｅｓｔ ｆｒａｍｅ）を受信し、Ｌｉｎｋの変更のためのｌｉｎｋ（ｒｅ）ｓｅｔ－ｕｐを実行することができる。

本明細書において提案される情報の要求に関する実施形態は、ＳＴＡがＡＰに必要な情報を要求する場合でも使用／適用される。ＳＴＡがＡＰから受信するフレーム（例えば、ｂｅａｃｏｎ）に含まれた情報が足りない場合ＳＴＡは足りない情報に対してＡＰに要求することができる。例えば、ＡＰがｏｔｈｅｒ ｌｉｎｋの情報を含めず接続されたｌｉｎｋの情報のみを送信するかｏｔｈｅｒ ｌｉｎｋの情報更新有無に関する情報のみを送信する場合、ＳＴＡは足りない情報に対してＡＰに要求することができる。

前記実施形態の具体的な例が図２０において説明される。

図２０はＯｔｈｅｒ ＡＰに関する情報を要求するためのｎｏｎ－ＡＰ ＭＬＤの動作を示している。

図２０を参照すれば、ＡＰ ＭＬＤ（又はＡＰ１からＡＰ３）はｂｅａｃｏｎフレームを介してＳＴＡにＯｔｈｅｒ ＡＰ（すなわち、ｌｉｎｋ）の情報更新有無に関する情報のみを送信することができる。したがって、ＳＴＡ２はＩｎｆｏ要求メッセージ（又はＩｎｆｏ ｒｅｑｕｅｓｔ ｆｒａｍｅ）をＡＰ２に送信することができる。ＳＴＡ２は前記Ｉｎｆｏ要求メッセージに基づいて、Ｉｎｆｏ応答メッセージ（又はＩｎｆｏ ｍｅｓｓａｇｅ）を受信することができる。ＳＴＡ２は前記Ｉｎｆｏ応答メッセージに基づいて、Ｏｔｈｅｒ ＡＰに関する情報を受信／獲得することができる。

例えば、ＢｅａｃｏｎにＡＰ ＭＬＤのＯｔｈｅｒ ＡＰ情報（例えば、ＢＳＳ ｌｏａｄ情報など）が含まれていないか、ＡＰ２がＯｔｈｅｒ ＡＰ情報に対する更新有無（例えば、ｖｅｒｓｉｏｎ／ｕｐｄａｔｅ ｖｅｒｓｉｏｎ）に関する情報のみを送信することができる。

ＳＴＡ２はＡＰ１の情報（又はＡＰ１に関する情報）が必要な場合がある。ＳＴＡ２はＡＰ２を介して必要な情報を要求することができる。ＳＴＡ２は前記要求に対する応答メッセージを介してＡＰ１の情報を獲得することができる。ＳＴＡ２は前記ＡＰ１の情報をＬｉｎｋ ｓｗｉｔｃｈｉｎｇする適切なリンクを再選択することに使用することができる。例えば、Ｌｉｎｋ ｓｗｉｔｃｈｉｎｇのためのｆｒａｍｅは多様に設定することができる。

さらに、上述したｓｏｌｉｃｉｔｅｄ方法はｍｕｌｔｉ－ｌｉｎｋ ｓｅｔｕｐ以前にもＳＴＡがＡＰ ＭＬＤが持ったＡＰの情報を獲得するために使用される。Ｎｏｎ－ＡＰ ＭＬＤ及びＡＰ ＭＬＤのｍｕｌｔｉ－ｌｉｎｋ ｓｅｔｕｐプロセスにおいて、ＡＰ ＭＬＤが持ったＡＰの数がｎｏｎ－ＡＰ ＭＬＤが持ったＳＴＡの数より多い場合、ｎｏｎ－ＡＰ ＭＬＤのＳＴＡはＡＰ ＭＬＤのあるＡＰとｌｉｎｋをｓｅｔｕｐするか決定する必要がある。この場合、ｎｏｎ－ＡＰ ＭＬＤのＳＴＡはｍｕｌｔｉ－ｌｉｎｋ ｓｅｔｕｐ以前にＡＰ ＭＬＤのＡＰに各リンク別の状態を把握するためにリンク別の特定の情報（例えば、ＡＰ ＭＬＤが持ったＡＰのＢＳＳ ｌｏａｄ情報など）を要求することができる。一例として、ＳＴＡは要求メッセージとしてＰｒｏｂｅ ｒｅｑｕｅｓｔを使用することができる。他の一例として、要求メッセージのための新規フレームが定義される。ＳＴＡは要求メッセージに特定のｅｌｅｍｅｎｔを要求するためのインジケーター（例えば、Ｒｅｑｕｅｓｔ ｅｌｅｍｅｎｔ又はＥｘｔｅｎｄｅｄ Ｒｅｑｕｅｓｔ ｅｌｅｍｅｎｔ又はＰＶ １ Ｐｒｏｂｅ Ｒｅｓｐｏｎｓｅ Ｏｐｔｉｏｎ ｅｌｅｍｅｎｔなど）及び特定のｌｉｎｋ情報を指示するためのインジケーター（例えば、Ｌｉｎｋ ＩＤなど）を含めて送信することができる。

例えば、ｎｏｎ－ＡＰ ＭＬＤのＳＴＡは接続するＡＰ ＭＬＤ内の全てのＡＰ別現在のＢＳＳ ｌｏａｄ情報を要求する指示事項を含んだ要求メッセージを送信することができる。前記要求メッセージを受信したＡＰはＳＴＡの指示事項に基づいて必要な情報を（ＡＰが接続されたＡＰ ＭＬＤの全てのＡＰのＢＳＳ ｌｏａｄ情報）応答メッセージに入れてＳＴＡに送信することができる。このとき、各ＡＰ別ＢＳＳ ｌｏａｄ情報を確認したＳＴＡは最もＢＳＳ ｌｏａｄが少ないＢＳＳ（すなわち、ＡＰ）順序で接続するリンクを選択することができる。ＳＴＡはｍｕｌｔｉ－ｌｉｎｋ ｓｅｔｕｐ時、選択されたリンクを指示することができる。つまり、ｍｕｌｔｉ－ｌｉｎｋ ｓｅｔｕｐ時、選択されたリンクに関する情報をＡＰに送信することができる。

このようにＳＴＡはｍｕｌｔｉ－ｌｉｎｋ ｓｅｔｕｐ以前、接続するｌｉｎｋを選択するためにＡＰ ＭＬＤの各ＡＰ別情報を獲得するための方法で上述したｓｏｌｉｃｉｔｅｄ方法を使用することもできる。

以下では、ｎｏｎ－ＡＰ ＭＬＤのＳＴＡが適したＬｉｎｋを選択するための情報を含む新しいｅｌｅｍｅｎｔ／ｆｉｅｌｄが提案される。

例えば、「ｒａｔｉｏ ｐｅｒ Ｌｉｎｋ」（ｅｌｅｍｅｎｔ／ｆｉｅｌｄ）が提案される。「ＳＴＡ ｒａｔｉｏ ｐｅｒ Ｌｉｎｋ」はＬｉｎｋ別に接続されたＳＴＡ数の比率に関する情報を含むことができる。「ＳＴＡ ｒａｔｉｏ ｐｅｒ Ｌｉｎｋ」の具体的な例が図２１において説明される。

図２１はＳＴＡ ｒａｔｉｏ ｐｅｒ Ｌｉｎｋの具体的な例を示している。

図２１を参照すれば、ＳＴＡ ｒａｔｉｏ ｐｅｒ Ｌｉｎｋ（ｅｌｅｍｅｎｔ／ｆｉｅｌｄ）は全体ＡＰ ＭＬＤにおいて各Ｌｉｎｋ別に接続されているＳＴＡ数又は比率に関する情報を含むことができる。

例えば、３つのＬｉｎｋを持ったＡＰ ＭＬＤに合計５０個のＳＴＡが接続されている場合、Ｌｉｎｋ１に１０個、Ｌｉｎｋ２に２０個のＳＴＡが接続される。ＡＰ ＭＬＤはＳＴＡ ｒａｔｉｏ ｐｅｒ Ｌｉｎｋ（ｅｌｅｍｅｎｔ／ｆｉｅｌｄ）を介してそれぞれのＬｉｎｋ別に接続されたＳＴＡに対する情報を値又は比率（％）に関する情報をｎｏｎ－ＡＰ ＭＬＤに送信することができる。

一例として、それぞれのＬｉｎｋ別に接続されたＳＴＡに対する情報が値として表現される場合、Ｌｉｎｋ１は１０、Ｌｉｎｋ２は２０で表現／設定することができる。したがって、ＳＴＡ ｒａｔｉｏ ｐｅｒ Ｌｉｎｋ１の値が１０に設定することができる。又、ＳＴＡ ｒａｔｉｏ ｐｅｒ Ｌｉｎｋ２の値が２０に設定することができる。

他の一例は、それぞれのＬｉｎｋ別に接続されたＳＴＡに対する情報が比率で表現される場合、Ｌｉｎｋ１は２０（１０／５０）％、Ｌｉｎｋ２は４０（２０／５０）％で表現／設定することができる。したがって、ＳＴＡ ｒａｔｉｏ ｐｅｒ Ｌｉｎｋ１の値が２０に設定することができる。又、ＳＴＡ ｒａｔｉｏ ｐｅｒ Ｌｉｎｋ２の値が４０に設定することができる。

上記の例は例示的なものであり、それぞれのＬｉｎｋ別に接続されたＳＴＡに対する情報は多様に設定することができる。上記の例に加えて相対値としてそれぞれのＬｉｎｋ別に接続されたＳＴＡに対する情報を設定することができる。

上述したそれぞれのＬｉｎｋ別に接続されたＳＴＡに対する情報に基づいて、ＳＴＡは各Ｌｉｎｋ別に接続されたＳＴＡ数及び比率を確認／獲得することができ、これをＬｉｎｋ選択のための情報として使用することができる。

一実施形態によれば、上述した「ｒａｔｉｏ ｐｅｒ Ｌｉｎｋ」（ｅｌｅｍｅｎｔ／ｆｉｅｌｄ）以外にも様々な情報／ｅｌｅｍｅｎｔ／ｆｉｅｌｄが情報応答メッセージに含まれる。例えば、下記のような情報／ｅｌｅｍｅｎｔ／ｆｉｅｌｄが情報応答メッセージに含まれる。

－各ＡＰ別ＢＳＳ ｌｏａｄ情報

－Ｌｉｎｋ間ＳＴＲ Ｃａｐａｂｉｌｉｔｙ情報

－各Ｌｉｎｋ別ＴＸ ＯＰ情報

－各Ｌｉｎｋ別ＮＡＶ情報

－推奨Ｌｉｎｋ情報（すなわち、「ｒｅｃｏｍｍｅｎｄ Ｌｉｎｋ」ｅｌｅｍｅｎｔ）

－Ｌｉｎｋ別の接続ＳＴＡ比率情報（すなわち、「ＳＴＡ ｒａｔｉｏ ｐｅｒ Ｌｉｎｋ」ｅｌｅｍｅｎｔ）

－その他

上述した情報／ｅｌｅｍｅｎｔ／ｆｉｅｌｄ以外にもｌｉｎｋ選択のために必要な様々な情報が情報応答メッセージに含まれて送信される。

上記の例のような情報を受信したＳＴＡは受信した情報に基づいて、自身が変更又は再接続するＡＰを選択した後、Ｌｉｎｋを再接続を要求するための要求メッセージを送信することができる。前記要求メッセージを受信したＡＰ ＭＬＤは要求を承認する場合「承認（Ａｃｃｅｐｔ）」の応答メッセージを送信することができる。ＡＰ ＭＬＤは要求を拒否する場合「拒否（Ｄｅｃｌｉｎｅ）」の応答メッセージを送信することができる。

もし要求を承認する場合、ＡＰは応答メッセージ送信以降から再選択されたＡＰとのＬｉｎｋを介してｆｒａｍｅ ｅｘｃｈａｎｇｅを実行することができる。逆に拒否する場合、ＳＴＡは既存のＬｉｎｋをそのまま使用することができる。

２）Ｕｎｓｏｌｉｃｉｔｅｄ方法

ｎｏｎ－ＡＰ ＭＬＤが直接追加情報を要求するＳｏｌｉｃｉｔｅｄ方法と違って、Ｕｎｓｏｌｉｃｉｔｅｄ方法によれば、ｎｏｎ－ＡＰ ＭＬＤの追加情報の要求なしにＢｅａｃｏｎ ｆｒａｍｅ又は別途のフレーム（例えば、ＱｏＳ ｄａｔａ ｆｒａｍｅのｆｉｅｌｄ（１１ａｘ規格のＡ－Ｃｏｎｔｒｏｌ ｆｉｅｌｄ）、ｍａｎａｇｅｍｅｎｔ ｆｒａｍｅ、ＦＩＬＳ ｄｉｓｃｏｖｅｒｙ ｆｒａｍｅ、ｕｎｓｏｌｉｃｉｔｅｄ Ｐｒｏｂｅ Ｒｅｓｐｏｎｓｅ ｆｒａｍｅ、ＰＳ－Ｐｏｌｌフレーム又はＮｕｌｌ ｆｒａｍｅなど）を介してＡＰ ＭＬＤはｎｏｎ－ＡＰ ＭＬＤに追加情報を送信することができる。他の例として、ｎｏｎ－ＡＰ ＭＬＤに追加情報を送信するためのフレームで新規フレームが定義される。

例えば、Ｂｅａｃｏｎ周期が多少長い場合、ｎｏｎ－ＡＰ ＭＬＤがＬｉｎｋ ｓｗｉｔｃｈｉｎｇのために必要な必須的な情報が足りないか最新情報ではない可能性がある。したがって、ＡＰはＡＰ ＭＬＤのＬｉｎｋ ｃａｐａｂｉｌｉｔｙ情報が含まれたフレームをｎｏｎ－ＡＰ ＭＬＤに送信することができる。以降、ｎｏｎ－ＡＰ ＳＴＡはＡＰ ＭＬＤの各Ｌｉｎｋ別のＣａｐａｂｉｌｉｔｙに対する最新情報を獲得することができる。前記フレームは周期的に送信されるか非周期的に送信される。

一例として、前記フレームが周期的に送信される場合、ＡＰは一定の時間間隔毎にＡＰの最新情報を共有するためにフレームを送信することができる。このとき、その時間間隔はＡＰが送信するＢｅａｃｏｎ周期よりは短い必要がある。又、前記フレームでＦＩＬＳ ｄｉｓｃｏｖｅｒｙ ｆｒａｍｅが使用される場合、前記フレームは２０ｕｓ毎に送信される。他の一例として、ＡＰとＳＴＡがｃａｐａｂｉｌｉｔｙ ｎｅｇｏｔｉａｔｉｏｎを介して合意した周期が使用される。例えば、ＩＯＭ ｃａｐａｂｉｌｉｔｙ ｅｌｅｍｅｎｔの「ｐｅｒｉｏｄｉｃ」ｆｉｅｌｄ及び「ｉｎｔｅｒｖａｌ」ｆｉｅｌｄ／ｓｕｂｆｉｅｌｄの値を介して送信周期を指示することができる。

他の一例として、前記フレームが非周期的に送信される場合、ＡＰの情報（ｃａｐａｂｉｌｉｔｙ、ＢＳＳ ｐａｒａｍｅｔｅｒ、ｏｐｅｒａｔｉｏｎ ｅｌｅｍｅｎｔ）が更新イベントが発生したとき毎にＡＰは前記フレームを送信することができる。具体的な一例として、ＡＰ ＭＬＤのＡＰのＬｉｎｋ ｃａｐａｂｉｌｉｔｙが変更するとき毎に接続されたＳＴＡに変更された情報が送信される。この場合、ＳＴＡはＬｉｎｋ ｃａｐａｂｉｌｉｔｙに対する最新情報を維持することができる。

上記の例によれば、ｎｏｎ－ＡＰ ＳＴＡが別途のＬｉｎｋ ｃａｐａｂｉｌｉｔｙ獲得のための要求メッセージを送信しないためｓｏｌｉｃｉｔｅｄ方法に比べて比較的ｆｒａｍｅ ｅｘｃｈａｎｇｅ ｏｖｅｒｈｅａｄが少なく発生する効果がある。又、主要情報が更新するとき毎に更新された情報をＳＴＡが受信することができるため、ＳＴＡが受信した情報を便利に使用できる効果がある。

Ｕｎｓｏｌｉｃｉｔｅｄ方法に係る具体的なＡＰ ＭＬＤ及びｎｏｎ－ＡＰ ＭＬＤの動作の例が図２２において説明される。

図２２はＬｉｎｋの変更又は再接続のためのＡＰ ＭＬＤ及びｎｏｎ－ＡＰ ＭＬＤの動作を示している。

図２２を参照すれば、ＡＰ ＭＬＤはｎｏｎ－ＡＰ ＭＬＤの別途の要求メッセージなしにＬｉｎｋ再選択（ｒｅｓｅｌｅｃｔｉｏｎ）に必要な必須情報を別途のｆｒａｍｅ（例えば、ＰＳ－Ｐｏｌｌフレーム又はＮｕｌｌ ｆｒａｍｅなど）でｎｏｎ－ＡＰに送信することができる。

一実施形態によれば、図２２と異なり、ＡＰ ＭＬＤはｎｏｎ－ＡＰ ＭＬＤの別途の要求メッセージなしに、Ｌｉｎｋ ｃａｐａｂｉｌｉｔｙに対する情報を自身がｎｏｎ－ＡＰ ＭＬＤに送信するＤＬフレーム（ｅ．ｇ．ＱｏＳ ｄａｔａ ｆｒａｍｅ）のｆｉｅｌｄを介してＳＴＡに送信することもできる。前記実施形態に係るＡＰ ＭＬＤ及びｎｏｎ－ＡＰ ＭＬＤの動作が図２３において説明される。

図２３はＬｉｎｋの変更又は再接続のためのＡＰ ＭＬＤ及びｎｏｎ－ＡＰ ＭＬＤの動作を示している。

図２３を参照すれば、ＡＰ２はＤＬフレーム（すなわち、ＤＬ１）に基づいて、Ｏｔｈｅｒ ＡＰの情報（又はＯｔｈｅｒ ＡＰに関する情報）をＳＴＡ２に送信することができる。つまり、ＤＬフレームはＯｔｈｅｒ ＡＰに関する情報を含むことができる。例えば、Ｏｔｈｅｒ ＡＰに関する情報は８０２．１１ａｘ規格のＡ－Ｃｏｎｔｒｏｌ ｆｉｅｌｄなどに含まれる。前記実施形態によれば、別途のメッセージなしに既存のＤＬフレームを活用するためフレームオーバーヘッドを減らせる効果がある。もしＯｔｈｅｒ ＡＰのＣｒｉｔｉｃａｌ情報が変更され、情報のリアルタイム性が必要な場合、図２３の実施形態のように別途のメッセージを介して更新情報が送信される。

例えば、ＡＰのＣｒｉｔｉｃａｌ情報は下記のＡからＱを含むことができる。

Ａ． Ｉｎｃｌｕｓｉｏｎ ｏｆ ａ Ｃｈａｎｎｅｌ Ｓｗｉｔｃｈ Ａｎｎｏｕｎｃｅｍｅｎｔ ｅｌｅｍｅｎｔ

Ｂ． Ｉｎｃｌｕｓｉｏｎ ｏｆ ａｎ Ｅｘｔｅｎｄｅｄ Ｃｈａｎｎｅｌ Ｓｗｉｔｃｈ Ａｎｎｏｕｎｃｅｍｅｎｔ ｅｌｅｍｅｎｔ

Ｃ． Ｍｏｄｉｆｉｃａｔｉｏｎ ｏｆ ｔｈｅ ＥＤＣＡ ｐａｒａｍｅｔｅｒｓ ｅｌｅｍｅｎｔ

Ｄ． Ｉｎｃｌｕｓｉｏｎ ｏｆ ａ Ｑｕｉｅｔ ｅｌｅｍｅｎｔ

Ｅ． Ｍｏｄｉｆｉｃａｔｉｏｎ ｏｆ ｔｈｅ ＤＳＳＳ Ｐａｒａｍｅｔｅｒ Ｓｅｔ

Ｆ． Ｍｏｄｉｆｉｃａｔｉｏｎ ｏｆ ｔｈｅ ＣＦ Ｐａｒａｍｅｔｅｒ Ｓｅｔ ｅｌｅｍｅｎｔ

Ｇ． Ｍｏｄｉｆｉｃａｔｉｏｎ ｏｆ ｔｈｅ ＨＴ Ｏｐｅｒａｔｉｏｎ ｅｌｅｍｅｎｔ

Ｈ． Ｉｎｃｌｕｓｉｏｎ ｏｆ ａ ＷｉｄｅＢａｎｄ ｗｉｄｔｈ Ｃｈａｎｎｅｌ Ｓｗｉｔｃｈ ｅｌｅｍｅｎｔ

Ｉ． Ｉｎｃｌｕｓｉｏｎ ｏｆ ａ Ｃｈａｎｎｅｌ Ｓｗｉｔｃｈ Ｗｒａｐｐｅｒ ｅｌｅｍｅｎｔ

Ｊ． Ｉｎｃｌｕｓｉｏｎ ｏｆ ａｎ Ｏｐｅｒａｔｉｎｇ Ｍｏｄｅ Ｎｏｔｉｆｉｃａｔｉｏｎ ｅｌｅｍｅｎｔ

Ｋ． Ｉｎｃｌｕｓｉｏｎ ｏｆ ａ Ｑｕｉｅｔ Ｃｈａｎｎｅｌ ｅｌｅｍｅｎｔ

Ｌ． Ｍｏｄｉｆｉｃａｔｉｏｎ ｏｆ ｔｈｅ ＶＨＴ Ｏｐｅｒａｔｉｏｎ ｅｌｅｍｅｎｔ

Ｍ． Ｍｏｄｉｆｉｃａｔｉｏｎ ｏｆ ｔｈｅ ＨＥ Ｏｐｅｒａｔｉｏｎ ｅｌｅｍｅｎｔ

Ｎ． Ｉｎｓｅｒｔｉｏｎ ｏｆ ａ Ｂｒｏａｄｃａｓｔ ＴＷＴ ｅｌｅｍｅｎｔ

Ｏ． Ｉｎｃｌｕｓｉｏｎ ｏｆ ｔｈｅ ＢＳＳ Ｃｏｌｏｒ Ｃｈａｎｇｅ Ａｎｎｏｕｎｃｅｍｅｎｔ ｅｌｅｍｅｎｔ

Ｐ． Ｍｏｄｉｆｉｃａｔｉｏｎ ｏｆ ｔｈｅ ＭＵ ＥＤＣＡ Ｐａｒａｍｅｔｅｒ Ｓｅｔ ｅｌｅｍｅｎｔ

Ｑ． Ｍｏｄｉｆｉｃａｔｉｏｎ ｏｆ ｔｈｅ Ｓｐａｔｉａｌ Ｒｅｕｓｅ Ｐａｒａｍｅｔｅｒ Ｓｅｔ ｅｌｅｍｅｎｔ

したがって、ｎｏｎ－ＡＰ ＭＬＤはＢｅａｃｏｎ ｆｒａｍｅ周期と関係なしに最新Ｌｉｎｋ ｃａｐａｂｉｌｉｔｙ情報を獲得することができる。ｎｏｎ－ＡＰ ＭＬＤは受信された情報に基づいて、Ｌｉｎｋ ｓｗｉｔｃｈｉｎｇ時、適したＬｉｎｋを選択することができる。前記受信された情報に基づいて、ＳＴＡは適したＬｉｎｋを再選択してＡＰ ＭＬＤにＬｉｎｋの変更又は再接続を要求することができる。前記要求メッセージは自身が再接続するＡＰ情報及びＬｉｎｋ情報を含むことができる。また、このメッセージを受信したＡＰ ＭＬＤは要求を承認する場合「承認（Ａｃｃｅｐｔ）」の応答メッセージを送信することができ、拒否する場合「拒否（Ｄｅｃｌｉｎｅ）」の応答メッセージを送信することができる。

もし要求を承認する場合、ＡＰは応答メッセージ送信以降からは再選択されたＡＰのＬｉｎｋでｆｒａｍｅ ｅｘｃｈａｎｇｅを介してＬｉｎｋ（ｒｅ）ｓｅｔｕｐを実行することができる。逆に拒否する場合、ＳＴＡは既存のＬｉｎｋをそのまま使用することができる。

３）Ｇｅｎｅｒａｌ方法

Ｇｅｎｅｒａｌ方法によれば、ｎｏｎ－ＡＰ ＭＬＤは自身が現在持った情報に基づいて、追加情報の要求なしにＬｉｎｋの変更又は再接続を要求することができる。このとき使用される情報は以前に受信したＢｅａｃｏｎ又はＭａｎａｇｅｍｅｎｔ ｆｒａｍｅなどに含まれたＡＰ ＭＬＤの情報及びｎｏｎ－ＡＰ ＭＬＤの情報（例えば、Ｌｉｎｋ別ＳＴＲ Ｃａｐａｂｉｌｉｔｙ情報、Ｌｉｎｋ ｓｔａｔｅ（ｅｎａｂｌｅ／ｄｉｓａｂｌｅ）情報など）を含むことができる。

Ｓｏｌｉｃｉｔｅｄ方法と異なって、ＳＴＡはＡＰ ＭＬＤに別途の情報の要求なしに直接Ｌｉｎｋの変更又は再接続のための要求メッセージをＡＰ ＭＬＤに送信することができる。前記要求メッセージは自身が再接続するＡＰ情報とＬｉｎｋ情報を含むことができる。前記要求メッセージを受信したＡＰ ＭＬＤは要求を承認する場合「承認（Ａｃｃｅｐｔ）」の応答メッセージを送り、拒否する場合「拒否（Ｄｅｃｌｉｎｅ）」の応答メッセージを送信することができる。

もし要求を承認する場合、ＡＰは応答メッセージ送信以降からは再選択されたＡＰとのＬｉｎｋを介してｆｒａｍｅ ｅｘｃｈａｎｇｅを実行することができる。逆に拒否する場合、ＳＴＡは既存のＬｉｎｋをそのまま使用することができる。

Ｇｅｎｅｒａｌ方法に係る具体的なＡＰ ＭＬＤ及びｎｏｎ－ＡＰ ＭＬＤの動作の例が図２４において説明される。

図２４はＬｉｎｋの変更又は再接続のためのＡＰ ＭＬＤ及びｎｏｎ－ＡＰ ＭＬＤの動作を示している。

図２４を参照すれば、ＳＴＡ２はＱｏＳ保証を理由に直接Ｌｉｎｋを変更することを希望する場合がある。ＳＴＡ２が既存ＡＰ ＭＬＤから受けた情報（例えば、Ｂｅａｃｏｎ ｆｒａｍｅ又はＭａｎａｇｅｍｅｎｔ ｆｒａｍｅなどを介して受信した情報）があるか再接続したいＬｉｎｋを既に決定した場合、ＳＴＡ２は別途の情報の要求なしにＬｉｎｋの変更又は再接続を要求することができる。

ＳＴＡ２はＬｉｎｋ ｓｗｉｔｃｈｉｎｇ ｒｅｑｕｅｓｔ ｆｒａｍｅにＳＴＡ情報（ｅ．ｇ．ＳＴＡ ＩＤなど）及び変更しようとするＬｉｎｋ情報（ｅ．ｇ．Ｌｉｎｋ ＩＤ又はＡＰＢＳＳ情報など）を含めて送信することができる。これを受信したＡＰ ＭＬＤは変更を承認する場合、既存Ｌｉｎｋ２を介して「承認」のＬｉｎｋ ｓｗｉｔｃｈｉｎｇ Ｒｅｓｐｏｎｓｅ ｆｒａｍｅをＳＴＡ３に送信することができる。以降、ｎｏｎ－ＡＰ ＭＬＤのＳＴＡ２はＬｉｎｋ（ｒｅ）ｓｅｔｕｐプロセスを実行した後、ＡＰ３に再接続される。

Ｌｉｎｋの変更及び再接続方法をＩｎｄｉｃａｔｉｏｎするためのシグナリング

上記提案された方法を指示するために、ＡＰ ＭＬＤ及びｎｏｎ－ＡＰ ＭＬＤ間のｎｅｇｏｔｉａｔｉｏｎを介して相互間合意プロセスが必要な場合がある。このために、以下明細書で提案される方法をｅｎａｂｌｅするためのシグナリング方法が提案される。

先ず、上記提案された方法を指示するために、新規ｅｌｅｍｅｎｔが提案される。以下ではＬｉｎｋの変更及び再接続方法に対してＩｎｄｉｃａｔｉｏｎするためのシグナリングに関する実施形態が説明されるが、前記実施形態はＡｎｃｈｏｒｅｄ Ｌｉｎｋの変更及び再接続方法に対してｉｎｄｉｃａｔｉｏｎするためのシグナリングに関する実施形態にも適用される。

Ｌｉｎｋの変更及び再接続方法をＩｎｄｉｃａｔｉｏｎするためのシグナリングプロセスはｍｕｌｔｉ－ｌｉｎｋ ｓｅｔｕｐ又はｍｕｌｔｉ－ｌｉｎｋ ｓｅｔｕｐ以降実行される。又、Ｌｉｎｋの変更及び再接続方法をＩｎｄｉｃａｔｉｏｎするためのシグナリングプロセスに以下で提案される新規ｅｌｅｍｅｎｔｓを使用することができる。例えば、前記ｅｌｅｍｅｎｔｓは従来の規格の（ｒｅ）ａｓｓｏｃｉａｔｉｏｎ ｆｒａｍｅ又は新規ｆｒａｍｅに含まれる場合もある。

ＩＯＭ（Ｉｎｆｏｒｍａｔｉｏｎ Ｏｂｔａｉｎ Ｍｅｔｈｏｄ）Ｃａｐａｂｉｌｉｔｙ Ｅｌｅｍｅｎｔ

ＩＯＭ ｃａｐａｂｉｌｉｔｙ ｅｌｅｍｅｎｔは多重リンクのための追加情報の獲得方法の活性化（ｅｎａｂｌｅ）可否に関する情報を含むことができる。例えば、ＡＰ ＭＬＤとｎｏｎ－ＡＰ ＭＬＤがｍｕｌｔｉ－ｌｉｎｋ ｓｅｔｕｐプロセスにおいて動作の合意のためのメッセージを交換するプロセス（例えば、ｃａｐａｂｉｌｉｔｙ ｎｅｇｏｔｉａｔｉｏｎプロセス）においてメッセージにｅｌｅｍｅｎｔにＩＯＭ ｃａｐａｂｉｌｉｔｙ値が存在する場合がある。前記メッセージにｅｌｅｍｅｎｔにＩＯＭ ｃａｐａｂｉｌｉｔｙ値が存在するということはＩＯＭ ｃａｐａｂｉｌｉｔｙがサポートされることを意味する。

一実施形態によれば、ＡＰ ＭＬＤがＩＯＭ ｃａｐａｂｉｌｉｔｙをサポートする場合、ＡＰはＯｔｈｅｒ ＡＰの情報が内部的に共有され、Ｏｔｈｅｒ ＡＰの情報を有する場合がある。Ｏｔｈｅｒ ＡＰの情報が共有されないＭＬＤはＩＯＭ ｃａｐａｂｉｌｉｔｙをサポートすることができない。

一実施形態によれば、ＩＯＭ ｃａｐａｂｉｌｉｔｙ ｅｌｅｍｅｎｔの値が第１値（例えば、１）に設定される場合、ＩＯＭ ｃａｐａｂｉｌｉｔｙ ｅｌｅｍｅｎｔはＩＯＭを活性化させ指示された機能で動作することを意味する。逆に、ＩＯＭ ｃａｐａｂｉｌｉｔｙ ｅｌｅｍｅｎｔの値が第２値（例えば、０）に設定される場合、ＩＯＭ ｃａｐａｂｉｌｉｔｙ ｅｌｅｍｅｎｔはＩＯＭを非活性化させることを意味する。

一実施形態によれば、ＩＯＭ ｃａｐａｂｉｌｉｔｙ ｅｌｅｍｅｎｔは様々な動作を指示するために様々なｆｉｅｌｄ／ｅｌｅｍｅｎｔを含むことができる。例えば、ＩＯＭ ｃａｐａｂｉｌｉｔｙ ｅｌｅｍｅｎｔは以下で説明する様々なｆｉｅｌｄ／ｅｌｅｍｅｎｔを含むこともできる。但し、ＡＰ ＭＬＤがリンク変更を要求する場合及びｎｏｎ－ＡＰ ＭＬＤがリンク変更を要求する場合によってＩＯＭ ｃａｐａｂｉｌｉｔｙ ｅｌｅｍｅｎｔに追加されるｆｉｅｌｄ／ｅｌｅｍｅｎｔが異なって設定することができる。又、ＩＯＭ ｃａｐａｂｉｌｉｔｙ ｅｌｅｍｅｎｔに追加されるｆｉｅｌｄ／ｅｌｅｍｅｎｔのうち、少なくとも一部は省略することもできる。一例として、ＩＯＭ ｃａｐａｂｉｌｉｔｙ ｅｌｅｍｅｎｔに追加されるｆｉｅｌｄ／ｅｌｅｍｅｎｔのうち、指示する必要がない情報を含むｆｉｅｌｄ／ｅｌｅｍｅｎｔは省略することができる。

以下では多重リンクに関する追加情報を獲得するために定義／設定される様々なｆｉｅｌｄ／ｅｌｅｍｅｎｔの例が説明される。以下で説明する様々なｆｉｅｌｄ／ｅｌｅｍｅｎｔは独立的に構成されるか、２つ以上のｆｉｅｌｄ／ｅｌｅｍｅｎｔが結合して様々なフレームを介して送信される。例えば、以下で説明する様々なｆｉｅｌｄ／ｅｌｅｍｅｎｔは別のｅｌｅｍｅｎｔに含まれて定義する動作を実行することができる。他の例として、以下で説明する様々なｆｉｅｌｄ／ｅｌｅｍｅｎｔはそれぞれのｅｌｅｍｅｎｔ又は独立的なｆｉｅｌｄで別のｅｌｅｍｅｎｔに追加され使用される。

Ｍｅｔｈｏｄ種類（又はＭｅｔｈｏｄ）ｆｉｅｌｄ／ｅｌｅｍｅｎｔ

Ｍｅｔｈｏｄ種類ｆｉｅｌｄ／ｅｌｅｍｅｎｔ（以下、Ｍｅｔｈｏｄ ｆｉｅｌｄ／ｅｌｅｍｅｎｔ）はＩＯＭの動作方法に関する情報を含むことができる。つまり、Ｍｅｔｈｏｄ ｆｉｅｌｄ／ｅｌｅｍｅｎｔはＩＯＭの動作方法を指示することができる。例えば、Ｎｏｎ－ＡＰ ＭＬＤがＡＰから情報獲得のためにＩＯＭ方法を活性化させるとき、Ｎｏｎ－ＡＰ ＭＬＤは上記提案した方法（例えば、Ｓｏｌｉｃｉｔｅｄ方法、Ｕｎｓｏｌｉｃｉｔｅｄ方法、Ｇｅｎｅｒａｌ方法）のうち、使用する方法を選択して指示することができる。

一例として、Ｍｅｔｈｏｄ ｆｉｅｌｄ／ｅｌｅｍｅｎｔの値が第１値（例えば、０）であることに基づいて、Ｓｏｌｉｃｉｔｅｄ方法が指示／使用することができる。Ｍｅｔｈｏｄ ｆｉｅｌｄ／ｅｌｅｍｅｎｔの値が第２値（例えば、１）であることに基づいて、Ｕｎｓｏｌｉｃｉｔｅｄ方法が指示／使用することができる。Ｍｅｔｈｏｄ ｆｉｅｌｄ／ｅｌｅｍｅｎｔの値が第３値（例えば、２）であることに基づいて、Ｇｅｎｅｒａｌ方法が指示／使用することができる。Ｍｅｔｈｏｄ ｆｉｅｌｄ／ｅｌｅｍｅｎｔの値が第４値（例えば、３）であることに基づいて、Ｓｏｌｉｃｉｔｅｄ方法とＵｎｓｏｌｉｃｉｔｅｄ方法全て指示／使用することができる。

他の一例として、Ｍｅｔｈｏｄ ｆｉｅｌｄ／ｅｌｅｍｅｎｔとして１ｂｉｔを使用することができる。この場合、Ｍｅｔｈｏｄ ｆｉｅｌｄ／ｅｌｅｍｅｎｔの値が第１値（例えば、０）（例えば、０）であることに基づいて、Ｓｏｌｉｃｉｔｅｄ方法が指示／使用することができる。Ｍｅｔｈｏｄ ｆｉｅｌｄ／ｅｌｅｍｅｎｔの値が第２値（例えば、１）であることに基づいて、Ｕｎｓｏｌｉｃｉｔｅｄ方法が指示／使用することができる。

他の一例として、Ｍｅｔｈｏｄ ｆｉｅｌｄ／ｅｌｅｍｅｎｔとして２ｂｉｔを使用することができる。この場合、各方法別の単独使用又は重複使用などが指示される。

リンク範囲（Ｌｉｎｋ ｒａｎｇｅ）ｆｉｅｌｄ／ｅｌｅｍｅｎｔ

ｎｏｎ－ＡＰ ＭＬＤはＡＰ ＭＬＤに情報を要求する場合、リンク範囲（Ｌｉｎｋ ｒａｎｇｅ）ｆｉｅｌｄ／ｅｌｅｍｅｎｔを介して要求するリンクの範囲を指示することができる。リンク範囲（Ｌｉｎｋ ｒａｎｇｅ）ｆｉｅｌｄ／ｅｌｅｍｅｎｔはＳＴＡがＡＰ ＭＬＤ内の全てのリンクの情報を要求することを希望するか又はＡＰ ＭＬＤ内の一部のリンクの情報を要求することを希望するか否かに関する情報を含むことができる。

例えば、リンク範囲ｆｉｅｌｄ／ｅｌｅｍｅｎｔの値が第１値（例えば、０）である場合、リンク範囲ｆｉｅｌｄ／ｅｌｅｍｅｎｔはＡＰ ＭＬＤ内の全てのリンクに対する情報を要求することを意味する。リンク範囲ｆｉｅｌｄ／ｅｌｅｍｅｎｔの値が第２値（例えば、１）である場合、リンク範囲ｆｉｅｌｄ／ｅｌｅｍｅｎｔはＡＰ ＭＬＤ内の一部のリンクに対する情報を要求することを意味する。

このとき、リンク範囲ｆｉｅｌｄ／ｅｌｅｍｅｎｔの値が第１値（例えば、０）である場合はＡＰ ＭＬＤ内の全体リンクに対する要求であるため別途のリンク指示（ｅ．ｇ．「Ｌｉｎｋ ｃｏｎｄｉｔｉｏｎ」ｆｉｅｌｄ）情報が必要ない。これとは逆に、リンク範囲ｆｉｅｌｄ／ｅｌｅｍｅｎｔの値が第２値（例えば、１）である場合はＡＰ ＭＬＤ内の一部のリンクに対する情報の要求であるためリンクインジケーター情報が必要である。例えば、このｆｉｅｌｄは８０２．１１ｂｅで定義したｍｕｌｔｉ－ｌｉｎｋ ｅｌｅｍｅｎｔに含まれて使用することができる。現在定義されたｍｕｌｔｉ－ｌｉｎｋ ｅｌｅｍｅｎｔは図２５の通りである。

図２５はＰｒｏｂｅ ｒｅｑｕｅｓｔ内の追加されたｍｕｌｔｉ－ｌｉｎｋ ｅｌｅｍｅｎｔの一例を示す。

図２５のように、ｎｏｎ－ＡＰ ＭＬＤがＡＰ ＭＬＤの情報の要求のために要求メッセージを送信する場合、Ｍｕｌｔｉ－ｌｉｎｋ ｅｌｅｍｅｎｔ内に「Ｒａｎｇｅ」ｆｉｅｌｄを追加して使用することができる。これに対する例示は図２６の通りである。

図２６はｍｕｌｔｉ－ｌｉｎｋ ｅｌｅｍｅｎｔにおいてＬｉｎｋ ｒａｎｇｅ ｆｉｅｌｄを使用する一例を示す。

図２６のように、Ｌｉｎｋ ｒａｎｇｅはＭＬＤ ＭＡＣ ａｄｄｒｅｓｓ ｆｉｅｌｄとともに使用され、当該ＭＬＤ内の全てのリンクの情報の要求を意味するか又は一部のリンクの情報を要求するか示すことができる。もしこのとき、当該フィールドの値が０であれば全てのリンクの情報の要求を意味することになるため、追加リンクインジケーター情報が必要なく「Ｐｅｒ－ＳＴＡ Ｐｒｏｆｉｌｅ（ｘ）」ｓｕｂ－ｅｌｅｍｅｎｔを省略することができる。

又、このｆｉｅｌｄは８０２．１１ｂｅで定義したｍｕｌｔｉ－ｌｉｎｋ ｅｌｅｍｅｎｔに含まれず、別のｅｌｅｍｅｎｔに追加され使用される。これに対する例は図２７の通りである。

図２７はＬｉｎｋの変更及び再接続を指示するために新しく提案したフィールドの一例を示す。

図２７のように、本明細書において提案する複数のフィールドはともに使用され図２７のように統合された形でＳＴＡがＡＰ ＭＬＤに要求する情報の範囲及び条件を指示することができる。又はＳＴＡはＡＰ ＭＬＤに情報を要求する時、それぞれ提案するフィールドを独立的に要求メッセージに含めることができ、不要な場合、省略することもできる。

情報範囲（Ｉｎｆｏ ｒａｎｇｅ）ｆｉｅｌｄ／ｅｌｅｍｅｎｔ

情報範囲（Ｉｎｆｏ ｒａｎｇｅ）ｆｉｅｌｄはｎｏｎ－ＡＰ ＭＬＤが情報を要求する場合、情報の範囲を指示するため使用することができる。

例えば、情報範囲（Ｉｎｆｏ ｒａｎｇｅ）ｆｉｅｌｄの値が第１値（例えば、０）である場合、情報範囲（Ｉｎｆｏ ｒａｎｇｅ）ｆｉｅｌｄはＡＰが持った一部の情報のみ提供されることを示すことができる。情報範囲（Ｉｎｆｏ ｒａｎｇｅ）ｆｉｅｌｄの値が第２値（例えば、１）である場合、情報範囲（Ｉｎｆｏ ｒａｎｇｅ）ｆｉｅｌｄはＡＰが持った全ての情報（又は全体情報）が提供されることを示すことができる。

一実施形態によれば、ＡＰが持った情報（ｅｌｅｍｅｎｔ）の全体又は一部要求を示すために情報範囲（Ｉｎｆｏ ｒａｎｇｅ）ｆｉｅｌｄが定義できるが、ＳＴＡは追加的なｓｕｂｆｉｅｌｄを介してより細かな情報を要求することもできる。例えば、提供される情報範囲（例えば、ａｌｌ ｉｎｆｏｒｍａｔｉｏｎ又はｐａｒｔｉａｌ ｉｎｆｏｒｍａｔｉｏｎ）を指示するためのｓｕｂｆｉｅｌｄが情報範囲ｆｉｅｌｄに含まれる場合もある。例えば、提供される情報範囲を指示するためのｓｕｂｆｉｅｌｄはａｌｌ／ｐａｒｔｉａｌ ｓｕｂｆｉｅｌｄとして定義／設定することができる。

一実施形態によれば、全ての情報を提供されるか否か又は前記全ての情報のうち、変更された情報のみを提供されるか否かを示すためのｓｕｂｆｉｅｌｄが新しく提案される。つまり、前記新しく提案されたｓｕｂｆｉｅｌｄは全ての情報を提供されるか否か又は前記全ての情報のうち、変更された情報のみを提供されるか否かを指示することができる。

例えば、全ての情報を提供されるか否か又は前記全ての情報のうち、変更された情報のみを提供されるか否かを示すためのｓｕｂｆｉｅｌｄはｏｎｌｙ ｕｐｄａｔｅｄ ｓｕｂｆｉｅｌｄとして定義／設定することができる。

ＳＴＡが変更された情報のみの受信を希望する場合、ｏｎｌｙ ｕｐｄａｔｅｄ ｓｕｂｆｉｅｌｄの値が１に設定することができる。つまり、ＳＴＡが変更された情報のみの受信を希望する場合、前記ＳＴＡはｏｎｌｙ ｕｐｄａｔｅｄ ｓｕｂｆｉｅｌｄの値を１に設定することができる。例えば、ｏｎｌｙ ｕｐｄａｔｅｄ ｓｕｂｆｉｅｌｄの値が１に設定された場合、ｓｏｌｉｃｉｔｅｄ方法によれば、ＳＴＡが情報を要求する時、ＡＰ（又はＡＰ ＭＬＤ）は要求した情報のうち、変更された情報（すなわち、更新された情報）のみを送信することができる。他の例として、ｏｎｌｙ ｕｐｄａｔｅｄ ｓｕｂｆｉｅｌｄの値が１に設定された場合、ｕｎｓｏｌｉｃｉｔｅｄ方法によれば、ＡＰはＳＴＡが設定した情報範囲において変更された情報のみを告知（ｎｏｔｉｆｙ）することができる。

前記の例によれば、変更された情報のみを受信するために、情報範囲（Ｉｎｆｏ ｒａｎｇｅ）ｆｉｅｌｄ内のｏｎｌｙ ｕｐｄａｔｅｄ ｓｕｂｆｉｅｌｄが提案されたが、これに限られるものではない。変更された情報のみを受信するために、別途のｆｉｅｌｄ又はｅｌｅｍｅｎｔを定義／設定することもできる。

上述した実施形態によれば、ＳＴＡが要求できる情報の範囲がＵｐｄａｔｅされた情報又は全ての情報に設定することができる。この場合、多いフレームオーバーヘッドを希望しないＳＴＡは変更された情報に対してのみ受信するように要求することができる。したがって、オーバーヘッドを減らせる効果がある。

リンク条件（Ｌｉｎｋ ｃｏｎｄｉｔｉｏｎ）ｆｉｅｌｄ／ｅｌｅｍｅｎｔ

リンク条件（Ｌｉｎｋ ｃｏｎｄｉｔｉｏｎ）ｆｉｅｌｄは要求する特定のリンクを指示するために使用することができる。つまり、リンク条件（Ｌｉｎｋ ｃｏｎｄｉｔｉｏｎ）ｆｉｅｌｄは要求する特定のリンクに関する情報を含むことができる。リンク条件ｆｉｅｌｄはＳＴＡが特定のリンク情報のみをＡＰから提供されることを希望する場合使用することができる。

リンク条件（Ｌｉｎｋ ｃｏｎｄｉｔｉｏｎ）ｆｉｅｌｄはリンク識別子（ｅ．ｇ．Ｌｉｎｋ ＩＤ、ＢＳＳ ＩＤ）として示すことができる。つまり、リンク条件（Ｌｉｎｋ ｃｏｎｄｉｔｉｏｎ）ｆｉｅｌｄはリンク識別子（ｅ．ｇ．Ｌｉｎｋ ＩＤ、ＢＳＳ ＩＤ）に関する情報を含むことができる。つまり、情報を獲得するためのリンクを特定のするために、リンク識別子を使用することができる。

例えば、Ｌｉｎｋ１に接続されたＳＴＡがＬｉｎｋ２、Ｌｉｎｋ３に対する情報のみをＡＰに要求したい場合、ＳＴＡはリンク条件ｆｉｅｌｄにｌｉｎｋ２、ｌｉｎｋ３を表示してＬｉｎｋ２、Ｌｉｎｋ３に対する情報をＡＰに要求することができる。例えば、上述したＩｎｆｏ ｒａｎｇｅ ｆｉｅｌｄの値が１である場合、ｌｉｎｋ２、ｌｉｎｋ３に該当する全ての情報が送信される。他の例として、上述したＩｎｆｏ ｒａｎｇｅ ｆｉｅｌｄの値が０である場合、ｌｉｎｋ２、ｌｉｎｋ３においてＳＴＡが指定した一部の情報が送信される。一実施形態によれば、ＳＴＡが指定する一部の情報は以下のＩｎｆｏ ｃｏｎｄｉｔｉｏｎ ｆｉｅｌｄを介して決定することができる。

一実施形態によれば、リンク条件（Ｌｉｎｋ ｃｏｎｄｉｔｉｏｎ）ｆｉｅｌｄの値がないか０である場合、ＡＰはリンク条件がないと判断することができる。したがって、ＡＰはＳＴＡに全てのリンクに関する情報を提供／送信することができる。

情報条件（Ｉｎｆｏ ｃｏｎｄｉｔｉｏｎ）ｆｉｅｌｄ／ｅｌｅｍｅｎｔ

情報条件（Ｉｎｆｏ ｃｏｎｄｉｔｉｏｎ）ｆｉｅｌｄは要求する特定の情報種類を指示するために使用することができる。つまり、情報条件（Ｉｎｆｏ ｃｏｎｄｉｔｉｏｎ）ｆｉｅｌｄはＳＴＡが特定の情報のみをＡＰから提供されることを希望する場合使用することができる。

例えば、情報条件ｆｉｅｌｄはＩｎｆｏ ｒａｎｇｅ ｆｉｅｌｄが０に設定された場合にのみ使用することができる。他の例として、情報条件ｆｉｅｌｄはＩｎｆｏ ｒａｎｇｅ ｆｉｅｌｄがない場合でもＳＴＡが特定の情報を指示するために使用することができる。

例えば、情報条件ｆｉｅｌｄ内において、ＳＴＡが指定可能な情報（ｅ．ｇ．ＢＳＳ ｌｏａｄ、ＳＴＲ Ｃａｐａｂｉｌｉｔｙなど）がＢｉｔｍａｐとして示すことができる。一例として、ＡＰが提供する情報の種類及びＢｉｔ内の指示方法又は手順などは多様に設定することができる。

一実施形態によれば、情報条件ｆｉｅｌｄは上述したリンク条件ｆｉｅｌｄとともに使用することができる。一実施形態によれば、情報条件ｆｉｅｌｄは様々なｆｉｅｌｄ／ｅｌｅｍｅｎｔの組み合わせに基づいて、様々な条件の要求情報をＳＴＡ（又はＡＰ）に送信することができる。

これに関連して、ＳＴＡが特定の情報を指示するように要求するために既存の規格のＥｌｅｍｅｎｔを再利用することもできる。例えば、Ｒｅｑｕｅｓｔ ＩＥ又はＥｘｔｅｎｄｅｄ Ｒｅｑｕｅｓｔ ＩＥを使用することができる。これに対するｅｌｅｍｅｎｔ情報は図２８及び図２９の通りである。

図２８はＲｅｑｕｅｓｔ ＩＥフォーマットの一例を示す。

図２９はＥｘｔｅｎｄｅｄ Ｒｅｑｕｅｓｔ ＩＥフォーマットの一例を示す。

図２８及び図２９のｅｌｅｍｅｎｔはＰｒｏｂｅ ｒｅｑｕｅｓｔ ｆｒａｍｅ又はｉｎｆｏｒｍａｔｉｏｎ ｒｅｑｕｅｓｔ ｆｒａｍｅに特定の情報を要求するために使用することができる。ＳＴＡが応答を獲得したい情報に対するリストをｒｅｑｕｅｓｔｅｄ ｅｌｅｍｅｎｔ ＩＤｓに指示すれば、ＡＰはそれに対応する情報をＰｒｏｂｅ Ｒｅｓｐｏｎｓｅ ｆｒａｍｅ又はｉｎｆｏｒｍａｔｉｏｎ Ｒｅｓｐｏｎｓｅ ｆｒａｍｅに含めて送信する。したがって、本明細書でもこのｅｌｅｍｅｎｔを特定の情報を要求するためのインジケーターで再利用することができ、リンク識別子（ｅ．ｇ．Ｌｉｎｋ Ｉｄｅｎｔｉｆｉｅｒ）とともに希望するリンクの情報を要求するために使用することもできる。例えば、図２８及び図２９において言及したＲｅｑｕｅｓｔ ｅｌｅｍｅｎｔにＢＳＳ ｌｏａｄ情報に対するｅｌｅｍｅｎｔ ＩＤを指示してＡＰ２に対する情報が欲しい場合Ｌｉｎｋ Ｉｄｅｎｔｉｆｉｅｒに指示する場合ＡＰ２のＢＳＳ ｌｏａｄ情報のみを要求することができる。このようなｅｌｅｍｅｎｔ ＩＤ情報はＬｉｎｋ識別子の情報とともに様々な組み合わせで特定のＡＰの特定の情報を指示することに使用することができる。もし、本発明において既存のフレームではない情報の要求のための新規フレームを定義する場合でも図２８及び図２９のＲｅｑｕｅｓｔ ｅｌｅｍｅｎｔ及びＥｘｔｅｎｄｅｄ Ｒｅｑｕｅｓｔ ｅｌｅｍｅｎｔは再利用できる。

また、既存の規格では特定の情報を要求するためにＰＶ １ Ｐｒｏｂｅ Ｒｅｓｐｏｎｓｅ Ｏｐｔｉｏｎ ｅｌｅｍｅｎｔを提供することに、特定の情報を指示する方法でこのようなｅｌｅｍｅｎｔを再利用することもできる。ＳＴＡが獲得したい情報をＰｒｏｂｅ ｒｅｑｕｅｓｔとしてｏｐｔｉｏｎａｌ ｉｎｆｏｒｍａｔｉｏｎを要求するために使用する方法で頻繁に使用する情報に対して、以下のようにＰｒｏｂｅ Ｒｅｓｐｏｎｓｅ Ｏｐｔｉｏｎ ｂｉｔｍａｐで各情報を指示している。但し、１１ｂｅの場合、ＭＬＤを考慮してｍｕｌｔｉ－ｌｉｎｋの情報を提供する必要があるため、ＳＴＡは以下のようなｂｉｔｍａｐインジケーターとともにＬｉｎｋ Ｉｄｅｎｔｉｆｉｅｒを使用して様々な組み合わせの特定のリンクの特定の情報を要求することができる。但し、この場合、８０２．１１ｂｅにおいてｍｕｌｔｉ－ｌｉｎｋとともに新しく定義されるｏｐｔｉｏｎａｌ ｉｎｆｏｒｍａｔｉｏｎ（ｅ．ｇ．ＳＴＲ Ｃａｐａｂｉｌｉｔｙ）があり得るため、もしこのＰＶ １ Ｐｒｏｂｅ Ｒｅｓｐｏｎｓｅ Ｏｐｔｉｏｎ ｅｌｅｍｅｎｔを再利用する場合は１１ｂｅにおいて新しく定義されるかさらに獲得する必要がある情報に対するｂｉｔｍａｐが新規定義又は追加定義される必要がある。

図３０はＰＶ １ Ｐｒｏｂｅ Ｒｅｓｐｏｎｓｅ Ｏｐｔｉｏｎ ｅｌｅｍｅｎｔフォーマットの一例を示す。

送信周期性（ｐｅｒｉｏｄｉｃ）ｆｉｅｌｄ／ｅｌｅｍｅｎｔ

ＳＴＡがＵｎｓｏｌｉｃｉｔｅｄ方法で情報を提供したい場合、前記情報を含むメッセージを周期的に受信するか非周期的に受信するか否かを送信周期性（ｐｅｒｉｏｄｉｃ）ｆｉｅｌｄを介して指示することができる。

例えば、ＳＴＡが前記情報を非周期的に受信したい場合、Ｏｔｈｅｒ ＡＰの情報に対して更新が発生するとき毎に更新された情報に対してＡＰが告知することができる。

他の例として、ＳＴＡが前記情報を周期的に受信するよう指示する場合はＳＴＡが設定した周期間隔で前記情報を含むメッセージを受信することもできる。

一実施形態によれば、送信周期性（ｐｅｒｉｏｄｉｃ）ｆｉｅｌｄが１ｂｉｔに設定することができる。送信周期性（ｐｅｒｉｏｄｉｃ）ｆｉｅｌｄの値が１に設定される場合、ＳＴＡは周期的にメッセージを受信するｐｅｒｉｏｄｉｃ方法を介して情報を受信／獲得することができる。送信周期性（ｐｅｒｉｏｄｉｃ）ｆｉｅｌｄの値が０に設定される場合、ＳＴＡは非周期的にメッセージを受信する方法を介して情報を受信／獲得することができる。

送信周期（ｉｎｔｅｒｖａｌ）ｆｉｅｌｄ／ｅｌｅｍｅｎｔ

一実施形態によれば、ＳＴＡが周期的にＯｔｈｅｒ ＡＰの情報を受信したい場合、ＳＴＡはその周期を直接設定することもできる。ＳＴＡは送信周期（ｉｎｔｅｒｖａｌ）ｆｉｅｌｄに基づいて、Ｏｔｈｅｒ ＡＰ情報を受信する周期に関する情報を送信することができる。但し、周期はＢｅａｃｏｎ送信周期よりは短く設定する必要がある。例えば、ＦＩＬＳ ｄｉｓｃｏｖｅｒｙ ｆｒａｍｅが使用される場合、その周期は２０ｕｓに設定する必要がある。

上述したように送信周期を指示するｅｌｅｍｅｎｔ内の別途のｆｉｅｌｄとして定義され、送信周期性ｆｉｅｌｄ（ｐｅｒｉｏｄｉｃ ｆｉｅｌｄ）内ｓｕｂｆｉｅｌｄとしても定義される。

一実施形態によれば、多重リンクに関する追加情報を獲得するために定義／設定されるｆｉｅｌｄ／ｅｌｅｍｅｎｔは上述したｆｉｅｌｄ／ｅｌｅｍｅｎｔに限られず、様々なｆｉｅｌｄ／ｅｌｅｍｅｎｔがさらに設定される。

したがって、ＭＬＤ（ＡＰ ＭＬＤ又はｎｏｎ－ＡＰ ＭＬＤ）はｍｕｌｔｉ－ｌｉｎｋ ｓｅｔｕｐプロセスにおいて上述したｅｌｅｍｅｎｔｓ／ｆｉｅｌｄｓのうち、少なくとも１つを使用してＡＰ ＭＬＤとｎｏｎ－ＡＰ ＭＬＤ間のｎｅｇｏｔｉａｔｉｏｎを介してＩＯＭ機能（ｃａｐａｂｉｌｉｔｙ）を指示することができる。又、ＭＬＤはｍｕｌｔｉ－ｌｉｎｋ ｓｅｔｕｐ完了以降、別途のメッセージ交換を介してＭＬＤ間の合意内容を更新させることができる。

一実施形態によれば、ＩＯＭ機能（ｃａｐａｂｉｌｉｔｙ）が活性化された場合、リンク変更及び再接続のための実施形態に基づいてＡＰ ＭＬＤ及びｎｏｎ－ＡＰ ＭＬＤが動作することができる。

以下では、ＩＯＭ機能（ｃａｐａｂｉｌｉｔｙ）が活性化された場合ＡＰ ＭＬＤ及びｎｏｎ－ＡＰ ＭＬＤの動作の例が説明される。例えば、ｎｏｎ－ＡＰ ＭＬＤが上述したｆｉｅｌｄ／ｅｌｅｍｅｎｔをＡＰ ＭＬＤに送信することで、多重リンクのための追加情報を要求することができる。ｎｏｎ－ＡＰ ＭＬＤは上述したｆｉｅｌｄ／ｅｌｅｍｅｎｔを含むＩＯＭ ｃａｐａｂｉｌｉｔｙ ｅｌｅｍｅｎｔをＡＰ ＭＬＤに送信することができる。上述したｆｉｅｌｄ／ｅｌｅｍｅｎｔがＩＯＭ ｃａｐａｂｉｌｉｔｙ ｅｌｅｍｅｎｔに含まれることは例示的なものであり、独立的なｆｉｅｌｄ／ｅｌｅｍｅｎｔとして送信される。

例えば、ｍｕｌｔｉ－ｌｉｎｋ ｓｅｔｕｐプロセスにおいてｎｏｎ－ＡＰ ＭＬＤは「Ｍｅｔｈｏｄ ｆｉｅｌｄ＝０」及び「Ｉｎｆｏ ｒａｎｇｅ ｆｉｅｌｄ＝１」を含むＩＯＭ ｃａｐａｂｉｌｉｔｙ ｅｌｅｍｅｎｔをＡＰ ＭＬＤに送信しＡＰ ＭＬＤとこれに対して合意することができる。この場合、ｍｕｌｔｉ－ｌｉｎｋ ｓｅｔｕｐ以降ｎｏｎ－ＡＰ ＭＬＤはＳｏｌｉｃｉｔｅｄ ｍｅｔｈｏｄに動作し、情報を要求する時、ｂｅａｃｏｎに含まれた全ての情報を含む多重リンクのための情報（例えば、Ｏｔｈｅｒ ＡＰに関する情報）を要求することができる。したがって、ＡＰ ＭＬＤはＳＴＡから要求メッセージを受信した場合にのみ、Ｌｉｎｋに対する情報を応答メッセージで提供／送信することができる。ＡＰ ＭＬＤは要求メッセージ受信する時、ＡＰ ＭＬＤ内の全てのリンクに対する情報を含む応答メッセージをＳＴＡに送信することができる。前記ＡＰ ＭＬＤ内の全てのリンクに対する情報はｂｅａｃｏｎに含まれた情報を全て含むことができる。

他の例として、ｎｏｎ－ＡＰ ＭＬＤは「Ｍｅｔｈｏｄ ｆｉｅｌｄ＝１」、「Ｉｎｆｏ ｒａｎｇｅ ｆｉｅｌｄ＝０」、「Ｌｉｎｋ ｒａｎｇｅ＝Ｌｉｎｋ ＩＤ２」、「Ｉｎｆｏ ｃｏｎｄｉｔｉｏｎ ｆｉｅｌｄ＝（ｂｉｔｍａｐを介してＢＳＳ ｌｏａｄを表示した値）」を含むＩＯＭ ｃａｐａｂｉｌｉｔｙ ｅｌｅｍｅｎｔをＡＰ ＭＬＤに送信しＡＰ ＭＬＤとこれに対して合意することができる。この場合、ｍｕｌｔｉ－ｌｉｎｋ ｓｅｔｕｐ以降、ｎｏｎ－ＡＰ ＭＬＤはＵｎＳｏｌｉｃｉｔｅｄ ｍｅｔｈｏｄに動作することができる。したがって、別途の要求メッセージなしにもＡＰはＬｉｎｋ２のＢＳＳ ｌｏａｄ情報を別途のメッセージを介してＳＴＡに送信することができる。

他の例として、ｎｏｎ－ＡＰ ＭＬＤは「Ｍｅｔｈｏｄ ｆｉｅｌｄ＝０」、「Ｉｎｆｏ ｒａｎｇｅ ｆｉｅｌｄ＝０」、「ｏｎｌｙ ｕｐｄａｔｅｄ ｆｉｅｌｄ ｏｒ ｓｕｂｆｉｅｌｄ＝１」、「Ｉｎｆｏ ｃｏｎｄｉｔｉｏｎ ｆｉｅｌｄ＝（ｂｉｔｍａｐを介してＢＳＳ ｌｏａｄを表示した値）」を含むＩＯＭ ｃａｐａｂｉｌｉｔｙ ｅｌｅｍｅｎｔをＡＰ ＭＬＤに送信しＡＰ ＭＬＤとこれに対して合意することができる。この場合、ｍｕｌｔｉ－ｌｉｎｋ ｓｅｔｕｐ以降ｎｏｎ－ＡＰ ＭＬＤはＳｏｌｉｃｉｔｅｄ ｍｅｔｈｏｄに動作することができる。したがって、ＡＰ ＭＬＤ（又はＡＰ）はＳＴＡが情報を要求する時、接続されたＡＰ ＭＬＤの全てのＡＰのＢＳＳ ｌｏａｄ情報のうち、更新された（変更された）情報のみを応答メッセージに含めてＳＴＡに送信することができる。

本明細書ではＳＴＡが接続ＡＰ ＭＬＤのＯｔｈｅｒ ＡＰの一部の情報（すなわち、ｔａｒｇｅｔ ｉｎｆｏｒｍａｔｉｏｎ）を要求するために新規ｅｌｅｍｅｎｔのための複数のオプションを提案する。

図３１はＭＬＤ Ｒｅｑｕｅｓｔ ｅｌｅｍｅｎｔの一例を示す。

図３１を参照すれば、「Ｔｈｅ ｎｕｍｂｅｒ ｏｆ Ｌｉｎｋ ＩＤ」はＳＴＡが特定のＡＰの情報を要求する場合、要求するＡＰ（すなわち、リンク）の数を指示するためのフィールドである。

「Ｌｉｎｋ ＩＤ」はＳＴＡが要求するＡＰのインジケーター情報を含むフィールドである。

例えば、ＳＴＡがＰｒｏｂｅ ｒｅｑｕｅｓｔ ｆｒａｍｅに上記のようなＭＬＤ Ｒｅｑｕｅｓｔ ｅｌｅｍｅｎｔを含めて送信する場合、ｒｅｑｕｅｓｔ ｍｅｓｓａｇｅを受信したＡＰは当該ｅｌｅｍｅｎｔに指示されたＡＰの全体情報を含んだＰｒｏｂｅ Ｒｅｓｐｏｎｓｅを応答する。もしＳＴＡが指示されたＡＰの全体情報ではない一部の情報を要求したい場合はＰｒｏｂｅ ｒｅｑｕｅｓｔ ｆｒａｍｅにＭＬＤ Ｒｅｑｕｅｓｔ ｅｌｅｍｅｎｔとともに既存の規格で定義したＲｅｑｕｅｓｔ ｅｌｅｍｅｎｔ又はＥｘｔｅｎｄｅｄ Ｒｅｑｕｅｓｔ ｅｌｅｍｅｎｔを含めて送信すれば、これを受信したＡＰはＲｅｑｕｅｓｔ ｅｌｅｍｅｎｔ又はＥｘｔｅｎｄｅｄ Ｒｅｑｕｅｓｔ ｅｌｅｍｅｎｔにおいて指示する情報のみを含めてＰｒｏｂｅ Ｒｅｓｐｏｎｓｅで応答する。

さらに、図３２の新規ｅｌｅｍｅｎｔも提案する。

図３２はＭＬＤ Ｒｅｑｕｅｓｔ ｅｌｅｍｅｎｔの他の例を示す。

図３２を参照すれば、「Ｔｈｅ ｎｕｍｂｅｒ ｏｆ Ｌｉｎｋ ＩＤ」はＳＴＡが特定のＡＰの情報を要求する場合、要求するＡＰ（すなわち、リンク）の数を指示するためのフィールドである。

「Ｌｉｎｋ ＩＤ」はＳＴＡが要求するＡＰのインジケーター情報を含むフィールドである。

「Ｒｅｑｕｅｓｔｅｄ ｅｌｅｍｅｎｔ ＩＤｓ／Ｒｅｑｕｅｓｔｅｄ ｅｌｅｍｅｎｔ ＩＤ ｅｘｔｅｎｓｉｏｎｓ」はＳＴＡが特定の情報（すなわち、ｅｌｅｍｅｎｔ）を要求する場合、要求する情報のＥｌｅｍｅｎｔ ＩＤ情報を含むフィールドである。このフィールドはＥｌｅｍｅｎｔ ＩＤが０－２５４に該当する場合はｅｌｅｍｅｎｔ ＩＤ情報のみを含み、もし２５５以上の値である場合はＥｘｔｅｎｄｅｄ Ｅｌｅｍｅｎｔ ＩＤとして認知してＲｅｑｕｅｓｔｅｄ ｅｌｅｍｅｎｔ ＩＤ ｅｘｔｅｎｓｉｏｎｓ情報がともに含まれる必要がある。このとき、「Ｒｅｑｕｅｓｔｅｄ ｅｌｅｍｅｎｔ ＩＤｓ／Ｒｅｑｕｅｓｔｅｄ ｅｌｅｍｅｎｔ ＩＤ ｅｘｔｅｎｓｉｏｎｓ」に該当する情報はＦｉｅｌｄ形で定義されることもできるが図３３のように新規ｅｌｅｍｅｎｔとして定義されＭＬＤ Ｒｅｑｕｅｓｔ ｅｌｅｍｅｎｔにｓｕｂ－ｅｌｅｍｅｎｔ形で含まれる。これに対する新規Ｅｌｅｍｅｎｔは図３３のように定義することができる。当該ｅｌｅｍｅｎｔは既存Ｒｅｑｕｅｓｔ ｅｌｅｍｅｎｔ又はＥｘｔｅｎｄｅｄ Ｒｅｑｕｅｓｔ ｅｌｅｍｅｎｔを区分せず１つのｅｌｅｍｅｎｔに指示することができオーバーヘッドを減らすことができる利点がある。

図３３はＭＬＤ Ｒｅｑｕｅｓｔ ｅｌｅｍｅｎｔに基づいて新規ｅｌｅｍｅｎｔを定義した一例を示す。

例えば、ＳＴＡがＰｒｏｂｅ ｒｅｑｕｅｓｔ ｆｒａｍｅに上記のようなＭＬＤ Ｒｅｑｕｅｓｔ ｅｌｅｍｅｎｔを含めて送信する場合、ｒｅｑｕｅｓｔ ｍｅｓｓａｇｅを受信したＡＰは当該ｅｌｅｍｅｎｔに指示されたＡＰの情報を含んだＰｒｏｂｅ Ｒｅｓｐｏｎｓｅを応答する。

図３３を参照すれば、当該ｅｌｅｍｅｎｔにおいて「Ｒｅｑｕｅｓｔｅｄ ｅｌｅｍｅｎｔ ＩＤｓ／Ｒｅｑｕｅｓｔｅｄ ｅｌｅｍｅｎｔ ＩＤ ｅｘｔｅｎｓｉｏｎｓ」フィールド省略可否によってＡＰはＳＴＡが要求する情報を全体又は部分情報として認知する。規格に定義されたＥｌｅｍｅｎｔ ＩＤ値情報は８０２．１１規格で定義されている。そして本明細書において言及する「Ｒｅｑｕｅｓｔｅｄ ｅｌｅｍｅｎｔ ＩＤｓ」と「Ｅｌｅｍｅｎｔ ＩＤ ｅｘｔｅｎｓｉｏｎｓ」の定義は既存の規格と同じである。

例えば、もしＳＴＡがＡＰにＡＰ又はＯｔｈｅｒ ＡＰの情報を要求する場合、Ｐｒｏｂｅ ｒｅｑｕｅｓｔ ｆｒａｍｅに上記の ＭＬＤ Ｒｅｑｕｅｓｔ ｅｌｅｍｅｎｔを含めて送信する。これを受信したＡＰは「Ｌｉｎｋ ＩＤ」フィールドを介して要求されたＡＰの情報のうち、「Ｒｅｑｕｅｓｔｅｄ ｅｌｅｍｅｎｔ ＩＤｓ／Ｒｅｑｕｅｓｔｅｄ ｅｌｅｍｅｎｔ ＩＤ ｅｘｔｅｎｓｉｏｎｓ」フィールドを介して要求された情報のみを含めＰｒｏｂｅ Ｒｅｓｐｏｎｓｅ ｆｒａｍｅを応答する。

このとき、もしＳＴＡが「Ｒｅｑｕｅｓｔｅｄ ｅｌｅｍｅｎｔ ＩＤｓ／Ｒｅｑｕｅｓｔｅｄ ｅｌｅｍｅｎｔ ＩＤ ｅｘｔｅｎｓｉｏｎｓ」フィールドを省略して送信する場合は、これを受信したＡＰは「Ｌｉｎｋ ＩＤ」フィールドを介して要求されたＡＰの全体情報を含めてＰｒｏｂｅ Ｒｅｓｐｏｎｓｅ ｆｒａｍｅを応答する。

上記提案したｆｏｒｍａｔは全てのリンクに対する同じ情報のみを要求することができる。

しかし、ＳＴＡは場合によってリンク別に異なる情報を要求することもできる。本明細書ではそのための複数のオプションを提案する。

第１に、図３４のようにリンク別に異なる情報を要求するためのｆｏｒｍａｔをさらに提案する。

図３４はＭＬＤ Ｒｅｑｕｅｓｔ ｅｌｅｍｅｎｔの他の例を示す。

図３４のように、ＳＴＡはリンク別異なる情報を要求するためにＭＬＥ Ｒｅｑｕｅｓｔ ｅｌｅｍｅｎｔ内においてリンク別に既存Ｒｅｑｕｅｓｔ ｅｌｅｍｅｎｔ ｏｒ／ａｎｄ Ｅｘｔｅｎｄｅｄ Ｒｅｑｕｅｓｔ ｅｌｅｍｅｎｔ情報を含めて示す方法である。このとき、要求するｅｌｅｍｅｎｔの長さを知らせるために新規フィールド又は要素「Ｔｈｅ ｎｕｍｂｅｒ ｏｆ Ｅｌｅｍｅｎｔｓ」を定義する。この情報はＬｉｎｋ ＩＤ（ｘ）に対して要求されたｅｌｅｍｅｎｔｓの数を意味する。

これを受信したＡＰはＭＬＤ Ｒｅｑｕｅｓｔ ｅｌｅｍｅｎｔに基づいて各リンク別に異なる要求をされた情報を確認してＲｅｓｐｏｎｓｅ ｆｒａｍｅに含めて応答する。

このとき、既存Ｒｅｑｕｅｓｔ ｅｌｅｍｅｎｔ ｏｒ／ａｎｄ Ｅｘｔｅｎｄｅｄ Ｒｅｑｕｅｓｔ ｅｌｅｍｅｎｔではない本発明において提案するフィールドを使用する場合、実施形態は図３５の通りである。各フィールド又は要素は必要によって省略することができる。

図３５はＭＬＤ Ｒｅｑｕｅｓｔ ｅｌｅｍｅｎｔの他の例を示す。

第２に、ＳＴＡが情報を要求する時、全てのリンクに対して同じく要求するＣｏｍｍｏｎ情報とリンク別に異なる要求をするｌｉｎｋ ｓｐｅｃｉｆｉｃ情報を区分するｆｏｒｍａｔを図３６のように提案する。

図３６はＭＬＤ Ｒｅｑｕｅｓｔ ｅｌｅｍｅｎｔの他の例を示す。

図３６のように、Ｔｈｅ ｎｕｍｂｅｒ ｏｆ Ｌｉｎｋ ＩＤフィールドの前にＲｅｑｕｅｓｔ ｅｌｅｍｅｎｔ ｏｒ／ａｎｄ Ｅｘｔｅｎｄｅｄ Ｒｅｑｕｅｓｔ ｅｌｅｍｅｎｔが含まれた場合、後で指示するリンクに対して共通的に要求するＣｏｍｍｏｎ情報に対するｅｌｅｍｅｎｔｓを意味し、Ｔｈｅ ｎｕｍｂｅｒ ｏｆ Ｌｉｎｋ ＩＤフィールドの後にＬｉｎｋ ＩＤ（ｘ）とともにＴｈｅ ｎｕｍｂｅｒ ｏｆ Ｅｌｅｍｅｎｔｓの後に並べられた情報はリンク別に要求するｅｌｅｍｅｎｔ情報を意味する。各フィールド又は要素は必要によって省略することができる。

このとき、既存Ｒｅｑｕｅｓｔ ｅｌｅｍｅｎｔ ｏｒ／ａｎｄ Ｅｘｔｅｎｄｅｄ Ｒｅｑｕｅｓｔ ｅｌｅｍｅｎｔではない本発明において提案するフィールドを使用する場合、実施形態は図３７の通りである。各フィールド又は要素は必要によって省略することができる。

図３７はＭＬＤ Ｒｅｑｕｅｓｔ ｅｌｅｍｅｎｔの他の例を示す。

図３７のように、Ｔｈｅ ｎｕｍｂｅｒ ｏｆ Ｌｉｎｋ ＩＤフィールドの前にＲｅｑｕｅｓｔ ｅｌｅｍｅｎｔ ｏｒ／ａｎｄ Ｅｘｔｅｎｄｅｄ Ｒｅｑｕｅｓｔ ｅｌｅｍｅｎｔが含まれた場合、後に指示するリンクに対して共通的に要求するＣｏｍｍｏｎ情報に対するｅｌｅｍｅｎｔｓを意味し、Ｔｈｅ ｎｕｍｂｅｒ ｏｆ Ｌｉｎｋ ＩＤフィールドの後にＬｉｎｋ ＩＤ（ｘ）とともにＴｈｅ ｎｕｍｂｅｒ ｏｆ Ｅｌｅｍｅｎｔｓの後に並べられた情報はリンク別に要求するｅｌｅｍｅｎｔ情報を意味する。各フィールド又は要素は必要によって省略することができる。

第４に、ＳＴＡが情報を要求する時、全てのリンクに対して同じく要求するＣｏｍｍｏｎ情報はＭＬＤ Ｒｅｑｕｅｓｔ ｅｌｅｍｅｎｔとともに別途のＲｅｑｕｅｓｔ ｅｌｅｍｅｎｔ又はＥｘｔｅｎｄｅｄ Ｒｅｑｕｅｓｔ ｅｌｅｍｅｎｔとして図３８のように指示することに使用される。

図３８はＣｏｍｍｏｎ情報を要求するフィールドの一例を示す。

ＳＴＡがＲｅｑｕｅｓｔ ｆｒａｍｅを介してＡＰ ＭＬＤの複数のリンクに対する情報を要求する場合、共通的に要求する情報は既存Ｒｅｑｕｅｓｔ ｏｒ／ａｎｄ Ｅｘｔｅｎｄｅｄ Ｒｅｑｕｅｓｔ ｅｌｅｍｅｎｔを介して指示し、リンク別に異なる要求をする情報の場合、ＭＬＤ Ｒｅｑｕｅｓｔ ｅｌｅｍｅｎｔを介して指示する方法である。このとき、ＭＬＤ Ｒｅｑｕｅｓｔ ｅｌｅｍｅｎｔのｆｏｒｍａｔは複数の形で定義される。この要求メッセージを受信したＡＰはＲｅｑｕｅｓｔ ｏｒ／ａｎｄ Ｅｘｔｅｎｄｅｄ Ｒｅｑｕｅｓｔ ｅｌｅｍｅｎｔに含まれた情報はＭＬＤ Ｒｅｑｕｅｓｔ ｅｌｅｍｅｎｔに指示されたリンクに対して共通的に要求される情報として認知してＭＬＤ Ｒｅｑｕｅｓｔ ｅｌｅｍｅｎｔに指示された全てのリンクに対する当該の要素情報を応答メッセージに含めて送信する。さらに、ＳＴＡがリンク別に異なる情報を要求する場合はＭＬＤ Ｒｅｑｕｅｓｔ ｅｌｅｍｅｎｔ内にリンク別に指示された情報に基づいてＡＰが応答メッセージに含めて送信する。

８０２．１１ｂｅ規格で定義したＭＬ（Ｍｕｌｔｉ－Ｌｉｎｋ）ＩＥを使用してＳＴＡが接続ＡＰ ＭＬＤのＯｔｈｅｒ ＡＰの部分情報を要求する方法も提案する。

図３９は８０２．１１ｂｅで定義されたＭＬ ＩＥフォーマットの一例を示す。

８０２．１１ｂｅでは各リンク別情報を定義するために図３９のようにＭＬ ＩＥ（Ｍｕｌｔｉ－Ｌｉｎｋ Ｉｎｆｏｒｍａｔｉｏｎ Ｅｌｅｍｅｎｔ）を定義した。以降、提案する機能によってＥｌｅｍｅｎｔ又はＦｉｅｌｄが追加される。Ｐｅｒ－ＳＴＡ Ｐｒｏｆｉｌｅ（ｘ）ｓｕｂ－ｅｌｅｍｅｎｔでは当該リンクに対する複数の情報を含むことができる。当該ｓｕｂ－ｅｌｅｍｅｎｔはＰｅｒ－ＳＴＡ Ｃｏｎｔｒｏｌ ｆｉｅｌｄを介して 当該リンクＩＤ及び当該ｓｕｂ－ｅｌｅｍｅｎｔが含む情報範囲に対する内容を含み、以降ＳＴＡが要求した情報に該当する情報（Ｅｌｅｍｅｎｔ）を並べる。このとき、もしｎｏｎ－ｉｎｈｅｒｉｔａｎｃｅ情報がある場合ｎｏｎ－ｉｎｈｅｒｉｔａｎｃｅ ｅｌｅｍｅｎｔを使用して情報を含むこともできる。Ｐｅｒ－ＳＴＡ Ｃｏｎｔｒｏｌ ｓｕｂ－ｅｌｅｍｅｎｔ内のＣｏｍｐｌｅｔｅ Ｐｒｏｆｉｌｅは含まれた情報が当該リンクのＣｏｍｐｌｅｔｅ情報であるか、Ｐａｒｔｉａｌ情報あるかを区分するフィールドである。

したがってこのようなＭＬ ＩＥをｒｅｑｕｅｓｔ ｆｒａｍｅ（ｅ．ｇ．Ｐｒｏｂｅ ｒｅｑｕｅｓｔ ｆｒａｍｅ）に含め、ＳＴＡはＯｔｈｅｒ ＡＰの部分情報の要求に活用することができ、そのための様々なオプションを提案する。

本明細書ではＭＬＤ ＰｒｏｂｉｎｇのためにＭＬ ＩＥを使用するために以下のような制限要素を定義する。ＳＴＡがＭＬＤ ＰｒｏｂｉｎｇのためにＰｒｏｂｅ ｒｅｑｕｅｓｔ ｆｒａｍｅにおいてＭＬ ＩＥを使用する場合は、Ｐｅｒ－ＳＴＡ Ｐｒｏｆｉｌｅ（ｘ）において提供するＥｌｅｍｅｎｔ情報（ｅ．ｇ．Ｅｌｅｍｅｎｔｘ，…，Ｅｌｅｍｅｎｔｎ）はオーバーヘッドを減らすために省略して送信することができる。（但し、Ａｓｓｏｃｉａｔｉｏｎのために使用するＡｓｓｏｃｉａｔｉｏｎ ｒｅｑｕｅｓｔ／Ｒｅｓｐｏｎｓｅ ｆｒａｍｅにおいてＭＬ ＩＥを使用する場合はＥｌｅｍｅｎｔ情報が含まれる必要がある。）。ＳＴＡが要求する情報がＬｉｎｋのＣｏｍｐｌｅｔｅ情報である場合は、Ｐｅｒ－ＳＴＡ Ｃｏｎｔｒｏｌ ｆｉｅｌｄを介してＣｏｍｐｌｅｔｅ情報ｂｉｔを指示した後、ｅｌｅｍｅｎｔ情報リストは省略して送信する。そのではない場合、Ｐｅｒ－ＳＴＡ Ｃｏｎｔｒｏｌ ｆｉｅｌｄを介してＰａｒｔｉａｌ情報ｂｉｔを指示しての後に要求するｅｌｅｍｅｎｔ ＩＤに対する情報を追加する。但し、ＳＴＡが全体情報ではない特定の要素（Ｅｌｅｍｅｎｔ）に対する部分情報を要求する場合に関する複数のオプションに対しては以下で詳細に定義する。

上記のように、８０２．１１ｂｅで定義するＭＬ ＩＥは当該要素がＡｓｓｏｃｉａｔｉｏｎ ｆｒａｍｅ又はＰｒｏｂｅ ｆｒａｍｅに含まれるか当該ｆｒａｍｅがＲｅｑｕｅｓｔであるか、Ｒｅｓｐｏｎｓｅであるかにしたがって含まれる情報が変更される。例えば、ＳＴＡがＰｒｏｂｅ ｒｅｑｕｅｓｔするとき、ＭＬ ＩＥを使用する場合は、Ｐｅｒ－ＳＴＡ Ｐｒｏｆｉｌｅ（Ｘ）内の複数の情報を含むＥｌｅｍｅｎｔが省略されるが、そうではない場合はＥｌｅｍｅｎｔ情報を含める必要がある。したがって、これを指示するためのＣｏｎｔｒｏｌ ｆｉｅｌｄを提案する。

現在８０２．１１ｂｅ標準で定義したｍｕｌｔｉ－ｌｉｎｋ ｅｌｅｍｅｎｔとＭｕｌｔｉ－ｌｉｎｋ Ｃｏｎｔｒｏｌ ｆｉｅｌｄｆｏｒｍａｔは図４０の通りである。

図４０はｍｕｌｔｉ－ｌｉｎｋ ｅｌｅｍｅｎｔフォーマットとＭｕｌｔｉ－ｌｉｎｋ Ｃｏｎｔｒｏｌ ｆｉｅｌｄフォーマットの一例を示す。

このとき、現在Ｍｕｌｔｉ－ｌｉｎｋ ｅｌｅｍｅｎｔが含まれたｆｒａｍｅの形を指示するためのｆｉｅｌｄをＭｕｌｔｉ－ｌｉｎｋ Ｃｏｎｔｒｏｌ ｆｉｅｌｄ ｅｌｅｍｅｎｔに追加する。提案するｆｉｅｌｄは「Ｅｌｅｍｅｎｔｓ ｐｅｒ－ＳＴＡ Ｐｒｅｓｅｎｔ」として定義する。当該フィールドの名称は必要によって再定義される。当該フィールドは現在ＭＬ ＩＥが要求するＳＴＡ別Ｅｌｅｍｅｎｔリスト情報の有無を示す。当該の値が１である場合は、Ｐｅｒ－ＳＴＡ Ｐｒｏｆｉｌｅ（ｘ）フィールド内Ｐｅｒ－ＳＴＡ Ｃｏｎｔｒｏｌ ｆｉｅｌｄ後、ｅｌｅｍｅｎｔ情報が含まれていることを意味し、０である場合は、Ｐｅｒ－ＳＴＡ Ｐｒｏｆｉｌｅ（ｘ）フィールド内Ｐｅｒ－ＳＴＡ Ｃｏｎｔｒｏｌ ｆｉｅｌｄ後、ｅｌｅｍｅｎｔ情報が省略されていることを意味する。これに対する実施形態は図４１の通りである。

図４１はＭｕｌｔｉ－ｌｉｎｋ Ｃｏｎｔｒｏｌ ｆｉｅｌｄフォーマットの一例を示す。

さらに、上記説明したように８０２．１１ｂｅで定義するＭＬ ＩＥは当該要素がＡｓｓｏｃｉａｔｉｏｎ ｆｒａｍｅ又はＰｒｏｂｅ ｆｒａｍｅに含まれるか当該ｆｒａｍｅがＲｅｑｕｅｓｔであるかＲｅｓｐｏｎｓｅであるかにしたがって含まれる情報が変更される。したがって、これを指示できるｆｉｅｌｄを提案する。当該ｆｉｌｅｄはｒｅｑｕｅｓｔ／Ｒｅｓｐｏｎｓｅ ｆｒａｍｅのＭＬ ＩＥ内に含まれてＳＴＡが現在送信するＦｒａｍｅ ｔｙｐｅを示し、これによってさらに構成されるｅｌｅｍｅｎｔ（０ ｏｒ ｖａｒｉａｂｌｅで構成されたｅｌｅｍｅｎｔ）内容や配列手順が異なる場合がある。

「Ｆｒａｍｅ ｔｙｐｅ」：現在ＳＴＡが送信するＦｒａｍｅ ｔｙｐｅを意味するインジケーターである。当該フィールドの値によって現在ＭＬ ＩＥが含まれたｆｒａｍｅのｔｙｐｅを示す。例えば、０：Ａｓｓｏｃｉａｔｉｏｎ ｒｅｑｕｅｓｔ、１：ａｓｓｏｃｉａｔｉｏｎ ｒｅｓｐｏｎｓｅ、３：Ｐｒｏｂｅ ｒｅｑｕｅｓｔ、４：Ｐｒｏｂｅ Ｒｅｓｐｏｎｓｅなどで分けて指示することができる。これは整数の値として示すこともできるが、ｂｉｔｍａｐで示すこともできる。これ以外にも、８０２．１１ｂｅにおいて構成するＭＬＤ Ｐｒｏｂｉｎｇを区分すれば、さらに５：ＭＬＤ Ｐｒｏｂｅ ｒｅｑｕｅｓｔ ｆｒａｍｅ、６：ＭＬＤ Ｐｒｏｂｅ Ｒｅｓｐｏｎｓｅ ｆｒａｍｅなどを追加することもできる。このようにＦｒａｍｅ ｔｙｐｅによってＭＬ ＩＥのｅｌｅｍｅｎｔ構成が異なることを示すためのインジケーターである。各Ｆｒａｍｅ ｔｙｐｅは「Ｆｒａｍｅ ｔｙｐｅ」ｆｉｅｌｄ内のｓｕｂｆｉｅｌｄ形で並べて１である場合、指示するフレームタイプを示す形で構成される。

このとき、送信されるｆｒａｍｅの複数の機能によって「Ｆｒａｍｅ ｔｙｐｅ」内の複数のｓｕｂｆｉｅｌｄで再び分類することもできる。したがって、本明細書では「Ｆｒａｍｅ ｔｙｐｅ」内ｆｒａｍｅの目的によって詳細に分類するｓｕｂｆｉｅｌｄである「ｒｅｑｕｅｓｔ ｔｙｐｅ」を定義する。当該「ｒｅｑｕｅｓｔ ｔｙｐｅ」ｓｕｂｆｉｅｌｄは「Ｆｒａｍｅ ｔｙｐｅ」で分類されたメッセージの形においてより詳細に分類するものでありこれは現在送信されるｆｒａｍｅの目的によって分類される。例えば、「Ｆｒａｍｅ ｔｙｐｅ」が特定のＡＰに対する全体又は一部の情報を要求するためにＭＬＤ Ｐｒｏｂｅ ｒｅｑｕｅｓｔ ｆｒａｍｅを送信する場合、「Ｆｒａｍｅ ｔｙｐｅ」ｆｉｅｌｄはＭＬＤ Ｐｒｏｂｅ ｒｅｑｕｅｓｔ ｆｒａｍｅ（ｆｉｅｌｄ＝５）に設定されるが、要求する情報が全体又は部分であるか、また、部分情報を要求する時、当該情報がある特定の情報（ｅ．ｇ．Ｃｒｉｔｉｃａｌ ｕｐｄａｔｅ関連情報、ｌｉｎｋ ｒｅ－ｓｅｔｕｐのためのｓｅｔｕｐされないｌｉｎｋ ｓｕｂｓｅｔ情報など）を要求するかを「ｒｅｑｕｅｓｔ ｔｙｐｅ」で詳細に分類できる。もし「Ｆｒａｍｅ ｔｙｐｅ」が特定のＡＰに対するリンク転換のために（ｒｅ）Ａｓｓｏｃｉａｔｉｏｎ ｒｅｑｕｅｓｔ ｆｒａｍｅに設定された場合、「Ｆｒａｍｅ ｔｙｐｅ」ｆｉｅｌｄは（ｒｅ）Ａｓｓｏｃｉａｔｉｏｎ ｒｅｑｕｅｓｔ ｆｒａｍｅに設定されるが（参考に現在８０２．１１ｂｅにおいてＭＬＤ Ｐｒｏｂｅ ｒｅｑｕｅｓｔ ｆｒａｍｅを除いて全てのｆｒａｍｅを同じｂａｓｉｃ ｔｙｐｅで区分しているため、（ｒｅ）Ａｓｓｏｃｉａｔｉｏｎ ｒｅｑｕｅｓｔ ｆｒａｍｅはｂａｓｉｃ ｔｙｐｅで分類される。しかし、後にフレームタイプ分類は変更する場合もある）、フレームを要求する目的（ｅ．ｇ．ＴＩＤ－ｌｉｎｋ ｍａｐｐｉｎｇ、ＭＬＤ間Ｌｉｎｋ ｓｗｉｔｃｈｉｎｇ、同じＭＬＤ内のＬｉｎｋ ｓｗｉｔｃｈｉｎｇ）によって「ｒｅｑｕｅｓｔ ｔｙｐｅ」ｓｕｂｆｉｅｌｄにこれを指示することができる。これを受信したｎｏｎ－ＡＰ ＳＴＡ又はＡＰは現在受信したｆｒａｍｅのｔｙｐｅとともに転送されたｓｕｂｆｉｅｌｄの値を介してＳＴＡが送信したフレームの目的をより詳細に把握して適切な情報をＲｅｓｐｏｎｓｅ ｆｒａｍｅに含めて送信することができる。

ＳＴＡが全体情報ではない特定の要素（Ｅｌｅｍｅｎｔ）に対する部分情報を要求する場合に関するＭＬ ＩＥに対する複数のＦｏｒｍａｔオプション及び動作は以下のように提案する。

第１に、既存ＭＬ ＩＥ内Ｐｅｒ－ＳＴＡ Ｐｒｏｆｉｌｅ（ｘ）にＳＴＡが当該ＡＰに要求しようとする情報を指示するためのＲｅｑｕｅｓｔ ｅｌｅｍｅｎｔ ｏｒ／ａｎｄ Ｅｘｔｅｎｄｅｄ Ｒｅｑｕｅｓｔ ｅｌｅｍｅｎｔを含めて送信する方法である。

当該情報を指示した要求メッセージを受信したＡＰはＭＬ ＩＥ情報を介してＳＴＡが要求しようとするＬｉｎｋの部分情報がわかり、当該情報をＲｅｓｐｏｎｓｅ ｆｒａｍｅ（ｅ．ｇ．Ｐｒｏｂｅ Ｒｅｓｐｏｎｓｅ ｆｒａｍｅ）に含めて送信する。ＳＴＡはＲｅｑｕｅｓｔ ｆｒａｍｅにＭＬ ＩＥ内Ｐｅｒ ＳＴＡ Ｐｒｏｆｉｌｅ（ｘ）内Ｐｅｒ－Ｃｏｎｔｒｏｌ ｆｉｅｌｄを介して要求したいＬｉｎｋ ＩＤと現在要求する情報が全部（Ｃｏｍｐｌｅｔｅ）であるか一部（Ｐａｒｔｉａｌ）であるか表示し、さらにＲｅｑｕｅｓｔ ｅｌｅｍｅｎｔ ｏｒ／ａｎｄ Ｅｘｔｅｎｄｅｄ Ｒｅｑｕｅｓｔ ｅｌｅｍｅｎｔを介して要求しようとする特定の情報を表示する方法である。図４２のようなｆｏｒｍａｔを使用してＳＴＡは各リンク別欲しい特定の情報を要求することができる。もしＲｅｑｕｅｓｔ ｅｌｅｍｅｎｔ ｏｒ／ａｎｄ Ｅｘｔｅｎｄｅｄ Ｒｅｑｕｅｓｔ ｅｌｅｍｅｎｔを省略する場合は当該ＡＰの全体情報（すなわち、ｃｏｍｐｌｅｔｅ情報）を要求することを意味する。但し、上記提案したようにＰｅｒ－ＳＴＡ Ｃｏｎｔｒｏｌ ｆｉｅｌｄ後、並べられたＥｌｅｍｅｎｔ情報は必要によって省略することができる。

図４２はＭＬ ＩＥフォーマットの一例を示す。

第２に、既存ＭＬ ＩＥ内Ｐｅｒ－ＳＴＡ Ｐｒｏｆｉｌｅ（ｘ）にＳＴＡが当該ＡＰに要求しようとする情報を指示するためのＲｅｑｕｅｓｔｅｄ ｅｌｅｍｅｎｔ ＩＤｓ／Ｒｅｑｕｅｓｔｅｄ ｅｌｅｍｅｎｔ ＩＤ ｅｘｔｅｎｓｉｏｎｓ ｆｉｅｌｄを含めて送信する方法である。当該フィールドは本明細書において提案するフィールドとして図４３で定義している。

図４３はＭＬ ＩＥフォーマットの他の例を示す。

当該情報を受信したＡＰはＭＬ ＩＥ情報を介してＳＴＡが要求しようとするＬｉｎｋの部分情報がわかり、当該情報をＲｅｓｐｏｎｓｅ ｆｒａｍｅ（ｅ．ｇ．Ｐｒｏｂｅ Ｒｅｓｐｏｎｓｅ ｆｒａｍｅ）に含めて送信する。ＳＴＡはＲｅｑｕｅｓｔ ｆｒａｍｅにＭＬ ＩＥ内Ｐｅｒ ＳＴＡ Ｐｒｏｆｉｌｅ（ｘ）内Ｐｅｒ－ＳＴＡ Ｃｏｎｔｒｏｌ ｆｉｅｌｄを介して要求したいＬｉｎｋ ＩＤと現在要求する情報がＣｏｍｐｌｅｔｅであるかＰａｒｔｉａｌであるか表示し、さらにＲｅｑｕｅｓｔｅｄ ｅｌｅｍｅｎｔ ＩＤｓ／Ｒｅｑｕｅｓｔｅｄ ｅｌｅｍｅｎｔ ＩＤ ｅｘｔｅｎｓｉｏｎｓ ｆｉｅｌｄを介して要求しようとする特定の情報を表示する方法である。Ｒｅｑｕｅｓｔｅｄ ｅｌｅｍｅｎｔ ＩＤｓ／Ｒｅｑｕｅｓｔｅｄ ｅｌｅｍｅｎｔ ＩＤ ｅｘｔｅｎｓｉｏｎｓ ｆｉｅｌｄを省略する場合は当該ＡＰの全体情報（すなわち、ａｌｌ ｅｌｅｍｅｎｔｓ情報）を要求することを意味する。当該ｆｏｒｍａｔの実施形態は以下の通りである。但し、上記提案したようにＰｅｒ－ＳＴＡ Ｃｏｎｔｒｏｌ ｆｉｅｌｄ後、並べられたＥｌｅｍｅｎｔ情報は必要によって省略することができる。

図４３のｆｏｒｍａｔは８０２．１１規格で定義するｅｌｅｍｅｎｔ指示情報をＲｅｑｕｅｓｔ ｅｌｅｍｅｎｔ ｏｒ／ａｎｄ Ｅｘｔｅｎｄｅｄ Ｒｅｑｕｅｓｔ ｅｌｅｍｅｎｔとして区分せず、１つの情報で送信することでｄｅｆａｕｌｔ ｆｉｅｌｄ ｏｖｅｒｈｅａｄ（ｅ．ｇ．ｅｌｅｍｅｎｔ ＩＤ、Ｌｅｎｇｔｈ）などを減らすことができるといった利点がある。

第３に、ＳＴＡが各ＡＰに要求しようとする情報を指示するためにＲｅｑｕｅｓｔ ｅｌｅｍｅｎｔ ｏｒ／ａｎｄ Ｅｘｔｅｎｄｅｄ Ｒｅｑｕｅｓｔ ｅｌｅｍｅｎｔを含めて送信することで、ＳＴＡが全てのＡＰに対して共通的に要求しようとするＣｏｍｍｏｎ ｉｎｆｏとＬｉｎｋ ｓｐｅｃｉｆｉｃ ｉｎｆｏを区分して要求するｆｏｒｍａｔである。前記フォーマットは図４４で定義している。

図４４はＭＬ ＩＥフォーマットの他の例を示す。

ＳＴＡがｒｅｑｕｅｓｔ ｆｒａｍｅ（ｅ．ｇ．Ｐｒｏｂｅ ｒｅｑｕｅｓｔ ｆｒａｍｅ）を介して各ＡＰの情報を要求する場合、一部の情報に対しては、同じく要求することができ他の一部の情報に対しては、各ＡＰ別に異なる情報を要求することもできる。これを指示するためのＦｏｒｍａｔを定義して実施形態を提案する。図４４のように、ＳＴＡがｒｅｑｕｅｓｔ ｆｒａｍｅを介して情報を要求するＡＰに対して要求する同じ情報を示すためのインジケーターはｒｅｑｕｅｓｔ Ｆｒａｍｅ内のＭＬ ＩＥとともにＲｅｑｕｅｓｔ ｏｒ／ａｎｄ Ｅｘｔｅｎｄｅｄ Ｒｅｑｕｅｓｔ ｅｌｅｍｅｎｔとして使用し、各ＡＰ別に要求する別の情報を示すためのインジケーターはＰｅｒ－ＳＴＡ Ｐｒｏｆｉｌｅ（ｘ）内にＲｅｑｕｅｓｔ ｏｒ／ａｎｄ Ｅｘｔｅｎｄｅｄ Ｅｌｅｍｅｎｔを使用する。但し、上記提案したようにＰｅｒ－ＳＴＡ Ｃｏｎｔｒｏｌ ｆｉｅｌｄ後、並べられたＥｌｅｍｅｎｔ情報は必要によって省略することができる。

例えば、ＳＴＡがＰｒｏｂｅ ｒｅｑｕｅｓｔ ｆｒａｍｅにＴＩＭ ｅｌｅｍｅｎｔに該当する情報（ｅ．ｇ．Ｅｌｅｍｅｎｔ５＝１１）をＲｅｑｕｅｓｔ ｅｌｅｍｅｎｔで表示し、ＭＬ ＩＥ内Ｐｅｒ－ＳＴＡ Ｐｒｏｆｉｌｅ（ｘ）のＰｅｒ－ＳＴＡ ＣｏｎｔｒｏｌにＬｉｎｋ ＩＤ＝１、Ｃｏｍｐｌｅｔｅ Ｐｒｏｆｉｌｅ＝０（逆に値が１である場合は、ａｌｌ ｅｌｅｍｅｎｔｓ情報の要求を意味）に指示し、Ｒｅｑｕｅｓｔ ｅｌｅｍｅｎｔにＢＳＳ ｌｏａｄ ｅｌｅｍｅｎｔに該当する情報（ｅ．ｇ．Ｅｌｅｍｅｎｔ ＩＤ＝１１）を表示し、Ｐｅｒ－ＳＴＡ Ｐｒｏｆｉｌｅ（ｙ）のＰｅｒ－ＳＴＡ ＣｏｎｔｒｏｌにＬｉｎｋ ＩＤ＝２、Ｃｏｍｐｌｅｔｅ Ｐｒｏｆｉｌｅ＝０に指示し、Ｅｘｔｅｎｄｅｄ Ｒｅｑｕｅｓｔ ｅｌｅｍｅｎｔにｎｏｎ－ｉｎｈｅｒｉｔａｎｃｅ ｅｌｅｍｅｎｔに該当する情報（ｅ．ｇ．Ｅｌｅｍｅｎｔ ＩＤ＝２５５、Ｅｌｅｍｅｎｔ ＩＤｅｘｔｅｎｓｉｏｎ＝５６）を表示して送信する場合にＡＰは次のような情報を含めてＰｒｏｂｅ Ｒｅｓｐｏｎｓｅ ｆｒａｍｅを応答する。

－Ｌｉｎｋ１、Ｌｉｎｋ２に対するＴＩＭ ｅｌｅｍｅｎｔ情報

－Ｌｉｎｋ１に対するＢＳＳ ｌｏａｄ ｅｌｅｍｅｎｔ情報

－Ｌｉｎｋ２に対するｎｏｎ－ｉｎｈｅｒｉｔａｎｃｅ ｅｌｅｍｅｎｔ情報

ＳＴＡはＦｒａｍｅ内ｅｌｅｍｅｎｔ階層にしたがって要求する情報をＣｏｍｍｏｎ又はＬｉｎｋ ｓｐｅｃｉｆｉｃで区分することで、リンク別他の情報を要求することができる。

このように、８０２．１１ｂｅではＭＬ Ｐｒｏｂｅ ｒｅｑｕｅｓｔ ｆｒａｍｅに対しても、ｉｎｈｅｒｉｔａｎｃｅ ｍｏｄｅｌを適用させることができる。上記説明したように、ＳＴＡがＭＬ Ｐｒｏｂｅ ｒｅｑｕｅｓｔ中に（Ｅｘｔｅｎｄｅｄ）Ｒｅｑｕｅｓｔ ｅｌｅｍｅｎｔを含めて送信する場合、このような部分情報の要求はｐｅｅｒ ＡＰだけでなくＭＬ ＩＥ（ｉ．ｅ．Ｐｒｏｂｅ ｒｅｑｕｅｓｔ ｖａｒｉａｎｔ Ｍｕｌｔｉ－Ｌｉｎｋ ｅｌｅｍｅｎｔ）を介して要求されたＡＰにもｉｎｈｅｒｉｔａｎｃｅ ｍｏｄｅｌが適用され全てのＡＰに対する共通情報の要求でｐｅｅｒ ＡＰは受け入れる。したがって、ＳＴＡから図４４のようにＭＬ ＩＥの外に（Ｅｘｔｅｎｄｅｄ）Ｒｅｑｕｅｓｔ ｅｌｅｍｅｎｔを含めたＰｒｏｂｅ ｒｅｑｕｅｓｔ ｆｒａｍｅを受信した場合、ｐｅｅｒ ＡＰとｒｅｑｕｅｓｔｅｄ ＡＰｓ（ｉ．ｅ．ＭＬ ＩＥ内Ｏｔｈｅｒ ＡＰ情報の要求のために指示されたＡＰ）に対する共通する情報の要求で解析して、ＭＬ Ｐｒｏｂｅ Ｒｅｓｐｏｎｓｅに（Ｅｘｔｅｎｄｅｄ）Ｒｅｑｕｅｓｔ ｅｌｅｍｅｎｔに指示された要求された情報を確認してＭＬ ＩＥ（ｉ．ｅ．ｂａｓｉｃ ｖａｒｉａｎｔ Ｍｕｌｔｉ－Ｌｉｎｋ ｅｌｅｍｅｎｔ）の中の各ＡＰに該当する情報をＰｅｒ－ＳＴＡ Ｐｒｏｆｉｌｅの中に含めて応答できる。

第４に、ＳＴＡが各ＡＰに要求しようとする情報を指示するためにＭｕｌｔｉ－ｌｉｎｋ ｅｌｅｍｅｎｔの中にＲｅｑｕｅｓｔ ｅｌｅｍｅｎｔ ｏｒ／ａｎｄ Ｅｘｔｅｎｄｅｄ Ｒｅｑｕｅｓｔ ｅｌｅｍｅｎｔを含めて送信することで、ＳＴＡが全てのＡＰに対して共通的に要求しようとするＣｏｍｍｏｎ ｉｎｆｏとＬｉｎｋ ｓｐｅｃｉｆｉｃ ｉｎｆｏを区分して要求するｆｏｒｍａｔである。前記フォーマットは図４５で定義している。

図４５はＭＬ ＩＥフォーマットの他の例を示す。

ＳＴＡがｒｅｑｕｅｓｔ ｆｒａｍｅ（ｅ．ｇ．Ｐｒｏｂｅ ｒｅｑｕｅｓｔ ｆｒａｍｅ）を介して各ＡＰの情報を要求する場合、一部の情報に対しては同じく要求することができ他の一部の情報に対しては各ＡＰ別に異なる情報を要求することもできる。これを指示するためのＦｏｒｍａｔを定義して実施形態を提案 する。もしＲｅｑｕｅｓｔ ｆｒａｍｅ（ｅ．ｇ．Ｐｒｏｂｅ ｒｅｑｕｅｓｔ）内Ｍｕｌｔｉ－ｌｉｎｋ ｅｌｅｍｅｎｔとともにＲｅｑｕｅｓｔ ｏｒ／ａｎｄ Ｅｘｔｅｎｄｅｄ Ｒｅｑｕｅｓｔ ｅｌｅｍｅｎｔが含まれる場合、これはＳＴＡが自身が接続されているＬｉｎｋ（すなわち、ａｓｓｏｃｉａｔｅｄ ＡＰ）に対して部分情報を要求することを意味する。もしＳＴＡが接続されたＡＰ ＭＬＤのＡＰのうち、自身のリンクではないＡＰの情報を要求する場合、これに対する指示情報はＭＬ ＩＥ（ｍｕｌｔｉ－ｌｉｎｋ ｅｌｅｍｅｎｔ）に含む。したがって上記のようにＭＬ ＩＥ内にＰｅｒ－ＳＴＡ Ｐｒｏｆｉｌｅ（ｘ）ｅｌｅｍｅｎｔ以前にＲｅｑｕｅｓｔ ｏｒ／ａｎｄ Ｅｘｔｅｎｄｅｄ Ｒｅｑｕｅｓｔ ｅｌｅｍｅｎｔを含む場合、当該要素を介してＳＴＡが要求するＡＰ ＭＬＤのＯｔｈｅｒ ＡＰ（ＳＴＡが接続されたＡＰ ＭＬＤが含むＡＰのうち、自身のリンクに該当されないＡＰ）に対して共通的に要求する情報を指示することができる。Ｏｔｈｅｒ ＡＰに対して共通的に要求する情報はＭＬ ＩＥ内Ｒｅｑｕｅｓｔ ｏｒ／ａｎｄ Ｅｘｔｅｎｄｅｄ Ｒｅｑｕｅｓｔ ｅｌｅｍｅｎｔを介して指示し、Ｏｔｈｅｒ ＡＰ毎にそれぞれ異なる要求をする情報はＰｅｒ－ＳＴＡ Ｐｒｏｆｉｌｅ（ｘ）内Ｐｅｒ－ＳＴＡ Ｃｏｎｔｒｏｌ ｆｉｅｌｄの後にＲｅｑｕｅｓｔ ｏｒ／ａｎｄ Ｅｘｔｅｎｄｅｄ Ｒｅｑｕｅｓｔ ｅｌｅｍｅｎｔを考慮した指示することができる。このとき、もしＭＬ ＩＥ内にＰｅｒ－ＳＴＡ Ｐｒｏｆｉｌｅ（ｘ）にＯｔｈｅｒ ＡＰではない自身のリンクに該当するＡＰのインジケーターを含む場合はＭＬ ＩＥを介してＳＴＡが自身のリンクに該当するＡＰの情報も得ることができる。この場合、自身のリンクに該当するＡＰの部分情報を要求するためにＭＬ ＩＥとともに含んだＲｅｑｕｅｓｔ ｏｒ／ａｎｄ Ｅｘｔｅｎｄｅｄ Ｒｅｑｕｅｓｔ ｅｌｅｍｅｎｔは省略することができる。

但し、上記提案したようにＰｅｒ－ＳＴＡ Ｃｏｎｔｒｏｌ ｆｉｅｌｄ後、並べられたＥｌｅｍｅｎｔ情報は必要によって省略することができる。

第５に、ＳＴＡはＭＬＤ Ｐｒｏｂｅ ｒｅｑｕｅｓｔを介してＰｅｅｒ ＡＰ（すなわち、ｔｒａｎｓｍｉｔｔｉｎｇ ｌｉｎｋ）とＯｔｈｅｒ ＡＰｓ（すなわち、Ｏｔｈｅｒ ｌｉｎｋ）に対して一部全体情報又は一部部分情報を要求することができる。これに関連した複数のケースと実施形態は以下の通りである。

１）Ｐｅｅｒ ＡＰに対して全体情報を要求してＯｔｈｅｒ ＡＰに対して全体情報を要求する場合

ＥＨＴ ｎｏｎ－ＡＰ ＳＴＡは１つのＰｒｏｂｅ ｒｅｑｕｅｓｔ ｆｒａｍｅでＰｅｅｒ ＡＰとＯｔｈｅｒ ＡＰに対して全体情報を要求するメッセージ送信が可能である。

図４６はＭＬ ＩＥフォーマットを含むＰｒｏｂｅ ｒｅｑｕｅｓｔ ｆｒａｍｅの一例を示す。

図４６を参照すれば、Ｐｅｅｒ ＡＰに対して全体情報を要求する場合、Ｃｏｒｅ ｏｆ Ｐｒｏｂｅ ｒｅｑｕｅｓｔ ｆｒａｍｅ（Ｐｒｏｂｅ ｒｅｑｕｅｓｔ ｆｒａｍｅのｆｒａｍｅ ｂｏｄｙ）に（Ｅｘｔｅｎｄｅｄ）Ｒｅｑｕｅｓｔ ｅｌｅｍｅｎｔを含めず、Ｍｕｌｔｉ－Ｌｉｎｋ ｅｌｅｍｅｎｔ（すなわち、Ｐｒｏｂｅ ｒｅｑｕｅｓｔ ｖａｒｉａｎｔ Ｍｕｌｔｉ－Ｌｉｎｋ ｅｌｅｍｅｎｔ）のＰｅｒ－ＳＴＡ Ｐｒｏｆｉｌｅの中にある「Ｐｅｒ－ＳＴＡ Ｃｏｎｔｒｏｌ」ｆｉｅｌｄの中のＣｏｍｐｌｅｔｅ Ｐｒｏｆｉｌｅ ｓｕｂｆｉｅｌｄを１に設定してＯｔｈｅｒ ＡＰに対する全体情報の要求を指示する。

２）Ｐｅｅｒ ＡＰに対して全体情報を要求してＯｔｈｅｒ ＡＰに対して全体又は部分情報を要求する場合

２）Ｐｅｅｒ ＡＰに対して全体情報を要求してＯｔｈｅｒ ＡＰに対して全体又は部分情報を要求する場合

ＥＨＴ ｎｏｎ－ＡＰ ＳＴＡは１つのＰｒｏｂｅ ｒｅｑｕｅｓｔ ｆｒａｍｅでＰｅｅｒ ＡＰに対して全体情報を要求してＭＬ ＩＥを介して指示されたＯｔｈｅｒ ＡＰに対して全体又は部分情報を要求するメッセージ送信が可能である。

図４７はＭＬ ＩＥフォーマットを含むＰｒｏｂｅ ｒｅｑｕｅｓｔ ｆｒａｍｅの他の例を示す。

図４７を参照すれば、Ｐｅｅｒ ＡＰに対して全体情報を要求する場合、Ｃｏｒｅ ｏｆ Ｐｒｏｂｅ ｒｅｑｕｅｓｔ ｆｒａｍｅに（Ｅｘｔｅｎｄｅｄ）Ｒｅｑｕｅｓｔ ｅｌｅｍｅｎｔを含めず、Ｏｔｈｅｒ ＡＰに対して部分情報を要求する場合は、Ｍｕｌｔｉ－Ｌｉｎｋ ｅｌｅｍｅｎｔ（すなわち、Ｐｒｏｂｅ ｒｅｑｕｅｓｔ ｖａｒｉａｎｔ Ｍｕｌｔｉ－Ｌｉｎｋ ｅｌｅｍｅｎｔ）のＰｅｒ－ＳＴＡ Ｐｒｏｆｉｌｅの中に（Ｅｘｔｅｎｄｅｄ）Ｒｅｑｕｅｓｔ ｅｌｅｍｅｎｔを含め「Ｐｅｒ－ＳＴＡ Ｃｏｎｔｒｏｌ」ｆｉｅｌｄの中の「Ｃｏｍｐｌｅｔｅ Ｐｒｏｆｉｌｅ」ｓｕｂｆｉｅｌｄを０に設定してＯｔｈｅｒ ＡＰに対する部分情報の要求を指示する。このとき、もし他のＯｔｈｅｒ ＡＰに対して全体情報を要求したい場合は、Ｐｅｒ－ＳＴＡ Ｐｒｏｆｉｌｅの中に（Ｅｘｔｅｎｄｅｄ）Ｒｅｑｕｅｓｔ ｅｌｅｍｅｎｔなしに「Ｐｅｒ－ＳＴＡ Ｃｏｎｔｒｏｌ」ｆｉｅｌｄの中の「Ｃｏｍｐｌｅｔｅ Ｐｒｏｆｉｌｅ」ｓｕｂｆｉｅｌｄを１に設定する。このように、Ｏｔｈｅｒ ＡＰに対しても各ＡＰ別に全体情報の要求又は部分情報の要求が１つのＰｒｏｂｅ ｒｅｑｕｅｓｔ ｆｒａｍｅで可能である。

３）Ｐｅｅｒ ＡＰに対して部分情報を要求してＯｔｈｅｒ ＡＰに対して全体又は部分情報を要求する場合

ＥＨＴ ｎｏｎ－ＡＰ ＳＴＡは１つのＰｒｏｂｅ ｒｅｑｕｅｓｔ ｆｒａｍｅでＰｅｅｒ ＡＰに対して部分情報を要求してＭｕｌｔｉ－Ｌｉｎｋ ｅｌｅｍｅｎｔを介して指示されたＯｔｈｅｒ ＡＰに対して全体又は部分情報の要求が可能である。

図４８はＭＬ ＩＥフォーマットを含むＰｒｏｂｅ ｒｅｑｕｅｓｔ ｆｒａｍｅの他の例を示す。

図４８を参照すれば、Ｐｅｅｒ ＡＰに対して部分情報を要求する場合、Ｃｏｒｅ ｏｆ Ｐｒｏｂｅ ｒｅｑｕｅｓｔ ｆｒａｍｅに（Ｅｘｔｅｎｄｅｄ）Ｒｅｑｕｅｓｔ ｅｌｅｍｅｎｔを含め、Ｏｔｈｅｒ ＡＰに対して全体情報を要求する場合は、Ｍｕｌｔｉ－Ｌｉｎｋ ｅｌｅｍｅｎｔ（すなわち、Ｐｒｏｂｅ ｒｅｑｕｅｓｔ ｖａｒｉａｎｔ Ｍｕｌｔｉ－Ｌｉｎｋ ｅｌｅｍｅｎｔ）のＰｅｒ－ＳＴＡ Ｐｒｏｆｉｌｅの中に（Ｅｘｔｅｎｄｅｄ）Ｒｅｑｕｅｓｔ ｅｌｅｍｅｎｔなしに「Ｐｅｒ－ＳＴＡ Ｃｏｎｔｒｏｌ」ｆｉｅｌｄの中の「Ｃｏｍｐｌｅｔｅ Ｐｒｏｆｉｌｅ」ｓｕｂｆｉｅｌｄを１に設定してＯｔｈｅｒ ＡＰに対する全体情報の要求を指示することができる。

このとき、もし他のＯｔｈｅｒ ＡＰに対して部分情報を要求したい場合は、Ｐｅｒ－ＳＴＡ Ｐｒｏｆｉｌｅの中に（Ｅｘｔｅｎｄｅｄ）Ｒｅｑｕｅｓｔ ｅｌｅｍｅｎｔを含め「Ｐｅｒ－ＳＴＡ Ｃｏｎｔｒｏｌ」ｆｉｅｌｄの中の「Ｃｏｍｐｌｅｔｅ Ｐｒｏｆｉｌｅ」ｓｕｂｆｉｅｌｄを０に設定する。このとき、もしＭＬＤ Ｐｒｏｂｅ ｒｅｑｕｅｓｔに対してｉｎｈｅｒｉｔａｎｃｅ ｍｏｄｅｌを適用する場合、Ｐｅｅｒ ＡＰとＰｅｒ－ＳＴＡ Ｐｒｏｆｉｌｅ（ｘ）に指示されたＡＰ（ｘ）（すなわち、Ｌｉｎｋ）に要求した部分情報に対して同じ情報である場合、Ｐｅｒ－ＳＴＡ Ｐｒｏｆｉｌｅ（ｘ）の中の（Ｅｘｔｅｎｄｅｄ）Ｒｅｑｕｅｓｔ ｅｌｅｍｅｎｔは省略することができる。すなわち、Ｃｏｒｅ ｏｆ Ｐｒｏｂｅ ｒｅｑｕｅｓｔ ｆｒａｍｅに含まれた（Ｅｘｔｅｎｄｅｄ）Ｒｅｑｕｅｓｔ ｅｌｅｍｅｎｔに対してｎｏｎ－ｉｎｈｅｒｉｔａｎｃｅ ｅｌｅｍｅｎｔに該当する場合にのみ、Ｐｅｒ－ＳＴＡ Ｐｒｏｆｉｌｅ（ｘ）の中に（Ｅｘｔｅｎｄｅｄ）Ｒｅｑｕｅｓｔ ｅｌｅｍｅｎｔが含まれ、そのではない場合は省略することができる。

ＭＬＤ Ｐｒｏｂｅ ｒｅｑｕｅｓｔに対してｉｎｈｅｒｉｔａｎｃｅ ｍｏｄｅｌを適用する時、実施形態は図４９の通りである。

図４９はＭＬ ＩＥフォーマットを含むＰｒｏｂｅ ｒｅｑｕｅｓｔ ｆｒａｍｅの他の例を示す。

図４９を参照すれば、ＥＨＴ ｎｏｎ－ＡＰ ＳＴＡがＭＬＤ Ｐｒｏｂｅ ｒｅｑｕｅｓｔを介してＰｅｅｒ ＡＰに対して部分情報を要求する場合、Ｃｏｒｅ ｏｆ Ｐｒｏｂｅ ｒｅｑｕｅｓｔ ｆｒａｍｅに（Ｅｘｔｅｎｄｅｄ）Ｒｅｑｕｅｓｔ ｅｌｅｍｅｎｔを含める。このとき、Ｍｕｌｔｉ－Ｌｉｎｋ ｅｌｅｍｅｎｔに指示されたＡＰのうち、一部のＡＰ（すなわち、Ｐｅｒ－ＳＴＡ Ｐｒｏｆｉｌｅ（ｘ））に対してＰｅｅｒ ＡＰと別の部分情報を要求する場合は、Ｐｅｒ－ＳＴＡ Ｐｒｏｆｉｌｅ（ｘ）の中にｎｏｎ－ｉｎｈｅｒｉｔａｎｃｅ ｅｌｅｍｅｎｔに該当する（Ｅｘｔｅｎｄｅｄ）Ｒｅｑｕｅｓｔ ｅｌｅｍｅｎｔを含め別の情報を要求することができる。このとき、Ｐｅｒ－ＳＴＡ Ｃｏｎｔｒｏｌ ｆｉｅｌｄのＣｏｍｐｌｅｔｅ Ｐｒｏｆｉｌｅの値は０に設定する。

又は、Ｍｕｌｔｉ－Ｌｉｎｋ ｅｌｅｍｅｎｔに指示されたＡＰのうち、一部のＡＰ（すなわち、Ｐｅｒ－ＳＴＡ Ｐｒｏｆｉｌｅ（ｙ））に対してＰｅｅｒ ＡＰと同じ部分情報を要求する場合は、Ｐｅｒ－ＳＴＡ Ｐｒｏｆｉｌｅ（ｙ）の中に（Ｅｘｔｅｎｄｅｄ）Ｒｅｑｕｅｓｔ ｅｌｅｍｅｎｔを省略する。このとき、Ｐｅｒ－ＳＴＡ Ｃｏｎｔｒｏｌ ｆｉｅｌｄのＣｏｍｐｌｅｔｅ Ｐｒｏｆｉｌｅの値は０に設定する。このようにＭＬＤ Ｐｒｏｂｅ ｒｅｑｕｅｓｔにｉｎｈｅｒｉｔａｎｃｅ ｍｏｄｅｌを適用させる場合は、もしＥＨＴ ｎｏｎ－ＡＰ ＳＴＡがＰｅｅｒ ＡＰにＥｌｅｍｅｎｔ（ａ）、Ｅｌｅｍｅｎｔ（ｂ）を要求してＰｅｒ－ＳＴＡ Ｐｒｏｆｉｌｅ（ｘ）に指示したＡＰ（ｘ）にＥｌｅｍｅｎｔ（ａ）、Ｅｌｅｍｅｎｔ（ｃ）を要求した場合は、Ｐｅｅｒ ＡＰとＡＰ（ｘ）に同じく要求する情報（ｅ．ｇ．Ｅｌｅｍｅｎｔ（ａ））があるが、別の情報（ｅ．ｇ．Ｅｌｅｍｅｎｔ（ｃ））も含むためそれをＡＰが区分するためにＰｅｒ－ＳＴＡ Ｐｒｏｆｉｌｅ（ｘ）の中にＥｌｅｍｅｎｔ（ａ）、Ｅｌｅｍｅｎｔ（ｃ）に対する情報の要求を指示する（Ｅｘｔｅｎｄｅｄ）Ｒｅｑｕｅｓｔ ｅｌｅｍｅｎｔを含める必要がある。（Ｉｎｈｅｒｉｔａｎｃｅ ｍｏｄｅｌを適用する時、ＡＰはＰｅｒ－ＳＴＡ Ｐｒｏｆｉｌｅ（ｘ）の中に（Ｅｘｔｅｎｄｅｄ）Ｒｅｑｕｅｓｔ ｅｌｅｍｅｎｔがある場合、Ｐｅｅｒ ＡＰと重複して要求する部分情報があるとしてもこれをｎｏｎ－ｉｎｈｅｒｉｔａｎｃｅ ｅｌｅｍｅｎｔとして認識するためＰｅｅｒ ＡＰと同じ部分情報を要求する場合ではなければＰｅｒ－ＳＴＡ Ｐｒｏｆｉｌｅ（ｘ）の中に含まれる（Ｅｘｔｅｎｄｅｄ）Ｒｅｑｕｅｓｔ ｅｌｅｍｅｎｔの中にはＰｅｅｒ ＡＰに対して要求する部分情報と関係なしにＰｅｒ－ＳＴＡ Ｐｒｏｆｉｌｅ（ｘ）を介して指示するＡＰ（ｅ．ｇ．ＡＰ（ｘ））に要求する全てのＥｌｅｍｅｎｔ情報を指示する必要がある）。但し、もしＥＨＴ ｎｏｎ－ＡＰ ＳＴＡがＰｅｅｒ ＡＰにＥｌｅｍｅｎｔ（ａ）、Ｅｌｅｍｅｎｔ（ｂ）を要求してＰｅｒ－ＳＴＡ Ｐｒｏｆｉｌｅ（ｘ）に指示したＡＰ（ｘ）に同じＥｌｅｍｅｎｔ（ａ）、Ｅｌｅｍｅｎｔ（ｂ）を要求した場合は、Ｐｅｅｒ ＡＰとＡＰ（ｘ）に要求する情報が全て同じであるためｉｎｈｅｒｉｔａｎｃｅ ｍｏｄｅｌを適用してＰｅｒ－ＳＴＡ Ｐｒｏｆｉｌｅ（ｘ）の中に「Ｃｏｍｐｌｅｔｅ Ｐｒｏｆｉｌｅ」ｓｕｂｆｉｅｌｄを０に設定してＥｌｅｍｅｎｔ（ａ）、Ｅｌｅｍｅｎｔ（ｂ）に対する情報の要求を指示する（Ｅｘｔｅｎｄｅｄ）Ｒｅｑｕｅｓｔ ｅｌｅｍｅｎｔを省略することができる。

この場合、Ｐｅｒ－ＳＴＡ Ｃｏｎｔｒｏｌ ｆｉｅｌｄのＣｏｍｐｌｅｔｅ Ｐｒｏｆｉｌｅの値を１に設定する場合は、Ｐｅｅｒ ＡＰの要求情報に対してｉｎｈｅｒｉｔａｎｃｅ ｍｏｄｅｌが適用されることではなくＡＰ（ｙ）に対する全体情報の要求を意味する。すなわち、Ｐｅｅｒ ＡＰに対する部分情報の要求内容をＭｕｌｔｉ－Ｌｉｎｋ ｅｌｅｍｅｎｔにｉｎｈｅｒｉｔａｎｃｅ ｍｏｄｅｌを適用するためにはＰｅｒ－ＳＴＡ Ｃｏｎｔｒｏｌ ｆｉｅｌｄのＣｏｍｐｌｅｔｅ Ｐｒｏｆｉｌｅの値は０に設定する必要がある。

ＳＴＡはＦｒａｍｅ内ｅｌｅｍｅｎｔの配置によって要求する情報をＣｏｍｍｏｎ又はＬｉｎｋ ｓｐｅｃｉｆｉｃで区分することで、リンク別他の情報を要求することができる。

このために、さらに、Ｍｕｌｔｉ－Ｌｉｎｋ Ｃｏｎｔｒｏｌ ｆｉｅｌｄに当該ＭＬ ＩＥが要求する情報がＣｏｍｍｏｎ情報を区分するかを示すための新規フィールドを提案する。上記のように、ＳＴＡはＲｅｑｕｅｓｔ ｅｌｅｍｅｎｔ ｏｒ／ａｎｄ Ｅｘｔｅｎｄｅｄ Ｒｅｑｕｅｓｔ ｅｌｅｍｅｎｔの配置によって当該リンクに対するＣｏｍｍｏｎ情報を示すことができる。これは、Ｃｏｍｍｏｎ情報の要求可否にしたがってｒｅｑｕｅｓｔ ｆｒａｍｅにＭＬ ＩＥ内ｐｅｒ－ＳＴＡ Ｐｒｏｆｉｌｅ（ｘ）が前にＲｅｑｕｅｓｔ ｅｌｅｍｅｎｔ ｏｒ／ａｎｄ Ｅｘｔｅｎｄｅｄ Ｒｅｑｕｅｓｔ ｅｌｅｍｅｎｔが存在する場合がある。したがってこれを示すためのＣｏｎｔｒｏｌ ｆｉｅｌｄを図５０のように提案する。

図５０はＭｕｌｔｉ－ｌｉｎｋ Ｃｏｎｔｒｏｌ ｆｉｅｌｄフォーマットの一例を示す。

図５０のｆｉｅｌｄは「Ｃｏｍｍｏｎ ｉｎｆｏ Ｐｒｅｓｅｎｔ」ｆｉｅｌｄのように定義することができ、当該名称は以降、他の名称で定義される。前記ｆｉｅｌｄが１に指示された場合、ＳＴＡはＡＰ ＭＬＤにＯｔｈｅｒ ＡＰに対する情報を要求する時、同じ情報の要求を意味するＲｅｑｕｅｓｔ ｅｌｅｍｅｎｔ ｏｒ／ａｎｄ Ｅｘｔｅｎｄｅｄ Ｒｅｑｕｅｓｔ ｅｌｅｍｅｎｔをＰｅｒ－ＳＴＡ Ｐｒｏｆｉｌｅ（ｘ）要素以前に含め送信する。そして各ＡＰ別異なる要求をするＬｉｎｋ ｓｐｅｃｉｆｉｃ情報に対してはＰｅｒ－ＳＴＡ Ｐｒｏｆｉｌｅ（ｘ）要素の中に含まれたＲｅｑｕｅｓｔ ｅｌｅｍｅｎｔ ｏｒ／ａｎｄ Ｅｘｔｅｎｄｅｄ Ｒｅｑｕｅｓｔ ｅｌｅｍｅｎｔを介して指示する。前記ｆｉｅｌｄが０で指示された場合はＳＴＡがＯｔｈｅｒ ＡＰに対して同じく要求する情報がないということを意味し、Ｐｅｒ－ＳＴＡ Ｐｒｏｆｉｌｅ（ｘ）要素以前に別途のＲｅｑｕｅｓｔ ｅｌｅｍｅｎｔ ｏｒ／ａｎｄ Ｅｘｔｅｎｄｅｄ Ｒｅｑｕｅｓｔ ｅｌｅｍｅｎｔが存在しないことを意味する。

これに対する実施形態は以下の通りである。

ＳＴＡはＡＰ ＭＬＤのＡＰにＣｒｉｔｉｃａｌ ｕｐｄａｔｅ情報に対してのみ部分要求をすることもできる。このために２つのオプションを提案する。このとき、ＡＰはＳＴＡがＢｅａｃｏｎを介して獲得できる全てのＡＰ（ｒｅｐｏｒｔｉｎｇ ＡＰ及びｒｅｐｏｒｔｅｄ ＡＰ）が該当される。Ｒｅｐｏｒｔｅｄ ＡＰはＳＴＡがＢｅａｃｏｎのＲＮＲ ｅｌｅｍｅｎｔを介して獲得できるＯｔｈｅｒ ＡＰを意味し、ｒｅｐｏｒｔｉｎｇ ＡＰと同じＡＰ ＭＬＤ内のＯｔｈｅｒ ＡＰだけでなく、ＴｘＢＳＳ ＩＤグループに該当するＯｔｈｅｒ ＡＰ、ｎｏｎ－ＴｘＢＳＳ ＩＤグループに該当するＯｔｈｅｒ ＡＰなどがある。つまり、ＳＴＡはＢｅａｃｏｎを介してＣＳＮ（Ｃｈａｎｇｅ Ｓｅｑｕｅｎｃｅ Ｎｕｍｂｅｒ）情報を獲得できる全てのＯｔｈｅｒ ＡＰに対してＣｒｉｔｉｃａｌ ｕｐｄａｔｅ情報を要求することができる（参考に、８０２．１１ｂｅでは、Ｂｅａｃｏｎ ｆｒａｍｅのＲＮＲ ｅｌｅｍｅｎｔにＯｔｈｅｒ ＡＰのＣｈａｎｇｅ Ｓｅｑｕｅｎｃｅ ｆｉｅｌｄ情報を含めることを同意した）。

１つ目の、Ｏｔｈｅｒ ＡＰのＣｒｉｔｉｃａｌ ｕｐｄａｔｅ情報の要求のための「Ｃｒｉｔｉｃａｌ ｕｐｄａｔｅ ｒｅｑｕｅｓｔ」ｆｉｅｌｄを新規として定義する方法である。

－「Ｃｒｉｔｉｃａｌ ｕｐｄａｔｅ ｒｅｑｕｅｓｔ」ｆｉｅｌｄ：ＡＰのＣｒｉｔｉｃａｌ ｕｐｄａｔｅとして定義されたシステム情報のみを要求するフィールド。リンクインジケーターとともに使用され特定のリンクのＣｒｉｔｉｃａｌ ｕｐｄａｔｅとして定義されたシステム情報を要求する時、使用することができる。

ＳＴＡがＡＰ ＭＬＤのＯｔｈｅｒ ＡＰの情報を要求するとき、Ｒｅｑｕｅｓｔ ｆｒａｍｅ（ｅ．ｇ．Ｐｒｏｂｅ ｒｅｑｕｅｓｔ ｆｒａｍｅ）にリンクインジケーター情報とともに当該フィールドの値を１に設定して送信すればこれを受信したＡＰは指示されたリンクに対するＣｒｉｔｉｃａｌ ｕｐｄａｔｅ情報をＲｅｓｐｏｎｓｅ ｆｒａｍｅに含めて応答する。このとき、Ｃｒｉｔｉｃａｌ ｕｐｄａｔｅ情報は既存８０２．１１規格のＳｙｓｔｅｍ ｉｎｆｏｒｍａｔｉｏｎ ｕｐｄａｔｅ ｐｒｏｃｅｄｕｒｅにおいて、Ｃｒｉｔｉｃａｌ ｕｐｄａｔｅとして定義する複数のシステム情報（ａ）Ｉｎｃｌｕｓｉｏｎ ｏｆ ａｎ Ｅｘｔｅｎｄｅｄ Ｃｈａｎｎｅｌ Ｓｗｉｔｃｈ Ａｎｎｏｕｎｃｅｍｅｎｔ、ｂ）Ｍｏｄｉｆｉｃａｔｉｏｎ ｏｆ ｔｈｅ ＥＤＣＡ ｐａｒａｍｅｔｅｒｓ、ｃ）Ｍｏｄｉｆｉｃａｔｉｏｎ ｏｆ ｔｈｅ Ｓ１Ｇ Ｏｐｅｒａｔｉｏｎ ｅｌｅｍｅｎｔ）を意味する。但し、以降８０２．１１ｂｅの場合、Ｃｒｉｔｉｃａｌ ｕｐｄａｔｅに対して既に定義されたｓｙｓｔｅｍ情報以外に新規情報を追加定義することができ、本明細書では言及するＣｒｉｔｉｃａｌ ｕｐｄａｔｅ情報は８０２．１１ｂｅにおいて新規定義したＣｒｉｔｉｃａｌ ｕｐｄａｔｅ情報を含んだ情報を意味する。もし当該フィールドの値を０に設定して送信すれば、ＡＰは既存動作のままＲｅｓｐｏｎｓｅ ｆｒａｍｅを応答する。提案するフィールドはＲｅｑｕｅｓｔ Ｆｒａｍｅ内あるｅｌｅｍｅｎｔに含めることができ、上記言及したＭＬＤ Ｒｅｑｕｅｓｔ ｅｌｅｍｅｎｔ又はＭＬ ＩＥに含めて使用される。これに対する実施形態は図５１の通りである。

図５１はＭＬ ＩＥフォーマットにＣｒｉｔｉｃａｌ ｕｐｄａｔｅ ｒｅｑｕｅｓｔ ｆｉｅｌｄが含まれる一例を示す。

図５１を参照すれば、ＳＴＡがＰｒｏｂｅ ｒｅｑｕｅｓｔ内ＭＬ ＩＥで特定のリンクに対する情報を要求する場合、Ｐｅｒ－ＳＴＡ Ｐｒｏｆｉｌｅ（ｘ）を介して特定のリンクに該当する情報を要求することができる。このとき、Ｐｅｒ－ＳＴＡ Ｐｒｏｆｉｌｅ（ｘ）内Ｐｅｒ－ＳＴＡ Ｃｏｎｔｒｏｌに新規定義した「Ｃｒｉｔｉｃａｌ ｕｐｄａｔｅ ｒｅｑｕｅｓｔ」ｆｉｅｌｄを含めて１に設定して送信する場合、ＡＰはＰｅｒ－ＳＴＡ Ｐｒｏｆｉｌｅ（ｘ）において指示するリンクに対してＣｒｉｔｉｃａｌ ｕｐｄａｔｅとして定義した現在ｓｙｓｔｅｍ情報を含んだＲｅｓｐｏｎｓｅ ｆｒａｍｅを応答する。このとき、ｎｏｎ－ＡＰ ＭＬＤのｎｏｎ－ＡＰ ＳＴＡはＭＬＤ Ｐｒｏｂｅ ｒｅｑｕｅｓｔを介してＣｒｉｔｉｃａｌ ｕｐｄａｔｅ情報を要求するために「Ｃｒｉｔｉｃａｌ ｕｐｄａｔｅ ｒｅｑｕｅｓｔ」ｆｉｅｌｄの値を１に設定して送信するとき、ｎｏｎ－ＡＰ ＭＬＤの各ｎｏｎ－ＡＰ ＳＴＡに対するＣＳＮ（Ｃｈａｎｇｅ Ｓｅｑｕｅｎｃｅ Ｎｕｍｂｅｒ）情報（ｅ．ｇ．Ｃｈａｎｇｅ ｓｅｑｕｅｎｃｅ ｅｌｅｍｅｎｔ、Ｃｈａｎｇｅ Ｓｅｑｕｅｎｃｅ ｆｉｅｌｄなど）をともに含め送信するかＳＴＡの実装によって省略して送信することもできる。この場合、もしＭＬＤ Ｐｒｏｂｅ ｒｅｑｕｅｓｔを使用してＡＰのＣｒｉｔｉｃａｌ ｕｐｄａｔｅ情報を要求する場合（すなわち、「Ｃｒｉｔｉｃａｌ ｕｐｄａｔｅ ｒｅｑｕｅｓｔ」ｆｉｅｌｄ＝１）、ＣＳＮ情報を含めるときＣｈａｎｇｅ ｓｅｑｕｅｎｃｅ ｅｌｅｍｅｎｔを使用する場合は別途の追加インジケーターが必要ではないが（ＡＰがＣｈａｎｇｅ ｓｅｑｕｅｎｃｅ ｅｌｅｍｅｎｔのｅｌｅｍｅｎｔ ＩＤを確認してｐｒｅｓｅｎｃｅを確認することができるため）、もしＣＳＮ情報でＣｈａｎｇｅ Ｓｅｑｕｅｎｃｅ ｆｉｅｌｄを使用する場合はＣｈａｎｇｅ Ｓｅｑｕｅｎｃｅ ｆｉｅｌｄのｐｒｅｓｅｎｃｅ有無を示すための（ｓｕｂ）ｆｉｅｌｄ（ｅ．ｇ．「ＣＳＮ Ｐｒｅｓｅｎｃｅ」ｓｕｂｆｉｅｌｄ）に対する追加定義が必要である。したがって、本明細書ではＭＬ ＩＥのＰｅｒ－ＳＴＡ Ｐｒｏｆｉｌｅ内ＣＳＮ情報有無を表示するためのインジケーターを以下のように追加提案する。

－「ＣＳＮ Ｐｒｅｓｅｎｃｅ」（ｓｕｂ）ｆｉｅｌｄ：Ｃｈａｎｇｅ Ｓｅｑｕｅｎｃｅ ｆｉｅｌｄが存在することを示すためのフィールドである。値が１に設定された場合はＣｈａｎｇｅ Ｓｅｑｕｅｎｃｅ ｆｉｅｌｄが存在することを示し、値が０である場合は、Ｃｈａｎｇｅ Ｓｅｑｕｅｎｃｅ ｆｉｅｌｄが存在しないことを示す。

－＞当該フィールドはＳＴＡがＯｔｈｅｒ ＡＰのＣｒｉｔｉｃａｌ ｕｐｄａｔｅ情報を要求する場合「Ｃｒｉｔｉｃａｌ ｕｐｄａｔｅ ｒｅｑｕｅｓｔ」ｆｉｅｌｄとともに使用することができる（例えば、「ＣＳＮ Ｐｒｅｓｅｎｃｅ」（ｓｕｂ）ｆｉｅｌｄはＭＬ ＩＥ内Ｐｅｒ－ＳＴＡ Ｐｒｏｆｉｌｅ ｅｌｅｍｅｎｔのｐｅｒ－ＳＴＡ Ｃｏｎｔｒｏｌ ｆｉｅｌｄ内「Ｃｒｉｔｉｃａｌ ｕｐｄａｔｅ ｒｅｑｕｅｓｔ」（ｓｕｂ）ｆｉｅｌｄとともに使用することができる）。

－＞当該フィールドはＡＰがＢｅａｃｏｎ／Ｐｒｏｂｅ Ｒｅｓｐｏｎｓｅを介してＡＰ（ｒｅｐｏｒｔｉｎｇ ＡＰ ａｎｄ ｒｅｐｏｒｔｅｄ ＡＰを含む）のＣＳＮ情報を広告（ａｄｖｅｒｔｉｓｉｎｇ）する場合でも使用することができる。当該ＣＳＮ情報をａｄｖｅｒｔｉｓｉｎｇするためにＣｈａｎｇｅ ｓｅｑｕｅｎｃｅ ｅｌｅｍｅｎｔを使用する場合は当該フィールドが必要ないが、Ｃｈａｎｇｅ Ｓｅｑｕｅｎｃｅ ｆｉｅｌｄを使用する場合はｆｉｅｌｄ存在を示す「ＣＳＮ Ｐｒｅｓｅｎｃｅ」（ｓｕｂ）ｆｉｅｌｄが必要である。この場合当該（ｓｕｂ）ｆｉｅｌｄは各ＡＰのＣＳＮ情報が含まれる位置にしたがって多様に含まれる。Ｂｅａｃｏｎ／Ｐｒｏｂｅ Ｒｅｓｐｏｎｓｅ ｆｒａｍｅ内に含まれるか（ｅ．ｇ．ｒｅｐｏｒｔｉｎｇ ＡＰのＣＳＮ情報がＢｅａｃｏｎ／Ｐｒｏｂｅ Ｒｅｓｐｏｎｓｅ ｆｒａｍｅに位置する場合）、ＭＬ ＩＥ内のＣｏｍｍｏｎ ｉｎｆｏ ｐａｒｔに含まれるか（ｅ．ｇ．ｒｅｐｏｒｔｅｄ ＡＰのＣＳＮ情報がＭＬ ＩＥ内のＣｏｍｍｏｎ ｉｎｆｏ ｐａｒｔに位置する場合）ｐｅｒ－ＳＴＡ Ｐｒｏｆｉｌｅ（ｅ．ｇ．ｒｅｐｏｒｔｅｄ ＡＰのＣＳＮ情報がＭＬ ＩＥ内ｌｉｎｋ ｉｎｆｏ ｐａｒｔに位置する場合）の中に含まれる。

このとき、もしｎｏｎ－ＡＰ ＳＴＡがＭＬＤ Ｐｒｏｂｅ ｒｅｑｕｅｓｔを使用して各ＳＴＡ（ｘ）、（ｙ）…など（すなわち、ＡＰ（ｘ）、（ｙ）…に対するＣｒｉｔｉｃａｌ ｕｐｄａｔｅ情報を要求するために、Ｍｕｌｔｉ－Ｌｉｎｋ ｅｌｅｍｅｎｔ（ｅ．ｇ．Ｐｒｏｂｅ ｒｅｑｕｅｓｔ ｖａｒｉａｎｔ Ｍｕｌｔｉ－Ｌｉｎｋ ｅｌｅｍｅｎｔ）のＰｅｒ－ＳＴＡ Ｐｒｏｆｉｌｅ（ｘ）内Ｐｅｒ－ＳＴＡ Ｃｏｎｔｒｏｌの「Ｃｒｉｔｉｃａｌ ｕｐｄａｔｅ ｒｅｑｕｅｓｔ」ｆｉｅｌｄの値を１に設定してＳＴＡ（ｘ）に対するＣｒｉｔｉｃａｌ ｕｐｄａｔｅ情報を要求する場合、ＣＳＮ情報に含まれるか否かによってこれを受信したＡＰはＭＬＤ Ｐｒｏｂｅ Ｒｅｓｐｏｎｓｅに対して以下のように応答することができる。

１）Ｎｏｎ－ＡＰ ＳＴＡがＰｅｒ－ＳＴＡ Ｐｒｏｆｉｌｅ（ｘ）に「Ｃｒｉｔｉｃａｌ ｕｐｄａｔｅ ｒｅｑｕｅｓｔ」ｆｉｅｌｄ＝１とともに、自身のＣＳＮ情報（すなわち、最近に受信したＣＳＮ情報でＣｈａｎｇｅ ｓｅｑｕｅｎｃｅ ｅｌｅｍｅｎｔ又はＣｈａｎｇｅ Ｓｅｑｕｅｎｃｅ ｆｉｅｌｄ形で含まれる）を含めてＭＬＤ Ｐｒｏｂｅ ｒｅｑｕｅｓｔを送信する場合

Ａ．ＡＰはｎｏｎ－ＡＰ ＳＴＡ（ｘ）のＣＳＮ情報とｎｏｎ－ＡＰ ＳＴＡ（ｘ）と接続されたＡＰ（ｘ）の現在ＣＳＮ情報を比較して更新されたＣｒｉｔｉｃａｌ ｕｐｄａｔｅ情報（すなわち、８０２．１１ｂｅにおいてＣｒｉｔｉｃａｌ ｕｐｄａｔｅ ｅｖｅｎｔに分類されたｅｌｅｍｅｎｔｓ）のみをＭＬＤ Ｐｒｏｂｅ Ｒｅｓｐｏｎｓｅに含めて応答することができる。

Ｂ．但し、この場合でも、もし受信したＡＰ ＭＬＤがＡＰのＣＳＮ別の更新情報をｔｒａｃｋｉｎｇする機能を実装しない場合は、ＣＳＮバージョン別にどの情報が更新されたことであるかわからないためｎｏｎ－ＡＰ ＳＴＡ（ｘ）と接続されたＡＰ（ｘ）の現在全てのＣｒｉｔｉｃａｌ ｕｐｄａｔｅ情報（すなわち、８０２．１１ｂｅにおいてＣｒｉｔｉｃａｌ ｕｐｄａｔｅ ｅｖｅｎｔに分類されたｅｌｅｍｅｎｔｓ）をＭＬＤ Ｐｒｏｂｅ Ｒｅｓｐｏｎｓｅに含めて応答することもできる。

Ｃ．本明細書ではＭＬＤ Ｐｒｏｂｅ Ｒｅｓｐｏｎｓｅのオーバーヘッドを減らすためにＣｒｉｔｉｃａｌ ｕｐｄａｔｅ情報を要求する時、ＡＰ（ｘ）の全体情報ではないＡＰ（ｘ）の現在全てのＣｒｉｔｉｃａｌ ｕｐｄａｔｅ情報を応答することを提案するが、ＡＰ実装によってｎｏｎ－ＡＰ ＳＴＡからＰｅｒ－ＳＴＡ Ｐｒｏｆｉｌｅ（ｘ）に「Ｃｒｉｔｉｃａｌ ｕｐｄａｔｅ ｒｅｑｕｅｓｔ」ｆｉｅｌｄ＝１に設定されたＭＬＤ Ｐｒｏｂｅ ｒｅｑｕｅｓｔを受信してもＡＰ（ｘ）のＣｏｍｐｌｅｔｅ Ｐｒｏｆｉｌｅ（すなわち、全体情報）を応答することができる。

２）Ｎｏｎ－ＡＰ ＳＴＡがＰｅｒ－ＳＴＡ Ｐｒｏｆｉｌｅ（ｘ）に「Ｃｒｉｔｉｃａｌ ｕｐｄａｔｅ ｒｅｑｕｅｓｔ」ｆｉｅｌｄ＝１とともに、自身のＣＳＮ情報（すなわち、最近受信したＣＳＮ情報）を省略してＭＬＤ Ｐｒｏｂｅ ｒｅｑｕｅｓｔを送信する場合

Ａ．ＡＰはｎｏｎ－ＡＰ ＳＴＡ（ｘ）のＣＳＮ情報がわからないため、ｎｏｎ－ＡＰ ＳＴＡ（ｘ）と接続されたＡＰ（ｘ）の現在全てのＣｒｉｔｉｃａｌ ｕｐｄａｔｅ情報（すなわち、８０２．１１ｂｅにおいてＣｒｉｔｉｃａｌ ｕｐｄａｔｅ ｅｖｅｎｔに分類されたｅｌｅｍｅｎｔｓ）をＭＬＤ Ｐｒｏｂｅ Ｒｅｓｐｏｎｓｅに含めて応答することができる。

Ｂ．本明細書ではＭＬＤ Ｐｒｏｂｅ Ｒｅｓｐｏｎｓｅのオーバーヘッドを減らすためにＣｒｉｔｉｃａｌ ｕｐｄａｔｅ情報を要求する時、ＡＰ（ｘ）の全体情報ではないＡＰ（ｘ）の現在全てのＣｒｉｔｉｃａｌ ｕｐｄａｔｅ情報を応答することを提案するが、ＡＰ実装によってｎｏｎ－ＡＰ ＳＴＡからＰｅｒ－ＳＴＡ Ｐｒｏｆｉｌｅ（ｘ）に「Ｃｒｉｔｉｃａｌ ｕｐｄａｔｅ ｒｅｑｕｅｓｔ」ｆｉｅｌｄ＝１に設定されたＭＬＤ Ｐｒｏｂｅ ｒｅｑｕｅｓｔを受信してＡＰ（ｘ）のＣｏｍｐｌｅｔｅ Ｐｒｏｆｉｌｅ（すなわち、全体情報）を応答することもできる。

図５２はＣｒｉｔｉｃａｌ ｕｐｄａｔｅ情報を要求する時、Ｃｈａｎｇｅ ｓｅｑｕｅｎｃｅ ｅｌｅｍｅｎｔを使用するＭＬＤ Ｐｒｏｂｅ ｒｅｑｕｅｓｔの一例を示す。

図５３はＣｒｉｔｉｃａｌ ｕｐｄａｔｅ情報を要求する時、Ｃｈａｎｇｅ ｓｅｑｕｅｎｃｅ ｅｌｅｍｅｎｔを使用するＭＬＤ Ｐｒｏｂｅ ｒｅｑｕｅｓｔの他の例を示す。

例えば、ｎｏｎ－ＡＰ ＳＴＡが特定のＳＴＡ（ｘ）に対するＣｒｉｔｉｃａｌ ｕｐｄａｔｅ情報を要求する場合でも５３のようにＣｒｉｔｉｃａｌ ｕｐｄａｔｅ ｒｅｑｕｅｓｔ＝１に設定してＣｈａｎｇｅ Ｓｅｑｕｅｎｃｅ Ｎｕｍｂｅｒ情報（ｅ．ｇ．Ｃｈａｎｇｅ ｓｅｑｕｅｎｃｅ ｅｌｅｍｅｎｔ ｏｒＣｈａｎｇｅ Ｓｅｑｕｅｎｃｅ ｆｉｅｌｄ）をともに送信することができる。このとき、ｎｏｎ－ＳＴＡは場合によってＣｈａｎｇｅ Ｓｅｑｕｅｎｃｅ Ｎｕｍｂｅｒ情報は省略して送信することもできる。但し、この場合は上記定義したようにＡＰが応答するＭＬＤ Ｐｒｏｂｅ Ｒｅｓｐｏｎｓｅに含まれる情報が限られる。

図５４はＭＬ ＩＥフォーマットにＣｒｉｔｉｃａｌ ｕｐｄａｔｅ ｒｅｑｕｅｓｔ ｆｉｅｌｄが含まれる一例を示す。

図５４を参照すれば、上記のようにＣｒｉｔｉｃａｌ ｕｐｄａｔｅ ｒｅｑｕｅｓｔ ｆｉｅｌｄをＭＬ ＩＥ内に位置させる場合、Ｐｅｒ－ＳＴＡ Ｐｒｏｆｉｌｅ（ｘ）を介して指示する全てのリンクに対するＣｒｉｔｉｃａｌ ｕｐｄａｔｅ情報を要求することができる。もしＣｒｉｔｉｃａｌ ｕｐｄａｔｅ ｒｅｑｕｅｓｔ ｆｉｅｌｄをＭＬ ＩＥ内のＣｏｍｍｏｎ ｉｎｆｏｒｍａｔｉｏｎを含む位置に含め、フィールドの値を１に指示して送信する場合、これを受信したＡＰは当該ｒｅｑｕｅｓｔ ｆｒａｍｅにおいて要求するリンクに対するＣｒｉｔｉｃａｌ ｕｐｄａｔｅ情報を含んだ応答フレームを応答する。又は、Ｃｒｉｔｉｃａｌ ｕｐｄａｔｅ ｒｅｑｕｅｓｔ ｆｉｅｌｄをＭＬ ＩＥ内Ｍｕｌｔｉ－ｌｉｎｋ Ｃｏｎｔｒｏｌ ｆｉｅｌｄ内ｓｕｂｆｉｅｌｄに含め指示することもできる。このように定義したｆｉｅｌｄの形（ｆｉｅｌｄ ｏｒ ｓｕｂｆｉｅｌｄ ｏｒ ｓｕｂｅｌｅｍｅｎｔなど）又はＭＬ ＩＥ内の位置は規格定義によって多様に定義される。

２つ目の、Ｏｔｈｅｒ ＡＰのＣｒｉｔｉｃａｌ ｕｐｄａｔｅ情報の要求のためのＣｈａｎｇｅ ｓｅｑｕｅｎｃｅ ｅｌｅｍｅｎｔを使用する方法である。８０２．１１ａｈではＰｒｏｂｅ ｒｅｑｕｅｓｔ ｆｒａｍｅにＣｈａｎｇｅ ｓｅｑｕｅｎｃｅ ｅｌｅｍｅｎｔを含めて送信する場合、ＡＰはＰｒｏｂｅ Ｒｅｓｐｏｎｓｅ ｆｒａｍｅに当該リンクに対する変更されたＣｒｉｔｉｃａｌ ｕｐｄａｔｅ情報のみをＣｏｍｐｒｅｓｓｅｄ Ｐｒｏｂｅ Ｒｅｓｐｏｎｓｅ ｆｒａｍｅに含めて送信する。８０２．１１ｂｅでもこれを活用することができる。

ＳＴＡがＰｒｏｂｅ ｒｅｑｕｅｓｔ ｆｒａｍｅにＯｔｈｅｒ ＡＰに対するリンクインジケーターとともにＣｈａｎｇｅ ｓｅｑｕｅｎｃｅ ｅｌｅｍｅｎｔを含めて要求する場合、これを受信したＡＰは指示されたリンクに対する変更されたＣｒｉｔｉｃａｌ ｕｐｄａｔｅ情報のみをＰｒｏｂｅ Ｒｅｓｐｏｎｓｅに含めて送信する。Ｃｈａｎｇｅ ｓｅｑｕｅｎｃｅ ｅｌｅｍｅｎｔはＲｅｑｕｅｓｔ Ｆｒａｍｅ内あるｅｌｅｍｅｎｔ又はｓｕｂ－ｅｌｅｍｅｎｔ内に含めることができ、上記言及したＭＬＤ Ｒｅｑｕｅｓｔ ｅｌｅｍｅｎｔ又はＭＬ ＩＥに含まれて使用される。これに対する実施形態は図５５の通りである。

図５５はＭＬ ＩＥフォーマットにＣｈａｎｇｅ ｓｅｑｕｅｎｃｅ ｅｌｅｍｅｎｔが含まれる一例を示す。

例えば、図５５のようにＭＬ ＩＥ内Ｃｈａｎｇｅ ｓｅｑｕｅｎｃｅ ｅｌｅｍｅｎｔを含めて送信する場合、ＡＰはＭＬ ＩＥを介して指示されたリンクに対して現在自身が持ったＣｈａｎｇｅ Ｓｅｑｕｅｎｃｅ ｆｉｅｌｄの値とＳＴＡが送信したＣｈａｎｇｅ ｓｅｑｕｅｎｃｅ ｅｌｅｍｅｎｔ内のＣｈａｎｇｅ Ｓｅｑｕｅｎｃｅ ｆｉｅｌｄの値を比較して変更事項がある場合、変更されたＣｒｉｔｉｃａｌ ｕｐｄａｔｅ情報をＰｒｏｂｅ Ｒｅｓｐｏｎｓｅに含め応答する。このとき、ＳＴＡが送信するＣｈａｎｇｅ ｓｅｑｕｅｎｃｅ ｅｌｅｍｅｎｔはＭＬ ＩＥにおいて情報を要求する全てのリンクに対するＣｈａｎｇｅ Ｓｅｑｕｅｎｃｅ情報を含める必要がある。したがって既存のＣｈａｎｇｅ ｓｅｑｕｅｎｃｅ ｅｌｅｍｅｎｔを使用する場合、さらに要求するリンクインジケーター情報が必要な場合がある。さらに本明細書では、上記のようにＭＬ ＩＥ内Ｃｈａｎｇｅ ｓｅｑｕｅｎｃｅ ｅｌｅｍｅｎｔを含めて送信する場合、ＡＰが現在持ったＣｒｉｔｉｃａｌ ｕｐｄａｔｅに関連した全ての情報を含めて送信するオプションも考慮する。もしＡＰがＳＴＡが送信したＣｈａｎｇｅ Ｓｅｑｕｅｎｃｅ ｆｉｅｌｄの値と現在自身が持ったｆｉｅｌｄを比較して異なる場合、ＡＰが現在持ったＣｒｉｔｉｃａｌ ｕｐｄａｔｅに関連した全ての情報をＳＴＡに送信する。このような方法はＡＰが送信する情報に対するオーバーヘッドは増加することができるが各ＡＰに対するＣｒｉｔｉｃａｌ ｕｐｄａｔｅバージョン別の変更情報を格納する必要がないためより簡単に実装することができる。

さらに、本明細書ではＭＬＤを考慮した新規ｅｌｅｍｅｎｔをさらに提案する。

「ＭＬＤ Ｃｈａｎｇｅ ｓｅｑｕｅｎｃｅ ｅｌｅｍｅｎｔ」：複数のリンクのＣｈａｎｇｅ Ｓｅｑｕｅｎｃｅ情報を含めることができるＥｌｅｍｅｎｔ

これに対する実施形態は図５６及び図５７の通りである。

図５６はＭＬＤ Ｃｈａｎｇｅ Ｓｅｑｕｅｎｃｅフォーマットの一例を示す。

図５７はＭＬＤ Ｃｈａｎｇｅ Ｓｅｑｕｅｎｃｅフォーマットの他の例を示す。

図５６のようにＭＬＤ Ｃｈａｎｇｅ Ｓｅｑｕｅｎｃｅの値は各リンク別にＣｈａｎｇｅ Ｓｅｑｕｅｎｃｅの値を繰り返して並べるか、図５７のようにリンクの数を「Ｔｈｅ ｎｕｍｂｅｒ ｏｆ Ｌｉｎｋ ＩＤ」に指示した後、Ｌｉｎｋ ＩＤ情報とＣｈａｎｇｅ Ｓｅｑｕｅｎｃｅ情報をそれぞれ指示して示すこともできる。

ＭＬＤ Ｃｈａｎｇｅ ｓｅｑｕｅｎｃｅ ｅｌｅｍｅｎｔに対する実施形態は図５８の通りである。

図５８はＭＬＤ Ｃｈａｎｇｅ ｓｅｑｕｅｎｃｅ ｅｌｅｍｅｎｔの一例を示す。

図５８のようにＭＬＤ Ｃｈａｎｇｅ ｓｅｑｕｅｎｃｅ ｅｌｅｍｅｎｔがＰｒｏｂｅ ｒｅｑｕｅｓｔ Ｆｒａｍｅ内のＭＬ ＩＥに含まれて送信する場合、ＡＰは各リンク別受信したＣｈａｎｇｅ Ｓｅｑｕｅｎｃｅ ｖａｌｕｅと自身が持ったＣｈａｎｇｅ Ｓｅｑｕｅｎｃｅ ｖａｌｕｅを比較して、更新されたＣｈａｎｇｅ Ｓｅｑｕｅｎｃｅ ｖａｌｕｅに該当するリンクに対する変更されたＣｒｉｔｉｃａｌ ｕｐｄａｔｅ情報をＲｅｓｐｏｎｓｅ ｆｒａｍｅに含めて応答することができる。この場合、もしＳＴＡがリンク別に異なる情報を要求することがない場合、Ｐｅｒ－ＳＴＡ Ｐｒｏｆｉｌｅ（ｘ）ｓｕｂ－ｅｌｅｍｅｎｔは省略して送信することもできる。

このとき、既存のＣｈａｎｇｅ ｓｅｑｕｅｎｃｅ ｅｌｅｍｅｎｔを使用する場合、図５９のように使用することができる。

図５９は既存の規格においてのＣｈａｎｇｅ ｓｅｑｕｅｎｃｅ ｅｌｅｍｅｎｔの一例を示す。

ＭＬ ＩＥ内に既存Ｃｈａｎｇｅ ｓｅｑｕｅｎｃｅ ｅｌｅｍｅｎｔをそのまま使用してリンク別に更新されたＣｒｉｔｉｃａｌ ｕｐｄａｔｅ情報を要求することもできる。これに対する実施形態は図５９の通りである。

図６０はＭＬ ＩＥフォーマットにＣｈａｎｇｅ ｓｅｑｕｅｎｃｅ ｅｌｅｍｅｎｔが含まれる他の例を示す。

図６０を参照すれば、ＳＴＡがＰｒｏｂｅ ｒｅｑｕｅｓｔ内ＭＬ ＩＥ内Ｐｅｒ－ＳＴＡ Ｐｒｏｆｉｌｅ（ｘ）内にＣｈａｎｇｅ ｓｅｑｕｅｎｃｅ ｅｌｅｍｅｎｔを含めて送信する場合、Ｐｅｒ ＳＴＡ Ｐｒｏｆｉｌｅ（ｘ）において指示するリンクの変更されたＣｒｉｔｉｃａｌ ｕｐｄａｔｅ情報の要求を意味する。したがって、Ｒｅｑｕｅｓｔ ｆｒａｍｅに含まれたＣｈａｎｇｅ ｓｅｑｕｅｎｃｅ ｅｌｅｍｅｎｔを確認したＡＰは受信したＣｈａｎｇｅ Ｓｅｑｕｅｎｃｅ ｖａｌｕｅと自身が持ったＣｈａｎｇｅ Ｓｅｑｕｅｎｃｅ ｖａｌｕｅを比較して更新がある場合（すなわち、ＳＴＡが更新する必要がある変更された情報がある場合）、変更されたＣｒｉｔｉｃａｌ ｕｐｄａｔｅ情報を含んだＲｅｓｐｏｎｓｅ ｆｒａｍｅを送信するか全体Ｃｒｉｔｉｃａｌ ｕｐｄａｔｅ関連情報を含んだＲｅｓｐｏｎｓｅ ｆｒａｍｅを送信することができる。

第３に、Ｏｔｈｅｒ ＡＰのＣｒｉｔｉｃａｌ ｕｐｄａｔｅ情報の要求のために上記定義した「Ｃｒｉｔｉｃａｌ ｕｐｄａｔｅ ｒｅｑｕｅｓｔ」ｆｉｅｌｄとともにＣｈａｎｇｅ Ｓｅｑｕｅｎｃｅ ｆｉｅｌｄを使用する方法である。上記ＳＴＡがＯｔｈｅｒ ＡＰの情報を要求するためのインジケーターとして以下のように「Ｃｒｉｔｉｃａｌ ｕｐｄａｔｅ ｒｅｑｕｅｓｔ」ｆｉｅｌｄを定義した。

－「Ｃｒｉｔｉｃａｌ ｕｐｄａｔｅ ｒｅｑｕｅｓｔ」ｆｉｅｌｄ：ＡＰのＣｒｉｔｉｃａｌ ｕｐｄａｔｅとして定義されたシステム情報のみを要求するフィールドである。リンクインジケーターとともに使用され特定のリンクのＣｒｉｔｉｃａｌ ｕｐｄａｔｅとして定義されたシステム情報を要求する時、使用することができる。

しかし、ＳＴＡが上記のように１ｂｉｔのインジケーターに特定のリンクのＣｒｉｔｉｃａｌ ｕｐｄａｔｅ情報を要求する場合、これを受信したＡＰが現在ＳＴＡが持ったＣｒｉｔｉｃａｌ ｕｐｄａｔｅ情報のバージョン（すなわち、ＳＴＡが持ったＣｒｉｔｉｃａｌ ｕｐｄａｔｅ情報のＣｈａｎｇｅ Ｓｅｑｕｅｎｃｅ ｆｉｅｌｄの値）がわからない場合、ＡＰは要求を受けたリンクに対する全てのＣｒｉｔｉｃａｌ ｕｐｄａｔｅ情報を含んだｒｅｓｐｏｎｓｅ ｍｅｓｓａｇｅを送信する必要がある。そして当該Ｒｅｓｐｏｎｓｅ ｆｒａｍｅにＣｒｉｔｉｃａｌ ｕｐｄａｔｅ情報とともにＣｈａｎｇｅ ｓｅｑｕｅｎｃｅ ｅｌｅｍｅｎｔをともに含めて送信することもできる。これは多少簡単な方法であるがＳＴＡが既に持っている情報に対する重複送信である場合があるためこれに対するオーバーヘッドを減らすためのｆｏｒｍａｔを追加提案する。これに対する実施形態は以下の通りである。

図６１はＣｒｉｔｉｃａｌ ｕｐｄａｔｅ情報の要求のためのＰｒｏｂｅ ｒｅｑｕｅｓｔ ｆｒａｍｅの一例を示す。

図６１を参照すれば、ＳＴＡはＲｅｑｕｅｓｔ ｆｒａｍｅにＣｒｉｔｉｃａｌ ｕｐｄａｔｅ情報の要求を指示するためのインジケーターであるＣｒｉｔｉｃａｌ ｕｐｄａｔｅ ｒｅｑｕｅｓｔフィールドとともに現在ＳＴＡが持ったＣｒｉｔｉｃａｌ ｕｐｄａｔｅのバージョン情報を示すＣｈａｎｇｅ Ｓｅｑｕｅｎｃｅ ｆｉｅｌｄｓ（又は、Ｃｈａｎｇｅ ｓｅｑｕｅｎｃｅ ｅｌｅｍｅｎｔ）を含めて送信することができる。このとき、Ｃｈａｎｇｅ Ｓｅｑｕｅｎｃｅ ｆｉｅｌｄｓはリンク別Ｃｈａｎｇｅ Ｓｅｑｕｅｎｃｅ ｖａｌｕｅを示したインジケーターを意味する。８０２．１１ｂｅにおいて、ＳＴＡはｂｅａｃｏｎ又はＰｒｏｂｅ Ｒｅｓｐｏｎｓｅを介して周期的に接続されたＡＰ ＭＬＤのＡＰに対するＣｈａｎｇｅ Ｓｅｑｕｅｎｃｅ ｖａｌｕｅ値を受けることができ、また、ＳＴＡがこの値を格納するものであり定義されたため、ＳＴＡは自身が現在受信したリンク別Ｃｈａｎｇｅ Ｓｅｑｕｅｎｃｅ ｖａｌｕｅ情報を認知している。したがって、本明細書で定義するＣｈａｎｇｅ Ｓｅｑｕｅｎｃｅ ｆｉｅｌｄｓフィールドはＳＴＡがＢｅａｃｏｎ又はＰｒｏｂｅ Ｒｅｓｐｏｎｓｅを介して以前に獲得した接続ＡＰ ＭＬＤのＡＰに対するＣｒｉｔｉｃａｌ ｕｐｄａｔｅ情報のバージョン（すなわち、Ｃｈａｎｇｅ Ｓｅｑｕｅｎｃｅ ｖａｌｕｅ）に対する情報を意味する。

このとき、「Ｃｒｉｔｉｃａｌ ｕｐｄａｔｅ ｒｅｑｕｅｓｔ」ｆｉｅｌｄの値が１である場合はＳＴＡがＣｒｉｔｉｃａｌ ｕｐｄａｔｅ情報を要求することを意味し、そのではない場合、値を０で指示する。「Ｃｒｉｔｉｃａｌ ｕｐｄａｔｅ ｒｅｑｕｅｓｔ」ｆｉｅｌｄの値が１である場合はＣｒｉｔｉｃａｌ ｕｐｄａｔｅ情報の要求を意味するためＣｈａｎｇｅ Ｓｅｑｕｅｎｃｅ ｆｉｅｌｄｓフィールド（又はＣｈａｎｇｅ ｓｅｑｕｅｎｃｅ ｅｌｅｍｅｎｔ）を含めて送信するが、値が０である場合はこのフィールドを省略して送信する。すなわち、つまり、「Ｃｒｉｔｉｃａｌ ｕｐｄａｔｅ ｒｅｑｕｅｓｔ」ｆｉｅｌｄの値が１である場合はＳＴＡがＣｈａｎｇｅ Ｓｅｑｕｅｎｃｅ ｆｉｅｌｄｓ（又はＣｈａｎｇｅ ｓｅｑｕｅｎｃｅ ｅｌｅｍｅｎｔ）を追加して送信することでこれを受信したＡＰが自身が持った現在情報と比較して変更された情報のみを（すなわち、ＳＴＡが更新する必要がある変更された情報のみを）応答メッセージに追加して送信することができ、「Ｃｒｉｔｉｃａｌ ｕｐｄａｔｅ ｒｅｑｕｅｓｔ」ｆｉｅｌｄの値が０である場合はオーバーヘッドを減らすためにＣｈａｎｇｅ Ｓｅｑｕｅｎｃｅ ｆｉｅｌｄｓ（又はＣｈａｎｇｅ ｓｅｑｕｅｎｃｅ ｅｌｅｍｅｎｔ）を省略して送信する。さらに本明細書では、上記のようにＭＬ ＩＥ内Ｃｈａｎｇｅ Ｓｅｑｕｅｎｃｅ ｆｉｅｌｄｓを含めて送信する場合、ＡＰが現在持ったＣｒｉｔｉｃａｌ ｕｐｄａｔｅに関連した全ての情報を含めて送信するオプションも考慮する。もし、ＡＰがＳＴＡが送信したＣｈａｎｇｅ Ｓｅｑｕｅｎｃｅ ｆｉｅｌｄの値と現在自身が持ったｆｉｅｌｄを比較して異なる場合、ＡＰが現在持ったＣｒｉｔｉｃａｌ ｕｐｄａｔｅに関連した全ての情報をＳＴＡに送信する。このような方法はＡＰが送信する情報に対するオーバーヘッドは増加することができるが各ＡＰに対するＣｒｉｔｉｃａｌ ｕｐｄａｔｅバージョン別の変更情報を格納する必要がないため、より簡単に実装することができる。

上記のように「Ｃｒｉｔｉｃａｌ ｕｐｄａｔｅ ｒｅｑｕｅｓｔ」ｆｉｅｌｄの値によってＣｈａｎｇｅ Ｓｅｑｕｅｎｃｅ ｆｉｅｌｄ（又は、Ｃｈａｎｇｅ ｓｅｑｕｅｎｃｅ ｅｌｅｍｅｎｔ）存在有無を区分して定義する場合もあるが、オプションにしたがって、「Ｃｒｉｔｉｃａｌ ｕｐｄａｔｅ ｒｅｑｕｅｓｔ」ｆｉｅｌｄの値とＣｈａｎｇｅ Ｓｅｑｕｅｎｃｅ ｆｉｅｌｄフィールド（又は、Ｃｈａｎｇｅ ｓｅｑｕｅｎｃｅ ｅｌｅｍｅｎｔ）を独立的に定義して使用することもできる。この場合は、もしＳＴＡが送信した要求メッセージに１の値を持った「Ｃｒｉｔｉｃａｌ ｕｐｄａｔｅ ｒｅｑｕｅｓｔ」ｆｉｅｌｄとともにＣｈａｎｇｅ Ｓｅｑｕｅｎｃｅ ｆｉｅｌｄｓフィールド（又はＣｈａｎｇｅ ｓｅｑｕｅｎｃｅ ｅｌｅｍｅｎｔ）を含まない場合が発生する場合があるが、この場合、これを受信したＡＰがただ更新されたＣｒｉｔｉｃａｌ ｕｐｄａｔｅ情報ではない全てのＣｒｉｔｉｃａｌ ｕｐｄａｔｅ情報を受信したいものであと見なして応答メッセージに全てのＣｒｉｔｉｃａｌ ｕｐｄａｔｅ情報を含めて応答する。本明細書では、以下のように「Ｃｒｉｔｉｃａｌ ｕｐｄａｔｅ ｒｅｑｕｅｓｔ」ｆｉｅｌｄとともにＳＴＡが以前に獲得したＣｈａｎｇｅ Ｓｅｑｕｅｎｃｅ ｖａｌｕｅ情報を送信してＡＰが現在自身が持ったＣｈａｎｇｅ Ｓｅｑｕｅｎｃｅ ｖａｌｕｅ情報と比較して変更された情報のみをＲｅｓｐｏｎｓｅ ｆｒａｍｅに含めて送信する方法を提案する。このとき、当該セクションではリンクのＣｈａｎｇｅ Ｓｅｑｕｅｎｃｅ情報を転送するために例としてＣｈａｎｇｅ Ｓｅｑｕｅｎｃｅ ｆｉｅｌｄｓフィールドを提供するが、ＳＴＡはＣｈａｎｇｅ Ｓｅｑｕｅｎｃｅ ｆｉｅｌｄｓフィールドではないＣｈａｎｇｅ ｓｅｑｕｅｎｃｅ ｅｌｅｍｅｎｔとして要求することもできる。但し、上記のセクションにおいてＣｈａｎｇｅ ｓｅｑｕｅｎｃｅ ｅｌｅｍｅｎｔ使用は既に言及したため当該セクションにおいて「Ｃｒｉｔｉｃａｌ ｕｐｄａｔｅ ｒｅｑｕｅｓｔ」ｆｉｅｌｄとともにＣｈａｎｇｅ ｓｅｑｕｅｎｃｅ ｅｌｅｍｅｎｔを使用する実施形態は省略した。

例えば、ＳＴＡがＭＬＤ ＰｒｏｂｉｎｇのためにＰｒｏｂｅ ｒｅｑｕｅｓｔ ｆｒａｍｅにＭＬ ＩＥを含めて送信する場合、Ｃｒｉｔｉｃａｌ ｕｐｄａｔｅを要求するための情報は図６１のように各ＳＴＡ別情報を要求するためのＰｅｒ－ＳＴＡ Ｐｒｏｆｉｌｅ（ｘ）ｓｕｂｅｌｅｍｅｎｔ内に含まれる。このとき、Ｐｅｒ－ＳＴＡ Ｃｏｎｔｒｏｌ ｆｉｅｌｄ内のＣｒｉｔｉｃａｌ ｕｐｄａｔｅ ｒｅｑｕｅｓｔ ｆｉｅｌｄが含まれ、現在ＳＴＡのＣｒｉｔｉｃａｌ ｕｐｄａｔｅ情報を持ったＣｈａｎｇｅ Ｓｅｑｕｅｎｃｅ ｆｉｅｌｄｓフィールドはＰｅｒ－ＳＴＡ Ｐｒｏｆｉｌｅ（ｘ）の中に位置することができる。このとき、Ｃｒｉｔｉｃａｌ ｕｐｄａｔｅ ｒｅｑｕｅｓｔ ｆｉｅｌｄはＰｅｒ－ＳＴＡ Ｃｏｎｔｒｏｌ ｆｉｅｌｄの中ではないＰｅｒ－ＳＴＡ Ｐｒｏｆｉｌｅ（ｘ）の中にＣｈａｎｇｅ Ｓｅｑｕｅｎｃｅ ｆｉｅｌｄｓとともに位置することもできる。これに対する実施形態は図６２の通りである。

図６２はＣｒｉｔｉｃａｌ ｕｐｄａｔｅ情報の要求のためのＰｒｏｂｅ ｒｅｑｕｅｓｔ ｆｒａｍｅの他の例を示す。

図６２のようなＲｅｑｕｅｓｔ ｆｒａｍｅを受信したＡＰはＲｅｑｕｅｓｔ Ｆｒａｍｅ内ＭＬ ＩＥ情報を報告し、ＳＴＡが要求した特定のリンクのＣｒｉｔｉｃａｌ ｕｐｄａｔｅ情報を含んだ応答メッセージを送信する。このとき、もしＭＬ ＩＥ内Ｐｅｒ－ＳＴＡ Ｐｒｏｆｉｌｅ（ｘ）要素内にＣｒｉｔｉｃａｌ ｕｐｄａｔｅ ｒｅｑｕｅｓｔ ｆｉｅｌｄが存在し、その値が１である場合、ＳＴＡがＣｒｉｔｉｃａｌ ｕｐｄａｔｅ情報を要求したものであり認識する。又、このときともに受信したＣｈａｎｇｅ Ｓｅｑｕｅｎｃｅ ｆｉｅｌｄｓ情報を介してＳＴＡが持ったＣｈａｎｇｅ Ｓｅｑｕｅｎｃｅ情報とＳＴＡが要求したリンク（Ｘ）に対する現在Ｃｈａｎｇｅ Ｓｅｑｕｅｎｃｅ情報を比較して、更新された事項がある場合（すなわち、ＳＴＡが更新する必要がある変更された情報がある場合）、更新された情報のみを含んだＣｏｍｐｒｅｓｓｅｄ Ｐｒｏｂｅ Ｒｅｓｐｏｎｓｅ ｆｒａｍｅを送信するか更新された事項がある場合、Ｃｒｉｔｉｃａｌ ｕｐｄａｔｅに関連した全ての情報をＰｒｏｂｅ Ｒｅｓｐｏｎｓｅ ｆｒａｍｅで応答することができる。

上記言及した情報はＭＬ ＩＥ内Ｌｉｎｋ ｓｐｅｃｉｆｉｃレベルではないＣｏｍｍｏｎ ｉｎｆｏレベルに含まれて、特定のリンクではない全てのリンクに対しても１度にＣｒｉｔｉｃａｌ ｕｐｄａｔｅ情報を要求することもできる。

これに対する実施形態は図６３の通りである。

図６３はＣｒｉｔｉｃａｌ ｕｐｄａｔｅ情報の要求のためのＰｒｏｂｅ ｒｅｑｕｅｓｔ ｆｒａｍｅの他の例を示す。

図６３のように、ＳＴＡがＭＬ ＩＥ内Ｌｉｎｋ ｓｐｅｃｉｆｉｃ情報位置（ｅ．ｇ．Ｐｅｒ－ＳＴＡ Ｐｒｏｆｉｌｅ（ｘ）ではないＣｏｍｍｏｎ情報位置にＣｒｉｔｉｃａｌ ｕｐｄａｔｅ ｒｅｑｕｅｓｔ ｆｉｅｌｄ（すなわち、値を１に設定）及びＣｈａｎｇｅ Ｓｅｑｕｅｎｃｅ ｆｉｅｌｄｓを含めてｒｅｑｕｅｓｔ ｆｒａｍｅを送信することができる。これを受信したＡＰはＳＴＡが特定のリンクではない自身が持った全てのリンクに対する要求で認識して、ＳＴＡが送信したＣｈａｎｇｅ Ｓｅｑｕｅｎｃｅ ｆｉｅｌｄｓ情報と自身が持った全てのリンクに対する現在Ｃｈａｎｇｅ Ｓｅｑｕｅｎｃｅ情報を比較して、更新された事項がある場合（すなわち、ＳＴＡが更新する必要がある変更された情報がある場合）、全てのリンクに対して更新された情報のみを含んだＣｏｍｐｒｅｓｓｅｄ Ｐｒｏｂｅ Ｒｅｓｐｏｎｓｅ ｆｒａｍｅを送信するか更新された事項がある場合、Ｃｒｉｔｉｃａｌ ｕｐｄａｔｅに関連した全ての情報をＰｒｏｂｅ Ｒｅｓｐｏｎｓｅ ｆｒａｍｅで応答することができる。

図６４はＣｒｉｔｉｃａｌ ｕｐｄａｔｅ情報の要求のためのＰｒｏｂｅ ｒｅｑｕｅｓｔ ｆｒａｍｅの他の例を示す。

このとき、ＳＴＡは図６４のようにＣｒｉｔｉｃａｌ ｕｐｄａｔｅ ｒｅｑｕｅｓｔ ｆｉｅｌｄをＭｕｌｔｉ－ｌｉｎｋ Ｃｏｎｔｒｏｌ ｆｉｅｌｄ内に位置してリンクの変更されたＣｒｉｔｉｃａｌ ｕｐｄａｔｅ情報の要求を指示することもできる。

上記ＳＴＡが特定のＡＰに対するＣｒｉｔｉｃａｌ ｕｐｄａｔｅ変更情報を要求する方法に対して、本明細書ではＡＰが応答するＲｅｓｐｏｎｓｅ動作に対して追加提案する。現在８０２．１１ａｘ規格では６ＧＨｚ ＡＰがＰｒｏｂｅ ｒｅｑｕｅｓｔを受信した場合、Ｐｒｏｂｅ Ｒｅｓｐｏｎｓｅ ｆｒａｍｅ送信するとき、ＡＰが自身のＢｅａｃｏｎ ｆｒａｍｅのＳＳＩＤ ｅｌｅｍｅｎｔのａｃｔｕａｌ ＳＳＩＤを指示しない場合、Ａｄｄｒｅｓｓ １ ｆｉｅｌｄにｂｒｏａｄｃａｓｔ ａｄｄｒｅｓｓを設定して送信するルールが既に定義されている。これを参考して、８０２．１１ｂｅ規格では２．４ＧＨｚ ｂａｎｄ又は５ＧＨｚ ｂａｎｄにおいて作動するＡＰに対して完全な情報を要求するＭＬＤ Ｐｒｏｂｅ ｒｅｑｕｅｓｔ ｆｒａｍｅを受信した場合、ＭＬＤ Ｐｒｏｂｅ Ｒｅｓｐｏｎｓｅ ｆｒａｍｅを応答するとき、ＡＰが自身のＢｅａｃｏｎ ｆｒａｍｅのＳＳＩＤ ｅｌｅｍｅｎｔのａｃｔｕａｌ ＳＳＩＤを指示しない場合、Ａｄｄｒｅｓｓ １ ｆｉｅｌｄをｂｒｏａｄｃａｓｔ ａｄｄｒｅｓｓに設定する方法に対して議論されている。

これに対して、本明細書ではＳＴＡがＭＬＤ Ｐｒｏｂｅ ｒｅｑｕｅｓｔ ｆｒａｍｅを介して特定のＡＰに対するＣｒｉｔｉｃａｌ ｕｐｄａｔｅ更新関連情報を要求した場合でも（例えば、ＳＴＡがＭＬＤ Ｐｒｏｂｅ ｒｅｑｕｅｓｔ ｆｒａｍｅにＣｈａｎｇｅ Ｓｅｑｕｅｎｃｅ ｆｉｅｌｄ情報を含めて送信した場合）、ＡＰがＭＬＤ Ｐｒｏｂｅ Ｒｅｓｐｏｎｓｅ ｆｒａｍｅを応答するとき、ＡＰが自身のＢｅａｃｏｎ ｆｒａｍｅのＳＳＩＤ ｅｌｅｍｅｎｔのａｃｔｕａｌ ＳＳＩＤを指示しなければ、Ａｄｄｒｅｓｓ １ ｆｉｅｌｄをｂｒｏａｄｃａｓｔ ａｄｄｒｅｓｓに設定する方法に対して提案する。Ｃｒｉｔｉｃａｌ ｕｐｄａｔｅ情報はＡＰの重要変更情報として全てのＳＴＡがデータ送／受信する前に知るべき情報である。したがってＭＬＤ Ｐｒｏｂｉｎｇによるｓｔｏｒｍを防ぐために、本明細書ではＳＴＡが特定のＡＰのＣｒｉｔｉｃａｌ ｕｐｄａｔｅに対する部分情報を要求する時、別途の指示がなければ、ｂｒｏａｄｃａｓｔ ｍｅｓｓａｇｅで応答する方法を提案する。

又、上記説明したように、ＡＰ ＭＬＤの実装によってＡＰ ＭＬＤは各ＡＰのＣＳＮ（Ｃｈａｎｇｅ Ｓｅｑｕｅｎｃｅ Ｎｕｍｂｅｒ、Ｃｒｉｔｉｃａｌ ｕｐｄａｔｅが発生する時毎に）別にどの情報（すなわち、ＩＥｓ）が更新したかを格納する方法を実装する場合もあり、メモリサイズによって実装しない場合がある。もし当該の方法をサポートする場合はＡＰが自身のＣＳＮ変更する時毎にどのＩＥ情報に対する更新が発生したかを記憶する必要がある。例えば、ＡＰがＣＳＮｎ＝１においてＥｌｅｍｅｎｔＸに対するＣｒｉｔｉｃａｌ ｕｐｄａｔｅ ｅｖｅｎｔが発生してＣＳＮ＝ｎ＋１においてＥｌｅｍｅｎｔ Ｙ、Ｚに対する更新が発生すれば、ＡＰはＣＳＮ＝ｎとＣＳＮｎ＋１においてどの情報が変更されたか情報を維持する必要がある。もしＡＰがこのようにＣＳＮ別にどのＩＥが変更されたかをＴｒａｃｋｉｎｇすることができれば、ＳＴＡが自身が現在格納して、あるＣＳＮ情報をＲｅｑｕｅｓｔ ｆｒａｍｅに含めて送信したとき、全体情報ではないＡＰの現在ＣＳＮ値と比較して変更された情報のみをＲｅｓｐｏｎｓｅ ｆｒａｍｅに含めて送信することができるためオーバーヘッドの側面で便利である。しかしこのようなｔｒａｃｋｉｎｇは簡単でない場合があり、ＡＰにも追加的なメモリを要求するためＡＰの実装の仕様によって当該能力をサポートできる場合とできない場合がある。したがって、このようなＡＰのＣＳＮ別の更新情報Ｔｒａｃｋｉｎｇに対する能力を指示するためのｃａｐａｂｉｌｉｔｙを当該発明において次のように提案する。

－「Ｃｒｉｔｉｃａｌ ｕｐｄａｔｅ Ｔｒａｃｋｉｎｇ Ｓｕｐｐｏｒｔ」ｆｉｅｌｄ：当該ｆｉｅｌｄは現在ＳＴＡ又はＡＰがＣＳＮ ｖａｌｕｅ別にどの情報（ｅ．ｇ．ＥＩ（Ｅｌｅｍｅｎｔ ＩＤ）情報）が更新されたことであるか格納する機能に対するサポート有無を指示する情報である。当該値が１である場合は、ＳＴＡ又はＡＰがＣＳＮ ｖａｌｕｅ別にどの情報に対する更新が発生したかを格納する能力をサポートすることを意味し、０である場合は、ＳＴＡ又はＡＰが当該機能をサポートしないことを意味する。例えば、このｆｉｅｌｄはＥｘｔｅｎｄｅｄ Ｃａｐａｂｉｌｉｔｉｅｓ ｅｌｅｍｅｎｔ又はＥＨＴ Ｃａｐａｂｉｌｉｔｉｅｓ ｅｌｅｍｅｎｔなどに含まれる。

ＳＴＡはＡｓｓｏｃｉａｔｉｏｎプロセスにおいて当該ＡＰ（又はＳＴＡ）がこの機能に対するサポート有無を確認して、特定のＡＰ（又はＳＴＡ）に対するＣｒｉｔｉｃａｌ ｕｐｄａｔｅ情報を要求することに活用することができる。当該機能はＭＬＤｌｅｖｅｌにおいてサポートされ、各ＳＴＡ別にＳＴＡ ｌｅｖｅｌにおいてサポートされる。

このように、ＭＬＤのＣｒｉｔｉｃａｌ ｕｐｄａｔｅ ｔｒａｃｋｉｎｇサポート有無を指示する「Ｃｒｉｔｉｃａｌ ｕｐｄａｔｅ Ｔｒａｃｋｉｎｇ Ｓｕｐｐｏｒｔ」ｆｉｅｌｄを定義する場合、これに係るＳＴＡの詳細の動作は以下のように定義される。

例えば、ＡＰ ＭＬＤがＣｒｉｔｉｃａｌ ｕｐｄａｔｅ Ｔｒａｃｋｉｎｇ Ｓｕｐｐｏｒｔをサポートする場合（ｅ．ｇ．「Ｃｒｉｔｉｃａｌ ｕｐｄａｔｅ Ｔｒａｃｋｉｎｇ Ｓｕｐｐｏｒｔ」ｆｉｅｌｄ＝１）、ｎｏｎ－ＡＰ ＭＬＤはｍｕｌｔｉ－ｌｉｎｋ ｓｅｔｕｐプロセスにおいてそれがわかる。

ＡＰ ＭＬＤがＣｒｉｔｉｃａｌ ｕｐｄａｔｅ ｔｒａｃｋｉｎｇをサポートする場合は、ｎｏｎ－ＡＰ ＭＬＤのＳＴＡがＣｒｉｔｉｃａｌ ｕｐｄａｔｅに関連した部分情報のみを要求する時にＰｒｏｂｅ ｒｅｑｕｅｓｔ ｆｒａｍｅにＣＳＮ（Ｃｈａｎｇｅ Ｓｅｑｕｅｎｃｅ Ｎｕｍｂｅｒ）情報を含め送信することができる。これを受信したＡＰは現在ＡＰのＣＳＮとＳＴＡから受信したＣＳＮ情報を比較して更新された情報のみを含むＰｒｏｂｅ Ｒｅｓｐｏｎｓｅ ｆｒａｍｅを送信することができる。但し、この場合でもＳＴＡが変更された情報のみではないＡＰのＣｒｉｔｉｃａｌ ｕｐｄａｔｅに関連した全体情報を得たい場合は、Ｃｒｉｔｉｃａｌ ｕｐｄａｔｅに関連した部分情報を要求する時にＰｒｏｂｅ ｒｅｑｕｅｓｔ ｆｒａｍｅにＣＳＮ情報を含めず送信することで獲得したい情報（ＡＰのＣｒｉｔｉｃａｌ ｕｐｄａｔｅに関連した全体情報）を獲得することができる。

ＡＰ ＭＬＤがＣｒｉｔｉｃａｌ ｕｐｄａｔｅ ｔｒａｃｋｉｎｇをサポートしない場合（ｅ．ｇ．「Ｃｒｉｔｉｃａｌ ｕｐｄａｔｅ Ｔｒａｃｋｉｎｇ Ｓｕｐｐｏｒｔ」ｆｉｅｌｄ＝０）には、ｎｏｎ－ＡＰ ＭＬＤのＳＴＡがＣｒｉｔｉｃａｌ ｕｐｄａｔｅに関連した情報のみを要求する時にＰｒｏｂｅ ｒｅｑｕｅｓｔ ｆｒａｍｅにＣＳＮ情報を含め送信しないことができる。これを受信したＡＰは現在ＡＰのＣＳＮに該当する全てのＣｒｉｔｉｃａｌ ｕｐｄａｔｅに関連したｅｌｅｍｅｎｔ情報（又は、別途の指示事項がない場合、要求されたＡＰの全体情報（すなわち、Ｃｏｍｐｌｅｔｅ Ｐｒｏｆｉｌｅ））を含むＰｒｏｂｅ Ｒｅｓｐｏｎｓｅ ｆｒａｍｅを送信することができる。但し、この場合でもＳＴＡがＣｒｉｔｉｃａｌ ｕｐｄａｔｅに関連した部分情報を要求する時にＰｒｏｂｅ ｒｅｑｕｅｓｔ ｆｒａｍｅにＣＳＮ情報を含め送信することもできる。しかしこれを受信したＡＰはＣＳＮ別の更新情報をｔｒａｃｋｉｎｇできないためＰｒｏｂｅ Ｒｅｓｐｏｎｓｅ ｆｒａｍｅに現在のＡＰのＣＳＮに該当する全てのＣｒｉｔｉｃａｌ ｕｐｄａｔｅに関連したｅｌｅｍｅｎｔ情報（又は別途の指示事項がない場合、要求されたＡＰの全体情報（すなわち、Ｃｏｍｐｌｅｔｅ Ｐｒｏｆｉｌｅ））を含め送信することができる。

このように、ＭＬＤに「Ｃｒｉｔｉｃａｌ ｕｐｄａｔｅ Ｔｒａｃｋｉｎｇ Ｓｕｐｐｏｒｔ」ｆｉｅｌｄを定義することで、ｎｏｎ－ＡＰ ＭＬＤがＡＰ ＭＬＤのＣＳＮ別の更新情報ｔｒａｃｋｉｎｇサポート有無がわかれば、ｎｏｎ－ＡＰ ＭＬＤがＣｒｉｔｉｃａｌ ｕｐｄａｔｅに関連した部分情報を要求する時、Ｐｒｏｂｅ ｒｅｑｕｅｓｔ ｆｒａｍｅにＣＳＮ情報を含めるか否かを決定することができるため便利である。

一実施形態によれば、ＡＰ ＭＬＤとｎｏｎ－ＡＰ ＭＬＤはｍｕｌｔｉ－ｌｉｎｋ ｓｅｔｕｐプロセスにおいて又はｍｕｌｔｉ－ｌｉｎｋ ｓｅｔｕｐ以降に、本明細書において提案されたシグナリング方法を介して提案するＩＯＭ方法を活性化させることができる。又、ＡＰ ＭＬＤとｎｏｎ－ＡＰ ＭＬＤはＩＯＭ ｃａｐａｂｉｌｉｔｙ ｅｌｅｍｅｎｔ内の様々なｆｉｅｌｄの値を介して要求する情報範囲及び種類を制限することができる。

一実施形態によれば、上述したＩＯＭシグナリング方法を介してＭＬＤ間の正確な動作交渉（Ｎｅｇｏｔｉａｔｉｏｎ）以降、ＩＯＭ動作が実行できるが、別途のシグナリングプロセスなしにＭＬＤ実装にのしてＩＯＭ動作が実行できる場合もある。これはＡＰ ＭＬＤとｎｏｎ－ＡＰ ＭＬＤの交渉なしにＡＰ ＭＬＤ実装によって又はｎｏｎ－ＡＰ ＭＬＤの実装によって動作することを意味する。

上述した実施形態に基づいて、ＡＰ ＭＬＤ及びｎｏｎ－ＡＰ ＭＬＤが動作することができるが、別途のシグナリング交換なしにＭＬＤがＩＯＭ動作を実行する場合、以下のような制約事項が発生することができる。

１）Ｓｏｌｉｃｉｔｅｄ方法に対する制約事項：もしＡＰ ＭＬＤのＡＰ間にＩｎｆｏ ｓｈａｒｉｎｇがサポートされない場合、ＳＴＡが別のＬｉｎｋに対する情報を要求した場合、応答することができない。

２）Ｕｎｓｏｌｉｃｉｔｅｄ方法に対する制約事項：ＡＰはＬｉｎｋ追加情報が必要なＳＴＡを自ら判断して（ｅ．ｇ．ｂｅａｃｏｎ周期など）別途のメッセージを提供することができる。したがって、ＳＴＡは自身がこの情報を受信するか予め予測することができない。

ＭＬＤが別途のシグナリング方法なしにＩＯＭを実装する場合、動作プロセスが単純になる効果があるが、上述した制約事項が発生できる問題がある。

一実施形態によれば、上述したＩＯＭ ｃａｐａｂｉｌｉｔｙ ｅｌｅｍｅｎｔを使用して実行されるＡＰ ＭＬＤとｎｏｎ－ＡＰ ＭＬＤ間の合意に基づいて、多重リンクに関する情報の要求方法を設定することができる。これとは異なり、Ｓｏｌｉｃｉｔｅｄ方法の場合、ＳＴＡが合意された内容ではない特定の情報を指示して一時的にその情報を獲得したい場合がある。この場合、ｄｙｎａｍｉｃにＳＴＡがｒｅｑｕｅｓｔ ｍｅｓｓａｇｅを送信するとき、指示する内容（例えば、ＩＯＭ ｃａｐａｂｉｌｉｔｙ情報）を含めて要求することもできる。

例えば、Ｍｕｌｔｉ－ｌｉｎｋ ｓｅｔｕｐ時、又はそれ以降、ＡＰ ＭＬＤとｎｏｎ－ＡＰ ＭＬＤが合意して、合意された内容に基づいてＳＴＡがＡＰから情報を提供することもできるが、ＳＴＡが一時的に特定のＡＰの情報又はＡＰの特定のパラメータ情報を要求したい場合がある。この場合、ＳＴＡは情報を要求する時、要求フレーム（ｅ．ｇ．Ｐｒｏｂｅ ｒｅｑｕｅｓｔ ｆｒａｍｅ又は（ｒｅ）ａｓｓｏｃｉａｔｉｏｎ ｆｒａｍｅ又は新規ｆｒａｍｅなど）内「ＩＯＭ ｃａｐａｂｉｌｉｔｙ」ｅｌｅｍｅｎｔに要求を獲得したい情報に対する指示事項を含めて送信することができる。ＡＰは前記要求フレームに基づいて、ＳＴＡが要求を獲得したい情報を含む応答メッセージをＳＴＡに送信／提供することができる。一実施形態によれば、ＩＯＭ ｃａｐａｂｉｌｉｔｙ ｅｌｅｍｅｎｔ内のフィールドが省略された場合は既存合意された内容に基づいて、ＡＰはＳＴＡに情報を提供することができる。

したがって、ＭＬＤ（ＡＰ ＭＬＤ又はｎｏｎ－ＡＰ ＭＬＤ）はｍｕｌｔｉ－ｌｉｎｋ ｓｅｔｕｐプロセス又はその後、上述したｅｌｅｍｅｎｔを使用してＡＰ ＭＬＤとｎｏｎ－ＡＰ ＭＬＤ間のｎｅｇｏｔｉａｔｉｏｎを実行することができる。ｎｏｎ－ＡＰ ＭＬＤは前記ｎｅｇｏｔｉａｔｉｏｎに基づいて、提供される情報（又は、受信する情報）に対して合意を実行し、これを受信することができる。又、ＳＴＡは要求メッセージに要求される情報に対する指示事項を含めて送信することで一時的に要求した情報に対してのみ受信することもできる。但し、要求メッセージに特別な指示事項が省略された場合、基本的に合意された指示事項に基づいて、ｎｏｎ－ＡＰ ＭＬＤ及びＡＰ ＭＬＤが動作することができる。

一実施形態によれば、ｍｕｌｔｉ－ｌｉｎｋ ｓｅｔｕｐ完了以降、合意内容の変更したい場合、ｎｏｎ－ＡＰ ＭＬＤ及びＡＰ ＭＬＤは別途のメッセージ交換を介してＭＬＤ間の合意内容を更新することもできる。

ＢＳＳパラメータの重要更新に対する手順は以下のように説明する。

ＡＰ ＭＬＤのＡＰが多重ＢＳＳ ＩＤに属しないか、前記ＡＰが多重ＢＳＳ ＩＤセット内ｔｒａｎｓｍｉｔｔｅｄ ＢＳＳ ＩＤに対応する場合、前記ＡＰは同じＡＰ ＭＬＤに属した全てのＡＰそれぞれに対するＢＰＣＣ（ＢＳＳ ｐａｒａｍｅｔｅｒ Ｃｈａｎｇｅ Ｃｏｕｎｔ）サブフィールドをビーコン及びプローブ応答フレームに含めて送信する。

各ＡＰのＢＰＣＣサブフィールドの値は０に初期化され、ＡＰに対する動作的パラメータに対して重要更新（Ｃｒｉｔｉｃａｌ ｕｐｄａｔｅ）が発生する場合増分する必要がある（ｍｏｄｕｌｏ２５６）。

ＡＰ ＭＬＤの別のＡＰそれぞれに対するＢＰＣＣサブフィールドは前記ＡＰに対応するＲＮＲ（Ｒｅｄｕｃｅｄ Ｎｅｉｇｈｂｏｒ Ｒｅｐｏｒｔ）ｅｌｅｍｅｎｔのＴＢＴＴ（Ｔａｒｇｅｔ Ｂｅａｃｏｎ Ｔｒａｎｓｍｉｓｓｉｏｎ Ｔｉｍｅ）ＩｎｆｏｒｍａｔｉｏｎフィールドのＭＬＤ Ｐａｒａｍｅｔｅｒｓサブフィールドにおいて転送される必要がある。

前記ＡＰに対するＢＰＣＣサブフィールドはＢａｓｉｃ Ｍｕｌｔｉ－Ｌｉｎｋ ｅｌｅｍｅｎｔのＣｏｍｍｏｎ ｉｎｆｏフィールドにおいて転送される必要がある。

前記ＡＰはビーコン及びプローブ応答フレームのＣａｐａｂｉｌｉｔｙ ＩｎｆｏｒｍａｔｉｏｎフィールドのＣｒｉｔｉｃａｌ ｕｐｄａｔｅ Ｆｌａｇサブフィールドを提供し、同じＡＰ ＭＬＤのどのＡＰに対するＲＮＲ ｅｌｅｍｅｎｔのＭＬＤ ＰａｒａｍｅｔｅｒｓフィールドのＢＰＣＣサブフィールドにおいて転送される値（又は、Ｂａｓｉｃ Ｍｕｌｔｉ－Ｌｉｎｋ ｅｌｅｍｅｎｔのＣｏｍｍｏｎ ｉｎｆｏフィールドのＢＰＣＣサブフィールドにおいて転送される値）に対する更新インジケーターを送信する。

同じＡＰ ＭＬＤのあるＡＰに対するＲＮＲ ｅｌｅｍｅｎｔのＭＬＤ ＰａｒａｍｅｔｅｒｓフィールドのＢＰＣＣサブフィールドにおいて転送される値（又は、Ｂａｓｉｃ Ｍｕｌｔｉ－Ｌｉｎｋ ｅｌｅｍｅｎｔのＣｏｍｍｏｎ ｉｎｆｏフィールドのＢＰＣＣサブフィールドにおいて転送される値）に変化がある場合、前記ＡＰはビーコンフレーム内Ｃａｐａｂｉｌｉｔｙ ＩｎｆｏｒｍａｔｉｏｎフィールドのＣｒｉｔｉｃａｌ ｕｐｄａｔｅ Ｆｌａｇサブフィールドを１に設定してＡＰが動作するリンクに対するｎｅｘｔ ＤＴＩＭビーコンフレームを含める。

それ以外の場合、ＡＰはＣａｐａｂｉｌｉｔｙ ＩｎｆｏｒｍａｔｉｏｎフィールドのＣｒｉｔｉｃａｌ ｕｐｄａｔｅ Ｆｌａｇサブフィールドを１に設定する。

ｎｏｎ－ＡＰ ＭＬＤはｍｕｌｔｉ－ｌｉｎｋ設定があるＡＰ ＭＬＤの各ＡＰに対して最近受信されたＢＰＣＣサブフィールドの値の記録を維持する必要がある。

以下では、図１から図６４を参照して、上述した実施形態を説明する。

図６５は本実施形態に係る送信ＭＬＤが受信ＭＬＤにプローブ応答フレームに基づいてＡＰの部分情報を提供する手順を示したフロー図である。

図６５の一例は次世代無線ＬＡＮシステム（ＩＥＥＥ８０２．１１ｂｅ又は、ＥＨＴ無線ＬＡＮシステム）がサポートされるネットワーク環境において実行される。前記次世代無線ＬＡＮシステムは８０２．１１ａｘシステムを改善した無線ＬＡＮシステムとして８０２．１１ａｘシステムと下位互換性（ｂａｃｋｗａｒｄｃｏｍｐａｔｉｂｉｌｉｔｙ）を満たすことができる。

本実施形態はＭＬＤ通信においてｎｏｎ－ＡＰ ＳＴＡがプローブ要求フレームを介してｐｅｅｒ ＡＰではない別のＡＰに対する部分情報を要求する場合、前記プローブ要求フレームの多重リンク要素に要求要素（Ｒｅｑｕｅｓｔ ｅｌｅｍｅｎｔ）を含め、前記要求要素に基づいて特定のＡＰに対する部分情報を要求する方法及び装置を提案する。ここで、送信ＭＬＤはＡＰ ＭＬＤに対応し、受信ＭＬＤはｎｏｎ－ＡＰ ＭＬＤに対応する。ｎｏｎ－ＡＰ ＳＴＡが第１受信ＳＴＡだとすれば、前記第１受信ＳＴＡと第１リンクに接続された第１送信ＳＴＡがｐｅｅｒ ＡＰであると言うことができ、別のリンクに接続された第２及び第３送信ＳＴＡは別のＡＰであるということができる。

Ｓ６５１０ステップにおいて、送信ＭＬＤ（Ｍｕｌｔｉ－ｌｉｎｋ Ｄｅｖｉｃｅ）は受信ＭＬＤから第１リンクを介してプローブ要求フレームを受信する。

Ｓ６５２０ステップにおいて、前記送信ＭＬＤは前記受信ＭＬＤに前記第１リンクを介してプローブ応答フレームを送信する。

前記送信ＭＬＤは前記第１リンクにおいて動作する第１送信ＳＴＡ（ｓｔａｔｉｏｎ）及び第２リンクにおいて動作する第２送信ＳＴＡを含む。前記受信ＭＬＤは前記第１リンクにおいて動作する第１受信ＳＴＡ及び前記第２リンクにおいて動作する第２受信ＳＴＡを含む。

前記プローブ要求フレームは前記第２受信ＳＴＡのプロファイルフィールドを含む。前記第２受信ＳＴＡのプロファイルフィールドは第１全体情報プロファイルサブフィールドを含む。

前記第１受信ＳＴＡが前記第２リンクに対する部分情報を要求する場合、前記第１全体情報プロファイルサブフィールドの値は０に設定される。前記第２受信ＳＴＡのプロファイルフィールドは第１要求要素（Ｒｅｑｕｅｓｔ ｅｌｅｍｅｎｔ）をさらに含む。このとき、前記第２リンクに対する部分情報は前記第１要求要素に基づいて要求される。

前記第１受信ＳＴＡが前記第２リンクに対する全体情報を要求する場合、前記第１全体情報プロファイルサブフィールドの値は１に設定することができる。前記第２受信ＳＴＡのプロファイルフィールドは前記第１要求要素を含まない場合がある。このとき、前記第２リンクに対する全体情報は前記第２受信ＳＴＡのプロファイルフィールドに基づいて要求される。

すなわち、前記プローブ応答フレームは前記第１全体情報プロファイルサブフィールドの値及び／又は前記第１要求要素に基づいて構成される。前記第１全体情報プロファイルサブフィールドの値が０である場合、前記受信ＭＬＤは前記プローブ要求フレームに前記第１要求要素に基づいて前記第２リンクに対する部分情報を要求することができ、前記送信ＭＬＤは前記プローブ応答フレームに前記第２リンクに対する部分情報を含めて転送することができる。前記第１全体情報プロファイルサブフィールドの値が１である場合、前記受信ＭＬＤは前記第２受信ＳＴＡのプロファイルフィールドのみで前記第２リンクに対する全体情報を要求することができ、前記送信ＭＬＤは前記プローブ応答フレームに前記第２リンクに対する全体情報を含めて転送することができる。

又、前記受信ＭＬＤは前記送信ＭＬＤ内の複数のＡＰに対する部分情報を要求することができる。

前記送信ＭＬＤは第３リンクにおいて動作する第３送信ＳＴＡをさらに含むことができる。前記受信ＭＬＤは前記第３リンクにおいて動作する第３受信ＳＴＡをさらに含むことができる。

前記プローブ要求フレームは前記第３受信ＳＴＡのプロファイルフィールドをさらに含むことができる。前記第３受信ＳＴＡのプロファイルフィールドは第２全体情報プロファイルサブフィールドを含むことができる。

前記第１受信ＳＴＡが前記第３リンクに対する部分情報を要求する場合、前記第２全体情報プロファイルサブフィールドの値は０に設定することができる。前記第３受信ＳＴＡのプロファイルフィールドは第２要求要素をさらに含むことができる。このとき、前記第３リンクに対する部分情報は前記第２要求要素に基づいて要求される。

前記第１受信ＳＴＡが前記第３リンクに対する全体情報を要求する場合、前記第２全体情報プロファイルサブフィールドの値は１に設定することができる。前記第３受信ＳＴＡのプロファイルフィールドは前記第２要求要素を含まない場合がある。このとき、前記第３リンクに対する全体情報は前記第３受信ＳＴＡのプロファイルフィールドに基づいて要求される。

同様に、前記プローブ応答フレームは前記第２全体情報プロファイルサブフィールドの値及び／又は前記第２要求要素に基づいて構成される。前記第２全体情報プロファイルサブフィールドの値が０である場合、前記受信ＭＬＤは前記プローブ要求フレームに前記第２要求要素に基づいて前記第３リンクに対する部分情報を要求することができ、前記送信ＭＬＤは前記プローブ応答フレームに前記第３リンクに対する部分情報を含めて転送することができる。前記第２全体情報プロファイルサブフィールドの値が１である場合、前記受信ＭＬＤは前記第３受信ＳＴＡのプロファイルフィールドのみで前記第３リンクに対する全体情報を要求することができ、前記送信ＭＬＤは前記プローブ応答フレームに前記第３リンクに対する全体情報を含めて転送することができる。

もし、前記プローブ要求フレームに前記第１及び第２要求要素が全て含まれる場合、前記プローブ応答フレームは前記第１及び第２全体情報プロファイルサブフィールドの値と前記第１及び第２要求要素に基づいて構成される。

又、前記プローブ要求フレームは第３要求要素及び多重リンク要素（ｍｕｌｔｉ－ｌｉｎｋ ｅｌｅｍｅｎｔ）を含むことができる。前記第１受信ＳＴＡが前記第１リンクに対する部分情報を要求する場合、前記第１リンクに対する部分情報は前記第３要求要素に基づいて要求される。前記第２及び第３受信ＳＴＡのプロファイルフィールドは前記多重リンク要素に含まれる。すなわち、ＭＬＤ通信においてｎｏｎ－ＡＰ ＳＴＡはｐｅｅｒ ＡＰに対する部分情報の要求は多重リンク要素に含まれない要求要素を介してすることができ、前記ｐｅｅｒ ＡＰではない別のＡＰに対する部分情報の要求は前記多重リンク要素を介してできる。

又、前記第１要求要素は前記第２リンクに対する部分情報を指示する第１識別子の情報を含むことができる。前記第２要求要素は前記第３リンクに対する部分情報を指示する第２識別子の情報を含むことができる。前記第１識別子の情報を介して前記第２リンクに対する部分情報のｅｌｅｍｅｎｔを分けることができる。前記第２識別子の情報を介して前記第３リンクに対する部分情報のｅｌｅｍｅｎｔも分けることができる。

すなわち、本実施形態は上述した多重リンク要素に含まれた各受信ＳＴＡのプロファイルフィールドに要求要素を含めるか否かに対するインジケーターを設定し、前記要求要素に基づいて特定のＡＰに対する部分情報を要求する方法を提案する。これで、ＡＰ ＭＬＤは前記全体情報プロファイルサブフィールドを復号して前記各受信ＳＴＡのプロファイルフィールドに前記要求要素が含まれているか確認し、前記要求要素において要求された部分情報を確認してプローブ応答フレームに当該部分情報を含むことができる。これで、ｎｏｎ－ＡＰ ＭＬＤは別のリンクに対して常に全体情報ではない部分情報も要求することができ、そのためフレームオーバーヘッドを減らせる効果がある。

図６６は本実施形態に係る受信ＭＬＤが送信ＭＬＤにプローブ要求フレームに基づいてＡＰの部分情報を要求する手順を示したフロー図である。

図６６の一例は次世代無線ＬＡＮシステム（ＩＥＥＥ８０２．１１ｂｅ又は、ＥＨＴ無線ＬＡＮシステム）がサポートされるネットワーク環境において実行される。前記次世代無線ＬＡＮシステムは８０２．１１ａｘシステムを改善した無線ＬＡＮシステムとして８０２．１１ａｘシステムと下位互換性（ｂａｃｋｗａｒｄｃｏｍｐａｔｉｂｉｌｉｔｙ）を満たすことができる。

本実施形態はＭＬＤ通信においてｎｏｎ－ＡＰ ＳＴＡがプローブ要求フレームを介してｐｅｅｒ ＡＰではない別のＡＰに対する部分情報を要求する場合、前記プローブ要求フレームの多重リンク要素に要求要素（Ｒｅｑｕｅｓｔ ｅｌｅｍｅｎｔ）を含め、前記要求要素に基づいて特定のＡＰに対する部分情報を要求する方法及び装置を提案する。ここで、送信ＭＬＤはＡＰ ＭＬＤに対応し、受信ＭＬＤはｎｏｎ－ＡＰ ＭＬＤに対応する。ｎｏｎ－ＡＰ ＳＴＡが第１受信ＳＴＡだとすれば、前記第１受信ＳＴＡと第１リンクに接続された第１送信ＳＴＡがｐｅｅｒ ＡＰであると言うことができ、別のリンクに接続された第２及び第３送信ＳＴＡは別のＡＰであると言うことができる。

Ｓ６６１０ステップにおいて、受信ＭＬＤ（Ｍｕｌｔｉ－ｌｉｎｋ Ｄｅｖｉｃｅ）は送信ＭＬＤに第１リンクを介してプローブ要求フレームを送信する。

Ｓ６６２０ステップにおいて、前記受信ＭＬＤは前記送信ＭＬＤから前記第１リンクを介してプローブ応答フレームを受信する。

前記送信ＭＬＤは前記第１リンクにおいて動作する第１送信ＳＴＡ（ｓｔａｔｉｏｎ）及び第２リンクにおいて動作する第２送信ＳＴＡを含む。前記受信ＭＬＤは前記第１リンクにおいて動作する第１受信ＳＴＡ及び前記第２リンクにおいて動作する第２受信ＳＴＡを含む。

前記プローブ要求フレームは前記第２受信ＳＴＡのプロファイルフィールドを含む。前記第２受信ＳＴＡのプロファイルフィールドは第１全体情報プロファイルサブフィールドを含む。

前記第１受信ＳＴＡが前記第２リンクに対する部分情報を要求する場合、前記第１全体情報プロファイルサブフィールドの値は０に設定される。前記第２受信ＳＴＡのプロファイルフィールドは第１要求要素（Ｒｅｑｕｅｓｔ ｅｌｅｍｅｎｔ）をさらに含む。このとき、前記第２リンクに対する部分情報は前記第１要求要素に基づいて要求される。

前記第１受信ＳＴＡが前記第２リンクに対する全体情報を要求する場合、前記第１全体情報プロファイルサブフィールドの値は１に設定することができる。前記第２受信ＳＴＡのプロファイルフィールドは前記第１要求要素を含まない場合がある。このとき、前記第２リンクに対する全体情報は前記第２受信ＳＴＡのプロファイルフィールドに基づいて要求される。

すなわち、前記プローブ応答フレームは前記第１全体情報プロファイルサブフィールドの値及び／又は前記第１要求要素に基づいて構成される。前記第１全体情報プロファイルサブフィールドの値が０である場合、前記受信ＭＬＤは前記プローブ要求フレームに前記第１要求要素に基づいて前記第２リンクに対する部分情報を要求することができ、前記送信ＭＬＤは前記プローブ応答フレームに前記第２リンクに対する部分情報を含めて転送することができる。前記第１全体情報プロファイルサブフィールドの値が１である場合、前記受信ＭＬＤは前記第２受信ＳＴＡのプロファイルフィールドのみで前記第２リンクに対する全体情報を要求することができ、前記送信ＭＬＤは前記プローブ応答フレームに前記第２リンクに対する全体情報を含めて転送することができる。

又、前記受信ＭＬＤは前記送信ＭＬＤ内の複数のＡＰに対する部分情報を要求することができる。

前記送信ＭＬＤは第３リンクにおいて動作する第３送信ＳＴＡをさらに含むことができる。前記受信ＭＬＤは前記第３リンクにおいて動作する第３受信ＳＴＡをさらに含むことができる。

前記プローブ要求フレームは前記第３受信ＳＴＡのプロファイルフィールドをさらに含むことができる。前記第３受信ＳＴＡのプロファイルフィールドは第２全体情報プロファイルサブフィールドを含むことができる。

前記第１受信ＳＴＡが前記第３リンクに対する部分情報を要求する場合、前記第２全体情報プロファイルサブフィールドの値は０に設定することができる。前記第３受信ＳＴＡのプロファイルフィールドは第２要求要素をさらに含むことができる。このとき、前記第３リンクに対する部分情報は前記第２要求要素に基づいて要求される。

前記第１受信ＳＴＡが前記第３リンクに対する全体情報を要求する場合、前記第２全体情報プロファイルサブフィールドの値は１に設定することができる。前記第３受信ＳＴＡのプロファイルフィールドは前記第２要求要素を含まない場合がある。このとき、前記第３リンクに対する全体情報は前記第３受信ＳＴＡのプロファイルフィールドに基づいて要求される。

同様に、前記プローブ応答フレームは前記第２全体情報プロファイルサブフィールドの値及び／又は前記第２要求要素に基づいて構成される。前記第２全体情報プロファイルサブフィールドの値が０である場合、前記受信ＭＬＤは前記プローブ要求フレームに前記第２要求要素に基づいて前記第３リンクに対する部分情報を要求することができ、前記送信ＭＬＤは前記プローブ応答フレームに前記第３リンクに対する部分情報を含めて転送することができる。前記第２全体情報プロファイルサブフィールドの値が１である場合、前記受信ＭＬＤは前記第３受信ＳＴＡのプロファイルフィールドのみで前記第３リンクに対する全体情報を要求することができ、前記送信ＭＬＤは前記プローブ応答フレームに前記第３リンクに対する全体情報を含めて転送することができる。

もし、前記プローブ要求フレームに前記第１及び第２要求要素が全て含まれる場合、前記プローブ応答フレームは前記第１及び第２全体情報プロファイルサブフィールドの値と前記第１及び第２要求要素に基づいて構成される。

又、前記プローブ要求フレームは第３要求要素及び多重リンク要素（ｍｕｌｔｉ－ｌｉｎｋ ｅｌｅｍｅｎｔ）を含むことができる。前記第１受信ＳＴＡが前記第１リンクに対する部分情報を要求する場合、前記第１リンクに対する部分情報は前記第３要求要素に基づいて要求される。前記第２及び第３受信ＳＴＡのプロファイルフィールドは前記多重リンク要素に含まれる。すなわち、ＭＬＤ通信においてｎｏｎ－ＡＰ ＳＴＡはｐｅｅｒ ＡＰに対する部分情報の要求は多重リンク要素に含まれない要求要素を介してすることができ、前記ｐｅｅｒ ＡＰではない別のＡＰに対する部分情報の要求は前記多重リンク要素を介してできる。

又、前記第１要求要素は前記第２リンクに対する部分情報を指示する第１識別子の情報を含むことができる。前記第２要求要素は前記第３リンクに対する部分情報を指示する第２識別子の情報を含むことができる。前記第１識別子の情報を介して前記第２リンクに対する部分情報のｅｌｅｍｅｎｔを分けることができる。前記第２識別子の情報を介して前記第３リンクに対する部分情報のｅｌｅｍｅｎｔも分けることができる。

すなわち、本実施形態は上述した多重リンク要素に含まれた各受信ＳＴＡのプロファイルフィールドに要求要素を含めるか否かに対するインジケーターを設定し、前記要求要素に基づいて特定のＡＰに対する部分情報を要求する方法を提案する。これで、ＡＰ ＭＬＤは前記全体情報プロファイルサブフィールドを復号して前記各受信ＳＴＡのプロファイルフィールドに前記要求要素が含まれているか確認し、前記要求要素において要求された部分情報を確認してプローブ応答フレームに当該部分情報を含むことができる。これで、ｎｏｎ－ＡＰ ＭＬＤは別のリンクに対して常に全体情報ではない部分情報も要求することができそのためフレームオーバーヘッドを減らせる効果がある。

上述した本明細書の技術的な特徴は様々な装置及び方法に適用される。例えば、上述した本明細書の技術的な特徴は図１及び／又は図１１の装置を介して実行／サポートされる。例えば、上述した本明細書の技術的な特徴は、図１及び／又は図１１の一部にのみ適用される。例えば、上述した本明細書の技術的な特徴は、図１の処理チップ１１４、１２４に基づいて実装されるか、図１のプロセッサ１１１、１２１とメモリ１１２、１２２に基づいて実装されるか、図１１のプロセッサ６１０とメモリ６２０に基づいて実装される。例えば、本明細書の装置は、送信ＭＬＤに第１リンクを介してプローブ要求フレームを送信し、前記送信ＭＬＤから前記第１リンクを介してプローブ応答フレームを受信する。

本明細書の技術的な特徴はＣＲＭ（ｃｏｍｐｕｔｅｒ ｒｅａｄａｂｌｅ ｍｅｄｉｕｍ）に基づいて実装される。例えば、本明細書によって提案されるＣＲＭは少なくとも１つのプロセッサ（ｐｒｏｃｅｓｓｏｒ）によって実行されることに基づく命令（ｉｎｓｔｒｕｃｔｉｏｎ）を含む少なくとも１つのコンピューター可読記録媒体（ｃｏｍｐｕｔｅｒ ｒｅａｄａｂｌｅ ｍｅｄｉｕｍ）である。

前記ＣＲＭは、送信ＭＬＤに第１リンクを介してプローブ要求フレームを送信するステップと、前記送信ＭＬＤから前記第１リンクを介してプローブ応答フレームを受信するステップを含む動作（ｏｐｅｒａｔｉｏｎｓ）を実行する命令（ｉｎｓｔｒｕｃｔｉｏｎｓ）を格納することができる。本明細書のＣＲＭ内に格納される命令は少なくとも１つのプロセッサによって実行（ｅｘｅｃｕｔｅ）される。本明細書のＣＲＭに関連された少なくとも１つのプロセッサは図１のプロセッサ１１１、１２１又は処理チップ１１４、１２４であるか、図１１のプロセッサ６１０である。その一方で、本明細書のＣＲＭは図１のメモリ１１２、１２２であるか図１１のメモリ６２０であるか、別途の外部メモリ／記憶媒体／ディスクなどである。

上述した本明細書の技術的な特徴は様々なアプリケーション（ａｐｐｌｉｃａｔｉｏｎ）やビジネスモデルに適用可能である。例えば、人工知能（Ａｒｔｉｆｉｃｉａｌ Ｉｎｔｅｌｌｉｇｅｎｃｅ：ＡＩ）をサポートする装置での無線通信のために上述した技術的な特徴が適用される。

人工知能は人工的な知能またはこれを作る方法論を研究する分野を意味し、機械学習（Ｍａｃｈｉｎｅ Ｌｅａｒｎｉｎｇ）は人工知能分野において扱う様々な問題を定義し、それを解決する方法論を研究する分野を意味する。機械学習はある作業に対して継続的な経験を介してその作業に対する性能を高めるアルゴリズムと定義することもある。

人工ニューラルネットワーク（人工ニューラルネットワーク；ＡＮＮ）は機械学習において用いられるモデルとして、シナプスの結合にネットワークを形成した人工ニューロン（ノード）で構成される、問題解決能力を持つモデル全般を意味する。人工ニューラルネットワークは他のレイヤーのニューロンの間の接続パターン、モデルパラメータを更新する学習過程、出力値を生成する活性化関数（Ａｃｔｉｖａｔｉｏｎ Ｆｕｎｃｔｉｏｎ）によって定義される。

人工ニューラルネットワークは入力層（Ｉｎｐｕｔ Ｌａｙｅｒ）、出力層（Ｏｕｔｐｕｔ Ｌａｙｅｒ）、そして選択的に一つ以上の隠れ層（Ｈｉｄｄｅｎ Ｌａｙｅｒ）を含むことができる。各層は一つ以上のニューロンを含み、人工ニューラルネットワークはニューロンとニューロンを接続するシナプスを含むことができる。人工ニューラルネットワークにおいて各ニューロンはシナプスを介して入力される入力信号、加重値、偏向に対する活性化関数の関数値を出力することができる。

モデルパラメータは学習を介して決定されるパラメータを意味し、シナプス接続の加重値とニューロンの偏向などが含まれる。そして、ハイパーパラメータは機械学習アルゴリズムにおいて学習前に設定する必要があるパラメータを意味し、学習率（Ｌｅａｒｎｉｎｇ Ｒａｔｅ）、繰り返し回数、ミニバッチサイズ、初期化関数などが含まれる。

人工ニューラルネットワークの学習の目的は損失関数を最小化するモデルパラメータを決定することである。損失関数は人工ニューラルネットワークの学習過程において最適のモデルパラメータを決定するための指標として用いられる。

機械学習は学習方法によって教師あり学習（Ｓｕｐｅｒｖｉｓｅｄ Ｌｅａｒｎｉｎｇ）、教師なし学習（Ｕｎｓｕｐｅｒｖｉｓｅｄ Ｌｅａｒｎｉｎｇ）、強化学習（Ｒｅｉｎｆｏｒｃｅｍｅｎｔ Ｌｅａｒｎｉｎｇ）として分類することができる。

教師あり学習は学習データに対するラベル（ｌａｂｅｌ）が与えられた状態において人工ニューラルネットワークを学習させる方法を意味し、ラベルという学習データが人工ニューラルネットワークに入力される場合、人工ニューラルネットワークが推論する必要がある正解（または、結果値）を意味する。教師なし学習は学習データに対するラベルが与えられない状態において人工ニューラルネットワークを学習させる方法を意味する。強化学習はある環境内において定義されたエージェントが各状態において累積報酬を最大化する行動または行動順序を選択するように学習させる学習方法を意味する。

人工ニューラルネットワークのうち、複数の隠れ層を含む深層ニューラルネットワーク（ＤＮＮ：Ｄｅｅｐ Ｎｅｕｒａｌ Ｎｅｔｗｏｒｋ）として実装される機械学習を深層学習（Ｄｅｅｐ Ｌｅａｒｎｉｎｇ）とも呼び、深層学習は機械学習の一部である。以下で、機械学習は深層学習を含む意味として使用される。

また、上述した技術的な特徴はロボットの無線通信に適用される。

ロボットは自ら保有した能力によって与えられた仕事を自動に処理するか、作動する機械を意味する。特に、環境を認識し自ら判断して動作を実行する機能を持つロボットを知能型ロボットと称する。

ロボットは使用目的や分野によって産業用、医療用、家庭用、軍事用などで分類できる。ロボットはアクチュエータまたはモータを含む駆動部を備えロボット関節を動かすなどの様々な物理動作を実行することができる。また、移動可能なロボットは駆動部にホイール、ブレーキ、プロペラなどが含まれ、駆動部を介して地上で走行するか空中で飛行することができる。

また、上述した技術的な特徴は拡張現実をサポートする装置に適用される。

拡張現実は仮想現実（ＶＲ：Ｖｉｒｔｕａｌ Ｒｅａｌｉｔｙ）、拡張現実（ＡＲ：Ａｕｇｍｅｎｔｅｄ Ｒｅａｌｉｔｙ）、複合現実（ＭＲ：Ｍｉｘｅｄ Ｒｅａｌｉｔｙ）を総称する。ＶＲ技術は現実世界のオブジェクトや背景などをＣＧ映像としてのみ提供し、ＡＲ技術は実際の物体映像上に仮想として作られたＣＧ映像をともに提供し、ＭＲ技術は現実世界に仮想物体をミックスして、且つ、結合させて提供するコンピューターグラフィックス技術である。

ＭＲ技術は仮想物体と仮想物体を一緒に見せるという点でＡＲ技術と似ている。しかし、ＡＲ技術では仮想物体が仮想物体を補完する形で用いられる一方、ＭＲ技術では仮想物体と仮想物体が同等な性格で使用されるという点で違いがある。

ＸＲ技術はＨＭＤ（Ｈｅａｄ－Ｍｏｕｎｔ Ｄｉｓｐｌａｙ）、ＨＵＤ（Ｈｅａｄ－Ｕｐ Ｄｉｓｐｌａｙ）、携帯電話、タブレットＰＣ、ノートパソコン、デスクトップ、ＴＶ、デジタルサイネージなどに適用され、ＸＲ技術が適用された装置をＸＲ装置（ＸＲ Ｄｅｖｉｃｅ）と称することができる。

本明細書に記載された請求項は様々な方法に組み合わせることができる。例えば、本明細書の方法請求項の技術的な特徴を組み合わせて装置に実装され、本明細書の装置請求項の技術的な特徴を組み合わせて方法として実装される。また、本明細書の方法請求項の技術的な特徴と装置請求項の技術的な特徴を組み合わせて装置に実装され、本明細書の方法請求項の技術的な特徴と装置請求項の技術的な特徴を組み合わせて方法として実装される。

Claims (14)

1. ＷＬＡＮ（wireless local area network）システムにおける方法であって、
   第１ｎｏｎ－ＡＰ（non-access point） ＳＴＡ（station）が第１ＡＰにマルチリンクプローブ要求フレームを送信するステップと、
   前記第１ｎｏｎ－ＡＰ ＳＴＡが前記第１ＡＰからマルチリンクプローブ応答フレームを受信するステップと、を含み、
   第１リンク上で動作する前記第１ＡＰ及び第２リンク上で動作する第２ＡＰは、ＡＰ ＭＬＤ（multi-link device）に所属し、
   前記第１リンク上で動作する前記第１ｎｏｎ－ＡＰ ＳＴＡ及び前記第２リンク上で動作する第２ｎｏｎ－ＡＰ ＳＴＡは、ｎｏｎ－ＡＰ ＭＬＤに所属し、
   前記マルチリンクプローブ要求フレームは、前記第２ＡＰに対するＰｅｒ－ＳＴＡ Ｐｒｏｆｉｌｅサブフィールドを運び、
   前記第２ＡＰに対する前記Ｐｅｒ－ＳＴＡ Ｐｒｏｆｉｌｅサブフィールドは、第１ＳＴＡ Ｃｏｎｔｒｏｌフィールドの第１全体情報プロファイルサブフィールドを含み、
   前記第１ｎｏｎ－ＡＰ ＳＴＡが前記第２ＡＰに関する部分情報を要求することを可能にする前記マルチリンクプローブ要求フレームに基づいて、
   前記第２ＡＰに対する前記Ｐｅｒ－ＳＴＡ Ｐｒｏｆｉｌｅサブフィールドは、第１要求要素を更に含み、
   前記第１全体情報プロファイルサブフィールドの値は、０に設定され、且つ、
   前記第２ＡＰに関する前記部分情報は、前記第１要求要素に基づいて要求され、
   前記第１ｎｏｎ－ＡＰ ＳＴＡが前記第２ＡＰに関する全体情報を要求することを可能にする前記マルチリンクプローブ要求フレームに基づいて、
   前記第１全体情報プロファイルサブフィールドの値は、１に設定され、
   前記第２ＡＰに対する前記Ｐｅｒ－ＳＴＡ Ｐｒｏｆｉｌｅサブフィールドは、前記第１要求要素を含まず、且つ、
   前記第２ＡＰに関する前記全体情報は、前記第２ＡＰに対する前記Ｐｅｒ－ＳＴＡ Ｐｒｏｆｉｌｅサブフィールドに基づいて要求される、方法。
2. 第３リンク上で動作する第３ＡＰが前記ＡＰ ＭＬＤに更に所属し、
   前記第３リンク上で動作する第３ｎｏｎ－ＡＰ ＳＴＡが前記ｎｏｎ－ＡＰ ＭＬＤに更に所属し、
   前記マルチリンクプローブ要求フレームは、前記第３ＡＰに対するＰｅｒ－ＳＴＡ Ｐｒｏｆｉｌｅサブフィールドを更に含み、
   前記第３ＡＰに対する前記Ｐｅｒ－ＳＴＡ Ｐｒｏｆｉｌｅサブフィールドは、第２ＳＴＡ Ｃｏｎｔｒｏｌフィールドの第２全体情報プロファイルサブフィールドを含む、請求項１に記載の方法。
3. 前記第１ｎｏｎ－ＡＰ ＳＴＡが前記第３ＡＰに関する部分情報を要求することに基づいて、前記第２全体情報プロファイルサブフィールドの値は、０に設定され、前記第３ＡＰに対する前記Ｐｅｒ－ＳＴＡ Ｐｒｏｆｉｌｅサブフィールドは、第２要求要素を更に含み、
   前記第３ＡＰに関する部分情報は、前記第２要求要素に基づいて要求される、請求項２に記載の方法。
4. 前記第１ｎｏｎ－ＡＰ ＳＴＡが前記第３ＡＰに関する全体情報を要求することに基づいて、前記第２全体情報プロファイルサブフィールドの値は、１に設定され、前記第３ＡＰに対する前記Ｐｅｒ－ＳＴＡ Ｐｒｏｆｉｌｅサブフィールドは、第２要求要素を含まず、
   前記第３ＡＰに関する前記全体情報は、前記第３ＡＰに対する前記Ｐｅｒ－ＳＴＡ Ｐｒｏｆｉｌｅサブフィールドに基づいて要求される、請求項２に記載の方法。
5. 前記マルチリンクプローブ要求フレームは、第３要求要素及びマルチリンク要素を含み、
   前記第１ｎｏｎ－ＡＰ ＳＴＡが前記第１ＡＰに関する部分情報を要求することに基づいて、前記第１ＡＰに関する部分情報は、前記第３要求要素に基づいて要求され、
   前記第２ＡＰに対する前記Ｐｅｒ－ＳＴＡ Ｐｒｏｆｉｌｅサブフィールド及び第３ＡＰに対する前記Ｐｅｒ－ＳＴＡ Ｐｒｏｆｉｌｅサブフィールドは、前記マルチリンク要素に含まれる、請求項１に記載の方法。
6. 前記第１要求要素は、前記第２ＡＰに関する前記部分情報を指示する第１識別子情報を含み、
   前記第２要求要素は、前記第３ＡＰに関する部分情報を指示する第２識別子情報を含み、
   前記マルチリンクプローブ応答フレームは、前記第１全体情報プロファイルサブフィールド及び前記第２全体情報プロファイルサブフィールドの前記値と、前記第１要求要素及び前記第２要求要素とに基づいて構成される、請求項３に記載の方法。
7. ＷＬＡＮ（wireless local area network）システムにおける第１ｎｏｎ－ＡＰ（non-access point） ＳＴＡ（station）であって、
   メモリと、
   送受信機と、
   前記メモリ及び前記送受信機と動作できるように結合されたプロセッサと、を含み、
   プロセッサは、
   第１ＡＰにマルチリンクプローブ要求フレームを送信し、
   前記第１ＡＰからマルチリンクプローブ応答フレームを受信する、ように構成され、
   第１リンク上で動作する前記第１ＡＰ及び第２リンク上で動作する第２ＡＰは、ＡＰ ＭＬＤ（multi-link device）に所属し、
   前記第１リンク上で動作する前記第１ｎｏｎ－ＡＰ ＳＴＡ及び前記第２リンク上で動作する第２ｎｏｎ－ＡＰ ＳＴＡは、ｎｏｎ－ＡＰ ＭＬＤに所属し、
   前記マルチリンクプローブ要求フレームは、前記第２ＡＰに対するＰｅｒ－ＳＴＡ Ｐｒｏｆｉｌｅサブフィールドを運び、
   前記第２ＡＰに対する前記Ｐｅｒ－ＳＴＡ Ｐｒｏｆｉｌｅサブフィールドは、第１ＳＴＡ Ｃｏｎｔｒｏｌフィールドの第１全体情報プロファイルサブフィールドを含み、
   前記第１ｎｏｎ－ＡＰ ＳＴＡが前記第２ＡＰに関する部分情報を要求することを可能にする前記マルチリンクプローブ要求フレームに基づいて、
   前記第２ＡＰに対する前記Ｐｅｒ－ＳＴＡ Ｐｒｏｆｉｌｅサブフィールドは、第１要求要素を更に含み、
   前記第１全体情報プロファイルサブフィールドの値は、０に設定され、且つ、
   前記第２ＡＰに関する前記部分情報は、前記第１要求要素に基づいて要求され、
   前記第１ｎｏｎ－ＡＰ ＳＴＡが前記第２ＡＰに関する全体情報を要求することを可能にする前記マルチリンクプローブ要求フレームに基づいて、
   前記第１全体情報プロファイルサブフィールドの値は、１に設定され、
   前記第２ＡＰに対する前記Ｐｅｒ－ＳＴＡ Ｐｒｏｆｉｌｅサブフィールドは、前記第１要求要素を含まず、且つ、
   前記第２ＡＰに関する前記全体情報は、前記第２ＡＰに対する前記Ｐｅｒ－ＳＴＡ Ｐｒｏｆｉｌｅサブフィールドに基づいて要求される、第１ｎｏｎ－ＡＰ ＳＴＡ。
8. ＷＬＡＮ（wireless local area network）システムにおける方法であって、
   第１ＡＰ（access point）が第１ｎｏｎ－ＡＰ（non-access point） ＳＴＡ（station）からマルチリンクプローブ要求フレームを受信するステップと、
   前記第１ＡＰが前記第１ｎｏｎ－ＡＰ ＳＴＡにマルチリンクプローブ応答フレームを送信するステップと、を含み、
   第１リンク上で動作する前記第１ＡＰ及び第２リンク上で動作する第２ＡＰは、ＡＰ ＭＬＤ（multi-link device）に所属し、
   前記第１リンク上で動作する前記第１ｎｏｎ－ＡＰ ＳＴＡ及び前記第２リンク上で動作する第２ｎｏｎ－ＡＰ ＳＴＡは、ｎｏｎ－ＡＰ ＭＬＤに所属し、
   前記マルチリンクプローブ要求フレームは、前記第２ＡＰに対するＰｅｒ－ＳＴＡ Ｐｒｏｆｉｌｅサブフィールドを運び、
   前記第２ＡＰに対する前記Ｐｅｒ－ＳＴＡ Ｐｒｏｆｉｌｅサブフィールドは、第１ＳＴＡ Ｃｏｎｔｒｏｌフィールドの第１全体情報プロファイルサブフィールドを含み、
   前記第１ｎｏｎ－ＡＰ ＳＴＡが前記第２ＡＰに関する部分情報を要求することを可能にする前記マルチリンクプローブ要求フレームに基づいて、
   前記第２ＡＰに対する前記Ｐｅｒ－ＳＴＡ Ｐｒｏｆｉｌｅサブフィールドは、第１要求要素を更に含み、
   前記第１全体情報プロファイルサブフィールドの値は、０に設定され、且つ、
   前記第２ＡＰに関する前記部分情報は、前記第１要求要素に基づいて要求され、
   前記第１ｎｏｎ－ＡＰ ＳＴＡが前記第２ＡＰに関する全体情報を要求することを可能にする前記マルチリンクプローブ要求フレームに基づいて、
   前記第１全体情報プロファイルサブフィールドの値は、１に設定され、
   前記第２ＡＰに対する前記Ｐｅｒ－ＳＴＡ Ｐｒｏｆｉｌｅサブフィールドは、前記第１要求要素を含まず、且つ、
   前記第２ＡＰに関する前記全体情報は、前記第２ＡＰに対する前記Ｐｅｒ－ＳＴＡ Ｐｒｏｆｉｌｅサブフィールドに基づいて要求される、方法。
9. 第３リンク上で動作する第３ＡＰが前記ＡＰ ＭＬＤに更に所属し、
   前記第３リンク上で動作する第３ｎｏｎ－ＡＰ ＳＴＡが前記ｎｏｎ－ＡＰ ＭＬＤに更に所属し、
   前記マルチリンクプローブ要求フレームは、前記第３ＡＰに対するＰｅｒ－ＳＴＡ Ｐｒｏｆｉｌｅサブフィールドを更に含み、
   前記第３ＡＰに対する前記Ｐｅｒ－ＳＴＡ Ｐｒｏｆｉｌｅサブフィールドは、第２ＳＴＡ Ｃｏｎｔｒｏｌフィールドの第２全体情報プロファイルサブフィールドを含む、請求項８に記載の方法。
10. 前記第１ｎｏｎ－ＡＰ ＳＴＡが前記第３ＡＰに関する部分情報を要求することに基づいて、前記第２全体情報プロファイルサブフィールドの値は、０に設定され、前記第３ＡＰに対する前記Ｐｅｒ－ＳＴＡ Ｐｒｏｆｉｌｅサブフィールドは、第２要求要素を更に含み、
    前記第３ＡＰに関する部分情報は、前記第２要求要素に基づいて要求される、請求項９に記載の方法。
11. 前記第１ｎｏｎ－ＡＰ ＳＴＡが前記第３ＡＰに関する全体情報を要求することに基づいて、前記第２全体情報プロファイルサブフィールドの値は、１に設定され、前記第３ＡＰに対する前記Ｐｅｒ－ＳＴＡ Ｐｒｏｆｉｌｅサブフィールドは、第２要求要素を含まず、
    前記第３ＡＰに関する前記全体情報は、前記第３ＡＰに対する前記Ｐｅｒ－ＳＴＡ Ｐｒｏｆｉｌｅサブフィールドに基づいて要求される、請求項９に記載の方法。
12. 前記マルチリンクプローブ要求フレームは、第３要求要素及びマルチリンク要素を含み、
    前記第１ｎｏｎ－ＡＰ ＳＴＡが前記第１ＡＰに関する部分情報を要求することに基づいて、前記第１ＡＰに関する部分情報は、前記第３要求要素に基づいて要求され、
    前記第２ＡＰに対する前記Ｐｅｒ－ＳＴＡ Ｐｒｏｆｉｌｅサブフィールド及び第３ＡＰに対する前記Ｐｅｒ－ＳＴＡ Ｐｒｏｆｉｌｅサブフィールドは、前記マルチリンク要素に含まれる、請求項８に記載の方法。
13. 前記第１要求要素は、前記第２ＡＰに関する前記部分情報を指示する第１識別子情報を含み、
    前記第２要求要素は、前記第３ＡＰに関する部分情報を指示する第２識別子情報を含み、
    前記マルチリンクプローブ応答フレームは、前記第１全体情報プロファイルサブフィールド及び前記第２全体情報プロファイルサブフィールドの前記値と、前記第１要求要素及び前記第２要求要素とに基づいて構成される、請求項１０に記載の方法。
14. ＷＬＡＮ（wireless local area network）システムにおける第１ＡＰ（access point）であって、
    メモリと、
    送受信機と、
    前記メモリ及び前記送受信機と動作できるように結合されたプロセッサと、を含み、
    プロセッサは、
    第１ｎｏｎ－ＡＰ ＳＴＡ（station）からマルチリンクプローブ要求フレームを受信し、
    前記第１ｎｏｎ－ＡＰ ＳＴＡにマルチリンクプローブ応答フレームを送信する、ように構成され、
    第１リンク上で動作する前記第１ＡＰ及び第２リンク上で動作する第２ＡＰは、ＡＰ ＭＬＤ（multi-link device）に所属し、
    前記第１リンク上で動作する前記第１ｎｏｎ－ＡＰ ＳＴＡ及び前記第２リンク上で動作する第２ｎｏｎ－ＡＰ ＳＴＡは、ｎｏｎ－ＡＰ ＭＬＤに所属し、
    前記マルチリンクプローブ要求フレームは、前記第２ＡＰに対するＰｅｒ－ＳＴＡ Ｐｒｏｆｉｌｅサブフィールドを運び、
    前記第２ＡＰに対する前記Ｐｅｒ－ＳＴＡ Ｐｒｏｆｉｌｅサブフィールドは、第１ＳＴＡ Ｃｏｎｔｒｏｌフィールドの第１全体情報プロファイルサブフィールドを含み、
    前記第１ｎｏｎ－ＡＰ ＳＴＡが前記第２ＡＰに関する部分情報を要求することを可能にする前記マルチリンクプローブ要求フレームに基づいて、
    前記第２ＡＰに対する前記Ｐｅｒ－ＳＴＡ Ｐｒｏｆｉｌｅサブフィールドは、第１要求要素を更に含み、
    前記第１全体情報プロファイルサブフィールドの値は、０に設定され、且つ、
    前記第２ＡＰに関する前記部分情報は、前記第１要求要素に基づいて要求され、
    前記第１ｎｏｎ－ＡＰ ＳＴＡが前記第２ＡＰに関する全体情報を要求することを可能にする前記マルチリンクプローブ要求フレームに基づいて、
    前記第１全体情報プロファイルサブフィールドの値は、１に設定され、
    前記第２ＡＰに対する前記Ｐｅｒ－ＳＴＡ Ｐｒｏｆｉｌｅサブフィールドは、前記第１要求要素を含まず、且つ、
    前記第２ＡＰに関する前記全体情報は、前記第２ＡＰに対する前記Ｐｅｒ－ＳＴＡ Ｐｒｏｆｉｌｅサブフィールドに基づいて要求される、第１ＡＰ。

Images