Target wake time (TWT) context transfer for seamless rooming

Abstract

A station (STA) receives from a first access point (AP) a first frame indicating a target wake time (TWT) service period (SP) for the STA. The STA transmits to the first AP a second frame comprising: a first indication of a transition from the first AP to a second AP; and a second indication of whether the STA accepts modification of the TWT SP after transitioning from the first AP to the second AP. The STA receives from the first AP a third frame in response to the second frame. In another aspect, the STA transmits to the first AP a first frame a first list of streams, established between the STA and the first AP, for which the STA requests resource prioritization from the second AP. The STA receives from the first AP a second frame indicating a second list of streams that are accepted by the second AP.

Description

Docket No.: 24-3050PCTTARGET WAKE TIME (TWT) CONTEXT TRANSFER FOR SEAMLESS ROOMING CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims the benefit of U.S. Provisional Application No. 63 / 716,796, filed November6, 2024, which is hereby incorporated by reference in its entirety.BRIEF DESCRIPTION OF THE DRAWINGS

[0002] Examples of several of the various embodiments of the present disclosure are described herein with reference to the drawings.

[0003] FIG. 1 illustrates example wireless communication networks in which embodiments of the present disclosure may be implemented.

[0004] FIG. 2 is a block diagram illustrating example implementations of a station (STA) and an access point (AP).

[0005] FIG. 3 illustrates an example of target wake time (TWT) operation.

[0006] FIG. 4 illustrates an example of TWT operation in an environment including an AP multi-link device (AP MLD) and a station multi-link device (STA MLD).

[0007] FIG. 5 illustrates an example TWT element which may be used to support individual TWT operation.

[0008] FIG. 6 illustrates an example TWT element which may be used to support restricted TWT (r-TWT) operation.

[0009] FIG. 7 illustrates an example of individual TWT operation.

[0010] FIG. 8 illustrates an example of broadcast TWT operation.

[0011] FIG. 9 illustrates an example of TWT protection in individual TWT operation.

[0012] FIG. 10 illustrates an example of a STA roaming from a first AP to a second AP.

[0013] FIG. 11 illustrates an example of the Fast Session Transfer protocol using the Over-the-DS method.

[0014] FIG. 12 illustrates an example of a procedure of session transfer via roaming.

[0015] FIG. 13 illustrates an example of a roaming procedure according to an embodiment.

[0016] FIG. 14 illustrates an example of another roaming procedure according to an embodiment.

[0017] FIG. 15 illustrate an example of another roaming procedure according to an embodiment.

[0018] FIG. 16 illustrates an example of another roaming procedure according to an embodiment.

[0019] FIG. 17 illustrates an example process according to an embodiment.

[0020] FIG. 18 illustrates an example process according to an embodiment.

[0021] FIG. 19 illustrates an example process according to an embodiment.DETAILED DESCRIPTION

[0022] In the present disclosure, various embodiments are presented as examples of how the disclosed techniques may be implemented and / or how the disclosed techniques may be practiced in environments and scenarios. It will be apparent to persons skilled in the relevant art that various changes in form and detail can be made therein without departing from the scope. After reading the description, it will be apparent to oneDocket No.: 24-3050PCT skilled in the relevant art how to implement alternative embodiments. The present embodiments may not be limited by any of the described exemplary embodiments. The embodiments of the present disclosure will be described with reference to the accompanying drawings. Limitations, features, and / or elements from the disclosed example embodiments may be combined to create further embodiments within the scope of the disclosure. Any figures which highlight the functionality and advantages, are presented for example purposes only. The disclosed architecture is sufficiently flexible and configurable, such that it may be utilized in ways other than that shown. For example, the actions listed in any flowchart may be re-ordered or only optionally used in some embodiments.

[0023] Embodiments may be configured to operate as needed. The disclosed mechanism may be performed when certain criteria are met, for example, in a station, an access point, a radio environment, a network, a combination of the above, and / or the like. Example criteria may be based, at least in part, on for example, wireless device or network node configurations, traffic load, initial system set up, packet sizes, traffic characteristics, a combination of the above, and / or the like. When the one or more criteria are met, various example embodiments may be applied. Therefore, it may be possible to implement example embodiments that selectively implement disclosed protocols.

[0024] In this disclosure, "a” and “an” and similar phrases are to be interpreted as “at least one” and “one or more.” Similarly, any term that ends with the suffix “(s)” is to be interpreted as “at least one” and “one or more.” In this disclosure, the term “may” is to be interpreted as “may, for example.” In other words, the term “may” is indicative that the phrase following the term “may” is an example of one of a multitude of suitable possibilities that may, or may not, be employed by one or more of the various embodiments. The terms “comprises” and “consists of’, as used herein, enumerate one or more components of the element being described. The term “comprises” is interchangeable with “includes” and does not exclude unenumerated components from being included in the element being described. By contrast, “consists of' provides a complete enumeration of the one or more components of the element being described. The term “based on”, as used herein, may be interpreted as “based at least in part on” rather than, for example, “based solely on”. The term “and / or” as used herein represents any possible combination of enumerated elements. For example, “A, B, and / or C” may represent A; B; C; A and B; A and C; B and C; or A, B, and C.

[0025] If A and B are sets and every element of A is an element of B, A is called a subset of B. In this specification, only non-empty sets and subsets are considered. For example, possible subsets of B = {STA1 , STA2] are: {STA1}, {STA2}, and {STA1 , STA2}. The phrase “based on” (or equally “based at least on”) is indicative that the phrase following the term “based on” is an example of one of a multitude of suitable possibilities that may, or may not, be employed to one or more of the various embodiments. The phrase “in response to” (or equally “in response at least to”) is indicative that the phrase following the phrase “in response to” is an example of one of a multitude of suitable possibilities that may, or may not, be employed to one or more of the various embodiments. The phrase “depending on” (or equally “depending at least to”)Docket No.: 24-3050PCT is indicative that the phrase following the phrase “depending on" is an example of one of a multitude of suitable possibilities that may, or may not, be employed to one or more of the various embodiments. The phrase “employing / using” (or equally “employing / using at least”) is indicative that the phrase following the phrase “employing / using” is an example of one of a multitude of suitable possibilities that may, or may not, be employed to one or more of the various embodiments.

[0026] The term configured may relate to the capacity of a device whether the device is in an operational or non-operational state. Configured may refer to specific settings in a device that effect the operational characteristics of the device whether the device is in an operational or non-operational state. In other words, the hardware, software, firmware, registers, memory values, and / or the like may be “configured” within a device, whether the device is in an operational or nonoperational state, to provide the device with specific characteristics. Terms such as “a control message to cause in a device” may mean that a control message has parameters that may be used to configure specific characteristics or may be used to implement certain actions in the device, whether the device is in an operational or non-operational state.

[0027] In this disclosure, parameters (or equally called, fields, or Information elements: lEs) may comprise one or more information objects, and an information object may comprise one or more other objects. For example, if parameter (IE) N comprises parameter (IE) M, and parameter (IE) M comprises parameter (IE) K, and parameter (IE) K comprises parameter (information element) J. Then, for example, N comprises K, and N comprises J. In an example embodiment, when one or more messages / frames comprise a plurality of parameters, it implies that a parameter in the plurality of parameters is in at least one of the one or more messages / frames but does not have to be in each of the one or more messages / frames.

[0028] Many features presented are described as being optional through the use of “may” or the use of parentheses. For the sake of brevity and legibility, the present disclosure does not explicitly recite each and every permutation that may be obtained by choosing from the set of optional features. The present disclosure is to be interpreted as explicitly disclosing all such permutations. For example, a system described as having three optional features may be embodied in seven ways, namely with just one of the three possible features, with any two of the three possible features or with three of the three possible features.

[0029] Many of the elements described in the disclosed embodiments may be implemented as modules. A module is defined here as an element that performs a defined function and has a defined interface to other elements. The modules described in this disclosure may be implemented in hardware, software in combination with hardware, firmware, wetware (e.g. hardware with a biological element) or a combination thereof, which may be behaviorally equivalent. For example, modules may be implemented as a software routine written in a computer language configured to be executed by a hardware machine (such as C, C++, Fortran, Java, Basic, Matlab or the like) or a modeling / simulation program such as Simulink, Stateflow, GNU Octave, or LabVIEWMathScript. It may be possible to implement modules using physical hardware that incorporates discrete or programmable analog, digital and / or quantum hardware. Examples of programmableDocket No.: 24-3050PCT hardware comprise: computers, microcontrollers, microprocessors, application-specific integrated circuits (ASICs); field programmable gate arrays (FPGAs); and complex programmable logic devices (CPLDs). Computers, microcontrollers and microprocessors are programmed using languages such as assembly, C, C++ or the like. FPGAs, ASICs and CPLDs are often programmed using hardware description languages (HDL) such as VHSIC hardware description language (VHDL) or Verilog that configure connections between internal hardware modules with lesser functionality on a programmable device. The mentioned technologies are often used in combination to achieve the result of a functional module.

[0030] FIG. 1 illustrates example wireless communication networks in which embodiments of the present disclosure may be implemented.

[0031] As shown in FIG. 1 , the example wireless communication networks may include an Institute of Electrical and Electronic Engineers (IEEE) 802.11 (WLAN) infra-structure network 102. WLAN infra-structure network 102 may include one or more basic service sets (BSSs) 110 and 120 and a distribution system (DS) 130.

[0032] BSS 110-1 and 110-2 each includes a set of an access point (AP or AP STA) and at least one station (STA or non-AP STA). For example, BSS 110-1 includes an AP 104-1 and a STA 106-1 , and BSS 1 10-2 includes an AP 104-2 and STAs 106-2 and 106-3. The AP and the at least one STA in a BSS perform an association procedure to communicate with each other.

[0033] DS 130 may be configured to connect BSS 110-1 and BSS 110-2. As such, DS 130 may enable an extended service set (ESS) 150. Within ESS 150, APs 104-1 and 104-2 are connected via DS 130 and may have the same service set identification (SSID).

[0034] WLAN infra-structure network 102 may be coupled to one or more external networks. For example, as shown in FIG. 1 , WLAN infra-structure network 102 may be connected to another network 108 (e.g., 802.X) via a portal 140. Portal 140 may function as a bridge connecting DS 130 of WLAN infra-structure network 102 with the other network 108.

[0035] The example wireless communication networks illustrated in FIG. 1 may further include one or more ad-hoc networks or independent BSSs (IBSSs). An ad-hoc network or IBSS is a network that includes a plurality of STAs that are within communication range of each other. The plurality of STAs are configured so that they may communicate with each other using direct peer-to-peer communication (i.e., not via an AP).

[0036] For example, in FIG. 1 , STAs 106-4, 106-5, and 106-6 may be configured to form a first IBSS 112- 1 . Similarly, STAs 106-7 and 106-8 may be configured to form a second IBSS 112-2. Since an IBSS does not include an AP, it does not include a centralized management entity. Rather, STAs within an IBSS are managed in a distributed manner. STAs forming an IBSS may be fixed or mobile.

[0037] A STA as a predetermined functional medium may include a medium access control (MAC) layer that complies with an IEEE 802.11 standard. A physical layer interface for a radio medium may be used among the APs and the non-AP stations (STAs). The STA may also be referred to using various other terms,Docket No.: 24-3050PCT including mobile terminal, wireless device, wireless transmit / receive unit (WTRU), user equipment (UE), mobile station (MS), mobile subscriber unit, or user. For example, the term "user" may be used to denote a STA participating in uplink Multi-user Multiple Input, Multiple Output (MU MIMO) and / or uplink Orthogonal Frequency Division Multiple Access (OFDMA) transmission.

[0038] A physical layer (PHY) protocol data unit (PPDU) may be a composite structure that includes a PHY preamble and a payload in the form of a PHY service data unit (PSDU). For example, the PSDU may include a PHY preamble and header and / or one or more MAC protocol data units (MPDUs). The information provided in the PHY preamble may be used by a receiving device to decode the subsequent data in the PSDU. In instances in which PPDUs are transmitted over a bonded channel (channel formed through channel bonding), the preamble fields may be duplicated and transmitted in each of the multiple component channels. The PHY preamble may include both a legacy portion (or "legacy preamble”) and a non-legacy portion (or “non-legacy preamble”). The legacy preamble may be used for packet detection, automatic gain control and channel estimation, among other uses. The legacy preamble also may generally be used to maintain compatibility with legacy devices. The format of, coding of, and information provided in the non-legacy portion of the preamble is based on the particular IEEE 802.11 protocol to be used to transmit the payload.

[0039] A frequency band may include one or more sub-bands or frequency channels. For example, PPDUs conforming to the IEEE 802.11 n, 802.1 1ac, 802.11 ax and / or 802.11 be standard amendments may be transmitted over the 2.4 GHz, 5 GHz, and / or 6 GHz bands, each of which may be divided into multiple 20 MHz channels. The PPDUs may be transmitted over a physical channel having a minimum bandwidth of 20 MHz. Larger channels may be formed through channel bonding. For example, PPDUs may be transmitted over physical channels having bandwidths of 40 MHz, 80 MHz, 160 MHz, or 320 MHz by bonding together multiple 20 MHz channels.

[0040] FIG. 2 is a block diagram illustrating example implementations of a STA 210 and an AP 260. As shown in FIG. 2, STA210 may include at least one processor 220, a memory 230, and at least one transceiver 240. AP 260 may include at least one processor 270, a memory 280, and at least one transceiver 290. Processor 220 / 270 may be operatively connected to memory 230 / 280 and / or to transceiver 240 / 290.

[0041] Processor 220 / 270 may implement functions of the PHY layer, the MAC layer, and / or the logical link control (LLC) layer of the corresponding device (STA 210 or AP 260). Processor 220 / 270 may include one or more processors and / or one or more controllers. The one or more processors and / or one or more controllers may comprise, for example, a general-purpose processor, a digital signal processor (DSP), a microcontroller, an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), a logic circuit, or a chipset, for example.

[0042] Memory 230 / 280 may include a read-only memory (ROM), a random-access memory (RAM), a flash memory, a memory card, a storage medium, and / or other storage unit. Memory 230 / 280 may comprise one or more non-transitory computer readable mediums. Memory 230 / 280 may store computer programDocket No.: 24-3050PCT instructions or code that may be executed by processor 220 / 270 to carry out one or more of the operations / embodiments discussed in the present application. Memory 230 / 280 may be implemented (or positioned) within processor 220 / 270 or external to processor 220 / 270. Memory 230 / 280 may be operatively connected to processor 220 / 270 via various means known in the art.

[0043] Transceiver 240 / 290 may be configured to transmit / receive radio signals. In an embodiment, transceiver 240 / 290 may implement a PHY layer of the corresponding device (STA 210 or AP 260). In an embodiment, STA 210 and / or AP 260 may be a multi-link device (MLD), that is a device capable of operating over multiple links as defined by the IEEE 802.11 standard. As such, STA 210 and / or AP 260 may each implement multiple PHY layers. The multiple PHY layers may be implemented using one or more of transceivers 240 / 290.

[0044] Target wake time (TWT), a feature introduced in the IEEE 802.11 ah standard, allows STAs to manage activity in the BSS by scheduling STAs to operate at different times to reduce contention. TWTs may allow STAs to reduce the required amount of time that a STA utilizing a power management mode may be awake. TWTs may be individual TWTs or broadcast TWTs. Individual TWTs follow a negotiated TWT agreement between STAs. Broadcast TWTs are based on a schedule set and provided to STAs by an AP.

[0045] In an individual TWT, a STA that requests a TWT agreement is called a TWT requesting STA. The TWT requesting STA may be a non-AP STA for example. The STA that responds to the request is called a TWT responding STA. The TWT responding STA may be an AP for example. The TWT requesting STA is assigned specific times to wake up and exchange frames with the TWT responding STA. The TWT requesting STA may communicate wake scheduling information to the TWT responding STA. The TWT responding STA may transmit TWT values to the TWT requesting STA when a TWT agreement is established between them.

[0046] When explicit TWT is employed, the TWT requesting STA may wake up and perform a frame exchange. The TWT requesting STA may receive a next TWT information in a response from the TWT responding STA. When implicit TWT is used, the TWT requesting STA may calculate a next TWT by adding a fixed value to the current TWT value.

[0047] The TWT values for implicit TWT may be periodic. The TWT requesting STA operating with an implicit TWT agreement may determine a next TWT service period (TWT SP) start time by adding a value of a TWT wake interval associated with the TWT agreement to the value of the start time of the current TWT SP. The TWT responding STA may include the start time for a series of TWT SPs corresponding to a single TWT flow identifier of an implicit TWT agreement in a target wake time field of a TWT element. The TWT element may contain a value of ‘accept TWT' in a TWT setup command field. The start time of the TWT SP series may indicate the start time of a first TWT SP in the series. Start times of subsequent TWT SPs may be determined by adding the value of the TWT wake interval to the start time of the current TWT SP. In an example, the TWT requesting STA, awake for an implicit TWT SP, may enter a doze state after the TWT SPDocket No.: 24-3050PCT has elapsed or after receiving an end of service period (EOSP) field equal to 1 from the TWT responding STA, whichever occurs first.

[0048] A TWT session may be negotiated between an AP and a STA. The TWT session may configure a TWT SP of DL and UL traffic between the AP and the STA. Expected traffic may be limited within the negotiated SP. The TWT SP may start at a specific time. The TWT SP may run for a SP duration. The TWT SP may repeat every SP interval.

[0049] FIG. 3 illustrates an example 300 of TWT operation. As shown in FIG. 3, example 300 includes an AP 311 , a STA 312, and a STA 313. AP 31 1 and STA 312 may establish a TWT SP 320. AP 311 and STA 313 may establish a TWT SP 321 . TWT SP 320 and TWT SP 321 may repeat as shown in FIG. 3, such that TWT SP 320 may include a first TWT SP 320-1 and a second TWT SP 320-2, and such that TWT SP 321 may include a first TWT SP 321 -1 and a second TWT SP 321 -2.

[0050] AP 311 and STA 312 may exchange frames during first TWT SP 320-1 . STA 312 may enter a doze state at the end of TWT SP 320-1 and may remain in the doze state until the start of second TWT SP 320-2. The start of second TWT SP 320-2 may be indicated by a TWT wake interval 330 associated with TWT SP 320. AP 311 and STA 312 may again exchange frames during second TWT SP 320-2.

[0051] Similarly, AP 311 and STA 313 may exchange frames during first TWT SP 321-1. STA 313 may enter a doze state at the end of first TWT SP 321 -1 and may remain in the doze state until the start of second TWT SP 321-2. The start of second TWT SP 321-2 may be indicated by a TWT wake interval 331 associated with TWT SP 321 . AP 311 and STA 313 may again exchange frames during second TWT SP 31-2.

[0052] In an awake state, a STA may be fully powered. The STA may transmit and / or receive a frame to / from an AP or another STA. In a doze state, a STA may not transmit and may not receive a frame to / from an AP or another STA.

[0053] An MLD is an entity capable of managing communication over multiple links. The MLD may be a logical entity and may have more than one affiliated station (STA). The MLD may have a single MAC service access point (MAC-SAP) to the LLC layer, which includes a MAC data service. An MLD may be an access point MLD (AP MLD) when a STA affiliated with the MLD is an AP STA (or an AP). An MLD may be a non- access point MLD (non-AP MLD) or STA MLD when a STA affiliated with the MLD is a non-AP STA (or a STA).

[0054] During negotiation of TWT agreements, a TWT requesting STA affiliated with a STA MLD and a TWT responding STA affiliated with an AP MLD may communicate multiple TWT elements. The TWT elements may comprise link ID bitmap subfields indicating different link(s) in a TWT setup frame. The TWT parameters provided by a TWT element may be applied to the respective link that is indicated in the TWT element.

[0055] FIG. 4 illustrates an example 400 of TWT operation in a multi-link environment including an AP multilink device (AP MLD) 410 and a STA multi-link device (STA MLD) 420. As shown in FIG. 4, AP MLD 410 may have three affiliated APs, AP 411 , AP2 412, and AP3 413. In an example, AP 411 , AP2 412, and AP3Docket No.: 24-3050PCT413 may operate respectively on the 2.4 GHz band, the 5 GHz band, and the 6 GHz band. STA MLD 420 may have three affiliated STAs, STA 421 , STA 422, and STA 423. In an example, STA 421 , STA 422, and STA 423 may operate respectively on the 2 4 GHz band, the 5 GHz band, and the 6 GHz band. In an example, AP 411 , AP2 412, and AP3 413 may be communicatively coupled via a first link (link 1), a second link (link 2), and a third link (link 3) respectively with STA 421 , STA 422, and STA 423, respectively.

[0056] In an example, STA 421 may transmit a TWT request to AP 41 1. The TWT request may include three TWT elements. Each TWT element may indicate a respective link of links 1-3 and may request the setup of a TWT agreement for the indicated link. The three TWT elements may have different TWT parameters, such as target wake time (TWT). In response to the TWT request, AP 411 may transmit a TWT response to STA 421 . The TWT response may include three TWT elements. Each TWT element may indicate a respective link of links 1-3 and may include a value of ‘accept TWT in a TWT setup command field.

[0057] Successful TWT agreement setup on links 1-3 establishes three TWT SPs with same or different TWT parameters on links 1 -3 respectively. The target wake time field of the TWT element indicating a given link indicates the start time of the TWP SP for that link. The starting time may be indicated in reference to a time synchronization function (TSF) time of the link.

[0058] In example 400, initial TWT SPs 430-1 , 430-2, and 430-3 of links 1-3 respectively may be aligned. TWT wake intervals associated with the TWT agreements of links 1-3 respectively may be set differently. As such, second TWT SPs 431-1 , 431 -2, and 431 -3 of links 1-3 respectively may not be aligned. STA 421 , STA 422, and STA 423 may enter a doze state between the end of initial TWT SPs 430-1 , 430-2, and 430-3, respectively, and the start of second TWT SPs 431-1 , 431-2, 431-3, respectively.

[0059] FIG. 5 illustrates an example target wake time (TWT) element 500 which may be used to support individual TWT operation.

[0060] In an example, an AP and a STA may use TWT element 500 to negotiate a TWT agreement. The AP and / or the STA may transmit TWT element 500 in an individually addressed management frame. The management frame may be of the type action, action no ack, (re)association request / response, and probe request response, for example.

[0061] The TWT schedule and parameters may be provided during a TWT setup phase. Renegotiation / changes of TWT schedules may be signaled via individually addressed frames that contain the updated TWT schedule / parameters. The frames may be management frames as described above or control or data frames that carry a field containing the updated TWT schedule / parameters.

[0062] Referring to FIG. 5, TWT element 500 includes an element ID field, a length field, a control field, and a TWT parameter information field.

[0063] The element ID field (e.g., 1 octet in length) may indicate that information element 500 is a TWT element. The length field (e.g., 1 octet) may indicate the length of TWT element 500 starting from the controlDocket No.: 24-3050PCT field until an end of TWT element 500. The end of TWT element 500 may be the end of a TWT Channel field or the end of a Link ID bitmap field of the TWT parameter information field.

[0064] The TWT parameter information field may include a request type field (e.g., 2 octets), a target wake time field (e.g., 8 octets or less), a TWT group assignment field (e.g., 9, 3, 2, or 0 octets), a nominal minimal TWT wake duration field (e.g., 1 octet), a TWT wake interval mantissa (e.g., 2 octets), a TWT channel field (e.g., 1 octet), an optional NDP paging field (e.g., 0 or 4 octets), and / or a Link ID bitmaps field (e.g., 0 or 2 Octets ).

[0065] The request type field may indicate a type of TWT request. The request type field may include a TWT request field (e.g., 1 bit), a TWT setup command field (e.g., 3 bits), a trigger field (e.g., 1 bit), an implicit field (e.g., 1 bit), a flow type (e.g., 1 bit), a TWT flow identifier (e.g., 3 bits), a TWT wake interval exponent (e.g., 5 bits), and / or a TWT protection field (e.g., 1 bit).

[0066] The TWT request field may indicate whether the TWT element 500 represents a request. If TWT request field has a value of 1 , then the TWT element 500 may represent a request to initiate TWT scheduling / setup.

[0067] The TWT setup command field may indicate a type of TWT command. In a TWT request, the type of TWT command indicated may be: a request TWT (the TWT responding STA specifies the TWT value; e.g., field set to 0), a suggest TWT (the TWT requesting STA suggests a TWT value; e.g., field set to 1), and a demand TWT (the TWT requesting STA demands a TWT value; e.g., field set to 2).

[0068] In a TWT response, the type of TWT command indicated may be: TWT grouping (the TWT responding STA suggests TWT group parameters that are different than the suggested or demanded TWT parameters of the TWT requesting STA; e.g., field set to 3), accept TWT (the TWT responding STA accepts the TWT request with the TWT parameters indicated by the TWT requesting STA; e.g. field set to 4), alternate TWT (the TWT responding STA suggests TWT parameters that are different than the parameters suggested or demanded by the TWT requesting STA; e.g., field set to 5), dictate TWT (the TWT responding STA demands TWT parameters that are different than the parameters suggested or demanded by the TWT requesting STA; e.g., field set to 6), or reject TWT (the TWT responding STA rejects the TWT setup; e.g. field set to 7).

[0069] In a TWT response, the TWT command may also indicate an unsolicited response or a broadcast TWT. An unsolicited TWT response is an individually addressed frame that is intended for a specific STA. An unsolicited TWT response may be followed by an ACK frame from the STA receiving the unsolicited TWT response. A broadcast TWT may be intended for multiple STAs and may be carried in a broadcast frame such as, for example, a beacon frame. A broadcast TWT may not be acknowledged by receiving STAs.

[0070] An unsolicited TWT response may be used a TWT responding STA to demand that a recipient follow a TWT schedule contained in the TWT element. In an embodiment, an unsolicited TWT response may have the TWT request field set to 0 and a value of 'dictate TWT’ in the TWT setup command field. A broadcastDocket No.: 24-3050PCTTWT response may be used by a TWT responding STA to schedule a TWT for any STA that receives and decodes the TWT element.

[0071] In certain embodiments, a TWT element, such as TWT element 500, may contain TWT parameter sets for multiple TWT negotiations or indications as described herein. As such, the TWT element may include multiple instances of the Control and the TWT parameter information fields. The TWT flow identifier of the request type field indicates the TWT negotiation which parameters are carried by the TWT parameter information field.

[0072] FIG. 6 illustrates an example target wake time (TWT) element 600 which may be used to support restricted TWT (r-TWT) operation. For r-TWT, TWT element 600 may be transmitted in a broadcast management frame, which can be a beacon frame, a TIM broadcast frame, a probe response frame, etc. In this embodiment, TWT element 600 provides non-negotiated TWT schedules (e.g., broadcast TWT schedules).

[0073] As shown, TWT element 600 includes an element ID field, a length field, a control field, and a TWT parameter information field.

[0074] The element ID field (e.g., 1 octet in length) may indicate that information element 600 is a TWT element. The length field (e.g., 1 octet) may indicate the length of TWT element 600 starting from the control field until an end of TWT element 600. The end of TWT element 600 may be the end of a broadcast TWT info field or the end of a r-TWT traffic info field of the TWT parameter information field.

[0075] The TWT parameter information field may include a request type field, a target wake time field (e.g., 2 octets), a nominal minimal TWT wake duration field (e.g., 1 octet), a TWT wake interval mantissa (e.g., 2 octets), a broadcast TWT info field (e.g., 2 octets), and an optional r-TWT traffic info field (e.g., 0 or 3 octets).

[0076] The request type field may include, among other fields, a TWT request field, a flow type field, and a TWT wake interval exponent field.

[0077] The TWT request field indicates whether TWT element 600 is a request. If the TWT request field has a value of 0, then TWT element 600 may represent a response to a request to initiate TWT scheduling / setup (solicit TWT), an unsolicited TWT response, and / or a broadcast TWT message.

[0078] The TWT wake interval represents the average time that a TWT requesting STA or a TWT scheduled STA expects to elapse between successive TWT SP start times of a TWT schedule. The TWT wake interval exponent field indicates a (base 2) exponent used to calculate the TWT wake interval in microseconds. In an embodiment, the TWT wake interval is equal to: (TWT wake interval mantissa) x 2(™T Wake lnterval ExP°nent). The TWT wake interval mantissa value is indicated in microseconds, base 2 in a TWT wake interval mantissa field of the TWT parameter information field.

[0079] The nominal minimum TWT wake duration field may indicate the minimum amount of time (in the unit indicated by a wake duration unit subfield of the control field) that a TWT requesting STA or a TWTDocket No.: 24-3050PCT scheduled STA is expected to be awake to complete frame exchanges for the period of the TWT wake interval.

[0080] The flow type field, in a TWT response that successfully set up a TWT agreement between a TWT requesting STA and a TWT responding STA, may indicate a type of interaction between the TWT requesting STA and the TWT responding STA within a TWT SP of the TWT agreement. A flow type field equal to 0 may indicate an announced TWT. In an announced TWT, the TWT responding STA may not transmit a frame to the TWT requesting STA within a TWT SP until the TWT responding STA receives a PS-Poll frame or a QoS Null frame from the TWT requesting STA. A flow type field equal to 1 may indicate an unannounced TWT. In an unannounced TWT, the TWT responding STA may transmit a frame to the TWT requesting STA within a TWT SP before it has received a frame from the TWT requesting STA.

[0081] Within a TWT element that includes a TWT setup command value of ‘request TWT’, 'suggest TWT’, or ‘demand TWT, a broadcast TWT ID may indicate a specific broadcast TWT in which the TWT requesting STA is requesting to participate. Within a TWT element that includes a TWT setup command value of ‘accept TWT', ‘alternate TWT', 'dictate TWT’, or ‘reject TWT', a broadcast TWT ID may indicate a specific broadcast TWT for which the TWT responding STA is providing TWT parameters. The value 0 in the broadcast TWT ID subfield may indicate the broadcast TWT whose membership corresponds to all STAs that are members of the BSS corresponding to the BSSID of the management frame carrying the TWT element and that is permitted to contain trigger frames with random access resource units for unassociated STAs. The Broadcast TWT ID subfield in a r-TWT Parameter set field is always set to a nonzero value.

[0082] A broadcast TWT element 600 that contains a r-TWT parameter set is also referred to as a r-TWT element A r-TWT traffic info present subfield of the broadcast TWT info field may be set to 1 to indicate the presence of the r-TWT traffic info field in TWT element 600. The r-TWT traffic info field is present in a r-TWT parameter set field when the r-TWT traffic info present subfield is set to 1 .

[0083] The r-TWT traffic info field may include a traffic info control field, a r-TWT DL TID bitmap field, and a r-TWT UL TID bitmap field.

[0084] The traffic info control field may include a DL TID bitmap valid subfield and an UL TID bitmap valid subfield. The DL TID bitmap valid subfield indicates if the r-TWT DL TID bitmap field has valid information. When the value of the DL TID bitmap valid subfield is set to 0, it may indicate that DL traffic of TIDs is identified as latency sensitive traffic, and the r-TWT DL TID bitmap field is reserved. The UL TID bitmap valid subfield may indicate if the r-TWT UL TID bitmap field has valid information. When the value of the UL TID bitmap valid subfield is set to 0, it may indicate that UL traffic of TIDs is identified as latency sensitive traffic, and the r-TWT UL TID bitmap field is reserved.

[0085] The r-TWT DL TID bitmap subfield and the r-TWT UL TID bitmap subfield may specify which TID(s) are identified by the TWT scheduling AP or the TWT scheduled STA as latency sensitive traffic streams in a downlink and a uplink direction, respectively. A value of 1 at bit position k in the bitmap indicates that TID kDocket No.: 24-3050PCT is classified as a latency sensitive traffic stream. A value of 0 at bit position k in the bitmap indicates that TID k is not classified as a latency sensitive traffic stream.

[0086] An individual target wake time (TWT) may be a specific time or set of times negotiated between two individual stations (e.g., a STA and another STA, or a STA and an AP, etc.) at which the stations may be awake to exchange frames during a service period (SP) of the TWT.

[0087] In trigger-enabled TWT, an AP may transmit a trigger frame for scheduling uplink multi-user transmissions from one or more ST As using uplink OFDMA (orthogonal frequency division multiple access) and / or uplink MU-MIMO (multi-user multiple input multiple output) during a trigger-enabled TWT SP. A TWT STA that receives the trigger frame from the AP may transmit a frame to the AP through a resource indicated in the trigger frame during the trigger-enabled TWT SP.

[0088] In non-trigger-enabled TWT, an AP may not be required to transmit a trigger frame to schedule uplink multi-user transmissions from one or more STAs during a non-trigger-enabled TWT SP.

[0089] In announced TWT, a STA may transmit a frame (e.g., a PS-Poll frame or a QoS null frame) to the AP to retrieve a downlink buffered data from the AP during a TWT SP. In unannounced TWT, an AP may transmit downlink data to a TWT STA without receiving a frame (e.g., a PS-Poll frame, or a QoS null frame) from the TWT STA during a TWT SP.

[0090] FIG. 7 illustrates an example 700 of individual TWT operation. As shown in FIG. 7, example 700 includes an AP 710, a STA 711 , and a STA 712. In an example, AP 710 may be a TWT responding STA and STA 711 and STA 712 may be TWT requesting STAs.

[0091] In an example, STA 711 may transmit a TWT request to AP 710 to setup a first trigger-enabled TWT agreement. STA 711 may set a trigger field of the TWT request to 1 to indicate that it is requesting a trigger- enabled TWT. AP 710 may accept the first TWT agreement with STA 711 . AP 710 may confirm the acceptance in a TWT response sent to STA 711. The TWT response may indicate a next TWT 730, which indicates the time until a next TWT SP 720 according to the first TWT agreement.

[0092] In an example, AP 710 may transmit an unsolicited TWT response to STA 712 to set up a second trigger-enabled TWT agreement with STA 712 without receiving a TWT request from STA 712. The first and second TWT agreements may be set up as announced TWTs.

[0093] After the setup of the TWT agreements, STA 711 and STA 712 may enter a doze state until the start of TWT SP 720. During trigger-enabled TWT SP 720, AP 710 may transmit a trigger frame. STA 71 1 and STA 12 may respond to the trigger frame by indicating that they are in awake state. In an example, STA 71 1 may transmit a power save poll (PS-Poll) frame. The PS-Poll frame may comprise a BSSID (receiver address: RA) field set to an address of AP 710 and a transmitter address (TA) field set to an address of STA 711 . In an example, STA 712 may transmit a QoS null frame in response to the trigger frame. The QoS null frame may comprise a MAC header (e.g., a frame control field, a duration field, address fields, a sequence control field, QoS control field) without a frame body.Docket No.: 24-3050PCT

[0094] In response to the PS-Poll frame and the QoS null frame, AP 710 may transmit a multi-STA Block Ack (M-BA) frame. The M-BA frame may include acknowledgement information associated with the PS-Poll frame and the QoS null frame received from STAs 711 and 712 respectively. Subsequently, STA 711 and STA 712 may receive downlink bufferable units (DL BUs) from AP 710. The DL BUs may include a medium access control (MAC) service data unit (MSDU), an aggregate MAC service data unit (A-MSDU), and / or a bufferable MAC management protocol data unit (MMPDU). STA 711 and STA 712 may transmit Block Ack (BA) frames in response to the DL BUs. At the end of the TWT SP 720, STA 71 1 and STA 712 may return to a doze state.

[0095] A STA may execute individual TWT setup exchanges. The STA may not transmit frames to an AP outside of negotiated TWT SPs. The STA may not transmit frames that are not contained within high efficiency trigger-based physical protocol data units (HE TB PPDUs) to the AP within trigger-enabled TWT SPs. A HE TB PPDU may be transmitted by a STA based on receiving a trigger frame triggering uplink multiuser transmissions.

[0096] The AP of a trigger-enabled TWT agreement may schedule for transmission a trigger frame for a STA within the trigger-enabled TWT SP. The STA may transmit an HE TB PPDU as a response to the trigger frame sent during the trigger-enabled TWT SP. A STA that is in power save (PS) mode may include a PS- Poll frame or a QoS null frame in the HE TB PPDU if the TWT is an announced TWT, to indicate to the AP that the STA is currently in the awake state. The AP that receives the PS-Poll frame or the QoS Null frame or any other indication from an STA in PS mode, may deliver to the STA as many buffered BUs as are available at the AP during the TWT SP.

[0097] A broadcast target wake time (TWT) may be a specific time or set of times broadcast by an AP to one or more STAs at which the STAs may be awake to exchange frames with the AP during a SP of the TWT.

[0098] FIG. 8 illustrates an example 800 of broadcast TWT operation. As shown in FIG. 8, example 800 includes an AP 810, a STA 81 1 , and a STA 812. In an example 800, AP 810 may be a TWT scheduling AP and STA 811 and STA 812 may be TWT scheduled STAs.

[0099] In an example, AP 810 may include a broadcast TWT element in a beacon frame that indicates a broadcast TWT SP 820. During the broadcast TWT SP 820, AP 810 may transmit trigger frames or DL BUs to STA 81 1 and STA 812. Beacon frames may be sent by AP 810 periodically at target beacon transmission times (TBTTs). The number of time units (TUs) between consecutive TBTTs is called the beacon interval. A TU is equal to 1024 microseconds.

[0100] In an example, STA 811 and STA 812 may enter a doze state until the first target beacon transmission time (TBTT). STA 811 and STA 812 may wake up to receive the beacon frame at the first TBTT to determine the broadcast TWT. Upon reception of a broadcast TWT element in a beacon frame, STA 81 1 and STA 812 may re-enter the doze state until the start of trigger-enabled TWT SP 820.Docket No.: 24-3050PCT

[0101] During trigger-enabled TWT SP 820, AP 810 may transmit a basic trigger frame to STA 81 1 and STA 812. STA 811 may indicate that it is awake by transmitting a PS-Poll, and STA 812 may indicate that it is awake by transmitting a QoS null frame in response to the basic trigger frame. Subsequently, STA 81 1 and STA 812 may receive DL BUs from AP 810. STA 81 1 and STA 812 may return to the doze state outside of the TWT SP 720.

[0102] In an example, a STA that intends to operate in power save mode may negotiate a wake TBTT and a wake interval with the AP. For example, as shown in FIG. 8, STA 811 may transmit a TWT request to AP 810 that identifies a wake TBTT of the first beacon frame and a wake interval between subsequent beacon frames. AP 810 may respond with a TWT response to the TWT request confirming the wake TBTT and wake interval. After successfully completing the negotiation, STA 81 1 may enter a doze state until a first negotiated wake TBTT 830. STA 811 may be in an awake state to listen to the beacon frame transmitted at first negotiated wake TBTT 830. If STA 81 1 receives a beacon frame from AP 810 at or after TBTT 830, STA 81 1 may return to the doze state until the next wake TBTT unless a traffic indication map (TIM) element in a beacon frame includes a positive indication for STA 811 . The STA 81 1 may return to the doze state after a nominal minimum TBTT wake duration time has elapsed from the TBTT start time.

[0103] A Network Allocation Vector (NAV) is an indicator, maintained by a station (STA), of time periods when transmission onto the wireless medium (WM) may not be initiated by the STA regardless of whether the clear channel assessment (CCA) function of the STA senses that the WM is busy. A STA that receives at least one valid frame in a PSDU may update its NAV with the information from any valid duration field in the PSDU. The STA may update the NAV when a value of the received duration field is greater than the current NAV value of the STA.

[0104] A TWT protection is a mechanism employed to protect a TWT session from external STA transmissions. During a TWT SP configured to protect the TWT session, a STA that initiates a transmission opportunity (TXOP) to transmit a frame may transmit a request to transmit (RTS) frame or a clear to transmit (CTS) frame to protect the TWT session by setting the NAV of other STAs based on receiving of the RTS frame and / or the CTS frame. The RTS frame may comprise a frame control field, a duration field, a receiver address (RA) field, a transmitter address (TA) field, and a frame check sequence (FCS) field. The CTS frame may comprise a frame control field, a duration field, a receiver address (RA) field, and a frame check sequence (FCS) field.

[0105] The TWT protection field in a TWT element may indicate whether a TWT is protected or unprotected. A TWT requesting STA may set the TWT protection field to 1 to request the TWT responding STA to provide protection for the set of TWT SPs. A TWT protection field equal to 1 may indicate to use a NAV protection mechanism to protect access to the medium during the corresponding TWT SPs.

[0106] FIG. 9 illustrates an example 900 of TWT protection in individual TWT operation. As shown in FIG. 9, example 900 includes an AP 910 and a STA 911 .Docket No.: 24-3050PCT

[0107] In an example, AP 910 may set the TWT protection field to 1 in a TWT response frame to protect the TWT SPs using a NAV protection mechanism. Upon reception of the TWT response frame, STA 91 1 may enter a doze state until the next TWT 930. AP 910 that has set the TWT protection field to 1 may transmit a NAV setting frame at the start of the TWT SP 920. For example, the NAV setting frame may be an RTS frame or a CTS frame.

[0108] A STA that receives the NV setting frame and that is not scheduled to access the medium during the TWT SP 920 may set their NAV according to the NAV setting frame. The STA may not access the medium for the specified amount of time in the NAV setting frame.

[0109] STA 911 may be scheduled to access the medium during the TWT SP 920. STA 91 1 may respond to the RTS frame with a CTS frame. Upon receiving the CTS frame, AP 910 may transmit a downlink frame to STA 911. STA 911 may respond to the downlink frame with a BA frame. When the TWT SP 920 ends, STA 911 may return to the doze state.

[0110] FIG. 10 illustrates an example 1000 of a STA 1006 transitioning / roaming from an AP 1002 to an AP 1004. Before the transitioning / roaming from AP 1002 to AP 1004, STA 1006 may be associated with AP 1002. When STA 1006 moves from within a communication range of AP 1002 to a communication range of AP 1004, a communication session of STA 1006 is transferred from AP 1002 to AP 1004. The IEEE 802.1 1 standard defines a Basic Service Set (BSS) transition process (described in FIG. 1 1 below) which may be used to transfer the communication session of STA 1006 from AP 1002 to AP 1004.

[0111] FIG. 10 illustrates an example of 1000 of BSS transition according to the IEEE 802.1 1 standard. As shown in FIG. 10, example 1000 may include APs 1002 and AP 1004 and STA 1006. STA 1006 may be associated with AP 1002 at the beginning of example 1000 and may have established a secure session 1008 with AP 1002.

[0112] STA 1006 starts the transition process by sending an authentication request frame 1010 to AP 1004. IEEE 802.10 authentication operates at the link level between IEEE 802.10 STAs. The IEEE 802.10 standard attempts to control LAN access via the authentication service. IEEE 802.10 authentication is a station service. This service might be used by all STAs to establish their identity to APs with which they communicate. If a mutually acceptable level of authentication has not been established between a STA and an AP, an association is not established.

[0113] If AP 1004 accepts authentication request frame 1010, AP 1004 may send an authentication response frame 1012 to STA 1006. Upon reception of authentication response frame 1012, STA 1006 may send an association request frame 1014 to AP 1004, requesting to start a secure session with AP 1004. If AP 1004 accepts the association request of STA 1006, AP 1004 sends an association response frame 1016 to indicate that the secure session is established.

[0114] A drawback of the BSS transition process illustrated in FIG. 10 is the duration required to exchange authentication request frame 1010 and authentication response frame 1012. To mitigate this problem, theDocket No.: 24-3050PCTIEEE 802.10 standard introduced the Fast BSS transition (FT) protocols. The FT protocols seek to reduce the length of time that connectivity is lost between a STA and the distribution system (DS) during a BSS transition. The FT protocols are part of the reassociation service and only apply to STA transitions between APs within the same mobility domain within the same extended service set (ESS). The FT protocols require information to be exchanged during the initial association (or a later reassociation) between a STA (denoted as the FT Originator (FTO)) and an AP. The initial exchange is referred to as the FT initial mobility domain association. Subsequent reassociations to APs within the same mobility domain may make use of the FT protocols.

[0115] The IEEE 802.11 standard defines two FT protocols: an FT protocol and an FT resource request protocol. The FT protocol is executed when an FTO makes a transition to a target AP and does not require a resource request prior to the transition. The FT resource request protocol is executed when an FT 0 requires a resource request prior to the transition. For an FTO to move from its current AP to a target AP utilizing the FT protocols, the message exchanges are performed using one of two methods: Over-the-Air or Over-the- DS. Using the Over-the-Air method, the FTO communicates directly with the target AP using IEEE 802.10 authentication with the FT authentication algorithm. Using the Over-the-DS method, the FTO communicates with the target AP via the current AP.

[0116] The communication between the FTO and the target AP is carried in FT Action frames between the FTO and the current AP. Between the current AP and target AP, communication is via an encapsulation. The current AP converts between the two encapsulations. APs advertise both capabilities and policies for supporting the FT protocols and methods.

[0117] FIG. 11 illustrates an example of 1100 of the FT protocol using the Over-the-DS method. As shown in FIG. 11 , example 1100 may include APs 1 102 and AP 1 104 and STA 1106. STA 1 106 may be associated with AP 1 102 at the beginning of example 1100 and may have established a secure session 1108 with AP 1 102. APs 1 102 and AP 1104 can communicate through the DS. STA 1106 is the FTO. AP 1104 is the Target AP.

[0118] The Over-the-DS fast BSS transition may begin with STA 1 106 (the FTO) sending an FT request 1 110 to AP 1104 (the target AP), via AP 1102. FT request 1 110 may include an address (e.g., MAC address) of STA 1106 and an address (e.g., BSSID) of AP 1104. AP 1104 may respond to FT request 11 10 by sending an FT response 1112 to STA 1106, via AP 1102. FT response 1112 may include an address of STA 1106, an address of AP 1104, and a status. If STA 1106 does not receive a response to FT request 1110, it may reissue the request following the restrictions given for Authentication frames.

[0119] If the status in FT response 1112 indicates SUCCESS, STA1106 may send a reassociation request frame 1114 to AP 1104. AP 1 104 may respond with a reassociation response 11 16 to STA 1 106.

[0120] While the FT protocol eliminates the need for authentication steps, a drawback of the FT protocol is that the FTO and the target AP are still required to perform reassociation steps.Docket No.: 24-3050PCT

[0121] FIG. 12 illustrates an example 1200 of a procedure of session transfer via roaming. As shown in FIG. 12, example 1200 may include a AP 1202, an AP 1204, and a STA 1206. STA 1206 may be associated with AP 1204 and may have established a secure session with AP 1204. AP 1202 and AP 1204 may each include a seamless mobility domain (SMD). The SMD may be a logical control plane entity. The SMD may be also referred to as a controller and may be present in all APs associated to an ESS. The SMD may be present in a subset of APs associated to an ESS. SMD may be responsible for authentication and association; thus for a session transfer, repetition of the steps of authentication and association may not be necessary.

[0122] As shown in FIG. 12, in example 1200, session transfer via roaming may be divided into two phases: roaming preparation and roaming execution.

[0123] Before initiating session transfer from AP 1204 to AP 1202, STA 1206 may send a link request (LR) notify frame 1208 to AP 1204 to indicate intention to roam from AP 1204. In an example, frame 1208 may comprise a SMD basic service set transition (ST) preparation request. In an example, the ST preparation request may further comprise a UHR link reconfiguration request.

[0124] Upon reception of LR notify frame 1208, AP 1204, using the SMD, may send a roaming request (RR) frame 1210 to AP 1202. RR frame 1210 initiates a static context transfer from AP 1204 to AP 1202. Additionally, STA 1206 may establish a new link with AP 1202. The static context transfer may include TWT session information of STA 1206, the SOS descriptors of all established SCS between STA 1206 and AP 1204, the block ack parameters and block ack timeout for any block ACK agreement on each TID, the latest sequence number (SN) for each TID with UL block agreement, and the starting packet number (PN) to be assigned for DL individually addressed frames by AP 1202.

[0125] After transmitting RR frame 1210, AP 1204 may transmit a LR notify frame 1212 to STA 1206 to indicate AP 1202 as a suitable candidate for roaming, by STA 1206, from AP 1204. In an example, frame 1212 may comprise a ST preparation response. In an example, the ST preparation response may further comprise a UHR link reconfiguration response.

[0126] On receiving LR notify frame 1212, STA 1206 may send to AP 1204 one or more uplink data frames 1214 including all the uplink data buffered at STA 1206.

[0127] After transmitting the one or more uplink data frames 1214, STA 1206 may send a LR request frame 1216 to AP 1204 to start session transfer via roaming LR request frame 1216 may indicate intention of STA 1206 to roam from AP 1204 to AP 1202. In an example, frame 1216 may comprise a ST execution request. In an example, the ST execution request may further comprise a UHR link reconfiguration request.

[0128] On receiving LR request frame 1216, AP 1204, using the SMD, may approve or partially approve the session transfer, and may send a RR frame 1218 to AP 1202. If session transfer is approved or partially approved, dynamic context transfer is initiated from AP 1204 to AP 1202. Dynamic context transfer may include sequence number (SN) information and packet number (PN) informationDocket No.: 24-3050PCT

[0129] Subsequently, AP 1204 may send a LR response frame 1220 to STA 1206 to indicate acceptance or rejection of the session transfer via roaming. If the session transfer via roaming is accepted, LR response frame 1220 may also indicate the context parameters that have been successfully transferred (e.g., TWT session information, SN information, and / or PN information) from AP 1204 to AP 1202. In an example, frame 1220 comprises a ST execution response. In an example the ST execution response further comprises a UHR link reconfiguration response.

[0130] Upon receiving LR response frame 1220, STA 1206 may proceed to finalize the session transfer via roaming by sending a LR request 1222 comprising / indicating a link deletion to disassociate STA 1206 from AP 1204.

[0131] In example 1200, LR response frame 1220 may indicate that TWT session information of STA 1206 has not been successfully transferred from AP 1204 to AP 1202. To establish a new TWT session between STA 1206 and AP 1202, STA 1206 may start a TWT negotiation by sending a TWT request frame 1224 to AP 1202. AP 1202 may respond with a TWT response frame 1226 accepting the request and establishing the new TWT session. STA 1206 may enter a doze state until a TWP SP 1228 of the new TWT session arrives.

[0132] In example 1200, LR response frame 1220 may indicate that the SCS descriptor of STA 1206 has not been successfully transferred from AP 1204 to AP 1202. To establish a new SCS stream between STA 1206 and AP 1202, STA 1206 may start a SCS negotiation by sending a SCS request frame 1224 to AP 1202. AP 1202 may respond with a SCS response frame 1226 accepting the request and establishing the new SCS stream.

[0133] As described above, the procedure of FIG. 12 may require renegotiation of TWT session once STA 1206 has roamed from AP 1204 to AP 1202. During this procedure, STA 1206 may not be able to maintain the QoS of traffic associated with the TWT session being negotiated (e.g., traffic with TIDs associated with the original TWT session). If the traffic associated with the TWT session comprises low latency data, the negotiation delay may cause the low latency data to be delayed or even lost before a TWT SP is reestablished.

[0134] As described above, the procedure of FIG. 12 may require renegotiation of a new SCS stream once STA 1206 has roamed from AP 1204 to AP 1202. During this procedure, STA 1206 may not be able to maintain the QoS of traffic associated with the SCS stream being negotiated (e.g., traffic with TIDs associated with the original SCS descriptor). If the traffic associated with the SCS stream comprises low latency data, the negotiation delay may cause the low latency data to be delayed or even lost before a SCS stream is reestablished.

[0135] Embodiments of the present disclosure, as further described below, address the above-discussed problem of existing technologies. In an aspect, a STA may transmit to a first AP a first frame indicating / requesting a transition (roaming) from the first AP to a second AP. In an embodiment, the firstDocket No.: 24-3050PCT frame may further comprise an indication of whether the STA accepts modification of its current first TWT SP with the first AP after transitioning to the second AP. In a different example, the first frame may further comprise an indication of the STA requesting for a second TWT SP after roaming from the first AP to the second AP. In another embodiment, the first AP may send a second frame to the STA indicating the acceptance / rejection of the first TWT SP. In an example, the second frame may further comprise a third TWT SP suggested by the second AP. In another embodiment, on receiving the second frame, the STA may transmit a third frame indicating / requesting a transition (roaming) from the first AP to the second AP. In an example, the third frame may further comprise an indication of acceptance / rejection of the third TWT SP. In an example, the third frame may further comprise an indication of a fourth TWT SP. In another embodiment, following the reception of the third frame, the first AP may send a fourth frame indicating acceptance of rejection of the fourth TWT SP by the second AP.

[0136] In an embodiment, a STA may transmit to a first AP, a first frame indicating a second AP for a transition from the first AP and a first list of streams, established between the STA and the first AP, for which the STA requests resource prioritization from the second AP upon transition to the second AP. In an embodiment, the first frame comprises a seamless mobility domain (SMD) basic service set (BSS) transition (ST) preparation request frame. In an embodiment, the first frame comprises a medium access control (MAC) identifier of the second AP. In an embodiment, the STA may receive from the first AP, a second frame indicating a second list of streams, among the first list of streams, that are accepted by the second AP. In an embodiment, the second frame comprises a ST preparation response frame. In an embodiment, the first / second list of streams comprises stream classification service (SCS) streams.

[0137] In an embodiment, a first AP may receive from a STA, a first frame indicating a first list of streams, established between the first AP and the STA, for which the STA requests resource prioritization from a second AP upon transition to the second AP. In an embodiment, the first AP may transmit to the second AP, a second frame indicating the first list of streams. In an embodiment, the second frame comprises descriptors corresponding to the first list of streams. In an embodiment, the first AP may receive from the second AP, a third frame indicating a second list of streams, among the first list of streams, that are accepted by the second AP.

[0138] In an embodiment, the first AP may transmit to the second AP, a fourth frame indicating a first set of links requested by the STA for setup with the second AP.

[0139] In an embodiment, the first AP may receive from the second AP, a fifth frame indicating acceptance by the second AP of setup of a second set of links, among the first set of links, between the second AP and the STA. In an embodiment, the transmitting the second frame is based on the receiving of the fifth frame.

[0140] In an embodiment, a first AP may receive from a second AP, a first frame indicating a first list of streams, established between the second AP and a station (STA), for which the STA requests resource prioritization from the first AP upon transition to the first AP. In an embodiment, the first frame comprisesDocket No.: 24-3050PCT descriptors corresponding to the first list of streams. In an embodiment, the first AP may transmit to the second AP, a second frame indicating a second list of streams, among the first list of streams, that are accepted by the first AP. In an embodiment, the first AP accepts or rejects a stream, among the first list streams, based on the STA requesting resource prioritization for the stream.

[0141] In an embodiment, the first AP may receive from the second AP, a third frame indicating a first set of links requested by the STA for setup with the first AP.

[0142] In an embodiment, the first AP may transmit to the second AP, a fourth frame indicating acceptance by the first AP of setup of a second set of links, among the first set of links, between the first AP and the STA.

[0143] FIG. 13 illustrates an example 1300 of a roaming procedure according to an embodiment. Example 1300 is provided for the purpose of illustration only and is not limiting of embodiments of the present disclosure. As shown in FIG. 13, example 1300 may include an AP 1302, an AP 1304, and a STA 1306. In an embodiment, each of AP 1302, AP 1304, and STA 1306 may be a multi-link device (MLD), that is a device capable of operating over multiple links as defined by the IEEE 802.1 1 standard.

[0144] At the beginning of example 1300, STA 1306 may be associated with AP 1304 and may have an established a secure session with AP 1304. In an embodiment, STA 1306 may have an established link with AP 1304. Example 1300 may begin with AP 1304 transmitting a frame 1316 to STA 1306. In an embodiment, frame 1316 indicates a first TWT SP scheduled by AP 1304 for STA 1306. In one embodiment, frame 1316 may comprise a TWT setup response frame. The TWT setup frame may include a TWT request field set to 0, indicating success in establishing the first TWT SP by AP 1304. In an embodiment, AP 1304 may transmit frame 1316 as a response to a TWT setup request frame (not shown in FIG. 13) sent by STA 1306 to AP 1304. In an embodiment, the TWT setup request frame may comprise a TWT element that includes parameters of the first TWT SP and a TWT setup command field.

[0145] In an embodiment, frame 1316 indicates a first SCS descriptor for a stream between AP 1304 for STA 1306. In one embodiment, frame 1316 may comprise an SCS response frame. In an embodiment, AP 1304 may transmit frame 1316 as a response to a SCS request frame (not shown in FIG. 13) sent by STA 1306 to AP 1304.

[0146] In an example, STA 1306 may determine to initiate a session transfer from AP 1304. To initiate session transfer, STA 1306 may transmit to AP 1304 a frame 1308 comprising a first indication of a transition (or roaming) from AP 1304 to another AP. The other AP may be AP 1302. Frame 1308 may comprise a link reconfiguration notify frame, a roaming announcement notify frame, a roaming announcement request frame, a roaming request frame, a roaming notify frame, a ST request or a probe request frame. In an embodiment, the ST request may comprise a UHR link reconfiguration request.

[0147] In an embodiment, frame 1308 may further indicate whether STA 1306 accepts modification of the first TWT SP by AP 1302 or AP 1304.Docket No.: 24-3050PCT

[0148] In an embodiment, frame 1308 may further indicate whether STA 1306 accepts modification of the first SCS descriptor by AP 1302 or AP 1304.

[0149] In an embodiment, frame 1308 may further request part of the context not to be transferred to AP 1302.

[0150] In an example, frame 1308 may suggest, request, or demand the first TWT SP.

[0151] In an example, frame 1308 may suggest, request, or demand the first SCS descriptor.

[0152] In an embodiment, where STA 1306 has the first TWT SP established with AP 1304, STA 1306 may suggest the first TWT SP in frame 1308. In an embodiment, STA 1306 suggesting the first TWT SP in frame 1308 indicates that STA 1306 wishes to maintain the first TWT SP after roaming from AP 1304 to AP 1302, but may also indicate that STA 1306 is open for negotiating the parameters of the first TWT SP.

[0153] In an embodiment, where STA 1306 has a first SCS stream associated to the first SCS descriptor established with AP 1304, STA 1306 may suggest the first SCS descriptor in frame 1308. In an embodiment, STA 1306 suggesting the first SCS descriptor in frame 1308 indicates that STA 1306 wishes to maintain the first SCS stream after roaming from AP 1304 to AP 1302, but may also indicate that STA 1306 is open for negotiating the parameters of the first SCS descriptor.

[0154] In an embodiment, where STA 1306 does not have the first TWT SP established with AP 1304, STA 1306 may request the first TWT SP in frame 1308. In an embodiment, STA 1306 requesting the first TWT SP in frame 1308 indicates that STA 1306 wishes to have the first TWT SP scheduled once roaming from AP 1304 to AP 1302 happens.

[0155] In an embodiment, where STA 1306 has the first SCS stream established with AP 1 104, STA 1306 may demand the first SCS descriptor in frame 1308. In an embodiment, STA 1306 demanding the first SCS descriptor in frame 1308 indicates that STA 1306 wishes to maintain the first SCS stream after roaming from AP 1304 to AP 1302 with no modifications. That is, STA 1306 is not open to negotiating the parameters of the first TWT descriptor.

[0156] In an embodiment, where STA 1306 has the first TWT SP established with AP 1104, STA 1306 may demand the first TWT SP in frame 1308. In an embodiment, STA 1306 demanding the first TWT SP in frame 1308 indicates that STA 1306 wishes to maintain the first TWT SP after roaming from AP 1304 to AP 1302 with no modifications. That is, STA 1306 is not open to negotiating the parameters of the first TWT SP.

[0157] On receiving frame 1308, AP 1304 may transmit a frame 1310 to STA 1306. Frame 1310 may comprise a roaming response, a link reconfiguration notify frame, a ST preparation response. In an example the STA preparation response may comprise a UHR link reconfiguration response. Frame 1310 may indicate a second TWT SP suggested / indicated by AP 1302 or AP 1304 to STA 1306.

[0158] In an embodiment, on receiving frame 1308, AP 1304 may transmit a frame 1310 to STA 1306. Frame 1310 may comprise a roaming response, a link reconfiguration notify frame, a ST preparation response. In an example the STA preparation response may comprise a UHR link reconfiguration response.Docket No.: 24-3050PCTFrame 1310 may indicate a second SCS descriptor suggested / indicated by AP 1302 or AP 1304 to STA 1306.

[0159] In an example, frame 1310 may include a TWT parameter information field as shown in FIG. 5. Alternatively, frame 1310 may include a subset of the fields of the TWT parameter information field shown in FIG. 5. For example, the TWT parameter information field in frame 1310 may indicate one or more of: a type of TWT session (implicit or explicit), a target wake time, a nominal minimum TWT wake duration, a TWT wake interval mantissa, and a TWT wake interval exponent.

[0160] On receiving frame 1310, STA 1306 may transmit a frame 1312 to AP 1304 or AP 1302. Frame 1312 may indicate a third TWT SP. In an example, frame 1312 may further indicate (imply) rejection of the second TWT SP.

[0161] On receiving frame 1310, STA 1306 may transmit a frame 1312 to AP 1304 or AP 1302. Frame 1312 may indicate a third SCS descriptor. In an example, frame 1312 may further indicate (imply) rejection of the second SCS descriptor.

[0162] In one embodiment, frame 1312 may include a TWT parameter information field as shown in FIG. 5. Alternatively, frame 1312 may include a subset of the fields of the TWT parameter information field shown in FIG. 5. For example, the TWT parameter information field in frame 1312 may indicate one or more of: a type of TWT session (implicit or explicit), a target wake time, a nominal minimum TWT wake duration, a TWT wake interval mantissa, and a TWT wake interval exponent.

[0163] In an embodiment where STA 1306 has rejected the second TWT SP, STA 1306 may suggest the third TWT SP in frame 1312. In an embodiment, STA 1306 suggesting the third TWT SP in frame 1312 indicates that STA 1306 wishes to establish the third TWT SP after roaming from AP 1304 to AP 1302, but may also indicate that STA 1306 is open for negotiating the parameters of the third TWT SP.

[0164] In an embodiment where STA 1306 has rejected the second SCS descriptor, STA 1306 may suggest the third SCS descriptor in frame 1312. In an embodiment, STA 1306 suggesting the third SCS descriptor in frame 1312 indicates that STA 1306 wishes to establish a third SCS stream associated with the third SCS descriptor after roaming from AP 1304 to AP 1302, but may also indicate that STA 1306 is open for negotiating the parameters of the third SCS descriptor.

[0165] In an embodiment where STA 1306 has rejected the second TWT SP, STA 1306 may request the third TWT SP in frame 1312. In an embodiment, STA 1306 requesting the third TWT SP in frame 1312 indicates that STA 1306 wishes to have the third TWT SP scheduled once roaming from AP 1304 to AP 1302 happens.

[0166] In an embodiment where STA 1306 has rejected the second SCS descriptor, STA 1306 may request the third SCS descriptor in frame 1312. In an embodiment, STA 1306 requesting the third SCS descriptor in frame 1312 indicates that STA 1306 wishes to have the third SCS stream associated with the third SCS descriptor scheduled once roaming from AP 1304 to AP 1302 happens.Docket No.: 24-3050PCT

[0167] In an embodiment where STA 1306 has rejected the second TWT SP, STA 1306 may demand the third TWT SP in frame 1312. In an embodiment, STA 1306 demanding the third TWT SP in frame 1312 indicates that STA 1306 wishes to maintain the third TWT SP after roaming from AP 1304 to AP 1302 with no modifications. That is, STA 1306 is not open to negotiating the parameters of the third TWT SP.

[0168] In an embodiment where STA 1306 has rejected the second SCS descriptor, STA 1306 may demand the third SCS descriptor in frame 1312. In an embodiment, STA 1306 demanding the third SCS descriptor in frame 1312 indicates that STA 1306 wishes to maintain the third SCS descriptor after roaming from AP 1304 to AP 1302 with no modifications. That is, STA 1306 is not open to negotiating the parameters of the third SCS descriptor.

[0169] In another embodiment, frame 1312 may indicate acceptance or rejection of the second TWT SP. In such an embodiment, frame 1312 may not indicate a third TWT SP as discussed above. In an embodiment, frame 1312 may comprise an indication of link deletion between STA 1306 and AP 1304.

[0170] In another embodiment, frame 1312 may indicate acceptance or rejection of the second SCS descriptor. In such an embodiment, frame 1312 may not indicate a third SCS descriptor as discussed above. In an embodiment, frame 1312 may comprise an indication of link deletion between STA 1306 and AP 1304.

[0171] Frame 1312 may comprise a link reconfiguration notify frame, a roaming announcement notify frame, a roaming announcement request frame, a roaming request frame, a roaming notify frame, a probe request frame, or an ST preparation request. In an example, the ST preparation request may comprise a UHR link reconfiguration request.

[0172] On receiving frame 1312, AP 1304 (or AP 1302) may transmit a frame 1314 indicating acceptance or rejection of the third TWT SP by AP 1302 (or AP 1304).

[0173] On receiving frame 1312, AP 1304 (or AP 1302) may transmit a frame 1314 indicating acceptance or rejection of the third SCS descriptor by AP 1302 (or AP 1304).

[0174] FIG. 14 illustrates an example 1400 of another roaming procedure according to an embodiment. Example 1400 is provided for the purpose of illustration only and is not limiting of embodiments of the present disclosure. As shown in FIG. 14, example 1400 may also include AP 1302, AP 1304, and STA 1306 described above with reference to FIG. 13.

[0175] As shown in FIG. 14, example 1400 begins with AP 1304 transmitting frame 1316, described above, to STA 1306, followed by STA 1306 transmitting frame 1308, described above, to AP 1304.

[0176] On receiving frame 1308, AP 1304 may transmit a frame 1402 to AP 1302. Frame 1402 may contain an indication of the first TWT SP. In an embodiment, frame 1402 may be transmitted over the distribution system (DS).

[0177] In an example, frame 1402 may include a TWT parameter information field as shown in FIG. 5. Alternatively, frame 1402 may include a subset of the fields of the TWT parameter information field shown in FIG. 5. For example, the TWT parameter information field in frame 1402 may indicate one or more of: a typeDocket No.: 24-3050PCT of TWT session (implicit or explicit), a target wake time, a nominal minimum TWT wake duration, a TWT wake interval mantissa, and a TWT wake interval exponent.

[0178] In an embodiment where STA 1306 has the first TWT SP established with AP 1304, AP 1304 may suggest the first TWT SP to AP 1302 in frame 1402. In an embodiment, AP 1304 suggesting the first TWT SP in frame 1402 indicates that AP 1304 wishes to establish the first TWT SP for STA 1306 after roaming from AP 1304 to AP 1302, but may also indicate that AP 1304 is open for negotiating (on behalf of STA 1306) the parameters of the first TWT SP.

[0179] In an embodiment where STA 1306 does not have the first TWT SP established with AP 1304, AP 1304 may request the first TWT SP in frame 1402. In an embodiment, AP 1304 requesting the first TWT SP in frame 1402 indicates that AP 1304 wishes to have the first TWT SP scheduled for STA 1306 once roaming from AP 1304 to AP 1302 happens.

[0180] In an embodiment where STA 1306 has the first TWT SP established with AP 1304, AP 1304 may demand the first TWT SP in frame 1402. In an embodiment, AP 1304 demanding the first TWT SP in frame 1402 indicates that AP 1304 wishes to maintain the first TWT SP for STA 1306 after roaming from AP 1304 to AP 1302 with no modifications. That is, AP 1304 is not open to negotiating (on behalf of STA 1306) the parameters of the first TWT SP.

[0181] On receiving frame 1402, AP 1302 may transmit a frame 1404 to AP 1304 indicating acceptance or rejection of the first TWT SP. In a different embodiment, frame 1404 may indicate the second TWT SP. In an embodiment, frame 1404 indicates the second TWT SP when AP 1302 rejects the first TWT SP indicated in frame 1402. In an example, frame 1404 may be transmitted over the DS.

[0182] In an example, frame 1404 may include a TWT parameter information field as shown in FIG. 5. Alternatively, frame 1404 may include a subset of the fields of the TWT parameter information field shown in FIG. 5. For example, the TWT parameter information field in frame 1404 may indicate one or more of: a type of TWT session (implicit or explicit), a target wake time, a nominal minimum TWT wake duration, a TWT wake interval mantissa, and a TWT wake interval exponent.

[0183] Upon receiving frame 1404, AP 1304 may transmit frame 1310, described above, to STA 1306, followed by STA 1306 transmitting frame 1312, described above, to AP 1304 (or AP 1302). As described above, frame 1310 may indicate the second TWT SP to STA 1306. In an embodiment, frame 1312 may indicate acceptance / rejection of the second TWT SP or may indicate the third TWT SP described above. In an embodiment, upon receiving frame 1312, AP 1304 may transmit a frame 1406 to AP 1302 indicating the third TWT SP. In an embodiment, frame 1406 may be transmitted over the DS.

[0184] In an embodiment where STA 1306 has rejected the second TWT SP, AP 1304 may suggest the third TWT SP to AP 1302 in frame 1406. In an embodiment, AP 1304 suggesting the third TWT SP in frame 1406 indicates that AP 1304 wishes to establish the third TWT SP for STA 1306 after roaming from AP 1304Docket No.: 24-3050PCT to AP 1302, but may also indicate that AP 1304 is open for negotiating (on behalf of STA 1306) the parameters of the third TWT SP.

[0185] In an embodiment where STA 1306 has rejected the second TWT SP, AP 1304 may request the third TWT SP in frame 1406. In an embodiment, AP 1304 requesting the third TWT SP in frame 1406 indicates that AP 1304 wishes to have the third TWT SP scheduled for STA 1306 once roaming from AP 1304 to AP 1302 happens.

[0186] In an embodiment, where STA 1306 has rejected the second TWT SP, AP 1304 may demand the third TWT SP in frame 1406. In an embodiment, AP 1304 demanding the third TWT SP in frame 1406 indicates that AP 1304 wishes to maintain the third TWT SP for STA 1306 after roaming from AP 1304 to AP 1302 with no modifications. That is, AP 1304 is not open to negotiating (on behalf of STA 1306) the parameters of the third TWT SP.

[0187] Upon receiving frame 1406, AP 1302 may transmit to AP 1304 a frame 1408 indicating acceptance or rejection of the third SP TWT SP. In an embodiment, frame 1408 may be transmitted over the DS.

[0188] FIG. 15 illustrate an example 1500 of another roaming procedure according to an embodiment. Example 1500 is provided for the purpose of illustration only and is not limiting of embodiment of the present disclosure. As shown in FIG. 15, example 1500 may also include AP 1302, AP 1304, and STA 1306 described above with reference to FIG. 13. Additionally, example 1500 includes an AP 1502. In an embodiment, AP 1302, AP 1304, and AP 1502 form a multi-AP group.

[0189] As shown in FIG. 15, example 1500 begins with STA 1306 transmitting a frame 1504 to AP 1304. Frame 1504 may be an embodiment of frame 1308 or frame 1312 described above. Upon receiving frame 1504, AP 1304 transmits a frame 1506 to AP 1302 indicating a fourth TWT SP. The fourth TWT SP may be suggested / requested / demanded by STA 1306 or AP 1304. In an example, frame 1506 is an embodiment of frame 1402 and / or frame 1406 described above. In an embodiment, frame 1506 is a unicast frame addressed to AP 1302 as illustrated in FIG. 15. In an embodiment, frame 1506 may be transmitted over the DS.

[0190] Upon receiving frame 1506, AP 1302 transmits a frame 1508 to AP 1304. In an example, frame 1508 is an embodiment of frame 1404 or frame 1408. In an embodiment, frame 1508 may be transmitted over the DS.

[0191] In an example, upon receiving frame 1508, AP 1304 may transmit a frame 1510 to AP 1502 indicating the fourth TWT SP. In an example, frame 1510 is an embodiment of frame 1402 and / or frame 1406 but with AP 1502 as a receiver. In an embodiment, frame 1510 is a unicast frame addressed to AP 1502 as illustrated in FIG. 15. In an embodiment, frame 1510 may be transmitted over the DS.

[0192] In an embodiment, frame 1510 is transmitter after, before, or concurrent with the transmitting of frame 1506.Docket No.: 24-3050PCT

[0193] Upon receiving frame 1510, AP 1502 transmits a frame 1512 to AP 1304. In an example, frame 1512 is an embodiment of frame 1404 or frame 1408 but with AP 1502 as a transmitter. In an embodiment, frame 1512 may be transmitted over the DS.

[0194] In an embodiment, AP 1304 may transmit frame 1510 to AP 1502 based on frame 1508 rejecting the fourth TWT SP suggested / request / demanded by STA 1306 or AP 1304. As such, AP 1304 may repeat the process described in FIG. 15 until AP 1304 receives a frame from an AP that accepts the fourth TWT SP.

[0195] In an embodiment, after receiving frames 1508 and 1510, AP 1304 may transmit a frame 1512 to STA 1306. Frame 1512 may indicate acceptance / rejection of the fourth TWT SP. In an embodiment, frame 1512 may further whether AP 1302 or AP 1502 accepted / rejected the fourth TWT SP. For example, if AP 1302 accepted the fourth TWT SP and AP 1502 rejected the fourth TWT SP, frame 1512 may indicate acceptance by AP 1302 of the fourth TWT SP (rejection by AP 1502 being implied). In another example, frame 1512 may indicate rejection of the fourth TWT SP if both AP 1302 and AP 1502 rejected the fourth TWT SP. In a further example, frame 1512 may indicate acceptance of the fourth TWT SP to indicate acceptance by both AP 1302 and AP 1502 of the fourth TWT SP. In an embodiment, when both AP 1302 and AP 1502 accept the fourth TWT SP, STA 1306 may select between AP 1302 and AP 1502 for roaming from AP 1304.

[0196] In another embodiment, frame 1512 may indicate a fifth TWT SP suggested by AP 1302 and / or a sixth TWT SP suggested by AP 1502. In a further embodiment, AP 1304 may indicate in frame 1512 a single TWT SP selected, by AP 1304, from among the fifth TWT SP and the sixth TWT SP.

[0197] FIG. 16 illustrates an example 1600 of another roaming procedure according to an embodiment. Example 1600 is provided for the purpose of illustration only and is not limiting of embodiment of the present disclosure. As shown in FIG. 16, example 1600 may also include AP 1302, AP 1304, STA 1306, and AP 1502 described above with reference to FIG. 15.

[0198] As shown in FIG. 16, example 1600 begins with STA 1306 transmitting frame 1504, as described above, to AP 1304. Upon receiving frame 1504, AP 1304 transmits a frame 1604 to both AP 1302 and AP 1502 indicating a seventh TWT SP suggested / requested / demanded by STA 1306 or AP 1304. In an example, frame 1604 is an embodiment of frame 1402 or frame 1406. In an embodiment, frame 1604 is a multicast or broadcast frame addressed to AP 1302 and AP 1502 as illustrated in FIG. 16. In an embodiment, frame 1604 may be transmitted over the DS.

[0199] Upon receiving frame 1604, AP 1302 transmits a frame 1606 to AP 1304. In an embodiment, frame 1606 is an embodiment of frame 1404 or frame 1408. In an embodiment, frame 1606 may be transmitted over the DS.

[0200] Upon receiving frame 1604, AP 1502 may transmit a frame 1608 to AP 1304. In an embodiment, frame 1608 is an embodiment of frame 1404 or frame 1408. In an embodiment, frame 1608 may beDocket No.: 24-3050PCT transmitted over the DS. In an embodiment, frame 1608 is transmitted after, before, or concurrent with the transmitting of frame 1606.

[0201] In an embodiment, after receiving frames 1606 and 1608, AP 1304 may transmit to STA 1306 frame 1512 described above.

[0202] FIG. 17 illustrates an example process 1700 according to an embodiment. Example process 1700 is provided for the purpose of illustration only and is not limiting embodiments. Process 1700 may be performed by an STA, such as STA 1306. As shown in FIG. 17, process 1700 may comprise steps 1702 and 1704.

[0203] Step 1702 comprises transmitting, by the STA to a first AP, a first frame comprising a first indication of a transition (roaming) from the first AP to a second AP. In an embodiment, the STA may be associated with the first AP.

[0204] Step 1704 comprises receiving, by the STA from the first AP, a second frame indicating a first TWT SP suggested / indicated by the second AP for the STA.

[0205] In an embodiment, process 1700 further comprises transmitting, by the STA, a third frame in response to the second frame.

[0206] In an embodiment, the third frame indicates a second TWT SP. In an embodiment, the third frame further indicates rejection of the first TWT SP. In an embodiment, the third frame suggests, demands, or requests the second TWT SP.

[0207] In another embodiment, the third frame indicates acceptance or rejection of the first TWT SP. In an embodiment, the third frame comprises an indication of link deletion between the STA and the first AP.

[0208] In an embodiment, process 1700 further comprise receiving, from the first AP, a fourth frame indicating acceptance or rejection of the second TWT SP. In an embodiment, the fourth frame indicates acceptance or rejection, by the first AP or the second AP, of the second TWT SP.

[0209] In an embodiment, the third frame is transmitted to the first AP or to the second AP.

[0210] In an embodiment, the first frame comprises a link reconfiguration notify frame.

[0211] In an embodiment, the third frame comprises a link reconfiguration notify frame.

[0212] In an embodiment, the second frame comprises a link reconfiguration notify frame.

[0213] In an embodiment, the second frame comprises a field indicating parameters for the first TWT SP.

[0214] In an embodiment, process 1700 further comprise receiving, by the STA from the first AP, a fifth frame indicating a third TWT SP scheduled by the first AP for the STA. In an embodiment, the fifth frame comprises a beacon frame or a TWT setup response frame. In an embodiment, the first frame further comprises a second indication of whether the STA accepts modification of the third TWT SP. In an embodiment, the first frame suggests, requests, or demands the third TWT SP.

[0215] In an embodiment, the first frame comprises a TWT request. In an embodiment, the first frame comprises a TWT setup request frame.Docket No.: 24-3050PCT

[0216] FIG. 18 illustrates an example process 1800 according to an embodiment. Example process 1800 is provided for the purpose of illustration only and is not limiting embodiments. Process 1800 may be performed by a first AP, such as AP 1304. As shown in FIG. 18, process 1800 may comprise steps 1802 and 1804.

[0217] Step 1802 comprises receiving, by the first AP from the STA, a first frame comprising a first indication of a transition (roaming) from the first AP to a second AP. In an embodiment, the STA is associated with the first AP.

[0218] Step 1804 comprises transmitting, by the first AP to the STA, a second frame indicating a first TWT SP suggested by the second AP for the STA.

[0219] In an embodiment, process 1800 further comprises receiving, by the first AP from the STA, a third frame in response to the second frame.

[0220] In an embodiment, the third frame indicates a second TWT SP. In an embodiment, the third frame further indicates rejection of the first TWT SP In an embodiment, the third frame suggests, demands, or requests the second TWT SP.

[0221] In another embodiment, the third frame indicates acceptance or rejection of the first TWT SP. In an embodiment, the third frame comprises an indication of link deletion between the STA and the first AP.

[0222] In an embodiment, process 1800 further comprise transmitting, to the STA, a fourth frame indicating acceptance or rejection of the second TWT SP.

[0223] In an embodiment, the fourth frame indicates acceptance or rejection, by the first AP or the second AP, of the second TWT SP. In an embodiment, the first frame comprises a link reconfiguration notify frame.

[0224] In an embodiment, the third frame comprises a link reconfiguration notify frame.

[0225] In an embodiment, the second frame comprises a link reconfiguration notify frame.

[0226] In an embodiment, wherein the second frame comprises a field indicating parameters for the first TWT SP.

[0227] In an embodiment, process 1800 further comprise transmitting, by the first AP to the STA, a fifth frame indicating a third TWT SP scheduled by the first AP for the STA. In an embodiment, the fifth frame comprises a beacon frame or a TWT setup response frame. In an embodiment, the first frame further comprises a second indication of whether the STA accepts modification of the third TWT SP. In an embodiment, the first frame suggests, requests, or demands the third TWT SP.

[0228] In an embodiment, process 1800 further comprise transmitting, by the first AP to the second AP, a sixth frame indicating the third TWT SP to the second AP. In an embodiment, process 1800 further comprise receiving, by the first AP from the second AP, a seventh frame indicating acceptance or rejection of the third TWT SP by the second AP. In another embodiment, the seventh frame indicates the first TWT SP.

[0229] In an embodiment, process 1800 further comprise transmitting, by the first AP to the second AP, an eighth frame indicating the second TWT SP. In an embodiment, process 1800 further comprise receiving, byDocket No.: 24-3050PCT the first AP from the second AP, a ninth frame indicating acceptance or rejection of the second TWT SP by the second AP.

[0230] In an embodiment, the sixth frame comprises a first indication of roaming by the STA from the first AP. In an embodiment, the sixth frame comprises a unicast frame addressed to the second AP. In an embodiment, the sixth frame is further transmitted to a third AP. In an embodiment, the sixth frame is a broadcast frame or a multicast frame.

[0231] In an embodiment, the sixth frame is transmitted via a backhaul channel.

[0232] In an embodiment, process 1800 further comprise transmitting, by the first AP to a third AP, an eleventh frame comprising a third indication of the roaming by the STA from the first AP. In an embodiment, the eleventh frame may further comprise a fourth indication of the third TWT SP. In an embodiment, the transmitting of the eleventh frame is after, before, or concurrent with the transmitting of the tenth frame.

[0233] In an embodiment, process 1800 further comprise receiving, by the first AP from the second AP, a twelfth frame indicating the first TWT SP. In an embodiment, process 1800 further comprise receiving, by the first AP from the third AP, a thirteenth frame indicating a fourth TWT SP suggested by the third AP for the STA. In an embodiment, the second frame further indicates the fourth TWT SP.

[0234] In an embodiment, the first frame comprises a TWT request. In an embodiment, the first frame comprises a TWT setup request frame.

[0235] FIG. 19 illustrates an example process 1900 according to an embodiment. Example process 1900 is provided for the purpose of illustration only and is not limiting embodiments. Process 1900 may be performed by an AP, such as AP 1302, or AP 1502. As shown in FIG. 19, process 1900 may comprise steps 1902 and 1904.

[0236] Step 1902 comprises receiving, by a first AP from a second AP, a first frame comprising a first indication of a transition (roaming) by a STA from the second AP.

[0237] Step 1904 comprises transmitting, by the first AP to the second AP, a second frame indicating a first TWT SP suggested / indicated by the first AP for the STA.

[0238] In an embodiment, the first frame indicates a second TWT SP scheduled by the first AP for the STA.

[0239] In an embodiment, the second frame further indicates acceptance or rejection of the second TWT SP by the first AP. In an embodiment, where the second frame indicates acceptance of the second TWT SP by the first AP, the first TWT SP may be the same as the second TWT SP. In an embodiment, where the second frame indicates rejection of the second TWT SP by the first AP, the first TWT SP may be different than the second TWT SP.

Claims

Docket No.: 24-3050PCTCLAIMS1. A method comprising: receiving, by a station (STA) from a first access point (AP), a first frame indicating a target wake time (TWT) service period (SP) scheduled by the first AP for the STA; transmitting, by the STA to the first AP, a second frame comprising: a first indication of a transition from the first AP to a second AP; and a second indication of whether the STA accepts modification of the TWT SP after transitioning from the first AP to the second AP; and receiving, by the STA from the first AP, a third frame in response to the second frame.

2. A method comprising: transmitting, by a station (STA) to a first access point (AP), a first frame comprising a first indication of a transition from the first AP to a second AP; and receiving, by the STA from the first AP, a second frame indicating a first target wake time (TWT) service period (SP) indicated by the second AP for the STA.

3. The method of claim 2, further comprising transmitting, by the STA, a third frame in response to the second frame, wherein the third frame indicates a second TWT SP.

4. The method of claim 3, wherein the third frame further indicates rejection of the first TWT SP.

5. The method of any of claims 3-4, wherein the third frame comprises an indication of link deletion between the STA and the first AP.

6. The method of any of claims 3-5, further comprising receiving, from the first AP, a fourth frame indicating acceptance or rejection of the second TWT SP.

7. The method of any of claims 3-6, wherein the third frame is transmitted to the first AP or to the second AP.

8. The method of any of claims 2-7, wherein the second frame comprises a field indicating parameters for the first TWT SP.

9. The method of any of claims 2-8, further comprising receiving, by the STA from the first AP, a fifth frame indicating a third TWT SP scheduled by the first AP for the STA.

10. The method of claim 9, wherein the fifth frame comprises a beacon frame or a TWT setup response frame.11 . The method of any of claims 9-10, wherein the first frame further comprises a second indication of whether the STA accepts modification of the third TWT SP.

12. The method of any of claims 2-11 , wherein the STA is associated with the first AP.

13. A method comprising:Docket No.: 24-3050PCT transmitting, by a first access point (AP) to a station (STA), a first frame indicating a target wake time (TWT) service period (SP) scheduled by the first AP for the STA; receiving, by the first AP from the STA, a second frame comprising: a first indication of a transition from the first AP to a second AP; and a second indication of whether the STA accepts modification of the TWT SP after transitioning from the first AP to the second AP; and transmitting, by the first AP to the STA, a third frame in response to the second frame.

14. A method comprising: receiving, by a first access point (AP) from a station (STA), a first frame comprising a first indication of a transition from the first AP to a second AP; and transmitting, by the first AP to the STA, a second frame indicating a first target wake time (TWT) service period (SP) suggested by the second AP for the STA.

15. The method of claim 14, further comprising receiving, by the first AP from the STA, a third frame in response to the second frame, wherein the third frame indicates a second TWT SP.

16. The method of claim 15, wherein the third frame further indicates rejection of the first TWT SP.

17. The method of any of claims 15-16, wherein the third frame comprises an indication of link deletion between the STA and the first AP.

18. The method of any of claims 15-17, further comprising transmitting, to the STA, a fourth frame indicating acceptance or rejection of the second TWT SP.

19. The method of any of claims 14-18, wherein the second frame comprises a field indicating parameters for the first TWT SP.

20. The method of any of claims 14-19, further comprising transmitting, by the first AP to the STA, a fifth frame indicating a third TWT SP scheduled by the first AP for the STA.21 . The method of claim 20, wherein the fifth frame comprises a beacon frame or a TWT setup response frame.

22. The method of any of claims 20-21 , wherein the first frame further comprises a second indication of whether the STA accepts modification of the third TWT SP.

23. The method of any of claims 20-22, further comprising transmitting, by the first AP to the second AP, a sixth frame indicating the third TWT SP to the second AP.

24. The method of claim 23, further comprising receiving, by the first AP from the second AP, a seventh frame indicating acceptance or rejection of the third TWT SP by the second AP.

25. The method of claim 23, further comprising receiving, by the first AP from the second AP, a seventh frame indicating the first TWT SP.

26. The method of any of claims 14-25, further comprising transmitting, by the first AP to the second AP, an eighth frame indicating the second TWT SP.Docket No.: 24-3050PCT27. The method of claim 14, further comprising receiving, by the first AP from the second AP, a ninth frame indicating acceptance or rejection of the second TWT SP by the second AP.

28. The method of any of claims 23-25, wherein the sixth frame comprises a first indication of transition by the STA from the first AP.

29. The method of any of claims 14-28, wherein the STA is associated with the first AP.

30. A method comprising: receiving, by a first access point (AP) from a station (STA), a first frame indicating a first list of streams, established between the first AP and the STA, for which the STA requests resource prioritization from a second AP upon transition to the second AP; transmitting, by the first AP to the second AP, a second frame indicating the first list of streams; and receiving, by the first AP from the second AP, a third frame indicating a second list of streams, among the first list of streams, that are accepted by the second AP.31 . The method of claim 30, further comprising transmitting, by the first AP to the second AP, a fourth frame indicating a first set of links requested by the STA for setup with the second AP.

32. The method of claim 31 , further comprising receiving , by the first AP from the second AP, a fifth frame indicating acceptance by the second AP of setup of a second set of links, among the first set of links, between the second AP and the STA.

33. The method of claim 32, wherein the transmitting the second frame is based on the receiving of the fifth frame.

34. The method of any of claims 30-33, wherein the second frame comprises descriptors corresponding to the first list of streams.

35. A method comprising: receiving, by a first access point (AP) from a second AP, a first frame indicating a first list of streams, established between the second AP and a station (STA), for which the STA requests resource prioritization from the first AP upon transition to the first AP; and transmitting, by the first AP to the second AP, a second frame indicating a second list of streams, among the first list of streams, that are accepted by the first AP.

36. The method of claim 35, further comprising receiving , by the first AP from the second AP, a third frame indicating a first set of links requested by the STA for setup with the first AP.

37. The method of claim 36, further comprising transmitting, by the first AP to the second AP, a fourth frame indicating acceptance by the first AP of setup of a second set of links, among the first set of links, between the first AP and the STA.

38. The method of any of claims 35-37, wherein the first frame comprises descriptors corresponding to the first list of streams.Docket No.: 24-3050PCT39. The method of any of claims 35-38, wherein the first AP accepts or rejects a stream, among the first list streams, based on the STA requesting resource prioritization for the stream.

40. A device comprising: one or more processors; and memory storing instructions that, when executed by the one or more processors, cause the device to perform a method according to any of claims 1-39.41 . A non-transitory computer-readable medium comprising instructions that, when executed by one or more processors, cause the one or more processors to perform a method according to any of claims

Images