# On the Evaluation of the NB-IoT Random Access Procedure in Monitoring Infrastructures
## 3 The Proposed Analytical Model and Simulation Tool
### Implemented Simulation Tool
In particular, Figure 8 depicts an overview of the implemented code. With respect to the **UeNbIoTRandomAccess** class, as soon as the traffic generator creates a packet at the application layer, the **UeNbIoTRandomAccess:StartRaProcedure0** method initializes the procedure. Then, several attributes and methods enabling coverage class transitions and attempts-checking are called. In particular, the **UeNbIoTRandomAccess:SendMessage10** method selects the appropriate NPRACH resources for transmitting preamb  
Figure 8: Block diagram of the implemented random access procedure. Figure 7: Overview of the main building blocks of the NB-IoT simulation platform. In addition, in the **UeNbIoTRandomAccess::ReStartRaProcedure0** method there is an attribute that stores the number of failed attempts for the current coverage class, in order to manage the transitions between coverage classes. On the other hand, the **EnNbIoTRandomAccess** class handles the remaining random access procedure features. First, the base station configures NPRACH resources for each coverage class \(c\), according to the chosen configuration parameters. Specifically, the base station actually allocates resources to the NPRACH by periodically calling the **EnNbIoTRandomAccess::SetRachReservedSubChannels0** method. This means that NPRACH resources must not be used by users for NPUSCH transmission, and, at the same time, they are the only ones where users can send preambles. It is worth mentioning that other configuration parameters, e.g., \(B\) and \(W\), are handled by the base station as well. The **EnNbIoTRandomAccess::CheckCollisions0** method is of paramount importance. Indeed, for each given RAO of all the coverage class, it checks whether any collisions happened (i.e., two or more users selected the same preamble) and it schedules new preamble transmission after a random backoff time \(b\). Then, as explained in Algorithm 1, both attempt counters are incremented and subsequently checked with the chosen values of \(a_{c}\) and \(\alpha\), in order to determine a coverage class transition or the procedure failure. Specifically, if the user has any overall attempt left but no more attempts for its class, it switches to the higher class and the number of its attempts for its class is set to zero. If no higher class is available, i.e., the user is already in the _Extreme_ class, the user goes on until it has overall attempts left. Next, a new preamble transmission is solicited. If the counter of the overall attempts hits its maximum, the procedure fails and both attempt counters are set to zero. On the contrary, the exchange of the next messages is conducted until the end of the procedure for the users not experiencing a collision. Specifically, the **EnNbIoTRandomAccess::SendMessage40** method finalizes the whole random access procedure and makes the end user active and able to transmit data. Each simulation run provides three main output variables: the number of users accessing an RAO, \(N\), as well as the collision and success probabilities, denoted by \(\overline{\mathcal{P}_{N,s}}\) and \(\overline{\mathcal{S}_{N,s}}\), respectively. ```
1:\(i,j=1\)
2:get \(c\), \(m\), \(s\), \(W\), \(\alpha\), \(a_{c}\), \(B\)
3:randomly select one of \(s\) preambles; wait next RAO; send the preamble
4:if preamble collided then
5:\(i=i+1\); \(j=j+1\)
6:draw random \(b\) from \([0,B]\)
7:wait \(W\)
8:if\(j\leq\alpha\)then
9:if\(c=n\)then
10:wait \(b\) and go to?? 11:else
12:wait \(b\) and go to?? 13:else
14:\(i=1\); \(c=c+1\)
15:wait \(b\) and go to?? 16:endif
17:endif
18:else
19:procedure FAIL
20:endif
21:else
22:exchange RAR
23:exchange Msg3
24:exchange Contention Resolution Message
25:endif
```  
**Algorithm 1** The implemented random access procedure.