OVSF code channel assignment with dynamic code set and buffering adjustment for UMTS

Abstract—The Universal Mobile Telecommunications System

(UMTS) provides users variable data rate services, which adopts wide-band code-division multiple-access (WCDMA) as the radio access technology. In WCDMA, orthogonal variable spreading factor (OVSF) codes are assigned to different users to preserve the orthogonality between users’ physical channels. The data rate supported by an OVSF code depends on its spreading factor (SF). An OVSF code with smaller SF can support higher data rate services than that with larger SFs. Randomly assigning the OVSF code with a large SF to a user may preclude a larger number of OVSF codes with small SFs, which may cause lots of high data rate call requests to be blocked. Therefore the OVSF code assignment affects the performance of the UMTS network significantly. In this paper, we propose two OVSF code assignment schemes CADPB1 and CADPB2 for UMTS. Both schemes are simple and with low system overhead. The simulation experiments are conducted to evaluate the performances for our schemes. Our study indicates that our proposed schemes outperform previously proposed schemes in terms of the weighted blocking probability and fairness index. Our schemes improve the call acceptance rate by slightly introducing call waiting time.

Index Terms—Code channel assignment, dynamic adjustment,

orthogonal variable spreading factor (OVSF), Universal Mobile Telecommunications System (UMTS), wide-band code-division multiple-access (WCDMA).

I. INTRODUCTION

T

code-division multiple-access (WCDMA) is used as the radio

access technology. In WCDMA, orthogonal variable spreading

factor (OVSF) codes are assigned to users’ calls to preserve

the orthogonality between users’ physical channels. The data rate supported by an OVSF code depends on its spreading

factor (SF). An OVSF code with smaller SF can support higher

data rate services than one with larger SF. The OVSF codes Manuscript received October 26, 2002; revised September 14, 2004. The work of P. Lin was supported in part by the National Science Council, Taiwan, R.O.C., under Contract NSC-93-2213-E-002-095; in part by the Institute for In-formation Industry, Taiwan, R.O.C.; in part by the Chung-Shan Institute of Sci-ence and Technology, Taiwan, R.O.C.; in part by CCL/ITRI, Taiwan, R.O.C.; and in part by Microsoft. The review of this paper was coordinated by Prof. M. Juntti.

P. Lin and C.-H. Gan are with the Department of Computer Science and In-formation Engineering, National Taiwan University, Taipei 106, Taiwan, R.O.C. (e-mail: [email protected]; [email protected]).

C.-C. Hsu is with the Institute for Information Industry, Taiwan, R.O.C. (e-mail: [email protected]).

Digital Object Identifier 10.1109/TVT.2004.842449

are generated by using a complete binary tree. Depending on the height of the position in the tree where an OVSF code locates, the SF of the OVSF code is determined. An OVSF code can be assigned to a user’s call if and only if the code, all of its ancestor OVSF codes, and descendant OVSF codes in the tree have not been assigned to other users’ calls. Within the coverage area of a Node B, the total data rate that can be assigned to users is fixed. In this paper, the coverage area of a Node B is denoted as a “cell.” The details of the criteria for the OVSF code assignment are given in Section II. Based on the OVSF code assignment criteria, randomly assigning the OVSF code with a large SF to a user may preclude a larger number of OVSF codes with small SFs, which may cause many high data rate call requests to be blocked. Thus the OVSF code assignment affects the quality of service (QoS) for the UMTS network significantly. For the above issue, 3GPP 25.213 [2] and 25.223 [3] proposed the multicode and single-code transmission mechanisms for variable data rate services.

In the multicode mechanism, multi-OVSF codes are used to serve a user’s call, and in the single-code mechanism, single OVSF code is used to serve a user’s call. Reference [13] and our previous study [6] proposed the OVSF code assignment schemes for the multicode mechanism.The multicode mechanism requires the complex transceiver, which may increase the complexity of a UE. To reduce the complexity of a UE, the single-code mechanism is preferred for variable data rate services. Several OVSF code assignment schemes [5], [7], [8], [12], [14] are proposed for the single-code mechanism, which can be classified into two categories: “rearrangeable” and “nonrearrangeable.” The rearrangeable scheme may reassign some calls (being severed with low data rate) other OVSF codes to hold a satisfied OVSF code for the incoming call request. Reference [12] has shown that the rearrangeable scheme can reduce the call blocking probability. However, in the rearrangeable scheme, there are drawbacks for rearrangement operations: Extra computation is required to “find” the served calls to be reassigned OVSF codes, which increases the computation overhead of the system. Furthermore, when rearrangement operations are exercised, some of the served calls have to be “reassigned” OVSF codes, which introduces extra message exchange, may cause a served call to be forced to terminate, and thus decreases the QoS of the network. Therefore, the most considered design issue in the rearrangeable schemes is to reduce the number of reassignment of the codes serving calls when accepting a new request. The nonrearrangeable schemes [5], [14] are considered simple and with low system overhead for the OVSF code assignment.

Fig. 1. The UMTS network architecture.

In this paper, we propose two nonrearrangeable OVSF code assignment schemes: code assignment with dynamic partition and buffering 1 (CADPB1) and CADPB2 with buffering mech-anisms. Based on the measured traffic load, our schemes dy-namically partition the OVSF code tree into subgroups to serve requests with different data rates. The buffering mechanism is adopted to queue the call requests that cannot be served (due to no satisfied OVSF code) instead of blocking them immediately. The buffering mechanism is considered simple and cost-effec-tive to reduce the call blocking probability, which can have the same effect of the reassignment operation (i.e., reducing the call blocking probability). Our schemes also dynamically adjust the sizes of the buffers according to the call waiting times. In [7] and [8], authors also adopted the tree partition concept for OVSF code assignment, where the tree partitioning (TP) scheme is pro-posed. The similitude between TP and our schemes is that the OVSF codes are partitioned into groups to serve different types of call requests, and the differences are listed as follows.

1) TP is a rearrangeable scheme, but our schemes are nonre-arrangeable schemes.

2) In our schemes, the dimension of each code tree partition is “dynamically” updated based on the traffic loads of dif-ferent types of calls.

3) One more difference between the TP scheme and the CADPB2 scheme is that in CADPB2, the code sets to support high data rate call requests also contain that to support the lower data rate call requests so that ancestors of the codes in the code set (supporting lower data rate calls) can also be used to support high data rate requests. In the end of this paper, we compare the performance of our schemes and the rearrangeable schemes to see the effects of the buffering mechanism and reassignment operation. This compar-ison was not seen in the other previous studies. This study fo-cuses on the media access control for different types of calls. The consideration of other physical layer limitation factors (e.g., signal-to-noise ratio, bit error rate, total transmission power, etc.) is not treated in this paper. This is because when the net-work enters the phase “allocating an OVSF code to a call re-quest,” the other physical layer limitations for the request should have been satisfied [9]. For the details of other physical layer limitation factors, readers may refer to [9].

This paper is organized as follows. In Section II, we intro-duce the criteria for the OVSF code assignment. Section III

presents the two schemes. In Section IV, we evaluate the per-formances for the CADPB1 and CADPB2 schemes. The con-clusion is given in Section V.

II. CRITERIA FOROVSF CODEASSIGNMENT

The rules for the generation of OVSF codes are based on a complete binary tree with 1 layers (from Layer 0 to Layer ) where . Fig. 2 depicts the binary tree. An OVSF code is corresponding to a node in the tree, which is denoted as , where is the layer number and is the position number in Layer . The node positions in Layer are sequentially labeled (i.e., ) from the left to the right. An OVSF code in Layer has the spreading factor SF . The data rate that can be supported by an OVSF code is determined by its SF. An OVSF code with the smaller SF can support higher data rate services than that with the larger SF. Suppose that the OVSF code can support data rate bits/s. Then the data rate supported by is

bits/s (1)

Three statuses free, busy, and assignable are used to indicate if an OVSF code can be allocated to a user. An OVSF code is free if the code has not been assigned to a user. An OVSF code is busy if the code is assigned to a user. A code is assignable if and only if the code and all of its ancestor and descendant OVSF codes in the tree are free. Only the OVSF codes in the assignable status can be assigned to users’ calls, which pre-serve the orthogonality between users’ physical channels. Ac-cordingly, the remaining data rate that can be assigned to users within a cell is depending on the statuses of the all OVSF codes in the tree, which can be calculated by summing the data rates supported by the assignable OVSF codes in Layer . Let denote the remaining data rates within a cell. Then

(2)

where is obtained from (1) and

if is assignable otherwise.

Fig. 2. AK + 1-layer OVSF code tree.

The total data rate supported by a Node-B can be calculated by summing the the total data rates supported by all codes in Layer . From (2), we have

bits/s

III. THECODEASSIGNMENTSCHEMESWITHDYNAMIC PARTITION ANDBUFFERINGMECHANISMS

This section proposes two OVSF code assignment schemes CADPB1 and CADPB2 for different types of calls. The call re-quests are classified into types: type type type . Sup-pose that for , the data rate requested by the type calls is bits/s, where is power of two. Without loss of

gen-erality, we assume that .

A. The CADPB1 Scheme

In CADPB1, we partition the OVSF codes in the code tree into sets: . The OVSF codes in are used to serve the type calls, where . Let the number of codes in be . For the type call requests, we maintain the first-in first-out buffer to queue the type call requests that cannot be served due to no assignable code in . Let the size of be .

In CADPB1, we dynamically partition the code tree and adjust the buffer sizes according to the measured traffic loads and the average call waiting times, respectively. The following system parameters are used in CADPB1 for the dynamic adjustment functionality.

1) is a threshold value used to trigger the dynamic adjust-ment functionality for both the code sets and buffer sizes. After every calls (including types) have been served, the network dynamically partitions the code sets and ad-justs the buffer sizes.

2) and are counters that count the numbers of the type call arrivals and of the served type calls during the time period when calls (including types) have been served, respectively.

3) , and accumulate the time spent by the type calls waiting in , the interarrival time of the type

calls, and the service time spent by the type calls when calls (including types) have been served, respectively. 4) , and store the average call waiting time,

av-erage arrival rate, avav-erage service time, and avav-erage traffic load for the type calls during the time period when calls (including types) have been served, respectively. 5) is a threshold values used to trigger the buffer

size to be discounted (increased) by one when the av-erage waiting time of the type calls is larger (smaller)

than .

The CADPB1 scheme consists of four procedures: Initial, Ar-rival, Departure, and Adjustment. “Initial” initiates the system parameters when the system starts. “Arrival” allocates the OVSF code to a call request. “Departure” is invoked when a call com-pletes. “Adjustment” repartitions the code sets and readjusts the buffer sizes for each type of calls, which is triggered when every calls have been served (i.e., ). The de-tails of the four procedures are described as follows.

1) Initial: When the system starts up, for each type of call, and are set to

(3) where is a constant number. Initially, we allocate the same data rate to each code set. The buffer size is initially set to . Based on , for , we generate the code set by the following rule:

(4) Fig. 3 shows an example of a partition result for four code sets where bits/s. In the figure, the nodes in the four rectangles are the codes in , where .

For , and

are set to zero, and all the codes in are marked as assignable.

2) Arrival: For a type call request where , the network finds an assignable code in . If such a code exists, the code is allocated to the request

Fig. 3. An example for the partition result of Initial procedure in CADPB1.

and marked as busy. Otherwise (i.e., there is no

assign-able code in ), the network checks . If is full, the call request is blocked. Otherwise (i.e., is not full), the call request is queued into is increased by one, and the time period between the call and last type call (i.e., intercall arrival time) is accumulated into . If tie-breaking occurs (i.e., there are call requests arriving at the same system time), they can be processed in any order.

3) Departure: When a type call (served with ) completes, the code is marked as assignable, is increased by one, the service time of this type call is accumulated into , and the waiting time of this type call in is accumulated into . Then is checked. If there are requests queued in , the released code is allocated to the queued request.

Note that if is allocated before the Adjustment procedure exercises, and released after the Adjustment procedure exercises, the code may not belong to . If so, the code is marked as free. After this action, some codes in other code sets may become assignable by checking their ancestor and descendant codes. Suppose that the code that becomes assignable is in . Then is checked. If is not empty, then the assignable code is allocated to the requests buffered in .

4) Adjustment:When every calls have been served (i.e., ), the code tree is repartitioned, and the buffer sizes are readjusted as follows.

To repartition the code tree, we first compute the traffic load of each type of calls as follows:

(5) where

and (6)

Based on (5), for , we recursively determine the size of each code set (i.e., ) by the fol-lowing equation:

round (7)

By applying (7) into (4), we obtain the new code set for the type calls.

The size of the buffer for each type of calls is readjusted based on the average call waiting time , which is ob-tained by

If , where is obtained from (6), the buffer size is discounted by one. If and

, the buffer size is increased by one.

After repartitioning the code tree and readjusting the buffer sizes, the statuses of the codes are updated by checking their ancestor and descendant codes. Then

, and are reset to zero.

B. The CADPB2 Scheme

In CADPB1, a situation may occur, that is, for , though there are assignable codes in , a type request cannot be served (due to no assignable code in ). For improvement, we propose CADPB2 by slightly modifying CADPB1. The system parameters in CADPB2 are the same as that in CADPB1. The four procedures are modified as follows.

1) Initial: Similar to CADPB1, for is initially determined by using (3). The generation of the code set follows (8), which is different from the one used in CADPB1 (i.e., (4))

(8) From (8), the ancestors of the codes in the set supporting lower data rate services can also serve higher data rate call requests. Fig. 4 shows an example for the result after this procedure exercises. The nodes in the four rectangles represent the codes in where .

2) Arrival: This procedure is similar to that in CADPB1, except that, when a type call request arrives, the network finds an assignable code in by checking the statuses of the codes in from “the right to the left.” If an assignable code is found, it is assigned to the request. The code is marked as busy, and its ancestor and descendant codes are set to free.

3) Departure: When the code serving the type call is released, it is marked as free. The network updates the statuses of the codes in by checking their ancestor and descendant codes. After this action, for

, the network checks sequentially. If is not empty, the network checks if there are assignable codes in . If such codes exist, the network allocates the codes to the requests queued in , then marks the statuses

Fig. 4. An example for the result of Initial procedure in CADPB2.

of the allocated codes as busy and modifies the statuses of their ancestor and descendant codes as free.

4) Adjustment is similar to that in CADPB1. The buffer sizes are readjusted following the rule used in CADPB1. The sizes of code sets (i.e., ) are calculated by using (7). Then is applied to (8) to obtain .

IV. PERFORMANCEEVALUATION

This section compares the performances between our schemes and the previously proposed schemes based on the simulation experiments. We build up the simulation model according to the behavior of our schemes. We adopt the dis-crete event-driven approach [6], [10]–[11]. The details are not presented here.

We define for type calls as the probability that a type call request cannot be served by the network. In our schemes, when a type call request arrives, the call request is blocked when there is no assignable OVSF code in , and the buffer is full. In the previous studies [7], [8], [12], the authors used the “code blocking probability” as the performance indicator, which is defined as the probability that “under the condition when the system has excess capacity to satisfy the requested data rate of a call (i.e., the requested data rate), the call is blocked.” In [12], the following theorem has been proven.

Theorem 1: If a rearrangeable code allocation scheme is

ap-plied, the code blocking would not occur.

In other words, for the rearrangeable code allocation schemes, the code blocking probability is equal to zero. Thus, the measurement of code blocking probability for code rear-rangeable scheme cannot clearly show the system capacity. Therefore, for meaningful performance comparison between the rearrangeable scheme “DCA” and our schemes, we use the “call blocking probability for the type calls (i.e., )” as the performance indicator, which is defined as the probability that “a type call request cannot be served by the network.” This occurs when a type call request arrives, and the left data rate of the network is less than the requested data rate (i.e., requested data rate). The call blocking probability can precisely reflect the ratio of call requests that can not be served.

Besides , we also derive the weighted blocking proba-bility [12], that is

(9) The intention of (9) is that the damage of QoS (i.e., ) for the high data rate calls is higher than that for the low data rate calls. By applying , we can more precisely investigate the overall QoS

for the network. The fairness index [14] is used to measure the fairness of code assignment for each type of calls, which is

(10) In (10), it is clear that . When the values for approach to the same value, the value ap-proaches to one. On the other hand, if the variance of all s where becomes large, approaches to zero. Therefore, a larger implies that each type of calls can get ser-vice more fairly.

To clearly indicate the improvement of our schemes over the previously proposed schemes, we investigate the performances of the dynamic code assignment (DCA) [12] and First Fit (FFit) [7], [8] schemes based on simulation experiments. In DCA, for an incoming type call request, the network checks if there is an assignable code that can serve it. If so, the assignable code is allocated to the request. Otherwise, the network reassigns some calls (being served with low data rate) other OVSF codes to hold a satisfied OVSF code for the request. The FFit scheme is a nonre-arrangeable scheme. In FFit, for a type call request, the network searches an assignable code supporting the data rate bits/s from the left to the right. If no such code is found, the request is blocked immediately. This scheme is considered simple.

From Theorem 1, we know that if the code assignment schemes implement the code rearrangement operation following Theorem 1, then they will have the same performance in terms of call blocking probability. Since most rearrangeable schemes (e.g., the TP scheme [7], [8] and the DCA scheme [12]) follow Theorem 1, we implement the simulation model for the DCA scheme (which can show the trend for the call blocking per-formance of the most rearrangeable schemes) to compare the performance of our schemes and rearrangeable schemes.

In this section, we first consider four types of calls—type type type type —to investigate the performance trend of our schemes, where requested data rates are 2 4 , and 8 bits/s, respectively. The UMTS system is mainly designed to support wireless transmission services for the existing Internet applica-tions (in particular for moving users to access Internet). In our study, the transmission rate kbits/s is sufficient to support streaming video applications (either with .asf or .rm file format). Therefore, we run several scenarios by considering the requested data rate up to 8 . The input parameter are set up as follows.

1) The threshold is set to 10 000.

2) The and thresholds are set to 1/10 and 1/12, respec-tively.

3) The requested data rates bits/s, bits/s, bits/s, bits/s for the four types of calls are set as

.

4) The buffer size is initially set as . 5) We set the mean 1 of the service times for the type

calls as

(11) 6) We normalize by . That is, during the time period 1 , averagely, type calls arrive at a cell, and , and

have the following relationship:

(12) where , and are constant numbers.

7) The total data rate supported by a Node B is bits/s.

8) We define the total traffic load

(13) Note that, in the previous studies [7], [8], [12], the fol-lowing equation is used to interpret the traffic load.

where is the sum of arrival rate for different types of calls, and is the mean of service time per call. To allow for a transparent comparison between our study and the previous studies [7], [8], [12], in the simulation re-sults, we use to interpret the total traffic load. The following equations are used to map the input parameters in our study to that in the previous studies [7], [8], [12]:

or

From (11)–(13), can be expressed as

(14) Applying (12)–(14) into (7), the size of each code set can be obtained as follows:

(15)

In our study, we consider four scenarios for the setups, which have been widely adopted in other pervious studies [7], [8], [12]:

Scenario I: ;

Scenario II: ;

Scenario III: ;

Scenario IV: .

1) Comparison for Call Blocking Probability : Fig. 5

compares the call blocking probability of the type calls for CADPB1, CADPB2, DCA, and FFit, where Sce-nario I is considered. In this figure, the total traffic load ranges from 42.66 to 66.66 (i.e., ranges from 160 to 250). This figure indicates that the , and values for CADPB1 are almost the same (see “ ” curves). CADPB1 partitions the code tree according to the traffic load for each type of calls, and since

, the sizes of four code sets are the same. Thus the four types of calls could be served with equal opportunity. In CADPB2 (see “ ” curves), the blocking probability for the high data rate call requests is lower than that for the low data rate call requests (i.e., ). This is because the ances-tors of the codes in the set supporting low data rate ser-vices can also serve high data rate call requests. For DCA (see “ ” curves) and FFit (see “ ” curves), we observe that . This is due to the fact that DCA and FFit do not partition the code tree, and from the criteria of OVSF code assignment, we know that the low data rate call requests are more likely to be served than high data rate call requests. The performances for the four schemes are in the following order:

FFit DCA CADPB1

CADPB2

FFit DCA CADPB1

CADPB2

FFit DCA CADPB1

CADPB2

CADPB2 CADPB1 DCA

FFit

From Fig. 5(d), DCA has much lower blocking rate for high data rate calls than FFit has. This is due to the fact that the reassignment operations are performed in DCA. In other words, with DCA, high data rate calls are more likely to occupy the OVSF codes, with the result that low data rate calls may not be served. Instead, in FFit, since the high data rate calls has worse chance to be served, more OVSF codes are left to serve low data rate requests. Thus, we observe the phenomenon shown in Fig. 5(a). To summarize, the performances for CADPB1 and CADPB2 are better than that of DCA and FFit. On the other hand, with FFit and DCA, the low data rate call requests has better chance to be served than high data rate call requests.

Fig. 5. Comparison for the call blocking probability (R = 256r bits/s; 1 = 10 000;  :  :  :  = 1 : 1 : 1 : 1). (a) Blocking probability for type calls. (b) Blocking probability for type calls. (c) Blocking probability for type calls. (d) Blocking probability for type calls.

2) Comparison for Weighted Blocking Probability :

Fig. 6 compares the weighted blocking probability for CADPB1, CADPB2, DCA, and FFit by considering Scenarios I–IV. In this figure, the total traffic load ranges from 42.66 to 66.66, from 38.10 to 59.52, from 48.48 to 75.75, and from 66.66 to 104.16 for Scenario I, Scenario II, Scenario III, and Scenario IV, respectively, that is, ranges from 160 to 250 for Scenarios I–IV. From (9), we know that the blocking probability for the high data rate call is assigned large weight and affects the performance significantly. In CADPB1 and CADPB2, the code sets for different types of calls are dynamically partitioned based on (7), i.e., according to the ratio of the measured traffic load from served calls (including four types). There is an error existing between the measured

traffic load and actual traffic load. Especially when is small, the error becomes significant. This error causes that the code tree cannot be partitioned precisely. For example, based on the actual traffic load, the code set size of the type calls should be four. However, based on the measured traffic load, there are actually three codes in the code set. The error may significantly degrade the performance for the types of calls whose code set is small. In FFit or DCA, no tree partition is performed. The four types of calls compete with each other for the OVSF codes. The calls having larger arrival rate are more likely to be served than that having smaller arrival rate.

In Scenario I [see Fig. 6(a)], CADPB1 and CADPB2 significantly outperform both DCA and FFit in terms of the performance. As shown in Fig. 5, in Scenario I,

Fig. 6. Comparison for the weighted blocking probability (R = 256r bits/s; 1 = 10 000). (a)  :  :  :  = 1 : 1 : 1 : 1. (b)  :  :  :  = 4 : 1 : 1 : 4. (c)  :  :  :  = 1 : 4 : 4 : 1. (d)  :  :  :  = 4 : 4 : 1 : 1.

Fig. 7. Comparison for the fairness index (R = 256r bits/s; 1 = 10 000;  :  :  :  = 1 : 1 : 1 : 1).

CADPB1 and CADPB2 have smaller values than that other schemes have. With lower blocking probability for high data rate calls, our schemes offer the better per-formance in Scenario I. The performances for the four schemes in Scenario I have the order: CADPB2

CADPB1 DCA FFit . For example, when (i.e., ), CADPB2 has 14.1%, 34.3%, and 51.8% improvement over CADPB1, DCA, and FFit in terms of the performance, respectively.

When and increase [i.e., Scenario II; see Fig. 6(b)] compared with Scenario I [Fig. 6(a)] the

Fig. 8. Average call waiting times for the CADPB1 and CADPB2 schemes (R = 256r bits/s; 1 = 10 000;  :  :  :  = 1 : 1 : 1 : 1).

performance for FFit gets better, the performance for DCA is slightly improved, the performance for our schemes become worse, and thus the performances for the four schemes are almost identical. In Scenario II, , which results in that the code set sizes for type and type calls decrease and become much smaller compared with that in Scenario I. Hence, and increase, and we observe higher values for CADPB1 and CADPB2 in Fig. 6(b). In

Sce-nario II, since , with DCA

or FFit, the type calls get better chance to be served than that in Scenario I [see Fig. 6(a)] and deceases. Since

Fig. 9. The and F performances for more traffic types (R = 256r bits/s; 1 = 10 000).  :  :  :  :  = 1 : 1 : 1 : 1 : 1. (b)  :  :  :  :  = 1 : 1 : 1 : 1 : 1. (c)  :  :  :  :  :  = 1 : 1 : 1 : 1 : 1 : 1. (d)  :  :  :  :  :  = 1 : 1 : 1 : 1 : 1 : 1.

the performance is dominated by the call blocking probability for high data rate calls, we observe the better

performance for FFit and DCA in Scenario II.

The results in Fig. 6(c) (i.e., Scenario III) are similar to that in Fig. 6(d) (i.e., Scenario IV). The two figures indicate that the performances for CADPB1 and DCA are almost identical. The CADPB2 scheme has the best performance among the four schemes. Compared with Fig. 6(a), the values for CADPB1 and CADPB2 in-crease in these two scenarios. This is due to that the ar-rival rates for the four types of calls are not well mixed. For FFit and DCA, due to the smaller arrival rate for the type calls in these two scenarios, we observe that the values for FFit and DCA become large.

To conclude, the CADPB2 scheme outperforms other schemes in terms of the performance in most cases. CADPB1 and DCA have the similar performance. 3) Comparison for Fairness Index : Fig. 7 compares the

fairness index for CADPB1, CADPB2, DCA, and FFit, where Scenario I is considered. The figure shows that in FFit, DCA, and CADPB1, the values do not change sig-nificantly as increases, but in CADPB2, increases as increases. The CADPB1 scheme has the best per-formance among the four schemes. When

(i.e., ), the performances for

CADPB2, DCA, and FFit are in the order DCA CADPB2 FFit . When

(i.e., ), CADPB2 outperforms DCA

and FFit in terms of the performance. When

in-creases, the performance for CADPB1 gets closer to that for CADPB2. In CADPB2, the ancestors of the codes in the set supporting low data rate services can also serve high data rate call requests, which results in unfairness for different types of calls. When is low (i.e.,

), the traffic load is not saturated, and the codes in the set supporting low data rate services are more likely free. Thus, the ancestors of these codes have high oppor-tunity to serve high data rate calls. On the other hand, as the traffic load is saturated (i.e., ), it is more likely that there are call requests queued in . The codes in the set supporting low data rate services are more likely to be allocated to the queued low data rate call requests. In summary, when traffic load is saturated, the behavior of CADPB2 is like that of CADPB1. 4) Average Call Waiting Time for CADPB1 and CADPB2:

In CADPB1 and CADPB2, the buffering mechanism with dynamic buffer-size-adjustment is used to queue the calls that cannot be served immediately. In Fig. 8, we investi-gate the average call waiting time for call requests (in-cluding four types) being queued in the buffer. The figure shows that increases as increases. The perfor-mances for CADPB1 and CADPB2 are almost identical,

which are bounded by the range .

The result indicates that our buffering mechanism im-proves the call acceptance rate by slightly introducing call waiting time.

5) Performance Comparison for More Traffic Types: Fig. 9 compares the and performances for CADPB1,

Fig. 10. The effects of buffering ( :  :  :  = 1 : 1 : 1 : 1; 3= = 66:66; R = 256r bits/s; 1 = 10 000). (a) The P performance. (b) The performance. (c) TheF performance. (d) The W performance.

CADPB2, DCA and FFit when more than four traffic types are considered. In Fig. 9(a) and (b), we consider five traffic types, where the data rates re-quested by the type type type type , and type calls are 2 4 8 , and 16 bits/s, respectively, and

. The total traffic load ranges from 25.80 to 40.32,i.e., ranges from 160 to 250.

Compare Figs. 9(a) and 6(a), where the network traffic load (i.e., ) has the same range. We observe that the trends for the performances for the four schemes in the two figures are similar. CADPB2 outperforms CADPB1, DCA, and FFit. The performances for CADPB1 and DCA are almost the same when there are five traffic types [see Fig. 9(a)]. This is because, in CADPB1, the number of codes used to support each type of calls decreases (i.e., the size of each code set gets smaller) as the number of traffic types increases. The call requests are more likely to be blocked, which results in higher .

Comparing Figs. 9(b) and 7, we observe that the trends for the performances for the four schemes are similar. The difference is that as the number of traffic types in-creases, CADPB2 outperforms DCA in terms of the performance in most cases [see Fig. 9(b)].

Moreover, we compare the and performances for six traffic types in Fig. 9(c) and (d), respectively. The data rates requested by the type type type type type , and type calls are 2 4 8 16 , and 32 bits/s, re-spectively, and

. The total traffic load ranges from 15.23 to 23.81, i.e., ranges from 160 to 250.

Compare Fig. 9(a) and (c), where the total traffic loads are in the same range, and we observe that as the number of traffic types increases, the values become large. The performances for the four schemes have the similar trend shown in Fig. 9(a). Fig. 9(d) shows that the values of CADPB2 get closer to that of CADPB1 in this figure. To conclude, as the number of traffic types increases, CADPB1 is still the scheme that can most fairly allocate the OVSF codes to each type of calls, and CADPB2 has the best performance.

6) Effects of Buffering: One may question that our compar-ison may not be fair since the DCA and FFit schemes are not implemented buffering. For this issue, we also apply the buffering on the DCA and FFit. As shown in Fig. 5, both DCA and our proposed schemes attempt to re-duce the blocking probability for the high data rate calls. Here, we address the , and performance com-parison for DCA, FFit, CADPB1, and CADPB2 while buffering is also applied in DCA and FFit. Let and

be the buffer sizes of DCA and FFit, respectively. Fig. 10 shows the results, where Scenario I is consid-ered, the total data rate is set to 256 bits/s, and the total

traffic load (i.e., ). For other

scenarios, we observe the similar results, which are not presented here. In Fig. 10(a), we observe that the values for DCA and FFit decrease as and increase. When and are less than 12, CADPB2 still has the

crease as and increase. When and are larger than four, the change of the values for DCA and FFit is insignificant, which are smaller than that of CADPB1 and CADPB2. The CADPB1 and CADPB2 more fairly allo-cate OVSF codes to different types of calls than that DCA or FFit does. Fig. 10(d) shows that the values for DCA and FFit increase as and increase. When

and , the values for DCA, FFit, CADPB1, and CADPB2 are almost the same.

In summary, the , and performances for DCA and FFit are improved as the buffering mechanism is ap-plied. As the buffer sizes are large enough, DCA and FFit outperform CADPB2 and CADPB1 in terms of the and performances. For the performance, CADPB2 and CADPB1 outperform DCA and FFit in all cases.

However DCA is a rearrangeable scheme. As we pointed out in Section I, there are drawbacks for re-arrangement operations1 _{including increase of system}

complexity and extra message exchanges, and decrease of the QoS of the system. For the FFit scheme, although it is a nonrearrangeable scheme, it cannot fairly allocate the OVSF codes to different types of calls. Especially for high data rate call requests, they are easy to block.

On the other hand, the proposed CADPB1 and CADPB2 are nonrearrangeable schemes. With dynami-cally partitioning OVSF codes (according to the traffic loads of different types of calls), CADPB1 and CADPB2 more fairly serve different types of calls. With dynamic buffering mechanism, the performance for CADPB1 and CADPB2 is better than that of DCA and FFit in some cases. The proposed schemes are also simple and easy to deploy in the real system.

V. CONCLUSION

In this paper, we proposed two nonrearrangeable OVSF code assignment schemes CADPB1 and CADPB2 for UMTS. Both are simple, cost effective, and spectrally efficient for implemen-tation. Many previous papers [7], [8], [12] addressed design re-arrangeable schemes such that the number of the reassignment operations can be reduced, which may increase the complexity of the designed schemes, and lead the schemes not easily to be deployed in the real system. On the other hand, few studies ad-dressed design nonrearrangeable schemes that can provide the QoS as good as or better than the rearrangeable schemes.

Simulation experiments were used to investigate the formances for our proposed schemes. We compared the

per-1_{Note that in [12, Table I] (where Scenario I is considered, and theR and}

3= are set to 256r bits/s and 16, respectively), the authors have shown that on average 0.39 calls should be reassigned OVSF codes to accommodate a new call.

types of calls.

3) The dynamic buffering mechanism in CADPB1 and CADPB2 improves the call acceptance rate by slightly introducing call waiting time.

4) The , and performances for DCA and FFit are improved while buffering mechanism is applied on them. 5) As the buffer sizes are large enough, DCA and FFit out-perform CADPB2 and CADPB1 in terms of the and

performances.

6) For the performance, either DCA and FFit with buffering or not, CADPB2 and CADPB1 outperform DCA and FFit in all cases.

To conclude, our study carried out a detailed comparison for DCA, FFit, CADPB1, and CADPB2. System developers, based on the tradeoffs (given in our study), may choose suitable schemes to be deployed in the real UMTS systems.

ACKNOWLEDGMENT

The authors would like to thank the three anonymous re-viewers, whose comments have significantly improved the quality of this paper.

REFERENCES

[1] 3rd Generation Partnership Project, “Radio interface protocol architec-ture,”, Tech. Rep. 3G TS 25.301 version 3.4.0, Mar. 2000.

[2] 3rd Generation Partnership Project, “Technical specification group radio access network; Spreading and modulation (FDD),”, Tech. Rep. 3G TS 25.213 version 3.5.0, Mar. 2001. 3GPP.

[3] 3rd Generation Partnership Project, “Technical specification group radio access network; Spreading and modulation (TDD),”, Tech. Rep. 3G TS 25.223 version 3.5.0, Mar. 2001. 3GPP.

[4] 3rd Generation Partnership Project, “Technical specification group ser-vices and systems aspects; General packet radio service (GPRS); Ser-vice description; Stage 2,”, Tech. Rep. 3G TS 23.060 version 4.1.0, Jun. 2001. 3GPP.

[5] R. Assarut, K. Kawanishi, U. Yamamoto, Y. Onozato, and M. Matsushita, “Region division assignment of orthogonal vari-able-spreading-factor codes in W-CDMA,” in Proc. IEEE VTC2001, 2001, pp. 1884–1888.

[6] R.-G. Cheng and P. Lin, “OVSF code channel assignment for IMT-2000,” in Proc. IEEE VTC2000-Spring, 2000, pp. 2188–2192. [7] M. Dell’Amico, M. L. Merani, and F. Maffioli, “Efficient algorithms for

the assignment of OVSF codes in wideband CDMA,” in IEEE Int. Conf.

2002, 2002, pp. 3055–3060.

[8] , “A tree partitioning dynamic policy for OVSF codes assignment in wideband CDMA,” IEEE Trans. Wireless Commun., vol. 3, pp. 1013–1017, Jul. 2004.

[9] H. Holma and A. Toskala, WCDMA for UMTS. New York: Wiley, 2000.

[10] P. Lin and Y.-B. Lin, “Channel allocation for GPRS,” IEEE Trans. Veh.

Technol., vol. 50, pp. 375–387, Mar. 2001.

[11] P. Lin, Y.-B. Lin, and J.-Y. Jeng, “Improving GSM call completion by call reestablishment,” IEEE J. Sel. Areas Commun., vol. 17, pp. 1305–1317, Jul. 1999.

[12] T. Minn and K.-Y. Siu, “Dynamic assignment of orthogonal variable-spreading-factor codes in W-CDMA,” IEEE J. Sel. Areas Commun., vol. 18, pp. 1429–1439, Aug. 2000.

[13] F. Shueh and W.-S. Eric Chen, “Code assignment for IMT-2000 on for-ward radio link,” in Proc. IEEE VTC2001-Fall, 2001, pp. 906–910. [14] Y. Yang and T.-S. P. Yum, “Nonrearrangeable compact assignment of

or-thogonal variable-spreading factor codes for multi-rate traffic,” in Proc.

IEEE VTC2001-Fall, 2001, pp. 906–910.

Phone Lin (M’02) received the B.S.C.S.I.E. and

Ph.D. degrees from National Chiao Tung University, Taiwan, R.O.C., in 1996 and 2001, respectively.

From August 2001 to July 2004, he was an Assistant Professor in the Department of Computer Science and Information Engineering (CSIE), National Taiwan University, Taiwan. Since August 2004, he has been an Associate Professor there. His current research interests include personal communi-cations services, wireless Internet, and performance modeling. He is an Associate Editorial Member for the WCMC Journal.

Dr. Lin is a Guest Editor for the IEEE WIRELESSCOMMUNICATIONSSpecial Issue on Mobility and Resource Management. He is actively involved with IEEE INFOCOM’05.P.

Chai-Hien Gan was born in Malaysia in 1971. He

re-ceived the M.S.C.S.I.E. degree from National Taiwan University, Taipei, Taiwan, R.O.C., in 1996, where he is currently pursuing the Ph.D. degree in the De-partment of Computer Science and Information En-gineering.

His current research interests include mobile com-puting, personal communications services, and wire-less Internet.

Ching-Chi Hsu was born in Taipei, Taiwan, R.O.C.,

in 1949. He received the B.S. degree in physics from National Tsing Hwa University, Hsishu, Taiwan, in 1971 and the M.S. and Ph.D. degrees in computer en-gineering from Electrical Enen-gineering Department, National Taiwan University, Taipei, Taiwan, in 1975 and 1982, respectively.

In 1977, he joined the Faculty of the Department of Computer Science and Information Engineering, Na-tional Taiwan University, and became an Associate Professor in 1982. During 1987 and 2002, he was first engaged as a Professor and became Chairman of the department. During his tenure at National Taiwan University, he was a Visiting Scholar in the Com-puter Science Department, Stanford University, from 1984 to 1985. After 25 years at National Taiwan University, he became President of Kai Nan Univer-sity in 2002. Since February 2004, he has been Executive Vice President of the Institute for Information Industry, in which he is mainly in charge of accelerating the growth of information industry in the whole nation. His research interests include distributed processing of data and knowledge, mobile computing, and wireless networks.