• 沒有找到結果。

Chapter 3 Resource Allocation for Real-Time Traffic in IEEE 802.11e WLANs

3.5. Simulation Results

The PHY and MAC parameters and all related information used in simulations are shown in Table 3.1. Note that the sizes of QoS-ACK and QoS-Poll in the table only include the sizes of MAC header and CRC overhead. The simulations are performed using Matlab on a PC with an Intel (R) Core (TM) 2 Quad CPU Q9550 operated at 2.83GHz with 3072 MB of RAM.

Traffic is delivered from QSTAs to AP and the contention-free period occupies the whole SI. We investigate three types of QSTA in the simulations. Each type of QSTA is assumed to be attached with two real-time traffic flows. Real traffic traces, developed by [54], are used for Type I and Type II QSTAs in our simulations. A Type III QSTA is attached with two flows, one with constant packet size and the other with variable packet size. The arrival processes are assumed to be Poisson. For flows which generate variable-size packets, the packet size varies according to exponential distribution. The length of each traffic flow lasts for one hour. The detailed information of traffic flows, including QoS

requirements and traffic parameters, are described in Table 3.3. For each flow, the mean  and the variance 2 of traffic arrivals in one SI can be calculated from the mean data rate  and the variance

of frame size 2 provided in the trace file or derived using the technique described in Chapter 3.1.

The calculated  and 2 of each flow are shown in the last two rows of Table 3.2. Note that Type III QSTA is included to study the effect of aggregating flows with identical QoS requirements

Table 3.1 Related parameters used in simulations.

PHY and MAC parameters

SIFS 10 us

MAC Header size 32 bytes

CRC size 4 bytes

QoS-ACK frame size 16 bytes

QoS CF-Poll frame size 36 bytes

PLCP Header Length 4 bytes

PLCP Preamble length 20 bytes

PHY rate(R) 11 Mbps

Minimum PHY rate (Rmin) 2 Mbps

Transmission time for different header and per-packet overhead

PLCP Preamble and Header (tPLCP) 96 μs

Table 3.2 TSPECs of traffic flows attached to Type I, Type II and Type III QSTAs.

Type of QSTA Type I Type II Type III

Attached Traffic Model Jurassic Park I Lecture

Camera Mr. Bean Office

Camera Poisson

(Constant) Poisson/EXP (Variable)

Packet Loss Rate Requirement (PL) 0.01 0.001 0.01 0.001 0.01 0.01 Maximum Service Interval (SImax) 80(ms) 160(ms) 80(ms) 160(ms) 80(ms) 80(ms) Mean Data Rate ( ) 268k(bps) 210k(bps) 184k(bps) 112k(bps) 500k(bps) 500k(bps) Nominal MSDU size (L) 1339 (bytes) 1048 (bytes) 920(bytes) 558(bytes) 1000 (bytes) 1000 (bytes) Variance of Frame Size ( ) 2 1273237 828990 801216 1604797 1000000 1000000 Frame inter-arrival time 40 (ms) Exponential(LSI)

Scheduled Service Interval (SI) 80 (ms)

Calculated Mean per SI ( ) 2680 (bytes) 2100 (bytes) 1840 (bytes) 1120 (bytes) 4000 (bytes) 4000 (bytes) Calculated Variance per SI ( ) 2 2546474 1657980 1602432 3209594 5000000 10000000

In Table 3.3, we compare packet loss probabilities after all data are delivered. Since there is only one trace for each video, we conducted simulations with 1,000 different starting positions to collect the 99%

confidence intervals. The symbol a b in Table 3.3 means the 99% confidence interval is given by (ab a, b). Transmission error is also considered for our proposed scheme. The frame transmission error

probability is set to be 0.5 10 3. The packet loss probability considering transmission error is marked with * and shown in the last row of In Table 3.3. According to the results, our proposed scheme can meet the individual QoS requirements requested by traffic flows whether or not there is aggregation of flows with identical QoS requirements. Moreover, no matter which TXOP allocation scheme is adopted, our proposed proportional-loss fair service scheduler can achieve the goal of maintaining the ratio of actual packet loss probabilities as that of the requested values. For example, the ratios of the actual packet loss probabilities of

Jurassic Park I and Lecture Camera for the sample scheduler, the RVAC scheme, the scheme proposed by Lee and Huang (2008), our proposed scheme, and our proposed scheme with transmission error are, respectively, 0.1857:0.0186, 0.0008:0.0001, 0.0052:0.0005, 0.0099:0.0010, and 0.0100:0.0010, which are all very close to the ratio of the requested packet loss probabilities, i.e., 0.01:0.001. Another important observation is that the results of our proposed scheme are satisfactory even for a frame error rate of 0.5 10 3. This implies that, to cope with transmission errors, one need only select an appropriate feasible physical transmission rate so that the probability of transmission error is sufficiently smaller than the requested packet loss probability. The average execution times of the proposed proportional-loss fair service scheduler are 0.31, 0.32, and 0.52 (ms) for Types I, II, and III QSTA, respectively. These numbers are much smaller than SI (80ms) and, therefore, the scheduler is feasible for real systems.

Table 3.3 The 99% confidence intervals of packet loss probability of flows attached to Type I, Type II and Type III QSTAs.

Packet Loss Probability (PL)

Type I QSTA Type II QSTA Type III QSTA

Jurassic Park I Lecture Camera Mr. Bean Office Camera Poisson

(Constant) Poisson/EXP

We also record the running packet loss probabilities of traffic flows attached to Type I QSTA for all investigated schemes. Here, the running packet loss probability for flow fi j, up to the nth SI is given by Li j,

 

n Ai j,

 

n . For the sample scheduler, as shown in Fig. 3.4, the running packet loss probabilities of all simulated traffic flows are more than 10 times larger than their requested levels for most of the time. For TXOP allocation schemes which consider packet loss probability, we compare the sample paths of each traffic flow attached to Type I QSTA . The results are illustrated in Fig. 3.4 and Fig. 3.5. It can be seen that the long-term packet loss probability meets the requirement for all the investigated schemes. However, our proposed scheme is the most efficient one because it allocates the smallest TXOP durations to QSTAs. To compare the bandwidth efficiency of the investigated schemes, we list the over-allocation ratios in Table 3.4. Here, the over-allocation ratio is defined as the ratio of unused TXOP duration to the allocated TXOP duration. As one can see, our proposed scheme has the least over-allocation ratio among the investigated schemes which meet QoS requirements. In other words, compared with other static TXOP allocation algorithms, our proposed scheme reduces over-allocation ratio and hence improves bandwidth utilization without sacrificing QoS guarantee.

0 5 10 15 20 25 30 35 40 45 0.010

0.05 0.1 0.15 0.2 0.25 0.3 0.35

Simulation Time (103 SI)

Packet Loss Probability

Packet Loss Probability of Jurassic Park I

Our proposed scheme

Scheme of (Lee and Huang,2008) RVAC

Fig. 3.4 Running packet loss probabilities of Jurassic Park I attached to Type I QSTA.

0 5 10 15 20 25 30 35 40 45 0.0010

0.005 0.01 0.015 0.02 0.025 0.030

Simulation Time (103 SI)

Packet Loss Probability

Packet Loss Probability of Lecture Camera

Our proposed scheme

Scheme of (Lee and Huang,2008) RVAC

Fig. 3.5 Running packet loss probabilities of Lecture Camera attached to Type I QSTA.

0 5 10 15 20 25 30 35 40 45 0.0010

0.005 0.01 0.015 0.02 0.025 0.030

Simulation Time (103 SI)

Packet Loss Probability

Packet Loss Probability of Lecture Camera

Our proposed scheme

Scheme of (Lee and Huang,2008) RVAC

Fig. 3.6 Running packet loss probabilities of Lecture Camera attached to Type I QSTA.

Table 3.4 Over-allocation Ratio of Type I, Type II and Type III QSTAs.

Over-allocation Ratio

Type I QSTA Type II QSTA Type III QSTA

Sample scheduler 11.58% 15.51% 4.56%

RVAC 52.46% 52.11% 24.75%

Scheme of Lee and Huang (2008) 45.64% 48.49% 16.54%

Our proposed scheme 41.52% 44.87% 16.54%

Our proposed scheme* 41.50% 44.86% 16.03%

Fig. 3.7 compares the admissible regions of the investigated TXOP allocation schemes. For a particular scheme, the system can accommodate x Type I QSTAs and y Type II QSTAs with QoS guarantee if (x, y) falls in the triangle formed by the x-axis, y-axis, and the curve labeled for the scheme. Our proposed scheme allows 8% and 18% more QSTAs to be admitted than the scheme proposed by Lee and Huang (2008) and RVAC, respectively.

In the second part of simulations, the circular round robin is adopted as the polling scheme so that all QSTAs are treated equally. In other words, the polling order in the i SI is QSTA th i (mod 10), QSTA i1 (mod 10) …, and QSTA i9 (mod 10). As a consequence, it suffices to consider the performance of one specific QSTA. The results are shown in Table 3.5. Note that, being a dynamic scheme, the PRO-HCCA has to calculate TXOP allocations at the beginning of each SI which is an overhead to the HC. According to our simulation results, the PRO-HCCA achieves smaller average transmission delay than our proposed scheme because it allocates TXOPs to QSTAs dynamically based on the queue status. However, compared with PRO-HCCA, our proposed scheme has smaller delay

jitter, which is defined as the difference between maximum and minimum delays in this chapter. The reason is that the TXOP duration allocated by our proposed scheme is a constant which equals 7.6 ms while that allocated by PRO-HCCA is dynamic and can be larger than 7.6 ms. As a result, the maximum delay of PRO-HCCA is larger than that of our proposed scheme, which implies the delay jitter of our proposed scheme is smaller because the minimum delays are roughly the same. Moreover, our proposed scheme guarantees packet loss probability requirements while PRO-HCCA does not. For PRO-HCCA, the packet loss probability of Lecture Camera is equal to 0.0028, which is greater than its requirement 0.001. If our proposed proportional-loss fair service scheduler is combined with PRO-HCCA, then packet loss probabilities become 0.0075 and 0.0007 for Jurassic Park I and Lecture Camera, respectively. The average delay and delay jitter change slightly. The average delays are 0.0261 (sec) and 0.0289 (sec) and the delay jitters are 0.0785 (sec) and 0.1591 (sec) for Jurassic Park I and Lecture Camera, respectively.

0 1 2 3 4 5 6 7 8 9 10 0

2 4 6 8 10 12 14

Number of Type I QSTA

Number of Type II QSTA

Admissible Region

Our proposed scheme

Scheme of (Lee and Huang,2008) RVAC

Fig. 3.7 Comparison of admissible region

Table 3.5 Performance comparison for our proposed scheme and PRO-HCCA.

Average Transmission delay (sec) Delay Jitter (sec) Packet loss probability Jurassic Park I Lecture Camera Jurassic Park I Lecture Camera Jurassic Park I Lecture Camera PRO-HCCA 0.0262 0.0287 0.0786 0.1589 0.0046 0.0028

Our proposed scheme 0.0274 0.0327 0.0757 0.1562 0.0099 0.0010

Chapter 4

Resource Allocation for Real-Time and Non-Real-Time Traffic in

OFDMA-Based Systems

In this chapter, we present a resource allocation algorithm for OFDMA-based systems which handles both real-time and non-real-time traffic. For real-time traffic, the QoS requirements are specified with delay bound and loss probability. The resource allocation problem is formulated as one which maximizes system throughput subject to the constraint that the bandwidth allocated to a flow is no less than its minimum requested bandwidth, a value computed based on loss probability requirement and running loss probability. A user-level proportional-loss scheduler is adopted to determine the resource share for flows attached to the same subscriber station (SS). In case the available resource is not sufficient to provide every flow its minimum requested bandwidth, we maximize the amount of real-time traffic transmitted subject to the constraint that the bandwidth

allocated to an SS is no greater than the sum of minimum requested bandwidths of all flows attached to it. Moreover, a pre-processor is added to maximize the number of real-time flows attached to each SS that meet their QoS requirements. We show that, in any frame, the proposed proportional-loss scheduler guarantees QoS if there is any scheduler which guarantees QoS.

Simulation results reveal that our proposed algorithm performs better than previous works.

4.1. System Model

The system model investigated in this chapter is the same as that presented in Chapter 2.2 and thus is not repeated here.

4.2. The Proposed Scheme

In this chapter, we present a resource allocation scheme which considers both delay bound and loss probability requirements requested by real-time traffic flows. As shown in Fig. 4.1, the minimum requested bandwidths of real-time flows are computed, summed for each SS, and then used together with queue occupancy as constraints in resource allocation. After the solution is obtained, a PL scheduler is adopted to determine how multiple real-time traffic flows attached to the same SS share the allocated bandwidth. In case the available resource is not sufficient to provide each flow its minimum requested bandwidth, a pre-processor is required to maximize the number of real-time flows attached to each SS that meet their QoS requirements. We describe calculation of minimum requested bandwidth, resource allocation, PL scheduler, and pre-processor separately

below.

SSn Minimum requested bandwidth calculation Resource allocation for maximum-throughput with QoS constraints

 

Fig. 4.1 Architecture of the proposed scheme.

The minimum requested bandwidth

PP t , then the running loss probability is still greater than or equal to the pre-defined level

,

Lemma 4.1. It holds that

The minimum requested bandwidth for all cases is summarized in Table 4.1. Note that the actual

allocated bandwidth could be different from Rn k*,

 

t . After obtaining Rn k*,

 

t for all k, 1 k Kn,

Resource allocation for maximum-throughput with QoS constraints

As described in Problem P1, the proposed resource allocation algorithm maximizes system

throughput while providing QoS guarantee to real-time traffic flows. In problem P1, we let

 

* 0

R tn  for all SS nNRT. As in previous section, we use rn m,

 

t to denote the maximum

achievable transmission rate on the mth sub-channel for SS n in the tth frame. The variable

Problem P1 can be solved by some integer linear programming algorithm [55]. If there is no feasible solution, meaning that the available resource is smaller than the summation of all minimum requested bandwidths, we set xn m,

 

t 0, for all nNRT, 1 m M  , and solve a modified problem, called problem P2, which is basically the same as problem P1 except that the constraint shown in equation (30) is replaced by 0 M1 n m,

 

n m,

 

n*

 

,

m x t r t R t n

   . Note that the

solution of Problem P2 always exists because xn m,

 

t 0, for all n , 1 m M  is one feasible solution. Unfortunately, the complexity of integer linear programming is NP-complete [56]. One possible strategy to mitigate the computational complexity is to set un m, =rn m,

 

t for all n , 1 m M  , and conduct the matrix-based scheduling algorithm for one or two rounds. In the first

round, we only consider SSs contained in  , assuming that the queue occupancy of SS n is equal RT

to R tn*

 

. The algorithm ends if the resource is exhausted in the first round. Otherwise, the second round is performed to allocate the remaining resource to all SSs, assuming the queue

occupancy of SS n is equal to Q tn

 

R tn*

 

. According to the analysis provided in Chapter 2.2, the computational complexity of the modified matrix-based scheduling algorithm is

2 2

2 2

(max( , ))

O M     MM .

Let yn m,

 

t be the solution obtained either from integer linear programming or matrix-based scheduling algorithm. We have

 

1 ,

 

,

 

R tR t . In this case, we need a user-level resource allocation algorithm for the attached flows to share the allocated bandwidth. In the following sub-section, we define the PL scheduler to solve this problem.

Proportional-loss (PL) scheduler

Consider SS n and assume that it is attached with multiple real-time traffic flows. Define

three disjoint sets U , Z U , and P UA such that flow fn k, is contained in U , Z U , or P U iff A

subject to proposed PL scheduler achieves min-max optimality, as stated in Lemma 4.2. In Theorem 4.3, we show that if there exists a scheduler which guarantees the loss probability requirements, so does the PL scheduler.

Lemma 4.2. Given R tn

 

0, Sn k,

 

t1 , Ln k,

 

t1 , and

Qn km, [ ]t

mDn k,1, 1 k Kn, the proposed PL scheduler minimizes the maximum normalized running loss probability of all the traffic flows attached to SSn.

Theorem 4.3. Given R tn

 

0, Sn k,

 

t1 , Ln k,

 

t1 , and

Qn km, [ ]t

mDn k,1, 1 k Kn, if there exists a scheduler which can guarantee the loss probability requirements of all the Kn traffic flows, so can the PL scheduler.

Theorem 4.3 provides the answer why the PL scheduler is proposed as the user-level resource

allocation algorithm. Define [R tn

 

, Sn k,

 

t1 , Ln k,

 

t1 , {Qn km, [ ]}t Dmn k,1 (1 k Kn)] as the state of SS n at the beginning of the t frame. Given the state at the beginning of the first frame, the th PL scheduler is preferred over other schedulers in the first frame, according to Theorem 4.3.

Assume that the PL scheduler is adopted in the first frame. The state at the beginning of the second frame is determined once traffic arrivals at the beginning of the second frame is known and Rn

 

2

is provided. Based on Theorem 4.3 again, the PL scheduler is still the preferred scheduler in the

second frame. The arguments can be applied to all frames.

In the rest of this sub-section, we present a realization of the PL scheduler. Again, consider

SS n in the tth frame and assume that R tn

 

is given. We need to determine Rn k,

 

t , 1 k Kn, so that equations (32) and (33) are satisfied.

Lemma 4.4. If R tn

 

R tn*

 

, equations (32) and (33) are satisfied for Rn k,

 

tR*n k,

 

t , 1 k Kn.

gradually, keeping equations (32) satisfied, until

 

n1 ,

 

(no solution is found earlier than Event 1), where

           

other events to happen can be similarly determined. After all flows are placed in the correct sets, the solution can be obtained by solving equations (32) and (33). To summarize, we repeatedly check the inequality shown in equation (35). If it holds, flow fn k,* is moved from one set to

and

All flows are placed in their correct sets once the inequality shown in (35) becomes false. The

solution can then be obtained as follows. Set Rn k,

 

t 0 if fn k,UZ or Qn k,

 

t if fn k,UA. For fn k,UP1UP2, Rn k,

 

t can be obtained by Rn k,

 

thn k,

P t PnF

 

n k, ;t

, where PnF

 

t represents the normalized running loss probability for any fn k,UP1UP2 at the end of the t th frame and is derived in the Appendix A.

Case 2 R tn

 

R tn*

 

Case 2 is similar to Case 1, except that we need to decrease Rn k,

 

t for fn k,UP1UP2UA. For this case, we repeatedly check the inequality shown in (38) until it becomes false. If it is true, flow fn k,* is moved from U to A UP2, from UP2 to U , or from P1 U to P1 U . Z

After the inequality shown in (38) becomes false, the solution can be obtained as follows. Set

,

 

0

Rn k t  if fn k,UZ or Qn k,

 

t if fn k,UA. For fn k,UP1UP2, Rn k,

 

t can be obtained

by Rn k,

 

thn k,

P t PnF

 

n k, ;t

. The pseudo code of the above realization of the PL scheduler is provided in the Appendix B.

Note that, for Case 1, the maximum number of iterations needed for the PL scheduler is 3K , n which happens when each flow is moved from U to Z U , from P1 U to P1 UP2, and then from UP2 to U . In each iteration, the computational complexity is (A O Kn) . Therefore, the total computational complexity is O K( n2). Obviously, the complexity for Case 2 is the same.

Pre-processor

Assume that R tn

 

R t*n

 

(i.e., Case 2 occurs) and Rn k,

 

t 0. In this case, flow fn k, will violate its loss probability requirement if the PL scheduler is adopted. As a consequence, all

flows attached to SS n violate their loss probability requirements if Rn k,

 

t 0 for all k. This is clearly not desirable. One possible remedy is to place a pre-processor in front of the PL

scheduler to maximize the number of flows which meet their loss probability requirements. Let

   

operation if   . Otherwise, repeat the process. After the operation of the pre-process ends, the remaining resource is allocated to the remaining flows belonging to UP1UP2UA by the PL scheduler. Clearly, the computational complexity of the pre-processor is (O KnlogKn , where )

   

1 2 , | , , , ,

n P P n k n k A n k n k n

K  UUf fU P tPK . As will be seen in the next section, adoption of the pre-processor can significantly increase the number of real-time flows which meet their QoS requirements.

4.3. Simulation Results

In our simulations, SSs are uniformly distributed in a circular area of radius 2Km and the BS is located at the center. Two types of real-time traffic flows are studied. Parameters of the simulation environment, AMC schemes, traffic specifications and QoS requirements of real-time flows are summarized in 0. A frame is decomposed into downlink and uplink sub-frame. We only consider downlink transmission, which is assumed to occupy 30 time slots in a frame. The other time slots are used for uplink transmission and signaling overhead. For non-real-time traffic, we assume that its queue is always non-empty. Two scenarios are investigated. In both scenarios, we assume that |NRT | 40 and the minimum requested bandwidth of every non-real-time flow is zero.

In the first scenario, in addition to the 40 non-real-time flows, there are various number of SSs each attached with one Type I real-time flow. The second scenario has 13 SSs each attached with two real-time flows, one of Type I and another of Type II. Simulations are performed for 10,000 frames using Matlab on a PC with an Intel Core 2 Quad CPU operated at 2.83GHz with 3072 MB of

In the first scenario, in addition to the 40 non-real-time flows, there are various number of SSs each attached with one Type I real-time flow. The second scenario has 13 SSs each attached with two real-time flows, one of Type I and another of Type II. Simulations are performed for 10,000 frames using Matlab on a PC with an Intel Core 2 Quad CPU operated at 2.83GHz with 3072 MB of

相關文件