# ACE: A Routing Algorithm Based on Autonomous Channel Scheduling for Bluetooth Mesh Network
## 5 ACE: A Routing Algorithm Based on Autonomous Channel Scheduling for Bluetooth Mesh Network
### Overview  
Our routing algorithm follows these basic rules: (1) Reusing existing mesh packets (e.g., heartbeat packets) for route creation and maintenance, (2) scheduling BLE channel for each node locally and autonomously, and (3) recovering route for moved nodes by a beacon-aware scheme adaptively.  
From a system integration perspective, we design ACE to be transparent to the applications. ACE is designed on the network layer and completely reuse Bluetooth Mesh stack layers above the network layer and the BLE specification core below it. Benefit from this, ACE enables off-the-shelf mobile phones to communicate with mesh network without knowing about the existence of ACE.  
Figure 2(a) gives a communication flows example of Bluetooth Mesh from the source node to the destination node, and Figure 2(b) is the communication flows of ACE in the same scenario for comparison.  
ACE can be divided into the following two phases:  
**Route creation Phase:** In this phase, each node in Bluetooth Mesh creates a neighbor table and a routing table. A neighbor table records ADV addresses of all nodes within the radio range and their scanning channel, respectively. A routing table record the destination element address, the next hop's ADV address and the hop count.  
**Route Maintenance Phase:** There are three actions involved in this phase:  
* **Packet Sending:** When a node has a packet to send, it will first look up the routing table and find out the ADV address of the next hop, and then look up the neighbor table using the ADV address to find out the scanning channel of the next hop, finally send the packet on this specific channel. However, suppose the routing table does not have the entry of the destination node. In that case, the node will send the packet to all its neighbors to ensure the destination element can receive the packet at all possible.
* **Packet Receiving:** When a node has a packet to receive, the first thing to do is to check whether the destination element address is one of its element address. If so, it will deliver the packet to the upper layer for further processing directly. Otherwise, if the TTL value in the packet is more than one and its relay feature is on, the node will forward the packet and then start the packet sending phase as described above. Otherwise, the packet will be discarded for the TTL value is less than one.
* **Routing Update (optional):** As for typical Bluetooth Mesh applications like lighting control, all light nodes are static, and the network topology can always keep fixed. In such a widely used scenario, we can disable the routing update function to avoid unnecessary overhead. However, there are some dynamic Bluetooth Mesh network scenarios, such as asset tracking. The node mobility issue needs to be taken into consideration to keep the route valid all the time. Therefore, we design the routing update phase (optional) to enable our algorithm to adapt to a dynamic network as well. The details of the design are described in the next section.