## 3 Enhanced Name Resolution System
### Partitioning-Based Registration and Resolution
#### 3.2.2 Name Registration and Name Resolution Schemes
The examples of name registration and resolution processes are shown in Figure 3b-d.  
(a) Name Registration  
Case 1: if \(0<T_{d}/2<T_{2}\), the REGISTER message will be forwarded to the HM of bottom-level HEA that the requestor belongs to, e.g., HM11. Case 2: if \(T_{i}\leq T_{d}/2<T_{i+1},2\leq i\leq L-1\), the REGISTER message will be forwarded to the HM of the i-th level HEA the requestor belongs to, e.g., HM21. Case 3: if \(T_{L}\leq T_{d}/2\leq T_{n}\), the REGISTER message will be forwarded to the HM of the top-level HEA, e.g., HM31. In ENRS, the procedure of the name update is similar to name registration. For a global NRS, it is expected to handle about 10 billion mobile devices' connecting requests through more than 100 networks a day, equivalent to 10 million resolutions and updates per second due to mobility. ENRS is a local NRS, the load of which is much smaller than the global ENRS, while the resolution and update frequencies are still worth considering. We assume that 100 ENRS sub-systems form a global NRS, thus each ENRS is expected to process about 10 million mobile devices' a day and 10 thousand update requests per second. Thus, fast update and synchronization mechanisms under mobility conditions must be designed to make EID accessible. The issue of name binding synchronization is beyond the scope of this paper. (b) Name Resolution  
The name resolution procedure is the inverse of name registration. For a given EID with \(T_{d}\), the QUERY message will be forwarded to the i-th HM according to the quantitative comparison results of \(T_{d}/2\) and \(T_{i}\). The situations can also be divided into three cases as follows:  
Case 1: if \(0<T_{d}/2<T_{2}\), the QUERY message will be forwarded to the HM of bottom level HEA that the requestor belongs to, e.g., HM11. Case 2: if \(T_{i}\leq T_{d}/2<T_{i+1},2\leq i\leq L-1\), the QUERY message will be forwarded to the i-th level HM that the requestor belongs to, e.g., HM21. Case 3: if \(T_{L}\leq T_{d}/2\leq T_{n}\), the QUERY message will be forwarded to the HM of top-level HEA that the requestor belongs to, e.g., HM31. In order to improve the hit ratio of ENRS, we define three message forwarding types between the neighboring HMs in the DNHT:  
* HEA-Unicast: A HM server unicasts to a certain peer HM. * HEA-Broadcast: A HM server broadcasts the messages to the entire DNHT. * HEA-Multicast: A HM server casts the messages to a group of HMs in the DNHT. As we described above, in Case 1 of the name resolution scheme, the QUERY request is forwarded to the bottom level HM. If the HM does not have requested EID, it will not disseminate the request to its neighbors, since for an ultra-low latency service, the timeout response is meaningless. While different from Case 1, in Case 2 and Case 3, if the QUERY request is forwarded to the middle level HM, whether to forward the name resolution message to the neighbors of HM will be decided by the Tolerable Latency-Based Peer HM Forwarding algorithm, which is subject to \(T_{d}\), \(T_{remain}\), and \(T_{send}\). We propose a Tolerable Latency-Based Peer HM Forwarding algorithm. The parameter updating and message forwarding methods are showed in Algorithm 2. The meaning of symbols used in Algorithm 2 are described in Table 2. If \(T_{remain}\) is set as \(-1\), Algorithm 2 is invalidated, while if \(T_{remain}\) is a positive integer, Algorithm 2 is available. When the QUERY message is sent by the requestor. \(T_{remain}\) will be updated each time the message is forwarded. If the load of ENRS is small, we can simply use HEA-Broadcast method to flood the query messages. If the load of ENRS is high, we can use Algorithm 2 to reduce the signalling overhead of ENRS. ```
Input: \(T_{d}\), \(T_{remain}\), \(T_{send}\), \(T_{recv}\), \(HM_{ik}\), \(\left\{HM_{ip}\right\}\), \(\left\{T_{p}\right\}\). Output: \(S_{f}\). Parameters: \(T_{cost}\), \(T_{trans}\).