Master of Science ThesisStockholm, Sweden 2013

TRITA-ICT-EX-2013:189

A N S E L Z A N D E G R A N A N T O N Y J E Y A S E H A R

Multi-Operator Multi-RadioPerformance Monitoring and Context-

Aware Access Provision Test-Bed

K T H I n f o r m a t i o n a n d

C o m m u n i c a t i o n T e c h n o l o g y

2

Multi-Operator Multi-Radio Performance Monitoring and Context-Aware Access Provision Test-Bed

Student

Ansel Zandegran Antony Jeyasehar

Supervisor

Pietro Lungaro

Examiner

Zary Segall

School of Information and Communication Technology,

KTH-Royal Institute of Technology

Stockholm, Sweden.

2012

3

Abstract

In recent years the growth of smartphone users has increased rapidly and smartphone are used to access various content types through mobile Internet. The mobile behaviour of the users and its corresponding traffic load, in terms of number of users, duration of data sessions and type of content may vary from place to place and over time. For example, in industrial areas the network usage may significantly more pronounced during the office hours. This makes the network not so congested during the other times. In order to improve the utilization of the infrastructure, content providers and/or mobile operators can push content to the users’ terminal exploiting times and locations where the network is not congested. This in turn can also provide users with improved Quality of Experience (QOE), since a significant portion of the content of interest can be instantaneously consumed.

In this thesis, the user behaviour, the traffic behaviour and available data rates are characterized in specific testing locations. For this purpose a system, which is capable of monitoring the available data rate throughout any specified time, was developed. The developed system uses TCP streams to estimate the available data rate, while file download is used to create TCP streams. The system also can serve user traffic through a context-aware WiFi tethering solution which acts according to different pre-configured policies. Among these, users can route their traffic through various providers based on achievable performances (overall best and to achieve specific target levels), but also potentially following price indications.

The results are presented and their validity outlined in the Thesis. In particular, the possibility and need of measuring the average data-rate from multiple operators is discussed in details, with highlights on current performances achieved from multiple operators. Data rate prediction methods, based on historic performances are presented and achieved prediction error rates presented. For some of the tethering scenarios, a set of simulations have been performed to understand the possibility of supporting content pre-fetching through multiple providers and to analyse and define some of the key system design parameters.

4

ACKNOWLEDGMENT

This Thesis work is completed as a part of the curriculum towards the completion of the master’s program in Network Services and Systems at Kunliga Tekniska Högskolan (KTH), Sweden. This is what made me grow as a professional and a person. This work is done at COS Mobile Service Lab under the guidance and supervision of Dr. Pietro Lungaro from March 2012 to June 2012.

I would like to take this opportunity to convey my gratitude to Dr. Pietro Lungaro for his consistent guidance and support throughout my work. His support was beyond the boundaries of a supervisor. His supervision helped me to amend and improvise the research and thereby making it a much better one.

I would like to express my heartfelt gratitude to Professor Zary Segall for giving the opportunity to pursue this challenge, which I consider as a cornerstone of my career. His valuable ideas helped to shape up my thesis work and myself professionally. In spite of his busy schedule, he managed to support and keeps track of the work.

I would like to thank Pavan Kumar Kamaraju and Kai Yu of mobile Services Lab, for the support they rendered. Last but not the least; I would like to extend my warm thanks to my friends, colleagues and parents, without whom it wouldn’t have been possible to accomplish this.

5

Table of Contents

Glossary ................................................................................................................................................... 7

1 Introduction ......................................................................................................................................... 8

1.1 Problem Description ..................................................................................................................... 8

1.2 Goal ............................................................................................................................................... 8

1.3 Contributions ................................................................................................................................ 9

1.4 Outline........................................................................................................................................... 9

2 Background .......................................................................................................................................... 9

2.1 Overview of 3G networks ........................................................................................................... 10

2.1.1 3GPP UMTS Specifications and Management ..................................................................... 10

2.1.2 UMTS Capabilities ................................................................................................................ 11

2.1.3 UMTS frequencies ................................................................................................................ 12

2.1.4 UMTS power control ............................................................................................................ 12

2.2 LTE Systems Overview................................................................................................................. 13

2.2.1 Overview of the LTE Standard .............................................................................................. 13

2.2.1 Targets for LTE ..................................................................................................................... 13

2.2.3 Overall Network Architecture .............................................................................................. 14

2.2.4 LTE Physical layer ................................................................................................................. 15

2.3 Introduction to LTE Advanced ..................................................................................................... 16

2.3.1 LTE Advanced key features .................................................................................................. 17

2.3.2 LTE Advanced technologies.................................................................................................. 17

3 Related Work ..................................................................................................................................... 17

3.1 Periodic Streams ......................................................................................................................... 17

3.2 TCP in HSDPA .............................................................................................................................. 18

3.3 QOS for Mobile Network ............................................................................................................ 18

4 System Design .................................................................................................................................... 18

4.1 System Requirements ................................................................................................................. 18

4.2 Methodology ............................................................................................................................... 19

4.3 Design Choices ............................................................................................................................ 19

4.4 Design Issues ............................................................................................................................... 20

4.5 System Implementation .............................................................................................................. 21

4.5.1 Measurement System .......................................................................................................... 21

4.5.2 Collection Server .................................................................................................................. 25

6

4.5.3 Trigger Server ....................................................................................................................... 25

4.5.4 Trigger Client ........................................................................................................................ 25

4.5.5 Cell ID and Signal Strength Monitoring System ................................................................... 25

4.5.6 Web Server ........................................................................................................................... 26

4.5.7 Notification System .............................................................................................................. 26

5 Results and Analysis ........................................................................................................................... 26

5.1 Data selection For Experiments .................................................................................................. 26

5.2 Relevance in the time domain .................................................................................................... 28

5.3 Study of Multiple operators ........................................................................................................ 30

5.3.1 Study of 3G Traffic................................................................................................................ 30

5.3.2 Study of LTE Traffic .............................................................................................................. 31

5.4 Study of 3G and LTE network ...................................................................................................... 32

5.5 Data Rate Prediction ................................................................................................................... 33

5.6 Serving User Traffic ..................................................................................................................... 34

5.6.1 Best Cost .............................................................................................................................. 34

5.6.2 Best Performance ................................................................................................................. 34

5.6.3 Target per User .................................................................................................................... 35

5.8 Performance analysis for Pre-fetching over multiple operators ................................................ 36

5.8.1 Experimentation: ................................................................................................................. 36

5.8.2 Data Overheads: .................................................................................................................. 36

5.8.3 Data Rates: ........................................................................................................................... 37

6 Conclusion .......................................................................................................................................... 38

6.1 Future Work ................................................................................................................................ 39

References ............................................................................................................................................ 40

Appendix 1: ........................................................................................................................................... 42

7

Glossary

GSM - Global System for Mobile-Communications, originally Groupe Spécial Mobile

GPRS – General Packet Radio Service

LTE – Long Term Evolution

3G – 3rd Generation

SIM – Subscriber Identification Module

UMTS - Universal Mobile Telecommunications System

CDMA – Code Division Multiple Access

WCDMA – Wideband Code division Multiple Access

HSDPA - High Speed Downlink Packet Access

HSUPA - High Speed Uplink Packet Access

FTP – File Transfer Protocol

UE – User Equipment

BSS – Base Station Sub-System

RNS – Radio Network Subsystem

RNC – Radio Network Controller

8

1 Introduction

The mankind is using non-renewable resources more than renewable resources. Hence the non-renewable resources are in the threat of extinction in the near future. It’s our duty to use the resources at its best efficiency and save the mankind. The infra-structure for the cellular networks is well established throughout the world and each of which consumes energy. This energy is not efficiently consumed. The users do not use the network, i.e. GSM or 3G or LTE during night as they do in day. But there is no difference in the energy required to keep the infrastructure up all the time. The networks cannot be shut down as it has become one of the essential parts of everyone’s life. Someone will be using the network at any- point of the time, it’s just that it’s is not at its peak performance all the time. Throughout this report 3G refers to 3G with HSDPA (High-Speed Downlink Packet Access) network which is discussed along with other technologies in the Background Chapter.

1.1 Problem Description

To overcome the problem of inefficient use of the cellular networks, data can be pushed to the user’s device when there is less traffic in the network. But the content provider cannot know when the network is less used. If the content is pushed at the wrong time (When the network is congested), it will further worsen the situation as it may add up to the congestion. It is also accountable, where the device is, because users in different locations may experience different quality of experience due to the number of active users and other parameters specific to that place. The place here refers to the area in which there are users connected to the same base station (have same cell ID). Users connected to the same cell share the same network behaviour. The actual data rate experienced and the quality of experience may differ depending on the distance of the user from the Base Station. But it can be found, whether the network is good or not or the expected average data rate available per user. It also depends on the different service providers. It is inefficient to push the content to the users, if the network status of the place (network status of the users connected to a particular Base Station or users sharing the same cell ID) is not known to the content provider.

Another problem is that when the users are subscribed to one operator, they get the good and bad data rates of that operator. Instead, good properties of two or more operators can be used to serve the user traffic, if there exists an access to multiple operators. For this purpose, a system is necessary to intelligently choose between various operators.

1.2 Goal

The Goal is to build a system or approach that allows knowing the network status in terms of available bandwidth of each user in a specific cell in different parts of the day. This information can be then used by the content provider to push the data that the user may need later. It is interesting to study and compare the network degradation in 3G and in LTE networks during the peak performance hours and less used hours for different providers. This system also enables us to study the user traffic behaviour round the clock and predict the user traffic (in terms of available bandwidth) for the future. All this study is done under the assumption that the when there are more active users connected to the base station the traffic available to our system is less and vice versa. The measurement is done periodically. It is also interesting to study how long the measurement is valid once it is done.

The idea is to install such systems in all the cells and study the bandwidth in each of the cells. The measurement is done periodically and our system is idle for the time in between. By this way our system itself is not efficient. There is a possibility of using the networks in those idle times. By allowing the users around the system to connect to the system through Wi-Fi (802.11) and then

9

routing the traffic through the best provider at that time can be done. This is beneficial for the users when their home service provider is not providing a good quality of experience at that time. This also creates a necessity to install this system close to a place where there is more number of users most of the time.

1.3 Contributions

A system and a method to study, measure and monitor the user traffic in any network in an

area is designed and analysed.

With the help of the system, one can

Measure the bandwidth available per user at any point of time.

Make measurements either in 3G or LTE networks or in a combined setup.

Get input to make predictions on any point of time in a specific area.

Make a Comparative study on bandwidth available on various days.

Make a Comparative study on bandwidth available on various locations.

Send their traffic through it based on various policies pre-configured.

It also serves the ultimate purpose of building it, which is that it tells the content provider

when to push the content to the user’s terminal in a specific location.

1.4 Outline

In the section 2, the background of technologies which is associated with this system is explored in detail. This gives a clear picture of the evolution of the technologies and where we are of late. In section 3, the related work along with how we came to this idea and what made us to design the system are outlined. In chapter 4, the system design is detailed. This is the place where the difficulties in building the system, the performance of the system, the logical decisions made in the system design, the flow of the system and the components of the system are clearly discussed. In chapter 5, results obtained from the system are analysed. This is the place where the capabilities of the system are briefed. In chapter 6, the conclusion is made and perspectives for future works are outlined.

2 Background

The 2G data network started in the commercial level in the early 90’s. Then the cellular data network started growing in a rapid phase. As of September 2002, there were 460 GSM networks throughout the world and there were seven hundred and forty seven and a half million subscribers in these networks.

ETSI had started the standardization works for the next generation mobile telecommunication, when the GSM was commercially announced. This new system was came to know as the UMTS – Universal Mobile Telecommunications System. This was the outcome of ETSI’s technical committee Special Mobile Group (SMG). There were many divisions in SMG, each specializing in a specific area. The ETSI was not the only organization running research programs in this area. There were many programs like Research on Advanced Communication Technologies in Europe (RACE) and Advanced Communication Technologies and Services (ACTS). In 1996 the UMTS Forum was created to define and manage standards needed for 3G

10

2.1 Overview of 3G networks

Figure 2.1: 3G technologies and its evolution. Source: www.gsma.com

3G is a family of technologies (Seen in Figure 2.1) which includes simple 3G, HSPDA and

HSUPA. The radio leg of 3G is based on WCDMA (Wideband Code Division Multiple Access). The third generation has to be able to offer an ample range of services. It is the 1990’s, when the mobile telecommunications underwent a great revolution.

Slowly and constantly the 3G technologies started moving forward with the development of HSDPA and HSUPA, which are capable of supporting more bandwidth. The Properties of the 3G family can be seen in the Table 2.1.

WCDMA (UMTS)

HSPA HSDPA / HSUPA

HSPA+ LTE

LTE ADVANCED (IMT ADVANCED)

Max downlink speed bps

384 k 14 M 28 M 100M 1G

Max uplink speed bps 128 k 5.7 M 11 M 50 M 500 M

Latency round trip time approx

150 ms 100 ms 50ms (max)

~10 ms less than 5 ms

3GPP releases Rel 99/4 Rel 5 / 6 Rel 7 Rel 8 Rel 10

Approx years of initial roll out

2003 / 4

2005 / 6 HSDPA 2007 / 8 HSUPA

2008 / 9 2009 / 10

Access methodology CDMA CDMA CDMA OFDMA / SC-FDMA

OFDMA / SC-FDMA

Table 2.1: Characteristics of different technologies. Source: www.radio-electronics.com

2.1.1 3GPP UMTS Specifications and Management

There was a necessity to develop a very large number of documents and specifications because the UMTS or Wideband CDMA is very complex. 3GPP- Third Generation Partnership Programme is the group responsible for managing this WCDMA or UMTS. The 3GPP is a global

11

organization, which is a joined venture by six groups ARIB, CCSA, ETSI, ATIS, TTA and TTC. The ultimate ail of 3GPP is to develop and deliver a globally applicable Technical specification and technical report for a third generation mobile telecommunications system. The GSM core network and the radio access technologies are the key technologies this third generation telecommunication specification relies on. The radio access technologies that the GSM core network supports are Time Division Duplex (TDD) modes and Universal Terrestrial Radio Access (UTRA) both Frequency Division Duplex (FDD). Even though it is formed to take care and of 3G and the data communication, It is taking care of the standards for the GSM as well. It is also responsible for future developments, of which LTE is the key technology.

2.1.2 UMTS Capabilities

Wideband CDMA - WCDMA is used as the radio transmission standard for UMT. It uses a 5 MHz channel bandwidth. The UMTS can handle more than 100 voice calls with this 5MHz bandwidth, or while transferring data it can reach up to 2Mbps, which is a good data rate. Then there occurred some advancement like HSDPA and HSUPA, using which a bandwidth of up to 14.4 Mbps is made possible. These advancements are later included in the releases.

Many capabilities of GSM have been enhanced for UMTS. Components like SIM have been enhanced into a more powerful component, USIM (Universal SIM). Moreover, there were enhancements made to the network design for GPRS and EDGE technologies. These enhancements are made useful by this technology. The initial cost was kept low and the technology migration was made seamless.

It was necessary for the UMTS to have some specification for Duplexing. Frequency Division Duplex (FDD) and Time Division Duplex (TDD) modes are defined in the specification. The FDD modes are introduced first, which had different uplink and downlink frequencies. In the networks that are being used and rolled out, the frequencies are spaced with 190 MHz Band.

However the TDD mode in which the uplink and downlink are split in time with the base stations and then the mobiles transmitting alternately on the same frequency is specifically suited to a wide range of applications. Obviously there are some places where spectrum is limited and paired bands suitably spaced, which are not available. This also performs well relatively, where small cells are to be used. When short distance is being covered, this baud will be smaller, because a guard time is always required. It is an universal fact that the down traffic is more than the up traffic in the internet. This is advantageous for this kind of system. It is also necessary to allocate more bandwidth to the downlink, which is not possible in paired spectrum. When a TDD system is used, it is possible to allocate more bandwidth for downlink than uplink and there by improve the efficiency. By employing this method an efficient management of picocells can be done. It is often called as TD-CDMA (Time Division CDMA). This UMTS WCDMA provided a far more efficient system when compared to the previous 2G technologies. The table below, Table 2.2 shows the UMTS parameters and their specification.

PARAMETER SPECIFICATION

Data rate 2048 kbps low range 384 kbps urban and outdoor

RF channel bandwidth 5 MHz

Multiple access scheme CDMA

Duplex schemes FDD and also TDD

Table 2.2: UMTS Parameters and Specification

12

2.1.3 UMTS frequencies

Six bands are specified for use for UMTS currently / WCDMA, even though operation on other frequencies is not prohibited. Frequency allocations around 2 GHz are focused for the transmission of UMTS. The bands 1885 - 2025 and 2110 - 2200 MHz were reserved at the World Administrative radio Conference (WARC) in 1992, for implementing International Mobile Telecommunications-2000 (IMT-2000). Easy roaming for UMTS / WCDMA users can be promoted by allocating spectrum on a worldwide basis.

There are reservations within these bands for different purposes, which of those are as follows:

Frequency Ranges Purpose/Modulation Channel Spacing Raster

1920-1980 and 2110-2170 MHz

Frequency Division Duplex (FDD, W-CDMA) Paired uplink and downlink

5 MHz 200 kHz

1900-1920 and 2010-2025 MHz

Time Division Duplex (TDD, TD/CDMA) Unpaired

5 MHz 200 kHz

1980-2010 and 2170-2200 MHz

Satellite uplink and downlink

Table 2.3: Frequency ranges and characteristics specification

UMTS carrier frequencies are identified and allocated by a UTRA Absolute Radio Frequency Channel Number (UARFCN). This is calculated from:

UARFCN = 5 x (frequency in MHz)

Wideband CDMA is the radio transport mechanism used by UMTS. The channel spacing is 5MHz for consumer implementations.

2.1.4 UMTS power control

Like any CDMA system, it is essential that the power levels of all the user equipment are same at the base station. They will not be heard, If not. This may be due to the fact that the UEs that are further away will be lower in strength than those closer to the base station. This effect is known as the near-far effect. The Base station instructs those stations closer in a cell to reduce the transmitting power in order to overcome this. This facilitates the transmission through same power levels.

It is also important for the base stations to control their own power levels as well. Signals from different ones will interfere, if the signals transmitted by the different base stations are not orthogonal to one another. Accordingly their power is also kept to the minimum required by the UEs being served.

Two techniques that are employed to achieve the power control: open loop; and closed loop.

13

During the initial access, .i.e. before communication between the UE and Base station has been fully established, Open loop techniques are used. It operates by calculating the received signal strength and with the help of that estimate the transmitter power required. The path losses in either direction are different as the transmit and receive frequencies are different, different and hence it can be said that this method is a close estimate, which has no room to improve.

Once the UE has established a connection with the node B, closed loop techniques are intiated. The signal strength is measured in each time slot. A power control bit is sent to signal the UE to step up or down its power. This process is done on both the up and downlinks. Only one bit is assigned to power control to enable the power to change continually. This will not create a overhead at any level

2.2 LTE Systems Overview

After the 3G data networks (e.g. GSM to UMTS to HSPA to LTE or CDMA to LTE), the next step to

step on is Long Term Evolution. LTE is based on standards developed by the 3rd Generation

Partnership Project (3GPP). It can be said that UMTS Terrestrial Radio Access (E-UTRA) and Evolved

UMTS Terrestrial Radio Access Network (E-UTRAN) transformed to the next stage, which is LTE. The

standards for GSM/UMTS family were created by 3GPP. The standards for LTE are totally new, with

some exceptions where it made sense. The key objectives for LTE are listed as follows.

Better downlink and uplink peak data rates.

Scalable bandwidth

Improved spectral efficiency

All IP network

A standard’s based interface, which is capable of supporting a wide multitude of user types.

The main goal or intension of LTE networks is to bridge the data transfer

speed gap between very high data rate fixed wireless Local Area Networks (LAN) and highly

mobile cellular networks.

2.2.1 Overview of the LTE Standard

The original study on Long Term Evolution (LTE) of the 3GPP Radio Access Technology family was

started with the aim of making sure that 3GPP RAT is more advanced in the future than that of the

predecessors. The motive of the investigation was to enhance and improve the radio-access

technology (UTRA) and optimization of radio access network (UTRAN). The main characteristics of

LTE are:

Efficient spectrum utilization Flexible spectrum allocation Reduced cost for the operator Improved system capacity and coverage Higher data rate with reduced latency

2.2.1 Targets for LTE

Some of the key targets set for LTE are listed below (as per [3GPP TR 25.913])[17]

14

Increased peak data rate: 100Mbps for DL with 20MHz (2 Rx Antenna at UE), up to 50Mbps

for UL with 20MHz

Improved spectrum efficiency: 5bps/Hz for downlink and 2.5bps/Hz for Uplink

Improved cell edge performance (in terms of data rate)

Relatively low latency.

2.2.3 Overall Network Architecture

The E-UTRAN makes use of simplified version single node architecture. This has the eNBs (E-UTRAN Node B). eNB and the Evolved Packet Core (EPC) communicates with each other through the S1 interface; specifically with the MME (Mobility Management Entity) and the UPE (User Plane Entity) identified as S-GW (Serving Gateway). This S-GW uses S1-C and S1-U for control plane and user plane respectively. MME and UPE are mostly implemented as separate network nodes so that independent scaling of the control plane and the user plane can be implemented. This is clearly illustrated in the figure 2.5.

Figure 2.2: Overall Architecture [8]

Multicast/Broadcast over a Single Frequency Network (MBSFN) is efficiently supported by

LTE, where multiple cells transmit a common signal with appropriate time synchronization. Even

though eNB is the only entity of the E-UTRAN, all the functions in a typical radio network, for

example, Radio Mobility management, Bearer control, scheduling and Admission control are

efficiently supported in it. The Access Stratum resides at the eNB.

15

Figure 2.3 Functional Split between E-UTRAN and EPC [8]

2.2.4 LTE Physical layer

To achieve the aim of high data rate and improved spectral efficiency, the LTE physical layer

is built with Orthogonal Frequency Division Multiplexing scheme OFDM. Both time also called as slot

and frequency units, which is also called as subcarrier makes the spectral resources that are

allocated/used as a combination. 2 or 4 Antennas are supported. UL and DL supports Multi-user

MIMO. QPSK, 16QAM and 64QAM are the modulation schemes supported in both uplink and

downlinklink spectrum.

2.2.4.1 Downlink (DL) Physical Channel

OFDM with cyclic prefix is used for the downlink transmission. OFDM is used due to the

reasons that are described below:

For the narrow band subcarrier, the channel appears to have nearly flat frequency response

and to mitigate this selective fading is countered by multiple carrier modulation (MCM).

By changing or adapting to the channel condition like the number of resource blocks and the

frequency range of each of the resource block, flexible spectrum allocation is achieved.

Higher peak data rates are achievable with the help of combining several resource blocks

and not by reducing the duration of each of the symbols in it or by using still higher order

modulation.

16

Higher spectral efficiency is an advantage obtained by the multiple orthogonal subcarriers.

2.2.4.2 Uplink (UL) Physical Channel

The uplink transmission is built with the SC-FDMA (Single Carrier FDMA) scheme. A two stage

process makes up the SC-FDMA scheme. The first stage is where the input signal is converted to

frequency domain, which are represented by DFT coefficients and the second stage is where OFDM

scheme is used to change these DFT coefficients to an OFDM signal. The SC-FDMA scheme is a

scheme which is known as DFT-Spread OFDM because of this association with OFDM. The reasons

for this choice are described below:

The two stage process facilitates the selection of appropriate frequency range for the

subcarriers while mapping the set of DFT coefficients to the Resource Blocks. At any given

time, Users get unique frequency. This avoids co-channel interference among the users of a

cell.

The transformation is same as the shift in the centre frequency of the single carrier input

signal. The subcarriers do not combine in random phases, which cause large variation in the

modulated signal in terms of instantaneous power. This implies Peak to Average Power Ratio

is low.

The Peak to Average Power Ratio (PAPR) of SC-FDMA is lesser than the PAPR of the

conventional OFDMA.

2.3 Introduction to LTE Advanced

Observing the growth and success rate of the 3G technologies, it is obvious that the growth rate of cellular network should not slow down. The ideas to start up 4G technology started to flow in and the investigation started. In an initial investigation happened on 25th of December, 2006 which was released on 9th of February 2007, NTT DoCoMo briefed out the information about the their trial which succeeded in sending data to a mobile station moving at a rate of 10Km/h, with a speed up to 5 Gb/s. This was done with a 10Mhz bandwidth. The Technique which made this possible includes several technologies to achieve this, of which the significant technologies are variable spreading factor spread orthogonal frequency division multiplex, MIMO, multiple input multiple output, and maximum likelihood detection. Methods and procedures for these new 4G experiments were passed to 3GPP for their consideration

3GPP organized two workshops in 2008 on IMT Advanced. This is where the "Requirements for Further Advancements for E-UTRA" were outlined. Technical Report 36.913 was made out of this and then published in June 2008. The LTE-Advanced system was submitted to the ITU-R as their proposal for IMT-Advanced.

The evolution from the 3G services was developed by making use of UMTS / W-CDMA Technologies. This is in turn followed by the development of LTE Advanced / IMT Advanced technologies.

There exists another technology that competes with LTE. WiMAX offers very high data rates with high levels of mobility. However it is less likely that the WiMAX may be adopted as the 4G technology. LTE Advanced seems to have a better probability.

17

2.3.1 LTE Advanced key features

With a large number of improvements are happening in LTE Advanced, a number of key features and requirements are found. In spite of the specification not being fixed now, there are many high level targets for the new LTE Advanced specification. These specifications need to be verified and validated. Much work has to be done in the specifications of this technology, before these are all fixed. Some of the main targets for LTE Advanced as of now are listed as follows:

1. Peak data rates: downlink - 1 Gbps; uplink - 500 Mbps. 2. Spectrum efficiency: 3 times greater than LTE. 3. Peak spectrum efficiency: downlink - 30 bps/Hz; uplink - 15 bps/Hz. 4. Spectrum use: the ability to support scalable bandwidth use and spectrum aggregation where

non-contiguous spectrum needs to be used. 5. Latency: from Idle to Connected in less than 50 ms and then shorter than 5 ms one way for

individual packet transmission. 6. Cell edge user throughput to be twice that of LTE. 7. Average user throughput to be 3 times that of LTE. 8. Mobility: Same as that in LTE 9. Compatibility: This is backwards compatible. LTE Advanced shall be capable of interworking with

3GPP legacy systems and LTE.

These are some of the key development targets for LTE Advanced. Their actual specifications and the actual implementation have to be done during the implementation stage of the system.

2.3.2 LTE Advanced technologies

There are various key technologies to achieve the high data throughput rates that are required as per the target of LTE advanced. MIMO and OFDM are the two of the base technologies that enable this amount of precision and efficiency. There exists number of other techniques and technologies apart from these.

OFDM forms the foundation of the radio bearer. Apart from that, there is OFDMA (Orthogonal Frequency Division Multiple Access) along with SC-FDMA (Single Channel Orthogonal Frequency Division Multiple Access). A hybrid format of these will be implemented. Anyhow all these schemes work based on OFDM.

3 Related Work

3.1 Periodic Streams This is the part to talk about the history. The Idea of making measurements from periodic

stream is logical and is not new to the world. “Network performance measurement with periodic

streams” [1], RFC 3432, which was rolled out in 2002 was to study the performance of the network

in terms of delay and jitter, which are necessary parameters for VOIP (Voice Over IP). In 2002, the

cellular data network had less penetration and the wired systems are not good. So it is necessary to

maintain good voice quality over the internet with this not so good wired infrastructure. This RFC

could be made to monitor the performance in these networks.

18

3.2 TCP in HSDPA “3G HSDPA Performance In Mobile Internet Connections” [2] talks more about TCP in the 3G

network. TCP is the dominant protocol in the internet, which constitutes 85% of internet traffic [3].

The remaining 15% may be mostly real time traffic such as voip communication, video conferences,

streaming traffic, etc. Since TCP is the widely used protocol and content delivery has to be made

using TCP (as it gives reliability), it’s rational to use TCP streams for the system. Some UDP streams

are also tested during the pre-study for the system. In the above mentioned thesis work, the author

does some experiments concentrating TCP and the radio level qualities. It is reasonable in a way that

performance TCP is associated with packet loss and packet loss is associated with the radio channel.

Now a days, packet loss in cellular network may be mainly because of the radio channel quality. The

wired infrastructure is very good now a day.

3.3 QOS for Mobile Network

As discussed in the section 3.1 the traffic types in the internet changes now and then. Users

started using real-time traffic like VOIP. For these real-time applications parameters like delay, jitter,

etc. The service providers have mechanisms and tools to monitor and maintain these QOS

parameters. As a user, it is not possible to get these details from the provider. The ultimate aim of

this system is to sense the radio leg of the 3G and LTE system in terms of practically available data

rate without data from the service provider. This is done by downloading files through the network.

This is close the procedure followed in the system used in “Measuring QoS for GPRS Mobile

Networks” [4]. Even though the concern is not on the results but on the procedure, that system also

provides importance to many parameters like packet loss, delay and some GPRS layer parameters.

4 System Design

The system is designed with careful consideration of all the parameters that could affect the bandwidth, a user can experience. The system needs to be very stable as it may have to run for a very long time for continuous monitoring.

4.1 System Requirements

The main aim of this system is to investigate what data rate a user can get practically from various operators at various times in a particular location. Moreover the system can be used to route the user traffic from the system itself or the connected peers via various operators based on the pre-defined policies. To get a data rate at a time, a file of pre-defined configurable size is downloaded and from the time taken to download and the file size, the average data rate is calculated. This is done every t seconds for all n interfaces. Each interface is separate HSDPA or LTE connection. There is also a need for recording these measurements and a web server to present these measurements live.

The connectivity to the service providers is out of this system and hence the system cannot recognize network failures. Optionally a separate notification system is necessary to notify network failures. So that it can be fixed manually. Without this feature it is necessary to check the connectivity frequently.

19

A provision to change the measuring frequency t and/or the file size while running the system from the local system or from a remote system can be helpful. The system can be understood more clearly from the figure 1.

When a user is connected to any operator, there is nothing the user can do. When the operator he is connected to is not performing well in terms of available bandwidth, when compared to the other operators, in that area, the user should be able to efficiently route the traffic through other operators in that area possibly through a Wi-Fi infrastructure. The system should be able to select operators to route the user traffic based on the current network status and configurable policies. For this functionality the system can make use of the results fetched from the monitoring system.

4.2 Methodology

The ultimate aim is to find when is the right time for the content provider to deliver the content to the user’s terminal. When more users are connected to a base station, lesser the resource available to each user, in terms of available data rate. So to solve the purpose of finding the right time to push the content, it is necessary to keep track of the bandwidth available per user in a cell. To get the available data rate per user in a cell in an operator, the system creates a TCP stream and measures the data rate available in a cell over time. This will enable the content provider to know when the cell is not congested .i.e. when there is less users and thereby increasing the data rate available to each user. Using this data, the content provider will have the ability to study the data characteristics and user behaviour in an area and push the content to the user at the right time. This system can also be used to study and analyse the data rates and user pattern in an area in each of the operator.

When a user experiences a low data rate in an area, the user can get a better data rate through this system. For this, the user has to connect to system through a local channel infrastructure (e.g. Wi-Fi). As the system is aware of the network states of different service providers in a cell, it can efficiently route the user traffic through a better operator. The decision for routing the user traffic is made based on the configurable policies.

4.3 Design Choices

This system includes a major amount of networking operations. Java from the beginning has a rich feature-set for networking. Moreover java has more API’s and third-party support than any other programming language. Hence Oracle’s JDK 1.7 is chosen to do majority of the tasks.

Apache2 is chosen as the web server to run in the measuring system. It is required to be run by the notification system to serve testing HTTP requests and the collection server to facilitate the user to see the results through web browser. PHP5 is used to read the excel files and to present it for the web server.

To download a file of pre-defined size from a FTP server, needs no API or any third party support. It can be done by native java utilities. A FTP server, vsftpd is used as the FTP server to provide the files of different predefined sizes.

From the time taken to download the file and the file size the data rate is calculated but this is the data rate at the application layer level, which means the packet overheads are not accounted. There is no good way to include these in the measurements. Though SNMP has a very low reliability,

20

it is good to record the SNMP measurements as well. To make SNMP requests to the SNMP agent (snmpd in our case), an API is needed and WebNMS [10] is used.

Suitable SNMP parameters should be selected to get the values from the agent. For every interface the incoming and outgoing traffic are important, so ifInOctets (OID: 1.3.6.1.2.1.2.2.1.10) and ifOutOctets (OID: 1.3.6.1.2.1.2.2.1.16) are chosen. The number of packets is also a good parameter to look at and the number or errors in each direction per interface may also useful. ifInUcastPkts (OID: 1.3.6.1.2.1.2.2.1.11), ifOutUcastPkts (OID: 1.3.6.1.2.1.2.2.1.17), ifInErrors (OID: 1.3.6.1.2.1.2.2.1.14) and ifOutErrors (OID: 1.3.6.1.2.1.2.2.1.20) are also fetched.

There are many inputs such as the interface IP addresses, number of interfaces, measurement interval are given to the measuring system. Giving those input in the program i.e, hard-coding in the program and the changing every time the program runs is difficult, time consuming and error prone. It is not user friendly as well. It is relatively easier and user-friendly, if those input are given through a separate excel file, with extension “.xls”. This is done with the help of the API JXL. The same API is used to record the results in the collection Server. It is used by the trigger server to change the input as well.

It is possible to get Cell ID and Signal Strength from the modem associated with each interface and the measuring system does not use any API or third party tools to fetch these. This is done by directly accessing the interfaces (eg: /dev/ttyUSB1).

The tethering system need a system to monitor the user traffic and allocate bandwidth based on the user traffic. To get the precise user traffic it is good to capture the packets in the tethered interface. This is done with the help of JPCAP API [11].

It would have been a complex task to make the measurement system monitor the interfaces constantly and send notifications. A third party tool called OpManager [12] is used for this system this is a separate system which has a good monitoring system and can send notifications via email and/or SMS. Above all this system has a web GUI through which, it can be configured or modified remotely.

4.4 Design Issues

It is simple to implement a system that downloads a file via one interface and then move to other interfaces, i.e. download from each interface one by one sequentially. But the problem is that the results have less accuracy, when compared with each other. The measurements are done at different times, if done sequentially and hence are less accurate to compare. Moreover service providers share base stations and doing the measurements for different interfaces in parallel and in sequential may give different results. To make parallel measurements multi-threading is used. Individual threads are created to take care of different interfaces with one interface each.

It is essential to route the traffic of the file download through different interfaces. Routing is decided based on the destination IP addresses. To solve this problem n public IP addresses are required to route traffic to and from n interfaces in a measuring unit. Any number of measuring units can be used with n interfaces each. The limit is the load that the FTP server can handle. The routing is controlled by native terminal commands. Another major problem is routing during network failure. When a network fails the measurement unit cannot recognize the network failure, because the notification system (which can recognize network failure) is a different, independent system. The file will be downloaded via the default gateway. To avoid this, a set of black-hole or null routes to the destination FTP servers are created with higher metric. When a network fails, the route

21

(with lower metric) to route the traffic through that particular interface disappears. The traffic is trapped by the black hole routes and is dropped. This can be recognized by the measurement system and handled effectively.

To give a provision in the measuring system to change some parameters like the measurement interval and the file size during the runtime, a separate thread is needed to constantly listen to a particular port, which is error prone and complicated. This can be done by updating the variables in each thread before each measurement. This can be easily done with the help of the functions that already exists to get the input from the excel file. A separate program called the trigger server is run to listen to a specific port and I changes the input excel file based on the triggers it receives from a remote system. This program also uses the JXL API to modify the input file.

The major issue with getting the signal strength and cell ID is that the serial port to send request to fetch these is blocked by the modem-manager (Ubuntu) for exclusive use. So the diagnostic port is used. This port does not take requests, but sends out the changes when there is one. Hence there is a need for a separate program to keep track of these changes and this program delivers the data needed for the measurement system through requests and responses.

Figure 4.1: System Layout

4.5 System Implementation

The system description is detailed below based on the flow of the measurement system.

4.5.1 Measurement System

The measurement system gets the inputs from the pre-configured excel file (.xls) file and starts a thread for each interface depending upon the interface configuration in the input file. Each

22

thread will send request to get values from the counters associated with corresponding interface. The time is noted as ts and the download request to get the file from the FTP server is sent and the file is downloaded. The time after the file download is noted as te. The size of the downloaded is noted as s bytes. The average data rate is given in KB/s by s/t*1000, where t=te-ts seconds. The threads will send its interface ID to the Cell ID and Signal Strength monitoring system and it will in turn return the cell ID and the Signal strength. The SNMP request is sent once again to get the discussed parameters and the results are calculated from the difference between these and the previously obtained values. Once the measurement is done, each thread sends the data to the Collection Server, which stores these results. The measured data is sent as a string with multiple values delimited by “#”. A sample data which is sent from the measurement unit to the Collection server is shown below.

MU1#Tele2#1340954987533#3145728#2097702#49094#1481#942#0#0#-69#7A13DA#46834#44.0#67.0

Here MU1 is the measurement unit ID, Tele2 is the interface ID, 1340954987533 is the Timestamp, system time at which the download at that interface started, 3145728 is the file size downloaded in bytes, 2097702 is the bytes received in the interface, 49094 is the bytes sent through the interface, 1481 is the packets received in that interface, 942 is the packets sent through the interface, the next two zeros are the errors during receiving and sending respectively, -69 is the signal strength, RSSI expressed in dbm, 7A13DA is the cell ID of the interface, 46834 is the duration of the download, 44.0 is the not so reliable SNMP based data rate in KBps and the 67.0 is the calculated (from file size and duration) data rate in KBps.

The threads then update its variables from the input file. This facilitates the change of parameters during runtime. Each thread calculates the time it has to wait for the next measurement and goes to sleep till then. This is illustrated in Figure 4.2 and Figure 4.3.

Figure 4.2: Layout of the Measurement System

23

Figure 4.3: Structure of the Measurement Unit

When the child threads are started the main thread will be alive and it is used to monitor the user traffic and change the routes according to the bandwidth and the policy. The packets are captured in the shared interface. The bandwidth of the user is calculated every second and if there is user traffic more than three seconds, then the tethering system will stop the measurement for the interfaces used for the user traffic. From the measurement data the bandwidth available in each interface is known. When the cumulative bandwidth of the user traffic exceeds a particular threshold, more interfaces are added to serve user traffic. When more interfaces are added, the measurement for those interfaces will be paused. The interfaces are selected based on policies that are predefined. Policies can be selected from the three main policies, which are bandwidth based, cost based and target per peer.

24

Figure 4.4: Structure of the Tethering System

The three policies based on which the user traffic is routed are discussed below

4.5.1.1 Best Performance

This is one of the policies using which the system can route the user traffic to the internet.

The user can change or configure the maximum number of interfaces used for serving the users. This

is the policy where the performance for the user is the first concern. The system will initially allocate

one interface for serving the user traffic. This one interface is the best interface of the system in

terms of available bandwidth. Once user traffic is deducted, the system will stop the measurement

for that interface and starts monitoring for that interface. Once 80% of the allocated interface is

consumed, one more interface (the next best) will be added. This 80% is based on the measurement

made prior to stopping the measurement in that interface. Again the total usage is monitored and

interfaces are added if necessary.

4.5.1.2 Best Cost

The best cost policy is similar to that of the Best performance policy but the difference is that the interfaces are selected based on the cost instead of available average bandwidth. The preference will be given to the interface with the lowest cost.

4.5.1.3 Target per User

It can be in a way said that this policy is a combination of both Best Performance and Best

Cost policies. The system will monitor the user traffic and it will fix a target for each user. Then it will

try to achieve that target for each user by allocating the interfaces starting from the lowest cost or

highest data rate.

25

4.5.2 Collection Server

The collection server receives the measurement data sent from the measurement system. It receives it as a single string delimited by “#”. It splits the values and stores it in a file (.xls file) as different fields. The file is named after the measurement unit ID. Hence this has the capability to handle measurements from multiple measurement units.

4.5.3 Trigger Server

The trigger server is that runs in the measurement unit to change the input file based on the requests from the trigger client. Since the measurement system will updates its variables every measurement, this change will reflect inside the measurement system during the runtime.

4.5.4 Trigger Client

This is the program that can be run from the local or a remote system to send requests to the trigger server to change the behaviour of a live measurement, which was already been running.

4.5.5 Cell ID and Signal Strength Monitoring System

As the cell ID and the signal strength cannot be obtained by sending requests, there is a need for a separate system that keeps track of all cell ID’s and signal strengths (of different interfaces), so that the measurement system can fetch whenever necessary. This is run in the local system and listens to a TCP port. The threads measurement system sends requests to fetch the data for the corresponding interface. This system can be understood from the Figure 4.5.

Figure 4.5: Structure of the Cell ID and Signal Strength Monitoring System

26

Similar to the measurement system, this also starts multiple threads, one for each interface, to monitor the signal strength and cell ID. The main thread will continue listening and serve the requests from the measurement system.

4.5.6 Web Server

The web server is an optional and independent server that runs along with the collection server (either local or remote). This displays the stored results in the browser. This coded in refresh every 5 seconds, so that it can show up the new entries.

4.5.7 Notification System

The notification system operates outside the measurement system, i.e. it is an independent system. This checks the configured interfaces every configurable time. If any of the interfaces fail, it sends email and/or SMS to pre-configured email address and/or mobile number respectively.

This system checks the interface by sending a HTTP request to the web server running in the system through the interface to be monitored. When the request times out then the connection is lost (Logical connection) and it will take the configured actions for the failure.

5 Results and Analysis

5.1 Data selection For Experiments

As discussed in the previous chapters the experiments are done by downloading a file from the FTP server. It is necessary to choose an optimum file size, which should satisfy our needs and also not consume so much of bandwidth. To make this decision a series of experiments were run by downloading different file sizes throughout the day. A part of the results is shown in the graph 5.1. It should be noted that since it is necessary to see the variations in the same interface, and one download should not affect the other, these files are downloaded sequentially. This is the only place where the files are downloaded sequentially and not parallel.

This part of the results is chosen to make the decision, because this is the part where there are more changes in the data rates. The reason for the more changes in the particular region is that this is the part of a day where there is more user activity. As seen in the X axis of the Graph 5.1 this is the results from 7am of a working day till 4pm of the same day. This data rates reflects the bandwidth available for a user at different times. On seeing the general behaviour of the data rates it can be observed that the available bandwidth is low during the break times, as expected. This can be explained by the fact that there are more users during the break times. These results are extracted from running the experiments in an area where there are more offices. It is obvious and expected that more bandwidth is available for each user before the office hours, due to less number of users in the area. This can also be seen from the Graph 5.1 from 7am to 8am.

27

Graph 5.1: Data rates for different file sizes

On observing the Graph 5.1 it can be inferred that there are less amount of variations for low file sizes. When the variations are less, it’s hard to make a certain decision about the network status. The main Idea of finding the network status at a specific time in a specific location itself is not satisfied by downloading small files. From Graph 5.2, which is an extract of only the small file sizes, It is more clear that all the details that are observed in the variations in large file sizes are not present in the variations obtained from downloading small file sizes.

Graph 5.2: Data Rates for small file sizes. Extract from Graph 5.1.

From the observations discussed above, it is very clear that a large file is required to do measurements to make it reflect the variations of the bandwidth more efficiently. Hence file size of 3 MB is used throughout, unless it is mentioned otherwise. Moreover the Y axis is always data rate in Kbps and X axis is Time, unless it is mentioned otherwise.

It is also considered that different traffic types behave differently, for example, TCP behaves different from UDP. Since the data delivery system and most of the system in the internet works based on TCP, TCP was chosen. Moreover FTP was chosen because; it has the capacity to use the entire radio link capacity. Some TCP based streaming systems are logically suitable for this purpose as the bandwidth hungry traffic from mobile terminal are those. It was not selected as the providers have implemented mechanisms to stop and then start the download. This protects them from not sending all the data unless it is tentatively used.

0

1000

2000

3000

4000

5000

6000

Tim

eSt

a…

07

:15

07

:35

07

:55

08

:15

08

:35

08

:55

09

:15

09

:35

09

:55

10

:15

10

:35

10

:55

11

:15

11

:35

11

:55

12

:15

12

:35

12

:55

13

:15

13

:35

13

:55

14

:15

14

:35

14

:55

15

:15

15

:35

15

:55

Dat

aRat

e in

Kb

ps

5M

3M

1M

500K

100K

50K

0

5

10

15

20

25

Tim

eSt

a…

07

:15

07

:35

07

:55

08

:15

08

:35

08

:55

09

:15

09

:35

09

:55

10

:15

10

:35

10

:55

11

:15

11

:35

11

:55

12

:15

12

:35

12

:55

13

:15

13

:35

13

:55

14

:15

14

:35

14

:55

15

:15

15

:35

15

:55D

ata

Rat

e in

hu

nd

red

s o

f K

bp

s 500K

100K

50K

28

5.2 Relevance in the time domain It would be interesting to study the data rate variation in the time domain. With the help of

this study, the significance of this system can be clearly understood. In the Graph 5.3 the available

data rate of a 3G network throughout a 24 hour period is seen, along with the 1 hour moving

average. It can be inferred from the above mentioned graph that there are fluctuations in the

available average data rate of consecutive measurements. On seeing the 1 hour moving average it

can also be inferred that the fluctuations are around a common data rate. That data rate is

predictable based in the moving average. It is obvious and expected that there would be less

average data rate available during office hours due the fact that there will be more users using their

mobile device and these measurements are made in an office area. Users are bringing in their 3G

enabled devices along with them to the office and there by congestion in the network occurs.

Graph 5.3: Data rate change throughout a 24 hour period with 1 hour moving average

It may be useful to study this phenomenon in a sliding window. This may facilitate to predict

the data rate in the time domain once the measurement has been made. This may enable see how

long a measurement is valid. A graph as seen in Graph 5.4 is obtained by looking at the data rate

variations in a sliding window of different sizes, 5 minutes, 10 minutes and 15 minutes.

From the graph mentioned above, it can be understood that there are no patterns or margins in which this variations are constrained to. But the magnitude of these variations are more during the time from 8am to 10am, which is the time frame in which there is most of the data rate drop. This is supported by the Graph 5.3, in which the average data rate drops from around 2.5 Mbps to 1 Mbps during this time.

0500

1000150020002500300035004000

11

:38

:45

PM

12

:28

:45

AM

1:1

8:4

5 A

M

2:0

8:4

5 A

M

2:5

8:4

5 A

M

3:4

8:4

5 A

M

4:3

8:4

5 A

M

5:2

8:4

5 A

M

6:1

8:4

5 A

M

7:0

8:4

5 A

M

7:5

8:4

5 A

M

8:4

8:4

5 A

M

9:3

8:4

5 A

M

10

:28

:45

AM

11

:18

:45

AM

12

:08

:45

PM

1:0

6:1

4 P

M

1:5

6:1

4 P

M

2:4

7:3

3 P

M

3:3

7:3

3 P

M

4:2

7:3

3 P

M

5:1

7:3

3 P

M

6:0

7:3

3 P

M

7:0

3:0

2 P

M

7:5

3:0

2 P

M

8:4

3:0

2 P

M

9:3

3:0

2 P

M

10

:23

:02

PM

11

:13

:02

PM

Time

DataRate inKbps

12 per.Mov.Avg.(DataRate inKbps)

29

Graph 5.4: Data rate variations in a sliding window of different sizes

The Graph 5.5 and Graph 5.6 shows the micro level variations of a single measurement (single download) in the system in 3G and LTE mode respectively. Simply put, both graphs imply that it is reasonable to record the average values. It can be evidently seen that the data rate sticks close to the average datarate throughout the measurement in all the operators.

Graph 5.5: Micro-level variations of a single download in 3G networks

Graph 5.6: Micro-level variations in data rate of a single download in LTE

But when the overall measurement record is observed as in Graph 5.3, it is seen that the consecutive measurements are not close enough. This means that the service provider may be employing some mechanism to limit the per flow traffic. This is quite probable to manage user traffic.

0200400600800

100012001400160018002000

11

:38

:45

PM

12

:33

:45

AM

1:2

8:4

5 A

M

2:2

3:4

5 A

M

3:1

8:4

5 A

M

4:1

3:4

5 A

M

5:0

8:4

5 A

M

6:0

3:4

5 A

M

6:5

8:4

5 A

M

7:5

3:4

5 A

M

8:4

8:4

5 A

M

9:4

3:4

5 A

M

10

:38

:45

AM

11

:33

:45

AM

12

:28

:45

PM

1:3

1:1

4 P

M

2:2

7:3

3 P

M

3:2

2:3

3 P

M

4:1

7:3

3 P

M

5:1

2:3

3 P

M

6:0

7:3

3 P

M

7:0

8:0

2 P

M

8:0

3:0

2 P

M

8:5

8:0

2 P

M

9:5

3:0

2 P

M

10

:48

:02

PM

11

:43

:02

PM

Dat

a R

ate

in K

bp

s

Time

5 min

10 min

15 min

30

5.3 Study of Multiple operators Data Traffic from multiple operators can be efficiently compared in a locality. This facilitates

to make decisions to deliver the content for the users using a specific service provider.

5.3.1 Study of 3G Traffic

The Graph 5.7 shows the percentage of people using 3G enabled smart phones. From this it

is seen that Sweden has the largest population (96%) using smart phones and 70.5% (Graph 5.11)

are active users. So it is necessary to study this traffic to deliver the content to the users. It is worth

saying that this is the purpose for which this system is built.

Graph 5.7: People having 3G enabled phones in Europe

The Graphs 5.8 and 5.9 are the graphs showing the data rates of three operators in a 24

hour period during weekend and week days respectively. When the Graph 5.7 is observed nothing

interesting happens. In the area were the measurements are made there is more Tele2 users,

because of which, the overall average bandwidth available per user is low for that operator.

Graph 5.8: Data rates from different operators during 24 hour period in weekend

0

500

1000

1500

2000

2500

3000

3500

01

:00

02

:00

03

:00

04

:00

05

:00

06

:00

07

:00

08

:00

09

:00

10

:00

11

:00

12

:00

13

:00

14

:00

15

:00

16

:00

17

:00

18

:00

19

:00

20

:00

21

:00

22

:00

23

:00

Dat

a R

ate

in K

bp

s

Time

Telia

Tele2

Telia2

31

It is quite interesting to look at the Graph 5.9 which is based on the measurement made on a

working day. The graph looks reasonably fair; when the users start coming to the offices (as the

measurement is made in an area with more offices) around 9am, the data rate available per user

drops. Then it slowly starts increasing from 5pm.

Graph 5.9: Data rates from different operators during 24 hour period in weekdays

Graph 5.9 supports the above mentioned fact that the data rate available from Tele2 is the

lowest because there exist more subscribers using Tele2. This is also true while looking at both of the

graphs. But it is interesting that the data rate available for each user in all the networks during peak

usage time (9am to 5pm in graph 5.9) is more or less same.

5.3.2 Study of LTE Traffic

It is good to see a data rate available in the LTE network at this early stage of LTE

penetration. This can be seen in the Graph 5.10. From the observation made from the Graph 5.10, it

can be said that the Tele2 network is less penetrated as the available bandwidth is always high and

there are no remarkable variations. This may be also because Telia is the first provider in the world

to provide LTE services, and hence there may be more users for Telia.

Graph 5.10: Data rates from different operators during 24 hour period in a LTE network

When the data rate available for the Telia users are observed, there are fluctuations but not

as much as 3G, because there are more users using 3G network than any other country in Europe.

This can be seen from the Graph 5.11, which is an extract from “European Mobile Observatory

2011”. Though this system not giving an absolute prediction as now, it can be of great use in the

near future as the LTE technology gets more penetration. Then different results are obtained.

0

1000

2000

3000

40000

1:0

0

02

:00

03

:00

04

:00

05

:00

06

:00

07

:00

08

:00

09

:00

10

:00

11

:00

12

:00

13

:00

14

:00

15

:00

16

:00

17

:00

18

:00

19

:00

20

:00

21

:00

22

:00

23

:00

Dat

a R

ate

in K

bp

s

Time

Telia

Tele2

Telia2

0

5000

10000

15000

20000

00

:05

01

:05

02

:05

03

:05

04

:05

05

:05

06

:05

07

:05

08

:05

09

:05

10

:05

11

:05

12

:05

13

:05

14

:05

15

:05

16

:05

17

:05

18

:05

19

:05

20

:05

21

:05

22

:05

23

:05Dat

a R

ate

in K

bp

s

Time

Tele2

Telia

Telia2

32

Graph 5.11: European 3G active Users

5.4 Study of 3G and LTE network

3G and LTE technology networks provide different data rates and hence it is not possible to

compare them directly. It is possible to compare those in terms of percentage of bandwidth

available. But it is inappropriate to compare these two as they have different levels of penetration in

the society and use different infrastructure. They may also have different cell sizes and user limits.

Without these details nothing much can be inferred by this comparative study. Still this may be

useful to the operators to see the user performances. There arises a question that why can’t an

operator uses an existing system to do this and get a precise measure of the live user traffic instead

of this test traffic. The answer is that different user traffic behaves differently and there may not be

any user traffic in the network at certain times. Hence it is not possible to keep a track of the radio

leg of the provider accessible by a user in terms of available data rate at all times.

Graph 5.12: 3G and LTE traffic during a 24 hour time frame

The Graph 5.12 is just a visualization of the comparison of 3G and 4G network. This

comparison is meaningless as discussed above without details like cell size, users connected, etc.

Those details are not available at the moment.

0

20

40

60

80

100

120

00

:04

00

:55

01

:55

02

:55

03

:55

04

:55

05

:55

06

:55

07

:55

08

:55

09

:55

10

:55

11

:55

12

:55

13

:55

14

:55

15

:55

16

:55

17

:55

18

:55

19

:55

20

:55

21

:55

22

:55

Dat

a R

ate

in %

Time

3G

LTE

33

5.5 Data Rate Prediction The next step and the ultimate purpose of the system is to predict the traffic data rate

available to the users. This can be done based on the previous measurements recorded. In that case,

it will not account for unpredictable changes in the user pattern. For example, it may not have the

capability to predict a sudden burst of user traffic due to a sale that opened in a mall or traffic during

some special occasions. So predicting just based on the previous measurements is inefficient.

Graph 5.13: Percentage Error in prediction over a 24 hour period (Interpolated)

Graph 5.13 shows the error rate incurred by sending out a 500KB data size and then

predicting the data rate for 20MB data stream. This is done in two operators Telia and Tele2. For

telia the error rate is lower than that of tele2 as seen in the graph. The error rate of telia averages

out to 1.31% with a standard deviation of 2.34%. The error rate of Tele2 is higher with an average of

7.77% and a standard deviation of 8.18%

Graph 5.14: Percentage Error in prediction over a 24 hour period (with previous measurements)

Just interpolating may not be efficient making decisions based on the previous

measurements may provide us a better predicting capablity. Graph 5.14 shows the percentage error

rate observed during predicting. In this case Tele2 prediction is better than that of Telia. Telia has a

average error rate of 6.89% and standard deviation of 9.17% where as Tele2 comes out with an

average of 3.03% and standard deviation of 3.06%. This is calculated with a another 24 hour

measurement as reference. The expected data rate is calculated by

0

10

20

30

40

50

60

12

:06

:41

AM

12

:56

:41

AM

1:4

6:4

1 A

M

2:3

6:4

1 A

M

3:2

6:4

1 A

M

4:1

6:4

1 A

M

5:0

6:4

1 A

M

5:5

6:4

1 A

M

6:4

6:4

1 A

M

7:3

6:4

1 A

M

8:2

6:4

1 A

M

9:1

6:4

1 A

M

10

:06

:41

AM

10

:56

:41

AM

11

:46

:41

AM

12

:36

:41

PM

1:2

6:4

1 P

M

2:2

6:4

1 P

M

3:1

6:4

1 P

M

4:0

6:4

1 P

M

4:5

6:4

1 P

M

5:4

6:4

1 P

M

6:3

6:4

1 P

M

7:2

6:4

1 P

M

8:1

6:4

1 P

M

9:0

6:4

1 P

M

9:5

6:4

1 P

M

10

:46

:41

PM

11

:36

:41

PM

Erro

r R

ate

in %

Time

Telia

Tele2

0

10

20

30

40

50

12

:06

:41

AM

12

:56

:41

AM

1:4

6:4

1 A

M

2:3

6:4

1 A

M

3:2

6:4

1 A

M

4:1

6:4

1 A

M

5:0

6:4

1 A

M

5:5

6:4

1 A

M

6:4

6:4

1 A

M

7:3

6:4

1 A

M

8:2

6:4

1 A

M

9:1

6:4

1 A

M

10

:06

:41

AM

10

:56

:41

AM

11

:46

:41

AM

12

:36

:41

PM

1:2

6:4

1 P

M

2:2

6:4

1 P

M

3:1

6:4

1 P

M

4:0

6:4

1 P

M

4:5

6:4

1 P

M

5:4

6:4

1 P

M

6:3

6:4

1 P

M

7:2

6:4

1 P

M

8:1

6:4

1 P

M

9:0

6:4

1 P

M

9:5

6:4

1 P

M

10

:46

:41

PM

11

:36

:41

PM

Erro

r R

ate

in %

Time

Telia

Tele2

34

Det=D500Kt/D20M*D500K

Where, Det is the estimated data rate for 20 Megabytes at time t, D500Kt is the data rate of the 500

Kilobytes data stream at time t. D20M is the data rate value for 20 Megabytes of data at time, which is

previously measured for corresponding data rate for 500 Kilobytes of data D500K.

This may not be suitable for real world scenarios, as the user traffic cannot be predicted,

because of the above mentioned reason.

5.6 Serving User Traffic

The policies used to serve the user traffic are discussed in 4.4.1. It’s interesting to look at the

graphs showing the performances of those different policies.

5.6.1 Best Cost

The best cost policy is designed to keep the cost low. It routes the user traffic accordingly, In the

figure 5.1 the cost of one operator (Telia) is increased from 5 to 7, which makes it more than the cost

of the other operator (Tele2). This makes the user traffic to be routed through the other interface.

This can be clearly seen around 230 seconds.

Figure 5.1: User Traffic with Best Cost Policy

5.6.2 Best Performance

This is the policy in which only the performance is of the concern. The Ultimate aim is to give

best performance available to the users. As shown in the figure 5.2, the initial probing is done in

which the operator Tele2 is found to be the best.

35

Figure 5.2: User Traffic with Best Performance Policy

Hence the user traffic is routed through Tele2. The next probing is done when the user traffic stops,

which is around 140 seconds. Now, Telia is better, in terms of data rate available and the user traffic

is routed through Telia. This process continues. A parameter for the maximum interfaces that can be

used for tethering is configured in the system. In this policy and the best cost policy, the interfaces

with the top characteristics in terms of cost or performance are selected for serving user traffic.

5.6.3 Target per User

This Policy is a combination of both the policies. It will try to achieve an even performance

for all the users by keeping the cost low. In the figure 5.3, the data rate available in each of the

operator is analysed by downloading a sample data stream. This is the monitoring traffic. This

probing data is seen in before 50 seconds. In this Telia has a lower cost and hence the user traffic is

routed through Telia. This user traffic is seen from 50 to 150 seconds. It comprises of browser traffic

from two users. Around 160 seconds one of the users starts a stream and it was consuming the

bandwidth available with Telia in reference with the probing traffic. Around 175 seconds as shown in

the figure, the interface 2 (connected to Tele2) is opened for user traffic and the traffic from the

second user is sent through Tele2.

Figure 5.3: User Traffic with Target per user Policy

The interface choosing policy can be chosen between best interface and best cost within

this. The key difference between the target per user and the best cost and best performance policies

should be understood well. The previous policies open up the interfaces for new streams if required

36

irrespective of the number of users and number of streams. But this routes traffic from different

users.

5.8 Performance analysis for Pre-fetching over multiple operators

The aim of these experiments is to see how optimal solution will it be to download through

multiple operators based on some scheme. In other words, it can be said that the previous study and

experiments are associated with when to deliver the content, whereas this is to study how to deliver

the content. The scheme is explained below, considering that the download is done through two

operators. The download is started in both the interfaces. At some point (after a certain checkpoint

in terms of data downloaded so far), the operators are compared in terms of average data rate. The

data after which the operators are compared is called the probe data, which may be a fixed or

dynamic size. The interface through which the probe data is downloaded first is chosen as the best

interface to continue download. The data download through the remaining interfaces are stopped

and the data downloaded through them are discarded. These become the data overhead as these

data are not used. The interface, which is chosen as the best will continue downloading the data till

some point (Pre specified), after which it will go for probe mode. The data download through the

best interface after the selection till it starts probing is called as the download data. I probing mode

the other interface will also start downloading the same data as the best and this process continues

till the download is over.

5.8.1 Experimentation:

The experimentation is a combination of real traffic measurements and simulated results.

Several traffic measurements are taken with two operators with same start time. This traffic is

streams and the streams are captured. The aim is to see how different will the combined stream

(making use of two operators) be, when compared with the original two streams.

5.8.2 Data Overheads:

Figure 5.4: Theoretical minimum usable download (XY)

Figure 5.5: Practical usable download (XY)

37

Figure 5.6: Theoretical minimum usable download (YZ)

Figure 5.7: Practical usable download (YZ)

These two operators have closer performance differences. Simulations need to be done with

different probe data size and download data size. The Figure 5.4 shows the theoretical minimum

usable download for different probe and download data sizes. The area below the marked line,

which is 75%, (.i.e. 25% overhead,) can be usable. More than 25% overhead can be used but it’s not

optimal and users will not prefer it as it will account for their data usage. An important note must be

made that this overhead is through the other interface and hence there will not be any data rate

loss.

In Figure 5.5 a sample of the practical usable data is presented which does not look very

different when compared to the theoretical one. But when figures 5.6 and 5.7 are observed, which

shows the z axis of figures 5.4 and 5.5 respectively, it can be inferred that the pattern is close, but

the practical usable download data is approximately 20% better than the theoretical one. That may

increase if the data rates of the two operators vary much from each other.

5.8.3 Data Rates:

Figure 5.8: Data rates for different probe and download data size (sample 1)

38

Figure 5.8 shows the different download rates with different probe data and download data

sizes. The red coloured area is the area with high data rates (around 1.1 Mbps) and the blue

coloured area is the low data rate area (around 960 Kbps). The good scenario is where the overhead

is low and the data rate is high. From Figure 5.4 the overhead is low below the marked line. By

adding up that fact with this figure (Figure 5.8) a good data rate is where the probe data size is

around 2Mb and download size is around 9Mb. At that point the data rate using our scheme is

1Mbps and the average data rate with the individual operators are 890 and 910 Kbps. The data rate

gain is 12.5% and 9.3% when compared with operator 1 and 2 respectively. The overhead is 15 %

where the maximum possible overhead with this download and probe size is 19%.

From the figure 5.8 the best operator (in terms of data rate) is Telia with an average data

rate of 910 Kbps and the worst possible combined data rate is 950 Kbps (approx). This is 4% better

than using the best operator. In most of the samples obtained the combined data rate is better than

the best of the two operators. Several other samples were observed and this probe data and

download data combination changes. It cannot be generalized as it totally depends on the stream

characteristics.

6 Conclusion

A better understanding of the user behaviour pattern and the data traffic behaviour is

obtained. The ultimate aim of building this system, which is to get the available average data-rate

per user in a specific location at a specific time, is successfully accomplished. The Validity of the

system is verified. The system provides data rates for the configured operators in a specific cell. The

collection server with web server with capability of acting as a collection of any number of

measuring units was successfully built. With this system it is possible to compare and study the data

rates and there by the user pattern in a specific area. The user pattern in 3G and LTE networks are

studied and compared as seen in 5.4. The data obtained from the measuring system cab used for

analysis of user patterns, predicting the data rate over time, traffic characteristic study, etc. The data

rate on any point of the day can be predicted and validated. This is effectively done in 5.5. It is found

that this method and system can be implemented irrespective of time and place to help content

providers deliver their content more efficiently based of the real-time status of the networks.

It can be inferred that there is a trade off in delivering the content through multiple

operators. When the probing frequency is high the data rate available of the performance is good in

terms of data rate but the data overhead is high. When the probing frequency is less the chance of

staying in a relatively bad interface in terms of available data rate is high, whereas the data overhead

is much reduced. Though the data overhead is through other interfaces, which means it will not

affect the data rate of the content delivery, it is an important factor to consider as it increases with

number of interfaces.

The efficiency of the system in terms of data transfer is improved by serving the user traffic.

The different policies to intelligently select and route the user traffic through multiple operators is

successfully achieved. The system is intelligent enough to make the decision as it is aware of the

network status in each area. This can be evidently observed from the sample user data provided in

5.6

39

The opposition report can be seen as Appendix 1 and the changes suggested were made and

the key change is the inclusion of a methodology section to give a clear understanding of the

procedures.

6.1 Future Work

The measuring technique can be improved, for which a major architecture change is

required. The current system measures data rate in the application layer and this can be improved

by monitoring it in the lower layers, possibly layer 3. This may be possible.

The prediction capability of the system in terms of data rate is not conclusive. It is necessary

to investigate with more operators and different scenarios. More experiments need to be done to

compare the predicting algorithms and is necessary to build new predicting techniques and use

them in the comparative study.

The performance of the tethering system or the part of the system which serves user traffic

is acceptable some extent. There exists a small network outage when switching between the

operators. This must be efficiently handled. The algorithms should be made efficient to account for

the efficiency increase due to switching of operators and switch only if it’s significant. The switching

can be made seamless by routing the traffic through a proxy server, which can be done. For this, the

system must undergo a major architecture change which is changing the TCP protocol stack to

Multipath TCP. By doing this one more benefit can be achieved, which is transferring a single stream

through multiple operators. This will in turn increase the overall bandwidth.

40

References

[1] V. Raisanen, G. Grotefeld, A. Morton, “Network performance measurement with periodic streams”, RFC3432, Network Working Group, November, 2002.

[2] X. Wang , “3G HSDPA Performance In Mobile Internet Connections”, Teliasonera, 22, March, 2004.

[3] Iljitsch, van Beijnum, “Multipath TCP”, IETF Journal, September 2009.

[4] C.M. Sarraf, L. El-Khazan, T. Zoghby, J. Maksoud, S. El-Asmar, J. Nassif, “Measuring QoS for GPRS

Mobile Networks”

[5] ETSI TS 125 308 V10.6.0, 3GPP, “Universal Mobile Telecommunications System (UMTS); UTRA

High Speed Downlink Packet Access (HSPDA); Overall description; Stage 2”, January, 2012.

[6] ETSI TS 136 201 V10.0.0, 3GPP, “LTE; Evolved Universal Terrestrial Radio Access (E-UTRA); LTE

physical layer; General description”, January 2011.

[7] 3GPP TR 36.810 V9.0.0, “Technical Specification Group Radio Access Network; Universal

Terrestrial Radio Access (UTRA) and Evolved Universal Terrestrial Radio Access (E-UTRA); UMTS

/ LTE in 800 MHz for Europe”, March, 2010.

[8] 3GPP TS 36.300 V11.2.0, Technical Specification Group Radio Access Network; Evolved Universal

Terrestrial Radio Access (E-UTRA) and Evolved Universal Terrestrial Radio Access Network (E-

UTRAN); Overall description; Stage 2 (Release 11), June, 2012.

[9] “UMTS / WCDMA Network Architecture”, www.radio-electronics.com, (http://www.radio-

electronics.com/info/cellulartelecomms/umts/umts-wcdma-network-architecture.php Visited:

19 July 2012)

[10] “WebNMS SNMP API 4”, WebNMS, (http://www.webnms.com/snmp/index.html, Visited: 19 July 2012)

[11] “jpcap -- a network packet capture library for applications written in Java”, (http://jpcap.sourceforge.net/ Visited: 19 July 2012)

[12] “OpManager - The network, server and virtualization monitoring software”, manageengine.com, (http://www.manageengine.com/network-monitoring/, Visited: 19 July 2012)

[13] K. McCloghrie “An Administrative Infrastructure for SNMPv2”, RFC1909, Network Working Group, February 1996.

[14] J. Case, R. Mundy, D. Partain, B. Stewart “Introduction to Version 3 of the Internet-standard Network Management Framework”, RFC2570, Network Working Group, April. 1999.

[15] D. Harrington, R. Presuhn, B. Wijnen “An Architecture for Describing SNMP Management Frameworks”, RFC2571, Network Working Group, April 1999.

41

[16] J. Case, K. McCloghrie, M. Rose, S. Waldbusser, “Textual Conventions for Version 2 of the Simple Network Management Protocol (SNMPv2)”, RFC1443, Network Working Group, January 1996.

[17] 3GPP TR 25.913 V8, Release 8, “Universal Mobile Telecommunications System UMTS);LTE;Requirements for Evolved UTRA (E-UTRA) and Evolved UTRAN (E-UTRAN)”, January 2009.

42

Appendix 1:

Opposition report on “Multi-Operator Multi-Radio Performance Monitoring and

Context-Aware Access Provision Test-bed”

Master thesis, by Ansel Zandegran

Overall Comments

The work conducted by the author provides insight information and design details on a test bed for

monitoring performance and provisioning access to mobile data where it requires expertise from

the reader to follow the technical issues regarding system design. The context is reach and covers a

variety of background information. The methods used to design the system seem pretty efficient and

the results are sound. However the author needs to re-work on the paper and address some minor

drawbacks.

Subject and Problem Area

The problem area is very interesting and it captures the reader’s attention as there is a strong

motivation to study when and where the content may be pushed to end users’ devices.

Layout, Formatting and Language

The layout and formatting are in general good but in some cases some coloring of headlines could be

improved for easier and more pleasant reading. Since the paper is for scientific purposes a more

distant language should be used from the author’s perspective.

Figures 2.2, 5.4 miss caption. Figure 5.13 is missing. From section 5.6 the figure numbers are totally

messy.

The language level is good but minor grammatical errors and language gaps exist throughout the

work that when addressed will improve the quality of the work.

Like for example in many parts of the text the author has used “it’s” instead “it is” and so on.

Structure and Contents

The content under Background (section 2) should better be used in the introduction part

directly. The section 3, related work is pretty well defined but the section about Contributions could

have been placed as a sub section for Related Work, talking about the author’s contribution and not

the usage examples of this thesis work. Another noticeable issue is the missing units in some figures

mainly in chapter 5. Chapter 4 contains useful information and is well structured. Chapter 5 is also

well structured. Chapter 5 is very good and the analysis that is made stands on solid ground. The

only issue with this section is 5.1 Data selection For Experiments which seems to be better if put in

section 4 System Design.

Methodology

43

The report misses a methodology section. The statistical approaches used for predictions are not

described. Results – Conclusions The results are interesting and have a logic link with the

information given in previous sections of the work. On the other hand the conclusion mainly seems

as a brief summary of what happened during your project.

References

The references are used correctly throughout the text with some minor mistakes.

Questions

Is it possible to design and implement the system for each user instead of an average approach?

meaning that the system would ensure each and every individual’s behavior then decides and reacts

upon it.

Why are you studying 3G as well as LTE? Why not only LTE?

Where did you get the formula been used in section 5.5?

In 5.5 you mention that the “predicting just based on the previous measurements is inefficient”, so

how come you mention either this method or the history based method should be used?

What is the relation between section 5.8 and the rest of section 5?

If you get hired tomorrow by a content provider as the person responsible to implement such a

system, would you use the same approach? Else, what would your action plan be from technological

point of view?

Opponent

Amirhossein Ghanbari

www.kth.se

TRITA-ICT-EX-2013:189