BMSim is an open-source and publicly available event-driven Bluetooth mesh network simulator. Python is used as the programming language for the implementation of the simulator. We first introduce the architecture of the simulator, and then discuss its core operation and user interfaces.
Fig. 1 shows the general architecture of BMSim and its inner components. A simulation starts by receiving some high-level network specifications from the user. The Initializer module prepares the first snapshot of the node deployment in the specified simulation area according to user wishes. Then the Updater module runs to prepare the required inputs for the simulator engine. The updater module runs every update seconds to support network dynamism as well as run-time configuration changes. The BM simulation engine is a discrete event simulator, for which the events and their timings are made according to the BLE and BM standard protocols. This engine continues making and processing events until the requested simulation time
Fig. 1: BMSim architecture
The initialize module is the entry point user interface for the simulator by which the user's initial settings are received and compiled into the simulation framework. It gets the number of nodes in the network (network size, N) and the dimensions of the area the nodes should be deployed in. Also, the simulation time
There are a number of parameters related to different models used in the next components of the simulator that are received from the user by the initializer module and are directly passed to the corresponding blocks. Parameters of the mobility/channel/radio/interference models, BM stack initial configuration and node types, and the level of expected logs are other inputs of the initializer module. Note that since the simulator is expected to be easily configurable by plugging in/out various models, the exact list of input parameters will differ. For instance, for link extraction, the user can simply specify the communication range of nodes or the Packet Reception Ratio (PRR) of links between each pair of nodes to have high-level modeling of channel behavior without simulating details of channel and radio. However, to have a more precise simulation, one can use a path-loss model, for instance, for which several parameters such as transmission power of nodes, receiver sensitivity, and channel path-loss exponent need to be set. The same applies to other models such as mobility and interference models.
This module is essential for supporting dynamism as well as the possibility of having run-time adaptations and (re)configurations. The procedures in this module run every
There are two categories of outputs from the network updater module to the simulation engine. The first category of outputs is related to the network topology and link quality, namely the adjacency
The core of the BM simulator is a discrete event simulator that is composed of three blocks. The event updater block runs BM protocol specification, generates events (event id and expiry time), and adds them to the event list. The event processor block controls the simulation time and allows it to elapse only if all events at the current simulation time are processed. The event processor picks an event from the top of the list (the event with the earliest expiry time) and processes it, which may lead to the generation of more events (performed in line with the event updater block). Some of the defined and processed events are data packet generation event (made periodically every
To closely study the behavior of BM networks and for post-processing toward performance extraction, various log files may be generated during a simulation run. Since the simulator is open-source for the public, users can add logs for whatever parameters and wherever in the protocol execution they aim for. However, there are already some logs produced by the simulator to report important parameters that have the interest of researchers. Such logs have two modes, determined by the user, that control the level of details being logged. If the detailed log flag is on, a separate log file is produced per node that contains details of the behavior of the packet generator nodes and the relay nodes. In the generator nodes' log file, the source ID, packet destination ID, packet generation time, sequence number, and the type of packets (heartbeat or data main packet) are logged for each generated packet. In the relay nodes' log, the advertiser node, the source node, packet TTL and sequence number, advertising and receiving and generation time, type of packets, and the number of packets in the node's buffer are logged. This information helps users to track the packet's path across the network. If the detailed log flag is off, per-node log files are not produced. Anyways, a general log file is generated in every simulation run that contains the required information for evaluating the performance metrics (i.e., PDR, latency, burst packet loss, and energy consumption). This log file includes the following items per delivered packet source and destination node IDs, packet generation time, packet delivery time to destination, packet type, and packet sequence number. For calculating energy consumption, the time duration that each node has spent in each operation mode (transmission, reception, sleep, and switch) and the source node, is logged. Then energy consumption is calculated based on these timing logs as well as the power consumption profile of the used radio transceiver (provided by the user).
The corresponding manuscript is:
**Zohreh Hosseinkhani and Majid Nabi, "BMSim: An Event-Driven Simulator for Performance Evaluation of Bluetooth Mesh Networks", IEEE Internet of Things journal, 2023. ** (https://ieeexplore.ieee.org/document/10171234)
The authors appreciate proper citation of the article in case the simulator is used for research, education, etc.