Communication methods and communication apparatus

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

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

[0002] The present application relates to the field of communication technology, and in particular to a communication method and device. Background Art

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

[0004] 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 through a coexistence request.

[0005] Therefore, the signaling indication in the coexistence request is a problem being studied by those skilled in the art. Summary of the Invention

[0006] The embodiments of the present application provide a communication method and apparatus that can flexibly manage different coexistence requests.

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

[0008] The first communication device generates a coexistence request (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 first communication device sends the coexistence request.

[0009] In an embodiment of the present application, the first communication device may include a (transmit opportunity, 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.

[0010] In the embodiment of the present application, the first communication device sends a coexistence request including an identifier and operation type information to the second communication device, so that the second communication device can flexibly manage different coexistence requests in combination with the identifier and perform different operations on the coexistence requests.

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

[0012] 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.

[0013] In an embodiment of the present application, the second communication device can determine 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 combine the coexistence request to determine: how to schedule the first communication device (for example, if the first communication device is a non-AP STA), or whether to end the TXOP early, etc., or can select the working bandwidth or the maximum number of transceiver streams or the maximum modulation and coding mode, etc., so that the second communication device can reasonably perform different processing.

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

[0015] New coexistence request; removed coexistence request; coexistence request with modified parameters; or temporarily suspended coexistence request.

[0016] 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.

[0017] With reference to 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.

[0018] In the embodiment of the present application, different radio frequency types may correspond to different service priorities. Therefore, 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.

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

[0020] In this embodiment of the present application, the first communication device may include an STA and may also include a radio frequency module corresponding to the above-mentioned 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 being interfered with by another STA. That is, the above-mentioned Wi-Fi may be the Wi-Fi corresponding to the coexistence request in the first communication device.

[0021] 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 the service priority of the radio frequency type corresponding to the coexistence request.

[0022] In an embodiment of the present application, the second communication device can obtain the radio frequency type service priority 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.

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

[0024] In combination with the first aspect or the second aspect, in one possible implementation, 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.

[0025] In an embodiment of the present application, a link identifier may indicate the identifier of a link affected by coexistence interference. An interference level may indicate the intensity or magnitude of interference to a STA within the first communication device. An interference-affected channel indicates the channel where the interference occurs. If the interference is periodic, it indicates that the interference generated by other RF modules within the first communication device is periodic; if the interference is aperiodic, it indicates that the interference generated by other RF modules within the first communication device is aperiodic. Other RF modules refer to RF modules other than STAs within the first communication device (which may also include other STAs). If the interference is symmetric, it indicates that the RF module corresponding to the coexistence request will cause interference to the STA within the first communication device, and that the STA will also cause interference to the aforementioned RF module; if the interference is asymmetric, it indicates that the RF module corresponding to the coexistence request causes interference to the STA, that the STA will not cause interference to the aforementioned RF module, or that the interference caused by the STA to the aforementioned RF 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 the interference is periodic, it means that the interference will occur at a certain period. For example, 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. 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.

[0026] 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 expected behavior of the STA in the first communication device.

[0027] 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.

[0028] 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.

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

[0030] Transmission of signals is permitted; reception of signals is restricted; reception of signals is permitted; transmission of signals is restricted; or neither transmission nor reception of signals is permitted.

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

[0032] In combination with the first aspect or the second aspect, in one possible implementation, the sending parameters include at least one of the following: link identifier, maximum number of streams (or maximum 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 and coding mode, or maximum LDPC codeword length (max LDPC codeword length).

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

[0034] In combination with the first aspect or the second aspect, in one possible implementation, 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 listening mode enable information, and the listening mode enable information is used to instruct the first communication device to turn on the listening mode (or called listening mode) or exit the listening mode.

[0035] 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 or exit the monitoring mode.

[0036] 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 item of power management information or more data information.

[0037] With reference to the first aspect, in a possible implementation manner, the method further includes: the first communication apparatus receiving a feedback result regarding the coexistence request from the second communication apparatus.

[0038] In the embodiment of the present application, the second communication device sends 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.

[0039] With reference to the second aspect, in a possible implementation manner, the method further includes: the second communication apparatus sending a feedback result regarding the coexistence request to the first communication apparatus.

[0040] In combination with the first aspect or the second aspect, in one possible implementation, the feedback result includes a cache report, which 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, which are used to indicate the status of the first communication device; or, the feedback result includes indication information, which is used to indicate that the scheduling of the first communication device in this transmission opportunity TXOP has ended.

[0041] 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 configured to execute the method in the first aspect or any possible implementation.

[0042] In a fourth aspect, embodiments of the present application provide a second communication device configured to execute the method in the second aspect or any possible implementation. The second communication device includes a module configured to execute the method in the second aspect or any possible implementation.

[0043] In a fifth aspect, an embodiment of the present application provides a 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.

[0044] In a possible implementation, the memory is located outside the first communication device.

[0045] In a possible implementation, the memory is located within the first communication device.

[0046] 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. For example, the first communication device may be a chip.

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

[0048] In a sixth aspect, an embodiment of the present application provides a 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.

[0049] In a possible implementation, the memory is located outside the second communication device.

[0050] In a possible implementation, the memory is located within the second communication device.

[0051] 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.

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

[0053] 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.

[0054] 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.

[0055] In the 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 above-mentioned first to second aspects or any possible implementation method is executed.

[0056] 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 thereof to be executed.

[0057] 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.

[0058] 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

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

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

[0061] FIG2 b is a schematic diagram of an address of an MLD provided in an embodiment of the present application;

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

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

[0064] FIG4 b is a schematic diagram of the format of a frame control field provided in an embodiment of the present application;

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

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

[0067] FIG6 a is a schematic diagram of a format of an expected behavior field provided in an embodiment of the present application;

[0068] FIG6 b is a schematic diagram of a format of a coexistence request provided in an embodiment of the present application;

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

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

[0071] FIG8 b 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;

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

[0073] FIG8 d is a schematic diagram of the format of a multi-STA block acknowledgement (multi-STA BA) frame provided in an embodiment of the present application;

[0074] FIG9 is a schematic structural diagram of a communication device provided in an embodiment of the present application;

[0075] FIG10 is a schematic structural diagram of a communication device provided in an embodiment of the present application;

[0076] FIG11 is a schematic structural diagram of a communication device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0077] To facilitate understanding of the technical solution of the present application, the present application will be further described below with reference to the accompanying drawings.

[0078] The terms "first" and "second" in the specification, claims, and drawings of this application are used only to distinguish different objects and are not used 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 the process, method, product, or device.

[0079] References to "embodiments" herein mean that a particular feature, structure, or characteristic described in connection with the embodiments may 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 does it refer to independent or alternative embodiments that are mutually exclusive of other embodiments. It will be understood, both explicitly and implicitly, by those skilled in the art that the embodiments described herein may be combined with other embodiments.

[0080] In this 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 can 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 can exist, such as only A exists, only B exists; when A and B are not mutually exclusive, it can also mean that three relationships exist, such as only A exists, only B exists, and A and B exist at the same time. The character " / " generally indicates that the previous and next associated objects 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".

[0081] 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.

[0082] In this 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 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 with the help of the arrangement order of each information agreed in advance (for example, stipulated by the protocol), thereby reducing the indication overhead to a certain extent. In addition, the information to be indicated can be sent together 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.

[0083] In this application, "sending" and "receiving" indicate the direction of signal transmission. For example, "sending 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 receiving from YY through the air interface, and also include indirect receiving from YY through the air interface from other units or modules. "Sending" can also be understood as the "output" of the chip interface, and "receiving" can also be understood as the "input" of the chip interface. In other words, sending and receiving can be carried out between devices, for example, between network devices and terminal devices, or can be carried out within a device, for example, sending or receiving between components, modules, chips, software modules or hardware modules within the device through a bus, trace or interface.

[0084] The present application provides a communication method and apparatus that can flexibly manage coexistence requests.

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

[0086] The technical solutions provided in the embodiments of the present application can be applied to wireless local area network (WLAN) systems, such as Wi-Fi. 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 the 802.11be protocol, the 802.11bn protocol (802.11bn is also known as Wi-Fi 8, or ultra high reliability (UHR) or ultra high reliability and throughput (UHRT) or the next generation of the 802.11bn protocol or the protocol that supports ambient power (AMP), 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 (WPANs) based on millimeter wave (MMW) and ultra wideband (UWB) technologies. The method provided in the embodiment of the present application can be applied to the IEEE802.15 series protocols, such as the 802.15.4a protocol, the 802.15.4z protocol or the 802.15.4ab protocol, or a future generation of UWB 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 emerging in future communication development. For example, the V2X may include: vehicle to vehicle (V2V), vehicle to infrastructure (V2I), vehicle to pedestrian (V2P) or vehicle to network (V2N) communication.

[0087] WLAN systems can provide high-speed and low-latency transmission. As WLAN application scenarios continue to evolve, WLAN systems will be applied to more scenarios or industries, such as the Internet of Things industry, the Internet of Vehicles industry, 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 stations) 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, displays, TVs, 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, infrastructure in daily life scenarios (such as vending machines, self-service navigation counters in supermarkets, self-service checkout equipment, self-service ordering machines, etc.), and equipment in large sports and music venues.

[0088] Although the embodiments of the present application primarily use WLAN as an example, particularly networks based on the IEEE 802.11 standard, the various aspects of the embodiments of the present application can be extended to other networks based on various standards or protocols, such as Bluetooth, high-performance wireless LAN (HIPERLAN) (a wireless standard similar to the IEEE 802.11 standard), wide area network (WAN), or other networks now known or developed in the future.

[0089] The method provided in the embodiments 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 details:

[0090] An AP is a device with wireless communication capabilities that supports communication, perception, or energy transmission using WLAN protocols. It has the ability to communicate, perceive, or transmit energy with other devices in a WLAN network (such as non-access point stations (non-AP STAs) or other access points). Of course, it can also have the ability to communicate, perceive, or transmit energy with other devices. Alternatively, an access point is equivalent to a bridge connecting a wired network and a wireless network. Its main function is to connect various wireless network clients together and then connect the wireless network to the Ethernet. In a WLAN system, an access point can be called an access point station (AP STA). The device with wireless communication capabilities can be a complete device, or it can be a chip, processing system, or functional module installed in the complete device. The device in which these chips, processing systems, or functional modules are installed can implement the methods and functions of the embodiments of the present application under the control of the chips, processing systems, or functional modules. The AP in the embodiments of the present application is a device that provides services for non-AP STAs 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, inside buildings, and inside campuses, 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, etc. Of course, an AP can also be a chip or processing system or module in the various forms of devices mentioned above, so as to realize 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 MLD) shown below.

[0091] A STA is a device with wireless communication capabilities that supports communication, sensing, or energy transmission using the WLAN protocol and has the ability to communicate, sense, or transmit energy with other non-AP STAs or access points in the WLAN network. In a WLAN system, a station can be referred to as a non-access point station (non-AP STA). For example, a STA is any user communication device that allows a user to communicate, sense, or transmit energy with an AP and thereby communicate with the WLAN. The device with wireless communication capabilities can be a complete device, or a chip, processing system, or functional module installed in the complete device. Devices equipped with these chips, processing systems, or functional modules can implement the methods and functions of the embodiments of the present application under the control of the chip, processing system, or functional module. For example, a STA can be a wireless communication chip, a wireless sensor, or a wireless communication terminal, and can also be referred to as a user. For another example, a STA can be a mobile phone that supports Wi-Fi communication capabilities, a tablet that supports Wi-Fi communication capabilities, a set-top box that supports Wi-Fi communication capabilities, a smart TV that supports Wi-Fi communication capabilities, a smart wearable device that supports Wi-Fi communication capabilities, an in-vehicle communication device that supports Wi-Fi communication capabilities, and a computer that supports Wi-Fi communication capabilities. Of course, the STA can also be a chip, processing system, or module in the various forms of devices described above, thereby implementing the methods and functions of the embodiments of the present application. The description of the STA here also applies to the non-AP multi-link device (non-AP multi-link device, non-AP MLD) shown below.

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

[0093] A multi-link device (MLD) is a device that simultaneously has multiple STAs (such as APs or non-AP STAs), each operating on different frequency bands or channels. When the channel spacing between two stations within a multi-link device is large enough, they can operate independently without interfering with each other. If any two stations can support one station transmitting while the other station is receiving, they are said to support simultaneous transmitting and receiving (STR) capability; otherwise, they are said to not have non-simultaneous transmitting and receiving (NSTR) capability. A multi-link device includes multiple subordinate stations, which can be physical or logical stations. Each station can operate on a link, a frequency band, a channel, etc. The subordinate stations shown here can be APs or non-AP STAs. For 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, a multi-link AP device, or an AP multi-link device (AP MLD). A multi-link device whose subordinate station is a non-AP STA is called a multi-link STA, a multi-link STA device, or a STA multi-link device (STA multi-link device, STA MLD). Alternatively, a multi-link device whose subordinate station is a non-AP STA is called a multi-link non-AP, 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 can be either a non-AP MLD or an AP MLD) is a communication device with wireless communication capabilities. The communication device can be a complete device, or a chip or processing system installed in the complete device. Devices installed with these chips or processing systems can implement the methods and functions of the embodiments of the present application under the control of these chips or processing systems.

[0094] FIG1 is a schematic diagram of the architecture of a communication system provided by an embodiment of the present application. As shown in FIG1 , the embodiment of the present application can be applied to scenarios such as communication or perception between an AP and a non-AP STA, between APs, or between non-AP STAs in a WLAN, and the embodiment of the present application is not limited thereto. For example, an AP can communicate or perceive with a single non-AP STA, or the AP can communicate or perceive with multiple non-AP STAs simultaneously. For example, communication or perception between an AP and multiple non-AP STAs can be further divided into downlink transmission in which the AP simultaneously sends signals to multiple non-AP STAs, and uplink transmission in which multiple non-AP STAs send signals to the AP. For example, AP1 can be an AP belonging to an AP MLD, or AP2 can be an AP belonging to an MLD. For example, non-AP STA1, non-AP STA2, or non-AP STA3 can be a non-AP STA belonging to a non-AP MLD. Among them, WLAN communication protocols can be supported between APs and non-AP STAs, between APs and APs, and between non-AP STAs and non-AP STAs. The communication protocols may include IEEE802.11 series protocols, such as 802.11bn protocol, and of course also applicable to protocols after 802.11bn.

[0095] Figure 1 uses a mobile phone as a non-AP STA and a router as an example, and does not limit the types of APs and non-AP STAs used in the embodiments of this application. Furthermore, the number of APs and non-AP STAs shown in Figure 1 is merely an example. In specific implementations, the number of APs or non-AP STAs may be greater or lesser, and this is not limited in the embodiments of this application.

[0096] Figure 2a 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 multi-link devices, so Figure 2a exemplarily shows the PHY and MAC layers.

[0097] As shown in Figure 2a, a multi-link device (such as a multi-link AP or a multi-link non-AP) may include a physical layer (PHY) (PHY#1 and PHY#2 as shown in Figure 2a) and a 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. Furthermore, the MAC layer can be divided into a high-MAC layer (high-MAC as shown in Figure 2a) and multiple low-MAC layers (low-MAC#1 and low-MAC#2 as shown in Figure 2a). As shown in Figure 2a, the multiple APs included in a 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 a 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, and the high-MAC layer can be shared by multiple links. Exemplarily, the high MAC layer mainly completes the allocation of sequence numbers (SN) and packet numbers (PN) of MAC service data units (MSDUs), as well as encryption and decryption operations. Exemplarily, the low MAC layer mainly completes the assembly of MAC protocol data units (MPDUs) of their respective links, 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 limiting the embodiments of the present application.

[0098] In Figure 2a, the PHY#1 layer, lower MAC#1 layer, and upper MAC layer in a multi-link AP can be considered AP#1, and the PHY#2 layer, lower MAC#2 layer, and upper MAC layer can be considered AP#2. This means that the multi-link AP can include two AP entities. In a multi-link non-AP, the situation is similar. The upper MAC layer in the multi-link non-AP is also shared by multiple links. The PHY#1 layer, lower MAC#1 layer, and upper MAC layer are considered STA#1 (or non-AP STA#1), and the PHY#2 layer, lower MAC#2 layer, and upper MAC layer are considered STA#2 (or non-AP STA#2). This means that the multi-link non-AP includes two STA entities (i.e., two non-AP STA entities). As shown in Figure 2a, PHY#1 of AP#1 in the multi-link AP and PHY#1 of STA#1 in the multi-link non-AP operate on the same channel. For example, AP#1 in the multi-link AP and STA#1 in the multi-link non-AP communicate via a link (Link#1 in Figure 2a). 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. For example, 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. 2 a).

[0099] Exemplarily, the high MAC layer or the low MAC layer can be implemented by a processor in the chip system of the 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 the functional modules of the 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, etc. The PHY and MAC layers shown in Figure 2a can be understood as a division of logical functions. In actual implementation, there can be other division methods. Figure 2a is shown as an example of a multi-link device including 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.

[0100] A non-AP MLD can establish associations with multiple links of an AP MLD simultaneously by performing a multi-link establishment operation on one of the links. The link that exchanges a multi-link association request frame or a multi-link association response frame is called a transmitted link, and the other links are called non-transmitted links. A multi-link association request frame or a multi-link association response frame can carry information about multiple links to enable simultaneous association of multiple links. For the multi-link establishment or association process, refer to the relevant standards or protocols and will not be described in detail here.

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

[0102] FIG3 is a schematic diagram of a framework of a communication device provided by 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 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 (5G) module, and a 5G wireless module. th-generation, 5G) module, etc. 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.

[0103] The interface in Figure 3 may include a 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 buffering data shown below can be understood as the corresponding wireless module receiving and sending signals or buffering data.

[0104] 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, etc. 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 that coexist 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.

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

[0106] From the perspectives of sending and receiving a coexistence request, the first communication device described below may be the communication device that sends the coexistence request, and the second communication device may be the communication device that receives the coexistence request. Alternatively, the first communication device may be referred to as a transmitter, and the second communication device may be referred to as a receiver.

[0107] In terms of the TXOP holder and 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 the device where the non-AP STA is located has other radio frequency modules inside. As another example, a non-AP STA may serve as a TXOP holder, and an AP may serve as a TXOP responder, if the device where the AP is located has other radio frequency modules inside. As yet another example, both the TXOP holder and the TXOP responder may have other radio frequency modules inside. The AP or non-AP STA described above may also be an AP or non-AP STA belonging to an MLD.

[0108] 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.

[0109] The following introduces the terms involved in the embodiments of this application.

[0110] 1. Medium protocol data unit (MPDU)

[0111] Figure 4a is a schematic diagram of the format of an MPDU provided in an embodiment of the present application. As shown in Figure 4a, 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 descriptions of each field, please refer to the relevant standards or protocols and will not be detailed here.

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

[0113] 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 power-saving mode whether the transmitter has any cached data to be received by the receiver. In power-saving mode, the transmitter can switch back and forth between awake and dormant states. 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 dormant state. For descriptions of other fields, please refer to the relevant standards or protocols and will not be described in detail here. The transmitter shown here is the communication device that sends the above-mentioned MPDU, and the receiver can be the device that receives the MPDU.

[0114] For example, 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 merely an example, and as standards evolve, the HT Control field may have other formats. The relationship between the values ​​and meanings of the various bits shown in Table 1 is merely an example and should not be construed as limiting the embodiments of this application.

[0115] Table 1

[0116] Figure 4c is a schematic diagram of the format of an A-Control field provided in an embodiment of the present application. As shown in Figure 4c, the A-Control field may include a control list and padding. The control list field may include one or more control fields, each of which may include a control identifier (control ID) and control information.

[0117] The number of bits (or bytes) occupied by each field given in the drawings of the embodiments of the present application, the order between different fields, etc. are only examples, and should not limit the format or frame length or the order of each field proposed in the embodiments of the present application. The names of the various frames and the fields contained in the drawings of the embodiments of the present application are only examples, and should not limit the various frames proposed in the embodiments of the present application. For ease of description, the various embodiments shown in this application are shown as "fields" and do not specifically distinguish between "fields", "subfields", "elements", "sub-elements", etc. Although the various embodiments shown in this 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 embodiments of the present application.

[0118] 2. Transmit opportunity (TXOP)

[0119] A transmission opportunity is 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 is indicated by the duration field in the MPDU header (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 limit set by the access category (AC) corresponding to the frame.

[0120] Generally speaking, a device that obtains a TXOP may be called a TXOP holder, and a corresponding receiving end may be called a TXOP responder.

[0121] 3. Coexistence Request

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

[0123] As an example, the coexistence request sent by the first communication device may be a coexistence request from 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.

[0124] As another example, the coexistence request sent by the first communication device is a coexistence request after multiple RF modules inside the device are merged. 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.

[0125] The following describes the methods involved in the embodiments of the present application.

[0126] FIG5 is a flow chart of a communication method provided in an embodiment of the present application. As shown in FIG5 , the method includes:

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

[0128] When the first communication device is an MLD, the coexistence request can be sent by a STA affiliated with the MLD. Exemplarily, before sending the coexistence request, the first communication device can also obtain or generate the coexistence request. For example, the step of obtaining the coexistence request can be performed by the STA. As an example, the step of generating the coexistence request can be performed by the STA. As another example, the step of generating the coexistence request can be performed by a processing module in the MLD. The embodiments of the present application do not limit which chip or functional module generates the coexistence request.

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

[0130] As another example, a coexistence request may be included in a data frame. The format of this data frame can be found in the description of the MPDU shown in Figure 4a and will not be detailed here. For example, the coexistence request may be carried in the control information field within the A-Control field. For the format of the A-Control field, see Figure 4c. The aforementioned control frames, management frames, or data frames may be collectively referred to as radio frames.

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

[0132] In the embodiment of the present application, the first communication device sends a coexistence request, which enables the second communication device to make a reasonable decision (or process) based on the coexistence request. This decision may include, but is not limited to: terminating the current TXOP early, terminating the scheduling of the first communication device in the current TXOP early (i.e., no longer scheduling the first communication device in the current TXOP), reasonably scheduling the first communication device, or selecting the operating bandwidth, maximum number of transmit and receive streams, or maximum modulation and coding mode.

[0133] 502. The second communication device parses the coexistence request.

[0134] In example 1, a TXOP holder can respect and follow coexistence requests from one or more TXOP responders and schedule transmissions based on the coexistence requests. Meanwhile, a STA (e.g., a non-AP STA or an AP) can also remove, suspend, or modify a coexistence request (as indicated by the operation type information below).

[0135] In the second example, 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 coexistence requests 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 this 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 about 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 within 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 during the time when coexistence interference exists with the non-AP STA or reduce the modulation and coding strategy.

[0136] For details about the steps performed by the second communication device, please refer to the description of the feedback result below, which will not be described in detail here.

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

[0138] 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 enable information, which is described in detail below.

[0139] 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, some of the above information can be carried in other elements or other fields in the radio frame other than the coexistence request, and the other part of the information can be 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 this embodiment of the present application.

[0140] 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.

[0141] (1) Logo

[0142] The identifier can be used to uniquely identify a coexistence request. For example, the identifier can include a coexistence request identifier (ID). To facilitate the management of coexistence requests between different radio frequency modules, the first communication device can assign an identifier, such as a coexistence request ID, to each coexistence request. 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.

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

[0144] By including a 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 flexibility of coexistence request management. Subsequently, the second communication device can use the coexistence request ID to distinguish different coexistence requests sent by the first communication device, or distinguish coexistence requests from different first communication devices, making it easier for the second communication device to manage different coexistence requests and improving management efficiency.

[0145] (2) Operation type information

[0146] 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 new coexistence request; a removed coexistence request; a coexistence request with modified parameters; or 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.

[0147] Exemplarily, the operation type information may be carried in the operation type field in the coexistence request. The names of the operation type information or the operation type field are only examples. 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.

[0148] 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 resumed, or the coexistence request is temporarily suspended until the indicated time point. The description of 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.

[0149] When the operation type information indicates that the coexistence request is a temporarily suspended coexistence request, the coexistence request may also include information indicating the resumption time of the coexistence request (not shown in Figure 6b). 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 will not be 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.

[0150] The second communication device may learn the operation type of the coexistence request based on the operation type information. For example, the second communication device may perform different processing for different operation types.

[0151] 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. 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 of the coexistence request. As another example, when the operation type information indicates that the coexistence request is a coexistence request that needs to modify the 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 the 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. The coexistence request becomes valid again after the moment indicated by the above-mentioned recovery time information.

[0152] (3) RF type information

[0153] 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 can 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 can also be replaced by the radio frequency module corresponding to the coexistence request, or the wireless module corresponding to the coexistence request, etc.

[0154] As an example, when the value of the RF type information is a special value, the RF type information can 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 can 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; and 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.

[0155] The second communication device can learn the radio frequency type of the coexistence request based on the radio frequency type information, and make reasonable decisions based on the radio frequency type. For example, the second communication device can determine whether to follow (or respect or comply with) the coexistence request based on the radio frequency type. In order to avoid interference between different radio frequency modules within 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 (within the interference window as 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 radio frequency type is 5G, the 5G module corresponds to low-latency services, and the second communication device can follow the coexistence request from the first communication device. They are not listed one by one here.

[0156] (4) Business priority information

[0157] 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 (traffic priority) field.

[0158] 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 two bits. These two bits can indicate four different access types. 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 four bits. If DSCP is a quality of service (QoS) classification standard, priorities can be distinguished by encoding values. For example, DSCP may occupy six 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 cached data corresponding to other radio modules. The cached data may be 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 severely degraded. Generally speaking, the shorter the minimum remaining time, the higher the service priority corresponding to the cached data.

[0159] 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, thereby reasonably scheduling the first communication device so that the first communication device can send and receive data of different service priorities based on the coexistence interference situation.

[0160] (5) Interference Report

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

[0162] 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 a 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 can carry an interference report. The interference report can indicate the parameters of the interference caused by the radio frequency type corresponding to the coexistence request to the STA.

[0163] 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, one indicating the interference parameters caused by the radio type corresponding to the coexistence request to the STA and the other indicating the interference parameters caused by the STA to the radio type.

[0164] 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.

[0165] 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 FIG6 b ), interference level, channel affected by interference, whether the interference is periodic or non-periodic, 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 channel affected by interference 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 (or duration or duration, etc.) field 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.

[0166] Among them, the link ID refers to the identifier of the link affected by the coexistence interference. The interference level is used to indicate the interference intensity or size of the interference to the STA. The channel affected by the 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 at 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.

[0167] The information shown above is shown by taking the example of being carried in the interference report, such as 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 the 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. These repeated information may not appear repeatedly in the coexistence request, or these repeated information may also appear repeatedly in the coexistence request. The embodiment of the present application does not limit this.

[0168] (6) Expected behavior information

[0169] 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 interference caused by other radio frequency modules to the STA.

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

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

[0172] a. Allowed to send signals (available Tx), or not allowed 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 radio frequency 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 radio frequency inside the first communication device) to send signals. In this way, the interference of other radio frequency modules on the STA can be reduced as much as possible, and the interference can be controlled within a reasonable range.

[0173] b. Restricted Rx, or allowing transmission and reception 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 reception parameters for the STA within the first communication device to receive signals with restrictions. The reception parameters include at least one of the following: link ID, maximum number of streams, expected receive margin, expected maximum data length, expected bandwidth, coding type (or coded modulation type, etc.), maximum LDPC codeword length, and maximum MCS.

[0174] Among them, the link ID is used to indicate the identifier of the link affected by 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 when the STA receives 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.

[0175] In the embodiment of the present application, by including receiving parameters in the coexistence request, coexistence between multiple radio frequency modules within the first communication device can be achieved, and mutual interference can be reduced as much as possible.

[0176] c. Available Rx allows reception of signals, or disallowed Tx allows transmission of signals. For example, based on interference within the first communication device, the STA desires to receive signals. The second communication device can send signals to the first communication device based on this desired behavior information. For example, other RF modules within the first communication device can receive signals, and the STA can also desire to receive signals, thereby minimizing mutual interference.

[0177] 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 with restrictions. The transmission parameters include at least one of the following: link identifier, maximum number of streams, maximum transmit power, minimum transmit power, expected receive redundancy, expected maximum data length, expected bandwidth, and 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 using the transmission parameters in the coexistence request.

[0178] The maximum transmit power may be used to indicate the maximum transmit power allowed by the STA when sending a TB-PPDU. The minimum transmit power may be used to indicate the minimum transmit power that the second communication device may use when sending a signal to the first communication device. For descriptions of other parameters, please refer to the description in section b and will not be detailed here.

[0179] 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 minimizing mutual interference as much as possible.

[0180] e. Disallowed Tx and disallowed Rx, or unavailable. For example, within the interference window, the first communication device neither transmits nor receives signals. For example, other radio frequency modules may cause significant interference to the STA, making it impossible to control the interference within a reasonable range. Therefore, the STA desires to neither transmit nor receive signals.

[0181] 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, etc. 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 indicated in (5) (such as the interference start time, interference duration, interval or number). 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 be 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 an explanation of the time information, reference may be made to the description of the interference start time, interference duration, interval or number in (5) above, which will not be repeated here.

[0182] 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 not overlap at all 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 mentioned above.

[0183] Exemplarily, the coexistence request may also include information indicating whether they are the same (not shown in FIG6 b ). This information 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.

[0184] Figure 6a is a schematic diagram of the format of an expected behavior field provided by an embodiment of the present application. As shown in Figure 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.

[0185] 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 called an 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.

[0186] The Expected Behavior Control field can be used to indicate any of the above items a through e. As an example, the Expected Behavior Control field can occupy 3 bits. If the value of this field is value #1, it can indicate that the expected behavior is to allow signal transmission; if the value of this field is value #2, it can indicate that the expected behavior is to restrict signal reception; if the value of this field is value #3, it can indicate that the expected behavior is to allow signal reception; if the value of this field is value #4, it can indicate that the expected behavior is to restrict signal transmission; and if the value of this field is value #5, it can indicate that the expected behavior is neither to allow signal transmission nor to allow signal reception. As another example, the Expected Behavior Control field can occupy 5 bits. If the first bit of these 5 bits can be used to indicate that the expected behavior is to allow signal transmission, the first bit can correspond to a above. Similarly, the second bit can correspond to b above, the third bit can correspond to c above, the fourth bit can correspond to d above, and the fifth bit can correspond to e above. These are not listed here one by one. The relationship between the bit order and meaning shown here is only an example and should not be understood as limiting the embodiments of the present application.

[0187] The bitmap presence 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 presence 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 presence field can be longer or shorter, and the above information that may appear in the expected behavior field can be more or less, and the embodiments of the present application do not limit this.

[0188] Figure 6b is a schematic diagram of the format of a 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.

[0189] 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 a to e above. 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.

[0190] (7) Listening mode enable information

[0191] The listening mode enable information can be used to instruct a first communication device (e.g., a STA within the first communication device) to enable or exit listening mode (also known as listening mode). Generally, to conserve energy, a STA can choose to operate in listening mode. In listening mode, the STA can transmit and receive signals using a small bandwidth, a single stream, or a low MCS. This effectively reduces power consumption of the communication device.

[0192] In an embodiment of the present application, the listening mode enabling information may be carried in a coexistence request. Alternatively, the listening mode enabling information may be carried in a radio frame, and the radio frame includes the listening mode enabling information and the coexistence request. In other words, the coexistence request does not include the listening mode enabling information, but the radio frame including the coexistence request includes the listening 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.

[0193] As an example, when the listening mode enabling information is a first value, it indicates that the first communication device exits the listening 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.

[0194] In mode 1A, if the value of the monitoring mode enabling information is 0, the first communication device may exit the monitoring mode, such as switching to the active mode (or active mode) by default.

[0195] In mode 2A, if the value of the listening mode enable information is 0, the first communications device may exit listening mode and switch to a designated mode. The designated mode may be determined by a power management field in a radio frame including a coexistence request. The power management field may be used to carry power management information. For a description of the power management field, refer to Term 1 above.

[0196] 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.

[0197] For another example, a value of 0 in the power management field indicates exiting the listening mode and switching to the active state (also 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, a value of 0 in the power management field may indicate exiting the listening mode and switching to the energy-saving mode; a value of 1 in the power management field indicates exiting the listening mode and switching to the active mode.

[0198] As another example, when the listening mode enable information has a second value, it indicates that the first communications device is in listening mode. The state of the first communications device is determined based on at least one of the power management information and the additional data information. For example, the second value may be 1. Generally speaking, the listening mode may include an awake state or a doze state.

[0199] In mode 1B, if the value of the listening mode enable information is 1, the first communications device enters listening mode and remains in an awake state, not permitted to switch to a sleep state. In listening mode, while awake, the first communications device can transmit and receive signals using low bandwidth, single stream, or low MCS parameters. For mode 1B, listening mode and energy-saving mode can operate in parallel.

[0200] In mode 2B, the listening mode enable information has a value of 1. The first communications device can switch between an awake state and a dormant state based on the power management field or multiple data fields. For example, in listening mode, the first communications device can switch back and forth between the awake state and the dormant state. For mode 2B, the listening mode and the energy-saving mode can be used in combination.

[0201] For example, if the value of the Power Management field is 1, the first communications device may 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 communications device may receive signals using the receive parameters in the coexistence request until the More Data field is set to 0, at which point the first communications device may switch to the sleep state.

[0202] 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.

[0203] By reusing the meaning of more current data fields, the monitoring mode and energy-saving mode can be paralleled, and the two can be used together (such as in the above method 2B) or separately (such as in method 1B). This is equivalent to adding a monitoring mode without changing the existing energy-saving mode operation, with minimal changes to the protocol.

[0204] 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 identifier or operation type information, so that the second communication device can flexibly manage different coexistence requests.

[0205] 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. Based on the feedback result, the first communication device can be informed of the decision of the second communication device. For example, the feedback result may explicitly indicate the decision of the second communication device, or it 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 using the TXOP holder and TXOP responder as an example:

[0206] Method 1: The feedback result may include or be a cache report. This cache report may indicate the status of the data cached by the TXOP holder. For example, this cache report may be carried in the ICF or A-control. After receiving this cache report, the TXOP responder can determine whether it has other higher-priority data to receive.

[0207] For example, when a non-AP STA receives a buffer report from an AP indicating that the non-AP STA has higher-priority data 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 buffer report). The non-AP STA may carry the coexistence request in a BA or A-Control field or an ICR frame, and instruct the AP to temporarily suspend or remove the corresponding coexistence request (such as the coexistence request before receiving the buffer report) through operation type information. For example, the coexistence request may include a coexistence request ID, operation type information, and resumption time information. The resumption time information may also be carried in a timing synchronization function (TSF) (resume TSF) field, etc. The resumption time information may be used to indicate the resumption time point, such as indicating the lower portion of the TSF. Exemplarily, the above-mentioned buffer report may include at least one of the following: the size of the buffered data, the minimum remaining time of the buffered data, or the service priority of the buffered data. The description of the minimum remaining time and service priority can be found above and will not be detailed here.

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

[0209] In an embodiment of the present application, the TXOP holder can implicitly indicate the TXOP holder's processing result of the coexistence request sent by the TXOP responder by sending a buffer report to the TXOP responder. When the buffer report indicates that the TXOP responder has higher priority data to receive, it can implicitly indicate that the TXOP holder may not comply with the coexistence request, and the TXOP holder will still send data to the TXOP responder.

[0210] Method 2: The feedback result may include a More Data field. The MPDU format for this feedback result can be described in Figures 4a or 4b. The TXOP responder can determine whether it has more data to receive based on the More Data field. If the More Data field is set to 1, the TXOP responder can continue receiving data until the More Data field in the next received MPDU is set to 0. For a description of the More Data field, refer to the above.

[0211] 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 may implicitly indicate that the TXOP holder may not comply with the coexistence request.

[0212] In method three, the feedback result may include indication information indicating whether the TXOP holder has received the coexistence request or whether the TXOP holder has complied with the coexistence request. For example, this indication information may be carried in the A-Control field, BA, or radio frame. Through this indication information, the TXOP responder can be informed of the TXOP holder's decision on the coexistence request.

[0213] In mode 4, the feedback result may include indication information, which may be used to indicate that the scheduling of the TXOP responder within the current TXOP has ended, or that the TXOP responder has stopped transmitting and receiving signals within the current TXOP. Upon receiving this indication information, the TXOP responder may be informed of the scheduling status of the TXOP responder by the TXOP holder. For example, this indication information may be carried in the A-Control field, and the control identifier field of the A-Control field may be newly defined with a value. The newly defined value may be used to indicate that the A-Control field is used to instruct the AP not to schedule non-AP STAs within the current TXOP.

[0214] For example 2 in step 502 of Figure 5, since the TXOP holder may have the right to decide, it is possible 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 more 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.

[0215] The coexistence request shown above can be combined with other examples or methods shown above. The specific manner of combination will not be described in detail here.

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

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

[0218] Wi-Fi 8 also addresses device energy conservation. For example, stations can choose to operate in monitoring mode or power-saving mode to conserve energy. In these modes, stations can operate with a small bandwidth, a single stream, and a low MCS. If an AP obtains a TXOP and wishes to transmit data to a non-AP STA, the two communicating parties can exchange ICF / ICR frames. For example, a non-AP STA can include a coexistence request in an ICR frame to inform the AP of parameters such as the maximum bandwidth, maximum MCS, and maximum number of streams to be used for data transmission.

[0219] Figure 7 is a flow chart of a communication method provided by an embodiment of the present application. In Figure 7, the AP can be the TXOP holder, and non-AP STA1 and non-AP STA2 can be the TXOP responders. Figure 7 illustrates an example of an AP triggering uplink multi-user transmission. The AP obtains a TXOP through EDCA contention for a channel. Non-AP STA 1 or non-AP STA2 operates in coexistence mode or listening mode (or energy-saving mode), and first exchanges ICF and ICR frames at the beginning of the TXOP.

[0220] As shown in FIG7 , the AP sends an ICF, and after receiving the ICF, non-AP STA1 or non-AP STA2 may reply with an ICR frame.

[0221] 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 an explanation of the coexistence request, please refer to the description of FIG5 or FIG6b, etc., which will not be described in detail here.

[0222] 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 responder.

[0223] Taking Figure 7 as an example, non-AP STA 1 and non-AP STA 2 can each declare their own coexistence requests in the ICR frame. For example, non-AP STA 1 requests that the TXOP end at time T1, duration A, and the corresponding service priority be X. Non-AP STA 2 requests that the TXOP end at time T2, duration B, and the corresponding service priority be 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 it requests that the 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. Regarding 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.

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

[0225] 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.

[0226] 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. For example, the desired behavior of non-AP STA 1 or non-AP STA 2 may be to allow transmission or to restrict transmission. As shown in Figure 7, the AP may send a trigger frame, and non-AP STA 1 or non-AP STA 2 may receive the trigger frame.

[0227] Exemplarily, the trigger frame includes resource scheduling and other parameters (such as association identifiers, coding and modulation strategies, etc.) for one or more users (stations) to transmit uplink data. Figure 8a is a schematic diagram of the format of a trigger frame provided in an embodiment of the present application. The trigger frame may include a common information (commoninfo) field and a user information list (userinfolist) 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 (AID) field is indicated as 2007. The special user information field carries some common information after the association identification field. Although it is a user information field, it carries common 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 (AID12) (e.g., the lower 12 bits of the AID) indicates the association identifier of a particular STA, and is usually referred to as the association identification field. The RU allocation field, combined with the primary and secondary 160 fields, indicates the specific resource unit or multi-RU (MRU) position allocated to the user (the user corresponding to AID 12). For further information about the trigger frame, please refer to the relevant standards or protocols and will not be detailed here.

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

[0229] 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, a trigger-based PPDU (TB PPDU) is sent 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 (EHT TB PPDU) or an ultra high reliability trigger-based PPDU (UHR TB PPDU). The types of TB PPDUs mentioned here are only examples and should not be understood as limiting the embodiments of the present application.

[0230] Figure 8b is a schematic diagram of the format of an EHT TB PPDU provided in an embodiment of the present application. Figure 8c is a schematic diagram of the format of a 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).

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

[0232] Table 2

[0233] As shown in FIG7 , after receiving a TB PPDU sent by one or more non-AP STAs, the AP responds with a multi-STA block acknowledgement (multi-STA BA) frame.

[0234] Figure 8d is a format diagram of a multi-STA BA frame provided in an embodiment of the present application. As shown in Figure 8d, 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 tagged memory configuration (memoryconfigurationtag), a management acknowledgment (managementack) or a service identifier (TID info). For descriptions of each field, please refer to the relevant standards or protocols and 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.

[0235] In the embodiments of the present application, coexistence requests are carried in ICF / ICR frames, and coexistence request IDs and operation type information are used to flexibly manage coexistence requests. This also addresses the issue of how to fully utilize 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, an AP can schedule these non-AP STAs based on coexistence requests from different non-AP STAs, such as complying with the coexistence requests of these non-AP STAs or not complying with the coexistence requests of one or more non-AP STAs.

[0236] The following describes a communication device according to an embodiment of the present application.

[0237] The present application divides the functional modules of the communication device according to the above-mentioned 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-mentioned 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 this application is schematic and is only a logical functional 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 with reference to Figures 9 to 11.

[0238] Figure 9 is a schematic diagram of the structure of a communication device provided in an embodiment of the present application. As shown in Figure 9, 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 referred to as an interface, a communication interface, or a communication module.

[0239] In some embodiments of the present application, the communication device may be used to perform the actions performed by the first communication device in the above method embodiments. In this case, the first communication device may be the Wi-Fi device itself, or a chip or functional module configurable in the device. The transceiver module 902 is used to perform the transceiver-related operations of the first communication device in the above method embodiments, and the processing module 901 is used to perform the processing-related operations of the first communication device in the above method embodiments.

[0240] Illustratively, the processing module 901 may be configured to generate a coexistence request; and the transceiver module 902 may be configured to send or output the coexistence request.

[0241] Exemplarily, the transceiver module 902 may also be configured to receive or input a cache report; or receive or input indication information, and the like.

[0242] Illustratively, the transceiver module 902 may include a radio frequency module, an antenna module, etc. Illustratively, the transceiver module 902 may include a pin module, etc.

[0243] Referring to 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 embodiments. In this case, the communication device can be the Wi-Fi device itself, or a chip or functional module configurable in the device. The transceiver module 902 is used to perform the transceiver-related operations of the second communication device in the above method embodiments, and the processing module 901 is used to perform the processing-related operations of the second communication device in the above method embodiments.

[0244] Illustratively, the transceiver module 902 may be configured to receive or input a coexistence request; and the processing module 901 may be configured to parse the coexistence request.

[0245] Exemplarily, the transceiver module 902 may be configured to send or output a cache report; or send or output indication information.

[0246] For example, the transceiver module 902 may include a radio frequency module, an antenna module, etc. For example, the transceiver module 902 may include a pin module, etc. The transceiver module may include multiple radio frequency modules.

[0247] 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. The processing module 901 may read the instructions and / or data in the storage module to enable the communication device to implement the above method embodiments. Exemplarily, the storage module may be used to store a coexistence request, etc.

[0248] In the above embodiments, for the specific description of each term or step, please refer to the introduction in the above method embodiment, and will not be described in detail here.

[0249] 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, please refer to the above method embodiments and will not be described in detail here.

[0250] The above describes the communication device according to the embodiment of the present application. The following describes possible product forms of the communication device. Any product having the functions of the communication device described in FIG. 9 falls within the scope of protection of the embodiment of the present application. The following description is for illustrative purposes only and does not limit the product forms of the communication device according to the embodiment of the present application to these examples.

[0251] In one possible implementation, in the communication device shown in FIG9 , the processing module 901 may be one or more processors, and the transceiver module 902 may be a transceiver. Alternatively, the transceiver module 902 may be a transmitting module and a receiving module, where the transmitting module may be a transmitter and the receiving module may be a receiver, with the transmitting module and receiving module being integrated into a single device, such as a transceiver. In embodiments of the present application, the processor and transceiver may be coupled, and the connection method between the processor and transceiver is not limited in this embodiment. During the execution of the above-described method, the process of sending information in the above-described method may be the process of the processor outputting the above-described information. When outputting the above-described information, the processor outputs the above-described information to the transceiver for transmission by the transceiver. After being output by the processor, the above-described information may require further processing before reaching the transceiver. Similarly, the process of receiving information in the above-described method may be the process of the processor receiving the above-described information. When the processor receives the input information, the transceiver receives the above-described information and inputs it into the processor. Furthermore, after the transceiver receives the above-described information, the above-described information may require further processing before being input into the processor.

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

[0253] In some embodiments of the present application, a communication device may be configured to execute the steps, methods, or functions performed by the first communication device described above. For example, the processor 1020 may be configured to execute the functions or steps implemented by the processing module 901 shown in FIG9 , and the transceiver 1010 may be configured to execute the functions or steps implemented by the transceiver module 902 shown in FIG9 . For a detailed description of the processor 1020 and the transceiver 1010, reference may be made to FIG9 or the method embodiment shown above and will not be described in detail here.

[0254] In other embodiments of the present application, the communication device is used to execute the steps, methods, or functions performed by the second communication device described above. For example, 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 detailed descriptions of the processor 1020 and the transceiver 1010, please refer to Figure 9 or the method embodiment shown above and will not be described in detail here.

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

[0256] 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 communication devices, units or modules, which can be electrical, mechanical or other forms, and is used for information exchange between communication devices, units or modules. 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.

[0257] The specific connection medium between the transceiver 1010, processor 1020, and memory 1030 is not limited in the embodiments of the present application. In Figure 10, the memory 1030, processor 1020, and transceiver 1010 are connected via a bus 1040. The bus is represented by a bold line in Figure 10. The connection methods between other components are merely illustrative and are not intended to be limiting. The bus can be divided into an address bus, a data bus, a control bus, etc. For ease of illustration, Figure 10 only uses a single bold line, but this does not mean that there is only one bus or only one type of bus.

[0258] 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 various 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 methods disclosed in the embodiments of the present application may be directly implemented as being executed by a hardware processor, or may be executed by a combination of hardware and software modules in the processor, etc.

[0259] In the embodiment of the present application, 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. Memory is any storage medium that can be used to carry or store program code 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 thereto. The memory in the embodiment of the present application can also be a circuit or other arbitrarily capable of realizing a storage function, for storing program instructions and / or data.

[0260] The processor 1020 is primarily used to process communication protocols and communication data, control the entire communication device, execute software programs, and process software program data. The memory 1030 is primarily used to store software programs and data. The transceiver 1010 may include a control circuit and an antenna. The control circuit is primarily used to convert baseband signals into radio frequency signals and process radio frequency signals. The antenna is primarily used to transmit and receive radio frequency signals in the form of electromagnetic waves. Input / output devices, such as a touch screen, display, and keyboard, are primarily used to receive user input and output data to the user.

[0261] When the communication device is powered 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 radio frequency circuit. The radio frequency circuit performs radio frequency processing on the baseband signal and then transmits the radio frequency signal to the outside in the form of electromagnetic waves through the antenna. When data is sent to the communication device, the radio frequency circuit receives the radio frequency signal through the antenna, converts the radio frequency 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.

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

[0263] The communication device shown in the embodiment of the present application may also have more components than those in Figure 10, and the embodiment of the present application is not limited to this. The method performed by the processor and transceiver shown above is only an example. For the specific steps performed by the processor and transceiver, please refer to the method described above.

[0264] 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 may be called 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 using a logic circuit 1101, and the transceiver module 902 may be implemented using an interface 1102. 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. For example, FIG11 is illustrated using the communication device as a chip, and the chip includes a logic circuit 1101 and an interface 1102.

[0265] In the embodiment of the present application, the logic circuit and the interface may 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. For example, the logic circuit 1101 can be used to perform the functions or steps implemented by the processing module 901 shown in Figure 9, and the interface 1102 can be used to perform the functions or steps implemented by the transceiver module 902 shown in Figure 9. For a specific description of the logic circuit 1101 and the interface 1102, please refer to Figure 9 or the method embodiment shown above, and will not be described in detail here.

[0266] 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.

[0267] 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.

[0268] 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.

[0269] The present application also provides a computer-readable storage medium having computer code stored therein. When the computer code is run on a computer, the computer executes the operations and / or processing performed by each communication device in the method provided by the present application.

[0270] The present application also provides a computer program product, which includes computer code or computer program. When the computer code or computer program is run on a computer, the operations and / or processes performed by the method provided in the present application are executed.

[0271] In the several embodiments provided in this 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. In actual implementation, there may be other division methods, 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 can be electrical, mechanical or other forms of connection.

[0272] The modules described as separate components may or may not be physically separate, and the components shown as modules may or may not be physical modules, that is, they may be located in one place or distributed across 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.

[0273] In addition, the functional modules in the various embodiments of the present application may be integrated into a processing module, or each module may exist physically separately, or two or more modules may be integrated into a single module. The above-mentioned integrated modules may be implemented in the form of hardware or software functional modules.

[0274] If the integrated module is implemented in the form of a software functional 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 the part that contributes 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 a number of instructions for enabling a computer device (which can be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the method described in each embodiment of the present application. The aforementioned readable storage medium includes: various media that can store program codes, such as a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk.

[0275] The above description is merely a specific embodiment of the present application, but the scope of protection of the present application is not limited thereto. Any changes or substitutions that can be easily conceived by a person skilled in the art within the technical scope disclosed in this application should be included in the scope of protection of this application. Therefore, the scope of protection of this application should be based on the scope of protection of the claims.

Claims

1. A communication method, characterized in that, The method includes: A first communication device generates a coexistence request, where the coexistence request includes an identifier of the coexistence request and operation type information, and the operation type information is used to indicate the operation type of the coexistence request; The first communication device sends the coexistence request.

2. A communication method, characterized in that, The method includes: A second communication device receives a coexistence request, where the coexistence request includes an identifier of the coexistence request and operation type information, and the operation type information is used to indicate the operation type of the coexistence request; The second communication device parses the coexistence request.

3. The method according to claim 1 or 2, characterized in that, 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 for modifying parameters; or A temporarily suspended coexistence request.

4. The method according to any one of claims 1 to 3, characterized in that, The coexistence request further includes expected behavior information, and the expected behavior information is used to indicate the expected behavior corresponding to a station STA in the first communication device.

5. The method according to claim 4, wherein The expected behavior includes any one of the following: Allowing signal transmission; Restricted signal reception; Allowing signal reception; Restricted signal transmission; or Not allowing signal transmission nor signal reception.

6. The method according to claim 4 or 5, characterized in that, The coexistence request further includes time information, and the time information is used to indicate the time period corresponding to the expected behavior.

7. The method according to claim 5 or 6, characterized in that, The coexistence request further includes reception parameters when the first communication device restricts signal reception, or transmission parameters when the first communication device restricts signal transmission.

8. The method according to any one of claims 1-7, characterized in that, The coexistence request further includes radio frequency type information, and the radio frequency type information is used to indicate the radio frequency type corresponding to the coexistence request.

9. The method according to any one of claims 1-8, characterized in that, The coexistence request further 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.

10. The method according to any one of claims 1-9, characterized in that, The coexistence request further includes an interference report, and the interference report is used to indicate interference parameters of the radio frequency type corresponding to the coexistence request. The interference parameters include at least one of the following: link identifier, interference level, channel affected by interference, whether the interference is periodic, whether the interference is symmetric, interference start time, interference duration.

11. The method according to any one of claims 1-10, characterized in that, The coexistence request further includes listening mode enabling information, and the listening mode enabling information is used to indicate that the first communication device enables or exits the listening mode.

12. The method according to any one of claims 1 to 10, 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 further includes listening mode enabling information, and the listening mode enabling information is used to indicate that the first communication device enables or exits the listening mode.

13. The method according to claim 11 or 12, characterized in that, When the listening mode enabling information is a first value, it indicates that the first communication device exits the listening mode, and the mode to be switched by the first communication device is determined based on power management information; or, When the listening mode enabling information is a second value, it indicates that the first communication device enables the listening mode, and the state of the first communication device is determined based on at least one of power management information or more data information.

14. The method according to claim 1, characterized in that, The method further includes: The first communication device receives a feedback result regarding the coexistence request.

15. The method according to claim 2, wherein The method further includes: The second communication device sends a feedback result regarding the coexistence request.

16. 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 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 within the current transmission opportunity TXOP has ended.

17. A communication device, characterized in that, comprising a module for performing the method according to any one of claims 1-16.

18. A communication device, characterized in that, comprising a processor, and the processor is used to perform the method according to any one of claims 1-16.

19. A communication device, characterized in that, comprising 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 perform the method according to any one of claims 1-16.

20. 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-16 is executed.

21. A computer program product, characterized in that, when the computer program product is executed, the method according to any one of claims 1-16 is executed.

22. 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 perform the method according to any one of claims 1, 3-14, 16, and the second communication device is used to perform the method according to any one of claims 2-13, 15, 16.

Images