- Open Access
Adjustable TXOP mechanism for supporting video transmission in IEEE 802.11e HCCA
EURASIP Journal on Wireless Communications and Networking volume 2011, Article number: 158 (2011)
The basic mechanism of HCCA (HCF Control Channel Access) has been introduced in IEEE 802.11e standard to support the parameterized QoS by allocating a fixed duration based on the requested TSPEC requirements during the admission control process. However, the variable bit rate (VBR) traffic (e.g., MPEG-2 and MPEG-4 video) cannot be surely supported. In this study, the adjustable TXOP mechanism for supporting video transmission, ATMV, has been proposed. The mechanism adaptively adjusts the TXOP duration according to a finite state machine based on feedback queue size information. The mechanism aims for prompt serving burst packets, generated from the incoming video frames, which finally minimizes the packet delay. Both system performance (mean packet delay, TXOP loss factor, and channel occupancy) and video quality (PSNR and MOS values) have been evaluated from five video clips in three categories by using the network simulator, NS2, with EvalVid toolset. The results reveal that the proposed mechanism performs well for rapid movement video category and adequately supports for other video categories.
To support quality of service (QoS) in IEEE 802.11 , the IEEE 802.11e task group  was setup. The standard has been rectified since 2005 based on its legacy IEEE 802.11 Distributed Coordination Function (DCF) and Point Coordination Function (PCF) modes. Two extended modes are proposed: Enhanced Distributed Channel Access (EDCA) and HCF Controlled Channel Access (HCCA). The EDCA mode is the next generation of DCF mode that aims for supporting prioritized QoS. EDCA raises voice or video traffic priority over the background traffic, such as Web and FTP, by differentiating its contention window (CW) and interframe space (IFS). However, the mechanism cannot guarantee the delay or bandwidth for each prioritized traffic.
While HCCA, enhanced from the PCF mode, provides the parameterized QoS, in HCCA mode, each QoS traffic needs to request for its required traffic specification (TSPEC), which will be granted by Hybrid Coordination Function (HCF). The mechanism can guarantee the QoS for each traffic flow according to its requested TSPEC. However, it is a fixed allocation at the beginning and not be able to support for any traffic fluctuation. Also the admission control has to be implemented for limiting the number of QoS-supported flows.
Constant bit rate (CBR) traffic, such as MPEG-1 video , G.711 , and G.729 voice, is well supported by HCCA mode according to their fixed data rate characteristics. In contrast with the variable bit rate (VBR) traffic, such as MPEG-2, MPEG-4 video, and G.718  voice traffic, for each interval time, the traffic requires various data rates, which differs from the accepted mean data rate. Hence, the VBR traffic might experience long delay and high packet drop rate.
For the admission control in HCCA mode, the accepted flow has been granted by QAP based on current available resources and requested information from QSTA's flow: mean data rate, mean MSDU size, maximum MSDU size, maximum service interval (SI), and physical data rate. QAP maintains a polling list according to the accepted flows. Each flow will receive a fixed TXOP (transmission opportunity) duration for transmission in each polling interval, granted by QAP.
Many researches proposed various mechanisms to support VBR traffic in HCCA mode.  proposed mechanism to adjust TXOP duration based on the remaining queue length feedback information. This mechanism is the most popular among researchers due to its implementation simplicity (only one parameter is needed, while all calculations are deployed only at QAP); While [7, 8] implemented the earliest deadline-driven mechanism for supporting the time-critical packets. In case of video transmission,  utilized the information (I-frame, B-frame and P-frame requirements) from the application layer to suitably mapping packets to appropriate queue.
In this study, the "adjustable TXOP mechanism for supporting video transmission in IEEE 802.11e HCCA", called ATMV, has been proposed. The mechanism is based on the feedback information approach. For an uplink traffic from QSTA to QAP, the mechanism utilizes the queue size field defined in QoS data frame header of the IEEE 802.11e standard. While for a downlink traffic, the queue size information can be directly retrieved from the QAP's queue.
The next section provides details of related work. Section 3 explains the proposed ATMV mechanism. The performance evaluation and discussion have been presented in Section 4. Section 5 concludes this study with the future work suggestion.
2 Related work
In this section, the IEEE 802.11e HCCA mode, video characteristics and previous work (related to the feedback information for estimating next TXOP duration) have been briefly reviewed.
2.1 IEE802.11e HCCA mode
In the reference scheme of IEEE 802.11e HCCA standard , during the contention period, QSTA with a new coming real-time traffic flow requires to send an ADD-TS-Request packet to QAP, asking for TXOP duration reservation for transmitting in the contention free period. The ADD-TS-Request packet contains the traffic specification, called TSPEC, which composes of the required mean data rate (ρ), physical data rate(Rdata), MAC service data unit(MSDU), and maximum service interval (SI). QAP will calculate a feasible minimum SI that can support for new requested and current flows. The mean arrival packets for flow i,N i , can be derived by Equation 1.
where M is the maximum MSDU size, L is a nominal MSDU size, and O is transmission overheads (including poll-packet, ack-packet, and inter-frame space period).
where k is the number of current flows, T is the repetition interval, and Tcp is the contention period.
Based on the above condition, QAP sends back an ADD-TS-Response packet. If the requested information cannot be satisfied, the "reject" result will be issued to the requested QSTA. Otherwise, QAP adds the particular flow i to the polling list and sends back the "accept" result.
2.2 Video characteristics
Usually video traffic characteristics can be dramatically differed by different encoding methods (such as MPEG-2, MPEG-4, and WMV) and video types (such as news, sport, drama, or action movie). Each video traffic composes of 3 types of frames: Intra-frame (I-frame), Bidirectional frame (B-frame) and Predicted-frame (P-frame). An I-frame is the most important frame with the biggest frame size. It contains completed information for a particular snapshot; While B-frame and P-frame are subordinated frames with much smaller in size. The video stream might be transmitted as a GOP (group of pictures) ; for example, GOP(9,3) generates a stream of "I BBPBBPBB I BBP..."frame sequence. Hence, packet sizes in each traffic stream are varied for any time interval.
2.3 Feedback information for estimating the next TXOP duration
By using the feedback queue information from QSTA, QAP can adjust the TXOP duration to serve each QSTA's flow accordingly. An example approach is the Flexible HCF (FHCF) . The FHCF employs the remaining queue length as a feedback information to estimate the granted TXOP duration, adjusted (increase, decrease, or remain unchanged) at the beginning of the SI. This study claims that the mechanism can support the Gaussian distribution mean data rate of the arriving traffic such as certain video streams. To reduce the effect of TXOP prediction error, statistical error values from the past history have been accounted. In , the TXOP duration has been adjusted based on the feedback control theory. The mechanism firstly sets a desired target queue length. After QSTA submits the queue length for each flow, QAP calculates and grants the correspondent TXOP duration to QSTA according to the set target by using the feedback control technique. However, the queue length is not a suitable parameter for TXOP prediction due to various arrival packet sizes. The queue size (in bytes) should be more quantitatively accurate.
Meanwhile, adaptive resource reservation over WLAN (ARROW) [7, 8] proposes a TXOP duration adjustment based on the queue size. Once QAP polls a QSTA, QSTA responses with the queue size of total packets waiting for transmission. The information is piggybacked with the data packet before sending back to QAP. The next TXOP allocation for the particular flow will be calculated based on the received queue size. To minimize the packet waiting time for each traffic flow, the earliest deadline first (EDF) policy has been used for selecting the most critical flow to be the first to transmit.
A feedback approach with cross-layer information has been proposed by . QSTA gathers the frame type, frame inter-arrival time, and bounded delay from the application layer. Then, the collected information will be converted into a number of waiting packets and its residual life time. Then QSTA sends the information back, by using a special mini-frame, to QAP as a feedback for TXOP duration allocation.
3 Proposed mechanism
The estimated TXOP duration directly affects the performance of the overall system. For overestimation, the system is under utilization. In contrast, for the underestimated duration, the particular flow might experience longer delay, more packet drops, and delay variation. In reality, it is quite challenge to correctly estimate the TXOP duration.
Normally, the admission control accepts each flow with mean data rate, converted to the TXOP duration, according to its requested TSPEC. Unfortunately, the accepted TXOP duration may not sufficiently support the fluctuated traffic, i.e., VBR.  suggests that to accommodate the VBR traffic, the admission control should accept each flow with mean data rate plus a small extra value (less than the SD in case of known arrival rate traffic such as playback video). Nonetheless, for unknown arrival distribution traffic such as live video, the system should be adaptively adjusted for each SI.
In our proposed mechanism, the exact TXOP estimation is not the goal. However, the mechanism provides a heuristic approach for allocating the TXOP duration based on the feedback queue size by implementing the finite state machine to dynamically adjust the TXOP duration for each SI.
The mechanism can support various video types with different characteristics in IEEE 802.11e HCCA mode.
3.1 TXOP duration allocation mechanism
For the system implementation point of view, the mechanism can support both uplink and downlink traffic flows. The uplink traffic flow occurs when QSTA transmits data to a station located outside the basic service set (BSS) via QAP; while the downlink traffic flow occurs when a station located outside BSS sends data to QSTA via QAP. For the uplink direction, the mechanism requires the feedback information from QSTA. However, for downlink, which is QAP traffic itself, QAP can extract the required information directly. All traffic flows are separately treated without any distinction.
In the proposed mechanism, QAP independently keeps the state of each traffic flow. Each state changes according to the event defined by the queue size information and certain threshold values. Each event will trigger the state change as defined in the finite state machine.
Firstly, in the admission control process, each flow will be accepted based on Equations 1 and 2. The accepted TXOP duration of each flow becomes the initial value, which will later be adjusted adaptively according to an event specified in the state machine.
In comparison with the ARROW mechanism , the TXOP duration for the next SI will be precisely adjusted as specified by the feedback queue size. We believe that the precise TXOP duration adjustment, based on the feedback information, can only take care of the previous amount of packets already waited for transmission. However, it does not account for new arrival packets that might occur during the next SI.
In our proposed mechanism, the TXOP duration for the next SI will not be adjusted precisely. It will be adjusted according the event and the current state of the particular flow. Therefore, TXOP duration might be granted exactly or with an extra duration.
Mechanism type 1 (ATMV1)
Let q i be the feedback queue size in bytes of flow i for each SI. Let be the mean queue size in bytes of flow i, used as a threshold value for the particular flow. The is calculated from the requested ρ i indicated in the TSPEC of flow i as shown in Equation 4.
Let e k , ∀k = 1, 2, 3, 4, be an event of flow i obtained from the comparison condition between the q i and the threshold value specified in Table 1.
Let δ k be a coefficient factor for bounding the range for the particular event with the value of δ1 = 1, δ2 = 1.5, and δ3 = 2.5. The δ values came from the fine-tuning process of trial-and-error adjustment.
The mechanism aims to cope with burst traffic by allocating various TXOP durations according to the state. A state in the finite state machine specifies the amount of TXOP duration granted for each flow with an extra duration.
In ATMV 1, four states have been defined. Let S j be the state j, ∀j = 1,2,3,4. Let γ j be a coefficient factor for the bounding amount of allocated queue size of state S j , where γ1 = 1, γ2 = 1.5, γ3 = 2.5, and γ4 = 3. State S1 is the minimum amount of granted TXOP duration (according to for any flow i), while S4 gives the maximum burst value.
The state transition is defined as shown in Figure 1. To jump up to the higher state (for example, from S2 to S3) or stay in its current state means that the burst (probably caused by the arrival of a new I-frame) occurs. Hence, the mechanism must provide an extra duration for clearing the occurred burst.
For jumping down from state S2 and S3 (probably caused by a small B-frame or P-frame), the next state becomes S1, because the burst has been served and the system should provide only the minimum amount TXOP duration. Nonetheless, to jump down from the highest state, S4, for all occurrence events, the next state becomes state S3. State S4 implies that there are a high number of packets in the queue (probably caused by an I-frame), which are being serviced in this SI. Thus, the system should remain in state S4. Otherwise, there should be only few left-over packets in the queue waiting for the service, which causes the feedback q i to become a low value. However, there might be new arrival packets, such as following B-or P-frames after the I-frame. The mechanism, therefore, plans to clear up all waiting packets plus new arrivals by remaining in state S3 for overprovisioning.
Normally, the number of packet calculation, N i (as shown in Equation 1), is rounded up to its ceiling value. In the proposed mechanism, the TXOP duration is allocated with an extra duration. If the regular N i has been used, the TXOP duration will become much more overprovisioning.
Hence, the new calculation for the number of packets has been proposed by using the floor value instead of the ceiling value. Let be a new calculated number of packets for flow i. Equations 5 and 6 show the new calculation of the number of packets and TXOP duration used in the proposed mechanism at state S j , respectively.
Mechanism type 2 (ATMV2)
For some types of video transmission, the I-frame might be very huge (upto 20 packets, 1,024 bytes per packet). If all pieces (packets) of the I-frame cannot arrive at the destination in time, then the particular frame will be dropped. Moreover, the following B- and P-frames are also useless if the leading I-frame has been dropped.
From ATMV 1, the allowed maximum burst size is limited to 3 times (γ4 = 3) of the defined in state S4. To cope with such a high burst, one might think that increasing the γ4 value can help. Unfortunately, if the q i is slightly higher than , then the particular flow will be granted with the high γ4 value, which causes low overall system utilization and less number of accepted flows.
Therefore, another mechanism called ATMV 2 has been proposed. A new state S5, along with the γ5 = 4, has been added to cope with such a high burst. However, the system should stay in S5 for only a short period and return to the normal state, S1, as soon as possible due to the usage of high amount of resources. The ATMV 2 finite state machine is shown in Figure 2.
ATMV 2 requires a new event called e5. The e4 and δ4 are also modified by setting the δ4 to 4. Table 2 shows the new event table. The number of packets and TXOP duration for any state S j can be also calculated based on Equations 5 and 6.
3.2 Implementation details
In the simulation, the proposed mechanism has been implemented on QAP as shown in Figure 3. For each SI, at the start of HCCA (shown in Figure 4), QAP starts the process by evaluating the next state S j according to the current state Sj'and the event e i of the particular flow i. Then, QAP polls each flow i with the granted TXOP duration as calculated. During the polling period, the feedback queue size of flow i can be recorded at QAP for generating the event e i for the next SI. Once all flows have been polled, the contention-free period is ended (the end HCCA, shown in Figure 4). Then, QAP waits for the start of HCCA in the next SI to continue the process.
From the Table 3, after the TXOP adjustment mechanism for each flow has been performed (line 6-11), the summation of TXOP requirements of all flows will then be compared with the available resource. If the sum of required durations is less than the available resource, each flow will be granted as calculated. Otherwise, each flow will receive only the committed TXOP duration as specified in S1. The algorithm can be seen in line 13-17.
3.3 Computational complexity
In the proposed mechanism, shown in Table 3, the operations at QAP can be divided into two major parts, TXOP duration calculation part (line 6-11) and checking for resource availability part (line 13-17). The first part composes of four steps for a particular flow i: (1) evaluate an event of the current flow, (2) evaluate a next state, (3) calculate a granted TXOP duration, and (4) calculate the sum of granted TXOP durations. Each step is a constant time, O(1). Let n be the number of active flows in the polling list. Therefore, the computational complexity for the first part is O(n). For checking resource availability shown in the second part, if the condition is valid (not enough resource), QAP will set the TXOP duration for all flows. The complexity in this part becomes O(n). Otherwise, the complexity is O(1). Thus, the overall computational complexity of the proposed mechanism becomes O(n).
4 Performance evaluation and discussion
In this section, the simulation has been described in details. The proposed mechanism is evaluated by using the EvalVid  framework. Various videos have been tested for quality measurements.
4.1 Simulation setup
The network simulator (NS2) , version 2.29, with IEEE 802.11e HCCA patch  is deployed. The HCCA standard has been enhanced by our proposed ATMV mechanism as an extension. To evaluate the video quality, the Evalvid framework is also patched. The admission control, for accepting any video flow, follows the reference scheme.
The testing scenario is composed of one QAP and certain number of QSTAs. All stations operate within a basic service set, infrastructure mode, with the ideal wireless channel assumption, as shown in Figure 5. To concentrate on the HCCA evaluation, all stations operate only in the HCCA mode without the allocated EDCA duration (the contention period, Tcp = 0).
QAP acts as a sink video receiver, while all QSTAs are video generators. Each QSTA will generate only one traffic flow due to the limitation of the adopted HCCA patch. However, for more traffic flows, QSTAs are added as required. To make sure that concurrent video flows occur during the test, each QSTA randomly starts the transmission uniformly within 0 and 3 s. The simulation parameters are listed in Table 6.
In general working environment, both downlink and uplink traffic can occur. For the downlink direction, QAP knows all parameters related to the flow. The queue size can be directly and easily obtained with the exact value before the TXOP duration adjustment. However, for the uplink direction, QAP can only retrieve the queue size information for each flow by observing the picky-backed queue size field in the data packet as a feedback. The received queue size information is not accounted for new arrival packets during the current SI. Therefore, to evaluate our mechanism based on the feedback information, only the uplink direction has been tested.
4.2 Video traffic details
Five video clips have been selected from the open video trace library  for testing. All videos are raw, uncompressed, and encoded in 4:2:0 YUV format with video resolution 352 × 288CIF. The selected videos can be classified  into three categories: slight movement, gentle walking, and rapid movement. The slight movement is represented by Akiyo. Container and Foreman represent the gentle walking category; while, Coastguard and Highway represent the rapid movement category. All videos are 300 frames in length except the Highway that contains 2000 frames. The snapshots of five videos are displayed in Figure 6.
In our simulation, all video clips are encoded into MPEG-4 format with target bit rate 256 Kbps, 30 fps, GOP(9,3) by using the ffmpeg version SVN-r23131.
Normally, an video frame (such as I-and P-frame) is quite large compared to the MTU packet size in the MAC layer. Hence, the fragmentation is required. In our case, each video frame is fragmented into 1,024 byte maximum packet size.
For example, the 300 frame of Akiyo composes of 34 I-frames, 199 B-frames, and 67 P-frames, fragmented into 283, 199, and 79 packets, respectively. The average packet sizes for I-, B-, and P-frames are 956, 179, and 624 bytes, respectively. The overall average packet size (638 bytes) has been used as L i , nominal MSDU in the requested TSPEC. The details of other videos can be seen in Table 7.
4.3 Video quality evaluation
To evaluate the system performance of the proposed mechanism, mean packet delay, TXOP loss factor, and channel occupancy are considered. The mean packet delay measures the average duration of all packets transmitted from a video sender (QSTA) to a video receiver (QAP). The TXOP loss factor is the ratio of unused TXOP duration compared to the allocated TXOP duration assigned by QAP for each flow, . The channel occupancy indicates the system utilization by measuring the reserved TXOP duration of all flows compared to an SI.
For the objective video evaluation, PSNR (Peak Signal to Noise Ratio) has been used. The quality of the video can be measured by the amount of decreasing PSNR at the receiver station compared to PSNR at the sender station.
While MOS (mean opinion score) is one of the popular metrics  for video quality measurement, MOS is represented by the subjective video evaluation, obtained from the perception of trained viewers, which is somehow related to the PSNR value. The relation between PSNR and MOS can be found in  as shown in Table 8.
To integrate the toolset with NS2, a video sender and receiver modules, called MyUDP, located at the sender and receiver stations are added. The sender module, acts as a traffic generator, reads a video trace file from EvalVid toolset and generates a stream of corresponding packets for transmission. Then, packets will be sent out in the NS2 simulation environment. Once packets arrive at the receiver station, the receiver module records their packet time stamps and generates the video trace file to EvalVid toolset for evaluation. The implementation details can be found at .
4.4 Experimental results
To demonstrate the behavior of each mechanism, the allocation and actual usage of TXOP duration in each SI have been shown in Figure 7. The proposed mechanisms, ATMV 1 and ATMV 2, are compared with both basic mechanism (defined in the standard) and ARROW mechanism for a same video clip, e.g., Akiyo.
From Figure 7a, the basic mechanism allocates a constant TXOP duration according to the mean data rate specified in the TSPEC, which might not be enough to serve all waiting packets in queue. Thus, the actual usage is still limited by the fixed allocation. In contrast with ARROW, ATMV 1, and ATMV 2, allocated TXOP durations are varied based on the feedback queue size information. Hence, the traffic stream can be served at the higher data rate according to an allowed certain burst duration as shown in Figure 7b-d. The minimum TXOP allocation of ARROW is a duration for transmitting one packet with the maximum MSDU size, while ATMV 1 and ATMV 2 allow transmission for a duration of . The allocation behavior of each mechanism causes the difference in TXOP loss factor value, details are shown in Figure 8.
The mean packet delay, TXOP loss factor, and channel occupancy are averaged from 20 simulation replications for each experiment.
Figure 8 shows the mean packet delay and TXOP loss factor. However, the mean packet delay of all videos for basic mechanism is not displayed in the graph due to their high delays (> 200 ms). If all concurrent flows are fully served (enough resource), e.g., 7 concurrent flows for Akiyo, the mean packet delay is quite constant. Once the demand is over the available resource, the mean packet delay starts to increase.
For Akiyo (Figure 8a), representing the slight movement video category, the mean packet delay for the ATMV 1 and ATMV 2 are slightly higher than ARROW, but both TXOP loss factors are lower than ARROW (6% for ATMV 1 and 8% for ATMV 2). ARROW mechanism, with high overprovision allocation, might cause the high TXOP loss factor for slight change in content among video frames.
For Container (Figure 8b), representing the gentle walking movement video category, the mean packet delay of ARROW is better than both proposed mechanisms. However, the TXOP loss factor of ARROW is still higher but closed to ATMV 1 and ATMV 2, because the change of frame content has been increased, compared with Akiyo.
The results of Foreman (Figure 8c) is quite interesting. Even though it has been classified as a gentle walking movement, it contains two major scenes: the still shot with slight movement scene and a panning high movement scene. With ATMV 1 allocation mechanism, the video cannot be well served. However, ATMV 2 and ARROW mechanisms provide enough overprovision to support the traffic with closed TXOP loss factor (2-3% differences).
For Coastguard and Highway (Figure 8d, e), representing the rapid movement video category, the mean packet delay of ATMV 1 is higher than others. However, ATMV 2 shows the lowest values for both mean packet delay and TXOP loss factor.
The channel occupancy for all video clips increases as the number of concurrent flows increases, as shown in Figure 9. All mechanisms reveal no significant difference in the channel occupancy metric.
For different traffic conditions, both proposed mechanisms grant the TXOP duration based on the feedback queue size of a flow. In case of high or burst traffic, QAP will allocate TXOP duration as high amount as request, bounded by the coefficient factor of the evaluated state, such as state S4 in ATMV 1 or state S5 in ATMV 2. However, in light traffic condition, if the required feedback queue size is less than the committed average queue size , QAP grants the TXOP duration as the boundary of the state S1. The amount of granted duration is only a little over provision from the committed traffic specification (TSPEC) of the particular flow, which causes low TXOP loss factor.
The video quality has been evaluated by the PSNR and MOS values extracted from EvalVid toolset. Both values are calculated at the sender station (e.g., QSTA) as details in Section 4.3 and be kept as reference values. Let PSNR S and MOS S be the PSNR and MOS at the sender station, while PSNR R and MOS R be the PSNR and MOS at the receiver station. Figure 10 shows PSNR and its correspondent MOS for all video clips from the first to last frame. The expected values for PSNR and MOS are displayed in Table 9.
Once the video clip has been received at the receiver station, the expected PSNR and MOS values are recalculated as PSNR R and MOS R . In the simulation, at the receiver station, the video playout buffer is set to 400 ms according to the ITU-T G.1010 , the worst case of one-way delay for video medium. If received packets for the corresponding frames arrive after 400 ms, those packets will not be accounted for the particular video frame reconstruction. Then, PSNR R and MOS R are compared to previous reference values, PSNR S and MOS S . The equality of the PSNR and MOS values means that the video quality has been preserved. However, in real situation, PSNR R and MOS R are normally less than PSNR S and MOS S due to loss or delayed packets, which might cause the video quality to be degraded. Figure 11 shows the expected PSNR R and MOS R values of all received flows, which can be compared with PSNR S and MOS S , shown in Table 9.
For Akiyo (Figure 11a), ATMV 1, ATMV 2, and ARROW mechanisms reveal the same PSNR (PSNR R = PSNR S ) and MOS (MOS R = MOS S ) values for the case of less than or equal to 7 concurrent flows. For 8 flows, ATMV 1 is the only mechanism that can maintain the same quality. Normally, for more than 7 flows, the PSNR R and MOS R of all mechanisms (except the basic mechanism) start to degrade due to the not enough available resource. Note that, for the basic mechanism, the PSNR R and MOS R are constant at a low value (low quality) due to its non-adaptive characteristic.
For Container (Figure 11b), ATMV 2 and ARROW mechanisms show the same values as references for up to 7 concurrent flows. In case of ATMV 1, the video quality is quite the same with small degradation of 1 dB for PSNR R and 0.17 for MOS R values compared to ATMV 2 and ARROW. For Foreman (Figure 11c), ATMV 2 and ARROW mechanisms show the same values as references for up to 5 concurrent flows; while ATMV 1 degraded with 5 dB in PSNR R , and 0.8 in MOS R .
For Coastguard (Figure 11d), ATMV 2 and ARROW mechanisms show the same values as references for up to 5 concurrent flows. The 4 dB in PSNR R and 0.87 MOS R are shown for the case of ATMV 1. For Highway (Figure 11e), both values are as same as references for up to 7 concurrent flows. ATMV 1 has been degraded with the values closed to the basic mechanism.
For real implementation, videos sent from different QS-TAs at the same time may belong to different categories. Moreover, within the same QSTA, different flows (sessions) might also be classified into different categories. In case of known priori video category, QAP may be implemented by adding selective mechanism to call appropriate functions (i.e., "getEvent" and "evaluateNextState" from Table 3, line 7-8); for example, QAP will select "getEvent" (from Table 4) of the ATMV 1 once the slightly movement video flow is evaluated, while "getEvent" (from Table 5) of the ATMV 2 will be called if the rapid movement video session occurs. However, in case of unknown video category, QAP will select a default mechanism (i.e., ATMV 1) for serving that particular flow. If QAP finds that the monitored flow falls into the state S4 for many consecutive SIs, it means that the flow is high burst, which should be adjusted to ATMV 2. Therefore, the proposed ATMV 1 and ATMV 2 mechanisms can be simultaneously implemented for serving each flow separately.
The feedback mechanism called ATMV has been proposed to support video transmission in IEEE 802.11e HCCA at QAP by adjusting the TXOP duration. The feedback is based on the queue size information in QSTA. The mechanism aims for quick response to serve the burst packets generated from the incoming video frames. The adjustment algorithm follows the proposed 4-state and 5-state finite state machines for ATMV 1 and ATMV 2, respectively. Both proposed mechanisms are compared with the (standard) basic mechanism and ARROW mechanism, tested by 5 video clips classified into 3 video categories: the slight movement, gentle walking movement, and rapid movement.
The results show that both proposed mechanisms, including ARROW, outperform the basic mechanism in terms of the system performance and video quality for all video categories.
ATMV 1 is suitable for the slight movement video and can support up to 8 concurrent flows. However, the video quality has been degraded with other video categories.
ATMV 2 and ARROW are suitable for all video categories with non-degradation quality and can support up to 7, 5-6, and 5 concurrent flows for the slight movement, gentle walking movement, and rapid movement, respectively. However, the ATMV 2 shows the best performance in terms of mean packet delay and TXOP loss factor for rapid movement category. For the slight movement, ATMV 2 reveals better TXOP loss factor with small higher delay (but still under 100 ms). Finally, for the gentle walking category, TXOP loss factor for both mechanisms are quite the same, While ATMV 2 and ARROW take turn outperforming each other in terms of mean packet delay. However, the packet delay of both mechanisms is less than 120 ms.
The summarization of proposed mechanisms, ATMV1 and ATMV2, is shown in Table 10.
Note that the reference admission control process admits each flow based on the mean TXOP duration, which is not designed for the dynamic allocation. Hence, for future work, the admission control process needs to be modified for accounting the ATMV dynamic mechanism behavior. Obviously, the number of accepted flows of the modified admission control might be slightly decreased, but the video quality of accepted video flows is highly preserved.
To better tuning the ATMV mechanism, the coefficient factor for bounding amount of allocated queue size of each state in the finite state machine should be dynamically adjusted according to the changing of major scenes in the video. We foresee that system is able to support unknown video categories or mixed contents in one video clip.
In addition, the TXOP allocation mechanism located at QAP should account for maintaining the quality of accepted flows that might be degraded by the noisy channel environment.
Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications IEEE Standard 802.11 1999.
IEEE Std. 802.11e-2005, Part 11: wireless LAN medium access control (MAC) and physical layer (PHY) specifications, amendment 8: medium access control (MAC) quality of service enhancements 2005.
Sikora T: MPEG digital video-coding standards. Signal Process IEEE Mag 1997, 14(5):82-100. 10.1109/79.618010
ITU-T Recommendation G.711. Pulse code modulation (PCM) of voice frequencies 1988.
ITU-T Recommendation G.718. Frame error robust narrowband and wideband embedded variable bit-rate coding of speech and audio from 8-32 Kb/s 2008.
Ansel P, Ni Q, Turletti T: FHCF: a simple and efficient scheduling scheme for IEEE 802.11e wireless LAN. Mob Netw Appl 2006, 11(3):391-403. 10.1007/s11036-006-5191-z
Passas N, Skyrianoglou D, Mouziouras P: Prioritized support of different traffic classes in IEEE 802.11e wireless LANs. Comput Commun 2006, 29(15):2867-2880. 10.1016/j.comcom.2006.03.010
Skyrianoglou D, Passas N, Salkintzis A: ARROW: an efficient traffic scheduling algorithm for IEEE 802.11e HCCA. IEEE Trans Wirel Commun 2006, 5(12):3558-3567.
Kim SM, Cho YJ: Channel time allocation scheme based on feedback information in IEEE 802.11e wireless LANs. Comput Netw 2007, 51(10):2771-2787. 10.1016/j.comnet.2006.11.024
Seeling P, Fitzek FH, Reisslein M: Video Traces for Network Performance Evaluation. Springer, Berlin; 2006.
Boggia G, Camarda P, Grieco L, Mascolo S: Feedback-based control for providing real-time services with the 802.11e MAC. IEEE/ACM Trans Netw 2007, 15(2):323-333.
Jansang A, Phonphoem A, Paillassa B: Analytical Model for Expected Packet Delay Evaluation in IEEE 802.11e. In Proceedings of the 2009 WRI International Conference on Communications and Mobile Computing. Volume 2. IEEE Computer Society, Washington; 2009:344-348.
Klaue J, Rathke B, Wolisz A: EvalVid--a framework for video transmission and quality evaluation. In Proceeding of the 13th International Conference on Modelling Techniques and Tools for Computer Performance Evaluation, Urbana, IL, USA 2003, 255-272.
The Network Simulator--ns-21999. [http://www.isi.edu/nsnam/ns/]
Cicconetti C, Lenzini L, Mingozzi E, Stea G: A Software Architecture for Simulating IEEE 802.11e HCCA. In Proceedings of the 3rd International Workshop on Internet Performance, Simulation, Monitoring and Measurement, Warsaw, Poland 2005, 97-104.
YUV video sequences (CIF)[http://www2.tkn.tu-berlin.de/research/evalvid/cif.html]
Khan A, Sun L, Ifeachor EC: Content-based video quality prediction for MPEG4 video streaming over wireless networks. J Multimed 2009, 4(4):228-239.
ITU-T Recommendation BT.500-11. Methodology for the subjective assessment of the quality of television pictures 2002.
Abdel-Hady M, Ward R: A framework for evaluating video transmission over wireless ad hoc networks. In Proceedings of IEEE Pacific Rim Conference on Communications, Computers and Signal Processing 2007 (PacRim2007), Victoria, B.C., Canada 78-81.
Choi M, Samokhina M, Moklyuk K, Choi S, Heo J, Oh SJ: VPAL: video packet adaptation layer for reliable video multicast over IEEE 802.11n WLAN. Comput Commun 2010, 33(18):2271-2281. 10.1016/j.comcom.2010.06.018
Ke CH, Chilamkurti N: A new framework for MPEG video delivery over heterogeneous networks. Comput Commun 2008, 31(11):2656-2668. 10.1016/j.comcom.2008.02.029
Lie A, Klaue J: Evalvid-RA: trace driven simulation of rate adaptive MPEG-4 VBR video. Multimed Syst 2008, 14: 33-50. 10.1007/s00530-007-0110-0
Venkataraman M, Chatterjee M, Chattopadhyay S: Evaluating Quality of Experience for Streaming Video in Real Time. In Proceedings of IEEE Global Telecommunications Conference 2009 (GLOBECOM2009), Honolulu, Hawaii, USA 1-6.
Ke CH, Shieh CK, Hwang WS, Ziviani A: An evaluation framework for more realistic simulations of MPEG video transmission. J Inf Sci Eng 2008, 24(2):425-440.
ITU-T Recommendation G.1010. End-user multimedia QoS categories 2001.
This work has been supported by Computer Engineering Graduate School Kasetsart University and Kasetsart University Research and Development Institute (Ref. 5510520000/2555).
The authors declare that they have no competing interests.
Authors’ original submitted files for images
Below are the links to the authors’ original submitted files for images.
About this article
Cite this article
Jansang, A., Phonphoem, A. Adjustable TXOP mechanism for supporting video transmission in IEEE 802.11e HCCA. J Wireless Com Network 2011, 158 (2011). https://doi.org/10.1186/1687-1499-2011-158
- IEEE 802.11e
- quality of service
- variable bit rate
- finite state machine