M2M Day Two

Syllabus Day one : Business and Architectures
Introduction to M2M
What is M2M?
The Business of M2M
Accelerating M2M Maturity
M2M Standards
The Business of M2M
The M2M Market
The M2M Market Adoption: Drivers and Barriers
The M2M Value Chain
Market Size Projections
Business Models
M2M Business Metrics
Market Evolution
Early M2M Deployments
M2M Requirements and High-Level Architectural Principles
Use-Case-Driven Approach to M2M Requirements
Smart Metering Approach in ETSI M2M
Syllabus Day Two : Deployment
M2M Optimizations in Public Mobile Networks
M2M Over a Telecommunications Network
Network Optimizations for M2M
The Role of IP in M2M
IPv6 for M2M
6LoWPAN
Routing Protocol for Low-Power and Lossy Networks (RPL) CoRE
M2M Security
Trust Relationships in the M2M Ecosystem
Security Requirements
Which Types of Solutions are Suitable?
Standardization Efforts on Securing M2M and MTC Communications
M2M Terminals and Modules
M2M Module Categorization
Hardware Interfaces
Temperature and Durability ServicesSmart Metering Approach in ETSI M2M
eHealth Approach in ETSI M2M
High-Level Architecture Principles for M2M Communication
ETSI M2M Services Architecture
High-Level System Architecture
ETSI TC M2M Service Capabilities Framework
ETSI TC M2M Release 1 Scenarios
ETSI M2M Service Capabilities
Introducing REST Architectural Style for M2M
ETSI TC M2M Resource-Based M2M Communication and Procedures
Temperature and Durability Services
Software Interface
Cellular Certification

7 April 20137 April 2013
Day two: DeploymentDay two: Deployment

IPv6 for M2M
6LoWPAN
M2M Security
Standardization Efforts on Securing M2M and MTC CommunicationsStandardization Efforts on Securing M2M and MTC Communications
Hardware Interfaces
Software Interface
Arief Hamdani GunawanArief Hamdani Gunawan

• Many M2M applications use public
telecommunications networks to transfer data from
M2M devices to an M2M server.
• These telecommunications networks will have to be
adapted to cope with the traffic generated by the
projected growth of M2M applications.projected growth of M2M applications.
• In the near future, many more devices will be
connected to the existing networks, as more and more
M2M applications are introduced.
• These M2M devices will have a very different effect on
the telecommunications network compared to human-
oriented devices.

Device-to-server and device-to-device communication scenarios

M2M communication path via M2M server

M2M via mobile networks creates independence from operators

Different M2M applications have different communication needs

Data connection establishment in a cellular mobile network

Different M2M applications with different communication patterns

Network Optimization
for machine-type communication
features in 3GPP Release 10 and Release 1

Machine Type Communications
• M2M is recognized as a key segment in future
cellular mobile packet data networks
• Initial 3GPP efforts have focused on the ability to
differentiate MTC -type devicesdifferentiate MTC -type devices
– This allows the operator to selectively handle such
devices in congestion/overload situations
• Low priority indicator has been added to the relevant UE-
network procedures
• Overload and Congestion control is done on both core
network and radio access network based on this indicator

Cost Optimizations
Cost drivers for an M2M application
in a mobile telecommunications network

Traffic Optimizations
QoS traffic classes in UMTS

QoS parameters applicable to the different UMTS traffic classes

Numbering and Identifiers Optimizations
• E.164 number format for telephone numbers
• Format for the International Mobile Subscriber
Identity (IMSI)

• Format for the International Mobile Equipment
Identity (IMEI)
• Format for the International Mobile Equipment
Identity and Software Version Number (IMEISV)

• Format of the International Circuit Card Identifier
(ICCID)

The Basics of Triggering (1/3)
When the M2M server decides to trigger an M2M
device, it generally includes the following
information in the trigger message:
• the identity of the target M2M device;
the identity of the application• the identity of the application
• a request counter associated to this request
allowing for the detection of duplicated requests,
for the correlation of requests with their
acknowledgment, and to allow the application to
cancel a request;

The Basics of Triggering (2/3)
• (optionally) the IP address (or FQDN) and/or port
numbers of the application server that the UE has to
contact;
• (optionally) an urgency request indication;
• (optionally) a validity timer, allowing for the removal of
triggers that are stored in the network when the device
• (optionally) a validity timer, allowing for the removal of
triggers that are stored in the network when the device
cannot be reached, for example, with SMS;
• (optionally) the area where triggering needs to be sent;
• (optionally) a limited amount of application-specific
information, for example, to instruct the M2M device
to do something before establishing communication
with the M2M server.

Triggering Optimizations (3/3)
Before the M2M server can send the trigger message, it needs
to determine where to send the trigger request. 3GPP is
defining a machine-type communication gateway (MTC
GW) that will act as an entry point in the mobile network
for control messages from the M2M servers.
The MTC GW may be pre-provisioned in the M2M server inThe MTC GW may be pre-provisioned in the M2M server in
case the M2M server only communicates with one network
operator.
Otherwise, the M2M server first needs to determine to which
operator a trigger request needs to be sent. Based on the
device ID or IMSI, the M2M server should be able to find
the correct mobile operator network.

Triggering Optimizations:
Overview architecture with different triggering solutions.

Triggering Mechanisms
• triggering using mobile-terminated SMS;

• triggering using IMS messages;

• triggering using cell broadcast;

• triggering via HSS and non-access stratum (NAS) signaling;

• triggering via network-requested PDP context
establishment

Closing
• For M2M application owners, mobile networks
are often more suitable as they offer better
possibilities for controlling the subscription and
have end-to-end visibility of the data connection.
• From an operator point of view, mobile networks• From an operator point of view, mobile networks
create more challenges whereby optimizations
are needed to cater for large volumes of M2M
traffic. Nevertheless, a lot of the issues,
problems, and solutions discussed are generic
and will also apply to fixed networks

• Very few computer network protocols lasted as long as the IPv4
protocol. Even if, at the outset, IP was never designed to become
the universal protocol we know nowadays, it was made versatile
enough to evolve and cover an ever-increasing number of
applications.
• IPv6 protocol is a simplification of the IPv4 packet and retains the
same principle. Fields that proved to be unused after years ofsame principle. Fields that proved to be unused after years of
exploitation have been removed.
– The first of these, the option field leading to a variable header size, has
been withdrawn and replaced by extensions. An extension can be
viewed as an intermediary protocol between Layer 3 (IP) and Layer 4
(UDP, TCP), except for the hop-by-hop extension that must be
processed by each router on the path. Other extensions are invisible
from the core network and only processed by the final destination.

Internet Protocol (IP) version 6

IP Addresses Optimizations
• M2M communication scenario using IPv6 addressing
• M2M communication scenario using IPv4 addressing

IP Addresses Optimizations
• M2M communication scenario using private
IPv4 addressing only

Network Applications
• Network applications cannot rely on the
device being constantly available and able to
send or receive data.
• Examples of IP-based communication protocol• Examples of IP-based communication protocol
evolutions to cope with constrained devices
include the work done in the IETF 6LoWPAN
(IPv6 over low power and lossy networks)
Working Group.

Constrained but still Internet
• Today - a complete IP based Web stack can be run on small
devices with microcontrollers.
(Constrained
Application
Protocol)

IETF 6LoWPAN
• The 6LoWPAN WG group has defined encapsulation
and header compression mechanisms that allow IPv6
packets to be sent and received over IEEE 802.15.4-
based networks. IEEE 802.15.4 maximum transfer unit
(MTU) is limited to 127 bytes.
• Taking into account frame overhead and optional• Taking into account frame overhead and optional
security headers, very little is left for upper layers, that
is, TCP/IP and application payload, unless protocol
overhead is optimized.
• In essence, the 6LowPAN work allows IP to be used all
the way to constrained devices, a desirable feature to
allow for an end-to-end IP-based communication.

6LoWPAN: Why IPv6?
• Long-lived technology (20 years+)
• Ability to connect heterogeneous networks
• Existing worldwide free-to-use infrastructure
• Global scalability• Global scalability
• 2^128 Bit (16 Byte) Addressing = Enough for
Internet of Things
• Great number of tools (diagnostic,
management etc.)

IPv6 Problems
• Bandwidth and Energy efficiency
Standard protocol: IEEE 802.15.4 L1/L2 (low bandwidth:
250 kbps, low power: 1mW)
• Fragmentation:
IPv6 minimum frame size (MTU) = 1280 bytesIPv6 minimum frame size (MTU) = 1280 bytes
IEEE 802.15.4 frame size (MTU) = 127 byte (higher bit error
rate, failure proneness)
• Header compression:
IPv6 headers (40 bytes) reduce payload
53 byte payload in 127 byte 802.15.4 frame

IPv6 Problems
• Mobility:
Node Mobility and Network Mobility
• Review of Transport Layer Protocols:
TCP inefficient for wireless embedded devices (wireless packet lost)
• Handle offline devices:
• IP assumes devices are always on, but embedded devices may not
(power and duty cycles)
• Multicast support:
IEEE 802.15.4 & other radios do not support Multicast (expensive)

6LoWPAN (IETF RFC4944)
• IPv6 over Low Power Wireless Area Networks
• Level 2/3 Protocol (OSI)
• Enables usage of IPv6 by wireless embedded devices
• Dedicated to specific task/ not general purpose like PC
• Limited hardware resources:• Limited hardware resources:
– Low processing power (microcontroller/ dsp)
– Little memory
– Low power
• Limited networks capabilities:
– Short range
– Low bitrate
– Message-Size

IEEE 802.15.4
46
Within the broad organization of the Institute of Electrical and Electronics
Engineers (IEEE), the 802 group is the section that deals with network
operations and technologies.
Group 15 works more specifically with wireless networking, and Task
Group 4 drafted the 802.15.4 standard for a low data rate wireless
personal area network (WPAN).

IEEE 802.15.4 Device Definitions
• Full function device (FFD)
– Any topology
– Network coordinator capable
– Talks to any other device– Talks to any other device
• Reduced function device (RFD)
– Limited to star topology
– Cannot become a network coordinator
– Talks only to a network coordinator
– Very simple implementation

Adaptation of IPv6 to LoWPAN environment
Several constraints require an adaptation of IPv6 to
LoWPAN environment:
• Layer 2 frame size may be limited compared to the IPv6
specifications with a minimum mandatory MTU of
1280 bytes. Fragmentation is required to provide the1280 bytes. Fragmentation is required to provide the
frame lengths specified by IPv6
• Energy can be drastically limited in some nodes. For
instance, some metering devices may run for several
years (up to 15) on the same battery. Unnecessary
exchanges and multicast traffic must be avoided in
order to save power.

Adaptation of IPv6 to LoWPAN environment
• Neighbor discovery messages should not be
fragmented. If some fragments are lost, the
protocol becomes inefficient.
• Radio range may be reduced and the IPv6• Radio range may be reduced and the IPv6
packet will have to be relayed from node to
node to reach the destination or an LBR.
• The neighborhood is not as well-defined as in
wired or WiFi networks and radio range
variation causes the neighbor list to change.

Organization
A 6LoWPAN network can be organized around three
topologies:
• Star topology: All sensor nodes can reach and are reachable
from the LBR.
• Meshed: Nodes are organized at Layer 2 in order to relay
frames toward the destination. Algorithms to organize theframes toward the destination. Algorithms to organize the
interconnection are not defined by 6LoWPAN, which simply
offers generic support to manage broadcast and hop-by-
hop bridging. From the point of view of the Internet, a
meshed network is similar to an Ethernet network where
every node shares the same prefix. 6LoWPAN refers to that
technology as mesh-under (MU).

Organization
• Routed: Nodes act as routers and forward packets
toward the destination. A routing protocol must be
running on some nodes in order to construct
forwarding information. Nodes acting as a router
inside the LoWPAN network and not directlyinside the LoWPAN network and not directly
connected to the Internet are called LoWPAN routers
(LRs). 6LoWPAN refers to that technology as route-
over (RO). The best candidate is the RPL protocol, as
defined by the Roll working group

Scenarios
6LoWPAN architecture covers two scenarios:
• The first, called mesh-under, supposes that an
L2 relaying strategy is defined, resulting in the
mesh network acting as a link for the IP layer.mesh network acting as a link for the IP layer.
• The second, called route-over, supposes that
some nodes have routing capabilities and are
able to forward packets toward the
destination.

Network Architectures
• Several routing protocols have already been
defined for fixed and ad-hoc IP networks.
• In the series of RFCs, the Roll working group
has defined the requirement for differenthas defined the requirement for different
network architectures:
– urban networks;
– industrial networks;
– home networks;
– building networks.

Routing Protocol for Low-Power
and Lossy Networks (RPL)
• The protocol defined by the Roll working
group is called RPL.
• It is based on distance vector algorithms, such
as routing information protocol (RIP), and isas routing information protocol (RIP), and is
designed to correct performance issues due to
bad loop detection.

Routing Protocol for Low-Power
and Lossy Networks (RPL)
• RPL must also remain flexible in the definition of
routing strategies.
• An urban network will not have the same
constraints as a home network, and also, within
each network type, the applications do noteach network type, the applications do not
always share the same objectives.
• An alarm system may try to reduce propagation
delays, and an application generating periodic
messages will try to select routers with the
highest level of energy (powered).

ROL Topology
• The RPL topology is based on a direction oriented
directed acyclic graph (DODAG).
• The DODAG is used to allow the upward traffic to
leave the LLN, but can also be used afterwards to
build a reverse path toward the nodes and leaves.build a reverse path toward the nodes and leaves.
• One difference compared with RIP, which
maintains a single path toward a destination, is
that the DODAG may contain more loop-free
paths toward the destination, which increases
reliability and speeds up recovery in the event of
a route failure.

DAG and DODAG
• Directed Acyclic Graph (DAG) - a directed
graph with no cycles exist.
• Destination Oriented DAG (DODAG) - a DAG
rooted at a single destination.rooted at a single destination.

ICMPv6 message
• RPL defines a new ICMPv6 message with three
possible types:
• DAG Information Object (DIO) - carries
information that allows a node to discover an RPL
Instance, learn its configuration parameters andInstance, learn its configuration parameters and
select DODAG parents
• DAG Information Solicitation (DIS) - solicit a
DODAG Information Object from a RPL node
• Destination Advertisement Object (DAO) - used to
propagate destination information upwards along
the DODAG.

Metrics and Constraints
• RPL intends to use different metrics and
constraints to build the topology.
• The metrics used can be additive (i.e., path
quality), can report a minimum or a maximumquality), can report a minimum or a maximum
(i.e., the energy of node on the path) and
finally can be multiplicative (i.e., error rate on
the path).

Metrics and Constraints
Metrics or constraints can be also related to the
node:
• energy: how the node is powered and percentage
of remaining energy;
• hop count: number of crossed hosts;• hop count: number of crossed hosts;
• throughput, latency;
• link quality level: from 1 (highest) to 7 (lowest);
• ETX (expected transmission): number of
transmissions required to successfully send a
packet

Multicast
• Multicast may be a useful feature, for example, when
switching on several lights in a building at the same
time.
• RPL routing protocol may be used to implement
multicast in a LoWPAN, but the group management
may require significant amounts of energy to flood themay require significant amounts of energy to flood the
whole network.
• The CoRE working group is currently defining a method
for implementing multicast at the application level in a
proxy gateway.
– CoRE: Constrained RESTful Environments
– REST: Representational State Transfer

REST
• REST is widely known as being the architectural
model of the web through the HTTP protocol.
• As for the web, the RESTful architecture is well-
suited to most types of M2M applications.
• It is based on the client-server paradigm.• It is based on the client-server paradigm.
• The server contains information that can be
saved or retrieved by clients.
• In this instance, a sensor or an actuator can be
viewed as a server and the application or the
gateway is treated as the client.

Interactions
REST defines four interactions between the client
and the server:
• GET (code 1 in the CoAP header): The client
requests the information located on the server.
• POST (code 2): The client creates and stores the• POST (code 2): The client creates and stores the
information on a resource located on the server.
• PUT (code 3): The client stores information on a
resource based on the server.
• DELETE (code 4): The client removes a resource
from the server

CoAP
• The CoAP (constraint application protocol)
protocol is a way of structuring the exchange
of information based on the representational
state transfer (REST) paradigm but optimizedstate transfer (REST) paradigm but optimized
for M2M applications.
• The HTTP protocol is the most famous
example of REST architecture.

M2M Security
• he M2M market is highly fragmented with many players
across numerous vertical domains.
• On the other hand, the industry has reached a point where
the value of M2M services for improving productivity in the
enterprise, as well as convenience and comfort for
consumers, is broadly understood.consumers, is broadly understood.
• Given the increased focus on M2M applications by large
network operators with a view toward leveraging their
existing assets, coupled with the opening up of their
networks and devices, M2M communications is poised to
take off in an unprecedented fashion.
• The communication security is a critical enabler for the
mass market adoption of M2M.

Security Characteristics of Cellular M2M
• Cellular M2M differs from current cellular networks in three
important ways, which suggests that the current security
mechanisms in place today for mobile devices in such networks are
not appropriate for M2M.
• First, cellular network services today are typically provided by a
single service provider that typically owns the device distribution
along with the SIM card distribution, device provisioning, networkalong with the SIM card distribution, device provisioning, network
infrastructure, and service delivery for voice and data services.
• In some cases, the device distribution, device provisioning, and
service delivery are owned by a mobile virtual network operator
(MVNO), while the underlying network infrastructure is owned by a
different network provider.
• On the other hand with cellular M2M, multiple players exist with
limited business relationships among them.

• Traditional network services, such as cellular voice and
data services, are provided by operators that deploy
and operate the network, market the services, certify
and channel the devices to end-users, and manage the
end-user subscriptions and billing.
• Essentially, a single entity is involved in all aspects of• Essentially, a single entity is involved in all aspects of
each service.
• On the other hand, M2M services typically involve
multiple entities in the delivery of each service.
• The entities most commonly involved are the end-user,
the network provider, the M2M service provider, the
application provider, and the device manufacturer.

• M2M operators negotiate network services in bulk from multiple
network providers and manage the network access subscriptions on
behalf of many application providers.
• Application providers, as the name suggests, are the entities that
provide the end-user application, such as collecting and processing
the data.
• An end-user may buy a device that incorporates the network• An end-user may buy a device that incorporates the network
connectivity module directly from the manufacturer (through a
retail distribution network) or from the application provider. Hence,
the ecosystem is much more complex than a traditional network
service.
• This renders the design of efficient end-to-end security solutions
quite challenging

Business relationships
between the main entities in smart metering service

• The M2M security requirements are drawn
from the need to protect the various entities
in the end-to-end solution from perceived
threats.threats.
• We will provide examples of the threats
experienced by each of the players identified
in the previous section and then summarize
the security requirements

Customer/M2M Device User
• Devices can be hijacked for the data they provide or for
their actuation capabilities by adversaries pretending
to be the back-end application servers.
• A scenario where such an attack could be of some
economic value to the adversary is the remote control
of home automation devices, such as alarms andof home automation devices, such as alarms and
garage door openers.
• By pretending to be the network-based home
automation server, attackers can deactivate the alarm,
and open doors to enter the house. Devices must be
protected from unauthorized entities trying to
establish communications to and from the devices

Access Network Provider
• Unlike the case of consumer electronic devices, in
many cases M2M devices are owned by the application
providers and deployed in premises that are not
constantly physically monitored or protected.
• For example, in the case of smart metering, the meters
are typically owned by the utility companies andare typically owned by the utility companies and
deployed in homes and small business locations.
• These devices are thus more susceptible to theft.
• Misuse of stolen communication modules found in
these devices for the purpose of regular Internet
communication, such as web-browsing, should not be
permitted.

M2M Service Provider
• The threats to an M2M service provider
include all those applicable to a network
operator.
• In addition, it is the responsibility of the M2M• In addition, it is the responsibility of the M2M
operator to ensure service availability to
application providers and guarantee that the
data sent to application-provider data centers
is not tampered with.

Application Provider
• Adversaries may benefit from modifying the
data transferred from the device to the back-
end application server or vice versa through
man-in-the-middle attacks.man-in-the-middle attacks.
• It should thus be possible to verify the
integrity of data transferred between the
entities

Common requirements (1/2)
Common requirements for any security solution.
• Mutual authentication: Only authenticated M2M devices
can access the network and M2M system, and conversely
any M2M device should authenticate the server before
accepting any data, such as commands or management-
related updates. This will ensure that data collected by therelated updates. This will ensure that data collected by the
back-end-server is coming from a legitimate device, and
the device is assured that it is communicating with a
legitimate server. The mutual authentication procedures
have to be completed between the M2M device and the
M2M operator network before initiating data transfer.
• Confidentiality: Data transfer between the M2M device and
the application server should be protected from
unauthorized eavesdropping.

Common requirements (2/2)
• Integrity: Application servers should be able to verify the
integrity of the data originating from an associated device.
Similarly, devices should be able to verify the integrity of
the data sent by the affiliated servers. This protects the
data from unauthorized modifications or manipulations.
• Exclusivity: Communication devices in the machine module• Exclusivity: Communication devices in the machine module
should not be capable of being used for other applications.
When the network provider entity is separate from the
application provider entity, this requirement implies that
the network provider has to deny service to a tampered
device.
• Anonymity: The identity of the device should not be
revealed to an eavesdropper in the network.

Bootstrapping Requirements
• Within the M2M ecosystem, we are dealing with
an explosion in the number of devices (perhaps
running into the billions, if widely adopted) and
hundreds of applications provided by a few
virtual operators using a mix of access networks.virtual operators using a mix of access networks.
• Therefore, several constraints are imposed on the
bootstrapping of security keys:
– Complex ecosystem
– Scalability
– Bootstrapping requires network authentication

Complex ecosystem
• We should expect a multitude of device vendors
participating in a relatively open ecosystem, selling low-cost
devices directly to consumers.
• For instance, as described earlier, the complex ecosystem
may involve device manufacturers selling on an open
market while service providers may not have a businessmarket while service providers may not have a business
relationship with the device vendor or reseller.
• Alternatively, in residential applications such as metering,
the end-user (home-owner) may not even know the virtual
network operator who is providing the service on behalf of
the owner of the organization which owns the application,
but yet securing the application is critical to all players in
the chain.

Scalability
• M2M services typically involve a large number of
devices, each sending a small amount of data.
• The revenue per device is generally small for any of the
players in the value chain. Thus, it is important to
minimize expenses incurred in deploying andminimize expenses incurred in deploying and
maintaining these devices.
• One of the key steps in the deployment of devices is
the provisioning of the device in the appropriate
databases of the network and application provider. In
particular, provisioning of keys or other information for
the security solution should be simple and scalable.

Bootstrapping requires network authentication
• More importantly, it is highly likely that the network operator (who
provides bandwidth to the M2M operator) will not be able to tell
when a device is executing a bootstrapping application.
• For instance, this constraint requires that a device authenticate
itself with the mobile data network using a network access identity,
which allows the network operator to “recognize” the device and
“authorize the data transaction,” despite the device not yet“authorize the data transaction,” despite the device not yet
possessing security keys or other access credentials.
• In other words, bootstrapping protocols for M2M devices should
assume that the M2M system is an overlay over existing (and
deployed) networking systems, thereby requiring devices to
successfully register with the access network before the
bootstrapping application is invoked, and such registration
procedures should clearly comply with existing networking
standards

Which Types of Solutions are Suitable
• Various attack detection and prevention
schemes for other types of deployments have
already been proposed.
• We develop them further below.• We develop them further below.
– Approaches Against Hijacking
– Public Key Solutions
– Smart Card-Based Solutions

Approaches Against Hijacking
• Encryption and Integrity Protection: A large body of
research and standardization studies have proposed
the use of cryptographic operations in order to detect
and prevent hijacking attacks.
• IP Address-Based Filtering: The idea here is to check
the source IP address of packets at intermediatethe source IP address of packets at intermediate
routers along a routing path in order to detect
impersonation, reflection, and hiding attacks. Such
techniques involve checking incoming packets using
routing tables and looking up the return path for the
source IP address, as well as comparing the IP address
that has been allocated to a specific MAC address,
potentially through IPCP or DHCP

Public Key Solutions
• One well-known method for bootstrapping keys involves
provisioning a private-public key pair along with a certificate of a
public key.
• This pair can be individually generated during manufacture and can
be pre-installed along with the corresponding certificate.
• Following this, during installation, the device could execute a well-
known public-key-based key-agreement protocol (such as internetknown public-key-based key-agreement protocol (such as internet
key exchange – IKE) to bootstrap a root key.
• While this sounds straightforward (and uses known techniques),
some of the issues with this method include the need for a large-
scale public key infrastructure (PKI) that can potentially handle a
billion devices

Smart Card-Based Solutions
• The use of smart cards (SIM cards for GSM systems or
UICC in general) is a very attractive option for scenarios
with M2M deployments over cellular networks. Since
the late 1990s, SIM cards have been widely used by
cellular network operators in mobile phones and othercellular network operators in mobile phones and other
mobile devices that attach to cellular base stations.
• Hence, for certain cellular M2M cases where devices
are by default equipped with smart cards, such cards
could provide the necessary key material for use by the
M2M service or the application layer, based on policies
and relationships .

Standardization Efforts on Securing
M2M and MTC Communications
• Recently, there has been an increasing interest in
standardizing various aspects of M2M security.
Such interest is aligned with parallel efforts on
standardizing functional architecture settings.standardizing functional architecture settings.
• In what follows, we discuss the current state of
such efforts for different standardization bodies.
– ETSI M2M Security
– 3GPP MTC Secturity

ETSI M2M Security
• The ETSI M2M Standards Group is focused on
designing the functional architecture of the M2M
service provider.
• It considers that the M2M provider is a service-layer
entity, which logically resides above the access layer,entity, which logically resides above the access layer,
and which is independent of (but may be collaborating
with) the access network operator(s), as well as the
M2M application provider(s).
• The establishment of secure data sessions between
M2M devices (or gateways) and the ETSI M2M service
capabilities is based on the existence of a key hierarchy.

3GPP MTC Security
• Standardizing machine-type communications (MTCs)
has received a lot of interest from the 3GPP.
• The 3GPP security group, SA3, has been guided by the
group requirements and the network architecture
group (SA1 and SA2, respectively) toward designing
and standardizing security procedures related toand standardizing security procedures related to
network improvements for MTC.
• Since 3GPP is predominantly interested in operations
exclusively involving the deployed 3GPP network,
architecture, and thereby security support for M2M
communications is tied to the existing 3GPP network
design.

IPv6 for M2M
6LoWPAN
M2M Security
Standardization Efforts on Securing M2M and MTC Communications
M2M Terminals and ModulesM2M Terminals and Modules
Hardware Interfaces
Software Interface
Muhammad Ary MurtiMuhammad Ary Murti

M2M: Architecture and Applications
BTP, Bandung, 6-7 April 2013.
Muhammad Ary Murti
m_ary_murti@ieee.org

• M2M Module Categorization
• Hardware Interfaces
• Temperature and Durability Services• Temperature and Durability Services
• Software Interface
• Cellular Certification
m_ARy-murti@ieee.org, 6-7 April 2013

Access Technology
Wireless or Wired ?
• Wired access technologies require a physical
connection to a cable such as a telephone line (e.g.,
RJ11) or the cable company's coaxial cable (e.g., RG-6).
• Some of the more popular wired access technologies
for M2M include powerline communications (PLC)
• Some of the more popular wired access technologies
for M2M include powerline communications (PLC)
(connection to AC mains), Ethernet (RJ-45), and xDSL.
• The use of wired-access technologies is not common
for M2M for several reasons, namely the inability to
support mobility, the high infrastructure costs of laying
new cable (PLC excluded), and the comparative
complexity of maintenance.

M2M End-to-End Network

M2M Access Networks

M2M Access Networks
• Wired Solution – dedicated cabling between sensor - gateway:
•  pros: very, very reliable; very high rates, little delay, secure, cheap to
maintain
•  cons: very expensive to roll out, not scalable
• Wireless Cellular Solution – dedicated cellular link:
•  pros: excellent coverage, mobility, roaming, generally secure
•  cons: expensive rollout, not cheap to maintain, not power efficient,•  cons: expensive rollout, not cheap to maintain, not power efficient,
delays
• Wireless Capillary Solution – shared short-range link/network:
•  pros: cheap to roll out, generally scalable, low power
•  cons: not cheap to maintain, poor range, low rates, weaker security,
large delays
• (Wireless) Hybrid Solution – short-range until cellular aggregator:
•  pros: best tradeoff between price, range, rate, power, etc.
•  cons: not a homogenous and everything-fits-all solution

Timeline of M2M
• Nokia M2M Platform Family [2002] = Nokia M2M Gateway software +
Nokia 31 GSM Connectivity Terminal + Nokia M2M Application Develop.
Kit (ADK)

Wireless Link Distance
• WPAN (wireless personal-area networks)
• WLAN (wireless local-area networks), and
• WWAN (wireless wide-area networks)

WWAN technologies
• frequency division multiple access (FDMA),
e.g., AMPS;
• time division multiple access (TDMA), e.g.,
GSM;GSM;
• code division multiple access (CDMA), e.g.,
UMTS;
• orthogonal frequency division multiple access
(OFDMA); e.g., LTE (long-term evolution)

Classifying WWAN by “Generation”
• 1G (first generation) includes technologies
such as AMPS, TACS and NTACS;
• 2G includes technologies such as IS-136, GSM,
and most commercial deployments of 1xRTT;and most commercial deployments of 1xRTT;
• 3G includes UMTS, TD-SCDMA, and EVDO;
• 3.5G includes technologies such as HSPA
(high-speed packet access);
• 4G includes UMB (ultra-mobile broadband),
WiMAX (802.16e), and LTE.

2G M2M modules are still being
deployed in 2012
• lower module cost
• seen as more mature, that is, more reliable, low power, and
have more features and services
• seen as superior—since most 2G was initially deployed in
the lower bands (cellular 800 and 900 MHz GSM band), and
3G in the higher bands (1800 MHz DCS and 1900 PCS), 2G3G in the higher bands (1800 MHz DCS and 1900 PCS), 2G
has a natural advantage of better coverage, especially for
indoor penetration.
• seen as good enough—since it is possible and even likely
that the module will have to operate in 2G mode in rural
and indoor areas (see the previous bullet-point on
coverage), the M2M application needs to be designed for
2G throughputs and latencies.

WAN Dominates the Wireless Connection Space
Mobile networks are
expected to host
roughly 86 million
connections
• Fixed installations• Fixed installations
are usually short
range to a home hub
• Greater demand for
mobility, faster data
speeds and remote
monitoring
Source: Machina Research

M2M Module Price Comparison
Source: Harbor Research, Inc., September 2010

Physical Form Factors M2M
module classifications
Solder-Down Module
Solder pads are used with :
a. line grid array (LGA)
b. ball grid arrays (BGAs)b. ball grid arrays (BGAs)

PCI Express Mini Card (Peripheral Component
Interconnect)
• supports two options for host interface connectivity—
PCI express and USB 2.0—most M2M module vendors
only support USB 2.0 connectivity.
• defined as 30 × 50.95 mm with a maximum thickness• defined as 30 × 50.95 mm with a maximum thickness
of 5 mm.
• PCI-SIG has also defined a half-length card that is
specified at 30 × 26.8 mm press Mini Card

Highly Integrated
• having a commercial housing and a
standardized host interface : USB, RS232, or
RJ45RJ45

Proprietary
• since the M2M module vendor is not constrained in any way,
the vendors can often innovate beyond the other form factors
to produce a module that is smaller or less costly or more
reliable or has better heat-dissipation properties or is morereliable or has better heat-dissipation properties or is more
specialized to a particular M2M application.

Hardware Interfaces
• Power Interface : 3.0 and 4.5 V
• USB (Universal Serial Bus) Interface
• UART (Universal Asynchronous Receiver/ Transmitter) Interface
baud rate supported by the module is 1200–115,200 bps
• Antenna Interface
• UICC (Universal Integrated Circuit Card) Interface• UICC (Universal Integrated Circuit Card) Interface
• GPIO (General-Purpose Input/Output Port) Interface
• SPI (Serial Peripheral Interface) Interface
• I2C (Inter-Integrated Circuit Bus) Interface : 400 Kbps
• ADC (Analog-to-Digital Converter) Interface
• PCM (Pulse Code Modulation) Interface
• PWM (Pulse Width Modulation) Interface
• Analog Audio Interface

Temperature and Durability
• Most modules provide an operating temperature
range of −30 to +70°C, which is satisfactory for
most industrial applications,
• but the automotive, metering, and some other
industrial applications are demanding higherindustrial applications are demanding higher
operaTng ranges of −40 to +85°C.
• The thermal shock cycle is another important
parameter, and module vendors typically provide
as many as 1000 thermal shock cycles on some
modules.

Software Interface (1/3)
AT Commands
• seven-bit ASCII character string commands.
The interface was originally designed to be
sent over a serial link but can also besent over a serial link but can also be
commonly used over USB
• The oldest, best-known, and thus most
commonly used
• 3GPP has standardized a broad set of AT
commands in the TS 27.707 specification

SDK Interface
• Provides many function calls, methods,
classes, and objects
• Corresponds well with more powerful OS-• Corresponds well with more powerful OS-
based environments
• OS-dependent (e.g., Windows, Linux, Android,
WinCE)
• Programming-language-dependent (e.g., C,
Lua, Java)

An SDK provides many advantages over the AT command interface
such as:
• excellent event-notification support;
• it encourages the use of standard programing practices;
• concurrent access: the single common API can be used by multiple• concurrent access: the single common API can be used by multiple
concurrent applications;
• SDKs tend to be more responsive;
• binary data support: binary data can be sent natively without first
hex-encoding.
• One of the issues with SDKs is that they are currently all proprietary

• Beyond regulatory certification, which is required
by all transmitting devices, cellular products also
require telecom industry and MNO certification.
• very large burden to the module vendors and the• very large burden to the module vendors and the
M2M application developers (or integrators).
• The industry is continuously trying to minimize
burden by modifying processes and testing
procedures, all the while trying not to affect the
quality of interoperability.

Telecom Industry Certification (1/3)
• For GSM-based modules, the telecom industry
certification is controlled via two associations,
that is, GCF (global certification forum) and
PTCRB (PCS terminal certification review board).PTCRB (PCS terminal certification review board).
• For CDMA-based modules, a new forum called
the CDMA certification forum (CCF) has been
established.
• Telecom industry certification typically requires:

Telecom industry certification typically requires:
• testing against some technical specification,
such as TS 51.010, using an accredited
laboratory;laboratory;
• field testing, e.g., drive testing;
• proof of a quality assurance programme, e.g.,
ISO9001.

Even if an integrated module has “module-
certification,” the integrator can be expected to
perform the following types of tests (depending
on the module form factor and the integrator's
implementation):implementation):
• radiated spurious emissions;
• measurement of radiated RF power and receiver
performance, e.g., total isotropic sensitivity (TIS)
and total radiated power (TRP);
• UICC/SIM electrical test cases;
• man-machine-interface-related test cases.

MNO Certification
• MNO certification is not standardized, so the amount
of testing, the test limits, and the test cases vary
between MNOs.
• MNO certification is focused on the equipment
deployed in the MNO network, where the field testing
and IOT (interoperability testing) is conducted on theand IOT (interoperability testing) is conducted on the
MNO's network and not on test equipment, such as
Agilent test equipment.
• MNO certification only deals with complete products
(not modules) but a module can be precertified, similar
to telecom industry certification, to reduce the burden
of testing required by the integrator.

Need To Be Optimized

Challenges for Capillary M2M
• Core Challenge #1 – Delays:
 Connection Delay: optimize L2/L3 node discovery protocols
 Communication Delay: ultra reliable & time-critical MAC urgently needed
• Core Challenge #2 – Security:
 Requirements: room for efficient end-to-end security solution
 Extras: fit security into standards, allow for aggregation, etc.
Core Challenge #3 – Standards:• Core Challenge #3 – Standards:
 so far: too many proprietary solutions on market
 need for: truly standardized embedded architecture
• Core Challenge #4 – P2P Traffic:
 Traffic Pattern: a lot more P2P traffic is emerging than initially thought
 Protocols: without jeopardizing converge-cast protocols, find solution

Challenges for Cellular M2M
• Core Challenge #1 – Complexity & Power:
 Modulation: simple to detect in DL; constant envelope in UL
 Processing: currently total over-kill; get it down by orders of magnitude
• Core Challenge #2 – Data Rates:
 uplink: allow for more UL traffic without disturbing current traffic
 downlink: mostly query; maybe embed into control plane downlink: mostly query; maybe embed into control plane
• Core Challenge #3 – Delays:
 Connection Delay: e2e delays need to be improved by orders of magnitude
 Communication Delay: generally solved; however for high rate only
• Core Challenge #4 – Architectural Elements:
 Technical: handling many nodes, group management, HOs, etc, etc.
 Billing: who and how pays the bill; compete with LAN/WLAN/WSNs

M2M Company

The EndThe End
Thank YouThank You

M2M Day Two

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (20)

Similar to M2M Day Two

Similar to M2M Day Two (20)

More from Arief Gunawan

More from Arief Gunawan (20)

Recently uploaded

Recently uploaded (20)

M2M Day Two