## 4 Enabling Multi-RAT Indoor Handover
### Proposed Handover Scheme  
The proposed handover scheme, LHO that is illustrated and described in Figure 5, is in general based on the knowledge of estimated robot locations and the potential LoS zone w.r.t. the mmWave AP location. In particular, the LHO is initiated whenever the robot enters/exits the mmWave NLoS area. To predict and execute the handover, the robot compares its current estimated location with the handover location on the LoS map of the environment that is shown in Figure 3. For instance, if the robot starts off in the LoS area, the LHO is triggered only if the estimated robot location no longer lies on the LoS map, in which case, a switch from mmWave RAT to WiFi shall occur. The performance of this scheme depends on multiple factors including the positioning accuracy, the presence of moving obstacles, and the robot speed. To improve the handover efficiency, one can take into account the robot trajectory, the channel statistics (measured signal level) and the sensor data (e.g., images/video, pseudo-range measurements). In addition, traditional RSSI hysteresis and time triggers may be used to eliminate possible ping-pong effects [10]. However, in this paper we use a \"proof of concept\" scheme, which only takes into account the current estimated location of the robot, and triggers a handover when the robot crosses the LoS-NLoS border. Assuming that we know the map of the building and the LoS border, together with the current location of the robot, the task of predicting if the robot is in the LoS area becomes in checking if it is located inside the polygon of an arbitrary shape, i.e., points in polygon (PiP). Since the observed polygon can be non-convex, the most efficient way to solve the problem is via a ray intersection method with the complexity of \(O(N)\), where \(N\) represents the number of edges in the considered polygon [50]. In order to decrease the computing power requirements, the LoS area polygon should be calculated separately (using e.g., Blender) for each mmWave AP in the deployment scenario, while the checking algorithm should be applied only for the currently used AP. The complexity and the feasibility of our scheme, therefore, depend on the complexity and the accuracy of the employed location estimation algorithm together with the complexity of the chosen PiP algorithm. As in the conventional schemes, the resultant computation intensity of the location-aware solution depends on the status (location) updates frequency. The implementation of the LHO scheme requires the storing of pre-calculated LoS maps and the realization of a mechanism to switch the packet flow from one RAT to another. In the paper, we compare the performance of the proposed handover scheme with a traditional RSSI-based approach. The RSSI-based handover is triggered when the WiFi RSSI is higher than the mmWave RSSI plus a 3 dB margin, for the duration of three consecutive measurements. Herein, the 3 dB hysteresis margin is set according to the recommendation made in [11]. It serves as the handover threshold throughout the overall handover process. Furthermore, the handover is implemented in a network-layer using \"soft handover\" approach--the data flow switching is enabled by changing the destination IP address, which triggers the routing table update and changes the physical interface (WiGig or WiFi TX) used for the transmission. In other words, the association (signaling) with appropriate AP (WiGig or WiFi) is not discontinued in order to record the appropriate statistics since it is connected to both APs at the same time. However, the implementation of the proposed algorithm could be realized using \"hard handover\" approach as well. In terms of the fairness of the comparison between the two considered handover scheme, we provide the following elaborations: in general, both the RSSI-based handover and the LHO belong to the context-aware handover scheme. Therefore, the two handover schemes are different in terms of the utilized context for handover prediction and triggering.