Machine to Machine White Paper

WHITE PAPER

MACHINE-TO-MACHINE (M2M)—
THE RISE OF THE MACHINES

Copyright © 2011, Juniper Networks, Inc. 1

WHITE PAPER - Machine-to-Machine (M2M)—The Rise of the Machines

Table of Contents
Executive Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

Opportunities for New Business Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

M2M Network Architecture Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

Present-Day Networks and M2M Challenges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

M2M Standards Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

ETSI and M2M . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

3GPP and M2M . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3GPP M2M Communication Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

About Juniper Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

Table of Figures
Figure 1: Infonetics Research M2M connections forecast (2009–2014) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

Figure 2: Revenue per vertical. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

Figure 3: Inverting the pipe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

Figure 4: MNO and partnership model co-operation for M2M . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

Figure 5: ETSI M2M network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

Figure 6: ETSI use case technical reports reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

Figure 7: ETSI TS 102 690 system architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

Figure 8: Stage 3 for ETSI M2M Release 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

Figure 9: Overall 3GPP high-level M2M architecture approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

Figure 10: 3GPP M2M communication, scenario 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

Figure 11: 3GPP M2M communication, scenario 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

Figure 12: 3GPP M2M communication, scenario 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

List of Tables
Table 1: 3GPP Machine-Type Communication Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

Table 2: High-Level Domains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

Table 3: Differences Between H2H and M2M . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

Table 4: Standards, Specification Descriptions and References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

Table 5: ETSI M2M Network Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

Table 6: Major Components of 3GPP M2M Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2 Copyright © 2011, Juniper Networks, Inc.


Executive Summary
This paper presents a high- level view of a rekindled market for Machine-to-Machine (M2M) communications. M2M
communication can be agnostic to the access technologies and will uses a broad range of fixed and wireless technologies
(cellular, Wi-Fi, wireline, DSL, satellite or even serial with gateways). Several key requirements emerge as the industry adopts
the M2M applications toward the Internet of things. Juniper’s portfolio of mobility solutions, such as Juniper Networks®
MobileNext, Junos® Pulse for security, Junos Space for management and Junos SDK position the company for leadership in
this market:

• Mobile Broadband Gateway (MBG) and Mobile Control Gateway (MCG) address scaling aspect for M2M endpoints.

• Junos Pulse for security expertise helps prevent man-in-the-middle attacks by examining the option of providing
embedded lightweight Junos Pulse for M2M.

• Junos SDK provides an open API and facilitates third-party development and integration tailored to M2M/MTC.

This paper focuses on cellular M2M/MTC communications and describes current considerations by key standard
organizations directly looking into the technical challenges and network enhancements required to address these
opportunities. It is directed to the field force involved with mobile wireless service providers. Through this educational paper,
network administrators are introduced to the growing market need for cellular M2M infrastructure enhancements and
application services.

Introduction
Although cellular M2M communication has existed for some time now, it has been a challenging and niche market.

• Existing M2M solutions are fragmented and usually are dedicated to a specific single application:

• There are many different incumbent and legacy technical solutions that lack standard homogenization.

• There is a need for new revenue models to address generally small volumes of traffic from M2M applications.

According to several market research firms, this market is on an upward path as the M2M market is projected to grow
exponentially in the coming years.

Personal communication has evolved from traditional phone calls to today’s modern text messaging using Short Message
Service (SMS) or multimedia content through Multimedia Messaging Service (MMS). Cellular M2M communications for
2G/3G use similar types of mechanisms to send short data bursts of information to report residential utility meter readings,
locations for telemetry applications and also for remote upgrades/activations of machines such as parking meters.

Concurrently, advances in wireless technologies, wider availability of application services and the upcoming demands
created by regulatory and policy initiatives for some verticals such as utilities/smart grid—the EU recently issued a mandate
on Smart Metering (M/441) to the European Standards Development Organizations (SDOs) and the United States National
Broadband Plan (March 2010)—prompted the industry (M2M modem vendors, operators, standards, application providers)
to take a second look at this overall segment. The M2M ecosystem is developing and opening the doors for tremendous
opportunities beyond the “traditional M2M market segment.”

Figure 1 shows the predictions by Infonetics Research for M2M connections.

Embedded mobile M2M connections are forecast to reach 428 million by 2014

450
Connections in Millions

0
2009 2014

© Infonetics Research, Embedded Mobile M2M Modem Market Outlook, Oct. 2010

Figure 1: Infonetics Research M2M connections forecast (2009–2014)



Furthermore, Harbor Research projects M2M to reach 390 million connections by 2014. Although the projections are slightly
different from each market research firm, it is undeniable that the M2M market is significantly growing.

Other markets verticals—besides utilities/smart grid/energy/telemetry—include transportation and logistics, security/
surveillance, healthcare, retail/vending, consumers, and miscellaneous (including environment, education and military).

As depicted in Figure 2, Harbor Research shows its revenue projections per vertical.

Exhibit: Value-Added Application Services by Venue

$350,000

$300,000

$250,000 Security/Infrastructure
Healthcare
Millions

$200,000 IT/Networks
Transportation
$150,000 Retail
Buildings
$100,000 Energy
Industrial
$50,000

$0
2008 2009 2010 2011 2012 2013 Source: Harbor Research, Inc.

Figure 2: Revenue per vertical
Some of those verticals such as smart metering and healthcare are gaining popularity and are in early deployment stages.
They already contribute at changing the economics and user experience perception. For example, gas and electric utility
companies can reduce their costs by discontinuing meter readings by their prescribed employees. eHealth can offer an
improved patient experience for those who have limited mobility or remote access by providing vital sign status through
networked monitoring equipment associated with the patient’s identification.

There are many different MTC applications with distinct characteristics. As such, every optimization feature put forward is
not suitable for all MTC applications. In other words, there is not a unique set of requirements that can be applied to all MTC
applications. Network operators must be able to differentiate between their MTC devices to provide MTC features on a per-
subscription basis. Subscriber database information as well as Policy and Charging Rules Function (PCRF) will play a key role
in this.



Table 1 presents a non-exhaustive list of machine-type communication applications (3GPP TR 22.368).

Table 1: 3GPP Machine-Type Communication Applications
SERVICE AREA MTC APPLICATIONS

Security Surveillance systems
Backup for landline
Control of physical access
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
Vending machine control
Vehicle diagnostics
Metering Power
Gas
Water
Heating
Grid control
Industrial metering
Consumer Devices Digital photo frame
Digital camera
e-book

Table 2 lists ETSI’s high-level domains with associated examples of possible industry use cases.

Table 2: High-Level Domains
DOMAINS EXAMPLE

Security Surveillance application, alarms, tracking (object/person).
Transportation Fleet management, emission control, toll payment, road safety.
Healthcare Related to eHealth, personal well-being and security.
Smart Energy Measurement, provisioning/billing of utilities, metering.
Supply/Provisioning Freight supply and distribution monitoring, vending machines.
City Automation Public lighting, waste management.
Future Many more new domains to be developed.

Opportunities for New Business Models
M2M provides low Average Return Per Device (ARPD) but at the same time offers low churn (if any), making it possible for
operators and executives to design lucrative business models that offer services as the industry shows converging signs that
this market segment can emerge as a serious and significant opportunity.



The current marketplace is extremely fragmented, with many small, vertical and specific niche applications. Efforts are
underway to bring some level of normalization in the direction of moving away from the current siloed landscape to a more
horizontal integrated approach. Occasionally, some in the industry refer to this as “inverting the pipes and going to mass
market applications,” as shown in Figure 3.

Existing Proprietary Applications Share Common Infrastructure,
Vertical Applications Environments, and Network Elements
Business Business Business Business Business Business
Application 1 Application 2 Application 3 Application 1 Application 2 Application 3

Application Infrastructure

Existing Existing Existing Network Infrastructure
Mobile Mobile Mobile
Infrastructure Infrastructure Infrastructure

CONVERGED NETWORK
(IP and Mobile Infrastructure)
SIM based SIM based SIM based
Dedicated Dedicated Dedicated
Services Services Services

Gateway
Concentrators

M2M M2M M2M
Device Device Device

Figure 3: Inverting the pipe
Currently, until new business models develop, mobile network operators have traditionally teamed with partners in
an attempt to benefit from the M2M market segment. Figure 4 (following chart) shows what several operators have
accomplished with partnership models.

THE REVENUE OPPORTUNITY FOR MOBILE
CONNECTED DEVICES IN SATURATED MARKETS

New business unit “Telenor Objects” and co-operation TELIT
TELENOR withTelit and Volvo for in-car SIM card
VOLVO

Echelon and T-Mobile alliance to reduce the cost of a secure CELEVOKE
T-MOBILE smart grid network for utilities; also co-operation with Celevoke
to sell wholesale data services to M2M clients ECHELON

Co-operation with OnStar/GM, also Verizon Wireless and Qualcomm QUALCOMM
VERIZON WIRELESS announce joint venture to provide advanced M2M solutions (nPhase)
ONSTAR BY GM

Emerging devices business unit launched in October 2008;
AT&T combined platform with Jasper Wireless JASPER WIRELESS

“Orange M2M Connect” platform; strategic partnerships with WAVECOM
Wavecom, Alcatel, and Cinterion, Orange (France and Spain) are
ORANGE co-operating with Securitas Direct to use wireless GSM network CINTERION
for more advanced surveillance solutions SECURITAS DIRECT

New M2M platform July 2009, Vodafone Spain also co-operates
VODAFONE with Securitas Direct SECURITAS DIRECT

TELEFONICA Telefonica’s Smart M2M platform in co-operation with Telit TELIT

Source: Northstream white paper, February 2010

Figure 4: MNO and partnership model co-operation for M2M



M2M Network Architecture Considerations
This section discusses M2M network architecture considerations both in terms of suitability of existing wireless networks in
supporting M2M applications as well as new architectural enhancements as proposed by standards bodies, such as 3GPP, to
efficiently support M2M applications.

Present-Day Networks and M2M Challenges
The current mobile networks (3GPP/2) primarily are designed for human-to-human (H2H) communications—voice call
(SMS/MMS) and server-to-human (downloading/streaming). However, these technologies might not be optimal for M2M
application services.

M2M networks are defined as communication without or with limited human end user intervention. Note that the human end
user is not typically the initiator of the input but only occasionally and optionally the recipient for the output.

Table 3 summarizes the differences between H2H and M2M.

Table 3: Differences Between H2H and M2M
TOPICS H2H M2M

Density Wireless devices’ penetration rate is increasing. There M2M outnumbers human end users by order of
are a lot of us. But maybe not that much compared to magnitude. 3GPP SA1 requires solutions to cater for
M2M potential. at least two orders of magnitude. Another possible
reason for IPv6. Possible shortage of phone numbers.
Data Volume Most of the traffic is downloaded and requires Traffic is mainly uploaded and most of it requires
significant amounts of bandwidth (file, Web and small amounts of bandwidth (video surveillance
video streaming). might require more).
Battery We can buy a new one—we can recharge. It must be capable of auto-generating power or be
self-sustaining for long periods.
Delay We do have a tolerance for it even when it comes to Some applications are mainly for real-time control;
voice. urgent/emergency action would have little tolerance.
Security Worth comes to worth. Instinct tells us or we just Not so much here. Robust security, even
know if it has been stolen. confidentiality ought to be available. New
considerations are being made regarding Machine
Communication Identity Module (MCIM) in Universal
Integrated Circuit Card (UICC) or Trusted Environment
(TRE).
Revenue Good. Low ARPD.
Dimensioning Normal business case. High level of endpoints connecting from time to time
(can be predefined) to transmit small amounts of
data. However, control network overload aspects
must be considered.
Value Chain Well defined. To be created/adapted for new opportunities on top
of common infrastructure.
Reachability Satisfying. Push/pull behavior. Might require much longer
dormant period to minimize signaling on control
plane.

Using Table 3 as a reference, it is apparent that M2M and H2H traffic patterns are quite different and accommodations and
optimizations are needed in current networks for M2M while maintaining or at least not disrupting existing H2H services.



M2M Standards Status
The European Telecommunications Standardization Institute (ETSI) and 3rd Generation Partnership Project (3GPP) are two
main standard groups that have been investigating M2M’s challenges, issues, gaps, and architectures. To a lesser degree, WiMAX
forum is also looking at M2M. Table 4 summarizes the two standards and associated specification descriptions and references.

Table 4: Standards, Speciﬁcation Descriptions and References
STANDARDS SPECIFICATION DESCRIPTION SPECIFICATION REFERENCE

ETSI M2M Functional Architecture ETSI TS 102 690
M2M Service Requirements ETSI TS 102 689
Smart Metering Use Cases ETSI TR 102 692
eHealth Use Cases ETSI TR 102 732
Automotive Applications Use Cases ETSI TR 102 898
City Applications Use Cases ETSI TR 102 897
M2M interfaces mIa, mId, dIa ETSI TS 102 921
3GPP SA1- M2M Study Report 3GPP TR 22.868
SA1- MTC Service Requirements 3GPP TS 22.368
SA2 - System Improvements for MTC 3GPP TR 23.888
SA3 - M2M Security Aspect for Remote Provisioning and Subscription Change 3GPP TR 33.812
SA3 - Security Aspect of MTC 3GPP TR 33.868
3GPP Study on RAN Improvements for MTC 3GPP TR 37.868
3GPP Study on GERAN Improvements for MTC 3GPP TR 43.868

ETSI and M2M
In 2009, ETSI created a Technical Committee (TC) whose goal is to develop M2M standards. Release 1 planning stages are
as follows:

Stage 1 (requirements)—Q3 2010

• Based on several M2M use cases

Stage 2 (architecture)—Q3 2011

• Key capability identified

• Message flows documented

• Key interfaces identified for Release 1 Stage 3 (detailed specifications)

Stage 3 (protocol)—Q4 2011

• Working on three main interfaces—mId, dIa and mIa.



Figure 5 depicts the high-level architecture concept that ETSI proposes for M2M application support.

M2M
Application M2M
Area
Network

Service M2M
Capabilities Gateway

Client M2M CORE
Application

APPLICATION NETWORK M2M DEVICE
DOMAIN DOMAIN DOMAIN

Figure 5: ETSI M2M network
Using Figure 5 as a reference, Table 5 lists and defines the major components that comprise the ETSI M2M network
architecture.

Table 5: ETSI M2M Network Architecture
MAJOR COMPONENTS DEFINITION

M2M Device Is capable of replying to requests for data contained within those devices or
capable of transmitting data contained within those devices autonomously.
M2M Area Network (device domain) Provides connectivity between M2M devices and M2M gateways— wireless
personal area networks (WPANs), Wi-Fi, Zigbee/802.15.4, Bluetooth and RFID.
M2M Gateway Uses M2M capabilities to ensure M2M devices are interworking and inter-
connected to the communication network.
M2M Communication Networks (network domain) Involves communications between the M2M gateways and M2M application
(3G, LTE, WiMAX, WLAN, and wireline).
M2M Applications Contains the middleware layer where data travels through various application
services and is used by the speciﬁc business-processing engines.



Figure 6 shows a reference to the ETSI use case technical reports, covering many types of industries from smart metering and
eHealth to city automation.

Source: ETSI MWC Barcelona Feb. 2011.

Work Methodology
TR 102 692 TR 102 732 TR 102 857 TR 102 898 TR 102 897
Smart eHealth Connected Automotive City
Metering Consumer Automation
PUBLISHED

TS 102 689
TR 102 920 M2M Service TR 102 725
Delivery of STAGE 1 Requirements M2M Deﬁnitions
M/441 Work PUBLISHED

TS 102 690
M2M
STAGE 2 Functional
TR 102 935 TR 101 531 TR 102 167
Architecture
Smart Grid Re-use of Threat Analysis and
Impacts on M2M 3GPP Nodes Counter Measures
by M2MSC Layer to M2M Service Layer
TS 102 921
M2M Communications;
STAGE 3 mia, dia, and
mid interfaces

Source: ETSI MWC Barcelona, February 2011

Figure 6: ETSI use case technical reports reference
The M2M device domain includes:

• M2M device

• M2M area network

• M2M gateway.

The network and application domain includes:

• Access network

• Transport network

• M2M core

• M2M applications

• Network management functions

• M2M management functions.



Figure 7 depicts the high-level system architecture put forward by ETSI TS 102 690.

PC/Dedicated
Appliance M2M Applications

M2M
M2M CORE Management
Functions

Service Capabilities

M2M
Capabilities
CORE NETWORK (CN)
(include enhancements
to existing CN capabilities) M2M-speciﬁc
Management
Functions

M2M
Capabilities
Network
Management
Functions
M2M Network and
ACCESS NETWORK Applications Domain
Capabilities
Based on existing standards
TRANSPORT NETWORK 3GPP, TISPAN, IETF, etc.

M2M Device Domain
M2M M2M Based on existing standards
Applications Applications and technologies, e.g.:
DLMS, CEN, CENELEC, PLT,
M2M M2M Zigbee, M-BUS, KNX, etc.
Capabilities Capabilities
M2M GATEWAY M2M DEVICE

M2M M2M AREA
Devices NETWORK

Figure 7: ETSI TS 102 690 system architecture
ETSI (TS 102 690) M2M service capabilities functional architecture framework is progressing to Stage 3 to define identified
reference points—mId, dIa and mIa, as illustrated in Figure 8.

M2M
M2M Application
Application Stage 3
for M2M R1

mla
dla

SC1

SC8 SC2
M2M
Service
Capabilities
Routing
SC7 Function SC3

SC6 SC4

SC5
mld
M2M SERVICE CAPABILITIES

Core network function,
based on existing standards
Communication Modules (3GPP, ETSI, TISPAN, IETF...)

CORE CORE
M2M DEVICE/ NETWORK A NETWORK B
GATEWAY DOMAIN

Figure 8: Stage 3 for ETSI M2M Release 1



Service capabilities can access network core functions through existing interfaces (defined by I.E 3GPP and ETSI) and
provide functions that can be shared among applications. In the following list, X represents N for networks, G for Gateway
and D for Device, as previously described in Table 3.

The following M2M service capabilities (SC) include:

• Application Enablement (xAE)

• Generic Communication (xGC)

• Reachability, Addressing and Repository (xRAR)

• Communication Selection (xCS)

• Remote Entity Management (xREM)

• SECurity (xSEC)

• History and Data Retention (xHDR)

• Transaction Management (xTM)

• Compensation Broker (xCB)

• Telco Operator Exposure (xTOE)

• Interworking Proxy (xIP)

mIa—Allows an application to access M2M SCs in the network and applications domain.

dIa—Allows an application within an M2M device to access the different SCs in the same M2M device or in an M2M gateway.
Allows an application within an M2M gateway to access the different service capabilities in the same M2M gateway.

mId—Enables an M2M device or M2M gateway to access M2M SCs in the network and application domain.

3GPP and M2M
In 2007, a 3GPP study item (TR-22.868) on M2M communications titled Study on Facilitating Machine to Machine
Communication in 3GPP Systems was completed. This particular 3GPP study has shown potential for M2M services beyond
the current “premium M2M market segment.” In 2010, 3GPP started the process of developing the study’s results into a
specification phase—TS 22.368 Service Requirements for Machine-Type Communication (MTC) Stage 1 June 2010; TR 23.888
System Improvements for MTC July 2010—to address required network system improvements to support MTC.

TS 22.368 defines general requirements and specific MTC features, and it generated two additional study items that focus on
alternatives for using E.164 numbering for MTC and enhancements for MTC (TR 22.888).

TR 23.888 identifies key issues and proposes corresponding possible solutions. 3GPP Release 10 addresses change requests
related to congestion and overload control while other remaining items are deferred to later releases.

TR 33.812 is a feasibility study on the security aspects of remote provisioning and change of subscription for M2M equipment.
TR 33.868 focuses on the security aspect of MTC and is expected to be delayed until 3GPP Release 11 as a new work item.

3GPP Radio Access Network (RAN) and GSM Edge Radio Access Network (GERAN) groups are also active and are working
on the improvements for MTC with TR 37.868 and TR 43.868.



Figure 9 depicts the high-level 3GPP architecture (3GPP TS 23.888).

MTCsms MTC Server
MTC Device 3GPP
3GPP Bearer Services/
PLMN-MTC SERVER
MTCu SMS/IMS
IWK Function
MTCi MTC Server

Figure 9: Overall 3GPP high-level M2M architecture approach
The MTC server can be located either inside or outside of the operator domain. Reference points MTCi and MTCsms can be
part of the interworking function itself that could facilitate access to the MTC server using non-3GPP interfaces. Roaming
scenarios are considered and the MTC devices would connect using MTCu from visited public land mobile Network (PLMN)
to access home services.

Table 6 identifies the major components of the 3GPP M2M architecture.

Table 6: Major Components of 3GPP M2M Architecture
COMPONENTS/TERMINOLOGY DEFINITION

MTC Machine-Type Communication.
MTCu Reference point providing MTC devices access to 3GPP network for
transporting user traffic.
MTCi Reference point for MTC server to connect 3GPP network using 3GPP bearer
service.
MTCsms Reference point for MTC server to connect 3GPP network using 3GPP SMS.
MTC User Legal entity that uses MTC terminals (usually the contractual partner for the
operator).
MTC Device User equipment for MTC communicating with MTC server or device.
MTC Server An entity that can communicate with MTC devices and connects to the PLMN.

3GPP M2M Communication Scenarios
Three scenarios have been defined in 3GPP TS 22.368 pertaining to the communication between MTC devices and the
MTC server:

• Scenario 1 (Located in the operator domain)

• Scenario 2 (Located outside the operator domain)

• Scenario 3 (Communication directly with each other without an intermediate MTC server).

Scenario 1

Scenario 1 represents MTC devices communicating with the MTC server located in the operator domain. The network
operator domain offers an API on its MTC server, and the MTC user accesses the MTC server through this API.

MTC User
MTC Server API
MTC Device
OPERATOR DOMAIN

Figure 10: 3GPP M2M communication, scenario 1



Scenario 2

Scenario 2 represents MTC devices communicating with the MTC server located outside the operator domain. In this case,
the network operator offers network connectivity to the MTC server outside of its domain.

MTC Server/
MTC User

OPERATOR DOMAIN
MTC Device


Scenario 3

Scenario 3 represents MTC devices communicating directly with each other without an intermediate MTC server.

OPERATOR DOMAIN A OPERATOR DOMAIN B
MTC Device MTC Device


3GPP Release 10 Feature Requirements for M2M

Overall, approximately 14 specific feature service requirements have been identified in 22.368 Release 10.

Low Mobility

• MTC devices are static, nomadic and move only within a predefined region.

• There is a reduction in mobility signaling and reporting frequency.

Time Controlled

• Data can be sent or received only during certain predefined periods.

• Signaling outside of these predefined time windows can be minimized.

Time Tolerant

• Data application can support delay.

Packet Switched Only

• Network access allows for services to be obtained, and triggering should be possible with or without a Mobile Station
International Subscriber Directory Number (MSISDN).

Small Data Transmissions

• Most MTC devices send small amounts of data uplink.

Mobile Originated Only

• The network should provide mechanisms to reduce control signaling originated by MTC devices

Infrequent Mobile Terminated



MTC Monitoring

• It is not intended to prevent theft.

• Detection functionality of events such as unexpected behaviors and loss of connectivity is provided.

• The end user is notified and predetermined action is taken.

Priority Alarm Message (PAM)

• There is a need for immediate attention.

• It is used in case of theft, urgency or emergency.

Secure Connection

• MTC devices connect through a roaming operator.

Location Specific Trigger

• Operator stores location information and can wake up and trigger the MTC device in a particular area.

Network Provided Destination for Uplink Data

• The ability to transmit to a specific address is available.

Infrequent Transmission

• Network resources are allocated only when needed.

Group Based MTC Features

• It should be possible to broadcast to a specific group of devices.

• Combined policy, charging, addressing and QoS for a specific group should be possible.

3GPP Release 10 will focus on the following general functionalities required to support the above-listed features:

• Overload control

• Addressing

• Identifiers

• Triggering

• Remote management

• Subscription control

• Charging

• Security.

Conclusion
The current mobile network is optimized for H2H traffic patterns and not necessarily for M2M. Enhancements and
optimizations are needed for MTC to address issues such as scalability, IP addresses shortages and telephone numbers to
protect against control network overload, to differentiate between MTC applications that have different characteristics, to
help secure connectivity between M2M devices and the network as well as with the application servers, and to lower costs to
align with lower ARPD for MTC.

We like to talk about killer applications for wireless cellular. Many people think the next killer application is video streaming,
which is estimated to represent up to 60 percent of data volume. Today, M2M might not be perceived as a killer application
segment.

However, even though M2M is expected to have applications predominately for low data usage (some might generate higher
traffic in the case of video surveillance), the order of magnitude for M2M endpoints that will connect to the network is significant.

Current forecasts indicate a large market for MTC. We have seen a first phase of fragmented, niche M2M vertical applications.
Currently, a second phase is occurring, driven by regulatory and policies initiatives. A third phase is expected to follow, with
the Internet of things made possible through the advent of technologies such as 6lowpan from IETF.

M2M communications bring the opportunity to use mobile networks in a new way. We probably cannot foresee today what



impact the rise that machines might have on mobile data usage. However, it definitely opens up the possibility to create
new businesses.

Juniper Networks can facilitate mobile network operators to start addressing M2M segment opportunities with its MobileNext
product portfolio (MobileNext Broadband Gateway, MobileNext Control Gateway)—offering unprecedented subscriber
density, call setup capability and PCRF partnerships (MobileNext Policy Manager) to help translate these new business rules
into profitable services. Juniper Networks is in a unique position to leverage its security expertise with Junos Pulse and Junos
SDK by providing open APIs for partnership development and integration.

About Juniper Networks
Juniper Networks is in the business of network innovation. From devices to data centers, from consumers to cloud providers,
Juniper Networks delivers the software, silicon and systems that transform the experience and economics of networking.
The company serves customers and partners worldwide. Additional information can be found at www.juniper.net.

Corporate and Sales Headquarters APAC Headquarters EMEA Headquarters To purchase Juniper Networks solutions,
Juniper Networks, Inc. Juniper Networks (Hong Kong) Juniper Networks Ireland please contact your Juniper Networks
1194 North Mathilda Avenue 26/F, Cityplaza One Airside Business Park representative at 1-866-298-6428 or
Sunnyvale, CA 94089 USA 1111 King’s Road Swords, County Dublin, Ireland
authorized reseller.
Phone: 888.JUNIPER (888.586.4737) Taikoo Shing, Hong Kong Phone: 35.31.8903.600
or 408.745.2000 Phone: 852.2332.3636 EMEA Sales: 00800.4586.4737
Fax: 408.745.2100 Fax: 852.2574.7803 Fax: 35.31.8903.601
www.juniper.net

Copyright 2011 Juniper Networks, Inc. All rights reserved. Juniper Networks, the Juniper Networks logo, Junos,
NetScreen, and ScreenOS are registered trademarks of Juniper Networks, Inc. in the United States and other
countries. All other trademarks, service marks, registered marks, or registered service marks are the property of
their respective owners. Juniper Networks assumes no responsibility for any inaccuracies in this document. Juniper
Networks reserves the right to change, modify, transfer, or otherwise revise this publication without notice.

2000416-001-EN May 2011 Printed on recycled paper


Machine to Machine White Paper

Recommended

Recommended

More Related Content

What's hot

What's hot (19)

Similar to Machine to Machine White Paper

Similar to Machine to Machine White Paper (20)

More from Josep Pocalles

More from Josep Pocalles (20)

Recently uploaded

Recently uploaded (20)

Machine to Machine White Paper