3.1. 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 3GPP specification.
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). 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::StartRaProcedure() method initializes the procedure. Then, several attributes and methods enabling coverage class transitions and attempts-checking are called. In particular, the UeNbIoTRandomAccess::SendMessage1() method selects the appropriate NPRACH resources for transmitting preambles in the correct coverage class. In addition, in the UeNbIoTRandomAccess::ReStartRaProcedure() 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 EnbNbIoTRandomAccess 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 EnbNbIoTRandomAccess:: SetRachReservedSubChannels() 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 EnbNbIoTRandomAccess::CheckCollisions() 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 and , 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 EnbNbIoTRandomAccess::SendMessage4() 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 and , respectively.
Algorithm 1 The implemented random access procedure. |
Require:- 1:
get c, n, s, W, , , B - 2:
randomly select one of s preambles; wait next RAO; send the preamble - 3:
if preamble collided then - 4:
; - 5:
draw random b from - 6:
wait W - 7:
if then - 8:
if then - 9:
wait b and go to 2 - 10:
else - 11:
if then - 12:
wait b and go to 2 - 13:
else - 14:
; - 15:
wait b and go to 2 - 16:
end if - 17:
end if - 18:
else - 19:
procedure FAIL - 20:
end if - 21:
else - 22:
exchange RAR - 23:
exchange Msg3 - 24:
exchange Contention Resolution Message - 25:
end if
|
3.2. Formulated Analytical Models
The collision probability and the success probability are analytically derived below, as a function of the actual number of users accessing an RAO,
N, and the number of available NPRACH subcarriers,
s. Let the
Collision Probability,
, be the probability that, in a given RAO, a preamble collision happens. First, if no users access the channel, no collisions will occur. Instead, the probability
that
k among
N users choose the same subcarrier follows a binomial distribution. Thus,
, where
p is the probability of choosing a specific subcarrier. According to NB-IoT specification, each subcarrier is selected with the same probability, hence
. If a preamble is chosen only once, that is
, the probability that only one of the
N users chooses the specific subcarrier is equal to:
Let
be the number of users not colliding. It is indeed equal to the average number of preambles chosen only once. In fact, given Equation (
1),
is computed as the product of
and the number of different preambles,
s:
As a result, the average number of collided users, that is
, corresponds to the total amount of users, i.e.,
N, except the users whose preambles not collide, i.e.,
, that is:
Thus, the Collision Probability can be expressed as follows:
Similarly, let the
Success Probability be the probability that, in a given RAO, a user successfully completes a preamble transmission. As previously stated,
is the number of users not colliding. Since
, as Equation (
2) reports,
clearly represents this success probability. Conversely, the success probability
can be intuitively modeled as:
Accordingly, it is worth noting that , as if a single user accesses an RAO, it will certainly not collide.
It is important to emphasize that no stringent assumption on the traffic model has been made in the formulated analytical model. In fact, the probability of a device attempting a preamble transmission in a given RAO depends on both its traffic arrival distribution and NPRACH structure in time. These aspects can be easily managed by the simulation platform.