ENS Cachan, Brittany Extension

University of Rennes 1

Congestion control in the context of

Machine Type Communications in
3GPP LTE Networks
Ahmed Amokrane
ahmed.amokrane@bretagne.ens-cachan.fr

Proposed by : Adlen Ksentini And Yassine Hadjadj-Aoul

DIONYSOS, INRIA Bretagne Atlantique

Rennes, January 2011

Contents
1 Introduction

2 Machine-to-Machine Applications
2.1 Denition and generalities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2 Application elds of M2M applications . . . . . . . . . . . . . . . . . . . . . . . . .
2.3 Properties of M2M applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2
2
3
4

3 LTE, Long Term Evolution Networks

3.1 Brief historical evolution of cellular networks . . . . . . . . . . . . . . . . . . . . .
3.2 Overview of the LTE network architecture . . . . . . . . . . . . . . . . . . . . . . .
3.3 LTE network in action: Trac Management . . . . . . . . . . . . . . . . . . . . . .

5
5
5
7

4 Machine-To-Machine applications over LTE

4.1 Concept and motivations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2 Challenges and eorts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

8
8
9

5 Congestion control of MTC in LTE networks

10
5.1 The core problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
5.2 Related works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
6 Conclusions and goal of the internship

14

Introduction

Machine-to-Machine (M2M) applications are automated applications which involve machines or

devices communicating through a network without human intervention. They can be used today
in almost all everyday life applications from military to civil applications, such as: transportation,
health care, smart energy, supply and provisioning, city automation, and manufacturing. The
communicating devices can be embedded in dierent environments like cars, cell towers, vending
machines...etc. They are generally spread in a wide area and should communicate through widely
deployed networks. A good candidate to play the role of such a network could be the cellular
mobile networks.
Cellular mobile networks oer dierent network technologies for M2M communications, and
there are strong realistic predictions stating that M2M will be leveraged over cellular mobile
networks to provide mobile operator much-needed revenues. However, cellular networks are designed for Human-to-Human (H2H), Human-to-Machine (H2M) and Machine-to-Human (M2H)
applications, which is dierent from M2M. Thus, Mobile Network Operators (MNO) should accommodate their networks to support the M2M applications which involve a huge amount of
autonomous devices. 3rd Generation Partnership Project (3GPP)1 [1] is working on specications to standardize the deployment of M2M applications in 3GPP networks (UMTS and LTE).
Such a deployment will benet for both MNO, users and application developers. However, it is
quite challenging and not trivial to nd out solutions to this deployment. In fact, it rises problems of congestion which may occur due to simultaneous signaling or data messages from MTC
devices (huge number of devices), which can be signicant. The congestion doesnt concern only
the radio part but, also, the core network part, in contrast with the former deployment. This
may lead to peak load situation and may have a tremendous impact on the operations of the
mobile network, penalizing both MTC and non-MTC devices.
In this work, we will address the issue of dealing with congestion in LTE in the context of
M2M applications. The main goal is to explore and propose a technique that leverage the problem
of congestion for both data and signaling.
The remainder of this document is organized as follows. Section 2 provides some denitions
and generalities on M2M applications. Section 3 describes rst a brief overview of the historical
evolution of cellular networks, then it introduces the key components of LTE networks and the
trac management aspects. Section 4 portrays the deployment of M2M applications in LTE
networks. Then, we go through the core problem of congestion in LTE in the context of M2M applications, and discuss the few related works in the literature, in section 5. Finally, the document
concludes in Section 6 with a brief summary, some remarks and some perspectives concerning the
orientations of the internship.

2
2.1

Machine-to-Machine Applications
Denition and generalities

Machine to Machine (M2M) is a term used to describe the technologies enabling computers,
embedded processors, smart sensors, actuators and mobile devices to communicate with a remote
server or device in order to monitor some physical phenomena, to take measurements and to make
decisions without or with limited human intervention [2]. Thus, their main purposes consist in
remotely conguring the machines (telematics), remotely monitoring and collecting data from
machines (telemetric) and processing collected data to make decisions and send notication in
1
3GPP is a collaboration between groups of telecommunications associations that aim to standardize the 3G
and the 4G Mobile systems to come through LTE and LTE advanced. It is composed of European Telecommunications Standards Institute (ETSI), Association of Radio Industries and Businesses/Telecommunication Technology
Committee (ARIB/TTC, Japan), China Communications Standards Association (CCSA), Alliance for Telecommunications Industry Solutions (ATIS, North America) and Telecommunications Technology Association (TTA,
South Korea).

Figure 1: A general architecture of a M2M application

unusual situations [3]. In the literature, M2M are also called Machine Type Communication or
MTC for abbreviation (name given rst by the 3GPP).
In an informal way, MTC is a form of data communication which involves one or more entities
that do not necessarily need human intervention [4].
In a practical scenario, a common M2M application uses a device (sensor, meter...) to capture
an event (temperature, inventory level, etc.) by converting analog measurements to digital data,
more precisely IP packets. The digital data is sent through a network (wireless, wired or hybrid,
UMTS, LTE..., depending mainly on the required QoS [5] and the cost) to an application (software
program) called a server 2 . The latter translates it into meaningful information (data stored,
threats detected...) [6, 7]. Afterwards, answers could be sent back to the devices.
The devices involved in a M2M application and having the required skills for doing it (replaying
to requests and/or sending data by themselves) are called M2M devices (or MTC devices) [4].
A generic and simple architecture of a M2M application is illustrated in Figure 1. The
architecture is composed of mainly three parts, M2M Device Domain containing the M2M devices,
Network Domain which relays the messages to servers located in the Application Domain, giving
data to business applications the devices are deployed to. The network domain could be UMTS
or LTE as we will see it in details later.

2.2

Application elds of M2M applications

The main goal of M2M applications is to automatize everyday life process and take advantage of
delegating tasks to machines. Hence, they are applied in a couple of elds ranging from military
to civil domains, for security, health, monitoring....etc. A classication of the main use cases is
given in [8]. The most relevant are:
1. Track and trace use case: commonly in automotive applications where M2M embedded
modules exist in vehicles like in:
Emergency call where the embedded M2M modules send alert messages as well as
additional information (location...) to an emergency center in case of accident for
instance. The latter will send the needed support.
Fleet management where the embedded modules send data related to their position
and weather or trac to a central server (belonging to a company for instance). The
latter will make decisions and, maybe, dictate the way or any changes to the vehicle
Theft tracking where in case of stolen vehicle, it could be recovered thanks to localization information given by the embedded module
2

Note that some other practical scenarios may involve only devices.

2. Monitoring use case: commonly in monitoring and controlling consumption (power,...),

monitoring animals or assets :
Metering or prepaid delivery of utilities where M2M modules are installed on metering
devices helping a central entity to have a real time information about the consumption
of the users, and hence, adapt the production in consequence (for example to save
energy). It could be used also in case of prepaid resources like gas. The M2M will
receive the amount paid by the supplier and stop the supply once the amount is
consumed.
Animals, persons or any other objects equipped with M2M modules that send data
related to their location helping a central server to do some statistics (migration in
case of animals...) or detect dangerous situation (in case of persons for instance).
3. Control use case: Controlling vending machines where embedded M2M modules send data
about their status (ll-level, malfunctions...) and can be updated automatically (sending
new prices to the machine from a remote server of the company...). The same could be said
about controlling the production machines.
4. Home automation use case: where the M2M application are very useful for security, health,
energy eciency.
For energy eciency where sensors will detect a non presence in a room and then
switch o the lights, or other equipments, for example . Those sensors are connected
to a M2M gateway which may take the decisions of switching o. This decisions can
also be taken by a remote entity.
For security matters where re detectors can be installed, for example. Equipped with
M2M modules, they send alerts in case of re or after an intrusions detection.
5. Health care use case: where persons suering from heart disease, for example, can be
equipped with M2M modules that send real time informations in case of a heart attack.
This can help giving support in case of emergency.
As we have mentioned, the list is not exhaustive and other use cases could be imagined.

2.3

Properties of M2M applications

M2M communications dier from H2H communications since a service in MTC is based on
data communications which can be part of dierent business scenarios. They are, in general,
characterized by some properties making them very dierent from H2H applications. The main
properties are [4]:
Large number of devices: Typical applications require a lot of devices deployed in the same
area leading to high density or distant leading to a large spread.
Devices can send and/or receive frequently or infrequently small amounts of data.
Low mobility for devices meaning that they dont move, move infrequently or move in a
predened region.
Reduced costs as these applications are used in everyday life and may involve a large number
of devices.
Devices may be grouped into Groups. This is interesting for charging, policing and multicast
(toward a group).
Devices should require ultra low power consumption.
4

 Time tolerant (generally), since data can be usually delayed. However, real-time transmission should also be considered for some applications.
Time controlled as the devices may send and receive data only at certain periods of time.
Security of exchanges between the devices and the server.
To summarize, M2M communications involve a huge number of cheap and low-power devices
which generate a small amount a trac. These properties make M2M applications dierent and
quite challenging in terms of deployment and management.

LTE, Long Term Evolution Networks

LTE or Long Term Evolution is the technology that will replace the 3G which is actually deployed
around the world. It is a standard led by 3GPP and one of the best candidates for the future
4G networks. We will present in this section a brief historical evolution of the cellular networks,
some denitions and a global view and mechanisms of the LTE architecture.

3.1

Brief historical evolution of cellular networks

In a cellular network, a service coverage area is divided into cells, each of them is served by a
Base Station (BS). The BSs are interconnected by mean of wired connexions in general. Cellular
networks have evolved from the rst generation analog systems (1G) to the LTE and LTE advanced in the last few years and the years to come. The major steps are summarized in Figure
2. Through all the evolutions and the enhancements to come, the main targets are: increasing
data rates, improving spectrum eciency and coverage, better QoS support, lowering the devices
cost, reducing the latency and optimizing data-packets while supporting multiple Radio Access
Technologies.

Figure 2: The 3GPP cellular networks evolution

3.2

Overview of the LTE network architecture

When moving from 3G to LTE, a lot of changes have been made in the radio part to speed up
the equipments and to provide more bandwidth. From the Release 8 of 3GPP, the interest was
given to the core network part to improve its scalability and to minimize the end-to-end latency
by reducing the number of elements in the network. The global architecture of an LTE network
is illustrated in Figure 3.
In contrast with the previous cellular networks, LTE has been designed to support only packetswitched services. It aims to provide seamless Internet Protocol (IP) connectivity between the
User Equipments (UE) and the Packet Data Network (PDN), without any disruption to the end
user applications during mobility [9]. It is also designed to provide seamless inter-working with
existing 3GPP and non-3GPP radio access technologies [10].
The network is comprised, of two parts: The E-UTRAN (Evolved UMTS Terrestrial Radio
Access Network) and a EPC (Evolved Packet Core Network). The evolution of the non-radio part
is sometimes referred to as System Architecture Evolution (SAE), which includes the EPC. The

Figure 3: The LTE Global architecture

whole is often referred to as the Evolved Packet System (EPS). Those parts are (see [9, Chapter
1] and [11, Chapter 1] for more details):
1. E-UTRAN part: It is composed of the UEs and the eNodeB. Compared to its predecessors, UMTS for instance (called UTRAN), eNodeBs are the BSs but a more sophisticated
version since they integrate functionalities like radio management which is in the Radio
Network Controller (RCN) for UMTS.
2. EPC part: It is the Core Network part in the SAE. It is responsible for the overall control
of the UE and the establishment of bearers between the UE and the PDN Gateways (For
simplicity, a bearer is a packet ow or tunnel between a UE and the PDN Gateway, we will
see it in more details see in section 3.3). Lets recall that it is IP-only network. It comprises
ve logical nodes :
PDN Gateway (P-GW): It insures the connexion with the IP Network of the operator.
It is responsible for allocating IP addresses for UEs and denes QoS enforcement and
ow-based charging according to PCRF rules. It, also, lters downlink packets into
bearers of dierent QoS and destinations (UEs). Furthermore, it is the anchor point
for internetworking with non-3GPP networks such as CDMA2000 and WiMAX.
Serving Gateway (S-GW): It serves as an anchor for data bearers when UE moves
from eNodeB to another (handover). It also holds data of downlink bearers when
UE is in idle state (turned o to save power, to release the radio bandwidth it uses
for others...) and while the MME re-establishes the bearer with the UE. Similarly
with P-GW, it serves also as an anchor, but this time, for internetworking with 3GPP
networks (UMTS, GPRS...).
Mobility Management Entity (MME): It is a key element in the LTE architecture as it
is responsible for processing signaling between UE and the Core Network. It assumes
functions related to both bearer management (establishment, maintenance and release)
and functions related to connection management (establishment of the connection and
security between the network and UE, authentication). It helps, as well, to reduce the
overhead in the radio network by holding informations about UEs, which ensures a
continuity when the UEs are in idle sates. These functions are handled by the Session
Management Layer in the Non-Access Stratum (NAS) protocol [12]
The Policy Control and Charging Rules Function (PCRF): It is responsible of the policy
control decision making and the management of the ow based charging functionalities
in the Policy Control Enforcement Function (PCEF). The latter resides in the P-GW.
6

Figure 4: The LTE Bearer Model

It provides the QoS authorization (QoS Class Identier (QCI) and bit rates) that
decides how a certain data ow will be treated in the PCEF (by the P-GW) and
ensures that this is in accordance with the users subscription prole.
The Home Subscriber Server (HSS): It is like a database of the users. It contains
informations about the users subscriptions. It could be the QoS prole or any access
restriction for roaming. It holds also the PDN to which user can connect as well as
dynamic information such as MME to which the user is currently attached or registered.
These parts and components are interconnected using standardized interfaces as detailed in
Figure 3. This allows interoperability between dierent manufacturers.
The main goal of the specications issued by 3GPP is to simplify the architecture. Indeed,
in UMTS, UTRAN is the part of the UMTS network composed of NodeBs and RNCs. These
two components, in the radio part, are responsible of connecting the User Equipment (UE) with
the Core Network of the operator. However, in LTE, the RNCs are merged with NodeBs to
get eNodeBs. These eNodeBs are organized in a atter architecture and interconnected between
them. Another enhancement is to separate user plane (mainly the data) from control plane
(signalization). Hence, the MME manages the control plane whereas the user plane bypasses the
MME to go directly to S-GW [13] as illustrated in Figure 6.

3.3

LTE network in action: Trac Management

The EPS uses the concept of EPS bearers, or bearers for short. A bearer is an IP packet ow
with a dened quality of service (QoS), to route IP trac from a P-GW to the UE and vice
versa. Said dierently, it is a tunnel from the UE to the P-GW for a bidirectional trac. The
establishment of bearers is done by the MME, as required by applications [9]. Moreover, between
the UE and the P-GW, a bearer should cross dierent interfaces and in each interface it crosses,
it is mapped onto a lower layer bearer [9]. The general schema is illustrated in Figure 4.
The bearers are the level of granularity for QoS management and uniquely identies packet
ows that receive a common QoS treatment between the UE and the P-GW. Note that the QoS
can be negotiated by the UE or by the network [14].
Furthermore, multiple bearers could be established for a UE in order to provide dierent QoS
streams or connectivity to dierent PDNs. For example, a user might be engaged in a voice call
(VoIP) while performing web browsing or FTP download at the same time. A VoIP bearer would
provide the necessary QoS for the voice call, while a best-eort bearer would be suitable for the
web browsing or FTP session [9]. So, the bearer represents a separator that enables dierent QoS
treatment of ows. Moreover, its associated signaling allows resource reservation before packet
ows [14].
Technically, an IP packet for a UE is encapsulated into an EPC-specic protocol and tunneled
between the P-GW and the eNodeB for transmission to the UE. Dierent tunneling protocols are

used across dierent interfaces. However, a 3GPP-specic tunneling protocol called the GPRS
Tunneling Protocol (GTP) is used over the EPS interfaces, S1 and S5/S8 (see gure 3).
Practically, once a UE connects to the network, a default bearer with a default QoS is established thanks to an IP address given by the P-GW. The QoS of the default bearer is assigned by
the MME based on informations provided by HSS [9].
Regarding the trac management, it is ensured in the EPS by mean of predened classes of
QoS for established bearers. They are a set of parameters describing the performance characteristics of the corresponding bearers. They are mainly :
QoS Class Identier (QCI) which can be Conversational, Streaming, Interactive or Background
Allocation and Retention Priority (ARP) which indicates the priority of the bearers compared to the other bearers. It helps allocating resource accordingly to the priority of the
bearer and helps also in preemption (when bearers should be dropped)
Maximum Bit Rate (MBR)
Guaranteed Bit Rate (GBR) which represents the Minimum bit rate for the bearer
Aggregate Maximum Bit Rate (AMBR) which represents the Maximum bit rate shared by
a group of non-GBR bearers (of the same UE)
The control and management of QoS is performed by a Policy Charging and Control (PCC)
module which is composed of the Policy Control Resource Function (PCRF) and the Policy Control Enforcement Function (PCEF). The PCRF makes decisions based on policies established
by network operators based on subscriber proles in the HSS. Then, these decisions are communicated by to the PCEF (residing in P-GW). Finally, they are translated into QoS rules for
individual service data ows and enforced on the data plane in the PCEF and the P-GW.

Machine-To-Machine applications over LTE

Today, there are more devices than humans and they are spread over the world. They have more
value when networked in a context of M2M. Also, according to Metcalfes Law, the value of a
telecommunications network is proportional to the square of the number of connected users of
the system [7]. Unfortunately, connecting those devices is a great challenge, mainly because of
their location (inaccessible regions,...).

4.1

Concept and motivations

Mobile Network Operators (MNO) have already a large coverage deployed infrastructure for
transporting users data. Hence, they can play a more direct role by carrying the data exchanged
between remote devices and servers for M2M applications [7]. The benet is for both M2M
applications and MNO [5]. In one direction, M2M applications over cellular networks will create
much more revenue opportunities for MNO. In the other direction, M2M applications will take
benet of an already widely deployed infrastructure with rich services avoiding a cost of deploying
a dedicated one. This is benet for M2M applications that require mobility and high data rates
with easier installation, especially for short time deployments [15]. Furthermore, it will also open
new perspectives for device manufacturers and application developers [16].
However, the M2M applications are designed to allow communication between machines, so,
they dier from H2H applications that the cellular networks are designed for. They are mainly
characterized by data communications requiring lower costs and eort with potentially a very
large number of communicating terminals with a large extent and little trac per terminal.
Hence, they need to adapt to the huge amount of devices in MTC and provide QoS in respect to

(a) MTC server in MNO domain

(b) MTC server outside MNO domain

(c) MTC Devices to MTC Devices

Figure 5: M2M applications in 3GPP networks

dierent applications. For instance, alert messages should be carried with time constraints while
video streaming application should be provided with a guaranteed bandwidth.
3GPP is leading the standardization process to enable deployment of M2M applications in
cellular networks (LTE since release 8). In fact, 3GPP have checked the feasibility of using 3G
networks as well as LTE in the context of M2M applications. The enhancements and pre-requisites
for the network to satisfy are discussed in [4] and earlier versions. Furthermore, the main issues
of security and subscription change for devices are discussed in [17] (Starting from Release 8). As
we described the M2M applications in the rst section, and in the context of MTC applications
deployed on top of a cellular network (UMTS then LTE), a MTC Device communicates through
a PLMN (Public Land Mobile Network) with MTC Server(s) and/or other MTC Devices [4].
Three possible scenarios may exist, they are illustrated in Figure 5. A common application is
composed of set of MTC devices and one or more servers. These servers can be under the control
of the MNO or outside the MNO domain controlled by a third party with interfaces to access
the PLMN. In addition to those two scenarios, MTC devices can communicate directly without
passing through a server. However, this last scenario is not considered in the 3GPP standards
[18].
The underlying LTE network provides the necessary raw support for the devices and the
servers. It consists in the 3GPP bearer services to transport the trac from and toward the
devices, the IMS (IP MultiMedia Subsystem) to support cases where servers are not under the
control of the MNO and the SMS service (Short Message System) optimized for MTC applications.
Such deployment on top of LTE networks will add value and functionality to the devices and
is the result of a combination of synergies between device manufacturers, application developers
and mobile operators [16]. However, it is quite challenging since it rises new problems not posed
(or posed dierently) in the LTE networks before.

4.2

Challenges and eorts

Earliest deployments of M2M applications on cellular networks were based only on SMS [5].
Today, they are more evolved with the arriving of packet core networks and, thus, IP packets are
directly used. However, SMSs is still remaining, in some cases, for signaling and breaking idle
states of devices.
The current mobile networks are optimally designed for H2H communications, but are less
optimal for M2M, M2H, or H2M applications. In fact, human users are intelligent and can make
decisions. The resilience of the underlying infrastructure is, generally, underpinned by the human
ability to make decisions to recover from adverse conditions, like rebooting the device for example
[19]. Hence, deploying M2M applications that are characterized dierently (see section 2.3) is
not trivial. In fact, the PLMN should provide the necessary support for large amount of devices
to communicate despite their location. Moreover, the network should, de facto, hold a part of
the application [19], like the localization of the devices in case of mobility which is transparent to
the applications. It, thus, becomes involved in the application. In addition, it should reduce the
costs and eorts and ensure the security constraints posed by applications. It is also important
to enable network operators to oer MTC services at a low cost level, to match the expectations
of mass-market machine-type services and applications [4].
Consequently, a reexion lead by 3GPP around these aspects have given birth to a series of

specications which aim to increase the Quality of Service and the Quality of Experience. This
should pass by the specication of requirements and enhancements in the mobile networks (LTE)
to overcome those challenges. In [8] (and since release 8), the enhancements for the system are
being dened. They didnt solve the problem yet but they are still in way. In [8], 14 system
improvement points have been dened by 3GPP. The most important of them are :
Packet switched network only in the Core Network part
Mobile originated communications only or infrequent mobile terminated. This means that
the communications with the servers are, in most of the cases, initiated by the devices and
rarely by the servers
Priority Alarm Message (PAM) for the need of immediate attention, for example in case of
a stolen device
Security of exchanges between the MTC devices and the server despite of roaming (changing
the location and the access network as well)
Group based communication, addressing and policing
Reduce the resource usage for low mobility devices
Some pessimistic predictions say that LTE will not be sucient to handle all the trac and
oer a required QoS for the growing trac in mobile networks. Consequently, multiple access
technologies would be needed. In this context, M2M applications will add some more challenging
issues since they are deployed by thousands of devices and adding alternative technologies costs
much in terms of deployment. Moreover, the main issue is congestion and overhead in both user
plane (data) and control plane (signaling) as we discuss it in the next section.

Congestion control of MTC in LTE networks

5.1

The core problem

The congestion is the core problem of LTE and all networks today. It is not about speed but
capacity. This means that manufacturers are developing devices with high data rates, boosted
by enhancements introduced in the radio access technologies. The real problem today for a user
application resides in the Round Trip Time (RTT) or the latency. It is increasing since the amount
of exchanged data and signaling grows and congestion is appearing in both the E-UTRAN and
the EPC.
In the context of M2M applications, the problem is posed dierently. Indeed, the applications
are mainly characterized by a huge amount of devices that communicate frequently or infrequently
by small amounts of data. These devices for a given application are deployed in a small area
(home automation for instance). Thus, they are on competition in the same nodes of the network
(eNodeB, MME, S-GW, P-GW, HSS). Consequently, a lot of devices trying to connect at the same
time (generally application dependent) is frequently happening in M2M applications, leading to
peaks in signaling and data. This penalizes the non M2M devices. Hence, and regarding the
architecture of the network, the congestion can appear at dierent levels as illustrated in Figure
6:
Radio network part: It appears commonly in eNodeBs where a lot of devices are connected
to the same eNodeB and consequently use the same channels, leading to collisions.
Evolved Packet Core Network part: It appears in the dierent nodes of the network, mainly
in MME responsible of managing the attachment of devices, S-GW in charge of carrying
the trac and the P-GW (A lot of devices will send and receive trac through the same
P-GW). It can also concern the HSS responsible for managing the subscriptions, since each
10

Figure 6: The congestion problem for MTC applications in LTE

attachment of a device requires a procedure that involves the HSS, leading to congestion
when a lot of devices have registered to the same HSS. Another problem is caused by the
overhead of managing bearers between UE and the P-GW. A lot of devices means a lot of
bearers used for small periods of time, leading to an overhead for managing them by the
MME mainly.
Regarding the nature of the trac and the cause of congestion, we can mainly distinguish
two classes: Congestion in the user plane and in the control plane. This separation is motivated
by the fact that those planes (user and control) are separated in the EPC in LTE (Figure 6).
Data trac congestion (Data plane): It is caused by the amount of data sent and received
by devices. In the context of MTC, this happens rarely since devices send and receive small
amounts of data. But it may frequently happen that a lot devices send their data at the
same time leading to a congestion mainly in the EPC part. Even if the amount of data per
terminal is small, the sum of all the devices can lead to congestion.
Signaling congestion and overhead (Control plane): It appears in all the architecture. It is
mainly due to the fact that the devices continuously generate signaling trac to attach to
the network, when triggering from the server, send data, send alerts, bearer management...
Note that even if the devices send small amounts of data, they generate normal amounts
of signaling, which causes overhead and congestion in MME mainly, and in all the other
nodes.
Hence, the network should be able to deal with small amount of data when transferring
without generating an overhead [4, 8]. Moreover, the network should be able to instruct the
MTC devices to reduce their mobility management function as well as other mechanisms as we
will see it in the next section.

5.2

Related works

MTC applications is a new topic and its deployment in LTE is challenging and remains an open
issue. Excepting the 3GPP group contributions (e.g. standardizing MTC operations in LTE),
only few works and a small amount of publications addressed this issue. Likewise, the congestion
caused by MTC in LTE networks (3G and LTE) is not well addressed in the literature.
Congestion in LTE (UMTS or cellular networks in general) has been addressed in literature.
Most of the works deal with scheduling algorithms in the radio part and channel reservation
[20, 21, 22] or even pricing policies [23]. Higher in protocol stack, the authors in [24] proposed an
enhancement for TCP (TCP-FIT) to reduce and leverage the congestion. At a dierent level and
more directly related to MTC, an architectural proposal was given, in [18], to deal with the notion
of Group based trac management. It described a technique and an algorithm to build groups
in the devices area. The groups are organized in a hierarchical way and all communications and
11

signaling pass through a cluster head to reach the eNodeB and the core network. This reduces
the signaling overhead and the trac congestion thanks to the aggregation mechanisms in the
groups. Note that the Group based technique is biased with report to the Group based concept
introduced by 3GPP [1] since it is build in an Ad-Hoc manner, using Bluetooth technology for
communications between the devices belonging to the same group.
However, the eorts of ETSI and 3GPP are the most interesting and they are in continues
progress throughout the dierent specications. Since release 8 [4, 8, 1, 25, 12, 26], the members
propose architecture evolutions and enhancements at dierent levels in LTE networks (and even
in UMTS) to simplify the integration of MTC applications and provide them with the needed
support. The same specications propose what could be the directions toward an ecient management of congestion, the most important of them are:
Group based mechanism of devices: The idea is to group devices into Groups. Each Group
is managed in a dierent way and independently from the other groups. This can reduce
the signaling overhead and simplies the devices management in terms of trac, policing
and charging. For instance, the members of the same group can communicate seamlessly,
regarding the PLMN, by using a Round Robin scheduling algorithm. Also, they could be
seen as being one entity regarding the charging (one subscription per group). However,
technical specications clearly indicate that each device should be visible from the network.
It is also stated that belonging to a group should be known by the Core Network (the HSS
mainly).
In case of triggering the devices (a server sending alerts to devices for instance) and where
devices are not mobile, the location is generally known by the application. So, the network
can use such kind of information given by the application to reduce the overhead. In fact,
it sends alerts to devices in the dened region given by the application and the network will
just carry messages instead of managing the localization of devices [4]
Build a time controlled policy where devices are provided granted and forbidden periods
(see [26] for more details). In the granted periods, devices can attach to the network and
communicate while this is not allowed in forbidden periods. Furthermore, a communication
window is assigned to the devices to limit the overhead. This means that a short period of
time (window) in the granted period is assigned to a device to communicate as illustrated in
Figure 7. Moreover, in this case, randomized triggering of devices in the access periods could
be performed to avoid lot of devices accessing the network at the same time. This means
that the assignment of communication windows will be done in a random way to avoid lot
of windows overlapping or starting at the same time. Also, and for low power consumption
devices, the granted periods could be given after moving (Traking Area Update/Routing
Area Update), and thus, the device can turn the radio o when not moving (6.17 in [26]).
However, for the last point, in case of frequently moving devices, the number of granted
periods should be reduced and the invert for low mobile ones. Furthermore, this is adapted
only to delay tolerant applications.

Figure 7: Time Controlled Policy [8]

Reject connection requests at dierent levels in case of congestion. The rejection can concern
requests targeting a particular P-GW, belonging to a group or of a given application [26].
The rejection could be done, also, using priorities (see sections 6.23 and 6.26 of [26] for
more details). The bearers and the trac in general is given a priority and the trac of
12

lower priority is rejected in cases of congestion. The rejection could be done at eNodeB
level by mean of indications received from MME (OVERLOAD START), at the S-GW
or the P-GW. The usage of priorities gives the radio access network a good criterion to
select the requests to reject which ensures saving the networks resources (MME, S-GW,...).
The rejection message is (could be) sent to the Device with a back-o time with possibly
a notication telling the rejections reason. The Device can, then, change its strategy
according to the indication and shouldnt send its request again until the end of the backo time. Furthermore, the back o time should be randomized to avoid simultaneous access
of devices with the same priority, for instance. This can happen if the network rejects the
requests of a group and gives them same back-o time. When the back-o time ends, they
all try to connect at the same time, which can cause congestion.
Note that the decision of connections rejection can be taken by the eNodeBs or by the EPC
nodes concerned with the congestion (MME, S-GW, P-GW).
Broadcasting MTC access barring by the eNodeB if the congestion occurred or expected
to occur in the network [26]. This is used to eciently bar all MTC Devices, low-priority
MTC Devices, and/or MTC Devices of a given group from attempting to attach to the
network. In opposition to the rejection strategy, no resources are used since the devices are
not attached in this case. However, this doesnt prevent congestion from re-appearing if the
devices try to attach at the same time after that the barring is over.

Discussion
As mentioned, only few works in the literature address the congestion problem in LTE networks.
These contributions, which deal with congestion in LTE in general, dont solve the problem
of MTC applications since they operate in the radio part of the network. In fact, for MTC
applications the problem of congestion is mainly observed in the core network part. For instance,
a lot of devices belonging to the same application but not attached to the same eNodeBs can
communicate at the same time, which leads to congestion in the Core Network part (MME or PGW) instead of the radio part. Also, some of the proposed solutions for upper layers (the example
of [24]) is not enough for M2M applications which poses other problems like signaling congestion.
Furthermore, the presented results are adapted only for some restricted scenarios (video transfer
applications [24]). The solution provided in [18] is more interesting than the previous ones but,
lacks of standardization and adds a bias. In fact, it adds a proprietary grouping technique in
the devices side. Moreover, it assumes that the devices are equipped with other communication
technologies (Bluetooth) which is not always possible (adding technologies makes the devices
expensive and consuming more power).
For 3GPP, the eorts are still in progress toward a standardization. Until now, few concepts
are validated and modications are still to come due to improvements. Furthermore, some concepts are still theoretical and may arise some problems in practical uses cases. For instance,
rejecting trac belonging to an application causing congestion is still an open issue, since we are
not yet able to detect to which application the trac belongs and the case where an application
is causing congestion. In addition, the proposed enhancements for 3GPP are given without the
real results and drawbacks they could have. Most of them require more architecture work to be
able to progress solutions based of them, for instance Group based feature [26]. Furthermore,
they are given as separated specications, which are not studied to work together. This means
that combining them is not really easy, or even impossible.
Finally, no measurement of the impact of M2M on Cellular Networks exist in literature. Although some works addressed the same issue, they didnt provide results regarding the congestion
caused and the performances in the underlying 3GPP network. This is the case in [18] where
the measurements are done in the heads of groups (the amount of sent data) and not in the core
network (UMTS or LTE in their case).

13

Conclusions and goal of the internship

M2M applications are applications that involve devices without human intervention. They are
used in a couple of elds ranging from security to home automation applications passing by health
care, environment and trac management. Their deployment on top of existing and widely
deployed infrastructure like cellular networks (LTE) is interesting for both MNO, application
developers and users. However, cellular networks and the exchanged data are growing at a
hallucinating speed. Deploying M2M applications in LTE networks add more complexity to the
existing architecture. It is, thus, a challenging issue, since applications are characterized by a
huge number of devices that can communicate at the same time or that compete on the same
resources in the network. They are completely dierent from H2M, M2H and H2H applications
for which the cellular networks are deployed. This poses problems on top of which we highlight
the congestion problem due to the amount of trac generated by devices. The congestion may
concern both the radio and the EPC parts and it is due to data (User plane) and/or signaling
(Control plane).
In literature, few works have addressed this new issue. The existing approaches mainly deal
with congestion in the radio part which is not sucient in the context of MTC since the congestion concerns also and more critically the EPC nodes. Other works propose proprietary biased
solutions which lack of standardization. The most interesting works are the eorts of the 3GPP
toward standardizing the deployment of MTC applications in 3GPP networks (mainly UMTS
and LTE). It issues specications since release 8, for enhancements in all the network (UMTS or
LTE) to make it able to give the needed support for MTC applications. It highlights the problem
of congestion in the Core Network and gives some directions that aim to solve it. However, those
specications are a general view of what could be the directions, not a detailed approaches and
no result regarding their impact on reducing congestion is given.
In this internship, we will go through the problems posed by this deployment and we will
propose our approach to deal with congestion in the context of generic M2M applications characterized by a huge number of devices communicating at low rates, and with reduced mobility. The
main direction to take is to enhance the specications of 3GPP, mainly the group management
and the time controlled mechanisms. Indeed, they are the two mechanisms that could eciently
reduce the amount of trac and the signaling overhead by involving the devices rst, much more
than the network. This helps to save the resources in the EPC part (MME,S-GW,P-GW) by
rejecting the trac in the radio part for example. This will be extended and enriched by the
usage of broadcast in the Radio part to inform the devices about the congestion in the network.
The solution will tackle mainly the problem of developing an ecient scheduling algorithm taking
into account the randomization in granted periods and the priorities of devices. This may pass by
a classication of applications and the design of a strategy to handle both MTC and non-MTC
devices.
Then, we will illustrate the developed solution through a use case study of a deployment
example. We will analyze and validate the results through simulations under OPNet.

References
[1] 3GPP website. www.3gpp.org.
[2] David S. Watson, Mary Ann Piette, Osman Sezgen, and Naoya Motegi. Machine to machine (m2m)
technology in demand responsive commercial buildings. In ECEEE press, editor, ACEEE Summer
Study on Energy Eciency in Buildings: Breaking Out of the Box, pages 2227. ACEEE, August
2004.
[3] Sudha Krishnamurthy, Omer Anson, Lior Sapir, Chanan Glezer, Mauro Rois, Ilana Shub, and Kilian
Schloeder. Automation of facility management processes using machine-to-machine technologies. In
Proceedings of the 1st international conference on The internet of things, IOT08, pages 6886, Berlin,
Heidelberg, 2008. Springer-Verlag.
[4] 3gpp ts 22.368 v10.1.0 (2010-06): Service requirements for machine-type communications (mtc). 2010.

14

[5] Mladen Sokele, Vlasta Hudek, and Alexandru-Ioan Mincu. Opportunities for implementation machineto machine services via 3g mobile networks. In Proceedings of the 7th International Conference on
Telecommunications, 2003. ConTEL 2003., volume 1, pages 9195. IEEE Computer Society, June
2003.
[6] Numerex website, http://www.numerex.com/.
[7] Bob EMMERSON. Perspective-m2m: the internet of 50 billion devices. European Editor of M2M
Magazine, January 2010.
[8] Etsi ts 102 689 v1.1.1 (2010-08): Machine-to-machine communications; m2m service requirements.
August 2010.
[9] Sudeep Palat and Philippe Godin. LTE The UMTS Long Term Evolution: From Theory to Practice.
Wiley publishing edition, February 2009.
[10] 3gpp ts 22.278 v9.2.0 (2008-12) service requirements for the evolved packet system (eps). 12 2008.
[11] Moray Rumney. LTE and the Evolution to 4G Wireless: Design and Measurement Challenges. Whiley,
May 2009.
[12] 3gpp technical specication 24.301 : Non-access-stratum (nas) protocol for evolved packet system
(eps); stage 3 (release 8). 12 2008.
[13] Dr Harri Holma and Dr Antti Toskala. LTE for UMTS - OFDMA and SC-FDMA Based Radio Access.
Wiley Publishing, 2009.
[14] Hannes Ekstrom from Ericsson. Qos control in the 3gpp evolved packet system. IEEE Communications
Magazine, pages 7683, February 2009.
[15] Standardization of machine-type communications v0.0.5 (2010-10). October 2010.
[16] Vania Goncalves and Philippe Dobbelaere. Business scenarios for machine-to-machine mobile applications. Mobile Business / Global Mobility Roundtable, International Conference on, 0:394401,
2010.
[17] 3gpp tr 33.812 v9.2.0 (2010-06): Feasibility study on the security aspects of remote provisioning and
change of subscription for machine to machine (m2m) equipment. June 2010.
[18] Kwang-Ryul Jung, Aesoon Park, and Sungwon Lee. Machine-type-communication (mtc) device grouping algorithm for congestion avoidance of mtc oriented lte network. In Tai-hoon Kim, Adrian Stoica,
and Ruay-Shiung Chang, editors, Security-Enriched Urban Computing and Smart Grid, volume 78 of
Communications in Computer and Information Science, pages 167178. Springer Berlin Heidelberg,
2010. 10.1007/978-3-642-16444-6 22.
[19] Steve Whitehead. Adopting wireless machine-to-machine technology. Computing and Control Engineering, 15(5):4046, 2004.
[20] Fei Yu and Victor Leung. Mobility-based predictive call admission control and bandwidth reservation
in wireless cellular networks. Comput. Netw., 38:577589, April 2002.
[21] Sunghyun Choi and Kang G. Shin. Predictive and adaptive bandwidth reservation for hand-os in
qos-sensitive cellular networks. SIGCOMM Comput. Commun. Rev., 28:155166, October 1998.
[22] Guohong Cao. Integrating distributed channel allocation and adaptive hando management for qossensitive cellular networks. Wirel. Netw., 9:131142, March 2003.
[23] Jiongkuan Hou, Jie Yang, and Symeon Papavassiliou. Integration of pricing with call admission
control to meet qos requirements in cellular networks. IEEE Transactions on Parallel and Distributed
Systems, 13:898910, 2002.
[24] Jingyuan Wang, Jiangtao Wen, Jun Zhang, and Yuxing Han. A demonstration of a new tcp congestion
control algorithm over lte and other challenging networks. ACM S3 2010 Workshop, Chicago, Illinois,
September 2010.
[25] 3gpp tr 36.306 v8.2.0 (2008-05) evolved universal terrestrial radio access network (e-utra); user equipment (ue) radio access capabilities. 05 2008.
[26] Technical Specication Group Services and System Aspects. 3gpp tr 23.888 v0.5.0 (2010-07): System
improvements for machine-type communications. (Release 10), July 2010.

15