# Virtualized MME Design for IoT Support in 5G Systems
## 3 System Model
### MTC Devices  
We assume that MTCDs are placed in fixed locations, and they send small data packets (reports) infrequently to centralized servers. Following the 3 GPP and METIS guidelines (see Section 2.1), we consider two types of MTCDs, mM2M and 1M2M devices. We assume mM2M devices run delay-tolerant M2M applications, which can tolerate seconds of delay [31], such as smart metering or agriculture applications. We also assume that IM2M devices run strict M2M applications, such as industrial applications or healthcare, which are characterized by low latency requirements among other demands. We also assume a large number of MTCDs connected to the network, which will  
\begin{table}
\begin{tabular}{l l} \hline \hline
**Notation** & **Description** \\ \hline \(\overline{T}_{j}\) & Mean response time for each tier (where \(j\in\{FE,SL,SDB\}\)) \\ \(\overline{D}_{j}\) & Target mean response time for tier \(j\) \\ \(N_{MBB}\) & Number of MBB UEs \\ \(N_{h}\) & Number of each class of M2M devices (where \(h\in\{mM2M,1M2M\}\)) \\ \(\overline{\lambda}_{SR}\) & Mean generation rate per MBB UE of _Service Request_ \\ \(\overline{\lambda}_{GRO}\) & Mean generation rate per MBB UE of _Service Release_ \\ \(\overline{\lambda}_{HO}\) & Mean generation rate per MBB UE of _Handover_ \\ \(\overline{\lambda}_{MBB}\) & Mean arrival rate of control messages generated by MBB UEs \\ \(\overline{\lambda}_{active}\) & Mean M2M device packet rate in the _active_ state \\ \(\overline{\lambda}_{alarm}\) & Mean M2M device packet rate in the _alarm_ state \\ \(a_{h}\) & Percent of M2M devices of each class that changes to the _alarm_ state in an M2M event \\ \(p_{h}\) & Percent of each class of M2M devices \\ \(p_{h}^{e}\) & Percent in a certain instant of time an M2M device is in the _alarm_ state \\ \(r\) & Ratio of M2M devices per MBB UE \\ \(\overline{\lambda}_{h}^{v}\) & Mean arrival rate of _MO-CPCEO_ per M2M class \\  & in a observation period (where \(v\in\{active,event,maxevent\}\)) \\ \(\overline{\lambda}_{h}\) & Mean arrival rate of _MO-CPCEO_ control messages generated per M2M class \\ \(w_{h}\) & Weighting factor of arrival rates for the absence or not of M2M events per M2M class \\ \(\lambda_{h}^{t}\) & Target arrival rate for dimensioning \\ \(\lambda_{h}^{intsmooth}\) & Target arrival rate with intense smoothing of peaks \\ \(\lambda_{h}^{smoothpeak}\) & Target arrival rate with moderate smoothing of peaks \\ \(\lambda_{h}^{peak}\) & Target arrival rate of peak traffic \\ \(\lambda_{FE}\) & Front end target arrival rate \\ \(\lambda_{SL}\) & Service logic target arrival rate \\ \(\lambda_{SDB}\) & State database target arrival rate \\ \(\mu_{j}\) & Service rate of tier instance \(j\) \\ \(m_{j}\) & Number of instances of tier \(j\) \\ \hline \hline \end{tabular}
\end{table}
Table 1: Primary definitions. FE, Front End; SL, Service Logic; SDB, State Database; MBB, Mobile Broadband; UE, User Equipment; mM2M, massive M2M; MO-CPCEO, Mobile-Originated Control Plane Cellular IoT Evolved packet system Optimization.  
cause traffic peaks due to M2M synchronization or alarm events. For simplicity, we assume there is no coordination among mM2M and IM2M events.  
As the M2M ratio of uplink traffic volume is higher than downlink (see [29]), we only consider uplink M2M traffic. To transmit a report, we assume that an M2M device triggers the Mobile-Originated data transport signaling procedure, defined in the Control Plane CIoT Evolved packet system Optimization (MO-CPCEO) [5]. Regarding the MO-CPCEO procedure, we assume that the following control messages do not take place (see Figure 1):  
* Messages 4 to 7 are not used, since there is a connection established between MME and SGW, and there is no important change to inform the Packet data network Gateway (PGW);
* Messages 9 to 13 are not used as, no downlink data are expected by the MTCD.  
Then, the MME has to process one control message for each MO-CPCEO procedure.