# ACE: A Routing Algorithm Based on Autonomous Channel Scheduling for Bluetooth Mesh Network
## 4 Motivation  
To better understand our approach and show how the performance can be improved using our routing algorithm, we give an example topology and analyze the packet flows when delivering messages. Figure 2(a,b) show the case of Bluetooth Mesh and ACE, respectively. At the left of Figure 2(a,b), example topology and layout of the nodes are represented. The left source node is out of radio range from the right destination node. The relay node 1 and the relay node 2 in the middle are responsible for forwarding the message from the source node to the destination node. Green solid lines between two adjacent nodes represent the packet flows for the first hop while delivering a packet, and the red dashed lines represent the second hop accordingly. As shown in Figure 2(a), relay 1 and relay 2 can both receive the packet from the source node and then forward the packet sequentially. For the second hop, as red dashed lines depicted, each node in the network  
Figure 3: Examples of communication flows for Bluetooth Mesh and ACE. (**a**) The standard Bluetooth Mesh nodes advertise each data packet on three advertising channels. Each relay node will forward the data packets. (**b**) ACE nodes advertise the data packets only on the scanning channel of the next hop in the route. can hear the packets from both relay 1 and relay 2. In particular, the source node receives the duplicate packets twice from two relay nodes, respectively, and two relay nodes could also receive the duplicate packet from each other. It's worth noting that, during the time of receiving duplicate packets, nodes would quit the scanning state and might lose packets that should have been received at that moment, which can reduce the reliability of Bluetooth Mesh network. In contrast, ACE has no duplicate packet to process, and thus there is no possibility of losing packets due to quitting the scanning state for duplicate packets receiving. ACE doesn't need to switch the scanning channels between three ADV channels, and thus improve the reliability due to leaving the scanning state. Besides, packet collisions issue in ACE is rarer than in Bluetooth Mesh. A more detailed traffic flows are depicted in the right of Figure 3a,b for Bluetooth Mesh and ACE separately. In Figure 3a, the source node advertises packet on three advertisement channels at the beginning. Relay 1 receives the packet first because its scanning channel is 37, which is prior to the ADV channel 39 in an advertising event that relay 2 is scanning on. Next, relay 1 broadcast the packet on three ADV channels and so does relay 2 later. Finally, the destination node receives the packet on channel 38 from relay 1. As for ACE depicts in Figure 3b of the same scenario, after finishing setting up the routing table and selecting each corresponding scanning channel, relay 1, relay 2 and the destination node are scanning on the channel 10, 16 and 31, respectively. According to the routing and neighbor table, the source node forwards the packet to relay 1 by advertising the packet on channel 10. Meanwhile, relay 2 is unaware of this communication flow and continues to scan on channel 16. Similarly, relay 1 advertises the packet on channel 31, which the destination node is scanning on. There is neither duplicate packet received from unrelated nodes nor an uncertain delay introduced by overlapping the scanning and the advertisement channel during this process. The latency between the source node and the destination node with n relay are:  
Bluetooth Mesh:  
\[t=T_{send}+\sum_{i=1}^{n}\left(t_{scan,i}+t_{process,i}+t_{rand,i}+T_{send}\right) \tag{1}\]  
ACE:  
\[t=T_{send}+\sum_{i=1}^{n}\left(t_{process,i}+t_{rand,i}+T_{send}\right) \tag{2}\]  
where \(T_{send}\) is the transmission time of an advertising packet, \(t_{scan,i}\) is a scanning delay, depending on which ADV channel (37, 38, or 39) the packet is receiving on. \(t_{rand,i}\) is \(i\)th relay node's random delay between receiving a mesh packet and relaying it, and \(t_{process,i}\) is the packet processing time of \(i\)th relay node.