# ICN-Oriented Mobility Support Method for Dynamic Allocation of Mobile Data Flows
## 3 How Can Dynamic Allocation Flows Be Realized in Mobility Support?
### Architecture Overview  
At present, the ICN industry has put forward many ICN deployment plans, such as Publish Subscribe Internet Technology (PURSUIT) [30], Content-Centric Networking (CCN) [31], and Named Data Networking (NDN) [32]. However, these deployment plans are not compatible with traditional IP networks, resulting in high deployment costs that limit their development. The ICN architecture used in our mobility support method is the On-Site, Elastic, Autonomous Network (SEANet) [33]. It can coexist with existing IP networks to achieve incremental deployment. The content discovery mechanism uses lookup by name instead of routing by name (represented by CCN and NDN). According to the main principle of separation of identity and location in ICN, elements such as contents, devices, and services can be regarded as entities in the network. Each entity is assigned an Entity ID (EID) as an identifier (or name) and a network address (NA) as a locator. In order to be compatible with the existing IP network, the IP address is used as the NA. Therefore, the identifier is completely separated from the locator, and they are dynamically bound together through use of the Name Resolution System (NRS).  
As shown in Figure 1, we consider a mobile communication system that includes a producer, routers, Name Resolution Systems (NRSs), wireless access points (APs), and a consumer. The NRS maintains the latest mapping relationship between EIDs and NAs. The consumer requests multiple forms of content released by the producer. The content will be divided into multiple groups of packets for transmission. We define a group of packets from the same content as a data flow. The data packet needs to carry the source EID (identifier of the content), destination EID (identifier of the consumer), and destination network address (consumer's network address). Therefore, the source EID and the destination EID jointly identify a data flow.  
When the consumer moves, the destination NA in the data packets sent to the consumer will become invalid. The router can find the valid network address of the mobile entity in the NRS according to the identifier of the mobile entity. To support packet redirection, each router needs to maintain a Mobile Flow Table (MFT), which is composed of  
Figure 1: Architecture and handoff for dynamic allocation of mobile data flows.  
a group of Mobile Flow Table Entries (MFTEs). Each MFTE includes the source EID, the destination EID, and the destination NA, which is the latest network address of the destination EID. After receiving the packets, the router can support finding MFTEs according to the source EID and the destination EID or only according to the destination EID carried in the packets. If there is a matching MFTE, the router will replace the network address in the packet with the corresponding NA in the MFTE and then match the FIB for packet forwarding. If the match fails, the router will directly match the FIB for forwarding. Similar to MobilityFirst [34], we identify the function of the router modifying the destination address of the packets according to the identification (source EID and destination EID joint identification or destination EID identification alone) as a late-binding function, and we label the router that performs late-binding processing as a late-binding node (LBN). Access routers can sense the movement of mobile entities in some way. Perception is not the focus of this paper.