Unavailable state reporting method, access point and storage medium

Abstract

The embodiment of the invention relates to the technical field of wireless communication, and discloses an unavailable state reporting method, an access point and a storage medium. In the invention, in a multi-access-point cooperation protocol negotiation stage, unavailable state information is reported to a second access point in a multi-access-point cooperation group through a negotiation frame or a report frame; the second access point will respond to the unavailable state information. Coordinating members in the multi-access point collaboration group to dynamically perform at least one of the following operations: adjusting join qualifications of the members of the multi-access point collaboration group, reallocating collaboration resources to avoid a first access point being scheduled while in an unavailable state, updating or terminating a current multi-access point collaboration protocol, therefore, each device under the cooperation of multiple APs can efficiently and reliably integrate and process unavailable report information from the access points and associated terminals thereof, and the cooperation task is dynamically reconstructed according to the unavailable report information, so that fault isolation is realized.

Description

Technical Field

[0001] This invention relates to the field of wireless communication technology, and in particular to an unavailability reporting method, access point, and storage medium. Background Technology

[0002] Wi-Fi 8 (standard number IEEE 802.11bn), as the next-generation wireless LAN technology, has shifted its core objective from simply pursuing peak data rates to building ultra-high reliability (UHR) networks. Building upon the high bandwidth and high-order modulation capabilities of Wi-Fi 7, Wi-Fi 8's key innovation lies in its systematic solution to long-standing user experience pain points such as high-density deployment, multi-device interference, and cross-technology resource competition through Multi-AP Coordination (MAPC) and In-device Co-existence mechanisms. This paves the way for demanding scenarios such as immersive XR, industrial IoT, and real-time control.

[0003] Multi-AP Coordination (MAPC) is arguably the revolutionary core of Wi-Fi 8. It completely transforms the traditional network landscape where multiple access points (APs) operate independently, driving the entire network towards global resource coordination and intelligent scheduling. It defines five multi-AP coordination strategies:

[0004] 1. Coordinated Time Division Multiple Access (Co-TDMA) allows an AP that has a Transmission Opportunity (TXOP) to share a portion of its TXOP with other APs that do not conflict with it in the time dimension. This strictly plans its data transmission window, fundamentally avoiding signal collisions between APs and significantly reducing transmission latency and packet loss rate.

[0005] 2. Coordinated Beamforming (Co-BF) enables multiple APs to collaboratively calculate the optimal beam direction, accurately serving the target terminal while actively forming a "signal null point" in the direction of interference, effectively suppressing co-channel interference between APs and users, and improving spatial multiplexing efficiency.

[0006] 3. The Coordinated Spatial Reuse (Co-SR) mechanism allows adjacent APs to dynamically negotiate transmit power levels to reduce interference between APs. Before an AP begins controlling its transmit power, there is a coordination phase that allows the AP to obtain information from other APs on the same channel. This information includes path loss and signal-to-noise ratio (SNR), and helps the sharing AP calculate the transmit power of all APs to maximize throughput.

[0007] 4. Coordinated Restricted Target Wake-up Time (Co-RTWT) extends the R-TWT (used to ensure low-latency mission-critical services) in Wi-Fi 7 to multi-AP scenarios. It allows multiple APs to work together to reserve and synchronize a dedicated low-latency transmission window for a specific R-TWT service period, ensuring that mission-critical services can obtain deterministic low-latency guarantees under the cooperation of multiple APs.

[0008] 5. Coordinated Channel Recommendation (Co-CR) allows access points to coordinate and advertise channel selection with other access points (APs) that do not belong to the same Extended Service Set (ESS). This coordination helps ensure that APs operating in different / same ESSes in the same area do not interfere with each other. Through coordination, APs can recommend and agree on channels that minimize interference, thereby improving overall network performance and availability.

[0009] These five strategies work together to make the entire network a logically unified whole. Users can move between different APs without noticing the handover, resulting in a qualitative leap in network capacity and reliability. This is especially suitable for complex environments such as large residential buildings, corporate parks, shopping malls, and sports stadiums.

[0010] Regarding in-device co-existence, Wi-Fi 8 primarily addresses resource conflicts when multiple wireless technologies (such as Wi-Fi, Bluetooth, Wi-Fi Boost, UWB, and cellular modules) operate simultaneously within a single device. Its core mechanism is the reporting of Unavailability Reports. When non-Wi-Fi technologies within a device (such as Bluetooth audio transmission or cellular positioning) require shared radio frequency resources (such as the 2.4GHz band or antenna), causing temporary Wi-Fi malfunction, the device proactively reports the specific time period during which its Wi-Fi function will be "unavailable" to its connected access point (AP) via a dedicated signal frame. This report clearly informs the AP that the device cannot receive or transmit Wi-Fi data during the specific time period. Upon receiving this report, the AP can decide how to respond based on the actual situation and its own capabilities, ensuring that no scheduling is performed on the corresponding STA during the "unavailable" period. This dynamic resource coordination mechanism based on explicit notifications greatly alleviates the "internal conflict" between different wireless technologies within devices, significantly improves the connection stability and efficiency of Wi-Fi on complex multi-mode devices (such as smartphones, tablets, and converged IoT gateways), and especially ensures a smooth experience in scenarios where Wi-Fi is used concurrently, such as Bluetooth headset calls and smart home device control.

[0011] The inventors have discovered at least the following problems in the related technology:

[0012] In the current design discussions of the Wi-Fi 8 protocol, an "Unavailability Report" mechanism has been planned for terminal devices (Stations, or STAs) and access points to address the issue of multiple technologies coexisting. This allows terminals to proactively report to their associated access points periods when Wi-Fi functionality is limited due to resource consumption by internal non-Wi-Fi technologies such as Bluetooth, UWB, or cellular, helping to optimize network scheduling.

[0013] However, the complexity of the problem increases significantly in multi-AP coordination scenarios. As the core of network coordination, the AP device not only faces conflicts arising from the coexistence of multiple technologies, but also enters a periodic unavailability state when power-saving mode is activated. This causes the AP to be unable to provide services to associated terminals during specific time periods, or even to fulfill its responsibilities within the multi-AP coordination group.

[0014] When multi-AP collaboration is enabled, the unavailability of a single AP or the unavailability periods reported by its associated terminals can severely impact the tightly coupled multi-AP collaboration mechanism. For example, the "absence" of an AP or the "loss of connection" of a critical terminal may disrupt the synchronization of collaborative transmission, interfere with the calculation of coordinated beamforming, and waste reserved low-time slot resources, ultimately preventing the core advantages of multi-AP collaboration, such as improved network capacity, reliability, and seamless roaming, from being effectively realized. Summary of the Invention

[0015] The purpose of this invention is to provide an unavailability reporting method, access point, and storage medium, so that each device in a multi-AP collaboration can efficiently and reliably integrate and process "unavailability report" information from the AP itself and its associated terminals, and dynamically reconstruct collaborative tasks and achieve fault isolation accordingly.

[0016] To address the aforementioned technical problems, embodiments of the present invention provide an unavailability reporting method, applied to a first access point, comprising:

[0017] During the multi-access point cooperation protocol negotiation phase, unavailability status information is reported to the second access point in the multi-access point cooperation group through negotiation frames or reporting frames.

[0018] In response to the unavailability status information, the second access point will coordinate the members in the multi-access point collaboration group to dynamically perform at least one of the following operations: adjust the membership of the members in the multi-access point collaboration group, reallocate collaboration resources to prevent the first access point from being scheduled while in an unavailable state, update or terminate the current multi-access point collaboration protocol.

[0019] The unavailability status information includes at least one of the following: periodic unavailability period information generated by the first access point, non-periodic unavailability period information of the first access point, and unavailability period information reported by the associated terminal of the first access point.

[0020] Embodiments of the present invention also provide an access point, comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to perform the above-described unavailability reporting method.

[0021] Embodiments of the present invention also provide a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the above-described unavailability reporting method.

[0022] In this embodiment of the invention, during the multi-access point cooperation protocol negotiation phase, unavailability status information is reported to the second access point in the multi-access point cooperation group via negotiation frames or reporting frames. In response to the unavailability status information, the second access point coordinates the members in the multi-access point cooperation group to dynamically perform at least one of the following operations: adjusting the membership qualifications of the members in the multi-access point cooperation group, reallocating cooperation resources to prevent the first access point from being scheduled when it is in an unavailable state, updating or terminating the current multi-access point cooperation protocol, thereby enabling each device under multi-AP cooperation to efficiently and reliably integrate and process the "unavailability report" information from the AP itself and its associated terminals, and dynamically reconstruct the cooperation task and achieve fault isolation accordingly. Attached Figure Description

[0023] One or more embodiments are illustrated by way of example with reference numerals in the accompanying drawings. These illustrations do not constitute a limitation on the embodiments. Elements with the same reference numerals in the drawings are denoted as similar elements. Unless otherwise stated, the figures in the drawings are not to be limited by scale.

[0024] Figure 1 This is a flowchart of an unavailability reporting method according to an embodiment of the present invention;

[0025] Figure 2 This is a schematic diagram of a multi-access point collaboration element format provided according to an embodiment of the present invention;

[0026] Figure 3 This is a schematic diagram of a periodic unavailability information report format provided according to an embodiment of the present invention;

[0027] Figure 4 This is a schematic diagram of a non-periodic unavailability information report format provided according to an embodiment of the present invention;

[0028] Figure 5 This is a schematic diagram of a multi-connection device periodic unavailability information report format according to an embodiment of the present invention;

[0029] Figure 6 This is a schematic diagram of a multi-connection device non-periodic unavailability information report format according to an embodiment of the present invention;

[0030] Figure 7 This is a schematic diagram of the access point structure according to another embodiment of the present invention. Detailed Implementation

[0031] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the various embodiments of the present invention will be described in detail below with reference to the accompanying drawings. However, those skilled in the art will understand that many technical details are presented in the various embodiments of the present invention to facilitate a better understanding of this application. However, the technical solutions claimed in this application can be implemented even without these technical details and various changes and modifications based on the following embodiments. The division of the various embodiments below is for ease of description and should not constitute any limitation on the specific implementation of the present invention. The various embodiments can be combined with and referenced by each other without contradiction.

[0032] One embodiment of the present invention relates to an unavailability reporting method, which can be applied to a first access point, which can be a single access point device or a multi-connection access point device. In this embodiment, during the multi-access point cooperation protocol negotiation phase, unavailability information is reported to a second access point in the multi-access point cooperation group via a negotiation frame or a reporting frame. In response to the unavailability information, the second access point coordinates the members in the multi-access point cooperation group to dynamically perform at least one of the following operations: adjusting the membership qualifications of the members in the multi-access point cooperation group, reallocating cooperation resources to prevent the first access point from being scheduled while in an unavailable state, updating or terminating the current multi-access point cooperation protocol. This enables each device in multi-AP cooperation to efficiently and reliably integrate and process "unavailability report" information from the AP itself and its associated terminals, and dynamically reconstruct cooperation tasks and achieve fault isolation accordingly. The implementation details of the unavailability reporting method of this embodiment are described below. The following content is only for ease of understanding and is not essential for implementing this solution.

[0033] like Figure 1 As shown, in step 101, during the multi-access point cooperation protocol negotiation phase, the first access point reports unavailability status information to the second access point in the multi-access point cooperation group through negotiation frames or reporting frames; wherein, the unavailability status information includes at least one of the following: periodic unavailability period information generated by the first access point, non-periodic unavailability period information of the first access point, and unavailability period information reported by the associated terminal of the first access point.

[0034] In step 102, the second access point will respond to the unavailability status information by coordinating the members in the multi-access point collaboration group to dynamically perform at least one of the following operations: adjust the membership of the members in the multi-access point collaboration group, reallocate collaboration resources to prevent the first access point from being scheduled while it is in an unavailable state, update or terminate the current multi-access point collaboration protocol.

[0035] To better understand the reporting method for unavailability period information, the following section first describes how to enable the unavailability reporting function before the multi-access point cooperation protocol negotiation phase. Specifically, before the multi-access point cooperation protocol negotiation phase, the first access point reports a frame carrying unavailability enabling parameters to the second access point. These enabling parameters indicate whether the first access point can enable the unavailability reporting function. Factors influencing whether the first access point can enable the unavailability reporting function include the currently executing multi-access point cooperation strategy.

[0036] First, considering the differences in capabilities among different access points (APs) and the fact that APs can dynamically adjust their capabilities in different scenarios, a control needs to be added to MAPC to enable or disable unavailability reporting. This parameter is referred to as MAPCUnavailabilityReportSupported in this invention; more specifically, when MAPCUnavailabilityReportSupported = 1, it indicates that unavailability reporting is allowed in multi-AP collaboration; when it is 0, it indicates that it is not supported.

[0037] Based on existing protocol advancements, the MAPCUnavailabilityReportSupported parameter can be added to the MAPC element. The components of this format are as follows: Figure 2 As shown (Note: Figure 2 The examples shown are for illustrative purposes only; the order of the fields is not strictly defined in this scheme. Figure 2 The MAPC element format shown includes parameters such as element name (Element ID), length, element ID extension, MAPC control, common information (Common Info), and MAPC scheme information (MAPCSchemes Info). Among them, MAPCUnavailabilityReportSupported can be placed in the MAPCControl field or the Common Info field, and is used to indicate whether the AP supports the unavailability reporting function in MAPC collaboration.

[0038] Furthermore, during the MAPC Discovery phase, each AP can, based on its own circumstances, include a MAPC element when sending the MAPC Discovery Request frame or MAPC Discovery Response frame, and include the MAPCUnavailabilityReportSupported parameter in that element.

[0039] In the subsequent MAPC Agreement Negotiation phase, the MAPC requesting AP should, based on the information obtained in the MAPC Discovery phase, decide whether to enable the unavailability reporting function and set the MAPCUnavailabilityReportSupported parameter value. Note: If any of the APs among those to whom the MAPC requesting AP wants to reach a MAPC agreement reported not supporting this function during the MAPC Discovery phase, the MAPC requesting AP should not set MAPCUnavailabilityReportSupported to 1 during the negotiation phase; the MAPC requesting AP may only enable this function in this phase if all participating APs support unavailability reporting. MAPCUnavailabilityReportSupported should be included in the MAPC element and sent to the MAPC responding AP via the MAPC negotiation request frame. The MAPC responding AP should also confirm this decision in its reply MAPC negotiation response frame.

[0040] Furthermore, in certain application scenarios, the functionality of MAPCUnavailabilityReportSupported can be further refined to distinguish between periodic unavailability reports and aperiodic (dynamic) unavailability reports. Specifically, two independent parameters can be defined, such as MAPCDynamicUnavailabilityReport and MAPCPeriodicUnavailabilityReport, to indicate whether aperiodic and periodic unavailability reports are supported, respectively. The usage of these two parameters and their position in the MAPC element are the same as those in MAPCUnavailabilityReportSupported, and will not be repeated here.

[0041] As mentioned above, the factors affecting whether the first access point can enable the unavailability reporting function include the currently executed multi-access point collaboration strategy. The relationship between the MAPC strategy and the unavailability reporting function is as follows:

[0042] Because different MAPC policies have varying degrees of sensitivity to the unavailability of an AP or its associated STA, or in other words, the impact of an AP or its associated STA's unavailability differs across MAPC policies, it's possible to pre-define that certain MAPC policies do not support unavailability reporting in some cases. When APs attempt to establish an agreement regarding this MAPC policy, APs experiencing unavailability periods will be denied access. For example, Co-SR and / or Co-RTWT and / or Co-CR policies do not support reporting unavailability time intervals between APs.

[0043] In some cases, the initiating AP can also make the decision. During the MAPC agreement negotiation phase, the MAPC requesting AP ultimately decides which MAPC policies support (or do not support) unavailable reporting and includes the relevant information in the MAPC negotiation request frame. The MAPC responding AP can also decide whether to accept the request by sending a MAPC negotiation response frame.

[0044] In some cases, the decision can also be made through negotiation between APs. During the MAPC discovery phase, the AP announces which or more of its MAPC policies support (or do not support) reporting unavailability. During the MAPCagreement negotiation phase, the AP that requests the MAPC policy ultimately decides which or more of its MAPC policies support (or do not support) reporting unavailability and includes this information in the MAPC negotiation request frame. The AP that responds to the MAPC policy can also decide whether to accept the proposal by sending a MAPC negotiation response frame.

[0045] Since factors affecting whether the first access point can enable the unavailability reporting function include the currently executed multi-access point cooperation strategy, in one example, adjusting the eligibility of members joining the multi-access point cooperation group in step 102 could be: when executing the C-TDMA cooperation strategy, denying access points with unavailability periods and reserved time slot conflicts from joining the multi-access point cooperation group; when executing the C-BF cooperation strategy, allowing access points with unavailability during the detection period to join the multi-access point cooperation group, but delaying the detection process of access points with unavailability during the detection period, etc.

[0046] Specifically, information regarding whether the MAPC policy supports unavailable reporting functionality can be indicated, similar to enabling parameters, by including this information in the MAPC element, for example as follows:

[0047] For example, it can be placed in the form of a Bitmap in the MAPC Control field or the Common Info field. Each bit represents a MAPC policy. When the corresponding bit is set to 0, it means that the policy does not support the unavailability reporting function. When the corresponding bit is set to 1, it means that the policy supports the unavailability reporting function.

[0048] Alternatively, this information can be placed in the MAPC schemes info field, with an additional 1 bit added for each MAPC scheme to indicate whether the MAPC scheme supports the unavailable reporting function. For example, this bit can be added to the MAPC scheme Control field of the MAPC schemes info, or to the MAPC SchemeParameter Set field of the MAPC schemes info.

[0049] In some cases, if an AP only becomes aware of its own or its associated STA's unavailability report after the MAPC Agreement Negotiation phase, it can update or terminate the MAPC collaboration through the MAPC Agreement update or MAPC Agreement teardown steps. The MAPC Agreement update is a step to update the MAPC agreement reached between APs, while the MAPC Agreement teardown is a step to terminate the MAPC agreement; it can be initiated by any AP after an agreement has been reached among multiple APs.

[0050] Since either AP can initiate an update or termination of the current MAPC Agreement after the two APs have successfully reached a MAPC agreement negotiation, in one example, the update or termination of the current multi-access point cooperation agreement in step 102 can be: when the multi-access point cooperation agreement negotiation phase ends, and the second access point detects the periodic unavailability period information generated by the first access point, the second access point updates or terminates the current multi-access point cooperation agreement through the multi-access point cooperation agreement update process.

[0051] Next, we will explain the unavailability reporting method of the first access point in step 101. There are two situations in which the first access point enters the unavailability state: one is that the first access point enters the unavailability state periodically, in which case the first access point reports a periodic unavailability report; the other is that the first access point enters the unavailability state non-periodically, in which case the first access point reports a non-periodic unavailability report.

[0052] Let's first illustrate this with an example of periodic unavailability reporting. Firstly, devices (including APs and non-AP STAs) can anticipate periodic unavailability. If an AP is aware of its own or its associated non-AP STA's periodic unavailability before multi-AP collaboration is established, it should report this unavailability period during the MAPC agreement negotiation phase. That is, the negotiation frame in step 101 can be either a MAPC negotiation request frame or a MAPC negotiation response frame as described in the above embodiments.

[0053] If the periodic unavailability of an AP or its associated non-AP STA occurs only after the MAPC agreement is reached, it needs to be reported during the multi-AP collaboration phase according to different multi-AP collaboration strategies. Alternatively, in some cases, a non-periodic unavailability reporting scheme can also be used. The non-periodic unavailability reporting scheme will be described in detail below and will not be repeated here. In addition, when an AP enables the periodic unavailability reporting function, its associated STA is assumed to support this function. How the AP and STA interact is not specifically limited in this invention.

[0054] In multi-AP collaboration, how do APs exchange information about unavailable resources? This invention provides two examples of solutions:

[0055] Option 1: Include unavailability query / report information in the MAPC negotiation request / response frame.

[0056] This solution can be combined with the relevant schemes for enabling parameters in the above embodiments. When the MAPC request AP sends a MAPC negotiation request frame, the frame carries an enabling parameter for MAPCUnavailabilityReportSupported or periodic unavailability reporting, and this parameter is set to 1 (i.e., the unavailability reporting function is enabled). At this time, this parameter can also indicate that the MAPC response AP can report if there are periodic unavailability periods. When the MAPC response AP sends a MAPC negotiation response frame, it can also carry unavailability information to report to the MAPC request AP, so that the latter can coordinate APs with unavailability periods in subsequent MAPC cooperation schemes.

[0057] Specifically, the periodic unavailability reporting of AP in response to MAPC can be included in the MAPC element. The enabling parameter for MAPCUnavailabilityReportSupported or periodic unavailability reporting from the above embodiments can be reused and included in the MAPC negotiation response frame. When this parameter is set to 1, it indicates that there are periodic unavailability periods that need to be reported, which means that there are related fields for unavailability reporting periods. Alternatively, in some cases, to avoid confusion, a new parameter can be set, which is called MAPCUnavailabilityReport in this invention. This parameter indicates that there are periodic unavailability periods that need to be reported. The configuration method of this parameter is the same as MAPCUnavailabilityReportSupported, and will not be repeated here.

[0058] In one example, the periodic unavailability period information includes the start time and duration of the unavailability period for the first access point, as well as the periodic interval. More specifically, regarding specific unavailability periods, the unavailability report fields can be included in the MAPCelement, such as... Figure 3 As shown, the format of a periodic unavailability report includes the following parameters: Unavailability Target Start Time, Unavailability Duration, and Period Interval. Optionally, if the AP knows the current cycle of periodic unavailability (i.e., the number of cycles), the Repetition Count parameter can also be included. Here, Unavailability Target Start Time indicates the start time of the unavailability period; Unavailability Duration indicates the duration of the unavailability period; Period Interval indicates the interval between cycles; and Repetition Count indicates the number of cycles. In some cases, the UnavailabilityReport field can be placed in the MAPC Control field or the Common Info field.

[0059] In addition, if the AP request has an unavailable period, the relevant fields of the unavailable reporting period can be included in the MAPC negotiation request frame to notify the AP responding to MAPC. The configuration method is the same as that of the AP responding to MAPC, and will not be described in detail here.

[0060] Option 2: After reaching an agreement through MAPC, send a separate unavailability query / report frame.

[0061] Another approach is that after MAPC negotiation reaches an agreement, the initiating AP sends a separate frame to inquire whether other cooperating APs have any unavailability time intervals that need to be reported. The specific frame format can reuse the inquiry mechanism between the AP and non-APSTA terminals. For example, the initiating AP sends an Initial Control Frame (ICF) to the responding AP, inquiring whether it has any periodic unavailability that needs to be reported. If so, the responding AP sends an Initial Control Response (ICR) frame carrying unavailability information back to the initiating AP. The ICF frame can be a BSRP frame, and the ICR frame can be a Multi-STA BA frame with the feedback type set to Unavailability feedback. The indication of periodic unavailability information can reuse the approach described in Scheme 1 above. Figure 3 The proposed solution will not be elaborated upon here.

[0062] In some cases, interaction frames from corresponding multi-AP cooperation strategies can be reused to carry queries / reports of unavailability. For example, in a Co-TDMA strategy, the ICF frame used to query other APs whether they want to join Co-TDMA can be reused to carry a request for unavailability, and the unavailability information of the AP can be carried in the corresponding Co-TDMA feedback frame (ICR frame). This reduces signaling overhead and time delay caused by signaling interaction steps, and the initiating AP can also more rationally and scientifically arrange how to share TXOPs with other APs based on the AP's unavailability information. Specifically:

[0063] ICF frames: An additional 1-bit field can be added to indicate whether there is an unavailability period that needs to be reported; if Co-TDMA is allowed to enable unavailability reporting during the MAPCagreement negotiation phase, this bit can be omitted. ICF frames can be BSRP frames. In some cases, a new value can be set for the Feedback Type field in the Feedback UserInfo field of the BSRP frame to indicate a query for Co-TDMA and unavailability information, as shown in Table 1 below.

[0064]

[0065] ICR Frame: APs being questioned about joining Co-TDMA can also include unavailability reporting information in their feedback ICR frames. ICR frames can be Multi-Site Block Acknowledgment (Multi-STA BA) frames. The FeedbackType in the ICR frame should be a newly established value indicating whether the feedback includes information on joining Co-TDMA and unavailability information, as shown in Table 1 below. Additionally, the Feedback field should also include information on the time period that Co-TDMA requires to occupy TXOPs and Unavailability information. These two types of Feedback information can be arranged sequentially; for example, the first X bits represent Co-TDMA related information, and the last Y bits represent unavailability information. The indication of periodic unavailability information can reuse information from Scheme 1. Figure 3 The proposed solution will not be elaborated upon here.

[0066] In some cases, other MAPC strategies can also reuse the Co-TDMA approach to add the function of unavailability reporting, which will not be elaborated here.

[0067] Furthermore, if the periodic unavailability report does not include the Repetition Count field (i.e., the number of cycles), the relevant APs must be notified promptly after the unavailability cycle ends to facilitate subsequent collaboration. A specific example is as follows:

[0068] For example, the AP can initiate a MAPC agreement update step to update unavailable information, such as reporting unavailable information. Figure 2 Setting all bits to 0 in the middle information indicates the end of the periodic unavailability.

[0069] In addition, the AP can also send specific frames (such as action frames, other management frames, or control frames) to indicate the end of periodic unavailability.

[0070] In addition, the AP can also resend the unavailable reporting frame, except for the unavailable reporting information ( Figure 3 All bits are set to 0, and the rest of the information is the same.

[0071] The above examples illustrate periodic unavailability reporting. The following examples illustrate the non-periodic case. Since the mechanism for non-periodic unavailability reporting is the same as that for periodic unavailability reporting, when the AP supports non-periodic unavailability reporting, if non-periodic unavailability exists during the MAPC agreement negotiation phase, the reporting method refers to Scheme 1 in the above periodic reporting examples, only the format of the unavailability reporting information is updated. For example, the updated format could be as follows: Figure 4The format shown is as follows. If non-periodic unavailability occurs after the MAPC agreement is reached, the reporting method refers to Scheme 2 in the above-described periodic reporting embodiment, and the format of the unavailability reporting information has been updated. The non-periodic unavailability period information includes: the start time and duration of the unavailability period of the first access point, which can be as follows: Figure 4 The format shown. Figure 4 The Aperiodic Unavailability Report format shown only requires the Unavailability Target Start Time and Unavailability Duration to be included in the aperiodic unavailability report information. In one example, after the multi-access point cooperation protocol negotiation phase ends, whenever aperiodic unavailability period information generated by the first access point is detected, the aperiodic unavailability period information of the first access point is reported in real time via a reporting frame.

[0072] The above embodiments illustrate that the first access point has periodic and aperiodic unavailability periods. The periodic unavailability periods are usually predictable. In one example, the reallocation of collaborative resources in step 102 to avoid scheduling the first access point when it is unavailable can be: based on the periodic unavailability period information generated by the first access point, resource allocation can be performed in advance to avoid the unavailability period of the first access point; or, based on the aperiodic unavailability period information generated by the first access point, resource reallocation can be triggered in real time and all members in the collaborative group can be notified.

[0073] In the Co-BF strategy, the AP needs to perform channel measurements with the OBSS STA to obtain CSI (Channel State Information) from the OBSS STA. This information is used to adjust the beam, enabling both APs and their associated STAs to transmit simultaneously while minimizing interference with the OBSS STA. If the OBSS STA is unavailable during certain periods, ensuring the normal operation of Co-BF becomes a problem that needs to be addressed. Currently, there are two channel measurement mechanisms for Co-BF: one is sequential channel sounding, where the AP within the current BSS (e.g., AP1) and its associated STA (e.g., STA1) complete the measurement, and then the OBSS AP (e.g., AP2) performs the measurement with STA1; the other is joint channel sounding, where AP1 and AP2 simultaneously initiate channel measurements with STA1. If STA1 experiences periodic or aperiodic unavailability during this time, it will affect the Co-BF measurement process.

[0074] To address the above problems, the present invention provides the following solutions:

[0075] 1. If it is known to be unavailable before the measurement, that is, if STA1 has reported its unavailable period before the measurement, its associated AP1 should remove it and prohibit it from participating in the Co-BF measurement.

[0076] 2. If STA1 is found to be unavailable during the measurement initiation phase, i.e., if AP1 learns of STA1's unavailability during the measurement initiation phase, it can modify the measurement STA according to the actual situation and notify AP2 to replace it with a STA without unavailability periods via a specific indication frame, a Co-BF sounding invite frame, or an Ultra High Reliability (UHR) Null Data PPDU (NDP) announcement frame. In some cases, AP1 can also notify AP2 to postpone the measurement via a specific indication frame, specifying the postponement time in the frame to avoid STA1's unavailability period. That is, in step 102, the eligibility for joining the multi-access point cooperation group is adjusted so that when the C-BF cooperation policy is implemented, access points with unavailability during the sounding period are allowed to join the multi-access point cooperation group, but the sounding process of access points with unavailability during the sounding period is postponed.

[0077] 3. If the measurement is found to be unavailable during the measurement process, that is, if AP1 only learns during the measurement that STA1 has an unavailable period and cannot be replaced, and this period will affect the current measurement, then AP1 is allowed to send a specific indication frame to terminate the measurement to save signaling overhead. AP2 and STA1 stop the measurement after receiving this frame, and the process will restart when AP1 sends a Co-BF Sounding invite frame or a UHR NDPAnnouncement frame again.

[0078] Furthermore, current discussions on unavailability reporting often focus on the time domain. If unavailability reporting could be further refined to the frequency domain, it would optimize the user experience of WiFi functionality and minimize the impact of multiple technologies coexisting on WiFi performance. Based on this consideration, this paper also proposes a frequency domain unavailability reporting function, that is, adding the reporting of the frequency range corresponding to the unavailability period to the time domain reporting. Specific details are as follows:

[0079] Current discussions on unavailability reporting primarily focus on the time domain. If reporting could be refined to the frequency domain, it would further enhance the user experience of WiFi functionality and reduce the impact of multiple technologies coexisting. Therefore, this proposal suggests a frequency domain unavailability reporting function, which, in addition to time domain reporting, adds reporting of the frequency domain range corresponding to the unavailability period.

[0080] In one example, the unavailability status information also includes: an unavailability frequency duration field, and / or an unavailability frequency granularity field. Specifically, in some cases, frequency-domain related fields, such as an unavailability frequency duration field, can be added to both the periodic unavailability report format and the aperiodic unavailability report format. Figure 5 , 6 The Unavailability Frequency Duration is used to represent the range of frequency domain unavailability. The specific units used to indicate this frequency range are shown in Table 2 below, using the Unavailability Frequency Granularity field. An example scheme is provided below:

[0081] In some cases, frequency-domain related fields can be added to the periodic / aperiodic Unavailability Report format (e.g., Figure 4 , 5 As shown, Figure 4 The example is a periodically unavailable report format. Figure 5 (This is a non-periodic unavailability report format). Unavailability Frequency Duration indicates the range of frequency domain unavailability. The specific frequency domain range unit is represented by the Unavailability Frequency Granularity field (as shown in Table 2), with an example scheme as follows:

[0082] Regarding solutions that are unavailable across the entire frequency band, the following are some examples:

[0083] First, set the Unavailability Frequency Granularity to 0, indicating that the entire frequency domain bandwidth is unavailable. That is, reporting the unavailability status information to the second access point in the multi-access point cooperation group in step 101 can be done as follows: when the unavailability status information is effective for the entire frequency band of the first access point, by setting the unavailability frequency granularity field in the unavailability status information to zero, the unavailability status information is reported to the second access point to be effective for the entire frequency band of the first access point.

[0084] Second, to save signaling overhead, an Unavailability FrequencyPresent field can be added to indicate whether the unavailability range of the frequency domain needs to be indicated: setting it to 0 indicates that the unavailability period occupies the entire bandwidth, in which case the Unavailability Frequency Granularity and Unavailability FrequencyDuration fields do not need to be included. That is, reporting unavailability status information to the second access point in the multi-access point cooperation group in step 101 can be: when the unavailability status information is effective for the entire frequency band of the first access point, by setting the unavailability frequency field in the unavailability status information to zero, the unavailability status information reported to the second access point is effective for the entire frequency band of the first access point by default, and there is no need to report the effective frequency domain range;

[0085] Regarding the link-based scheme, the details are as follows: Multi-Link Devices (MLDs) can be configured on a link-by-link basis. If an unavailability period affects a portion of the channels of a certain link, the UnavailabilityFrequency Duration is set to the link number. Additionally, in some cases, when a device is in Multi-Link Single Radio / Enhanced Multi-Link Single Radio (MLSR / eMLSR) mode, if it is currently configured to operate on Link1, and Link1 has an unavailability period, it can switch to operating on Link2. That is, reporting unavailability status information to the second access point in the multi-access point cooperation group in step 101 can be: when the first access point is a multi-connection device, it reports each connection in the first access point corresponding to the unavailability status information to the second access point, using the unavailability frequency duration field, on a link-by-link basis. In one example, when the primary connection of the first access point enters an unavailability period, it automatically switches to a secondary connection to maintain the multi-access point cooperation state.

[0086] Regarding the scheme based on primary and secondary channels, the primary and secondary channels are divided according to the device's current operating channel. For example, with an 80MHz bandwidth, it is divided into a primary 40MHz channel and a non-primary 40MHz channel, where the primary 40MHz channel includes the primary channel. A value of 0 in the Unavailability Frequency Duration field indicates that the primary 40MHz channel is unavailable, while a value of 1 indicates that the non-primary 40MHz channel is unavailable. Other bandwidth divisions follow the same principle. Therefore, reporting unavailability status information to the second access point in the multi-access point cooperation group in step 101 can be done by using the current operating channel's division into primary and secondary channels as units, and reporting each channel in the first access point corresponding to the unavailability status information through the unavailability frequency duration field to the second access point.

[0087] Regarding the channel-granularity scheme, it combines the Unavailability Frequency Granularity and Unavailability Frequency Duration fields. For example, when Unavailability Frequency Granularity = 3, it means that in 20MHz bandwidth units, the channels are numbered sequentially according to the working channel frequency band from high to low or from low to high, and the unavailable channel number is indicated by the Unavailability Frequency Duration field. That is, reporting the unavailability status information to the second access point in the multi-access point cooperation group in step 101 can be done by reporting the channel number of each channel in the first access point corresponding to the unavailability status information to the second access point through the unavailability frequency duration field. The channel number of each channel is obtained by sorting the channels in the first access point according to the information carried by the unavailability frequency granularity field.

[0088]

[0089]

[0090] In this embodiment, during the multi-access point cooperation protocol negotiation phase, unavailability status information is reported to the second access point in the multi-access point cooperation group via negotiation frames or reporting frames. In response to the unavailability status information, the second access point coordinates the members in the multi-access point cooperation group to dynamically perform at least one of the following operations: adjust the membership qualifications of the members in the multi-access point cooperation group, reallocate cooperation resources to prevent the first access point from being scheduled when it is in an unavailable state, update or terminate the current multi-access point cooperation protocol, so that each device under multi-AP cooperation can efficiently and reliably integrate and process the "unavailability report" information from the AP itself and its associated terminals, and dynamically reconstruct cooperation tasks and achieve fault isolation accordingly.

[0091] The steps described above are for clarity only. In practice, they can be combined into one step or some steps can be split into multiple steps. As long as they include the same logical relationship, they are all within the scope of protection of this application. Adding insignificant modifications or introducing insignificant designs to the algorithm or process, but without changing the core design of the algorithm and process, are also within the scope of protection of this application.

[0092] Another embodiment of the present invention relates to an access point, such as Figure 7 As shown, it includes at least one processor 501; and a memory 502 communicatively connected to the at least one processor; wherein the memory 502 stores instructions executable by the at least one processor 501, the instructions being executed by the at least one processor 501 to enable the at least one processor 501 to perform the unavailability status reporting method as described above.

[0093] The memory 502 and processor 501 are connected via a bus, which can include any number of interconnecting buses and bridges. The bus connects various circuits of one or more processors 501 and memory 502 together. The bus can also connect various other circuits, such as peripheral devices, voltage regulators, and power management circuits, which are well known in the art and therefore will not be described further herein. A bus interface provides an interface between the bus and the transceiver. The transceiver can be a single element or multiple elements, such as multiple receivers and transmitters, providing a unit for communicating with various other devices over a transmission medium. Data processed by processor 501 is transmitted over a wireless medium via an antenna, which further receives data and transmits it to processor 501.

[0094] Processor 501 is responsible for managing the bus and general processing, and can also provide various functions, including timing, peripheral interfaces, voltage regulation, power management, and other control functions. Memory 502 can be used to store data used by processor 501 during operation.

[0095] Another embodiment of the present invention relates to a computer-readable storage medium storing a computer program. When executed by a processor, the computer program implements the above-described method embodiments.

[0096] That is, those skilled in the art will understand that all or part of the steps in the methods of the above embodiments can be implemented by a program instructing related hardware. This program is stored in a storage medium and includes several instructions to cause a device (which may be a microcontroller, chip, etc.) or processor to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as a USB flash drive, a portable hard drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk.

[0097] Those skilled in the art will understand that the above embodiments are specific examples of implementing the present invention, and in practical applications, various changes in form and detail may be made without departing from the spirit and scope of the present invention.

Claims

1. A method for reporting unavailability, characterized in that, Applied to the first access point, including: During the multi-access point cooperation protocol negotiation phase, unavailability status information is reported to the second access point in the multi-access point cooperation group through negotiation frames or reporting frames. In response to the unavailability status information, the second access point will coordinate the members in the multi-access point collaboration group to dynamically perform at least one of the following operations: adjust the membership of the members in the multi-access point collaboration group, reallocate collaboration resources to prevent the first access point from being scheduled while in an unavailable state, update or terminate the current multi-access point collaboration protocol. The unavailability status information includes at least one of the following: periodic unavailability period information generated by the first access point, non-periodic unavailability period information of the first access point, and unavailability period information reported by the associated terminal of the first access point.

2. The unavailability reporting method according to claim 1, characterized in that, The negotiation frame is a MAPC negotiation request frame or a MAPC negotiation response frame; The periodic unavailability period information includes: the start time and duration of the unavailability period for the first access point, and the periodic interval; The non-periodic unavailability period information includes: the start time and duration of the unavailability period for the first access point.

3. The unavailability reporting method according to claim 2, characterized in that, The method further includes: After the negotiation phase of the multi-access point cooperation protocol ends, whenever non-periodic unavailability period information generated by the first access point is detected, the non-periodic unavailability period information of the first access point is reported in real time through the reporting frame.

4. The unavailability reporting method according to claim 1, characterized in that, The adjustment of the eligibility criteria for joining the multi-access point collaboration group includes: When implementing the C-TDMA cooperation strategy, access points that have unavailable time periods and reserved time slots are refused entry into the multi-access point cooperation group. When the C-BF cooperation strategy is executed, access points that are unavailable during the detection period are allowed to join the multi-access point cooperation group, but the detection process of access points that are unavailable during the detection period is postponed.

5. The unavailability reporting method according to claim 1, characterized in that, The reallocation of collaborative resources to prevent the first access point from being scheduled when it is unavailable includes: Based on the periodic unavailability period information generated by the first access point, resource allocation is performed in advance to avoid the unavailability periods of the first access point; or, Based on the non-periodic unavailability period information generated by the first access point, resource reallocation is triggered in real time and all members in the collaboration group are notified.

6. The unavailability reporting method according to claim 1, characterized in that, The update or termination of the current multi-access point cooperation protocol includes: After the negotiation phase of the multi-access point cooperation protocol ends, when the second access point detects the periodic unavailability period information generated by the first access point, the second access point updates the current multi-access point cooperation protocol or terminates the current multi-access point cooperation protocol through the update process of the multi-access point cooperation protocol.

7. The unavailability reporting method according to claim 1, characterized in that, The unavailability status information further includes: an unavailability frequency duration field, and / or, an unavailability frequency granularity field, or an unavailability frequency field; reporting the unavailability status information to the second access point in the multi-access point cooperation group includes: When the unavailability status information applies to the entire frequency band of the first access point, the unavailability frequency granularity field is set to zero, and the second access point is informed that the unavailability status information applies to the entire frequency band of the first access point; or... When the unavailability status information applies to the entire frequency band of the first access point, by setting the unavailability frequency field to zero, the unavailability status information is reported to the second access point, which by default applies to the entire frequency band of the first access point, without needing to report the range of the effective frequency domain; or, When the first access point is a multi-connection device, the unavailability frequency duration field is used as the unit to report each connection in the first access point corresponding to the unavailability status information to the second access point; or, Using the current working channel as a unit for classifying it as a primary channel and a secondary channel, the unavailable frequency duration field is used to report each channel in the first access point corresponding to the unavailable status information to the second access point; or, The channel number of each channel in the first access point corresponding to the unavailable status information is reported to the second access point through the unavailable frequency duration field. The channel number of each channel is obtained by sorting the channels in the first access point according to the information carried by the unavailable frequency granularity field.

8. The unavailability reporting method according to claims 1-7, characterized in that, The method further includes: Before the multi-access point cooperation protocol negotiation phase, an enable parameter carrying an indication of whether the first access point supports unavailable reporting is reported to the second access point; Factors affecting whether the first access point supports unavailability reporting include the currently executed multi-access point collaboration strategy.

9. An access point, characterized in that, include: At least one processor; as well as, A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the unavailability reporting method as described in any one of claims 1 to 8.

10. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by the processor, it implements the unavailability reporting method as described in any one of claims 1 to 8.

Images