# Opportunistic Sensor Data Collection with Bluetooth Low Energy
## 3 Using Bluetooth Low Energy for Opportunistic Sensor Data Collection
### Bluetooth Low Energy Overview
#### 3.1.2 Link Layer  
In BLE, communication between two devices may take place following two main Link Layer interaction patterns: the two devices may act as: (i) advertiser and scanner, whereby the advertiser unidirectionally transmits data that can be received by the scanner, or as (ii) master and slave, whereby the two devices have established a connection and may exchange data bidirectionally.  
An advertiser transmits advertising packets through advertising channels within time periods called advertising events. The time between two consecutive advertising events is equal to _advInterval + advDelay_, whereby _advInterval_ has a fixed value that may be configured between 20 ms and 10.24 s (for non-connection-oriented advertising packets, _advInterval_ ranges between 100 ms and 10.24 s), and _advDelay_ is a random variable uniformly distributed between 0 and 10 ms, intended to avoid possible harmful synchronization effects with other advertisers. In one advertising event, an advertiser transmits an advertising packet through one, two or the three advertising channels.  
In order to enable bidirectional data exchange between two devices, they must establish a Link Layer connection. To this end, one of the devices has to advertise that it is connectable. The other device, called initiator, listens for such advertisements. When the initiator detects the presence of a connectable advertiser, it may send a Connection Request message to that advertiser, which has to be listening for such possible incoming messages. When a Connection Request message is received by the advertiser, a Link Layer connection has been established, and both devices may communicate using data channels. Within a connection, the former advertiser and initiator will play the slave and master roles, respectively. The Connection Request message includes the parameters that govern a connection. After the transmission of the Connect Request message, a wait time of 1.25 ms elapses, and the master may delay the transmission of its first data packet up to _TransmitWindowSize_ time.  
Within a connection, a slave is assumed to be by default in sleep mode to save energy, and turn on its radio interface periodically for incoming packets from the master. Communication between a master and a slave takes place in time intervals called connection events. At the beginning of a connection event, the master sends a packet to the slave, which must respond to the master. After that, the exchange of messages may continue if any of the devices has more data to transmit. From the end of the transmission of a packet until the start of the next one, an Inter Frame Space (IFS) of at least 150 us must be guaranteed. The packet flow is controlled by means of a stop-and-wait mechanism based on cumulative acknowledgments, with error recovery assisted by negative acknowledgments. When the two connected devices have sent all their pending data, the connection event will be closed. Connection event closure occurs also if certain errors affect the communication (the reception of two consecutive packets with errors, or an error affecting the address field of a packet) or if the next connection eventstart is imminent (i.e., more data cannot be sent and acknowledged within the remaining time before the next connection event).  
The time between the start of two consecutive connection events is given by a parameter called _connInterval_, which may adopt values from 7.5 ms to 4 s. Another relevant parameter is _connSlaveLatency_, which states a number of consecutive connection events (between 0 and 499) during which the slave may skip listening to the master to save energy. The connection health is tracked by running a timer that accounts for the time since the last packet was received. If that time exceeds the _connSupervisionTimeout_ parameter (between 100 ms to 32 s, and equal to or greater than _connInterval_), the connection is assumed to have failed.