Channel announcement in a wireless communication system
By generating frames with recommended channel information, WLAN systems can manage traffic more efficiently, reducing interference and ensuring QoS for latency-sensitive applications through optimized channel allocation.
Patent Information
- Application Number
- JP2025522236
- Authority / Receiving Office
- JP · JP
- Patent Type
- Applications
- Current Assignee / Owner
- Priority Date
- 2024-01-16
- Filing Date
- 2024-02-06
- Publication Date
- 2025-11-12
AI Technical Summary
Current WLAN systems lack a mechanism to effectively manage unregulated traffic and prioritize low-latency applications, leading to interference and reduced performance in networks with latency-sensitive devices.
An AP device generates frames indicating recommended channels for peer-to-peer communication, including information such as channel usage and power constraints, to guide non-AP devices in selecting optimal channels for reduced interference and improved traffic management.
This approach reduces interference and enhances network management, ensuring Quality of Service (QoS) for latency-sensitive applications by allocating and announcing preferred channels for peer-to-peer communication.
Smart Images

Figure 2025536932000001_ABST
Abstract
Description
[Technical Field]
[0001] The present disclosure relates generally to wireless communication systems, and more particularly, for example but not limited to, channel announcements in wireless communication systems. [Background technology]
[0002] Wireless local area network (WLAN) technology has evolved to increase data rates and has grown over the years since the late 1990s in various markets, including homes, businesses, and hotspots. WLAN allows devices to access the Internet in the 2.4 GHz, 5 GHz, 6 GHz, or 60 GHz frequency bands. WLAN is based on the Institute of Electrical and Electronics Engineers (IEEE) 802.11 standard. The IEEE 802.11 family of standards aims to increase speed and reliability, as well as extend the operating range of wireless networks.
[0003] WLAN devices are increasingly required to support various delay-sensitive or real-time applications, such as augmented reality (AR), robotics, artificial intelligence (AI), cloud computing, and unmanned vehicles. To implement the ultra-low latency and ultra-high throughput required by such applications, multi-link operation (MLO) has been proposed for WLANs. A WLAN is formed by WLAN devices within a limited area, such as a home, school, apartment, or office building. Each WLAN device may have one or multiple stations (STAs), such as access point (AP) STAs and non-access point (non-AP) STAs.
[0004] MLO may allow a non-AP multi-link device (MLD) to set up multiple links with an AP MLD, each of which may independently enable channel access and frame exchange between the non-AP MLD and the AP MLD, thereby reducing latency and increasing throughput.
[0005] A statement set forth in the Background section should not be assumed to be prior art merely because it is set forth in the Background section. The Background section may describe aspects or embodiments of the present disclosure. Summary of the Invention [Means for solving the problem]
[0006] One aspect of the present disclosure provides an AP device in a wireless network. The AP device includes a transceiver, a memory, and a processor coupled to the memory. The processor is configured to generate a frame indicating one or more recommended channels for peer-to-peer communication. The processor is configured to control the transceiver to transmit the frame to one or more non-AP devices.
[0007] In some embodiments, the frame is a beacon frame or a probe response frame.
[0008] In some embodiments, the frame includes a channel usage element for one or more recommended channels.
[0009] In some embodiments, the channel usage element includes a usage mode field that indicates the usage of one or more recommended channels.
[0010] In some embodiments, the channel usage element includes a channel field indicating one or more channel numbers for one or more recommended channels and an operating class field indicating one or more operating classes for the one or more recommended channels.
[0011] In some embodiments, the one or more non-AP devices include at least one non-AP device that is not associated with an AP device.
[0012] In some embodiments, the frame includes a power constraint element that indicates the maximum transmit power intended for the receiving AP device.
[0013] In some embodiments, the frame includes an Enhanced Distributed Channel Access (EDCA) parameter set element that indicates EDCA parameters for transmissions intended for the receiving non-AP device.
[0014] In some embodiments, the one or more recommended channels are within the set of channels used by the AP device for the infrastructure basic service set.
[0015] In some embodiments, the one or more recommended channels are outside the set of channels used by the AP device for the infrastructure basic service set.
[0016] One aspect of the present disclosure provides a non-AP device in a wireless network. The non-AP device includes a transceiver, a memory, and a processor coupled to the memory. The processor is configured to control the transceiver to receive a frame from an AP device indicating one or more recommended channels for peer-to-peer communication. The processor is configured to select a channel from the one or more recommended channels for peer-to-peer communication based on the received frame. The processor is configured to conduct peer-to-peer communication with one or more non-AP devices on the selected channel.
[0017] In some embodiments, the frame is a beacon frame or a probe response frame.
[0018] In some embodiments, the frame includes a channel usage element for one or more recommended channels.
[0019] In some embodiments, the channel usage element includes a usage mode field that indicates the usage of one or more recommended channels.
[0020] In some embodiments, the channel usage element includes a channel field indicating one or more channel numbers for one or more recommended channels and an operating class field indicating one or more operating classes for the one or more recommended channels.
[0021] In some embodiments, the AP device is not associated with the non-AP device.
[0022] In some embodiments, the frame includes a power constraint element, and the processor is further configured to determine a maximum transmit power based on the power constraint element.
[0023] In some embodiments, the frame includes an Enhanced Distributed Channel Access (EDCA) parameter set element, and the processor is further configured to determine EDCA parameters for the transmission based on the EDCA parameter set element.
[0024] In some embodiments, the one or more recommended channels are within the set of channels used by the AP device for the infrastructure basic service set.
[0025] In some embodiments, the one or more recommended channels are outside the set of channels used by the AP device for the infrastructure basic service set. [Brief explanation of the drawings]
[0026] [Figure 1] FIG. 1 illustrates an example of a wireless network according to an embodiment. [Figure 2A] FIG. 2 illustrates an example of an AP according to an embodiment. [Figure 2B] FIG. 2 illustrates an example of an STA according to an embodiment. [Figure 3] 1 illustrates an example of multi-link communication operation according to an embodiment. [Figure 4] FIG. 1 illustrates an example network according to an embodiment. [Figure 5] FIG. 1 illustrates an example of a recommended P2P channel according to an embodiment. [Figure 6] FIG. 10 illustrates another example of a recommended P2P channel according to an embodiment. [Figure 7] FIG. 10 illustrates an example of a recommended P2P channel usage information element according to an embodiment. [Figure 8] FIG. 10 illustrates another exemplary format of a Channel Info field in a Channel Usage Information subelement, according to an embodiment. [Figure 9] 1 is a flowchart of an exemplary process for channel recommendation according to an embodiment. [Figure 10] 1 is a flowchart of an exemplary process for channel recommendation according to an embodiment. [Figure 11] 1 is a flowchart of an exemplary process for a channel recommendation procedure according to an embodiment. [Figure 12] FIG. 10 illustrates another example of a recommended P2P channel usage information element according to an embodiment. [Figure 13] FIG. 10 illustrates another example of a recommended P2P channel usage information element according to an embodiment. [Figure 14] FIG. 10 illustrates another example of a recommended P2P channel usage information element according to an embodiment. [Figure 15] FIG. 10 illustrates another example of a recommended P2P channel usage information element according to an embodiment. [Figure 16]FIG. 10 illustrates another example of a recommended P2P channel usage information element according to an embodiment. DETAILED DESCRIPTION OF THE INVENTION
[0027] Not all of the components shown in each figure may be required in one or more implementations, and one or more implementations may include additional components not shown in the figures. Variations in the arrangement and type of components may be made without departing from the scope of the present disclosure. Additional, different, or fewer components may be used within the scope of the present disclosure.
[0028] The detailed description of the present invention, set forth below with reference to the accompanying drawings, is intended as a description of various implementations and is not intended to represent the only implementations in which the present technology may be practiced. Rather, the detailed description includes specific details for providing a thorough understanding of the subject matter of the present invention. As will be appreciated by those skilled in the art, the described implementations may be modified in various ways, all without departing from the scope of the present disclosure. Accordingly, the drawings and descriptions should be regarded as illustrative in nature, and not as restrictive. Like reference numerals refer to like elements.
[0029] The following description is directed to several implementations for purposes of describing the inventive aspects of the present disclosure. However, those skilled in the art will readily recognize that the teachings herein can be applied in many different ways. The examples in this disclosure are based on WLAN communications according to the Institute of Electrical and Electronics Engineers (IEEE) 802.11 standard, including the IEEE 802.11be standard and any future amendments to the IEEE 802.11 standard. However, the described embodiments may be implemented in any device, system, or network capable of transmitting and receiving radio frequency (RF) signals according to the IEEE 802.11 standard, the Bluetooth standard, Global System for Mobile Communications (GSM), GSM / General Packet Radio Service (GPRS), Enhanced Data GSM Environment (EDGE), Terrestrial Telecommunications (TETRA), Wideband-CDMA (W-CDMA), Evolution Data Optimized (EV-DO), 1xEV-DO, EV-DO Rev A, EV-DO Rev B, High Speed Packet Access (HSPA), High Speed Downlink Packet Access (HSDPA), High Speed Uplink Packet Access (HSUPA), Evolved High Speed Packet Access (HSPA+), Long Term Evolution (LTE), 5G NR (New Radio), AMPS, or other known signals used to communicate within a wireless, cellular, or Internet of Things (IoT) network, such as a system using 3G, 4G, 5G, 6G technology, or further implementations thereof.
[0030] Depending on the network type, other well-known terms such as "router" or "gateway" may be used instead of "access point" or "AP." For convenience, the term "AP" is used in this disclosure to refer to a network infrastructure component that provides wireless access to remote terminals. Considering that APs also contend for wireless channels in a WLAN, APs may also be referred to as STAs. Also, depending on the network type, other well-known terms such as "mobile station," "subscriber station," "remote terminal," "user equipment," "wireless terminal," or "user device" may be used instead of "station" or "STA." For convenience, the terms "station" and "STA" are used in this disclosure to refer to remote wireless devices that wirelessly access an AP or contend for wireless channels in a WLAN, whether the STA is a mobile device (such as a mobile phone or smartphone) or is generally considered to be a stationary device (e.g., a desktop computer, an AP, a media player, a stationary sensor, a television, etc.).
[0031] Multi-link operation (MLO) is a key feature currently being developed by the standards bodies for next-generation, very high-throughput (EHT) Wi-Fi systems in IEEE 802.11be. A Wi-Fi device that supports MLO is called a multi-link device (MLD). With MLO, a non-AP MLD can discover, authenticate, associate, and set up multiple links with an AP MLD. Channel access and frame exchange are possible on each link between the AP MLD and the non-AP MLD.
[0032] 1 illustrates an example of a wireless network 100 according to one embodiment. The embodiment of wireless network 100 illustrated in FIG. 1 is for illustrative purposes only. Other embodiments of wireless network 100 may be used without departing from the scope of this disclosure.
[0033] As shown in FIG. 1, wireless network 100 may include multiple wireless communication devices. Each wireless communication device may include one or more stations (STAs). An STA may be a logical entity that is a singly addressable instance of a medium access control (MAC) layer and a physical (PHY) layer interface to the wireless medium. STAs may be classified as access point (AP) STAs and non-access point (non-AP) STAs. An AP STA may be an entity that provides associated STAs with access to distribution system services over the wireless medium. A non-AP STA may be a STA that is not included in an AP-STA. For ease of explanation, an AP STA may be referred to as an AP, and a non-AP STA may be referred to as an STA. In the example of FIG. 1, APs 101 and 103 are wireless communication devices, each of which may include one or more AP STAs. In such an embodiment, APs 101 and 103 may be AP multilink devices (MLDs). Similarly, STAs 111-114 are wireless communication devices, each of which may include one or more non-AP STAs. In such an embodiment, the STAs 111-114 may be non-AP MLDs.
[0034] APs 101 and 103 communicate with at least one network 130, such as the Internet, a proprietary Internet Protocol (IP) network, or other data network. AP 101 provides wireless access to network 130 to multiple stations (STAs) 111-114 within its coverage area 120. APs 101 and 103 may communicate with each other and with the STAs using Wi-Fi or other WLAN communication techniques.
[0035] Depending on the network type, other well-known terms such as "router" or "gateway" may be used instead of "access point" or "AP." For convenience, the term "AP" is used in this disclosure to refer to a network infrastructure component that provides wireless access to remote terminals. Considering that APs also contend for wireless channels in a WLAN, APs may also be referred to as STAs. Also, depending on the network type, other well-known terms such as "mobile station," "subscriber station," "remote terminal," "user equipment," "wireless terminal," or "user device" may be used instead of "station" or "STA." For convenience, the terms "station" and "STA" are used in this disclosure to refer to remote wireless devices that wirelessly access an AP or contend for wireless channels in a WLAN, whether the STA is a mobile device (such as a mobile phone or smartphone) or is generally considered to be a stationary device (e.g., a desktop computer, an AP, a media player, a stationary sensor, a television, etc.).
[0036] 1, dotted lines indicate the approximate extent of coverage areas 120 and 125 of APs 101 and 103, which are shown as approximately circular for purposes of illustration and explanation. It should be clearly understood that coverage areas associated with APs, such as coverage areas 120 and 125, may have other shapes, including irregular shapes, depending on the configuration of the APs.
[0037] As described in more detail below, one or more of the APs may include circuitry and / or programming for managing multi-user multiple-input multiple-output (MU-MIMO) and orthogonal frequency division multiple access (OFDMA) channel sounding in a WLAN. While FIG. 1 illustrates an example of wireless network 100, various modifications may be made to FIG. 1 . For example, wireless network 100 may include any number of APs and any number of STAs in any suitable arrangement. AP 101 may also directly communicate with any number of STAs and provide those STAs with wireless broadband access to network 130. Similarly, each AP 101 and 103 may directly communicate with network 130 and provide the STAs with direct wireless broadband access to network 130. Additionally, APs 101 and / or 103 may provide access to other or additional external networks, such as an external telephone network or other type of data network.
[0038] 2A illustrates an example of an AP 101 according to an embodiment. The embodiment of the AP 101 illustrated in FIG. 2A is for illustrative purposes, and the AP 103 in FIG. 1 may have the same or a similar configuration. However, APs come in a wide variety of configurations, and FIG. 2A does not limit the scope of the present disclosure to any particular implementation of an AP.
[0039] 2A, the AP 101 may include multiple antennas 204a-204n, multiple radio frequency (RF) transceivers 209a-209n, transmit (TX) processing circuitry 214, and receive (RX) processing circuitry 219. The AP 101 may also include a controller / processor 224, memory 229, and a backhaul or network interface 234. The RF transceivers 209a-209n receive incoming RF signals, such as signals transmitted by STAs in the network 100, from the antennas 204a-204n. The RF transceivers 209a-209n downconvert the incoming RF signals to generate intermediate (IF) or baseband signals. The IF or baseband signals are sent to the RX processing circuitry 219, which generates processed baseband signals by filtering, decoding, and / or digitizing the baseband or IF signals. The RX processing circuitry 219 sends the processed baseband signals to the controller / processor 224 for further processing.
[0040] TX processing circuitry 214 receives analog or digital data (such as voice data, web data, email, or interactive video game data) from controller / processor 224. TX processing circuitry 214 encodes, multiplexes, and / or digitizes outgoing baseband data to generate processed baseband or IF signals. RF transceivers 209a-209n receive the outgoing processed baseband or IF signals from TX processing circuitry 214 and upconvert the baseband or IF signals to RF signals, which are transmitted via antennas 204a-204n.
[0041] The controller / processor 224 may include one or more processors or other processing devices that control the overall operation of the AP 101. For example, the controller / processor 224 may control the reception of uplink signals and the transmission of downlink signals by the RF transceivers 209a-209n, the RX processing circuitry 219, and the TX processing circuitry 214 in accordance with well-known principles. The controller / processor 224 may also support additional functionality, such as more advanced wireless communication functions. For example, the controller / processor 224 may support beamforming or directional routing operations, in which transmitted signals from multiple antennas 204a-204n are weighted differently to effectively steer the transmitted signals in a desired direction. The controller / processor 224 may also support OFDMA operations, in which transmitted signals are assigned to different subsets of subcarriers intended for different recipients (e.g., different STAs 111-114). Any of a wide variety of other functions may be supported in the AP 101 by the controller / processor 224, including a combination of DL MU-MIMO and OFDMA in the same transmission opportunity. In some embodiments, the controller / processor 224 may include at least one microprocessor or microcontroller. The controller / processor 224 may also execute programs and other processes that reside in the memory 229, such as an OS. The controller / processor 224 may move data in and out of the memory 229 as required by the processes being executed.
[0042] The controller / processor 224 is also coupled to a backhaul or network interface 234. The backhaul or network interface 234 enables the AP 101 to communicate with other devices or systems over a backhaul connection or over a network. The interface 234 may also support communication over any suitable wired or wireless connection. For example, the interface 234 may enable the AP 101 to communicate over a wired or wireless local area network or over a wired or wireless connection to a larger network (such as the Internet). The interface 234 may include any suitable structure supporting communication over a wired or wireless connection, such as an Ethernet or RF transceiver. The memory 229 is coupled to the controller / processor 224. A portion of the memory 229 may include random access memory (RAM), and another portion of the memory 229 may include flash memory or other read-only memory (ROM).
[0043] As described in more detail below, the AP 101 may include circuitry and / or programming for managing channel sounding procedures in a WLAN. While FIG. 2A illustrates an example of an AP 101, various modifications may be made to FIG. 2A . For example, the AP 101 may include any number of each of the components shown in FIG. 2A . As a specific example, the AP may include several interfaces 234, and the controller / processor 224 may support a routing function for routing data between different network addresses. As another example, although shown as including a single instance of TX processing circuitry 214 and a single instance of RX processing circuitry 219, the AP 101 may include multiple instances of each (e.g., one per RF transceiver). Alternatively, for example, a legacy AP may include only one antenna and RF transceiver path. Also, various components in FIG. 2A may be combined, further subdivided, or omitted, and additional components may be added, according to specific needs.
[0044] As shown in FIG. 2A, in some embodiments, the AP 101 may be an AP MLD that includes multiple APs 202a-202n. Each AP 202a-202n is associated with the AP MLD 101 and includes multiple antennas 204a-204n, multiple radio frequency (RF) transceivers 209a-209n, transmit (TX) processing circuitry 214, and receive (RX) processing circuitry 219. Each AP 202a-202n may independently communicate with the controller / processor 224 and other components of the AP MLD 101. While FIG. 2A shows each AP 202a-202n having separate antennas, each AP 202a-202n may share multiple antennas 204a-204n without requiring separate antennas. Each AP 202a-202n may represent a physical (PHY) layer and a lower medium access control (MAC) layer.
[0045] 2B illustrates an example of an STA 111 according to an embodiment. The embodiment of the STA 111 illustrated in FIG. 2B is for illustrative purposes, and the STAs 111 to 114 in FIG. 1 may have the same or similar configurations. However, STAs are provided in a wide variety of configurations, and FIG. 2B does not limit the scope of the present disclosure to any particular implementation of an STA.
[0046] 2B, the STA 111 may include an antenna 205, an RF transceiver 210, TX processing circuitry 215, a microphone 220, and RX processing circuitry 225. The STA 111 may also include a speaker 230, a controller / processor 240, an input / output (I / O) interface (IF) 245, a touchscreen 250, a display 255, and memory 260. The memory 260 may include an operating system (OS) 261 and one or more applications 262.
[0047] The RF transceiver 210 receives incoming RF signals transmitted by APs of the network 100 from the antenna 205. The RF transceiver 210 downconverts the incoming RF signals to generate IF or baseband signals. The IF or baseband signals are sent to the RX processing circuitry 225, which generates processed baseband signals by filtering, decoding, and / or digitizing the baseband or IF signals. The RX processing circuitry 225 transmits the processed baseband signals to the speaker 230 (e.g., for voice data) or to the controller / processor 240 (e.g., for web browsing data) for further processing.
[0048] TX processing circuitry 215 receives analog or digital voice data from microphone 220 or other outgoing baseband data (such as web data, email, or interactive video game data) from controller / processor 240. TX processing circuitry 215 encodes, multiplexes, and / or digitizes the outgoing baseband data to generate a processed baseband or IF signal. RF transceiver 210 receives the outgoing processed baseband or IF signal from TX processing circuitry 215 and upconverts the baseband or IF signal to an RF signal, which is transmitted via antenna 205.
[0049] The controller / processor 240 may include one or more processors and execute a basic OS program 261 stored in memory 260 to control the overall operation of the STA 111. In one such operation, the controller / processor 240 controls the reception of downlink signals and the transmission of uplink signals by the RF transceiver 210, the RX processing circuitry 225, and the TX processing circuitry 215 in accordance with well-known principles. The controller / processor 240 may also include processing circuitry configured to enable management of channel sounding procedures in the WLAN. In some embodiments, the controller / processor 240 may include at least one microprocessor or microcontroller.
[0050] The controller / processor 240 may also execute other processes and programs residing in the memory 260, such as operations for managing channel sounding procedures in a WLAN. The controller / processor 240 may move data to or from the memory 260 as required by the executing processes. In some embodiments, the controller / processor 240 is configured to execute multiple applications 262, such as an application for channel sounding, including feedback calculation based on received null data packet announcements (NDPAs) and null data packets (NDPs), and an application for transmitting beamforming feedback reports in response to trigger frames (TFs). The controller / processor 240 may operate the multiple applications 262 based on an OS program 261 or in response to signals received from an AP. The controller / processor 240 is also coupled to an I / O interface 245, which provides the STA 111 with the ability to connect to other devices, such as laptop computers and handheld computers. The I / O interface 245 is a communication path between these accessories and the main controller / processor 240.
[0051] Controller / processor 240 is also coupled to input 250 (e.g., a touchscreen) and display 255. An operator of STA 111 can use input 250 to enter data into STA 111. Display 255 may be a liquid crystal display, light emitting diode display, or other display capable of rendering text and / or at least limited graphics, for example, from a website. Memory 260 is coupled to controller / processor 240. A portion of memory 260 may include RAM, and another portion of memory 260 may include flash memory or other ROM.
[0052] While FIG. 2B illustrates an example of the STA 111, various modifications may be made to FIG. 2B. For example, various components in FIG. 2B may be combined, further subdivided, or omitted, and additional components may be added, according to specific needs. In a specific example, the STA 111 may include any number of antennas 205 for MIMO communication with the AP 101. In another example, the STA 111 may not include voice communication, or the controller / processor 240 may be divided into multiple processors, such as one or more central processing units (CPUs) and one or more graphics processing units (GPUs). Also, while FIG. 2B illustrates the STA 111 configured as a cellular phone or smartphone, the STA may be configured to operate as other types of mobile or stationary devices.
[0053] As shown in FIG. 2B, in some embodiments, the AP 111 may be a non-AP MLD including multiple STAs 203a-203n. Each STA 203a-203n is associated with the non-AP MLD 111 and includes an antenna 205, an RF transceiver 210, TX processing circuitry 215, and RX processing circuitry 225. Each STA 203a-203n may communicate independently with the controller / processor 240 and other components of the non-AP MLD 111. While FIG. 2B shows each STA 203a-203n having a separate antenna, each STA 203a-203n may share the antenna 205 without requiring a separate antenna. Each STA 203a-203n may represent a physical (PHY) layer and a lower medium access control (MAC) layer.
[0054] 3 illustrates an example of multi-link communication operation according to an embodiment. The multi-link communication operation may be enabled in the IEEE 802.11be standard and any future amendments to the IEEE 802.11 standard. In FIG. 3, the AP MLD 310 may be the wireless communication devices 101 and 103 of FIG. 1, and the non-AP MLD 220 may be one of the wireless communication devices 111-114 of FIG. 1.
[0055] As shown in FIG. 3 , the AP MLD 310 may include multiple associated APs, including, for example, AP1, AP2, and AP3. Each associated AP may include a PHY interface (Link 1, Link 2, or Link 3) to the wireless medium. The AP MLD 310 may include a single MAC Service Access Point (SAP) 318 through which the AP MLD 310's associated APs communicate with higher layers (Layer 3 or network layer). Each associated AP of the AP MLD 310 may have a MAC address (lower MAC address) that is different from any other associated AP of the AP MLD 310. The AP MLD 310 may have an MLD MAC address (upper MAC address), and the associated APs share a single MAC SAP 318 to Layer 3. Thus, the associated APs share a single IP address, and Layer 3 recognizes the AP MLD 310 by assigning it a single IP address.
[0056] The non-AP MLD 320 may include multiple associated STAs, including, for example, STA1, STA2, and STA3. Each associated STA may include a PHY interface (Link 1, Link 2, or Link 3) to the wireless medium. The non-AP MLD 320 may include a single MAC SAP 328 through which the non-AP MLD 320's associated AP communicates with higher layers (Layer 3 or network layer). Each associated STA of the non-AP MLD 320 may have a MAC address (lower MAC address) that is different from any other associated STA of the non-AP MLD 320. The non-AP MLD 320 may have an MLD MAC address (upper MAC address), and the associated STAs share a single MAC SAP 328 to Layer 3. Thus, the associated STAs share a single IP address, and Layer 3 recognizes the non-AP MLD 320 by assigning it a single IP address.
[0057] The AP MLD 310 and non-AP MLD 320 may set up multiple links between their associated APs and STAs. In this example, AP1 and STA1 may set up Link 1 operating in the 2.4 GHz band. Similarly, AP2 and STA2 may set up Link 2 operating in the 5 GHz band, and AP3 and STA3 may set up Link 3 operating in the 6 GHz band. Each link may uniquely enable channel access and frame exchange between the AP MLD 310 and non-AP MLD 320, which may increase data throughput and reduce latency. Upon associating with the AP MLD on a set of links (setup links), each non-AP device is assigned a unique association identifier (AID).
[0058] 4 illustrates an example network according to an embodiment. The network illustrated in FIG. 4 is for explanation and illustration purposes. FIG. 4 does not limit the scope of the present disclosure to any particular implementation.
[0059] 4, STA 410 is a non-AP station associated with AP 430, and STA 420 is a non-AP station not associated with AP 430. Furthermore, solid lines between stations represent uplinks or downlinks with AP 430, while dashed lines between stations represent direct links.
[0060] Next-generation WLAN systems must provide improved support for low-latency applications. Today, it is not uncommon to observe multiple devices operating on the same network. Many of these devices may be latency tolerant, but still compete or contend with devices running low-latency applications for the same time and frequency resources. In some cases, an AP, as a network controller, may not have sufficient control over unregulated or unmanaged traffic competing with low-latency traffic in an infrastructure BSS (Basic Service Set). In some embodiments, an infrastructure BSS is a basic service set including an AP and one or more non-APs, and an independent BSS is a basic service set in which stations communicate with each other without the need for a central AP. Some of the unregulated or unmanaged traffic interfering with latency-sensitive traffic in an AP's BSS may originate from uplink, downlink, or direct link communications within the infrastructure BSS managed by the AP. Another source of interference may be transmissions from a neighboring infrastructure BSS (Overlapping Basic Service Set), while other sources of interference may arise from nearby independent BSSs or P2P networks. Therefore, next-generation WLAN systems need a mechanism to more effectively handle unmanaged traffic while still prioritizing low-latency traffic within the network. In WLAN networks, if STAs 410 and 420 within those networks or neighboring networks use predetermined or recommended channels for uplink, downlink, and direct-link communications, the management of BSS traffic can be significantly enhanced, thereby supporting latency-sensitive applications within the network. However, no such mechanism currently exists to address the problem.
[0061] This disclosure provides improved mechanisms for more efficiently managing traffic in a network. It also describes how an AP can allocate and announce channels for direct link and UL / DL communication. This allocation can help reduce interference in low latency traffic originating from direct link and UL / DL link communication from its own BSS or OBSS.
[0062] In some embodiments, an AP may announce or advertise channels within its BSS that are preferred for peer-to-peer (P2P) communication. These channels may be considered more conducive to P2P communication than other available channels and may be referred to in this disclosure as "preferred P2P channels" or "recommended channels."
[0063] In some embodiments, an AP may announce or advertise a preferred P2P channel within its BSS by including relevant information in beacon or probe response frames. Additionally, broadcast, multicast, or group-addressed frames may also be used to announce a preferred P2P channel.
[0064] By allocating channels for P2P communication and grouping P2P transmissions into these recommended P2P channels, an AP can effectively reduce uncontrolled interference from channels used for infrastructure BSS operation, e.g., uplink / downlink communication. This allows the AP to manage its network more effectively and can guarantee QoS requirements for STAs within its BSS. From the STA's perspective, if STAs planning to establish an independent BSS (e.g., a P2P group) or change their operating channel for P2P operation receive relevant information from the AP about recommended channels for P2P or independent BSS operation, it is best to use these recommended channels. Using the recommended channels can reduce interference originating from the infrastructure network. For example, if a STA randomly selects a channel for launching a P2P group, it may overlap with one of the channels used by a nearby AP for its BSS operation. Therefore, this random channel selection will encounter significantly more interference from the infrastructure network compared to the channel recommended by the AP for P2P communication.
[0065] In one embodiment, an AP that advertises a channel as a preferred P2P channel may prevent the AP from using the preferred P2P channel as an operating channel in its infrastructure BSS, which may create an incentive for non-AP STAs involved in P2P communications to use the preferred channel because the preferred channel is not used for traffic delivery in the infrastructure network.
[0066] In one embodiment, an AP that advertises a channel as a preferred P2P channel may still use that channel for traffic distribution in an infrastructure network. However, the AP may attempt to minimize transmissions on the channel. In some implementations, the AP may allow only trigger-enabled transmissions on the recommended channel. In some implementations, the AP may use the recommended channel for latency-sensitive or priority access traffic, such as national security or disaster management-related traffic. Other applications that limit the use of the recommended channel are possible. In one embodiment, an AP may not advertise a channel as a preferred P2P channel if the channel is used for DFS (dynamic frequency selection) or radar purposes.
[0067] In an embodiment, when an AP advertises a channel used for DFS or radar purposes as a recommended P2P channel and a non-AP STA uses that channel for P2P communication, the non-AP STA may ensure that the P2P communication does not cause interference with the DFS or radar application. In some implementations, non-AP STAs involved in P2P communication may utilize lower power communication, such as short-range communication, rather than the standard power level for P2P communication.
[0068] In an embodiment, the recommended P2P channel may belong to the set of channels used by the AP for its infrastructure BSS operation. This P2P channel may be referred to as the "infrastructure P2P channel" or "infra P2P channel" in this disclosure. Although the P2P channel is part of the AP's operating channels, the AP may not use this channel for its BSS operation during channel announcement. However, the AP may use this channel at a larger stage by performing a BSS channel switch operation.
[0069] In one embodiment, the recommended P2P channel may not belong to the set of channels used by the AP for its BSS operation. The P2P channel may be referred to as a "non-infrastructure P2P channel" or "non-infrastructure P2P channel." When a STA intending to engage in P2P communications uses the channel, the STA may not encounter interference from the infrastructure network.
[0070] 5 illustrates an example of a recommended P2P channel according to an embodiment. The channel types illustrated in FIG. 5 are for illustrative purposes only and do not limit the scope of the present disclosure to any particular implementation of a recommended P2P channel.
[0071] In the example of FIG. 5 , the AP has eight available channels, channel 1 through channel 8, during its operational link. Channels 1, 2, 5, and 8 are used for uplink (UL) and downlink (DL) communications by the AP, and channels 4 and 6 are DFS channels for special activities such as radar, defense, or weather-related activities. To minimize interference from P2P traffic on the UL / DL channels, the AP may recommend channels 3 and 7 for P2P communications. Channel 3 is used for the infrastructure P2P channel. That channel may be allocated for P2P communications even if it is part of the AP's operational channel set. For example, a TDLS (tunneled direct link setup) peer STA may use channel 3 for TDLS channel switching, moving from the base channel to an off-channel for TDLS. In some embodiments, the off-channel may be a channel used by the TDLS STA that does not overlap with the channel used by the AP associated with the TDLS STA, and the base channel is the primary channel of the BSS of the AP associated with the TDLS STA. Channel 7 is used for a non-infrastructure P2P channel. This channel is not part of the AP's operating channel set. For example, a STA may use this channel to launch a Wi-Fi Direct P2P group.
[0072] In one embodiment, an AP advertising a P2P channel may not distinguish between infrastructure and non-infrastructure P2P channels. The AP may simply allocate one channel on which it intends to accept all P2P transmissions, regardless of whether the channel is an infrastructure or non-infrastructure P2P channel. This channel may be referred to as the "mixed P2P channel."
[0073] In another embodiment, another recommended P2P channel may be defined. At the time of the P2P channel advertisement, the recommended P2P channel may be in use by the AP for its infrastructure BSS. This P2P channel may be referred to as a "coexisting P2P channel." This is particularly beneficial for parallel P2P devices that need to maintain simultaneous association with both an infrastructure network (e.g., for Internet connectivity) and a P2P group, and may prefer not to switch channels for communication between these two networks, e.g., for power saving purposes.
[0074] 6 illustrates another example of a recommended P2P channel according to an embodiment. The channel types illustrated in FIG. 6 are for illustrative purposes only and do not limit the scope of the present disclosure to any particular implementation of a recommended P2P channel.
[0075] In the example of Figure 6, the AP has eight available channels, channel 1 through channel 8, during its operational link. Channels 1, 2, 5, and 8 are used for uplink (UL) and downlink (DL) communications by the AP, and channels 4 and 6 are DFS channels for special activities such as radar, defense, or weather-related activities. To minimize interference from P2P traffic on the UL / DL channels, the AP may recommend channels 3 and 7 for P2P communications. Channel 3 is used for the mixed P2P channel, and channel 7 is used for the coexisting P2P channel.
[0076] In one embodiment, a STA that supports this feature and receives a recommendation or advertisement from a beacon frame or probe response frame may not use any other channel other than the recommended channel. In other words, the STA may use the recommended channel exclusively and avoid using any other channel. In another embodiment, a STA that supports this feature and receives a recommendation or advertisement from a beacon frame or probe response frame may have the discretion to follow or ignore the recommendation. Even if a STA supports the channel recommendation feature and receives the related required information from the AP, the STA may choose to use another channel for P2P communication that is not in the set of channels recommended by the AP.
[0077] In an embodiment, if an AP STA or non-AP STA supports the P2P channel recommendation procedure described in this disclosure, it may set the dot11ChannelRecommendationSupported MIB variable to 1. If it does not support it, it may set the dot11ChannelRecommendationSupported MIB variable to 0. In another embodiment, if an AP STA or non-AP STA supports the P2P channel recommendation procedure described in this disclosure, it may set the channel recommendation supported field in the extended capability element to 1. If it does not support it, it may set the channel recommendation supported field in the extended capability element to 0.
[0078] In an embodiment, an AP that supports the channel recommendation procedure may advertise or announce its recommended channels by including a Recommended P2P Channel Usage Info element in a beacon frame or a probe response frame.
[0079] 7 illustrates an example of a Recommended P2P Channel Usage Info element, according to an embodiment. The example format shown in FIG. 7 is for explanation and illustration purposes. The example format does not limit the scope of the present disclosure to any particular implementation.
[0080] 7, the recommended P2P channel usage info element 700 may include an element ID field, a length field, and a channel usage info list field. The element ID field may include information for identifying the recommended P2P channel usage info element 700. The length field may indicate the length of the recommended P2P channel usage info element 700. The channel usage info list field may include one or more channel usage information sub-elements. In some embodiments, each of the channel usage information sub-elements may be associated with a respective one of one or more recommended channels indicated by the recommended P2P channel usage info element 700. In some implementations, the number of channel usage information sub-elements may be the same as the number of recommended channels.
[0081] One possible form of a channel usage information subelement may include a subelement ID field, a length field, a channel info field, a country string field, a power constraint element field, an EDCA (Enhanced Distributed Channel Access) parameter set element field, a transmit power envelope element field, and a timeout interval element field.
[0082] The subelement ID field may include information for identifying the channel usage information subelement. The length field may indicate the length of the channel usage information subelement.
[0083] The Channel Info field may include information related to the recommended P2P channel. Specifically, the Channel Info field may include a Usage Mode field, an Operation Class field, and a Channel field. The Usage Mode field may include information for identifying a value indicating the use of the recommended P2P channel. Table 1 below provides an example encoding of the Usage Mode field. The Usage Mode field may be interpreted as an AP's recommendation on how to use the recommended P2P channel. The Operation Class field may indicate an Operation Class value. The Operation Class may be interpreted in the context of the country specified in the beacon frame. The Channel field may indicate a channel number that can be interpreted in the context of the indicated Operation Class. The Channel number may indicate a recommended channel for peer-to-peer communication.
[0084] [Table 1]
[0085] The country string field may be the value contained in the dot11CountryString attribute. Upon receiving this subelement, the receiving STA may set the value of dot11CountryString to the value contained in this field.
[0086] The power constraint element field may be optional. This field may contain zero or one power constraint element. The power constraint element may contain information necessary to allow the receiving STA to determine a local maximum transmit power.
[0087] The EDCA Parameter Set Elements field contains zero or one EDCA Parameter Set Elements, which may provide information required by a receiving STA for proper operation of QoS (Quality of Service) facilities during contention periods.
[0088] The transmit power envelope element field may contain zero or more transmit power envelope elements, which may provide local or specified maximum transmit power for various transmission bandwidths or channels within the bandwidth of the BSS.
[0089] The Timeout Interval Element field may contain zero or one Timeout Interval element. The Timeout Interval element may contain information about the time interval and the timeout. The Timeout Interval element may indicate the duration for which the P2P channel recommendation remains valid, as indicated in the corresponding Channel Usage Information subelement in the Recommended P2P Channel Usage Info element.
[0090] In one embodiment, the information carried on the power constraint element field, the EDCA parameter set element field, the transmit power envelope element field, and the timeout interval element field in the channel usage information subelement is intended for the receiving STA, i.e., these parameters are proposed for use by the STA if the STA intends to use the recommended channel in the corresponding channel usage information subelement for P2P communications.
[0091] In another embodiment, the information carried on the power constraint element field, EDCA parameter set element field, transmit power envelope element field, and timeout interval element field in the channel usage information subelement serves to indicate that the AP can use these parameters for the channel indicated by the corresponding channel usage information subelement.
[0092] FIG. 8 illustrates another exemplary format of a Channel Info field in a Channel Usage Information subelement, according to an embodiment.
[0093] Referring to FIG. 8, the Channel Info field may include a Usage Mode field, an Operation Class field, a Channel field, and a Type field. Various fields in the Channel Info field shown in FIG. 8 may be the same as or similar to the corresponding fields in the Channel Info field shown in FIG. 7, except for the Type field. The Type field may indicate a recommended P2P channel type. Table 2 below provides an example encoding of the Type field. The Type subfield can be used by a STA as a measure of expected interference in the advertised P2P channel. Therefore, this formulation can help a STA decide which recommended P2P channel to select for its P2P communication.
[0094] [Table 2]
[0095] 9 shows a flowchart of an example process for channel recommendation according to an embodiment. For purposes of explanation and illustration, the example process 900 may be performed by the AP 430 of FIG. 4. Although one or more operations are described or shown in a particular order, in other embodiments, the operations may be reordered differently, which may include performing multiple operations during at least partially overlapping time periods.
[0096] Process 900 may begin at operation 901. At operation 901, an AP that supports the channel recommendation process may set the dot11ChannelRecommendationSupprted value to 1. Process 900 then proceeds to operation 903.
[0097] At operation 903, the AP may decide to announce or advertise recommended channels to assist non-AP STAs for P2P communication in the network. In an embodiment, the AP may assist the non-AP STAs in setting up off-channel TDLS direct links or selecting bands and channels for independent BSSs or P2P groups. Process 900 then proceeds to operation 905.
[0098] In operation 905, the AP may advertise relevant information about recommended channels for P2P communication through a beacon frame or a probe response frame. In an embodiment, the relevant information may be included in the beacon frame or the probe response frame in a recommended P2P channel usage element shown in FIG. 7.
[0099] 10 shows a flowchart of an exemplary process for channel recommendation according to an embodiment. For purposes of explanation and illustration, the exemplary process 1000 may be performed by the non-AP STA 410 of FIG. 4, particularly when the non-AP STA intends to switch channels for an existing P2P link. Although one or more operations are described or shown in a particular order, in other embodiments, the operations may be reordered differently, which may include performing multiple operations during at least partially overlapping time periods.
[0100] Process 1000 may begin at operation 1001. At operation 1001, a non-AP STA that supports the channel recommendation process may set the dot11ChannelRecommendationSupprted value to 1. Process 1000 then proceeds to operation 1003.
[0101] At operation 1003, while the non-AP STA is operating on the P2P link (e.g., the base channel TDSL direct link), the non-AP STA may decide to switch to another operating channel for P2P communication (e.g., the off-channel TDLS direct link). In other words, the non-AP STA may move from the base channel TDSL direct link to the off-channel TDLS direct link. Then, process 1000 proceeds to operation 1005.
[0102] At operation 1005, the non-AP STA may listen for a beacon frame or a probe response frame transmitted from the AP controlling the infrastructure BSS, and may receive within the beacon frame or the probe response frame the recommended P2P channel usage element shown in FIG. 7. Process 1000 then proceeds to operation 1007.
[0103] In operation 1007, the non-AP STA may select one channel from the recommended channels indicated in the recommended P2P channel usage element in the beacon frame or probe response frame and initiate a channel switch for P2P communication.
[0104] 11 shows a flowchart of an exemplary process for a channel recommendation procedure in accordance with an embodiment. For purposes of explanation and illustration, exemplary process 1100 may be performed by non-AP STA 410 or 420 of FIG. 4, particularly when the non-AP STA intends to establish a non-infrastructure P2P group. Although one or more operations are described or shown in a particular order, in other embodiments, the operations may be reordered, which may include performing multiple operations in at least partially overlapping time periods.
[0105] Process 1100 may begin at operation 1101. At operation 1101, a non-AP STA that supports the channel recommendation process may set the dot11ChannelRecommendationSupprted value to 1. Process 1100 then proceeds to operation 1103.
[0106] At operation 1103, a non-AP STA intending to form a P2P group may determine that it does not have sufficient information to select an operating channel for the P2P group.
[0107] At operation 1105, the non-AP STA may listen for beacon frames or probe response frames transmitted from a nearby AP that controls an infrastructure BSS near the non-AP STA, and may receive within the beacon frame or probe response frame the recommended P2P channel usage element shown in FIG. 7. Process 1100 then proceeds to operation 1107.
[0108] In operation 1107, the non-AP STA may select one channel from the recommended channels indicated in the recommended P2P channel usage element in the beacon frame or probe response frame and initiate the formation of a P2P group for conducting P2P communication.
[0109] 12 illustrates another example of a Recommended P2P Channel Usage info element 1200 according to an embodiment. The example format illustrated in FIG. 12 is for illustrative purposes only and does not limit the scope of the present disclosure to any particular implementation.
[0110] 12, the Recommended P2P Channel Usage info element 1200 may include an Element ID field, a Length field, a Control field, a Power Constraint element field, an EDCA Parameter Set element field, a Transmit Power Envelope element field, a Timeout Interval element field, and a Channel Info List field. In some aspects, the various fields in the Recommended P2P Channel Usage info element 1200 shown in FIG. 12 may be the same as or similar to corresponding fields or subfields in the Recommended P2P Channel Usage info element 700 shown in FIGS. 7 and 8, with example differences described below.
[0111] The control fields may include a power constraint element present field, an EDCA parameter set element present field, a transmit power envelope element present field, a timeout interval element present field, and a channel number info field.
[0112] The power constraint element present field may indicate whether a power constraint element field is present in the recommended P2P channel usage info element 1200. When the power constraint element present field is set to 1, it may indicate that the power constraint element field is present. If not present, it is set to 0.
[0113] The EDCA Parameter Set Element Present field may indicate whether the EDCA Parameter Set Element field is present in the Recommended P2P Channel Usage Info element 1200. When the EDCA Parameter Set Element Present field is set to 1, it may indicate that the EDCA Parameter Set Element field is present. If not present, it is set to 0.
[0114] The Transmit Power Envelope Element Present field may indicate whether the Transmit Power Envelope Element field is present in the Recommended P2P Channel Usage Info element 1200. When the Transmit Power Envelope Element Present field is set to 1, it may indicate that the Transmit Power Envelope Element Present is present. Otherwise, it is set to 0.
[0115] The Timeout Interval Element Present field may indicate whether a Timeout Interval Element field is present in the Recommended P2P Channel Usage Info element 1200. When the Timeout Interval Element Present subfield is set to 1, it may indicate that the Timeout Interval Element field is present. If not present, it is set to 0.
[0116] The NumberOfChannelsInfo field may indicate how many channels are recommended in the RecommendedP2PChannelUsageInfo element 1200. In some implementations, the NumberOfChannelsInfo field may also indicate the NumberOfChannelsInfo field included in the ChannelInfoList field in the RecommendedP2PChannelUsageInfo element 1200.
[0117] The Channel Info List field may include one or more Channel Info fields, each of which may include a Usage Mode field, an Operation Class field, a Channel field, a Country String field, and a Type field, which are the same as or similar to the corresponding fields or subfields in the Recommended P2P Channel Usage Info element 700 shown in FIGS.
[0118] In some embodiments, each of the channel info fields may be associated with a respective one of one or more recommended channels indicated by the Recommended P2P Channel Usage Info element 1200. In some implementations, the number of channel info fields may be the same as the number of recommended channels.
[0119] In the example of FIG. 12, the power constraint element field, the EDCA parameter set element field, the transmit power envelope element field, and the timeout interval element field may be common to all recommended channels indicated by the recommended P2P channel usage info element 1200, or these fields shown in FIG. 7 may be specific to their corresponding channels indicated by the channel usage information subelement.
[0120] 13 illustrates another example of a Recommended P2P Channel Usage info element 1300 according to an embodiment. The example format illustrated in FIG. 13 is for illustrative purposes only and does not limit the scope of the present disclosure to any particular implementation.
[0121] 13, the recommended P2P channel usage info element 1300 may include an element ID field, a length field, a control field, a power constraint element field, an EDCA parameter set element field, a transmit power envelope element field, a timeout interval element subfield, and a channel usage element field. In some aspects, the various fields and subfields in the recommended P2P channel usage info element 1300 may be the same as or similar to corresponding fields or subfields in the recommended P2P channel usage info elements 700 and 1200 shown in FIGS. 7, 8, and 12, with example differences described below.
[0122] The channel usage element field may include one or more channel usage element subfields, each of which may include an element ID field, a length field, a usage mode field, and a channel entry field.
[0123] The Element ID field may contain information to identify the Channel Usage Element subfield, and the Length field may indicate the length of the Channel Usage Element subfield. The Usage Mode field may be interpreted as the AP's recommendation on how to use the recommended P2P channel. In some embodiments, the Usage Mode field may indicate the use of the recommended channels listed in Table 1 above.
[0124] The channel entry field may include one or more operational class and channel fields. Each operational class and channel field may include an operational class field and a channel field. The operational class field may indicate an operational class value. The operational class may be interpreted in the context of a country specified in the beacon frame. The channel field may indicate a channel number that may be interpreted in the context of the indicated operational class. The channel number may indicate a recommended channel for peer-to-peer communication.
[0125] Referring to FIG. 13, the Recommended P2P Channel Usage info element 1300 may include one or more Channel Usage element subfields, which is an example of a difference from the previous example.
[0126] In one embodiment, while advertising a recommended P2P channel, the AP may indicate how long the channel recommendation is valid. This indication may be accomplished by including a timeout interval element in the Recommended P2P Channel Usage Info element. In another embodiment, alternative mechanisms may be utilized for this purpose, such as indicating an end time for the recommendation. This may include, for example, specifying a TSF (Timing Synchronization Function) value or a duration of recommendation validity relative to the transmission time of a beacon frame or probe response frame that includes the corresponding Recommended P2P Channel Usage Info element.
[0127] In an embodiment, a first AP associated with an AP MLD and operating on a first link may advertise or announce through a beacon frame or a probe response frame a recommended P2P channel for a second link on which a second AP associated with the same AP MLD is operating.
[0128] In an embodiment, when a first AP associated with an AP MLD and operating on a first link advertises or announces a recommended P2P channel corresponding to another AP associated with the same AP MLD, the first AP may indicate the link or the other AP (operating on the link) for P2P channel recommendation. In some implementations, to indicate the link for recommendation, the first AP may include a Link ID subfield in the Recommended P2P Channel Usage info element. In some aspects, possible formats of the Recommended P2P Channel Usage info element are shown in Figures 14 and 15, which are based on Figures 12 and 13, respectively.
[0129] 14 and 15 illustrate another example of recommended P2P channel usage info elements 1400 and 1500 according to an embodiment. The example format illustrated in FIG. 14 is for illustrative purposes only. The example format does not limit the scope of the present disclosure to any particular implementation. In some aspects, various fields and subfields in the recommended P2P channel usage info element 1400 may be the same as or similar to corresponding fields or subfields in the recommended P2P channel usage info element 1200 illustrated in FIG. 12 , with example differences described below. In some aspects, various fields or subfields in the recommended P2P channel usage info element 1500 may be the same as or similar to corresponding fields or subfields in the recommended P2P channel usage info element 1300 illustrated in FIG. 13 , with example differences described below.
[0130] 14, the control field may further include a link ID field and a reserved field compared with the control field of FIG. 12. The link ID field indicates one or more links for P2P channel recommendation.
[0131] 15, the control field may further include a link ID field and a reserved field compared with the control field of FIG. 13. The link ID subfield indicates one or more links for P2P channel recommendation.
[0132] In some implementations, a link ID bitmap may be used to indicate the links for which P2P recommended channel information is provided. A possible example is shown in FIG.
[0133] FIG. 16 illustrates another example of a Recommended P2P Channel Usage info element 1600, according to an embodiment. The example format illustrated in FIG. 16 is for illustrative purposes only. The example format does not limit the scope of the present disclosure to any particular implementation. In some aspects, various fields and subfields in the Recommended P2P Channel Usage info element 1600 may be the same as or similar to corresponding fields or subfields in the Recommended P2P Channel Usage info element 1200 of FIGS. 12-15, with example differences described below.
[0134] 16, the Recommended P2P Channel Usage Info element 1600 may include an Element ID field, a Length field, a Link ID Bitmap field, and a Link Info List field. The Link ID Bitmap field may indicate the link for which the P2P channel recommendation is given. If bit position i of the Link ID Bitmap field is set to 1, it may indicate that there is a P2P channel recommendation for the i-th link. Otherwise, it may indicate that there is no P2P channel recommendation for the link.
[0135] The Link Info List field may include one or more Link Info subfields. In some implementations, the number of Link Info subfields may be equal to the number of "1" values in the Link ID Bitmap field. The order for Link Info subfields corresponding to different links may be the same as the order of the "1" values in the Link ID Bitmap subfield. In some implementations, when the Link ID Bitmap field is set as "1001010000000000", the first Link Info subfield may correspond to Link 1, the second Link Info subfield may correspond to Link 4, and the third Link Info subfield may correspond to Link 6.
[0136] In the example of FIG. 16, each Link Info List subfield may include a Control field, a Power Constraint element field, an EDCA Parameter Set element field, a Transmit Power Envelope element field, a Timeout Interval element field, and a Channel Info List field.
[0137] In some embodiments, the control field may be positioned in parallel with the Link ID Bitmap subfield as an alternative frame format to that shown in Figure 16. In some embodiments, the Power Constraint Element field, the EDCA Parameter Set Element field, the Transmit Power Envelope Element field, and the Timeout Interval Element field may be common to the channel recommendation for all links whose information is carried in the Recommended P2P Channel Usage Info element.
[0138] In some embodiments, P2P channel recommendation information, such as information carried in a Recommended P2P Channel Usage Info element, may be encrypted as unprotected in a beacon or probe response frame, allowing STAs that are not associated with an AP to still scan the beacon or probe response frame and extract the channel recommendation information.
[0139] In some embodiments, if a non-AP STA determines, after receiving channel recommendation information from the AP, that none of the recommended channels are suitable for P2P communication purposes, the non-AP STA may request the AP to modify the recommendation by sending a message. This modification may involve opening or allocating a new channel for P2P communication. Upon receiving a request from the non-AP STA, the AP may decide to allocate a new channel for P2P communication or to perform load balancing within existing channels. If not received, the AP may ignore the modification request. In some embodiments, if the AP receives such a request from at least a threshold number of non-AP STAs in the network, the AP may honor the request.
[0140] In some embodiments, an AP associated with an NSTR (non-simultaneous transmit and receive) mobile AP MLD and operating on a primary link may advertise a recommended P2P channel for other APs associated with the same NSTR mobile AP MLD and operating on a non-primary link.
[0141] In some embodiments, a first AP operating in a first BSS may coordinate with nearby APs operating in other BSSs in a multi-AP coordination manner to determine the recommended P2P channel. Alternatively, the first AP may coordinate the channel selection with other APs operating under the same Extended Service Set (ESS). This means that a centralized controller controlling the APs in the ESS may evaluate the overall enterprise network conditions and determine the recommended channel accordingly.
[0142] Reference to an element in the singular does not mean one and only one, but also one or more, unless so expressly stated. For example, "a" module may refer to one or more modules. An element preceded by "a," "an," "the," or "said" does not, without further constraints, preclude the presence of additional identical elements.
[0143] Headings and subheadings, if any, are used for convenience only and do not limit the invention. The word exemplary is used to mean serving as an example or illustration. To the extent that terms such as "including," "having," and the like are used, such terms are intended to be inclusive, similar to the term "comprising" when used as a transitional term in the claims. Relative terms such as first and second may be used to distinguish one entity or action from another, but do not necessarily require or imply any actual relationship or ordering between such entities or actions.
[0144] Phrases such as "an aspect," "the aspect," "another aspect," "several aspects," "one or more aspects," "an implementation," "the implementation," "another implementation," "several implementations," "one or more implementations," "an embodiment," "the present embodiment," "another embodiment," "some embodiments," "one or more embodiments," "a configuration," "the configuration," "another configuration," "some configurations," "one or more configurations," "the technology," "the disclosure," "the present disclosure," and other variations thereof are used for convenience and do not imply that disclosure of such phrases is essential to the technology or that such disclosure applies to all configurations of the technology. Disclosure of such phrases may apply to all configurations or one or more configurations. Disclosure of such phrases may provide one or more examples. Phrases such as "an aspect" or "several aspects" may refer to one or more aspects, and vice versa, as is the case with other phrases mentioned above.
[0145] The phrase "at least one of," preceding a list of items, with the term "and" or "or" separating any of the items, modifies the list as a whole, not each member of the list. The phrase "at least one of," does not require selection of at least one item; the phrase allows for the meaning of including any one of the items, at least one, and / or at least one of any combination of the items, and / or at least one of each of the items. By way of example, the phrases "at least one of A, B, and C" or "at least one of A, B, or C" each refer to A only, B only, or C only, any combination of A, B, and C, and / or at least one of each of A, B, and C.
[0146] It is understood that the specific order or hierarchy of steps, operations, or processes disclosed is an illustration of an example approach. It is understood that, unless otherwise stated, the specific order or hierarchy of steps, operations, or processes may be performed in different order. Some of the steps, operations, or processes may be performed together or as part of one or more other steps, operations, or processes. The accompanying method claims present elements of the various steps, operations, or processes, if any, in an example order, and are not meant to be limited to the specific order or hierarchy presented. They may be performed serially, linearly, in parallel, or in different orders. It is understood that the instructions, operations, and systems described may generally be integrated into a single software / hardware product or packaged into multiple software / hardware products.
[0147] The present disclosure is provided to enable any person skilled in the art to practice the various aspects described herein. In some instances, well-known structures and components are shown in block diagram form to avoid obscuring the concepts of the present technology. The present disclosure provides various examples of the present technology, and the present technology is not limited to these examples. Various modifications of these aspects will be readily apparent to those skilled in the art, and the principles described herein may be applied to other aspects.
[0148] All structural and functional equivalents of the elements of the various embodiments described throughout this disclosure that are known or later become known to those skilled in the art are expressly incorporated herein by reference and are intended to be encompassed by the claims. Moreover, nothing disclosed herein is intended to be made public, regardless of whether such disclosure is explicitly recited in the claims. No element of a claim is to be construed under the provisions of 35 U.S.C. § 112, paragraph 6, unless the element is expressly recited using the phrase "means for" or, in the case of a method claim, the element is recited using the phrase "step for."
[0149] The title, background art, brief description of the drawings, abstract, and drawings are hereby incorporated into this disclosure and are provided as illustrative examples of the disclosure, not as a limiting description. They are submitted with the understanding that they will not be used to limit the scope or meaning of the claims. Furthermore, in the Detailed Description, it will be recognized that the description provides illustrative examples, and that various features are grouped into various implementations for the purpose of streamlining the disclosure. This method of disclosure is not to be interpreted as reflecting an intention that the claimed subject matter requires more features than are expressly recited in each claim. Instead, as the appended claims reflect, inventive subject matter lies in less than all features of a single disclosed structure or operation. The appended claims are hereby incorporated into the Detailed Description, with each claim standing on its own as separately claimed subject matter.
[0150] The claims are not intended to be limited to the embodiments described herein, but are to be accorded the full scope consistent with the claims literally and encompass all legal equivalents. Nevertheless, none of the claims are intended, and should not be construed, to encompass subject matter that does not satisfy applicable patent law requirements. [Explanation of symbols]
[0151] 100 Wireless Network, Network 101 AP, AP MLD, Wireless Communication Device 103 AP, wireless communication device 111 STA, Non-AP MLD, Wireless Communication Device 112 STA, Wireless Communication Device 113 STA, Wireless Communication Device 114 STA, Wireless Communication Device 130 Network 202 AP 203 STA 204 Antenna 205 Antenna 209 Radio Frequency (RF) Transceiver 210 RF Transceiver 214 Transmit (TX) processing circuit configuration 215 TX processing circuit configuration 219 Receiving (RX) processing circuit configuration 220 microphones, non-AP MLD 224 Controller / Processor 225 RX processing circuit configuration 229 memory 230 speakers 234 Backhaul or Network Interface, Interface 240 Controllers / Processors 245 Input / Output (I / O) Interface (IF) 250 touch screen, input 255 display 260 memory 261 Operating System (OS), Basic OS Program 262 Applications 310 AP MLD 318 MAC Service Access Point (SAP) 320 Non-AP MLD 328 MAC SAP 410 STA 420 STA 430 AP
Claims
1. 1. An access point (AP) device in a wireless network, comprising: A transceiver; Memory and a processor coupled to the memory; wherein the processor: generating a frame indicating one or more recommended channels for peer-to-peer communication; controlling the transceiver to transmit the frames to one or more non-AP devices; An AP device configured to:
2. The AP device of claim 1 , wherein the frame is a beacon frame or a probe response frame.
3. The AP device of claim 1 , wherein the frame includes a channel usage element for the one or more recommended channels.
4. The AP device of claim 3 , wherein the channel usage element includes a usage mode field indicating usage of the one or more recommended channels.
5. The AP device of claim 3, wherein the channel usage element includes a channel field indicating one or more channel numbers for the one or more recommended channels, and an operating class field indicating one or more operating classes for the one or more recommended channels.
6. The AP device of claim 1 , wherein the one or more non-AP devices include at least one non-AP device that is not associated with the AP device.
7. The AP device of claim 1 , wherein the frame includes at least one power constraint element indicating a maximum transmit power for a receiving AP device.
8. The AP device of claim 1 , wherein the frame includes an Enhanced Distributed Channel Access (EDCA) parameter set element that indicates EDCA parameters for a transmission intended for a receiving non-AP device.
9. The AP device of claim 1 , wherein the one or more recommended channels are within a set of channels used by the AP device for an infrastructure basic service set.
10. The AP device of claim 1 , wherein the one or more recommended channels are outside a set of channels used by the AP device for an infrastructure basic service set.
11. A non-access point (AP) device in a wireless network, comprising: A transceiver; Memory and a processor coupled to the memory; wherein the processor: controlling the transceiver to receive a frame from an AP device indicating one or more recommended channels for peer-to-peer communication; selecting a channel among the one or more recommended channels for the peer-to-peer communication based on the received frame; and conducting the peer-to-peer communication with one or more non-AP devices on the selected channel; A non-AP device configured to:
12. The non-AP device of claim 11 , wherein the frame is a beacon frame or a probe response frame.
13. The non-AP device of claim 11 , wherein the frame includes a channel usage element for the one or more recommended channels.
14. The non-AP device of claim 13 , wherein the channel usage element includes a usage mode field that indicates usage of the one or more recommended channels.
15. 14. The non-AP device of claim 13, wherein the channel usage element includes a channel field indicating one or more channel numbers for the one or more recommended channels and an operational class field indicating one or more operational classes for the one or more recommended channels.
Citation Information
Patent Citations
Key BSS parameter management method suitable for multiple links and related device
CN114079941A
Method and system for performing peer-to-peer communication between stations within basic service set (BSS)
JP2012191669A
Radio communication device, radio communication method, and radio communication program
JP2016036062A
Communication device and communication method for adjusting frequencies in the 6 GHz band
JP2022542229A
Method, apparatus, and computer program product for channel usage information delivery within a peer-to-peer group
US20160295350A1