特許 5718350 通信デバイスでの省電力

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

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

(11)【特許番号】5718350

(24)【登録日】2015年3月27日

(45)【発行日】2015年5月13日

(54)【発明の名称】通信デバイスでの省電力

(51)【国際特許分類】

   H04W 52/02 20090101AFI20150423BHJP

【ＦＩ】

   H04W52/02 111

【請求項の数】24

【全頁数】29

(21)【出願番号】特願2012-537191(P2012-537191)

(86)(22)【出願日】2010年11月2日

(65)【公表番号】特表2013-510469(P2013-510469A)

(43)【公表日】2013年3月21日

(86)【国際出願番号】US2010055118

(87)【国際公開番号】WO2011056790

(87)【国際公開日】20110512

【審査請求日】2013年10月22日

(31)【優先権主張番号】61/354,013

(32)【優先日】2010年6月11日

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

(31)【優先権主張番号】61/257,768

(32)【優先日】2009年11月3日

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

(73)【特許権者】

【識別番号】502188642

【氏名又は名称】マーベル ワールド トレード リミテッド

(74)【代理人】

【識別番号】110000877

【氏名又は名称】龍華国際特許業務法人

(72)【発明者】

【氏名】リウ、ヨン

(72)【発明者】

【氏名】ジャン、ホンヤン

【審査官】 望月 章俊

(56)【参考文献】

【文献】 米国特許出願公開第２００６／００４５０３５（ＵＳ，Ａ１）

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

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

(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】

前記排他的利用指標は、１ビットのフラグである、請求項２２または請求項２３に記載の装置。

【発明の詳細な説明】

【技術分野】

【0001】

本開示内容は、概して通信システムに関し、具体的には当該通信システムにおける省電力技術に関する。

【背景技術】

【0002】

［関連出願］
本願は、米国仮特許出願第６１／２５７，７６８号（発明の名称：「プリアンブルを用いた受信フィルタリング」、出願日：２００９年１１月３日）および第６１／３５４，０１３号（発明の名称：「ＶＨＴの省電力の改善」、出願日：２０１０年６月１１日）による恩恵を主張する。両出願の開示内容は全て、参照による本願に組み込まれることは明らかである。

【0003】

本明細書に記載する背景技術の説明は、本開示がどのような文脈で為されたかの概要を説明する目的で記載するものである。本願の発明者として名前を挙げているものの研究内容は、この背景技術のセクションに記載されている限りにおいて、出願時に先行技術と認められない部分と同様に、本開示に対する先行技術として明示的にも暗示的にも認めるものではない。

【0004】

ワイヤレスローカルエリアネットワーク（ＷＬＡＮ）は、過去１０年間の間に急速に発展が進んだ。米国電子電気学会（ＩＥＥＥ）８０２．１１ａ、８０２．１１ｂ、８０２．１１ｇおよび８０２．１１ｎ規格等のＷＬＡＮ規格の開発によって、単一ユーザピークデータスループットが改善された。例えば、ＩＥＥＥ８０２．１１ｂ規格では、１１メガビット毎秒（Ｍｂｐｓ）という単一ユーザピークスループットを仕様で定めており、ＩＥＥＥ８０２．１１ａ規格および８０２．１１ｇ規格では、５４Ｍｂｐｓという単一ユーザピークスループットを仕様で定めており、ＩＥＥＥ８０２．１１ｎ規格は、６００Ｍｂｐｓという単一ユーザピークスループットを仕様で定めている。新しい規格、ＩＥＥＥ８０２．１１ａｃに関する研究が始まっている。この規格では、さらなるスループットの改善が約束されている。

【発明の概要】

【課題を解決するための手段】

【0005】

ある実施形態によると、通信デバイスにおいて受信したデータユニットを処理する方法であって、受信したデータユニットに基づき、通信デバイスが指定された受信機であるか否かを判断する段階と、受信したデータユニットが排他的利用指標を含むか否かを判断する段階と、（ｉ）受信したデータユニットが排他的利用指標を含むか否かを判断する段階の判断結果、および、（ｉｉ）通信デバイスが指定された受信機であるか否かを判断する段階の判断結果に基づき、通信デバイスが入力されるデータユニットを監視する必要がない区間を決定する段階とを備え、排他的利用指標は、一の期間において少なくとも１つの指定された受信機にのみ複数のデータユニットを送信する旨を示しており、複数のデータユニットはそれぞれ、少なくとも対応する物理層（ＰＨＹ）プリアンブルを含む。

【0006】

別の実施形態によると、通信デバイスにおいて通信チャネルを介して送信するべくデータユニットを生成する方法であって、データユニットの少なくとも１つの指定された受信機の識別情報を特定するべく、データユニットの第１のフィールドを生成する段階と、排他的利用指標を含む、データユニットの第２のフィールドを生成する段階とを備え、排他的利用指標は、一の期間において少なくとも１つの指定された受信機にのみ複数のデータユニットを送信する旨を示しており、複数のデータユニットはそれぞれ、少なくとも対応する物理層（ＰＨＹ）プリアンブルを含む。

【0007】

別の実施形態によると、通信デバイスで用いられる装置であって、受信したデータユニットに基づいて、通信デバイスが指定された受信機であるか否かを判断するデータユニット処理部と、受信したデータユニットが排他的利用指標を含むか否かを判断する排他的利用指標処理部と、（ｉ）受信したデータユニットが排他的利用指標を含むか否かの判断結果、および、（ｉｉ）通信デバイスが指定された受信機であるか否かの判断結果に基づき、入力されるデータユニットを通信デバイスが監視する必要がない区間を決定するスリープ制御部とを備え、排他的利用指標は、一の期間において少なくとも１つの指定された受信機にのみ複数のデータユニットを送信する旨を示しており、複数のデータユニットはそれぞれ、少なくとも対応する物理層（ＰＨＹ）プリアンブルを含む。

【0008】

別の実施形態によると、通信デバイスで用いられる装置であって、データユニットの少なくとも１つの指定された受信機の識別情報を特定するべく、データユニットの第１のフィールドを生成するフレーム生成モジュールと、排他的利用指標を含むデータユニットの第２のフィールドを生成する排他的利用指標生成部とを備え、排他的利用指標は、一の期間において少なくとも１つの指定された受信機にのみ複数のデータユニットを送信する旨を示しており、複数のデータユニットはそれぞれ、少なくとも対応する物理層（ＰＨＹ）プリアンブルを含む。

【図面の簡単な説明】

【0009】

【図1】備える１以上のデバイスが本開示に係る省電力技術を利用する通信システムを示すブロック図である。

【0010】

【図2A】送信要求（ＲＴＳ）フレーム、送信準備完了（ＣＴＳ）フレーム、および、１以上のデータフレームを含む公知の送信機会（ＴｘＯＰ）形式を示す図である。

【0011】

【図2B】公知のアグリゲートメディアアクセスコントロール（ＭＡＣ）プロトコルデータユニット（ＡＭＰＤＵ）を示す図であり、複数のＡＭＰＤＵサブフレームを含むことを示す図である。

【0012】

【図2C】ある実施形態に係る、複数の受信デバイスに対する同時送信のために一部分が空間多重化されている通信フレームを示す図である。

【0013】

【図3】ある実施形態に係る、図１のシステムで送信される通信フレームに含められるグループ定義フィールドを示す図である。

【0014】

【図4A】ある実施形態に係る、マルチユーザ（ＭＵ）指標サブフィールドでＭＵの利用を示すストリーム指標フィールドを示す図である。

【0015】

【図4B】ある実施形態に係る、ＭＵ指標サブフィールドでシングルユーザ（ＳＵ）の利用を示すストリーム指標フィールドを示す図であり、ストリーム指標フィールドが受信フィルタリング情報を含む様子を示す図である。

【0016】

【図4C】別の実施形態に係る、ＭＵ指標サブフィールドでＳＵの利用を示すストリーム指標フィールドを示す図であり、ストリーム指標フィールドが受信フィルタリング情報を含む様子を示す図である。

【0017】

【図5A】公知のＲＴＳフレームを示す図である。

【0018】

【図5B】ある実施形態に係る、フレーム制御フィールドに排他的利用指標を含むＲＴＳフレームを示す図である。

【0019】

【図6】ある実施形態に係る、ＲＴＳフレームを含む制御ラッパフレームを示す図である。

【0020】

【図7A】ある実施形態に係る、図６に示す制御ラッパフレームに含み得る排他的利用指標を持つ高スループット（ＨＴ）制御フィールドを示す図である。

【0021】

【図7B】ある実施形態に係る、図６に示す制御ラッパフレームに含み得るグループ識別子を持つＨＴ制御フィールドを示す図である。

【0022】

【図8A】公知のＣＴＳフレームを示す図である。

【0023】

【図8B】ある実施形態に係る、フレーム制御フィールドに排他的利用指標を含むＣＴＳフレームを示す図である。

【0024】

【図9A】ある実施形態に係る、巡回冗長検査（ＣＲＣ）ビットまたはパリティビットを含むサービスフィールドを示す図である。

【0025】

【図9B】ある実施形態に係る、第１のＡＭＰＤＵサブフレームのデリミタによってサービスフィールドをチェックする通信フレームの一部分を示す図である。

【0026】

【図9C】ある実施形態に係る、第１のＡＭＰＤＵサブフレームのフレームチェックシーケンス（ＦＣＳ）フィールドによってサービスフィールドをチェックする通信フレームの一部分を示す図である。

【0027】

【図9D】ある実施形態に係る、スクランブラシードを含む物理層（ＰＨＹ）プリアンブルの超高スループット（ＶＨＴ）信号伝達（ＳＩＧ）フィールドを示す図である。

【0028】

【図10A】ある実施形態に係る通信フレームの一部分を示す図であり、ＰＳＤＵヘッダが、受信フィルタリングに用いられ得る情報を含むＰＨＹサービスデータユニット（ＰＳＤＵ）ヘッダを含む様子を示す図である。

【0029】

【図10B】ある実施形態に係るＰＳＤＵヘッダを示す図である。

【0030】

【図11】ある実施形態に係るＣＲＣビットまたはパリティビットを含むＭＡＣヘッダを示す図である。

【0031】

【図12】ある実施形態に係る、受信フィルタリング情報を含む通信フレームを生成する送信機を示す図である。

【0032】

【図13】ある実施形態に係る、受信フィルタリング情報を含む通信フレームを処理する受信機を示す図である。

【0033】

【図14】ある実施形態に係る、排他的利用指標を含む通信フレームを生成する方法の一例を説明するフローチャートである。

【0034】

【図15】ある実施形態に係る、通信フレームに含められた排他的利用指標を利用して許容可能なスリープ期間を決定する方法の一例を説明するフローチャートである。

【0035】

【図16】ある実施形態に係る、通信フレームまたはその一部分が適切に受信され得るか否かの判断結果に基づいて、受信フィルタリングを行う方法の一例を説明するフローチャートである。

【0036】

【図17】ある実施形態に係る、通信フレームのＰＨＹプリアンブルに含まれた指標を用いて許容可能なスリープ期間を決定する方法の一例を説明するフローチャートである。

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

【0037】

図１は、ワイヤレスローカルエリアネットワーク（ＷＬＡＮ）１０の一例を示すブロック図である。ＷＬＡＮ１０では、アクセスポイント（ＡＰ）１４等の無線ネットワークデバイスが通信フレーム等の信号を生成する。ある実施形態によると、通信フレームは、当該通信フレームの特定の受信機が、当該受信機が共有無線チャネル１２上の他の通信を無視可能な期間（以下では、「スリープ期間」と呼ぶ）を高効率で決定できるような情報を含む。一部の実施形態によると、受信機は、スリープ期間の決定に応じて、少なくとも当該受信機の通信モジュールの電源を切り、電力および処理時間を節約する。後述するさまざまな実施形態によると、ＷＬＡＮ１０で動作するＡＰ１４または別のデバイスは、特定の期間、例えば、特定のネットワーク割り当てベクトル（ＮＡＶ）に対応付けられている期間（例えば、送信機会（ＴｘＯＰ）、省電力マルチポーリング（ＰＳＭＰ）期間、シングルユーザ（ＳＵ）またはマルチユーザ（ＭＵ）の場合の送信−応答シーケンス、当該シーケンスを複数含むシーケンス群、複数の通信フレームを含むシーケンス等）が１以上のネットワークデバイスによる排他的利用のために保留されていることを示す指標を生成する。これによって、他のネットワークデバイスは、この期間において関連する可能性のある通信フレームを監視する必要があるか否かを判断することができる。またこれも後述するが、一部の実施形態によると、ネットワークデバイスは、１以上の特定のネットワークデバイスに送信される予定の通信フレームを、当該通信フレームの受信機が当該通信フレームが当該受信機に対してアドレス指定されているのか、別のネットワークデバイスにアドレス指定されているのかを高効率且つ高精度で決定できるようにフォーマッティングする。これによって、当該受信機に対してアドレス指定されていない場合には通信フレームの処理を省略して、電力を節約する。便宜上、特定のデバイスによる排他的利用のために特定の期間が保留されているか否かを指定および判断する方法、通信フレームが当該通信フレームの特定の受信機に対して送信されているか否かを高効率且つ高精度に検出する方法、および、通信フレームの特定の一部分に基づき、受信機が通信フレームの残り部分を復号可能か否かを判断する方法は、本明細書において「受信フィルタリング」方法と呼ぶ。

【0038】

ある実施形態によると、ＷＬＡＮ１０は、ＡＰ１４とＫ個のクライアント局２５との間においてダウンリンク（ＤＬ）マルチユーザ（ＭＵ）多入力多出力（ＭＩＭＯ）通信をサポートする。また、ＷＬＡＮ１０は、少なくとも一部の実施形態において、ＡＰと各クライアント局２５との間においてＤＬシングルユーザ（ＳＵ）通信をサポートする。ＡＰ１４およびクライアント局２５は、「通信デバイス」と呼ぶとしてよい。少なくとも一部の実施例によると、ＡＰ１４および少なくとも一部のクライアント局２５は、一の通信フレームが特定のクライアント局群に送信されるグループ送信モードをサポートする。より詳細に後述するが、クライアント局群（以下では、「ＭＵグループ」と呼ぶ）に送信される通信フレームは、複数の異なる空間ストリームまたは空間−時間ストリームを用いて同時に送信される複数のクライアント固有部分を含むとしてよい。本明細書で説明する実施形態のうち少なくとも一部の実施形態では、各通信フレームは、対応する物理層（ＰＨＹ）プリアンブルを含むデータユニットである。

【0039】

ＡＰ１４では、ホストプロセッサ１５がネットワークインターフェース１６に結合されている。ある実施形態によると、ネットワークインターフェース１６は、メディアアクセスコントロール（ＭＡＣ）部１８、ＰＨＹ部２０、ならびに、ＭＡＣ部１８およびＰＨＹ部２０の一方または両方に結合される受信フィルタリング送信（Ｔｘ）制御部１９を含む。ＰＨＹ部２０はさらに、ＮＴ個の送受信機２１を含む。当該送受信機は、ＮＴ個のアンテナ２４に結合されている。図１では送受信機２１およびアンテナ２４としてそれぞれ３つを図示しているが（つまり、ＮＴ＝３）、ＡＰ１４が有する送受信機２１およびアンテナ２４の数は他の実施形態では変更することができる（例えば、ＮＴ＝２、４、５等）。

【0040】

動作について説明すると、ある実施形態では、受信フィルタリングＴｘ制御部１９は、特定のネットワークデバイスが排他的に利用できるように特定の期間を保留すべきか否か判断し、ＭＡＣ部１８および／またはＰＨＹ部２０にＰＨＹ層またはＭＡＣ層の一方または両方において適切な指標を生成させる。別の実施形態によると、受信フィルタリングＴｘ制御部１９は、ＭＡＣ部１８および／またはＰＨＹ部２０に、通信フレームを生成させる。通信フレームは、当該通信フレームを受信したデバイスが、当該通信フレームの一部分に基づき、通信フレームの残り部分を処理すべきか否かを高速且つ正確に決定することができるように構成される。

【0041】

図１をさらに参照して説明を続けると、各クライアント局２５−ｉは、対応する複数のアンテナを備える。図１には３つのクライアント局２５を図示しているが、ＷＬＡＮ１０が備えるクライアント局２５の数はさまざまな状況および実施形態において変更することができる（例えば、Ｋ＝２、４、５、６等）。ある実施形態によると、クライアント局２５のうち２以上は、ＡＰ１４から同時に送信された複数のデータストリームを受信するように構成されている。また、ある状況を一例として挙げると、複数のクライアント局２５（例えば、クライアント局２５−１および２５−２）は、一時的にＭＵグループに対応付けて、ＡＰ１４は、複数のクライアント固有部分を、空間多重化を利用して、ＭＵグループに対応付けられているクライアント局に同時に送信するように、１以上のデータフレームを送信する。

【0042】

ある実施形態によると、クライアント局２５−１では、ホストプロセッサ２６がネットワークインターフェース２７に結合されている。ネットワークインターフェース２７は、ＭＡＣ部２８およびＰＨＹ部２９を含む。ＰＨＹ部２９は、Ｎ１個の送受信機３０を含む。Ｎ１個の送受信機３０はＮ１個のアンテナ３４に結合されている。図１には送受信機３０およびアンテナ３４をそれぞれ３個図示しているが（つまり、Ｎ１＝３）、クライアント局２５−１が含む送受信機３０およびアンテナ３４の数を、他の実施形態では、変更し得る（例えば、Ｎ１＝１、２、４、５等）。クライアント局２５−２の構造は、クライアント局２５−１と同一または概して同様である。ある実施形態によると、クライアント局２５−２は、クライアント局２５−１と同様の構造を持つが、送受信機およびアンテナの数はそれぞれ、２個のみである（つまり、Ｎ２＝２）。他の実施形態では、クライアント局２５−２が備えるアンテナの数が異なる（例えば、１個、３個、４個、５個等）。

【0043】

ある実施形態によると、ＡＰ１４は、クライアント局２５−１および２５−２に複数の空間ストリームを送信するように構成されているので、各クライアント局は、対応する複数の区間ストリームを介してデータを受信する。例えば、ＡＰ１４が５個の空間ストリームを介して同時にデータを送信し、クライアント局２５−１が３つの空間ストリームを介してデータを受信し、クライアント局２５−２が２個の空間ストリームを介してデータを受信する。一般的に、クライアント局は、備えているアンテナの数より多い空間ストリームを利用することはできない。また、空間−時間コーディングを利用する場合、当業者であれば、複数の空間ストリームを空間−時間ストリームと呼ぶ場合がある。一部の実施形態によると、空間−時間ストリーム数が送信チェーン数より少ない場合、空間マッピングを利用する。簡単に説明すると、１のネットワークデバイスから２以上のネットワークデバイスに１の同一無線チャネル（例えば、周波数）を介してデータを同時に送信することは、本明細書において「ＭＵ送信」と呼ぶ。これとは対照的に、特定の１のネットワークデバイスに対する通信フレームの送信は、本明細書では「ＳＵ送信」と呼ぶ。ある実施形態によると、ＭＵ送信用の通信フレームを生成する機能およびＭＵ送信を処理する機能を持つネットワークデバイスは、本明細書において超高スループット（ＶＨＴ）プロトコルと呼ぶプロトコルに少なくとも応じて動作するように構成されている。一般的に、ＶＨＴプロトコルに応じて動作するネットワークデバイスは、ＭＵ送信およびＳＵ送信の両方を生成および処理する機能を持つ。

【0044】

ある実施形態によると、クライアント局のネットワークインターフェース２７は、ＭＡＣ部２８およびＰＨＹ部２９の一方または両方に通信可能に結合されている受信フィルタリングＲｘ制御部３３を含む。ある実施形態によると、受信フィルタリングＲｘ制御部３３は、通信フレームの入力を検出すると、本開示に係る１以上の方法を利用して、通信フレームの残りの部分を処理すべきか否かを高効率に決定する。一部の実施形態によると、受信フィルタリングＲｘ制御部３３はさらに、クライアント局２５−１が通信フレームの入力を監視する必要がない期間を決定する。

【0045】

図１を参照して説明を続けると、一部の実施形態では、ＷＬＡＮ１０はさらに、ＶＨＴプロトコルに応じて動作するように構成されていないが、レガシープロトコル（例えば、８０２．１１ｎ）に応じて動作するように構成されているクライアント局２５−３を含む。ある実施形態によると、レガシープロトコルは、高スループット（ＨＴ）形式を含む。このようなクライアント局２５−３は、本明細書では「レガシークライアント局」と呼ぶ。一部の実施形態によると、ＷＬＡＮ１０は、複数のレガシークライアント局を含む。他の実施形態では、ＷＬＡＮ１０にはレガシークライアント局を含まない。

【0046】

本開示に係る受信フィルタリング方法の一例をより詳細に説明する前に明確にしておくべく、公知の送信機会（ＴｘＯＰ）形式および公知のアグリゲート・メディア・アクセス・コントロール（ＭＡＣ）プロトコルデータユニットの形式をそれぞれ、図２Ａおよび図２Ｂを参照しつつ説明する。

【0047】

図２Ａをまず参照すると、ＷＬＡＮ１０等の通信システムにおけるＴｘＯＰ５０は通常、１のネットワークデバイスが共有通信チャネルへのアクセスを取得する期間に対応する。複数のネットワークデバイスが同時に送信を行わないようにするべく（衝突が発生する可能性があるので）、１のネットワークデバイスは、送信要求（ＲＴＳ）５２を送信して、これに応じて送信準備完了（ＣＴＳ）５４を受信する。例えば、クライアント局２５−１がＲＴＳをＡＰ１４に送信し、対応するＣＴＳをＡＰ１４から受信するまでデータフレームの送信を開始しない。このようにして、別のクライアント局がクライアント局２５−１と同時または略同時にＲＴＳをＡＰ１４に対して送信すると、ＡＰ１４は、ＴｘＯＰ５０の期間にわたって、１つのクライアント局（例えば、ＲＴＳを最初に送信したクライアント局）にのみ通信チャネルへのアクセスを許可する。

【0048】

クライアント局（またはＡＰ）は、ＣＴＳを受信すると、１以上のデータフレーム５６−１、５６−２、５６−Ｌの送信を行う。全てのクライアント局およびＡＰは、ＴｘＯＰ５０の間、通信フレームを見逃さないように入力される通信フレームを監視する。

【0049】

図２Ｂは、公知のアグリゲートＭＡＣプロトコルデータユニット（ＡＭＰＤＵ）６０を示す図である。ＡＭＰＤＵ６０は、ＡＭＰＤＵサブフレーム１、２、・・・、Ｎを含む。一部のケースを説明すると、例えば、ＭＡＣ層に対応付けられるセグメンテーションおよび再アセンブリの原則（例えば、フレーム長に課される制限）のために、通信デバイスが、特定量のデータを、後に一のＡＭＰＤＵにアセンブルして１のＰＨＹデータユニットのＶＨＴ−ＡＭＰＤＵ部分として送信する複数のＡＭＰＤＵサブフレームにフォーマッティングする必要がある。通信フレームのＶＨＴ−ＡＭＰＤＵ部分でＶＨＴ−ＡＭＰＤＵを送信する方法の一例について、図２Ｃを参照しつつ後述する。

【0050】

図２Ｂに図示しているように、各ＡＭＰＤＵサブフレームは、当該ＡＭＰＤＵサブフレームの先頭を示すデリミタフィールド６２と、ＭＡＣヘッダフィールド６４と、（ＭＡＣ）フレーム本体フィールド６６と、フィールド６４および６６のインテグリティを確認するためのフレーム検査シーケンス（ＦＣＳ）フィールド６８とを含む。複数のＡＭＰＤＵサブフレームを含むＡＭＰＤＵを生成および処理する公知の方法によると、ＡＭＰＤＵが含む全てのサブフレームは、同一受信機に送信される。

【0051】

ある実施形態によると、図２Ｂに図示した形式に準拠するＡＭＰＤＵは、図２Ｃを参照しつつ後述するデータユニット７０（例えば、通信フレーム）を用いて送信する。ある実施形態によると、ＡＰ１４等のネットワークデバイスは、直交周波数分割多重（ＯＦＤＭ）変調を利用してクライアント局にデータユニット７０を送信するように構成されている。ある実施形態によると、データユニット７０は、空間多重化を利用して対応するユーザ（例えば、クライアント局）にユーザ固有情報を送信するＭＵ通信フレームである。

【0052】

ある実施形態によると、データユニット７０のプリアンブルは、レガシートレーニングフィールド（Ｌ−ＴＦ）７２を含み、Ｌ−ＴＦ７２は、１のレガシーショートトレーニングフィールド（ＬＳＴＦ）および１以上のレガシーロングトレーニングフィールド（Ｌ−ＬＴＦ）を含む。データユニット７０はさらに、レガシー信号フィールドＬ−ＳＩＧ７４を含む。フィールド７２および７４によって、データユニット７０のレガシー部分を形成する。実施形態の少なくとも一部では、フィールド７２に含まれるＬ−ＳＴＦおよびＬ−ＬＴＦは、Ｌ−ＳＩＧフィールド７４と同様に、ＩＥＥＥ８０２．１１ａ規格および／またはＩＥＥＥ８０２．１１ｎ規格等のレガシープロトコルによって仕様を規定している形式に準拠している。Ｌ−ＳＩＧ７４の長さサブフィールドおよびレートサブフィールドは、データユニット７０のうちレガシー部分の後に来る残余部分の期間を示すように設定されている。このような構成とすることによって、ＶＨＴプロトコルに応じて構成されていないクライアント局が、例えば、搬送波感知多重アクセス／衝突回避（ＣＳＭＡ／ＣＡ）方式を採用するべく、データユニット７０の終端を判断することができるようになる。少なくとも一部の実施形態では、フィールド７２および７４は、ネットワーク（例えば、ＷＬＡＮ１０）内で動作している任意の局が少なくともフィールド７２および７４を処理できるような変調方式を用いて送信される。ある実施形態によると、データユニット７０のレガシー部分は、２０ＭＨｚ帯域を占有する。

【0053】

また、ある実施形態によると、データユニット７０は、ＶＨＴ部分を含み、ＶＨＴ部分は、ＶＨＴ信号伝達フィールド（ＶＨＴ−ＳＩＧＡ）７６、ＶＨＴトレーニングフィールド７８（例えば、ＶＨＴ−ＳＴＦおよび／またはＶＨＴ−ＬＴＦを含む）、ＶＨＴ信号伝達フィールド（ＶＨＴ−ＳＩＧＢ）８０、サービスフィールド８２、ＶＨＴ−ＡＭＰＤＵ８４、ＰＨＹパッド８４、および、テイル部分８８を含む。空間多重化または別の適切な方法を利用して、受信機固有情報を持つフィールド８２−８８を並列に複数の受信機に対して送信する。別の実施形態によると、ＶＨＴ−ＳＩＧＢ８０もまた、クライアント固有情報を持っており、空間多重化される。例えば、ＶＨＴ−ＳＩＧＡ７６は、全てのクライアント局に共通する情報（例えば、空間−時間ストリームの割り当て）を含み、ＶＨＴ−ＳＩＧＢ８０は、１のクライアント局に特有の情報（例えば、変調方式およびコーディングレート）を含む。

【0054】

簡単に説明すると、ＶＨＴトレーニングフィールド７８は、例えば、受信機にＭＩＭＯチャネルを正確に推定させるためのトレーニングシーケンスを含む。サービスフィールド８２は、一実施形態によると、スクランブラ初期化に用いられる。ある実施形態によると、ＶＨＴ−ＡＭＰＤＵ８４の形式は、図２Ｂを参照しつつ上述したＡＭＰＤＵ６０の形式と同様である。各ＶＨＴ−ＡＭＰＤＵ８４は１以上の空間ストリームを介して１の特定の受信機に特有の情報を搬送することに留意されたい。各受信機に送信されるＶＨＴ−ＡＭＰＤＵ８４は長さが同じである必要はないので、ＶＨＴ−ＡＭＰＤＵ８４の各インスタンスの後にＰＨＹパッド部分８６を追加する。場合によっては、ＰＨＹパッド部分８６の長さはゼロビットである。

【0055】

ある実施形態によると、ＶＨＴ−ＳＩＧＡ７６は、少なくとも一部のケースにおいて、グループ識別情報を含むストリーム指標フィールドを含み、データユニット７０がＭＵモードまたはＳＵモードで送信されるか否かを示し、データユニット７０がＭＵモードで送信される場合、ＭＵグループと、ＭＵグループに含まれる複数のクライアント局に対する空間ストリームのマッピングとを特定している。ストリーム指標フィールドの形式例については、図４Ａから図４Ｃを参照しつつより詳細に説明する。ある実施形態において、ストリーム指標フィールドおよび当該フィールドに含まれるグループ識別情報がデータユニット７０がＳＵモードで送信される旨を示す場合、データユニット７０の送信機は、データユニット７０の送信先である１の受信機以外のクライアント局への空間ストリームのマッピングを特定する必要はないと留意されたい。ある実施形態によると、ＳＵモードで送信されているデータユニット７０の宛先でない受信機がデータユニット７０の送信先が別のネットワークデバイスであるとより早い段階で判断できるように、送信機は、ストリーム指標フィールドのうち空間ストリームマッピングに割り当てられている部分の少なくとも一部を利用して、データユニット７０の受信先の識別情報の一部を少なくとも特定する。実施形態によっては、この「少なくとも特定」される「識別情報の一部」は、宛先である受信機のＭＡＣアドレス、宛先である受信機のアソシエーション識別情報（ＡＩＤ）等に対応する。このように、ＶＨＴ−ＳＩＧＡ７６に含まれるストリーム指標フィールドの一部、または、データユニット７０の別の部分（例えば、ＶＨＴ−ＳＩＧＢ８０）を受信フィルタリングに利用することができる。

【0056】

図４Ａから図４Ｃに図示したストリーム指標フィールドの形式の一例をより分かりやすく説明するべく、通信ネットワークにおけるＭＵグループ形成方法およびストリーム割り当て方法を以下で簡単に説明する。

【0057】

ある実施形態によると、ＡＰ１４等のネットワークデバイスは、ＭＵグループ、つまり、少なくとも１個のデータフレームを同時に送信する対象である複数のクライアント局を、データフレームのうち対応する空間ストリーム群で局固有情報を搬送する部分を用いて、定義する。ＡＰ１４は、ＭＵグループを形成する際に、各クライアント局の機能、各クライアント局に送信すべきデータの種類等のうち１以上を考慮する。ある実施形態によると、ＡＰ１４は、各グループを構成するクライアント局として最高で４個選択する。各グループに含めるクライアント局の数は、ＡＰ１４が備える送信アンテナの数によって制限されるのが普通である。

【0058】

続いて、ある実施形態によると、ＡＰ１４は、例えば、グループにグループ識別子（グループＩＤまたは単にＧＩＤ）を割り当てて、グループ定義フィールドを管理通信フレームまたは制御通信フレームに含めることでグループが形成された旨を発表する。ある実施形態によると、ＡＰ１４は、グループ定義フィールドをチャネルサウンディング通信フレームに含める。さらに、ある実施形態によると、ＡＰ１４は、複数のグループ定義フィールドと、グループ定義フィールドの数を特定するフィールドとを含む通信フレームを生成する。

【0059】

図３は、グループ定義フィールド１００の一例を示す図である。ある実施形態によると、グループ定義フィールド１００は、ＧＩＤサブフィールド１０２および４つのアソシエーション識別子（ＡＩＤ）サブフィールド１０４を含む。他の実施形態によると、グループ定義フィールド１００が含むＡＩＤサブフィールドの数を変更する（例えば、２、３、５、６等）。グループ定義フィールド１００は、グループＩＤサブフィールド１０２が特定するグループ（つまり、「ＭＵグループ」）に割り当てられているＭＵ−ＭＩＭＯユーザと同数のＡＩＤサブフィールド１０４を含む。例えば、図３に示すように、ＡＩＤサブフィールド１０４は、第１のＡＩＤ（ＡＩＤ１）サブフィールド１０４−１、第２のＡＩＤ（ＡＩＤ２）サブフィールド１０４−２、第３のＡＩＤ（ＡＩＤ３）サブフィールド１０４−３、および、第４のＡＩＤ（ＡＩＤ４）サブフィールド１０４−４を含む。図１に戻って説明すると、一実施形態において、グループ定義フィールド１００は、ＰＨＹ部２０によって生成される。別の実施形態によると、ＡＩＤサブフィールド１０４のうち少なくとも１つ、および／または、当該ＡＩＤサブフィールド１０４に含まれる情報は、少なくとも一部分がＭＡＣ部１８によって生成される。

【0060】

各ＡＩＤサブフィールド１０４は、グループＩＤサブフィールド１６２が特定したＭＵグループにＡＰ１４が割り当てたクライアント局２５のうち１つのクライアント局２５のＡＩＤを含む。各クライアント局２５は、グループ定義フィールド１６０全てを受信して、ＡＩＤサブフィールド１０４のうち１つに含まれている自分のＡＩＤを検出した後、当該クライアント局２５が、グループＩＤサブフィールド１０２が特定しているＭＵグループの一員であると判断する。各クライアント局２５はさらに、複数のＡＩＤサブフィールド１０４における他のクライアント局２５のＡＩＤと相対的に決まる自分のＡＩＤの配置に基づいて、自分の空間ストリーム数の指標をストリーム指標フィールドで送信する順序を、他のクライアント局２５の指標と相対的に、決定する。これについては、簡単に上述しており、図４Ａから図４Ｃを参照しつつより詳細に説明する。グループ定義フィールド１００が特定のクライアント局２５のＡＩＤを含まない場合、ある実施形態によると、このクライアント局２５は、グループＩＤサブフィールド１０２が特定しているＭＵグループの一員ではないと判断して、クライアント局２５が自分が属しているＭＵグループを判断するまで、例えば、同一または他のサウンディングフレーム内の後続のグループ定義フィールドを監視する。通信システムにおいて空間ストリームまたは空間−時間ストリームを指定する方法の例は、関連技術と共に、同時係属中の米国特許出願第１２／９１０，６０８号（代理人整理番号：ＭＰ３４１５、発明の名称：「ＷＬＡＮ用のストリーム数指標」、以下では、「ＭＰ３４１５出願」と呼ぶ、出願日：２０１０：１０月２２日）に記載されている。当該出願の開示内容は全て、参照により本明細書に組み込まれる。

【0061】

図４Ａを参照すると、ある実施形態では、２以上のクライアント局を含むＭＵグループに通信フレームを送信するネットワークデバイスは、ストリーム指標フィールド１１０を利用する。図４Ａが対応するケース例では、ストリーム指標フィールド１１０は、ＭＵ指標サブフィールド１１２を含む。ＭＵ指標サブフィールド１１２が「ＭＵ」に設定されると、当該ストリーム指標フィールド１１０を含む通信フレームの少なくとも一部分がＭＵモードで送信されていることを示す。ある実施形態によると、ＭＵ指標サブフィールド１１２は、長さが１ビットである。ストリーム指標フィールド１１０はさらに、ＭＵグループを指定するＧＩＤサブフィールド１１４、および、指定されたＭＵグループに対応付けられているクライアント局に割り当てられている空間ストリームまたは空間−時間ストリームを示す複数の空間ストリームサブフィールドまたは空間−時間ストリームサブフィールド１１６を含む。一部の実施形態によると、ＧＩＤサブフィールド１１４の所定値は、通信フレームがＳＵモードで送信されていることを示す。このような一部の実施形態によると、ストリーム指標フィールド１１０は、ＭＵ指標サブフィールド１１２を含まないか、または、ＭＵ指標サブフィールド１１２のビットを用いて他の情報を搬送する。ある実施形態によると、ストリーム指標フィールド１１０の受信機は、管理フレームで先に受信したグループ定義フィールドに基づいて、当該受信機に関連するサブフィールド１１６を決定する。例えば、ＡＩＤ Ａを持つ受信機が受信するグループ定義フィールドは、ＭＵグループＧを特定しており、対応するＡＩＤサブフィールド群ではＡＩＤ Ａを２番目の位置に挙げている（例えば、図３の形式ではサブフィールド１０４−２）。ＭＵ指標サブフィールド１１２が「ＭＵ」に設定され、ＧＩＤサブフィールド１１４がＧに設定されているストリーム指標フィールド１１０を受信すると、受信機は、サブフィールド１１６−２をチェックして、当該受信機に割り当てられている空間ストリームまたは空間−時間ストリームを決定する。このような技術については、ＭＰ３４１５出願でより詳細に説明している。

【0062】

ある実施形態によると、各サブフィールド１１６は、ストリーム数として、０、１、２、３、４、５、６または８を特定するべく長さは３ビットである。別の実施形態によると、ストリーム指標フィールド１１０は、ＷＬＡＮの特定の実施例でサポートされていない状況を省略することによって、「圧縮」される。例えば、特定の実施形態によると、ＭＵ通信フレームを受信する際に利用するストリーム数について各クライアント局に対して４を限界値として設定するので、各サブフィールド１１６のサイズは２ビットまで小さくしても安全である。別の実施形態によると、クライアント局に対するストリームのマッピングとして許容可能なもの（例えば、４つのストリームを第１のクライアント局に、２つのストリームを第２のクライアント局に、１つのストリームを第３および第４のクライアント局それぞれにマッピング）はそれぞれ、ルックアップテーブルに列挙している。このため、複数のサブフィールド１１６は、ルックアップテーブルに対するインデックスを含む１つのサブフィールドに統合することができる。ストリーム指標フィールドのこのような形式については、本明細書では「圧縮形式」と呼ぶ。

【0063】

以下で図４Ａを参照しつつ説明すると、ＡＰ１４等のネットワークデバイスは、ＳＵモードで１の特定のクライアント局に通信フレームを送信し、ストリーム指標フィールド１２０を用いて受信フィルタリング情報を受信機に供給する。ある実施形態によると、ストリーム指標フィールド１２０は、ＳＵモードでは１以上のサブフィールドの利用方法が異なることを除き、上述したストリーム指標フィールド１１０と同じ形式である。したがって、ある実施形態によると、ネットワークデバイスは、ストリーム指標フィールド１１０または１２０を含む少なくとも一部分がＳＵモードでもＭＵモードでも同じになる通信フレームの形式を利用する。例えば、ある実施形態によると、ストリーム指標フィールド１２０は、ＰＨＹプリアンブルのＶＨＴ−ＳＩＧＡ部分に含められる。

【0064】

図４Ｂに示す実施形態では、ストリーム指標フィールド１２０のＭＵ指標サブフィールド１２２が「ＳＵ」に設定されると、当該ストリーム指標フィールド１２０を含む通信フレームがＳＵモードで送信されている旨を示す。空間ストリーム数サブフィールドまたは空間−時間ストリーム数サブフィールド１２６−１は、当該通信フレームの１の受信機に割り当てられている空間ストリームまたは空間−時間ストリームを指定する。ある実施形態によると、ストリーム指標フィールド１２０の残りのサブフィールドの一部または全てを用いて、受信フィルタリング情報を提供する。例えば、一実施形態によると、フィールド１２４、１２６−２、１２６−３および１２６−４の一部または全ては、通信フレームの指定された受信機のＭＡＣアドレスの最下位ビット（ＬＳＢ）または受信機のＭＡＣアドレスのアドレスビットの一部または全てから生成された別の指標（他の受信機の指標が同様で重複を避けるため）を特定している。さらに別の実施形態によると、これらのフィールドの一部または全てでは、通信フレームの指定された受信機のＡＩＤまたは部分ＡＩＤを特定している。さらに別の実施形態では、これらのフィールドの一部または全てでは、宛先である受信機に固有の他の情報を特定している。

【0065】

これらの実施形態では、クライアント局は、ストリーム指標フィールド１２０を受信して、ＭＵ指標サブフィールド１２２をチェックして通信フレームがＳＵモードで送信されていると判断して、サブフィールド１２２および１２６−１以外のサブフィールドに基づいて当該クライアント局が通信フレームの指定された受信機であるか否かを判断する。ある実施形態によると、クライアント局は、通信フレームの指定された受信機が当該クライアント局でないと判断することに応じて、通信フレームの処理を中止して、処理リソースおよび／または電力を節約するという利点を持つ。それ以外の場合には、クライアント局は通信フレームの処理を継続して行う。

【0066】

図４Ｃは、ストリーム指標フィールド１３０を示す図である。ストリーム指標フィールド１３０は、ストリーム指標フィールド１３０内の他の位置のビットが受信フィルタリングに用いられることを除き、概してストリーム指標フィールド１２０と同様である。この実施形態例では、フィールド１３６−１から１３６−４は、図４Ａの形式では空間ストリームまたは空間−時間ストリームを特定するために用いられているが、受信フィルタリング情報を搬送するために用いられる。

【0067】

一般的に、ＭＵモードおよびＳＵモードで利用されるストリーム指標フィールドは、送信側のデバイスが通信フレームがＭＵモードまたはＳＵモードのいずれで送信されているのかを特定できるように、さらに、一例では各クライアント局に対するストリームのマッピング、および、別の例では受信フィルタリング情報を特定できるように任意の適切な方法でフォーマッティングされ得る。このようにして、送信モードがＭＵモードおよびＳＵモードのいずれにおいても、同じフィールド（または、少なくとも、通信フレーム内の同位置にある同サイズのフィールド）を用いることができる。また、一部の実施形態によると、ネットワークデバイスは、ストリーム指標フィールドの圧縮形式を利用する。このような一実施形態によると、例えば、非圧縮方式に比べて、受信フィルタリングに用いられるビット数が少なくなる。

【0068】

一部の実施形態によると、ネットワークデバイスは、上述した方法を利用して高度な省電力対策を実施する。例えば、一実施形態によると、ＡＰまたはクライアント局は、グループ定義フィールド１００を用いて、多トラフィックモード（例えば、大型ファイルのダウンロード）で動作するクライアント局群を形成する。そして、ＡＰまたはクライアント局は、ＭＵモードでは形式１１０、ＳＵモードでは形式１２０に準拠したストリーム指標フィールドを利用して、例えば、現時点において多トラフィックモードで動作していない他のクライアント局による消費電力を効率よく制御する。

【0069】

続いて、図５Ａから図１１を参照しつつ他の受信フィルタリング方法を説明する。

【0070】

図５Ａを参照して説明すると、公知のＲＴＳフレーム１５０は、一部の通信システムにおいて、ＴｘＯＰを確保しておくために用いられる。ＲＴＳフレーム１５０は、フレーム制御フィールド１５２、長さフィールド１５４、受信機アドレス１５６、宛先アドレス１５８、および、ＦＣＳ１６０を含む。図２Ａを参照しつつ上述したように、ネットワークデバイスは、１以上の通信フレームの１以上の受信デバイスに対する送信にＴｘＯＰを割り当てる。ある実施形態によると、公知のＲＴＳフレーム１５０は、レガシープロトコルである８０２．１１プロトコルが定義した形式に準拠する。

【0071】

ネットワークデバイスの動作を効率化するべく（例えば、電力および／または他のリソースを節約するべく）、本開示のある実施形態によると、ＲＴＳフレーム１７０は、排他的利用指標１７２を含む。排他的利用指標１７２は、例えば、当該ＲＴＳフレーム１７０が対応するＮＡＶ（ネットワーク割り当てベクトル）期間（例えば、ＴｘＯＰ）が、受信機アドレスフィールド１７８で特定されているデバイス、または、別のケースでは、上述したストリーム指標フィールドを用いてＰＨＹプリアンブルで特定されているグループに対する情報の送信用のみに確保されているか否かを示す。ある実施形態によると、排他的利用指標１７２に対応付けられているＮＡＶ期間の長さは、長さフィールド１７６で示す。また、ある実施形態によると、排他的利用指標１７２は、ＦＣＳフレーム制御フィールド１７４に含まれている１ビットのフラグとして実現される。しかし、他の実施形態によると、排他的利用指標１７２は、例えば、ＰＨＹプリアンブル、ＰＨＹヘッダ、ＭＡＣヘッダ等内の別の適切な位置に含まれている。

【0072】

例を挙げると、ネットワークデバイスは、排他的利用指標１７２が「真」に設定されているＲＴＳ１７０を受信して、ＲＴＳ１７０に対応するＣＴＳ通信フレームを検出することに応じて（例えば、図２Ａを参照のこと）、対応するＴｘＯＰ（例えば、長さはフィールド１７６で特定されている）をフィールド１７８で特定されている受信機への排他的送信へ割り当てることにＲＴＳ１７０の送信機が成功したと判断する。ある実施形態によると、当該ネットワークデバイスは、フィールド１７８で特定されている受信機が当該ネットワークデバイスでない場合、ＲＴＳ１７０に対応付けられているＴｘＯＰの全期間にわたって入力される通信フレームの処理が不要であると判断する。ネットワークデバイスはこの後、実施形態によっては、例えば、通信回路またはデバイス全体をオフに制御する。しかし、排他的利用指標１７２が「偽」に設定されている場合、ネットワークデバイスは通常、ＴｘＯＰにおいて送信されている入力通信フレームをそれぞれチェックして、ネットワークデバイスが当該通信フレームの指定された受信機であるか否かを確認する。

【0073】

以下では図６を参照しつつ説明すると、別の実施形態では、図５Ａに示す公知の形式に準拠したＲＴＳが、排他的利用指標を含む制御ラッパフレーム１９０に「ラップ」されている。ある実施形態によると、制御ラッパフレーム１９０は、ＰＨＹプリアンブルおよびヘッダ部分１９２、フレーム制御フィールド１９４、長さフィールド１９６、アドレスフィールド１９８、搬送フレーム制御フィールド２００、ＨＴ／ＶＨＴ制御フィールド２０２、ＲＴＳを含む搬送フレーム部分２０４、および、ＦＣＳ２０６を含む。さまざまな実施形態によると、排他的利用指標は、フィールド１９２、１９４、２００または２０２のうち１以上のフィールドに含まれる。例えば、ある実施形態によると、１ビットのフラグとして実現される排他的利用指標は、ＭＡＣヘッダ内のＶＨＴ制御フィールドに含まれている。また、特定の実施形態によると、制御ラッパフレーム１９０のＶＨＴ制御フィールドはさらに、「ラップ」されたＲＴＳに対応付けられているＴｘＯＰが確保されているＭＵグループの指標を含む。上述した実施形態と同様に、制御ラッパフレーム１９０は、１以上の前段デバイスによる排他的利用にＴｘＯＰを割り当てるために用いることが出来るので、他のデバイスは高効率および高精度で受信フィルタリングを実行することができる。

【0074】

図７Ａは、例えば、図６の制御ラッパフレーム１９０に含まれる排他的利用指標を持つＨＴ−ＶＨＴ制御フィールド２２０の一例を示す図である。ＨＴ／ＶＨＴ制御フィールド２２０は通常、フィールド２２０の１以上の保留ビットまたはフィールド２２０の「無用」ビット（例えば、ＨＴ局について意味のある情報を持つが、ＶＨＴ局について意味のある情報を持たないビット）が排他的利用指標２２２Ａまたは２２２Ｂとして用いられていることを除き、ＩＥＥＥ８０２．１１ｎ規格が仕様を規定しているＨＴ制御フィールドと同様である。

【0075】

図７Ｂに示す別の実施形態では、ＨＴ／ＶＨＴ制御フィールド２３０は、対応するＴｘＯＰが割り当てられているＭＵグループを特定するグループ識別子を含む。本実施形態においてグループ識別子は、フィールド２３２および２３４の間で分割され、グループ識別子の最上位ビット（ＭＳＢ）はフィールド２３２に格納され、グループ識別子の最下位ビット（ＬＳＢ）はフィールド２３４に格納される。また、ある実施形態によると、制御ラッパフレームは、排他的利用指標およびグループ識別子の両方を含む。

【0076】

一部の実施形態によると、ＣＴＳフレームは、対応するＲＴＳフレームに含まれている排他的利用指標に代えて、または、当該排他的利用指標に加えて、排他的利用指標を含む。図８Ａは、公知の形式に準拠しているＣＴＳ２５０を示す。ＣＴＳ２５０は、フレーム制御フィールド２５２、長さフィールド２５４、受信機アドレスフィールド２５６、および、ＦＣＳ２５８を含む。一方、ある実施形態によると、図８Ｂに図示するＣＴＳフレーム２６０は、排他的利用指標２６４を含むフレーム制御フィールド２６２を含む。また、当該実施形態によると、ＣＴＳフレーム２５０または２６０は、上述したＲＴＳフレームと同様の制御ラッパフレームにラップすることができる。

【0077】

より一般的には、上述した方法と同一または同様の方法を用いて、排他的ＮＡＶ割当メカニズムを実現する。さまざまな実施形態において、特定のＮＡＶ期間は、ＳＵモードまたはＭＵモードでの送信／応答やり取り、このような送信／応答やり取りを２回以上含むシーケンス、ＴｘＯＰ期間、ＰＳＭＰ期間等に対応する。実施形態によっては、ネットワークデバイスは、ＭＡＣヘッダ、デリミタ（図２Ｂに示すデリミタ６２等）、サービスフィールド（図２Ｃのサービスフィールド８２等）、ＰＨＹプリアンブル等において、１の特定のネットワークデバイスまたは特定のネットワークデバイス群に対するデータの送信についてＮＡＶ期間の長さを特定する。一部の実施形態によると、ネットワークデバイスは、通信フレームのうち、ＮＡＶ期間を特定する上記の部分または他の部分において、ＮＡＶ期間の排他的利用を通知する。

【0078】

別の実施形態によると、割り当てられたＮＡＶ期間の排他的利用は、ＮＡＶ期間の長さを特定している通信フレームを受信するネットワークデバイスによって判断される。例えば、一実施形態によると、ネットワークデバイスは、ＮＡＶ割り当てを特定している通信フレームを受信することに応じて、ＮＡＶ期間についての排他的利用指標を含む確認応答フレーム（ＡＣＫ）を生成する。そして、このような一実施形態では、ＡＣＫの送信機が排他的に利用するようにＮＡＶ期間を確保する。別の実施形態によると、ネットワークデバイスは、ＮＡＶ割り当てを含む通信フレームを受信して、排他的利用指標と、ＮＡＶ期間が割り当てられるＭＵグループのＧＩＤとで応答する。このような実施形態の一部または全てでは、クライアント局は、例えば、一の特定の受信機または当該クライアント局を含まない受信機群が排他的に利用するべく特定のＮＡＶ期間を確保している旨を示す通信フレームを受信して、完全または部分的に（例えば、ＲＦ回路を一時的にディセーブル）オフになり、電力を節約する。

【0079】

続いて、通信フレームの宛先である受信機を特定する際の「偽の肯定回答」および「偽の否定回答」を回避するための受信フィルタリング技術を考える。具体的には、特定のケースでは、ネットワークデバイスは、自身を宛先としない通信フレームを、自身を宛先とする通信フレームと間違えて特定する。別のケースでは、ネットワークデバイスは、自身を宛先とする通信フレームを、自身を宛先としない通信フレームと特定する。以下でより詳細に説明するが、処理済の受信機の識別情報が正しいか否かを検証すると、通信フレーム全て、または、関連情報（例えば、ＣＲＣ、パリティ）の前の通信フレームの大部分を処理する必要がある場合がある。

【0080】

図９Ａを参照して説明すると、ある実施形態では、サービスフィールド３００が検証ビット（例えば、巡回冗長検査、パリティ）３０２を含むので、受信側のデバイスは、同様にサービスフィールド３００に含まれているスクランブラシード３０４が正しいか否か確認することができる。一部の実施形態によると、検証ビット３０２はさらに、スクランブラシード３０４の前にある他のフィールドまたはサブフィールド、例えば、ＶＨＴ−ＳＩＧＢ、Ｌ−ＳＩＧ等が正しいか否かをチェックするためにも用いられる。図２Ｃに戻って、例えば、サービスフィールド８２は、少なくとも一部の実施形態において、ＶＨＴ−ＡＭＰＤＵ８４を処理するために必要なスクランブラシードを含む。このため、サービスフィールド８２が誤った情報を含んでいれば、ＡＭＰＤＵ８４のサブフレームはいずれも正しく処理することが出来ない。ある実施形態によると、送信側のデバイスは、サービスフィールド８２として検証ビット３０２を含むサービスフィールド３００を利用するので、受信側のデバイスはサービスフィールド３００全体を受信すると即座にスクランブラシードが正しいか否かをチェックすることが出来る。受信側のデバイスは、サービスフィールド３００に含まれているスクランブラシードが誤りであると判断すると、ＡＭＰＤＵ８４を処理しないので、電力等のリソースが節約される。

【0081】

図９Ｂに示す別の実施形態によると、ある実施形態において、サービスフィールド３１０は、第１のＡＭＰＤＵサブフレームのデリミタ３１４内のＣＲＣ指標３１２によってチェックされる。この実施形態では、受信側のデバイスは、サービスフィールド３１０が正しいか否かチェックする前にサービスフィールド３１０に加えてデリミタ３１４を処理する。また、一部の実施形態において、ＣＲＣ指標３１２はさらに、サービスフィールド３１０の前にある他のフィールドまたはサブフィールドが正しいか否かをチェックするためにも用いられる。

【0082】

図９Ｃを参照すると、この実施形態において、サービスフィールド３３０は、第１のＡＭＰＤＵサブフレームのＦＣＳ３３２によってチェックされる。このため、受信側のデバイスはこの場合、サービスフィールド３３０が正しいか否かチェックする前に、サービスフィールド３３０に加えて第１のＡＭＰＤＵサブフレームを処理する。別の実施形態によると、サービスフィールド３３０は、ＡＭＰＤＵフィールド全体のＦＣＳによって保護されている。また、一部の実施形態によると、ＦＣＳ３３２はさらに、サービスフィールド３３０の前の他のフィールドまたはサブフィールドが正しいか否かをチェックするためにも用いられる。

【0083】

別の実施形態によると、ＰＨＹプリアンブルのＶＨＴ−ＳＩＧ部分３４０は、スクランブラシード３４２と、スクランブラシード３４２を含むＶＨＴ−ＳＩＧ部分３４０が正しいか否かを確認するためのＣＲＣビット３４４とを含む。この実施形態によると、ＣＲＣが正しいか否かは、比較的早い段階で検出することができ、エラーを検出すると、受信側のデバイスは通信フレームの残りの部分を処理する必要がなくなる。また、一部の実施形態によると、ＣＲＣビット３４４はさらに、ＶＨＴ−ＳＩＧ部分３４０の前の他のフィールドまたはサブフィールドが正しいか否かをチェックするために用いられる。

【0084】

一部の実施形態によると、図１０Ａに示すように、ＰＨＹサービスデータユニット（ＰＳＤＵ）ヘッダ３５０を生成して、通信フレーム３５４内の、サービスフィールド３５２の後で第１のＡＭＰＤＵサブフレームの前に含める。ＰＳＤＵヘッダ３５０の形式の例を、図１０Ｂに示す。ある実施形態によると、ＰＳＤＵヘッダ３５０は、長さフィールド３６０、ＮＡＶ期間フィールド３６２、宛先デバイスまたは宛先グループの識別子３６４、排他的利用指標３６６、ＭＡＣヘッダ３６８、および、ＣＲＣフィールド３７０を含む。しかし、他の実施形態によると、ＰＳＤＵヘッダは、ＰＳＤＵヘッダ３５０の複数のフィールドのうち一部のみを含む。

【0085】

ＰＳＤＵヘッダ３５０を含む通信フレームを受信するネットワークデバイスは、例えば、ＰＳＤＵ長さフィールド３６０を利用して、有用なデータおよびパッドビットを含む部分の終端を決定する。例えば、ネットワークデバイスは、識別子フィールド３６４に基づいて当該ネットワークデバイスに送信されるデータをＰＳＤＵが全く含まないと判断し、ＣＲＣフィールド３７０を用いてＰＳＤＵヘッダ３５０が正しいか否かを検証し、ＰＳＤＵヘッダ３５０が正しく処理されていると判断したことに応じて、ＰＳＤＵ長さフィールド３６０の値に基づいてスリープ期間（または、ネットワークデバイスが入力データを処理する必要がない期間）を決定する。例えば、ある実施形態によると、ＰＳＤＵ長さフィールド３６０は、通信フレームに含まれる全ＡＭＰＤＵの長さを特定することによって、通信フレームの受信機は、識別子フィールド３６４（および、少なくとも一部の実施形態では、対応するＣＲＣフィールド３７０）を用いてＡＭＰＤＵの期間にわたって受信側がスリープ状態を維持できるか否かを判断することができる。

【0086】

上述した実施形態のうち一部と同様に、ＮＡＶ期間フィールド３６２は、ＮＡＶ期間の長さを特定し、排他的利用指標３６６は、識別子フィールド３６４で特定している１以上のネットワークデバイスに対するデータの送信のみにＮＡＶ期間を利用しているか否かを示す。このため、通信フレームの受信機は、受信フィルタリングを適宜実行することができる。

【0087】

ある実施形態によると、ＣＲＣフィールド３７０は、ＰＳＤＵヘッダ３５０と、ＰＳＤＵヘッダ３５０の直前にあるサービスフィールド３５２とを対象とする。また、ある実施形態によると、サービスフィールド３５２およびＰＳＤＵヘッダ３５０は、比較的低い変調モード（例えば、ＢＰＳＫ）を用いて送信される。別の実施形態によると、ＰＳＤＵヘッダ３５０はさらに、ＰＳＤＵヘッダ３５０の直後に位置する第１のＡＭＰＤＵサブフレームのデリミタとしても機能する。一方、別の実施形態によると、ＰＳＤＵヘッダ３５０は、デリミタおよび特定用途向けＭＰＤＵを含む特別なＡＭＰＤＵサブフレームである。さらに別の実施形態によると、ＰＳＤＵヘッダ３５０は、サービスフィールド３５２の拡張版である。

【0088】

図１１を参照しつつ説明すると、ＭＡＣヘッダ３８０は、検証ビット３８２（例えば、ＣＲＣ、パリティ）を含む。例えば、ある実施形態によると、１以上のＣＲＣビットまたはパリティビットを、ＭＡＣヘッダ３８０の終端に含まれているＨＴ／ＶＨＴ制御フィールドに追加する。ある実施形態によると、ネットワークデバイスは、通信フレームを受信して、検証ビット３８２を用いてＭＡＣヘッダ３８０（宛先アドレスを含む）が正しいか否かを検証する。一部の実施形態によると、検証ビット３８２はさらに、ＭＡＣヘッダ３８０の前にある他のフィールド、例えば、サービスフィールド、ＶＨＴ信号フィールドが正しいか否かを検証するために用いられる。このように、ネットワークは確実に、受信フィルタリングを実現することができる（例えば、ＭＡＣヘッダ３８０の宛先アドレスが別のデバイスを特定していると判断すると、通信フレームの残りの処理を行わない）。

【0089】

続いて、図１２は、上述した方法のうち少なくとも一部を実行して、通信フレームに含める受信フィルタリング情報を生成する送信機４００の一例を示す図である。さまざまな実施形態によると、送信機４００は、図１２に図示した構成要素のうち一部のみを含む。

【0090】

ある実施形態によると、送信機４００は、受信フィルタリング生成モジュール４０１を備える。受信フィルタリング生成モジュール４０１は、ＮＡＶ期間の長さを決定するＮＡＶ期間制御部４０２と、特定のＮＡＶ期間を１以上の通信フレームを送信するために一の特定のネットワークデバイスまたは一の特定可能なネットワークデバイス群（例えば、特定のＧＩＤに対応付けられているもの）にのみ割り当てるべきか否かを判断するべくＮＡＶ期間制御部４０２に結合されている排他的利用指標生成部４０４とを有する。また、ある実施形態によると、受信フィルタリング生成モジュール４０１は、例えば、形式１１０または１２０に応じてストリーム指標フィールドを選択的に生成するストリーム指標フィールド制御部４０６を含む（図４Ａおよび図４Ｂをそれぞれ参照のこと）。

【0091】

さまざまな実施形態によると、受信フィルタリング生成モジュール４０１は、制御フレーム生成部４１２、データフレーム生成部４１４および管理フレーム生成部４１６のうち１以上を含むフレーム生成モジュール４１０に結合されている。したがって、実施形態によっては、ＮＡＶ割り当て情報（例えば、長さ）、排他的利用指標およびストリーム指標フィールドのうち１以上を、制御フレーム、データフレームまたは管理フレームのうち１以上に含める。さらに、ある実施形態によると、フレーム生成モジュール４１０は、特定の通信フレーム（例えば、ＲＴＳ、ＣＴＳ）をラップしてラップされた通信フレームが受信フィルタリング情報を含むようにする制御ラッパフレーム制御部（不図示）を有する。

【0092】

図１２を参照しつつ説明を続けると、ある実施形態において、送信機４００はさらに、ＰＨＹフレーム制御部４２２およびＭＡＣフレーム制御部４２４を含むフレームフォーマッティングモジュール４２０を備える。制御部４２２および４２４は、ＰＨＹ層およびＭＡＣ層に対応付けられているプリアンブル部分、ヘッダ部分およびペイロード部分をそれぞれ生成して、無線通信チャネルを介して送信するべく通信フレーム４３０を生成する。

【0093】

図１に戻って、ある実施形態によると、送信機４００の構成要素のうち少なくとも一部は、受信フィルタリングＴｘ制御部１９に含まれる。例えば、ある実施形態において、受信フィルタリングＴｘ制御部は、受信フィルタリング生成モジュール４０１を含む。別の実施形態によると、受信フィルタリングＴｘ制御部は、受信フィルタリング生成モジュール４０１およびフレーム生成モジュール４１０を含む。また、一部の実施形態によると、ＭＡＣ部１８はさらに、ＭＡＣフレーム制御部４２４、および／または、構成要素４１２−４１６のうち１以上を含む。一部の実施形態によると、ＰＨＹ部２０は、ＰＨＹフレーム制御部４２２を含む。

【0094】

図１３は、適宜、入力される通信フレームを処理して、含まれている受信フィルタリング情報を処理する受信機５００の一例を示す図である。ある実施形態によると、受信機５００は、ＰＨＹプリアンブル処理部５２２、ＰＨＹヘッダ処理部５２４、ＭＡＣヘッダ処理部５２６、ＶＨＴ ＡＭＰＤＵ処理部５２８、および、ＰＳＤＵヘッダ処理部５３０を有する通信フレーム処理部（または、「データユニット処理部」）５１０を備える。また、ある実施形態によると、ＶＨＴ ＡＭＰＤＵ処理部５２８は、ＡＭＰＤＵサブフレーム処理部５３２に結合される。さまざまな実施形態によると、構成要素５２２−５３２は、通信フレームの各部分を処理して、受信フィルタリングに関連する情報を受信フィルタリング処理モジュール５４０に供給する。

【0095】

ある実施形態によると、受信フィルタリング処理モジュール５４０は、例えば、形式１１０または１２０に応じたストリーム指標フィールドを処理するストリーム指標処理部５４２を有する（図４Ａおよび図４Ｂをそれぞれ参照のこと）。受信フィルタリング処理モジュール５４０はさらに、割り当てられたＮＡＶ期間の長さを決定するＮＡＶ期間処理部５４４と、特定のＮＡＶ期間が１以上の通信フレームを送信するために一の特定のネットワークデバイスまたは一の特定可能なネットワークデバイス群（例えば、ある実施形態によると、特定のＧＩＤに対応付けられているもの）にのみ割り当てられているか否かを判断する排他的利用指標処理部５４６とを含む。

【0096】

ある実施形態によると、フィルタリング処理モジュール５４０は、スリープ制御部５５０に結合されている。スリープ制御部５５０は、構成要素５４２−５４６のうち１以上が供給する情報に基づき、受信機５００が入力する通信フレームを監視しなくても安全な期間を決定する。図１に戻って、ある実施形態によると、受信機４００の構成要素のうち少なくとも一部は、受信フィルタリングＲｘ制御部３３に含まれ得る。例えば、ある実施形態によると、受信フィルタリングＲｘ制御部は、受信フィルタリング処理モジュール５４０を含む。別の実施形態によると、受信フィルタリングＲｘ制御部は、受信フィルタリング処理モジュール５４０およびスリープ制御部５５０を含む。さらに、一部の実施形態によると、ＭＡＣ部２８はさらに、１以上の構成要素５２６−５３２を含む。一部の実施形態によると、ＰＨＹ部３９は、構成要素５２２および／または構成要素５２４を含む。

【0097】

一部の実施形態に係る、送信機４００または受信機５００で実現される方法の幾つかの例を、図１４−１７を参照しつつ以下で説明する。

【0098】

図１４は、排他的利用指標を含む通信フレームを生成する方法７００の一例を示すフローチャートである。ブロック７０２において、ＮＡＶ期間（例えば、ＴｘＯＰ、データフレームシーケンス等）の長さを決定する。続いて、ブロック７０４において、ＮＡＶ期間を一の特定のネットワークデバイスまたは一の特定可能なネットワークデバイス群に対する送信にのみ割り当てるべきか否かを判断して、ブロック７０６において、適切な指標（例えば、「排他的利用」、「非排他的利用」）を生成する。ある実施形態によると、方法７００は、送信機４００で少なくとも一部分を実現する（例えば、構成要素４０２および４０４）。

【0099】

図１５を参照すると、許容可能なスリープ期間を決定する方法７３０の一例は、少なくとも一部分が受信機５００で実現される（例えば、構成要素５４４、５４６および５００）。ブロック７３２において、受信した通信フレームでＮＡＶ期間割り当てを検出する。例えば、受信した通信フレームは、図５Ｂに示したＲＴＳフレーム１７０等のＲＴＳフレームとして認識される。ブロック７３４において、割り当てられたＮＡＶ期間の長さフィールドを決定する。この例で説明を続けると、ＲＴＳフレーム１７０の長さフィールド１７６を処理する。続いて、ブロック７３６において、ＰＨＹプリアンブルの別のフィールド、ＰＨＹヘッダ、ＭＡＣヘッダ、または、受信した通信フレーム内の別の箇所をチェックして、ＮＡＶ期間が割り当てられておりデータフレーム等の通信フレームが一の特定の受信機または一の受信機群にのみ送信されるか否かを判断する。上記の例によると、排他的利用指標１７２をチェックする。また、ブロック７３６において、確保されているＮＡＶ期間において通信フレームの送信先である１以上の受信機が方法７３０を実行しているネットワークデバイスを含むか否かを判断する。

【0100】

ＮＡＶ期間が他のデバイスが排他的に利用するために割り当てられていると判断される場合、ブロック７３８において、受信機の少なくとも一部分はスリープ状態となる。他の実施形態によると、ブロック７３８では、受信フィルタリングおよび／または省電力に関する他の判断も行う。ＮＡＶ期間が他のデバイスが排他的に利用するために割り当てられていないと判断される場合、ブロック７４０において、受信機は、関連する可能性がある通信フレームが入力されるか否かを監視する。一般的に、排他的に利用されるように確保されていないＴｘＯＰでは、任意のタイミングでネットワークデバイスに通信フレームを送信することができる。したがって、ネットワークデバイスは、ＴｘＯＰにおいて送信される各フレームの少なくとも一部分を処理するために起きている必要がある。

【0101】

図１６は、通信フレームのフィールドにおいて、受信機が当該通信フレームを正しく処理できなくなる原因であるエラーを高効率且つ高精度で判断することによって、受信フィルタリングを行う方法７６０の一例を示すフローチャートである。ブロック７６２において、通信フレームの「重要」フィールドを検出および処理して、ブロック７６４において、「保護フィールド」と呼ばれる別のフィールドを用いて重要フィールドのインテグリティ（例えば、正しいか否か）を検証する。さまざまな実施形態によると、重要フィールドは、受信フィルタリング（例えば、通信フレームの宛先を決定して、通信フレームの残りを処理する等）に利用され得る情報を含む。例えば、一実施形態によると、重要フィールドは、サービスフィールドのスクランブラシードサブフィールドであり、対応する保護フィールドは、サービスフィールドまたはデリミタ等の他のフィールドに含まれる一連のＣＲＣビットまたはパリティビットである。別の実施形態例によると、例えば、重要フィールドは、ＭＡＣヘッダ内の宛先アドレスであり、対応する保護フィールドは、ＭＡＣヘッダに含まれる一連のＣＲＣビットまたはパリティビットである。さらに別の実施形態によると、重要フィールドは、ＰＳＤＵヘッダのうちＮＡＶ期間割り当て情報、排他的利用指標、部分的または完全なＭＡＣヘッダ情報のうち１以上を含む部分であり、対応する保護フィールドは、ＰＳＤＵヘッダに含まれる一連のＣＲＣビットまたはパリティビットである。

【0102】

ブロック７６６において、保護フィールドを用いて重要フィールドのインテグリティを検証する。重要フィールドの正当性が確認されると、ブロック７６８において、通信フレームの残り部分またはその一部分（例えば、ＶＨＴ−ＡＭＰＤＵ）を処理する。重要フィールドの正当性が確認されない場合、ブロック７７０において、通信フレームの残り部分を省略するので、方法７６０を実行しているネットワークデバイスは電力および／または他のリソースを節約することができる。

【0103】

ある実施形態によると、方法７６０は、ＰＨＹヘッダ処理部５２４、ＭＡＣヘッダ処理部５２６、および、ＰＳＤＵヘッダ処理部５３０のうち１以上によって少なくとも一部分を実行する。

【0104】

図１７は、許容可能なスリープ期間を決定する方法８００の別の例を示すフローチャートである。ブロック８０２において、入力通信フレームのＰＨＹプリアンブルを検出する。ブロック８０４において、ストリーム指標フィールド１１０または１２０内に含まれているＭＵ指標フィールド１１２または１２２等のＭＵ指標を処理する。ある実施形態によると、当該通信フレームの受信機を含まないネットワークデバイス群に当該通信フレームが送信されている、または、当該通信フレームが受信機以外のデバイスに送信されていると判断される場合、受信機は、当該通信フレームの残りを処理しない（ブロック８０６）。しかし、当該通信フレームの受信機を含むネットワークデバイス群に当該通信フレームが送信されている、または、当該通信フレームが特に当該受信機に送信されていると判断される場合、受信機は、当該通信フレームの残り部分を処理する（ブロック８０８）。ある実施形態によると、ブロック８０４における判断は、ＭＵ指標がＭＵモードを特定している場合にはストリーム指標フィールド１１０に含まれているＧＩＤを用いて行われ、または、ＭＵ指標がＳＵモードを特定する場合には指標フィールド１１０に含まれている受信フィルタリング情報を用いて行われる。

【0105】

ある実施形態によると、通信デバイスで実行する方法は、フィールドを含むデータユニットのＰＨＹプリアンブルを受信する段階を備え、フィールドは、（ｉ）データユニットがＭＵ送信に対応付けられているか否かを示す第１のサブフィールドとを含み、第１の形式によると、さらに（ｉｉ）複数の受信デバイスが所属しているグループの識別情報を示す第２のサブフィールドと、（ｉｉｉ）当該グループに対応付けられている複数の受信デバイスのそれぞれに割り当てられているストリーム数を特定する第３のサブフィールドとを含み、当該方法はさらに、第１のサブフィールドに基づいてデータユニットがＭＵ送信に対応付けられているか否かを判断する段階と、データユニットがＭＵ送信に対応付けられていないとの判断結果に応じて、通信デバイスがデータユニットを処理すべきか否かを示す指標をフィールドが含む第２の形式に応じてデータユニットを処理する段階とを備える。第２の形式の実施例のうち１つでは、フィールドが受信デバイスの指標を含むので、通信デバイスは、当該指標が通信デバイスの識別情報に対応している場合にはデータユニットが処理されるべきと判断する。このような一実施形態によると、受信デバイスの指標を通知するために用いられるビットは、第１の形式において第２のサブフィールドおよび第３のサブフィールドの部分のうち少なくとも一部が占めるビットに対応する。さらに、第１の形式の実施例のうち１つでは、第２のサブフィールドは４ビットのフィールドであり、第３のサブフィールドは４つの指標を含み、各指標は、複数の受信デバイスのうち対応する１つについてのストリームを特定している。実施形態例によると、各指標は４ビットフィールドである。

【0106】

別の実施形態によると、通信デバイスで実行する方法は、１以上の受信デバイスに複数の通信フレームを送信するための期間を割り当てる段階と、割り当てられた期間において当該１以上の受信デバイスにのみ情報を送信するように示す指標を生成する段階と、当該指標を、無線通信チャネルを介して送信される通信フレームに含める段階とを備える。

【0107】

さらに別の実施形態によると、通信デバイスで実行する方法は、受信したデータユニットの重要フィールドを処理して、重要フィールドを用いて受信したデータユニットを処理する段階と、受信したデータユニットの検証フィールドを処理して、重要フィールドの正当性を確認する段階と、重要フィールドの正当性が確認されない場合、受信したデータユニットを処理しない段階とを備える。別の実施形態によると、通信デバイスで実行する方法が、受信したデータユニットの重要フィールドを処理して、受信したデータユニットを重要フィールドを用いてフィルタリングする段階と、受信したデータユニットの検証フィールドを処理して、重要フィールドの正当性を確認する段階と、重要フィールドの正当性が確認された場合に、受信したデータユニットを処理する必要があるか否かを判断する段階とを備える。

【0108】

上述したさまざまなブロック、処理および方法のうち少なくとも一部は、ハードウェア、ファームウェア命令を実行するプロセッサ、ソフトウェア命令を実行するプロセッサ、または、これらの任意の組み合わせを用いて実現され得る。

【0109】

ソフトウェア命令またはファームウェア命令を実行しているプロセッサを用いて実行される場合、ソフトウェア命令またはファームウェア命令は、磁気ディスク、光ディスク、または、その他の格納媒体等の任意のコンピュータ可読メモリ、ＲＡＭまたはＲＯＭまたはフラッシュメモリ、プロセッサ、ハードディスクドライブ、光ディスクドライブ、テープドライブ等に格納されるとしてよい。同様に、ソフトウェア命令またはファームウェア命令は、任意の公知または所望の配信方法によって、ユーザまたはシステムに配信されるとしてよい。例えば、コンピュータ可読ディスクまたは他の輸送可能なコンピュータ格納機構に格納して配信するか、または、通信媒体を介して配信されるとしてよい。通信媒体は通常、コンピュータ可読命令、データ構造、プログラムモジュールまたはその他のデータを、搬送波またはその他の輸送機構等の変調データ信号で具現化したものである。「変調データ信号」という用語は、特性のうち１以上を信号に情報を符号化するように設定または変更された信号を意味する。通信媒体は、一例として挙げると、これらに限定されないが、有線ネットワークまたは直接有線接続等の有線媒体、および、音波、無線周波数、赤外線等の無線媒体を含む。このように、ソフトウェア命令またはファームウェア命令は、電話線、ＤＳＬライン、ケーブルテレビライン、光ファイバライン、無線通信チャネル、インターネット等の通信チャネルを介してユーザまたはシステムに配信されるとしてよい。（上記の通信チャネルの例は、輸送可能な格納媒体によってソフトウェアを提供することと同じ、または、置き換え可能であると見なされる）。ソフトウェア命令またはファームウェア命令は、プロセッサによって実行されると、当該プロセッサにさまざまな処理を実行させる機械可読命令を含むとしてよい。

【0110】

ハードウェアで実現される場合、ハードウェアは、ディスクリート素子、集積回路、ＡＳＩＣ、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）等のうち１以上を備えるとしてよい。

【0111】

数多くのさまざまな実施形態を詳細に上述してきたが、本特許の範囲は請求項に記載した文言によって定義されるものと理解されたい。詳細な説明は、例示に過ぎないと解釈されるべきであり、不可能でなければ現実的でないといえるので、実施可能な実施形態を全て網羅して説明したものではない。現在の技術水準または本開示の出願日以降に開発される技術を用いて、数多くの代替実施形態を実行することが可能である。これらの代替案も請求項の範囲に含まれるものである。

【図1】

【図2A】

【図2B】

【図2C】

【図3】

【図4A】

【図4B】

【図4C】

【図5A】

【図5B】

【図6】

【図7A】

【図7B】

【図8A】

【図8B】

【図9A】

【図9B】

【図9C】

【図9D】

【図10A】

【図10B】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】