Patent Description:
Current wireless technologies using the Open Systems Interconnection (OSI) model, such as the IEEE <NUM> protocols, do not provide low latency capability. However, a wide range of applications, such as real time applications (RTA), require low latency.

RTAs require low latency communication and use best effort communication. The data generated from the RTA is called RTA traffic and is packetized as an RTA packet at the transmitter station (STA). Conversely, the data generated from a non-time sensitive application is referred to herein as non-RTA traffic and will be packetized as a non-RTA packet at the transmitter STA.

The RTA packet requires low latency due to its high timeliness requirement on packet delivery. The RTA packet is only valid if it is delivered within a certain period of time. To achieve this requirement, new communication functions are required in the OSI model, as well as the interworking communication between the network layers.

OSI is a conceptual model defined by the International Organization for Standardization (IOS) to establish telecommunication between various computing systems with standard communication protocols. Typically, OSI consists of seven layers, application (APP) layer, presentation layer, session layer, transport layer, network layer, data link layer, and physical layer. Those layers are used to define and standardize the functions utilized in various forms of communications. When two systems share the same communication protocol at the same layers, they are able to exchange information between each other.

When communication occurs, each layer provides service to the layer above it and requests service from the layer below it. Therefore, the interworking communication between the network layers in the OSI model is utilized for enabling these services.

IEEE <NUM> protocols define the standard communication protocols at the data link (i.e., MAC) and physical (i.e., PHY) layers. The current <NUM> protocols only focus on obtaining throughput performance of the wireless networks. However, the latency performance of the wireless networks is not considered and this is problematic for RTAs. When the network transmits RTA packets they are typically only valid for a certain period of time, it requires the APP layer and the MAC layer to establish the interworking communication to control and monitor the traffic transmission within that time, thus a measure of control over packet latency is required.

Existing technologies do not meet the timeliness requirement of the RTA packet and are not directed toward minimizing RTA packet transmission latency.

Accordingly, a need exists for enhanced latency control of RTA packet traffic in WLAN system. The present disclosure fulfills that need and provides additional benefits over previous technologies.

<CIT> relates to media control in a communication network.

The current wireless communication systems of IEEE <NUM> do not identify the RTA packet and non-RTA packet. All the packets use the same OSI model. The current OSI model of IEEE <NUM> does not characterize or standardize the functions of low latency communication for RTA packets. IEEE <NUM> standards at this time do not address controlling the latency to which an RTA packet is subjected. The lack of these functions makes the current IEEE <NUM> protocols unable to satisfy the low latency requirements of RTA packets.

To satisfy the low latency requirement of RTA traffic, the present disclosure describes distinguishing RTA packets and provides a beneficial RTA interface between the Medium Access Control (MAC) and Application (APP) layers which are part of interworking communications in the OSI model.

The task of creating an RTA interface between MAC and APP layers is more challenging due to the coexistence of RTA traffic and non-RTA traffic on the network. The challenge in this process can be summarized as: (a) identifying and distinguish between RTA packets and non-RTA packets; (b) designing new interworking communications between network layers to support low latency requirements of RTA packets; and (c) allowing RTA packets to use the new interworking communications for obtaining low latency service, while non-RTA packets can utilize existing interworking communications to benefit from a high throughput service.

The RTA interface between MAC and APP layers aims to consider the time-validity of RTA traffic and provide possible low latency service by interworking communication where RTA and non-RTA traffic coexist in a wireless network.

It is possible that several functions of low latency communication will be characterized and standardized at the MAC or PHY layer. In order to enable those functions in the OSI model of IEEE <NUM>, a new interworking communication between the network layers of the OSI model is necessary.

The RTA traffic is primarily concerned with end-to-end latency, which is the time between when the traffic is generated at the APP layer of the transmitter and the time that the traffic is received at the APP layer of the receiver. Therefore, it is beneficial to allow the APP layer to have some capability to control and monitor the MAC layer functions for RTA traffic.

The present disclosure teaches an RTA interface between MAC and APP layers as a part of interworking communication in the OSI model for RTA packets, while non-RTA packets can still use the regular OSI model. The present disclosure may be applied to IEEE <NUM>, and more preferably IEEE <NUM> be and beyond.

The RTA interface between MAC and APP layers allows the APP layer to manage the RTA session at the MAC layer. Often, an RTA generates traffic periodically, in the manner of connection-oriented communications. RTA connection-oriented communication established by an application between STAs is called an RTA session. It is possible that a station (STA) can have multiple RTA sessions in the network. The APP is able to manage those RTA sessions properly by using the disclosed interface between the MAC and APP layers.

The RTA interface between the MAC and APP layers allows the APP layer to manage the RTA queues at the MAC layer. The APP layer is able to send commands to set the parameters of the RTA queue through the RTA interface. The interface also allows the MAC layer to report RTA queue status to the APP layer.

The RTA interface between the MAC and APP layers allows the APP layer to measure RTA Key Performance Indicators (KPIs) at the MAC and PHY layers. The APP layer sends an RTA KPI measurement request to the MAC layer and the MAC layer reports the KPI measurement results to the APP layer through the RTA interface.

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:.

<FIG> depicts the details of a WLAN system under IEEE <NUM> using Carrier Sense Multiple Access/Collision Avoidance (CSMA/CA) to allow stations (STAs) to have random access to the channel for packet transmission and retransmission. In a CSMA/CA system, the STA senses the channel for transmission when there is data to be transmitted. Before each transmission and retransmission, the STA must sense the channel and set (wait) a backoff time to contend for channel access.

The backoff time is decided by a uniform random variable between zero and the size (duration) of the contention window. After the STA waits for the backoff time and senses that the channel is idle, it decides whether to send an RTS frame to ensure channel occupancy or not. If the STA sends an RTS frame, the channel occupancy is ensured when it receives a CTS frame, at which time the STA sends the packet. If the STA does not send an RTS frame, it may in some cases send the packet directly. A retransmission is required if the CTS frame is not received after sending the RTS frame, or if the STA does not receive the ACK before timeout. Otherwise, if the CTS frame is received the transmission has succeeded. When retransmission is required, the STA checks the number of retransmissions of the packet, and if the number of retransmissions exceeds the retry limit, then the packet is dropped, and no retransmission is scheduled; otherwise, retransmission is scheduled. If the retransmission is scheduled, then another backoff time is needed to contend for channel access for retransmission. If the size of the contention window has not reached the upper limit, the STA increases it. The STA sets another backoff time, depending on the new size of the contention window, and waits the backoff time for retransmission and this process continues.

<FIG> illustrates an example of random channel access between a transmitting station and a receiving station under CSMA/CA in which RTS/CTS is disabled. When the MAC layer of the transmitter STA receives the data from its upper layers, it contends to gain channel access. When the transmitter STA contends for the channel, it has to wait until a backoff time, whereby the size of the contention window is "n" slots (CW= n slots), which it counts down to zero during backoff. The count-down process is interrupted (i.e., the Clear Channel Assessment (CCA) indicates busy) when another packet transmission occurs over the channel. After the transmitter STA gains channel access for transmitting 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 fails, a retransmission of the packet is required. The transmitter STA sets another backoff time to contend for channel access. This time, the size of the contention window is doubled, which is <NUM>*n slots (CW= <NUM>*n slots), due to this being a retransmission. The expected backoff time is also doubled by the contention window size. When the backoff time is longer, there is an increased probability that the count-down process will be interrupted (i.e., CCA busy) by another packet transmission. The figure shows that after an initially failed transmission and then contending for the channel three times that it finally performs a <NUM>st retransmission which succeeds when it receives an ACK.

The figure also depicts the timing with SIFS, DIFS and ACK Timeout. G1 in the figure represents a Short Inter-frame Spacing (SIFS), which is the time interval required by a wireless device in between receiving a frame and responding to the frame. The Distributed Coordination Function (DCF) protocol controls access to the physical medium in which a station must sense the status of the wireless medium before transmitting. If it finds that the medium is continuously idle for a DCF Interframe Space (DIFS) duration, it is then permitted to transmit a frame. If the channel is found busy during the DIFS interval, the station should defer its transmission. The figure represents DIFS as G2. It will be noted that conventional DIFS is calculated as DIFS = SIFS + (<NUM> * Slot time). G3 represents the ACK Timeout interval which is the time allowed for the acknowledgement of transmission to be received before it is assumed a transmission error has occurred.

<FIG> depicts a WLAN Enhanced Distributed Channel Access (EDCA) queue system. In WLAN systems, IEEE <NUM> uses an EDCA protocol to classify packets into different Access Categories (AC), with each AC representing a different priority of the traffic. A STA maps all the packets into different ACs and pushes them into independent queues with respect to the ACs.

The reference implementation model of the queue system using the EDCA protocol is shown in the figure, in which are seen four ACs, such as voice (VO), video (VI), best-effort (BE), and background (BK), with the priority reducing from the left to the right. Each AC has an independent queue to manage the order of packet transmission. Each queue relies on the random channel access mechanism based on CSMA/CA to gain channel access. Depending on traffic priority of the AC, the backoff time differs for each queue to gain channel access. When traffic priority of the AC is higher, the average backoff time for the queue of that AC is shorter. Therefore, the packet in the queue of the higher priority AC has a higher probability to gain channel access earlier than the packet in the queue of a lower priority AC.

The current wireless communication systems of IEEE <NUM> does not identify and distinguish between RTA packets and non-RTA packets, with all the packets being handled according to the same traditional OSI model, that did not specifically address latency issues of RTA packets. At this time the current OSI model of IEEE <NUM> does not characterize or standardize the functions of low latency communication for RTA packets. The lack of those functions means that the current IEEE <NUM> protocols cannot satisfy the low latency requirements of RTA packets.

Toward supporting low latency communication several functions are described herein for being characterized and standardized at the MAC or PHY layer. In order to enable those functions in the OSI model of IEEE <NUM>, a change to the interworking communication model between the network layer of OSI model is needed.

In RTA traffic a very important factor is end-to-end latency, which is the time between the time traffic is generated at the APP layer of the transmitter and the time that traffic is received at the APP layer of the receiver. Therefore, it is beneficial to allow the APP layer to have some capability to control and monitor the MAC layer functions for the RTA traffic.

The present disclosure describes an RTA interface between the MAC and APP layers as part of interworking communications in the OSI model for RTA packets, while non-RTA packets can still rely on the elements of a traditional (regular) OSI model.

The RTA interface between the MAC and APP layers allows the APP layer to manage the RTA session at the MAC layer. Often, RTAs generate traffic periodically, as a form of connection-oriented communication. RTA connection-oriented communications established by an application between STAs is called an RTA session. It is possible that a STA can have multiple RTA sessions in the network. The APP is able to manage those RTA sessions properly by using the disclosed interface between MAC and APP layers.

The RTA interface between MAC and APP layers allows the APP layer to manage the RTA queues at the MAC layer. The APP layer is able to send commands to set the parameters of the RTA queue through the RTA interface. The interface also allows the MAC layer to report RTA queue status to the APP layer.

The RTA interface between the MAC and APP layers allows the APP layer to measure the RTA Key Performance Indicators (KPIs) at the MAC and PHY layers. The APP layer sends an RTA KPI measurement request to the MAC layer and the MAC layer reports the KPI measurement results to the APP layer through the RTA interface.

<FIG> illustrates an example embodiment <NUM> of a WLAN station according to the present disclosure. An I/O path <NUM> is shown into circuit block <NUM> which has a bus <NUM> connected to at least one computer processor (CPU) <NUM>, memory (RAM) <NUM>, and at least one modem <NUM>. Bus <NUM> allows connecting various devices to the CPU, 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 protocol, which are executed to allow the STA to perform the functions of an access point (AP) station or a regular station (STA). It should also be appreciated that the programming is configured to operate in different modes (source, intermediate, destination, first AP, other AP, stations associated with first AP, stations associated with other AP, coordinator, coordinatee and so forth), depending on what role it is playing in the current communication context.

This host machine is shown configured with at least one modem and RF circuit. By way of example and not limitation, a mmW modem <NUM> is coupled to at least one radio-frequency (RF) circuit <NUM> which connects to a plurality of antennas 26a, 26b, 26c through 26n (e.g., antenna array) to transmit and receive frames with neighboring STAs. The combination of processor, modem and RF circuits, allow beamformed (directional) communications to be supported, as well as for supporting quasi-omni (referred to herein simply as omni) mode transmissions from the antenna array. In addition, in at least one preferred embodiment nulls can be generated in directional patterns created by the antenna array to shield select directions (sectors) and thus reduce interference between stations. The example also depicts modem <NUM> coupled to an omni-directional RF circuit <NUM> and antenna <NUM>.

Thus, the STA HW is shown configured with at least one modem, and associated RF circuitry for providing communication on at least one band. By way of example and not limitation the intended directional communication band is implemented with a mmW band modem and its associated RF circuitries for transmitting and receiving data in the mmW band. In some implementations another band can be supported in hardware, generally referred to as a discovery band, which by way of example and not limitation may comprise a sub-<NUM> modem and its associated RF circuitry for transmitting and receiving data in the sub-<NUM> band.

It should be appreciated that the present disclosure can be configured with multiple modems <NUM>, with each modem 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 neighboring 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.

<FIG> illustrates an example network scenario embodiment <NUM> for explaining the operation of the proposed technology. It should be appreciated that the present disclosure is not limited to this specific scenario, as the disclosure may be utilized in scenarios of larger networks containing more than two APs, any desired number of STAs, any relative orientations of STAs and APs, and having any arbitrary or fixed boundaries of the broadcast area. In this example scenario there is seen STAG (AP) <NUM>, STA5 (AP) <NUM> and six other STAs (STA1 <NUM>, STA2 <NUM>, STA3 <NUM>, STA4 <NUM>, STA6 <NUM> and STA7 <NUM>) within two Basic Service Sets (BSSs) in a room, or local area <NUM>. It will be noted that a Basic Service Set consists of a set of stations (STAs) that have successfully synchronized with an AP in the network. Each STA can communicate with the other STAs in the same BSS. All STAs use CSMA/CA for random channel access for non-RTA packets. The location of the STAs and their transmission links are as shown in the figure.

The present disclosure classifies packets in the wireless communication system as either RTA or non-RTA packets. RTA packets use the present disclosure for packet transmission, while non-RTA packets may use the regular IEEE <NUM> CSMA/CA scheme. To that end, the STA identifies the RTA packet and non-RTA packet at the MAC layer.

<FIG> illustrates an example embodiment <NUM> of RTA and non-RTA traffic communication in the OSI model. 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 transmitter STA. 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 the packets in the wireless communication system as being either RTA or non-RTA. RTA packets 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.

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 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 the transmission. This section provides the details of how the STA copes with the lifetime expiration of the RTA packet.

Often, RTAs generate traffic periodically, in the manner of connection-oriented communications. 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 this 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 can 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, receiver STA can also classify 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 as explained in Section <NUM>.

<FIG> illustrates an example embodiment <NUM> of prior negotiation for an RTA traffic packet at a transmitter side <NUM> and a receiver side <NUM>. It should be appreciated that one prior negotiation establishes one RTA session and can 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 on 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 identifying information can be picked from the information listed in Table <NUM>, such as TCP/UDP port number, the type of service, and so forth. 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 it 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 which 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.

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 packetize the RTA traffic into an 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 <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 being non-RTA traffic. After identifying the packet 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> that the traffic is RTA traffic.

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 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>.

When the RTA user initiates an RTA session, the initiation procedure is launched by the application layer and executed at the MAC layer as explained in <FIG>. There are two types of communication. One type of communication occurs between the different network layers in one STA. The other type of communication occurs between two STAs.

<FIG> illustrates an example embodiment <NUM> of an interworking model for the disclosed RTA management. The figure illustrates an RTA User <NUM> and other higher layers <NUM>. A MAC sublayer <NUM> is shown with a MAC Service Access Point (SAP) <NUM> between it and the higher layers <NUM>. A similar SAP for the PHY layer is seen <NUM> connecting to the PHYsical (PHY) and Physical Medium Dependent (PMD) sublayers <NUM>. A MAC Layer Management Entity (MLME) <NUM> is shown for communicating in MAC sublayer <NUM>, and through a MLME to PHY layer Management Entity (PLME) SAP <NUM> to a PLME <NUM>. At the lower right in the figure is seen a Station Management Entity (SME) <NUM> having RTA management functions <NUM> for communicating with RTA user <NUM>. In addition the SME is seen having an MLME SAP <NUM> for communicating with the MLME, and a PLME SAP <NUM> for communicating with the PLME <NUM>.

In operation, when the communication between the different network layers of one STA occurs, the RTA user can manage RTA activities through the cross-layer interfaces. The RTA user can communicate and exchange information with the MAC layer and the higher layers, such as the APP layer.

The RTA user at the APP layer can provide multiple RTA services to the MAC layer. For example, the STA can provide: (a) RTA event service, such as RTA session management; (b) RTA command service, such as RTA queue settings; and (c) RTA information service, such as RTA KPI measurement.

An RTA user can pass those service requests through the RTA management <NUM> of the Station Management Entity (SME) <NUM> at the MAC layer. Then, according to the request information, the SME is able to take action at the MAC layer through the MAC Sublayer Management Entity Service Access Point (MLME SAP) interface <NUM>.

When the communication occurs between two STAs, the RTA user can pass a message through the cross-layer interfaces and let the MAC transmit and receive frames between two STAs.

Besides the direct message exchange between RTA user and SME, it is also possible that the RTA user at the APP layer exchanges the message with the SME through a MAC State Generic Convergence Function (MSGCF), thus the message can be forwarded via MSGCF SAP and MSGCF-SME SAP defined in IEEE <NUM>.

<FIG> illustrates an example embodiment <NUM> of a layer management model for RTA management. The figure depicts SME <NUM>, MLME <NUM> and MAC Sublayer <NUM>. RTA Management <NUM> (was shown as block <NUM> in <FIG>) is seen having modules for RTA Queue Management <NUM>, RTA KPI Measurement Policy <NUM> and RTA Session Management <NUM>. At the MLME level are seen a set of functions for RTA Queue Setting 266a, External RTA Queue Setting 266b, RTA KPI Measure 266c, RTA KPI Measure Request and Report 266d, and RTA Session Initiation and Destruction 266e. It should be appreciated that the above functions are given by way of example for a specific embodiment, while these functions may be truncated or expanded without departing from the teachings of the present disclosure. A series of modules are seen coupled to these functions as RTA Queue Operation Protocols 270a, RTA Queue Setting Frame 270b, RTA KPI Measurement Protocols 270c, RTA KPI Measurement Frame 270d, and RTA Session Events 270e. Below these are seen a function for RTA Queue Control and Monitoring <NUM> coupled to a Queue structure <NUM> at the MAC sublayer. In addition a MAC Timing (TSF Training) block <NUM> is seen for communicating with blocks 270a through 270e.

The layer management has a certain partition of functionality between the MLME and SME. As shown in the figure, the RTA management entity <NUM> residing in the SME <NUM> represents the management decisions, while the functions residing in the MLME take actions following the management decisions from the SME. The RTA management in SME is able to make decisions and receive feedback for RTA queue management, RTA KPI measurement policy, and RTA session management.

When the RTA management entity <NUM> makes decisions on RTA session management <NUM>, it calls the RTA session events function 270e at MLME. According to the decision, the STA is able to initiate, re-initiate, or destruct 266e an RTA session with another STA. More details will be explained in Section <NUM>.

When the RTA management entity <NUM> makes decisions on RTA queue management <NUM>, it either calls the RTA Queue Operation Protocols 270a function at MLME to control the internal queue 266a at MAC sublayer, or calls the RTA Queue Setting Frame function 270b at MLME to send management frame to set the external queue 266b. The RTA Queue Operation Protocols function 270a is able to report the status of the queue to the RTA management entity <NUM>. The RTA Queue Setting Frame function 270b is able to receive the frame from other STAs and pass the information in the frame to RTA management. More details are explained in Section <NUM>.

When RTA management makes a decision on RTA KPI Measurement Policy <NUM>, it either calls the RTA KPI Measurement Protocol function 270c at MLME to launch the RTA KPI measurements 266c at the MAC and PHY layers, or calls the RTA KPI Measure Frame function 270d at MLME to transmit a management frame to other STAs to schedule an RTA KPI measurement 266d at another STA. The RTA KPI Measurement Protocols function 270c is able to report the measurement results to RTA management <NUM>. The RTA KPI Measurement Frame function 270d can receive a measurement report frame from other STAs and pass the report to RTA management. More details are explained in Section <NUM>.

When the functions at MLME perform actions according to the decisions made by the RTA management at SME, it can use the timestamp at the MAC layer, such as the TSF timing, as the time reference.

This section explains the details of how a STA initiates, re-initiates, and destructs an RTA session by using the interface between the RTA session management at SME and the RTA Session Events function at MLME.

<FIG> illustrates an example embodiment <NUM> of RTA session information comprising identifying information <NUM>, status information <NUM>, requirement information <NUM>, transmission information <NUM>, queue information <NUM> and measurement information <NUM>.

When two STAs establish an RTA session, they need to exchange information for the RTA session. The figure shows an example of RTA session information. The content contains the following messages and fields.

Identifying Info <NUM> is the identifying information from the MAC header, such as Source MAC Address and Destination MAC Address, that is from the layers above the MAC layer as listed in Table <NUM>, such as Session ID, Type of Service, Source IP Address, Source Port, Destination IP Address, and Destination Port.

Status Info <NUM> is the status information containing status such as Session Status, Comment, and Last Active Time. Session status shows whether the RTA session is set to generate traffic or not. Table <NUM> lists the possible 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 and does not generate RTA traffic from the user. When the RTA session status is an error, the RTA session is not able to generate or transmit RTA traffic because of the error. The comment field can be utilized to show the details of the RTA session status. It can be used to carry warning or error messages. For example, the comment can show the transmission quality is poor when numerous RTA packets are corrupted in this session. It can also be used to carry information suggesting operating parameters for creating a new RTA session. The last active time field can be used to trigger some event to check the status of the RTA session. The 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. The RTA session status should be checked to find whether some error has occurred.

Requirement Info <NUM> contains fields about requirements information comprising Bandwidth Requirement, Delay Requirement, Jitter Requirement, Periodic Time, Session Start Time, and Session End Time. The bandwidth requirement field indicates the amount of RTA traffic to transmit. When a STA measures the channel bandwidth, it can compare the measured bandwidth with the required bandwidth. The details of the bandwidth measurement are explained in Section <NUM>. If the measurement results cannot satisfy the requirement, then the STA can reject the RTA session initiation.

The delay requirement field indicates the transmission delay of the RTA packets. When the STA measures packet transmission latency, it can compare measured latency with required delay. The details of the latency measurement are explained in Section <NUM>. If the measurement results cannot satisfy the requirement, then the STA can reject the RTA session initiation.

The jitter requirement field indicates the maximum difference in the RTA packet delay during each periodic transmission time. When a STA measures the packet transmission latency, it can obtain the jitter information and compare it with jitter requirement. The details of the latency measurement are explained in Section <NUM>. If the measurement results cannot satisfy the requirement, then the STA can reject the RTA session initiation.

The periodic time indicates the duration of time until the RTA session generates RTA traffic once; that is to say that the RTA session generates traffic every periodic time. The session start time field and end time field indicate the start time and the end time of the RTA session.

Transmission Info <NUM> is a transmission information message comprising fields for Time Allocation, RU Allocation and SS Allocation. The time allocation field indicates the amount of channel time that is distributed to the RTA session for transmission.

The RU allocation field 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>. The RU determines which channel frequency to use for transmission.

The SS allocation field indicates the spatial stream allocation for the RTA session traffic transmission. The SS allocation can be a unit in MIMO terminology used in IEEE <NUM> or an index of directional antenna pattern in beamforming terminology.

Queue Info <NUM> provides queue information and contains fields comprising Initial Queue Types, Lifetime, RTA Priority. The initial queue types indicate which queue the traffic should be pushed to when it is generated by the RTA session. The lifetime represents the time that the RTA packets can be stored at the queue. When the lifetime expires, the packet is dropped. In one mode according to at least one embodiment of the present disclosure, an RTA packet closer to its expiration time is transmitted first. The RTA priority field indicates the priority of the RTA packet. In one mode according to at least one embodiment of the present disclosure, an RTA packet with higher priority should be transmitted first.

Measurement Info <NUM> - measurement information has fields comprising Measurement Indication, RTA KPIs Measure Method, RTA KPI Measure Report. The measurement indication subfield can be implemented as a one-bit indication. When it is set to a first state (e.g., "<NUM>"), then the STA requests RTA KPls measurements before initiating an RTA session; however, when it is set to a second state (e.g., "<NUM>"), then the RTA KPIs measurement is not requested by RTA session initiation.

The RTA KPIs measurement method field indicates which types of RTA KPIs measurements should be launched during the RTA session initiation procedure. Several examples of the measurements will be provided in Section <NUM>. The RTA KPI Measurement Report field carries the RTA KPI measurement results.

<FIG> illustrate an example embodiment <NUM> exemplifying a complete procedure of RTA session initiation and a message exchange between an originator <NUM> and a recipient, each having an APP Layer <NUM>, <NUM>, SME Layer <NUM>, <NUM>, MLME Layer <NUM>, <NUM>. It will be noted that the actual messages are exchanged between the MAC layers of these two STAs.

When the RTA user of the originator STA decides (determines) to initiate an RTA session <NUM>, it passes an RTASESSIONEVENT. request message <NUM> as shown in Table <NUM> to its SME. Then SME needs to initiate the RTA session <NUM>, such as by measuring the RTA KPI first to ensure the channel resource is available to establish the RTA session. The RTA session management at the SME of the originator STA makes decision and sends an RTAKPIMEASURE. request message <NUM> to the RTA KPI measurement protocols function at the MLME layer <NUM>. The format of the RTAKPIMEASURE. request message is explained in Table <NUM>.

Then, the MLME launches the RTA KPI measurement procedure <NUM> according to the request in the RTAKPIMEASURE. request message. For example, if the originator STA plans to transmit RTA packets, the channel bandwidth measurement as explained in Section <NUM>. <NUM> can be performed here. The RTA KPI measurement procedure is explained in Section <NUM>. After the MLME finishes the measurement procedure, it sends an RTAKPIMEASURE. confirm message <NUM> as explained in Table <NUM> to report the measurement results.

When the SME of the originator STA receives the RTA KPI measurement results, it compiles the measurement report <NUM> and decides whether to continue initiating <NUM> the RTA session or not. For example, the STA can compare the RTA KPI measurement results, such as channel bandwidth, with the requirement information of the RTA session (as defined in <FIG>). If the measurement results satisfy the requirement, it continues RTA session initiation.

If the STA decides to continue the RTA session initiation, the RTA session management at the SME of the originator STA sends an RTASESSIONINIT. request message <NUM> to the RTA session events function at the MLME via MLME SAP interface. The format of the RTASESSIONINIT. request message is explained in Table <NUM>.

When the MLME of the originator STA receives the RTASESSIONINIT. request message, it collects the RTA session information in the RTASESSIONINIT. request message and sends an RTA session initiation request frame <NUM> to the recipient STA. The format of the RTA session initiation request frame is shown in <FIG>. The MLME of the recipient STA <NUM> receives the frame and generates an RTASESSIONINIT. indication message <NUM>, as shown in Table <NUM>, to its SME via the MLME SAP interface.

Then, SME layer <NUM> passes an RTASESSIONINITEVENT. indicate message <NUM>, as shown in Table <NUM>, to the RTA user at the APP layer of the recipient STA. If the RTA user at the APP layer of the recipient STA determines <NUM> in <FIG> to follow the initiation event, it passes an RTASESSIONINITEVENT. response message <NUM>, as shown in Table <NUM>, back to the SME layer. Within this response message, if the APP layer has decided to continue the initiation, it has set the FollowEvent field in RTASESSIONINITEVENT. response message to indicate following the initiation event, such as by setting it to "<NUM>" in the example.

Then SME continues following the RTA session initiation <NUM> procedure. As explained in <FIG> <FIG>, the recipient STA needs to check the channel resource availability and determine whether to grant the RTA session initiation request. To make this determination the recipient STA needs to measure the RTA KPIs on its side. The procedure of the RTA KPI measurement is the same as at the originator STA, with sending an RTAKPIMEASURE. request message <NUM>, in response to which a KPI measurement process is performed <NUM>, and a RTAKPIMEASURE. confirm message <NUM> is sent back to the SME. For example, if the recipient STA plans to receive the RTA packets, the packet transmission latency measurement as explained in Section <NUM>. <NUM> can be performed here. The measurement information is compiled <NUM> and a decision made <NUM> in <FIG> whether or not to grant RTA session initiation.

Then, the SME of the recipient STA sends an RTASESSIONINIT. response message <NUM> containing feedback information to its MLME. The format of RTASESSIONINIT. response message is explained in Table <NUM>. Then, the MLME of the recipient STA sends an RTA session initiation response frame <NUM> to the MLME of the originator STA. The MLME of the originator STA receives the frame and sends an RTASESSIONINIT. confirm message <NUM>, as shown in Table <NUM>, to its SME, which is made aware <NUM> of the session initiation agreement. The SME of the originator then informs <NUM> the RTA users, through an RTASESSIONINITEVENT. confirm message, that the initiation of the RTA session is successful or not, which completes <NUM> RTA session initiation, with a similar RTASESSIONINITEVENT. confirm message <NUM> being sent from the recipient SME <NUM> to its users at the APP layer.

The SME of both the originator STA and recipient STA are aware of the RTA session initiation results. They forward the result via an RTASESSIONINITEVENT. confirm message as shown in Table <NUM> to the APP layer.

<FIG> illustrates an example embodiment <NUM> of an RTA session initiation request frame format 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. A TA field contains the address of the STA that transmitted the frame. An Action field indicates the type of management frame; which in this case 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 an RTA session initiation request frame. The Initiation Request information field contains the following subfields. (a) An RTA Session ID subfield identifies the RTA session, with its content being shown in <FIG>. (b) A Resource Requirement subfield contains requirement information of the RTA session as described in <FIG>. (c) A Queue Information subfield provides queue information for the RTA session as described in <FIG>. (d) A Measurement Indication subfield indicates whether the measurement is required for RTA initiation, and can be implemented as a one-bit indication. When this field is set to a first state (e.g., "<NUM>"), the measurement is required for RTA session initiation, and when this field is set to a second state (e.g., "<NUM>"), the measurement is not required. (e) An RTA KPIs Measure Method subfield carries the information on how to measure the RTA KPIs at the recipient STA. This field can use the formats shown in Section <NUM>. For example, this field could be the packet transmission latency measurement as explained in <FIG> of Section <NUM>.

<FIG> illustrates an example embodiment <NUM> of an RTA session initiation reply 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, in this case it 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 RTA session initiation reply frame, and contains the following subfields. An RTA Session ID subfield provides identifying information for the RTA session. The content of this field is shown in <FIG>. An Initiation Result subfield provides an indication (e.g., one bit) 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 this field is set to a second state (e.g., "<NUM>"). A Transmission Information subfield provides transmission information of the RTA session as described in <FIG>. A Status Information subfield contains the status information for the RTA session as described in <FIG>. A Measurement Indication subfield indicates whether the measurement results is included. By way of example, when this field is set to a first state (e.g., "<NUM>"), the measurement result is included, and when this field is set to a second state (e.g., "<NUM>"), the measurement is not included. A RTA KPI Measure Report subfield carries the RTA KPI measurement results.

<FIG> and <FIG> illustrates an example embodiment <NUM> of an alternative procedure for performing RTA session initiation. In certain situations, the originator STA initiates an RTA session without negotiating with the recipient STA. The figure provides another example of a message exchange between two STAs to complete RTA session initiation. The figure depicts communications between an originator and recipient as in <FIG>.

The RTA user of the originator STA decides <NUM> to initiate an RTA session and passes an RTASESSIONEVENT. request message <NUM> to its SME. The RTASESSIONEVENT. request message <NUM> is shown in Table <NUM>. Then the SME needs to determine <NUM> a few things before initiating the RTA session. First the SME measures the RTA KPI to ensure that sufficient channel resource is available to establish the RTA session. In this case the RTA session management at the SME of the originator STA makes a decision to initiate the RTA session and it sends a RTAKPIMEASURE. request message <NUM> to the RTA KPI measurement protocols function at the MLME layer. The format of the RTAKPIMEASURE. request message is explained in Table <NUM>.

Then the MLME launches the RTA KPI measurement procedure <NUM> according to the request in the RTAKPIMEASURE. request message. For example, if the originator STA plans to transmit RTA packets, the channel bandwidth measurement as explained in Section <NUM>. <NUM> can be performed at this time. The RTA KPI measurement procedure is explained in Section <NUM>. After the MLME finishes the measurement procedure, it sends RTAKPIMEASURE. confirm message <NUM> as explained in Table <NUM> to report the measurement results.

When the SME of the originator STA receives and compiles <NUM> in <FIG> the RTA KPI measurement results, it decides <NUM> whether to establish the RTA session or not. For example, the STA can compare the RTA KPI measurement results with the requirement information of the RTA session (as defined in <FIG>). If the measurement results satisfy the requirement, it determines to establish the RTA session.

If the STA decides to establish the RTA session initiation, the RTA session management at the SME of the originator STA sends an RTASESSIONANNOUNCE. request message <NUM> as shown in Table <NUM> to the RTA session events function at the MLME via MLME SAP interface. When the MLME of the originator STA receives the RTASESSIONANNOUNCE. request message, it collects the RTA session information in the RTASESSIONANNOUNCE. request message and sends an RTA session announce request frame <NUM> to the recipient STA. The format of the RTA session announcement request frame is shown in <FIG>. The MLME of the recipient STA receives the frame and generates an RTASESSIONANNOUNCE. confirm message <NUM> as shown in Table <NUM> to its SME via MLME SAP interface.

The SME of the both originator STA and recipient STA are aware <NUM>, <NUM>, of the RTA session initiation results. They forward the result via an RTASESSIONINITEVENT. confirm message <NUM>, <NUM> to their respective APP layer, thus RTA session initiation is completed <NUM>. The RTASESSIONINITEVENT. confirm message as shown in Table <NUM>.

Table <NUM> shows an example of RTA session table created by the RTA session initiation procedure at STA <NUM> when considering the network topology in <FIG>. The RTA session in the table can contain all the information listed in <FIG>. In order to make the RTA session table easier to understand, the table only contains the part of the RTA session information listed in <FIG>. The RTA session table at STA <NUM> (AP) as shown in Table <NUM> contains three RTA sessions. Each column in the table represents an RTA session. The session ID is simplified to an index number.

The first Session ID column represents RTA session <NUM> (simplified Session ID), 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, STA <NUM> has full flexibility to allocate channel time (Time Allocation Options), the RU (RU Allocation Options) and the spatial stream (SS Allocation Options). The periodic Time of RTA session <NUM> is <NUM>, which means RTA session <NUM> generates RTA traffic every <NUM>. The RTA priority is <NUM> and it will be transmitted through VI queue. The session status is active, which means the RTA session initiation is completed successfully and the session is generating RTA packets.

The second session ID column 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, STA <NUM> has full flexibility to allocate channel time (Time Allocation Options), the RU (RU Allocation Options) but the spatial stream (SS Allocation Options) must be fixed. The periodic Time of RTA session <NUM> is <NUM>, which means RTA session <NUM> generates RTA traffic every <NUM>. The RTA priority is <NUM> and it will be transmitted through VI queue. The session status is active, which means the RTA session initiation is completed successfully and the session is generating RTA packets.

The third Session ID 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, STA <NUM> has full flexibility to allocate channel time (Time Allocation Options), the RU (RU Allocation Options) and the spatial stream (SS Allocation Options). The periodic Time of RTA session <NUM> is <NUM>, which means RTA session <NUM> does not generate RTA traffic periodically. The RTA priority is <NUM>, which is higher than the other two RTA sessions. The packets generated by this RTA session will be transmitted through VO queue. The session status is active, which means that RTA session initiation has completed successfully and the session is generating RTA packets.

<FIG> illustrates an example embodiment <NUM> of an RTA session initiation being rejected by the originator STA. As in <FIG> and <FIG>, the communication between APP, SME and MLME take place on the originator side with communication from the APP layer to the SME and MLME down to the point where the SME compiles the measurements <NUM> and then instead of deciding to accept initiation as in <FIG> and <FIG>, in this example it decides to reject initiation <NUM>. The SME passes an RTASESSIONINITEVENT. confirm message <NUM> to the APP with the InitiationSuccess field setting to "<NUM>", so that when the RTA user at the APP layer receives this message, it knows the RTA session initiation failed <NUM>.

<FIG> and <FIG> illustrates an example embodiment <NUM> of an RTA session initiation being rejected by the recipient STA. As in <FIG> and <FIG>, the communication between APP, SME and MLME take place on the originator side with communication from the APP layer to the SME and MLME down to the point where the SME compiles the measurements <NUM> in <FIG> and here it decides to request session initiation <NUM> from the recipient APP. An RTASESSIONINIT. request message <NUM> is sent to the MLME which generates an RTA session initiation request frame <NUM> to the MLME of the recipient. The recipient MLME receives this input and generates an RTASESSIONINIT. indication message <NUM> to its SME which in turn generates an RTASESSIONINITEVENT. indicate message <NUM> to the APP layer. The APP layer decides to reject the initiation <NUM>, and sends an RTASESSIONINITEVENT. response message <NUM>, indicating that the initiation is rejected, to its SME which sends and RTASESSIONINIT. response message <NUM> to its MLME which sends a RTA session initiation response frame <NUM> to the MLME of the originating station. The originator MLME sends an RTA SESSIONINIT. confirm message <NUM> to its SME which sends an RTASESSIONINITEVENT. confirm message <NUM> containing an indication of the initiation rejection to the APP layer which fails <NUM> the RTA session initiation.

Table <NUM> shows an example of the RTA session table at STA <NUM> after a new RTA session is initiated between STA <NUM> and 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 represents the simplified RTA session identifying information. In the new RTA session, the session status is error since the session initiation is rejected by STA <NUM>.

<FIG> and <FIG> illustrates an example embodiment <NUM> of a procedure for RTA session re-initiation. The originator STA is able to re-initiate the RTA session when the initiation request is rejected by the recipient STA. The figure shows the message exchange between two STAs for an RTA session re-initiation. The procedure of RTA session re-initiation is the same as the complete procedure of the RTA session initiation as shown in <FIG> except that the RTA KPI measurement procedures are skipped on both sides. The STA is able to indicate that the measurement is not needed by setting the Measurementlndication parameter to "<NUM>" in the messages.

When the RTA user of the originator STA decides (determines) to initiate an RTA session <NUM>, it passes an RTASESSIONEVENT. request message <NUM> to its SME. Then since the message contains information that the measurement is not needed, the SME immediately starts to initiate <NUM> the RTA session and sends an RTASESSIONINIT. request message <NUM> to the RTA session events function at the MLME via MLME SAP interface. The format of the RTASESSIONINIT. request message is explained in Table <NUM>.

When the MLME of the originator STA receives the RTASESSIONINIT. request message, it collects the RTA session information in the RTASESSIONINIT. request message and sends an RTA session initiation request frame <NUM> to the recipient STA MLME. The MLME of the recipient STA receives the frame and generates an RTASESSIONINIT. indication message <NUM>, as shown in Table <NUM>, to its SME via the MLME SAP interface.

Then, the recipient SME passes an RTASESSIONINITEVENT. indicate message <NUM>, as shown in Table <NUM>, to the RTA user at the APP layer of the recipient STA. If the RTA user at the APP layer of the recipient STA determines <NUM> to allow the initiation event, it generates an RTASESSIONINITEVENT. response message <NUM>, as shown in Table <NUM>, back to the SME layer. Within this response message it has set the FollowEvent field in RTASESSIONINITEVENT. response message <NUM> to "<NUM>", since the APP layer has decided to continue the initiation.

Then SME continues following <NUM>, as seen in <FIG>, the RTA session initiation procedure, and it can proceed without a measurement as indicated from the originator side. A decision is made <NUM> to grant RTA session initiation. The SME of the recipient STA sends an RTASESSIONINIT. response message <NUM> containing feedback information to its MLME. The format of RTASESSIONINIT. response message is explained in Table <NUM>. Then, the MLME of the recipient STA sends an RTA session initiation response frame <NUM> to the originator STA. The MLME of the originator STA receives the frame and sends an RTASESSIONINIT. confirm message <NUM>, as shown in Table <NUM>, to its SME, which is made aware <NUM> of the session initiation agreement. The SME of the originator then informs the RTA users, through sending an RTASESSIONINITEVENT. confirm message <NUM>, that the initiation of the RTA session is successful or not, which completes <NUM> RTA session initiation. It will be noted that the SME of the recipient was similarly made aware <NUM> of the session initiation agreement and sends an RTASESSIONINITEVENT. confirm message <NUM> to its users at the APP layer.

Table <NUM> shows an example of the RTA session table at STA <NUM> after RTA session <NUM> is re-initiated between STA <NUM> and STA <NUM>. The RTA session table before the initiation procedure is shown in Table <NUM>. The initiation of RTA session <NUM> suggested to defer the session start time in the comment field of RTA session information as shown in <FIG>. So in this case, RTA session <NUM> is re-initiated by STA1 and STAG with new session start time. STAG grants the re-initiation of RTA session <NUM>.

<FIG> illustrates an example embodiment <NUM> of a procedure for performing RTA session destruction between originator and recipient STAs. When the RTA user of the originator STA decides <NUM> to destruct (end/close) an RTA session, it passes an RTASESSIONDESTRUCT. request message <NUM> to its SME. Then, the RTA session management at the SME of the originator STA starts to destruct <NUM> the session and sends an RTASESSIONDESTRUCT. request message <NUM> to the RTA session events function at the MLME via the MLME SAP interface. The format of the RTASESSIONDESTRUCT. request message is explained in Table <NUM>. When the MLME of the originator STA receives the RTASESSIONDESTRUCT. request message, it collects the RTA session information in the RTASESSIONDESTRUCT. request message and sends an RTA session destruction request frame <NUM> to the recipient STA. The format of the RTA session destruction request frame is shown in <FIG>. The MLME of the recipient STA receives the frame and generates an RTASESSIONDESTRUCT. confirm message <NUM> as shown in Table <NUM> to its SME via MLME SAP interface and forwards it <NUM> to the RTA user at the APP layer of the recipient.

<FIG> illustrates an example embodiment <NUM> 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 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; which in this example indicates that the management frame is an RTA session destruction request frame. An RTA Session ID field indicates the identifying information of RTA session, which is shown in <FIG>.

Table <NUM> shows an example of the RTA session table at STA <NUM> after RTA session <NUM> is destructed. The RTA session table before the initiation procedure is shown in Table <NUM>.

<FIG> illustrates an example embodiment <NUM> of a procedure for performing an RTA session announcement in which a STA is able to inform its neighboring STAs of its RTA session information. In the figure the message exchange is seen between two STAs which share RTA session information. The details of how one STA shares an RTA session with another STA is described as follows.

When the RTA user at the APP layer of the originator STA decides <NUM> to share or announce an RTA session, it passes an RTASESSIONANNOUNCE. request message <NUM> to the RTA session management at the SME of this originator STA which decides to announce an RTA session <NUM> and forwards the message <NUM> to the RTA session events function at the MLME via MLME SAP interface. The format of the RTASESSIONANNOUNCE. request message is explained in Table <NUM>.

When the MLME of the originator STA receives the RTASESSIONANNOUNCE. request message <NUM>, it collects the RTA session information in the RTASESSIONANNOUNCE. request message and sends an RTA session announce request frame <NUM> to the recipient STA. The format of the RTA session announcement request frame is shown in <FIG>. The MLME of the recipient STA receives the frame and generates an RTASESSIONANNOUNCE. confirm message <NUM> as shown in Table <NUM> to its SME via MLME SAP interface. The SME then forwards this message <NUM> to the RTA user of the APP layer.

<FIG> illustrates an example embodiment <NUM> of the RTA session announcement frame format 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. A TA field contains the address of the STA that transmitted the frame. An Action field indicates the type of management frame, which in this case indicates that the management frame is an RTA session announcement frame.

An Announcement Information field follows the Action field when the Action field indicates that the frame is RTA session announcement frame. The Announcement Information field contains the following subfields. An RTA Session ID subfield provides identifying information for the RTA session. The content of this RTA Session ID subfield is shown in <FIG>. A Requirement Information subfield contains requirement information of the RTA session as described in <FIG>. A Transmission Information subfield provides transmission information for the RTA session as described in <FIG>. A Status Information subfield contains status information for the RTA session as described in <FIG>.

Table <NUM> shows an example of the RTA session table at STA <NUM> after STA5 announces that it established RTA session <NUM>. The RTA session table before the initiation procedure is shown in Table <NUM>.

<FIG> and <FIG> illustrates an example embodiment <NUM> of RTA queue parameter setting. This section explains the details of how a STA sets queue parameters by using the interface between the RTA queue management at SME and the RTA Queue Operation protocol function and the RTA queue setting frame function at MLME. The figure shows a message exchange between two STAs when the originator STA sets the parameters of the queue at the recipient STA.

When the originator STA decides <NUM> to set RTA queue parameters of the recipient STA, the RTA session management at the APP layer sends an RTAQUEUEPARASETREQUEST. request message <NUM>, which is then forwarded <NUM> to the RTA session events function at the MLME via MLME SAP interface. The format of the RTAQUEUEPARASETREQUEST. request message is explained in Table <NUM>.

When the MLME of the originator STA receives the RTAQUEUEPARASETREQUEST. request message, it collects the RTAQueuePara in the RTAQUEUEPARASETREQUEST. request message and sends an RTA queue parameter setting request frame <NUM> to the recipient STA. The format of the RTA queue parameter setting request frame is shown in <FIG>. The MLME of the recipient STA receives the frame and in <FIG> generates an RTAQUEUEPARASETREQUEST. indication message <NUM> as shown in Table <NUM> to its SME via MLME SAP interface.

The RTA session management at the SME of the recipient STA then passes RTAQUEUEPARASET. request message <NUM> to the RTA Queue Operation protocol function at the MLME layer to perform RTA queue parameter setting <NUM>. The format of the RTAQUEUEPARASET. request message is explained in Table <NUM>. Then, the MLME sets the queue parameters according to the RTAQueuePara in the RTAQUEUEPARASET. request message.

After the MLME finishes the queue parameter setting, it sends RTAQUEUEPARASET. confirm message <NUM>, as explained in Table <NUM>, to report the parameter setting result. Then, the SME of the recipient STA sends two messages. The SME sends an RTAQUEUEPARASETREQUEST. confirm message <NUM> to the recipient APP layer to inform it about the parameter update of the queue. The SME also sends an RTAQUEUEPARASETREQUEST. response message <NUM> containing parameter setting result to its MLME. The format of RTAQUEUEPARASETREQUEST. response message is explained in Table <NUM>. Then, the MLME of the recipient STA sends an RTA queue parameter setting response frame <NUM> to the originator STA. The MLME of the originator STA receives the frame and sends an RTAQUEUEPARASETREQUEST. confirm message <NUM>, as shown in Table <NUM>, to its SME. The SME of the originator then forwards the message <NUM> to inform the RTA users on whether the initiation of the RTA session has been successful or not.

<FIG> illustrates an example embodiment <NUM> of an RTA queue parameter setting request 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. A TA field contains the address of the STA that transmitted the frame. An Action field indicates the type of management frame, which in this example indicates that the management frame is an RTA queue parameter setting request frame.

An RTA Queue Parameters field contains RTA queue parameter setting information having the following subfields. A Queue Type subfield indicates the type of queue, such as VO, VI, BE, BK, whose parameters are to be set. A Max Buffer Size subfield indicates the maximum buffer size of the queue. A Max Channel Time subfield indicates the maximum ratio of channel time that can be allocated to the queue. A Max Number of RTA Sessions subfield indicates the maximum number of RTA sessions whose packets can wait in the RTA queue. A Lifetime subfield indicates the lifetime of a packet in the queue; when the lifetime expires, the packet will be dropped. A Sorting Method subfield indicates the method to be used in sorting the packets in the queue. A Queue Channel Time Allocation subfield indicates the time during which the queue is allowed to transmit packets; which is shown with subfields for periodic time, start time, duration of each period, and end time.

<FIG> illustrates an example embodiment <NUM> of an RTA queue parameter setting response 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. A TA field contains the address of the STA that transmitted the frame. An Action field indicates the type of management frame; which in this case indicates that the management frame is an RTA queue parameter setting response frame. An RTA Queue Parameter setting result field indicates whether the RTA queue parameter setting was successful or not.

<FIG> and <FIG> illustrates example embodiments <NUM>, <NUM> of RTA queue operation in response to setting queue parameters.

In <FIG> is seen a case of sorting RTA packets by importance index. The figure explains the details of how an STA sets the sorting method to change the transmission order of the packets in its VI queue. It is seen that the VI queue sorts the packets by RTA priority <NUM>, with the packet with the highest RTA priority in the queue to be transmitted first. The figure gives an example of the STA changing <NUM> the sorting method, in this example to sort the packets by expiration time <NUM>, showing a different sort order of the packets depicted now with the shortest expiration time packets to be transmitted first.

In <FIG> is seen an example of how a station allocates channel time to different queues. Every periodic time <NUM>, the STA allocates separate channel times to different queues, such as VO <NUM>, VI <NUM>, BE <NUM>, BK queues <NUM> in EDCA. When the channel time is allocated to one queue, the STA only transmits the packets from that queue.

This section explains the details of how a station measures RTA KPIs by using the interface between the RTA session management at SME and the RTA KPI Measurement Protocol function and RTA KPI Measure Frame function at MLME.

<FIG> illustrates an example embodiment <NUM> depicting an example scenario of an RTA KPI measurement process between the MAC layers of an originator and recipient, showing message exchange when the originator STA requests RTA KPI measurement at the recipient STA.

When the RTA user at the APP of the originator STA determines <NUM> to request RTA KPIs measurement at the recipient STA, it sends an RTAKPIMREQUEST. request message <NUM> to the RTA session management at the SME of the originator STA which forwards it <NUM> to the RTA KPI measurement frame function at the MLME via MLME SAP interface. The format of the RTAKPIMREQUEST. request message is explained in Table <NUM>. When the MLME of the originator STA receives the RTAKPIMREQUEST. request message, it collects the RTA KPI measure method and report method in the RTAKPIMREQUEST. request message <NUM> and the originator MLME sends an RTA KPI measure request frame <NUM> to the recipient STA MLME. The format of the RTA KPI measure request frame is shown in <FIG>. The MLME of the recipient STA receives the frame and generates an RTAKPIMREQUEST. indication message <NUM> as shown in Table <NUM> to its SME via MLME SAP interface.

The RTA session management at the SME of the recipient STA then passes an RTAKPIMEASURE. request message <NUM> to the RTA KPI Measurement Protocol function at the MLME layer. The format of the RTAKPIMEASURE. request message is explained in Table <NUM>. Then, the MLME starts to measure the RTA KPIs in an RTA KPI measurement process <NUM>. After the MLME finishes the RTA KPI measurement, it sends an RTAKPIMEASURE. confirm message <NUM>, as explained in Table <NUM>, to report the measurement result.

Then, the SME of the recipient STA compiles the KPI measurement report <NUM> and sends an RTAKPIMREPORT. request message <NUM> containing measurement results to its MLME. The format of RTAKPIMREPORT. response message is explained in Table <NUM>. Then, the MLME of the recipient STA sends an RTA KPI measurement report frame <NUM> to the originator STA. The format of the RTA KPI measurement report frame is shown in <FIG>. The MLME of the originator STA receives the frame and sends an RTAKPIMREPORT. confirm message <NUM>, as shown in Table <NUM>, to its SME. The SME of the originator then forwards this message <NUM> to provide RTA KPI measurement results to the RTA users.

<FIG> illustrates an example embodiment <NUM> of an RTA KPI measurement request frame format 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 a 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; in this instance it indicates that the management frame is an RTA KPI measurement request frame. An RTA KPIs Measure Method field specifies how to measure the RTA KPIs. Several examples of the format of this field is explained in Section <NUM>. An RTA KPIs Report Method field specifies how to report the RTA KPIs. In at least one embodiment, this field can be implemented as a one-bit indication. When this field is set to a first state (e.g., "<NUM>"), then the report will be transmitted immediately after RTA KPI measurement finishes; otherwise, when this field is set to a second state (e.g., "<NUM>"), then the report will be transmitted later.

<FIG> illustrates an example embodiment <NUM> of an RTA KPI measurement report frame format 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. A TA field contains the address of the STA that transmitted the frame. An Action field indicates the type of management frame, which in this case indicates the management frame is a RTA KPI measure report frame. An RTA KPIs Measurement Report field carries the RTA KPI measurement results. The format of this field depends on the RTA KPI measurement method. Several examples of the format of this field is provided in Section <NUM>.

This section shows an example of measuring channel bandwidth using the RTA KPI measurement procedure.

<FIG> illustrates an example embodiment <NUM> of an RTA KPIs Measure Method field format for channel bandwidth measurement. The figure illustrates the content of RTA KPIs Measure Method field shown in <FIG> when the STA requests to measure channel bandwidth during the RTA KPI measurement procedure. A Measure Code field indicates the type of RTA KPI measurement, which in this case indicates that the RTA KPI measurement is channel bandwidth measurement. A Start Time field indicates the start time of the measurement. An End Time field indicates the end time of the measurement. A Timeout field indicates the longest interval that the STA requires for transmitting a packet to measure the channel condition.

<FIG> illustrates an example embodiment <NUM> of the content for RTA KPIs Measure Report field shown in <FIG> when the STA reports the channel bandwidth measurement result during the RTA KPI measurement procedure. A Measure Code field indicates the type of RTA KPI measurement, in this case indicating that the RTA KPI measurement is channel bandwidth measurement. A Channel bandwidth measurement time field indicates the duration of the measurement. A Best throughput Modulation and Coding Scheme (MCS) field indicates the estimated MCS that the STA can use to achieve its highest throughput. A PER of the best throughput MCS field indicates the Packet Error Rate when using the best throughput MCS for transmission. A Second best throughput MCS field indicates the estimated MCS that the STA can use to achieve the second highest throughput. PER of the Second best throughput MCS field indicates the packet error rate when using the second best throughput MCS for transmission.

A Best probability MCS field indicates the estimated MCS that the STA can use to achieve the lowest packet loss. A PER of Best probability MCS field indicates the packet error rate when using best probability MCS for transmission. An Average channel access delay field indicates the average time that the STA spends on channel contention. A Deviation of channel access delay field indicates the deviation of the time that the STA spends on channel contention. A Transmission time field indicates the transmitting time of the STA during the measurement. An Estimated channel bandwidth field indicates estimated channel bandwidth. By way of example and not limitation, one algorithm for this is as follows: (Estimated channel bandwidth) = (Best throughput MCS) * (Transmission time) / (Channel bandwidth measurement time).

<FIG> and <FIG> illustrates an example embodiment <NUM> of a Channel bandwidth measurement procedure. A STA starts <NUM> the channel bandwidth measurement at the start time. A check is made <NUM> if the STA has a packet in the queue to send before timeout. If there is a packet, the STA sends <NUM> the packet from the queue; otherwise the station generates <NUM> a probe packet. In either case block <NUM> is reached where the STA records the MCS, channel access delay, packet error, and the transmission time of the packet. A check <NUM> determines if the measurement duration has not expired. If we are still in the measurement duration, then execution returns to block <NUM> and the STA continues to send packets for measurement purposes. Otherwise, the duration has expired and execution reaches block <NUM>.

In block <NUM> the STA calculates the best throughput MCS, the second best throughput, and the best probability MCS according to the record during measurement. The best throughput MCS is the MCS having a maximum value of MCS * (<NUM>-PERMCS) where PERMCS is denoted as the packet error rate at MCS. The second best throughput MCS is the MCS having a second maximum value of MCS *(<NUM>-PERMCS). The best probability MCS is the MCS that has a lowest value of PERMCS. The STA also calculates <NUM> in <FIG> the average and deviation of the channel access delay of the packets during measurement. Lastly the STA calculates <NUM> the total transmission time of STA during the measurement and generates <NUM> a channel bandwidth measurement report using the format shown in <FIG>, before the process ends <NUM>.

This section shows an example of measuring packet transmission latency using the RTA KPI measurement procedure.

<FIG> illustrates an example embodiment <NUM> of an RTA KPIs Measure Method field format for packet latency measurement. In the figure is seen the content of RTA KPIs Measure Method field shown in <FIG> when the STA requests to measure the packet transmission latency during the RTA KPI measurement procedure. A Measure Code field indicates the type of RTA KPI measurement; which in this instance indicates that the RTA KPI measurement is a packet latency measurement. A Start Time field indicates the start time of the measurement. An End Time field indicates the end time of the measurement. A Timeout field indicates the longest interval that the STA needs to transmit a packet to measure the channel condition. If the STA does not have a packet to transmit before Timeout, it generates and transmits a probe packet for the purpose of latency measurement as shown in <NUM> of <FIG>,.

<FIG> illustrates an example embodiment <NUM> of an RTA KPI Measurement Report field format for packet latency measurement. In the figure is seen the content of RTA KPIs Measure Report field shown in <FIG> when the STA reports the packet transmission latency measurement result during the RTA KPI measurement procedure. A Measure Code field indicates the type of RTA KPI measurement; which in this case is a packet transmission latency measurement. An Avg transmission latency field indicates the average packet transmission latency during the measurement. A Jitter field indicates the standard deviation of the packet transmission latency during the measurement. A Max transmission latency field indicates the maximum packet transmission latency during the measurement.

<FIG> and <FIG> illustrates an example embodiment <NUM> of a Packet latency measurement procedure. For the sake of simplicity of illustration, it is assumed in this example that the timing of the transmitter STA and the receiver STA are sufficiently well synchronized, such as can be achieved under IEEE <NUM>. 1AS, although the system can be configured to synchronize and/or overcome synchronization issues without departing from the teachings of the present disclosure.

The receiver STA starts <NUM> with the channel bandwidth measurement at the start time and informs <NUM> the transmitter STA to start the measurement by sending a frame similar to <FIG> with the RTA KPIs Measure Method field as shown in <FIG>. A check <NUM> is made to determine if the transmitter STA has a packet in the queue to send before timeout. If there is a packet in the queue, then the transmitter STA prepares <NUM> to send the packet from the queue. Otherwise, if at block <NUM> it is determined that there are no packets in the queue, then the STA generates <NUM> a probe packet to send. Then in either case execution reaches block <NUM> with the transmitter STA sending <NUM> the packet with the current TSF timing stamp embedded in the packet. When the receiver STA receives the packet, it can determine packet transmission latency <NUM> by calculating the difference (delta) between the TSF timing in the packet and the current TSF timing.

A check <NUM> in <FIG> then determines if the measurement is still in progress. If the measurement hasn't yet ended, then execution returns to block <NUM> with the transmitter STA continuing to send packets for measurement purposes. Otherwise, if at block <NUM> it is determined that the measurement duration has expired, then the receiver STA calculates <NUM> the average latency, the jitter and, the maximum latency, after which the STA generates a packet transmission latency measurement report <NUM> using the format as shown in <FIG> before the process ends <NUM>.

This section depicts an example of measuring channel usage in response to performing an RTA KPI measurement procedure.

<FIG> illustrates an example embodiment <NUM> of an RTA KPIs Measure Method field format, shown in <FIG>, for making a channel usage measurement when the STA requests to measure the channel usage during the RTA KPI measurement procedure. A Measure Code field indicates the type of RTA KPI measurement. In this example instance the RTA KPI measurement is a channel usage measurement. A Start Time field indicates the start time of the measurement. An End Time field indicates the end time of the measurement.

<FIG> illustrates an example embodiment <NUM> of the content of RTA KPIs Measure Report field shown in <FIG> when the STA reports the packet transmission latency measurement result during the RTA KPI measurement procedure. A Measure Code field indicates the type of RTA KPI measurement; which here indicates that the RTA KPI measurement is a channel usage measurement. A Channel bandwidth measure time field indicates measurement duration. An Avg NAV time field indicates the average time of the NAV periods during the measurement. A Deviation of NAV time field indicates the deviation of the time of the NAV periods during the measurement. An Avg Clear Channel Assessment (CCA) busy time due to <NUM> packet field indicates the average time of CCA busy periods due to <NUM> packet transmission during the measurement. A Deviation of CCA busy time due to <NUM> packet field indicates the deviation of the time of CCA busy periods due to <NUM> packet transmission during the measurement. An Avg CCA busy time due to non <NUM> packet field indicates the average time of CCA busy periods due to non-<NUM> packet transmission during the measurement. A Deviation of CCA busy time due to non <NUM> packet field indicates the deviation of the time of CCA busy periods due to non-<NUM> packet transmission during the measurement. An Avg channel idle time field indicates the average time of channel idle period during the measurement. A Deviation of channel idle time field indicates the deviation of the time of channel idle period during the measurement.

<FIG> illustrates an example embodiment <NUM> of a Channel usage measurement procedure. The transmitter STA starts <NUM> the channel usage measurement at the start time. The STA stops transmitting packets and monitors <NUM> the channel. The STA records <NUM> the NAV time, the CCA busy time due to <NUM> packets, the CCA busy time due to non <NUM> packets, and channel idle time. At the end time of the measurement, STA calculates <NUM> the average and the deviation of the NAV time, the CCA busy time due to <NUM> packets, the CCA busy time due to non <NUM> packets, and the channel idle time according to the record during measurement. The STA then generates <NUM> a channel usage measurement report using the format as shown in <FIG> and the process ends <NUM>.

This section shows an example of measuring queue status using the RTA KPI measurement procedure.

<FIG> illustrates an example embodiment <NUM> of an RTA KPIs Measure Method field format for queue status measurement. The content of RTA KPIs Measure Method field is shown in <FIG> when the STA requests to measure the queue status during the RTA KPI measurement procedure. A Measure Code field indicates the type of RTA KPI measurement; which in this case indicates that the RTA KPI measurement is a queue status measurement. A Start Time field indicates the start time of the measurement, and an End Time field indicates the end time of the measurement.

<FIG> illustrates an example embodiment <NUM> of an RTA KPI Measurement Report field format for queue status measurement. The content of the RTA KPIs Measure Report field is shown in <FIG> when the STA reports the queue status measurement result during the RTA KPI measurement procedure. A Measure Code field indicates the type of RTA KPI measurement; which in this case indicates that the RTA KPI measurement is a queue status measurement. A Num of Queues field indicates the number of queues whose status is included in this report. Queue status fields <NUM> through N indicate measurement results on queue status for queues <NUM> through N. The status field comprises the following subfields. A Queue type subfield indicates the identification of the queue. A Max queue size subfield indicates the maximum queue size during the measurement. A Min queue size subfield indicates the minimum queue size during the measurement. A Packet arrival rate subfield indicates the rate of the packets enqueued during the measurement. A Packet service rate subfield indicates the rate of the packets dequeued during the measurement. queuing delay subfield indicates the average waiting time of the packets in the queue during the measurement. A Deviation of queuing delay subfield indicates the deviation of the waiting time of the packet in the queue during the measurement.

<FIG> illustrates an example embodiment <NUM> of a Queue status measurement procedure. The STA starts <NUM> the queue status measurement at the start time. The STA records <NUM> maximum queue size, minimum queue size, packet arrival rate, and packet service rate of each queue during the measurement. At the end time of the measurement the STA calculates <NUM> the average and the deviation of queuing delay of the packets during measurement. The STA generates <NUM> a queue status measurement report using the format as shown in <FIG> and the process ends <NUM>.

This section describes an example of traffic analysis using the RTA KPI measurement procedure.

<FIG> illustrates an example embodiment <NUM> of a RTA KPIs Measure Method field format for traffic analysis. The content of RTA KPIs Measure Method field is shown in <FIG> when the STA requests to measure the queue status during the RTA KPI measurement procedure. A Measure Code field indicates the type of RTA KPI measurement; which for instance in this case indicates that the RTA KPI measurement is a queue status measurement. A Start Time field indicates the start time of the measurement. An End Time field indicates the end time of the measurement. A Timeout field indicates the longest interval that the STA needs to transmit a packet to measure channel conditions.

<FIG> illustrates an example embodiment <NUM> of a RTA KPI Measurement Report field format for traffic analysis. Content of the RTA KPIs Measure Report field is shown in <FIG> when the STA reports the traffic analysis result during the RTA KPI measurement procedure. A Measure Code field indicates the type of RTA KPI measurement; which in this example indicates that the RTA KPI measurement is a traffic analysis measurement. A Num of traffic types field indicates the number of traffic types that are analyzed in this report.

A Traffic Type Status field <NUM> through N indicates the analysis result of each traffic type, and has the following subfields. A Traffic type subfield indicates the access category of non-RTA traffic or RTA priority of RTA traffic. retry count subfield indicates the average retry count of the packet during the measurement. A Deviation of retry count subfield indicates the deviation of retry counts of packets during the measurement. contention time subfield indicates the average contention time of the packets during the measurement. A Deviation of contention time subfield indicates the deviation of the contention time of the packets during the measurement. retransmission time subfield indicates the average time between the start of a first retransmission and the end of the last retransmission. A Deviation of retransmission time subfield indicates the deviation of the time between the start of the first retransmission and the end of the last retransmission. A Packet error rate (PER) subfield indicates the probability of packet transmission fails. A Total amount of traffic subfield indicates the total amount of traffic (bytes) during the measurement.

<FIG> illustrates an example embodiment <NUM> of a Traffic analysis procedure. The STA starts <NUM> the traffic analysis at the start time. A check is made <NUM> to determine if the STA has a packet to transmit before timeout. If there is a packet to transmit, then at block <NUM> it transmits the packet and records the AC/the RTA priority, the length, the retry count, the contention time, and the retransmission time of the packet before reaching block <NUM>. If at block <NUM> the STA does not have a packet to transmit before timeout or the STA finishes transmitting one packet, then execution moves from check <NUM> to block <NUM>.

At block <NUM> a check is made whether the measurement duration is still ongoing. If the measurement has not ended, then execution returns to block <NUM> and the STA tries to transmit another packet for measurement purposes. Otherwise, if at block <NUM> it is determined that the measurement period has ended, then at block <NUM> the STA calculates the average and the deviation of the retry count, the contention time and the retransmission time, the packet loss and the total amount of each traffic type. The STA generates <NUM> a traffic analysis report using the format as shown in <FIG>, with the process ending <NUM>.

<FIG> illustrates an example embodiment <NUM> of using measurement results for multi-link transmission, in this case of using the RTA KPI measurement for RTA packet transmission. The figure shows how to use the RTA KPI measurement results to schedule RTA packet transmissions over multiple links (multi-links). In the figure multiple links are shown, here by way of example and not limitation are seen four links, Link1 <NUM>, Link2 <NUM>, Link3 <NUM> and Link4 <NUM>. The figure depicts multiple options, here by way of example and not limitation are seen four options, Option #<NUM><NUM>, Option #<NUM><NUM>, Option #<NUM><NUM>, and Option #<NUM><NUM>. The purpose of this application is to find some multi-link transmission options as shown in the figure. When a STA uses one option to transmit RTA packets generated by an RTA session and the transmission failure rate is lower than the packet loss requirement of the RTA session, then the packet loss of the RTA packets satisfies the requirement and no retransmission is needed.

Each option represents a simultaneous transmission of a duplicated packet over a multi-link. The MCS of the packet transmission on each link is fixed. For example, Option #<NUM><NUM> in the figure represents a simultaneous multi-link transmission of packet <NUM> over Link1 <NUM> using MCS <NUM> and link2 <NUM> using MCS <NUM>. Option #<NUM><NUM> depicts a simultaneous multi-link transmission of packet <NUM> over Link3 <NUM> using MCS7 and over Link4 <NUM> using MCS9. It is possible that the multi-link transmission in an option picks more than two links for transmission as shown in Option #<NUM><NUM> which depicts packet <NUM> in a simultaneous multi-link transmission over Link1 <NUM> using MCS10, over Link <NUM><NUM> using MCS10 and over Link4 <NUM> using MCS9.

It is also possible that duplicated transmission occurs over the same link in an option. For example, Option #<NUM><NUM> in the figure represents a simultaneous multi-link transmission of packet <NUM> over Link1 <NUM> using MCS11, and over Link3 <NUM> using MCS3. It will be seen in the figure that the packet is transmitted multiple times over Link1.

STA is able to estimate the transmission failure rate of using one option by using RTA KPI measurement. The multi-link transmission failure rate of option i, denoted by pfail(optioni) is: <MAT> where Optioni represents the set of links that are used for transmission in Option i (i = <NUM>, <NUM>,. ), pfail(linkj) represents the transmission failure rate at link j (j = <NUM>, <NUM>, <NUM>,. The transmission failure rate at link j can be calculated by: <MAT> where pfail(MCSk,linkj) represents the packet error rate when transmitting a packet using MCS k (k = <NUM>, <NUM>, <NUM>,. ) on link j, and n represents the number of duplicated packet transmissions. The packet error rate can be measured by channel bandwidth measurement as explained in Section <NUM>.

When the packet arrival rate of RTA session, STA is able to schedule packet transmission or polling using the options. Also, the retry limit can be <NUM> since no retransmission is needed.

The enhancements described in the presented technology can be readily implemented within various wireless communication stations and their associated protocols. It should also be appreciated that communication stations 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 data communication. 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.

It will also be appreciated that the computer readable media (memory storing instructions) in these computations systems is "non-transitory", which comprises any and all forms of computer-readable media, with the sole exception being a transitory, propagating signal. Accordingly, the disclosed technology may comprise any form of computer-readable media, including those which are random access (e.g., RAM), require periodic refreshing (e.g., DRAM), those that degrade over time (e.g., EEPROMS, disk media), or that store data for only short periods of time and/or only in the presence of power, with the only limitation being that the term "computer readable media" is not applicable to an electronic signal which is transitory.

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 a 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.

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 which indicate "at least one of" followed by a listing elements, indicates that at least one of these group elements is present, which includes any possible combination of these listed elements as applicable.

References in this specification referring to "an embodiment", "at least one embodiment" or similar embodiment wording indicates that a particular feature, structure, or characteristic described in connection with a described embodiment is included in at least one embodiment of the present disclosure. Thus, these various embodiment phrases are not necessarily all referring to the same embodiment, or to a specific embodiment which differs from all the other embodiments being described. The embodiment phrasing should be construed to mean that the particular features, structures, or characteristics of a given embodiment may be combined in any suitable manner in one or more embodiments of the disclosed apparatus, system or method.

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.

All structural and functional equivalents to the elements of the disclosed embodiments that are known to those of ordinary skill in the art are expressly incorporated herein by reference and are intended to be encompassed by the present claims. No claim element herein is to be construed as a "means plus function" element unless the element is expressly recited using the phrase "means for". No claim element herein is to be construed as a "step plus function" element unless the element is expressly recited using the phrase "step for".

Claim 1:
An apparatus (STA) for wireless communication in a network, the apparatus being a wireless local area network, WLAN, station operating on a WLAN, the apparatus comprising:
(a) a wireless communication circuit for wirelessly communicating over a channel with at least one other WLAN station in its reception area;
(b) a processor coupled to said wireless communication circuit configured for operating on the WLAN; and
(c) a non-transitory memory storing instructions executable by the processor;
(d) wherein said instructions, when executed by the processor, cause the WLAN station:
(i) to operate 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 non-real time packets and distinguishing RTA packets from non-RTA packets;
(ii) to configure an application, APP, layer that is configured to generate and receive application data, and to generate a new RTA session, and has an interface to communicate with a MAC layer management entity, MLME, a network layer that is configured to determine a route to an end-to-end peer WLAN station and a next hop peer WLAN station, a medium access control, MAC, layer that is configured to control wireless media access protocols, and a physical, PHY, layer that is configured to transmit and receive physical signals to the next hop peer WLAN station;
(iii) to generate a request by the APP layer requesting the MAC layer to start a new RTA session between the WLAN station and a recipient WLAN station with a given set of requirements;
(iv) to monitor the channel by the MAC layer and to obtain, by a station management entity, SME, of the WLAN station, key performance indicators, KPIs, to derive a response to the APP layer;
(v) to either accept or reject, by the SME, the request to start a new RTA session by the APP layer according to the RTA session requirements and measured KPIs; and
(vi) to reissue the request by the APP layer to start a new RTA session by the APP layer with adjusted parameters if the request to start a new RTA gets rejected.