Bluetooth Low Energy Wireless Sensor Network Library in MATLAB Simulink

: The paper describes the elements of the developed MATLAB Simulink library for building the models of Bluetooth Low Energy (BLE) wireless sensor networks to simulate the communication between BLE devices in the presence of interference and channel noise. Various parameters can be conﬁgured for the devices including their 2D positions to take into account the distances between them for calculating the attenuation coefﬁcients of the transmitted signals. Two simulation examples are provided, one of which demonstrates the data exchange between one master device and one slave at high data packet transmission rate (2 kHz), while the other example shows the data exchange between one master and multiple slaves simultaneously, in which case the data packet transmission rate can be no larger than 133 Hz.


Introduction
Wireless communication technologies can play a significant role in the industrial environment for factory automation to increase productivity and efficiency of the manufacturing systems [1,2]. By adding sensors to industrial equipment, wireless sensor networks are often used for data acquisition in Industrial Internet of Things (IIoT). The main advantage of using wireless connections in factory automation is that devices and machines can be moved and connected more freely and no restricting cables are present.
Real-time wireless sensors is one of the building blocks of the recent large-scale I-MECH project [3,4], which is fully industry driven initiative trying to enable fast integration of diverse set of components (either electronic systems, software modules, sensors or actuators) for demanding mechatronic applications respecting model-based system engineering principles. In this regard, the modeling library for wireless data acquisition was developed within the aforementioned building block, which deals with robust wireless network providing reliable, synchronized and secure data delivery from sensors to the master node (or central computing unit) in an energy efficient manner. Among a number of different wireless communication technologies (Wi-Fi, ZigBee, Bluetooth, RFID, etc. [5,6]), Bluetooth Low Energy (BLE), which is optimized for low power communication [7], was selected as the most appropriate solution satisfying the majority of identified requirements. These include low latency (less than 500 us) and fast update rates (at least 1.6 kHz), which are necessary for advanced control strategies exploiting auxiliary load-side measurements.
With the release of Bluetooth v4.0, the BLE protocol was introduced in 2010. It was designed to be ultra-low power and low cost technology for short-range communications, and was targeted at monitoring and control applications that require devices to send small amounts of data from once a second to once every few days [7]. Few examples are energy management for smart homes [8], sensor-based healthcare systems [9] and indoor positioning systems [10].
Over time, different aspects of the protocol have been analyzed (e.g., throughput [11,12], energy consumption [13], delay performance for connection-oriented applications [14], neighbor discovery process [15], channel utilization and the adaptive frequency hopping scheme [16]), including BLE suitability for IIoT applications [17][18][19] and proposed solutions to meet the real-time demands set for IIoT [19,20]. For example, in [17], the reliability of BLE for industrial wireless sensor and actuator networks is evaluated by studying a point-to-point link based on the physical layers 1M and 2M of BLE under different wireless channels, while in [18] the potential of BLE for industrial automation is explored by testing the hardware in metal enclosure with different antennas and varying transmitting power. In [19], the suitability of BLE for time-critical IIoT applications is evaluated showing that by optimally modifying the BLE retransmission scheme, it is possible to ensure reliability and timeliness requirements of IIoT applications, while in [20] the real-time communication problem is solved for Bluetooth mesh networks by proposing a multi-hop real-time BLE protocol, which is developed on top of BLE to obtain bounded packet delays over mesh networks.
Although many studies have been published on the BLE protocol, only one simulation tool [21,22] for investigating the network-level performance has been reported till 2019, when the "Communications Toolbox TM Library for the Bluetooth Protocol" was first introduced with R2019a release of MATLAB [23]. While the former tool allows to simulate the lower layers (primarily, the Physical and Link Layers) of the BLE protocol and supports only one active link at a time for each simulated device, the latter provides more functionality covering all the layers of BLE stack.
In this paper, the BLE wireless sensor network library, developed in MATLAB (R2017b) Simulink for its support of model-based design, is described (the development of the library started in 2017 when the aforementioned Toolbox library was not yet available; therefore, the proposed library, which was almost completed by the mid of 2019, uses none of the elements from the released library). Different parameters defined by the BLE protocol are explained for the configurable BLE devices (either masters or slaves) with the masters supporting either one or multiple active links at a time depending on the required sampling rate of the sensors connected to the slaves. By considering that high sampling rates (at least 1.6 kHz) and low latencies (less than 500 us) can be achieved only in the connection-oriented mode, the devices in the networks can be connected only in star topologies. Shared slaves and master/slave devices are not supported. The developed tool allows to simulate the Physical and Link Layers of the networks using a fixed-step (1 us) discrete solver. The Physical Layer is responsible for transmission and reception of raw bit streams over a physical medium, while the Link Layer defines how two devices can use a radio to transmit information between one another [7]. These two layers form the controller part of the BLE protocol stack, which also contains the host residing above the controller. The host is responsible for higher level functionalities, and is not implemented by the library; therefore, is left out of the discussion.
The advantage of the developed library is that it is compatible with earlier versions of MATLAB (2017a), it provides complete blocks of the master and slave devices, which can be conveniently placed and configured in the models, and the provided function new_BLE_model (explained later) allows fast creation of the networks by taking into account the distances between the devices to calculate the attenuation coefficients of the transmitted signals.
The rest of the paper is organized as follows. Section 2 describes the configurable elements of the library including a function for creating the initial BLE models. Section 3 provides two examples of the networks demonstrating the operation of the master device in one slave and multiple slaves modes, while the conclusions are given in Section 4.

Library Description
The BLE wireless sensor network library (Figure 1) allows to build the models for simulating the communication between multiple BLE devices. The library includes configurable blocks of BLE master and slave devices, a sensor, an 802.11b interferer, a transmission channel and a diagnostics block. For creating the initial BLE models, a special MATLAB function (explained in Section 2.8) can be used, which allows specifying the locations of the devices to determine the distances between them and the corresponding path attenuations of the transmitted signals. The key elements of the library are the BLE master and slave devices, the common internal block diagram of which is shown in Figure 2. The operation of the devices is controlled by a Stateflow chart (controller), which enables or disables the transmitter (Tx) and receiver (Rx) blocks (only one block can be active at a time), sets the channel index in the range from 0 to 39 (indices 37, 38 and 39 are used for 3 primary advertising channels with center frequencies 2402, 2426 and 2480 MHz, respectively, while the indices from 0 to 10 and from 11 to 36 are used for 37 data channels with center frequencies 2402 + 2(ν + 1), ν = 0, 1, . . . , 10 and 2402 + 2(ν + 2), ν = 11, 12, . . . , 36, respectively [24] p. 2864), initializes a linear feedback shift register for CRC (cyclic redundancy check) generation, controls the formation of the packets, etc. The Tx block is responsible for bit stream processing (CRC generation, whitening [24] p. 2923) and formation of the radio frequency (RF) signal-the BLE system operates in the 2.4 GHz ISM band and uses 40 RF channels with center frequencies 2402 + 2κ MHz, where κ = 0, 1, . . . , 39; the modulation is Gaussian Frequency Shift Keying (GFSK) with a bandwidth-bit period product BT = 0.5 and a modulation index 0.5 ([24] p. 2833); a binary one and zero are represented by +250 kHz and −250 kHz frequency deviations, respectively, while a symbol rate is 1 Msym/s. The Rx block demodulates the received signal and performs dewhitening and CRC checking operations. At packet reception, the Access Address is checked first. If the Access Address is correct, the packet is considered received, otherwise the packet is rejected. If the CRC is correct, the packet is considered valid, otherwise the packet is rejected ( [24] p. 2923).

Controller
Tx block For detection of link loss, both the master and the slave use a connection supervision timer, which starts upon entering the Connection State and resets upon reception of a valid data channel packet. If the timer reaches a certain threshold (called a connection supervision timeout), the connection is considered lost. One threshold value equaling 6 times the connection interval is used after entering the Connection State (at this point, the connection is considered to be created), while the other threshold value is used after receiving a data channel packet from the peer device, which leads to the connection that is considered to be established ( [24] p. 2979).

Master
The master (initiator) block has one input, which is the received signal from the channel, and two outputs. The first output is the transmitted signal, which goes to the channel, while the second output is the diagnostics bus containing different internal signals of the device, which can be displayed on the scope and analyzed.
For the master device, the following parameters are configurable ( Figure 3):   Figure 6. Transmit Window. After receiving the advertising packet form the slave, master sends the CONNECT_IND packet to the slave and transitions to the Connection State. The start of the first data packet, which determines the anchor point for the first connection event, and therefore the timings of all future connection events in this connection, is no earlier than transmitWindowDelay + transmitWindowO f f set and no later than transmitWindowDelay + transmitWindowO f f set + transmitWindowSize after the end of the CONNECT_IND packet (transmitWindowDelay = 1.25 ms).
Connection Supervision Timeout-the maximum time connSupervisionTimeout between two received data packets before the connection is considered lost; connSupervisionTimeout must be a multiple of 10 ms in the range from 100 ms to 32.0 s and larger than 2connInterval(1 + connSlaveLatency) ( [24] p. 2981); therefore, given connInterval = 1.25n ms and connSlaveLatency = 0, the parameter connSupervisionTimeout = 10u ms, where u ∈ [max(10, (n/4) + 1), 3200] is the integer; Connection Slave Latency-the number connSlaveLatency of consecutive connection events that the slave is not required to listen for the master; connSlaveLatency must be an integer in the range from 0 to connSupervisionTimeout/(2connInterval) − 1 and less than 500 ( [24] p. 2981), which means that connSlaveLatency ∈ [0, min( 4u/n − 1, 499)] (in the model, this parameter is set to zero; therefore, the slave listens at every anchor point to enable higher sampling rates of the sensors and lower latencies between data acquisition (slave) and data reception (master) sides); Master SCA-the worst case master's sleep clock accuracy, which determines the uncertainty window of the slave device at a connection event ( [24] pp. 2883, 2986) (in the model, the sleep clock accuracy is assumed to be 0 ppm, which corresponds to SCA = 7); Data acquisition mode: • MD bit is used-master examines the MD (more data) bit in the Header of the received data packet from the slave: if MD = 1, the master continues the connection event by sending another packet; if MD = 0, the master closes the connection event ( Figure 7), which also happens when either the packet is not received from the slave or two consecutive packets are received with an invalid CRC match ( [24] p. 2986) (this mode supports the connection with only one slave simultaneously); to ensure immunity to noise when MD bit is used by the slave to increase the sampling rate of the sensors, two additional options can be selected: • Non-disruptive mode-master closes the connection event 150 us before the end of the connection interval (this prevents the closure of the connection event in the case when the noise changes the MD bit value from 1 to 0); • Data length is forced to be (1 ... 251 octets)-the length of the Payload in the received data packets from the slave (this ensures an agreement of RxEn (receive enable) and TxEn (transmit enable) intervals between the master and slave devices during the connection interval independent of the errors in the Length field of the Header of the received packets from the slave due to noise); • MD bit is ignored-master disregards the value of the MD bit of the Header of the received data packet from the slave (MD bit is assumed to be 0); this mode supports the connections with multiple slaves simultaneously.
As follows from the data acquisition mode, master can be set to communicate either with only one slave or with multiple slaves simultaneously-the choice depends on the required sampling frequency of the sensors connected to the slaves. If the sampling rate exceeds 133 Hz, which is the reciprocal of the minimum connInterval = 7.5 ms, then only one slave is supported due to continues exchange of the data packets (150 us apart) between the master and the slave. Otherwise, if the sampling rate is no larger than 133 Hz, then only one data packet per connection interval can be received from the slave, granting the master an idle time to communicate with other devices in the time interval between the end of the data packet from the slave and the start of the next connection event.

One Slave Mode
At the start of simulation, the master resides in the Standby State (Figure 8). At Turn ON time, the master enters the Initiating State and starts to listen on the 3 primary advertising channels for the advertising packets ( Figure 4). If the packet is received, the master sends the initiating packet CONNECT_IND to the slave and transitions to the Connection State. The CONNECT_IND packet contains all the parameters (Access Address, initialization value for the CRC calculation, transmit window size, transmit window offset, connection interval, etc.) that are necessary for establishing the connection between the master and the slave ( [24] p. 2881). In the Connection State, the master sends and receives the data packets to and from the slave. If the connection is lost and the master's connection supervision timer reaches the Connection Supervision Timeout, the master returns to the Standby State.

Multiple Slaves Mode
The state diagrams of the master device in one slave and multiple slaves modes are similar ( Figure 8). The difference is that in the latter case the master can return from the Connection State to the Initiating State to listen for new advertisements, while in the former case it is not possible. In the multiple slaves mode, after creating the connection with the first slave, the master subdivides the specified connection interval into 2500 us subintervals, the length of which is determined by the maximum value of the sum 80 + 150 + (80 + 8N) + 150 us, where 80 us is the length of the empty data packet sent from the master to the slave, 150 us is the inter frame space succeeding the master's and the slave's data packets, and (80 + 8N) is the length of the data packet sent from the slave to the master, where N = 0 . . . 255 octets is the length of the Paylaod in the slave's data packet. If connInterval = 1.25n ms is not the multiple of 2.5 ms, then the last subinterval is 2.5 + 1.25 = 3.75 ms long, while the rest subintervals are 2.5 ms long.
Each subinterval can be used either for one connection event for sending and receiving one data packet to and from the slave, in which case the master resides in the Connection State, or for listening for new advertisements in the Initiating State (one example is shown in Figure 9). The master can therefore be in connection with multiple slaves simultaneously, the maximum number of which equals the number of obtained subintervals .  T_IFS  T_IFS  T_IFS  T_IFS  T_IFS  T_IFS  T_IFS  T_IFS  T_IFS  T   T_IFS  T_IFS   T_IFS  T_IFS   T_IFS  T_IFS   T_IFS  T_IFS   T_IFS Figure 9. An example of timing diagrams of the master device in the multiple slaves mode-the connection interval is subdivided into 5 subintervals with the first, the second and the fifth subintervals used for one connection event between the master and the slaves 1, 2 and 3, respectively, while the third and the fourth subintervals are used for listening for new advertisements.

Slave
The slave (advertiser) block has two inputs and two outputs. The first input is used for connecting the sensors to the slave, while the second input is the received signal from the channel. The first output is the transmitted signal, which goes to the channel, while the second output is the diagnostics bus.
The slave device has the following configurable parameters ( Figure 10). • ADV_IND has the payload containing only the slave's address; • ADV_DIRECT_IND has the payload containing the slave's address and the target's or master's address the slave intends to communicate with (by selecting ADV_DIRECT_IND, additional three fields appear in the dialog box, which allow to select the target device from the list of available masters in the model and configure the chosen master by setting its connection interval and data acquisition mode according to the sampling settings required by the slave); Time between two consecutive ADV_IND PDUs-the time interval T_ADV_I ND ≤ 10 ms between the start of two consecutive advertising packets within an advertising event ( [24] p. 2938); the advertising event is composed of three advertising packets sent on 3 primary advertising channels starting from the channel index 37 and ending with the last channel index 39 ( Figure 11); after each advertising packet, the slave listens on the same channel for the initiating packet from the master-if the CONNECT_IND packet is received, the advertising event can be closed early;  Figure 11. Advertising event of length T_advEvent and consisting of three advertising packets (TxEn is set high) sent on 3 primary advertising channels.
advInterval (multiple of 0.625 ms in the range from 20 ms to 10485.759375 ms)-the parameter, which determines the advertising interval T_advEvent, which is the time between the start of two consecutive advertising events: T_advEvent = advInterval + advDelay, where advDelay ≤ 10 ms is a pseudo-random value generated for each advertising event ( [24] p. 2939); Sampling parameters: • MD bit is used-slave sets the MD bit in its data packets to 1 to indicate that it intends to continue the connection event; this mode enables the continuous and equally spaced in time data transmission from the slave to the master with the period T sampling less than 7.5 ms, which is the minimum connection interval ( Figure 12); to achieve this, the connInterval must be an integer l multiple of T sampling = 80 + 150 + (80 + 8N) + 150 us, where 80 us is the length of the empty data packet from the master, 150 us is the inter frame space succeeding the master's and the slave's data packets, (80 + 8N) is the length of the data packet from the slave and N = 0 . . . 255;  Table 1), according to which the MD bit will be set by the slave in the data packets sent to the master; • Non-disruptive mode (this option is available only when MD bit is used)-slave closes the connection event 150 us before the end of the connection interval (this prevents the closure of the connection event too early if either the packet is not received from the master or two consecutive packets are received with an invalid CRC match due to noise); • MD bit is not used-slave sets the MD bit in its data packets to 0 (only one packet per connection interval is sent): • Data length-the length of the Payload in the data packets; • Required connection interval-the connection interval that needs to be set by the master to obtain the required sampling frequency 1/connInterval = 1/(1.25n) = 0.8/n [kHz], where n is the integer from 6 to 3200; Battery parameters (required for estimating the state of charge of the battery of the slave): battery voltage and capacity; idle state power consumption, when the device is neither transmitting nor receiving; energy spent per bit sent; energy spent per bit received; battery charging power (if zero, the battery is disconnected from the charger). At the start of simulation, the slave resides in the Standby State ( Figure 13). At Turn ON time, the slave enters the Advertising State and starts to send either ADV_IND or ADV_DIRECT_IND packets on the 3 primary advertising channels ( Figure 11). After sending each packet, the slave listens on the same channel for the initiating packet CONNECT_IND from the master. If the packet is received, the slave transitions to the Connection State, in which it sends and receives the data packets to and from the master. If the connection is lost and the slave's connection supervision timer reaches the Connection Supervision Timeout, the slave returns to the Standby State.

Sensor
Sensors are simulated as random number generators giving the binary numbers every 1 us in the range from 0 to 2 p − 1, where p is the number of bits per sample specified in the dialog box of the sensor block.
When the sensor output is connected to the first input of the slave device, the sensor values are captured by the slave at the rising edges of its transmit enable (TxEn) signal with the periodicity of T sampling (Figure 14).

Interferer
The interferer block has two outputs. The first output, which is applied to the channel, provides the signal as specified by IEEE 802.11b standard [25], while the second output is the diagnostics bus, which contains the transmit enable signal of the device, and the channel frequency index κ, which is the integer in the range from 1 to 13 and determines the channel center frequency 2407 + 5κ Mhz.
For the interferer, the following parameters are configurable: Average rate-the average number of Poisson-distributed packets per second sent by the interferer; Mean packet length-the length of the packets sent by the interferer; Interference frequency number-the channel frequency index κ used by the interferer.

Channel
In the library, the channel block has neither inputs nor outputs-the ports appear after creating the model by calling a special function new_BLE_model (explained in Section 2.8), which takes into account the number K of all BLE devices in the model and builds the corresponding internal structure of the block with K + 1 inputs and K outputs. The inputs are used for collecting the transmitted signals of the BLE devices and one interferer, while the outputs provide the received signals, which are connected to the inputs of the BLE devices. By denoting the arrays of transmitted and received signals by x = [x M1 (t), x M2 (t), . . . , x S1 (t), x S2 (t), . . . , x I (t)] T and y = [y M1 (t), y M2 (t), . . . , y S1 (t), y S2 (t), . . .] T , respectively, the following equation holds: where the matrix contains the attenuation coefficients [26] a ij = λ/(4πd ij ) = 1/(32πd ij ) of the transmitted signals depending on the wavelength λ = 1/8 m and the distances d ij between the corresponding devices ( Figure 15), while n = [n M1 (t), n M2 (t), . . . , n S1 (t), n S2 (t), . . .] T is composed of noise signals, which are added to the channel output. When the interferer is disabled, the last column in A, which contains the attenuation coefficients of the interferer signal x I (t), is set to zero. The following parameters are configurable for the block: BLE transmit power-the transmission power level, which is equal for all BLE devices in the model (can be varied individually after the model has been created); AWGN channel noise power-the additive white Gaussian noise power, which is also equal for all BLE devices and can be varied individually after creating the model; Interferer On-enable or disable the 802.11b interference signal; Interferer transmit power-the transmission power level of the 802.11b interferer.

Diagnostics
The diagnostics block allows to observe the quality of communication between one selected slave device and one master. It also contains one scope showing different internal signals of the devices during the simulation.
The block has three inputs and four outputs. The inputs are connected to the diagnostics buses of one slave, one master and the interferer, while the first three outputs provide the Bit Error Rate (BER-the number of bit errors divided by the total number of transferred bits), the Packet Error Rate (PER-the number of invalid packets divided by the total number of valid packets) and the Packet Rejection Rate (PRR-number of rejected packets divided by the total number of transferred packets) of the packets sent from the slave to the master. The last output gives the battery status of the slave, which indicates both the state of charge (SOC) and the time left to fully charge or discharge the battery.
When the simulation starts, the built-in scope of the diagnostics block opens four displays showing: (1) channel frequencies used by the selected slave and the master, and the interferer; (2) transmit enable (TxEn), receive enable (RxEn), Access Address control (AccA OK) and CRC control (CRC OK) signals of the slave (AccA OK and CRC OK signals are composed of 1 us pulses, which are generated after verifying the correctness of the Access Address and CRC fields of the received packets, respectively); (3) TxEn, RxEn, AccA OK and CRC OK signals of the master; (4) AccA OK and CRC OK signals of the slave and the master, and the control signal (InterfON) of the interferer, which shows when the device is transmitting to see its impact on data exchange between the chosen two BLE devices (the example in Figure 17 shows that when the interferer is turned on and its channel frequency is close to the frequency of the master and the slave, the connection events disrupt due to either not receiving the packets (Access Address is incorrect) or receiving two consecutive packets with invalid CRC match).

Exporting
The library contains the block for exporting the settings of the BLE devices. After placing the block in the model and by double clicking on its icon, the parameters of the devices are stored in plain text files, which can be used for identical configuration of real-world devices.

Creating the Model
For creating the initial BLE models, a special MATLAB function new_BLE_model(modelname, xy_M, xy_S, xy_I) can be used, which allows to specify the locations of the devices (the Cartesian coordinates x and y of the master devices, slaves and the interferer are given by xy_M, xy_S and xy_I, respectively) to take into account the distances between them (the distances are used for calculating the attenuation matrix A in the channel block). In addition, the devices in the model are placed in accordance to their given locations with the scale of the model saved in the model workspace (the scale of the model is the ratio of a distance in the model to the corresponding real distance following from the given coordinates). Every time the simulation starts, the distances and the matrix A are recalculated; therefore, after the model has been created, the locations of the devices can be changed as necessary.
When placing additional BLE devices in the model after the model has been created, the channel block should be changed accordingly with its inputs connected to the outputs of the master devices, slaves and the interferer, while the outputs of the channel block should be connected to the corresponding inputs of the masters, then slaves.
In the Simulink, by opening the Diagnostic Viewer, the messages generated by the devices during the simulation can be observed. For the master device, the messages are produced when the master: (1) enters the Initiating State; (2) receives the advertising packet from the slave; (3) creates the connection with the slave; (4) sets the anchor point for the connection; (5) establishes the connection with the slave; (6) checks the CRC validity of the received packet; (7) terminates the connection with the slave. Similarly, for the slave device, the messages are produced when the slave: (1) enters the Advertising State; (2) starts or closes the advertising event; (3) creates the connection with the master; (4) establishes or fails to establish the anchor point for the connection; (5) establishes the connection with the master; (6) checks the CRC validity of the received packet; (7) terminates the connection with the master. For correctly displaying the messages in the Diagnostic Viewer, the names to the BLE devices should be given as 'BLE masterX' or 'BLE slaveY', where X and Y are integer numbers.

Simulation Examples
Example 1. By calling the function new_BLE_model(M2S1, [0,0; 0,10], [10,0], [−10,0]), the model in Figure 16 is created. The model contains two master devices and one slave, which means that both the masters will respond to the advertising packet ADV_IND sent by the slave causing the interference between the packets; therefore, depending on the signal strength, the connection may be established with only either master1 or master2. The addresses of the BLE devices are random and shown on their icons, while their configurations conform to the dialog boxes in Figure 3 and Figure 10, respectively. The interferer's parameters (Average rate, Mean packet length, Interference frequency number) are set to 70 packets per second, 8384 bits per packet and 11, respectively, while the channel's parameters (BLE transmit power, AWGN channel noise power, Interferer On, Interferer frequency number) are 0 dBm, −80 dBm, enabled and 0 dBm, respectively. After running the simulation for 50 ms, the signals displayed by the scope of the diagnostics block are shown in Figure 17, while the messages appearing in the Diagnostic Viewer are as follows: M1: initiating state entered at 0.000 ms M2: initiating state entered at 0.000 ms S1: advertising state entered at 0.001 ms S1: advertising event started at 0.001 ms M1: advertising packet received from S1 at 0.130 ms M2: advertising packet received from S1 at 0.130 ms M1: connection created with S1 at 0.632 ms S1: connection created with M1 at 0.632 ms M2: connection created with S1 at 0.632 ms M1: anchor point set for S1 at 3.171 ms M2: anchor point set for S1 at 3.191 ms S1: anchor point established for M1 at 3.171 ms S1: connection established with M1 at 3.251 ms S1: CRC passed from M1 at 3.251 ms M2: CRC failed from S1 at 3.501 ms M1: connection established with S1 at 3.521 ms M1: CRC passed from S1 at 3.521 ms S1: CRC passed from M1 at 3.751 ms M1: CRC passed from S1 at 4.021 ms S1: CRC passed from M1 at 4.251 ms . . . M2: CRC failed from S1 at 11.001 ms . . . M1: CRC passed from S1 at 13.021 ms S1: CRC passed from M1 at 13.251 ms M1: CRC failed from S1 at 13.521 ms S1: CRC failed from M1 at 13.751 ms S1: CRC passed from M1 at 18.251 ms M2: CRC failed from S1 at 18.501 ms M1: CRC passed from S1 at 18.521 ms S1: CRC passed from M1 at 18.751 ms . . . M2: CRC failed from S1 at 26.001 ms . . . M2: CRC failed from S1 at 33.501 ms . . . M1: CRC passed from S1 at 40.521 ms S1: CRC passed from M1 at 40.751 ms M2: CRC failed from S1 at 41.001 ms M1: CRC failed from S1 at 41.021 ms S1: CRC passed from M1 at 41.251 ms M1: CRC failed from S1 at 41.521 ms S1: CRC failed from M1 at 41.751 ms M2: connection terminated with S1 at 45.632 ms S1: CRC passed from M1 at 48.251 ms M1: CRC passed from S1 at 48.521 ms S1: CRC passed from M1 at 48.751 ms . . . At the start of simulation, both the masters (M1 and M2) enter the Initiating State and receive the advertising packet from the slave (S1) at 0.13 ms. After T_IFS = 0.15 ms, each master starts sending the CONNECT_IND packet to S1 and enters the Connection State (creates the connection with S1) after the packet has been sent at 0.13 + T_IFS + 0.352 = 0.632 ms, where 0.352 ms is the length of the CONNECT_IND packet, and, depending on the parameters transmitWindowO f f set and transmitWindowSize indicated in the CONNECT_IND packet, calculates the anchor point (t 1 = 3.171 ms and t 2 = 3.191 ms are obtained by M1 and M2, respectively) for the new connection. At the same moment (at 0.632 ms), S1 successfully receives the initiating packet from M1 (located closer to S1) and creates the connection with it. Given the already calculated anchor points, M1 and M2 start to send their empty data channel packets of length 0.08 ms to S1 at t 1 and t 2 , respectively, while S1 receives the data packet (and checks its CRC) only from M1 at t 1 + 0.08 = 3.251 ms (after confirming the correctness of the Access Address of the packet, S1 determines the anchor point for the connection and establishes the connection with M1 after receiving the whole packet at 3.251 ms). In response to the data packet from M1, the slave sends its data packet with the MD bit set to 1 (according to the sampling parameters in Figure 10) to M1, which receives the packet and establishes the connection with S1 at t 1 + 0.08 + T_IFS + 0.12 = 3.521 ms, where 0.12 ms is the length of the data packet from S1, while M2 fails (due to S1 has not created the connection with M2) to receive the data packets from S1 at t 2 + 0.08 + T_IFS + 0.08 + k · connInterval = 3.501 + k · connInterval ms (k = 0, 1, . . .) until the connection is terminated at 0.632 + connSupervisionTimeout = 45.632 ms, where connSupervisionTimeout = 6 · connInterval, and connInterval = 7.5 ms. Exchange of the data packets between M1 and S1 continues with periodicity of 0.5 ms and stops shortly after the interferer starts to transmit at 12.962 ms and 40.834 ms, and its channel frequency is close to the frequencies used by M1 and S1 (shown in Figure 17 on the left). The data exchange between M1 and S1 restarts at the beginning of the new connection events at 18.171 ms and 48.171 ms, respectively, when the channel frequencies of M1 and S1 hop to other values more distant from the interferer's frequency.
If the coordinates of M1 are changed to (−6,0), then S1 creates and establishes the connection with M2, which is now closer to S1, however, if the PDU type in Figure 10 is changed to ADV_DIRECT_IND with M1 indicated as the target device, then S1 creates and establishes the connection with M1.    Figure 17. Internal signals of the master1 (M1), slave1 (S1) and 802.11b interferer (model M2S1) from 0 to 50 ms (on the left) and from 3 to 3.8 ms (on the right)-the left side shows interruptions in the data transmission between M1 and S1 when the interferer is turned on and its channel frequency is close to the frequencies used by M1 and S1, while the right side shows the exchange of the first data packets between M1 and S1 after the connection has been created.  Figure 18 is created. The master device (M1) is configured as in Figure 3 with the data acquisition mode selected: MD bit is ignored (supports multiple slaves); while the slaves (S1, S2, S3 and S4) have their configurations as in Figure 10 with Turn ON times: 1 us, 15 ms, 1 ms and 110 ms, respectively; sampling parameters: MD bit is not used; data lengths: N 1 = 40, N 2 = 251, N 3 = 125 and N 4 = 5 octets, respectively. In addition, the input and output RF signals of S1 are disabled at 11 ms to simulate the link loss between S1 and M1. The parameters of the channel block (BLE transmit power, AWGN channel noise power, Interferer On, Interferer frequency number) are 0 dBm, −80 dBm, disabled and 0 dBm, respectively. After running the simulation for 120 ms, the messages from the Diagnostic Viewer are as follows: M1: initiating state entered at 0.000 ms S1: advertising state entered at 0.001 ms S1: advertising event started at 0.001 ms M1: advertising packet received from S1 at 0.130 ms M1: connection created with S1 at 0.632 ms M1: anchor point set for S1 at 4.284 ms S1: connection created with M1 at 0.632 ms M1: initiating state entered at 0.782 ms S3: advertising state entered at 1.000 ms S3: advertising event started at 1.000 ms M1: advertising packet received from S3 at 1.129 ms M1: connection created with S3 at 1.631 ms M1: anchor point set for S3 at 6 At the start of simulation, M1 enters the Initiating State and receives the advertising packet from S1 at 0.130 ms. M1 responds to the packet by sending the initiating packet with the indicated connInterval = 7.5 ms to S1 and creates the connection with the slave at 0.632 ms. At this moment, the anchor point for the connection is set to t 1 = 4.284 ms, and M1 returns to the Initiating State at 0.632 + T_IFS = 0.782 ms for listening for new advertisements from other devices. At 1.129 ms, M1 receives the advertising packet from S3, which is responded by sending the initiating packet to S3 and creating the connection with the slave at 1.631 ms. The anchor point for this connection is set to t 2 = t 1 + 2.5 = 6.784 ms, where 2.5 ms is the length of the subinterval in the multiple slaves mode (in total, there are connInterval/2.5 = 3 subintervals). M1 returns to the Initiating State at 1.631 + T_IFS = 1.781 ms but receives no new advertisements up to t 1 − τ = 3.632 ms, where τ = 0.652 = T_IFS + 0.352 + T_IFS ms is the time interval reserved for responding with the initiating packet of length 0.352 ms to an advertiser and entering the Connection State. At t 1 , which is the start of the first subinterval ( Figure 19), M1 begins to send the empty data packet of length 0.08 ms to S1, which receives the packet and establishes the connection with M1 at t 1 + 0.08 = 4.364 ms, while M1 receives the data packet and establishes the connection with S1 at t 1 + 0.08 + T_IFS + 0.4 = 4.914 ms, where 0.4 = 0.08 + 8N 1 /1000 ms is the length of the data packet from S1. Similarly, at t 2 , which is the start of the second subinterval, M1 begins sending the data packet to S3, which receives the packet and establishes the connection with M1 at t 2 + 0.08 = 6.864 ms, while M1 establishes the connection with S3 after receiving the data packet from the slave at t 2 + 0.08 + T_IFS + 0.08 + 8N 3 /1000 = 8.094 ms. Whereas at t 3 = t 2 + 2.5 = 9.284 ms, which is the start of the third subinterval, M1 enters the Initiating State and listens for new advertisements until t 1 + connInterval − τ.   3 1 Figure 19. Internal signals of S1, S2, S3 and M1 (model M1S4) from 0 to 30 ms: S1, S2 and S3 create and establish the connection with M1 at 0.632 ms and 4.364 ms, 17.631 ms and 24.364 ms, 1.631 ms and 6.864 ms, respectively (starting from 11 ms, the input and output RF signals of S1 are disabled), while M1 creates and establishes the connections with S1, S2 and S3 at 0.632 ms and 4.914 ms, 17.631 ms and 26.602 ms, 1.631 ms and 8.094 ms, respectively (after creating the connections with the slaves, the channel frequencies of M1 and S1, M1 and S2, M1 and S3 conform in the subintervals 1, 3 and 2 (numbered above the lower window), respectively).
At t 1 + k · connInterval (k = 1, 2, . . .), which are the starting points of the first subintervals, M1 begins to send the data packets to S1 but receives no responses; therefore, M1 terminates the connection with S1 at 4.914 + connSupervisionTimeout = 104.914 ms, where 4.914 ms is the moment of receiving the last data packet from S1, while connSupervisionTimeout = 100 ms, as indicated in Figure 3, whereas S1 terminates the connection with M1 at 4.364 + connSupervisionTimeout = 104.364 ms. After termination, M1 uses the first subintervals for listening for new advertisements, and receives the advertising packet from S4 at 110.129 ms, which is followed by creating and establishing the connection with the slave at 110.631 ms and 117.134 ms, respectively.
At t 2 + k · connInterval, which are the starting points of the second subintervals, M1 begins to send the data packets to S3, which are received by the slave at t 2 + 0.08 + k · connInterval ms, while the responding packets from S3 are received by M1 at t 2 + 0.08 + T_IFS + 8N 3 /1000 + k · connInterval = 8.094 + k · connInterval ms.
In the third subintervals, which start at t 3 + k · connInterval, M1 resides in the Initiating State until the advertising packet from S2 is received at 17.129 ms. After creating and establishing the connection with S2 at 17.631 ms and 26.602 ms, respectively, the third subintervals are used for exchanging the data packets between M1 and S2.

Conclusions
The developed library allows to build different models of BLE wireless sensor networks for testing the communication between multiple BLE devices in the presence of interference and channel noise. The number of devices, which can be placed in a model, are theoretically unlimited, however, in practice, a restrictive factor is the processing power of a computing machine. For example, the models M2S1 and M1S4 in Section 3 required 0.5 s and 1.33 s, respectively, of computing time (Intel (R) Core (TM) i5-3470 CPU, RAM of 16 GB) to calculate 1 ms of the simulation time.
The master and slave blocks operate as specified by the BLE protocol, however, not all features are implemented: (1) in the models, the clocks of the devices are assumed to be precise; therefore, window widening ( [24] p. 2930) is not implemented, which also means that signal delays due to propagation through the channel are not taken into account; (2) the channel map in channel selection algorithm ( [24] p. 2987) is not updated during the simulation by assuming that all 37 data channels are constantly available for data transmission; (3) the acknowledgment and flow control scheme ( [24] p. 2995) is not fully implemented because of the requirement for high sampling rates (at least 1.6 kHz) of the sensors and low latencies (under 500 us) for data transmission, which means that resending of unacknowledged data packets is not possible (for the same reason, the connection slave latency in Figure 3 can not exceed 0). In addition, the Scanning State for the BLE devices is not implemented due to not suiting the purpose of simulating the data exchange at high packet transmission rates, which can reach up to 2137 packets per second as follows from Table 1.