JP2020088720A - 電子装置 - Google Patents

Abstract

【課題】同一の外部装置との間であることを認識しつつ双方向のアソシエーション関係を構築することができる電子装置を提供する。【解決手段】電子装置１と電子装置２は、ＡＰとＳＴＡとを具備する。電子装置２は、第１アソシエーション要求フレームＳ１１を電子装置１のＳＴＡから受信する。電子装置２は、第１アソシエーション要求フレームＳ１１の受信に応じて、第１アソシエーション要求フレームに対応する第１アソシエーション応答フレームＳ１３を電子装置１へ送信し、かつ、第２アソシエーション要求フレームＳ１４を電子装置１へ送信する。【選択図】図５

Description

本発明の実施形態は、電子装置に関する。

複数のＭＡＣアドレスを有する無線通信装置が存在する。複数のＭＡＣアドレスを有する無線通信装置においては、たとえば、アクセスポイント（ＡＰ）として他の無線通信装置との間でアソシエーション関係を構築するとともに、ステーション（ＳＴＡ）として別の他の無線通信装置との間でアソシエーション関係を構築することなどが可能である。

IEEE Standard for Information Technology-Local and Metropolitan Area Networks-Specific Requirements, Part 11: Wireless LAN MAC and PHY Specifications

従来、複数のＭＡＣアドレスを有する無線通信装置においては、複数のＭＡＣアドレスを有する他の無線通信装置との間で、ＡＰとＳＴＡとの関係が互い違いの２つのアソシエーション関係を構築し、双方向のアソシエーション関係を構築することはできるものの、その２つのアソシエーション関係が同一の他の無線通信装置との間で構築されたものであるか否かを認識することなどができなかった。
本発明が解決しようとする課題は、同一の外部装置との間であることを認識しつつ双方向のアソシエーション関係を構築することができる電子装置を提供することである。

実施形態によれば、電子装置は、受信手段と、送信手段とを具備する。受信手段は、第１アソシエーション要求フレームを第１電子装置から受信する。送信手段は、前記第１アソシエーション要求フレームの受信に応じて、前記第１アソシエーション要求フレームに対応する第１アソシエーション応答フレームを前記第１電子装置へ送信し、かつ、第２アソシエーション要求フレームを前記第１電子装置へ送信する。

第１実施形態の電子装置を含む無線通信システムの一例を示す図。 第１実施形態の電子装置の機能ブロック構成の一例を示す図。 第１実施形態の電子装置の一構成例を示す図。 Managementフレームのフォーマット例を示す図。 第１実施形態の電子装置の双方向のアソシエーション関係の構築に関する処理フローの一例を示す図。 Association Request frame bodyに格納されるelementのフォーマットを示す図。 第１実施形態の電子装置において図６のフォーマットに準じて作成されるCo-located AP Info elementの一例を示す図。 第２実施形態の電子装置の双方向のアソシエーション関係の構築に関する処理フローの一例を示す図（ＡＰがAsoc RspとAsoc Reqとの集約を行うケース）。 第２実施形態の電子装置の双方向のアソシエーション関係の構築に関する処理フローの他の一例を示す図（ＳＴＡがAsoc RspとAsoc Reqとの集約を行うケース）。 第２実施形態の電子装置において作成されるTemporary AIDs for Association Interval elementの一例を示す図。 第２実施形態の電子装置において定義されるTemporary AIDs for Association Interval elementの他の一例を示す図。 第３実施形態の電子装置の双方向のアソシエーション関係の構築に関する処理フローの一例を示す図（ＳＴＡがAsoc RspとAsoc Reqとの集約を行うケース）。 第３実施形態の電子装置の双方向のアソシエーション関係の構築に関する処理フローの他の一例を示す図（図８Ａの（ＳS）ＰがAsoc RspとAsoc Reqとの集約を行うケース）。 第３実施形態の電子装置において使用し得るBlockAckフレームの一例を示す図。 第４実施形態の電子装置の双方向のアソシエーション関係の構築に関する処理フローの一例を示す図（Asoc Reqを送信するケース）。 第４実施形態の電子装置の双方向のアソシエーション関係の構築に関する処理フローの他の一例を示す図（Asoc Rspを送信するケース）。 第５実施形態の電子装置の双方向のアソシエーション関係の構築に関する処理フローの一例を示す図。

以下、実施の形態について図面を参照して説明する。
（第１実施形態）
まず、第１実施形態について説明する。
図１は、第１実施形態の電子装置（無線端末１および無線端末２）を含む無線通信システム１００の一例を示す図である。無線端末１および無線端末２は、たとえば、タブレットＰＣやノートＰＣなどのパーソナルコンピュータ、スマートフォンなど、無線通信機能を有する様々な電子装置として実現され得る。この無線通信システム１００は、無線端末１と無線端末２とが無線通信のためのアソシエーション関係を構築することによって構築される。

無線端末１および無線端末２は、それぞれ、図２に示すような階層モデルに準じた機能ブロック構成で実現されており、複数のＭＡＣアドレスを持つものとする。各ＭＡＣアドレスを有する機能ブロックをＭＡＣ機能ブロック（ａ１）と呼ぶ。各無線端末１，２の複数のＭＡＣ機能ブロックは、それぞれのAbstraction機能ブロック（ａ２）によってまとめられ、上位の機能ブロック（ａ４）からは１つのＭＡＣ機能ブロックとみなせるようになっている。Abstraction機能ブロックは、ＭＡＣアドレスに基づいて、上位機能ブロックからのフレームを複数のＭＡＣ機能ブロックのうちの適切なものに振り分けたり、ＭＡＣ機能ブロック間でのフレーム交換を実現したりする役割を担う。なお、上位機能ブロックからのフレームを適切なＭＡＣ機能ブロックに振り分ける手法や、ＭＡＣ機能ブロック間でのフレーム交換手法については後述する。また、ＭＡＣ機能ブロックの下位には、ＰＨＹ機能ブロック（ａ３）が存在する。図２中、（Ａ）は、複数のＭＡＣ機能ブロックに対して１つのＰＨＹ機能ブロックが設けられる例を示し、（Ｂ）は、複数のＭＡＣ機能ブロックと一対に複数のＰＨＹ機能ブロックが設けられる例を示している。

図３に、本実施形態の電子装置（無線端末１および無線端末２）の一構成例を示す。
無線端末１および無線端末２は、それぞれ、図３に示すように、ＭＡＣフレームを送受信する送受信部１１（第１送信部１１−１、第２送受信部１１−２）と、前述のＭＡＣフレームの生成や無線媒体（エア）へのアクセス制御を行うＭＡＣ機能ブロック（第１ＭＡＣブロック１２−１、第２ＭＡＣブロック１２−２）と、ホスト機能ブロック１３とを有する。

送受信部１１、ＭＡＣ機能ブロックおよびホスト機能ブロック１３は、それぞれ個別の電子回路として構成されてもよいし、これらのいくつかまたは全部が１つの電子回路として構成されてもよい。また、これらは、メモリデバイスに格納されてプロセッサによって実行されるファームウェアなどによって構成されてもよい。

送受信部１１は、図２のＰＨＹ機能ブロックに該当する機能を提供する。図３は、図２（Ｂ）の各ＭＡＣ機能ブロックにＰＨＹ機能ブロックが接続している場合を示している。図２（Ａ）のＰＨＹ機能ブロックが複数のＭＡＣ機能ブロック間で共通の場合は、送受信部１１を１つにし、各ＭＡＣ機能ブロックに接続するようにすればよい。図３では、２つのＭＡＣ機能ブロック１２がある例を示している。例えば、この各ＭＡＣ機能ブロック１２内にアソシエーションフレーム生成部１２１（アソシエーションフレーム生成部１２１−１、アソシエーションフレーム生成部１２１−２）がある。アソシエーションフレーム生成部１２１は、アソシエーションプロセスを実施するために必要なアソシエーション要求(Association Request)フレームまたはアソシエーション応答(Association Response)フレームの生成を行う。各ＭＡＣ機能ブロック１２は、ホスト機能ブロック１３に接続する。ホスト機能ブロック１３には、図２のAbstraction機能ブロックおよびその上位層に対応する機能ブロックが含まれる。

本実施形態では、IEEE 802.11規格の無線ＬＡＮシステムにおけるフレームが用いられる。このIEEE 802.11規格には、IEEE 802.11a、IEEE 802.11b、IEEE 802.11g、IEEE 802.11n、IEEE 802.11ac、IEEE 802.11ax等に加え、今後規定されるIEEE 802.11の後継規格も含まれる。

図４は、Managementフレームのフォーマット例を示す。Managementフレームは、ＢＳＳ（Basic Service Set）の構築や、ＳＴＡ（ＡＰも含む）との間の接続・切断などを行うためのフレームである。図４に示すフォーマットのフレームは、Managementフレームの他に、上位の機能ブロックからのパケットを運ぶDataフレームや、ＭＡＣレベルでの通信を制御するのに使うControlフレームなどが存在する。これらのフレームの種別は、後述するMAC Header部（ｂ１）のFrame Control（ｂ１１）内のTypeで識別され、さらにAssociation Requestなどといった細かい種別は、Frame Control内のSubtypeで識別される。

Managementフレームは，MAC Header部（ｂ１）、Frame Body部（ｂ２）およびFCS(Frame Check Sequence)部（ｂ３）を含む。
MAC Header部は、ＭＡＣ機能ブロックにおける受信処理に必要な情報を設定する。Frame Body部は、フレームの種類に応じた情報が設定される。FCS部は、MAC Header部とFrame Body部とが正常に受信できたか否かを判定するために用いる誤り検出コードであるCRC(Cyclic Redundancy Code)が設定される。

MAC Header部には、フレームの種類に応じた値が設定されるFrame Controlフィールド（ｂ１１）、Durationフィールド（ｂ１２）などが存在する。また、MAC Header部には、Addressフィールド（ｂ１３）が複数存在する。Address 1フィールドには、直接の受信側のＭＡＣアドレス（Receiving Address:RA）を設定する。Address 2フィールドには、直接の送信局のＭＡＣアドレス（Transmitting Address:TA）を設定する。Address 3フィールドには、BSSIDなどのアドレスを設定する。ＡＰがＢＳＳを構成する場合には、BSSIDはＡＰのＭＡＣアドレスと等しい。

また、MAC Header部には、Sequence Controlフィールド（ｂ１４）が存在する。Sequence Controlフィールドには、送信するデータのシーケンス番号や、データをフラグメント化した場合のフラグメント番号を設定する。

Frame Controlフィールド（Ｂ１１）には、フレームの種類を示すTypeフィールドおよびSubtypeフィールドや、To DSフィールド、From DSフィールド、モアフラグメント（more fragment）フィールド、プロテクト（protected）フレームフィールド、オーダー（order）フィールド等が存在する。

Typeフィールドに設定されるビット列によって、MACフレームが、Controlフレーム、ManagementフレームまたはDataフレームのうちのどのフレームタイプに属するフレームであるかを認識することができる。さらにSubtypeフィールドのビット列によって、各フレームタイプ内のＭＡＣフレームの種類が示される。

また、To DSフィールドには、受信局が無線基地局であるか、無線端末であるかの情報が設定され、From DSフィールドには、送信局が無線基地局であるか、無線端末であるかの情報が設定される。
More Fragmentフィールドは、データがフラグメント化された場合に、後続するフラグメントフレームが存在するか否かを示す情報を保持する。プロテクトフレームフィールドには、当該フレームがプロテクトされているか否かの情報が設定される。オーダーフィールドには、フレームを中継する際に、フレームの順序を入れ替えてはいけないことを示す情報が設定される。あるいは、オーダーフィールドの情報は、後述するオプションフィールドの有無を示す役割を持つこともある。

また、MAC Header部には、HT(High Throughput) Controlフィールド（ｂ１５）が存在し得る。HT Controlフィールドは、QoS DataあるいはManagementフレームのときに、オーダーフィールドが１に設定されていると存在するものである。HT Controlフィールドは、VHT(Very High Throughput)Controlフィールドにも、HE(High Efficient) Controlフィールドにも拡張可能であり、各々、IEEE 802.11n、IEEE 802.11acあるいはIEEE 802.11axの各種機能に応じた通知をすることができる。

なお、MAC Header部の構成は、上述したフィールドのみに限らない。新しいIEEE 802.11の後継規格が規定されることで、MAC Header部に新規フィールドが追加されることがある。
次に、無線端末１と無線端末２とがそれぞれＡＰとＳＴＡとの両方の役割を担えるように双方向のアソシエーション関係を構築するための処理について説明する。

ここで、ＡＰの役割とは、例えばIEEE 802.11axに基づくマルチユーザ通信（以下、ＭＵ通信）を利用して、同時に複数の宛先からパケットを収集したり、複数の宛先へパケットを送信したりすることを実行できる役割を指し、ＳＴＡの役割とは、前述のＭＵ通信における、ＡＰ以外の無線端末が果たす役割を指す。

また、アソシエーションとは、ＳＴＡがＡＰに接続する、言い換えれば、ＡＰが構築するＢＳＳに加入する接続プロセスの１つであり、通常、ＳＴＡの要求に対して、ＡＰが応答する。ＡＰが要求を許可した場合（応答フレームのStatus Code fieldが0(SUCCESS))、そのＳＴＡにAIDが割り当てられる。これによって、ＳＴＡは、ＡＰが構築するＢＳＳ内でデータフレームを送信できるようになる。

無線端末１における２つのＭＡＣ機能ブロック１２−１，１２−２をそれぞれＡＰ１、ＳＴＡ１と呼び、同様に、無線端末２における２つのＭＡＣ機能ブロック１２−１，１２−２をそれぞれＡＰ２、ＳＴＡ２と呼ぶ。つまり、無線端末１と無線端末２とは、それぞれ、互いに異なるＭＡＣアドレスを有するＭＡＣ機能ブロック１２−１，１２−２によって実現されるアクセスポイント部とステーション部とを有する。以下、ＳＴＡ１がＡＰ２に、また、ＳＴＡ２がＡＰ１に互いにアソシエーションする。

無線端末１と無線端末２との対称性より、ここでは、無線端末１から処理を開始する場合を考える。双方向のアソシエーション関係の構築に関する処理フローの一例を図５に示す。
双方向のアソシエーション関係の構築に関する処理フローは、無線端末２から送信されるBeaconやProbe Response、前提条件などからＡＰ２の存在および情報を既知とするＳＴＡが、ＡＰ２に対してManagementフレームの一例であるAssociation Request（Asoc Req）を送信することから開始される（Ｓ１１）。

ここで、ＡＰ２の情報は、少なくともＡＰ２のＭＡＣアドレスを含み、他にはSSID(Service Set Identifier)などアソシエーション上で必要かつ未知となっている情報が含まれる場合がある。
ＳＴＡ１は、Asoc Reqによって、 Capability Information、Listen Interval、接続したいSSIDを示す情報を通知するとともに、アソシエーションおよび通信に必要な情報（Supported Rates and BSS Membership SelectorsやPower Capabilityなど）を通知する。

ＳＴＡ１がAsoc ReqをＡＰ２に対して送信することによって、ＳＴＡ１とＡＰ２とのアソシエーションが開始されることとなるが、本実施形態では、さらに、Asoc Reqを利用して、無線端末１は、ＡＰ１の情報を無線端末２に通知する。
ここで、ＡＰ１の情報とは、アソシエーションを完了させるのに必要な情報（例えばＭＡＣアドレスやＡＰ１の通信チャネルなど）のうち、前提条件と定められているなどして既知であるものと、BeaconやProbe Responseを用いてＡＰ１からＳＴＡにすでに通知されているもの（ＡＰのＭＡＣアドレスがBSSIDとなるため、ＡＰのＭＡＣアドレスを通知してもらうことで、どのBeacon/Probe Responseかを対応づけることができる）を除いた情報のうち必要なものを示す。なお、通知するべき情報がない場合には、ＳＴＡ１が属する無線端末１にアソシエーション可能なＡＰ１が存在するということを示す情報が、ＡＰ１の情報ということとなる。このＡＰ１の情報により、無線端末２は、無線端末１が、互いに異なるＭＡＣアドレスが割り当てられたアクセスポイント部とステーション部とを有することを識別することができる。また、このＡＰ１の情報により、無線端末２は、後述するAsoc Reqを無線端末１へ送信することができる。

Asoc Reqを用いてＡＰ１の情報を通知する手段として、Association Request frame bodyに新たにelementを定義する、Association Request frame bodyの最後に付与されているVendor Specific elementを利用する、などが考えられる。現在、IEEE 802.11では、elementを識別するためのElement IDが枯渇しているため、最大値である255がElement IDにある場合には、Element ID Extensionサブフィールドが追加され、そこで識別できるようになっている。例えばこのElement ID Extensionサブフィールドとして既存のIEEE 802.11規格では割り当てられていない値を用いて、新規のElementを定義する。この新規elementあるいはVendor Specific elementに、ＡＰ１のＭＡＣアドレスの情報を少なくとも含める。ＡＰ１がBeaconフレームを送信していない場合には、従来Beaconフレームで通知する情報を入れるようにしてもよい。例えば、ＳＳＩＤを当該無線通信端末間で共有する場合には、ＡＰ２で用いるSSIDとＡＰ１で用いるSSIDとは共通であるので、従来はBeaconフレームで通知するところ、それを省略してもＳＴＡ２では既知として処理することができる。

なお、無線端末２が複数のＭＡＣ機能ブロックを持たない場合やElement IDを認識できない場合には、ＡＰ１とのアソシエーションは実行されず無視される。
Association Request frame bodyなどに入れられるelementのフォーマットを図６に示す。elementのフォーマットの基本構成は、先頭に、まずelementを識別するためのElement IDフィールド（ｃ１）があり、続いて、後続するフィールド長の総和をオクテット長で表すLengthフィールド（ｃ２）がある。Element IDフィールドが255の場合は、さらにElement IDの番号を拡張するためのElement ID Extensionフィールド（ｃ３）が設けられる。そして、そのElement IDに関する情報を格納するInformationフィールド（ｃ４）を含む。

Informationフィールドは、Element IDが0であるSSID Elementのように、１つの情報のみを含んでもよいし、Element IDが33であるPower Capabilityのように、複数の情報を含んでもよい。すなわち、任意の数で、Lengthフィールドで指定できる最大１オクテットまでの情報を通知することができる。Lengthフィールドの後に複数の情報フィールドを入れる場合には、各情報フィールドが固定値であれば、予め定義することによって受信側でも各情報フィールドから情報を抽出できる。情報フィールドの一部を可変長にしたい場合には、当該情報フィールドの前にフィールド長を特定するための必要なサブフィールドを追加すればよい。

ＡＰ１のＭＡＣアドレスをVendor Specificで定義したelementによってフレームを構成する例を説明する。Vendor Specific elementとは、IEEE 802.11無線ＬＡＮ規格で定義されない、各ベンダーの都合で通知したい情報を入れるために設けられているものである。

まず、Vendor Specific elementであることを通知するため、Element IDに221を設定する。次に、Lengthフィールドに、後続のOrganization IdentifierフィールドとVendor-specific contentフィールドの長さを表す値を設定する。Organization Identifierには、どの組織特有で利用するものかを識別できるようにし、Vendor-specific contentとして、本実施形態ではＡＰ１のＭＡＣアドレスを記載するようにする。

新規elementを定義する場合には、Element IDに255を設定し、Element ID Extensionには既存のIEEE 802.11規格で未使用の値(0〜8，12，52，…などがある)を用いるようにしてもよいし、あるいはElement IDとして既存のIEEE 802.11規格で未使用の値(例えば，2，8，9，…などがある)を用いるようにしてもよい．後者の場合は、Element ID Extensionフィールドは不要である。そして、Informationフィールドを例えばMAC Address of Co-located APフィールドと名づけ、そこにＡＰ１のＭＡＣアドレスを記載する。ＡＰのＭＡＣアドレスは当該ＡＰが構成するＢＳＳのBSSIDと等価であるので、MAC Address of Co-located APフィールドの代わりに、Co-located BSSIDフィールドとするのでもよい。ＡＰのＭＡＣアドレスは６オクテットであるので，Lengthフィールドは、Element ID Extensionフィールドを含める場合には7、Element ID Extensionフィールドが不要で存在しない場合には6となる。また、ＳＴＡ１のＭＡＣアドレスとＡＰ１のＭＡＣアドレスの一部（例えば先頭）が共通などの場合には、ＡＰ１のＭＡＣアドレスの６オクテットを全て表示せず、例えば先頭Ｘオクテットは共通で残り（６−Ｘ）オクテットがいくつ、というように短縮した表示方法なども考えられる。いずれにせよ、Asoc Reqを受信した無線端末側でＡＰ１に対するAsoc ReqをＳＴＡ２が生成することができる情報が、受信したAsoc Reqに含まれていればよい。図７は、Element IDを255とし、Element ID Extensionとして例えば60を選択し、６オクテットのMAC Address of Co-located APフィールドを入れたelement例である。例えばこの新規elementをCo-located AP Info element（ｃ４Ａ）とする。

図５に戻って、双方向のアソシエーション関係の構築に関する処理フローの説明を続ける。
（Ｓ１１）でAsoc Reqを受信したＡＰ２は、ＳＴＡ１からのアソシエーション要求を受け、同時に、ＳＴＡ１を持つ無線端末１がＡＰ１を持つことを知ることができる。これにより、ＡＰ２は、ＳＴＡ１とのアソシエーションを完了させるために、Managementフレームの一例であるAssociation Response（Asoc Rsp）をＳＴＡ１宛てに送信する（Ｓ１３）。加えて、ＡＰ２は、Abstraction機能ブロックを介して、ＳＴＡ２がＡＰ１とのアソシエーションするためのＡＰ１の新規情報を伝達する（Ｓ１２）。Abstraction機能ブロックは、各ＭＡＣ機能ブロックのＭＡＣアドレスを、テーブル等によって管理しており、ＡＰ２から受け取った情報を適切にＳＴＡ２に通知することが可能となっている。また、Station Management Entity（SME）を実施する機能ブロックを別途設け、それを利用して情報を通知してもよい。ここで、SMEは、すべてのＭＡＣ機能ブロックと接続している、各ＭＡＣ機能ブロックにアソシエーション開始などの命令や情報を伝達することが可能な管理部である。

このように、ＡＰ２がＳＴＡ２に情報を通知する方法は多数あり、本実施形態は特定の方法に限定されない。また、（Ｓ１２）と（Ｓ１３）の順序は逆であってもよい。
Asoc Rspによって、Capability Informationや、Status code、ＡＰからＳＴＡに割り当てられるAIDの他に、必要に応じた情報（例えば、Supported Rates and BSS Membership SelectorsやEDCA Parameter Setなど）が通知される。

ＳＴＡ１は、受信したAsoc Rspを処理し、Status Codeの値が0、すなわちSuccess （成功）である場合には、これによってＡＰ２とＳＴＡ１とのアソシエーション関係が成立する。アソシエーション関係が成立すると、ＡＰ２とＳＴＡ１との間でデータフレームの交換が可能となる。

一方、ＡＰ１の情報が通知されたＳＴＡ２では、その情報に基づいて、Asoc ReqをＡＰ１宛てに作成して送信する（Ｓ１４）。
ＡＰ１は、受信したAsoc Reqを処理し、ＳＴＡ２にAsoc Reqを送信する（Ｓ１５）。
ＳＴＡ２は、受信したAsoc Rspを処理し、これによってＡＰ１とＳＴＡ２とのアソシエーションが完了する。

無線端末１が始めに送信するAsoc Reqがトリガーとなって、複数のアソシエーション関係（ＡＰ２とＳＴＡ１とのアソシエーション関係およびＡＰ１とＳＴＡ２とのアソシエーション関係）が構築されることによって、以下の利点が得られる。
まず、無線端末２が、ＡＰ１とＳＴＡ１が無線端末１に含まれていること（co-locatedであること）を知ることができる。従来、neighborレポートを利用して、あるＡＰが他のＡＰの存在を通知する方法は存在するが、co-locatedであるかは通知されない。当然、あるＡＰが当該ＡＰとco-locateするＳＴＡの情報を通知することも、また、その逆であるＳＴＡが当該ＳＴＡとco-locateするＡＰの情報を通知することもできない。

また、チャネルスキャンの効率化が行える。従来、相互のアソシエーション関係を構築するためには、ＳＴＡ１、ＳＴＡ２がそれぞれ独立にＡＰ２、ＡＰ１の通信チャネルを検出して、アソシエーション処理を開始する（co-locatedであることは認識できない）。一方、本実施形態では、片側が通信チャネルを検出できれば、アソシエーションを開始するフレームが送信され、それをトリガーに両アソシエーションが完了されるため、より効率的にアソシエーションが行える。特に、ＰＨＹ機能ブロックが共通の場合、ＡＰとＳＴＡでチャネルを毎回切り替える必要がない。また、ＰＨＹ機能ブロックが複数の場合でも、チャネル検出にかかる時間は軽減され、同じ無線端末のＡＰとＳＴＡのチャネルが被っている時の対処を考慮に入れる必要がない。

また、無線端末が互いにアソシエーションすることによって、メッシュネットワークを構成する無線端末間が互いにＡＰの役割を行うことができる。これによって、ルーティングやルートダイバーシチ、ネットワークモニタリングなど様々な場面において、マルチユーザ通信が実行可能となり、情報伝送の時間効率向上が期待できる。

なお、アップリンクＭＵ通信によってフレームが送信されるのであればＳＴＡが、ダウンリンクＭＵ通信によってフレームが送信されるのであればＡＰが、それぞれそのフレームを処理すべきＭＡＣ機能ブロックとなるが、このような上位の機能ブロックから入力されたデータをどのＭＡＣ機能ブロックに振り分けるかの判断は、Abstraction機能ブロックによって行われる。 Abstraction機能ブロックは、テーブルなどを用いて、各ＭＡＣ機能ブロックのＭＡＣアドレスを管理しており、振り分けに関する何らかのルールやポリシーを設けることにより、上位機能ブロックからのデータをＭＡＣ機能ブロックに振り分けられる。

以上のように、本実施形態の電子装置においては、同一の外部装置との間であることを認識しつつ双方向のアソシエーション関係を構築することができる。
（第２実施形態）
次に、第２実施形態について説明する。
本実施形態は、基本的には、第１実施形態に基づいているため、ここでは、その差分を説明する。

図８Ａおよび図８Ｂは、本実施形態の電子装置（無線端末１および無線端末２）における双方向のアソシエーション関係の構築に関する処理フローの一例をそれぞれ示す図である。
本実施形態が第１実施形態と異なる点は、第１実施形態では、ＡＰ２からＳＴＡ１へのAsoc Rspと、ＳＴＡ２からＡＰ１へのAsoc Reqとを別々に送信していたのに対し、Asoc ReqとAsoc Rspとを同一の物理パケット（物理フレーム）にまとめる点である。図８Ａは、ＡＰ２がAsoc RspとAsoc Reqとの集約を行い、ユニキャストまたは多重化のうちのいずれかの手段を用いて無線端末１へ送信する場合の例を示している。一方、図８Ｂは、ＳＴＡ２がAsoc Rsp とAsoc Reqとの集約を行い、ユニキャストまたは多重化のうちのいずれかの手段を用いて無線端末１へ送信する場合の例を示している。図８Ａおよび図８Ｂを参照して、本実施形態における双方向のアソシエーション関係の構築に関する処理フローを説明する。なお、第１実施形態と同様、無線端末１から処理を開始する場合を考える。

本実施形態においても、双方向のアソシエーション関係の構築に関する処理フローは、無線端末２から送信されるBeaconやProbe Response、前提条件などからＡＰ２の存在および情報を既知とするＳＴＡ１が、ＡＰ２に対してAsoc Reqを送信することから開始される（Ｓ２１）。

ＳＴＡ１からAsoc Reqを受信したＡＰ２は、Asoc Reqに内包されるＡＰ１の情報から、ＳＴＡ１を有する無線端末１がＡＰ１も有することを知ることができる。ＡＰ２は、ＳＴＡ１とのアソシエーションを完了させるためのAsoc Rspを作成する。さらに、ＡＰ２は、ＳＴＡ２がＡＰ１とアソシエーションプロセスを開始できるように、取得したＡＰ１の情報を伝達する（Ｓ２２）。

なお、第１実施形態と同様、無線端末２が複数のＭＡＣ機能ブロックを持たない場合やElement IDを認識できない場合には、ＡＰ１とのアソシエーションは実行されず無視され、処理は終了される。
フレームの多重化には、フレームアグリゲーションや、それぞれ異なる周波数帯域幅を用いてフレームを送信する周波数多重化、複数のアンテナで送信する空間分割多重化、それぞれ異なる符号を使って送信する符号多重化、および、同じ周波数帯域幅でも、それぞれ異なるサブキャリアを用いてフレームを送信する直交周波数多重化などがある。
なお，処理フローの現ステップ（Ｓ２２）では、アソシエーションが完了していないため、多重化を行うために必要であるが共有できていない情報が存在する場合がある。例えば、IEEE802.11ax規格において周波数多重化や空間多重化を利用し、ＳＴＡ１へのAsoc RspとＡＰ１へのAsoc Reqを多重送信する場合には、ダウンリンク（Downlink:DL）多重の形態をとることになる。この場合、PHYヘッダに含まれるHE-SIG-Bに各リソースユニットあるいは各ストリームの送信先を示すため、AID情報が必要となるが、AID情報は、アソシエーションによって共有される情報である。そこで、不足している情報がある場合には、前ステップ（Ｓ２１）で送達されたフレームによって、テンポラリの値を割り当てることを考える。

アソシエーションプロセス中に多重送信を実現するためテンポラリのAID値を割り当てることを例にとれば、新しくTemporary AIDs for Association Intervalというelementを設ける。このelementで、ＳＴＡ１へのAsoc RspとＡＰ１へのAsoc Reqとが多重化されたフレームを識別するため、ＳＴＡ１／ＡＰ１側の無線端末１で各々に一時的に割り当てるAIDを指定し、ＳＴＡ１からＡＰ２へ送信するAsoc Reqの中に含める。この一時的なAIDも従来のAIDの範囲である1から2007の値の中から取るようにする場合、すでに割り当てているAIDがあるならば、それを除いて選択するようにすることが望ましい。

例えばＳＴＡ１の一時的なAIDとして2001を、ＡＰ１の一時的なAIDとして2002を用いるように、Temporary AIDs for Association Interval elementでＳＴＡ１がAsoc Reqで指定したとする。ＡＰ２は、Asoc Reqを受信して復号し、ＳＴＡ１はAIDを2001、ＡＰ１はAIDを2002とHE-SIG-Bフィールドに指定すれば、送信した多重パケットがＳＴＡ１／ＡＰ１の無線端末側で受信・復号できると把握する。例えば直交周波数分割多元接続方式を多重方式として考えた場合、ＳＴＡ１宛てのAsoc Rspを例えばあるサブキャリアグループ１（これをResource Unit(RU)１とも表す）で、ＡＰ１宛てのAsoc Reqを別のサブキャリアグループ２（これをRU2とも表す）で送信するようにし、その多重パケットのPHYヘッダのHE-SIG-Bフィールドで、AID=2001宛てのPHYペイロード（すなわちMACフレーム）はサブキャリアグループ１を用いていること、AID=2002宛てのPHYペイロードはサブキャリアグループ２を用いていることを通知するようにすれば、ＳＴＡ１またはＡＰ１で各々当該PHYパケットを受信して、所望のPHYペイロードを復号することができる。

このHE-SIG-Bで用いるAIDは、1から2007の値の範囲に限定される場合には１１ビットあれば十分であるため、Temporary AIDs for Association Interval elementで指定する各AIDも１１ビットまでで表現すればいいことになる。例えば一時的なAIDがＡＰ用かＳＴＡ用かを識別するためにAP/STA Indicationサブフィールドを設け、そのサブフィールドが1であればＡＰ用、0であればＳＴＡ用とし、その後に一時的なAIDを書き込むサブフィールドを設けるということが考えられる。その場合は、例えば図９のようになる。

これでは２つの一時的なAIDを割り当てる場合にしか適用できないが、Temporary AIDs for Association Intervalフィールド（ｃ４Ｂ）を可変長にすれば、その制限を外すこともできる。また、この表現方法では、ＳＴＡ１がAID=2001、ＡＰ１がAID=2002であることを明示的に表現しているわけではないため、ＡＰ２で、先のMAC Address of Co-located AP elementと合わせて、ＳＴＡ用のAID=2001はＳＴＡ１に、ＡＰ用のAID=2002はＡＰ１に対応づけることが必要になる。一方、ＳＴＡ１のＭＡＣアドレスとその一時的なAID、ＡＰ１のＭＡＣアドレスとその一時的なAIDを通知する、というようにしてもよい．この場合は、先のMAC Address of Co-located AP elementは、当該elementで通知しているため不要になる。ここで、DL MUのPHYパケットには、IEEE 802.11axではBSS_COLORというＢＳＳを識別するための値が入れられる。ＡＰ２からＳＴＡ１へのAsoc Rspと、ＳＴＡ２からＡＰ１へのAsoc RspをＡＰ２が多重化して送信する場合、例えばこの多重化したPHYパケットのBSS_COLORにはＡＰ２が用いているBSS_COLORを用いるようにすればよい。

以上によって、HE-SIG-Bを構成するのに必要な情報が得られ、周波数多重や空間多重などが利用可能となる。このように、アソシエーションが完了する前であっても、テンポラリ値を割り当てることによって、様々な多重化技術を利用することができる。

図８Ａおよび図８Ｂに戻って、双方向のアソシエーション関係の構築に関する処理フローの説明を続ける。
ＡＰ２が集約を行う場合（図８Ａ）、ＡＰ１の情報を通知されたＳＴＡ２は、その情報を利用して、Asoc Req生成に必要な情報をＡＰ２に通知するか、ＡＰ１宛てのAsoc ReqをＡＰ２に送る（Ｓ２３）。

Asoc Req生成に必要な情報は、例えば、IEEE 802.11無線ＬＡＮ規格でのSMEからMLME(MAC sublayer management entity)に入力されるMLME-ASSOCIATE.requestプリミティブのパラメータを参考にすればよい。ここで、ＡＰ２は、Asoc Reqのための情報を受けた場合には、ＳＴＡ２からＡＰ１宛てのAsoc Reqを代理で作成する。この結果、ＡＰ２は、自身が作成したAsoc Rspと合わせて、Asoc ReqとAsoc Rspを集約できる。

一方、ＳＴＡ２が集約を行う場合には（図８Ｂ）、ＡＰ２が、ＡＰ１の情報通知の他に、Asoc Rspの生成に必要な情報またはＳＴＡ１に送信予定のAsoc RspをＳＴＡ２に渡す（Ｓ２３’）。同様に、ＳＴＡ２は、自身が作成したAsoc Reqと合わせて、Asoc ReqとAsoc Rspを集約できる。

Asoc RspとAsoc Reqの集約を行ったＡＰ２またはＳＴＡ２は、前述の通り、それぞれをユニキャスト、多重化のうちいずれかの手段を利用して無線端末１へ送信する（図８Ａ：（Ｓ２４）、図８Ｂ：（Ｓ２４’））。
ここで、フレームアグリゲーションを利用して送信を行う例について述べる。Asoc RspとAsoc Reqをフレーム集約してA-MPDU(Aggregate MAC Protocol Data Unit)を構成し、送信する場合は、Asoc RspのMACヘッダの最初のアドレス１フィールドには送信先アドレス(Receiver Address:RA)としてＳＴＡ１のＭＡＣアドレス、次のアドレス２フィールドには送信元アドレス(Transmitter Address:TA)としてＡＰ２のＭＡＣアドレス、アドレス３フィールドにはBSSIDとしてＡＰ２のMACアドレスが入れられる。Asoc ReqのMACヘッダのアドレス１フィールドにはRAとしてＡＰ１のＭＡＣアドレス、アドレス２フィールドにはTAとしてＳＴＡ２のMACアドレス、アドレス３フィールドにはBSSIDとしてＡＰ１のＭＡＣアドレスが入れられる。この場合、先頭のAsoc RspのRAがＳＴＡ１に指定されていることにより、ＳＴＡ１がこのA-MPDUを受信・復号することになる。

逆に、ＳＴＡ２からA-MPDUを送信する場合には、Asoc Reqを先頭にしてAsoc Rspを次に入れるようにした方が望ましい。こうすることで、先頭のAsoc ReqのRAがＡＰ１に指定されていることにより、ＡＰ２がこのA-MPDUを受信・復号することになる。

図１０は、Asoc Rsp、Asoc Reqの順でフレームがアグリゲーションされた例である。Asoc RspとAsoc Reqとは、それぞれ、MPDU（ｄ１）としてMPDU delimiter（DLM）（ｄ１１）で境界がわかるように接続される。MPDU delimiterは、４オクテットの長さを持ち、MPDU長や8bitCRC、MPDU delimiterであることを示すDelimiter Signatureなどから構成される。

以上の例は、アグリゲーションされたAsoc RspとAsoc ReqそれぞれのMACヘッダに正しく送信先アドレスが指定された場合について述べているが、「Asoc RspはＳＴＡが処理するべきフレーム」、「Asoc ReqはＡＰが処理すべきフレーム」であるという特性を利用することででき、あるいは、さらに、前述と同様に、意図する受信先端末（ＳＴＡまたはＡＰ）への正しい情報をelementに含めることで、必ずしも前述の例のようにフレームがアグリゲーションされている必要はない。例えば、ＡＰ１がAsoc Rspを受信し、RAにＡＰ１が指定されていたとしても、通常、Asoc Rspを処理するのは、ＡＰではなくＳＴＡであり、同一無線端末にＡＰとともにＳＴＡも内包していることを把握しているため、TAがＡＰ１であっても、ＡＰ１はＳＴＡ１にAsoc Rspを渡すことが可能である。

また、新しくReceiver Address of This Association Frame elementを設け、そのInformationフィールドにそのelementを格納するアソシエーションフレームを受ける本来のＭＡＣアドレス、すなわちＭＡＣ機能ブロックを指定し、途中で本来は宛先の変わるアソシエーションフレーム（Asoc Rspの次にAsoc Reqが来る順番ならAsoc Req）のフレームボディに格納するようにすれば、Asoc ReqのMACヘッダのRAにＡＰ１が指定されていても、当該MACフレームを処理する段階でＡＰ１のＭＡＣ機能ブロックはＳＴＡ１のＭＡＣ機能ブロックにAsoc Rspを、あるいはAsoc Rspのフレーム内から抽出した情報を渡せば、ＳＴＡ１のＭＡＣ機能ブロックでAsoc Rspを受信したと同様の処理ができ、ＡＰ２との間でアソシエーションプロセスが終了した(Asoc Rspの中のStatus Codeが0 (SUCCESS)の場合には、AIDフィールドによって割り当てられたAIDを今後ＡＰ２との間で用いることも含め)と把握できる。

図８Ａおよび図８Ｂに戻って、双方向のアソシエーション関係の構築に関する処理フローの説明を続ける。
ＡＰ２またはＳＴＡ２が送信したフレームは、ＳＴＡ１とＡＰ１それぞれが正しく受信する場合と、ＡＰ１がAsoc Rsp、ＳＴＡ１がAsoc Reqといった、本来と異なるＭＡＣMAC機能ブロックが受信する場合がある。後者の場合、ＡＰ１およびＳＴＡ１は、受信したフレームを処理できないため、他のＭＡＣ機能ブロックへAbstraction機能ブロックなどを介して転送する（図８Ａ：（Ｓ２５）、図８Ｂ：（Ｓ２５’））。

このとき、フレームをMAC protocol data unit（MPDU）の形で他のＭＡＣ機能ブロックに転送してもよいし、MAC service data unit（MSDU）の形で他のＭＡＣ機能ブロックに転送してもよいし、具体的な情報レベルで他のＭＡＣ機能ブロックに転送してもよい。MPDUの形で他のＭＡＣ機能ブロックに転送する場合には、他のＭＡＣ機能ブロックのPHYとのI/Fを介して入力するようにしてもよい。これに関しては、ルール化されているものとし、本実施形態では、所望の情報が正確に他のＭＡＣ機能ブロックに通知されればよく、その方法は限定しない。

ここで、保有しているすべてのＭＡＣ機能ブロックで処理できない場合、そのフレームは破棄される。
ＳＴＡ１は、受信したAsoc Rspを処理し、これによって、ＡＰ２とＳＴＡ１とのアソシエーションが完了する。また、ＳＴＡ２は、受信したAsoc Rspを処理し、これによって、ＡＰ１とＳＴＡ２とのアソシエーションが完了する。

以上のように、本実施形態の電子装置においては、第１実施形態に加えて、フレームを集約して多重化して送信されていることから、より効率化される。
（第３実施形態）
次に、第３実施形態について説明する。
本実施形態は、基本的には、第２実施形態に基づいているため、ここでは、その差分を説明する。

図１１Ａおよび図１１Ｂは、本実施形態の電子装置（無線端末１および無線端末２）における双方向のアソシエーション関係の構築に関する処理フローの一例をそれぞれ示す図である。
本実施形態が第２実施形態と異なる点は、第２実施形態では、ＳＴＡ１から送信されるAsoc Reqがトリガーとなってアソシエーションが実行されるための処理フローが開始されていたことに対し、このAsoc Reqを省略する点である。このため、本実施形態では、無線端末１が、第２実施形態における無線端末２と似た動作を行い、無線端末２が、第２実施形態における無線端末１と似た動作を行う。

本実施形態では、ＡＰ１がＳＴＡ２の存在と情報を既知とすることを想定し、ＳＴＡ２からAsoc Reqを受けていないにも関わらず、無線端末１は、ＳＴＡ２を送信先としたAsoc Rspを送信する。つまり、第２実施形態で図８Ａおよび図８Ｂに示した（Ｓ２１）を省略する。

ここで、ＳＴＡ２の存在と情報を既知とする手段には、BeaconやProbe Responseを利用すること、または前提条件によって取り決められていることを考える。BeaconまたはProbe Responseによって情報を通知する場合には、Vendor Specific informationを利用する、または、全く新しいelementを追加する。これによって、無線端末内に存在する他のＳＴＡまたはＡＰの情報を通知することができる。前提条件によって、無線端末内に存在するＡＰ／ＳＴＡの存在の有無に関する情報を既知とする場合、例えば、ネットワークに追加される無線端末は、必ず２つのＭＡＣ機能ブロックを持ち、それぞれのＭＡＣアドレスは１違いで、ＡＰの方が小さい（0に近い）ＭＡＣアドレスであるなどのルールなどを定める方法が考えられる。この場合、新たにネットワークに追加された無線端末のＡＰのＭＡＣアドレスは、Beaconなどを受信することで、そのMACヘッダにあるTAあるいはBSSIDを通知するアドレスフィールドから取得できる。例えば少なくとももう１つＳＴＡとしてＭＡＣ機能ブロックがあるというのが前提条件であれば、同時に当該もう１つのＳＴＡのＭＡＣ機能ブロックのＭＡＣアドレスは、ＡＰのＭＡＣアドレスの末尾を１繰り上げたものと把握することができる。

無線端末１は、Asoc ReqとAsoc Rspを無線端末２へ送信する。図１１Ａおよび図１１Ｂは、これらのアソシエーションフレームを、ＳＴＡ１（図１１Ａ）またはＡＰ１（図１１Ｂ）が集約して送信する例を示している。なお、第１実施形態のように、ＡＰ１がAsoc Rspを、ＳＴＡ１がAsoc Reqをそれぞれ送信するようにしてもよい。

ＳＴＡが集約して送信を行う場合（図１１Ａ）、ＡＰ１は、Asoc Rspフレームまたは生成に必要な情報をＳＴＡ１に伝達する（Ｓ３１）。一方、ＡＰ１が集約して送信を行う場合（図１１Ｂ）、ＳＴＡ１は、Asoc Reqフレームまたは生成に必要な情報をＡＰ１に伝達する（Ｓ３１’）。

以降は、第２実施形態の場合と無線端末１，２が逆転して、同様にフローを進める（Ｓ３２［Ｓ３２’］、Ｓ３３［Ｓ３３’］）。
最後に、ＡＰ２は、Asoc RspをＳＴＡ１に送信し、アソシエーション関係が構築される（Ｓ３４［Ｓ３４’］）。ここで、ＡＰ１とＳＴＡ２のアソシエーション関係の構築結果を示す情報（フラグ）をこのAsoc Rspに追加してもよい。例えば、Status Code of The Other Associationという新規のelementを定義し、通常のStatus Codeフィールドと同様の値の割り当て方にし、受信したＡＰ１からＳＴＡ２へのAsoc RspのStatus Codeの内容をコピーして入れる。例えばＡＰ１からＳＴＡ２へのAsoc RspのStatus Codeが0でSuccess (成功)であるなら、それと同様の値をStatus Code of The Other Association elementに入れ、ＡＰ２からＳＴＡ１へのAsoc Rspに含める。このelementを用いる方法では、図１１Ａの例の場合、ＳＴＡ１はＡＰ１に対し、ＡＰ１とＳＴＡ２のアソシエーション関係の結果を通知する必要がある（Ｓ３５）。この結果、ＡＰ１は、必ず、ＡＰ１からＳＴＡ２へ送信したAsoc Rspが正しくＳＴＡ２で受信され、ＡＰ１とＳＴＡ２のアソシエーション関係が構築できたと判断することができる。このように、無線端末１は、Asoc Rspの送信に基づき、無線端末２とのアソシエーション関係が構築されたと判断することができる。

あるいは、ＡＰ１が、ＡＰ１からＳＴＡ２へ送信したAsoc RspがＳＴＡ２で受信成功したことを、ＡＰ１からＳＴＡ２へ送信されるAsoc Req＋Asoc Rsp（ここで、＋は、アグリゲートすることまたは多重することを意味する）に対し、ＳＴＡ２がAckまたはBlockAckを送信することで、把握するようにしてもよい。通常の動作として、ユニキャストのＭＡＣアドレスをRAとして指定した管理フレームに対しては、受信側でAckフレームを当該管理フレームのSIFS (Short Interframe Space)後に送信するようになっている。SIFSとは送受信の切り替えが実施される際に必要な最小フレーム間隔であり，例えば５GHz帯の２０MHzチャネル間隔で用いるIEEE 802.11無線ＬＡＮの場合はその値は１６usである。これまでのフレーム交換を示す図（図５、図８Ａ、図８Ｂ）では、このSIFS後のAckフレームまたは後述のBlockAckフレーム送信は省略している。管理フレームであるAsoc ReqやAsoc Rspは、このSIFSよりも長い固定時間及びランダムなバックオフ期間を取って送信される。そこで、Asoc Req＋Asoc Rspの形態で送信されたフレームに関しても、Ackフレームを送信する。この場合、Ackフレームは図１１Ａの例では、ＡＰ２からＳＴＡ１に送信されることになるため、ＳＴＡ１は、ＡＰ１に対し、ＡＰ１からＳＴＡ２へのAsoc RspがＳＴＡ２で正しく受け取られたことを通知する必要がある（Asoc Req＋Asoc Rsp送信のSIFS後にAckを受信するので、その際にＳＴＡ１からＡＰ１への通知が（Ｓ３５）の代わりに発生する）。

なお、Asoc ReqとAsoc Rspの２つのフレームがアグリゲートされている形態では、その個々のMACフレームに対し，本来はAckフレームを送信すべきであるため、IEEE 802.11axのMulti-STA BlockAckを応用した形態で応答するようにしてもよい。例えばこのBlockAckフレームは図１２のようにする。BA Controlフィールド（ｅ１）のBA Typeサブフィールドは、新規のBlockAck variantを定義するようにしてもよいが、ここでは、IEEE 802.11axのMulti-STA BlockAckを利用する場合で説明する。Multi-STA BlockAckでは、BA Typeサブフィールドの値は１１となる。BA Informationフィールド（ｅ２）は、Per AID TID Infoサブフィールド単位になるが、最初のPer AID TID Infoサブフィールド（ｅ２１）はＳＴＡ１宛て、２つ目のPer AID TID Infoサブフィールド（ｅ２２）はＡＰ１宛てに対するAckを通知するものとなり、各RAフィールドには各々のＭＡＣアドレスが入る。なお、Multi-STA BlockAck全体としてはMACヘッダの先頭のアドレスフィールドにRAを入れることになるが、このRAにはブロードキャストアドレスが入る。従って、Multi-STA BlockAckは、ＡＰ１とＳＴＡ１が各々受信して送達確認を得られることになるため、elementやAckのときのようにＳＴＡ１からＡＰ１への通知は必要ない（（Ｓ３５）のようにＳＴＡ１からＡＰ１への通知は不要）。各AID TID InfoサブフィールドはさらにAID11、Ack Type、TIDのサブフィールドに分かれているが、これらにはＳＴＡ１宛て、ＡＰ１宛てに関わらず、共通でAID11には2045、Ack Typeは0、TIDは15と設定する。これは後述するUORAで未接続の各ＳＴＡが送信した管理フレームに対し、Multi-STA BlockAckの形態でAck応答を送信する方法と同じである。このようなMulti-STA BlockAckを送信することによって、ＳＴＡ１は、Per AID TID InfoサブフィールドのRAサブフィールドに自ＭＡＣアドレスが記載されていることで、ＳＴＡ１からＡＰ２に送信したAsoc ReqがＡＰ２で受信されたことを把握できる。また、ＡＰ１は、Per AID TID InfoサブフィールドのRAサブフィールドに自ＭＡＣアドレスが記載されていることで、ＡＰ１からＳＴＡ２に送信したAsoc RsqがＳＴＡ２で受信されたことを把握でき、ＳＴＡ２との間でアソシエーションプロセスが終了したとすることができる。なお、ここでいずれかのPer AID TID Infoサブフィールドがなければ、そのフレーム受信が無線端末２側でなかったことを意味する。したがって、適宜フレームの再送が発生することになる。

逆に、無線端末１側でＡＰ１とＳＴＡ２のアソシエーション関係が構築できたと確認できない場合には、ＡＰ１は、Asoc Rspを再送する必要が生じるが、ＡＰ１がどの過程を経てAsoc Rspを再送信するかについては、いくつかの手順を適用し得る。

たとえば、（Ｓ３２）［図１１Ａの場合］に対するACKがあると期待され、それを用いて再送判断する場合、ＳＴＡ１が（Ｓ３２）でフレームを送信した後、一定時間（SIFS時間）後に受信するAsoc Rspに対するACKの有無をＡＰ１に通知する。この結果、ＡＰ１もAsoc Rspに対するACKの有無を知ることができ、無ければAsoc Rspの再送処理に入る（厳密にはCSMA/CAに基づき送信機会を獲得して送信する。以降も同様）。

また、（Ｓ３２’）［図１１Ｂの場合］に対するACKがあると期待され、それを用いて再送判断する場合、このACKを受け取るのはＡＰ１であるため、（Ｓ３２’）でフレームを送信した後、一定時間（SIFS時間）後ACKがなければ、Asoc Rspの再送処理に入る。

または、（Ｓ３２）あるいは（Ｓ３２’）に対しMulti-STA BlockAckがあると期待され、それを用いて再送判断する場合、このMulti-STA BlockAckはＡＰ１及びＳＴＡ１の各々で受信できるため、（Ｓ３２）あるいは（Ｓ３２’）でフレームを送信した後、一定時間（SIFS時間）後にＡＰ１がMulti-STA BlockAck自体を受信しない場合、あるいはMulti-STA BlockAckのPer AID TID InfoサブフィールドのRAサブフィールドにＡＰ１のＭＡＣアドレスを検出できなかった場合、ＡＰ１はAsoc Rspの再送処理に入る。

あるいは、（Ｓ３４）［図１１Ａの場合］におけるAsoc Rspで通知される場合、ＡＰ１は、ＳＴＡ１から（（Ｓ３２）で送信したAsoc RspのACKの有無を受けるのではなく）（Ｓ３４）のAsoc Rspに示された内容（Status Code of The Other Association elementまたはACK bit）の通知を受ける。この結果、ＡＰ１とＳＴＡ２とのアソシエーションが構築されていないと判明した場合にＡＰ１はAsoc Rspの再送処理に入る。

本実施形態において、ＡＰ１からＳＴＡ２に対するAsoc Rspが、Asoc Reqを省略して送信されていることに関して、例えば、ＳＴＡ２がすでに他のＡＰとアソシエーション関係を構築しているなどして、ＳＴＡ２がAsoc Rspを受け付けられない場合に、明示的にＡＰ１にそのことを伝えることは重要である。これは、ＡＰ１がAsoc Rspをアソシエーション不可のＳＴＡ２へ何度も送信することを回避するためである。

次に、以上について、ここまでで説明した、Status Code of The Other Association elementを利用し、Asoc RspのStatus Codeが0（(成功)をコピーするのではなく、他の不成功を意味するいずれか適当なStatus Codeに書き換える方法以外である、Disassociationフレーム（DisAsoc）を用いる手段について述べる。

DisAsocを用いることによって、ＳＴＡは、アソシエーション関係を構築しているＡＰへ、関係破棄を通知できる。DisAsocには、Reason Codeフィールドをフレームボディに入れるようになっている。そのReason Codeフィールドを用いてアソシエーション関係を取り下げる理由を通知することで、DisAsocを受信したＡＰ１でその後適切な判断をする助けになる。例えば、Reason CodeにはＳＴＡが別のＡＰへと移りたいという理由を表すものとして１２のBSS_TRANSITION_DISASSOCというものがある。このようにすることによって、現状でアソシエーション関係を構築しているＡＰに、関係破棄を理由とともに通知できる。既存のreason codeで定義されている値を利用する以外に、具体的に本実施形態でのＳＴＡの拒否理由を通知する場合には、reservedとなっているreason code 0, 67-65 535に新規定義を行ってもよい。例として、ＳＴＡ２がすでに他のＡＰとアソシエーション関係を構築しているため、ＡＰ１とアソシエーション関係を構築できないとき、STA_ASSOCIATEDという意味のreason code を例えば67として新規定義すれば、reason code 67を入力したDisAsocフレームによって、ＡＰ１にその内容を通知できる。

以上のように、本実施形態の電子装置においては、第２実施形態におけるＳＴＡ１からのAsoc Reqの送信（図８Ａ：（Ｓ２１）、図８Ｂ：（Ｓ２１’））を省略することができる。
（第４実施形態）
次に、第４実施形態について説明する。
本実施形態は、基本的には、第３実施形態に基づいているため、ここでは、その差分を説明する。

図１３Ａおよび図１３Ｂは、本実施形態の電子装置（無線端末１および無線端末２）における双方向のアソシエーション関係の構築に関する処理フローの一例をそれぞれ示す図である。
本実施形態が第３実施形態と異なる点は、第３の実施形態では、無線端末１からのAsoc ReqとAsoc Rspをトリガーとして処理が開始されていることに対し、これらのうちのいずれか一方を送信する点である。

つまり、本実施形態では、前述の第３実施形態において（Ｓ３２）［図１１Ａ］またはＳ３２’［図１１Ｂ］で送信しているAsoc ReqとAsoc Rspの片方を送信しない。片方が送信されない場合、それぞれ、本来通知すべき情報が不足することは明確である。逆に考えると、この不足した情報を互いに共有できれば、片方を送信せずにアソシエーション関係の構築を実行することができる。

不足する情報の例として、Asoc Reqを送信しない場合には、ＳＴＡ１のＭＡＣアドレスなどが考えられ、一方、Asoc Rspの場合は、ＳＴＡ２に割り当てられたAIDなどが考えられる。Asoc ReqとAsoc Rspの片方を送信せずに、これらの情報を如何にして共有するかについては、たとえば、前提条件によって、これらの情報を共通情報としてもよいし、BeaconやProbe Responseを用いて、これらの情報について事前に情報共有を行ってもよい。

また、送信していない方のアソシエーションフレームの情報を、送信している方のアソシエーションフレームの情報または既知の情報と共通にし、または、ルール化により、送信している方のアソシエーションフレームの情報または既知の情報から算出可能にしてもよい。Asoc RspとAsoc Reqで共通化できる情報としては、例えば、HT Capabilityが考えられる。また、ＡＰ１とＳＴＡ１のＭＡＣアドレスを連番などと取り決めていれば、ＡＰ１のＭＡＣアドレスからＳＴＡ１のＭＡＣアドレスが算出でき、逆に、ＳＴＡ１のＭＡＣアドレスからＡＰ１のＭＡＣアドレスを算出することもできる。

さらには、送信している方のアソシエーションフレームに、送信しない方の情報を新規elementまたはVendor specific elementとして追加してもよい。このように、無線端末１は、無線端末２へ送信したAsoc Req（ＡＰ２−ＳＴＡ１間）に対する無線端末２からのAsoc Rspの受信に基づき、無線端末２との間で双方向（ＡＰ１−ＳＴＡ２間およびＡＰ２−ＳＴＡ１間）のアソシエーション関係が構築されたと判定することができるし、または、無線端末２へAsoc Rsp（ＡＰ１−ＳＰＡ２間）を送信した後の無線端末２からのAsoc Rsp（ＡＰ２−ＳＰＡ１間）の受信に基づき、無線端末２との間で双方向（ＡＰ１−ＳＴＡ２間およびＡＰ２−ＳＴＡ１間）のアソシエーション関係が構築されたと判定することができる。一方、無線端末２は、無線端末１から受信したAsoc Req（ＡＰ２−ＳＴＡ１間）に対する無線端末１へのAsoc Rspの送信に基づき、無線端末１との間で双方向（ＡＰ１−ＳＴＡ２間およびＡＰ２−ＳＴＡ１間）のアソシエーション関係が構築されたと判定することができるし、または、無線端末１からAsoc Rsp（ＡＰ１−ＳＴＡ２間）を受信した後の無線端末１へのAsoc Rsp（ＡＰ２−ＳＴＡ１間）の送信に基づき、無線端末１との間で双方向（ＡＰ１−ＳＴＡ２間およびＡＰ２−ＳＴＡ１間）のアソシエーション関係が構築されたと判定することができる。
以上のように、本実施形態の電子装置においては、第３実施形態における無線端末１からのAsoc ReqとAsoc Rspとの送信（図１１Ａ：（Ｓ３２）、図１１Ｂ：（Ｓ３２’））について、Asoc Reqのみ（図１３Ａ：（Ｓ４２））またはAsoc Rspのみ（図１３Ｂ：（Ｓ４２’））とすることができる。

（第５実施形態）
次に、第５実施形態について説明する。
本実施形態は、基本的には、第１実施形態から第４実施形態に基づいているため、ここでは、その差分を説明する。
図１４は、本実施形態の電子装置（無線端末１および無線端末２）における双方向のアソシエーション関係の構築に関する処理フローの一例を示す図である。

図１４に示すように、本実施形態においては、無線端末２を複数とする（無線端末２−１，２−２，．．．，２−Ｎ）。なお、図１４は、第２実施形態（図８Ａ）において無線端末２を複数とした場合を想定した例を示しているが、本実施形態の手法は、前述の第１実施形態から第４実施形態のすべてに適用し得る。

まず、無線端末１から送信するＭＡＣフレームのRAをbroadcast addressに設定し、無線端末２−１，２−２，．．．，２−Ｎへアソシエーションフレームをブロードキャストする（Ｓ５１）。ブロードキャストするとき、アソシエーションフレームの無線端末２−１，２−２，．．．，２−Ｎそれぞれに宛てた情報部分については、多重化してもよいし、１つのフレームに無線端末２−１，２−２，．．．，２−Ｎそれぞれに対する情報と無線端末２−１，２−２，．．．，２−Ｎそれぞれの宛先を含めた新しいelementを設けてもよい。

ブロードキャストによって送信されたアソシエーションフレームを受けた無線端末２−１，２−２，．．．，２−Ｎは、自身以外に宛てられた情報も受けることとなるため、RAを確認して、自身宛の（もしくは全ての無線端末に宛てられた）情報を抽出して、その後の処理を進めていく（図１４の例では、（Ｓ５４）のAsoc Rspを返す処理）。

無線端末２−１，２−２，．．．，２−Ｎからのフレームは、ＭＵ通信で無線端末１へ送信される。これを実現するには、テンポラリのAIDを定義しておくか、UORA（Uplink OFDMA-based Random Access）を利用する。
テンポラリAIDを定義する場合、ＭＵ通信を行う前に、ＡＰから複数のＳＴＡに送信されるフレームが存在することが前提となる。なお，必ずしもアソシエーションフレームでなくてもよく、テンポラリAIDを振り分けるためのBeaconフレームやProbeフレームでもよい。

また、UL MUでフレームをまとめる場合には、ＡＰがトリガーフレームを送信する必要がある。ＡＰに送信するフレームを有する無線端末は、トリガーフレームを受けた一定時間後（SIFS後）にフレームを送信する。
ここで、UORAとは、RUとして端末を指定せずに実現できるUL OFDMAのことである。送信フレームがあるＳＴＡは、AID無指定のRUに送信するか否かを、CSMA/CAのランダムアクセスと同様の要領で判断する。２端末以上が同一のRUを選択して送信した場合には、衝突により送信はいずれも失敗する。RUのAIDが2045の場合、AIDが未割り当ての端末が利用できる。AID未割り当ての端末はRUで管理フレームを１つしか送信できない。ＡＰはMulti-STA BlockAckフレームでAIDを2045にしつつ、通常BlockAck bitmapを表示する領域に受信成功した端末のＭＡＣアドレスを入れ、受信成功した端末へのACKの代わりとする。これにより、アソシエーション前でも、ＡＰは、複数のＳＴＡから、フレームを同時に送信させることができる。

以上のように、本実施形態の電子装置においては、複数の外部装置との間の双方向のアソシエーション関係を効率的に構築することを可能とする。
以上説明したいくつかの実施形態の電子装置によれば、効率的に２つの電子装置が互いにアソシエーションする方法によって、電子装置間の一方的な関係では実現できない双方向のＭＵ通信が実行可能となり、情報伝送の時間効率を向上させる。

また、これにより、メッシュネットワークにおけるルーティングやルートダイバーシチ、ネットワークモニタリングなどでの同時送受信要求を実現しやすくなる。
本発明のいくつかの実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。

１，２…無線端末、１１…送受信部、１２…ＭＡＣ機能ブロック、１３…ホスト機能ブロック、１００…無線通信システム、１２１…アソシエーションフレーム生成部。

Claims (20)

1. 第１アソシエーション要求フレームを第１電子装置から受信する受信手段と、
   前記第１アソシエーション要求フレームの受信に応じて、前記第１アソシエーション要求フレームに対応する第１アソシエーション応答フレームを前記第１電子装置へ送信し、かつ、第２アソシエーション要求フレームを前記第１電子装置へ送信する送信手段と、
   を具備する電子装置。
2. 前記第１アソシエーション要求フレームには、前記第１電子装置が、第１ＭＡＣアドレスに指定される第１ステーション部と、前記第１ＭＡＣアドレスとは異なる第２ＭＡＣアドレスに指定される第１アクセスポイント部とを有することを識別可能な第１情報が含まれており、
   前記第１アソシエーション要求フレームは、前記第１電子装置の前記第１ステーション部より送信されたものであって、
   前記第２アソシエーション要求フレームは、前記第１電子装置の第２アクセスポイント部へ送信されたものである、
   請求項１に記載の電子装置。
3. 前記第１情報は、前記第２ＭＡＣアドレスの情報であって、
   前記送信手段は、前記第２ＭＡＣアドレスを用いて前記第２アソシエーション要求フレームを送信する、
   請求項２に記載の電子装置。
4. 第３ＭＡＣアドレスに指定される第２ステーション部と、前記第３ＭＡＣアドレスとは異なる第４ＭＡＣアドレスに指定される第２アクセスポイント部とを備え、
   前記第２ステーション部に対応する前記送信手段が、前記第２アソシエーション要求フレームを送信する、
   請求項２または請求項３に記載の電子装置。
5. 前記第２アクセスポイント部に対応する前記受信手段が、前記第１アソシエーション要求フレームを受信し、
   前記第２アクセスポイント部に対応する前記送信手段が、前記第２アソシエーション要求フレームを送信し、
   前記第１ステーション部と前記第２アクセスポイント部との間のアソシエーション関係と、前記第２ステーション部と前記第１アクセスポイント部との間のアソシエーション関係とが、同時に構築されうる、
   請求項４に記載の電子装置。
6. 前記送信手段は、前記第１アソシエーション応答フレームと前記第２アソシエーション要求フレームとを含む第１物理フレームを前記第１電子装置へ送信する請求項１乃至請求項４のいずれか１項に記載の電子装置。
7. 第１アソシエーション要求フレームを第１電子装置へ送信し、かつ、第２アソシエーション応答フレームを前記第１電子装置へ送信する送信手段と、
   前記第１アソシエーション要求フレーム及び前記第２アソシエーション応答フレームを送信した後に、前記第１アソシエーション要求フレームに対応する第１アソシエーション応答フレームを受信する受信手段と、
   を具備する電子装置。
8. 前記第１アソシエーション要求フレームと前記第１アソシエーション応答フレームとによる前記第１電子装置との第１アソシエーション関係と、前記第２アソシエーション応答フレームによる前記第１電子装置との第２アソシエーション関係とが、同時に構築されうる、請求項７に記載の電子装置。
9. 前記送信手段は、前記第１アソシエーション要求フレームと前記第２アソシエーション応答フレームとを含む物理フレームを前記第１電子装置へ送信する請求項７または請求項８に記載の電子装置。
10. 前記第１アソシエーション応答フレームの送信に基づき、前記第１電子装置とのアソシエーション関係が構築されたと判断する制御手段をさらに具備する請求項７乃至請求項９のいずれか１項に記載の電子装置。
11. 前記送信手段は、前記第１アソシエーション要求フレームを、ブロードキャストで送信し、
    前記第１アソシエーション要求フレームは、前記第１電子装置及び第２電子装置に受信されるものであって、
    前記受信手段は、前記第１電子装置から前記第１アソシエーション応答フレームを受信し、かつ、前記第２電子装置から、前記第１アソシエーション要求フレームに対応するアソシエーション応答フレームを受信する、
    請求項７〜１０のいずれか１項に記載の電子装置。
12. 第１アソシエーション要求フレームを第１電子装置から受信し、かつ、第２アソシエーション応答フレームを前記第１電子装置から受信する受信手段と、
    前記第１アソシエーション要求フレーム及び前記第２アソシエーション応答フレームを受信した後に、前記第１アソシエーション要求フレームに対応する第１アソシエーション応答フレームを送信する送信手段と、
    を具備する電子装置。
13. 前記第１アソシエーション要求フレームと前記第１アソシエーション応答フレームとによる前記第１電子装置との第１アソシエーション関係と、前記第２アソシエーション応答フレームによる前記第１電子装置との第２アソシエーション関係とが、同時に構築されうる、請求項１２に記載の電子装置。
14. 前記受信手段は、前記第１アソシエーション要求フレームと前記第２アソシエーション応答フレームとを含む物理フレームを前記第１電子装置から受信する請求項１２または請求項１３に記載の電子装置。
15. 第１アソシエーション要求フレームを第１電子装置へ送信する送信手段と、
    前記第１アソシエーション要求フレームに対応する第１アソシエーション応答フレームを前記第１電子装置から受信する受信手段と、
    前記第１アソシエーション応答フレームの受信に基づき、前記第１電子装置の第１ステーション部とのアソシエーション関係と、前記第１電子装置の第１アクセスポイント部とのアソシエーション関係とが構築されたと判定する制御手段と、
    を具備する電子装置。
16. 前記送信手段は、前記第１アソシエーション要求フレームをブロードキャストで送信し、
    前記第１アソシエーション要求フレームは、前記第１電子装置及び第２電子装置に受信されるものであって、
    前記受信手段は、前記第１電子装置から前記第１アソシエーション応答フレームを受信し、かつ、前記第２電子装置から、前記第１アソシエーション要求フレームに対応するアソシエーション応答フレームを受信する、
    請求項１５に記載の電子装置。
17. 第１アソシエーション要求フレームを第１電子装置から受信する受信手段と、
    前記第１アソシエーション要求フレームが受信された場合、前記第１アソシエーション要求フレームに対応する第１アソシエーション応答フレームを前記第１電子装置へ送信する送信手段と、
    前記第１アソシエーション応答フレームの送信に基づき、前記第１電子装置の第１ステーション部とのアソシエーション関係と、前記第１電子装置の第１アクセスポイント部とのアソシエーション関係とが構築されたと判定する制御手段と、
    を具備する電子装置。
18. 第１アソシエーション応答フレームを第１電子装置へ送信する送信手段と、
    前記第１アソシエーション応答フレームを送信した後、第２アソシエーション応答フレームを前記第１電子装置から受信する受信手段と、
    前記第２アソシエーション応答フレームの受信に基づき、前記第１電子装置の第１ステーション部とのアソシエーション関係と、前記第１電子装置の第１アクセスポイント部とのアソシエーション関係とが構築されたと判定する制御手段と、
    を具備する電子装置。
19. 前記送信手段は、前記第１アソシエーション応答フレームをブロードキャストで送信し、
    前記第１アソシエーション応答フレームは、前記第１電子装置及び第２電子装置に受信されるものであって、
    前記受信手段は、前記第１電子装置から前記第２アソシエーション応答フレームを受信し、かつ、前記第２電子装置から、第３アソシエーション応答フレームを受信する、
    請求項１８に記載の電子装置。
20. 第１アソシエーション応答フレームを第１電子装置から受信する受信手段と、
    前記第１アソシエーション応答フレームを受信した後、第２アソシエーション応答フレームを前記第１電子装置へ送信する送信手段と、
    前記第２アソシエーション応答フレームの送信に応じて、前記第１電子装置の第１ステーション部とのアソシエーション関係と、前記第１電子装置の第１アクセスポイント部とのアソシエーション関係とが構築されたと判定する制御手段と、
    を具備する電子装置。

Images