特許 6166406 無線ローカルエリアネットワークにおける高度アクティブスキャンニング

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】6166406

(24)【登録日】2017年6月30日

(45)【発行日】2017年7月19日

(54)【発明の名称】無線ローカルエリアネットワークにおける高度アクティブスキャンニング

(51)【国際特許分類】

   H04W 48/16 20090101AFI20170710BHJP

   H04W 76/02 20090101ALI20170710BHJP

   H04W 84/12 20090101ALI20170710BHJP

【ＦＩ】

   H04W48/16

   H04W76/02

   H04W84/12

【請求項の数】28

【全頁数】46

(21)【出願番号】特願2016-31337(P2016-31337)

(22)【出願日】2016年2月22日

(62)【分割の表示】特願2015-510258(P2015-510258)の分割

【原出願日】2013年3月7日

(65)【公開番号】特開2016-96587(P2016-96587A)

(43)【公開日】2016年5月26日

【審査請求日】2016年3月23日

(31)【優先権主張番号】61/642,275

(32)【優先日】2012年5月3日

(33)【優先権主張国】US

(31)【優先権主張番号】61/668,285

(32)【優先日】2012年7月5日

(33)【優先権主張国】US

(31)【優先権主張番号】61/696,567

(32)【優先日】2012年9月4日

(33)【優先権主張国】US

(31)【優先権主張番号】61/749,064

(32)【優先日】2013年1月4日

(33)【優先権主張国】US

(73)【特許権者】

【識別番号】510030995

【氏名又は名称】インターデイジタル パテント ホールディングス インコーポレイテッド

(74)【代理人】

【識別番号】110001243

【氏名又は名称】特許業務法人 谷・阿部特許事務所

(72)【発明者】

【氏名】ジャン グオドン

(72)【発明者】

【氏名】レイ ワン

(72)【発明者】

【氏名】シアオフェイ ワン

(72)【発明者】

【氏名】ジョセフ エス．レヴィ

(72)【発明者】

【氏名】ロバート エル．オレセン

【審査官】 田部井 和彦

(56)【参考文献】

【文献】 国際公開第２０１２／０４８２５１（ＷＯ，Ａ２）

【文献】 特開２００５−０３９６３２（ＪＰ，Ａ）

【文献】 LG Electronics，TGai FILS Proposal，IEEE 802.11-11/1000r1，２０１１年 ７月１９日，Slide5，[retrieved on 2017.01.17]，ＵＲＬ，https://mentor.ieee.org/802.11/dcn/11/11-11-1000-01-00ai-tgai-fils-proposal.pptx

【文献】 Nokia，Active Scanning Enabling FILS，IEEE 802.11-11/1619r3，２０１２年 １月１９日，[retrieved on 2017.01.17]，ＵＲＬ，https://mentor.ieee.org/802.11/dcn/11/11-11-1619-03-00ai-active-scanning.docx

【文献】 SANTOSH ABRAHAM (QUALCOMM)，TEXT FOR ACCESS DELAY REDUCTION FOR FILS，IEEE 802.11-12/0124r1，米国，IEEE-SA MENTOR，２０１２年 ３月１３日，VOL:802.11AI NR:2，PAGE(S):1-7

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｈ０４Ｗ ４／００−９９／００

Ｈ０４Ｂ ７／２４− ７／２６

(57)【特許請求の範囲】

【請求項1】

高速初期リンクセットアップ（ＦＩＬＳ）のためのＩＥＥＥ ８０２．１１局（ＳＴＡ）における使用のための方法であって、
情報要素を備えたフレームをＩＥＥＥ ８０２．１１アクセスポイント（ＡＰ）から受信するステップであって、前記情報要素は、前記ＩＥＥＥ ８０２．１１ＡＰとのＦＩＬＳプロシージャを行うことを許可された少なくとも１つのＩＥＥＥ ８０２．１１ＳＴＡの少なくとも１つの識別子（ＩＤ）、および前記少なくとも１つのＩＥＥＥ ８０２．１１ＳＴＡが、１つまたは複数のＦＩＬＳフレームを使用して前記ＩＥＥＥ ８０２．１１ＡＰと関連付けることを許可された、前記ＦＩＬＳプロシージャを行うための特定の時間間隔のインジケーションを備えたアクセス情報を含む、ステップと、
前記少なくとも１つのＩＥＥＥ ８０２．１１ＳＴＡの前記少なくとも１つのＩＤが前記ＩＥＥＥ ８０２．１１ＳＴＡのＩＤと一致することを条件に、前記示された特定の時間間隔の間に、アソシエーションリクエストメッセージを前記ＩＥＥＥ ８０２．１１ＡＰに送信することを含む、前記ＦＩＬＳプロシージャを行うステップと
を備えたことを特徴とする方法。

【請求項2】

前記フレームは、ビーコンフレームであることを特徴とする請求項１に記載の方法。

【請求項3】

前記フレームは、プローブ応答フレームであることを特徴とする請求項１に記載の方法。

【請求項4】

前記情報要素は、少なくとも１つのＩＥＥＥ ８０２．１１ＳＴＡに対する優先度情報をさらに含むことを特徴とする請求項１に記載の方法。

【請求項5】

ＦＩＬＳプロシージャを行う前記ステップは、認証フレームを前記ＩＥＥＥ ８０２．１１ＡＰに送信することを備えていることを特徴とする請求項１に記載の方法。

【請求項6】

ＦＩＬＳプロシージャを行う前記ステップは、プローブ要求フレームを前記ＩＥＥＥ ８０２．１１ＡＰに送信することを備えていることを特徴とする請求項１に記載の方法。

【請求項7】

前記識別子は、媒体アクセス制御（ＭＡＣ）アドレスであることを特徴とする請求項１に記載の方法。

【請求項8】

高速初期リンクセットアップ（ＦＩＬＳ）を実行するように構成されたＩＥＥＥ ８０２．１１局（ＳＴＡ）であって、
送信機と、
情報要素を備えたフレームをＩＥＥＥ ８０２．１１アクセスポイント（ＡＰ）から受信するように構成された受信機であって、前記情報要素は、前記ＩＥＥＥ ８０２．１１ＡＰとのＦＩＬＳプロシージャを行うことを許可された少なくとも１つのＩＥＥＥ ８０２．１１ＳＴＡの少なくとも１つの識別子（ＩＤ）、および前記少なくとも１つのＩＥＥＥ ８０２．１１ＳＴＡが、１つまたは複数のＦＩＬＳフレームを使用して前記ＩＥＥＥ ８０２．１１ＡＰと関連付けることを許可された、前記ＦＩＬＳプロシージャを行うための特定の時間間隔のインジケーションを備えたアクセス情報を含む、受信機と、
前記少なくとも１つのＩＥＥＥ ８０２．１１ＳＴＡの少なくとも１つのＩＤが前記ＩＥＥＥ ８０２．１１ＳＴＡのＩＤと一致するかを判定するように構成されたプロセッサと
を備え、
前記プロセッサは、前記少なくとも１つのＩＥＥＥ ８０２．１１ＳＴＡの前記少なくとも１つのＩＤが前記ＩＥＥＥ ８０２．１１ＳＴＡの前記ＩＤと一致することを条件に、前記示された特定の時間間隔の間に、アソシエーションリクエストメッセージを前記ＩＥＥＥ ８０２．１１ＡＰに送信することを含む、前記ＦＩＬＳプロシージャを行うようにさらに構成されている
ことを特徴とするＩＥＥＥ ８０２．１１ＳＴＡ。

【請求項9】

前記フレームは、ビーコンフレームであることを特徴とする請求項８に記載のＩＥＥＥ ８０２．１１ＳＴＡ。

【請求項10】

前記フレームは、プローブ応答フレームであることを特徴とする請求項８に記載のＩＥＥＥ ８０２．１１ＳＴＡ。

【請求項11】

前記情報要素は、少なくとも１つのＩＥＥＥ ８０２．１１ＳＴＡに対する優先度情報をさらに含むことを特徴とする請求項８に記載のＩＥＥＥ ８０２．１１ＳＴＡ。

【請求項12】

前記送信機は、前記ＦＩＬＳプロシージャに従って、認証フレームを前記ＩＥＥＥ ８０２．１１ＡＰに送信するように構成されていることを特徴とする請求項８に記載のＩＥＥＥ ８０２．１１ＳＴＡ。

【請求項13】

前記送信機は、前記ＦＩＬＳプロシージャに従って、プローブ要求フレームを前記ＩＥＥＥ ８０２．１１ＡＰに送信するように構成されていることを特徴とする請求項８に記載のＩＥＥＥ ８０２．１１ＳＴＡ。

【請求項14】

前記識別子は、媒体アクセス制御（ＭＡＣ）アドレスであることを特徴とする請求項８に記載のＩＥＥＥ ８０２．１１ＳＴＡ。

【請求項15】

高速初期リンクセットアップ（ＦＩＬＳ）のためのＩＥＥＥ ８０２．１１アクセスポイント（ＡＰ）における使用のための方法であって、
情報要素を備えたフレームをＩＥＥＥ ８０２．１１局（ＳＴＡ）に送信するステップであって、前記情報要素は、前記ＩＥＥＥ ８０２．１１ＡＰとのＦＩＬＳプロシージャを行うことを許可された少なくとも１つのＩＥＥＥ ８０２．１１ＳＴＡの少なくとも１つの識別子（ＩＤ）、および前記少なくとも１つのＩＥＥＥ ８０２．１１ＳＴＡが、１つまたは複数のＦＩＬＳフレームを使用して前記ＩＥＥＥ ８０２．１１ＡＰと関連付けることを許可された、前記ＦＩＬＳプロシージャを行うための特定の時間間隔のインジケーションを備えたアクセス情報を含む、ステップと、
前記少なくとも１つのＩＥＥＥ ８０２．１１ＳＴＡの前記少なくとも１つのＩＤが前記ＩＥＥＥ ８０２．１１ＳＴＡのＩＤと一致することを条件に、前記示された特定の時間間隔の間に前記ＩＥＥＥ ８０２．１１ＳＴＡから、アソシエーションリクエストフレームを含む、少なくとも１つのＦＩＬＳフレームを受信するステップと
を備えたことを特徴とする方法。

【請求項16】

前記フレームは、ビーコンフレームであることを特徴とする請求項１５に記載の方法。

【請求項17】

前記フレームは、プローブ応答フレームであることを特徴とする請求項１５に記載の方法。

【請求項18】

前記情報要素は、少なくとも１つのＩＥＥＥ ８０２．１１ＳＴＡに対する優先度情報をさらに含むことを特徴とする請求項１５に記載の方法。

【請求項19】

前記示された特定の時間間隔の間に前記ＩＥＥＥ ８０２．１１ＳＴＡから受信された前記少なくとも１つのＦＩＬＳフレームは、認証フレームを含むことを特徴とする請求項１５に記載の方法。

【請求項20】

前記示された特定の時間間隔の間に前記ＩＥＥＥ ８０２．１１ＳＴＡから受信された前記少なくとも１つのＦＩＬＳフレームは、プローブ要求フレームを含むことを特徴とする請求項１５に記載の方法。

【請求項21】

前記識別子は、媒体アクセス制御（ＭＡＣ）アドレスであることを特徴とする請求項１５に記載の方法。

【請求項22】

高速初期リンクセットアップ（ＦＩＬＳ）を実行するように構成されたＩＥＥＥ ８０２．１１アクセスポイント（ＡＰ）であって、
情報要素を備えたフレームをＩＥＥＥ ８０２．１１局（ＳＴＡ）に送信するように構成された送信機であって、前記情報要素は、前記ＩＥＥＥ ８０２．１１ＡＰとのＦＩＬＳプロシージャを行うことを許可された少なくとも１つのＩＥＥＥ ８０２．１１ＳＴＡの少なくとも１つの識別子（ＩＤ）、および前記少なくとも１つのＩＥＥＥ ８０２．１１ＳＴＡが、１つまたは複数のＦＩＬＳフレームを使用して前記ＩＥＥＥ ８０２．１１ＡＰと関連付けることを許可された、前記ＦＩＬＳプロシージャを行うための特定の時間間隔のインジケーションを備えたアクセス情報を含む、送信機と、
前記少なくとも１つのＩＥＥＥ ８０２．１１ＳＴＡの前記少なくとも１つのＩＤが前記ＩＥＥＥ ８０２．１１ＳＴＡのＩＤと一致することを条件に、前記示された特定の時間間隔の間に、アソシエーションリクエストフレームを含む、少なくとも１つのＦＩＬＳフレームを前記ＩＥＥＥ ８０２．１１ＳＴＡから受信するように構成された受信機と
を備えたことを特徴とするＩＥＥＥ ８０２．１１ＡＰ。

【請求項23】

前記フレームは、ビーコンフレームであることを特徴とする請求項２２に記載のＩＥＥＥ ８０２．１１ＡＰ。

【請求項24】

前記フレームは、プローブ応答フレームであることを特徴とする請求項２２に記載のＩＥＥＥ ８０２．１１ＡＰ。

【請求項25】

前記情報要素は、少なくとも１つのＩＥＥＥ ８０２．１１ＳＴＡに対する優先度情報をさらに含むことを特徴とする請求項２２に記載のＩＥＥＥ ８０２．１１ＡＰ。

【請求項26】

前記示された特定の時間間隔の間に前記ＩＥＥＥ ８０２．１１ＳＴＡから受信された前記少なくとも１つのＦＩＬＳフレームは、認証フレームを含むことを特徴とする請求項２２に記載のＩＥＥＥ ８０２．１１ＡＰ。

【請求項27】

前記示された特定の時間間隔の間に前記ＩＥＥＥ ８０２．１１ＳＴＡから受信された前記少なくとも１つのＦＩＬＳフレームは、プローブ要求フレームを含むことを特徴とする請求項２２に記載のＩＥＥＥ ８０２．１１ＡＰ。

【請求項28】

前記識別子は、媒体アクセス制御（ＭＡＣ）アドレスであることを特徴とする請求項２２に記載のＩＥＥＥ ８０２．１１ＡＰ。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、無線通信に関する。

【背景技術】

【0002】

本出願は、その内容を参照により本明細書に組み込まれている、２０１２年５月３日に出願された米国仮特許出願第６１／６４２，２７５号、２０１２年７月５日に出願された米国仮特許出願第６１／６６８，２８５号、２０１２年９月４日に出願された米国仮特許出願第６１／６９６，５６７号、２０１３年１月４日に出願された米国仮特許出願第６１／７４９，０６４号の利益を主張する。

【0003】

ＩＥＥＥ ８０２．１１では、いくつかの異なるシナリオにおいて、性能およびユーザ経験に悪影響を与えることのある要因が存在する。ユーザのデバイスに対する初期接続を確立するのにＩＥＥＥ ８０２．１１に対して要求される時間の長さ（例えば、最大数秒）は、ユーザ経験に悪影響を与えることがある。例えば、対話型セション（例えば、Ｓｋｙｐｅビデオ）を使用して、別のネットワーク、例えば第三世代（３Ｇ）からＷＬＡＮに切り換えるときに、接続が維持できないことがある。リンクセットアッププロセスが性能に悪影響を与えることがある別の例は、拡張サービスセット（ＥＳＳ）に同時に入ってくる多数のユーザをサポートし、および、ユーザの初期認証をセキュアに提供する要件である。

【発明の概要】

【0004】

無線ネットワークにおけるアクティブスキャンニングのための方法は、２つの送信機を含んでもよい。このような方法では、以下のステップ、第１の送信機から発信するスキャンニングターゲットを有する第１のプローブ要求を検出するステップと、第２の送信機からスキャンニングターゲットへのプローブ要求を送信することを要求するステップと、第２の送信機が第１のプローブ要求を検出する条件で、第２のプローブ要求をキャンセルするステップと、を実行する。

【図面の簡単な説明】

【0005】

添付の図面と併せて例示される以下の説明から、より詳細な理解を得ることができる。

【0006】

【図1A】１または複数の開示される実施形態が実装することができる例示的な通信システムのシステム図である。

【図1B】図１Ａにおいて例示される通信システム内で使用されてもよい例示的な無線送信／受信ユニット（ＷＴＲＵ）のシステム図である。

【図1C】図１Ａにおいて例示される通信システム内で使用されてもよい例示的な無線（radio）アクセスネットワークおよび例示的なコアネットワークのシステム図である。

【図2】ＩＥＥＥ ８０２．１１リンクセットアッププロシージャの例を示す。

【図3】アクティブスキャンニングの例を示す。

【図3A】初期リンクセットアップ要素を示す。

【図4】局およびアクセスポイント範囲の例を示す。

【図5】プローブ応答（Ｐｒｏｂｅ Ｒｅｓｐｏｎｓｅ）キャンセルの例を示す。

【図6】プローブ応答のキャンセルの例を示す。

【図7】プローブ応答のキャンセルの別の例を示す。

【図8】ＦＩＬＳ ＥＤＣＡパラメータセット情報要素の例を示す。

【図9】アクセスオプション情報要素（Ａｃｃｅｓｓ Ｏｐｔｉｏｎ Ｉｎｆｏｒｍａｔｉｏｎ Ｅｌｅｍｅｎｔ）を示す。

【図10】アクセスオプションＩＥのスペックｉフィールド（Ｓｐｅｃ ｉ ｆｉｅｌｄ）を示す。

【図10A】ＩＬＳ要素（Ｅｌｅｍｅｎｔ）設計を示す。

【図11】異なる記述フィールド（description field）での簡易プローブ要求フレームの第１の例を示す。

【図12】異なる記述フィールドでの簡易プローブ要求フレームの第２の例を示す。

【図13】簡易プローブ要求フレームにおける差分フィールド／ＩＥの例を示す

【図14】簡易プローブ要求フレームにおける差分フィールド／ＩＥの例を示す。

【図15】差分記述フィールドでの簡易プローブ応答フレームの例を示す。

【図16】差分記述フィールドでの簡易プローブ応答フレームの例を示す。

【図17】簡易プローブ応答フレームにおける差分フィールド／ＩＥを示す。

【図18】簡易プローブ応答フレームにおける差分フィールド／ＩＥを示す。

【発明を実施するための形態】

【0007】

＜導入＞

【0008】

無線通信においては、および具体的には、非公式にはＷｉ-Ｆｉとして知られる米国電気電子学会（ＩＥＥＥ）８０２．１１プロトコルにおいては、多くの場合、アクセスポイント（ＡＰ）などのネットワークエンティティが多数のユーザに接続を提供することができることを要求される。ユーザは、一般的に、接続を確立するとき、通信ネットワークをスキャンする。スキャンニングは多くの場合、ネットワーク帯域幅に負担をかけ、ユーザとネットワークとの間のプローブ要求および応答の交換に起因して、アクセス衝突および遅延を引き起こす結果となる。

【0009】

方法および装置において、アクティブスキャンを示すスキャンタイプ（ＳｃａｎＴｙｐｅ）を有するＭＬＭＥ−ＳＣＡＮ．ｒｅｑｕｅｓｔプリミティブ（primitives）が受信されてもよく、および、プローブ遅延（ＰｒｏｂｅＤｅｌａｙ）タイマが満了となり、または、ＰＨＹＲｘＳｔａｒｔ．ｉｎｄｉｃａｔｉｏｎプリミティブが受信されるという条件で、基本アクセスプロシージャが実行されてもよい。方法および装置において、プローブ要求（Ｐｒｏｂｅ Ｒｅｑｕｅｓｔ）の送信が中断またはキャンセルされてもよい。キャンセルの中断は、局管理エンティティ（ＳＭＥ）と媒体アクセス制御（ＭＡＣ）レイヤ管理エンティティ（ＭＬＭＥ）との間でプリミティブを介して実行されてもよく、それによって、ＭＬＭＥ−Ｓｃａｎ−ＳＴＯＰ．ｒｅｑｕｅｓｔプリミティブが、現在のチャネルに対するアクティブスキャンニングの中断を示してもよい。さらに、方法および装置では、プローブ応答フレームが復号されないという条件で、プローブ要求フレームが送信されてもよい。

【0010】

図１Ａは、１または複数の開示された実施形態が実装されてもよい例示的な通信システム１００の図である。通信システム１００は、音声、データ、ビデオ、メッセージング、ブロードキャストなどのコンテンツを、複数の無線ユーザに提供する多元アクセスシステムであってもよい。通信システム１００は、複数の無線ユーザが無線帯域幅を含むシステムリソースの共有を通じて、このようなコンテンツにアクセスすることを可能にすることができる。例えば、通信システム１００は、符号分割多元接続（ＣＤＭＡ）、時分割多元接続（ＴＤＭＡ）、周波数分割多元接続（ＦＤＭＡ）、直交ＦＤＭＡ（ＯＦＤＭＡ）、シングルキャリアＦＤＭＡ（ＳＣ−ＦＤＭＡ）などの、１または複数のチャネルアクセス方法を採用してもよい。

【0011】

図１Ａに示すように、通信システム１００は、無線送信／受信ユニット（ＷＴＲＵ）１０２ａ、１０２ｂ、１０２ｃ、１０２ｄ、無線アクセスネットワーク（ＲＡＮ）１０４、コアネットワーク１０６、公衆交換電話網（ＰＳＴＮ）１０８、インターネット１１０、およびその他のネットワーク１１２を含んでもよいが、開示される実施形態は、任意の数のＷＴＲＵ、基地局、ネットワーク、および／またはネットワーク要素を考慮してもよいことを理解されるであろう。ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄのそれぞれは、無線環境で動作および／または通信するように構成された任意のタイプのデバイスであってもよい。例として、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄは、無線信号を送信および／または受信するように構成されてもよく、ユーザ機器（ＵＥ）、移動局、固定または移動加入者ユニット、ページャ、携帯電話、携帯情報端末（ＰＤＡ）、スマートフォン、ラップトップ、ネットブック、パーソナルコンピュータ、無線センサ、および家庭用電化製品などを含んでもよい。

【0012】

通信システム１００はまた、基地局１１４ａおよび基地局１１４ｂを含んでもよい。基地局１１４ａ、１１４ｂのそれぞれは、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄの少なくとも１つと無線にインタフェースして、コアネットワーク１０６、インターネット１１０、および／またはネットワーク１１２などの、１または複数の通信ネットワークへのアクセスを容易にするように構成された任意のタイプのデバイスであってもよい。例として、基地局１１４ａ、１１４ｂは、ベーストランシーバ局（ＢＴＳ）、ＮｏｄｅＢ、ｅＮｏｄｅＢ、ホームＮｏｄｅＢ、ホームｅＮｏｄｅＢ、サイトコントローラ、アクセスポイント（ＡＰ）、および無線ルータなどであってもよい。基地局１１４ａ、１１４ｂは、それぞれ単一要素として示されているが、基地局１１４ａ、１１４ｂは、任意の数の相互接続された基地局および／またはネットワーク要素も含んでもよいことを理解されよう。

【0013】

基地局１１４ａは、ＲＡＮ１０４の一部であってもよく、および、ＲＡＮ１０４は、基地局コントローラ（ＢＳＣ）、無線ネットワークコントローラ（ＲＮＣ）、リレーノードなど、他の基地局および／またはネットワーク要素（図示せず）も含んでもよい。基地局１１４ａおよび／または基地局１１４ｂは、セル（図示せず）と称されてもよい特定の地理的領域内で無線信号を送信および／または受信するように構成されてもよい。セルは、セルセクタにさらに分割されてもよい。例えば、基地局１１４ａと関連付けられたセルは、３つのセクタに分割されてもよい。したがって、１つの実施形態では、基地局１１４ａは３つの送受信機、すなわちセルの各セクタに対して１つを含んでもよい。別の実施形態では、基地局１１４ａは、多入力多出力（ＭＩＭＯ）技術を採用してもよく、したがって、セルの各セクタに複数の送受信機を利用してもよい。

【0014】

基地局１１４ａ、１１４ｂは、任意の適切な無線通信リンク（例えば、無線周波数（ＲＦ）、マイクロ波、赤外線（ＩＲ）、紫外線（ＵＶ）、可視光線など）であってもよいエアインタフェース１１６上でＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄの１つまたは複数と通信してもよい。エアインタフェース１１６は、任意の適切な無線アクセス技術（ＲＡＴ）を使用して確立されてもよい。

【0015】

より詳細には、上述したように、通信システム１００は、多元アクセスシステムであってもよく、ならびに、ＣＤＭＡ、ＴＤＭＡ、ＦＤＭＡ、ＯＦＤＭＡ、およびＳＣ−ＦＤＭＡなどの１または複数のチャネルアクセススキームを採用してもよい。例えば、ＲＡＮ１０４における基地局１１４ａおよびＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、広帯域ＣＤＭＡ（ＷＣＤＭＡ（登録商標））を使用してエアインタフェース１１６を確立することができるユニバーサル移動体通信システム（ＵＭＴＳ）地上波無線アクセス（ＵＴＲＡ）などの無線技術を実装してもよい。ＷＣＤＭＡは、高速パケットアクセス（ＨＳＰＡ）および／または進化型ＨＳＰＡ（ＨＳＰＡ＋）などの通信プロトコルを含んでもよい。ＨＳＰＡは、高速ダウンリンクパケットアクセス（ＨＳＤＰＡ）および／または高速アップリンクパケットアクセス（ＨＳＵＰＡ）を含んでもよい。

【0016】

別の実施形態では、基地局１１４ａおよびＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、ロングタームエボリューション（ＬＴＥ）および／またはＬＴＥ−Ａｄｖａｎｃｅｄ（ＬＴＥ−Ａ）を使用してエアインタフェース１１６を確立することができる進化型ＵＭＴＳ地上無線アクセス（Ｅ−ＵＴＲＡ）などの無線技術を実装してもよい。

【0017】

別の実施形態では、基地局１１４ａおよびＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、ＩＥＥＥ ８０２．１６（すなわち、Ｗｏｒｌｄｗｉｄｅ Ｉｎｔｅｒｏｐｅｒａｂｉｌｉｔｙ ｆｏｒ Ｍｉｃｒｏｗａｖｅ Ａｃｃｅｓｓ（ＷｉＭＡＸ））、ＣＤＭＡ２０００、ＣＤＭＡ２０００ １Ｘ、ＣＤＭＡ２０００ ＥＶ−ＤＯ、Ｉｎｔｅｒｉｍ Ｓｔａｎｄａｒｄ ２０００（ＩＳ−２０００）、Ｉｎｔｅｒｉｍ Ｓｔａｎｄａｒｄ ９５（ＩＳ−９５）、Ｉｎｔｅｒｉｍ Ｓｔａｎｄａｒｄ ８５６（ＩＳ−８５６）、Ｇｌｏｂａｌ Ｓｙｓｔｅｍ ｆｏｒ Ｍｏｂｉｌｅ ｃｏｍｍｕｎｉｃａｔｉｏｎｓ（ＧＳＭ（登録商標））、Ｅｎｈａｎｃｅｄ Ｄａｔａ ｒａｔｅｓ ｆｏｒ ＧＳＭ Ｅｖｏｌｕｔｉｏｎ（ＥＤＧＥ）、ＧＳＭ ＥＤＧＥ（ＧＥＲＡＮ）などの無線技術を実装してもよい。

【0018】

図１Ａにおける基地局１１４ｂは、例えば、無線ルータ、ホームＮｏｄｅＢ、ホームｅＮｏｄｅＢ、またはアクセスポイントであってもよく、ならびに、職場、家庭、自動車、学校などの局所的エリアにおいて無線接続を容易にするための任意の適切なＲＡＴを利用してもよい。１つの実施形態では、基地局１１４ｂおよびＷＴＲＵ１０２ｃ、１０２ｄは、ＩＥＥＥ ８０２．１１などの無線技術を実装して、無線ローカルエリアネットワーク（ＷＬＡＮ）を確立してもよい。別の実施形態では、基地局１１４ｂおよびＷＴＲＵ１０２ｃ、１０２ｄは、ＩＥＥＥ ８０２．１５などの無線技術を実装して、無線パーソナルエリアネットワーク（ＷＰＡＮ）を確立してもよい。さらに別の実施形態では、基地局１１４ｂおよびＷＴＲＵ１０２ｃ、１０２ｄは、セルラベースのＲＡＴ（例えば、ＷＣＤＭＡ、ＣＤＭＡ２０００、ＧＳＭ、ＬＴＥ、ＬＴＥ−Ａなど）を利用して、ピコセルまたはフェムトセルを確立してもよい。図１Ａに示すように、基地局１１４ｂは、インターネット１１０への直接接続を有してもよい。したがって基地局１１４ｂは、コアネットワーク１０６を介してインターネット１１０にアクセスすることを必要としなくてもよい。

【0019】

ＲＡＮ１０４は、音声、データ、アプリケーション、および／またはボイスオーバーインターネットプロトコル（ＶｏＩＰ）サービスをＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄの１または複数に提供するように構成された任意のタイプのネットワークとすることができるコアネットワーク１０６と通信してもよい。例えば、コアネットワーク１０６は、呼制御、課金サービス、モバイルロケーションベースサービス、プリペイド通話、インターネット接続性、ビデオ配信などを提供し、および／または、ユーザ認証など高レベルセキュリティ機能を実行してもよい。図１Ａには示されていないが、ＲＡＮ１０４および／またはコアネットワーク１０６は、ＲＡＮ１０４と同一のＲＡＴまたは異なるＲＡＴを採用する他のＲＡＮと直接または間接通信してもよいことを理解されるであろう。例えば、Ｅ−ＵＴＲＡ無線技術を使用していてもよいＲＡＮ１０４に接続されていることに加えて、コアネットワーク１０６はまた、ＧＳＭ無線技術を採用する別のＲＡＮ（図示しない）と通信してもよい。

【0020】

コアネットワーク１０６はまた、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄが、ＰＳＴＮ１０８、インターネット１１０、および／または他のネットワーク１１２にアクセスするためのゲートウェイとしてサービスしてもよい。ＰＳＴＮ１０８は、旧来の電話サービス（ＰＯＴＳ）を提供する回線交換電話網を含んでもよい。インターネット１１０は、ＴＣＰ／ＩＰインターネットプロトコルスイートにおける伝送制御プロトコル（ＴＣＰ）、ユーザデータグラムプロトコル（ＵＤＰ）、インターネットプロトコル（ＩＰ）などの共通通信プロトコルを使用する、相互接続コンピュータネットワークおよびデバイスのグローバルシステムを含んでもよい。ネットワーク１１２は、他のサービスプロバイダによって所有および／または提供される有線または無線通信ネットワークを含んでもよい。例えばネットワーク１１２は、ＲＡＮ１０４と同一のＲＡＴ、または異なるＲＡＴを採用することができる、１または複数のＲＡＮに接続された別のコアネットワークを含んでもよい。

【0021】

通信システム１００のＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄの一部または全部は、マルチモード機能を含んでもよく、すなわち、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄは、異なる無線リンク上で異なる無線ネットワークと通信するための複数の送受信機を含んでもよい。例えば図１Ａに示すＷＴＲＵ１０２ｃは、セルラベースの無線技術を採用することができる基地局１１４ａ、および、ＩＥＥＥ ８０２無線技術を採用することができる基地局１１４ｂと通信するように構成されてもよい。

【0022】

図１Ｂは、例示的なＷＴＲＵ１０２のシステム図である。図１Ｂに示すように、ＷＴＲＵ１０２は、プロセッサ１１８、送受信機１２０、送信／受信要素１２２、スピーカ／マイクロフォン１２４、キーパッド１２６、ディスプレイ／タッチパッド１２８、着脱不能メモリ１３０、着脱可能メモリ１３２、電源１３４、全地球測位システム（ＧＰＳ）チップセット１３６、および他の周辺機器１３８を含んでもよい。ＷＴＲＵ１０２は、実施形態との一貫性を維持したまま、前述の要素の任意のサブコンビネーションを含んでもよいことを理解されよう。

【0023】

プロセッサ１１８は、汎用プロセッサ、専用プロセッサ、従来型プロセッサ、デジタルシグナルプロセッサ（ＤＳＰ）、複数のマイクロプロセッサ、ＤＳＰコアと関連する１または複数のマイクロプロセッサ、コントローラ、マイクロコントローラ、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）回路、その他のタイプの集積回路（ＩＣ）、状態機械などであってもよい。プロセッサ１１８は、信号符号化、データ処理、電力制御、入力／出力処理、および／またはＷＴＲＵ１０２が無線環境で動作できるようにするその他の機能を実行してもよい。プロセッサ１１８は、送信／受信要素１２２に結合することができる送受信機１２０に結合されてもよい。図１Ｂはプロセッサ１１８および送受信機１２０を別々の構成要素として示しているが、プロセッサ１１８および送受信機１２０は、電子パッケージまたはチップに統合されてもよいことを理解されるであろう。

【0024】

送信／受信要素１２２は、エアインタフェース１１６上で基地局へ信号を送信し、または基地局から信号を受信するように構成されてもよい。例えば、１つの実施形態では、送信／受信要素１２２は、ＲＦ信号を送信および／または受信するように構成されたアンテナであってもよい。別の実施形態では、送信／受信要素１２２は、例えば、ＩＲ、ＵＶ、または可視光線信号を送信および／または受信するように構成されたエミッタ／ディテクタであってもよい。さらに別の実施形態では、送信／受信要素１２２は、ＲＦと光信号の両方を送信／受信するように構成されてもよい。送信／受信要素１２２は、無線信号の任意の組合せを送信および／または受信するように構成されてもよいことを理解されよう。

【0025】

加えて、送信／受信要素１２２は図１Ｂでは単一要素として示されているが、ＷＴＲＵ１０２は任意の数の送信／受信要素１２２を含んでもよい。さらに具体的には、ＷＴＲＵ１０２はＭＩＭＯ技術を採用してもよい。したがって、１つの実施形態では、ＷＴＲＵ１０２は、エアインタフェース１１６上で無線信号を送信および受信するための２つ以上の送信／受信要素１２２（例えば複数のアンテナ）を含んでもよい。

【0026】

送受信機１２０は、送信／受信要素１２２によって送信されることになる信号を変調し、および、送信／受信要素１２２によって受信される信号を復調するように構成されてもよい。上述したように、ＷＴＲＵ１０２は、マルチモード機能を有してもよい。したがって、送受信機１２０は、ＷＴＲＵ１０２が例えばＵＴＲＡおよびＩＥＥＥ ８０２．１１などの、複数のＲＡＴによって通信できるようにするための複数の送受信機を含んでもよい。

【0027】

ＷＴＲＵ１０２のプロセッサ１１８は、スピーカ／マイクロフォン１２４、キーパッド１２６、および／またはディスプレイ／タッチパッド１２８（例えば、液晶ディスプレイ（ＬＣＤ）ディスプレイユニットまたは有機発光ダイオード（ＯＬＥＤ）ディスプレイユニット）に結合されてもよく、ならびに、これらからユーザ入力データを受信してもよい。プロセッサ１１８はまた、スピーカ／マイクロフォン１２４、キーパッド１２６、および／またはディスプレイ／タッチパッド１２８にユーザデータを出力してもよい。加えて、プロセッサ１１８は、着脱不能メモリ１３０および／または着脱可能メモリ１３２などの、任意のタイプの適切なメモリからの情報にアクセスしてもよく、ならびに、任意のタイプの適切なメモリにデータを格納してもよい。着脱不能メモリ１３０は、ランダムアクセスメモリ（ＲＡＭ）、リードオンリメモリ（ＲＯＭ）、ハードディスク、または任意の他のタイプのメモリ記憶装置を含んでもよい。着脱可能メモリ１３２は、加入者識別モジュール（ＳＩＭ）カード、メモリスティック、セキュアデジタル（ＳＤ）メモリカードを含んでもよい。他の実施形態では、プロセッサ１１８は、サーバまたは家庭用コンピュータ（図示せず）などの、ＷＴＲＵ１０２に物理的に位置していないメモリからの情報にアクセスし、および、このメモリにデータを格納してもよい。

【0028】

プロセッサ１１８は、電源１３４から電力を受信してもよく、および、ＷＴＲＵ１０２における他の構成要素に電力を分配および／または制御するように構成されてもよい。電源１３４は、ＷＴＲＵ１０２に電力を供給するための任意の適切なデバイスであってもよい。例えば、電源１３４は、１または複数の乾電池（例えば、ニッケルカドミウム（ＮｉＣｄ）、ニッケル亜鉛（ＮｉＺｎ）、ニッケル水素（ＮｉＭＨ）、リチウムイオン（Ｌｉ−ｉｏｎ）、その他）、太陽電池、および燃料電池などを含んでもよい。

【0029】

プロセッサ１１８は、ＷＴＲＵ１０２の現在の位置に関する位置情報（例えば、経度および緯度）を提供するように構成することができるＧＰＳチップセット１３６に結合されてもよい。ＧＰＳチップセット１３６からの情報に加えて、またはそれに代えて、ＷＴＲＵ１０２は、基地局（例えば基地局１１４ａ、１１４ｂ）からエアインタフェース１１６上で位置情報を受信し、および／または、２以上の近隣基地局から受信されている信号のタイミングに基づいて、その位置を判定してもよい。ＷＴＲＵ１０２は、一実施形態との整合性を維持しながら、任意の適切な位置判定方法によって位置情報を取得してもよいことを理解されよう。

【0030】

プロセッサ１１８はさらに、追加の特徴、機能、および／または有線もしくは無線接続性を提供する１または複数のソフトウェアモジュールおよび／またはハードウェアモジュールを含むことができる他の周辺機器１３８に結合されてもよい。例えば、周辺機器１３８は、加速度計、電子コンパス、衛星送受信機、デジタルカメラ（写真またはビデオ用）、ユニバーサルシリアルバス（ＵＳＢ）ポート、振動デバイス、テレビジョン送受信機、ハンズフリーハンドセット、Ｂｌｕｅｔｏｏｔｈ（登録商標）モジュール、周波数変調（ＦＭ）無線ユニット、デジタル音楽プレイヤ、メディアプレイヤ、ビデオゲームプレイヤモジュール、およびインターネットブラウザなどを含んでもよい。

【0031】

図１Ｃは、一実施形態に従ったＲＡＮ１０４およびコアネットワーク１０６のシステム図である。ＲＡＮ１０４は、ＩＥＥＥ ８０２．１６無線技術を使用して、エアインタフェース１１６上でＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと通信するアクセスサービスネットワーク（ＡＳＮ）であってもよい。以下にさらに説明するように、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、ＲＡＮ１０４、およびコアネットワーク１０６の異なる機能エンティティ間の通信リンクは、参照ポイントとして定義されてもよい。

【0032】

図１Ｃに示すように、ＲＡＮ１０４は、基地局１４０ａ、１４０ｂ、１４０ｃ、およびＡＳＮゲートウェイ１４２を含んでもよいが、ＲＡＮ１０４は、実施形態との整合性を維持しながら、任意の数の基地局およびＡＳＮゲートウェイも含んでもよいことを理解されよう。基地局１４０ａ、１４０ｂ、１４０ｃはそれぞれ、ＲＡＮ１０４において特定のセル（図示せず）と関連付けられてもよく、および、それぞれエアインタフェース１１６上でＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと通信するための１または複数の送受信機を含んでもよい。１つの実施形態では、基地局１４０ａ、１４０ｂ、１４０ｃは、ＭＩＭＯ技術を実装してもよい。したがって、基地局１４０ａは、例えば、複数のアンテナを使用してＷＴＲＵ１０２ａに無線信号を送信し、および、ＷＴＲＵ１０２ａから無線信号を受信してもよい。基地局１４０ａ、１４０ｂ、１４０ｃはまた、ハンドオフトリガリング、トンネル確立、無線リソース管理、トラフィック分類、およびサービス品質（ＱｏＳ）ポリシ実行などの、モビリティ管理機能を提供してもよい。ＡＳＮゲートウェイ１４２は、トラフィックアグリゲーションポイントとしてサービスしてもよく、ならびに、ページング、加入者プロファイルのキャッシング、およびコアネットワーク１０６へのルーティングなどを担当してもよい。

【0033】

ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃとＲＡＮ１０４との間のエアインタフェース１１６は、ＩＥＥＥ ８０２．１６仕様を実装するＲ１参照ポイントとして定義されてもよい。加えて、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃのそれぞれは、コアネットワーク１０６との論理インタフェース（図示せず）を確立してもよい。ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃとコアネットワーク１０６との間の論理インタフェースは、認証、認可、ＩＰホスト構成管理、および／またはモビリティ管理に使用することができるＲ２参照ポイントとして定義されてもよい。

【0034】

基地局１４０ａ、１４０ｂ、１４０ｃのそれぞれの間の通信リンクは、基地局間のＷＴＲＵハンドオーバおよびデータの転送を容易にするためのプロトコルを含む、Ｒ８参照ポイントとして定義されてもよい。基地局１４０ａ、１４０ｂ、１４０ｃとＡＳＮゲートウェイ１４２との間の通信リンクは、Ｒ６参照ポイントとして定義されてもよい。Ｒ６参照ポイントは、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃのそれぞれと関連付けられたモビリティイベントに基づいてモビリティ管理を容易にするためのプロトコルを含んでもよい。

【0035】

図１Ｃに示されるように、ＲＡＮ１０４は、コアネットワーク１０６に接続されてもよい。ＲＡＮ１０４とコアネットワーク１０６との間の通信リンクは、例えば、データ転送およびモビリティ管理能力を容易にするためのプロトコルを含む、Ｒ３参照ポイントとして定義されてもよい。コアネットワーク１０６は、モバイルＩＰホームエージェント（ＭＩＰ−ＨＡ）１４４、認証、許可、課金（ＡＡＡ）サーバ１４６、およびゲートウェイ１４８を含んでもよい。前述の要素のそれぞれは、コアネットワーク１０６の一部として示されているが、これらの要素の任意の１つがコアネットワークオペレータ以外のエンティティによって所有および／または操作されてもよいことを理解されよう。

【0036】

ＭＩＰ ＨＡは、ＩＰアドレス管理を担当してもよく、ならびに、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃが異なるＡＳＮおよび／または異なるコアネットワーク間でローミングを可能にしてもよい。ＭＩＰ−ＨＡ １４４は、ＷＴＲＵ １０２ａ、１０２ｂ、１０２ｃに、インターネット１１０などのパケット交換ネットワークへのアクセスを提供して、ＷＴＲＵ １０２ａ、１０２ｂ、１０２ｃとＩＰ対応デバイスとの間の通信を容易にしてもよい。ＡＡＡサーバ１４６は、ユーザ認証およびユーザサービスのサポートを担当してもよい。ゲートウェイ１４８は、他のネットワークとの相互作用を容易にしてもよい。例えば、ゲートウェイ１４８は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに、ＰＳＴＮ１０８などの回線交換ネットワークへのアクセスを提供して、ＷＴＲＵ １０２ａ、１０２ｂ、１０２ｃと従来型固定通信デバイスとの間の通信を容易にしてもよい。加えて、ゲートウェイ１４８は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに、他のサービスプロバイダによって所有および／または操作される他の有線または無線ネットワークを含むことができる、ネットワーク１１２へのアクセスを提供してもよい。

【0037】

図１Ｃには示されていないが、ＲＡＮ１０４は、他のＡＳＮに接続されてもよく、および、コアネットワーク１０６は、他のコアネットワークに接続されてもよいことを理解されよう。ＲＡＮ１０４と他のＡＳＮとの間の通信リンクは、ＲＡＮ１０４と他のＡＳＮとの間のＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃのモビリティを調整するためのプロトコルを含むことができる、Ｒ４参照ポイントとして定義されてもよい。コアネットワーク１０６と他のコアネットワークとの間の通信リンクは、ホームコアネットワークと移動先コアネットワークとの間の相互作用を容易にするためのプロトコルを含むことができる、Ｒ５参照として定義されてもよい。

【0038】

他のネットワーク１１２はさらに、ＩＥＥＥ８０２．１１ベースの無線ローカルエリアネットワーク（ＷＬＡＮ）１６０に接続されてもよい。ＷＬＡＮ１６０は、アクセスルータ１６５を含んでもよい。アクセスルータは、ゲートウェイ機能を含んでもよい。アクセスルータ１６５は、複数のアクセスポイント（ＡＰ）１７０ａ、１７０ｂと通信してもよい。アクセスルータ１６５とＡＰ１７０ａ、１７０ｂとの間の通信は、有線イーサネット（登録商標）（ＩＥＥＥ ８０２．３規格）、または任意のタイプの無線通信プロトコルを介してもよい。ＡＰ１７０ａは、エアインタフェース上でＷＴＲＵ１０２ｄと無線通信している。

【0039】

インフラストラクチャ基本サービスセット（ＢＳＳ）モードにおける無線ローカルエリアネットワーク（ＷＬＡＮ）は、ＢＳＳに対するアクセスポイント（ＡＰ）、およびＡＰと関連付けられた１または複数の局（ＳＴＡ）を有してもよい。ＡＰは、配信システム（ＤＳ）、または、ＢＳＳにおけるトラフィックおよびＢＳＳの外側のトラフィックを搬送する別のタイプの有線もしくは無線ネットワークへのアクセスまたはインタフェースを有してもよい。ＢＳＳの外側から発するＳＴＡへのトラフィックは、ＡＰを通じて到着し、およびＳＴＡに配信される。ＳＴＡから発生し、ＢＳＳの外側を宛先とするトラフィックは、ＡＰに送信されて、そのそれぞれの宛先に配信される。ＢＳＳ内のＳＴＡ間のトラフィックはまた、ＡＰを通じて送信されてもよく、ソースＳＴＡはＡＰにトラフィックを送信し、ＡＰはトラフィックを宛先ＳＴＡに配信する。ＢＳＳ内のＳＴＡ間のトラフィックは、ピアツーピアトラフィックである。ピアツーピアトラフィックはまた、米国電気電子技術者協会（ＩＥＥＥ）８０２．１１ｅ ＤＬＳ、またはＩＥＥＥ８０２．１１ｚトンネルＤＬＳ（ＴＤＬＳ）を使用して、ダイレクトリンクセットアップ（ＤＬＳ）でソースＳＴＡと宛先ＳＴＡとの間で直接送信されてもよい。独立ＢＳＳモードにおけるＷＬＡＮはＡＰを有さず、ＳＴＡは互いに直接通信する。

【0040】

＜説明＞

【0041】

初期リンクセットアッププロセスならびに高速初期リンクセットアップ（ＦＩＬＳ：Fast Initial Link Setup）が説明される。

【0042】

ロバストセキュリティネットワークアソシエーション（ＲＳＮＡ：Robust Security Network Association）セキュリティレベルを維持しつつ、１００ミリ秒未満の初期リンクセットアップ時間が、ＩＥＥＥ ８０２．１１通信において要求される１つのベンチマークである。初期リンクセットアップ時間は、ＡＰを通じて有効なＩＰアドレスでインターネットプロトコル（ＩＰ）トラフィックを送信する能力を得るために必要とされる時間として定義されてもよい。さらに、１秒以内に少なくとも１００の非ＡＰ ＳＴＡがＥＳＳに入り、リンクセットアップに成功するという最小ユーザ負荷サポートが、１つのベンチマークである。加えて、高バックグラウンド負荷の存在において少なくとも５０％の媒体負荷に対するリンクセットアップを提供するロバスト性が、別のベンチマークである。

【0043】

ＦＩＬＳプロセスは、５つのフェーズ、ＡＰ発見（AP discovery）、ネットワーク発見（network discovery）、追加のタイミング同期機能（ＴＳＦ）、認証およびアソシエーション、ならびに上位レイヤＩＰセットアップを備えてもよい。

【0044】

図２は、ＩＥＥＥ８０２．１１リンクセットアップの例を示す。図２では、拡張可能認証プロトコル（ＥＡＰ：Extensible Authentication Protocol）が使用される。図２に示されるのは、ＳＴＡによるアクティブスキャンニングまたはパッシブ（passive）スキャンニングのいずれかを使用して達成することができるＡＰ発見２０２の５つのフェーズ、ネットワーク発見２０４、追加のＴＳＦ２０６、認証２０８およびアソシエーション２１０、ならびに上位レイヤＩＰセットアップ２１２である。

【0045】

説明は、アクティブスキャンニングおよびＦＩＬＳをより詳細に述べる。

【0046】

２つのタイプのスキャンニング、アクティブおよびパッシブスキャンニングが存在してもよい。本明細書では、アクティブスキャンニングおよびＦＩＬＳが説明される。パッシブスキャンニングは、以下のように特徴付けられる。

【0047】

（１）ＳＴＡは、ＡＰにいかなる信号も送信しなくてもよい。

【0048】

（２）ＳＴＡは、各チャネル、例えば、候補チャネルリスト上の各チャネルに同調し、および、ビーコンフレームを待機する。

【0049】

（３）受信されるすべてのビーコンはバッファリングされて、ビーコンを送信したＢＳＳに関する情報を取り出してもよい。

【0050】

パッシブスキャンニングでは、低オーバーヘッドが存在し、および、フレーム交換はなく、ならびに、潜在的に遅く、スキャンニングはビーコン間隔に依存する。

【0051】

アクティブスキャンニングは、以下のように特徴付けられる。

【0052】

（１）各チャネル上で、ＳＴＡはアクセス権を取得した後に、プローブ要求を送信してもよい。

【0053】

（２）ＳＴＡは、プローブ応答を待機してもよい。

【0054】

（３）プローブ応答は、受信を確認される（ACKed）必要のあるユニキャスト管理フレームであってもよい。

【0055】

アクティブスキャンニングでは、それは１対１（one-on-one）として設計されているので、ビーコンに比べて速度が上がってもよく、また、高オーバーヘッドが存在し、アクティブスキャンニングは、輻輳したシナリオに設計されなくてもよい。

【0056】

スキャンニングプロセスの終わりに、全ての発見されたＢＳＳおよびそのパラメータをリスト化するスキャンレポートが生成されてもよい。これらのパラメータは、ＢＳＳ識別（ＢＳＳＩＤ）、サービスセットＩＤ（ＳＳＩＤ）、ＢＳＳタイプ、ビーコン間隔、タイミングパラメータ、および物理レイヤ（ＰＨＹ）パラメータなどであってもよい。ＳＴＡは、基準に従って参加するＢＳＳまたはＡＰを選択してもよい。

【0057】

次に、改良（enhanced）アクティブスキャンニングを述べる。

【0058】

図３は、アクティブスキャンニングの例を示す。フィルタリストがプローブ要求フレーム３０４に追加されて、要求ＳＴＡがより正確に応答することができるＡＰを定義することを可能にする。プローブ要求フレーム３０４の送信機３０２は、それがプローブ応答フレーム３０６を受信するために利用可能な最大チャネル時間（Ｍａｘ ＣＨＡＮＮＥＬ Ｔｉｍｅ）を示してもよい。プローブ要求フレーム３０４の送信機３０２は、プローブ終了フレーム（Ｐｒｏｂｅ Ｅｎｄ ｆｒａｍｅ）をＡＰに送信することによって、保留（pending）プローブ応答フレーム３０６の送信をキャンセルしてもよく、したがって、プローブ要求フレームの送信機が別のチャネルをスキャンすることに切り替える場合、プローブ応答の不必要な再送信を回避する。

【0059】

プローブ応答３０６は、ブロードキャストアドレスに送信されてもよく、および、プローブ応答フレームは、他のＢＳＳからの情報を含んでもよい。ＡＰ３０８が、そのＢＳＳからの情報を含むプローブ応答３０６をオーバーヒアする（overhear）場合、ＡＰは、そのプローブ応答フレームの送信をキャンセルしてもよい。ＡＰ３０８が、複数のプローブ要求フレーム３０４を受信する場合、ＡＰ３０８は、１つのプローブ応答フレーム３０６を複数の要求への応答として送信してもよい。同様にビーコンは、プローブ応答として使用されてもよく、したがって、同一の情報の重複送信を排除することができる。加えて、プローブ応答フレームは、スキャンされることになるチャネルの数を減らすように、そのプライマリチャネルがスキャンされるチャネル以外であるＢＳＳに関する情報を含んでもよい。

【0060】

説明は、アクティブスキャンニングパラメータを述べる。

【0061】

アクティブスキャンニングが説明される。本明細書ではＭＬＭＥ−ＳＣＡＮ−ＳＴＯＰ．ｒｅｑｕｅｓｔと称されるプリミティブがまた、本明細書で説明される。ＭＬＭＥ−ＳＣＡＮ−ＳＴＯＰ．ｒｅｑｕｅｓｔプリミティブパラメータは、以下のように、ＭＬＭＥ−ＳＣＡＮ−ＳＴＯＰ．ｒｅｑｕｅｓｔ（ＳｃａｎＳｔｏｐＴｙｐｅ、ＢＳＳＩＤ、ＳＳＩＤ、ＳＳＩＤＬｉｓｔ、ＨＥＳＳＩＤ、メッシュＩＤ（Ｍｅｓｈ ＩＤ）、（フィルタリスト（Ｆｉｌｔｅｒ Ｌｉｓｔ）、ＶｅｎｄｏｒＳｐｅｃｉｆｉｃＩｎｆｏ）である。表１は、ＭＬＭＥ−ＳＣＡＮ−ＳＴＯＰ．ｒｅｑｕｅｓｔプリミティブのパラメータのタイプ、有効範囲、および説明を示す。

【0062】

【表1】

【0063】

ＭＬＭＥ−ＳＣＡＮ−ＳＴＯＰ．ｒｅｑｕｅｓｔプリミティブは、ＳＴＡに対してＳＭＥによって生成されて、進行中の任意のスキャンプロセスを停止し、または、進行中のスキャンに対する新たな基準を設定してもよい。

【0064】

ＭＬＭＥ−ＳＣＡＮ−ＳＴＯＰ．ｒｅｑｕｅｓｔプリミティブの受信の効果は、進行中のスキャンプロシージャを終了し、および、プローブ終了フレームを送信することであってもよい。スキャン終了の確認は、ＭＬＭＥ−ＳＣＡＮ．ｃｏｎｆｉｒｍプリミティブを通じて規定されてもよい。

【0065】

本明細書では「フィルタリスト」と称されるフィールドが、ＭＬＭＥ−Ｓｃａｎ．ｒｅｑｕｅｓｔプリミティブに追加されてもよい。リストは、要求を無視することができるＨＥＳＳＩＤ、メッシュＩＤ、ＳＳＩＤ、およびＢＳＳＩＤを指定する。

【0066】

アクティブスキャンを示しているスキャンタイプを有するＭＬＭＥ−ＳＣＡＮ．ｒｅｑｕｅｓｔプリミティブを受信すると、ＳＴＡは、スキャンされることになる各チャネルに対して以下を実行してもよい。

【0067】

ａ）ＰｒｏｂｅＤｅｌａｙ時間が満了し、またはＰＨＹＲｘＳｔａｒｔ．ｉｎｄｉｃａｔｉｏｎプリミティブが受信されるまで待機する。

【0068】

ｂ）基本アクセスプロシージャを実行する。

【0069】

ｃ）ＭＬＭＥ−ＳＣＡＮ．ｒｅｑｕｅｓｔプリミティブからのＳＳＩＤおよびＢＳＳＩＤとともに、ブロードキャスト宛先アドレスにプローブ要求を送信する。ＭＬＭＥ−ＳＣＡＮ．ｒｅｑｕｅｓｔプリミティブにＳＳＩＤリストが存在するときに、ＳＳＩＤリストに示されるＳＳＩＤおよびＭＬＭＥ−ＳＣＡＮ．ｒｅｑｕｅｓｔプリミティブからのＢＳＳＩＤをそれぞれ有する、１または複数のプローブ要求フレームを送信する。

【0070】

ｄ）プローブタイマ（ＰｒｏｂｅＴｉｍｅｒ）を０に設定し、プローブタイマを起動する。

【0071】

ｅ）プローブタイマが最小チャネル時間（ＭｉｎＣｈａｎｎｅｌＴｉｍｅ）に到達する前に、ＰＨＹ−ＣＣＡ．ｉｎｄｉｃａｔｉｏｎ（ｂｕｓｙ）プリミティブが検出されていない場合、ＮＡＶを０に設定し、次のチャネルをスキャンする。他には、ＭＬＭＥは、プローブ応答またはビーコンフレームが初めてＡＰから受信されるとき、ＡＰの情報を含むＢＳＳＤｅｓｃｒｉｐｔｉｏｎＳｅｔを有するＭＬＭＥ−ＳＣＡＮ．ｒｅｃｅｉｖｅｄプリミティブを発行してもよい。ＰｒｏｂｅＴｉｍｅｒが最大チャネル時間（ＭａｘＣｈａｎｎｅｌＴｉｍｅ）に到達するときに、ＮＡＶを０に設定し、次のチャネルをスキャンする。

【0072】

チャネルリスト（ＣｈａｎｎｅｌＬｉｓｔ）におけるすべてのチャネルがスキャンされると、ＭＬＭＥは、スキャンの間に集められたすべての情報を含むＢＳＳ記述セット（ＤｅｓｃｒｉｐｔｉｏｎＳｅｔ）を有するＭＬＭＥ−ＳＣＡＮ．ｒｅｃｅｉｖｅｄプリミティブを発行してもよい。ＭＬＭＥがＭＬＭＥ−ＳＣＡＮ−ＳＴＯＰ．ｒｅｑｕｅｓｔプリミティブを受信する場合、ＳＴＡは、ＦＩＬＳ要求パラメータのＴｅｒｍｉｎａｔｅ Ａｌｌ Ｒｅｑｕｅｓｔｓフィールドを１に設定したプローブ終了フレームを送信し、および、進行中のスキャンプロセスを停止してもよい。ＭＬＭＥは、集められた情報を含み、および、ＳＣＡＮ＿ＡＢＯＲＴＥＤに設定されたＲｅｓｕｌｔＣｏｄｅを有するＢＳＳＤｅｓｃｒｉｐｔｉｏｎＳｅｔを有する、ＭＬＭＥ−ＳＣＡＮ．ｃｏｎｆｉｒｍプリミティブを発行してもよい。

【0073】

説明は、プローブ要求への応答をキャンセルすること、およびプローブ終了フレームを述べる。

【0074】

本明細書では、プローブ終了でプローブ要求への応答をキャンセルすることが説明される。プローブ要求フレームのジェネレータが、プローブ終了フレームをブロードキャストアドレスまたは個々のアドレスに送信してもよい。プローブ終了フレームを受信したＳＴＡが、送信を開始しておらず、または、プローブ終了フレームの送信機にプローブ応答フレームを送信している場合、プローブ要求フレームへの応答は、以下の基準が満たされるという条件で、送信されてもよい。

【0075】

ａ）プローブ終了フレームのフィルタリストにおけるＢＳＳタイプ要素のＴｅｒｍｉｎａｔｅ Ａｌｌ Ｒｅｑｕｅｓｔｓフィールドは、０に設定される。

【0076】

ｂ）ＳＴＡは、ＡＰ ＳＴＡであり、プローブ終了フレームのフィルタリストにおけるＢＳＳタイプ要素のインフラストラクチャ（Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ）フィールドは０に設定され、または、ＳＴＡのＳＳＩＤ、ＢＳＳＩＤ、もしくは同種ＥＳＳ識別子（ＨＥＳＳＩＤ）が、プローブ終了フレームのフィルタリストに含まれていない。または、

【0077】

１）ＳＴＡのＢＳＳは、独立したＢＳＳ（ＩＢＳＳ）であり、プローブ終了フレームのフィルタリストにおけるＢＳＳタイプ要素のＩＢＳＳフィールドは０に設定され、または、ＳＴＡのＳＳＩＤもしくはＢＳＳＩＤは、プローブ終了フレームのフィルタリストに含まれていない。または、

【0078】

２）ＳＴＡは、メッシュＳＴＡであり、プローブ終了フレームのフィルタリストにおけるＢＳＳタイプ要素のメッシュＢＳＳ（ＭＢＳＳ）フィールドは０に設定され、または、メッシュＳＴＡのメッシュＩＤもしくはＭＡＣアドレスは、プローブ終了フレームのフィルタリストに含まれない。

【0079】

上記の基準が満たされない場合、プローブ終了フレームの受信側は、プローブ応答フレームへの応答を一度送信し、または、再送信してもよいが、応答は、二度以上送信され、または、再送信されなくてもよいことが要件となってもよい。

【0080】

説明は、簡易プローブ応答を述べる。

【0081】

簡易プローブ応答では、ＡＰが、ＳＴＡ（例えば、ＳＴＡ１）によって送信されたプローブ要求に応答して、通常のプローブ応答フレームを送信してもよい。別のＳＴＡ（例えば、ＳＴＡ２）からのプローブ要求への応答において（応答が簡易化されているか否か）、ＡＰは、以前に送信された通常のプローブ応答への参照を有することによって、簡易プローブ応答をＳＴＡ２に送信してもよい。これは、ＳＴＡ２が通常のプローブ応答をリスンしていることをＡＰが認識している限り行われてもよい。例えば、ＡＰは、それが通常のプローブ応答を送信する直前に、ＳＴＡ２からプローブ要求を受信してもよく、または、第２のプローブ要求は、第１のプローブ要求を参照する簡易プローブ要求であり、ＳＴＡ２が、それが第１のプローブ要求を受信して以来、アウェイクし、および、チャネルをリッンしていることを要求されることを示している。

【0082】

簡易プローブ応答は、例えば、以前に送信されたプローブ応答におけるシーケンス制御番号をコピーするプローブ応答参照フィールドまたはＩＥを参照情報として含んでもよい。簡易プローブ応答のターゲットの受信側は、参照情報を使用して、以前に受信された、参照されるプローブ応答を一意に識別してもよい。

【0083】

説明は、差異化（differentiated）初期リンクセットアップを述べる。

【0084】

差異化初期リンクセットアップでは：

【0085】

ＡＰは、ビーコン、ＦＩＬＳ発見フレーム、およびプローブ応答などのフレームにおいて、要素ＩＤ ３５２および長さ３５４に加えて以下のフィールドを有する、図３Ａに示すような初期リンクセットアップ（ＩＬＳ）要素を含んでもよい。

【0086】

初期リンクセットアップカテゴリ（ＩＬＳＣ）ビットマップ３５６：ＳＴＡのどのＩＬＳカテゴリが、以下の期間にＡＰに関連付けることを試みるかを示す８ＩＬＳＣビットを含むビットマップ。

【0087】

ＩＬＳ時間３５８：ＩＬＳＣビットが０に設定されたＳＴＡが、ＡＰに関連付けることを試みることを許可されない期間のインジケーション。

【0088】

説明は、使用において直面されることがあるいくつかのシナリオを述べる。

【0089】

第１のシナリオにおいて、初期リンクセットアップを要求している多数のＳＴＡが、同時にＢＳＳに入るとき、アクティブスキャンニングを行っているＳＴＡは、ＡＰにプローブ要求フレームを送信してもよい。例えば、東京駅における実際のトラフィック測定に基づいて、プローブ応答パケット数は、プローブ要求パケット数よりも約４から５倍多く、これは、各プローブ要求パケットが、平均で４から５のプローブ応答パケットをトリガすることを示す。これは、ワイルドカードＳＳＩＤを有するプローブ要求フレームを使用した結果となる。さらに、プローブ要求／応答パケットによるエアタイム占有率（air time occupancy）は、約１８．３２％となる。加えて、プローブ要求／応答パケットの数は、全パケットの３５％であり、これは、チャネルアクセス衝突および遅延の可能性を増大させ、したがって、ＡＰのアクティブスキャンニングに対する遅延時間を生じさせる結果となる。ゆえに、初期リンクセットアップを要求しているＳＴＡによって送信されるプローブ要求フレームの不要な送信を回避することが望ましい。加えて、ワイルドカードＳＳＩＤを有するプローブ要求の送信を最小化することがまた望まれる。

【0090】

第２のシナリオでは、送信したプローブ要求フレームへの応答を受信することに成功したＳＴＡが、プローブ要求終了フレームをＡＰに送信して、プローブ要求への応答のいかなる保留送信をキャンセルしてもよい。しかしながら、ＳＴＡは、チャネル上の他のＳＴＡのスキャンニングが成功したか否かを（すなわち、プローブ応答またはビーコンが受信されるか否かを）を認識していないことがある。プローブ応答フレームのキャンセルが、初期リンクセットアップを求めている他のＳＴＡに対して問題を引き起こすことがあることを示す例が得られる。

【0091】

図４は、プローブ応答キャンセルの例を示す。例えば、ＳＴＡ１ ４０２が、ＡＰ１／ＢＳＳ１ ４０４およびＡＰ２／ＢＳＳ２ ４０６をヒアする（hear）ことが可能であるが、ＳＴＡ２ ４０８は、ＡＰ１／ＢＳＳ１ ４０４をヒアすることができず、ＡＰ２／ＢＳＳ２ ４０６をヒアすることが可能なシナリオを考慮する。さらにＳＴＡ１ ４０２は、ＡＰ１ ４０４およびＡＰ２ ４０６によって受信されるプローブ要求を送信し、ＡＰ２／ＢＳＳ２ ４０６の情報を成功して含む、ＡＰ１ ４０４からのプローブ要求への応答を受信する。ＡＰ２ ４０６は、ＡＰ１ ４０４によって送信されたそのＢＳＳとともにプローブ要求への応答をオーバーヒアし、ＳＴＡ１ ４０２からのプローブ要求に応答するためのプローブ応答フレームを送信しないことがある。しかしながら、ＳＴＡ２ ４０８は、ＡＰ１ ４０４から遠く離れているために、応答を受信しない。その後、ＳＴＡ２ ４０８は、ＡＰ２ ４０６にプローブ要求を送信する。次いで、ＡＰ２ ４０８が第２のプローブ要求への応答の送信を開始する前に、ＡＰ１ ４０４およびＡＰ２ ４０６の両方が、ＳＴＡ１ ４０２からプローブ終了フレームを受信する。

【0092】

図５は、プローブ応答キャンセルの例を示す。ＳＴＡ１ ５０２が、ＡＰ１ ５００にプローブ要求５０４を送信し、および、ＡＰ１ ５００からプローブ要求５０４への応答５０５を成功して受信する。ＳＴＡ２ ５０６が、ＡＰ１ ５００にプローブ要求５０８を送信する。ＡＰ１ ５００は、ＳＴＡ１ ５０２からプローブ終了５１０フレームを受信し、および、第２のプローブ要求５０８への応答の送信を開始する前に、５１２において応答を生じさせる。

【0093】

上記の両方の例は、プローブ応答のキャンセルが、ＳＴＡ２がＡＰのスキャニングに遅延を引き起こすことがあることを示す。したがって、アクティブスキャンニングの適正な動作を保証するために、プローブ終了フレームを受信するとプローブ応答の適切なキャンセルを可能にすることが望ましい。

【0094】

第３のシナリオでは、ＦＩＬＳにおいて、高バックグラウンド負荷の存在下でのロバスト性が望ましいことがある。さらに、少なくとも５０％の媒体負荷に対するリンクセットアップを提供することを示すことが望ましい。しかしながら、ＦＩＬＳプロセスを容易にするために使用されるパケットは、管理（Ｍａｎａｇｅｍｅｎｔ）タイプであってもよい。管理フレームは、アクセスカテゴリ（ＡＣ）ＡＣ＿ＶＯを使用して送信されてもよい。高バックグラウンド負荷の存在下では、ＦＩＬＳにおいて使用される管理フレームは、ＡＣ＿ＶＯを使用する他の（データまたは管理）フレームと同一の優先度を使用する媒体アクセスに対して、衝突および競合することがあり、これが初期リンクセットアップにおいて遅延を引き落とすことがある。

【0095】

第４のシナリオでは、簡易プローブ要求および応答を使用するアクティブスキャンニングスキームが望ましいことがある。プローブ要求および応答の応用は、２つのプローブ要求または２つのプローブ応答が、それらのパラメータの大部分に対して同一の値を有するか、または、それらが一部のパラメータに対して異なる値を有するかに依存することがある。

【0096】

１つのシナリオに対する議論が他のシナリオに適用可能であるという理解のもとで、上記のシナリオの各々がさらに詳細に議論される。第１のシナリオでは、ＳＴＡが、アクティブスキャンを示しているスキャンタイプを有するＭＬＭＥ−ＳＣＡＮ．ｒｅｑｕｅｓｔプリミティブの受信後であるが、プローブ遅延時間の満了、またはＰＨＹＲｘＳｔａｒｔ．ｉｎｄｉｃａｔｉｏｎの受信およびチャネルアクセスを取得する状態の前に、保留プローブ要求を送信させるとみなされてもよい。

【0097】

３種類の保留プローブ要求、特定のＳＳＩＤ／ＳＴＡに対してターゲットとされるプローブ要求、ＳＳＩＤリストに対してターゲットとされるプローブ要求、またはワイルドカードＳＳＩＤに対してターゲットとされるプローブ要求が存在してもよい。

【0098】

ある条件が満たされる場合、保留プローブ要求またはオーバーヒアされるプローブ要求が、一致したスキャニングターゲットまたはパラメータを有するとみなされてもよい。

【0099】

第１のケースにおいて、対象の保留プローブ要求が特定のＳＳＩＤまたは第２のＳＴＡの特定の媒体アクセス制御（ＭＡＣ）アドレスのターゲットとされる場合、ａ）オーバーヒアされるプローブ要求におけるアドレス１フィールドは、ブロードキャストアドレスまたは第２のＳＴＡの特定のＭＡＣアドレスであってもよく、以下の項目ｂ）または項目ｃ）のいずれかが満たされる。

【0100】

ｂ）保留要求においてターゲットとされるＳＳＩＤ／ＳＴＡは、メッシュＩＤ／ＳＴＡであってもよく、オーバーヒアされるプローブ要求におけるフィルタリストは、保留要求における第２のＳＴＡのメッシュＩＤまたは特定のＭＡＣアドレスを含まなくてもよく、オーバーヒアされるプローブ要求におけるメッシュＩＤは、ワイルドカードメッシュＩＤまたは保留要求における第２のＳＴＡの特定のメッシュＩＤである。

【0101】

ｃ）保留要求におけるターゲットとされるＳＳＩＤ／ＳＴＡは、メッシュＳＳＩＤ／ＳＴＡでなくてもよく、オーバーヒアされるプローブ要求におけるフィルタリストは、保留要求における第２のＳＴＡの特定のＳＳＩＤまたは特定のＭＡＣアドレスを含まなくてもよく、オーバーヒアされるプローブ要求におけるＳＳＩＤは、ワイルドカードＳＳＩＤであってもよく、オーバーヒアされるプローブ要求におけるＳＳＩＤは、保留プローブ要求における第２のＳＴＡの特定のＳＳＩＤであってもよく、または、保留プローブ要求の特定のＳＳＩＤは、オーバーヒアされるプローブ要求のＳＳＩＤリスト要素に含まれてもよく、オーバーヒアされるプローブ要求におけるアドレス３フィールドは、ワイルドカードＢＳＳＩＤまたは保留プローブ要求における第２のＳＴＡのＢＳＳＩＤであってもよい。

【0102】

第２のケースにおいて、対象の保留プローブ要求が、ワイルドカードＳＳＩＤに対してターゲットとされる場合、ａ）オーバーヒアされるプローブ要求におけるアドレス１フィールドは、ブロードキャストアドレスであってもよく、項目ｂ）または項目ｃ）のいずれかが満たされてもよい。

【0103】

ｂ）オーバーヒアされるプローブ要求におけるメッシュＩＤは、ワイルドカードメッシュＩＤ、または保留要求における第２のＳＴＡの特定のメッシュＩＤであってもよい。

【0104】

ｃ）保留要求におけるターゲットとされるＳＳＩＤ／ＳＴＡは、メッシュＳＳＩＤ／ＳＴＡでなくてもよく、オーバーヒアされるプローブ要求におけるＳＳＩＤは、ワイルドカードＳＳＩＤであり、オーバーヒアされるプローブ要求におけるアドレス３フィールドは、ワイルドカードＢＳＳＩＤである。

【0105】

第３のケースにおいて、対象の保留プローブ要求が、特定のＳＳＩＤリストに対してターゲットとされる場合、ａ）プローブ要求におけるアドレス１フィールドは、ブロードキャストアドレスであってもよく、項目ｂ）または項目ｃ）のいずれかが満たされてもよい。

【0106】

ｂ）保留要求におけるターゲットとされるＳＳＩＤリストは、メッシュＩＤ／ＳＴＡのリストであってもよく、オーバーヒアされるプローブ要求におけるフィルタリストは、保留要求におけるターゲットとされるＳＳＩＤリストを含まなくてもよく、オーバーヒアされるプローブ要求におけるメッシュＩＤは、ワイルドカードメッシュＩＤであってもよい。

【0107】

ｃ）保留要求におけるターゲットとされるＳＳＩＤリストは、メッシュＳＳＩＤ／ＳＴＡのリストではなくてもよく、オーバーヒアされるプローブ要求におけるフィルタリストは、保留要求におけるターゲットとされるＳＳＩＤリストを含んでもよく、オーバーヒアされるプローブ要求におけるＳＳＩＤは、ワイルドカードＳＳＩＤであってもよく、または保留プローブ要求における特定のＳＳＩＤリストは、オーバーヒアされるプローブ要求のＳＳＩＤリスト要素に含まれてもよく、オーバーヒアされるプローブ要求におけるアドレス３フィールドは、ワイルドカードＢＳＳＩＤであてもよい。

【0108】

第１のシナリオに関する第１の考えられる方法では、図６を参照して、プローブ要求フレームの数を削減するために、初期リンクセットアップを求めているＳＴＡ２ ６０６が、それが、一致したスキャンニングターゲットまたはパラメータを有するプローブ要求フレーム６０４をオーバーヒアする場合、そのプローブ要求６０８をキャンセルしてもよい。さらに、対応するプローブ応答６０５は、同様にＳＴＡ２ ６０６によって受信されてもよい。

【0109】

アクティブスキャンニングプロシージャ、アクティブスキャンを示すスキャンタイプを有するＭＬＭＥ−ＳＣＡＮ．ｒｅｑｕｅｓｔプリミティブを受信すると、ＳＴＡ２ ６０６が、以下を実行してもよい。

【0110】

スキャンされることになる各チャネルに対し、ａ）プローブ遅延時間が満了するまで、または、ＰＨＹＲｘＳｔａｒｔ．ｉｎｄｉｃａｔｉｏｎプリミティブが受信されるまで待機する。加えて、ＳＴＡ２ ６０６は、プローブ遅延タイマ６１０が満了し、または、次の条件が満たされる場合にＰＨＹＲｘＳｔａｒｔ．ｉｎｄｉｃａｔｉｏｎプリミティブが受信される前に、第２のＳＴＡに対するそのプローブ要求６０８を送信する試みをキャンセルしてもよい。ＳＴＡ２ ６０６は、ＳＴＡ１ ６０２からのプローブ要求６０４フレームをオーバーヒアし、受信したプローブ要求６０４フレームのＲＳＳＩは、予め定義された閾値未満でなく、および、オーバーヒアしたプローブ要求６０４は、保留プローブ要求と一致したスキャンニングターゲットまたはパラメータを有する。

【0111】

ｂ）基本アクセスプロシージャを実行する。加えて、ＳＴＡ２ ６０６は、以下の条件が満たされる場合にのみ、媒体へのアクセス権を取得する前に、第２のＳＴＡに対するそのプローブ要求６０８を送信する試みをキャンセルしてもよい。ＳＴＡ２ ６０６は、プローブ要求６０４フレームをオーバーヒアし、受信したプローブ要求６０４フレームのＲＳＳＩは、予め定義された閾値未満でなく、および、オーバーヒアしたプローブ要求６０４は、保留プローブ要求と一致したスキャンニングターゲットを有する。

【0112】

上記のａ）およびｂ）では、ＳＭＥとＭＬＭＥとの間のプリミティブを通じて、プローブ要求のキャンセルが行われてもよい。前述の条件を満たすプローブ要求フレームをオーバーヒアすると、ＳＭＥは、現在のチャネルのアクティブスキャンニングを停止するためにＭＬＭＥ−Ｓｃａｎ−ＳＴＯＰ．ｒｅｑｕｅｓｔ ６１２プリミティブを生成してもよい。（これは、プローブ要求送信をキャンセルするための方法の１つである。他の方法が存在する。例えば、ＭＡＣレイヤは、プローブ要求を送信せず、代わりにより長い時間の間、応答の受信を待ちながら待機してもよい。）これは、例として説明される以下のうちの１つによって実現されてもよい。

【0113】

第１の例では、新たな値「Ｓｔｏｐ ｃｕｒｒｅｎｔ ｃｈａｎｎｅｌ」が、ＭＬＭＥ−Ｓｃａｎ−ＳＴＯＰ．ｒｅｑｕｅｓｔ ６１２プリミティブにおけるＳｃａｎＳｔｏｐＴｙｐｅのフィールドに追加されてもよい。ＭＬＭＥ−Ｓｃａｎ−ＳＴＯＰ．ｒｅｑｕｅｓｔ ６１２は、ＳｃａｎＳｔｏｐＴｙｐｅのフィールドが「Ｓｔｏｐ ｃｕｒｒｅｎｔ ｃｈａｎｎｅｌ」に設定されて生成されてもよい。

【0114】

第２の例では、新たな値「Ｓｔｏｐ」が、ＳｃａｎＳｔｏｐＴｙｐｅのフィールドに追加され、「ＣｈａｎｎｅｌＩｎｄｅｘ」の新たなフィールドが、ＭＬＭＥ−Ｓｃａｎ−ＳＴＯＰ．ｒｅｑｕｅｓｔ ６１２プリミティブにおいて追加される。ＭＬＭＥ−Ｓｃａｎ−ＳＴＯＰ．ｒｅｑｕｅｓｔ６１２は、ＳｃａｎＳｔｏｐＴｙｐｅのフィールドが「Ｓｔｏｐ」に設定され、および、「ＣｈａｎｎｅｌＩｎｄｅｘ」のフィールドが現在のチャネルのインデックスに設定されて、生成されてもよい。

【0115】

第３の例では、「ＣｈａｎｎｅｌＬｉｓｔ」の新たなフィールドが、ＭＬＭＥ−Ｓｃａｎ−ＳＴＯＰ．ｒｅｑｕｅｓｔ６１２プリミティブにおいて追加される。ＭＬＭＥ−Ｓｃａｎ−ＳＴＯＰ．ｒｅｑｕｅｓｔ６１２は、ＳｃａｎＳｔｏｐＴｙｐｅのフィールドが「Ｓｅｔ＿Ｃｒｉｔｅｒｉａ」に設定され、および、「ＣｈａｎｎｅｌＬｉｓｔ」のフィールドが、対応するＭＬＭＥ−Ｓｃａｎ．ｒｅｑｕｅｓｔにおけるＣｈａｎｎｅｌＬｉｓｔに設定されて、現在のチャネルのインデックスを除いて生成されてもよい。

【0116】

一致したパラメータ／ターゲットを有するオーバーヒアされたプローブ要求の受信に起因して、ステップａ）またはｂ）における待機時間の間に現在のチャネルに対してプローブ要求がキャンセルされる場合、ＳＴＡは、プローブタイマを０に設定し、プローブタイマを開始してもよい。プローブタイマが最小チャネル時間に到達する前に、ＰＨＹ−ＣＣＡ．ｉｎｄｉｃａｔｉｏｎ（ｂｕｓｙ）プリミティブが検出されていない場合、ＮＡＶは０に設定され、および、次のチャネルがスキャンされてもよい。その他の場合は、ＭＬＭＥは、プローブ応答またはビーコンフレームが初めてＡＰから受信されるとき、ＡＰの情報を含むＢＳＳ記述セットを有するＭＬＭＥ−ＳＣＡＮ．ｃｏｎｆｉｒｍ６１４プリミティブを発行してもよい。プローブタイマが最大チャネル時間に到達するときに、ＮＡＶは０に設定され、および、次のチャネルがスキャンされてもよい。

【0117】

ＳＴＡ２ ６０６が、上記ａ）またはｂ）における待機時間の間に、一致したスキャンニングパラメータ／ターゲットを有するいかなるプローブ要求もオーバーヒアせず、ＳＴＡ２ ６０６が媒体へのアクセスを取得する場合、ＳＴＡ２ ６０６は、１または複数のプローブ要求フレームを、それぞれＭＬＭＥ−ＳＣＡＮ．ｒｅｑｕｅｓｔプリミティブからのＳＳＩＤおよびＢＳＳＩＤとともに送信してもよい。

【0118】

第１のシナリオに関する第２の考えられる方法において、別のアクティブスキャンニングプロシージャが説明される。アクティブスキャンを示しているスキャンタイプを有するＭＬＭＥ−ＳＣＡＮ．ｒｅｑｕｅｓｔプリミティブを受信すると、ＳＴＡは、スキャンされることになる各チャネルに対し、例えば、ＩＥＥＥ８０２．１１ＷＬＡＮ ＭＡＣまたはＰＨＹプロシージャごとに、プローブ遅延時間が満了し、または、ＰＨＹＲｘＳｔａｒｔ．ｉｎｄｉｃａｔｉｏｎプリミティブが受信されるまで待機してもよく（本明細書ではアクションａと称される）、基本アクセスプロシージャを実行してもよい（本明細書ではアクションｂと称される）。アクションａまたはアクションｂの間に、ＳＴＡはさらに、以下の条件、ＳＴＡがプローブ要求フレームをオーバーヒアする（本明細書では条件１と称される）、受信されたプローブ要求フレームのＲＳＳＩが閾値、例えば予め定義された閾値未満でない（本明細書では条件２と称される）、またはオーバーヒアされたプローブ要求が、ＳＴＡにおいて保留プローブ要求と一致するスキャンニングパラメータ／ターゲットを有する（本明細書では条件３と称される）場合、プローブ遅延タイマが満了し、またはＰＨＹＲｘＳｔａｒｔ．ｉｎｄｉｃａｔｉｏｎプリミティブが受信される前に、そのプローブ要求を送信する試みを停止またはキャンセルしてもよい。閾値は、ＳＴＡが、オーバーヒアされたプローブ要求に応答しているプローブ応答フレームを復号できないという条件付確率が、オーバーヒアされるＳＴＡがこのようなプローブ応答を復号する場合、所望のパーセンテージ（例えば１％）を超えないように、適度に高い値に設定されてもよい。

【0119】

あるいは、ＳＴＡは、上述した条件が満たされるとき、位置および時刻の予め取得した知識を使用して、そのプローブ要求を送信する試みを停止またはキャンセルするかをさらに決定してもよい。例えば、ＳＴＡは、ピーク時間の間に人口密度の高い位置（ピーク通勤時間における混雑した列車の駅など）にいることを認識してもよく、一致するスキャンニングパラメータ／ターゲットを有するプローブ要求フレームをオーバーヒアするときに、プローブ要求停止／削除（omission）を使用することを決定してもよい。一方では、ＳＴＡが、オフピーク時間の間に人口密度の低いエリアに（例えば、午前６時に公園に）いることを認識する場合、ＳＴＡは、プローブ要求停止／削除を使用しないことを決定してもよい。

【0120】

あるいは、ＳＴＡは、ＳＴＡがＷｉＦｉデバイス（例えば、ＩＥＥＥ ８０２．１１デバイス）の人口密集したエリアにいるかを判定してもよい。アクションａまたはｂの間に、平均受信信号／エネルギーレベル（ＰＨＹ＿ＣＣＡ．ｉｎｄｉｃａｔｅ（ＢＵＳＹ）時間内）が所定の閾値Ｓ１未満でない場合、ＳＴＡは、ＳＴＡがＷｉＦｉデバイスの人口密集したエリアにいると判定してもよく、条件１〜３が満たされるときに、プローブ要求停止／削除を使用してもよい。例えば、受信信号レベルの閾値は、
送信電力−パスロス（ｄ）−マージン 式１
のように設定されてもよい。

【0121】

ｄの値は、（プローブ要求の数およびアクティブスキャンニングの遅延のバランスをとるためのトレードオフに応じて）５メートルまたは１０メートルなどの短い距離に等しくてもよい。ＩＥＥＥ ８０２．１１における５ＧＨｚ帯に対し、送信電力は、２３デシベルミリワット（ｄＢｍ）であってもよく、ｄ＝５ｍにおけるシャドウフェージングのないパスロスは、５６．５ｄＢであってもよい。したがって、閾値は、−３３．５ｄＢｍ−マージンとして計算されてもよい。

【0122】

あるいは、ＳＴＡは、準ランダム期間（semi-random time period）を選択して、ＷｉＦｉデバイスの人口密集したエリアにおいてプローブ要求を送信してもよい。ランダム期間は、ＳＴＡのアクセスクラスに依存してもよく、例えば、マシンツーマシン（Ｍ２Ｍ）タイプＳＴＡは、他のタイプのＳＴＡよりも頻繁にプローブ要求を送信してもよい。

【0123】

プローブ要求のキャンセルは、ＳＭＥとＭＬＭＥとの間のプリミティブを介して（または説明したように他の方法を使用して）実行されてもよい。上述した条件を満たすプローブ要求フレームをオーバーヒアすると、ＳＭＥは、現在のチャネルのアクティブスキャンニングを停止することを示すＭＬＭＥ−Ｓｃａｎ−ＳＴＯＰ．ｒｅｑｕｅｓｔ ６１２プリミティブを生成してもよい。アクティブスキャンニングを停止すること、またはアクティブスキャンニングを停止することを示すことを実現するために、「Ｓｕｓｐｅｎｄ ｃｕｒｒｅｎｔ ｃｈａｎｎｅｌ」の新たな値が、ＭＬＭＥ−Ｓｃａｎ−ＳＴＯＰ．ｒｅｑｕｅｓｔプリミティブのＳｃａｎＳｔｏｐＴｙｐｅのフィールドに追加されてもよい。ＭＬＭＥ−Ｓｃａｎ−ＳＴＯＰ．ｒｅｑｕｅｓｔは、ＳｃａｎＳｔｏｐＴｙｐｅのフィールドが「Ｓｕｓｐｅｎｄ ｃｕｒｒｅｎｔ ｃｈａｎｎｅｌ」に設定されて生成されてもよい。

【0124】

さらに、「Ｓｕｓｐｅｎｄ」の新たな値は、ＳｃａｎＳｔｏｐＴｙｐｅのフィールドに追加されてもよく、「ＣｈａｎｎｅｌＩｎｄｅｘ」の新たなフィールドが、ＭＬＭＥ−Ｓｃａｎ−ＳＴＯＰ．ｒｅｑｕｅｓｔプリミティブにおいて追加されてもよい。ＭＬＭＥ−Ｓｃａｎ−ＳＴＯＰ．ｒｅｑｕｅｓｔは、ＳｃａｎＳｔｏｐＴｙｐｅのフィールドが「Ｓｕｓｐｅｎｄ」に設定され、「ＣｈａｎｎｅｌＩｎｄｅｘ」のフィールドが現在のチャネルのインデックスに設定されて、生成されてもよい。

【0125】

ＭＬＭＥ−Ｓｃａｎ−ＳＴＯＰ．ｒｅｑｕｅｓｔプリミティブの「ＣｈａｎｎｅｌＬｉｓｔ」の新たなフィールドはまた、追加されてもよい。ＭＬＭＥ−Ｓｃａｎ−ＳＴＯＰ．ｒｅｑｕｅｓｔは、ＳｃａｎＳｔｏｐＴｙｐｅのフィールドが「Ｓｅｔ＿Ｃｒｉｔｅｒｉａ」に設定され、「ＣｈａｎｎｅｌＬｉｓｔ」のフィールドが対応するＭＬＭＥ−Ｓｃａｎ．ｒｅｑｕｅｓｔ中のチャネルリストに設定され、現在のチャネルのインデックスを除いて生成されてもよい。

【0126】

現在のチャネルのアクティブスキャンニングを停止することを指示するＭＬＭＥ−Ｓｃａｎ−ＳＴＯＰ．ｒｅｑｕｅｓｔプリミティブを受信した後に、ＳＴＡは、プローブ要求フレームを送信することを停止し、プローブタイマを、現在の時刻から、停止を引き起こした一致したプローブ要求フレームをオーバーヒアした時刻を引いた値に設定し、プローブタイマを開始してもよい。これは、一致したプローブ要求フレームがオーバーヒアされたとき、プローブタイマをゼロに設定することに等しい。ＳＴＡは、プローブタイマが最小チャネル時間に到達する前に、チャネルを監視することを維持してもよく、以下の条件の１つが満たされた場合、ＳＴＡは、ＡＰが、オーバーヒアされたプローブ要求に応答してプローブ応答フレームをすでに送信したと考えてもよい。ＳＴＡはさらに、オーバーヒアされたプローブ要求に応答して送信されたプローブ応答フレームを復号することができないと判定してもよく、したがってそれ自身のプローブ要求フレームを送信してもよい。

【0127】

条件１：ＳＴＡは、それがプローブ要求をオーバーヒアした後の、少なくともＳＩＦＳ時間において、ある期間の間ビジーとされるチャネル媒体を検出していたが、有効なプローブ応答、ビーコン、またはＦＩＬＳ発見フレームは復号されない。さらに、ＳＴＡは、検出したビシーチャネル媒体時間の後のＳＩＦＳ時間にプローブ要求を送信したＳＴＡからのＡＣＫをオーバーヒアする。オーバーヒアされるＡＣＫに先行するチャネル媒体ビジー時間の例示的値は、プローブ応答、ビーコン、またはＦＩＬＳ発見フレームの送信時間に近い。

【0128】

条件２：ＳＴＡは、それがプローブ要求をオーバーヒアした後の少なくともＴ１時間に、プローブ要求を送信したＳＴＡからのＡＣＫをオーバーヒアする。Ｔ１の例示的な値は、プローブ応答、ビーコン、またはＦＩＬＳ発見フレームに２ＳＩＦＳ時間を加算したものに近くてもよい。

【0129】

条件２を容易にするために、ブロードキャスト／マルチキャストプローブ応答フレームにおけるフィールドが使用されて、要求ＳＴＡが、受信したプローブ応答フレームにＡＣＫで応答することができるように、プローブ応答を要求したＳＴＡを示してもよい。プローブ応答を要求したＳＴＡを識別する方法はいくつか存在する。

【0130】

１．そのプローブ要求がプローブ応答をトリガしたＳＴＡのＡＩＤまたは部分ＡＩＤ（ＰＡＩＤ：Partial AID）をシグナリングするプローブ応答フレームにおいて新たなフィールドまたは情報要素（ＩＥ）を追加する。

【0131】

２．そのプローブ要求がプローブ応答をトリガしたＳＴＡのＡＩＤまたは部分ＡＩＤ（ＰＡＩＤ）をシグナリングするプローブ応答フレームのＭＡＣヘッダにおいてＤｕｒａｔｉｏｎ／ＩＤフィールドを再利用する。

【0132】

３．ＰＬＣＰヘッダにおけるＳＩＧフィールド上のＰＡＩＤサブフィールドにおいて、そのプローブ要求がプローブ応答をトリガしたＳＴＡの部分ＡＩＤ（ＰＡＩＤ）を示す。

【0133】

ブロードキャスト／マルチキャストプローブ応答フレームを受信すると、プローブ要求を送信したスキャンＳＴＡは、受信したプローブ応答フレームにおけるＡＩＤ／ＰＡＩＤインジケーションがそのＡＩＤまたはＰＡＩＤに一致するかをチェックするべきである。一致した場合、それはＡＣＫで応答するべきである。

【0134】

ＰＨＹ−ＣＣＡ．ｉｎｄｉｃａｔｉｏｎ（ｂｕｓｙ）プリミティブが、プローブタイマが最小チャネル時間に到達する前に検出されなかった場合、ＳＴＡは、プローブ要求を送信する試みが停止またはキャンセルされる前のチャネルビジー時間の間の平均受信信号／エネルギーレベルが、所定の閾値、Ｓ１未満でない場合、その自身のプローブ要求フレームを送信してもよい。その他の場合、ＳＴＡは、ＮＡＶを０に設定し、次のチャネルをスキャンしてもよい。

【0135】

プローブタイマが最小チャネル時間に到達する前に、ＳＴＡが有効なプローブ応答、ビーコン、またはＦＩＬＳ発見フレームを受信する場合、ＭＬＭＥは、プローブ応答またはビーコンフレームが初めてＡＰから受信されるときに、プローブ応答またはビーコンフレームがＡＰの情報を含んだＢＳＳ記述セットを有するＭＬＭＥ−ＳＣＡＮ．ｃｏｎｆｉｒｍプリミティブを発行してもよい。プローブタイマが最大チャネル時間に到達するときに、ＮＡＶは０に設定されてもよく、および、次のチャネルがスキャンされてもよい。

【0136】

ＳＴＡが、アクションａまたはｂにおいて待機時間の間に、一致したスキャンニングパラメータ／ターゲットを有するいかなるプローブ要求をオーバーヒアせず、ならびに、ＳＴＡが、媒体へのアクセスを取得する場合、ＳＴＡは、ＭＬＭＥ−ＳＣＡＮ．ｒｅｑｕｅｓｔプリミティブからのＳＳＩＤおよびＢＳＳＩＤとともに、ブロードキャスト宛先アドレスにプローブ要求を送信してもよい。

【0137】

第１のシナリオに関する第３の方法では、アクティブスキャンを示すスキャンタイプを有するＭＬＭＥ−ＳＣＡＮ．ｒｅｑｕｅｓｔプリミティブを受信すると、ＳＴＡは、プローブ要求フレームを生成し、および、その後受信するプローブ応答フレームを処理することによって、アクティブスキャンニングを実行してもよい。

【0138】

スキャンされることになる各チャネルに対し、プローブ要求フレームの送信は、プローブ遅延時間が満了し、またはＰＨＹＲｘＳｔａｒｔ．ｉｎｄｉｃａｔｉｏｎプリミティブが受信されるまで、待機することが必要な場合があるので、ＳＴＡがチャネルをスキャンする準備ができた時から、対応するプローブ要求フレームが無線媒体で送信される時までの待機期間が存在することがある。さらに、ＳＴＡは、基本アクセスプロシージャを実行してもよい。

【0139】

プローブ要求フレームの不要な送信は回避されてもよく、および、アクティブスキャンニングプロシージャは、本明細書に記載されるように加速されてもよい。

【0140】

アクティブスキャンスキャンを示しているスキャンタイプを有するＭＬＭＥ−ＳＣＡＮ．ｒｅｑｕｅｓｔプリミティブを受信すると、ＳＴＡは、スキャンされることになる各チャネルに対してアクションを実行してもよい。ＳＴＡがスキャンされることになるチャネルにプローブ要求を送信するための待機期間の間に、ＳＴＡがスキャンされることになるチャネルの要求される情報を取得した場合、ＳＴＡは、その保留プローブ要求フレームの送信をキャンセルしてもよく、および、チャネルのそのスキャンニングの完了を考慮してもよい（例えば、受信されるチャネルの情報のすべてを含むＢＳＳ記述セットを有するＭＬＭＥ−ＳＣＡＮ．ｃｏｎｆｉｒｍプリミティブを生成することによって）。

【0141】

これは、ＳＴＡ１ ７０２、ＳＴＡ２ ７０６、およびＡＰ ７００を示す図７にまとめて示される。示されるように、ＳＴＡ１ ７０２が、プローブ要求７０４をＡＰ ７００に送信すると同時に、ＳＴＡ２ ７０６がプローブ要求を送信することを待機している。ＳＴＡ２ ７０６が同一のターゲットに対するＳＴＡ１ ７０２のプローブ要求への応答７０５を検出すると、ＳＴＡ２ ７０６は、その自身のプローブ要求７０８をキャンセルする。ＳＴＡ２ ７０６の、そのプローブ要求７０８をキャンセルするためのトリガイベントは、ＡＰの応答７０５に限定される必要がないことに留意されたい。ＳＴＡ２ ７０６は、本明細書に記載されるように、他のソースからチャネル情報を取得してもよい。

【0142】

キャンセル７０５は、ＳＭＥとＭＬＭＥとの間でプリミティブを通じて（または説明したように他の方法を使用して）行うことができる。待機期間の間にスキャンされることになるチャネルの要求される情報を受信すると、ＳＭＥは、現在のチャネルのスキャンニングを停止することを示すＭＬＭＥ−ＳＣＡＮ−ＳＴＯＰ．ｒｅｑｕｅｓｔ ７１２プリミティブを生成してもよい。これは、例として述べられる以下のうちの１つによって実現することができる。

【0143】

第１の例では、新たな値「Ｓｔｏｐ ｃｕｒｒｅｎｔ ｃｈａｎｎｅｌ」が、ＭＬＭＥ−Ｓｃａｎ−ＳＴＯＰ．ｒｅｑｕｅｓｔ ７１２プリミティブにおけるＳｃａｎＳｔｏｐＴｙｐｅのフィールドに追加される。ＭＬＭＥ−Ｓｃａｎ−ＳＴＯＰ．ｒｅｑｕｅｓｔ ７１２は、ＳｃａｎＳｔｏｐＴｙｐｅのフィールドが「Ｓｔｏｐ ｃｕｒｒｅｎｔ ｃｈａｎｎｅｌ」に設定されて生成される。

【0144】

第２の例では、新たな値「Ｓｔｏｐ」が、ＳｃａｎＳｔｏｐＴｙｐｅのフィールドに追加され、「ＣｈａｎｎｅｌＩｎｄｅｘ」の新たなフィールドが、ＭＬＭＥ−Ｓｃａｎ−ＳＴＯＰ．ｒｅｑｕｅｓｔプリミティブにおいて追加される。ＭＬＭＥ−Ｓｃａｎ−ＳＴＯＰ．ｒｅｑｕｅｓｔは、ＳｃａｎＳｔｏｐＴｙｐｅのフィールドが「Ｓｔｏｐ」に設定され、「ＣｈａｎｎｅｌＩｎｄｅｘ」のフィールドが現在のチャネルのインデックスに設定されて、生成される。

【0145】

第３の例では、「ＣｈａｎｎｅｌＬｉｓｔ」の新たなフィールドが、ＭＬＭＥ−Ｓｃａｎ−ＳＴＯＰ．ｒｅｑｕｅｓｔ７１２プリミティブにおいて追加される。ＭＬＭＥ−Ｓｃａｎ−ＳＴＯＰ．ｒｅｑｕｅｓｔ７１２は、ＳｃａｎＳｔｏｐＴｙｐｅのフィールドが「Ｓｅｔ＿Ｃｒｉｔｅｒｉａ」に設定され、「ＣｈａｎｎｅｌＩｎｄｅｘ」のフィールドが対応するＭＬＭＥ−Ｓｃａｎ．ｒｅｑｕｅｓｔにおけるチャネルリストに設定され、現在のチャネルのインデックスを除いて生成されてもよい。

【0146】

ＭＬＭＥ−Ｓｃａｎ−ＳＴＯＰ．ｒｅｑｕｅｓｔ７１２プリミティブを受信すると、ＭＬＭＥは、チャネル上の保留プローブ要求フレーム７０８の送信をキャンセルし、および、受信されるチャネルの情報のすべてを含むＢＳＳ記述セットを有するＭＬＭＥ−ＳＣＡＮ．ｃｏｎｆｉｒｍプリミティブを生成してもよい。

【0147】

ＳＴＡ２ ７０６が、ＳＴＡ２ ７０６がスキャンされることになるチャネルにプローブ要求を実際に送信するための待機期間の間に、他のソースを通じてスキャンされることになるいくつかのチャネルの要求される情報を待機期間の間に取得した場合、ＳＴＡ２ ７０６は、情報が受信されるチャネル上の、その保留プローブ要求フレーム７０８をキャンセルしてもよい。キャンセルは、ＳＭＥとＭＬＭＥとの間のプリミティブを通じて行われる。待機期間中にスキャンされることになるいくつかのチャネルの情報を受信すると、ＳＭＥは、チャネルのスキャンニングの停止を示すＭＬＭＥ−Ｓｃａｎ−ＳＴＯＰ．ｒｅｑｕｅｓｔ７１２プリミティブを生成してもよい。チャネルのスキャンニングの停止を示すＭＬＭＥ−Ｓｃａｎ−ＳＴＯＰ．ｒｅｑｕｅｓｔ７１２プリミティブのこの生成は、以下のいずれかによって実現されてもよい。これは、ＭＬＭＥ−Ｓｃａｎ−ＳＴＯＰ．ｒｅｑｕｅｓｔ７１４プリミティブにおいて、ＳｃａｎＳｔｏｐＴｙｐｅのフィールドへの新たな「Ｓｔｏｐ」値および「ＣｈａｎｎｅｌＬｉｓｔ」の新たなフィールドを追加することによって生成されてもよい。ＭＬＭＥ−Ｓｃａｎ−ＳＴＯＰ．ｒｅｑｕｅｓｔ７１２は、ＳｃａｎＳｔｏｐＴｙｐｅのフィールドが「Ｓｔｏｐ」に設定され、「ＣｈａｎｎｅｌＩｎｄｅｘ」のフィールドが、その情報が受信されるチャネルのインデックスに設定されて、生成されてもよい。

【0148】

さらに、「ＣｈａｎｎｅｌＬｉｓｔ」の新たなフィールドが、ＭＬＭＥ−Ｓｃａｎ−ＳＴＯＰ．ｒｅｑｕｅｓｔ７１４プリミティブにおいて追加されてもよい。ＭＬＭＥ−Ｓｃａｎ−ＳＴＯＰ．ｒｅｑｕｅｓｔ７１２は、ＳｃａｎＳｔｏｐＴｙｐｅのフィールドが「Ｓｅｔ＿Ｃｒｉｔｅｒｉａ」に設定され、「ＣｈａｎｎｅｌＩｎｄｅｘ」のフィールドが、対応するＭＬＭＥ−Ｓｃａｎ．ｒｅｑｕｅｓｔにおけるチャネルリストに設定され、その情報が受信されるチャネルを除いて、生成されてもよい。

【0149】

ＭＬＭＥ−Ｓｃａｎ−ＳＴＯＰ．ｒｅｑｕｅｓｔ７１２プリミティブを受信すると、ＭＬＭＥは、ＭＬＭＥ−Ｓｃａｎ−ＳＴＯＰ．ｒｅｑｕｅｓｔ７１２のパラメータ（例えば、その情報が受信されるチャネル）に従って、その保留プローブ要求７０８フレームの送信をキャンセルし、受信されるチャネルの情報のすべてを含むＢＳＳ記述セットを有するＭＬＭＥ−ＳＣＡＮ．ｃｏｎｆｉｒｍ７１４プリミティブを生成してもよい。

【0150】

ＳＴＡ２ ７０６（またはＳＴＡ２ ７０６内のＳＭＥ）が、関連付けることができるＡＰ７００を発見したと決定する場合、ＳＴＡ２ ７０６（またはＳＴＡ２ ７０６内のＳＭＥ）は、ＳｃａｎＳｔｏｐＴｙｐｅのフィールドを「Ｓｔｏｐ＿Ａｌｌ」に設定されたＭＬＭＥ−Ｓｃａｎ−ＳＴＯＰ．ｒｅｑｕｅｓｔ ７１２を生成して、アクティブスキャンニングプロセス全体を停止し、リンクセットアップの次のステップ（例えば、ネットワーク発見、認証、およびアソシエーション（association）など）に進んでもよい。その他の場合、ＳＴＡ７０６は、次のチャネルに行き、アクティブスキャンイングを実行してもよい。

【0151】

ＳＴＡ２ ７０６は、以下を介して、他のソースからチャネル情報を取得してもよい。

【0152】

ＳＴＡ２ ７０６は、チャネルを監視してもよく、ＳＴＡ２ ７０６に対するフレームを受信する。例えば、ビーコンフレーム（ショートビーコンまたはＳＴＡがＡＴに接続するために必要とされるビーコン情報のサブセットを含むＦＩＬＳビーコン／ＦＩＬＳ発見フレームを含む）、測定パイロットフレーム、ブロードキャストプローブ応答フレームなどの、チャネル情報を提供するブロードキャストフレームである。

【0153】

複数のネットワークインタフェースがサポートされる場合、ＳＴＡ２ ７０６は、別の他のネットワークインタフェースを通じてチャネル情報を受信する。この場合、あるＭＬＭＥ ＳＡＰプリミティブが、スキャンニングプロシージャを行うＭＡＣエンティティに通知を提供するように定義されてもよい。

【0154】

ＭＬＭＥ−ＳＣＡＮ．ｒｅｑｕｅｓｔ ７１２プリミティブを受信することと、対応するプローブ要求フレームの送信することとの間の待機時間は、プローブ要求／応答フレーム交換によって引き起こされるオーバーヘッドと、必要なチャネル情報を取得する際の待ち時間とのトレードオフを提供するために調整されてもよい。これは特に、アクティブスキャンニングを行っている多数のＳＴＡが存在するときに有益であり、ＡＰは、ブロードキャストされたプローブ応答フレームおよび／または他のブロードキャストされたフレームを使用して、受信されたプローブ要求フレームへのその応答としてチャネル情報を提供してもよい。

【0155】

待機時間の調整は、プローブ遅延パラメータに適切な値を設定することによって実行されてもよい。あるいは、ＳＴＡ２ ７０６は、チャネル状態に関するＳＴＡの評価または他の考慮に基づいて、チャネルアクセスプロシージャにおけるその待機時間またはバックオフウィンドウ／プロシージャを動的に調整してもよい。

【0156】

第１のシナリオに関する第４の方法では、スキャンニングを行っているＳＴＡが、ＭＬＭＥ−ＳＣＡＮ．ｒｅｑｕｅｓｔプリミティブによって提供されるチャネルリストにおけるすべてのチャネルをスキャンすることを要求されてもよい。さらにＳＴＡは、スキャンの間に集められたチャネルの情報を含むＢＳＳ記述セットを有するＭＬＭＥ−ＳＣＡＮ．ｃｏｎｆｉｒｍプリミティブを発行してもよい。ＳＴＡは、チャネルリストにおけるすべてのチャネルがスキャンされるまで、一度に１つのチャネルをスキャンしてもよい。

【0157】

ＡＰが、ＡＰ自身の動作チャネル以外のチャネルに関するある一定の知識を取得してもよい。ＡＰは、ＳＴＡに対するスキャンニングプロセスを加速するために、他のチャネルの知識をＳＴＡに提供して、チャネルリストにおけるチャネルの情報が集められるようにしてもよい。

【0158】

チャネル情報プロビジョニングフレーム（channel information provisioning frame）では、送信ＳＴＡは、それ自身の動作チャネルに加えて、他のチャネルのチャネル情報を含んでもよい。チャネル情報提供フレームの例は、ショートビーコンまたはＳＴＡがＡＰに接続するために重要なビーコン情報のサブセットを含むＦＩＬＳビーコン／発見フレームを含むビーコンフレーム、プローブ応答フレーム、および測定パイロットフレームなどを含む。他のチャネルのチャネル情報は、チャネル情報提供フレームに含まれる情報要素（ＩＥ）において符号化されてもよい。同様に、これはまた、パッシブスキャンニングにおいて利用されてもよい。

【0159】

チャネルをスキャンしている間、ＳＴＡが、他のチャネルの必要な情報を受信する場合、ＳＭＥは、ＳｃａｎＳｔｏｐＴｙｐｅのフィールドを「Ｓｅｔ＿Ｃｒｉｔｅｒｉａ」に設定し、「ＣｈａｎｎｅｌＬｉｓｔ」の新たなフィールドを、対応するＭＬＭＥ−Ｓｃａｎ．ｒｅｑｕｅｓｔのチャネルリストに設定し、その情報が受信されたチャネルのインデックスを除いて、ＭＬＭＥ−Ｓｃａｎ−ＳＴＯＰ．ｒｅｑｕｅｓｔを生成してもよい。例えば、チャネル、例えばＣｈ−Ａをスキャンしている間に、ＳＴＡが別のチャネル、例えばＣｈ−Ｂのすべての必要な情報を取得する場合、ＳＴＡは、チャネル、例えばＣｈ−Ｂに対する明示的なスキャンニングプロシージャをスキップしてもよく、リンクセットアップの後半で、Ｃｈ−Ｂ情報（Ｃｈ−Ａのスキャンニングの間に取得された）を使用する。同様に、これはまた、パッシブスキャンニングに利用されてもよい。

【0160】

Ｃｈ−Ａなどのチャネルをスキャンするとき、ＳＴＡが、すべての必要な情報ではないが、Ｃｈ−Ｂの一部の情報を取得する場合、ＳＴＡは、Ｃｈ−Ａのスキャンの間に取得されたＳＳＩＤ情報を使用することによって、Ｃｈ−Ｂ上のスキャンニングを行ってもよく、したがってワイルドカードＳＳＩＤを有するプローブ要求が回避されるようにしてもよい。

【0161】

アクティブスキャンニングを行っているＳＴＡはまた、そのプローブ要求フレームにおいて（対応するＭＬＭＥ−Ｓｃａｎ．ｒｅｑｕｅｓｔプリミティブに指定されるように）、ＳＴＡのチャネルリストを提供またはシグナリングして、プローブ応答を提供しているＳＴＡに、チャネルリストにおける他のチャネルならびに現在のスキャンニングプロシージャの下のチャネルの情報も含むことを要求するためのインジケータとしてサービスしてもよい。このようなチャネルリストは、プローブ要求フレームにおけるＩＥとして符号化されてもよい。

【0162】

第１のシナリオに関する第５の方法では、多数のＳＴＡが、同時にスペースに入ることがあり、全部または大部分が、新たな位置において（例えば、列車が駅に到着するとき）それらに利用可能なサービスにアクセスしようとすることがある。駅に到着する前の列車上のＳＴＡのすべては、列車上のＡＰを介して接続されており、および、列車上のＡＰは、その位置を認識しており、それが駅に到着したと仮定されてもよい。したがって、列車上のＡＰは、列車上の多くのＳＴＡが、列車のＡＰから駅におけるＡＰに移ってもよいこと、および、駅における多くのＳＴＡが、駅におけるＡＰから列車のＡＰに移ってもよいことを認識していてもよい。

【0163】

１つの手法では、ＳＴＡまたは複数のＳＴＡが、モバイルであり、その位置を認識しているＡＰと関連付けられてもよい。ＡＰがそのＳＴＡの一部または全部が新たなＡＰに移り、または、追加のサービスを探すことができる一に近づくとき、ＡＰはこの必要性を予想し、その関連付けられたＳＴＡおよびそれと関連付けることを求めることができるＳＴＡに、以下のサービスを提供してもよい。

【0164】

ＡＰは、その関連付けられたＳＴＡに、それらが追加のＡＰおよびサービスが利用可能である（すなわち、電車が駅に入っている）エリアに到着しているというブロードキャストメッセージを送信してもよい。このメッセージはまた、ＳＴＡに、ＡＰが未来のある定義された時間にプローブ要求を送信していてもよく、または、過去にそれを送信したことを通知してもよい。それはまた、追加のプローブ要求がＡＰおよびＳＴＡが現在使用しているチャネル以外のチャネル上で送信されてもよいことを示してもよい。

【0165】

メッセージはまた、ＡＰが、入るエリアで利用可能なサービスに関して有する情報を含んでもよい。加えて、ＡＰがプローブ要求を送信することができる通知は、関連付けられたＳＴＡによって使用されて、それら自身のプローブ要求を抑制してもよく、および、ＡＰのプロキシプローブ要求に依存して、新たな環境を評価してもよい。

【0166】

適切な時間（例えば、ブロードキャストメッセージにおいて示される時間）に、ＡＰは、そのＳＴＡに対するプロキシプローブ要求を送信してもよい。

【0167】

ＳＴＡは、ＡＰプロキシプローブ要求を受信し、エリアにおいて利用可能なＡＰおよびサービスからのプローブ応答を待機し、ＡＰプロキシプローブ要求がＳＴＡによって送信されたかのように進行してもよい。

【0168】

ＡＰはまた、ＡＰと通信し、または無線でまたはＤＳを介して、新たなエリアにおいてネットワークサービスクエリを実行してもよい。ＡＰは、それがそれらのエリアに到着していることを（例えば、列車がそれらの駅に入っていること）を示してもよい。この情報を受信すると、ＡＰは、到着するＡＰが現在それらのエリアにあることを、それらのＳＴＡに通知してもよい。ＡＰは、その後、上述したようにそれらの関連付けられたＳＴＡに、ブロードキャストメッセージも発行することを選択してもよい。

【0169】

別の手法では、ＡＰと関連付けられたＳＴＡまたは複数のＳＴＡは、ＡＰがＳＴＡに対してプロキシプローブ要求を送信することを要求してもよい。要求は、管理フレームによって開始されてもよく、または、それは、ＳＴＡからのデータ、管理、またはＡＣＫフレーム上でピギーバックされてもよい。ＳＴＡはまた、ＳＴＡが、プロキシプローブ要求が作成されることを求めるチャネルおよび時間を示してもよい。ＳＴＡが要求を行うとき、ＡＰは、本明細書に示される同様のプロシージャに従ってもよい。

【0170】

ＡＰは、それがプローブ要求を送信することを意図する、その関連付けられたＳＴＡにブロードキャストメッセージを送信してもよく、および、それがいつプローブ要求を送信することを求めているか、およびそれがどのチャネルを使用して要求を送信することができるかを示してもよい。関連付けられたＳＴＡは、それら自身のプローブ要求を抑制してもよく、および、ＡＰプロキシプローブ要求に依存してもよい。

【0171】

ＡＰがプロキシプローブ要求を送信すると、ＳＴＡは、その後ＡＰプロキシプローブ要求をヒアし、プローブ応答を待機し、それらが自身でプローブ要求を送信したかのようにその後進行することができる。

【0172】

別の手法では、ＡＰが、別のＡＰからＤＳを介してまたは無線上で、ＡＰがそのエリアに入っており、または、サービスを探しているＳＴＡを有することを示すメッセージを受信してもよい。メッセージを送信したＡＰはまた、メッセージを受信しているＡＰと関連付けられたＳＴＡに提供するための新たなサービスを有することを示してもよい。このメッセージを受信すると、受信しているＳＴＡは、そのＳＴＡに情報を通知してもよく、または、そのＳＴＡに、それがプロキシプローブ要求を送信することを通知してもよく、これによりそのＳＴＡは、エリアにおいてＡＰからのプローブ応答およびサービスを受信することが可能になる。メッセージを発信したＡＰはプローブ要求に応答してもよいと仮定されてもよいことに留意されたい。

【0173】

第１のシナリオに関する第６の方法では、アクティブにスキャンされることになるチャネル上で動作しているＡＰが存在しないが、隣接チャネルが、スキャンＳＴＡに最大チャネル時間の間にチャネルをスキャンさせてもよく、初期スキャンニング時間を超えてチャネルのスキャンニングを継続するかのスキャンＳＴＡの決定は、その時までにＰＨＹ−ＣＣＡ．ｉｎｄｉｃａｔｉｏｎ（ｂｕｓｙ）の代わりにＰＨＹ−ＲｘＳｔａｒｔ．ｉｎｄｉｃａｔｉｏｎプリミティブが受信されたかに基づいていてもよい。

【0174】

アクティブスキャンを示しているスキャンタイプを有するＭＬＭＥ−ＳＣＡＮ．ｒｅｑｕｅｓｔプリミティブを受信すると、ＳＴＡが、以下のプロシージャを使用してもよい。

【0175】

スキャンされることになる各チャネルに対し、ａ）プローブ遅延時間が満了するまで、または、ＰＨＹＲｘＳｔａｒｔ．ｉｎｄｉｃａｔｉｏｎプリミティブが受信されるまで待機する。

【0176】

ｂ）本明細書に記載されるように基本アクセスプロシージャを実行する。

【0177】

ｃ）ＭＬＭＥ−ＳＣＡＮ．ｒｅｑｕｅｓｔプリミティブからのＳＳＩＤおよびＢＳＳＩＤとともに、ブロードキャスト宛先アドレスにプローブ要求を送信する。ＭＬＭＥ−ＳＣＡＮ．ｒｅｑｕｅｓｔプリミティブにＳＳＩＤリストがあるとき、それぞれがＳＳＩＤリストにおいて示されるＳＳＩＤおよびＭＬＭＥ−ＳＣＡＮ．ｒｅｑｕｅｓｔプリミティブからのＢＳＳＩＤを有する、１または複数のプローブ要求フレームを送信する。

【0178】

ｄ）プローブタイマを０に設定し、プローブタイマを起動する。

【0179】

ｅ）プローブタイマが最小チャネル時間＋ＰＨＹ ＲＸ待ち時間に到達する前に、ＰＨＹ−ＲｘＳｔａｒｔ．ｉｎｄｉｃａｔｉｏｎプリミティブが検出され、または、プローブタイマが最小チャネル時間＋ＰＨＹ ＲＸ待ち時間に到達するまでに、少なくとも１つのＰＨＹ−ＲｘＳｔａｒｔ．ｉｎｄｉｃａｔｉｏｎプリミティブが検出されたが、それらのすべてがプローブ要求フレームによってトリガされる場合、ＮＡＶを０に設定し、次のチャネルをスキャンし、他に、ＭＬＭＥは、プローブ応答またはビーコンフレームがＡＰから初めて受信されるとき、ＡＰの情報を含むＢＳＳ記述セットを有するＭＬＭＥ−ＳＣＡＮ．ｃｏｎｆｉｒｍプリミティブを発行する。プローブタイマが最小チャネル時間＋ＰＨＹ ＲＸ待ち時間＋ＭＡＣ処理待ち時間に到達する時までに、スキャンＳＴＡは、プローブタイマが最小チャネル時間＋ＰＨＹ ＲＸ待ち時間に到達する前に検出されるＰＨＹ−ＲｘＳｔａｒｔ．ｉｎｄｉｃａｔｉｏｎプリミティブのすべてが、プローブ要求フレームによってトリガされるかを判定してもよいことに留意されたい。ＳＩＦＳ時間＝ＰＨＹ ＲＸ待ち時間＋ＭＡＣ処理待ち時間＋ＰＨＹ ＴＸ待ち時間であるので、ＰＨＹ ＲＸ待ち時間＋ＭＡＣ処理待ち時間の値は、ＳＩＦＳ時間よりも小さくてもよい。プローブタイマが最小チャネル時間に到達するときに、ＮＡＶを０に設定し、次のチャネルをスキャンする。

【0180】

第２のシナリオに関して、効率的なアクティブスキャンニングが説明される。未解決の（outstanding）プローブ要求は、まだ応答されていない一意のＳＴＡからＡＰが受信するプローブ要求である一方で、プローブ要求において指定されるスキャニングに対する、ＳＴＡの関連する最大チャネル時間はまだ経過していない。プローブ応答フレームへの応答の時期尚早（premature）のキャンセルを減らすために、各未解決のプローブ要求に対し、ＳＴＡが、プローブ要求を送信した対応するＳＴＡから有効なプローブ終了フレームを受信する場合、ＳＴＡはプローブ要求フレームへの応答をキャンセルしてもよい。

【0181】

例えば、ＳＴＡがプローブ終了フレームを受信し、および、ＳＴＡがプローブ応答の送信を開始しておらず、またはＳＴＡがプローブ終了フレームの送信側へプローブ応答フレームを現在送信している場合、以下の基準が満たされる場合、プローブ要求フレームへの応答が送信されてもよい。

【0182】

ａ）プローブ終了フレームのフィルタリストにおけるＢＳＳタイプ要素のＴｅｒｍｉｎａｔｅ Ａｌｌ Ｒｅｑｕｅｓｔｓフィールドは、０に設定される。

【0183】

ｂ）ＳＴＡは、ＡＰ ＳＴＡであり、プローブ終了フレームのフィルタリストにおけるＢＳＳタイプ要素のインフラストラクチャフィールドは０に設定され、または、ＳＴＡのＳＳＩＤ、ＢＳＳＩＤ、もしくはＨＥＳＳＩＤは、プローブ終了フレームのフィルタリストに含まれない。または、（１）ＳＴＡのＢＳＳは、ＩＢＳＳであり、プローブ終了フレームのフィルタリストにおけるＢＳＳタイプ要素のＩＢＳＳフィールドは０に設定され、ＳＴＡのＳＳＩＤ、またはＢＳＳＩＤは、プローブ終了フレームのフィルタリストに含まれない。または、

【0184】

（２）ＳＴＡは、メッシュＳＴＡであり、プローブ終了フレームのフィルタリストにおけるＢＳＳタイプ要素のＭＢＳＳフィールドは０に設定され、またはメッシュＳＴＡのメッシュＩＤもしくはＭＡＣアドレスは、プローブ終了フレームのフィルタリストに含まれない。

【0185】

ｃ）少なくとも１つの未解決のプローブ要求に対し、対応するプローブ終了フレームが受信されておらず、または、対応するプローブ終了フレームが受信されたが、上記の条件ａ）およびｂ）が満たされない。

【0186】

上記の基準が満たされない場合、プローブ終了フレームの受信側は、プローブ要求フレームへの応答を一度送信し、または再送信してもよい。しかしながら、応答は、２度以上送信されず、または再送信されないことが要求されることがある。

【0187】

第３のシナリオについて、効率的なアクティブスキャンニングおよびＦＩＬＳプロセスが説明される。さらに、ＦＩＬＳに対するアクセスカテゴリが説明される。ＦＩＬＳに使用される管理フレームの送信を優先付けるために、管理フレームに使用することができるＡＣ＿ＦＩＬＳと称されるアクセスカテゴリが、ＦＩＬＳプロセスで利用される。ＡＣ＿ＦＩＬＳを使用して送信することができるＦＩＬＳフレームは、以下を含む。

【0188】

プローブ要求フレーム、またはプローブ要求フレームがＢＳＳとまだ関連付けられていないＳＴＡによって単に送信されることが要求されてもよい。

【0189】

プローブ応答フレーム。

【0190】

認証フレーム。

【0191】

アソシエーション（association）要求フレーム。

【0192】

アソシエーション応答フレーム。

【0193】

汎用広告サービス（ＧＡＳ：Generic Advertisement Service）クエリ／応答に対するアクションフレーム、または、ＧＡＳクエリ／応答に対するアクションフレームが、ＢＳＳとまだ関連付けられていないＳＴＡによって単に送信されることが要求されてもよい。

【0194】

セキュリティセットアップに使用される管理フレーム、または管理フレームが、ＢＳＳとまだ関連付けられていないＳＴＡによって送信されるセキュリティセットアップに単に使用されることが要求されてもよい。

【0195】

アクセスカテゴリＡＣ＿ＦＩＬＳが、ＡＰによって判定されてもよい。ＦＩＬＳプロセスを速める（speed）ために、ＡＣ＿ＦＩＬＳは、アクセスカテゴリボイス（ＡＣ＿ＶＯ：Access Category Voice）と比較して、より小さいフレーム送信間隔（ＡＩＦＳ：Arbitration Inter Frame Space）、より小さい最小コンテンションウインドウ（ＣＷｍｉｎ：Minimum Contention Window）、および最大コンテンションウィンドウ（ＣＷｍａｘ：Maximum Contention Window）サイズを有する。さらに、ＡＣ＿ＦＩＬＳに対して定義されてもよい送信権占有（ＴＸＯＰ：transmission opportunity）リミット（limit）は、ＡＣ＿ＶＯに許可されるＴＸＯＰリミットよりも短く、または等しくてもよい。

【0196】

さらに、ＦＩＬＳフレームは、ＩＥＥＥ ８０２．１１通信においてはＭＡＣレイヤにローカライズされるので、新たなＡＣが割り当てられる必要がなくてもよい。ＦＩＬＳフレームは、ＳＴＡの内部と、ＳＴＡの外部の無線媒体上の両方で、上述のものと同様の、ローカライズされたＦＩＬＳ改良分散チャネルアクセス（ＥＤＣＡ：enhanced distributed channel access）パラメータを使用して送信されてもよい。ＡＣ＿ＦＩＬＳアクセスカテゴリ定義は、本明細書において例示的なものであり、異なる用語を使用して定義されてもよいことに留意されたい。

【0197】

説明は、ＡＣ＿ＦＩＬＳ ＥＤＣＡパラメータセット情報要素およびアクセスオプション情報要素を述べる。図８は、ＦＩＬＳ ＥＤＣＡパラメータセット情報要素の例を示す。本明細書では、ＡＣ＿ＦＩＬＳ ＥＤＣＡパラメータセット情報要素およびアクセスオプション情報要素について説明される。ＡＣ＿ＦＩＬＳに対するＥＤＣＡパラメータセット、またはＦＩＬＳフレームに対するローカルＦＩＬＳ ＥＤＣＡパラメータが説明される。ＦＩＬＳ ＥＤＣＡパラメータセット情報要素は、以下のフィールドを含んでもよい。

【0198】

要素アイデンティティ（ＩＤ）８０２。要素ＩＤは、現在の要素ＩＤがＦＩＬＳ ＥＤＣＡパラメータセット情報要素であることを識別するのにサービスする。

【0199】

長さ（情報ＩＤのバイトで）８０４。

【0200】

ＡＣ＿ＦＩＬＳ ＡＣＩに対するＡＣインデックス（ＡＣＩ）８０６。利用可能なＡＣを収容するために、ＡＣＩは、新たなＡＣを定義する３ビット以上であってもよい。例えば、ＡＣ＿ＦＩＬＳに対するＡＣインデックスは、４ビットであってもよい。ローカライズされたＦＩＬＳ ＥＤＣＡパラメータのみがＦＩＬＳフレームに使用される場合、ＡＣＩフィールドは任意（optional）であることが要求されてもよい。

【0201】

フレーム送信間隔（ＡＩＦＳ）番号（ＡＩＦＳＮ）８０８。ＡＣ＿ＦＩＬＳと関連付けられたＡＩＦＳＮに対し、デフォルトのＡＣ＿ＦＩＬＳは１であってもよい。

【0202】

指数（exponent）ＣＷｍｉｎ（ＥＣＷｍｉｎ）および指数ＣＷｍａｘ（ＥＣＷｍａｘ）８１０。ＥＣＷｍｉｎおよびＥＣＷｍａｘは、それぞれ、現在のＡＰとのＦＩＬＳを望んでいるＳＴＡが適合すべきであるＣＷｍｉｎおよびＣＷｍａｘを定義し、ＣＷｍｉｎ＝２ＥＣＷｍｉｎ−１およびＣＷｍａｘ＝２ＥＣＷｍａｘ−１となるように定義される。ＣＷｍｉｎおよびＣＷｍａｘは、ＦＩＬＳフレームの過度の衝突および再送信は、初期リンクセットアップ時間における過度の遅延に繋がることがあるので、ＦＩＬＳフレームの過度の衝突および再送信を回避することによって、到来する期間にＦＩＬＳ動作を実行するＳＴＡの予想される数を収容するために十分な大きさであってもよい。

【0203】

ＴＸＯＰリミット８１２。ＴＸＯＰリミットは、ＦＩＬＳ ＴＸＯＰと関連付けられたＴＸＯＰの制限を含む。

【0204】

ＡＣ＿ＦＩＬＳまたはローカルＦＩＬＳ ＥＤＣＡパラメータセット情報要素は、選択されたビーコン、ショートビーコン、ＦＩＬＳ発見フレーム、プローブ応答フレーム、または任意の他のタイプの制御もしくは管理フレームに含まれてもよい。ＳＴＡは、ＡＣ＿ＦＩＬＳまたはローカルＦＩＬＳ ＥＤＣＡパラメータセット情報要素を、プローブ要求フレーム、または任意の他のタイプの制御もしくは管理フレームに含めてもよい。ＡＩＦＳＮ、ＥＣＷｍｉｎ、ＥＣＷｍａｘフィールドは、ＳＴＡからＡＰへのこれらのフレームにおいてゼロに設定されて、ＳＴＡからＡＰに、ＳＴＡは促進（expedited）ＦＩＬＳが可能であることを示してもよい。

【0205】

図９は、アクセスオプション情報要素を示す。

【0206】

ＡＰは、そのビーコン、ショートビーコン、プローブ応答フレーム、または任意の他のタイプの制御もしくは管理フレームに、ＦＩＬＳフレームに関連するＵＬチャネルアクセスに対する他の情報を含めてもよい。例えば、ＡＰは、非ＦＩＬＳフレームが送信されないＦＩＬＳ動作のみに使用することができる１もしくは複数のビーコン間隔またはビーコンサブ間隔を示してもよい。加えて、ＡＰは、ＳＴＡのサブセットが１もしくは複数のビーコン間隔またはビーコンサブ間隔でＦＩＬＳ動作を行うことができることを示してもよい。別の例では、ＡＰは、より高い優先度で、ＦＩＬＳ動作に使用することができ、および、非ＦＩＬＳフレームがＦＩＬＳフレームよりも低い優先度で送信される、１もしくは複数のビーコン間隔またはビーコンサブ間隔を示してもよい。アクセスオプション情報要素は、すべてのタイプのＳＴＡに、およびすべてのタイプのフレーム送信に、一般化されてもよい。

【0207】

アクセスオプション情報要素は、以下フィールドを含んでもよい。

【0208】

要素ＩＤ ９０２：アクセスオプションＩＥとしてＩＥを識別するＩＤ。

【0209】

長さ９０４：ＩＥの残りのオクテットでの長さ。

【0210】

Ｓｐｅｃフィールドの数９０６：ＩＥの残りに含まれるＳｐｅｃフィールドの数。

【0211】

Ｓｐｅｃ１〜ＳｐｅｃＮフィールド９０８：各フィールドが、ＳＴＡアクセスに対する仕様のセットを含む。各フィールドは、時間間隔のセット、ＳＴＡのセット、トラフィックのセット、またはその任意の組合せに対する仕様を含んでもよい。

【0212】

図１０は、アクセスオプションＩＥのスペックｉフィールド（Ｓｐｅｃ ｉ Ｆｉｅｌｄ）を示す。図１０では、１＜ｉ＜Ｎである。Ｓｐｅｃフィールドは、スケジューリング情報の以下のサブフィールドを含んでもよい。

【0213】

開始ビーコン間隔１００２：アクセスポリシーが開始する開始ビーコン間隔。ビーコンは、常にＴＢＴＴにおいて送信されないので、開始ビーコン間隔は、ターゲットビーコン間隔を始めるビーコンのＴＢＴＴを指してもよい。あるいは、このサブフィールドは、ＴＳＦタイマの特定の値を含んでもよい。

【0214】

オフセット１００４：ビーコン、またはＴＢＴＴから、またはＴＳＦタイマの時間の参照ポイントまで、アクセスポリシーがマイクロ秒または他の任意の時間単位で開始する期間の開始のオフセット。

【0215】

継続時間１００６：アクセスポリシーが有効である期間の継続時間を指定する。

【0216】

繰り返し頻度１００８：アクセスオプションＩＥにおいて指定されたアクセスポリシーがどの程度繰り返されるかを表す。サブフィールドは、ビーコン間隔の数、またはマイクロ秒もしくは他の時間単位で定義されてもよい。

【0217】

スケジュール情報（Ｓｃｈｅｄｕｌｅ Ｉｎｆｏ）サブフィールドが要求されてもよいが、他の実施形態では、スケジュール情報サブフィールドは要求されなくてもよい。例えば、アクセスオプションＩＥがビーコンもしくはショートビーコン、または他のタイプの管理もしくは制御フレームに含まれて、指定されたアクセスポリシーが、ビーコン間隔もしくはビーコンサブ間隔、または送信されたフレームに直接続く他の継続時間の間有効であることをアナウンスするとき。

【0218】

Ｓｐｅｃフィールド１００９はまた、以下を含んでもよい。

【0219】

許可されたＳＴＡタイプ１０１０：指定された間隔、優先度、トラフィック、および／またはＥＤＣＡパラメータに対する媒体アクセスを行うことを許可されたＳＴＡのタイプ。ＳＴＡタイプの例は、ＦＩＬＳ ＳＴＡ、センサおよびメータＳＴＡ、セルラオフローディングＳＴＡ、バッテリ電力ＳＴＡ、および電気主電源（electrical main-powered）ＳＴＡなどであってもよい。許可されたＳＴＡタイプフィールドは、許可された様々なタイプのＳＴＡを示すビットマップであってもよい。

【0220】

ＩＤ １０１２：このサブフィールドは、指定された間隔、優先度、トラフィック、および／または指定されたＥＤＣＡパラメータを使用して、媒体にアクセスすることを許可されたＳＴＡまたはＳＴＡの特定のグループのＩＤを指定する。

【0221】

許可されるトラフィックタイプ１０１４：指定されたＥＤＣＡパラメータを使用して、指定された間隔、ＳＴＡタイプに対する許可されたアクセス媒体であるトラフィックタイプを指定する。例えば、許可されたトラフィックタイプの一部は、ＦＩＬＳフレーム、ＡＣ＿ＶＯフレーム、ＡＣ＿ＶＩフレーム、センサおよびメータセンサフレーム、火事または侵入者の検知を報告する非常警報（red-alert）フレームなどであってもよい。許可されたトラフィックタイプフィールドは、許可されたトラフィックの様々なタイプのＡＣを示すビットマップであってもよい。

【0222】

ＥＤＣＡパラメータ１０１６：指定された間隔、ＳＴＡタイプ、優先度、および／またはトラフィックに使用することができるＥＤＣＡパラメータの異なるセットを示す。ＥＤＣＡパラメータセットは、Ｓｐｅｃ ｉフィールドにおいて明示的に指定されてもよい。あるいは、ＦＩＬＳ ＥＤＣＡパラメータセット情報要素に指定されたＥＤＣＡパラメータセットのインデックスが使用されてもよい。

【0223】

ＦＩＬＳ ＥＤＣＡパラメータセットＩＥ、アクセスオプションＩＥ、またはフィールドもしくはサブフィールドの任意のサブセットは、任意の既存のもしくは新たなＩＥのサブフィールドまたはサブフィールドのサブセットであってもよく、または任意の制御、管理、もしくはＭＡＣ／ＰＬＣＰヘッダの一部としてのサブフィールドまたはサブフィールドのサブセットであってもよいことに留意されたい。

【0224】

説明は、ＳＴＡ／ＡＰ挙動を述べる。促進ＦＩＬＳが可能なＡＰは、ＦＩＬＳ要件、現在のネットワーク負荷などに応じてＡＣ＿ＦＩＬＳに対するＡＩＦＳ、ＣＷｍｉｎ、ＣＷｍａｘ、およびＴＸＯＰ ＬｉｍｉｔなどのＥＤＣＡパラメータを判定してもよく、またはＡＰは、ＦＩＬＳフレームが別個のＡＣに属することを要求することなく、ＦＩＬＳフレームに対するＥＤＣＡパラメータを判定してもよい。ＡＰが、時々、ＡＣ＿ＦＩＬＳまたはローカルＦＩＬＳ ＥＤＣＡパラメータを変更してもよく、ＡＣ＿ＦＩＬＳもしくはローカルＦＩＬＳ ＥＤＣＡパラメータセット、および／またはアクセスオプションＩＥを、そのビーコンもしくはショートビーコン、ＦＩＬＳ発見フレームもしくはプローブ応答、または他のタイプの管理もしくは制御フレームに含めてもよい。

【0225】

加えて、促進ＦＩＬＳが可能なＳＴＡの前に、ＳＴＡは、ビーコン、またはＡＣ＿ＦＩＬＳまたはローカルＦＩＬＳ ＥＤＣＡパラメータセット情報要素および／またはアクセスオプションＩＥを含む他のタイプの管理もしくは制御フレームを受信する。ＳＴＡは、ＡＣ＿ＶＯに対してデフォルトＥＤＣＡパラメータを使用してプローブ要求を送信し、ＡＣ＿ＦＩＬＳに指定されたデフォルトＥＤＣＡパラメータもしくはＦＩＬＳパラメータを使用してプローブ要求を送信し、またはプローブ要求に含まれるＡＣ＿ＦＩＬＳもしくはローカルＥＤＣＡパラメータセット情報要素におけるＡＩＦＳＮ、ＥＣＷｍｉｎ、ＥＣＷｍａｘのフィールドをゼロに設定してもよい。

【0226】

促進ＦＩＬＳが可能なＳＴＡが、ビーコンもしくはショートビーコン、または他の管理、ＦＩＬＳ発見フレーム、もしくはＡＣ＿ＦＩＬＳもしくはローカルＦＩＬＳ ＥＤＣＡパラメータセット情報要素、および／またはアクセスオプションＩＥを含む制御フレームを受信した後、ＳＴＡは、任意の送信または媒体アクセスを行おうと試みるとき、アクセスオプションＩＥによって設定された、アクセス間隔、パラメータなどのアクセスポリシーに従ってもよい。加えて、ＳＴＡは、ビーコンにおけるＡＣ＿ＦＩＬＳまたはローカルＦＩＬＳフレームに指定されたＥＤＣＡパラメータを使用してプローブ要求を送信してもよい。さらにＳＴＡは、ＡＣ＿ＦＩＬＳまたはローカルＦＩＬＳ ＥＤＣＡパラメータセット情報要素を、ＡＰから受信した値に設定して、それがまた促進ＦＩＬＳが可能なことを示してもよい。

【0227】

促進ＦＩＬＳが可能なＡＰが、ＡＩＦＳＮ、ＥＣＷｍｉｎ、およびＥＣＷｍａｘフィールドをゼロに設定された、ＡＣ＿ＦＩＬＳまたはローカルＦＩＬＳ ＥＤＣＡパラメータセット情報要素を含むプローブ要求フレームをＳＴＡから受信すると、ＡＰは、全てのＡＣ＿ＦＩＬＳまたはローカルＦＩＬＳ ＥＤＣＡパラメータをすべて含むＡＣ＿ＦＩＬＳまたはローカルＦＩＬＳ ＥＤＣＡパラメータセット情報要素を有するプローブ応答で応答してもよい。

【0228】

ＳＴＡおよびＡＰは、ＦＩＬＳプロセスの残りに対して、ＡＣ＿ＦＩＬＳもしくはローカルＦＩＬＳ ＥＤＣＡパラメータ、およびアクセスオプションＩＥによって設定されたアクセスポリシーを使用してもよい。近接して複数のＡＰが存在する場合、ＳＴＡは、ＡＣ＿ＦＩＬＳもしくはローカルＦＩＬＳ ＥＤＡパラメータ、およびＳＴＡが関連付けすることを要求しているアクセスポリシーを適応してもよい。ＡＰは、ＦＩＬＳ関連のパケット交換に対して、そのビーコンにおいて広告されるものとは異なる、ＡＣ＿ＦＩＬＳもしくはローカルＦＩＬＳ ＥＤＣＡパラメータ、またはアクセスポリシーのセットを使用してもよい。

【0229】

ＡＰと関連付けられ、またはＡＰとすでに関連付けられているＳＴＡは、すべての後続の媒体アクセスにおいて、そのＡＰによって送信された最近のアクセスオプションＩＥによって設定された最新のアクセスポリシーに従ってもよい。

【0230】

説明は、アクセスオプション情報要素の代替となる格調ＩＬＳ要素を述べる。上述のＩＬＳ要素設計は、ＩＬＳ間隔のスケジュールおよび関連付けられたパラメータでさらに拡張および改良されてもよい。このような改良ＩＬＳ要素の例が、図１０Ａに示される。改良ＩＬＳ要素は、ビーコン、ショートビーコン、プローブ応答、ＦＩＬＳ発見フレーム、または任意の他のタイプの制御、管理、もしくは他のタイプのフレームなどのフレームに含まれてもよい。

【0231】

改良ＩＬＳ要素フィールドは、以下を含んでもよい。

【0232】

要素ＩＤ １０５０：これが改良ＩＬＳ要素であることを示す要素ＩＤ

【0233】

長さ１０５２：改良ＩＬＳ要素の長さ

【0234】

フィールドの数１０５４：改良ＩＬＳ要素に含まれるフィールドの数

【0235】

フィールド１〜フィールドＮ １０５６：各フィールドが、ＩＬＳに対する仕様、または特定の期間もしくはビーコンサブ間隔の間の通常のトラフィックに対する仕様を含んでもよく、以下のサブフィールドを有してもよい。

【0236】

ＩＬＳＣインジケーション１０５８：ＩＬＳＣインジケーションサブフィールドは、スケジュールサブフィールドに示される期間またはビーコンサブ間隔にＡＰとのアソシエーションを行うことを許可されたＳＴＡのＩＳＬカテゴリを示してもよい。ＩＬＳＣインジケーション１０５８は、ビットマップとして実装されてもよい。

【0237】

ＡＣインジケーションサブフィールド１０６２：ＡＣインジケーションサブフィールド１０６２は、ＳＴＡが、スケジュールサブフィールドに示される期間またはビーコンサブ間隔において送信することができるトラフィックのアクセスカテゴリを示してもよい。ＡＣインジケーション１０６２は、ビットマップとして実装されてもよい。

【0238】

スケジュール１０６４：スケジュールサブフィールド１０６４は、期間またはビーコンサブ間隔の継続時間を示してもよい。例えば、継続時間Ｔ１がフィールド１において指定され、継続時間Ｔ２がフィールド２において指定され、期間１がＴ０（開始ポイントＴ０は、ターゲットビーコン時間、または拡張ＩＬＳ要素を含む現在のパケットの終わりを指してもよい。）において開始すると仮定する場合、期間１は、Ｔ０からＴ０＋Ｔ１まで続いてもよく、期間２は、Ｔ０＋Ｔ１からＴ０＋Ｔ１＋Ｔ２までとなってもよい。同様に、期間Ｎは、Ｔ０＋……＋ＴＮ−１からＴ０＋……＋ＴＮ−１＋ＴＮまでとなってもよい。

【0239】

パラメータ１０６６：ＦＩＬＳパケットに対するパラメータおよび非ＦＩＬＳトラフィックパケットに対するパラメータ。これらのパラメータは、以下を含んでもよい。

【0240】

ＥＤＣＡパラメータ：期間およびビーコンサブ間隔において許可されるＩＬＳＣのそれぞれに対するＥＤＣＡパラメータ、ならびに、期間およびビーコンサブ間隔において送信されることになることを許可されるＡＣのそれぞれに対するＥＤＣＡパラメータ。

【0241】

ＡＰ／ＢＳＳ：ＡＰが、改良ＩＬＳ要素において近隣報告の一部として、近隣ＡＰに対する改良ＩＬＳ情報を含んでもよい。

【0242】

説明は、改良ＩＬＳ要素を使用する差異化ＦＩＬＳプロシージャを述べる。ＡＰは、そのビーコン、ショートビーコン、ＦＩＬＳ発見フレーム、およびプローブ応答に、改良ＩＬＳ要素を含めて、１または複数の期間およびビーコンサブ間隔の間、すべてのＳＴＡに以下を通知してもよい。

【0243】

ＡＰとのアソシエーションを行うことを許可されたＳＴＡの１もしくは複数のＩＬＳＣ、ならびに／または、ＦＩＬＳ ＳＴＡがその期間もしくはビーコンサブ間隔の間、ＦＩＬＳ関連のパケット交換に使用すべきＥＤＣＡパラメータ、ならびに／または、関連付けられたＳＴＡがその期間またはビーコンサブ間隔の間に送信することができる１もしくは複数のＡＣ、ならびに／または、関連付けられたＳＴＡが、期間もしくはビーコンサブ間隔の間にＡＣのそれぞれに対して使用すべきＥＤＣＡパラメータ。

【0244】

改良ＩＬＳ要素を使用して、ＡＰは、異なる期間またはビーコンサブ間隔に対して、ＦＩＬＳトラフィックの様々なＩＬＳＣと、現在関連付けられているＳＴＡからのトラフィックの様々なＡＣの組合せの様々なバリエーションを割り当ててもよい。ある期間またはビーコンサブ間隔において、ＡＰは、あるＩＬＳＣ ＳＴＡまたはＡＣ＿ＢＫもしくはＡＣ＿ＢＥなどのトラフィックのＡＣを許可せず、ＦＩＬＳ ＳＴＡまたはＦＩＬＳ ＳＴＡのサブセットに対してより迅速なアソシエーションプロセスを可能にしてもよい。

【0245】

ＳＴＡのＩＬＳＣは、ＳＴＡが送信／受信している進行中のトラフィックの最上位のＡＣによって判定されてもよい。別の実装では、ＳＴＡのＩＬＳＣは、プレミアムまたはレギュラー顧客などの、ＳＴＡのＳＬＡ（サービスレベルアグリーメント）のクラスによって判定されてもよい。ＳＴＡのＩＬＳＣは、ランダムに判定され、または、それらのＭＡＣアドレス、例えばＳＴＡのＭＡＣアドレスの４ＬＳＢまたはＭＳＢに基づいて判定されてもよい。

【0246】

ＯＢＳＳにおけるＡＰは、異なるＩＬＳＣおよびトラフィックのＡＣのそれらのスケジューリングを調整してもよい。ＡＰはまた、改良ＩＬＳ要素を使用して、異なるＩＬＳＣおよびトラフィックのＡＣに対して隣接ＡＰのスケジュールを示してもよい。

【0247】

ＦＩＬＳプロセスを行うことを望むＦＩＬＳ ＳＴＡは、プローブ応答、ＦＩＬＳ発見フレーム、ビーコン、ショートビーコン、または改良ＩＬＳ要素を含む他のタイプのフレームをヒアするとき、他の構成の中から、ＦＩＬＳ ＳＴＡが属するＩＬＳＣに対してもっとも早いスケジュールを有するＡＰと関連付けることを選択してもよい。ＦＩＬＳ ＳＴＡは、次いで、指定された期間中に指定されたＥＤＣＡパラメータを適合させ、ＦＩＬＳプロセスを行ってもよい。

【0248】

説明は、自律ＦＩＬＳパラメータ調整を述べる。ＦＩＬＳ ＳＴＡは、いかなるメッセージまたはインジケーションを受信することなく、そのＥＤＣＡパラメータを自律的に調整してもよい。ＳＴＡが下位ＩＬＳＣを有するとき、例えば、それが非リアルタイムトラフィックのみを有する場合、それが関連付けられたＳＴＡから、または初期リンクセットアップを行っている他のＳＴＡから、高トラフィック負荷を経験しているＡＰ／ＢＳＳでＦＩＬＳプロセスを行う必要があるとき、それは、バースト的なリンクアクセス需要を徐々に成形することによってリンクアクセス競合の低減を支援するために、下位ＩＬＳＣまたは下位ＡＣのＥＤＣＡパラメータを自律的に適合させてもよい。

【0249】

ＦＩＬＳ ＳＴＡが、以下の、予め定義されたあるトリガに基づいて、自律ＦＩＬＳパラメータ調整を起動してもよい。

【0250】

予め習得された知識での位置／時間／コンテキストベースのトリガ、例えば、ＦＩＬＳ ＳＴＡが、ＡＰ／ＢＳＳは高いトラフィック負荷を有するという予め習得された知識を有する場合、ＦＩＬＳ ＳＴＡは混雑した列車の駅にラッシュ時に到着する、および、監視／測定ベースのトリガ、例えば、ＦＩＬＳ ＳＴＡが検知した無線媒体が高負荷であり、または非常に競合的（contentious）である。

【0251】

第４のシナリオに関して、差異化プローブ要求フレーム形式が、図１１および図１２に示される。いくつかの例では、ＳＴＡの保留プローブ要求のスキャンニングパラメータの一部または大部分は、以前に受信されたプローブ要求のものと同一であるが、一部のパラメータは異なる。簡易プローブ要求フレーム１１００、１２００（図１１および図１２に示す）のより頻繁な利用を可能にしてオーバーヘッドを低減するために、差異化記述フィールドまたはＩＥ１１００、１１２０が、簡易プローブ要求フレーム１１００、１２００において使用されて、以前にオーバーヒア／受信されたプローブ要求のパラメータと、ＳＴＡがプローブ要求において送信することを試みるパラメータとの間の差分を示してもよい。

【0252】

差分記述フィールドは、以前のオーバーヒアされた／受信されたプローブ要求と、簡易プローブ要求フレームで送信されるプローブ要求との差分を示すために利用される。フレーム１１００、１２００は、別のプローブ要求への参照を含んでもよい。フレーム１１００では、参照は、それ独自のフィールド１１１２にあり、フレーム１２００では参照は、ＭＡＣヘッダ１２１４にある。フレーム１１００とフレーム１２００の両方が、ＰＬＣＰヘッダ１１１６、１２１６、およびＦＣＳフィールド１１１８、１２１８を含んでいることに留意する。

【0253】

要求アプローチに対する第１の差分記述フィールドでは、図１３に示される簡易プローブ要求フレーム１３００における差分記述フィールドは、それぞれプローブ要求において予め定義された要素の差分を記述する固定数のサブフィールド１３１０、１３２０、１３３０またはＩＥを含む。各サブフィールド１３１０、１３２０、１３３０またはＩＥは、各フィールドまたはＩＥの順序および意味が予め定義されているので、要素ＩＤを含まなくてもよい。

【0254】

ＳＴＥＴ 各要素の差分は、要素の性質により適切に符号化されてもよい。例えば、ＳＳＩＤリストのパラメータの差分は、プラス／マイナス符号の１ビットのインジケータおよびＳＳＩＤリストのサブセットとして符号化されてもよい。以前に受信されたプローブ要求フレームがＳＳＩＤリスト要素＝｛ＳＳＩＤ１，ＳＳＩＤ２，……，ＳＳＩＤ１０｝を有し、保留プローブ要求がＳＳＩＤリスト要素＝｛ＳＳＩＤ１，ＳＳＩＤ２，……，ＳＳＩＤ８｝を有する場合、ＳＳＩＤリストパラメータの差分は、「−」などの１ビットインジケータ、および｛ＳＳＩＤ９，ＳＳＩＤ１０｝などのＳＳＩＤサブセットとして、符号化されてもよい。

【0255】

要求のための第２の差分記述フィールドアプローチでは、図１４に示される簡易プローブ要求フレーム１４００は、それぞれが要素ＩＤ１４０５、１４１５、１４２５と、プローブ要求１４００における対応する要素（要素ＩＤによって識別される）の差分の記述１４１０、１４２０、１４３０とを含む、サブフィールドまたはＩＥの変数を含む。差分記述フィールド１４１０、１４２０、１４３０または特定の要素のＩＥの長さは、所定のものである（対応する要素ＩＤと１対１のマッピングを有する）。

【0256】

スキャンされることになる各チャネルに対し、ＳＴＡが、アクティブスキャンを示しているＭＬＭＥ−ＳＣＡＮ．ｒｅｑｕｅｓｔプリミティブを受信する時間から、対応するプローブ要求フレームが送信される時間までの待機時間が存在することがある。プローブ要求フレームの送信は、プローブ遅延時間が満了し、またはＰＨＹＲｘＳｔａｒｔ．ｉｎｄｉｃａｔｉｏｎプリミティブが受信されるまで待機してもよく、および、ＳＴＡが基本アクセスプロシージャを実行してもよい。

【0257】

アクティブスキャンを示しているスキャンタイプを有するＭＬＭＥ−ＳＣＡＮ．ｒｅｑｕｅｓｔプリミティブを受信すると、ＳＴＡは、スキャンされる各チャネルに対し、本明細書に記載するプロシージャを使用してもよい。

【0258】

スキャンされることになるチャネルにＳＴＡがプローブ要求を送信するための待機期間の間、ＳＴＡは、別のＳＴＡによって送信されたプローブ要求をオーバーヒアしたかをチェックしてもよい。ＳＴＡがプローブ要求をヒアしていない場合、ＳＴＡは、通常のプローブ要求フレームをＡＰに送信することを続けてもよい。残りのスキャンニングプロシージャは、通常のプローブ要求のそれと同一であってもよい。

【0259】

ＳＴＡがプローブ要求をヒアしていた場合、ＳＴＡは、オーバーヒア／受信されたプローブ要求におけるパラメータを、ＳＴＡが保留プローブ要求で送信することを望むパラメータと比較してもよい。異なるパラメータの数がＫよりも大きい場合、ＳＴＡは、通常のプローブ要求フレームをＡＰに送信してもよい。残りのスキャンニングプロシージャは、通常のプローブ要求のそれと同一であってもよい。

【0260】

異なるパラメータの数がＫ以下である場合、ＳＴＡは、異なる記述フィールドで、本明細書に記載するフォーマットを使用して、簡易プローブ要求を生成してもよい。

【0261】

簡易プローブ要求フレームを受信すると、ＡＰは、簡易プローブ要求フレームにおける参照フィールドまたはＩＥを使用して、以前に受信された参照プローブ要求フレームの情報を検索し、および、それを差分記述フィールドと結合して、簡易プローブ要求に対して完全なパラメータを再構成してもよい。残りのスキャンニングプロシージャは、通常のプローブ要求のそれと同一であってもよい。

【0262】

保留プローブ応答のスキャンニングパラメータの大部分は、以前に受信されたプローブ応答のものと同一であってもよい。しかしながら、一部のパラメータは異なってもよい。簡易プローブ応答フレーム１５００、１６００（図１５および図１６に示す）のより頻繁な利用を可能にしてオーバーヘッドを低減するために、簡易プローブ応答フレーム１５００、１６００において差分記述フィールド１５１０、１６１０またはＩＥが使用されて、以前に受信されたプローブ応答と、簡易プローブ応答との間のパラメータにおける差分を示してもよい。

【0263】

本明細書では２つの代替的実施形態が説明されて、以前に受信されたプローブ応答と、簡易プローブ要求フレームにおいて送信されることになるプローブ応答との差分を示す。フレーム１５００、１６００は、ともに別のプローブ応答への参照を含んでもよい。フレーム１５００では、参照は、その独自のフィールド１５１２にあり、フレーム１６００では参照は、ＭＡＣヘッダ１６１４にある。フレーム１５００とフレーム１６００の両方が、ＰＬＣＰヘッダ１５１６、１６１６、およびＦＣＳフィールド１５１８、１６１８を含むことに留意する。

【0264】

図１７に示される、第１の応答アプローチでは、簡易プローブ応答フレーム１７００における差分記述フィールドは、それぞれプローブ応答１７００における予め定義された要素の差分を記述する固定数のサブフィールド１７１０、１７２０、１７３０またはＩＥを含む。各サブフィールドまたはＩＥのシーケンスおよび意味は予め定められているので、各サブフィールドまたはＩＥは、要素ＩＤを含まなくてもよい。１つのサブフィールドは、ＴＳＦ値またはタイムスタンプ値であり、現在のＴＳＦ値と以前のプローブ応答におけるＴＳＦ値との差分もしくはデルタ（すなわち、ＴＳＦ現在−ＴＳＦ以前）または現在のＴＳＦであってもよい。

【0265】

ＳＴＡが単に、以前に受信したプローブ応答を、Ｔｍａｘマイクロ秒の最大継続時間まで保持することがある場合、デルタＴＳＦ値のサブフィールドは、

【0266】

【数1】

【0267】

ビットまたは

【0268】

【数2】

【0269】

オクテットの長さを有することになる。

【0270】

図１８に示す第２の応答アプローチでは、簡易プローブ応答フレーム１８００における差分記述フィールドは、その後に、それぞれ要素ＩＤ１８０５、１８２５と、プローブ応答１８００における対応する要素（要素ＩＤによって識別される）の差分の記述１８１０、１８３０とを含む可変数のサブフィールドまたはＩＥが続く、差分ＴＳＦ値またはタイムスタンプ値のサブフィールド１８０３を含む。差分記述フィールド１８１０、１８３０、または特定の要素のＩＥの長さは、所定のものであってもよい（対応する要素ＩＤと１対１のマッピングを有する）。差分ＴＳＦ値サブフィールド１８０３の長さは、第１のアプローチで使用されたものと同一であってもよい。

【0271】

ＡＰが、最後のＮｍｓ内にプローブ応答を送信しており、ＡＰが、ＳＴＡに送信されることになる保留プローブ応答を有する場合、ＡＰは、以前に送信されたプローブ応答におけるパラメータを、保留プローブ応答における送信することを望むパラメータと比較してもよい。Ｎの値は、スキャニングＳＴＡがチャネルをリスンしていた時間に等しくすることができるパラメータである。Ｎの値は、プローブ遅延＋対象のプローブ応答に対応するプローブ要求がＡＰで受信されてから経過した時間＋マージン、によって表されてもよい。

【0272】

異なるパラメータの数が、Ｋよりも大きい場合、ＡＰは、通常のプローブ応答フレームをＳＴＡに送信してもよい。残りのスキャンニングプロシージャは、通常のプローブ応答のそれと同一であってもよい。

【0273】

異なるパラメータの数が、Ｋ以下である場合、ＡＰは、本明細書に記載したように差分記述フィールドで本明細書に記載した形式を使用して簡易プローブ応答を生成してもよい。

【0274】

簡易プローブ応答フレームを受信すると、ＳＴＡは、簡易プローブ応答フレームにおける参照フィールドまたはＩＥを使用して、以前に受信された参照プローブ応答フレームの情報を検索し、それを差分記述フィールドと結合して、簡易プローブ応答に対する完全なパラメータを再構成してもよい。残りのスキャンニングプロシージャは、通常のプローブ応答のそれと同一であってもよい。

【0275】

簡易プローブ応答フレームはまた、ＯＢＳＳに使用されてもよい。ＯＢＳＳにおける第１のＡＰが、通常のプローブ応答を送信するとき、第２のＡＰは、第１のＡＰによって送信された通常のプローブ応答をオーバーヒアしてもよく、簡易プローブ応答を別のＳＴＡまたはブロードキャストアドレスに送信してもよい。簡易プローブ応答は、第１のＡＰによって送信された以前のプローブ応答を参照してもよい。簡易プローブ応答は、プローブ応答参照フィールドまたはＩＥを含んでもよい。

【0276】

参照プローブ応答および／または参照プローブ応答のシーケンス制御番号を送信したＡＰのＢＳＳＩＤ（またはＭＡＣアドレス）は、参照プローブ応答を識別するために使用されてもよい。

【0277】

ＡＰがプローブ応答を送信するための待機期間の間、ＡＰは、最後のＮｍｓ内に別のＡＰによる別のプローブ応答をオーバーヒアしたかをチェックしてもよい。Ｎは、スキャニングＳＴＡがチャネルをリスンしていた時間に等しくてもよいパラメータである。Ｎの値は、プローブ遅延＋対象のプローブ応答に対応するプローブ要求がＡＰで受信されてから経過した時間＋マージンに等しくてもよい。

【0278】

ＡＰが別のプローブ応答をオーバーヒアしていない場合、ＡＰは、通常のプローブ応答フレームをＳＴＡに送信することを続けてもよい。残りのスキャンニングプロシージャは、通常のプローブ応答のそれと同一であってもよい。ＡＰが別のプローブ応答をオーバーヒアしていた場合、ＡＰは、以前にオーバーヒアしたプローブ応答におけるパラメータを、保留プローブ応答で送信することを試みるパラメータと比較してもよい。異なるパラメータの数が、Ｋよりも大きい場合、ＡＰは、通常のプローブ応答フレームをＳＴＡに送信することを続けてもよい。残りのスキャンニングプロシージャは、通常のプローブ応答のそれと同一であってもよい。

【0279】

異なるパラメータの数が、Ｋ以下である場合、ＡＰは、本明細書に記載したように差分記述フィールドで本明細書に記載した形式を使用して簡易プローブ応答を生成してもよい。簡易プローブ応答フレームを受信すると、ＳＴＡは、簡易プローブ応答フレームにおける参照フィールドまたはＩＥ（参照プローブ応答を送信したＡＰのＢＳＳＩＤ／ＭＡＣアドレス、および／または参照プローブ応答のシーケンス制御番号）を使用して、以前に受信された参照プローブ応答フレームの情報を検索し、それを差分記述フィールドと結合して、簡易プローブ応答に対する完全なパラメータを再構成してもよい。残りのスキャンニングプロシージャは、通常のプローブ応答のそれと同一であってもよい。

【0280】

簡易プローブ応答に対するリカバリ方式では、ＳＴＡは、ＡＰから受信する簡易プローブ応答を理解しなくてもよい。スキャニングＳＴＡからプローブ要求を受信すると、本明細書に記載する簡易プローブ応答を使用する条件が満たされるとき、ＡＰが、簡易プローブ応答を送信して応答してもよい。簡易プローブ応答の送信後、ＡＰは、本明細書では「ＡＣＫタイマ」と称されるタイマを開始する。ＡＣＫタイマが、予め定義された値（ＳＩＦＳまたはＡＣＫもしくはショートＡＣＫの継続時間に基づいていてもよく、例えば、ＳＩＦＳ期間＋ＡＣＫまたはショートＡＣＫの継続時間）に到達するまでに、ＡＰが、スキャニングＳＴＡからＡＣＫを受信しない場合、ＡＰは、例えば、参照プローブ応答がＳＴＡによって受信されなかったという側面に起因して、簡易プローブ応答はスキャニングＳＴＡによって理解されないとみなすことができる。ＡＰは、その後、通常のプローブ応答をスキャニングＳＴＡに送信して、それをエラーケースからリカバリしてもよい。

【0281】

実施形態

【0282】

実施形態１。２つの送信機を備えたネットワークにおけるアクティブスキャンニングのための方法であって、
第１の送信機から発信するスキャンニングターゲットを有する第１のプローブ要求を検出するステップと、
第２の送信機からスキャンニングターゲットへプローブ要求を送信することを要求するステップと、
第２の送信機が第１のプローブ要求を検出するという条件で、第２のプローブ要求をキャンセルするステップとを備えている方法。

【0283】

実施形態２。第１のプローブ要求フレームの相対受信信号強度インジケータ（ＲＳＳＩ）が、所定の閾値未満である実施形態１の方法。

【0284】

実施形態３。プローブ要求が、第１の局によって送信され、プローブ応答が、第１のプローブ要求に応答して、アクセスポイントから送信される実施形態１の方法。

【0285】

実施形態４。第１のプローブ要求が第２の送信機によって検出されるという条件で、ＳＭＥが、現在のチャネルのアクティブスキャンニングを停止するためのインジケーションを有するＭＬＭＥ−Ｓｃａｎ−ＳＴＯＰ．ｒｅｑｕｅｓｔプリミティブを生成する実施形態１の方法。

【0286】

実施形態５。第２の送信機が同一のスキャンニングターゲットを有する第１のプローブ要求を検出しないという条件で、第２の送信機からスキャンニングターゲットにプローブ要求を送信するステップをさらに含む、実施形態１の方法。

【0287】

実施形態６。２つの送信機を備えたネットワークにおけるアクティブスキャンニングのための方法であって、
第１の送信機からスキャンニングターゲットを有する第１のプローブ要求を送信するステップと、
第２の送信機からスキャンニングターゲットへ第２のプローブ要求を送信することを要求するステップと、
第１のプローブ要求へのプローブ応答を検出するステップと、
第２の送信機がプローブ応答を検出するという条件で、第２の送信機からプローブ要求をキャンセルするステップとを備えている方法。

【0288】

実施形態７。第１のプローブ要求フレームの相対受信信号強度インジケータ（ＲＳＳＩ）が、所定の閾値未満である実施形態６の方法。

【0289】

実施形態８。実施形態７の方法であって、
プローブタイマが最小チャネル時間に到達する前に、ＰＨＹ−ＣＣＡ．ｉｎｄｉｃａｔｉｏｎプリミティブが検出されないという条件で、ネットワーク割り当てベクトル（ＮＡＶ）を０に設定し、次のチャネルをスキャンするステップをさらに備えている方法。

【0290】

実施形態９。プローブ要求は、第１の局によって送信され、検出は、第２の局で行われ、プローブ応答は、アクセスポイントによって送信される実施形態６の方法。

【0291】

実施形態１０。第１のプローブ要求へのプローブ要求が送信されるという条件で、ＳＭＥが、現在のチャネルのアクティブスキャンニングを停止するためのインジケーションを有するＭＬＭＥ−Ｓｃａｎ−ＳＴＯＰ．ｒｅｑｕｅｓｔプリミティブを生成する実施形態６の方法。

【0292】

実施形態１１。実施形態６の方法であって、
第２の送信機が同一のスキャンニングターゲットを有するプローブ応答を検出しないという条件で、スキャンニングターゲットに第２のプローブ要求を送信するステップをさらに備えている方法。

【0293】

実施形態１２。少なくとも２つの送信／受信ユニット（ＴＲＵ）を備えたネットワークにおけるアクティブスキャンニングのための方法であって、
第１のＴＲＵからのプローブ要求を送信して、スキャンされるチャネルのチャネル情報を取得することを要求するステップと、
第２のＴＲＵによってチャネル情報を送信するステップと、
第１のＴＲＵによって所望のチャネル情報を受信するステップと、
第１のＴＲＵからのプローブ要求をキャンセルするステップとを備えている方法。

【0294】

実施形態１３。第１のＷＴＲＵによって受信されるチャネル情報は、第２のＴＲＵから送信されるビーコンフレームに含まれている実施形態１２の方法。

【0295】

実施形態１４。第１のＷＴＲＵによって受信されるチャネル情報は、第２のＷＴＲＵから送信されるプローブ応答フレームに含まれ、プローブ応答フレームは、第３のＷＴＲＵから第２のＴＲＵへプローブ要求への応答として送信される実施形態１２の方法。

【0296】

実施形態１５。第１のＴＲＵによって受信されるチャネル情報は、第２のＴＲＵから送信されるブロードキャストフレームに含まれ、ショートビーコンフレーム、高速初期リンクセットアップ（ＦＩＬＳ）発見フレーム、または測定パイロットフレームのうちの少なくとも１つをさらに含む実施形態１２の方法。

【0297】

実施形態１６。チャネル情報は、アクティブスキャンを示すスキャンタイプを有するＭＬＭＥ−ＳＣＡＮ．ｒｅｑｕｅｓｔプリミティブの受信とプローブ要求の送信との間の待機期間の間に第１のＴＲＵによって受信される実施形態１２の方法。

【0298】

実施形態１７。待機時間は、プローブ遅延時間と、送信する前にチャネルアクセスプロシージャを行うために使用される時間と、待機期間を調整するために使用される時間とをさらに含む実施形態１６の方法。

【0299】

実施形態１８。チャネル情報を受信するために待機期間を調整するステップをさらに備えている実施形態１６の方法。

【0300】

実施形態１９。第１のＴＲＵからのプローブ要求送信のキャンセルは、第１のＴＲＵでチャネル情報が受信されるという条件で、ＳＭＥが現在のチャネルのアクティブスキャンニングを停止するためのインジケーションを有するＭＬＭＥ−Ｓｃａｎ−ＳＴＯＰ．ｒｅｑｕｅｓｔプリミティブを生成するステップを備えている実施形態１２の方法。

【0301】

実施形態２０。第１のＴＲＵからのプローブ要求送信のキャンセルは、現在のチャネルのアクティブスキャンニングを停止するステップと、切り換えて次のチャネルをスキャンそ、または現在のチャネルの収集されたチャネル情報を報告するステップとを備えている実施形態１２の方法。

【0302】

特徴および要素について特定の組合せで上述したが、各特徴または要素は、単独で、または他の特徴および要素とのいかなる組合せでも使用されることが可能であることを当業者は理解するであろう。さらに、本明細書に記載された方法は、コンピュータまたはプロセッサで実行するためにコンピュータ可読媒体に組み込まれたコンピュータプログラム、ソフトウェア、またはファームウェアで実行されることが可能である。コンピュータ可読媒体の例には、電子信号（有線または無線接続によって送信される）、およびコンピュータ可読記憶媒体が含まれる。コンピュータ可読記憶媒体の例には、リードオンリメモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、レジスタ、キャッシュメモリ、半導体メモリデバイス、内蔵ハードディスクおよびリムーバブルディスクなどの磁気媒体、光磁気媒体、およびＣＤ−ＲＯＭディスクおよびデジタル多用途ディスク（ＤＶＤ）などの光媒体が含まれるが、これらに限定されない。ソフトウェアと関連したプロセッサが使用されて、ＷＴＲＵ、ＵＥ、端末、基地局、ＲＮＣ、またはいずれかのホストコンピュータで使用する無線周波数送受信機を実現することができる。

【図1A】

【図1B】

【図1C】

【図2】

【図3】

【図3A】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図10A】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】

【図18】