# Global IoT Mobility: A Path Based Forwarding Approach
## 4 Mobility over Path Forwarding Architectures
#### Macro Mobility Support  
The proposed macro mobility solution in a path-based forwarding architecture is presented using an IP-over-ICN embodiment [45]. This follows a gateway-based approach and provides the necessary path-based forwarding described in Section 4 above. The access from the MN to the network uses existing IP-based protocols, such as HTTP, CoAP, TCP, or IPv4/v6, while the NAP serves as an entry gateway point to the ICN network and  
Figure 4: Micro (intra-domain) mobility handover in a path-based forwarding architecture. maps the chosen protocol abstraction to ICN. The ICN core employs a Publish-Subscribe paradigm [45] for information dissemination that names information at the network layer, arranging individual information items into a context named scoping. Relationships between information items and scopes are represented as a directed acyclic graph of which leaves represent pieces of information and inner nodes represent scopes. Each node in the graph is identified with its full path starting from a root scope. In the context of an IP-over-ICN architecture, the ICN names are simply the IP addresses of the MNs or the fully qualified domain names (FQDNs) used by the end-systems. The IP-over-ICN solution uses Publish/Subscribe (Pub/Sub) semantics for carrying IPv4/v6 datagrams over the ICN network. As described earlier, the INF (referred to as the Rendezvous in the IP-over-ICN embodiment) looks after mapping names (IP address or FQDNs), and the PCE (referred to as the Topology Manager in the IP-over-ICN embodiment) creates the forwarding FIDs. Note that the FID encodes a delivery tree for the communication [13]. Figure 5 presents an example of macro mobility handover in IP-over-ICN, where MN A moves from Domain 1 to Domain 2 while communicating with the CN that exists in Domain 1. To support both micro and macro mobility management (referred to in this paper as global mobility management), we propose the namespace shown in Figure 6, where every MN's globally unique EUI48 identifier is represented as a scope identifier under the mobility namespace. Any IP address assigned to a MN will be represented as an identifier that is multi-homed to both the mobility root scope (M) and the EUI48 scope specific for that MN. This allows for two publication/subscription possibilities for a specific IP address. The first is without the EUI48 identifier when publishing a request for a destination IP address where the EUI48 identifier is unknown (e.g., /M/IP1), and the second is with the EUI48 identifier when subscribing to the MN's own IP address where the EUI48 identifier is known (e.g., /M/EUI48/IP1). Figure 5: Macro (inter-domain) Mobility Handover in a path-based forwarding architecture. We also propose that the Rendezvous (RV) maintains a mobility binding list whose rows represent MN EUI48 identifiers and columns represent corresponding IP addresses learnt by the Rendezvous for that MN. The last IP address in the list is the latest IP address allocated to the MN. These relations are learnt from the subscription messages sent from every MN each time it attaches to an NAP and requests communication through the ICN network. Figure 7 shows a basic 2 Node initial session establishment scenario with mobility support. In this scenario, MN A and B attach to NAP A and B respectively completing Link Layer Connectivity and IP Address Establishment. NAP A then extracts the source and destination IP addresses from the first packet sent from MN A towards MN B and publishes scope (/M/IP-B 1) on behalf of MN A to request communication with MN B and implicitly subscribes to scope (/M/EUI48-A/IP-A 1), so it can receive any information directed to MN A. On the other hand, NAP B publishes scope (/M/IP-A 1) on behalf of MN B to request communication with MN A and implicitly subscribes to scope (/M/EUI48-B/IP-B 1), so it can receive any information directed to MN B.