一個LTE網路上的機器類型通訊負載控制之流量匯聚機制研究

國

立

交

通

大

學

網路工程研究所

碩

士

論

文

一個 LTE 網路上的機器類型通訊負載控制之流量匯聚機制研究

A Study of Traffic Aggregation Mechanism for Overload Control in

LTE-based Machine Type Communications

研 究 生：謝叢至

指導教授：陳耀宗 博士

一個 LTE 網路上的機器類型通訊負載控制之流量匯聚機制研究

A Study of Traffic Aggregation Mechanism for Overload Control

in LTE-based Machine Type Communications

研 究 生：謝叢至 Student：Tsung-Chih Hsieh

指導教授：陳耀宗 Advisor：Yaw-Chung Chen

國 立 交 通 大 學

資 訊 科 學 與 工 程 研 究 所

碩 士 論 文

A Thesis

Submitted to Institute of Computer Science and Engineering College of Computer Science

National Chiao Tung University in partial Fulfillment of the Requirements

for the Degree of Master

In

Computer Science

September 2014

Hsinchu, Taiwan, Republic of China

i

一個 LTE 網路上的機器類型通訊負載控制之流量匯聚機制研究

學生：謝叢至

指導教授：陳耀宗 博士

國立交通大學網路工程研究所

摘要

機器類型通訊指的是機器與機器間透過有線或無線的連接來通訊而沒有人 為的介入。長期演進(LTE)蜂巢式網路擁有的全球連通性和廣大的覆蓋範圍提供 一個很好的架構來布建機器類型通訊相關的應用。然而，傳統的通訊方式和機器 類型通訊間的差異給長期演進網路帶來新的技術上的挑戰。在本篇論文中，我們 針對有關機器類型通訊瞬間大量資料傳送所造成的擁塞問題，提出了一個流量匯 聚的解決方法，此方法將使用機器類型通訊的裝置產生的流量在本地端聚集，如 此將可以減少因為大量機器類型通訊裝置嘗試連接長期演進網路的次數。我們使 用電腦模擬來評估所提出方法之效能，而結果是有大幅度的效能改進。此方法成 功的減少嘗試連接至基地台的次數，同時也不會對裝置造成過多的負擔。

關鍵字: 機器類型通訊，長期演進技術，擁塞控制，流量匯

聚

ii

A Study of Traffic Aggregation Mechanism for Overload Control

in LTE-based Machine Type Communications

Student：Tsung-Chih Hsieh

Advisor：Dr. Yaw-Chung Chen

Institute of Network Engineering

National Chiao Tung University

Abstract

Machine Type Communication means the communications between machine and machine through either wired or wireless links without any human intervention. The LTE cellular networks with global connectivity and wide range of coverage provide good infrastructure for developing MTC applications. However, the differences between the conventional communication and the Machine-type communication bring the LTE networks new technical challenges. In this thesis, we investigate the problem of congestion in machine type communication. We propose a traffic aggregation solution that aggregates the traffic generated by MTC devices on local side in order to reduce the total access attempts to the LTE base station from massive amount of MTC devices. We evaluate the performance of the proposed scheme with the computer simulation and the results show the remarkable performance improvement. The proposed scheme succeeds in reducing the number of access attempts while not causing too much overhead on the devices.

iii

誌謝

在這兩年的研究生生涯中，感謝陳耀宗老師給予我學習以及研究上的指導， 每當有問題向老師請教時，老師總會和我討論並理解我的問題後，給我適當的建 議或甚至是一些不同的想法，這些都讓我獲益良多也讓我在研究的路上少走了許 多彎路。 另外也要感謝實驗室夥伴們這段時間的鼓勵與幫助。感謝林冠宇學長一直以 來給我的支持與建議，能讓我更有系統地進行我的研究，也幫助我解決了許多大 大小小不僅是課業上還有生活上的問題。同屆的同伴李巧女、廖椿育、游哲維和 吳書淮，大家互相支持、鼓勵，也互相激勵，才會有現在的成果。也謝謝實驗室 的學弟、學妹們，這些日子有他們的幫助，在研究這條路上才能如此順利。 最後要感謝的是我的家人們和思函，他們在背後無私的支持推著我前進，在 我感到挫折時總是能因為他們讓我迅速地恢復過來。也是因為他們才能毫無罣礙 的走完這最後的求學階段，

iv

Contents

摘要... i Abstract ... ii 誌謝... iii Contents ... iv Table List ... vi

Figure List ... vii

Chapter 1 Introduction ... 1

1.1 Motivation ... 1

1.2 Objective ... 2

1.3 Thesis Overview ... 2

Chapter 2 Background and Related works... 3

2.1 Background ... 3

2.1.1 MTC Network Architecture ... 3

2.1.2 Common Features of MTC Applications ... 4

2.1.3 Example of MTC Applications ... 7

2.1.4 Problem of Congestion ... 7

2.2 Related Works ... 9

Chapter 3 The Proposed Scheme ... 12

3.1 System Architecture ... 12

3.2 Group Construction ... 13

3.3 Method Description ... 14

3.3.1 Role Decision Mechanism ... 15

3.3.1 Overall Processes ... 16

Chapter 4 Simulation and Numerical Results ... 20

4.1 Simulation Environment ... 20

4.1.1 Simulation Parameter ... 21

4.1.2 Traffic Model ... 22

4.2 Performance Metrics ... 23

4.3 Numerical Results ... 24

v

vi

Table List

Table 2.1: MTC Features ... 5

Table 2.2: Example of MTC applications ... 6

Table 4.1: Simulation Parameters ... 21

Table 4.2: Traffic Model ... 22

vii

Figure List

Figure 2.1: MTC Architecture ... 3

Figure 2.2: Core Network Congestion Use Case ... 8

Figure 2.3: Signaling Network Congestion Use Case ... 9

Figure 3.1: System Architecture ... 13

Figure 3.2: Report Group Communication ... 14

Figure 3.3: State Transition ... 15

Figure 3.4: Process in a Communication Group ... 17

Figure 3.5: Process in a Report Group ... 18

Figure 4.1: Simulation Environment ... 21

Figure 4.2 Access attempts ... 24

Figure 4.3 Access success ratio ... 25

Figure 4.4 Total preamble transmissions ... 26

1

Chapter 1 Introduction

1.1 Motivation

Machine Type Communications (MTC), also called Machine-to-machine (M2M) communications, enable the automated applications which are regarding the

communication between machine and machine without any human intervention. MTC devices connect to each other through wired or wireless connections and share their own information by themselves. In this way, M2M applications help automating everyday life process. There are some already established applications such as transportation, health care, and smart meters to name a few.

While some existing M2M applications use short-range radio technologies, the LTE cellular network with widespread coverage makes MTC devices easier to install and support the applications that require immediate and reliable delivery of data to distant servers. However, the massive amount of MTC devices bring the LTE cellular network many requirements and technical challenges.

LTE cellular network is mainly designed for traditional human-to-human (H2H) services, such as voice conversation and web browsing, but M2M applications often have quite different requirements and traffic types because of their specific features. The third generation partnership project (3GPP) has launched standardization activities on MTC. In 3GPP TR 23.888 [1], the working group of 3GPP studied and evaluated architectural aspects of the System Improvements for Machine Type Communications requirements specified in 3GPP TS 22.368 [2]. They mainly focus on preventing MTC signaling congestion and network overload, and those are important challenges for supporting the mass-market MTC services.

2

1.2 Objective

In this work, we focus on the problem of congestion and system overload in M2M applications over LTE cellular networks. This problem happens when the massive amount of MTC devices try to access the network, sending signaling or data messages at the same time. Take Smart Electric Metering application as an example, meters periodically report the electric power usage to the server for billing application. When these meters try to send their data almost at the same time, the peak load

situations have a tremendous impact on the operations of the LTE network, and both MTC and non-MTC traffic could be affected.

There are some solutions aimed to decentralize the access attempts to enhance the RACH resource utility. However, when the amount of MTC devices grows to a significant level, the RACH still could not sustain the traffic they generated. Thus our proposed scheme focuses on reducing the number of MTC devices accessing the LTE networks.

1.3 Thesis Overview

The remainder of this thesis is organized as follows. Chapter 2 briefly describes the Machine-type communication and the LTE cellular network. The congestion problem and the related works are also presented. Chapter 3 discusses the proposed scheme in detail. The simulation and numerical results are presented in Chapter 4. Finally, Chapter 5 concludes this work.

3

Chapter 2 Background and Related works

In this chapter, we first introduce the overview of Machine-type communication described in the 3GPP specification [2]. Then we describe the problem of congestion. And some related works are presented at the end.

2.1 Background

In order to deeply understand the machine type communication, we study the 3GPP specifications about MTC and describe some details in this section. The architecture of MTC network is presented in first subsection. Some features and examples of MTC applications are listed after that.

2.1.1 MTC Network Architecture

Figure 2.1 MTC Architecture.

Typically the MTC architecture consists of three domain as in Figure 2.1, that is, the MTC device domain, the communication network domain, and the MTC

4

application domain. The communication network domain mentioned here is the LTE cellular network through which MTC devices communicate with remote application servers.

As depicted in Figure 2.1, 3GPP considers two communication scenarios for MTC communications. One is that MTC devices communicate with one or more MTC server, and the MTC server could be controlled by the network operator or not controlled by the network operator. The other is that MTC devices communicate with each other without intermediate MTC server. The first scenario is the most common one and is adopted by many MTC applications, such as power, gas, water, heating, grid control, electrical meters, vending machine control, and fleet management. These kinds of applications use devices (e.g. sensor, meter, etc.) to get some information (e.g. power consumption, temperature, etc.). The information is packaged into an IP packet and sent to an application server through the communication network. Finally, the application server processes these data and makes the related operations such as sending a utility bill to the customer.

2.1.2 Common Features of MTC Applications

The requirements of MTC applications are different from traditional

human-to-human (H2H) and human-to-machine (H2M) ones. Furthermore, different MTC applications do not all have the same characteristics. Therefore, 3GPP

summarized several MTC features to provide structure for the different system optimization as in Table 2.1 in [2].

5

Table 2.1 MTC Features

Take Smart Electric Meters as an example, these meters are fixed at each house (Low Mobility) and the meters send metered information (Small Data Transmissions) every month. Most MTC applications have the similar properties to the Smart Electric Meters, they generate synchronized, short-payload, MTC device originated traffic and with less or no mobility. Therefore, the system optimization must be done according

Features Description

Low Mobility Do not move or move infrequently, Move within a certain region Time Controlled Send or receive data only during

defined time interval Small Data Transmissions Send or receive small amounts of

data

Infrequent Mobile Terminated Mainly utilize mobile originated communications MTC Monitoring Monitoring MTC device related

events

Secure Connection

Require a secure connection between the MTC server and

services

Group Based Features MTC features that applies to a MTC Group

Group Based Policing

MTC Group for which the network operator wants to enforce a

combined QoS policy

Group Based Addressing

MTC Group for which the network operator wants to optimize the message volume when many MTC

devices need to receive the same message

6 to the features compared to the traditional traffic.

Table 2.2: Example of MTC applications.

Features Description

Security

Surveillance systems Backup for landline Control of physical access Car/driver security

Tracking & Tracing

Fleet Management Order Management Pay as you drive Asset Tracking Navigation

Traffic information Road tolling

Road traffic optimization/steering Payment

Point of sales Vending machines Gaming machines

Health

Monitoring vital signs

Supporting the aged or handicapped Web Access Telemedicine points Remote diagnostics

Remote Maintenance/ Control

Sensors Lighting Pumps Valves Elevator control Vehicle diagnostics Metering Power Gas Water Heating Grid control Industrial metering Consumer Devices

Digital photo frame Digital camera eBook

7

2.1.3 Example of MTC Applications

In Table 2.2 [2], 3GPP listed some indicative MTC applications in different scopes, but this is not all. There will be more kind of applications with the maturing of MTC communications in the near future.

2.1.4 Problem of Congestion

In the context of MTC applications, the congestion problem can happen in different part of the communication networks. 3GPP described three use cases about congestion in different area of the LTE networks [2]. Actually, these use cases have common characteristic that a massive amount of MTC devices send their generated information to a single MTC server simultaneously.

- Use case 1 : Radio network congestion

It happens when mass concurrent data transmissions of a MTC application. Taking the bridge monitoring with a mass sensors and the hydrology monitoring during heavy rain as examples, all the sensors transmit the monitored data almost at the same time. Therefore, the network should be optimized to accommodate a potential number of MTC devices in a particular area to transmit data almost simultaneously.

- Use case 2 : Core network congestion

The second use case is that the MTC devices in a MTC group affiliated with a MTC application are developed over the network. Even though the MTC devices in any particular cell will not cause a radio network congestion when they send data simultaneously, data congestion may occur in the LTE core network or the link between LTE core network and MTC server because of the aggregation of the traffic

8 related to a MTC application as in Figure 2.2.

Figure 2.2: Core Network Congestion Use Case.

- Use case 3 : Signaling network congestion

The last use case, congestion in the signaling network (i.e. the control plane of the network), is caused by a massive amount of MTC devices trying to attach to the network or to activate/modify/deactivate a connection at the same time as in Figure 2.3. For instance, when a large group of metering devices want to report their metered data, they have to do the attach procedure in order to turn from idle mode into connect mode. The simultaneous signaling messages usually cause heavy overload on the control plane of the LTE network.

9

Figure 2.3 Signaling Network Congestion Use Case.

2.2 Related Works

MTC communications over LTE networks is a new research issue. Several studies and system optimization solutions have been proposed in these days. These works mainly focus on system optimizations that prevent MTC signaling congestion and network overload which is the key point to support the massive amount of MTC devices/applications. Two categories are distinguished among the mechanisms [1]:

1. Soft mechanisms try to minimize the frequency of attempts to access the network by using soft measures, so as to finish a particular procedure without having to throttle them.

- Reducing Tracking Area Updates (TAUs) signaling from the MTC devices with low mobility feature. The TAU period timer can be increased or even disabled for fixed MTC devices.

- A pull-based approach that the base station controls the number of access attempts from MTC devices through paging [3]. However, the application needs to know about the location of the device, and only the MTC

10 terminated scenario is suitable.

- The group-based access control and signaling scheme in [] use paging to trigger the devices and only one of them is assigned by the base station to be a leader. The leader initiate the random access procedure and other devices will reuse the resources granted to the leader for access to the network.

2. In the rigid mechanisms, rigid measures are used by the mobile network operator to reject the MTC devices that try to access the network if they cause the

overload condition.

- Forming groups of devices based on MTC features such as low mobility, and small data transmission. The HSS (a database in the LTE core network) records the information about the group and devices belonging to the group. Thus the operations of the mobile network are done as a group, and then the signaling overload can be reduced.

- The subclass of the rigid mechanisms to deal with signaling congestion is connection request rejection, also called push-based approaches. The main purpose of this class of methods try to spread the massive access attempts onto a long period of time [5].

 Apply a much larger backoff indicator for MTC devices in order to alleviate the contention of the RACH resources with non-MTC devices as in [6]

 Before the MTC devices attempts to access the network, it first randomly generates a random number between 0 and 1. If the number is smaller than the predefined value p assigned to the device, it can

11

start the random access procedure. Otherwise, the device have to wait until the next access opportunity according to the backoff timer.  Access Class Barring based solutions separate the MTC devices and

non-MTC devices into different access class, and each class has its own probability of access and the access barring time duration.  As suggested in [7], non-MTC traffic and MTC traffic are assigned

with different resources to prevent the contention between them. They also consider the resource usage efficiency, suggesting that the

resource allocation of MTC devices could be dynamically adjusted according to the immediate traffic change.

In the [8], they introduce a solution that rejects MTC traffic at RAN using

feedback from core network nodes (like MME, HSS) regarding their congestion status. And in the [9], they take an overview of existing mechanisms for traffic overload and signaling congestion control, and they also present a complementary solution that suggests handling a bulk of similar signaling messages from MTC devices in a single shot.

All the methods mentioned above concentrate on enhancing the RACH resource usage efficiency and try not to affect the non-MTC traffic. But the tradeoff is the efficiency of the MTC applications limited by the resource of RACH. Consequently, our proposed scheme tries to reduce the access attempts generated by the MTC application with lower overhead on it.

12

Chapter 3 The Proposed Scheme

In this chapter, we present our proposed scheme for massive MTC sensor devices which report their data to the remote server. In our method, MTC devices refer to power, gas, water, heating, grid control, electrical meters, etc. They have the MTC service characteristics like low mobility, time tolerant, and small data transmissions. Other MTC devices having same characteristics can also suit the method.

3.1 System Architecture

We target at the Smart Electric Metering application where multiple smart electrical meters and a single server are considered. Smart electric meters are used to monitor electric networks, to measure electricity usage and report to a central meter management facility.

Smart electric meters support not only one communication technologies [10], transferring data through mobile broadband technology (such as 3G, LTE) to the remote server, and devices located close enough can construct a group by using wireless personal area network (such as Bluetooth, Wi-Fi), aggregating the traffic within a group before reporting to the server so as to alleviate the collision probability of mobile broadband as in Figure 3.1.

13

Figure 3.1 The Proposed System Architecture.

3.2 Group Construction

Smart electric meters in dense area are distributed into several communication groups in a cell coverage, and meters within a communication group communicate with each other by using Wi-Fi ad hoc mode. The number of meters in a communication group depends on how the application generates the traffic, and it has a great effect on the performance of our proposed scheme that we will discuss later. There are several delegates in a communication group take in charge of transferring data through LTE network, and some meters in the communication group send their data to the delegate by using Wi-Fi ad hoc mode. These subgroups are referred to as report group as illustrated in Figure 3.2.

14

Figure 3.2 Report Group Communication.

3.3 Method Description

As mentioned before, meters wake up within a short time period and try to send data to remote server through the network. According to 3GPP specifications, each device should perform a radio resource control (RRC) connection establishment then it can upload its data through LTE cellular networks. Before devices can start their RRC connection establishment, a contention-based random access procedure must be performed. Each cell is allocated 64 preambles and some of them are reserved for the non-contention-based random access procedure. When more than two devices send the same preamble at the same time, the base station may not be able to decode any of the preambles and it cannot respond to the random access request. Devices should wait until the random access response timer is expired and know that a collision has occurred. Devices will keep sending a preamble only if the number of preambles sent reaches the maximum number of preamble transmissions. After that device consider that the random access procedure is failed.

15

When meters use only LTE cellular networks to report their data, the massive number of attempts to access the base station increases the chance of collision and causes not only the inefficiency of the application but also the poor influence on other user in the cell. In our proposed scheme, we aggregate data of meters in a group that decreases the number of attempts to access the base station, but we don’t modify the 3GPP specifications to enhance the RACH performance. In the following, we describe our method in more detail.

3.3.1 Role Decision Mechanism

We introduce a mechanism into meters, and the mechanism involves some state transitions (as shown in Figure 3.3) determining what role should the meter play and how the report data could be sent. Because that smart meters or other M2M devices have limited computing power, the mechanism cannot be too complicated.

16

When a meter wakes up, it would not send its data immediately but start changing between different states. The first state is waiting state. Meters wait for a time interval which we called report interval, and listen to the Wi-Fi channel if there is any beacon from other meters in the communication group. Meter, which did not receive a beacon after the report interval, gets into the delegate state and broadcasts a beacon in the communication group. Other meters, which receive the beacon within the report interval, get into the member state and send their data to the device from which the beacon is sent. These member nodes then wait for a period of time to receive the ack from the delegate, and they get into the finish state. However, if member nodes didn’t receive the ack from the delegate within this period of time, they assume that the delegate didn’t acquire the data they sent and get back into the

waiting state. This waiting time is shorter than the report interval, and it have chance

to join the next report group. The group delegate also waits for this waiting time to collects the member data and sends back an ack to each member nodes. So far all the communication mentioned here are using Wi-Fi ad hoc mode, only the group delegate sends the aggregation of the report data through LTE cellular networks. In the last step, the group delegate also gets into the finish state, and all the processes in a report group is finished.

3.3.1 Overall Processes

In the scenario that N smart electric meters exists in a cell coverage, and they are grouped into communication groups. The meters in a communication group will be further divided into report groups when the application processes the report procedure dynamically. and number of meters in a report group have something to do with the distribution of traffic generated by application and the report interval we set. Suppose the traffic of the application distributes within T seconds and the

17

report interval we set is . For the reason that a meter in a communication decides

to be the report group delegate every in T, we can say that . But sometimes there will be some meters miss the last report group and get back into

waiting state, will be larger than as illustrated in Figure 3.4.

Figure 3.4 Process in a Communication Group.

As presented in Figure 3.5, when the first meter in the communication group waked up, it had no idea whether there was any other meter trying to report the data or not at this time. After the report interval, the meter didn’t get any beacon on Wi-Fi channel, and it became the first report group delegate. The first report group delegate then broadcasted a beacon to tell other meters in the communication group waked up within the report interval of the first report group delegate that was in charge of collecting the traffic and sending to the remote server. Other meters receiving the beacon became members of the first report group and sent their data to the report group delegate immediately, and the report group delegate sent back an ack to them. After all this works, the report group sent the aggregation of the report data to the remote server through LTE network. This process is repeated again and again until all the meters in the communication group have completed their report process.

18

Figure 3.5: Process in a Report Group

Therefore, we can adjust the number of meters in a communication group and the

report interval, depending on different application traffic types and the total number

of meters in a cell coverage. When the communication group is constructed with a bigger group size, there will be less communication groups in the cell. With less communication groups, the number of delegates in the cell are also reduced.

Consequently, the total attempts to access the network are decreased. However, the bigger report group size causes more group members in a report group and the higher probability of packet loss on the report group delegate. On the contrary, the small communication group makes the proposed scheme inefficient, because there are still many devices trying to access the network. On the other hand, the length of report

interval is also important for our proposed scheme. The well setting report interval

can control the report group size in a reasonable range, thus the application can work with good performance.

19

Since only report group delegates access the LTE cellular network, the total access attempts are reduced to a smaller level. That is, the average number of group delegates in a communication group is D, and the number of access meters is lower from N to . As a result, the proposed scheme reduces the collision probability and the average preamble transmissions per device, thus there are more meter

measurement data successfully sent to the remote sever. Furthermore, this scheme leaves more resource for other users in the cell, making less negative influence on the LTE cellular network. Though the scheme need to use both Wi-Fi and LTE for

communication, the scheme leads to power saving for report group members because the distance between a report group member and a report group delegate is much shorter than the distance between the devices and the base station. The overhead of group delegate is reduced because of the less preamble retransmissions in random access procedure.

20

Chapter 4 Simulation and Numerical Results

The simulation results in this chapter were performed by using NS3 simulator with LTE module capability to simulate a MTC environment [11]. We constructed the simulation scenario based on the 3GPP specification TR 37.868 [12]. In the following sections, we introduce the simulation environment first, and then the performance metrics are presented. We compare the performance of the conventional scheme that every meter in a cell sends their report data through LTE cellular network directly and the proposed scheme that a report group delegate gathers data from all report group member before send it to the remote server.

4.1 Simulation Environment

Consider a cell located in a dense area that a massive number of meters in it try to report their data to a remote server. The report data size is small enough to be packed in one packet. For the purpose of lower down the complexity of the simulation, we divided meters into several communication groups with the fixed group size of 100 meters as in Figure 4.1. And the report interval is set to 0.5 seconds. This two parameters settings control the maximum report group size with the traffic model described in the following section. Tuning the two parameters depends on the traffic type and devices deployment of the application in order to have a better performance in a report group.

21

Figure 4.1 Simulation Environment.

4.1.1 Simulation Parameter

In our simulation, we refer to the parameters shown in [9, Table 6.2.2.1.1] and set the one in LTE module of NS3 simulator. Table 4.1 lists the parameters we used for LTE module and Wi-Fi module.

Parameter Setting

Cell bandwidth 5 MHz

Total number of preambles 54

Maximum number of preamble transmission 10

Ra-ResponseWindowSize 5 subframes

SrsPeriodicity 320

Wi-Fi Fragmentation Threshold 2200 bytes

Wi-Fi Reception gain -10 dB

Wi-Fi transmission power level -4 dbm

22

4.1.2 Traffic Model

Since we want our simulation getting close to the reality, annex B.1 in [12] is a good example for us to build the traffic model. It takes the census data and the statistics of the population density in London to calculate the approximate household density. And then, they estimate the average number of Smart Electric meters per cell based on these information (assuming that each household has a meter). Furthermore, we found that there can be more than 30,000 meters in a cell coverage, so we took the number 30,000 as our largest size of meters in a cell. According to the study in the specification [12], the possibility of all meters generating their attempts within 10 seconds due to lack of clock synchronization in meters. Combine all the information above, Table 4.2 shows the traffic model we use for evaluating the performance of the proposed scheme.

Characteristics Traffic model

Number of MTC devices 1000, 3000, 5000, 10000, 30000

Arrival distribution Beta distribution over T,

Distribution period (T) 10 seconds

Table 4.2 Traffic Model.

The time limited beta distribution is used to describe the access intensity within T in [12]. Then the number of arrivals in the i-th access opportunity is given by:

1 _ ( ) ( ) i i t t Access intensity i N p t dt         





23 Where:

- N is the total number of meters.

- is the time of the i-th access opportunity. - the distribution p(t) follows the Beta distribution:

- 0 , 0 ) , ( ) ( ) ( ₁ 1 1     __          Beta T t T t t p

, Beta(,) is the Beta function. The values of α=3 and β=4 are assumed in the study.

- The distribution of access attempts should be limited in the time T:



 T dt t p 0 1 ) (

4.2 Performance Metrics

The following metrics could be taken into account for the performance of the proposed scheme:

- The total number of access attempts: the number of access attempts generated by the application.

- Access success ratio: the ratio between the number of meters that successfully report their data through LTE cellular network and the total number of meters that try to access the base station.

- Total number of preamble transmissions: the number of preamble transmissions generated by the application.

- Average number of preamble transmissions: the average times of preamble transmissions for the successfully accessed meters.

24

4.3 Numerical Results

In this section, we present the numerical results based on the scenario introduced in previous section. The proposed scheme is designed for the massive amount of meters, but it is still beneficial for a small number of devices. It can reduce the access attempts in significant measure. Not only the capacity of the cell is increased but also the negative effects is lowered. In the following, we compare the numerical results from the conventional scheme and the proposed scheme.

25

Figure 4.3 Access success ratio.

Figure 4.2 shows the total access attempts (both successful ones and failed ones) of the conventional scheme and that of the proposed scheme with different number of meters. We can see that the number of access attempts the proposed scheme used is less than one-fifth of which the conventional scheme used to achieve the report process. Therefore, in Figure 4.3, the access success ratio of the proposed scheme could still reach 94.35%, but that of the conventional scheme dropped to 7.47%, when the number of meter grows to 30,000. Even though the actual ratio of report success meters is about 78.37% because the average number of report group members is about 4.9, the result of the proposed scheme outperforms that of the conventional scheme. Although the meters have to support two communication technologies to reach the goal of reduce access attempts, only the group delegates have to use both

communication technologies to finish the report processes. Since some of the MTC applications are delay tolerant, the nodes in a report group spend some time for aggregating the report data is acceptable.

26

Figure 4.4 Total preamble transmissions.

Figure 4.5 Average preamble transmissions of the successful access.

In Figure 4.4, it is obvious that the more meters are located in a cell, the more number of preambles is needed to be sent. The reason is that the probability of preamble collision increases when there are more access attempts at the same time. Since we reduced amount of access attempts with our proposed scheme, the total number of preamble transmissions could be reduced, too. Consequently, the proposed

27

scheme will help not overload the RACH. By observation of Figure 4.5, we can find that when the RACH is overloaded, the average number of preamble transmission sent by the successfully accessed meters is close to 6. That is, the meter sent about six times of preamble to successfully report their data, and that increased the power consumption and the transmission delay within a random access procedure.

Number of Meters 1000 3000 5000 10000 30000

Number of Delegates 135 415 694 1392 5081

Number of Members 865 2585 4306 8608 24919

Retransmissions of Member 218 783 1354 2822 12149

Average Transmission Times 1.25 1.3 1.31 1.33 1.49

Table 4.3: Retransmissions of report group member

Table 4.3 shows more detail of the simulation such as number of delegates, number of members, retransmissions of report group member, and the average transmission times. We found that the average transmission times of the report group member only had a slightly difference from the number of total meters. This is because the transmission of the report group member is located in a communication group, and we set the same communication group size in different scenarios.

Therefore, if we consider more conditions in the environment and set the appropriate communication group size, the performance of the communication group can be much better. Consequently, the performance of entire MTC application also benefits from it.

28

Chapter 5 Conclusion and Future Work

Machine-type communications enable a variety of new services to make our daily life easier. Since the MTC applications use a network to communicate between MTC devices and MTC servers, the LTE cellular network with already developed and large coverage infrastructure is a good option for MTC applications. However, the

Machine-type communication over LTE network brings new challenges on it, because the mobile network is originally designed for supporting the human-to-human

communications. The most important issue is reducing congestion problem caused by a massive amount of MTC devices trying to access the network simultaneously. Even though there are some existing solutions try to enhance the efficiency of RACH resource usage, the performance of the MTC applications and the LTE network are still limited by the restricted resource because of the huge amount of MTC devices.

Therefore, our proposed scheme takes advantage of the local communication by using Wi-Fi to aggregate the traffic within a report group, so as to reduce the total access attempts generated by MTC devices. The simulation results show that the proposed scheme could reduce the total access attempts to a much smaller amount, and the outcome led to the higher access success ratio and less preamble

transmissions. Not only is the performance of MTC applications becoming higher, but also is the resource of the network less consumed. Furthermore, the transmission distance between report group member and report group delegate is much shorter than that between report group delegate and the base station, and that results in the less power consumption of report group members. The power consumption of report group delegate may not grow high because of the less collision on the RACH.

29

report interval) may be dynamically tuned according to the network circumstance, traffic generated by MTC application, and other possible conditions. Furthermore, the waiting time that delegate collects member data and members wait for an Ack can be set with a more accurate number in order to reduce the unnecessary waiting

time .With the support of LTE-direct, the security and interference issue caused by unlicensed band which Wi-Fi works on could be solved.

30

References

[1] 3GPP TR 23.888, “System Improvements for Machine-Type Communications,” v11.0.0, Sep. 2012.

[2] 3GPP TS 23.368, “Service requirements for Machine-Type Communications,” v12.2.0, March 2013.

[3] 3GPP R2-104870, “Pull based RAN overload control,” Hwawei and China Unicom, RAN2#71, Aug. 2010.

[4]Golnaz Farhadi and Akira Ito Fujitsu Labs of America, Sunnyvale, CA, “Group-based signaling and access control for cellular machine-to-machine communication,” in Vehicular Technology Conference (VTC Fall), 2013 IEEE 78th, pp. 1-6, Sept. 2013.

[5] Ming-Yuan Cheng, Guan-Yu Lin, and Hung-Yu Wei, National Taiwan University, and Alex Chia-Chun Hsu, MediaTek Inc, “Overload Control for

Machine-Type-Communications in LTE-Advanced System,” in IEEE Communications Magazine, pp. 38-45, June 2012.

[6] 3GPP R2-112863, “Backoff Enhancements for RAN Overload Control,” ZTE, Barcelona, Spain, May. 2011.

[7] Shao-Yu Lien and Kwang-Cheng Chen, National Taiwan University, and Yonghua Lin, IBM Research Division, “Toward ubiquitous massive accesses in 3GPP machine-to-machine communications,” in IEEE Communications Magazine, pp. 66-74, April 2011.

31

[8] Adlen Ksentini and Yassine Hadjadj-Aoul, University of Rennes1 Tarik Taleb, NEC Europe, “Cellular-Based Machine-to-Machine: Overload Control,” in Network, IEEE, pp.54-60, Jan. 2013.

[9] Tarik Taleb and Andreas Kunz, NEC Europe, “Machine Type Communications in 3GPP Networks Potential, Challenges, and Solutions,” in Communications Magazine, IEEE, pp. 178-184, Mar. 2012

[10] Kwang-Ryul Jung, Aesoon Park, and Sungwon Lee,

“Machine-Type-Communication (MTC) Device Grouping Algorithm for Congestion Avoidance of MTC Oriented LTE Network,” in Security-Enriched Urban Computing and Smart Grid, pp. 167-178.

[11] http://www.nsnam.org/, ns3 simulator web site. [12] 3GPP TR 37.868, “Study on RAN Improvements for