 the lub interface. There are three main reasons: (1) HSPA consists of mainly interactive or background services which have much more relaxed requirements on the delay than the real time services; (2) in HSPA network the radio related control functions is shifted from RNC Node B, such as the fast packet scheduling and fast retransmissions are located at the Node B A.15 Dimensioning for HSPA Traffic now, SO there is no tight transport delay requirement on the lub interface as in Re199; (3) In order to protect from the heavy congestion situation on the lub interface, a congestion control scheme is applied in HSPA, with which the long buffering delays and the resultant packet losses can be avoided. Therefore, for the HSPA traffic the transport network delay and packet discard are no longer the major QoS issue for the lub, instead the user-relevant application QoS becomes the main objective of dimensioning. Framework for the Dimensioning of HSPA This section presents a general framework for dimensioning the lub interface to transport the HSPA traffic (valid for both HSDPA and HSUPA). In order to properly dimension the backhaul bandwidth for the ATM-based lub interface, The following aspects need to be determined: (1) how many HSPA cells are supported by one Node B; (2) how many HSPA UEs are active in each cell; (3) how much is the entire air interface capacity of each HSPA cell and the scheduled data rate of HSPA UEs; (4) what are the applications and services to be transferred via HSPA; (5) is there any additional traffic control functions applied on the lub interface to avoid or diminish the link congestion; (6) at last the desired QoS target for the dimensioning. To include all the above facts into the dimensioning framework, we can summarize them into the following factors to be considered for the lub dimensioning in HSPA: (1) The number of HSPA cells supported by the lub link, depicted by K (2) The number of HSPA UEs of cell i, depicted by N: (3) The air interface capacity of cell i, depicted by Ci; (4) The traf