WO2024075793A1 - アクセスポイント及び協調通信の制御方法 - Google Patents

アクセスポイント及び協調通信の制御方法 Download PDF

Info

Publication number
WO2024075793A1
WO2024075793A1 PCT/JP2023/036276 JP2023036276W WO2024075793A1 WO 2024075793 A1 WO2024075793 A1 WO 2024075793A1 JP 2023036276 W JP2023036276 W JP 2023036276W WO 2024075793 A1 WO2024075793 A1 WO 2024075793A1
Authority
WO
WIPO (PCT)
Prior art keywords
access point
coordinator
cooperative communication
information
cooperative
Prior art date
Application number
PCT/JP2023/036276
Other languages
English (en)
French (fr)
Inventor
浩幸 金谷
嘉夫 浦部
裕幸 本塚
Original Assignee
パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ filed Critical パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ
Publication of WO2024075793A1 publication Critical patent/WO2024075793A1/ja

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W16/00—Network planning, e.g. coverage or traffic planning tools; Network deployment, e.g. resource partitioning or cells structures
    • H04W16/24—Cell structures
    • H04W16/28—Cell structures using beam steering
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/16—Central resource management; Negotiation of resources or communication parameters, e.g. negotiating bandwidth or QoS [Quality of Service]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W84/00—Network topologies
    • H04W84/02—Hierarchically pre-organised networks, e.g. paging networks, cellular networks, WLAN [Wireless Local Area Network] or WLL [Wireless Local Loop]
    • H04W84/10—Small scale networks; Flat hierarchical networks
    • H04W84/12—WLAN [Wireless Local Area Networks]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W88/00—Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
    • H04W88/08—Access point devices
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W92/00—Interfaces specially adapted for wireless communication networks
    • H04W92/16—Interfaces between hierarchically similar devices
    • H04W92/20—Interfaces between hierarchically similar devices between access points

Definitions

  • This disclosure relates to a method for controlling access points and cooperative communication.
  • 802.11be The technical specifications for 802.11be (hereinafter referred to as “11be”) are currently being developed as the successor standard to 802.11ax (hereinafter referred to as “11ax”), the IEEE (Institute of Electrical and Electronics Engineers) 802.11 standard. 11ax is also known as High Efficiency (HE), and 11be is also known as Extreme High Throughput (EHT). Discussions are also underway regarding the required specifications for the successor standard to 11be (sometimes called UHR (Ultra High Reliability), hereinafter referred to as "beyond 11be”).
  • UHR Ultra High Reliability
  • IEEE 802.11-18/1982r0 Consideration on multi-AP Coordination for EHT IEEE 802.11-19/0103r1, AP Coordination in EHT IEEE Std 802.11-2020, December 2020
  • control method of Multi-AP (Access Point) Coordination such as the method of selecting cooperative communication, the method of starting cooperative communication, or the operation when direct transmission and reception between APs is not possible, has not been fully considered.
  • Non-limiting examples of the present disclosure contribute to providing a method for controlling access points and cooperative communication.
  • An access point has a transceiver unit that receives information related to cooperative communication, and a control circuit that determines whether to operate as an access point that controls cooperative communication.
  • the present invention provides a method for controlling access points and cooperative communication.
  • a diagram showing the availability information of Coordinator AP and Coordinated AP, and the combination of Coordinator selection results A diagram showing an example of the format for transmitting a collaboration bitmap via a Multi-AP element
  • Diagram showing an example of the format of the Multi-AP Capabilities Information field A diagram showing an example of a Multi-AP Setup Request defined in the Multi-AP element.
  • FIG. 13 is a flowchart showing an example of an operation using backhaul communication. Diagram showing different overall steps Diagram showing an example of AP and STA placement A diagram showing an example of a cooperative start request defined in the Multi-AP element A diagram showing another example of AP and STA placement. A diagram showing yet another example of the placement of APs and STAs.
  • a diagram showing a collaborative bitmap A diagram showing a coordination bitmap with bits indicating whether each Coordinator AP is available, whether each Coordinated AP is available, and whether each coordination method is available. A diagram showing a coordination bitmap in which bits indicating the availability of each coordination method are provided for each "Coordinator AP availability" and "Coordinated AP availability.” A diagram showing a coordination bitmap with bits indicating whether or not a Coordinator AP is available and whether or not a Coordinated AP is available for each coordination method.
  • AP STAs base stations
  • STAs non-AP STAs
  • an AP that controls cooperative communication also called Coordinator AP, Primary AP, Controller AP, or Master AP; hereinafter referred to as "Coordinator AP”
  • Coordinator AP controls an AP that is controlled by cooperative communication
  • Coordinated AP also called Coordinated AP, Secondary AP, Agent AP, or Slave AP; hereinafter referred to as "Coordinated AP”
  • Coordinated AP also called Coordinated AP, Secondary AP, Agent AP, or Slave AP
  • each AP determines whether or not to operate as a Coordinator AP and performs Multi-AP cooperative communication.
  • [STA configuration] 3 is a diagram showing the configuration of an STA.
  • the STA includes a transmission packet generator 301, a control signal generator 302, a wireless transmission/reception unit 303, a reception packet decoder 304, and a reception quality measurement unit 305.
  • At least one of the transmission packet generator 301, the control signal generator 302, the reception packet decoder 304, and the reception quality measurement unit 305 may constitute a control circuit 306.
  • a packet may be called a physical layer (PHY) protocol data unit (PPDU).
  • PPDU physical layer protocol data unit
  • the packet and/or PPDU may be a signal obtained by encoding and modulating a medium access control (MAC) frame (MPDU: MAC protocol data unit).
  • MAC medium access control
  • the transmission packet generator 301 generates a transmission packet based on the input data and the control signal generated by the control signal generator 302, and outputs the packet to the wireless transmitter/receiver 303.
  • the input data may be called a medium access control (MAC) service data unit (MSDU) or upper layer data.
  • MAC medium access control
  • MSDU service data unit
  • the control signal generating unit 302 generates a control signal based on the input data, the control information output from the received packet decoding unit 304, the reception quality measured by the reception quality measuring unit 305, and the internal state, and outputs the control signal to the transmission packet generating unit 301.
  • the wireless transceiver 303 converts the transmission packets generated by the transmission packet generator 301 into wireless signals and outputs them to the antenna.
  • the wireless transceiver 303 also receives wireless signals from the antenna and outputs the received signals to the received packet decoder 304 and the reception quality measurement unit 305.
  • the received packet decoding unit 304 outputs output data obtained by decoding the received signal from the wireless transceiver unit 303, and also outputs control information to the reception quality measurement unit 305 and the control signal generation unit 302.
  • the reception quality measurement unit 305 measures the reception quality based on the received signal received from the wireless transceiver unit 303, the control information received from the received packet decoding unit 304, and the internal state.
  • FIG. 4 is a diagram showing the configuration of an AP.
  • the AP includes a transmission packet generator 401, a control signal generator 402, a wireless transceiver 403, a received packet decoder 404, a reception quality measurement unit 405, and a cooperative control unit 406.
  • the cooperative control unit 406 may be added to the configuration of the STA shown in Fig. 3. At least one of the transmission packet generator 401, the control signal generator 402, the received packet decoder 404, the reception quality measurement unit 405, and the cooperative control unit 406 may constitute a control circuit 407.
  • the transmission packet generator 401, the control signal generator 402, the wireless transceiver 403, the received packet decoder 404, and the reception quality measurement unit 405 may have the same functions as the transmission packet generator 301, the control signal generator 302, the wireless transceiver 303, the received packet decoder 304, and the reception quality measurement unit 305.
  • the cooperative control unit 406 generates cooperative control information for performing cooperative communication based on the input data, the control information output by the received packet decoding unit 404, the reception quality measured by the reception quality measurement unit 405, and the internal state, and outputs the information to the control signal generation unit 402.
  • Example 1 As an example, the case where AP2 is newly installed, started, and/or restarted while AP1 is installed in a state where it periodically transmits a beacon will be described below.
  • the overall steps are shown in Fig. 5.
  • each AP performs Multi-AP measurement S502 and Multi-AP transmission S503.
  • the AP negotiates with neighboring APs to determine whether the AP will act as a Coordinator AP or a Coordinated AP.
  • the AP and STA measure the amount of interference and transmit the measurement results to each other.
  • the Coordinator AP may specify the measurement target. Measurement may be performed periodically, or may be performed, for example, when the path loss changes. If the operating coordination method is, for example, C-TDMA or C-OFDMA, control based on the amount of interference is not required, so Multi-AP measurement does not need to be performed. This eliminates the need for interference measurement by the STA, making it possible to reduce the power consumption of the STA. Also, since it is no longer necessary to transmit the interference measurement results, it is possible to prevent a decrease in throughput.
  • the Sharing AP i.e., the AP that has acquired the Transmission Opportunity (TXOP)
  • TXOP Transmission Opportunity
  • Cooperative communication may be performed only when the Coordinator AP is the sharing AP.
  • cooperative communication may be performed by specification of the Coordinator AP (e.g., a trigger).
  • an AP acquires a TXOP and performs cooperative communication in Multi-AP Transmission S503, but for example, a service period for cooperative communication may be set in Multi-AP Setup S501, and cooperative communication (for example, AP1 and AP2 transmit in their individual service periods) may be performed in Multi-AP Transmission S503 based on the set service period.
  • the service period setting may be, for example, a TWT (Target Wake Time) setting that includes setting information for cooperative communication.
  • each AP may also transmit and receive with each STA that is individually associated with it in addition to cooperative communication.
  • Figure 6 shows an example of an operation sequence in which AP2 negotiates with AP1 in the Multi-AP setup S501 to determine whether or not to act as a coordinator AP.
  • the Beacon may include capability information for the Coordinator AP and Coordinated AP (hereinafter referred to as the "coordination bitmap").
  • the coordination bitmap may be composed of a "bit indicating whether or not the Coordinator AP is available" and a "bit indicating whether or not the Coordinated AP is available", as shown in Figure 20.
  • the order of the bits may be reversed. For example, bit 1 may indicate “available” and bit 0 may indicate “no”, or bit 1 may indicate "no” and bit 0 may indicate "available”.
  • AP2 may search for neighboring APs (also called discovery or scanning) when it starts up.
  • AP2 may receive a Beacon periodically transmitted by AP1 and obtain capability information regarding cooperative communication (e.g., a cooperative bitmap) contained in the received Beacon. AP2 may also transmit a Probe Request, receive a Probe Response transmitted by AP1 in response to the Probe Request, and obtain capability information regarding cooperative communication from the Probe Response.
  • capability information regarding cooperative communication e.g., a cooperative bitmap
  • AP2 determines the Coordinator AP based on the received AP1 capability information regarding cooperative communication and information (internal information) equivalent to AP2's own capability information regarding cooperative communication. For example, the feasibility of cooperative communication and the Coordinator AP may be selected based on the received AP1 cooperation bitmap and internal information equivalent to AP2 cooperation bitmap.
  • AP2 may transmit a Multi-AP Setup Request to AP1 as a request to start cooperative communication (cooperative start request).
  • the Multi-AP Setup Request may include the result of the selection of the Coordinator AP.
  • AP1 may send a Multi-AP Setup Response to AP2 as a response to the collaboration start request (collaboration start response).
  • the Multi-AP Setup Response may include the result of the Coordinator AP selection.
  • AP1 may send an Ack (acknowledge) instead of the Multi-AP Setup Response.
  • Figure 7 shows an example of a combination of Coordinator AP availability information and Coordinated AP availability information for each AP, created based on internal information corresponding to AP1's coordination bitmap and AP2's coordination bitmap, and the results of Coordinator AP selection.
  • Coordination communication availability and Coordinator AP selection may be performed based on the combinations shown in Figure 7.
  • Figure 7 if both the Coordinator AP and Coordinated AP in the coordination bitmap are unavailable, cooperative communication is clearly not possible, so this is not shown.
  • the AP with the larger number of Coordinated APs or the larger number of associated STAs may be the Coordinator AP.
  • the AP may, for example, include at least one of the number of Coordinated APs and the number of associated STAs in the Multi-AP Setup Request it sends.
  • *2 both AP1 and AP2 can only be Coordinator AP
  • a cooperation method e.g., C-TDMA or dynamic AP selection
  • a cooperation method that does not require one to be the Coordinator AP and the other to be the Coordinator AP
  • both AP1 and AP2 may be Coordinator APs, or it is not necessary to select a Coordinator AP or a Coordinated AP.
  • *3 both AP1 and AP2 can only be Coordinator AP
  • both AP1 and AP2 are operational, a cooperative method is selected that does not require one to be a Coordinator AP and the other to be a Coordinated AP, and both AP1 and AP2 may be Coordinated APs, or a Coordinator AP and a Coordinated AP do not need to be selected.
  • the Coordinator AP in the coordination bitmap may be marked as Yes, or an item for the Coordinated AP that is already registered with the other Coordinator AP may be added to the coordination bitmap.
  • the AP can select a Coordinator AP based on the coordination bitmap notified from other APs and information equivalent to its own coordination bitmap, thereby performing Multi-AP measurement S502 and Multi-AP transmission S503 under the control of the Coordinator AP.
  • the coordination bitmap may include information on the coordination methods (e.g., C-TDMA, C-OFDMA, C-SR, CBF, JT, dynamic AP selection, etc.) that each AP can operate.
  • the coordination bitmap may be a coordination bitmap in which a bit indicating whether each coordination method is available for each AP is provided as shown in FIG. 21, or a coordination bitmap in which a bit indicating whether each coordination method is available for each "Coordinator AP available" and "Coordinated AP available” is provided as shown in FIG. 22, or a coordination bitmap in which a bit indicating whether "Coordinator AP available" and "Coordinated AP available” is provided as shown in FIG. 23.
  • the order of the coordination methods may be a different order or a specified order. Only some of the coordination methods may be included, or coordination methods other than those exemplified may be included. In this case, based on the information on the coordination methods included in the coordination bitmap, the coordination methods used in the cooperative communication may be limited to those that all APs can operate. In this case, for example, the Multi-AP Setup Request may notify the available cooperation methods. This allows the selection of a cooperation method according to the functions of the cooperating APs. Furthermore, when using the cooperation bitmap shown in Figures 22 and 23, in the case of *1 in Figure 7 (AP1 and AP2 are both Coordinator APs and Coordinated APs), the AP with the most available cooperation methods may be set as the Coordinator AP.
  • AP2 may establish a BSS (Basic Service Set) (also called starting the BSS) after the Multi-AP setup S501.
  • BSS Basic Service Set
  • AP2 can specify the same primary CH as AP1, which can easily be assigned to the same transmission frequency band required for cooperative communication.
  • C-OFDMA when operating with C-OFDMA, AP2 can specify a different primary CH from AP1, which can easily be assigned to a different transmission frequency band required for cooperative communication.
  • Each AP may have a Coordinated AP list, and the Coordinator AP may add to the Coordinated AP list the APs that it designated as Coordinated APs in the Multi-AP setup S501.
  • becoming a Coordinator AP and becoming a Coordinated AP may also be referred to as joining a Coordination Group (or Coordination set).
  • the Multi-AP Setup negotiation may be considered successful when AP1 successfully sends a Multi-AP Setup Response in response to the Multi-AP Setup Request sent by AP2, that is, when AP2 receives a Multi-AP Setup Response, or when AP1 receives an Ack for the Multi-AP Setup Response.
  • AP2 sends a Multi-AP Setup Request including a "Coordinator AP candidate or other candidates for Multi-AP related parameters", and AP1 may send a Multi-AP Setup Response including "whether or not you agree with the candidate", or may send a response including either "Agree (to the candidate), request a change, or reject”.
  • Multi-AP Setup Response indicating "agreement"
  • the Multi-AP Setup negotiation is deemed successful and the Coordinator AP/Coordinated AP is determined.
  • AP2 may send, for example, a Multi-AP Setup Response including whether or not it agrees to the change of Coordinator AP/Coordinated AP.
  • the Coordinator AP may add the AP with which it negotiated (i.e., the Coordinated AP) to the Coordinated AP list.
  • the Coordinator AP may assign a Coordination Group ID (or Coordination Set ID) to a Coordination Group (or Coordination set) as an identifier to identify the Coordination Group (or Coordination set).
  • the Coordination Group ID may be assigned during the exchange of a Multi AP Setup Request/Response or after negotiation through the exchange of a Request/Response.
  • the Coordination Group ID may be an ID uniquely identified by the combination of the Coordinator AP ID and the Coordination Group ID, that is, an ID unique for each Coordinator AP ID.
  • An AP may participate in multiple Coordination Groups.
  • the Coordinator AP may also manage the combination of the Coordination Group ID and the Coordinated AP list for one Coordination Group.
  • the Coordination Group ID may be notified to the Coordinated AP, or may be announced to other APs via a Beacon, etc.
  • a list compiling the IDs (e.g., BSS ID, Mac address, BSS color, etc.) of the APs included in the Coordinator AP and Coordinated AP lists may be used as a cooperative AP list, and may be notified to other APs and STAs via Beacons, etc.
  • An AP (e.g. AP3) that is not participating in an already established Coordination Group (e.g. a Coordination Group consisting of AP1 and AP2) may join the Coordination Group (e.g. a Coordination Group consisting of AP1 and AP2) by sending a Multi-AP Setup Request to an AP (e.g. AP1) that is a member of the Coordination Group and negotiating with that AP.
  • an AP e.g. AP1
  • AP1 e.g. AP1
  • AP3 may send a Multi-AP Setup Request to AP1 including the Coordination Group ID included in the Beacon.
  • AP3 may join the Coordination Group by receiving a Multi-AP Setup Response from AP1.
  • a Multi-AP Setup Request is used as the cooperative start request and a Multi-AP Setup Response is used as the cooperative start response, but instead of a Multi-AP Setup Request, AP2 may send a frame that does not require a response, such as an Announcement or Advertisement. In this case, AP1 may return an Ack frame instead of a Multi-AP Setup Response.
  • AP2 may also send the coordination start request (e.g., a Multi-AP Setup Request) by broadcast.
  • a coordination start request e.g., a Multi-AP Setup Request
  • broadcast e.g., a Multi-AP Setup Request
  • the Element format shown in FIG. 1 may be used to notify control information (e.g., a cooperation bitmap) related to Multi-AP.
  • control information e.g., a cooperation bitmap
  • the value of Element IDExtension is 111 as an example, but may be another value indicating that the element is a Multi-AP element.
  • the Multi-AP element may be included in, for example, information of a Management frame (e.g., a Beacon, a Probe Response, an Association Request, a Re-Association Request, an Association Response, or a Re-Association Response frame), a Multi-AP Setup Request frame, a Multi-AP Setup Response frame, or another Action frame newly defined in the 11be standard or a successor standard.
  • a Management frame e.g., a Beacon, a Probe Response, an Association Request, a Re-Association Request, an Association Response, or a Re-Association Response frame
  • a Multi-AP Setup Request frame e.g., a Multi-AP Setup Response frame
  • a Multi-AP Setup Response frame e.g., a Multi-AP Setup Response frame
  • another Action frame e.g., a Multi-AP Setup Response frame
  • the Multi-AP element may be named by another name (e.g., a Multi-AP Information element).
  • Figure 8 shows an example of transmitting a collaboration bitmap in a format using a Multi-AP element.
  • a Multi-AP Setup Request or Multi-AP Setup Response may use a different Type value of the Multi-AP element.
  • the contents may be changed depending on the method of transmitting the collaboration bitmap (including it in a Beacon, including it in a Multi-AP Setup Request, etc.).
  • an element that includes a field indicating information regarding whether or not the AP can operate as a Coordinator AP may be called a Multi-AP Status variant, Multi-AP Advertisement variant, Multi-AP Operation variant, Multi-AP Configuration variant, Multi-AP Setup Information variant, etc.
  • the collaborative bitmap field may be the collaborative bitmap shown in FIG. 20.
  • the numAP field may be the number of Coordinated APs in the Coordination Group that contains the AP.
  • the numSTA field may be the number of STAs associated with the AP in question, or the number of STAs associated with APs in the Coordination Group. If numAP and numSTA are the information used in the case of *1 in Figure 7, they may only be added if both the Coordinator AP and the Coordinated AP are available in the coordination bitmap. numAP or numSTA may be sent only if the receiving AP will use it.
  • information regarding whether or not a device can operate as a Coordinator AP may be included in an element (for example, a UHR Capabilities element) that contains capability information of a beyond 11be terminal (including APs, e.g., AP1, AP2).
  • an element for example, a UHR Capabilities element
  • capability information of a beyond 11be terminal including APs, e.g., AP1, AP2.
  • FIG. 8A An example format is shown in Figure 8A.
  • the Element ID field is set to a value (255) indicating that the element contains an Element ID Extension field.
  • the Length field contains information about the length of the element.
  • the Element ID Extension field contains a value (for example, 200) that indicates that the element is a UHR Capabilities element.
  • the UHR MAC Capabilities Information field contains information indicating whether the terminal supports optional functions of the MAC layer of beyond 11be, and contains multiple fields (not shown) corresponding to each optional function.
  • the UHR PHY Capabilities Information field contains information on whether the terminal supports optional functions of the PHY layer of beyond be, and contains multiple fields (not shown) corresponding to each optional function.
  • the Multi-AP Capabilities Information field contains information indicating whether the terminal (including the AP) supports optional functions related to Multi-AP cooperation.
  • the AP transmits the UHR Capabilities element with the Multi-AP Capabilities Information field as an optional field
  • the Multi-AP Capabilities Information field may be included in the UHR Capabilities element.
  • the STA transmits the UHR Capabilities element
  • the Multi-AP Capabilities Information field may not be included in the UHR Capabilities element.
  • Figure 8B shows an example of the format of the Multi-AP Capabilities Information field.
  • the Coordinator AP mode supported subfield indicates whether the AP can act as a Coordinator AP.
  • the Coordinated AP mode supported subfield indicates whether the AP can operate as a Coordinated AP.
  • the combination of the Coordinator AP mode supported and Coordinated AP mode supported subfields may be referred to as the coordination bitmap.
  • the Maximum number of Coordinated AP subfield contains information about the maximum number of Coordinated APs that can join when the AP acts as a Coordinator AP. Note that if the value of the Maximum number of Coordinated AP subfield is 0, this means that the AP does not support acting as a Coordinator AP, and the Coordinator AP mode supported subfield may be omitted.
  • the Supported coordination types subfield contains information about the coordination methods supported by the AP (C-TDMA, C-OFDMA, C-SR, CBF, JT, dynamic AP selection, etc.).
  • Multi-AP Setup Request and Multi-AP Setup Response may be defined as a type of Management frame.
  • a Multi-AP Action frame with Category "Multi-AP” may be defined as an Action frame
  • a Multi-AP Setup Request frame or a Multi-AP Setup Response frame may be defined as a subtype.
  • the Multi-AP Setup Request and Multi-AP Setup Response may be defined with different Type values of the Multi-AP element, and the contents may be changed depending on the application (whether to be included in a Beacon, to be included in a Setup Request, etc.).
  • part of the information of the coordination bitmap may be included in the frames of Figures 8 and 8A.
  • each bit of the coordination bitmap may be included in a different frame.
  • Figure 8 Multi-AP element
  • the availability information of the Coordinater AP may be included, and the availability information of the Coordinated AP may be omitted.
  • Figure 8A UHR Capabilities element
  • the availability information of the Coordinated AP may be included, and the availability information of the Coordinater AP may be omitted.
  • An example of a Multi-AP Setup Request in which the Type value of the Multi-AP element is specified as 1 is shown in Figure 9.
  • the Coordinator AP ID indicates the ID of the AP that will be the Coordinator AP.
  • the Coordinator AP ID may be the ID of AP3.
  • information (1 bit) indicating whether or not it is a Coordinator may be used.
  • Coordinate Type may indicate the coordination method (C-TDMA, C-OFDMA, C-SR, CBF, JT, dynamic AP selection, etc.).
  • the information may be control information for each cooperative method, or may include control information for multiple cooperative methods that can be operated.
  • the information included in the information may be, for example, the time slot or transmission start timing and transmission interval in the case of C-TDMA, the maximum interference power or path loss detection threshold (maximum or minimum value) in the case of C-SR, CBF, or JT, and the switching detection power threshold and the number of forward and backward protection times in the case of dynamic AP selection.
  • the Multi-AP Setup Request may include the ID of the Multi-AP Coordination Group, or the Coordinator AP ID may be the ID of the Multi-AP Coordination Group.
  • the Multi-AP Setup Request may include a Coordinated AP list.
  • Multi-AP Setup Request defined in the Multi-AP element is shown, but the fields below the Coordinator AP ID may be included in the Multi-AP Setup frame as fields other than elements.
  • the Multi-AP Setup Response may be in the format shown in Figure 9, or in a format including either "Agree to the candidate or not” or “Agree to the candidate/request change/reject.”
  • the format shown in Figure 9 may be used, and when AP1 becomes a Coordinated AP, the format may be selected, including either "Agree to the candidate or not” or "Agree to the candidate/request change/reject.”
  • the Coordinate Type included in the Multi-AP Setup Response may be a cooperative method in which both AP1 and AP2 can operate.
  • Example 2 In the first embodiment, an example was shown in which the Beacon or Probe Response in the Multi-AP setup S501 includes capability information related to the Multi-AP (e.g., a cooperation bitmap), whereas in the second embodiment, an example is shown in which the Multi-AP Setup Request in the Multi-AP setup S501 includes capability information related to the Multi-AP (e.g., a cooperation bitmap).
  • the Multi-AP Setup Request in the Multi-AP setup S501 includes capability information related to the Multi-AP (e.g., a cooperation bitmap).
  • Figure 10 shows another example of an operation sequence in which AP1 and AP2 negotiate to determine whether or not to act as a Coordinator AP in the Multi-AP setup S501.
  • AP2 may search for neighboring APs when it starts up.
  • AP2 receives a Beacon that is periodically transmitted by AP1.
  • AP2 may also transmit a Probe Request and receive a Probe Response that is transmitted by AP1 in response to the Probe Request.
  • AP2 may send a Multi-AP Setup Request to AP1.
  • AP2 may include a collaboration bitmap in the Multi-AP Setup Request that it sends.
  • the Multi-AP Setup Request frame may include a Multi-AP element (as an example, the frame format shown in FIG. 8).
  • AP1 which has received the Multi-AP Setup Request, selects a Coordinator AP.
  • the Coordinator AP may be selected based on internal information corresponding to the received collaboration bitmap of AP2 and the collaboration bitmap of AP1.
  • AP1 may send a Multi-AP Setup Response to AP2. Having received the Multi-AP Setup Request, AP1 may send a Multi-AP Setup Response to AP2 only when preparations for cooperative communication are complete.
  • the Multi-AP Setup Response frame may include a Multi-AP element (as an example, the frame format shown in FIG. 9).
  • a cooperative communication operation feasibility flag indicating whether cooperative communication is possible may be added to the Beacon or Probe Response sent by AP1.
  • AP2 can prevent the sending of an invalid Multi-AP Setup Request by sending a Multi-AP Setup Request only if the cooperative communication operation feasibility flag of AP1 is "yes.”
  • AP1 may transmit information indicating the operating status of the Multi-AP in a Beacon or Probe Response.
  • Figure 10A shows an example of the format of information indicating the Multi-AP operation status (Multi-AP Operation element).
  • the Group ID field contains the ID of the Multi-AP group (called the Multi-AP Group, Coordination Group, etc.). If AP1 has not performed Multi-AP setup with other APs, or has terminated Multi-AP operation, it may set the value of the Group ID field to a specific value (such as 0 or 255) that is not used as an ID, to notify other APs that Multi-AP operation has not started.
  • the Multi-AP Operation element may contain a field (not shown) indicating whether or not Multi-AP operation is in progress.
  • the Coordinator field includes information indicating whether or not AP1 is operating as a Coordinator AP. Note that if the Group ID field and/or other fields indicate that Multi-AP operation is not in progress, the Coordinator field may indicate whether or not AP1 can operate as a Coordinator AP. In other words, the meaning of the Coordinator field may change depending on whether or not Multi-AP operation is in progress.
  • the Coordinated AP list field contains a list of the IDs (BSSID, BSS color, MAC address, hash value of MAC address, etc.) of the APs participating in the Multi-AP coordination group indicated by the Group ID field.
  • the Connectivity bitmap field may include information indicating whether each AP shown in the Coordinated AP list field can communicate directly with the Coordinator AP via wireless media. Note that Coordinated APs that cannot communicate directly with the Coordinator AP via wireless media are expected to perform Multi-AP coordination by communicating with the Coordinator AP via a wired backhaul (Ethernet connection) or the like. Therefore, instead of the Connectivity bitmap field, each AP shown in the Coordinated AP list field may include information indicating whether it communicates with the Coordinator AP via wired media (e.g., a Wired Backhaul bitmap field).
  • the Coordinated AP list field and Connectivity bitmap field may be omitted.
  • the amount of information transmitted by the periodic beacon can be reduced compared to the first embodiment.
  • Example 3 In the first and second embodiments, an embodiment was shown in which a Coordinator AP is selected using a coordination bitmap in the Multi-AP setup S501. In the third embodiment, an embodiment is shown in which an AP notifies surrounding APs of whether or not it can operate as a Coordinator AP (hereinafter referred to as "Coordinator AP availability information") in the Multi-AP setup S501, and a Coordinator AP is selected.
  • a Coordinator AP is selected using a coordination bitmap in the Multi-AP setup S501.
  • Coordinator AP availability information hereinafter referred to as "Coordinator AP availability information"
  • Figure 11 shows yet another example of an operation sequence in which AP1 and AP2 negotiate to determine whether or not to act as a Coordinator AP in the Multi-AP setup S501.
  • AP2 may search for neighboring APs when it starts up.
  • AP2 receives a Beacon that AP1 periodically transmits.
  • AP1 may include Coordinator AP capability information in the Beacon it transmits.
  • AP2 may transmit a Probe Request and receive a Probe Response that AP1 transmits in response to the Probe Request.
  • the Probe Response may include Coordinator AP capability information.
  • AP2 which has received the Beacon or Probe Response sent by AP1, may determine whether or not cooperative communication is possible based on the Coordinator AP availability information contained in the Beacon or Probe Response. For example, it may determine that cooperative communication is possible if "AP1 is capable of functioning as a Coordinator AP and AP2 is not capable of functioning as a Coordinator AP" or "AP1 is not capable of functioning as a Coordinator AP and AP2 is capable of functioning as a Coordinator AP.”
  • AP2 may send a Multi-AP Setup Request to AP1.
  • AP2 may send a Multi-AP Setup Request if it determines that cooperative communication is possible.
  • the Multi-AP Setup Request may use the format shown in FIG. 9, or may use a format from FIG. 9 that excludes the Coordinator AP ID information, or may use a format that includes information indicating whether or not to operate as a Coordinator AP instead of the Coordinator AP ID information.
  • AP1 may send a Multi-AP Setup Response to AP2.
  • the format of the Multi-AP Setup Response may be the same as that of the Multi-AP Setup Request.
  • the Coordinate Type included in the Multi-AP Setup Response may be a coordination method in which both AP1 and AP2 can operate.
  • the Multi-AP Setup Response may notify that preparations for cooperative communication as a Coordinator AP or Coordinated AP have been completed. It may be determined that preparations for cooperative communication as a Coordinator AP or Coordinated AP have been completed by sending or receiving the Multi-AP Setup Response.
  • the Coordinator AP is determined in the Multi-AP setup S501, but for example, after the Coordinator AP is determined in the Multi-AP setup S501, an AP to notify the control information of the cooperative communication (hereinafter, referred to as the "AP to be connected to in inter-AP communication") may be determined.
  • the modified example can be combined with any of the first, second and third embodiments.
  • AP1 when AP1 is a Coordinator AP or AP1 is a Coordinated AP participating in a Coordination Group, and AP2 is a Coordinated AP and can transmit and receive with multiple APs, AP1 may notify AP2 of which AP is optimal to notify when AP2 transmits to AP1.
  • AP2 may notify AP1 of transmittable AP information (information of multiple APs with which AP2 can transmit and receive), and APs along the way may perform the same operation, so that when AP1 receives the transmittable AP information, AP1 may specify the AP to which AP2 will connect for inter-AP communication when AP2 transmits to AP1 (the AP to which AP1 will transmit when the final destination AP is AP1) based on at least one of the number of transfers from AP2 and the reception quality during transfer.
  • transmittable AP information information of multiple APs with which AP2 can transmit and receive
  • AP2 may notify AP1 of the transmittable AP information to be notified in a Multi-AP Setup Request, and AP1 may notify AP2 of the AP to which AP2 will connect for inter-AP communication in a Multi-AP Setup Response.
  • AP1 may forward the Multi-AP Setup Request and Multi-AP Setup Response notified between the Coordinator AP and AP2.
  • Example 1 when AP2 is a Coordinator AP or a Coordinated AP participating in a Coordination Group, and AP1 is a Coordinated AP and can transmit and receive with multiple APs, AP1 may notify AP2 of the APs it can transmit and receive with in a Multi-AP Setup Response, and AP2 may notify AP1 of the AP to which it will connect for inter-AP communication in a Multi-AP Action frame with Category defined as Cooperative AP designation.
  • the AP information available for transmission and reception is notified in a Multi-AP Setup Request or Multi-AP Setup Response
  • the destination AP for AP-to-AP communication is notified in a Multi-AP Setup Response or a Multi-AP Action frame with a Category designated as a cooperative AP.
  • the AP information available for transmission and reception and the destination AP for AP-to-AP communication may both be notified in a Multi-AP Action frame with a Category designated as a cooperative AP, or may be notified in other frames.
  • the AP notification format shown in Figure 12 may be used to notify transmitting/receiving AP information or the AP to which inter-AP communication is connected.
  • the AP ID field may be the ID of the AP capable of transmitting and receiving in the case of transmitting and receiving AP information.
  • the AP ID may be the ID of the AP to which inter-AP communication is connected.
  • the RSSI field may indicate the reception quality of each AP capable of transmitting and receiving (for example, the reception power and path loss of the beacon transmitted by each AP). It may also be used by the Coordinator AP to select the optimal AP. RSSI does not have to be included in the response specifying the connection destination for AP-to-AP communication.
  • Example 4 The Coordinator AP capability information of the AP in the third embodiment may be specified by a higher layer.
  • Figure 13 shows an example of an operation sequence in Multi-AP setup S501, where AP1 and AP2 are started in that order, and the Coordinator AP is selected after AP2 is started.
  • the higher layer SME station management entity
  • Multi-AP parameters including information on whether the Coordinator AP is available
  • the MLME of AP1 that received the MLME-START.request may check whether it receives the beacons sent by the surrounding APs. In this operation example, since the beacons sent by the surrounding APs are not received, it may start sending periodic beacons (including information on whether the Coordinator AP is available). The transmission of beacons by AP1 does not have to be periodic, but may be irregular.
  • an MLME-START.confirm primitive may be returned to the SME of AP1.
  • the MLME of AP2 receives an MLME-START.request primitive from the SME, just like AP1 does when starting up.
  • the MLME of AP2 may check whether it receives the Beacon sent by the surrounding AP. In this operation example, it receives the Beacon sent by AP1.
  • AP2 may send a Probe Request and receive a Probe Response sent by AP1 in response to the Probe Request.
  • the MLME of AP2 determines whether or not cooperative communication is possible based on the Coordinator AP availability information included in the MLME-START.request primitive and the Coordinator AP availability information included in the Beacon or Probe Response sent by AP1. For example, the MLME of AP2 may determine that cooperative communication is possible if "AP1 is capable of functioning as a Coordinator AP and AP2 is not capable of functioning as a Coordinator AP" or "AP1 is not capable of functioning as a Coordinator AP and AP2 is capable of functioning as a Coordinator AP.” If AP2 determines that cooperative communication is possible, it may send a Multi-AP Setup Request to AP1.
  • AP1 when AP1 receives the Multi-AP Setup Request, it may send a Multi-AP Setup Response to AP2.
  • the MLME may return an MLME-START.confirm primitive to the SME.
  • the MLME-START.confirm primitive may include information indicating the start of cooperative communication operation.
  • the upper layer is SME, it may be a layer other than SME, such as a hostapd program, firmware, an access point management program, an IEEE1905 standard entity, or a Terminal defined in the Wi-Fi standard.
  • AP1 may notify AP2 that it is a Coordinated AP under the control of another Coordinator AP by using a Beacon or Probe Response.
  • AP1 may notify AP2 of the ID of the Coordinator AP by using a Beacon, Probe Response, or Multi-AP Setup Response.
  • the Coordinator AP may notify that the Coordinated AP list has been updated if other Coordinated APs exist. For example, if AP1 is the Coordinator AP, it may notify the Coordinated AP list in a Multi-AP Setup Response frame. If AP2 is the Coordinator AP, it may notify the Coordinated AP list in a Multi-AP Setup Request frame. Furthermore, the Coordinated AP list may include the IDs of the Coordinated APs.
  • Example 4 an example was shown in which the Coordinator AP availability information of the AP in Example 3 is notified by the upper layer, but in the operational examples of Examples 1, 2, or the modified examples, the upper layer may similarly notify a coordination bitmap.
  • the information notified from the upper layer may be Coordinator AP availability information and Coordinated AP availability information, and the coordination bitmap may be created in the MLME based on this information.
  • the information notified from the upper layer may include operable coordination methods, or the notified operable coordination methods may be limited to methods related to the path of the transmission data (e.g. JT or dynamic AP selection, etc.).
  • FIG. 14 shows an example of a flowchart of an operation example using backhaul communication in the Multi-AP setup S501.
  • the AP type is determined.
  • the SME may determine the AP type (Coordinator or Coordinated AP). For example, if the AP operates as a Wi-Fi Easy Mesh controller AP, it may be set as a Coordinator AP, and if the AP operates as a Wi-Fi Easy Mesh agent AP, it may be set as a Coordinated AP.
  • a Coordinator AP capable of backhaul connection may be found by a Coordinator AP search in S1403, and in S1404 the AP may begin operating as a Coordinated AP and perform the Coordination Group joining procedure.
  • the Coordination Group joining procedure may be performed with the Coordinator AP via backhaul communication.
  • Capable of backhaul connection may mean that IP (Internet Protocol) communication is possible, or that two or more APs on the same segment (subnet) are capable of IP communication.
  • the "Coordination Group joining procedure” may include at least one of an ID registration procedure, a capability exchange procedure, and an authentication procedure.
  • a Coordinator AP that can connect to a backhaul may be discovered by a Coordinator AP search in S1405, and in S1406 the AP may begin operating as a Coordinator AP and generate a Coordination Group.
  • the Coordination Group joining procedure may be performed on the Coordinator AP via backhaul communication.
  • the results of the determination of the Coordinator AP and Coordinated AP by AP type determination S1401, and Coordination Group information may be included in the MLME-START.request sent from the SME to the MLME, for example.
  • the inter-AP communication shown in Example 1, Example 2, Example 3, the modified example, and Example 4 may be performed via backhaul communication.
  • the Coordinator AP may accept a Coordination Group participation request from a Coordinated AP via backhaul communication after the Coordinator AP starts operating, or the Coordinator AP may determine whether or not to participate and notify the Coordinated AP of the result via backhaul communication.
  • a backhaul transceiver unit may be provided to perform backhaul communication, and the input data input to the cooperative control unit 406 and the output data output from the cooperative control unit 406 (not shown in the figure) may include information to be transmitted and received via backhaul communication.
  • the Coordinator AP may notify other Coordinator APs via backhaul communication that the list of Coordinator APs has been updated, and the Coordinator AP that receives the notification may notify the updated list from the SME to the MLME.
  • the notification may include this information in the newly defined MLME-MULTIAP-RECONFIGURATION.request.
  • Multi-AP setup using AP-to-AP communication can also be performed at the same time.
  • a Beacon may be received from other APs or a Probe Request may be sent to other APs, and if other APs are present, the Multi-AP setup operation shown in Examples 1 to 4 may be performed, or Multi-AP setup may be performed via backhaul communication for the AP that sent the received Beacon, or the APs that perform Multi-AP setup via backhaul communication may be limited to the AP that received the Beacon.
  • the configuration of the STA and AP may be the same as that shown in embodiment 1.
  • Fig. 15 shows an overall step different from that shown in Fig. 5. It shows an example in which AP2 is newly installed in a state where AP1 is installed and periodically transmits a beacon. As shown in Fig. 15, each AP performs multi-AP setup S1501 and cooperation start determination S1502, followed by multi-AP measurement S1503 and multi-AP transmission S1504.
  • Multi-AP setup S1501, Multi-AP measurement S1503, and Multi-AP transmission S1504 may be the same as those in the first embodiment.
  • the cooperation start determination S1502 may determine that cooperative communication should be started when a transmission wait occurs due to the effects of interference from other APs or STAs, etc.
  • Multi-AP measurement S1503 and Multi-AP transmission S1504 may be started after the cooperation start determination S1502. Note that the determination as to whether a transmission wait has occurred may be made when the amount of transmission data stored in the transmission buffer increases (increase in transmission queue length) or when data transmission delay increases.
  • the Coordinated AP may notify the Coordinator AP of a request to initiate cooperative communication.
  • a STA When a STA determines to start cooperative communication, it may notify the association AP of a request to start cooperative communication, or, if the association AP is a Coordinated AP, may forward the request to start cooperative communication to the Coordinator AP.
  • the cooperative start request may include the device's own ID, the ID of the detected AP (e.g., BSS ID or BSS color), and the UL/DL information of the interfering packet.
  • the targets of the multi-AP measurement may be limited based on the information contained in the received cooperative start request.
  • the power consumption of the STA can be reduced by measuring interference only when cooperative communication is required.
  • frequency utilization efficiency can be improved by transmitting and transferring interference data only when cooperative communication is required.
  • Figure 16 shows an example of the arrangement of APs and STAs.
  • Figure 16 shows an example of an arrangement in which STA1-1 and STA1-2 are associated with AP1, which is the Coordinator AP, and STA2-1 is associated with AP2, which is the Coordinated AP.
  • This figure discloses the operation when STA2-1 is unable to transmit due to interference from a signal transmitted by AP1 and is forced to wait for transmission in the arrangement shown in Figure 16.
  • STA2-1 detects that a transmission wait has occurred and notifies AP2, the associated AP, of a collaboration start request.
  • the collaboration start request may include information about the source of the interfering signal (AP1 in this example).
  • AP2 the coordinated AP, forwards STA2-1's collaboration start request to AP1, the coordinator AP.
  • AP1 receives the forwarded collaboration start request and measures the interference, and instructs AP2 to measure the interference as well.
  • AP1 and AP2 may instruct the STAs with which they are associated (e.g., STA1-1, STA1-2, and STA2-1) to measure interference.
  • the targets for measuring interference may be limited to some STAs.
  • the STAs for which interference is measured may be limited to STAs with small path loss (e.g., STA1-1) and STA2-1 that has notified a request to start cooperation.
  • AP1 may specify the operation of cooperative communication based on the results of the interference measurement. For example, AP1 may specify C-SR, which simultaneously transmits from AP1 to STA1-1 and from STA2-1 to AP2.
  • notification of a cooperation start request may be limited to cases where there is interference caused by signals transmitted by cooperative APs (Coordinator AP and coordinated APs) and STAs associated with the cooperative APs.
  • the cooperative AP list (including the BSS ID or BSS color of the cooperative APs) may be notified to the STA in advance. This makes it possible to prevent notification of a cooperation start request caused by interference caused by signals transmitted by APs and STAs that are not subject to cooperative communication.
  • the multi-AP setup S1501 may be performed when a request to start cooperative communication occurs. This allows the multi-AP setup S1501 to be performed for the APs that will perform cooperative communication. It also makes it possible to prevent the construction of unnecessary Coordination Groups.
  • the cooperation initiation request shown in the sixth embodiment may be defined as a type of management frame.
  • the cooperation initiation request may be defined by a Multi-AP Action frame in which Category is set to cooperation initiation request in an Action frame, for example.
  • An example of the cooperation initiation request defined in a Multi-AP element is shown in FIG. 17.
  • the AP/STA ID field indicates the AP or STA affected by the interference, and in the case of a STA it may be the AID (Association ID), and in the case of an AP it may be an unused AID (e.g., 4094).
  • the BSS ID field may contain the BSS ID or BSS color of the interfering source.
  • the DL/UL field is the DL/UL information of the interference packet, and may be, for example, "0: DL, 1: UL, 2: DL and UL.” If DL/UL is UL or DL and UL, the source STA ID may be added to the format shown in Figure 17.
  • the STA when an AP is placed in a position where direct transmission and reception between the APs is not possible, the STA transfers information (cooperative control information, etc.) to be communicated between the APs, thereby enabling transmission and reception between the APs.
  • the configurations of the STA and the AP may be the same as those shown in the first embodiment.
  • FIG. 18 shows another example of the arrangement of APs and STAs.
  • Fig. 18 shows a case where AP2 is newly arranged in a position where direct communication with AP1 is not possible but direct communication with STA1 is possible in a state where AP1 and STA1 associated with AP1 are arranged.
  • an example of performing the Multi-AP cooperative operation shown in the first and second embodiments by STA1 transferring information to be transmitted between AP1 and AP2 will be described.
  • STA1 When STA1 receives a beacon from the newly activated AP2, it may notify AP1 that AP2 has been deployed (hereinafter referred to as cooperative candidate AP notification). Note that the presence or absence of notification may be determined based on Multi-AP capability information (e.g. cooperative operation capability flag) included in the beacon from AP2. In addition, STA1 may be notified when a transmission wait occurs in STA1, such as when there is interference from AP2 or a STA associated with AP2, or when AP2 is not included in the cooperative AP list.
  • Multi-AP capability information e.g. cooperative operation capability flag
  • AP1 which receives the cooperative candidate AP notification, may send a cooperative start request (for example, the Multi-AP Setup Request shown in embodiment 1) to AP2 to STA1, and STA1 may forward the received cooperative start request to AP2.
  • STA1 may also associate with AP2 in order to communicate with AP2.
  • STA1 associates with AP2 it may include information indicating that the purpose is cooperative inter-AP control data transfer (for example, a flag indicating transfer or AP1's ID, etc.), or the cooperative start request may be included in the signal sent when associating.
  • the communication between AP1 and AP2 in the cooperative communication shown in the first and second embodiments may be communication via STA1.
  • Figure 19 shows another example of the placement of APs and STAs.
  • Figure 19 shows an example of operation when AP1 and AP2, which are capable of using Dynamic AP selection as a coordination method, participate in the same Coordination Group, and STA1 moves in the direction of AP2 after associating with AP1.
  • AP1 and AP2 selected dynamic AP selection as the cooperation method by the Multi-AP setup S501 shown in the first, second, and third embodiments.
  • STA1 may associate with AP2 as a switching candidate for dynamic AP selection. For example, STA1 may associate when AP2 is included in the list of cooperative APs and/or when the received power of a signal (e.g., a beacon) transmitted by AP2 exceeds a certain threshold. AP1 may also notify STA1 in advance of a list of APs capable of dynamic AP selection, and STA1 may associate when AP2 is included in the list of APs received by STA1.
  • a signal e.g., a beacon
  • dynamic AP selection can be performed by identifying APs that will be the target of cooperative communication in a Multi-AP setup.
  • unnecessary associations can be prevented by having STAs that are likely to perform dynamic AP selection associate with candidate APs to switch to.
  • association request that STA1 sends to AP2 may contain information indicating that it is a candidate destination for dynamic AP selection, or may contain the ID of the AP to which STA1 is currently associated (e.g. AP1) and the ID of STA1 (e.g. the AID assigned by AP1). This allows the candidate destination AP to identify the source AP.
  • the association response that AP2 notifies STA1 may include information on whether dynamic AP selection is possible and/or rank information.
  • the rank information may be, for example, rank 1 when transmitted packet information can be shared between AP1 and AP2, and rank 2 when it cannot be shared.
  • STA1 may change the dynamic AP selection parameters (for example, the threshold value of the difference between AP1 received power and AP2 received power for determining the start of switching operation, or the number of forward and backward protections when switching is performed) according to the rank.
  • rank 1 may be a value that allows switching to be performed easily. This allows switching to be performed according to the functions of the destination AP and the source AP.
  • STA1 may also notify AP1 (the source AP) and AP2 (the destination AP) of a request to switch the transmission/reception destination.
  • AP1 may make a switch request.
  • the switch request may be made based on the results of multi-AP measurement S1503 (measurement of interference from AP2 on STA1).
  • a BSS (virtual BSS) that includes AP1 and AP2 may be provided.
  • STA1 may associate with the virtual BSS instead of associating with AP2.
  • the notation "part” used for each component may be replaced with other notations such as “circuitry”, “assembly”, “device”, “unit”, or “module”.
  • Each functional block used in the description of the above embodiments may be realized, in part or in whole, as an LSI, which is an integrated circuit, and each process described in the above embodiments may be controlled, in part or in whole, by one LSI or a combination of LSIs.
  • the LSI may be composed of individual chips, or may be composed of one chip that contains some or all of the functional blocks.
  • the LSI may have data input and output. Depending on the degree of integration, the LSI may be called an IC, system LSI, super LSI, or ultra LSI.
  • the integrated circuit method is not limited to LSI, and may be realized by a dedicated circuit, a general-purpose processor, or a dedicated processor. Also, a field programmable gate array (FPGA) that can be programmed after LSI manufacturing, or a reconfigurable processor that can reconfigure the connections and settings of circuit cells inside the LSI, may be used.
  • FPGA field programmable gate array
  • the present disclosure may be realized as digital processing or analog processing.
  • the present disclosure may be implemented in any type of apparatus, device, or system (collectively referred to as a communications apparatus) having communications capabilities.
  • the communications apparatus may include a radio transceiver and processing/control circuitry.
  • the radio transceiver may include a receiver and a transmitter, or both as functions.
  • the radio transceiver (transmitter and receiver) may include an RF (Radio Frequency) module and one or more antennas.
  • the RF module may include an amplifier, an RF modulator/demodulator, or the like.
  • Non-limiting examples of communication devices include telephones (e.g., cell phones, smartphones, etc.), tablets, personal computers (PCs) (e.g., laptops, desktops, notebooks, etc.), cameras (e.g., digital still/video cameras), digital players (e.g., digital audio/video players, etc.), wearable devices (e.g., wearable cameras, smartwatches, tracking devices, etc.), game consoles, digital book readers, telehealth/telemedicine devices, communication-enabled vehicles or mobile transport (e.g., cars, planes, ships, etc.), and combinations of the above-mentioned devices.
  • telephones e.g., cell phones, smartphones, etc.
  • tablets personal computers (PCs) (e.g., laptops, desktops, notebooks, etc.)
  • cameras e.g., digital still/video cameras
  • digital players e.g., digital audio/video players, etc.
  • wearable devices e.g., wearable cameras, smartwatches, tracking
  • Communication devices are not limited to portable or mobile devices, but also include any type of equipment, device, or system that is non-portable or fixed, such as smart home devices (home appliances, lighting equipment, smart meters or measuring devices, control panels, etc.), vending machines, and any other "things” that may exist on an IoT (Internet of Things) network.
  • smart home devices home appliances, lighting equipment, smart meters or measuring devices, control panels, etc.
  • vending machines and any other “things” that may exist on an IoT (Internet of Things) network.
  • IoT Internet of Things
  • Communications include data communication via cellular systems, wireless LAN systems, communication satellite systems, etc., as well as data communication via combinations of these.
  • the communication apparatus also includes devices such as controllers and sensors that are connected or coupled to a communication device that performs the communication functions described in this disclosure.
  • a communication device that performs the communication functions described in this disclosure.
  • controllers and sensors that generate control signals and data signals used by the communication device that performs the communication functions of the communication apparatus.
  • communication equipment includes infrastructure facilities, such as base stations, access points, and any other equipment, devices, or systems that communicate with or control the various non-limiting devices listed above.
  • CPS Chip Physical Systems
  • IoT Internet of Things
  • an edge server located in physical space and a cloud server located in cyberspace can be connected via a network, and processing can be distributed and processed by processors installed in both servers.
  • each processing data generated in the edge server or cloud server is preferably generated on a standardized platform, and the use of such a standardized platform can improve the efficiency of building a system that includes a variety of sensor groups and IoT application software.
  • An access point has a transceiver unit that receives information related to cooperative communication, and a control circuit that determines whether to operate as an access point that controls cooperative communication.
  • an access point according to (1) is an access point in which the information relating to the cooperative communication received by the transceiver is information received from another access point, the transceiver transmits the information relating to the cooperative communication to the other access point, and the control circuit decides whether or not to operate as an access point that controls the cooperative communication through negotiation with the other access point.
  • the information relating to cooperative communication received from the other access points or the information relating to cooperative communication transmitted to the other access points is a cooperative bitmap.
  • the transceiver unit of the access point of (1) transmits to other access points whether or not the access point can operate as an access point that controls cooperative communication.
  • the access point of (1) is configured such that the control circuit specifies whether or not the access point operates as an access point in which a higher layer controls cooperative communication.
  • the information regarding the cooperative communication received by the transceiver unit includes a cooperative method, and is information received from another access point, and the control circuit determines the cooperative method for the cooperative communication based on an operable cooperative method.
  • the control circuit determines to start cooperative communication based on the results of interference measurements by other access points or terminals.
  • the transceiver unit receives information about cooperative communication transmitted by other access points from the terminal.
  • an access point in (1) receives from a terminal information indicating that the access point is a candidate destination for dynamic AP selection, or an association including the ID of the currently associated access point and the ID of the terminal, thereby identifying the access point from which dynamic AP selection is to be switched.
  • an access point receives information related to cooperative communication and determines whether or not to operate as an access point that controls cooperative communication.
  • This disclosure is useful for cooperative communication.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Quality & Reliability (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

協調通信に関する情報を受信する送受信部と、Coordination APとして動作するか否かを決定する制御回路と、を有するＡＰ装置。

Description

アクセスポイント及び協調通信の制御方法
　本開示は、アクセスポイント及び協調通信の制御方法に関する。
　IEEE（the Institute of Electrical and Electronics Engineers）802.11の規格である802.11ax（以下、「11ax」という。）の後継規格として、802.11be（以下、「11be」という。）の技術仕様策定が進められている。11axはHigh Efficiency（HE）とも呼ばれ、11beはExtreme High Throughput（EHT）とも呼ばれる。また、11beの後継規格（UHR(Ultra High Reliability)と呼ぶ場合がある。以下、「beyond 11be」という。）についても要求仕様の議論が進められている。
IEEE 802.11-18/1982r0, Consideration on multi-AP Coordination for EHT IEEE 802.11-19/0103r1, AP Coordination in EHT IEEE Std 802.11-2020, December 2020
　しかしながら、Multi-AP（Access Point） Coordination（以下、「協調通信」という。）の制御方法、例えば協調通信の選択方法、協調通信の動作開始方法、又はAP間で直接送受信できない場合の動作について、は十分に検討されていない。
　本開示の非限定的な実施例は、アクセスポイント及び協調通信の制御方法の提供に資する。
　本開示の一実施例に係るアクセスポイントは、協調通信に関する情報を受信する送受信部と、協調通信を制御するアクセスポイントとして動作するか否かを決定する制御回路と、を有する。
　なお、これらの包括的又は具体的な態様は、システム、装置、方法、集積回路、コンピュータプログラム、又は、記録媒体で実現されてもよく、システム、装置、方法、集積回路、コンピュータプログラム及び記録媒体の任意な組み合わせで実現されてもよい。
　本発明によれば、アクセスポイント及び協調通信の制御方法を提供することができる。
　本開示の一実施例における更なる利点及び効果は、明細書及び図面から明らかにされる。かかる利点及び／又は効果は、いくつかの実施形態並びに明細書及び図面に記載された特徴によってそれぞれ提供されるが、１つ又はそれ以上の同一の特徴を得るために必ずしも全てが提供される必要はない。
Elementのフォーマットを示す図 Element IDのテーブルを示す図 STAの構成を示す図 APの構成を示す図 全体のステップを示す図 Coordinator APとして動作するか否かを決定する動作シーケンスの例を示す図 Coordinator AP及びCoordinated APの可否情報、及びCoordinator選択結果の組合せを示す図 協調bitmapをMulti-AP elementによって送信するフォーマット例を示す図 beyond 11be端末のCapability情報を含むエレメントのフォーマット例を示す図 Multi-AP Capabilities Informationフィールドのフォーマット例を示す図 Multi-AP elementで規定したMulti-AP Setup Requestの例を示す図 Coordinator APとして動作するか否かを決定する動作シーケンスの別の例を示す図 Multi-APの動作状態を送信するフォーマット例を示す図 Coordinator APとして動作するか否かを決定する動作シーケンスのさらに別の例を示す図 Multi-AP elementで規定したAP通知フォーマットの例を示す図 AP1、AP2の順に起動しAP2起動後にCoordinator APを選択する動作シーケンスの例を示す図 バックホール通信を用いた動作例のフローチャートを示す図 別の全体のステップを示す図 APとSTAの配置例を示す図 Multi-AP elementで規定した協調開始要求の例を示す図 APとSTAの別の配置例を示す図 APとSTAのさらに別の配置例を示す図 協調bitmapを示す図 各「Coordinator APの可否」及び「Coordinated APの可否」及び「各協調方式の可否」を示すビットを設けた協調bitmapを示す図 各「Coordinator APの可否」及び「Coordinated APの可否」毎に各協調方式の可否を示すビットを設けた協調bitmapを示す図 各協調方式毎に「Coordinator APの可否」及び「Coordinated APの可否」を示すビットを設けた協調bitmapを示す図
＜Multi-AP Coordinationについて＞
　11be及びbeyond 11beでは、アクセスポイント（「基地局（AP STA）」とも呼ばれる。以下、「AP」という。）が協調して各端末（non-AP STAとも呼ばれる。以下、「STA」という。）との間でデータを送受信する協調通信の適用が検討されている。
　協調通信の構成として、協調通信を制御するAP（Coordinator AP、Primary AP、Controller AP、又はMaster APとも言う。以下、「Coordinator AP」と言う。)が、協調通信を制御されるAP（Coordinated AP、Secondary AP、Agent AP、又はSlave APとも言う。以下、「Coordinated AP」と言う。)を制御する方法が検討されている（非特許文献１を参照）。
　一方、協調通信の方式としてC-OFDMA（Coordinated Orthogonal Frequency Division Multiple Access）、C-TDMA（Coordinated Time Division Multiple Access）、C-SR（Coordinated Spatial Reuse）、CBF（Coordinated Beamforming）、JT(Joint Transmissions)、dynamic AP selection等が提案されている(非特許文献２を参照)。
　また、IEEE802.11では、送受信する情報としてElementがある。Elementのフォーマットを図１に、Element IDのテーブルを図２に示す（非特許文献３を参照）。
＜実施の形態１＞
　本発明の一形態では、少なくとも２つのAPが配置されている場合において、各APがCoordinator APとして動作するか否かを決定し、Multi-AP協調通信を行う。
［STAの構成］
　図３はSTAの構成を示す図である。STAは、送信パケット生成部301、制御信号生成部302、無線送受信部303、受信パケット復号部304、受信品質測定部305を含む。送信パケット生成部301、制御信号生成部302、受信パケット復号部304、及び受信品質測定部305の少なくとも１つは、制御回路306を構成してもよい。パケットを、physical layer (PHY) protocol data unit (PPDU)と呼ぶ場合がある。また、パケット及び／またはPPDUは、medium access control(MAC)フレーム（MPDU: MAC protocol data unit）を符号化及び変調した信号であってもよい。
　送信パケット生成部301は、入力データ及び制御信号生成部302によって生成された制御信号、に基づいて送信パケットを生成し、無線送受信部303に出力する。入力データを、medium access control (MAC) service data unit (MSDU)、上位レイヤデータ、と呼ぶ場合がある。
　制御信号生成部302は、入力データ、受信パケット復号部304から出力された制御情報、受信品質測定部305が測定した受信品質、及び内部状態に基づいて制御信号を生成し、送信パケット生成部301に出力する。
　無線送受信部303は、送信パケット生成部301によって生成された送信パケットを無線信号に変換し、アンテナへ出力する。また、無線送受信部303は、アンテナから無線信号を受信し、受信パケット復号部304及び受信品質測定部305へ受信信号出力する。
　受信パケット復号部304は、無線送受信部303から受信した受信信号を復号した出力データを出力すると共に、受信品質測定部305及び制御信号生成部302に制御情報を出力する。
　受信品質測定部305は、無線送受信部303から受信した受信信号、受信パケット復号部304から受信した制御情報、及び内部状態に基づいて受信品質を測定する。
［APの構成］
　図４はAPの構成を示す図である。APは、送信パケット生成部401、制御信号生成部402、無線送受信部403、受信パケット復号部404、受信品質測定部405、協調制御部406を含む。図３に示したSTAの構成に協調制御部406を加えた構成としてもよい。送信パケット生成部401、制御信号生成部402、受信パケット復号部404、受信品質測定部405、及び協調制御部406の少なくとも１つは、制御回路407を構成してもよい。
　送信パケット生成部401、制御信号生成部402、無線送受信部403、受信パケット復号部404、受信品質測定部405は、送信パケット生成部301、制御信号生成部302、無線送受信部303、受信パケット復号部304、受信品質測定部305と同じ機能を有してもよい。
　協調制御部406は、入力データ、受信パケット復号部404が出力した制御情報、受信品質測定部405が測定した受信品質、及び内部状態に基づいて協調通信を行うための協調制御情報を生成し、制御信号生成部402に出力する。
＜実施例１＞
　以下一例として、AP1が定期的にBeaconを送信している状態で設置されている時に、AP2が新たに設置、起動、又は／及び再起動される場合の例を説明する。図５に、全体のステップを示す。各APは、図５に示すようにMulti-APセットアップS501の後に、Multi-AP測定S502及びMulti-AP送信S503を行う。
　Multi-APセットアップS501では、APは周辺APとネゴシエーションして、APがCoordinator APとして動作するか、Coordinated APとして動作するかを決定する。
　Multi-AP測定S502では、AP及びSTAが干渉量を測定し、測定結果を互いに送信する。なお、Coordinator APが測定対象を指定してもよい。測定は、定期的に実施してもよいし、例えばパスロスが変化した場合等に実施してもよい。動作する協調方式が、例えばC-TDMA又はC-OFDMAの場合は、干渉量による制御が不要であるから、Multi-AP測定を行わなくてもよい。これにより、STAによる干渉測定が不要となるから、STAの消費電力を低減することができる。また、干渉量測定結果の送信が不要となるから、スループットの低下を防ぐことができる。
　Multi-AP送信S503では、Sharing AP（すなわち、TXOP（Transmission Opportunity）を取得したAP）が協調通信の送受信を指定してもよい。Coordinator APがsharing APとなる場合のみ協調通信を行ってもよい。Coordinated APがsharing APとなる場合はCoordinator APの指定（例えばトリガ）により協調通信を行ってもよい。
　Multi-AP送信S503において、APがTXOPを獲得して協調通信を行う例を示したが、例えばMulti-APセットアップS501で協調通信を行うサービスピリオドの設定を行い、Multi-AP送信S503で、設定されたサービスピリオドに基づいて協調通信（例えばAP1とAP2が個別のサービスピリオドで送信）をしてもよい。なおサービスピリオドの設定とは、例えば協調通信の設定情報を含むTWT（Target Wake Time）の設定であってもよい。
　また、各AP（Coordinator AP及びCoordinated AP）は、協調通信以外に個別にアソシエートしている各STAとの送受信を行ってもよい。
　図６に、AP2が、Multi-APセットアップS501において、AP1とのネゴシエーションによってcoordinator APとして動作するか否かを決定する動作シーケンス例を示す。
　AP1は協調通信に関するCapability情報を報知または通知する。例えば、BeaconにCoordinator AP及びCoordinated APの可否情報（以下、「協調bitmap」という。）を含めてもよい。
　協調bitmapは、図２０に示すように、「Coordinator APの可否を示すビット」と「Coordinated APの可否を示すビット」から構成されてもよい。ビットの順番は逆でもよい。例えば、ビット１は「可」を示しビット０は「否」を示してもよいし、ビット１は「否」を示しビット０は「可」を示してもよい。
　S601において、AP2は起動時に周辺APをサーチ(ディスカバリ又はスキャンとも言う)してもよい。
　S602において、AP2は、AP1が定期的に送信しているBeaconを受信し、受信したBeaconに含まれる協調通信に関するCapability情報（例えば協調bitmap）を得てもよい。AP2がProbe Requestを送信し、Probe Requestに応答してAP1が送信するProbe Responseを受信し、Probe Responseから協調通信に関するCapability情報を得てもよい。
　S603において、AP2は、受信したAP1の協調通信に関するCapability情報及びAP2自身の協調通信に関するCapability情報に相当する情報（内部情報）に基づいてCoordinator APを決定する。例えば、受信したAP1の協調bitmap及びAP2の協調bitmapに相当する内部情報に基づいて協調通信の可否及びCoordinator APを選択してもよい。
　S604において、AP2が、協調通信が可能であると判定した場合は、AP1に協調通信の開始要求（協調開始要求）としてMulti-AP Setup Requestを送信してもよい。Multi-AP Setup RequestにCoordinator APの選択結果を含めてもよい。
　S605において、AP1がAP2に協調開始要求に対する応答（協調開始応答）としてMulti-AP Setup Responseを送信してもよい。Multi-AP Setup ResponseにCoordinator AP選択結果の可否を含めてもよい。AP1は、Multi-AP Setup Responseの代わりにAck(acknowledge)を送信してもよい。
　図７に、AP1の協調bitmap及びAP2の協調bitmapに相当する内部情報に基づいて作成した各AP毎のCoordinator APの可否情報及びCoordinated APの可否情報、及びCoordinator APの選択結果の組合せの例を示す。図７に示す組合せに基づいて、協調通信の可否及びCoordinator APの選択を行ってもよい。図７では、協調bitmapのCoordinator AP及びCoordinated APがともに不可の場合は、協調通信は不可であることが明らかなので記載していない。
　図７において、*1（AP1とAP2が共に、Coordinator AP及びCoordinated AP共に可）の場合は、Coordinated AP数またはアソシエーションSTA数が多いAPをCoordinator APとしてもよい。この場合、APは、例えば、送信するMulti-AP Setup RequestにCoordinated AP数及びアソシエーションSTA数の少なくとも１つを含めてもよい。*2（AP1とAP2が共にCoordinator APのみ可）の場合は、協調不可と判断してもよい。あるいは、AP1とAP2が共に可能であれば、一方がCoordinator APとなり他方がCoordinated APとならなければならないという必要のない協調方式（例えばC-TDMAやdynamic AP selection）が選択され、AP1及びAP2の両方をCoordinator APとしてもよいし、Coordinator AP及び Coordinated APを選定しなくてもよい。*3（AP1とAP2が共にCoordinated APのみ可）の場合は、協調不可と判断してもよい。あるいは、AP1とAP2が共に動作可能であれば、一方がCoordinator APとなり他方がCoordinated APとならなければならないという必要のない協調方式が選択され、AP1及びAP2の両方をCoordinated APとしてもよいし、Coordinator AP及びCoordinated APを選定しなくてもよい。
　協調bitmapを送信するAPが、他Coordinator APに登録済みのCoordinated APである、という場合は、協調bitmap内のCoordinator APの可否を可としてもよいし、協調bitmapに他Coordinator APに登録済みCoordinated APの項目を追加してもよい。
　このように、Multi-APセットアップS501において、APは、他のAPから通知された協調bitmap及び自身の協調bitmapに相当する情報に基づいてCoordinator APを選択することにより、Coordinator APの制御によるMulti-AP測定S502及びMulti-AP送信S503を行うことができる。
　協調bitmapに、各APが動作可能な協調方式（例えばC-TDMA、C-OFDMA、C-SR、CBF、JT、dynamic AP selection等）の情報が含まれてもよい。協調bitmapは、図２１に示すように、AP毎に各協調方式の可否を示すビットを設けた協調bitmapでもよいし、図２２に示すように、各「Coordinator APの可否」及び「Coordinated APの可否」毎に各協調方式の可否を示すビットを設けた協調bitmapでもよいし、図２３に示すように、各協調方式毎に「Coordinator APの可否」及び「Coordinated APの可否」を示すビットを設けた協調bitmapでもよい。図２１、図２２、及び図２３において、協調方式の順番は別の順番でもよいし、指定された順番でもよい。一部の協調方式だけでもよいし、例示した以外の協調方式が含まれてもよい。この場合、協調bitmapに含まれる協調方式の情報に基づいて、協調通信で使用する協調方式は、全てのAPが動作可能な協調方式に限定されてもよい。この場合、例えばMulti-AP Setup Requestで動作可能な協調方式が通知されてもよい。これにより協調するAPの機能に応じた協調方式を選択することができる。また、図２２及び図２３に示した協調bitmapを用いた場合に、図７において*1（AP1とAP2が共に、Coordinator AP及びCoordinated AP共に可）の場合は、動作可能な協調方式が多くなるAPがCoordinator APとされてもよい。
　AP2は、Multi-APセットアップS501の後にBSS(Basic Service Set)の構築（BSSの開始ともいう）をしてもよい。Multi-APセットアップS501の後にBSSの構築を行うことにより、協調方式に応じたprimary CHを指定することができる。例えばC-SR、CBF、またはJTで動作する場合は、AP2がAP1と同じprimary CHを指定することにより、協調通信を行う際に必要な、同じ送信周波数帯域への割り当てを容易に行うことができる。例えばC-OFDMAで動作する場合は、AP2がAP1と違うprimary CHを指定することにより、協調通信を行う際に必要な、違う送信周波数帯域への割り当てを容易に行うことができる。
　各APがCoordinated APリストを有し、Coordinator APが、Multi-APセットアップS501においてCoordinated APとしたAPをCoordinated APリストに追加してもよい。また、Coordinator APになること、及びCoordinated APになること（Coordinated APリストに含まれること）を、Coordination Group（またはCoordination set）に参加すると言ってもよい。
　AP2が送信するMulti-AP Setup Requestへの応答として、AP1がMulti-AP Setup Responseの送信に成功したとき、つまり、AP2がMulti-AP Setup Responseを受信したとき、あるいはAP1がMulti-AP Setup Responseに対するAckを受信したときに、Multi-AP Setupネゴシエーションが成功したものとしてもよい。
　AP2は、Multi-AP Setup Requestに「Coordinator AP候補またはその他Multi-AP関連パラメータの候補」を含んで送信し、AP1はMulti-AP Setup Responseに「候補に同意するか否か」を含んだ応答を送信してもよいし、または「（候補に）同意/変更要求/拒否」のいずれかを含んだ応答を送信してもよい。
　「同意」を示すMulti-AP Setup Responseの送信が成功したとき、Multi-AP Setupネゴシエーションは成功したと判断され、Coordinator AP / Coordinated APが決定される。
　「変更要求」を示すMulti-AP Setup Responseの送信が成功したとき、AP2は、Coordinator AP / Coordinated APの変更に同意するか否かを含んだ、例えばMulti-AP Setup Responseを送信してもよい。
　「拒否」を示すMulti-AP Setup Responseの送信が成功したとき、Multi-AP Setupネゴシエーションは失敗したと判断され、Coordinator AP / Coordinated APは決定されない。
　Multi-AP Setupネゴシエーションが成功したとき、Coordinator APはネゴシエーション相手のAP（すなわち、Coordinated AP）をCoordinated APリストに追加してもよい。
　Coordinator APはCoordination Group（またはCoordination set）を識別する識別子としてCoordination Group ID（またはCoordination Set ID）をCoordination Group（またはCoordination set）に対して割り当ててもよい。なお、Coordination Group IDを、Multi AP Setup Request / Responseの交換時またはRequest / Responseの交換によるネゴシエーション後に割り当ててもよい。Coordination Group IDは、Coordinator APのIDとCoordination Group IDの組で一意に識別されるID、つまりCoordinator APのID毎に一意なIDとしてもよい。APは複数のCoordination Groupに参加してもよい。また、Coordinator APは、一つのCoordination Groupについて、Coordination Group IDとCoordinated APリストの組を管理してもよい。Coordination Group IDは、Coordinated APに通知されてもよいし、またはBeacon等で他のAPに報知されてもよい。Coordinator AP及びCoordinated APリストに含まれるAPのID（例えば、BSS ID、Macアドレス、BSS color、等）をまとめたリストを協調APリストとし、Beacon等で他のAP及びSTAに報知してもよい。
　既に成立しているCoordination Group(例えばAP1とAP2で構成されているCoordination Group)に対して、そのCoordination Groupに参加していないAP(例えばAP3)が、Multi-AP Setup RequestをCoordination Groupを構成しているAP(例えばAP1)に送信してネゴシエーションすることで、そのCoordination Group(例えばAP1とAP2で構成されているCoordination Group)に参加してもよい。例えばAP3が、AP1のBeaconに含まれるCoordination Group IDによって、AP1がBeaconに含まれるCoordination Group IDのCoordination Groupに参加していることを認識した場合、Beaconに含まれるCoordination Group IDを含めたMulti AP Setup RequestをAP1に送信してもよい。AP3は、AP1からMulti AP Setup Responseを受け取ることで、そのCoordination Groupに参加してもよい。
　協調開始要求としてMulti-AP Setup Requestを、協調開始応答としてMulti-AP Setup Responseを用いる例を示したが、Multi-AP Setup Requestの代わりにAnnouncementやAdvertisementなどResponseを求めないフレームをAP2が送信してもよい。この場合、Multi AP Setup Responseの代わりにAP1がAckフレームを返送してもよい。
　以上、AP2が、AP1へ協調開始要求(例えば、Multi-AP Setup Request)を送信する動作例を示したが、協調開始要求(例えば、Multi-AP Setup Request)をAP2がbroadcastで送信してもよい。例えば複数のAPがCoordination Groupに含まれる場合は、broadcastで送信することでCoordination Groupに含まれる複数のAPに同時に協調開始要求を送信することができる。
［フォーマット例］
　図１に示したElementフォーマットを用いて、Multi-APに関する制御情報（例えば、協調bitmap）を通知してもよい。例えば図２に示したElement IDのテーブルのElement ID = 255, Element ID Extension = 111をMulti-AP elementとしてもよい。Element IDExtensionの値は、一例として111であるとしたが、エレメントがMulti-AP elementであることを示す他の値であってもよい。Multi-AP elementは、例えばManagement frameの情報(例えばBeacon、Probe Response、Association Request、Re Association Request、Association Response、またはRe Association Responseフレーム）、またはMulti-AP Setup Requestフレーム、Multi-AP Setup Responseフレームに含めてもよいし、11be規格、または後継規格において新たに定義された他のAction frameに含めてもよい。また、Elementフォーマット以外のフォーマットでMulti-APに関する制御情報を通知してもよい。Multi-AP elementは別の名称(例えば、Multi-AP Information element)としもよい。
　図８に、協調bitmapをMulti-AP elementを用いたフォーマットで送信する例を示す。図８に示すMulti-AP elementの例では、協調bitmapの送信に用いるType値を０（Type = 0）とした。なお、Multi-AP Setup RequestまたはMulti-AP Setup Responseは、Multi-AP elementの別のType値を用いてもよい。協調bitmapの送信方法（Beaconに含める場合、Multi-AP Setup Requestに含める場合、等）に応じて内容を変えてもよい。図８のように、Coordinator APとしての動作可否に関する情報(一例として、協調 bitmap)を示すフィールドを含むエレメントは、Multi-AP Status variant、Multi-AP Advertisement variant、 Multi-AP Operation variant、Multi-AP Configuration variant、Multi-AP Setup Information variant等と呼ばれてもよい。
　図８において、協調bitmapフィールドは、図２０に示した協調bitmapとしてもよい。
　numAPフィールドは、該当APが含まれるCoordination GroupのCoordinated AP数としてもよい。
　numSTAフィールドは、該当APにアソシエーションしているSTA数としてもよいし、Coordination Group内のAPにアソシエーションしているSTA数としてもよい。numAP及びnumSTAが、図７の*1の場合に用いられる情報である場合は、協調bitmapにおいてCoordinator AP及びCoordinated APの両方が可の場合のみ加えてもよい。numAPまたはnumSTAは、受信したAPが使用する場合にだけ送信されるようにしてもよい。
　図８のMulti-AP elementを用いる代わりに、Coordinator APとしての動作可否に関する情報(協調bitmap情報)を、beyond 11be端末(APを含む。例えば、AP1、AP2)のCapabirity情報を含むエレメント(一例として、UHR Capabilities elementという)に含めてもよい。
　図８Aにフォーマット例を示す。Element IDフィールドは、エレメントがElement ID Extensionフィールドを含むことを示す値(255)に設定される。
　Lengthフィールドは、エレメントの長さに関する情報を含む。
　Element ID Extensionフィールドは、エレメントがUHR Capabilities elementであることを示す値(一例として、200)を含む。
　UHR MAC Capabilities Informationフィールドは、beyond 11beのMAC層のオプション機能を端末がサポートするか否かを示す情報を含み、各オプション機能に対応した複数のフィールド(図示せず)を含む。
　UHR PHY Capabilities Informationフィールドは、beyond beのPHY層のオプション機能を端末がサポートするか否かの情報を含み、各オプション機能に対応した複数のフィールド(図示せず)を含む。
　Multi-AP Capabilities Informationフィールドは、Multi-AP 協調に関するオプション機能を端末(APを含む)がサポートするか否かを示す情報を含む。Multi-AP Capabilities Information フィールドをオプションフィールドとして、UHR Capabilities elementをAPが送信する場合には、Multi-AP Capabilities Informationフィールドを UHR Capabilities elementに含めてもよい。UHR Capabilities elementをSTAが送信する場合には、Multi-AP Capabilities InformationフィールドをUHR Capabilities elementに含めないとしてもよい。
　図８Bに、Multi-AP Capabilities Informationフィールドのフォーマット例を示す。
　Coordinator AP mode supportedサブフィールドは、APがCoordinator APとしての動作可否を示す。
　Coordinated AP mode supportedサブフィールドは、APがCoordinated APとしての動作可否を示す。
　Coordinator AP mode supportedとCoordinated AP mode supported サブフィールドの組み合わせを、協調bitmapと呼んでもよい。
　Maximum number of Coordinated APサブフィールドは、APがCoordinator APとして動作する場合、参加可能なCoordinated APの最大数に関する情報を含む。なお、Maximum number of Coordinated AP サブフィールドの値が0の場合、Coordinator APとしての動作をサポートしないことを意味すると定め、Coordinator AP mode supportedサブフィールドを省略してもよい。
　Supported coordination typesサブフィールドは、APがサポートする協調方式（ C-TDMA、C-OFDMA、C-SR,CBF、JT、dynamic AP selection等）に関する情報を含む。
　Multi-AP Setup Request及びMulti-AP Setup ResponseがManagement frameの一種として定義されてもよい。あるいは、例えばAction frameとして、CategoryをMulti-APとしたMulti-AP Action frameが定義され、サブタイプとしてMulti-AP Setup Request frameまたはMulti-AP Setup Response frameが定義されてもよい。
　Multi-AP Setup Request及びMulti-AP Setup Responseが、Multi-AP elementの別のType値で定義され、用途（Beaconに含める場合、Setup Requestに含める場合、等）に応じて内容が変えられてもよい。また、図８、図８Ａのフレームに、協調bitmapの一部の情報を含めてもよい。また、協調bitmapの各ビットを、異なるフレームに含めてもよい。例えば、図８（Multi-AP element）において、Coordinater APの可否情報を含め、Coordinated APの可否情報を省略してもよい。また、図８Ａ（UHR Capabilities element）において、Coordinated APの可否情報を含め、Coordinater APの可否情報を省略してもよい。
　前記Multi-AP Setup Request frameは、例えば、Multi-AP elementのType値を１（Type = 1）としたフレームとして定義されてもよい。Multi-AP elementのType値を１と規定されたMulti-AP Setup Requestの例を図９に示す。
　図９において、Coordinator AP IDはCoordinator APとなるAPのIDを示す。例えば、AP1が、AP3をCoordinator APとしたCoordinated APとして動作している場合に、今回のMulti-APセットアップ動作(協調bitmapを用いた判定)の対象となるAPとしてAP1が選択された場合は、Coordinator AP IDはAP3のIDとしてもよい。Coordinator AP IDの代わりにCoordinatorか否かを示す情報(1bit)としてもよい。
　Coordinate Typeは、協調方式（C-TDMA、C-OFDMA、C-SR、CBF、JT、dynamic AP selection、等）を示してもよい。
　informationは、各協調方式での制御情報としてもよいし、動作可能な複数の協調方式の制御情報を含めてもよい。informationに含まれる情報は、例えば、C-TDMAの場合にはtime-slotまたは送信開始タイミング、及び送信区間でもよく、C-SR、CBF、またはJTの場合には最大干渉電力またはパスロス検出閾値（最大または最小値）でもよく、dynamic AP selectionの場合には切り替え検出電力閾値及び前方・後方保護回数でもよい。
　Multi-AP Setup RequestにMulti-AP Coordination GroupのIDが含まれてもよいし、Coordinator AP IDがMulti-AP Coordination GroupのIDとされてもよい。Multi-AP Setup RequestにCoordinated APリストが含まれてもよい。
　Multi-AP elementで規定したMulti-AP Setup Requestの例を示したが、Coordinator AP ID以下のfieldが、element以外のfieldとしてMulti-AP Setup frameに含まれてもよい。
　Multi-AP Setup Responseは、図９に示したフォーマットとしてもよいし、「候補に同意するか否か」または「候補に同意/変更要求/拒否」のいずれかを含むフォーマットとしてもよい。例えば、AP1がCoordinator APとなる場合は図９に示したフォーマットとし、AP1がCoordinated APとなる場合は「候補に同意するか否か」または「候補に同意/変更要求/拒否」のいずれかを含むフォーマットとする等、フォーマットを選択可能にしてもよい。
　Multi-AP Setup Responseに含めるCoordinate Typeは、AP1とAP2が共に動作可能な協調方式としてもよい。
＜実施例２＞
　実施例１では、Multi-APセットアップS501において、BeaconまたはProbe ResponseにMulti-APに関するCapability情報（例えば協調bitmap）が含まれる実施例を示したが、実施例２では、Multi-APセットアップS501において、Multi-AP Setup RequestにMulti-APに関するCapability情報（例えば協調bitmap）が含まれる実施例を示す。
　図１０に、Multi-APセットアップS501においてAP1とAP2とのネゴシエーションによってCoordinator APとして動作するか否かを決定する動作シーケンスの別の例を示す。
　S1001において、AP2は起動時に周辺APをサーチしてもよい。
　S1002において、AP2は、AP1が定期的に送信しているBeaconを受信する。AP2がProbe Requestを送信し、Probe Requestに応答してAP1が送信するProbe Responseを受信してもよい。
　S1003において、AP2は、AP1にMulti-AP Setup Requestを送信してもよい。この時、AP2は、送信するMulti-AP Setup Requestに協調bitmapを含めてもよい。この場合、Multi-AP Setup Requestフレームに、Multi-AP エレメント（一例として、図８に示したフレームフォーマット）を含めてもよい。
　S1004において、Multi-AP Setup Requestを受信したAP1は、Coordinator APを選択する。実施例１と同様に、受信したAP2の協調bitmap及びAP1の協調bitmapに相当する内部情報に基づいてCoordinator APが選択されてもよい。
　S1005において、AP1は、AP2にMulti-AP Setup Responseを送信してもよい。Multi-AP Setup Requestを受信したAP1は、協調通信の動作準備が完了した場合のみ、AP2にMulti-AP Setup Responseを送信してもよい。この場合、Multi-AP Setup Responseフレームに、Multi-AP エレメント（一例として、図９に示したフレームフォーマット）を含めてもよい。
　AP1が送信するBeacon又はProbe Responseに、例えば、協調通信の動作が可能か否かを示す協調通信動作可否フラグを追加してもよい。この場合、AP2はAP1の協調通信動作可否フラグが可の場合のみMulti-AP Setup Requestを送信することにより、無効なMulti-AP Setup Requestの送信を防ぐことができる。
　また、図１０において、AP1は、Multi-APの動作状態を示す情報をBeacon又はProbe Responseに含めて送信してもよい。
　図１０Aに、Multi-APの動作状態を示す情報のフォーマットの一例（Multi-AP Operationエレメント）を示す。
　Group IDフィールドは、Multi-APのグループのID(Multi-AP Group, Coordination Group等と呼ぶ)を含む。AP1が他のAPとMulti-APセットアップを行っていない場合、又はMulti-AP動作を終了した場合、Group IDフィールドの値を、IDとして利用しない特定の値(0またはや255等)に設定し、Multi-AP動作を開始していないことを他のAPに通知してもよい。また、Multi-AP動作中か否かを示すフィールド(図示せず)をMulti-AP Operationエレメントに含めてもよい。
　Coordinatorフィールドは、AP1がCoordinator APとして動作しているか否かを示す情報を含む。なお、Group IDフィールド及び/又は他のフィールドが、Multi-AP動作中ではないことを示す場合、Coordinatorフィールドは、AP1がCoordinator APとして動作可能か否かを示すとしてもよい。つまり、Multi-AP 動作中か否かによって、Coordinatorフィールドの意味を変更してもよい。
　Coordinated AP listフィールドは、Group IDフィールドによって示されるMulti-AP協調のグループに参加しているAPのID(BSSID、BSS color、MAC アドレス、MAC アドレスのハッシュ値、等)のリストを含む。
　Connectivity bitmapフィールドは、Coordinated AP listフィールドに示される各APが、Coordinator APと無線メディアによって直接通信可能か否かを示す情報を含んでよい。なお、Coordinator APと無線メディアによって直接通信可能ではないCoordinated APは、有線バックホール（イーサネット接続）等でCoordinator APと通信することによってMulti-AP 協調を行うことが期待されるので、Connectivity bitmapフィールドの代わりに、Coordinated AP listフィールドに示される各APが、Coordinator APと有線メディアによって通信を行うか否かを示す情報（例えば、Wired Backhaul bitmap フィールド）を含んでもよい。
　AP1がCoordinator APとして動作しない場合（未セットアップの場合を含む）、Coordinated AP listフィールド、Connectivity bitmapフィールドは省略されてもよい。
　実施例２によれば、定期的に送信しているBeaconが送信する情報量を、実施例１より少なくすることができる。
＜実施例３＞
　実施例１及び実施例２では、Multi-APセットアップS501において、協調bitmapによりCoordinator APを選択する実施例を示したが、実施例３では、Multi-APセットアップS501において、APが、Coordinator APとして動作可能か否か（以下、「Coordinator AP可否情報」という。）を周辺APに通知して、Coordinator APを選択する実施例を示す。
　図１１に、Multi-APセットアップS501において、AP1とAP2のネゴシエーションによってCoordinator APとして動作するか否かを決定する動作シーケンスのさらに別の例を示す。
　S1101において、AP2は起動時に周辺APをサーチしてもよい。
　S1102において、AP2は、AP1が定期的に送信しているBeaconを受信する。AP1は、送信するBeaconにCoordinator AP可否情報(Capability情報)を含めてもよい。AP2がProbe Requestを送信し、Probe Requestに応答してAP1が送信するProbe Responseを受信してもよい。この場合、Probe ResponseにCoordinator AP可否情報(Capability情報)を含めてもよい。
　S1103において、AP1が送信したBeacon又はProbe Responseを受信したAP2が、Beacon又はProbe Responseに含まれるCoordinator AP可否情報に基づいて協調通信の可否を判断してもよい。例えば、「AP1がCoordinator AP動作可かつAP2がCoordinator AP動作否」または「AP1がCoordinator AP動作否かつAP2がCoordinator AP動作可」の場合に協調通信可と判断してもよい。
　S1104において、AP2は、AP1にMulti-AP Setup Requestを送信してもよい。例えば、AP2が、協調通信可と判断した場合にMulti-AP Setup Requestを送信してもよい。Multi-AP Setup Requestは図９に示したフォーマットを用いてもよいし、図９から、Coordinator AP ID情報を除いたフォーマットを用いてもよいし、Coordinator AP ID情報の代わりにCoordinator APとして動作するか否かを示す情報を含めたフォーマットを用いてもよい。
　S1105において、AP1は、AP2にMulti-AP Setup Responseを送信してもよい。Multi-AP Setup Responseのフォーマットは前記Multi-AP Setup Requestと同じフォーマットとしてもよい。なお、Multi-AP Setup Responseに含めるCoordinate Typeは、AP1とAP2の両方が動作可能な協調方式としてもよい。Coordinator APまたはCoordinated APとしての協調通信の動作準備が完了したことを、Multi-AP Setup Responseで通知してもよい。Multi-AP Setup Responseの送信または受信によりCoordinator APまたはCoordinated APとしての協調通信の動作準備が完了したと判断してもよい。
＜変形例＞
　実施例１、実施例２、及び実施例３では、Multi-APセットアップS501でCoordinator APを決定する実施例を示したが、例えば、Multi-APセットアップS501においてCoordinator APが決定した後に、協調通信の制御情報を通知するAP（以降「AP間通信接続先AP」という）を決めてもよい。変形例は、実施例１、実施例２、及び実施例３のいずれとも、組合せることが可能である。
　例えば、実施例１において、AP1がCoordinator APの場合またはAP1がCoordination Groupに参加しているCoordinated APの場合であって、AP2がCoordinated APとなり、かつAP2が複数のAPと送受信可能である場合については、AP2がAP1に送信するときにどのAPに通知するのが最適であるか、をAP1がAP2に通知してもよい。たとえば、AP2が送受信可能AP情報（AP2が送受信可能な複数のAPの情報）をAP1に通知し、途中のAPも同様の動作を行うことにより、AP1が送受信可能AP情報を受信したとき、AP2からの転送回数及び転送時の受信品質の少なくとも１つに基づいて、AP2がAP1に送信するときのAP間通信接続先AP（最終目的APがAP1の場合に送信するAP）を、AP1が指定してもよい。この場合、AP2がAP1に通知する送受信可能AP情報をMulti-AP Setup Requestで通知し、AP1がAP2に通知するAP間通信接続先APをMulti-AP Setup Responseで通知してもよい。
　AP1以外がCoordinator APの場合は、Coordinator APとAP2との間で通知されるMulti-AP Setup Request及びMulti-AP Setup ResponseをAP1が転送してもよい。
　実施例１において、AP2がCoordinator APの場合またはAP2がCoordination Groupに参加しているCoordinated APの場合であって、AP1がCoordinated APとなり、かつAP1が複数のAPと送受信可能である場合については、AP1がAP2に送受信可能AP情報をMulti-AP Setup Responseで通知し、AP2がAP1に通知するAP間通信接続先APを、Categoryを協調AP指定として定義したMulti-AP Action frameで通知してもよい。
　なお、送受信可能AP情報を、Multi-AP Setup RequestまたはMulti-AP Setup Responseで通知し、AP間通信接続先APをMulti-AP Setup ResponseまたはCategoryを協調AP指定としたMulti-AP Action frameで、通知する動作例を示したが、送受信可能AP情報及びAP間通信接続先APは、共にCategoryを協調AP指定としたMulti-AP Action frameで通知してもよいし、その他のフレームで通知してもよい。
　送受信可能AP情報またはAP間通信接続先APの通知には、図１２に示したAP通知フォーマットを用いてもよい。
　図１２に示したAP通知フォーマットにおいて、AP IDフィールドは、送受信可能AP情報の場合は、送受信可能APのIDとしてもよい。AP IDは、AP間通信接続先APの場合は、AP間通信接続先APのIDとしてもよい。
　RSSIフィールドは、各送受信可能APの受信品質（例えば各APが送信するBeaconの受信電力やパスロス）としてもよい。Coordinator APによる最適なAPの選択に用いてもよい。AP間通信接続先を指定する応答ではRSSIが含まれなくてもよい。
　図１２ではMulti-AP elementにおいてType値を3（Type = 3）とした例を示したが、Multi-AP Setup RequestまたはMulti-AP Setup Responseに、例えばAP ID及びRSSIを加えたフォーマットとしてもよい。また、AP間通信接続先APの通知をする場合は、１つのAP IDのみを含めたフォーマットとしてもよい。
＜実施例４＞
　実施例３におけるAPのCoordinator AP可否情報は、上位レイヤにより指定されてもよい。
　図１３にMulti-APセットアップS501において、AP1、AP2の順に起動しAP2起動後にCoordinator APを選択する動作シーケンスの例を示す。
　S1301において、AP1では、起動時に上位レイヤであるSME(station management entity)が、下位レイヤであるMLME（MAC sublayer management entity）に、Multi-APパラメータ(Coordinator AP可否情報を含む)を含めたMLME-START.requestプリミティブを送信する。
　S1302において、MLME-START.requestを受信したAP1のMLMEが、周辺のAPが送信したBeaconを受信するか確認してもよい。本動作例では周辺APが送信したBeaconを受信しないので、定期的なBeacon(Coordinator AP可否情報を含む)の送信を開始してもよい。AP1によるBeaconの送信は定期的でなく、不定期でもよい。
　S1303において、Beaconの送信の開始と共に、AP1のSMEにMLME-START.confirmプリミティブを返信してもよい。
　S1304において、AP2では、起動時にAP1と同様に、AP2のMLMEがSMEからMLME-START.requestプリミティブを受信する。
　S1305において、AP2のMLMEが、周辺のAPが送信したBeaconを受信するかを確認してもよい。本動作例ではAP1が送信したBeaconを受信する。AP2がProbe Requestを送信し、Probe Requestに応答してAP1が送信するProbe Responseを受信してもよい。
　S1306において、AP2のMLMEは、MLME-START.requestプリミティブに含まれるCoordinator AP可否情報及びAP1が送信したBeacon又はProbe Responseに含まれるCoordinator AP可否情報に基づいて、協調通信の可否を判断する。例えば、AP2のMLMEは、「AP1がCoordinator AP動作可かつAP2がCoordinator AP動作否」または「AP1がCoordinator AP動作否かつAP2がCoordinator AP動作可」の場合に協調通信が可能であると判断してもよい。AP2が、協調通信が可能であると判断した場合にAP1にMulti-AP Setup Requestを送信してもよい。
　S1307において、AP1は、Multi-AP Setup Requestを受信した場合にAP2にMulti-AP Setup Responseを送信してもよい。
　S1308において、Multi-AP Setup Responseを受信したAP2は、MLMEが、SMEにMLME-START.confirmプリミティブを返信してもよい。なお、MLME-START.confirmプリミティブに協調通信の動作開始を示す情報を含めてもよい。
　なお、上位レイヤをSMEとしたが、SME以外の上位レイヤでもよく、例えばhostapdプログラム、ファームウェア、アクセスポイント管理プログラム、IEEE1905規格エンティティ、Wi-Fi規格に定められるTerminal、等であってもよい。
　AP1が、他Coordinator AP制御下のCoordinated APである場合には、Beacon又はProbe Responseで他Coordinator AP制御下のCoordinated APであることを通知してもよい。この場合、AP1が、AP2に対して、Beacon又はProbe Response又はMulti-AP Setup ResponseによりCoordinator APのIDを通知してもよい。
　Coordinator APは、他のCoordinated APが存在する場合にCoordinated APリストが更新されたことを通知してもよい。例えば、AP1がCoordinator APの場合、Coordinated APリストをMulti-AP Setup Responseフレームで通知してもよい。AP2がCoordinator APの場合、Coordinated APリストをMulti-AP Setup Requestフレームで通知してもよい。さらには、Coordinated APリストにCoordinated APのIDが含まれてもよい。
　実施例４では、実施例３におけるAPのCoordinator AP可否情報を、上位レイヤが通知する実施例を示したが、実施例１、実施例２、または変形例の動作例において、同様に上位レイヤが協調bitmapを通知してもよい。上位レイヤから通知される情報をCoordinator APの可否情報及びCoordinated APの可否情報とし、これら情報に基づいてMLMEで協調bitmapが作成されてもよい。また、上位レイヤから通知される情報に動作可能な協調方式が含まれてもよいし、通知される動作可能な協調方式が、例えば送信データの経路が関係する方式（例えばJTまたはdynamic AP selection等）に限定されてもよい。
＜実施例５＞
　図１４に、Multi-APセットアップS501において、バックホール通信を用いた動作例のフローチャートの例を示す。
　バックホール通信を用いた場合、他のAPが送信するBeaconを受信できない場合でもMulti-APの構成が可能となる。したがって、Beaconを受信できない場合でもCoordinator APであるかCoordinated APであるかを決定することが必要となる。
　S1401において、AP種別を決定する。AP種別決定は、SMEがAPの種別（CoordinatorまたはCoordinated AP）を決定してもよい。例えば、APがWi-Fi Easy MeshのコントローラAPとして動作を行う場合にCoordinator APと設定してもよいし、APがWi-Fi Easy MeshのエージェントAPとして動作を行う場合にCoordinated APと設定してもよい。
　AP種別決定S1401においてAPがCoordinated APと決定された場合(S1402がNoの場合)、S1403において、Coordinator AP検索によりバックホール接続可能なCoordinator APを発見し、S1404において、Coordinated APとして動作を開始し、Coordination Group参加手続きを行ってもよい。この場合、バックホール通信でCoordinator APにCoordination Group参加手続きを行ってもよい。「バックホール接続可能」とは、IP(Internet Protocol)通信できることであってもよいし、同一セグメント(サブネット)上の2以上のAPがIP通信できることであってもよい。「Coordination Group参加手続き」は、ID登録手続き、Capability交換手続き、及び認証手続きの少なくとも１つを含んでもよい。
　AP種別決定S1401においてAPがCoordinator APと決定された場合(S1402がYesの場合)、S1405においてCoordinated AP検索によりバックホール接続可能なCoordinated APを発見し、S1406において、Coordinator APとして動作を開始し、Coordination Groupを生成してもよい。この場合、バックホール通信でCoordinated APにCoordination Group参加手続きを行ってもよい。
　AP種別決定S1401によるCoordinator APおよびCoordinated APの判定結果、およびCoordination Group情報（Coordination GroupのIDやCoordinated APのリスト等）を、例えばSMEからMLMEに通知するMLME-START.requestに含めても良い。
　実施例１、実施例２、実施例３、変形例、及び実施例４で示したAP間通信をバックホール通信で行ってもよい。例えば、Coordinator APは、Coordinator AP動作開始以降にバックホール通信でCoordinated APからCoordination Group参加要求を受け付けてもよいし、Coordinator APは、参加可否を判定し、バックホール通信でCoordinated APに結果を通知してもよい。
　バックホール通信を行うバックホール送受信部を設けてもよいし、協調制御部406に入力される入力データおよび協調制御部406から出力される出力データ（図に記載なし）にバックホール通信で送受信する情報を含めても良い。
　Coordinator APは、Coordinator APのリストが更新されたことを、他のCoordinated APへバックホール通信で通知してもよく、通知を受信したCoordinated APでは、SMEからMLMEへ、更新されたリストを通知してもよい。例えば、新たに規定されるMLME-MULTIAP-RECONFIGURATION.requestに当該情報を含めて通知してもよい。
　以上、バックホール通信によるMulti-APセットアップの動作例を示したが、AP間通信によるMulti-APセットアップを同時に実施してもよい。
　例えば、図１４に示したCoordinator AP検索及びCoordinated AP検索において、他APからのBeacon受信、または他APへのProbe Request送信を行い、他APが存在する場合に実施例１～４に示したMulti-APセットアップ動作を行ってもよいし、受信したBeaconを送信したAPに対してバックホール通信によるMulti-APセットアップを行ってもよいし、バックホール通信によるMulti-APセットアップを行うAPをBeacon受信したAPに限定してもよい。
（実施の形態２）
　本発明の一形態では、AP及びSTAの状態により協調通信の動作（干渉の測定を含む）を開始する。
　STA及びAPの構成は実施の形態１で示した構成と同一でもよい。
＜実施例６＞
　図１５に、図５とは別の全体ステップを示す。AP1が設置されて定期的にBeaconを送信する状態で、新たにAP2が設置される場合の例を示している。各APは図１５に示すように、Multi-APセットアップS1501及び協調開始判定S1502後にMulti-AP測定S1503及びMulti-AP送信S1504を行う。
　図１５において、Multi-APセットアップS1501、Multi-AP測定S1503、及びMulti-AP送信S1504は実施の形態１と同じ動作としてもよい。協調開始判定S1502は、他APまたはSTAによる干渉の影響等、送信待ちが発生した場合に協調通信を開始すると判定してもよい。協調開始判定S1502の後にMulti-AP測定S1503及びMulti-AP送信S1504を開始してもよい。なお、送信待ちが発生したかどうかの判断は、送信バッファに記憶されている送信データが増大（送信キュー長の増加）した場合、またはデータ送信遅延が増大した場合に、送信待ちが発生したと判断してもよい。
　Coordinated APは、協調通信を開始すると判定した場合に、Coordinator APへ協調開始要求を通知してもよい。
　STAは、協調通信を開始すると判定した場合に、アソシエーションAPへ協調開始要求を通知してもよく、アソシエーションAPが、Coordinated APである場合はCoordinator APに協調開始要求を転送してもよい。
　協調開始要求には自身のID及び検出したAPのID（例えばBSS IDまたはBSS color）及び干渉パケットのUL/DL情報が加えられてもよい。受信した協調開始要求に含まれる情報に基づいてMulti-AP測定の対象が限定されてもよい。
　このように、送信待ちが発生した場合に協調通信を開始することにより、協調通信が必要な場合のみ干渉の測定を行うことによりSTAの消費電力を低減することができる。また、協調通信が必要な場合のみ干渉データの送信及び転送を行うことにより周波数利用効率を改善することができる。
　図１６は、APとSTAの配置例を示す図である。図１６は、STA1-1とSTA1-2がCoordinator APであるAP1にアソシエーションしており、STA2-1がCoordinated APであるAP2にアソシエーションしている配置例を示す。図１６の配置において、STA2-1が、AP1が送信している信号による干渉の影響によって送信が行えず送信待ちが発生した場合の動作を開示する。
　STA2-1は、送信待ちが発生したことを検出し、協調開始要求をアソシエーションAPであるAP2に通知する。協調開始要求には干渉信号の送信元情報（この例ではAP1）が含まれてもよい。Coordinated APであるAP2は、Coordinator APであるAP1にSTA2-1の協調開始要求を転送する。
　転送された協調開始要求を受信したAP1は、干渉を測定すると共に、AP2に対し干渉の測定を指示する。
　AP1及びAP2は、各々アソシエーションしているSTA（例えばSTA1-1及びSTA1-2、及びSTA2-1）に干渉を測定する指示をしてもよい。なお、干渉を測定する対象が一部のSTAに限定されてもよい。例えば、干渉を測定させるSTAを、動作する協調方式がC-SRの場合にパスロスの小さいSTA(例えばSTA1-1)及び協調開始要求を通知したSTA2-1に限定してもよい。前記干渉測定の結果に基づいてAP1が協調通信の動作を指定してもよい。例えばAP1が、AP1からSTA1-1への送信及びSTA2-1からAP2への送信を同時に行うC-SRを指定してもよい。
　なお、協調開始要求の通知を、協調AP（Coordinator AP及びcoordinated AP）及び協調APにアソシエーションしているSTAが送信している信号による干渉の影響がある場合に限定してもよい。この場合、事前に協調APリスト（協調APのBSS IDまたはBSS colorを含む）をSTAに通知してもよい。これにより、協調通信の対象外のAP及びSTAが送信した信号による干渉の影響による協調開始要求の通知を防ぐことが出来る。
　また、Multi-APセットアップS1501は、協調通信を開始する要求が発生した時に実施してもよい。これにより、協調通信を行うAPを対象としたMulti-APセットアップS1501を実施できる。また、不要なCoordination Groupの構築を防ぐことが出来る。
［フォーマット例］
　実施例６で示した協調開始要求はManagement frameの一種として定義されてもよい。協調開始要求は、例えばAction frameにおいて、Categoryを協調開始要求としたMulti-AP Action frameによって定義されてもよい。例えばMulti-AP elementにおいて、Type値が4（Type = 4）によって規定されてもよい。Multi-AP elementで規定された協調開始要求の例を図１７に示す。
　図１７において、AP/STA IDフィールドは、干渉の影響を受けたAPまたはSTAを示し、STAの場合はAID（Association ID）とし、APの場合は未使用AID（例えば4094）としてもよい。
　BSS IDフィールドは、干渉元のBSS IDまたはBSS colorとしてもよい。
　DL/ULフィールドは、干渉パケットのDL/UL情報であって、例えば「0:DL、1:UL、2:DL及びUL」としてもよい。なお、DL/ULがULまたはDL及びULの場合は図１７に示したフォーマットに送信元STA IDを追加してもよい。
（実施の形態３）
　本発明の一形態では、AP間で直接送受信できない位置にAPが配置された場合に、STAがAP間で通信する情報（協調制御情報等）を転送することでAP間の送受信を可能とする。STA及びAPの構成は実施の形態１で示した構成と同一でもよい。
＜実施例７＞
　図１８に、APとSTAの別の配置例を示す。図１８は、AP1及びAP1にアソシエーションしているSTA1が配置されている状態において、AP1とは直接送受信できないがSTA1とは直接送受信できる位置にAP2が新たに配置された場合を示す。図１８に示された配置において、AP1とAP2の間で送信する情報をSTA1が転送することにより、実施の形態１及び実施の形態２で示したMulti-AP協調動作を行う例を説明する。
　STA1は、新規に起動したAP2のBeaconを受信した場合、AP1に、AP2が配置されたことを通知（以下、協調候補AP通知という）してもよい。なお、通知の有無をAP2のBeaconに含まれるMulti-APに関するCapability情報（例えば協調動作可否フラグ）で判断してもよい。また、AP2またはAP2にアソシエートしているSTAによる干渉の影響がある場合等、STA1に送信待ちが発生した場合に通知してもよいし、協調APリストにAP2が含まれない場合に通知してもよい。
　協調候補AP通知を受信したAP1は、AP2への協調開始要求（例えば実施の形態1で示したMulti-AP Setup Request）をSTA1に送信し、STA1は、受信した協調開始要求をAP2に転送してもよい。なお、STA1がAP2と通信するため、STA1はAP2にもアソシエーションしてもよい。STA1がAP2にアソシエーションする時に、協調AP間制御データ転送が目的であることを示す情報（例えば転送を示すフラグやAP1のID等）を含めてもよいし、アソシエーションする時に送信する信号に協調開始要求を含めてもよい。
　以降、実施の形態１及び実施の形態２で示した、協調通信におけるAP1とAP2の間の通信をSTA1経由した通信としてもよい。
　このように、直接送受信できないAP間であってもSTAを経由して通信を行うことで協調動作を行うことができる。
（実施の形態４）
　実施の形態１、実施の形態２、及び実施の形態３で示したMulti-AP協調通信に適用される協調方式がDynamic AP selectionの場合は、以下に示す動作としてもよい。
　図１９に、APとSTAのさらに別の配置例を示す。図１９に、協調方式としてDynamic AP selectionが動作可能なAP1及びAP2が、同じCoordination Groupに参加していて、かつSTA1がAP1にアソシエーションした後にAP2の方向に移動した場合の動作例を示す。
　AP1及びAP2は、実施の形態１、実施の形態２、及び実施の形態３で示したMulti-APセットアップS501により、協調方式としてdynamic AP selectionが選択された。
　STA1は、dynamic AP selectionの切り替え候補としてAP2にアソシエーションしてもよい。例えば、協調APリストにAP2が含まれる場合及び／またはAP2が送信する信号（例えばBeacon）の受信電力がある閾値を超えた場合に、STA1がアソシエーションを行ってもよい。また、AP1がdynamic AP selectionが可能なAPのリストを事前にSTA1に通知し、STA1が受信したAPのリストにAP2が含まれる場合に、STA1がアソシエーションを行ってもよい。
　このように、Multi-APセットアップで協調通信の対象となるAPを特定することによりdynamic AP selectionを実行できる。また、dynamic AP selectionを行う可能性が高いSTAが切り替え候補先APにアソシエーションを行うことで、不要なアソシエーションを防ぐことができる。
　なお、STA1がAP2に通知するアソシエーション要求に、dynamic AP selectionの移動先候補であることを示す情報を含めてもよいし、STA1が現在アソシエーションしているＡＰ（例えばAP1）のID及びSTA1のID（例えばAP1が割り当てたAID）を含めてもよい。これにより切り替え候補先APが切り替え元APを特定することが出来る。
　また、AP2がSTA1に通知するアソシエーション応答にdynamic AP selectionの可否情報及び／またはランク情報を含めてもよい。ランク情報は、例えば、送信済みパケット情報がAP1及びAP2で共有可能な場合をランク１、共有不可な場合をランク２としてもよい。STA1はランクに応じてdynamic AP selectionのパラメータ（例えば、切り替え動作開始を判定するためのAP1受信電力とAP2受信電力の差の閾値、または切り替え実施の前方後方保護の回数）を変更してもよい。例えば、ランク１は容易に切り替えが実施される値としてもよい。これにより、切り替え先AP及び切り替え元APの機能に応じた切り替えをすることができる。
　また、STA1が、送受信先切り替え要求をAP1(切り替え元AP)及びAP2(切り替え先AP)に通知してもよい。
　また、AP1が切り替え要求をしてもよい。この場合、Multi-AP測定S1503（STA1のAP2による干渉の測定）の結果に基づいて切り替え要求をしてもよい。
　また、AP1とAP2が含まれるBSS（仮想BSS）を設けてもよい。この場合、STA1は前記AP2へのアソシエーションの代わりに仮想BSSへのアソシエーションを行ってもよい。
　以上、図面を参照しながら実施の形態について説明したが、本開示はかかる例に限定されない。当業者であれば、特許請求の範囲に記載された範疇において、各種の変更例又は修正例に想到し得ることは明らかである。そのような変更例又は修正例についても、本開示の技術的範囲に属するものと了解される。また、本開示の趣旨を逸脱しない範囲において、実施の形態における各構成要素は任意に組み合わされてよい。
　上述の実施の形態においては、各構成要素に用いる「・・・部」という表記は、「・・・回路（circuitry）」、「・・・アッセンブリ」、「・・・デバイス」、「・・・ユニット」、又は、「・・・モジュール」といった他の表記に置換されてもよい。
　本開示はソフトウェア、ハードウェア、又は、ハードウェアと連携したソフトウェアで実現することが可能である。上記実施の形態の説明に用いた各機能ブロックは、部分的に又は全体的に、集積回路であるＬＳＩとして実現され、上記実施の形態で説明した各プロセスは、部分的に又は全体的に、一つのＬＳＩ又はＬＳＩの組み合わせによって制御されてもよい。ＬＳＩは個々のチップから構成されてもよいし、機能ブロックの一部又は全てを含むように一つのチップから構成されてもよい。ＬＳＩはデータの入力と出力を備えてもよい。ＬＳＩは、集積度の違いにより、ＩＣ、システムＬＳＩ、スーパーＬＳＩ、ウルトラＬＳＩと呼称されることもある。
　集積回路化の手法はＬＳＩに限るものではなく、専用回路、汎用プロセッサー又は専用プロセッサーで実現してもよい。また、ＬＳＩ製造後に、プログラムすることが可能なＦＰＧＡ（Field Programmable Gate Array）や、ＬＳＩ内部の回路セルの接続や設定を再構成可能なリコンフィギュラブル・プロセッサーを利用してもよい。本開示は、デジタル処理又はアナログ処理として実現されてもよい。
　さらには、半導体技術の進歩又は派生する別技術によりＬＳＩに置き換わる集積回路化の技術が登場すれば、当然、その技術を用いて機能ブロックの集積化を行ってもよい。バイオ技術の適用等が可能性としてありえる。
　本開示は、通信機能を持つあらゆる種類の装置、デバイス、システム（通信装置と総称）において実施可能である。通信装置は無線送受信機（トランシーバー）と処理／制御回路を含んでもよい。無線送受信機は受信部と送信部、又はそれらを機能として、含んでもよい。無線送受信機（送信部、受信部）は、ＲＦ（Ｒａｄｉｏ　Ｆｒｅｑｕｅｎｃｙ）モジュールと１又は複数のアンテナを含んでもよい。ＲＦモジュールは、増幅器、ＲＦ変調器／復調器、又はそれらに類するものを含んでもよい。通信装置の、非限定的な例としては、電話機（携帯電話、スマートフォン等）、タブレット、パーソナル・コンピューター（ＰＣ）（ラップトップ、デスクトップ、ノートブック等）、カメラ（デジタル・スチル／ビデオ・カメラ等）、デジタル・プレーヤー（デジタル・オーディオ／ビデオ・プレーヤー等）、着用可能なデバイス（ウェアラブル・カメラ、スマートウオッチ、トラッキングデバイス等）、ゲーム・コンソール、デジタル・ブック・リーダー、テレヘルス・テレメディシン（遠隔ヘルスケア・メディシン処方）デバイス、通信機能付きの乗り物又は移動輸送機関（自動車、飛行機、船等）、及び上述の各種装置の組み合わせがあげられる。
　通信装置は、持ち運び可能又は移動可能なものに限定されず、持ち運びできない又は固定されている、あらゆる種類の装置、デバイス、システム、例えば、スマート・ホーム・デバイス（家電機器、照明機器、スマートメーター又は計測機器、コントロール・パネル等）、自動販売機、その他ＩｏＴ（Ｉｎｔｅｒｎｅｔ　ｏｆ　Ｔｈｉｎｇｓ）ネットワーク上に存在し得るあらゆる「モノ（Things）」をも含む。
　通信には、セルラーシステム、無線ＬＡＮシステム、通信衛星システム等によるデータ通信に加え、これらの組み合わせによるデータ通信も含まれる。
　また、通信装置には、本開示に記載される通信機能を実行する通信デバイスに接続又は連結される、コントローラやセンサ等のデバイスも含まれる。例えば、通信装置の通信機能を実行する通信デバイスが使用する制御信号やデータ信号を生成するような、コントローラやセンサが含まれる。
　また、通信装置には、上記の非限定的な各種装置と通信を行う、あるいはこれら各種装置を制御する、インフラストラクチャ設備、例えば、基地局、アクセスポイント、その他あらゆる装置、デバイス、システムが含まれる。
　また、近年、ＩｏＴ（Ｉｎｔｅｒｎｅｔ　ｏｆ　Ｔｈｉｎｇｓ）技術において、フィジカル空間とサイバー空間の情報連携により新たな付加価値を作りだすという新しいコンセプトであるＣＰＳ（Ｃｙｂｅｒ　Ｐｈｙｓｉｃａｌ　Ｓｙｓｔｅｍｓ）が注目されている。上記の実施の形態においても、このＣＰＳコンセプトを採用することができる。
　すなわち、ＣＰＳの基本構成として、例えば、フィジカル空間に配置されるエッジサーバと、サイバー空間に配置されるクラウドサーバとを、ネットワークを介して接続し、双方のサーバに搭載されたプロセッサーにより、処理を分散して処理することが可能である。ここで、エッジサーバ又はクラウドサーバにおいて生成される各処理データは、標準化されたプラットフォーム上で生成されることが好ましく、このような標準化プラットフォームを用いることで、各種多様なセンサ群やＩｏＴアプリケーションソフトウェアを含むシステムを構築する際の効率化を図ることができる。
　（１）本開示の一実施例に係るアクセスポイントは、協調通信に関する情報を受信する送受信部と、協調通信を制御するアクセスポイントとして動作するか否かを決定する制御回路と、を有する。
　（２）本開示の一実施例に係るアクセスポイントは、（１）のアクセスポイントにおいて、前記送受信部が受信する前記協調通信に関する情報は、他のアクセスポイントから受信する情報であって、前記送受信部は、前記他のアクセスポイントに対して、協調通信に関する情報を送信し、前記制御回路は、前記他のアクセスポイントとのネゴシエーションによって協調通信を制御するアクセスポイントとして動作するか否かを決定する。
　（３）本開示の一実施例に係るアクセスポイントは、（２）のアクセスポイントにおいて、前記他のアクセスポイントから受信する協調通信に関する情報または前記他のアクセスポイントに対して送信する協調通信に関する情報は、協調bitmapである。
　（４）本開示の一実施例に係るアクセスポイントは、（１）のアクセスポイントにおいて、前記送受信部は、他のアクセスポイントに対して、協調通信を制御するアクセスポイントとして動作可能か否かを送信する。
　（５）本開示の一実施例に係るアクセスポイントは、（１）のアクセスポイントにおいて、前記制御回路は、上位レイヤが協調通信を制御するアクセスポイントとして動作するか否かを指定する。
　（６）本開示の一実施例に係るアクセスポイントは、（１）のアクセスポイントにおいて、前記送受信部が受信する、前記協調通信に関する情報は、協調方式を含み、他のアクセスポイントから受信される情報であって、前記制御回路は、動作可能な協調方式に基づいて、協調通信の協調方式を決定する。
　（７）本開示の一実施例に係るアクセスポイントは、（１）のアクセスポイントにおいて、前記制御回路は、他のアクセスポイントまたは端末による干渉測定の結果に基づいて、協調通信を開始すると判定する。
　（８）本開示の一実施例に係るアクセスポイントは、（１）のアクセスポイントにおいて、前記送受信部は、端末から、他のアクセスポイントが送信した協調通信に関する情報を受信する。
　（９）本開示の一実施例に係るアクセスポイントは、（１）のアクセスポイントにおいて、端末から、dynamic AP selectionの移動先候補であることを示す情報、または現在アソシエーションしているアクセスポイントのID及び端末のID、が含まれるアソシエーションを受信することにより、Dynamic AP selectionの切り替え元アクセスポイントを特定する。
　（１０）本開示の一実施例に係る協調通信の制御方法は、アクセスポイントが、協調通信に関する情報を受信し、協調通信を制御するアクセスポイントとして動作するか否かを決定する。
　２０２２年１０月７日出願の特願２０２２－１６２３９２の日本出願に含まれる明細書、図面および要約書の開示内容は、すべて本願に援用される。
　本開示は、協調通信に有用である。
　３０１、４０１：送信パケット生成部
　３０２、４０２：制御信号生成部
　３０３、４０３：無線送受信部
　３０４、４０４：受信パケット復号部
　３０５、４０５：受信品質測定部
　３０６、４０７：制御回路
　４０６：協調制御部
 

Claims (10)

  1. 　協調通信に関する情報を受信する送受信部と、
    　協調通信を制御するアクセスポイントとして動作するか否かを決定する制御回路と、
    　を有するアクセスポイント。
  2. 　前記送受信部が受信する前記協調通信に関する情報は、他のアクセスポイントから受信する情報であって、
    　前記送受信部は、前記他のアクセスポイントに対して、協調通信に関する情報を送信し、
    　前記制御回路は、前記他のアクセスポイントとのネゴシエーションによって協調通信を制御するアクセスポイントとして動作するか否かを決定する、
    　請求項１に記載のアクセスポイント。
  3. 　前記他のアクセスポイントから受信する協調通信に関する情報または前記他のアクセスポイントに対して送信する協調通信に関する情報は、協調bitmapである、
    　請求項２に記載のアクセスポイント。
  4. 　前記送受信部は、他のアクセスポイントに対して、協調通信を制御するアクセスポイントとして動作可能か否かを示す情報を送信する、
    　請求項１に記載のアクセスポイント。
  5. 　前記制御回路は、上位レイヤが協調通信を制御するアクセスポイントとして動作するか否かを指定する、
    　請求項１に記載のアクセスポイント。
  6. 　前記送受信部が受信する、前記協調通信に関する情報は、協調方式を含み、他のアクセスポイントから受信される情報であって、
    　前記制御回路は、動作可能な協調方式に基づいて、協調通信の協調方式を決定する、
    　請求項１に記載のアクセスポイント。
  7. 　前記制御回路は、他のアクセスポイントまたは端末による干渉測定の結果に基づいて、協調通信を開始すると判定する、
    　請求項１に記載のアクセスポイント。
  8. 　前記送受信部は、端末から、他のアクセスポイントが送信した協調通信に関する情報を受信する、
    　請求項１に記載のアクセスポイント。
  9. 　前記制御回路は、端末から、dynamic AP selectionの移動先候補であることを示す情報、または現在アソシエーションしているアクセスポイントのID及び端末のID、が含まれるアソシエーションを受信することにより、Dynamic AP selectionの切り替え元アクセスポイントを特定する、
    　請求項１に記載のアクセスポイント。
  10. 　アクセスポイントが、協調通信に関する情報を受信し、協調通信を制御するアクセスポイントとして動作するか否かを決定する、協調通信の制御方法。
     
PCT/JP2023/036276 2022-10-07 2023-10-04 アクセスポイント及び協調通信の制御方法 WO2024075793A1 (ja)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2022-162392 2022-10-07
JP2022162392 2022-10-07

Publications (1)

Publication Number Publication Date
WO2024075793A1 true WO2024075793A1 (ja) 2024-04-11

Family

ID=90608192

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2023/036276 WO2024075793A1 (ja) 2022-10-07 2023-10-04 アクセスポイント及び協調通信の制御方法

Country Status (1)

Country Link
WO (1) WO2024075793A1 (ja)

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2022190677A1 (ja) * 2021-03-12 2022-09-15 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ 端末、アクセスポイント、及び、通信方法

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2022190677A1 (ja) * 2021-03-12 2022-09-15 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ 端末、アクセスポイント、及び、通信方法

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
WOOK BONG LEE (SAMSUNG): "Virtual BSS For Multi AP Coordination", IEEE DRAFT; 11-19-1019-00-00BE-VIRTUAL-BSS-FOR-MULTI-AP-COORDINATION, IEEE-SA MENTOR, PISCATAWAY, NJ USA, vol. 802.11 EHT; 802.11be, no. 0, 8 July 2019 (2019-07-08), Piscataway, NJ USA , pages 1 - 12, XP068152793 *

Similar Documents

Publication Publication Date Title
US9877181B2 (en) Device discovery method and communication device thereof
KR101719736B1 (ko) 무선 시스템에서 밀리미터파 무선 채널 상의 애드혹 통신을 위한 방법 및 시스템
US9699715B2 (en) Discovery method and device in a wireless communication system
JP6294351B2 (ja) 無線通信システムにおけるサービス転換方法及び装置
KR102081936B1 (ko) 와이파이 다이렉트 네트워크를 통한 지원 서비스 탐색 방법 및 디바이스
JP5526236B2 (ja) 無線通信ネットワーク内でのピア発見のための方法および装置
EP2522194B1 (en) Method and apparatus for assisted/coordinated intra-home communications
US7924831B2 (en) Procedure of setting up peer link in wireless mesh network and wireless station supporting the same
WO2019056970A1 (zh) 通信方法及装置
US9807677B2 (en) Service discovery method and device in wireless LAN system
JP2016158249A (ja) 拡張サービスセットを通じた直接リンク設定
KR101421732B1 (ko) 메쉬 네트워크의 설정을 위한 능동 스캔 방법
KR101670753B1 (ko) 와이파이 다이렉트(Wi- Fi Direct) P2P(Peer to Peer) 통신을 위한 기기 발견 방법 및 이를 위한 장치
JP2006524958A (ja) 自己構成と自己最適化とを行うワイヤレスローカルエリアネットワークシステム
CN104854953A (zh) 用于无线通信系统中的会话初始化的方法和设备
CN107852590B (zh) 在无线通信系统中执行发现的方法和装置
JP6599541B2 (ja) 無線通信システムにおいてアプリケーションサービスプラットホームセッション形成方法及び装置
US10397837B2 (en) Method and device for performing session handover in wireless communication system
US20230363058A1 (en) Communication apparatus, control method, and computer-readable storage medium
KR102424844B1 (ko) 외부 장치와의 무선 p2p 통신을 지원하는 전자 장치 및 그 전자 장치의 통신 방법
US20180077738A1 (en) Method and apparatus for establishing application service platform session in wireless communication system
US11064003B2 (en) Method and apparatus for receiving streaming via transport protocol in wireless communication system
WO2024075793A1 (ja) アクセスポイント及び協調通信の制御方法
WO2022017303A1 (zh) 用于无线通信系统的电子设备、方法和存储介质
WO2024127786A1 (ja) アクセスポイント及び協調通信の制御方法

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 23874918

Country of ref document: EP

Kind code of ref document: A1