Method and electronic device for multi-AP coordination based on information on service

Abstract

A method for operating an electronic device according to an embodiment may comprise an operation of identifying a service through the electronic device. The method may comprise an operation of negotiating multi-AP coordination for the service. The method may comprise an operation of receiving traffic of the service through the multi-AP coordination.

Description

Multi-AP cooperation method and electronic device based on information about service

[0001] Embodiments of the present invention relate to a multi-AP cooperation method and electronic device based on information about a service.

[0002] Wi-Fi has grown in popularity over the past decade, fueled by the emergence of mobile devices such as laptops, smartphones, and tablets. As Wi-Fi adoption has grown, so has the demand for faster wireless networks. Consequently, Wi-Fi has evolved over the generations. The latest Wi-Fi technology, currently standardized and commercialized, is Wi-Fi 6, and standardization for the next-generation technology, Wi-Fi 7, is currently underway within the relevant task group.

[0003] Discussions on the next-generation Wi-Fi standard beyond Wi-Fi 7 began in early 2023. Discussions are currently underway at the study group stage, the stage preceding the task group stage, where the actual standardization process begins. Various technologies are being discussed as candidates, and one of the key technologies with a high probability of inclusion in the standard is multi-AP coordination. Multi-AP coordination allows electronic devices to transmit and receive data with multiple access points (APs).

[0004] An electronic device according to one embodiment may include one or more wireless communication circuits configured to transmit and receive wireless signals, one or more processors operatively connected to the wireless communication circuits, and one or more memories electrically connected to the processors and storing instructions. The instructions may be individually or collectively executed by the processors to cause the electronic device to transmit a request frame requesting multi-AP coordination for a service through the electronic device to an access point (AP) associated with the electronic device. The instructions may be individually or collectively executed by the processors to cause the electronic device to receive a response frame to the request frame through the AP. The above instructions may be individually or collectively executed by the processor to cause the electronic device to communicate traffic of the service through the multi-AP cooperation.

[0005] An electronic device according to one embodiment may include one or more wireless communication circuits configured to transmit and receive wireless signals, one or more processors operatively connected to the wireless communication circuits, and one or more memories electrically connected to the processors and storing instructions. The instructions may be individually or collectively executed by the processors to cause the electronic device to transmit a request frame requesting multi-AP coordination including traffic flow information of a service to an access point (AP) associated with the electronic device. The instructions may be individually or collectively executed by the processors to cause the electronic device to receive a response frame to the request frame through the AP. The above instructions may be individually or collectively executed by the processor to cause the electronic device to receive traffic of the service through the multi-AP cooperation.

[0006] A method of operating an electronic device according to one embodiment may include an operation of identifying a service through the electronic device. The method may include an operation of negotiating multi-AP coordination for the service. The method may include an operation of receiving traffic for the service through the multi-AP coordination.

[0007] Figure 1 illustrates an example of a wireless LAN system according to one embodiment.

[0008] Figure 2 illustrates an example of a wireless LAN system according to one embodiment.

[0009] FIG. 3 is a diagram illustrating an example of a link setup operation according to one embodiment.

[0010] FIG. 4 is a diagram illustrating an example of multi-AP cooperation according to one embodiment.

[0011] FIGS. 5A and 5B are diagrams illustrating operation modes for multi-AP cooperation according to one embodiment.

[0012] FIG. 6 is a diagram illustrating negotiation for multi-AP cooperation according to one embodiment.

[0013] FIG. 7a is a diagram illustrating a negotiation process for multi-AP cooperation according to one embodiment, and FIG. 7b shows an example of a format of a request frame requesting multi-AP cooperation according to one embodiment.

[0014] Figures 8a to 8d illustrate examples of elements for specifying information about a service according to one embodiment.

[0015] FIG. 9 is a diagram for explaining information about an AP included in a request frame requesting multi-AP cooperation according to one embodiment.

[0016] FIG. 10 is a block diagram of an electronic device within a network environment according to one embodiment.

[0017] Hereinafter, embodiments will be described in detail with reference to the attached drawings. In the description with reference to the attached drawings, identical components are assigned the same reference numerals regardless of the drawing numbers, and redundant descriptions thereof will be omitted.

[0018]

[0019] FIG. 1 is a drawing for explaining an example of a wireless LAN system according to one embodiment.

[0020] Referring to FIG. 1, according to one embodiment, a wireless LAN system (10) may represent an infrastructure mode in which an access point (AP) exists in the structure of a wireless LAN (WLAN) of the Institute of Electrical and Electronic Engineers (IEEE) 802.11. The wireless LAN system (10) may include one or more basic service sets (BSS) (e.g., BSS1, BSS2). The BSS (BSS1, BSS2) may mean a set of an access point (AP) and a station (STA) (e.g., an electronic device (1001), an electronic device (1002), and an electronic device (1004) of FIG. 10) that are capable of communicating with each other by being synchronized. BSS1 may include AP1 and STA1, and BSS2 may include AP2, STA2, and STA3.

[0021] According to one embodiment, a wireless LAN system (10) may include at least one STA (STA1 to STA3), a plurality of APs (AP1, AP2) providing a distribution service, and a distribution system (100) connecting the plurality of APs (AP1, AP2). The distribution system (100) may connect a plurality of BSSs (BSS1, BSS2) to implement an extended service set (ESS). The ESS may be used as a term indicating a network formed by connecting a plurality of APs (AP1, AP2) through the distribution system (100). A plurality of APs (AP1, AP2) included in a single ESS may have the same SSID (service set identification).

[0022] According to one embodiment, STAs (STA1 to STA3) may be any functional medium including medium access control (MAC) and a physical layer interface for a wireless medium according to the Institute of Electrical and Electronics Engineers (IEEE) 802.11 standard. STAs (STA1 to STA3) may be used to mean both APs and non-AP STAs. STAs (STA1 to STA3) may also be referred to by various names, such as electronic devices, mobile terminals, wireless devices, wireless transmit / receive units (WTRUs), user equipment (UEs), mobile stations (MSs), mobile subscriber units, or simply users.

[0023]

[0024] FIG. 2 is a drawing for explaining an example of a wireless LAN system according to one embodiment.

[0025] Referring to FIG. 2, according to one embodiment, unlike the wireless LAN system (10) of FIG. 1, the wireless LAN system (20) may represent an ad-hoc mode in which communication is performed by establishing a network between a plurality of STAs (STA1 to STA3) without an AP in the structure of a wireless LAN (WLAN) of the Institute of Electrical and Electronic Engineers (IEEE) 802.11. The wireless LAN system (20) may include a BSS operating in an ad-hoc mode, i.e., an independent basic service set (IBSS).

[0026] In one embodiment, an IBSS may not have a centralized management entity because it does not include APs. In an IBSS, STAs may be managed in a distributed manner. In an IBSS, all STAs may be mobile, and access to distributed systems is not permitted, creating a self-contained network.

[0027]

[0028] FIG. 3 is a diagram illustrating an example of a link setup operation according to one embodiment.

[0029] Referring to FIG. 3, according to one embodiment, a link setup operation may be performed between devices (e.g., STA (301), AP (401)) to communicate with each other. For link setup, a network may be discovered, authentication may be performed, an association may be established, and a security configuration operation may be performed. The link setup operation may be referred to as a session initiation operation or a session setup operation. In addition, the link setup operation's discovery, authentication, association, and security configuration operations may be collectively referred to as an association operation.

[0030] According to one embodiment, the network discovery operation may include operations 310 and 320. In operation 310, the STA (301) (e.g., the electronic device (1001), the electronic device (1002), or the electronic device (1004) of FIG. 10) may transmit a probe request frame to search for an AP and wait for a response to the probe request frame. The STA (301) may perform a scanning operation to access a network to find a network to which it can join. The probe request frame may include information of the STA (301) (e.g., a device name and / or address of the STA (301)). The scanning operation in operation 310 may mean an active scanning operation. In operation 320, the AP (401) may transmit a probe response frame to the STA (301) that transmitted the probe request frame in response to the probe request frame. The probe response frame may include information about the AP (401) (e.g., the device name and / or network information of the AP (401)). Although the network discovery operation in FIG. 3 is illustrated as being performed through active scanning, it is not necessarily limited thereto, and if the STA (301) performs passive scanning, the operation of transmitting the probe request frame may be omitted. The STA (301) performing passive scanning may receive the beacon frame transmitted by the AP (401) and perform the following subsequent procedures.

[0031] According to one embodiment, after the STA (301) discovers a network, an authentication operation including operations 330 and 340 may be performed. In operation 330, the STA (301) may transmit an authentication request frame to the AP (401). In operation 340, the AP (401) may determine whether to allow authentication for the STA (301) based on information included in the authentication request frame. The AP (401) may provide the result of the authentication process to the STA (301) through an authentication response frame. The authentication frame used for the authentication request / response may correspond to a management frame.

[0032] According to one embodiment, the authentication frame may include information about an authentication algorithm number, an authentication transaction sequence number, a status code, a challenge text, a robust security network (RSN), or a finite cyclic group.

[0033] According to one embodiment, after STA (301) is successfully authenticated, an association operation including operations 350 and 360 may be performed. In operation 350, STA (301) may transmit an association request frame to AP (401). In operation 360, AP (401) may transmit an association response frame to STA (301) in response to the association request frame.

[0034] According to one embodiment, the association request frame and / or the association response frame may include information related to various capabilities. For example, the association request frame may include information related to various capabilities, a beacon listen interval, a service set identifier (SSID), supported rates, supported channels, an RSN, a mobility domain, supported operating classes, a traffic indication map broadcast request, and / or information about interworking service capabilities. For example, the association response frame may include information related to various capabilities, status codes, association ID (AID), supported rates, enhanced distributed channel access (EDCA) parameter sets, received channel power indicator (RCPI), received signal to noise indicator (RSNI), mobility domains, timeout interval (association comeback time), overlapping BSS scan parameters, TIM broadcast response, and / or QoS maps.

[0035] According to one embodiment, after STA (301) is successfully associated with the network, a security setup operation including operations 370 and 380 may be performed. The security setup operation may be performed via a robust security network association (RSNA) request / response. For example, the security setup operation may include an operation of setting up a private key via a four-way handshaking via an extensible authentication protocol over LAN (EAPOL) frame. The security setup operation may also be performed according to a security method not defined in the IEEE 802.11 standard.

[0036] According to one embodiment, a security session is established between STA (301) and AP (401) according to a security setup operation, and STA (301) and AP (401) can perform secure data communication.

[0037]

[0038] FIG. 4 is a diagram illustrating an example of multi-AP cooperation according to one embodiment.

[0039] Referring to FIG. 4, a wireless LAN system (30) (e.g., the wireless LAN system (10) of FIG. 1, the wireless LAN system (20) of FIG. 2) may include one or more STAs (e.g., STAs (301)), multiple APs (e.g., APs (401) and APs (405)), and an AP controller (500). In the wireless LAN system (30), multi-AP cooperation (or multi-AP coordination) may be performed. Multi-AP cooperation may refer to a method of transmitting a signal to an STA (e.g., STA (301)) using multiple APs (e.g., APs (401) and APs (405)). For example, the STA (301) may perform data transmission and reception with the AP (401) and the AP (405) while being connected to the AP (401). In multi-AP cooperation, a signal from an AP (405) no longer causes interference to an STA (301) connected to the AP (401), but becomes a desired signal. Multi-AP cooperation may include transmission methods such as distributed MIMO, C-OFDMA, coordinated beamforming, and coordinated spatial reuse. Although FIG. 4 illustrates multi-AP cooperation using two APs (401) and an AP (405), it is not necessarily limited thereto, and the number of APs in multi-AP cooperation according to an embodiment may be three or more. Multi-AP cooperation is not limited to the structure illustrated in FIG. 4, and may be performed in various forms.

[0040] According to one embodiment, the multi-AP cooperation technology may be a method of minimizing interference between BSSs during data transmission and reception by sharing information (e.g., link information, channel feedback information, scheduling information) about STAs required for multi-AP cooperation between APs (e.g., AP (401) and AP (405)) when transmitting and receiving data between STAs (e.g., STA (301)) and APs (e.g., AP (401) and AP (405)), or increasing data transmission efficiency by having two or more APs (e.g., AP (401) and AP (405)) participate in data transmission and reception for STAs (e.g., STA (301)) at a specific time. In order to transmit data simultaneously using multiple APs (e.g., AP (401) and AP (405)) in a wireless LAN system (30), a multi-AP cooperation environment must be created so that multiple APs (e.g., AP (401) and AP (405)) can be coordinated. In order for APs to be coordinated, a link between APs (e.g., AP (401) and AP (405)) must be formed, and information necessary for multi-AP cooperation, such as information about STAs (e.g., STA (301)) associated with each AP (e.g., AP (401) and AP (405)) (e.g., link information, channel feedback information, scheduling information), must be shared.

[0041] According to one embodiment, the AP controller (500) may perform a role of managing and controlling (or coordinating) a plurality of APs (e.g., AP (401) and AP (405)) existing in the wireless LAN system (30). The AP controller (500) may manage information on a BSS configured by each of the plurality of APs (e.g., AP (401) and AP (405)) and / or information on an STA associated with the BSS.

[0042] According to one embodiment, the AP controller (500) can initiate and control multi-AP cooperation. For example, the AP controller (500) can group or select APs (e.g., AP (401) and AP (405)) that will perform multi-AP cooperation with the STA (301), and manage the link with the APs (e.g., AP (401) and AP (405)) that will perform multi-AP cooperation so that information can be shared between the APs (e.g., AP (401) and AP (405)) that will perform multi-AP cooperation.

[0043] According to one embodiment, the AP (e.g., AP (401), AP (405)) can perform the same function as the AP that can form the BSS in the wireless LAN system (30), can be coordinated by the AP controller (500), and can participate in multi-AP cooperation. For example, the AP (e.g., AP (401), AP (405)) can form an association with the AP controller (500) and share information (e.g., control information, management information, data traffic) with the AP controller (500).

[0044] According to one embodiment, STA (301) may be associated with one AP (e.g., AP (401)) among APs (e.g., AP (401) and AP (405)) participating in multi-AP cooperation. In multi-AP cooperation, APs (e.g., AP (401) and AP (405)) may be capable of direct transmission and reception with AP controller (500), and STA (301) may be capable of direct transmission and reception with APs (e.g., AP (401) and AP (405)) participating in multi-AP cooperation. In FIG. 4, the AP controller (500) and STA (301) are illustrated as not being capable of direct transmission and reception with each other, but the AP controller (500) may be aware of the presence of STA (301). According to one embodiment, the AP controller (500) and STA (301) may be capable of direct transmission and reception with each other.

[0045] According to one embodiment, the AP controller (500) may be referred to as a master AP or a sharing AP, and the APs (e.g., AP (401), AP (405)) that can participate in multi-AP cooperation may be referred to as slave APs or shared APs. The AP controller (500) and the APs (e.g., AP (401), AP (405)) that can participate in multi-AP cooperation may be replaced with various expressions.

[0046] In one embodiment, multi-AP cooperation can provide user experience benefits by maintaining a constant latency time that is inconsistent due to interference or fading. In non-real-time service usage situations, it is difficult for users to perceive the benefits of multi-AP cooperation, but in real-time service usage situations, users can obtain meaningful user experience improvements through multi-AP cooperation. Real-time services may refer to latency-sensitive services (e.g., services such as online games, audio, and video calls), and non-real-time services may refer to services that are not latency-sensitive (or services that are not latency demanding) (e.g., services such as web browsers and file downloads).

[0047]

[0048] FIGS. 5A and 5B are diagrams illustrating operation modes for multi-AP cooperation according to one embodiment.

[0049] Referring to FIGS. 5A and 5B , according to one embodiment, STA (301) may operate in a normal operation mode or a multi-AP cooperative operation mode. The normal operation mode is an operation mode in which STA (301) transmits and receives data through an associated AP (e.g., AP (401)), and the multi-AP cooperative operation mode may be an operation mode in which STA (301) transmits and receives data through multi-AP cooperation. FIG. 5A illustrates an example of the normal operation mode, and FIG. 5B illustrates an example of the multi-AP cooperative mode.

[0050] According to one embodiment, the STA (301) may operate in a normal operation mode or a multi-AP cooperative operation mode depending on the type of service. For example, if the type of service is a real-time service, the STA (301) may determine to operate in a multi-AP cooperative operation mode. If the type of service is a non-real-time service, the STA (301) may determine to operate in a normal operation mode. According to one embodiment, the STA (301) may operate in a multi-AP cooperative operation mode for one or more services provided to a user regardless of the type of service.

[0051] According to one embodiment, the STA (301) can negotiate multi-AP cooperation for a service with the AP controller (500) in a multi-AP cooperation operation mode. During the negotiation process for multi-AP cooperation with the AP controller (500), the STA (301) can utilize information about the service requesting multi-AP cooperation (e.g., traffic flow information of the service). The traffic flow information of the service can include IP information of traffic generated by the service. The traffic flow information of the service can include various types of information that can specify the traffic (or traffic flow) generated by the service.

[0052] According to one embodiment, the STA (301) may selectively perform multi-AP cooperation for one or more designated services. Multi-AP cooperation may not be performed for all data traffic of the STA (301), but may be performed only for traffic generated by a service for which the STA (301) has requested multi-AP cooperation. By allowing the STA (301) to apply multi-AP cooperation only to traffic for which a differentiated user experience can be provided through multi-AP cooperation, the burden of the backhaul link and the overhead associated with data distribution and management of the AP controller (500) are reduced, and the user experience improvement effect resulting from multi-AP cooperation can be maintained.

[0053]

[0054] FIG. 6 is a diagram illustrating negotiation for multi-AP cooperation according to one embodiment.

[0055] Referring to FIG. 6, operations 610 to 680 may be intended to describe operations for initiating / performing / teardown negotiations for multi-AP cooperation. Operations 610 to 680 may be performed sequentially, but are not necessarily sequential. For example, the order of each operation (610 to 680) may be changed, and at least two operations may be performed in parallel.

[0056] In operation 610, an STA (301) operating in association with an AP (401) can identify (e.g., recognize) whether traffic for a service running on the STA (301) is real-time traffic. The STA (301) can identify the type of service (e.g., real-time service, non-real-time service).

[0057] In operation 620, if traffic for a service running on STA (301) is identified as non-real-time traffic, STA (301) may operate in a normal operation mode.

[0058] In operation 630, if traffic for a service running on STA (301) is identified as real-time traffic, STA (301) may operate in a multi-AP cooperative operation mode.

[0059] In operation 640, STA (301) can identify information about a service requesting multi-AP cooperation (e.g., IP information of traffic for the service).

[0060] In operation 650, STA (301) may perform negotiation for multi-AP cooperation with AP controller (500) for the service using information about the identified service (e.g., IP information of traffic for the service).

[0061] In operation 660, after completing negotiations for multi-AP cooperation, STA (301) can communicate service traffic through multi-AP cooperation. For example, STA (301) can transmit and receive service-generated traffic through multiple APs (e.g., AP (401) and AP (405)).

[0062] In operation 670, the STA (301) can check (e.g., detect) whether traffic generated from a service that requested multi-AP cooperation has stopped during the multi-AP cooperation operation.

[0063] In operation 680, if there is no traffic generated from the service that requested multi-AP cooperation, the STA (301) may no longer use multi-AP cooperation (e.g., TWT tear down).

[0064]

[0065] FIG. 7a is a diagram illustrating a negotiation process for multi-AP cooperation according to one embodiment, and FIG. 7b shows an example of a format of a request frame requesting multi-AP cooperation according to one embodiment.

[0066] Referring to FIGS. 7A and 7B , operations 710 through 750 may be intended to illustrate a negotiation process for multi-AP cooperation. Operations 710 through 750 may be performed sequentially, but are not necessarily sequential. For example, the order of each operation (710 through 750) may be changed, and at least two operations may be performed in parallel.

[0067] In operation 710, the STA (301) may decide to request multi-AP cooperation for a service. At this time, the service type may be a real-time service. The embodiments are not limited to requesting multi-AP cooperation only for real-time services, and according to one embodiment, the STA (301) may request multi-AP cooperation for one or more services provided to the user (e.g., non-real-time services, real-time services), regardless of the service type.

[0068] In operation 730, the STA (301) may transmit a request frame (e.g., the Multi-AP coordination request frame (770) of FIG. 7B) requesting multi-AP cooperation for a service to the AP controller (500) via the connected AP (401). For example, the AP (401) may receive the request frame from the STA (301) and transmit the request frame to the AP controller (500).

[0069] In operation 750, the AP controller (500) may transmit a response frame (e.g., a multi-AP coordination response) to the request frame to the STA (301) via the AP (401). For example, the AP (401) may receive the response frame from the AP controller (500) and transmit the response frame to the STA (301). The AP controller (500) may accept or reject the multi-AP cooperation request based on available resources. The response frame may include information regarding acceptance or rejection of the multi-AP cooperation request.

[0070] According to one embodiment, a request frame (770) requesting multi-AP cooperation may be composed of a plurality of elements and a plurality of fields. One or more elements and / or one or more fields within the request frame (770) may include information for multi-AP cooperation (e.g., information about a service, information about an AP, and / or scheduling information for a service).

[0071] According to one embodiment, the request frame (770) may include information about a service requesting multi-AP cooperation. The information about the service may be specified in a traffic classification (TCLAS) element, which is one of multiple elements within the request frame (770).

[0072] According to one embodiment, the request frame (770) may include multiple TCLSA elements. Each of the multiple TCLSA elements may specify information about each service requesting multi-AP cooperation. In this case, the request frame (770) may further include a TCLSA processing element.

[0073] According to one embodiment, the request frame (770) may further include information (or a list) (e.g., basic service set identifier (BSSID) or basic service set (BSS) color information) about APs located around the STA (301) (e.g., one or more APs with which the STA (301) wishes to participate in multi-AP cooperation). If the multi-AP cooperation request is accepted, one or more APs included in the information about the AP may or may not participate in multi-AP cooperation. According to one embodiment, all APs included in the information about the AP may participate in multi-AP cooperation. According to one embodiment, participation in multi-AP cooperation of an AP included in the information about the AP may be determined under the control (e.g., selection) of the AP controller (500).

[0074] According to one embodiment, the request frame (770) may further include scheduling information for the service (e.g., service interval and duration). If the multi-AP cooperation request is accepted, the AP controller (500) may perform a multi-AP cooperation operation for the STA (301) based on the scheduling information for the service specified in the request frame (770). This may further ensure the quality (e.g., real-time performance or latency) required for the service.

[0075] According to one embodiment, when a multi-AP cooperation request is accepted, the AP controller (500) may perform a multi-AP cooperation operation for the STA (301) based on information about the service specified in the TCLAS element in the request frame (770). The STA (301) may communicate traffic of the service through multi-AP cooperation.

[0076]

[0077] Figures 8a to 8d illustrate examples of elements for specifying information about a service according to one embodiment.

[0078] Figure 8a illustrates the format of the TCLAS element defined in IEEE 802.11. In one embodiment, the TCLAS element can be used to select traffic flows for services requesting multi-AP cooperation. The TCLAS element can specify one or more parameters (e.g., IP parameters) to specify specific traffic flows. In the TCLAS element, various parameters that can specify traffic flows can be utilized.

[0079] According to one embodiment, a TCLAS element may include an element ID field (e.g., Element ID), a length field (e.g., Length), a user priority field (e.g., User Priority), and a frame classifier field (e.g., Frame Classifier). The element ID field indicates the type of the element, which in this case may be used to indicate a TCLAS element. The length field may indicate the length of the TCLAS element. The user priority field may indicate a user priority from a higher layer. The frame classifier field may indicate a method used to classify frames from a higher layer.

[0080] FIG. 8A illustrates an example in which a frame classifier field includes a classifier type field (or a classifier type subfield) (e.g., Classifier Type), a classifier mask field (or a classifier mask subfield) (e.g., Classifier Mask), and a classifier parameter field (or a classifier parameter subfield) (e.g., Classifier Parameters). According to one embodiment, the classifier type in the frame classifier field may be appropriately used to specify traffic for a service requesting multi-AP cooperation. Table 1 shows examples of classifier types and parameters for classification. Table 1 may indicate that the frame classifier field may be interpreted in various formats (e.g., the frame classifier field of FIG. 8B, the frame classifier field of FIG. 8C) depending on the classifier type (e.g., a value that distinguishes the classifier type).

[0081]

[0082] [Table 1]

[0083]

[0084]

[0085] In one embodiment, classifier types 0 to 10 may be used to specify traffic for a service requesting multi-AP cooperation. For example, if the classifier type is 4, IP parameters (or higher layer parameters) (e.g., parameters such as source IP address, destination IP address, source port, destination port, DSCP, and protocol) may be set, so that traffic flows can be specified based on IP information. FIG. 8b and FIG. 8c may each illustrate the structures of IPV4 and IPV6 frame classifier fields according to the version field when the classifier type is 4.

[0086] In one embodiment, classifier types 11 to 255 may be used to specify traffic for a service requesting multi-AP cooperation. For example, a classifier type for specifying traffic for a service requesting multi-AP cooperation may be set in classifier types 11 to 255, and a new structure for a frame classifier field may be defined by adding one or more parameters that can set information that can specify traffic for the service.

[0087] FIG. 8D illustrates the format of a TCLAS processing element defined in IEEE 802.11. According to one embodiment, when a request frame (770) includes multiple TCLSA elements, the request frame (770) may further include a TCLSA processing element. In a situation where traffic for a service requesting multi-AP cooperation is to be selected by utilizing multiple TCLSA elements, the TCLSA processing element may be utilized to define conditions, such as whether all conditions must be satisfied for the multiple TCLSA elements or whether any one of the conditions is sufficient. The TCLSA processing element may include an element ID field (e.g., Element ID), a length field (e.g., Length), and a processing field (e.g., Processing). The element ID field indicates the type of the element, in this case, indicates a TCLAS processing element. The length field indicates the length of the TCLAS processing element. The Handling field indicates how to classify traffic from upper layers when multiple TCLAS elements are present, and Table 2 shows the associated meaning for classification according to the Handling field (or Handling subfield) value. Handling field values ​​3-255 can be used to additionally add associated meaning for classification and one or more additional handling values.

[0088]

[0089] [Table 2]

[0090]

[0091]

[0092] FIG. 9 is a diagram illustrating information about an AP included in a request frame requesting multi-AP cooperation according to one embodiment. In FIG. 9, circles may represent cells.

[0093] Referring to FIG. 9, according to one embodiment, surrounding APs that do not receive signals from STA (301) cannot provide benefits through multi-AP cooperation. The AP controller (500) may set the surrounding APs (e.g., AP (401)) to which STA (301) is currently connected based on floor plan information on which APs are installed (or constructed) as APs that perform multi-AP cooperation. If STA (301) specifies surrounding AP information to participate in multi-AP cooperation depending on situations such as movement (or mobility), the overhead associated with performing multi-AP cooperation may be further alleviated.

[0094] According to one embodiment, when requesting multi-AP cooperation, the STA (301) may additionally specify information regarding which surrounding APs will perform multi-AP cooperation in the request frame (770). The STA (301) may request multi-AP cooperation by including information (or a list) (e.g., basic service set identifier (BSSID) or basic service set (BSS) color information) about APs located around the STA (301) (e.g., one or more APs with which the STA (301) wishes to participate in multi-AP cooperation) in the request frame (770).

[0095]

[0096] FIG. 10 is a block diagram of an electronic device (1001) within a network environment (1000) according to various embodiments. Referring to FIG. 10, in the network environment (1000), the electronic device (1001) may communicate with the electronic device (1002) via a first network (1098) (e.g., a short-range wireless communication network), or may communicate with at least one of the electronic device (1004) or the server (1008) via a second network (1099) (e.g., a long-range wireless communication network). According to one embodiment, the electronic device (1001) may communicate with the electronic device (1004) via the server (1008). According to one embodiment, the electronic device (1001) may include a processor (1020), a memory (1030), an input module (1050), an audio output module (1055), a display module (1060), an audio module (1070), a sensor module (1076), an interface (1077), a connection terminal (1078), a haptic module (1079), a camera module (1080), a power management module (1088), a battery (1089), a communication module (1090), a subscriber identification module (1096), or an antenna module (1097). In some embodiments, the electronic device (1001) may omit at least one of these components (e.g., the connection terminal (1078)), or may have one or more other components added. In some embodiments, some of these components (e.g., sensor module (1076), camera module (1080), or antenna module (1097)) may be integrated into a single component (e.g., display module (1060)).

[0097] The processor (1020) may, for example, execute software (e.g., a program (1040)) to control at least one other component (e.g., a hardware or software component) of the electronic device (1001) connected to the processor (1020) and perform various data processing or operations. According to one embodiment, as at least a part of the data processing or operations, the processor (1020) may store commands or data received from other components (e.g., a sensor module (1076) or a communication module (1090)) in a volatile memory (1032), process the commands or data stored in the volatile memory (1032), and store result data in a non-volatile memory (1034). According to one embodiment, the processor (1020) may include a main processor (1021) (e.g., a central processing unit or an application processor) or an auxiliary processor (1023) (e.g., a graphics processing unit, a neural processing unit (NPU), an image signal processor, a sensor hub processor, or a communication processor) that can operate independently or together with the main processor (1021). For example, when the electronic device (1001) includes the main processor (1021) and the auxiliary processor (1023), the auxiliary processor (1023) may be configured to use less power than the main processor (1021) or to be specialized for a given function. The auxiliary processor (1023) may be implemented separately from the main processor (1021) or as a part thereof.

[0098] The auxiliary processor (1023) may control at least a portion of functions or states associated with at least one component (e.g., the display module (1060), the sensor module (1076), or the communication module (1090)) of the electronic device (1001), for example, on behalf of the main processor (1021) while the main processor (1021) is in an inactive (e.g., sleep) state, or together with the main processor (1021) while the main processor (1021) is in an active (e.g., application execution) state. In one embodiment, the auxiliary processor (1023) (e.g., an image signal processor or a communication processor) may be implemented as a part of another functionally related component (e.g., a camera module (1080) or a communication module (1090)). In one embodiment, the auxiliary processor (1023) (e.g., a neural network processing unit) may include a hardware structure specialized for processing artificial intelligence models. The artificial intelligence models may be generated through machine learning. This learning can be performed, for example, on the electronic device (1001) itself where the artificial intelligence model is executed, or can be performed through a separate server (e.g., server (1008)). The learning algorithm can include, for example, supervised learning, unsupervised learning, semi-supervised learning, or reinforcement learning, but is not limited to the examples described above. The artificial intelligence model can include multiple artificial neural network layers.The artificial neural network may be one of a deep neural network (DNN), a convolutional neural network (CNN), a recurrent neural network (RNN), a restricted Boltzmann machine (RBM), a deep belief network (DBN), a bidirectional recurrent deep neural network (BRDNN), a deep Q-network, or a combination of two or more of the above, but is not limited to the examples described above. In addition to, or alternatively to, a hardware structure, an artificial intelligence model may include a software structure.

[0099] The memory (1030) can store various data used by at least one component (e.g., the processor (1020) or the sensor module (1076)) of the electronic device (1001). The data can include, for example, software (e.g., the program (1040)) and input data or output data for commands related thereto. The memory (1030) can include volatile memory (1032) or non-volatile memory (1034).

[0100] The program (1040) may be stored as software in memory (1030) and may include, for example, an operating system (1042), middleware (1044), or an application (1046).

[0101] The input module (1050) can receive commands or data to be used in a component of the electronic device (1001) (e.g., a processor (1020)) from an external source (e.g., a user) of the electronic device (1001). The input module (1050) can include, for example, a microphone, a mouse, a keyboard, a key (e.g., a button), or a digital pen (e.g., a stylus pen).

[0102] The audio output module (1055) can output audio signals to the outside of the electronic device (1001). The audio output module (1055) can include, for example, a speaker or a receiver. The speaker can be used for general purposes, such as multimedia playback or recording playback. The receiver can be used to receive incoming calls. In one embodiment, the receiver can be implemented separately from the speaker or as part of the speaker.

[0103] The display module (1060) can visually provide information to an external party (e.g., a user) of the electronic device (1001). The display module (1060) may include, for example, a display, a holographic device, or a projector, and a control circuit for controlling the device. In one embodiment, the display module (1060) may include a touch sensor configured to detect a touch, or a pressure sensor configured to measure the intensity of a force generated by the touch.

[0104] The audio module (1070) can convert sound into an electrical signal, or vice versa, convert an electrical signal into sound. According to one embodiment, the audio module (1070) can acquire sound through the input module (1050), output sound through the sound output module (1055), or an external electronic device (e.g., electronic device (1002)) (e.g., speaker or headphone) directly or wirelessly connected to the electronic device (1001).

[0105] The sensor module (1076) can detect the operating status (e.g., power or temperature) of the electronic device (1001) or the external environmental status (e.g., user status) and generate an electrical signal or data value corresponding to the detected status. According to one embodiment, the sensor module (1076) can include, for example, a gesture sensor, a gyro sensor, a barometric pressure sensor, a magnetic sensor, an acceleration sensor, a grip sensor, a proximity sensor, a color sensor, an IR (infrared) sensor, a biometric sensor, a temperature sensor, a humidity sensor, or an illuminance sensor.

[0106] The interface (1077) may support one or more designated protocols that may be used to directly or wirelessly connect the electronic device (1001) to an external electronic device (e.g., the electronic device (1002)). In one embodiment, the interface (1077) may include, for example, a high definition multimedia interface (HDMI), a universal serial bus (USB) interface, an SD card interface, or an audio interface.

[0107] The connection terminal (1078) may include a connector through which the electronic device (1001) may be physically connected to an external electronic device (e.g., the electronic device (1002)). In one embodiment, the connection terminal (1078) may include, for example, an HDMI connector, a USB connector, an SD card connector, or an audio connector (e.g., a headphone connector).

[0108] The haptic module (1079) can convert electrical signals into mechanical stimuli (e.g., vibration or movement) or electrical stimuli that a user can perceive through tactile or kinesthetic sensations. In one embodiment, the haptic module (1079) can include, for example, a motor, a piezoelectric element, or an electrical stimulation device.

[0109] The camera module (1080) can capture still images and videos. In one embodiment, the camera module (1080) may include one or more lenses, image sensors, image signal processors, or flashes.

[0110] The power management module (1088) can manage power supplied to the electronic device (1001). According to one embodiment, the power management module (1088) can be implemented as, for example, at least a part of a power management integrated circuit (PMIC).

[0111] A battery (1089) may power at least one component of the electronic device (1001). In one embodiment, the battery (1089) may include, for example, a non-rechargeable primary battery, a rechargeable secondary battery, or a fuel cell.

[0112] The communication module (1090) may support the establishment of a direct (e.g., wired) communication channel or a wireless communication channel between the electronic device (1001) and an external electronic device (e.g., electronic device (1002), electronic device (1004), or server (1008)), and the performance of communication through the established communication channel. The communication module (1090) may operate independently from the processor (1020) (e.g., application processor) and may include one or more communication processors that support direct (e.g., wired) communication or wireless communication. According to one embodiment, the communication module (1090) may include a wireless communication module (1092) (e.g., a cellular communication module, a short-range wireless communication module, or a global navigation satellite system (GNSS) communication module) or a wired communication module (1094) (e.g., a local area network (LAN) communication module, or a power line communication module). Any of these communication modules may communicate with an external electronic device (1004) via a first network (1098) (e.g., a short-range communication network such as Bluetooth, wireless fidelity (WiFi) direct, or infrared data association (IrDA)) or a second network (1099) (e.g., a long-range communication network such as a legacy cellular network, a 5G network, a next-generation communication network, the Internet, or a computer network (e.g., a LAN or WAN)). These various types of communication modules may be integrated into a single component (e.g., a single chip) or implemented as multiple separate components (e.g., multiple chips). The wireless communication module (1092) may use subscriber information (e.g., an international mobile subscriber identity (IMSI)) stored in the subscriber identification module (1096) to verify or authenticate the electronic device (1001) within a communication network such as the first network (1098) or the second network (1099).

[0113] The wireless communication module (1092) can support 5G networks and next-generation communication technologies following the 4G network, such as NR access technology (new radio access technology). NR access technology can support high-speed transmission of high-capacity data (eMBB (enhanced mobile broadband)), minimizing terminal power and connecting multiple terminals (mMTC (massive machine type communications)), or high reliability and low latency (URLLC (ultra-reliable and low-latency communications)). The wireless communication module (1092) can support, for example, a high-frequency band (e.g., mmWave band) to achieve a high data transmission rate. The wireless communication module (1092) may support various technologies for securing performance in a high-frequency band, such as beamforming, massive multiple-input and multiple-output (MIMO), full dimensional MIMO (FD-MIMO), array antenna, analog beam-forming, or large scale antenna. The wireless communication module (1092) may support various requirements specified in the electronic device (1001), an external electronic device (e.g., the electronic device (1004)), or a network system (e.g., the second network (1099)). According to one embodiment, the wireless communication module (1092) can support a peak data rate (e.g., 20 Gbps or more) for eMBB realization, a loss coverage (e.g., 164 dB or less) for mMTC realization, or a U-plane latency (e.g., 0.5 ms or less for downlink (DL) and uplink (UL), or 1 ms or less for round trip) for URLLC realization.

[0114] The antenna module (1097) can transmit or receive signals or power to or from an external device (e.g., an external electronic device). In one embodiment, the antenna module (1097) may include an antenna including a radiator formed of a conductor or a conductive pattern formed on a substrate (e.g., a PCB). In one embodiment, the antenna module (1097) may include a plurality of antennas (e.g., an array antenna). In this case, at least one antenna suitable for a communication method used in a communication network, such as the first network (1098) or the second network (1099), may be selected from the plurality of antennas, for example, by the communication module (1090). A signal or power may be transmitted or received between the communication module (1090) and an external electronic device via the at least one selected antenna. In some embodiments, in addition to the radiator, another component (e.g., a radio frequency integrated circuit (RFIC)) may be additionally formed as a part of the antenna module (1097).

[0115] According to various embodiments, the antenna module (1097) may form a mmWave antenna module. In one embodiment, the mmWave antenna module may include a printed circuit board, an RFIC disposed on or adjacent a first side (e.g., a bottom side) of the printed circuit board and capable of supporting a designated high frequency band (e.g., a mmWave band), and a plurality of antennas (e.g., an array antenna) disposed on or adjacent a second side (e.g., a top side or a side side) of the printed circuit board and capable of transmitting or receiving signals in the designated high frequency band.

[0116] At least some of the above components can be interconnected and exchange signals (e.g., commands or data) with each other via a communication method between peripheral devices (e.g., a bus, GPIO (general purpose input and output), SPI (serial peripheral interface), or MIPI (mobile industry processor interface)).

[0117] According to one embodiment, commands or data may be transmitted or received between the electronic device (1001) and an external electronic device (1004) via a server (1008) connected to a second network (1099). Each of the external electronic devices (1002 or 1004) may be the same or a different type of device as the electronic device (1001). According to one embodiment, all or part of the operations executed in the electronic device (1001) may be executed in one or more of the external electronic devices (1002, 1004, or 1008). For example, when the electronic device (1001) is to perform a certain function or service automatically or in response to a request from a user or another device, the electronic device (1001) may, instead of or in addition to executing the function or service itself, request one or more external electronic devices to perform the function or at least a part of the service. One or more external electronic devices that receive the request may execute at least a portion of the requested function or service, or an additional function or service related to the request, and transmit the result of the execution to the electronic device (1001). The electronic device (1001) may process the result as is or additionally and provide it as at least a portion of a response to the request. For this purpose, cloud computing, distributed computing, mobile edge computing (MEC), or client-server computing technology may be used, for example. The electronic device (1001) may provide an ultra-low latency service by using distributed computing or mobile edge computing, for example. In another embodiment, the external electronic device (1004) may include an Internet of Things (IoT) device. The server (1008) may be an intelligent server utilizing machine learning and / or a neural network.According to one embodiment, an external electronic device (1004) or server (1008) may be included within the second network (1099). The electronic device (1001) may be applied to intelligent services (e.g., smart homes, smart cities, smart cars, or healthcare) based on 5G communication technology and IoT-related technology.

[0118]

[0119] According to one embodiment, an electronic device (e.g., STA (301) of FIG. 4, electronic device (1001) of FIG. 10) may include one or more wireless communication circuits (e.g., wireless communication module (1092) of FIG. 10) configured to transmit and receive wireless signals, one or more processors (e.g., processor (1020) of FIG. 10) operatively connected to the wireless communication circuits (1092), and one or more memories (e.g., memory (1030) of FIG. 10) storing instructions. The instructions may be individually or collectively executed by the processor (1020) to cause the electronic device (301; 1001) to transmit a request frame (770) requesting multi-AP coordination for a service through the electronic device (301; 1001) to an access point (AP) (401) associated with the electronic device. The instructions may be individually or collectively executed by the processor (1020) to cause the electronic device (301; 1001) to receive a response frame to the request frame (770) through the AP (401). The above instructions may be individually or collectively executed by the processor (1020) to cause the electronic device (301; 1001) to communicate traffic of the service through the multi-AP cooperation.

[0120] In one embodiment, the service may be a real-time service.

[0121] According to one embodiment, the request frame (770) may include information about the service.

[0122] According to one embodiment, information about the service may include IP information of traffic generated by the service.

[0123] According to one embodiment, information about the service may be specified in a traffic classification (TCLAS) element included in the request frame.

[0124] According to one embodiment, when the request frame includes a plurality of TCLSA elements, a TCLSA (traffic classification) processing element may be included in the request frame (770).

[0125] According to one embodiment, the request frame (770) may include information about an AP located around the electronic device (301; 1001).

[0126] According to one embodiment, the information about the AP may include basic service set identifier (BSSID) or basic service set (BSS) color information.

[0127] According to one embodiment, the request frame (770) may include scheduling information for the service.

[0128] According to one embodiment, the scheduling information may include a service interval and duration.

[0129] According to one embodiment, an electronic device (e.g., STA (301) of FIG. 4, electronic device (1001) of FIG. 10) may include one or more wireless communication circuits (e.g., wireless communication module (1092) of FIG. 10) configured to transmit and receive wireless signals, one or more processors (e.g., processor (1020) of FIG. 10) operatively connected to the wireless communication circuits (1092), and one or more memories (e.g., memory (1030) of FIG. 10) storing instructions. The above instructions may be individually or collectively executed by the processor (1020) to cause the electronic device (301; 1001) to transmit a request frame (770) requesting multi-AP coordination including traffic flow information of a service to an access point (AP) (401) associated with the electronic device (301; 1001). The above instructions may be individually or collectively executed by the processor (1020) to cause the electronic device (301; 1001) to receive a response frame to the request frame (770) through the AP (401). The above instructions may be individually or collectively executed by the processor (1020) to cause the electronic device (301; 1001) to receive traffic of the service through the multi-AP cooperation.

[0130] In one embodiment, the service may be a real-time service.

[0131] According to one embodiment, the traffic flow information may include IP information of traffic generated by the service.

[0132] According to one embodiment, the traffic flow information may be specified in a TCLAS element included in the request frame (770).

[0133] According to one embodiment, when the request frame (770) includes a plurality of TCLSA elements, a TCLSA processing element may be included in the request frame (770).

[0134] According to one embodiment, the request frame (770) may include information about an AP located around the electronic device (301; 1001).

[0135] According to one embodiment, the information about the AP may include basic service set identifier (BSSID) or basic service set (BSS) color information.

[0136] According to one embodiment, the request frame (770) may include scheduling information for the service.

[0137] According to one embodiment, the scheduling information may include a service interval and duration.

[0138] A method of operating an electronic device (e.g., STA (301) of FIG. 4, electronic device (1001) of FIG. 10) according to one embodiment may include an operation of identifying a service through the electronic device (301; 1001). The method may include an operation of negotiating multi-AP coordination for the service. The method may include an operation of receiving traffic of the service through the multi-AP coordination.

[0139]

[0140] Electronic devices according to the various embodiments disclosed in this document may take various forms. Electronic devices may include, for example, portable communication devices (e.g., smartphones), computer devices, portable multimedia devices, portable medical devices, cameras, wearable devices, or home appliances. Electronic devices according to the embodiments of this document are not limited to the aforementioned devices.

[0141] The various embodiments of this document and the terminology used therein are not intended to limit the technical features described in this document to specific embodiments, but should be understood to include various modifications, equivalents, or substitutes of the embodiments. In connection with the description of the drawings, similar reference numerals may be used for similar or related components. The singular form of a noun corresponding to an item may include one or more of the items, unless the context clearly indicates otherwise. In this document, each of the phrases "A or B", "at least one of A and B", "at least one of A or B", "A, B, or C", "at least one of A, B, and C", and "at least one of A, B, or C" can include any one of the items listed together in the corresponding phrase among those phrases, or all possible combinations thereof. Terms such as "first," "second," or "first" or "second" may be used merely to distinguish one component from another, and do not limit the components in any other respect (e.g., importance or order). When a component (e.g., a first component) is referred to as "coupled" or "connected" to another (e.g., a second component), with or without the terms "functionally" or "communicatively," it means that the component can be connected to the other component directly (e.g., wired), wirelessly, or through a third component.

[0142] The term "module" used in various embodiments of this document may include a unit implemented in hardware, software, or firmware, and may be used interchangeably with terms such as logic, logic block, component, or circuit. A module may be an integral component, or a minimum unit or part of such a component that performs one or more functions. For example, according to one embodiment, a module may be implemented in the form of an application-specific integrated circuit (ASIC).

[0143] Various embodiments of the present document may be implemented as software (e.g., a program (1040)) including one or more instructions stored in a storage medium (e.g., an internal memory (1036) or an external memory (1038)) readable by a machine (e.g., an electronic device (1001)). For example, a processor (e.g., a processor (1020)) of the machine (e.g., an electronic device (1001)) may call at least one instruction among the one or more instructions stored from the storage medium and execute it. This enables the machine to operate to perform at least one function according to the at least one called instruction. The one or more instructions may include code generated by a compiler or code executable by an interpreter. The machine-readable storage medium may be provided in the form of a non-transitory storage medium. Here, 'non-transitory' simply means that the storage medium is a tangible device and does not contain signals (e.g., electromagnetic waves), and the term does not distinguish between cases where data is stored semi-permanently or temporarily on the storage medium.

[0144] According to one embodiment, the method according to various embodiments disclosed in this document may be provided as included in a computer program product. The computer program product may be traded as a product between a seller and a buyer. The computer program product may be distributed in the form of a machine-readable storage medium (e.g., compact disc read-only memory (CD-ROM)), or may be distributed online (e.g., downloaded or uploaded) through an application store (e.g., Play Store™) or directly between two user devices (e.g., smart phones). In the case of online distribution, at least a portion of the computer program product may be temporarily stored or temporarily generated in a machine-readable storage medium, such as the memory of a manufacturer's server, an application store's server, or an intermediary server.

[0145] According to various embodiments, each component (e.g., a module or a program) of the above-described components may include one or more entities, and some of the entities may be separated and placed in other components. According to various embodiments, one or more components or operations of the aforementioned components may be omitted, or one or more other components or operations may be added. Alternatively or additionally, a plurality of components (e.g., a module or a program) may be integrated into a single component. In such a case, the integrated component may perform one or more functions of each of the plurality of components identically or similarly to those performed by the corresponding component among the plurality of components prior to the integration. According to various embodiments, the operations performed by a module, program, or other component may be executed sequentially, in parallel, iteratively, or heuristically, or one or more of the operations may be executed in a different order, omitted, or one or more other operations may be added.

Claims

1. In an electronic device (301; 1001), One or more wireless communication circuits (1092) configured to transmit and receive wireless signals; One or more processors (1020) operatively connected to the wireless communication circuit (1092); and One or more memories (1030) for storing instructions Including, The above instructions are individually or collectively executed by the processor (1020) to cause the electronic device (301; 1001) to: A request frame (770) requesting multi-AP coordination for a service is transmitted to an access point (AP) (401) associated with the electronic device (301; 1001), A response frame to the above request frame (770) is received through the AP (401), To communicate the traffic of the above service through the above multi-AP cooperation, Electronic devices (301; 1001).

2. In paragraph 1, The above services are, Electronic device (301; 1001), a real-time service.

3. In either of paragraphs 1 and 2, The above request frame (770) is, An electronic device (301; 1001) containing information about the above service.

4. In any one of paragraphs 1 to 3, Information about the above services: An electronic device (301; 1001) containing IP information of traffic generated by the above service.

5. In any one of paragraphs 1 to 4, Information about the above services: An electronic device (301; 1001) specified in the TCLAS (traffic classification) element included in the above request frame (770).

6. In any one of paragraphs 1 to 5, If the above TCLAS element is included in the request frame in multiple instances, An electronic device (301; 1001), wherein a TCLAS (traffic classification) processing element is included in the request frame (770).

7. In any one of paragraphs 1 to 6, The above request frame (770) is, An electronic device (301; 1001) comprising information about an AP located in the vicinity of the electronic device (301; 1001).

8. In any one of paragraphs 1 to 7, Information about the above AP is: An electronic device (301; 1001) including BSSID (basic service set identifier) ​​or BSS (basic service set) color information.

9. In any one of paragraphs 1 to 8, The above request frame (770) is, An electronic device (301; 1001) comprising scheduling information for the above service.

10. In any one of paragraphs 1 to 9, The above scheduling information is, An electronic device (301; 1001) comprising a service interval and duration.

11. In the electronic device (301; 1001), One or more wireless communication circuits (1092) configured to transmit and receive wireless signals; One or more processors (1020) operatively connected to the wireless communication circuit (1092); and One or more memories (1030) for storing instructions Including, The above instructions are individually or collectively executed by the processor (1020) to cause the electronic device (301; 1001) to: A request frame (770) requesting multi-AP coordination including traffic flow information of the service is transmitted to an AP (access point) (401) associated with the electronic device (301; 1001), A response frame to the above request frame (770) is received through the AP (401), To receive traffic of the above service through the above multi-AP cooperation, Electronic devices (301; 1001).

12. In paragraph 11, The above services are, Electronic device (301; 1001), a real-time service.

13. In either of paragraphs 11 and 12, The above traffic flow information is, An electronic device (301; 1001) containing IP information of traffic generated by the above service.

14. In any one of paragraphs 11 to 13, The above traffic flow information is, An electronic device (301; 1001) specified in the TCLAS element included in the above request frame (770). TCLASTCLAS 15. In the operating method of an electronic device (301; 1001), An action of identifying a service through the above electronic device (301; 1001); An action to negotiate multi-AP coordination for the above service; An action of receiving traffic of the above service through the above multi-AP cooperation. A method of operation, comprising:

Images