# An Interactive Real-Time Locating System Based on Bluetooth Low-Energy Beacon Network +
## 3 System Design
### Messages in the Beacon Network  
In our system, we use BLE non-connectable advertising packets to implement all types of messages so there would be no need for the devices to pair with each other before sending any data. The breakdown of a BLE air interface packet is shown in Figure 3. According to Bluetooth Specification v4.1 [32], the maximum size of a BLE advertising packet data unit (PDU) is 39 bytes. Excluding the 2-byte header field and the 6-byte advertiser's address field, there are up to 31 bytes to carry the advertising data. The advertising data is further divided into a sequence of advertising data (AD) structures. The iBeacon protocol uses AD Structure 1 and AD Structure 2 combined to carry its advertisement information, with the message format shown in Figure 4.  
There are four types of messages in our Bluetooth beacon network:  
* Type 1: beacon messages sent by the Mesh Beacons
* Type 2: presence messages sent by the Mobile Apps
* Type 3: presence messages forwarded by the Mesh Beacons
* Type 4: acknowledgement messages sent by the Mesh Router. First, in our implementation the beacon message (Type 1) format follows the iBeacon format, where the Proximity UUID field is filled with our own 128-bit Mesh UUID. We configure the Mesh Beacons to broadcast beacon messages every 100 ms. Next, for the design of the presence message  
Figure 2: An example of the flow of operations. sent by the Mobile App (Type 2), we are forced to follow the iBeacon message format again because we implement our Mobile App on the iOS platform. Since we are not allowed to customize the message format, our solution is to embed the presence state in the Proximity UUID field. Specifically, we reformat the 16-byte Proximity UUID field into 5 fields shown in Figure 5. The Mesh UUID value is set to 0x/ECE, which is the 16-bit prefix of our 128-bit Mesh UUID. The Service ID is designed to indicate the message type. For the presence message from the Mobile App (Type 2), the Service ID is assigned the value of 0 xD122. The User ID field carries the encrypted user ID, which is determined at the time the user registered. The Location field carries the discovered Major/Minor values from the received beacon message. Note that in Type 2 messages, the values in the original Major/Minor fields of the iBeacon message are unused since Mesh Beacons need not to do locating on receiving Type 2 messages. As for the presence messages forwarded by the Mesh Beacons (Type 3) and the acknowledgement messages sent by the Mesh Router (Type 4), we are able to customize their formats using the BLE advertising packet. Basically, they share the same format as shown in Figure 3 with three AD structures. Figure 4: Apple iBeacon message format. Figure 5: User’s presence state from the Mobile App is embedded in the Proximity universally unique identifier (UUID) field of a standard iBeacon message. Figure 3: The breakdown of a Bluetooth low energy (BLE) air interface packet. To simplify the presentation, in Figure 6 we only show AD Structure 2 and 3 in our design. In AD Structure 2, the AD Type of 0x03 means that there is a 16-bit Service Class UUID in the AD Data field. We use this field to denote the Mesh UUID, so the value in this field is also 0x7 ECE. In AD Structure 3, we see the Service ID field again. To distinguish the two types of messages from the presence message sent by the Mobile App (Type 2), the presence message forwarded by the Mesh Beacon (Type 3) is assigned the value of 0 xD123, and the acknowledgement message sent by the Mesh Router (Type 4) is assigned 0 xD124, respectively. Finally, the User ID and the Location fields serve the same functionalities as in Figure 5, which have been described in the previous paragraph. As we stated earlier, the Mesh Beacons are configured to broadcast beacon messages (i.e., Type 1 messages) periodically. When the Mobile App discovers a beacon message, it first checks whether the carried Mesh UUID matches our own specific value.