Chapter 1 Introduction
1.3 CRCN resource management scheme
Figure 3 inter-cell interference
In our CRCN architecture, CRAPs should ask CR Cloud for available resource, they can’t decide which channels to use by themselves, so CR Cloud can manage the resource for
6
each CRAP, deciding which channels each CRAP can uses. Thus, the intuitional idea is separating the resource management into two-tiers. The first tier is from CR Cloud to CRAPs, and the second tier is from CRAPs to CR users.
After CR Cloud calculates the available channels for CRAPs, it allocates some of these channels to each CRAP according its requirements (the amount of data it should serve), and then each CRAP use its allocated channels to serve the CR users who associate with it.
Because CRAPs do their resource allocations independently, nearby CRAPs may interfere with each other (referred as inter-cell interferences). Inter-cell interference may reduce the throughputs, so when CR Cloud allocates available channels to CRAPs, it should try to allocate different channels to nearby CRAPs as many as possible. However, the nearby CRAPs may use the same channels without inter-cell interferences by power control as figure 3. Thus, the second idea is adding the power control issue into first tier resource allocation.
Figure 4 power control examaple
7
Under the second idea, the first tier allocations not only allocate available channels to each CRAP, but limit the maximal power of each channel for each CRAP, so nearby CRAPs may share the same channels, increasing the channel reusability. Nevertheless, this way is not perfect enough. For example, as figure 4, under the second idea, CRAP1 and CRAP2 share the same channels, red and blue channels, by power control. However, if CRAP1 allocated the red channel to SU2 with smaller power, and SU2 can be satisfied with the power, CRAP2 can use larger power on red channel, so CRAP2 can have higher data rate to serve its associated SUs.
To optimize the efficiency of channels, doing power control based all users is essential.
However, it is not realistic because of its high complexity. To conquer the problem, we propose a CRCN resource management scheme as Figure 5. In the scheme, we group some SUs with close locations into a super SU (referred as SSU), and then CR Cloud will only do power control based on SSUs. Also, we distribute CRAPs to several areas, and each area is controlled by one resource management virtual machine (called RM VM). Therefore, the complexity of doing power control based on SSUs can be reduced very much, so the third idea will be implementable.
In addition, because each RMVM only control one area, RMVMs can’t take the CRAPs of nearby areas into considerations, so the boundary CRAPs of nearby areas may interfere with each other. Therefore, after main VM distribute CRAPs to several areas, main VM should allocate channels to the boundary CRAPs of nearby areas first to avoid inter-cell interference as best as possible.
8
Figure 5 CRCN resource management scheme
To avoid wasting resource, before CR Cloud allocates channels to CRAPs, CR Cloud needs to know the amount of resource each CRAP requires. Therefore, CRAPs should first classify their associated users to groups (as SSUs), collect their requests, and transform the requests to the form (such as the number of required channels) CR Cloud needs. Then the main VM distributes all CRAPs to several areas according to the amount of required resource, the number of associated users, and the cost between nearby CRAPs. The main VM will try to balance the workloads of each RMVM to let each RMVM can finish their jobs under the acceptable time. In Addition, after the main VM finish areas distributing, it will allocate available channels to boundary CRAPs.
Afterwards, each RMVM will do channel allocation and power control for the CRAPs in its managed area. The channel allocation and power control will be done based on the requirement of each SSU. RMVMs allocate each SSU several channels, and limit the
9
maximum power for each channel to meet the SINR demand. RMVMs will try to satisfy each SSU’s requirements, but not absolutely, so after RMVMs finish channel allocations, SSUs may not get the whole resource they required.
Finally, CRAPs will allocate channels and timeslots to each CR users by groups. If the resource is enough, CRAPs will satisfy each CR users’ requests. But when the resource is insufficient, CRAPs need to do their scheduling based on some regulations, such as throughput, and fairness. The scheduling will be done group by group, because the power control is based on the location and requirement of each group. If CRAPs arbitrarily allocate channels to discordant groups, it will cause inter-cell interferences, reducing the throughput of CRCN.
In conclusion, the CRCN resource management scheme separates the resource allocation to three tiers. The first one is the area distribution and interference avoidance for boundary CRAPs in main VM. The second one is resource allocation and power control for CRAPs in RMVMs. And the last one is grouping, request transforming and scheduling in CRAPs.
In this paper, we will focus on the third tier, the resource management in CRAPs. There are several challenges in the third tier. At first, how should we classify CR users into groups?
The definition of one group is that all CR users in the group have the same or similar SINR in a specific channel, so locations of the CR users in the same group should be close enough.
However, if we classify each group in a too small range, the number of SSUs will too many, causing the complexity of power control to become too high. Therefore, the first challenge is how to define a way to classify groups by considering the two issues.
Second, after classifying groups, we should collect the request of each group, and transform it to the number of channel the CRAP needs to serve the group. Because using larger powers will have higher SINRs (data rates), CRAPs should not only tell CR Cloud how many channels they need, but also the required SINR of each channel. Hence, transforming the CR users’ request to numbers of channels with specific data rates is the second challenge.
10
At last, after CR Cloud finishes the resource allocation, CRAPs should allocate channels and timeslots to CR users group by group based on their request. If the resource is not enough, CRAPs will do scheduling based on the fairness. Because we assume each user only have one antenna, each user only can use one channel each frame. In such condition, the allocation will become a challenging problem.
The reset of this paper is organized as follows. The system models and assumptions are introduced in chapter 2, including the way to group CR users. The proposed transforming and scheduling algorithms are contained in chapter 3. The results and simulations of our algorithms are showed in chapter 4. And we summarize the conclusions in chapter 5.
11