nce it can be applied to 7 Dimensioning for Single IP-Based lub efficiently dimension IP bandwidth of the lub link and promise multi-service QoS provisioning in the UTRAN. required total NRT IP BW for NRT RAB 64 delay QoS required total NRT IP BW for NRT RAB 128 delay QoS Simulations Simulations M/G/R/N-PS M/G/R/N-PS AF11 app. delay (s) AF21 app. delay (s) required total NRT IP BW for NRT RAB 384 delay QoS required total NRT IP BW for NRT HSPA BE delay QoS Simulations Simulations M/G/R/N-PS M/G/R/N-PS AF 41 app. delay (s) BE app. delay (s) Figure 7.3: Validation of M/G/R/N-PS Model - IP bandwidth 7.3.3 Dimensioning Procedure The above analytical approach is able to estimate the achieved average application performance in terms of mean transfer delay or application throughput for each AF or BE PHB. Given a specific application QoS per service class, the required IP bandwidth for meeting the QoS of that service class can be derived with the presented analytical model. For the dimensioning process, the total required IP bandwidth on the lub link needs to fulfill the QoS requirements of all service classes. It can be derived with the following steps. 1) For one service class of elastic traffic, the required total IP bandwidth can be derived numerically by performing delay calculations for a range of configured IP bandwidths until the resultant average transfer delay from a certain IP bandwidth reaches the desired application delay QoS of that service class. 7.3 Dimensioning for Elastic Traffic 2) Repeat the above step 1) for all service classes. Then for each service class k, there is one dimensioned IP bandwidth that satisfies the delay QoS of that service class IP_BW_NRT 3) Take the maximum IP bandwidth from all IP_BW_NRT (k) to be the dimensioned bandwidth for that link, as it will satisfy the QoS requirements of each service class. 4) If there are additional IP bandwidths reserved for Real Time (RT) (derived from MD- Erlang) or signaling traffic (e.g. DCCH, CCCH), then these extra bandwidths also need to be added