Ultra-low latency operation mode implementation in a radio network controller

Abstract

Ultra-low latency operation mode implementations in a wireless network controller are disclosed. The disclosed implementations describe techniques to implement an operation mode change of a wireless connection between a first communication device (CD) and a second CD. In example implementations, the disclosed techniques can include detecting, by a wireless network controller of the second CD, an indication that the first CD has requested an operation mode change from a first operation mode to a second operation mode. The disclosed techniques can also include modifying transmission information (TI) associated with one or more frames in a transmission queue of the second CD, the TI including representations used by a physical layer of the second CD to configure transmission of the respective frames to the first CD, wherein the one or more frames in the transmission queue have been previously programmed with first mode TI, and wherein the modification to the TI is to second mode TI.

Description

[0001] Cross-reference of related applications

[0002] This application claims the benefit of U.S. Provisional Application No. 63 / 069,639, filed August 24, 2020, the entire contents of which are incorporated herein by reference. Technical Field

[0003] This disclosure relates to wireless networks; more specifically, to implementing rapid operating mode changes to improve the performance of wireless networks. Background Technology

[0004] Wireless networks typically have connections whose throughput varies depending on intrinsic conditions (e.g., the capabilities and configuration of the devices connected to the network) and extrinsic conditions (e.g., the conditions of electromagnetic wave propagation in the environment). Access points may support specific bandwidths, while some stations connected to the access point may be able to utilize the full bandwidth or only a portion of it. Stations and access points can establish wireless connections using operating modes based on the intersection of the capabilities of the two devices. For example, an operating mode established by two devices may have the smaller of the bandwidths of the access point and the station. Sometimes, intrinsic or extrinsic conditions change over time, forcing devices connected to the wireless network to modify their operating modes. Changes to operating modes require time to execute and can therefore lead to increased data transmission latency, adversely affecting the overall performance of the network. Summary of the Invention

[0005] One aspect of this disclosure discloses a method for changing the operating mode of a wireless connection between a first communication device (CD) and a second CD, the method comprising: detecting, by a radio network controller of the second CD, an indication that the first CD has requested a change of operating mode from a first operating mode to a second operating mode; and modifying, by the radio network controller, transmission information (TI) associated with one or more frames in a transmission queue of the second CD, the TI including representations used by the physical layer of the second CD to configure transmission of the corresponding frames to the first CD, wherein one or more frames in the transmission queue were previously associated with a first mode TI, and wherein the modification of the TI is to change it to a second mode TI.

[0006] Another aspect of this disclosure discloses an apparatus including: a memory; and a processing means coupled to the memory, the processing means being configured to: detect an indication that a communication device CD has requested a change in operating mode from a first operating mode to a second operating mode for wireless connection; and modify transmission information TI associated with one or more frames in a transmission queue using the CD, the TI including representations used by a physical layer communicatively coupled to the processing means to configure the transmission of the corresponding frames to the CD, wherein one or more frames in the transmission queue have previously been programmed using the first mode TI, and wherein the modification of the TI is to change it to the second mode TI.

[0007] Another aspect of this disclosure discloses a system comprising: one or more antennas; a physical layer of a second communication device CD, the physical layer being configured to transmit one or more frames in a transmission queue of the second CD to a first CD via one or more antennas based on transmission information TI associated with corresponding frames; and a media access control (MAC) layer of the second CD, communicatively coupled to the physical layer, the MAC layer being configured to: program the TI associated with one or more frames in the transmission queue to a first operating mode of the first CD; detect an indication that the first CD has requested a change in operating mode of the wireless connection between the first CD and the second CD from the first operating mode to a second operating mode; and reprogram the TI associated with one or more frames in the transmission queue to the second operating mode. Attached Figure Description

[0008] Figure 1 An exemplary implementation of a wireless network with one or more access points and one or more station devices is shown, the performance of which can be optimized by a network controller capable of enabling rapid changes in operating modes.

[0009] Figure 2 This is a block diagram of an exemplary architecture of a device including a network controller capable of rapidly and efficiently changing operating modes in a wireless network, according to some implementations of this disclosure.

[0010] Figure 3 This is a block diagram illustrating example operations for rapid and efficient mode-changing in a wireless network using an ultra-low latency network controller, according to some implementations of this disclosure.

[0011] Figure 4 This is a block diagram illustrating example operations for rapid and efficient changes in operating modes in a wireless network including conventional devices, based on some implementations of this disclosure.

[0012] Figure 5This is a flowchart illustrating an example method for a fast and efficient change of operating mode in a wireless network, performed by a response device according to some implementations of this disclosure.

[0013] Figure 6 This is a flowchart illustrating an example method for a fast and efficient change of operating mode in a wireless network, executed by an initiating device, based on some implementations of this disclosure.

[0014] Figure 7 The advantages of the disclosed implementation are shown by comparing the latency in a conventional wireless device (top figure) with the latency in a wireless device with ULOME functionality (bottom figure). Detailed Implementation

[0015] This disclosure relates to a rapid implementation of changes in the Operating Mode (OM) of connections for various devices supported in a wireless network. An Access Point (AP) can provide wireless network services to multiple Stations (STs) (e.g., client devices). The OM established during the initial connection negotiation between the AP and STAs may be changed (multiple times). For example, an AP with four antennas supporting four spatial streams (SSs) with a maximum bandwidth of 160 MHz and a STA with two antennas (supporting two SSs) with a maximum bandwidth of 80 MHz can initially establish a first OM characterized by one SS and 80 MHz bandwidth if the STA's second antenna is currently experiencing interference that hinders its effective reception and transmission of data. Over time, the STA's wireless chip may overheat, and the STA may initiate an OM change to a second OM with one SS and 40 MHz bandwidth to reduce the STA chip temperature. At a later time, when the amount of interference in the network decreases, the second STA antenna may become available. Therefore, the STA can initiate another OM change to a third OM with two SSs and 40 MHz bandwidth, and so on.

[0016] Changing the OM (Original Name) can be time-consuming. For example, to implement a change under the Ultra High Throughput (VHT) IEEE 802.11ac standard, the first device (either a STA or AP if the change is initiated by an AP) might need to place an action frame at the end of the queue of other data frames scheduled to be sent to the second device. The action frame includes an OM notification element that signals to the other device that the first device is requesting the OM change. The second device eventually receives the action frame. The second device's Media Access Control (MAC) layer processes the action frame, acknowledges the OM change, and begins using the new OM. This process is slow and can take several milliseconds or longer to complete the OM change. Furthermore, previously queued but not yet sent frames will still be sent using the old OM settings.

[0017] Newer standards—such as High-Efficiency Wireless (HEW) IEEE 802.11ax—allow for more efficient OM change mechanisms. OM change indicators can be inserted into the High Throughput Control (HTC) field of the MAC header of frames transmitted over a wireless connection. The aspects and implementations disclosed herein overcome the aforementioned challenges and significantly reduce latency involved in OM change processing. A network controller that efficiently utilizes OM change indicators that can be transmitted using Quality of Service (QoS) data frames is disclosed.

[0018] The network controller may have upper-layer MAC functions and lower-layer MAC functions, which may be implemented on separate chips or on a single chip. The upper-layer MAC may receive data packets (e.g., from a host device), generate data frames, and place the data frames in a transmission queue. The upper-layer MAC may also provide a transmission descriptor based on the current OM (Original Mode Change) to the data frame. The upper-layer MAC may also perform monitoring of external and internal conditions that may trigger OM changes. The transmission descriptor may be used to provide instructions to the physical layer (PHY) on how to transmit data frames over the wireless network. Mode change operations may be a cooperative process involving an OM change initiating device (“initiating device”) and an OM change responding device (“responding device”). The upper-layer MAC of the initiating device may determine the OM change to be performed. The lower-layer MAC of the initiating device may introduce an OM change indicator in an appropriate field of the frame (e.g., the first frame in the transmission queue and / or subsequent packets in the queue) without changing the transmission descriptor. The lower-layer MAC of the responding device, having received a data packet with an OM change indicator, can begin modifying the transport descriptors in the responding device's transport queue. The modified transport descriptors instruct the responding device's PHY layer to transmit frames in the transport queue using the new OM mode as specified in the OM change indicator received from the initiating device. Modification of the transport descriptors may include rewriting the values ​​in the transport descriptors corresponding to the old OM using values ​​corresponding to the new OM. Furthermore, the upper-layer MAC of the responding device can begin providing transport descriptors to new frames (added later in the responding device's queue) to instruct the PHY layer to transmit new frames based on the new OM. The upper-layer MAC can transmit the identifier of the oldest frame (or the most recent frame with the old descriptor) with the new descriptor to the lower-layer MAC to notify the lower-layer MAC when to stop reprogramming the descriptors from the old OM to the new OM. The lower-layer MAC of the responding device can also generate an acknowledgment frame to confirm to the initiating device that the transition to the new OM has been performed.

[0019] Conversely, the lower-layer MAC of the initiating device, having detected receiving an acknowledgment (e.g., an ACK frame) from the responding device (and thus detecting that the requested change to the OM has been accepted), begins modifying the transport descriptors in the initiating device's transport queue to instruct the initiating device's PHY layer to use the new OM mode to transmit frames in the (initiating device's) transport queue. Furthermore, the upper-layer MAC of the initiating device can begin providing transport descriptors under the new OM to new frames (added later in the initiating device's queue). The upper-layer MAC can also notify the lower-layer MAC when to stop reprogramming descriptors from the old OM to the new OM.

[0020] Therefore, both devices can switch to the new OM extremely quickly, without waiting until the entire queue of data packets already programmed with the old OM (by either device) is sent. The reduction in latency can be quite significant. For example, using existing techniques, it might take tens of milliseconds (or more) to cycle through the queue of data frames already programmed by the initiating device, send the OM change action frame, have the action frame detected and processed by the responding device, send an acknowledgment frame, and have the responding device send the queue of data frames programmed before the implementation of the new OM, etc. On the other hand, the fast OM change processing implemented by the network controller disclosed herein may only take tens of microseconds (or less).

[0021] In some implementations, as disclosed in more detail below, improved OM change processing can also be achieved when only one of the devices (e.g., the responding device) has a fast network controller while the other device (e.g., the initiating device) is a legacy device. In such an implementation, the lower-layer MAC of the responding device can begin modifying the transport descriptor as soon as it receives the request to change the OM from the legacy initiating device, while the upper-layer MAC of the responding device begins programming new data packets using the new transport descriptor.

[0022] Figure 1 An exemplary implementation of a wireless network 100 with one or more access points and one or more station devices is shown, the performance of which can be optimized by a network controller capable of enabling rapid changes in operating modes. The wireless network 100 may be a wireless local area network (WLAN), a wireless wide area network (WWAN), a wireless metropolitan area network (WMAN), a wireless personal area network (PAN), etc. In one implementation, the wireless network 100 may have one or more access points (base stations), for example, an AP 102 equipped with one or more antennas 106(1)...106(N) capable of supporting various spatial streams (SS) of wireless signals. Wireless connectivity can use any frequency band, such as the 2.4 GHz modulation domain, the 5 GHz domain, the 60 GHz domain, the 6 GHz domain, or any other frequency band.

[0023] In some implementations, AP 102 may include multiple access points (e.g., a first AP operating in a first frequency band (e.g., 2.4 GHz) and a second AP operating in a second frequency band (e.g., 5 GHz)). The multiple access points may use the same or separate antennas 106, some of which may be multiple-input multiple-output (MIMO) antennas. AP 102 may include an ultra-low latency OM implementation controller (ULOME) 104 to implement the above-described and relative... Figures 2 to 4 More detailed disclosure of rapid OM changes. ULOME 104 can be integrated into AP 102 or can communicate with AP 102 electronically or wirelessly.

[0024] Wireless network 100 can support multiple stations (STAs), such as client devices, for example, STA 110 and STA 111. Some of the stations may include similar ULOME controllers. For example, STA 110 may include ULOME 114. Some of the stations (e.g., STA 111) may be legacy stations without ULOME functionality. Wireless connections between access points and stations (or peering connections between different stations and / or different access points) may have different maximum supported SS counts and different maximum bandwidths (referred to herein as the OM of the connection). For example, as Figure 1 As schematically depicted, the wireless connection between AP 102 and STA 110 can have two spatial streams 120(1) and 120(2) implemented by AP antenna 106(1) and AP antenna 106(2), and STA antenna 116(1) and STA antenna 116(2). During the duration of the wireless connection, some of the SSs may become unavailable, for example, due to excessive interference that could render one or more SSs ineffective for the wireless connection. For example, SS 120(2) may become ineffective at some point. Furthermore, the bandwidth of the connection may change over time (up or down). For example, as indicated by the dashed lines, the bandwidth may change from, for example, 40MHz (solid and dashed lines 120(1)) to 20MHz (solid line 120(1) only). In response to changing conditions, individual access points and stations may change the OM mode of the connection from time to time (e.g., for maximum efficiency).

[0025] As disclosed below, various aspects and implementations of this disclosure utilize a ULOME controller to address efficient and rapid OM changes. In some implementations, only one device (e.g., AP102) with a wireless connection (e.g., connection 120(3)) can have ULOME functionality. In such implementations, efficient OM changes supporting ULOME can still be achieved, for example, when the initiating device is a legacy device (e.g., STA111) and the responding device is a ULOME-equipped device (e.g., AP102).

[0026] Wireless Network 100 can be implemented in urban environments, commercial environments, office environments, home environments, automotive environments (or any other transportation environment).

[0027] Figure 2 This is a block diagram of an exemplary architecture of a device 200, including a network controller capable of rapid and efficient change of operating mode in a wireless network, according to some implementations of this disclosure. Figure 2 Some of the components shown may be optional. The illustrated architecture may include a host device 202 having an application 204 instantiated thereon that exchanges data with other devices on the network. The host device 202 may be any computing device, such as a desktop computer, server, laptop computer, tablet computer, smartphone, IoT device, smart controller, video device, audio device, or any other device that may be part of a wireless network (e.g., network 100). The application 204 may be any application that can operate on the host device 202 (e.g., browser, graphics application, word processing application, operating system, virtual machine, etc.). The application 204 instantiated on the host device 202 may prepare output transmission data, such as TX data 206 that may include multiple TX data packets 207. The term "data packet" should be understood to include any part of a data packet, such as a data segment, data string, etc. The data payload of each data packet is depicted using white rectangles. Various metadata that may be used by the host device 202 or by the network layer of the Open Systems Interconnection (OSI) is depicted using gray squares. Metadata can describe the nature of data packets (e.g., video, audio, network content, etc.), the priority of the data (e.g., high, normal, low), or any other type of information describing the data packets. Furthermore, application 204 can receive input transmission data, such as RX data 208 which may include multiple RX data packets 209. TX data packets 207 and RX data packets 209 can be transmitted to a network controller. The network controller can be a ULOME controller, such as ULOME 220.

[0028] TX data packets 207 can be transmitted via network interface 210. To connect host device 202 to the network controller, any suitable type of network interface 210 can be used, such as a Peripheral Component Interconnect Fast (PCIe) interface, a Secure Digital Input / Output (SDIO) interface, a Universal Serial Bus (USB) interface, or any other similar type of parallel or serial connection. Network interface 210 may include the OSI network layer (not explicitly shown).

[0029] The ULOME 220 may include multiple blocks, such as the upper MAC layer (UMAC) 230, the lower MAC layer (LMAC) 250, and the physical layer (PHY) 270. UMAC 230 and LMAC 250 may constitute an OSI data link layer. In some implementations, the different layers of the ULOME 220 are implemented on a single die. In other implementations, one or more chips may be used to house the individual layers of the ULOME 220. For example, UMAC 230 and LMAC 250 may be implemented on a single chip, and PHY 270 may be implemented on a separate die. In another example, all three layers may be implemented as separate devices. In the implementation where UMAC 230 and LMAC 250 are implemented on a single chip, references to UMAC 230 and LMAC 250 should be understood as references to the corresponding functions provided by UMAC 230 and LMAC 250, rather than references to the actual physical location of the referenced functions.

[0030] UMAC 230 may include an internal monitoring module 232 and an external monitoring module 234. Internal monitoring 232 can monitor the internal state of ULOME 220, including parameters such as the temperature of ULOME 220 or any of its components (if implemented individually), the voltages applied to the various modules and components of ULOME 220, and other physical parameters that may be related to the selection of the OM (Original Memory) for network connection. External monitoring 234 can monitor conditions unrelated to ULOME 220, such as the amount of interference experienced by the various SS (Security Streams) and / or antennas. Information collected by internal monitoring 232 and external monitoring 234 can be provided to the Transmission Governor (T-GOV) function 240, where decisions regarding the OM can be made. Other tasks that can be performed by T-GOV 240 include: notifying LMAC 250 of decisions regarding changes to the OM of device 200, detecting changes to the OM of another (initiating) device, and notifying LMAC 250 of changes to the OM initiated by another device, as follows: Figure 3 and Figure 4For a more detailed description, UMAC 230 may also include a TXD module 236, which can generate a transport descriptor for the data packet based on the metadata 205 of the data packet 207. The transport descriptor is schematically depicted as a black rectangle included in frame 253. The term "frame" should be understood as any block of data prepared by the MAC layer for further processing by the physical layer (e.g., PHY 270) and transmitted over the wireless network via radio. A data frame (e.g., one of data frames 253) may include data packets (e.g., one of data packets 207), the IP address and MAC address of the host device 202 and / or ULOME 220, various headers, transport descriptors, and any other information (e.g., metadata) that may be used in the processing, transmission, and reception of the data packet. In some implementations, a frame may be a data frame, an action frame, a management frame, etc.

[0031] A transmission descriptor can be used to inform the PHY 270 how to transmit the corresponding frame 253. For example, the transmission descriptor can indicate the specific SS (or multiple SSs) to be used in the transmission of the corresponding frame (e.g., a data frame), the transmission bandwidth, priority level, transmission rate, the power of the amplifier to be used in the transmission, and other transmission parameters that may be required. Because the transmission descriptor depends on the specific OM used by the ULOME 220, the TXD module 236 can be updated with respect to changes in the OM (by the T-GOV 240) to change the transmission descriptor of subsequent frames 253. The UMAC 230 may also include a frame parser module 242 to detect changes in the OM used by other devices by analyzing (parsing) the RX frames 263 received from such devices.

[0032] LMAC 250 may include a Transmit / Reflect (TX / RX) Actuator (TRACT) 255 and a Receive Conditioner Function (R-GOV) 260. Operations performed by TRACT 255 may include: inserting an OM change indicator into TX frame 253 to transmit the OM change of ULOME 220 to other devices, and modifying the transmission descriptor of TX (output) frame 253 for a duration between detecting that another device has implemented (e.g., initiated or agreed to) an OM change and the time when T-GOV 240 begins generating a transmission descriptor for subsequent TX frames using the new OM format. Detection of an OM change implemented by another device may be performed by R-GOV 260 based on analysis of RX (input) frame 263 received from another device. TX frame 253 and RX frame 263 may be held (before transmission and after reception) in TX register 252 and receive register 262, respectively, or in some other memory device. TX register 252 and RX register 262 may be FIFO (First-In, First-Out) memory devices. LMAC 250 may also include a PHY programming module 254 to program PHY 270 using the transport descriptor of TX frame 253. LMAC 250 may also include a bit substitution engine (BSE) 256 to implement the insertion of OM change indicators according to instructions from TRACT 255, which may include modifying appropriate fields in the header of the corresponding TX frame 253.

[0033] The individual blocks of the UMAC 230 and LMAC 250 can be implemented in software and / or hardware. In some implementations, the UMAC 230 can be implemented in an embedded processor (e.g., The UMAC 230 is implemented on an R4 processor, where the T-GOV 240 and other modules are implemented in software or firmware executed by the embedded processor. The LMAC 250 can be implemented in a precision microcontroller that controls the timing of sending MAC protocol data units (which may include TX frames 253 and RX frames 263) to and from the PHY 270. The TRACT 255 and R-GOV 260 can be implemented in software or firmware executed by the precision microcontroller. In at least some implementations, the BSE 256 can be implemented in hardware. Similarly, some components of the UMAC 230 and LMAC 250 (including the T-GOV 240, R-GOV 260, and TRACT 255) can be implemented in dedicated hardware.

[0034] The PHY 270 can be the 802.11ax physical layer or the physical layer of any other wireless standard that implements transmissions supporting OM change indication within data frames. The PHY 270 can receive radio signals and convert the received signals into frames that can then be processed by the MAC layer. The PHY 270 can also convert frames received from the MAC layer into radio signals and transmit them using radio waves. The PHY 270 may include an intermediate frequency amplifier, an analog-to-digital converter, an inverse Fourier transform module, a parsing module, an interleaver, an error correction module, a scrambler, a PHY-MAC fill layer, and other components (not explicitly shown). In some implementations, all PHY 270 components may be integrated into the same chip. In some implementations, the PHY 270 may be integrated on the same chip as the UMAC 230 and LMAC 250. In other implementations, some components (e.g., the analog-to-digital converter and / or the intermediate frequency amplifier) ​​may be performed by separate circuitry outside the PHY 270. The PHY 270 may have a transmission processing unit (TX processing) 272 and a reception processing unit (RX processing) 276. In some implementations, some of the TX processing 272 and RX processing 276 units may be shared. The TX processing 272 and RX processing 276 may include various front-end modules that interface the PHY 270 with various antennas (e.g., one or more TX antennas 274 and one or more RX antennas 278). In some implementations, some of the antennas may operate as both TX and RX antennas.

[0035] In some implementations, the ULOME 220 may also include one or more central processing units (CPUs) and memory devices (not shown). The ULOME 220 may also include input / output controllers for communication with external devices and structures, power management units, and other components. In one implementation, the interaction of the ULOME 220 components may occur as follows: The CPU may perform logical link control (LLC) in communication with the memory device, receive data from the host device 202, prepare data units (e.g., MAC Service Data Units (MSDUs)), and provide the data units to the MAC layer. Before sending the protocol data units to the PHY 270 for analog-to-digital processing, intermediate frequency amplification, and filtering, the MAC layer may add additional bytes (e.g., header bytes and / or trailer bytes) to form appropriate MAC Protocol Data Units (MPDUs), such as frames. The analog signal output from the PHY 270 can then be provided to the radio front-end circuitry for radio frequency processing and transmission through one or more antennas 274. The reverse processing may occur when receiving input radio frequency signals through antenna 278.

[0036] UL can support various types of wireless networks, such as WLAN or WWAN (e.g., Network), PAN (e.g., (e.g., individual domain networks). In some implementations, a single ULOME 220 can support two or more APs, for example, APs operating in different frequency bands (e.g., 2.4 GHz and 5 GHz bands) and having dedicated UMAC 230, LMAC 250, and PHY 270 modules and components for each band. In some implementations, some of the UMAC 230, LMAC 250, and PHY 270 modules and components can be shared between different APs.

[0037] Figure 3 This is a block diagram illustrating an example operation 300 for a fast and efficient change of operating mode in a wireless network using an ultra-low latency network controller, according to some implementations of this disclosure. Figure 3 The diagram illustrates operations performed by a first (initiating) device and a second (responding) device 201. The first (initiating) device may be device 200, and the second (responding) device 201 may have a similar architecture to device 200. Both devices may include ULOME controllers, such as ULOME 220 of the first device 200 and ULOME 320 of the second device 201. Components and modules of two devices with the same (or similar) functionality may be listed using numbers with different first digits. For example, component 2XY of the first device (e.g., TRACT 255) may have the same (or similar) functionality as component 3XY of the second device (e.g., TRACT 355). Odd-numbered boxes (boxes 301 to 349) indicate various operations of OM change processing, with arrows indicating the direction of the instruction flow and / or data flow associated with the corresponding operation. The numbers in the boxes are for identification purposes only and should not be construed as indicating a specific order of operations. For example, operations identified by different numbers may be performed simultaneously. An operation identified by a larger number may be performed earlier than an operation identified by a smaller number, and vice versa. For the sake of brevity and clarity, and for the convenience of the reader, the above references... Figure 2 The components shown and described should be understood to exist in the first device 200 and the second device 201 even if not explicitly depicted.

[0038] An application executed by host device 202 of first device 200 can generate (box 301) a stream of MSDUs including data packets 207 from TX data 206. Each data packet may include metadata describing the type and priority of data packet 207. The metadata may be generated by host device 202 or by the OSI network layer (not shown) of first device 200. The MSDU containing data packets 207 can be received by TXD module 236 to generate a transport descriptor (TXD) for the data packets based on the metadata. The TXD module 236 can pre-add the TXD to each corresponding MSDU. Various other information can be added to form TX frames (or other MPDUs), such as TX frame 253. The TX frame 253 with the added transport descriptor can be placed in a transport queue maintained by TX FIFO register 252 to await processing by PHY programming 254 and transmission to PHY 270. Meanwhile, TRACT 255 can gain access to the TX frame (box 303). If ULOME 220 does not initiate a change to the current OM, T-GOV 240 may not take any action on the TX frames in the queue. However, if T-GOV 240, which is monitoring the internal and external conditions of ULOME 220, determines that an OM change is necessary, T-GOV 240 may transmit the start of OM change processing to TRACT 255 (box 305). Unlike the normal operation where TRACT 255 transmits TX frames unchanged to TX processing 272 (box 307), after the OM change processing begins, TRACT 255 may begin inserting OM change indicators into the headers of TX frames waiting in the transmission queue, for example, starting with the first TX frame that has not yet been relayed to PHY 270. For example, the OM change indicator may be inserted into the HTC field (or some other predetermined field) of the MAC header of HEW TX data frames (or management frames, action frames, or any other TX frames) in the transmission queue. TRACT 255 can output instructions (box 309) to the bit substitution engine 256 to insert an OM change indicator into the corresponding field of the MAC header (as schematically depicted by assembling frames in box 256 using a mesh header). BSE 256 can provide data packets with the inserted OM change indicator (box 311) to TX processing 272 for transmission to the second device. The OM change indicator may include a description of the new OM (e.g., number of SSs, bandwidth, etc.) to provide the ULOME 320 of the second device 201 with the information necessary to implement the OM change.

[0039] If the transmission queue in TX FIFO 252 does not currently contain TX frame 253, TRACT 255 may generate an empty data frame (without actual data payload), such as a Quality of Service (QoS) data frame (or any other appropriate frame) with an OM change indicator inserted in the MAC header (e.g., in the HTC field of the MAC header).

[0040] Radio signals carrying TX frames with OM change indicators can be output by the TX antenna 274 of the first device 200 and received by the RX antenna 378 of the second device 201 (box 313). The RX processing 376 of the second device 201 can provide the received data packets to the host device 302 as part of RX data 208 (box 315). As part of box 315, the PHY 370 can convert the received (RX) signal into RX frames 263 that can then be processed by the MAC layer of the ULOME 320 (e.g., ...). Figure 2 As shown in the diagram. While (or before) PHY 370 provides data packets to host device 302, R-GOV 360 can inspect the header of the RX frame packet (box 317). Once R-GOV 360 detects an OM change indicator in the MAC header of the RX frame, R-GOV 360 can notify TRACT 355 that the first device 200 has initiated an OM change (box 321).

[0041] In response to receiving an indication of an OM change, TRACT 355 may begin intercepting TX frames output by TXD 336. The TX frame may be constructed from an MSDU containing TX data packets prepared by host device 302 (box 323) and a transport descriptor provided by TXD 336 (box 325). More specifically, TRACT 355 may begin reprogramming the transport descriptor of the TX frame and provide the TX frame with the reprogrammed transport descriptor for PHY programming (box 327). Specifically, TRACT 355 may begin overwriting the bandwidth and / or SS quantity information in the transport descriptor using information received from first device 200 (e.g., new OM information obtained from the HTC field of the MAC header of an RX frame or from the OM notification element of a (traditional) action frame). Reprogramming may be performed by PHY programming 254 (not shown) of LMAC 350. Optionally, the OM indicator can be modified by the BSE 356 of the LMAC 350 and inserted into the header of the TX frame (box 329). Therefore, based on the reprogrammed transmission descriptor, the TX frame output by the TX processor 372 is transmitted via the TX antenna 374 of the second device 201 using the new OM mode. The transmitted packets can be received by the RX antenna 278 of the first device 200 (box 331).

[0042] The RX processing 276 of the first device 200 can provide data packets (encoded in the received signal) received from the second device 201 to the host device 202 as part of RX data 208 (box 333). As part of box 333, the PHY 270 can convert the received signal into an RX frame that can then be processed by the MAC layer of the ULOME 220. Simultaneously (or before) the PHY 270 provides the RX data packets to the host device 202, the R-GOV 260 can inspect the RX frame (e.g., the HTC field in the header of the RX frame) (box 335). Once the R-GOV 260 detects an RX frame including an acknowledgment (ACK) frame received by the first device 200 from the second device 201, the R-GOV 260 begins a reciprocal transmission by initiating a data transfer from the first device 200 to the second device 201 under a new OM. Specifically, the R-GOV 260 can notify TRACT 255 (box 339) that the second device 201 has accepted the OM change.

[0043] In response to receiving acceptance of the OM change, TRACT 255 can begin intercepting output TX data frames awaiting transmission in TX FIFO 252 and reprogramming the transmission descriptor of the TX frame. This reprogramming can be performed by the PHY programming module 254 of LMAC 250. Data packets with the reprogrammed transmission descriptors can be provided to TX processing 272 for transmission to the second device 201 via TX antenna 274. Therefore, the first device 200 responds very quickly to the accepted OM change (by the second device 201) because the first frame currently in TX FIFO 252 can be transmitted to the second device 201 using the new OM.

[0044] In addition to the inspection of RX data frames by R-GOV 260 performed within LMAC 250 (box 335), RX data frames can also be sent to UMAC 230 for further processing. For example, frame parser 242 of UMAC 230 can also inspect RX frames (box 337). RX frames may include ACK frames sent by second device 201 to confirm that second device 201 has transitioned to the new OM. Using frame parser 242 to detect the presence of an ACK frame confirming the OM change (box 341), T-GOV 240 can begin providing new transport descriptors under the new OM to new frames added to the transport queue (box 343). T-GOV 240 can also, for example, notify TRACT 255 when to stop reprogramming descriptors from the old OM to the new OM based on the identifier of the first TX data packet provided with the new OM transport descriptor. Alternatively, in order to determine when to stop reprogramming, TRACT 255 may continue to check the transport descriptors of frames in the queue until the first frame with a transport descriptor programmed with the new OM is detected.

[0045] In parallel, a similar operation can be performed by the UMAC 330 of the second device 201. Specifically, in addition to the inspection of RX data frames received from the first device 200 by the R-GOV 360 performed within the LMAC 350 (box 317), the frame parser 342 of the UMAC 330 can also inspect the RX data frames received from the first device 200 (box 319). Detecting the presence of an ACK frame with an OM acknowledgment using the frame parser 342 (box 345), the T-GOV 240 can begin providing new transport descriptors under a new OM to new packets added to the transport queue of TX frames (box 347). The T-GOV 340 can also, for example, notify the TRACT 355 (box 349) when to stop reprogramming descriptors from the old OM to the new OM based on the identifier of the first TX data packet provided with the new OM transport descriptor. Alternatively, to determine when to stop reprogramming, TRACT 355 may continue to check the transport descriptors of frames in the queue until the first frame with a transport descriptor programmed with the new OM is detected. In some implementations, the functionality of frame parser 342 may be combined with the functionality of R-GOV 360, wherein the combined R-GOV 360 notifies both T-GOV 340 (box 345) and TRACT 355 (box 321) that the first device 200 has initiated an OM change.

[0046] Figure 4 This is a block diagram illustrating an example operation 400 for a fast and efficient change of operating mode in a wireless network including conventional devices, according to some implementations of the present disclosure. Figure 4The diagram illustrates the operations performed by the conventional (initiating) device 401 and the second (responding) device 201. The conventional device 401 may not have a ULOME controller, while the second device is similar to... Figure 3 The second device 201 may include a ULOME 320. Various operations of the OM change process are indicated using small, odd-numbered boxes (boxes 403 to 431), where arrows indicate the direction of the instruction and / or data flow associated with the corresponding operation. The numbers in the boxes are for identification purposes only and should not be construed as indicating a specific order of operations. For example, operations identified by different numbers may be performed simultaneously. An operation identified by a larger number may be performed earlier than an operation identified by a smaller number, and vice versa. For simplicity and clarity, and for the convenience of the reader, the above references... Figure 2 Even if not explicitly depicted, components shown and / or described should be understood to still be present in the second device 201. Similarly, conventional device 401 may include components not shown in the second device 201. Figure 4 Additional components explicitly shown in the document, such as CPU, memory devices, power management unit, input / output controller, etc.

[0047] An application executed by host device 402 of legacy device 401 can generate a stream of TX data packets (block 403) based on TX data 406. Each data packet may include metadata describing the type and priority of the data packet. The metadata may be generated by host device 402, the OSI network layer (not shown), or the CPU (not shown) of legacy chip 420. The MSDU containing the packets may be received by TXD module 436 to generate a transport descriptor for the TX data packets based on the metadata. TXD may be pre-added to each corresponding MSDU by TXD module 436. Various other information may be added to form TX frames (or other MPDUs). TX frames with added transport descriptors may be placed in a transport queue maintained by the TX FIFO register to await processing by PHY programming and transmission to PHY 470. Legacy control module 440 can monitor the internal and external conditions of legacy chip 420. Control module 440 can determine the OM of legacy chip 420 to be changed. Control module 440 can initiate OM change processing by providing OM change notification to TXD module 436 or alternatively to some other software executed by the CPU of conventional chip 420 (block 405). MAC 430 can generate an action frame (block 407) to transmit a request for OM change to second device 201. The action frame can be placed after the current queue of TX frames and can include a description of the new OM (e.g., number of SS, bandwidth, etc.) to provide second device 201 with the information necessary to implement the OM change.

[0048] Action frames can be processed by the TX processing 472 of legacy device 401 and transmitted to the second device 201 via the TX antenna 474 (box 409). Action frames can be received by the RX antenna 378 of the second device 201 (box 409). The RX processing 376 of the second device 201 can provide the received data packets to the host device 302 as part of RX data 208 (box 411). As part of box 411, the PHY 270 can convert the received signal into a frame that can then be processed by the MAC layer of ULOME 320. While (or before) the PHY 370 provides the received data packets to the host device 302, the R-GOV 360 can inspect the header of the RX frame (box 413). Once the R-GOV 360 detects the presence of an action frame in the RX frame, the R-GOV 360 can notify TRACT 355 (box 417) that legacy device 401 has initiated an OM change.

[0049] In response to a notification of an OM change, TRACT 355 may begin intercepting TX data frames with transport descriptors output by TXD 336 (box 421). The TX frame may be constructed from an MSDU containing TX data packets prepared by host device 302 (box 419) and a transport descriptor provided by TXD 336 (box 421). More specifically, TRACT 355 may begin reprogramming the transport descriptor of the TX frame and provide the TX frame with the reprogrammed transport descriptor for PHY programming (box 423). Specifically, TRACT 355 may begin overwriting the bandwidth and / or SS quantity information in the transport descriptor using information received from first device 401 (e.g., new OM information obtained from the HTC field of the MAC header of an RX frame or from the OM notification element of a (traditional) action frame). Reprogramming may be performed by the PHY programming module 254 (not shown) of LMAC 350. Therefore, based on the reprogrammed transmission descriptor, the TX data frames processed and output by the TX processing 372 can be transmitted via the TX antenna 374 of the second device 201 and received by the RX antenna 478 (box 425) using the new OM mode, and processed by the RX processing 476 of the conventional device 401.

[0050] In addition to the inspection of RX data frames received from legacy device 401 by R-GOV 360 performed within LMAC 350 (box 413), RX data frames can also be sent to UMAC 230 for further processing. For example, frame parser 342 of UMAC 330 can also inspect RX frames received from legacy device 401 (box 415). Detecting the presence of an ACK frame with an OM change acknowledgment using frame parser 342 (box 427), T-GOV 340 can instruct TXD 336 to begin providing new transport descriptors under a new OM to new frames added to the queue of the transport queue (box 429). T-GOV 340 can also, for example, notify TRACT 355 (box 431) when to stop reprogramming descriptors from the old OM to the new OM based on the identifier of the first TX data frame equipped with the new OM transport descriptor. Alternatively, to determine when to stop reprogramming, TRACT 355 can continue to check the transport descriptors of frames in the queue until the first frame with a transport descriptor programmed with the new OM is detected.

[0051] Figure 5 This is a flowchart of an example method 500 for a fast and efficient change of operating mode in a wireless network, executed by a response device according to some implementations of this disclosure. Method 500 can be... Figure 2 ULOME 220 or Figure 3 and Figure 4 The processing logic of ULOME 320 is executed. The processing logic executing method 500 may include hardware (e.g., circuitry, dedicated logic, programmable logic, microcode, etc.), software (which may perform operations of T-GOV 240 and T-GOV 340, R-GOV 260 and R-GOV360, TRACT 255 and TRACT 355), firmware, or a combination thereof. In some implementations, method 500 may be executed by a single processing thread. Alternatively, method 500 may be executed by two or more processing threads, each thread executing one or more individual functions, routines, subroutines, or operations of the method. In the illustrative example, the processing threads implementing method 500 may be synchronized (e.g., using semaphores, critical sections, and / or other thread synchronization mechanisms). Alternatively, the processing threads implementing method 500 may execute asynchronously relative to each other. Figure 5 Compared to the order shown, various operations of method 500 can be performed in different orders. Some operations of the method can be performed concurrently with other operations. Some operations can be optional.

[0052] Method 500 can be executed to implement an operating mode change for the wireless connection between a first (initiating) communication device (CD) and a second (responding) CD. In one implementation, method 500 can be executed by processing logic of the second CD. At operation 510, the processing logic executing method 500 can detect an indication that the first CD has requested an operating mode change from a first operating mode to a second operating mode. For example, the R-GOV of the second CD can detect the operating mode indication in the MAC header of a frame received from the first CD. If the first CD is an IEEE 802.11ax device, the operating mode indication can be located in the high throughput control field of the MAC header of a frame (e.g., a QoS data frame received from the first CD). Alternatively, if the first CD is an IEEE 802.11ac device, the operating mode indication can be an Operating Mode Notification (OMN) element in an action frame received from the first CD. The operating mode change transmitted using the operating mode indication can include a change in the number of spatial streams or the bandwidth of the wireless connection.

[0053] At operation 520, method 500 may continue to use processing logic to modify the transmission information (TI) associated with one or more frames in the transmission queue of the second CD. One or more frames in the transmission queue may have previously been programmed using first-mode transmission information. The TI may include a representation that can be used by the physical layer of the second CD to configure the transmission of the corresponding frame to the first CD. In one implementation, the TI may be a transmission descriptor (TXD) within one or more frames. In another implementation, the TI may be a separate source, such as a cache (register or any other memory device), a table (e.g., a mapping table, lookup table, etc.) that maps one or more frames to representations used by the physical layer to configure the transmission of the corresponding frames. The cache and / or table may be periodically updated to identify which frames in the queue will be transmitted using which specific operating modes. In some implementations, the transmission information may not be code or direct instructions to the physical layer, but may be an intermediate representation that can be used by LMAC 250 and / or PHY programming 254 to generate code or instructions to the physical layer to configure the transmission of the corresponding frame. The first mode transmission information may include a representation for programming the transmission in a first operating mode (e.g., having a first number of spatial streams and a first bandwidth). Modification of the transmission information may include changing or reprogramming the transmission information to a second mode transmission information (e.g., having a second number of spatial streams and a second bandwidth).

[0054] Operations 530 to 560, as indicated by the dashed boxes, can be optional. At operation 530, in response to an indication that the second CD has requested a change of operating mode, method 500 can continue to program additional data frames with second-mode transmission information using processing logic. These additional data frames can include any data frames, action frames, management frames, etc., prepared by the MAC layer after the request for a change of operating mode has been detected. At operation 540, the multiple programmed additional data frames can be placed into a transmission queue. Therefore, the transmission queue can include frames associated with first-mode transmission information (older frames) and frames associated with second-mode transmission information (newer frames). The older frames associated with the transmission information can be modified to the second operating mode, for example, via TRACT 255, before being relayed to the PHY layer.

[0055] At operation 550, the processing logic can identify the last frame in the transmission queue that has been previously programmed with the first mode transmission information, and at operation 560, after the transmission information of the identified last frame has been modified to the second mode transmission information, it stops modifying the transmission information of other (updated) frames in the transmission queue.

[0056] Figure 6 This is a flowchart of an example method 600 for changing a fast and efficient operating mode in a wireless network, executed by an initiating device, according to some implementations of this disclosure. Method 600 can be... Figure 2 and Figure 3 The processing logic of ULOME 220 is executed. The processing logic executing method 600 may include hardware (e.g., circuitry, dedicated logic, programmable logic, microcode, etc.), software (which may perform operations of T-GOV 240, R-GOV 260, TRACT 255), firmware, or a combination thereof. In some implementations, method 600 may be executed by a single processing thread. Alternatively, method 600 may be executed by two or more processing threads, each thread executing one or more individual functions, routines, subroutines, or operations of the method. In the illustrative example, the processing threads implementing method 600 may be synchronized (e.g., using semaphores, critical sections, and / or other thread synchronization mechanisms). Alternatively, the processing threads implementing method 600 may execute asynchronously relative to each other. Figure 6 Compared to the order shown, various operations of method 600 can be performed in different orders. Some operations of this method can be performed concurrently with other operations. Some operations can be optional.

[0057] Method 600 can be executed to change the operating mode of the wireless connection between the initiating communication device (CD) and the responding CD. In one implementation, method 600 can be executed by the processing logic of the first CD. In some implementations, method 600 can be executed after method 500, wherein the second (responding) CD of method 500 is the initiating CD of method 600 and the first (initiating) CD of method 500 is the responding CD of method 600. For example, the first CD (e.g., AP 102) communicating with the second CD (e.g., STA 110) can initiate an OM upgrade from the first OM to the second OM. Subsequently, at a later time, after being subjected to harmful interference, STA 110 can initiate an OM downgrade from the second OM to the third OM.

[0058] At operation 610, the processing device executing method 600 can determine that the current operating mode will be changed to a new operating mode. For example, T-GOV 240 can determine that the temperature of the ULOME chip has increased (or decreased) or the amount of reliable space flow has changed due to interference from other flows or devices, resulting in a decrease (or increase).

[0059] At operation 620, method 600 may continue to utilize TRACT 255 of LMAC 250 to insert an indication pointing to the new operating mode into the operating mode indication field of the MAC header of one or more frames in the current transmission queue that initiated the CD. At operation 630, the physical layer (e.g., PHY 270) may configure the transmission of at least one frame in the transmission queue with the indication pointing to the new operating mode to the response CD. At operation 640, the processing means performing method 600 may detect that the response CD has transitioned to the new operating mode. For example, R-GOV 260 of LMAC 250 may determine that the response CD has begun transmitting frames using the new operating mode.

[0060] At operation 650, method 600 may continue to reprogram the transmission information of frames currently in the transmission queue of the initiating device (e.g., frames previously programmed using transmission information of an old operating mode) to a new operating mode. At operation 660, the processing device may also program the transmission information of multiple additional frames to a new operating mode, and at operation 670, the multiple additional frames may be placed into the transmission queue of the initiating CD.

[0061] Figure 7The advantages of the disclosed implementation, which is illustrated by comparing the latency in a conventional wireless device (top figure) with the latency in a wireless device with ULOME functionality (bottom figure), are shown. Referring to the top figure, the initiating conventional device may have to send the entire current contents of the TX FIFO register before it can send an action frame (AF) with an OM Notification Element (OMN) to the responding device. The TX FIFO contents may include two (in an illustrative example) aggregated MPDUs (AMPDUs), each with 64 MPDUs. The timing of the processing is shown, where the top row indicates the data sent by the initiating device and the bottom row indicates the data sent by the responding device. For example, before sending the action frame with the OMN (grey box), in addition to some minimum inter-frame interval (SIFS), distributed coordination function inter-frame interval (DIFS), and random backoff, the initiating device may also send a request to transmit (RTS) signal for each AMPDU (e.g., AMPDU-1 and AMPDU-2) and receive a clear transmit (CTS) signal and a block acknowledgment (BA) signal from the responding device. In one example, with two spatial streams, an 80MHz bandwidth, and VHT modulation and coding index 7, the time before transmitting OMN / AF could exceed 3500µs (plus the duration of two backoff intervals). In contrast, the following line illustrates the provision of OM notification in a wireless device with a ULOME controller. The following line includes a single set of RTS and CTS (with SIFS in between) before the field (e.g., the HTC field) is transmitted along with the first frame of the first AMPDU (which can be a data frame or any other frame). Therefore, the delay can be less than 80µs.

[0062] It should be understood that the above description is intended to be illustrative and not restrictive. Many other implementation examples will become apparent to those skilled in the art after reading and understanding the above description. While specific examples are described in this disclosure, it should be recognized that the systems and methods of this disclosure are not limited to the examples described herein but can be implemented with modifications within the scope of the appended claims. Therefore, the specification and drawings are to be considered illustrative rather than restrictive. Consequently, the scope of this disclosure should be determined by reference to the appended claims and the full scope of their equivalents.

[0063] The methods, hardware, software, firmware, or code described above can be implemented via instructions or code executable by a processing element and stored on a machine-accessible, machine-readable, computer-accessible, or computer-readable medium. "Memory" includes any mechanism that provides (i.e., stores and / or transmits) information in a form readable by a machine (e.g., a computer or electronic system). For example, "memory" includes: random access memory (RAM), such as static RAM (SRAM) or dynamic RAM (DRAM); ROM; magnetic or optical storage media; flash memory devices; electrical storage devices; optical storage devices; acoustic storage devices; and any type of tangible machine-readable medium suitable for storing or transmitting electronic instructions or information in a form readable by a machine (e.g., a computer).

[0064] Throughout this specification, references to "an implementation" or "implementation" mean that a particular feature, structure, or characteristic described with respect to that implementation is included in at least one implementation of this disclosure. Therefore, the appearance of the phrase "in an implementation" or "in an implementation" throughout this specification does not necessarily refer to the same implementation. Furthermore, a particular feature, structure, or characteristic may be combined in any suitable manner in one or more implementations.

[0065] The foregoing specification has been described in detail with reference to specific exemplary implementations. However, it will be apparent that various modifications and changes may be made therein without departing from the broader spirit and scope of this disclosure as set forth in the appended claims. Therefore, the specification and drawings should be considered illustrative rather than restrictive. Furthermore, the foregoing use of the terms "implementation," "implementation," and / or other exemplary language does not necessarily refer to the same implementation or the same example, but may refer to different and distinct implementations as well as potentially similar implementations.

[0066] The terms “example” or “exemplary” are used herein to indicate that they are used as examples, instances, or illustrations. Any aspect or design described herein as “example” or “exemplary” is not necessarily to be construed as preferred or advantageous over other aspects or designs. Rather, the use of the terms “example” or “exemplary” is intended to present concepts in a specific manner. As used herein, the term “or” is intended to mean an inclusive “or” rather than an exclusive “or.” That is, unless otherwise stated or clear from the context, “X comprises A or B” is intended to mean any naturally inclusive permutation. That is, if X comprises A; X comprises B; or X comprises both A and B, then “X comprises A or B” is satisfied in any of the foregoing cases. Additionally, unless otherwise stated or clearly specified from the context as a singular form, the articles “a” and “an” as used herein and in the appended claims should generally be construed as meaning “one or more.” Furthermore, the use of the terms “implementation” or “an implementation” or “implementation” or “an implementation” throughout the document is not intended to mean the same implementation or implementation unless so described. Furthermore, the terms “first,” “second,” “third,” “fourth,” etc., used in this article are intended as markers to distinguish different elements, and their numerical designations may not necessarily have an ordering meaning.

Claims

1. A method for changing the operating mode of a wireless connection between a first communication device (CD) and a second CD, the method comprising: The wireless network controller of the second CD detects an indication that the first CD has requested a change of operating mode from the first operating mode to the second operating mode; In response to a detected indication, the radio network controller identifies one or more frames in the transmission queue of the second CD, wherein, prior to detecting the indication, the one or more frames were associated with first mode transmission information (TI), and wherein the first mode TI is configured to cause the physical layer of the second CD to use the first operating mode to transmit the one or more frames in the transmission queue; and The radio network controller modifies the first mode TI to a second mode TI, wherein the second mode TI is configured to cause the physical layer of the second CD to use the second operating mode to transmit the one or more frames in the transmission queue.

2. The method according to claim 1, wherein, Detecting an indication that the first CD has requested a change in operating mode includes detecting an operating mode indication in the MAC header of a frame received from the first CD.

3. The method according to claim 2, wherein, The frames received from the first CD are Quality of Service (QoS) data frames.

4. The method according to claim 1, wherein, Detecting an indication that the first CD has requested a change in operating mode includes detecting an operating mode notification element in an action frame received from the first CD.

5. The method according to claim 1, further comprising: In response to an indication that the first CD has requested a change in the operating mode, multiple data frames are associated with the second mode TI; as well as The plurality of data frames are placed into the transmission queue.

6. The method according to claim 5, further comprising: Identify the last frame in the one or more frames in the transmission queue; as well as After the TI associated with the last identified frame has been modified to the second mode TI, modification of the TI associated with other frames in the transmission queue is stopped.

7. The method according to claim 1, wherein, The change in the operating mode of the wireless connection includes at least one of the change in the number of spatial streams of the wireless connection or the change in the bandwidth of the wireless connection.

8. The method according to claim 1, wherein, The TI associated with the one or more frames includes the transport descriptor within the one or more frames.

9. A device for changing the operating mode of communication, the device comprising: Memory; as well as A processing device coupled to the memory, the processing device being configured to: The detection communication device CD has requested an instruction to change the operating mode from the first operating mode to the second operating mode of the wireless connection; In response to a detected indication, one or more frames in the transmission queue are identified, wherein, prior to the detection of the indication, the one or more frames have been associated with first mode transmission information (TI), and wherein the first mode TI is configured to cause a physical layer communicatively coupled to the processing device to use the first operating mode to transmit the one or more frames in the transmission queue; and The first mode TI is modified to a second mode TI, wherein the second mode TI is configured to enable the physical layer to use the second operating mode to transmit the one or more frames in the transmission queue.

10. The device according to claim 9, wherein, In order to detect that the CD has requested an indication of a change in operating mode, the processing device will: Detect the operation mode indication in the MAC header of the frame received from the CD; or Detect the operation mode notification element in the action frame received from the CD.

11. The device according to claim 9, wherein, The processing device will also: In response to an indication that the CD has requested a change in the operating mode, multiple data frames are associated with the second mode TI; as well as The plurality of data frames are placed into the transmission queue.

12. The device according to claim 9, wherein, The processing device will also: Identify the last frame in the one or more frames in the transmission queue; as well as After the TI associated with the last identified frame has been modified to the second mode TI, modification of the TI associated with other frames in the transmission queue is stopped.

13. A system for changing the operating mode of communication, the system comprising: One or more antennas; The physical layer of the second communication device CD, the physical layer being configured to configure the transmission of the frames in the transmission queue of the second CD to the first CD via the one or more antennas based on transmission information TI associated with corresponding frames in the frames in the transmission queue of the second CD; and The second CD has a Media Access Control (MAC) layer, which is communicatively coupled to the physical layer. The MAC layer is used for: The TI associated with one or more frames in the transmission queue is programmed as a first operating mode of the first CD; The system detects an indication that the first CD has requested a change in the operating mode of the wireless connection between the first CD and the second CD from the first operating mode to the second operating mode, wherein the indication is detected after programming the TI. In response to the detected indication, identify the one or more frames in the transmission queue; and The TI associated with the one or more frames in the transmission queue is reprogrammed to the second operating mode.

14. The system according to claim 13, wherein, In order to detect an indication that the first CD has requested a change in operating mode, the MAC layer will detect the operating mode indication in the MAC header of the frame received from the first CD.

15. The system according to claim 14, wherein, The frames received from the first CD are Quality of Service (QoS) data frames.

16. The system according to claim 13, wherein, In order to detect an indication that the first CD has requested a change in operating mode, the MAC layer will detect the operating mode notification element in the action frame received from the first CD.

17. The system according to claim 13, wherein, The MAC layer will also: In response to an indication that the first CD has requested a change in operating mode, the TI for the second operating mode of the first CD is associated with a plurality of additional frames; as well as The plurality of additional frames are placed into the transmission queue.

18. The system according to claim 17, wherein, The MAC layer will also: Identify the last frame in one or more frames in the transmission queue that have a TI associated with the first operating mode; as well as After the TI of the last identified frame has been reprogrammed to the second operating mode, the reprogramming of the TI of the frames in the transmission queue is stopped.

19. The system according to claim 13, wherein, The change in the operating mode of the wireless connection includes at least one of the change in the number of spatial streams of the wireless connection or the change in the bandwidth of the wireless connection.

20. The system according to claim 13, wherein, The MAC layer will also: It has been determined that the second operating mode will be changed to the third operating mode; Insert an indication pointing to the third operating mode into the operating mode indication field of the MAC header of one or more frames in the current transmission queue of the second CD; as well as The physical layer will also: The transmission of at least one frame from the transmission queue that has an indication pointing to the third operating mode to the first CD is configured.

21. The system according to claim 20, wherein, The MAC layer will also: In response to detecting that the first CD has switched to the third operating mode, the TI associated with the multiple frames currently in the transmission queue is reprogrammed to the third operating mode; Associate the TI of multiple additional frames with the third operating mode; as well as The plurality of additional frames are placed into the transmission queue.

22. The system according to claim 13, wherein, The TI associated with the one or more frames includes the transport descriptor within the one or more frames.

23. The system of claim 13, further comprising a host system communicatively coupled to the MAC layer, wherein, The one or more frames include data packets obtained from the host system.

Images