Machine-to-Machine (M2M) communication is a promising technology for next generation communication systems.

This communication paradigm facilitates ubiquitous communications with full mechanical automation, where a large number of intelligent devices connected by wired/wireless links, interact with each other without direct human intervention.

As a result, M2M communication finds applications in wide areas such as smart grids, e-healthcare, home area networks, intelligent transportation systems, environmental monitoring, smart cities, and industrial automation.

However, distinctive features in M2M communications form different challenges from those in human-to-human communications.

These challenges need to be addressed, or otherwise it is not easy for this paradigm to gain trust of people.

To understand M2M communications deeply, this section presents a comprehensive review of M2M communication technology in terms of its system model architecture proposed by different standards developing organizations.

This mainly includes 3GPP, ETSI, and oneM2M. Further, we have investigated distinctive features of various M2M applications and their supporting attributes, the M2M data traffic and their characterization, various M2M standardization bodies and their unique tasks, and potential M2M communication challenges and their proposed state-of-the-art solutions, followed by future research directions.

Machine-to-Machine (M2M) communication has its origin in the supervisory control and data acquisition (SCADA) systems, where sensors and other devices being connected through wired or radio frequency networks are used with computers to monitor and control industrial processes.

A key factor behind the growth of M2M communications today is the pervasive accessibility of low cost, ubiquitous connectivity. We have already become used to low cost, high-speed home and commercial Internet access.

Now-a-days, in many regions around the globe, 3G and LTE mobile networks are providing almost similar access speeds at highly competitive prices.

The use of IPconnected devices such as sensors, monitors, and actuators, in homes and in the industries, has enabled the growth of new interconnected, inter-operable services, which are capable to renovate our daily lives.

Exploiting multiple novel sources of information, the M2M technologies present a number of applications, sometimes known as “Internet of Things” (IoT)

The M2M communication system model is shown in Fig. below. It consists of three interlinked domains. These are the M2M device domain, the network domain, and the application domain.

In this domain, an M2M area network is formed by the collaboration of a large number of devices (e.g. sensors, actuators, and smart meters) and gateways (data aggregation points/concentrators).

These devices collect the sensory data from different parts in the M2M area domain, and collaboratively make “intelligent decisions” to transmit the sensory and monitored data to a gateway.

The gateway itself is an “intelligent device”, which receives the sensory data and intelligently manages the received data packets.

It forwards the data packets through efficient paths by single-hop or multi-hop channels via a network domain to the back-end server of the application domain.

When there are multiple gateways in an M2M area domain, they can further communicate with each other directly (peer-to-peer communication) to make collaborative decisions.

The network domain acts as an interface between M2M device domain and M2M application domain.

In this domain, long-range wired/wireless network protocols (e.g. telephone networks, WiMAX, and 3G/4G cellular networks) are used to provide cost efficient and reliable channels with wide coverage to convey the sensory information from M2M device domain to the application domain.

The application domain consists of a back-end server (BS) and M2M application clients.

The back-end server is the main component of the M2M system and acts as an integration point to store all the sensory information transmitted from the M2M device domain.

It also provides the real-time monitoring data to various client applications for real-time remote monitoring management (RMM), i.e. smart metering, e-health care, and traffic monitoring.

The BS can also vary for different applications; e.g. in smart grids, the control center acts as the BS, whereas in ehealthcare systems, the BS is the M2M health-monitoring server.

Considering M2M domain in Fig. below only, we can think of two communication scenarios.

The first scenario assumes the client/ server model, which considers the communication among M2M devices (deployed in M2M domain) and one or more M2M servers (within application domain).

This scenario represents the most considered one and is used in various M2M applications, such as smart electrical power grids, home automation, and environmental monitoring.

On the other hand, the peer-to-peer (p2p) model is whereby M2M devices communicate directly among themselves. These applications form the basis of the second scenario. This kind of inter-M2M device communications can be either through the mobile network or in an ad hoc mode. domain.

We explain below some of the important M2M characteristics, and their supporting features of above mentioned M2M applications

Concurrent bulk device transmission: This characteristic handles concurrent/simultaneous transmission attempts to the access network's gateways or base station from an exceedingly large number of M2M devices. This attribute may be required for a number of use cases such as healthcare, public safety, secured access and surveillance, and smart metering. Support for this attribute may require enhancements to the channel request and allocation protocols, interference mitigation mechanism, and cooperative communication.

Reliability: By the term reliability, we mean that connectivity must be assured regardless of working environment (e.g. mobility, interference, and channel quality). This characteristic is required in emergency situations where confidentiality is exceptionally important (e.g. healthcare and remote payment). Improved reliability may require changes to channel request and allocation protocols, improved interference mitigation mechanism, and device collaboration.

Priority scheduling and access: Priority access is necessary in order to schedule “events” in a variety of use cases. An improved access priority may require changes to the channel request and allocation protocols, an efficient device sleep and wake mechanism, and a superior cooperative communication. Changes to the frame structure may also be required.

Low power consumption: This characteristic is required by power constrained devices, which should wake only on demand, and after completing the task, it should go into sleep mechanism until its next turn. Support for this characteristic may require control signaling updates, an efficient sleep and wake mechanism, and device collaboration to reduce power consumption.

Bursty traffic: The data being transmitted by M2M devices in most of the cases is bursty. Support for this characteristic may require changes to SMS transmission mechanism, channel request and allocation protocol, channel coding, and frame structure. Additionally, a smaller resource unit is important to transmit a very small downlink (DL)/UL burst size.

Low or no mobility: Many M2M application scenarios involve stationary or high/low mobility devices (e.g. metering and VANETs). In such scenarios, the system must facilitate optimized mobility management so as to minimize power consumption and signaling overhead. This characteristic may require changes to handover signaling and execution.

Monitoring and security: As M2M devices are deployed in the field, it exposes them to attacks on hardware and software, and network attacks such as hacking. Further, the devices may also compromise of credentials and configuration. To prevent such things, the M2M devices must be capable of sensing unusual events such as changed device location and facilitate proper level of authentication for M2M devices and gateways. Improved monitoring and security may require an efficient mobility management mechanism, interference mitigation mechanism, and changes to cooperative communication algorithms and network entry/re-entry procedure.

Low latency: Low latency requires both the network access latency and data transmission latency to be minimized. This characteristic is required in a number of emergency scenarios (e.g. healthcare). Changes to the channel request and allocation protocols, and network entry/re-entry protocols may be required to support this feature. Additionally, it may also require changes to the frame structure, and control signaling

Controlling traffic volumes: As a huge number of M2M devices take part in M2M communications, they will generate a tremendous amount of data traffic as a result of a large number of M2M device operations. The amount of these operations will go past anything which largest network operators presently have noticed.

New signaling demands: Signaling/controlling traffic is going to be one of the primary bottlenecks as M2M devices are being deployed practically.

Inefficient use of resources: Key information such as the location of the M2M device, the time duration when the device is active, who is authorizing access and which portions of the network are congested, is often ignored by the application developers. This kind of approach results in inefficient resource consumption in both the network and the device.

Elastic applications: These applications are relatively delay tolerant. An example of such applications is downloading files of distant Machine type communication devices MTCDs from Machine type communication MTC servers. Their user utility has diminishing minor improvements with additional increase in the attainable data rate.

Hard real-time applications: These applications require their data to be served within a specified delay constraint. Otherwise, even if the data rate is further increased, there is no further utility gain. Traditional telephony is a good example of such applications. A classic M2M service application is vehicle and asset tracking, which has to observe and manage the MTCDs in real-time, which is also a hard real-time application.

Delay-adaptive applications: A unique feature of applications such as audio and video services is that they are delay sensitive. Though, a number of these applications can be made relatively tolerant of infrequent delay-bound violation and dropped packets. They have a fundamental data rate requirement, and the user utility depreciates rapidly only when the attainable data rate is below the prerequisite. There are a large number of this type of applications in M2M communications, e.g. remote monitoring in e-Health services.

Rate-adaptive applications: These applications adjust their transmission rates depending upon the available radio resources while preserving reasonable delays. Hence, the performance of these applications highly depends on the scheduling scheme and the quality of the underlying wireless channel. Evidently, the improvement in utility with increasing data rate is only minor at high data rates. On the other hand, the improvement in utility will not be significant at very low data rates due to intolerably low signal quality.

Mobile streaming: A use case of this type of application can be the signal gathered by a camera, which is to be transferred to the control center through mobile network. The customer can see and control the setting through Internet. The content of mobile streaming is typically video; the number of packets is usually several Mbps; the transmission mode is usually continuous; the priority is generally low because the video needs large bandwidth, and in congestion, it may be blocked. Mobile streaming services are error tolerant.

Smart grid: The smart grid makes utility generation (e.g. electric power, gas, and water) and delivery infrastructure capable to communicate to automate monitoring and control. In this way, when utility supply is dynamically matched with demand, it results in considerable savings in resource consumption as well. Some of the smart grid applications are distribution network automation, smart metering, demand response, equipment diagnostics, as well as wide area monitoring and control.

Regular monitoring: Some of the use cases of such an application are environmental monitoring, electricity transmission and switching monitoring in smart grid, street light control in public safety, etc. The content of such applications is packets, and the amount is generally tens or hundreds of bytes. The transmission mode is periodic, where the period may vary from tens of seconds up to several hours. The transmission priority of packets is low, and in congestion, it may be rejected.

Emergency services: Emergency services are activated in unexpected situation, and the alerting messages call to be noticed in no time. The use cases of such applications include low/high voltage alerting in smart grid, gas leakage/illegal entry alarm in smart homes, etc. The types of content transmitted in such applications are packet data or video streaming. E.g. an alert message about a vending machine running out of stock is sent through data, while an anti-theft alert message is sent by video streaming usually. In case of packet data, the packet size will be small. On the other hand, in case of video streaming, the packet size will be large. Further, the transmission mode of emergency services is bursty, and the priority of transmission is high for obvious reasons.

eHealthcare: eHealthcare aims at enhancing the quality of patient care and reducing its associated costs. The use cases of such an application include telemedicine to improve patient care by using more precise and faster reporting of variations in the patient's physical state, automatic connectivity of medical devices to the hospital network and remote management of these devices. We can consider a scenario of remote patient care and monitoring, where a patient puts on bio-sensors to observe health and fitness indicators such as body temperature, heart rate, blood pressure, and weight. The sensors may forward their collected sensory data to an M2M device (information aggregator), which further forwards this data to the M2M application server in the cloud. Based on the collected sensory data, the M2M server sends alerts and appropriate medical records to medical service providers.

Information and navigation services: The majority of vehicular M2M applications can be classified into one of the categories, namely safety and security, information and navigation, diagnostics, or entertainment. One of the use cases of a safety and security service is automatic crash notification. In this case, a variety of crash sensors on the vehicle are used to report the location and degree of damage to the vehicle, meeting crash. It also establishes a voice call to help reporting of the crash to emergency services. Furthermore, information and navigation services offer access to a variety of location sensitive information (such as Google map search) and content for the vehicle occupant.

Home energy management systems (HEMS): The HEMS are deployed on the power consumer side in a smart grid, where a control center can monitor and control the electrical home appliances (e.g. air conditioner, refrigerator, and washing machine) with smart meters to optimize the power supply and consumption. A range of services of HEMS are introduced (e.g. Apple Smart-Home Energy Management, Google Powermeter, and Microsoft Hohm) in which consumers can monitor the power consumption and perform optimization in order to reduce power costs. M2M communications play a key role in HEMS, as the information about home appliances has to be transferred to the control center for analysis and optimization. Some of the known wireless communication technologies (e.g. WiMAX and ZigBee) are possible choices owing to the low cost and flexible infrastructure.

Railways systems and public safety: Every year, hundreds/thousands of people across the globe accidentally die at unmanned level crossings due to unavailability of right information about the arrival of the train at a specific crossing at right time. To prevent this, a number of devices came into existence (especially sensors) in order to enhance public safety. The use cases of such M2M application can be automatic protection of unmanned level crossing, and tracking of trains in the railways network. In case of sensors, providing all the necessary information, the data packet length is short (r1 kB). The sensors transmit the sensory data in a periodic manner with high priority.

Energy efficiency Some machine nodes in the device domain and application domain of M2M systems are battery-powered. These nodes (such as sensors, actuators, and smart phones) need to function for a long span of time without battery recharging/replacement. Thus, it is essential for such machine nodes to be power-efficient. At application level, battery-aware applications can switch to an energy-saving mode, schedule their major energy consuming tasks, compress the data, and/or offload some computation tasks into servers in order to save energy. To reduce the power consumption and maximize the operation life time of M2M devices, the devices should go to sleep mode and only wake up when necessary .

Reliability : Wireless channels in M2M communications are notoriously unreliable due to the channel fluctuations, interference due to nearby machine nodes, noise, and large traffic in air interference. In M2M communications, one of the effective techniques to improve reliability is by exploiting redundancy technologies.

Security A number of applications visualized for M2M communications will only be feasible if security is properly addressed right from the beginning. Although, there is an urgent requirement for appropriate security mechanisms and procedures, different characteristics of M2M systems and applications may create challenges to the design of proper security mechanisms. There are several security and privacy issues in M2M communications such as physical attacks, compromise of credentials, configuration attacks, protocol attacks on the devices, attacks on the core network, user data and identity attacks, and unattended characteristics of the M2M possessing security challenges.

Ultra-scalable connectivity: To enable low cost connectivity among billions of MTC devices with diverse requirements, M2M networks should have a massive network scale

Massive access control, congestion, and overload control Further, in machine type communication (MTC), a large number of MTC devices may try to access the MTC server simultaneously, which may cause congestion in the network

Globally unique identifier to identify a node in M2M systems As a large number of intelligent devices will be involved in future M2M communications for various operations, it will be difficult to identify each device in the large scale of M2M systems. Hence, there is a requirement of an identity naming system for all network attached objects using the concept of a globally unique identifier (GUID)

IPv6 for M2M M2M can now have surplus options for connectivity with the launch of IPv6. The problem with IPv4 system was that it had limited number of device connectivity (4.3 billion) with the Internet. Although, it is a large number, but considering the fact that the world population has crossed the 7 billion mark, and they are already having a large number of things which could get connected, the 4.3 billion will eventually be used up. The IPv6 has the capability of handling 3.4 10 38 unique IP addresses, which will be used up unless every individual on the planet will be having 4.8 1028 directly connected devices. The concept of direct connectivity is going to be beneficial for M2M due to the fact that it makes connections simpler. Presently, majority of the devices do not have a publically routable IP address due to the fact that earlier, the IPv4 limited the number of publically routable IP addresses to 3.4 billion (not the number of devices). Therefore, the service provider or the local area network offered their connectivity through firewalls and routers. It often required IT involvement, which is not a good thing with respect to M2M perspective. Often, the connectivity ports, packet types of the machines would be regularly blocked by firewalls. This indicates that any non-outbound connections needed broader IT support. This process typically discouraged air interface connectivity and therefore restricted numerous possible benefits, such as having an expert distantly troubleshooting a down machine. On the other hand, the IPv6 indicates that more routable IP addresses should become available. As a result, the machines which do not require LAN access can have direct connection to the Internet. The reverse side of direct connectivity provided by IPv6 is that the machines will need to look after themselves with respect to hackers, viruses, and malwares more frequently

Device heterogeneity M2M network consists of a large number of heterogeneous devices connected with wired/wireless communication links. Additionally, M2M applications use multiple vendor equipment. The presence of multiple management protocols may result in heterogeneous devices which will use them to communicate. Hence, M2M communication requires a standard format for the management of the heterogeneity of devices

Spectrum management Due to the limited licensed spectrum, machine type communication (MTC) devices consume more energy and the network efficiency may be degraded. Therefore, a secondary spectrum is required to avoid spectrum congestion and energy consumption

Quality-of-Service (QoS) M2M communication consists of many stationary and low mobility devices to reduce the power consumption and signaling overhead. The critical data needs to be transmitted to the control center immediately without any delay but due to channel fluctuations and noise, there may be a chance of delay in data transmission. Hence the QoS may be degraded. M2M systems need a proper reliable data transmission technique without any delay and data loss to maintain the QoS

The data being delivered by M2M systems are often referred to as the oil of the twentyfirst century. It might be coincidental but the M2M data flow resembles the oil processing flow in that it is composed of data (i) upstream, (ii) mash-up, and (iii) downstream:

Upstream: Here, data are being collected from sensors in the field that deliver the data wirelessly to a gateway via single-hop or mesh networking technologies. The data traverse the Internet and reach dedicated servers or cloud platforms, where they are stored and profiled for further analytics.

Downstream: Here, business intelligence is applied to the data and intelligent decisions are taken. These are pushed back down to the customer, by either controlling some actuators, displaying some information/alerts in control/service platforms, or simply informing users about issues pertaining to this specific M2M application. Human–computer interfaces (HCI) or even computer–computer interfaces (beyond the typical APIs) will be instrumental in ensuring the offtake of M2M technologies.

Mash-up: The data processing and business intelligent platforms are likely the most important constituent of emerging M2M systems. Data flows from machines, humans, and the Internet in general will feed intelligent analytics engines, which are able to find trends, optimize processes, and thus make the industry vertical more efficient and effective.

There are a multitude of standards like Bluetooth and WiFi that address mid to high data rates for voice, PC LANs, video, etc. However, up till now there hasn't been a wireless network standard that meets the unique needs of sensors and control devices. Sensors and controls don't need high bandwidth but they do need low latency and very low energy consumption for long battery lives and for large device arrays

In contrast to Bluetooth, which has many different modes and states depending upon your latency and power requirements, ZigBee/IEEE 802.15.4 has two major states: active (transmit/receive) or sleep

The ZigBee Alliance is not pushing a technology; rather it is providing a standardized base set of solutions for sensor and control systems.

The physical layer was designed to accommodate the need for a low cost yet allowing for high levels of integration. The use of direct sequence allows the analog circuitry to be very simple and very tolerant towards inexpensive implementations.

The media access control (MAC) layer was designed to allow multiple topologies without complexity. The power management operation doesn't require multiple modes of operation. The MAC allows a reduced functionality device (RFD) that needn't have flash nor large amounts of ROM or RAM. The MAC was designed to handle large numbers of devices without requiring them to be "parked".

The network layer has been designed to allow the network to spatially grow without requiring high power transmitters. The network layer also can handle large amounts of nodes with relatively low latencies

ZigBee/IEEE802.15.4 - Typical Traffic Types Addressed

Each of these traffic types mandates different attributes from the MAC. The IEEE802.15.4 MAC is flexible enough to handle each of these types.

Periodic data can be handled using the beaconing system whereby the sensor will wake up for the beacon, check for any messages and then go back to sleep.

Intermittent data can be handled either in a beaconless system or in a disconnected fashion. In a disconnected operation the device will only attach to the network when it needs to communicate saving significant energy.

Low latency applications may choose to the guaranteed time slot (GTS) option. GTS is a method of QoS in that it allows each device a specific duration of time each Superframe to do whatever it wishes to do without contention or latency.