M2M communication

1. See discussions, stats, and author profiles for this publication at: https://www.researchgate.net/publication/269102010
Efficient and Secure M2M Communications for Smart Metering
Conference Paper · September 2014
DOI: 10.1109/ETFA.2014.7005176
CITATIONS
7
READS
714
6 authors, including:
Some of the authors of this publication are also working on these related projects:
WINEMO View project
Towards Scalable Routing for Mutli-hop Wireless Networks (PhD Thesis) View project
Andre Riker
University of Coimbra
30 PUBLICATIONS 206 CITATIONS
SEE PROFILE
Tiago J. Cruz
University of Coimbra
102 PUBLICATIONS 864 CITATIONS
SEE PROFILE
Marilia Curado
University of Coimbra
245 PUBLICATIONS 1,982 CITATIONS
SEE PROFILE
Paulo Simoes
University of Coimbra
190 PUBLICATIONS 1,165 CITATIONS
SEE PROFILE
All content following this page was uploaded by Tiago J. Cruz on 11 December 2014.
The user has requested enhancement of the downloaded file.

2. Efficient and Secure M2M Communications for
Smart Metering
André Riker∗, Tiago Cruz∗, Bruno Marques†, Marilia Curado∗, Paulo Simões∗, Edmundo Monteiro∗
∗Department of Informatics Engineering, University of Coimbra, Portugal
Email: {ariker, tjcruz, marilia, psimoes, edmundo}@dei.uc.pt
†OneSource, Lda, Portugal
Email: bruno@onesource.pt
Abstract—Machine-to-Machine technology supports several
application scenarios, such as smart metering, automotive, health-
care and city monitoring. Smart metering applications have
attracted the interest of companies and governments since these
applications bring many benefits (e.g. costs reduction and in-
creased reliability) for production, monitoring and distribution
of utilities, such as gas, water and electricity. Multi-hop wireless
communication is a cost-effective technology for smart metering
applications because it extends the wireless range and enables
fast deployment. Smart metering data communicated via wireless
multi-hop approaches needs mechanisms that makes the commu-
nication less vulnerable to security threats and saves the device
resources. Data encryption and data aggregation mechanisms
emerge as potential solutions to fulfill these requirements. How-
ever, the simultaneous execution of data encryption and data
aggregation mechanisms is not a trivial task. This is because
the data encryption prevents the data aggregation mechanism
to summarize the data along the path. Another challenge is to
manage both mechanisms according to the concurrent Machine-
to-Machine (M2M) applications interests. In this context, we
present sMeter, which is a framework that deals with multiple
applications interests, avoiding interest conflicts of concurrent
users and supporting the management of data aggregation and
data encryption. sMeter is implemented using low-cost hardware
in an indoor environment. The communication is performed via
a wireless multi-hop technology, and the performance of this
communication is evaluated in terms of delay, data reception
ratio and received signal strength indication.
I. INTRODUCTION
A machine-to-machine (M2M) system is a large-scale
network with heterogeneous applications and a large number
of connected devices [1]. Smart metering is one of the M2M
applications and is defined as the technological system used to
remotely monitor and control resource utilities (e.g. oil, water,
gas and heat).
Some recent smart metering implementations have used
wireless technologies to communicate data. The main reason
for that is the low-cost involved in the maintenance and deploy-
ment process. In this context, two communication paradigms
are suitable, single-hop and multi-hop. In multi-hop communi-
cation, the nodes transmit their own data or relay data produced
by other nodes. In contrast, in single-hop communication,
all nodes only transmit data directly to the sink node. In
comparison to single-hop, multi-hop communication extends
the wireless network area, reducing the costs of maintenance
and deployment and increasing resilience [2].
However, wireless multi-hop communication has some
drawbacks when compared with single-hop communication.
Multi-hop traffic has higher delay due to the retransmission
process necessary for the communication [3]. Another multi-
hop issue is related to the data privacy. In multi-hop commu-
nication, relay nodes forward data produced by other nodes
in the network, making necessary the usage of mechanisms
to preserve the data privacy, for example data encryption.
Besides the data encryption mechanisms, data aggregation
mechanisms are necessary for smart metering applications that
use wireless multi-hop communication. In general, data aggre-
gation mechanisms reduce the amount of data communicated
in the data collection process, applying statistical functions
(e.g. maximum, minimum, average, count and sum) on the
data [4].
In this context, this paper addresses two issues. The first
is related to the, simultaneous, execution of data aggregation
and data encryption mechanisms. The second involves the
management of these mechanisms, meeting the requirement
of concurrent users. Regarding the first issue, data aggregation
functionalities are not compatible with end-to-end encryption
approaches. This is because, end-to-end encryption prevents
the intermediate nodes to access the data content. Another data
encryption approach is the hop-by-hop, which allows the data
decryption at each hop. However, it delays the communication
and consumes more energy and bandwidth due to the hop-by-
hop overhead. Regarding the second issue, the M2M system
has driven to a M2M platform that promotes the sharing of
functionalities and information between different applications.
The M2M platform should be able to manage the multi-hop
communication as well as the data gathering mechanisms such
as data aggregation and data confidentiality. According to the
applications and users requirement, the M2M platform should
coordinate the multi-hop path selection, and update the data
aggregation and data confidentiality settings on the devices.
Many of the current implementations of smart metering
use single-hop communication, preventing the nodes to take
advantages of cost-effective multi-hop communication. On the
other hand, most of the smart metering applications that use
multi-hop communication do not address the management of
data aggregation and data confidentiality mechanisms. There-
fore, this paper aims to describe an framework, named sMeter,
located in the M2M platform that provides the management
of data aggregation and data confidentiality mechanisms. This
paper shows the implementation of sMeter in an indoor smart

3. metering application, using low-cost hardware, and shows the
performance of the wireless multi-hop communication.
The remainder of this paper is structured as follows.
Section II shows background information about smart metering
applications and M2M. Section III presents some open issues
of smart metering. Section IV introduces the sMeter architec-
ture and Section V describes the experiments. Finally, Section
VI presents the conclusions.
II. BACKGROUND
Smart metering applications are deployed in indoor as
well as in outdoor environments. In some cases, the smart
metering monitors companies asset, while in other cases it
senses domestic environments. The sections below address the
smart metering general concepts, the M2M architecture used
to communicate smart metering data, the M2M platform, and
the main concepts of data aggregation and data encryption
mechanisms.
A. Smart Metering Applications
The aim of smart metering is to measure the consumption
of the utilities and control the assets (e.g. drills, wells and
pipelines), during the process of extraction, transport and
distribution. Smart metering applications provide valuable in-
formation that benefits consumers, suppliers and utility distrib-
utors. Smart metering supports the monitoring of the resource
usage throughout the day, enabling costumers to make smarter
decisions about how to control the resources utilization. More-
over, consumers could use Smartphone applications to create a
usage planning (e.g. adjust the thermostats before people leave
the house, and set a suitable temperature for the time when the
people return).
In addition, with smart metering, the suppliers understand
better the needs of the customers, and the distributors have
better tools to manage and monitor their networks. Smart
metering is a very important tool since there are several
factors that influence the supply of utilities, such as weather,
generation, demand, malfunctions and failures. By monitoring
these factors, smart metering collects periodical information
about utility usage, or about outage, tamper events, voltage
and diagnostic flags. Controlling this critical information, the
suppliers are in a better position to make business decisions,
improve service reliability, and enhance customer satisfaction.
B. Generic M2M Architecture
The combination of wired and wireless network technolo-
gies may result in several variants of network architectures
able to provide communication for the M2M systems. By inte-
grating network technologies, some solutions have shown the
M2M network architecture as a Heterogeneous Hierarchical
Architecture (HHA) [5] and [6].
As can be observed in Fig. 1, the Sensor and Actuator
Nodes directly interact with the real environment, collecting
data (e.g. temperature, power, voltage and electric current)
and triggering electronic circuits (e.g. regulation or switches
off/on). The hardware capabilities of the Sensor and Actuator
are restricted in terms of Central Processing Unit (CPU),
battery autonomy and memory. This limited hardware capacity
imposes severe restrictions on the functionalities carried out by
these devices.
The Monitoring Nodes may receive data from the Sensor
and Actuator Nodes via Zigbee [7], Radio Frequency, RFID
or wired technologies. In addition, many Sensor and Actuator
Nodes may be connected to a single Monitoring Node.
Applications
Monitoring Nodes
Sensors and Actuators
Cloud M2M Platform
RFID RF ZigBee Wired
WiFi 3G Ethernet
Apps Utilities Entities
Fig. 1: Network Architecture of M2M Communication.
The Cloud M2M Platform receives the information col-
lected by the Monitoring Nodes, and this communication may
be performed by WiFi, 3G or Ethernet technologies. The Cloud
M2M Platform uses Backend Servers equipped with powerful
hardware resources which are able to process a large amount
of data [8].
Several stakeholders and entities may be interested on
M2M data. With different authorizations, some stakeholders
only access data stored in the Cloud M2M Platform, while
other entities have an additional authorization to change de-
vices settings, for instance update the communication period-
icity.
The M2M communication depends on several interfaces
between various parties, stakeholders, business logic network-
ing and the roles of M2M partners [9], [10]. Most of these
factors are open and have not been yet completely defined.
Thus, the HHA is a tentative design for an appropriate M2M
Architecture, being susceptible to alterations.
C. M2M Platforms
The M2M platform can be defined as a software layer that
enables the M2M applications to access their devices by using
a common set of services [11]. The wide range of devices
in terms of capabilities, software complexity and costs, and
the necessary interoperability between many stakeholders, have
resulted in the adoption of a M2M platform [12].
The traditional way of establishing a M2M communication
does not encompass a M2M platform. In the traditional M2M
communication, each device establishes a direct connection
with the application and each application communicates data

4. Fig. 2: Functional Architecture of M2M Platform.
by using its own protocols [13]. However, when the tradi-
tional method is used, the share-capability and interoperability
between the stakeholders become restricted [14].
The M2M platform enables the interaction of different
applications from different stakeholders and reduces the pro-
gramming costs. To ensure the future of M2M communication,
it is essential to develop an efficient platform layer that is able
to support the interaction of multiple applications and provide
them with a common application infrastructure [15].
According to the European Telecommunications Standards
Institute (ETSI) [16] (see Fig. 2), the platform is composed
of two service layers: the M2M network capability layer and
the M2M gateway capability layer. The first is implemented
in the backend servers and the second is implemented in
M2M Gateways [17]. The mId is the interface that enables
the backend server applications to access the M2M network
capability layer. On the other hand, the dla interface enables
the Gateway/Devices applications to access the M2M gateway
capability layer. Finally, the mIa is the virtual link between the
two capability layers (Network and Gateway) [18].
It is very important to observe that the Remote Entity
Management capability enables multiple M2M entities to per-
form concurrent actions (e.g. data queries based on criteria)
on the M2M devices. The Network Reachability, Addressing
and Repository capability is responsible to resolve the data
queries and to find and to manage the group of devices
that will provide the data. Therefore, the network solutions
should take into account these groups to improve the M2M
communication.
D. Data Aggregation
Data aggregation solutions explore the spatio-temporal cor-
relations to summarize the amount of data generated by sensor
nodes. Data aggregation decreases drastically the amount of
resources used to communicate data. To save the devices
resources, the amount of data should be reduced as much as
possible [19]. Thus, the data aggregation approaches inspect
messages and apply aggregation function on the data during
the multi-hop communication, summarizing the data along the
path. The aggregation functions eliminate duplicate messages,
merger many message payloads in a single header, or compute
statistical data (e.g. Count, Minimum, Maximum, Sum and
Average) [20].
The efficiency of data aggregation is, strongly, influenced
by the path selection scheme. So, usually, data aggregation so-
lutions have a suitable path selection algorithm [21]. The path
selection scheme designed for data aggregation is designed
to achieve many objectives. Examples of data aggregation
objectives are: minimize the amount of data communicated,
minimize the end-to-end delay and satisfy levels of data accu-
racy. Some proposals deals with theses objectives separately,
while other tries to cope, simultaneously, multiples objectives.
E. Data Confidentiality
Smart metering applications communicates information
that could reveal the living routine of a home or a company.
Moreover, data confidentiality mechanisms are even more
needed in wireless multi-hop communication, as considered
in this paper. Thus, mechanisms that support the protection of
data privacy are essential for smart metering applications, since
they prevent outsiders from eavesdropping on the wireless
communication. Data encryption is a well-known technique
to provide data privacy. Data encryption approaches use an
encryption key to change the message content. Without the
encryption key, the nodes can not access the content of the
encrypted messages [22]. Thus, data encryption is an approach
that maintains the data privacy even in case an malicious node
intercepts the communication.
The data encryption solutions may be divided in two
groups of solutions, namely, end-to-end and hop-by-hop [23].
In end-to-end solutions, the intermediate nodes do not have
the encryption key, so they do not access the content of the
communication. On the other hand, in a hop-by-hop approach,
every intermediate nodes performs the following tasks: receive

5. encrypted messages, decrypt the messages, access the mes-
sages content for a given purpose, encrypt the messages again
and transmit the messages [24].
After describing the main concepts of smart metering and
the M2M architecture, the next section clarifies the open issues
addressed in this paper.
III. OPEN ISSUES
Two relevant open issues are identified. The first is related
to mechanisms that promote the data gathering from the nodes.
The second is related to the M2M platform. More details are
given on the next sections.
A. Data aggregation and encryption mechanisms
Most of the data aggregation solutions suppose that the
nodes are trustable and secure, so these solutions are not de-
signed to protect the confidentiality of the data communicated.
On the other hand, several data encryption solutions, mainly
the end-to-end approaches, are not designed for in-network
data aggregation, since the intermediate node can not access
the data content, preventing the data aggregation functionalities
to be executed. In addition, the hop-by-hop data encryption
solutions increase the communication delay and overhead.
Therefore, the design and implementation of solutions that
assure resource savings and confidentiality protection represent
an open issue for smart metering.
B. Manage data gathering mechannisms to meet concurrent
users interests
The functionalities of the M2M platform that promote the
transparent management of data gathering mechanisms, such as
data aggregation and data encryption, is a challenge, since the
solutions are designed for a single user, and do not consider
the existence of multiple and concurrent user with different
interests. The management of these mechanisms needs to
allow the users to interact with the system in high-level of
abstraction, or inferring the costumers context and making
auto-adjustments on the data accuracy settings. For instance, in
some moments, the user may be interested to know the overall
utility consumption. In other moments the costumers need to
know the raw data of every device. The open issue consists in
providing this management for concurrent users, avoid users
settings conflicts and meeting the concurrent users interests,
as much as possible.
IV. SMETER ARCHITECTURE
The solution proposed by this paper, called sMeter, enables
the smart metering system to communicate using data aggrega-
tion and data encryption, as well as it supports the transparent
management of these mechanisms. Besides, sMeter uses the
Open Energy Monitor [25], which is open source software
that enables data fusion and data visualization.
Figure 3 shows how the sMeter components interact. First,
the Settings interface supports the change of data gathering
settings in a high level of abstraction. Using this interface
the user entities adjust the data gathering functionalities.
Listing 1 presents an example of a message produced by
the Settings interface, configuring the communication peri-
odicity, the aggregation function, the rate sensing and group
criteria. Second, the Data Gathering Management updates the
Monitoring Nodes according to the users configurations, and
manages the data gathering settings to avoid conflicts between
the concurrent users interests. Third, the Monitoring Nodes
executes the settings defined by the system, sending data to
the sink node, which stores the collected data in the data base
system. Fourth and fifth, the Open Energy Monitor accesses
the data base, and provides data fusion and data visualization
for users.
Fig. 3: sMeter Components and Interactions.
Listing 1: Data Request Message Example
1 <DataRequest>
2 <id> A </ id>
3 <Frequency> 1 </ Frequency>
4 <DelayTolerance> 0.5 </ DelayTolerance>
5 <AggFunction> Max </ AggFunction>
6 <G r o u p C r i t e r i a>
7 <LocationLat> 40.20 </ LocationLat>
8 <LocationLon> −8.42 </ LocationLon>
9 <Range> 100 </ Range>
10 </ G r o u p C r i t e r i a>
11 </ DataRequest>
To avoid settings conflicts, the Users Conflict Resolver
keeps track of the current data gathering settings. In case of
setting conflicts, the Users Conflict Resolver finds alternatives
to avoid the data gathering conflict. For example, two users
request, for the same group of nodes, data aggregation using
different aggregation functions. To avoid the conflict, the Users
Conflict Resolver updates the involved Monitoring Nodes to
produce two data aggregation outputs, one for each aggregation
function. In case of communication periodicity conflict, the
Users Conflict Resolver finds the smallest common number.

6. As the data aggregation mechanism may execute a sta-
tistical aggregation function or only header suppression, and
the data encryption mechanism may execute end-to-end or
hop-by-hop encryption, sMeter may use these different data
aggregation and data encryption seetings to control the data
gathering mechanisms. The combination of each profile pro-
duces communication performance, in terms of delay, level
of security and energy consumption. In sMeter, the profiles’
selection is made to maintain appropriate levels of perfor-
mance, which may be specified by the user. In case the user
specifies the tolerable delay and level of security, the selected
profile should satisfy the user requirements, minimizing the
energy consumption. In the case the user does not specify any
explicit requirement, sMeter can infer what is the best, based
on context information (e.g. historical and social network).
V. EXPERIMENTS
This Section describes the settings used to configure the
experiments as well as the results obtained in a real scenario
of smart metering.
A. Set Up
To evaluate the communication performance of sMeter, real
experiments were executed in an indoor environment. Five
Monitoring Nodes were placed in two rooms (see Fig. 4).
The sink device has two network connections, WiFi (IEEE
802.11g) and Ethernet (IEEE 802.3), and all other devices have
only the IEEE 802.11g connection.
Sink node
Open Energy
Monitor
Node 2
Node 4
Node 3
Node 1
Room 1 Room 2
Hall
Wireless Link
Wired Link
Fig. 4: Devices deployment.
The Optimized Link State Routing (OLSR) [26] protocol
was configured in the nodes, enabling the Multi-hop Wireless
Communication. In this scenario, nodes 1, 2, 3 and 4 transmit
their data readings to the sink node every second, during 15
minutes. Many of these communications were executed via
multi-hop, according to the OLSR behavior. In addition, Table
I presents additional configuration parameters.
The hardware platform used to implement the Monitoring
Nodes is presented in Fig. 5. These devices are Raspberry Pis
equipped with an ARM 32 bits processor running at 700 Mhz,
512 Mb RAM and with an IEEE 802.11g interface.
Parameter Value
Number of Nodes 5
Number of Traffic Flows 4 and 8
Communication Periodicity 1 s
Routing Protocol OLSR
Routing Metric ETX
Wireless Technology IEEE 802.11g
Packet Length 56 bytes
TABLE I: Configuration Parameters.
Fig. 5: Monitoring Node Prototype.
In addition, the Monitoring Nodes use an unique authen-
tication key, previously configured, to communicate with the
Data Base. The Data Base verifies the authentication key when
it receives data from the nodes. This verification is necessary
to avoid unauthorized nodes to communicate data.
The initial objective of this experiment is to evaluate the
performance of the multi-hop communication. Therefore, the
Monitoring Nodes were not configured to execute any Data
Aggregation or Data Encryption mechanism.
B. Results
Figure 6 presents the Received Signal Strength Indication
(RSSI). Due to the utilization of the OLSR protocol, the RSSI
value does not measure the RSSI of a particular wireless link,
since many wireless links are likely to transmit data. Thus,
this RSSI value is the average RSSI of every wireless link
that communicated data. After clarifying that, it is possible
to notice that node 3 has the lowest RSSI values, which is on
average around 60 dBm. The level of noise in the environment
is 0 dBm and it is almost constant for all devices.
The Round Trip Time (RTT) measured the communication
delay, which can be defined as the time necessary to transmit a
message and receive its acknowledgement. Figure 7 reveals the
RTT when all nodes transmit data to the sink. The obtained
RTT values are proportional to the average number of hops
executed in the wireless communication. Nodes 1, 2, 3 and 4
used, on average, 1, 3.8, 3 and 2 hops to communicate their
data to the sink. Therefore, the number of hops has a strong

7. 52
54
56
58
60
62
64
66
68
70
72
74
Sink
Node
1
Node
2
Node
3
Node
4
RSSI
(
dBm)
Fig. 6: RSSI.
influence on the communication delay. In addition, the commu-
nication between node 2 and sink can be performed using paths
with different number of hops (e.g 4, 3 or 2). The selection of
heterogeneous paths results in higher standard deviation, and
consequently produces larger confidence interval.
0
2
4
6
8
10
12
14
16
Node
1
Node
2
Node
3
Node
4
RTT
(
ms)
Fig. 7: RTT.
Figure 8 shows the percentage of Packet Reception Ratio
(PRR). To measure the PRR of all nodes, in addition to the
fours traffic flows (all node transmitting to the sink), the reverse
communications also were established (sink transmitting to all
nodes), otherwise only the sink PRR would be measured. It
is possible to notice that node 3 and sink had the lowest and
best percent of PRR, respectively.
VI. CONCLUSION AND FUTURE WORKS
Smart metering is one of the important M2M scenarios that
have attracted the investments of companies and government.
Cost-effective communication solutions designed for smart
metering applications represent an important advance for the
use of this technology, since the high cost of smart metering
applications is, usually, due to the deployment of a large
number of devices.
Using Raspberry Pis and multi-hop wireless communi-
cation, the smart metering devices are able to be deployed
and operated in a fast and low-cost manner. Moreover, the
smart metering application covers a large wireless area, making
82
84
86
88
90
92
94
96
98
100
Sink
Node
1
Node
2
Node
3
Node
4
Packet
R
ecep*on
R
a*o
(
%)
Fig. 8: Packet Reception Ratio.
the communication more cooperative, increasing the com-
munication reliability. However, the feasibility to use multi-
hop wireless communication in smart metering application
depends on many factors, such as the data confidentiality, data
aggregation and the transparent management of data gathering
mechanisms.
This paper presents the practical implementation of the
sMeter application, which is a framework designed for data
aggregation and data encryption mechanisms, and to promote
the appropriate management of these mechanisms. In the
current stage of sMeter, only the performance of the wireless
communication is evaluated. This performance is obtained
from experiments executed in an indoor environment, and it
was measured in terms of Round Trip Time, Received Strength
Signal Indication and Packet Received Ratio. The values of
these metrics show the feasibility of sMeter in scenarios
requiring multi-hop communication.
The next steps are the implementation of data aggrega-
tion and encryption profiles, evaluation the communication
performance for each combination of profile, and design of
a mechanism to infer the user preference based on the user
context.
ACKNOWLEDGMENT
We would like to acknowledge the preliminary experimen-
tations performed by Inłs Rodrigues, Leonel Morais and Pedro
Morais. This work was partially funded by the sMeter project;
and iCIS project, under the grant CENTRO-07-ST24-FEDER-
002003; and CAPES/CNPq (Brazil) through the Ciencia sem
Fronteiras Program/2013.
REFERENCES
[1] A. Lo, Y. W. Law, and M. Jacobsson, “A cellular-centric service
architecture for machine-to-machine (m2m) communications,” Wireless
Communications, IEEE, vol. 20, no. 5, pp. 143–151, 2013.
[2] I. F. Akyildiz and X. Wang, “A survey on wireless mesh networks,”
Communications Magazine, IEEE, vol. 43, no. 9, pp. S23–S30, 2005.
[3] T. Wang, C. Wu, P. Ji, and J. Zhang, “A noble data aggregation
algorithm for low latency in wireless sensor network,” in Mechatronics
and Automation (ICMA), 2010 International Conference on. IEEE,
2010, pp. 894–898.
[4] E. Fasolo, M. Rossi, J. Widmer, and M. Zorzi, “In-network aggregation
techniques for wireless sensor networks: a survey,” Wireless Communi-
cations, IEEE, vol. 14, no. 2, pp. 70–87, 2007.

8. [5] J. Zhang, L. Shan, H. Hu, and Y. Yang, “Mobile cellular networks
and wireless sensor networks: toward convergence,” Communications
Magazine, IEEE, vol. 50, no. 3, pp. 164 –169, march 2012.
[6] N. Tekbiyik and E. Uysal-Biyikoglu, “Energy efficient wireless unicast
routing alternatives for machine-to-machine networks,” Journal of Net-
work and Computer Applications, vol. 34, no. 5, pp. 1587–1614, 2011.
[7] Z. Alliance, “Zigbee specification,” Document 053474r06, Version,
vol. 1, 2006.
[8] K. Matoba, K. Abiru, and T. Ishihara, “Service oriented network archi-
tecture for scalable m2m and sensor network services,” in Intelligence in
Next Generation Networks (ICIN), 2011 15th International Conference
on, oct. 2011, pp. 35 –40.
[9] O. Jumira and R. Wolhuter, “Value chain scenarios for m2m ecosystem,”
in GLOBECOM Workshops (GC Wkshps), 2011 IEEE, dec. 2011, pp.
410 –415.
[10] V. Gonçalves and P. Dobbelaere, “Business scenarios for machine-
to-machine mobile applications,” in Mobile Business and 2010 Ninth
Global Mobility Roundtable (ICMB-GMR), 2010 Ninth International
Conference on, june 2010, pp. 394 –401.
[11] A. S. Tanenbaum and M. Van Steen, Distributed systems. Prentice
Hall, 2002, vol. 2.
[12] S.-K. Zhang, J.-W. Zhang, and W. Li, “Design of m2m platform based
on j2ee and soa,” in E-Business and E-Government (ICEE), 2010
International Conference on, may 2010, pp. 2029 –2032.
[13] Y. J. Kim, E. K. Kim, B. W. Nam, and I. Chong, “Service composition
using new dson platform architecture for m2m service,” in Information
Networking (ICOIN), 2012 International Conference on, feb. 2012, pp.
114 –119.
[14] Y. Yang, H. Ye, S. Fei, Y. Yang, H. Ye, and S. Fei, “Design of
communication interface for m2m-based positioning and monitoring
system,” in Electronics, Communications and Control (ICECC), 2011
International Conference on, sept. 2011, pp. 2624 –2627.
[15] A. Herstad, E. Nersveen, H. Samset, A. Storsveen, S. Svaet, and
K. Husa, “Connected objects: Building a service platform for m2m,”
in Intelligence in Next Generation Networks, 2009. ICIN 2009. 13th
International Conference on, oct. 2009, pp. 1 –4.
[16] ETSI, “Functional architecture,” ETSI TS 102.169 Machine-to-Machine
communications, 2010.
[17] S.-Y. Lien, K.-C. Chen, and Y. Lin, “Toward ubiquitous massive ac-
cesses in 3gpp machine-to-machine communications,” Communications
Magazine, IEEE, vol. 49, no. 4, pp. 66 –74, april 2011.
[18] T. ETSI, “Interfaces: mia, dia and mid,” ETSI TS 102.921 Machine-to-
Machine communications, 2010.
[19] H. S. AbdelSalam, S. R. Rizvi, and S. Olariu, “Energy-aware task as-
signment and data aggregation protocols in wireless sensor networks,” in
Consumer Communications and Networking Conference, 2009. CCNC
2009. 6th IEEE. IEEE, 2009, pp. 1–5.
[20] A. Manjhi, S. Nath, and P. B. Gibbons, “Tributaries and deltas: efficient
and robust aggregation in sensor network streams,” in Proceedings of
the 2005 ACM SIGMOD international conference on Management of
data. ACM, 2005, pp. 287–298.
[21] R. Rajagopalan and P. Varshney, “Data aggregation techniques in sensor
networks: A survey,” 2006.
[22] S. Ozdemir and H. Çam, “Integration of false data detection with data
aggregation and confidential transmission in wireless sensor networks,”
IEEE/ACM Transactions on Networking (TON), vol. 18, no. 3, pp. 736–
749, 2010.
[23] J. Albath and S. Madria, “Secure hierarchical data aggregation in
wireless sensor networks,” in Wireless Communications and Networking
Conference, 2009. WCNC 2009. IEEE. IEEE, 2009, pp. 1–6.
[24] J. Shi, Y. Zhang, and Y. Liu, “Prisense: privacy-preserving data aggre-
gation in people-centric urban sensing systems,” in INFOCOM, 2010
Proceedings IEEE. IEEE, 2010, pp. 1–9.
[25] T. Lea, “Open energy monitor,” 2014. [Online]. Available: www.
openenergymonitor.org/
[26] T. Clausen, P. Jacquet, C. Adjih, A. Laouiti, P. Minet, P. Muhlethaler,
A. Qayyum, L. Viennot et al., “Optimized link state routing protocol
(olsr),” 2003.
View publication stats
View publication stats