Adjustable TXOP mechanism for supporting video transmission in IEEE 802.11e HCCA
© Jansang and Phonphoem; licensee Springer. 2011
Received: 6 April 2011
Accepted: 7 November 2011
Published: 7 November 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.
KeywordsIEEE 802.11e quality of service variable bit rate finite state machine
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
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)
Event table of flow i for ATMV 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.
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.
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.
Event table of flow i for ATMV 2.
3.2 Implementation details
TXOP adjustment based on state machine
PLIST ← Polling List
STATE ← Flow State List
Q← Feeback Queue Size List
TXOP curr ← Current TXOP List
SUM txop ← 0
for p in PLIST do
event ← getEvent(p, Q)
STATE[p] ← evaluateNextState(p,STATE,event)
TXOP curr [p] ← calculateTXOP(p,STATE)
SUM txop ← SUM txop + TXOP curr [p]
if SUM txop >(SI - T cp ) then
for p in PLIST do
TXOP curr [p] ← calculateTXOP(p,S1)
getEvent(p,Q) for ATMV 1
δ1 ← 1, δ2 ← 1.5, δ3 ← 2.5
event ← 0
q ← Q[p]
SI ← getSI()
event ← e1
else if then
event ← e2
else if then
event ← e3
event ← e4
getEvent(p,Q) for ATMV 2
δ1 ← 1, δ2 ← 1.5, δ3 ← 2.5, δ4 ← 4
event ← 0
q ← Q[p]
SI ← getSI()
event ← e1
else if then
event ← e2
else if then
event ← e3
else if then
event ← e4
event ← e5
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.
10 μ s
30 μ s
50 μ s
20 μ s
IFQ (interface queue)
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
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.
The details of tested video clips.
Number of packets
(avg.packet size in byte)
(avg.packet size in byte)
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.
PSNR to MOS conversion.
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
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.
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 expected PSNR S and MOS S of video clips at the sender station.
PSNR S [dB]
40.13 ± 1.48
5.00 ± 0.00
32.44 ± 3.17
3.69 ± 0.59
29.78 ± 3.10
3.23 ± 0.53
27.68 ± 2.14
3.08 ± 0.33
35.83 ± 1.62
4.17 ± 0.39
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.
ATMV 1 and ATVM 2 summarization.
Number of states
4-state finite state machine
5-state finite state machine
High burst arrival
Supported video categories
Gentle walking, Rapid movement
Coefficient factor for bounding the range of the particular event
δ1 = 1
δ1 = 1
δ2 = 1.5
δ2 = 1.5
δ3 = 2.5
δ3 = 2.5
δ4 = 4
Coefficient factor for bounding the allocated queue size
γ1 = 1
γ1 = 1
γ2 = 1.5
γ2 = 1.5
γ3 = 2.5
γ3 = 2.5
γ4 = 3
γ4 = 3
γ5 = 4
Maximum granted TXOP duration for flow i
O(n), where n is a number of active flows in the polling list
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.
This work has been supported by Computer Engineering Graduate School Kasetsart University and Kasetsart University Research and Development Institute (Ref. 5510520000/2555).
- Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications IEEE Standard 802.11 1999.Google Scholar
- 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.Google Scholar
- Sikora T: MPEG digital video-coding standards. Signal Process IEEE Mag 1997, 14(5):82-100. 10.1109/79.618010View ArticleGoogle Scholar
- ITU-T Recommendation G.711. Pulse code modulation (PCM) of voice frequencies 1988.Google Scholar
- 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.Google Scholar
- 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-zView ArticleGoogle Scholar
- 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.010View ArticleGoogle Scholar
- 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.View ArticleGoogle Scholar
- 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.024View ArticleMATHGoogle Scholar
- Seeling P, Fitzek FH, Reisslein M: Video Traces for Network Performance Evaluation. Springer, Berlin; 2006.Google Scholar
- 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.View ArticleGoogle Scholar
- 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.View ArticleGoogle Scholar
- 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.View ArticleGoogle Scholar
- 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.Google Scholar
- 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.View ArticleGoogle Scholar
- FFmpeg2008. [http://ffmpeg.mplayerhq.hu/]
- ITU-T Recommendation BT.500-11. Methodology for the subjective assessment of the quality of television pictures 2002.Google Scholar
- 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.View ArticleGoogle Scholar
- 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.018View ArticleGoogle Scholar
- 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.029View ArticleGoogle Scholar
- 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-0View ArticleGoogle Scholar
- 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.Google Scholar
- 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.Google Scholar
- ITU-T Recommendation G.1010. End-user multimedia QoS categories 2001.Google Scholar
This article is published under license to BioMed Central Ltd. This is an Open Access article distributed under the terms of the Creative Commons Attribution License (http://creativecommons.org/licenses/by/2.0), which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited.