WO2025148893A1 - Communication methods and communication apparatus - Google Patents

Abstract

Communication methods and a communication apparatus. The present application supports IEEE protocols, e.g., an IEEE 802.11be/Wi-Fi 7/EHT protocol, an IEEE 802.11bn/UHR/Wi-Fi 8 protocol, an IEEE 802.15/UWB protocol, and an IEEE 802.11bf/sensing protocol. A first communication apparatus sends a coexistence request, and a second communication apparatus receives the coexistence request. For example, the second communication apparatus may determine, on the basis of the coexistence request, whether to end the current TXOP in advance or how to schedule the first communication apparatus. The coexistence request may comprise the identifier and operation type information of the coexistence request, and the operation type information may be used for indicating an operation type of the coexistence request. The coexistence request comprises the identifier and the operation type information, such that the second communication apparatus can flexibly manage different coexistence requests.

Description

Communication method and device

This application claims the priority of the Chinese patent application filed with the State Intellectual Property Office of China on January 12, 2024, with application number 202410055206.8, and the priority of the Chinese patent application with the invention name “Communication Method and Device”, all contents of which are incorporated by reference in this application.

Technical Field

The present application relates to the field of communication technology, and in particular to a communication method and device.

Background Art

At present, there is a coexistence mechanism, in which a communication device (such as a terminal device, etc.) may include a STA, which may be a STA belonging to a multi-link device, and the communication device may also include other wireless modules, and the other wireless modules may include Bluetooth (BT), ultra wideband (UWB), Zigbee, ^5th generation (5G), etc. That is, the STA and other wireless modules can coexist in the communication device.

The STA in the above communication device can send and receive signals, and other wireless modules can also send and receive signals. There may be interference between the STA and other wireless modules. In this case, the interference situation can be indicated by a coexistence request.

Therefore, the signaling indication in the coexistence request is a problem being studied by those skilled in the art.

Summary of the invention

The embodiments of the present application provide a communication method and device that can flexibly manage different coexistence requests.

In a first aspect, an embodiment of the present application provides a communication method, which is applied to a first communication device, where the first communication device may be a Wi-Fi device, or a chip or a functional module provided in the Wi-Fi device, and the method includes:

The first communication device generates a coexistence request (coexistence request), wherein the coexistence request includes an identifier of the coexistence request and operation type information, wherein the operation type information is used to indicate an operation type of the coexistence request; and the first communication device sends the coexistence request.

In an embodiment of the present application, the first communication device may include a (transmitopportunity, TXOP) responder, and the second communication device may include a TXOP holder. The TXOP holder may be an access point (AP), and the TXOP responder may be a non-AP station (non-AP STA). Alternatively, the TXOP holder may be a non-AP STA, and the TXOP responder may be an AP. In an embodiment of the present application, the STA may include an AP STA (i.e., AP) or a non-AP STA. For example, the first communication device may include a STA and other radio frequency modules (such as a radio frequency module corresponding to the radio frequency type in the coexistence request). For example, the second communication device may also include a STA and other radio frequency modules.

In the embodiment of the present application, by sending a coexistence request including an identifier and operation type information to the second communication device, the first communication device can enable the second communication device to flexibly manage different coexistence requests in combination with the identifier and perform different operations on the coexistence requests.

In a second aspect, an embodiment of the present application provides a communication method, which is applied to a second communication device, where the second communication device may be a Wi-Fi device, or a chip or a functional module provided in the Wi-Fi device, and the method includes:

The second communication device receives a coexistence request, where the coexistence request includes an identifier of the coexistence request and operation type information, where the operation type information is used to indicate an operation type of the coexistence request; and the second communication device parses the coexistence request.

In an embodiment of the present application, the second communication device can decide whether to respect the coexistence request by parsing the coexistence request. For example, the second communication device can perform different operations on the coexistence request based on the update type information. For example, the second communication device can determine in combination with the coexistence request: the method of scheduling the first communication device (such as the first communication device is a non-AP STA), or decide whether to end the TXOP in advance, etc., or can select the working bandwidth or the maximum number of transceiver streams or the maximum modulation and coding method, etc., so that the second communication device can reasonably perform different processing.

In combination with the first aspect or the second aspect, in a possible implementation manner, the operation type of the coexistence request includes any one of the following:

A newly added coexistence request; a removed coexistence request; a coexistence request with modified parameters; or a temporarily suspended coexistence request.

In the embodiment of the present application, the coexistence request may enable the second communication device to perform different operations in combination with different operation types by indicating the above operation types.

In combination with the first aspect or the second aspect, in a possible implementation manner, the coexistence request further includes radio frequency type information, where the radio frequency type information is used to indicate a radio frequency type corresponding to the coexistence request.

In the embodiment of the present application, different radio frequency types may correspond to different service priorities, so the coexistence request may indicate its corresponding radio frequency type, so that the second communication device may determine whether to respect the coexistence request based on the radio frequency type.

In combination with the first aspect or the second aspect, in a possible implementation manner, the radio frequency type corresponding to the coexistence request includes any one of the following: Bluetooth (BT), ultra wideband (UWB), Zigbee, ^fifth generation (5G), and Wi-Fi.

In an embodiment of the present application, the first communication device may include a STA, and may also include a radio frequency module corresponding to the above radio frequency type. When the radio frequency type corresponding to the coexistence request is Wi-Fi, it may indicate that a STA in the first communication device is interfered by another STA. That is, the above Wi-Fi may be the Wi-Fi corresponding to the coexistence request in the first communication device.

In combination with the first aspect or the second aspect, in a possible implementation manner, the coexistence request further includes service priority information, where the service priority information is used to indicate a service priority of a radio frequency type corresponding to the coexistence request.

In an embodiment of the present application, the second communication device can obtain the RF type service priority situation corresponding to the coexistence request based on the service priority information, so that the second communication device can reasonably schedule the first communication device, so that the first communication device can send and receive data of different service priorities in combination with the coexistence interference situation.

In combination with the first aspect or the second aspect, in a possible implementation manner, the coexistence request also includes an interference report, where the interference report is used to indicate an interference parameter of a radio frequency type corresponding to the coexistence request.

In combination with the first aspect or the second aspect, in a possible implementation method, the interference parameters include at least one of the following: link identification, interference level, channel affected by interference, whether the interference is periodic, whether the interference is symmetrical, interference start time, interference duration, interval between adjacent interference windows, and the number of interference windows.

In an embodiment of the present application, a link identifier may indicate an identifier of a link affected by coexistence interference. An interference level may indicate the intensity or magnitude of interference to a STA in a first communication device. An interference-affected channel indicates a channel where interference is located. Interference is periodic, indicating that the interference generated by other radio frequency modules in the first communication device is periodic; interference is aperiodic, indicating that the interference generated by other radio frequency modules in the first communication device is aperiodic. Other radio frequency modules refer to other radio frequency modules (which may also include other STAs) in the first communication device except for STA. Interference is symmetric, indicating that the radio frequency module corresponding to the coexistence request will interfere with the STA in the first communication device, and the STA will also interfere with the aforementioned radio frequency module; interference is asymmetric, indicating that the radio frequency module corresponding to the coexistence request interferes with the STA, the STA will not interfere with the aforementioned radio frequency module, or the interference caused by the STA to the aforementioned radio frequency module is less than a certain threshold. Interference start time and interference duration can be used to indicate the start time and duration of coexistence interference. When interference is periodic, it means that interference will occur in a certain period, such as the start time of interference occurrence is indicated by the interference start time, and the duration of interference in a period is indicated by the interference duration. For example, the interference duration may also be referred to as an interference window. When the interference is periodic, the interference report may further include the interval between adjacent interference windows or the number of interference windows.

In combination with the first aspect or the second aspect, in a possible implementation manner, the coexistence request further includes expected behavior information, where the expected behavior information is used to indicate an expected behavior of the STA in the first communication device.

In combination with the first aspect or the second aspect, in a possible implementation manner, the coexistence request further includes time information, where the time information is used to indicate a time period corresponding to the expected behavior.

In the embodiment of the present application, in combination with the expected behavior information and the time information, the first communication device can indicate the behavior expected by the STA within the time period indicated by the time information through these two information.

In combination with the first aspect or the second aspect, in a possible implementation manner, the behavior expected by the first communication device includes any one of the following:

Sending of signals is permitted; receiving of signals is restricted; receiving of signals is permitted; sending of signals is restricted; or neither sending nor receiving of signals is permitted.

In combination with the first aspect or the second aspect, in a possible implementation manner, the coexistence request further includes a reception parameter when the first communication device is restricted from receiving a signal, or a transmission parameter when the first communication device is restricted from sending a signal.

In combination with the first aspect or the second aspect, in a possible implementation method, the sending parameters include at least one of the following: link identifier, maximum number of streams (or maximum number of spatial streams (number of spatial streams, NSS)), maximum transmit power (max Txpower), minimum transmit power, expected receive redundancy (expected Rxmargin), expected maximum data length (or maximum TB-PPDU length (max TB-PPDU length)), expected bandwidth (expected bandwidth, expected BW), modulation coding method or maximum LDPC codeword length (max LDPC codeword length).

In combination with the first aspect or the second aspect, in a possible implementation, the receiving parameters include at least one of the following: a link identifier, a maximum number of streams, an expected receiving redundancy, an expected maximum data length, an expected bandwidth, a modulation coding method, or a maximum LDPC codeword length.

In combination with the first aspect or the second aspect, in a possible implementation method, the coexistence request is carried in an initial control frame (ICF) or an initial control response (ICR) frame, and the ICF or the ICR frame also includes monitoring mode enable information, and the monitoring mode enable information is used to instruct the first communication device to start the monitoring mode (or called listening mode) or exit the monitoring mode.

In combination with the first aspect or the second aspect, in a possible implementation manner, the coexistence request further includes monitoring mode enabling information, where the monitoring mode enabling information is used to instruct the first communication device to turn on the monitoring mode or exit the monitoring mode.

In combination with the first aspect or the second aspect, in one possible implementation, when the listening mode enable information is a first value, it indicates that the first communication device exits the listening mode, and the mode to be switched to by the first communication device is determined based on power management information; or, when the listening mode enable information is a second value, it indicates that the first communication device turns on the listening mode, and the state of the first communication device is determined based on at least one of the power management information or more data information.

In combination with the first aspect, in a possible implementation manner, the method further includes: the first communication device receiving a feedback result regarding the coexistence request from the second communication device.

In the embodiment of the present application, the second communication device can send a feedback result so that the first communication device can effectively know whether the second communication device complies with the coexistence request, so as to know the processing result of the second communication device and improve communication efficiency.

In combination with the second aspect, in a possible implementation manner, the method further includes: the second communication device sending a feedback result about the coexistence request to the first communication device.

In combination with the first aspect or the second aspect, in a possible implementation method, the feedback result includes a cache report, and the cache report includes at least one of the following: the size of the cached data, the minimum remaining time of the cached data, or the service priority of the cached data; or, the feedback result includes more data fields, and the more data fields are used to indicate the state of the first communication device; or, the feedback result includes indication information, and the indication information is used to indicate that the scheduling of the first communication device in this transmission opportunity TXOP has ended.

In a third aspect, an embodiment of the present application provides a first communication device, configured to execute the method in the first aspect or any possible implementation. The first communication device includes a module for executing the method in the first aspect or any possible implementation.

In a fourth aspect, an embodiment of the present application provides a second communication device, configured to execute the method in the second aspect or any possible implementation. The second communication device includes a module for executing the method in the second aspect or any possible implementation.

In a fifth aspect, an embodiment of the present application provides a first communication device, the first communication device comprising a processor, configured to execute the method described in the first aspect or any possible implementation. The processor is configured to execute a program stored in a memory, and when the program is executed, the method described in the first aspect or any possible implementation is executed.

In a possible implementation manner, the memory is located outside the first communication device.

In a possible implementation manner, the memory is located in the first communication device.

In the embodiment of the present application, the processor and the memory may also be integrated into one device, that is, the processor and the memory may also be integrated together. Exemplarily, the first communication device may be a chip.

In a possible implementation, the first communication device further includes a transceiver, and the transceiver is used to receive information or send information. Exemplarily, the first communication device can be a multi-link device (MLD).

In a sixth aspect, an embodiment of the present application provides a second communication device, the second communication device comprising a processor, configured to execute the method described in the second aspect or any possible implementation. The processor is configured to execute a program stored in a memory, and when the program is executed, the method described in the second aspect or any possible implementation is executed.

In a possible implementation manner, the memory is located outside the second communication device.

In a possible implementation manner, the memory is located in the second communication device.

In the embodiment of the present application, the processor and the memory may also be integrated into one device, that is, the processor and the memory may also be integrated together. Exemplarily, the second communication device may be a chip.

In a possible implementation, the second communication device further includes a transceiver, and the transceiver is used to receive information or send information. Exemplarily, the first communication device may be a multi-link device.

In the seventh aspect, an embodiment of the present application provides a first communication device, which includes a logic circuit and an interface, and the logic circuit and the interface are coupled; the interface is used to input and/or output information, and the logic circuit is used to execute the method described in the first aspect or any possible implementation method.

In an eighth aspect, an embodiment of the present application provides a second communication device, which includes a logic circuit and an interface, and the logic circuit and the interface are coupled; the interface is used to input and/or output information, and the logic circuit is used to execute the method described in the second aspect or any possible implementation method.

In a ninth aspect, an embodiment of the present application provides a computer-readable storage medium, which is used to store a computer program. When the computer-readable storage medium is run on a computer, the method shown in any one of the first to second aspects or any possible implementation method is executed.

In a tenth aspect, an embodiment of the present application provides a computer program product, which, when executed on a computer, enables the method shown in any one of the first to second aspects or any possible implementation method to be executed.

In an eleventh aspect, an embodiment of the present application provides a computer program. When the computer program is run on a computer, the method shown in any one of the first to second aspects or any possible implementation is executed.

In the twelfth aspect, an embodiment of the present application provides a communication system, which includes a first communication device and/or a second communication device, the first communication device is used to execute the method shown in the above-mentioned first aspect or any possible implementation of the first aspect, and the second communication device is used to execute the method shown in the above-mentioned second aspect or any possible implementation of the second aspect.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG1 is a schematic diagram of the architecture of a communication system provided in an embodiment of the present application;

FIG2a is a schematic diagram of the architecture of another communication system provided in an embodiment of the present application;

FIG2b is a schematic diagram of an address of an MLD provided in an embodiment of the present application;

FIG3 is a schematic diagram of a communication device provided in an embodiment of the present application;

FIG4a is a schematic diagram of a format of an MPDU provided in an embodiment of the present application;

FIG4b is a schematic diagram of the format of a frame control field provided in an embodiment of the present application;

FIG4c is a schematic diagram of the format of an aggregated-control (A-control) field provided in an embodiment of the present application;

FIG5 is a flow chart of a communication method provided in an embodiment of the present application;

FIG6a is a schematic diagram of a format of an expected behavior field provided in an embodiment of the present application;

FIG6b is a schematic diagram of a format of a coexistence request provided in an embodiment of the present application;

FIG7 is a flow chart of a communication method provided in an embodiment of the present application;

FIG8a is a schematic diagram of a format of a trigger frame provided in an embodiment of the present application;

FIG8b is a schematic diagram of the format of an extremely high throughput trigger-based PPDU (EHT TB PPDU) provided in an embodiment of the present application;

FIG8c is a schematic diagram of the format of an ultra-high reliability (UHR) TB PPDU provided in an embodiment of the present application;

FIG8d is a schematic diagram of the format of a multi-STA block acknowledgment (multi-STA BA) frame provided in an embodiment of the present application;

FIG9 is a schematic diagram of the structure of a communication device provided in an embodiment of the present application;

FIG10 is a schematic diagram of the structure of a communication device provided in an embodiment of the present application;

FIG. 11 is a schematic diagram of the structure of a communication device provided in an embodiment of the present application.

DETAILED DESCRIPTION

To facilitate understanding of the technical solution of the present application, the present application will be further described below in conjunction with the accompanying drawings.

The terms "first" and "second" in the specification, claims and drawings of this application are only used to distinguish different objects, rather than to describe a specific order. In addition, the terms "including" and "having" and any variations thereof are intended to cover non-exclusive inclusions. For example, a process, method, system, product or device that includes a series of steps or units is not limited to the listed steps or units, but may optionally include steps or units that are not listed, or may optionally include other steps or units that are inherent to these processes, methods, products or devices.

The "embodiment" mentioned in this article means that the specific features, structures or characteristics described in conjunction with the embodiment can be included in at least one embodiment of the present application. The appearance of this phrase in various places in the specification does not necessarily refer to the same embodiment, nor is it an independent or alternative embodiment that is mutually exclusive with other embodiments. It can be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

In the present application, "at least one (item)" means one or more, "more than one" means two or more, "at least two (items)" means two or three and more than three, and "and/or" is used to describe the association relationship of associated objects, indicating that three relationships may exist. For example, "A and/or B" can mean: only A exists, only B exists, and A and B exist at the same time, where A and B can be singular or plural. "Or" means that two relationships may exist, such as only A exists, only B exists; when A and B are not mutually exclusive, it can also mean that there are three relationships, such as only A exists, only B exists, and A and B exist at the same time. The character "/" generally indicates that the associated objects before and after are in an "or" relationship. "At least one of the following" or similar expressions refers to any combination of these items. For example, at least one of a, b or c can mean: a, b, c, "a and b", "a and c", "b and c", or "a and b and c".

In this application, "indication" may include direct indication, indirect indication, explicit indication, and implicit indication. When describing that a certain indication information is used to indicate A, it can be understood that the indication information carries A, directly indicates A, or indirectly indicates A.

In the present application, the information indicated by the indication information is referred to as the information to be indicated. In the specific implementation process, there are many ways to indicate the information to be indicated, such as but not limited to, the information to be indicated can be directly indicated, such as the information to be indicated itself or the index of the information to be indicated. The information to be indicated can also be indirectly indicated by indicating other information, wherein there is an association relationship between the other information and the information to be indicated. It is also possible to indicate only a part of the information to be indicated, while the other parts of the information to be indicated are known or agreed in advance. For example, the indication of specific information can also be achieved by means of the arrangement order of each information agreed in advance (for example, specified by the protocol), thereby reducing the indication overhead to a certain extent. In addition, the information to be indicated can be sent as a whole, or it can be divided into multiple sub-information and sent separately, and the sending period and/or sending time of these sub-information can be the same or different.

In this application, "send" and "receive" indicate the direction of signal transmission. For example, "send information to XX" can be understood as the destination of the information is XX, which can include direct sending through the air interface, and also include indirect sending through the air interface by other units or modules. "Receiving information from YY" can be understood as the source of the information is YY, which can include direct reception from YY through the air interface, and also include indirect reception from YY through the air interface from other units or modules. "Send" can also be understood as the "output" of the chip interface, and "receive" can also be understood as the "input" of the chip interface. In other words, sending and receiving can be performed between devices, for example, between network devices and terminal devices, or can be performed within a device, for example, sending or receiving between components, modules, chips, software modules or hardware modules within the device through a bus, wiring or interface.

The present application provides a communication method and device that can flexibly manage coexistence requests.

The following introduces the communication system involved in the embodiments of the present application.

The technical solution provided in the embodiment of the present application can be applied to wireless local area network (WLAN) systems, such as Wi-Fi, etc. The method provided in the embodiment of the present application can be applied to the Institute of Electrical and Electronics Engineers IEEE 802.11 series protocols, such as 802.11be protocol, 802.11bn protocol (802.11bn is also called Wi-Fi 8, or ultra high reliability (UHR) or ultra high reliability and throughput (UHRT) or the next generation protocol of 802.11bn protocol or support ambient power (ambient power) r, AMP) protocols, etc., which are not listed one by one. The technical solution provided in the embodiment of the present application can also be applied to wireless personal area networks (wireless personal area networks, WPANs) based on millimeter wave (millimeter wave, MMW) and ultra wideband (ultra wideband, UWB) technologies. For example, the method provided in the embodiment of the present application can be applied to the IEEE802.15 series of protocols, such as 802.15.4a protocol, 802.15.4z protocol or 802.15.4ab protocol, or a future generation of UWB. B WPAN protocol, etc., are not listed one by one. The technical solution provided in the embodiment of the present application can also be applied to the following communication systems, for example, it can be an Internet of Things (IoT) system, vehicle-to-everything (V2X, X can represent anything), device-to-device (D2D), narrowband Internet of Things (NB-IoT) system, long-term evolution (LTE) system, fifth-generation (5G) communication system, and new communication systems that will emerge in the future development of communication. For example, the V2X can include: vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I), vehicle-to-pedestrian (V2P) or vehicle-to-network (V2N) communication, etc.

WLAN systems can provide high-speed and low-latency transmission. With the continuous evolution of WLAN application scenarios, WLAN systems will be applied to more scenarios or industries, such as the Internet of Things industry, the Internet of Vehicles industry or the banking industry, corporate offices, sports stadiums and exhibition halls, concert halls, hotel rooms, dormitories, wards, classrooms, supermarkets, squares, streets, production workshops and warehouses, etc. Of course, devices that support WLAN communication or perception (such as access points or sites) can be sensor nodes in smart cities (such as smart water meters, smart electricity meters, and smart air detection nodes), smart devices in smart homes (such as smart cameras, projectors, display screens, televisions, speakers, refrigerators, washing machines, etc.), nodes in the Internet of Things, entertainment terminals (such as wearable devices such as augmented reality (AR) and virtual reality (VR)), smart devices in smart offices (such as printers, projectors, loudspeakers, speakers, etc.), Internet of Vehicles devices in the Internet of Vehicles, infrastructure in daily life scenarios (such as vending machines, self-service navigation desks in supermarkets, self-service checkout equipment, self-service ordering machines, etc.), and equipment in large sports and music venues.

Although the embodiments of the present application mainly take WLAN as an example, especially the network applied to the IEEE 802.11 series of standards. Various aspects involved in the embodiments of the present application can be extended to other networks that adopt various standards or protocols. For example, Bluetooth, high performance radio LAN (HIPERLAN) (a wireless standard similar to the IEEE 802.11 standard) and wide area network (WAN) or other networks known now or developed later.

The method provided in the embodiment of the present application can be implemented by a communication device in a communication system. For example, the communication device can be an access point (AP) or a station (STA) or a multi-link device. The following is a detailed description:

AP is a device with wireless communication function, supports communication or perception or energy transmission using WLAN protocol, has the function of communicating or perceiving or energy transmission with other devices in WLAN network (such as non-access point station (non-AP STA) or other access points), and of course, can also have the function of communicating or perceiving or energy transmission with other devices. Alternatively, the access point is equivalent to a bridge connecting wired network and wireless network, and its main function is to connect various wireless network clients together and then connect the wireless network to Ethernet. In the WLAN system, the access point can be called access point station (AP STA). The device with wireless communication function can be a complete device, or a chip, processing system or functional module installed in the complete device. The device installed with these chips or processing systems or functional modules can implement the methods and functions of the embodiments of the present application under the control of the chips or processing systems or functional modules. The AP in the embodiments of the present application is a device that provides services for non-AP STA, and can support 802.11 series protocols or subsequent protocols. For example, an access point can be an access point for a terminal (such as a mobile phone) to enter a wired (or wireless) network. It is mainly deployed in homes, buildings, and parks, with a typical coverage radius of tens to hundreds of meters. Of course, it can also be deployed outdoors. For another example, an AP can be a communication server, router, switch, bridge, or other communication entity; an AP can include various forms of macro base stations, micro base stations, relay stations, and the like. Of course, an AP can also be a chip or processing system or module in the various forms of equipment mentioned above, so as to implement the methods and functions of the embodiments of the present application. The description of the AP here also applies to the AP multi-link device (AP multi-link device, AP MLD) shown below.

STA is a device with wireless communication function, supports communication or perception or energy transmission using WLAN protocol, and has the ability to communicate or perceive or transmit energy with other non-AP STA or access points in the WLAN network. In the WLAN system, the station can be called a non-access point station (non-AP STA). For example, STA is any user communication device that allows the user to communicate or perceive or transmit energy with the AP and then communicate with the WLAN. The device with wireless communication function can be a complete device, or a chip or processing system or functional module installed in the complete device. The device installed with these chips or processing systems or functional modules can implement the methods and functions of the embodiments of the present application under the control of the chip or processing system or functional module. For example, STA can be a wireless communication chip, a wireless sensor or a wireless communication terminal, etc., and can also be called a user. For another example, STA can be a mobile phone supporting Wi-Fi communication function, a tablet supporting Wi-Fi communication function, a set-top box supporting Wi-Fi communication function, a smart TV supporting Wi-Fi communication function, a smart wearable device supporting Wi-Fi communication function, a vehicle-mounted communication device supporting Wi-Fi communication function, and a computer supporting Wi-Fi communication function. Of course, STA can also be a chip or processing system or module in the above-mentioned various forms of devices, so as to implement the methods and functions of the embodiments of the present application. The description of STA here also applies to the non-AP multi-link device (non-AP multi-link device, non-AP MLD) shown below.

For ease of description, when referring to specific examples below, STA may include AP STA (or AP) or non-AP STA.

A multi-link device (MLD) is a device that has multiple STAs (such as APs or non-AP STAs) working on different frequency bands or channels. When the channel spacing between two stations in a multi-link device is large enough, they can operate independently without interfering with each other. If any two stations can support one station sending while the other station is receiving, the two stations can be said to support simultaneous transmission and reception (STR) capabilities. Otherwise, the two stations are said to not have non-simultaneous transmission and reception (NSTR) capabilities. A multi-link device includes multiple subordinate stations, which can be physical stations or logical stations. Each station can work on a link, a frequency band, or a channel. The subordinate stations shown here can be APs or non-AP STAs. For the convenience of description, in the embodiments of the present application, a multi-link device whose subordinate station is an AP may be referred to as a multi-link AP or a multi-link AP device or an AP multi-link device (AP multi-link device, AP MLD). A multi-link device whose subordinate station is a non-AP STA may be referred to as a multi-link STA or a multi-link STA device or a STA multi-link device (STA multi-link device, STA MLD), or a multi-link device whose subordinate station is a non-AP STA may be referred to as a multi-link non-AP or a multi-link non-AP device or a non-AP multi-link device (non-AP multi-link device, non-AP MLD). A multi-link device (which may be either a non-AP MLD or an AP MLD) is a communication device with a wireless communication function. The communication device may be a complete device, or may be a chip or a processing system installed in the complete device, etc. The devices installed with these chips or processing systems may implement the methods and functions of the embodiments of the present application under the control of these chips or processing systems.

FIG. 1 is a schematic diagram of the architecture of a communication system provided by an embodiment of the present application. As shown in FIG. 1 , the embodiment of the present application can be applicable to scenarios such as communication or perception between AP and non-AP STA, between AP and AP, or between non-AP STA and non-AP STA in WLAN, and the embodiment of the present application is not limited to this. Exemplarily, the AP can communicate or perceive with a single non-AP STA, or the AP can communicate or perceive with multiple non-AP STAs at the same time. Exemplarily, the communication or perception between the AP and multiple non-AP STAs can be divided into downlink transmission in which the AP sends signals to multiple non-AP STAs at the same time, and uplink transmission in which multiple non-AP STAs send signals to the AP. Exemplarily, AP1 can be an AP belonging to an AP MLD, or AP2 can be an AP belonging to an MLD. Exemplarily, non-AP STA1 or non-AP STA2 or non-AP STA3 can be a non-AP STA belonging to a non-AP MLD. Among them, WLAN communication protocol can be supported between AP and non-AP STA, between AP and AP, and between non-AP STA and non-AP STA. The communication protocol can include IEEE802.11 series protocols, such as 802.11bn protocol, and of course, it is also applicable to protocols after 802.11bn.

In FIG1, the non-AP STA is a mobile phone and the AP is a router as an example, which does not limit the types of AP and non-AP STA in the embodiment of the present application. At the same time, the number of APs and non-AP STAs shown in FIG1 is only an example. In a specific implementation, the number of APs or non-AP STAs can be more or less, and the embodiment of the present application does not limit this.

FIG2a is a schematic diagram of the architecture of another communication system provided by an embodiment of the present application. The 802.11 standard focuses on the 802.11 physical layer (PHY) and medium access control (MAC) layer in a multi-link device, so FIG2a exemplarily shows the PHY and MAC layers.

As shown in FIG2a, a multi-link device (such as a multi-link AP or a multi-link non-AP) may include a physical layer (physical layer, PHY) (PHY#1, PHY#2 as shown in FIG2a) and a medium access control (medium access control, MAC) layer. The physical layer can be used to process physical layer signals, and the MAC layer can be used to process MAC layer signals. Further, in the MAC layer, it can also be divided into a high-MAC layer (high MAC as shown in FIG2a) and multiple low-MAC layers (low MAC#1, low MAC#2 as shown in FIG2a). As shown in FIG2a, the multiple APs included in the multi-link AP are independent of each other in the low MAC layer and PHY, and share the high MAC layer. The multiple STAs included in the multi-link non-AP are independent of each other in the low MAC layer and PHY, and share the high MAC layer. The high MAC layer is connected to multiple low MAC layers respectively, and the high MAC layer can be shared by multiple links. Exemplarily, the high MAC layer mainly completes the allocation of sequence number (SN) and packet number (PN) of the MAC service data unit (MSDU) and encryption and decryption and other operations. Exemplarily, the low MAC layer mainly completes the assembly of the MAC protocol data unit (MPDU) of each link, channel access, packet sending and reception confirmation and other operations. The functions implemented by the high MAC layer or the low MAC layer shown here are only examples and should not be understood as limitations on the embodiments of the present application.

In FIG2a, the PHY#1 layer, the low MAC#1 layer, and the high MAC layer in the multi-link AP can be regarded as AP#1, and the PHY#2 layer, the low MAC#2 layer, and the high MAC layer can be regarded as AP#2, that is, the multi-link AP can include 2 AP entities. In the multi-link non-AP, the situation is similar, that is, the high MAC layer in the multi-link non-AP is also shared by multiple links, the PHY#1 layer, the low MAC#1 layer, and the high MAC layer are regarded as STA#1 (or non-AP STA#1), and the PHY#2 layer, the low MAC#2 layer, and the high MAC layer are regarded as STA#2 (or non-AP STA#2), that is, the multi-link non-AP includes 2 STA entities (i.e., 2 non-AP STA entities). As shown in FIG2a, the PHY#1 of AP#1 in the multi-link AP and the PHY#1 of STA#1 in the multi-link non-AP work on the same channel, such as AP#1 in the multi-link AP and STA#1 in the multi-link non-AP communicate through a link (link#1 as shown in FIG2a). PHY#2 of AP#2 in the multi-link AP and PHY#2 of STA#2 in the multi-link non-AP operate on another identical channel, such as AP#2 in the multi-link AP and STA#2 in the multi-link non-AP communicate through a link (link #2 as shown in FIG. 2a ).

Exemplarily, the high MAC layer or the low MAC layer can be implemented by a processor in a chip system of a multi-link device, and can also be implemented by different software processing modules in a chip system, etc., which are not listed in the embodiments of the present application. Figure 2a can be a division of functional modules of a multi-link device. The modules shown in Figure 2a can be implemented in the form of hardware or in the form of software functional modules. The PHY and MAC layers shown in Figure 2a can be understood as a division of logical functions, and there can be other division methods in actual implementation. Figure 2a is shown as an example in which a multi-link device includes two sites. In a specific implementation, the multi-link device can also include more or fewer sites, which are not listed here. In the embodiments of the present application, the frequency bands in which the multi-link device operates may include but are not limited to: sub 1GHz, 2.4GHz, 5GHz, 6GHz, etc., which are not listed here one by one.

For non-AP MLD, it can establish associations with multiple links of AP MLD at the same time by performing multi-link establishment operation on one of the links. Among them, the link that exchanges multi-link association request frame or multi-link association response frame is called transmitted link, and other links are called non-transmitted link. Multi-link association request frame or multi-link association response frame can carry information of multiple links to achieve association of multiple links at the same time. For the process of establishing or associating multiple links, please refer to relevant standards or protocols, which will not be described in detail here.

FIG2b is a schematic diagram of an address of an MLD provided in an embodiment of the present application. As shown in FIG2b, for a multi-link device, each link in each multi-link device may correspond to a link address, such as link address 1 (linkaddress 1) and link address 2 (linkaddress 2) in FIG2b, and the multi-link device may also correspond to an MLD MAC address (MLD MAC address). Taking the architecture shown in FIG2a as an example, the high MAC layer may be uniquely identified by the MAC address corresponding to the MLD, and the low MAC layer may be uniquely identified by the MAC address corresponding to the link, such as low MAC#1 and low MAC#2 may correspond to the MAC addresses of their respective corresponding links, respectively. For example, the MLD MAC address may also be referred to as the MLD high MAC layer address, and the link address may also be referred to as the MLD low MAC layer address. The ID within the MLD range shown below may be similar to the MLD MAC address shown in FIG2b.

3 is a schematic diagram of the framework of a communication device provided in an embodiment of the present application. The communication device supports a coexistence mechanism within the device. For example, the communication device may include an MLD (such as an AP MLD or a non-AP MLD), and the MLD includes a Wi-Fi radio frequency module (or referred to as a Wi-Fi radio frequency or a Wi-Fi module). In addition to the MLD, the communication device may also be provided with other wireless modules. Other wireless modules may include, but are not limited to: a Bluetooth (BT) module, a UWB module, a Zigbee module, a fifth generation (5th ^- generation, 5G) module, and the like. For example, the above-mentioned wireless module may include a radio frequency module, and the above-mentioned BT module or UWB module may also include a corresponding radio frequency module. Of course, in addition to the radio frequency module, the wireless module may also include other modules, which are not listed here. The radio frequency module shown below may also represent the wireless module of the radio frequency module.

The interface in Figure 3 may include a coexistence coordination interface (coexistence coordination interface). The coexistence coordination interface can be used to obtain coexistence requests sent by other RF modules. Coexistence request (coexistencerequest) #n is the coexistence request corresponding to the BT module, and coexistence request #m is the coexistence request corresponding to the 5G module. The format of the coexistence request sent by other RF modules to STA may be the same as the format of the coexistence request sent by the STA to other STAs, or it may be different. The embodiment of the present application does not limit the format of the coexistence request sent by other RF modules to TA. The RF module receiving and sending signals or caching data shown below can be understood as the corresponding wireless module receiving and sending signals or caching data.

Exemplarily, there may be interference between different RF modules, and the interference may be asymmetric or symmetric. Exemplarily, different RF modules may share a certain resource, such as working on the same channel, or sharing the same or multiple antennas. FIG3 is shown by taking the MLD including STA1 and STA2 as an example. In a specific implementation, the MLD may also include more or fewer STAs. The communication device shown in FIG3 is also applicable to the first communication device or the second communication device. For example, the first communication device may include a STA (such as STA 1), and may also include other RF modules coexisting with the STA (the other RF modules may include STA 2). The STA in the first communication device can send and receive signals, and the above-mentioned other RF modules can also send and receive signals. That is, there is a situation where STA and other RF modules coexist inside the first communication device, and coexistence interference may occur during the coexistence process.

In the embodiment of the present application, non-AP MLD may include UHR non-AP MLD, and AP MLD may include UHR AP MLD. The embodiment of the present application does not limit the specific product form of AP MLD or non-AP MLD.

From the perspective of sending a coexistence request and receiving a coexistence request, the first communication device shown below may be a communication device that sends a coexistence request, and the second communication device may be a communication device that receives a coexistence request. Alternatively, the first communication device may also be called a sending end, and the second communication device may also be called a receiving end.

In terms of the TXOP holder and the TXOP responder, the first communication device shown below may include a TXOP responder, and the second communication device may include a TXOP holder. As an example, an AP may serve as a TXOP holder, and a non-AP STA may serve as a TXOP responder, if other radio frequency modules exist inside the device where the non-AP STA is located. As another example, a non-AP STA may serve as a TXOP holder, and an AP may serve as a TXOP responder, if other radio frequency modules exist inside the device where the AP is located. As yet another example, other radio frequency modules exist inside both the TXOP holder and the TXOP responder. The above-mentioned AP or the above-mentioned non-AP STA may also be an AP or non-AP STA belonging to an MLD.

The embodiment of the present application describes the method provided by the embodiment of the present application based on the first communication device and the second communication device. However, during the process of transmitting signals, the first communication device and the second communication device can also forward the signal through other devices, such as forwarding the signal between the first communication device and the second communication device through a forwarding device. The embodiment of the present application does not limit other devices other than the first communication device and the second communication device.

The following introduces the terms involved in the embodiments of the present application.

1. Medium protocol data unit (MPDU)

FIG4a is a schematic diagram of the format of an MPDU provided in an embodiment of the present application. As shown in FIG4a, the MPDU may include at least one of the following: frame control, duration, address 1, address 2, address 3, sequence control, quality of service (QoS) control, high throughput (HT) control, frame body, or frame check sequence (FCS). For the description of each field, please refer to the relevant standards or protocols, which will not be described in detail here.

FIG4b is a schematic diagram of the format of the frame control field provided in an embodiment of the present application. As shown in FIG4b, the frame control field may include at least one of the following: protocol version, type, subtype, to DS, from DS, more fragments, retry, power management, more data, protected frame, and whether HT control (HCT) exists.

The power management field is used to indicate the power management mode of the transmitter. The more data field is used to indicate to the receiver in the energy-saving mode whether the transmitter has any cached data to be received by the receiver. The transmitter can switch back and forth between the awake state and the sleep state in the energy-saving mode. If the transmitter has data to be received, it remains in the awake state; if there is no data to be received, it switches to the sleep state. For the description of other fields, please refer to the relevant standards or protocols and will not be described in detail here. The transmitter shown here is a communication device that sends the above-mentioned MPDU, and the receiver can be a device that receives the MPDU.

Exemplarily, the format of the HT control field may be as shown in Table 1. Based on the settings of B1 and B2, the HT control field may have different formats. Of course, Table 1 is only an example. As the standard progresses, the HT control field may have other formats. The relationship between the value and meaning of each bit shown in Table 1 is only an example and should not be understood as a limitation on the embodiments of the present application.

Table 1

FIG4c is a schematic diagram of the format of an A-control field provided in an embodiment of the present application. As shown in FIG4c, the A-control field may include a control list and padding. The control list field may include one or more control fields, and the control field may include a control identifier (control ID) and control information.

The number of bits (or bytes) occupied by each field given in each figure of the embodiment of the present application, the order between different fields, etc. are only examples, and the format or frame length or the order of each field proposed in the embodiment of the present application should not be limited. The names of the various frames and the fields contained in the figures of the embodiment of the present application are only examples, and the various frames proposed in the embodiment of the present application should not be limited. For ease of description, the various embodiments shown in the present application are shown as "fields" and do not specifically distinguish between "fields", "subfields", "elements", "sub-elements", etc. Although the various embodiments shown in the present application do not specifically distinguish between "fields", "subfields", "elements", and "sub-elements", those skilled in the art can adaptively distinguish the relationship between the various fields shown in the embodiment of the present application.

2. Transmit opportunity (TXOP)

A transmission opportunity refers to a bounded period of time during which a device (such as an AP or non-AP STA) can transmit a specific communication category. The specific duration can be indicated by the duration field in the MPDU header (as shown in Figure 4a). In the enhanced distributed channel access (EDCA) scenario, the device can obtain a TXOP through the channel access process. Once the TXOP is obtained, the device can continue to transmit data frames, control frames and management frames, and receive response frames. The duration of these frames does not exceed the TXOP upper limit set by the access category (AC) corresponding to the frame.

Generally speaking, the device that obtains the TXOP can be called the transmission opportunity holder (TXOP holder), and the corresponding receiving end can be called the TXOP responder (TXOP responder).

3. Coexistence Request

When there is coexistence interference between different RF modules in the device, the RF module can generate a coexistence request. The coexistence request can be used to coordinate the coexistence interference between different RF modules. For example, the coexistence request may include information of other RF modules and/or information of STA. Taking Figure 3 as an example, the coexistence request may be a coexistence request initiated by the BT module, or a coexistence request initiated by the UWB module, or a coexistence request initiated by the Zifeng module, or a coexistence request initiated by the 5G module.

As an example, the coexistence request sent by the first communication device may be a coexistence request of a radio frequency module inside the device, such as a coexistence request from a radio frequency module obtained by the STA (or the MLD to which the STA belongs) through an interface.

As another example, the coexistence request sent by the first communication device is a coexistence request merged from multiple RF modules inside the device. After the STA (or the MLD to which the STA belongs) obtains the coexistence requests from multiple RF modules through the interface, the coexistence requests of the multiple RF modules can be merged into one coexistence request. For example, when there is coexistence interference between different RF modules in the device, the STA (or the MLD to which the STA belongs) can merge multiple coexistence requests into one coexistence request after receiving the coexistence requests sent by other RF modules.

The following describes the method involved in the embodiments of the present application.

FIG. 5 is a flow chart of a communication method provided in an embodiment of the present application. As shown in FIG. 5 , the method includes:

501. A first communication device sends a coexistence request, and correspondingly, a second communication device receives the coexistence request.

When the first communication device is an MLD, the coexistence request can be sent by the STA belonging to the MLD. Exemplarily, before the first communication device sends the coexistence request, it can also obtain or generate the coexistence request. For example, the step of obtaining the coexistence request can be performed by the above-mentioned STA. As an example, the step of generating a coexistence request can be performed by the above-mentioned STA. As another example, the step of generating a coexistence request can be performed by a processing module in the MLD. The embodiment of the present application does not limit which chip or functional module, etc., specifically generates the coexistence request.

As an example, the coexistence request may be included in a control frame or a management frame. The format of the control frame or the management frame may refer to the description of the MPDU shown in FIG. 4a, and will not be described in detail here. For example, the coexistence request may be carried in the frame body field.

As another example, the coexistence request may be included in a data frame. The format of the data frame may refer to the description of the MPDU shown in FIG. 4a, which will not be described in detail here. For example, the coexistence request may be carried in the control information field in the A-control field. For the format of the A-control field, refer to FIG. 4c. The above control frame, management frame or data frame may be collectively referred to as a radio frame.

Exemplarily, the coexistence request may be included in an ICF or ICR frame. For example, when the first communication device includes an AP, the coexistence request may be included in an ICF. For another example, when the first communication device includes a non-AP STA, the coexistence request may be included in an ICR frame.

In the embodiment of the present application, the first communication device can send a coexistence request so that the second communication device can make a reasonable decision (or process) in combination with the coexistence request. The decision may include but is not limited to: ending the current TXOP in advance, ending the scheduling of the first communication device in the current TXOP in advance (i.e., no longer scheduling the first communication device in the current TXOP), reasonably scheduling the first communication device, or selecting the working bandwidth or the maximum number of transceiver streams or the maximum modulation and coding mode, etc.

502. The second communication device parses the coexistence request.

In example 1, the TXOP holder can respect and follow the coexistence request from one or more TXOP responders and schedule transmission based on the coexistence request. At the same time, the STA (such as non-AP STA or AP) can also remove, suspend or modify the coexistence request (as shown in the operation type information below).

Example 2: The TXOP holder may have the final decision-making power. For example, the AP as the TXOP holder may decide how to schedule transmission or whether to end the TXOP early based on the coexistence request from one or more non-AP STAs. Ways to end the TXOP early may include: the TXOP holder sends a contention-free end (CF-end) to instruct the TXOP responder to end the TXOP early. For example, the second communication device may learn whether the TXOP needs to be ended early by parsing the coexistence request. The first communication device may effectively learn the coexistence interference situation within the first communication device by sending a coexistence request to the second communication device. As a result, the second communication device may end the TXOP early and no longer schedule the transmission of the first communication device in this TXOP. For another example, when the second communication device is an AP, the second communication device may learn how to schedule the non-AP STA specifically. For example, the AP may not schedule the non-AP STA or reduce the modulation and coding strategy during the time when the non-AP STA has coexistence interference.

For the steps executed by the second communication device, please refer to the description of the feedback result below, which will not be described in detail here.

The following introduces the coexistence request involved in the embodiments of the present application.

The coexistence request includes at least one of the following: an identifier, operation type information, radio frequency type information, service priority information, interference report, expected behavior information, or listening mode enabling information. Detailed description is given below.

It should be understood that the above information can be included in the coexistence request at the same time; or, when the coexistence request is included in a radio frame, part of the above information can be carried in other elements or other fields in the radio frame except the coexistence request, and the other part of the information is carried in the coexistence request in the radio frame. The specific position or order of the above information in the coexistence request or radio frame is not limited in the embodiment of the present application.

For ease of description, when referring to specific examples below, the first communication device includes a TXOP responder, and a non-AP STA serves as a TXOP responder, and the second communication device includes a TXOP holder, and an AP serves as a TXOP holder. However, this should not be understood as a limitation on the embodiments of the present application.

(1) Logo

The identifier can be used to uniquely identify a coexistence request. For example, the identifier can include a coexistence request identifier (identifier, ID) (coexistencerequest ID). To facilitate the management of coexistence requests between different RF modules, the first communication device can assign an identifier to each coexistence request, such as a coexistence request ID. The coexistence request ID assigned by the first communication device can be within the MLD range. For example, the coexistence request ID can be an ID within the MLD range that can be assigned by the first communication device.

Exemplarily, the identifier may be carried in a coexistence request ID field in a coexistence request.

By carrying the coexistence request ID in the coexistence request, the second communication device can flexibly operate on different coexistence requests, identify different coexistence requests, and improve the management flexibility of the coexistence request. Then, the second communication device can distinguish different coexistence requests sent by the first communication device based on the coexistence request ID, or distinguish coexistence requests from different first communication devices, so that the second communication device can easily manage different coexistence requests and improve management efficiency.

(2) Operation type information

The operation type information may be used to indicate the operation type of the coexistence request. The operation type of the coexistence request may include but is not limited to: a newly added coexistence request; a removed coexistence request; a coexistence request with modified parameters; and a temporarily suspended coexistence request. The operation type of the coexistence request indicated by the operation type information may be any of the above operation types.

Exemplarily, the operation type information may be carried in an operation type field in the coexistence request. The name of the operation type information or the operation type field is only an example, for example, the operation type information may also be called update type information, and the operation type field may also be called update type (updatetype) field.

Exemplarily, the relationship between the value and meaning of the operation type information (i.e., the operation type field) can be as follows: the operation type information is set to 00 to indicate that the coexistence request is a newly added coexistence request; the operation type information is set to 01 to indicate that the coexistence request is removed; the operation type information is set to 10 to indicate that the relevant parameters of the coexistence request (such as the sending parameters and/or receiving parameters shown below) are modified; the operation type information is set to 11 to indicate that the coexistence request is temporarily suspended until it is restored, or the coexistence request is temporarily suspended until the indicated time point. The description between the value and meaning of the operation type information shown here is only an example, and the value and meaning of the operation type information can also have other relationships, such as the operation type information value is set to 11 to indicate a newly added coexistence request; the operation type information value is set to 00 to indicate that the coexistence request is removed; the operation type information value is set to 10 to indicate that the coexistence request is removed; the operation type information value is set to 01 to indicate that the coexistence request is temporarily suspended, etc., which are not listed here one by one.

When the operation type information indicates that the coexistence request is a temporarily suspended coexistence request, the coexistence request may also include resumption time information indicating the coexistence request (not shown in FIG. 6 b). At the moment indicated by the resumption time information, the coexistence request may release the temporary suspension. Exemplarily, the resumption time information may be carried in a timing synchronization function (TSF) (resume TSF) field, which may include at least one of the following: next starting time, next duration, next interval, etc. How to indicate the resumption time of the coexistence request is not described in detail here. For example, when the service of the radio frequency type corresponding to the coexistence request is temporarily stopped, the operation type of the coexistence request may be a temporarily suspended coexistence request.

The second communication device may learn the operation type of the coexistence request based on the operation type information. Exemplarily, the second communication device may perform different processing for different operation types.

As an example, when the operation type information indicates that the coexistence request is a newly added coexistence request, the second communication device may save the coexistence request. For example, the TXOP holder may schedule the TXOP responder based on the coexistence request, or process the transmission request (or scheduling request, etc.) of the TXOP responder, etc. As another example, when the operation type information indicates that the coexistence request is a coexistence request that needs to be removed, the second communication device may delete the cache about the coexistence request. As another example, when the operation type information indicates that the coexistence request is a coexistence request that needs to modify parameters, the second communication device may update its saved coexistence request based on the parameters indicated in the coexistence request. If the second communication device is an AP, the AP may schedule a non-AP STA using the updated coexistence request. As another example, when the operation type information indicates that the coexistence request is temporarily suspended, the second communication device may temporarily ignore the coexistence request. If after the moment indicated by the above-mentioned recovery time information, the coexistence request becomes valid again.

(3) RF type information

The radio frequency type information can be used to indicate the radio frequency type (or coexistence type) corresponding to the coexistence request. For example, the radio frequency type may include but is not limited to: BT, WUB, Zifeng, 5G, Wi-Fi. The radio frequency type corresponding to the coexistence request shown in the embodiment of the present application may also be referred to as the radio frequency type of the radio frequency module corresponding to the coexistence request, or the radio frequency type of other radio frequency modules. The other radio frequency modules are relative to STA. In the embodiment of the present application, the radio frequency type corresponding to the coexistence request may also be replaced by the radio frequency module corresponding to the coexistence request, or the wireless module corresponding to the coexistence request, etc.

As an example, when the value of the RF type information is a special value, the RF type information may implicitly indicate that the coexistence request is a coexistence request merged from coexistence requests corresponding to multiple RF modules. As another example, when the value of the RF type information is a normal value, the RF type information may implicitly indicate that the coexistence request is a coexistence request corresponding to a RF module. For example, if the value of the RF type information is a normal value #1, it indicates that the RF type corresponding to the coexistence request is BT; if the value of the RF type information is a normal value #2, it indicates that the RF type corresponding to the coexistence request is WUB, and so on. The specific values of the normal value or the special value are not listed here one by one.

The second communication device can learn the RF type of the coexistence request based on the RF type information, and make a reasonable decision based on the RF type. For example, the second communication device can determine whether to follow (or respect or comply with) the coexistence request based on the RF type. In order to avoid interference between different RF modules inside the first communication device, or to control the interference within a reasonable range, the second communication device can follow the coexistence request, such as: the second communication device can end the TXOP in advance; for example, the second communication device can not schedule the first communication device during the period when there is coexistence interference with the first communication device (such as within the interference window shown below). When the second communication device does not follow the coexistence request, the second communication device can ignore the coexistence request. For example, the RF type is 5G, and the 5G module corresponds to low-latency services. The second communication device can follow the coexistence request from the first communication device. They are not listed one by one here.

(4) Business priority information

The service priority information may be used to indicate the service priority of the radio frequency type corresponding to the coexistence request. Exemplarily, the service priority information may be carried in a service priority (trafficpriority) field.

The service priority information may include, but is not limited to, access category, traffic identifier (TID), differentiated services code point (DSCP), or minimum remaining time. For example, the access category refers to the access type of the radio type corresponding to the coexistence request. Different access types may correspond to different service priorities. For example, the access category may occupy 2 bits. Four different access types may be indicated by these 2 bits. For example, the service identifier refers to the TID of the radio type corresponding to the coexistence request. Different TIDs may correspond to different service priorities. For example, the TID may occupy 4 bits. If DSCP is a quality of service (QoS) classification standard, the priority may be distinguished by the coding value. For example, DSCP may occupy 6 bits. The minimum remaining time refers to the minimum remaining time of the radio type corresponding to the coexistence request. That is, the minimum remaining time may indicate the minimum remaining time of the cached data corresponding to other radio modules. The cached data may be the data corresponding to the radio module corresponding to the coexistence request. When the minimum remaining time is exceeded, the cached data corresponding to the other radio modules may be discarded or the QoS may be seriously deteriorated. Generally speaking, the shorter the minimum remaining time, the higher the service priority corresponding to the cached data.

The second communication device can obtain the service priority of the radio frequency type corresponding to the coexistence request based on the service priority information, so as to reasonably schedule the first communication device so that the first communication device can send and receive data of different service priorities in combination with the coexistence interference situation.

(5) Interference Report

The interference report may indicate whether the interference is asymmetric or symmetric.

When the interference is asymmetric, it means that the radio frequency type corresponding to the coexistence request will cause interference to the STA (such as including Wi-Fi radio frequency), but the STA will not cause interference to the radio frequency type corresponding to the coexistence request, or the interference caused is less than a certain threshold, or the interference caused by the STA to the radio frequency type corresponding to the coexistence request is less than the interference caused by the radio frequency type corresponding to the coexistence request to the STA. For example, the coexistence request may carry an interference report. The interference report may indicate the parameters of the interference of the radio frequency type corresponding to the coexistence request to the STA.

When the interference is symmetrical, it means that the radio type corresponding to the coexistence request will cause interference to the STA, and the STA will also cause interference to the radio type. For example, the coexistence request can carry two interference reports, indicating the interference parameters caused by the radio type corresponding to the coexistence request to the STA and the interference parameters caused by the STA to the radio type.

Exemplarily, the interference report may be carried in a coexistence report field. Whether the interference is asymmetric or symmetric may be carried in a symmetric interference field in the coexistence report.

Exemplarily, in addition to indicating whether the interference is asymmetric or symmetric, the interference report may also include at least one of the following: link ID (not shown in FIG. 6 b), interference level, interference-affected channel, whether the interference is periodic or aperiodic, interference start time, interference duration, interval between adjacent interference windows, and the number of interference windows. Exemplarily, the interference level may be carried in the interference level field in the coexistence report, the interference-affected channel may be carried in the interference channel field in the coexistence report, the interference start time may be carried in the start time field in the coexistence report, the interference duration may be carried in the duration field (or referred to as duration or duration, etc.) in the coexistence report, the interval between adjacent interference windows may be carried in the interval field in the coexistence report, and the number of interference windows may be carried in the count field in the coexistence report.

Among them, link ID refers to the identifier of the link affected by coexistence interference. The interference level is used to indicate the interference intensity or size of the interference to the STA. The channel affected by interference indicates the channel where the interference is located. If the interference is periodic, it means that the coexistence interference is periodic. If the interference is non-periodic, it means that the coexistence interference is not periodic. The interference start time can be used to indicate the start time of the coexistence interference. The interference duration can be used to indicate the duration of the coexistence interference. When the interference is periodic, it means that the interference will occur in a certain period, such as the start time of the interference is indicated by the interference start time, and the duration of the interference within a period is indicated by the interference duration. The interference start time and the interference duration can constitute an interference window. When the interference is periodic, the interference report can also include the interval between adjacent interference windows or the number of interference windows. In other words, the interference window is periodic.

The information shown above is shown by taking the example of being carried in an interference report. For example, the above information can be carried in the coexistence report field in the form of a field. However, in a specific implementation, the various information listed in (5) above can also be carried in the coexistence request in other forms, which are not listed here one by one. For example, the priority information shown in (4) above can be carried in a coexistence report (as shown in Figure 6b). The specific form in which the various information in (1) to (7) shown in the embodiment of the present application is carried in the coexistence request is not limited by the embodiment of the present application. There may be repeated information in the information in (1) to (7) shown in the embodiment of the present application. The repeated information may not appear repeatedly in the coexistence request, or the repeated information may appear repeatedly in the coexistence request. The embodiment of the present application does not limit this.

(6) Expected behavior information

The expected behavior information is used to indicate the expected behavior of the STA in the first communication device. In other words, the coexistence request is the behavior expected by the STA in the first communication device. In other words, the behavior expected by the STA in response to the interference caused by other radio frequency modules to the STA.

Exemplarily, the expected behavior information may be carried in an expected behavior field.

Exemplarily, the above-mentioned expected behavior includes any of the following:

a. Allowed to send signals (available Tx), or disallowed to receive signals (disallowed Rx). For example, based on the coexistence interference existing inside the first communication device, the STA expects to be allowed to send signals. The second communication device can schedule the STA in the first communication device to transmit based on the expected behavior information. Exemplarily, other RF modules in the first communication device need to send signals within the interference window, so the first communication device can expect the STA (such as the Wi-Fi RF inside the first communication device) to send signals. Thereby, the interference of other RF modules on the STA can be reduced as much as possible, and the interference can be controlled within a reasonable range.

b. Restricted received signals (restricted Rx), or allowing sending signals and allowing receiving signals with restricted parameters (available Tx and available Rx with restricted parameters). In this case, the coexistence request may also include restricted parameters, such as the receiving parameters when the STA in the first communication device receives signals with restrictions. The receiving parameters include at least one of the following: link ID, maximum number of streams, expected receiving redundancy (margin), expected maximum data length, expected bandwidth, coding type (or coding modulation type, etc.), maximum LDPC codeword length, and maximum MCS.

Among them, the link ID is used to indicate the identification of the link affected by the coexistence interference. The maximum number of streams can be used to indicate the maximum number of streams that the STA can use when receiving a signal. The maximum MCS can be used to indicate the maximum MCS used by the STA when receiving a signal. The reception redundancy can be used to determine the redundancy of the SNR corresponding to the maximum MCS. The expected maximum data length can indicate the maximum TB-PPDU length that the STA expects to receive. The expected bandwidth can be used to indicate the maximum transmission bandwidth. The coding type can indicate a coding method, such as a low-density parity-check (LDPC) coding method or other coding methods, which are not listed here. The maximum LDPC codeword length can be used to indicate the maximum allowed LDPC codeword length.

In the embodiment of the present application, by including receiving parameters in the coexistence request, coexistence between multiple radio frequency modules inside the first communication device can be achieved, thereby reducing mutual interference as much as possible.

c. Allowed to receive signals (available Rx), or disallowed to send signals (disallowed Tx). For example, based on the interference inside the first communication device, the STA expects to receive signals. The second communication device can send signals to the first communication device based on the expected behavior information. Exemplarily, other RF modules in the first communication device can receive signals, and the STA can also expect to receive signals, so that mutual interference can be reduced as much as possible.

d. Restricted transmission signal (restricted Tx), or allowing reception of signals and allowing transmission of signals using restricted parameters (available Rx and available Tx with restricted parameters). In this case, the coexistence request may also include restricted parameters, i.e., transmission parameters when the STA in the first communication device transmits signals in a restricted manner. The transmission parameters include at least one of the following: link identifier, maximum number of streams, maximum transmission power, minimum transmission power, expected reception redundancy, expected maximum data length, expected bandwidth, coding type (or maximum LDPC code length). For example, for a trigger-based (TB) physical layer (PHY) protocol data unit (PPDU), the second communication device may schedule the first communication device through the transmission parameters in the coexistence request.

Among them, the maximum transmit power can be used to indicate the maximum transmit power allowed by the STA when sending a TB-PPDU. The minimum transmit power can be used to indicate the minimum transmit power that can be used when the second communication device sends a signal to the first communication device. For the description of other parameters, please refer to the description in b, which will not be described in detail here.

In the embodiment of the present application, by including a sending parameter in the coexistence request, coexistence between multiple radio frequency modules within the first communication device can be achieved, thereby reducing mutual interference as much as possible.

e. Disallowed Tx and disallowed Rx, or unavailable. For example, within the interference window, the first communication device neither sends nor receives signals. For example, other radio frequency modules have a large interference impact on the STA, and the interference cannot be controlled within a reasonable range. Therefore, the STA expects that it is not allowed to send or receive signals.

As an example, the time corresponding to the expected behavior information may be the same as the time shown in (5). Exemplarily, when the coexistence request includes an interference report, and the interference report includes the interference start time and the interference duration, or the interference report also includes the interval between adjacent interference windows and the number of interference windows, the second communication device may schedule the first communication device based on the interference window indicated in the interference report. That is, the time period corresponding to the above-mentioned expected behavior may be determined by the time (such as the interference start time, the interference duration, the interval or the number) indicated in (5). When the coexistence request does not include an interference report, the coexistence request may also include time information, which may be used to indicate the time period corresponding to the above-mentioned expected behavior. For example, the time information may include the interference start time and the interference duration. For example, the time information may also include at least one of the interval between adjacent interference windows or the number of interference windows. For the description of the time information, reference may be made to the description of the interference start time, the interference duration, the interval or the number in (5) above, which will not be repeated here.

As another example, the time period corresponding to the expected behavior may be different from the time shown in (5). For example, the expected behavior information may also include time information. The time period indicated by the time information may partially overlap or completely not overlap with the interference window indicated in (5). For example, the time information may include a start time and a duration. For another example, the time information may include a start time and an end time. For another example, the time information may include a start time, a duration, and a period, etc. For the description of the time information shown here, reference may also be made to the description of the interference window described above.

Exemplarily, the coexistence request may also include information indicating whether they are the same (not shown in FIG. 6 b), which may be used to indicate whether the interference window is the same as the time period corresponding to the expected behavior, or the information may implicitly indicate whether the time period corresponding to the expected behavior will appear in the coexistence request. For example, when the interference window is the same as the time period corresponding to the expected behavior, the time period corresponding to the expected behavior may not appear in the coexistence request. For another example, when the interference window is different from the time period corresponding to the expected behavior, the time period corresponding to the expected behavior may appear in the coexistence request.

Fig. 6a is a schematic diagram of the format of an expected behavior field provided by an embodiment of the present application. As shown in Fig. 6a, the expected behavior field may include a control field and a time field. The control field may include an expected behavior control field and a bitmap present field.

Among them, the above-mentioned time field can be used to indicate the time period corresponding to the expected behavior. If the expected behavior is that neither sending nor receiving signals is allowed, the time field can be used to indicate an unavailable time period (or unavailable window). That is, within the time period indicated by the time field, the STA is not allowed to send or receive signals. If the expected behavior is restricted reception of signals, the time field can be used to indicate that within the time period indicated by the time field, the STA can use the reception parameters in the coexistence request to receive signals. For the description of the time field, please refer to the time information shown and will not be described in detail here.

The expected behavior control field can be used to indicate any of the above items a to e. As an example, the expected behavior control field can occupy 3 bits. If the value of the field is value #1, it can indicate that the expected behavior is to allow the sending of signals, the value of the field is value #2, it can indicate that the expected behavior is to allow the receiving of signals, the value of the field is value #3, it can indicate that the expected behavior is to allow the receiving of signals, the value of the field is value #4, it can indicate that the expected behavior is to allow the sending of signals, and the value of the field is value #5, it can indicate that the expected behavior is not allowed to send signals or receive signals. As another example, the expected behavior control field can occupy 5 bits. If the first bit of the 5 bits can be used to indicate that the expected behavior is to allow the sending of signals, that is, the first bit can correspond to the above a. By analogy, the second bit can correspond to the above b, the third bit can correspond to the above c, the fourth bit can correspond to the above d, and the fifth bit can correspond to the above e. They are not listed here one by one. The relationship between the bit order and the meaning shown here is only an example and should not be understood as a limitation on the embodiments of the present application.

The bitmap appearance field can be used to indicate whether the following information exists: maximum number of streams, maximum MCS, maximum LDPC codeword length (max LDPC codewordlength), maximum TB-PPDU length (max TB-PPDU length), expected bandwidth (expected BW), expected receive redundancy (expected Rxmargin) or maximum transmit power (max Txpower). For example, the bitmap appearance field can occupy 8 bits, and these 8 bits can be used to indicate whether the corresponding information appears. The information listed here is only an example. In a specific implementation, the length of the bitmap appearance field can be longer or shorter, and the above information that may appear in the expected behavior field can be more or less, which is not limited in the embodiments of the present application.

Figure 6b is a schematic diagram of the format of a coexistence request (coexistence request) provided in an embodiment of the present application. The coexistence request may include a coexistence control field and an expected behavior field. For example, the coexistence request may also include a coexistence report field.

Exemplarily, the coexistence control field may include a coexistence request ID field, an operation type field, and a coexistence report presence (coexistencereport) field. For the description of the coexistence request ID field, please refer to the description of (1) above, and for the description of the operation type field, please refer to the description of (2) above, which will not be described in detail here. The coexistence report presence field can be used to indicate whether there is a coexistence report in the coexistence request. For the description of the coexistence report field, please refer to the description of (5) above, and for the description of the service priority field in the coexistence report field, please refer to the description of (4) above. For the description of the expected behavior field, please refer to the description of (6) above. In Figure 6b, the expected behavior indicated by the expected behavior control field can be any one of the above a to e. Although the expected behavior field in Figure 6b includes a time field, and the interference report field includes a start time field, a duration field, an interval field, and a count field. However, it should not be understood as a limitation on the embodiments of the present application. The order or position of the various fields shown in Figure 6b is only an example and should not be understood as a limitation on the embodiments of the present application.

(7) Listening mode enable information

The listening mode enable information can be used to instruct the first communication device (such as the STA in the first communication device) to turn on the listening mode (listening mode) or exit the listening mode (or listening mode). Generally speaking, in order to save energy, the STA can choose to work in the listening mode. In the listening mode, the STA can send and receive signals under small bandwidth, single stream or low MCS. Thereby, the power consumption of the communication device can be effectively reduced.

In an embodiment of the present application, the monitoring mode enabling information may be carried in a coexistence request. Alternatively, the monitoring mode enabling information may be carried in a radio frame, and the radio frame includes the monitoring mode enabling information and the coexistence request. In other words, the coexistence request does not include the monitoring mode enabling information, but the radio frame including the coexistence request includes the monitoring mode enabling information. The embodiment of the present application does not limit the position of each information shown in (1) to (7) in the radio frame.

As an example, when the monitoring mode enabling information is a first value, it indicates that the first communication device exits the monitoring mode. The mode to be switched to by the first communication device is determined based on the power management information. Exemplarily, the first value may be 0.

In method 1A, if the value of the monitoring mode enable information is 0, the first communication device can exit the monitoring mode, such as switching to the active mode (or active mode) by default.

Mode 2A, the value of the listening mode enabling information is 0, the first communication device can exit the listening mode and switch to a specified mode. The specified mode can be determined by a power management field in a radio frame including a coexistence request. The power management field can be used to carry power management information. For an explanation of the power management field, refer to Term 1 above.

For example, if the value of the power management field is 1, it indicates exiting the listening mode and switching to the power save (PS) mode.

For another example, if the value of the power management field is 0, it means exiting the listening mode and switching to the active state (or called activation mode or active mode, etc.). Of course, the correspondence between the value and meaning of the power management field shown here is only an example. For example, if the value of the power management field is 0, it can mean exiting the listening mode and switching to the energy-saving mode; if the value of the power management field is 1, it means exiting the listening mode and switching to the active mode.

As another example, when the monitoring mode enabling information is a second value, it indicates that the first communication device turns on the monitoring mode. The state of the first communication device is determined based on at least one of the power management information or more data information. Exemplarily, the second value may be 1. Generally speaking, the monitoring mode may include an awake state or a doze state.

In mode 1B, if the value of the monitoring mode enable information is 1, it means that the first communication device enters the monitoring mode and remains in the awake state, and is not allowed to switch to the sleep state. For example, in the monitoring mode, the first communication device can send and receive signals through small bandwidth, single stream or low MCS parameters in the awake state. For mode 1B, the monitoring mode and the energy saving mode can be in parallel.

In mode 2B, the value of the listening mode enabling information is 1, and the first communication device can switch between the awake state or the sleep state based on the power management field or more data fields. For example, in the listening mode, the first communication device can switch back and forth between the awake state and the sleep state. For mode 2B, the listening mode and the energy saving mode can be used in combination.

For example, if the value of the power management field is 1, the first communication device can switch back and forth between the awake state and the sleep state based on the data field. If the more data field is 1, the first communication device can receive the signal through the reception parameters in the coexistence request until the more data field is set to 0, and the first communication device can switch to the sleep state.

For another example, a value of 0 in the power management field indicates that the first communication device enters the listening mode and remains in the awake state, and is not allowed to switch to the sleep state.

By reusing the meaning of more current data fields, the monitoring mode and the energy-saving mode can be in parallel, and it is known that the two can be used in combination (such as the above method 2B) or separately (such as method 1B). This is equivalent to adding a monitoring mode without changing the operation of the existing energy-saving mode, and the protocol is slightly modified.

In an embodiment of the present application, the first communication device sends a coexistence request to the second communication device, so that on the one hand, the second communication device schedules the first communication device based on the coexistence request; on the other hand, the coexistence request includes an identification or operation type information, so that the second communication device can flexibly manage different coexistence requests.

In an embodiment of the present application, after receiving the above-mentioned coexistence request, the second communication device may also send a feedback result to the first communication device. The first communication device may learn the decision of the second communication device based on the feedback result. For example, the feedback result may explicitly indicate the decision of the second communication device, or may implicitly indicate the decision of the second communication device. For example, the feedback result may include a cache report, more data fields, and indication information. The following is a detailed description taking the TXOP holder and the TXOP responder as examples:

Method 1: The feedback result may include a cache report, or the feedback result may be a cache report. The cache report may be used to indicate the status of the cached data of the TXOP holder. For example, the cache report may be carried in the ICF or A-control. After receiving the cache report, the TXOP responder may know whether it has other data with higher priority to be received.

For example, when a non-AP STA receives a cache report sent by an AP indicating that the non-AP STA has data with a higher priority to be received (the data may be data corresponding to other radio frequency modules), the non-AP STA may suspend or remove the previous coexistence request (such as the coexistence request before receiving the cache report). The non-AP STA may carry the coexistence request in the BA or A-Control field or ICR frame, and instruct the AP to temporarily suspend or remove the corresponding coexistence request (such as the coexistence request before receiving the cache report) through the operation type information. For example, the coexistence request may include a coexistence request ID, operation type information, and resume time information. The resume time information may also be carried in a timing synchronization function (TSF) (resume TSF) field, etc. The resume time information may be used to indicate the time point of the resume, such as indicating the low-order part of the TSF. Exemplarily, the above-mentioned cache report may include at least one of the following: the size of the cached data, the minimum remaining time of the cached data, or the service priority of the cached data. The description of the minimum remaining time and the service priority can be referred to above and will not be described in detail here.

For another example, the TXOP responder determines the maximum bandwidth, the maximum MAC and/or the maximum number of flows used for subsequent data transmission according to the buffer report sent by the TXOP holder.

In the embodiment of the present application, the TXOP holder can implicitly indicate the processing result of the coexistence request sent by the TXOP responder by sending a cache report to the TXOP responder. When the cache report indicates that the TXOP responder has higher priority data to be received, it can implicitly indicate that the TXOP holder may not comply with the coexistence request, and the TXOP holder will also send data to the TXOP responder.

Mode 2: The feedback result may include a more data field. For example, the MPDU format of the feedback result may refer to the description of FIG. 4a or FIG. 4b. The TXOP responder may know whether it has data to be received based on the more data field. If the more data field is set to 1, the TXOP responder may continue to receive data until the more data field in the MPDU it receives again is set to 0. For the description of the more data field, refer to the above.

In the embodiment of the present application, when the More Data field is set to 1, it means that the TXOP holder will also send data to the TXOP responder, which can implicitly indicate that the TXOP holder may not comply with the coexistence request.

Mode 3: The feedback result may include indication information, which is used to indicate whether the TXOP holder has received the coexistence request, or whether the TXOP holder complies with the coexistence request. For example, the indication information may be carried in the A-Control field or BA or radio frame, etc. Through the above indication information, the TXOP responder can learn the decision of the TXOP holder on the coexistence request.

Mode 4: The feedback result may include indication information, which may be used to indicate that the scheduling of the TXOP responder in this TXOP has ended, or that the TXOP responder stops sending and receiving signals in this TXOP. The TXOP responder receives the indication information and can learn about the scheduling of the TXOP responder by the TXOP holder. If the indication information can be carried in the A-control field, the control identifier field of the A-control field can define a new value, and the newly defined value can be used to indicate that the role of the A-control field is to indicate that the AP will no longer schedule non-AP STAs in this TXOP.

For example 2 in step 502 of Figure 5, since the TXOP holder may have the right to decide, it may happen that the TXOP holder does not comply with the coexistence request. When the TXOP holder does not comply with the coexistence request, the following situation may occur: the duration of the TXOP partially overlaps or completely overlaps in time with the unavailable window indicated in the coexistence request of one or more TXOP responders. For example, the TXOP holder may not comply with the coexistence request sent by one or more TXOP responders, and the TXOP holder may still schedule the TXOP holder within the unavailable window of one or some TXOP holders. In the above situation, it is also possible to combine the above methods one to four so that the TXOP responder can be informed of the TXOP holder's decision on the coexistence request, thereby further improving communication efficiency.

The coexistence request shown above may be combined with other examples or methods shown above, and the specific manner of the combination will not be described in detail here.

The following is an illustrative introduction to the scenarios involved in the embodiments of the present application.

Generally speaking, when either end of the communicating parties is in coexistence mode, the communicating parties may exchange initial control frames (ICF) and initial control response (ICR) frames at the beginning of each TXOP. Coexistence requests or receiving parameters, etc., are exchanged by exchanging ICF and ICR frames. Exemplarily, ICF and ICR frames may be newly defined control frames. Or the formats of ICF and ICR frames may reuse the formats of existing control frames, such as the format of ICR may refer to the format of multi-user request to send (MU-RTS), and the format of ICR frame may refer to the format of clear to send (CTS); or the format of ICR may refer to the format of MU-BAR, and the format of ICR frame may refer to the format of BA.

Currently, Wi-Fi 8 also discusses the energy saving of equipment. For example, in order to save energy, the station can choose to work in monitoring mode or energy saving mode. In the above modes, the station can work under small bandwidth, single stream and low MCS. If the AP obtains TXOP and wants to transmit data with the non-AP STA, the two communicating parties can exchange ICF/ICR frames. For example, the non-AP STA can carry a coexistence request in the ICR frame to inform the AP of the maximum bandwidth, maximum MCS, maximum number of streams and other parameters used when transmitting data.

FIG7 is a flow chart of a communication method provided by an embodiment of the present application. In FIG7 , the AP may be a TXOP holder, and non-AP STA1 and non-AP STA2 may be TXOP responders. FIG7 is illustrated by taking AP triggering uplink multi-user transmission as an example. The AP obtains a TXOP through an EDCA competitive channel, and non-AP STA 1 or non-AP STA2 operates in a coexistence mode or in a listening mode (or energy-saving mode), and ICF and ICR frames are first exchanged at the beginning of the TXOP.

As shown in Figure 7, the AP sends an ICF, and non-AP STA1 or non-AP STA2 can reply with an ICR frame after receiving the ICF.

As an example, the ICF may carry the coexistence request within the TXOP holder, and the ICR frame may carry the coexistence request within the TXOP responder. For the description of the coexistence request, please refer to the description of FIG. 5 or FIG. 6 b, etc., which will not be described in detail here.

As another example, the ICR frame may carry the coexistence request within the TXOP responder. Since the TXOP holder can control the transmission within the TXOP itself, the TXOP holder may not need to indicate the coexistence request within the TXOP.

Taking FIG. 7 as an example, non-AP STA 1 and non-AP STA 2 may declare their respective coexistence requests in the ICR frame. For example, non-AP STA 1 requests that TXOP end at time T1, duration A, and the corresponding service priority X. Non-AP STA 2 requests that TXOP end at time T2, duration B, and the corresponding service priority Y. If the expected behavior of the coexistence request sent by non-AP STA 1 may be unavailable, the time information may be used to indicate the unavailable time (i.e., unavailable window). For example, non-AP STA 1 may indicate through the time information that non-AP STA 1 requests that this TXOP end at time T1. Time T1 may be determined by the start time of the unavailable time, such as time T1 may be the start time of the unavailable time. Duration A may be indicated by the duration field in the time information. X may be indicated by the service priority information. Similarly, the description of non-AP STA 2 may refer to non-AP STA 1, and will not be described in detail here. For the steps performed by the AP based on the coexistence request, reference may be made to the above-mentioned Example 1 or Example 2, which will not be described in detail here.

Optionally, the AP may send data, and non-AP STA1 or non-AP STA2 may receive the data. After receiving the data, non-AP STA1 or non-AP STA2 may reply with a block acknowledgment (BA) frame.

Exemplarily, when the AP needs to feed back the processing result of the coexistence request, the above data may include the feedback result shown above.

The AP may not comply with the coexistence request of non-AP STA 1 and/or the coexistence request of non-AP STA 2. For example, the AP may continue to schedule non-AP STA 1 or non-AP STA 2. Exemplarily, the expected behavior of non-AP STA 1 or non-AP STA 2 may be to allow transmission or to restrict transmission signals. As shown in FIG. 7 , the AP may send a trigger frame, and non-AP STA 1 or non-AP STA 2 may receive the trigger frame.

Exemplarily, the trigger frame includes resource scheduling and other parameters (such as association identifier, coding and modulation strategy, etc.) for one or more users (stations) to send uplink data. Figure 8a is a format diagram of a trigger frame provided in an embodiment of the present application. The trigger frame may include a common information field and a user information list field. The common information field may include common information that multiple users need to read. The user information list field is composed of one or more user information fields, wherein the first user information field may be a special user information field, and the associated identification (associated identification, AID) field is indicated as 2007, and the associated identification field in the special user information field carries some public information. Although it is a user information field, it carries public information, so the first user information field is called a special user information field. Starting from the second user information field, each user information field contains information that each user needs to read separately. In the user information field, association identification 12 (association identification 12, AID12) (such as the lower 12 bits of AID) indicates the association identification of a certain STA, usually referred to as the association identification field. The resource unit (RU) allocation field is combined with the primary and secondary 160 fields to indicate the specific resource unit or multi-resource unit (MRU) position allocated to this user (the user corresponding to AID12). For other descriptions of the trigger frame, please refer to the relevant standards or protocols, which will not be described in detail here.

The trigger frame shown in FIG8a is only an example. As the standard progresses, other types of trigger frames may appear in the future. The trigger frame may also have other formats, which is not limited in the embodiments of the present application.

After receiving the trigger frame, non-AP STA1 or non-AP STA2 can read the common information field and the special user information field, and parse the user information field that matches its own AID. Then send a trigger-based PPDU (TB PPDU) on the RU or MRU indicated by the resource unit allocation field in the user information field. For example, the TB PPDU may include an extremely high throughput trigger-based PPDU (extremely high throughput trigger based PPDU, EHT TB PPDU), or an ultra-high reliability trigger-based PPDU (ultra high reliability trigger based PPDU, UHR TB PPDU). The types of TB PPDUs here are only examples and should not be understood as limitations on the embodiments of the present application.

FIG8b is a format diagram of an EHT TB PPDU provided in an embodiment of the present application. FIG8c is a format diagram of an UHR TB PPDU provided in an embodiment of the present application. Exemplarily, the TB PPDU may include at least one of the following: a legacy short training field (L-STF), a legacy long training field (L-LTF), a legacy signaling field (L-SIG), a repeated legacy signaling field (RL-SIG), a universal signaling (Universal SIG, U-SIG), EHT-STF or UHR-STF, EHT-LTF or UHR-LTF, data or packet extension (PE).

Table 2 exemplarily shows the functions of various fields, but it should not be understood as a limitation on the embodiments of the present application.

Table 2

As shown in Figure 7, after the AP receives the TB PPDU sent by one or more non-AP STAs, it replies with a multi-STA block acknowledgment (multi-STA BA) frame.

FIG8d is a schematic diagram of the format of a multi-STA BA frame provided in an embodiment of the present application. As shown in FIG8d, the multi-STA BA frame may include at least one of the following: frame control, duration, received address (RA), transmitting address (TA), block acknowledgment control (BA control), block acknowledgment information (BA information), or FCS. The block acknowledgment control field may include a block acknowledgment type (BA type), no memory reserved (nomemorykept), a marked memory configuration (memoryconfigurationtag), a management acknowledgment (managementack), or a service identifier (TID info). For the description of each field, please refer to the relevant standards or protocols, which will not be described in detail here. Different block acknowledgment types may correspond to different block acknowledgment information. That is, the value of the block acknowledgment type field is different, and the format of the block acknowledgment information field may also be different. It will not be described in detail here.

In the embodiment of the present application, the coexistence request can be flexibly managed by carrying the coexistence request in the ICF/ICR frame and by using the coexistence request ID and operation type information. At the same time, it also solves the problem of how to make full use of the current TXOP for transmission while ensuring coexistence when the TXOP end times indicated by different non-AP STAs in a multi-user scenario are inconsistent. For example, the AP can schedule these non-AP STAs based on coexistence requests based on different non-AP STAs, such as following the coexistence requests of these non-AP STAs, or not following the coexistence requests of one or more non-AP STAs.

The following is an introduction to the communication device provided in the embodiments of the present application.

The present application divides the functional modules of the communication device according to the above method embodiment. For example, each functional module can be divided according to each function, or two or more functions can be integrated into one processing module. The above integrated modules can be implemented in the form of hardware or in the form of software functional modules. It should be noted that the division of modules in the present application is schematic and is only a logical function division. There may be other division methods in actual implementation. The communication device of the embodiment of the present application will be described in detail below in conjunction with Figures 9 to 11.

FIG9 is a schematic diagram of the structure of a communication device provided in an embodiment of the present application. As shown in FIG9 , the communication device includes a processing module 901 and a transceiver module 902. The transceiver module 902 can implement corresponding communication functions, and the processing module 901 is used to implement corresponding processing functions. For example, the transceiver module 902 can also be called an interface, a communication interface, or a communication module.

In some embodiments of the present application, the communication device may be used to execute the action executed by the first communication device in the above method embodiment. In this case, the first communication device may be a Wi-Fi device itself or a chip or functional module that can be configured in the device, etc. The transceiver module 902 is used to execute the transceiver-related operations of the first communication device in the above method embodiment, and the processing module 901 is used to execute the processing-related operations of the first communication device in the above method embodiment.

Exemplarily, the processing module 901 may be used to generate a coexistence request; the transceiver module 902 may be used to send or output the coexistence request.

Exemplarily, the transceiver module 902 may also be used to receive or input a cache report; or receive or input indication information, etc.

Exemplarily, the transceiver module 902 may include a radio frequency module, an antenna module, etc. Exemplarily, the transceiver module 902 may include a pin module, etc.

Reusing Figure 9, in some other embodiments of the present application, the communication device can be used to perform the actions performed by the second communication device in the above method embodiment. In this case, the communication device can be the Wi-Fi device itself or a chip or functional module that can be configured in the device. The transceiver module 902 is used to perform the transceiver-related operations of the second communication device in the above method embodiment, and the processing module 901 is used to perform the processing-related operations of the second communication device in the above method embodiment.

Exemplarily, the transceiver module 902 may be used to receive or input a coexistence request; the processing module 901 may be used to parse the coexistence request.

Exemplarily, the transceiver module 902 may be used to send or output a cache report; or send or output indication information.

Exemplarily, the transceiver module 902 may include a radio frequency module, an antenna module, etc. Exemplarily, the transceiver module 902 may include a pin module, etc. The transceiver module may include multiple radio frequency modules.

Optionally, in each of the above embodiments, the communication device may further include a storage module, which may be used to store instructions and/or data, and the processing module 901 may read the instructions and/or data in the storage module so that the communication device implements the above method embodiments. Exemplarily, the storage module may be used to store a coexistence request, etc.

In the above-mentioned embodiments, for the specific description of each term or step, please refer to the introduction in the above method embodiment, which will not be described in detail here.

The specific descriptions of the transceiver module and the processing module shown in the above embodiments are only examples. For the specific functions or execution steps of the transceiver module and the processing module, reference may be made to the above method embodiments and will not be described in detail here.

The communication device of the embodiment of the present application is introduced above, and the possible product forms of the communication device are introduced below. Any product of any form having the functions of the communication device described in FIG. 9 above falls within the protection scope of the embodiment of the present application. The following introduction is only for example, and does not limit the product form of the communication device of the embodiment of the present application to this.

In a possible implementation, in the communication device shown in FIG. 9, the processing module 901 may be one or more processors, the transceiver module 902 may be a transceiver, or the transceiver module 902 may also be a sending module and a receiving module, the sending module may be a transmitter, the receiving module may be a receiver, and the sending module and the receiving module are integrated into one device, such as a transceiver. In the embodiment of the present application, the processor and the transceiver may be coupled, etc., and the embodiment of the present application does not limit the connection mode of the processor and the transceiver. In the process of executing the above method, the process of sending information in the above method may be a process in which the processor outputs the above information. When outputting the above information, the processor outputs the above information to the transceiver so that it is transmitted by the transceiver. After the above information is output by the processor, it may also need to be processed in other ways before it reaches the transceiver. Similarly, the process of receiving information in the above method may be a process in which the processor receives the input information. When the processor receives the input information, the transceiver receives the above information and inputs it into the processor. Furthermore, after the transceiver receives the above information, the above information may need to be processed in other ways before it is input into the processor.

As shown in FIG. 10 , the communication device 100 includes one or more processors 1020 and a transceiver 1010 .

In some embodiments of the present application, the communication device may be used to execute the steps, methods or functions executed by the first communication device, such as the processor 1020 may be used to execute the functions or steps implemented by the processing module 901 shown in FIG9 , and the transceiver 1010 may be used to execute the functions or steps implemented by the transceiver module 902 shown in FIG9 . For specific descriptions of the processor 1020 and the transceiver 1010, reference may be made to FIG9 or the method embodiments shown above, which will not be described in detail here.

In other embodiments of the present application, the communication device is used to execute the steps or methods or functions executed by the second communication device, such as the processor 1020 can be used to execute the functions or steps implemented by the processing module 901 shown in Figure 9, and the transceiver 1010 can be used to execute the functions or steps implemented by the transceiver module 902 shown in Figure 9. For specific descriptions of the processor 1020 and the transceiver 1010, reference can be made to Figure 9 or the method embodiments shown above, and no further description is given here.

In various implementations of the communication device shown in FIG10 , the transceiver may include a receiver and a transmitter, wherein the receiver is used to perform a receiving function (or operation) and the transmitter is used to perform a transmitting function (or operation). The transceiver is used to communicate with other devices/devices via a transmission medium.

Optionally, the communication device 100 may further include one or more memories 1030 for storing program instructions and/or data. The memory 1030 is coupled to the processor 1020. The coupling in the embodiment of the present application is an indirect coupling or communication connection between the communication device, unit or module, which may be electrical, mechanical or other forms, and is used for information exchange between the communication device, unit or module. The processor 1020 may operate in conjunction with the memory 1030. The processor 1020 may execute program instructions stored in the memory 1030. Optionally, at least one of the one or more memories may be included in the processor.

The specific connection medium between the above-mentioned transceiver 1010, processor 1020 and memory 1030 is not limited in the embodiment of the present application. In FIG. 10, the memory 1030, processor 1020 and transceiver 1010 are connected through a bus 1040. The bus is represented by a bold line in FIG. 10. The connection mode between other components is only for schematic illustration and is not limited thereto. The bus can be divided into an address bus, a data bus, a control bus, etc. For ease of representation, only one bold line is used in FIG. 10, but it does not mean that there is only one bus or one type of bus.

In the embodiments of the present application, the processor may be a general-purpose processor, a digital signal processor, an application-specific integrated circuit, a field programmable gate array or other programmable logic device, a discrete gate or transistor logic device, a discrete hardware component, etc., and may implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of the present application. The general-purpose processor may be a microprocessor or any conventional processor, etc. The steps of the method disclosed in the embodiments of the present application may be directly embodied as being executed by a hardware processor, or may be executed by a combination of hardware and software modules in the processor, etc.

In the embodiments of the present application, the memory may include, but is not limited to, non-volatile memories such as hard disk drive (HDD) or solid-state drive (SSD), random access memory (RAM), erasable programmable read-only memory (EPROM), read-only memory (ROM) or portable read-only memory (CD-ROM), etc. The memory is any storage medium that can be used to carry or store program codes in the form of instructions or data structures and can be read and/or written by a computer (such as the communication device shown in the present application), but is not limited to this. The memory in the embodiments of the present application can also be a circuit or any other device that can realize a storage function, which is used to store program instructions and/or data.

The processor 1020 is mainly used to process the communication protocol and communication data, and to control the entire communication device, execute the software program, and process the data of the software program. The memory 1030 is mainly used to store the software program and data. The transceiver 1010 may include a control circuit and an antenna. The control circuit is mainly used to convert the baseband signal and the radio frequency signal and process the radio frequency signal. The antenna is mainly used to send and receive radio frequency signals in the form of electromagnetic waves. The input and output devices, such as a touch screen, a display screen, a keyboard, etc., are mainly used to receive data input by the user and output data to the user.

When the communication device is turned on, the processor 1020 can read the software program in the memory 1030, interpret and execute the instructions of the software program, and process the data of the software program. When data needs to be sent wirelessly, the processor 1020 performs baseband processing on the data to be sent, and outputs the baseband signal to the RF circuit. The RF circuit performs RF processing on the baseband signal and then sends the RF signal outward in the form of electromagnetic waves through the antenna. When data is sent to the communication device, the RF circuit receives the RF signal through the antenna, converts the RF signal into a baseband signal, and outputs the baseband signal to the processor 1020. The processor 1020 converts the baseband signal into data and processes the data.

In another implementation, the RF circuit and antenna may be arranged independently of the processor performing baseband processing. For example, in a distributed scenario, the RF circuit and antenna may be arranged remotely from the communication device.

The communication device shown in the embodiment of the present application may also have more components than those in FIG10, and the embodiment of the present application does not limit this. The method performed by the processor and transceiver shown above is only an example, and the specific steps performed by the processor and transceiver can refer to the method described above.

In another possible implementation, in the communication device shown in FIG9 , the processing module 901 may be one or more logic circuits, and the transceiver module 902 may be an input/output interface, or a communication interface, or an interface circuit, or an interface, etc. Alternatively, the transceiver module 902 may also be a sending module and a receiving module, the sending module may be an output interface, the receiving module may be an input interface, and the sending module and the receiving module are integrated into one module, such as an input/output interface. As shown in FIG11 , the communication device shown in FIG11 includes a logic circuit 1101 and an interface 1102. That is, the processing module 901 may be implemented with a logic circuit 1101, and the transceiver module 902 may be implemented with an interface 1102. Among them, the logic circuit 1101 may be a chip, a processing circuit, an integrated circuit, or a system on chip (SoC) chip, etc., and the interface 1102 may be a communication interface, an input/output interface, a pin, etc. Exemplarily, FIG11 is exemplified by taking the communication device as a chip, and the chip includes a logic circuit 1101 and an interface 1102.

In the embodiment of the present application, the logic circuit and the interface can also be coupled to each other. The embodiment of the present application does not limit the specific connection method of the logic circuit and the interface. Exemplarily, the logic circuit 1101 can be used to execute the function or step implemented by the processing module 901 shown in Figure 9, and the interface 1102 can be used to execute the function or step implemented by the transceiver module 902 shown in Figure 9. For the specific description of the logic circuit 1101 and the interface 1102, please refer to Figure 9 or the method embodiment shown above, which will not be described in detail here.

The communication device shown in the embodiment of the present application can implement the method provided in the embodiment of the present application in the form of hardware, or can implement the method provided in the embodiment of the present application in the form of software, etc., and the embodiment of the present application is not limited to this.

An embodiment of the present application further provides a communication system, which includes a first communication device and a second communication device. The first communication device and the second communication device can be used to execute the method in any of the aforementioned embodiments.

In addition, the present application also provides a computer program, which is used to implement the operations and/or processing performed by each communication device in the method provided by the present application.

The present application also provides a computer-readable storage medium, in which computer codes are stored. When the computer codes are executed on a computer, the computer executes the operations and/or processes performed by each communication device in the method provided by the present application.

The present application also provides a computer program product, which includes a computer code or a computer program. When the computer code or the computer program runs on a computer, the operations and/or processes performed by each method provided by the present application are executed.

In the several embodiments provided in the present application, it should be understood that the disclosed systems, communication devices and methods can be implemented in other ways. For example, the communication device embodiments described above are only schematic. For example, the division of the modules is only a logical function division. There may be other division methods in actual implementation, such as multiple modules or components can be combined or integrated into another system, or some features can be ignored or not executed. In addition, the mutual coupling or direct coupling or communication connection shown or discussed can be an indirect coupling or communication connection through some interfaces, communication devices or modules, or it can be an electrical, mechanical or other form of connection.

The modules described as separate components may or may not be physically separated, and the components displayed as modules may or may not be physical modules, that is, they may be located in one place or distributed on multiple network modules. Some or all of the modules may be selected according to actual needs to achieve the technical effects of the solutions provided in the embodiments of the present application.

In addition, each functional module in each embodiment of the present application can be integrated into one processing module, or each module can exist physically separately, or two or more modules can be integrated into one module. The above integrated modules can be implemented in the form of hardware or software functional modules.

If the integrated module is implemented in the form of a software function module and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application is essentially or partly contributed to the prior art, or all or part of the technical solution can be embodied in the form of a software product, and the computer software product is stored in a readable storage medium, including several instructions for a computer device (which can be a personal computer, server, or network device, etc.) to perform all or part of the steps of the method described in each embodiment of the present application. The aforementioned readable storage medium includes: U disk, mobile hard disk, read-only memory (ROM), random access memory (RAM), disk or optical disk, and other media that can store program codes.

The above is only a specific implementation of the present application, but the protection scope of the present application is not limited thereto. Any person skilled in the art who is familiar with the present technical field can easily think of changes or substitutions within the technical scope disclosed in the present application, which should be included in the protection scope of the present application. Therefore, the protection scope of the present application should be based on the protection scope of the claims.

Claims (22)

A communication method, characterized in that the method comprises: The first communication device generates a coexistence request, wherein the coexistence request includes an identifier of the coexistence request and operation type information, where the operation type information is used to indicate an operation type of the coexistence request; The first communication device sends the coexistence request. A communication method, characterized in that the method comprises: The second communication device receives a coexistence request, where the coexistence request includes an identifier of the coexistence request and operation type information, where the operation type information is used to indicate an operation type of the coexistence request; The second communication device parses the coexistence request. The method according to claim 1 or 2, characterized in that the operation type of the coexistence request includes any one of the following: New coexistence request; Removed coexistence request; A coexistence request to modify parameters; or Temporarily pending coexistence request. The method according to any one of claims 1-3 is characterized in that the coexistence request also includes expected behavior information, and the expected behavior information is used to indicate the expected behavior corresponding to the station STA in the first communication device. The method according to claim 4, characterized in that the expected behavior includes any of the following: Allows sending of signals; Restricted reception signals; Allows receiving signals; restricted transmission signals; or Neither sending nor receiving signals is allowed. The method according to claim 4 or 5 is characterized in that the coexistence request also includes time information, and the time information is used to indicate the time period corresponding to the expected behavior. The method according to claim 5 or 6 is characterized in that the coexistence request also includes reception parameters when the first communication device is restricted to receive signals, or transmission parameters when the first communication device is restricted to send signals. The method according to any one of claims 1-7 is characterized in that the coexistence request also includes radio frequency type information, and the radio frequency type information is used to indicate the radio frequency type corresponding to the coexistence request. The method according to any one of claims 1-8 is characterized in that the coexistence request also includes service priority information, and the service priority information is used to indicate the service priority of the radio frequency type corresponding to the coexistence request. The method according to any one of claims 1-9 is characterized in that the coexistence request also includes an interference report, and the interference report is used to indicate interference parameters of the radio frequency type corresponding to the coexistence request, and the interference parameters include at least one of the following: link identification, interference level, channel affected by interference, whether the interference is periodic, whether the interference is symmetric, interference start time, and interference duration. The method according to any one of claims 1-10 is characterized in that the coexistence request also includes monitoring mode enabling information, and the monitoring mode enabling information is used to instruct the first communication device to turn on the monitoring mode or exit the monitoring mode. The method according to any one of claims 1-10 is characterized in that the coexistence request is carried in an initial control frame ICF or an initial control response ICR frame, and the ICF or the ICR frame also includes monitoring mode enable information, and the monitoring mode enable information is used to instruct the first communication device to turn on the monitoring mode or exit the monitoring mode. The method according to claim 11 or 12, characterized in that when the monitoring mode enabling information is a first value, it indicates that the first communication device exits the monitoring mode, and the mode to be switched by the first communication device is determined based on power management information; or When the monitoring mode enabling information is a second value, it indicates that the first communication device turns on the monitoring mode, and the state of the first communication device is determined based on at least one of power management information or more data information. The method according to claim 1, characterized in that the method further comprises: The first communication device receives a feedback result regarding the coexistence request. The method according to claim 2, characterized in that the method further comprises: The second communication device sends a feedback result regarding the coexistence request. The method according to claim 14 or 15, characterized in that The feedback result includes a cache report, and the cache report includes at least one of the following: the size of the cache data, the minimum remaining time of the cache data, or the service priority of the cache data; or The feedback result includes more data fields, where the more data fields are used to indicate the state of the first communication device; or The feedback result includes indication information, where the indication information is used to indicate that the scheduling of the first communication device in this transmission opportunity TXOP has ended. A communication device, characterized in that it comprises a module for executing the method as described in any one of claims 1-16. A communication device, characterized in that it comprises a processor, wherein the processor is used to execute the method according to any one of claims 1-16. A communication device, characterized in that it comprises a logic circuit and an interface, wherein the logic circuit and the interface are coupled; The interface is used to input and/or output information, and the logic circuit is used to execute the method according to any one of claims 1-16. A computer-readable storage medium, characterized in that the computer-readable storage medium is used to store a computer program, and when the computer program is executed, the method according to any one of claims 1 to 16 is executed. A computer program product, characterized in that when the computer program product is executed, the method according to any one of claims 1 to 16 is executed. A communication system, characterized in that the communication system includes a first communication device and a second communication device, the first communication device is used to execute the method as described in any one of claims 1, 3-14, and 16, and the second communication device is used to execute the method as described in any one of claims 2-13, 15, and 16.