Method and apparatus for indicating feedback using an ICR frame in a wireless network

Abstract

Disclosed subject matter relates to method and UE for indicating feedback in an Initial Control Response (ICR) frame in IEEE 802.11 based network is disclosed. The present disclosure comprises transmitting an ICR frame to a peer station (STA) device. The ICR frame comprises a block acknowledgement starting sequence control field comprising a total number of feature Identifiers (IDs) and a total length of one or more feedback. The ICR frame further comprises a block acknowledgement bitmap field comprising a feature ID, a feedback presence indicator, length of per ID feedback, and per ID feedback, for each of one or more features. The per ID feedback comprises the one or more feedback.

Description

METHOD AND APPARATUS FOR INDICATING FEEDBACK USING AN ICR FRAME IN A WIRELESS NETWORK

[0001] The present disclosure relates to the field of Wireless Local Area Network (WLAN) technology. Particularly, but not exclusively, the present disclosure relates to a method and a apparatus for indicating feedback in an Initial Control Response (ICR) frame in a wireless network.

[0002] Wireless communication devices today commonly support multiple technologies such as Wi-Fi (IEEE 802.11), Bluetooth (BT), Ultra-Wideband (UWB), Zigbee, and 5G New Radio (NR). These technologies often operate simultaneously within the same device, leading to In-Device Coexistence (IDC) issues. Such issues arise due to interference between radios operating in close proximity, which can degrade performance across one or more technologies.

[0003] For example, transmission or reception by one radio (e.g., Bluetooth) may interfere with another (e.g., Wi-Fi), resulting in missed acknowledgments or reduced throughput. This phenomenon, sometimes referred to as double punishment, can cause a station to lower its data rate unnecessarily due to perceived packet loss.

[0004] The IEEE 802.11 working group, particularly the Ultra High Reliability (UHR) Task Group (Tgbn), has recognized the significance of these coexistence challenges. Discussions within the group have focused on mechanisms to better manage device availability and operational constraints, especially during scheduled transmission opportunities (TXOPs). In these contexts, communication between Access Points (APs) and Stations (STAs) may be affected by time-based, frequency-based, or spatial stream-based constraints. Coexistence events can be periodic or aperiodic, and their unpredictable nature complicates scheduling and resource allocation in wireless networks.

[0005] However, challenges remain in efficiently representing multiple types of feedback, handling partial or missing information, and maintaining compatibility with existing standards. These issues are relevant in dynamic environments where device capabilities and availability may change rapidly due to internal or external factors. Hence, there is a need to overcome these limitations.

[0006] The information disclosed in this background of the disclosure section is only for enhancement of understanding of the general background of the disclosure and should not be taken as an acknowledgement or any form of suggestion that this information forms prior art already known to a person skilled in the art.

[0007] One or more shortcomings of the prior art may be overcome, and additional advantages may be provided through the present disclosure. Additional features and advantages may be realized through the techniques of the present disclosure. Other embodiments and aspects of the disclosure are described in detail herein and are considered a part of the claimed disclosure.

[0008] In a non-limiting embodiment of the disclosure, a method of indicating feedback in an Initial Control Response (ICR) frame in IEEE 802.11 based network is disclosed. The method comprises transmitting an ICR frame to a peer station (STA) device. The ICR frame comprises a block acknowledgement starting sequence control field comprising a total number of feature Identifiers (IDs) and a total length of one or more feedback. The ICR frame further comprises a block acknowledgement bitmap field comprising a feature ID, a feedback presence indicator, length of per ID feedback, and per ID feedback, for each of one or more features. The per ID feedback comprises the one or more feedback.

[0009] In a non-limiting embodiment of the disclosure, a STA device for indicating feedback in an Initial Control Response (ICR) frame in IEEE 802.11 network is disclosed. The UE comprises a processor and a memory communicatively coupled to the processor, where the memory stores processor executable instructions, which, on execution, may cause the STA device to transmit an ICR frame to a peer station (STA) device. The ICR frame comprises a block acknowledgement starting sequence control field comprising a total number of feature Identifiers (IDs) and a total length of one or more feedback. The ICR frame further comprises a block acknowledgement bitmap field comprising a feature ID, a feedback presence indicator, length of per ID feedback, and per ID feedback, for each of one or more features. The per ID feedback comprises the one or more feedback.

[0010] The foregoing summary is illustrative only and is not intended to be in any way limiting. In addition to the illustrative aspects, embodiments, and features described above, further aspects, embodiments, and features will become apparent by reference to the drawings and the following detailed description.

[0011] The accompanying drawings, which are incorporated in and constitute a part of this disclosure, illustrate exemplary embodiments and, together with the description, serve to explain the disclosed principles. In the figures, the left-most digit(s) of a reference number identifies the figure in which the reference number first appears. The same numbers are used throughout the figures to reference like features and components. Some embodiments of system and / or methods in accordance with embodiments of the present subject matter are now described, by way of example only, and with reference to the accompanying figures, in which:

[0012] Fig. 1 shows an exemplary environment for indicating feedback in an Initial Control Response (ICR) frame in IEEE 802.11 based network, in accordance with some embodiments of the present disclosure;

[0013] Fig. 2 shows a detailed block diagram of a STA device, in accordance with some embodiments of the present disclosure;

[0014] Fig. 3 shows a M-STA BA frame format as per current specification;

[0015] Fig. 4 shows a modified M-STA BA frame format, in accordance with some embodiments of the present disclosure;

[0016] Fig. 5a shows a first variant of a simplified modified M-STA BA frame format, in accordance with some embodiments of the present disclosure;

[0017] Fig. 5b shows a second variant of a simplified modified M-STA BA frame format, in accordance with some embodiments of the present disclosure;

[0018] Fig. 6 shows a modified M-STA BA frame format with feedback presence indicator, in accordance with some embodiments of the present disclosure;

[0019] Fig. 7a-7b show an exemplary scenario where unavailability information has an update, in accordance with some embodiments of the present disclosure;

[0020] Fig. 8a-8b show an exemplary scenario where unavailability information has no update, in accordance with some embodiments of the present disclosure;

[0021] Fig. 9a-9b show an exemplary scenario where duration information is missing, in accordance with some embodiments of the present disclosure;

[0022] Fig. 9c shows an exemplary scenario where start time information is missing, in accordance with some embodiments of the present disclosure;

[0023] Fig. 10a shows an exemplary action frame, in accordance with some embodiments of the present disclosure;

[0024] Fig. 10b shows an exemplary DUO Event frame, in accordance with some embodiments of the present disclosure;

[0025] Fig. 11 shows an exemplary control frame, in accordance with some embodiments of the present disclosure; and

[0026] Fig. 12 is a flowchart illustrating a method for managing forbidden lists of Tracking Areas (TAs) in communication networks, in accordance with some embodiments of the present disclosure.

[0027] Fig. 13 is a block diagram of an exemplary computer system for implementing embodiments consistent with the present disclosure.

[0028] It should be appreciated by those skilled in the art that any block diagrams herein represent conceptual views of illustrative systems embodying the principles of the present subject matter. Similarly, it will be appreciated that any flow charts, flow diagrams, state transition diagrams, pseudo code, and the like represent various processes which may be substantially represented in computer readable medium and executed by a computer or processor, whether or not such computer or processor is explicitly shown.

[0029] In the present document, the word "exemplary" is used herein to mean "serving as an example, instance, or illustration." Any embodiment or implementation of the present subject matter described herein as "exemplary" is not necessarily to be construed as preferred or advantageous over other embodiments.

[0030] While the disclosure is susceptible to various modifications and alternative forms, specific embodiment thereof has been shown by way of example in the drawings and will be described in detail below. It should be understood, however, that it is not intended to limit the disclosure to the forms disclosed, but on the contrary, the disclosure is to cover all modifications, equivalents, and alternative falling within the scope of the disclosure.

[0031] The terms "comprises," "comprising," "includes" or any other variations thereof, are intended to cover a non-exclusive inclusion, such that a setup, device, or method that includes a list of components or steps does not include only those components or steps but may include other components or steps not expressly listed or inherent to such setup or device or method. In other words, one or more elements in a system or apparatus proceeded by "comprises… a" does not, without more constraints, preclude the existence of other elements or additional elements in the system or method.

[0032] The present invention relates to the field of wireless communication. In particular, the present invention relates to wireless communication system.

[0033] A typical Station (STA) supports multiple wireless technologies such as Bluetooth (BT), Ultra-Wide Band (UWB), New Radio (NR) / 5G, Zigbee for IoT, peer-to-peer (P2P) connections with other Wi-Fi devices, and Wireless LAN (WLAN / Wi-Fi). Multiple connections to various devices are enabled due to wireless technology, such as earbuds over Bluetooth using 2.4 GHz channels, VR headsets over Wi-Fi Direct or Bluetooth using 2.4 GHz or 5 GHz channels, and wearables like watches or rings over Bluetooth using 2.4 GHz or 5 GHz channels. Further, 3GPP technologies like NR are also supported, which operate in Sub-6 GHz frequencies. However, this can lead to in-device coexistence issues which is due to the integration of multiple technologies within a single device. For example, transmission or reception of Bluetooth, can hamper or disrupt the operation of Wi-Fi, which may result in issues such as double punishment, due to in-device coexistence, Acknowledgment (Ack) may not be transmitted, or a STA is unable to receive the data packets and as a result, the transmitting station shall reduce the data rates of future data packets.

[0034] This interference causes the lower data rates of subsequent transmissions. To address these challenges, the Institute of Electrical and Electronics Engineers (IEEE), 802.11 Ultra High Reliability (UHR) Task Group such as, Tgbn is actively discussing solutions to mitigate in-device coexistence issues.

[0035] When a co-existence (co-ex) event occurs, communication with an Access Point (AP) or STA may experience interference, and constraints can be applied to parameters such as time, frequency, and spatial streams. A co-ex event can occur at the time of operation when a transmission or reception is scheduled. Further, the co-ex event can occur on specific frequency of operation or can impact the operation of number of spatial streams. The co-ex events are typically categorized into periodic and non-periodic (or urgent / aperiodic) events. For periodic events, existing mechanisms in 802.11, like P2P Target-Wake-Time (TWT), can be leveraged to enhance support. For urgent or aperiodic events, the Tgbn group has proposed new mechanisms, including control frames that can notify on updated / reduced transmission capabilities within a Transmit Opportunity, TXOP. These updates can reduce time availability, bandwidth, and the number of spatial streams due to the co-ex event for example. The present disclosures in 802.11bn discuss about introducing an Initial Control Frame (ICF) sent by an AP that solicits the non-AP STA, so that the it can respond with an Initial Control Response (ICR) frame that can include the availability or unavailability information. A peer STA sends an ICF that solicits unavailability info from the STA with IDC issues. The STA that is experiencing co-ex issues sends an ICR that includes an unavailability report with start time and duration etc.

[0036] In an embodiment, the Buffer Status Report Poll (BSRP) and Multi-STA Block Acknowledgment (M-STA-BA) are utilized for the Initial Control Frame (ICF) and Initial Control Response (ICR) according to the motions agreed upon in the UHR standards (Ref: 24 / 1226, 24 / 834, 24 / 0171).

[0037] Choice of ICF-ICR: (Ref: 24 / 1226 , 24 / 834, 24 / 0171) - is BSRP and M-STA-BA according to agreed motions in UHR standards

[0038] 1. Buffer Status Report Poll (BSRP) trigger frame (TF):

[0039] - Motion 139: TGbn uses BSRP Trigger frame as a UHR Initial Control frame (ICF) sent:

[0040] From an AP for soliciting response in TB PPDU format from one or more scheduled STAs to allow a Multi-STA BA frame to be included in the TB PPDU sent by the UHR scheduled STAs in response, when carrying unavailability information.

[0041] BSRP Trigger frame follows baseline rules for the solicited TB PPDU

[0042] 2. Multi-STA Block Ack (M-STA-BA) :

[0043] - Motion 138: TGbn uses Multi-STA BA for Initial Control Response frame (ICR) for DL and UL, at least when carrying the unavailability information

[0044] M-STA BA frame format as per current specification.

[0045] - The BA control has BA Type set to M-STA BA.

[0046] - BA information has Per AID TID Info

[0047] - Per AID TID Info has AID TID Info (Which has AID11, Ack Type, TID), BA Starting Sequence control which comprises of Fragment number and Starting sequence and BA Bitmap.

[0048] - The Fragment number identifies the length of the BA bitmap for Block Ack purposes as shown in the table.

[0049] Agreed in 802.11bn (References: [24 / 0171]) some fields in M-STA-BA are modified and reused to indicate the unavailability feedback

[0050] - Motion 138: TGbn uses Multi-STA BA for Initial Control Response frame (ICR) for DL and UL, at least when carrying the unavailability information

[0051] - Motion 140: TGbn defines the following fields for unavailability indication in M-STA BA frames:

[0052] o an Unavailability Target Start Time field defined as the TSF time at which the STA becomes unavailable (range and resolution TBD, expectation is to use a portion of the TSF)

[0053] o an Unavailability Duration field defined as the time during which the STA is unavailable (field may be not present or set to an unknown value)

[0054] - Motion 141: TGbn defines a special Feedback Per AID TID Info field (name TBD) that carries control feedback in the Multi-STA BA frame

[0055] o The control feedback (i.e., unavailability indication) is carried instead of the BlockAck Bitmap in that Feedback Per AID TID Info field

[0056] o The Ack Type subfield of the Per AID TID Info field is set to 0 and the TID subfield of the Per AID TID Info field is set to a reserved value

[0057] o The AID11 subfield of this Per AID TID Info field is set to a reserved TBD value if the control feedback is addressed to all STAs or to the AID11 that identifies the intended recipient STA

[0058] o The Starting Sequence Number field of this Per AID TID Info field is reserved

[0059] - Motion 151: 11bn allows Multi-STA BA to carry one or more types of feedback (e.g., unavailability) information

[0060] o How to include feedback information is TBD

[0061] The current proposal according to UHR agreed motions, modifies and reuses some fields of M-STA-BA for indicating the unavailability feedback to handle the in-device coexistence issues. Further enhancements can be proposed to the proposed design of M-STA-BA to include following:

[0062] 1. Motion 151 specifies that M-STA-BA can carry more than one type of feedback and the design of Frame format for this is TBD.

[0063] - Enhancements to M-STA-BA frame format can be proposed to include multiple types of feedback which is currently TBD.

[0064] - A common framework can be proposed to be included in M-STA-BA to include type of feedback with its associated information.

[0065] 2. Motion 141 specifies that the Per AIDTID Info is designed to carry in specific (reserved) values to indicate unavailability information.

[0066] - But this design is not optimal or complete to carry unavailability information in multiple scenarios like:

[0067] 1. No Update to previous unavailability update

[0068] 2. Need update from previous data (with start time and duration)

[0069] 3. No start time of unavailability available

[0070] 4. No duration of unavailability available to report

[0071] - Enhancements to format of indicating unavailability information with optimal design to carry information in multiple scenarios while keeping agreed design in UHR

[0072] According to the existing disclosures in the Tgbn group, there has been no discussion on how to include multiple types of feedback in the Multi-STA Block Acknowledgment (M-STA-BA) frame. However, based on the group's discussions, various types of feedback or feature-related information could potentially be sent within the M-STA-BA frame. These include unavailability information to mitigate or address in-device coexistence issues, the C-TDMA operation (as a response to polling by one AP in an Initial Control Frame (ICF) to another AP), power-saving information such as transitioning a device from low capability to high capability mode via an Initial Control Response frame, and NPCA / DSO, among others. Since multiple feedback types can be included in the same M-STA-BA frame, it is necessary to define a framework within the M-STA-BA format to accommodate the inclusion of these different types of feedback.

[0073] The present disclosure relates to the mitigation of in-device coexistence issues in wireless communication, particularly within the context of 802.11 technologies. It highlights the challenge posed by multiple wireless technologies (e.g., Bluetooth, Wi-Fi, NR / 5G, Zigbee) coexisting in a single form factor, leading to interference that can affect communication reliability and performance and introduces mechanisms like the Initial Control Frame (ICF) and Initial Control Response (ICR) for dynamic management of unavailability information, including start time and duration of unavailability periods. It further explores enhancements to the Multi-STA Block Ack (M-STA-BA) frame, which will carry feedback on unavailability information, with a detailed design to indicate when the information is updated or unavailable. It discusses a Feedback Presence field to optimize feedback handling, saving airtime and improving flexibility when unavailability data is missing or unchanged. Further, the other embodiment of the disclosure discusses scenarios where dynamic unavailability events (DUO-START and DUO-END) are communicated between AP and non-AP STA, using control frames to handle such events efficiently.

[0074] The present disclosure, based on the UHR agreed motions, modifies and reuses some fields of M-STA-BA for indicating the unavailability feedback to handle the in-device coexistence issues. However, further enhancements may be proposed to improve the M-STA-BA frame design. According to Motion 151, the M-STA-BA frame could carry more than one type of feedback, also enhancements to M-STA-BA frame format may be proposed to include multiple types of feedback which is currently TBD. A common framework can be proposed to be included in M-STA-BA to include type of feedback with its associated information.

[0075] According to agreed motions, in order to send control feedback. AID 11 is addressed to specific STA or set to reserved value (eg: 2008) to address to multiple STAs and Ack Type 0 , TID is set to reserved value (eg 13).

[0076] In an embodiment, the frame format for a typical M-STA-BA in current specification is disclosed. The current solution shall further define the Block Ack Starting sequence control and BA bitmap values for a common framework to carry control feedback.

[0077] Block Ack Starting Sequence Control consists of 2 octets. According to the proposed solution, as part of first octet, Fragment number can be modified to indicate number of Feature ID and Total length of the feedback in Block Ack Bitmap field. The details are as per Table 1.

[0078] FeatureNumber of Feature ID(mapped from Fragment Number field )Length(in octets)B3B2B1B0In-Device Coexistence00003 (9 bits for duration, 9 bits for start time)C-TDMA0001TBDPower Save0010TBDNPCA0011TBDDSO0100TBDReserved<< Values from 5 to 16 are reserved for future use>>Reserved

[0079] Further, the Block Ack Bitmap field is modified to represent the Feature ID, the length of the feedback, and, following that, the per-ID feedback field, which specifies the type of feedback defined for each feature. This per-ID feedback field spans a number of octets corresponding to the length specified.

[0080] A new mapping for Fragment number field is defined which includes mapping of features to Fragment number bits which shall indicate the Feature ID number. The remaining bits can indicate the total length in the control feedback message which will be part of BA bitmap field. As per the agreed motions, 18 bits are allocated for unavailability information to indicate the in-device coexistence feature. The total length (B4-B7) field will be the sum of the lengths of all the features present in the feedback, plus the octet that defines the feature ID. The total length is calculated as the summation of the feature ID lengths (as defined in Table 1) plus the number of Feature IDs multiplied by one octet, which is shown in equation 1 below.

[0081]

[0082] In the alternate solution, the Total length is determined by the summation of length fields that follow the ID field +Num feature ID*1octet.

[0083] Table 1 entails, the feature ID mapping and the associated feedback length for each feature. The total length of feedback is derived as the summation of the lengths of the features for which feedback is present. The Block Ack (BA) bitmap subfield is modified to indicate the actual feedback information per feature. The first octet identifies the feature ID, and the length of feedback for that feature is determined based on the values specified in Table 1. Alternatively, the feedback length can be explicitly defined in a field following the feature ID. For the specified length of the given feature ID, the per-ID feature feedback field is defined. The exact definition of this field is currently to be determined (TBD) and will be developed as the specification evolves.

[0084] An example format where an ID is followed by per ID feedback details is disclosed. For example in context of Unavailability feedback, this could include unavailability start time and duration. It also can include some reserved fields which could be defined per ID. In another alternative of the solution, the length is included in the 4 remaining bits of the ID field. This gives even more optimal and flexible design to only include those fields that are required. The length mapping is defined as Number of octets = 2^ (length value). The following number of octets will be the actual feedback.

[0085] The present disclosure under discussion requires that, before a TXOP, an AP should request unavailability information using the ICF-ICR mechanism. However, various scenarios must be addressed, such as when the unavailability information has changed and needs to be updated, when it has not changed since the last update, when the unavailability duration is unavailable, or when the unavailability start time is unknown. To accommodate these scenarios, the ICF-ICR framework should include fields within the message that can indicate the presence of the field / information and include relevant fields. A proposed design for the framework introduces flexibility in the ICR message, allowing the presence and associated values to be updated as needed. To illustrate this framework, unavailability information is used as an example, as the specification has progressed to define its values, making it a useful reference for better understanding the proposed design.

[0086] The present disclosure discloses the AP soliciting unavailability information through an Initial Control Frame (ICF), and the non-AP STA responds with an Initial Control Response (ICR) providing the start time and unavailability duration. In the first scenario, the AP limits transmission and concludes the TXOP before the indicated unavailability start time. In the second scenario, the unavailability occurs much later, after the initial TXOP. As per the agreed motions, whenever the non-AP STA operates in Dynamic Unavailability Operation (DUO) mode, the AP must solicit updated unavailability information via an ICF before the next TXOP begins. If the non-AP STA identifies another unavailability period with a known start time and duration, it includes this updated information in the ICR.

[0087] From these use cases, several requirements for the ICR can be derived to accommodate updates to the unavailability start time and duration. The ICR should include a field to indicate that the unavailability information has been updated. It should also have a presence field to specify whether the unavailability start time and / or duration has been updated. Additionally, the ICR must contain the new start time and the new duration of unavailability. Furthermore, the ICR should be capable of indicating all valid start times and durations of unavailability known to the non-AP STA.

[0088] Another scenario is disclosed where AP solicits unavailability information through an Initial Control Frame (ICF), and the non-AP STA responds with an Initial Control Response (ICR), providing the start time and unavailability duration. In one case, the AP limits its transmission and concludes the TXOP before the unavailability start time, as indicated in the first ICR. In contrast, in another case, the unavailability start time occurs much later, after the TXOP limit ends. As per the agreed motions, when the non-AP STA operates in Dynamic Unavailability Operation (DUO) mode, the AP must solicit updated unavailability information via an ICF before the next TXOP begins. As per first case, the non-AP STA does not have any future unavailability information to update or as per second case, the non-AP STA has already indicated a future unavailability information in the previous ICR and has no further update to provide.

[0089] Analyzing these use cases, the following requirements for an ICR for the case where there is no update to the unavailability start time and duration can be derived where, ICR should contain a field to indicate that there is no update to the unavailability information. ICR should be able to validate the previous unavailability information is still valid in next transaction as well.

[0090] The AP solicits unavailability information from the non-AP STA, but the STA may not have complete information of unavailability which includes the start time and duration. The nature of this unavailability is periodic and due to multiple technologies and modules, it is possible that complete information of start time and duration is not available at all times to be indicated in an ICR.

[0091] A scenario is disclosed where in first case Start time is known, but duration is not known, however, in another case, the start time is not known, but duration is known. Further, when unavailability ends at non-AP STA, an event is generated and similarly when it starts, an event is generated at STA which can be used to indicate necessary information.

[0092] Hence considering these factors, an ICR design needs to incorporate: a presence field to indicate which of the duration or start time are indicated, a method to indicate the end of unavailability period using a polling mechanism and a method to indicate the start of unavailability using a messaging sequence.

[0093] Two variants of solutions are proposed, which aligns with the baseline framework described above. When the AP solicits unavailability information from the STA, it may not always have complete details, such as the start time and duration of the unavailability period. To address this, a Feedback Presence field is introduced. This field is 3 bits long but can be extended as needed based on the feature ID or specific requirements, with reserved bits for future use.

[0094] The Feedback Presence field includes the various sub-fields such as feedback update which is a 1-bit indicator that specifies whether feedback information is present. A value of 0 indicates no feedback, while a value of 1 indicates valid feedback. When the value is 0, the remaining bits do not need to be decoded by the AP or included in the feedback by the STA, thereby providing an efficient solution. Another sub-field is Presence Start Time which is also a 1-bit indicator that specifies whether start time information is available when the Feedback Update value is 1. A value of 1 indicates the presence of start time information, while 0 indicates otherwise. Further, Presence Duration specifies whether duration information is available when the Feedback Update value is 1. A value of 1 indicates the presence of duration information, while 0 indicates otherwise.

[0095] As per the proposed solution, a Feedback Presence field is introduced that can indicate whether unavailability information or feedback has an update and whether complete information including start time and duration is present.

[0096] This approach is disclosed, where it enables the indication of updates to unavailability information. In one scenario, the AP maintains feedback information from both reports, as the previously indicated start time has not yet occurred, and the ICRs include updates indicating the presence of two separate blocks of unavailability information. A modification is needed in this scenario, that allows AP to handle the unavailability reports from both ICRs as the Feedback update field is set and it shall indicate that both the values are valid and AP can maintain both. To manage this process, a limit can be defined for the number of reports can be used or stored by an AP or STA as per its capabilities. This value can be advertised or exchanged in Capabilities information field.

[0097] In another case, the proposed solution demonstrates an optimized approach for handling unavailability information. In the first ICR, the non-AP STA is aware of the unavailability information and shares it using the proposed Feedback Presence bits set to 111 as shown. In subsequent scenarios where there is no update to the unavailability feedback, but the AP still expects a response, the non-AP STA can indicate this by setting the Feedback Update field in the ICR to 0. Consequently, the presence fields for the start time and duration are also set to 0.

[0098] Hence when the AP receives this ICR, it need not decode the remaining fields. Henceforth, non-AP STA also shall benefit by this proposed solution as it need not encode the remaining bits as there is no useful information to be shared with AP. This shall save the airtime resources and provide a more flexible and optimal design for ICR when unavailability information is not available in subsequent sequence of operations.

[0099] There are two variant of solutions that depict the sequence to indicate the end of unavailability duration. In first variant, an existing baseline frame is used that is usually used in power save to indicate end of unavailability duration. In first case, when the AP solicits the unavailability information, the non-AP STA sends an ICR with feedback presence with presence duration set to 0 to indicate that duration is unknown or not included. Hence the AP shall now wait for a frame to indicate that unavailability period or duration is over. So when the unavailability ENDS an event generated in the non-AP STA shall trigger a PS-Poll frame that indicates end of unavailability.

[0100] Alternatively in second variant, a new message is introduced that shall perform the same function as explained above, but a new message is introduced for the same. As shown in this example, it can be called as Dynamic unavailability operation(DUO)-END to indicate end of unavailability duration. The frame format of DUO-END will be explained subsequently. DUO-END can be a Control or Action Frame format.

[0101] Furthermore, a message sequence introducing a new message to indicate the start of a dynamic unavailability event as it occurs, is disclosed. In this scenario, the duration of unavailability has already been communicated in a previous ICR, which can assist in determining the start time of the unavailability. The Feedback Presence bits in the ICR indicate the absence of the start time.

[0102] When this situation arises, the AP can wait for a message from the non-AP STA, such as a DUO-START, to confirm the unavailability start time and accurately determine the unavailability period. The frame format of the DUO-START message is explained subsequently and can be designed as either a control or an action frame format.

[0103] A new category value needs to be defined for UHR Action Field from the reserved values. UHR Action field values are defined in Table 3 for DUO Event Indication. DUO Event indication table is shown in Table 4 for its action details. The frame format can indicate specifically if the event is for DUO-START or DUO-END.

[0104] CodeMeaningSee SubclauseRobustGroup Addressed Privacy<<Value between 40 and 125>>Exact value is TBDUHR Action Field<<UHR subclause for action field description>>TBDTBD

[0105] UHR Action Field is shown in Table 3 below:

[0106] ValueMeaning0DUO Event Indication1 - 255Reserved - TBD

[0107] DUO Event Indication is shown in Table 4 below:

[0108] OrderMeaning1Category2UHR Action field3Dialog Token4Frame Format for DUO event indication

[0109] As an alternative to an Action Frame, a Control Frame can be used for defining DUO-START and DUO-END event frames, in order to provide solutions for the cases described in this specification. For implementing a new control frame, a new value from the reserved set is selected within the control frame extension to specify the Type and Subtype fields in the Frame Control header, as outlined in Table 5. The DUO-Event can indicate DUO-START with a value of 1 and DUO-END with a value of 2, while the remaining values are reserved for future use.

[0110] TypeB3 B2Sub TypeB7 B6 B5 B4Control Frame Extension ValueB11 B10 B9 B8Description010110<< TBD value from 1100- 1111>DUO-Event

[0111] Disclosed herein is a method and a system for indicating feedback in an Initial Control Response (ICR) frame in IEEE 802.11 based network. Existing approaches for handling in-device coexistence in IEEE 802.11 networks rely on repurposing fields in Multi-STA Block Acknowledgement (M-STA BA) frames to convey feedback. However, these methods lack flexibility and scalability―they do not support multiple types of feedback, cannot efficiently handle partial or missing information (such as unknown start time or duration), and offer limited mechanisms to indicate whether feedback has been updated. This leads to inefficiencies in communication and suboptimal resource utilization during transmission opportunities.

[0112] To solve the above problem, the present disclosure discloses a method and a system for indicating feedback in an Initial Control Response (ICR) frame in IEEE 802.11 based network. In the present disclosure, a structured and extensible format for the Initial Control Response (ICR) frame is introduced. The ICR frame enables the inclusion of multiple types of feedback using feature specific identifiers and length indicators. Particularly, a field corresponding to a feedback presence indicator is included in the ICR frame, which allows efficient signalling of whether feedback information is updated and whether the feedback information is missing. Therefore, the proposed ICR frame structure reduces unnecessary overhead, improves responsiveness to dynamic coexistence conditions, and optimizes airtime usage in wireless networks.

[0113] In the following detailed description of the embodiments of the disclosure, reference is made to the accompanying drawings that form a part hereof, and in which are shown by way of illustration specific embodiments in which the disclosure may be practiced. These embodiments are described in sufficient detail to enable those skilled in the art to practice the disclosure, and it is to be understood that other embodiments may be utilized and that changes may be made without departing from the scope of the present disclosure. The following description is, therefore, not to be taken in a limiting sense.

[0114] Fig. 1 shows an exemplary environment for indicating feedback in an Initial Control Response (ICR) frame in IEEE 802.11 based network, in accordance with some embodiments of the present disclosure.

[0115] Fig.1 shows an environment 100 for transmitting an Initial Control Response (ICR) frame from a station (STA) device to a peer STA device. As shown, the environment 100 includes an STA device 102, an Access Point (AP) 1041, a Virtual Reality (VR) headset 1042, a smart watch 1043, and earbuds 1044collectively referred as the plurality of peer STA devices 104. A person skilled in art may understand that for illustration purposes only four peer STA devices are shown in Fig. 1. In an embodiment, the STA device 102 may correspond to a User Equipment (UE) of a user. The UE may communicate with the AP 1041that operates in predefined frequencies. The VR headset 1042and the smart watch 1043may be connected to the UE over a Wi-Fi direct or Bluetooth over 2.4 Ghz frequency or 5 Ghz channels., Similarly, the earbuds 1044may be connected over Bluetooth that operate through 2.4 Ghz channels. A person skilled will appreciate that the peer STA devices 104 may connect with the STA device 102 via any of the IEEE 802.11 based network. In an embodiment, one of the peer STA device from the plurality of peer STA devices 104 may send an Initial Control Frame (ICF) to the STA device 102 to solicit feedback information. The feedback information may relate to availability or operational constraints of the STA device 102. The ICF may act as a trigger, prompting the STA device 102 to respond with an Initial Control Response (ICR) frame that includes relevant feedback information. According to the IEEE 802.11 standards, Buffer Status Report Poll (BSRP) Trigger Frame (TF) may be utilized as the ICF and Multi-STA Block Ack (M-STA-BA) may be utilized as the ICR frame.

[0116] According to the present disclosure, upon receiving the ICF from the peer STA device 1041, the STA device 102 may be configured to generate the ICR frame which comprises of a block acknowledgement starting sequence control field and a block acknowledgement bitmap field. The block acknowledgement starting sequence control field further comprises a total number of feature Identifiers (IDs) and a total length of one or more feedback. The block acknowledgement bitmap field further comprises a feature ID, a feedback presence indicator, length of per ID feedback, and per ID feedback, for each of one or more features. The per ID feedback furthermore comprises the one or more feedback. The one or more features may correspond to various types of feedback that may be sent in the ICR frame. In an embodiment, the features may include but are not limited to, In-Device Coexistence (IDC) mode, Code-Division Multiple Access (C-TDMA) operation mode, power save mode, Non-Primary Channel Access (NPCA) / Dynamic Sub-channel Operation (DSO) mode, and the like.

[0117] The feedback presence indicator comprises a feedback update indicator indicating one of: a presence or absence, of an update in the one or more feedback, and the feedback presence indicator further comprising one or more fields indicating one of, a presence or an absence of feedback information in the corresponding one or more feedback. In an embodiment, when the feedback update indicator indicates the absence of the update in the one or more feedback, the one or more fields are indicative of absence of the feedback information in the corresponding one or more feedback. Therefore, when the ICR frame is received by the peer STA device 1041, the ICR frame is decoded to determine the value in the feedback update indicator field. Based on the value in the feedback update indicator field, the remaining one or more fields are decoded. In an embodiment, when the feedback update indicator field indicates the absence of the update in the one or more feedback (denoted by value 0), the remaining one or more fields are not decoded. In an embodiment, when the feedback update indicator field indicates the presence of the update in the one or more feedback (denoted by value 1), the one or more fields are indicative of one of, the presence of the feedback information in the corresponding one or more feedback, or the absence of the feedback information in the corresponding one or more feedback. In this embodiment, though the feedback update indicator indicates the presence of the update in the one or more feedback, there is a possibility that one of the one or more fields are indicative of absence of the feedback information. In such cases, the STA device 102 further transmits one of, a control frame or an action frame, to the peer STA device 1041. The control frame or the action frame comprises of a signal indicating an event corresponding to a feature of the one or more features. The event is associated with the feedback information which was absent in the ICR frame. In an embodiment, the STA device 102 transmits one of, the control frame or the action frame upon transmitting the ICR frame to the peer STA device 1041. Therefore, when the feedback update indicator within the ICR frame signifies the absence of the update in the one or more feedback fields, the peer STA device 1041may refrain from decoding the remaining bits of the feedback fields associated with the given feature. This selective decoding mechanism advantageously reduces processing overhead and conserves airtime resources, thereby enhancing overall communication efficiency within the wireless network.

[0118] Fig. 2 shows a detailed block diagram of a STA device in an IEEE 802.11 based network, in accordance with some embodiments of the present disclosure.

[0119] Fig. 2 shows internal architecture of the STA device 102 in accordance with some embodiments of the present disclosure. The STA device 102 may include at least one Central Processing Unit ("CPU" or "processor") 112 and a memory 110 storing instructions executable by the at least one processor 112. The processor 112 may comprise at least one data processor for executing program components for executing user or system-generated requests. The memory 110 is communicatively coupled to the processor 112. The STA device 102 further comprises an Input / Output (I / O) interface 108. The I / O interface 108 is coupled with the processor 112 through which an input signal or / and an output signal is communicated.

[0120] In some implementations, the STA device 102 may include data 200 and modules 202. As an example, the data 200 may be stored within the memory 110 associated with the STA device 102. In some embodiments, data 200 may include, for example, received data 204, transmission data 206 and other data 208. In some embodiments, the data 200 may be stored in the memory 110 in form of various data structures. The STA device 102 may include more or less modules, and the illustrated modules must not be considered as a limitation.

[0121] The received data 204 comprises the ICF sent by the peer STA device to solicit feedback information from the STA device 102.

[0122] The transmission data 206 comprises the ICR frame with various fields with some fields being specific to the said feedback feature. The transmission data 206 further comprise of the control frame or the action frame which are transmitted when the one of the one or more fields under the feedback presence indicator, are indicative of the absence of the feedback information.

[0123] The other data 208 may be stored data, including temporary data and temporary files, generated by the modules 202 for performing the various functions of the STA device 102.

[0124] In an embodiment, the data 200 in the memory 110 are processed by the one or more modules 202 present within the memory 110 of the STA device 102.

[0125] One or more modules 202 along with the data 200, functions to indicate feedback in the ICR frame in IEEE 802.11 network. In one implementation, the one or more modules 202 may include, but are not limited to, a receiving module 210, a generating module 212, a transmitting module 214 and one or more other modules 216.

[0126] In an embodiment, the one or more modules 202 may be implemented as dedicated units. As used herein, the term module refers to an application specific integrated circuit (ASIC), an electronic circuit, a field-programmable gate arrays (FPGA), Programmable System-on-Chip　 (PSoC), a combinational logic circuit, and / or other suitable components that provide the described functionality. In some implementations, the one or more modules 202 may be communicatively coupled to the processor 112 for performing one or more functions of the STA device 102. The said modules 202 when configured with the functionality defined in the present disclosure will result in a novel hardware.

[0127] In an embodiment, the receiving module 210 may be configured to receive the ICF from the peer STA device 1041. In an embodiment, the ICF may be stored as received data 204.

[0128] In an embodiment, the generating module 212 may be configured to generate the ICR frame in response to receiving the ICF frame. In an embodiment, the generating module 212 may generate the ICR frame in a M-STA BA frame format.

[0129] Fig. 3 shows a M-STA BA frame format as per existing specification. As seen from the figure, the BA Control field has the BA Type field set to M-STA BA. Further, the BA information has Per AID TID Info filed which further comprises of AID TID Info field (which has AID11, Ack Type, TID), BA Starting Sequence Control field (which has Fragment number and Starting sequence) and the BA Bitmap field. The Fragment number identifies the length of the BA bitmap for Block Ack purposes.

[0130] Fig. 4 shows a modified M-STA BA frame format, in accordance with some embodiments of the present disclosure. The generating module 212 may generate the ICR frame as shown in Fig. 4. Particularly, as seen from the figure, the Per AID TID Info field is modified. The BA Starting Sequence Control field and the BA Bitmap field are specifically modified as shown in the figure. Particularly, the BA Starting Sequence Control field is modified to encode the total number of feature identifiers (IDs) and the total length of the one or more feedback associated with the respective features. The BA Bitmap field is further restructured to include, for each feature, a feature ID field and a corresponding per ID feedback field. In an embodiment, the feature ID field indicates a feature of the one or more features that correspond to a specific type of feedback. Further, the per ID feedback field indicates the feedback information which is defined per the said feature. This arrangement enables the transmission of multiple types of feedback in a compact and extensible format, allowing each feature-specific feedback to be parsed based on its identifier and length. Such a design facilitates efficient feedback signalling while maintaining compatibility with existing frame structures.

[0131] Fig. 5a shows a first variant of a modified M-STA BA frame format, in accordance with some embodiments of the present disclosure. The first variant of the modified M-STA BA frame format generated as the ICR frame comprises the AID TID Info field which holds two octets. Further, the number of feature IDs field holds one octet, the total length field holds four octets, and a reserved field further holds one octet. Furthermore, the feature ID field holds one octet and the one or more per ID feedback field hold a variable length depending on the number of feature IDs. Based on the feature ID field, a length of the feedback for the said feature is determined using Table 6 which defines the feature ID mapping with an associated length of feedback for the given feature.

[0132]

[0133] As seen from Table 6, the Fragment Number field within the BA Starting Sequence Control field is redefined to encode the number of feature identifiers (IDs) using specific bit mappings, with each combination representing a distinct feedback type. The remaining bits in the field are utilized to indicate the total length of the one or more feedback.

[0134] For the first variant, the total length is computed as the summation of the individual feedback lengths determined for each feature using the Table 1 and the overhead for feature identification, expressed as given in equation 2 below:

[0135]

[0136] Therefore, the total length as computed using equation (2) relies on predefined lengths for each feature as specified in Table 1. These lengths are fixed or agreed upon per feature (e.g., 3 octets for In-Device Coexistence), and the total length is computed using those known values.

[0137] Fig. 5b shows a second variant of a modified M-STA BA frame format, in accordance with some embodiments of the present disclosure. The second variant of the modified M-STA BA frame format generated as the ICR frame comprises the AID TID Info field which holds two octets. Further, the number of feature IDs field holds one octet, the total length field holds four octets, and a reserved field further holds one octet. Furthermore, the feature ID field holds one octet and the one or more per ID feedback field hold a variable length depending on the number of feature IDs. Additionally, the second variant comprises of a length field after the feature ID field. The length field is indicative of the actual size of the feedback data associated with the specific feature ID.

[0138] For the second variant, the total length is determined by summing the length fields that follow each feature ID field, along with the overhead for feature identification, expressed as:

[0139]

[0140] Therefore, the total length as computed using equation (3) does not rely on Table 1. Instead, the explicit length fields that are included in the frame itself after each feature ID are utilized. This allows for a more dynamic and flexible encoding, where the length of each feedback segment is determined at runtime rather than being fixed.

[0141] The ICR frame generated by the generating module 212 further comprises the feedback presence indicator field.

[0142] Fig. 6 shows a modified M-STA BA frame format with feedback presence indicator, in accordance with some embodiments of the present disclosure. In an embodiment, when the peer STA device 1041may solicit feedback information from the STA device 102, a possibility may occur that there may be no update in the feedback information provided previously by the STA device 102. There may be another possibility that there may be an update in the feedback information, however, a part of the feedback information may be missing. Therefore, to include the said possibilities, the generating module 212 generates the ICR frame which provisions to include three fields under the feedback presence indicator field. The first field corresponds to the feedback update indicator field indicating one of: the presence and absence, of the update in the one or more feedback. The second and third fields (also referred as one or more fields) correspond to indicate one of: the presence or the absence of feedback information in the corresponding one or more feedback of the said feature.

[0143] As seen from Fig. 6, the first and second variant of the ICR frame is shown with the feedback presence indicator field comprising of the further three fields, each holding one bit. Considering an example where the feature corresponds to IDC, then each of the three fields may comprise the following feedback information:

[0144] Feedback update indicator: a field that indicates whether the feedback information is present or not. Where, 0 indicates no update in feedback and 1 indicates an update in feedback. When the value is 0, it essentially means that the remaining bits need not be decoded by the peer STA device 1041.

[0145] Unavailability information for IDC:

[0146] Presence Start Time: a feedback field for the IDC feature that indicate whether the start time information is available when feedback update value is 1. Where, 1 indicates the presence and 0 otherwise.

[0147] Presence Duration: a feedback field for the IDC feature that indicates whether duration information is available when feedback update value is 1. Where, 1 indicates the presence and 0 otherwise.

[0148] For the ease of understanding, the following description is described for the scenario when the feature corresponds to IDC. However, this should not be construed as a limitation of the present disclosure by the person skilled in art, as the description may be applicable for any other feature apart from IDC.

[0149] Fig. 7a-7b show an exemplary scenario where unavailability information must be updated, in accordance with some embodiments of the present disclosure. In the scenario illustrated in Fig. 7a, upon receiving the ICF from the peer STA device 1041, the generating module 212 may generate the ICR frame that includes updated unavailability information. The ICR frame comprises the feedback presence indicator set as '1' to reflect the presence of valid feedback and includes fields specifying the presence start time field and the presence duration field set as '1'. The start time and the duration correspond to the feedback when the feature corresponds to IDC. Therefore, the feedback information may correspond to start time as a specific time given in seconds and the duration as a specific unavailability period indicating for how long the STA device 102 will be unavailable. This enables the peer STA device 1041to adjust its transmission schedule and terminate the transmission opportunity (TXOP) prior to the onset of the indicated unavailability information. In the scenario depicted in Fig. 7b, the STA device 102 may identify a second unavailability period in addition to the one previously reported. In response to a new ICF, the generating module 212 may generate another ICR frame with the feedback presence indicator set to indicate an update in the feedback. The ICR includes fields for the new start time and duration, which may help the peer STA device 1041to maintain both sets of feedback reports. This capability supports dynamic scheduling and ensures that the peer STA device 1041may respond to multiple, distinct unavailability periods of the STA device 102, thereby enhancing transmission reliability and resource efficiency.

[0150] Fig. 8a-8b show an exemplary scenario where unavailability information does not have an update, in accordance with some embodiments of the present disclosure. In the scenario illustrated in Fig. 8a, upon receiving the ICF from the peer STA device 1041, the generating module 212 generates the ICR frame indicating that there is no update to the previously reported unavailability information. The ICR frame includes the feedback presence indicator with the feedback update bit set to '0', and the presence bits for both start time and duration also set to '0'. This configuration allows signalling the peer STA device 1041that the previously communicated unavailability parameters remain valid and no new feedback needs to be processed, thereby conserving airtime and processing resources. In the scenario depicted in Fig. 8b, the STA device 102 may have already reported a future unavailability period in a prior ICR frame and, upon receiving a subsequent ICF by the receiving module 210, the generating module 212 may determine that no changes have occurred. Accordingly, the generating module 212 may generate the ICR frame with the feedback presence indicator set to reflect the absence of updated feedback. The peer STA device 1041, upon receiving the ICR frame, may rely on the previously stored feedback and avoid decoding or processing redundant information. This mechanism ensures efficient communication and optimal utilization of network resources when feedback remains unchanged across transmission opportunities.

[0151] Fig. 9a-9b show an exemplary scenario where duration information is missing, in accordance with some embodiments of the present disclosure. In the scenario illustrated in Fig. 9a, upon receiving the ICF by the receiving module 210, from the peer STA device 1041, the generating module 212 may generate the ICR frame that includes the feedback presence indicator. The indicator reflects that feedback is available, but the duration of unavailability is unknown. Specifically, the presence duration bit is set to '0', while the start time is provided. To signal the end of the unavailability period, the generating module 212 subsequently generates a legacy Power Save Poll (PS-Poll) frame, which serves as an implicit notification to the peer STA device 1041, indicating that the STA device 102 has become available again. This approach leverages existing frame formats to minimize signaling overhead. In the scenario depicted in Fig. 9b, the generating module 212 similarly generates the ICR frame in response to the ICF received by the receiving module 210, indicating the start time of unavailability but omitting the duration field due to lack of feedback information. Instead of relying on a legacy frame, the generating module 212 may generate a newly defined control or action frame referred to as Dynamic Unavailability Operation-End (DUO-END) frame, which explicitly signals the end of the unavailability period. This dedicated frame format provides a more robust and standardized mechanism for conveying dynamic availability changes, particularly in environments where legacy signalling may be insufficient.

[0152] Fig. 9c shows an exemplary scenario where start time information is missing, in accordance with some embodiments of the present disclosure. In the scenario illustrated in Fig. 9c, upon receiving the ICF by the receiving module 210, from the peer STA device 1041, the generating module 212 may generate the ICR frame that includes feedback indicating the duration of unavailability but omits the start time due to its unavailability at the time of reporting. The feedback presence indicator within the ICR frame is configured to reflect this partial feedback, with the presence bit for start time set to '0' and the duration bit set to '1'. To subsequently inform the peer STA device 1041of the actual onset of the unavailability period, the generating module 212 generates a dedicated control or action frame referred to as DUO-START frame. This frame explicitly signals the beginning of the unavailability event, enabling the peer STA device 1041to accurately align its transmission schedule with the dynamic availability status of the STA device 102. The use of DUO-START frame provides a reliable mechanism for conveying asynchronous availability changes when complete feedback cannot be provided upfront.

[0153] In an embodiment, the action frame generated by the generating module 212 indicates dynamic unavailability events, such as the start or end of an unavailability period.

[0154] Fig. 10a shows an exemplary action frame, in accordance with some embodiments of the present disclosure. As shown in the figure, the action frame format includes a sequence of fields: a Category field, a UHR Action field, a Dialog Token field, and a DUO Event Indication field. The Category field is assigned a reserved value within the range of 40 to 125, designated for UHR-specific actions. The UHR Action field as given in Table 7, includes a value of '0' to indicate a DUO event, with other values reserved for future use.

[0155] ValueMeaning0DUO Event Indication1-255Reserved-TBD

[0156] The DUO Event Indication field, as given in Table 8, specifies whether the frame corresponds to a DUO-START or DUO-END event. This allows the STA device 102 to explicitly signal either the beginning or the conclusion of an unavailability period.

[0157] OrderMeaning1Category2UHR Action field3Dialog Token4Frame Format for DUO Event indication

[0158] The ordering of fields within the frame is defined in Table 9. The ordering as considered in Table 9 ensures consistent interpretation by the receiving AP. This structured action frame format enables robust signalling of dynamic availability changes, supports extensibility for future event types, and enhances coordination between STA and AP in environments affected by in-device coexistence.

[0159]

[0160] Fig. 10b illustrates the internal structure of the DUO Event frame format, which is generated by the generating module 212 to signal either the start or end of a dynamic unavailability period. This frame includes bit-level indicators, B0 and B1, where a value of '1' denotes the presence of a specific field or event type. These bits may be used to distinguish between DUO-START and DUO-END events, allowing the peer STA device 1041to interpret the nature of the unavailability signal with precision. The DUO Event frame format thus provides a compact and extensible signalling mechanism that supports dynamic feedback scenarios, enabling the STA device 102 to communicate asynchronous availability changes in a standardized and efficient manner.

[0161] In another embodiment, the control frame generated by the generating module 212 may indicate dynamic unavailability events such as DUO-START and DUO-END. As shown in Table 3, the control frame format includes a Type field with bits B3-B2, a Subtype field with bits B7-B4, and a Control Frame Extension Value with bits B11-B8. The Control Frame Extension Value is selected from a reserved range corresponding to 1100-1111, to uniquely identify DUO-related events. The Description column in the table specifies that the frame is used for signalling DUO events.

[0162] Fig. 11 shows an exemplary control frame, in accordance with some embodiments of the present disclosure.

[0163] Therefore, upon receiving the ICF by the receiving module 210, from the peer STA device 1041, the generating module 212 may generate the ICR frame based on the feedback information and may further generate the action or control frame corresponding to one of, PS-Poll frame, the DUO-END frame and the DUO-START frame. As described under description of Figs. 7a-7b, 8a-8b, 9a-9c, 10a-10b, and 11, the generating module 212 may perform the generation based on the presence of feedback information. Thereafter, the generated frame is sent to the transmitting module 214.

[0164] The transmitting module 214 may receive the generated frame from the generating module 212. The transmitting module 214 may transmit the generated frame to the corresponding peer STA device 1041, which sent the ICF frame to STA device 102. In an embodiment, the transmitted frame may be stored in the transmission data 206.

[0165] Fig. 12 is a flowchart illustrating a method for managing forbidden lists of Tracking Areas (TAs) in communication networks, in accordance with some embodiments of the present disclosure.

[0166] As illustrated in Fig. 12, the method 1200 comprises one or more blocks illustrating a method of indicating feedback in an Initial Control Response (ICR) frame in IEEE 802.11 based network, in accordance with some embodiments of the present disclosure. The method 1200 may be described in the general context of computer-executable instructions. Generally, computer-executable instructions can include routines, programs, objects, components, data structures, procedures, modules, and functions, which perform functions or implement abstract data types.

[0167] The order in which the method 1200 is described is not intended to be construed as a limitation, and any number of the described method blocks can be combined in any order to implement the method 1200. Additionally, individual blocks may be deleted from the methods without departing from scope of the subject matter described herein. Furthermore, the method 400 can be implemented in any suitable hardware, software, firmware, or combination thereof.

[0168] At block 1202, the method 1200 may include receiving, by the STA device 102, the ICF from the peer STA device 1041to solicit feedback information from the STA device 102.

[0169] At block 1204, the method 1200 may include generating, by the STA device 102, the ICR frame, in response to receiving the ICF.

[0170] At block 1206, the method 1200 may include transmitting, by the STA device 102, the ICR frame, to the peer STA device 1041. The ICR frame comprises of a block acknowledgement starting sequence control field comprising a total number of feature Identifiers (IDs) and a total length of one or more feedback. The ICR frame further comprises of a block acknowledgement bitmap field comprising a feature ID, a feedback presence indicator, length of per ID feedback, and per ID feedback, for each of one or more features, wherein the per ID feedback comprises the one or more feedback.

[0171] Fig. 13 is a block diagram of an exemplary computer system for implementing embodiments consistent with the present disclosure.

[0172] In some embodiments, FIG. 13 illustrates a block diagram of an exemplary computer system 1300 for implementing embodiments consistent with the present disclosure. In some embodiments, the computer system 1300 can be the STA device 102 that comprises a processor (also referred as a processor 1302 in this FIG. 13) that is used for indicating feedback in an Initial Control Response (ICR) frame in IEEE 802.11 based network. The processor 1302 may include at least one data processor for executing program components for executing user or system-generated business processes. The processor 1302 may include specialized processing units such as integrated system (bus) controllers, memory management control units, floating point units, graphics processing units, digital signal processing units, etc.

[0173] The processor 1302 may be disposed in communication with input devices 1310 and output devices 1311 via I / O interface 1301. The I / O interface 1301 may employ communication protocols / methods such as, without limitation, audio, analog, digital, stereo, IEEE-1394, serial bus, Universal Serial Bus (USB), infrared, PS / 2, BNC, coaxial, component, composite, Digital Visual Interface (DVI), high-definition multimedia interface (HDMI), Radio Frequency (RF) antennas, S-Video, Video Graphics Array (VGA), IEEE 802.n / b / g / n / x, Bluetooth, cellular (e.g., Code-Division Multiple Access (CDMA), High-Speed Packet Access (HSPA+), Global System For Mobile Communications (GSM), Long-Term Evolution (LTE), WiMax, or the like), etc.

[0174] Using the I / O interface 1301, computer system 1300 may communicate with input devices 1310 and output devices 1311.

[0175] In some embodiments, the processor 1302 may be disposed in communication with a communication network 1309 via a network interface 1303. The network interface 1303 may communicate with the communication network 1309. The network interface 1303 may employ connection protocols including, without limitation, direct connect, Ethernet (e.g., twisted pair 10 / 100 / 1000 Base T), Transmission Control Protocol / Internet Protocol (TCP / IP), token ring, IEEE 802.11a / b / g / n / x, etc. Using the network interface 1303 and the communication network 1309, the computer system 1300 may communicate with the peer STA device 1041via the communication network 106.

[0176] The communication network 1309 can be implemented as one of the different types of networks, such as intranet or Local Area Network (LAN) and such within the organization. The communication network 1309 may either be a dedicated network or a shared network, which represents an association of the different types of networks that use a variety of protocols, for example, Hypertext Transfer Protocol (HTTP), Transmission Control Protocol / Internet Protocol (TCP / IP), Wireless Application Protocol (WAP), etc., to communicate with each other.

[0177] Further, the communication network 1309 may include a variety of network devices, including routers, bridges, servers, computing devices, storage devices, etc. In some embodiments, the processor 1302 may be disposed in communication with a memory 1305 (e.g., RAM, ROM, etc. not shown in FIG. 13) via a storage interface 1304. The storage interface 1304 may connect to memory 1305 including, without limitation, memory drives, removable disc drives, etc., employing connection protocols such as Serial Advanced Technology Attachment (SATA), Integrated Drive Electronics (IDE), IEEE-1394, Universal Serial Bus (USB), fibre channel, Small Computer Systems Interface (SCSI), etc. The memory drives may further include a drum, magnetic disc drive, magneto-optical drive, optical drive, Redundant Array of Independent Discs (RAID), solid-state memory devices, solid-state drives, etc.

[0178] The memory 1305 may store a collection of program or database components, including, without limitation, a user interface 1306, an operating system 1307, a web browser 1308 etc. In some embodiments, the computer system　1300 may store user / application data, such as the data, variables, records, etc. as described in this invention. Such databases may be implemented as fault-tolerant, relational, scalable, secure databases such as Oracle or Sybase.

[0179] Operating system　1307　may facilitate resource management and operation of computer system　1300. Examples of operating systems include, without limitation, APPLE®MACINTOSH®OS X®, UNIX®, UNIX-like system distributions (E.G., BERKELEY SOFTWARE DISTRIBUTION®(BSD), FREEBSD®, NETBSD®, OPENBSD, etc.), LINUX®DISTRIBUTIONS (E.G., RED HAT®, UBUNTU®, KUBUNTU®, etc.), IBM®OS / 2®, MICROSOFT®WINDOWS®(XP®, VISTA® / 7 / 8, 10 etc.), APPLE®IOS®, GOOGLETMANDROIDTM, BLACKBERRY®OS, or the like. User interface　1306　may facilitate display, execution, interaction, manipulation, or operation of program components through textual or graphical facilities. For example, user interfaces may provide computer interaction interface elements on a display system operatively connected to computer system　1300, such as cursors, icons, check boxes, menus, scrollers, windows, widgets, etc. Graphical User Interfaces (GUIs) may be employed, including, without limitation, Apple®Macintosh®operating systems' Aqua®, IBM®OS / 2®, Microsoft®Windows®(e.g., Aero, Metro, etc.), web interface libraries (e.g., ActiveX®, Java®,　Javascript®, AJAX, HTML, Adobe®Flash®, etc.), or the like.

[0180] The computer system　1300　may implement web browser　1308　stored program components. Web browser　1308　may be a hypertext viewing application, such as MICROSOFT®INTERNET EXPLORER®, GOOGLETMCHROMETM, MOZILLA®FIREFOX®, APPLE®SAFARI®, etc. Secure web browsing may be provided using Secure Hypertext Transport Protocol (HTTPS), Secure Sockets Layer (SSL), Transport Layer Security (TLS), etc. Web browsers 1308 may utilize facilities such as AJAX, DHTML, ADOBE®FLASH®, JAVASCRIPT®, JAVA®, Application Programming Interfaces (APIs), etc. The computer system 1300　may implement a mail server stored program component. The mail server may be an Internet mail server such as Microsoft Exchange, or the like. The mail server may utilize facilities such as ASP, ACTIVEX®, ANSI®C++ / C#, MICROSOFT®,. NET, CGI SCRIPTS, JAVA®, JAVASCRIPT®, PERL®, PHP, PYTHON®, WEBOBJECTS®, etc. The mail server may utilize communication protocols such as Internet Message Access Protocol (IMAP), Messaging Application Programming Interface (MAPI), MICROSOFT®exchange, Post Office Protocol (POP), Simple Mail Transfer Protocol (SMTP), or the like. In some embodiments, the computer system 1300 may implement a mail client stored program component. The mail client may be a mail viewing application, such as APPLE®MAIL, MICROSOFT®ENTOURAGE®, MICROSOFT®OUTLOOK®, MOZILLA®THUNDERBIRD®, etc.

[0181] Furthermore, one or more computer-readable storage media may be utilized in implementing embodiments consistent with the present invention. A computer-readable storage medium refers to any type of physical memory on which information or data readable by a processor may be stored. Thus, a computer-readable storage medium may store instructions for execution by one or more processors, including instructions for causing the processor(s) to perform steps or stages consistent with the embodiments described herein. The term "computer-readable medium" should be understood to include tangible items and exclude carrier waves and transient signals, i.e., non-transitory. Examples include Random Access Memory (RAM), Read-Only Memory (ROM), volatile memory, non-volatile memory, hard drives, Compact Disc (CD) ROMs, Digital Video Disc (DVDs), flash drives, disks, and any other known physical storage media.

[0182] An embodiment of the present disclosure discloses a method and a system for indicating feedback in an Initial Control Response (ICR) frame in IEEE 802.11 based network. In the present disclosure, a structured and extensible format for the Initial Control Response (ICR) frame is introduced. The ICR frame enables the inclusion of multiple types of feedback using feature specific identifiers and length indicators. Particularly, a field corresponding to a feedback presence indicator is included in the ICR frame, which allows efficient signalling of whether feedback information is updated and whether the feedback information is missing. Therefore, the proposed ICR frame structure reduces unnecessary overhead, improves responsiveness to dynamic coexistence conditions, and optimizes airtime usage in wireless networks.

[0183] Equivalents:

[0184] A description of an embodiment with several components in communication with each other does not imply that all such components are required. On the contrary a variety of optional components are described to illustrate the wide variety of possible embodiments of the invention. When a single device or article is described herein, it will be apparent that more than one device / article (whether or not they cooperate) may be used in place of a single device / article. Similarly, where more than one device or article is described herein (whether or not they cooperate), it will be apparent that a single device / article may be used in place of the more than one device or article, or a different number of devices / articles　may be used instead of the shown number of devices or programs. The functionality and / or the features of a device may be alternatively embodied by one or more other devices which are not explicitly described as having such functionality / features. Thus, other embodiments of the invention need not include the device itself.

[0185] The embodiments described herein are non-limiting. Such embodiments can be combined in various combinations, although such combinations are not explicitly described a person skilled will appreciate possibility of such combinations.

[0186] The specification has described a system and a method for performing edge federation in the federated network. The illustrated steps are set out to explain the exemplary embodiments shown, and it should be anticipated that on-going technological development will change the manner in which particular functions are performed. These examples are presented herein for purposes of illustration, and not limitation. Further, the boundaries of the functional building blocks have been arbitrarily defined herein for the convenience of the description. Alternative boundaries can be defined so long as the specified functions and relationships thereof are appropriately performed. Alternatives (including equivalents, extensions, variations, deviations, etc., of those described herein) will be apparent to persons skilled in the relevant art(s) based on the teachings contained herein. Such alternatives fall within the scope and spirit of the disclosed embodiments. Also, the words "comprising," "having," "containing," and "including," and other similar forms are intended to be equivalent in meaning and be open-ended in that an item or items following any one of these words is not meant to be an exhaustive listing of such item or items or meant to be limited to only the listed item or items. It must also be noted that as used herein and in the appended claims, the singular forms "a," "an," and "the" include plural references unless the context clearly dictates otherwise.

[0187] Finally, the language used in the specification has been principally selected for readability and instructional purposes, and it may not have been selected to delineate or circumscribe the inventive subject matter. It is therefore intended that the scope of the invention be limited not by this detailed description, but rather by any claims that issue on an application based here on. Accordingly, the embodiments of the present invention are intended to be illustrative, but not limiting, of the scope of the invention, which is set forth in the following claims.

Claims

1.A method performed by a station (STA) device in wireless network, the method comprising:transmitting an Initial Control Response (ICR) frame to a peer STA device;wherein the ICR frame comprises:a block acknowledgement starting sequence control field comprising a total number of feature Identifiers (IDs) and a total length of one or more feedbacks; anda block acknowledgement bitmap field comprising a feature ID, a feedback presence indicator, length of per ID feedback, and per ID feedback, for each of one or more features, wherein the per ID feedback comprises the one or more feedbacks.2.The method of claim 1, wherein the ICR frame is transmitted in response to receiving an Initial Control Frame (ICF) from the peer STA device.3.The method of claim 1, wherein the feedback presence indicator comprises:a feedback update indicator indicating one of: a presence and absence, of an update in the one or more feedbacks, andone or more fields indicating one of: a presence or an absence of feedback information in the corresponding one or more feedbacks.4.The method of claim 3, wherein when the feedback update indicator indicates the presence of the update in the one or more feedbacks, the one or more fields are indicative of one of:the presence of the feedback information in the corresponding one or more feedbacks, orthe absence of the feedback information in the corresponding one or more feedbacks.5.The method of claim 3 or 4, further comprises:transmitting to the peer STA device, one of, a control frame or an action frame, comprising a signal indicating an event corresponding to a feature of one or more features, when one of the one or more fields are indicative of the absence of the feedback information.6.The method of claim 5, wherein one of, the control frame or the action frame is transmitted upon transmitting the ICR frame to the peer STA device.7.A station (STA) device in wireless network, comprising:a transceiver;memory including one or more storage media storing instructions; andat least one processor, comprising processing circuit, configured to operably coupled to the transceiver and the memory, wherein at least one processor configured to:transmit an Initial Control Response (ICR) frame to a peer STA device,wherein the ICR frame comprises:a block acknowledgement starting sequence control field comprising a total number of feature Identifiers (IDs) and a total length of one or more feedbacks; anda block acknowledgement bitmap field comprising a feature ID, a feedback presence indicator, length of per ID feedback, and per ID feedback, for each of one or more features, wherein the per ID feedback comprises the one or more feedbacks.8.The STA device of claim 7, wherein at least one processor is configured to transmit the ICR frame in response to receiving an Initial Control frame (ICF) from the peer STA device.9.The STA device of claim 7, wherein the feedback presence indicator comprises:a feedback update indicator indicating one of: a presence and absence, of an update in the one or more feedbacks, andone or more fields indicating one of: a presence or an absence of feedback information in the corresponding one or more feedbacks.10.The STA device of claim 9, wherein when the feedback update indicator indicates the presence of the update in the one or more feedbacks, the one or more fields are indicative of one of:the presence of the feedback information in the corresponding one or more feedbacks, orthe absence of the feedback information in the corresponding one or more feedbacks.11.The STA device of claim 9 or 10, wherein at least one processor is configured to:transmit, to the peer STA device, one of, a control frame or an action frame, comprising a signal indicating an event corresponding to a feature of one or more features, when one of the one or more fields is indicative of the absence of the feedback information.12.The STA device of claim 11, wherein at least one processor is configured to:transmit one of, the control frame or the action frame upon transmitting the ICR frame to the peer STA device.13.A method performed by a station (STA) device in wireless network, the method comprising:transmitting an Initial Control Frame (ICF) to a peer STA device; andin response to the ICF, receiving Initial Control Response (ICR) frame from the peer STA device;wherein the ICR frame comprises:a block acknowledgement starting sequence control field comprising a total number of feature Identifiers (IDs) and a total length of one or more feedbacks; anda block acknowledgement bitmap field comprising a feature ID, a feedback presence indicator, length of per ID feedback, and per ID feedback, for each of one or more features, wherein the per ID feedback comprises the one or more feedbacks.14.A station (STA) device in wireless network, comprising:a transceiver;memory including one or more storage media storing instructions; andat least one processor, comprising processing circuit, configured to operably coupled to the transceiver and the memory, wherein at least processor configured to:transmit an Initial Control Frame (ICF) to a peer STA device; andin response to the ICF, receive Initial Control Response (ICR) frame from the peer STA device;wherein the ICR frame comprises:a block acknowledgement starting sequence control field comprising a total number of feature Identifiers (IDs) and a total length of one or more feedbacks; anda block acknowledgement bitmap field comprising a feature ID, a feedback presence indicator, length of per ID feedback, and per ID feedback, for each of one or more features, wherein the per ID feedback comprises the one or more feedbacks.

Images