Named Data Networking (NDN) supports the consumer mobility service by letting a consumer reissue an interest. This method is straightforward, but it may cause several drawbacks, including unnecessary handover overhead and long handover delay. We concentrate on the NDN communication model in which the pair of an interest and a data packet is considered a single communication working set (i.e., transaction unit). In this respect, reissuing an interest means creating a new transaction due to the connection damaged by the movement of a consumer. It makes all states of the current transaction useless, and this is where the drawbacks arise. In order to enhance the consumer mobility service, we propose Mobility Link Service (MLS) operated in NDN face which is responsible for management of a connection for a transaction. MLS reuses the existing states of a transaction by establishing a connection for the transaction instead of creating a new one. In addition, MLS in NDN face makes consumer mobility service transparent to the NDN forwarding plane. Therefore, the consumer mobility service and the NDN architecture can evolve independently. The performance evaluation shows that MLS reduces the amount of retransmitted data and handover latency compared with the existing NDN mobility solution.

1. Introduction

Named Data Networking (NDN) [1, 2] is a promising future Internet architecture. It has emerged as an alternative architecture to the traditional IP-based networking to meet the requirements of content-oriented applications such as video streaming and P2P data sharing service. NDN treats contents as primitive elements, thereby being able to support content location independent communication. This NDN feature brings many advantages for content dispersion with use of in-network caching.

In NDN, consumer mobility service can be provided easily by retransmitting an interest for the content that is requested, but not received due to the handover. This approach is straightforward; however there are drawbacks to be improved. First of all, a consumer has to request and receive the entire content again regardless of how much content is received before handover, causing redundant data transmission. Second, a retransmitted interest will follow a new communication path until it reaches a NDN node that caches the requested content. In general, the NDN node having requested content is at the intersection of the new and old interest path. If both paths intersect after so many hops, or even do not intersect, the cache functionality of NDN may not be used effectively. These disadvantages arise because reissuing new interest makes existing NDN states, such as a cached data packet and PIT entry, useless.

Several proposals regarding the NDN consumer mobility problem have been published [35]. A proactive caching approach [3] lets a candidate NAR that is expected to communicate with a consumer after handover proactively retrieve and cache the contents. A centralized architecture of MobiNDN [4] maintains conditions of NDN nodes. When interest retransmission occurs, it establishes an optimal path for a reissued interest according to the consideration of cache efficiency. A proxy-based scheme [5] delegates a content dispatch process as well as handover handling process to a CCN proxy node. It fetches the cached content from the previous CCN node. All of these proposals focus on how to fetch the lost content again. However, these schemes are also based on reissuing a new interest through new NAR, so that the problems of the existing NDN consumer mobility scheme may be repeated. In addition, as they modify NDN architecture for mobility service, the dependency between NDN architecture and the mobility feature is formed. This may break the principle for simple architecture of a NDN forwarding plane.

In this paper, we pay attention to a NDN communication model in which a pair of interest and data packets is considered as a single communication working set. We define this communication set as a transaction unit in NDN communication. In transaction respect, reissuing an interest for mobility service means that a new transaction is created due to the connection being damaged by the movement of a consumer, even if there is no corruption on the transaction. Eventually, it makes all states for the current transaction worthless, causing the drawbacks of the existing consumer mobility scheme. In order to support consumer mobility service in terms of transaction, a Mobility Link Service (MLS) is introduced. MLS is operated as one link service protocol level at the NDN face which is responsible for the management of the connection under the NDN forwarding plane. It reuses the state of the existing transaction by reestablishing a connection to the previous NAR instead of creating a new transaction. This scheme decouples transaction, as well as connection for transaction. It makes the distortion of the connection transparent to the transaction, making the states of the transaction available continuously. It can reduce the handover latency and the amount of retransmitted data compared with the existing NDN solution. In addition, MLS can be developed independent of the NDN forwarding plane by being embedded to the face.

MLS is proposed based on our previous work [6]. The difference is that the unnecessary control message is eliminated, and the investigation result was corrected accordingly. The rest of this paper is organized as follows. Section 2 presents the related work. Section 3 introduces MLS in detail. Section 4 shows the analytical and simulation investigation result for the performance of the proposed scheme. In Section 5, we conclude this paper.

2.1. Named Data Networking

NDN [1, 2] is one of the most notable Information Centric Networking (ICN) architectures that has emerged to inherently support content-oriented communication. NDN treats content as a primitive element of communication. The contents are accessed based on their name, instead of a content server address. NDN communication is performed by the exchange of two types of packets: interest and data packet. An interest represents a data request, whereas a data packet is a response to the data request through the interest. A NDN node maintains three data structures for packet forwarding: Content Store (CS), Pending Interest Table (PIT), and Forwarding Information Base (FIB). CS is a local cache for data packets that have been passed through the NDN node. PIT records the information of received interests to build the reverse path of the interest for data packet forwarding. FIB is employed to forward an interest toward a producer of requested content, built by a name-based routing protocol such as NLSR [7].

NDN provides the consumer mobility service by letting a consumer retransmit an interest for the content that is requested, but not received during the handover procedure. This approach is not complicated, but there are several problems. First, entire data packets should be retransmitted regardless of how much content is received before handover whenever consumer handover occurs. A communication path leading a reissued interest will continue toward the NDN node, which is at the intersection of the new path and old path for the previous interest and caches content. If both paths intersect after multiple hops or even do not intersect, long handover latency will be caused.

2.2. Existing Consumer Mobility Schemes

There have been several proposals to address consumer mobility issues. Rao et al. [3] proposed a proactive caching approach in which a mobile consumer announces, pending its arrival to a candidate NAR, that it is expected to communicate with a consumer before handover. The candidate NAR fetches the content proactively. MobiNDN [4] proposes a centralized architecture permitting a centralized controller node to keep track of NDN node conditions like Software-Defined Networking. After handover, a mobile consumer reissues an interest to a centralized controller. The controller establishes an optimal path for the retransmitted interest according to the consideration of cache efficiency. A CCN proxy node introduced in a proxy-based mobility management scheme [5] is responsible for content dispatch, caching, and handover handling. When handover occurs (e.g., CCN proxy node is changed), a new CCN proxy node retrieves the cached content from the previous CCN node. These schemes pay attention to how to quickly the lost content is retrieved again with a reissued interest. As there is no consideration for NDN transaction, the drawbacks mentioned above may be repeated. In addition, these schemes modify the NDN architecture. It strengthens the dependency between the mobility feature and NDN forwarding plane and can damage the principles of simple NDN architecture.

3.1. System Overview

The handover signaling in the proposed scheme is performed only between the following two types of network entities: mobile NDN consumer (MNC) and NDN access router (NAR). MNC is literally a consumer who wants to receive content while moving. NAR is a NDN node considered to know where NDN packets are forwarded to reach the content source according to NDN routing protocol such as OSPFN [8] and NLSR [7]. As MNC does not employ the routing protocols commonly, MNC should send interests toward NAR. In the proposed scheme, ndn-autoconfig [9] is used to discover NAR with which MNC should communicate.

MLS is operated as a link service protocol at NDN face. When a handover is detected, MLS restores the connection that is corrupted due to the movement of MNC instead of creating a new transaction via a new interest. Through this recovered connection, data that could not be received during the handover procedure is received again from the lost point. At the same time, new interests for contents that will be requested after handover are sent toward new NAR. Figure 1 shows the network entities and their basic activities.

MLS supports the consumer mobility service as well as the content fragmentation and retransmission function with the following two message types: a MLS fragment message and a status report message. The fragmentation function is provided with the MLS fragment messages into which NDN packet is divided with sequence number. The status report message is used to request reestablishment of the connection and retransmission of a lost NDN packet.

3.2. A Mobility Link Service Architecture

Face, the generalization of the network interface, is located under the NDN forwarding plane. It is responsible for the management of a connection for a transaction. Face is composed of a link service and a transport. The link service provides a link adaptation function, such as fragmentation and link error recovery, whereas the transport supports low-level details for transmitting and retrieving packets via specific links.

Generic link service, the default NDN link service, provides fragmentation, reassembly, and retransmission functions. However, as it cannot keep track of the condition of a connection for a transaction, it cannot handle the movement of MNC.

MLS is proposed as one of link service of face for consumer mobility service. MLS provides the following three main functions: a connection reestablishment, data retransmission, and NDN packet fragmentation and reassembly. These functions are operated based on a transaction structure and two types of MLS messages. Figure 2 illustrates the NDN face architecture with MLS.

3.2.1. Transaction Structure

A transaction structure is used to maintain the states of transactions within MLS such as endpoint address of connection and the sequence number of receiving MLS fragment messages. This structure is generated for each transaction. In other words, it is generated when receiving an interest that initiates a NDN transaction from an upper or a lower layer. It is a soft-state structure. When a NDN transaction is terminated by receiving all required data, or expiration time of a transaction structure has passed, it is eliminated. The transaction structure consists of the following four elopements: content name, nonce, transmission state, and address information.(i)Content name: literally the content name which is derived from a received interest. It is used to identify a transaction structure in MLS.(ii)Nonce: the fixed-length value from a nonce field of a received interest. In other words, a nonce is assigned by MNC. It is included in MLS messages to identify a relevant transaction structure within MLS of a remote node instead of the content name. It can reduce unnecessary packet overhead caused by variable-length content name.(iii)Transmission state: a condition about NDN transaction. For example, how much NDN packet is currently received and the expiration time of a remaining transaction. In addition, transmission state includes buffer function that maintains NDN packets until the NDN transaction ends. It is used to fulfill elements of MLS messages such as sequence number of a data fragment message or sequence number of missed fragment of status report message.(iv)Address information: field for representing transport endpoint of the communicating connection. It is updated when receiving a status report message that contains the information for the changed condition of a connection.

3.3. MLS Messages

MLS introduces two message types (Figure 3): the MLS fragment message and the status report message. A Type-Length-Value (TLV) structure is adopted to MLS messages according to the link service packet format of NDN face [10].

3.3.1. MLS Fragment Message

MLS fragments an NDN packet to several MLS fragment messages with sequence numbers. For the size of this message, a Maximum Transmission Unit (MTU) of the underlying transport network or wireless link condition should be considered.(i)Nonce: the value from the nonce field of a NDN packet. MLS fragment messages derived from the same NDN packet have the same nonce value. It is used to group the MLS fragment messages together like the identification field of a IPv4 header.(ii)Sequence number: the offset of a fragmented packet.(iii)Last fragment flag: flag value indicating whether more MLS fragment messages should be expected like more fragment field of IPv4 header.(iv)Payload: fragmented NDN packet.

3.3.2. Status Report Message

MLS uses a status report message to inform the previous NAR about the status of transaction, such as connection information that is changed after the handover MNC. In addition, it can be employed to request retransmission of a MLS fragment message, even if the handover does not occur, when the retransmission timer expires.(i)Nonce: the same value with a nonce field of a transaction structure that is derived from a nonce value of interest. It is used by a remote node receiving status report message to distinguish a relevant transaction structure.(ii)Sequence number of missed fragment: the sequence number of the lost MLS fragment message.(iii)Address information: field indicating changed transport endpoint address of MNC. It is an optional field, as this field is not used when requesting retransmission without handover.

3.4. MLS Operation

MLS is operated in two stages: before handover stage and during handover stage. Figure 4 shows the operation flow of MLS.

3.4.1. Before Handover Stage

The operation of MLS starts at MNC when receiving an interest from the NDN forwarding plane. MLC creates a transaction structure based on the received interest that triggers the transaction. The interest is fragmented into several MLS fragment messages if the size of the interest is bigger than MTU size (or a condition of wireless network is bad). Otherwise, the interest is included in the MLS fragment message as payload. The MLS fragment message for the interest is transmitted via a transport of the NDN face to a NAR.

MLS of the NAR, which receives the MLS fragment message derived from the interest of MNC, generates a transaction structure based on the received interest. The interest is passed to an upper NDN forwarding plane. When receiving a data packet from the NDN layer as response of the interest, MLS fragments this packet into several MLS fragments messages. These messages are sent to the MNC.

MLS of the MNC receives the MLS fragment messages derived from the requested data and recognizes the relevant transaction field based on a nonce field of a MLS fragment message. It reassembles the received MLS fragment messages based on the sequence numbers and the transaction structure. Then, when all MLS fragment messages are received, every role of MLS is completed for this transaction. The transaction structure is eliminated. The transaction structure of the NAR waits for a status report from MNC. If no status report message is received until after the expiration time for the transaction has passed, the transaction structure of NAR is also removed.

Provided that MLS fragment messages are lost without handover like a case that transmission expiration timer for a transaction expires, a status report message can be used to request retransmission for lost MLS fragment messages with their sequence numbers.

3.4.2. During Handover Stage

The process of during handover stage is straightforward. If MLS fragment messages (derived from NDN data packet) are lost because of the movement of MNC before the transaction ends, MNC sends the status report message that includes the new transport endpoint information and the sequence number of the missed MLS fragment message to the previous NAR. Upon receipt of the status report message, NAR updates the address information of the transaction structure and retransmits the lost MLS fragment messages.

The operation of MLS on during handover stage is only relevant to a transaction that has the connection corrupted by consumer movement. A new interest that creates a new transaction (for new content) is transferred to a new NDG to which MNC attaches after handover.

For the clarification of the proposed scheme, Algorithm 1 shows the operation of MLS (it assumes that interest does not exceed MTU size).

1:  while isMLSTerminated( ) do
2:   procedure RECEIVEPACKET
3:    type = Packet.getType( )
4:    if then
5:     cn = Interest.getContentName ( )
6:     nonce = Interest.getNonce ( )
7:     trans = new Transaction
8:     this.sendPacket
9:    end if
10:    if then
11:     nonce = Data.getNonce( )
12:     trans = this.findTransaction
13:     mlsFrags = this.fragment
14:     this.sendPacket
15:    end if
16:    if then
17:     nonce = mlsFrag.getNonce( )
18:     trans = this.findTransaction
19:     trans.putFrag
20:     if then
21:      packet = trans.getPacket( )
22:      this.sendPacket
23:      delete
24:     end if
25:    end if
26:    if then
27:     nonce = stateReport.getNonce( )
28:     trans = this.findTransaction
29:     trans.updateTransaction
30:     mlsFrags = trans.getFrags
31:     this.sendPacket
32:   end if
33:   end procedure
35:   procedure DETECTHANDOVER
36:    sr = new StateReport
37:    this.sendPacket
38:   end procedure
39:  end while

4. Performance Evaluation

In this section, we evaluate the performance with an analytical and simulation investigation by comparing the NDN consumer mobility scheme. Before discussing the performance evaluation, we define the network model.

4.1. Network Model

The network model for performance evaluation is shown in Figure 5. In this network model, we assume that NDN basically operated over IPv4 as a transport protocol because it is impractical for current IP-based networks to be replaced by NDN at once. The hop count between each network entity is set to 1.

The handover events can be categorized as two cases: the intra NAR handover and the inter NAR handover. The intra NAR handover is the case that no NAR is changed, while the connection condition for the current transaction is changed because of the IP address change by movement toward another IP router. The inter NAR handover is the case that NAR with which MNC should communicate is changed. The proposed scheme handles both cases in the same way.

We assume the intra NAR handover as the situation that MNC communicates with NAR1 through AP1, and then it moves to AP2, so that the existing transaction cannot be completed normally. And, the inter NAR handover is that the MNC communicates with NAR1, and then it moves to NAR2.

4.2. Analytical Investigation

For the analytical investigation, we formulated the analytical cost model of the proposed scheme and the existing NDN consumer mobility scheme with a generic link service (default NDN link service). The total handover cost of both schemes, which is defined as the additional accumulative overhead resulting from transmitting handover-related packets, besides the cost of creating an existing transaction, is evaluated.

The parameters used for analytical investigation are defined in Table 1. We assume that MLS and the original NDN’s scheme fragment data packets into the same size , and interest () is not fragmented. We set the default values of related parameters as follows: = 44 bytes, = 31 bytes, = 1 MB, = 1033 bytes, and N = 1024, respectively, according to [2, 1012]. is set to 0 and 1 to show the cases of intra NAR handover and inter NAR handover, respectively.

4.2.1. Analytical and Numerical Result

The cost for creating a transaction in the original NDN which fragments a data packet into N data messages through a generic link service or MLS (denoted by ) can be expressed as

In order to handle handover, the original NDN consumer mobility scheme creates a new transaction regardless of how much data is received by reissuing an interest for the content that is requested, but not received. The process of regenerating transaction should continue until the NDN node where the old path leading the interest issued before handover and the new path for the reissued interest intersect. Therefore, if we let be the hop counts to the intersection, its handover cost () can be defined as

MLS reestablishes a connection with the previous NAR that maintains information for the current transaction such as cached data and PIT entry using a status report message. It requests retransmission of lost data from the lost point instead of requesting retransmission of whole data packet again. The handover cost () to can be formulated as

Figure 6 shows the total overhead of both schemes according to parameter K. The overhead of MLS is always smaller than that of the original NDN mobility scheme regardless of intra NAR handover or inter NAR handover. This is the result of the NDN mobility scheme always having to create a new transaction, whereas the proposed scheme retrieves the data from the lost point using the state of the existing transaction.

Since the transaction creation process in the existing NDN scheme should be repeated until a new interest reaches the intersection, its overhead caused by inter NDG handover will be grown as increases or the size of the data packet increases. In addition, the overhead of the NDN scheme should be larger when data packet loss occurs more than once for the same transaction.

4.3. Simulation Investigation

To assess the handover performance of the proposed scheme, we modify the ndnSIM 2.0 that is implemented based on the ns-3 simulator [13]. The network model is described in Figure 5. The link delay for each network entity is 10ms, and the speed of the MNC is 6 m/s with the constant velocity mobility model. The size of the data packet which the MNC requests is 1MB, and this data is fragmented into 1KB payloads.

In the simulation investigation, we measure the delay of inter NAR handover, which is the time spent until MLS fragment messages for data are completely received from when MNC and NAR2 connect.

4.3.1. Simulation Result

Figure 7 shows the inter NAR handover delay of the proposed scheme and the NDN’s solution according to the sequence number of the lost data segment. MLS always performs better than the original NDN mobility scheme. The first reason is that the original NDN should retrieve the entire packet again, whereas the proposed scheme needs to receive fragmented messages from the lost point. The second is that the reissued interest of NDN follows a new communication path to an intersection node with hop count set by 1. The proposed scheme retrieves the lost data from the previous NAR via a new connection. Therefore, although the first fragment is lost, the performance of the proposed scheme betters than that of NDN. The larger the hop count to an intersection NDN node, the larger the performance difference between the both schemes. This means that the proposed scheme has a better advantage of the NDN cache capabilities.

5. Conclusion

We propose MLS, which is operated under the NDN forwarding plane, to enhance the consumer mobility service. It establishes a new connection for a transaction to replace the connection damaged by the movement of a MNC instead of reissuing an interest that creates a new transaction. It allows for reuse of the states of existing transaction such as cached content and PIT entry. It is located in the NDN face, so that it hides the distortion of the connection to the transaction. Therefore, the consumer mobility service of the proposed scheme is transparent to the rest of NDN architecture. The NDN architecture and MLS can be developed independently, and it is possible to apply different mobility schemes at the NDN level with MLS. The analytical and simulation investigation show that MLS is practical and more effective than the NDN solution.

As the upcoming 5G era has to support high capacity services such as virtual reality, augmented reality, and 4K video streaming, NDN (with its features for content dispersion) will attract attention of telecommunication industry. However, even if NDN is utilized, especially in the case where handover between routers occurs frequently like vehicle communication environment, mobility handling has to be supported to constantly provide these services. We think that MLS would be helpful to address mobility problem.

Data Availability

The data used to support the findings of this study are available from the corresponding author upon request.

Conflicts of Interest

The authors declare that they have no conflicts of interest.


This work was supported by the National Research Foundation of Korea (NRF) grant funded by the Korea Government (MSIT) (no. NRF-2018R1A2B6009122). And, this research was supported by the MIST (Ministry of Science and ICT), Korea, under the National Program for Excellence in SW (2015-0-00936) supervised by the IITP (Institute for Information & Communications Technology Promotion).