# From Sensor Networks to Internet of Things. Bluetooth Low Energy, a Standard for This Evolution
## 7 Improving the CSR Mesh  
As already described, one of the weaknesses of the CSR mesh network is its scalability, especially when new sensor devices are adding to it: to introduce a new non-CSR devices on network, the use of a CSR device as bridge is necessary. Because of great impact that BLE mesh network topology can have on the Industry 4.0, this network scalability must be complete, irrespective of the devices which conform the network. After the study of the behaviour of the CSR mesh, we decided to develop a new mesh proposal based on it. While to connect an external device to a bridge CSR device using a master-slave connection is necessary in the CSR mesh to take part of this network, our proposal removes this restriction. In this way, all BLE devices could broadcast packets with the specified format, which are retransmitted to their destination. Although the behaviour of the devices may seem similar, there are important differences between the protocol proposed in this section and CSR Mesh, namely:  
* Our proposal is an open protocol, in contrast to CSR Mesh. It allows us to implement our protocol in any BLE device. In addition, this characteristic will be very useful for future evaluations. * Bridge devices are not needed. In our proposal, any BLE device can take part of the mesh network, because all nodes broadcast their data packets to their neighbours. It improves the scalability and the cost savings, due to bridge devices are not needed for each new added device in the network. * Master-slave connection is not required in our proposal. It greatly improves the inclusion of mobile devices (like users smartphones). In this way, a user could move freely within mesh network, without worrying about master-slave connection interruptions. In addition to these important differences, for our mesh proposal, a new packet format was defined. This packet format is compatible with CSR devices, so that these devices can be included in our mesh as a backbone of it, since their BLE 4.1 chips allow us to obtain a better performance in this use case than if we used only BLE 4.0 chips. This better performance is due to the possibility of using observer and broadcaster modes simultaneously, without the need to switch them. A single BLE 4.0 radio only can transmit or receive data at a certain point. However, using BLE 4.1, to change the mode of operation from observer to broadcaster (or vice versa) is not necessary. It allows us to take advantage during the idle periods for doing other useful actions. Figure 12 shows these differences between BLE version 4.0 and 4.1:As said above, we created our own packet format since CSR uses its proprietary packet format for its proprietary mesh protocol, and it is not available for users. However, in our proposal, we have developed our packet format following BLE standard, and it is compatible with CSR devices, to give the choice of including them in the network. Thereby, any two devices can communicate using the mesh when both of them are inside its coverage range. In this way, devices only have to transmit an advertising package, following the defined format, in their broadcaster mode to transmit data. Figure 13 shows our proposed format, which can be used by any developer to create a new mesh network. This packet format follows the BLE specification, so that, the most of its fields can be consulted in [41]. These fields are shown below:  
* Preamble: all BLE packets have an eight bit preamble, which is used in the receiver for frequency synchronization, symbol timing estimation, and Automatic Gain Control training tasks. In advertising packets, as in this case, preamble must be 0 xAA. * Access Address: in advertising packets, access address is a 32-bit value, and for advertising packets shall be 0x8E89 BED6. * Payload Data Unit (PDU): packets have a variable size payload, from 12 to 37 bytes, which includes:
* Header: a 16-bit header, where PDU type is specified. This PDU type is _non connectable undirected advertising_, which is used in broadcast data transmissions.