Loading web-font TeX/Math/Italic
Secure and Fault-Tolerant Distributed Location Management for Intelligent 5G Wireless Networks | IEEE Journals & Magazine | IEEE Xplore

Secure and Fault-Tolerant Distributed Location Management for Intelligent 5G Wireless Networks


A secure and fault-tolerant distributed location management is proposed in this paper. The proposal utilizes a distributed hash table of access nodes for a mobile node's ...

Abstract:

Distributed mobility management (DMM) requires a flattened cellular network architecture to meet ever-increasing traffic demands of mobile users. In order to get rid of c...Show More
Topic: Intelligent Systems for the Internet of Things

Abstract:

Distributed mobility management (DMM) requires a flattened cellular network architecture to meet ever-increasing traffic demands of mobile users. In order to get rid of centralized mobility entities, it is desirable to manage locations of mobile nodes (MNs) in a distributed but secure and fault-tolerant manner. To address such issues, in this paper, we propose a secure and fault-tolerant mechanism for DMM. The proposed mechanism utilizes a distributed hash table of access nodes for distributed location management, and a ticket-reuse approach is adopted for improving authentication performance while providing secure authentication of the MNs. We present an analytical model to calculate the processing time of a location query. We have evaluated the proposed security mechanism in terms of authentication latency and a number of authentication messages required for secure handover. Analysis results confirm that the proposed mechanism outperforms the popular existing authentication protocol, EAP-TLS, in a DMM environment.
Topic: Intelligent Systems for the Internet of Things
A secure and fault-tolerant distributed location management is proposed in this paper. The proposal utilizes a distributed hash table of access nodes for a mobile node's ...
Published in: IEEE Access ( Volume: 6)
Page(s): 18117 - 18127
Date of Publication: 28 February 2018
Electronic ISSN: 2169-3536

Funding Agency:

No metrics found for this document.

SECTION I.

Introduction

Existing mobility management protocols such as Mobile IPv6 (MIPv6) [1] and Proxy Mobile IPv6 (PMIPv6) [2] have been developed with an assumption that a cellular network architecture is centralized. However, the assumption is being changed. The cellular network architecture is being flattened for better performance and scalability, while there are many reports that centralized network architecture and mobility management protocols cause a network bottleneck and present a single point of failure. To address the centralized mobility management protocol issues, the IETF Distributed Mobility Management (DMM) working group was proposed to develop DMM protocols to operate in a distributed network architecture [3] for intelligent 5G wireless networks [4]–​[8]. Some of the important ongoing works of the working group include DMM deployment models and architectural considerations, on-demand mobility management, protocol for forward policy configuration, etc.

In DMM, the data plane and the control plane are separated and the data plane is distributed for better performance and scalability over the network architecture. The control plane however can either be distributed (i.e., fully distributed DMM) or centralized (i.e., semi-distributed DMM) for ease of location management [9], [10]. For instance, in [11], a centralized Session Initiation Protocol (SIP) register has been proposed for a DMM environment. However, the SIP register can be duplicated to improve the reliability but it does not give the level of resilience that can be obtained with a fully distributed architecture. There is thus a need to define an architecture fully compatible with DMM. More details about the background and approaches of DMM are available in [9] and [10]. In addition, as a preliminary work [12], we analyzed the performance of a DMM approach called Dynamic Mobility Anchoring (DMA) [13] in comparison with PMIPv6.

Without securing wireless network access, an illegitimate Mobile Node (MN) can access network resources and launch various attacks. Only an authenticated and authorized MN, i.e., legitimate MN, should be able to access the network resources. For instance, only a legitimated MN registers and updates its location during its handover after secure authentication. If no wireless network access security provided, an illegitimate MN can send malicious location update messages on behalf of a legitimate MN or it can redirect or block data packets related to location updates. To address such issues, in this paper, we propose a secure and fault-tolerant mechanism that uses a distributed hash table of access nodes for distributed location management while a ticket-reuse approach is adopted for improving authentication performance. The main contributions of this paper are as follows:

  1. Fault-tolerant and fully distributed location management based on a Chord Distributed Hash Table (DHT).

  2. Analytical model to calculate the average processing (response) time of a location query.

  3. Ticket-reuse approach designed for distributed location management.

  4. Performance analysis results of the proposal that has been compared with TAP-TLS in terms of authentication latency and number of authentication messages.

The remainder of the paper is organized as follows: Section II briefly describes the literature closely related to our work. Section III presents the analytical model to calculate the processing time of a location query and describes the proposed mechanism. Performance analysis is described in Section IV and the results are presented in Section V. The paper is concluded with some remarks in Section VI.

SECTION II.

Related Work

A. Mobility Management and Handover Authentication

A distributed and dynamic location management scheme proposed in [14] reduces the signaling traffic and signaling delay as compared to previously developed schemes. The authors proposed the scheme to distribute the signaling burden by dynamically adjusting regional network boundaries depending on the up-to-date mobility and traffic load for each MN.

The idea of using multiple location servers instead of a centralized home location register is not new. Prakash et al. [15] proposed a distributed location management strategy that is based on quorums and dynamic hashing and has the granularity of a Registration Area (RA). The works presented in [16]–​[19] have similar ideas. The main aim of the mechanism in [15] was to provide load balancing among location servers in order to reduce location update and query time.

A dynamic location management scheme is described in [20] for the low mobility rate of an MN and a static scheme is presented for the high mobility rate. According to the authors’ claim, the dynamic scheme performs better than the static scheme for high paging cost or when the number of cells in an Location Area (LA) is large.

Sidhu and Singh [21] describe several metrics such as location update cost and paging cost metrics for location management. The schemes are classified into static and dynamic location update schemes. The static schemes are based on the topology of the network whereas the dynamic schemes are based on time, movement or distance. In [22], a simulation environment is described with a claim that, in terms of location management cost, LA based location management using a profile or history-based direction information gives the best performance. In order to reduce the cost of location updates, a dynamic location management approach has been proposed in [23]. However, the approach slightly increases the paging cost compared to the static approach.

DHT based mechanisms have extensively been proposed to solve different problems in wireless networks. An improved handover management mechanism based on a DHT was proposed in [24]. A DHT based distributed localization service for wireless mesh networks is also proposed in [25]. To reduce the packet loss due to IP handovers, a mechanism utilizing the mobile Stream Control Transmission Protocol (mSCTP) for improved transport and a Chord DHT [26] for location management was proposed in [27]. A two-tier Chord DHT for distributed location management was introduced in [28] that uses the nodes with high computation power and stability as location servers.

For DMM, a SIP-based centralized location server was described in an earlier work of Ali-Ahmad et al. [29]. The main objective of the work in [29] was to reduce the number of location update messages that are sent by MNs to the centralized location server. An analytical model was presented to calculate the load of the location updates.

TAP-TLS [30] is a popular authentication scheme that is widely used in existing wireless mobile networks. It performs the full EAP exchange for initial and handover authentications for an MN. As a baseline authentication scheme, TAP-TLS has been deployed and analyzed, but as studied, this scheme does not provide any performance optimization. For instance, when an MN changes its attachment point, the MN must perform the full EAP exchange that causes a long latency so that user’s quality of experience is degraded. To address this kind of problem, studies on performance optimization in handover authentication have been conducted. For instance, the authentication scheme in [31] utilizes a local credential obtained from an Access Router (AR), i.e., Mobile Access Gateway (MAG) of PMIPv6, in initial authentication when an MN performs handover authentication with another AR in a PMIPv6 environment. In [35], Handover Optimized Ticket-based Authentication (HOTA) has been proposed in which an MN performs handover authentication on different access networks securely by reusing credential issued by authentication server in a PMIPv6 environment.

The proposed work is different compared with the distributed and dynamic location management scheme in [14] as the proposed mechanism considers a fixed-size access network area, i.e., the area covered by the AR. In addition, the proposed mechanism introduces a replication strategy for a distributed and secure location management based on a DHT. Our work is also different compared with the previous DHT based mechanisms [24], [25], [27], [28] as the proposed mechanism considers that all ARs have location registers and extends the DHT to provide fault tolerance in location management. Compared with the existing authentication schemes in [31] and [35], the proposed one is developed for DMM and focuses on providing an application level security.

B. Chord DHT

Chord is a protocol and algorithm for a peer-to-peer DHT. The central pillars of the DHT are n -bit identifiers in the range [0, 2^{n}-1 ]. An identifier of a node is its ID. An identifier of a data item is its key ({K} ). A data item has a record value ({V} ) that is associated with the key ({K} ) of the data item. Both, the node and the data items, are mapped on the same n -bit Chord identifier space. The key and value pair (K-V) is hosted by the node whose ID is greater than or equal to K . A node in a Chord circle is responsible for all keys that precede it counter-clockwise till the previous node [36].

Figure 1 illustrates a 6-bit Chord identifier circle having ten nodes and seven data items. It shows that N8 is the successor node of K5 as it is the next node to it clockwise and the successor node of K43 is N43 as their identifiers are equal.

FIGURE 1. - A 6-bit Chord identifier space in which the dotted lines indicate which nodes host which keys and the black lines represent the fingers of node 
$N8$
 [36].
FIGURE 1.

A 6-bit Chord identifier space in which the dotted lines indicate which nodes host which keys and the black lines represent the fingers of node N8 [36].

Every node maintains a routing table called a finger table pointing to some other nodes on the identifier circle. The finger table has n entries in a circle with n -bit identifiers. On a node p , the finger table entry at row i identifies the first node that succeeds p by at least 2^{i-1} , i.e., successor \left ({p+2^{i-1}}\right) , where 1\leq i \leq n . For example, the third finger (8 + 22 = 12) is N15 . The i -th finger of a node in its finger table is always its immediate successor node on the identifier circle. For routing purpose, each finger entry consists of a node ID, its IP address, and port number. When a query reaches a node p such that K lies between p and the numerically closest successor in the finger table of p , then the node p reports the successor as the answer to the query.

SECTION III.

Secure and Fault-Tolerant Mechanism

In this section, we present the proposed secure and fault-tolerant mechanism. We choose a finger-table based Chord DHT to implement fault-tolerant distributed location management. Chord is preferred because it is a simple and efficient protocol for storing, updating, and retrieving a location binding of an MN in O(logm) time, where m is the total number of access networks in a cellular network.

In the proposed mechanism, every MN is uniquely identified by its ID information, e.g., SIP-like URI such as SIP:MN0@abc.com or permanent IP address of the MN. The mobile network is made of Access Nodes (ANs). In a centralized mobile network, the Location Register (LR) is a standalone entity. We propose to distribute the LR function on every AN. It means that an AN has both AR and LR functions. MNs can access the Internet through the AR of an AN. An IP prefix is associated to that AR. In other words, when an MN is managed by an AN {j} , it gets an IP address whose prefix is the one associated with the AR of AN {j} . Location of an MN is managed by an LR, which knows the association between the ID and the prefix of an MN. So, knowing the location of an MN is equivalent to knowing its IP address in DMA for instance [13].

The data items are the IDs of the MNs and the nodes are the ANs. We map the keys and ANs on a Chord circle using hash values produced from the IDs of MN and network prefixes of ANs. Each MN has a unique ID, ID_{MN} , which is used to produce {K} . The hash values are mapped on the same address space. The LR maintains the location binding information of MNs. Each entry of LR holds a K-V pair. In the proposed scenario, {K} is the hash of ID_{MN} and {V} is the current IP address of the MN.

A. Addition/Update of K-V Pair

We propose a fault-tolerant distributed location server. We achieve the fault-tolerance through a single level of replication for the location bindings of MNs. The chances that both peers (i.e., ANs), maintaining the main and the backup copies of an MN’s location binding, go down simultaneously are close to zero. So, it is reasonable to consider only a single level of replication.

Figure 2 shows a Chord circle having 8 ANs mapped on it. It shows that the backup copy of a K-V pair, maintained on AN7 , is accessed by a Correspondent Node (CN) in case of failure of the main copy, maintained on AN3 . We outline the step-wise procedures of addition/update of main and backup copies of a K-V pair, separately.

FIGURE 2. - Fault-tolerance in the distributed location management. The backup copy of K-V pair is accessed in case of failure of the main copy.
FIGURE 2.

Fault-tolerance in the distributed location management. The backup copy of K-V pair is accessed in case of failure of the main copy.

1) Addition/Update of Main Copy

On addition/update of the main copy of K-V pair, the pair is assigned to the peer that is the first successor of K=hash(ID_{MN}) on the Chord circle.

Through the currently attached AN, an MN sends the location registration/update to its default LR. The location information that is stored along with the key is the current IP address of the MN. We call this query as a Location Update Query (LUQ).

When a peer receives a location registration/update query from an MN, it checks whether the address space managed by it includes {K} . In case the address space includes {K} , it registers/updates the location and sends the acknowledgement to the MN. In case, it does not include {K} , it checks its finger table to find the closest successor of the {K} on the Chord circle and then it forwards the query to that successor node. This process continues till the target node, managing the relevant {K} , is found out. With the help of a simple example, in which 10 ANs are mapped on a 6-bit Chord circle, we explain the K-V pair addition/update process of the proposed scheme. Figure 3 illustrates the K-V pair addition/update process.

  1. An MN is connected with its AN (i.e., AN8 in Figure 3) to register/update its location.

  2. AN8 sends MN’s location registration/update request to its LR.

  3. The LR of AN8 calculates K=hash(ID_{MN}) . The LR of AN8 checks whether the address space managed by it includes {K} . The LR does not find {K} . So, AN8 checks its finger-table in order to find the closest successor of {K} on the Chord circle. As shown in Figure 3, the closest successor to {K} is AN43 .

  4. AN8 forwards the locations registration/update query to AN43 .

  5. The LR of AN43 finds out that {K} is managed by it. So, it stores/updates the location binding information of the MN.

  6. Subsequently, the LR of AN43 replies back the registration acknowledgement on the reverse query path to the MN.

FIGURE 3. - Addition/update of main copy of K-V pair.
FIGURE 3.

Addition/update of main copy of K-V pair.

The Location Search Query (LSQ) from a CN is handled in the same way as mentioned above. As a result of the LSQ, the CN gets the current IP address of the MN on providing the ID_{MN} .

2) Addition/Update of the Backup Copy

On addition/update of the backup copy of K-V pair, the pair is assigned to the peer which is the first successor of K^{\prime }=Successor(hash(ID_{MN})+2^{n}/2) on the Chord circle. The steps of addition/update of the backup copy of K-V pair are the same as explained above for the addition/update of the main copy. We emphasize that the failure of an AN in the proposed mechanism is a rare event as opposed to a typical P2P system.

B. Analytical Model for Calculating the Processing Time

In this section, we present an analytical model for calculating the average processing time taken by a Location Query (LQ). An LQ can either be a Location Update Query (LUQ) or a Location Search Query (LSQ). Since, each type of query performs the same type of routing steps in the DHT and undergoes similar type of processing so, in the model, we do not differentiate them and consider each of them as an LQ. An LQ can either have a query-miss on an AN or it can have a query-hit on the AN. In case of query-miss, the AN is called an intermediate AN and in case of query-hit, it is called a final AN. The two types of processing at an AN results in a two-queue based query processing system as shown in Figure 4. Each queue of the system is a deterministic queue having its own service rate. Since the processing steps at an AN are always same, an LQ always takes a constant service time for processing while being in service. The symbols that are used in the analytical model are listed in Table 1.

TABLE 1 List of the Symbols Used in the Analytical Model
Table 1- 
List of the Symbols Used in the Analytical Model
FIGURE 4. - The two-queue based query processing system wherein 
$D_{i}$
 and 
$D_{f}$
 represent the deterministic service times of an LQ at intermediate and final ANs, respectively.
FIGURE 4.

The two-queue based query processing system wherein D_{i} and D_{f} represent the deterministic service times of an LQ at intermediate and final ANs, respectively.

We assume that LQ requests arrive at an AN according to a Poisson process. The process results naturally when a reasonably large population of the MNs update their locations independently and a reasonably large population of the CNs search for the locations of the MNs independently. Since there is no practical evidence that the pattern of arrivals of LQ requests on an AN follows any special distribution, but there are strong indications that a cellular network have a large numbers of MNs, the Poisson assumption holds.

Let \lambda _{LSQ} be the arrival rate of LSQs on the DHT related to an MN. This is the rate with which the CNs are creating the sessions on the MN. Let \lambda _{LUQ} be the arrival rate of LUQs on the DHT sent by an MN. This is the rate with which the MN is updating its location in the DHT. Let \lambda _{LQ} be the arrival rate of both types of LQs on the DHT. Then, \lambda _{LQ} can be calculated as follows:\begin{equation} \lambda _{LQ} = \lambda _{LSQ}+\lambda _{LUQ} \end{equation}

View SourceRight-click on figure for MathML and additional features.

Let N_{MN} be the total number of MNs and N_{AN} be the total number of ANs in the cellular network. Let \lambda be the arrival rate of LQs on an AN. Then, \lambda is calculated as follows:\begin{equation} \lambda = \frac {\lambda _{LQ} N_{MN}}{N_{AN}} \end{equation}

View SourceRight-click on figure for MathML and additional features.

Let N_{DHT} be the average number of DHT overlay hops that are traversed for an LQ. Based on the findings in [32]–​[34], it can be calculated as follows:\begin{equation} N_{DHT} = \left \lceil{ \frac {N_{AN}}{\log (\log (N_{AN}))} }\right \rceil \end{equation}

View SourceRight-click on figure for MathML and additional features.

Let {p} be the probability that the arrival of an LQ is on an intermediate AN. Then, p=\frac {N_{DHT}}{N_{DHT}+1} . Let \lambda _{i}(=p\lambda) be the arrival rate of the LQs for which an AN is an intermediate AN. Let \mu _{i} be the service rate of an LQ on an intermediate AN and \rho _{i}\left ({=\frac {\lambda _{i}}{\mu _{i}}}\right) be the utilization of the server of this m/D_{i}/1 queue. Let W_{i} be the waiting (processing) time of an LQ on the intermediate AN. Then, from the standard queueing theory, W_{i} is calculated as follows:\begin{equation} W_{i} = \frac {1}{\mu _{i}}+\frac {\rho _{i}}{2\mu _{i}(1-\rho _{i})} \end{equation}

View SourceRight-click on figure for MathML and additional features.

Let \lambda _{f}(=(1-p)\lambda) be the arrival rate of the LQs for which an AN is a final AN. Let \mu _{f} be the service rate of an LQ on a final AN and \rho _{f}\left ({=\frac {\lambda _{f}}{\mu _{f}}}\right) be the utilization of the server of this m/D_{f}/1 queue. Let W_{f} be the waiting (processing) time of an LQ on the final AN. Then, from the standard queueing theory, W_{f} is calculated as follows:\begin{equation} W_{f} = \frac {1}{\mu _{f}}+\frac {\rho _{f}}{2\mu _{f}(1-\rho _{f})} \end{equation}

View SourceRight-click on figure for MathML and additional features.

Let N_{hops} be the average number of the physical IP network routing hops to be traversed by an LQ for each hop of the DHT and R_{delay} be the average per hop routing delay of the IP network. Let \Theta be the average processing time of an LQ. Then, \Theta can be calculated as follows:\begin{equation} \Theta = (N_{DHT} \times N_{hops} \times R_{delay}) + (N_{DHT}\times W_{i}) + W_{f} ~ \end{equation}

View SourceRight-click on figure for MathML and additional features.

C. Adding Security

We present Ticket-based Authentication for Location Management (TALM) of the proposal. The authentication process can be divided into two parts. As explained in Section III, we define AN=AR+LR , i.e., an AN has both AR and LR functions.

  1. Authentication at the time of expiry of the required security credentials (for performing authentication) of an MN or at the first time the MN is switched on (Ticket creation and expiry).

  2. Authentication at the time of an IP handover of an MN in which the MN has to obtain the required security credentials from the previous AR (Ticket collection from the previous AR).

The symbols that are used in TALM are listed in Table 2. We assume that the keys shared between the Authentication Server (AS) and the MN, K_{AS-MN} , and between the AR and the AS, K_{AS-AR} , already exist. The AS only needs to provide K_{MN-AR} (i.e., session key), which will be shared between the MN and the AR.

TABLE 2 List of the Symbols Used in TALM
Table 2- 
List of the Symbols Used in TALM

1) Ticket Creation and Expiry

Following are the steps of TALM for ticket creation and expiry.

  1. An initial message (MN_{Reg}) is sent from the MN to the AR when the MN has just been switched on and needs to register itself with the AR or MN is creating a new ticket due to the expiry of the previous ticket.\begin{equation*}MN -> AR: MN_{Reg}(ID_{MN} || ID_{AR} || N_{MN})\end{equation*}

    View SourceRight-click on figure for MathML and additional features. where N_{MN} is the nonce generated by the MN.

  2. As the AR receives this initial message, it adds its own nonce and creates a message (MN_{Reg}AS_{Msg}) to be sent to the AS: \begin{align*}&\hspace {-0.7pc}AR -> AS: MN_{Reg}AS_{Msg}(E (K_{AR-AS}, ID_{MN}||\\&\qquad \quad \qquad \qquad \qquad \qquad \qquad ID_{AR}||N_{MN}|| N_{AR}))\end{align*}

    View SourceRight-click on figure for MathML and additional features. The AR encrypts this message before sending to the AS using the key it shares with the AS.

  3. The AS generates the following ticket:\begin{equation*} TK = E(K_{TK},K_{MN-AR}||ID_{MN}||TT)\end{equation*}

    View SourceRight-click on figure for MathML and additional features. This ticket is encrypted using another key K_{TK} . Inside this ticket is K_{MN-AR} (that is shared between the MN and AR) and the time TT for which this ticket is valid. The AS wants to transmit the K_{MN-AR} to both the MN and the AR. Since, sending important data such as a key over the network is not safe, we use K_{TK} .

  4. Now the AS will send a message (AS_{Res}) to send K_{MN-AR} to the AR by encrypting it using the key it shares with the AR: \begin{align*} AS -> AR: AS_{Res}(ID_{MN} || TK || E (K_{MN-AS}, K_{MN-AR} || \\ ID_{AR} || TT || N_{MN}) || E (K_{AR-AS}, K_{TK} || TT ||N_{AR}))\end{align*}

    View SourceRight-click on figure for MathML and additional features. The AR will only be able to extract \begin{equation*}E(K_{AR-AS}, K_{TK} || TT || N_{AR})\end{equation*}
    View SourceRight-click on figure for MathML and additional features.
    part of the message. Once the AR gets K_{TK} , it can decrypt TK and extract K_{MN-AR} (the key it shares with the MN).

  5. Now the AR will communicate {K} to the MN using (RegRes) message:\begin{align*}&\hspace {-0.5pc}AR -> MN: RegRes (ID_{MN} || TK || \\&\qquad \quad \qquad E (K_{MN-AS}, K_{MN-AR} || ID_{AR} || TT || N_{MN}))\end{align*}

    View SourceRight-click on figure for MathML and additional features. Using its key with the AS, the MN will be able to extract K_{MN-AR} .

  6. Now both AR and MN have K_{MN-AR} and both have knowledge of the ticket’s expiry. A last message (AuthMsg) will be sent by the MN to the AR to authenticate itself along with a location update message.\begin{align*}&\hspace {-1.7pc}MN -> AR: AuthMsg (ID_{AR} || TK || E (K_{MN-AR},\\&\qquad \qquad ID_{MN} || IP-Addr || (N+1)_{MN}))\end{align*}

    View SourceRight-click on figure for MathML and additional features.

If the AR successfully decrypts this message, then the MN has successfully authenticated itself. IP-Addr is the current IP address of the MN, which is securely sent. Nonces are used in the messages to prevent man-in-the-middle replay attack. The flow of the messages is shown in Figure 5.

FIGURE 5. - Ticket creation and expiry.
FIGURE 5.

Ticket creation and expiry.

2) Ticket Collection from a Previous AR

Following are the steps of TALM for ticket collection from previous AR.

  1. The MN sends a message (nAR_{Reg}) to the nAR (newly attached AR of the MN), which does not know about K_{MN-AR} .\begin{equation*}MN -> nAR: nAR_{Reg}(TK || ID_{MN} || N_{MN}+1)\end{equation*}

    View SourceRight-click on figure for MathML and additional features. where N_{MN} is a nonce generated by the MN.

  2. The nAR receives the message and sends a message (MN_{Reg-pAR}) to the pAR (previously attached AR of the MN), which has K_{MN-AR} .\begin{align*}&\hspace {-0.5pc}nAR ->pAR: MN_{Reg-pAR} (E (K_{pAR-nAR},\\&\qquad \qquad \qquad \qquad \qquad \qquad \qquad ID_{MN} || N_{MN}+1))\end{align*}

    View SourceRight-click on figure for MathML and additional features.

  3. The pAR sends the message (MN_{RegRes}) back to the nAR by adding the information about the time for which the ticket is valid and K_{TK} . The pAR encrypts this using the key it shares with the nAR. \begin{align*}&\hspace {-0.5pc}pAR ->nAR: MN_{RegRes} (E (K_{pAR-nAR}, \\&\qquad \qquad \qquad \qquad \qquad \qquad \qquad ID_{MN} || TT || K_{TK}))\end{align*}

    View SourceRight-click on figure for MathML and additional features.

    The nAR decrypts the message to get the ticket using the key it shares with the pAR. Once, it gets K_{TK} , it decrypts TK and extracts K_{MN-AR} . The flow of the messages is shown in Figure 6.

FIGURE 6. - Ticket collection from a previous AR.
FIGURE 6.

Ticket collection from a previous AR.

In this section, we have proposed a protocol which makes the proposed location management secure. We have illustrated how an MN interacts with an AR and how a ticket is generated by the AS for a user session. We have also illustrated how a ticket can be reused to reduce authentication latency. In the next section, we evaluate the performance of TALM.

SECTION IV.

Performance Evaluation

In this section, we compare TALM with TAP-TLS. The EAP-TLS based authentication performs EAP exchange between an MN and its AS; there is no concept of ticket reuse in EAP-TLS. Typically a successful TAP-TLS authentication has four steps of authentication process [35]. For the authentication related performance metrics, the simulation program is written in C++ and the simulation time is one year. We also calculate the average LQ processing time using the analytical model. The performance metrics are listed below:

  1. Authentication latency (L_{auth} ): Authentication latency is the latency to create a ticket (by an MN to authenticate itself to the AR for the first time), or renew a ticket when it is expired, or regain a ticket (from previous AR) in case of an IP handover. IP handover occurs when an MN changes its point of network access. The average authentication latency is calculated by dividing the cumulative authentication latency over a period of time by the total number of location update messages in that time period.

  2. Number of authentication messages per location update message (N_{auth} ): The number of authentication messages (requiring TALM protocol steps) in a time period is the number of times an MN authenticates itself to an AR in cases of ticket creation, ticket renewal, and ticket collection (from previous AR) in that time period. The number of authentication messages per location update message is calculated by dividing the total number of authentications (performed by an MN) by the total number of location update messages (sent by an MN) within a time period.

  3. Average LQ processing time (\Theta ): It is the average response time of an LQ.

A. Calculation of Authentication Latency for TALM

Let nhops be the number of hops between the AR and the AS, T_{MN-AR} be the message transmission delay on one hop, T_{AR-AS} be the message transmission delay from the AR to the AS, and T_{MN-AS} be the message transmission delay from the MN to the AS.

We use the same parameter settings as defined in [35]. We select the value of nhops in the interval [5], [9], T_{MN-AR} = 20\,\,ms , the velocity of an MN is taken in the interval [{10, 40}] m/s , and the radius of the AR-area for an MN in the interval [{100, 200}] m .

There can be {n} hops between an AR and an AS. So, the message transmission delay from the AR to the AS is T_{AR-AS} = nhops \times T_{MN-AR} .

For MN to AS message transmission, the delay is divided into two parts. First, when a message is sent by an MN to the AR and second, when the message is sent to the AS from an AR. This transmission delay is T_{MN-AS} = T_{MN-AR} + T_{AR-AS} = 20\,\,ms + (nhops \times T_{MN-AR}) .

Following is the order of messages for a ticket creation:

  1. MN -> AR; 1\,\,hop, 0.02s

  2. AR -> AS; n\,\,hops, n\times 0.02s

  3. AS -> AR; n\,\,hops, n\times 0.02s

  4. AR -> MN; 1\,\,hop,0.02s

  5. MN -> AR; 1\,\,hop, 0.02s

As the message transmission delay per hop is 0.02s , the number of hops between an MN and the AR is 1, and the number of hops between an AR and the AS is nhops so, the time for the complete authentication process = T (MN -> AR) + T (AR -> AS) + T (AS -> AR) + T (AR -> MN) + T (MN -> AR) = 0.02 + (nhops\times 0.02) + (nhops\times 0.02) + 0.02 + 0.02\text{s} .

Following is the order of messages for a ticket creation:

  1. MN -> nAR; 1\,\,hop, 0.02s

  2. nAR -> pAR; 1\,\,hop, 0.02s

  3. pAR -> nAR; 1\,\,hop, 0.02s

The ticket collection time (from the previous AR) = T (MN -> nAR) + T (nAR -> pAR) + T (pAR -> nAR) = 0.02 + 0.02 + 0.02\text{s} .

B. Calculation of Authentication Latency for TAP-TLS

The initial authentication delay is the authentication delay when an MN creates or renews (on its expiry) a ticket. As calculated in [35], it is 3T_{MN-AR} + T_{AR-AS} + T(m, T_{MN-AS}) , where T_{MN-AR} is the transmission delay between an MN and an AR , T_{AR-AS} is the transmission delay between an AR and the AS and T (m, T_{MN-AS}) is a function of T with m=4 , and the transmission delay between an MN and the AS is T_{MN-AR} + T_{AR-AS} .

As calculated in [35], the handover authentication delay in EAP-TLS = L_{l2} + initial authentication delay + D_{SA} + D_{RS} + D_{REG} + D_{P_{LMA}} , where L_{l2} = 0.04535 , D_{SA}=4T_{MN-AR} , D_{RS} is the transmission delay between an MN and an AR, D_{REG}=2T_{AR-LMA} , and D_{P_{LMA}} = T_{AR-AS}+ T_{MN-AR} .

C. Calculation of the Average LQ Processing Time

Our choice of the parameter settings are comparable in magnitude with the ones defined in [11], [12], and [35]. We select \lambda _{LSQ} in the interval \left [{\frac {5}{3600},\frac {50}{3600}}\right] , \lambda _{LUQ}=\frac {1}{3600} , N_{MN}=30\times 10^{6} , N_{AN} in the interval \left [{30,3\times 10^{7}}\right] , R_{delay}=20\,\,ms , and N_{hops} in the interval [5, 10].

In order to compute the values of \mu _{i} and \mu _{f} , we implement an LR (that is maintained on an AN and is part of the DHT) as an in-memory database (IMDB) as well as the finger-table (also in the memory) of the AN for the DHT overlay routing. Main memory databases provides quicker access than the disk-optimized databases because a disk access is slower than a memory access. Accessing data in-memory eliminates the seek time when querying the data, which, consequently results in faster and more predictable performance than disk [37]. Also, the main memory sizes have grown big, so implementing an LR as an IMDB has become realistic.

The implementation is done on a standard hardware — Intel Core i3 CPU M 390 with clock speed 2.67~GHz and 4~GB main memory — and run on Linux OS. By taking the average of 100,000 measurements, \mu _{i}=2\times 10^{-6} and \mu _{f}=11\times 10^{-6} . The dominant part of the average LQ processing (response) time is the standard routing delay in Internet. It is due to the in-memory processing of the LR and the finger-table of an AN. In the next section, we take \lambda _{LSQ} , N_{AN} , and N_{hops} as variable parameters and show the results for \Theta besides showing the results for the average authentication latency and the average number of authentication messages per location update in TALM.

SECTION V.

Results and Discussion

We now present the network topology, the parameter settings, the results of the simulations, and our discussion of the results.

A wrapped-around cellular network topology of 19 hexagonal ANs is used in the simulations as shown in Figure 7.

FIGURE 7. - Cellular network topology.
FIGURE 7.

Cellular network topology.

For the simulations, we choose the AN-Area residence time \alpha to be an exponentially distributed random variable as also chosen in [12] and [38]–​[40]. The results of the seven scenarios shown in Table 3 are given and discussed in the following sections.

TABLE 3 Scenarios and Parameter Settings
Table 3- 
Scenarios and Parameter Settings

A. Average Authentication Latency

We compare the average authentication latency of TALM with that of EAP-TLS. The variable parameter of this experiment is nhops. The results of this experiment are shown in Figure 8. With the increase in nhops, the average authentication latency for both the protocols increases. The results show that TALM performs better than TAP-TLS. We calculate the simulation results of TALM with 95% confidence interval as shown in Figure 8. The percentage reduction in authentication latency by TALM is nearly equal to 99%. This is mainly due to the reuse of the authentication ticket in TALM.

FIGURE 8. - 
$L_{auth}$
 vs. 
$nhops$
.
FIGURE 8.

L_{auth} vs. nhops .

B. Average Number of Authentication Messages

Figure 9 shows the average number of authentication messages per location update as the lifetime of a ticket varies. With the increase in the lifetime of the ticket, the average number of authentication messages per location update decreases. For bigger lifetime of a ticket, an MN faces less number of authentication ticket expiries than the number of the expiries when the lifetime is less.

FIGURE 9. - 
$N_{auth}$
 vs. Ticket Lifetime.
FIGURE 9.

N_{auth} vs. Ticket Lifetime.

Figure 10 shows the effect on average number of authentication messages per location update when the velocity of an MN is varied. We can see that the average number of authentication messages increases with the increase in the velocity. This is due to the reason that with the increase in velocity, the MN experiences more IP handovers. Hence, the MN performs more handover authentications and it results in the increase of the average number of authentication messages.

FIGURE 10. - 
$N_{auth}$
 vs. Velocity.
FIGURE 10.

N_{auth} vs. Velocity.

Figure 11 shows the effect on average number of authentication messages per location update when the area of an AN is varied. We observe that the average number of authentication messages decreases with the increase in the AN-Area. This is due to the reason that with the increase in the AN-Area, an MN experiences less IP handovers. Hence, the MN performs less number of handover authentications and it results in the decrease of the average number of authentication messages.

FIGURE 11. - 
$N_{auth}$
 vs. AN-Area.
FIGURE 11.

N_{auth} vs. AN-Area.

C. Average LQ Processing Time

We vary \lambda _{LSQ} in the interval \left [{\frac {5}{3600},\frac {50}{3600}}\right] , choose N_{hops}=7 , N_{AN}=30 and calculate \Theta using Equation (6). The results are shown in Figure 12. The results show that there is only a little increase in \Theta as we increase \lambda _{LSQ} but keep N_{hops} and N_{AN} constant. It is due to the scalability of the proposed distributed location management scheme using the Chord circle.

FIGURE 12. - 
$\Theta $
 vs. 
$\lambda _{LSQ}$
.
FIGURE 12.

\Theta vs. \lambda _{LSQ} .

Then, we vary N_{hops} in the interval \left [{5,10}\right] , choose \lambda _{LSQ}=0.0014 , N_{AN}=30 and calculate \Theta using Equation (6). The results are shown in Figure 13. The results show that \Theta is a linear function of N_{hops} , when \lambda _{LSQ} and N_{AN} are kept constant.

FIGURE 13. - 
$\Theta $
 vs. 
$N_{hops}$
.
FIGURE 13.

\Theta vs. N_{hops} .

Last but not the least, we vary N_{AN} in the interval \left [{30,3\times 10^{7}}\right] , choose \lambda _{LSQ}=0.0014 , N_{hops}=7 and calculate \Theta using Equation (6). The results are shown in Figure 14. The results show that \Theta is a linear function of N_{AN} , when \lambda _{LSQ} and N_{hops} are kept constant.

FIGURE 14. - 
$\Theta $
 vs. 
$N_{AN}$
.
FIGURE 14.

\Theta vs. N_{AN} .

SECTION VI.

Conclusion

In this paper, we have proposed a new mechanism for secure and fault-tolerant operations for DMM. The proposed mechanism utilizes a distributed hash table of access nodes for distributed location management. It is mapping the network prefixes of the access nodes and the location binding information of the MNs on a Chord circle. A replication strategy has been described for the proposed mechanism. The distribution of location server is important as it addresses the limitations and weaknesses of a central location server like single point of failure and attack, traffic bottleneck resulting in long delays in the additions and update of location binding information of MNs, and long response times of location queries that are sent by the CNs. The analytical model that has been used to calculate the average processing (response) time of a location query can help in designing and planning the processing requirements on an AN in future 5G networks.

The proposed mechanism also adopted a ticket-reuse approach called TALM for improving authentication performance while providing secure authentication of MNs. It provides security to the location additions and updates on the wireless link between an MN and its AR. The work is important as it reduces the latency of the authentication process and the number of authentication messages that are sent for a location update message. The results demonstrate significant performance gain of the proposed protocol as compared to a non-ticket based existing wireless authentication protocol, TAP-TLS. In order to replace all centralized components with their distributed counterparts for future 5G networks, it is desirable to have a distributed authentication service for secure handovers.

ACKNOWLEDGEMENTS

The authors are thankful to Prof. Renato Lo Cigno (DISI, University of Trento, Italy) for his guidance related to the analytical modeling part of the manuscript.

Usage
Select a Year
2025

View as

Total usage sinceMar 2018:1,286
01234JanFebMarAprMayJunJulAugSepOctNovDec310000000000
Year Total:4
Data is updated monthly. Usage includes PDF downloads and HTML views.

References

References is not available for this document.