Master of Science Thesis
Stockholm, 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-Radio
Performance Monitoring and
Context-Aware Access Provision Test-Bed
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
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.
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.
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 ... 102.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
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
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
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.
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.
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
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 TD-CDMA). This UMTS WTD-CDMA 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
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.
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
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]
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
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.
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
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-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.
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.
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.
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
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.
23
Figure 4.3: Structure of the Measurement Unit
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
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.
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.
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.
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.
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
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
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.
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.
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
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
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
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)
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:
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.
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.
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 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.
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
