The Vault

Enabling Smart Grid with ETSI M2M Standards
Research Paper / Jan 2011

Enabling Smart Grid with ETSI M2M Standards


Guang Lu, Ana Lucia Pinheiro, Dale Seed, Michael Starsinic, Chonggang Wang, Paul Russell

InterDigital Communications, LLC
Email: {first name.last name}@InterDigital.com


Abstract — There are global initiatives underway to establish a
communications framework for Smart Grid systems. These

efforts are led by governments, standardization bodies, and

industry consortiums. This paper analyzes several challenges that

are associated with communicating in Smart Grid systems and

assesses the suitability of using the European

Telecommunications Standards Institute’s machine to machine
architectures and protocols (ETSI M2M) to communicate in

Smart Grid systems. The paper concludes with a presentation of

an ETSI M2M compliant prototyping system that demonstrates

solutions to some of the communications challenges that are
found in Smart Grid systems.

I. INTRODUCTION

The communication system architectures and protocols that
are used to exchange information between connected devices
are critical to the successful deployment of Smart Grid systems.
Devices in Smart Grid systems need to be able to communicate
efficiently, reliably and securely. There are multiple efforts
underway to establish communication architectures and
protocols for the Smart Grid systems. These efforts are led by
governments, standardization bodies, and industry consortiums.
One of the standardization efforts is led by the US National
Institute of Standards and Technology (NIST). NIST has
published an interoperability guideline that provides
requirements and identifies candidate standards to be used in
US Smart Grid systems [1]. The European Commission (EU)
has also initiated a mandate on Smart Grid standardization [2].
The objective of the EU mandate is to develop a set of
consistent standards within a common European framework
that integrates a variety of digital computing and
communication technologies to provide services and
interoperability for European Smart Grid systems.

Besides the many Smart Grid standardization initiatives that
are under way worldwide, there are also numerous initiatives to
standardize machine to machine (M2M) communications.
M2M communications involve the automated exchange of data
between devices, i.e. without or very little human intervention.
Popular M2M uses cases include home automation, fleet
tracking, eHealth, etc. However, there is no use case that is
more prevalent than communication within Smart Grid
systems. Smart Grid systems must be able to automatically
respond to events in the grid without human intervention.

The European Telecommunications Standards Institute
(ETSI) is leading an effort to standardize how M2M
applications exchange information. This paper focuses on
some of the technical challenges associated with Smart Grid
systems and how ETSI M2M standards can be used to address
these challenges.

The remainder of this paper is organized as follows. Section
II provides an overview of some Smart Grid system design
challenges. Section III presents features in the ETSI M2M
standards that address these challenges. Section IV presents an
ETSI M2M compliant prototype system that implements
solutions to some of these challenges. Section V concludes the
paper with a discussion of future work within ETSI M2M.

II. OVERVIEW OF SMART GRID CHALLENGES

Smart Grid systems present communication challenges that
are not found in the power grid and Internet today due to its
large scale and complexity. This section discusses several of
the key challenges.

A. Interoperability and Scalability

NIST defines interoperability as “the capability of two or
more networks, systems, devices, applications, or components
to exchange and readily use information securely, effectively,
and with little or no inconvenience to the user” [1].
Interoperability, or compatibility, allows different systems to
exchange information and take predefined actions in response
to the information. In order to facilitate interoperability,
devices must adhere to a common set of communication
specifications or standards.

Currently, the grid is based on various proprietary and
segmented standards. NIST has identified 25 existing standards
as relevant and important to Smart Grid systems, such as the
IEC standard suite [1], and there are more standards under
evaluation. The challenge is at the regulation level as well as
the technical level to ensure the re-use and migration of
existing standards into the open standard that Smart Grid
systems require.

The GridWise Architecture presented in [3] defines three
layers of interoperability; organizational, informational and
technical. These layers allow the architecture to take into
consideration human aspects when working on interoperability
issues. The GridWise framework is illustrated in Figure 1. with
cross-cutting issues identified.


Figure 1. Interoperability Framework Diagram [3]



B. Security

Security is a critical challenge facing the successful
adoption and deployment of Smart Grid systems. As evidence
of this, NIST defines an extensive list of security requirements
and challenges related to the deployment of Smart Grid
systems [5]. Many of the challenges are related to key
management, authentication, and cryptography issues involving
constrained and/or unmanned systems.

Some examples of these security challenges include:

Limited computational power and/or ability to
store cryptographic material

Low bandwidth communication channels that may
be too slow to exchange large security certificates
frequently

Limited or no connectivity to key servers,
certificate authorities, etc.

Insufficient sources of entropy to randomize
cryptographic keys

In order to overcome these challenges and satisfy the
security requirements of Smart Grid systems, optimized and
efficient security technologies, protocols, and standards are
needed.

C. Device Management

Smart Grid systems will consist of numerous devices such
as sensors, actuators, and smart meters. Hundreds of devices
could be found in a single home or commercial building.
Additionally, numerous monitoring and control devices will be
integrated into infrastructure equipment, such as transformers.
With such a large number of end devices, it is crucial that
Smart Grid system deployments employ a robust device
management strategy.

Traditional components of device management include
fault management, configuration management, account
management, performance management, firmware/software
management, and security management. The ability to remotely
fix, debug, and upgrade smart grid devices is critical towards
reducing overall operating expenses.

The fact that Smart Grid devices have a wide range of
capabilities poses big challenges in the development of remote
management procedures. For example, some devices are
connected using wireline communications (such as power
lines) and others use wireless communications (either short
range or long range). Some devices are kept online all the time,
while others may be battery-powered and periodically go
offline to conserve energy. Also, some devices may be
deployed in harsh environments which make it nearly
impossible to manage them manually after the deployment.
Device management procedures must take into account the
wide range of device capabilities and constraints that are found
in the Smart Grid systems.



D. Demand-Response

Demand response (DR) is one of the eight priority focus
areas for Smart Grid deployments identified by NIST in [1].
DR programs enable customers to shift their consumption to
off-peak hours, thus lowering peak demand [10]. Lowering
peak demand results in decreases in the generation costs and in
the capital expenditures that are required to meet peak demands
[9][10]. Demand response also refers to the real-time
automated response of Smart Grid systems to changes in load,
requests for power, and error conditions.

In order for DR to achieve wide spread deployment,
connected devices need to be capable of adjusting their
demands without human interaction. Devices such as light
switches, home appliances, and commercial machinery need to
communicate with each other and with the grid in order to
make autonomous decisions about when to run and when to
shut down.

The DR challenges described above imply an architecture
where one or more centralized smart meters (or gateways)
enable communication across different physical links and
enable event signaling and data exchange between the devices
and the utility operator. A key challenge in this architecture is
the design of a communication architecture that is suitable for
all devices in the smart grid, from low resource power switches
and appliance controllers, to smart meters, and to servers that
are owned by the utility.

III. OVERVIEW OF ETSI M2M

The European Telecommunication Standard Institute
(ETSI) created a dedicated Technical Committee (TC) to
develop a set of M2M standards. ETSI M2M is working on
various solutions for M2M systems and expects to publish first
releases of several specifications including service level
requirements, architecture-level design, and protocol / API
definitions including information models in 2011. The
following sections provide an introduction of the ETSI M2M
standards being developed and our view of how they can be
applied to Smart Grid systems.

A. ETSI M2M Architecture

ETSI M2M takes a service and application oriented
approach to its architecture design. The ETSI M2M system
architecture includes an M2M Device domain and a Network
and Applications domain [4]. The M2M Device domain
consists of M2M Devices, M2M Gateways and M2M Area
Networks. The Network and Application Domain, referred to
as the M2M Core, contains network components (access
network, transport network, network management) and M2M
components on the network side (M2M network application,
M2M service capabilities, M2M management).

The ETSI M2M architecture introduces the concept of
Service Capabilities (SCs). SCs provide functions that are to be
shared by different applications. SCs include Application
Enablement (xAE), Generic Communication (xGC),
Reachability, Addressing and Repository (xRAR), Remote
Entity Management (xREM), SECurity (xSEC), History and
Data Retention (xHDR), Transaction Management (xTM),



Telco Operator Exposure (xTOE), Interworking Proxy (xIP),
etc. , where „x‟ can represent Network, Gateway, or Device.

Figure 2. illustrates the ETSI M2M architecture. M2M
applications can run on devices, gateways, and networks,
represented as DA, GA, and NA respectively. Due to the
constrained nature of M2M devices, some devices may not
have SCs within themselves. They are called D‟ devices and
they need to connect to the M2M Core via a M2M gateway.
D‟ devices make use of SCs that are in the M2M gateway.
Some devices have SCs locally. They are called D devices, and
may connect to the M2M Core directly, or connect to a M2M
gateway.

ETSI defines three reference points based on open APIs.
The mIa reference point allows an application to access the
M2M SCs in the M2M Core. dIa allows an application residing
in a M2M Device to access the different M2M SCs in the same
M2M Device or in a M2M Gateway; or an application residing
in a M2M Gateway to access the different M2M SCs in the
same M2M Gateway. The mId reference point allows an M2M
Device or M2M Gateway to communicate with the M2M SCs
in the M2M Core.

ETSI M2M is agnostic to the underlying access
technologies. An ETSI M2M device can connect to any area
network (such as ZigBee, WiFi, cellular, DECT, PLC) and the
M2M service platform can be built on top of different core
networks, such as 3GPP CN, ETSI TISPAN CN, 3GPP2 CN,
or WiMax.

In the following sections, we discuss in detail how the ETSI
M2M framework can address the various challenges in Smart
Grid systems identified in Section II.



Figure 2. ETSI M2M Architecture

B. Applying ETSI M2M to Smart Grid Systems

Figure 3. shows a scenario where ETSI M2M standards are
applied to a Smart Grid system deployment. The control
centers can be viewed as domains of M2M Core. The energy
generation system, transmission system, and distribution
system can be viewed as corresponding M2M device domains.
The dotted line represents the digital communication system for
the Smart Grid system, implementing ETSI M2M open APIs,
which can utilize communication networks, such as cellular,
PLC, or fiber optic. The ETSI M2M standards provide

flexibility in terms of how devices are deployed, for example,
the devices can connect to a M2M Core directly, or via
multiple gateways.




Figure 3. Apply ETSI M2M to Smart Grid Systems

C. Interoperability and Scalability

The cross-cutting issues identified in [3] are addressed by
ETSI M2M. For example, the RAR (Reachability, Addressing
and Repository) capability facilitates the handling of resource
identification by providing a mapping between the name of a
network element and a set of routable network addresses. The
HDR (History and Data Retention) capability provides history
and data retention services which allow for logging and
auditing. Transaction management is provided through the TM
(Transaction Management) capability. A set of “Service
Classes”, which are related to a pre-defined set of
communications and connectivity requirements, enables the
support of different QoS requirements. ETSI M2M allows for
automated service discovery, automated service bootstrapping,
as well as device management support for device configuration.
ETSI M2M addresses the system evolution and scalability
aspects of the architecture by defining a service bootstrapping
procedure that is scalable and requires minimal signaling. An
M2M Service Bootstrap Function (MSBF) negotiates
parameters with the devices and facilitates the bootstrap
protocol. The service oriented approach enables that the ETSI
M2M can be deployed in a large scale regardless of underlying
technologies.

D. Security

Due to the critical nature of security in Smart Grid
deployments, ETSI M2M has devoted a great deal of effort in
analyzing the security threats that are applicable to its
application services layer architecture and specifying a set of
corresponding security requirements [6][7].

The goal of this activity is to ensure the proper level of
security of the ETSI M2M application services layer and its
corresponding procedures, while taking into account security
challenges such as those mentioned in section II.B of this
paper. From a security perspective, ETSI M2M leverages a
combination of existing proven technologies and protocols
standardized by other standards development organizations as
well as complementary solutions standardized by ETSI M2M.



The types of security considerations addressed by ETSI M2M
include key management, authentication, and cryptography.

The bootstrapping and registration procedures are good
examples where security considerations have been accounted
for in the ETSI M2M architecture. ETSI M2M is defining
procedures to allow the M2M service layers on M2M Devices,
Gateways and M2M Core to bootstrap and register with one
another in a secure manner. Likewise, ETSI M2M also defines
similar procedures to allow applications to register to M2M
service layers on M2M Devices, Gateways, and M2M Core.
These bootstrap and registration procedures support operations
such as mutual authentication and key establishment.

Rather than supporting a single procedure for bootstrapping
and registration, ETSI M2M recognizes that to support
optimized bootstrapping for a wide spectrum of use cases,
several options and procedures may need to be supported. For
example, ETSI M2M currently supports two independent
procedures for authentication. One procedure is a public key
certificate based approach that relies on the presence of a
Public Key Infrastructure (PKI). A second and arguably lighter
weight procedure, based on the Identity Based Authenticated
Key Exchange (IBAKE) [8] protocol, is also supported. In
addition, ETSI M2M recognizes that for some use-cases
bootstrapping at the M2M services layer may not be optimal or
necessary. For example, bootstrapping may already take place
at other layers in the protocol stack independent of the ETSI
M2M services layer. In these cases, ETSI M2M can leverage
the security credentials established during these bootstrapping
procedures rather than perform its own separate bootstrapping
procedures.

E. Device Management

The ETSI M2M functional architecture defines a Remote
Entity Management (REM) service capability for Device
Management, i.e. NREM for the M2M Core, GREM in the
M2M Gateway, and DREM in the M2M Devices. The xREM
includes the following management functions:

Configuration, performance, and fault
management for M2M applications, services, and
devices

M2M applications and services software
management

The NREM, as a management server, is responsible for
managing the DREM and GREM (both are management
clients) using certain management protocols including the
scenario where M2M Devices are behind an M2M Gateway.
Instead of inventing a new management protocol, existing
protocols including the Device Management (DM) protocol
from Open Mobile Alliance (OMA) [12] and the CPE WAN
Management Protocol (CWMP)/TR069 [13] specified by
Broadband Forum (BBF) are being considered for interactions
between the NREM and DREM/GREM to accomplish the
xREM functions. In order to use OMA-DM and BBF-TR069,
an M2M management objects tree needs to be created in the
NREM that leverages Management Object (MO) data in OMA-
DM and BBF-TR069. New M2M MO data is being specified
and exported to OMA and BBF.

A network application (NA) can initiate and issue an M2M
management command to the M2M Core via the mIa interface.
The command will eventually be processed by NREM, which
will translate the ETSI M2M command to corresponding
OMA-DM or BBF-TR069 commands. OMA-DM and BBF-
TR0690 will be invoked to handle the DM procedures and feed
results back to NREM. The NREM will then forward the
results to NA.

F. Demand-Response

Consider the example of an industrial plant that is part of a
Smart Grid DR system. Several wind mills are constructed
next to the plant and the power that they generated could be
used to run the heavy machinery in the plant during the day.
When the wind mills are not providing a useful amount of
energy, the plant operators monitor power pricing information
which is periodically provided by the utility provider. The
level of production in the plant will be ramped up and down as
the price of electricity falls and rises. On windy nights, when
the plant is shut down, power from the wind mills is sold back
to the utility provider.

Standards such as OpenADR (Automation of Demand
Response) define message formats that can be used for the
exchange of price and reliability information between smart
grid devices such as machinery, wind mills, and gateways.
The ETSI M2M framework provides efficient means for
delivering DR messages such as those defined by OpenADR.
The resource discovery mechanism defined in ETSI M2M can
be used as a mechanism for “discovering” power sources such
as a local source and those provided by the utility. The
resource discovery procedure can also be used to query the
centralized gateway, smart meter, or server for information
about each power resource. The device performing discovery
may choose to use whatever power source is cheapest, most
reliable, or simply decide to run at later time when prices drop.

Suppose the queried resources are all too expensive when
compared against benefits of running the device. It would be
inefficient for the device to constantly query the gateway until
prices fall to a suitable level. The subscription management
procedures within ETSI M2M can be used to “subscribe” to
pricing information that is stored on the gateway. When prices
change, the gateway can notify the device or application of the
update, and a management application could autonomously
decide to turn the device on.

ETSI M2M also provides the announce/de-announce
procedures for resource discovery. The announce procedure
can be used to “announce” the available power to the utility on
windy nights. The utility can then decide whether or not to
purchase the power. In the morning, when plant operations
restart, the gateway may de-announce the power resource so
that the power from the wind mills can be used by the plant‟s
internal machinery.

IV. PROTOTYPING

InterDigital has prototyped an ETSI M2M compliant and
IP-based end-to-end system. The M2M prototyping system
consists of M2M Devices (both D-type and D‟-type), an M2M
Gateway, and an M2M Core, as illustrated in Figure 4.



The M2M Core implements the ETSI M2M
Network and Application domain as defined in the
ETSI M2M functional architecture [4]. The M2M
Core also includes a network application (NA),
which accesses service capabilities in the M2M
Core via the mIa reference point. The M2M Core
is accessible via an IP address and the M2M GW
connects to the M2M Core via a 3G UMTS
connection. The M2M devices access the M2M
Core via a GSM/GPRS connection.

The M2M Gateway implements gateway service
capabilities (SCs) and a gateway application (GA).
The GA is used to control D‟-type devices using
IEEE 802.15.4. The M2M Gateway uses its
UMTS 3G interface and its IEEE 802.15.4
interfaces to bridge the M2M Core and the M2M
D‟-type devices.

M2M D-type Devices have full device service
capabilities and a Device Application (DA) that
connect to the M2M Core directly through a
GSM/GPRS cellular connection.

M2M D‟-type Devices are resource constrained
IEEE 802.15.4 nodes. They have no service
capabilities, but do have a device application
(DA), which communicates with the gateway
service capabilities in the M2M Gateway via the
dIa interface. The D‟-type devices form two
separate M2M area networks running on different
IEEE 802.15.4 channels. Each D‟-type device has
an integrated sensor or actuator such as
temperature sensor, motion sensor, light switch, or
fan. The sensors and actuators are used to
demonstrate behavior such as home automation,
building security, and demand response. The D‟-
type devices use a protocol stack implemented in
BLIP [14] that is based on the IETF 6LoWPAN
protocol [15].



M2M D-type Devices

(GSM Terminal)

Motion

Sensor

Light

Switch

M2M Area Network 2

Buzzer

Motion

sensor
Temperature

Sensor

M2M Area Network 1

M2M Core

M2M Gateway

IEEE 802.15.4

IEE
E 8

02.
15.

4

Cellular

Cellu
lar



Figure 4. M2M Prototyping Architecture



In the following sections we discuss how the M2M
platform demonstrates solutions to some of the challenges in
Smart Grid systems.

A. Interoperability and Scalibility

The prototype provides common interfaces and procedures
that allow remote (device or network) applications to
communicate, enabling a variety of services. It supports a
diverse set of M2M devices that use different access
technologies and protocols to seamlessly communicate with
each other.

The prototype implements a service-oriented architecture.
ETSI M2M “Resources” and “Service Capabilities” are
distributed and they are independent of the physical devices.
“Resources” and “Service Capabilities” are software entities
that reside in entities such as M2M Devices, Gateways and the
M2M Core.

All ETSI M2M messages are transported via the open API
defined in ETSI M2M, using the IETF Constrained Application
Protocol (CoAP) [11] which is based on RESTful methods
such as Create, Retrieve, Update, and Delete (CRUD).

The converged gateway pushes communication and
management functionalities to the edge, providing benefits
such as local services, offloading data and signaling, proxying,
etc.. The gateway architecture enables the hierarchical
integration of M2M services and network scalability.

B. Security

The InterDigital ETSI M2M prototype supports several
ETSI M2M security features including key management,
authentication, cryptography, and device firmware integrity
validation. In addition the prototype supports the M2M service
layer and application bootstrapping and registration procedures.

The prototype‟s current version of key management relies
on provisioning of root keys in the M2M Applications,
Devices, Gateways, and M2M Core. From these provisioned
root keys, session and application keys are derived during the
registration procedures. During this procedure mutual
authentication of M2M Devices, Gateways, and the M2M Core
takes place. In addition, functionality is also included in the
Gateway to support proxying on behalf of D‟ devices for
secure ETSI M2M communication and registration. An
enhanced version of the prototype which supports automated
bootstrapping and key exchange via the IBAKE [8] protocol is
currently under development along with support for Identity
Based Encryption (IBE) [16][17].

The prototype also supports encryption and decryption of
ETSI M2M service layer messages. The current version of the
prototype uses the 3GPP F8 and F9 cryptographic algorithms
for encryption and decryption of M2M messages. However the
prototype is flexible and can be easily modified to use other
cryptographic algorithms.

Security Integrity Validation is also a feature supported
within the prototype which allows a device to check the
integrity of its firmware images when booting up. If an
integrity problem is encountered, the device notifies the M2M
Gateway during its registration procedure. The M2M Gateway
in turn supports a policy engine that it uses to determine
whether the device can be repaired or not. If the device is



repairable, the M2M Gateway performs a firmware update (i.e.
remediation) of the device via an Over-the-Air (OTA) update.

C. Device Management

InterDigital‟s ETSI M2M Prototype supports the following
management functions:

M2M service configuration management such as
querying the version of M2M service capabilities
in the M2M Gateway and D-type Devices

M2M service performance management which
provides performance-related statistics of M2M
service capabilities in the M2M Gateway and D-
type Devices, such as the number of lost M2M
messages, M2M message delay, and M2M service
interruption time. Also, it supports enabling or
disabling the statistics collection

M2M service fault management which provides
fault-related statistics of M2M service capabilities
in the M2M Gateway and D-type Devices, such as
memory allocation failures and devices that
unexpectedly become unreachable. It also supports
enabling or disabling the statistics collection

M2M device application management which
provides OTA programming of M2M D‟-type
Devices.

D. Demand-Response

InterDigital‟s ETSI M2M prototype includes a gateway that
is connected to multiple WPAN networks. The WPAN
networks consist of various sensors and actuators that represent
devices such as heating and cooling systems, motion sensors,
buzzers, thermostats, and a lighting system. The gateway runs
an ETSI M2M compliant application that allows the users to
manage the WPAN networks via an application GUI.

The application GUI can be used to “discover” network
resources. The ETSI M2M resource discovery procedure [4],
is used to discover what devices are connected to the network.
The prototype also supports subscription/notification
mechanisms. The GUI is used to subscribe to events and
configure automatic reactions to the subscribed events. For
example, the user can subscribe to a particular motion sensor
event. The lighting system can be configured to automatically
turn on and the buzzer can be configured to sound whenever
the motion sensor is triggered. The user could subscribe to a
temperature change on a thermostat and this event would cause
the fan to automatically turn on.

The subscription/notification mechanisms that are
implemented in InterDigital‟s prototype demonstrate how DR
requirement can be satisfied using the ETSI M2M framework.
The interactions demonstrated in the prototype between a
motion sensor and a lighting system are no different than the
interactions required between a Smart Grid transmission
system and the transmission control center.



V. CONCLUSION AND FUTURE WORK

This paper analyzed some of the key architectural
challenges associated with communications in Smart Grid
systems and demonstrated that ETSI M2M standards can be
used to meet these challenges. The application and services
based approach of ETSI M2M standards enables the
interoperability and scalability required by Smart Grid systems.
Additionally, the ETSI M2M framework provides features that
facilitate the efficient implementation of requirements such as
security, device management, and demand-response.

The ETSI M2M TC is targeting 2011 for its first release of
the standard. Future releases will follow, with enhanced
features. Additionally, ETSI M2M has started an official work
item to further evaluate ways in which ETSI M2M can be used
in Smart Grid systems.

REFERENCES


[1] “NIST Special Publication 1108 NIST Framework and Roadmap for

Smart Grid Interoperability Standards”, Release 1.0, 2010.

[2] European Commission “Draft Standardisation Mandate to European
Standardisation Organisations (ESOs) to support European Smart Grid
deployment”.

[3] GridWise Interoperability Context-Setting Framework, GridWise
Architecture Council, March 2008.

[4] ETSI TS 102 690 Machine-to-Machine communications M2M)
Functional architecture, draft v0.10.4 (2011-01).

[5] NISTIR 7628 Guidelines for Smart Grid Cyber Security v1.0 – August
2010.

[6] Machine-to-Machine communications (M2M); M2M service
requirements, ETSI TS 102 689 V1.1.1 (2010-08).

[7] Machine to Machine Communications (M2M); Threat Analysis and
Counter-Measures to M2M Service Layer, ETSI TR 103 167 V0.2.1

(2011-01).

[8] V. Cakulev, G. Sundaram, “IBAKE: Identity-Based Authenticated Key
Agreement”, IETF draft draft-cakulev-ibake-03.txt, March 7, 2011

[9] M. McGranaghan, A. Didierjean, and R. Russ, “The Buisness case for a
Consumer Portal to Implement Flexible Pricing, Consumer Services and

Demand Response Programs,” 18th International Conference on
Electricity Distribution, June 2005.

[10] M. H. Albadi and E. F. El-Saadany, “Demand Response in Electricity
Markets: An Overview,” IEEE Power Engineering Society General
Meeting, 2007.

[11] Z. Shelby, et al., “Constrained Application Protocol (CoAP),” draft-ietf-
core-coap-05 (draft), March 2011, (https://datatracker.ietf.org/doc/draft-
ietf-core-coap/)

[12] Open Alliance Mobile (http://www.openmobilealliance.org/)

[13] Broadband Forum (http://www.broadband-forum.org/)

[14] http://smote.cs.berkeley.edu:8000/tracenv/wiki/blip

[15] G. Montenegro, N. Kushalnagar, J. Hui, D. Culler, “Transmisson of IPv6
Packets over IEEE 802.15.4 Networks”, RFC4944, September 2007.

[16] Boyen, X. and L. Martin, "Identity-Based CryptographyStandard (IBCS)
#1: Supersingular Curve Implementations of the BF and
BB1Cryptosystems", RFC 5091, December 2007.

[17] Appenzeller, G., Martin, L., and M. Schertler, "Identity-Based
Encryption Architecture and Supporting DataStructures", RFC 5408,
January 2009.