# A Cooperative MAC Protocol for a M2M Heterogeneous Area Network
## 3 M2M Network Architecture and Requirements  
Network design requirements for M2M and IoT applications are significantly different from H2H and M2H communications due to the nature of the services. Data and communication requirements of H2H and H2M systems are mainly dominated by higher data rate and low latency. These networks also need to support data rate asymmetry with higher data volume on the downlink for applications, such as file download and video streaming. Requirements of M2M applications are discussed in Section 2. Figure 1 shows a functional M2M communication network architecture based on the ETSI standard [5; 14]. The architecture is divided into two domains; the _device and gateway_, and the _network_. The device and gateway domain is composed of M2M devices, area networks, applications, and the M2M gateway. The network domain mainly consists of access and core networks, M2M management functions, and various M2M applications. The device and gateway domain can support two types of M2M devices where enhanced devices can have direct connectivity to application servers via the access network, whereas other devices with lower capabilities can only connect to the network domain via an M2M gateway through the area network as shown in the figure. M2M devices can also be connected to the network domain via multiple M2M gateways through different access networks. Network elements in the device and gateway domain should serve the M2M traffic directly from source nodes which are distributed over a wide area. These devices will generate short data bursts and have low energy consumption requirements. On the other hand, in the network domain, the data connections are mostly served by the gateways and enhanced M2M devices where data bursts are generally larger, with less restrictions on energy consumption. Connectivity in this domain can be supported by conventional cellular networking standards, as well as high data rate short range wireless networking standards. To support M2M communication requirements over a cellular network, new radio resource allocation techniques need to be developed so that short and infrequent data bursts can be efficiently served [15; 16].  
\begin{table}
\begin{tabular}{c c c c c} \hline \hline
**Application** & **Delay Requirements (maximum)** & **Packet Loss (\%)** & **Traffic Flow Direction** & **Traffic Type** \\ \hline Smart Grid: & & & & \\ \hline Grid protection information & 1–10 ms & 0 & UL, DL & Event triggered, timed \\ \hline Breaker closure & 16 ms & 0 & UL, DL & Event triggered, timed \\ Transformer protection/control & 16 ms & 0 & UL, DL & Event triggered, timed \\ PMU (Phase Measurement Unit)–synchronism & 20 ms & \textless{}1 & UL & Periodic \\ SCADA periodic measurements & 100 ms & \textless{}2 & UL, DL & Periodic, on demand \\ DSM (Demant Side Management) services & 200–500 ms & 0 & UL, DL & Periodic, open demand \\ Automatic meter reading–demand & 250 ms & 0 & UL, DL & Periodic, open demand \\ Fault isolation \& service restoration & 100–1000 ms & 0 & UL, DL & Event based, planned \\ Automatic meter reading–regular reads & \textgreater{}15 s & \textless{}5 & UL & Periodic \\ \hline Smart City: & & & & \\ \hline Building structure monitor & Data: 30 min; Alarm: 10 s & Variable & UL, DL & Periodic, event based \\ Waste management & Data: 30 min & Variable & UL & Periodic, on demand \\ Traffic congestion & Data: 5 min & Variable & UL, DL & Periodic, event based, on demand \\ Smart parking & Data: \textless{}1 min & 0 & UL, DL & On demand \\ Smart lighting control & Data: 1-1 mins & 0 & UL, DL & On demand \\ Health monitoring & Data: 1–5 min; Alarm: \textless{}1 min & 0 & UL, DL & Periodic, on demand \\ \hline \hline \end{tabular}
\end{table}
Table 1: Smart grid and smart city application communication requirements.