Print Email Download

Paid Writing Services

More Free Content

Get Your Own Essay

Order Now

Instant Price

Search for an Essay


IP address

Abstract

IP address has become a key feature in the current internet architecture. However, the basic design of Internet Protocol stack is based on architecture shaped decades ago, when internet was a static network [20]. Fixed IP addresses did not caused any problems until communication devices became mobile, because when a Mobile Node (MN) in an active association with another node, changes its Point of Attachment (PoA) its current IP address changes and hence its active session terminates. Different techniques are implemented to support mobility using Internet Protocol Stack. Mobile IP supports mobility at network layer, mSCTP supports mobility at transport layer, and SIP works at application layer. Although the question that which layer is suitable for mobility is still an open issue.

Stream Control Transmission Protocols (SCTP) exploits its multihoming feature along with Dynamic Address Reconfiguration (DAR), to provide a non-delayed handover solution with higher security and almost negligible packet losses. However, mSCTP requires location management to provide a complete and reliable handover solution. Location management in IP based handovers provides an IP address of the mobile node. This requirement can be fulfilled by using Chord, which along with DHT can provide the required name to IP mapping. Chord is DHT lookup algorithm, which can efficiently retrieve the key-value pair by mapping the key onto a node that contains the required value.

We proposed a decentralized mobility framework for IP based handovers that does not require any evolutionary technology changes and can be deployed without any complexity. Suitability of our framework is tested by preliminary analysis of Chord lookup efficiency and SCTP handover procedure. Our mobility framework exploits the multihoming feature of SCTP to provide handoff management and efficient key-value mapping of DHT Chord to provide the necessary location management. Efficient lookup algorithm, high scalability, flexible naming, authorization support, and no central point of failure make DHT Chord an ideal candidate for location management. Backed by mSCTP multihoming feature and DAR extension, Chord can efficiently provide the required location information and support non-delayed handover procedures. Besides technical advantages, end users will gain added functionalities and more flexibility from this mobility framework.

Chapter 1 Introduction

Introduction:

Internet Protocol Suite has become an essential technology in both telecommunication and computer networks, because of its layered architecture. However the basic design of Internet Protocol stack was based on the assumption that, "all nodes have fixed IP addresses" [20]. This concept of fixed IP addresses did not caused any problem until communication devices became mobile. Since then IP mobility is one of the major issues, which needs to be resolved for wireless IP services, so that the end users can obtain continuous services in anytime and anywhere.

To conceive the full potential of ubiquitous mobile computing, a mobile device must be able to roam seamlessly across different networks without any interruption in the services it is providing or receiving. Two main factors that incorporate seamless mobility across independent networks are Location Management and Handover Management. Location management is a Mobile Node's (MN) location update process, which enables a Correspondent Node (CN) to locate the MN current location, in order to initiate and establish a communication process. Handover Management refers to the ability of maintaining any active sessions irrespective of the movement of a MN between independent networks.

The performance of ubiquitous mobile computing mainly depends on efficiency of the handoff mechanisms it relies on. Although Mobile IP (MIP) and its extensions i.e. (MIPv4) and (MIPv6), have been proposed and standardized as network layer mobility solutions. Their handover mechanisms however bring an unavoidable tunneling overhead, transmission throughput and transport layer blocking. Besides, to accommodate MIP, modifications are required in the existing heterogeneous network architecture [8]. Mobile Stream Control Transmission Protocol (mSCTP) is another solution, which provides seamless handovers at Transport layer utilizing its multihoming feature. Unlike MIP, it does not rely on additional network components resulting in reduced handover latency and a secure and efficient handoff process. However mSCTP does not provide any location management therefore, to exploit the full potential of its handover capabilities, it has to work along with some location management scheme, to provide the necessary location information.

IP address can provide location information about any internet-connected device. It can answer question like who, where and how about any device in the network architecture [21]. Various location management schemes, based on name to IP mapping, are proposed to increase the efficiency of lookup times [10] [22] [23] [24]. However all schemes rely on fixed and inflexible set of location servers. Besides inflexibility another drawback linked with these systems is, a centralized database, which can introduce problems like single point of failure, dependence on additional network components and lack of reliability. In this thesis, we propose a decentralized and distributed architecture for location management that relies on P2P algorithm: Chord.

Peer to peer systems provides a long list of features which include efficient data location, redundant storage, authentication, search, high performance lookups and distributed content placement and discovery via Distributes Hash Tables and its algorithms [13]. DHT algorithms like CHORD, CAN and TAPESTRY are widely used to provide content discovery at distributed and decentralized level. We have used Chord because of its simplicity and acceptance across the research community. Chord is an efficient distributed lookup service based on consistent hashing which provides support for only one operation: given a key and it efficiently maps the key onto a node [12]. This feature of Chord can be exploited to provide the necessary location management, by creating an identifier-locator set for each participating node, such that key represents the identifier and locator presents the value in the key-value pair.

In this thesis, we propose a mobility framework for IP networking and roaming architecture that does not require any evolutionary technology changes and can be deployed without any unnecessary complexity. Our mobility framework utilizes mSCTP and DHT Chord, where mSCTP being a transport layer solution provides the necessary handover management, and DHT Chord used by application layer provides the required location management to go along with mSCTP. We exploit the multihoming feature of mSCTP and key-value mapping of Chord to enable a MN, to roam seamlessly across independent networks without any interruption in the services it is using. Performance analysis of Chord using Overlay Weaver shows, that Chord can not only efficiently locate a key value pair, but can also perform its lookup operation abruptly with a very little effect from the increasing network size and instability of the network. Chord along with DHT can provide the current location by traditional name to IP mapping, such that Key represents the name Unique Identifier (UID) and value giving the IP address referred to as value Temporary Locator (TL). Chord via its efficient and abrupt lookup mechanism can locate the Base Node keeping information about MN's IP address, and provide it to the querying CN node. Once the MN is located, CN initiates the session while handoff management is provided by mSCTP using its multihoming feature and DAR extension.

Motivation and Contribution:

Vertical handover solutions can be classified in different ways. One approach is to characterize the handover solutions from the point of view they tackle the problem, i.e., from a user's or the network's point of view. User-centric, or mobile- controlled, handover solutions have the advantage of full control over the handover mechanism, whereas network-controlled handovers are usually faster in signaling. However, recent work has shown that LTE and 4G technologies will not be able to support network-controlled handovers [47] in the near future. Therefore, it is important to concentrate on user centric approach for a seamless handover solution.

mSCTP can be used to provide a quick and efficient vertical handover solution, without relying on additional network components. The multihoming feature of SCTP along with DAR extension can be used to perform vertical handovers. However mSCTP does not provide any location management. Therefore to exploit the full potential of its handover capabilities, it must be used along with some location management scheme.

Connection establishment inside the internet usually starts with a location query i.e. name to IP mapping [23]. DNS can provide the required location information, but with consequences like added routing overhead and single point of failure. An alternative to DNS lookup is DHT Chord, which can provide the traditional name to IP mapping. Name represents the key and, IP address represents the value [12] in the key-value pair of Chord. This feature of Chord is utilized to provide the necessary location management in our framework. This thesis provides the basic requirements and changes required for DHT Chord, to support location management, and its operation along with mSCTP.

Preliminary testing is conducted to analyze the performance of Chord, by observing various performance metrics like lookup latency and get results of query with nodes entering and leaving the network. Overlay Weaver is used as a test tool, which is an overlay construction toolkit with the ability to work on real networks. Detailed operation of the framework is described by explaining the following points:

To the best of our knowledge, it is a unique contribution of our thesis, that we provide the use of Chord as a location manager along with mSCTP to improve its handover over performance, in a robust, scalable and decentralized fashion. mSCTP using its multihoming feature and Chord utilizing its efficient lookup can result in a complete decentralized mobility framework.

Related Work:

In future IP based mobile networks, the effectiveness of IP based handoff solutions will determine the efficiency and reliability of the system and services it is providing. As the importance of IP-based mobility has increased, many research efforts have been made in this aspect. It this section we will briefly explain the works that has been done to improve handoff management and location management.

Many efforts have been made to determine a suitable layer for seamless mobility. Kim and koh [19] compared the performance of Mobile IP and mSCTP over Ipv6 networks. They adapted analytical approach to determine handoff latencies for both MIP and mSCTP and then backed up their observation by experiments over Linux test bed. They proved in their work that handover latency for a single homed device is greater then a multi homed. Zeadally and Siddiqui empirically compared the handover delay for for MIP, mSCTP and SIP. They showed via experiments on Linux test bed that mSCPT is performing better than both MIP and SIP in terms of handover latency and packet transmission time after handover [11]. Ferrus and Brunstrom in [7] states that transport layer handover solutions are a worth while option and deserves more attention than the current network and application layer solutions. It also covers the key challenges and scenarios in handling seamless roaming across different networks by concentration on SCTP and its multihoming feature.

Location Management along with mSCTP is still an open issue and requires alot of research in this field. Park and kim [25] found that SCTP along with SIP can achieve performance equal to UDP in terms of Quality of Service required for real-time media. They have used the multihoming feature of SCTP bind together with location and network transparency provided by SIP. Fu and Atiqquzama in [23] developed an analytical model to validate the use of DNS as location manager and study its performance in terms of internet traffic load, success rate and velocity of a mobile host. SCTP Draft has proposed the use of Mobile IP as a location manager along with mSCTP when CN is the one initiating the session.

P2P networks provide content distribution and discovery in a distributed fashion and can perform lookups in matter of ms, as shown in [12]. Yet a very little work has been done on peer to peer networks in this regard. Sethom and Afifi in [27] presents PALMA (peer to peer architecture for location management), which use tapestry to perform the necessary location management in mobile networks. However PALMA is not designed to solve mobility related problems it only locate MNs for new communication sessions. Cirani and Veltri in [28] have proposed architecture for Distributed Location Service which is composed of three major components p2p protocol, a DHT algorithm and a client protocol. Hanks and Kunzmann in [17] introduced a new concept for Next Generation Internet Based Architecture based on DHT algorithm.

Thesis Outline:

The thesis consists of 5 chapters each of which explains the following; Chapter 2: Theoretical Background provides an insight on the architecture and operation of the basic components of our mobility framework. Section 2.1 describes the architecture and some crown features of SCTP, followed by handover mechanism and operation of mSCTP in section 2.5. Last section 2.7, provides a detailed explanation providing various features and operation of Chord.

In, Chapter 3: Performance Analysis of mobile SCTP and Chord, section 3.1 we conduct a theoretical analysis of mSCTP handover latency followed by simulation study of SCTP dualhoming feature and its performance under handover operation. Section 3.2 will cover the suitability of Chord as location manager with regard to lookup latency and get results with nodes entering and leaving the network. Last section 3.3 concludes the observations made during analysis.

Chapter 4: Decentralized mobility framework: provides a detailed operation of DHT Chord as location manager. Section 4.1 covers the basic requirements like addressing scheme, and basic components for the framework. Section 4.2 covers working of the framework including node placement, content discovery, and node departure etc. later section cover the complete handover procedure with both mSCTP and DHT Chord working together. Last section encompasses open issues and challenges we encountered. Chapter 5: Conclusion and Future work, concludes the entire work along with some suggestions regarding improvements in the future work section.

Chapter 2 Theoretical Background

This chapter encompasses the basic components of our mobility framework. First section 2.1, explains the basic architecture of SCTP and some of its prominent features. mSCTP and its basic operation are explained in section 2.5, which is followed by DHT Chord in section 2.7.

Stream Control Transmission Protocol (SCTP):

Stream Control Transmission Protocol is an end-to-end, message oriented protocol that provides transportation services over the internet [1]. It is designed to eventually replace TCP and perhaps UDP [6]. SCTP offers flow control, reliability, full-duplex data transfer and ordered delivery and unordered delivery of data. However, SCTP provides other features that are currently not available in either of the workhorses of the internet that have supported it for more than 20 years. These features include multistreaming, multihoming, and four-way handshake for connection establishment, discussed in section 2.4. SCTP protocol was published by IETF as a proposed standard in 2000.

Historical Background:

In the last few years we have witnessed a great deal of convergence in IP based networks and Public Switched Telephone Networks (PSTN). It has become a common practice to use IP networks for voice communication in order to reduce the cost. However, most of the services provided by PSTN networks require SS7 signaling network support [1]. Signaling System Number 7 is a combination of telephone signaling protocols, and its main purpose is to setup and tear down telephone calls.

SS7 is all about the exchange of control information associated with call establishments on telecommunication circuits. That is the why the transport of SS7 messages has a strong requirement of timely and reliable delivery [1]. An IETF working group (SIGTRAN) was formed in 1998, to design a mechanism for transporting call control signaling reliably over the IP networks. SIGTRAN's goal was to create an IP complement to the SS7 network. Use of TCP during SIGTRAN's work conferred the following problems [1] [6].

Considering these problems, SIGTRAN began work over a new transport protocol to carry its call control signals over the Internet. Simultaneously, the IETF transport Area Directors (Scott Bradner and Vern Paxson) recognized the value of solving these problems for a wider audience. They expanded the scope of the work from a small, dedicated protocol for a specific task (SIGTRAN) to a general-purpose transport protocol that other applications could use as well [6]. Within this larger scope, SCTP was born.

SCTP Structure:

SCTP transmit data in the form messages, which contains one or more SCTP packets. An SCTP packet is composed of 12 bytes common header, and chunks that can be either DATA chunks or CONTROL chunks. Single SCTP packet can carry multiple chunks up to the PATH-MTU size [3]. Figure 2.1 shows the common header for an SCTP packet.

SCTP Features:

SCTP and TCP look very similar at first glance; however, SCTP supports more features as compared to TCP and UDP. Table 2.1 shows a comparison of features and services of SCTP, TCP, and UDP.

Multihoming:

Multihoming is the ability to support multiple IP addresses/interfaces during an association for a single endpoint [5]. In a single-homed connection, like that of TCP, which binds a single point of attachment at either ends can isolate the endpoint from the entire network in case of a single failure. SCTP on the other hand can bind multiple points of attachments during an association, which makes SCTP highly fault tolerant [1].

A host with multihoming feature can communicate with other nodes using a single interface with SCTP address. This address is known is a Primary Address, and is used to communicate data chunks across the network as shown in Figure 2.2. Alternate address or addresses are available in case of retransmission known as Secondary address. If the primary address fails to respond after multiple tries, Secondary Address is used as a primary path for communication of data chunks as long as the primary path is recovered [4]. Heartbeat chunks are continuously sent to check availability of both primary and secondary paths.

SCTP multihoming feature can provide path redundancy. This ability can interrupt data transfer services in order to change the path with in an association to achieve continuity of transmission [4] [48]. This feature of SCTP makes it an ideal candidate to perform handovers, for which an extension of SCTP known as mobile SCTP is used which utilizes the multihoming feature to perform handovers without any additional components.

Multistreaming:

The name Stream Control Transmission protocol is derived from its multistreaming feature [1]. Multistreaming allows data partition into multiple streams, which are capable of independent delivery as shown in the Figure 2.3. This feature enables continuous flow of data such that, a message loss in one stream will not hinder the flow of data in other parallel streams [4]. This property of SCTP can prevent HOL (Head of Line blocking), caused by queuing of later incoming packets into the receiver buffer when an earlier incoming packet is lost.

SCTP accomplishes its multistreaming by creating independence between data delivery and data transmission [3]. Each message is given a Stream ID, which is used to determine the sequence of delivery of the received messages. This can help the receiver to determine the sequence of the incoming packets and check if any packet is lost in the corresponding stream. In case of lost messages, receiver buffers the incoming messages only in the affected stream and continues to receive messages from the remaining unaffected streams.

Association Setup:

SCTP provides a secure way of connection establishment, which can prevent DOS (Denial of Service) attacks caused by flooding the target by continuous connection setup requests and making it unavailable to its intended users. SCTP utilizes a four-way handshake in which the server does not directly assign resources to the connecting body [3]. Following steps describe a four-way handshake mechanism as show in Figure 2.4.

Mobile SCTP:

SCTP multihoming feature allows a MN to bind multiple IP addresses to its interfaces. This feature of SCTP makes it able to perform vertical handover processes. However the current architecture of SCTP, explained in section 2.4, does not support vertical handover because of the following reasons [7].

Dynamic Address Reconfiguration (DAR):

SCTP can extend to a mobility-enabled transport protocol with the help of DAR [9]. However, DAR can only be used as a mobility enabling feature, not a mobility solution as a whole [7]. The DAR extension allows SCTP to dynamically add or delete IP address and request for a primary path change during an active SCTP association with the help of three parameters: add-IP, delete-IP and set-primary-IP. The DAR extension presents two new chunks that can reliably transfer the control information regarding changes in the address [9]. These are Address Configuration chunks (ASCONF) and Address Configuration Acknowledgment chunks (ASCONF-ACK). SCTP with DAR extensions is referred to as Mobile SCTP (mSCTP), which can be used to perform vertical handovers.

Add Delete and Set Primary IP parameters:

These parameters defined in DAR extension allow mSCTP to perform seamless handovers at transport layer. Add IP Address (add-IP) is an address configuration parameter that informs the other end to add a new IP address in its active association [9].

Figure 2.5 shows the message format of add-IP ASCONF chunk. The type field value 0xC001 identifies the add-IP parameter. Length field in this message is variable as the address parameter can carry multiple IP addresses. Delete IP address (delete-IP) informs the node on the other end to remove an IP address from the active association. It is represented by type 0xC002, length field in this message chunk is variable like that of add-IP message. Set Primary Address (set-primary-IP) informs node on the other end to change the IP address of the destination to the designated IP address. Set-primary-IP message is recognized by type 0xC004.

Address configuration change chunk (ASCONF):

ASCONF communicates configuration change requests to the end-points. It carries add-IP, delete-IP and set primary-IP parameters. The address information carried in the ASCONF Chunk uses the form of a Type- Length-Value (TLV) for all variable parameters. ASCONF chunk can be bundled with data chunks in an active SCTP association. This chunk must be sent in an authenticated way. In case of unauthenticated chunk, SCTP-AUTH silently discards it.

ASCONF chunk is recognized by type value, 0xC1 as shown in the Figure 2.6. The flag field is not used and is set to 0. Length field represents the length of the chunks. Serial number is used to distinguish an ASCONF chunks from other ASCONF chunks. Address parameter is set to sender address.

Address Configuration ACK Chunk (ASCONF-ACK):

The receiver of an ASCONF chunk, to acknowledge its reception and authenticity, uses it. Figure 2.6 shows the format of ASCONF-ACK chunk in which the type field is set to 0x80, which is used to represent ASCONF-ACK chunk. Serial number contains the serial number of the received ASCONF chunk.

mSCTP Handover Procedure:

Handover process explained in this section will undertakes the handover scenario when a MN triggers the handover process, and, as the MN knows about its movement and the signal strength from the old and new AR, so there is no need for location management [10]. Figure 2.7 shows the handover process in which a Mobile Node MN initiates an association with the Correspondent Node CN, and then moves from one domain to another having different IP addresses. The handover process can be explained under the following headings.

Session initiation:

Mobile Node (MN) initiates an SCTP association with Correspondent Node (MN). It is assumed that MN attains an IP address 192.168.2.2 with the help of DHCP server and initiates a session with CN having IP 192.168.4.2. CN in this case is a single homed device and the only address at it interface is 192.168.4.2. MN on the other hand is a multihoming device but is in single homing state at the moment with the IP address 192.168.2.2 set to its primary IP address.

Obtaining an IP address in new Network:

Let us assume that MN moves from network A to network B. We also assume that MN can obtain a new IP address from location B by contacting its DHCP server. We assume that the new IP obtained at network B is 192.168.3.2. MN signals the newly attained IP address to its mSCTP stack, which is added to the active session at MN. MN now needs to inform CN of the newly attained IP address, so that CN can add it to the on-going association and send packets using the new IP address.

Adding new IP address to association:

MN sends an ADDIP chunk to CN, to inform CN of the newly attained IP address i.e. 192.168.3.2 and add it in the current SCTP association. CN replies with an ASCONF ACK chunk and confirms the incorporation of the new IP address into the association. CN however will send a message using the old IP address, as the primary change is not yet requested. However MN is now in the dual homing state, and the data sent from MN towards CN can be sent on any of the two interfaces.

Changing the Primary Address:

As MN continues to move towards network B, network A signal strength will decrease and MN will have to change its primary address for communication. MN however needs to have some appropriate rule to switch from one network interface to anther while roaming between different networks. These rules according to [10] [7] are:

  1. When a new IP address is detected.
  2. By utilizing indication from the underlying layer.
  3. Indication from the upper layer
  4. Feedback from bandwidth estimation techniques
  5. Use of IEEE 802.21 Media Independent Handover (MIH) to fetch the network information.

Using one of the rules mentioned above, MN would switch its primary address and notify CN by sending and ASCONF chunk with set primary address parameter set to the primary address it require. CN on reception of this chunk will change the primary address to 192.168.3.2, and use 192.168.2.2 as secondary address.

Deletion of old IP address:

MN needs to remove the old IP address i.e. 192.169.2.2 from SCTP association after it completely moves into network B. ASCONF chunks with delete IP parameters can discard the old IP address from the active association. CN on reception of this chunk will remove the old and inactive IP address i.e. 192.168.2.2 from the association.

mSCTP Limitations:

mSCTP being an efficient and abrupt transport layer handover solution, still exists at a draft level and requires solution for many issues like:

Media Independent Handover (MIH):

MIH, also know as IEEE 802.21 can be utilized to optimize the handover process for mSCTP [44]. MIH can improve mSCTP seamless handover between homogenous and heterogeneous networks by providing layer-2 trigger information. This information can help mSCTP to perform interface switching during the handoff process with a minimum delay and complexity [45]. However MIH only provides information to allow handover between different networks, it does not perform any handovers by itself.

MIH provides three services to optimize the handover process [44]. Event Services provides information about the events taking place across the link layer. These events include parameters like Link up, Link down, link going down etc. Command services issues commands, which enable higher layers to control lower layer like physical layer, link layer. Information Services are utilized to discover and obtain network information of the MN, which can facilitate the handover process.

MIH main advantage is to detect the changes taking place in the network state. These changes include link up, link down and link going down [44]. This information can be provided by observing the signal strength of the network MN currently resides in. It can then be used by the handover decision components to optimize the switch over process and decide when the association path should be changed during the mSCTP handover process.

Interface switchover can be optimized by using MIH. However, mSCTP still needs some additional components to perform location management. This brings us to the problem of Location Management in mSCTP, which is provided by DHT Chord in our framework. To understand the operation of the framework, it is necessary to study the performance of CHORD in details.

Peer-to-Peer Systems:

Peer-to-Peer systems and applications are distributed systems with no hierarchical organization and centralized control. Systems in a certain network are normally categorized as servers and clients according to some specific rules. However, in p2p systems this categorization is difficult because a typical server or client might have a server or client relation with other nodes. In a file sharing application like that of bit torrent, a node will act as a client by getting some files from other peers, however it will also act as a server at that time by sharing part of a file with the neighboring peers [13]. So it is safe to say that in a pure peer to peer system all nodes provides the same services, in fact the main characteristics of these systems is the similarity of all participating nodes.

First Generation P2P Systems:

This system employs a centralized server or flooding based mechanisms to locate desired data [16]. This system can be divided in two parts.

Centralized Systems:

As the name shows, these systems depend on a centralized system for content discovery. When a node wants to locate an item, it forwards its query to the centralized server. Such systems are fast and reliable however, they suffer from drawbacks like single point of failure and giant communication traffic on storage systems [16].

Napster is an example of such systems; that uses a central server that directs traffic between registered users. When a user submits a query for a song, the central server creates a list of users who are currently connected to Napster with the queried song in their collection and forward it to the querying user.

Decentralized Systems:

As the name suggests, such systems doesn't use a central server; however, most of the systems had no deterministic information of data location [16]. Main technique used to locate a data item was broadcasting i.e. when a node receives a request for a key; it first attempts to retrieve the file associated with that key locally. If this attempt fails it forwards the request to other neighboring nodes, and this process continues until the desired data item is found and reported.

Gnutella and Freenet are examples of such peer-to-peer systems. Disadvantages of these systems are no guarantee of reliable content location information, flooding mechanism for resource discovery and scalability.

Second Generation P2P systems (DHT):

Distributed Hash Table can be termed as second-generation peer-to-peer systems [16], as they have introduced scalability, fault-tolerance and load balance to p2p systems along with decentralized content discovery [17]. As size of the p2p networks increase, the amount of shared resources across the network also increases, therefore finding a certain resource across tens and thousands of nodes in a scalable manner is a real design challenge. Early p2p systems like Napster and Gnutella provided these functionalities but at the cost of higher network traffic, minimum guarantees and single point of failures [13].

DHT is a distributed data structure whose main function is to hold the key-value pair in a completely distributed manner and any participating peer in the overlay network can retrieve the value associated with the given key [13]. DHT uses consistent hashing to map the responsible node for a key-value pair. Along with efficient mapping of a key-value pair to nodes, DHT also has the ability to isolate the network changes to a small part of it thus limiting the overhead and bandwidth consumption during networks and resources updates [13].

DHT is an abstract idea that helps us to achieve complete independence from a central lookup entity and tolerance to changes in the network [16]. Different algorithms have been designed to implement and refine DHT idea. CAN, PASTRY, TAPSTERY, CHORD are the most popular implementations of DHT. We will use CHORD as a basic look up mechanism for our mobility framework due to simplicity, availability, and acceptance in the research community.

Chord:

Chord is an efficient distributed lookup service based on consistent hashing which provides support for only one operation: given a key and it efficiently maps the key onto a node [12]. At its heart chord provides a fast and efficient computation of the hash function by mapping keys onto the nodes [13]. Chord forms a one dimensional identifier circle which ranges from 0 to , where m is the number of bits in the identifier for SHA-1 (160 bits). Each nodes and keys are assigned an m-bit identifier. Node identifier is produced by hashing the node's IP address and the port using it, whereas 160-bit key identifier is produced by hashing the key [12]. Identifiers are assigned in such a way that the probability of two nodes having same hashed identifiers is negligible.

Chord protocol simplifies the design of peer-to-peer systems by addressing to the following problems [12].

Load Balance:

Chord has the ability to spread the keys evenly over the participating nodes, which provides a degree of natural load balance. Decentralization:

No node in a Chord overlay network is more important than any other participating node. This ability of chord makes the system more robust and failure tolerant. Scalability:

The number of messages required in a chord lookup increases as the log of the number of nodes as chord lookup is based on 0(Log N) messages. So scalability can be achieved without any complex parameter tuning.

Availability:

Chord automatically adjusts its finger tables whenever a node joins or leaves the network. This makes it able to provide the key/value pair every time a query is made despite of failures in the underlying network.

Flexible naming:

Chord puts no constraints on the structure of keys it lookup i.e. the key space provided by chord is flat.

Components:

To explain the operation of chord, it is necessary to explain the following parameters.

Finger table:

A node in the overlay network uses this list to send messages to other peers [18]. A finger table entry contains both the hashed chord identifier and IP address of the relevant node. First entry in the finger table is also referred to as successor of a node n on the identifier circle.

Successor node:

It is a peer immediately after a peer or key on the identifier circle. As shown in the Figure 2.8, successor of identifier 1, 2 and 4 is node N7. It is the node that immediately follows a node n or a key K, whose identifier value is equal to or follows k in the identifier space [12].

Predecessor node:

Predecessor node refers to a peer directly before a participating peer on the identifier circle.

Key-Node Mapping:

When a node in chord overlay network wants something, it simply hashes its identifier i.e. key and search for a node with that key. A total of 0(Log N) messages are required to locate an object, where N is the number of nodes in the overlay network [12]. Figure 2.9 shows, key to node mapping process in which node N7 receives a request for key K27 from node X residing outside the network. Node N7 on receiving the query checks if it has the key or not. With zero response it will use the mapping function to check which of its neighbors are close to the key-value storing location [13]. It will use its finger table to find the interval containing key K27.

Finger table of node N7 shows that key K27 is located in the interval [23, 7], which is related to the successor node N26. Therefore, it will forward the request to node N26. Node N26 will use the map function to check how close it is to the key place, and will search its finger table for the interval containing key 27. Node 26 will find that key 27 is located in interval [27, 30], with successor 30. Now node 26 will forward the request to node 30 along with an IP address of the request originator. Node 30 finally finds the requested key-value pair for key 27, and initiates associations with node X.

Key-Value Insertion:

Chord uses DHT to store a key-value pair at a nodes to which the key maps [15]. Inserting a key-value pair in required DHT is analogous to finding the key value pair in the identifier space. When a node receives a request with the hashed key identifier, it will use the map function to check how close it is to the key place on the identifier circle as shown in fig where N0 wants to put a value in K27. It will follow the same steps as in previous section to reach N30.

When the query reaches N30, it will check how close it is to the hashed key place in identifier space, and will understand that it is the best place to store the key [2]. N30 will send its IP address to node N0, which will use this IP address to insert the value in node N30. However, additional RPCs will be required to route the values from node N0 towards node N30 DHT [14].

Node Placement:

In dynamic networks, nodes can leave and join the network any time. Therefore chord must be able to locate the key efficiently even in highly unstable conditions. To achieve this goal, it has to maintain the following two invariants [12]

  1. Successors list in each node is correctly maintained.
  2. For every key k, node successor (k) is responsible for k.

Node entering the overlay network, simply hashes its IP address and port number to create a Node-ID, The hashed Node-ID using SHA-1 function looks like 3752ac6235a888e2b938f9c2f77ef7236d261f39= h (192.168.2.2:3997). It then sends a REGISTER message to any bootstrap node in the overlay network. Bootstrap node will query for a, nearest to the hashed Node-ID of the joining node. Node entering the network will repeat this process until it finds the node currently responsible or near the space it will occupy. After joining the overlay network, it exchanges additional REGISTER messages with the admitting/successor node. This allows the joining node to learn about other neighboring nodes in the network and obtain information from the neighboring nodes about resources the joining node will be responsible for [18].

Existing nodes in the network must also update their finger tables to reflect the insertion of a new node. Each node in chord ring maintains a predecessor pointer to simplify the join/ leave process [12]. Predecessor pointer simply contains a Chord identifier and IP address of the node that is its immediate predecessor. When a node n joins the network, it has to know about an existing node say n'. Figure 2.10 shows an example of node insertion in Chord ring, where N16 wants to joins the network.

When N16 wants to join the network, it will have to locate a node inside the chord ring. After locating N0, using any bootstrap method, node N16 will send a join request to N0, in other words it will ask node N0 to locate its fingers and predecessors. Node N0 will use the find_successor algorithm in order to obtain the successors [12]. The initialized finger table is sent back to node N16, as a response message. Node N16 after joining the overlay network then sends an update request to inform all nodes, whose finger tables include 16. As a result, the concerned nodes will update their respective finger tables. In this case, node N7 and N 12 finger tables are updated as shown in the figure.

The last operation that has to be performed when a node enter or leave the overlay network, is to move responsibility of the keys to the newly entered nodes. This can be achieved by notifying the higher-level software, so that it can transfer keys and values to a node n that is now responsible for them [12].

Basic Location Management Application:

Chord is a basic lookup system that can be used as a building block in larger protocols that implements, for example a data authentication, file distribution system, redundant storage, and efficient data location [15]. However, such services are not implemented directly by chord; it simply provides a high performance, flexible lookup primitive upon which such services can be efficiently layered. Chord can also be used to provide IP address to host name mapping like that of DNS but chord is not a storage system, it only associate keys with nodes responsible for them rather than giving the values linked with those keys [13].

With the help of additional layers like that of DHT, which can translate high level names into chord identifiers, chord can be used as a powerful lookup service for name to IP mapping [12], as chord utilizes DHT to store key-value pair at nodes to which the key maps [15]. By layering additional features on top of chord, it can gain robustness and scalability, therefore a useful extension to the chord lookup system is DHT as shown in the figure, which can provide the required values for any desired key and hence increase its efficiency and performance of chord as location manager.

Figure 2.11 shows a simple Location Management Application that can provide values, i.e. IP address, for any user associated with a Chord key queried by CN using the following commands.

Put (key, value): This is used to store a key value pair into DHT using chord to find the successor node of the hashed key on the identifier circle.

Get (value): This can be used to get the value from DHT, which is associated with the given key. Chord is used to locate the node on the identifier circle with the requested key-value pair.

Remove (Key): Remove (Key) as the name suggest is used to remove the key and its value from its responsible node.

LM application interacts with Chord in two main ways. First, it provides a lookup (Key) algorithm via Get and Put commands, that yields IP address of nodes responsible for the key and hence the value related with that key. Second, it notifies application of any changes in the set of keys that the node is responsible for [13]. This allows corresponding application to move the values to their new homes i.e. update the responsible DHT's whenever a node enters or leaves the network. Additional RPC interface is required to move the values and data to and from the responsible nodes.

Chapter 3 Performance Analysis of mSCTP and Chord

We discussed Stream Control Transmission Protocol and its transport layer handoff solution, Mobile SCTP (mSCTP) along with Chord architecture and operation in Chapter 2. In this chapter, we conduct performance analysis of mSCTP and Chord individually to check their suitability for mobility purposes. We will conduct a theoretical analysis of mSCTP handover latency in section 3.1 followed by simulation study of SCTP dualhoming feature and its performance under handover operation. Section 3.2 will cover the suitability of Chord as location manager concerning lookup latency and get results as nodes enters and leave the network. In last section 3.3, we will conclude the results obtained during the analysis.

mSCTP Handover Latency:

"Handover latency is the time at which an existing IP address becomes unavailable for end to end data transmission by movement of a node into a new network, to the time at which the end node receives a sequence of end to end transmission using the newly obtained IP address" [8]. mSCTP handover delay at this moment is generated by MN's movement detection, configuration of the newly attained IP address and Dynamic Address Reconfiguration (DAR) between a MN and a CN [19]. Following parameters are used to determine handover latency for mSCTP:

In this equation is the time taken to perform the complete handover process. is Movement Detection Delay, which is the time taken by a MN to detect its movement in the newly entered network. is the processing time of the newly attained IP address which includes; router solicitations, router advertisements and processing of the newly attained IP address. represents delay introduced by exchanging ASCONF and ASCONF-ACK chunks between MN and CN along with which presents the processing time required to switch data transmission from one interface to another during DAR procedure.

As dynamic assignment of newly attained IP address includes the exchange of ADD-IP message to inform CN of the newly attained IP address, Primary Change messages to inform the CN to change the primary path for communication, DEL-IP message to remove the previous IP address from the association and changing the primary path for communication, so in eq. 1 becomes,

MN undergoing the handover procedure is a multihomed device. SCTP can exploit its multihoming feature to transmit all data chunks using one interface i.e. the primary interface. Secondary interface on the other hand, can transmit control chunks required to configure the newly obtained IP address. Thus the time taken during movement detection and address configuration ( can be neglected, because MN and CN can communicate during these processes. So the total handover latency in equation (1) becomes

As explained in [8] [9]; that ASCONF chunks can be transmitted by bundling them with data chunks. Therefore, delay introduced by exchanging DAR control chunks between CN and MN, 3(+, can be neglected as no extra time is spent in transmitting these chunks from MN towards CN. Only delay significant enough is the processing time of a MN during DAR procedure which mainly includes switching of data transmission from one interface to another. So the total theoretical handover latency for mSCTP in equation (6) becomes

NS-2 Simulation:

In this section, we will analyze the performance of SCTP handover utilizing its multihoming feature. Ns-2 simulator and its SCTP module are used in this simulation. Currently SCTP module in ns-2 does not support any DAR parameters, therefore to compensate this limitation; handover (switching of interfaces in a multihomed device) is introduced by switching active session from one interface to another using force-source command in SCTP module.

Network Architecture:

Network architecture used in simulation is shown in the Figure 3.1. CN is connected to a router R via 10 Mbps link having a transmission delay of 20ms. Mobile Node having two interfaces if_1 and if_2 is connected to Routers R1 and R2. if_1 is connected to R1 using 2 Mbps links with a transmission delay of 50ms and if_2 is connected to R2 via 2 Mbps having a transmission delay of 50 ms. Router R1 and R2 are connected to R via 5 Mbps links with a transmission delay of 40 ms. FTP application is used to transmit data packets from MN towards CN. Simulation scenario is run for 60 seconds and handover is introduced by switching active session from if_1 and R1, to if_2 and R2 at 30 seconds.

MN interfaces are arranged in such a way that MN sends FTP packets towards CN using R1 and if_1 at the start of an SCTP association. Meanwhile if_2 does not participate in this communication session, and MN is in association with CN via R1 only. After 30 seconds an interface switching is done, and if_2 is activated, at this point MN uses both if_1 and if_2 to communicate with CN until if_1 has transmitted all its packets. Switching data transmission from one interface to another is done using force-source command in SCTP module. This command is used to initialize the inactive interface i.e. if_2, and transfer all active sessions from form if_1 to if_2. Data transmitted from MN towards CN during 60 seconds is shown in the Figure 3.2.

Performance Parameters:

Performance of SCTP is analyzed using the following performance metrics:

Handoff Delay:

Handoff delay is obtained by measuring the time taken for MN to execute a primary change operation along with the time taken for the first FTP packet to reach at CN after MN's interface is switched from if_1 to if_2. Primary change procedure includes the exchange of DAR configuration chunks along with the time taken for new interface to start transmission after handover.

After handoff period, MN starts transmitting FTP packets at 30.002s using newly switched interface i.e. if_2, while CN receives the first FTP packet from if_2 at 30.122s. mSCTP handoff procedure does not incur any significant delay during the primary change operation, as ASCONF and ASCONF-ACK chunks are bundled with data chunks in the on-going SCTP association utilizing as explained in section 3.1. Total delay of 2ms occurs during the primary change operation for MN to switch data transmission from if_1 to if_2. This delay primarily includes processing time during interface switching as explained in section 3.1.

Time taken by FTP packets to reach CN from MN's if_2 is 120ms. Thus, the total handoff latency including primary change operation and transmission time is 122ms. SCTP uses its multihoming feature to configure the newly attained IP address and bundle DAR configuration chunks with data chunks to reduce handoff delay by a greater extent. Only delay significant enough is introduced by the time taken for data chunks to reach CN.

Packet Loss:

Packet loss during the handoff interval is analyzed by counting the packets, which are dropped during swapping of the active session from if_1 to if_2. Packet traces show that two packets are dropped during the entire SCTP association; first packet is dropped at 20.21 seconds when if_1 is transmitting packets, which is immediately followed by recovery mechanism of SCTP using if_1. This also indicates that if_2 is inactive at this moment. Second packet drop occurs at 49.79 seconds when if_2 is transmitting.

Switching of active association from if_1 to if_2 is introduced at 30 seconds; and it is clear from packet traces that no packet drop occurs at this instant. Various observations are made by varying the time for handover procedure and analyzing any packet drop during the process. However, simulation result shows that no packet drop occurs when data transmission in an active session is switched from if_1 to if_2.

Chord Analysis:

Success and suitability of DHT Chord to operate as location manager depends on how efficiently it can locate MN's IP address, and how quickly can it answer to the queries requested by CN. Beside these features it also needs to self organize itself in worst network conditions such that its performance is not affected by the unstable nature, e.g. packet loss, high churn rate, BER etc, of wireless networks. Various tests are performed to analyze DHT chord and its suitability as location manager in this section.

Overlay Weaver:

Overlay Weaver is used to analyze the performance of Chord, which is an overlay construction tool kit having the following properties.

DHT shell is a layered command language interpreter, which is used to control DHT and its algorithms. It can invoke single or multiple nodes on the structured overlay network, using multiple instances of DHT Shell. Each instance of DHT shell acts as a node on the overlay network [overlay weaver]. Following commands are used during our analysis.

Test Scenario:

To simulate a large-scale overlay network in a relatively small environment, we invoked multiple instances of DHT shell, over fewer machines that are connected to one another in a local area network. The local area network consists of 8 nodes; connected to one another via router and switch using 10/100 Mbps Ethernet links. Each node is equipped with Overlay weaver and Apache Ant build tool.

Every node/instance in the overlay network is assigned a different port number, to differentiate it from other nodes running on the same machine. 50 nodes of DHT shell are invoked on each computer, to get a large-scale overlay network up to 400 nodes. Figure 3.4 shows the overlay network for 400 DHT nodes. Black lines represent the exchange of messages in between the nodes on the overlay circle. UDP is used as a transport protocol, and iterative lookup style is adapted to perform queries between Chord nodes. SHA-1 is used as a hashing algorithm to create 160-bits Node IDs and Resource IDs. Chord algorithm provided in the DHT Shell has the ability to support multiple values for a single key; this feature is also exploited in our tests for performance analysis.

Three experiments are conducted to analyze the performance of Chord as location manager by undertaking performance metrics like lookup latency, success of value retrieval when nodes enter and leaves the network. Lookup latency and get result for nodes entering the network is determined side by side. Initially the test starts by implementing single DHT instances on each machine and observing the lookup latency by entering a key-value pair in a randomly selected node using Put <key> <value> command. Another node is randomly selected to retrieve the value using Get <value> command. Five observations are made at each instant, and their mean is determined to obtain the average lookup latency. The number of nodes is then increased and the lookup latency is determined at each instant until 400 nodes.

Meanwhile success rate is also determined by making 25 queries for a key value pair in randomly selected nodes. Four tests are conducted by varying the number of values associated with a key. Nodes are randomly selected to insert the key-value pair using Put <key> <value>> and retrieve the required value using Get <value> at each instant. The number of queries successfully answered determines success of value retrieval. For nodes leaving the network, percentage of value retrieval is determined by manually decreasing the number of nodes from 400 to 100 at random times. Queries are made at random instances in randomly selected nodes at each step. The results obtained are explained below.

Performance Metrics:

Lookup Latency and Success rate of the queries successfully served, as nodes enters and leaves the network, is used to analyze the performance of Chord and check its suitability as a location manager. The results obtained are explained as under.

Lookup latency:

Session initiation between CN and a MN heavily depends on the time taken by CN to locate MN's IP address. Scalability of Chord is analyzed by observing its lookup latency while increasing the number of nodes in the laid network. Results in figure 3.5 shows that; as we increase the number of nodes, time taken to perform the query also increases. Besides increase in the number of nodes, number of messages during a query process can also be accounted for this slight increase in lookup delay [12].

However, the number of messages required to perform a query varied from node to node regardless of the number of values associated with a key. This variation in path length also affected the total time taken during queries at each instant. However, overall increase in the number of nodes does not have any significant affect on Chord's lookup latency, as Chord is still able to, efficiently and abruptly; locate a key-value pair with nodes continuously entering the network.

Get Results (Nodes Entering):

Suitability and success of chord depends on how successfully it can get MN's IP address. We define get results as the percentage of queries successfully answered out of the total number of queries. For this purpose, we gradually increased the number of nodes in the overlay network, and randomly performed multiple queries at each instant while observing the total number of queries successfully answered.

Figure 3.6 shows that as we increase the number of nodes, amount of queries effectively answered is decreased. However, the percentage of queries successfully answered in most cases remains high, more than 95%, as shown in the figure. Route failures and amount of values associated with a key, can also be accounted for the small uneven decrease in the number of queries successfully answered. Figure shows that overall increase in the number of nodes does not have any significant effect on the performance of Chord, as successful gets remains more than 95% in most cases. This shows that Chord is able successfully retrieve a key-value even, when the network keeps on growing.

Get Results (Nodes Leaving):

Nodes participating in a wireless network may leave or fail instantly. Therefore it is essential to analyze the performance of Chord when nodes forming an overlay network instantly fail or leaves the network. We performed our tests by manually removing 50 nodes at each instant from the network, and checking the successful gets for a key-value pair.

Figure 2.7 shows that, the performance of Chord is affected by small amount, as the percentage of successful retrievals remains as high as 90% in most cases. Even when we decreased the number of nodes from 400 to 100 nodes, Chord is still able to retrieve the required key value pair; however, the time taken in each query increased as we decreased the number of nodes in the overlay network, which may occur due to route failures. To account for this effect, we discarded any query that took more than 5 seconds. The number of values linked which each key, also showed some effect on the successful retrieval of the key-value pair.

Overall decrease in the number of nodes does not have any significant effect on the performance of Chord, as the percentage of successful gets remains more than 90% even when the network reduces to less than half of its original size.

Planet lab Nodes:

Tests performed previously are carried out in a controlled environment with limited number of physical nodes and without any network traffic to follow the queries. In this section, we have performed some tests for lookup latency and success rate on plant lab nodes. Planet lab is a tool, which can be used to perform internet related studies. It spans nodes across the world and runs on a common route that makes it special and more realistic than a simulation process.

Overlay weaver has the ability to connect the network formed by planet lab nodes, thus giving an overlay network consisting of all participating nodes in the planet lab system. We connected one of our nodes to a well-known entry point for DHT chord i.e. 140.127.208.239:3998 and entered a key-value pair. Then we performed our queries on randomly selected nodes from the successor list of currently selected node and observed the time and success rate of the queries. Results obtained are shown in table 3.2.

Conclusion:

In this chapter, we analyzed the performance of Chord and SCTP for mobility purpose. Section 3.1 presents the handover latency for an SCTP handoff process. SCTP exploits its multihoming feature to configure the newly attained IP address and bundle DAR configuration chunks along with data chunks to reduce the handover delay. These features of SCTP also help in reducing packet drops during the handover process, and doesnot affect any significant throughput during the on-going session, thus making SCTP an ideal candidate for vertical handovers.

Analysis of Chord in section 3.2 shows that lookup latency is increased as we increase the number of nodes. Path length during a query process also grows, at 0(Log N), with increase in the number of nodes, thus giving a slight increase in lookup delay. This feature provides high scalability to Chord and no significant changes are required to deal with growing network sizes. Providing a suitable solution for reducing the number of messages during a query process can further reduce lookup latency. Analysis of Chord value retrieval shows that, Chord can efficiently retrieve the required value under unstable networks. However, techniques like data redundancy can further improve the value retrieval process. Efficient and abrupt lookup operation and no need for additional network components make Chord an efficient candidate for location management along with mSCTP.

Chapter 4 Decentralized Mobility Framework

We discussed Stream Control Transmission Protocol and its transport layer handoff solution, Mobile SCTP along with Chord architecture and operation in Chapter 2. Performance analysis of mSCTP and Chord shows that both can be used together to produce a decentralized mobility framework, based on mSCTP multihoming feature and Chord efficient key-value mapping. In this chapter, we describe the proposed framework for mSCTP location management. Section 4.1covers the basic requirements and operation of DHT Chord as location manager. Operation of Chord along with mSCTP is explained in section 4.2. Last section 4.3, covers the challenges, and open issues related to our proposed framework.

Deployment of DHT Chord as Location Manager:

Most connections generated inside the internet starts with location query i.e. IP address [23]. IP address is the key feature in the current internet architecture. It can be used to uniquely indentify an internet-connected device, specify the location of a device, and provide the routing path to that device in the network. Main function of DHT chord as a location manager is to locate the mobile host and provide its IP address to CN. Chord along with DHT can provide the necessary name to IP mapping where name presents a Key and IP represents a Value in the key-value pair [12]. CN after receiving the required IP address will handle the communication process using mSCTP.

Addressing Scheme:

For DHT chord to perform the necessary location management we need to create an identifier-locator set for each participating node, such that identifier refers to the key and locator presents a value in the key-value pair. Identifier has to be a unique value for every participating node, and every node that wants to communicate with a certain node must know its identifier. We refer to this identifier as UID (Unique Identifier).

UID must be assigned in such a way, which is globally unique and location transparent, because using the location information in UID will make it difficult to handle mobility [27]. We used three basic components for our UID, which are easy to remember and their combination can result in a globally unique identifier. These are name.device.ID. The name attribute refers to the name of the device owner; it can be a surname or name initials. Device attribute refers to the device he or she is using. It can be a laptop, PDA or a mobile device. ID refers to the value of a unique identity that can be his or her mobile number, email address or social security number e.g. waq.laptop.850508xxxx can be a UID for a laptop. We can use any naming scheme as chord provides flexible naming mechanism.

Locator represents the current IP address of the node in a certain network. It is arranged in such a way that when a node changes its point of attachment and attains a new IP address, the locator also updates, resulting an update in the value section of the key-value pair. We refer to this as TL (Temporary Locator) which is synonymous to the current IP address at the interface of the node or node ID. Combination of UID and TL value in DHT Chord can efficiently provide the required location management functionalities.

Value Parameters:

The value field in the key value pair can be associated with more than just TL values. It can carry multiple information, which can not only optimize handover management but also improve the location management process. Information like TL value priorities, explained in later section, can be carried along with the TL values to make the communication process less complex. Time to Live (TTL) for a certain TL value can also be associated with the value parameter, which can help to remove the value from a certain DHT when its corresponding node departs.

Value field can also utilize to MIH Event Services Ids [44] to optimize the handover process and interface switching process of mSCTP. These event Ids contains information about states like; link up, link down and link going down. This information can determine the link states associated with its TL value, and facilitate the interface switching process during handovers as explained in subsection 2.5.4.

Network Components:

Overall network consists of the following components.

Chord Nodes:

Chord nodes are those nodes, which are connected to one another in the overlay network constructed at the application layer. This overlay network forms a virtual backbone for location management that is distributed, decentralized and self-organizing. Any node and device in the network capable of storing a small amount of information and forwarding the chord query packets can become a Chord node. Each Chord node is assigned a new identifier, which is generated by hashing it current IP address and port number using SHA-1. Node ID is then used to place the node on the chord overlay circle.

Once a node enters into the overlay network, it can publish and update its location management information along with querying for any desired TL value. As there is no central coordination so, the users communicate to each other via application that functions both as client and server, where the server offers the location management services and client receives them.

Bootstrap Nodes:

Bootstrap nodes are same as that of chord nodes; however, those nodes that are less mobile and have resided in the network for a long period can become bootstrap nodes. MN can use these nodes to enter into the network, and a local DHCP server, which is regularly updated with their info, can provide the required information.

Node Positioning:

Position of a Chord node on the identifier circle primarily depends on its Node ID obtained by hashing its IP address i.e. TL value and port number. However, such values can lead to a random placement of the node in the overlay network. Therefore a better approach will be, to place the entire node in a single network, as close as possible. Adding a network prefix to the node id such that each node in same network will have the same prefix can provide the required node placement.

Figure 4.2 shows an example of node positioning, in which all the nodes having same color represent the nodes in a same network, having same network prefix. Same network prefix places them together in the overlay identifier circle as shown in the figure. This arrangement can help MN to select a nearer Chord node to submit it queries and location information. Successor nodes in the finger tables are arranged in such a way that it has many entries containing nearby nodes, and less entries containing more remote nodes [18]. Thus it make its less complicated to send pointer, explained in later section, towards closer successor nodes rather than sending them all over the overlay network. This arrangement can also be extended to a two or three tier architecture, which can resolve NAT traversals and routing overheads, however it requires the concept of super nodes and many issues has to be resolved in order to put it together [17] [31].

Node Entry:

When a MN enters into the network, it needs to publish its location information in order to establish itself as a communication endpoint. For this purpose, it needs to locate an entry point in the overlay network. Information about the bootstrap node can be provided by querying DHCP server along with other information necessary for a node when it enters into the network. MN updates its UID-TL pair on the reception of a new IP address, and the pair looks like

waq.laptop.850508xxxx

44d03ae2b26872da3b50213fd5db94666d5fff93

When a node wants to join the overlay network, it hashes its IP address and port number to create a Node-ID added with network prefix and sends a REGISTER message to a bootstrap node in the overlay network. After joining the overlay network MN will submit a query, to find mapping between its UID value and a base node, to publish its TL value. Chord node carrying the required TL value is referred to as BASE NODE in rest of the document. The mapping process is explained in subsection 2.7.2. MN on reception of the base node information will send its UID TL pair to the base node. MN can use time based update mechanism and, periodically send update messages on the received IP address of the base node, and wait for its acknowledgment from the base node. These acknowledgment messages will indicate the presence of the base node. In case of a base node, failure ACK messages will cease to arrive, and MN will again hash its UID value to locate another base node on the identifier circle and publish its TL value.

Base node on reception of UID-TL value from MN will publish pointers towards every Chord node on its finger table. Pointer can help in reducing the number of messages required during a query process. Figure 4.3 shows the process , where a base node N8 publish pointers towards its successors advertising; that it has the TL value for node N0 having unique identifier UID0. Base node will periodically publish pointer for all the values in its DHT, which can help in coping with any updated information regarding TL values.

Node Departure:

When a base node suddenly fails or leaves the network, MN will notice the failure or departure of its base node as, the acknowledgment messages it is receiving in response to the TL update messages will cease to arrive.

In this case, MN will again submit a query to find the mapping between its UID value and a new base node. On reception of the query reply, it will transfer the values on the new IP address of the newly mapped base node.

Base node on reception of the new TL value will publish pointers for the newly arrived TL value towards its successor nodes. Figure 4.3 shows this process in which base node N7 leaves the network and the value stored in N7 is transferred to its successor node N8. N8 on reception of the new TL value will publish its pointers towards its successor nodes. Meanwhile the pointers assigned by base node N7 will time out and vanish, if they are not updated periodically. These pointers can help in reducing the number of messages during a query process shown in Fig 4.4, which in turns reduces the total time taken to perform a query.

Location Search:

When CN wants to initiate a session with a MN it will submit a query carrying MN UID value and its own IP address, to its successor Chord node regarding TL value of the MN. Successor node will map the given UID value to the responsible base node as explained in subsection 2.7.2, and provide the base node with an IP address of the querying CN. The IP address can help to transfer the requested TL values directly from base node to the CN.

Let us say, during the query process it encounters a chord node with a pointer towards the base node. The query is instantaneously redirected towards the base node, which will provide the necessary TL value as shown in the Figure 4.4, in which Chord node N19 querying for the TL value linked with UID0 submits a query to its successor node N21. N21 after searching for the closest interval forwards the query to node N26. N26, having a pointer for UID0, will redirect the query to node N7. Node N7 will take the IP address from the query packet, and will directly transfer the required TL value to node N19. Successor pointer can reduce the 0(Log N) messages required to locate an object over the chord identifier circle, as shown in the Figure 4.4.

Worst case during the query process can be that; the querying node does not find any pointer towards the successor chord node and it will take the necessary 0(Log N) steps to complete the search process. Base node on reception of the query request will transfer the required TL value to the querying CN. In order to have the current TL value, CN need to perform the query process at regular intervals, which can provide the current location information along with any updates regarding change of the base node containing TL value.

Location Update:

When a MN enters the overlapping region, it attains a new IP address from new network, say network 2 DHCP server along with the local bootstrap node information in that domain. MN will signal the new IP address to its mSCTP stack and add it in the current SCTP association along with updating its TL values and responsible base node. Its respective base node will also notify CN of the change in TL value. CN at this instant will again submit quries to check for any changes in the base node carrying the required UID-TL pair.

However, MN still resides in network 1. CN at this instant can use TL value priorities to determine primary IP address for communicatin with MN. In the overlapping region, the priorities of TL values will be such that the TL value attained in network 2 will have a low priority and CN will use the TL value from network 1 as a primary path as shown in Figure 4.5. When MN leaves network 1 and joins the network 2, but is still in the overlapping region, it will change the priorities such that TL value in network 2 will have a higher priority.

When MN leaves network 1, but is still in the overlapping region, it will send a register message to the bootstrap node in network 2, and update its location and base node in the overlay network as its node ID will change due to a change in its TL value. At this point MN will have two base nodes carrying its TL value. BN1 will be located in network 1, and BN2 located in its new network 2 as shown in Figure 4.5. MN on joining the new overlay network will inform BN2 of its previous base node BN1. BN2 on receiving the necessary information will send a redirect query message towards BN1. BN1on reception of this message, will redirect all the queries regarding UID value of the MN towards BN2, until its value times out in BN1 as shown in the figure.

When MN leaves the overlapping region and completely transfers into network 2, it will update its UID-TL value by sending an update message to the responsible BN2. CN on query will get the new TL value and use this value as a primary path for communication. CN will remove TL value from network 1 from the active association. When a UID-TL value becomes inaccessible in the previous network base node, due to node leaving or failure to provide a location update, location information pointers placed on successor nodes will time out and vanish.

Handover Procedure:

The use of mSCTP along with DHT Chord focuses on sessions initiated from CN towards a MN. DHT Chord will only provide the current TL value of a MN to the querying CN. CN will use this information to initialize an SCTP association with the MN. Once an association is established, mobile SCTP vertical handover procedures will support the on-going session when required [10].

Association Establishment:

CN needs to locate the MN in order to start an SCTP association. For this purpose, it will hash the UID value of the MN and submit a query for its TL value. After querying and obtaining the required TL value, it will send the value to its mSCTP stack and, will start the basic SCTP association initialization process by sending an INIT chunk towards the MN on the obtained TL (IP address) value. It will be replied with an INIT-ACK chunk from MN, and finally the connection will be established by exchanging COOKIE-ECHO and COOKIE-ACK messages.

Figure 4.6 shows an example in which a MN N19 enters network 1, we assume that the MN has obtained an IP address from local DHCP server along with information regarding bootstrap node, and has joined the overlay network and published its UID-TL pair and its base node is N26. N26 on reception of the TL value from N19 will publish pointers towards its successor nodes. Now CN N0 wants to initiate an SCTP association with N19, it will query for the required TL value of N19 by using its UID. After performing the necessary search operation it will get the required TL from N26. N0 will use it to send an INIT chunk to the MN N19, and hence establish an SCTP association by exchanging INIT-ACK, COOKIE-ECHO and COOKIE-ACK chunks.

Data Transport and Handover:

After an association is established, CN will send packets directly to MN over the acquired TL value. Base node will have the current information on location of the mobile node, and MN periodically updates it location by sending update messages towards its base node. CN will periodically query the mapped base node in order to keep itself updated all the time. Base node on the other hand will send pointers towards its successor chord nodes advertising all TL values it has, along with replying to MN with acknowledgment messages and CN with the required TL value and update messages in case of any change in the queried UID value.

Let us say MN moves from network 1 to network 2, and we assume that it attains a new TL value and bootstrap node information from network 2 DHCP server. It will update its respective base node i.e. BN1, with the new TL having lower priority. CN will also get an update message from its respective base node regarding update in the queried UID TL value. CN on reception of this message will again submit a query in order to find any changes in the base node. MN on the other hand will perform a soft handover by adding the newly attained IP address to its ongoing SCTP association using mSCTP DAR extension.

Handling Priorities:

MN will have two TL values in the overlapping region. Now the priority of the TL value will decide a TL value to communicate the MN. Figure 4.7 shows the priorities in which MN handles its TL values priorities and updates its responsible base node. Let us say that initially MN has only one TL value, which is used during the active session. At the time t1, MN enters into the overlapping region, attains a new IP address, and updates its TL value.

MN after updating its Tl value will send an update message to the responsible base node in network 1 i.e. BN1 and updates its UID-TL pair with both values in such a way that TL value obtained at network 1 has higher priority, and is used as a primary path for the communication process. At time t2 MN handoff to a different network, and it sends another update message to the responsible base node in network 2 i.e. BN2, with the newly obtained TL value having higher priority. TL value attained from network 2 will be used as a primary path for communication. After handoff is complete and MN leaves the overlapping region at time t3, it will send an update message to remove the old TL value from previous network and set the new value as a primary value.

Challenges and Open Issues:

One of the major issues concerning our framework is unstable Chord nodes. As mentioned in section 4.1.2, almost every node can be a Chord node. Such solution however decentralized, brings unstability to our system along with deterioration in performance. Nodes with minimum computation capabilites can slow down the lookup mechanism. Besides low compution power nodes, high rate of nodes entering and leaving the network can also affect the performance of the location management framework. As high rate of nodes, departure will result in more configuration and update messages and hence the system can result in a high transmission throughput. One approach to overcome this issue is to remove nodes with less computation power and high mobility from the location management backbone. Such nodes will act as clients to the Chord nodes, which will act as Distributed Location Servers (DLS), with high computation power and much stability as compared to other mobile nodes. The client nodes on entering the network can decide, either to join the overlay network and take responsibilities as a DLS, or simply act a client connected and updates by DLS. Such an approach can bring stability to our proposed framework, with its decentralization feature still intact. However, such an approach demands for more set of rules and regulation regarding DLSs, and their operation in the network.

The proposed framework has only considered issues like efficient retrieval of key-value pair. Churn related issues has not been considered, therefore it requires a proper attention in this aspect as wireless networks are unstable and can introduce high churn rates due to nodes continuously entering and leaving the system. DHCP server providing the required bootstrap node IP address, needs to be updated frequently as, base nodes are mobile and unstable and can easily leave the overlay network. Therefore, a suitable body has to be assigned, in order to update DHCP serves.

mSCTP handover rules also needs to be decided, as no proper set of rules are yet determined to decide when to switch the interfaces during the handover process [10]. Many suggestions are provided regarding this issue, but they are still at the testing stage, and are not yet implemented completely. Another major issue regarding mSCTP is that, mSCTP still exists at the draft level, and is not yet deployed as MIP and SIP. Therefore, a proper infrastructure of rules and regulations is required for its deployment and operation.

Use of Chord with mSCTP can introduce problems like delay in the update of a base node's DHT. This can expire an active session before a handover takes place, as CN will get an old TL value on querying the base node. However, by properly using the multihoming feature of mSCTP can solve this problem. Multihoming allows SCTP to hold TL values at both the interfaces, and thus CN can use the previous TL value in case of failure of the newly attained TL value.

Chapter 5 Conclusion and Future Work

We discussed two major aspects of mobility management; Location Management and Handoff Management and proposed a decentralized location management scheme for mSCTP. mSCTP provides a seamless handover solution based on its multihoming feature and DAR extension. However, mSCTP does not provide any location management. DHT Chord is proposed to work along with mSCTP as a location manager.

Conclusion:

Ubiquitous mobile computing requires seamless IP based handover solutions to exploit its full potential. Many solutions have been proposed to support seamless roaming of mobile users in the heterogeneous networks. Mobile IP, a network controlled solution, is one of the most widely deployed handover solutions till date. However due to its network layer mechanism and dependence over additional components, it cannot reduce significant delay during it handover procedures. This delay not only effects transmission behaviors at transport layer but also introduce a significant amount of end-to-end delay during handovers [8]. mSCTP being a transport layer solution provides several advantages over MIP. mSCTP can provide a non delayed IP based handover procedure with almost no packet loss as shown in section 3.1 and 3.2. Its multihoming feature can also be exploited to support data transmission on one interface and configuration packets transmission on another interface, which not only improves the handover mechanism, but also eliminates any interruptions in the active communication session during the handover procedure.

mSCTP however, is basically designed for client-server operations; therefore it cannot provide any location management in situations where server/CN initiates the communication session. Location management in IP based handovers; provides IP address of the MN. By choosing Chord to perform the required name (UID) to IP (TL) mapping, we can build a completely decentralized location management system as explained in section 4.1. Chord is a DHT algorithm which can efficiently retrieve a key value pair stored in DHT of the node to which the key maps. Performance analysis of Chord in section 3.3 shows that, it can efficiently and abruptly retrieve a key-value pair with a success rate of almost 99%, regardless of any changes in the size of the network or the number of values associated with a key. Additionally the time that it requires to perform a query depends on a total of 0(Log N) messages; therefore no special changes are required to cope with the scalability issue.

However for DHT Chord to work along mSCTP the key-value pair has to exchanged with locator-identifier set, referred to as Unique Identifier(UID) and Temporary Locator (TL) as given in subsection 4.1.1. TL value is analogous to the IP address of the MN and is updated as the IP address changes. Besides addressing scheme, any node and device in the network must be capable of storing a small amount of information and forwarding the chord query packets. This approach not only brings decentralization to our introduced framework, but also eliminates the need of any additional components in the network architecture. Successor Pointers, as given in subsection 4.1.4, are also introduced in the framework to efficiently reduce the lookup messages during a query process and speed up the key-value mapping as explained in section 3.2.4.

Chord nodes bring decentralization to our framework however with certain disadvantages like; each node participating as a location server will require a continuous set of services, which can result in greater overhead and transmission throughput. Chord Nodes are mobile and the time that they spend in the network varies. Therefore sharing location management responsibilities with a node that enters the network for a very short span can make the system unstable. However, this approach can be replaced by the concept of super nodes that will introduce much stable and high computation power DLS systems to the architecture as explained in section 4.3, but more work is required in this regard.

Efficient lookup algorithm, high scalability, flexible naming, authorization support, and no central point of failure make DHT Chord an ideal candidate for location management. Backed by mSCTP multihoming feature and DAR extension, Chord can efficiently provide the required location information and support non-delayed handover procedures. Besides technical advantages, end users will gain more flexibility and added functionalities because of this mobility architecture. However this framework still faces some challenges, and issues like Churn, unstable Chord nodes and high transmission throughput during the update process have to be resolved before it can be deployed as a proper seamless roaming solution.

Future Work:

During the course of our thesis, we narrowed down our work by using some assumptions. Our work can be extended by working on these assumptions and issues, to provide suitable solutions for them. Throughout our framework we neglected NAT related issues as existing NAT infrastructure is not designed to support mSCTP handover, as it assigns a different port number to an active association whenever a primary address changes. mSCTP does not accept this change in the port number and hence terminated the association [11]. More work is required in this aspect. As mentioned in subsection 4.1.3, DHT hierarchy can resolve this issue. However, introducing hierarchy to the network can result in higher lookup times and more challenges to work with.

mSCTP handover triggering rules, to work along with Chord, have been narrowed to a single a rule; the handover occurs only when the signal strength decreases in the overlapping region. Though an essential enhancement lies not only in determining the set of rules, which can help to decide when to switch the primary path, but also in evaluation the possible gain by working along with Chord as location manager [7]. MIH parameters can be utilized to improve the handover mechanism and its information can be transmitted in Chord value section as shown in subsection 4.1.2.

Issues related to DHCP server, which is used to maintain bootstrap nodes information has been neglected. This work can be extended to introduce a suitable update source for the DHCP server which include Internet Service Providers, Private persons etc. Updating and Churn in Chord are also been neglected.

Throughout our thesis, we focused on the fact that every node can be a Chord node. Although it is a completely distributed approach, it can cause problems as some of the nodes have week computation capabilities, limited storage space and signal strength. Nodes can also be mobile, which can introduce a great deal of routing overhead for the exchange of update messages throughout the network along with instability. Therefore, a better approach will be to use the concept of super nodes as DLS, which can act as a distributed location server. Super nodes can introduce stability to the proposed framework and many churn related issues can be resolved with this technique. However, it required complete set of rules and regulation to appoint a super node and its functionalities.

We have used only Chord to propose our mobility framework. DHT provides many algorithms like CAN, TAPESTRY, PASTRY, which can also be considered to propose the required the framework. We have analyzed the required performance of mSCTP and Chord individually. The results showed that Chord along with mSCTP could provide seamless handover procedures. However, a prototype of the proposed framework needs to be developed in order to analyze the performance and behavior of complete framework.

References:

  1. S. Fu and M. Atiquzzaman, "SCTP: State of the Art in Research, Products, and Technical Challenges," IEEE Communication magazine, vol. 42, no. 4, pp. 64-76, Apr. 2004.
  2. SCTP for Beginners, http://tdrwww.exp-math.uni-essen.de, [Online], [Accessed: May 5th, 2010].
  3. SCTP Programmer's Guide: HP-UX 11i v2, HP-UX 11i v3, http://www.docs.hp.com/en/5992-4578/index.html, [Online], [Accessed: April 10th, 2010].
  4. Muhammad Omer Chughtai, "Transport Protocol for Video Traffic over Mobile WiMAX", Masters Thesis, Department of Electrical Engineering, Comsats Institute of Information Technology, Islamabad, Pakistan, 2009.
  5. Leopld Franzens, "Speeding Up Java Web Applications and Web Services Calls with SCTP", Masters Thesis, Institute of Computer Science, University of Innsburk, 2008.
  6. Randall Stewart, Paul D. Amer, Why is SCTP needed given TCP and UDP are widely available?, September 2007, http://www.isoc.org/briefings/017/, [Online], [Accessed: May 10th, 2010]
  7. L. Budzisz, R. Ferrus, A. Brunstrom, and F. Casadevall, "Towards transport-layer mobility: Evolution of SCTP multihoming," Computer Communication, vol. 31, pp. 980-998, Dec. 2008.
  8. J. K. Song, "Performance Evalution of Handoff between UMTS/802.11 Based on Mobile IP and Stream Control Transmission Protocol", Masters Thesis, Department of Computer Science, North Carolina State University, 2005.
  9. R. Stewart, Q. Xie, M. Tuexen, M. Maruyama, and M. Kozuka. (2007, Jun.) Internet-Draft SCTP Dynamic Address Reconfiguration. [Online]. http://tools.ietf.org/html/drafts/ietf-tsvwg-addip-sctp-22.
  10. S. J. Koh, Q. Xie, and S. D. Park. (2005, Oct.) Internet Draft mSCTP for IP Handover Support. [Online], http://www.ietf.org/proceedings/65/IDs?drafts-sjkoh-msctp-01.txt.
  11. S. Zeadally and F. Siddiqui, "An Empirical Analysis of Handoff Performance for SIP, Mobile IP, and SCTP Protocols," Wireless personal communications, vol. 43, pp. 589-603, 2007.
  12. I. Stoica, R. Morris, and D. Karger, "Chord: A scalable peer-to-peer lookup service for internet application," ACM SIGCOMM Computer Communication, vol. 31, pp. 149-160, 2001.
  13. S. Sarmady, "A survey on Peer-to-Peer and DHT", Grid Lab, School of Computer Science, Universiti Sains Malaysia, Penang, Malaysia, 2007.
  14. F. Dabek, E. Brunskill, M. F. Kaashoek, and D. Karger, "Building peer-to-peer systems with chord, a distributed lookup service," Proceeding of the eighth Workshop on operating System, pp. 81-86, Aug. 2002.
  15. J. Yang, "Measuring the Performance and Reliability of Routing in Peer to Peer Systems," Master Thesis, Victoria university of Wellington, New Zealand.
  16. M. Xie, "P2P Systems Based on Distributed Hash Table", Masters Thesis, Department of Computer Science, University of Ottawa, September 2003.
  17. O. Hanka, C. Spleib, G. Kunzmann, and J. Eberspächer, "A novel DHT-Based network architecture for the Next Generation Internet," Eighth International Conference on Networks, pp. 332-341, May 2009.
  18. M. Zangrilli, D. Bryan, "A Chord-based DHT for Resource Lookup in P2PSIP", Internet Dreaft draft-zangrilli-p2psip-dsip-dhtchord-00, SIPeerior Technologies, February 25, 2007.
  19. D. Kim and S. Koh, "Analysis of handover latency for mobile IPv6 and mSCTP," IEEE International Conference on Communication Workshops, pp. 420-429, May 2008.
  20. W. M. Eddy, "At What Layer Does Mobility Belong?," IEEE Communication Magazine,, vol. 42, no. 10, pp. 155-159, Oct. 2004.
  21. T. You and S. Lee, "The framework for mobility and multihoming Using Overlay Network," The framework for mobility and mu8th International Conference on Advanced communication Technology, vol. 3, pp. 1803-1806, May 2006.
  22. S.Thomson, Y. Rekhter, Paul Vixie, "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136.
  23. A. A. S. R. Reaz, M. Atiquzzaman, and S. Fu, "Performance of DNS as location manager," IEEE International Conference on Etectro Information Technology, p. 6, May 2005.
  24. S.Hailes, A.Pappas, R.Giaffreda, "Mobile Host Location Tracking through DNS", London Communication Symposium, September 2002.
  25. H. Park, M. Kim, S. Lee, S. Kang, and Y. Kim, "A mobility management scheme using SCTP-SIP for real-time services across heterogeneous networks," A mobility management scheme using SCTP-SIP for rea proceedingsof the 2009 ACM symposium on Applied Computing, pp. 196-200, 2009.
  26. Overlay Weaver, http://overlayweaver.sourceforge.net, [online], [Accessed: May 10, 2010].
  27. K. Sethom, H. Afifi, G. pujolle, "PALMA: A P2P based Architecture for Location Management", IFIP International Conference on Mobile and Wireless Communications Networks, 2005.
  28. S. Cirani, L. Veltri, "Implementation of a Framework for DHT-based Distributed Location Service", International Conference on Software, Telecommunication and Computer Networks, p 279-83, 2008.
  29. V. Pappas, D. Massey, A. Terzis, Z. Lixia, " A Comparitive Study of the DNS Design with DHT-based Alternatives", 25th IEEE INFOCOM Conference, p 1446-58, 2006.
  30. D. Kato, T. Kamiya, "Evaluating DHT Implementations in Complex Environments by Network Emulator", NEC Corporation, 2007.
  31. Z. Xu, Y. Hu, "SBARC: A Supernode Based Peer-to-Peer File Sharing System", Computers and Communications, Eight IEEE International Symposium on Digital Object Identifier, 2003.
  32. A. Popescu, D. Erman, M. Fiedler, and K. D. Vogeleer, "An application layer architecture for seamless roaming," An application layer architecture for seamless Proceedings of 6th International conference on Wireless on Demand Network Systems and Services, pp. 212-220, Mar. 2009.
  33. M. Atiquzzaman and A. S. Reaz, "Survey and Classification of Transport Layer Mobility Management Schemes," 16th IEEE International Symposium on Personal, Indoor and Mobile Radio Communications,2005, vol. 04, pp. 2109-2115, Jul. 2006.
  34. M. J. Freedman, M. Vutukuru, N. Feamster, and H. Balakrishnan, "Geographic Locality of IP Prefixes," Internet Measurement Conference , Oct. 2005.
  35. D. Doval and D. O'Mahony, "Overlay networks: A scalable alternative for P2P," IEEE Internet Computing, vol. 07, no. 04, pp. 79-82, Jul. 2003.
  36. K. Singh and H. Schulzrinne, "Using an External DHT as a SIP Location Service," Department of Computer Science, Columbia University, New York, Computer Science Technical Report Series, 2006.
  37. A. L. Caro, K. Shah, J. R. Iyengar, and P. D. Amer. (2003) CiteSeerX. [Online]. http://web1.fandm.edu/jiyengar/papers/sctpvariants-techrep2003.pdf
  38. D. J. Oneil, H. J. Kang, J. Kim, and D. Kwon. (2004) CiteSeerx. [Online]. http://www-users.cs.umn.edu/~jinohkim/docs/supernode.pdf
  39. M. Zundt, G. Dee, M. Naumann, and D. M. Ludwig, "De-centralized Location Management: Minimizing Privacy Concerns for Location Based Services," in 3rd International Conference on Information Technology: Research and Education, Hsinchu, Taiwan, Sep. 2005, pp. 23-27.
  40. I. Aydin, W. Seok, and C. C. Shen, "Cellular SCTP:A Transport-Layer Approach to Internet Mobility," in Proceeding 12th International Conference on Computer Communications and Networks,2003, Dallas, TX, USA, 2003, pp. 285-290.
  41. V. Pappas, D. Massey, A. Terzis, and L. Zhang, "A Comparative Study of the DNS Design with DHT-Based Alternatives," in proceedings 25th IEEE International Conference on Computer Communications, Barcelona, Spain, 2006, pp. 1-13.
  42. S. Sivaraja, M. Thiyagarajah, T. Piranavam, C. H. Lung, and S. Majumdar, "Efficient Multiple-Keyword Search in DHT-based Decentralized Systems," in proceedings International Symposium on Performance Evaluation of Computer and Telecommunication System, Edinburgh, UK, 2008, pp. 406-412.
  43. B. Sidhu, H. Singh, "Location Management in Cellular Networks", World Academy of Science, Engineering and Technology, 2007.
  44. Y. Chen, M. Lei, S. Lin, S. Chang, "SCTP-Based Handoff Based on MIH Triggers Information in Campus Networks", 8th International Conference on Communication Technology, p 5 pp, 2006.
  45. E. Fallon, J. Murphy, L. Murphy, Y, Qiao, " Towards a Media Independent Handover Approach to Heterogenous Network Mobility", ISSC, Derry, 2007.
  46. M. Emmelmann, S. Wiethoelter, A. Koepsel, C. Kappler, A. Wolisz, "Moving Towards Seamless Mobility- State of the Art and Emerging Aspects in Standardization Bodies", Wireless personal Communication, v 43, p 803-16, 2007.
  47. L. M. Campoy, " LTE-Advance Evolution to match Explosion of Mobile Data Traffic", 2nd International ICST Conference on Mobile Lightweight", Barcelone, Spain, 2010.
  48. D. Nagamalai, J. Lee, "SCTP over High Speed Wide Area Networks", lEEE Conference on Cybernetics and Intelligent Systems Singapore, Vol. 3420/2005, pp. 628-634, 2005.