Radio resource management schemes for combined GSM/GPRS mobile systems

WIRELESS COMMUNICATIONS AND MOBILE COMPUTING Wirel. Commun. Mob. Comput. 23; 3:357 384 (DOI: 1.12/wcm.96) Radio resource management schemes for combined GSM/GPRS mobile systems C. N. Konstantinopoulou, K. A. Koutsopoulos, P. P. Demestichas and M. E. Theologou*, National Technical University of Athens (NTUA) Department of Electrical and Computer Engineering 9 Heroon Polytechniou Street GR 157 73 Zographou Athens Greece G. L. Lyberopoulos COSMOTE Mobile Telecommunications S.A Department of Switching and Network Management 9 Marinou Antypa GR 141 21 N. Iraklion Athens Greece Summary Data services like Web browsing, e-mail and file transfer are becoming more and more popular in cellular systems. In contemporary systems like Global System for Mobile communications (GSM), data transfer has been circuit-switched, that is, physical resources are allocated to a user for the entire call/session duration. However, this is inefficient in case of bursty traffic, where bursts are separated by long intervals of inactivity. This has been the main reason for the introduction of General Packet Radio Service (GPRS), which on the one hand acts as a mobile access network to the Internet, while on the other hand it enables the operator to offer a wide variety of value-added services [Wireless Access Protocol (WAP) over GPRS, e/m-banking, e/m-commerce, push services, etc.] efficiently. However, in contemporary commercial implementations of GPRS the radio resource allocation algorithm does not take into account the Quality of Service (QoS)-related service characteristics although such information is exchanged between the terminal and the network and consequently all service requests are treated the same way ( best effort ). In this paper, we propose and evaluate via a simulation platform various Radio Resource Management (RRM) schemes capable of differentiating the handling of service requests (in uplink and downlink), taking into account the GPRS-related QoS parameters (precedence, reliability, delay, mean and peak throughput). The evaluation is performed for a range of voice (circuit-switched) traffic loads, number of Transmit Receive exchange (TRXs), offered data (packet-switched) services characteristics, number of dedicated Packet Data Channels (PDCHs), and so on, taking into account the respective QoS requirements for both service types (circuit- and packet-switched). Copyright 23 John Wiley & Sons, Ltd. Ł Correspondence to: M. E. Theologou, National Technical University of Athens (NTUA), Department of Electrical and Computer Engineering, 9, Heroon Polytechniou Street, 157 73, Zographou, Athens, Greece. E-mail: theolog@cs.ntua.gr Copyright 23 John Wiley & Sons, Ltd.

358 C. N. KONSTANTINOPOULOU ET AL. KEY WORDS GPRS traffic source models interactive services background services QoS parameters GPRS QoS profile radio resource management (RRM) priority-based RRM schemes 1. Introduction The impressive growth of cellular mobile telephony, as well as the number of Internet users, promises an exciting potential for a market that combines both innovations, that is the cellular wireless data services. It is foreseen that within the next few years there will be an extensive demand for wireless data services. In particular, it is expected that data usage drive up traffic per user as much as 3 to 5 per cent and may also act as a stimulator of additional voice calls, as already witnessed with voice mail. To cope with the inefficiencies, which are inherent to contemporary GSM technologies mainly related to inefficient use of radio resources the GPRS is conceived as the first vital step toward the provision of higher speed data rates. The GPRS, by enabling much more effective data use of the radio spectrum, will allow operators to develop new applications with richer content (e.g. location-based information in conjunction with geographical data) and therefore to further enhance their business role. GPRS may increase the data transfer speed (beyond 1 kb/s), offering session establishment times below one second. We shall stress that the actual transfer rate of a single session depends on a variety of factors that are relevant both to the terminal [multislot capability, Coding Scheme (CS)] and the network (number of active terminals, CSs supported, the utilized slot assignment scheme, the currently available bandwidth for GPRS services, etc.). In addition, GPRS may offer a user-friendlier billing compared to current charging models based on call/session duration since it allows charging based on the volume of transferred data. The advantage for the user is that he/she can be always connected and that charging may be based on the transferred data volume. However, the realization of the GPRS system requires upgrades to the existing GSM network elements (BTS, BSC, MSC and HLR ) as well as the implementation of an IP-based backbone network (Figure 1) consisting of new GPRS-related network elements (SGSN, GGSN, BG, CG, DNS, DHCP/RADIUS, FW ). The GSM/GPRS air-interface will be capable of supporting efficiently circuit-switched and packetswitched (GPRS) traffic demands, taking into account the application/service related QoS parameters. In addition, it is envisaged that owing to the extra GPRS traffic/signaling both the signaling traffic and the overall interference level will increase. To sum up, GPRS improves the utilization of the radio resources, may offer volume-based billing, higher transfer rates, shorter access times, and simplifies the access to packet data networks (e.g. internet) [1 3]. As far as radio resource allocation is concerned, European Telecommunications Standards Institute (ETSI) proposes the fixed and on-demand channel allocation mechanisms [4]. P. Lin and Y. Lin have proposed and evaluated the following four resource allocation mechanisms [5]: (i) Fixed Resource Allocation (FRA), (ii) Dynamic Resource Allocation (DRA), (iii) Fixed Resource Allocation with Queue capability (FRAQ) and (iv) Dynamic Resource Base Transmitter Station (BTS), Base Station Controller (BSC), Mobile Switching Center (MSC), Home Location Register (HLR). Serving GPRS Support Node (SGSN), Gateway GPRS Support Node (GGSN), Border Gateway (BG), Charging Gateway (CG), Domain Name Server (DNS), Dynamic Host Configuration Protocol (DHCP), Remote Access Dial- In User Service (RADIUS), Firewall (FW).

RADIO RESOURCE MANAGEMENT SCHEME 359 PSTN BSC MSC Internet Intranet Um RADIUS/ DHCP SGSN BG GPRS GPRS Backbone backbone SS7 CG GGSNs Billing System FW HLR AuC EIR Router Corporate LAN Server Inter-PLMN DNSs To OMC Internet To other PLMNs Intranet Fig. 1. GPRS architecture. Allocation with Queue capability (DRAQ). However, none of these algorithms considers (circuit-switched) voice priority, neither takes into account the QoS characteristics of data sessions. Fixed and on-demand channel allocation have also been investigated by Stuckman and Muller [6,7]. In Reference [6], no voice traffic has been considered in the system, while in Reference [7], circuit-switched voice calls are assigned higher priority than data services, but no distinction between data requests has been implemented. In Reference [8] Stuckman and Muller studied the issue of QoS management of GPRS resources. The data rate and the one-way delay have been considered as QoS parameters, while the traffic source models described in Reference [9] have been adopted. The aim of this paper is to investigate and evaluate (via a simulation platform) various RRM schemes capable of differentiating the handling of service requests (in uplink and downlink) taking into account GPRS-specific QoS parameters. The evaluation will be performed for a range of voice (circuit-switched) traffic loads, number of TRXs, offered services, number of dedicated PDCHs, and so on, taking into account the respective QoS requirements for both service types (circuit- and packet-switched). The simulation platform through which the evaluation of the proposed RRM schemes has been performed exhibits the following capabilities [1]: ž Handling of any number of TRXs. ž Adoption of the frame structure as specified in Reference [4] for GSM/GPRS. ž Uplink and downlink transmissions are performed according to Reference [4]. More specifically, up to seven transmissions (from different terminals jj ) can be assigned to an uplink PDCH, while up to nine transmissions ŁŁ can be assigned to a downlink PDCH. ž Possibility to define dedicated PDCHs for GPRS use only. ž Possibility to assign higher priority to circuitswitched voice calls, by preempting active data sessions. ž Consideration of the GPRS terminal multislot capability in slot assignment procedure. ž Support of all CSs (CS-1, CS-2, CS-3 and CS-4). A dedicated PDCH is a slot that can be used exclusively by GPRS connections. jj DiscriminatedbytheUplink State Flag (USF) value. ŁŁ Discriminated by the Temporary Flow Identity (TFI) value.

36 C. N. KONSTANTINOPOULOU ET AL. ž Adoption of realistic traffic source models for a variety of services. ž Possibility to prioritize services requests, both uplink and downlink, based on the applied RRM scheme (see Section 5). The material included in this paper is organized as follows. In Section 2, the QoS profiles specified for the GPRS system are presented. Section 3 assesses some open issues regarding the radio resource allocation in contemporary GPRS systems. The adopted traffic source models for the various data services and the relative parameters are described in Section 4. In Section 5, we propose priority-based RRM schemes, while in Section 6 evaluation results are presented. Finally, in Section 7 some concluding results have been drawn. 2. QoS Issues In GPRS, the Mobile Station (MS), before any information exchange with the system has to perform the so-called Packet Data Protocol (PDP) context activation procedure in order: (i) to be assigned a (public or private) IP address and (ii) to agree upon a QoS profile. A QoS profile comprises the parameters shown in Table I. The combinations of these parameters result in 1 26 different QoS profiles [2]. In GPRS, we may discriminate four QoS profile types (Figure 2): MS SGSN QoS Requested 1 QoS Negotiated Accept 2 Reject 3 Check QoS Subscribed QoS Negotiated (1) At PDP Context Activation request (2) if (QoS Negotiated) > (QoS Minimum) (3) if (QoS Negotiated) < (QoS Minimum) HLR QoS Negotiated Fig. 2. QoS profile information exchange. GGSN 1. The QoS Subscribed profile that is defined at subscription time and is stored at the HLR. 2. The QoS Requested profile that is sent during the PDP Context Activation. 3. The QoS Negotiated profile containing the QoS parameter values that the system can ensure depending on the current loading conditions and the SGSN/GGSN capabilities. 4. The QoS Minimum profile that contains the minimum acceptable values for each QoS parameter for the specific GPRS service. Even if contemporary commercial implementations of GPRS consider QoS profile information exchange between the MS, the SGSN and the GGSN, they never exploit such information. More specifically, the Table I. QoS parameters. QoS parameters Definition # Values Minimum value Maximum value Precedence class Delay class Reliability class Peak throughput class Mean throughput class Indicates the relative importance of maintaining the service commitments under abnormal conditions (e.g. limited resources, network congestion) Defines the maximum values for mean (end-to-end) and 95-percentile delay to be incurred by the transfer of data through the GPRS network(s) Indicates the transmission characteristics that are required by an application Specifies the maximum rate at which data is expected to be transferred across the network for an individual PDP context Specifies the average rate at which data is expected to be transferred across the GPRS network during the remaining lifetime of an activated PDP context 3 1 (High) 4 1 (Predictive) 5 1 (Nonreal time traffic) 9 1 (8 kb/s) 19 1 (¾.22 b/s) 3 (Low) 4 (Best effort) 5 (Real-time traffic) 9 (248 kb/s) 31 (Best effort)

RADIO RESOURCE MANAGEMENT SCHEME 361 resource management algorithm that is applied does not take into account the specific GPRS QoS parameters of the services requests, that is, all requests are treated the same way ( best effort ) no priority in handling higher priority requests is employed. In addition, the standards have not proposed resource management algorithms that take into account services QoS requirements. This task has been left to the GPRS vendors, and as such the performance of the GPRS air-interface is strongly dependent on the specific resource management scheme applied by the vendor. 3. Radio Resource Management: Open Issues A nonexhaustive list of the RRM schemes open issues is given below: 1. Currently, the RRM scheme does not take into account QoS parameters. Currently, the commercial versions of the GPRS offer the best effort option only. The relation between user/service QoS parameters and network-related ones has to be investigated. 2. Session Admission Control (SAC) algorithm. In addition, the current versions of the GPRS do not employ a SAC algorithm that takes into account the loading conditions of the radio airinterface. 3. Allocation of the GSM and GPRS slots/pdchs onto the TRXs. One of the main RRM issues is the allocation of timeslots/pdchs to circuit- and packet-switched traffic. In contemporary GSM, slot allocation is based on the low interference criterion, that is, an incoming circuit-switched call is assigned to the slot exhibiting the lowest interference level. For the combined GSM/GPRS case, the following two alternatives can be envisaged: a. Apply the low interference criterion for GPRS traffic too. The GPRS data sessions reserve slots/pdchs as GSM calls, based on low interference. However, in this case, the scheme shall take into account that a GPRS session may need Apart from the resource management scheme used, the performance of the GPRS air-interface depends on service behavior (session arrival rate, session duration), user behavior (user tolerance) and network behavior (number of GPRS capable TRXs, cell reselection criteria, delays, packet interarrival times) parameters. to reserve more than one PDCHs (in the same TRX). Unavailability of PDCHs in a single carrier may lead to performance degradation due to assignment of lower number of PDCHs than requested/needed for a single session although there may be available resources in the system. b. Consecutive slot allocation for both GSM and GPRS. According to this scheme, the system assigns consecutive slots to GSM and GPRS requests starting from different carriers (Figure 3). The major advantage of this scheme is that the GPRS performance is not compromised. On the contrary, it may lead to increase in intracell handovers (under high loading conditions). 4. PDCH selection to be preempted by incoming circuit-switched call during congestion. Criteria shall be defined for the selection of the proper PDCH to be preempted, such as the number of assigned USFs per PDCH. 5. The mechanism that selects the proper PDCHs during the activity periods of a data session so as to satisfy the QoS Negotiated parameters. An efficient RRM scheme will be capable of prioritizing service requests and assigning the proper number of PDCHs as well as those that can provide the maximum throughput (if possible) so as to respect the QoS Negotiated parameter values. 4. Traffic Source Models Source modeling is one of the most important issues that has to be dealt with in this paper, since it is one of the critical parameters that determines the overall performance of the GPRS. We shall stress though that it is impossible to define a generic source model representing all possible service types, for example, conversational, streaming, interactive and background [11]. However, independently of the service type, the traffic source model shall take into account the following: Interactive services are typical instant response-request messaging services. Example services are Web browsing, database retrieval, server access, polling for measurement records and automatic database enquiries (telemachines). In this service type, the end user (typically a computer) sends and receives data files in the background. Examples are background deliveries of e-mails, database downloads, reception of measurement records, and so on.

362 C. N. KONSTANTINOPOULOU ET AL. TRX #1 1 2 3 4 5 6 7 1 2 3 4 5 6 7 C C C C Signaling TRX #2 TRX #3 C C C C C C C C C C C C C Circuit-swithced slots Slots occupied by circuit-swithced voice GPRS PDCHs TRX #4 C C C Dedicated GPRS PDCHs GSM/GPRS border GSM/GPRS border Fig. 3. Consecutive slot allocation. ž A data session consists of a sequence of packet calls, each composed of a (bursty) sequence of datagrams. ž Session parameters such as number of packet calls per session, number of datagrams/packet call, packets interarrival time, packet call size. ž User behavior parameters (e.g., user tolerance). Since this paper focuses on GPRS, we only consider interactive and background service classes; more specifically Web-browsing, ftp upload, ftp download. The source models for the above-mentioned service types are described in the following subsections. 4.1. Interactive Services A typical example of a Web-browsing data session is depicted in Figure 4, while its detailed traffic source model is shown in Figure 5. As shown, four different states can be identified: ž Active state (A active, B inactive). The user initiates a request. As shown, the user (A) is active, while User request Uplink Downlink Waiting state A packet call A data session Reading state Waiting state Datagrams Fig. 4. Example of a Web-browsing data session. t t the host (B), which for example is the Web server for Web-browsing, is inactive. ž Waiting state (A inactive, B inactive). This state represents the time interval between the completion of transfer of user request for uplink and the beginning of downlink transmission. This state includes delays due to GPRS network itself as well as external networks (e.g. Internet). ž Receiving information state (A inactive, B active). This state represents the download information transfer phase. ž Reading state (A inactive, B inactive). It represents the time that the user needs to read the downloaded information before proceeding in a new request. The active state can be decomposed in several phases. First, the MS sends a packet channel request and enters the contention phase. On collision, the MS sends again its request after back-off time. If no collision occurred, but there are no available uplink PDCHs, the request is queued. When the system finds resources, it sends the uplink Packet Assignment Message (PAM) to the MS, containing a list of assigned PDCHs, the USF(s) per PDCH(s), the TFI, as well as timing advance and power control information, if available. The MS monitors the PDCHs in the downlink channel, in order to identify its USF(s). If the MS detects its USF(s), it transmits a radioblock to the corresponding uplink PDCH(s). After the radioblock transmission, if the MS has more information to send, it waits until it listens to its USF(s) again [3,4]. In the downlink, the system after a certain number of MS radioblocks (e.g. 1 to 15) sends positive acknowledgments (ACKs) to verify The radioblock is the basic transmission unit in GPRS and it is formed by four slots in consecutive TDMA frames.

RADIO RESOURCE MANAGEMENT SCHEME 363 Session setup Active state Packet channel request Contention ti Session release (*) List of uplink PDCHs, USF per PDCH, TFI, timing advance, power control (*) ) Wait for packet uplink assignment Packet uplink assignment Check assigned PDCHs for its own USFs Uplink transmission of a radioblock per assigned PDCH (**) List of Downlink PDCHs, TFI, Timing Advance, Power Control Wait for Packet Downlink Assignment (**) Waiting state Fig. 5. Detailed source traffic model for Web-browsing. Reading state Check assigned downlink PDCHs for its own TFI Receiving info state that information has been received successfully, or negative acknowledgments (NACK) indicating the erroneous radioblocks. If there is information to be sent to the MS, the system sends a downlink PAM, containing a list of downlink PDCHs, the TFI, as well as timing advance and power control information, if available. The MS monitors the assigned downlink PDCHs, in order to identify the packets addressed to it through its TFI. Downlink packets are kept in a queue until downlink resources become available and each time a single radioblock is transmitted in each assigned PDCH, until the downlink information is successfully completed [3,4]. After this phase, the user shall read the downloaded information, and then proceeds in requesting a new packet call (in the same session), thus returning to the contention phase. As before, ACKs/NACKs are sent periodically in the uplink to verify the correct transmission of data or to indicate the erroneous radioblocks and ask for retransmission. We shall stress that the user may initiate a session release: 1. In the active state, if he waits for a long time in the uplink queue until the system finds available resources. 2. When the downlink response is too delayed. 3. After the reading state where the user can decide to initiate a request for a new session, releasing at the same time the existing one. 4.2. Background Services 4.2.1. Upload background services A detailed traffic source model for a background upload service (suitable for e-mail, FTP upload, etc.) is depicted in Figure 6(a). As it is shown, the model is similar to the one described for interactive services, as far as uplink transmission concerns. The difference in this case is that there is only one contention phase. After the assignment of required PDCHs to the MS, the uplink transmission is performed in the specific resources, whenever the MS identifies its USF in the downlink, until the completion of the data upload. In the downlink channel, the system sends ACKs periodically to verify that information has been received successfully or NACKs indicating the erroneous radioblocks. Normally, session release occurs when the user has successfully transmitted the entire information. Abnormal session release may be initiated either by the system or the user himself whenever the QoS falls below certain limits for example, so far offered mean bit rate falls below a certain percentage

364 C. N. KONSTANTINOPOULOU ET AL. (a) Session setup Packet channel request Contention Session release Wait for packet uplink assignment (*) List of uplink PDCHs, USF per PDCH, TFI, timing advance, power control (*) Packet uplink assignment Check assigned PDCHs for its own USFs Uplink transmission of a radioblock per assigned PDCH (b) Session setup Active state Packet channel request Contention Session release Wait for packet uplink assignment (*) List of uplink PDCHs, USF per PDCH, TFI, timing advance, power control (* ) Packet uplink assignment Check assigned PDCHs for its own USFs Uplink transmission of a radioblock per assigned PDCH (**) List of downlink PDCHs, TFI, timing advance, power control Wait for packet downlink assignment (**) Waiting state Check assigned downlink PDCHs for its own TFI Fig. 6. (a) Traffic source model for background upload services and (b) detailed traffic source model for background download services. (e.g. 6% to 7%) and remains there for a certain time period (e.g. 3 min). 4.2.2. Download background services In the case of a download background service the detailed traffic source model is depicted in Figure 6(b). As it is shown, the session set-up procedure and the transmission of the uplink request are performed as previously. There is only one contention phase, and after the assignment of resources and the successful transmission of the uplink request, the system sends a downlink PAM and the user starts

RADIO RESOURCE MANAGEMENT SCHEME 365 monitoring the assigned downlink PDCHs to identify the packets addressed to him through his TFI. Both downlink and uplink transmissions are performed in radioblocks, as described for interactive services. As before, ACKs/NACKs are sent periodically in the uplink to verify the correct transmission of data or to indicate the erroneous radioblocks and ask for retransmission. After the completion of download phase, a normal session release follows. Abnormal session release may be initiated either by the system or the user himself whenever the QoS falls below certain limits, for example, so far offered mean bit rate falls below a certain percentage (e.g. 6% to 7%) and remains there for a certain time period (e.g. 3 min). 4.3. Source Models Parameters The source models parameters for interactive and background services are listed below [12]: ž Service APN. This is a descriptive name, the Access Point Name (APN), sent during the PDP Context Activation (e.g. wap, internet ). It can be utilized as an extra priority level for services having the same precedence class (e.g. health-care applications and Web-browsing of the same precedence class). ž QoS parameters. Precedence, Delay, Reliability, Peak Throughput and Mean Throughput class ([2]). ž Service parameters (Table II), which characterize the service behavior; these are as follows: Number of packet calls per session, N pc.this is a geometrically distributed random variable with a mean µ Npc (packet calls). Packet call size, S pc. The size of the packet call (bytes). This follows Pareto distribution with cut-off. Datagram Size, S d. Uniformly distributed between an upper and a lower bound (bytes). Table II. Interactive and background traffic source model parameters. Service characteristics Interactive Download background Upload background p p p N pc p D pc (sec) p N/A p N/A D rr (sec) p p N/A p N d p p p D d (sec) p p p S d (bytes) User behavior p N ur p N/A N/A T ut (sec) N/A N/A Interarrival time between datagrams within a packet call, D d. This is an exponentially distributed random variable with a mean µ Dd (model time steps). Reading time between packet calls, D pc.this is an exponentially distributed random variable with a mean µ Dpc (model time steps). Note that the reading time starts when the last datagram of the packet call is successfully received by the user and ends normally when the user makes a new request. GPRS and external network(s) delay, D GI.This is an exponentially distributed random variable with a mean µ Drr. This parameter represents the time interval between the successful transmission of the uplink packet call and the transmission of the first datagram in the downlink. ž User behavior parameters (Table II), which characterize the user behavior; these are as follows: User tolerance time, T ut. This is a constant variable, which mostly models user behavior. This time starts after the user uplink packet channel request. If this time expires before the user has received the expected information, the user makes a retry for the same request. Maximum number of user retries, N ur.thisis a constant variable representing the maximum number of user retries performed in the case that the user tolerance time has expired before the complete reception of the expected information. 5. Proposed RRM Schemes In our study, we propose and evaluate a number of RRM schemes, which enable services prioritization, based on precedence, service APN and mean throughput QoS parameters. As such, the following schemes have been implemented: PST: Prioritized by Precedence Service APN mean Throughput PTS: Prioritized by Precedence class mean Throughput Service APN TSP: Prioritized by mean Throughput Service APN Precedence class TPS: Prioritized by mean Throughput Precedence class Service APN STP: Prioritized by Service APN mean Throughput Precedence class SPT: Prioritized by Service APN Precedence class mean Throughput

366 C. N. KONSTANTINOPOULOU ET AL. Note: For the sake of comparison, the classical nonpriority ( best effort ) scheme, the so-called Round Robin (RR) scheme has been implemented. 5.1. Priority-based RRM Schemes 5.1.1. Call/session admission control When a new voice call arrives, the system searches for a free slot in both uplink and downlink. If not found and if there are PDCHs allocated to GPRS (not dedicated), it will preempt a PDCH (uplink and downlink) and allocate it to the incoming voice call. The selection of the proper GPRS PDCH will be based on the following: ž The number of packet calls that each GPRS PDCH serves. ž The number of packet calls of services with the highest priority that each GPRS PDCH serves. Otherwise, the voice call is blocked. Note: Voice call dropping has not been considered because (a) intracell handovers are not performed because of radio quality violation but for respecting the consecutive slot implementation (Figure 3) and (b) intercells handovers have not been assumed. All incoming data sessions enter the system session blocking is not performed. An active data session is dropped when the QoS parameters are violated as described in Sections 4.1 and 4.2. 5.1.2. Slot allocation to GSM/GPRS domain In our study, we have adopted the consecutive slot allocation scheme (Figure 3) that operates as follows: the assignment of slots to circuit-switched connections starts from the beginning of the first TRX, while for the GPRS connections the allocation of PDCHs starts from the end of the last TRX. Every slot may be used either by GSM or GPRS connections, unless a slot has been characterized as dedicated PDCH. If dedicated PDCHs have been defined by the operator, these should be located at the end of the last TRX (Figure 3). Additionally, the PDCHs that have been assigned to a terminal for transmission or reception must belong to the same TRX. 5.1.3. Upgrading/downgrading the GPRS domain A GPRS domain upgrade is issued when a certain percentage (e.g. 8%) of the USFs of the existing PDCHs have been allocated to data sessions. In the case that available slots are found in another TRX, an intracell handover shall be performed first (Figure 3). If the GPRS domain upgrade fails, the request is reactivated as soon as a slot is released. A GPRS domain downgrade occurs whenever a PDCH preemption occurs. 5.1.4. PDCH/USF assignment mechanism The proposed PDCH/USF Assignment Mechanism is responsible for allocating the proper number of USFs to packet calls, determines which packet call(s) shall transmit a radioblock and when. It is obvious that such a mechanism shall guarantee the QoS negotiated of the active packet calls, ensuring at the same time that high priority services have a special treatment. Services prioritization is implemented by a (fixed length) queue per PDCH, containing all the packet calls to which a USF has been assigned (see Figure 7). It is evident that a packet call may have many instances (entries in queues) depending on the number of USFs currently allocated to it. Packet calls that do not have any assigned USF(s) (e.g. during congestion periods) are stored in a separate queue, the so-called pending queue. The handling of a new uplink packet call is depicted in Figure 8(a). As shown, as soon as the contention phase is completed successfully, the system checks whether there is an available USF jjjj in one of the existing PDCHs. ž If available, a PAM is sent to the MS, which starts monitoring the assigned PDCH in order to listen its USF. As soon as it detects its USF, it transmits a radioblock starting from the next frame. It shall be stressed that a radioblock transmission implies that the packet call has been placed first in the queue of the corresponding PDCH, as indicated by the applied RRM scheme. Additional USF/PDCH (if available) may be assigned to the corresponding packet call, if the QoS-related system measurements (e.g. mean throughput) dictate so. Release of a USF may occur when (i) the corresponding USF/PDCH is preemptied by a circuitswitched call (Note 1), (ii) a higher priority packet call, for which the QoS-negotiated profile is not respected, is assigned the USF, or (iii) the (so-far) jjjj In the PDCH currently offering the maximum throughput, if possible.

RADIO RESOURCE MANAGEMENT SCHEME 367 GSM/GPRS border Applied RRM scheme: 1. Precedence 2. Service ID 3. Mean throughput GSM/GPRS border t 1 2 3 4 5 6 7 t +1 1 2 3 4 5 6 7 Comparison P=1 P=1 P=1 P=1 P=1 P=1 Transmission of S=1 S=1 S=1 S=1 S=1 S=1 T=11T=12T=12 T=11T=12T=12 a radioblock/pdch P=1 P=1 P=2 S=2 S=1 S=2 T=11T=11T=11 P=1 P=1 P=2 S=2 S=1 S=2 T=11T=11T=11 P=1 P=1 P=2 S=2 S=2 S=2 T=1T=11T=1 P=1 P=1 P=2 S=2 S=1 S=2 T=1T=1T=1 P=2 P=1 P=2 S=1 S=2 S=2 T=11T=1 T=9 P=2 P=1 P=2 S=1 S=2 S=2 T=11T=11 T=9 P=2 P=2 P=3 Preemption P=2 P=1 P=3 S=2 S=3 S=2 T=11T=1 T=1 of the packet call with the lowest S=2 S=2 S=2 T=11T=1T=1 P=2 P=2 P=3 QoS requirements P=2 P=2 P=3 S=2 S=3 S=2 & S=2 S=3 S=2 T=1 T= 9 T= 9 queues sorting T=1T=1 T=9 P=3 P=3 P=3 P=3 P=2 P=3 S=2 S=3 S=3 S=2 S=3 S=3 T=11 T= 9 T=1 T=11 T= 9 T=1 New P=1 arrival S=1 T=1 P=2 P=2 P=2 P= P= P= S=2 S=2 S=2 S= S= S= P=2 P=2 P=2 P=3 P= P= P= S=2 S=2 S=2 S=3 S= S= S= T=12T=11T=1 T= T= T= T=12T=11 T=1 T= 9 T= T= T= Pending queue Pending queue Fig. 7. PDCH assignment scheme an example. offered mean throughput exceeds a certain percentage (e.g. 2%) of the negotiated one (Note 2). In any case of USF(s)/PDCH(s) reallocation a packet reassignment message is sent to the MS. ž If not available, the comparison phase starts. During this phase it is checked whether the new packet call has higher priority as dictated by the RRM scheme than at least one packet call to which a USF has currently been allocated to. If so, the USF of the existing packet call with the lowest QoS requirements is released and assigned to the new packet call. Otherwise, the new packet call enters the pending queue. Note: Packet calls in pending queue are also sorted according to the applied RRM scheme and the first is assigned a USF when a packet call transmission has been completed successfully. As shown in Figure 8(b), the downlink packet call transmission is similar to the uplink one, apart from the use of TFI(s) instead of USF(s). 5.2. Nonpriority-based RRM Schemes In the RR RRM scheme, the slot allocation to GSM and GPRS domains, the call/session acceptance control algorithm and the GPRS upgrade/downgrade procedures are performed as described in the priority-based schemes. However, in this case, the PDCH/USF assignment is performed on a roundrobin basis that is, prioritization in USF and pending queues is not considered. 6. Case Studies and Results 6.1. Generic Working Assumptions ž Studies are restricted in a single cell. ž MSs are uniformly distributed within the cell area. ž Terminal multislot capability: 3 C 1 (3 slots downlink and 1 slot uplink). ž Mean voice call duration: 6 s. ž Error-free environment has been assumed (ideal C/I). ž QoS criteria: Voice call blocking probability 1% Data session dropping probability 1%. ž All CSs are supported. More specifically, three CS zones have been defined: Zone A (close to the cell border), where the CS-1 and CS-2 are available Zone B (in the inner part of the cell), where CS-2 and CS-3 are available

368 C. N. KONSTANTINOPOULOU ET AL. (a) Uplink packet call (PC) request Contention successful? YES NO YES 1 USF (PDCH) available? YES NO Packet assignment message New PC Higher priority (*) than at least one existing PC? YES Release USF from the PC with the lowest QoS requirements NO (*) Based on applied RRM scheme Pending queue Release resources Additional USFs/PDCHs? (Note 2) NO (Note 1) MS waits for its USF(s) Radioblock transmission per PDCH Only assigned USF of preemptied PC? YES NO Update system statistics NO Last radioblock? YES Packet reassignment message END (b) Downlink packet call arrival YES 1 TFI (PDCH) available? YES NO Packet assignment message New PC Higher priority (*) than at least one existing PC? YES Release TFI from the PC with the lowest QoS requirements NO (*) Based on applied RRM scheme Pending queue Release resources Additional TFIs/PDCHs? (Note 2) NO (Note 1) MS waits for its TFI(s) Radioblock transmission per PDCH Only assigned TFI of preemptied PC? YES NO Update system statistics NO Last radioblock? YES Packet reassignment Message END Fig. 8. (a) Uplink data transfer and (b) downlink data transfer.

RADIO RESOURCE MANAGEMENT SCHEME 369 Zone C (close to the BTS), where CS-3 and CS-4 are available. The data sessions are equally distributed among the zones A, B and C, while in each zone the corresponding CSs have been equally utilized (Figure 9). ž Simulation time depends on the time the system needs to converge in terms of QoS criteria for both voice and data. Table III depicts specific working assumptions for the case studies that have been performed and are described in the following sections. The results concern a set of performance parameters shown in Table IV. 6.2. Case Study I The aim of this study is to assess the performance ŁŁŁ of a GSM/GPRS radio link for a range of voice traffic loads. The study has been performed for CS3 CS4 Zone A Zone B Zone C Fig. 9. Coding schemes zones. CS1 CS2 CS2 CS3 ŁŁŁ The system performance is expressed as the maximum CAR of offered services that the system can withstand respecting the QoS parameters. ž a single data service (Web-browsing), ž one and two TRXs, ž various data services characteristics (e.g. number of packet calls per session, packet call size), ž use of dedicated PDCHs or not. The results concern a set of performance parameters such as ž the maximum supported Call Arrival Rate (CAR) for the data service for various voice traffic loads, ž the percentage of slot utilization (for GSM and GPRS), ž the mean access delay (both uplink and downlink) for the data service, ž the maximum supported CAR for the data service for different number of packet calls per session, ž the maximum supported CAR for the data service for different packet call lengths, ž the maximum supported CAR for the data service, assuming that the number of dedicated PDCHs ranges from to 4. 6.2.1. Input data The input data for Case study I are depicted in Table V. 6.2.2. Results Figure 1(a) depicts the maximum sustainable CAR for the Web-browsing service for a range of voice CARs, provided that the QoS parameters for both voice and data service are respected. The results indicate that the Web-browsing CAR decreases as voice load increases. This has been expected, as voice calls have higher priority over the GPRS data services implemented as follows: a circuit-switched call will reserve a timeslot (in uplink and downlink) that has been allocated to GPRS if there are no other free timeslots. Table III. Specific working assumptions for each case study. Case study 1 Case study 2 Case study 3 Case study 4 #TRXs 1 2 2 2 2 3 # Signaling channels 1 2 2 2 2 2 # Dedicated PDCHs 4 Assumed services Circuit-switched voice, Web-browsing Circuit-switched voice, gold web, silver Web (Table 6) Circuit-switched voice, Web-browsing, FTP upload, FTP download Circuit-switched voice, Web-browsing, FTP upload, FTP download Applied RRM scheme RR PTS RR PTS PTS

37 C. N. KONSTANTINOPOULOU ET AL. Table IV. Performance parameters. Performance parameters Maximum supported data call arrival rate Voice call blocking probability (%) Data session dropping probability (%) Percentage of slots utilization (%) Mean uplink access delay (sec) Mean downlink access delay (sec) Mean downlink queuing delay (ms/kb) Mean downlink queue transfer rate (KB/s) Mean offered throughput (kbps) Definition The maximum CAR that the system can support provided that the QoS criteria for both voice and data services are respected The percentage of incoming voice calls that have not been accepted by the system owing to resources unavailability The percentage of active data sessions that have not been completed successfully The percentage of traffic slots that have been used for information transfer (voice and/or data) The time between the uplink packet channel request and the start of transmission (first datagram of the packet call) The time between the arrival of a packet call in the downlink queue [PDCH(s) queue(s)] and the start of transmission The total time a kilobyte of information remains in the downlink queues [PDCH(s) queue(s), pending queue] The rate of information leaving the downlink queues, not including the transmission periods The mean throughput that the system managed to offer to the sessions of a data service Table V. Case study 1 input data. Service APN Data services parameters Web-browsing # Uplink packet calls per session 1 # Downlink packet calls per session 1 Uplink packet call size (kb).5 Downlink packet call size (kb) 87.5 Uplink datagram size (bytes) 2 8 Downlink datagram size (bytes) 2 8 Uplink datagram interarrival within a 1 packet call (ms) Downlink datagram interarrival within a 1 packet call (ms) Reading time between packet calls (s) 3 GPRS and external networks delay (s).5 Precedence class GPRS QoS parameters Low Mean throughput (kbps) 4 Peak throughput (kbps) 8 User behavior parameters User tolerance time (min) 5 Maximum number of user retries 3 (data) services. The results indicate that when only voice service is available the overall slot utilization (uplink, downlink) reaches the 6% for voice call blocking probability 1%, while in the presence of GPRS data the downlink slot utilization ranges from 7% to 8%, depending on voice traffic load. Figure 12 illustrates the uplink and downlink access delay for Web-browsing sessions for a range of voice CARs. As shown, the Web-browsing downlink access delay increases as voice traffic load increases. This is justified by the fact that under high voice traffic loads the majority of downlink slots are occupied by voice connections, thus it is more difficult for Webbrowsing sessions to find available slots. The same applies for uplink too. However, the uplink access delay is lower than the corresponding downlink, as the uplink data volume is significantly lower than the downlink one. Figure 13(a) illustrates the impact of the session duration on the system performance, as a function of packet calls per session, considering that the packet call size (kb) remains the same. More specifically we have assumed Figure 1(b) depicts the maximum supported Webbrowsing CAR for 1 and 2 TRXs and for a range of voice traffic loads (up to the maximum voice traffic supported by a single TRX, according to Erlang-B formula). The results indicate that the Web-browsing CAR can at least be double. Figure 11 depicts the percentage of slot utilization in uplink and downlink for GSM (voice) and GPRS ž Case A: 1 packet calls per session ž Case B: 15 packet calls per session As expected, the Web-browsing CAR that the system can support is higher in Case A than the corresponding one for Case B. We shall notice that Case A/Case B CAR is about 1.5, as is the ratio of number of packet calls per session (15/1).

RADIO RESOURCE MANAGEMENT SCHEME 371 (a) 3 Web-browsing CAR (sessions/ h) 25 2 15 1 5 Session dropping 1% Voice blocking 1% 2 4 6 8 1 12 14 Voice CAR (calls/ h) (b) 7 Web-browsing CAR (sessions/ h) 6 5 4 3 2 1 1 TRX 2 TRXs 2 4 6 8 1 12 14 Voice CAR (calls/ h) Fig. 1. (a) Maximum supported web-browsing CAR vs various voice CARs and (b) maximum supported Web-browsing CAR for 1 and 2 of TRXs. 144.27 1.93 6.49 6.49 Voice CAR (calls/h) 13 8 4.36.41.5 9.53 9.53 19.5 19.5 28.76 44.94 44.94 56.8 69.24.58 8.45 1 2 3 4 5 6 7 8 9 % slot utilization GSM uplink GPRS uplink GSM downlink GPRS downlink Fig. 11. Percentage of slots utilization for GSM and GPRS services for various voice traffic loads.

372 C. N. KONSTANTINOPOULOU ET AL. Access Delay (s) 4 3.5 3 2.5 2 1.5 1 Uplink access delay Downlink access delay Session dropping 1% Voice blocking 1%.5 2 4 6 8 1 12 14 Voice CAR (calls/ h) Fig. 12. Web-browsing access delay (uplink and downlink) vs various voice CARs. (a) Web-browsing CAR (sessions/ h) Web-browsing CAR (sessions/ h) (b) 3 25 2 15 1 5 2 4 6 8 1 12 14 6 5 4 3 2 1 Session dropping 1% Voice blocking 1% Session dropping 1% Voice blocking 1% Voice CAR (calls/ h) 1 packet calls per session 15 packet calls per session File size 85 kb File size: 42.5 kb 2 4 6 8 1 12 14 Voice CAR (calls/ h) Fig. 13. (a) Maximum supported Web-browsing CAR for different session durations (# packet calls per session) and (b) maximum supported Web-browsing CAR for different packet call lengths.

RADIO RESOURCE MANAGEMENT SCHEME 373 Web-browsing CAR (sessions/ h) 3 25 2 15 1 5 Voice CAR = 144 calls h 1 Web browsing Web browsing Voice CAR = 8 calls h 1 Voice CAR = 144 calls h 1 Web-browsing CAR 1 2 3 4 Dedicated PDCHs Voice blocking Voice blocking Voice CAR = 8 calls h 1 Voice call blocking probability Fig. 14. Maximum supported Web-browsing CAR and voice call blocking probability vs number of dedicated PDCHs for medium and high voice traffic. 3 25 2 15 1 5 Voice call blocking probability (%) Figure 13(b) illustrates the impact of packet call size on the system performance, considering that the number of packet calls per session remains the same. More specifically we have assumed: ž Case A: 85 kb ž Case B: 42.5 kb (the half of Case A) Results show that in Case A the system can withstand less Web data sessions than in Case B. This has been expected, as in Case A more data have to be transmitted per packet call and consequently per session. Figure 14 depicts the impact of the existence of dedicated PDCHs to the overall system performance, assuming ž the maximum supported voice CAR, which corresponds (for a single TRX) to 144 calls/h, according to Erlang-B formula and ž a medium voice traffic load (8 calls/h). We may observe that as the number of dedicated PDCHs increases, the data CAR increases because dedicated PDCHs cannot be preempted by voice calls. That is why voice call blocking increases too. We shall note that in high voice traffic loads (144 calls/h), the use of dedicated PDCHs is prohibitive, as voice call blocking probability exceeds the limit of 1%. On the contrary, in medium voice traffic loads (8 calls/h) the operator may use up to two dedicated PDCHs, as the criterion voice call blocking probability 1% is respected. 6.3. Case Study II The aim of this study is to investigate how the system performance is affected by the application of various RRM schemes at the presence of more than one data services with different QoS parameters. In particular, we have considered ž a 2 TRX-based GSM/GPRS radio link, ž two data services (Gold Web, Silver Web). The results concern a set of performance parameters such as ž the maximum supported total data CAR for various voice traffic loads and different service mixes, ž the maximum supported total data CAR when different RRM schemes are applied, ž the data session dropping probability, ž the mean downlink queuing delay (s/kb). ž The mean downlink queue transfer rate (kb/s). 6.3.1. Input data The input data for Case study II are depicted in Table VI.

374 C. N. KONSTANTINOPOULOU ET AL. Table VI. Case study 2 input data. Data services parameters Service APN Gold Web Silver Web # Uplink packet calls per session 1 1 # Downlink packet calls per session 1 1 Uplink packet call size (kb).5.5 Downlink packet call size (kb) 87.5 87.5 Uplink datagram size (bytes) 2 8 2 8 Downlink datagram size (bytes) 2 8 2 8 Uplink datagram interarrival within a packet call (ms) 1 1 Downlink datagram interarrival within a packet call (ms) 1 1 Reading time between packet calls (s) 3 3 GPRS and external networks delay (s).5.5 GPRS QoS parameters Precedence class High Normal Mean throughput (kbps) 6 3 Peak throughput (kbps) 1 6 User behavior parameters User tolerance time (min) 5 5 Maximum number of user retries 3 3 6.3.2. Results Figure 15(a) illustrates the maximum total CAR for data services that the system can support, when the PTS RRM scheme is applied, for various voice CARs and different service mixes: ž Case A: 75% Gold Web, 25% Silver Web ž Case B: 5% Gold Web, 5% Silver Web ž Case C: 25% Gold Web, 75% Silver Web As shown in Figure 15(a), as far as the percentage of Gold Web decreases, the maximum total data CAR that the system can support increases. This is justified by the fact that the Gold Web service is more demanding than Silver Web and it also has higher priority based on its precedence class. Figure 15(b) illustrates the maximum total data CAR that the system can withstand (Case B), for a range of voice traffic loads for PTS and RR RRM schemes. For both schemes the restriction that data session dropping probability should be 1% has to be respected. As shown, for PTS scheme the system can support higher data traffic loads, ensuring also that the higher priority service is better served. Figure 16 compares the data session dropping probability for Gold and Silver Web for PTS and RR for Case B, assuming that the same data CARs are offered in both schemes. Results indicate that for Gold Web session dropping ž is lower than the corresponding one of Silver Web when PTS scheme is applied and ž is significantly lower than the corresponding one of Gold Web when RR scheme is applied The low data session dropping for Gold Web in the case that PTS scheme is applied is due to the fact that it is of higher precedence class and thus is served better. In the case that the RR scheme is applied, even if all services are treated the same, data session dropping for Gold Web is high enough because of its increased throughput demands. Figure 17(a) and (b) depict, respectively, the mean downlink queuing delay for Case B when PTS and RR RRM schemes are applied. We have assumed that there is no voice traffic in the system. Results indicate that in the case of PTS the mean downlink queuing delay for Gold Web is significantly lower than that of Silver Web. On the other hand, for RR scheme, the results show that the mean downlink queuing delay is almost the same for both services. This was more or less expected as RR scheme treats all data sessions the same way without taking into account their precedence class value. Figure 18(a) and (b) present how the different RRM schemes affect the mean downlink queuing transfer rate for Case B. We have also assumed no voice traffic in the system. Results indicate that for PTS scheme the mean downlink queuing transfer rate for Gold Web is higher than that of Silver Web. This is justified by the fact that for PTS scheme the higher

RADIO RESOURCE MANAGEMENT SCHEME 375 (a) 3 5% Gold Web -5% Silver Web Overall data CAR (sessions/ h) 25 2 15 1 5 Gold Web Precedence = high Min. throughput = 6 Max. throughput = 1 Session dropping 1% Voice blocking 1% RRM scheme: PTS Silver Web Precedence = normal Min. throughput = 3 Max. throughput = 6 75% Gold Web -25% Silver Web 25% Gold Web -75% Silver Web 2 4 6 8 1 12 14 Voice CAR (calls/ h) (b) Overall data CAR (sessions/ h) 25 2 15 1 5 5% Gold Web 5% Silver Web Session dropping 1% Voice blocking 1% PTS RR 2 4 6 8 1 12 14 Voice CAR (calls/ h) Fig. 15. (a) Maximum supported total data CAR vs various voice CARs for different service mixes and (b) maximum supported total data CAR for different RRM schemes applied. priority service is better served. On the other hand, for RR scheme, the mean downlink queue transfer rate for both services is almost the same, as all offered services are served the same way. 6.4. Case Study III The aim of this study is to investigate the overall system performance for various offered data service mixes. For this study we have considered ž a 2 TRX-based GSM/GPRS radio link, ž the PTS RRM scheme has been selected. The results concern a set of performance parameters such as ž the maximum supported total data CAR for various voice traffic loads and different service mixes, ž the data session dropping probability, ž the percentage of slot utilization (for GSM and GPRS), ž the offered mean throughput for the data services.

376 C. N. KONSTANTINOPOULOU ET AL. 3. 2.5 5% Gold Web 18 ses/h 14.69 ses/h Dropping probability (%) 2. 1.5 1. 25.17 ses/h 21.69 ses/h 4.8 ses/h.5. 2 4 6 8 1 12 14 Voice CAR (calls/ h) Gold Web (PTS) Silver Web (PTS) Gold Web (RR) Silver Web (RR) Fig. 16. Percentage of data session dropping vs various voice CARs for the same data CAR. 6.4.1. Input data The input data for Case study III are depicted in Table VII. 6.4.2. Results Figure 19(a) illustrates the maximum total CAR for data services that the system can support, when the PTS RRM scheme is applied, for various voice CARs and different service mixes: ž Case A: 5% Web-browsing, 25% FTP download, 25% FTP upload ž Case B: 6% Web-browsing, 3% FTP download, 1% FTP upload ž Case C: 5% Web-browsing, 4% FTP download, 1% FTP upload As shown in Figure 19(a), the system performance is mainly affected 1. firstly by the percentage of Web-browsing, owing to the higher precedence class, 2. and secondly by the percentage of FTP download, as system performance is determined by the performance of the downlink direction. Consequently, on the basis of the above the system behaves better for Case A, then Case C and finally Case B. Figure 19(b) depicts the session dropping probability for Case B and for various voice CARs. As shown, session dropping probability remains low for Web-browsing and FTP upload, while it reaches the limit of 1% for FTP download. This is justified by the fact that ž FTP download, like Web-browsing, are downlink demanding services, but FTP download is not served as well as Web-browsing because of its lower precedence class, ž FTP upload is served well, even if it is of low precedence class, because of the low aggregate traffic in the uplink direction. Figure 2 depicts the percentage of slots utilization in uplink and downlink for voice (GSM) and/or data (GPRS) services (Case B). As shown, the percentage of slots utilization ž reaches the 8%, at the presence of voice service only and for voice call blocking probability 1%, ž ranges from 7% to 8% for the downlink when voice and data services coexist, depending on voice traffic load,

RADIO RESOURCE MANAGEMENT SCHEME 377 (a) Queueing delay (ms/ kb) 25 2 15 1 5 Gold Web Silver Web PTS 5% Gold Web 5% Silver Web Voice traffic = calls/h Session dropping 1% 17 18 19 2 21 22 23 24 25 Data CAR (sessions/ h) (b) Downlink queueing delay (ms/ kb) 2 15 1 Gold Web Silver Web RR 5% Gold Web 5% Silver Web Voice traffic = calls/h Session dropping 1% 5 17 18 19 2 21 22 23 24 25 Data CAR (sessions/ h) Fig. 17. (a) Mean downlink queuing delay vs various data CARs for PTS scheme applied and (b) mean downlink queuing delay vs various data CARs for RR scheme applied. ž ranges from 1.78% to 59% for the uplink when voice and data services coexist, depending on voice traffic load, ž the significant difference in uplink and downlink slot utilization for GPRS is experienced because of the asymmetric nature of the data services. Figure 21 illustrates the offered mean throughput for Case B and for various voice traffic loads. As shown, the offered mean throughput seems to be independent from the voice traffic load. We may observe that for all data services the offered mean throughput is higher than the negotiated one. More specifically, ž for Web-browsing: offered mean throughput ¾ D negotiated peak throughput, since it is of higher precedence class, ž for the FTP download: offered mean throughput ¾ D negotiated mean throughput, since it is downlink demanding and of lower precedence class, ž for the FTP upload: offered mean throughput ¾ D negotiated peak throughput, because of the low uplink aggregated traffic.

378 C. N. KONSTANTINOPOULOU ET AL. (a) Downlink queue transfer rate (kb/s) 3 25 2 15 1 5 Gold Web Silver Web PTS 5% Gold Web 5% Silver Web Voice traffic = calls/h Session dropping 1% 17 18 19 2 21 22 23 24 25 Data CAR (sessions/ h) (b) Downlink queue transfer rate (kb/s) 12 1 8 6 4 2 17 18 19 2 21 22 23 24 25 Data CAR (sessions/ h) Gold Web Silver Web RR 5% Gold Web 5% Silver Web Voice traffic = calls/h Session dropping 1% Fig. 18. (a) Mean downlink queue transfer rate for PTS vs various data CARs for PTS scheme applied and (b) mean downlink queue transfer rate for RR vs various data CARs for PTS scheme applied. 6.5. Case Study IV The aim of this study is to estimate the required number of TRXs in a cell, given specific operator s requirements: ž Voice traffic (in Erl) ž Number of circuit-switched voice calls per subscriber during busy hour (incoming and outgoing) ž Mean voice call duration ž Offered data services and services characteristics ž The CAR per GPRS subscriber and per hour for each offered data service ž Number of existing TRXs in the cell ž Supported CSs ž Specific QoS requirements for circuit-switched and packet-switched traffic ž Percentage of GSM subscribers who are GPRS subscribers too ž Percentage of GPRS attached subscribers during busy hour ž Percentage of GPRS attached subscribers who have an active PDP context during busy hour. 6.5.1. Input data The operator s specific input data for Case study IV are depicted in Table VIII.

RADIO RESOURCE MANAGEMENT SCHEME 379 Table VII. Case study III input data. Data services parameters Service APN Web-browsing FTP Download FTP Upload # Uplink packet calls per session 1 1 # Downlink packet calls per session 1 1 Uplink packet call size (kb).5.75 2 Downlink packet call size (kb) 87.5 5.125 Uplink datagram size (bytes) 2 8 75 15 75 15 Downlink datagram size (bytes) 2 8 75 15 75 15 Uplink datagram interarrival within a packet 1 1 1 call (ms) Downlink datagram interarrival within a packet 1 1 1 call (ms) Reading time between packet calls (s) 3 N/A N/A GPRS and external networks delay (s).5 N/A N/A GPRS QoS Parameters Precedence class Normal Low Low Mean throughput (kbps) 4 15 8 Peak throughput (kbps) 8 25 15 User behavior parameters User tolerance time (min) 5 5 5 Maximum number of user retries 3 3 3 Table VIII. Operator s specific input data. Operator s input data Values Voicetraffic(Erl) 4 Number of calls per subscriber during busy hour (incoming and outgoing) 2 Required total data CAR (sessions/h/gprs sub) 3 Offered data services characteristics Table 7 Traffic mix (Web-browsing, FTP download, FTP upload) 6% 3% 1% Number of existing TRXs in the cell 2 Percentage of GSM subscribers who are GPRS subscribers too 15% Percentage of GPRS attached subscribers during busy hour 75% Percentage of GPRS attached subscribers who have an active PDP context during busy 95% hour The mean voice call duration, the supported CSs, the QoS requirements are as stated in Section 6.1. 6.5.2. Results Firstly, we need to check whether the number of existing TRXs in the cell can support the required voice traffic load (4 Erl), respecting the restriction that voice call blocking probability 1%. Using the Erlang-B formula for 2 TRXs (14 traffic channels) and voice traffic load equal to 4 Erl, the voice call blocking probability is.6%. In the sequel, we estimated that the voice CAR (calls/h) is 24 calls/h by using Little s law (N D T). In addition, as the operator gives the required data CAR in (sessions/h/gprs sub), we need to estimate Where N is the voice traffic load (4 Erl), is the voice CAR (calls/h) and T is the mean voice call duration (1/6 h).

38 C. N. KONSTANTINOPOULOU ET AL. (a) Overall data CAR (sessions/ h) 8 7 6 5 4 3 2 1 Session dropping 1% Voice blocking 1% 5% Web, 25% FTP download, 25% FTP upload 6% Web, 3% FTP download, 1% FTP upload 5% Web, 4% FTP download, 1% FTP upload 5 1 15 2 25 3 35 4 45 Voice CAR (calls/ h) (b) Dropping probability (%) 1.8.6.4.2 Web-browsing (6%) FTP download (3%) FTP upload (1%) 5 1 15 2 25 3 35 4 45 Voice CAR (calls/ h) Fig. 19. (a) Maximum supported data CAR vs various voice CARs for different service mixes and (b) percentage of data session dropping vs various voice CARs (Case B). 444 4.23.31 12.86 18.89 52.14 52.14 58.57 58.57 6% Web-browsing 3% FTP download 1% FTP upload Voice CAR (calls/h) 32 24 16.54.87 1.19 2.64 2.64 34.29 39.29 39.29 44.29 33.57 33.57 58. 8 1.5 11.4 11.4 67.86 1.78 8.36 % Slot utilization GSM uplink GPRS uplink GSM downlink GPRS downlink Fig. 2. Percentage of slots utilization for various voice CARs (Case B).

RADIO RESOURCE MANAGEMENT SCHEME 381 25 Peak Offered mean throughput (kb/s) 2 15 1 5 Peak Mean Mean Peak Mean 5 1 15 2 25 3 35 4 45 5 Voice CAR (calls/ h) Web-browsing (6%) FTP download (3%) FTP upload (1%) Fig. 21. Offered mean throughput vs various voice CARs (Case B). Table IX. Required #TRXs in a cell for various voice traffic loads and different range of maximum supported overall data CAR. # GSM subs Voice traffic (Erl) Maximum supported data CAR (sessions per hour per sub) # required TRXs # GPRS subs (% GPRS subs) 1 CAR < 2.4 2 2.4 < CAR < 4.6 3 CAR > 4.6 >3 2 CAR < 2.1 2 2.1 < CAR < 4.15 3 CAR > 4.15 >3 3 CAR < 1.6 2 1.6 < CAR < 3.8 3 CAR > 3.8 >3 4 CAR < 1.32 2 1.32 < CAR < 3.42 3 CAR > 3.42 >3 5 CAR <.95 2.95 < CAR < 2.82 3 CAR > 2.82 >3 6 CAR <.6 2.6 < CAR < 2.52 3 CAR > 2.52 >3 7 CAR <.45 2.45 < CAR < 2.25 3 CAR > 2.25 >3 the number of GPRS subscribers. This is given by the following formula, which is graphically explained in Figure 22: (% attached subs) # Attached GPRS subs (% subs having a PDP context active) # GPRS active subs Fig. 22. Formula giving the number of active GPRS subscribers. # GPRS active subs D (# GSM subs) Ł(% GPRS subs) Ł (% GPRS attached subs) Ł (% GPRS subs having at least one active PDP context) where #GSM subs D voice CAR calls/h / calls/h/gsm sub Taking into account that voice CAR D 24 calls/h and that the number of calls per hour per GSM sub D 2 the number of GSM subscribers is 12, while the number of GPRS subscribers is 13.

382 C. N. KONSTANTINOPOULOU ET AL. 5. 4.81 Overall data CAR (sessions/sub/h) 4.5 4. 3.5 3. 2.5 2. 1.5 1..5 2.72 4.46 2.34 3.97 1.87 3.42 1.32 2.78.83 2 TRXs 3 TRXs 2.43 2.5.48.36. 1 2 3 4 5 6 7 Voice traffic load (Erl) Fig. 23. Maximum supported data CAR vs voice traffic (Erl), considering two and three TRXs in the cell (Case B). Figure 23 illustrates the maximum supported data CAR per subscriber for a range of voice traffic load (in Erlangs) and for two and three TRXs. We may observe that two TRXs are not enough for satisfying the required data CAR (1.32 sessions/h/gprs sub), while three TRXs can support up to 3.42 sessions/h/gprs sub. Consequently, the operator shall increase the number of TRXs from two to three. Some indicative results regarding the required number of TRXs in a cell for various voice traffic loads and for different range of the maximum supported overall data CAR are depicted in Table IX. 7. Conclusions In this paper, we have proposed and evaluated via a simulation platform various RRM schemes capable of differentiating the handling of service requests (in uplink and downlink) taking into account the specific QoS parameters. The evaluation is performed for a range of voice (circuit-switched) traffic loads, number of TRXs, offered data (packet-switched) services characteristics, number of dedicated PDCHs, and so on, taking into account the respective QoS requirements for both service types (circuit- and packetswitched). The results have shown the following: ž The performance of the air-interface of a classical GSM system (i.e. the voice traffic load that the system can support) is not affected by the presence of GPRS data services, when the operator has not assigned dedicated PDCHs. On the other hand, the support of GPRS services results in an increase in the number of intracell handovers and in the interference level. ž Slot utilization of a combined GSM/GPRS system increases by 2% compared to a (voice based) classical GSM system. ž The (maximum supported) data CAR depends heavily on the voice traffic load. ž The use of dedicated PDCHs improves the overall data CAR that the system can support. The penalty paid is an increase of voice call blocking. Therefore, the assignment of dedicated PDCHs shall be carefully decided by the operator. ž If more than one (data) service are offered, the less the percentage of the more demanding service the higher the overall supported data CAR. ž Prioritized RRM schemes (a) do not improve significantly the overall system performance, (b) reduce significantly the mean downlink queuing delay for the high priority service, (c) increase significantly the downlink queuing transfer rate for the high priority service and (d) offer higher throughput range for the high priority service. ž The required number of TRXs in a cell depends on the voice traffic load and on the required maximum

RADIO RESOURCE MANAGEMENT SCHEME 383 supported overall data CAR, parameters imposed by the operator. The implications of the proposed RRM schemes onto the GPRS system are 1. the implementation of the resource scheduling algorithm (i.e. proper allocation of PDCHs to active data sessions according to the applied RRM scheme) at the Packet Control Unit (PCU) of the BSC, 2. the gathering and exploitation of measurements regarding the so-far offered mean throughput of each active data session. References 1. Cai J, Goodman DJ. General packet radio service in GSM. IEEE Communications Magazine 1997; 35(1): 122 131. 2. Digital Cellular Telecommunications System (Phase 2), General Packet Radio Service (GPRS), Service Description (Stage 2), ETSI GSM 3.6 Version 7.1., Release 1998. 3. Kalden R, Meirick I, Meyer M. Wireless Internet access basedongprs. IEEE Personal Communications 2; 7(2): 8 18. 4. Digital Cellular Telecommunications System (Phase 2), General Packet Radio Service (GPRS), Overall Description of the GPRS Radio Interface (Stage 2), ETSI GSM 3.64 Version 7.., Release 1998. 5. Lin P, Lin Y. Channel allocation for GPRS. IEEE Transactions on Vehicular Technology 21; 5(2): 375 387. 6. Stuckman P, Muller F. GPRS radio network capacity and quality of service using fixed and on-demand channel allocation techniques. In Proceedings of the IEEE Vehicular Technology Conference (VTC Spring 21), Rodos, Greece, 6 9 May 21. 7. Stuckman P, Muller F. GPRS radio network capacity considering coexisting circuit switched traffic sources. In European Conference on Wireless Technologies 2, Paris, France, October 2. 8. Stuckman P, Muller F. Quality of service management in GPRS networks. In Proceedings of the IEEE International Conference on Networking (ICN 1), Colmar, France, July 21; pp. 276 287. 9. Stuckman P, Seidenberg P. Quality of service of internet applications over GPRS. In Proceedings of the European Wireless (EW 99), Munich, Germany, October 1999. 1. Konstantinopoulou CN, Koutsopoulos KA, Lyberopoulos GL, Theologou ME. QoS management in GSM/GPRS airinterface. In 8 th International Conference on Advances in Communication and Control (COMCON 8), Telecommunications/Signal Processing, Rethymno, Greece, 25 29 June 21. 11. 3GPP; Technical Specification Group Services and System Aspects; QoS Concept and Architecture, 3GPP TS 23.17, Release 1999. 12. Universal Mobile Telecommunications System (UMTS) Selection procedures for the choice of radio transmission technologies of the UMTS, ETSI UMTS 3.3 Version 3.2., Release 1998. Authors Biographies Dr Christina N. Konstantinopoulou (ckonsta@telecom.ntua.gr) was born in Athens, Greece, in 1975. She received the Diploma and the Ph.D. degree in electrical and computer engineering from the National Technical University of Athens (NTUA) in 1998 and 22, respectively. During 1998 to 22, she worked as a research engineer in the Telecommunications Laboratory of the NTUA. Since 1998, she has been involved in several research programs both national and international in the area of mobile telecommunications (ACTS STORMS, IST MOEBIUS, etc.). She has been with COSMOTE Mobile Telecommunications S.A. (one of the three mobile operators in Greece) since July 22. She is the author of several scientific papers in the area of mobile communications (traffic and mobility modeling, network planning, optimization). She is a member of the Technical Chamber of Greece. Konstantinos A. Koutsopoulos (kkoutso@telecom.ntua.gr) was born in Aigio, Greece, in 1974. He received the degree of electrical and computer engineer from the National Technical University of Athens (NTUA), Greece, in 1997. He has been working as a research associate since 1998 at the Division of Communication, Electronic and Information Engineering at NTUA where he has worked in the following research projects: ACTS STORMS, IST MOEBIUS, IST HARP. He is the author of several scientific papers in the areas of mobile communications and security. He is a member of the Technical Chamber of Greece. Dr George L. Lyberopoulos (glimperop@cosmote.gr), was born in Athens, Greece, in 1965. He received the Electrical Engineers Diploma from the Democritus University of Thrace (DUTH), in 1989 and the Dr.-Ing. degree in electrical engineering from the National Technical University of Athens (NTUA), Greece, in 1994. During 1989 to 1994, he worked as a research engineer in the Telecommunications Laboratory of the NTUA, while during 1996 to 1998 he worked for the NTUA as a senior research engineer. Since 1989, he has been involved in several research programs both national and international in the areas of ATM-based broadband networks and digital cellular mobile systems (RACE MOBILE, RACE MONET, RACE CSF, ACTS STORMS, ACTS EXODUS, ACTS ASPeCT, etc.). He has been with COSMOTE Mobile Telecommunications S.A. (one of the three mobile operators

384 C. N. KONSTANTINOPOULOU ET AL. in Greece) since August 1999 and became a 3G Technology Manager in February 21. He is the author of over 3 scientific papers in the areas of mobile communications (traffic and mobility modeling, network planning, optimization, performance analysis and protocols). He is a member of the IEEE and the Technical Chamber of Greece. Panagiotis Demestichas (pdemest @cc.ece.ntua.gr) was born in Athens, Greece, in 1967. He received the diploma and the Ph.D. degree in electrical and computer engineering from the National Technical University of Athens (NTUA). Currently, he is a senior research engineer at the Telecommunications Laboratory in NTUA. Since 21 he teaches courses on programming languages, data structures and databases at NTUA, in the department of Applied Mathematics and Physics. At the European level, he has been actively involved in a number of international research and development programs in the EURET, RACE II, BRITE/EURAM, ACTS, and IST framework. He is the manager of the IST MONASIDRE project. His research interests include the design and performance evaluation of mobile and broadband networks, software engineering, service and network management, algorithms and complexity theory and queuing theory. He has several publications in these areas in international journals and refereed conferences. He is a member of the IEEE and of the Technical Chamber of Greece. Michael E. Theologou (theolog @cs.ntua.gr) received the degree in electrical engineering from Patras University and his Ph.D. degree from the Department of Electrical Engineering and Computer Science of the National Technical University of Athens. Currently he is an associate professor at National Technical University of Athens, School of Electrical Engineering and Computer Science conducting teaching and research in the wider area of telecommunication systems. His research interests are in the fields of mobile and personal communications systems, integrated broadband communications networks, routing, flow control, quality of service and network management. He has many publications in the above areas. He is a member of IEEE and the Technical Chamber of Greece.