A frame interaction indication method and device for multi-ap cooperation mode selection
By introducing cross-mode fallback enable and performance feedback information bits into the Wi-Fi 8 standard frame structure, the problem of the lack of cross-mode fallback control in the Wi-Fi 8 standard is solved, enabling adaptive switching of multi-AP cooperative modes and improving transmission reliability and throughput.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- CHONGQING UNIV
- Filing Date
- 2026-05-27
- Publication Date
- 2026-07-14
Smart Images
Figure CN122395553A_ABST
Abstract
Description
Technical Field
[0001] This invention belongs to the field of wireless communication technology and relates to a frame interaction indication method and apparatus for selecting multi-AP cooperative mode. Background Technology
[0002] Wi-Fi 8 / UHR MAPC operations include Co-BF, Co-SR, and Co-TDMA. Existing drafts specify the procedures for Co-BF Invite / Trigger, Co-SR Invite / Trigger, and Co-TDMA ICF / ICR / TXOP allocation, respectively. Furthermore, the Feedback User Info already includes Feedback Type=2 / 3 / 4 to represent Co-BF, Co-TDMA, and Co-SR feedback, respectively. In other words, the standard can distinguish between different types of MAPC feedback, but it doesn't provide a unified information bit to indicate whether fallback is allowed when initiating a specific MAPC mode, whether performance metrics need to be returned, which MAPC modes are allowed to fall back to, and how the receiver should return key performance information for re-initiating ICF.
[0003] While the standard provides feedback types for each mode, it lacks a cross-mode fallback enable bit. The AP and peer AP cannot explicitly agree in the initial ICF whether a fallback to another mode is allowed after a primary mode failure. When a mode among Co-BF, Co-SR, or Co-TDMA is unsuitable for the current link, the coordinating AP only knows that the current mode has failed, lacking unified feedback on key performance indicators such as sounding, synchronization, power, interference, TXOP duration, and ACK duration. Without performance feedback, the coordinating AP struggles to determine whether to select Co-SR, Co-TDMA, Co-BF, or cancel MAPC when retransmitting the ICF, potentially leading to additional control overhead or wasted TXOPs. Summary of the Invention
[0004] In view of this, the purpose of the present invention is to provide a frame interaction indication method and apparatus for selecting multi-AP cooperative mode.
[0005] To achieve the above objectives, the present invention provides the following technical solution: On the one hand, a frame interaction indication method for selecting multi-AP cooperation modes in Wi-Fi 8 is provided. This method configures cross-mode fallback enable information bits and performance feedback information bits in the intra-frame reserved bits, reserved type, or extensible control fields of the existing standard frame structure of Wi-Fi 8. This allows an AP to pre-determine its fallback conditions and fallback feedback information based on the cross-mode fallback enable information bits and performance feedback information bits when initiating or responding to a multi-AP cooperation mode. During the configuration process, select the bearer fields for the cross-mode fallback enable information bit and the performance feedback information bit according to the requirements, and configure the corresponding logical information bits according to the selected bearer fields.
[0006] Furthermore, the carried fields include the multi-AP collaboration user information field MAPC User Info, and the carried logical information bits include at least the cross-mode fallback enable bit Fallback Enable, the performance feedback request bit Metric Feedback Req, the allowed fallback mode bitmap Allowed Fallback Mode Bitmap, and the fallback mode time range Fallback Scope. Among them, the cross-mode fallback enable bit is used to control whether to enable the multi-AP collaboration cross-mode fallback mechanism, as the master switch of the fallback process; the performance feedback request bit is used to actively request the peer AP to provide feedback on the collaborative link performance indicators, providing a basis for mode decision; the allowed fallback mode bitmap defines the set of switchable fallback modes in bitmap form, limiting the scope of legal degradation; the fallback mode time range defines the time domain in which the fallback mode takes effect, limiting the fallback to whether it occurs in the current TXOP or a subsequent TXOP.
[0007] Furthermore, the logical information bits carried by the multi-AP collaboration user information field also include the performance metric type bit (Metric Type Bitmap), the reason hint bit (Reason Hint), the metric format bit (Metric Format), and the reserved bit (Reserved).
[0008] Furthermore, the carried fields include a Feedback User Info field, wherein the carried logical information bits include at least a cross-mode fallback enable bit (Fallback Enable), a performance feedback request bit (Metric FeedbackReq), and an Allowed Fallback Mode Bitmap. The cross-mode fallback enable bit can reuse existing Feedback User Info and is used to control whether to enable the multi-AP collaborative cross-mode fallback mechanism; the performance feedback request bit triggers performance feedback with minimal overhead in a short field; and the Allowed Fallback Mode Bitmap is used to indicate the set of fallback modes that the AP can accept, avoiding illegal mode switching.
[0009] Furthermore, the logical information bits carried by the feedback user information field also include the performance metric type bitmap (MetricType Bitmap), the fallback scope (Fallback Scope), and the reserved bit (Reserved).
[0010] Furthermore, the bearer fields include the Coordination Response Multi-Site Block Acknowledgment Frame (CR Multi). STA BlockAck, wherein the carried logical information bits include at least the Beam Gain Class, Sync Class, Power Class, Interference Class, and Transmission Opportunity Class (TXOP Class) bits, wherein the Beam Gain Class bit is the feedback beamforming gain level, used to determine Co Whether BF is available; the synchronization level bit provides feedback on the synchronization quality between APs, determining whether the concurrent cooperation mode is feasible; the power level bit provides feedback on the transmit power status, evaluating Co. Is SR feasible? The interference level bit provides feedback on the channel interference level, used to assess the risk of concurrent transmission. The transmission opportunity level bit provides feedback on whether the TXOP duration is sufficient, used to determine whether to downgrade to Co. TDMA.
[0011] Furthermore, the logical information bits carried by the coordinated response multi-site block confirmation frame also include the MetricValid Bitmap, Fallback Needed, Primary Status, Reason Code, and Reserved.
[0012] Furthermore, the bearer field includes the A-Control field, where the bearer's logical information bits include at least the Suggested Mode bit and the Suggested Time bit. The Suggested Mode bit provides the recommended mode for the next collaboration, assisting the AP in quickly selecting the optimal solution; the Suggested Time bit provides the recommended duration corresponding to the suggested mode, assisting in resource allocation.
[0013] Furthermore, the logical information bits carried by the A control field also include Hint Valid, Reason, Metric Valid Bitmap, Validity, Seq Hint, and Reserved.
[0014] On the other hand, the apparatus also includes a frame processing unit, a control unit, and a communication unit, wherein... The frame processing unit is used to parse and edit the Wi-Fi 8 standard frame structure. In the intra-frame reserved bits, reserved type or extensible control fields of the existing Wi-Fi 8 standard frame structure, it configures the cross-mode fallback enable information bits and performance feedback information bits. At the same time, during the configuration process, it is used to select the bearer fields of the cross-mode fallback enable information bits and performance feedback information bits according to the actual application requirements of Wi-Fi 8 multi-AP cooperation, and configure the corresponding logical information bits according to the selected bearer fields. The control unit is used to control the AP device to initiate or respond to the multi-AP cooperation mode, read the cross-mode fallback enable information bit and performance feedback information bit configured by the frame processing unit, pre-agree with other Wi-Fi 8 AP devices in the network on fallback conditions and fallback feedback information based on the information bits, and dynamically determine whether to trigger fallback based on the actual cooperation performance. The communication unit is used to enable frame interaction between AP devices and other AP devices, and transmits Wi-Fi 8 standard frames containing cross-mode fallback enable information bits and performance feedback information bits to ensure collaborative interaction and synchronization between multiple APs.
[0015] The beneficial effects of this invention are as follows: This invention utilizes Wi The Fi8 standard frame structure introduces a cross-mode backoff enable and performance feedback indication mechanism in the reserved bits, reserved types, or scalable control fields, without altering existing Cooperative Beamforming (CoBEM) mechanisms. BF), Co-working Space Reuse SR), Cooperative Time Division Multiple Access (Co) Under the premise of the TDMA basic process, it provides lightweight and compatible cross-mode fallback control capability for multi-AP collaboration (MAPC), and can achieve adaptive mode switching without reconstructing the standard protocol stack, which significantly improves the versatility and standardization adaptability of the solution.
[0016] This invention pre-configures cross-mode backoff enable and allowed backoff mode sets during the coordination frame initiation phase, enabling the coordinating AP and the coordinated AP to clearly define backoff rules at the initial link establishment stage, avoiding communication interruptions caused by mode incompatibility. Simultaneously, the coordinated AP can accurately report key performance reasons for the unavailability of the primary mode to the coordinating AP, including expired channel probes, insufficient synchronization, power limitations, excessive interference, and insufficient transmission opportunities, providing reliable decision-making basis for the coordinating AP. This prevents the coordinating AP from blindly retrying inapplicable cooperative modes in unknown link conditions, reducing invalid frame interactions and state misjudgments.
[0017] The coordinating AP can resend the Initiate Coordination Frame (ICF) based on the performance metrics and backoff requests returned by the coordinated AP, and autonomously select a backoff mode more suitable for the current link state, thus achieving Coordination. BF, Co SR, Co Smooth degradation and optimal mode switching between TDMAs effectively reduce transmission opportunity (TXOP) waste, reduce control frame overhead and air interface resource occupation, and improve the overall throughput and transmission reliability of multi-AP cooperation.
[0018] Furthermore, the fallback control and performance feedback logic information bits of this invention are not limited to fixed field positions, and can be flexibly carried in MAPC User Info, Feedback User Info, CR Multi... STA BlockAck, A Among various existing fields such as Control, it supports adaptive adaptation based on field resources and application scenarios, which not only improves the flexibility of solution implementation, but also ensures compatibility with different standard versions and device implementations, and has strong scalability and engineering practicality.
[0019] Other advantages, objectives, and features of the invention will be set forth in part in the description which follows, and in part will be apparent to those skilled in the art from the following examination, or may be learned from practice of the invention. The objectives and other advantages of the invention can be realized and obtained through the following description. Attached Figure Description
[0020] To make the objectives, technical solutions, and advantages of the present invention clearer, the preferred embodiments of the present invention will be described in detail below with reference to the accompanying drawings, wherein: Figure 1 This is a schematic diagram illustrating an application scenario of the frame interaction indication method for selecting Wi-Fi 8 multi-AP cooperative modes according to an embodiment of the present invention; Figure 2 This is a flowchart of the basic frame switching process for Fallback Enable according to an embodiment of the present invention; Figure 3 This is a flowchart illustrating the process of reverting to Co-SR when Co-BF is not satisfied, according to an embodiment of the present invention. Figure 4 This is a flowchart illustrating the process of reverting to Co-TDMA via ICF when concurrent transmission is not satisfied, as described in this embodiment of the invention. Figure 5 This is a flowchart illustrating the ICR performance feedback field return process in an embodiment of the present invention. Figure 6 This is a flowchart illustrating A-Control as the auxiliary feedback for the next TXOP in an embodiment of the present invention. Detailed Implementation
[0021] The following specific examples illustrate the implementation of the present invention. Those skilled in the art can easily understand other advantages and effects of the present invention from the content disclosed in this specification. The present invention can also be implemented or applied through other different specific embodiments, and various details in this specification can be modified or changed based on different viewpoints and applications without departing from the spirit of the present invention. It should be noted that the illustrations provided in the following embodiments are only schematic representations of the basic concept of the present invention. Unless otherwise specified, the following embodiments and features can be combined with each other.
[0022] The accompanying drawings are for illustrative purposes only and are schematic diagrams, not actual pictures. They should not be construed as limiting the invention. To better illustrate the embodiments of the invention, some parts in the drawings may be omitted, enlarged, or reduced, and do not represent the actual product dimensions. It is understandable to those skilled in the art that some well-known structures and their descriptions may be omitted in the drawings.
[0023] In the accompanying drawings of the embodiments of the present invention, the same or similar reference numerals correspond to the same or similar components. In the description of the present invention, it should be understood that if terms such as "upper," "lower," "left," "right," "front," and "rear" indicate the orientation or positional relationship based on the orientation or positional relationship shown in the drawings, they are only for the convenience of describing the present invention and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation. Therefore, the terms used to describe positional relationships in the drawings are only for illustrative purposes and should not be construed as limiting the present invention. For those skilled in the art, the specific meaning of the above terms can be understood according to the specific circumstances.
[0024] Please see Figures 1-6 This invention relates to a frame interaction indication method and apparatus for selecting multi-AP cooperative modes.
[0025] This invention does not advocate using the standard Feedback Type=2 / 3 / 4 to represent Co-BF, Co-TDMA, or Co-SR, as this is already defined by the standard. The core of this invention is to add a fallback enable bit and a performance feedback bit to the reserved bits, reserved types, or extensible control fields of the existing standard frame structure. This allows AP1 and AP2 to agree on whether fallback is allowed and which performance metrics need to be fed back during fallback when initiating a MAPC operation. The bearer fields for the fallback enable bit and performance feedback bit are flexibly selected based on methods such as effective throughput calculation or other throughput estimation, including calculations of effective transmission information bits such as Block ACK, Multi-STA Block ACK, and ACK, and the corresponding logical information bits are configured according to the selected bearer fields.
[0026] When AP1 initiates a primary mode, such as Co-BF, and sets Fallback Enable=1, if AP2 determines that Co-BF does not meet the conditions, it does not need to directly determine the final fallback mode. Instead, it returns Fallback Needed=1 and key performance information in the ICR / Feedback field. AP1 resends the ICF based on this performance information, and the new ICF carries an indication of Co-SR, Co-TDMA, or other fallback modes.
[0027] Figure 1 This diagram illustrates an application scenario for enabling MAPC fallback according to the present invention. Figure 1 In Co-BF / Co-SR, the primary scenario is the pairwise MAPC of AP1 and AP2; AP3 simply indicates that Co-TDMA can be extended to multiple coordinated AP(s). The problem addressed by this invention is how to enable AP1 to retransmit ICF and select a more suitable MAPC mode when the preferred mode of AP1 is not suitable for the current link, through fallback enablement and performance feedback.
[0028] This invention protects a set of logical information elements used for MAPC fallback, rather than the fixed arrangement of these elements in a standard field. The positions B0, B1, etc., in the following table are merely preferred examples for illustrative purposes; in actual implementation, these logical information elements can be carried as a whole or in parts within the available reserved bits, reservation types, extended fields, multiple consecutive fields, or dedicated fields negotiated after capability agreement for MAPC User Info, Feedback User Info, ICR Multi-STA BlockAck, A-Control, QoS Data / QoS Null. Any element whose function is to indicate whether fallback is allowed, request / return performance metrics, indicate the reason for fallback, or assist in retransmitting ICF falls within the scope of this invention.
[0029] Specifically, any implementation that changes the order of fields in the following table, places multiple logical information elements in different reserved bits, uses different bit widths, employs multiple field combinations, adopts a Type-Length-Value structure, uses an existing bitmap with variable-length payload, or pre-agres to field mapping through capability negotiation, as long as it is still used to implement fallback enabling, allowed fallback mode set, performance feedback request, fallback reason, or performance metric return in MAPC three-mode fallback switching, should not be considered as departing from the inventive concept. Next, the specific solutions of the present invention will be described in detail with reference to specific embodiments: Example 1 This embodiment focuses on the Fallback Request Control field in the MAPC User Info. The corresponding standard field is the MAPC User Info field in IEEE P802.11bn / D1.4 9.3.1.22.9. A reserved MAPC Info Type, such as a value from 7-15, can be used to represent Fallback Request Control; alternatively, a shorter fallback enable field can be carried in the reserved bits of the specific Co-BF / Co-SR / Co-TDMA related MAPC Information.
[0030] In the standard diagram, MAPC Info Type 7-15 is reserved. In this embodiment, one of the reserved values is defined as the fallback request control type. The MAPC Information in the standard diagram is 24 bits. In this invention, fallback enable, whether to request performance feedback, the set of allowed fallback modes, and the performance metric type are carried in it.
[0031] Table 1
[0032] Table 2
[0033] Table 1 is an example of the MAPC User Info field structure in this embodiment, and Table 2 is an example of the fallback subfield in MAPC Information.
[0034] Specifically, in this embodiment, the definitions of each request-side logical information bit in the fallback subfield are shown in Table 3 below: Table 3
[0035] In Table 3, the Allowed Fallback Mode Bitmap indicates whether fallback to Co-TDMA, Co-SR, or Co-BF is allowed; Fallback Scope can indicate the same TXOP, the next TXOP, or both; see Table 4 below for details: Table 4
[0036] The 3-bit bitmap described above is only a preferred example. Equivalent implementations can use different bit orders, such as bit0=Co-BF, bit1=Co-SR, bit2=Co-TDMA; they can also use enumerated values, multiple Mode IDs, mode lists, TLVs, capability negotiation profiles, or longer bitmaps to represent the same set of allowed fallback modes.
[0037] In this embodiment, as Figure 2 As shown, the following is a basic ICF / ICR process example for Fallback Enable: 1. AP1 selects the primary MAPC mode, such as Co-BF, and sets Fallback Enable=1 in ICF or MAPC User Info.
[0038] 2. AP1 also sets Metric Feedback Request=1 and indicates the set of allowed fallback modes through Allowed FallbackMode Bitmap. For example, bitmap=101 indicates that fallback to Co-SR or Co-TDMA is allowed, and bitmap=111 indicates that AP1 is allowed to choose from Co-SR, Co-BF, and Co-TDMA modes based on performance metrics.
[0039] 3. After receiving the ICF, AP2 first checks whether the main mode is executable; if it is executable, it returns a normal accept response.
[0040] 4. If the main mode is not executable and Fallback Enable=1, AP2 returns Fallback Needed=1 and performance feedback information in ICR.
[0041] 5. AP1 resends the ICF based on the feedback information. The new ICF indicates the rollback mode, and subsequent processes are executed according to the corresponding standard mode.
[0042] Example 2 This embodiment focuses on the fallback short field in the Feedback User Info. The corresponding standard field is the Feedback User Info field in IEEE P802.11bn / D1.4 9.3.1.22.8. The standard Feedback Type=2 / 3 / 4 already represent Co-BF, Co-TDMA, and Co-SR feedback respectively. This invention does not change the meaning of this standard, but instead carries the fallback enable or performance feedback request in the Reserved bit of the corresponding Feedback Information.
[0043] Table 5
[0044] Table 6
[0045] Table 5 shows an example of the Feedback User Info structure in this embodiment, and Table 6 shows an example of short fields that can be carried in the Reserved bits of FeedbackInformation in this embodiment. When Feedback Type=2 or 4, 16 bits of Reserved are preferred; when Feedback Type=3, 13 bits of Reserved are preferred, and a portion of the field can be compressed. The logical information bits in the short fields of Feedback User Info are defined as shown in Table 7 below: Table 7
[0046] In the short field of Feedback User Info, the Allowed Mode Bitmap can use the same 3-bit encoding as in Table 7. When there are insufficient Reserved bits available, only FallbackEnable, Metric Feedback Req, and part of the Allowed Mode Bitmap can be carried through capability negotiation, with the remaining information supplemented by the subsequent ICR performance feedback field. The standard Feedback Type is only used to identify the feedback format. This invention protects the fallback enable and performance feedback request in the Reserved bits, rather than the standard Feedback Type=2 / 3 / 4.
[0047] In this embodiment, key performance information that AP2 can return in ICR is defined. This performance information does not have to be an exact physical value; it can also be a rating or bitmap to accommodate the MAC control field length.
[0048] like Figure 3 As shown, this embodiment also provides a process example for reverting from Co-BF to Co-SR when Co-BF is not satisfied: 1. AP1 initiates Co-BF ICF and sets Fallback Enable=1 and Allowed Fallback ModeBitmap=001, indicating that if the main mode Co-BF is not satisfied, only fallback to Co-SR is allowed; in other implementations, it can also be set to 101 or 111 to allow Co-SR and Co-TDMA or all three modes as candidates.
[0049] 2. AP2 determines that the sounding is outdated, Nss is insufficient, or the synchronization quality is insufficient, but the power constraints and interference conditions of Co-SR are met.
[0050] 3. AP2 returns Fallback Needed=1, Reason=sounding stale or syncinsufficient in ICR, and returns Power Class / Interference Class.
[0051] 4. AP1 does not interrupt the Co-BF PPDU transmission, but instead retransmits the ICF before the Co-BF Trigger. The new ICF indicates the Co-SR.
[0052] 5. After AP2 confirms the new Co-SR ICF, AP1 and AP2 perform concurrent transmission according to the Co-SR Trigger.
[0053] like Figure 4 As shown, this embodiment also provides a process example for reverting to Co-TDMA via ICF when concurrent transmission is not satisfied: 1. AP1 prefers Co-BF or Co-SR and sets Fallback Enable=1 and Allowed FallbackMode Bitmap=100, indicating that it will fall back to Co-TDMA first when the concurrent transmission conditions are not met; in multiple candidate implementations, it can be set to 101, 110 or 111.
[0054] 2. AP2 returns performance feedback indicating that the synchronization, power, or interference conditions required for concurrent transmission are not met, but one TXOP time slice is acceptable.
[0055] 3. AP1 retransmits the Co-TDMA ICF based on the feedback, polls AP2 in the remaining time of the same TXOP or the next TXOP, and may also poll other coordinated APs such as AP3 if necessary.
[0056] 4. The polled AP returns in the ICR whether it requests a time slice and the acceptable duration.
[0057] 5. AP1 allocates a TXOP time slice based on the response and performs Co-TDMA transmission.
[0058] Example 3 This embodiment is designed for performance feedback response in CR Multi-STA BlockAck. The corresponding standard field is the Feedback Per AID TID Info subfield of IEEE P802.11bn / D1.4 9.3.1.8.6. While AP2 acknowledges the ICF in the ICR, it can return whether fallback is needed, the reason, and key performance indicators in the Feedback field. This feedback is used by AP1 to determine whether to resend the ICF and select the fallback mode.
[0059] Table 8
[0060] Table 9
[0061] Table 8 shows an example of the CR Multi-STA BlockAck field in this embodiment, and Table 9 shows an example of the performance feedback subfield in the Feedback field. The logical information bits in the ICR performance feedback subfield are defined as shown in Table 10 below: Table 10
[0062] The Fallback Needed, Primary Status, Reason Code, and various Metric Classes in the ICR performance feedback fields can be arranged in any order, and can appear partially in the Feedback field and partially in other ICR-related reserved fields. If some metrics are not requested or are unavailable, they can be indicated as invalid through the Metric Valid Bitmap, field omissions, missing TLVs, or reserved values.
[0063] The aforementioned ICR performance feedback fields are strongly correlated with the Allowed Fallback Mode Bitmap: when bitmap=001, AP1 primarily uses Power Class and Interference Class to determine Co-SR; when bitmap=010, AP1 primarily uses Beam Gain Class and Sync Class to determine Co-BF; when bitmap=100, AP1 primarily uses TXOP Class to determine Co-TDMA; when bitmap=111, AP1 comprehensively considers all valid metrics to determine the fallback target in the three modes. The standard graph provides a Feedback field as the feedback carrier. This invention defines the performance feedback categories required for cross-mode fallback in this field, rather than directly requiring AP2 to determine the final fallback mode. AP1 re-initiates ICF based on this performance information.
[0064] like Figure 5 As shown, the ICR performance feedback field return process is illustrated below: 1. AP2 returns the Beam Gain Class in ICR, which indicates the Co-BF expected return level.
[0065] 2. AP2 returns a Sync Class, which indicates whether the synchronization between APs satisfies Co-BF or Co-SR concurrent transmission.
[0066] 3. AP2 returns either Power Class or TX Power Constraint, indicating whether Co-SR can be performed under power constraints.
[0067] 4. AP2 returns an Interference Class, which indicates the risk of spatial reuse interference.
[0068] 5. AP2 returns TXOP Class or Max Acceptable Duration, indicating whether Co-TDMA time slice allocation is suitable.
[0069] Example 4 This embodiment focuses on the design of the next TXOP fallback hint field in A-Control. The corresponding standard fields are the A-Control subfield of IEEE P802.11REVmf / D2.1 9.2.4.6.4 and the Control ID encoding in Table 9-25. A-Control serves only as an auxiliary hint for the next TXOP and is not the main control field for the current ICF / ICR.
[0070] Table 11
[0071] Table 12
[0072] Table 11 shows examples of the A-Control field in this embodiment, and Table 12 shows examples of the hint subfield in ControlInformation in this embodiment. Specifically, the logical information bits in the A-Control hint are defined as shown in Table 13 below: Table 13
[0073] The logical information elements in the A-Control hint are not limited to the above order. In the implementation, HintValid can be implicitly included in the Control ID, Suggested Mode can be represented as a pattern bitmap or a list of patterns, Reason and Metric Valid Bitmap can be split into multiple A-Control subfields, or different encoding methods can be specified through capability negotiation.
[0074] The Suggested Mode in the A-Control hint does not require AP1 to use this mode; it, along with the Validity, Reason, and Metric Valid Bitmap, serves as a candidate mode hint for the next TXOP. AP1 can still set Allowed Fallback Mode Bitmap=111 in the next ICF to allow reselection among the three modes based on real-time ICR performance feedback.
[0075] The reserved Control ID of A-Control can be used as a control subfield for the MAPC fallback hint in subsequent standardization. This method only affects the candidate mode selection for the next TXOP; the next formal operation should still be completed through ICF / ICR.
[0076] The field positions in the above design are examples and not limitations. Optional bearers include, but are not limited to: reserved MAPC Info Types 7-15 in MAPC UserInfo, reserved bits in specific Co-BF / Co-SR / Co-TDMA MAPC Information, reserved bits in AID12=2008 Feedback User Info, reserved Feedback context / reserved Feedback Type in Multi-STABlockAck, reserved Control IDs 10-14 in A-Control, and reserved bits allowed by context in QoS Data / QoS Null. Reserved bits for QoS Control are only an alternative implementation; preferably, MAPC / ICF / ICR related fields are still the primary focus.
[0077] like Figure 6 As shown, this embodiment provides a flowchart example of TXOP auxiliary feedback under A-Control: 1. After AP1 and AP2 complete the current MAPC transmission, AP2 obtains a new local state, such as queue growth, power limitation, or sounding about to expire.
[0078] 2. AP2 carries A-Control in QoS Null, QoS Data, or other frames that allow HT Control.
[0079] 3. A-Control uses a reserved Control ID, such as 12 or 13, to carry the fallback hint for the next TXOP.
[0080] 4. AP1 records the hint in the history table, but does not directly change the transmission that has already started for the current TXOP.
[0081] 5. When AP1 obtains TXOP again, it will still formally set Fallback Enable and target mode through ICF / MAPC User Info.
[0082] Example 5 This embodiment describes an apparatus for performing the aforementioned method. The apparatus is integrated into a Wi-Fi 8 AP device and includes a frame processing unit, a control unit, and a communication unit, wherein: The frame processing unit is used to parse and edit the Wi-Fi 8 standard frame structure. Specifically, it is used to configure cross-mode fallback enable information bits and performance feedback information bits in the intra-frame reserved bits, reserved type, or extensible control fields of the existing Wi-Fi 8 standard frame structure. At the same time, during the configuration process, it is used to select the bearer fields of the cross-mode fallback enable information bits and performance feedback information bits according to the actual application requirements of Wi-Fi 8 multi-AP cooperation, and configure the corresponding logical information bits according to the selected bearer fields to ensure that the configured frame structure conforms to the Wi-Fi 8 standard transmission specifications. The control unit is used to control the AP device to initiate or respond to the multi-AP cooperation mode. Specifically, it is used to read the cross-mode fallback enable information bit and performance feedback information bit configured by the frame processing unit, pre-agree with other Wi-Fi 8 AP devices in the network on fallback conditions and fallback feedback information based on the information bits, and dynamically determine whether to trigger fallback based on the actual cooperation performance. The communication unit is used to enable frame interaction between AP devices and other Wi-Fi 8 AP devices, and to transmit Wi-Fi 8 standard frames containing cross-mode fallback enable information bits and performance feedback information bits to ensure the cooperative interaction and synchronization between multiple APs.
[0083] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and are not intended to limit it. Although the present invention has been described in detail with reference to preferred embodiments, those skilled in the art should understand that modifications or equivalent substitutions can be made to the technical solutions of the present invention without departing from the spirit and scope of the present invention, and all such modifications or substitutions should be covered within the scope of the claims of the present invention.
Claims
1. A frame interaction indication method for selecting multi-AP cooperative mode, characterized in that: The method configures cross-mode fallback enable information bits and performance feedback information bits in the intra-frame reserved bits, reserved type, or extensible control fields of the existing standard frame structure of Wi-Fi 8; so that when an AP initiates or responds to a multi-AP cooperation mode, it can pre-determine its fallback conditions and fallback feedback information based on the cross-mode fallback enable information bits and performance feedback information bits, wherein... During the configuration process, select the bearer fields for the cross-mode fallback enable information bit and the performance feedback information bit according to the requirements, and configure the corresponding logical information bits according to the selected bearer fields.
2. The frame interaction indication method for multi-AP cooperative mode selection according to claim 1, characterized in that: The carried fields include the MAPC User Info field for multi-AP collaboration user information. The carried logical information bits include at least the Fallback Enable bit, the Metric Feedback Req bit, the Allowed Fallback Mode Bitmap, and the Fallback Scope. The Fallback Enable bit controls whether to enable the multi-AP collaboration cross-mode fallback mechanism, serving as the master switch for the fallback process. The Metric Feedback Req bit is used to actively request feedback from the peer AP on the collaborative link performance metrics, providing a basis for mode decisions. The Allowed Fallback Mode Bitmap defines the set of switchable fallback modes in bitmap form, limiting the scope of legal degradation. The Fallback Scope defines the time domain in which the fallback mode takes effect, limiting whether the fallback occurs in the current TXOP or a subsequent TXOP.
3. The frame interaction indication method for multi-AP cooperative mode selection according to claim 2, characterized in that: The logical information bits carried by the multi-AP collaborative user information field also include the performance metric type bit (Metric TypeBitmap), the reason hint bit (Reason Hint), the metric format bit (Metric Format), and the reserved bit (Reserved).
4. The frame interaction indication method for multi-AP cooperative mode selection according to claim 1, characterized in that: The bearer fields include a Feedback User Info field, wherein the logical information bits carried include at least a Fallback Enable bit, a Metric Feedback Req bit, and an Allowed Fallback Mode Bitmap. The Fallback Enable bit can reuse existing Feedback User Info and is used to control whether to enable the multi-AP collaborative cross-mode fallback mechanism; the Metric Feedback Req bit triggers performance feedback with minimal overhead in a short field; and the Allowed Fallback Mode Bitmap is used to indicate the set of fallback modes that the AP can accept, avoiding illegal mode switching.
5. The frame interaction indication method for multi-AP cooperative mode selection according to claim 4, characterized in that: The logical information bits carried by the feedback user information field also include a performance metric type bitmap, a fallback scope, and a reserved bit.
6. The frame interaction indication method for multi-AP cooperative mode selection according to claim 1, characterized in that: The bearer field includes the Coordination Response Multi-Site Block Acknowledgment Frame (CR Multi). STA BlockAck, wherein the carried logical information bits include at least the Beam Gain Class, Sync Class, Power Class, Interference Class, and Transmission Opportunity Class (TXOP Class) bits, wherein the Beam Gain Class bit is the feedback beamforming gain level, used to determine Co Whether BF is available; the synchronization level bit provides feedback on the synchronization quality between APs, determining whether the concurrent cooperation mode is feasible; the power level bit provides feedback on the transmit power status, evaluating Co. Is SR feasible? The interference level bit provides feedback on the channel interference level, used to assess the risk of concurrent transmission. The transmission opportunity level bit provides feedback on whether the TXOP duration is sufficient, used to determine whether to downgrade to Co. TDMA.
7. The frame interaction indication method for multi-AP cooperative mode selection according to claim 6, characterized in that: The logical information bits carried by the coordinated response multi-site block confirmation frame also include a Metric Valid Bitmap, a Fallback Needed bit, a Primary Status bit, a Reason Code bit, and a Reserved bit.
8. The frame interaction indication method for multi-AP cooperative mode selection according to claim 1, characterized in that: The bearer field includes an A-Control field, wherein the logical information bits of the bearer include at least a Suggested Mode bit and a Suggested Time bit. The Suggested Mode bit provides a recommended mode for the next collaboration, assisting the AP in quickly selecting the optimal solution; the Suggested Time bit provides the recommended duration corresponding to the suggested mode, assisting in resource allocation.
9. The frame interaction indication method for multi-AP cooperative mode selection according to claim 8, characterized in that: The logical information bits carried by the A control field also include Hint Valid, Reason, Metric Valid Bitmap, Validity, Seq Hint, and Reserved.
10. An apparatus for performing the frame interaction indication method for selecting a multi-AP cooperative mode according to any one of claims 1-9, characterized in that: The device includes a frame processing unit, a control unit, and a communication unit, wherein... The frame processing unit is used to parse and edit the Wi-Fi 8 standard frame structure. In the intra-frame reserved bits, reserved type or extensible control fields of the existing Wi-Fi 8 standard frame structure, it configures the cross-mode fallback enable information bits and performance feedback information bits. At the same time, during the configuration process, it is used to select the bearer fields of the cross-mode fallback enable information bits and performance feedback information bits according to the actual application requirements of Wi-Fi 8 multi-AP cooperation, and configure the corresponding logical information bits according to the selected bearer fields. The control unit is used to control the AP device to initiate or respond to the multi-AP cooperation mode, read the cross-mode fallback enable information bit and performance feedback information bit configured by the frame processing unit, pre-agree with other Wi-Fi 8 AP devices in the network on fallback conditions and fallback feedback information based on the information bits, and dynamically determine whether to trigger fallback based on the actual cooperation performance. The communication unit is used to enable frame interaction between AP devices and other AP devices, and transmits Wi-Fi 8 standard frames containing cross-mode fallback enable information bits and performance feedback information bits to ensure collaborative interaction and synchronization between multiple APs.