• 沒有找到結果。

Chapter 3 Proposed Algorithm

3.3 Heuristic Method

3.3.3. Detailed Example

A detailed example is illustrated in this paragraph, in which we assume the UL bandwidth is divided into 4 RBs (denoted as , , and ) and 3 active UEs (denoted as , and ) want to transmit UL resources. After active UEs reporting their channel qualities to eNodeB, the eNodeB gets SNR values of active UEs as shown in Table III.

Table III. Example – Initial SNR table

Let window size (ws) of window (w) be 3. At “Build window SNR table”, w is placed on all the RBs of UEs of Table III to build window table. Here, we should note that since is the first RB index, there is no RB on the left of . Thus, the w at only covers and . The value of is expressed as:

Similarly, since is the last index, there is no RB on the right of . Thus, the w at only covers and . The value of is expressed as:

28

For and , there is RB both on left and right. The w can hence properly cavers , and for . For , the w can properly covers , and . The value of and are expressed as:

The procedure of deriving values of and from SNR values is similar to . The result is shown in Table IV

Table IV. Example – Build window SNR table

At “Choose starting RB to UE”, we first calculate , , and , respectively.

For , and . Thus, can be calculated as:

For , and . Thus, can be calculated as:

29

For , and . Thus, can be calculated as:

The calculation of is similar to , and , which is 0.769. Since is the maximal, is chosen as starting RB at this procedure. Besides, belongs to , we hence allocates to . The result is shown in Table V, where the red grid on of manes the allocated to .

Table V. Example – Choose starting RB to UE

Since the latest scheduling allocates to , is get at “Adjust SNR table”. In this procedure, SNR values of are checked. If the checked SNR value is larger than , the SNR value is assigned to value of . From observation, we know value of , and is less than . Thus, the SNR value doesn’t need to revise. The result is shown in Table VI, where the red bold word 10.66 is .

30

Table VI. Example – Adjust SNR table

At “Adjust window SNR table”, is first on the left side of allocated RBs. Since the right side of is allocated to and , doesn’t need to revise left side unchecked RBs. For , new is calculated as:

Since the new equals to original one, doesn’t need to revise. Besides, the stop determination happens at , we don’t need to check and . For , new is calculated as:

Since the new not equals to original one, which is 1.23, is adjusted to 2.113. Similarly, the stop determination happens at , we don’t need to check and . For right side unchecked RBs, is first on the right side of allocated RBs.

Since the left side of is allocated to and , doesn’t need to revise right side unchecked RBs. For , new is calculated as:

31

Since the new not equals to original one, which is 7.462, is adjusted to 10.58. The procedure of is similar to , and is adjusted to 3.701. The result of this procedure shows in Table VII, in which the red bold words are revised values.

Table VII. Example – Adjust window SNR table

At “Choose next RB” procedure, is and is . Due to the right side of is , which is allocated to , the decision value of is . On the other hand, the left side of is also , the decision value of is . Since , is chosen as . The result is shown in Table VIII, where the yellow grid on means is chosen to be checked.

Table VIII. Example – Choose next RB

32

At “Choose available allocated UEs”, is not allocated to virtual UE. Thus the condition (1) of this procedure is skipped. Since is larger than , condition (2) is met, where . The result shows in Table IX, where the yellow grids on of and of means and are selected in set.

Table IX. Example – Choose available allocated UEs

At “Upper bound estimation”, for , and . Since the decision value of , which is , is larger than , which is , the sorting list of is . At first, is pseudo-allocated to , and gets 16.462. Then the upper bounds after pseudo-allocating to , or are 23.259, 22.068, 18.575 and 16.462, respectively. Since the upper bound after pseudo-allocating to is maximal, is pseudo-allocated to and gets 23.259.

Similarly, for , the upper bounds after pseudo-allocating to , or are 15.78, 25.838, 25.8 and 23.259, respectively. Since 25.838 is maximal and no RBs need to calculate, the upper bound estimation of allocating to is 25.838. The calculations of allocating to or are similar to above, in which the estimation of is 28.627. Besides, the estimation of is 18.807. Due to the upper bound estimation of is larger than and , which is 28.627, thus we allocates to . The result shows in Table X, where the green grid on of manes obtains .

33

Table X. Example – Upper bound estimation

The rest of this example follows the flowchart in Fig. 9. The scheduling result is shown in Table XI, where is allocated to , are allocated to , and is allocated to .

Table XI. Example – Scheduling result

3.3.4. Pseudo Code and Time Complexity

To help analysis time complexity of proposed algorithm – UBERA, we present the pseudo codes here. In Table XII., we list the main body. Besides, Table XIII and Table XIV list the “Adjust SNR table” and “Adjust window SNR table” procedure, respectively.

In Table XII, line 1 to line 16 execute “Build window SNR table”, which build a brand-new table based on SNR values, where eNodeB get from UEs’ periodically report. Here, the SNRs in window size of UE at specific RB are all checked at line 8, and find the minimum among these SNRs as corresponding wSNR at line 9. From line 18 to line 35,

34

“Choose starting RB to UE” is executed, where we get all the ∆j from line 24 to line 29. At line 30, we check whether there are ∆js having same value as max∆j. The RB decision and allocation is from line 31 to line 35. At line 37, “Adjust SNR table” is executed and listed in Table XIII. In Table XIII, SNR of RB of specific UE is got at line 5, checked at line 6 and assigned at line 7. At line 38 of Table XII, “Adjust window SNR table” is executed and listed in Table XIV. In Table XIV, the searching order of RBs, which are in window size of left side non-checked RBs, is decided at line 7 and line 8. The searching order of RBs, which are in window size of right side non-checked RBs, is decided at line 9 and line 10. Besides, the new wSNR is continued updated from line 12 to line 19, and revise the old wSNR at line 21.

At line 40, algorithm goes into while-loop for allocating remaining non-checked RBs.

From line 42 to line 70, “Choose next RB” is executed to pick one of non-checked RBs. If no RB needs to check, we return “no remaining RB needs to be checked” at line 47. The decision value of and got from line 55 to line 59 and from line 60 to line 64, respectively. From line 65 to line 69, RB to be checked is chosen. If “no remaining RB needs to be checked” is returned, the algorithm is terminated at line 73. Otherwise, “Choose available allocated UEs” is executed to choose candidate UEs from line 76 to line 83. From line 85 to line 100, “Upper bound estimation” is executed, in which the upper bound value of UE is calculated at line 93 according to 3.3.2 (7), and the decision of is from line

35

38: Execute Adjust window SNR table [Table VI.];

39:

40: while (true) do 41:

42: // Choose next RB

36

37

1: Let c be the latest scheduled RB, which is allocated to UE i 2: if UE i is not a virtual UE then

3: Let be the SNR of UE i on RB c

38

39

At “Build window SNR table”, it checks all RBs of all UEs to build the window table.

Since the size of w is ws, it takes . At “Choose starting RB to UE”, the scheduler RBs be checked currently as c. “Adjust window SNR table” revises window table similar to

“Build window SNR table”, but doesn’t revises the checked RBs. Hence, the scheduler the total time complexity of the proposed method can be calculated as

40

Since “Adjust SNR table” and “Adjust window SNR table” are called after each resource allocation, these two procedures run m times, respectively. Besides, since the first RB is allocated at “Choose starting RB to UE”, the “Choose next RB”, “Choose available allocated UEs” and “Upper bound estimation” run (m-1) times.

41

Chapter 4 Simulation Results

In this chapter, we first evaluate and compare the system throughput of proposed heuristic algorithms with optimal solution (denoted as OPT), Regular-CDS (denotes as CAS) [17] and two Regular-CDS based Smart-CDSs (denotes as TTRA and STRA [22]). Due to the exponential time complexity, OPT is only included into comparison with UEs vary from 1 to 10 where the UL bandwidth 3MHz is divided into 15 RBs. Then, we simulate large scale condition with UEs vary from 1 to 60 where the UL bandwidth 20 MHz is divides into 100 RBs. In this large scale simulation, OPT is not compared due to the problem of time complexity. Besides, two types of fading channel are also employed to evaluate the system throughput in different weather conditions and with physical objects between UE and eNodeB, in which the UEs vary from 1 to 30 with UL bandwidth 10MHz is divided into 50RBs. At second paragraph, we assume there are many active UEs want to transmit UL resources, in which the RBs are less than active UEs. In this simulation, the starvation ratio is proposed to evaluate how many UEs don’t grant RBs for UL transmission. We compare the starvation ratio of proposed method with CAS, TTRA and STRA. To observe the influence of window size, we compare the system throughput of proposed algorithm itself by adjusting window size at third paragraph. The problem of proposed method is discussed at final paragraph. In system bandwidth, the UL bandwidth is set to 3MHz, 10MHz and 20MHz with 15 RBs, 50 RBs and 100 RBs, respectively. Each RB in frequency is composed of 12 subcarriers with 15 kHz per subcarrier. In time domain, each RB consists 1ms which is composed of 7 OFDM symbols.

The simulation result is the average of 1,000 ms, where we assume the active UEs report there channel conditions every 1ms. According to specification, LTE offers 8 different MCSs for modulating UEs’ transmission data. The rest of parameter settings are listed in Table XV.

42

Table XV. Parameter settings of the LTE UL system

Parameter Setting

In Fig. 10, the number of deployed UEs varies from 1 to 10 with 15 RBs per TTI. In this figure, we can observe that the optimum solution performs the best among the rest approaches.

However, UBERA always performs better than CAS, TTRA and STRA, and is much closer to optimum. Since constraint of robust MCS mode is not considered in CAS, it performs worst among the compared methods. Although robust MCS mode is considered in TTRA and STRA, these methods are all proposed based on CAS. Thus, the grown up of these two is limited by CAS.

43

Figure 10. System throughput with optimum solution be compared

In Fig. 11, the number of deployed UEs varies from 1 to 60 with 100 RBs per TTI. Since the exponential time complexity of optimum solution, we only compare UBERA with CAS, TTRA and STRA. From the simulation result, we can observe that UBERA outperforms than the other three approaches. However, as the number of UEs higher than 45, the difference between UBERA and the other three approaches decreases. The reason is that, as the number of UEs grows to a degree, the maximal system throughput approaches. Thus the growing of system throughput becomes slowly. Besides, because the multi-user diversity gains of LTE UL, the throughput of all these approaches grows as number of UEs increases.

44

Figure 11. System throughput without optimum solution be compared

Then, we compare the system throughput performance in more comprehensive situation.

The results are shown in Fig. 12, in which the number of deployed UEs varies from 1 to 30 with 50 RBs per TTI. There are two types of channel are employed: frequency-selective fading, which can be regarded as an independent fading channel, denoted asμ = 0; flat fading, which can be seen as a highly correlated fading channel, denoted asμ = 1. In Fig. 12, UBERA always performs better than CAS, TTRA and STRA in both frequency-selective fading (μ = 0) and flat fading (μ = 1). Through observation, we know the proposed algorithm can still keep well performance in system throughput no matter the weather conditions and buildings between UE and eNodeB.

45

Figure 12. System throughput with different fading channel

4.2 Starvation Ratio

Due to the scarcity of wireless resources (or RBs) and there are many active UEs want to transmit UL resources, some active UEs may unable to grant RBs. Moreover, if the channel qualities of these active UEs are poor often, they will suffer from no more RBs to use. Hence, the starvation ratio ( ) is introduced to analysis the ratio of UEs unable to obtain RBs, where is expressed as:

where numerator is number of UEs doesn’t obtain any RB at TTI t and denominator n is

46

number of active UEs want to transmit UL resource.

Figure 13. Starvation ratio vs. Number of UEs

The simulation result shows in Fig. 13, in which the number of deployed UEs varies from 1 to 30 with only 15 RBs per TTI. From simulation result, we observe the starvation ratio of UBERA is less than CAS and TTRA and higher than STRA while the number of UEs is less, and higher than all the three methods while the number of UEs is more than 5. Besides, by taking Fig. 12 and Fig. 13 into analysis, the system throughput of STRA in flat fading (μ = 1) is lower than CAS and TTRA while UEs are less than 11. In addition, we can also observe the starvation ratio of STRA is lower than CAS and TTRA while UEs are less than 11. Thus, we can conclude there is tradeoff between system throughput and starvation ration. In other words, the better performance in system throughput means some active UEs owning well channel qualities obtain more RBs, which makes the UEs owning worse channel qualities

47

unable to obtain any RB. Therefore, the performance of starvation ratio performs worse. Since the objective of proposed UBERA algorithm is to maximize system throughput, the simulation result of outage ratio doesn’t perform well. However, the UBERA always performs better than CAS, TTRA and STRA in system throughput.

4.3 Influence of Window Size

In Fig. 14, we compare UBERA itself with different number of window size. The number of deployed UEs varies from 1 to 30 with 50 RBs per TTI. The observation shows that as the window size sets to 1, which means , it doesn’t get well result. The best result is acquired as window size set to 5. We can also know that the higher window size cannot guarantee better result.

Figure 14. System throughput with different window size

48

An example shows in Fig. 15. As the window size set to 5, the scheduler can appropriately calculate of the UE in this scenario. Hence, the scheduler can clearly notice that the UE’s most advantageous contiguous RBs region is nearing RB5. Thus we can try to allocate RBs nearing RB5 to this UE. However, as the window size set too small such as 1, the scheduler will confuse whether it should allocate contiguous RBs nearing RB3, RB5 or RB9 to the UE. If the scheduler decides to allocate RBs nearing RB9, it will hence get low system throughput, because RB8 doesn’t have well capacity to the UE. In case we set the window size too large such as 9, of the UE in this example are all equivalent. Thus, the scheduler can’t make decision which RBs have abrupt well capacity to the UE. Since the RBs capacity conditions may different according to the positions of the UEs, applying different window size to UEs may be the best policy to the scheduler. Thus, dynamic adjusting window size will be one of our focused future works.

Figure 15. An example of influence on different window size

49

4.4 Problem of UBERA

Some problems may cause the UBERA doesn’t work well. First, as the window size doesn’t suit in this scenario, the scheduler will make confuse as described above. Hence, it may pick RB to wrong UE compared to the allocation result of optimal solution at “Choose starting RB to UE”. For example, if window size set too large that all the UEs themselves have same crossing all the RBs as in window size =9 of Fig. 15, we will get same and at all the RBs. Thus it cannot accurately allocate suitable UE to RB at “Choose starting RB to UE”. Besides, since the step of “Upper bound estimation” owns the highest time complexity, the scheduler at “Choose available allocated UEs” tries to exclude some UEs from doing estimation, which may not be possible allocated at . However, the determination cannot guarantee the scheduler will not exclude the UE of optimal solution at . Thus it causes the system throughput goes down while excluding this UE. At last, if we try to get the upper bound of a specific UE allocated at while considering constraints of LTE UL, it still is a NP-hard problem (LTE UL maximal system throughput while is allocated to the specific UE). Thus, we don’t consider contiguous constraint (relax constraint) while doing estimation at step of “Upper bound estimation”, which will cause the estimation not so accurately every time and may allocate wrong UE to .

50

Chapter 5 Conclusion

In this thesis, we first introduce two inherent constraints of SC-FDMA channel access scheme. Here we name these two constraints as contiguous RB assignment and robust MCS mode. Taking the two constraints into consideration, we formulate the scheduling problem of maximize LTE UL system throughput as Integer Linear Programming. Due to the exponential time complexity of optimal solution, we design an estimation based algorithm – Upper Bound Estimation Resource Allocation (UBERA). In simulation experiment, we compare UBERA with optimal solution, CAS, TTRA and STRA, The simulation results show the UBERA indeed have better performance than CAS, TTRA and STRA, while having fewer gaps from optimal in system throughput.

Since the window size is constant in single resource allocation period, our future work will focus on adjust window size automatically in one period to further enhance the performance of UBERA. Furthermore, “proportional fairness”, as known as long-term fairness, is also a critical issue in the LTE scheduling problem. By taking this issue into consideration, we will modify our proposed method to enhance the performance of proportional fairness while maintaining the system throughput at the same time.

51

References

[1] H. Ekstr¨om; A. Furusk¨ar; J. Karlsson; M. Meyer; S. Parkvall; J. Torsner; and M.

Wahlqvist, “Technical Solutions for the 3G Long-Term Evolution,” IEEE

Wahlqvist, “Technical Solutions for the 3G Long-Term Evolution,” IEEE

相關文件