# FOXS-GSC--Fast Offset Xpath Service with HexagonS Communication
## 3 Proposed Solution
### Message Routing Addressed to Cloudlet
```
Input :// neighbors list[N, NE, SE, S, SW, HW] containing vehicle ID and timestamp of the received beacon; 1 neighbors_list[] //hexagons graph sectors; 2 \(\mathit{Gll}\_sector\) //message to be (re)transmitted, see Table 2; 3 MSG //current vehicle characteristics (id, position, current_sector); 4 public  Output:the MSG updated to (re)transmitted; //make a temporary copy of hexagon graph (\(\mathit{Gll}\_sector\)) //make a temporary copy of hexagon graph (\(\mathit{Gll}\_sector\)) //make \(\mathit{cog}\)(\(\mathit{Gll}\_sector\)) //make \(\mathit{cog}\)(\(\mathit{s}\))sector from temporary hexagon graph if it is empty if\(\mathit{s}\) is empty then \(\mathit{Gll}\_remove(\mathit{s})\); foreach\(\mathit{v}\in\mathit{MSG}\_instled\_sectors\)[]do //removes all visited sectors from temporary hexagon graph 10 \(\mathit{Gll}\_remove(\mathit{v})\); //get next hop sector between current sector and destination sector using temporary sector graph 11 \(\mathit{nexthopSector\leftarrow\mathit{gll}\_exchangeDScot(\mathit{Gll}\_tmp,\_chic\_ current\_sector,\mathit{MSG}\_destination\_sector)}\); //get a vehicle inside of next sector with more recent activity 12 \(\mathit{nexthopVehicle\leftarrow\mathit{gll}\_exchangeDVehicle(\mathit{neighborslist[\mathit{nexthopSector}]})}\); //update message fields 13 \(\mathit{MSG}\_nexthop\_sector\leftarrow\mathit{nexthopSector}\); 14 \(\mathit{MSG}\_nexthop\_vehicle\leftarrow\mathit{nexthopVehicle}\); 15 \(\mathit{MSG}\_instled\_sectors\) append(\(\mathit{vehicle\_current\_sector}\)); 16 \(\mathit{MSG}\_visited\_solic\_append(\mathit{vehicle\_appal(\mathit{vehicle\_appal(\mathit{vehicle\_appal(\mathit{vehicle\_appal(\)}})}})\);
```  
**Algorithm 1**Next Sector Chooser  
To avoid the protocol choosing a sector that does not have any vehicles or creating a loop when the message is routed to the destination, sector nodes can be removed from the hexagon sector graph in certain cases. The first case is presented in Algorithm 1, line 6, where the algorithm checks which neighboring list (\(\mathit{neighbors\_list}\)) contain at least one active vehicle. Neighboring sectors that do not have any vehicles are temporarily removed from the sector graph. In the second case (Algorithm 1, line 9), all sectors contained in the \(\mathit{visited\_sectors}\) list received in the message to be retransmitted are temporarily removed from the graph (\(\mathit{Gtmp}\)). In this way, the next hop is chosen based on the shortest path between the current sector and the destination sector (see Algorithm 1, line 16). After choosing the sector, the algorithm verifies whether more than one vehicle is a relay candidate in this sector. If this is the case, the vehicle with the most recent beacon is chosen as a relay (see Algorithm 1, line 12). Finally, the message field is updated (see Algorithm 1, lines 13 to 16). During the message retransmission process, note that the ID of vehicle relays and visited sectors are stored in the lists _visited_vehicles_ and _visited_sectors_, respectively (see Algorithm 1, lines 15, 16). This process is repeated until reaching the destination. In addition to being used in the above method, these lists are used in the service response message process, which is presented in Section 3.6. In case of retransmission errors, the proposed protocol includes a recovery mode. The recovery technique is similar to the backtracking technique, in which the previous relay tries a different sector nearer by (if any exists) if a relay node does not have any neighboring sectors containing vehicles suitable for retransmission. In this technique, a timer is triggered for each message sent. If the vehicle does not listen to the retransmission within this period, the message is updated (the _recovery_tag_ (1) is added and the sector previously used for transmission is placed in the _visited_sectors_ list) and the process of choosing a new next-hop sector for retransmission is initiated (Algorithm 1). The _recovery_tag_ is used to limit the number of backtracking steps.