# From Sensor Networks to Internet of Things. Bluetooth Low Energy, a Standard for This Evolution
## 7 Improving the CSR Mesh
* Advertising Address: this 6-octet field contains the BLE address. In our proposal this is a random address generated by device. * Advertising Data: this variable size field (from 4 to 31 bytes) contains data collected from sensors or device information (battery level, for example). Advertising Data contains the following fields:
* Advertising Data Packet Length: following the BLE standard, first octet contains the PDU length. * Data header: contains two different fields. The first field is _Type_ which indicates the PDU service. For mesh packets, its value is 0x16 (service data). The second field is a 16-bit _UUID_. To ensure the compatibility with CSR devices, the UUID for his packets shall be the CSR UUID. * Destination Device ID: due to the use of random address, devices use an ID to identify them, which is shorter than a BLE address. Figure 12: Differences between Advertising and Scanning processes in BLE version 4.0 and 4.1. (a) Advertising and Scanning processes in BLE 4.0; (b) Advertising and Scanning processes in BLE 4.1. * Data Fields: are divide in two sections, an ID which indicates the data type and its length, and the data itself. * Packet ID: each packet contains its own ID, to avoid the uncontrolled packet retransmission, this field includes the source device ID and a packet counter, to ensure the uniqueness of the packet at any given time. * TTL: where TTL value which limits the lifespan of the packet is stored. * Cyclic Redundancy Check (CRC): at the end of every packet there is a 24-bit CRC, which shall be calculated over the PDU. Using our defined format, to transmit a packet to a device it is enough to know its identifier. This identifier device can be programmed in the memory of the device or be assigned dynamically by a BLE network controller. In addition, this packet format provides two possible configurations for sensor devices, since it is possible to communicate with a mesh device without being a complete mesh device:  
* _Individual Mesh_: sensor devices only transmit their data packets, but they do not retransmit the packets of other devices. This option provides us a lower traffic network. * _Collaborative Mesh_: sensor devices transmit their data packets and they retransmit the received packet for other devices. This option increases the network coverage, but also the network traffic. Furthermore, to deploy a mesh network with this option using only sensor devices is possible, without the use of CSR devices. Finally, all these modifications allow us to obtain different improvements:
* To know the source and destination device of each packet. * To increase the size of the data field in each package. * To introduce new devices working as mesh devices, either to transmit only their own data or to retransmit the received packets, without using a CSR device as a bridge. This advantage is notably accentuated when the devices we want to include in the mesh are mobile or wearable devices from users: smartphones, tablets, smartwatchs or smartbands, for example. While in the option  
Figure 13: Our proposed mesh packet format. (1) Preamble; (2) BLE Header; (3) Advertising Data Length; (4) Destination Device ID; (5) Source Device ID; (6) TTL. proposed by CSR a device must establish a master-slave connection that will be lost when the user leaves the range of coverage of the bridge device, our option allows us to transmit packets to the network in general, accentuating the concept of mesh and total coverage. * To add new devices, no matter how many bridge devices are available, since they are no required. In this way, our network provides increased scalability, sustainability, and saving cost, because we can eliminate CSR bridge devices, reducing the final number of network devices without compromising the network performance.