Communication method and related apparatus
By using the channel configuration negotiation and scheduled transmission mechanism of multi-AP cooperation technology, the problems of channel resource waste and insufficient reserved resource adjustment in the IEEE 802.11 series of standards are solved, realizing the efficient utilization of channel and spectrum resources and improving network performance.
Patent Information
- Authority / Receiving Office
- WO · WO
- Patent Type
- Applications
- Current Assignee / Owner
- SHENZHEN TCL NEW-TECH CO LTD
- Filing Date
- 2025-01-21
- Publication Date
- 2026-07-30
AI Technical Summary
In existing technologies, the IEEE 802.11 series of standards waste channel resources, especially when the primary channel is busy and the secondary channel is idle, resulting in the inability of devices to access the network, which leads to a waste of spectrum resources. Furthermore, they lack a channel configuration negotiation mechanism between multiple BSSs and a method for quickly adjusting reserved resources.
Through multi-AP cooperation technology, including channel configuration negotiation and scheduled transmission, and by utilizing mechanisms such as cooperative channel configuration requests, responses, and trigger frames, cooperative transmission and rapid adjustment of reserved resources among multiple BSSs can be achieved, supporting rapid adjustment of reserved resources for dynamic traffic.
It improves the utilization efficiency of channel and spectrum resources, reduces transmission interference, increases network throughput and coverage, and supports flexible adjustment of dynamic traffic.
Smart Images

Figure CN2025073773_30072026_PF_FP_ABST
Abstract
Description
Communication methods and related devices Technical Field
[0001] This application relates to the field of wireless communication technology, and in particular to a communication method and related apparatus. Background Technology
[0002] The current Institute of Electrical and Electronics Engineers (IEEE) 802.11 series of standards imposes specific usage restrictions on primary and secondary channels. Devices will connect when at least the primary channel is idle. If the primary channel is idle while secondary channels are busy, the device will choose to connect to the primary channel to ensure smooth communication. However, when the primary channel is busy and secondary channels are idle, the existing access strategy chooses not to connect to any channel, which to some extent leads to a waste of channel resources such as spectrum resources.
[0003] With the development and popularization of communication technology, the number of electronic devices accessing wireless channels is increasing, leading to a surge in demand for spectrum resources. Given the numerous limitations of existing channel access and spectrum usage mechanisms, it is difficult to guarantee these new demands, especially in scenarios where multiple BSSs overlap and interference occurs frequently. Therefore, how to efficiently utilize channel and spectrum resources has become one of the important research directions for wireless communication standards, particularly IEEE 802.11bn (Wi-Fi 8, Ultra High Reliability (UHR)) and future standards. Summary of the Invention
[0004] This application provides a communication method and related apparatus for efficiently utilizing channel and spectrum resources.
[0005] To achieve the above objectives, this application adopts the following technical solution:
[0006] The first aspect of this application provides a communication method for a second access point (AP), comprising: sending a cooperative channel configuration request to a first AP, the cooperative channel configuration request being used to request channel configuration negotiation, the first AP and the second AP being in a multi-AP cooperative relationship; and receiving a cooperative channel configuration response sent by the first AP.
[0007] A second aspect of this application provides a communication method for a first access point (AP), comprising: receiving a cooperative channel configuration request sent by a second AP, the cooperative channel configuration request being used to request channel configuration negotiation, the first AP and the second AP having a multi-AP cooperative relationship; and sending a cooperative channel configuration response to the second AP.
[0008] A third aspect of this application provides a communication method for a first AP, comprising: when a scheduled transmission start time in a first TWT schedule is reached, sending a first trigger frame to a second AP, the first trigger frame being used to indicate the initiation of multi-BSS cooperation and / or multi-site cooperation, the first trigger frame also indicating the resources actually used by the current transmission, the first AP and the second AP having a multi-BSS cooperation relationship and / or a multi-site cooperation relationship, the second AP having joined the first AP's first TWT schedule, the first TWT schedule being used for multi-site cooperation.
[0009] A fourth aspect of this application provides a communication method for a second access point (AP), comprising: receiving a first trigger frame sent by a first AP, wherein the first trigger frame further indicates the resources currently being used for transmission, the first AP and the second AP are in a multi-BSS cooperation relationship and / or a multi-AP cooperation relationship, the second AP has been added to the first AP's first TWT schedule, the first TWT schedule being used for multi-BSS cooperation; and enabling a multi-BSS cooperation mode based on the first trigger frame.
[0010] A fifth aspect of this application also provides a wireless communication device, comprising: a processor and a memory, wherein the memory is used to store a computer program, and the processor is used to call and run the computer program stored in the memory to perform the method as described in any of the preceding embodiments.
[0011] A sixth aspect of this application also provides a computer-readable storage medium, the computer-readable storage medium including instructions that, when executed, cause the method described in any of the preceding claims to be implemented. Attached Figure Description
[0012] Figure 1 shows a possible application scenario provided by this application;
[0013] Figure 2 is a flowchart of a possible communication method provided in an embodiment of this application;
[0014] Figure 2a is a schematic diagram of a possible first frame structure provided in an embodiment of this application;
[0015] Figure 2b is a schematic diagram of a possible second frame structure provided in an embodiment of this application;
[0016] Figure 2c is a schematic diagram of a possible third frame structure provided in an embodiment of this application;
[0017] Figure 3 is a flowchart illustrating another possible communication method provided in an embodiment of this application;
[0018] Figure 4 is a flowchart illustrating another possible communication method provided in an embodiment of this application;
[0019] Figure 4a is a schematic diagram of the frame structure of a possible first TWT schedule provided in an embodiment of this application;
[0020] Figure 4b is a schematic diagram of another possible frame structure of the first TWT schedule provided in the embodiment of this application;
[0021] Figure 4c is a schematic diagram of a possible TWT frame structure provided in an embodiment of this application;
[0022] Figure 4d is a schematic diagram of the frame structure of a possible first trigger frame provided in an embodiment of this application;
[0023] Figure 4e is a schematic diagram of the frame structure of another possible first trigger frame provided in an embodiment of this application;
[0024] Figure 4f is a schematic diagram of the frame structure of another possible first trigger frame provided in an embodiment of this application;
[0025] Figure 5 is a schematic diagram of the storage of a possible wireless communication device provided in an embodiment of this application. Detailed Implementation
[0026] For ease of understanding, the relevant technologies involved in the embodiments of this application will be described below.
[0027] The technical solutions of the embodiments of this application will now be described with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. All other embodiments obtained by those skilled in the art based on the embodiments of this application without creative effort are within the scope of protection of this application.
[0028] It should be understood that the term "and / or" in this document is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. Additionally, the character " / " in this document generally indicates that the preceding and following related objects have an "or" relationship. It should be noted that the naming of the parameters in this document is for ease of description; other names may be used in practice, and this application does not impose any restrictions on their specific use.
[0029] The messages described in this article include frames, instructions, commands, etc., and the names of device or functional entities, process names, frames, fields, etc. are not unique and are only used to assist in the description of functions, methods, behaviors, information, etc.
[0030] To facilitate a better understanding of this application, the following will provide relevant explanations of the technical points that may arise.
[0031] Multi-AP Coordination (MAPC) is a technology that improves network performance in a wireless network environment by enabling multiple access points to cooperate with each other. As spectrum resources become increasingly congested, research on MAPC technology is receiving more and more attention. In traditional wireless networks, each AP works independently, primarily responsible for access and data transmission for client devices within its coverage area. Multi-AP Coordination breaks this independent working model, enabling APs to share resources and coordinate transmission, further reducing transmission interference, enhancing coverage, and increasing network capacity.
[0032] In wireless networks, a Basic Service Set (BSS) typically requires one primary channel (PCH) and n secondary channels (SCHs), where n ≥ 0. The IEEE 802.11 series of standards imposes specific usage restrictions on the primary and secondary channels. For example, if a site device has frames to send, it cannot send them if its channel detection results indicate that the primary channel is busy. In other words, even if all or part of the remaining secondary channels are idle, the idle secondary channels cannot be used for transmission. Conditions or reasons for the primary channel being busy include, but are not limited to, Overlapping Basic Service Set (OBSS) interference, interference from the local BSS site, or other interference. In short, a site can only transmit when the primary channel's channel detection result is idle. Especially given that 802.11be already supports a maximum channel bandwidth of 320MHz and subsequent standards will support even more channel bandwidth, if the primary 20MHz channel is busy, even if the remaining 300MHz of secondary channels are idle, they cannot be used for transmission, which will result in a waste of spectrum resources.
[0033] In addition to MPCA technology, this application may also involve Non-primary channel access (NPCA) technology. NPCA technology means that besides the PCH, there can be one or more SCHs, called anchor channels or the primary channel (NPPCH) in NPCA. When the PCH becomes unavailable, or is known to become unavailable after a period of time, the station can switch to the NPPCH to compete for channel access. A typical scenario is that when a station detects interference (e.g., P2P transmission) caused by PPDUs from other BSSs or PPDUs from its own BSS on the PCH, it can choose to perform NPCA, i.e., switch to the NPPCH to compete for channel access. The station can be an AP station or a non-AP station.
[0034] Furthermore, considering that in multi-BSS scenarios, if the PCHs of multiple BSSs overlap, independent transmissions between APs can cause frequent interference to sites in the overlapping BSS area. Existing technologies lack a mechanism for PCH or working bandwidth negotiation between multiple BSSs. This application primarily addresses the following shortcomings:
[0035] Question 1: Regarding MAPC channel configuration / setting and triggering transmission
[0036] For baseline channel configuration, such as Operating Bandwidth (OBW) selection and PCH selection, existing standards do not define a clear process. It is generally assumed that the APs themselves select these channels, for example, through optimization algorithms or manual configuration, and then instruct non-AP sites within the BSS. For a period of time, the frequency band positions of OBW and PCH are generally relatively fixed. In traditional technologies, multiple APs should be set up on different frequency bands or channels to avoid spectrum overlap, thereby reducing interference and improving network throughput. For example, if multiple APs operate in the 2.4GHz band, it is recommended to use channels 1, 6, and 11 respectively to avoid overlap. Regarding the selection of the primary channel (PCH), existing technologies generally consider choosing the least occupied channel, i.e., the channel with the fewest other APs.
[0037] However, the situation changes with the introduction of MAPC technology, as shown in the following ways:
[0038] 1. If site deployments are dense and spectrum resources are limited, it is difficult to fully utilize non-overlapping spectrum. In the 5GHz band, when using the 20MHz mode on a single frequency, there is no overlap, and currently only 8 frequency bands can be provided; if the 80MHz mode is used and there is no overlap, only 2 frequency bands can be provided.
[0039] 2. Sites in overlapping areas are most severely affected by neighboring BSS. While transmission cooperation is possible for these sites, a channel configuration negotiation process conducive to such cooperation is lacking. Some transmission cooperation requires the location of the PCH and must be negotiated and decided upon among the APs to be effective.
[0040] 3. The existing trigger transmission process cannot support MAPC technology. On the one hand, the existing trigger frames only support non-AP sites as receivers, and cannot support AP sites as receivers; on the other hand, the existing trigger frames only support Extreme High Throughput (EHT) and earlier sites, and cannot support next-generation sites as receivers.
[0041] Question 2: How to support rapid adjustment of reserved resources for dynamic traffic?
[0042] By reserving resources for certain services (such as low-latency services) in advance through negotiation—a process known as scheduled transmission—timely transmission is facilitated and signaling overhead during actual transmission is reduced, thereby lowering transmission latency. Scheduled transmission involves agreeing on the start time and duration of transmission in advance, with channel contention and transmission initiation occurring when the scheduled time arrives. However, for transmissions with reserved resources, a mismatch between reserved and actual required transmission resources can occur when the actual transmission time arrives. This mismatch can be caused by changes in the buffer at the transmission site or dynamic changes in traffic patterns. For example, multimedia services, especially human-computer interaction services, are characterized by jitter and dynamic traffic.
[0043] Existing technologies can support the transmission of reserved resources, but lack a method for quickly adjusting these reserved resources. This can lead to insufficient reserved resources, resulting in transmission failure, or excessive or unused resources, causing overprotection. This is particularly problematic in multi-AP site collaborative MAPC scenarios, where APs reserve time-domain or frequency-domain resources during negotiation or notification phases, but lack a method for quickly adjusting these resources during actual transmission. If an AP that reserved resources doesn't use them or doesn't use them fully, other APs, following AP collaboration rules, will also refrain from using them, leading to resource waste. If an AP that reserved resources discovers insufficient reserves and transmission cannot be completed, it needs to compete for transmission opportunities again, adding waiting time and signaling redundancy.
[0044] Therefore, for transmission using reserved resources, a rapid adjustment method needs to be designed to quickly adjust the range of reserved resources to support dynamic changes in traffic. This rapid adjustment needs to allow for bidirectional adjustments, including both expanding and reducing reserved resources.
[0045] In view of this, this application proposes corresponding solutions to the problems considered above. Please refer to Figure 1, which is a possible application scenario diagram provided by this application, where BSS1 consists of AP1 site and its associated non-AP site, and BSS2 consists of AP2 site and its associated non-AP site. Non-AP STA1 and non-AP STA3 are associated with AP1, and non-AP STA2 is associated with AP2. Other non-AP STAs may also exist under BSS1 and BSS2, but this is only an example. For BSS1 and BSS2, AP1 and AP2 can use the scheme of this application to perform channel configuration for multiple BSS negotiations, thereby establishing a cooperative transmission or cooperative roaming relationship and the necessary channel configuration support; they can also use other schemes of this application to perform scheduled cooperative transmission and rapid adjustment of reserved resources between AP1 and AP2. It should be noted that the scenarios applied in this application are not limited to the examples above. For example, the method of this application can be extended to scenarios with more than two BSSs, and there is no specific limitation.
[0046] It should be noted that in the embodiments of this application, the interaction between APs can be via air interface connection or wired connection, such as an over-the-distribution system (over-the-DS) connection, which can be implemented according to the invention process. Furthermore, the PCH mentioned in this application can refer not only to the primary 20MHz (P20) channel, but also to other bandwidths, such as P40, P80, etc. For example, in a 20MHz, 40MHz, 80MHz, 160MHz, or 80+80MHz BSS, the primary channel is the primary 20MHz channel.
[0047] The following will discuss the processing flow under different circumstances to address the problems mentioned above. Please refer to Figure 2, which is a flowchart of a possible communication method provided in this application, specifically including:
[0048] 201. The first AP sends the first frame to the second AP;
[0049] In this embodiment, the first AP can autonomously or be triggered to indicate its supported operating modes to the second AP, that is, by sending a first frame to the second AP. This first frame, which can also be called an Operation Mode Indication frame, is used to indicate the operating modes supported by the first AP (AP Working / Operation Mode), as well as other cooperative transmission support information. In this embodiment, the first frame can be a Public Action frame, a Beacon frame, or other frames; this application does not limit the specific type.
[0050] The first frame can carry various types of information. For ease of understanding, we will take a Public Action frame as an example. Please refer to Figure 2a, which is a schematic diagram of a possible first frame structure provided in this application. Specifically, the Public Action frame includes an Action field, which includes a Public Action field. The Public Action field can be indicated in various ways, including but not limited to:
[0051] Indication Method 1: The Public Action field uses a value to indicate the meaning of each frame, as shown in Table 1 below. When the Public Action field value is x, it indicates that the frame is an Operation Mode Indication frame, such as the first frame. When it is y, it indicates that the frame is a Coordinated Transmission Request frame. When it is z, it indicates that the frame is a Coordinated Transmission Response frame. When it is w, it indicates that the frame is a MAPC Indication frame. Alternatively, other values and corresponding frames can be set according to the actual situation. This application does not limit the specifics.
[0052] Table 1
[0053] Method 2: In the Public Action field, a value indicates the MAPC Indication frame. As shown in Table 1 above, the Public Action field value of 'w' indicates that the frame is a MAPC Indication frame. Then, other fields in the Action field of the frame indicate which type of MAPC Indication frame it is, and the specific information it includes.
[0054] If Indication Method Two is used, the Indication Type field exists, indicating what type of frame the frame is, i.e., the first frame or another second, third, etc. When the Indication Type field in Figure 2a indicates the frame is the first frame, subsequent fields exist; otherwise, they do not. If Indication Method One is used, the Indication Type field does not exist because the Public Action field already indicates what type of frame it is.
[0055] As shown in Figure 2a, the first frame may also include an AP working / operation mode indicator field. In this application, the AP working mode can be set to include, but is not limited to, a first mode, a second mode, and a third mode.
[0056] First mode: Independent working mode, does not participate in / does not support multi-AP collaboration, can be considered the default basic mode. APs autonomously configure their working frequency band according to the baseline, and do not receive or respond to collaboration requests from other APs;
[0057] The second mode is the cooperative transmission support mode, which supports multi-AP cooperative transmission. Cooperative transmission can reduce interference between adjacent BSSs, for example, by using Coordinated Time Division Multiple Access (CTDMA), Coordinated Beamforming (CBF), Coordinated Spatial Reuse (CSR), Non-Primary Channel Access (NPCA), and Coordinated Orthogonal Frequency-Division Multiple Access (COFDMA); or by using synchronous transmission to utilize the coverage of adjacent BSSs to improve the transmission performance of edge users, such as multiple APs using Joint Transmission (JTX) to transmit the same payload to the same site.
[0058] The third mode: Collaborative roaming support mode, which supports roaming with multiple access points.
[0059] There are several methods to indicate the operating mode of the AP, including: 1) using a bitmap. For example, the first bit indicates whether the first mode is supported, the second bit indicates whether the second mode is supported, and so on. If the bitmap is 011, it indicates that the second and third modes are supported, but the first mode is not supported; 2) first use one bit to indicate whether the first mode is supported. If the first mode is not supported, then indicate whether the second and / or third modes are supported. If the first mode is supported, the second or third mode is not supported by default, because supporting the first mode means that the AP site works independently, which can be understood as not supporting the second or third mode that requires cooperation with other APs. Optionally, if the first mode is indicated as supported, the subsequent fields are reserved or do not exist.
[0060] Optionally, if the indication supports the second mode, it can further indicate the specific supported cooperative transmission methods, including but not limited to one or more of CTDMA, CBF, CSR, NPCA, COFDMA, and JTX cooperation (such as CTDMA Support, CBF Support, CSR Support, NPCA Support, COFDMA Support, and JTX Support); furthermore, it can indicate whether Supported Coordinated Transmit Power Control (CTPC) is supported. CTPC Support controls neighboring cell interference through negotiated CTPC. For example, it can also be indicated using a Bitmap.
[0061] Additionally, the first frame may indicate whether the first AP supports Negotiated Channel Switch Support (NESS). If it indicates support, it can be understood that the first AP supports negotiating with other APs to switch to a different operating frequency band or a different PCH when necessary.
[0062] Furthermore, when the first frame indicates support for channel switching negotiation between the first AP and other APs, it can further indicate whether operating channel negotiation (Operating / Operation Channel Negotiation Support) is supported in the corresponding mode. If operating channel negotiation is supported, one or more parameters such as operating frequency band, primary channel (PCH) position, and primary channel (NPPCH) position in NPCA can be negotiated, depending on the different cooperative transmission methods.
[0063] Optionally, the first frame may also indicate whether the first AP supports establishing a Coordinated TWT Establishment Support schedule for multi-BSS collaboration. If supported, it can be understood that the first AP will send a notification to establish a TWT schedule for multi-BSS collaboration and will receive requests from other APs to join the TWT schedule.
[0064] Correspondingly, the first frame can also indicate whether the first AP supports joining the TWT schedule (Coordinated TWT Participation Support) for multi-BSS cooperation. If supported, it can be understood that the first AP will receive and parse the frames sent by other APs to establish the TWT schedule for multi-BSS cooperation; and will send a request to join when necessary.
[0065] It should be noted that the information carried in the first frame can also be carried in the newly defined New Action frame or Beacon frame, which will not be elaborated here.
[0066] 202. The second AP sends the second frame to the first AP;
[0067] After receiving the first frame, the second AP determines the operating modes supported by the first AP based on the first frame. When the first AP supports the second mode and / or the third mode, the second AP can perform the following operations: Request 1, requesting to establish multi-AP cooperation with the first AP; Request 2, requesting to perform channel negotiation configuration with the first AP. It should be noted that in this application, Request 1 and Request 2 can be included in one message and requested together; or the request to establish multi-AP cooperation can be made first, and then the request to perform channel negotiation configuration can be made. The specific implementation is not limited. For example, this application will describe the first case, that is, Request 1 and Request 2 are included in one message.
[0068] Specifically, the second AP sends a second frame to the first AP. This second frame, also known as a Coordinated Transmission Request frame, requests to establish a multi-AP cooperation relationship with the first AP. The second frame is also used to request channel configuration negotiation. In this embodiment, the second frame can be a Public Action frame, a Beacon frame, or other frames. This application does not limit the specifics.
[0069] The second frame can carry various types of information. For ease of understanding, we will take the Public Action frame as an example for illustration. Please refer to Figure 2b, which is a schematic diagram of a possible second frame structure provided by this application. The Public Action frame includes an Action field, which includes a Public Action field. The indication method of the Public Action field is similar to the indication method of the Public Action field mentioned in step 201, and will not be repeated here.
[0070] Similarly, if the Public Action field uses Indication Method 2, the Indication Type field exists; if the Indication Type field indicates that the frame is the second frame, subsequent fields exist; otherwise, they do not exist.
[0071] The Coordination Type field can also indicate the type of collaboration request, which may include one or more of CTDMA Request, CBF Request, CSR Request, NPCA Request, COFDMA Request, JTX Request, and Coordinated Roaming Request, for example, indicated by a bitmap.
[0072] The second frame may also indicate the channel configuration information (Channel Config Info) of the second AP, including but not limited to PCH, and / or NPCA PCH, and / or OBW;
[0073] Optionally, when a Channel Config Request field is present to indicate a request for channel configuration negotiation, there is also a Suggested Channel Config Info field indicating the suggested channel configuration information to the first AP, and a Suggested Channel Config Num field indicating the number of Suggested Channel Config Info fields. In this application, the Suggested Channel Config Num field is optional. When the Suggested Channel Config Num field does not exist or its value is a special value or a reserved value, such as 0 or 1, a Suggested Channel Config Info field can include all the suggested information.
[0074] Alternatively, if the Channel Config Request field is not present, and the Suggested Channel Config Num field indicates a special or reserved value, such as 0, indicating that no channel configuration negotiation is requested, then the subsequent Suggested Channel Config Info field will be absent or have a value of 0.
[0075] The Suggested Channel Config Info field includes, but is not limited to, the Suggested PCH Info, the Suggested NPCA PCH Info, and / or the Suggested OBW Info. In this application, at least one of the following methods can be used to indicate the suggested channel configuration information; similar methods can also be used to indicate the channel configuration information of the second AP:
[0076] Option a) A channel bitmap is used for indication. Optionally, the channel granularity and / or the total bandwidth (Channel Width) are indicated. For example, if the channel granularity is 20MHz and the channel width is 160MHz, then each bit of the channel bitmap represents whether a channel within a 20MHz bandwidth of the 160MHz bandwidth belongs to the channel to be indicated; for example, a bitmap of 11110000 indicates that the first 80MHz bandwidth of the channel belongs to the channel to be indicated, and the last 80MHz bandwidth does not; a bitmap of 11000000 indicates that the first 40MHz bandwidth of the channel belongs to the channel to be indicated, and the last 120MHz bandwidth does not. In some implementations, the channel granularity is a default value, such as 20MHz.
[0077] Option b) uses the Operating Class and / or Channel Number to indicate the operating class. The specific Operating Class depends on the region where the operating system is located. The specific meanings of the Operating Class and Channel Number can be found in existing standards, and will not be elaborated here.
[0078] Option c) uses a combination of one or more (First Channel Number, Number of Channels) to indicate a subband. The First Channel Number indicates the first channel in a subband supporting the channel to be indicated, and the Number of Channels indicates the number of channels in a subband supporting the channel to be indicated. Consistent with standard indication methods, the descriptions of Suggested PCH or PCH or Suggested NPCA PCH or NPCA PCH can also be found in Table 2 below, where the description of Annex E can be found in the existing standard Annex E of Draft Revme 7.1.
[0079] Table 2
[0080] For example, the suggested BSS BW / OBW can be indicated in the manner described in Tables 3 and 4.
[0081] Table 3
[0082] Table 4
[0083] This application also proposes that the channel configuration information of the second AP, such as the channel configuration information suggested to the first AP and / or the channel configuration information of the first AP, can follow a first rule, which includes, but is not limited to, at least one of the following rules:
[0084] 0. For CTDMA, the PCH configured by the first AP should be within the OBW of the second AP. This facilitates the sharing of time-domain and / or frequency-domain resources between the first AP and the second AP using resource-sharing methods on channels that include at least the PCH. The PCH is typically P20, but can also be P40, P80, etc. In a special case, the first AP and the second AP are configured with the same PCH.
[0085] 1. For CBF cooperation, the PCH configured in the first AP should be within the OBW of the second AP. This is to facilitate the reduction of transmission interference between BSSs using beamforming technology on channels that include at least the PCH; the PCH is usually P20, but can also be P40, P80, etc.; an exception is that the first AP and the second AP are configured with the same PCH.
[0086] 2. For CSR cooperation, the PCH configured in the first AP should be within the OBW of the second AP. This facilitates spatially multiplexed transmission on channels that include at least the PCH; an exception is that the first AP and the second AP are configured with the same PCH.
[0087] 3. For JTX cooperation, the PCH configured in the first AP should be within the OBW of the second AP. This facilitates joint transmission on channels that include at least the PCH; an exception is that the first AP and the second AP are configured with the same PCH.
[0088] 4. For COFDMA cooperation, the first and second APs should be configured with different PCHs or different operating channels (OBWs). This facilitates the use of different frequency bands for transmission and reduces inter-band interference.
[0089] 5. For NPCA collaboration, the second AP configures the NPCA PCH based on the first AP's suggestion and instructs the first AP. The PCH configured by the first AP can be inside or outside the second AP's OBW;
[0090] 6. For roaming cooperation, the first and second APs should be configured with different PCHs or different operating channels (OBWs) to facilitate expanding the roaming frequency band coverage.
[0091] In summary, if one or more of CTDMA, CBF, CSR, and JTX cooperative transmissions are performed, the recommended PCH should be within the OBW of the second AP; if NPCA cooperation is performed, the recommended PCH can be within or outside the OBW of the second AP; if one or more of COFDMA cooperation or roaming cooperation are performed, the recommended PCH should be different from the PCH of the second AP.
[0092] It should be noted that in the above-mentioned CTDMA cooperation, CBF cooperation, CSR cooperation, JTX cooperation, or NPCA cooperation, a special case is that the first AP and the second AP are configured with the same PCH. When the first AP and the second AP send trigger frames on the PCH to indicate or allocate Resource Units (RUs), they can indicate the RU Index based on the common PCH. This is used by the receiver to find the location of the RU in the frequency band, which helps to simplify the design complexity of MAPC.
[0093] 203. The first AP sends the third frame to the second AP;
[0094] After receiving the second frame from the second AP, the first AP replies with a third frame, which can be used to indicate whether it accepts the establishment of a multi-AP cooperation relationship. This third frame is also called a Coordinated Transmission Response frame. If the third frame indicates acceptance, channel configuration can proceed according to the first rule mentioned above; alternatively, the third frame can also indicate the accepted Suggested Channel Config Info, such as the PCH configured by the first AP based on the second AP's suggestion, and / or the configured NPCA PCH, and / or the configured OBW. If channel switching is required, it can also indicate the effective time (Channel Config Delay Time).
[0095] It's important to note that the third frame may also be sent unsolicited, not as a response frame to the second frame. This means the first AP can send the third frame independently, indicating channel configuration information, Channel Config Delay Time information, or updates to the aforementioned information. For example, if the first AP needs more time for channel switching, it can send the third frame independently, indicating the new Channel Config Delay Time information. Alternatively, if the first AP has changed the PCH and / or NPCA PCH and / or OBW information, it can also send the third frame independently, indicating the updated information.
[0096] In this embodiment, the third frame can be a Public Action frame, a Beacon frame, or other frames; this application does not limit the specific frame.
[0097] The information that can be carried in the third frame also includes a variety of information. For ease of understanding, the third frame is also taken as a Public Action frame for illustration. Please refer to Figure 2c, which is a schematic diagram of a possible third frame structure provided by this application. The Public Action frame includes an Action field, which includes a Public Action field. The indication method of the Public Action field is similar to the indication method of the Public Action field mentioned in step 201, and will not be repeated here.
[0098] Similarly, if the Public Action field is used to indicate method two, the Indication Type field will exist; if the Indication Type field indicates that the frame is the third frame, subsequent fields will exist; otherwise, they will not exist.
[0099] In Figure 2c, the Accept or Reject Coordination field in the third frame indicates whether to accept cooperative transmission. If Reject Coordination is indicated, no subsequent fields are present. If the third frame is sent unsolicited, this field should indicate Accept Coordination.
[0100] Additionally, the third frame may include a Channel Config Response Type field, which may include an indication of at least one of the following:
[0101] 1) The Accept Suggestion indicates acceptance of the suggested channel configuration. If more than one set of channel configurations is suggested, the Channel Config Acceptance Index field indicates the index of the accepted channel configuration. For example, it can be indicated by a bitmap or an absolute index value.
[0102] 2) Partially Accept Suggestion indicates acceptance of the partially suggested channel configuration. Other (unaccepted) configurations can be indicated in the Additional Channel Config Info field. For example, if the PCH suggestion is accepted but the NPA PCH suggestion is not accepted, the NPA PCH information can be indicated in the Additional Channel Config Info field.
[0103] 3) The Reject indicator rejects the suggested configuration;
[0104] 4) Reject / Accept (with Additional Channel Config Info) indicates that there is a self-determined configuration. Optionally, when the Additional Channel Config Info Present field indicates its presence (e.g., set to 1), the self-determined channel configuration is indicated in the Additional Channel Config Info field; when the Additional Channel Config Info Present field indicates its absence (e.g., set to 0), the Additional Channel Config Info field is reserved or does not exist.
[0105] 5) Revised Config indicates that the third frame was sent autonomously, and subsequent information indicates updated configuration information or latency information.
[0106] In some implementations, setting the Additional Channel Config Info field to a reserved value, a special value, or its absence can also indicate that the first AP accepts all Suggested Channel Config Info, i.e., indicating an Accept Suggestion rather than a Reject result. It is understood that the Additional Channel Config Info Present field is optional; that is, it can be used to indicate whether there is no self-determined channel configuration information, in which case the Additional Channel Config Info field is 0 or empty, otherwise a specific indication is given.
[0107] Optionally, the third frame may also include a Channel Config Delay Time Present field. The Channel Config Delay Time field exists when an indication is present (e.g., a value of 1 indicates Present); it is reserved or does not exist when an indication is absent (e.g., a value of 0). If the Channel Config Delay Time Present field does not exist, a special value for the Channel Config Delay Time field can be used to indicate that no channel configuration delay is needed, such as using a value of 0.
[0108] Additionally, if the first AP needs to switch channels, the Channel Config Delay Time field indicates the delay time caused by the change in channel configuration. In other words, changing the channel configuration takes a period of time, during which collaboration cannot be carried out.
[0109] 204. The first AP performs channel switching.
[0110] After the first AP and the second AP establish multi-AP cooperation and negotiate the channel configuration, in practical applications, the first AP can perform channel switching (or PCH switching) as needed. It can use existing procedures, such as channel switching procedure, channel switch announcement element operation, or extended channel switching procedure, etc. The specifics are not elaborated in this application.
[0111] In this embodiment, through step 201, after the second AP learns from the first frame that the first AP supports the second mode and / or the third mode, it can send a second frame to the first AP to request the establishment of multi-AP cooperation and request channel configuration negotiation, and accept the response from the second AP. Regarding channel configuration negotiation, the second AP can suggest channel configuration information to the first AP based on the first rule, and the first AP can then decide whether to accept all or part of the suggestion or reject the suggestion. Alternatively, after the second AP sends the channel negotiation configuration request, the first AP can suggest channel configuration information to the second AP based on the first rule, and the second AP can decide whether to accept all or part of the suggestion or reject the suggestion. Or, the two parties can negotiate to configure part of the channel configuration information respectively. Therefore, the specific suggesting party and the suggested party are not limited in this application.
[0112] Furthermore, the description of the channel configuration negotiation section in this application can be based on either APs that have not established a multi-AP cooperation relationship, as described in this embodiment, or on APs that have established a multi-AP cooperation relationship, i.e., in the scenario where the first AP and the second AP have established a multi-AP cooperation relationship. A channel configuration negotiation request can be sent to either party to conduct channel configuration negotiation. Therefore, this application does not limit the specific application scenario.
[0113] In this embodiment, the second AP receives direct instruction information from the first AP and learns that the first AP's operating mode supports multi-AP cooperation. The second AP then requests the establishment of a cooperative transmission relationship with the first AP and performs cooperative channel configuration. This solves the problem that existing technologies do not support channel configuration negotiation between APs or BSSs, supports different channel configuration requirements for various multi-AP cooperative technologies, and improves efficiency by utilizing the overlap of spectrum.
[0114] The aforementioned second AP requests to establish a multi-AP cooperation relationship by directly instructing the first AP. This application embodiment also provides a communication method in which the second AP requests indirectly by instructing the first AP. Please refer to Figure 3 for a flowchart of another possible communication method, which includes the following steps:
[0115] 301. The first AP sends the fourth frame to the second AP;
[0116] The first AP can send a fourth frame to the second AP, either actively or by being triggered. This fourth frame is a Beacon frame or other frames, including the first AP's existing channel configuration information.
[0117] 302. The second AP sends the second frame to the first AP;
[0118] After receiving the fourth frame, the second AP parses the existing channel configuration information of the first AP within it. Based on the fourth frame, it sends a second frame to the second AP to request the establishment of a multi-AP cooperation relationship with the first AP. The specific multi-AP cooperation relationship requested includes, but is not limited to, at least one of the following:
[0119] 1. If the PCH of the first AP and the second AP are the same, or the PCH of the first AP is within the OBW of the second AP, request to establish a multi-AP cooperation relationship, including one or more of CTDMA cooperation, CBF cooperation, CSR cooperation, and JTX cooperation;
[0120] 2. If the PCH of the first AP and the second AP are the same, request to switch to another channel as the PCH for frequency division transmission to minimize interference, i.e., establish a COFDMA cooperative relationship;
[0121] 3. If the PCH of the first AP and the second AP are different, request to establish a COFDMA cooperative relationship for frequency division transmission;
[0122] 4. If the PCH of the first AP and the second AP are different, request to establish a roaming cooperation relationship and perform frequency division roaming coverage;
[0123] 5. If the PCH of the first AP and the second AP are different, or if the PCH of the first AP is outside the OBW of the second AP, request to establish a multi-AP cooperation relationship and perform channel negotiation and configuration, and perform channel configuration according to the first rule.
[0124] Additionally, the second frame may also indicate the channel configuration information of the second AP, and / or indicate the channel configuration information suggested to the first AP. In this embodiment, the frame format of the second frame is similar to that of the second frame mentioned in the embodiment shown in Figure 2, for example, the part concerning channel configuration information will not be described in detail here.
[0125] 303. The first AP sends the third frame to the second AP;
[0126] In this embodiment, the frame format of the third frame is similar to that of the third frame mentioned in the embodiment shown in Figure 2, and will not be described in detail here.
[0127] 304. The first AP performs channel switching.
[0128] In this embodiment, step 304 is similar to step 204 in the embodiment shown in Figure 2, and will not be described in detail here.
[0129] Furthermore, the description of the channel configuration negotiation section in this application can be based on either APs that have not established a multi-AP cooperation relationship, as described in this embodiment, or on APs that have established a multi-AP cooperation relationship, i.e., in the scenario where the first AP and the second AP have established a multi-AP cooperation relationship. Either party can send a channel configuration negotiation request to perform channel configuration negotiation. Therefore, this application does not limit the specific application scenario of this embodiment.
[0130] In this embodiment, the second AP establishes a cooperative transmission relationship with the first AP by receiving indirect indication information from the first AP, and performs cooperative channel configuration. This solves the problem that existing technical solutions do not support channel configuration negotiation between APs or BSSs, supports the different channel configuration requirements of various multi-AP cooperative technologies, and improves utilization efficiency by leveraging the overlap of spectrum.
[0131] Figures 2 and 3 above both propose corresponding solutions to the aforementioned problem 1. Regarding problem 2, this application also provides a corresponding solution. Please refer to Figure 4, which is a flowchart illustrating another possible communication method, specifically including the following steps:
[0132] 401. The first AP sends the first broadcast frame;
[0133] The first AP sends a first broadcast frame to advertise the first TWT schedule. The first broadcast frame indicates whether the first TWT schedule is a TWT schedule used for multi-BSS cooperation. Furthermore, it can also indicate whether it is used for one or more specific cooperation methods in multi-BSS cooperation, such as CTDMA cooperation, CBF cooperation, CSR cooperation, JTX cooperation, NPCA cooperation, etc.
[0134] In this embodiment, the first TWT schedule, also known as the MAPC TWT schedule (or MAP-TWT schedule), may further include an indication of rapid resource reservation. The rapid resource reservation is indicated in a segmented or hierarchical manner, including time-domain and / or frequency-domain resources. By rapidly adjusting the reserved resources, the risk of transmission failure due to insufficient reserved resources is reduced; or the problem of resource waste (overprotection) caused by excessive or unused reserved resources is mitigated.
[0135] The first TWT schedule may include various information. Please refer to Figure 4a, which is a schematic diagram of the frame structure of a possible first TWT schedule provided in an embodiment of this application. It includes a TWT element, which includes a Control field. Setting the Broadcast field in the Control field to 1 indicates that the TWT element is broadcast. The corresponding Broadcast TWT Recommendation field indicates that the TWT is a MAP-TWT established between APs for cooperative transmission.
[0136] Furthermore, the TWT Element indicates that the service period (SP) reserved for this TWT belongs to MAP-TWT and is used for collaborative transmission between APs; the TWT Element includes one or more MAPC TWT parameter set fields.
[0137] Accordingly, as shown in Table 5 below, a Broadcast TWT Parameter Set field, in which the Broadcast TWT Recommendation field is set to v, is referred to as a MAPC TWT Parameter Set field. The MAPC TWT Parameter Set field indicates the parameter information related to the cooperative transmission between APs, and the Broadcast TWT Parameter Set field is included in the TWT Parameter Information field.
[0138] Table 5
[0139] The first TWT schedule may also include an indication of the cooperative transport type (MAPC Type). For example, this can be placed in the Control field or the MAPC TWT Parameter Set field. If indicated in the Control field, different values can be used in the Broadcast TWT Recommendation field to distinguish different cooperative types, as shown in Table 6 below; or it can be included in the MAPC TWT Parameter Set field, similarly using different indication values to distinguish different cooperative types.
[0140] Table 6
[0141] The first TWT schedule also includes an indication for rapid resource reservation. For example, a frame structure diagram can be shown in Figure 4b. Specifically, the Control field may include the following fields: Dynamic Resource Reservation Present, Dynamic Duration Reservation Present, and Dynamic Bandwidth Reservation Present. Each field will be described in detail below.
[0142] When the Dynamic Resource Reservation Present field indicates its presence, the Dynamic Resource Reservation Information field also exists. Other stations that parse the Dynamic Resource Reservation Present field know that the first TWT schedule is used to quickly reserve resources. When the transmission time arrives, they will adjust their access behavior accordingly based on the actual resources used obtained from parsing other frames, such as the first trigger frame. Conversely, when the Dynamic Resource Reservation Present field does not indicate its presence, stations that parse this field know that the first TWT schedule reserves a fixed number of transmission resources.
[0143] In some implementations, when the Dynamic Resource Reservation Present field indicates that it exists, other stations wake up from their dormant state when the actual transmission time arrives, parse the first trigger frame, obtain the actual resources used, and adjust the duration of continued dormancy (including extending or shortening it); when the Dynamic Resource Reservation Present field indicates that it does not exist, other stations continue to dormant when the actual transmission time arrives until the reserved fixed transmission duration ends.
[0144] If the "Dynamic Duration Reservation Present" field indicates its presence (Present), then the "Dynamic Resource Reservation Information" includes dynamic time resource reservation information; if the "Dynamic Bandwidth Reservation Present" field indicates its presence (Present), then the "Dynamic Resource Reservation Information" includes dynamic bandwidth resource reservation information. Taking time resource reservation as an example, this application uses at least the following two indication methods:
[0145] Indication Method 1: The time domain can be divided into N segments with a granularity of T0. The first TWT schedule initially reserves N*T0 segments. When the transmission time arrives, based on real-time buffer conditions, channel quality, etc., the first trigger frame indicates the use of N0*T0 segments of time resources, achieving dynamic resource reservation and resolving issues of insufficient or excessive resource reservation. The time domain granularity T0 can be a predefined value or explicitly indicated in the first TWT schedule. When the transmission time arrives, the first trigger frame only needs to indicate the value of N0 to simplify signaling. For example, T0 is in units of 16us. Indicating N=2 means reserving 32us of time resources, and indicating N0=1 means actually using 16us of time resources.
[0146] Instruction Method 2: The first TWT schedule indicates the reservation of time resources of the corresponding level, such as 8ms, 16ms, 24ms, with corresponding indices of 1, 2, ..., M; when the transmission time arrives, the first trigger frame indicates which index of time resource to use. For example, indicating that the time resource with index 2 means that the actual transmission time used is 16ms, and so on, to simplify signaling.
[0147] 402. The second AP sends a first request frame to the first AP;
[0148] After receiving the first broadcast frame from the first AP, the second AP parses it to determine that the first TWT schedule is a TWT schedule for multi-BSS cooperation. The second AP then sends a first request frame to the first AP, requesting to join the first TWT schedule. Furthermore, the first request frame may also indicate whether it requests to join one or more of the following cooperation methods: CBF cooperation, CSR cooperation, JTX cooperation, and NPCA cooperation.
[0149] 403. The first AP sends a first request reply frame to the second AP;
[0150] The first AP receives the first request frame and sends a first request reply frame to the second AP, indicating whether to accept the second AP's request to join the first TWT schedule.
[0151] It should be noted that the aforementioned first broadcast frame, first request frame, and first reply frame can all be distinguished by the TWT Setup Command field. For example, referring to Table 7 below, they can be distinguished by a newly defined TWT Setup Command field value. For instance, when the TWT Setup Command field value is 'a', the frame is the first broadcast frame; when the value is 'b', the frame is the first request frame, and so on. Optionally, existing TWT Setup Command field values can also be reused, as shown in Figure 4c, and combined with the above fields to distinguish them from their existing meanings.
[0152] Table 7
[0153] 404. The second AP sends the fifth frame to the third station;
[0154] The second AP receives the first request reply frame sent by the first AP. If the first reply frame indicates acceptance of the request, the second AP sends a fifth frame within its own BSS (e.g., the second BSS) to broadcast a notification to the first TWT scheduler station within its own BSS, such as the third station, indicating the cooperative transmission with the first BSS where the first AP is located.
[0155] Optionally, the second AP may also send a fifth frame to a specific site in the second BSS, such as a third site, to notify the first TWT schedule, optionally inquiring whether to accept joining the first TWT schedule.
[0156] 405. The third station sends the fifth reply frame to the second AP;
[0157] The third station receives the fifth frame and sends a fifth reply frame to the second AP. This fifth reply frame can indicate whether to request joining the first TWT schedule, or it can receive an inquiry from the second AP confirming joining the first TWT schedule.
[0158] In addition, when the fifth reply frame indicates a request to join the first TWT schedule, the second AP also replies to the third station with an indication of whether to confirm joining the first TWT schedule.
[0159] 406. The first AP sends the first trigger frame to the second AP;
[0160] 407. The first AP, the second AP, and the third site cooperate in multiple BSS.
[0161] When the scheduled transmission time in the first TWT schedule arrives, the first AP sends a first trigger frame to instruct the second AP to enable multi-BSS cooperation; alternatively, the second AP may send the first trigger frame to instruct the first AP to enable multi-BSS cooperation for triggering transmission between AP sites.
[0162] It should be noted that the first trigger frame indicates the actual resources used in this transmission, which can be greater than, less than, or equal to the number of reserved resources in the first TWT schedule. Please refer to Figure 4d, which is a schematic diagram of the frame structure of a possible first trigger frame provided in an embodiment of this application. It includes existing fields such as the frame control field and the frame duration field, as well as a New Common Info field, which is a Common Info field and includes information indicating shared / common information to relevant users; and a New User Info field, which is a User Info field and includes information indicating the specific user indicated by the field related to the Association Key Identifier (AID) in this field.
[0163] Referring to Figures 4e and 4f provided in the embodiments of this application, the design of the first trigger frame sent to the AP includes at least one of the following methods:
[0164] 1. Trigger Type field design:
[0165] Option 1 defines a new trigger frame type using reserved bits in the Common Info field (e.g., using any of the bits B22, B26, B53, B56 to B63). This type indicates that all User Info fields in the frame only include information for the AP site and is specifically used for trigger transmission between APs. Its advantage is that it is more scalable and flexible, and can distinguish between AP AID12 identifiers and non-AP AID12 identifiers even if they are the same.
[0166] Option 2 indicates the site identifier of the receiving AP in the subsequent (New) User Info field via the AID12 field. For example, the AID12 field indicates the AP ID or a similar identifier. Option 2 requires that the AP ID or similar identifier cannot be the same as the AID or other site identifier of a non-AP site. Its advantage is that the User Info field of this frame can simultaneously indicate the location of both the AP site and the non-AP site, allowing for joint information parsing.
[0167] Option 3 explicitly indicates in the subsequent (New) User Info field that the User Info is for an AP site rather than a non-AP site, for example, by using B25. This way, even if the AID12 identifier of the AP is the same as that of the non-AP, they can be distinguished.
[0168] It should be noted that in this embodiment, option 1, option 2, and option 3 can be combined and used in combination. For example, a new trigger frame type is defined using the reserved bits of the Common Info field, indicating that the User Info field of this frame includes information for the AP site. Then, the subsequent (New) User Info field explicitly indicates that the User Info is for the AP site and not a non-AP site, and the AID12 field indicates the identifier of the receiving AP. This combined approach can include more information, allowing different sites to decide which segment to parse according to their own needs. For example, if a second AP parses the Common Info field and finds that it does not include information for the AP site, it can stop parsing.
[0169] It should be noted that the User Info field of the first trigger frame may only include AP sites and exclude non-AP sites; the recipient of the first trigger frame may also include both AP sites and non-AP sites. For example, if the first AP sends the first trigger frame in a broadcast manner, the AID12 field of the first User Info field indicates that the recipient is the second AP site, and the AID12 field of the second User Info field indicates that the recipient is the fourth site (such as a non-AP site).
[0170] 2. Indication of actual resources used in this transmission. To ensure that this indication is resolved by as many other stations as possible so they can adjust their behavior accordingly, it can be placed in the (New)Common Info field. For example, it can be indicated using any of the bits B22, B26, B53, and B56 to B63. The indication method can adopt the method for indicating reserved resources and actual resources used as described in step 401, which will not be elaborated here. In addition, the indication of actual resources used in this transmission can also be placed in other fields besides the (New)Common Info field; there are no restrictions here.
[0171] 3. UL Length Field Design: No longer limited to uplink (UL) transmission, it indicates (triggers) the L-SIG LENGTH field value in the TB PPDU of the receiver's reply, where the receiver can be an AP site. Similar to the UL BW field, UL FEC Coding Type field, UL EHT-MCS field, and UL Target Receive Power field, it can indicate (trigger) the target receive power information of the frame replied by the AP.
[0172] 4. AP Tx Power field design: When the sender is a non-AP, this field can indicate the transmission power of the non-AP site, or it can be set to a reserved value when not needed.
[0173] 5. Indicate that the receiver of the frame includes an AP site by reserving bits, for example, by using any bit from B56 to B62.
[0174] In some implementations, the first trigger frame is a Buffer Status Report Poll (BSRP) frame or a variation thereof; its receiver may include AP sites and / or non-AP sites. If both AP sites and non-AP sites are included, it can be used for transmissions within the BSS and with other BSSs simultaneously.
[0175] It should be noted that the design and transmission of the first trigger frame in this application can be based on the application scenario where the second AP and the third station have joined the first AP's TWT schedule, or as shown in Figure 4, the second AP and the STAs in this BSS can be joined to the first AP's TWT schedule first, and then multi-BSS cooperation can be carried out when the scheduled transmission time in the first TWT schedule arrives.
[0176] Furthermore, considering that buffering, channel states, and other factors may change during the process from resource reservation to actual transmission, the actual required resources may differ from the number of reserved resources in the first TWT schedule. The first AP can alleviate the problem of "insufficient reservations leading to transmission failure, requiring another competition for transmission opportunities to continue, which adds extra waiting time and signaling redundancy" by sending a first trigger frame to indicate the actual resources used.
[0177] After other sites receive the first trigger frame, the first AP, the second AP, and the third site cooperate through multi-BSS. Specifically, other sites parse the first trigger frame to obtain the actual resources used and can adjust their access behavior, such as performing off-channel transmission, P2P transmission, or sleep-to-energy saving during the actual resource usage period, and engaging in channel contention or access after the end; when the actual resources used are less than the number of reserved resources in the first TWT schedule, it can also avoid waste caused by over-reservation.
[0178] Furthermore, this application also provides a novel trigger frame, distinct from EHT and previous trigger frame designs. This novel trigger frame can support the aggregated transmission of Physical Layer Protocol Data Units (PPDUs) of different generations, such as EHT PPDUs, High Efficient (HE) PPDUs, and next-generation (e.g., Ultra High Rate, UHR) PPDUs, thereby improving scheduling efficiency. The fields included in this novel trigger frame may include, but are not limited to, at least one of the following fields:
[0179] 1. The HE / EHT P160 field (B54) in the New Common Info field: A value of 0 indicates that the trigger-based (TB) PPDU replied by the receiver on the primary 160MHz channel is an Extremely High Throughput (EHT) PPDU or a UHR PPDU; a value of 1 indicates that it is an HE TB PPDU. This method allows UHR PPDUs to be transmitted on the primary 160MHz channel, while other types of PPDUs (such as EHT PPDUs or HE PPDUs) are transmitted on other channels, enabling the aggregation of PPDUs from different generations.
[0180] 2. A new EHT / UHR P160 field has been added. Reserved bits in the New Common Info field can be used, such as B53: a value of 0 indicates that the TB PPDU replied by the receiver on the primary 160MHz channel is a UHR PPDU, and a value of 1 indicates an EHT TB PPDU; or the indication can be reversed. This method allows UHR PPDUs to be transmitted on the primary 160MHz channel, while other types of PPDUs (such as EHT PPDUs or HE PPDUs) are transmitted on other channels, achieving PPDU aggregation. The newly added EHT / UHR P160 field and HE / EHT P160 field can also be used together. For example, if the HE / EHT P160 field is set to 0 and the newly added EHT / UHR P160 field is also set to 0, then traditional devices will only parse the HE / EHT P160 field and process it according to the EHT PPDU, parsing EHT-related information to achieve backward compatibility; UHR or higher devices will parse both the HE / EHT P160 field and the newly added EHT / UHR P160 field and process it according to the UHR PPDU, further parsing UHR-related information.
[0181] 3. Special User Info Field Flag (B55) in the New Common Info field: A value of 0 indicates that the Special User Info field exists in this trigger frame. The Special User Info field is a User Info field that does not carry user-specific information but carries extended common information not provided in the (New) Common Info field. The Special User Info field includes user information related to the next-generation UHR. One or more Special User Info fields may exist, and the number of such fields can be indicated in the New Common Info field accordingly; for example, using reserved bits, a value of 0 indicates the existence of one Special User Info field, a value of 2 indicates the existence of two Special User Info fields, and other values can also be used to indicate this.
[0182] 4. The PS160 field (B39) in the New User Info field: A value of 1 indicates that the User Info field is not a HE variant, but may be of EHT or UHR type; a value of 1 also indicates that the User Info field is of EHT or UHR type (EHT / UHR variant). When the value is set to 0, combined with the value of the HE / EHT P160 field (B54 in the New Common Info field), if the HE / EHT P160 field value is set to 1, it indicates that the User Info field is of HE type (HE variant); if the HE / EHT P160 field value is set to 0, it indicates that the User Info field is of EHT or UHR type. When the PS160 field value is set to 0, and the HE / EHT P160 field value is also set to 0, combined with the newly added EHT / UHR P160 field, if the newly added EHT / UHR P160 field value is set to 0, it indicates that the User Info field is of type UHR; of course, you can also use the newly added EHT / UHR P160 field value to be set to 1 to indicate that the User Info field is of type UHR.
[0183] In summary, in this embodiment, the second AP requests to join the first TWT schedule established by the first AP. This first TWT schedule is a TWT schedule for multi-BSS cooperation. The first TWT schedule includes information on quickly reserving resources, where the quick resource reservation is based on a time-domain / frequency-domain resource segmentation or tiering method. By designing resource reservation and quick adjustment methods, dynamic changes in traffic are supported, reducing transmission latency. Furthermore, the direction of quick adjustment allows for bidirectional adjustment, including expanding and reducing reserved resources. Moreover, resource reservation (periodic or scheduled) transmissions, compared to opportunistic transmissions, result in less transmission redundancy, less transmission latency, and less energy consumption, because opportunistic transmissions require more signaling interactions, such as the control signaling overhead incurred each time an opportunistic transmission is initiated.
[0184] Furthermore, in this application, the embodiments shown in Figures 2 and 3 are used to solve the channel configuration negotiation problem before actual transmission. This can be understood as a necessary preparatory stage for MAPC. After the multi-AP cooperation relationship, i.e., the MAPC relationship, is established or the channel negotiation is successful, the reserved transmission resources can be effectively utilized for actual transmission through the embodiment shown in Figure 4. Therefore, Figures 2 or 3 in this application can be combined with the embodiment shown in Figure 4, i.e., the embodiment shown in Figure 2 or 3 can be executed first, and then the embodiment shown in Figure 4 can be executed; of course, it can also be implemented separately in conjunction with existing processes.
[0185] The above figures illustrate in detail the communication method provided in the embodiments of this application. Please refer to Figure 5, which is a storage diagram of a wireless communication device in an embodiment of this application. The wireless communication device includes a processor and a memory. The memory stores computer programs, and the processor calls and runs the computer programs stored in the memory to execute the methods provided by any embodiment of the channel determination method or channel switching method of this application, as well as any non-conflicting combination thereof. The storage medium 20 of the wireless communication device in this embodiment stores instruction / program data 21. When the instruction / program data 21 is executed, it implements the methods provided by any embodiment of the communication method of this application, as well as any non-conflicting combination thereof. The instruction / program data 21 can be formed into a program file and stored in the storage medium 20 in the form of a software product, so that a computer device (which may be a personal computer, server, or network device, etc.) or processor executes all or part of the steps of the methods in various embodiments of this application. The aforementioned storage medium 20 includes various media capable of storing program code, such as a USB flash drive, mobile hard drive, read-only memory (ROM), random access memory (RAM), magnetic disk, or optical disk, or terminal devices such as computers, servers, mobile phones, and tablets.
[0186] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces, or indirect coupling or communication connection between apparatuses or units, and may be electrical, mechanical, or other forms.
[0187] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.
[0188] The above are merely embodiments of this application and do not limit the scope of this patent application. Any equivalent structural or procedural changes made using the content of this application's specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the scope of patent protection of this application.
[0189] The above embodiments can be implemented, in whole or in part, by software, hardware (such as circuits), firmware, or any other combination thereof. When implemented using software, the above embodiments can be implemented, in whole or in part, in the form of a computer program product. The computer program product includes one or more computer instructions or computer programs. When the computer instructions or computer programs are loaded or executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that includes one or more sets of available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium. A semiconductor medium can be a solid-state drive.
[0190] It should be understood that the term "and / or" in this article is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone. A and B can be singular or plural. Additionally, the character " / " in this article generally indicates an "or" relationship between the preceding and following related objects, but it can also represent an "and / or" relationship. Please refer to the context for a more accurate understanding.
[0191] In this application, "at least one" means one or more, and "more than one" means two or more. "At least one of the following" or similar expressions refer to any combination of these items, including any combination of single or multiple items. For example, at least one of a, b, or c can mean: a, b, c, ab, ac, bc, or abc, where a, b, and c can be single or multiple.
[0192] It should be understood that in the various embodiments of this application, the order of the above-mentioned processes does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.
[0193] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.
[0194] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.
[0195] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.
[0196] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.
[0197] In addition, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.
[0198] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.
[0199] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.
Claims
1. A communication method, said method being applied to a second access point (AP), characterized in that, include: A cooperative channel configuration request is sent to the first AP. The cooperative channel configuration request is used to request channel configuration negotiation. The first AP and the second AP have a multi-AP cooperative relationship. Receive the cooperative channel configuration response sent by the first AP.
2. The method according to claim 1, characterized in that, The multi-AP cooperation relationship includes, but is not limited to, at least one of the following relationships: coordinated time division multiple access (CTDMA) cooperation relationship, coordinated beamforming (CBF) cooperation relationship, coordinated space utilization (CSR) cooperation relationship, multi-AP use (JTX) cooperation relationship, coordinated orthogonal frequency division multiple access (COFDMA) cooperation relationship, non-primary channel access (NPCA) cooperation relationship, and / or roaming cooperation relationship.
3. The method according to claim 1 or 2, characterized in that, The method further includes: Receive the first frame sent by the first AP; Based on the first frame, the multi-AP cooperation relationship is established with the first AP.
4. The method according to claim 3, characterized in that, The establishment of the multi-AP cooperation relationship with the first AP includes: Send a second frame to the first AP, the second frame being used to request the establishment of the multi-AP cooperation relationship; Receive a third frame sent by the second AP, the third frame being used to indicate acceptance of establishing the multi-AP cooperation relationship.
5. The method according to claim 4, characterized in that, The cooperative channel configuration request is included in the second frame, and the cooperative channel configuration response is included in the third frame.
6. The method according to any one of claims 1 to 5, characterized in that, The cooperative channel configuration request includes the channel configuration information of the second AP.
7. The method according to any one of claims 1 to 6, characterized in that, The cooperative channel configuration request also includes at least one set of suggested channel configuration information, which includes, but is not limited to, at least one of the following: primary channel PCH information, primary channel NPCA PCH information for non-primary channel access, and / or operating bandwidth OBW information.
8. The method according to claim 7, characterized in that, The indication methods for the at least one set of suggested channel configuration information include, but are not limited to, at least one of the following: indicating using a Channel Bitmap, indicating using an Operating Class and / or a Channel Number, or indicating using at least one combination (First Channel Number, Number of Channels).
9. The method according to any one of claims 1 to 8, characterized in that, The cooperative channel configuration response includes, but is not limited to, at least one of the following: the channel configuration suggested by the first AP based on the first rule and the channel configuration information of the second AP, the channel configuration information of the first AP, some or all of the information accepted in the channel configuration information suggested by the second AP, the indication of rejection of the channel configuration information suggested by the second AP, and / or the effective time.
10. The method according to claim 9, characterized in that, When the cooperative channel configuration response includes an autonomous transmission indication, the cooperative channel configuration response also includes updated channel configuration information and / or delayed activation delay information.
11. The method according to any one of claims 6 to 10, characterized in that, The method further includes: The channel configuration information of the first AP and / or the channel configuration information suggested by the second AP are configured based on the first rule.
12. The method according to any one of claims 9 to 11, characterized in that, The first rule includes, but is not limited to, at least one of the following rules: For the CBF collaboration, the CSR collaboration, or the JTX collaboration, the PCH configured in the first AP is within the OBW of the second AP; or, For the COFDMA cooperation or the roaming cooperation, the first AP and the second AP are configured with different PCHs / different operating channels OBWs; or, For the NPCA collaboration, the second AP configures the NPCA PCH in conjunction with the recommendations of the first AP.
13. The method according to any one of claims 3 to 12, characterized in that, The first frame is used to indicate the operating modes supported by the first AP, including supporting multi-AP collaboration.
14. The method according to claim 13, characterized in that, The working modes include, but are not limited to, a first mode, a second mode, and a third mode. The first mode is an independent working mode, the second mode is a cooperative transmission support mode, and the third mode is a cooperative roaming support mode. The first AP supports operating modes including the second mode and / or the third mode.
15. The method according to claim 14, characterized in that, When the first AP supports an operating mode including the second mode, the first frame is also used to indicate the supported multi-AP cooperative transmission type, which includes, but is not limited to, at least one of the following types: CTDMA cooperative transmission, CBF cooperative transmission, CSR cooperative transmission, NPCA cooperative transmission, COFDMA cooperative transmission, and / or JTX cooperative transmission.
16. The method according to any one of claims 2 to 12, characterized in that, The first frame includes the existing channel configuration information of the first AP.
17. The method according to claim 16, characterized in that, When the PCH of the first AP and the second AP are the same, or the PCH of the first AP is within the OBW of the second AP, the second frame is used to request the establishment of a multi-AP cooperation relationship, including but not limited to at least one of the following relationships: CBF cooperation relationship, CSR cooperation relationship, JTX cooperation relationship. or, When the first AP and the second AP have the same PCH, and the first frame indicates a request to switch to another channel as the PCH, the second frame is used to request the establishment of a multi-AP cooperation relationship, including a COFDMA cooperation relationship. or, When the PCH of the first AP and the second AP are different, the second frame is used to request the establishment of a multi-AP cooperation relationship, including but not limited to at least one of the following relationships: COFDMA cooperation relationship, roaming cooperation relationship; or, When the PCH of the first AP is different from that of the second AP, or when the PCH of the first AP is outside the OBW of the second AP, the second frame is also used to request channel negotiation configuration.
18. The method according to any one of claims 2 to 17, characterized in that, The first frame also includes a reservation capability indication, which indicates whether the first AP supports Target Wake Time Schedule (TWT) transmission for multi-BSS collaboration.
19. The method according to any one of claims 2 to 18, characterized in that, The second frame also includes a collaboration type indicator, which indicates the type of collaboration requested.
20. A communication method, the method being applied to a first AP side, characterized in that, include: The first AP receives a cooperative channel configuration request sent by the second AP. The cooperative channel configuration request is used to request channel configuration negotiation. The first AP and the second AP have a multi-AP cooperative relationship. Send a cooperative channel configuration response to the second AP.
21. The method according to claim 20, characterized in that, The method further includes: Send the first frame to the second AP; Based on the first frame, the multi-AP cooperation relationship is established with the second AP.
22. The method according to claim 21, characterized in that, Establishing the multi-AP cooperation relationship with the second AP includes: Receive a second frame sent by the second AP, the second frame being used to request the establishment of the multi-AP cooperation relationship; A third frame is sent to the second AP, the third frame being used to indicate acceptance of establishing the multi-AP cooperation relationship.
23. The method according to claim 22, characterized in that, The cooperative channel configuration request is included in the second frame, and the cooperative channel configuration response is included in the third frame.
24. The method according to any one of claims 20 to 23, characterized in that, The cooperative channel configuration request includes at least one of the following: the channel configuration information of the second AP and / or at least one set of suggested channel configuration information.
25. The method according to claim 24, characterized in that, The method further includes: Channel configuration is performed based on the first rule and the channel configuration information of the second AP.
26. The method according to claim 24 or 25, characterized in that, The cooperative channel configuration response includes, but is not limited to, at least one of the following: the channel configuration suggested by the first AP based on the first rule and the channel configuration information of the second AP, the channel configuration information of the first AP, some or all of the information accepted in the channel configuration information suggested by the second AP, the indication of rejection of the channel configuration information suggested by the second AP, and / or the effective time.
27. The method according to any one of claims 20 to 26, characterized in that, The first frame is used to indicate the operating mode of the first AP, and the operating modes supported by the first AP include supporting multi-AP collaboration.
28. The method according to any one of claims 20 to 27, characterized in that, The first frame includes the existing channel configuration information of the first AP.
29. A communication method, the method being applied to a first AP side, characterized in that, include: When the scheduled transmission start time in the first TWT schedule is reached, a first trigger frame is sent to the second AP. The first trigger frame is used to indicate the start of multi-BSS cooperation and / or multi-site cooperation. The first trigger frame also indicates the resources actually used by the current transmission. The first AP and the second AP have a multi-BSS cooperation relationship and / or a multi-site cooperation relationship. The second AP has joined the first AP's first TWT schedule. The first TWT schedule is used for multi-site cooperation.
30. The method according to claim 29, characterized in that, Before sending the first trigger frame to the second AP, the method further includes: Send a first broadcast frame, the first broadcast frame including the first TWT schedule for BSS cooperation; Receive a first request frame sent by the second AP, the first request frame being used to request to join the first TWT schedule; Send a first request reply frame to the second AP, the first request reply frame being used to indicate that the second AP is to join the first TWT schedule.
31. The method according to claim 29 or 30, characterized in that, The first TWT schedule includes, but is not limited to, at least one of the following: cooperative transmission type indication and / or fast resource reservation indication, wherein the fast resource reservation indication includes, but is not limited to, the following indication information: dynamic time resource reservation information, dynamic bandwidth resource reservation information and / or dynamic resource reservation information.
32. The method according to claim 31, characterized in that, The indication methods for the dynamic time resource reservation information include, but are not limited to, the following: indicating the time domain by segmenting it according to the time domain granularity and the number of reserved segments, and indicating the reservation of multiple levels of time resources and corresponding indexes.
33. The method according to any one of claims 29 to 32, characterized in that, The first trigger frame includes, but is not limited to, at least one of the following: a specific receiver indication, a non-AP site transmit power indication, and / or a reserved bit indication, wherein the specific receiver indication is used to indicate transmission information dedicated to APs, and the reserved bit indication indicates that the receiver includes AP sites.
34. A communication method, the method being applied to a second AP side, characterized in that, include The first trigger frame sent by the first AP is received. The first trigger frame also indicates the actual resources used by the current transmission. The first AP and the second AP have a multi-BSS cooperation relationship and / or a multi-AP cooperation relationship. The second AP has joined the first AP's first TWT schedule. The first TWT schedule is used for multi-BSS cooperation. Based on the first trigger frame, the multi-BSS collaborative mode is enabled.
35. The method according to claim 34, characterized in that, The method further includes: Receive a first broadcast frame sent by the first AP, the first broadcast frame including the first TWT schedule for BSS cooperation; Send a first request frame to the first AP, the first request frame being used to request to join the first TWT schedule; Receive a first request response frame sent by the first AP, the first request response frame being used to indicate acceptance of the second AP joining the first TWT schedule.
36. The method according to claim 35, characterized in that, After receiving the first request reply frame sent by the first AP, the method includes: A second frame is transmitted within the second BSS, the second frame including the first TWT schedule, the second broadcast frame indicating that the first TWT schedule is used for cooperative transmission with the first BSS where the first AP is located.
37. The method according to claim 36, characterized in that, The second frame is a broadcast frame, or the second frame is used to send to a specific site.
38. The method according to claim 37, characterized in that, The second frame is used to request the receiver to join the first TWT schedule.
39. The method according to claim 38, characterized in that, After transmitting the second frame within the second BSS, the method further includes: Receive a second reply frame sent by a third station within the second BSS. The second reply frame is used to indicate confirmation of joining the first TWT schedule. The third station can be any station within the second BSS, or the specific station.
40. The method according to claim 37, characterized in that, After transmitting the second frame within the second BSS, the method further includes: Receive a second response frame sent by a third site within the second BSS. The second response frame is used to request joining the first TWT schedule. The third site can be any site within the second BSS, or the specific site.
41. The method according to any one of claims 34 to 40, characterized in that, Enabling the multi-BSS collaboration mode includes: Based on the comparison between the current actual resources used in transmission and the reserved resources indicated by the first TWT schedule, the access behavior is dynamically adjusted.
42. A wireless communication device, comprising: A processor and a memory, the memory being used to store a computer program, the processor being used to invoke and run the computer program stored in the memory to perform the method as described in any one of claims 1 to 41.
43. A readable storage medium, characterized in that, The computer-readable storage medium includes instructions that, when executed, cause the method according to any one of claims 1 to 41 to be implemented.