## 3 Performance Evaluation
### Energy Consumption  
We first investigate the theoretical lifetime of a slave that is connected to a master in a data collection application. Note that a slave is typically a device with limited energy supply, whereas a master may not suffer the same energy constraints. We consider two different methods by which the master obtains sensor measurement readings (which are handled as attribute values) from the slave, which is assumed to act as the attribute server. We denote these methods by one-way ATT communication and round-trip ATT dialogue, respectively. In the one-way ATT communication, the slave sends a notification in response to a poll from the master. In the round-trip ATT dialogue, the master sends a request to the slave, which transmits a response to the master (and both the request and the response trigger Link Layer acknowledgments). For the two methods described, the first packet transmission from the master takes place at the beginning of each connection event. The evaluation is carried out theoretically by assuming current consumption values obtained from measurements for the CC2540 radio chip, for a transmit power of 0 dBm [11]. Specifically, for the one-way ATT communication, the study takes into account the energy consumed during each one of the following states: device wake up, radio turn on (in order to receive the initial BLE packet from the master), request reception, radio switch to transmit mode, notification transmission, and final post-processing before the device returns to sleep mode. For the round-trip ATT dialogue, the additional energy consumption due to response transmission, radio switch to receive mode, and acknowledgment reception is also considered. The energy consumption during sleep periods is considered as well for both types of ATT transactions. For the evaluation of the device lifetime, we assume an ideal battery with a capacity of 230 mAh (_i.e._, a common value for a coin cell battery). The study considers the impact of _connInterval_ and _connSlaveLatency_ parameters. The whole range of valid _connInterval_ values (_i.e._, from 7.5 ms to 4000 ms) is covered. For _connSlaveLatency_, values in the range between 0 and 7 are considered, since these values can be used for any permitted _connSupervisionTimeout_ setting. The study is also carried out for the maximum possible _connSlaveLatency_ value, which is given for the maximum _connSupervisionTimeout_ value (_i.e._, 32 s), and depends on the _connInterval_ value. For this study, a BER equal to zero is assumed, which gives an upper bound on the slave lifetime under the described conditions. The results are shown in Figure 2.  
Figure 2 illustrates the trade-off between slave lifetime and _connInterval_ and _connSlaveLatency_ parameters. The maximum slave lifetime obtained is 14.1 and 12.4 years for the one-way and round-trip methods, respectively. These values are achieved for both options for a _connInterval_ of 86.25 ms and a _connSlaveLatency_ of 370. With these settings, the master obtains one sensor measurement reading every 32 s. On the other hand, the most energy-intensive settings (_i.e._, _connInterval_ of 7.5 ms  
Figure 2: Theoretical lifetime of a slave for one-way and round-trip ATT message exchanges, and for different parameter configurations, based on CC2540 current measurements [11]. and _connSlaveLatency_ of 0) yield a slave lifetime of 2.6 and 2.0 days for each method, respectively. In this case, the time between consecutive readings is equal to 7.5 ms. Thus, BLE offers the flexibility for accommodating a wide range of measurement reading frequencies, which trade for slave lifetime. Note that for applications that can exploit the maximum _connSlaveLatency_ values (_i.e._, applications that do not require frequent measurements) slave lifetime does not exhibit a monotonical tendency with _connInterval_. This happens because the maximum _connSlaveLatency_ is defined as an integer value and cannot be greater than 499.