# Virtualized MME Design for IoT Support in 5G Systems
## 7 Evaluation
### Results
#### 7.2.2 Delay  
We studied the response time experienced by a control packet at the SL's tier of the vMME for all of the schemes (see Figure 12). Additionally, we computed the CDF of the overall system response time, which is the sum of the delay experienced by a packet at each tier of the vMME (see Figure 13). To that end, we generated a signaling trace for 636,000 MBB UEs and 300 s of duration. The trace includes the three considered classes. Table 7 summarizes the results for this point. The number of UEs is selected such that the processing capacity of the OS scheme and the IM2M SL pool in the TS scheme are about to require an additional SL instance to satisfy \(\overline{D}_{SL}\). However, with this number of users, the remaining schemes do not experience the same situation. The same signaling traces were used for the four schemes considered. The response time results are filtered with a simple 90-ms moving average. The results show that response time is higher than the target mean response time at the SL tier (\(\overline{D}_{SL}\) = 1 ms) during the mM2M alarm events for the BS case (Figure 12a). That is because the SL tier is under-dimensioned to support the mM2M traffic peaks. Consequently, in such situations, the mM2M traffic might delay the other traffic types, which may be delay-sensitive, such as IM2M (see Figure 13a). On the contrary, for the OS case, the response time at the SL tier is all of the time below \(\overline{D}_{SL}\) since the system is overdimensioned (Figure 12b).  
For the SS approach, the SL tier response time always meets the condition \(\overline{T}_{SL}\leq\overline{D}_{SL}\) (Figure 12c). That is because the mM2M traffic peaks are limited by the traffic shaper. Moreover, during the IM2M traffic peaks, the system takes advantage of the multiplexing gain. In the TS case, the IM2M pool of the SL tier also meets the condition \(\overline{T}_{SL}\leq\overline{D}_{SL}\) during the IM2M traffic peak (see Figure 12f). On the contrary, the mM2M pool of the SL tier exceeds by several orders of magnitude the response time budget during and after the mM2M traffic peaks (see Figure 12e), as moderate smoothing of the peaks is applied. The MBB pool of the SL tier also meets the response time budget condition (see Figure 12d). Recall that, with the selected number of UEs, only the OS (Figure 12b) and the IM2M class in the TS scheme (Figure 12f) have a processing load close to the dimensioned capacity.  
\begin{table}
\begin{tabular}{c c c} \hline \hline  & & **Sample Scenario** \\
**Element** & **Memory Consumption** & (\(\mathbf{N}_{MBB}\) = 636, 000 MBB UEs \(\mathbf{N}_{\text{M2M}}\) = 10 \(\cdot\mathbf{N}_{MBB}\))** \\ \hline State & UE context: 264 B/UE & 264 B/UE \(\cdot(N_{MBB}+N_{M2M})=1846\) MB \\ database & & \\ \hline \multirow{4}{*}{Service logic} & Operating System ROM: 1000 MB/instance & \multirow{2}{*}{ROM: 1000 MB \(\cdot\) 7 instances = 7000 MB} \\  & Operating System RAM: 400 MB/instance [40] & RAM: ( 400 MB + 264 B/UE ) \(\cdot\) 7 instances \\ \cline{1-1}  & UE context: 264 B/UE & + 16,545 packets \(\cdot\) 200 B/packet = 2803 MB \\ \cline{1-1}  & Packet size: 200 B & \\ \hline \hline \end{tabular}
\end{table}
Table 6: Memory consumption estimation (UE context extracted from [38; 39]).  
Figure 12: SLs’ filtered processing time for each scheme (ten M2M devices per MBB UE). (**a**) Baseline scheme; (**b**) Overdimensioned scheme; (**c**) Traffic shaper scheme; (**d**) Traffic separated scheme: MBB class; (**e**) Traffic separated scheme: mM2M class; (**f**) Traffic separated scheme: IM2M class.