## 5 M2M Communication Models and Paradigms  
Before reviewing M2M application protocols used to implement the communication between M2M entities, we discuss here the underlying communication models envisioned for M2M applications and the RESTful and publish-subscribe paradigms. These are the drivers for the protocols that are currently being considered for implementing the communication among M2M entities. Communication among M2M entities can be categorised in two patterns: event- and polling-based [49]. Polling-based M2M communications follow a request-response communication model. M2M Devices or Applications send requests for specific data, e.g., to actively sample  
Figure 2: High-level view of the storyboard. measurements values. Event-based communications are triggered by the occurrence of a particular event, like, for example, the change in value of a variable. M2M Devices or Applications send data to other entities spontaneously, _i.e._, not in response to a specific request. This pattern is more adequate to M2M application scenarios that require timeliness of reaction upon the occurrence of an event of interest, but can also be used in other scenarios. Event-based communication causes fewer message transmissions, as there are no explicit requests of information. This message reduction can be of extreme importance when networks and devices are constrained. For example, a service constantly polling a mobile device, like a smartphone and nearby sensors (M2M Devices), about the activity level of an individual can cause unnecessary energy (and bandwidth) consumption for all the unnecessary requests while there is no new value to be reported. A better approach in terms of resource efficiency is to use event-based communications, in which only new activity level values originate message exchange. ETSI adopts a RESTful architecture style to organise how M2M entities communicate with each other [45]. Representational State Transfer (REST) is a client-server based architectural style created by [PERSON] in 2000 [50]. REST allows contents changing over time. The main concepts in REST are the stateless interactions between clients and servers to manipulate data, and the notion that a distributed application is composed of resources, that each has a particular state, and that each is uniquely addressable. Stateless interactions precludes that every request from a client to a server must contain all of the information necessary for the server to understand the request, and the server cannot use any previously stored context [50]. Stateless communications induce properties of reliability and scalability, since every request can be treated independently. However, REST's statelessness requirement for client-server interactions can be intolerable for constrained wireless devices and networks in mobile M2M communications, either in network bandwidth or energy consumption, due to the required amount of information to be transmitted in every request and response. REST uses CRUD (Create, Read, Update, Delete) operations to manipulate the resources. These operations can manipulate any resource and, therefore, the same architecture can be used by several applications, avoiding the use of dedicated infrastructures. REST foresees the use of intermediaries, or proxies, that perform caching of information to deliver greater scalability. REST is inherently a request-response based architecture. But, for event-based communications, publish-subscribe is a more reasonable choice. Publish-subscribe is a one-to-many communication paradigm, in which entities, termed subscribers, state their interest in being notified of data/events produced by other entities, termed publishers, at message brokers. This manifestation of interest in events is termed subscription and occurs only once. Publishers transmit to message brokers, and these deliver the message to all the subscribers, whereby both communication entities do not need to be online simultaneously.