# Virtualized MME Design for IoT Support in 5G Systems
## 7 Evaluation
### Simulation Setup  
Our evaluation methodology includes three steps, namely:  
1. The dimensioning of each tier of the vMME model and the estimation of the associated cost using the target arrival rate as input; this estimation is done for a range of UEs and a given ratio of M2M devices per UE;
2. The generation of signaling traces for each traffic class (MBB, mM2M and IM2M); similarly, this trace generation is done assuming a specific number of UEs and a given ratio of M2M devices per UE;
3. Finally, the simulation of the vMME queuing model using the signaling trace as input.  
We use the MATLAB Simulink framework to simulate the queuing system presented in Section 6, which provides the vMME response time experienced by a control plane message. The queuing model is fed with the traces of signaling packets generated by each traffic class. In the model, the service rates of the FE tier, SL tier, SDB tier and output interface are extracted from [32].  
For the MO-CPCEO procedure, we obtained that the processing time needed at an SL instance is 145.05 \(\upmu\)s. Other main parameters of the simulation are summarized in Table 4. To avoid excessively long simulations, we assume a period of time between mM2M events equal to 60 s.  
\begin{table}
\begin{tabular}{l c} \hline \hline Simulation Parameters & \\ \hline Simulation Time & 300 s \\ MBB UEs & 636,000 \\ M2M devices per MBB UE & 10 \\ M2M packet size & 200 B [19] \\ M2M event duration & 1 s \\ FE mean response time budget & 1 ms \\ SL mean response time budget & 1 ms \\ SDB mean response time budget & 1 ms \\ Unweighted sliding-average smooth & 90 ms \\ \(w_{m\text{M2M}}\) & 0.1 \\ \(w_{l\text{IM2M}}\) & 0.0033 \\ \hline \multicolumn{3}{c}{**Traffic Models**} \\ \hline Mobile Broadband & \(\overline{\lambda}_{SR}\) & 0.0045 pkt /s [32] \\ (MBB) & \(\overline{\lambda}_{SR}\) & 0.0045 pkt/s [32] \\ \(\overline{\lambda}_{HO}\) & 0.0012 pkt/s [32] \\ \hline \multirow{2}{*}{Both M2M devices} & \(\overline{\lambda}_{active}\) & 0.0033 pkt/s \\  & \(\overline{\lambda}_{alarm}\) & 0.033 pkt/s \\ \hline \multirow{4}{*}{Massive M2M (mM2M)} & Percentage of mM2M devices & 90\% \\  & Event’s period & 60 s \\ (mM2M) & Event’s magnitude values & [10; 30; 50; 8] \% \\ \multicolumn{3}{c}{Event magnitude values’ probability mass} & [5; 60; 20; 15] \% \\ \hline \multirow{2}{*}{Low latency} & Percentage of lM2M devices & 10\% \\  & Event’s period & Unique (at 40 s of the simulation) \\ \multicolumn{3}{c}{Event’s magnitude value} & 33\% \\ \hline \hline \end{tabular}
\end{table}
Table 4: Parameters’ configuration.  
To estimate the system running cost, we consider the Amazon EC2 service, with the costs and configuration detailed in Table 5. We assume a medium-sized CPU instance _m3.xlarge_ with an average of 11.38 \(\times\) 10\({}^{9}\) float operations per second [36]. We use the price of the load balancing service provided by Amazon to estimate the cost of the FE tier. Our setup also includes the Amazon Aurora database [37], which is reported to provide 10\({}^{5}\) updates/s transactions. The overall cost includes the per instance cost, the time-based rental fee and the data traffic processed.