WO2021021105A1

WO2021021105A1 - Systems and methods of client-based wifi channel reservation

Info

Publication number: WO2021021105A1
Application number: PCT/US2019/043946
Authority: WO
Inventors: Teng WEI; Zengbin Zhang; David Chu
Original assignee: Google Llc
Priority date: 2019-07-29
Filing date: 2019-07-29
Publication date: 2021-02-04

Abstract

Systems and methods are provided for predicting, at a client device, a time period during which a data frame of a plurality of data frames is expected to be received via a wireless channel with an access point device, reserving, at the client device, the wireless channel for the access point device to use by transmitting a control frame to the access point device, and receiving, at the client device, the data frame when the wireless channel is reserved.

Description

SYSTEMS AND METHODS OF CLIENT-BASED WIFI CHANNEL RESERVATION

BACKGROUND

[0001] Latency and/or jitter in wireless communications networks, such as WiFi networks, may be due to channel contention. Such channel contention may be from access points (APs) or clients that attempt to compete for transmission opportunities when operating on the same channel. Methods to protect a designated link may include AP-side methods, which cannot be applied without full control of the AP, or client-side methods.

BRIEF SUMMARY

[0002] According to an implementation of the disclosed subject matter, a method is provided that includes predicting, at a client device, a time period during which a data frame of a plurality of data frames is expected to be received via a wireless channel with an access point device, reserving, at the client device, the wireless channel for the access point device to use by transmitting a control frame to the access point device, and receiving, at the client device, the data frame when the wireless channel is reserved.

[0003] According to an implementation of the disclosed subject matter, a system is provided that includes an access point device that receives a plurality of data frames from a server. The system includes a client device to predict a time period during which a data frame of the plurality of data frames is expected to be received via a wireless channel with the access point device, to reserve the wireless channel for the access point device to use by transmitting a control frame to the access point device, and to receive the data frame when the wireless channel is reserved.

[0004] According to an implementation of the disclosed subject matter, means for reserving a wireless channel are provided, including predicting, at a client device, a time period during which a data frame of a plurality of data frames is expected to be received via a wireless channel with an access point device, reserving, at the client device, the wireless channel for the access point device to use by transmitting a control frame to the access point device, and receiving, at the client device, the data frame when the wireless channel is reserved.

[0005] Additional features, advantages, and implementations of the disclosed subject matter may be set forth or apparent from consideration of the following detailed description, drawings, and claims. Moreover, it is to be understood that both the foregoing summary and the following detailed description are illustrative and are intended to provide further explanation without limiting the scope of the claims.

BRIEF DESCRIPTION OF THE DRAWINGS

[0006] The accompanying drawings, which are included to provide a further understanding of the disclosed subject matter, are incorporated in and constitute a part of this specification. The drawings also illustrate implementations of the disclosed subject matter and together with the detailed description serve to explain the principles of implementations of the disclosed subject matter. No attempt is made to show structural details in more detail than may be necessary for a fundamental understanding of the disclosed subject matter and various ways in which it may be practiced.

[0007] FIGS. 1 A-1B show example methods of client-based WiFi channel reservation according to implementations of the disclosed subject matter.

[0008] FIGS. 2A-2G show examples of client-based WiFi channel reservation according to implementations of the disclosed subject matter.

[0009] FIG. 3 shows a system that includes a client device and an access point device according to implementations of the disclosed subject matter.

[0010] FIG. 4 shows a client device according to an implementation of the disclosed subject matter.

[0011] FIG. 5 shows a network configuration according to an implementation of the disclosed subject matter. DETAILED DESCRIPTION

[0012] Interactive streaming of data with cloud-based and/or server based rendering may use a high-quality network which has high throughput, as well as low latency and high stability (i.e., low jitter). The interactive streaming may include video games and/or other video-based streaming, and/or other data streaming applications. Such streaming may be challenging to implement on existing network infrastructure, such as WiFi networks. In a cloud server based rendering system and/or a server based rendering system, periodic inputs from keyboard, controller and/or headset may be sent via WiFi uplink (e.g., from a client device to an access point device via a wireless channel) to the cloud server based rendering system. Data frames and/or video frames may be rendered in the cloud server system based on the received inputs, and may be transmitted to the client via WiFi downlink (e.g., from the access point device to the client device via the wireless channel) to be displayed.

[0013] In one example, uplink traffic may be around 2Mbps (megabits per second), and downlink traffic may be around 40Mbps. In a video, gaming, a VR/AR (virtual

reality/augmented reality), and/or multimedia context, input-to-display latency may be an important metric of the system, as high latency may cause discomfort (e.g., visual discomfort) in user experience.

[0014] One source of the high WiFi latency and/or jitter may be due to WiFi channel contention. Other WiFi transmitters, e.g. other access point device and/or client devices, when operating on the same channel, may compete for transmission opportunities and may cause the designated link (the desired access point device and/or client device) to wait. Heavy contentions may cause packet retransmission, which may cause additional latency.

[0015] In particular, methods on the side of the access point device may not be applied without full control of the access point device. That is, these methods may be applied to the designated uplink for which the transmitter radio is under control. Methods on the side of the client device, such as Call Admission Control (CAC), may be used on the client device to request the access point device to set the designed downlink traffic to be high priority. However, such methods are not widely deployed in current access point devices. [0016] The downlink traffic may be much heavier and more vulnerable to channel contention, and may be difficult to protect without the assistance of the access point device. Due to the highly fragmented access point device market, it may be challenging to deploy any method of protecting the designated link on the side of the access point device.

[0017] Implementations of the disclosed subject matter provide just-in-time wireless channel reservation, which may allow a client device to predict when a next data frame, such as a video frame, is expected to come. The client device may reserve the wireless channel exclusively for the desired access point device to use ahead of time before the data frame is sent. These implementations avoid the latency of channel contention and retransmission of the current systems and techniques described above.

[0018] Implementations of the disclosed subject matter may protect packets by reserving the wireless channel for each data frame. For example, when the data frames are video frames, each frame may have a targeted display time. An estimated time needed to decode the video frame may be subtracted from the latest time that the frame needs to be received by the client device from the access point device. The propagation time of the video frames (from the server and the access point device to the client device) may be estimated, and the client device may transmit a control frame to the access point device to reserve a time window for the transmission of the packets of the video frame from the access point device to the client device via a wireless channel.

[0019] In some implementations, the transmission of a control frame to reserve the wireless channel may be delayed, according to the data frame pacing (e.g., from a server to the access point device). Since the wireless channel may be busy, early arrived packets may be queued in the access point device. In implementations of the disclosed subject matter, a control frame may be transmitted from the client device to the access point device to reserve the wireless channel at a time which is close to the last packet time of a data frame, so that the access point device is able to transmit queued packets at once in one or more aggregated frames.

[0020] FIGS. 1 A-1B show example methods of client-based WiFi channel reservation according to implementations of the disclosed subject matter. FIG. 1A shows an example method 100 that includes operation 102 that may predict, at a client device (e.g., client device 20 shown in FIGS. 3-5 and described below), a time period during which a data frame (e.g., data frame 202 shown in FIGS. 2A-2F) of a plurality of data frames (e.g., data frames 202, 204, 206, 208, and/or 210 shown in FIG. 2C) is expected to be received via a wireless channel (e.g., wireless channel 302 shown in FIG. 3) with an access point device (e.g., access point device 30 shown in FIGS. 3 and 5). Operation 104 may reserve, at the client device, the wireless channel for the access point to use by transmitting a control frame (e.g., control frame 212 shown in FIG. 2B-2F) to the access point device. The control frame may be a request-to-send (RTS) frame (e.g., control frame 212 shown in FIGS. 2B-2F) and/or a clear-to-send (CTS) frame (e.g., control frame 214 shown in FIGS. 2B-2F). In some implementations, the client device may transmit a RTS frame, and the access point device may respond by transmitting a CTS frame, as shown in FIGS. 2B-2F, where the RTS frame may be control frame 212 and the CTS frame may be control frame 214. In some implementations, the request-to-send frame may be a prioritized frame. For example, as shown in FIG. 2F and discussed in detail below, the control frames 212, 214 may be prioritized frames. In some implementations, the method 100 may include determining a time to transmit the control frame based on a pacing of transmissions from a server (e.g., server 13 shown in FIGS. 2A-2F and FIG. 5) to the access point device (e.g., access point device 30 shown in FIGS. 2A-3 and FIG. 5). At operation 106, the client device may receive the data frame when the wireless channel is reserved.

[0021] As shown in FIG. IB, the reservation of the wireless channel at operation 104 may include estimating a propagation time of one or more packets (e.g., packets 220, 222, 224, 226, and/or 228 shown in FIGS. 2A-2F) of the data frame (e.g., data frame 202 shown in FIGS. 2A and 2C-2F) at operation 106, and reserving a time window for receiving the one or more packets of the data frame at operation 108. The wireless channel may be reserved for a predetermined time before a predetermined decode time (e.g., decode 250, 252 shown in FIGS. 2A, 2E, and 2F) to decode the one or more packets of the data frame.

[0022] In some implementations, operation 104 of FIG. 1A may include measuring a reservation delay for reserving the wireless channel (e.g., wireless channel 302 shown in FIG. 3). Based on the measured reservation delay of one or more previous reservations of the wireless channel, the client device (e.g., client device 20 shown in FIGS. 3-5) may compute a weighted average, which may be used to make the next reservation of the wireless channel. [0023] In some implementations, the client device (e.g., client device 20 shown in FIGS. 3-5) may transmit an end frame to reset the wireless channel (e.g., wireless channel 302 shown in FIG. 3) to allow a second client device (e.g., client device 21 shown in FIG. 5) to communicate with the access point device (e.g., access point device 30 shown in FIGS. 2A-3 and FIG. 5). For example, the client device may transmit a contention free-end frame to reset the wireless channel to allow a second client device to communicate with the access point device (e.g., access point device 30 shown in FIGS. 2A-3 and FIG. 5) without having to wait for the end of the reservation of the wireless channel when the client device receives the next data frame. In some

implementations, the client device may transmit a new control frame to cancel the reservation of the wireless channel when a predetermined idling timeout period occurs.

[0024] FIGS. 2A-2F show examples of client-based WiFi channel reservation according to implementations of the disclosed subject matter. In particular, FIG. 2A shows a method of protecting data packets (e.g., packets 220) by reserving a WiFi channel (e.g., wireless channel 302 shown in FIG. 3) of each frame (e.g., frame 202) to be transmitted from an access point device 30 to a client device 20. For example, some implementations of the disclosed subject matter may be used in the transmission of video frames (e.g., for a video game, a VR or AR experience, or the like). Each video frame may have a targeted display time on a display (e.g., display 22 shown in FIG. 4) of the client device. This targeted display time may correspond to a VSYNC time 260. To determine the latest time that a video frame (e.g., frame 202) may be received, the client device may subtract an estimated decode time (i.e., the time to decode the video frame for display) from the targeted display time (VSYNC time 260). The client device may estimate the propagation time, and reserve a time window for the transmission of the packets of the video frame over the wireless channel between the access point device and the client device. In some implementations, the propagation time may include time for packets 220 to be transmitted from the server 13 to the access point device 30, and/or the time for the packets 220 to be transmitted from the access point device 30 to the client device 20.

[0025] As shown in FIG. 2B, a control frame 212 (e.g., an RTS frame) may be transmitted from the client device 20 to the access point device 30 to reserve the time window for the transmission. The control frame 212 may be short, and thus may be unlikely to collide with other data transmitted wirelessly (e.g., data from other clients, or the like). A control frame 214 (e.g., a CTS frame) may be transmitted from the access point device 30 to the client device 20 upon reception of the control frame 212 to control the channel reservation. In some instances, there may be a collision of the control frame 212 or the control frame 214 with another packet (e.g., from client device 21 or another access point device, or the like). For example, FIG. 2C shows collision 216 of control frame 214 with another packet. Collision may be minimized for example, by prioritizing the control frame 214 and/or control frame 216, as discussed below in connection with FIG. 2F.

[0026] As shown in FIG. 2C, the server 30 may be expected to send out the data frame (e.g., frame 202, 204, 206, 208, 210) at a fixed interval (determined by the frame rate). For example, a first VR headset may operate at 75 Hz and a second VR headset may operate at 60 Hz, which translates to 13.33 ms and 16.67 ms frame rates, respectively. The first and second VR headsets may act as client devices, and may receive packets of a data frame from an access point device. The frame’s incoming time interval may be denoted as Ad. Because of the network latency between the server 13 and the access point device 30 (e.g., the latency of network 7 shown in FIG. 5), each data frame (e.g., which may include a plurality of consecutive packets) may not arrive at the access point device 30 at the same pace. The delay of the first packet (e.g. packet 220) between the server 13’s sending time and access point device 30’s receiving time may be designated as At, which is not a fixed value, and may be a random variable over time due to network latency jitter.

[0027] The client device 20 may determine the control frame injection time Af (e.g., RTS injection time) such that the control frame 212 (e.g., RTS frame) is transmitted to the access point 30 just before the packets 220 of data frame 202 (e.g., a video frame) arrive at the access point 30. The transmission of the control frame 212 from the client device 20 to the access point device 30 may be referred to as control frame injection. In some implementations, the client device 20 may select Af= min {At), by observing the network latency jitter over the past period. Once the initial control frame injection time is determined, the remaining injection times for control frames 212 may be determined by the client device 20 based on the server 13’s pacing Ad. [0028] The network condition may change and shift the average network latency value. In this case, the determined control frame injection time may no longer work well because it may either arrive too early or too late. When the determined control frame time is too late, it may be considered a reservation delay or reservation failure, which may be equivalent to no channel reservation. To address this, the client device 20 may track a reservation delay d_d, and maintain it to be a small but non-zero value. If the reservation delay is zero, reserved wireless channel time may be wasted. If the reservation delay exceeds a predetermined threshold, the wireless channel reservation may not occur at all. The client device 20 may detect the reservation delay when it starts receiving the data frame (e.g., a video frame) before triggering the control frame injection.

[0029] Another parameter is the wireless channel reservation duration Av, which may set in a control frame duration field. In some implementations, Av may be equal to the time that access point device 30 takes to receive a data frame, i.e., In some

implementations, due to the network latency jitter, throughput variation, and frame size variation (e.g., where the compression rate may be based on the content), a duration may be selected such that it can provide sufficient protection even under variations, where the client device 20 may set:

[0030] To avoid potentially wasting the idling wireless channel time and disrupting the throughput of other client devices (e.g., client device 21 shown in FIG. 5) of other users, a control frame (e.g., contention free-end (CF End)) may be transmitted by the client device 20 to the access point device 30. The contention free-end control frame may reset the reserved wireless channel, and may allow other devices (e.g., client device 21) to use the wireless channel without having to wait until the end of the reserved duration (e.g., by client device 20). For example, the client device 20 may transmit contention free-end control frame to the access point device 30 when it receives the last packet of the data frame (e.g., a video frame). [0031] In some implementations, a desired wireless channel performance for client devices may have less variation of Ad and shorter duration Dn because it may maximize the possibility of reserving the wireless channel just-in-time, while avoiding wasting the wireless channel time with idling.

[0032] In an example, the distribution of Ad may be determined as the time interval between the starting packet of two consecutive video frames during VR streaming to a client device (e.g., client device 20) from a server (e.g., server 13) via an access point (e.g., access point 30). The Ad value may be based on, for example, a video frame rate and the network quality. In this example, when the wireless channel reservation is started before the expected (or average) video frame start time, the wireless channel may be reserved for 75-95% of video frames before they arrive at the access point device (e.g., from the server over a wired network to the access point, and from the access point to the client device via the wireless channel). The amount of the reservation of the wireless channel may be based on whether the frame rate is, for example, 60 frames per second (FPS), 75 FPS, or any other suitable frame rate, and the network quality.

[0033] Continuing with the above example, the distribution of Dn (i.e., the time interval between the starting packet and end packet of a single video frame) may be determined. The value of assuming the sender (e.g., the access point or the

server) placed the data of a video frame into a network buffer as quickly as possible. For example, when a bandwidth between the network and the server is 200 Mbps, and an average video frame size of 0.33 Mbits, the expected Dn may be 1.65 ms. The expected Dn may change as the video frame size and/or network bandwidth increases or decreases.

[0034] In this example, the measurement result may be that the video frame duration is similar to or the same as the expected frame duration based on the server 13 transmitting the packets of the video frame by following a specific pacing. The default setting may pace packets of a frame evenly.

[0035] Large packet pacing may affect the wireless network (e.g., wireless channel 302 shown in FIG 3) performance. For example, the large packet packing may reserve about 50-75% of the wireless channel for a single VR streaming. This amount of the reservation of the wireless channel may be based on whether the frame rate is, for example, 60 FPS, 75 FPS, or any other suitable frame rate, and the network quality. Having such a reservation may affect the throughput of other devices (e.g., client device 21 shown in FIG. 5). To address this, a tighter pacing may be used that matches with the network bandwidth. In some implementations, this may be addressed by using frame aggregation, which is discussed in detail below.

[0036] The access point device 30 may typically aggregate multiple packets (e.g., into media access control protocol data units (MPDU)) into a single large packet (e.g., a physical protocol data unit (PPDU)) to be transmitted to the client device 20 in order to improve the overall wireless transmission efficiency and throughput.

[0037] With regard to frame aggregation, for packets that are already pushed into a transmission queue, the access point device 30 may aggregate them. For example, the packets may be aggregated such that the number of packets in an aggregated frame is no more than 64, and the total size of an aggregated frame is no larger than 64 KB. The number of packets and the total size of the aggregated frame are merely examples, and other suitable values may be used. For packets that are not pushed into the transmission queue of the access point device 30, it may wait for them to be pushed into the queue, if the access point senses that the wireless channel is idle or is busy. For example, the wireless channel may be sensed as idle when packet inter arrival time is 1 ms or less and/or the total waiting time is about 4 ms or less. These are merely examples of ranges of inter-arrival and total waiting times, and other time ranges may be used to sense that the wireless channel is idle. The wireless channel may be sensed as busy when there is no upper-bound of waiting time (i.e., when the transmission queue keeps growing until channel senses idle).

[0038] Under severe channel contention, the access point device 30 may typically send a larger aggregated frame, because the access point device 30 may have to spend more time on carrier sense multiple access (CSMA), resulting in more packets being pushed into the transmission queue.

[0039] The client device 20 may start to decode the video frame when all packets for a particular frame (e.g., frame 202) are received. In other words, the network latency of the first packet will not affect the input-to-photon latency, as long as the network latency of the last packet remains the same. Given this, along with the wireless frame aggregation property, the channel reservation parameters discussed above may be adjusted so as to increase efficiency.

[0040] As shown in FIG. 2D, implementations of the disclosed subject matter may delay the control frame injection (e.g., transmission of the control frame, such as RTS, from the client device 20 to the access point device 30) based on the data frame pacing. When the wireless channel is busy, early arrived data packets may be queued in the access point device. In some implementations, the client device 20 may transmit the control frame at the time which is close to the last packet time of a data frame (e.g., a video frame), so that the access point device 30 may transmit out the queued packets at once in one or more aggregated frames (e.g., aggregated frame 220a, 222a, 220b). For example, the aggregated frame size may be as large as 64 KB, and the average video frame size for VR traffic may be around 40 KB. Thus, in this example, it may be possible that all packets of a video frame may be encapsulated into a single wireless aggregated frame.

[0041] In some instances, the access point device may be able to transmit (e.g., when the wireless channel is sensed to be idle and a backoff counter zero) even before the receipt of a control frame (e.g., RTS injection). In this case, a data frame (e.g., a video frame) may not be encapsulated into an aggregated frame due to time limitations for larger frame pacing, as discussed above. In some implementations, the channel reservation may still make sure the remaining packets of the data frame (e.g., video frame) are delivered on time. That is, the channel reservation may be bound the latency to the last packet of the data frame (e.g., video frame).

[0042] With frame aggregation, the client device may set the reservation duration Dn' = {Video Frame Size)/ {Wireless Physical Bitrate). In some implementations, for the control frame injection time Af (e.g., RTS frame injection time), the client device 20 may set the frame aggregation to At + Ap— Dn', where Ap is the data frame (e.g., video frame) pacing.

[0043] It may be difficult to observe the frame starting time, frame interval Ad, and frame duration Av, for example, at the side of the access point device 30. The observations may typically be at the client device 20 side. Frames that are ahead of the client device’s VSYNC time (e.g., VSYNC time 260, 262) may not help to reduce the input-to-photon latency. In implementations of the disclosed subject matter, this case may be addressed by delaying the data frame’s reception time until a particular point in time.

[0044] As shown in FIG. 2E, when a data frame (e.g., data frame 202, 204) arrives at the access point device 30, it may be buffered or forwarded to the client device 20 depending on the channel contention. However, the client device 20 may not attempt to reserve the wireless channel until the time becomes t_VSync At decode

wireless transmission d t_/ip backoff - That is, At_AP ackoff may select the maximum value based on the contention window. Once the client device 20 reserves the wireless channel for the access point device 30, the access point device 30 may transmit all the buffered packets at once to the client device 20. The data frame (e.g., data frame 222a) may arrive at the client device 20 just-in-time such that it has enough time to decode (e.g., at decode 250, 252) and display (e.g., at VSYNC time 260, 262). A frame (e.g., data frame 204 having packets 222) may arrive late to the access point device 30, and the access point device 30 may not be able to transmit anything at the time of wireless channel reservation. In this case, the client device 20 may use the CF-End frame as discussed above to cancel the wireless channel reservation after a predetermined idling timeout period. That is, the client device 20 may transmit the CF-End frame to the access point 30 to cancel the wireless channel reservation. Such a late frame may be discarded at the client device 20 because it may eventually miss the VSYNC deadline (e.g., VSYNC time 260, 262).

[0045] As shown in FIG. 2F, one or more of the control frames 212, 214 may be transmitted with a higher quality of service under WiFi Multi-Media (WMM) to improve the chances of reserving the wireless channel. For example, the control frames 212, 214 may be transmitted with the highest level of service (e.g., VI (video)), which may allow the client device 20 to reserve the wireless channel (e.g., wireless channel 302 shown in FIG. 3), as other data packets may likely be transmitted at a BE (best effort) level of service. In the example shown in FIG. 2F, the wireless channel may be reserved 5 ms before a targeted decode time (e.g., decode 250, 252). The 5 ms time is merely an example time, and other times or range of times (e.g., 4-10 ms) may be used. The example 5 ms duration may provide time for the client device 20 to handle any frame jitter of the packets in the data frame being transmitted from the access point device 30. The reservation time may cap the overall ratio of the wireless channel time (i.e., airtime) used by the client device relative to other client devices competing for time with the access point device. For example, a percentage airtime cap (e.g., 25%, 30%, or the like) and video frame rate (e.g., 60 FPS, 75 FPS, or the like) may change the amount of reservation time. In some implementations, a cap may be based on the wireless channel link rate and video frame size. For example,

12*(Video Frame Size)/ {Wireless Physical Bitrate) may indicate that no more than 20% of the airtime may be used for transmitting the data at the current rate. That is, implementations of the disclosed subject matter may limit airtime used by individual client devices to maintain network fairness.

[0046] As described above in connection with FIGS. 2A-2F, each frame (e.g., frame 202,

204, 206, 208, and/or 210) may have a targeted VSYNC time (e.g., VSYNC time 260, 262), which may be the deadline on which the frame needs to arrive at the client device 20. In some instances, the actual VSYNC time for each frame may not be available. To address this, a protection implementation at the client device may infer the protection time by using the

Vi deoReceive Start time and VideoReceiveEnd time of each frame (see, e.g., FIG. 2G). That is, the reservation window may be adapted to make sure the future frames are delivered in time.

[0047] This example protection implementation on the client device may determine when to reserve a wireless channel, and for low long to reserve the wireless channel. To keep up with the data frame rate (e.g., video frame rate) and make sure each frame is transmitted from the access point device 30 before the next frame comes in, the protection implementation may define a virtual deadline for each frame to arrive at the client device 20’ s WiFi interface (e.g., network interface 29 of client device 20 shown in FIG. 4), and use it as an end time to reserve the wireless channel for each frame.

[0048] When fixed-size frames are transmitted in a network with no variation, the last packet of a frame may arrive at the client device 20 in fixed intervals, matching the frame rate. The last packet arrival time may be the virtual deadline. Variations in network bandwidth, the capacity of the access point device 30, the wireless channel bandwidth, and frame size may cause the last packets of frames to be received at varying intervals. To handle such variation, the virtual deadline may shift its schedule to maximize the chance that the last packet of the expected frame being delivered inside the reserved time window, while minimizing the remaining reserved airtime after the last packet. [0049] As shown in FIG. 2G, to find a virtual deadline schedule and handle variable network conditions, the virtual deadline may be adapted by observing previous frames’ arrival time at the interface 29 of the client device 30 (i.e., WiFiReceiveEnd(i)). The frame (e.g., frame 202) may arrive on time when it arrives between the predetermined frame early threshold and

frame late threshold. The virtual deadline may be updated so that the new

VirtualDeadline(i+ 1) is equal to VirtualDeadline(i) + 1/FPS (frame per second). Tuning frame early threshold and/or frame late threshold may be used to trade off late frames versus overall latency. When the frame i (e.g., frame 202) arrives late to the WiFi interface 29 of the client device 20 (i.e., at a time that is later than the frame late threshold), the virtual deadline may be adjusted for the next frame /+ 1 (e.g., frame 204), where VirtualDeadline(i+ 1) may be equal to VirtualDeadline(i) + 1/FPS + deadline step size, and where deadline step size is a fixed value for offseting the current virtual deadline setting. When the frame i (e.g., frame 202) arrives much earlier than the frame early threshold, virtual deadline may be adjusted forward, where VirtualDeadline(i+ 1) is equal to VirtualDeadline(i) + 1/FPS - deadline step size. When a frame is late by a large duration (e.g., WiFiReceiveEnd(i) - VirtualDeadline(i) » delta), the virtual deadline may be adjusted by delta, so that the streaming is robust to, for example, noise that may be introduced by one or more factors (e.g., occasional large frames, WAN/WiFi latency variation, or the like).

[0050] In handling the frame rate variation, the frame rate on the server 13 side may vary, which may confuse the client device 20. That is, the frames may appear to be behind schedule to the client device 20. The frame rate variation may be detected by periodically checking the offset between expected frame index and the most recently received frame index, and resetting the scheduling when it happens. Once the user is playing the actual game (i.e., has advanced past the game start-up phase), the frame rate may be stable.

[0051] As the arrival time of frame i may be observed from the application layer, i.e.

VideoReceiveEnd(i) . The WiFiReceiveEnd(i) may be estimated by subtracting a constant offset, packet reception delay, from VideoReceiveEnd(i) to compensate for application/system/driver introduced latency. In some implementations, a value of lOOps may be used for

packet reception delay, or any other suitable value may be used. The initial virtual deadline for the next frame may be based on the VideoReceivedEnd of the last observed frame, subtracting estimated system latency packet reception delay, and adding 1/FPS.

[0052] In the protection implementation described above, the client device 20 may reserve the wireless channel for a duration that is large enough for the remaining packets of the expected frame to be transmitted by the virtual deadline. Before the channel reservation, some packets of the frame might have arrived earlier, and the access point device 30 may find an opportunity to transmit them to the client device 20, which may not affect the overall latency. That is, for the reservation duration, the operation at the client device 20 may be based on whether the remaining packets may be drained by the virtual deadline of the frame.

[0053] In some implementations, frame buffering status of the access point device 30 and the WiFi channel busy factor may be used to determine whether more protection of the wireless channel is needed. Frame buffering status of the access point device 30 may determine whether the wireless channel can match the WAN speed (of the network 7). Because the client device 20 may infer the buffering status of the access point device 30 from the observations of the client device 20, it might not be accurate as possible. The WiFi channel busy factor may allow the client device to confirm that some WiFi contention is occurring with the WiFi channel.

[0054] If the client device 20 determines that the access point device has started to buffer video frames, the packets of consecutive frames may be likely be transmitted closely in time, as the access point device may not have knowledge on frame boundaries, and may place all the packets in the same queue. Packets from different video frames may be aggregated together. In a case with no buffering, if the access point has capacity to deliver each frame without excessive buffering, the packets of consecutive frames may be likely to be separated in time. For example, a server (e.g., server 13) may use a portion of a reserved time to transmit a frame, while leaving the remaining time unused.

[0055] There may be two exceptions for the frame buffering case. The streamer (e.g., client device 20) may pace the traffic evenly or approximately over the whole frame interval, which may cause consecutive frames to be close to each other. The WAN link (e.g., the network 7 between the server 13 and the access point device 30 shown in FIG. 5) may sometimes function as a bottleneck, which may cause consecutive frames to be close to each other. As the WiFi (e.g., the wireless channel 302 shown in FIG. 3) may not be the bottleneck in these cases, it may be undesirable to increase protection duration erroneously.

[0056] In some implementations, the frame gap parameter may be used by the client device 20 to determine if buffering is occurring at the access point. The frame gap parameter may be the difference between VideoReceiveEnd(i) and VideoReceiveStart(i+ 1) and

channel busy factor.

[0057] Excessive wireless channel reservation may be avoided and/or minimized at the client device 20 by comparing the frame duration, i.e., the duration between the VideoReceiveStart(i) and VideoReceiveEnd(i ), with the reservation duration. If the reservation duration is greater than the frame duration, the protection may be considered as excessive, and the client device 20 may reduce the protection duration for the next frame by duration step size . When the WiFi channel busy factor and frame gap indicate that the WiFi contention is not happening any more, the client device 20 may reduce the protection duration in a stepwise manner. In some implementations, a maximum reservation duration may be set to cap to the reservation duration in order to coexist well with other client devices (e.g., client device 21 shown in FIG. 5) and not use a

predetermined excessive amount of air time. The initial duration may be set at the client device 20 based on the current WiFi link rate and average frame size, i.e. ( Video Frame Size)/ (Wireless Physical Bitrate). The client device 20 may use the protection implementation described above when WiFi is on and the WiFi channel is busy. That is, a WiFi channel busy factor threshold may be used by the client device 20 to determine whether utilize the stream control features described above, or not.

[0058] In some instances, there might not be enough time to use the Virtual Deadline and Reservation adaptation results from frame i to drive the control frame (e.g., the RTS packet) for frame /+1, because the client device may need to wait for frame i to be sent and processed before adaptation may be performed. The client device may detect this situation, and may determine that frame i+2 may be protected instead.

[0059] Under heavy contention, the control frame (e.g., RTS packet) might take more time to be transmitted to the access point device to reserve the wireless channel. As described above in connection with FIG. 2F, a high WMM priority may be used so that the control frame may be transmitted to the access point device. In some implementations, the delay of control frame (e.g., RTS packets) transmission may be tracked. With this information, the client device may transmit the packets earlier in application layer to compensate for the medium access time.

[0060] FIG. 3 shows a system 300 that includes the client device 20, the access point device 30, and the server 13 according to implementations of the disclosed subject matter. The client device 20, the access point device 30, and the server 13 are described in detail below in connection with FIGS. 4-5. The access point device may include one or more of a processor, memory and/or a buffer, at least one wireless communications interface to communicate with the client device 20, and a communication interface to communicate with the server 13. The access point device 30 may be communicatively coupled to the server 13 via the network 7. The access point device may be communicatively coupled to the client device 20 via the wireless channel 302, as described above in connection with FIGS. 1 A-2F. The access point device 30 may transmit data packets of frames via the wireless channel 302 that it receives from the server 13 via the network 7.

[0061] Embodiments of the presently disclosed subject matter may be implemented in and used with a variety of components and network architectures. FIG. 4 is an example client device 20 suitable for implementing embodiments of the presently disclosed subject matter. The client device 20 may be, for example, a virtual reality (VR) or augmented reality (AR) headset, a wearable computing device, a gaming system, a desktop or laptop computer, or a mobile computing device such as a smart phone, tablet, or the like. The client device 20 may include a bus 21 which interconnects major components of the client device 20, such as a central processor 24, a memory 27 such as Random Access Memory (RAM), Read Only Memory (ROM), flash RAM, or the like, a user display 22 such as one or more display screens. The client device 20 may include a user input interface 26, which may include one or more controllers and associated user input devices such as a visual input device, game controller, keyboard, mouse, touch screen, and the like, a fixed storage 23 such as a solid state drive, hard drive, flash storage, and the like, a removable media component 25 operative to control and receive an optical disk, flash drive, and the like, and a network interface 29 operable to communicate with one or more remote devices, such an access point device, via a suitable network connection. [0062] The bus 21 allows data communication between the central processor 24 and one or more memory components, which may include RAM, ROM, and other memory, as previously noted. Typically RAM is the main memory into which an operating system and application programs are loaded. A ROM or flash memory component can contain, among other code, the Basic Input-Output system (BIOS) which controls basic hardware operation such as the interaction with peripheral components. Applications resident with the client device 20 are generally stored on and accessed via a computer readable medium, such as a solid state drive, hard disk drive (e.g., fixed storage 23), an optical drive, floppy disk, or other storage medium.

[0063] The fixed storage 23 may be integral with the client device 20 or may be separate and accessed through other interfaces. The network interface 29 may provide a direct connection to a remote server via a wired or wireless connection. The network interface 29 may provide such connection using any suitable technique and protocol as will be readily understood by one of skill in the art, including WiFi, Bluetooth(R), near-field, digital cellular telephone, and the like. For example, the network interface 29 may allow the computer to communicate with other access point devices and/or computers via one or more local, wide-area, or other communication networks, as described in further detail below.

[0064] Many other devices or components (not shown) may be connected in a similar manner (e.g., document scanners, digital cameras and so on). Conversely, all of the components shown in FIG. 4 need not be present to practice the present disclosure. The components can be interconnected in different ways from that shown. The operation of a computer such as that shown in FIG. 4 is readily known in the art and is not discussed in detail in this application. Code to implement the present disclosure can be stored in computer-readable storage media such as one or more of the memory 27, fixed storage 23, removable media 25, or on a remote storage location.

[0065] FIG. 5 shows an example network arrangement that may include a client device and an access point according to an implementation of the disclosed subject matter. One or more client devices 20, 21, such as a virtual reality (VR) or augmented reality (AR) headset, a wearable computing device, a gaming system, a desktop or laptop computer, or a mobile computing device and the like may connect to other devices via one or more networks 7. Each device 20, 21 may be a client device as previously described. The client devices 20, 21 may have a wireless channel 302 to communicate with an access point device 30. The access point device 30 may be communicatively coupled to the server 13, databases 15, and/or remote platform 17 via the communication networks 7. The access point device 30 may be a WiFi router, a networking router, and/or any suitable network communication device. The network may be a local network, wide-area network, the Internet, or any other suitable communication network or networks, and may be implemented on any suitable platform including wired and/or wireless networks. The devices 20, 21 may communicate with one or more remote devices, such as servers 13 and/or databases 15. The server 13 may be a cloud-based server and/or any other suitable server. The remote devices may be directly accessible by the client devices 20, 21, or one or more other devices may provide intermediary access such as where a server 13 provides access to resources stored in a database 15. The devices 20, 21 also may access remote platforms 17 or services provided by remote platforms 17 such as cloud computing arrangements and services. The remote platform 17 may include one or more servers 13 and/or databases 15.

[0066] More generally, various implementations of the presently disclosed subject matter may include or be embodied in the form of computer-implemented processes and apparatuses for practicing those processes. Implementations also may be embodied in the form of a computer program product having computer program code containing instructions embodied in non- transitory and/or tangible media, such as floppy diskettes, CD-ROMs, hard drives, USB

(universal serial bus) drives, or any other machine readable storage medium, such that when the computer program code is loaded into and executed by a computer, the computer becomes an apparatus for practicing implementations of the disclosed subject matter. Implementations also may be embodied in the form of computer program code, for example, whether stored in a storage medium, loaded into and/or executed by a computer, or transmitted over some transmission medium, such as over electrical wiring or cabling, through fiber optics, or via electromagnetic radiation, such that when the computer program code is loaded into and executed by a computer, the computer becomes an apparatus for practicing implementations of the disclosed subject matter. When implemented on a general-purpose microprocessor, the computer program code segments configure the microprocessor to create specific logic circuits. [0067] In some configurations, a set of computer-readable instructions stored on a computer- readable storage medium may be implemented by a general-purpose processor, which may transform the general-purpose processor or a device containing the general-purpose processor into a special-purpose device configured to implement or carry out the instructions.

Implementations may be implemented using hardware that may include a processor, such as a general purpose microprocessor and/or an Application Specific Integrated Circuit (ASIC) that embodies all or part of the techniques according to implementations of the disclosed subject matter in hardware and/or firmware. The processor may be coupled to memory, such as RAM, ROM, flash memory, a hard disk or any other device capable of storing electronic information. The memory may store instructions adapted to be executed by the processor to perform the techniques according to implementations of the disclosed subject matter.

[0068] The foregoing description, for the purpose of explanation, has been described with reference to specific implementations. However, the illustrative discussions above are not intended to be exhaustive or to limit implementations of the disclosed subject matter to the precise forms disclosed. Many modifications and variations are possible in view of the above teachings. The implementations were chosen and described in order to explain the principles of implementations of the disclosed subject matter and their practical applications, to thereby enable others skilled in the art to utilize those implementations as well as various

implementations with various modifications as may be suited to the particular use contemplated.

[0069] Implementations disclosed herein may include systems, devices, arrangements, techniques, and compositions such as the following:

1. A method comprising:

predicting, at a client device, a time period during which a data frame of a plurality of data frames is expected to be received via a wireless channel with an access point device; reserving, at the client device, the wireless channel for the access point to use by transmitting a control frame to the access point device; and receiving, at the client device, the data frame when the wireless channel is reserved. 2. The method of implementation 1, wherein the control frame is selected at least one from the group consisting of: a request-to-send frame, and a clear-to-send frame.

3. The method of any previous implementation, wherein the request-to-send frame is a prioritized frame.

4. The method of any previous implementation, wherein the reserving further comprises: estimating a propagation time of one or more packets of the data frame; and reserving a time window for receiving the one or more packets of the data frame.

5. The method of any previous implementation, wherein the wireless channel is reserved for a predetermined time before a predetermined decode time to decode the one or more packets of the data frame.

6. The method of any previous implementation, further comprising:

determining a time to transmit the control frame based on a pacing of transmissions from a server to the access point device.

7. The method of any previous implementation, further comprising: measuring a reservation delay for the reserving of the wireless channel; computing a weighted average based on the measured reservation delay; and reserving the wireless channel based on the computed weighted average.

8. The method of any previous implementation, further comprising:

transmitting an end frame to reset the wireless channel to allow a second client device to communicate with the access point device.

9. The method of any previous implementation, further comprising: transmitting a contention tree-end frame to reset the wireless channel to allow a second client device to communicate with the access point device without having to wait for the end of the reservation of the wireless channel when the client device receives the next data frame of the plurality of data frames.

10. The method of any previous implementation, further comprising:

transmitting a new control frame to cancel the reservation of the wireless channel when a predetermined idling timeout period occurs.

11. A system comprising:

an access point device that receives a plurality of data frames from a server; and a client device to predict a time period during which a data frame of the plurality of data frames is expected to be received via a wireless channel with the access point device, to reserve the wireless channel for the access point device to use by transmitting a control frame to the access point device, and to receive the data frame when the wireless channel is reserved.

12. The system of implementation 11, wherein the control frame is selected at least one from the group consisting of: a request-to-send frame, and a clear-to-send frame.

13. The system of any previous implementation, wherein the request-to-send frame is a prioritized frame.

14. The system of any previous implementation, wherein the client device estimates a propagation time of one or more packets of the data frame, and reserves a time window for the access point device to transmit the one or more packets of the data frame.

15. The system of any previous implementation, wherein the wireless channel is reserved for a predetermined time before a predetermined decode time to decode the one or more packets of the data frame. 16. The system of any previous implementation, wherein the client device determines a time to transmit the control frame based on a pacing of transmissions from the server to the access point device.

17. The system of any previous implementation, wherein the client device measures a reservation delay for the reserving of the wireless channel, computes a weighted average based on the measured reservation delay, and reserves the wireless channel based on the computed weighted average.

18. The system of any previous implementation, wherein the client device transmits an end frame to reset the wireless channel to allow a second client device to communicate with the access point device.

19. The system of any previous implementation, wherein the client device transmits a contention free-end frame to reset the wireless channel to allow a second client device to communicate with the access point device without having to wait for the end of the reservation of the wireless channel when the client device receives the next data frame of the plurality of video frames.

20. The system of any previous implementation, wherein the client device transmits a new control frame to the access point device to cancel the reservation of the wireless channel when a predetermined idling timeout period occurs.

21. A means for reserving a wireless channel comprising:

means for predicting, at a client device, a time period during which a data frame of a plurality of data frames is expected to be received via a wireless channel with an access point device; means for reserving, at the client device, the wireless channel for the access point to use by transmitting a control frame to the access point device; and means for receiving, at the client device, the data frame when the wireless channel is reserved. 22. The means of implementation 21, wherein the control frame is selected at least one from the group consisting of: a request-to-send frame, and a clear-to-send frame.

23. The means of any previous implementation, wherein the request-to-send frame is a prioritized frame.

24. The means of any previous implementation, wherein the means for reserving further comprises:

means for estimating a propagation time of one or more packets of the data frame; and means for reserving a time window for receiving the one or more packets of the data frame.

25. The means of any previous implementation, wherein the wireless channel is reserved for a predetermined time before a predetermined decode time to decode the one or more packets of the data frame.

26. The means of any previous implementation, further comprising:

means for determining a time to transmit the control frame based on a pacing of transmissions from a server to the access point device.

27. The means of any previous implementation, further comprising: means for measuring a reservation delay for the reserving of the wireless channel; means for computing a weighted average based on the measured reservation delay; and means for reserving the wireless channel based on the computed weighted average.

28. The means of any previous implementation, further comprising:

means for transmitting an end frame to reset the wireless channel to allow a second client device to communicate with the access point device. 28. The means of any previous implementation, further comprising:

means for transmitting a contention free-end frame to reset the wireless channel to allow a second client device to communicate with the access point device without having to wait for the end of the reservation of the wireless channel when the client device receives the next data frame of the plurality of data frames.

29. The means of any previous implementation, further comprising:

means for transmitting a new control frame to cancel the reservation of the wireless channel when a predetermined idling timeout period occurs.

Claims

1. A method comprising:

predicting, at a client device, a time period during which a data frame of a plurality of data frames is expected to be received via a wireless channel with an access point device;

reserving, at the client device, the wireless channel for the access point to use by transmitting a control frame to the access point device; and

receiving, at the client device, the data frame when the wireless channel is reserved.

2. The method of claim 1, wherein the control frame is selected at least one from the group consisting of: a request-to-send frame, and a clear-to-send frame.

3. The method of claim 2, wherein the request-to-send frame is a prioritized frame.

4. The method of claim 1, wherein the reserving further comprises:

estimating a propagation time of one or more packets of the data frame; and

reserving a time window for receiving the one or more packets of the data frame.

5. The method of claim 4, wherein the wireless channel is reserved for a predetermined time before a predetermined decode time to decode the one or more packets of the data frame.

6. The method of claim 1, further comprising:

7. The method of claim 1, further comprising: measuring a reservation delay for the reserving of the wireless channel;

computing a weighted average based on the measured reservation delay; and

reserving the wireless channel based on the computed weighted average.

8. The method of claim 1, further comprising:

9. The method of claim 1, further comprising:

transmitting a contention free-end frame to reset the wireless channel to allow a second client device to communicate with the access point device without having to wait for the end of the reservation of the wireless channel when the client device receives the next data frame of the plurality of data frames.

10. The method of claim 1, further comprising:

11. A system comprising:

12. The system of claim 11, wherein the control frame is selected at least one from the group consisting of: a request-to-send frame, and a clear-to-send frame.

13. The system of claim 12, wherein the request-to-send frame is a prioritized frame.

14. The system of claim 11, wherein the client device estimates a propagation time of one or more packets of the data frame, and reserves a time window for the access point device to transmit the one or more packets of the data frame.

15. The system of claim 14, wherein the wireless channel is reserved for a predetermined time before a predetermined decode time to decode the one or more packets of the data frame.

16. The system of claim 11, wherein the client device determines a time to transmit the control frame based on a pacing of transmissions from the server to the access point device.

17. The system of claim 11, wherein the client device measures a reservation delay for the reserving of the wireless channel, computes a weighted average based on the measured reservation delay, and reserves the wireless channel based on the computed weighted average.

18. The system of claim 11, wherein the client device transmits an end frame to reset the wireless channel to allow a second client device to communicate with the access point device.

19. The system of claim 11, wherein the client device transmits a contention free-end frame to reset the wireless channel to allow a second client device to communicate with the access point device without having to wait for the end of the reservation of the wireless channel when the client device receives the next data frame of the plurality of video frames.

20. The system of claim 11, wherein the client device transmits a new control frame to the access point device to cancel the reservation of the wireless channel when a predetermined idling timeout period occurs.