Patent Description:
The IEEE <NUM> wireless local area networking (WLAN) standard defines one of the most widely deployed wireless technologies in the world. The popularity of wireless networking is driven by the ubiquity of portable mobile hand-held devices, and the convenience of untethered communications. With the increasing deployment of multimedia content on the Internet-such as digital video, voice over IP (VoIP), videoconferencing, and real-time applications such as multi-player networked games-along with the deployment of time-sensitive critical applications, there is a strong motivation to develop QoS features to meet the more stringent performance requirements.

Regarding QoS provisions, the legacy standards IEEE <NUM>. 11a/b/g only have the basic distributed coordination function (DCF) and the optional point coordination function (PCF) enhancements, such as collision avoidance and a first in first out (FIFO) scheduler. In the DCF-based schemes, the access to the medium is given using a carrier sense multiple access (CSMA) scheme. Though statistically fair, not all sessions are created equal regarding expected network performance. During heavy network loads, DCF+CSMA can potentially result in sessions being deprived of their required bandwidth share. There is no proper mechanism to distinguish between the sessions on priority basis in the DCF-based environments. The legacy standards of IEEE <NUM> a/b/g/ have no standard mechanisms to ensure QoS. Because these standards do not incorporate admission control, performance degradation occurs during heavy traffic load.

The IEEE <NUM>. 11e amendment introduces a Hybrid Coordination Function (HCF), a new coordination function proposed to enhance DCF. HCF introduces the concept of transmission opportunity (TXOP) and uses two methods to acquire the TXOP: the first method is contention-based and it is known as enhanced distributed channel access (EDCA), and the second method is contention-free and it is known as HCF-controlled channel access (HCCA). Both these schemes are useful for QoS provisioning to support delay-sensitive voice and video applications.

EDCA uses timing information based on contention window sizes to differentiate between high priority and low priority access categories. The central coordinator assigns a contention window of shorter length to the high priority access categories to help them to obtain access to the medium and transmission opportunity (TXOP) before the lower priority ones. To differentiate further, interframe spacing (IFS) can be varied according to different access categories. Instead of using a distributed interframe spacing (DIFS) as for the DCF traffic, a new interframe spacing called arbitration interframe spacing (AIFS) is used. AIFS is a number of time slots an EDCA function (EDCAF) waits before contending for the medium. Therefore, a traffic category having smaller AIFS gets higher priority.

Table <NUM> presents the minimum and maximum contention window durations for the four Access Categories in EDCA using default OFDMA parameters of aCWmin=<NUM>, aCWmax=<NUM>, and slot duration of <NUM>.

The lowest-latency access category, AC_VO (Voice), has a contention window that ranges from <NUM> to <NUM> microseconds under these conditions. Even with this relatively short backoff time, under worst-case conditions, i.e. a high density of voice traffic mapped to AC_VO concurrently with real time application traffic, latency of real time application traffic mapped to AC_VO can cause an unsatisfactory user experience. It is desired to provide a shorter maximum latency for real-time application traffic in wireless LANs.

Another example is provided in document <CIT>, disclosing an AP supporting plural traffic types. For efficient support of real-time traffic, encoding of real time packets in any queue a a configuration option, typically the video traffic queue is proposed. Also a load distribution algorithm is moving stations to other APs if the traffic channel is congested. By mapping the real time traffic to video traffic, real time category is prioritised.

Example embodiments of the present disclosure provide a method, apparatus and computer-readable storage medium for priority transmission of WLAN frames, and the invention is defined in the appended claims.

For a more complete understanding of the present embodiments, and the advantages thereof, reference is now made, by way of example, to the following descriptions taken in conjunction with the accompanying drawings, in which:.

For illustrative purposes, specific example embodiments will now be explained in greater detail below in conjunction with the figures.

The embodiments set forth herein represent information sufficient to practice the claimed subject matter and illustrate ways of practicing such subject matter. Upon reading the following description in light of the accompanying figures, those of skill in the art will understand the concepts of the claimed subject matter and will recognize applications of these concepts not particularly addressed herein.

Moreover, it will be appreciated that any module, component, or device disclosed herein that executes instructions may include or otherwise have access to a non-transitory computer/processor readable storage medium or media for storage of information, such as computer/processor readable instructions, data structures, program modules, and/or other data. A non-exhaustive list of examples of non-transitory computer/processor readable storage media includes magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, optical disks such as compact disc read-only memory (CD-ROM), digital video discs or digital versatile discs (i.e. DVDs), Blu-ray Disc™, or other optical storage, volatile and non-volatile, removable and non-removable media implemented in any method or technology, random-access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology. Any such non-transitory computer/processor storage media may be part of a device or accessible or connectable thereto. Computer/processor readable/executable instructions to implement an application or module described herein may be stored or otherwise held by such non-transitory computer/processor readable storage media.

The present disclosure relates to communication in a wireless LAN (WLAN) between components of a basic service set (BSS). With reference to <FIG>, a BSS <NUM> comprises one or more access points(AP) <NUM> which provide connectivity over a wireless medium <NUM> between client STAs <NUM> and a wide area network (WAN) such as the Internet, a core network, a Radio Access Network, or other networks. Access points may include wireless routers, mobile phone personal hotspots, Wi-Fi equipped PCs, Wi-Fi equipped cable modems, or any other electronic devices capable of hosting an IEEE <NUM> connection. Wireless medium <NUM> may comprise frequency channels in various spectral bands including those on and around <NUM>, <NUM>, <NUM>, <NUM>, and any other portions of unlicensed spectrum for scientific and industrial use. Where a frequency is cited, the actual band comprises a range of frequencies around the cited frequency. The AP <NUM> communicates with one or more of the STAs <NUM> over one or more air interfaces using wireless media <NUM> e.g. radio frequency (RF), microwave, infrared (IR), etc. The air interfaces may utilize any suitable radio access technology. For example, the BSS <NUM> may implement one or more orthogonal or non-orthogonal channel access methods, such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), or single-carrier FDMA (SC-FDMA) in the air interfaces.

STAs <NUM> may comprise cellular phones, tablets, computers, consumer entertainment devices, appliances, Internet of Things (IoT) clients, smart watches, or any other devices capable of connecting to a Wi-Fi Basic Service Set. Communication may occur in the uplink (STA to AP) direction or the downlink (AP to STA) direction. In certain circumstances direct STA to STA communication (sidelink communication) can occur. Although certain numbers of these components or elements are shown in <FIG>, any reasonable number of these components or elements may be included in the system <NUM>.

With reference to <FIG>, a wireless communication device <NUM> functioning as a STA in a BSS may take the form of a smartphone, portable computer, consumer electronic appliance, or other piece of Wi-Fi enabled technology and comprises one or more processors <NUM> coupled to a computer readable storage medium <NUM> and a network interface <NUM>. The storage medium stores the operating software for the wireless communication device <NUM> including instructions <NUM> for handling real time application traffic according to the present disclosure. Processor <NUM> may comprise an integrated circuit, such as a central processing unit (CPU), application processor (AP), field programmable gate array (FPGA) or application-specific integrated circuit (ASIC). Network interface <NUM> may comprise a baseband processor or other circuits for implementing a Medium Access Controller, a Physical layer, transmitting amplifiers, and one or more RF antennas as required for communicating over a wireless medium. The network interface <NUM> may utilize any suitable radio access technology. For example, the communication system <NUM> may implement one or more orthogonal or non-orthogonal channel access methods, such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), or single-carrier FDMA (SC-FDMA) in the network interface <NUM>. Storage medium <NUM> may comprise nonvolatile storages for unpowered storage of software such as EEPROM, NOR flash, and NAND flash, as well as volatile storages for application processor workspace such as DRAM and SRAM.

STA devices <NUM> such as personal computers, tablets, smartphones, thin client notebooks, and interactive smart TVs are capable of running high performance real-time applications such as live action games, musical collaborations, augmented reality, vehicle navigation, and other programs requiring low-latency interaction with other electronic devices for a satisfactory, and in some cases safe, user experience. In a case where many STAs <NUM> share one AP <NUM>, bandwidth is shared and devices are required to contend with one another for access to the wireless medium <NUM>. Quality of Service (QoS) protocols currently exist in IEEE <NUM> to give certain traffic classes such as voice and video a competitive advantage over other less time sensitive classes of traffic such as file transfer, email, software updates, and other interruption-tolerant communication sessions.

The contention-based Enhanced Distributed Channel Access is described with reference to <FIG> and <FIG> illustrates a block diagram <NUM> of EDCA procedures. The Application (APP) layer <NUM> of a protocol stack generates packets for sending over an electronic device's internet connection <NUM>, which is established by way of an <NUM> compliant access point (AP) <NUM>. The packets must first be sent to the MAC layer <NUM> and packaged as MAC Protocol Data Units (MPDU), also called MAC frames. A User Priority field (UP) which can be valued from <NUM> to <NUM>, is stored in the frame header and is used by the Hybrid Coordination Function <NUM> to map MAC frames based on their UP into one of four Access Categories (AC), each with its own contention parameters that determine which AC wins access to the wireless medium each time it is up for contention.

Table <NUM>, reproduced from Table <NUM>-<NUM> of IEEE P802. <NUM>-REVmd/D3. <NUM>, October <NUM> indicates how UP is mapped to AC in EDCA.

Referring to <FIG>, the most favored priority traffic, requiring latency of approximately <NUM>, is mapped to AC VO <NUM>. Traffic for which latency of about <NUM> is allowable gets mapped to AC VI <NUM>. The bulk of network traffic is mapped to AC BE <NUM>, and low priority traffic frames which are assigned to wait for leftover network bandwidth are mapped to AC BK <NUM>. Each of queues <NUM><NUM><NUM> and <NUM> contends for the wireless medium via its own respective EDCA Function (EDCAF) <NUM>, <NUM>, <NUM>, and <NUM> respectively. These EDCAFs take as inputs the parameters listed in Table <NUM> and calculate a contention window (CW) for each EDCAF, which determines the time it must wait before requesting a TXOP. The TXOP has a duration, during which a STA may send to the physical layer as many MAC frames as possible from the AC queue to which the TXOP belongs before the duration elapses. MAC frames are sent to the PHY <NUM> for adding PHY preambles, encoding and modulation into PHY Protocol Data Units (PPDUs, or WLAN traffic frames), and eventual transmission. The higher priority ACs have small contention window sizes and tend to receive the TXOP preferentially. Lower priority ACs tend to get a TXOP when there are no frames in the higher priority queues or when their randomly assigned backoff times(part of the CW calculation) happen to be shorter than the randomly assigned backoff time given to a higher priority AC. Without the random backoff timers, lower priority traffic would be almost entirely deferred as long as any higher priority traffic existed in queue.

Despite the current provision of QoS in <NUM>, simulations and real-world observations show that even when traffic frames are mapped to AC_VO, latency times for the most performance intensive real time applications such as high frame-rate gaming and vehicular control are a limiting factor in the utility of such applications and manifest themselves as noticeable lag between control inputs and output responses coming over the network. This is owing to a number of factors. Firstly, when one of a STA's EDCAFs wins contention for the TXOP, only frames from that EDCAF's queue are allowed to transmit during the TXOP. Secondly, each AC's queue is a FIFO queue, so RTA traffic frames mapped to AC_VO must wait for other AC_VO traffic ahead of them to transmit. Thirdly, if a RTA traffic frame is next to transmit, it might still need to wait for a long frame of another access category (a bulk file transfer in AC_BE, for example) to finish before it can transmit. A mechanism is desired for enabling low latency requirement traffic frames, for example real time application frames, to get around these restrictions to enable higher priority transmission of traffic frames than is currently available in WLAN traffic scheduling.

Aspects of the present disclosure propose a method of communicating over a wireless LAN comprising transmitting a first traffic frame, comprising a first header including a frame type and subtype, and mapping the traffic frame to a first Enhanced Distributed Channel Access (EDCA) access category (AC). The method further comprises obtaining a transmission opportunity (TXOP) for a second EDCA AC to transmit traffic frames on a wireless medium, and based on the values of the frame type and subtype, transmitting the first traffic frame during the TXOP before any other traffic frames which are mapped to the first EDCA AC.

An example embodiment of the method of the present disclosure is described below with regard to <FIG> and <FIG>. <FIG> then illustrates operation of a Basic Service Set according to embodiments of the present disclosure.

<FIG> is a block diagram illustrating the journey of data packets <NUM>, <NUM> as they travel through various layers of a protocol stack <NUM> from an application layer <NUM> executing a program on a wireless device <NUM> to the physical layer <NUM> of a network interface for transmission over a medium <NUM>. In the OSI (Open Systems Interconnection) model, there are <NUM> layers of functionality in order of visibility to the end user. Layer <NUM>, the application layer (<NUM> in <FIG>), is the domain of applications that process human-compatible input and output. Beneath that lies Layer <NUM>, the presentation layer, responsible for, in one example, encryption and decryption of data for secure transmission. Layer <NUM>, the session layer, manages persistent connections between machines (sessions) such as telnet, ftp, or http sessions. Beneath this, Layer <NUM>, the transport layer, establishes numbered ports over which protocols such as TCP and UDP can work. Underneath this, Layer <NUM>, the network layer, is where DNS, routers, and IP addresses make sure data travels to the right place anywhere in the world. Layer <NUM>, the data link layer, responsible for maintaining logical LAN connections, comprises the Logical Link Control layer and a lower sublayer, the Medium Access Control (MAC) layer (<NUM> in <FIG>). Components on a LAN refer to one another by their MAC addresses. Finally, layer <NUM>, the physical layer (<NUM> in <FIG>), controls the actual bit transmission over physical media such as radio waves and cables. The physical layer modulates, scrambles, and encodes signals to provide robust and private transmission. Some layers of the protocol stack are omitted in this discussion for clarity, as they do not perform any steps of the present disclosure.

With reference to <FIG>, a generalized network packet <NUM> which has been generated by the application layer <NUM> is marked by an icon representing a series of information fields indicated by blank squares. An application may identify a network packet as a real time application (RTA) packet if the application generating it demands low latency, real-time communications. An RTA network packet <NUM> is marked by a similar icon except for an RTA identifier <NUM> symbolized by a first pattern fill in a square of the icon of the network packet <NUM>. The exact format of the RTA identifier <NUM> is outside the scope of the present disclosure, but it may take the form, for example, of a packet type field or subfield in the packet header. This advantageously allows RTA packets to be treated differently from other packets when they reach the MAC layer. Network packets <NUM>, <NUM>, both general and RTA, may reach the MAC layer <NUM> in any order as a result of being generated by the application layer <NUM> or, in an alternate example, being received by the PHY layer <NUM> as traffic frames and decoded as having eventual destinations different from the wireless device <NUM> which received them. In this case, the MAC layer hardware <NUM> repackages a network packet into a new traffic frame for retransmission to its eventual destination.

To prepare network packets for traveling to other network nodes, the MAC layer hardware <NUM> prepends a MAC header onto each network packet, creating a MAC Protocol Data Unit (MPDU) of each one. The MAC header of an RTA MPDU <NUM> comprises an identifier (for example a frame type and subtype) represented by patterned fill square <NUM>, whose value identifies the frame as an RTA frame. A blank square <NUM> occupying a similar position in an MPDU icon <NUM> signifies an identifier of a different value, signifying a general MPDU not from a real time application.

A detailed structure of the MAC header, adapted from IEEE802. <NUM>-REVmd/D3. <NUM>, is given in <FIG>. MAC header <NUM> comprises several fields, of particular note the frame control field <NUM> and Quality of Service (QoS) control field <NUM>. The Frame Control field <NUM> comprises bit positions B2 and B3 <NUM> indicating a Frame Type and bit positions B4 to B7 <NUM> indicating a Frame Subtype. The possible values of these subfields differentiate between the various possible Management, Control, Data, and Extension frames. Frame type (expressed as B3B2) can take on values including <NUM> for Management, <NUM> for Control, <NUM> for Data, and <NUM> for Extension. The first three frame types already have all of their subtypes allocated to specific purposes. According to an embodiment of the present disclosure, the identifier <NUM>, <NUM> comprises a novel combination of frame type <NUM> and subtype <NUM> values, which in combination <NUM> identify the MPDU as an RTA MPDU to any device capable of decoding the MAC header. A new subtype value in the range <NUM> (B7B6B5B4) to <NUM> of Frame type <NUM> for Extension frames is proposed to indicate that a traffic frame is QoS RTA Data. The setting of B7 to <NUM> retains backward compatibility with previously defined QoS Data frame subtypes of the Frame type <NUM> Data.

Thus, according to an embodiment of the present disclosure, the MAC hardware <NUM> prepends to RTA packets <NUM> a MAC header <NUM> comprising a frame type <NUM> and subtype ranging from <NUM> to <NUM>, creating RTA MPDUs <NUM>. To non-RTA packets <NUM> it prepends a MAC header <NUM> comprising a different combination of frame type and subtype <NUM>, creating general MPDUs <NUM>.

The other relevant portion of the MAC header to RTA MPDUs is the Quality of Service (QoS) control field. The QoS Control field format <NUM> comprises a subfield TID <NUM> used to identify the User Priority UP in a <NUM> bit value from <NUM> to <NUM> corresponding to the UP in Table <NUM>. In an embodiment of the present disclosure, Real Time Application MPDUs <NUM> are assigned a UP of <NUM> or <NUM> to ensure they are mapped into the AC_VO access category <NUM>.

The MAC layer hardware <NUM> maps the non-RTA traffic frames <NUM> into any of four Access Categories (AC) AC_BK <NUM>, AC_BE <NUM>, AC_VI <NUM>, and AC_VO <NUM> based on the value of their User Priority according to Table <NUM>. In general, a FIFO queue is maintained for each AC so that MPDUs queued first generally are transmitted before other MPDUs queued later in the same AC. Noting that information flow in <FIG> is represented as from the top to the bottom of the diagram, a frame positioned in the bottom of an access category queue is at the head of the queue. Advantageously according to the present disclosure, the MAC hardware <NUM> recognizes RTA MPDU <NUM> and others like it, queueing them first, overriding the FIFO ordering. Thus RTA traffic frames will transmit with priority before any other traffic in AC_VO <NUM> once a TXOP <NUM> is obtained for that queue.

The TXOP acts as a gate for PHY layer processing of MPDUs into physical medium traffic frames and transmission of the traffic frames. Contention for a TXOP in EDCA is carried out by EDCA Functions(EDCAF). Each AC's EDCAF accomplishes this by first checking for a clear channel indication and setting the network allocation vector to zero. It then waits for a time equal to its contention window, which is a sum of an arbitration interframe spacing (different for each AC) and a random backoff time. If the channel is still clear, the EDCAF attempts to access the medium. A collision arbitration function in the MAC layer <NUM> resolves any collisions (ties, simultaneous transmit attempts) between EDCAFs within the single STA. The winning EDCAF causes the STA to send MPDUs <NUM>, <NUM> into the PHY <NUM> to try to transmit them as traffic frames. At this point, in the prior art, MPDUs from the queue of the winning AC would be sent to the PHY for transmission. However, a technical advantage is provided by an embodiment of the present disclosure in which no matter which EDCAF wins the contention, the first frames sent for transmission by the PHY layer <NUM> are to be the RTA frames <NUM> marked with the RTA frame type and subtype <NUM>. Only after all RTA frames <NUM> are transmitted, may other frames <NUM> from the contention-winning AC be transmitted in FIFO order within the time limit defined by the TXOP <NUM>. If the TXOP runs out before all RTA traffic is transmitted, the STA must contend again for another TXOP before transmitting the remaining RTA traffic frames and non-RTA frames.

In a case in which there are no RTA MPDUs <NUM> queued in AC_VO <NUM> and the STA <NUM> maintaining the queues <NUM><NUM><NUM><NUM> wins a TXOP <NUM> for a first AC, which may be for example AC_BK <NUM> or any of the other access categories, the leading MAC frame <NUM> in the first AC queue <NUM> will be sent to the PHY <NUM> for transmission. At some point during the transmission of the non-RTA frame <NUM>, an RTA frame <NUM> may be put in queue in AC_VO <NUM> at the transmitting STA <NUM>. According to the present disclosure, this RTA frame <NUM> will become the next frame to transmit, provided sufficient time remains in the TXOP. In one embodiment of the present disclosure, the RTA frame <NUM> will be given a non-preemptive priority, meaning the RTA frame <NUM> will transmit once the non-RTA frame <NUM> completes transmission, TXOP length permitting. In an alternate embodiment, the RTA frame <NUM> will be given a pre-emptive priority, meaning the non-RTA frame <NUM> will immediately cease transmission to free the wireless medium <NUM> for transmitting the RTA frame <NUM>. In the case where the transmitting STA <NUM> notifies the receiving STA that the transmission is pausing, the non-RTA frame <NUM> can be resumed from the point of interruption once the RTA frame <NUM> transmission is completed, again TXOP length permitting. In the case where the transmitting STA <NUM> does not notify the receiving STA that the transmission is pausing, the frame fragment will be discarded at the receiver and the transmission must start from the beginning.

With reference to <FIG>, a flowchart is now presented which describes the operation of a WiFi Basic Service Set (BSS) according to embodiments of the present disclosure. BSS <NUM> comprises, for example, at least an AP <NUM>, STA A <NUM> and STA B <NUM>. Each component of the BSS <NUM> is associated with a vertical timeline on the flowchart that proceeds from top to bottom in chronological order. Events internal to each component are marked with boxes, and transmission/reception/carrier sense events between components are marked with arrows representing the direction of information communication.

At the beginning of the flowchart, AP <NUM> is managing communications on a wireless link medium. The medium is characterized by a busy state <NUM> if, for example, the AP is transmitting management frames to other STAs that are not shown. Concurrently, STA A <NUM> is preparing data for network transmission, generating firstly an AC_VI category frame <NUM> and secondly an RTA type frame <NUM> which will be mapped to the AC_VO. STA B <NUM> is also preparing data for transmission, generating an AC_BK frame <NUM> and an AC_BE frame <NUM>.

STAs A <NUM> and B <NUM> have data queued for transmission, they perform Clear Channel Assessments <NUM> and <NUM> to try and sense if PPDUs are being transmitted over the wireless medium, or if there is non-Wi-Fi energy present in the frequency channel (a <NUM> baby monitor signal, for example). The STAs determine the channel is clear, so they begin to contend for the TXOP.

STA A <NUM> has two queues frames waiting to send: AC_VO and AC_VI. Both of these ACs use an AIFS of <NUM> timeslots, with a standard timeslot duration of <NUM>. Thus both the AC_VO AIFS <NUM> and AC_VI AIFS <NUM> will take <NUM> to elapse before these queues enter their contention window timers. The AC_BK queue at STA B <NUM> waits an AIFS <NUM> of <NUM> timeslots (<NUM>), whereas the AC_BE AIFS <NUM> is <NUM> timeslots (<NUM>).

The AIFS <NUM>, <NUM> at STA A <NUM> will finish first, and each EDCAF contending within STA A will be assigned a random contention window time selected from the range of values configured for its respective AC. In the present example, the randomly generated values are <NUM> for the AC_VO contention window <NUM> and <NUM> for the AC_VI contention window <NUM>. Thus the AC_VI EDCAF at STA A <NUM> will win contention for the medium and be granted the TXOP <NUM> by the AP. AC_VI is typically granted a TXOP length <NUM> of <NUM> of contention-free time within which to send as many queued frames as are available in AC_VI.

According to existing QoS operation, the RTA frame <NUM> would have to wait for the AC_VI TXOP to end, and additionally until the next time AC_VO at STA A wins a TXOP, to be transmitted. But according to an embodiment of the present disclosure, STA A <NUM> checks to see if any RTA frames are in queue in AC_VO, despite AC_VO not winning the TXOP. In the present example there is one, and STA A begins transmission <NUM> of the RTA frame. At the conclusion of RTA frame transmission <NUM>, the AP may reply with an acknowledgement (ACK) frame if needed <NUM> to notify STA A <NUM> of a successful reception. RTA frames from an online game, for example, are typically characterized by short packets of state data such as position, acceleration, sprite collision flags, and action initiation commands. As such, RTA transmission <NUM> will not cause much of a delay in the transmission <NUM> of the AC_VI frame, which begins just a SIFS (<NUM> in <NUM>. 11ac) after the RTA's acknowledgement frame <NUM> is received at STA A <NUM>. Thus a technical advantage is realized in saving precious milliseconds of latency in a real-time two-way communication application though not materially affecting the frame rate of a video transmission that is typically buffered by a few seconds to begin with.

When AC_VI transmission <NUM> concludes, and the AP <NUM> has acknowledged <NUM> the AC_VI frame, STA A <NUM> has no more frames left to send. Even though the TXOP limit <NUM> is far from over, STA A will stop transmitting, allowing other STAs including STA B <NUM> to sense a clear channel <NUM>. At STA B <NUM>, the AC_BE AIFS <NUM> of <NUM> was nearing completion, with <NUM> to go when the STA A contention window <NUM> finished. AC_BE contention window <NUM> is the next to begin counting down, from <NUM> in the present example. AC_BE at STA B will win the TXOP <NUM> next, as AC_BK did not finish its AIFS before the next frame <NUM> appeared on the channel, and AC_BK will need to start over its AIFS <NUM> and wait for a contiguous <NUM> of idle channel before contending.

Continuing the flowchart, AP <NUM> grants an AC_BE TXOP <NUM> to STA B <NUM>. Accordingly, STA B <NUM> transmits the BE frame <NUM>, and the AP responds with an ACK frame <NUM>. It will be appreciated that processors that control wireless electronic devices are capable of performing tasks in parallel owing to multiple cores and multithreaded architecture. As such, during transmission of, for example, a large multi-millisecond AC_BE frame <NUM>, in some embodiments STA B <NUM> may generate an RTA frame <NUM> and queue it in AC_VO before AC_BE frame transmission <NUM> completes. According to one embodiment of the present disclosure, the RTA frame <NUM> would receive non-preemptive priority and be queued next for transmission during the TXOP <NUM> after the conclusion of frame transmission <NUM> and frame acknowledgement <NUM>. Whereas this next-in-line privilege eliminates the latency incurred by re-contending for the TXOP, the RTA frame would still have to wait the entire duration of the incumbent transmitting frame. To provide a further advantage in transmission promptness, in an alternate embodiment of the present disclosure, the RTA frame <NUM> would receive pre-emptive priority in order to advantageously avoid multiple milliseconds of latency. To implement pre-emptive priority, STA B pauses AC_BE frame transmission <NUM>, transmits the RTA frame <NUM>, and receives acknowledgement <NUM> from the AP <NUM> for the RTA frame. In one embodiment, STA B <NUM> resumes transmission <NUM> of the AC_BE frame, salvaging the effort <NUM> already spent on transmitting the first part of AC_BE frame. In an alternate embodiment, AP <NUM> does not allow the TXOP <NUM> to be extended to finish AC_BE frame transmission <NUM>, and AC_BE must once again contend for a TXOP.

Claim 1:
A method of communicating over a wireless LAN (<NUM>) comprising:
obtaining, by a wireless electronic device (<NUM>), a transmission opportunity (<NUM>) via Enhanced Distributed Channel Access for a first access category (<NUM>, <NUM>); and
transmitting, by the wireless electronic device, a first traffic frame (<NUM>) comprising a header (<NUM>), the header including a frame type subfield (<NUM>) and a frame subtype subfield (<NUM>), the values of the frame type and frame subtype subfields (<NUM>) identifying the first traffic frame as a real time application frame;
wherein the first traffic frame is mapped to a second access category (<NUM>, <NUM>) different from the first access category, such that the first traffic frame is the first frame transmitted during the transmission opportunity even when the first access category is allocated to the transmission opportunity,
wherein there are a plurality of traffic frames, each comprising the frame type and frame subtype subfields identifying the plurality of traffic frames as real time application frames (<NUM>), are transmitted within the transmission opportunity before any traffic frames <NUM> belonging to the first access category (<NUM>, <NUM>) are transmitted; and
no traffic frames (<NUM>) comprising the frame type and frame subtype subfields identifying traffic frames as real time application frames are transmitted within the transmission opportunity after any traffic frames (<NUM>) belonging to the first access category are transmitted.