Master Thesis Electrical Engineering December 2012

Analysis of Radio Access Network Buffer Filling Based on Real Network Data
Logabharathi Aruchamy

School of Computing Blekinge Institute of Technology 37179 Karlskrona Sweden

This thesis is submitted to the School of Computing at Blekinge Institute of Technology in partial fulfillment of the requirements for the degree of Master of Science in Electrical Engineering. The thesis is equivalent to 20 weeks of full time studies.

Contact Information Author: Logabharathi Aruchamy E-mail: logabharathi@gmail.com External Advisor(s) Tomas Lundborg, Systems Manager, Ericsson AB, Development Unit Radio-System and Technology, Torshamnsgatan 33, 164 80 Stockholm, Sweden. University advisor: Prof. Markus Fiedler, School of Computing (COM) School of Computing Blekinge Institute of Technology 371 79 KARLSKRONA SWEDEN Internet: www.bth.se/com Phone: +46 455 385000 SWEDEN Mathias Sintorn, Senior Specialist R&D, Ericsson AB, Development Unit Radio-System and Technology, Torshamnsgatan 33, 164 80 Stockholm, Sweden.

Abstract
The 3G and 4G networks have drastically improved availability and quality in data transmission for bandwidth hungry services such as video streaming and location-based services. As 3G networks are very widely deployed, there exists increased capacity requirement and transport channel allocation to simultaneous users under a particular cell. Due to this reason, adequate resources are not available, which in turn degrades both service quality and user experienced quality. This research aims at understanding the characteristics of buffer filling during dedicated channel (DCH) transmission under fixed bit-rate assumptions on a per-user level taking different services into consideration. Furthermore, the resource utilisation in terms of empty buffer durations and user throughput achieved during dedicated channel transmission are also analysed for different data services existing in the mobile networks. The traces are collected from a real network and characteristics of the traffic are analysed prior to understanding its buffer filling in Radio Network Controller (RNC) during downlink data transmission. Furthermore, the buffer is modelled with some series of assumptions on channel bit-rates and simulations are performed taking single user scenario into consideration, for different services with the help of obtained traces as input to the buffer. This research is helpful in understanding the RNC buffer filling for different services, in turn yielding possible understanding on the existing transport channel switching scenario. With the help of analysing the buffer filling for different services and transport channel utilisation, we learn that most of the data services show low DCH utilisation of approximately around 20% and also found to have 80% of the total DCH session duration with empty buffer, causing sub-optimal radio resource utilisation.

Keywords: Traffic Characteristics, Radio Network Controller (RNC), Dedicated Channel (DCH) and Channel Switching.

i

Systems Manager for his continuous advice and encouragement throughout the course of this thesis. I am most grateful to Prof. to only some of whom it is possible to give particular mention here.both spiritually and materially. Last. ii . Senior R&D Specialist. Karlskrona and Stockholm for all the fun we have had during my stay in Sweden. Manager. but by no means least. My sincere thanks also goes to Mathias Sintorn. I would like to express the profound gratitude from my deep heart to my parents: Aruchamy and Lakshmi and my brother: Gopienathan for their love and continuous support . I would also like to thank my friends in Ronneby. Foremost. Ericsson AB.Acknowledgement It would not have been possible to complete my thesis work without the help and support of the kind people around me. I gratefully acknowledge Tomas Lundborg. At this moment of accomplishment. for his insightful comments and absolute support to the thesis. Radio Networks . I would like to express my deepest sense of Gratitude to ¨ Jessica Ostergaard. I thank him for his systematic guidance and great effort he put into training me in the scientific field. Markus Fiedler for his technical support and encouragement whenever I was in need. for giving me such an wonderful opportunity to perform this thesis work at Ericsson AB.Systems and Concepts.

. . . . . . . . . . . . .2.1 WCDMA UMTS Components [27] . . . . . . . . . . . . . . . . . . . .3 Related Work . . . . . . . . . .1. . .2 Data Trace Analysis . . . . . 2. . . . . . . . . . . iii . . . 2. . . . . . . . .3 Working Process . . . . . . 1. 2. . . . . . . . . . .2. . . .3 Radio Resource Management (RRM) 2. . . . . . . . . . . . iii vi viii ix 1 1 2 2 3 3 5 5 5 8 9 10 10 12 16 2 Background 2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2 Study Prerequisites 1.1. . . . . . . .2 Trace Analysis . . . . . . . . . . . .1 Trace Generation . . . 2. . . . . . .1. . . . . . . . . . . . . . . . . . . . . . . . . 1. . . . . . . .2 Radio Network Controller (RNC) . . .4 Contribution . . . . . . . . . . . . . . . . . . .Contents Abstract Acknowledgement i ii Contents List of Figures List of Tables List of Acronyms 1 Introduction 1.5 Reader Guidance . . . . . . . . . . . 2. . . . . . . 1. . . . . . . . . . .1 3G Network Architecture . . . . . . . . . . . . . . . . . . . . . .1 Scope . . . . . . 2.

. . .2 Dedicated Channel Utilisation [UDCH ] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4 Validity of the Results . . . . . . . . . . . . . . . . . . . . . . . . . . . .3 Transport Channels and State Transitions 5. . . 4. . . . . . . . . . . . . . . . . . .1. . . . . . . . . . . 4. . . 19 3. .5 Attained Buffer Levels . . . . . . . . . . . . . . . . . . . . . 22 22 23 23 25 26 27 29 31 34 34 35 37 38 40 40 43 44 46 48 50 52 52 53 55 57 58 60 62 63 . . .2 Inter-arrival Times [IP ] . . . . . 6. . . . 7 Conclusion and Future Work 65 7. . . . . . . . . . . . . . . . . .2. . . 5. . .3. . . . . 66 iv . . 4. . . . . . 6. . . . . .3 Clean Service Traffic Percentage [C S ] . . . . . . .4 Effects of Buffering Delays and QoS . . . . . . .2 Data Volume Transmitted per Session [SA 4. . . 6. . .4. . . . . .2 Research Questions . . . . . . . . . . . . . . . . . . 65 7. . . 20 4 Traffic Data Analysis 4. . . . . 4. . . . . . . . . . . . . . .3 Research Methodology 19 3.3. . .1 Packet Sizes [SP ] . . . . . . . . . . . . . 4. . . . . . . . . . . . . . . . . . . . . . .3 Burst Sizes [S B ] . . . . . . . . . .3 Burst Characteristics . . . . . . . . . . . . . . .1 Service Distribution . . . . . . .1 Trace-Based Simulation Buffer Model . . . . 4. . . . . . 5. S] 4. . . . . .1 Burst Inter-arrival Times [I B ] . . . . . .2 Percentage of Emptiness in Buffer per DCH Session [Pe ] 6. . 5. .4 Session Characteristics . . . .3. . 4. . . . . . . . . . . . . 4. . . . . .6 Summary . . . . . . . . . . . . . . . . . . . . . . . . . .1 Achieved User Throughput on DCH [Ta ] . . . .5 Summary . 4. . . . . . . . . . . . . . . . . . . . . . . . . .2. 19 3. . . . . . .1 Conclusion . . . . . . . . . . . . . . . . . .4. . . . . . . . . .2. . . . . . . . . . 5 RNC Buffer Modelling 5. . . . . . . . . . . . . . . . . . . . . . . . . . .1. . 6. . . . . .4.3 Discussion of the Results . .1 Duration of Sessions [DS ] . . 6.1 Idle buffer Characteristics during Dedicated Channel Transmission . . . 4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3 Research Methodology . . . .2 Burst Durations [D B ] . . . . . . . . . 6. . .1 Aim and Objectives . .2 IP Packet Characteristics . . . 5. . . . . . .2 Design Assumptions . . .2 Radio Resource Utilisation in terms of Dedicated Channel Performance . . . . . . . . . . . . . . . . . . . . . .2. . . 6 Results and Discussion 6. . .1 Empty Buffer Duration [De ] . . . . . . . . . .2 Future Work . . . . . . . . . . . . . . .

Bibliography Appendix A Sub-types of Services 68 71 72 v .

List of Figures
1.1 2.1 2.2 2.3 2.4 2.5 2.6 3.1 4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8 4.9 4.10 4.11 4.12 5.1 5.2 5.3 5.4 5.5 5.6 6.1 6.2 6.3 6.4 Working Process . . . . . . . . . . . . . . . . . . . . . . . . . Simplified 3GPP UMTS network reference model . . . . . UTRAN Components and Interfaces . . . . . . . . . . . . Overview of RNC in UTRAN connecting CN and UE . . Modes of RRC and CELL States of UE . . . . . . . . . . Differentiation criteria for services from the traffic logs [1] Essential terms and their definitions with respect to traffic 3

. . 6 . . 7 . . 8 . . 9 . . 12 [11] 15 21 23 24 26 28 29 30 31 32 33 35 36 38 42 43 45 47 49 50 54 55 56 57

Step-by-step flow of the research work . . . . . . . . . . . . . Service Distribution . . . . . . . . . . . . . . . . . . . . . . Packet sizes for different services . . . . . . . . . . . . . . . Inter-arrival times between packets for different services . . Inter-arrival time between bursts for different services . . . Mean Inter-Arrival Time between Bursts . . . . . . . . . . . Duration of Bursts for different services . . . . . . . . . . . Average Burst Durations . . . . . . . . . . . . . . . . . . . . Burst sizes for different services . . . . . . . . . . . . . . . . Mean burst sizes for different services . . . . . . . . . . . . Durations of Sessions for different services . . . . . . . . . . Data Volume per Session for different services . . . . . . . . Mean Clean Service Traffic Percentage for different services . . . . . . . . . . . .

Calculation of different parameters of the buffer model . . . . Flowchart of RNC buffer model in relation with queueing . . Switching between transport channels and UE State Transitions Average Buffering Delays for different services . . . . . . . . . Buffer filling levels for different services . . . . . . . . . . . . Average buffer levels for different services . . . . . . . . . . . Idle Durations of Buffer during DCH transmission . . . . . Average Idle Durations of Buffer during DCH transmission Empty Buffer Percentage during DCH sessions . . . . . . . Average Empty Buffer Percentage during DCH sessions . . vi . . . .

6.5 6.6 6.7 6.8

Achieved Throughput on DCH transmission . . . . . . . . . . Average Achieved Throughput on DCH transmission . . . . . Utilisation of Dedicated Channel for different services . . . . Average Utilisation of Dedicated Channel for different services

59 60 61 62

vii

List of Tables
2.1 2.2 5.1 UE states and Transport Channels with corresponding achievable bit-rates [27] . . . . . . . . . . . . . . . . . . . . . Sample tags captured from the traffic capturing tool . . . . . 10 14

QoS End-to-End Packet Delay Range for Different Services [13] 46

viii

List of Acronyms CN Core Network CS Circuit Switched DCH Dedicated Channel DPCCH Dedicated Physical Control Channel DPDCH Dedicated Physical Data Channel DRX Discontinuous Reception ETSI European Telecommunications Standard Institute FACH Forward Access Channel FIFO First In First Out FTP File Transfer Protocol GBR Guaranteed Bit Rate GSM Global System for Mobile Communication IMEI International Mobile Equipment Identity IMSI International Mobile Subscriber Identity ISDN Integrated Services Digital Network LTE Long Term Evolution MS Mobile Station MSC Mobile Station Controller NBAP Node-B Application Part PS Packet Switched PSTN Public Switched Telephone Network QoS Quality of Service QoE Quality of Experience RAB Radio Access Bearer RACH Random Access Channel ix .

RAN Radio Access Network RLC Radio Link Control RNC Radio Network Controller RNSAP Radio Network Application Subsystem Part RRC Radio Resource Control RRM Radio Resource Management SF Spreading Factor SGSN Serving General Packet Radio Service Support Node SLA Service Level Agreement UE User Equipment UMTS Universal Mobile Telecommunications System URA UTRAN Registration Area UTRAN UMTS Terrestrial Radio Access Network VLR Visitors Location Register WCDMA Wideband Code Division Multiple Access x .

empty RNC buffer periods and transport channel utilisation are very important to understand the impact of poor resource usage on the system capacity. In this research. considering different services and their traffic from real network traces. the performance of different services in the radio network scenario in terms of network parameters such as user throughput. there is a need to emphasize further on performance variations observed during the existence of traffic for different data services in RAN.1 Scope The performance study conducted in this research will evaluate how different services fill the RNC buffer in live networks with fixed channel bit-rate considerations. 1. Moreover. latency and jitter in the transmission. the buffer filling is analysed and performance variations in terms of channel utilisation is studied. caused by inadequate channel capacity. resource optimization techniques to ensure optimal use of radio resources in the network to achieve good service quality are under research. unwanted resource occupied by one user in a particular cell leads to poor experienced quality for another user in the same cell due to more delay. related to fundamental limitations of the current state machine design with respect to state transitions and down-switch timer in terms of system overhead and performance. This will be determined by understanding the characteristics of input traffic data and different output parameters of the 1 .Chapter 1 Introduction Due to ever-increasing users and subsequent network capacity requirements. In addition. With the help of some suggestions from [10].

The discussions will be made regarding the bursty behaviour of the traffic models. after supplying the epoch timestamps and corresponding packet sizes from real network traces as input. RNC buffer model and finally illustrate the results obtained from the buffer model with default channel bit-rate considerations. the working process as shown in Figure 1. the transmission protocols. According to these assumptions and the input traffic data.2 Study Prerequisites For the work conducted in this research. 1. 1. 2 .modelled buffer in terms of Cumulative Distribution Function (CDF).1 is involved. mean values and confidence intervals (CI). An initial study was conducted for four weeks during which a selected number of books and articles were read. the basics of 3G and 4G networks. • Understanding of queuing theory and its application on teletraffic engineering and packet data networks.3 Working Process The RNC buffer model makes a series of assumptions and approximations on the behaviour of the mobile networks it is designed to emulate. the model estimates the empty buffer time and DCH utilisation for the users using different services. The report will demonstrate the obtained traffic characteristics. Radio Access Network (RAN) architecture and queuing theory in general. empty buffer behaviour and dedicated channel utilisation. • Knowledge of statistical modelling and empirical data analysis with understanding related to cumulative distribution. standard deviation and confidence interval. mean. the prerequisites needed were: • Knowledge of the networking protocols used in today’s 3G and 4G mobile networks. For achieving the outcomes. which provided knowledge on mobile communication in general.

user throughput and transport channel utilisation obtained from modelled buffer to understand radio resource utilisation with respect to RNC buffer and dedicated channel for different services.5 Reader Guidance The remainder of the report is organised as follows. The background information. taking different services into consideration.4 Contribution The major contributions of this thesis work are as follows: • A methodology for evaluation of RNC buffer filling with real network traces. • Analysis of traffic data in terms of packet sizes and inter-arrival times for different services and its performance variations during dedicated channel transmissions. key concepts covering 3G network architecture. • Presentation of results in terms of empty buffer time. followed by the research questions and research methodology.Trace Files Collected through Traffic Capturing tool Service Name User 1 User 2 Traffic Data Analysis RNC Buffer Model Parsed Trace File according to service tags User N Estimation of Buffer and DCH Parameters Figure 1. data trace analysis and related work are explained in Chapter 2. 1. the traffic data analysis from the obtained real network traces for different services is covered. In Chapter 4. The RNC buffer modelling with design assumptions and validations are explained in Chapter 5 and 3 . Chapter 3 describes the aim and objectives. 1.1: Working Process Further explanations on the research methodology and process flow will be explained in detail in Chapter 3.

Finally key conclusions with potential future directions of the research are explained in Chapter 7.subsequent results are discussed in Chapter 6. 4 .

UMTS consists of four major network components as follows: • User Equipment (UE) • Radio Access Network (RAN) • Core Network (CN) • External Network (e. 5 . This section is organised as follows. Section 2.1.1.1 3G Network Architecture The Universal Mobile Telecommunication Systems (UMTS) is designed to have flexible delivery of any type of service with no requirement of network optimisation for each service [27].1 WCDMA UMTS Components [27] According to the 3GPP reference network model. mobile commerce and on-line gaming. iPad or PC dongle connected to the network through Mobile Station (MS).3 covers Radio Resource Management (RRM) present in UTRAN for resource control mechanisms. UMTS is evolving to cope with ever-increasing need of wireless data services such as multi-media messaging.g.Chapter 2 Background 2.1 explains essential components of WCDMA UMTS network briefly.2 about Radio Network Controller (RNC) and its modes of operation in terms of buffer behaviour and Section 2. PSTN/ISDN) The UE is the end-user electronic device such as Android/iPhone.1. video streaming. In addition. the data bandwidth of the UE is significantly limited by the battery capacity of UE due to MS power consumption during wireless data transmission [18].. followed by Section 2.1. location based services. 2. IP networks.

• Radio Base Station (Node B) • Radio Network Controller (RNC) • Interfaces Node B This provides air interface L1 processing such as channel coding and interleaving. Logical functionalities of RNC Load and congestion control of its own cells and execution of admission control and code control for new radio links to be established are handled 6 . the RAN is termed as UTRAN (UMTS Terrestrial RAN) and this network part is of our research interest. spreading and so on. PSTN/ISDN CircuitSwitched Domain IP Network Packet Switched Domain Core Network (CN) Radio Access Network (RAN) User Equipment (UE) WCDMA Node B RNC External Network Figure 2. Some of the radio resource management functions like inner loop power control are also carried out by Node B. In addition.In 3GPP and ETSI. As far as RAN is considered. whereas RAN handles all radio-related functionality.1: Simplified 3GPP UMTS network reference model The core network is similar to the GSM network having packet-switched or circuit-switched domains according to external networks such as PSTN/ISDN or IP networks respectively. rate adaptation. it is essential to understand the functionalities of the following components. Several components making up this network will be explained to understand how bits are transmitted over the radio interface. the CN is responsible for switching/routing calls and data connections to external networks.

which is not shown in Figure 2. Serving RNCs (SRNC) perform L2 processing of data to/from the radio interface. UTRAN Interfaces Figure 2. If the external network is a circuit-switched (CS) network consisting of Mobile Switching Center (MSC)/Visitors Location Register (VLR). RNC-RNC (Iur) This interface is primarily to enable inter-RNC soft handover. SRNC and DRNC functionalities. 2. the interface is termed Iu-CS.2. In the same way. macro diversity combining and splitting.by the Controlling RNC (CRNC). mapping of Radio Access Bearer (RAB) parameters into air interface transport channel parameters. Iu has two different instances. 7 . A single RNC normally contains all the CRNC. hand-over decisions and outer-loop power control. Another interface.2: UTRAN Components and Interfaces 1. which differ according to the type of external network. Iu Broadcast (Iu-BC). Whereas.2. Iu-PS is used in case of a packet-switched (PS) network with Serving General Packet Radio Services Support Node (SGSN). the Drift RNCs (DRNC) control cells used by the mobile. but it has some additional functionalities such as (a) Inter-RNC mobility. is used for the Broadcast domain of CN. On the other hand. UTRAN-CN (Iu) As can be seen from Figure 2.

RNC-Node B (Iub) In case of the Iub interface. 8 .2 Radio Network Controller (RNC) The RNC plays an important role in maintaining the proper flow of data according to available bit rates over the radio link. Moreover. according to operators’ requirements. which with the help of MS. 2.(b) Dedicated channel traffic handover. which is divided into common NBAP (C-NBAP) for signalling procedures across common signalling links and dedicated NBAP (D-NBAP) used in dedicated signalling links. as there is a large number of users sharing a particular RNC. The signalling protocol is Radio Network Subsystem Application Part (RNSAP) and it is possible to implement any one of the four Iur modules between two RNCs. 3. there are several protocols. External Network RNC Node B Buffer UE UMTS Core Network Processor Figure 2. transmits data over the radio interface. It owns and controls the resources in the radio network in its domain and also manages the connections to UE [27]. which make this process easier to control. (d) Global resource management.1. the Uu interface is between the RAN and UE.3: Overview of RNC in UTRAN connecting CN and UE As shown in the Figure 2. the RNC processes the packets received from CN by queuing the packets and transmitting with a defined bit-rate. 4. (c) Common channel traffic handover. traffic termination is one of the main functions and the signalling interface is Node B Application Part (NBAP). Node B-UE (Uu) Finally.3.

but UTRAN has no connection with UE at this point and does not have any information about the idle mode UEs. DCH is allocated for the user. transport channel availability and number of users within a particular cell. the connection can be created through paging (network initiated) or random access (UE initiated). During the CELL DCH state. However. Connected Mode CELL_DCH Idle Mode CELL_FACH CELL_PCH URA_PCH Figure 2. during connected mode. the UE can receive system information and broadcasting messages through RRC signaling. CELL PCH and URA PCH as shown in Figure 2. However. CELL FACH. under which the RNC can locate the UE.4: Modes of RRC and CELL States of UE Idle During idle mode. Connected On the other hand. In these states. There are two basic modes of operation: idle and connected mode. the UE can transmit or receive data through any of the following transport channels as shown in Table 2.1.3 Radio Resource Management (RRM) RRC messages in terms of handovers.1.which is dependent on the radio link allocation for the user based on the service level agreement (SLA) agreed between the service provider and the users. 2. there can be four possible states such as CELL DCH. This has higher transmission rates to provision high bandwidth services.4. CELL represents the current cell. 9 . which can be mapped to physical channels such as Dedicated Physical Data Channel (DPDCH) or Dedicated Physical Control Channel (DPCCH). URA represents the UTRAN Registration Area. the attained bit-rates vary over time due to varying network conditions. cell updates and measurements between UE and UTRAN are performed by the RRM functionalities present in the RAN. Furthermore.

2.2. i. traces are collected from an operating 3G network in a major American city. during low bit-rates. which is an 10 .e. In other words. The channel-switching functions are carried out by Radio Resource Management (RRM) function through Radio Resource Control (RRC) protocol messages. Thus data transmission is achieved through FACH having low bit rates as the channel is shared. Section 2. This same scenario is applicable in URA PCH. up to 2 Mbps Channel (DCH) CELL FACH Forward Low.e.1 Trace Generation To address the characteristics of the buffer filling for different services in the RNC of UTRAN. up to 64 kbps Access Channel (FACH) CELL PCH/URA PCH Paging Only Signalling/Paging Channel (PCH) 2. through RRM. traffic data are collected and their properties we determined and Section 2.2 covers the important terms used in the report to understand the analysis and how the traffic data analysis on per user basis is performed for different services.Conversely. Table 2. Iu-PS using a traffic capturing tool. the data is collected at the interface between CN and RAN.2 Data Trace Analysis This part is organised as follows.2. In addition. UE is forced to CELL FACH state. the UE will be assigned appropriate transport channels. and the data rate is controlled. except that the user can be known on URA level and paging is over the entire URA.1: UE states and Transport Channels with corresponding achievable bit-rates [27] UE State Transport Practical Bit-Rates Channel CELL DCH Dedicated High. 2.1 explains the way in which the traces i. the user can be contacted through PCH and the user is known on the cell level in this state. In the CELL PCH state.

In addition. So assumptions on channel bit-rates are made and buffer fillings under this scenario for different services are studied. the set of rules are freely modifiable and extensible and it also provides a way to filter or process the complete measurement data along pre-defined aspects. and that packet traffic information is collected from 3G network only. Furthermore. Furthermore. So. which resulted in 2880 trace files each having file size of around 5000 kB containing traces of the packet data traffic and it should be noted that there is no voice data collected. It should also be noted that the delay or jitter between CN and RAN (which is in the order of a few ms) is not expected to have relevant impact on the study. each packet is identified using timestamps.Ericsson tool set to measure and analyse IP traffic. during evaluation of the rules. payload of incoming packets is matched against each rule. The traces are collected for every single minute interval for 2 days continuously. In addition. source IP address and port number. it processes and classifies traffic online and instead of full traces. as defined by the classification rules. For this. TCP/UDP session. It should be noted that the link bit-rates exhibited in the radio network are not known. This tool classifies the user plane traffic using a set of rules and associated decision logic defined in an XML file. encoded International Mobile Subscriber Identity (IMSI). only stores traffic statistics at various levels of detail. 11 . International Mobile Equipment Identity (IMEI) and service tags. uplink/downlink. the information on the network policy control framework of the network was not possible to obtain because of sensitivity of the information from the mobile operator’s point of view. each user data flow may have zero or more tags attached to it. destination IP address and port number.

non-GBR services such as background services are considered to be delivered with best effort. Service Sub-Types Web-browsing-HTTP-Google Social-Networking-SSL-Facebook . which are real-time or GBR services need low packet delay and loss ratio. Services The traffic data collected has different services.. Figure 2.4. the conversational services such as voice or video calling are not considered. the conversational and streaming services.2 Trace Analysis Guaranteed Bit-Rate Non-Guaranteed Bit-Rate QoS Classes Conversational Streaming Interactive Background Services Gaming Web-browsing Email .. but to reduce the 12 . As shown in the Figure 2. 2.6.5: Differentiation criteria for services from the traffic logs [1] 1. QoS Classes The QoS class is the differentiation of services in terms of whether it has guaranteed bit-rate or not in the radio network. the Guaranteed Bit-Rate (GBR) bearer carries traffic that requires a minimum bit-rate guarantee from the network. the QoS packet delay parameter for each service will be explained in detail. From the bit-rate considerations observed in the real network scenario.2. as the research is related only to the data services in the wireless networks. Moreover... Each service has its own traffic parameters according to QoS differentiation in terms of priority. while the non-Guaranteed Bit Rate (non-GBR) bearer carries variable bit-rate traffic and is offered as best-effort service by the network [11]. packet delay and packet error loss rate. In Section 5.2. On the other hand.

all the major services are only taken out from the trace files. file-download. (a) GBR Streaming • video-playback • audio-playback • media-playback (b) Non-GBR Interactive • instant-messaging • gaming • web-browsing • social-networking • maps (c) Non-GBR Background • email • file-download • advertisement • software-update • file-sharing It should be noted that media-playback is the real-time streaming with protocols such as RTP. 3. media-playback and advertisement. gaming. representing different aspects of the traffic. since the analysis is considered with a single user at a time. instant-messaging. video-playback. 13 . Facets include • Functionality The functionality or service tells the activity type for which the flow is used and this comprises of social-networking.107. the services are differentiated according to their QoS in the following way to understand their characteristics related to this research separately. which will be an essential parameter to differentiate the packet when it is collected. email.complexities. Moreover. the extent of QoS based prioritization in the input traces is not known. Service Sub-Types Furthermore. audio-playback. whereas video and audio-playback are buffered streaming with HTTP protocol. However. The service here is termed as functionality in the traffic capturing tool. software-update. maps. RTSP. this is not relevant for the study. web-browsing. the tags that are attached to flows are grouped into facets. According to 3GPP 23.

• Protocol This tells the protocol carrying this flow such as HTTP. • Encryption Most of the secure services need encryption. the same service can be accessed through different applications such as web-browsing through Mozilla Firefox. these algorithms can be negotiated during RRC Radio Bearer (RB) establishment or reconfiguration procedures [27].2. • Encapsulation Additionally. if there exists service-provider information in the packet data. Chrome or Internet Explorer. SIP. who provide services on different functionalities such as Google providing email. SSH. RTSP and RTP. so as to ensure the data security in terms of confidentiality. In addition. XMPP. FTP. For example a flow can be characterised like sample tags given in the Table 2. So this tells which service-provider is behind the flow. which provides header compression algorithms for IP packets. The data security and protection in the radio network is achieved through Packet Data Convergence Protocol (PDCP). • Service-provider There are several service providers.2: Sample tags captured from the traffic capturing tool protocol HTTP HTTP RTSP functionality socialnetworking videoplayback mediaplayback serviceprovider Facebook Apple clientapplication MozillaFirefox iPhoneMedia-Player encryption SSL - - - - 14 . Table 2. integrity and authenticity by enabling SSL for the data transmission. web-browsing and maps services. • Client-application Similar to service providers. encapsulation is also found in some services to secure the transmission further to protect the data from intruders.

6: Essential terms and their definitions with respect to traffic [11] 4. 5. Bursts It is important to understand the term bursts. 5 s or 10 s and so on for different services depending on the assumptions on user behaviour. 200 ms for all the services to reduce complexity in comparison and analysis. Even if it is a single packet with no packets accompanying it with inter-arrival time less than 200 ms.6. which is assumed to be a set of one or more IP packets arriving with inter-arrival time less than 200 milliseconds as shown in Figure 2. then that particular packet is also considered as a burst.IP PACKETS time (s) Burst Sizes (bytes) B1 > 200 ms Burst Duration B2 B3 BURSTS time (s) S1 Session Sizes (bytes) > 300 s S2 SESSIONS time (s) Session Duration U1 U2 USERS time (s) Figure 2. It should be noted that. In addition. but it is assumed to have a fixed value in this study i. IP Packets The major information of IP packets from the traces such as epoch timestamps and IP packet sizes will be analysed for any regularities/irregularities in the traffic flow for different services. this value is assumed only after prior understanding of the packet inter-arrivals 15 . the inter-arrival time of packets within a burst can be assumed with different values other than 200 ms such as 2 s.e.

then it will be considered as the end of the current burst or start of the next burst. It is interesting to know about the characteristics of the bursts in terms of inter-arrival times. the analysis of essential parameters to understand the radio resource utilisation is also made. duration and size of bursts for different services in the radio network scenario. Sessions For a single user. rather than regular inter-arrivals of packets. as shown in Figure 2. Thus. Users If a particular service is considered. In addition.6. numerous research work state the principle of bursty behaviour in packet arrivals for most TCP services. If there is such an inactivity. 2. a session is termed as the traffic during downlink data transmission with no inactivity for about 300 seconds. In addition. After the differentiation of services with the aforementioned criteria. for the users who use this service. if the packet inter-arrival time is more than 200 ms.3 Related Work The ever-increasing need for high-bandwidth applications accessible through 3G and LTE networks widens the research opportunities in analysing existing network scenario and identifying possible quality enhancements and resource optimization procedures in the radio networks. the whole trace file is checked with the help of tags. This information is used for further investigating into the flow of packets towards the user for different services. the session is assumed to terminate and new session for the same user starts again with arrival of packets belonging to the same service considered. the research is carried out on analysing several parameters both from the traffic and buffer model implemented. 6. Finally.and related analysis on the traffic data. So. when a single service is considered. there are various work related to performance measurements with the help of emulation of a real network and analysis of several parameters involving quality improvements in the wireless networks. there may be continuous flow of packets for a certain time period or intermittent gaps between the packet flows. 7. 16 .

NewReno or SACK). with the help of simulations carried out resembling the real radio networks and there are reflections of TCP congestion control mechanisms such as slow start (exponential growth) and congestion avoidance (linear growth). Moreover. In addition. the expected waiting times. under which there are various algorithms proposed to meet the specifications of RNC and evaluations are made with the help of simulations. resource utilization in terms of channel switching is an important consideration. The up-switching threshold (bytes) and down-switching timer (seconds) for transport channel switching are considered to be static leading to consideration of all traffic with same characteristics leading to the difficulty in balancing the trade-off between network essentials in terms of network management.RNC Buffer Related Work In [19]. system overhead and performance. The performance of TCP over dedicated channels with different bit rates and different transmission time intervals (TTI) is examined to understand end-to-end packet delay. the behaviour of Non-Real-Time sessions and channel switching are evaluated with the help 17 . analysis of TCP performance with respect to RLC buffer size is analysed. queue length and power saving factor are also analysed in [14]. Furthermore. several impacts of parameter settings on performance with respect to packet loss probability and utilisation of dedicated channels are analysed in [16]. FTP file size. In addition. delay in the radio access network and throughput in the wireless link [17]. An analysis related to link throughput according to changes in the buffer size by varying TCP flavour (Tahoe. Reno. RLC buffer size and DCH data rates is conducted in [23]. Some of the accessibility issues such as termination failures and frequent user registrations are studied to understand the performance of the network according to user types and device types in [9]. RRM Related Work The findings in [10] suggest the fundamental limitation of the current state machine design with respect to transitions and timer values in UMTS network. The ETSI discrete event simulation model is proposed to study the Discontinuous Reception (DRX) mechanism exercised between the network and MS to study the inactivity timer threshold and DRX cycle [14]. A research work related to usability of instant messaging service over a 3G WCDMA network gives the technical performance analysis and usability evaluations of the radio network controller under different network set-ups [25].

of blocking rate. Even though there are numerous works in the radio resource and performance analysis. 18 . mean packet delay and cell throughput to decrease the number of blocked calls keeping other metrics at a satisfactory level [24]. taking the most widely used data services existing in wireless 3G and LTE networks into consideration. this research aims at studying in detail the RNC buffer filling with fixed channel bit-rate conditions.

Chapter 3 Research Methodology This chapter is organised as follows: Section 3.1 explains the aim and objectives. durations and size of bursts of IP packets for different services? 19 .2 Research Questions The leading questions that should be addressed in this research work are • RQ 1: What are the variations in terms of inter-arrivals. analyse radio resource utilization and radio network performance in terms of RNC buffer and DCH parameters for different services.2 gives the guiding questions to be addressed and motivation behind the research and Section 3. • implement and analyse different parameters of the RNC buffer model. taking into account different services. 3. • fit a parameterized model of IP packet inter-arrival times and IP packet sizes to the existing packet traces. • with the resulting level of buffer filling.3 describes the research methodology handled in order to fulfil the goals of the thesis work. operating networks impacts the buffer filling in the radio network nodes. The objectives to achieve this goal are to • analyse packet traces from real networks. 3. Section 3.1 Aim and Objectives The goal of this thesis work is to investigate how traffic from real. • evaluate buffer filling for users using different services in the radio network. in terms of resulting parameters of the model.

so as to understand the regularities or irregularities of bursts in traffic for different services. this is essential to gather information about the performance of different services in the radio network in terms of buffer utilisation.2. the packet sizes and inter-arrival times are examined for different services and bursts of the data traffic is also analysed. the analysis will reflect the radio resource utilisation with respect to dedicated channel for different services. 4. 5. The following describes the steps carried out to obtain the necessary outcomes of this research as shown in Figure 3. From the traces.1. 20 . The second question is framed to address how different services incur empty durations in the RNC buffer due to intermediate inactivity during dedicated channel transmission according to the channel bit-rate conditions assumed. 3. 2. The data traffic is analysed to get the knowledge of obtainable parameters from the trace files.• RQ 2: How long does the RNC buffer show empty buffer levels during DCH transmission for different services? • RQ 3: How do different services perform on dedicated channel data transmission in terms of user throughput and channel utilisation? The first question is mainly to find out the distribution of the traffic models supplied to the buffer as input to understand the characteristics of the data traffic obtained.3 Research Methodology The research work comes under the category of empirical data analysis and it deals with traffic data analysis of obtained traces with respect to different services and further investigation related to the radio network buffer filling for different services. In addition. The RNC buffer is modelled with a series of assumptions and approximations to understand how buffer performance is affected by different services in a real RNC. From the third question. 1. The obtained traffic separated as sessions for different services are supplied as input to the buffer to evaluate the buffer filling. 3. The traces are classified according to different services so as to be analysed further in terms of important parameters of the traffic and this is mentioned in Section 2.

7.Dedicated Channel with high bit rates up to 2 Mbps with exception of background services having fixed 512 kbps **** . The radio resource utilisation is studied in terms of obtained user throughput and channel utilisation on the DCH link for different services from the buffer model.Forward Access Channel with low bit rates because of the shared nature of the channel Figure 3. delay) Channel utilisation) * . Buffering packet User throughput. (Empty buffer time. The real network traces obtained for our research work contain additional details in terms of traffic parameters to understand the buffer filling at radio network part for different data services. Traces obtained from Traffic Capturing Tool Service / Functionality RNC Buffer Modelling & Analysis Transport Channels ****FACH ***DCH Traffic Data Analysis Encoded user IMSI + (IP packet sizes and epoch timestamps) Session-wise traffic data file RNC Buffer (Leaky-bucket) *Burst Characteristics: (Inter-arrival times. During DCH transmission. 8.Bursts are assumed to be one or more IP packets with inter-arrival time less than 200 ms ** . the empty buffer times and percentage of empty time durations are obtained for different services and this helps to understand how different data services perform in the radio network scenario. after which session ends *** . the buffer levels achieved and packet delays occurred due to buffering are estimated for different services. durations and sizes) **Session Characteristics: (Duration and Data Volume) Buffer Parameters: DCH Parameters: (Buffer levels.6.1: Step-by-step flow of the research work In [10]. real network traces are used for evaluating the improvement of energy levels in the UE by leveraging an existing feature called fast dormancy supported by 3GPP specifications. To validate the buffer model.Sessions are traffic flows towards a user with no inactivity greater than 300 s. 21 .

the session ends after 300 s of inactivity.Chapter 4 Traffic Data Analysis The obtained packet traffic data is analysed by classifying the services under their corresponding QoS classes as mentioned before. almost all the streaming. As mentioned before. so as to understand the inter-arrival times and packet sizes for different services. Total Data Volume [%] The data volume of a session is calculated by summing up the IP packet sizes during that particular session. The sessions considered for different services vary in the amount of data transmission and time duration. file-download and web-browsing services show larger data volumes than other services. The percentage of total data volume is calculated so as to ensure clarity in the picture as shown in Figure 4. total number of sessions and total duration of the session are estimated for each service.1 that. It is evident from Figure 4.1. So. the total data volume. 4. Some of the major parameters needed to understand the traffic characteristics of different services are also explained in this section.1 Service Distribution Primarily it is essential to know the amount of each service traffic present in the collected traffic data. Total Number of Sessions [%] The total number of sessions for a service in % is the ratio between the number of sessions for that particular service and the total number of 22 . The percentage total data volume for each service is estimated using the ratio between the total data volume calculated from all the sessions of a particular service and total data volume for all the services present in the trace file.

It is calculated from the ratio between the duration of all the sessions of a particular service and total session duration of all the services. maps and file-download services have shorter session durations and lower number of sessions. instant-messaging and email show a comparatively large number of sessions.2 4. This is similar to that of the total number of sessions [%]. the total session duration [%] for different services is also important.1. As can be seen from the Figure 4.2. social-networking. social-networking.1 IP Packet Characteristics Packet Sizes [SP ] The characteristics of the traffic flow can be understood from the packet sizes and inter-arrival times for different services.*-Android-Market-Android-Market email audio-playback advertisement 80 60 % of total 40 20 0 Tota l Data Tota Volu me[% ] l Num ber o f Tota Sess l Ses sion ion[% ] Dura tion[% ] Details of Service Sessions Figure 4. 100 YouTube web-browsing video-playback software-update social-networking media-playback maps instant-messaging gaming file-sharing file-download-.*-iTunes-iTunes file-download-. It is evident from the Figure 4. instant-messaging. email and advertisement show longer durations of sessions than other services. In short. but transmit larger data volume than social-networking. 4. web-browsing.sessions for all the services. web-browsing. email and advertisement services. 23 . instant-messaging. web-browsing. all the streaming.1: Service Distribution Total Session Duration [%] In addition to the above analysis related to total data volume [%] and total number of sessions [%].1 that.

2 gives an overview of packet sizes in the form of CDF plot. 60% packet sizes are found to be 52 bytes. whereas web-browsing and maps show packet sizes of 1448 bytes 24 .2: Packet sizes for different services In case of non-GBR interactive services such as gaming. instant-messaging and social-networking. other than media-playback which has varying packet sizes between 52 and 1448 bytes. from which almost all GBR streaming services are found to have 80% of packet sizes on 1448 bytes.Figure 4. Figure 4.

25 . It is interesting to look at the file-sharing services.3 that roughly around 70% of inter-arrival times are less than 200 ms for almost all the services and this implies that there are more packets as bursts. services such as instant-messaging and social-networking send small chunks of data most of the time. when the user is connected to the network and accessing these services.for roughly 70% of the values. It is evident from the Figure 4. which show small packet sizes probably due to signalling in the network.3. On the other hand. according to our assumptions. Similar behaviour to that of streaming services is observed in case of file-download and software-update services. from the traffic data obtained. So there exists notable diversity within this group and this may be due to the services such as web-browsing and maps sending large chunks of data towards the user.2 Inter-arrival Times [IP ] As can be seen from Figure 4. whereas advertisement and file-sharing show packet sizes of 52 bytes in 50% of the values.2. similarities among services in terms of inter-arrival times are observed. 4.

in order to get a clear picture on the data volume sent as packet bursts.3 Burst Characteristics It is important to evaluate the characteristics of bursts of packets for different services. This might vary with respect to different services.Figure 4. 26 . This analysis has been carried out based on the assumption of burst inter-arrival times greater than 200 ms.3: Inter-arrival times between packets for different services 4. before analysing the buffer filling at the radio network.

Epoch time stamp of first packet or start of current burst tB e.n . there is a maximum value of 300 seconds. the inter-arrival times between bursts have a minimum value of 200 ms. 27 .4 that GBR-streaming services. below which the packets are considered as bursts. 4.3.Inter-arrival time of burst n in seconds tB s. durations and sizes taking different services into consideration. is addressed in this section. interactive services except instant-messaging and background services except advertisement and file-sharing show most of the inter-arrival times between bursts less than 1 second.n−1 (4.n − te.1) B In where. It can be observed from Figure 4.1 Burst Inter-arrival Times [I B ] The formula used for calculating this value is as follows. B B In = tB s. there is only 40% of the inter-arrival times are less than 1 second. . above which the session is considered to be terminated and new session will commence with arrival of packets of the service considered. However in case of file-sharing. instant-messaging and advertisement have roughly 60% of the burst inter-arrival times less than 1 second. In addition. Moreover.Thus the first research question on analysis related to bursts.n−1 .Epoch time stamp of last packet or end of previous burst It should be noted that. This deals with the study of bursty behaviour of packet arrivals in terms of burst inter-arrival times.

Figure 4.4: Inter-arrival time between bursts for different services 28 .

Mean Inter-Arrival Time between Bursts advertisement audio-playback email file-download-.*-Android-Market-Android-Market file-download-.*-iTunes-iTunes file-sharing gaming
Services

instant-messaging maps media-playback social-networking software-update video-playback web-browsing YouTube 0 2 4 6 8 10 12 14

Inter-Arrival of Bursts [seconds]

Figure 4.5: Mean Inter-Arrival Time between Bursts In addition, the mean value of the burst inter-arrivals are calculated with the confidence intervals as shown in the Figure 4.5, which has most of the services showing the inter-arrival time roughly around 1 second, which is relatively high in case of instant-messaging and file-sharing having values more than 5 seconds.

4.3.2

Burst Durations [D B ]

It is important to understand the duration of how long the burst exists for different services, which may be regular or irregular according to the type of service and also the conditions in the network during data collection. This is calculated from the formula,
B B Dn = tB e,n − ts,n

(4.2)

where, B - Duration of burst n in seconds Dn tB e,n - Epoch time stamp of last packet or end of current burst tB s,n - Epoch time stamp of first packet or start of the current burst

From the Figure 4.6, media-playback is found to have short duration of bursts i.e. less than 1 ms in roughly around 50% of the values. This might be because of real-time streaming causing short duration of bursts or 29

individual packet arrivals in case of media-playback. As shown in Figure 4.6, most of the other services show a duration of bursts in the range of 200 ms and 1 second, which is observed in more than 70% of the bursts for almost all the services except advertisement and software-update, which show around 40% of the burst durations more than 1 second.

Figure 4.6: Duration of Bursts for different services In addition, from the Figure 4.7, the mean and confidence interval 30

implies that most of the services have duration of bursts less than 5 seconds, but advertisement and software-update show comparatively long burst durations.
Mean Duration of Bursts advertisement audio-playback email file-download-.*-Android-Market-Android-Market file-download-.*-iTunes-iTunes file-sharing gaming
Services

instant-messaging maps media-playback social-networking software-update video-playback web-browsing YouTube 0 50 100 150 200 250 300

Duration of Bursts [seconds]

Figure 4.7: Average Burst Durations

4.3.3

Burst Sizes [S B ]

The constraint that groups the packets m,m +1...m+N in a single burst, is that every packet fulfils the following condition,
P tP m+1 − tm < 200 ms

(4.3)

where, tP m+1 - Epoch timestamp of the next packet, in seconds tP m - Epoch timestamp of the current packet, in seconds Even though most of the services show almost similar behaviour in terms of burst inter-arrivals and durations, the size of bursts are found to vary according to the type of service. This value is calculated as follows:
B P P P Sn = Sm + Sm +1 + · · · + Sm+N

(4.4)

where, B - Data Volume or Size of the burst n, in bytes Sn
P ...S P Sm m+N - Size of each packet from m to m+N (m+N is the total

31

in bytes Figure 4. GBR streaming services such as audio and media playback show around 80% of the burst sizes in the range of 1448 bytes and 10 kB.8: Burst sizes for different services As shown in Figure 4. The reason behind this characteristics emphasizes the larger contents sent as bursts in case of 32 .number of packets in the burst). whereas video-playback is found to have around 80% of the burst sizes between 1 kB and 1 MB.8.

which is contradictory to file-download iTunes showing 40% and file-download-Android showing roughly around 80% of the burst sizes in the range of 1 kB and 10 kB. 33 . web-browsing. Conversely. However. file-sharing service is observed to have lower burst sizes most of the time showing less than 100 bytes of burst sizes in 70% of the obtained values. In contrast. non-GBR interactive services such as instant-messaging and gaming have most of the bursts in the range of 52 and 1448 bytes.9: Mean burst sizes for different services From the Figure 4.9 above. email.video-playback than the audio and media-playbacks. which is because of single packets as bursts most of the time. social-networking. Mean Burst Sizes advertisement audio-playback email file-download-. most of the services have burst sizes less than 50 kB. advertisement and software-update show burst sizes between 100 bytes and 100 kB in roughly 70% of the values. but GBR streaming services except media-playback have bursts of sizes between 50 and 100 kB and software-update service has larger bursts in the range of 100 to 200 kB. Eventhough the presumption was like all the file-download services have similar characteristics in downloading.*-iTunes-iTunes file-sharing gaming Services instant-messaging maps media-playback social-networking software-update video-playback web-browsing YouTube 0 50 100 150 200 250 Burst Sizes [KB] Figure 4. the obtained results from burst sizes for different services show varying characteristics.*-Android-Market-Android-Market file-download-. maps.

around 70% of the streaming and file-sharing services show session durations between 1 and 100 minutes. It is interesting to note that.10 showing the duration of sessions in minutes.4. it is evident that almost all the services have most of their session durations approximately less than 100 minutes. From the following Figure 4.1 Session Characteristics Duration of Sessions [DS ] The following analysis is related to understanding the length of sessions for different services. 34 .4.4 4. which is higher than interactive services and background services.

11.2 S Data Volume Transmitted per Session [SA ] For each session the data volume transmitted in kB is calculated by summing up the IP packet sizes during that session for different services.Figure 4.10: Durations of Sessions for different services 4. the GBR streaming services are found to have 70% of the sessions with data volumes in the range of 10 kB and 100 MB. From the following Figure 4. 35 .4.

Figure 4. followed by gaming and social-networking with 80% session data volume in the range of 1 kB and 100 kB. In case of background services roughly around 80% of the sessions have session data volumes below 100 kB. instant messaging shows around 80% of the sessions with session data volume less than 10 kB. other than file-download-Android 36 .11: Data Volume per Session for different services Conversely in case of non-GBR interactive services. However. maps and web-browsing services show around 60% of the sessions with data volumes between 10 kB and 10 MB.

4. which is observed to transmit highest volumes of data per session from the obtained traces. CS = S SC × 100% S SA (4. the percentage of packets belonging to a particular service during a session is calculated to understand this value from the obtained traffic data.showing 70% of the sessions having data volume ranging from 1 MB to 10 MB.3 Clean Service Traffic Percentage [C S ] It should be noted that the traffic data considered for different services. the term session has the same definition as mentioned in Section 2. due to simultaneous access of different services at the user side. cleaner the service is. From the analysis related to session data volumes. the interest on clean traffic percentage is mainly due to improve the understanding on how traffic data for different services show clean service packets in the bursts. representing the services under consideration.Amount of data transmitted as clean service packets per session SC S . This is calculated by finding the ratio between amount of data S and total transmitted as clean service packets only during a session SC S data volume transmitted during the session SA . 4.2 So. Moreover.2. So. C S . The mean clean service traffic percentage is calculated for each service and the 95% 37 . This also helps us to ensure how reliable different traffic data from the traces.4. In other words. the higher the value of C S . which may be because of the bulk data sent towards the user during each session in terms of streaming services.2.Clean Service Traffic Percentage per session S . Here.Total data volume transmitted or summation of all packet sizes per SA session as explained in Section 4.5) where. there are possibilities that the bursts of packets of a particular service may have a few packets belonging to other services. it is clear that GBR-streaming services achieve larger data volumes than other services. may possess other services also in the bursts of packets.

other services show lower inter-arrivals than 200 ms most of the time leading to conclusion that large number of packets are transmitted as bursts of packets with our assumption of 200 ms. bursts and sessions. except file-sharing. Percentage of Clean Bursts per User Session advertisement audio-playback email file-download-.*-Android-Market-Android-Market file-download-. • When it comes to bursty behaviour of the TCP traffic. Some of the points to remember from this analysis are as follows: • Packet sizes obtained from the traces are mostly 52 and 1448 bytes. However.12 below. which has approximately 60% of its inter-arrival times greater than 200 ms. inter-arrival times. for which different services share these sizes in different proportions. the traffic data analysis is essential to understand the behaviour of the flow of traffic for different services in terms of packet sizes. most of the services show bursty arrival of packets in 90% of the traces. Furthermore. showing most of the services achieve C S greater than 75%. software-update and gaming show higher proportion of mixture of other services also in the bursts than other services.12: Mean Clean Service Traffic Percentage for different services 4.*-iTunes-iTunes file-sharing gaming Services instant-messaging maps media-playback social-networking software-update video-playback web-browsing YouTube 0 20 40 60 80 100 Clean Bursts [%] Figure 4. • In case of inter-arrival times.5 Summary To put it in a nutshell. most of the sessions considered for different services show more than 75% clean service packets and helpful for analysis on each service separately. depending on their corresponding data volume transmitted. services such as advertisement. 38 .confidence interval is plotted in the Figure 4.

• The total data volume transmitted to the users during their sessions is dependent on the type of traffic. but still there are some sessions which last for longer durations than an hour. Thus. because it is helpful in understanding the traffic data filling buffer. the traffic profiles for different services and their properties in terms of several parameters serve the purpose of deducing their traffic behaviour in the radio networks in general. there exist relatively high data volumes in case of streaming and file-download services.• Most of the user sessions considered are found to have their durations below 1 hour. since different services have varying size in the amount of data sent. 39 . Moreover. the analysis related to burst characteristics is of major importance. given the inter-arrival times and sizes of bursts. For the subsequent study on buffer filling.

Section 5. as mentioned before sessions are active periods containing downlink data traffic for users under each service.2 explains the major design assumptions and approximations made for the buffer model.4 is intended to provide the validation of the model by explaining the possible packet buffering delays and how it conforms with QoS packet delay budget for different services. From this traffic data.1 gives an overview on how the buffer is modelled explaining how the input from the obtained traces is handled. Section 5. In addition. The UE is considered to be Idle during every session initiation and the major parameters affecting buffer filling are the channel bit-rates and switching considerations. Furthermore. 5.5 describes the achieved buffer levels and its relationship with the burst sizes for different services. and an example scenario to understand how the output parameters are estimated from the buffer model. each packet data in terms of epoch timestamp and packet size for different services is given as input to the buffer.Chapter 5 RNC Buffer Modelling This chapter is organised as follows: Section 5. Section 5. Finally.3 describes the transitions in the play-out rates of the RNC buffer due to link bit-rate considerations when there is a switching between channels.1 Trace-Based Simulation Buffer Model The real network data obtained has been differentiated into session-wise traffic data files for each service. Section 5. However. each packet will be serviced according to the bit-rate in the channel existing at that particular moment of packet arrival. according to the 3GPP Release 7 as mentioned in [27] the conditions for channel switching and bit-rates for both dedicated channel (DCH) and forward access channel (FACH) in the pseudo code are 40 . which are set as default for our study.

as follows: At the point of a packet arrival. else TransmissionRate = 2 Mbps. If 512 kbps < TransmissionRate < 1 Mbps: TransmissionRate = 1 Mbps. It takes the value of 1 second for streaming and 400 milliseconds for interactive according to [13] on QoS requirements. CHANNEL DOWNSWITCHING If UE is not Idle. CHANNEL UPSWITCHING If UE is not Idle. SERVICE-DEPENDENT CHANNEL UPSWITCHING ON QoS If UE is not Idle and Service is Streaming/Interactive and TransmissionTime > MaxAccDelay : TransmissionRate = BufferLevel/MaxAccDelay where. Channel == DCH and Emptytime > 3 seconds: Channel = FACH: TransmissionRate = 16 kbps. 41 . Channel == FACH and BufferLevel > 512 bytes: Channel = DCH and TransmissionRate = 512 kbps. MaxAccDelay is the maximum acceptable packet delay caused in the network and acceptable for the user and it differs for different services. If UE is not Idle and Channel == DCH: TransmissionRate = 512 kbps. INITIAL CONDITIONS If UE is Idle: Channel = DCH and TransmissionRate = 512 kbps. If UE is not Idle and Channel == FACH: TransmissionRate = 16 kbps.

it will fill the buffer and gradually the buffer level decreases according to the rate of transmission through the channel allocated during that particular state of UE. since the resource allocated during dedicated channel transmission is relatively high and needs optimisation also.1. These buffer levels are important to understand. Moreover. since many users share the channel simultaneously. during which there are no data in the buffer and it is measured during DCH transmission only.A1 A2 A3 A4 IP Packet Arrivals & Departures 6 D4 Buffer Filling 6 7 7 0 D1 1 2 D3 3 4 5 D2 Buffer Levels 0 1 2 3 4 5 Empty Time User Throughput DCH FACH 0 1 2 3 4 Empty Time Packet Buffering Delay Channel Switching 5 6 7 Figure 5. On the other hand.1: Calculation of different parameters of the buffer model As shown in Figure 5. 42 . whereas other services may show low levels due to smaller burst sizes. FACH transmission is shared and it has low bit-rates and less resource allocation. the user throughput is also calculated for different services. This packet buffering delay is an important factor because. In addition. some of the services may cause the buffer levels to increment quickly due to large burst sizes. the buffer should not take longer time to process the packets. since the end-to-end packet delays should be within the acceptable limit for delay-sensitive services. Furthermore. In addition. This has been used for validation of the model and the results will be explained in Section 5. if there is an arrival of packet. the packet buffering delay is measured using the value obtained as the difference between the time of arrival of packet in buffer and time of the packet leaving the buffer totally. there may be empty times.4. given the transmission rates and switching conditions according to our model. how different services remain in the RNC buffer.

This is estimated from the ratio between number of bits transmitted and total time period on DCH. 5. the DCH Utilization has been calculated for every DCH session according to the channel bit-rate assumptions. a leaky-bucket buffer model having a random rate of arrival of packets and deterministic rate of departure of packets is chosen.2.2.2. to understand the achieved throughput in the DCH transmissions.2 Design Assumptions For ease of analysis and simplicity.1. However. when the buffer model is supplied with the real network traces.2: Flowchart of RNC buffer model in relation with queueing As shown in Figure 5. the play-out rates set by the buffer depend on UE states as mentioned in Section 5. Additionally. Packet Arrival Empty RNC Buffer Yes No Move Packet to RNC buffer No Previous Packets Serviced Wait until previous packets are serviced Yes Send Packet Figure 5. which are presented in Section 6. Further explanation on estimation of these parameters in detail with the help of formulae are given in the following sections with the results obtained. the RNC buffer model can be understood as a First-In-First-Out (FIFO) queuing model with the play-out bit-rate 43 .during each DCH session for different services.

1.depending on the channel bit-rate at the moment of packet arrival.Packet Size.Epoch time stamp of the complete packet departure from the buffer.2) 5.Transmission bit-rate depending on the transport channel allocated. the transport channels such as DCH and FACH are allocated by the RNC. tp s = where. tp d . S p . in seconds The time taken to service a packet is calculated from the following formula. in bits B CH . in seconds p−1 td . in seconds tp s . Sp B CH (5. The time at which the packet is fully serviced is calculated as follows: p−1 tp + tp s d = td (5.3. to attain data transmission according to the data in buffer.3.Epoch time stamp when the previous packet is serviced (if the packet arrives at empty buffer. this time is the packet arrival time). As can be seen from the Figure 5.Time taken to service the packet fully. in bps.3 Transport Channels and State Transitions As mentioned in the Section 2.1) where. there are two modes of operations according to the activity of data transmission through different transport channels and the channel switching is dependent on parameters such as • Up-switch Threshold • Down-switch Timer • Inactivity Timer 44 .

3: Switching between transport channels and UE State Transitions If there is no data transmission between the UE and CN for a while i. it can reach higher values upto 2 Mbps according to the packet buffering delay in case of streaming and interactive services. It should also be noted that. the UE power consumption values are found to be around 30 mW in case of power saving modes such as CELL PCH and URA PCH. which is an assumption on the initial bit-rate for our study. the UE is Idle and there is a packet arrival. the transport channel primarily allocated will be DCH. as FACH is a shared channel among several users. Furthermore. since the user is allocated with a dedicated channel at 512 kbps.e. In other words. and it will be allocated only if the user can be served with low data rates. Yet it can be shifted up to DCH when the buffer level is increased to higher values than 512 bytes of data. the power and cost incurred will also be increased accordingly. the bit-rate cannot be guaranteed and it is assumed to have 16 kbps bit-rate. if the data rates are increased. In 3G. which makes the UE to enter into CELL DCH state. From the understanding gained from the 3GPP standards Release 9 [27].Mode:Active CELL_DCH Packet Buffering Delay > Maximum Acceptable Delay ( Up-switch Streaming & Interactive only) 2 Mbps 1 Mbps 512 Kbps Up switch threshold: buffer level > 512 bytes Down switch timer: no traffic for 3 seconds CELL_FACH 16 Kbps Inactivity timer: No traffic for 300 seconds (Session Termination) Up-switch trigger buffer level > 1 byte Mode:Idle Figure 5. 400 mW in case of CELL FACH and 800 mW in case of CELL DCH state. However. the UE is capable of sending large chunks of data with good QoS and bit-rates. CELL FACH state consumes only 50% of power than the CELL DCH state [18]. During this state. the practical bit-rate assumptions through DCH and FACH has been 45 .

filedownload. if there are no packet arrivals for 300 seconds. social-networking. 46 .1 gives the acceptable overall end-to-end packet delay range for different services according to ITU-T and 3GPP QoS Standards.made. Media (Buffered Streaming) Interactive Gaming. this is evaluated in order to demonstrate the validity of the model. The following Table 5. The down-switching from DCH to FACH is considered to happen after 3 seconds. 5. Moreover the down-switching to FACH from DCH is caused due to expiry of the down-switching timer. Moreover. advertisement) Non-GBR Interactive 400 ms Non-GBR Background Best Effort The buffer model includes the aforementioned QoS requirements. the delays due to buffering for delay-sensitive services should be analysed in order to conform the buffer model with acceptable QoS packet delays for different services. maps) TCP-based (email. TCP based (instant-messaging. softwareupdate. by incrementing the transmission rates up to 2 Mbps if packet buffering delay is more than the QoS delay and this avoids additional delay. The UE is considered to be Idle mode. since longer duration than this value on DCH could lead to radio resource waste and shorter may lead to excessive up-switch after premature down-switch i. p2p. which is considered as the termination of the session. which has 3 seconds as default timer value in this study. Table 5.e. by comparing the packet delays due to RAN buffering and RAN transmission with the end-to-end QoS delay for different services.file sharing.1: QoS End-to-End Packet Delay Range for Different Services [13] Resource Type GBR Traffic Class Streaming Acceptable Delay 1s Services Non-Conversational Video.4 Effects of Buffering Delays and QoS Even though there are default link bit-rates. webbrowsing. Audio. frequent switching.

the average packet delay due to buffering for the modelled RNC buffer is calculated for different services.Packet buffering delay.4. which can go higher upto 2 Mbps if there is a need to send the packets within the acceptable delays and default 16 Kbps FACH. in seconds tp a . In addition.3) where. Average Packet Delay due to Buffering advertisement audio-playback email file-download-.*-iTunes-iTunes file-sharing gaming Services instant-messaging maps media-playback social-networking software-update video-playback web-browsing YouTube 0 5 10 15 20 25 30 35 Packet Delay on Buffering [milliseconds] Figure 5. leading to conformance of the valid buffer model having default 512 Kbps DCH. B p . p B p = (tp d − ta ) × 1000 (5.Epoch time stamp when the packet is fully serviced (both waiting and service). in milliseconds tp d .The packet delay due to buffering is calculated using the following formula.1.*-Android-Market-Android-Market file-download-. the services such as file-download and software-update 47 . As shown in the Figure 5. all the services are found to have low delays due to buffering at RNC around 20 ms. which cannot be varied.Epoch time stamp when the packet arrives at the buffer.4 that. in seconds With the help of the above formula.4: Average Buffering Delays for different services It is also evident from Figure 5. almost all the services show packet delays due to buffering within the acceptable QoS packet delay budget as shown in Table 5.

5 Attained Buffer Levels In addition to the above analysis. Furthermore.showing larger burst sizes in Figure 4. due to varying play-out rates. are found to have longer delays. Furthermore. the buffer levels can be higher for services which need high bandwidth. it is important to analyse the buffer levels achieved. 5. these variations have an impact on buffer levels for different services due to this type of link allocation procedure and the following Figure 5. 48 .5 shows the variation in buffer levels during downlink data transmission for different services. and also due to larger bursts and relatively low play-out rates. which is also considered to ensure the validity of the buffer model.8.

Figure 5. . it is evident that around 80% of the buffer levels for GBR streaming services except media-playback is between 1 kB and 1 MB. Conversely. Similarly in case of non-GBR interactive services such as web-browsing and maps around 90% of the buffer levels are in the same range as that of streaming services.5: Buffer filling levels for different services From the Figure 5.5. non-GBR interactive 49 services such as gaming.

email and file-sharing showing around 70% of the buffer levels less than 1448 B. non-GBR background services such as file-download and software-update show around 80% of the buffer levels between 1 MB and 10 MB. giving the mean value and its confidence intervals.5 than other services. As can be seen from Figure 4.*-Android-Market-Android-Market file-download-.6 Summary As can be understood from the above modelling and analysis of the RNC buffer: 50 .6 shows the average buffer levels in Mega-Bytes for different services.8. Similar characteristics are found in case of non-GBR background services such as advertisement. the services such as file-download and software-update showing larger burst sizes.instant-messaging and social-networking are observed to achieve buffer levels of around 52 B in around 50% of the values. This is considered as validation of the results obtained from the model.6: Average buffer levels for different services 5. which implies that mostly the packets arrive at an empty buffer as single 52 B packet.*-iTunes-iTunes file-sharing gaming Services instant-messaging maps media-playback social-networking software-update video-playback web-browsing YouTube 0 2 4 6 8 10 12 14 Average Buffer Level [MB] Figure 5. the following Figure 5. are found to have higher buffer levels as shown in Figure 5. Furthermore. Mean Buffer Level Achieved advertisement audio-playback email file-download-. On the other hand.

• The buffer levels achieved by different services are comparatively high in case of non-GBR background services such as email.8 are found to have higher buffer levels as shown in Figure 5. it is evident that all the services incur packet delays at RAN lower than the acceptable limit according to end-to-end QoS packet delay budget set for 3G and LTE network for different services [13]. file-download and software-update in increasing order. when transmission is through DCH. • The buffer levels are estimated to understand the validity of the results with the help of input data. the rates can be incremented upto 2 Mbps.5 than other services and this is considered to be a validation check for the buffer model and the results obtained. • From the observations made after supplying the obtained traffic data as input to the modelled buffer. indicating the validity of the buffer model for the study involved. However. This is performed by tracking the buffer levels and transmission time taken to service the packets arrived at the buffer for different services.• The RNC buffer modelled has no maximum limit and considered to be of a leaky-bucket model having random rate of packet arrivals and deterministic play-out rates with default setting of 512 Kbps through DCH and 16 Kbps through FACH. in case of delay-sensitive services. 51 . It is observed that services having large bursts as shown in Figure 4.

4 summarises the validity of the results obtained.3 discusses the overall results for different services with the help of obtained parameters from the buffer model and Section 6. It should be noted that DCH session signifies the duration of the users’ presence in the dedicated channel with infinite active time and finite time to stay on DCH during inactivity for about 3 seconds. This chapter is organised as follows: Section 6. the assumptions and approximations made in modelling the RNC buffer are covered. The analysis is performed step by step for each service by focussing on certain important parameters of the buffer model with channel bit-rate assumptions. there occurs intermittent time intervals during which there are no data transmission to the user from the radio network. after which 52 . which address the research questions framed in the Chapter 3. 6.1 explains the obtained empty buffer durations during DCH transmission for different services. which takes place only when the down-switch timer expires. Section 6.1 Idle buffer Characteristics during Dedicated Channel Transmission Due to irregular arrivals of packets for different services. This in turn causes down-switching from DCH to FACH. Section 6. Furthermore on the analysis made.2 comparatively illustrates the performance of different services in terms of user throughput and dedicated channel utilisation for different services.Chapter 6 Results and Discussion In Chapter 4. the characteristics of traffic data supplied as input to the leaky-bucket RNC buffer model and in Chapter 5. there are some important results.

by analysing the emptiness of buffer during DCH transmission for different services and the percentage of empty buffer duration observed from the total DCH session duration. This value is calculated using. which is found to be valid in most of the networks. during which no data is present in the buffer during DCH transmission.1.1) 53 .1. The second research question is addressed in this section. De = tds − tbe where. for some data services.Epoch time when down-switching occurs from DCH to FACH during each DCH session tbe . during DCH transmission.down-switching happens. the variations in the empty buffer times for different services are analysed. which can be maximum up to 3 seconds as can be seen in some cases.Epoch time when buffer becomes empty during DCH session As shown in the following Figure 6.Empty Buffer Duration in seconds tds . 6. most of the services have idle buffer behaviour for roughly 200 milliseconds duration. after which there is a channel down switching to shared channel FACH. De . This value is an assumption. Due to varying characteristics of data services in 3G networks. but the radio resources allocated for the user are still occupied.1 Empty Buffer Duration [De ] In this section. (6. there may be empty times in buffer. making the resources occupied by the user but no data transmission during those periods.

1: Idle Durations of Buffer during DCH transmission Furthermore. almost all the services have short empty times less than 500 ms in most of the cases.Figure 6. software-update and advertisement reaching roughly around 700 54 .2 shows the average value on empty buffer times. but if there are a lot of short empty times. there are possibilities that the channel may not be used to its full potential. a bit higher in case of gaming. This might be helpful in avoiding frequent down-switching. from which it is clear that almost all the services have a mean empty buffer duration of about 500 milliseconds. The following Figure 6.

in the DCH.2 Percentage of Emptiness in Buffer per DCH Session [Pe ] The following calculation is performed for each DCH session by finding the ratio between the total empty buffer duration and the total DCH session duration like. there occurs empty duration of around 500 milliseconds.8 0.Empty Buffer Percentage per DCH session t . the channel down-switching happens only when the down-switching timer expires.*-Android-Market-Android-Market file-download-.milliseconds.2: Average Idle Durations of Buffer during DCH transmission It should be noted that. which is observed in most of the services.1. t De × 100 DDCH Pe = (6.6 0.7 0. However.9 Average Empty Buffer Time [seconds] Figure 6.4 0. Pe .Total empty buffer duration during the DCH session De DDCH .Total time duration of the DCH session 55 . Mean Idle Buffer Time advertisement audio-playback email file-download-.2) where.. So.e. most of the services do not show large number of empty times showing maximum value i.5 0.2 0.1 0. 3 seconds. 6.3 0.*-iTunes-iTunes file-sharing gaming Services instant-messaging maps media-playback social-networking software-update video-playback web-browsing YouTube 0 0.

Figure 6. most of the empty buffer percentage values are more than 80% of the total duration for almost all the services except video-playback and file-download-Android. respectively. around 60% and 75% of the empty percentage values are below 75% for video-playback and file-download-Android.4.The following Figure 6. which shows that. However. because of numerous empty times of buffer during a DCH session. it is evident that the mean empty buffer 56 .3: Empty Buffer Percentage during DCH sessions As shown in Figure 6.3. gives the percentage of these values for each service.

because due to intermittent short gaps between arrivals. which only shows about 40% of the DCH session with empty RNC buffer. there occurs more short empty times in the buffer causing high empty buffer percentage during DCH session for most of the services. which involves understanding the user throughput and transport channel utilisation during DCH transmission according to our buffer model assumptions and 57 .4: Average Empty Buffer Percentage during DCH sessions It is interesting to observe the empty buffer duration percentage in each DCH session.percentage value is around 90% for most of the services. This section addresses the third research question.*-Android-Market-Android-Market file-download-.*-iTunes-iTunes file-sharing gaming Services instant-messaging maps media-playback social-networking software-update video-playback web-browsing YouTube 0 10 20 30 40 50 60 70 80 90 100 Average Empty Buffer Duration [%] Figure 6. RNC cost and resources. it is evident that most of the services have short gaps between arrivals less than 500 ms causing empty buffer during most of the DCH sessions. It should be noted that. followed by video-playback showing 60% empty percentage. except file-download-Android. it incurs more power. Mean Idle Buffer Duration per DCH Session advertisement audio-playback email file-download-.2 Radio Resource Utilisation in Dedicated Channel Performance terms of From the above analyses related to RNC buffer behaviour. 6. when the DCH channels are occupied and the users are inactive during their DCH session.

2. whereas it can be switched up to 1 Mbps or 2 Mbps. Figure 6.5 has throughput values in Mbps on its x-axis. This is evident from the Figure 6. whereas video-playback is found to have around 60% of the throughput between 128 kbps and 1 Mbps. which can have maximum value of 2 Mbps on DCH. with roughly around 60% of the DCH sessions with maximum 512 kbps throughput. non-GBR interactive services show throughput values less than 64 Kbps during most of the DCH sessions. file-download-Android show higher throughput values than any other services. which is similar to almost all the non-GBR background services.1. 58 . BDCH DDCH Ta = (6. GBR streaming services other than video-playback have throughput values around 128 Kbps.Achieved User Throughput during the DCH session BDCH . As can be seen from Figure 6. of bits transmitted per DCH session DDCH .obtained traffic data.5. Ta . The Ta values are found using the equation. On the other hand. when the transmission time for a packet to be fully serviced is more than the acceptable QoS delay for different services as shown in Table 5. 6.5.Total duration of the DCH session It should be noted that. It should also be noted that. However.1 Achieved User Throughput on DCH [Ta ] The throughput achieved per DCH session is termed as user throughput and the maximum achievable is limited to 2 Mbps because of radio link bit-rate limitations as described in 3GPP Release 7 [27]. which can be less than that for pure best effort services. the maximum channel bit-rate is 512 kbps in case of non-GBR background services.3) where.No.

have an average user throughput less than 128 kbps.Figure 6.6 shows that most of the services other than GBR streaming and file-download-Android services. 59 .5: Achieved Throughput on DCH transmission The following Figure 6.

Similar characteristics is observed in almost all the non-GBR background services which shows around 10% DCH utilisation. except 60 .*-Android-Market-Android-Market file-download-. UDCH .Mean Achieved Throughput on DCH advertisement audio-playback email file-download-.1 0.1. It can be found using.6 Average User Throughput on DCH [Mbps] Figure 6.2. it is evident that 35% DCH utilisation is found in case of 70% GBR streaming services and only 15% DCH utilisation is observed in case of 70% non-GBR interactive services.5 0.6: Average Achieved Throughput on DCH transmission 6. Ta × 100 TL UDCH = (6.7.Achieved user throughput per DCH session TL .Utilisation of the dedicated channel per DCH session Ta .2.3 0.2 Dedicated Channel Utilisation [UDCH ] In addition to the analysis related to the user throughput in the previous Section 6.2 0.4) where. there is a need to evaluate the channel utilisation by finding the ratio between the achieved and achievable throughput of the dedicated channel. which is also termed as DCH utilisation.*-iTunes-iTunes file-sharing gaming Services instant-messaging maps media-playback social-networking software-update video-playback web-browsing YouTube 0 0.Link throughput achievable or maximum on DCH link during the DCH session From the following Figure 6.4 0.

Figure 6. 61 .file-download Android. poor utilisation of the channel is observed in most of the cases. But comparatively the proportion is low and according to the assumed channel bit-rate and switching conditions.7: Utilisation of Dedicated Channel for different services However. which shows approximately around 90% DCH utilisation in most of the cases. in a few cases there is 100% utilisation also observed in some of the services.

*-Android-Market-Android-Market file-download-.Mean Utilisation of DCH advertisement audio-playback email file-download-. 6.8: Average Utilisation of Dedicated Channel for different services This is a matter of concern. • The user throughput values are found to have significantly lower values than the achievable throughput of the channel and in turn the DCH utilisation is also found to achieve lower values for most of the 62 . file-download and software-update services. when it comes to resource optimisation in the radio networks in terms of DCH channel allocation. Longer durations of bursts are seen in advertisement and software-update services and larger bursts are found in most of the GBR streaming.*-iTunes-iTunes file-sharing gaming Services instant-messaging maps media-playback social-networking software-update video-playback web-browsing YouTube 0 20 40 60 80 100 Average DCH Utilisation [%] Figure 6. except file-download-Android and video-playback show average DCH utilisation less than 20%.3 Discussion of the Results From the statistical analysis with the obtained real network traces and their behaviour from the buffer model.8 also show that most of the services. Furthermore. the following results are implied: • For almost all the services. the average utilisation levels of DCH for different services from the Figure 6. but the percentage of total empty time duration to a DCH session duration is around 80% for most of the services. the burst size and duration depend on the type and content abundance of the particular service. • Short empty buffer times are observed during DCH sessions for different services and most of their values are below 500 milliseconds.

a methodology to study the RNC buffer characteristics and DCH channel utilisation has been proposed. the bit-rates exhibited in the real network during packet capturing are not known and so the RNC buffer model is studied under default channel assumptions as understood from [27] and the results are observed and analysed. – In order to avoid congestion at the RAN. since the priorities might vary for the services among different operators.services. it may be the time-sensitive data getting higher priority than the non-time-sensitive data or delivery of normal users’ data more important than the heavy users’ data or the service for providing for premium subscribers’ data might be more important than the basic subscribers’ data. the mobile operators have to consider a fair network policy control framework. analyses every single user and his/her service access and no multiple user scenarios are considered simultaneously. • Channel Switching Assumptions Furthermore. with channel transmission assumptions. – However. • Bit-Rate Assumptions – It should be noted that the results are valid only for the conditions assumed in terms of bit-rate conditions in the DCH and FACH channels. which persuaded us to conclude that there exists undesirable resource utilisation with respect to transport channel allocation and overall performance of different services. since this study is aimed at providing characteristics of different services at the radio network with respect to single user traffic flow. the study is mainly aimed at analysing the traffic data obtained and understanding the buffer filling for that particular kind of traffic profiles.4 Validity of the Results As a general idea. – In addition. the buffer model using this assumption. In addition. 6. channel switching considerations in terms of up-switching threshold (in bytes) and down-switching timer (in 63 . which is suboptimal when it comes to effective radio resource utilisation. This differs from one operator to another. – The real transmission conditions were remodelled for the assumptions made for the study and this might be different in real network scenario. However.

The results might vary. since numerous sessions of traffic are considered for each service from the obtained traffic. • Dataset Variations The obtained real network traces are large and it is captured from a single 3G network.seconds) are assumptions based on understanding related to optimal channel switching and processing overhead under the sensitivity analysis. 64 . similarities in the traffic characteristics for different services analysed would be observed in most of the cases. Even if the dataset is varied. if these values are varied.

• RQ 2: How long does the RNC buffer show empty buffer levels during DCH transmission for different services? 65 . durations and sizes of bursts of IP packets for different services? – Most of the bursts of packets have mean inter-arrival time of less than 2 seconds.1 Conclusion From the collective analysis of different service traffic. except file-sharing and instant-messaging. 7. file-download and software-update have large burst sizes of around 50 to 200 kB. other than advertisement and software-update services. which is larger than most of the other services such as non-GBR interactive and non-GBR background services showing mean burst sizes less than 50 kB. so as to address the research questions. it is important to achieve necessary understandings from the results obtained. the major analysis carried out is related to the buffer filling in the RNC for different services and in accordance with the transport channel transitions. – The mean duration of bursts is found to vary around 200 milliseconds for most of the services. which have longer burst durations. the performance of different services in the radio network is studied. This section compares the research questions with the obtained outcomes as follows: • RQ 1: What are the variations in terms of inter-arrivals. – Only some of the services such as GBR streaming.Chapter 7 Conclusion and Future Work In this thesis work. which have mean inter-arrival time of 5 and 10 seconds respectively.

which will be helpful in allocating unused channels to other users. the average achieved user throughput show generally low values for most of the services.– From the analysis made on buffer filling levels. However. – In case of almost all the services.2 Future Work The potential future work of this research can be related to understanding further. file-download-Android and video-playback are found to show better buffer performance than other services. the highest percentage of empty buffer levels during DCH session is found to be around 80%. incurring undesirable cost and power for the RNC. with the perspective of radio resource optimisation. – However. during which there is no data reception or transmission at the RAN. the transport channel requirements for different services may vary and a better solution would be to track the services and provide the channel allocation to eliminate unwanted utilisation of channels. raising a question on effective switching and state considerations in radio access network for data services. Furthermore. that show shorter mean empty times. • RQ 3: How do different services perform on dedicated channel data transmission in terms of user throughput and channel utilisation? – The average buffer levels observed in the RNC are less than 1 MB for most of the services except file-download and software-update services. the mean duration of empty buffer during DCH transmission is found to vary around 400 milliseconds for most of the services. 7. this might additionally increase the overhead and incur more delays due to channel switching. but the resources are still allocated to the users. In addition. utilisation of dedicated channel is found to be around 30% for most of the services. by achieving smaller empty buffer percentages less than 40%. which is not optimal. except the GBR streaming services. – In addition. – Consecutively. the cost and resource utilisation in terms of channel switching between DCH and FACH. taking different services into 66 . these services are widely-used services and have crucial impact on the radio network utilisation and there is a need to analyse solutions to eliminate this problem.

the study can be extended further with analytical modelling with fluid-flow models and this will help us to understand the traffic parameters and their regularities or irregularities for different services. a need to deeply understand the buffer real network cell considerations like and lowly loaded network scenario. Moreover. this may further complicate the model with varying bit-rates for each service according to their data volume understood from the traffic data obtained. medium loaded containing multiple users scenario resource utilisation. the switching conditions.consideration. the RRM functions such as handover and power management functionalities in the buffer model would help to understand the buffer filling for different traffic scenarios and accordingly from these results packet scheduling can be performed at the CN in order to increase the channel utilisation for different services. the capacity or bit-rates of the channels such as DCH and FACH can be increased further until the large backlogs or data volumes in the buffer for some services such as software update vanishes. and test cases and its impacts on the In order to improve the buffer model further. which have been assumed with a specific value can be varied to understand the optimum value of switching for each service under which there may be possibilities of achieving fair utilization of the channel. Furthermore. In addition. the same kind of real of network traces can be used for the analysis with an enhanced buffer model consisting of different load scenario and RRM functionalities to study the performance of different services according to different kinds of network considerations. the switching may have to be compromised with the cost and delays occurred if there are frequent switching. However. with the inclusion of heavily loaded. However. there is behaviour. 67 . From the results obtained. In fact.

[8] W. 2nd Edition. Keralapura and A. Qian. 2008. Morley Mao. ”Evolved Universal Terrestrial Radio Access (EUTRA) and Evolved Universal Terrestrial Radio Access Network (EUTRAN):Overall Description. ”Characterizing Radio Resource Allocation for 3G Networks”.” [5] 3GPP TS 36. pp. ”Evolved Universal Terrestrial Radio Access Network (E-UTRAN). [11] R. 3G Evolution: HSPA Evolution and LTE for Mobile Broadband.300. 6. Lau. G. June 2011. Quality of Service (QoS) concept and architecture. July 2012. Wang. A. 68 . Z. Tan. Lam and W. Spatscheck.” [7] E. Academic Press. S.” [3] 3GPP TS 34. QoS Control and QoS Aware Scheduler”. L. vol. C. Z. Sen and O. ”Universal Mobile Telecommunications System(UMTS). S1 Application Protocol. Nov 2010. [10] F. ”Evolved Universal Terrestrial Radio Access Network (E-UTRAN). ”General Packet Radio Service (GPRS) Enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) Access. IEEE International Conference on Communications.108.” IEEE Transactions on Mobile Computing. Aricent White Paper. June 2008.” [4] 3GPP TS 36. no. Zhu.401. F. Sk¨ old and P. Delay Budget within the Access Stratum. ”Characterizing Data Services in a 3G Network: Usage. Mayank Kumar.Bibliography [1] 3GPP TS 23. Cao. ”Developing a QoS Aware Framework for LTE. Radio Resource Control (RRC).Protocol Specification. J. pp.” [2] 3GPP TS 23. Technical Specification Group RAN. 1-6.107. Beming. 7. S. Nucci. Gerber. 737-750.331. ”An Empirical Study on the Capacity and Performance of 3G Networks. International Mobile Conference.413. Dahlman. Parkvall.” [6] 3GPP TS 36. ”3rd Generation Partnership Project. R. Mobility and Access Issues”. [9] Z.

G. 1-6. [18] L. pp. Sen and O. [14] S. 8 pages. IEICE Transactions on Communications. 217 -223. Pentikousis. 6. 20. March 2007. [21] P. networks and systems. pp. [16] Y.[12] A. March-April 2006. Qian. ”RLC buffer occupancy when using a TCP connection over UMTS”. T. Boggia and K. C. K. 4. September 2002. pp. Wang. Belyaev.” IEEE Transactions on Mobile Computing. March 2008. A. no. vol. J. 252-263. Cerdan and J. 285-294. A. Bouras and V. no. Ohta.” Proceedings of the 1st international conference on Simulation tools and techniques for communications. Mao. Yang and Y. Cerdan and J. ”TOP: Tail Optimization Protocol For Cellular Radio Resource Allocation. no. Garcia-Haro. [15] J. Kawahara. [13] ITU-T Y. January 2005. J. Garcia-Haro. ”Simulation of 3G DCHs supporting TCP traffic: design. Bestak. May 2004. vol. 2008. P. 56-64. pp. Indoor and Mobile Radio Communications. Gerber. ”Performance Evaluation of TCP over UMTS Transport Channels”. ”Differentiated TCP User Perception over Downlink Packet Data Cellular Systems. experiments and insights on parameter tuning. F. [19] R. Oct. 69 . Oie. 11th International Conference on ITS Telecommunications. Perala. X.1541. Wang. Spatscheck. Igglesis. Martins. H. ”Theory and Practice of RRC State Transitions in UMTS Networks. E87B. [22] F. G. 3. ”Performance evaluation of channel switching scheme for packet data transmission in Radio Network Controller”. IEEE Transactions on Wireless Communications. 5. F. Z. M. 2010. Lin. Barbuzzi. Alexiou.” IEEE Network. 3. Article 75. [20] J. 2. ”Network performance objectives for IP-based services”. Wang and M. Sang. vol. 1141-1150.” 18th IEEE International Conference on Network Protocols (ICNP). Ukhanova and E. ”Power consumption analysis of constant bit rate data transmission over 3G mobile wireless networks”. No. pp. 1. Godlewski and P. August 2011. pp. Nov-Dec 2009. vol. ”Optimizing TCP and RLC interaction in the UMTS radio access network. [17] A. 1161-1165. A. J. Z. ”Modeling UMTS Discontinuous Reception Mechanism”. pp. Alcaraz. vol. Alcaraz. S. Madihian. The 13th IEEE International Symposium on Personal. Pedreo.” IEEE GLOBECOM Workshops. Ikenaga and Y.

Wallington and F. Thesis. P. Holma and A. April 2006. 4th Edition. pp.HSPA evolution and LTE. ”Using buffer management in 3G radio bearers to enhance end-to-end TCP performance. 2002. 2005. 70 . November 2005. Van Peteghem and L. John Wiley and Sons. Larmo. 5. 6th IEE International Conference on 3G and Beyond. [26] J. [24] H. [25] A. ”TCP Performance Over UMTS Dedicated Channels with Finite RLC Buffer Size”. J. Toskala. IEEE 65th Vehicular Technology Conference. ”Usability of Instant Messaging over WCDMA”. Finland. pp. S. 1061-1065. Schumacher. Schneider. Cerdan. April 2007. WCDMA for UMTS . Featherstone. [27] H. 1-5. pp. ”UMTS Non Real-Time Sessions Channel Switching Emulation”. Alcaraz and F. Helsinki University of Technology. 2. vol.[23] W. J.” 20th International Conference on Advanced Information Networking and Applications. M.

Appendix 71 .

Appendix A Sub-types of Services • unknown • SSL • HTTP-web-browsing • HTTP • maps-HTTP-Google • file-download-HTTP-iTunes-iTunes • video-playback-HTTP-YouTube-iPhone-Media-Player • social-networking-HTTP-Facebook • Google • blackberry • DNS-system • web-browsing-HTTP-Google • video-playback-HTTP-iPhone-Media-Player • Google-SSL • audio-playback-HTTP-Apple-iPhone-Media-Player • email-IMAP-SSL • email-POP3-SSL • HTTP-audio-playback • video-playback-HTTP-YouTube-Android-Media-Player 72 .

• HTTP-video-playback • email-IMAP-SSL-Google • POP3-email • social-networking-HTTP-Facebook-Facebook • FB1-AKAMAI • HTTP-iPhone-Media-Player • video-playback-HTTP-YouTube-Internet-Explorer • instant-messaging-SSL-Google-GTalk • web-browsing-HTTP-YouTube-iPhone-Media-Player • web-browsing-HTTP-YouTube-YouTube-player • web-browsing-HTTP-Chrome • HTTP-Google • web-browsing-HTTP-Mozilla-Firefox • XMPP-instant-messaging • video-playback-HTTP-YouTube • web-browsing-HTTP-Internet-Explorer • audio-playback-HTTP-iTunes-iTunes • media-playback-RTP-Google • audio-playback-Spotify-Spotify-Spotify • advertisement-HTTP-Google • audio-playback-HTTP-iPhone-Media-Player • web-browsing-HTTP-Apple-Internet-Explorer • HTTP-MMS • FB2-AKAMAI • file-download-HTTP-Android-Market-Android-Market • HTTP-SSL • IMAP-email 73 .

• web-browsing-HTTP-YouTube-Internet-Explorer • software-update-HTTP-Microsoft-Microsoft-Windows • ICMP-system • web-browsing-HTTP-Apple-Mozilla-Firefox • IPSec-NAT-traversal-IPSec-NAT-traversal • software-update-HTTP-Symantec-Symantec • web-browsing • HTTP-Apple • video-playback-HTTP-YouTube-Mozilla-Firefox • FB3-AKAMAI • social-networking-HTTP-Twitter-Twitter • instant-messaging-Google-GTalk • web-browsing-HTTP-YouTube-Android-Media-Player • social-networking-HTTP-Twitter • FTP-file-sharing • RTMP-media-playback • video-playback-HTTP-Mozilla-Firefox • video-playback-HTTP-Internet-Explorer • web-browsing-HTTP-iPhone-Media-Player • maps-HTTP-Google-GoogleEarth • advertisement-HTTP-AdMob • web-browsing-HTTP-Google-Internet-Explorer • email-SMTP-Google • SMTP-email • web-browsing-HTTP-YouTube • web-browsing-HTTP-SSL • social-networking-HTTP-Facebook-Chrome 74 .

• web-browsing-HTTP-Google-Mozilla-Firefox • video-playback-HTTP-Chrome • video-playback-HTTP-YouTube-Chrome • web-browsing-HTTP-megavideo-Mozilla-Firefox • Windows-system • advertisement-HTTP-Flurry • RTSP-media-playback • web-browsing-HTTP-Google-Chrome • web-browsing-HTTP-YouTube-Chrome • web-browsing-HTTP-Apple • video-playback-HTTP-Apple-iPhone-Media-Player • UPnP-system • HTTP-weather • social-networking-HTTP-Facebook-Internet-Explorer • advertisement-HTTP-Google-Internet-Explorer • email-SMTP-SSL-Google • social-networking-HTTP-Facebook-Mozilla-Firefox • HTTP-maps • advertisement-AKAMAI-Google-FB3 • instant-messaging-XMPP-Google • web-browsing-HTTP-YouTube-Mozilla-Firefox • HTTP-Android-Market-Android-Market • web-browsing-HTTP-Apple-iPhone-Media-Player • instant-messaging-HTTP-Yahoo • audio-playback-HTTP-Internet-Explorer • advertisement-HTTP-Google-Mozilla-Firefox • RTP-media-playback 75 .

• video-playback-HTTP-Google • email-POP3-SSL-Google • RTP-Google • email-HTTP-Yahoo • gaming-HTTP-KaW • instant-messaging-HTTP-KakaoTalk • social-networking-HTTP-Xiaonei • social-networking-HTTP-Weibo • instant-messaging-XMPP-SSL • social-networking-HTTP-Twitter-Mozilla-Firefox • gaming-HTTP-WordsWithFriends • web-browsing-AKAMAI • HTTP-SSL-Apple • web-browsing-HTTP-Tencent-QQ • advertisement-HTTP-Google-Chrome • instant-messaging-GTalk • web-browsing-Opera-Mini-sockets-Opera-Mini • email-SMTP-SSL • social-networking-HTTP-SSL-Facebook • photo-sharing-HTTP-Flickr • software-update-HTTP-Flurry-Skype • LLMNR-system • HTTP-YouTube • web-browsing-Mozilla-Firefox • video-playback-HTTP-Tencent-QQ • NTP-system • web-browsing-AKAMAI-Apple 76 .

• audio-playback-HTTP-Windows-Media-Player • HTTP-Internet-Explorer • social-networking-HTTP-SSL-Twitter-Twitter • web-browsing-YouTube • social-networking-HTTP-Myspace • web-browsing-HTTP-Baidu • media-playback-RTSP-Google • HTTP-iTunes-iTunes • web-browsing-HTTP-Baidu-Chrome • FB4-AKAMAI • software-update-HTTP-Installous • software-update-HTTP-Telesphoreo • gaming-HTTP-Flurry-WordsWithFriends • SIP • web-browsing-Internet-Explorer • social-networking-HTTP-Twitter-Internet-Explorer • software-update-HTTP-Skype • gaming-HTTP-Smurfs • social-networking-HTTP-YouTube-Twitter • instant-messaging-Tencent-QQ • web-browsing-Chrome • file-download-HTTP-SSL-iTunes-iTunes • IGMP-system • HTTP-AppleDaily • web-browsing-AKAMAI-Internet-Explorer • social-networking-HTTP-SSL-Twitter • social-networking-HTTP-Twitter-Chrome 77 .

• media-playback-RTMP-HTTP • web-browsing-AKAMAI-Chrome • HTTP-speedtest • instant-messaging-HTTP-Viber-Viber • advertisement-HTTP-YouTube • maps-HTTP-Tencent-QQ • instant-messaging-HTTP-Fring • web-browsing-AKAMAI-Apple-Mozilla-Firefox • instant-messaging-XMPP-SSL-Google • gaming-HTTP-TeamLava-Storm8 • STUN-system • FB1-SSL-AKAMAI • web-browsing-Apple • web-browsing-AKAMAI-Mozilla-Firefox • advertisement-Google • gaming-HTTP-SSL-WordsWithFriends • FB2-SSL-AKAMAI • web-browsing-Google • instant-messaging-HTTP-Google-WhatsApp • AKAMAI-YouTube-FB1 • DHCP-system • AKAMAI-YouTube-FB3 • social-networking-HTTP-Flurv • instant-messaging-HTTP-WhatsApp • email-HTTP-iPhone-Mail • advertisement-HTTP-SSL-Google • maps-HTTP-SSL-Apple 78 .

• software-update-HTTP-Apple-Installous • email-HTTP-Yahoo-Mozilla-Firefox • instant-messaging-HTTP-Apple-WhatsApp • Apple-AKAMAI • social-networking-HTTP-Facebook-Opera • weather-HTTP-Google • instant-messaging-HTTP-Nimbuzz-Nimbuzz • video-playback-HTTP-YouTube-YouTube-player • HTTP-Mozilla-Firefox • gaming-HTTP-Facebook-WordsWithFriends • software-update-HTTP-Adobe-Adobe-Update-Manager • video-playback-HTTP-Tencent-QQ-iPhone-Media-Player • advertisement-HTTP-Google-YouTube-player • instant-messaging-SSL-Tencent-QQ • maps-HTTP-Apple • instant-messaging-MSN • email-HTTP-Google • web-browsing-HTTP-Opera • WAP-MMS • social-networking-Twitter-Twitter • SSH-remote-access • social-networking-HTTP-SSL-Facebook-Facebook • WAP-web-browsing • email-HTTP-SSL-Google • gaming-HTTP-TeamLava • advertisement-AKAMAI-Google-FB2 • video-playback-HTTP-Google-Internet-Explorer 79 .

• HTTP-Tencent-QQ • web-browsing-Google-Mozilla-Firefox • social-networking-HTTP-Facebook-iPhone-Media-Player • instant-messaging-AOL • web-browsing-HTTP-SSL-Apple • weather-HTTP-Internet-Explorer • maps-HTTP-SSL-Google • instant-messaging-HTTP-SSL-WhatsApp • web-browsing-AKAMAI-SSL-FB2 • web-browsing-HTTP-Apple-Chrome • photo-sharing-HTTP-Google • video-playback-HTTP-Google-Mozilla-Firefox • gaming-HTTP-Storm8 • weather-HTTP-Chrome • HTTP-social-networking • web-browsing-HTTP-SSL-YouTube-YouTube-player • instant-messaging-HTTP-Yahoo-Mozilla-Firefox • maps-HTTP-Twitter-Twitter • email-HTTP-SSL-Yahoo • photo-sharing-HTTP-Flickr-Mozilla-Firefox • web-browsing-HTTP-SSL-Apple-YouTube-player • photo-sharing-HTTP-Flickr-Chrome • web-browsing-SSL • speedtest-HTTP-Facebook • weather-HTTP-Mozilla-Firefox • AKAMAI-advertisement-SSL-Google-FB2 • HTTP-Netflix 80 .

• email-HTTP-Google-Mozilla-Firefox • maps-HTTP-SSL • web-browsing-HTTP-Apple-YouTube-player • maps-HTTP-Chrome • social-networking-HTTP-Twitter-AppleDaily • web-browsing-AKAMAI-FB2 • advertisement-Google-Internet-Explorer • web-browsing-HTTP-Netflix • advertisement-AdMob • HTTP-Chrome • instant-messaging-HTTP-Tencent-QQ • gaming-HTTP-Apple-WordsWithFriends • HTTP-Google-Internet-Explorer • email-HTTP-Google-Internet-Explorer • video-playback-Funshion-P2P 81 .