JP7635302B2 - Electronics - Google Patents

Description

An embodiment of the present invention relates to an electronic device.

There are wireless communication devices that have multiple MAC addresses. In a wireless communication device that has multiple MAC addresses, for example, it is possible to establish an association relationship with another wireless communication device as an access point (AP), and also to establish an association relationship with another wireless communication device as a station (STA).

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

Conventionally, in a wireless communication device having multiple MAC addresses, it was possible to establish two association relationships with another wireless communication device having multiple MAC addresses, in which the AP and STA relationships were staggered, thereby establishing a bidirectional association relationship, but it was not possible to recognize whether the two association relationships were established with the same other wireless communication device.
An object of the present invention is to provide an electronic device that can establish a bidirectional association relationship with the same external device while recognizing that the electronic device is connected to the same external device.

According to an embodiment, the electronic device includes a transmitting means, a receiving means, and a control means. The transmitting means transmits a first association request frame to the first electronic device. The receiving means receives a first association response frame from the first electronic device corresponding to the first association request frame. The control means determines, based on the reception of the first association response frame, 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 have been established. This allows the association relationship with the first station unit of the first electronic device and the association relationship with the first access point unit of the first electronic device to be established simultaneously.

FIG. 1 is a diagram illustrating an example of a wireless communication system including an electronic device according to a first embodiment. FIG. 2 is a diagram showing an example of a functional block configuration of the electronic device according to the first embodiment. FIG. 1 is a diagram showing an example of a configuration of an electronic device according to a first embodiment. 1 shows an example of a format of a Management frame. 5 is a diagram showing an example of a processing flow relating to building a bidirectional association relationship in the electronic device according to the first embodiment; A diagram showing the format of the element stored in the Association Request frame body. 7 is a diagram showing an example of a Co-located AP Info element created in accordance with the format of FIG. 6 in the electronic device of the first embodiment. FIG. 13 is a diagram showing an example of a processing flow relating to the construction of a bidirectional association relationship in the electronic device of the second embodiment (a case in which the AP aggregates Asoc Rsp and Asoc Req). FIG. 13 is a diagram showing another example of the processing flow relating to the construction of a bidirectional association relationship in the electronic device of the second embodiment (a case in which the STA aggregates Asoc Rsp and Asoc Req). FIG. 11 is a diagram showing an example of Temporary AIDs for Association Interval element created in the electronic device according to the second embodiment. FIG. 13 is a diagram showing another example of Temporary AIDs for Association Interval elements defined in the electronic device according to the second embodiment. FIG. 13 is a diagram showing an example of a processing flow relating to the construction of a bidirectional association relationship in an electronic device according to the third embodiment (a case in which a STA aggregates Asoc Rsp and Asoc Req). FIG. 11 is a diagram showing another example of the processing flow relating to the construction of a bidirectional association relationship in the electronic device of the third embodiment (a case in which (SS)P in FIG. 8A aggregates Asoc Rsp and Asoc Req). FIG. 13 is a diagram showing an example of a BlockAck frame that can be used in the electronic device according to the third embodiment. FIG. 13 is a diagram showing an example of a process flow relating to building a bidirectional association relationship in an electronic device according to the fourth embodiment (a case in which an Asoc Req is transmitted). FIG. 13 is a diagram showing another example of the process flow relating to the construction of a bidirectional association relationship in the electronic device of the fourth embodiment (a case in which an Asoc Rsp is transmitted). FIG. 13 is a diagram showing an example of a processing flow relating to building a bidirectional association relationship in an electronic device according to the fifth embodiment.

Hereinafter, an embodiment will be described with reference to the drawings.
First Embodiment
First, the first embodiment will be described.
1 is a diagram showing an example of a wireless communication system 100 including electronic devices (wireless terminal 1 and wireless terminal 2) according to the first embodiment. The wireless terminal 1 and the wireless terminal 2 can be realized as various electronic devices having wireless communication functions, such as personal computers such as tablet PCs and notebook PCs, and smartphones. This wireless communication system 100 is established by the wireless terminal 1 and the wireless terminal 2 establishing an association relationship for wireless communication.

Each of the wireless terminals 1 and 2 is realized by a functional block configuration conforming to the hierarchical model shown in FIG. 2, and has multiple MAC addresses. The functional block having each MAC address is called a MAC functional block (a1). The multiple MAC functional blocks of each of the wireless terminals 1 and 2 are organized by their respective Abstraction functional blocks (a2), and can be regarded as one MAC functional block from the upper functional block (a4). The Abstraction functional block plays a role in distributing frames from the upper functional block to the appropriate one of the multiple MAC functional blocks based on the MAC address, and in realizing frame exchange between the MAC functional blocks. The method of distributing frames from the upper functional block to the appropriate MAC functional block and the method of frame exchange between the MAC functional blocks will be described later. In addition, the PHY functional block (a3) exists below the MAC functional block. In FIG. 2, (A) shows an example in which one PHY functional block is provided for multiple MAC functional blocks, and (B) shows an example in which multiple PHY functional blocks are provided in pairs with multiple MAC functional blocks.

FIG. 3 shows an example of the configuration of the electronic device (wireless terminal 1 and wireless terminal 2) of this embodiment.
As shown in FIG. 3, wireless terminal 1 and wireless terminal 2 each have a transceiver unit 11 (first transmitter unit 11-1, second transceiver unit 11-2) that transmits and receives MAC frames, MAC functional blocks (first MAC block 12-1, second MAC block 12-2) that generate the aforementioned MAC frames and control access to the wireless medium (air), and a host functional block 13.

The transceiver 11, MAC function block, and host function block 13 may each be configured as separate electronic circuits, or some or all of them may be configured as a single electronic circuit. They may also be configured by firmware stored in a memory device and executed by a processor.

The transceiver 11 provides functions corresponding to the PHY functional block in FIG. 2. FIG. 3 shows a case where a PHY functional block is connected to each MAC functional block in FIG. 2(B). If the PHY functional block in FIG. 2(A) is common to multiple MAC functional blocks, the transceiver 11 can be made into one and connected to each MAC functional block. FIG. 3 shows an example where there are two MAC functional blocks 12. For example, each MAC functional block 12 has an association frame generating unit 121 (association frame generating unit 121-1, association frame generating unit 121-2). The association frame generating unit 121 generates an association request frame or an association response frame required to perform the association process. Each MAC functional block 12 connects to a host functional block 13. The host function block 13 includes the Abstraction function block in Figure 2 and function blocks corresponding to its upper layers.

In this embodiment, frames in a wireless LAN system conforming to the IEEE 802.11 standard are 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, and other standards, as well as successor standards to IEEE 802.11 that will be defined in the future.

Figure 4 shows an example of the format of a Management frame. Management frames are used to establish a BSS (Basic Service Set) and connect/disconnect with STAs (including APs). In addition to Management frames, frames in the format shown in Figure 4 include Data frames that carry packets from higher-level functional blocks and Control frames used to control communications at the MAC level. The types of these frames are identified by the Type in the Frame Control (b11) of the MAC Header section (b1), which will be described later, and more specific types such as Association Request are identified by the Subtype in the Frame Control.

The management frame includes a MAC Header section (b1), a Frame Body section (b2), and a Frame Check Sequence (FCS) section (b3).
The MAC Header section sets information necessary for reception processing in the MAC function block. The Frame Body section sets information according to the type of frame. The FCS section sets a CRC (Cyclic Redundancy Code), which is an error detection code used to determine whether the MAC Header section and Frame Body section have been received correctly.

The MAC Header section contains a Frame Control field (b11), a Duration field (b12), and other fields in which values are set according to the type of frame. The MAC Header section also contains multiple Address fields (b13). The Address 1 field contains the MAC address of the direct receiving side (Receiving Address: RA). The Address 2 field contains the MAC address of the direct transmitting station (Transmitting Address: TA). The Address 3 field contains an address such as the BSSID. When an AP forms a BSS, the BSSID is equal to the MAC address of the AP.

The MAC Header also contains a Sequence Control field (b14). The Sequence Control field contains the sequence number of the data to be sent and the fragment number if the data is fragmented.

The Frame Control field (B11) contains a Type field and a Subtype field that indicate the type of frame, as well as a To DS field, a From DS field, a more fragment field, a protected frame field, an order field, etc.

The bit string set in the Type field allows you to identify which frame type a MAC frame belongs to: Control frame, Management frame, or Data frame. Furthermore, the bit string in the Subtype field indicates the type of MAC frame within each frame type.

In addition, the To DS field is set with information indicating whether the receiving station is a wireless base station or a wireless terminal, and the From DS field is set with information indicating whether the transmitting station is a wireless base station or a wireless terminal.
The More Fragment field holds information indicating whether or not there is a subsequent fragment frame when data is fragmented. The Protected Frame field holds information indicating whether or not the frame is protected. The Order field holds information indicating that the order of frames must not be changed when relaying the frames. Alternatively, the information in the Order field may also serve to indicate the presence or absence of an option field, which will be described later.

The MAC Header may also contain an HT (High Throughput) Control field (b15). The HT Control field is present when the frame is a QoS Data or Management frame and the order field is set to 1. The HT Control field can be expanded to either a VHT (Very High Throughput) Control field or a HE (High Efficient) Control field, and can provide notifications according to the various functions of IEEE 802.11n, IEEE 802.11ac, or IEEE 802.11ax, respectively.

The configuration of the MAC Header is not limited to the above fields. When a new successor standard to IEEE 802.11 is defined, new fields may be added to the MAC Header.
Next, a process for establishing a bidirectional association relationship so that the wireless terminal 1 and the wireless terminal 2 can act as both an AP and a STA will be described.

Here, the role of an AP refers to the role of being able to simultaneously collect packets from and transmit packets to multiple destinations, for example, using multi-user communication (hereinafter, MU communication) based on IEEE 802.11ax, and the role of a STA refers to the role played by a wireless terminal other than the AP in the aforementioned MU communication.

Association is a process in which a STA connects to an AP, in other words, joins a BSS created by an AP, and usually the AP responds to a request from the STA. If the AP grants the request (the Status Code field of the response frame is 0 (SUCCESS)), an AID is assigned to the STA. This allows the STA to send data frames within the BSS created by the AP.

The two MAC function blocks 12-1 and 12-2 in wireless terminal 1 are called AP1 and STA1, respectively, and similarly, the two MAC function blocks 12-1 and 12-2 in wireless terminal 2 are called AP2 and STA2, respectively. In other words, wireless terminal 1 and wireless terminal 2 each have an access point section and a station section realized by MAC function blocks 12-1 and 12-2 that have different MAC addresses. Hereinafter, STA1 associates with AP2, and STA2 associates with AP1.

Consider here the case where processing is started from wireless terminal 1, due to the symmetry between wireless terminal 1 and wireless terminal 2. An example of a processing flow relating to the establishment of a bidirectional association relationship is shown in FIG.
The processing flow for establishing a bidirectional association relationship begins when a STA, which is aware of the existence and information of AP2 from a Beacon or Probe Response transmitted from wireless terminal 2, prerequisites, etc., transmits an Association Request (Asoc Req), which is an example of a Management frame, to AP2 (S11).

Here, the information on the AP 2 includes at least the MAC address of the AP 2, and may also include other information that is necessary for association but is unknown, such as an SSID (Service Set Identifier).
STA1 notifies, by means of the Asoc Req, Capability Information, Listen Interval, and information indicating the SSID to which it wishes to connect, as well as information necessary for association and communication (Supported Rates and BSS Membership Selectors, Power Capability, etc.).

When STA1 transmits an Asoc Req to AP2, association between STA1 and AP2 is initiated. In this embodiment, however, wireless terminal 1 further uses the Asoc Req to notify wireless terminal 2 of information about AP1.
Here, the information of AP1 refers to the necessary information among the information required to complete the association (e.g., MAC address and communication channel of AP1, etc.), excluding information that is known as a prerequisite and information that has already been notified from AP1 to the STA using a Beacon or Probe Response (because the MAC address of the AP becomes the BSSID, it is possible to associate which Beacon/Probe Response by having the MAC address of the AP notified). Note that, if there is no information to be notified, the information of AP1 is information indicating that there is an AP1 that can be associated with the wireless terminal 1 to which STA1 belongs. This information of AP1 allows the wireless terminal 2 to identify that the wireless terminal 1 has an access point unit and a station unit to which different MAC addresses are assigned. Furthermore, this information of AP1 allows the wireless terminal 2 to transmit an Asoc Req, which will be described later, to the wireless terminal 1.

As a means of notifying information about AP1 using Asoc Req, it is possible to define a new element in the Association Request frame body, or to use the Vendor Specific element added to the end of the Association Request frame body. Currently, in IEEE 802.11, the Element ID for identifying elements is exhausted, so if the maximum value of 255 is in the Element ID, an Element ID Extension subfield is added so that it can be identified there. For example, a new Element is defined using a value that is not assigned in the existing IEEE 802.11 standard as this Element ID Extension subfield. This new element or Vendor Specific element includes at least the MAC address information of AP1. If AP1 does not transmit a Beacon frame, it may be possible to include information that is conventionally notified in a Beacon frame. For example, when the SSID is shared between the wireless communication terminals, the SSID used by AP2 and the SSID used by AP1 are the same, so even if the SSID is omitted, it can be processed as known by STA2, even if it is notified in a Beacon frame as in the past.

It should be noted that if the wireless terminal 2 does not have multiple MAC functional blocks or if the Element ID cannot be recognized, association with the AP 1 is not performed and is ignored.
The format of an element that is inserted in an Association Request frame body, etc., is shown in Figure 6. The basic structure of the element format is that at the beginning, there is an Element ID field (c1) for identifying the element, followed by a Length field (c2) that indicates the total length of the following fields in octets. If the Element ID field is 255, an Element ID Extension field (c3) is further provided for extending the Element ID number. It also includes an Information field (c4) that stores information about the Element ID.

The Information field may contain only one piece of information, such as the SSID Element with an Element ID of 0, or multiple pieces of information, such as the Power Capability with an Element ID of 33. In other words, any number of pieces of information can be notified, up to a maximum of one octet that can be specified in the Length field. When multiple information fields are inserted after the Length field, if each information field has a fixed value, the receiving side can also extract information from each information field by defining it in advance. If it is desired to make some of the information fields variable length, the necessary subfields for specifying the field length can be added before the relevant information field.

Here is an example of constructing a frame using an element defined as Vendor Specific for the MAC address of AP1. Vendor Specific elements are provided to include information that each vendor wishes to notify for its own convenience, and are not defined in the IEEE 802.11 wireless LAN standard.

First, to notify that this is a vendor specific element, the Element ID is set to 221. Next, a value indicating the length of the subsequent Organization Identifier and Vendor-specific content fields is set in the Length field. The Organization Identifier is used to identify which organization is using it specifically, and in this embodiment, the MAC address of AP1 is entered as the vendor specific content.

When defining a new element, the Element ID is set to 255, and an unused value in the existing IEEE 802.11 standard (such as 0 to 8, 12, 52, ...) may be used for the Element ID Extension, or an unused value in the existing IEEE 802.11 standard (such as 2, 8, 9, ...) may be used for the Element ID. In the latter case, the Element ID Extension field is not necessary. Then, for example, the Information field is named the MAC Address of Co-located AP field, and the MAC address of AP1 is entered there. Since the MAC address of the AP is equivalent to the BSSID of the BSS that the AP configures, 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 are partly the same (for example, the beginning), it is possible to display not all 6 octets of the MAC address of AP1, but rather shorten it by displaying, for example, the first X octets are common and the remaining (6-X) octets. In any case, it is sufficient that the received Asoc Req contains information that enables STA2 to generate an Asoc Req for AP1 on the wireless terminal side that received the Asoc Req. Figure 7 shows an example of an element with an Element ID of 255, an Element ID Extension of, for example, 60, and a 6-octet MAC Address of Co-located AP field. For example, let this new element be a Co-located AP Info element (c4A).

Returning to FIG. 5, the description of the process flow for establishing a bidirectional association relationship will be continued.
The AP2 that received the Asoc Req in (S11) receives an association request from the STA1 and can know that the wireless terminal 1 having the STA1 has the AP1 at the same time. As a result, the AP2 transmits an Association Response (Asoc Rsp), which is an example of a Management frame, to the STA1 in order to complete the association with the STA1 (S13). In addition, the AP2 transmits new information of the AP1 for the STA2 to associate with the AP1 via the Abstraction functional block (S12). The Abstraction functional block manages the MAC addresses of each MAC functional block by a table or the like, and is capable of appropriately notifying the STA2 of the information received from the AP2. In addition, a functional block that implements the Station Management Entity (SME) may be provided separately and used to notify the information. Here, the SME is a management unit that is connected to all the MAC functional blocks and can transmit commands and information such as association start to each MAC functional block.

As described above, there are many methods for the AP 2 to notify the STA 2 of information, and the present embodiment is not limited to a specific method. Also, the order of (S12) and (S13) may be reversed.
The Asoc Rsp notifies the STA of capability information, status code, AID assigned by the AP to the STA, and other information as required (e.g., supported rates and BSS membership selectors, EDCA parameter set, etc.).

STA1 processes the received Asoc Rsp, and if the value of the Status Code is 0, i.e., Success, an association relationship is established between AP2 and STA1. Once the association relationship is established, data frames can be exchanged between AP2 and STA1.

On the other hand, STA2, which has been notified of the information of AP1, creates and transmits an Asoc Req to AP1 based on that information (S14).
The AP1 processes the received Asoc Req and transmits the Asoc Req to the STA2 (S15).
STA2 processes the received Asoc Rsp, thereby completing the association between AP1 and STA2.

The Asoc Req that the wireless terminal 1 first transmits acts as a trigger to establish multiple association relationships (an association relationship between AP2 and STA1 and an association relationship between AP1 and STA2), which provides the following advantages.
First, wireless terminal 2 can know that AP1 and STA1 are included in wireless terminal 1 (co-located). Conventionally, there is a method in which an AP notifies the existence of another AP using a neighbor report, but it does not notify whether it is co-located. Naturally, an AP cannot notify information of a STA co-located with the AP, and conversely, a STA cannot notify information of an AP co-located with the STA.

In addition, channel scanning can be made more efficient. Conventionally, in order to build a mutual association relationship, STA1 and STA2 would each independently detect the communication channels of AP2 and AP1 and start the association process (co-located relationships cannot be recognized). On the other hand, in this embodiment, if one side can detect a communication channel, a frame to start the association is transmitted, which triggers the completion of both associations, making association more efficient. In particular, when the PHY function block is common, there is no need to switch channels between the AP and STA every time. Also, even when there are multiple PHY function blocks, the time required for channel detection is reduced, and there is no need to take into account how to deal with cases when the channels of the AP and STA of the same wireless terminal overlap.

In addition, by associating with each other, wireless terminals that make up the mesh network can act as APs for each other. This makes it possible to perform multi-user communication in a variety of situations, such as routing, route diversity, and network monitoring, and is expected to improve the time efficiency of information transmission.

If a frame is transmitted by uplink MU communication, the STA is the MAC functional block that should process the frame, and if a frame is transmitted by downlink MU communication, the AP is the MAC functional block that should process the frame. The Abstraction functional block determines which MAC functional block to allocate data input from such higher-level functional blocks to. The Abstraction functional block uses a table or the like to manage the MAC addresses of each MAC functional block, and can allocate data from higher-level functional blocks to MAC functional blocks by establishing some kind of rule or policy regarding allocation.

As described above, the electronic device of this embodiment can build a bidirectional association relationship with the same external device while recognizing that the two devices are connected to each other.
Second Embodiment
Next, a second embodiment will be described.
This embodiment is basically based on the first embodiment, so only the differences will be described here.

8A and 8B are diagrams showing an example of a process flow relating to the establishment of a bidirectional association relationship in the electronic device (wireless terminal 1 and wireless terminal 2) of this embodiment, respectively.
The difference between the present embodiment and the first embodiment is that, whereas in the first embodiment, the Asoc Rsp from the AP2 to the STA1 and the Asoc Req from the STA2 to the AP1 are transmitted separately, the Asoc Req and the Asoc Rsp are combined into the same physical packet (physical frame). FIG. 8A shows an example in which the AP2 aggregates the Asoc Rsp and the Asoc Req and transmits them to the wireless terminal 1 using either unicast or multiplexing. On the other hand, FIG. 8B shows an example in which the STA2 aggregates the Asoc Rsp and the Asoc Req and transmits them to the wireless terminal 1 using either unicast or multiplexing. A process flow for constructing a bidirectional association relationship in this embodiment will be described with reference to FIGS. 8A and 8B. Note that, as in the first embodiment, a case in which the process is started from the wireless terminal 1 will be considered.

In this embodiment, the process flow for establishing a bidirectional association relationship also starts when STA1, which knows the existence and information of AP2 from a Beacon or Probe Response transmitted from wireless terminal 2, prerequisites, etc., transmits an Asoc Req to AP2 (S21).

AP2, which has received the Asoc Req from STA1, can learn from the information about AP1 contained in the Asoc Req that the wireless terminal 1 that has STA1 also has AP1. AP2 creates an Asoc Rsp to complete the association with STA1. Furthermore, AP2 transmits the acquired information about AP1 so that STA2 can start the association process with AP1 (S22).

As in the first embodiment, if the wireless terminal 2 does not have multiple MAC functional blocks or if the Element ID cannot be recognized, association with the AP 1 is not performed and is ignored, and the process ends.
Frame multiplexing techniques include frame aggregation, frequency multiplexing, in which frames are transmitted using different frequency bandwidths, spatial division multiplexing, in which frames are transmitted using multiple antennas, code multiplexing, in which frames are transmitted using different codes, and orthogonal frequency multiplexing, in which frames are transmitted using different subcarriers even within the same frequency bandwidth.
In addition, in the current step (S22) of the processing flow, since the association is not completed, there may be information necessary for multiplexing but not shared. For example, in the IEEE802.11ax standard, when frequency multiplexing or spatial multiplexing is used to multiplex and transmit Asoc Rsp to STA1 and Asoc Req to AP1, a form of downlink (DL) multiplexing is adopted. In this case, AID information is required to indicate the destination of each resource unit or each stream to HE-SIG-B included in the PHY header, but the AID information is information shared by association. Therefore, if there is missing information, it is considered to assign a temporary value by the frame delivered in the previous step (S21).

For example, to assign a temporary AID value to achieve multiplexing during the association process, a new element called Temporary AIDs for Association Interval is created. In order to use this element to identify a frame in which an Asoc Rsp to STA1 and an Asoc Req to AP1 are multiplexed, an AID to be temporarily assigned to each is specified by wireless terminal 1 on the STA1/AP1 side, and is included in the Asoc Req sent from STA1 to AP2. If this temporary AID is to be taken from the conventional AID range of 1 to 2007, it is desirable to select an AID excluding any AIDs that have already been assigned.

For example, suppose STA1 specifies in the Asoc Req Temporary AIDs for Association Interval element that 2001 will be used as STA1's temporary AID and 2002 will be used as AP1's temporary AID. AP2 receives and decodes the Asoc Req, and if STA1 specifies AID 2001 and AP1 specifies AID 2002 in the HE-SIG-B field, it will understand that the transmitted multiplexed packet can be received and decoded on the wireless terminal side of STA1/AP1. For example, if we consider the orthogonal frequency division multiple access method as the multiplexing method, the Asoc Rsp addressed to STA1 can be transmitted, for example, on a certain subcarrier group 1 (also referred to as Resource Unit (RU) 1), and the Asoc Req addressed to AP1 can be transmitted on another subcarrier group 2 (also referred to as RU2). In the HE-SIG-B field of the PHY header of the multiplexed packet, it is notified that the PHY payload (i.e., MAC frame) addressed to AID=2001 uses subcarrier group 1, and the PHY payload addressed to AID=2002 uses subcarrier group 2. Then, STA1 or AP1 can receive the PHY packet and decode the desired PHY payload.

When the AID used in HE-SIG-B is limited to a value range of 1 to 2007, 11 bits are sufficient, so each AID specified in Temporary AIDs for Association Interval element can also be expressed in up to 11 bits. For example, an AP/STA Indication subfield can be provided to identify whether the temporary AID is for an AP or a STA, with a value of 1 indicating that it is for an AP and a value of 0 indicating that it is for a STA, followed by a subfield into which the temporary AID is written. In that case, it would look, for example, as shown in Figure 9.

This can only be applied when allocating two temporary AIDs, but this restriction can be removed by making the Temporary AIDs for Association Interval field (c4B) variable length. Also, this representation method does not explicitly represent that STA1 has AID=2001 and AP1 has AID=2002, so AP2 must associate AID=2001 for the STA with STA1 and AID=2002 for the AP with AP1, in addition to the MAC Address of Co-located AP element mentioned above. On the other hand, it is also possible to notify the MAC address of STA1 and its temporary AID, and the MAC address of AP1 and its temporary AID. In this case, the MAC Address of Co-located AP element mentioned above is not necessary because it has been notified by the element. Here, in IEEE 802.11ax, a value called BSS_COLOR is entered into the DL MU PHY packet to identify the BSS. When AP2 multiplexes and transmits the Asoc Rsp from AP2 to STA1 and the Asoc Rsp from STA2 to AP1, for example, the BSS_COLOR of this multiplexed PHY packet can be set to the BSS_COLOR used by AP2.

This provides the information necessary to configure HE-SIG-B, making frequency multiplexing, spatial multiplexing, and other techniques available. In this way, even before association is complete, various multiplexing techniques can be used by assigning temporary values.

Returning to FIG. 8A and FIG. 8B, the description of the process flow for establishing a bidirectional association relationship will be continued.
When AP2 performs aggregation (FIG. 8A), STA2, which has been notified of the information of AP1, uses that information to notify AP2 of information necessary for generating an Asoc Req, or sends an Asoc Req addressed to AP1 to AP2 (S23).

The information required to generate an Asoc Req can be, for example, the parameters of the MLME-ASSOCIATE.request primitive input from the SME to the MLME (MAC sublayer management entity) in the IEEE 802.11 wireless LAN standard. Here, when AP2 receives information for an Asoc Req, it creates an Asoc Req addressed to AP1 from STA2 on its behalf. As a result, AP2 can aggregate the Asoc Req and Asoc Rsp together with the Asoc Rsp it created itself.

On the other hand, when STA2 performs aggregation (FIG. 8B), in addition to the information notification from AP1, AP2 passes to STA2 information required for generating the Asoc Rsp or the Asoc Rsp to be sent to STA1 (S23'). Similarly, STA2 can aggregate the Asoc Req and Asoc Rsp together with the Asoc Req it created.

After aggregating the Asoc Rsp and Asoc Req, the AP 2 or the STA 2 transmits them to the wireless terminal 1 by using either unicast or multiplexing, as described above (FIG. 8A: (S24), FIG. 8B: (S24')).
Here, an example of transmission using frame aggregation will be described. When A-MPDU (Aggregate MAC Protocol Data Unit) is configured by aggregating Asoc Rsp and Asoc Req frames and transmitting, the MAC address of STA1 is entered as the destination address (Receiver Address: RA) in the first Address 1 field of the MAC header of the Asoc Rsp, the MAC address of AP2 is entered as the source address (Transmitter Address: TA) in the next Address 2 field, and the MAC address of AP2 is entered as the BSSID in the Address 3 field. The MAC address of AP1 is entered as the RA in the Address 1 field of the MAC header of the Asoc Req, the MAC address of STA2 is entered as the TA in the Address 2 field, and the MAC address of AP1 is entered as the BSSID in the Address 3 field. In this case, since the RA of the first Asoc Rsp is specified as STA1, STA1 will receive and decode this A-MPDU.

Conversely, when STA2 transmits A-MPDU, it is preferable to put the Asoc Req at the beginning and the Asoc Rsp after it. By doing this, the RA of the first Asoc Req is specified as AP1, so AP2 will receive and decode this A-MPDU.

Figure 10 shows an example where frames are aggregated in the order Asoc Rsp, Asoc Req. Asoc Rsp and Asoc Req are connected as MPDU (d1) so that the boundary can be determined by the MPDU delimiter (DLM) (d11). The MPDU delimiter has a length of 4 octets and is composed of the MPDU length, 8-bit CRC, and a Delimiter Signature that indicates that it is an MPDU delimiter.

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, but this can be achieved by utilizing the characteristics that "Asoc Rsp is a frame that should be processed by the STA" and "Asoc Req is a frame that should be processed by the AP", or, as mentioned above, by including correct information for the intended destination terminal (STA or AP) in the element, the frames do not necessarily have to be aggregated as in the previous example. For example, even if AP1 receives an Asoc Rsp and AP1 is specified in the RA, it is usually the STA, not the AP, that processes the Asoc Rsp, and since it is known that the same wireless terminal contains both the AP and the STA, AP1 can pass the Asoc Rsp to STA1 even if the TA is AP1.

In addition, if a new Receiver Address of This Association Frame element is created and the original MAC address, i.e., the MAC functional block, that receives the association frame that stores this element is specified in its Information field, and stored in the frame body of the association frame whose destination would normally change midway (if the Asoc Req comes after the Asoc Rsp, then it is the Asoc Req), then even if AP1 is specified in the RA of the MAC header of the Asoc Req, when processing the MAC frame, the MAC functional block of AP1 can pass the Asoc Rsp, or information extracted from within the Asoc Rsp frame, to the MAC functional block of STA1, and perform processing similar to that when the Asoc Rsp is received by the MAC functional block of STA1, and it can be determined that the association process with AP2 has ended (including the fact that the AID assigned by the AID field will be used with AP2 in the future if the Status Code in the Asoc Rsp is 0 (SUCCESS)).

Returning to FIG. 8A and FIG. 8B, the description of the process flow for establishing a bidirectional association relationship will be continued.
A frame transmitted by AP2 or STA2 may be received correctly by both STA1 and AP1, or may be received by a different MAC functional block than the original, such as AP1 receiving Asoc Rsp and STA1 receiving Asoc Req. In the latter case, AP1 and STA1 cannot process the received frame, so they transfer it to another MAC functional block via an Abstraction functional block or the like (FIG. 8A: (S25), FIG. 8B: (S25')).

At this time, the frame may be transferred to another MAC functional block in the form of a MAC protocol data unit (MPDU), may be transferred to another MAC functional block in the form of a MAC service data unit (MSDU), or may be transferred to another MAC functional block at a specific information level. When transferring to another MAC functional block in the form of an MPDU, the frame may be input via an I/F with the PHY of the other MAC functional block. This is considered to be a rule, and in this embodiment, the method is not limited as long as the desired information is accurately notified to the other MAC functional block.

If the frame cannot be processed by any of the MAC functional blocks, the frame is discarded.
STA1 processes the received Asoc Rsp, thereby completing the association between AP2 and STA1. Also, STA2 processes the received Asoc Rsp, thereby completing the association between AP1 and STA2.

As described above, in the electronic device of this embodiment, in addition to the first embodiment, frames are aggregated, multiplexed, and transmitted, so that the efficiency is improved.
Third Embodiment
Next, a third embodiment will be described.
This embodiment is basically based on the second embodiment, so only the differences will be described here.

11A and 11B are diagrams showing an example of a process flow relating to the establishment of a bidirectional association relationship in the electronic device (wireless terminal 1 and wireless terminal 2) of this embodiment, respectively.
The present embodiment differs from the second embodiment in that, whereas in the second embodiment, the process flow for performing association is started by the Asoc Req transmitted from STA1 as a trigger, this Asoc Req is omitted in this embodiment. Therefore, in this embodiment, the wireless terminal 1 performs an operation similar to that of the wireless terminal 2 in the second embodiment, and the wireless terminal 2 performs an operation similar to that of the wireless terminal 1 in the second embodiment.

In this embodiment, it is assumed that AP1 is aware of the existence and information of STA2, and even if it has not received an Asoc Req from STA2, wireless terminal 1 transmits an Asoc Rsp with STA2 as the destination. In other words, (S21) shown in Figures 8A and 8B in the second embodiment is omitted.

Here, the means for making the existence and information of STA2 known may be a beacon or a probe response, or may be determined by preconditions. When notifying information by a beacon or a probe response, vendor specific information is used, or a completely new element is added. This makes it possible to notify information about other STAs or APs present in the wireless terminal. When making information about the presence or absence of an AP/STA present in the wireless terminal known by preconditions, for example, a method of defining rules such as that a wireless terminal added to a network must have two MAC function blocks, that the MAC addresses of each differ by one, and that the MAC address of the AP is smaller (closer to 0). In this case, the MAC address of the AP of a 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 a beacon, etc. For example, if the precondition is that there is at least one more MAC function block as a STA, the MAC address of the MAC function block of the other STA can be understood to be the MAC address of the AP with the end of the MAC address moved up by one.

Wireless terminal 1 transmits Asoc Req and Asoc Rsp to wireless terminal 2. Figures 11A and 11B show an example in which these association frames are aggregated and transmitted by STA1 (Figure 11A) or AP1 (Figure 11B). Note that, as in the first embodiment, AP1 may transmit Asoc Rsp and STA1 may transmit Asoc Req.

When the STAs perform aggregation and transmission (FIG. 11A), AP1 transmits the Asoc Rsp frame or information required for generation to STA1 (S31). On the other hand, when AP1 performs aggregation and transmission (FIG. 11B), STA1 transmits the Asoc Req frame or information required for generation to AP1 (S31').

Thereafter, the wireless terminals 1 and 2 are reversed from the second embodiment, and the flow proceeds in the same manner (S32 [S32'], S33 [S33']).
Finally, AP2 transmits the Asoc Rsp to STA1, and an association relationship is established (S34 [S34']). Here, information (flag) indicating the establishment result of 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, and the same value is assigned as in the normal Status Code field, and the contents of the Status Code of the Asoc Rsp received from AP1 to STA2 are copied and inserted. For example, if the Status Code of the Asoc Rsp from AP1 to STA2 is 0, which indicates Success, the same value is inserted into the Status Code of The Other Association element and included in the Asoc Rsp from AP2 to STA1. In the method using this element, in the case of 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, the AP 1 can determine that the Asoc Rsp transmitted from the AP 1 to the STA 2 has been correctly received by the STA 2 and that an association relationship has been established between the AP 1 and the STA 2. In this way, the wireless terminal 1 can determine that an association relationship with the wireless terminal 2 has been established based on the transmission of the Asoc Rsp.

Alternatively, STA2 may know that the Asoc Rsp transmitted from AP1 to STA2 has been successfully received by AP1 by transmitting an Ack or BlockAck in response to the Asoc Req+Asoc Rsp (where + means aggregation or multiplexing) transmitted from AP1 to STA2. In normal operation, for a management frame that specifies a unicast MAC address as RA, the receiving side transmits an Ack frame after the SIFS (Short Interframe Space) of the management frame. SIFS is the minimum frame interval required when switching between transmission and reception. For example, in the case of an IEEE 802.11 wireless LAN used with a 20 MHz channel interval in the 5 GHz band, the value is 16 us. In the figures showing the frame exchange so far (Figures 5, 8A, and 8B), the transmission of the Ack frame or the BlockAck frame described below after this SIFS is omitted. The management frames Asoc Req and Asoc Rsp are transmitted with a fixed time longer than this SIFS and a random backoff period. Therefore, an Ack frame is also transmitted for frames transmitted in the form of Asoc Req + Asoc Rsp. In this case, in the example of FIG. 11A, the Ack frame is transmitted from AP2 to STA1, so STA1 needs to notify AP1 that the Asoc Rsp from AP1 to STA2 was correctly received by STA2 (since Ack is received SIFS after the transmission of Asoc Req + Asoc Rsp, a notification from STA1 to AP1 occurs at that time instead of (S35)).

In addition, in a form in which two frames, Asoc Req and Asoc Rsp, are aggregated, an Ack frame should be sent for each MAC frame, so a response may be made in a form that applies the Multi-STA BlockAck of IEEE 802.11ax. For example, this BlockAck frame may be as shown in FIG. 12. The BA Type subfield of the BA Control field (e1) may define a new BlockAck variant, but here we will explain the case where the Multi-STA BlockAck of IEEE 802.11ax is used. In the Multi-STA BlockAck, the value of the BA Type subfield is 11. The BA Information field (e2) is in units of Per AID TID Info subfields, but the first Per AID TID Info subfield (e21) notifies Ack to STA1, and the second Per AID TID Info subfield (e22) notifies Ack to AP1, and each RA field contains the MAC address of each. For the Multi-STA BlockAck as a whole, RA is put into the address field at the beginning of the MAC header, and this RA contains a broadcast address. Therefore, since the Multi-STA BlockAck is received by AP1 and STA1 respectively and a delivery confirmation is obtained, there is no need for notification from STA1 to AP1 as in the case of element and Ack (no notification from STA1 to AP1 as in (S35) is not required). Each AID TID Info subfield is further divided into AID11, Ack Type, and TID subfields, and these are commonly set to 2045 for AID11, 0 for Ack Type, and 15 for TID, regardless of whether it is addressed to STA1 or AP1. This is the same as the method of sending an Ack response in the form of a Multi-STA BlockAck to a management frame sent by each unconnected STA in UORA, which will be described later. By transmitting such a Multi-STA BlockAck, STA1 can determine that the Asoc Req sent from STA1 to AP2 has been received by AP2 because its own MAC address is written in the RA subfield of the Per AID TID Info subfield. Also, because its own MAC address is written in the RA subfield of the Per AID TID Info subfield, AP1 can determine that the Asoc Rsq sent from AP1 to STA2 has been received by STA2, and can determine that the association process with STA2 has ended. Note that if any of the Per AID TID Info subfields is missing, this means that the frame was not received by the wireless terminal 2. Therefore, the frame will be retransmitted as appropriate.

Conversely, if wireless terminal 1 is unable to confirm that an association relationship between AP1 and STA2 has been established, AP1 will need to resend the Asoc Rsp, but there are several procedures that can be applied to determine the process through which AP1 will resend the Asoc Rsp.

For example, if an ACK for (S32) [in the case of Figure 11A] is expected and used to determine whether to retransmit, STA1 notifies AP1 of the presence or absence of an ACK for the Asoc Rsp that is received a certain time later (SIFS time) after transmitting the frame in (S32). As a result, AP1 can also know whether there is an ACK for the Asoc Rsp, and if there is not, it will enter into the process of retransmitting the Asoc Rsp (strictly speaking, it will acquire a transmission opportunity based on CSMA/CA and transmit. The same applies below).

Also, if an ACK for (S32') [in the case of Figure 11B] is expected and is used to determine whether to retransmit, AP1 will receive this ACK, and so if there is no ACK after a certain period of time (SIFS time) after the frame is sent in (S32'), the Asoc Rsp retransmission process will begin.

Alternatively, if a Multi-STA BlockAck is expected for (S32) or (S32') and is used to determine whether to retransmit, this Multi-STA BlockAck can be received by both AP1 and STA1. Therefore, if AP1 does not receive the Multi-STA BlockAck itself a certain time (SIFS time) after transmitting the frame in (S32) or (S32'), or if the MAC address of AP1 cannot be detected in the RA subfield of the Per AID TID Info subfield of the Multi-STA BlockAck, AP1 will enter the process of retransmitting the Asoc Rsp.

Alternatively, if notification is given in the Asoc Rsp in (S34) [in the case of FIG. 11A], AP1 receives notification from STA1 of the contents indicated in the Asoc Rsp in (S34) (Status Code of The Other Association element or ACK bit) (rather than receiving the presence or absence of ACK for the Asoc Rsp sent in (S32)). As a result, if it is determined that an association has not been established between AP1 and STA2, AP1 begins the process of retransmitting the Asoc Rsp.

In this embodiment, regarding the fact that the Asoc Rsp from AP1 to STA2 is sent without the Asoc Req, if STA2 cannot accept the Asoc Rsp, for example because STA2 has already established an association relationship with another AP, it is important to explicitly inform AP1 of this. This is to prevent AP1 from repeatedly sending the Asoc Rsp to STA2 with which it cannot associate.

Next, we will discuss a method that uses the Status Code of The Other Association element explained above, and does not copy the Status Code of the Asoc Rsp from 0 (success) but rewrites it to any other appropriate Status Code that means failure, using the Disassociation frame (DisAsoc).

By using DisAsoc, the STA can notify the AP with which it has established an association relationship of the termination of the relationship. DisAsoc is designed to include a Reason Code field in the frame body. By notifying the reason for the withdrawal of the association relationship using the Reason Code field, it helps the AP 1 that received the DisAsoc to make an appropriate decision thereafter. For example, the Reason Code has a value of 12, BSS_TRANSITION_DISASSOC, which indicates the reason that the STA wants to move to another AP. In this way, it is possible to notify the AP with which it currently has an association relationship of the termination of the relationship together with the reason. In addition to using the value defined in the existing reason code, when notifying the specific reason for the STA's rejection in this embodiment, a new definition may be made for the reserved reason code 0, 67-65 535. For example, if STA2 is already associated with another AP and therefore cannot establish an association with AP1, by defining a new reason code for STA_ASSOCIATED, for example 67, it can notify AP1 of this by sending a DisAsoc frame with reason code 67.

As described above, in the electronic device of this embodiment, the 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.
This embodiment is basically based on the third embodiment, so only the differences will be described here.

13A and 13B are diagrams showing an example of a process flow relating to the establishment of a bidirectional association relationship in the electronic device (wireless terminal 1 and wireless terminal 2) of this embodiment, respectively.
The present embodiment differs from the third embodiment in that in the third embodiment, processing is started using the Asoc Req and Asoc Rsp from the wireless terminal 1 as a trigger, and either one of these is transmitted.

In other words, in this embodiment, one of the Asoc Req and Asoc Rsp sent in (S32) [Fig. 11A] or S32' [Fig. 11B] in the third embodiment described above is not sent. If one of them is not sent, it is clear that the information that should be notified will be missing. Conversely, if this missing information can be shared with each other, it is possible to establish an association relationship without sending one of them.

An example of missing information would be the MAC address of STA1 if Asoc Req is not sent, while in the case of Asoc Rsp, the AID assigned to STA2 would be considered. As for how to share this information without sending either Asoc Req or Asoc Rsp, for example, this information may be made common information depending on preconditions, or this information may be shared in advance using Beacon or Probe Response.

In addition, the information in the association frame of the non-transmitting device may be made common to the information in the association frame of the transmitting device or known information, or a rule may be established to make it possible to calculate the information from the information in the association frame of the transmitting device or known information. One example of information that can be made common to Asoc Rsp and Asoc Req is HT Capability. In addition, if the MAC addresses of AP1 and STA1 are agreed upon as consecutive numbers, the MAC address of STA1 can be calculated from the MAC address of AP1, and conversely, the MAC address of AP1 can also be calculated from the MAC address of STA1.

Furthermore, the information of the non-transmitting side may be added to the transmitting side association frame as a new element or a vendor specific element. In this way, the wireless terminal 1 can determine that a bidirectional association relationship (between AP1-STA2 and between AP2-STA1) has been established with the wireless terminal 2 based on the reception of an Asoc Rsp from the wireless terminal 2 in response to an Asoc Req (between AP2-STA1) transmitted to the wireless terminal 2, or can determine that a bidirectional association relationship (between AP1-STA2 and between AP2-STA1) has been established with the wireless terminal 2 based on the reception of an Asoc Rsp (between AP2-SPA1) from the wireless terminal 2 after transmitting an Asoc Rsp (between AP1-SPA2) to the wireless terminal 2. On the other hand, wireless terminal 2 can determine that a bidirectional association relationship (between AP1-STA2 and AP2-STA1) has been established with wireless terminal 1 based on the transmission of an Asoc Rsp to wireless terminal 1 in response to an Asoc Req (between AP2-STA1) received from wireless terminal 1, or can determine that a bidirectional association relationship (between AP1-STA2 and AP2-STA1) has been established with wireless terminal 1 based on the transmission of an Asoc Rsp (between AP2-STA1) to wireless terminal 1 after receiving an Asoc Rsp (between AP1-STA2) from wireless terminal 1.
As described above, in the electronic device of this embodiment, instead of transmitting Asoc Req and Asoc Rsp from the wireless terminal 1 in the third embodiment (FIG. 11A: (S32), FIG. 11B: (S32')), it is possible to transmit only Asoc Req (FIG. 13A: (S42)) or only Asoc Rsp (FIG. 13B: (S42')).

Fifth Embodiment
Next, a fifth embodiment will be described.
This embodiment is basically based on the first to fourth embodiments, and therefore only the differences therebetween will be described here.
FIG. 14 is a diagram showing an example of a process flow relating to the establishment of a bidirectional association relationship in the electronic device (wireless terminal 1 and wireless terminal 2) of this embodiment.

As shown in FIG. 14, in this embodiment, there are multiple wireless terminals 2 (wireless terminals 2-1, 2-2, ..., 2-N). Note that FIG. 14 shows an example in which there are multiple wireless terminals 2 in the second embodiment (FIG. 8A), but the method of this embodiment can be applied to all of the first to fourth embodiments described above.

First, the RA of the MAC frame sent from wireless terminal 1 is set to the broadcast address, and the association frame is broadcast to wireless terminals 2-1, 2-2, ..., 2-N (S51). When broadcasting, the information portions of the association frame addressed to each of the wireless terminals 2-1, 2-2, ..., 2-N may be multiplexed, or a new element may be provided in one frame that includes information for each of the wireless terminals 2-1, 2-2, ..., 2-N and the destinations of each of the wireless terminals 2-1, 2-2, ..., 2-N.

When wireless terminals 2-1, 2-2, ..., 2-N receive the association frame transmitted by broadcast, they will also receive information addressed to them, so they check the RA, extract the information addressed to them (or to all wireless terminals), and proceed with the subsequent processing (in the example of Figure 14, the process of returning Asoc Rsp in (S54)).

Frames from the wireless terminals 2-1, 2-2, ..., 2-N are transmitted to the wireless terminal 1 by MU communication. To achieve this, a temporary AID is defined or UORA (Uplink OFDMA-based Random Access) is used.
When defining a temporary AID, it is assumed that there is a frame transmitted from the AP to multiple STAs before MU communication is performed. Note that the frame does not necessarily have to be an association frame, and may be a beacon frame or a probe frame for distributing temporary AIDs.

Furthermore, when consolidating frames in a UL MU, the AP must transmit a trigger frame. A wireless terminal that has a frame to transmit to the AP transmits the frame a certain time after receiving the trigger frame (after a SIFS).
Here, UORA refers to UL OFDMA that can be realized without specifying a terminal as an RU. A STA with a frame to transmit determines whether to transmit to an RU with no AID specified in the same manner as CSMA/CA random access. If two or more terminals select the same RU and transmit, all transmissions will fail due to collision. If the AID of an RU is 2045, terminals with unassigned AIDs can be used. Terminals with unassigned AIDs can only transmit one management frame with an RU. The AP sets the AID to 2045 in a Multi-STA BlockAck frame, and enters the MAC address of the terminal that successfully received the frame in the area that normally displays the BlockAck bitmap, as a substitute for an ACK to the terminal that successfully received the frame. This allows the AP to transmit frames simultaneously from multiple STAs even before association.

As described above, the electronic device of this embodiment makes it possible to efficiently build two-way association relationships with a plurality of external devices.
According to the electronic devices of the several embodiments described above, a method for efficiently associating two electronic devices with each other enables two-way MU communication that cannot be achieved with a one-way relationship between the electronic devices, thereby improving the time efficiency of information transmission.

This also makes it easier to realize simultaneous transmission and reception requirements for routing, route diversity, network monitoring, and the like in mesh networks.
Although some embodiments of the present invention have been described, these embodiments are presented as examples and are not intended to limit the scope of the invention. These novel embodiments can be implemented in various other forms, and various omissions, substitutions, and modifications can be made without departing from the spirit of the invention. These embodiments and their modifications are included in the scope and spirit of the invention, and are included in the scope of the invention and its equivalents described in the claims.

1, 2... wireless terminal, 11... transceiver unit, 12... MAC function block, 13... host function block, 100... wireless communication system, 121... association frame generation unit.

Claims (7)

a transmitting means for transmitting a first association request frame to the first electronic device;
a receiving means for receiving a first association response frame from the first electronic device, the first association response frame corresponding to the first association request frame;
a control means for determining, based on reception of the first association response frame, 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 have been established;
Equipped with
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 can be established simultaneously;
Electronic device. 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;
2. The electronic device of claim 1. the first association request frame includes first information that identifies the electronic device as having a second station unit designated by a third MAC address and a second access point unit designated by a fourth MAC address different from the third MAC address;
The first association request frame is a frame in which the second station unit of the electronic device requests an association relationship.
2. The electronic device of claim 1. the first electronic device has the first station unit designated by a first MAC address and the first access point unit designated by a second MAC address different from the first MAC address;
2. The electronic device of claim 1. receiving means for receiving a first association request frame from the first electronic device;
a 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;
a control means for determining, based on the transmission of the first association response frame, 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 have been established;
Equipped with
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 can be established simultaneously;
Electronic device. the first association request frame includes first information that identifies that the first electronic device has the first station unit specified by a first MAC address and the first access point unit specified by a second MAC address different from the first MAC address;
the first association request frame is a frame in which the first station unit of the first electronic device requests an association relationship;
6. The electronic device of claim 5. a second station unit designated by a third MAC address, and a second access point unit designated by a fourth MAC address different from the third MAC address;
6. The electronic device of claim 5.

Images