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

Master Thesis Electrical Engineering December 2012

Analysis of Radio Access Network Buﬀer 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 fulﬁllment 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: [email protected]

External Advisor(s)

Tomas Lundborg, Mathias Sintorn, Systems Manager, Senior Specialist R&D, Ericsson AB, Ericsson AB, Development Unit Radio-System and Development Unit Radio-System and Technology, Technology, Torshamnsgatan 33, Torshamnsgatan 33, 164 80 Stockholm, Sweden. 164 80 Stockholm, Sweden.

University advisor:

Prof. Markus Fiedler, School of Computing (COM)

School of Computing Internet: www.bth.se/com Blekinge Institute of Technology Phone: +46 455 385000 371 79 KARLSKRONA SWEDEN 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: Traﬃc Characteristics, Radio Network Controller (RNC), Dedicated Channel (DCH) and Channel Switching.

i Acknowledgement

It would not have been possible to complete my thesis work without the help and support of the kind people around me, to only some of whom it is possible to give particular mention here.

Foremost, I would like to express my deepest sense of Gratitude to Jessica Ostergaard,¨ Manager, Radio Networks - Systems and Concepts, Ericsson AB, for giving me such an wonderful opportunity to perform this thesis work at Ericsson AB.

At this moment of accomplishment, I gratefully acknowledge Tomas Lundborg, Systems Manager for his continuous advice and encouragement throughout the course of this thesis. I thank him for his systematic guidance and great effort he put into training me in the scientific field. My sincere thanks also goes to Mathias Sintorn, Senior R&D Specialist, for his insightful comments and absolute support to the thesis.

I am most grateful to Prof. Markus Fiedler for his technical support and encouragement whenever I was in need.

I would also like to thank my friends in Ronneby, Karlskrona and Stockholm for all the fun we have had during my stay in Sweden.

Last, but by no means least, 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 - both spiritually and materially.

ii Contents

Abstract i

Acknowledgement ii

Contents iii

List of Figures vi

List of Tables viii

List of Acronyms ix

1 Introduction 1 1.1 Scope ...... 1 1.2 Study Prerequisites ...... 2 1.3 Working Process ...... 2 1.4 Contribution ...... 3 1.5 Reader Guidance ...... 3

2 Background 5 2.1 3G Network Architecture ...... 5 2.1.1 WCDMA UMTS Components [27] ...... 5 2.1.2 Radio Network Controller (RNC) ...... 8 2.1.3 Radio Resource Management (RRM) ...... 9 2.2 Data Trace Analysis ...... 10 2.2.1 Trace Generation ...... 10 2.2.2 Trace Analysis ...... 12 2.3 Related Work ...... 16

iii 3 Research Methodology 19 3.1 Aim and Objectives ...... 19 3.2 Research Questions ...... 19 3.3 Research Methodology ...... 20

4 Traﬃc Data Analysis 22 4.1 Service Distribution ...... 22 4.2 IP Packet Characteristics ...... 23 4.2.1 Packet Sizes [SP]...... 23 4.2.2 Inter-arrival Times [IP] ...... 25 4.3 Burst Characteristics ...... 26 4.3.1 Burst Inter-arrival Times [I B] ...... 27 4.3.2 Burst Durations [DB] ...... 29 4.3.3 Burst Sizes [S B] ...... 31 4.4 Session Characteristics ...... 34 4.4.1 Duration of Sessions [DS] ...... 34 S 4.4.2 Data Volume Transmitted per Session [SA] ...... 35 4.4.3 Clean Service Traﬃc Percentage [C S] ...... 37 4.5 Summary ...... 38

5 RNC Buffer Modelling 40 5.1 Trace-Based Simulation Buffer Model ...... 40 5.2 Design Assumptions ...... 43 5.3 Transport Channels and State Transitions ...... 44 5.4 Effects of Buffering Delays and QoS ...... 46 5.5 Attained Buffer Levels ...... 48 5.6 Summary ...... 50

6 Results and Discussion 52 6.1 Idle buffer Characteristics during Dedicated Channel Transmission ...... 52 6.1.1 Empty Buffer Duration [De] ...... 53 6.1.2 Percentage of Emptiness in Buffer per DCH Session [Pe] 55 6.2 Radio Resource Utilisation in terms of Dedicated Channel Performance ...... 57 6.2.1 Achieved User Throughput on DCH [Ta] ...... 58 6.2.2 Dedicated Channel Utilisation [UDCH] ...... 60 6.3 Discussion of the Results ...... 62 6.4 Validity of the Results ...... 63

7 Conclusion and Future Work 65 7.1 Conclusion ...... 65 7.2 Future Work ...... 66

iv Bibliography 68

Appendix 71

A Sub-types of Services 72

v List of Figures

1.1 Working Process ...... 3

2.1 Simplified 3GPP UMTS network reference model ...... 6 2.2 UTRAN Components and Interfaces ...... 7 2.3 Overview of RNC in UTRAN connecting CN and UE . . . . 8 2.4 Modes of RRC and CELL States of UE ...... 9 2.5 Differentiation criteria for services from the traffic logs [1] . . 12 2.6 Essential terms and their definitions with respect to traffic [11] 15

3.1 Step-by-step ﬂow of the research work ...... 21

4.1 Service Distribution ...... 23 4.2 Packet sizes for different services ...... 24 4.3 Inter-arrival times between packets for different services . . . 26 4.4 Inter-arrival time between bursts for different services . . . . 28 4.5 Mean Inter-Arrival Time between Bursts ...... 29 4.6 Duration of Bursts for different services ...... 30 4.7 Average Burst Durations ...... 31 4.8 Burst sizes for different services ...... 32 4.9 Mean burst sizes for different services ...... 33 4.10 Durations of Sessions for different services ...... 35 4.11 Data Volume per Session for different services ...... 36 4.12 Mean Clean Service Traffic Percentage for different services . 38

5.1 Calculation of different parameters of the buffer model . . . . 42 5.2 Flowchart of RNC buffer model in relation with queueing . . 43 5.3 Switching between transport channels and UE State Transitions 45 5.4 Average Buffering Delays for different services ...... 47 5.5 Buffer filling levels for different services ...... 49 5.6 Average buffer levels for different services ...... 50

6.1 Idle Durations of Buffer during DCH transmission ...... 54 6.2 Average Idle Durations of Buffer during DCH transmission . 55 6.3 Empty Buffer Percentage during DCH sessions ...... 56 6.4 Average Empty Buffer Percentage during DCH sessions . . . 57

vi 6.5 Achieved Throughput on DCH transmission ...... 59 6.6 Average Achieved Throughput on DCH transmission . . . . . 60 6.7 Utilisation of Dedicated Channel for diﬀerent services . . . . 61 6.8 Average Utilisation of Dedicated Channel for diﬀerent services 62

vii List of Tables

2.1 UE states and Transport Channels with corresponding achievable bit-rates [27] ...... 10 2.2 Sample tags captured from the traﬃc capturing tool . . . . . 14

5.1 QoS End-to-End Packet Delay Range for Diﬀerent 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 Chapter 1

Introduction

Due to ever-increasing users and subsequent network capacity requirements, resource optimization techniques to ensure optimal use of radio resources in the network to achieve good service quality are under research.

Moreover, the performance of diﬀerent services in the radio network scenario in terms of network parameters such as user throughput, empty RNC buﬀer periods and transport channel utilisation are very important to understand the impact of poor resource usage on the system capacity. In addition, 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, latency and jitter in the transmission, caused by inadequate channel capacity.

With the help of some suggestions from [10], 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, there is a need to emphasize further on performance variations observed during the existence of traffic for different data services in RAN. In this research, considering different services and their traffic from real network traces, the buffer filling is analysed and performance variations in terms of channel utilisation is studied.

1.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. This will be determined by understanding the characteristics of input traffic data and different output parameters of the

1 modelled buﬀer in terms of Cumulative Distribution Function (CDF), mean values and conﬁdence intervals (CI).

The report will demonstrate the obtained traffic characteristics, RNC buffer model and finally illustrate the results obtained from the buffer model with default channel bit-rate considerations, after supplying the epoch timestamps and corresponding packet sizes from real network traces as input. The discussions will be made regarding the bursty behaviour of the traffic models, empty buffer behaviour and dedicated channel utilisation.

1.2 Study Prerequisites

For the work conducted in this research, the prerequisites needed were:

• Knowledge of the networking protocols used in today’s 3G and 4G mobile networks.

• Understanding of queuing theory and its application on teletraﬃc engineering and packet data networks.

• Knowledge of statistical modelling and empirical data analysis with understanding related to cumulative distribution, mean, standard deviation and conﬁdence interval.

An initial study was conducted for four weeks during which a selected number of books and articles were read, which provided knowledge on mobile communication in general, the basics of 3G and 4G networks, the transmission protocols, Radio Access Network (RAN) architecture and queuing theory in general.

1.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. According to these assumptions and the input traffic data, the model estimates the empty buffer time and DCH utilisation for the users using different services. For achieving the outcomes, the working process as shown in Figure 1.1 is involved.

2 Trace Files Collected Traffic Data through Traffic Analysis Service Capturing tool Name RNC Buffer User 1 Model User 2 Parsed Trace File according to User N service tags

Estimation of Buffer and DCH Parameters

Figure 1.1: Working Process

Further explanations on the research methodology and process ﬂow will be explained in detail in Chapter 3.

1.4 Contribution

The major contributions of this thesis work are as follows:

• A methodology for evaluation of RNC buffer filling with real network traces, taking different services into consideration.

• Analysis of traﬃc data in terms of packet sizes and inter-arrival times for diﬀerent services and its performance variations during dedicated channel transmissions.

• Presentation of results in terms of empty buffer time, 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.

1.5 Reader Guidance

The remainder of the report is organised as follows. The background information, key concepts covering 3G network architecture, data trace analysis and related work are explained in Chapter 2. Chapter 3 describes the aim and objectives, followed by the research questions and research methodology.

In Chapter 4, the traffic data analysis from the obtained real network traces for different services is covered. The RNC buffer modelling with design assumptions and validations are explained in Chapter 5 and

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

4 Chapter 2

Background

2.1 3G Network Architecture

The Universal Mobile Telecommunication Systems (UMTS) is designed to have ﬂexible delivery of any type of service with no requirement of network optimisation for each service [27]. UMTS is evolving to cope with ever-increasing need of wireless data services such as multi-media messaging, video streaming, location based services, mobile commerce and on-line gaming.

This section is organised as follows, Section 2.1.1 explains essential components of WCDMA UMTS network brieﬂy, followed by Section 2.1.2 about Radio Network Controller (RNC) and its modes of operation in terms of buﬀer behaviour and Section 2.1.3 covers Radio Resource Management (RRM) present in UTRAN for resource control mechanisms.

2.1.1 WCDMA UMTS Components [27] According to the 3GPP reference network model, UMTS consists of four major network components as follows: • User Equipment (UE)

• Radio Access Network (RAN)

• Core Network (CN)

• External Network (e.g., IP networks, PSTN/ISDN) The UE is the end-user electronic device such as Android/iPhone, iPad or PC dongle connected to the network through Mobile Station (MS). In addition, the data bandwidth of the UE is signiﬁcantly limited by the battery capacity of UE due to MS power consumption during wireless data transmission [18].

5 In 3GPP and ETSI, the RAN is termed as UTRAN (UMTS Terrestrial RAN) and this network part is of our research interest. Several components making up this network will be explained to understand how bits are transmitted over the radio interface.

PSTN/ISDN

Circuit- WCDMA Switched Node B Domain IP Network RNC Packet Switched Domain

Core User Radio Access Network Equipment External Network Network (RAN) (CN) (UE)

Figure 2.1: Simpliﬁed 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. In addition, the CN is responsible for switching/routing calls and data connections to external networks, whereas RAN handles all radio-related functionality.

As far as RAN is considered, it is essential to understand the functionalities of the following components,

• Radio Base Station (Node B)

• Radio Network Controller (RNC)

• Interfaces

Node B This provides air interface L1 processing such as channel coding and interleaving, rate adaptation, spreading and so on. Some of the radio resource management functions like inner loop power control are also carried out by Node B. 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 by the Controlling RNC (CRNC). Whereas, Serving RNCs (SRNC) perform L2 processing of data to/from the radio interface, mapping of Radio Access Bearer (RAB) parameters into air interface transport channel parameters, hand-over decisions and outer-loop power control.

In the same way, the Drift RNCs (DRNC) control cells used by the mobile, macro diversity combining and splitting. A single RNC normally contains all the CRNC, SRNC and DRNC functionalities.

UTRAN Interfaces

Figure 2.2: UTRAN Components and Interfaces

1. UTRAN-CN (Iu) As can be seen from Figure 2.2, Iu has two diﬀerent instances, which diﬀer according to the type of external network. If the external network is a circuit-switched (CS) network consisting of Mobile Switching Center (MSC)/Visitors Location Register (VLR), the interface is termed Iu-CS. On the other hand, Iu-PS is used in case of a packet-switched (PS) network with Serving General Packet Radio Services Support Node (SGSN). Another interface, Iu Broadcast (Iu-BC), is used for the Broadcast domain of CN, which is not shown in Figure 2.2.

2. RNC-RNC (Iur) This interface is primarily to enable inter-RNC soft handover, but it has some additional functionalities such as

(a) Inter-RNC mobility;

7 (b) Dedicated channel traﬃc handover; (c) Common channel traﬃc handover; (d) Global resource management.

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, according to operators’ requirements.

3. RNC-Node B (Iub) In case of the Iub interface, traﬃc termination is one of the main functions and the signalling interface is Node B Application Part (NBAP), 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.

4. Node B-UE (Uu) Finally, the Uu interface is between the RAN and UE, which with the help of MS, transmits data over the radio interface.

2.1.2 Radio Network Controller (RNC) The RNC plays an important role in maintaining the proper ﬂow of data according to available bit rates over the radio link. Moreover, there are several protocols, which make this process easier to control, as there is a large number of users sharing a particular RNC. It owns and controls the resources in the radio network in its domain and also manages the connections to UE [27].

External Network

RNC UE Node B Processor Buffer UMTS Core Network

Figure 2.3: Overview of RNC in UTRAN connecting CN and UE

As shown in the Figure 2.3, the RNC processes the packets received from CN by queuing the packets and transmitting with a deﬁned bit-rate,

8 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. However, the attained bit-rates vary over time due to varying network conditions, transport channel availability and number of users within a particular cell.

2.1.3 Radio Resource Management (RRM) RRC messages in terms of handovers, cell updates and measurements between UE and UTRAN are performed by the RRM functionalities present in the RAN. There are two basic modes of operation: idle and connected mode.

Connected Mode

CELL_DCH

Idle Mode CELL_FACH

CELL_PCH URA_PCH

Figure 2.4: Modes of RRC and CELL States of UE

Idle During idle mode, the UE can receive system information and broadcasting messages through RRC signaling, but UTRAN has no connection with UE at this point and does not have any information about the idle mode UEs. However, the connection can be created through paging (network initiated) or random access (UE initiated).

Connected On the other hand, during connected mode, there can be four possible states such as CELL DCH, CELL FACH, CELL PCH and URA PCH as shown in Figure 2.4. In these states, CELL represents the current cell, URA represents the UTRAN Registration Area, under which the RNC can locate the UE. Furthermore, the UE can transmit or receive data through any of the following transport channels as shown in Table 2.1.

During the CELL DCH state, DCH is allocated for the user, which can be mapped to physical channels such as Dedicated Physical Data Channel (DPDCH) or Dedicated Physical Control Channel (DPCCH). This has higher transmission rates to provision high bandwidth services.

9 Conversely, during low bit-rates, UE is forced to CELL FACH state. Thus data transmission is achieved through FACH having low bit rates as the channel is shared.

In the CELL PCH state, the user can be contacted through PCH and the user is known on the cell level in this state. This same scenario is applicable in URA PCH, except that the user can be known on URA level and paging is over the entire URA.

The channel-switching functions are carried out by Radio Resource Management (RRM) function through Radio Resource Control (RRC) protocol messages. In other words, the UE will be assigned appropriate transport channels, and the data rate is controlled, through RRM.

Table 2.1: UE states and Transport Channels with corresponding achievable bit-rates [27] UE State Transport Practical Bit-Rates Channel CELL DCH Dedicated High, up to 2 Mbps Channel (DCH) CELL FACH Forward Low, up to 64 kbps Access Channel (FACH) CELL PCH/URA PCH Paging Only Signalling/Paging Channel (PCH)

2.2 Data Trace Analysis

This part is organised as follows, Section 2.2.1 explains the way in which the traces i.e. traffic data are collected and their properties we determined and Section 2.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.

2.2.1 Trace Generation To address the characteristics of the buffer filling for different services in the RNC of UTRAN, traces are collected from an operating 3G network in a major American city. In addition, the data is collected at the interface between CN and RAN, i.e. Iu-PS using a traffic capturing tool, which is an

10 Ericsson tool set to measure and analyse IP traﬃc.

Furthermore, it processes and classifies traffic online and instead of full traces, only stores traffic statistics at various levels of detail. 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.

This tool classifies the user plane traffic using a set of rules and associated decision logic defined in an XML file. So, during evaluation of the rules, payload of incoming packets is matched against each rule. In addition, 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. For this, each user data flow may have zero or more tags attached to it, as defined by the classification rules.

The traces are collected for every single minute interval for 2 days continuously, 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, and that packet traffic information is collected from 3G network only.

In addition, each packet is identiﬁed using timestamps, TCP/UDP session, source IP address and port number, destination IP address and port number, uplink/downlink, encoded International Mobile Subscriber Identity (IMSI), International Mobile Equipment Identity (IMEI) and service tags.

It should be noted that the link bit-rates exhibited in the radio network are not known. Furthermore, 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.

So assumptions on channel bit-rates are made and buffer fillings under this scenario for different services are studied.

11 2.2.2 Trace Analysis

Non-Guaranteed Bit-Rate Guaranteed Bit-Rate

QoS Classes Conversational Streaming Interactive Background

Services Gaming Web-browsing Email ...

Service Web-browsing-HTTP-Google Social-Networking-SSL-Facebook Sub-Types ...

Figure 2.5: Diﬀerentiation criteria for services from the traﬃc 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. Each service has its own traffic parameters according to QoS differentiation in terms of priority, packet delay and packet error loss rate. In Section 5.4, the QoS packet delay parameter for each service will be explained in detail.

From the bit-rate considerations observed in the real network scenario, the Guaranteed Bit-Rate (GBR) bearer carries traffic that requires a minimum bit-rate guarantee from the network, 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].

As shown in the Figure 2.6, the conversational and streaming services, which are real-time or GBR services need low packet delay and loss ratio. On the other hand, non-GBR services such as background services are considered to be delivered with best eﬀort.

Moreover, as the research is related only to the data services in the wireless networks, the conversational services such as voice or video calling are not considered.

2. Services The traﬃc data collected has diﬀerent services, but to reduce the

12 complexities, all the major services are only taken out from the trace files. The service here is termed as functionality in the traffic capturing tool, which will be an essential parameter to differentiate the packet when it is collected.

According to 3GPP 23.107, the services are differentiated according to their QoS in the following way to understand their characteristics related to this research separately. However, the extent of QoS based prioritization in the input traces is not known. Moreover, this is not relevant for the study, since the analysis is considered with a single user at a time. (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, RTSP, whereas video and audio-playback are buffered streaming with HTTP protocol. 3. Service Sub-Types

Furthermore, the tags that are attached to flows are grouped into facets, representing different aspects of the traffic. Facets include • Functionality The functionality or service tells the activity type for which the flow is used and this comprises of social-networking, web-browsing, instant-messaging, gaming, maps, software-update, file-download, email, video-playback, audio-playback, media-playback and advertisement.

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

For example a ﬂow can be characterised like sample tags given in the Table 2.2.

Table 2.2: Sample tags captured from the traﬃc capturing tool protocol functionality service- client- encryption provider application HTTP social- Facebook Mozilla- SSL networking Firefox HTTP video- Apple iPhone- - playback Media-Player RTSP media- - - - playback

14 IP PACKETS time (s) B2 Burst B1 Sizes > 200 ms B3 (bytes) BURSTS Burst Duration time (s)

S1 S2 Session > 300 s Sizes SESSIONS (bytes) time (s) Session Duration U1 U2 USERS

time (s)

Figure 2.6: Essential terms and their deﬁnitions with respect to traﬃc [11]

4. 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. 5. Bursts It is important to understand the term bursts, 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.6. Even if it is a single packet with no packets accompanying it with inter-arrival time less than 200 ms, then that particular packet is also considered as a burst.

It should be noted that, the inter-arrival time of packets within a burst can be assumed with different values other than 200 ms such as 2 s, 5 s or 10 s and so on for different services depending on the assumptions on user behaviour, but it is assumed to have a fixed value in this study i.e. 200 ms for all the services to reduce complexity in comparison and analysis. In addition, this value is assumed only after prior understanding of the packet inter-arrivals

15 and related analysis on the traﬃc data. So, if the packet inter-arrival time is more than 200 ms, 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, duration and size of bursts for diﬀerent services in the radio network scenario. In addition, numerous research work state the principle of bursty behaviour in packet arrivals for most TCP services, rather than regular inter-arrivals of packets.

6. Sessions For a single user, there may be continuous flow of packets for a certain time period or intermittent gaps between the packet flows, when a single service is considered. Thus, as shown in Figure 2.6, a session is termed as the traffic during downlink data transmission with no inactivity for about 300 seconds. If there is such an inactivity, 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.

7. Users If a particular service is considered, the whole trace file is checked with the help of tags, for the users who use this service. This information is used for further investigating into the flow of packets towards the user for different services.

After the differentiation of services with the aforementioned criteria, the research is carried out on analysing several parameters both from the traffic and buffer model implemented. Finally, the analysis of essential parameters to understand the radio resource utilisation is also made.

2.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. In addition, 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.

16 RNC Buffer Related Work In [19], analysis of TCP performance with respect to RLC buffer size is analysed, 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). 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]. In addition, the expected waiting times, queue length and power saving factor are also analysed in [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]. An analysis related to link throughput according to changes in the buffer size by varying TCP flavour (Tahoe, Reno, NewReno or SACK), FTP file size, RLC buffer size and DCH data rates is conducted in [23]. 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, delay in the radio access network and throughput in the wireless link [17].

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 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, system overhead and performance.

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].

In addition, resource utilization in terms of channel switching is an important consideration, under which there are various algorithms proposed to meet the speciﬁcations of RNC and evaluations are made with the help of simulations. Furthermore, several impacts of parameter settings on performance with respect to packet loss probability and utilisation of dedicated channels are analysed in [16]. Moreover, the behaviour of Non-Real-Time sessions and channel switching are evaluated with the help

17 of blocking rate, mean packet delay and cell throughput to decrease the number of blocked calls keeping other metrics at a satisfactory level [24].

Even though there are numerous works in the radio resource and performance analysis, this research aims at studying in detail the RNC buffer filling with fixed channel bit-rate conditions, taking the most widely used data services existing in wireless 3G and LTE networks into consideration.

18 Chapter 3

Research Methodology

This chapter is organised as follows: Section 3.1 explains the aim and objectives, Section 3.2 gives the guiding questions to be addressed and motivation behind the research and Section 3.3 describes the research methodology handled in order to fulﬁl the goals of the thesis work.

3.1 Aim and Objectives

The goal of this thesis work is to investigate how traffic from real, 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;

• ﬁt a parameterized model of IP packet inter-arrival times and IP packet sizes to the existing packet traces, taking into account diﬀerent services;

• implement and analyse diﬀerent parameters of the RNC buﬀer model;

• evaluate buffer filling for users using different services in the radio network, in terms of resulting parameters of the model;

• with the resulting level of buffer filling, analyse radio resource utilization and radio network performance in terms of RNC buffer and DCH parameters for different services.

3.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, durations and size of bursts of IP packets for diﬀerent services?

19 • RQ 2: How long does the RNC buffer show empty buffer levels during DCH transmission for different services?

• RQ 3: How do diﬀerent 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.

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. In addition, this is essential to gather information about the performance of different services in the radio network in terms of buffer utilisation.

From the third question, the analysis will reﬂect the radio resource utilisation with respect to dedicated channel for diﬀerent services.

3.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. The following describes the steps carried out to obtain the necessary outcomes of this research as shown in Figure 3.1.

1. The data traﬃc is analysed to get the knowledge of obtainable parameters from the trace ﬁles.

2. 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.2.

3. From the traces, the packet sizes and inter-arrival times are examined for different services and bursts of the data traffic is also analysed, so as to understand the regularities or irregularities of bursts in traffic for different services.

4. 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.

5. The obtained traffic separated as sessions for different services are supplied as input to the buffer to evaluate the buffer filling.

20 6. To validate the buffer model, the buffer levels achieved and packet delays occurred due to buffering are estimated for different services.

7. During DCH transmission, 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.

8. The radio resource utilisation is studied in terms of obtained user throughput and channel utilisation on the DCH link for diﬀerent services from the buﬀer model.

Traces obtained from RNC Buffer Modelling & Service / Functionality Traffic Capturing Tool Analysis

Traffic Data Analysis Transport Channels Encoded user IMSI + (IP ****FACH Session-wise traffic RNC Buffer packet sizes and epoch data file (Leaky-bucket) timestamps) ***DCH

Buffer Parameters: DCH Parameters: *Burst Characteristics: **Session Characteristics: (Buffer levels, (Empty buffer time, (Inter-arrival times, (Duration and Data Buffering packet User throughput, durations and sizes) Volume) delay) Channel utilisation)

* - Bursts are assumed to be one or more IP packets with inter-arrival time less than 200 ms ** - Sessions are traffic flows towards a user with no inactivity greater than 300 s, after which session ends *** - Dedicated Channel with high bit rates up to 2 Mbps with exception of background services having fixed 512 kbps **** - Forward Access Channel with low bit rates because of the shared nature of the channel

Figure 3.1: Step-by-step ﬂow 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. 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.

21 Chapter 4

Traﬃc Data Analysis

The obtained packet traffic data is analysed by classifying the services under their corresponding QoS classes as mentioned before, so as to understand the inter-arrival times and packet sizes for different services. Some of the major parameters needed to understand the traffic characteristics of different services are also explained in this section.

4.1 Service Distribution

Primarily it is essential to know the amount of each service traffic present in the collected traffic data. The sessions considered for different services vary in the amount of data transmission and time duration. As mentioned before, the session ends after 300 s of inactivity. So, the total data volume, total number of sessions and total duration of the session are estimated for each service.

Total Data Volume [%] The data volume of a session is calculated by summing up the IP packet sizes during that particular session. 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 ﬁle.

The percentage of total data volume is calculated so as to ensure clarity in the picture as shown in Figure 4.1. It is evident from Figure 4.1 that, almost all the streaming, ﬁle-download and web-browsing services show larger data volumes than other services.

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 sessions for all the services. As can be seen from the Figure 4.1, web-browsing, social-networking, instant-messaging and email show a comparatively large number of sessions.

100 YouTube web-browsing video-playback software-update 80 social-networking media-playback maps instant-messaging gaming 60 file-sharing file-download-.*-iTunes-iTunes file-download-.*-Android-Market-Android-Market email audio-playback % of total 40 advertisement

0 Total Data Volume[%]Total Number of Session[%]Total Session Duration[%]

Details of Service Sessions

Figure 4.1: Service Distribution

Total Session Duration [%] In addition to the above analysis related to total data volume [%] and total number of sessions [%], the total session duration [%] for diﬀerent services is also important. 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. It is evident from the Figure 4.1 that, web-browsing, social-networking, instant-messaging, email and advertisement show longer durations of sessions than other services. This is similar to that of the total number of sessions [%].

In short, all the streaming, web-browsing, maps and ﬁle-download services have shorter session durations and lower number of sessions, but transmit larger data volume than social-networking, instant-messaging, email and advertisement services.

4.2 IP Packet Characteristics

4.2.1 Packet Sizes [SP] The characteristics of the traffic flow can be understood from the packet sizes and inter-arrival times for different services.

23 Figure 4.2 gives an overview of packet sizes in the form of CDF plot, from which almost all GBR streaming services are found to have 80% of packet sizes on 1448 bytes, other than media-playback which has varying packet sizes between 52 and 1448 bytes.

Figure 4.2: Packet sizes for diﬀerent services

In case of non-GBR interactive services such as gaming, instant-messaging and social-networking, 60% packet sizes are found to be 52 bytes, whereas web-browsing and maps show packet sizes of 1448 bytes

24 for roughly 70% of the values.

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. On the other hand, 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.

Similar behaviour to that of streaming services is observed in case of file-download and software-update services, whereas advertisement and file-sharing show packet sizes of 52 bytes in 50% of the values. It is interesting to look at the file-sharing services, which show small packet sizes probably due to signalling in the network.

4.2.2 Inter-arrival Times [IP] As can be seen from Figure 4.3, similarities among services in terms of inter-arrival times are observed. It is evident from the Figure 4.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, according to our assumptions, from the traﬃc data obtained.

25 Figure 4.3: Inter-arrival times between packets for diﬀerent services

4.3 Burst Characteristics

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

26 Thus the ﬁrst research question on analysis related to bursts, is addressed in this section. This deals with the study of bursty behaviour of packet arrivals in terms of burst inter-arrival times, durations and sizes taking diﬀerent services into consideration.

4.3.1 Burst Inter-arrival Times [I B] The formula used for calculating this value is as follows,

B B B In = ts,n − te,n−1 (4.1)

where, B In - Inter-arrival time of burst n in seconds

B ts,n - Epoch time stamp of ﬁrst packet or start of current burst

B te,n−1 - Epoch time stamp of last packet or end of previous burst

It should be noted that, the inter-arrival times between bursts have a minimum value of 200 ms, below which the packets are considered as bursts. In addition, there is a maximum value of 300 seconds, above which the session is considered to be terminated and new session will commence with arrival of packets of the service considered.

It can be observed from Figure 4.4 that GBR-streaming services, interactive services except instant-messaging and background services except advertisement and ﬁle-sharing show most of the inter-arrival times between bursts less than 1 second.

Moreover, instant-messaging and advertisement have roughly 60% of the burst inter-arrival times less than 1 second. However in case of ﬁle-sharing, there is only 40% of the inter-arrival times are less than 1 second.

27 Figure 4.4: Inter-arrival time between bursts for diﬀerent 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 instant-messaging maps Services 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 conﬁdence 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 ﬁle-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 diﬀerent 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 B Dn = te,n − ts,n (4.2) where, B Dn - Duration of burst n in seconds

B te,n - Epoch time stamp of last packet or end of current burst

B ts,n - Epoch time stamp of ﬁrst 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 diﬀerent services

In addition, from the Figure 4.7, the mean and conﬁdence 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 instant-messaging maps Services 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 fulﬁls the following condition,

P P tm+1 − tm < 200 ms (4.3) where, P tm+1 - Epoch timestamp of the next packet, in seconds

P tm - 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 Sn - Data Volume or Size of the burst n, in bytes

P P Sm...Sm+N - Size of each packet from m to m+N (m+N is the total

31 number of packets in the burst), in bytes

Figure 4.8: Burst sizes for diﬀerent services

As shown in Figure 4.8, 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, whereas video-playback is found to have around 80% of the burst sizes between 1 kB and 1 MB. The reason behind this characteristics emphasizes the larger contents sent as bursts in case of

32 video-playback than the audio and media-playbacks.

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, which is because of single packets as bursts most of the time. However, maps, social-networking, web-browsing, email, advertisement and software-update show burst sizes between 100 bytes and 100 kB in roughly 70% of the values.

Conversely, 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, 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.

Eventhough the presumption was like all the ﬁle-download services have similar characteristics in downloading, the obtained results from burst sizes for diﬀerent services show varying characteristics.

Mean Burst Sizes advertisement audio-playback email file-download-.*-Android-Market-Android-Market file-download-.*-iTunes-iTunes file-sharing gaming instant-messaging maps Services media-playback social-networking software-update video-playback web-browsing YouTube

0 50 100 150 200 250 Burst Sizes [KB]

Figure 4.9: Mean burst sizes for diﬀerent services

From the Figure 4.9 above, most of the services have burst sizes less than 50 kB, 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.

33 4.4 Session Characteristics

4.4.1 Duration of Sessions [DS] The following analysis is related to understanding the length of sessions for diﬀerent services. From the following Figure 4.10 showing the duration of sessions in minutes, it is evident that almost all the services have most of their session durations approximately less than 100 minutes.

It is interesting to note that, around 70% of the streaming and ﬁle-sharing services show session durations between 1 and 100 minutes, which is higher than interactive services and background services.

34 Figure 4.10: Durations of Sessions for diﬀerent services

S 4.4.2 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 diﬀerent services.

From the following Figure 4.11, the GBR streaming services are found to have 70% of the sessions with data volumes in the range of 10 kB and 100 MB.

35 Figure 4.11: Data Volume per Session for diﬀerent services

Conversely in case of non-GBR interactive services, instant messaging shows around 80% of the sessions with session data volume less than 10 kB, followed by gaming and social-networking with 80% session data volume in the range of 1 kB and 100 kB. However, maps and web-browsing services show around 60% of the sessions with data volumes between 10 kB and 10 MB.

In case of background services roughly around 80% of the sessions have session data volumes below 100 kB, other than ﬁle-download-Android

36 showing 70% of the sessions having data volume ranging from 1 MB to 10 MB, which is observed to transmit highest volumes of data per session from the obtained traces.

From the analysis related to session data volumes, it is clear that GBR-streaming services achieve larger data volumes than other services, which may be because of the bulk data sent towards the user during each session in terms of streaming services.

4.4.3 Clean Service Traffic Percentage [C S] It should be noted that the traffic data considered for different services, may possess other services also in the bursts of packets, due to simultaneous access of different services at the user side.

Moreover, 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. In other words, there are possibilities that the bursts of packets of a particular service may have a few packets belonging to other services.

So, the percentage of packets belonging to a particular service during a session is calculated to understand this value from the obtained traffic data. Here, the term session has the same definition as mentioned in Section 2.2.2. This also helps us to ensure how reliable different traffic data from the traces, representing the services under consideration.

This is calculated by ﬁnding the ratio between amount of data S transmitted as clean service packets only during a session SC and total S data volume transmitted during the session SA.

S S SC C = S × 100% (4.5) SA where, CS - Clean Service Traﬃc Percentage per session

S SC - Amount of data transmitted as clean service packets per session

S SA - Total data volume transmitted or summation of all packet sizes per session as explained in Section 4.4.2

So, the higher the value of CS, cleaner the service is. The mean clean service traﬃc percentage is calculated for each service and the 95%

37 conﬁdence interval is plotted in the Figure 4.12 below, showing most of the services achieve CS greater than 75%.

Percentage of Clean Bursts per User Session advertisement audio-playback email file-download-.*-Android-Market-Android-Market file-download-.*-iTunes-iTunes file-sharing gaming instant-messaging maps Services media-playback social-networking software-update video-playback web-browsing YouTube

0 20 40 60 80 100 Clean Bursts [%]

Figure 4.12: Mean Clean Service Traﬃc Percentage for diﬀerent services

4.5 Summary

To put it in a nutshell, the traffic data analysis is essential to understand the behaviour of the flow of traffic for different services in terms of packet sizes, inter-arrival times, bursts and sessions. Some of the points to remember from this analysis are as follows:

• Packet sizes obtained from the traces are mostly 52 and 1448 bytes, for which diﬀerent services share these sizes in diﬀerent proportions, depending on their corresponding data volume transmitted.

• In case of inter-arrival times, except ﬁle-sharing, which has approximately 60% of its inter-arrival times greater than 200 ms, 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.

• When it comes to bursty behaviour of the TCP traﬃc, most of the services show bursty arrival of packets in 90% of the traces. Furthermore, services such as advertisement, software-update and gaming show higher proportion of mixture of other services also in the bursts than other services. However, most of the sessions considered for diﬀerent services show more than 75% clean service packets and helpful for analysis on each service separately.

38 • Most of the user sessions considered are found to have their durations below 1 hour, but still there are some sessions which last for longer durations than an hour.

• The total data volume transmitted to the users during their sessions is dependent on the type of traffic, since different services have varying size in the amount of data sent. Thus, there exist relatively high data volumes in case of streaming and file-download services.

For the subsequent study on buffer filling, the analysis related to burst characteristics is of major importance, because it is helpful in understanding the traffic data filling buffer, given the inter-arrival times and sizes of bursts. Moreover, 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.

39 Chapter 5

RNC Buﬀer Modelling

This chapter is organised as follows: Section 5.1 gives an overview on how the buffer is modelled explaining how the input from the obtained traces is handled, and an example scenario to understand how the output parameters are estimated from the buffer model. Section 5.2 explains the major design assumptions and approximations made for the buffer model. Section 5.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. Section 5.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. Finally, Section 5.5 describes the achieved buffer levels and its relationship with the burst sizes for different services.

5.1 Trace-Based Simulation Buﬀer Model

The real network data obtained has been differentiated into session-wise traffic data files for each service. In addition, as mentioned before sessions are active periods containing downlink data traffic for users under each service.

From this traffic data, each packet data in terms of epoch timestamp and packet size for different services is given as input to the buffer. However, each packet will be serviced according to the bit-rate in the channel existing at that particular moment of packet arrival.

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, which are set as default for our study. Furthermore, 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 as follows:

At the point of a packet arrival,

INITIAL CONDITIONS If UE is Idle: Channel = DCH and TransmissionRate = 512 kbps; If UE is not Idle and Channel == DCH: TransmissionRate = 512 kbps; If UE is not Idle and Channel == FACH: TransmissionRate = 16 kbps;

CHANNEL UPSWITCHING If UE is not Idle, Channel == FACH and BufferLevel > 512 bytes: Channel = DCH and TransmissionRate = 512 kbps;

CHANNEL DOWNSWITCHING If UE is not Idle, Channel == DCH and Emptytime > 3 seconds: Channel = FACH: TransmissionRate = 16 kbps;

SERVICE-DEPENDENT CHANNEL UPSWITCHING ON QoS If UE is not Idle and Service is Streaming/Interactive and TransmissionTime > MaxAccDelay : TransmissionRate = BufferLevel/MaxAccDelay where, MaxAccDelay is the maximum acceptable packet delay caused in the network and acceptable for the user and it differs for different services. It takes the value of 1 second for streaming and 400 milliseconds for interactive according to [13] on QoS requirements. If 512 kbps < TransmissionRate < 1 Mbps: TransmissionRate = 1 Mbps; else TransmissionRate = 2 Mbps.

41 A2 A3 A4 A1 IP Packet Arrivals & Departures

0 1 2 3 4 5 6 7

D1 D2 D3 D4

Buffer Buffer Filling Levels

0 1 2 3 4 5 6 7 Empty Empty Packet Time Time Buffering User Delay Throughput DCH Channel FACH Switching

0 1 2 3 4 5 6 7

Figure 5.1: Calculation of diﬀerent parameters of the buﬀer model

As shown in Figure 5.1, if there is an arrival of packet, 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. These buffer levels are important to understand, how different services remain in the RNC buffer, given the transmission rates and switching conditions according to our model. Furthermore, some of the services may cause the buffer levels to increment quickly due to large burst sizes, whereas other services may show low levels due to smaller burst sizes.

Moreover, there may be empty times, during which there are no data in the buﬀer and it is measured during DCH transmission only, since the resource allocated during dedicated channel transmission is relatively high and needs optimisation also. On the other hand, FACH transmission is shared and it has low bit-rates and less resource allocation, since many users share the channel simultaneously.

In addition, 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.

This packet buﬀering delay is an important factor because, the buﬀer 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. This has been used for validation of the model and the results will be explained in Section 5.4.

In addition, the user throughput is also calculated for diﬀerent services,

42 during each DCH session for diﬀerent services, to understand the achieved throughput in the DCH transmissions. This is estimated from the ratio between number of bits transmitted and total time period on DCH.

Additionally, the DCH Utilization has been calculated for every DCH session according to the channel bit-rate assumptions, which are presented in Section 6.2.2.

Further explanation on estimation of these parameters in detail with the help of formulae are given in the following sections with the results obtained, when the buﬀer model is supplied with the real network traces.

5.2 Design Assumptions

For ease of analysis and simplicity, a leaky-bucket buﬀer model having a random rate of arrival of packets and deterministic rate of departure of packets is chosen. However, the play-out rates set by the buﬀer depend on UE states as mentioned in Section 5.1.

Packet Arrival

No Empty Move Packet to RNC RNC buffer Buffer

Yes

No Previous Packets Serviced

Wait until previous packets are serviced Yes

Send Packet

Figure 5.2: Flowchart of RNC buﬀer model in relation with queueing

As shown in Figure 5.2, the RNC buﬀer model can be understood as a First-In-First-Out (FIFO) queuing model with the play-out bit-rate

43 depending on the channel bit-rate at the moment of packet arrival. The time at which the packet is fully serviced is calculated as follows:

p p−1 p td = td + ts (5.1) where, p td - Epoch time stamp of the complete packet departure from the buﬀer, in seconds

p−1 td - Epoch time stamp when the previous packet is serviced (if the packet arrives at empty buﬀer, this time is the packet arrival time), in seconds

p ts - Time taken to service the packet fully, in seconds

The time taken to service a packet is calculated from the following formula, Sp tp = (5.2) s BCH where, Sp - Packet Size, in bits

BCH - Transmission bit-rate depending on the transport channel allocated, in bps.

5.3 Transport Channels and State Transitions

As mentioned in the Section 2.1.3, the transport channels such as DCH and FACH are allocated by the RNC, to attain data transmission according to the data in buﬀer. As can be seen from the Figure 5.3, there are two modes of operations according to the activity of data transmission through diﬀerent transport channels and the channel switching is dependent on parameters such as

• Up-switch Threshold

• Down-switch Timer

• Inactivity Timer

44 Mode:Active

CELL_DCH Down switch timer: Packet Buffering Delay > CELL_FACH 2 Mbps no traffic for 3 Maximum Acceptable seconds Delay ( Up-switch 1 Mbps 16 Kbps Streaming & Interactive only) 512 Kbps Up switch threshold: buffer level > 512 bytes Inactivity timer: No traffic for 300 seconds (Session Termination) Up-switch trigger Mode:Idle buffer level > 1 byte

Figure 5.3: Switching between transport channels and UE State Transitions

If there is no data transmission between the UE and CN for a while i.e. the UE is Idle and there is a packet arrival, the transport channel primarily allocated will be DCH, which makes the UE to enter into CELL DCH state.

During this state, the UE is capable of sending large chunks of data with good QoS and bit-rates, since the user is allocated with a dedicated channel at 512 kbps, which is an assumption on the initial bit-rate for our study. Furthermore, it can reach higher values upto 2 Mbps according to the packet buﬀering delay in case of streaming and interactive services.

It should also be noted that, if the data rates are increased, the power and cost incurred will also be increased accordingly. In 3G, 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, 400 mW in case of CELL FACH and 800 mW in case of CELL DCH state. In other words, CELL FACH state consumes only 50% of power than the CELL DCH state [18].

However, as FACH is a shared channel among several users, the bit-rate cannot be guaranteed and it is assumed to have 16 kbps bit-rate, 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 buﬀer level is increased to higher values than 512 bytes of data.

From the understanding gained from the 3GPP standards Release 9 [27], the practical bit-rate assumptions through DCH and FACH has been

45 made.

Moreover the down-switching to FACH from DCH is caused due to expiry of the down-switching timer, which has 3 seconds as default timer value in this study. The down-switching from DCH to FACH is considered to happen after 3 seconds, 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.e. frequent switching.

The UE is considered to be Idle mode, if there are no packet arrivals for 300 seconds, which is considered as the termination of the session.

5.4 Eﬀects of Buﬀering Delays and QoS

Even though there are default link bit-rates, 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.

Moreover, this is evaluated in order to demonstrate the validity of the model, by comparing the packet delays due to RAN buffering and RAN transmission with the end-to-end QoS delay for different services. The following Table 5.1 gives the acceptable overall end-to-end packet delay range for different services according to ITU-T and 3GPP QoS Standards.

Table 5.1: QoS End-to-End Packet Delay Range for Different Services [13] Resource Type Traffic Acceptable Services Class Delay GBR Streaming 1 s Non-Conversational Video, Audio, Media (Buffered Streaming) Non-GBR Interactive 400 ms Interactive Gaming, TCP based (instant-messaging, social-networking, web- browsing, maps) Non-GBR Background Best Effort TCP-based (email,file sharing, p2p, file- download, software- update, advertisement)

The buﬀer model includes the aforementioned QoS requirements, by incrementing the transmission rates up to 2 Mbps if packet buﬀering delay is more than the QoS delay and this avoids additional delay.

46 The packet delay due to buﬀering is calculated using the following formula,

p p p B = (td − ta) × 1000 (5.3) where, Bp - Packet buﬀering delay, in milliseconds

p td - Epoch time stamp when the packet is fully serviced (both waiting and service), in seconds

p ta - Epoch time stamp when the packet arrives at the buﬀer, in seconds

With the help of the above formula, the average packet delay due to buffering for the modelled RNC buffer is calculated for different services. As shown in the Figure 5.4, almost all the services show packet delays due to buffering within the acceptable QoS packet delay budget as shown in Table 5.1, leading to conformance of the valid buffer model having default 512 Kbps DCH, 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, which cannot be varied.

Average Packet Delay due to Buffering advertisement audio-playback email file-download-.*-Android-Market-Android-Market file-download-.*-iTunes-iTunes file-sharing gaming instant-messaging maps Services 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.4: Average Buﬀering Delays for diﬀerent services

It is also evident from Figure 5.4 that, all the services are found to have low delays due to buﬀering at RNC around 20 ms.

In addition, the services such as ﬁle-download and software-update

47 showing larger burst sizes in Figure 4.8, are found to have longer delays, which is also considered to ensure the validity of the buﬀer model.

5.5 Attained Buﬀer Levels

In addition to the above analysis, it is important to analyse the buﬀer levels achieved, due to varying play-out rates. Furthermore, the buﬀer levels can be higher for services which need high bandwidth, and also due to larger bursts and relatively low play-out rates.

Furthermore, these variations have an impact on buffer levels for different services due to this type of link allocation procedure and the following Figure 5.5 shows the variation in buffer levels during downlink data transmission for different services.

48 Figure 5.5: Buffer filling levels for different services

From the Figure 5.5, it is evident that around 80% of the buﬀer levels for GBR streaming services except media-playback is between 1 kB and 1 MB.

Similarly in case of non-GBR interactive services such as web-browsing and maps around 90% of the buﬀer levels are in the same range as that of streaming services.

Conversely, non-GBR interactive services such as gaming,

49 instant-messaging and social-networking are observed to achieve buffer levels of around 52 B in around 50% of the values, which implies that mostly the packets arrive at an empty buffer as single 52 B packet. Similar characteristics are found in case of non-GBR background services such as advertisement, email and file-sharing showing around 70% of the buffer levels less than 1448 B.

On the other hand, non-GBR background services such as ﬁle-download and software-update show around 80% of the buﬀer levels between 1 MB and 10 MB.

Furthermore, the following Figure 5.6 shows the average buffer levels in Mega-Bytes for different services, giving the mean value and its confidence intervals.

As can be seen from Figure 4.8, the services such as ﬁle-download and software-update showing larger burst sizes, are found to have higher buﬀer levels as shown in Figure 5.5 than other services. This is considered as validation of the results obtained from the model.

Mean Buffer Level Achieved advertisement audio-playback email file-download-.*-Android-Market-Android-Market file-download-.*-iTunes-iTunes file-sharing gaming instant-messaging maps Services 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.6: Average buﬀer levels for diﬀerent services

5.6 Summary

As can be understood from the above modelling and analysis of the RNC buﬀer:

50 • 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. However, in case of delay-sensitive services, the rates can be incremented upto 2 Mbps, when transmission is through DCH. This is performed by tracking the buffer levels and transmission time taken to service the packets arrived at the buffer for different services.

• From the observations made after supplying the obtained traffic data as input to the modelled buffer, 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], indicating the validity of the buffer model for the study involved.

• The buffer levels achieved by different services are comparatively high in case of non-GBR background services such as email, file-download and software-update in increasing order.

• The buffer levels are estimated to understand the validity of the results with the help of input data. It is observed that services having large bursts as shown in Figure 4.8 are found to have higher buffer levels as shown in Figure 5.5 than other services and this is considered to be a validation check for the buffer model and the results obtained.

51 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, the assumptions and approximations made in modelling the RNC buffer are covered. Furthermore on the analysis made, there are some important results, which address the research questions framed in the Chapter 3.

The analysis is performed step by step for each service by focussing on certain important parameters of the buﬀer model with channel bit-rate assumptions.

This chapter is organised as follows: Section 6.1 explains the obtained empty buffer durations during DCH transmission for different services, Section 6.2 comparatively illustrates the performance of different services in terms of user throughput and dedicated channel utilisation for different services, Section 6.3 discusses the overall results for different services with the help of obtained parameters from the buffer model and Section 6.4 summarises the validity of the results obtained.

6.1 Idle buﬀer Characteristics during Dedicated Channel Transmission

Due to irregular arrivals of packets for diﬀerent services, there occurs intermittent time intervals during which there are no data transmission to the user from the radio network. This in turn causes down-switching from DCH to FACH, which takes place only when the down-switch timer expires.

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, after which

52 down-switching happens. This value is an assumption, which is found to be valid in most of the networks.

Due to varying characteristics of data services in 3G networks, for some data services, during DCH transmission, there may be empty times in buﬀer, making the resources occupied by the user but no data transmission during those periods.

The second research question is addressed in this section, 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.

6.1.1 Empty Buffer Duration [De] In this section, the variations in the empty buffer times for different services are analysed, during which no data is present in the buffer during DCH transmission, but the radio resources allocated for the user are still occupied. This value is calculated using,

De = tds − tbe (6.1) where, De - Empty Buﬀer Duration in seconds tds - Epoch time when down-switching occurs from DCH to FACH during each DCH session tbe - Epoch time when buﬀer becomes empty during DCH session

As shown in the following Figure 6.1, most of the services have idle buﬀer behaviour for roughly 200 milliseconds duration, which can be maximum up to 3 seconds as can be seen in some cases, after which there is a channel down switching to shared channel FACH.

53 Figure 6.1: Idle Durations of Buﬀer during DCH transmission

Furthermore, almost all the services have short empty times less than 500 ms in most of the cases. This might be helpful in avoiding frequent down-switching, but if there are a lot of short empty times, there are possibilities that the channel may not be used to its full potential.

The following Figure 6.2 shows the average value on empty buﬀer times, from which it is clear that almost all the services have a mean empty buﬀer duration of about 500 milliseconds, a bit higher in case of gaming, software-update and advertisement reaching roughly around 700

54 milliseconds.

Mean Idle Buffer Time advertisement audio-playback email file-download-.*-Android-Market-Android-Market file-download-.*-iTunes-iTunes file-sharing gaming instant-messaging maps Services media-playback social-networking software-update video-playback web-browsing YouTube

0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 Average Empty Buffer Time [seconds]

Figure 6.2: Average Idle Durations of Buﬀer during DCH transmission

It should be noted that, the channel down-switching happens only when the down-switching timer expires. So, most of the services do not show large number of empty times showing maximum value i.e., 3 seconds. However, in the DCH, there occurs empty duration of around 500 milliseconds, which is observed in most of the services.

6.1.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,

t De Pe = × 100 (6.2) DDCH where, Pe - Empty Buﬀer Percentage per DCH session

t De - Total empty buﬀer duration during the DCH session

DDCH - Total time duration of the DCH session

55 The following Figure 6.3, gives the percentage of these values for each service, which shows that, 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, because of numerous empty times of buffer during a DCH session. However, around 60% and 75% of the empty percentage values are below 75% for video-playback and file-download-Android, respectively.

Figure 6.3: Empty Buﬀer Percentage during DCH sessions

As shown in Figure 6.4, it is evident that the mean empty buﬀer

56 percentage value is around 90% for most of the services, except ﬁle-download-Android, which only shows about 40% of the DCH session with empty RNC buﬀer, followed by video-playback showing 60% empty percentage.

Mean Idle Buffer Duration per DCH Session advertisement audio-playback email file-download-.*-Android-Market-Android-Market file-download-.*-iTunes-iTunes file-sharing gaming instant-messaging maps Services 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.4: Average Empty Buﬀer Percentage during DCH sessions

It is interesting to observe the empty buffer duration percentage in each DCH session, because due to intermittent short gaps between arrivals, there occurs more short empty times in the buffer causing high empty buffer percentage during DCH session for most of the services.

6.2 Radio Resource Utilisation in terms of Dedicated Channel Performance

From the above analyses related to RNC buﬀer behaviour, it is evident that most of the services have short gaps between arrivals less than 500 ms causing empty buﬀer during most of the DCH sessions.

It should be noted that, it incurs more power, RNC cost and resources, when the DCH channels are occupied and the users are inactive during their DCH session.

This section addresses the third research question, which involves understanding the user throughput and transport channel utilisation during DCH transmission according to our buﬀer model assumptions and

57 obtained traﬃc data.

6.2.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 eﬀort services. The Ta values are found using the equation,

BDCH Ta = (6.3) DDCH where, Ta - Achieved User Throughput during the DCH session

BDCH - No. of bits transmitted per DCH session

DDCH - Total duration of the DCH session

It should be noted that, Figure 6.5 has throughput values in Mbps on its x-axis, which can have maximum value of 2 Mbps on DCH.

As can be seen from Figure 6.5, GBR streaming services other than video-playback have throughput values around 128 Kbps, whereas video-playback is found to have around 60% of the throughput between 128 kbps and 1 Mbps.

On the other hand, non-GBR interactive services show throughput values less than 64 Kbps during most of the DCH sessions, which is similar to almost all the non-GBR background services. However, ﬁle-download-Android show higher throughput values than any other services, with roughly around 60% of the DCH sessions with maximum 512 kbps throughput.

It should also be noted that, the maximum channel bit-rate is 512 kbps in case of non-GBR background services, whereas it can be switched up to 1 Mbps or 2 Mbps, when the transmission time for a packet to be fully serviced is more than the acceptable QoS delay for diﬀerent services as shown in Table 5.1. This is evident from the Figure 6.5.

58 Figure 6.5: Achieved Throughput on DCH transmission

The following Figure 6.6 shows that most of the services other than GBR streaming and ﬁle-download-Android services, have an average user throughput less than 128 kbps.

59 Mean Achieved Throughput on DCH advertisement audio-playback email file-download-.*-Android-Market-Android-Market file-download-.*-iTunes-iTunes file-sharing gaming instant-messaging maps Services media-playback social-networking software-update video-playback web-browsing YouTube

0 0.1 0.2 0.3 0.4 0.5 0.6 Average User Throughput on DCH [Mbps]

Figure 6.6: Average Achieved Throughput on DCH transmission

6.2.2 Dedicated Channel Utilisation [UDCH] In addition to the analysis related to the user throughput in the previous Section 6.2.1, there is a need to evaluate the channel utilisation by ﬁnding the ratio between the achieved and achievable throughput of the dedicated channel, which is also termed as DCH utilisation. It can be found using,

Ta UDCH = × 100 (6.4) TL where, UDCH - Utilisation of the dedicated channel per DCH session

Ta - Achieved user throughput per DCH session

TL - Link throughput achievable or maximum on DCH link during the DCH session

From the following Figure 6.7, 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.

Similar characteristics is observed in almost all the non-GBR background services which shows around 10% DCH utilisation, except

60 ﬁle-download Android, which shows approximately around 90% DCH utilisation in most of the cases.

Figure 6.7: Utilisation of Dedicated Channel for diﬀerent services

However, in a few cases there is 100% utilisation also observed in some of the services. But comparatively the proportion is low and according to the assumed channel bit-rate and switching conditions, poor utilisation of the channel is observed in most of the cases.

61 Mean Utilisation of DCH advertisement audio-playback email file-download-.*-Android-Market-Android-Market file-download-.*-iTunes-iTunes file-sharing gaming instant-messaging maps Services media-playback social-networking software-update video-playback web-browsing YouTube

0 20 40 60 80 100 Average DCH Utilisation [%]

Figure 6.8: Average Utilisation of Dedicated Channel for diﬀerent services

This is a matter of concern, when it comes to resource optimisation in the radio networks in terms of DCH channel allocation. Furthermore, the average utilisation levels of DCH for diﬀerent services from the Figure 6.8 also show that most of the services, except ﬁle-download-Android and video-playback show average DCH utilisation less than 20%.

6.3 Discussion of the Results

From the statistical analysis with the obtained real network traces and their behaviour from the buﬀer model, the following results are implied: • For almost all the services, the burst size and duration depend on the type and content abundance of the particular service. Longer durations of bursts are seen in advertisement and software-update services and larger bursts are found in most of the GBR streaming, ﬁle-download and software-update services.

• Short empty buﬀer times are observed during DCH sessions for diﬀerent services and most of their values are below 500 milliseconds, but the percentage of total empty time duration to a DCH session duration is around 80% for most of the services.

• The user throughput values are found to have signiﬁcantly 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 services, which is suboptimal when it comes to eﬀective radio resource utilisation.

6.4 Validity of the Results

As a general idea, a methodology to study the RNC buﬀer characteristics and DCH channel utilisation has been proposed, which persuaded us to conclude that there exists undesirable resource utilisation with respect to transport channel allocation and overall performance of diﬀerent services.

• 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. – In order to avoid congestion at the RAN, the mobile operators have to consider a fair network policy control framework. This differs from one operator to another, since the priorities might vary for the services among different operators. In addition, 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. – However, 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 addition, the buffer model using this assumption, analyses every single user and his/her service access and no multiple user scenarios are considered simultaneously, since this study is aimed at providing characteristics of different services at the radio network with respect to single user traffic flow. – The real transmission conditions were remodelled for the assumptions made for the study and this might be different in real network scenario. However, the study is mainly aimed at analysing the traffic data obtained and understanding the buffer filling for that particular kind of traffic profiles, with channel transmission assumptions.

• Channel Switching Assumptions Furthermore, channel switching considerations in terms of up-switching threshold (in bytes) and down-switching timer (in

63 seconds) are assumptions based on understanding related to optimal channel switching and processing overhead under the sensitivity analysis. The results might vary, if these values are varied.

• Dataset Variations The obtained real network traces are large and it is captured from a single 3G network. Even if the dataset is varied, similarities in the traffic characteristics for different services analysed would be observed in most of the cases, since numerous sessions of traffic are considered for each service from the obtained traffic.

64 Chapter 7

Conclusion and Future Work

In this thesis work, 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 performance of different services in the radio network is studied.

7.1 Conclusion

From the collective analysis of diﬀerent service traﬃc, it is important to achieve necessary understandings from the results obtained, so as to address the research questions. This section compares the research questions with the obtained outcomes as follows:

• RQ 1: What are the variations in terms of inter-arrivals, durations and sizes of bursts of IP packets for diﬀerent services?

– Most of the bursts of packets have mean inter-arrival time of less than 2 seconds, except ﬁle-sharing and instant-messaging, which have mean inter-arrival time of 5 and 10 seconds respectively. – The mean duration of bursts is found to vary around 200 milliseconds for most of the services, other than advertisement and software-update services, which have longer burst durations. – Only some of the services such as GBR streaming, ﬁle-download and software-update have large burst sizes of around 50 to 200 kB, 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.

• RQ 2: How long does the RNC buffer show empty buffer levels during DCH transmission for different services?

65 – From the analysis made on buffer filling levels, the mean duration of empty buffer during DCH transmission is found to vary around 400 milliseconds for most of the services, except the GBR streaming services, that show shorter mean empty times. – In case of almost all the services, the highest percentage of empty buffer levels during DCH session is found to be around 80%, during which there is no data reception or transmission at the RAN, but the resources are still allocated to the users, incurring undesirable cost and power for the RNC. – However, file-download-Android and video-playback are found to show better buffer performance than other services, by achieving smaller empty buffer percentages less than 40%.

• RQ 3: How do diﬀerent 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. – In addition, the average achieved user throughput show generally low values for most of the services, which is not optimal. – Consecutively, utilisation of dedicated channel is found to be around 30% for most of the services, raising a question on effective switching and state considerations in radio access network for data services.

Furthermore, 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, with the perspective of radio resource optimisation.

In addition, the transport channel requirements for diﬀerent services may vary and a better solution would be to track the services and provide the channel allocation to eliminate unwanted utilisation of channels, which will be helpful in allocating unused channels to other users. However, this might additionally increase the overhead and incur more delays due to channel switching.

7.2 Future Work

The potential future work of this research can be related to understanding further, the cost and resource utilisation in terms of channel switching between DCH and FACH, taking diﬀerent services into

66 consideration. In addition, there is a need to deeply understand the buﬀer behaviour, with the inclusion of real network cell considerations like heavily loaded, medium loaded and lowly loaded network scenario, containing multiple users scenario and test cases and its impacts on the resource utilisation.

In order to improve the buffer model further, 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. However, this may further complicate the model with varying bit-rates for each service according to their data volume understood from the traffic data obtained.

Furthermore, the switching conditions, which have been assumed with a speciﬁc 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. However, the switching may have to be compromised with the cost and delays occurred if there are frequent switching.

From the results obtained, 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.

Moreover, 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.

In fact, 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.

67 Bibliography

[1] 3GPP TS 23.107, ”Universal Mobile Telecommunications System(UMTS); Quality of Service (QoS) concept and architecture.”

[2] 3GPP TS 23.401, ”General Packet Radio Service (GPRS) Enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) Access.”

[3] 3GPP TS 34.108, ”3rd Generation Partnership Project; Technical Speciﬁcation Group RAN; Delay Budget within the Access Stratum.”

[4] 3GPP TS 36.300, ”Evolved Universal Terrestrial Radio Access (E- UTRA) and Evolved Universal Terrestrial Radio Access Network (E- UTRAN):Overall Description.”

[5] 3GPP TS 36.331, ”Evolved Universal Terrestrial Radio Access Network (E-UTRAN); Radio Resource Control (RRC);Protocol Speciﬁcation.”

[6] 3GPP TS 36.413, ”Evolved Universal Terrestrial Radio Access Network (E-UTRAN); S1 Application Protocol.”

[7] E. Dahlman, S. Parkvall, J. Sk¨oldand P. Beming, 3G Evolution: HSPA Evolution and LTE for Mobile Broadband, 2nd Edition, Academic Press, 2008.

[8] W. L. Tan, F. Lam and W. C. Lau, ”An Empirical Study on the Capacity and Performance of 3G Networks,” IEEE Transactions on Mobile Computing, vol. 7, no. 6, pp. 737-750, June 2008.

[9] Z. Zhu, G. Cao, R. Keralapura and A. Nucci, ”Characterizing Data Services in a 3G Network: Usage, Mobility and Access Issues”, IEEE International Conference on Communications, pp. 1-6, June 2011.

[10] F. Qian, Z. Wang, A. Gerber, Z. Morley Mao, S. Sen and O. Spatscheck, ”Characterizing Radio Resource Allocation for 3G Networks”, International Mobile Conference, Nov 2010.

[11] R. Mayank Kumar, ”Developing a QoS Aware Framework for LTE, QoS Control and QoS Aware Scheduler”, Aricent White Paper, July 2012.

68 [12] A. Sang, X. Wang and M. Madihian, ”Diﬀerentiated TCP User Perception over Downlink Packet Data Cellular Systems,” IEEE Transactions on Mobile Computing, vol. 6, no. 3, pp. 252-263, March 2007.

[13] ITU-T Y.1541, ”Network performance objectives for IP-based services”.

[14] S. Yang and Y. Lin, ”Modeling UMTS Discontinuous Reception Mechanism”, IEEE Transactions on Wireless Communications, vol. 4, no. 1, January 2005.

[15] J. J. Alcaraz, F. Cerdan and J. Garcia-Haro, ”Optimizing TCP and RLC interaction in the UMTS radio access network,” IEEE Network, vol. 20, no. 2, pp. 56-64, March-April 2006.

[16] Y. Ohta, K. Kawahara, T. Ikenaga and Y. Oie, ”Performance evaluation of channel switching scheme for packet data transmission in Radio Network Controller”, IEICE Transactions on Communications, vol. E87B, No. 5, pp. 1141-1150, May 2004.

[17] A. Alexiou, C. Bouras and V. Igglesis, ”Performance Evaluation of TCP over UMTS Transport Channels”, 2008.

[18] L. Wang, A. Ukhanova and E. Belyaev, ”Power consumption analysis of constant bit rate data transmission over 3G mobile wireless networks”, 11th International Conference on ITS Telecommunications, pp. 217 -223, August 2011.

[19] R. Bestak, P. Godlewski and P. Martins, ”RLC buﬀer occupancy when using a TCP connection over UMTS”, The 13th IEEE International Symposium on Personal, Indoor and Mobile Radio Communications, vol. 3, pp. 1161-1165, September 2002.

[20] J. J. Alcaraz, G. Pedreo, F. Cerdan and J. Garcia-Haro, ”Simulation of 3G DCHs supporting TCP traﬃc: design, experiments and insights on parameter tuning,” Proceedings of the 1st international conference on Simulation tools and techniques for communications, networks and systems, Article 75, 8 pages, March 2008.

[21] P. H. J. Perala, A. Barbuzzi, G. Boggia and K. Pentikousis, ”Theory and Practice of RRC State Transitions in UMTS Networks,” IEEE GLOBECOM Workshops, pp. 1-6, Nov-Dec 2009.

[22] F. Qian, Z. Wang, A. Gerber, Z. M. Mao, S. Sen and O. Spatscheck, ”TOP: Tail Optimization Protocol For Cellular Radio Resource Allocation,” 18th IEEE International Conference on Network Protocols (ICNP), pp. 285-294, Oct. 2010.

69 [23] W. Featherstone, J. P. Wallington and F. Schneider, ”TCP Performance Over UMTS Dedicated Channels with Finite RLC Buﬀer Size”, 6th IEE International Conference on 3G and Beyond, pp. 1-5, November 2005.

[24] H. Van Peteghem and L. Schumacher, ”UMTS Non Real-Time Sessions Channel Switching Emulation”, IEEE 65th Vehicular Technology Conference, pp. 1061-1065, April 2007.

[25] A. Larmo, ”Usability of Instant Messaging over WCDMA”, M. S. Thesis, Helsinki University of Technology, Finland, 2005.

[26] J. J. Alcaraz and F. Cerdan, ”Using buﬀer management in 3G radio bearers to enhance end-to-end TCP performance,” 20th International Conference on Advanced Information Networking and Applications, vol. 2, pp. 5, April 2006.

[27] H. Holma and A. Toskala, WCDMA for UMTS - HSPA evolution and LTE, 4th Edition, John Wiley and Sons, 2002.

70 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