# On the Evaluation of the NB-IoT Random Access Procedure in Monitoring Infrastructures
## 3 The Proposed Analytical Model and Simulation Tool  
### Implemented Simulation Tool  
The proposed tool extends the simulator presented in [25], which is based on the well-known LTE-Sim [48]. The latter is an open-source event-driven simulator which provides a complete performance verification of LTE networks. It was written in C++, using the object-oriented paradigm in order to ensure modularity, polymorphism, flexibility, and high performance. In general, it includes four main components, each of them modeled by a dedicated class: **Simulator** creates, handles and ends events; **NetworkManager** creates and administrates devices; **FlowsManager** manages applications; and **FrameManager** schedules frames and subframes. The parameters related to the spectrum, e.g., frequency carrier, available bandwidth, etc., are handled by the **BandwidthManager** class. Furthermore, the simulator allows the creation of a specific network scenario as a static function, enabling to model a range of different environments and situations. Every scenario actually creates the aforementioned four basic components, as well as channels, spectrum, cells, devices, Evolved Node-Bs (eNBs), and applications. Then, during the execution of the simulation, the simulator displays several information in real time either on the standard output or on a structured trace file, in order to subsequently and efficiently post-process it. This simulation platform was later extended for supporting the majority of NB-IoT features. Figure 7 provides an overview of the developed modules for the NB-IoT platform. Specifically, the **BandwidthManager** class has been drastically changed for handling different subcarrier spacings and _Single-Tone_ and _Multi-Tone_ transmissions (the latter can be configured for using 3, 6 or 12 tones). Moreover, by modifying the set of frequencies to use, the class natively supports Stand-Alone, In-Band, and Guard-Band operating modes. Multiple carriers can also be enabled by simply defining more channels of 180 kHz each to be used for data transmission. In addition, the **FrameManager** class has been properly updated for controlling the correct length of RUs duration, based on the actual number of tones and the subcarrier spacing chosen for the simulation. Furthermore, a completely redesigned uplink scheduler is realized by means of the **nbUplinkPacketScheduler** class. It provides crucial methods for the management of the RUs. Baseline uplink scheduling strategies, i.e., FIFO and Round-Robin, have been developed as well. A simplified Adaptive Modulation and Coding module (i.e., **nbAMCmodule** class) is used to choose the Transport Block Size (TBS), starting from the selected Modulation and Coding Scheme (MCS) index and number of RUs given by the scheduling strategy, according to 3 GPP specification. \begin{table}
\begin{tabular}{c c} \hline \hline
**Symbol** & **Parameter** \\ \hline \(c\) & Coverage class \\ \(n\) & Number of coverage classes \\ \(s\) & Number of NPRACH subcarriers \\ \(W\) & RAR Window \\ \(\alpha\) & Maximum transmission attempts \\ \(a_{c}\) & Number of transmission attempts in class \(c\) \\ \(b\) & Chosen backoff time \\ \(B\) & Maximum backoff time \\ \(N\) & Number of users accessing an RAO \\ \(M\) & Number of users in the cell \\ \(\mathcal{P}_{N,s}\) & Collision Probability \\ \(\overline{\mathcal{P}}_{N,s}\) & Simulated Collision Probability \\ \(\mathcal{S}_{N,s}\) & Success Probability \\ \hline \hline \end{tabular}
\end{table} 
Table 2: Description of adopted symbols. Nevertheless, the preliminary version of the NB-IoT simulator did not support the standard-compliant random access procedure. At the code level, the **EnbNbIoTRandomAccess** and **UeNbIoTRandomAccess** classes handle the random access procedure from the base station and user point of view, respectively. Consequently, these classes have been deeply revised since they were not capable of addressing the multi-class attempts control and transitions between coverage classes (as discussed in Section 2.2).