Application-derived Communication Protocol ...

4 downloads 7544 Views 348KB Size Report
Email: {andreea.ancuta.corici, alex.bourreau, ... gateways to an M2M server platform. Keywords— IoT; M2M ... implementation using OpenMTC, an M2M platform enabling ..... consider here the substation automation application for.

Application-derived Communication Protocol Selection in M2M Platforms for Smart Cities Asma Elmangoush, Ronald Steinke, Thomas Magedanz

Andreea Ancuta Corici, Alex Bourreau, Adel AlHezmi

Technical University of Berlin Berlin Germany Email: [email protected], {ronald.steinke, thomas.magedanz}

Fraunhofer Institute FOKUS - competence center Next Generation Network Infrastructures (NGNI) Berlin Germany Email: {andreea.ancuta.corici, alex.bourreau, adel.alhezmi}

Abstract— Linking the communication and the information technology infrastructures forms the new Machine-to-machine (M2M) communication trend. We aim to exploit available standard protocols to support smart cities applications. In this paper, we report the work of implementing and evaluating the performance of using request/response protocols for M2M communications. The paper also introduces a mechanism to select the proper communication technology based on the exchanging M2M traffic pattern from sensors/devices and gateways to an M2M server platform. Keywords— IoT; M2M; Transport Protocols; Smart Cities

I. INTRODUCTION Machine-to-Machine (M2M) communications shall enable every physical and virtual object to integrate seamlessly into a large-scale infrastructure without human intervention. This applies and reinforces a convergence of heterogeneous technology families in various layers (application, transportation and physical) to accommodate the technical communication and service requirements. Unlike traditional human-to-human (H2H) or human-to-machine (H2M) services, which mainly involves multimedia sessions, messaging, web browsing and remote control, M2M services have different features and communication requirements [1]. M2M communication provides the opportunity of deploying new services and engaging various kind of connected objects with different domain-specific applications. This leads to new type of traffic profiles and patterns emerged in the Future Internet (FI). The traffic generated from connected devices will have a huge variety in payload size and traffic rate due to the heterogeneity in both devices’ capabilities, and the content nature. The principle of limiting human interaction in M2M systems and integrating billions of devices with heterogeneous computational capabilities into it demands a fully network and application agnostic system. The main challenges are driven from integrating low-power devices and low bandwidth networks. In this paper, we originally propose to exploit available standard protocols to support smart city applications. In

particular, we report the experience of implementing and evaluating the performance of using HTTP and CoAP protocol in exchanging M2M traffic from sensors/devices to an M2M server platform. After comparing the protocols, we introduce a novel concept for adapting the transport protocol parameters according to the application requirements. The rest of the paper is organized as follows: Section II overviews the related work on transporting protocols used in the M2M communications. Section III highlights some M2M use cases and discusses the communication requirements accordingly. Section IV describes the concept of adapting the transport protocol information according to the application. Section V presents the implementation using OpenMTC, an M2M platform enabling the Internet of Things (IoT). Section VI presents the evaluation results obtained in the research work. Finally, section VII concludes the paper. II. BACKGROUND The current M2M related technologies landscape is highly fragmented. As figure 1 illustrates, the protocol stack for the M2M communication includes various standardized protocols at transport, network and data link layers. In [2], a survey of a standardized protocol stack for IoT is presented, focusing on power-efficient wireless communication. Typically, M2M applications utilize IP-compatible open protocols that are standardized, in order to be widely deployable. Recently, various protocols have been proposed to the IoT development, aiming to address the requirements of integrating resourceconstrained devices and supporting ubiquitous access. In the following subsections we analyze some of the protocols and overview the work related to our topic. A. Hypertext Transfer Protocol (HTTP) HTTP is an application layer protocol designed within the framework of the IP suite (RFC 2616). The protocol is welltried and powerful, but it’s relatively expensive both in implementation code space and network resource usage. Though, its definition presumes an underlying and reliable transport layer protocol and TCP/IP is most commonly used, however it can use unreliable protocols such as the User Datagram Protocol (UDP) as well [3]. HTTP is widely

supported on different kind of computing devices (i.e., smartphones and tablets); however it might not be suited for all M2M applications due to its resource-demanding nature. B. Constrained Application Protocol (CoAP) The Constrained Application Protocol (CoAP) was proposed by the IETF Constrained RESTful Environments (CoRE) working group, and recently confirmed (RFC 7252) [4], to support constrained devices (i.e., with low computational/memory capabilities) and networks, such as those expected to form the IoT. To facilitate the implementation on similar devices, a number of design choices have been considered including: i) the use of UDP as the transport layer protocol to avoid the overhead of connection oriented protocols; ii) efficient packing of protocol information in the header, which can be as small as 4 bytes. CoAP is a lightweight client/server application protocol, which supports the Representational State Transfer (REST) paradigm, through a request/response model using four request types: GET (i.e., retrieve the content of the resource), POST (i.e., create a new resource), PUT (i.e., update the content of an existing resource), DELETE (i.e., remove a resource). Similar to HTTP, CoAP is a stateless protocol that identify resources through Unique Resource Identifiers (URI), e.g., coap://

C. Message Queue Telemetry Transport (MQTT) MQTT [5] is an open protocol specified by IBM and Eurotech, and recently it is used by the Eclipse foundation in M2M applications. The protocol was designed to be simple and lightweight in order to be suitable for constrained devices. The MQTT protocol adapts the Publish/Subscribe (PS) module and uses long-lived outgoing TCP connections to a broker node.




MQTT is also used by Facebook in implementing a fast lightweight asynchronous messaging protocol. D. Advanced Message Queuing Protocol (AMQP) Similar to MQTT, AMQP is a binary open protocol that provides a very much richer set of messaging scenarios. AMQP comes from the finance community, designed to efficiently support a wide variety of messaging applications and communication patterns. AMQP supports different acknowledgment uses cases and transactions across message queues; it allows separation of the different transactional semantics.

Fig. 1. Heterogonous M2M protocol Stack

E. Protocol Classification The previously described protocols could be categorized under two main communication paradigms: • The Request/Response (RR) model, commonly used in distributed system to exchange information through message passing between a sender and a receiver. The RR model adapts the polling mechanism to enable users to retrieve the state of other entities.






Architecture Style Transport

Client/server model RESTful TCP

Client/server model RESTful UDP



Message size

Service levels (QoS) Data distribution Security



Proposed OASIS standard MQTT Brokered style

Brokered style





Larger, partly because status detail is textbased

Small to fit in single IP datagram. Header 4 bytes

Up to 256 MB Header 2 bytes

Publish/Subscribe (P2P or Brokered) Unlimited Header 8 byte

All messages get the same level of service One-to-one

Confirmable or nonconfirmable messages One-to-one

(Typically based SSL or TLS)

(Typically based SSL or TLS)

Three quality of service settings One-to-one , and oneto-many Simple Username/Password Authentication, SSL for data encryption




Different 3 QoS levels One-to-one , and oneto-many SASL authentication, TLS for data encryption

• The Publish/Subscribe (PS) model, which is based on an event broker to forward updates (notifications) to interested users (subscribers), regarding changes of senders’ (publishers’) statuses. The RR model is adapted in common transport protocols like HTTP and CoAP, applying the RESTful architecture. Other protocols adapting the PS model include MQTT and AMQP. F. Related Work The authors in [6] analyze the strengths and weaknesses of both paradigms in supporting communications in ubiquitous systems. The authors conclude that the communication semantics of the developed solution is the main criteria to choose which model to implement. On the one hand, the polling mechanism used in RR model is considered insufficient to be implemented within systems that have infrequent status changes. On the other hand, the PS model lacks the end-to-end delivery reliability due to the existence of intermediary entities (broker) between publishers and subscribers. Relatively few studies have been published on evaluating comparison between transport protocols for the IoT. A comparative study of both CoAP and HTTP, published in [7], shows by means of simulation the benefits of CoAP in terms of energy consumption and response time comparing to HTTP. Another study of performance evaluation in terms of latency, memory occupation, and energy consumption for CoAP and HTTP over both TCP and UDP is presented in [3]. The authors of [8] present a compression of MQTT-S and COAP by means of simulation. The study observes that the maximum achieved Discarded Publication Ratio (DPR) by CoAP is better than what is achieved by MQTT-S [9]. MQTT-S is currently known as MQTT-SN and aiming to extend the MQTT protocol beyond the reach of TCP/IP infrastructure for sensors and actuators. III. COMMUNICATION REQUIREMENTS DRIVEN FROM M2M USE CASES

The idea of the IoT and M2M communication are evolving

TABLE II. Use Case Mobility Latency tolerant

Traffic pattern Message size Device density

based on existing Internet infrastructure to facilitate the representation of addressable objects. Additionally, new protocols and technology are being developed in this domain, to address the requirements of emerging services in heterogeneous environments. There are a lot of domains and environments in which M2M communication is likely to improve the quality of our lives, such as smart buildings, transportation, healthcare etc. Almost all Standards Development Organizations (SDOs) started their work in M2M communication by defining the common requirements of various Smart Services [10][11][12]. Table 2 overviews the communication requirements of some selected M2M use cases. It is widely agreed that the end-toend aspects of communication between M2M devices and servers are critical to many applications [13][14]. Most important are the strict requirements on the end-to-end delay of packets transmitted, which should be maintained when building/designing the end solution architecture. Current communication platforms are optimized for human-tohuman (H2H) communications, and require essential improvements to support: •

The heterogenetic nature of connected objects and their capabilities;

new trend of traffic patterns [15];

decoupling the diverse service underlying access technologies; and

managing large amounts of data/resources efficiently.



As not all M2M nodes will support every transport protocol that is defined for M2M services, the M2M gateway will have to translate from one protocol to another. We now consider that in a smart building all the energy meters will perform a firmware update during the night and afterwards transmit log information based on the result of the operation. All the M2M gateways serving the smart meter devices will act as the closest hop to the devices and process all the requests. For both these operations: firmware update and log exposure, a CoAP blockwise transfer is recommended in order to minimize the energy consumption [15]. The block size is negotiated between the endpoints and then the transmission takes place.

COMMUNICATION REQUIREMENTS OF SOME M2M USE CASES Smart Building Low mobility Low/no mobility eHealth

few msec in Minutes emergency cases to hours for remote monitoring Random Random Few Bytes Medium

Bytes Kbytes Low

Smart Metering speed No mobility


High mobility

msec to minutes seconds hours (depending on the sevice)



– MBytes




IV. COMMUNICATION SELECTION CONCEPT Usually, mobile or portable devices have multiple connectivity capabilities spanning over new Access Networks and also allow various application installations. Applications running on an M2M endpoint (device or gateway) might be aware of the current allocated IP connection on the endpoint, but they are usually decoupled from the connectivity and mobility management components for security reasons. As application requirements might collide in terms of connectivity, e.g., some require frequent real-time data exchange, while others perform event-based data transmission. In order to minimize the human intervention in an M2M solution, the configuration information exchange in terms of transport management is required. The M2M system can either

receive provisioning information or adapt to current application’s requirements and IP connectivity parameters. In this paper, we address the challenge of selecting a proper communication channel and technology dynamically, based on the application’s communication criteria. In the case of an M2M gateway serving multiple sensors/devices, it should adapt to the heterogeneous traffic (both upstream and downstream), and engage into strategies to optimize the usage of available communication channels and energy. One option is to configure provision policies based on the application identity (i.e., originator of the request), to utilize the transport protocol that performs better with the expected traffic pattern of the application (see Figure 2). A connectivity management module is necessary for handling heterogeneous Access Networks. A Policy and Rules component is necessary to store the provisioned or learned policies and rules. And the Request/Reply handler is the main component that receives the requests from the M2M Applications and forwards them to a Destination M2M Node.

Fig. 2. Transport policy concept

Based on the application id (originator of the request), the M2M Gateway either has provisioned policies stating the protocol to be used or learn what is the most appropriate and what are the parameters to be used. For a normal HTTP transport the connection time can be learned in order to meet the pattern of the application: e.g., sending multiple chunks of data at a specific hour and for another interval only a few. For example, in case of air quality monitoring: during the night the interest on pollution monitoring is decreased and the application might be instructed to aggregate the data and send it less often than during the day. We introduce also the idea that such an M2M gateway learns about the served nodes on the downstream and upstream paths and use it to build rules that define the transmission capability of the peers in order to optimize the next message exchange. Either the originating or destination application’s parameters can be used as key of the learned rule: identity, IP or DNS address. Using the IP address would be recommended related to the served nodes. When the M2M gateway will interact with a node outside its own topology, it can learn about the IP, DNS and negotiated block size: when sending the request to a DNS name, the IP and block size is stored afterwards. When more than one rule has the same DNS and resulted block size, the M2M gateway will have to aggregate the rules based on the DNS information. This helps keeping the

knowledge database light, and avoid denial of service when the servicing node runs on a cloud infrastructure. V. IMPLEMENTATION CONCEPT The OpenMTC platform is a prototype implementation in Python of an M2M middleware, developed by Fraunhofer FOKUS and Technische Universität Berlin [16]. It has been designed to act as a horizontal convergence layer supporting multiple vertical application domains, such as transport, utilities, automotive, eHealth, etc., which may be deployed independently or as part of a common platform. OpenMTC features are aligned with ETSI M2M Rel. 2 specifications [17][18], providing an implementation of ETSI specified Service Capability Layers (SCL) at the Frontend (Gateway GSCL) and Backend (Network NSCL) M2M architecture. Currently, the oneM2M [19] specifications support is being added. OpenMTC supports a client/server based RESTful architecture with a hierarchical resource tree defined by ETSI, and communication over all interfaces is independent of the transport protocol. The OpenMTC Reachability, Addressing and Repository (RAR) capability manages a subscription and notification mechanism. Through this mechanism, applications, gateways and the OpenMTC platform are able to receive notifications from each other, enabling management and control of devices, which belong to the same service provider or using the same technology family. As illustrated in Figure 3, the OpenMTC platform includes a Generic Transport (GT) layer that enables the interaction between the frontend and backend over unmanaged access, as well as managed Access Networks by integrating with the OpenEPC framework. The GT layer includes an Adaptable M2M Transport (AM2MT) module, which provides pluggable transport protocols such as HTTP and CoAP. The OpenMTC gateway supports a Store and Forward (SAF) feature for applications. This feature enables the handling of different traffic streams based on their priority. This functionality is based on two types of static or dynamic policies: •

The Access Network provider policies include a control of which request category is handled depending on a schedule, as well as defining how long the M2M Service should wait before reusing a channel that experienced a connectivity failure.

The policies used by the M2M Service provider include control over the number of requests or data stored in the Service databases when no channels are available, as well as a list of preferred channels for each request category.

To support integration of heterogeneous sensors, the design of the platform enables the integration of various specific interworking proxies. Each proxy is responsible for one technology (e.g., FS20, ZigBee, etc.) and acts as a controller for the external devices by mapping these devices for monitoring and controlling into the M2M resource tree. Additionally, the concept of inter-working proxies can be implemented to

support extensibility to large-scale IoT systems by interworking with different standards, such as IEEE1888 [20]. In order to support the development of M2M applications and make the core assets and service capabilities available to 3rd party developers, the OpenMTC application enablement consists of a set of high-level abstraction Application Programming Interfaces (APIs) which hide internal system complexity, and allow the developer to focus on the implementation of the application logic. In addition, it supports the OMA NGSI 9 and 10 interfaces for context management on the gateway and the backend server [21]. The platform supports both XML and JSON format for data representation.

Fig. 3. OpenMTC Platform

VI. PROOF-OF- CONCEPT EVALUATION In order to evaluate the performance of the supported restful protocols, i.e., CoAP and HTTP, we executed some experiments using an M2M testbed consisting of a device gateway that supports multi-protocols. The tests were conducted using a PC with Ubuntu 12.10 OS as gateway that receives requests from devices. In this work, we evaluate the performance of CoAP and HTTP from two aspects: the response time and the consumed bandwidth. Our aim is gaining a better understanding of the expected performance of M2M applications associated with special traffic model, when using any of these protocols in publishing data to an M2M front-end server. A. Effect of request rate To study the impact of request rate on the performance of the data aggregation process, POST requests have been sent with a fixed payload size of 200 bytes. The interval time of the sequence requests was in the range of 2 sec – 1 msec. Figure 4 plots the consumed bandwidth to push the same amount of data using HTTP in comparison to CoAP, while Figure 5 plots the average response time. The results show that with high request rate CoAP performs better in term of the response time, but it attends to consume more bandwidth in contrast to using HTTP. In the case of using HTTP, the consumed bandwidth has significantlyincreased for requests with an interval time of 100 msec or less. As for such small intervals the connection of the first request will be reused by the following requests. Thus, the three-hand checking between client and server for each connection will be saved. Although the HTTP Keep-Alive extension can be used to keep the connection idle for longer time, connection resources at the server side can be used more efficiently when an idle connection timeout is set to a limited time.

The Store and Forward (SAF) functionality allowing both the Access Network providers and the M2M Service provider to gain control over the request flow with the use of policies was implemented in the Generic Transport component. Requests transmitted from the front-end to the back-end can use one of the various channels defined by the Access Network providers, depending on their emergency category according to the SAF policies. The retargeting mechanism is used to forward information from an M2M Gateway application to another M2M node. The request destination address (represented by the resource URL) is analyzed and if it is not matched to any address on the machine IP Address list, the message will be forwarded to the destination IP. This mechanism was implemented as a method to forward requests on a multi-hop route, bringing the advantages of enabling also transport protocol translation and channel selection based on different criteria, for example the cost. These channels can be assimilated to physical interfaces, as Wi-Fi or Ethernet. The ETSI M2M standardized definition of the SAF policy was extended to support also applying/modifying the transport protocols. Channels can define for example: ”HTTP over LTE” or ”CoAP over Wi-Fi”.

Fig. 4. Consumed bandwidth with incresing request rates

C. Smart Energy use case: Based on experimental observation presented in previous sub-sections, we conducted further experiments to evaluate the use of CoAP to push data flows with low rate/small payload, and HTTP for data flows with high rate/big payload. We consider here the substation automation application for monitoring, protection and control functions performed on substation and feeder equipment. The analysis of communication requirements and traffic loads for this application presented in [22] was adapted in our experiment. In this experiment we measure the response time of two data flows: sampling data from emulated sensor and control flow from an OpenMTC front-end gateway. The data flows are pushed to the OpenMTC front-end by a POST request with JSON formatted payload similar to: {"contentInstance": {"content": {"$t": spayload, "contentType": "application/JSON"}}}. Fig. 5. The response time with increased request rates

B. Effect of message size The aim of this test is to study the effect of the message size on the performance of data aggregation. A simple application was implemented to emulate a sensor feeding the gateway with one data flow. The sample rate was fixed to (1Hz). The response time was measured for POST requests of different messages sizes in the range of 100 – 1200 bytes. As illustrated from Figure 6, the average response time when using HTTP is less affected than CoAP with the increase of the payload size. Due to the message size’s limit with CoAP, that shall remain small to fit in single IP datagram, we show the results for 1200 byte, however the response time didn’t change a lot with bigger payload size using HTTP. Although CoAP has the advantage of a smaller overhead of only 4 bytes, the encoding/decoding time is slightly affected with the size of the payload.

Figure 7 shows two plot diagrams for the response time of data flows, that represent aggregated data: i) sampling data (rate 1 sample/second and payload size 1600 byte), ii) control parameters (rate: 100 request/s, payload size 200 byte). The substation automation applications are strictly delay sensitive, and from the plots, we can see the improvement on using CoAP in transporting the control interactions.

Fig. 7. Performance of emulated substation automation application

Fig. 6. The effect of message size on the performance

D. eHealth use case A second use case in our study considered a Remote Patient Monitoring (RPM) service, which collects and stores health conditions remotely. The traffic in this case consists of multiple

simultaneous data flows with different rates: 1, 10, and 100 req/s. The data flows are pushed to the OpenMTC front-end by a POST request. Figure 8 shows the response time of the data flows that represent aggregated data from: i) blood pressure sensor (rate 1 sample/second and sample size 16 bit), ii) ECG leads (rate: 1250 sample/s, sample size 12 bit), and iii) oxi meter (rate: 75 sample/sec, sample size 5 byte).

[4] [5] [6]




[10] [11]

Fig. 8. Performance of emulated ehealth service.

[12] [13]

VII. CONCLUSION AND FUTURE WORK The main goal of M2M platforms is to connect efficiently the increasing number of connected objects, and enable the exchange of gathered data between smart services. The heterogeneity of integrated communications technologies, targeted service domain and data representation, highlights the need to study the communication requirements of various services and traffic pattern. In this paper, we address the challenge of selecting a proper communication channel and technology, based on the application’s communication criteria. A novel mechanism was described and evaluated on the exchanging M2M traffic pattern from sensors/devices and gateways to an M2M server platform. In our future work, we will consider other protocols such as MQTT.

[14] [15]

[16] [17] [18] [19] [20]




G. Wu, S. Talwar, K. Johnsson, H. Nageen, and K. Johnson, “M2M : From Mobile to Embedded Internet,” IEEE Commun. Mag., vol. 49, no. 4, pp. 36–43, 2011. M. R. Palattella, N. Accettura, X. Vilajosana, T. Watteyne, L. A. Grieco, S. Member, G. Boggia, and M. Dohler, “Standardized Protocol Stack for the Internet of ( Important ) Things,” IEEE Commun. Surv. TUTORIALS, vol. 15, no. 3, pp. 1389–1406, 2013. A. Ludovici, P. Moreno, and A. Calveras, “TinyCoAP: A Novel Constrained Application Protocol (CoAP) Implementation for Embedding RESTful Web Services in Wireless Sensor Networks Based on TinyOS,” J. Sens. Actuator Networks, vol. 2, no. 2, pp. 288– 315, May 2013.



Z. Shelby, K. Hartke, and C. Bormann, “RFC 7252: The Constrained Application Protocol (CoAP).” 2014. International Business Machines Corporation (IBM), “MQTT V3.1 Protocol Specification,” 2010. C. Rodríguez-Domínguez, K. Benghazi, M. Noguera, J. L. Garrido, M. L. Rodríguez, and T. Ruiz-López, “A communication model to integrate the Request-Response and the Publish-Subscribe paradigms into ubiquitous systems,” Sensors (Basel)., vol. 12, no. 6, pp. 7648–68, Jan. 2012. W. Colitti, K. Steenhaut, N. De Caro, B. Buta, and V. Dobrota, “Evaluation of constrained application protocol for wireless sensor networks,” in 18th IEEE Workshop on18th IEEE Workshop on Local & Metropolitan Area Networks (LANMAN), 2011, 2011, pp. 1–6. E. G. Davis, A. Calveras, and I. Demirkol, “Improving packet delivery performance of publish/subscribe protocols in wireless sensor networks,” Sensors (Basel)., vol. 13, no. 1, pp. 648–80, Jan. 2013. U. Hunkeler, H. L. Truong, and A. Stanford-Clark, “MQTT-S — A publish/subscribe protocol for Wireless Sensor Networks,” in 2008 3rd International Conference on Communication Systems Software and Middleware and Workshops (COMSWARE ’08), 2008, pp. 791–798. ETSI TS 102 689 V1.1.2, “Machine-to-Machine communications (M2M); M2M service requirements,” 2011. 3GPP-TS22.368, “Service requirements for Machine-Type Communications (MTC) Rel-12.” 3GPP, 2013. OneM2M TR 0001, “oneM2M Use cases collection.” 2013. N. Nikaein and S. Krco, “Latency for Real-Time Machine-to-Machine Communication in LTE-Based System Architecture,” in Wireless Conference 2011 - Sustainable Wireless Technologies (European Wireless), 11th European, 2011, vol. 7, pp. 263–268. D. Boswarthick, O. Elloumi, and O. Hersent, M2M Communications: A Systems Approach. John Wiley & Sons, 2012, p. 280. M. Z. Shafiq, L. Ji, A. X. Liu, J. Pang, and J. Wang, “A First Look at Cellular Machine-to-Machine Traffic – Large Scale Measurement and Characterization Categories and Subject Descriptors,” in 12th ACM SIGMETRICS/PERFORMANCE joint international conference on Measurement and Modeling of Computer Systems, 2012, pp. 65–76. “OpenMTC platform.” [Online]. Available: ETSI TS 102 690 v1.1.1, “Machine-to-Machine communications (M2M); Functional architecture,” 2011. ETSI TS 102 921 v1.1.1, “Machine-to-Machine communications (M2M); mIa, dIa and mId interfaces,” 2012. OneM2M-TS-0001, “OneM2M Functional Architecture,” vol. 1. 2014. T. Klinpratum, C. Saivichit, A. Elmangoush, and T. Magedanz, “Toward Interconnecting M2M / IoT Standards : Interworking Proxy for IEEE1888 Standard at ETSI M2M Platforms,” in 29th International Technical Conference on Circuit/Systems Computers and Communications (ITC-CSCC 2014), 2014, pp. 763–766. A. Elmangoush, H. Coskun, T. Magedanz, and N. Blum, “An Approach to Expose M2M Services over OMA Next Generation Service Interface,” in 17th International Conference on Intelligence in Next Generation Networks (ICIN), 2013, pp. 152–159. R. H. Khan and J. Y. Khan, “A comprehensive review of the application characteristics and traffic requirements of a smart grid communications network,” Comput. Networks, vol. 57, no. 3, pp. 825– 845, Feb. 2013.

Suggest Documents