Patent Description:
The technology of this disclosure pertains generally to wireless communication stations, and more particularly to wireless local area network (WLAN) stations communicating a combination of real time and non-real time traffic.

Current wireless technologies using Carrier Sense Multiple Access/Collision Avoidance (CSMA / CA) focus on high overall network throughput, however they lack low latency capability for properly supporting real time applications (RTAs).

An RTA requires low latency communication and uses best effort communication. The data generated from the RTA is called RTA traffic and is packetized as RTA packets at the transmitter station (STA), while the data generated from a non-time sensitive application is called non-RTA traffic and is packetized as non-RTA packets at the transmitter STA. These RTA packets require low latency due to a high timeliness requirement (real-time) on packet delivery. The RTA packet is valid only if it can be delivered within a certain period of time.

Due to the random channel access scenario, a STA needs to sense and contend for channel access before transmitting each packet. Although obtaining a short channel contention time accelerates channel access, it increases the probability of packet collision. The delay inherent in packet collisions is still significant due to the channel contention time required for each retransmission. To avoid packet collisions and improve packet delivery success rates, an STA retransmits the packet following a longer channel contention period after a packet collision, which further delays the packet.

In view of the above, it is seen that there are still significant latencies involved in communicating time sensitive RTA packets within a CSMA / CA system.

Accordingly, a need exists for enhanced handling of real time application (RTA) packets and significantly reducing packet latency. The present disclosure fulfills that need and provides additional benefits over previous technologies.

Non-patent document "<NPL>et al) presents a new energy-efficient MAC scheme for fully connected wireless ad hoc networks, that reduces energy consumption by putting radio interfaces in the sleep state periodically and by reducing transmission collisions, which results in high throughput and low packet transmission delay.

<CIT> relates to an apparatus and method for processing packets in which a multiple queue model for sorting and processing real-time service packets and data packets is provided and simultaneously fragmentation threshold values of the data packets are dynamically adjusted.

Non-patent document "<NPL>et al) proposes a fair scheduler for A-MDSU aggregation that transmits the MSDUs according to their priority based on their lifetime.

Non-patent document "<NPL>et al) discloses another example of the prior art.

The communication of packet traffic for real time applications (RTAs) is enhanced by reserving future channel time. Yet, obtaining a future channel reservation for an RTA packet in a CSMA / CA system introduces numerous challenges. In the present disclosure stations are able to distinguish between RTA packets and non-RTA packets, and separate the channel access scheme for RTA packets from that of non-RTA packets, thus allowing non-RTA packet traffic to still use regular random channel access scheme defined in CSMA / CA.

The disclosed technology allows the station (STA) to have knowledge of the arrival time of RTA traffic at its Medium Access Control (MAC) layer and schedule the future channel time for RTA traffic transmission. In addition, this technology allows the STA to occupy the channel before the scheduled channel time for RTA traffic transmission. The STA thus can have channel access for the RTA traffic at the beginning of the scheduled channel time.

The disclosed technology schedules channel time based on the expected RTA packet arrival and allows the STA to reject the non-RTA packet and unexpected RTA packet transmission during the scheduled channel time for RTA packet transmission. The future RTA channel time reservation of this disclosure considers the time-validity of RTA traffic and minimizes its latency in a wireless network where RTA and non-RTA traffic coexist. Thus, the disclosure technology overcomes many issues with existing wireless networking technologies that fail to meet timeliness requirements of RTA packets.

Further aspects of the technology described herein will be brought out in the following portions of the specification, wherein the detailed description is for the purpose of fully disclosing preferred embodiments of the technology without placing limitations thereon.

The technology described herein will be more fully understood by reference to the following drawings which are for illustrative purposes only:.

Conventional WLAN systems under IEEE <NUM>, specifically up to <NUM>. 11ax, use carrier-sense multiple access / collision avoidance (CSMA / CA) to allow stations (STAs) to have random access to the channel for packet transmission and retransmission.

<FIG> depicts contention-based channel access in CSMA / CA. In a CSMA / CA system, the STA senses the channel for transmission when there is data to transmit. Before each transmission and retransmission, the STA has to sense the channel and set a backoff time to contend for channel access. The backoff time is decided by a uniform random variable between zero and the size of a contention window (CW).

After the STA waits for the backoff time and senses that the channel is idle (unoccupied), the STA decides whether to send a Ready To Send (RTS) frame to ensure channel occupancy or not. If the STA sends an RTS frame, the channel occupancy is ensured when it receives a Clear To Send (CTS) frame, whereby the STA sends the packet. If the STA does not send an RTS frame, then it sends the packet directly. A retransmission is required if the CTS frame is not received after sending an RTS frame, or if the STA does not receive an ACKnowledgement (ACK) before timeout. Otherwise, the transmission succeeds. When the retransmission is required, the STA checks the number of retransmissions of the packet. If the number of retransmissions exceeds the retry limit, then the packet is dropped and no retransmissions are scheduled. Otherwise, the retransmission is scheduled. If the retransmission is scheduled, then another backoff time is needed to contend for channel access for the retransmission. If the size of the contention window does not reach the upper limit, then the STA increases it. The STA sets another backoff time depending on the new size of the contention window. The STA waits the backoff time for retransmission and so forth.

<FIG> depicts one example of random channel access in CSMA / CA where the RTS / CTS is disabled. It will be noted that the <NUM> standard regarding CSMA / CA utilizes the two lowest levels in the OSI networking stack, which are the Physical (PHY) layer and the Medium Access Control (MAC) layer. When the MAC layer of the transmitter STA receives the data from its upper layers, it contends for the channel to gain access. When the transmitter STA contends for the channel, it has to wait until the backoff time, whereby the size of the contention window is n slots, and counts down to zero. The count-down process will be interrupted, such as by a Clear Channel Assessment (CCA) that indicates busy, when other packet transmissions are occurring over the channel. After the transmitter STA gains channel access to transmit the data, it packetizes the data into a packet and transmits the packet over the channel. As shown in the figure, if the initial transmission of the packet does not succeed, a retransmission of the packet is performed. The transmitter STA sets backoff time again to contend for channel access. This time, the size of the contention window is doubled, which is <NUM>*n slots, due to the retransmission. The expected backoff time is also doubled by the contention window size. When the backoff time is longer, there is more chance that the count-down process will be interrupted (i.e., CCA busy) by other packet transmissions.

In CSMA / CA, a STA is able to occupy the channel by using an RTS/CTS exchange which protects packet transmission from interference from other nodes, especially in a hidden node problem (situation).

<FIG> depicts the content of a RTS frame having the following fields. A Frame Control field indicates the type of the frame. A Duration field contains network allocation vector (NAV) information used for CSMA / CA channel access. A Recipient Address (RA) field contains the address of a recipient of the frame. A Transmitter Address (TA) field contains the address of the station that transmitted the frame.

<FIG> depicts the content of the CTS frame having the following fields. A Frame Control field indicates the type of the frame. A Duration field contains NAV information used for CSMA / CA channel access. An RA field contains the address of the recipient of the frame.

<FIG> depicts an example explaining how a station occupies the channel by using RTS / CTS exchange in CSMA / CA. Before the transmitter STA transmits the packet, it first sends an RTS frame to request the channel occupancy time for the packet transmission. When the receiver STA receives the RTS frame, it sends a CTS frame back to the transmitter STA to report that the channel occupancy time is reserved for the packet transmission. The other STAs receiving RTS and CTS frames will set the network allocation vector (NAV) to reserve that time, so that during the period of time set by the NAV, the other STAs will not transmit any packets.

The current wireless communication systems using CSMA / CA do not identify, or distinguish, an RTA packet from a non-RTA packet, nor do they reserve specific channel times for RTA traffic. Under CSMA / CA all the packets must use the same random channel access scheme. The random channel access scheme in CSMA / CA cannot guarantee channel time for RTA packet transmission. CSMA / CA arranges channel access after the data arrives at the MAC layer. In most cases, the data has to wait in the queue to be transmitted, which causes a queuing delay for packet transmission.

The RTA packet in the present disclosure, however, has priority over non-RTA packets. And within RTA packets, the RTA packet with higher priority should always transmit earlier than the RTA packet with lower priority. However, the random channel access scheme in CSMA / CA is directed to fair access between all the packet transmissions. That is, the packet with low priority has a chance to be transmitted earlier than the packet with higher priority. The RTS / CTS exchange in CSMA / CA forces all the other STAs to set the NAV and keep quiet. Though this design protects the packet transmission between two STAs from the interference due to other STAs, it blocks channel access to other STAs that may have more important data to be transmitted.

By utilizing the disclosed technology, STAs are able to identify and distinguish RTA packets from non-RTA packets. The disclosed technology separates the channel access scheme for RTA packets from non-RTA packets, and allows non-RTA packets to still use the regular random channel access scheme defined in CSMA / CA. The disclosed technology allows the STA to obtain information (knowledge) of the arrival time of RTA traffic at its MAC layer and schedule future channel time for an RTA traffic transmission. The disclosed technology allows the STA to occupy the channel before the scheduled channel time for RTA traffic transmission; therefore, the STA should have channel access for the RTA traffic at the beginning of the scheduled channel time. The disclosed technology allows the STA to reject the non-RTA packet and unexpected RTA packet transmission during the scheduled channel time for RTA packet transmission.

<FIG> illustrates an example embodiment <NUM> of STA hardware configuration showing I/O path <NUM> into hardware block <NUM>, having a computer processor (CPU) <NUM> and memory (RAM) <NUM> coupled to a bus <NUM>, which is coupled to I/O path <NUM> giving the STA external I/O, such as to sensors, actuators and so forth. Instructions from memory <NUM> are executed on processor <NUM> to execute a program which implements the communication protocols, which are executed to allow the STA to perform the functions of a "new STA", or one of the STAs already in the network. It should also be appreciated that the programming is configured to operate in different modes (source, intermediate, destination, access point (AP) and so forth); depending on what role it is playing in the current communication context.

The STA may be configured with a single modem and single radio-frequency (RF) circuitry, or it may be configured with multiple modems and multiple RF circuits as depicted by way of example and not limitation in <FIG>. In this example, the host machine is shown configured with a millimeter-wave (mmW) modem <NUM> coupled to radio-frequency (RF) circuitry 22a, 22b, 22c to a plurality of antennas 24a - 24n, 26a - 26n, 28a - 28n to transmit and receive frames with neighboring STAs. In addition, the host machine is also seen with a sub-<NUM> modem <NUM> coupled to radio-frequency (RF) circuitry <NUM> to antenna(s) <NUM>, although this second communication path is not absolutely necessary for implementing the present disclosure.

Thus, this host machine is shown configured with two modems (multi-band) and their associated RF circuitry for providing communication on two different bands. By way of example and not limitation the intended directional communication band is implemented with a millimeter-wave (mmW) band modem and its associated RF circuitries for transmitting and receiving data in the mmW band. The other band, generally referred to a discovery band, comprises a sub-<NUM> modem and its associated RF circuitry for transmitting and receiving data in the sub-<NUM> band.

Although three RF circuits are shown in this example for the mmW band, embodiments of the present disclosure can be configured with modem <NUM> coupled to any arbitrary number of RF circuits. In general, using a larger number of RF circuits will result in broader coverage of the antenna beam direction. It should be appreciated that the number of RF circuits and number of antennas being utilized is determined by hardware constraints of a specific device. Some of the RF circuitry and antennas may be disabled when the STA determines it is unnecessary to communicate with neighbor STAs. In at least one embodiment, the RF circuitry includes frequency converter, array antenna controller, and so forth, and is connected to multiple antennas which are controlled to perform beamforming for transmission and reception. In this way the STA can transmit signals using multiple sets of beam patterns, each beam pattern direction being considered as an antenna sector.

It is seen therefore, that the host machine accommodates a modem which transmit/receives data frames with neighboring STAs. The modem is connected to at least one RF module to generate and receive physical signals. The RF module(s) include a frequency converter, array antenna controller, and other circuitry as necessary. The RF module(s) are connected to multiple antennas which are controlled to perform beamforming for transmission and reception. In this way, the STA can transmit signals using multiple sets of beam patterns.

<FIG> illustrates an example network topology (scenario) <NUM> as an aid to explaining the goal of the disclosed technology. By way of example and not limitation, this example assumes there are <NUM> STAs consisting of two Basic Service Sets (BSSs) in a given area <NUM>, herein exemplified as a room. Each STA can communicate with the other STAs in the same BSS. All STAs use CSMA / CA for random channel access. A first BSS depicts STAG <NUM> operating as an access point (AP) and non-AP stations STA1 <NUM>, STA2 <NUM>, STA3 <NUM> and STA4 <NUM>. A second BSS depicts STA5 <NUM> as AP along with STA6 <NUM>, STA7 <NUM>.

All STAs in this example are considered to support both applications requiring low latency communication and applications that utilize best effort communication. The data generated from the application requiring low latency communication is called Real Time Application (RTA) traffic and will be packetized as RTA packets at the transmitter STA. Also, the data generated from the non-time sensitive applications are called non-RTA traffic and are packetized as non-RTA packets at the transmitter STA. As a consequence, the transmitter STA generates both RTA traffic and non-RTA traffic for communication. The location of the STAs and their transmission links are as shown in this example network topology figure.

When the STA transmits a non-RTA packet, the STA can follow the regular CSMA / CA scheme. One goal of the disclosed technology is to reduce latency of RTA traffic.

<FIG> illustrates an example embodiment <NUM> of RTA and non-RTA traffic communication which generally follow an Open Systems Interconnection (OSI) model. In an OSI model there is an Application Layer, Transport Layer, Network Layer (IP), Data Link Layer (MAC), and Physical Layer (PHY). In the present disclosure the transport layer and network layer are merely referred to as layers in the middle, with the described protocol (e.g., proposed IEEE802. <NUM> variant/standard) utilizing the MAC and PHY layers.

In this section, the STA layer model for traffic communication is explained. As shown in this example two STAs, STA1 <NUM> and STA2 <NUM> generate RTA traffic and non-RTA traffic <NUM>, <NUM> and communicate with each other with RTA packets <NUM> and non-RTA packets <NUM>. The overall process is explained below.

Both RTA traffic and non-RTA traffic are generated by the APP layer 76a, 78a of the respective transmitter STAs. The APP layer of the transmitter STA passes the RTA traffic and non-RTA traffic to the MAC layer 76c, 78c via (through) layers in the middle 76b, 78b. The MAC layer 76c, 78c and the PHY layer 76d, 78d append additional signal fields in the MAC header and PLCP header to the packet, and the packets are transmitted over the PHY layer of the network.

The receiver STA receives the packets at the PHY layer, decodes and sends them to its MAC layer if the packets are decoded correctly, after which the data is fed to its APP layer through (via) layers in the middle.

The disclosed technology classifies packets in the wireless communication system as being either RTA or non-RTA packets. RTA packets use reserved future channel time for transmission and use an immediate retransmission scheme for packet retransmissions, while non-RTA packets may use the regular CSMA / CA scheme. To that end, the STA identifies the RTA packet and non-RTA packet at the MAC layer. This process is described in this section.

According to the STA layer model shown in <FIG>, it is possible that the MAC layer of the transmitter STA identifies the RTA traffic and non-RTA traffic from the upper layers and packetizes them into RTA packets and non-RTA packets, respectively. This section provides the details of how the transmitter STA identifies the RTA traffic using prior negotiation.

According to the STA layer model shown in <FIG>, the transmitter STA transmits the packets to the receiver STA over the PHY layer of the network. When the receiver STA receives the packet at the MAC layer, it is able to identify the RTA packet and non-RTA packet based on the information embedded in the MAC header or Physical Layer Convergence Protocol (PLCP) header. This section provides the details on how the receiver STA identifies the RTA packet based on the PLCP or MAC header information.

The RTA traffic has to be communicated within a given lifetime to assure the validity of the data. In other words, if the RTA traffic is not received by the receiver before this lifetime expires, the RTA traffic is invalid and can be discarded. The STA packetizes the RTA traffic into RTA packets for transmitting through the PHY layer. Hence, the RTA packet also has a lifetime for its transmission. This section provides the details of how the STA copes with the lifetime expiration of the RTA packet.

Often, real time applications (RTAs) generate traffic periodically, just as with connection-oriented communication. RTA connection-oriented communications established by an application between STAs is called an RTA session. It is possible that STAs can have multiple RTA sessions in the network. Each STA according to the present disclosure is able to manage those RTA sessions properly.

Before an RTA session starts transmitting RTA traffic, a prior negotiation occurs between the transmitter STA and the receiver STA to establish the connection. During the prior negotiation, the transmitter STA and the receiver STA record the RTA session with the RTA session identifying information that can be used for identifying the RTA traffic at the MAC layer of the transmitter side and the RTA packet at the MAC layer of the receiver side.

As was shown in <FIG>, when the APP layer passes the traffic to the MAC layer on the transmitter side, the layers in the middle add header information to the traffic. When the MAC layer of the transmitter STA receives traffic from the upper layers, it extracts the header information from the upper layers and looks up (searches) the RTA session records created by the prior negotiation. If the header information matches one RTA session in the records, the traffic is RTA; otherwise, the traffic is considered non-RTA. The header information that could be used for identifying RTA traffic is listed in Table <NUM>. In this section, the details of the prior negotiation are described.

According to the prior negotiation results, it is also possible that the receiver STA classifies the RTA and non-RTA packet by the channel resource for packet transmission, such as time, frequency, and other metrics. When a packet is received using the channel resource that is granted for an RTA packet, then the STA identifies it as an RTA packet. Otherwise, that packet is a non-RTA packet. This scenario will be used when the packet is transmitted in multi-user uplink mode.

<FIG> illustrates an example embodiment <NUM> of prior negotiation between transmitter <NUM> and receiver <NUM> for RTA traffic packet <NUM> at transmitter side and packet <NUM> at receiver side. It should be appreciated that one prior negotiation establishes one RTA session and could be used for all the RTA packets generated by that RTA session. The figure shows prior negotiation for establishing an RTA session between two STAs in a STA layer model as was seen in <FIG>. A transmitter STA <NUM> is shown having layers APP 96a, layers in the middle 96b, MAC layer 96c and PHY layer 96d with a receiver STA <NUM> having the same layers APP 98a, layers in the middle 98b, MAC layer 98c and PHY layer 98d. The process of the prior negotiation is explained below.

Referring to <FIG>, the following steps are seen. The APP layer 96a of transmitter <NUM> requests <NUM> a resource (e.g., time, channel) negotiation. Thus, on the transmitter STA side, the APP layer starts an RTA session and requests a negotiation of the channel resources, such as time and bandwidth, for its RTA traffic transmission. This negotiation request is transmitted from the management entity in the APP layer to the management entity residing in the MAC layer.

The MAC layer of the transmitter STA receives the negotiation request from the upper layer and checks <NUM> resource availability on its side. Also, it records the RTA session identifying information provided by the upper layers for identifying RTA traffic in the session. The record of the identifying information could be picked from the information listed in Table <NUM>, such as TCP/UDP port number, the type of service, etc. It may deny the request from the upper layer if the resource is unavailable, or re-negotiate with the upper layer.

If the MAC layer of the transmitter STA finds the resource available, it sends <NUM> a negotiation request frame to the MAC layer of the receiver STA. The negotiation frame contains the identifying information of the RTA session so that the receiver can record and use it afterwards. After the MAC layer of the receiver STA receives the negotiation request frame, it first informs <NUM> its APP layer to get ready for receiving RTA packets by sending a negotiation request from the management entity in the MAC layer to the management entity in the APP layer. The negotiation may fail if the APP layer is not available for RTA transmission.

The APP layer of the receiver grants the availability of resources at its layer and sends <NUM> this information from the management entity in the APP layer to the management entity that resides in the MAC layer. Then, the MAC layer of the receiver STA checks <NUM> the resource availability on its side. The MAC layer can deny or re-negotiate if the resource is unavailable. The MAC layer of the receiver STA collects all the negotiation information on its side and reports it <NUM> to the MAC layer of the transmitter. The MAC layer of the transmitter receives the negotiation result and forwards it <NUM> to its APP layer. If the negotiation succeeds, the APP layer can start to transmit RTA traffic using the resource granted by both STAs.

In the claimed embodiment, according to the RTA session records created by the prior negotiation, the MAC layer of the transmitter STA identifies the RTA traffic and non-RTA traffic by the header information from the upper layers. When the APP layer generates RTA traffic, the RTA traffic is passed to its MAC layer with the header information provided by the layers in the middle. By looking up the RTA session records created by the prior negotiation, the transmitter STA is able to use that header information to identify the RTA traffic and packetizes the RTA traffic into RTA packet at the MAC layer.

<FIG> illustrates an example embodiment <NUM> of identifying RTA packet traffic on the transmitter side. The routine starts <NUM> and the MAC layer of the transmitter STA receives traffic <NUM> from the upper layer. The MAC layer extracts <NUM> information embedded by the upper layer for identifying RTA traffic, and is checking the header information of the upper layers, such as the type of service and the TCP/UDP port number.

The MAC layer of the transmitter STA compares (looks up) <NUM> the header information from the upper layers with the RTA session records created by the prior negotiation. A check <NUM> is made on the header information. If the header information from the upper layers matches one RTA session in the record, then block <NUM> is reached with the traffic determined to be RTA traffic, otherwise block <NUM> is reached with the traffic considered to be non-RTA traffic, after which processing ends <NUM>.

<FIG> illustrates an example embodiment <NUM> of an RTA session identifying information format. When the transmitter STA generates RTA packets, it adds additional signal fields in the PLCP or MAC header. When the additional signal field contains the RTA session identifying information, the receiver STA can use the RTA session identifying information in the PLCP or the MAC header to distinguish at the MAC layer between an RTA packet and a non-RTA packet. One example of the RTA session identifying information is shown in the figure.

<FIG> illustrates an example embodiment <NUM> of header information exchange <NUM>, <NUM> between APP layer and MAC layer. A transmitter STA <NUM> is seen with APP layer 176a, layers in the middle 176b, MAC layer 176c, and PHY layer 176d. A receiver STA <NUM> is seen with the same layers APP layer 178a, layers in the middle 178b, MAC layer 178c, and PHY layer 178d.

The figure depicts details of how this process works between two STAs in the STA layer model. The APP layer of the transmitter STA generates <NUM> RTA traffic and passes it to the MAC layer. When the traffic is passed through the layers in the middle, the header information, such as the type of service field and the TCP/UDP port numbers is added to the traffic. When the MAC layer of the transmitter STA receives the RTA traffic from the upper layer, it extracts the header information, such as the type of service and the TCP/UDP port numbers from the traffic. By looking up the RTA session records created by the prior art, the MAC layer identifies <NUM> the traffic is RTA.

Then the MAC layer of the transmitter STA packetizes the traffic into an RTA packet <NUM> and embeds the type of service and the TCP/UDP port numbers in the MAC header or the PLCP header as the RTA session identifying information. One example of the RTA session identifying information was shown in <FIG>. Next, the transmitter STA sends <NUM> the RTA packet to the receiver STA which receives it as packet <NUM>. When the receiver STA receives the RTA packet at its MAC layer, it can identify <NUM> the RTA packet based on the RTA session identifying information in the PLCP or the MAC header.

<FIG> illustrates an example embodiment <NUM> of a process for identifying an RTA packet on the receiver side at the MAC layer. The process starts <NUM> and the receiver receives a packet at the PHY layer <NUM>. As explained in <FIG>, the MAC header or the PLCP header of RTA packets includes the identifying information of a RTA session. Referring again to <FIG> a check is made <NUM> to determine if the identifying information exists. If the identifying information exists, then execution moves to block <NUM> as the receiver STA has determined that the packet is an RTA packet. Otherwise, if the information does not exist, then execution moves from block <NUM> to <NUM>, as it has been determined that the packet is a non-RTA packet. After which the process ends <NUM>.

In the conventional WLAN, the retransmissions of a packet are discontinued when the number of retransmissions of that packet exceeds the retry limit, and the packet is dropped. In contrast, the RTA packet has a limited lifetime for being transmitted. When the lifetime of the RTA packet expires, the retransmission of that RTA packet stops and the packet is dropped.

The RTA traffic has a lifetime which represents the time during which the information of the packet (traffic) is considered valid. The lifetime of the RTA packet is used to ensure the RTA traffic carried by the packet is valid when the packet is received by the receiver STA. Therefore, the lifetime of the RTA packet should not be longer than the lifetime of the RTA traffic. In the simplest case, those two lifetimes can be set to the same value.

<FIG> illustrates an example embodiment <NUM> of an RTA packet being dropped due to an expired packet lifetime, in particular in the case of when the retransmission of an RTA packet is not scheduled due to the expiration of the packet lifetime. The figure depicts a transmitter STA <NUM> and receiver STA <NUM>. When the transmitter STA transmits an RTA packet, it sets a lifetime <NUM> to transmit that packet. An initial transmission is seen <NUM>. In the figure the value G1 represents Short Interframe Spaces (SIFS), G2 represents Distributed Coordination Function (DCF) Interframe Spaces (DIFS) and G3 represents an ACKnowledgement (ACK) Timeout. Before performing any retransmitting of the RTA packet, the transmitter STA checks whether the lifetime of the packet expires. The retransmission is not scheduled and that packet is dropped if the lifetime has expired. In this example, the transmitter after the period <NUM> (G2+G3) which is between events <NUM> and <NUM>, and performs a backoff <NUM>, after then having obtained the channel, the STA transmits a first retransmission <NUM> since the packet lifetime has not expired. After that, it checks the packet lifetime and it is found in this example that it has expired <NUM>, so it stops retransmitting and drops the packet.

On the receiver side, the RTA packet could be stored in the buffer before the packet lifetime expires. When the packet lifetime expires, the receiver should delete that packet from the buffer since the RTA traffic in the packet is no longer valid.

This section details how a STA creates an RTA session and how the STA manages multiple RTA sessions at its MAC layer. As mentioned in Section <NUM>. <NUM>, the transmitter and the receiver STAs are able to identify the RTA traffic or packet by looking up the RTA session record created by prior negotiation. The disclosed technologies allow the STAs to create an RTA session table when a STA has RTA sessions to be established. A STA collects information about each RTA session and records the information in the RTA session table. RTA sessions can be inserted, removed, and modified in the table.

When a STA records an RTA session, it collects the information of that RTA session which could be used to track the session. In order to track the RTA session, the following requirements must be met for the RTA session. (a) Recording Identifying information to identify the RTA session and distinguish it from other RTA sessions. (b) Collecting status information to report the recent status of the RTA session. (c) Obtaining requirement information to indicate the transmission quality requirement of the RTA traffic generated by the RTA session. (d) Utilizing transmission information to show the channel resource that is distributed to the RTA traffic generated by the RTA session.

<FIG> illustrates an example embodiment <NUM> of RTA session information. The identifying information that is from the MAC header, such as Source MAC Address and Destination MAC Address, which are from the layers above the MAC layer are listed in Table <NUM>, such as Session ID, Type of Service, Source IP Address, Source Port, Destination IP Address, Destination Port.

The following describes aspects of the status information such as Session Status, Comment, and Last Active Time. The session status shows whether the RTA session is set to generate traffic or not. Table <NUM> lists the possible states of RTA session status. When the RTA session status is active, the RTA session is enabled and generating RTA traffic. When the RTA session status is inactive, the RTA session is disabled to not generate RTA traffic by the user. When the RTA session status is error, the RTA session is not able to generate or transmit RTA traffic because of the error.

The Comment field can be used to show the details of the RTA session status. It can be used to carry warnings or error messages. For example, the comment could indicate that the transmission quality is poor when multiple RTA packets have been corrupted in the session.

The Last Active Time can be used to trigger an event, such as to check the status of the RTA session. Last Active Time is updated every time when RTA packet transmission occurs for the RTA session. This information can be used to track whether the RTA traffic is generated or delivered regularly. If the last active time is not updated for a certain period of time, then the RTA session is not generating or delivering RTA traffic. In at least one embodiment the RTA session status is regularly checked to determine whether errors are occurring.

Requirement information including Bandwidth Requirement, Delay Requirement, Jitter Requirement, Periodic Time, Priority, Session Start Time, and Session End Time are now described. The Bandwidth Requirement indicates the amount of the RTA traffic to transmit. The Delay Requirement indicates the transmission delay of the RTA packets. The Jitter Requirement indicates the maximum difference in the RTA packet delay during each periodic transmission time. The Periodic Time indicates the period of time between RTA transmissions in the RTA session. That is to say that the RTA session generates traffic every "periodic time". The Priority indicates the priority of the RTA traffic. The system is configured to first transmit RTA traffic with higher priority. The Session Start Time and Session End Time indicates the start time and the end time of the RTA session.

Transmission information including Time Allocation, Resource Unit (RU) Allocation, and Space Stream (SS) Allocation are now described. The Time Allocation indicates the channel time that is distributed to the RTA session for transmission. The RU Allocation indicates the resource unit (RU) of the channel that is distributed to the RTA session for transmission. The RU is a unit in OFDMA terminology used in IEEE <NUM>. 11ax, and it indicates which channel frequency to use for transmission. The SS Allocation indicates the spatial stream allocation for the RTA session traffic transmission. The SS allocation can be a unit as per MIMO terminology used in IEEE <NUM>, or an index of directional antenna pattern in beamforming terminology.

Table <NUM> shows an example of RTA session table created by STA <NUM> when considering the network topology in <FIG>. The RTA session in the table could contain all the information listed in <FIG>. In order to make the RTA session table easier to describe herein, the table is depicted by way of example and not limitation as only containing the part of the RTA session information listed in <FIG>. The RTA session table at STA <NUM> contains five RTA sessions. Each row in the table represents an RTA session.

The columns are Session Number (#), the Transmit and Receive stations (Tx and Rx), Session Start Time, Session End Time, Time Allocation (Time Alloc. mS), RU Allocation (RU Alloc. ), SS Allocation (SS Alloc. ), Period Time (Per. Time mS), Priority (Pri. ) and Session Status (Sess Stat.

The first row represents RTA Session Number (<NUM>), which transmits RTA traffic from STA <NUM> to STA <NUM>. RTA session <NUM> starts at <NUM> (Session Start Time) and ends at <NUM> (Session End Time). Every time the RTA session generates traffic, it has <NUM> channel time (Time Allocation) to transmit. The RU and SS allocations are all random. The periodic Time of RTA session <NUM> is <NUM>, which means RTA session <NUM> generates RTA traffic by demand. Since the priority of RTA session <NUM> is <NUM>, which is higher than other sessions, its traffic has higher priority to transmit than the traffic of other sessions. When the session status is active, RTA session <NUM> is able to generate traffic.

The second row represents RTA session <NUM>, which transmits RTA traffic from STA <NUM> to STA <NUM>. RTA session <NUM> starts at <NUM> and ends at <NUM>. Every time the RTA session generates traffic, it has <NUM> channel time to transmit. The RU and SS allocations are all random. The periodic time of RTA session <NUM> is <NUM>, which means RTA session <NUM> generates RTA traffic every <NUM>. The priority of RTA session <NUM> is <NUM>, which is lower than RTA session <NUM>. When RTA session <NUM> and <NUM> generates traffic simultaneously, RTA session <NUM> has a right to transmit its traffic first. When the session status is active, RTA session <NUM> is able to generate traffic. The remainder of the rows in the table represent other RTA sessions.

This section provides the details of how a STA manages the RTA sessions. In order to manage the RTA sessions, the STA is able to initiate an RTA session, update the RTA session, and finish the RTA session. Before the STA transmits RTA traffic, it creates an RTA session with RTA session information. The RTA session information is recorded in the RTA session table. The STA is able to manage the RTA sessions using this RTA session table. In order to simplify the description all the examples use the network topology as shown in <FIG>, although of course the present disclosure is configured to operate under any realistic topology.

As described in Section <NUM>. <NUM>, an RTA session uses the prior negotiation to establish the RTA traffic communication between STAs. During this procedure, a management frame exchange is performed to share the RTA session information between the STAs.

<FIG> illustrates an example embodiment <NUM> depicting how STAs, herein exemplified as STAG <NUM> and STA2 <NUM>, exchange management frames at the MAC layer to initiate an RTA session. The management frames that are used to initiate an RTA session are shown in <FIG> and <FIG>.

In <FIG> the procedure is depicted in which STAG checks resource availability on its side <NUM> and initializes <NUM> an RTA session from the perspective of the MAC layer. As shown in the figure, STA <NUM> initiates an RTA session with STA <NUM> and sends an RTA session initiation request frame (RTAInit. REQ) <NUM> containing the RTA session identifying information and requirement information to STA <NUM>. STA <NUM> receives the RTA session initiation request frame and checks <NUM> resource availability according to the requirement information in the received frame. If the resource is available, STA <NUM> sends <NUM> an RTA session initiation reply frame (RTAInit. REP) containing the RTA session transmission information back to STA <NUM>. If the resource is unavailable, the RTA session initiation reply frame would indicate the failure of the initiation procedure. STA <NUM> receives the RTA session initiation reply frame and sends <NUM> an RTA session initiation ACK frame (RTAInit. ACK) containing the RTA session status information to STA2. The RTA session finishes exchanging information between two STAs. Both STAs collect 266a, 266b the complete RTA session information and add this RTA session information in its RTA session table.

<FIG> illustrates an example embodiment <NUM> of the content of an RTA session initiation request frame. A Frame Control field indicates the type of frame. A Duration field contains NAV information used for CSMA / CA channel access. An RA field contains an address of the recipient of the frame. A TA field contains an address of the STA that transmits the frame. An Action field indicates the type of management frame, and specifically indicates that the management frame is an RTA session initiation request frame. An Initiation Request Information field follows the Action field when the Action field indicates that the frame is RTA session initiation request frame, and contains the fields as follows. (a) An RTA Session ID which provides identifying information of the RTA session. The content of this field is shown in <FIG>. (b) A Resource Requirement field indicates the information requirement of the RTA session as described in Section <NUM>. The subfields within of the Resource Requirement are as follows. A Bandwidth Requirement field indicates the amount of RTA traffic to be transmitted. A Delay Requirement field indicates the amount of transmission delay of the RTA packets. A Jitter Requirement field indicates the maximum difference in the RTA packet delay during each periodical transmission time. A Periodic time subfield indicates the duration of time that RTA session generates RTA traffic once (periodicity). A Priority field indicates the priority of the RTA traffic. A Session Start Time field and Session End Time field indicates a start time and end time of the RTA session, respectively.

<FIG> illustrates an example embodiment <NUM> of RTA session initiation reply frame contents with the following fields. A Frame Control field indicates the type of the frame. A Duration field contains NAV information used for CSMA / CA channel access. An RA field contains an address for the recipient of the frame. A TA field contains the address of the STA that transmitted the frame. An Action field indicates the type of management frame, and in this case indicates that the management frame is an RTA session initiation reply frame. An Initiation Response Information field follows the Action field when the Action field indicates that the frame is an RTA session initiation reply frame, and contains the following fields. (a) An RTA Session ID provides for identifying the information of the RTA session. The content of this field is shown in <FIG>. (b) An Initiation Result field is a one bit indication to show whether the initiation is granted or not. When this field is set to a first state (e.g., "<NUM>"), then the initiation is granted by the other STA; otherwise if this field is set to a second state (e.g., "<NUM>") then the request was not granted. A Transmission Information field provides transmission information of RTA sessions as described in Section <NUM>. A Time Allocation field shows the channel time that is distributed to the RTA session for transmission. An RU Allocation field shows the resource unit (RU) of the channel that is distributed to the RTA session for transmission. An SS Allocation field indicates the spatial stream allocation for the RTA session traffic transmission. A Status Information field provides status information of the RTA session as described in Section <NUM>. A Session Status field indicates the status of an RTA session. A Comment field indicates more details of the RTA session status. This information can be used to report the initiation result and its details.

<FIG> illustrates an example embodiment <NUM> of an RTA session initiation ACK frame. A Frame Control field indicates the type of frame. A Duration field contains NAV information used for CSMA / CA channel access. An RA field contains an address of the recipient of the frame. A TA field contains the address of the STA that transmits the frame. An Action field indicates the type of management frame, and in this case indicates that the management frame is an RTA session initiation ACK frame. An Initiation ACK Information field follows the Action field when the Action field indicates that the frame is RTA session initiation ACK frame. It contains the fields as follows. (a) An RTA Session ID for identifying information of the RTA session. The content of this field is shown in <FIG>. (b) A Status Information field provides the status information of the RTA session as described in Section <NUM>. , and includes the following fields. A Session Status field indicates the status of the RTA session. A Comment field indicates more details of the RTA session status.

Table <NUM> shows an example of the RTA session table at STA <NUM> after it initiates a new RTA session with STA <NUM>. The RTA session table before the initiation procedure is shown in Table <NUM>. Here, a new RTA session <NUM> is inserted into the RTA session table. The session ID is linked to the RTA session identifying information. In the new RTA session, the time, RU and SS resources are allocated and fixed by the procedure. When RTA session <NUM> generates RTA traffic every <NUM> to transmit, it has <NUM> time (time domain) to transmit RTA packets using RU <NUM> (frequency domain) and SS <NUM> (spatial domain) of the channel resources.

After the RTA session is initiated by the STAs, in certain cases the RTA session information will need to be updated between the STAs when the RTA session information at one STA side changes.

<FIG> illustrates an example embodiment <NUM> of how STAs exchange the management frames at the MAC layer to update an RTA session. The management frames that are used to update an RTA session are shown in <FIG>, and <FIG>.

In <FIG> the procedure of updating an RTA session from the perspective of the MAC layer at STAG <NUM> and STA2 <NUM>. STA <NUM> first checks <NUM> resource availability on its side. Then, it sends an RTA session update request frame (RTAUpdate. REQ) <NUM> containing the update information names and the update information values to STA <NUM>. When STA <NUM> receives the RTA session update request frame, it checks <NUM> the resource availability on its side. Then STA <NUM> sends an RTA session update reply frame (RTAUpdate. REP) <NUM> to STA <NUM>. The information updated by STA <NUM> will be carried by the RTA session update reply frame. STA <NUM> receives the RTA session update reply frame and sends an RTA session update ACK frame (RTAUpdate. ACK) <NUM> to STA2. The RTA session finishes exchanging information between two STAs. Both STAs acknowledge the change of the RTA session information and update 346a, 346b the RTA session in its RTA session table.

<FIG> illustrates an example embodiment <NUM> of an RTA session update request frame. A Frame Control field indicates frame type. A Duration field contains NAV information used for CSMA / CA channel access. An RA field contains an address for the recipient of the frame. A TA field contains the address of the STA that transmitted the frame. An Action field indicates the type of management frame, and in this case indicates that the management frame is an RTA session update request frame. An Update Request Information field follows the Action field when the Action field indicates that the frame is an RTA session update request frame, and contains the following fields. (a) An RTA Session ID provides identifying information of the RTA session. The content of this field is shown in <FIG>. A Number of Update Information field indicates the number (amount) of update information carried by this frame. An Update Info Name field indicates the name of the update information. An Update Info Value gives the value of the update information.

<FIG> illustrates an example embodiment <NUM> of an RTA session update reply frame. A Frame Control field indicates the frame type. A Duration field contains NAV information used for CSMA / CA channel access. An RA field contains an address for the recipient of the frame. A TA field contains the address of the STA that transmitted the frame. An Action field indicates the type of management frame, and in this case indicates that the management frame is an RTA session update reply frame. An Update Reply Information field follows the Action field when the Action field indicates that the frame is RTA session update reply frame, and contains the fields as follows. (a) An RTA Session ID provides identifying information of the RTA session; the content of this field is shown in <FIG>. A Number of Update Information field provides the number of update information carried by this frame. An Update Info Name provides the name of the update information. An Update Information Value field provides a value of the update information.

<FIG> illustrates an example embodiment <NUM> of an RTA session update ACK frame. A Frame Control field indicates frame type. A Duration field contains NAV information used for CSMA / CA channel access. An RA field contains an address for the recipient of the frame. A TA field contains the address of the STA that transmitted the frame. An Action field indicates the type of management frame, and in this case indicates that the management frame is an RTA session update ACK frame. An RTA Session ID field follows the Action field when the Action field indicates that the frame is an RTA session update ACK frame, the content of this field was shown in <FIG>.

Table <NUM> shows an example of the RTA session table at STA <NUM> after it updates RTA session <NUM> with STA <NUM>. The RTA session table before the update procedure is shown in Table <NUM>. Here, STA <NUM> sends an RTA session update request frame to reduce the periodic time from <NUM> to <NUM> in RTA session <NUM>. When STA <NUM> receives the frame, it checks the resources on its side. Then, STA <NUM> finds that the resources are unavailable to support the update of the session. STA <NUM> then changes the session status to error and puts the reason of error as a comment. When STA <NUM> sends the RTA session update reply frame to STA <NUM>, it puts the new session status and the comment in the frame. It informs STA <NUM> that the session status is changed to error and the reason of the error status is carried by the Comment field. STA <NUM> receives the RTA session update reply frame and updates the RTA session table as shown in Table <NUM>. It should be noted that the Comment field is not shown in the table but it can be part of the table.

A STA is able to finish an RTA session at any time using the RTA session finish procedure. The figure described below provides an example to show how STAs exchange the management frames at the MAC layer to finish an RTA session. The management frames that are used to finish an RTA session are shown in <FIG>.

<FIG> illustrates an example embodiment <NUM> of finishing an RTA session from the perspective of the MAC layer for STA0 <NUM> and STA2 <NUM>. When STA <NUM> plans to finish an RTA session, it sends an RTA session finish request frame (RTAFinish. REQ) <NUM> containing RTA session identifying information to STA <NUM>. When STA <NUM> receives the RTA session finish request frame, it finds the RTA session and removes it <NUM> from its RTA session table. Then, STA <NUM> sends an RTA session finish ACK frame (RTAFinish. ACK) <NUM> to STA <NUM>. Both of the RTA session finish request frame and the RTA session finish ACK frame contains the RTA session identifying information so that the neighboring STAs can be informed immediately. The RTA session can also be finished at the Session End Time. When the RTA session is finished, it is removed <NUM> from the RTA session table.

<FIG> illustrates an example embodiment <NUM> of an RTA session finish request frame. A Frame Control field indicates frame type. A Duration field contains NAV information used for CSMA / CA channel access. An RA field contains an address of the recipient of the frame. A TA field contains the address of the STA that transmitted the frame. An Action field indicates the type of management frame, and in this case indicates that the management frame is an RTA session finish request frame. An RTA Session ID field (shown in <FIG>) follows the Action field when the Action field indicates that the frame is RTA session finish request frame.

<FIG> illustrates an example embodiment <NUM> of an RTA session finish ACK frame. A Frame Control field indicates the type of frame. A Duration field contains NAV information used for CSMA / CA channel access. An RA field contains an address for the recipient of the frame. A TA field contains the address of the STA that transmitted the frame. An Action field indicates the type of management frame, and in this case indicates that the management frame is an RTA session finish ACK frame. An RTA Session ID field (shown in <FIG>) follows the Action field when the Action field indicates that the frame is RTA session finish ACK frame.

Table <NUM> shows an example of the RTA session table at STA <NUM> after it finishes RTA session <NUM> with STA <NUM>. The RTA session table before the update procedure is shown in Table <NUM>. Here, STA <NUM> sends an RTA session finish request frame to finish RTA session <NUM>. When STA <NUM> receives the frame, it finds the RTA session <NUM> in its RTA session table and removes it. After that, STA <NUM> sends the RTA session finish ACK frame to STA <NUM>. STA <NUM> receives the RTA session finish ACK frame and removes RTA session <NUM> from the RTA session table as shown in Table <NUM>.

<FIG> illustrates an example embodiment <NUM> of announcing an RTA session between STA5 <NUM> and STAG <NUM>. In this way a STA is able to communicate to its neighboring STAs that an RTA session has been created at its side. The figure gives an example to show how STAs exchange the management frames at the MAC layer to announce an RTA session to its neighboring STAs, with the management frame used to announce an RTA session being described in <FIG>.

In <FIG> STA <NUM> creates an RTA session on its side, it sends an RTA session announcement frame (RTA. ANN) <NUM> containing RTA session information to STA <NUM>. When STA <NUM> receives the RTA session announcement frame, it adds <NUM> the RTA session in the announcement frame into its RTA session table. It should be noted that the RTA session announcement frame can be broadcast.

<FIG> illustrates an example embodiment <NUM> of an RTA session announcement frame. A Frame Control field indicates the type of frame. A Duration field contains NAV information used for CSMA / CA channel access. An RA field contains an address for the recipient of the frame. A TA field contains the address of the STA that transmitted the frame. An Action field indicates the type of management frame, and in this case indicates that the management frame is RTA session announcement frame. An RTA Session Information field (shown in <FIG>) follows the Action field when the Action field indicates that the frame is an RTA session announcement frame.

Table <NUM> shows an example of the RTA session table at STA <NUM> after it receives RTA session announcement frames from STA <NUM>. The RTA session table before the update procedure is shown in Table <NUM>. According to the RTA session announcement frames, STA <NUM> knows that STA <NUM> schedules RTA sessions <NUM> and <NUM> on its side. STA <NUM> adds RTA session <NUM> and <NUM> into the RTA session table as shown in Table <NUM>.

When an RTA session generates traffic periodically, a STA is able to schedule the channel resource allocation for the traffic transmission of the RTA session. Every periodic time (interval), the active RTA session creates an RTA scheduled period (RTA-SP) to allocate the scheduled channel time for the RTA traffic transmission. During each RTA-SP, the amount of RTA traffic that needs to be transmitted is known by the STA (e.g., the amount of RTA traffic is constant).

The disclosed technology allows a STA to schedule RTA-SPs based on the information in its RTA session table at the MAC layer. Then the STA stores the RTA-SPs in an RTA channel scheduling table. The STA executes the RTA-SPs by following the list in the RTA channel scheduling table. Each RTA-SP is responsible for transmitting the RTA traffic or RTA packets of a certain RTA session. The method of identifying RTA traffic or RTA packet at the MAC layer of the STA is explained at Section <NUM>.

Due to the lifetime of the RTA packet as explained in Section <NUM>. <NUM>, when RTA-SP is used to transmit RTA packets, the duration of RTA-SP should not be any longer than the lifetime of the RTA packet so as to ensure the validation of the packet when it is delivered.

<FIG> illustrates an example embodiment <NUM> of a resource block for RTA traffic transmission in an RTA scheduled period. During RTA-SP, the RTA traffic can be transmitted using the allocated channel resource at a specific channel frequency and / or space. The allocated time, frequency, and space of the channel resource generates a separate resource block for the RTA traffic transmission in an RTA-SP. Due to the separate resource block used in the RTA-SP, the channel scheduling scheme is able to schedule the multi-user transmission, such as MIMO, OFDMA, and so forth.

When a STA schedules RTA-SPs for RTA sessions in its RTA session table, it creates an RTA channel scheduling table to list all the RTA-SPs that are scheduled for the future. One example of the RTA channel scheduling table is shown in Table <NUM>.

Table <NUM> shows an example of RTA channel scheduling table of STA <NUM> at time <NUM>. The RTA-SPs in the table are scheduled based on the RTA session table as shown in Table <NUM>. Each row in the table represents an RTA-SP which is scheduled by the STA. The content of each column is explained as follows. RTA-SP Number represents the order number of RTA-SP. The RTA-SP with a larger order number is scheduled later than the RTA-SP with a smaller order number. A Session ID indicates which RTA session scheduled the RTA-SP. The Session ID in the RTA channel scheduling table can be pointed to (directed to) the Session ID in the RTA session table. For example, RTA-SP <NUM> with Session ID <NUM> in Table <NUM> indicates that the RTA-SP is scheduled by RTA session <NUM> in Table <NUM>. For the purpose of simplifying the description, RTA session <NUM> is called the RTA session of RTA-SP <NUM>. The period start time and the period end time represent the start time and the end time of the RTA-SP. The period time of RTA-SP is equal to the Periodic Time of its RTA session in the RTA session table. Table <NUM> lists the first RTA-SPs scheduled by all the RTA sessions in Table <NUM>. The Period Start Time of RTA-SP in this example is considered to be the same as the Session Start Time of its RTA session.

The RU Allocation and SS Allocation fields show the allocated channel resource of frequency and space, respectively, and they can be fixed or random. When RU Allocation or SS Allocation is random, the RTA packet can be transmitted using random channel resource of either frequency or space according to the channel condition during RTA-SP. When RU Allocation or SS Allocation is fixed, then the RTA packet can only be transmitted using allocated channel resources of frequency or space during the RTA-SP. For example, RU1 and RU2 are denoted as channel resource of RU Allocation. SS1 and SS2 are denoted as channel resources of SS Allocation. RTA-SP <NUM> can only use RU1 and SS1 for RTA packet transmission during its period time. RTA-SP <NUM> can only use RU2 and SS2 for RTA packet transmission during its period time.

Priority is the priority of the RTA-SP. The RTA-SP has the same priority of its RTA session. The RTA-SP with higher priority has the higher priority to use the allocated resource block for transmission. Activity represents the actions STA will take during the RTA-SP. This can be determined by checking the Tx Node and Rx Node of the RTA session in the RTA session table. If the STA is the Tx Node, then it transmits RTA packets during the RTA-SP. If the STA is the Rx Node, then it receives RTA packets during the RTA-SP. If the STA is neither the Tx Node nor the Rx Node, it only listens to the channel during RTA-SP.

The RTA-SPs in the RTA channel scheduling table are sorted using the period start time as a primary sort key, and the priority as a secondary sort key. According to the RTA channel scheduling table, the STA is able to execute the RTA-SPs line by line in the RTA channel scheduling table. Every time the STA finishes one RTA-SP, it will remove the finished RTA-SP from the table, schedule a new RTA-SP based on the RTA session information of the finished RTA-SP, and insert the new RTA-SP to the table.

<FIG> illustrates an example embodiment <NUM> of a STA scheduling RTA-SPs and adding it into the RTA channel scheduling table. When the STA schedules <NUM> an RTA-SP for RTA session, it first obtains <NUM> RTA session information from the RTA session table. A check <NUM> is performed if the RTA session status is active. If the RTA session is not active, then RTA-SP is not scheduled and the process ends <NUM>. Otherwise, if the RTA session is active, the STA creates <NUM> an RTA-SP with allocated resource block for that RTA session. The STA then adds (inserts) <NUM> the RTA-SP into the RTA channel scheduling table. The RTA-SPs in the RTA channel scheduling table will be sorted <NUM> using the period start time as primary sort key, and the priority as secondary sort key, before ending <NUM> the process.

Tables <NUM> through Table <NUM> provide an example to show how STA <NUM> schedules RTA-SPs and manages them using the RTA channel scheduling table. Table <NUM> shows the RTA channel scheduling table of STA <NUM> at time <NUM> based on the RTA session information in Table <NUM>. As shown in Table <NUM>, at time <NUM>, STA <NUM> finishes the RTA traffic transmission in RTA-SP <NUM> and removes it from the RTA channel scheduling table. Meanwhile, STA <NUM> needs to schedule a new RTA-SP based on the information of RTA session information of RTA-SP <NUM>, such as RTA session <NUM>.

According to <FIG>, STA <NUM> checks the information of RTA session <NUM> in its RTA session table. The status of RTA session <NUM> is active. STA <NUM> schedules a new RTA-SP for RTA session <NUM>, which is RTA-SP <NUM> shown in Table <NUM>. The Period Start Time of RTA-SP <NUM> could be the Periodic Time of RTA session <NUM> plus the Period Start Time of RTA-SP <NUM>. The other information of RTA-SP <NUM> is the same as that of RTA-SP <NUM> since there is no update in RTA session <NUM>. STA <NUM> inserts the RTA-SP <NUM> into the RTA channel scheduling table. Since RTA-SP has the latest Period Start Time, it is listed at the last line of the table.

Table <NUM> lists the RTA-SPs in the RTA channel scheduling table of STA <NUM> at time <NUM>. STA <NUM> uses multi-user transmission to transmit RTA traffic of RTA sessions <NUM>, <NUM>, and <NUM>. STA <NUM> finishes the RTA transmission of RTA sessions <NUM> first and ends RTA-SP <NUM>. It removes RTA-SP <NUM> from the table and inserts a new RTA-SP <NUM> for RTA session <NUM>. This process is the same as explained in Table <NUM>.

Table <NUM> lists the RTA-SPs in the RTA channel scheduling table of STA <NUM> at time <NUM>. STA <NUM> ends RTA-SPs <NUM> and <NUM>. STA <NUM> inserts two new RTA-SPs <NUM> and <NUM> into the table. RTA-SP <NUM> is for RTA session <NUM> and RTA-SP <NUM> is for RTA session <NUM>. Since the Period Start Time of RTA-SPs <NUM>, <NUM> and <NUM> is the same but RTA-SP <NUM> has higher priority, RTA-SP <NUM> lists above RTA-SP <NUM> and <NUM>.

Table <NUM> lists the RTA-SPs in the RTA channel scheduling table of STA <NUM> at time <NUM>. STA <NUM> ends RTA-SPs <NUM> and <NUM> and inserts two new RTA-SPs <NUM> and <NUM> into the table. RTA-SP <NUM> is for RTA session <NUM> and RTA-SP <NUM> is for RTA session <NUM>. Since the Period Start Time of RTA-SPs <NUM> and <NUM> is earlier than RTA-SPs <NUM>, <NUM>, <NUM>, RTA-SPs <NUM> and <NUM> lists above RTA-SPs <NUM>, <NUM>, <NUM>.

This section explains how a STA starts and ends an RTA-SP in the RTA channel scheduling table.

<FIG> illustrates an example embodiment <NUM> of a STA starting an RTA-SP listed in its RTA channel scheduling table. When a STA plans to start <NUM> an RTA-SP, it first searches <NUM> (lookup) the RTA channel scheduling table. A check is made <NUM> if there is an RTA-SP in the immediate future which is a fixed period of time determined by the STA. If there is no RTA-SP scheduled in this near future, then execution returns to block <NUM> and it will keep searching and looking up in the RTA channel scheduling table. Otherwise, if there is an RTA-SP scheduled in the near future then the STA needs to make a decision whether to gain the channel access before RTA-SP starts so that the channel can be occupied in advance. So a check is made <NUM> to determine if it should occupy the channel in advance. If it decides to occupy the channel in advance it will try to occupy the channel as seen at block <NUM> before the RTA-SP starts to occupy the channel in advance by reserving the channel resource block for RTA-SP to allow the RTA traffic transmission to start at the beginning of the RTA-SP without channel contention. The method of channel occupancy in advance is explained in Section <NUM>. Then the STA starts <NUM> the RTA-SP at the Period Start Time listed in the RTA channel scheduling table. Otherwise, if the STA decides not to occupy the channel, then the STA does not reserve the channel and execution directly reaches block <NUM> to start RTA-SP. After starting RTA-SP the process ends <NUM>.

<FIG> illustrates an example embodiment <NUM> of a STA ending an RTA-SP. The process starts <NUM> and the STA stays <NUM> in an RTA-SP and looks up (searches) <NUM> information of the RTA-SP in the RTA channel scheduling table. A check is made <NUM> if the current time has reached the Period End Time of the RTA-SP shown in the RTA channel scheduling table. If the end is reached then execution moves on to block <NUM> to end the RTA-SP immediately. Otherwise, if the end time has not been reached then the STA may remain in (stay in) RTA-SP and be tracking RTA traffic. A check is made at block <NUM> to determine if the STA is either the transmitter or the receiver in the RTA-SP. If the STA is neither transmitter nor receiver, then it is a listener and execution returns back to block <NUM> to check period end time. Otherwise, since the STA is either a transmitter or receiver it knows there are more packet transmissions, so it checks <NUM> whether there are more RTA packets to transmit or receive during the RTA-SP. If there are more RTA packet transmissions, it remains in RTA-SP and execution moves back to block <NUM>. Otherwise, with no more packets transmissions it ends the RTA-SP <NUM>, then based on RTA session information it schedules <NUM> an RTA-SP for the RTA session before the process ends <NUM>.

<FIG> illustrates an example embodiment <NUM> of a STA executing the RTA-SPs listed in the RTA scheduling table, and showing both channel scheduling <NUM> and packet transmission <NUM>, with time markers along the base of each, exemplified here from <NUM> to <NUM>. The channel scheduling in the figure follows the RTA channel scheduling table of STA <NUM> as shown in Table <NUM>. CBAP in the channel scheduling represents the contention based access period. That is, during CBAP, the STA access the channel following the CSMA / CA scheme. The packet transmission in the figure represents the packet transmission over the channel following the channel scheduling.

During time <NUM> to <NUM>, the channel scheduling is CBAP, non-RTA packets are allowed to transmit over the channel. As seen in block <NUM> of <FIG>, STA <NUM> starts the RTA-SP <NUM> for receiving RTA packets generated by RTA session <NUM> at time <NUM>. The RTA packet can be identified as explained in <FIG>. RTA-SP <NUM> is scheduled to end at time <NUM>. However, the RTA packets of RTA session <NUM> finish transmitting before time <NUM>. STA <NUM> ends the RTA-SP <NUM> when the RTA packet transmission finishes as explained in blocks <NUM>, <NUM>, <NUM> in <FIG>. The remaining time for RTA-SP <NUM> can be used as CBAP. There is no RTA-SP scheduled during time <NUM> to <NUM>. That period of time is CBAP and used for non-RTA packet transmission.

Three RTA-SPs (i.e., RTA-SPs <NUM>, <NUM>, <NUM>) are scheduled to start at time <NUM>. Especially, RTA-SP <NUM> has higher priority and is required to occupy the channel in advance. As seen in blocks <NUM>, <NUM>, <NUM> in <FIG>, STA <NUM> gains the channel access before time <NUM> and transmits the RTA packet generated by RTA session <NUM> at time <NUM> without channel contention. The RTA packets generated by different RTA sessions can be identified as explained in <FIG>. The RTA packets generated by RTA sessions <NUM> and <NUM> may be transmitted after finishing the RTA packet transmission of RTA sessions <NUM> due to the priority.

RTA-SPs <NUM>, <NUM>, <NUM> end earlier than time <NUM> because STA <NUM> finishes the RTA packet transmission, with the remainder of the time of the RTA-SPs used for non-RTA packet transmission.

RTA-SPs <NUM> and <NUM> start at time <NUM>. As shown in Table <NUM>, those two RTA-SPs have allocated resource block for transmission, i.e., RU1 and RU2 in the figure. If there exists extra resource blocks, such as RU3, then STA <NUM> can use these for packet transmission. Since STA <NUM> is the listener, it ends RTA-SPs <NUM> and <NUM> at Period End Time <NUM> as seen in <FIG>.

As mentioned in Section <NUM>. <NUM>, the STA is able to gain the channel access in advance and reserve the channel for RTA-SP. This section provides one method of allowing a STA to gain channel access before the start of RTA-SP. The disclosed technology is able to use RTA-RTS / CTS / NTS exchange to allow a STA to occupy the channel in advance for packet transmissions in RTA-SP. RTA-RTS / CTS / NTS exchange occupies the channel by setting the NAV at STAs, which is similar to RTS / CTS exchange. Compared with regular RTS / CTS exchange, the RTA-RTS / CTS / NTS exchange has the following features. (a) When STA sends an RTA-RTS frame, it will either receive an RTA-CTS frame to indicate successful channel occupancy, or receive an RTA-NTS to indicate that the channel occupancy is rejected and some other transmission is scheduled in the near future. (b) The RTA-RTS / CTS / NTS frame carries the traffic information that will be transmitted using the channel occupied by the RTA-RTS / CTS exchange. The response of RTA-RTS frame depends on the priority of the traffic indicated in the RTA-RTS frame. (c) When channel occupancy is denied, it also denies the traffic transmission indicated in the RTA-RTS frame.

<FIG> illustrates an example embodiment <NUM> of an RTA-RTS frame having the following fields. A Frame Control field indicates frame type. A Duration field contains NAV information used for CSMA / CA channel access. An RA field contains an address for the recipient of the frame. A TA field contains the address of the STA that transmitted the frame. An RTA Traffic field is a one bit indication to show whether the packet transmission following the RTA-RTS / CTS exchange is RTA or not. When the bit is set to a first state (e.g., "<NUM>"), the packet transmission is RTA; otherwise it is non-RTA. An RTA Session ID field (shown in <FIG>) indicates the identifying information of the RTA session. A Priority field indicates the priority of RTA traffic that will be transmitted after the RTA-RTS / CTS exchange.

<FIG> illustrates an example embodiment <NUM> of a RTA-CTS frame having the following fields. A Frame Control field indicates the type of frame. A Duration field contains NAV information used for CSMA / CA channel access. An RA field contains an address for the recipient of the frame. An RTA Traffic field is a one bit indication to show whether the packet transmission following the RTA-RTS / CTS exchange is RTA or not. When the bit is set to a first state (e.g., "<NUM>"), then packet transmission is RTA; otherwise if set to a second state (e.g., "<NUM>"), it is considered non-RTA. An RTA Session ID field indicates the identifying information of the RTA session, as was shown in <FIG>. A Priority field indicates the priority of RTA traffic that will be transmitted after the RTA-RTS / CTS exchange.

<FIG> illustrates an example embodiment <NUM> of an RTA-NTS frame having the following fields. A Frame Control field indicates frame type. A Duration field contains NAV information used for CSMA / CA channel access. An RA-NAV field contains an address for the recipient of the frame who sent the RTS or RTA-RTS frame. The recipient should set the NAV according to the Duration field and Start Time of Channel Occupancy field. A Number of RA-notNAV field indicates the number of RA-notNAV fields in the frame. RA-notNAV field contains address of the recipient of the frame who should remove the NAV set by RTS frame or RTA-RTS frame. An RTA Traffic field provides a one bit indication of whether the packet transmission after the RTA-RTS / CTS exchange is RTA or not. When the bit is set to a first state (e.g., "<NUM>"), the packet transmission is RTA; otherwise it set to a second state (e.g., "<NUM>") it is considered non-RTA transmission. An RTA Session ID field indicates the identifying information of RTA session as was shown in <FIG>. A Priority field indicates the priority of RTA traffic that will be transmitted after the RTA-RTS / CTS exchange. A Start Time of Channel Occupancy field indicates the start time that the channel will be occupied by the STA who sends this RTS-NTS.

<FIG> illustrates an example embodiment <NUM> for NAV setting when receiving an RTA-RTS / CTS frame. When the STA receives <NUM> an RTA-RTS/CTS frame, it checks <NUM> the RA field in the frame. If the STA address is not the same as in the RA field then at block <NUM> the NAV is set, and the process ends <NUM>. Otherwise, if the STA address is the same as in the RA field, then from block <NUM> execution moves to end <NUM> as it does not need to set the NAV. The duration of the NAV is the time in the Duration field of the frame and the NAV starts when it receives the frame.

<FIG> illustrates an example embodiment <NUM> of how the NAV at the STA is set when receiving an RTA-NTS frame. When a STA receives RTA-NTS frame <NUM>, it checks <NUM> the RA-notNAV field in the frame. If the STA address is the same as in the RA-notNAV field, it removes <NUM> the NAV and the process ends <NUM>. Otherwise, execution reaches block <NUM> and it sets the NAV according to the Duration field and Start Time of Channel Occupancy field in the frame and then reaches ends <NUM>. When setting or removing the NAV, the start time and the duration of the NAV is the same. The duration of the NAV is the time in the Duration field of the frame and the NAV starts at the Start Time of Channel Occupancy.

This section explains the details of how the STA is able to occupy the channel using an RTA-RTS / CTS / NTS exchange. The channel occupancy can be used for: (a) occupying the channel in advance for RTA-SP; and (b) occupying the channel for RTA and non-RTA packet transmissions.

<FIG> illustrates an example embodiment <NUM> of a STA sending RTA-RTS frame to request channel occupancy. When the STA determines <NUM> to send an RTA-RTS frame to request channel occupancy, it first performs <NUM> a clear channel assessment before gaining channel access for sending the RTA-RTS frame. A check at block <NUM> determines if the channel is available for sending an RTA-RTS. If the channel is not available, then the process ends <NUM>. Otherwise, if the channel is available, then a check is made at block <NUM> as to whether the channel occupancy request is for RTA traffic or non-RTA traffic.

If the request is for occupying the channel for sending RTA traffic, the STA sets <NUM> the Indication of RTA Traffic field to a first state (e.g., "<NUM>") to indicate that the channel is occupied for RTA traffic in the RTA-RTS frame, adds the RTA session ID, and sets <NUM> the priority of the RTA traffic in the Priority field.

Otherwise, if at block <NUM> the channel occupancy is only requested for transmitting non-RTA traffic, then in block <NUM> the STA sets the indication of RTA Traffic field to a second state (e.g., "<NUM>") in the RTA-RTS frame to indicate the traffic is non-RTA. Then in either occupancy case execution reaches block <NUM> where the STA sets the channel occupancy time in the Duration field of the frame and transmits <NUM> the RTA-RTS frame.

A check <NUM> determines if the STA receives the RTA-CTS frame after sending RTA-RTS frame. If it received the RTA-CTS, then at block <NUM> channel occupancy succeeds with the STA able to use the occupied channel for packet transmission, and the process ends <NUM>. Otherwise, if the RTA-CTS is not received, then occupancy is directly or indirectly rejected, so a check is made at block <NUM> for RTA-NTS. If the STA receives RTA-NTS frame as a direct rejection, then at block <NUM> the STA sets NAV according to the information in RTA-NTS frame and reaches block <NUM> to reject channel occupancy and the process ends <NUM>. Otherwise, if the check at block <NUM> determines that RTA-NTS is not received, then execution reaches block <NUM> with occupancy rejected and the process ends <NUM>. Thus, even if the STA does not receive anything after sending RTA-RTS frame, it also indicates that channel occupancy is rejected. The STA is required to re-contend for the channel for the purpose of channel occupancy.

<FIG> illustrates an example embodiment <NUM> of a STA replying to a channel occupancy request in response to an RTA-RTS frame. When the STA receives <NUM> an RTA-RTS frame for channel occupancy request, it first checks <NUM> whether it is the intended receiver. If the STA is not the intended receiver, it sets <NUM> the NAV as explained in <FIG> and continues monitoring the channel, wherein the process is seen ending <NUM>.

Otherwise, if the STA is the intended receiver then execution moves from block <NUM> to block <NUM> wherein the STA extracts traffic information from the RTA-RTS frame and thus the STA recognizes the type of traffic (i.e., RTA or non-RTA). If the traffic is RTA, STA can also obtain the RTA session identifying information and the priority of the traffic.

Then, the STA performs a lookup (search) <NUM> of its RTA channel scheduling table and checks <NUM> whether the channel occupancy time requested by the RTA-RTS frame would conflict with the RTA-SPs scheduled in the table. If there is no conflict, that is to say that the channel occupancy time does not overlap with the RTA-SPs in the table or the channel occupancy is for one RTA-SP in the table, then block <NUM> is reached with the STA sending an RTA-CTS frame back to the requesting station to grant channel occupancy, after which the process ends <NUM>.

Otherwise, if it is found at block <NUM> that the channel occupancy requested by the RTA-RTS frame conflicts the RTA-SPs scheduled in the table, then a check <NUM> is performed on the traffic type indicated in the RTA-RTS frame. If the traffic type is not RTA traffic, the execution moves to block <NUM> with the STA sending an RTA-NTS to reject the channel occupancy request and indicate that there is RTA traffic transmission in the near future, before the process ends <NUM>.

If, however, the traffic type determined at check <NUM> is RTA, then at block <NUM> the STA performs a check comparing the priority of the RTA traffic indicated in the RTA-RTS frame with the priority of the RTA-SPs which have conflicts with the channel occupancy time requested by the RTA-RTS frame. If the RTA traffic indicated in the RTA-RTS frame has higher priority, then the STA allows the RTA-RTS to occupy the channel and execution moves to block <NUM> which sends an RTA-CTS frame back to grant the request. Otherwise, if the request is of lower priority, then execution moves to block <NUM> with the STA rejecting the channel occupancy request and sending an RTA-NTS frame.

<FIG> illustrate an example embodiment <NUM>, <NUM>, <NUM> explaining how RTA-RTS / CTS / NTS exchange is used for channel occupancy in advance for RTA-SPs. All the examples consider the scenario as shown in <FIG> when STA <NUM> occupies the channel in advance for RTA-SP <NUM>. Multiple options are provided to occupy the channel in advance.

In <FIG> is an example <NUM> is shown of how a STA uses RTA-RTS / CTS exchange to occupy the channel in advance for RTA-SP. The figure depicts the interaction between transmitter STAG <NUM>, receiver STA2 <NUM> and other STAs <NUM>. STA <NUM> generates <NUM> an RTA-RTS frame carrying traffic information to indicate the channel occupancy request for RTA-SP2 and sends it to STA <NUM>. STA <NUM> receives the RTA-RTS frame from STA <NUM>. It extracts the traffic information carried by the RTA-RTS frame and compares it with the RTA-SPs listed in its RTA channel scheduling table. STA <NUM> recognizes that the RTA-RTS frame is requesting channel occupancy for RTA-SP2 and sends <NUM> an RTA-CTS frame back to STA <NUM>, with the channel occupied <NUM> for the start of RTA-SP2. When STA <NUM> receives the RTA-CTS frame, the channel is occupied <NUM> successfully, and the RTA packet is <NUM> is sent, with an ACK <NUM> sent back from receiver STA2. The figure depicts time period <NUM> for RTA-SP2, RTA-SP3, and RTA-SP4.

Other STAs <NUM> are receiving these transmission and sets NAV <NUM> in response to RTA-RTS, and NAV <NUM> in response to RTA-CTS as was shown in <FIG>. Accordingly, STA <NUM> can transmit RTA packets generated by RTA session <NUM> at the beginning of RTA-SP <NUM> over the channel without contention issues.

In <FIG> is an example <NUM> of how a STA uses RTA-RTS / NTS exchange to occupy the channel in advance for RTA-SP. The figure depicts the interaction between transmitter STA1 <NUM>, receiver STAG <NUM>, RTA STAs <NUM>, <NUM>, <NUM><NUM> and other STAs <NUM>. In this example, the RTA-SP is able to occupy the channel in advance by rejecting the channel occupancy request from other STAs. As was shown in <FIG>, before RTA-SP <NUM> starts, the channel stays in CBAP for non-RTA traffic transmission.

In the example scenario of <FIG>, when the CBAP is close to its end, STA <NUM> sends <NUM> an RTA-RTS to STA <NUM> for with a channel occupancy request. According to the traffic information carried by the STA <NUM>, the traffic is non-RTA. As explained in <FIG>, all the STAs except STA <NUM> will set the NAV. However, the channel occupancy time, starting at <NUM>, is overlapped with the period time <NUM> of RTA-SPs <NUM>, <NUM>, <NUM>. So STA <NUM> must reject the channel occupancy request from STA <NUM> to protect the channel time for RTA-SPs <NUM>, <NUM>, <NUM>. It sends <NUM> an RTA-NTS frame to STA <NUM> as well as to STAs <NUM>, <NUM>, <NUM>, who are involved in RTA-SPs <NUM>, <NUM>, <NUM>. The Duration field of the RTA-NTS frame is set to the period time of RTA-SPs <NUM>, <NUM>, <NUM>. The Start Time of Channel Occupancy field of the RTA-NTS frame is set to the start time of RTA-SPs <NUM>, <NUM>, <NUM>. When STAs <NUM>, <NUM>, <NUM> receive the RTA-NTS frame, they change NAV <NUM> to a notNAV <NUM> that occupies the duration time of RTA-SPs <NUM>, <NUM>, <NUM>. STA <NUM> recognizes that the channel is occupied and sets NAV (RTS-NTS) <NUM> since the channel occupancy request was rejected. The other STAs also set NAV (RTA-RTS) <NUM>, then at time <NUM> also set <NUM> NAV (RTS-NTS) to reserve the channel time for RTA-SPs <NUM>, <NUM>, <NUM>.

The example in <FIG> shows operation of the channel occupancy request for non-RTA traffic that is rejected if the channel occupancy time is overlapped with the RTA-SPs. If the traffic information carried by the RTA-RTS frame in the example is RTA traffic instead of non-RTA traffic, it is possible that the channel occupancy request for RTA traffic also gets rejected. As was shown in <FIG>, if the priority of the RTA traffic indicated in the RTA-RTS frame is not higher than the priority of the RTA-SPs, the channel occupancy request will be rejected. In the example shown in this figure, if priority of the RTA traffic indicated in the RTA-RTS frame is not higher than <NUM> (the priority of RTA session <NUM>), the channel occupancy request will be rejected.

In <FIG> is another example <NUM> of channel occupancy for RTA-SP, showing interaction between transmitter STA0 <NUM>, receiver STA2 <NUM> and other STAs <NUM>. In this example, the channel occupancy is not launched by RTA-RTS frame as shown in <FIG> and <FIG>, but in the case of <FIG> it is possible that the receiver STA in the RTA-SP sends an RTA-CTS frame <NUM> to the transmitter STA for channel occupancy. This request is received prior to time <NUM> with the start of the RTA-SP2-<NUM><NUM>.

So in this example before RTA-SP <NUM><NUM> commences, STA <NUM> sends <NUM> an RTA-CTS frame to occupy the channel in advance. When the other STAs receive the RTA-CTS frame, they set the NAV <NUM> as was seen in <FIG>.

The decision of launching the channel occupancy in advance by RTA-RTS frame or RTA-CTS frame can be made by the time before the start of RTA-SP. For example, if the time before the start of RTA-SP is enough for RTA-RTS / CTS / NTS exchange, the channel occupancy is launched by the RTA-RTS frame as shown in <FIG> and <FIG>. Otherwise, the channel occupancy is launched by the RTA-CTS frame as shown in <FIG>. In this case we see STA <NUM> transmitting <NUM> RTA packet (RTA Session <NUM>), which is ACKnowledged <NUM> by STA <NUM>.

This section explains the details of how the STA is able to decide whether to receive the packets during RTA-SP using RTA-RTS / CTS / NTS exchange, especially the packets that are not scheduled to transmit during RTA-SP. The goal is to ensure the STA can occupy the channel during the RTA-SPs to transmit RTA packets. Toward that goal, the STA is configured to be able to reject packet reception during RTA-SP by rejecting the channel occupancy request from RTS or RTA-RTS frame.

When the transmitter STA transmits a packet, it may send a regular RTS frame or an RTA-RTS frame first for a channel occupancy request. When the receiver STA receives the RTS frame or RTA-RTS frame, it is able to decide whether to grant the request and receive the packet from the transmitter STA by sending a CTS frame or RTA-CTS frame, or to reject the request and not receive the packet from the transmitter STA by sending a RTA-NTS frame.

<FIG> illustrates an example embodiment <NUM> of the operation of a STA when it receives an RTS frame for packet reception. The process starts <NUM> and the STA receives <NUM> an RTS frame and determines <NUM> whether it is the intended receiver. If the STA is not the intended receiver, then at block <NUM> it sets the NAV and continues monitoring the channel, wherein the process ends <NUM>.

If, however, the STA is the intended receiver, then execution moves from check <NUM> to check <NUM> which determines whether the RTS frame is an RTA-RTS frame or a regular RTS frame. If the frame is RTA-RTS, then execution reaches block <NUM> with the STA generating a reply to the channel reservation as was described in <FIG>.

However, if it is determined at block <NUM> that the frame is a regular RTS, then check <NUM> determines whether the channel occupancy time requested by the RTS frame conflicts the duration time of any RTA-SP. If there is no conflict, then the STA sends <NUM> a CTS frame with full NAV to grant the channel occupancy request by RTS.

Otherwise, if a conflict is detected at block <NUM> then a decision at block <NUM> determines one of three options (A, B or C) that the STA can choose to protect RTA-SP.

The examples shown in previous <FIG> (explained in Section <NUM>. ) and in <FIG> below explain how STA uses RTA-RTS / CTS / NTS to ensure channel occupancy for the RTA traffic transmission during RTA-SPs by rejecting RTA and non-RTA packet receptions. Both of the examples consider the scenario as shown in <FIG> when STA <NUM> occupies the channel in advance for RTA-SP <NUM>.

<FIG> illustrates an example embodiment <NUM> of rejecting non-RTA packet reception by RTA-NTS when RTS / CTS is enabled. The figure depicts communication between transmitter STA1 <NUM>, receiver STAG <NUM>, RTA STA2-<NUM><NUM> and other STAs <NUM>. STA <NUM> transmits <NUM> a regular RTS frame to STA <NUM>. When STA <NUM> receives an RTS frame, since it has an impact on the RTA-SP, it sends an RTA-NTS frame <NUM> to reject the channel occupancy request and the packet reception. Meanwhile, STA2-<NUM>, associated with RTA-SP <NUM>, <NUM>, <NUM><NUM>, have set NAV (RTS) <NUM> in response to the RTS, have received the RTA-NTS frame <NUM> and remove the NAV, changing to notNAV (RTA-NTS) <NUM> for the portion that overlaps the duration time of RTA-SP <NUM>, <NUM>, <NUM>. During the time between the end of RTA-NTS frame and the start of RTA-SP <NUM>-<NUM>, STA <NUM> is able to use this period of time for packet transmission. The other stations <NUM> are seen setting NAV (RTS) <NUM> upon receiving RTS <NUM>, and NAV (RTA-NTS) <NUM> in response to the received RTA-NTS <NUM>.

<FIG> and <FIG> illustrate an example embodiment <NUM>, <NUM> explain how a STA uses regular RTS / CTS to ensure channel occupancy for the RTA traffic transmission during RTA-SPs by rejecting RTA and non-RTA packet receptions. Both of the examples consider the scenario as shown in <FIG> when STA <NUM> occupies the channel in advance for RTA-SP <NUM>.

In <FIG> interaction <NUM> is seen between transmitter STA1 <NUM>, receiver STA0 <NUM>, RTA STA2, <NUM>, <NUM><NUM> and other STAs <NUM>, in the scenario of allowing non-RTA packet reception before the start of RTA-SP <NUM>, <NUM>, <NUM><NUM> by sending a CTS frame with short NAV duration. This option is seen in block <NUM> of <FIG>. Referring again to <FIG>, STA1 sends RTS <NUM>, which is received by STA <NUM>, that sends a CTS frame <NUM> back with short NAV. The duration of the NAV in CTS frame ends before the start <NUM> of RTA-SP <NUM>, <NUM>, <NUM><NUM>. In response to the CTS, STA1 knows to use the duration of NAV set by the CTS frame for packet transmission, and it transmits packet <NUM> which is ACKnowledged <NUM> by STA <NUM>.

When STA <NUM>, <NUM>, <NUM> receives RTS <NUM> they set NAV (RTS) <NUM>, and after CTS frame <NUM> they set short NAV (CTS) <NUM> to adjust the NAV setting accordingly. At the beginning of time RTA-SP <NUM>, <NUM>, <NUM> these stations set notNAV (cue to CTS) <NUM>, for example, they reset the NAV to the Duration field of the CTS frame. The other STAs set the NAV as usual, with NAV (RTS) <NUM> in response to RTS and a short NAV (CTS) <NUM> in response to CTS <NUM>.

In <FIG> an example <NUM> is seen of interaction between transmitter STA1 <NUM>, receiver STAG <NUM>, RTA STA2-<NUM><NUM> and other STAs <NUM>, in which non-RTA packet reception is rejected by no response when RTS / CTS is enabled, that is of rejecting non-RTA packet reception by not responding to the RTS frame. This option is shown in block <NUM> of <FIG>. Returning to <FIG>, STA1 <NUM> sends <NUM> an RTS / RTA-RTS. After STA <NUM> receives RTS frame <NUM> from STA <NUM>, it notices that the channel occupancy time requested by the RTS frame overlaps the RTA-SPs <NUM>. STA <NUM> can simply reject the channel occupancy request by taking no action. STA <NUM>, <NUM>, <NUM>, having upcoming RTA-SP <NUM>, <NUM>, <NUM><NUM> starting at time <NUM>, and ending at <NUM>, can decide to not NAV <NUM> since they did not hear any response for the RTS frame. The other stations <NUM> set NAV (RTS) <NUM> in response to RTS <NUM>.

During the RTA-SP, there is at least one exception in which a STA may accept the channel occupancy request and receive the packet that is not scheduled by RTA-SP. As seen in blocks <NUM> and <NUM> of <FIG>, if the packet is an RTA packet with higher priority than the priority of the RTA-SP, the STA is able to receive the packet.

<FIG> illustrates an example embodiment <NUM> of accepting RTA packet reception when the RTA-SP is affected. The figure depicts interaction between transmitter STAG <NUM>, receiver STA2 <NUM>, and other STAs <NUM>. In this example RTA-SPs <NUM>, <NUM>, <NUM><NUM> is scheduled in the near future to start at <NUM> and end at <NUM>. The communication commences with STA <NUM> sending an RTA-RTS frame <NUM> to occupy the channel for transmitting RTA packet generated by RTA session <NUM>. As shown in Table <NUM>, the priority of RTA session <NUM> is <NUM> which is higher than the priority of RTA-SPs <NUM>, <NUM>, <NUM>. In response to this RTS, STA <NUM> sends an RTA-CTS frame <NUM> to grant channel occupancy and receive the RTA packet <NUM> transmitted from STA <NUM>, which it then ACKnowledges <NUM>. The other STAs <NUM> set NAV (RTA-RTS) <NUM> and then NAV (RTA-CTS) <NUM>.

The enhancements described in the presented technology can be readily implemented within various wireless communication circuits. It should also be appreciated that wireless communication circuits are preferably implemented to include one or more computer processor devices (e.g., CPU, microprocessor, microcontroller, computer enabled ASIC, etc.) and associated memory storing instructions (e.g., RAM, DRAM, NVRAM, FLASH, computer readable media, etc.) whereby programming (instructions) stored in the memory are executed on the processor to perform the steps of the various process methods described herein.

The computer and memory devices were not depicted in the diagrams for the sake of simplicity of illustration, as one of ordinary skill in the art recognizes the use of computer devices for carrying out steps involved with wireless packet communications. The presented technology is non-limiting with regard to memory and computer-readable media, insofar as these are non-transitory, and thus not constituting a transitory electronic signal.

Embodiments of the present technology may be described herein with reference to flowchart illustrations of methods and systems according to embodiments of the technology, and/or procedures, algorithms, steps, operations, formulae, or other computational depictions, which may also be implemented as computer program products. In this regard, each block or step of a flowchart, and combinations of blocks (and/or steps) in a flowchart, as well as any procedure, algorithm, step, operation, formula, or computational depiction can be implemented by various means, such as hardware, firmware, and/or software including one or more computer program instructions embodied in computer-readable program code. As will be appreciated, any such computer program instructions may be executed by one or more computer processors, including without limitation a general purpose computer or special purpose computer, or other programmable processing apparatus to produce a machine, such that the computer program instructions which execute on the computer processor(s) or other programmable processing apparatus create means for implementing the function(s) specified.

Accordingly, blocks of the flowcharts, and procedures, algorithms, steps, operations, formulae, or computational depictions described herein support combinations of means for performing the specified function(s), combinations of steps for performing the specified function(s), and computer program instructions, such as embodied in computer-readable program code logic means, for performing the specified function(s). It will also be understood that each block of the flowchart illustrations, as well as any procedures, algorithms, steps, operations, formulae, or computational depictions and combinations thereof described herein, can be implemented by special purpose hardware-based computer systems which perform the specified function(s) or step(s), or combinations of special purpose hardware and computer-readable program code.

It will further be appreciated that as used herein, that the terms processor, hardware processor, computer processor, central processing unit (CPU), and computer are used synonymously to denote a device capable of executing the instructions and communicating with input/output interfaces and/or peripheral devices, and that the terms processor, hardware processor, computer processor, CPU, and computer are intended to encompass single or multiple devices, single core and multicore devices, and variations thereof.

As used herein, the singular terms "a," "an," and "the" may include plural referents unless the context clearly dictates otherwise. Reference to an object in the singular is not intended to mean "one and only one" unless explicitly so stated, but rather "one or more.

As used herein, the term "set" refers to a collection of one or more objects. Thus, for example, a set of objects can include a single object or multiple objects.

As used herein, the terms "substantially" and "about" are used to describe and account for small variations. When used in conjunction with an event or circumstance, the terms can refer to instances in which the event or circumstance occurs precisely as well as instances in which the event or circumstance occurs to a close approximation. When used in conjunction with a numerical value, the terms can refer to a range of variation of less than or equal to ± <NUM>% of that numerical value, such as less than or equal to ±<NUM>%, less than or equal to ±<NUM>%, less than or equal to ±<NUM>%, less than or equal to ±<NUM>%, less than or equal to ±<NUM> %, less than or equal to ±<NUM>%, less than or equal to ±<NUM> %, or less than or equal to ±<NUM>%. For example, "substantially" aligned can refer to a range of angular variation of less than or equal to ±<NUM>°, such as less than or equal to ±<NUM>°, less than or equal to ±<NUM>°, less than or equal to ±<NUM>°, less than or equal to ±<NUM>°, less than or equal to ±<NUM>°, less than or equal to ±<NUM>°, less than or equal to ±<NUM>°, or less than or equal to ±<NUM>°.

Additionally, amounts, ratios, and other numerical values may sometimes be presented herein in a range format. It is to be understood that such range format is used for convenience and brevity and should be understood flexibly to include numerical values explicitly specified as limits of a range, but also to include all individual numerical values or sub-ranges encompassed within that range as if each numerical value and sub-range is explicitly specified. For example, a ratio in the range of about <NUM> to about <NUM> should be understood to include the explicitly recited limits of about <NUM> and about <NUM>, but also to include individual ratios such as about <NUM>, about <NUM>, and about <NUM>, and sub-ranges such as about <NUM> to about <NUM>, about <NUM> to about <NUM>, and so forth.

Although the description herein contains many details, these should not be construed as limiting the scope of the disclosure but as merely providing illustrations of some of the presently preferred embodiments. Therefore, it will be appreciated that the scope of the disclosure fully encompasses other embodiments which may become obvious to those skilled in the art.

Phrasing constructs, such as "A, B and/or C", within the present disclosure describe where either A, B, or C can be present, or any combination of items A, B and C. Phrasing constructs indicating, such as "at least one of" followed by listing group of elements, indicates that at least one of these group elements is present, which includes any possible combination of these listed elements as applicable.

Claim 1:
An apparatus (<NUM>) for wireless communication in a network, the apparatus comprising:
(a) a wireless communication circuit (<NUM>) configured for wirelessly communicating with at least one other wireless local area network, WLAN, station in its reception area;
(b) a processor (<NUM>) coupled to said wireless communication circuit within a station configured for operating on the WLAN;
(c) a non-transitory memory (<NUM>) storing instructions executable by the processor; and
(d) wherein said instructions, when executed by the processor, perform one or more steps comprising:
(i) operating said wireless communication circuit as a WLAN station configured to support communicating real-time application, RTA, packets that are sensitive to communication delays as well as communicating non-real time packets;
(ii) distinguishing RTA packets from non-RTA packets by making a determination based on a combination of prior negotiation and packet header information;
(iii) utilizing carrier sense multiple access/collision avoidance, CSMA / CA, in which RTA traffic and non-RTA traffic coexist;
(iv) maintaining an RTA scheduling table for tracking active RTA sessions and managing transmission times for RTA traffic;
(v) scheduling channel time based on the expected RTA packet arrival time; and
(vi) rejecting other packet transmissions during the scheduled channel time for RTA packet.