JP2023116804A - electronic device - Google Patents
electronic device Download PDFInfo
- Publication number
- JP2023116804A JP2023116804A JP2023102928A JP2023102928A JP2023116804A JP 2023116804 A JP2023116804 A JP 2023116804A JP 2023102928 A JP2023102928 A JP 2023102928A JP 2023102928 A JP2023102928 A JP 2023102928A JP 2023116804 A JP2023116804 A JP 2023116804A
- Authority
- JP
- Japan
- Prior art keywords
- asoc
- association
- frame
- information
- mac
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 230000004044 response Effects 0.000 claims abstract description 22
- 230000005540 biological transmission Effects 0.000 claims description 17
- 230000002457 bidirectional effect Effects 0.000 abstract description 20
- 101100161473 Arabidopsis thaliana ABCB25 gene Proteins 0.000 description 73
- 101100096893 Mus musculus Sult2a1 gene Proteins 0.000 description 73
- 101150081243 STA1 gene Proteins 0.000 description 73
- OVGWMUWIRHGGJP-WVDJAODQSA-N (z)-7-[(1s,3r,4r,5s)-3-[(e,3r)-3-hydroxyoct-1-enyl]-6-thiabicyclo[3.1.1]heptan-4-yl]hept-5-enoic acid Chemical compound OC(=O)CCC\C=C/C[C@@H]1[C@@H](/C=C/[C@H](O)CCCCC)C[C@@H]2S[C@H]1C2 OVGWMUWIRHGGJP-WVDJAODQSA-N 0.000 description 53
- 101000988961 Escherichia coli Heat-stable enterotoxin A2 Proteins 0.000 description 53
- 238000000034 method Methods 0.000 description 33
- 238000012545 processing Methods 0.000 description 33
- 238000004891 communication Methods 0.000 description 28
- 238000010586 diagram Methods 0.000 description 21
- 238000007726 management method Methods 0.000 description 17
- 230000008569 process Effects 0.000 description 16
- 238000010276 construction Methods 0.000 description 8
- 239000000523 sample Substances 0.000 description 8
- 239000008186 active pharmaceutical agent Substances 0.000 description 4
- 239000012634 fragment Substances 0.000 description 4
- 230000002776 aggregation Effects 0.000 description 3
- 238000004220 aggregation Methods 0.000 description 3
- 230000008520 organization Effects 0.000 description 3
- OVGWMUWIRHGGJP-WTODYLRWSA-N (z)-7-[(1r,3s,4s,5r)-3-[(e,3r)-3-hydroxyoct-1-enyl]-6-thiabicyclo[3.1.1]heptan-4-yl]hept-5-enoic acid Chemical compound OC(=O)CCC\C=C/C[C@H]1[C@H](/C=C/[C@H](O)CCCCC)C[C@H]2S[C@@H]1C2 OVGWMUWIRHGGJP-WTODYLRWSA-N 0.000 description 2
- 101100366889 Caenorhabditis elegans sta-2 gene Proteins 0.000 description 2
- 108700026140 MAC combination Proteins 0.000 description 2
- 101100172132 Mus musculus Eif3a gene Proteins 0.000 description 2
- 238000001514 detection method Methods 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 238000012544 monitoring process Methods 0.000 description 2
- 238000012790 confirmation Methods 0.000 description 1
- 125000004122 cyclic group Chemical group 0.000 description 1
- 230000006872 improvement Effects 0.000 description 1
- 238000012546 transfer Methods 0.000 description 1
Images
Classifications
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
- Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
- Y02D30/00—Reducing energy consumption in communication networks
- Y02D30/70—Reducing energy consumption in communication networks in wireless communication networks
Landscapes
- Mobile Radio Communication Systems (AREA)
Abstract
Description
本発明の実施形態は、電子装置に関する。 Embodiments of the present invention relate to electronic devices.
複数のＭＡＣアドレスを有する無線通信装置が存在する。複数のＭＡＣアドレスを有する無線通信装置においては、たとえば、アクセスポイント（ＡＰ）として他の無線通信装置との間でアソシエーション関係を構築するとともに、ステーション（ＳＴＡ）として別の他の無線通信装置との間でアソシエーション関係を構築することなどが可能である。 There are wireless communication devices with multiple MAC addresses. A wireless communication device having a plurality of MAC addresses, for example, builds an association relationship with another wireless communication device as an access point (AP), and establishes an association relationship with another wireless communication device as a station (STA). It is possible to build an association relationship between them.
従来、複数のＭＡＣアドレスを有する無線通信装置においては、複数のＭＡＣアドレスを有する他の無線通信装置との間で、ＡＰとＳＴＡとの関係が互い違いの２つのアソシエーション関係を構築し、双方向のアソシエーション関係を構築することはできるものの、その２つのアソシエーション関係が同一の他の無線通信装置との間で構築されたものであるか否かを認識することなどができなかった。
本発明が解決しようとする課題は、同一の外部装置との間であることを認識しつつ双方向のアソシエーション関係を構築することができる電子装置を提供することである。
Conventionally, a wireless communication device having a plurality of MAC addresses builds two association relationships in which the relationship between the AP and the STA is alternated with another wireless communication device having a plurality of MAC addresses. Although it is possible to construct an association relationship, it is not possible to recognize whether or not the two association relationships are established with the same other wireless communication device.
The problem to be solved by the present invention is to provide an electronic device that can establish a bidirectional association relationship while recognizing that it is with the same external device.
実施形態によれば、電子装置は、送信手段と、受信手段と、制御手段と、を具備する。送信手段は、第１アソシエーション要求フレームを第１電子装置へ送信する。受信手段は、第１アソシエーション要求フレームに対応する第１アソシエーション応答フレームを第１電子装置から受信する。制御手段は、第１アソシエーション応答フレームの受信に基づき、第１電子装置の第１ステーション部とのアソシエーション関係と、第１電子装置の第１アクセスポイント部とのアソシエーション関係とが構築されたと判定する。 According to an embodiment, an electronic device comprises transmitting means, receiving means and control means. The transmitting means transmits the first association request frame to the first electronic device. The receiving means receives a first association response frame corresponding to the first association request frame from the first electronic device. The control means determines that an association relationship between the first electronic device and the first station unit and an association relationship between the first electronic device and the first access point unit are established based on the reception of the first association response frame. .
以下、実施の形態について図面を参照して説明する。
（第１実施形態）
まず、第１実施形態について説明する。
図１は、第１実施形態の電子装置（無線端末１および無線端末２）を含む無線通信システム１００の一例を示す図である。無線端末１および無線端末２は、たとえば、タブレットＰＣやノートＰＣなどのパーソナルコンピュータ、スマートフォンなど、無線通信機能を有する様々な電子装置として実現され得る。この無線通信システム１００は、無線端末１と無線端末２とが無線通信のためのアソシエーション関係を構築することによって構築される。
Hereinafter, embodiments will be described with reference to the drawings.
(First embodiment)
First, the first embodiment will be explained.
FIG. 1 is a diagram showing an example of a wireless communication system 100 including electronic devices (
無線端末１および無線端末２は、それぞれ、図２に示すような階層モデルに準じた機能ブロック構成で実現されており、複数のＭＡＣアドレスを持つものとする。各ＭＡＣアドレスを有する機能ブロックをＭＡＣ機能ブロック（ａ１）と呼ぶ。各無線端末１，２の複数のＭＡＣ機能ブロックは、それぞれのAbstraction機能ブロック（ａ２）によってまとめられ、上位の機能ブロック（ａ４）からは１つのＭＡＣ機能ブロックとみなせるようになっている。Abstraction機能ブロックは、ＭＡＣアドレスに基づいて、上位機能ブロックからのフレームを複数のＭＡＣ機能ブロックのうちの適切なものに振り分けたり、ＭＡＣ機能ブロック間でのフレーム交換を実現したりする役割を担う。なお、上位機能ブロックからのフレームを適切なＭＡＣ機能ブロックに振り分ける手法や、ＭＡＣ機能ブロック間でのフレーム交換手法については後述する。また、ＭＡＣ機能ブロックの下位には、ＰＨＹ機能ブロック（ａ３）が存在する。図２中、（Ａ）は、複数のＭＡＣ機能ブロックに対して１つのＰＨＹ機能ブロックが設けられる例を示し、（Ｂ）は、複数のＭＡＣ機能ブロックと一対に複数のＰＨＹ機能ブロックが設けられる例を示している。
The
図３に、本実施形態の電子装置（無線端末１および無線端末２）の一構成例を示す。
無線端末１および無線端末２は、それぞれ、図３に示すように、ＭＡＣフレームを送受信する送受信部１１（第１送信部１１－１、第２送受信部１１－２）と、前述のＭＡＣフレームの生成や無線媒体（エア）へのアクセス制御を行うＭＡＣ機能ブロック（第１ＭＡＣブロック１２－１、第２ＭＡＣブロック１２－２）と、ホスト機能ブロック１３とを有する。
FIG. 3 shows a configuration example of the electronic device (
As shown in FIG. 3, each of the
送受信部１１、ＭＡＣ機能ブロックおよびホスト機能ブロック１３は、それぞれ個別の電子回路として構成されてもよいし、これらのいくつかまたは全部が１つの電子回路として構成されてもよい。また、これらは、メモリデバイスに格納されてプロセッサによって実行されるファームウェアなどによって構成されてもよい。
The transmitting/receiving
送受信部１１は、図２のＰＨＹ機能ブロックに該当する機能を提供する。図３は、図２（Ｂ）の各ＭＡＣ機能ブロックにＰＨＹ機能ブロックが接続している場合を示している。図２（Ａ）のＰＨＹ機能ブロックが複数のＭＡＣ機能ブロック間で共通の場合は、送受信部１１を１つにし、各ＭＡＣ機能ブロックに接続するようにすればよい。図３では、２つのＭＡＣ機能ブロック１２がある例を示している。例えば、この各ＭＡＣ機能ブロック１２内にアソシエーションフレーム生成部１２１（アソシエーションフレーム生成部１２１－１、アソシエーションフレーム生成部１２１－２）がある。アソシエーションフレーム生成部１２１は、アソシエーションプロセスを実施するために必要なアソシエーション要求(Association Request)フレームまたはアソシエーション応答(Association Response)フレームの生成を行う。各ＭＡＣ機能ブロック１２は、ホスト機能ブロック１３に接続する。ホスト機能ブロック１３には、図２のAbstraction機能ブロックおよびその上位層に対応する機能ブロックが含まれる。
The transmitter/
本実施形態では、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の後継規格も含まれる。 In this embodiment, a frame in a wireless LAN system conforming to the IEEE 802.11 standard is used. The IEEE 802.11 standard includes IEEE 802.11a, IEEE 802.11b, IEEE 802.11g, IEEE 802.11n, IEEE 802.11ac, IEEE 802.11ax, etc., as well as IEEE 802.11 successor standards to be defined in the future.
図４は、Managementフレームのフォーマット例を示す。Managementフレームは、ＢＳＳ（Basic Service Set）の構築や、ＳＴＡ（ＡＰも含む）との間の接続・切断などを行うためのフレームである。図４に示すフォーマットのフレームは、Managementフレームの他に、上位の機能ブロックからのパケットを運ぶDataフレームや、ＭＡＣレベルでの通信を制御するのに使うControlフレームなどが存在する。これらのフレームの種別は、後述するMAC Header部（ｂ１）のFrame Control（ｂ１１）内のTypeで識別され、さらにAssociation Requestなどといった細かい種別は、Frame Control内のSubtypeで識別される。 FIG. 4 shows a format example of a Management frame. The Management frame is a frame for constructing a BSS (Basic Service Set), connecting/disconnecting with STA (including AP), and the like. The frames of the format shown in FIG. 4 include, in addition to the Management frame, a Data frame that carries packets from upper functional blocks, a Control frame that is used to control communication at the MAC level, and the like. The types of these frames are identified by Type in Frame Control (b11) of MAC Header section (b1), which will be described later, and detailed types such as Association Request are identified by Subtype in Frame Control.
Managementフレームは，MAC Header部（ｂ１）、Frame Body部（ｂ２）およびFCS(Frame Check Sequence)部（ｂ３）を含む。
MAC Header部は、ＭＡＣ機能ブロックにおける受信処理に必要な情報を設定する。Frame Body部は、フレームの種類に応じた情報が設定される。FCS部は、MAC Header部とFrame Body部とが正常に受信できたか否かを判定するために用いる誤り検出コードであるCRC(Cyclic Redundancy Code)が設定される。
The Management frame includes a MAC Header section (b1), a Frame Body section (b2) and an FCS (Frame Check Sequence) section (b3).
The MAC Header section sets information necessary for reception processing in the MAC functional block. Information corresponding to the frame type is set in the Frame Body section. A CRC (Cyclic Redundancy Code), which is an error detection code used to determine whether or not the MAC Header section and Frame Body section have been successfully received, is set in the FCS section.
MAC Header部には、フレームの種類に応じた値が設定されるFrame Controlフィールド（ｂ１１）、Durationフィールド（ｂ１２）などが存在する。また、MAC Header部には、Addressフィールド（ｂ１３）が複数存在する。Address 1フィールドには、直接の受信側のＭＡＣアドレス（Receiving Address:RA）を設定する。Address 2フィールドには、直接の送信局のＭＡＣアドレス（Transmitting Address:TA）を設定する。Address 3フィールドには、BSSIDなどのアドレスを設定する。ＡＰがＢＳＳを構成する場合には、BSSIDはＡＰのＭＡＣアドレスと等しい。
The MAC Header portion includes a Frame Control field (b11), a Duration field (b12), and the like, in which a value corresponding to the type of frame is set. Also, the MAC Header portion has a plurality of Address fields (b13). The MAC address (Receiving Address: RA) of the direct receiving side is set in the
また、MAC Header部には、Sequence Controlフィールド（ｂ１４）が存在する。Sequence Controlフィールドには、送信するデータのシーケンス番号や、データをフラグメント化した場合のフラグメント番号を設定する。 Also, the MAC Header portion has a Sequence Control field (b14). In the Sequence Control field, set the sequence number of the data to be transmitted and the fragment number when the data is fragmented.
Frame Controlフィールド（Ｂ１１）には、フレームの種類を示すTypeフィールドおよびSubtypeフィールドや、To DSフィールド、From DSフィールド、モアフラグメント（more fragment）フィールド、プロテクト（protected）フレームフィールド、オーダー（order）フィールド等が存在する。 The Frame Control field (B11) includes a Type field and a Subtype field indicating the type of frame, a To DS field, a From DS field, a more fragment field, a protected frame field, an order field, and the like. exists.
Typeフィールドに設定されるビット列によって、MACフレームが、Controlフレーム、ManagementフレームまたはDataフレームのうちのどのフレームタイプに属するフレームであるかを認識することができる。さらにSubtypeフィールドのビット列によって、各フレームタイプ内のＭＡＣフレームの種類が示される。 The bit string set in the Type field makes it possible to recognize which frame type the MAC frame belongs to, out of Control frame, Management frame, or Data frame. Furthermore, the bit string of the Subtype field indicates the type of MAC frame within each frame type.
また、To DSフィールドには、受信局が無線基地局であるか、無線端末であるかの情報が設定され、From DSフィールドには、送信局が無線基地局であるか、無線端末であるかの情報が設定される。
More Fragmentフィールドは、データがフラグメント化された場合に、後続するフラグメントフレームが存在するか否かを示す情報を保持する。プロテクトフレームフィールドには、当該フレームがプロテクトされているか否かの情報が設定される。オーダーフィールドには、フレームを中継する際に、フレームの順序を入れ替えてはいけないことを示す情報が設定される。あるいは、オーダーフィールドの情報は、後述するオプションフィールドの有無を示す役割を持つこともある。
Information indicating whether the receiving station is a wireless base station or a wireless terminal is set in the To DS field, and whether the transmitting station is a wireless base station or wireless terminal is set in the From DS field. information is set.
The More Fragment field holds information indicating whether or not there are subsequent fragment frames when the data is fragmented. Information as to whether or not the frame is protected is set in the protected frame field. Information indicating that the order of frames should not be changed when relaying frames is set in the order field. Alternatively, the order field information may have a role of indicating the presence or absence of an option field, which will be described later.
また、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の各種機能に応じた通知をすることができる。 Also, in the MAC Header part, an HT (High Throughput) Control field (b15) can exist. The HT Control field is present when the Order field is set to 1 in QoS Data or Management frames. The HT Control field can be extended to the VHT (Very High Throughput) Control field and the HE (High Efficient) Control field, and the notification according to various functions of IEEE 802.11n, IEEE 802.11ac or IEEE 802.11ax respectively. can do
なお、MAC Header部の構成は、上述したフィールドのみに限らない。新しいIEEE 802.11の後継規格が規定されることで、MAC Header部に新規フィールドが追加されることがある。
次に、無線端末１と無線端末２とがそれぞれＡＰとＳＴＡとの両方の役割を担えるように双方向のアソシエーション関係を構築するための処理について説明する。
Note that the configuration of the MAC Header section is not limited to the fields described above. As new IEEE 802.11 successor standards are specified, new fields may be added to the MAC Header section.
Next, a description will be given of processing for building a bidirectional association relationship so that the
ここで、ＡＰの役割とは、例えばIEEE 802.11axに基づくマルチユーザ通信（以下、ＭＵ通信）を利用して、同時に複数の宛先からパケットを収集したり、複数の宛先へパケットを送信したりすることを実行できる役割を指し、ＳＴＡの役割とは、前述のＭＵ通信における、ＡＰ以外の無線端末が果たす役割を指す。 Here, the role of the AP is to collect packets from multiple destinations at the same time and transmit packets to multiple destinations using, for example, multi-user communication based on IEEE 802.11ax (hereafter referred to as MU communication). The role of the STA refers to the role played by the wireless terminal other than the AP in the MU communication described above.
また、アソシエーションとは、ＳＴＡがＡＰに接続する、言い換えれば、ＡＰが構築するＢＳＳに加入する接続プロセスの１つであり、通常、ＳＴＡの要求に対して、ＡＰが応答する。ＡＰが要求を許可した場合（応答フレームのStatus Code fieldが0(SUCCESS))、そのＳＴＡにAIDが割り当てられる。これによって、ＳＴＡは、ＡＰが構築するＢＳＳ内でデータフレームを送信できるようになる。 Also, association is one of connection processes in which an STA connects to an AP, in other words, joins a BSS constructed by the AP. Usually, the AP responds to the STA's request. If the AP grants the request (the Status Code field of the response frame is 0 (SUCCESS)), the STA is assigned an AID. This allows the STA to transmit data frames within the BSS established by the AP.
無線端末１における２つのＭＡＣ機能ブロック１２－１，１２－２をそれぞれＡＰ１、ＳＴＡ１と呼び、同様に、無線端末２における２つのＭＡＣ機能ブロック１２－１，１２－２をそれぞれＡＰ２、ＳＴＡ２と呼ぶ。つまり、無線端末１と無線端末２とは、それぞれ、互いに異なるＭＡＣアドレスを有するＭＡＣ機能ブロック１２－１，１２－２によって実現されるアクセスポイント部とステーション部とを有する。以下、ＳＴＡ１がＡＰ２に、また、ＳＴＡ２がＡＰ１に互いにアソシエーションする。
The two MAC functional blocks 12-1 and 12-2 in the
無線端末１と無線端末２との対称性より、ここでは、無線端末１から処理を開始する場合を考える。双方向のアソシエーション関係の構築に関する処理フローの一例を図５に示す。
双方向のアソシエーション関係の構築に関する処理フローは、無線端末２から送信されるBeaconやProbe Response、前提条件などからＡＰ２の存在および情報を既知とするＳＴＡが、ＡＰ２に対してManagementフレームの一例であるAssociation Request（Asoc Req）を送信することから開始される（Ｓ１１）。
Considering the symmetry between the
The processing flow for building a two-way association relationship is an example of a management frame to AP2 from an STA that knows the existence and information of AP2 from the Beacon and Probe Response transmitted from the
ここで、ＡＰ２の情報は、少なくともＡＰ２のＭＡＣアドレスを含み、他にはSSID(Service Set Identifier)などアソシエーション上で必要かつ未知となっている情報が含まれる場合がある。
ＳＴＡ１は、Asoc Reqによって、 Capability Information、Listen Interval、接続したいSSIDを示す情報を通知するとともに、アソシエーションおよび通信に必要な情報（Supported Rates and BSS Membership SelectorsやPower Capabilityなど）を通知する。
Here, the information of AP2 includes at least the MAC address of AP2, and may include other information such as SSID (Service Set Identifier) that is necessary and unknown on the association.
STA1 uses Asoc Req to notify Capability Information, Listen Interval, information indicating the SSID to be connected, and information necessary for association and communication (Supported Rates and BSS Membership Selectors, Power Capability, etc.).
ＳＴＡ１がAsoc ReqをＡＰ２に対して送信することによって、ＳＴＡ１とＡＰ２とのアソシエーションが開始されることとなるが、本実施形態では、さらに、Asoc Reqを利用して、無線端末１は、ＡＰ１の情報を無線端末２に通知する。
ここで、ＡＰ１の情報とは、アソシエーションを完了させるのに必要な情報（例えばＭＡＣアドレスやＡＰ１の通信チャネルなど）のうち、前提条件と定められているなどして既知であるものと、BeaconやProbe Responseを用いてＡＰ１からＳＴＡにすでに通知されているもの（ＡＰのＭＡＣアドレスがBSSIDとなるため、ＡＰのＭＡＣアドレスを通知してもらうことで、どのBeacon/Probe Responseかを対応づけることができる）を除いた情報のうち必要なものを示す。なお、通知するべき情報がない場合には、ＳＴＡ１が属する無線端末１にアソシエーション可能なＡＰ１が存在するということを示す情報が、ＡＰ１の情報ということとなる。このＡＰ１の情報により、無線端末２は、無線端末１が、互いに異なるＭＡＣアドレスが割り当てられたアクセスポイント部とステーション部とを有することを識別することができる。また、このＡＰ１の情報により、無線端末２は、後述するAsoc Reqを無線端末１へ送信することができる。
The association between STA1 and AP2 is started by STA1 transmitting Asoc Req to AP2. The information is notified to the
Here, the information of AP1 means information that is known as a precondition among the information necessary for completing the association (for example, the MAC address and the communication channel of AP1), and the information such as Beacon and Already notified from AP1 to STA using Probe Response (Because the MAC address of AP is BSSID, it is possible to associate which Beacon/Probe Response by having the MAC address of AP notified. ) indicates the necessary information. If there is no information to be notified, the information indicating that the
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フレームで通知するところ、それを省略してもＳＴＡ２では既知として処理することができる。 As means for notifying the information of AP1 using Asoc Req, it is conceivable to define a new element in the Association Request frame body, or to use the Vendor Specific element added at the end of the Association Request frame body. Currently, IEEE 802.11 has run out of Element IDs for identifying elements, so if an Element ID has the maximum value of 255, an Element ID Extension subfield will be added to identify it. ing. For example, a new Element is defined using a value not assigned in the existing IEEE 802.11 standard as this Element ID Extension subfield. At least the MAC address information of AP1 is included in this new element or Vendor Specific element. If the AP1 has not transmitted the Beacon frame, the information notified by the conventional Beacon frame may be included. For example, when the SSID is shared between the wireless communication terminals, the SSID used by AP2 and the SSID used by AP1 are common. can be processed as
なお、無線端末２が複数のＭＡＣ機能ブロックを持たない場合やElement IDを認識できない場合には、ＡＰ１とのアソシエーションは実行されず無視される。
Association Request frame bodyなどに入れられるelementのフォーマットを図６に示す。elementのフォーマットの基本構成は、先頭に、まずelementを識別するためのElement IDフィールド（ｃ１）があり、続いて、後続するフィールド長の総和をオクテット長で表すLengthフィールド（ｃ２）がある。Element IDフィールドが255の場合は、さらにElement IDの番号を拡張するためのElement ID Extensionフィールド（ｃ３）が設けられる。そして、そのElement IDに関する情報を格納するInformationフィールド（ｃ４）を含む。
If the
FIG. 6 shows the format of the element that can be put in the Association Request frame body and the like. The basic structure of the format of element has an Element ID field (c1) for identifying the element at the beginning, followed by a Length field (c2) representing the sum of subsequent field lengths in octets. If the Element ID field is 255, an Element ID Extension field (c3) is provided for further extending the Element ID number. It also includes an Information field (c4) that stores information about the Element ID.
Informationフィールドは、Element IDが0であるSSID Elementのように、１つの情報のみを含んでもよいし、Element IDが33であるPower Capabilityのように、複数の情報を含んでもよい。すなわち、任意の数で、Lengthフィールドで指定できる最大１オクテットまでの情報を通知することができる。Lengthフィールドの後に複数の情報フィールドを入れる場合には、各情報フィールドが固定値であれば、予め定義することによって受信側でも各情報フィールドから情報を抽出できる。情報フィールドの一部を可変長にしたい場合には、当該情報フィールドの前にフィールド長を特定するための必要なサブフィールドを追加すればよい。 The Information field may contain only one piece of information, such as SSID Element whose Element ID is 0, or may contain multiple pieces of information, such as Power Capability whose Element ID is 33. In other words, any number of information up to 1 octet that can be specified in the Length field can be notified. When a plurality of information fields are inserted after the Length field, if each information field is a fixed value, the receiving side can also extract information from each information field by defining in advance. If it is desired to make a part of the information field variable length, a necessary subfield for specifying the field length should be added before the information field.
ＡＰ１のＭＡＣアドレスをVendor Specificで定義したelementによってフレームを構成する例を説明する。Vendor Specific elementとは、IEEE 802.11無線ＬＡＮ規格で定義されない、各ベンダーの都合で通知したい情報を入れるために設けられているものである。 An example in which the MAC address of AP1 is configured by an element defined by Vendor Specific will be described. The Vendor Specific element is provided to contain information that is not defined by the IEEE 802.11 wireless LAN standard and that each vendor wishes to notify for their convenience.
まず、Vendor Specific elementであることを通知するため、Element IDに221を設定する。次に、Lengthフィールドに、後続のOrganization IdentifierフィールドとVendor-specific contentフィールドの長さを表す値を設定する。Organization Identifierには、どの組織特有で利用するものかを識別できるようにし、Vendor-specific contentとして、本実施形態ではＡＰ１のＭＡＣアドレスを記載するようにする。 First, 221 is set in the Element ID to notify that it is a Vendor Specific element. Next, set the Length field to a value representing the length of the subsequent Organization Identifier and Vendor-specific content fields. In the Organization Identifier, it is possible to identify which organization is used, and in this embodiment, the MAC address of AP1 is described as 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（ｃ４Ａ）とする。 When defining a new element, set the Element ID to 255, and use values not used in the existing IEEE 802.11 standard for the Element ID Extension (0 to 8, 12, 52, etc.). Alternatively, a value not used in the existing IEEE 802.11 standard (for example, there are 2, 8, 9, etc.) may be used as the Element ID. In the latter case, the Element ID Extension field is unnecessary. Then, the Information field is named MAC Address of Co-located AP field, for example, and the MAC address of AP1 is described therein. Since the MAC address of the AP is equivalent to the BSSID of the BSS configured by the AP, the Co-located BSSID field may be used instead of the MAC Address of Co-located AP field. Since the MAC address of the AP is 6 octets, the Length field is 7 if the Element ID Extension field is included, and 6 if the Element ID Extension field is unnecessary and does not exist. Also, if the MAC address of STA1 and the MAC address of AP1 have a part (for example, the beginning) in common, all the 6 octets of the MAC address of AP1 are not displayed. X) An abbreviated display method, such as how many octets there are, is also conceivable. In any case, it is sufficient that the received Asoc Req contains information that enables the STA2 to generate the Asoc Req for AP1 on the wireless terminal side that received the Asoc Req. FIG. 7 is an example of an element in which Element ID is 255, Element ID Extension is 60, and MAC Address of Co-located AP field of 6 octets is entered. For example, let this new element be a Co-located AP Info element (c4A).
図５に戻って、双方向のアソシエーション関係の構築に関する処理フローの説明を続ける。
（Ｓ１１）でAsoc Reqを受信したＡＰ２は、ＳＴＡ１からのアソシエーション要求を受け、同時に、ＳＴＡ１を持つ無線端末１がＡＰ１を持つことを知ることができる。これにより、ＡＰ２は、ＳＴＡ１とのアソシエーションを完了させるために、Managementフレームの一例であるAssociation Response（Asoc Rsp）をＳＴＡ１宛てに送信する（Ｓ１３）。加えて、ＡＰ２は、Abstraction機能ブロックを介して、ＳＴＡ２がＡＰ１とのアソシエーションするためのＡＰ１の新規情報を伝達する（Ｓ１２）。Abstraction機能ブロックは、各ＭＡＣ機能ブロックのＭＡＣアドレスを、テーブル等によって管理しており、ＡＰ２から受け取った情報を適切にＳＴＡ２に通知することが可能となっている。また、Station Management Entity（SME）を実施する機能ブロックを別途設け、それを利用して情報を通知してもよい。ここで、SMEは、すべてのＭＡＣ機能ブロックと接続している、各ＭＡＣ機能ブロックにアソシエーション開始などの命令や情報を伝達することが可能な管理部である。
Returning to FIG. 5, the description of the processing flow for building the bidirectional association relationship continues.
AP2, which has received Asoc Req in (S11), receives the association request from STA1, and at the same time can know that
このように、ＡＰ２がＳＴＡ２に情報を通知する方法は多数あり、本実施形態は特定の方法に限定されない。また、（Ｓ１２）と（Ｓ１３）の順序は逆であってもよい。
Asoc Rspによって、Capability Informationや、Status code、ＡＰからＳＴＡに割り当てられるAIDの他に、必要に応じた情報（例えば、Supported Rates and BSS Membership SelectorsやEDCA Parameter Setなど）が通知される。
Thus, there are many methods for AP2 to notify STA2 of information, and the present embodiment is not limited to any particular method. Also, the order of (S12) and (S13) may be reversed.
Asoc Rsp notifies Capability Information, Status code, AID assigned from AP to STA, and other necessary information (for example, Supported Rates and BSS Membership Selectors, EDCA Parameter Set, etc.).
ＳＴＡ１は、受信したAsoc Rspを処理し、Status Codeの値が0、すなわちSuccess （成功）である場合には、これによってＡＰ２とＳＴＡ１とのアソシエーション関係が成立する。アソシエーション関係が成立すると、ＡＰ２とＳＴＡ１との間でデータフレームの交換が可能となる。 STA1 processes the received Asoc Rsp, and if the value of Status Code is 0, that is, Success (success), this establishes an association relationship between AP2 and STA1. When the association relationship is established, data frames can be exchanged between AP2 and STA1.
一方、ＡＰ１の情報が通知されたＳＴＡ２では、その情報に基づいて、Asoc ReqをＡＰ１宛てに作成して送信する（Ｓ１４）。
ＡＰ１は、受信したAsoc Reqを処理し、ＳＴＡ２にAsoc Reqを送信する（Ｓ１５）。
ＳＴＡ２は、受信したAsoc Rspを処理し、これによってＡＰ１とＳＴＡ２とのアソシエーションが完了する。
On the other hand, STA2 to which the information of AP1 has been notified creates and transmits Asoc Req to AP1 based on the information (S14).
AP1 processes the received Asoc Req and transmits Asoc Req to STA2 (S15).
STA2 processes the received Asoc Rsp, which completes the association between AP1 and STA2.
無線端末１が始めに送信するAsoc Reqがトリガーとなって、複数のアソシエーション関係（ＡＰ２とＳＴＡ１とのアソシエーション関係およびＡＰ１とＳＴＡ２とのアソシエーション関係）が構築されることによって、以下の利点が得られる。
まず、無線端末２が、ＡＰ１とＳＴＡ１が無線端末１に含まれていること（co-locatedであること）を知ることができる。従来、neighborレポートを利用して、あるＡＰが他のＡＰの存在を通知する方法は存在するが、co-locatedであるかは通知されない。当然、あるＡＰが当該ＡＰとco-locateするＳＴＡの情報を通知することも、また、その逆であるＳＴＡが当該ＳＴＡとco-locateするＡＰの情報を通知することもできない。
The Asoc Req first transmitted by the
First, the
また、チャネルスキャンの効率化が行える。従来、相互のアソシエーション関係を構築するためには、ＳＴＡ１、ＳＴＡ２がそれぞれ独立にＡＰ２、ＡＰ１の通信チャネルを検出して、アソシエーション処理を開始する（co-locatedであることは認識できない）。一方、本実施形態では、片側が通信チャネルを検出できれば、アソシエーションを開始するフレームが送信され、それをトリガーに両アソシエーションが完了されるため、より効率的にアソシエーションが行える。特に、ＰＨＹ機能ブロックが共通の場合、ＡＰとＳＴＡでチャネルを毎回切り替える必要がない。また、ＰＨＹ機能ブロックが複数の場合でも、チャネル検出にかかる時間は軽減され、同じ無線端末のＡＰとＳＴＡのチャネルが被っている時の対処を考慮に入れる必要がない。 In addition, efficiency of channel scanning can be improved. Conventionally, in order to establish a mutual association relationship, STA1 and STA2 independently detect communication channels of AP2 and AP1 and start association processing (they cannot recognize that they are co-located). On the other hand, in the present embodiment, if one side can detect a communication channel, a frame for starting association is transmitted, which triggers both associations to be completed. Therefore, association can be performed more efficiently. In particular, when the PHY function block is common, there is no need to switch channels between the AP and the STA each time. Also, even when there are a plurality of PHY function blocks, the time required for channel detection is reduced, and it is not necessary to take into consideration the case where the AP and STA channels of the same wireless terminal overlap.
また、無線端末が互いにアソシエーションすることによって、メッシュネットワークを構成する無線端末間が互いにＡＰの役割を行うことができる。これによって、ルーティングやルートダイバーシチ、ネットワークモニタリングなど様々な場面において、マルチユーザ通信が実行可能となり、情報伝送の時間効率向上が期待できる。 In addition, wireless terminals forming a mesh network can function as APs with each other by associating wireless terminals with each other. As a result, multi-user communication can be executed in various situations such as routing, route diversity, network monitoring, etc., and time efficiency improvement of information transmission can be expected.
なお、アップリンクＭＵ通信によってフレームが送信されるのであればＳＴＡが、ダウンリンクＭＵ通信によってフレームが送信されるのであればＡＰが、それぞれそのフレームを処理すべきＭＡＣ機能ブロックとなるが、このような上位の機能ブロックから入力されたデータをどのＭＡＣ機能ブロックに振り分けるかの判断は、Abstraction機能ブロックによって行われる。 Abstraction機能ブロックは、テーブルなどを用いて、各ＭＡＣ機能ブロックのＭＡＣアドレスを管理しており、振り分けに関する何らかのルールやポリシーを設けることにより、上位機能ブロックからのデータをＭＡＣ機能ブロックに振り分けられる。 If the frame is transmitted by uplink MU communication, the STA is the MAC functional block that should process the frame, and if the frame is transmitted by the downlink MU communication, the AP is the MAC functional block that should process the frame. The Abstraction function block determines to which MAC function block the data input from a higher-level function block should be distributed. The abstraction function block manages the MAC address of each MAC function block using a table or the like, and by setting some sort of rules and policies regarding distribution, data from the upper function block can be distributed to the MAC function blocks.
以上のように、本実施形態の電子装置においては、同一の外部装置との間であることを認識しつつ双方向のアソシエーション関係を構築することができる。
（第２実施形態）
次に、第２実施形態について説明する。
本実施形態は、基本的には、第１実施形態に基づいているため、ここでは、その差分を説明する。
As described above, in the electronic device of this embodiment, it is possible to establish a bidirectional association relationship while recognizing that it is with the same external device.
(Second embodiment)
Next, a second embodiment will be described.
Since this embodiment is basically based on the first embodiment, differences therebetween will be explained here.
図８Ａおよび図８Ｂは、本実施形態の電子装置（無線端末１および無線端末２）における双方向のアソシエーション関係の構築に関する処理フローの一例をそれぞれ示す図である。
本実施形態が第１実施形態と異なる点は、第１実施形態では、ＡＰ２からＳＴＡ１へのAsoc Rspと、ＳＴＡ２からＡＰ１へのAsoc Reqとを別々に送信していたのに対し、Asoc ReqとAsoc Rspとを同一の物理パケット（物理フレーム）にまとめる点である。図８Ａは、ＡＰ２がAsoc RspとAsoc Reqとの集約を行い、ユニキャストまたは多重化のうちのいずれかの手段を用いて無線端末１へ送信する場合の例を示している。一方、図８Ｂは、ＳＴＡ２がAsoc Rsp とAsoc Reqとの集約を行い、ユニキャストまたは多重化のうちのいずれかの手段を用いて無線端末１へ送信する場合の例を示している。図８Ａおよび図８Ｂを参照して、本実施形態における双方向のアソシエーション関係の構築に関する処理フローを説明する。なお、第１実施形態と同様、無線端末１から処理を開始する場合を考える。
FIGS. 8A and 8B are diagrams respectively showing an example of a processing flow for building a bidirectional association relationship in the electronic devices (
This embodiment differs from the first embodiment in that, in the first embodiment, Asoc Rsp from AP2 to STA1 and Asoc Req from STA2 to AP1 were separately transmitted, whereas Asoc Req and Asoc Rsp is combined into the same physical packet (physical frame). FIG. 8A shows an example in which
本実施形態においても、双方向のアソシエーション関係の構築に関する処理フローは、無線端末２から送信されるBeaconやProbe Response、前提条件などからＡＰ２の存在および情報を既知とするＳＴＡ１が、ＡＰ２に対してAsoc Reqを送信することから開始される（Ｓ２１）。
In this embodiment as well, the processing flow for building a two-way association relationship is as follows: STA1, which knows the existence and information of AP2 from the Beacon and Probe Response transmitted from
ＳＴＡ１からAsoc Reqを受信したＡＰ２は、Asoc Reqに内包されるＡＰ１の情報から、ＳＴＡ１を有する無線端末１がＡＰ１も有することを知ることができる。ＡＰ２は、ＳＴＡ１とのアソシエーションを完了させるためのAsoc Rspを作成する。さらに、ＡＰ２は、ＳＴＡ２がＡＰ１とアソシエーションプロセスを開始できるように、取得したＡＰ１の情報を伝達する（Ｓ２２）。
AP2, which has received Asoc Req from STA1, can know that
なお、第１実施形態と同様、無線端末２が複数のＭＡＣ機能ブロックを持たない場合やElement IDを認識できない場合には、ＡＰ１とのアソシエーションは実行されず無視され、処理は終了される。
フレームの多重化には、フレームアグリゲーションや、それぞれ異なる周波数帯域幅を用いてフレームを送信する周波数多重化、複数のアンテナで送信する空間分割多重化、それぞれ異なる符号を使って送信する符号多重化、および、同じ周波数帯域幅でも、それぞれ異なるサブキャリアを用いてフレームを送信する直交周波数多重化などがある。
なお，処理フローの現ステップ（Ｓ２２）では、アソシエーションが完了していないため、多重化を行うために必要であるが共有できていない情報が存在する場合がある。例えば、IEEE802.11ax規格において周波数多重化や空間多重化を利用し、ＳＴＡ１へのAsoc RspとＡＰ１へのAsoc Reqを多重送信する場合には、ダウンリンク（Downlink:DL）多重の形態をとることになる。この場合、PHYヘッダに含まれるHE-SIG-Bに各リソースユニットあるいは各ストリームの送信先を示すため、AID情報が必要となるが、AID情報は、アソシエーションによって共有される情報である。そこで、不足している情報がある場合には、前ステップ（Ｓ２１）で送達されたフレームによって、テンポラリの値を割り当てることを考える。
As in the first embodiment, if the
Frame multiplexing includes frame aggregation, frequency multiplexing in which frames are transmitted using different frequency bandwidths, space division multiplexing in which frames are transmitted using multiple antennas, code multiplexing in which frames are transmitted using different codes, Also, there is orthogonal frequency multiplexing in which frames are transmitted using different subcarriers even if the same frequency bandwidth is used.
In the current step (S22) of the processing flow, since the association has not been completed, there may be information that is necessary for multiplexing but not shared. For example, when frequency multiplexing or spatial multiplexing is used in the IEEE802.11ax standard and Asoc Rsp to STA1 and Asoc Req to AP1 are multiplexed, Downlink (DL) multiplexing is used. become. In this case, AID information is required to indicate the transmission destination of each resource unit or each stream in HE-SIG-B included in the PHY header, and AID information is information shared by associations. Therefore, if there is missing information, consider assigning a temporary value according to the frame delivered in the previous step (S21).
アソシエーションプロセス中に多重送信を実現するためテンポラリのAID値を割り当てることを例にとれば、新しくTemporary AIDs for Association Intervalというelementを設ける。このelementで、ＳＴＡ１へのAsoc RspとＡＰ１へのAsoc Reqとが多重化されたフレームを識別するため、ＳＴＡ１／ＡＰ１側の無線端末１で各々に一時的に割り当てるAIDを指定し、ＳＴＡ１からＡＰ２へ送信するAsoc Reqの中に含める。この一時的なAIDも従来のAIDの範囲である1から2007の値の中から取るようにする場合、すでに割り当てているAIDがあるならば、それを除いて選択するようにすることが望ましい。
Taking as an example the assignment of temporary AID values to realize multiple transmission during the association process, a new element Temporary AIDs for Association Interval is provided. In this element, in order to identify a frame in which Asoc Rsp to STA1 and Asoc Req to AP1 are multiplexed, the AID temporarily assigned to each by the
例えばＳＴＡ１の一時的な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ペイロードを復号することができる。
For example, assume that STA1 designates 2001 as a temporary AID for STA1 and 2002 as a temporary AID for AP1 by Asoc Req in Temporary AIDs for Association Interval element. AP2 receives and decodes Asoc Req, and if STA1 specifies
このHE-SIG-Bで用いるAIDは、1から2007の値の範囲に限定される場合には１１ビットあれば十分であるため、Temporary AIDs for Association Interval elementで指定する各AIDも１１ビットまでで表現すればいいことになる。例えば一時的なAIDがＡＰ用かＳＴＡ用かを識別するためにAP/STA Indicationサブフィールドを設け、そのサブフィールドが1であればＡＰ用、0であればＳＴＡ用とし、その後に一時的なAIDを書き込むサブフィールドを設けるということが考えられる。その場合は、例えば図９のようになる。 If the AID used in this HE-SIG-B is limited to a value range of 1 to 2007, 11 bits is sufficient, so each AID specified by Temporary AIDs for Association Interval element can also be up to 11 bits. It should be expressed. For example, an AP/STA Indication subfield is provided to identify whether the temporary AID is for AP or STA. If the subfield is 1, it is for AP, and if it is 0, it is for STA. It is conceivable to provide a subfield in which the AID is written. In that case, it becomes like FIG. 9, for example.
これでは２つの一時的な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を用いるようにすればよい。 This is applicable only when assigning two temporary AIDs, but the limitation can be removed by making the Temporary AIDs for Association Interval field (c4B) variable length. Also, in this expression method, it is not explicitly expressed that STA1 is AID=2001 and AP1 is AID=2002, so in AP2, together with the above MAC Address of Co-located AP element , AID=2001 for STA must be associated with STA1, and AID=2002 for AP must be associated with AP1. On the other hand, the MAC address of STA1 and its temporary AID, and the MAC address of AP1 and its temporary AID may be notified. In this case, the previous MAC Address of Co-located AP element becomes unnecessary because it is notified by the element. Here, in IEEE 802.11ax, the PHY packet of the DL MU contains a value called BSS_COLOR for identifying the BSS. When AP2 multiplexes and transmits Asoc Rsp from AP2 to STA1 and Asoc Rsp from STA2 to AP1, for example, the BSS_COLOR used by AP2 may be used as the BSS_COLOR of this multiplexed PHY packet. .
以上によって、HE-SIG-Bを構成するのに必要な情報が得られ、周波数多重や空間多重などが利用可能となる。このように、アソシエーションが完了する前であっても、テンポラリ値を割り当てることによって、様々な多重化技術を利用することができる。 As described above, information necessary for configuring HE-SIG-B can be obtained, and frequency multiplexing and spatial multiplexing can be used. Thus, by assigning temporary values even before the association is complete, various multiplexing techniques can be used.
図８Ａおよび図８Ｂに戻って、双方向のアソシエーション関係の構築に関する処理フローの説明を続ける。
ＡＰ２が集約を行う場合（図８Ａ）、ＡＰ１の情報を通知されたＳＴＡ２は、その情報を利用して、Asoc Req生成に必要な情報をＡＰ２に通知するか、ＡＰ１宛てのAsoc ReqをＡＰ２に送る（Ｓ２３）。
Returning to FIGS. 8A and 8B, the description of the processing flow regarding the construction of the bidirectional association relationship continues.
When AP2 aggregates (FIG. 8A), STA2, which has been notified of the information of AP1, uses the information to notify AP2 of information necessary for generating Asoc Req, or sends Asoc Req addressed to AP1 to AP2. send (S23).
Asoc Req生成に必要な情報は、例えば、IEEE 802.11無線ＬＡＮ規格でのSMEからMLME(MAC sublayer management entity)に入力されるMLME-ASSOCIATE.requestプリミティブのパラメータを参考にすればよい。ここで、ＡＰ２は、Asoc Reqのための情報を受けた場合には、ＳＴＡ２からＡＰ１宛てのAsoc Reqを代理で作成する。この結果、ＡＰ２は、自身が作成したAsoc Rspと合わせて、Asoc ReqとAsoc Rspを集約できる。 For the information necessary for Asoc Req generation, for example, the parameters of the MLME-ASSOCIATE.request primitive input from the SME in the IEEE 802.11 wireless LAN standard to the MLME (MAC sublayer management entity) can be referred to. Here, when AP2 receives information for Asoc Req, it creates Asoc Req addressed to AP1 from STA2 on behalf of AP2. As a result, AP2 can aggregate Asoc Req and Asoc Rsp together with Asoc Rsp created by itself.
一方、ＳＴＡ２が集約を行う場合には（図８Ｂ）、ＡＰ２が、ＡＰ１の情報通知の他に、Asoc Rspの生成に必要な情報またはＳＴＡ１に送信予定のAsoc RspをＳＴＡ２に渡す（Ｓ２３’）。同様に、ＳＴＡ２は、自身が作成したAsoc Reqと合わせて、Asoc ReqとAsoc Rspを集約できる。 On the other hand, when STA2 performs aggregation (FIG. 8B), AP2 passes information necessary for generating Asoc Rsp or Asoc Rsp scheduled to be transmitted to STA1 to STA2 in addition to the information notification of AP1 (S23'). . Similarly, STA2 can aggregate Asoc Req and Asoc Rsp together with Asoc Req created by itself.
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を受信・復号することになる。
Here, an example of transmission using frame aggregation will be described. Asoc Rsp and Asoc Req are frame-aggregated to configure A-MPDU (Aggregate MAC Protocol Data Unit), and when sending, the destination address (Receiver Address: RA ), the MAC address of AP2 as a transmitter address (Transmitter Address: TA) in the
逆に、ＳＴＡ２からA-MPDUを送信する場合には、Asoc Reqを先頭にしてAsoc Rspを次に入れるようにした方が望ましい。こうすることで、先頭のAsoc ReqのRAがＡＰ１に指定されていることにより、ＡＰ２がこのA-MPDUを受信・復号することになる。 Conversely, when transmitting A-MPDU from STA2, it is desirable to put Asoc Req at the head and Asoc Rsp next. By doing so, AP2 receives and decodes this A-MPDU because the RA of the leading Asoc Req is designated to AP1.
図１０は、Asoc Rsp、Asoc Reqの順でフレームがアグリゲーションされた例である。Asoc RspとAsoc Reqとは、それぞれ、MPDU（ｄ１）としてMPDU delimiter（DLM）（ｄ１１）で境界がわかるように接続される。MPDU delimiterは、４オクテットの長さを持ち、MPDU長や8bitCRC、MPDU delimiterであることを示すDelimiter Signatureなどから構成される。 FIG. 10 is an example in which frames are aggregated in the order of Asoc Rsp and Asoc Req. Asoc Rsp and Asoc Req are connected as MPDU (d1) so that the boundary can be identified by MPDU delimiter (DLM) (d11). The MPDU delimiter has a length of 4 octets and is composed of MPDU length, 8-bit CRC, Delimiter Signature indicating MPDU delimiter, and the like.
以上の例は、アグリゲーションされたAsoc RspとAsoc ReqそれぞれのMACヘッダに正しく送信先アドレスが指定された場合について述べているが、「Asoc RspはＳＴＡが処理するべきフレーム」、「Asoc ReqはＡＰが処理すべきフレーム」であるという特性を利用することででき、あるいは、さらに、前述と同様に、意図する受信先端末（ＳＴＡまたはＡＰ）への正しい情報をelementに含めることで、必ずしも前述の例のようにフレームがアグリゲーションされている必要はない。例えば、ＡＰ１がAsoc Rspを受信し、RAにＡＰ１が指定されていたとしても、通常、Asoc Rspを処理するのは、ＡＰではなくＳＴＡであり、同一無線端末にＡＰとともにＳＴＡも内包していることを把握しているため、TAがＡＰ１であっても、ＡＰ１はＳＴＡ１にAsoc Rspを渡すことが可能である。 The above example describes the case where the destination address is correctly specified in the MAC header of each of the aggregated Asoc Rsp and Asoc Req. is the frame to be processed", or, as before, by including the correct information to the intended recipient terminal (STA or AP) in the element, the above Frames need not be aggregated as in the example. For example, even if AP1 receives Asoc Rsp and AP1 is specified in RA, it is usually STA, not AP, that processes Asoc Rsp, and the same wireless terminal includes both AP and STA. Therefore, even if the TA is AP1, AP1 can pass Asoc Rsp to STA1.
また、新しく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を今後ＡＰ２との間で用いることも含め)と把握できる。 In addition, a new Receiver Address of This Association Frame element is provided, and the original MAC address to receive the association frame storing that element in the Information field, that is, the MAC function block is specified, and the association frame (Asoc If Asoc Req is the order in which Asoc Req comes next to Rsp, if it is stored in the frame body of Asoc Req), even if AP1 is specified in RA of the MAC header of Asoc Req, AP1's If the MAC function block passes Asoc Rsp to the MAC function block of STA1 or information extracted from the frame of Asoc Rsp, the same processing as if Asoc Rsp was received by the MAC function block of STA1 can be performed. (If the Status Code in Asoc Rsp is 0 (SUCCESS), the AID assigned by the AID field will be used from now on with AP2).
図８Ａおよび図８Ｂに戻って、双方向のアソシエーション関係の構築に関する処理フローの説明を続ける。
ＡＰ２またはＳＴＡ２が送信したフレームは、ＳＴＡ１とＡＰ１それぞれが正しく受信する場合と、ＡＰ１がAsoc Rsp、ＳＴＡ１がAsoc Reqといった、本来と異なるＭＡＣMAC機能ブロックが受信する場合がある。後者の場合、ＡＰ１およびＳＴＡ１は、受信したフレームを処理できないため、他のＭＡＣ機能ブロックへAbstraction機能ブロックなどを介して転送する（図８Ａ：（Ｓ２５）、図８Ｂ：（Ｓ２５’））。
Returning to FIGS. 8A and 8B, the description of the processing flow regarding the construction of the bidirectional association relationship continues.
The frame transmitted by AP2 or STA2 may be received correctly by STA1 and AP1 respectively, or may be received by different MAC MAC functional blocks such as Asoc Rsp by AP1 and Asoc Req by STA1. In the latter case, AP1 and STA1 cannot process the received frame, so they transfer it to another MAC function block via the Abstraction function block (FIG. 8A: (S25), FIG. 8B: (S25')).
このとき、フレームをMAC protocol data unit（MPDU）の形で他のＭＡＣ機能ブロックに転送してもよいし、MAC service data unit（MSDU）の形で他のＭＡＣ機能ブロックに転送してもよいし、具体的な情報レベルで他のＭＡＣ機能ブロックに転送してもよい。MPDUの形で他のＭＡＣ機能ブロックに転送する場合には、他のＭＡＣ機能ブロックのPHYとのI/Fを介して入力するようにしてもよい。これに関しては、ルール化されているものとし、本実施形態では、所望の情報が正確に他のＭＡＣ機能ブロックに通知されればよく、その方法は限定しない。 At this time, the frame may be transferred to other MAC functional blocks in the form of MAC protocol data unit (MPDU), or may be transferred to other MAC functional blocks in the form of MAC service data unit (MSDU). , may be forwarded to other MAC functional blocks at specific information levels. When transferred to another MAC functional block in the form of MPDU, it may be input via an I/F with the PHY of the other MAC functional block. Regarding this, it is assumed that there are rules, and in this embodiment, it is sufficient that the desired information is accurately notified to other MAC functional blocks, and the method is not limited.
ここで、保有しているすべてのＭＡＣ機能ブロックで処理できない場合、そのフレームは破棄される。
ＳＴＡ１は、受信したAsoc Rspを処理し、これによって、ＡＰ２とＳＴＡ１とのアソシエーションが完了する。また、ＳＴＡ２は、受信したAsoc Rspを処理し、これによって、ＡＰ１とＳＴＡ２とのアソシエーションが完了する。
Here, if the frame cannot be processed by all of the MAC functional blocks it possesses, the frame is discarded.
STA1 processes the received Asoc Rsp, which completes the association between AP2 and STA1. STA2 also processes the received Asoc Rsp, which completes the association between AP1 and STA2.
以上のように、本実施形態の電子装置においては、第１実施形態に加えて、フレームを集約して多重化して送信されていることから、より効率化される。
（第３実施形態）
次に、第３実施形態について説明する。
本実施形態は、基本的には、第２実施形態に基づいているため、ここでは、その差分を説明する。
As described above, in the electronic apparatus of the present embodiment, in addition to the first embodiment, the frames are aggregated, multiplexed, and transmitted, so efficiency is improved.
(Third embodiment)
Next, a third embodiment will be described.
Since this embodiment is basically based on the second embodiment, differences therebetween will be explained here.
図１１Ａおよび図１１Ｂは、本実施形態の電子装置（無線端末１および無線端末２）における双方向のアソシエーション関係の構築に関する処理フローの一例をそれぞれ示す図である。
本実施形態が第２実施形態と異なる点は、第２実施形態では、ＳＴＡ１から送信されるAsoc Reqがトリガーとなってアソシエーションが実行されるための処理フローが開始されていたことに対し、このAsoc Reqを省略する点である。このため、本実施形態では、無線端末１が、第２実施形態における無線端末２と似た動作を行い、無線端末２が、第２実施形態における無線端末１と似た動作を行う。
FIGS. 11A and 11B are diagrams respectively showing an example of a processing flow regarding construction of a bidirectional association relationship in the electronic devices (
This embodiment differs from the second embodiment in that, in the second embodiment, the Asoc Req transmitted from STA1 triggers the start of the processing flow for executing the association. The point is that Asoc Req is omitted. Therefore, in this embodiment, the
本実施形態では、ＡＰ１がＳＴＡ２の存在と情報を既知とすることを想定し、ＳＴＡ２からAsoc Reqを受けていないにも関わらず、無線端末１は、ＳＴＡ２を送信先としたAsoc Rspを送信する。つまり、第２実施形態で図８Ａおよび図８Ｂに示した（Ｓ２１）を省略する。
In this embodiment, it is assumed that AP1 is aware of the existence and information of STA2, and
ここで、ＳＴＡ２の存在と情報を既知とする手段には、BeaconやProbe Responseを利用すること、または前提条件によって取り決められていることを考える。BeaconまたはProbe Responseによって情報を通知する場合には、Vendor Specific informationを利用する、または、全く新しいelementを追加する。これによって、無線端末内に存在する他のＳＴＡまたはＡＰの情報を通知することができる。前提条件によって、無線端末内に存在するＡＰ／ＳＴＡの存在の有無に関する情報を既知とする場合、例えば、ネットワークに追加される無線端末は、必ず２つのＭＡＣ機能ブロックを持ち、それぞれのＭＡＣアドレスは１違いで、ＡＰの方が小さい（0に近い）ＭＡＣアドレスであるなどのルールなどを定める方法が考えられる。この場合、新たにネットワークに追加された無線端末のＡＰのＭＡＣアドレスは、Beaconなどを受信することで、そのMACヘッダにあるTAあるいはBSSIDを通知するアドレスフィールドから取得できる。例えば少なくとももう１つＳＴＡとしてＭＡＣ機能ブロックがあるというのが前提条件であれば、同時に当該もう１つのＳＴＡのＭＡＣ機能ブロックのＭＡＣアドレスは、ＡＰのＭＡＣアドレスの末尾を１繰り上げたものと把握することができる。 Here, it is considered that the means for making the existence and information of STA2 known is to use Beacon or Probe Response, or to be determined by preconditions. When notifying information by Beacon or Probe Response, use Vendor Specific information or add a completely new element. This makes it possible to notify the information of other STAs or APs existing in the wireless terminal. If information about the presence or absence of an AP/STA existing in a wireless terminal is known according to the precondition, for example, a wireless terminal added to the network always has two MAC function blocks, and each MAC address is With one difference, a method of setting a rule such that the AP has a smaller (closer to 0) MAC address can be considered. In this case, the MAC address of the AP of the wireless terminal newly added to the network can be obtained from the address field that notifies the TA or BSSID in the MAC header by receiving Beacon or the like. For example, if the precondition is that there is at least one more MAC function block as an STA, the MAC address of the MAC function block of the other STA is understood to be the MAC address of the AP incremented by 1 at the same time. be able to.
無線端末１は、Asoc ReqとAsoc Rspを無線端末２へ送信する。図１１Ａおよび図１１Ｂは、これらのアソシエーションフレームを、ＳＴＡ１（図１１Ａ）またはＡＰ１（図１１Ｂ）が集約して送信する例を示している。なお、第１実施形態のように、ＡＰ１がAsoc Rspを、ＳＴＡ１がAsoc Reqをそれぞれ送信するようにしてもよい。
ＳＴＡが集約して送信を行う場合（図１１Ａ）、ＡＰ１は、Asoc Rspフレームまたは生成に必要な情報をＳＴＡ１に伝達する（Ｓ３１）。一方、ＡＰ１が集約して送信を行う場合（図１１Ｂ）、ＳＴＡ１は、Asoc Reqフレームまたは生成に必要な情報をＡＰ１に伝達する（Ｓ３１’）。 When STAs aggregate and transmit (FIG. 11A), AP1 transmits the Asoc Rsp frame or information necessary for generation to STA1 (S31). On the other hand, when AP1 aggregates and transmits (FIG. 11B), STA1 transmits an Asoc Req frame or information necessary for generation to AP1 (S31').
以降は、第２実施形態の場合と無線端末１，２が逆転して、同様にフローを進める（Ｓ３２［Ｓ３２’］、Ｓ３３［Ｓ３３’］）。
最後に、ＡＰ２は、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の送信に基づき、無線端末２とのアソシエーション関係が構築されたと判断することができる。
Thereafter, the
Finally, AP2 sends Asoc Rsp to STA1 and an association relationship is established (S34 [S34']). Here, information (flag) indicating the result of building the association relationship between AP1 and STA2 may be added to this Asoc Rsp. For example, a new element called Status Code of The Other Association is defined, values are assigned in the same manner as the normal Status Code field, and the content of Status Code of Asoc Rsp received from AP1 to STA2 is copied and inserted. For example, if the Status Code of Asoc Rsp from AP1 to STA2 is 0 and Success (success), a value similar to that is entered in Status Code of The Other Association element and included in Asoc Rsp from AP2 to STA1. In the method using this element, in the example of FIG. 11A, STA1 needs to notify AP1 of the result of the association relationship between AP1 and STA2 (S35). As a result, AP1 can always determine that Asoc Rsp transmitted from AP1 to STA2 has been correctly received by STA2 and that the association relationship between AP1 and STA2 has been established. Thus,
あるいは、ＡＰ１が、ＡＰ１からＳＴＡ２へ送信した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を受信するので、その際にＳＴＡ１からＡＰ１への通知が（Ｓ３５）の代わりに発生する）。 Alternatively, AP1 can confirm that Asoc Rsp transmitted from AP1 to STA2 has been successfully received by STA2, and Asoc Req + Asoc Rsp transmitted from AP1 to STA2 (where + means to aggregate or multiplex ) may be grasped by STA2 transmitting Ack or BlockAck. As a normal operation, for a management frame specifying a unicast MAC address as RA, the receiving side transmits an Ack frame after SIFS (Short Interframe Space) of the management frame. SIFS is the minimum frame interval required when switching between transmission and reception, and for example, in the case of IEEE 802.11 wireless LAN that uses 20 MHz channel intervals in the 5 GHz band, the value is 16 us. In the diagrams (FIGS. 5, 8A, and 8B) showing the frame exchanges so far, transmission of the Ack frame after this SIFS or BlockAck frame, which will be described later, is omitted. Asoc Req and Asoc Rsp, which are management frames, are transmitted with a fixed time longer than this SIFS and a random backoff period. Therefore, an Ack frame is also transmitted for a frame transmitted in the form of Asoc Req+Asoc Rsp. In this case, since the Ack frame is transmitted from AP2 to STA1 in the example of FIG. 11A, STA1 must notify AP1 that Asoc Rsp from AP1 to STA2 has been correctly received by STA2. (Since Ack is received after SIFS of Asoc Req + Asoc Rsp transmission, notification from STA1 to AP1 is generated at that time instead of (S35)).
なお、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サブフィールドがなければ、そのフレーム受信が無線端末２側でなかったことを意味する。したがって、適宜フレームの再送が発生することになる。
In addition, in a form in which two frames, Asoc Req and Asoc Rsp, are aggregated, an Ack frame should be transmitted for each MAC frame, so IEEE 802.11ax Multi-STA BlockAck is applied. You may make it respond in the form which carried out. For example, this BlockAck frame is as shown in FIG. The BA Type subfield of the BA Control field (e1) may define a new BlockAck variant, but here, the case of using IEEE 802.11ax Multi-STA BlockAck will be described. Multi-STA BlockAck has a value of 11 in the BA Type subfield. The BA Information field (e2) is in Per AID TID Info subfield units, but the first Per AID TID Info subfield (e21) is addressed to STA1, and the second Per AID TID Info subfield (e22) is addressed to AP1. Each RA field contains each MAC address. Note that the entire Multi-STA BlockAck contains an RA in the address field at the beginning of the MAC header, and this RA contains a broadcast address. Therefore, since Multi-STA BlockAck is received by both AP1 and STA1 and the delivery confirmation is obtained, there is no need for notification from STA1 to AP1 unlike element and Ack (as in (S35) No notification from STA1 to AP1 is required). Each AID TID Info subfield is further divided into subfields of AID11, Ack Type, and TID. and set. This is the same as the method of transmitting an Ack response in the form of Multi-STA BlockAck to a management frame transmitted by each unconnected STA in UORA, which will be described later. By transmitting such a Multi-STA BlockAck, STA1 has its own MAC address described in the RA subfield of the Per AID TID Info subfield, so that the Asoc Req transmitted from STA1 to AP2 is received by AP2. You can understand what has been done. Also, since AP1 has its own MAC address described in the RA subfield of the Per AID TID Info subfield, it can recognize that Asoc Rsq transmitted from AP1 to STA2 has been received by STA2. can be said to have ended the association process. If there is no Per AID TID Info subfield here, it means that the frame was not received on the
逆に、無線端末１側でＡＰ１とＳＴＡ２のアソシエーション関係が構築できたと確認できない場合には、ＡＰ１は、Asoc Rspを再送する必要が生じるが、ＡＰ１がどの過程を経てAsoc Rspを再送信するかについては、いくつかの手順を適用し得る。
Conversely, if it cannot be confirmed that the association relationship between AP1 and STA2 has been established on the
たとえば、（Ｓ３２）［図１１Ａの場合］に対するACKがあると期待され、それを用いて再送判断する場合、ＳＴＡ１が（Ｓ３２）でフレームを送信した後、一定時間（SIFS時間）後に受信するAsoc Rspに対するACKの有無をＡＰ１に通知する。この結果、ＡＰ１もAsoc Rspに対するACKの有無を知ることができ、無ければAsoc Rspの再送処理に入る（厳密にはCSMA/CAに基づき送信機会を獲得して送信する。以降も同様）。 For example, (S32) [in the case of FIG. 11A] is expected to have an ACK, and if retransmission is determined using that, after STA1 transmits the frame in (S32), after a certain time (SIFS time) Asoc received The presence or absence of ACK for Rsp is notified to AP1. As a result, AP1 can also know the presence or absence of ACK for Asoc Rsp, and if there is no ACK, it will start retransmission processing for Asoc Rsp (strictly speaking, it acquires a transmission opportunity based on CSMA/CA and transmits, and the same applies thereafter).
また、（Ｓ３２’）［図１１Ｂの場合］に対するACKがあると期待され、それを用いて再送判断する場合、このACKを受け取るのはＡＰ１であるため、（Ｓ３２’）でフレームを送信した後、一定時間（SIFS時間）後ACKがなければ、Asoc Rspの再送処理に入る。 Also, (S32') ACK for [in the case of FIG. 11B] is expected, and when retransmission is determined using it, AP1 receives this ACK, so after transmitting the frame in (S32') , If there is no ACK after a certain period of time (SIFS time), retransmission processing of Asoc Rsp is started.
または、（Ｓ３２）あるいは（Ｓ３２’）に対しMulti-STA BlockAckがあると期待され、それを用いて再送判断する場合、このMulti-STA BlockAckはＡＰ１及びＳＴＡ１の各々で受信できるため、（Ｓ３２）あるいは（Ｓ３２’）でフレームを送信した後、一定時間（SIFS時間）後にＡＰ１がMulti-STA BlockAck自体を受信しない場合、あるいはMulti-STA BlockAckのPer AID TID InfoサブフィールドのRAサブフィールドにＡＰ１のＭＡＣアドレスを検出できなかった場合、ＡＰ１はAsoc Rspの再送処理に入る。 Alternatively, if a Multi-STA BlockAck is expected for (S32) or (S32') and retransmission is determined using it, this Multi-STA BlockAck can be received by each of AP1 and STA1 (S32). Alternatively, if AP1 does not receive Multi-STA BlockAck itself after a certain period of time (SIFS time) after transmitting the frame in (S32'), or if the RA subfield of the Per AID TID Info subfield of Multi-STA BlockAck If the MAC address cannot be detected, AP1 enters Asoc Rsp retransmission processing.
あるいは、（Ｓ３４）［図１１Ａの場合］におけるAsoc Rspで通知される場合、ＡＰ１は、ＳＴＡ１から（（Ｓ３２）で送信したAsoc RspのACKの有無を受けるのではなく）（Ｓ３４）のAsoc Rspに示された内容（Status Code of The Other Association elementまたはACK bit）の通知を受ける。この結果、ＡＰ１とＳＴＡ２とのアソシエーションが構築されていないと判明した場合にＡＰ１はAsoc Rspの再送処理に入る。 Alternatively, when notified by Asoc Rsp in (S34) [in the case of FIG. 11A], AP1 receives Asoc Rsp in (S34) (instead of receiving ACK of Asoc Rsp transmitted in (S32)) from STA1. (Status Code of The Other Association element or ACK bit) is notified. As a result, when it is found that the association between AP1 and STA2 has not been established, AP1 enters Asoc Rsp retransmission processing.
本実施形態において、ＡＰ１からＳＴＡ２に対するAsoc Rspが、Asoc Reqを省略して送信されていることに関して、例えば、ＳＴＡ２がすでに他のＡＰとアソシエーション関係を構築しているなどして、ＳＴＡ２がAsoc Rspを受け付けられない場合に、明示的にＡＰ１にそのことを伝えることは重要である。これは、ＡＰ１がAsoc Rspをアソシエーション不可のＳＴＡ２へ何度も送信することを回避するためである。 In this embodiment, Asoc Rsp from AP1 to STA2 is transmitted without Asoc Req. is not accepted, it is important to explicitly tell AP1 about it. This is to avoid AP1 from repeatedly sending Asoc Rsp to STA2 that cannot be associated.
次に、以上について、ここまでで説明した、Status Code of The Other Association elementを利用し、Asoc RspのStatus Codeが0（(成功)をコピーするのではなく、他の不成功を意味するいずれか適当なStatus Codeに書き換える方法以外である、Disassociationフレーム（DisAsoc）を用いる手段について述べる。 Next, for the above, using the Status Code of The Other Association element explained so far, the Status Code of Asoc Rsp does not copy 0 ((success), but any other unsuccessful A method using a Disassociation frame (DisAsoc) other than the method of rewriting to an appropriate Status Code will be described.
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フレームによって、ＡＰ１にその内容を通知できる。
By using DisAsoc, the STA can notify the AP with which it has established an association relationship of disassociation. DisAsoc has a Reason Code field in the frame body. By notifying the reason for withdrawing the association relationship using the Reason Code field, AP1 that receives DisAsoc will help to make an appropriate judgment thereafter. For example, there is a Reason Code of 12, BSS_TRANSITION_DISASSOC, which indicates the reason why the STA wants to move to another AP. By doing so, it is possible to notify the AP with which the association relationship is currently established with the reason for the cancellation of the relationship. In addition to using the value defined by the existing reason code, when specifically notifying the reason for refusal of the STA in this embodiment, the
以上のように、本実施形態の電子装置においては、第２実施形態におけるＳＴＡ１からのAsoc Reqの送信（図８Ａ：（Ｓ２１）、図８Ｂ：（Ｓ２１’））を省略することができる。
（第４実施形態）
次に、第４実施形態について説明する。
本実施形態は、基本的には、第３実施形態に基づいているため、ここでは、その差分を説明する。
As described above, in the electronic device of the present embodiment, transmission of Asoc Req from STA1 in the second embodiment (FIG. 8A: (S21), FIG. 8B: (S21')) can be omitted.
(Fourth embodiment)
Next, a fourth embodiment will be described.
Since this embodiment is basically based on the third embodiment, differences therebetween will be explained here.
図１３Ａおよび図１３Ｂは、本実施形態の電子装置（無線端末１および無線端末２）における双方向のアソシエーション関係の構築に関する処理フローの一例をそれぞれ示す図である。
本実施形態が第３実施形態と異なる点は、第３の実施形態では、無線端末１からのAsoc ReqとAsoc Rspをトリガーとして処理が開始されていることに対し、これらのうちのいずれか一方を送信する点である。
FIGS. 13A and 13B are diagrams respectively showing an example of a processing flow regarding construction of a two-way association relationship in the electronic devices (
The difference of this embodiment from the third embodiment is that, in the third embodiment, processing is started with Asoc Req and Asoc Rsp from the
つまり、本実施形態では、前述の第３実施形態において（Ｓ３２）［図１１Ａ］またはＳ３２’［図１１Ｂ］で送信しているAsoc ReqとAsoc Rspの片方を送信しない。片方が送信されない場合、それぞれ、本来通知すべき情報が不足することは明確である。逆に考えると、この不足した情報を互いに共有できれば、片方を送信せずにアソシエーション関係の構築を実行することができる。 That is, in the present embodiment, one of Asoc Req and Asoc Rsp, which is transmitted in (S32) [Fig. 11A] or S32' [Fig. 11B] in the third embodiment, is not transmitted. If one is not sent, it is clear that the information to be notified is lacking in each case. Conversely, if this missing information can be shared with each other, it is possible to build an association relationship without sending one of them.
不足する情報の例として、Asoc Reqを送信しない場合には、ＳＴＡ１のＭＡＣアドレスなどが考えられ、一方、Asoc Rspの場合は、ＳＴＡ２に割り当てられたAIDなどが考えられる。Asoc ReqとAsoc Rspの片方を送信せずに、これらの情報を如何にして共有するかについては、たとえば、前提条件によって、これらの情報を共通情報としてもよいし、BeaconやProbe Responseを用いて、これらの情報について事前に情報共有を行ってもよい。 Examples of missing information include the MAC address of STA1 when Asoc Req is not sent, and the AID assigned to STA2 when Asoc Rsp is sent. Regarding how to share these information without sending one of Asoc Req and Asoc Rsp, for example, depending on the precondition, these information may be used as common information, or using Beacon or Probe Response , information may be shared in advance.
また、送信していない方のアソシエーションフレームの情報を、送信している方のアソシエーションフレームの情報または既知の情報と共通にし、または、ルール化により、送信している方のアソシエーションフレームの情報または既知の情報から算出可能にしてもよい。Asoc RspとAsoc Reqで共通化できる情報としては、例えば、HT Capabilityが考えられる。また、ＡＰ１とＳＴＡ１のＭＡＣアドレスを連番などと取り決めていれば、ＡＰ１のＭＡＣアドレスからＳＴＡ１のＭＡＣアドレスが算出でき、逆に、ＳＴＡ１のＭＡＣアドレスからＡＰ１のＭＡＣアドレスを算出することもできる。 Also, the information of the association frame that is not transmitted is shared with the information of the association frame that is transmitted or known information, or the information of the association frame that is transmitted or known information is made into a rule. It may be possible to calculate from the information of Information that can be shared between Asoc Rsp and Asoc Req is, for example, HT Capability. Also, if the MAC addresses of AP1 and STA1 are serial numbers, the MAC address of STA1 can be calculated from the MAC address of AP1, and conversely, the MAC address of AP1 can be calculated from the MAC address of STA1.
さらには、送信している方のアソシエーションフレームに、送信しない方の情報を新規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のみ（図１３Ｂ：（Ｓ４２’））とすることができる。
Furthermore, the information of the non-transmitting side may be added as a new element or vendor specific element to the transmitting association frame. In this way,
As described above, in the electronic device of the present embodiment, regarding the transmission of Asoc Req and Asoc Rsp from the
（第５実施形態）
次に、第５実施形態について説明する。
本実施形態は、基本的には、第１実施形態から第４実施形態に基づいているため、ここでは、その差分を説明する。
図１４は、本実施形態の電子装置（無線端末１および無線端末２）における双方向のアソシエーション関係の構築に関する処理フローの一例を示す図である。
(Fifth embodiment)
Next, a fifth embodiment will be described.
Since this embodiment is basically based on the first to fourth embodiments, differences therebetween will be explained here.
FIG. 14 is a diagram showing an example of a processing flow regarding construction of a two-way association relationship in the electronic devices (
図１４に示すように、本実施形態においては、無線端末２を複数とする（無線端末２－１，２－２，．．．，２－Ｎ）。なお、図１４は、第２実施形態（図８Ａ）において無線端末２を複数とした場合を想定した例を示しているが、本実施形態の手法は、前述の第１実施形態から第４実施形態のすべてに適用し得る。
As shown in FIG. 14, in this embodiment, there are a plurality of wireless terminals 2 (wireless terminals 2-1, 2-2, . . . , 2-N). Note that FIG. 14 shows an example assuming a case where a plurality of
まず、無線端末１から送信するＭＡＣフレームのRAをbroadcast addressに設定し、無線端末２－１，２－２，．．．，２－Ｎへアソシエーションフレームをブロードキャストする（Ｓ５１）。ブロードキャストするとき、アソシエーションフレームの無線端末２－１，２－２，．．．，２－Ｎそれぞれに宛てた情報部分については、多重化してもよいし、１つのフレームに無線端末２－１，２－２，．．．，２－Ｎそれぞれに対する情報と無線端末２－１，２－２，．．．，２－Ｎそれぞれの宛先を含めた新しいelementを設けてもよい。
First, the RA of the MAC frame transmitted from the
ブロードキャストによって送信されたアソシエーションフレームを受けた無線端末２－１，２－２，．．．，２－Ｎは、自身以外に宛てられた情報も受けることとなるため、RAを確認して、自身宛の（もしくは全ての無線端末に宛てられた）情報を抽出して、その後の処理を進めていく（図１４の例では、（Ｓ５４）のAsoc Rspを返す処理）。 The wireless terminals 2-1, 2-2, . . . , 2-N will also receive information addressed to other than itself, so check RA, extract information addressed to itself (or addressed to all wireless terminals), and perform subsequent processing. Proceed (in the example of FIG. 14, the process of returning Asoc Rsp in (S54)).
無線端末２－１，２－２，．．．，２－Ｎからのフレームは、ＭＵ通信で無線端末１へ送信される。これを実現するには、テンポラリのAIDを定義しておくか、UORA（Uplink OFDMA-based Random Access）を利用する。
テンポラリAIDを定義する場合、ＭＵ通信を行う前に、ＡＰから複数のＳＴＡに送信されるフレームが存在することが前提となる。なお，必ずしもアソシエーションフレームでなくてもよく、テンポラリAIDを振り分けるためのBeaconフレームやProbeフレームでもよい。
Wireless terminals 2-1, 2-2, . . . , 2-N are transmitted to the
When defining a temporary AID, it is assumed that there are frames to be transmitted from the AP to multiple STAs before MU communication is performed. Note that the frame may not necessarily be an association frame, and may be a Beacon frame or Probe frame for distributing temporary AIDs.
また、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の代わりとする。これにより、アソシエーション前でも、ＡＰは、複数のＳＴＡから、フレームを同時に送信させることができる。
Also, when the UL MU puts frames together, the AP needs to transmit a trigger frame. A wireless terminal having a frame to transmit to the AP transmits the frame after a certain period of time (after SIFS) after receiving the trigger frame.
Here, UORA is UL OFDMA that can be realized without designating terminals as RUs. A STA having a transmission frame determines whether or not to transmit to an RU with no AID specified, in the same manner as in CSMA/CA random access. If two or more terminals select the same RU and transmit, the transmission fails due to collision. If the RU's AID is 2045, terminals with no AID assigned can use it. A terminal with no AID assigned can transmit only one management frame in the RU. While setting AID to 2045 in the Multi-STA BlockAck frame, the AP puts the MAC address of the successfully received terminal in the area where the normal BlockAck bitmap is displayed, as an ACK to the successfully received terminal. This allows the AP to simultaneously transmit frames from multiple STAs even before association.
以上のように、本実施形態の電子装置においては、複数の外部装置との間の双方向のアソシエーション関係を効率的に構築することを可能とする。
以上説明したいくつかの実施形態の電子装置によれば、効率的に２つの電子装置が互いにアソシエーションする方法によって、電子装置間の一方的な関係では実現できない双方向のＭＵ通信が実行可能となり、情報伝送の時間効率を向上させる。
As described above, in the electronic device of this embodiment, it is possible to efficiently construct a bidirectional association relationship with a plurality of external devices.
According to the electronic devices of the several embodiments described above, the method of efficiently associating two electronic devices with each other makes it possible to execute two-way MU communication that cannot be realized in a one-way relationship between electronic devices, Improve the time efficiency of information transmission.
また、これにより、メッシュネットワークにおけるルーティングやルートダイバーシチ、ネットワークモニタリングなどでの同時送受信要求を実現しやすくなる。
本発明のいくつかの実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。
This also makes it easier to realize simultaneous transmission and reception requests in routing, route diversity, network monitoring, etc. in mesh networks.
While several embodiments of the invention have been described, these embodiments have been presented by way of example and are not intended to limit the scope of the invention. These novel embodiments can be implemented in various other forms, and various omissions, replacements, and modifications can be made without departing from the scope of the invention. These embodiments and modifications thereof are included in the scope and gist of the invention, and are included in the scope of the invention described in the claims and equivalents thereof.
１，２…無線端末、１１…送受信部、１２…ＭＡＣ機能ブロック、１３…ホスト機能ブロック、１００…無線通信システム、１２１…アソシエーションフレーム生成部。
DESCRIPTION OF
Claims (3)
前記第１アソシエーション要求フレームに対応する第１アソシエーション応答フレームを前記第１電子装置から受信する受信手段と、
前記第１アソシエーション応答フレームの受信に基づき、前記第１電子装置の第１ステーション部とのアソシエーション関係と、前記第１電子装置の第１アクセスポイント部とのアソシエーション関係とが構築されたと判定する制御手段と、
を具備する電子装置。 transmitting means for transmitting a first association request frame to the first electronic device;
receiving means for receiving a first association response frame corresponding to the first association request frame from the first electronic device;
Control for determining that an association relationship with a first station unit of the first electronic device and an association relationship with a first access point unit of the first electronic device are established based on the reception of the first association response frame. means and
An electronic device comprising:
前記第１アソシエーション要求フレームは、前記第１電子装置及び第２電子装置に受信されるものであって、
前記受信手段は、前記第１電子装置から前記第１アソシエーション応答フレームを受信し、かつ、前記第２電子装置から、前記第１アソシエーション要求フレームに対応するアソシエーション応答フレームを受信する、
請求項１に記載の電子装置。 the transmitting means broadcasts the first association request frame;
The first association request frame is received by the first electronic device and the second electronic device,
the receiving means receives the first association response frame from the first electronic device and receives an association response frame corresponding to the first association request frame from the second electronic device;
An electronic device according to claim 1 .
前記第１アソシエーション要求フレームが受信された場合、前記第１アソシエーション要求フレームに対応する第１アソシエーション応答フレームを前記第１電子装置へ送信する送信手段と、
前記第１アソシエーション応答フレームの送信に基づき、前記第１電子装置の第１ステーション部とのアソシエーション関係と、前記第１電子装置の第１アクセスポイント部とのアソシエーション関係とが構築されたと判定する制御手段と、
を具備する電子装置。 receiving means for receiving a first association request frame from the first electronic device;
transmitting means for transmitting a first association response frame corresponding to the first association request frame to the first electronic device when the first association request frame is received;
Control for determining that an association relationship with the first station unit of the first electronic device and an association relationship with the first access point unit of the first electronic device are established based on the transmission of the first association response frame. means and
An electronic device comprising:
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2023102928A JP2023116804A (en) | 2018-11-29 | 2023-06-23 | electronic device |
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2018223445A JP7039446B2 (en) | 2018-11-29 | 2018-11-29 | Electronic device |
| JP2022035447A JP7305829B2 (en) | 2018-11-29 | 2022-03-08 | electronic device |
| JP2023102928A JP2023116804A (en) | 2018-11-29 | 2023-06-23 | electronic device |
Related Parent Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2022035447A Division JP7305829B2 (en) | 2018-11-29 | 2022-03-08 | electronic device |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| JP2023116804A true JP2023116804A (en) | 2023-08-22 |
Family
ID=87072378
Family Applications (2)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2022035447A Active JP7305829B2 (en) | 2018-11-29 | 2022-03-08 | electronic device |
| JP2023102928A Pending JP2023116804A (en) | 2018-11-29 | 2023-06-23 | electronic device |
Family Applications Before (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2022035447A Active JP7305829B2 (en) | 2018-11-29 | 2022-03-08 | electronic device |
Country Status (1)
| Country | Link |
|---|---|
| JP (2) | JP7305829B2 (en) |
Family Cites Families (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP4314294B2 (en) * | 2004-04-02 | 2009-08-12 | 株式会社東芝 | COMMUNICATION DEVICE, COMMUNICATION SYSTEM, COMMUNICATION METHOD, AND COMMUNICATION CONTROL PROGRAM |
| US20100246464A1 (en) * | 2009-03-23 | 2010-09-30 | Texas Instruments Incorporated | Power conservation through bi-directional association of multiple devices |
| US8873393B2 (en) * | 2010-01-20 | 2014-10-28 | Nec Europe Ltd. | Method for operating a wireless network and a wireless network |
| US9198215B2 (en) * | 2013-03-01 | 2015-11-24 | Qualcomm Incorporated | Peer connectivity using reciprocal wireless connections |
-
2022
- 2022-03-08 JP JP2022035447A patent/JP7305829B2/en active Active
-
2023
- 2023-06-23 JP JP2023102928A patent/JP2023116804A/en active Pending
Also Published As
| Publication number | Publication date |
|---|---|
| JP2022066488A (en) | 2022-04-28 |
| JP7305829B2 (en) | 2023-07-10 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP7394920B2 (en) | Communication devices, communication methods and integrated circuits | |
| KR102448231B1 (en) | Resource Units for Unassociated Stations and Grouped Multi-User Transmissions in 802.11ax Networks | |
| US10432381B2 (en) | Method for transmitting and receiving multiple user block acknowledgement frame in wireless LAN system, and apparatus therefor | |
| US10425209B2 (en) | Method and apparatus for processing ACK signal in a wireless local area network system | |
| US20230262768A1 (en) | Method and wireless communication terminal for transmitting/receiving frame in wireless communication system | |
| US8175047B2 (en) | Data transmission method in wireless mesh network and A-MSDU format | |
| US9844037B2 (en) | Method and apparatus for transmitting uplink in wireless communication system | |
| JP2020014235A (en) | Wireless communication device and wireless communication method | |
| US20170311310A1 (en) | Method and device for allocating uplink transmission resource on basis of buffer status information in wireless lan | |
| US10313082B2 (en) | Method for transmitting and receiving acknowledgment/negative-acknowledgment signal for uplink multi-user data in wireless LAN system and apparatus therefor | |
| JP6335205B2 (en) | Wireless communication apparatus and wireless communication method | |
| US20170359159A1 (en) | Method for transmitting and receiving acknowledgment signal for uplink multi-user data in wlan system and device therefor | |
| JP6715204B2 (en) | Wireless communication device and wireless communication method | |
| JP6876847B2 (en) | Wireless communication device and wireless communication method | |
| US11677445B2 (en) | Electronic apparatus | |
| JP7146042B2 (en) | Wireless communication device and wireless communication method | |
| JP7053033B2 (en) | Wireless communication equipment and methods | |
| WO2017076069A1 (en) | Wireless communication method and device | |
| JP7305829B2 (en) | electronic device | |
| US10341058B2 (en) | Method for transmitting and receiving multi-station block ACK frame of expanded capacity and device therefor | |
| JP2021114720A (en) | Radio communication device, method, and radio communication system | |
| JP7322226B2 (en) | Wireless communication device and method | |
| US20230284290A1 (en) | Enhanced Multi-link UORA | |
| WO2024086193A1 (en) | Transmission techniques for multi-ap transmission | |
| KR20230129466A (en) | Wireless communication method using multi-link and wireless communication terminal using the same |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20230623 |