Seamless roaming scheduling negotiation

Abstract

: Where STAs having TWT agreements and commitments of QoS need to roam, the roaming may cause a need for renegotiation of the TWT agreements which in turn may cause problems for the QoS requirements. Thus, there is provided a method to reduce problems by comprising receiving, by a first access point (AP) from a station (STA), a first frame inquiring whether a second AP accepts the STA joining a target wake time (TWT) schedule of the second AP if or after the STA roams to the second AP; and transmitting, by the first AP to the STA, a second frame in response to the first frame. There may also be receiving, by a first access point (AP) from a station (STA), a first frame indicating roaming by the STA from the first AP, transmitting, by the first AP to the STA, a third frame indicating a second AP for the roaming by the STA from the first AP, transmitting, by the first AP to the STA, a fourth frame indicating a target wake time (TWT) schedule of the second and the a second frame indicates acceptance or rejection of the inquiry from the STA to join the TWT schedule of the second AP if or after the STA roams to the second AP.

Description

[0001] SEAMLESS ROAMING SCHEDULING NEGOTIATION

[0002] BACKGROUND

[0003] Wireless networks are often required to cater for the mobility of devices connected to them. This mobility may lead to a device distancing itself from the node (such as an access point or base station) with which it has a link (being served by, in other words) and becoming closer to second access point / base station. From a point of view of link bandwidth and reliability, it may be more desirable for it to connect to the second access point i.e. to perform a roaming hand-over.

[0004] Furthermore, it is desirable that the hand-over be executed in a manner that does not disrupt ongoing communications. In general, a device (sometimes referred to as a ‘station’ (STA) or ‘user equipment’ (UE)), prepares the handover by announcing its intention then performing a negotiation. Then, the handover is executed. Roaming may also be referred to as ‘transitioning’.

[0005] SUMMARY

[0006] The present invention is defined in the appended independent claims. Embodiments, aspects and variants are defined in the appended dependent claims.

[0007] In an aspect, a method includes receiving, by a first access point (AP) from a station (STA), a first frame inquiring / requesting whether a second AP accepts the STA joining a target wake time (TWT) schedule of the second AP if or after the STA roams to the second AP; and transmitting, by the first AP to the STA, a second frame in response to the first frame and the response frame may indicating acceptance or rejection of the inquiry from the STA to join the TWT schedule of the second AP if or after the STA roams to the second AP. In a variant, the method may also comprise receiving, by a first access point (AP) from a station (STA), a frame indicating roaming by the STA from the first AP, transmitting, by the first AP to the STA, a response frame indicating a second AP for the roaming by the STA from the first AP and another frame indicating a target wake time (TWT) schedule of the second AP, receiving, by the first AP from the STA, another frame asking whether the second AP accepts the STA joining the TWT schedule of the second AP if or after the STA roams to the second AP.

[0008] Hitherto, roaming of a STA might result in the need for renegotiation of TWT agreement once STA has roamed. During this procedure, the STA might not be able to maintain the QoS of traffic associated with the TWT agreement being negotiated (e.g., traffic with TIDs associated with the original TWT it had before roaming). If the traffic associated with the TWT agreement comprises low latency data, the negotiation delay may cause the low latency data to be delayed or even lost before a TWT SP is re-established. This can lead to a failure to meet QoS requirements for STA 1206 after roaming (e.g., a failure to meet latency and / or minimum latency jitter requirement(s) for low latency traffic). The proposed solution provides a way of allowing the roaming while mitigating the effects of having to renegotiate any TWTs.

[0009] BRIEF DESCRIPTION OF THE DRAWINGS

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

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

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

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

[0014] 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).

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

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

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

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

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

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

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

[0022] FIG. 12 illustrates an example of a problem that may arise for TWT negotiation during a roaming procedure.

[0023] FIG. 13 illustrates an example of a TWT negotiation before a roaming procedure according to an embodiment.

[0024] FIG. 14 illustrates an example of a TWT negotiation before or during a roaming procedure according to an embodiment.

[0025] FIG. 15 illustrates an example of a TWT negotiation before or during a roaming procedure according to an embodiment.

[0026] FIG. 16 illustrates an example process according to an embodiment.

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

[0028] DETAILED DESCRIPTION

[0029] 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 one 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.

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

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

[0032] 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”) 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.

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

[0034] In this disclosure, parameters (or equally called, fields, or Information elements: IES) 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.

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

[0036] 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 programmable 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.

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

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

[0039] 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 110-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.

[0040] 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).

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

[0042] 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).

[0043] 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. 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, 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.

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

[0045] A frequency band may include one or more sub-bands or frequency channels. For example, PPDUs conforming to the IEEE 802.1 In, 802. 1 lac, 802. 1 lax and / or 802. 1 Ibe 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.

[0046] FIG. 2 is a block diagram illustrating example implementations of a STA 210 and an AP 260. As shown in FIG. 2, STA 210 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.

[0047] 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. 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 program 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.

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

[0049] Target wake time (TWT), a feature introduced in the IEEE 802.1 lah 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.

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

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

[0052] 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 SP has elapsed or after receiving an end of service period (EOSP) field equal to 1 from the TWT responding STA, whichever occurs first.

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

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

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

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

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

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

[0059] 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. FIG. 4 illustrates an example 400 of TWT operation in a multi -link environment including an AP multi-link 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 AP3 413 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.

[0060] In an example, STA 421 may transmit a TWT request to AP 411. 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.

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

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

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

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

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

[0066] Referring to FIG. 5, TWT element 500 includes an element ID field, a length field, a control field, and a TWT parameter information field. 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 control 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.

[0067] 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 ).

[0068] 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).

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

[0070] 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).

[0071] 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).

[0072] 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. 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 broadcast TWT response may be used by a TWT responding STA to schedule a TWT for any STA that receives and decodes the TWT element.

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

[0074] 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).

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

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

[0077] 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).

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

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

[0080] 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<TWT wake interval Exponent) y|qeqy^T wake interval mantissa value is indicated in microseconds, base 2 in a TWT wake interval mantissa field of the TWT parameter information field. 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 TWT scheduled STA is expected to be awake to complete frame exchanges for the period of the TWT wake interval.

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

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

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

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

[0085] 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. 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 k 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 multiuser transmissions from one or more STAs 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 711 and STA 12 may respond to the trigger frame by indicating that they are in awake state. In an example, STA 711 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.

[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 711 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 multi-user 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 811, 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 811 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 811 and STA 812 may re-enter the doze state until the start of trigger-enabled TWT SP 820. During trigger-enabled TWT SP 820, AP 810 may transmit a basic trigger frame to STA 811 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 811 and STA 812 may receive DL BUs from AP 810. STA 811 and STA 812 may return to the doze state outside of the TWT SP 720.

[0101] 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 811 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 811 receives a beacon frame from AP 810 at or after TBTT 830, STA 811 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 811 may return to the doze state after a nominal minimum TBTT wake duration time has elapsed from the TBTT start time.

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

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

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

[0105] 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. 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 911 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.

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

[0107] STA 911 may be scheduled to access the medium during the TWT SP 920. STA 911 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.

[0108] 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.11 standard defines a Basic Service Set (BSS) transition process (described in FIG. 11 below) which may be used to transfer the communication session of STA 1006 from AP 1002 to AP 1004.

[0109] FIG. 10 illustrates an example of 1000 of BSS transition according to the IEEE 802.11 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.

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

[0111] 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 1018 is established.

[0112] 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, the IEEE 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.

[0113] 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 FTO 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.

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

[0115] 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 1102 and AP 1104 and STA 1106. STA 1106 may be associated with AP 1102 at the beginning of example 1100 and may have established a secure session 1108 with AP 1102. APs 1102 and AP 1104 can communicate through the DS. STA 1106 is the FTO. AP 1104 is the Target AP.

[0116] The Over-the-DS fast BSS transition may begin with STA 1106 (the FTO) sending an FT request 1110 to AP 1104 (the target AP), via AP 1102. FT request 1110 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 1110 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.

[0117] If the status in FT response 1112 indicates SUCCESS, STA1106 may send a reassociation request frame 1114 to AP 1104. AP 1104 may respond with a reassociation response 1116 to STA 1106.

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

[0119] FIG. 12 illustrates an example 1200 of a problem that may arise for TWT (re)-negotiation during a roaming procedure. As shown in FIG. 12, example 1200 may include an 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. In an example, the SMD may be present in all APs associated to an ESS. As another example, the SMD may be present in a subset of APs associated to an ESS.

[0120] The 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. For example, to avoid reauthentication during roaming, the SMD may have a virtual MAC address associated with it. This virtual MAC address may be used by all the APs that are a part of the SMD, for authentication. STAs connecting to an AP that is part of the SMD for the first time are required to authenticate once. Roaming to another AP that is part of the SMD does not require reauthentication since STAs are associated to the same virtual SMD MAC address.

[0121] In an example, STA 1206 may intend to roam from AP 1204 to AP 1202. Before initiating session transfer from AP 1204 to AP 1202, STA may send a link reconfiguration (LR) request frame 1208 to AP 1204 to initiate the roaming procedure to roam from AP 1204 to AP 1202.

[0122] Upon reception of LR request frame 1208, AP 1204, using the SMD, may send a roaming request (RR) frame 1210 to AP 1202. RR frame 1210 initiates a context transfer from AP 1204 to AP 1202. The context transfer may include TWT agreement information of STA 1206.

[0123] Subsequently, AP 1204 may send a LR response frame 1212 to STA 1206 to indicate acceptance or rejection of the session transfer via roaming. In an example, AP 1204 can receive an indication from AP 1202 of the context parameters that have been transferred successfully and a list of the parameters that need to be renegotiated (e.g., TWT agreement information, SN information, and / or PN information). In an example, AP 1204 may indicate the information received by AP 1202 in frame 1212, to STA 1206, to indicate the context parameters that have been transferred successfully from AP 1204 to AP 1202.

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

[0125] In example 1200, frame 1212 may indicate that TWT agreement information of STA 1206 has not been successfully transferred from AP 1204 to AP 1202. To establish a new TWT agreement between STA 1206 and AP 1202, STA 1206 may start a TWT negotiation by sending a TWT request frame 1214 to AP 1202. AP 1202 may respond with a TWT response frame 1216 accepting the request and establishing the new TWT agreement. STA 1206 may enter a doze state until a TWP SP 1218 of the new TWT agreement begins.

[0126] As described above, the procedure of FIG. 12 may require renegotiation of TWT agreement 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 agreement being negotiated (e.g., traffic with TIDs associated with the original TWT agreement associated with AP 1204). If the traffic associated with the TWT agreement comprises low latency data, the negotiation delay may cause the low latency data to be delayed or even lost before a TWT SP is re-established. This can lead to a failure to meet QoS requirements for STA 1206 after roaming (e.g., a failure to meet latency and / or minimum latency jitter requirement(s) for low latency traffic).

[0127] Embodiments of the present disclosure, as further described below, address the abovediscussed problem of existing technologies. In an aspect, a STA may transmit a first frame to a first AP indicating / requesting a transition (roaming) from the first AP to a second AP. In an embodiment, the first frame may further indicate that the STA inquires / requests (re)-negotiation of a TWT agreement. In another embodiment, the first AP may transmit a second frame indicating an inquiry / request from the STA to negotiate with the second AP the TWT agreement. In an example, the second AP may transmit a third frame to the first AP indicating roaming availability for the STA to roam from the first AP to the second AP. In another embodiment, the first AP may transmit a fourth frame to the STA indicating roaming availability for the STA to roam from the first AP to the second AP. Subsequently, the first AP may transmit a fifth frame to the STA indicating the TWT schedule of the second AP. In an embodiment, STA may transmit a sixth frame inquiring / asking / requesting whether the second AP accepts the STA joining the TWT schedule of the second AP if / after / once the STA roams to the second AP. In an embodiment, the first AP may transmit a seventh frame indicating an inquiry / request from the STA for the STA to join the TWT schedule of the second AP if / after / once the STA roams to the second AP. In an example, the second AP may transmit an eighth frame indicating acceptance or rejection of the inquiry / request from the STA to join the TWT schedule of the second AP if / after / once the STA roams to the second AP. In an embodiment, the first AP may send a ninth frame to the STA indicating acceptance or rejection of the inquiry / request from the STA to join the TWT schedule of the second AP if / after / once the STA roams to the second AP. As such, in an embodiment the STA may avoid renegotiating the TWT schedule after roaming and / or may ensure that the TWT schedule, during and after roaming, maintains an appropriate QoS for traffic between the AP and STA.

[0128] In an embodiment, a first access point (AP) receives, from a station (STA), a first frame indicating a timeout value for roaming, by the STA, from the first AP to a second AP. The first AP and the second AP may be part of a seamless mobility domain (SMD). The first AP may transmit, to the second AP, a context for the roaming. The timeout value may indicate a time after which the second AP is to delete at least a portion of the context. In another embodiment a first AP receives, from a STA, a first frame indicating a timeout value for roaming, by the STA, from a second AP to the first AP. The first AP and the second AP may be part of an SMD. The first AP may receive, from the second AP, a context for the roaming. The timeout value may indicate a time after which the first AP is to delete at least a portion of the context. In another embodiment a first AP transmits, to a STA, a first frame indicating a timeout value for roaming, by the STA, from the first AP to a second AP. The first AP and the second AP may be part of an SMD. The first AP may transmit, to the second AP, a context for the roaming. The timeout value may indicate a time after which the second AP is to delete at least a portion of the context.

[0129] In an embodiment, a first access point (AP) receives, from a station (STA), a first frame indicating a request to update an existing roaming execution time for roaming, by the STA, from the first AP to a second AP. In an embodiment, the first AP and the second AP are part of a seamless mobility domain (SMD). In an embodiment, the roaming execution time relates to a deadline for the STA to begin roaming.

[0130] FIG. 13 illustrates an example 1300 of a TWT (re) -negotiation before 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.11 standard.

[0131] 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 STA 1306 transmitting a frame 1308 to AP 1304. In an embodiment, frame 1308 may indicate roaming by STA 1306 from AP 1304. For example, 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, or a probe request frame. In an embodiment, frame 1308 further comprises an indication of STA 1306 inquiring / requesting (re)-negotiation of a TWT agreement before the roaming procedure begins. As one example, as discussed above, frame 1308 may indicate STA 1306 inquiring / requesting (re) -negotiation of an r-TWT agreement. Further, in an embodiment, frame 1308 may indicate one or more TWT agreements (e.g., one or more r-TWT agreements) for the roaming. For example, frame 1308 may indicate one or more existing TWT agreements between AP 1304 and STA 1306. In an example, these existing TWT agreements may be used (e.g., by AP 1304 and / or AP 1302) to create a new TWT agreement between STA 1306 and AP 1302, or to identify a suitable TWT agreement for AP 1302 to apply to STA 1306. As one example, AP 1302 may modify an existing TWT agreement to accommodate the one or more TWT agreements indicated in frame 1308. As another example, AP 1302 may identify an existing TWT agreement that may be suitable for STA 1306 (e.g., based on the one or more TWT agreements indicated in frame 1308).

[0132] In an embodiment, frame 1308 further comprises a first field indicating a first roaming execution time. For example, a first roaming execution time can correspond to a future start time of a roaming procedure (e.g., initiated by STA 1306 or AP 1304). In one embodiment, a roaming execution time may indicate an average / estimated / approximate value for a time relating to a roaming procedure (e.g., an average / estimated / approximate value for a future start time of the roaming procedure by STA 1306 from AP 1304). Alternatively, a roaming execution time may indicate an exact value for a time relating to a roaming procedure (e.g., an exact value for the future start time of the roaming procedure by STA 1306 from AP 1304). Further, in an embodiment frame 1308 may include an indication of whether the first roaming execution time indicates an average / estimated / approximate value, or an exact value (e.g., a flag). In an embodiment, the roaming execution time may indicate a time of day, a duration, a time period, or any other suitable time. As one example, the roaming execution time may comprise a timeout value. For example, the roaming execution time (e.g., timeout value) may indicate a time after which AP 1302 is to delete at least a portion of the roaming context transferred from AP 1304 to AP 1302 (e.g., transmitted by AP 1304 to AP 1302). The portion of the roaming context may include TWT agreement context, as discussed further below. This is merely an example, and the roaming execution time (e.g., timeout value) may indicate a time after which AP 1302 is to delete any portion of the roaming context, including all of the roaming context, transferred from AP 1304 to AP 1302. For example, the roaming execution time (e.g., timeout value) may indicate a time after which AP 1302 is to delete setup links and context transferred to AP 1302.

[0133] In an embodiment, the roaming execution time (e.g., timeout value) may be indicated in an SMD information element. For example, an SMD information element may provide information related to a SMD. As one example, the SDM information element may include an element ID field (e.g., one octet), a length field (e.g., one octet), an element ID extension field (e.g., one octet), an SMD identifier field (e.g., six octets), an SMD capabilities field (e.g., one octet), and a timeout value field (e.g., two octets). The SMD identifier field may indicate a unique identifier for the SMD, and may be in the format of a MAC address (e.g., a 48-bit MAC address). The SMD capabilities field may include a DL data forwarding field (e.g., 1 bit) and reserved bits (e.g., seven reserved bits). The DL data forwarding field may be set to 1 if forwarding of buffered DL data of a non-AP MLD from a current AP MLD to a target AP MLD is supported by the SMD, and may be set to 0 otherwise. The timeout value field may carry the roaming execution time (e.g., timeout value). The timeout value field may be set to the timeout between a seamless transition (ST) preparation response and a ST execution request, and may be in units of TU that apply across all AP MLDs managed by the SMD management entity (SMD-ME) of the SMD.

[0134] An AP MLD that is managed by an SMD may include an SMD information element in probe response frames. In addition, or alternatively, an SMD information element may be provided as part of a neighbor report element in a BSS transition management request frame and / or neighbor report response frames for a reported AP that is part of a different SMD than a reporting AP. In an embodiment, to perform SMD-level association, a non-AP MLD may initiate association and authentication with the SMD-ME. An SMD information element may be included in the authentication frame when authenticating with the SMD-ME. In addition, or alternatively, an SMD information element may be included in a (re)association request and / or response frame when performing initial association with the SMD-ME. For example, when a robust security network association (RSNA) is established between a non-AP MLD and an SMD-ME, an SMD information element may be included in authentication frames and (re)association request and response frames. In an embodiment, frame 1308 may be a seamless mobility domain basic service set transition preparation request. For example, a seamless mobility domain basic service set transition preparation request may be a UHR link reconfiguration request frame with a type field in the frame set to 0, and may be transmitted by a non-AP MLD to an AP MLD to prepare a target AP MLD.

[0135] On receiving frame 1308, AP 1304 may transmit a frame 1310 to AP 1302 indicating roaming of STA 1306 from AP 1304. In an embodiment, frame 1310 comprises an indication of an inquiry / request from STA 1306 to negotiate with the AP 1302 the TWT agreement (e.g., including an r- TWT agreement as discussed above). In an embodiment, frame 1310 comprises a roaming request frame.

[0136] In another embodiment, frame 1310 further comprise a second field indicating a second roaming execution time. In an example, the second roaming execution time is provided by AP 1304 (e.g., AP 1304 provides an average / estimated / approximate, or exact, future start time of the roaming procedure by STA 1306 from AP 1304). In another example, the second roaming execution time is provided by STA 1306, and it is equal to the first roaming execution time.

[0137] Upon receiving frame 1310, AP 1302 may transmit a frame 1312 to AP 1304 to indicate roaming availability for STA 1306 to roam from AP 1304 to AP 1302. In an embodiment, frame 1312 further comprises an indication of acceptance or rejection of the inquiry / request from STA 1306 to (re)- negotiate the TWT agreement (e.g., including an r-TWT agreement as discussed above). In an 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 agreement (implicit or explicit), a target wake time, a nominal minimum TWT wake duration, a TWT wake interval mantissa, and a TWT wake interval exponent. In an embodiment, frame 1312 may further include a field with a roaming execution time (e.g., the first or second roaming execution time, discussed above, or a different roaming execution time).

[0138] On receiving frame 1312, AP 1304 may transmit frame 1314 to STA 1306 to indicate roaming availability for STA 1306 to roam from the AP 1304 to AP 1302. In an embodiment, frame 1314 further comprises an indication of acceptance or rejection of the inquiry / request from STA 1306 to (re)- negotiate the TWT agreement (e.g., including an r-TWT agreement as discussed above). In an embodiment, frame 1314 may comprise a link reconfiguration notify or a link reconfiguration response frame. Alternatively, or in addition, frame 1314 may indicate one or more TWT agreements (e.g., r-TWT agreements) for use by STA 1306 (e.g., after roaming). For example, frame 1314 may identify one or more TWT agreements using a TWT ID, or another suitable identifier. Frame 1314 may, in one embodiment, also indicate a mapping between one or more existing TWT agreements between STA 1306 and AP 1304, and one or more TWT agreements between STA 1306 and AP 1302. Alternatively, frame 1314 may identify one or more TWT agreements (e.g., for use by STA 1306 and AP 1302 after roaming) without identifying a mapping. In an embodiment, frame 1314 may be a seamless mobility domain basic service set transition preparation response. For example, a seamless mobility domain basic service set transition preparation response may be a UHR link reconfiguration response frame with a type field in the frame set to 0 that is transmitted by an AP MLD to a non-AP MLD as a response to the ST preparation request (e.g., frame 1308, as described above).

[0139] Subsequently, AP 1304 may transmit frame 1316 to STA 1306 to indicate the TWT schedule of AP 1302. In an embodiment, frame 1316 may comprise a beacon frame comprising a TWT element. In an embodiment, the TWT element may indicate a broadcast TWT parameter set. In another embodiment, the broadcast TWT parameter set may indicate a broadcast TWT recommendation field, a restricted TWT traffic info present field, a restricted TWT schedule info field and a restricted TWT DL TID bitmap. In an embodiment, frame 1314 or frame 1316 may include a field with a roaming execution time (e.g., the same roaming execution time included in frame 1312 discussed above, or a different roaming execution time).

[0140] Upon receiving frame 1316, STA 1306 may transmit a frame 1318 to AP 1304 inquiring / asking / reque sting whether AP 1302 accepts STA 1306 joining the TWT schedule of AP 1302 if / after / once STA 1306 roams to AP 1302. In an embodiment, frame 1318 comprises a TWT request frame with the negotiation type field set to 3 and the broadcast TWT ID of the TWT schedule. In another embodiment, frame 1318 further comprises a third field indicating a third roaming execution time.

[0141] On receiving frame 1318, AP 1304 may transmit a frame 1320 to AP 1302 indicating an inquiry / request from STA 1306 for STA 1306 to join the TWT schedule of AP 1302 if / after / once the STA roams to the second AP. In another embodiment, frame 1320 further comprises a fourth field indicating a fourth roaming execution time. In an embodiment, the fourth roaming execution time may indicate a deadline for STA 1306 to roam (e.g., a deadline for STA 1306 to begin roaming, or conclude roaming), after which the (re)-negotiated TWT agreement is no longer valid. As described above, in an embodiment the fourth roaming execution time may indicate an average / estimated / approximate value for the deadline, or may indicate an exact value for the deadline. As one example, as discussed above, the deadline indicated by the fourth roaming execution time may comprise a timeout value. This timeout value may indicate a time after which AP 1302 is to delete at least a portion of the roaming context transferred from AP 1304 to AP 1302 (e.g., the (re)-negotiated TWT agreement). This is merely an example, and the deadline indicated by the fourth roaming execution time (e.g., timeout value) may indicate a time after which AP 1302 is to delete any portion of the roaming context, including all of the roaming context, transferred from AP 1304 to AP 1302.

[0142] On receiving frame 1320, AP 1302 may transmit frame 1322 to AP 1304 indicating acceptance or rejection of the inquiry / request from STA 1306 to join the TWT schedule of AP 1302 if / after / once STA 1306 roams to AP 1302. In an embodiment, frame 1322 further comprise a fifth field indicating a fifth roaming execution time. In an example, the fifth roaming execution time is provided by AP 1302. Upon receiving frame 1322, AP 1304 may transmit frame 1324 to STA 1306 indicating acceptance or rejection of the inquiry / request from STA 1306 to join the TWT schedule of AP 1302 if / after / once STA 1306 roams to AP 1302. In an embodiment, frame 1324 may comprise a TWT response frame. In another embodiment, frame 1324 may comprise a sixth field indicating a sixth roaming execution time. In an embodiment, the sixth roaming execution time matches the fifth roaming execution time. Alternatively, the sixth roaming execution time is provided by AP 1304.

[0143] In an example, STA 1306 is associated with AP 1304 and indicates the intention to (re)- negotiate a TWT agreement before roaming. In an embodiment, STA 1306 may indicate its intention to roam to AP 1302 and initiates the TWT agreement negotiation with AP 1302 through AP 1304. During this period (e.g., before roaming begins), STA 1306 and AP 1304 continue serving traffic associated with the current TWT agreement (e.g., low latency traffic). In an example, AP 1302 accepts the (re)- negotiation and shares its current TWT agreements with AP 1304. In an embodiment, AP 1304 shares the TWT agreements of AP 1302 with STA 1306. STA 1306 requests to join one of the TWT agreements. In an embodiment, AP 1302 agrees to the request of STA 1306, allowing the (e.g., low latency) stream to use one of the TWT agreements once the roaming procedure occurs (e.g. once STA 1306 roams to AP 1302). Thus, in an embodiment and unlike in example 1200, the low latency traffic has a TWT agreement in place once roaming occurs, reducing the negative impact of (re) -negotiating the TWT agreement in the low latency traffic QoS.

[0144] FIG. 14 illustrates example 1400 of a TWT (re)-negotiation before or during a 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 illustrated, AP 1302, AP 1304, and STA 1306 in example 1400 correspond to AP 1302, AP 1304, and STA 1306 described in example 1300. Example 1400 further describes additional embodiments of example 1300, where a new TWT agreement is requested by STA 1306 before or during roaming.

[0145] At the beginning of example 1400, STA 1306 may transmit frame 1402 to AP 1304 to indicate a request to negotiate a new TWT agreement. In an embodiment, frame 1402 may indicate the negotiation of a new individual, broadcast, and / or restricted TWT agreement.

[0146] STA 1306 may further transmit frame 1404 to AP 1304 to indicate roaming by STA 1306 from AP 1304. In an embodiment, STA 1306 may transmit frame 1404 after transmitting frame 1402. Alternatively, STA 1306 may transmit frame 1404 before transmitting frame 1402. In an embodiment, frame 1404 may be an embodiment of frame 1308 discussed in example 1300.

[0147] Upon receiving frame 1402 or 1404, AP 1304 may transmit frame 1406 to AP 1302 to indicate an inquiry / request from STA 1306 for STA 1306 to establish the new TWT agreement with AP 1302 if / after / once the STA roams to AP 1302. In an embodiment, frame 1402 or frame 1404 may comprise a first field indicating a first roaming execution time. As discussed above in example 1300, the first roaming execution time may correspond to a future start time (e.g., an average / estimated / approximate time, or an exact time) of a roaming procedure (e.g., initiated by STA 1306 or AP 1304). In an embodiment, frame 1406 may also include a field indicating a roaming execution time (e.g., the first roaming execution time included in frame 1402 or 1404, or a new roaming execution time determined by AP 1304). As discussed above, as one example the roaming execution time may comprise a timeout value. For example, as discussed above for example 1300 illustrated in FIG. 13, the roaming execution time (e.g., timeout value) may indicate a time after which AP 1302 is to delete at least a portion of the roaming context transferred from AP 1304 to AP 1302 (e.g., transmitted by AP 1304 to AP 1302).

[0148] In an embodiment, on receiving frame 1406 AP 1302 may transmit frame 1408 to AP 1304 to indicate roaming availability for STA 1306 to roam from AP 1304 to AP 1302. For example, frame 1408 may comprise an indication of acceptance or rejection of the inquiry / request from STA 1306 to (re) -negotiate the new TWT agreement. In an embodiment, frame 1408 may be an embodiment of frame 1312 discussed above in example 1300.

[0149] On receiving frame 1408, AP 1304 may transmit frame 1410 to STA 1306 to indicate roaming availability for STA 1306 to roam from AP 1304 to AP 1302. In an embodiment, frame 1410 may be an embodiment of frame 1314 discussed above in example 1300.

[0150] Subsequently, AP 1304 may transmit frame 1412 to STA 1306 indicating acceptance or rejection of the inquiry / request from STA 1306 to create the new TWT agreement with AP 1302 if / after / once STA 1306 roams to AP 1302. In an embodiment, frame 1412 may be an embodiment of frame 1324 discussed above in example 1300.

[0151] In an example, STA 1306 is associated with AP 1304 and indicates the intention to create a new TWT agreement before roaming. In an embodiment, STA 1306 may indicate its intention to roam to AP 1302 and initiate the new TWT agreement negotiation with AP 1302 through AP 1304. During this period (e.g., before or during roaming), STA 1306 and AP 1304 continue serving traffic associated to the current TWT agreement (e.g., low latency traffic). In an example, AP 1302 accepts the new TWT agreement (e.g., creates a new TWT schedule for STA 1306), allowing the (e.g., low latency) stream to use the new TWT agreement once the roaming procedure occurs (e.g. once STA 1306 roams to AP 1302). Thus, in an embodiment and unlike in example 1200, the low latency traffic has a TWT agreement in place once roaming occurs, reducing the negative impact of (re)-negotiating the new TWT agreement in the low latency traffic QoS.

[0152] FIG. 15 illustrates example 1500 of a roaming execution time update before or during a roaming procedure according to an embodiment. Example 1500 is provided for the purpose of illustration only and is not limiting of embodiments of the present disclosure. As illustrated, AP 1302, AP 1304, and STA 1306 in example 1500 correspond to AP 1302, AP 1304, and STA 1306 described in examples 1300 and 1400. Example 1500 further describes additional embodiments of examples 1300 and 1400, where STA 1306 may update a roaming execution time. As discussed above, in an embodiment the roaming execution time (e.g., the roaming execution time being changed / updated) may relate to a deadline for STA 1306 to begin roaming. As one example, as discussed above, the roaming execution time may comprise a timeout value. For example, as discussed above for example 1300 illustrated in FIG. 13, the roaming execution time (e.g., timeout value) may indicate a time after which AP 1302 is to delete at least a portion of the roaming context transferred from AP 1304 to AP 1302 (e.g., transmitted by AP 1304 to AP 1302).

[0153] At the beginning of example 1500, STA 1306 may transmit frame 1502 to AP 1304 to indicate a first change request related to the roaming execution time. In an embodiment, frame 1502 may comprise a TWT request frame or an action frame. As discussed above in example 1300, the roaming execution time may correspond to a future start time (e.g., an average / estimated / approximate time, or an exact time) of a roaming procedure (e.g., initiated by STA 1306 or AP 1304). In an embodiment, STA 1306 provides an initial roaming execution time (e.g., an expected future start time for roaming by STA 1306 from AP 1304) prior to transmitting frame 1502. STA 1306 may update the initial roaming execution time by transmitting frame 1502 to AP 1304 indicating the change request related to the roaming execution time.

[0154] As noted above, STA 1306 may change / update the roaming execution time (e.g., transmit frame 1502) before or during a roaming procedure. As one example, STA 1306 may transmit frame 1502 after roaming preparation has been performed (e.g., with AP 1302). In an embodiment, the roaming execution time (e.g., timeout) is a time between the ST preparation response and ST execution request. In an embodiment, STA 1306 may transmit frame 1502 after AP 1304 has performed at least some roaming preparation with AP 1302 (e.g., after AP 1304 has performed some roaming preparation with AP 1302 or after AP 1304 has completed roaming preparation with AP 1302). In an embodiment, STA 1306 may transmit frame 1502 after an ST preparation response and prior to an ST execution request. In an embodiment, the roaming execution time may indicate a timeout for sending a roaming execution request (e.g., a timeout for sending a roaming execution request after roaming preparation has been performed with AP 1302). Further, in an embodiment, frame 1502 may indicate extending the roaming execution time (e.g., extending a timeout value). Frame 1502 may, in an embodiment, cancel roaming preparation (e.g., cancel roaming preparation that has been performed). Further, STA 1306 may transmit frame 1502 to AP 1302 (e.g., instead of, or in addition to, transmitting frame 1502 to AP 1304).

[0155] Upon receiving frame 1502, AP 1304 may transmit frame 1504 to AP 1302 to indicate a second change request related to the roaming execution time. In an embodiment, the second change request originates from STA 1306, and it is equal to the first change request transmitted by STA 1306 in frame 1502. In another embodiment, the second change request originates from AP 1304.

[0156] Upon receiving frame 1504, AP 1302 may transmit frame 1506 to AP 1304 to indicate acceptance or rejection of the second change request. In a different embodiment, frame 1506 may indicate a third change request originating from AP 1302.

[0157] Upon receiving frame 1506, AP 1304 may send frame 1508 to STA 1306 to indicate acceptance or rejection of the second change request. In a different embodiment, frame 1508 may indicate the third change request. In an embodiment, frame 1508 may comprise a TWT response frame or an action frame.

[0158] In an example, STA 1306 may have successfully (re) -negotiated a TWT agreement with AP 1302, indicating a roaming execution time. In an embodiment, STA 1306 may start the roaming procedure later than the roaming execution time. AP 1302 may reject the TWT agreement if STA 1306 does not begin the procedure before the roaming execution time. STA may have to (re)-negotiate the TWT agreement once the roaming procedure finalizes, causing a degradation of the QoS in a low latency traffic associated to the TWT agreement. In an embodiment, STA 1306 may indicate a change of the TWT roaming execution time to prevent rejection of the TWT agreement by AP 1302 and reduce the negative impact of (re)-negotiating the TWT agreement in the low latency traffic QoS after roaming.

[0159] FIG. 16 illustrates an example process 1600 according to an embodiment. Example process 1600 is provided for the purpose of illustration only and is not limiting embodiments. Process 1600 may be performed by any suitable AP, such as AP 1304 illustrated in FIGS. 13-15. As shown in FIG. 16, process 1600 may comprise steps 1602 and 1604.

[0160] Step 1602 comprises receiving, by a first access point (AP) from a station (STA), a first frame inquiring / asking / requesting whether a second AP accepts the STA joining a target wake time (TWT) schedule of the second AP if / after / once the STA roams to the second AP. The STA may be any suitable STA, such as STA 1306 illustrated in FIGS. 13-15.

[0161] Step 1604 comprises transmitting, by the first AP to the STA, a second frame in response to the first frame.

[0162] In an embodiment, the STA is associated with the first AP.

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

[0164] In an embodiment, the second frame comprises a TWT response frame indicating acceptance or rejection of the inquiry / request from the STA to join the TWT schedule of the second AP if / after / once the STA roams to the second AP.

[0165] In an embodiment, process 1600 further comprises transmitting, by the first AP to the STA, a third frame indicating the TWT schedule of the second AP.

[0166] In an embodiment, the third frame comprises a beacon frame comprising a broadcast TWT element.

[0167] In an embodiment, process 1600 further comprises transmitting, by the first AP to the second AP, a fourth frame indicating an inquiry / request from the STA for the STA to join the TWT schedule of the second AP if / after / once the STA roams to the second AP.

[0168] In an embodiment, the first frame further comprises a first field indicating a first roaming execution time.

[0169] In an embodiment, the first roaming execution time comprises an expected time for the STA to roam from the first AP to the second AP. In an embodiment, the fourth frame further comprises a second field indicating a second roaming execution time.

[0170] In an embodiment, the first roaming execution time equals the second roaming execution time.

[0171] In an embodiment, process 1600 further comprises receiving, by the first AP from the second AP, a fifth frame indicating acceptance or rejection of the inquiry / request from the STA to join the TWT schedule of the second AP if / after / once the STA roams to the second AP.

[0172] In an embodiment, the second frame further comprises a third field indicating a third roaming execution time.

[0173] In an embodiment, the third roaming execution time comprises a first deadline for the STA to roam from the first AP to the second AP.

[0174] In an embodiment, the fifth frame further comprises a fourth field indicating a fourth roaming execution time, the fourth roaming execution time comprising a second deadline for the STA to roam from the first AP to the second AP.

[0175] In an embodiment, the third roaming execution time equals the fourth roaming execution time.

[0176] In an embodiment, process 1600 further comprises receiving, by the first AP from the STA, a sixth frame indicating roaming by the STA from the first AP.

[0177] In an embodiment, the sixth frame comprises a link reconfiguration notify frame, a roaming announcement notify frame, a roaming announcement request frame, a roaming request frame, a roaming notify frame, or a probe request frame.

[0178] In an embodiment, the sixth frame indicates that the STA inquires / requests (re)- negotiation of a TWT agreement.

[0179] In an embodiment, the sixth frame comprises a fifth field indicating a fifth roaming execution time for the STA to roam from the first AP.

[0180] In an embodiment, process 1600 further comprises transmitting by the first AP to the second AP, a seventh frame indicating an inquiry / request from the STA to negotiate with the second AP the TWT agreement.

[0181] In an embodiment, the seventh frame indicates roaming by the STA from the first AP to the second AP.

[0182] In an embodiment, the seventh frame further comprises a sixth field indicating a sixth roaming execution time for the STA to roam from the first AP.

[0183] In an embodiment, the fifth roaming execution time equals the sixth roaming execution time.

[0184] In an embodiment, process 1600 further comprises receiving by the first AP from the second AP, an eighth frame indicating roaming availability for the STA to roam from the first AP to the second AP. In an embodiment, the eighth frame further comprises an indication of acceptance or rejection of the inquiry / request from the STA to negotiate the TWT agreement.

[0185] In an embodiment, process 1600 further comprises transmitting by the first AP to the STA a ninth frame indicating roaming availability for the STA to roam from the first AP to the second AP.

[0186] In an embodiment, the ninth frame further comprises an indication of acceptance or rejection of the inquiry / request from the STA to negotiate the TWT agreement.

[0187] In an embodiment, the ninth frame comprises a roaming response or a link reconfiguration notify frame.

[0188] In an embodiment, the first frame indicates a request to negotiate a new TWT agreement.

[0189] In an embodiment, the second frame comprises a TWT response frame indicating acceptance or rejection of the inquiry / request from the STA to negotiate the new TWT agreement.

[0190] In an embodiment, process 1600 further comprises receiving, by the first AP from the STA, a third frame indicating roaming by the STA from the first AP.

[0191] In an embodiment, the third frame comprises a link reconfiguration notify frame, a roaming announcement notify frame, a roaming announcement request frame, a roaming notify frame, or a probe request frame.

[0192] In an embodiment, process 1600 further comprises transmitting from the first AP to the second AP, a fourth frame indicating an inquiry / request from the STA for the STA to create / negotiate a new TWT schedule with the second AP if / after / once the STA roams to the second AP.

[0193] In an embodiment, the first frame or the third frame further comprises a first field indicating a first roaming execution time.

[0194] In an embodiment, process 1600 further comprises receiving, by the first AP from the second AP, a fifth frame indicating acceptance or rejection of the inquiry / request from the STA to create / negotiate the TWT schedule of the second AP if / after / once the STA roams to the second AP.

[0195] In an embodiment, process 1600 further comprises transmitting by the first AP to the STA, a sixth frame comprising an indication of acceptance or rejection of the inquiry / request from the STA to negotiate the new TWT agreement.

[0196] In an embodiment, the sixth frame comprises a roaming response or a link reconfiguration notify frame.

[0197] In an embodiment, process 1600 further comprises receiving by the first AP from the STA, a tenth frame indicating a change request relating to the roaming execution time.

[0198] 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 a STA, such as STA 1306 illustrated in FIGS. 13-15. As shown in FIG. 17, process 1700 may comprise steps 1702 and 1704. Step 1702 comprises transmitting, by a station (STA) to a first access point (AP), a first frame inquiring / asking / requesting whether a second AP accepts the STA joining a target wake time (TWT) schedule of the second AP if / after / once the STA roams to the second AP. The AP may be any suitable AP, such as AP 1304 illustrated in FIGS. 13-15.

[0199] Step 1704 comprises receiving, by the STA from the first AP, a second frame in response to the first frame.

[0200] In an embodiment, the STA is associated with the first AP.

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

[0202] In an embodiment, the second frame comprises a TWT response frame indicating acceptance or rejection of the inquiry / request from the STA to join the TWT schedule of the second AP if / after / once the STA roams to the second AP.

[0203] In an embodiment, process 1700 further comprises receiving, by the STA from the first AP, a third frame indicating the TWT schedule of the second AP.

[0204] In an embodiment, the third frame comprises a beacon frame comprising a broadcast TWT element.

[0205] In an embodiment, the first frame further comprises a first field indicating a first roaming execution time.

[0206] In an embodiment, the first roaming execution time comprises an expected time for the STA to roam from the first AP to the second AP.

[0207] In an embodiment, the second frame further comprises a second field indicating a second roaming execution time.

[0208] In an embodiment, the second roaming execution time comprises a deadline for the STA to roam from the first AP to the second AP.

[0209] In an embodiment, process 1700 further comprises transmitting, by the STA to the first AP, a fourth frame indicating roaming by the STA from the first AP.

[0210] In an embodiment, the fourth frame comprises a link reconfiguration notify frame, a roaming announcement notify frame, a roaming announcement request frame, a roaming request frame, a roaming notify frame, or a probe request frame.

[0211] In an embodiment, the fourth frame indicates that the STA inquires / requests (re)- negotiation of a TWT agreement.

[0212] In an embodiment, the fourth frame comprises a third field indicating a third roaming execution time for the STA to roam from the first AP.

[0213] In an embodiment, process 1700 further comprises receiving by the STA from the first AP a fifth frame indicating roaming availability for the STA to roam from the first AP to the second AP.

[0214] In an embodiment, the fifth frame further comprises an indication of acceptance or rejection of the inquiry / request from the STA to negotiate the TWT agreement. In an embodiment, the fifth frame comprises a roaming response or a link reconfiguration notify frame.

[0215] In an embodiment, the first frame indicates a request to negotiate a new TWT agreement.

[0216] In an embodiment, the second frame comprises a TWT response frame indicating acceptance or rejection of the inquiry / request from the STA to negotiate the new TWT agreement.

[0217] In an embodiment, process 1700 further comprises transmitting, by the STA to the first AP, a third frame indicating roaming by the STA from the first AP.

[0218] In an embodiment, the third frame comprises a link reconfiguration notify frame, a roaming announcement notify frame, a roaming announcement request frame, a roaming notify frame, or a probe request frame.

[0219] In an embodiment, the first frame or the third frame further comprises a first field indicating a first roaming execution time.

[0220] In an embodiment, process 1700 further comprises receiving by the STA from the first AP, a fourth frame comprising an indication of acceptance or rejection of the inquiry / request from the STA to negotiate the new TWT agreement.

[0221] In an embodiment, the fourth frame comprises a roaming response or a link reconfiguration notify frame.

[0222] In an embodiment, process 1700 further comprises transmitting by the STA to the first AP, a tenth frame indicating a change request relating to the roaming execution time.

[0223] In another embodiment, a process may include receiving, by a first access point (AP) from a station (STA), a first frame indicating a roaming execution time for roaming, by the STA, from the first AP to a second AP. The first AP and the second AP may be part of a seamless mobility domain (SMD). In an embodiment, the roaming execution time comprises a timeout value. In an embodiment, the roaming execution time comprises a deadline relating to the roaming, by the STA, from the first AP to the second AP. In an embodiment, this process further includes transmitting, by the first AP to the second AP, a context for the roaming. The roaming execution time may indicate a time after which the second AP is to delete at least a portion of the context. In an embodiment, the roaming, by the STA, from the first AP to the second AP, does not require reauthentication, based on the first AP and the second AP being part of the SMD. In an embodiment, the first frame further indicates roaming, by the STA, from the first AP to the second AP.

[0224] In another embodiment, a process may include receiving, by a first access point (AP) from a station (STA), a first frame indicating a change / update request related to a roaming execution time for roaming, by the STA, from the first AP to a second AP. In an embodiment, the roaming execution time relates to a future start time of the roaming. In an embodiment, the roaming execution time relates to a deadline for the STA to begin roaming. In an embodiment, the change / update request related to the roaming execution time comprises a request to change an existing first roaming execution time. In an embodiment, the change / update request related to the roaming execution identifies a second roaming execution time, different from the first roaming execution time. In an embodiment, the first AP receives the first frame during a procedure for roaming, by the STA, from the first AP to the second AP. In an embodiment, the first AP receives the first frame after the first AP has performed at least some roaming preparation with the second AP. In an embodiment, the first AP receives the first frame after the first AP has completed roaming preparation with the second AP. In an embodiment, the first frame comprises an action frame. In an embodiment, the roaming execution time comprises a timeout value. In an embodiment, the first AP and the second AP are part of a seamless mobility domain (SMD)

Claims

33CLAIMS:

1. A method comprising : receiving, by a first access point (AP) from a station (STA), a first frame indicating roaming by the STA from the first AP; transmitting, by the first AP to the STA, a second frame indicating a second AP for the roaming by the STA from the first AP; transmitting, by the first AP to the STA, a third frame indicating a target wake time (TWT) schedule of the second AP; receiving, by the first AP from the STA, a fourth frame inquiring whether the second AP accepts the STA joining the TWT schedule of the second AP if or after the STA roams to the second AP; and transmitting, by the first AP to the STA, a fifth frame indicating acceptance or rejection of the inquiry from the STA to join the TWT schedule of the second AP if or after the STA roams to the second AP.

2. A method comprising: receiving, by a first access point (AP) from a station (STA), a first frame inquiring whether a second AP accepts the STA joining a target wake time (TWT) schedule of the second AP if or after the STA roams to the second AP; and transmitting, by the first AP to the STA, a second frame in response to the first frame.

3. The method of claim 2, wherein the STA is associated with the first AP.

4. The method of any of claims 2-3, wherein the first frame comprises a TWT request frame.

5. The method of any of claims 2-4, wherein the second frame comprises a TWT response frame indicating acceptance or rejection of the inquiry / request from the STA to join the TWT schedule of the second AP if or after the STA roams to the second AP.

6. The method of any of claims 2-5, further comprising transmitting, by the first AP to the STA, a third frame indicating the TWT schedule of the second AP.

347. The method of claim 6. wherein the third frame comprises a beacon frame comprising a broadcast TWT element.

8. The method of any of claims 2-7, further comprising transmitting, by the first AP to the second AP, a fourth frame indicating an inquiry from the STA for the STA to join the TWT schedule of the second AP if or after the STA roams to the second AP.

9. The method of claim 8, wherein the first frame further comprises a first field indicating a first roaming execution time.

10. The method of claim 9, wherein the first roaming execution time comprises an expected time for the STA to roam from the first AP to the second AP.

11. The method of any of claims 9-10, wherein the fourth frame further comprises a second field indicating a second roaming execution time.

12. The method of claim 11, wherein the first roaming execution time equals the second roaming execution time.

13. The method of any of claims 2-12, further comprising receiving, by the first AP from the second AP, a fifth frame indicating acceptance or rejection of the inquiry from the STA to join the TWT schedule of the second AP if or after the STA roams to the second AP.

14. The method of claim 13, where the second frame further comprises a third field indicating a third roaming execution time.

15. The method of claim 14, wherein the third roaming execution time comprises a first deadline for the STA to roam from the first AP to the second AP.

16. The method of any of claims 14-15, wherein the fifth frame further comprises a fourth field indicating a fourth roaming execution time, the fourth roaming execution time comprising a second deadline for the STA to roam from the first AP to the second AP.

17. The method of claim 16, wherein the third roaming execution time equals the fourth roaming execution time.

18. The method of any of claims 2-17, further comprising receiving, by the first AP from the STA, a sixth frame indicating roaming by the STA from the first AP.

19. The method of claim 18, wherein the sixth frame comprises a link reconfiguration notify frame, a roaming announcement notify frame, a roaming announcement request frame, a roaming request frame, a roaming notify frame, or a probe request frame.

20. The method of any of claims 18-19, wherein the sixth frame indicates that the STA inquires / requests (re) -negotiation of a TWT agreement.

21. The method of claim 20, wherein the sixth frame comprises a fifth field indicating a fifth roaming execution time for the STA to roam from the first AP.

22. The method of claim 21, further comprising transmitting by the first AP to the second AP, a seventh frame indicating an inquiry from the STA to negotiate with the second AP the TWT agreement.

23. The method of claim 22, wherein the seventh frame indicates roaming by the STA from the first AP to the second AP.

24. The method of claim 23, wherein the seventh frame further comprises a sixth field indicating a sixth roaming execution time for the STA to roam from the first AP.

25. The method of claim 24, wherein the fifth roaming execution time equals the sixth roaming execution time.

26. The method of any of claims 20-25, further comprising receiving by the first AP from the second AP, an eighth frame indicating roaming availability for the STA to roam from the first AP to the second AP.

27. The method of claim 26, wherein the eighth frame further comprises an indication of acceptance or rejection of the inquiry from the STA to negotiate the TWT agreement.

28. The method of any of claims 20-27, further comprising transmitting by the first AP to the STA a ninth frame indicating roaming availability for the STA to roam from the first AP to the second AP.

29. The method of claim 28, the ninth frame further comprising an indication of acceptance or rejection of the inquiry from the STA to negotiate the TWT agreement.

30. The method of claim 29, wherein the ninth frame comprises a roaming response or a link reconfiguration notify frame.

31. The method of claim 4, wherein the first frame indicates a request to negotiate a new TWT agreement.

32. The method of claim 31, wherein the second frame comprises a TWT response frame indicating acceptance or rejection of the inquiry from the STA to negotiate the new TWT agreement.

33. The method of any of claims 31-32, further comprising receiving, by the first AP from the STA, a third frame indicating roaming by the STA from the first AP.

34. The method of claim 33, wherein the third frame comprises a link reconfiguration notify frame, a roaming announcement notify frame, a roaming announcement request frame, a roaming notify frame, or a probe request frame.

35. The method of any of claims 31-34, further comprising transmitting from the first AP to the second AP, a fourth frame indicating an inquiry from the STA for the STA to create / negotiate a new TWT schedule with the second AP if or after the STA roams to the second AP.

36. The method of any of claims 33-35, wherein the first frame or the third frame further comprises a first field indicating a first roaming execution time.

37. The method of claims 31-36, further comprising receiving, by the first AP from the second AP, a fifth frame indicating acceptance or rejection of the inquiry from the STA to create / negotiate the new TWT schedule of the second AP if or after the STA roams to the second AP.

38. The method of any of claims 31-37, further comprising transmitting by the first AP to the STA, a sixth frame comprising an indication of acceptance or rejection of the inquiry from the STA to negotiate the new TWT agreement.

39. The method of claim 38, wherein the sixth frame comprises a roaming response or a link reconfiguration notify frame.3740. The method of any of claims 36-39, further comprising receiving by the first AP from the STA, a tenth frame indicating a change request relating to the first roaming execution time.

41. A method comprising : transmitting, by a station (STA) to a first access point (AP), a first frame indicating roaming by the STA from the first AP; receiving, by the STA from the first AP, a second frame indicating a second AP for the roaming by the STA from the first AP; receiving, by the STA from the first AP, a third frame indicating a target wake time (TWT) schedule of the second AP; transmitting, by the STA to the first AP, a fourth frame inquiring whether the second AP accepts the STA joining the TWT schedule of the second AP if or after the STA roams to the second AP; and receiving, by the STA from the first AP, a fifth frame indicating acceptance or rejection of the inquiry from the STA to join the TWT schedule of the second AP if or after the STA roams to the second AP.

42. A method comprising: transmitting, by a station (STA) to a first access point (AP), a first frame inquiring whether a second AP accepts the STA joining a target wake time (TWT) schedule of the second AP if or after the STA roams to the second AP; and receiving, by the STA from the first AP, a second frame in response to the first frame.

43. The method of claim 42, wherein the STA is associated with the first AP.

44. The method of any of claims 42 - 43, wherein the first frame comprises a TWT request frame.

45. The method of any of claims 42 - 44, wherein the second frame comprises a TWT response frame indicating acceptance or rejection of the inquiry from the STA to join the TWT schedule of the second AP if or after the STA roams to the second AP.

46. The method of any of claims 42 - 45, further comprising receiving, by the STA from the first AP, a third frame indicating the TWT schedule of the second AP.

47. The method of claim 46, wherein the third frame comprises a beacon frame comprising a broadcast TWT element.3848. The method of any of claims 42 - 47, wherein the first frame further comprises a first field indicating a first roaming execution time.

49. The method of claim 48, wherein the first roaming execution time comprises an expected time for the STA to roam from the first AP to the second AP.

50. The method of any of claims 42 - 49, where the second frame further comprises a second field indicating a second roaming execution time.

51. The method of claim 50, wherein the second roaming execution time comprises a deadline for the STA to roam from the first AP to the second AP.

52. The method of any of claims 42 - 51, further comprising transmitting, by the STA to the first AP, a fourth frame indicating roaming by the STA from the first AP.

53. The method of claim 52, wherein the fourth frame comprises a link reconfiguration notify frame, a roaming announcement notify frame, a roaming announcement request frame, a roaming request frame, a roaming notify frame, or a probe request frame.

54. The method of any of claims 52 - 53, wherein the fourth frame indicates that the STA inquires / requests (re) -negotiation of a TWT agreement.

55. The method of claim 54, wherein the fourth frame comprises a third field indicating a third roaming execution time for the STA to roam from the first AP.

56. The method of any of claims 54 - 55, further comprising receiving by the STA from the first AP a fifth frame indicating roaming availability for the STA to roam from the first AP to the second AP.

57. The method of claim 56, the fifth frame further comprising an indication of acceptance or rejection of the inquiry from the STA to negotiate the TWT agreement.

58. The method of claim 57, wherein the fifth frame comprises a roaming response or a link reconfiguration notify frame.3959. The method of claim 54, wherein the first frame indicates a request to negotiate a new TWT agreement.

60. The method of claim 59, wherein the second frame comprises a TWT response frame indicating acceptance or rejection of the inquiry from the STA to negotiate the new TWT agreement.

61. The method of claim 59 - 60, further comprising transmitting, by the STA to the first AP, a third frame indicating roaming by the STA from the first AP.

62. The method of claim 21, wherein the third frame comprises a link reconfiguration notify frame, a roaming announcement notify frame, a roaming announcement request frame, a roaming notify frame, or a probe request frame.

63. The method of any of claims 21-22 wherein the first frame or the third frame further comprises a first field indicating a first roaming execution time.

64. The method of any of claims 19-23, further comprising receiving by the STA from the first AP, a fourth frame comprising an indication of acceptance or rejection of the inquiry from the STA to negotiate the new TWT agreement.

65. The method of claim 24, wherein the fourth frame comprises a roaming response or a link reconfiguration notify frame.

66. The method of any of claims 23-25, further comprising transmitting by the STA to the first AP, a tenth frame indicating a change request relating to the first roaming execution time.

Images