JP2018516018A - 無線ｌａｎシステムにおいてｎａｖを管理する方法及びそのための装置 - Google Patents

Abstract

本発明の一実施例によってＨＥ ＰＰＤＵ（ｈｉｇｈ ｅｆｆｉｃｉｅｎｃｙ ｐｈｙｓｉｃａｌ ｌａｙｅｒ ｐｒｏｔｏｃｏｌ ｄａｔａ ｕｎｉｔ）を支援する無線ＬＡＮシステムにおいてステーション（ＳＴＡ）がＮＡＶ（ｎｅｔｗｏｒｋ ａｌｌｏｃａｔｉｏｎ ｖｅｃｔｏｒ）を管理する方法は、区間（ｄｕｒａｔｉｏｎ）情報を含むフレームを受信するステップと、上記ＳＴＡが有する複数のＮＡＶの中から所定のＮＡＶを選択するステップと、上記フレームの区間情報に基づいて上記所定のＮＡＶを管理するステップとを含み、上記所定のＮＡＶは、上記フレームが上記ＳＴＡの属するＢＳＳ（ｂａｓｉｃ ｓｅｒｖｉｃｅ ｓｅｔ）から受信されたか否かに基づいて選択され得る。【選択図】 図３６

Description

本発明は、無線ＬＡＮシステムにおいてＮＡＶ（ｎｅｔｗｏｒｋ ａｌｌｏｃａｔｉｏｎ ｖｅｃｔｏｒ）を管理する方法及び装置に関し、特に、受信されたフレームに基づいてＮＡＶを管理する方法及びそのための装置に関する。

無線ＬＡＮ技術に対する標準がＩＥＥＥ（Ｉｎｓｔｉｔｕｔｅ ｏｆ Ｅｌｅｃｔｒｉｃａｌ ａｎｄ Ｅｌｅｃｔｒｏｎｉｃｓ Ｅｎｇｉｎｅｅｒｓ） ８０２．１１標準として開発されている。ＩＥＥＥ ８０２．１１ａ及びｂは２．４．ＧＨｚ又は５ＧＨｚで無免許帯域（ｕｎｌｉｃｅｎｓｅｄ ｂａｎｄ）を利用し、ＩＥＥＥ ８０２．１１ｂは１１Ｍｂｐｓの伝送速度を提供し、ＩＥＥＥ ８０２．１１ａは５４Ｍｂｐｓの伝送速度を提供する。ＩＥＥＥ ８０２．１１ｇは２．４ＧＨｚで直交周波数分割多重化（Ｏｒｔｈｏｇｏｎａｌ ｆｒｅｑｕｅｎｃｙ−ｄｉｖｉｓｉｏｎ ｍｕｌｔｉｐｌｅｘｉｎｇ；ＯＦＤＭ）を適用して、５４Ｍｂｐｓの伝送速度を提供する。ＩＥＥＥ ８０２．１１ｎは多重入出力ＯＦＤＭ（ｍｕｌｔｉｐｌｅ ｉｎｐｕｔ ｍｕｌｔｉｐｌｅ ｏｕｔｐｕｔ−ＯＦＤＭ；ＭＩＭＯ−ＯＦＤＭ）を適用して、４個の空間的なストリーム（ｓｐａｔｉａｌ ｓｔｒｅａｍ）に対して３００Ｍｂｐｓの伝送速度を提供する。ＩＥＥＥ ８０２．１１ｎではチャネル帯域幅（ｃｈａｎｎｅｌ ｂａｎｄｗｉｄｔｈ）を４０ＭＨｚまで支援し、この場合には６００Ｍｂｐｓの伝送速度を提供する。

上述した無線ＬＡＮ標準は、最大で１６０ＭＨｚ帯域幅を使用し、８個の空間ストリームを支援して最大で１Ｇｂｉｔ／ｓの速度を支援するＩＥＥＥ ８０２．１１ａｃ標準を経て、ＩＥＥＥ ８０２．１１ａｘ標準化に関して議論されている。

本発明が遂げようとする技術的課題は、ＨＥ ＰＰＤＵを支援する無線ＬＡＮシステムにおいてフレームを送信したＢＳＳを考慮してＮＡＶを管理する方法及び装置を提供することにある。

本発明は上述の技術的課題に限定されず、他の技術的課題を本発明の実施例から類推することができる。

上述した技術的課題を達成するための本発明の一側面に係る、ＨＥ ＰＰＤＵ（ｈｉｇｈ ｅｆｆｉｃｉｅｎｃｙ ｐｈｙｓｉｃａｌ ｌａｙｅｒ ｐｒｏｔｏｃｏｌ ｄａｔａ ｕｎｉｔ）を支援する無線ＬＡＮシステムにおいてステーション（ＳＴＡ）がＮＡＶ（ｎｅｔｗｏｒｋ ａｌｌｏｃａｔｉｏｎ ｖｅｃｔｏｒ）を管理する方法は、区間（ｄｕｒａｔｉｏｎ）情報を含むフレームを受信するステップと、上記ＳＴＡが有する複数のＮＡＶの中から所定のＮＡＶを選択するステップと、上記フレームの区間情報に基づいて上記所定のＮＡＶを管理するステップとを含み、上記所定のＮＡＶは、上記フレームが上記ＳＴＡの属するＢＳＳ（ｂａｓｉｃ ｓｅｒｖｉｃｅ ｓｅｔ）から受信されたか否かに基づいて選択され得る。

上述した技術的課題を達成するための本発明の他の側面に係る、ＨＥ ＰＰＤＵ（ｈｉｇｈ ｅｆｆｉｃｉｅｎｃｙ ｐｈｙｓｉｃａｌ ｌａｙｅｒ ｐｒｏｔｏｃｏｌ ｄａｔａ ｕｎｉｔ）を支援する無線ＬＡＮシステムにおいてＮＡＶ（ｎｅｔｗｏｒｋ ａｌｌｏｃａｔｉｏｎ ｖｅｃｔｏｒ）を管理するステーション（ＳＴＡ）は、区間（ｄｕｒａｔｉｏｎ）情報を含むフレームを受信する受信器と、上記ＳＴＡが有する複数のＮＡＶの中から所定のＮＡＶを選択し、上記フレームの区間情報に基づいて上記所定のＮＡＶを管理するプロセッサとを備え、上記所定のＮＡＶは、上記フレームが上記ＳＴＡの属するＢＳＳ（ｂａｓｉｃ ｓｅｒｖｉｃｅ ｓｅｔ）から受信されたか否かに基づいて選択され得る。

好ましくは、上記ＳＴＡは、上記フレームが上記ＳＴＡの属したＢＳＳから受信されたと決定されると、第１ＮＡＶを選択し、上記フレームが上記ＳＴＡの属しないＢＳＳから受信されたと決定されると、第２ＮＡＶを選択することができる。より好ましくは、上記ＳＴＡは、上記フレームがいずれのＢＳＳから受信されたものかを決定不可能な場合、上記第２ＮＡＶを選択することができる。

好ましくは、上記複数のＮＡＶは、イントラＢＳＳ ＮＡＶ及び非−イントラＢＳＳ ＮＡＶを含み、上記非−イントラＢＳＳ ＮＡＶは、ＯＢＳＳ（ｏｔｈｅｒ ＢＳＳ）フレームのためのものであってもよい。より好ましくは、上記非−イントラＢＳＳ ＮＡＶは、ＢＳＳを特定不可能なフレームのためのものであってもよい。より好ましくは、上記ＢＳＳを特定不可能なフレームは、ＡＣＫ（ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ）フレームであるか、又はＣＴＳ（ｃｌｅａｒ−ｔｏ−ｓｅｎｄ）フレームであってもよい。

好ましくは、上記複数のＮＡＶのいずれか一つでも０より大きい値を有する場合、上記ＳＴＡはチャネルアクセスを保留することができる。

好ましくは、上記ＳＴＡは、上記複数のＮＡＶに対応する複数のＮＡＶタイマーを設定することができる。

好ましくは、上記複数のＮＡＶは、上記複数のＮＡＶ間の差値と１つのＮＡＶタイマーによって管理されてもよい。

より好ましくは、上記１つのＮＡＶタイマーの値が上記複数のＮＡＶのうち、第１ＮＡＶから第２ＮＡＶに変更される場合、上記複数のＮＡＶ間の差値がアップデートされてもよい。

より好ましくは、上記ＳＴＡは、上記複数のＮＡＶ間の差値及び上記１つのＮＡＶタイマーにマップされた第１ＮＡＶの現在値を用いて第２ＮＡＶの有効性を判断することができる。

本発明の一実施例によれば、ＨＥ ＰＰＤＵを支援する無線ＬＡＮシステムにおいてＳＴＡは複数のＮＡＶを管理する際にフレームを送信したＢＳＳを考慮するので、ＮＡＶを正確に且つ効率的に管理することができる。

上述した技術的効果以外の技術的効果も本発明の実施例から類推することができる。

無線ＬＡＮシステムの構成の一例を示す図である。 無線ＬＡＮシステムの構成の他の例を示す図である。 一般のリンクセットアップ（ｌｉｎｋ ｓｅｔｕｐ）過程を説明するための図である。 バックオフ過程を説明するための図である。 隠れノード及びさらしノードに関して説明するための図である。 ＲＴＳとＣＴＳを説明するための図である。 ＴＩＭを受信したＳＴＡの動作を説明するための図である。 ＴＩＭを受信したＳＴＡの動作を説明するための図である。 ＴＩＭを受信したＳＴＡの動作を説明するための図である。 ＩＥＥＥ ８０２．１１システムにおいて用いられるフレーム構造の一例を説明するための図である。 ＣＦ（ｃｏｎｔｅｎｔｉｏｎ ｆｒｅｅ）−ＥＮＤフレームを例示する図である。 ＨＥ ＰＰＤＵの一例を示す図である。 ＨＥ ＰＰＤＵの他の例を示す図である。 ＨＥ ＰＰＤＵの更に他の例を示す図である。 ＨＥ ＰＰＤＵの更に他の例を示す図である。 ＨＥ ＰＰＤＵの更に他の例を示す図である。 ＨＥ−ＳＩＧ Ｂに対するパディング方案を説明する。 ＨＥ−ＳＩＧ Ｂに対するパディング方案を説明する。 本発明の一実施例に係る上りリンク多重ユーザ伝送状況を説明するための図である。 本発明の一実施例に係るトリガーフレームフォーマットを示す図である。 ＮＡＶ設定（ｓｅｔｔｉｎｇ）の一例を示す図である。 ＴＸＯＰ ｔｒｕｎｃａｔｉｏｎの一例を示す図である。 既存ＮＡＶ管理方法に伴う問題点を例示する図である。 ＵＬ ＭＵ伝送に関連した既存のＮＡＶ管理を例示する図である。 本発明の一実施例に係るＮＡＶ管理を例示する図である。 本発明の他の実施例に係るＮＡＶ管理を例示する図である。 本発明の一実施例に係るＮＡＶ差値のアップデートを例示する図である。 本発明の他の実施例に係るＮＡＶ差値アップデートを例示する図である。 本発明の更に他の実施例に係るＮＡＶ管理を例示する図である。 本発明の更に他の実施例に係るＮＡＶ管理を例示する図である。 イントラＢＳＳフレームによるＴＸＯＰ ｔｒｕｎｃａｔｉｏｎを例示する図である。 本発明の更に他の実施例に係るＮＡＶ管理を例示する図である。 本発明の一実施例に係るＮＡＶ差値を例示する図である。 本発明の更に他の実施例に係るＮＡＶ管理を例示する図である。 本発明の一実施例に係る２個のＮＡＶタイマーを例示する図である。 本発明の一実施例に係るＮＡＶ管理方法の流れを例示する図である。 本発明の一実施例に係る装置を説明するための図である。

以下、本発明に係る好適な実施の形態を添付の図面を参照して詳しく説明する。添付の図面と共に以下に開示される詳細な説明は、本発明の例示的な実施の形態を説明するためのもので、本発明の唯一の実施の形態を示すためのものではない。

以下の詳細な説明は本発明の完全な理解を提供するために具体的な細部事項を含む。しかし、このような具体的な細部事項なしにも本発明が実施され得るということが当業者には理解される。場合によって、本発明の概念が曖昧になることを避けるために、公知の構造及び装置は省略されたり、各構造及び装置の核心機能を中心にしたブロック図の形式で図示されることもある。

上述したように、以下の説明は、無線LANシステムで広い帯域を持つチャネルを効率的に活用するための方法及びそのための装置のことである。このため、まず、本発明が適用される無線LANシステムについて具体的に説明する。

図１は、無線ＬＡＮシステムの構成の一例を示す図である。

図１に示すように、無線ＬＡＮシステムは、一つ以上の基本サービスセット（Ｂａｓｉｃ Ｓｅｒｖｉｃｅ Ｓｅｔ；ＢＳＳ）を含む。ＢＳＳは、成功的に同期を取って互いに通信できるステーション（Ｓｔａｔｉｏｎ；ＳＴＡ）の集合である。

ＳＴＡは、媒体接続制御（Ｍｅｄｉｕｍ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ；ＭＡＣ）と無線媒体に対する物理層（Ｐｈｙｓｉｃａｌ Ｌａｙｅｒ）インターフェースを含む論理個体であり、アクセスポイント（ａｃｃｅｓｓ ｐｏｉｎｔ；ＡＰ）と非ＡＰ ＳＴＡ（Ｎｏｎ−ＡＰ Ｓｔａｔｉｏｎ）を含む。ＳＴＡのうち、ユーザの操作する携帯用端末はＮｏｎ−ＡＰ ＳＴＡであり、単にＳＴＡというときは、Ｎｏｎ−ＡＰ ＳＴＡを指すこともある。Ｎｏｎ−ＡＰ ＳＴＡは、端末（ｔｅｒｍｉｎａｌ）、無線送受信ユニット（Ｗｉｒｅｌｅｓｓ Ｔｒａｎｓｍｉｔ／Ｒｅｃｅｉｖｅ Ｕｎｉｔ；ＷＴＲＵ）、ユーザ装備（Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔ；ＵＥ）、移動局（Ｍｏｂｉｌｅ Ｓｔａｔｉｏｎ；ＭＳ）、携帯用端末（Ｍｏｂｉｌｅ Ｔｅｒｍｉｎａｌ）、又は移動加入者ユニット（Ｍｏｂｉｌｅ Ｓｕｂｓｃｒｉｂｅｒ Ｕｎｉｔ）などの他の名称としてもよい。

そして、ＡＰは自身に結合されたＳＴＡ（Ａｓｓｏｃｉａｔｅｄ Ｓｔａｔｉｏｎ）に無線媒体を介して分配システム（Ｄｉｓｔｒｉｂｕｔｉｏｎ Ｓｙｓｔｅｍ；ＤＳ）への接続を提供する個体である。ＡＰは、集中制御機、基地局（Ｂａｓｅ Ｓｔａｔｉｏｎ；ＢＳ）、Ｎｏｄｅ−Ｂ、ＢＴＳ（Ｂａｓｅ Ｔｒａｎｓｃｅｉｖｅｒ Ｓｙｓｔｅｍ）、又はサイト制御機などと呼ぶこともできる。

ＢＳＳは、インフラストラクチャー（ｉｎｆｒａｓｔｒｕｃｔｕｒｅ）ＢＳＳと、独立した（Ｉｎｄｅｐｅｎｄｅｎｔ）ＢＳＳ（ＩＢＳＳ）とに区別することができる。

図１に示すＢＢＳは、ＩＢＳＳである。ＩＢＳＳはＡＰを含まないＢＳＳを意味し、ＡＰを含まないことから、ＤＳへの接続が許容されず、自己完備的ネットワーク（ｓｅｌｆ−ｃｏｎｔａｉｎｅｄ ｎｅｔｗｏｒｋ）をなす。

図２は、無線ＬＡＮシステムの構成の他の例を示す図である。

図２に示すＢＳＳは、インフラストラクチャーＢＳＳである。インフラストラクチャーＢＳＳは一つ以上のＳＴＡ及びＡＰを含む。インフラストラクチャーＢＳＳにおいて非ＡＰ ＳＴＡ同士の通信はＡＰを経由してなされることが原則であるが、非ＡＰ ＳＴＡの間に直接リンク（ｌｉｎｋ）が設定された場合には、非ＡＰ ＳＴＡ同士で直接通信も可能である。

図２に示すように、複数のインフラストラクチャーＢＳＳは、ＤＳを介して相互接続することができる。ＤＳを介して接続された複数のＢＳＳを拡張サービスセット（Ｅｘｔｅｎｄｅｄ Ｓｅｒｖｉｃｅ Ｓｅｔ；ＥＳＳ）という。ＥＳＳに含まれるＳＴＡは互いに通信することができ、同じＥＳＳ内で非ＡＰ ＳＴＡはシームレスに通信しながら一つのＢＳＳから他のＢＳＳに移動することができる。

ＤＳは、複数のＡＰを接続させるメカニズム（ｍｅｃｈａｎｉｓｍ）であり、必ずしもネットワークである必要はなく、所定の分配サービスを提供可能なものであればその形態には何ら制限がない。例えば、ＤＳは、メッシュ（ｍｅｓｈ）ネットワークのような無線ネットワークであってもよく、ＡＰを互いに接続させる物理的な構造物であってもよい。

層構造

無線ＬＡＮシステムにおいて動作するＳＴＡの動作を層（ｌａｙｅｒ）構造の観点で説明することができる。装置構成の側面において層構造は、プロセッサによって具現することができる。ＳＴＡは複数個の層構造を有することができる。例えば、８０２．１１標準文書で扱う層構造は、主に、ＤＬＬ（Ｄａｔａ Ｌｉｎｋ Ｌａｙｅｒ）上のＭＡＣサブ層（ｓｕｂｌａｙｅｒ）及び物理（ＰＨＹ）層である。ＰＨＹは、ＰＬＣＰ（Ｐｈｙｓｉｃａｌ Ｌａｙｅｒ Ｃｏｎｖｅｒｇｅｎｃｅ Ｐｒｏｃｅｄｕｒｅ）個体、ＰＭＤ（Ｐｈｙｓｉｃａｌ Ｍｅｄｉｕｍ Ｄｅｐｅｎｄｅｎｔ）個体などを含むことができる。ＭＡＣサブ層及びＰＨＹはそれぞれ、ＭＬＭＥ（ＭＡＣ ｓｕｂｌａｙｅｒ Ｍａｎａｇｅｍｅｎｔ Ｅｎｔｉｔｙ）及びＰＬＭＥ（（Ｐｈｙｓｉｃａｌ Ｌａｙｅｒ Ｍａｎａｇｅｍｅｎｔ Ｅｎｔｉｔｙ）と呼ばれる管理個体を概念的に含む。これらの個体は、層管理機能が作動する層管理サービスインターフェースを提供する。

正確なＭＡＣ動作を提供するために、ＳＭＥ（Ｓｔａｔｉｏｎ Ｍａｎａｇｅｍｅｎｔ Ｅｎｔｉｔｙ）が各ＳＴＡ内に存在する。ＳＭＥは、別の管理プレーン内に存在したり又は別個として離れている（ｏｆｆ ｔｏ ｔｈｅ ｓｉｄｅ）ように見えうる、層と独立した個体である。ＳＭＥの正確な機能は、本文では具体的に説明しないが、一般的には、様々な層管理個体（ＬＭＥ）から層−従属的な状態を収集し、層−特定パラメータの値を類似に設定するなどの機能を担当するものといえる。ＳＭＥは、一般に、このような機能を一般システム管理個体を代表して（ｏｎ ｂｅｈａｌｆ ｏｆ）行い、標準管理プロトコルを具現することができる。

前述した個体は様々な方式で相互作用する。例えば、個体同士はＧＥＴ／ＳＥＴプリミティブ（ｐｒｉｍｉｔｉｖｅ）を交換（ｅｘｃｈａｎｇｅ）することによって相互作用することができる。プリミティブは、特定目的に関連した要素（ｅｌｅｍｅｎｔ）やパラメータのセットを意味する。ＸＸ−ＧＥＴ．ｒｅｑｕｅｓｔプリミティブは、与えられたＭＩＢ ａｔｔｒｉｂｕｔｅ（管理情報基盤属性情報）の値を要求するために用いられる。ＸＸ−ＧＥＴ．ｃｏｎｆｉｒｍプリミティブは、Ｓｔａｔｕｓが“成功”である場合には適切なＭＩＢ属性情報値をリターンし、そうでないと、Ｓｔａｔｕｓフィールドにおいてエラー指示をリターンするために用いられる。ＸＸ−ＳＥＴ．ｒｅｑｕｅｓｔプリミティブは、指示されたＭＩＢ属性が与えられた値に設定されるように要求するために用いられる。上記ＭＩＢ属性が特定動作を意味する場合、これは当該動作が行われることを要求するものである。そして、ＸＸ−ＳＥＴ．ｃｏｎｆｉｒｍプリミティブは、ｓｔａｔｕｓが“成功”である場合に指示されたＭＩＢ属性が、要求された値に設定されたと確認してくれ、そうでないと、ｓｔａｔｕｓフィールドにエラー条件をリターンするために用いられる。ＭＩＢ属性が特定動作を意味する場合、これは当該動作が行われたと確認してくれる。

また、ＭＬＭＥ及びＳＭＥは、様々なＭＬＭＥ＿ＧＥＴ／ＳＥＴプリミティブをＭＬＭＥ＿ＳＡＰ（Ｓｅｒｖｉｃｅ Ａｃｃｅｓｓ Ｐｏｉｎｔ）を介して交換することができる。また、様々なＰＬＭＥ＿ＧＥＴ／ＳＥＴプリミティブが、ＰＬＭＥ＿ＳＡＰを介してＰＬＭＥとＳＭＥとの間で交換されてもよく、ＭＬＭＥ−ＰＬＭＥ＿ＳＡＰを介してＭＬＭＥとＰＬＭＥとの間で交換されてもよい。

リンクセットアップ過程

図３は、一般のリンクセットアップ（ｌｉｎｋ ｓｅｔｕｐ）過程を説明するための図である。

ＳＴＡがネットワークに対してリンクをセットアップし、データを送受信するためには、まず、ネットワークを発見（ｄｉｓｃｏｖｅｒｙ）し、認証（ａｕｔｈｅｎｔｉｃａｔｉｏｎ）を行い、連携（ａｓｓｏｃｉａｔｉｏｎ）を確立（ｅｓｔａｂｌｉｓｈ）し、保安（ｓｅｃｕｒｉｔｙ）のための認証手順などを行わなければならない。リンクセットアップ過程をセッション開始過程、セッションセットアップ過程と呼ぶこともできる。また、リンクセットアップ過程における発見、認証、連携、保安設定の過程を総称して連携過程と呼ぶこともできる。

図３を参照して例示的なリンクセットアップ過程について説明する。

段階Ｓ５１０で、ＳＴＡはネットワーク発見動作を行うことができる。ネットワーク発見動作はＳＴＡのスキャニング（ｓｃａｎｎｉｎｇ）動作を含むことができる。すなわち、ＳＴＡがネットワークにアクセスするためには、参加可能なネットワークを探さなければならない。ＳＴＡは無線ネットワークに参加する前に互換可能なネットワークを識別しなければならないが、特定領域に存在するネットワーク識別過程をスキャニングという。

スキャニング方式には、能動的スキャニング（ａｃｔｉｖｅ ｓｃａｎｎｉｎｇ）と受動的スキャニング（ｐａｓｓｉｖｅ ｓｃａｎｎｉｎｇ）がある。

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

図３には示していないが、スキャニング動作は受動的スキャニング方式で行われてもよい。受動的スキャニングにおいて、スキャニングを行うＳＴＡはチャネルを移りながらビーコンフレームを待つ。ビーコンフレームは、ＩＥＥＥ ８０２．１１において管理フレーム（ｍａｎａｇｅｍｅｎｔ ｆｒａｍｅ）の一つであり、無線ネットワークの存在を知らせ、スキャニングを行うＳＴＡが無線ネットワークを探して無線ネットワークに参加できるように、周期的に送信される。ＢＳＳでＡＰがビーコンフレームを周期的に送信する役割を担い、ＩＢＳＳではＩＢＳＳ内のＳＴＡが交互にビーコンフレームを送信する。スキャニングを行うＳＴＡはビーコンフレームを受信すると、ビーコンフレームに含まれたＢＳＳに関する情報を保存し、他のチャネルに移動しながら各チャネルでビーコンフレーム情報を記録する。ビーコンフレームを受信したＳＴＡは、受信したビーコンフレームに含まれたＢＳＳ関連情報を保存し、次のチャネルに移動して同一の方法で次のチャネルでスキャニングを行うことができる。

能動的スキャニングと受動的スキャニングとを比較すれば、能動的スキャニングが受動的スキャニングに比べてディレー（ｄｅｌａｙ）及び電力消耗が小さいという利点がある。

ＳＴＡがネットワークを発見した後に、段階Ｓ５２０で認証過程を行うことができる。このような認証過程は、後述する段階Ｓ５４０の保安セットアップ動作と明確に区別するために、第１の認証（ｆｉｒｓｔ ａｕｔｈｅｎｔｉｃａｔｉｏｎ）過程と呼ぶことができる。

認証過程は、ＳＴＡが認証要請フレーム（ａｕｔｈｅｎｔｉｃａｔｉｏｎ ｒｅｑｕｅｓｔ ｆｒａｍｅ）をＡＰに送信し、これに応答してＡＰが認証応答フレーム（ａｕｔｈｅｎｔｉｃａｔｉｏｎ ｒｅｓｐｏｎｓｅ ｆｒａｍｅ）をＳＴＡに送信する過程を含む。認証要請／応答に用いられる認証フレーム（ａｕｔｈｅｎｔｉｃａｔｉｏｎ ｆｒａｍｅ）は管理フレームに該当する。

認証フレームは、認証アルゴリズム番号（ａｕｔｈｅｎｔｉｃａｔｉｏｎ ａｌｇｏｒｉｔｈｍ ｎｕｍｂｅｒ）、認証トランザクションシーケンス番号（ａｕｔｈｅｎｔｉｃａｔｉｏｎ ｔｒａｎｓａｃｔｉｏｎ ｓｅｑｕｅｎｃｅ ｎｕｍｂｅｒ）、状態コード（ｓｔａｔｕｓ ｃｏｄｅ）、検問テキスト（ｃｈａｌｌｅｎｇｅ ｔｅｘｔ）、ＲＳＮ（Ｒｏｂｕｓｔ Ｓｅｃｕｒｉｔｙ Ｎｅｔｗｏｒｋ）、有限循環グループ（Ｆｉｎｉｔｅ Ｃｙｃｌｉｃ Ｇｒｏｕｐ）などに関する情報を含むことができる。これは、認証要請／応答フレームに含まれ得る情報の一例示に過ぎず、他の情報に置き換わったり、追加の情報がさらに含まれたりしてもよい。

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

ＳＴＡが成功的に認証された後に、段階Ｓ５３０で連携過程を行うことができる。連携過程は、ＳＴＡが連携要請フレーム（ａｓｓｏｃｉａｔｉｏｎ ｒｅｑｕｅｓｔ ｆｒａｍｅ）をＡＰに送信し、それに応答してＡＰが連携応答フレーム（ａｓｓｏｃｉａｔｉｏｎ ｒｅｓｐｏｎｓｅ ｆｒａｍｅ）をＳＴＡに送信する過程を含む。

例えば、連携要請フレームは、様々な能力（ｃａｐａｂｉｌｉｔｙ）に関する情報、ビーコン聴取間隔（ｌｉｓｔｅｎ ｉｎｔｅｒｖａｌ）、ＳＳＩＤ（ｓｅｒｖｉｃｅ ｓｅｔ ｉｄｅｎｔｉｆｉｅｒ）、支援レート（ｓｕｐｐｏｒｔｅｄ ｒａｔｅｓ）、支援チャネル（ｓｕｐｐｏｒｔｅｄ ｃｈａｎｎｅｌｓ）、ＲＳＮ、移動性ドメイン、支援オペレーティングクラス（ｓｕｐｐｏｒｔｅｄ ｏｐｅｒａｔｉｎｇ ｃｌａｓｓｅｓ）、ＴＩＭ放送要請（Ｔｒａｆｆｉｃ Ｉｎｄｉｃａｔｉｏｎ Ｍａｐ Ｂｒｏａｄｃａｓｔ ｒｅｑｕｅｓｔ）、相互動作（ｉｎｔｅｒｗｏｒｋｉｎｇ）サービス能力などに関する情報を含むことができる。

例えば、連携応答フレームは、様々な能力に関する情報、状態コード、ＡＩＤ（Ａｓｓｏｃｉａｔｉｏｎ ＩＤ）、支援レート、ＥＤＣＡ（Ｅｎｈａｎｃｅｄ Ｄｉｓｔｒｉｂｕｔｅｄ Ｃｈａｎｎｅｌ Ａｃｃｅｓｓ）パラメータセット、ＲＣＰＩ（Ｒｅｃｅｉｖｅｄ Ｃｈａｎｎｅｌ Ｐｏｗｅｒ Ｉｎｄｉｃａｔｏｒ）、ＲＳＮＩ（Ｒｅｃｅｉｖｅｄ Ｓｉｇｎａｌ ｔｏ Ｎｏｉｓｅ Ｉｎｄｉｃａｔｏｒ）、移動性ドメイン、タイムアウト間隔（連携カムバック時間（ａｓｓｏｃｉａｔｉｏｎ ｃｏｍｅｂａｃｋ ｔｉｍｅ））、重畳（ｏｖｅｒｌａｐｐｉｎｇ）ＢＳＳスキャンパラメータ、ＴＩＭ放送応答、ＱｏＳマップなどの情報を含むことができる。

これは連携要請／応答フレームに含まれ得る情報の一例に過ぎず、他の情報に置き換わったり、追加の情報がさらに含まれたりしてもよい。

ＳＴＡがネットワークに成功的に連携された後に、段階Ｓ５４０で保安セットアップ過程を行うことができる。段階Ｓ５４０の保安セットアップ過程は、ＲＳＮＡ（Ｒｏｂｕｓｔ Ｓｅｃｕｒｉｔｙ Ｎｅｔｗｏｒｋ Ａｓｓｏｃｉａｔｉｏｎ）要請／応答を通じた認証過程ということもでき、上記の段階Ｓ５２０の認証過程を第１の認証（ｆｉｒｓｔ ａｕｔｈｅｎｔｉｃａｔｉｏｎ）過程とし、段階Ｓ５４０の保安セットアップ過程を単純に認証過程と呼ぶこともできる。

段階Ｓ５４０の保安セットアップ過程は、例えば、ＥＡＰＯＬ（Ｅｘｔｅｎｓｉｂｌｅ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｐｒｏｔｏｃｏｌ ｏｖｅｒ ＬＡＮ）フレームを通じた４−ウェイ（ｗａｙ）ハンドシェーキングを通じて、プライベートキーセットアップ（ｐｒｉｖａｔｅ ｋｅｙ ｓｅｔｕｐ）をする過程を含むことができる。また、保安セットアップ過程は、ＩＥＥＥ ８０２．１１標準で定義しない保安方式によって行われてもよい。

媒体アクセスメカニズム

ＩＥＥＥ ８０２．１１に基づく無線ＬＡＮシステムにおいて、ＭＡＣ（Ｍｅｄｉｕｍ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ）の基本アクセスメカニズムは、ＣＳＭＡ／ＣＡ（Ｃａｒｒｉｅｒ Ｓｅｎｓｅ Ｍｕｌｔｉｐｌｅ Ａｃｃｅｓｓ ｗｉｔｈ Ｃｏｌｌｉｓｉｏｎ Ａｖｏｉｄａｎｃｅ）メカニズムである。ＣＳＭＡ／ＣＡメカニズムは、ＩＥＥＥ ８０２．１１ ＭＡＣの分配調整機能（Ｄｉｓｔｒｉｂｕｔｅｄ Ｃｏｏｒｄｉｎａｔｉｏｎ Ｆｕｎｃｔｉｏｎ、ＤＣＦ）とも呼ばれるが、基本的に「ｌｉｓｔｅｎ ｂｅｆｏｒｅ ｔａｌｋ」アクセスメカニズムを採用している。このような類型のアクセスメカニズムによれば、ＡＰ及び／又はＳＴＡは送信を開始するに先立ち、所定の時間区間（例えば、ＤＩＦＳ（ＤＣＦ Ｉｎｔｅｒ−Ｆｒａｍｅ Ｓｐａｃｅ）の間に無線チャネル又は媒体（ｍｅｄｉｕｍ）をセンシング（ｓｅｎｓｉｎｇ）するＣＣＡ（Ｃｌｅａｒ Ｃｈａｎｎｅｌ Ａｓｓｅｓｓｍｅｎｔ）を行うことができる。センシングの結果、媒体が遊休状態（ｉｄｌｅ ｓｔａｔｕｓ）と判断されると、当該媒体を通じてフレーム送信を始める。一方、媒体が占有状態（ｏｃｃｕｐｉｅｄ ｓｔａｔｕｓ）と感知されると、当該ＡＰ及び／又はＳＴＡは自身の送信を開始せず、媒体アクセスのための遅延期間（例えば、任意バックオフ周期（ｒａｎｄｏｍ ｂａｃｋｏｆｆ ｐｅｒｉｏｄ））を設定して待った後、フレーム送信を試みることができる。任意バックオフ周期の適用から、複数のＳＴＡはそれぞれ異なった時間待った後にフレーム送信を試みることが期待されるため、衝突（ｃｏｌｌｉｓｉｏｎ）を最小化することができる。

また、ＩＥＥＥ ８０２．１１ ＭＡＣプロトコルはＨＣＦ（Ｈｙｂｒｉｄ Ｃｏｏｒｄｉｎａｔｉｏｎ Ｆｕｎｃｔｉｏｎ）を提供する。ＨＣＦはＤＣＦとＰＣＦ（Ｐｏｉｎｔ Ｃｏｏｒｄｉｎａｔｉｏｎ Ｆｕｎｃｔｉｏｎ）に基づく。ＰＣＦは、ポーリング（ｐｏｌｌｉｎｇ）ベースの同期式アクセス方式で、全ての受信ＡＰ及び／又はＳＴＡがデータフレームを受信できるように周期的にポーリングする方式のことをいう。また、ＨＣＦは、ＥＤＣＡ（Ｅｎｈａｎｃｅｄ Ｄｉｓｔｒｉｂｕｔｅｄ Ｃｈａｎｎｅｌ Ａｃｃｅｓｓ）とＨＣＣＡ（ＨＣＦ Ｃｏｎｔｒｏｌｌｅｄ Ｃｈａｎｎｅｌ Ａｃｃｅｓｓ）を有する。ＥＤＣＡは、提供者が複数のユーザにデータフレームを提供するためのアクセス方式を競合ベースとするものであり、ＨＣＣＡは、ポーリングメカニズムを用いた非競合ベースのチャネルアクセス方式を用いるものである。また、ＨＣＦは、ＷＬＡＮのＱｏＳ（Ｑｕａｌｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ）を向上させるための媒体アクセスメカニズムを含み、競合周期（Ｃｏｎｔｅｎｔｉｏｎ Ｐｅｒｉｏｄ；ＣＰ）、非競合周期（Ｃｏｎｔｅｎｔｉｏｎ Ｆｒｅｅ Ｐｅｒｉｏｄ；ＣＦＰ）のいずれにおいてもＱｏＳデータを送信することができる。

図４は、バックオフ過程を説明するための図である。

図４を参照して任意バックオフ周期に基づく動作について説明する。占有（ｏｃｃｕｐｙ又はｂｕｓｙ）状態だった媒体が遊休（ｉｄｌｅ）状態に変更されると、複数のＳＴＡはデータ（又はフレーム）送信を試みることができる。この時、衝突を最小化するための方案として、ＳＴＡはそれぞれ任意バックオフカウントを選択し、それに該当するスロット時間だけ待機した後、送信を試みることができる。任意バックオフカウントは、擬似−任意整数（ｐｓｅｕｄｏ−ｒａｎｄｏｍ ｉｎｔｅｇｅｒ）値を有し、０乃至ＣＷ範囲の値のいずれか一つに決定され得る。ここで、ＣＷは、競合ウィンドウ（Ｃｏｎｔｅｎｔｉｏｎ Ｗｉｎｄｏｗ）パラメータ値である。ＣＷパラメータは初期値としてＣＷｍｉｎが与えられるが、送信失敗の場合（例えば、送信されたフレームに対するＡＣＫを受信できなかった場合）に２倍の値を取ることができる。ＣＷパラメータ値がＣＷｍａｘになると、データ送信に成功するまでＣＷｍａｘ値を維持しながらデータ送信を試みることができ、データ送信に成功する場合にはＣＷｍｉｎ値にリセットされる。ＣＷ、ＣＷｍｉｎ及びＣＷｍａｘ値は２^ｎ−１（ｎ＝０，１，２，…）に設定されることが好ましい。

任意バックオフ過程が始まると、ＳＴＡは、決定されたバックオフカウント値によってバックオフスロットをカウントダウンする間に続けて媒体をモニタする。媒体が占有状態とモニタされるとカウントダウンを止めて待機し、媒体が遊休状態になると残りのカウントダウンを再開する。

図４の例示で、ＳＴＡ３のＭＡＣに送信するパケットが到達した場合に、ＳＴＡ３はＤＩＦＳだけ媒体が遊休状態であることを確認し、直ちにフレームを送信することができる。一方、残りのＳＴＡは、媒体が占有（ｂｕｓｙ）状態であることをモニタして待機する。その間にＳＴＡ１、ＳＴＡ２及びＳＴＡ５のそれぞれでも送信するデータが発生することがあり、それぞれのＳＴＡは、媒体が遊休状態とモニタされると、ＤＩＦＳだけ待機した後に、それぞれ選択した任意バックオフカウント値によってバックオフスロットのカウントダウンを行うことができる。図４の例示では、ＳＴＡ２が最も小さいバックオフカウント値を選択し、ＳＴＡ１が最も大きいバックオフカウント値を選択した場合を示す。すなわち、ＳＴＡ２がバックオフカウントを終えてフレーム送信を始める時点でＳＴＡ５の残余バックオフ時間はＳＴＡ１の残余バックオフ時間よりも短い場合を例示する。ＳＴＡ１及びＳＴＡ５は、ＳＴＡ２が媒体を占有する間に暫くカウントダウンを止めて待機する。ＳＴＡ２の占有が終了して媒体が再び遊休状態になると、ＳＴＡ１及びＳＴＡ５はＤＩＦＳだけ待機した後に、止めていたバックオフカウントを再開する。すなわち、残余バックオフ時間だけの余りのバックオフスロットをカウントダウンした後にフレーム送信を始めることができる。ＳＴＡ５の残余バックオフ時間がＳＴＡ１よりも短かったため、ＳＴＡ５がフレーム送信を始めるようになる。一方、ＳＴＡ２が媒体を占有する間にＳＴＡ４でも送信するデータが発生することがある。このとき、ＳＴＡ４の立場では、媒体が遊休状態になるとＤＩＦＳだけ待機した後、自身が選択した任意バックオフカウント値によるカウントダウンを行ってフレーム送信を始めることができる。図４の例示では、ＳＴＡ５の残余バックオフ時間がＳＴＡ４の任意バックオフカウント値と偶然に一致する場合を示し、この場合、ＳＴＡ４とＳＴＡ５間に衝突が発生することがある。衝突が発生する場合はＳＴＡ４、ＳＴＡ５両方ともＡＣＫを受けることができず、データ送信に失敗することになる。この場合、ＳＴＡ４とＳＴＡ５はＣＷ値を２倍に増やした後に任意バックオフカウント値を選択してカウントダウンを行うことができる。一方、ＳＴＡ１は、ＳＴＡ４とＳＴＡ５の送信によって媒体が占有状態である間に待機しているが、媒体が遊休状態になると、ＤＩＦＳだけ待機した後、残余バックオフ時間が経過するとフレーム送信を開始することができる。

ＳＴＡのセンシング動作

前述したように、ＣＳＭＡ／ＣＡメカニズムは、ＡＰ及び／又はＳＴＡが媒体を直接センシングする物理的キャリアセンシング（ｐｈｙｓｉｃａｌ ｃａｒｒｉｅｒ ｓｅｎｓｉｎｇ）の他、仮想キャリアセンシング（ｖｉｒｔｕａｌ ｃａｒｒｉｅｒ ｓｅｎｓｉｎｇ）も含む。仮想キャリアセンシングは、隠れノード問題（ｈｉｄｄｅｎ ｎｏｄｅ ｐｒｏｂｌｅｍ）などのように媒体アクセスで発生し得る問題を補完するために用いられる。仮想キャリアセンシングのために、無線ＬＡＮシステムのＭＡＣはネットワーク割当ベクトル（Ｎｅｔｗｏｒｋ Ａｌｌｏｃａｔｉｏｎ Ｖｅｃｔｏｒ；ＮＡＶ）を用いることができる。ＮＡＶは、現在媒体を利用していたり又は利用する権限のあるＡＰ及び／又はＳＴＡが、媒体を使用可能な状態になるまで残っている時間を、他のＡＰ及び／又はＳＴＡに指示（ｉｎｄｉｃａｔｅ）する値である。したがって、ＮＡＶに設定された値は、当該フレームを送信するＡＰ及び／又はＳＴＡによって媒体の利用が予定されている期間に該当し、ＮＡＶ値を受信するＳＴＡは、当該期間において媒体アクセス（又は、チャネルアクセス）が禁止（ｐｒｏｈｉｂｉｔ）又は延期（ｄｅｆｅｒ）される。ＮＡＶは、例えば、フレームのＭＡＣヘッダ（ｈｅａｄｅｒ）の「ｄｕｒａｔｉｏｎ」フィールドの値によって設定されてもよい。

また、衝突可能性を低減するために堅牢な衝突検出（ｒｏｂｕｓｔ ｃｏｌｌｉｓｉｏｎ ｄｅｔｅｃｔ）メカニズムが導入された。これについて図５及び図６を参照して説明する。実際にキャリアセンシング範囲と送信範囲は同一でないこともあるが、説明の便宜のために両者は同一であると仮定する。

図５は、隠れノード及びさらしノードを説明するための図である。

図５（ａ）は、隠れノードに対する例示であり、ＳＴＡ ＡとＳＴＡ Ｂとが通信中にあり、ＳＴＡ Ｃが送信する情報を持っている場合である。具体的に、ＳＴＡ ＡがＳＴＡ Ｂに情報を送信している状況であるにもかかわらず、ＳＴＡ ＣがＳＴＡ Ｂにデータを送る前にキャリアセンシングを行う際、媒体が遊休状態にあると判断することがある。これは、ＳＴＡ Ａの送信（すなわち、媒体占有）をＳＴＡ Ｃの位置ではセンシングできないこともあるためである。このような場合、ＳＴＡ ＢはＳＴＡ ＡとＳＴＡ Ｃの情報を同時に受け、衝突が発生することになる。このとき、ＳＴＡ ＡをＳＴＡ Ｃの隠れノードということができる。

図５（ｂ）は、さらしノード（ｅｘｐｏｓｅｄ ｎｏｄｅ）に対する例示であり、ＳＴＡ ＢがＳＴＡ Ａにデータを送信している状況で、ＳＴＡ ＣがＳＴＡ Ｄに送信する情報を持っている場合である。この場合、ＳＴＡ Ｃがキャリアセンシングを行うと、ＳＴＡ Ｂの送信によって媒体が占有された状態であると判断することができる。そのため、ＳＴＡ ＣがＳＴＡ Ｄに送信する情報を持っていても、媒体占有状態とセンシングされたため、媒体が遊休状態になるまで待たなければならない。しかし、実際にはＳＴＡ ＡはＳＴＡ Ｃの送信範囲外にあるため、ＳＴＡ Ｃからの送信とＳＴＡ Ｂからの送信とがＳＴＡ Ａの立場では衝突しないこともあるため、ＳＴＡ Ｃは、ＳＴＡ Ｂが送信を止めるまで余計に待機することになる。このとき、ＳＴＡ ＣをＳＴＡ Ｂのさらしノードということができる。

図６は、ＲＴＳとＣＴＳを説明するための図である。

図５のような例示的な状況で衝突回避（ｃｏｌｌｉｓｉｏｎ ｖｏｉｄａｎｃｅ）メカニズムを効率的に利用するために、ＲＴＳ（ｒｅｑｕｅｓｔ ｔｏ ｓｅｎｄ）とＣＴＳ（ｃｌｅａｒ ｔｏ ｓｅｎｄ）などの短いシグナリングパケット（ｓｈｏｒｔ ｓｉｇｎａｌｉｎｇ ｐａｃｋｅｔ）を利用することができる。両ＳＴＡ間のＲＴＳ／ＣＴＳは周囲のＳＴＡがオーバーヒヤリング（ｏｖｅｒｈｅａｒｉｎｇ）できるようにし、この周囲のＳＴＡが上記両ＳＴＡ間の情報送信の有無を考慮するようにすることができる。例えば、データを送信しようとするＳＴＡがデータを受けるＳＴＡにＲＴＳフレームを送信すると、データを受けるＳＴＡはＣＴＳフレームを周囲のＳＴＡに送信することによって、自身がデータを受けることを知らせることができる。

図６（ａ）は、隠れノード問題を解決する方法に関する例示であり、ＳＴＡ ＡとＳＴＡ ＣがいずれもＳＴＡ Ｂにデータを送信しようとする場合を仮定する。ＳＴＡ ＡがＲＴＳをＳＴＡ Ｂに送ると、ＳＴＡ ＢはＣＴＳを自身の周囲にあるＳＴＡ Ａ及びＳＴＡ Ｃの両方に送信する。その結果、ＳＴＡ ＣはＳＴＡ ＡとＳＴＡ Ｂのデータ送信が終わるまで待機し、衝突を避けることができる。

図６（ｂ）は、さらしノード問題を解決する方法に関する例示であり、ＳＴＡ ＡとＳＴＡ Ｂ間のＲＴＳ／ＣＴＳ送信をＳＴＡ Ｃがオーバーヒヤリングすることによって、ＳＴＡ Ｃは自身が他のＳＴＡ（例えば、ＳＴＡ Ｄ）にデータを送信しても衝突が発生しないと判断することができる。すなわち、ＳＴＡ Ｂは周囲の全ＳＴＡにＲＴＳを送信し、実際に送るデータを持っているＳＴＡ ＡのみがＣＴＳを送信するようになる。ＳＴＡ Ｃは、ＲＴＳのみを受信し、ＳＴＡ ＡのＣＴＳは受信できなかったため、ＳＴＡ ＡがＳＴＡ Ｃのキャリアセンシング外にあるということがわかる。

電力管理

前述したように、無線ＬＡＮシステムではＳＴＡが送受信を行う前にチャネルセンシングを行わなければならないが、チャネルを常にセンシングすることは、ＳＴＡの持続した電力消耗を引き起こす。受信状態における電力消耗は送信状態における電力消耗に比べて大きな差がなく、受信状態を維持し続けることも、電力の制限された（すなわち、バッテリーによって動作する）ＳＴＡに大きい負担となる。したがって、ＳＴＡが持続してチャネルをセンシングするために受信待機状態を維持すると、無線ＬＡＮ処理率側面で特別な利点も無しに電力を非効率的に消耗することになる。このような問題点を解決するために、無線ＬＡＮシステムではＳＴＡの電力管理（ｐｏｗｅｒ ｍａｎａｇｅｍｅｎｔ；ＰＭ）モードを支援する。

ＳＴＡの電力管理モードは、アクティブ（ａｃｔｉｖｅ）モードと省電力（ｐｏｗｅｒ ｓａｖｅ；ＰＳ）モードとに区別される。ＳＴＡは基本的にアクティブモードで動作する。アクティブモードで動作するＳＴＡはアウェイク状態（ａｗａｋｅ ｓｔａｔｅ）を維持する。アウェイク状態は、フレーム送受信やチャネルスキャニングなどの正常な動作が可能な状態である。一方、ＰＳモードで動作するＳＴＡは、スリープ状態（ｓｌｅｅｐ ｓｔａｔｅ）（又は、ドーズ（ｄｏｚｅ）状態）とアウェイク状態（ａｗａｋｅ ｓｔａｔｅ）に切り替え（ｓｗｉｔｃｈ）されながら動作する。スリープ状態で動作するＳＴＡは最小限の電力で動作し、フレーム送受信はもとより、チャネルスキャニングも行わない。

ＳＴＡがスリープ状態で長く動作するほど電力消耗が減るため、ＳＴＡは動作期間が増加する。しかし、スリープ状態ではフレーム送受信ができず、無条件に長く動作することはできない。スリープ状態で動作するＳＴＡがＡＰに送信するフレームが存在する場合、アウェイク状態に切り替わってフレームを送信することができる。一方、ＡＰがＳＴＡに送信するフレームがある場合、スリープ状態のＳＴＡはそれを受信することができず、受信するフレームが存在することにも気づくことができない。このため、ＳＴＡは、自身に送信されるフレームの存在有無を確認するために（また、存在するなら、それを受信するために）特定周期でアウェイク状態に切り替わる動作が必要であろう。

ＡＰは一定の周期でビーコンフレーム（ｂｅａｃｏｎ ｆｒａｍｅ）をＢＳＳ内のＳＴＡに送信することができる。ビーコンフレームはＴＩＭ（Ｔｒａｆｆｉｃ Ｉｎｄｉｃａｔｉｏｎ Ｍａｐ）情報要素（Ｉｎｆｏｒｍａｔｉｏｎ Ｅｌｅｍｅｎｔ）が含むことができる。ＴＩＭ情報要素は、ＡＰが自身に関連したＳＴＡに対するバッファされたトラフィックが存在し、フレームを送信することを知らせる情報を含むことができる。ＴＩＭ要素には、ユニキャスト（ｕｎｉｃａｓｔ）フレームを知らせるために用いられるＴＩＭと、マルチキャスト（ｍｕｌｔｉｃａｓｔ）又はブロードキャスト（ｂｒｏａｄｃａｓｔ）フレームを知らせるために用いられるＤＴＩＭ（ｄｅｌｉｖｅｒｙ ｔｒａｆｆｉｃ ｉｎｄｉｃａｔｉｏｎ ｍａｐ）とがある。

図７〜図９はＴＩＭを受信したＳＴＡの動作を詳細に説明するための図である。

図７を参照すると、ＳＴＡはＡＰからＴＩＭを含むビーコンフレームを受信するためにスリープ状態からアウェイク状態に切り替わり、受信したＴＩＭ要素を解釈して、自身に送信されるバッファされたトラフィックがあることに気付くことができる。ＳＴＡは、ＰＳ−Ｐｏｌｌフレーム伝送のための媒体アクセスのために他のＳＴＡと競合（ｃｏｎｔｅｎｄｉｎｇ）を行った後に、ＡＰにデータフレーム伝送を要求するためにＰＳ−Ｐｏｌｌフレームを送信することができる。ＳＴＡによって送信されたＰＳ−Ｐｏｌｌフレームを受信したＡＰは、ＳＴＡにフレームを送信することができる。ＳＴＡはデータフレームを受信し、それに対する確認応答（ＡＣＫ）フレームをＡＰに送信することができる。その後、ＳＴＡは再びスリープ状態に切り替わり得る。

図７に示すように、ＡＰはＳＴＡからＰＳ−Ｐｏｌｌフレームを受信した後、所定の時間（例えば、ＳＩＦＳ（Ｓｈｏｒｔ Ｉｎｔｅｒ−Ｆｒａｍｅ Ｓｐａｃｅ））後にデータフレームを送信すると即座応答（ｉｍｍｅｄｉａｔｅ ｒｅｓｐｏｎｓｅ）方式によって動作することができる。一方、ＡＰがＰＳ−Ｐｏｌｌフレームを受信した後に、ＳＴＡに送信するデータフレームをＳＩＦＳ時間で準備できかなった場合には、遅延された応答（ｄｅｆｅｒｒｅｄ ｒｅｓｐｏｎｓｅ）方式によって動作することができる。これについて図８を参照して説明する。

図８の例示で、ＳＴＡがスリープ状態からアウェイク状態に切り替わってＡＰからＴＩＭを受信し、競合を経てＰＳ−ＰｏｌｌフレームをＡＰに送信する動作は、図７の例示と同様である。ＡＰがＰＳ−Ｐｏｌｌフレームを受信したがＳＩＦＳにおいてデータフレームを準備できなかった場合、データフレームを送信する代わりにＡＣＫフレームをＳＴＡに送信することができる。ＡＰはＡＣＫフレーム伝送後にデータフレームが準備されると、競合を行った後にデータフレームをＳＴＡに送信することができる。ＳＴＡはデータフレームの受信に成功したことを示すＡＣＫフレームをＡＰに送信し、スリープ状態に切り替わり得る。

図９は、ＡＰがＤＴＩＭを送信する例示に関する。ＳＴＡはＡＰからＤＴＩＭ要素を含むビーコンフレームを受信するためにスリープ状態からアウェイク状態に切り替わ得る。ＳＴＡは、受信したＤＴＩＭから、マルチキャスト／ブロードキャストフレームが送信されることが分かる。ＡＰは、ＤＴＩＭを含むビーコンフレームの伝送後にＰＳ−Ｐｏｌｌフレームの送受信動作無しで直ちにデータ（すなわち、マルチキャスト／ブロードキャストフレーム）を送信することができる。ＳＴＡは、ＤＴＩＭを含むビーコンフレームを受信した後に、続けてアウェイク状態を維持する中でデータを受信し、データ受信が完了した後に再びスリープ状態に切り替わり得る。

フレーム構造

図１０は、ＩＥＥＥ ８０２．１１システムにおいて用いられるフレーム構造の一例を説明するための図である。

ＰＰＤＵ（Ｐｈｙｓｉｃａｌ Ｌａｙｅｒ Ｐｒｏｔｏｃｏｌ Ｄａｔａ Ｕｎｉｔ）フレームフォーマットはＳＴＦ（Ｓｈｏｒｔ Ｔｒａｉｎｉｎｇ Ｆｉｅｌｄ）、ＬＴＦ（Ｌｏｎｇ Ｔｒａｉｎｉｎｇ Ｆｉｅｌｄ）、ＳＩＧ（ＳＩＧＮＡＬ）フィールド、及びデータ（Ｄａｔａ）フィールドを含むことができる。最も基本的な（例えば、ｎｏｎ−ＨＴ（Ｈｉｇｈ Ｔｈｒｏｕｇｈｐｕｔ））ＰＰＤＵフレームフォーマットは、Ｌ−ＳＴＦ（Ｌｅｇａｃｙ−ＳＴＦ）、Ｌ−ＬＴＦ（Ｌｅｇａｃｙ−ＬＴＦ）、ＳＩＧフィールド及びデータフィールドのみで構成することができる。

ＳＴＦは、信号検出、ＡＧＣ（Ａｕｔｏｍａｔｉｃ Ｇａｉｎ Ｃｏｎｔｒｏｌ）、ダイバーシチ選択、精密な時間同期などのための信号であり、ＬＴＦは、チャネル推定、周波数誤差推定などのための信号である。ＳＴＦとＬＴＦを合わせてＰＬＣＰプリアンブル（ｐｒｅａｍｂｌｅ）と称することができ、ＰＬＣＰプリアンブルはＯＦＤＭ物理層の同期化及びチャネル推定のための信号といえる。

ＳＩＧフィールドはＲＡＴＥフィールド及びＬＥＮＧＴＨフィールドなどを含むことができる。ＲＡＴＥフィールドはデータの変調及びコーディングレートに関する情報を含むことができる。ＬＥＮＧＴＨフィールドはデータの長さに関する情報を含むことができる。さらに、ＳＩＧフィールドはパリティ（ｐａｒｉｔｙ）ビット、ＳＩＧ ＴＡＩＬビットなどを含むことができる。

データフィールドはＳＥＲＶＩＣＥフィールド、ＰＳＤＵ（Ｐｈｙｓｉｃａｌ ｌａｙｅｒ Ｓｅｒｖｉｃｅ Ｄａｔａ Ｕｎｉｔ）、ＰＰＤＵ ＴＡＩＬビットを含むことができ、必要な場合にはパディングビットも含むこともできる。ＳＥＲＶＩＣＥフィールドの一部のビットは、受信端におけるデスクランブラの同期化のために用いることができる。ＰＳＤＵは、ＭＡＣ層で定義されるＭＰＤＵ（ＭＡＣ Ｐｒｏｔｏｃｏｌ Ｄａｔａ Ｕｎｉｔ）に対応し、上位層で生成／利用されるデータを含むことができる。ＰＰＤＵ ＴＡＩＬビットは、エンコーダを０状態にリターンするために用いることができる。パディングビットは、データフィールドの長さを所定の単位に合わせるために用いることができる。

ＭＰＤＵは様々なＭＡＣフレームフォーマットによって定義され、基本的なＭＡＣフレームは、ＭＡＣヘッダー、フレームボディー、及びＦＣＳ（Ｆｒａｍｅ Ｃｈｅｃｋ Ｓｅｑｕｅｎｃｅ）で構成される。ＭＡＣフレームはＭＰＤＵで構成され、ＰＰＤＵフレームフォーマットのデータ部分のＰＳＤＵで送信／受信され得る。

ＭＡＣヘッダーは、フレーム制御（Ｆｒａｍｅ Ｃｏｎｔｒｏｌ）フィールド、期間（Ｄｕｒａｔｉｏｎ）／ＩＤフィールド、アドレス（Ａｄｄｒｅｓｓ）フィールドなどを含む。フレーム制御フィールドはフレーム送信／受信に必要な制御情報を含むことができる。期間／ＩＤフィールドは、当該フレームなどを送信するための時間に設定することができる。

ＭＡＣヘッダーに含まれた期間／ＩＤフィールドは１６ビット長（例えば、Ｂ０〜Ｂ１５）に設定され得る。期間／ＩＤフィールドに含まれるコンテンツは、フレームタイプ及びサブタイプ、ＣＦＰ（ｃｏｎｔｅｎｔｉｏｎ ｆｒｅｅ ｐｅｒｉｏｄ）において送信されるか否か、送信ＳＴＡのＱｏＳキャパビリティなどによって変わり得る。（ｉ）サブタイプがＰＳ−Ｐｏｌｌである制御フレームにおいて、期間／ＩＤフィールドは送信ＳＴＡのＡＩＤを含むことができ（例えば、１４ＬＳＢビットで）、２ＭＳＢビットは１に設定され得る。（ｉｉ）ＰＣ（ｐｏｉｎｔ ｃｏｏｒｄｉｎａｔｏｒ）又はｎｏｎ−ＱｏＳ ＳＴＡによってＣＦＰで送信されるフレームにおいて、期間／ＩＤフィールドは固定値（例えば、３２７６８）に設定され得る。（ｉｉｉ）その他、ｎｏｎ−ＱｏＳ ＳＴＡによって送信される他のフレーム又はＱｏＳ ＳＴＡによって送信される制御フレームにおいて、期間／ＩＤフィールドは各フレームタイプ別に定義されたｄｕｒａｔｉｏｎ値を含むことができる。ＱｏＳ ＳＴＡによって送信されるデータフレーム又はマネジメントフレームにおいて、期間／ＩＤフィールドは各フレームタイプに対して定義されたｄｕｒａｔｉｏｎ値を含むことができる。例えば、期間／ＩＤフィールドのＢ１５＝０に設定されると、期間／ＩＤフィールドがＴＸＯＰ Ｄｕｒａｔｉｏｎを示すために用いられることを示し、Ｂ０〜Ｂ１４は、実際ＴＸＯＰ Ｄｕｒａｔｉｏｎを示すために用いることができる。Ｂ０〜Ｂ１４によって示される実際ＴＸＯＰ Ｄｕｒａｔｉｏｎは、０〜３２７６７のいずれか一つであり、その単位はマイクロセカンド（ｕｓ）であってよい。ただし、期間／ＩＤフィールドが固定のＴＸＯＰ Ｄｕｒａｔｉｏｎ値（例えば、３２７６８）を示す場合には、Ｂ１５＝１であり、Ｂ０〜Ｂ１４＝０に設定され得る。その他、Ｂ１４＝１、Ｂ１５＝１に設定されると、期間／ＩＤフィールドがＡＩＤを示すために用いられ、Ｂ０〜Ｂ１３は１〜２００７のうちの一つのＡＩＤを示す。ＭＡＣヘッダーのＳｅｑｕｅｎｃｅ Ｃｏｎｔｒｏｌ、ＱｏＳ Ｃｏｎｔｒｏｌ、ＨＴ Ｃｏｎｔｒｏｌサブフィールドの具体的な内容は、ＩＥＥＥ ８０２．１１標準文書を参照されたい。

ＭＡＣヘッダーのフレーム制御フィールドはＰｒｏｔｏｃｏｌ Ｖｅｒｓｉｏｎ、Ｔｙｐｅ、Ｓｕｂｔｙｐｅ、Ｔｏ ＤＳ、Ｆｒｏｍ ＤＳ、Ｍｏｒｅ Ｆｒａｇｍｅｎｔ、Ｒｅｔｒｙ、Ｐｏｗｅｒ Ｍａｎａｇｅｍｅｎｔ、Ｍｏｒｅ Ｄａｔａ、Ｐｒｏｔｅｃｔｅｄ Ｆｒａｍｅ、Ｏｒｄｅｒサブフィールドを含むことができる。フレーム制御フィールドの各サブフィールドの内容は、ＩＥＥＥ ８０２．１１標準文書を参照されたい。

図１１は、ＣＦ（ｃｏｎｔｅｎｔｉｏｎ ｆｒｅｅ）−ＥＮＤフレームを例示する。

説明の便宜上、ＣＦ−ＥＮＤフレームがｎｏｎ−ＤＭＧ（ｄｉｒｅｃｔｉｏｎａｌ ｍｕｌｔｉ−ｇｉｇａｂｉｔ，１１ａｄ）ＳＴＡによって送信されると仮定する。ＣＦ−ＥＮＤフレームはＴＸＯＰ ｄｕｒａｔｉｏｎを切断（ｔｒｕｎｃａｔｉｏｎ）するために送信され得る。したがって、ＣＦ−ＥＮＤフレームで期間（ｄｕｒａｔｉｏｎ）フィールドは０に設定される。ＲＡ（Ｒｅｃｅｉｖｅｒ Ａｄｄｒｅｓｓ）フィールドはブロードキャストグループアドレスに設定され得る。ＢＳＳＩＤフィールドはＡＰに含まれたＳＴＡのアドレスに設定され得る。ただし、ＶＨＴ ＳＴＡがＶＨＴ ＡＰに送信するｎｏｎ−ＨＴ又はｎｏｎ−ＨＴ ｄｕｐｌｉｃａｔｅフォーマットのＣＦ−ＥＮＤフレームの場合、ＢＳＳＩＤフィールドのＩｎｄｉｖｉｄｕａｌ／Ｇｒｏｕｐビットは１に設定され得る。

ＨＥ ＰＰＤＵ構造の例示

以下では、１１ａｘを支援する無線ＬＡＮシステムにおけるＨＥ ＰＰＤＵ（Ｈｉｇｈ Ｅｆｆｉｃｉｅｎｃｙ Ｐｈｙｓｉｃａｌ ｌａｙｅｒ Ｐｒｏｔｏｃｏｌ Ｄａｔａ Ｕｎｉｔ）フォーマットの一例について説明する。

図１２にＨＥ ＰＰＤＵの一例を示す。図１２を参照すると、ＨＥ−ＳＩＧ Ａ（又は、ＨＥ−ＳＩＧ１）フィールドはＬ−Ｐａｒｔ（例えば、Ｌ−ＳＴＦ、Ｌ−ＬＴＦ、Ｌ−ＳＩＧ）に続いて位置し、Ｌ−Ｐａｒｔと同様に２０ＭＨｚ単位で反復（ｄｕｐｌｉｃａｔｉｏｎ）される。ＨＥ−ＳＩＧ ＡはＳＴＡに対する共通制御情報（ｃｏｍｍｏｎ ｃｏｎｔｒｏｌ ｉｎｆｏｒｍａｔｉｏｎ）（例えば、ＢＷ、ＧＩ長、ＢＳＳインデックス、ＣＲＣ、Ｔａｉｌなど）を含む。ＨＥ−ＳＩＧ ＡフィールドはＨＥ ＰＰＤＵを解釈するための情報を含み、したがって、ＨＥ−ＳＩＧ Ａフィールドに含まれる情報は、ＨＥ ＰＰＤＵのフォーマット（例えば、ＳＵ ＰＰＤＵ、ＭＵ ＰＰＤＵ又はトリガーベースのＰＰＤＵなど）によって変わり得る。例えば、ＨＥ ＳＵ ＰＰＤＵフォーマットにおいて、ＨＥ−ＳＩＧ Ａフィールドは、ＤＬ／ＵＬ指示子、ＨＥ ＰＰＤＵフォーマット指示子、ＢＳＳ Ｃｏｌｏｒ、ＴＸＯＰ Ｄｕｒａｔｉｏｎ、ＢＷ（ｂａｎｄｗｉｄｔｈ）、ＭＣＳ、ＣＰ＋ＬＴＦ長、コーディング情報、ストリーム数、ＳＴＢＣ（例えば、ＳＴＢＣ使用の有無）、送信ビームフォーミング（ＴｘＢＦ）情報、ＣＲＣ及びＴａｉｌのうち少なくとも一つを含むことができる。ＨＥ ＳＵ ＰＰＤＵフォーマットの場合、ＨＥ−ＳＩＧ Ｂフィールドが省略されてもよい。ＨＥ ＭＵ ＰＰＤＵフォーマットにおいて、ＨＥ−ＳＩＧ Ａフィールドは、ＤＬ／ＵＬ指示子、ＢＳＳ Ｃｏｌｏｒ、ＴＸＯＰ Ｄｕｒａｔｉｏｎ、ＢＷ（ｂａｎｄｗｉｄｔｈ）、ＳＩＧ ＢフィールドのＭＣＳ情報、ＳＩＧ Ｂフィールドのシンボル数、ＨＥ ＬＴＦシンボル数、全帯域ＭＵ−ＭＩＭＯ使用の有無を示す指示子、ＣＰ＋ＬＴＦ長、送信ビームフォーミング（ＴｘＢＦ）情報、ＣＲＣ及びＴａｉｌのうち少なくとも一つを含むことができる。ＨＥトリガーベースのＰＰＤＵフォーマットにおいて、ＨＥ−ＳＩＧ Ａフィールドは、フォーマット指示子（例えば、ＳＵ ＰＰＤＵか又はトリガーベースＰＰＤＵか）、ＢＳＳ Ｃｏｌｏｒ、ＴＸＯＰ Ｄｕｒａｔｉｏｎ、ＢＷ、ＣＲＣ及びＴａｉｌのうち少なくとも一つを含むことができる。

図１３にはＨＥ ＰＰＤＵの他の例を示す。図１３を参照すると、ＨＥ−ＳＩＧ Ａは、上述した共通制御情報（ｃｏｍｍｏｎ ｉｎｆｏｒｍａｔｉｏｎ）の他に、ユーザ割り当て情報（ｕｓｅｒ ａｌｌｏｃａｔｉｏｎ ｉｎｆｏｒｍａｔｉｏｎ）、例えば、ＰＡＩＤ又はＧＩＤなどのＳＴＡ識別子、割り当てられたリソース情報及びストリーム数（Ｎｓｔｓ）のうち少なくとも一つが含まれてもよい。図１３によれば、ＨＥ−ＳＩＧ Ｂ（又は、ＨＥ−ＳＩＧ２）はＯＦＤＭＡ割り当てごとに送信され得る。ＭＵ−ＭＩＭＯである場合、ＨＥ−ＳＩＧ ＢはＳＤＭでＳＴＡによって区別される。ＨＥ−ＳＩＧ Ｂは追加のユーザ割り当て情報（ｕｓｅｒ ａｌｌｏｃａｔｉｏｎ ｉｎｆｏｒｍａｔｉｏｎ）、例えば、ＭＣＳ、Ｃｏｄｉｎｇ情報、ＳＴＢＣ（Ｓｐａｃｅ Ｔｉｍｅ Ｂｌｏｃｋ ｃｏｄｅ）情報、送信ビームフォーミング（ＴＸＢＦ）情報などを含むことができる。

図１４に、ＨＥ ＰＰＤＵの更に他の例を示す。ＨＥ−ＳＩＧ Ｂは、ＨＥ−ＳＩＧ Ａの次に送信される。ＨＥ−ＳＩＧ Ｂは、ＨＥ−ＳＩＧ Ａの情報（ｎｕｍｅｒｏｌｏｇｙ）に基づいて、全帯域（ｆｕｌｌ ｂａｎｄ）を通じて送信され得る。ＨＥ−ＳＩＧ Ｂはユーザ割り当て情報、例えば、ＳＴＡ ＡＩＤ、リソース割り当て情報（例えば、割り当てサイズ）、ＭＣＳ、ストリーム数（Ｎｓｔｓ）、Ｃｏｄｉｎｇ、ＳＴＢＣ、送信ビームフォーミング（ＴＸＢＦ）などを含むことができる。

図１５に、ＨＥ ＰＰＤＵの更に他の例を示す。ＨＥ−ＳＩＧ Ｂは、一定の単位チャネルごとに反復送信され得る。図１５を参照すると、ＨＥ−ＳＩＧ Ｂは２０ＭＨｚ単位で反復送信され得る。例えば、８０ＭＨｚ帯域幅上で２０ＭＨｚ当たりに同一情報が複写されることによってＨＥ−ＳＩＧ Ｂが送信され得る。

２０ＭＨｚチャネル当たりに反復送信されるＨＥ−ＳＩＧＢを受信したＳＴＡ／ＡＰは、２０ＭＨｚチャネル当たりに受信したＨＥ−ＳＩＧ Ｂを累積（ａｃｃｕｍｕｌａｔｉｏｎ）してＨＥ−ＳＩＧ Ｂ受信に対する信頼性（ｒｅｌｉａｂｉｌｉｔｙ）を向上させることができる。

チャネル当たりに同一信号（例えば、ＨＥ−ＳＩＧ Ｂ）が反復送信されるので、累積された信号の利得は、信号が反復送信されるチャネルの個数に比例して受信性能が向上し得る。理想的には、反復送信される前の信号に比べて、反復送信される信号は３ｄＢ Ｘチャネル数（ｎｕｍｂｅｒ ｏｆ ｃｈａｎｎｅｌ）の利得を有することができる。したがって、反復送信されるＨＥ−ＳＩＧ Ｂは、反復送信されるチャネルの数に従ってＭＣＳレベルを高めて送信され得る。例えば、反復伝送がない時にＨＥ−ＳＩＧ ＢにＭＣＳ ０が用いられると仮定すれば、４０ＭＨｚで反復送信されるＨＥ−ＳＩＧ ＢにはＭＣＳ１が用いられ得る。反復伝送のためのチャネルの個数が増加するほど、より高いＭＣＳレベルでＨＥ−ＳＩＧ Ｂが送信され得るため、単位チャネル当たりのＨＥ−ＳＩＧ Ｂのオーバーヘッドを減らすことができる。

図１６にＨＥ ＰＰＤＵの更に他の例を示す。図１６を参照すると、ＨＥ−ＳＩＧ Ｂは、２０ＭＨｚチャネル単位ごとに独立した情報を含むことができる。ＨＥ−ＳＩＧ Ｂは、レガシーパート（例えば、Ｌ−ＳＴＦ、Ｌ−ＬＴＦ、Ｌ−ＳＩＧ）及びＨＥ−ＳＩＧ Ａと同様に１ｘシンボル構造で送信され得る。一方、広帯域幅（ｗｉｄｅ ｂａｎｄｗｉｄｔｈ）において、“Ｌ−ＳＴＦ＋Ｌ−ＬＴＦ＋Ｌ−ＳＩＧ＋ＨＥ−ＳＩＧＡ＋ＨＥ−ＳＩＧＢ”の長さは全チャネルにおいて同一でなければならない。２０ＭＨｚ当たりに送信されるＨＥ−ＳＩＧ Ｂは、当該帯域に対する割り当て情報、例えば、当該帯域を利用するユーザ別割り当て情報、ユーザ識別子などを含むことができる。しかし、各帯域別に支援されるユーザ数と各帯域で利用されるリソースブロックの構成が異なることから、ＨＥ−ＳＩＧ Ｂの情報が帯域別に異なり得る。したがって、ＨＥ−ＳＩＧ Ｂの長さはチャネル別に異なり得る。

図１７では、ＨＥ−ＳＴＦ以前の長さ（例えば、ＨＥ−ＳＩＧ Ｂまでの長さ）をチャネル別に同一に構成するために、ＨＥ−ＳＩＧ Ｂに対するパディング方案を説明する。例えば、パディング長（ｐａｄｄｉｎｇ ｌｅｎｇｔｈ）の分だけＨＥ−ＳＩＧ Ｂを反復させてＨＥ−ＳＩＧ Ｂの長さを整列することができる。図１８に示すように、ＨＥ−ＳＩＧ Ｂの先頭（又は、末尾）から必要なパディング長だけのＨＥ−ＳＩＧ ＢがＨＥ−ＳＩＧ Ｂにパッドされ得る。

一実施例によれば、帯域幅が２０ＭＨｚより大きくない場合、１つのＨＥ−ＳＩＧ Ｂフィールドが送信され得る。帯域幅が２０ＭＨｚより大きい場合、２０ＭＨｚサイズのチャネルは、それぞれ、第１タイプＨＥ−ＳＩＧ Ｂ（以下、ＨＥ−ＳＩＧ Ｂ ［１］）又は第２タイプＨＥ−ＳＩＧ Ｂ（以下、ＨＥ−ＳＩＧ Ｂ ［２］）のいずれか一つを送信することができる。例えば、ＨＥ−ＳＩＧ Ｂ ［１］とＨＥ−ＳＩＧ Ｂ ［２］が交互に送信され得る。奇数番目の２０ＭＨｚチャネルはＨＥ−ＳＩＧ Ｂ ［１］を送信し、偶数番目の２０ＭＨｚチャネルはＨＥ−ＳＩＧ Ｂ ［２］を送信することができる。より具体的に、４０ＭＨｚ帯域幅の場合、ＨＥ−ＳＩＧ Ｂ ［１］が１番目の２０ＭＨｚチャネル上で送信され、ＨＥ−ＳＩＧ Ｂ ［２］が２番目の２０ＭＨｚチャネル上で送信される。８０ＭＨｚ帯域幅の場合、ＨＥ−ＳＩＧ Ｂ ［１］が１番の２０ＭＨｚチャネル上で送信され、ＨＥ−ＳＩＧ Ｂ ［２］が２番目の２０ＭＨｚチャネル上で送信され、同じＨＥ−ＳＩＧ Ｂ ［１］が３番目の２０ＭＨｚチャネル上で反復送信され、同じＨＥ−ＳＩＧ Ｂ ［２］が４番目の２０ＭＨｚチャネル上で反復送信される。１６０ＭＨｚ帯域幅でもこれと類似に送信される。

このように、ＨＥ−ＳＩＧ Ｂは帯域幅のサイズが増加するに従って反復送信され得るが、反復送信されるＨＥ−ＳＩＧ Ｂは、自身と同じタイプのＨＥ−ＳＩＧ Ｂが送信された２０ＭＨｚチャネルから２０ＭＨｚサイズだけ周波数跳躍して送信され得る。

一方、ＨＥ−ＳＩＧ Ｂ ［１］とＨＥ−ＳＩＧ Ｂ ［２］のコンテンツはそれぞれ異なり得る。ただし、ＨＥ−ＳＩＧ−Ｂ ［１］は全て同じコンテンツを有する。同様に、ＨＥ−ＳＩＧ Ｂ ［２］は全て同じコンテンツを有する。

一実施例によれば、ＨＥ−ＳＩＧ Ｂ ［１］は奇数番２０ＭＨｚチャネルに対するリソース割り当て情報のみを含み、ＨＥ−ＳＩＧ Ｂ ［２］は偶数番２０ＭＨｚチャネルに対するリソース割り当て情報のみを含むように設定され得る。本発明の他の実施例によれば、ＨＥ−ＳＩＧ Ｂ ［１］が偶数２０ＭＨｚチャネルうちの一部に対するリソース割り当て情報を含んだり、ＨＥ−ＳＩＧ Ｂ ［２］が奇数２０ＭＨｚチャネルうちの一部に対するリソース割り当て情報を含むことができる。

ＨＥ−ＳＩＧ Ｂは共通フィールド（Ｃｏｍｍｏｎ ｆｉｅｌｄ）及びユーザ特定フィールド（Ｕｓｅｒ ｓｐｅｃｉｆｉｃ ｆｉｅｌｄ）を含むことができる。共通フィールドはユーザ特定フィールドに先行し得る。共通フィールドとユーザ特定フィールドはＯＦＤＭシンボル単位ではなくビット単位で区別され得る。

ＨＥ−ＳＩＧ Ｂの共通フィールドは、当該帯域幅でＰＰＤＵを受信するように指定された全てのＳＴＡに関する情報を含む。共通フィールドはＲＵ（ｒｅｓｏｕｒｃｅ ｕｎｉｔ）割り当て情報を含むことができる。ＨＥ−ＳＩＧ Ｂ ［１］同士はいずれもコンテンツが同一であり、同様にＨＥ−ＳＩＧ Ｂ ［２］同士はいずれもコンテンツが同一である。例えば、８０ＭＨｚを構成する４個の２０ＭＨｚチャネルを［ＬＬ，ＬＲ，ＲＬ，ＲＲ］と区分するとき、ＨＥ−ＳＩＧ Ｂ ［１］の共通フィールドにＬＬ及びＲＬに対する共通ブロックが含まれ、ＨＥ−ＳＩＧ Ｂ ［２］の共通フィールドにＬＲ及びＲＲに対する共通ブロックが含まれ得る。

ＨＥ−ＳＩＧ Ｂのユーザ特定フィールドは多数のユーザフィールド（ｕｓｅｒ ｆｉｅｌｄ）を含むことができ、各ユーザフィールドはＰＰＤＵを受信するように指定された個別ＳＴＡに特定的な情報を含むことができる。例えば、ユーザフィールドは、ステーションＩＤ、ＳＴＡ別ＭＣＳ、ストリーム数（Ｎｓｔｓ）、Ｃｏｄｉｎｇ（例えば、ＬＤＰＣ使用に対する指示）、ＤＣＭ指示子及び送信ビームフォーミング情報のうちの一つを含むことができ、これに限定されない。

ＵＬ ＭＵの伝送

図１９は、本発明の一実施例に係る上りリンク多重ユーザ伝送状況を説明するための図である。

上述したように、８０２．１１ａｘシステムではＵＬ ＭＵ伝送方式を用いることができ、これは、図１９に示すように、ＡＰが複数のＳＴＡ（例えば、ＳＴＡ１〜ＳＴＡ４）にトリガーフレーム（Ｔｒｉｇｇｅｒ Ｆｒａｍｅ）を送信することによって開始できる。トリガーフレームはＵＬ ＭＵ割り当て情報を含むことができる。ＵＬ ＭＵ割り当て情報は、例えば、リソース位置及びサイズ、ＳＴＡ ＩＤ又は受信ＳＴＡアドレス、ＭＣＳ及びＭＵタイプ（ＭＩＭＯ、ＯＦＤＭＡなど）のうち少なくとも一つを含むことができる。具体的に、トリガーフレームは、（ｉ）ＵＬ ＭＵフレームに対する持続時間（ｄｕｒａｔｉｏｎ）、（ｉｉ）割り当ての数（Ｎ）、及び（ｉｉｉ）各割り当ての情報のうち少なくとも一つを含むことができる。各割り当ての情報はユーザ別情報（Ｐｅｒ ｕｓｅｒ Ｉｎｆｏ）を含むことができる。各割り当ての情報は、例えば、ＡＩＤ（ＭＵの場合、ＳＴＡ数だけさらに含まれる。）、電力調節（Ｐｏｗｅｒ ａｄｊｕｓｔｍｅｎｔ）、リソース（又は、トーン）割り当て情報（例えば、ビットマップ）、ＭＣＳ、ストリーム数（Ｎｓｔｓ）、ＳＴＢＣ、コーディング、送信ビームフォーミングに関する情報のうち少なくとも一つを含むことができる。

一方、図１９に示すように、ＡＰは媒体に接続するために競合過程を経てトリガーフレームを送信するＴＸＯＰを取得することができる。これに対応してＳＴＡは、トリガーフレームのＳＩＦＳ後に、ＡＰが示しているフォーマットでＵＬデータフレームを送信することができる。これに対応して本発明の実施例に係るＡＰは、ＢＡ（Ｂｌｏｃｋ ＡＣＫ）フレームでＵＬ ＭＵデータフレームに対して確認応答を行うことを仮定する。

図２０に、一実施例に係るトリガーフレームフォーマットを示す。

図２０を参照すると、トリガーフレームは、フレーム制御（ｆｒａｍｅ ｃｏｎｔｒｏｌ）フィールド、長さ（ｄｕｒａｔｉｏｎ）フィールド、ＲＡ（ｒｅｃｉｐｉｅｎｔ ＳＴＡ ａｄｄｒｅｓｓ）フィールド、ＴＡ（ｔｒａｎｓｍｉｔｔｉｎｇ ＳＴＡ ａｄｄｒｅｓｓ）フィールド、共通情報（ｃｏｍｍｏｎ ｉｎｆｏｒｍａｔｉｏｎ）フィールド、１つ又は２つ以上の個別ユーザ情報（Ｐｅｒ Ｕｓｅｒ Ｉｎｆｏ）フィールド及びＦＣＳ（Ｆｒａｍｅ Ｃｈｅｃｋ Ｓｕｍ）のうち少なくとも一つを含むことができる。ＲＡフィールドは、受信ＳＴＡのアドレス又はＩＤを示し、実施例によって省略されてもよい。ＴＡフィールドは、送信ＳＴＡのアドレスを示す。

共通情報フィールドは、長さ（ｌｅｎｇｔｈ）サブフィールド、カスケード指示子（Ｃａｓｃａｄｅ Ｉｎｄｉｃａｔｉｏｎ）、ＨＥ−ＳＩＧ Ａ情報サブフィールド、ＣＰ／ＬＴＦタイプサブフィールド、トリガータイプサブフィールド及びトリガー−依存共通情報（ｔｒｉｇｇｅｒ−ｄｅｐｅｎｄｅｎｔ Ｃｏｍｍｏｎ Ｉｎｆｏ）サブフィールドのうち少なくとも一つを含むことができる。長さサブフィールドは、ＵＬ ＭＵ ＰＰＤＵのＬ−ＳＩＧ長を示す。カスケード指示子は、現在トリガーフレームに続いてトリガーフレームの伝送があるか否かを示す。ＨＥ−ＳＩＧ Ａ情報サブフィールドは、ＵＬ ＭＵ ＰＰＤＵのＨＥ−ＳＩＧ Ａに含まれるコンテンツを示す。ＣＰ／ＬＴＦタイプサブフィールドは、ＵＬ ＭＵ ＰＰＤＵに含まれるＣＰ及びＨＥ ＬＴＦタイプを示す。トリガータイプサブフィールドは、トリガーフレームのタイプを示す。トリガーフレームは、当該タイプ特定の共通情報及びタイプ特定の個別ユーザ情報（Ｐｅｒ Ｕｓｅｒ Ｉｎｆｏ）を含むことができる。トリガータイプは、例えば、ベーシックトリガータイプ（例えば、タイプ０）、ビームフォーミング報告ボールトリガー（Ｂｅａｍｆｏｒｍｉｎｇ Ｒｅｐｏｒｔ Ｐｏｌｌ Ｔｒｉｇｇｅｒ）タイプ（例えば、タイプ１）、ＭＵ−ＢＡＲ（Ｍｕｌｔｉ−ｕｓｅｒ Ｂｌｏｃｋ Ａｃｋ Ｒｅｑｕｅｓｔ）タイプ（例えば、タイプ２）又はＭＵ−ＲＴＳ（ｍｕｌｔｉ−ｕｓｅｒ ｒｅａｄｙ ｔｏ ｓｅｎｄ）タイプ（例えば、タイプ３）のいずれか一つに設定され得、これに限定されない。トリガータイプがＭＵ−ＢＡＲである場合、トリガー依存共通情報サブフィールドはＧＣＲ（Ｇｒｏｕｐｃａｓｔ ｗｉｔｈ Ｒｅｔｒｉｅｓ）指示子及びＧＣＲアドレスを含むことができる。

個別ユーザ情報フィールド（Ｐｅｒ Ｕｓｅｒ Ｉｎｆｏ ｆｉｅｌｄ）は、ユーザ識別子サブフィールド、ＲＵ（ｒｅｓｏｕｒｃｅ ｕｎｉｔ）割り当てサブフィールド、コーディングタイプサブフィールド、ＭＣＳフィールド、ＤＣＭ（ｄｕａｌ ｓｕｂ−ｃａｒｒｉｅｒ ｍｏｄｕｌａｔｉｏｎ）サブフィールド、ＳＳ（ｓｐａｔｉａｌ ｓｔｒｅａｍ）割り当てサブフィールド及びトリガー依存個別ユーザ情報（Ｔｒｉｇｇｅｒ ｄｅｐｅｎｄｅｎｔ Ｐｅｒ Ｕｓｅｒ Ｉｎｆｏ）サブフィールドのうち少なくとも一つを含むことができる。ユーザ識別子サブフィールドは、ＵＬ ＭＵ ＰＰＤＵのＭＰＤＵを送信するために当該リソースユニット（ｒｅｓｏｕｒｃｅ ｕｎｉｔ）を使用するＳＴＡのＡＩＤを示す。ＲＵ割り当てサブフィールドは、該当のＳＴＡがＵＬ ＭＵ ＰＰＤＵを送信するためのリソースユニットを示す。コーディングタイプサブフィールドは、該当のＳＴＡが送信するＵＬ ＭＵ ＰＰＤＵのコーディングタイプを示す。ＭＣＳサブフィールドは、該当のＳＴＡが送信するＵＬ ＭＵ ＰＰＤＵのＭＣＳを示す。ＤＣＭサブフィールドは、該当のＳＴＡが送信するＵＬ ＭＵ ＰＰＤＵの二重キャリア変調に関する情報を示す。ＳＳ割り当てサブフィールドは、該当のＳＴＡが送信するＵＬ ＭＵ ＰＰＤＵの空間ストリーム（ｓｐａｔｉａｌ ｓｔｒｅａｍｓ）に関する情報を示す。トリガータイプがＭＵ−ＢＡＲである場合、トリガー依存個別ユーザ情報サブフィールドはＢＡＲ制御及びＢＡＲ情報を含むことができる。

ＮＡＶ（ｎｅｔｗｏｒｋ ａｌｌｏｃａｔｉｏｎ ｖｅｃｔｏｒ）

ＮＡＶは、送信ＳＴＡ（例えば、ＴＸＯＰ ｈｏｌｄｅｒ）のＴＸＯＰを保護するための一種のタイマーと理解され得る。ＳＴＡは、自身に設定されたＮＡＶが有効な期間ではチャネルアクセスを行わず、他のＳＴＡのＴＸＯＰを保護することができる。

現在ｎｏｎ−ＤＭＧ ＳＴＡの場合、１つのＮＡＶを支援する。有効な（ｖａｌｉｄ）フレームを受信したＳＴＡは、ＰＳＤＵのｄｕｒａｔｉｏｎフィールド（例えば、ＭＡＣヘッダーのｄｕｒａｔｉｏｎフィールド）でＮＡＶをアップデートすることができる。ただし、受信したフレームのＲＡフィールドが当該ＳＴＡのＭＡＣアドレスと一致する場合、ＳＴＡはＮＡＶをアップデートしない。受信したフレームのｄｕｒａｔｉｏｎフィールドが示すｄｕｒａｔｉｏｎが、ＳＴＡの現在ＮＡＶ値より大きいと、ＳＴＡは、受信したフレームのｄｕｒａｔｉｏｎでＮＡＶをアップデートする。

図２１に、ＮＡＶ設定（ｓｅｔｔｉｎｇ）の一例を示す。

図２１を参照すると、Ｓｏｕｒｃｅ ＳＴＡはＲＴＳフレームを送信し、Ｄｅｓｔｉｎａｔｉｏｎ ＳＴＡはＣＴＳフレームを送信する。上述したように、ＲＴＳフレームによって受信者として指定されたｄｅｓｔｉｎａｔｉｏｎ ＳＴＡはＮＡＶを設定しない。他のＳＴＡの一部はＲＴＳフレームを受信してＮＡＶを設定し、他の一部はＣＴＳフレームを受信してＮＡＶを設定することができる。

ＲＴＳフレームを受信した時点（例えば、ＭＡＣがＲＴＳフレームに対応するＰＨＹ−ＲＸＥＮＤ．ｉｎｄｉｃａｔｉｏｎ ｐｒｉｍｉｔｉｖｅを受信した時点）から一定期間内にＣＴＳフレーム（例えば、ＰＨＹ−ＲＸＳＴＡＲＴ．ｉｎｄｉｃａｔｉｏｎ ｐｒｉｍｉｔｉｖｅ）を受信しないと、ＲＴＳフレームを用いてＮＡＶを設定又はアップデートしたＳＴＡはＮＡＶをリセット（例えば、０）することができる。一定期間は、（２＊ａＳＩＦＳＴｉｍｅ＋ＣＴＳ＿Ｔｉｍｅ＋ａＲｘＰＨＹＳｔａｒｔＤｅｌａｙ＋２＊ａＳｌｏｔＴｉｍｅ）であってよい。ＣＴＳ＿Ｔｉｍｅは、ＲＴＳフレームが示すＣＴＳフレームの長さ及びデータレートに基づいて計算することができる。

図２１では便宜のためにＲＴＳフレーム又はＣＴＳフレームを用いてＮＡＶを設定又はアップデートすることを例示したが、ＮＡＶ設定／再設定／アップデートは他の様々なフレーム、例えば、ｎｏｎ−ＨＴ ＰＰＤＵ、ＨＴ ＰＰＤＵ、ＶＨＴ ＰＰＤＵ又はＨＥ ＰＰＤＵのｄｕｒａｔｉｏｎフィールド（例えば、ＭＡＣフレームのＭＡＣヘッダー内のｄｕｒａｔｉｏｎフィールド）に基づいて行われてもよい。例えば、受信したＭＡＣフレームにおいてＲＡフィールドが自身のアドレス（例えば、ＭＡＣアドレス）と一致しないと、ＳＴＡはＮＡＶを設定／再設定／アップデートすることができる。

ＴＸＯＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｏｐｐｏｒｔｕｎｉｔｙ）切断（Ｔｒｕｎｃａｔｉｏｎ）

図２２にＴＸＯＰ ｔｒｕｎｃａｔｉｏｎの一例を示す。

ＴＸＯＰ ｈｏｌｄｅｒ ＳＴＡは、ＣＦ−ＥＮＤフレームを送信することによってＴＸＯＰを切断（ｔｒｕｎｃａｔｉｏｎ）することができる。ＣＦ−ＥＮＤフレーム又はＣＦ−ＥＮＤ＋ＣＦ−ＡＣＫフレームを受信したＳＴＡは、ＮＡＶをリセット（例えば、０）することができる。

ＥＤＣＡによってチャネルアクセスを取得したＳＴＡが自身の送信キュー（ｑｕｅｕｅ）を空けた場合、ＣＦ−ＥＮＤフレームを送信することができる。ＳＴＡはＣＦ−ＥＮＤフレームを送信して自身のＴＸＯＰ完了を明示的に示すことができる。ＣＦ−ＥＮＤフレームはＴＸＯＰ ｈｏｌｄｅｒが送信することができる。ＴＸＯＰ ｈｏｌｄｅｒでないｎｏｎ−ＡＰ ＳＴＡは、ＣＦ−ＥＮＤフレームを送信することができない。ＣＦ−ＥＮＤフレームを受信したＳＴＡは、ＣＦ−ＥＮＤフレームが含まれたＰＰＤＵの終了時点でＮＡＶをリセットする。

図２２を参照すると、ＥＤＣＡで媒体にアクセスしたＳＴＡは、ＮＡＶ設定のためのシーケンス（例えば、ＲＴＳ／ＣＴＳなど）を送信する。

ＳＩＦＳ後に、ＴＸＯＰ ｈｏｌｄｅｒ（又は、ＴＸＯＰ ｉｎｉｔｉａｔｏｒ）とＴＸＯＰ ｒｅｓｐｏｎｄｅｒはＰＰＤＵを送受信する（例えば、ｉｎｉｔｉａｔｏｒ ｓｅｑｕｅｎｃｅ）。ＴＸＯＰ ｈｏｌｄｅｒはＴＸＯＰ限度内でそれ以上送信できるデータがない場合、ＣＦ−ＥＮＤフレームを送信することによってＴＸＯＰを切断（ｔｒｕｎｃａｔｅ）する。

ＣＦ−ＥＮＤフレームを受信したＳＴＡは自身のＮＡＶをリセットし、それ以上の遅延無しで媒体アクセスのための競合（ｃｏｎｔｅｎｄｉｎｇ）を始めることができる。

上述したように、現在無線ＬＡＮシステムにおいてＴＸＯＰ ｄｕｒａｔｉｏｎはＭＡＣヘッダーのＤｕｒａｔｉｏｎフィールドで設定される。すなわち、ＴＸＯＰ ｈｏｌｄｅｒ（例えば、Ｔｘ ＳＴＡ）とＴＸＯＰ Ｒｅｓｐｏｎｄｅｒ（例えば、Ｒｘ ＳＴＡ）は、それらが互いに送受信するフレームのＤｕｒａｔｉｏｎフィールドに、フレームの送受信に必要な全ＴＸＯＰ情報を含めて送信する。ＴＸＯＰ ｈｏｌｄｅｒやＴＸＯＰ Ｒｅｓｐｏｎｄｅｒでない第３のＳＴＡ（すなわち、Ｔｈｉｒｄ ｐａｒｔｙ ＳＴＡｓ）は、ＴＸＯＰ ｈｏｌｄｅｒとＴＸＯＰ Ｒｅｓｐｏｎｄｅｒとの間に交換されるフレームのＤｕｒａｔｉｏｎフィールドを確認し、ＮＡＶを設定／アップデートすることによってＮＡＶ期間までチャネル使用を延期する。

ＨＥ ＰＰＤＵを支援する１１ａｘシステムにおいて、ＵＬ ＭＵ ＰＰＤＵがＨＥ−ＳＩＧ Ｂを含まないと、第３のＳＴＡはＵＬ ＭＵ ＰＰＤＵを受信しても、ＵＬ ＭＵ ＰＰＤＵに含まれたＭＰＤＵをデコードすることができない。第３のＳＴＡがＭＰＤＵをデコードできないと、第３のＳＴＡがＭＰＤＵのＭＡＣヘッダーに含まれたＴＸＯＰ Ｄｕｒａｔｉｏｎ情報（例えば、Ｄｕｒａｔｉｏｎフィールド）を取得できない。このため、ＮＡＶ設定／アップデートを正しく行い難いという問題点がある。

ＨＥ−ＳＩＧ Ｂを含むＨＥ ＰＰＤＵフレームが受信されても、ＨＥ−ＳＩＧ Ｂ構造が各ＳＴＡに個別にコードされ、ＳＴＡが自身に割り当てられたＨＥ−ＳＩＧ Ｂコンテンツだけを読めるようにＨＥ−ＳＩＧ Ｂ構造が設計される場合、第３のＳＴＡは、他のＳＴＡが送受信するＭＡＣフレーム（例えば、ＨＥ ＰＰＤＵにおける他のＳＴＡのＭＰＤＵ）をデコードすることができない。このため、この場合にも第３のＳＴＡはＴＸＯＰ情報を取得できないという問題点がある。

● ＨＥ−ＳＩＧ Ａを用いたＴＸＯＰ Ｄｕｒａｔｉｏｎの指示

このような問題点を解決するために、ＳＴＡがＴＸＯＰ ｄｕｒａｔｉｏｎ情報をＨＥ−ＳＩＧ Ａに含めて送信する方法を提案する。上述したように、ＭＡＣヘッダーのｄｕｒａｔｉｏｎフィールドのうち１５ビット（例えば、Ｂ０〜１４）がｄｕｒａｔｉｏｎ情報を示し、最大で約３２．７ｍｓ（０〜３２７６７ｕｓ）を示すことができる。ＭＡＣヘッダーのｄｕｒａｔｉｏｎフィールドに含まれた１５ビットのｄｕｒａｔｉｏｎ情報をそのままＨＥ−ＳＩＧ Ａに含めて送信する場合、１１ａｘ ｔｈｉｒｄ ｐａｒｔｙ ＳＴＡが正しくＮＡＶ設定／アップデートをすることはできるが、ＨＥ−ＳＩＧ Ａのシグナリングオーバーヘッドが過度に増加するという問題点がある。ＭＡＣ層においてペイロード伝送のためのＭＰＤＵ内で１５ビットは相対的に小さいサイズといえるが、物理層で共通制御情報伝送のためのＨＥ−ＳＩＧ Ａはコンパクトに設計されたフィールドであることから、ＨＥ−ＳＩＧ Ａ内で１５ビットの増加は相対的に大きいシグナリングオーバーヘッドに該当する。

したがって、本発明の一実施例では、ＨＥ−ＳＩＧ Ａのオーバーヘッドを最小化するＴＸＯＰ ｄｕｒａｔｉｏｎの効率的な指示方法を提案する。また、ＨＥ−ＳＩＧ Ａ内に新しく定義されたＴＸＯＰ ｄｕｒａｔｉｏｎに基づくフレーム送受信動作が提案される。以下、ＭＡＣヘッダーに含まれたｄｕｒａｔｉｏｎフィールドは、便宜上、ＭＡＣ ｄｕｒａｔｉｏｎと呼ぶことができる。

以下の実施例においてＴＸＯＰ ｄｕｒａｔｉｏｎ情報はＨＥ ＳＩＧ Ａに含まれて送信されると仮定するが、本発明の権利範囲はこれに限定されず、他の部分（例えば、Ｌ−ＳＩＧ、ＨＥ−ＳＩＧ Ｂ、ＨＥ−ＳＩＧ Ｃ、…、Ａ−ＭＰＤＵやＭＰＤＵの部分）で送信されてもよい。例えば、ＨＥ−ＳＩＧ ＢでＴＸＯＰ ｄｕｒａｔｉｏｎが送信される場合、ＨＥ−ＳＩＧ Ｂの共通情報（例えば、ｃｏｍｍｏｎ ｐａｒｔ）又はＨＥ−ＳＩＧ Ｂにおいて先頭（又は、末尾）部分に送信されるＳＩＧ Ｂ ｃｏｎｔｅｎｔｓ ｐａｒｔ（例えば、Ｐｅｒ ｕｓｅｒ Ｉｎｆｏ）で送信されてもよい。

以下、ＨＥ ＳＩＧフィールドにおいてＴＸＯＰ ｄｕｒａｔｉｏｎの構造及びこれを指示する実施例について説明する。第３のＳＴＡのＮＡＶに設定された値は、ＴＸＯＰ ｈｏｌｄｅｒ／Ｒｅｓｐｏｎｄｅｒに対するＴＸＯＰ Ｄｕｒａｔｉｏｎと解釈することができる。例えば、Ｄｕｒａｔｉｏｎフィールド値はＴＸＯＰ ｈｏｌｄｅｒ／Ｒｅｓｐｏｎｄｅｒの観点ではフレーム送受信のためのＴＸＯＰであるが、第３のＳＴＡの観点ではＮＡＶ値を意味する。したがって、第３のＳＴＡがＮＡＶを設定／アップデートする動作は、ＴＸＯＰ ｈｏｌｄｅｒ／Ｒｅｓｐｏｎｄｅｒに対するＴＸＯＰ分だけＮＡＶを設定することであるから、第３のＳＴＡがＮＡＶを設定／アップデートする動作は、便宜上、ＴＸＯＰを設定／アップデートする動作と呼ぶこともできる。また、ＴＸＯＰ Ｄｕｒａｔｉｏｎという言葉を、簡略にＤｕｒａｔｉｏｎと呼んだり、又はＴＸＯＰと呼ぶこともできる。ＴＸＯＰ Ｄｕｒａｔｉｏｎは、場合によって、フレーム内でフィールド（例えば、ＨＥ−ＳＩＧ Ａ内のＴＸＯＰ Ｄｕｒａｔｉｏｎフィールド）を示すために用いられたり、又は実際ＴＸＯＰ Ｄｕｒａｔｉｏｎ値を示すために用いられてもよい。

後述する実施例に割り当てられたインデックスは説明の便宜のためのものであって、個別のインデックスを有する実施例を組み合わせて一つの発明を実施してもよく、それぞれを別個の発明として実施してもよい。

ＴＸＯＰ ｄｕｒａｔｉｏｎの実施例１

ＴＸＯＰ ｄｕｒａｔｉｏｎは２^Ｎ−１（又は、２^Ｎ）に設定され得る。便宜上、ＴＸＯＰ ｄｕｒａｔｉｏｎが２^Ｎ−１に設定されたと仮定する。Ｎ値がＨＥ−ＳＩＧ ＡのＴＸＯＰ ｄｕｒａｔｉｏｎフィールドで送信され得る。

例えば、Ｎが４ビットサイズである場合、Ｎは０〜１５の値を有する。したがって、４ビットサイズのＮで示されるＴＸＯＰ ｄｕｒａｔｉｏｎは、０〜３２７６７ｕｓの値を有することができる。これと違い、ＴＸＯＰ ｄｕｒａｔｉｏｎが最大で５ｍｓを示すように設定される場合、Ｎ＝０〜１３の値のみがＴＸＯＰ ｄｕｒａｔｉｏｎを示すために用いられ、Ｎ＝１４及び１５は他の目的で用いられてもよい。

本実施例は、Ｘ＊２^Ｙ−１方式でＴＸＯＰ ｄｕｒａｔｉｏｎを示す方法の一例示（例えば、Ｘ＝１の場合）であり、Ｘ及び／又はＹは様々に変更されてもよい。また、Ｘ及びＹ値をＨＥ−ＳＩＧ Ａフィールドで送信することができる。

ＴＸＯＰ ｄｕｒａｔｉｏｎの実施例２

本発明の一実施例によれば、ＴＸＯＰ ｄｕｒａｔｉｏｎはＸ^Ｙ−１（又は、Ｘ^Ｙ）に設定されてもよい。便宜上、Ｘ^Ｙ−１に設定されたと仮定する。ＳＴＡはＸとＹ値をＴＸＯＰ ｄｕｒａｔｉｏｎフィールド（例えば、ＨＥ−ＳＩＧ Ａ内）で送信することができる。

ＨＥ−ＳＩＧ Ａで送信されるＴＸＯＰ ｄｕｒａｔｉｏｎフィールドが総Ｋビットだと仮定すれば、Ｋビットのうちのｎビット（例えば、前のｎビット）はＸの値を示し、ｍビット（例えば、後のｍビット）はＹの値を示すことができる。ｎビットはＭＳＢ ｎビット又はＬＳＢ ｍビットであってよく、ｍビットはＬＳＢ ｍビット又はＭＳＢ ｍビットであってよい。Ｋ、ｍ、ｎ値は様々に設定され得る。

（ｉ）一例として、Ｋ＝６、ｎ＝３、ｍ＝３と仮定する。Ｘ∈｛２〜９｝の整数であり、Ｙ∈｛０〜７｝の整数であってもよい。この場合、ＴＸＯＰ ｄｕｒａｔｉｏｎ値は０〜４７８２９６８ｕｓを有し得る。

（ｉｉ）他の例として、Ｋ＝５、ｎ＝２、ｍ＝３と仮定する。Ｘ∈｛２〜５｝の整数であり、Ｙ∈｛０〜７｝の整数であってもよい。この場合、ＴＸＯＰ ｄｕｒａｔｉｏｎ値は０〜７８１２４ｕｓを有し得る。これと違い、Ｘ∈｛２，３，５，６｝のうち一つの整数であり、Ｙ∈｛０〜７｝の整数であれば、ＴＸＯＰ ｄｕｒａｔｉｏｎ値は０〜７８１２４ｕｓを有し得る。

（ｉｉｉ）更に他の例として、Ｋ＝４、ｎ＝１、ｍ＝３と仮定する。Ｘ∈｛２，３｝（又は、Ｘ∈｛５，６｝）のうち一つの整数であり、Ｙ∈｛０〜７｝の整数であってもよい。ＴＸＯＰ ｄｕｒａｔｉｏｎ値は０〜２７９９６３ｕｓを有し得る。

仮に、ＴＸＯＰ ｄｕｒａｔｉｏｎフィールド（例えば、ＨＥ−ＳＩＧ Ａ内）で最大Ｐ ｍｓ（例えば、５ｍｓ）まで指示しようとする場合、Ｘ^Ｙ−１≧Ｐ ｍｓ（例えば、５ｍｓ）を満たす（Ｘ，Ｙ）組み合わせの中でＸ^Ｙ−１が最小となる（Ｘ，Ｙ）組み合わせが最大ＴＸＯＰ ｄｕｒａｔｉｏｎ値を指示するために用いられ、残りの（Ｘ，Ｙ）組み合わせは用いられなくてもよい。

本実施例はＺ＊Ｘ^Ｙ−１方式でＴＸＯＰ ｄｕｒａｔｉｏｎを示す方法の一例示であり、Ｘ，Ｙ及び／又はＺは様々に変更されてもよい。

ＴＸＯＰ ｄｕｒａｔｉｏｎの実施例３

本発明の一実施例によれば、ＴＸＯＰ ｄｕｒａｔｉｏｎはＸ＊２^Ｙ−１（又は、Ｘ＊２^Ｙ）に設定されてもよい。ＸとＹ値がＴＸＯＰ ｄｕｒａｔｉｏｎフィールドで送信され得る。

ＨＥ−ＳＩＧ Ａで送信されるＴＸＯＰ ｄｕｒａｔｉｏｎフィールドを総Ｋビットと仮定すれば、Ｋビットのうち、ｎビット（例えば、前のｎビット）はＸの値を示し、ｍビット（例えば、後のｍビット）はＹの値を示すことができる。ｎビットはＭＳＢ ｎビット又はＬＳＢ ｍビットであってよく、ｍビットはＬＳＢ ｍビット又はＭＳＢ ｍビットであってよい。Ｋ、ｍ、ｎ値は様々に設定され得る。

例えば、Ｋ＝６、ｎ＝３、ｍ＝３と仮定する。Ｘ∈｛１，５，１０，２０，３０，４０，５０，６０｝であり、Ｙ∈｛０〜７｝であってよい。この場合、ＴＸＯＰ ｄｕｒａｔｉｏｎ値は０〜７６８０ｕｓを有するだろう。

仮に、ＴＸＯＰ ｄｕｒａｔｉｏｎフィールド（例えば、ＨＥ−ＳＩＧ Ａ内）で最大Ｐ ｍｓ（例えば、５ｍｓ）まで指示しようとする場合、Ｘ＊２^Ｙ−１≧Ｐ ｍｓ（例えば、５ｍｓ）を満たす（Ｘ，Ｙ）組み合わせのうち、Ｘ＊２^Ｙ−１が最小となる（Ｘ，Ｙ）組み合わせが最大ＴＸＯＰ ｄｕｒａｔｉｏｎを示すために用いられ、残りの（Ｘ，Ｙ）組み合わせは用いられなくてもよい。

本実施例は、Ｘ＊Ｚ^Ｙ−１方式でＴＸＯＰ ｄｕｒａｔｉｏｎを示す方法の一例示であり、Ｘ、Ｙ及び／又はＺは様々に変更されてもよい。

ＴＸＯＰ ｄｕｒａｔｉｏｎの実施例４

一実施例によれば、ＴＸＯＰ Ｄｕｒａｔｉｏｎは、１マイクロセカンド（ｕｓ）の代わりに他の単位（例えば、より大きい単位又はシンボル単位）に設定されてもよい。例えば、４ｕｓ、８ｕｓ、１０ｕｓ、１６ｕｓ、３２ｕｓ、５０ｕｓ、６４ｕｓ、１００ｕｓ、１２８ｕｓ、２５６ｕｓ、５００ｕｓ、５１２ｕｓ、１０２４ｕｓ、…などのように、より大きい単位が用いられてもよい。この場合、ＴＸＯＰ ｄｕｒａｔｉｏｎの値はｕｎｉｔ（例えば、６４ｕｓ）＊ｖａｌｕｅ ｏｆ ＴＸＯＰ ｄｕｒａｔｉｏｎ ｆｉｅｌｄと決定されるはずである。例えば、３２ｕｓ単位のとき、ＴＸＯＰ Ｄｕｒａｔｉｏｎ（１）＝３２ｕｓ、ＴＸＯＰ Ｄｕｒａｔｉｏｎ（２）＝６４ｕｓ、ＴＸＯＰ Ｄｕｒａｔｉｏｎ（３）＝９６ｕｓ、…になり得る。

一方、ＴＸＯＰ Ｄｕｒａｔｉｏｎは８ｍｓまで最大値を有することが好ましい。したがって、単一単位（ｕｎｉｔ）が用いられるとき、次のようなＴＸＯＰ Ｄｕｒａｔｉｏｎ ｆｉｅｌｄオプションを考慮することができる。

− オプション１：３２ｕｓ ｕｎｉｔが用いられ、８ビットサイズのＴＸＯＰ Ｄｕｒａｔｉｏｎフィールドが定義される。このとき、最大（ｍａｘｉｍｕｍ）ＴＸＯＰ ｄｕｒａｔｉｏｎ値は８１９２ｕｓであってもよい。

− オプション２：６４ｕｓ ｕｎｉｔが用いられ、７ビットサイズのＴＸＯＰ Ｄｕｒａｔｉｏｎフィールドが定義される。このとき、ｍａｘｉｍｕｍ ＴＸＯＰ ｄｕｒａｔｉｏｎ値は８１９２ｕｓであってもよい。

ＴＸＯＰフィールドのサイズが８ビットよりも少し大きく設定される場合（例えば、９〜１１ビット）、次のようなＴＸＯＰ Ｄｕｒａｔｉｏｎフィールド構造が用いられてもよい。

−オプションＡ−１：１６ｕｓ ｕｎｉｔ、〜３２ｍｓ、１１ビット

−オプションＡ−２：１６ｕｓ ｕｎｉｔ、〜１６ｍｓ、１０ビット

−オプションＡ−３：１６ｕｓ ｕｎｉｔ、〜８ｍｓ、９ビット

−オプションＢ−１：３２ｕｓ ｕｎｉｔ、〜３２ｍｓ、１０ビット

−オプションＢ−２：３２ｕｓ ｕｎｉｔ、〜１６ｍｓ、９ビット

−オプションＣ−１：６４ｕｓ ｕｎｉｔ、〜１６ｍｓ、９ビット

また、一つ以上の単位（ｕｎｉｔ）の組み合わせ（例えば、（１６ｕｓ，５１２ｕｓ）又は（８ｕｓ，１２８ｕｓ）、など）を用いることができる。又は、ｕｓの代わりに１ｘ ｓｙｍｂｏｌ又は４ｘ ｓｙｍｂｏｌ単位が用いられたり、又はＮ＊１ｘ ｓｙｍｂｏｌ、Ｎ＊４ｘ ｓｙｍｂｏｌ単位（Ｎは自然数）で表示されてもよい。

表１は、４ｘ ｓｙｍｂｏｌ単位で示されるＴＸＯＰ Ｄｕｒａｔｉｏｎを例示する。

上述した実施例１／２／３のうちの一つと実施例４との組み合わせでＴＸＯＰ ｄｕｒａｔｉｏｎが示されてもよい。

ＴＸＯＰ ｄｕｒａｔｉｏｎの実施例５

一実施例によれば、ＴＸＯＰ Ｄｕｒａｔｉｏｎフィールドは事前に定義された値を有し得る。例えば、ＴＸＯＰ ｄｕｒａｔｉｏｎフィールドに設定される値（例えば、ＴＸＯＰ ｄｕｒａｔｉｏｎインデックス）と実際ＴＸＯＰ ｄｕｒａｔｉｏｎ値とをマップするテーブルが事前に定義されてもよい。表２は、ＴＸＯＰ ｄｕｒａｔｉｏｎインデックスを例示する。

一実施例によれば、ＴＸＯＰ Ｄｕｒａｔｉｏｎの一部の範囲は第１関数形態で表現され、他の範囲は第２関数形態で表現／構成され得る。例えば、特定値まではＴＸＯＰ Ｄｕｒａｔｉｏｎが指数（ｅｘｐｏｎｅｎｔｉａｌ）関数の形態で増加し、特定値の次からは一様分布（ｕｎｉｆｏｒｍ ｄｉｓｔｒｉｂｕｔｉｏｎ）関数の形態で増加するように設定され得る。

表３は、ＴＸＯＰ Ｄｕｒａｔｉｏｎフィールドが４ビットに設定された場合を例示する。表３を参照すると、３２ｕｓ〜５１２ｕｓ（又は、１０２４ｕｓ）まではＴＸＯＰ Ｄｕｒａｔｉｏｎが指数的に増加し、５１２ｕｓ（１０２４ｕｓ）からは５１２ｕｓ（約０．５ｍｓ）ずつ増加する。

表４は、ＴＸＯＰ Ｄｕｒａｔｉｏｎフィールドが５ビットに設定された場合を例示する。表４を参照すると、３２ｕｓ〜２５６ｕｓ（又は、５１２ｕｓ）まではＴＸＯＰ Ｄｕｒａｔｉｏｎが指数的に増加し、２５６ｕｓ（５１２ｕｓ）からは２５６ｕｓ（約０．２５ｍｓ）ずつ増加する。

ＴＸＯＰ ｄｕｒａｔｉｏｎの実施例６

一実施例によれば、ＴＸＯＰ ＤｕｒａｔｉｏｎはＸビットのサイズのｓｃａｌｉｎｇ ｆａｃｔｏｒとＹビットサイズのｄｕｒａｔｉｏｎ値によって設定されてもよい。例えば、ＴＸＯＰ ｄｕｒａｔｉｏｎ値はＳｃａｌｉｎｇ ｆａｃｔｏｒ（Ｘビット）＊Ｄｕｒａｔｉｏｎ（Ｙビット）に基づいて設定されてもよい。具体的に、ＴＸＯＰ ｄｕｒａｔｉｏｎ＝Ｓｃａｌｉｎｇ ｆａｃｔｏｒ（Ｘビット）＊Ｄｕｒａｔｉｏｎ（Ｙビット）であってもよい。又は、ＴＸＯＰ ｄｕｒａｔｉｏｎ＝Ｓｃａｌｉｎｇ ｆａｃｔｏｒ（Ｘビット）＊Ｄｕｒａｔｉｏｎ（Ｙビット）＋ａであり、ａは所定の定数であってよい（例えば、ａ＝１）。

ＴＸＯＰ ｄｕｒａｔｉｏｎフィールドのサイズはＸ＋Ｙビットに設定され得る。

例えば、Ｄｕｒａｔｉｏｎ値の単位はｓｃａｌｉｎｇ ｆａｃｔｏｒによって１ｕｓ、４ｕｓ、１６ｕｓのうちの一つに設定され得る。Ｙビットの長さは様々に設定されてもよい。

Ｘビットのｓｃａｌｉｎｇ ｆａｃｔｏｒインデックス０は実際ｓｃａｌｉｎｇ ｆａｃｔｏｒ＝０を示すことができる。表５のＣａｓｅ Ａ及びＣａｓｅ Ｂはそれぞれ２ビットサイズのＳｃａｌｉｎｇ ｆａｃｔｏｒの一例を示す。

表６は３ビットサイズのＳｃａｌｉｎｇ ｆａｃｔｏｒの一例を表す。

一方、Ｄｕｒａｔｉｏｎ値は２^Ｙ形態で表現されてもよい。

ＴＸＯＰ ｄｕｒａｔｉｏｎの実施例７

一実施例によれば、ＴＸＯＰ Ｄｕｒａｔｉｏｎは、Ｘビットのサイズのｓｃａｌｉｎｇ ｆａｃｔｏｒ、Ｙビットサイズのｄｕｒａｔｉｏｎ値、Ｚビットサイズのｄｕｒａｔｉｏｎ単位情報を用いて示すことができる。ＴＸＯＰ ｄｕｒａｔｉｏｎは、‘Ｓｃａｌｉｎｇ ｆａｃｔｏｒ（Ｘビット）＊（Ｄｕｒａｔｉｏｎ（Ｙビット） ｕｓ＊Ｄｕｒａｔｉｏｎ ｕｎｉｔ（Ｚビット） ｕｓ）’であってよい。ＴＸＯＰ ｄｕｒａｔｉｏｎ ｆｉｅｌｄのサイズは（Ｘ＋Ｙ＋Ｚ）ビットに設定され得る。

Ｚビットサイズのｄｕｒａｔｉｏｎ単位は、送信されるｄｕｒａｔｉｏｎ情報の単位を示す。例えば、Ｚビットサイズが１ビットのとき、０は４ｕｓ単位を示し、１は１６ｕｓ単位を示すことができ、これに限定されない。

● ＴＸＯＰ Ｔｅｒｍｉｎａｔｉｏｎ／Ｔｒｕｎｃａｔｉｏｎ方案

一方、上述した実施例によれば、ＨＥ−ＳＩＧ ＡのＴＸＯＰ ｄｕｒａｔｉｏｎフィールドは、相対的に大きいｇｒａｎｕｌａｒｉｔｙベースでＴＸＯＰ ｄｕｒａｔｉｏｎが設定され得る。例えば、ＭＡＣヘッダーに含まれるＤｕｒａｔｉｏｎフィールドは１ｕｓ ｇｒａｎｕｌａｒｉｔｙベースで示され、ＨＥ−ＳＩＧ ＡのＴＸＯＰ ｄｕｒａｔｉｏｎフィールドはそれよりより大きいｇｒａｎｕｌａｒｉｔｙベースでＴＸＯＰ ｄｕｒａｔｉｏｎ値を示するように設定されてもよい。

このようにＨＥ−ＳＩＧ ＡのＴＸＯＰ ｄｕｒａｔｉｏｎフィールドによって相対的に大きいｇｒａｎｕｌａｒｉｔｙベースでＴＸＯＰ ｄｕｒａｔｉｏｎが設定されると、実際のフレーム伝送にかかる時間よりも長い時間がＴＸＯＰ ｄｕｒａｔｉｏｎに設定されることがある。このため、他のＳＴＡがＨＥ−ＳＩＧ Ａに基づいて誤ったＮＡＶを設定し、特定時間においてチャネル使用ができない場合があり、チャネル効率性が低下しうる。

このような問題点を解決するために、ＴＸＯＰの早期終了（Ｅａｒｌｙ ｔｅｒｍｉｎａｔｉｏｎ）のための情報を送信することができる。例えば、ＴＸＯＰ ｈｏｌｄｅｒ／ｒｅｓｐｏｎｄｅｒはＴＸＯＰ区間で最後のフレーム（例えば、ＡＣＫ、Ｂｌｏｃｋ ＡＣＫ、Ｍｕｌｔｉ−ＳＴＡ ＢＡ）を送信する際、ＴＸＯＰを早期終了するということを示す情報を最後のフレームに含めて送信することができる。ＴＸＯＰ早期終了（ｔｅｒｍｉｎａｔｉｏｎ）は、ＴＸＯＰ ｔｒｕｎｃａｔｉｏｎと表現したり、又は簡略に（ｅａｒｌｙ）ｔｅｒｍｉｎａｔｉｏｎ／ｔｒｕｎｃａｔｉｏｎと表現してもよい。以下、ＴＸＯＰを終了する方案について説明する。

（１）ＣＦ−ＥＮＤフレームを用いる方案

ＴＸＯＰ ｈｏｌｄｅｒ／ｒｅｓｐｏｎｄｅｒはＴＸＯＰ区間で最後のフレームを送信した後、ＣＦ−ＥＮＤフレームを送信することによってＴＸＯＰを終了（ｔｅｒｍｉｎａｔｉｏｎ）することができる。

（２）早期終了指示子（Ｅａｒｌｙ ｔｅｒｍｉｎａｔｉｏｎ ｉｎｄｉｃａｔｏｒ）を用いる方案

一実施例によれば、ＳＴＡは早期終了指示子（Ｅａｒｌｙ ｔｅｒｍｉｎａｔｉｏｎ ｉｎｄｉｃａｔｏｒ）をフレームの一部（例えば、ＨＥ−ＳＩＧ Ａ、ＨＥ−ＳＩＧ Ｂのｃｏｍｍｏｎ ｐａｒｔなど）に含めて送信することができる。例えば、ＳＴＡはＥａｒｌｙ ｔｅｒｍｉｎａｔｉｏｎ ｉｎｄｉｃａｔｏｒ＝１に設定すると、ＴＸＯＰが早期終了することを示すことができる。Ｅａｒｌｙ ｔｅｒｍｉｎａｔｉｏｎ ｉｎｄｉｃａｔｏｒ＝１を含むフレーム後に直ちにＴＸＯＰを終了することができる。一方、Ｅａｒｌｙ ｔｅｒｍｉｎａｔｉｏｎ ｉｎｄｉｃａｔｏｒはＤｕｒａｔｉｏｎと組み合わせて用いられてもよい。例えば、Ｅａｒｌｙ ｔｅｒｍｉｎａｔｉｏｎ ｉｎｄｉｃａｔｏｒ＝１であれば、Ｄｕｒａｔｉｏｎが示す時間でＴＸＯＰが終了することを示すことができる。Ｄｕｒａｔｉｏｎ＝０であれば、当該フレーム後にＴＸＯＰが終了し、Ｄｕｒａｔｉｏｎが０以上の値であれば、Ｄｕｒａｔｉｏｎが示す時間にＴＸＯＰが終了し得る。

（ｉ）ＴＸＯＰ早期終了指示子としてＭＤ（Ｍｏｒｅ ｄａｔａ）フィールド又はＥＳＯＰフィールドを再使用することもできる。

（ｉｉ）ＤＬ ｆｒａｍｅの場合、早期終了指示子は、設定されたＴＸＯＰの最後のフレームで送信することができる。例えば、最後のフレームで早期終了指示子と共にＴＸＯＰ Ｄｕｒａｔｉｏｎをアップデートして送信することができる。ＴＸＯＰ Ｄｕｒａｔｉｏｎは、既存のＴＸＯＰ Ｄｕｒａｔｉｏｎより小さい値に設定され、早期終了指示子でＴＸＯＰの終了を示すことができる。

（ｉｉｉ）ＴＸＯＰ情報のアップデートが必要な場合、ＳＴＡ（例えば、ＴＸＯＰ ｈｏｌｄｅｒ／ｒｅｓｐｏｎｄｅｒ）はフレームを送信する際にアップデートされるＴＸＯＰを設定してフレームを送信する。ＴＸＯＰをアップデートするフレームにおいて早期終了指示子（Ｅａｒｌｙ ｔｅｒｍｉｎａｔｉｏｎ ｉｎｄｉｃａｔｏｒ）はＴＸＯＰアップデート指示子として用いられる。例えば、ＴＸＯＰがアップデートされる度に、早期終了指示子＝１に設定して送信することができる。早期終了指示子＝１に設定されたフレームを受信したＳＴＡ（例えば、ｔｈｉｒｄ ｐａｒｔｙ）は、当該ＳＴＡのＴＸＯＰをアップデートする（例えば、ＮＡＶアップデート）。

（ｉｖ）単一フレーム（例えば、ＰＰＤＵ）伝送の場合は、ＴＸＯＰ ｄｕｒａｔｉｏｎがＡＣＫ／ＢＡのサイズに設定され得る。多重フレーム伝送の場合、多重フレーム及びＡＣＫ／ＢＡ伝送のためにＴＸＯＰ ｄｕｒａｔｉｏｎが設定され得る。

（ｖ）ＵＬ ＭＵ伝送：トリガーフレームがｎｏｎ−ＨＴ ＰＰＤＵ（例えば、１１ａ ｆｏｒｍａｔ）で送信される場合、トリガーフレームのコンテンツで正確なＴＸＯＰ ｄｕｒａｔｉｏｎが示されるので、レガシーＳＴＡ（例えば、１１ａｘを支援しないＳＴＡ）であってもＴＸＯＰ ｄｕｒａｔｉｏｎを正しく設定することができる（例えば、ＮＡＶ設定／アップデート）。また、ＵＬ ＭＵフレームではＡＣＫ／ＢＡフレームの伝送長さ分だけＴＸＯＰ ｄｕｒａｔｉｏｎを示すので、ＮＡＶ設定／アップデートは問題にならない。

しかし、１１ａｘ ｆｏｒｍａｔが用いられ、ＨＥ−ＳＩＧ Ａに設定されたＴＸＯＰ ｄｕｒａｔｉｏｎとフレームのコンテンツに含まれたＴＸＯＰ ｄｕｒａｔｉｏｎ情報（例えば、ＭＡＣヘッダーのＴＸＯＰ ｄｕｒａｔｉｏｎ）とが異なる場合は問題になる。例えば、一部のＳＴＡ（例えば、ｔｈｉｒｄ ｐａｒｔｙ）はＨＥ−ＳＩＧ Ａのみを読み、他のＳＴＡ（例えば、ｔｈｉｒｄ ｐａｒｔｙ）はＨＥ−ＳＩＧ Ａ及びフレームコンテンツの両方を読むことがある。

両方を読んだＳＴＡは、フレームコンテンツ（例えば、ＭＡＣ ｈｅａｄｅｒ）のＤｕｒａｔｉｏｎ情報を用いてＴＸＯＰを設定する。例えば、両方を読んだＳＴＡは、ＨＥ−ＳＩＧ Ａに含まれたｄｕｒａｔｉｏｎ情報を持っているが、ＭＡＣヘッダーのＤｕｒａｔｉｏｎ（又は、Ｃｏｎｔｅｎｔｓのｄｕｒａｔｉｏｎ）を読むと、ＳＴＡはＨＥ−ＳＩＧ Ａのｄｕｒａｔｉｏｎの代わりにＭＡＣヘッダーのｄｕｒａｔｉｏｎ（又は、ｃｏｎｔｅｎｔｓのｄｕｒａｔｉｏｎ）に基づいて最終ＴＸＯＰ ｄｕｒａｔｉｏｎを決定してＮＡＶをアップデートする。

ＨＥ−ＳＩＧ Ａのみを読んだＳＴＡは、ＨＥ−ＳＩＧ Ａに含まれたＴＸＯＰ ｄｕｒａｔｉｏｎに基づいてＮＡＶをアップデートする。この場合にも、実際ＭＡＣヘッダーのＴＸＯＰ ｄｕｒａｔｉｏｎよりも長いＴＸＯＰ ｄｕｒａｔｉｏｎ設定が問題になり得る。例えば、ＵＬ ＭＵフレームに対するＡＣＫ／ＢＡ／Ｍ−ＢＡフレームが送信される際、ＳＴＡはＨＥ−ＳＩＧ Ａ／Ｂ又はＭＡＣ ｈｅａｄｅｒに含まれたＴＸＯＰ ｄｕｒａｔｉｏｎ情報を用いてＴＸＯＰをアップデートする（例えば、ＮＡＶアップデート）が、早期終了指示（又は、ＴＸＯＰアップデート指示子）が１に設定されると、ＴＸＯＰを該当の時点で終了できる。

（ｖｉ）一方、ＴＸＯＰの終了（Ｔｅｒｍｉｎａｔｉｏｎ）はＢＳＳ ｃｏｌｏｒに基づいて行われてもよい。例えば、ＳＴＡ（例えば、ｔｈｉｒｄ ｐａｒｔｙ）は自身のＢＳＳ ｃｏｌｏｒに該当するフレームでＴＸＯＰ終了が示された場合にのみ、ＴＸＯＰを終了するように設定されてもよい。ＳＴＡ（例えば、ｔｈｉｒｄ ｐａｒｔｙ）はフレームに含まれたＢＳＳ ｃｏｌｏｒを確認する。仮にＢＳＳ ＣｏｌｏｒがＯｔｈｅｒ ＢＳＳを示すと、当該フレームがＴＸＯＰの終了を示してもＳＴＡ（例えば、ｔｈｉｒｄ ｐａｒｔｙ）はＴＸＯＰを終了させない。したがって、ＳＴＡ（例えば、ｔｈｉｒｄ ｐａｒｔｙ）は自身のＢＳＳのフレームがＴＸＯＰ終了を示す場合（例えば、明示的指示子又はｄｕｒａｔｉｏｎが０に設定される暗黙的指示）にのみ、ＴＸＯＰを終了（ｔｅｒｍｉｎａｔｉｏｎ／ｔｒｕｎｃａｔｉｏｎ）させることができる。ただし、Ｏｔｈｅｒ ＢＳＳに対する当該ＳＴＡのアクセス機会の損失が発生し得ることはある。

（ｖｉｉ）一実施例によれば、ＳＴＡ（例えば、ＴＸＯＰ ｈｏｌｄｅｒ／ｒｅｓｐｏｎｄｅｒ）がＴＸＯＰ内で１１ａｘフレームを送信する際に、最後のフレームには必ずＴＸＯＰ終了（ｔｅｒｍｉｎａｔｉｏｎ／ｔｒｕｎｃａｔｉｏｎ）情報を含めて送信することができる。一方、１１ａフレームの場合にはＭＡＣヘッダーのｄｕｒａｔｉｏｎでＴＸＯＰが設定されるため、正確なＴＸＯＰを設定することができる。一実施例によれば、ＨＥ−ＳＩＧ ＡのＴＸＯＰ ｄｕｒａｔｉｏｎにＭＡＣ ｈｅａｄｅｒのｄｕｒａｔｉｏｎが上書きされてもよい。

（３）最後のフレームのＤｕｒａｔｉｏｎ ｆｉｅｌｄ値を用いる方案

一実施例によれば、ＳＴＡ（例えば、ＴＸＯＰ ｈｏｌｄｅｒ／ｒｅｓｐｏｎｄｅｒ）は、明示的なＴＸＯＰ終了指示子を用いる代わりに、最後のフレームのＤｕｒａｔｉｏｎ ｆｉｅｌｄ値を特定値に設定（例えば、０又は全ビットを１に設定）してＴＸＯＰ早期終了（ｅａｒｌｙ ｔｅｒｍｉｎａｔｉｏｎ／ｔｒｕｎｃａｔｉｏｎ）を示すこともできる。したがって、ＳＴＡ（例えば、ｔｈｉｒｄ ｐａｒｔｙ）がＤｕｒａｔｉｏｎ＝特定値（例えば、０）を示すフレームを受信すると、当該フレーム以降にＴＸＯＰ ｄｕｒａｔｉｏｎが終了（ｔｅｒｍｉｎａｔｉｏｎ ／ｔｒｕｎｃａｔｉｏｎ）したと判断できる。これは、ＣＦ−ＥＮＤフレームに類する役割と理解できる。

（４）ＴＸＯＰ ｄｕｒａｔｉｏｎの終了のためのＮＡＶアップデート／リセット

既存のＮＡＶ設定／アップデート方式によれば、受信されたフレームのＴＸＯＰ Ｄｕｒａｔｉｏｎ値がＳＴＡ（例えば、ｔｈｉｒｄ ｐａｒｔｙ）に現在設定されたＮＡＶ値よりも大きい場合に限ってＮＡＶアップデートが行われた。ＴＸＯＰの早期終了のためには、ＳＴＡに現在設定されたＮＡＶ値に比べて受信されたフレームのＴＸＯＰ ｄｕｒａｔｉｏｎ値が小さい場合にもＮＡＶがアップデートされる必要がある。一実施例によれば、ＳＴＡは上述のＴＸＯＰ終了／アップデート指示子（ｔｒｕｎｃａｔｉｏｎ／ｔｅｒｍｉｎａｔｉｏｎ／ｕｐｄａｔｅ ｉｎｄｉｃａｔｏｒ）に基づいて、ＳＴＡに現在設定されたＮＡＶ値より小さいＴＸＯＰ ｄｕｒａｔｉｏｎでＮＡＶをアップデートすることもできる。ただし、現在設定されたＮＡＶ値より小さいＴＸＯＰ ｄｕｒａｔｉｏｎとしてＮＡＶをアップデートすることは、マイＢＳＳ（ｍｙ ＢＳＳ）フレームに含まれたＴＸＯＰ終了／アップデート指示子のみに基づいて行われるように設定されてもよい。

● ＮＡＶ管理

図２３には既存ＮＡＶ管理方法に伴う問題点を例示する。

レガシー無線ＬＡＮシステム（例えば、１１ａ／ｂ／ｇ／ｎ／ａｃ）においてＳＴＡは１つのＮＡＶを維持する。ＳＴＡはフレーム（例えば、自身を受信者として示していないフレーム）を受信すると、フレームのＭＡＣヘッダー内にｄｕｒａｔｉｏｎフィールド（例えば、ＭＡＣ ｄｕｒａｔｉｏｎ）によって計算されたＮＡＶが自身に設定された現在ＮＡＶより大きいか判断する。ＭＡＣ ｄｕｒａｔｉｏｎによって計算されたＮＡＶが現在ＮＡＶより大きいと、ＳＴＡはＭＡＣ ｄｕｒａｔｉｏｎでＮＡＶをアップデートする。

このように１つのＮＡＶのみを管理するＳＴＡの現在ＮＡＶが０でない時にＳＴＡがＣＦ−ＥＮＤフレームを受信すると、ＳＴＡはＮＡＶをリセット（例えば、ＮＡＶタイマーを０に設定）する。しかし、ＮＡＶリセット以前に当該ＮＡＶが多重のフレームによってアップデートされてきた場合には、ＣＦ−ＥＮＤによるＮＡＶリセットは他のフレーム伝送に影響を及ぼすことがある。

図２３を参照すると、ＡＰ２とＳＴＡ３とが相互フレームを送受信しており、そのためにＳＴＡ２にはＮＡＶが設定されたと仮定する。また、ＡＰ２とＳＴＡ３は互いにフレームを交換する際に、ＡＰ１及びＳＴＡ１に影響を与えないと見なす。例えば、（ＡＰ２，ＳＴＡ３）のチャネルアクセスと（ＡＰ１，ＳＴＡ１）のチャネルアクセスでは相互間に影響がないと仮定する。

したがって、ＡＰ２及びＳＴＡ３がフレーム（例えば、データ／ＡＣＫ）を交換する間にも、ＡＰ１とＳＴＡ１がＲＴＳ、ＣＴＳフレームを交換することができる。例えば、ＡＰ１はＳＴＡ１を受信者と指定してＲＴＳフレームを送信する。ＳＴＡ１はＲＴＳに対する応答としてＣＴＳフレームをＡＰ１に送信する。ＣＴＳフレームのＲＡフィールドはＲＴＳフレームのＴＡフィールドと同一に設定され、ＣＴＳフレームのＤｕｒａｔｉｏｎはＲＴＳフレームのＤｕｒａｔｉｏｎから取得され、ＣＴＳフレームではＴＡフィールドが省略され得る。

ＳＴＡ２はＡＰ１のＲＴＳフレームを受信することはできなかったが、ＳＴＡ１のＣＴＳフレームを受信したと仮定する。ＳＴＡ１のＣＴＳフレームを受信したＳＴＡ２は、自身がＣＴＳフレームの受信者として指定されていないことを把握し、ＣＴＳフレームが示すＤｕｒａｔｉｏｎに基づいてＮＡＶをアップデートする。例えば、ＳＴＡ２の現在ＮＡＶ値よりもＣＴＳフレームが示すＤｕｒａｔｉｏｎが大きいと、ＳＴＡ２はＮＡＶをアップデートする。

ＡＰ２はＳＴＡ３からＡＣＫを受信すると、ＴＸＯＰ ｔｒｕｎｃａｔｉｏｎのためにＣＦ−ＥＮＤフレームを送信する。ＣＦ−ＥＮＤフレームを送信するＡＰ２は、ＳＴＡ２のＮＡＶがＳＴＡ１のＣＴＳフレームによってアップデートされたという事実は分からない。

ＳＴＡ２はＡＰ２から受信したＣＦ−ＥＮＤフレームに基づいて、ＮＡＶをリセットする。例えば、ＳＴＡ２の場合、ＡＰ１／ＳＴＡ１のＴＸＯＰ保護のためにＮＡＶをアップデートしたにもかかわらず、ＡＰ２からＣＦ−ＥＮＤフレームが受信されるとＮＡＶリセットを行う。既存のＮＡＶ管理動作によれば、ＣＦ−ＥＮＤ／ＲＴＳ／ＣＴＳなどの制御フレームが受信されると、ＳＴＡは当該制御フレームのＲＡ（ｒｅｃｅｉｖｅｒ ａｄｄｒｅｓｓ）と自身のアドレスとの同一性を判別する。ＳＴＡのアドレスと一致しないフレームに対してＳＴＡは、ＴＸＯＰ ｈｏｌｄｅｒ／ｒｅｓｐｏｎｄｅｒを問わず１つのＮＡＶを管理する。

ＮＡＶをリセットしたＳＴＡ２はチャネルにアクセス可能なため、ＡＰ２にデータを送信することができる。しかし、ＳＴＡ２のデータフレーム伝送は、ＡＰ１とＳＴＡ１のデータ／ＡＣＫ送受信に影響を及ぼす。

このようにＮＡＶがＴＸＯＰ ｈｏｌｄｅｒ／ｒｅｓｐｏｎｄｅｒ １（例えば、ＡＰ１／ＳＴＡ１）によってアップデートされ、当該ＮＡＶが終了しない状態でＴＸＯＰ ｈｏｌｄｅｒ／ｒｅｓｐｏｎｄｅｒ ２（例えば、ＡＰ２／ＳＴＡ３）によってＮＡＶがリセットされたと仮定すれば、ＮＡＶリセットはＴＸＯＰ ｈｏｌｄｅｒ／ｒｅｓｐｏｎｄｅｒ １のデータ送受信に影響を与えることがある。

上述した既存のＮＡＶ管理動作の問題点を解決するためのＮＡＶ管理（例えば、設定、アップデート及び／又はリセット）方案について説明する。

本発明の一実施例によれば、ＳＴＡはＢＳＳを考慮してＮＡＶを管理することができる。

一例として、ＳＴＡはＢＳＳ ｃｏｌｏｒ別にＮＡＶを設定及び維持することができる。ＢＳＳ ｃｏｌｏｒ別にＮＡＶを設定したＳＴＡは、ＴＸＯＰ ｔｒｕｎｃａｔｉｏｎを示すフレームが受信されると、受信されたフレームが示すＢＳＳ Ｃｏｌｏｒに該当するＮＡＶのＴＸＯＰを切断（ｔｒｕｎｃａｔｉｏｎ）することができる。

また、ＮＡＶ設定及び管理の複雑性を低減するために、ＳＴＡはマイＢＳＳ（ｍｙ ＢＳＳ）ＮＡＶとＯｔｈｅｒ ＢＳＳ ＮＡＶ（例えば、ｍｙ ＢＳＳ以外のＢＳＳ又はｍｙ ＢＳＳを示していないフレーム）の、２種類のＮＡＶを設定及び維持することもできる。マイＢＳＳ ＮＡＶという用語はイントラＢＳＳ ＮＡＶに言い換えてもよい。Ｏｔｈｅｒ ＢＳＳ ＮＡＶという用語はインター（ｉｎｔｅｒ）ＢＳＳ ＮＡＶ又は正規（ｒｅｇｕｌａｒ）ＮＡＶ、又は非−イントラＢＳＳ ＮＡＶに言い換えてもよいが、これに限定されない。

ＮＡＶ管理の実施例１

一実施例によれば、ＳＴＡは、｛ＲＡ（Ｒｅｃｅｉｖｅｒ Ａｄｄｒｅｓｓ）とＴＡ（Ｔｒａｎｓｍｉｔｔｅｒ Ａｄｄｒｅｓｓ）｝との組み合わせ、又は｛ＳＡ（Ｓｏｕｒｃｅ Ａｄｄｒｅｓｓ）とＤＡ（Ｄｅｓｔｉｎａｔｉｏｎ Ａｄｄｒｅｓｓ）｝との組み合わせでＮＡＶを維持／管理することができる。

例えば、ＳＴＡがそれぞれの｛ＲＡ，ＴＡ｝組み合わせを用いてＮＡＶを管理する場合には、異なる｛ＲＡ，ＴＡ｝組み合わせを持つフレームに対しては異なるＮＡＶを維持しなければならない。このような方法は、１１ａｘのように密集した（ｄｅｎｓｅ）環境を考慮すると、ＳＴＡが維持すべきＮＡＶリストが多くなる。このため、ＳＴＡが各ＮＡＶを管理してアップデートする上で複雑度が増加し、１１ａｘでは効率的でないこともある。表７には｛ＲＡ，ＴＡ｝組み合わせによるＮＡＶリストを例示する。例えば、各ＮＡＶは｛ＲＡ，ＴＡ｝組み合わせによってインデックスされる。

ＮＡＶ管理の実施例２

本発明の一実施例によれば、ＳＴＡはＢＳＳ別に（例えば、ＢＳＳＩＤ又はＢＳＳ Ｃｏｌｏｒ別に）、ＮＡＶを維持／管理することができる。

例えば、ＢＳＳＩＤ別にＮＡＶを維持／管理するＳＴＡが、同じＢＳＳＩＤを有する互いに異なるフレームを受信し、これらのフレームのうち、後に受信されたフレームによって示されたｄｕｒａｔｉｏｎ（例えば、ＴＸＯＰ ｄｕｒａｔｉｏｎ及び／又はＭＡＣ ｄｕｒａｔｉｏｎ）が現在ＮＡＶ（例えば、当該ＢＳＳＩＤに対する現在ＮＡＶ）よりも長いと仮定する。ＳＴＡは、当該ＢＳＳＩＤに対するＮＡＶを、受信されたフレームのｄｕｒａｔｉｏｎを用いてアップデートする。

ＢＳＳＩＤを有していないフレーム（例えば、ＡＣＫ又はＣＴＳ）に対しては別のＮＡＶが設定され得る。例えば、ＢＳＳＩＤを有していないフレームに対してＳＴＡは特定ＢＳＳＩＤ値（例えば、実際のＢＳＳＩＤではなくＢＳＳＩＤフォーマットを有する仮想のＢＳＳＩＤ）を用いてＮＡＶを管理することができる。このような特定ＢＳＳＩＤ値は、ＣＴＳフレーム、ＡＣＫフレーム又は（ＣＴＳ＆ＡＣＫ）フレームに対応し得る。したがって、ＳＴＡはＣＦ−ＥＮＤを受信しても、ＣＴＳ／ＡＣＫ／（ＣＴＳ＆ＡＣＫ）に該当するＮＡＶはそのまま維持する。また、ＳＴＡはＣＦ−ＥＮＤを受信すると、ＣＦ−ＥＮＤに含まれたＢＳＳＩＤに該当するＮＡＶのみをリセットすることができる。

表８には、ＢＳＳＩＤに基づいて設定されるＮＡＶを例示する。

表８で、ＣＴＳ＆ＡＣＫに該当するＢＳＳＩＤ（例えば、Ｚ）に対してＮＡＶ（例えば、Ｌ）が設定される場合、ＢＳＳＩＤ Ｘ／ＢＳＳＩＤ Ｙに対するＮＡＶ Ｊ／Ｋは別に設定されなくてもよい。例えば、ＢＳＳＩＤ ＺでインデックスされたＮＡＶ Ｌを用いてＣＴＳ＆ＡＣＫ、ＣＴＳ及びＡＣＫフレームのＴＸＯＰが統合して管理されてもよい。

便宜上、ＡＣＫフレーム及びＣＴＳフレームを例示したが、本発明はこれに限定されず、他の制御フレーム又は管理フレームに対応するＢＳＳＩＤ及び／又はＮＡＶが設定されてもよい。

一方、ＳＴＡはＡＣＫ／ＣＴＳに含まれたＲＡが表８のＮＡＶテーブルのＢＳＳＩＤリストの一つと一致すれば、当該ＢＳＳＩＤに対するＮＡＶを、受信されたＡＣＫ／ＣＴＳフレームのｄｕｒａｔｉｏｎにアップデートし、ＣＴＳ／ＡＣＫ専用ＮＡＶをアップデートしなくてもよい。例えば、ＲＡフィールドに設定されたＢＳＳＩＤ値を有するＢＳＳに対してＮＡＶが存在すると、ＳＴＡは当該ＮＡＶに対するアップデートを優先して行う。しかし、ＲＡフィールドに設定されたＢＳＳＩＤ値を有するＢＳＳに対してＮＡＶが存在しないと、ＣＴＳ／ＡＣＫ専用ＮＡＶをアップデートすることができる。

受信されたフレームにＢＳＳ Ｃｏｌｏｒ情報のみが存在し（例えば、ＢＳＳＩＤ情報が存在しないフレーム）、当該ＢＳＳ ＣｏｌｏｒにマップされたＢＳＳＩＤがあると、ＳＴＡは、マップされた ＢＳＳＩＤを用いてＮＡＶを追加又はアップデートすることができる。仮に、当該ＢＳＳ Ｃｏｌｏｒに対してマップされたＢＳＳＩＤがないと、ＳＴＡは当該ＢＳＳ Ｃｏｌｏｒに対して１つのＢＳＳＩＤを割り当て、それを維持することができる。ＳＴＡがフレームでＢＳＳ ＣｏｌｏｒとＢＳＳＩＤの両方を読むことができると、当該ＢＳＳＩＤに対応するＮＡＶをアップデートすることができる。

表９に、ＢＳＳ ｃｏｌｏｒ別に設定されたＮＡＶを例示する。

ＳＴＡが各ＢＳＳ Ｃｏｌｏｒに対してマップされたＢＳＳＩＤ情報を知っており、ＢＳＳ Ｃｏｌｏｒを含まないフレーム（例えば、１１ａ／ｂ／ｇ／ｎ／１１ａｃ（ＤＬ）などのレガシーフレーム）にＢＳＳＩＤ情報が含まれた場合、当該フレームのｄｕｒａｔｉｏｎを用いてＳＴＡは、ＢＳＳＩＤにマップされた ＢＳＳ Ｃｏｌｏｒに対するＮＡＶを追加又はアップデートする。ＳＴＡは、ＡＣＫ／ＣＴＳのようにＢＳＳ Ｃｏｌｏｒ及びＢＳＳＩＤが含まれないフレームがレガシーＰＰＤＵフォーマットで受信されると、それらのフレームに対しては特定のＢＳＳ Ｃｏｌｏｒ値をマップしてＮＡＶを維持及び管理（例えば、追加及びアップデート）することができる。

本発明の一実施例によれば、ＮＡＶは｛ＢＳＳＩＤ，ＢＳＳ Ｃｏｌｏｒ｝の組み合わせによって管理されてもよい。表１０に｛ＢＳＳＩＤ，ＢＳＳ Ｃｏｌｏｒ｝の組み合わせで識別されるＮＡＶを例示する。

ＮＡＶ管理の実施例３

本発明の一実施例によれば、ＳＴＡは１つのＮＡＶ（例えば、１つのＮＡＶタイマー）を維持し管理することができる。ＳＴＡはＮＡＶをアップデートするとき、ＮＡＶがどれによってアップデートされたかに関する情報を維持することができる。

表１１に、本発明の一実施例によってＮＡＶの最終アップデートに用いられたＩＤを例示する。

ＮＡＶの最終アップデートに用いられたＩＤ（Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ ｕｓｅｄ ｆｏｒ ｕｐｄａｔｉｎｇ ｔｈｅ ｌａｔｅｓｔ ＮＡＶ）を該当のＮＡＶにマップすることができる。ＮＡＶの最終アップデートに用いられたＩＤは、例えば、ＢＳＳ Ｃｏｌｏｒ、ＢＳＳＩＤ、｛ＢＳＳＩＤ，ＢＳＳ Ｃｏｌｏｒ｝、ＲＡ、ＴＡ、ＳＡ、ＤＡ、｛ＲＡ，ＴＡ｝、｛ＲＡ，ＳＡ｝、｛ＤＡ，ＳＡ｝及び｛ＤＡ，ＴＡ｝のうち少なくとも一つであってよく、これに限定されない。

表１２に、｛ＲＡ，ＴＡ｝組み合わせが用いられる場合を例示する。

表１３にはＢＳＳＩＤが用いられる場合を例示する。

仮に、ＳＴＡが該当のＩＤ情報を含まないフレームによってＮＡＶをアップデートする場合、上述したＮＡＶ管理実施例２で言及された方法のうちの一つを用いることができる。例えば、表１３のようにＢＳＳＩＤが用いられ、ＡＣＫ／ＣＴＳフレームにＢＳＳＩＤ（又は、ＢＳＳＩＤにマップされた情報）がないと、ＳＴＡはＡＣＫ／ＣＴＳフレームに特定ＢＳＳＩＤ（例えば、仮想のＢＳＳＩＤ）をマップしてＮＡＶアップデートを行うことができる。例えば、ＡＣＫ／ＣＴＳ用ＢＳＳＩＤがＸであるとシステムにおいて定められ、ＳＴＡがＡＣＫやＣＴＳを受信すると、ＮＡＶテーブルのＮＡＶの最終アップデートに用いられたＩＤ（例えば、ＢＳＳＩＤ項目）をＸにアップデートすることができる。

このようにＮＡＶに対応するＩＤがＮＡＶと共に維持され、ＳＴＡが、ＴＸＯＰ ｔｒｕｎｃａｔｉｏｎを示すフレーム（例えば、ＣＦ−ＥＮＤ）を受信すると、ＳＴＡはフレームのＩＤ情報（例えば、ＲＡ、ＴＡ、ＢＳＳ Ｃｏｌｏｒ、ＢＳＳＩＤなど）のうちの一つがＮＡＶに対応するＩＤと一致する場合にのみ、ＴＸＯＰを切断（ｔｒｕｎｃａｔｉｏｎ）することができる。例えば、表１３のようにＢＳＳＩＤに基づいてＮＡＶが管理されるとき、ＳＴＡはＣＦ−ＥＮＤフレームが現在ＮＡＶのＢＳＳＩＤに該当する情報を含む場合に限ってＴＸＯＰを切断することができる。仮に、現在ＮＡＶのＢＳＳＩＤに該当する情報がＣＦ−ＥＮＤフレームに含まれていない場合、ＳＴＡはＴＸＯＰを切断させなくてもよい。

本発明の実施例のために、ＳＴＡは、送信されるフレームをオーバーヒヤリングすることによって、｛ＢＳＳ Ｃｏｌｏｒ，ＢＳＳＩＤ｝のリストを維持することもできる。ＢＳＳ Ｃｏｌｏｒのみを含んだり又はＢＳＳＩＤのみを含むフレームが受信されると、ＳＴＡは、｛ＢＳＳ Ｃｏｌｏｒ，ＢＳＳＩＤ｝リストを用いてＢＳＳ Ｃｏｌｏｒに対応するＢＳＳＩＤ又はＢＳＳＩＤに対応するＢＳＳ Ｃｏｌｏｒ情報を取得することもできる。

表１４は、｛ＢＳＳＩＤ，ＢＳＳ Ｃｏｌｏｒ｝の組み合わせが用いられる場合を例示する。

ＳＴＡは、マイＢＳＳＩＤに対するＢＳＳ Ｃｏｌｏｒを様々な方法（例えば、ビーコン、プローブ応答などの管理フレーム）を用いて取得することができる。したがって、ＳＴＡは、マイＢＳＳで送信されたフレームを受信した場合、当該フレームがレガシーＰＰＤＵか或いはＨＥ（すなわち、１１ａｘ）ＰＰＤＵかを問わず、ＢＳＳ ＣｏｌｏｒとＢＳＳＩＤを共にアップデートすることができる。例えば、ＳＴＡがマイＢＳＳ Ｃｏｌｏｒを含む１１ａｘ ＰＰＤＵを受信した場合、ＮＡＶをアップデートする際にＢＳＳ Ｃｏｌｏｒ及びマイＢＳＳＩＤを共にアップデートすることができる。ＳＴＡがマイＢＳＳＩＤ情報を含むレガシーＰＰＤＵを受信した場合、ＮＡＶをアップデートする際にＢＳＳＩＤ及びＢＳＳ Ｃｏｌｏｒを共にアップデートすることができる。

ＳＴＡがＴＸＯＰ Ｔｒｕｎｃａｔｉｏｎを示すフレーム（例えば、ＣＦ−ＥＮＤ、ｄｕｒａｔｉｏｎ＝０であるフレームなど）を受信し、当該フレームに含まれた情報（例えば、ＢＳＳ Ｃｏｌｏｒ、ＢＳＳＩＤ、ＴＡ、ＲＡなど）のうちの一つ以上が現在ＮＡＶにマップされたＢＳＳＩＤ又はＢＳＳ Ｃｏｌｏｒに一致すると、ＳＴＡはＮＡＶを切断することができる。フレームに含まれた情報と現在ＮＡＶにマップされたＢＳＳＩＤ／ＢＳＳ ｃｏｌｏｒとが一致しないと、ＳＴＡは当該ＮＡＶを切断しなくてもよい。

仮に、ＳＴＡに｛ＢＳＳＩＤ，ＢＳＳ Ｃｏｌｏｒ｝リストがない場合に、Ｏｔｈｅｒ ＢＳＳのフレームを受信したり又は１１ａｘ ＰＰＤＵに対してＢＳＳ Ｃｏｌｏｒのみを取得すると、ＳＴＡは、ＮＡＶにマップされるＢＳＳＩＤを０に設定することができる。また、ｌｅｇａｃｙ ＰＰＤＵが受信され、ＳＴＡがＢＳＳ Ｃｏｌｏｒ無しでＢＳＳＩＤのみを取得した場合、ＮＡＶにマップされるＢＳＳ Ｃｏｌｏｒを０に設定することもできる。

ＳＴＡが制御フレームを受信し、制御フレームがマイＢＳＳ ＣｏｌｏｒやマイＢＳＳＩＤのうちの一つ以上と一致する情報を含むと、ＳＴＡは、ＮＡＶにマップされた｛ＢＳＳＩＤ，ＢＳＳ Ｃｏｌｏｒ｝情報をＮＡＶと共にアップデートすることができる。

仮に、制御フレーム内でＮＡＶにマップされた｛ＢＳＳＩＤ，ＢＳＳ Ｃｏｌｏｒ｝と一致する情報がない場合（例えば、ｏｔｈｅｒ ＢＳＳ制御フレーム）、ＳＴＡは、当該制御フレームに対してはＮＡＶに｛ＲＡ，ＴＡ｝組み合わせをマップすることができる。その後、ＴＸＯＰ Ｔｒｕｎｃａｔｉｏｎを示すフレームが受信され、当該フレームがＮＡＶにマップされたＩＤ情報（例えば、｛ＢＳＳ Ｃｏｌｏｒ，ＢＳＳＩＤ｝又は｛ＲＡ，ＴＡ｝）と一致するＩＤ情報を含むと、ＳＴＡはＴＸＯＰを切断することができる。仮に、受信されたフレームがＮＡＶにマップされたＩＤ情報を含まないと、ＳＴＡはＴＸＯＰを切断させなくてもよい。

一方、ＳＴＡはＮＡＶにマップされたＩＤが｛ＢＳＳ Ｃｏｌｏｒ，ＢＳＳＩＤ｝組み合わせか、或いは｛ＲＡ，ＴＡ｝組み合わせかを示すＩＤ Ｔｙｐｅ情報を当該ＮＡＶにマップすることもできる。ＳＴＡはＩＤ Ｔｙｐｅから、如何なるＩＤがＮＡＶにマップされたかを把握することができる。表１５に、一実施例によるＩＤタイプ情報を例示する。

ＮＡＶ管理の実施例４

本発明の一実施例によれば、ＳＴＡはＴＸＯＰを開始（ｉｎｉｔｉａｔｉｏｎ）するフレームを受信すると、ＴＸＯＰ ｈｏｌｄｅｒアドレスを保存することができる。

例えば、ＲＴＳフレームではＴＡ（Ａｄｄｒｅｓｓ ２、Ｔｒａｎｓｍｉｔｔｅｒ ａｄｄｒｅｓｓ）がＴＸＯＰ ｈｏｌｄｅｒアドレスを示し、ＣＴＳではＲＡ（Ａｄｄｒｅｓｓ １、Ｒｅｃｅｉｖｅｒ ａｄｄｒｅｓｓ）がＴＸＯＰ ｈｏｌｄｅｒアドレス
を示す。

ＳＴＡは該当のフレームに基づいてＮＡＶをアップデートしながら、ＴＸＯＰ ｈｏｌｄｅｒアドレスを共に保存することができる。その後、ＴＸＯＰ ｔｒｕｎｃａｔｉｏｎを示すＣＦ−ＥＮＤフレームが受信されると、ＳＴＡはＣＦ−ＥｎｄのＴＡとＮＡＶにマップされたＴＸＯＰ ｈｏｌｄｅｒアドレスとを比較する。仮に、ＣＦ−ＥＮＤフレームのＴＡがＮＡＶにマップされたＴＸＯＰ ｈｏｌｄｅｒアドレスと一致すると、ＳＴＡはＴＸＯＰ ｔｒｕｎｃａｔｉｏｎを行う。しかし、Ｆ−ＥＮＤフレームのＴＡがＮＡＶにマップされたＴＸＯＰ ｈｏｌｄｅｒアドレスと一致しないと、ＳＴＡはＮＡＶをそのまま維持することができる。

一方、本発明の一実施例によれば、ＳＴＡはＮＡＶアップデート前のＮＡＶ情報を維持することができる。ＮＡＶアップデートされる前に、ＮＡＶ情報は、例えば、アップデート前のＮＡＶ値及びアップデート前のＴＸＯＰ ｈｏｌｄｅｒの情報のうち少なくとも一つを含むことができる。

例えば、ＳＴＡは、現在ＮＡＶに対するＴＸＯＰ Ｈｏｌｄｅｒアドレスのみを維持するのではなく、以前ＮＡＶ値及び以前ＮＡＶに対するＴＸＯＰ Ｈｏｌｄｅｒアドレスを維持することもできる。ＳＴＡは以前ＮＡＶ値を維持するために、ＮＡＶ ｕｐｄａｔｅ時に以前ＮＡＶタイマーを保存したり、又は以前ＮＡＶ値を計算できる情報としてＮＡＶ差値（ＮＡＶ ｄｉｆｆｅｒｅｎｃｅ ｖａｌｕｅ）を保存することができる。例えば、フレームを受信してＮＡＶをアップデートするとき、ＳＴＡは｛当該フレームで示されたＤｕｒａｔｉｏｎ−現在のＮＡＶ値｝をＮＡＶ差値として保存することができる。

その後、ＣＦ−Ｅｎｄフレームが受信され、ＣＦ−ＥｎｄフレームのＴＡと現在ＮＡＶのＴＸＯＰホルダーアドレスとが一致すれば、ＳＴＡはＮＡＶをリセットする代わりに、以前ＮＡＶのＴＸＯＰ ｈｏｌｄｅｒアドレスとＣＦ−ＥｎｄフレームのＴＡとを比較する。以前ＮＡＶのＴＸＯＰ ｈｏｌｄｅｒアドレスとＣＦ−ＥｎｄフレームのＴＡとが一致すれば、ＳＴＡはＮＡＶをリセットする。しかし、以前ＮＡＶのＴＸＯＰ ｈｏｌｄｅｒアドレスとＣＦ−ＥｎｄフレームのＴＡとが一致しないと、現在ＮＡＶをリセットせず、以前ＮＡＶ値を復元する（例えば、ＮＡＶ差値を利用）。ＣＦ−ＥｎｄフレームのＴＡが現在ＮＡＶのＴＸＯＰ ｈｏｌｄｅｒアドレスと一致しないと、ＳＴＡは現在ＮＡＶを維持する。

一実施例によれば、ＳＴＡがＴＸＯＰを開始（ｉｎｉｔｉａｔｉｏｎ）するフレームを受信し、ＴＸＯＰ ｈｏｌｄｅｒアドレスを保存することは、当該ＳＴＡがアソシエーション（ａｓｓｏｃｉａｔｉｏｎ）しているＢＳＳのＴＸＯＰ ｈｏｌｄｅｒのアドレスに限定されてもよい。または、ＳＴＡは、自身がアソシエーションしているＡＰのアドレスのみをＴＸＯＰ ｈｏｌｄｅｒアドレスとして保存することに限定されてもよい。例えば、ＡＰがＲＴＳのようなＴＸＯＰを開始（ｉｎｉｔｉａｔｉｏｎ）するフレームを送信した時、ＴＸＯＰ ｈｏｌｄｅｒアドレスはＴＡ（Ａｄｄｒｅｓｓ ２）である。ＳＴＡによって送信されたＣＴＳの場合、ＡＰのＲＡ（Ａｄｄｒｅｓｓ １，ＡＰ ａｄｄｒｅｓｓ）がＴＸＯＰ ｈｏｌｄｅｒアドレスである。

上述したように、ＳＴＡ（例えば、ＡＰ ｏｒ ｎｏｎ−ＡＰ ＳＴＡ）は、フレームを受信した時、ＴＸＯＰ ｈｏｌｄｅｒ ａｄｄｒｅｓｓ（又は、ＳＴＡがアソシエーションしているＴＸＯＰ ｈｏｌｄｅｒのａｄｄｒｅｓｓ）及び／又はＢＳＳ ｃｏｌｏｒ（ＳＴＡがアソシエーションしているＢＳＳのＣｏｌｏｒ）を保存することができる。例えば、ＳＴＡがアソシエーションしているＢＳＳからフレームを受信した場合、ＳＴＡは、当該ＢＳＳの｛ＴＸＯＰ ｈｏｌｄｅｒ ａｄｄｒｅｓｓ，ＢＳＳ Ｃｏｌｏｒ｝を保存することができる。仮に、ＢＳＳ ｃｏｌｏｒがないフレーム（例えば、ＲＴＳ／ＣＴＳ／Ｔｒｉｇｇｅｒ ｆｒａｍｅ／ＡＣＫ／Ｂｌｏｃｋ ＡＣＫなどのように、ＢＳＳ ｃｏｌｏｒのないｌｅｇａｃｙ ＰＰＤＵで送信されるフレーム）が受信され、当該フレームに含まれたＴＸＯＰ ｈｏｌｄｅｒ ａｄｄｒｅｓｓが、自身がアソシエーションしているＡＰのＭＡＣ ａｄｄｒｅｓｓと一致すれば、ＳＴＡは自身が事前に知っている当該ＡＰに対するＢＳＳ ＣｏｌｏｒをＴＸＯＰ ｈｏｌｄｅｒ ａｄｄｒｅｓｓと共に保存することができる。

受信されたＭＵ−ＲＴＳ／ＲＴＳフレームのＲＡに自身のａｄｄｒｅｓｓ／ＩＤ（例えば、ＡＩＤ又はＰａｒｔｉａｌ ＡＩＤ）がなく、ＴＡに自身がアソシエーションしているＢＳＳのＴＸＯＰ ｈｏｌｄｅｒ ａｄｄｒｅｓｓが含まれていると、ＳＴＡはＮＡＶ値と共に｛ＴＸＯＰ ｈｏｌｄｅｒ ａｄｄｒｅｓｓ，ＢＳＳ ｃｏｌｏｒ｝を保存する。ＳＴＡは、ＭＵ−ＲＴＳ／ＲＴＳによって設定されたＮＡＶをリセットせねばならない場合、ＢＳＳ Ｃｏｌｏｒを確認してＮＡＶリセットを行うことができる。

ＮＡＶ管理の実施例５

既存のＮＡＶアップデート方式によれば、ＯＢＳＳ（ｏｔｈｅｒ ＢＳＳ）フレームによってＮＡＶが設定された後、マイＢＳＳフレームが受信され、マイＢＳＳフレームのＮＡＶ値が現在ＮＡＶ値（例えば、ＯＢＳＳフレームによって設定されたＮＡＶ）より大きいと、ＳＴＡはマイＢＳＳフレームに基づいてＮＡＶをアップデートする。例えば、ＳＴＡがＮＡＶアップデート（例えば、変更、リセット、取消など）を要求するフレーム（例えば、ＣＦ−Ｅｎｄ／トリガーフレーム／ＣＴＳ／ＡＣＫ／ＢＡなど）をマイＢＳＳのＳＴＡ／ＡＰから受信すると、ＳＴＡは当該フレームを受信してＮＡＶをアップデートする。

図２４に、ＵＬ ＭＵ伝送に関連した既存のＮＡＶ管理を例示する。ＳＴＡ １，２，３はＡＰにアソシエーション（ａｓｓｏｃｉａｔｉｏｎ）しており、ＳＴＡ３はＯＢＳＳフレームを受信してＮＡＶを設定した状態でマイＡＰが送信するＴＦ（Ｔｒｉｇｇｅｒ ｆｒａｍｅ）１を受信したと仮定する。

図２４を参照すると、ＴＦ１にはＳＴＡ３に関するリソース割り当て情報がないため、ＴＦ１のｄｕｒａｔｉｏｎ値がＳＴＡ３に設定された現在ＮＡＶより大きいと、ＳＴＡ３はＴＦ１のｄｕｒａｔｉｏｎ値を用いてＮＡＶをアップデートする。

その後、マイＡＰがＴＦ２を送信してＳＴＡ３にＵＬリソースを割り当てる。ＳＴＡ３にはマイＢＳＳによってＮＡＶが設定されているため、ＳＴＡ３はＮＡＶを無視してＵＬ伝送を行うことができる。しかし、このようなＳＴＡ３のＵＬ伝送はＯＢＳＳに影響を与えることがある。

（１）ＮＡＶ管理実施例５−１：ＮＡＶ差値

このような問題を解決するための一方法として、ＯＢＳＳ ＮＡＶ差値を用いる方案を考慮することができる。ＯＢＳＳ ＮＡＶ差値は簡略にＮＡＶ差値と呼ぶこともできる。

例えば、ＳＴＡは一つのＮＡＶタイマーを維持するが、ＯＢＳＳフレームによって設定されたＮＡＶをマイＢＳＳフレームに基づいてアップデートする時、ＳＴＡはＯＢＳＳ ＮＡＶ差値を計算して保存することができる。ＯＢＳＳ ＮＡＶ差値は、｛受信されたマイＢＳＳフレームのＮＡＶタイマー−現在ＮＡＶタイマー（例えば、ＯＢＳＳによって最後にアップデートされたＮＡＶタイマー）｝のように計算することができる。

ＯＢＳＳ ＮＡＶ差値を保存したＳＴＡは、マイＢＳＳフレームによってＮＡＶがアップデートされる時（例えば、現在ＮＡＶがリセットされるか、マイＡＰから受信されたトリガーフレームの指示によって現在ＮＡＶが無視されたり又は考慮されないとき）、ＮＡＶ差値を用いて現在時点でＯＢＳＳ ＮＡＶが有効か否かを判断できる。

仮に、ＯＢＳＳ ＮＡＶが有効であれば、ＳＴＡはＯＢＳＳ ＮＡＶを考慮する（例えば、ＯＢＳＳ ＮＡＶが終了するまでチャネルアクセスを保留）。ＳＴＡは現在時点で｛現在ＮＡＶタイマー−ＮＡＶ差値｝を計算してＯＢＳＳ ＮＡＶが有効か否かをチェックすることができる。例えば、｛現在ＮＡＶタイマー− ＮＡＶ差値｝がＯＢＳＳ ＮＡＶ有効閾値（例えば、０）より大きいと、ＳＴＡはＯＢＳＳ ＮＡＶが有効だと判断できる。仮に、｛現在ＮＡＶタイマー−ＮＡＶ差値｝が０より小さい又は等しいと、ＳＴＡはＯＢＳＳ ＮＡＶが有効でないと判断できる。ＳＴＡは、ＯＢＳＳ ＮＡＶが有効でないと、ＮＡＶ差値をそれ以上維持しないか、又は０に設定することができる。また、ＳＴＡは、ＮＡＶ差値がないか或いは０に設定されていると、ＯＢＳＳ ＮＡＶを考慮しないでチャネルアクセスを行うことができる。ＳＴＡがＮＡＶを考慮する場合には、チャネルが混雑（ｂｕｓｙ）していると仮定してフレーム伝送を試みないことを意味することができる。

ＳＴＡに保存されたＮＡＶ差値は、マイＢＳＳフレームによってＮＡＶアップデートがなかったらＳＴＡに維持されるはずだったＯＢＳＳ ＮＡＶタイマーが現在時点で満了したか、或いは残余時間があるかを判断するために用いることができる。

図２５は、ＮＡＶ差値を用いてＮＡＶを管理する方法を例示する。

図２５を参照すると、ＳＴＡ３は、ＯＢＳＳによって設定されたＮＡＶを維持しているが、マイＢＳＳ（又は、イントラＢＳＳ） ＳＴＡであるＡＰからＴＦ１を受信する。ＳＴＡ３は、ＴＦ１のＮＡＶ（例えば、ｄｕｒａｔｉｏｎ）が現在ＮＡＶ（例えば、ＯＢＳＳ ＮＡＶ）より大きいと、ＴＦ１に基づいて自身のＮＡＶをアップデートする。この時、ＳＴＡ３はＮＡＶ差値（例えば、ＴＦ１のｄｕｒａｔｉｏｎ値−現在ＮＡＶタイマー）を計算して保存することができる。

ＳＴＡ３のスケジューリング情報が含まれたＴＦ２が受信されると、ＳＴＡ３は、ＴＦ２に基づく伝送を行う前に、ＯＢＳＳ ＮＡＶが有効であるか検査する。例えば｛現在ＮＡＶタイマー−ＮＡＶ差値｝がＯＢＳＳ ＮＡＶ有効閾値（例えば、０）を超えると、ＳＴＡ３は、ＯＢＳＳ ＮＡＶが有効だと見なすことができる。ＯＢＳＳ ＮＡＶが有効である間に、ＳＴＡ３はＴＦ２に基づくフレーム伝送を保留することができる。

一方、ＯＢＳＳ ＮＡＶ差値は、ＮＡＶがマイＢＳＳのフレーム（例えば、イントラＢＳＳフレーム）によってアップデートされる時、有効でなくてもよい。

図２６に、マイＢＳＳのフレームに基づくＮＡＶアップデートを例示する。

図２６を参照すると、ＳＴＡ３は、ＯＢＳＳフレームによって設定されたＮＡＶをＴＦ１（例えば、ＳＴＡ３がアソシエーションしているＡＰから受信）を用いてアップデートする。ＳＴＡ３はＴＦ１を用いてＮＡＶをアップデートする際に、ＮＡＶ差値（例えば、受信されたフレームのｄｕｒａｔｉｏｎによるＮＡＶ値−現在ＮＡＶ値）を計算及び保存することができる。

ＳＴＡ３はＴＦ２を受信してＮＡＶをアップデートする。

ＳＴＡ３がＴＦ３でＵＬリソース割り当てを受けると、ＳＴＡ３はＮＡＶ差値を用いてＯＢＳＳ ＮＡＶが有効か否か検査する。しかし、ＮＡＶ差値は以前ＮＡＶ（例えば、ＴＦ１）に基づいて計算されたものであるため、ＳＴＡ３に保存されたＮＡＶ差値はＴＦ３を受信した時点では不正確な値になり得、ＯＢＳＳ ＮＡＶの有効性検査に適合しないことがある。

（２）ＮＡＶ管理実施例５−２：ＮＡＶ差値のアップデート

上述した問題点を解決するための一方法として、ＳＴＡのＮＡＶがアップデートされる時、ＳＴＡはＮＡＶ差値も共にアップデートすることができる。

例えば、ＳＴＡはＮＡＶをアップデートする時、ＮＡＶ差値を用いてＯＢＳＳ ＮＡＶが有効か否かを検査する。例えば、｛現在ＮＡＶ値−ＮＡＶ差値｝を計算した結果がＯＢＳＳ ＮＡＶ有効閾値（例えば、デフォルト値は０）を超えると、ＳＴＡはＯＢＳＳ ＮＡＶが有効だと見なす。

ＯＢＳＳ ＮＡＶが有効でなければ、ＳＴＡはＮＡＶ差値を０に設定できる。例えば、ＯＢＳＳ ＮＡＶ差値＝０は、ＯＢＳＳ ＮＡＶが有効でないことを示すことができる。

ＯＢＳＳ ＮＡＶが有効であれば、ＳＴＡはＮＡＶ差値をアップデートすることができる。ＳＴＡはＮＡＶアップデートに用いられる該当のフレームのｄｕｒａｔｉｏｎを用いてＮＡＶ差値をアップデートすることができる。例えば、ＳＴＡは｛該当のフレームによるＮＡＶ値（例えば、ｄｕｒａｔｉｏｎ）−（現在ＮＡＶ値−ＮＡＶ差値）｝の値にＮＡＶ差値をアップデートし、自身のＮＡＶもアップデートすることができる。

図２７は、ＮＡＶ差値のアップデートを例示する。ＴＦ１受信前にＳＴＡ３はＯＢＳＳフレームによってアップデートされたＮＡＶを有すると仮定する。

ＳＴＡ３は自身のＡＰからＴＦ１を受信し、ＮＡＶをアップデートする。ＳＴＡ３は、ＴＦ１のｄｕｒａｔｉｏｎを用いてＮＡＶをアップデートする前に、ＳＴＡ３はＮＡＶ差値を計算して保存する。

ＳＴＡ３はＴＦ２を受信してＮＡＶアップデートを行う際に、ＯＢＳＳ ＮＡＶが有効か否か検査する。ＯＢＳＳ ＮＡＶが有効であれば、ＳＴＡ３はＮＡＶ差値を現在受信されたフレーム（例えば、ＴＦ２）のｄｕｒａｔｉｏｎに基づいてアップデートすることができる。例えば、ＮＡＶ差値を｛受信されたフレームによるＮＡＶ値−（現在ＮＡＶ値−保存されたＮＡＶ差値）｝にアップデートすることができる。続いて、ＳＴＡ３は、ＴＦ２を用いてＮＡＶをアップデートすることができる。

ＳＴＡ３に対するＵＬリソース割り当てを含むＴＦ３が受信されると、ＳＴＡ３はＮＡＶ差値を用いてＯＢＳＳ ＮＡＶが有効か否かを検査する。便宜上、ＯＢＳＳ ＮＡＶが有効でないと仮定する。したがって、ＳＴＡ３はＴＦ３に応答してＵＬ ＭＵフレームを送信する。

一方、ＮＡＶ差値のアップデートは、ＯＢＳＳ ＮＡＶが更に他のＯＢＳＳフレームによってアップデートされる時にも行うことができる。例えば、ＳＴＡがＯＢＳＳフレームを受信しており、現在ＯＢＳＳ ＮＡＶが有効だと仮定する。ＳＴＡは、ＮＡＶ差値を用いて、受信されたＯＢＳＳフレームによるＮＡＶ値が現在ＯＢＳＳ ＮＡＶ（＝現在ＮＡＶ値−保存されたＮＡＶ差値）より大きいか確認する。

受信されたＯＢＳＳフレームによるＮＡＶ値が現在ＯＢＳＳ ＮＡＶより大きいと、ＳＴＡはＮＡＶ差値を｛現在ＮＡＶ値−受信されたＯＢＳＳフレームによるＮＡＶ値｝にアップデートする。この時、ＳＴＡは自身のＮＡＶ（例えば、現在ＮＡＶ値）をそのまま維持することができる。このようなＮＡＶ差値のアップデートは、ＳＴＡが受信されたＯＢＳＳフレームによって現在のＮＡＶはアップデートせず、ＯＢＳＳ ＮＡＶをアップデートするためである。

図２８に、本発明の他の実施例に係るＮＡＶ差値のアップデートを例示する。ＳＴＡ３は、ＯＢＳＳフレーム１によってＮＡＶをアップデートしており、その後、自身のＡＰからＴＦ１を受信してＮＡＶをアップデートすると仮定する。

ＳＴＡ３は、ＴＦ１のｄｕｒａｔｉｏｎを用いてＮＡＶをアップデートする前に、ＮＡＶ差値を計算する。例えば、ＮＡＶ差値は｛受信されたフレームによるＮＡＶ（すなわち、フレームのｄｕｒａｔｉｏｎ値）−現在ＮＡＶタイマー｝であってもよい。ＳＴＡは、計算されたＮＡＶ差値を保存する。

ＳＴＡ３はＴＦ２を受信するが、ＮＡＶアップデートは行われず、よって、現在ＮＡＶタイマーが維持されると仮定する。

その後、ＳＴＡ３は、ＯＢＳＳ ＳＴＡからＯＢＳＳフレーム２を受信し、ＯＢＳＳ ＮＡＶが有効か否か検査する。ＯＢＳＳ ＮＡＶが有効だと仮定する。ＳＴＡ３は、受信されたＯＢＳＳフレーム２によるＮＡＶ（例えば、ｄｕｒａｔｉｏｎ）がＯＢＳＳ ＮＡＶより大きいか確認する。

ＯＢＳＳフレーム２によるＮＡＶがＯＢＳＳ ＮＡＶより大きい場合、ＳＴＡ３はＯＢＳＳフレームのｄｕｒａｔｉｏｎを用いてＮＡＶ差値を再び計算する（例えば、アップデート）。例えば、ＳＴＡ３はＮＡＶ差値を｛現在ＮＡＶタイマー−ＯＢＳＳフレーム２によるＯＢＳＳ ＮＡＶ｝で計算し、ＳＴＡ３は計算されたＮＡＶ差値を保存することができる。

その後、ＳＴＡ３はＴＦ３を受信し、ＴＦ３によってＵＬリソースが割り当てられる。ＳＴＡ３は、ＵＬ伝送を行う前に、ＮＡＶ差値を用いてＯＢＳＳ ＮＡＶが有効かを検査する。便宜上、ＯＢＳＳ ＮＡＶが有効だと仮定する。したがって、ＳＴＡ３はＯＢＳＳ ＮＡＶが満了する前にはＵＬ ＭＵフレームを送信しない。

ＮＡＶ管理の実施例６

以下では、図２４を参照して上述した既存のＮＡＶ管理方法の問題点を解決するための更に他の実施例について説明する。

（１）ＮＡＶ管理の実施例６−１：複数のＮＡＶタイマー

本発明の一実施例によれば、ＳＴＡはマイＢＳＳ（例えば、イントラＢＳＳ） ＮＡＶタイマーとＯＢＳＳ（例えば、インターＢＳＳ） ＮＡＶタイマーをそれぞれ維持／管理することができる。マイＢＳＳフレームによってＮＡＶアップデートが必要であれば、ＳＴＡはマイＢＳＳ ＮＡＶタイマーをアップデートすることができる。ＯＢＳＳフレームによってＮＡＶアップデートが必要であれば、ＳＴＡはＯＢＳＳ ＮＡＶタイマーをアップデートすることができる。

図２９に本発明の一実施例に係るＮＡＶ設定を例示する。

図２９を参照すると、ＳＴＡ３は、ＯＢＳＳフレームを受信すると、ＯＢＳＳ ＮＡＶタイマーをアップデート（例えば、ここで、アップデートは設定、変更、最小／リセットのうちの一つを意味できる。）し、マイＢＳＳ ＮＡＶタイマーはアップデートしない。

ＳＴＡ３はマイＢＳＳフレームを受信すれば、マイＢＳＳ ＮＡＶタイマーを設定又はアップデートして、ＯＢＳＳ ＮＡＶタイマーをアップデートしない。

ＳＴＡはマイＢＳＳ ＮＡＶとＯＢＳＳ ＮＡＶのいずれか一方でも０以上の値を有すると、ＳＴＡはチャネルアクセスを行わない。

ＳＴＡは、マイＢＳＳ ＮＡＶタイマーの代わりに、既存と同じＮＡＶタイマーを維持することもできる。例えば、ＳＴＡは、既存と同じ方式で動作するＮＡＶタイマーとＯＢＳＳ ＮＡＶタイマーを維持することができる。例えば、既存ＮＡＶタイマーはイントラＢＳＳ／インターＢＳＳフレームを問わずにアップデートされ（例えば、既存と同様に）、ＯＢＳＳ ＮＡＶタイマーはＯＢＳＳ（インターＢＳＳ）フレームのみによってアップデートされ得る。

したがって、イントラＢＳＳ ＳＴＡが送信するフレームによって既存のＮＡＶタイマーがアップデートされても、ＯＢＳＳ ＮＡＶタイマーが有効であれば、ＳＴＡはＯＢＳＳ ＮＡＶを考慮してＵＬ ＭＵフレームを送信しなくてもよい。また、ＳＴＡは、ＯＢＳＳ ＮＡＶタイマーがＯＢＳＳ ＮＡＶ有効閾値（例えば、デフォルト値は０）より大きい値である場合、ＯＢＳＳ ＮＡＶが有効だと判断できる。

一方、ＯＢＳＳ ＮＡＶ有効閾値はシステムによって決定され、ビーコンのようなブロードキャスト／マルチキャストフレーム又はユニキャストフレームによってＳＴＡに伝達され得る。

（２）ＮＡＶ管理の実施例６−２：１つのＮＡＶタイマー

本発明の一実施例によれば、ＳＴＡは既存のように１つのＮＡＶタイマーを維持するが、ＯＢＳＳフレームによって設定されたＮＡＶがマイＢＳＳフレームによってアップデートされる時、ＳＴＡはＯＢＳＳ ＮＡＶ差値を計算して保存することができる。ＯＢＳＳ ＮＡＶ差値は、｛受信されたフレームのＮＡＶタイマー−現在ＮＡＶタイマー｝と計算することができる。例えば、受信されたフレームのＮＡＶタイマーは、受信されたフレームのｄｕｒａｔｉｏｎによって計算することができ、現在ＮＡＶタイマーはＯＢＳＳによって最後にアップデートされたＮＡＶタイマーであってもよい。ＯＢＳＳ ＮＡＶ差値は、ＮＡＶ差値と略してもよい。

ＳＴＡは現在ＮＡＶをリセット（例えば、ＣＦ−Ｅｎｄ受信）したり、又は現在ＮＡＶを考慮せずにフレーム伝送を試みる場合（例えば、トリガーフレームに基づいてＵＬフレームを送信する場合）、保存されたＮＡＶ差値を用いてＯＢＳＳ ＮＡＶが有効か否か検査できる。

例えば、ＳＴＡは、該当の時点に｛現在ＮＡＶタイマー−ＯＢＳＳ ＮＡＶ差値｝を計算してＯＢＳＳ ＮＡＶが有効か否かチェックできる。例えば、｛現在ＮＡＶタイマー−ＮＡＶ差値｝の値がＯＢＳＳ ＮＡＶ有効閾値（例えば、デフォルトは０、しかし、０より大きい値に設定され得る。）より大きいと、ＳＴＡはＯＢＳＳ ＮＡＶが有効だと判断する。仮に、｛現在ＮＡＶタイマー−ＮＡＶ差値｝が０より小さいか等しいと、ＳＴＡはＯＢＳＳ ＮＡＶ差値を維持しないか、又は０に設定することができる。ＮＡＶ差値がないか、又は０に設定されていると、ＯＢＳＳ ＮＡＶが有効でないことを示すことができ、ＳＴＡはＯＢＳＳ ＮＡＶを考慮しなくてもよい。

ＯＢＳＳ ＮＡＶが有効であれば、ＳＴＡはＯＢＳＳ ＮＡＶを考慮して動作することができる。例えば、ＳＴＡはＯＢＳＳ ＮＡＶが有効であれば、ＮＡＶリセット時点でＮＡＶをリセットしないか、フレーム伝送時点にはフレームを送信しなくてもよい。

ＳＴＡがＮＡＶを考慮するという意味は、チャネルが混雑（ｂｕｓｙ）であると仮定してフレーム伝送を試みないこと、又はＯＢＳＳ ＮＡＶをリセットしないこと、を指すことができる。

図３０に本発明の一実施例に係るＮＡＶ管理方法を例示する。

ＳＴＡ３はＯＢＳＳによって設定されたＮＡＶを維持していると仮定する。

ＳＴＡ３はマイＢＳＳのＡＰからＴＦ１を受信する。ＴＦ１のＮＡＶが現在ＮＡＶより大きいと仮定する。ＳＴＡ３はＴＦ１に基づいてＮＡＶをアップデートする。この時、ＳＴＡ３はＮＡＶ差値｛ＴＦ１のＮＡＶタイマー−現在ＮＡＶタイマー｝を計算及び保存する。

その後、ＳＴＡ３はＴＦ２を受信する。ＴＦ３はＳＴＡ３のスケジューリング情報を含む。ＳＴＡ３はＴＦ２に基づくＵＬ伝送を試みる前に、ＯＢＳＳ ＮＡＶが有効か否かをさらに検査する。一方、ＳＴＡ３の現在ＮＡＶがイントラＢＳＳ ＳＴＡによって設定されているため、ＳＴＡ３は現在のＮＡＶは考慮しなくてもよい。

仮に、｛現在ＮＡＶタイマー−ＮＡＶ差値｝がＯＢＳＳ ＮＡＶ有効閾値を超えると、ＳＴＡ３はＯＢＳＳ ＮＡＶが有効だと見なすことができる。ＳＴＡ３はＯＢＳＳ ＮＡＶが有効である間にＵＬフレームを送信しない。

一方、図２８で説明したように、ＳＴＡはＭｙＢＳＳ（又は、イントラＢＳＳ）によって設定されたＮＡＶがＯＢＳＳ（又は、イントラＢＳＳ）によってアップデートされる時にもＮＡＶ差値を計算及び保存する動作を行うことができる。例えば、その後、インターＢＳＳフレームによってＮＡＶがアップデート（例えば、リセット／取消）される時に、ＳＴＡはＭｙＢＳＳ ＮＡＶが有効であるかチェックする。ＭｙＢＳＳ ＮＡＶが有効である場合、ＳＴＡはＭｙＢＳＳ ＮＡＶを考慮して動作することができる。ＮＡＶ差値を計算し、有効か否かを検査する方法は、上述した内容と重複するので説明を省く。

（３）ＮＡＶ管理の実施例６−３：ＣＦ−ＥＮＤフレーム

以下では、ＴＸＯＰ ｔｒｕｎｃａｔｉｏｎのためのＣＦ−Ｅｎｄを受信した場合、ＮＡＶアップデート方法について説明する。

現在ＮＡＶがイントラＢＳＳフレームによってアップデートされたものであり、ＯＢＳＳ ＮＡＶが有効であれば、ＳＴＡがイントラＢＳＳ ＳＴＡからのＣＦ−Ｅｎｄフレームの受信によって現在のＮＡＶをＯＢＳＳ ＮＡＶにアップデートすることができる。

上述したＮＡＶ管理の実施例６−１のように、ＳＴＡがＯＢＳＳ ＮＡＶタイマーをさらに維持していると、ＳＴＡはＯＢＳＳ ＮＡＶタイマー値を確認することによってＯＢＳＳ ＮＡＶが有効である否かが分かる。ＯＢＳＳ ＮＡＶが有効であれば、ＳＴＡは現在のＮＡＶをＯＢＳＳ ＮＡＶタイマー値に設定する。

上述したＮＡＶ管理の実施例６−２のように、ＳＴＡがＯＢＳＳ ＮＡＶ差値を計算して保存していると、ＳＴＡはＯＢＳＳ ＮＡＶ差値から、ＯＢＳＳ ＮＡＶが有効であるか否かが分かる。ＯＢＳＳ ＮＡＶが有効であれば、ＳＴＡは、ＯＢＳＳ ＮＡＶ差値を用いて現在のＮＡＶをＯＢＳＳ ＮＡＶに設定することができる。ＮＡＶ管理の実施例６−２で説明したように、現在のＮＡＶがＯＢＳＳフレームによってアップデートされる時、ＳＴＡはＯＢＳＳ ＮＡＶ差値｛受信されたフレームのＮＡＶタイマー−現在のＮＡＶタイマー｝を計算することができる。ＳＴＡは、ＯＢＳＳ ＮＡＶ有効性の検査時点に、｛現在のＮＡＶタイマー−ＯＢＳＳ ＮＡＶ差値｝がＯＢＳＳ ＮＡＶ有効閾値を超えると、ＯＢＳＳ ＮＡＶが有効だと判断し、現在のＮＡＶをＯＢＳＳ ＮＡＶ（＝現在のＮＡＶタイマー−ＯＢＳＳ ＮＡＶ差値）にアップデートすることができる。

（４）ＮＡＶ管理の実施例６−４：ＮＡＶアップデート指示子

本発明の一実施例によれば、現在のＮＡＶが過去のＮＡＶ値からアップデートされたものか、それとも新しく設定されたものかによって、ＳＴＡがＮＡＶを考慮したり又はＮＡＶをリセットすることができる。

例えば、現ＮＡＶ直前のＮＡＶがｚｅｒｏであったかｎｏｎ−ｚｅｒｏであったかによって、ＮＡＶをリセットするか否かを決定することができる。ＳＴＡはＮＡＶを設定又はアップデートする時、以前のＮＡＶに関する情報（例えば、ＮＡＶアップデート指示子）を保存することができる。例えば、ＮＡＶがｎｏｎ−ｚｅｒｏ値からアップデートされると、ＮＡＶアップデート指示子＝１に設定され、ＮＡＶがｚｅｒｏ値から初期設定されていると、ＮＡＶアップデート指示子＝０に設定され得る。

ＳＴＡが自身のＡＰからトリガーフレームを受信してＵＬ ＭＵフレームを送信する際に、現在ＮＡＶがイントラＢＳＳ ＳＴＡが送信したフレームによるものであれば、ＳＴＡはＮＡＶアップデート指示子を確認する。ＮＡＶアップデート指示子＝０であれば、ＳＴＡは、現在ＮＡＶが新しく設定（例えば、ＮＡＶ＝０から初期設定）されたと判断し、設定されたＮＡＶを考慮しない（例えば、ＵＬフレーム伝送）。仮に、ＮＡＶアップデート指示子＝１であれば、ＳＴＡは現在ＮＡＶがｎｏｎ−ｚｅｒｏ値からアップデートされたものだと判断し、設定されたＮＡＶを考慮することができる（例えば、ＮＡＶ満了前にはＵＬフレームを送信しない）。

ＳＴＡがイントラＢＳＳ ＳＴＡ（例えば、ＡＰ）からＣＦ−Ｅｎｄを受信した時、現在ＮＡＶがイントラＢＳＳフレームによるものであれば、ＳＴＡはＮＡＶアップデート指示子を確認する。ＮＡＶアップデート指示子＝０であれば、ＳＴＡは、現在ＮＡＶが初期設定されたものだと判断し、ＮＡＶをリセットすることができる。ＮＡＶアップデート指示子＝１であれば、ＳＴＡは、現在ＮＡＶがｎｏｎ−ｚｅｒｏ値からアップデートされたものだと判断し、ＮＡＶをリセットしなくてもよい。

ＲＴＳ又はＭＵ−ＲＴＳフレームを受信したＳＴＡ（例えば、ｔｈｉｒｄ ｐａｒｔｙ）が指定された時間内にフレーム（例えば、ＣＴＳ）を受信できなかった場合、ＮＡＶアップデート指示子を確認することができる。ＮＡＶアップデート指示子＝０であれば、ＳＴＡは、現在ＮＡＶが初期設定されたものだと判断し、ＮＡＶをリセットすることができる。ＮＡＶアップデート指示子＝１であれば、ＳＴＡは、現在ＮＡＶがｎｏｎ−ｚｅｒｏ値からアップデートされたものだと判断し、設定されたＮＡＶをリセットしなくてもよい。

（５）ＮＡＶ管理の実施例６−５：マイＢＳＳ ＮＡＶ差値

上述した方法は、イントラＢＳＳ（又は、マイＢＳＳ） ＮＡＶからインターＢＳＳ（又は、ＯＢＳＳ） ＮＡＶにアップデートされる時にも用いることができる。この場合、ＳＴＡが計算して保存する値は、ＮＡＶアップデート指示子の代わりに、イントラＢＳＳ ＮＡＶ差値又はマイＢＳＳ ＮＡＶ差値と呼ぶことができ、これに限定されない。便宜上、マイＢＳＳ ＮＡＶ差値と呼ぶものとする。

イントラＢＳＳ ＮＡＶ（すなわち、イントラＢＳＳフレームを受信して設定／アップデートされたＮＡＶを意味する。）を維持していたＳＴＡがインターＢＳＳフレームを受信してＮＡＶをアップデートする場合、ＳＴＡはマイＢＳＳ ＮＡＶ差値を計算する。マイＢＳＳ ＮＡＶ差値は、上述したＯＢＳＳ ＮＡＶ差値に類する方式で計算することができる。例えば、マイＢＳＳ ＮＡＶ差値は、｛現在受信されたＯＢＳＳフレームによって計算されたＮＡＶ値−現在のＮＡＶ値（例えば、マイＢＳＳ ＮＡＶ値）｝と計算することができる。ＮＡＶアップデートによって、マイＮＡＶはＯＢＳＳ ＮＡＶに変更される。ＳＴＡは保存されたマイＢＳＳ ＮＡＶ差値を用いてＭｙＢＳＳ ＮＡＶが有効であるか検査できる。例えば、ＯＢＳＳ ＮＡＶがＯＢＳＳ ＳＴＡによって送信されたフレーム（例えば、ＣＦ−Ｅｎｄ）によってＮＡＶがリセットされなければならない場合に、ＳＴＡはマイＢＳＳ ＮＡＶが有効であるか検査できる。マイＢＳＳ ＮＡＶが有効であれば、ＳＴＡは現在ＮＡＶ（例えば、ＯＢＳＳ ＮＡＶ）をマイＢＳＳ ＮＡＶにアップデートする。

一方、ＳＴＡはマイＢＳＳ ＮＡＶ差値が特定閾値（例えば、デフォルト値は０）以上であれば、マイＢＳＳ ＮＡＶが有効であるか検査する必要があると判断できる。

マイＢＳＳ ＮＡＶが有効であるか検査する際、ＳＴＡは｛現在ＮＡＶ値−マイＢＳＳ ＮＡＶ差値｝が特定閾値（例えば、デフォルト値は０）以上であれば、マイＢＳＳ ＮＡＶが有効だと見なすことができる。

このとき、マイＢＳＳ ＮＡＶは｛現在ＮＡＶ値−マイＢＳＳ ＮＡＶ差値｝であってもよい。

ＮＡＶ管理の実施例の要約

上述したように、、ＳＴＡがＯＢＳＳ ＳＴＡからＣＦ−ＥＮＤフレームを受信すると、ＳＴＡは現在のＮＡＶ（例えば、最後に行われたＮＡＶアップデート／設定）がイントラＢＳＳフレームによるものか否かを考慮しなければならない。仮に、最後に行われたＮＡＶアップデートがイントラＢＳＳフレームによるものであれば、ＳＴＡはＯＢＳＳからのＣＦ−ＥＮＤフレームに基づいてＮＡＶをリセットしない（例えば、イントラＢＳＳ ＮＡＶの保護）。

また、イントラＢＳＳ ＮＡＶの他、インターＢＳＳ ＮＡＶも保護される必要がある。例えば、イントラＢＳＳ ＳＴＡからＣＦ−ＥＮＤフレームが受信されると、ＳＴＡは、現在のＮＡＶ（例えば、最後に行われたＮＡＶアップデート／設定）がインターＢＳＳフレームによるものか否かを考慮しなければならない。仮に、最後に行われたＮＡＶアップデートがインターＢＳＳフレームによるものであれば、ＳＴＡはマイＢＳＳからのＣＦ−ＥＮＤフレームに基づいてＮＡＶをリセットしなくてもよい（例えば、インターＢＳＳ ＮＡＶの保護）。

なお、ＯＢＳＳによって設定されたＮＡＶがイントラＢＳＳフレームによってアップデートされる場合において、イントラＢＳＳフレームによるＴＸＯＰ ｔｒｕｎｃａｔｉｏｎが考慮される必要がある。以下では、上述した議論に基づき、イントラＢＳＳフレームによるＴＸＯＰ ｔｒｕｎｃａｔｉｏｎ方法及び／又はＵＬ ＭＵフレーム応答（例えば、トリガーフレームに基づく伝送）に使用可能な方法についてさらに述べる。

図３１には、イントラＢＳＳフレームによるＴＸＯＰ ｔｒｕｎｃａｔｉｏｎを例示する。ＳＴＡのＮＡＶはＯＢＳＳによって設定されたものだと仮定する。ＳＴＡは自身のＡＰからフレーム（例えば、ＴＦ又はＣＴＳなど）を受信すると、ＮＡＶをアップデートする。その後、ＡＰがＣＦ−ＥＮＤフレームを送信すると、ＳＴＡはＮＡＶをリセットする。ＮＡＶリセット後にＳＴＡがＵＬフレームを送信する場合、ＯＢＳＳのＮＡＶが保護され得ないという問題点がある。

図３２は、図３１の問題点を解決するための、本発明の一実施例に係るＮＡＶ管理方案を例示する。図３１と重複する説明は省略する。

図３２を参照すると、ＳＴＡが自身のＡＰからＣＦ−ＥＮＤフレームを受信すると、ＳＴＡはＮＡＶをリセットする前に、ＯＢＳＳ ＮＡＶが有効か否かをまず判断しなければならない。ＯＢＳＳ ＮＡＶが有効であれば、ＳＴＡはＮＡＶをリセットしなくてもよい。例えば、ＯＢＳＳ ＮＡＶが有効であれば、ＳＴＡは現在のＮＡＶをＯＢＳＳ ＮＡＶにアップデート（例えば、復元）することができる。

図３３はＮＡＶ差値を説明するための例示である。

ＯＢＳＳ ＮＡＶがイントラＢＳＳフレームによってアップデートされる場合、ＳＴＡはＮＡＶ差値を計算及び保存することができる。ＮＡＶ差値は｛受信されたフレーム（例えば、イントラＢＳＳフレーム）によるＮＡＶ値−現在ＮＡＶ値｝であってもよい。

その後、ＳＴＡはＣＦ−ＥＮＤフレームを自身のＡＰから受信する。ＳＴＡはＮＡＶをリセットする前にＯＢＳＳ ＮＡＶが有効か否かをチェックする。ＯＢＳＳ ＮＡＶの有効性は、ＮＡＶ差値に基づいて計算することができる。例えば、｛現在（例えば、ＯＢＳＳ ＮＡＶ有効性チェック時点）ＮＡＶ値Ｘ−ＮＡＶ差値Ｙ｝が０より大きい場合、ＳＴＡはＯＢＳＳ ＮＡＶが有効だと判断できる。例えば、イントラＢＳＳフレームによるＮＡＶアップデートがなかったという仮定の下に残余ＯＢＳＳ ＮＡＶが存在すると、ＳＴＡはＯＢＳＳ ＮＡＶが相変らず有効なものだと判断できる。

ＯＢＳＳ ＮＡＶが有効であれば、ＳＴＡは現在のＮＡＶを有効なＯＢＳＳ ＮＡＶ値にアップデートすることができる（例えば、ＣＦ−ＥＮＤフレーム受信などの理由でマイＢＳＳ ＮＡＶがそれ以上保護される必要がない場合）。ＯＢＳＳ ＮＡＶ値を用いたＮＡＶアップデートは、イントラＢＳＳフレームによってＮＡＶがアップデートされなかったなら維持されるはずだったＯＢＳＳ ＮＡＶ値を復元することと理解できる。

ＯＢＳＳ ＮＡＶが有効でなければ、ＳＴＡはＮＡＶをリセットすることができる（例えば、ＯＢＳＳ ＮＡＶ及びマイＢＳＳ ＮＡＶの両方とも保護される必要がない場合）。

図３４は、本発明の一実施例に係るＮＡＶアップデートを説明するための例示である。ＳＴＡ５にはＯＢＳＳ ＮＡＶが設定されたと仮定する。

ＳＴＡ５はＴＦ１（例えば、イントラＢＳＳフレーム）を用いてＮＡＶ（例えば、ＯＢＳＳ ＮＡＶ）をアップデートする時、ＮＡＶ差値を計算及び保存する。

ＳＴＡ５はＴＦ２を受信する。ＴＦ２によるＮＡＶアップデートはなく、ＴＦ２はＳＴＡ５に対するリソース割り当て情報を含むと仮定する。

ＳＴＡ５はＴＦ２に基づいてＵＬフレームを送信する前に、ＮＡＶ差値を用いてＯＢＳＳ ＮＡＶが有効か否かをチェックする。例えば、｛現在（例えば、ＯＢＳＳ ＮＡＶチェック時点）ＮＡＶ値−ＮＡＶ差値｝が０より大きいと、ＳＴＡ５はＯＢＳＳ ＮＡＶが有効だと仮定することができる。

ＯＢＳＳ ＮＡＶが有効である間に、ＳＴＡ５はＴＦ２に基づくＵＬフレーム伝送を行わない（例えば、ＯＢＳＳＳ ＮＡＶを考慮）。

（ｉ）１つのＮＡＶタイマーを用いた複数のＮＡＶの管理

一方、ＳＴＡは１つのＮＡＶタイマーを用いて複数のＮＡＶ（例えば、２個のＮＡＶ）管理することができる。複数のＮＡＶはイントラＢＳＳ ＮＡＶ及び非−イントラＢＳＳ ＮＡＶを含むことができる。イントラＢＳＳ ＮＡＶは、イントラＢＳＳフレームによってアップデートされるＮＡＶであってもよい。非−イントラＢＳＳ ＮＡＶは、イントラＢＳＳフレーム以外のフレーム又はイントラＢＳＳフレームと決定できないフレーム（例えば、インターＢＳＳフレーム、又はＣＴＳ／ＡＣＫなどのように、インターＢＳＳフレームかイントラＢＳＳフレームかを区別できないフレーム）によってアップデートされるＮＡＶであってもよい。非−イントラＢＳＳ ＮＡＶは、レギュラーＮＡＶと呼ぶこともできる。

現在のＮＡＶ（例えば、１つのＮＡＶタイマー）がイントラＢＳＳ ＮＡＶによって設定されたものであり、イントラＢＳＳフレーム以外のフレームによってアップデートされる場合（又は、その逆の場合）、ＳＴＡはＮＡＶ差値を計算して保存することができる。ＮＡＶ差値は｛受信されたフレームによるＮＡＶ値−イントラＢＳＳ ＮＡＶ｝であるか、又は｛受信されたフレームによるＮＡＶ値−インターＢＳＳ ＮＡＶ｝であってもよい。

その後、ＳＴＡは自身のＮＡＶ（例えば、１つのＮＡＶタイマー）をインターＢＳＳフレームのｄｕｒａｔｉｏｎを用いてアップデートすることができる。したがって、ＳＴＡの現在ＮＡＶはインターＢＳＳ ＮＡＶと見なすことができる。

ＮＡＶ差値が０である場合、２つのＮＡＶが全て有効でないか、又は現在ＮＡＶのみが有効である場合であってもよい。

仮に、ＮＡＶのチェックが必要な場合（例えば、ＵＬ ＭＵフレームを送信する前に又はＮＡＶをリセットする前に）、ＳＴＡは２個のＮＡＶが有効であるか否かをチェックできる。例えば、２個のＮＡＶの値がいずれも０でないと、２個のＮＡＶが全て有効であると判断される。ＮＡＶ値が０であるＮＡＶは有効でないと判断される。２個のＮＡＶの有効性を判断するためにＮＡＶ差値を用いることができる。例えば、｛現在ＮＡＶ値（例えば、１つのＮＡＶタイマー）−ＮＡＶ差値｝が０より大きい場合には、２個のＮＡＶが有効だと判断される（例えば、現在ＮＡＶ値も０でないため）。しかし、｛現在のＮＡＶ値−ＮＡＶ差値｝が０より大きくないと、ただ１個のＮＡＶ（例えば、イントラＢＳＳ ＮＡＶ又はインターＢＳＳ ＮＡＶ）のみが有効であると判断される。

仮に、２個のＮＡＶがいずれも有効であれば、ＳＴＡは２個のＮＡＶを全て考慮して動作する。現在のＮＡＶ（例えば、イントラＢＳＳ ＮＡＶ又はインターＢＳＳ ＮＡＶ）のみが有効であれば、ＳＴＡは当該ＮＡＶのみを考慮して動作できる。

現在のＮＡＶ（例えば、１つのＮＡＶタイマー）がイントラＢＳＳ ＮＡＶであり、ＳＴＡがイントラＢＳＳ ＳＴＡからＣＦ−ＥＮＤフレームを受信した場合を仮定する。仮に、２つのＮＡＶとも有効であれば、ＳＴＡは現在のＮＡＶ（例えば、１つのＮＡＶタイマー）を非−イントラＮＡＶ（例えば、現在のＮＡＶ値−ＮＡＶ差値）にアップデートする。２つのＮＡＶとも有効でない場合には、ＳＴＡはＣＦ−ＥＮＤフレームに基づいて現在のＮＡＶ（例えば、１つのＮＡＶタイマー）をリセットする。

現在のＮＡＶ（例えば、１つのＮＡＶタイマー）がイントラＢＳＳ ＮＡＶであり、ＳＴＡがインターＢＳＳ ＳＴＡからＣＦ−ＥＮＤフレームを受信した場合を仮定する。仮に、２つのＮＡＶとも有効であれば、ＳＴＡはイントラＢＳＳに該当する現在のＮＡＶ（例えば、１つのＮＡＶタイマー）をリセットしない。しかし、ＳＴＡは、非−イントラＮＡＶをリセットすることはできる。非−イントラＮＡＶのリセットは、ＮＡＶ差値を０に設定することを意味できる。

現在のＮＡＶ（例えば、１つのＮＡＶタイマー）が非−イントラＢＳＳ ＮＡＶであり、ＳＴＡがインターＢＳＳ ＳＴＡからＣＦ−ＥＮＤフレームを受信した場合を仮定する。仮に、２つのＮＡＶとも有効であれば、ＳＴＡは非−イントラＢＳＳに対応する現在のＮＡＶ（例えば、１つのＮＡＶタイマー）をイントラＮＡＶ（例えば、現在のＮＡＶ値−ＮＡＶ差値）にアップデートする。２つのＮＡＶとも有効でない場合には、ＳＴＡはＣＦ−ＥＮＤフレームに基づいて現在のＮＡＶ（例えば、１つのＮＡＶタイマー）をリセットする。

現在のＮＡＶ（例えば、１つのＮＡＶタイマー）が非−イントラＢＳＳ ＮＡＶであり、ＳＴＡがイントラＢＳＳ ＳＴＡからＣＦ−ＥＮＤフレームを受信した場合を仮定する。仮に、２つのＮＡＶとも有効であれば、ＳＴＡは、非−イントラＢＳＳに該当する現在のＮＡＶ（例えば、１つのＮＡＶタイマー）をリセットしない。しかし、ＳＴＡはイントラＮＡＶをリセットすることはできる。イントラＮＡＶのリセットは、ＮＡＶ差値を０に設定することを意味できる。

（ｉｉ）複数のＮＡＶタイマーを用いた複数のＮＡＶ管理

このように、ＳＴＡは、ＵＬ ＭＵフレームなどを送信する際にＮＡＶを考慮することができ、特に、ＳＴＡは複数のＮＡＶ（例えば、イントラＢＳＳ ＮＡＶ／非−イントラＢＳＳ ＮＡＶ）を管理することができる。複数のＮＡＶを管理するために、ＳＴＡは、１つのＮＡＶタイマーを設定する方法（例えば、ＮＡＶ差値を利用）の他、複数のＮＡＶタイマーを設定することもできる。例えば、イントラＢＳＳ ＮＡＶ及び非−イントラＢＳＳ ＮＡＶのそれぞれに対して別のＮＡＶタイマーを設定することができる。

例えば、イントラＢＳＳ ＮＡＶタイマーは、イントラＢＳＳフレーム／ＰＰＤＵによってアップデートされるＮＡＶタイマーであってもよい。非−イントラＢＳＳ ＮＡＶタイマーは、イントラＢＳＳフレームでないか、又はイントラＢＳＳかインターＢＳＳかを区別できないフレームによってアップデートされるＮＡＶタイマーであってもよい。

ＳＴＡは、トリガーフレームに対応してＵＬ ＭＵフレームを送信する前に非−イントラＢＳＳ ＮＡＶタイマーを考慮しなければならない。

また、ＳＴＡはイントラＢＳＳからＣＦ−ＥＮＤフレームが受信されると、イントラＢＳＳ ＮＡＶをリセットし、インターＢＳＳからＣＦ−ＥＮＤフレームが受信されると、非−イントラＢＳＳ ＮＡＶをリセットすることができる。

図３５に、本発明の一実施例に係る２個のＮＡＶタイマーを例示する。

図３５を参照すると、ＳＴＡは、ＯＢＳＳ ＳＴＡからＴＦ又はＣＴＳなどのフレームを受信して非−イントラＢＳＳ ＮＡＶタイマーを設定する。

ＳＴＡは、自身のＡＰからＴＦ又はＣＴＳフレームを受信し、イントラＢＳＳ ＮＡＶタイマーを起動する。ＳＴＡは、自身のＡＰからＣＥ−ＥＮＤフレームを受信すると、イントラＢＳＳ ＮＡＶタイマーをリセットする。

１つのＮＡＶタイマーを用いて２個のＮＡＶを管理する実施例において、ＳＴＡは、現在ＮＡＶタイマーの値がいずれか一つのＮＡＶから他のＮＡＶに変更される度に、ＮＡＶ差値を計算して保存することができる。

２個のＮＡＶタイマーを用いて２個のＮＡＶを管理する実施例において、ＳＴＡはＵＬ ＭＵフレーム伝送前に非−イントラＢＳＳ ＮＡＶを考慮しなければならず、ＣＦ−ＥＮＤフレームが受信されると、当該ＮＡＶタイマーをリセットする。

図３６に、本発明の一実施例に係るＮＡＶ管理方法を例示する。上述した説明と重複する説明は省略する。

図３６を参照すると、ＳＴＡは、区間（ｄｕｒａｔｉｏｎ）情報を含むフレームを受信する（Ｓ３６０５）。区間情報は、ＨＥ−ＳＩＧ Ａフィールドに含まれたＴＸＯＰ ｄｕｒａｔｉｏｎフィールドが示すＴＸＯＰ ｄｕｒａｔｉｏｎ値であるか、又はＭＡＣヘッダーに含まれたｄｕｒａｔｉｏｎフィールドが示すＭＡＣ ｄｕｒａｔｉｏｎ値であってよく、これに限定されない。

例えば、フレームは、ＲＴＳ、ＣＴＳなどの制御フレーム、管理フレーム、トリガーフレーム又はＨＥ−ＰＰＤＵベースのフレーム又はＮｏｎ−ＨＥ ＰＰＤＵベースのフレームであってよく、これに限定されない。

ＳＴＡは複数のＮＡＶの中から所定のＮＡＶを選択する（Ｓ３６１０）。

例えば、ＳＴＡは複数のＮＡＶを有することができる。複数のＮＡＶは、イントラＢＳＳ ＮＡＶ及び非−イントラＢＳＳ ＮＡＶを含むことができる。非−イントラＢＳＳ ＮＡＶは、ＯＢＳＳ（ｏｔｈｅｒ ＢＳＳ）フレームのためのものであってよい。さらに、非−イントラＢＳＳ ＮＡＶは、ＢＳＳを特定できないフレームのためのものであってもよい。ＢＳＳを特定できないフレームは、例えば、ＲＡフィールド又はＴＡフィールドなどにおいてＢＳＳＩＤ情報を持たないフレームであり得る（例えば、ＡＣＫ、ＣＴＳなど）。

所定のＮＡＶは、当該フレームがＳＴＡの属するＢＳＳ（ｂａｓｉｃ ｓｅｒｖｉｃｅ ｓｅｔ）から受信されたものか否かに基づいて選択され得る。例えば、ＳＴＡは、フレームがマイＢＳＳから受信されたか否かを判断できる。

ＳＴＡは、フレームがＳＴＡの属したＢＳＳから受信されたものと決定されると、第１ＮＡＶ（例えば、イントラＢＳＳ ＮＡＶ）を選択し、フレームがＳＴＡの属しないＢＳＳから受信されたものと決定されると、第２ＮＡＶを選択（例えば、非−イントラＢＳＳ ＮＡＶ）することができる。さらに、ＳＴＡはフレームがいずれのＢＳＳから受信されたかを決定できない場合にも第２ＮＡＶを選択（例えば、非−イントラＢＳＳ ＮＡＶ）することができる。

ＳＴＡはフレームの区間情報に基づいて所定のＮＡＶを管理することができる（Ｓ３６１５）。ＮＡＶ管理は、ＮＡＶ初期設定、ＮＡＶアップデート又はＮＡＶリセットのいずれか一つであってよく、これに限定されない。

複数のＮＡＶのいずれか一つでも０より大きい値を有する場合、ＳＴＡはチャネルアクセスを保留することができる。

一実施例によれば、ＳＴＡは複数のＮＡＶに対応する複数のＮＡＶタイマーを設定することができる。

他の実施例によれば、ＳＴＡは、１つのＮＡＶタイマーのみを設定してもよい。例えば、複数のＮＡＶを、複数のＮＡＶ間の差値と１つのＮＡＶタイマーによって管理することができる。１つのＮＡＶタイマーの値が第１ＮＡＶから第２ＮＡＶに変更されたり又は第２ＮＡＶから第１ＮＡＶに変更される場合、複数のＮＡＶ間の差値をアップデートすることができる。また、ＳＴＡは、１つのＮＡＶタイマーにマップされたいずれか一つのＮＡＶの現在値と複数のＮＡＶ間の差値を用いて、他のＮＡＶの有効性を判断することができる。

図３７は、上述したような方法を具現するための装置を説明するための図である。

図３７の無線装置８００は上述の特定ＳＴＡに、無線装置８５０は上述のＡＰに対応し得る。

ＳＴＡ８００は、プロセッサ８１０、メモリ８２０、送受信部８３０を含むことができ、ＡＰ８５０は、プロセッサ８６０、メモリ８７０及び送受信部８８０を含むことができる。送受信部８３０及び８８０は無線信号を送信／受信し、ＩＥＥＥ ８０２．１１／３ ＧＰＰなどの物理層で実行され得る。プロセッサ８１０及び８６０は、物理層及び／又はＭＡＣ層で実行され、送受信部８３０及び８８０と接続している。プロセッサ８１０及び８６０は上述したＵＬ ＭＵスケジューリング手順を行うことができる。

プロセッサ８１０及び８６０及び／又は送受信部８３０及び８８０は、特定集積回路（ａｐｐｌｉｃａｔｉｏｎ−ｓｐｅｃｉｆｉｃ ｉｎｔｅｇｒａｔｅｄ ｃｉｒｃｕｉｔ；ＡＳＩＣ）、他のチップセット、論理回路及び／又はデータプロセッサを含むことができる。メモリ８２０及び８７０は、ＲＯＭ（ｒｅａｄ−ｏｎｌｙ ｍｅｍｏｒｙ）、ＲＡＭ（ｒａｎｄｏｍ ａｃｃｅｓｓ ｍｅｍｏｒｙ）、フラッシュメモリ、メモリカード、記憶媒体及び／又は他の記憶ユニットを含むことができる。一実施例がソフトウェアによって実行されるとき、上述した方法は、上述した機能を行うモジュール（例えば、プロセス、関数）として実行され得る。上記モジュールはメモリ８２０，８７０に格納されて、プロセッサ８１０，８６０によって実行され得る。上記メモリ８２０，８７０は上記プロセス８１０，８６０の内部又は外部に設けられ、周知の手段で上記プロセス８１０，８６０に接続され得る。

以上開示した本発明の好適な実施形態に関する詳細な説明は、当業者が本発明を具現して実施できるように提供されている。上記では本発明の好適な実施形態を参照して説明したが、当該技術の分野における熟練した当業者は、上述した説明から本発明を様々に修正及び変更可能であることが理解できる。したがって、本発明は、ここに開示した実施形態に制限しようとするものではなく、ここに開示した原理及び新規な特徴と一致する最も広い範囲を付与しようとするものである。

上述したような本発明はＨＥ ＰＰＤＵを支援する無線ＬＡＮシステムに適用されることを仮定して説明したが、これに限定されることはない。本発明は、ＩＥＥＥ ８０２．１１をはじめとする様々な無線通信システムに適用可能である。

Claims (19)

1. ＨＥ ＰＰＤＵ（ｈｉｇｈ ｅｆｆｉｃｉｅｎｃｙ ｐｈｙｓｉｃａｌ ｌａｙｅｒ ｐｒｏｔｏｃｏｌ ｄａｔａ ｕｎｉｔ）を支援する無線ＬＡＮシステムにおいてステーション（ＳＴＡ）がＮＡＶ（ｎｅｔｗｏｒｋ ａｌｌｏｃａｔｉｏｎ ｖｅｃｔｏｒ）を管理する方法であって、
   区間（ｄｕｒａｔｉｏｎ）情報を含むフレームを受信するステップと、
   上記ＳＴＡが有する複数のＮＡＶの中から所定のＮＡＶを選択するステップと、
   上記フレームの区間情報に基づいて上記所定のＮＡＶを管理するステップと、
   を含み、
   上記所定のＮＡＶは、上記フレームが上記ＳＴＡの属するＢＳＳ（ｂａｓｉｃ ｓｅｒｖｉｃｅ ｓｅｔ）から受信されたか否かに基づいて選択される、ＮＡＶ管理方法。
2. 上記所定のＮＡＶを選択するステップは、
   上記フレームが上記ＳＴＡの属したＢＳＳから受信されたと決定されると、第１ＮＡＶを選択し、
   上記フレームが上記ＳＴＡの属しないＢＳＳから受信されたと決定されると、第２ＮＡＶを選択する、請求項１に記載のＮＡＶ管理方法。
3. 上記所定のＮＡＶを選択するステップは、
   上記フレームがいずれのＢＳＳから受信されたものかを決定不可能な場合、上記第２ＮＡＶを選択する、請求項２に記載のＮＡＶ管理方法。
4. 上記複数のＮＡＶは、イントラＢＳＳ ＮＡＶ及び非−イントラＢＳＳ ＮＡＶを含み、
   上記非−イントラＢＳＳ ＮＡＶは、ＯＢＳＳ（ｏｔｈｅｒ ＢＳＳ）フレームのためのものである、請求項１に記載のＮＡＶ管理方法。
5. 上記非−イントラＢＳＳ ＮＡＶは、ＢＳＳを特定不可能なフレームのためのものである、請求項４に記載のＮＡＶ管理方法。
6. 上記ＢＳＳを特定不可能なフレームは、ＡＣＫ（ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ）フレームであるか、又はＣＴＳ（ｃｌｅａｒ−ｔｏ−ｓｅｎｄ）フレームである、請求項５に記載のＮＡＶ管理方法。
7. 上記複数のＮＡＶのいずれか一つでも０より大きい値を有する場合、上記ＳＴＡはチャネルアクセスを保留する、請求項１に記載のＮＡＶ管理方法。
8. 上記ＳＴＡは、上記複数のＮＡＶに対応する複数のＮＡＶタイマーを設定する、請求項１に記載のＮＡＶ管理方法。
9. 上記複数のＮＡＶは、
   上記複数のＮＡＶ間の差値と１つのＮＡＶタイマーによって管理される、請求項１に記載のＮＡＶ管理方法。
10. 上記１つのＮＡＶタイマーの値が、上記複数のＮＡＶのうち、第１ＮＡＶから第２ＮＡＶに変更される場合、上記複数のＮＡＶ間の差値がアップデートされる、請求項９に記載のＮＡＶ管理方法。
11. 上記１つのＮＡＶタイマーにマップされた第１ＮＡＶの現在値と上記複数のＮＡＶ間の差値を用いて第２ＮＡＶの有効性を判断するステップをさらに含む、請求項９に記載のＮＡＶ管理方法。
12. ＨＥ ＰＰＤＵ（ｈｉｇｈ ｅｆｆｉｃｉｅｎｃｙ ｐｈｙｓｉｃａｌ ｌａｙｅｒ ｐｒｏｔｏｃｏｌ ｄａｔａ ｕｎｉｔ）を支援する無線ＬＡＮシステムにおいてＮＡＶ（ｎｅｔｗｏｒｋ ａｌｌｏｃａｔｉｏｎ ｖｅｃｔｏｒ）を管理するステーション（ＳＴＡ）であって、
    区間（ｄｕｒａｔｉｏｎ）情報を含むフレームを受信する受信器と、
    上記ＳＴＡが有する複数のＮＡＶの中から所定のＮＡＶを選択し、上記フレームの区間情報に基づいて上記所定のＮＡＶを管理するプロセッサと、
    を備え、
    上記所定のＮＡＶは、上記フレームが上記ＳＴＡの属するＢＳＳ（ｂａｓｉｃ ｓｅｒｖｉｃｅ ｓｅｔ）から受信されたか否かに基づいて選択される、ステーション。
13. 上記所定のＮＡＶを選択する上記プロセッサは、
    上記フレームが上記ＳＴＡの属したＢＳＳから受信されたと決定されると、第１ＮＡＶを選択し、
    上記フレームが上記ＳＴＡの属しないＢＳＳから受信されたと決定されると、第２ＮＡＶを選択する、請求項１２に記載のステーション。
14. 上記所定のＮＡＶを選択する上記プロセッサは、
    上記フレームがいずれのＢＳＳから受信されたものかを決定不可能な場合、上記第２ＮＡＶを選択する、請求項１３に記載のステーション。
15. 上記複数のＮＡＶは、イントラＢＳＳ ＮＡＶ及び非−イントラＢＳＳ ＮＡＶを含み、
    上記非−イントラＢＳＳ ＮＡＶは、ＯＢＳＳ（ｏｔｈｅｒ ＢＳＳ）フレームのためのものである、請求項１２に記載のステーション。
16. 上記非−イントラＢＳＳ ＮＡＶは、ＢＳＳを特定不可能なフレームのためのものである、請求項１５に記載のステーション。
17. 上記ＢＳＳを特定不可能なフレームは、ＡＣＫ（ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ）フレームであるか、又はＣＴＳ（ｃｌｅａｒ−ｔｏ−ｓｅｎｄ）フレームである、請求項１６に記載のステーション。
18. 上記プロセッサは、上記複数のＮＡＶに対応する複数のＮＡＶタイマーを設定する、請求項１２に記載のステーション。
19. 上記複数のＮＡＶは、上記複数のＮＡＶ間の差値と１つのＮＡＶタイマーによって管理される、請求項１２に記載のステーション。