Seamless Handover in Heterogeneous Radio Access Networks Christina Thorpe University College Dublin, Ireland Contact: christina.thorpe@ucdco nnect.ie
Sean Murphy University College Dublin, Ireland Contact:
[email protected] m
Abstract This paper provides a detailed discussion of the problem of Seamless Handover in Heterogeneous Radio Access Networks. Brief descriptions of several wireless access technologies are included to provide some background information and to illustrate the importance of solving the seamless handover problem for network subscribers. Several approaches to providing a handover solution have been proposed, some of which will be described and compared, in order to indicate possible directions for continuing to search for a seamless handover solution. Various problems are present in the existing solutions, and are discussed in this paper. These problems are significant enough to warrant further investigation in the handover area, and leave scope for modifications and improvements.
1. Introduction. Wireless Communications is the main source of expansion in the area of communications in recent years; it has evolved rapidly and is one of the most promising areas of research. Third generation networks, with provision for streaming applications, internet access and gaming have now been commercially realized and the standardization of fourth generation technology has already begun. Wireless communication brings fundamental changes to data networking and makes integrated networks a reality; their main objective being the ubiquitous availability of personal communications. With these advancements comes the inevitable demand to enable mobile hosts to move seamlessly between the available networks. The main objective of this paper is to determine the most desirable approach to the
Liam Murphy University College Dublin, Ireland Contact:
[email protected]
seamless handover problem in heterogeneous radio access networks. The results of this comparative study will point to future investigative work, where the process of simulating scenarios will be used to determine the most efficient protocol to solve the handover problem. There have been many approaches to solving the handover problem, some dealing with the network layer and others higher up in transport layer. The network layer solution proposed which will be discussed is Mobile IP. Details will be provided to illustrate the functionality and features of this mobility solution; the problems existing in this technology will also be mentioned. These problems are significant enough to call into question the wide adoption of this solution, and therefore leave scope for alternative solutions. Two such alternatives include mSCTP, which is a modification to the Stream Control Transmission Protocol; and TCP Migrate, which is a modification to the Transmission Control Protocol. The remainder of this paper is structured as follows: Section 2 contains background information, provided to clearly demonstrate the significance of research carried out in the seamless handover area. Section 3 will provide a high level definition of what the problem of seamless handover actually is, and illustrates why it is an important issue in wireless communication. This section is then further divided to discuss the three handover solutions proposed. Section 3.1, 3.2, and 3.3 discuss Mobile IP, mSCTP and TCP Migrate respectively, with details on the features, handover processes and problems present in each. Section 4 details preliminary simulations carried out and possible future simulation work to be performed on the two transport layer protocols. Finally, section 5 will conclude the research carried out and presented in this paper.
2. Background. Wireless networks have been growing and evolving rapidly in recent years. Their straightforward, cost effective and fast deployment, together with their mobility support, has made them a popular alternative to the traditional wired networks. As a result many wireless standards have been ratified by standardization bodies such as IEEE and ETSI; for example 802.11, 802.21, 802.16, Bluetooth, and 3G, each of which aim to solve different problems. A typical wireless system uses one or more Base Stations (BSs) or Access Points (AP) to connect users to a network. Many of the existing standards for wireless systems are illustrated in Figure 1 below.
Figure 1.
Seamless handover is when a handover from one cell to another takes place without perceptible interruption of the radio connection. Seamless handover is a fundamental concern in any system with mobility. Its major goal is to hide from the application (or user) any difference between the normal service offered within a domain and during a migration. Explanations of the actual handover procedure will be given with the help of Figure 3 below. The network scenario used is two wireless access routers A and B, and a wired access router C, all connected through the Internet. The coverage areas of both wireless routers are overlapping, and the mobile node connected to access router A is communicating with the correspondent node connected to access router C. If the mobile node decides to move from the coverage area of A towards B and passes through the overlapping area, communication should hand over from A to B without loss of connection or noticeable decrease in performance.
Wireless technologies
2.4 Current Trends. The current Internet is constructed from various kinds of wired and wireless access networks. To connect with these networks, mobile hosts have multiple network interfaces. In such an environment, it is an essential problem to enable mobile hosts to move across these different networks without loss of connection or degradation of communication quality. Moreover, since “real-time” communications, such as gaming and voice over IP, are expected to increase more than non real time communications, keeping the quality of a real time communication during handover is essential. Many equipment vendors already offer multimode devices which have integrated WLAN interfaces included in their design, a trend which will continue for the foreseeable future.
3. Handover Solutions.
Figure 2.
Seamless handover
3.1 Mobile IP. Mobile IP can be thought of as comprising of three major subsystems. First, there is a discovery mechanism defined so that mobile computers can determine their new attachment points when the move from the coverage area of one access router into the coverage area of another. Second, once the mobile computer knows the IP address at its new attachment point, it registers with an agent representing its home network. Lastly, it defines mechanisms to deliver datagrams to the mobile node when it’s away from its home network [1]. Agent discovery is the method by which a mobile node first establishes contact with an agent
on the local network to which it is attached. The main goals of agent discovery include: Agent/Node communication - messages are sent between the agent and the node. Orientation the node uses the agent discovery process to determine where it is. Care-of address assignment – the agent discovery process is the method used to tell a mobile node the care of address it should use. Once a mobile node has completed agent discovery, it knows whether it is on its home network or a foreign network. If it is at home, it communicates as a regular IP device; but if it is away, it must activate Mobile IP. The main purpose of registration is to actually trigger the activation of Mobile IP. The mobile node must contact the home agent and tell it that it is on a foreign network and request that datagram forwarding be turned on. It also must let the home agent know its care-of address so the home agent knows where to send the forwarded datagrams. Successful registration establishes a mobility binding between the home agent and mobile node. The mobile node is supposed to manage its registration and handle various events using several actions [2]: The mobile node must register when it first detects it has moved away from home. The mobile node must deregister when it returns to its home network. Finally, the mobile node must update its registration when it moves to a new foreign network or if its current registration is about to expire. Encapsulation is required because each datagram which is intercepted and forwarded needs to be resent over the network to the device’s care-of address. The default encapsulation process used in Mobile IP is called IP encapsulation within IP defined in RFC2003. It is a relatively simple method that describes how to take an IP datagram and make it the payload of another IP datagram. Two other encapsulation methods may be used: Minimal Encapsulation within IP defined in RFC2004, and Generic routing Encapsulation defined in RFC1701. To use either of these, the mobile node must request the appropriate method in its registration request and the home agent must agree to use it. The encapsulation process creates a tunnel between the device that encapsulates and the device that decapsulates. The tunnel represents a conduit over which datagrams are forwarded across the internet. In Mobile IP, the start of the
tunnel is the home agent, which does the encapsulation. The end of the tunnel depends on what sort of care-of address is used. With a foreign agent care-of address the foreign agent is the end of the tunnel. With a co-located care-of address, the mobile node is the end of the tunnel. 3.1.1 Agent Node Communication. Mobile agents are routers that have additional functionality to make them “Mobile IP aware”. There is considerable similarity between agent discovery and normal router discovery, therefore, it made sense to implement agent discovery as a modification to the existing process rather than to set up a whole new system. Provision already exists for the communication between a device on an IP network and it’s local router, in the form of ICMP messages; namely, Router Advertisement and Router Solicitation messages. The modified messages for communication between a mobile node and it’s local agent are Agent Advertisement and Agent Solicitation. The first is transmitted regularly by a router acting as a mobile agent; it consists of a regular router advertisement message with some extensions added to it. Agent Solicitation messages can be sent by a mobile node to request a local agent to send an advertisement. Two new message types have been defined in Mobile IP to perform registration: registration request and registration reply [3]. 3.1.2 Tunnelling. The diagram shown in Figure 4 below illustrates the tunnelling process used for the co-located care-of addresses1. If the mobile node moves from its home network to a foreign network, it will detect this by the agent advertisement messages it receives. It will then obtain a care of address and must inform its home agent that it is away from home and request that datagram forwarding be turned on; this creates a mobility binding. If the correspondent node sends a packet to the mobile node at its home network, this packet will be intercepted by the home agent, encapsulated and forwarded on to the mobile node’s care of address. In the case of a co-located care of address the encapsulated datagram will be sent directly to the mobile node, where it will be decapsulated. However, if a foreign agent care of address is used the datagram will be sent to the 1
The other type of tunnelling that may be used is for the foreign agent care of address and is quite similar.
foreign agent, where it will be decapsulated and sent on to the mobile node.
Figure 3.
forwarding process itself, by encapsulating a bogus datagram to trick a mobile node into thinking it was sent something that it never was. While Mobile IP includes authentication measures for registration messages, it does not for other types of messages. It also doesn't specify authentication of encapsulated datagrams being forwarded from the home agent to the mobile node. Encryption is also not provided to safeguard the privacy of either control messages or forwarded datagrams. Although the problems mentioned above are significant, however, there are some solutions provided by IPv6 to address some of them.
MIP tunnelling
3.2 mSCTP. 3.1.3 Mobile IP Issues. The biggest problem with MIP is that it will take a long time to roll out – it requires a lot of changes to the network infrastructure, and history teaches us that any technology that requires changes to the network infrastructure either fails or takes a long time to reach significant penetration (e.g. IPV6). There are some efficiency issues with MIP as all sending devices must communicate through the home agent. For example, the greatest inefficiency results when the sending device is actually on the foreign network that the mobile node is visiting, which is often the case. If the mobile node’s home network is in London and it is visiting a network in Tokyo the following process ensues: if device A is on the mobile node's current network in Tokyo, it must send all the way to London and then have the result forwarded all the way back again to Tokyo. To make matters worse, consider what happens if reverse tunneling is used, which may be convenient when the routing is dependent on the source address. Here, tunneling is done not just for datagrams sent to the mobile node but sent from it as well. In the “worst case” example, a request/reply pair from the mobile node to another device on the foreign network requires two complete round-trips from Tokyo to London and back. In terms of operation, Mobile IP has a number of risks due to it using a registration system and then forwarding datagrams across an unsecured Internet. A malicious device could interfere with the registration process, causing the datagrams intended for a mobile device to be diverted. An “attacker” might also interfere with the data
SCTP was originally designed for the transport of message based signalling information over IP networks [4]. SCTP is a reliable transport protocol operating on top of a potentially unreliable connectionless packet service such as IP. It offers acknowledged error-free nonduplicated transfer of SCTP messages. Protection of data corruption, loss or duplication of data is achieved using checksum sequence numbers. A selective retransmission mechanism is applied to correct loss and errors. SCTP transfers data units that are called chunks. The protocol determines the maximum possible size of a chunk at which IP packets can be sent to a destination without being segmented. It segments large messages into chunks that will fit into an IP packet; several small chunks resulting from small messages may be multiplexed into one IP packet by a process called bundling. SCTP flow and congestion control mechanisms have been designed specifically so that SCTP traffic behaves in the same way as TCP traffic; this allows the seamless introduction of SCTP services into existing IP networks. SCTP provides a message-oriented data delivery service; it is different to TCP, which is byte-oriented. Because of the message-oriented nature of SCTP, the application does not have to concern itself with maintaining message boundaries as these are automatically conserved. An important difference between SCTP and TCP is the support of multi-homed nodes that may be reached via several IP addresses. If one of the multi-homed node’s IP addresses fails (possibly from an interface or link failure or severe congestion), the destination host can still receive
data through an alternative source interface. SCTP keeps track of each destination address’s reachability using two mechanisms: acknowledgements of the data chunks, and heart beat chunks. Multi-streaming is a novel service that SCTP includes; an SCTP stream is a uni-directional logical dataflow within an SCTP association. The SCTP endpoints negotiate application requested streams during association setup that exist for the life of the association. Within streams, SCTP uses stream sequence numbers to preserve the data order and reliability for each data chunk; between streams, however, no data order is preserved. This approach avoids the TCP head-of-line blocking problem, in which successfully transmitted segments must wait in the receiver’s queue until the TCP sending endpoint retransmits any previously lost segments. In SCTP, if data on a stream is lost only that particular stream is blocked at the receiver while awaiting retransmission.
Figure 4.
Figure 5.
SCTP association setup
Recent work on SCTP includes the so-called ADDIP extension: this enables an SCTP endpoint to add a new IP address or delete an unnecessary IP address, and also to change the primary IP address used for the association while the association is active [5]. When events such as add, delete or change occurs during an association, the SCTP endpoint will notify the corresponding event to the remote endpoint by sending an SCTP ASCONF chunk (Association Configuration chunk). The correspondent node will then reply with an ASCONF ACK chunk.
SCTP multi-streaming
SCTP uses a four-way handshake (Figure 6) in which a cookie mechanism establishes an association that prevents blind SYN attacks. If host A initiates an association with host B, the following actions occur: Host A sends an INIT chunk to host B. When host B receives the INIT, it returns an INIT ACK to host A. This initialisation acknowledgement contains a cookie composed of information that only B can verify. The cookie helps to check if host A is legitimate. Unlike in the case of TCP, host B does not allocate any memory to maintain state for the requested association at this point, helping to prevent blind SYN attacks. When host A receive the INIT ACK it replies with a cookie echo chunk, this may contain A’s first data and as the name indicates it echoes the cookie that host B sent. On receiving the cookie echo chunk, host B checks the cookie’s validity; a valid cookie establishes hosts A’s legitimacy. Only at this point does SCTP establish the association and allocate resources at host B.
Figure 6.
Mobile SCTP
After initiation of an SCTP association the mobile node moves from the access router A to the access router B, as shown in Figure 6 above. It is assumed that the mobile node initiates an association with the correspondent node. The resulting SCTP association consists of an IP address 1.1.1.1 for the mobile node and IP address 1.1.1.3 for the corresponding node. If the mobile node moves from the access router A to the access router B and is now in the overlapping region, the mobile node will obtain a new IP address 1.1.1.2 from the access router B by using some suitable address configuration protocol. A mobile SCTP node informs its corresponding node that it will be using a new IP
address by sending it an ASCONF chunk. The mobile node receives an ASCONF ACK chunk from the corresponding node. While the mobile node continues to move towards access router B, it needs to change the new IP address to be its primary IP address according to an appropriate rule. Research has been performed using combinations of two different Add–IP rules with two different Primarychange rules. These are as follows: • Aggressive Add-IP with Aggressive PrimaryChange; • Aggressive Add-IP with Conservative Primary– Change; • Conservative Add-IP with Aggressive Primary– Change; • Conservative Add-IP with Conservative Primary-Change. Where, Aggressive Add-IP ensures that the new IP address is added to the association only if the signal strength is greater than a given threshold. The Aggressive Primary-Change sets the threshold higher than the Conservative Primary-Change. Conservative Add-IP ensures that a new IP address is added to the association if its signal strength is greater than those for the current IP address. As the mobile node progresses to move toward the access router B, if the old IP address becomes inactive, the mobile node must delete it from the address list [6]. 3.2.1 SCTP Issues. The key issue with mSCTP is that SCTP is not used by applications, hence to have mSCTP used in widespread fashion would involve modifying lots of applications. The protocol can also be inefficient if the mobile node keeps moving back and forth between two bases. Signalling is required for every correspondent node when a mobile node changes its network attachment point: this can result in a lot of overhead if there are many correspondent nodes. Both endpoints must support mSCTP which again would require changes in the network terminals. However, it is significantly easier to implement changes to the terminal than to the network infrastructure, as in the case of Mobile IP. The simultaneous handover of two correspondent nodes, although possible, may lead to the loss of the connection. Simultaneous handover is problematic as each node is unable to inform the other about its address change. This
problem can be addressed with the use of other location management mechanisms such as MIP and dynamic DNS.
3.3 TCP Migrate. TCP Migrate is an end-to-end architecture for Internet host mobility. It uses dynamic updates to the domain name system to track host location and has functionality to enable the handover of existing TCP connections [7]. Existing TCP connections are retained using secure and efficient connection migration, enabling established connections to negotiate a change in end point IP addresses without the need for a third party. The architecture is secure – name updates are effected via the secure DNS update protocol, while TCP connection migration involves the exchange of a new set of specifically designed migrate options. It provides a pure end-system alternative to routing based approaches such as Mobile IP. To locate mobile hosts as they change their network attachment point, TCP Migrate takes advantage of the widely deployed domain name system and its ability to support secure dynamic updates. Because most Internet applications resolve hostnames to an IP address at the beginning of a transaction or connection, this approach is viable for initiating new sessions with mobile hosts. When a host changes its network attachment point, it sends a secure DNS update to one of the name servers in its home domain updating its current location. The name-to-address mappings for these hosts are uncachable by other domains, so stale mappings are eliminated. The ability to support continuous communication during periods of mobility without modifying the network infrastructure is a more challenging problem. Two communicating peers must securely negotiate a change in the underlying network layer IP address and then seamlessly continue communication. A new TCP option was designed to support the secure migration of an established TCP connection across an IP address change. The Migrate option allows hosts to divert established TCP connections to a new IP address/TCP port pair by referencing them with a cryptographic token. Security is achieved through the use of this connection identifier or a token, which may be secured by a shared secret key negotiated through an ECDH key exchange during initial connection
establishment. It requires no third party authenticate migration requests, thereby allowing the end-points to use whatever authentication mechanism they choose to establish a trust relationship. TCP Migrate proves it is possible to implement mobility as an end-to-end service without network layer support. 3.3.1 Addressing. The key to the scalability of the Internet architecture is that the IP address serve as a routing locators, reflecting the addressee’s point of attachment in the network. This enables aggregation based on address prefixes and allows routing to scale well. IP addresses are used to identify the mobile host; when a mobile host moves from one WLAN to another, it loses it’s old IP address and therefore needs to obtain a new one. TCP Migrate separates the issues of obtaining an IP address in a foreign domain from locating and communicating with mobile hosts. Any suitable mechanism for address allocation may be employed such as manual assignment, the dynamic host configuration protocol or an auto-configuration protocol. TCP Migrate does not require any forwarding or reverse tunnelling to maintain seamless connectivity. Since no triangle routing anomalies are imposed, end-to-end latency for active connections is better than standard Mobile IP. In a foreign network a mobile host uses a locally obtained interface address valid in the foreign domain as its source address while communicating with other Internet hosts. 3.3.2 Mobile Host Location. Once a mobile host obtains an IP address, there are two ways in which it can communicate with correspondent hosts. Firstly, as a client, when the mobile host actively opens connections to the correspondent host. In this case, there is no special host location task to be performed, simply using the DNS as before works [9]. If a mobile host were always a client, then no updates need to be made to any third party such as a home agent or the DNS. To support VoIP like services and other applications where Internet hosts actively originate communication with a mobile host, the DNS is used to provide a level of indirection between a host’s current location and an invariant end-point identifier. TCP Migrate is not a network layer solution and can avoid the indirection for every packet. It takes advantage of the fact that a hostname lookup is ubiquitously done by most
applications that originate communication with a network host, and use the DNS name as an invariant. A DNS name identifies a host and does not assume anything about the network attachment point to which it may be attached. The indirection occurs only when the initial lookup is done via a control message. When a mobile host changes its attachment point, it must detect this and change the hostname-to-address mapping in the DNS. To avoid a stale mapping from being used from the DNS name cache, the time to live field for the mapping is set to zero, which prevents it from being cached. 3.3.3 Connection Migration. In order to facilitate secure and efficient connection migration a new Migrate TCP option was proposed. This option was included in SYN segments, and identifies the SYN packet as part of a previously established connection, rather than a request for a new connection (Figure 7). This Migrate option contains a token that identifies a previously established connection on the same destination pair. The token is negotiated during initial connection establishment through the use of a Migrate-permitted option. After a successful token negotiation, TCP connections may be uniquely identified by either their traditional 4-tuple or a new triple on each host. A mobile host may restart a previously established TCP connection from a new address by sending a special Migrate SYN packet that contains the token identifying the previous connection (communication line 2 in Figure 8 below). The fixed host will then re-synchronise the connection with the mobile host at the new end point (communication line 3 in Figure 8 below). A migrated connection maintains the same control block and state (with different end points), including the sequence number space, so any necessary retransmissions can be requested in the standard fashion. This also ensures that SACK and any similar options continue to operate properly.
It is not possible for both endpoints to simultaneously change their network attachment points as this action would lead to the loss of connection. Again there is the issue of making changes to the network terminals in order to make them TCP Migrate enabled.
4. Simulation Work.
Figure 7.
Connection migration
Any options negotiated on the initial SYN exchange remain in effect after connection migration and need not be resent in a migrate SYN. However, they can be if needed. For example it might be useful to renegotiate a new maximum segment size reflecting the properties of the new path.
The performance of networking protocols can be analyzed and optimized efficiently using the tools provided by the QualNet simulation tool. A library of protocol models in source form is provided, so developers can build new network functionality. The version being used in this research has a SCTP module; however there is no support for the operation of TCP Migrate. Before simulation of TCP Migrate begins a suitable module must be written and patched into the existing QualNet simulator. Simulations will be performed on the operations of both mSCTP and TCP Migrate using models of applications such as Skype Voice over IP. Following the completion of the simulation of both protocols, a comparative analysis based on metrics such as handover latency, throughput or delay will be carried out.
4.1 Preliminary simulations. Several tasks have been completed before preliminary simulations of mSCTP handover for this document could be performed and various other tasks must still be completed for future simulations of TCP Migrate handover, including: Figure 8.
TCP Migrate handover
3.3.4 TCP Migrate Issues. The problems with TCP Migrate include the high latency that can be involved in it’s handover procedure. Before resuming communication, the congestion-related state of the TCP connection must be reset to initial slow-start conditions in order to re-discover the properties of the new path in both directions; this may lead to handover latency. Also, the fact that TCP is mainly used for non delay sensitive traffic such as file transfer may cause some issues; however, Skype uses TCP in certain cases – and it would be interesting to simulate the operation of Skype using TCP Migrate.
4.1.1 TCP Migrate module. Code to implement the TCP Migrate protocol must be written and patched into the existing simulation tool. Work has begun on the implementation of the Migrate Permitted and the Migrate options; however, this task is in the early stages of development and is not yet mature enough to facilitate the execution of experiments. 4.1.2 Scenario design. The design of logical and appropriate simulation scenarios is necessary in order to generate realistic and valid simulation results. Figure 9 below depicts the scenario design decided upon for preliminary simulation experiments. This scenario consists of various network components; three wireless access points;
and two terminal hosts, all connected to two wireless subnets. The mobile node, illustrated with the laptop image, is multi-homed with interfaces connecting it to two wireless APs operating on different channels. The correspondent host is connected to a third wireless access point, and it communicates with the mobile node using a specially designed application called GENERIC/FTP over SCTP. The location of each node shown below is approximately the same as the coordinates specified in the node placement file of the simulation scenario, the values along the x and y axes are representing hundreds of meters. The wireless technology being modelled is 802.11b, the default coverage area of which is 378m, ensuring that the coverage areas of access point A and B are overlapping.
Figure 9.
Simulation scenario
The mobility model incorporated in the experimental scenario involves the mobile node traveling in a straight line from access point A to access point B, covering a distance of 500m in 1500sec or 25mins, giving an average velocity of 20m/min. The reasoning behind such slow speeds stems from the default heartbeat mechanism implemented as part of the SCTP protocol. The default HB interval used in the protocol is 30s; this, combined with the default HB error threshold of 6 (the number of consecutive times a heartbeat is not acknowledged before it is declared inactive) exposes SCTP handover to extremely significant latencies. Therefore, in order to ensure that a successful handover is possible, the mobile node must be positioned in the overlapping region of two APs for a period of at least 180s or 3min. 4.1.3 Running simulations. Determining a correct simulation configuration is an important aspect, which has a direct effect on the quality of the
results obtained. The simulations performed in the course of this initial research into the handover performance are basic and the corresponding results preliminary. The configurations and techniques employed are not optimal, but rather, used to obtain results from which we can refine our simulations with the view of improving the overall handover performance. The main concession made in the course of the simulation work is the unsophisticated method by which the mobile node discovers the inactivity of it’s primary wireless interface. The rfc contains no definition of how this functionality should be implemented and it therefore poses an interesting research problem. However, due to the preliminary nature of this work, the inactivity of the primary wireless link is detected by the remote correspondent node using heartbeat chunks. The remote node then reports this event to the mobile node by sending it an InactivePrimary Chunk. The receipt of this chunk triggers the mobile node to send an Asconf Chunk instructing the correspondent node to update the association’s address list by setting an alternative specified address as the primary destination address. Despite our interest in simulating handover using VoIP traffic, for the sake of convenience, we opted to use GENERIC/FTP/SCTP. This application is a modification to the GENERIC/FTP application, which has been adapted to run over SCTP by facilitating multistreaming. 4.1.4 Obtaining and analysing results. The scenario detailed previously was run five times, using a different random seed each time. Packet trace and statistics files were generated for each execution and used to determine delay incurred during handover. The simulation length was set to 3000s with the application starting at 800s and the source of communication being the stationary node. The heartbeat interval was set to be 10s. The results obtained from these simulations indicated that the detection of inactivity of a wireless interface took on average approximately 1000s. When the peer failure occurs the DATA chunk sent to the destination addr1 will cause a timeout at endpoint A. This timeout event will increase the total error counter of the peer by one and will trigger the retransmission of the chunk to
destination addr2. This will also cause the RTO of the first address to be doubled. Similarly, this retransmission to addr2 will time out, and the events described above will be repeated again and again, each time with longer RTOs an increased error values. Finally the error counter will exceed the value of the associations max retransmission and the endpoint is declared unreachable. This figure indicates that both the HB interval and the HB error threshold may need to be tuned and in setting optimal values for these parameters may offer significant reduction in the handover latency. One other observation is that, when the mobile node enters the overlapping region, the corresponding node continues using the current primary address, until the mobile node tells the corresponding node to change the primary address. During this time, the data chunks could not be transmitted to the old primary address as the link is not strong enough, which causes reduction in congestion window value and retransmissions. The basic simulation work carried out and detailed in this document helped to identify possible improvements to be made to the SCTP protocol. The latency times experienced are sufficient indications that the performance of the SCTP handover needs to be significantly improved to provide the continuous connectivity required to support real time applications during periods of mobility. The selection policy for the temporary primary destination address is not specified in the SCTP protocol and is an implementation decision. In the SCTP implementation used for this work we assume that all the data chunks marked for retransmission will go to the same alternate destination. Thus, some of the data chunks might go to the same destination as their original with this strategy. This technique is suboptimal in its selection of an alternative destination address, where to send the rtx chunks remains a research issue. The previously mentioned implementation of measuring the health of wireless links is obviously suboptimal; clearly, detection of the inactivity of a link, when performed locally, would be significantly quicker than a remote host reporting the link failure. Therefore, by incorporating some cross layer communication, where the mobile node queries the health of a link from the lower layers, would provide significant performance improvements.
5. Conclusions. A network layer handover solution has the important advantage in that it does not require changes to the applications – however, it has significant problems in that it requires substantial changes to the network infrastructure. For this reason, it is interesting from a research perspective to study the transport layer options. Two transport layer options have been presented, each having some advantages and disadvantages. Both are possibly suited to different cases or different types of traffic. For example, TCP Migrate may be used for non delay sensitive traffic such as FTP or HTTP, while mSCTP may be used for new applications with/without delay sensitive characteristics. The handover problem poses an interesting research prospect and we plan to carry out some simulation work in the next few months. Preliminary results obtained are a positive indication that more research is needed in this area and that significant improvements may be obtained. Acknowledgement The support of the Informatics Research initiative of Enterprise Ireland is gratefully acknowledged.
References [1] D. C. Lynch and M. T. Rose (eds.). Internet System Handbook. Addison-Wesley, 1993. [2] Perkins, C.E., Mobile networking through Mobile IP, IEEE Internet Computing, Volume2, Issue 1, Jan – Feb. 1998 [3] Andrew S. Tanenbaum, Computer Networks, Fourth Edition. Prentice Hall 2003. [4] C. Perkins, “IP Mobility for IP v4, revised” RFC 3220, January 2002 [5] R. Stewart, “Stream Control Transport Protocol” RFC 2960, October 2001 [6] M Riguel, M Tuexan, “Mobile SCTP”, draft-riegeltuexen-mobile-sctp-01.txt [7] Seok Joo Koh; Moon Jeong Chang; Meejeong Lee; mSCTP for soft handover in transport layer, IEEE Communications Letters Volume 8, Issue 3, March 2004 [8] AC Snoeren, H Balakrishnan, An end-to-end approach to host mobility, 6th ACM/IEEE International Conference on Mobile Computing and Networking (MobiCom ‘00) [9] W. Stallings. Data and Computer Communication, Seventh Edition. Macmillan, 1988.
