## 3 Enhanced Name Resolution System  
### System Model  
Figure 1 shows the system model of the Enhanced Name Resolution System (ENRS). The ENRS is a flat-name based local NRS, which provides a deterministic low latency name resolution service. ENRS adopts the 2-step resolution mechanism. In our system, we employ 128-bit Entity ID (EID) as the identifier and use IP (IPv4 or IPv6) addresses as NAs. Each entity has an EID; the generation and distribution of EIDs can be completed offline. Flat names provide some advantages compared to hierarchical ones, such as higher flexibility, simpler name allocation, and benefits in terms of persistency and privacy. Using IP addresses can improve the forward compatibility of ENRS with current equipment. ENRS is realized by partitioning the network into nested Hierarchical Elastic Areas (HEAs) with a dedicated resolver, named the HEA Manager (HM), assigned to each HEA. We envision at least one HM per HEA; the hierarchical model of ENRS can improve the scalability of ENRS and the nested structure is beneficial to the system management. Each HM has a unique ID, stores the mappingsof EIDs and NAs in their local DataBase (DB), and provides the basic functions of name binding registration, querying, and updates for the nodes in the same HEA. The HM in each HEA is deployed at a location that satisfies the bounded and deterministic latency between the user node to the HM. The HEAs in the same hierarchy are non-overlapping and have the same latency bounds; different hierarchies have different latency bounds. The higher the level of HEA, the greater the latency bounds. The equipment that evolves in the same HEA is User Equipment (UE), routers, and other intermediate equipment. For each HM, it also stores a Dynamic Neighbor HM Table (DNHT). DNHT is made up of the information of its peer HMs, including the IDs of peer HMs and distances (i.e., latency) between itself and its peer HMs. Mobility is an important issue worth considering. The position of the resolver serving a HEA will not change once the HEA has been partitioned at the first stage; the nodes involved in a HEA will be updated if nodes move into or leave the HEA, and the bindings of EIDs and NAs stored in the HEA will be updated also. The 5G system adopts the Control-Plane and User-Plane Separation (CUPS) architecture. In our ENRS, UE first sends an EID resolution request to the local hierarchical HM based on response time requirements to get the NA(s) of EID through Control-Plane functions, such as extensional Access and Management Function (AMF++) and extensional Session and Mobility Function (SMF++) [46] When the NA(s) re returned, then UE will send a data request to the NA(s) and perform the cache strategies through User Plane Function (UPF). To achieve scalable name resolution and fast name retrieval, each HM uses a Bloom Filter (BF) as name information aggregation for EIDs. The BF is implemented based on a bitmap, which is a fixed length array. The diagram of BF's working principles is shown in Figure 2. The working steps are as follows. First, initialize the array and set all of the parts of the array as zero. When a new element (i.e., EID) is added to the BF, the element is first mapped through K hash functions sequentially. Each mapping will generate a hash value. This value corresponds to a point in the bit array, and then the point is marked as 1. When querying whether an element (i.e., EID) exists in the BF, the same mapping method using the same hash functions is employed. If one of the points selected is not 1, it can be judged that the element must not exist in the set. Conversely, if the values of all K points are 1, the element may exist in the set. All the BFs at the different levels of HEAs form a BF-based tree structure. BFs stored in different HMs can be exchanged periodically. The trade-off between the false positive rate and BF size should be thought over. Figure 1: The system model of the Enhanced Name Resolution System (ENRS).