## 4 Use Case Scenario  
As a typical IoT scenario, the video stream monitoring service in Smart Home is used to show how the proposed naming and name resolution mechanisms work in ENRS together with other infrastructures to guarantee the continuity of service.  
The live streaming data are stored by IoT Gateway (GW) with data of a dynamically refreshed file as the named object. We use a push-based real-time video streaming service provided by a camera  
Figure 4: The diagram of name record replica diffusion in the tree topology of ENRS.  
using a publisher-subscriber model because a push-based model is more suitable for IoT scenarios [52]. In Figure 5, The Global Naming and Name Certification System (GNNCS) is responsible for EID assignment and authorization. The illustration of the use case scenario is shown in Figure 5. The workflow is as follows.  
Step 1: The IoT-GW (Producer) initiates a registration request to the GNNCS to obtain the EID of the real-time video streaming service with the Human Readable Name (HRN). Then, the GNNCS allocates a unique EID for it.  
Step 2: After receiving the EID of the real-time video streaming service, the IoT-GW sends a name registration request to ENRS with the binding of EID and NA, as well as other parameters, such as \(T_{d}\). The ENRS Agent intercepts the message and forwards it to ENRS according to the name registration strategies.  
Step 3: If a UE (Consumer) wants to get the real-time video streaming service, firstly, the UE will search the GNNCS with HRN by explicit or implicit look-up to get the service EID.  
Step 4: After the UE has obtained the EID, it will store the binding of HRN and EID in its local cache. Then, the UE will send a name resolution message with EID and other parameters to the ENRS, according to the name resolution strategies, to obtain the NA(s).  
Step 5: After the UE has obtained the NA(s) by service EID, the bindings of EID and NA will be stored in UE. Then, the UE will send a data request that carries the EID of UE, EID of service, and EID of destination and NA(s) of requested data to the network; the data routing path will be generated according to the NA(s). The name resolution path and the data routing path could be dissymmetric.  
Step 6: When the IoT-GW receives the data request message with EIDs, it will add the UE's EID into the video service subscription table. Once the camera produces new content, the IoT-GW will name the video stream with the service EID and push it to all the subscribers by getting the NAs of all the UEs' EIDs. For real-time video services, the latest content provided by the camera will be stored in the network, the expired ones being ignored. Thus, we can use the same EID to represent the latest video data generated by the camera. The binding of the real-time video service's EID and its NA will only register once in ENRS until the NA changed. By querying the unique service EID, we can get the real-time video streaming service with its newest NA.  
For a pull-based, non-real-time service supported by ENRS, the steps of getting the content produced by these services are similar to the real-time video streaming service mentioned above. However, what is different is that each new data chunk should be registered in the ENRS with its unique EID, while the EID of the real-time video streaming service is only registered once with the same EID. In the pull-based model, each time a consumer requests new data, it needs to send an ICN name resolution request to the name resolution system to get the NA with data EID.  
Figure 5: The use case scenario of ENRS.