Aalborg University Institute of Electronic Systems - Communication Networks - 6th Semester

Transcription

1 Aalborg University Institute of Electronic Systems - Communication Networks - 6th Semester TITLE: Experimental Analysis of Mobility Support Schemes for Vertical Handover SUBJECT: Basic Wireless Communication PROJECT PERIOD: 2/ / PROJECT GROUP: 681 GROUP MEMBERS: Thorbjørn Haack Jørgensen Lars Bonde Pedersen Synopsis ***: Skriv noget i synopsisen SUPERVISORS: Hans P. Schwefel NUMBER PRINTED: NUMBER OF PAGES: 83 APPENDIX: XX pages and 1 CD

2

3 Preface This project is made by group 681, during the 6th semester of the Communication Network line at Aalborg University. The semester theme is Basic Wireless Communication. The report is aimed at the censor, the supervisors of the group and other technical students. References to the bibliography are numbered sequentially, as shown in the following example. Reference: The specification of the extended capabilities port is written according to [4]. Bibliography: [4] Interfacing the extended capabilities port, Figures and Tables are indexed according to the chapter number. Hence Figure 5 in Chapter 7 is denominated Figure 7.5. Footnotes 1 are numbered sequentially throughout the chapters. In the report the following notations are used. Hexadecimal numbers: 0x20FF (example) Active-low (electronics): HostClk (example) The enclosed CD contains the program code, a copy of the report in portable document format (PDF), as well as... Thorbjørn Haack Jørgensen Lars Bonde Pedersen 1 Example footnote. 3

4

5 Contents 1 Introduction 17 2 Preliminary analysis What is a handover? Horizontal handover Vertical handover Mobility techniques Analysis Mobility at the network layer Migrating IP Mobile IP Mobility at the transport layer Stream Control Transmission Protocol (SCTP) Extending SCTP for mobility Why use transport mobility Mobility at the application layer Session Initiated Protocol (SIP) Why use application layer mobility Key features Delimitation of mobility techniques Mobility in reality Why and when to do a handover? Mobility applications Mobility interfacing

6 6 CONTENTS 4.2 Use cases Migrating IP Mobile IP applications SCTP applications Experimental implementation and measurements Implementation notes Interfaces for measuring Operating system Migrating IP Setup Design Implementation Measurement scenarios Results Mobile IP Setup Design Implementation Measurement scenarios Results Conclusion Results Definitions Handover time Statistic Migrating IP A single sample All measurements Conclusion

7 CONTENTS 7 Bibliography 82 Appendices 83 A Preliminary measurement 85 B Routing in an Ethernet 87 C Address Resolution Protocol 89 C.1 ARP and gratuitous ARP C.2 ARP packet structure D Mobile IP packets 93 D.1 Mobile IP D.1.1 Agent Advertisement D.1.2 Registration E SCTP packets 97 E.1 SCTP header and chunks E.1.1 Payload data E.1.2 INIT E.1.3 INIT ACK E.1.4 SACK F Source code 103 F.1 Migrating IP script

8

9 List of Figures 1.1 Features of mobile generations Example of a 4G network Horizontal handover between two antennas Vertical handover between a GPRS and a WLAN network Horizontal VS vertical handover MIP and Migrating IP are operating on Layer 3 in the OSI model Scenario using migrating IP to mobility within a subnet A MN in its home network A MN in a foreign network Sequence diagram of a packet transfer between a fixed CN and a MN. This sequence diagram is adapted to the network shown in Figure An IP in an IP packet A minimal IP encapsulation The sequences of retrieving a COA and register it on the HA The structure of an Agent advertisement The registration process over a FA The registration process between a MN and a HA MIP running on an IPv6 network SCTP operates on Layer 4 in the OSI model SCTP packet construction SCTP association SCTP initialization packet flow SCTP streams SCTP data and retransmission packet flow

10 10 LIST OF FIGURES 3.19 SCTP packet flow example SCTP packet flow example SCTP packet flow example SIP operates on Layer 7 in the OSI model Example of data communication using SIP A single subnet with several access points using different network technologies MIP scenario where FA decapsulation is used MIP scenario where MN decapsulation is used VoIP scenario with SCTP mobility support Gaming scenario with SCTP mobility support Salesman scenario with SCTP mobility support Setup to test Migrating IP Activity diagram for the migrating script MIP setup Bluetooth (bnep0) to WLAN (eth1) migration WLAN (eth1) to Bluetooth (bnep0) migration Design of MIP agent software Home Bluetooth to Home WLAN setup Home Bluetooth to foreign WLAN setup Home WLAN to foreign WLAN setup MIP FA decapsulation packet flow Packet flow during a handover from a Bluetooth to a WLAN connection Packet flow during a handover from a WLAN to Bluetooth connection Histogram showing A.1 Test setup of the preliminary measurement B.1 An example network with router, switch and ARP cache tables C.1 Sequence of an ARP request and reply C.2 Sequence of a gratuitous ARP request

11 LIST OF FIGURES 11 C.3 Packet structure of an ARP request D.1 The structure of an Agent Advertisement D.2 The structure of the registration request fields in a UDP packet D.3 The structure of the registration reply fields in a UDP packet E.1 SCTP packet structure E.2 SCTP Payload packet structure E.3 SCTP INIT packet structure E.4 SCTP INIT ACK packet structure E.5 SCTP SACK packet structure

12

13 List of Tables 1 Nomenclature of frequently used symbols in the report Comparison of features of the 4 techniques analyzed in this chapter Comparison of WLAN, Bluetooth and GPRS Handover times measured in 6 experiments Details regarding BT to WLAN handover D.1 Registration reply codes (Sch03) E.1 Description of ID values

14

15 Nomenclature Frequently used symbols is introduced in Table 1. 15

16 16 LIST OF TABLES Symbol Abbreviation Description MN Mobile Node CN Corresponding Node Smart phone using several network interfaces HA/FA Home Agent and Foreign Agent Stream server Database server Layer 2 switch Router (layer 3) Access Point Antenna for mobile phone communication Table 1: Nomenclature of frequently used symbols in the report.

17 1Introduction People have always had a need to communicate, and through time our needs have expanded. In the beginning communication was made from mouth to mouth, but over time techniques to communicate over distances have been developed, from smoke signaling to telegraph lines. Today it is possible to get in contact with almost everybody anywhere. The ways to communicate has also expanded, so today there is a wide range of possibilities, from text messages, to voice and even video telephony. All the new technologies have made the users of the systems more critical about what they expect from a communication system, they want more and more services available no matter where they are. In Europe the mobile communication system have evolved through different generations. The generations has given the user more and more possibilities fore reliable communications, and expanded the number of services available for the user. Generations Analog Telephony Digital Telephony Digital Data Constant Connectivity Mobile Voice Telephony Short message service Low speed data transfer High speed data Multimedia applications Services avaliable always Nordic Mobile Telephone (NMT) Global System for Mobile communication (GSM) Universal Mobile Telephony Service (UMTS) Various Wireless Technologies Figure 1.1: Features of mobile generations. The first generation gave users opportunity to make calls from mobile phone. The second generation expanded this idea and introduced other simple data services, like short message service. Third generation gives the user high speed data on the mobile phone; which will make it possible to make Video calls. Fourth generation will bind different wireless technologies together, as shown in Figure 1.2, so the user always will have access to the fastest or the cheapest connection. The fourth generation mobile network is still under development, and different kind of problem will have to be solved. The switch between wireless technologies is one of the problems. For the end user the switch will have to be seamless, and different kind of existing techniques can be used for this approach. ***: hvilke? du tænker på MIP osv.? The purpose of this project is to investigate performance when a handover is performed between two types of wireless technologies. It is important that handovers are performed seamless to the user. Interruptions in data or speak streams is often unacceptable, hence the han- 17

18 18 Chapter 1. Introduction IP backbone GMS/GPRS WLAN Satellite Figure 1.2: Example of a 4G network. dover time must be measured in order to evaluate if the handover is seamless to the user 1. ***: definer ordet seamless If the measurements show the need of improvements, suggestions will be made for a possible optimal solutions. ***: gør vi dette? The measurements are conducted experimental and by using existing technologies regarding hardware as well as software. Initiating problem: Experimental measurements of the performance during handover between two types of wireless technologies. ***: Chapter descriptions 1 The term seamless dependent heavily on the application and will be defined in the report

19 2Preliminary analysis In this section the difference between vertical and horizontal handover will be stated. This definition is henceforth used in this project. Also some mobility techniques will be presented, which will be analysed in Chapter What is a handover? A handover is in this project defined as the event where a connection is passed on to another provider. The term provider is split into two groups Horizontal handover Vertical handover Horizontal handover Horizontal handover occurs for example when a cellular phone connection is performed while driving in a car, as shown in Figure 2.1. First, the cellular phone is within range of the shaded antenna. When it moves to the right it has to switch to the other antenna in order to stay connected. The communication technology within the network is the same. This type of networks are also called homogeneous. The horizontal handover is not the topic of this project. As described in the project proposal we are interested in the vertical handover Vertical handover The term handover will in the remaining of the report denote vertical handover. In contrast to the horizontal handover where the communication technology is the same all over the network this is not the case when a vertical handover is performed. The main reason for changing communication technology may be to achieve higher bandwidth or to use a less expensive communication technology. 19

20 20 Chapter 2. Preliminary analysis Figure 2.1: Horizontal handover between two antennas. Figure 2.2 shows a scenario where the WLAN technology is advantageous, for example due to higher bandwidth. Whenever the laptop is within range of the WLAN (shaded area) this connection should be used. When the laptop is out of range of the WLAN, the GPRS technology must be used in order to remain connectivity. Often networks consisting of more than one communication technology is denoted heterogeneous networks. GPRS WLAN Figure 2.2: Vertical handover between a GPRS and a WLAN network. The vertical handover is the scope of this project, or more precisely, the performance of technologies used in performing the vertical handover.

21 2.2 Mobility techniques 21 Figure 2.3 shows the relation between vertical and horizontal handovers. When the network technology is changed during the handover, it is denoted vertical. In contrast, if the network technology is the same before and after the handover, it is denoted horizontal. Satellite Vertical handover GMS/GPRS WLAN Horizontal handover ***: Section about obtainment of IP address Figure 2.3: Horizontal VS vertical handover. 2.2 Mobility techniques This section present 4 different ways out of several to gain mobility in a network. The techniques operate on different layers in the OSI model and have different requirements to the network in order to operate. Also the usefulness is rather different. The 4 techniques are Migrating IP Mobile IP SCTP Session Initiated Protocol In Chapter 3 an analysis will be performed in order to gain knowledge about how the mobility techniques operate.

22

23 3Analysis In this chapter different protocols for handling mobility in IP networks, will be analysed. The protocols will be split into the layers they are operating on. First mobility on the network layer will be analysed in terms of Mobile IP and Migrating IP. Next SCTP will be analysed, which operates on the transport layer. Finally the Session Initiated Protocol operating on the application layer will be analysed. 3.1 Mobility at the network layer To achieve mobility at the network layer, different techniques can be used - for example Mobile IP (MIP) or Migrating IP. The basic concept of both techniques is to keep the same IP address throughout communication. The usefulness of MIP is higher than Migrating IP, since the latter only offers mobility within a single subnet, hence the physical distance may be limited. MIP on the other hand is designed for offering mobility even on a worldwide scale. Figure 3.1 shows, that MIP and Migrating IP operate on Layer 3, the network layer, in the OSI model implying that the layers above are unaffected though communication is mobile. MIP or Migrating IP may affect Layer 2, the data link layer. The data link layer is responsible for link establishment and maintenance, thus a change in the signal/interference ratio may occur when the mobile node is moving around. Most likely nodes which are using the MIP or Migrating IP moves quite often which may cause the data link layer to establish new connections all the time. In the following sections these two techniques will be analysed Migrating IP Migrating an IP address from one network interface (NIC) to another can gain mobility, but only within the subnet. This is the main reason why Migrating IP often is not used for mobility purposes but for server redundancy instead. An implementation of a migrating IP scenario which could be used to achieve a higher level of mobility within a subnet is shown in Figure

24 24 Chapter 3. Analysis Upper layers (Layer 5, 6 and 7) Transport layer (Layer 4) Network layer (Layer 3) Data link layer (Layer 2) Migrating IP Mobile IP Physical layer (Layer 1) Upper layers (Layer 5, 6 and 7) Transport layer (Layer 4) Network layer (Layer 3) Data link layer (Layer 2) Figure 3.1: MIP and Migrating IP are operating on Layer 3 in the OSI model. Subnet WLAN access point BT access point WLAN (Eth0) BT (Eth1) VIP: Figure 3.2: Scenario using migrating IP to mobility within a subnet.

25 3.1 Mobility at the network layer 25 The laptop has two NICs (Eth0 and Eth1) which can be used for access to the network. Each NIC has a unique MAC (Media Access Control) address which is coded in a chip on the NIC. Also IP addresses have been assigned to both NICs (Eth0: ; Eth1: ). Additionally a virtual IP (VIP) address has been obtained ( ). The VIP is the destination address of packets sent to the laptop, so the VIP can only be assigned to one NIC at a time. Using a VIP makes it very easy and fast to migrate between interfaces, since no IP obtainment procedure is needed, only a information packet to the other nodes telling about the new association of the VIP is needed. In Figure 3.2 Eth0 is selected as the primary NIC, hence VIP is assigned to this interface. The NICs are connected to access points, as shown in Figure 3.2, which again are connected to the subnet. A router may connect the subnet with other subnets. If the link to the WLAN access point fails or the quality is low and the link to the BT access point still remains, Eth1 must take over connectivity impling that the VIP must be assigned to Eth1. In order to inform other nodes and routers that the VIP has been assigned to Eth1 we use a technique called gratuitous ARP, which is described in Appendix C. Gratuitous ARP is simply an ARP request asking who owns the IP address of itself. The ARP packet is broadcasted as a request, although it contains all needed information to update routers and nodes connected to the subnet. When a node or a router receives this kind of ARP request they update their ARP cache hereby linking the MAC address of Eth1 to the VIP (unless the router/nodes are configured not to support gratuitous ARP since gratuitous can be used to perform ARP spoofing) which is the desired effect. After the broadcast all nodes will henceforth route the packets to Eth1 instead of Eth0, hence it is again possible to communicate with the laptop Mobile IP Mobile IP is one of several ways to achieve mobility in a network. One of the pioneers in developing Mobile IP (MIP) is Charles E. Perkins. In (Per98) he describes the goal of Mobile IP as follows: The major goal of Mobile IP protocol design was to handle mobility at the network layer and to leave transport and other higher layers unaffected, so that the existing routing infrastructure, nonmobile hosts, and current applications would not be required to change. The MIP protocol has been developed to coexist with today s networks, nevertheless additional infrastructure nodes must be added to the network in order to achieve mobility. These nodes will be described in Section Some software must also be installed on the mobile node in order to ensure that it operates as a mobile node. Some of the concepts of MIP will be described in the next section.

26 26 Chapter 3. Analysis The elements in a Mobile IP network MIP has introduced many new terms. Some of the most fundamental of these will now be described. Mobile Node (MN) is a node which may change its point of attachment to the network during normal use. Correspondent Node (CN) is the node which communicates with the MN. The CN can be a fixed or mobile node. Home network is the subnet the MN belongs to. No MIP support is needed within the home network. Foreign network is a subnet the MN is visiting. Home Agent (HA) is a node on the home network holding the home address for the MN. A HA can also be implemented in a router, which is the optimum solution since packets have to pass the router anyway. Foreign Agent (FA) is a node on the foreign network which the MN is attached to. The FA can help the MN in receiving packets from its home network. Care Of Address (COA) is an IP address from the network which the MN is currently attached to. All packets sent to the MN are delivered to its COA. The delivery is done using tunneling, which will be described in Section The COA marks the tunnel endpoint. COA s can be split into to groups: Foreign agent COA: The COA could be located at the FA, i.e. the COA is the address of the FA. The FA forwards the packets to the MN. Co-located COA: The COA is co-located if the MN temporarily have an additional IP address which acts as COA. The endpoint of the tunnel is therefore the MN, which implies that FAs are not needed. Home Address (HADD) is an IP address assigned to the MN making it logically appear attached to its home network. Foreign Address (FADD) is an IP address assigned to the MN when it is connected to a foreign network Common Mobile IP scenarios The basic terms of MIP have been defined, and will be used in the following scenarios regarding MIP, to explain the pratical use of the protocol.

27 3.1 Mobility at the network layer 27 Figure 3.3 shows a scenario where a MN is located in its home network. A CN wants to send a data packet to the MN. The CN knows the HADD of the MN. This implys that the packet is sent to the HA, or in case of a co-located COA, is sent directly to the MN. The packet can be replied as usual. In this scenario the communication is almost as usual when two nodes are communicating. MN HA Internet CN Figure 3.3: A MN in its home network. Foreign Network Home Network 1 HA COA 2 Internet FA 3 MN CN 4 Figure 3.4: A MN in a foreign network. Figure 3.4 shows a scenario where a MN is located in a foreign network. The network consists of a home network and two foreign networks. The MN is attached to a foreign network, and there has been established a tunnel between the HA and the FA. A CN (assumed to be a fixed node) is connected to another network and wants to send a data packet to the MN. A sequence

28 28 Chapter 3. Analysis diagram of the the sending procedure of this particular scenario is shown in Figure 3.5. The current address of the MN is unknown to the CN, but it does not matter, since the address to the HA is known. The packet is sent to the HA (marked 1 in Figure 3.4), with HA s IP address as destination and CN s address as source. CN HA FA MN Transmits packet Tunnels Forwards [Time] Reply Figure 3.5: Sequence diagram of a packet transfer between a fixed CN and a MN. This sequence diagram is adapted to the network shown in Figure 3.4. ***: Ret transmit til send på figuren When the packet is received at the HA it knows, that the MN is not within its home network. Therefore the packet is tunneled to the COA address, in this example the IP address of the FA (2). The data packet is encapsulated in an IP packet. This implies, that the original data packet now has two IP headers, see Section for details. When the tunneled packet is received at the FA the outer IP header is removed and the original data packet is forwarded (3) to the MN (the original data packet has the MN s HADD as destination and CN as source). This procedure ensures that the MN is unaware of the forwarding which has occurred, since the packet is received as a usual packet. It might seem straightforward to return a data packet to the CN. Nevertheless, sending a packet with a source address not matching the subnet it is sent from raises security issues, which will be described in Section For now it is assumed that the MN can send the packet directly to the CN without any problems (4). The routing performed in the situation in Figure 3.4 is called triangular routing since the packets are routed in a triangular manner Tunneling A tunnel is a virtual pipe for data packets between the entry and the endpoint of the tunnel. In MIP forward tunneling is mandatory in order to send between the HA and the COA of

29 3.1 Mobility at the network layer 29 the MN. Often also reverse tunneling is used, since this concept solves some problems which emerges in MIP. In the following sections forward and reverse tunneling will be reviewed Forward tunneling In Figure 3.4 a tunnel was established between the HA and the FA. Sending packets through a tunnel is achieved by encapsulation. The original data packet is encapsulated in a new packet, in this case an IP packet. Two ways of encapsulation will be described which is used in MIP: IP-in-IP encapsulation Minimal encapsulation IP-in-IP encapsulation IP-in-IP encapsulation is mandatory for MIP (Sch03). This encapsulation scheme is also the easiest to perform, since the original packet is just encapsulated in a new IP packet. The structure of an encapsulated packet is shown in Figure 3.6. The structure of the IP headers is almost like the usual IP header. The fields of the outer IP header have no special meaning for MIP except the TTL (Time To Live) and IP-in-IP. The TTL must be high enough so the packet can reach the endpoint of the tunnel. The IP-in-IP field indicates the type of protocol encapsulated in the IP packet. The type is set to 4, which is the code for an IP ver. 4 packet. The tunnel entry (the HA) is the source address of the outer IP header. The destination address is the tunnel exit (the COA). The inner IP header (shaded fields) is almost unchanged compared to the original packet. The TTL is decremented by 1. This means that the whole tunnel is considered as a single hop from the original packet s point of view. This implies that the MN can behave as if it was attached to its home network. Finally the payload follows. Minimal IP encapsulation The IP-in-IP encapsulation consists of a great part of redundancy. In order to optimize the encapsulation header size the minimal encapsulation has been developed. The minimal encapsulation in MIP is optionally. The structure of a minimal encapsulation is shown in Figure 3.7. The outer header is almost identical to a usual IP header. The field Min. encap which contains information about the encapsulated header type is set to 55 for minimal encapsulation protocol. The inner header (shaded fields) is quite different. The first field of the inner header is Layer 4 protocol field which contains information about the protocol type of the payload. An S field follows. If S is set, the original address of the CN is included. The IP checksum is as usual. No field for fragmentation offset is left in the inner header which implies, that minimal encapsulation does not work with already fragmented packets Reverse tunneling It might seem straightforward to send an answer from the MN back to the CN in Figure 3.4 (marked 4). This is not necessary the case. Often firewalls

30 30 Chapter 3. Analysis Ver. IHL DS (TOS) Length IP identification Flags Fragment offset TTL IP-in-IP IP checksum IP address of HA Care-of address (COA) Ver. IHL DS (TOS) Length IP identification Flags Fragment offset TTL Layer 4 protocol IP checksum IP address of CN IP address of MN TCP/UDP/... payload Figure 3.6: An IP in an IP packet Ver. IHL DS (TOS) Length IP identification Flags Fragment offset TTL Min. encap IP checksum IP address of HA Care-of address (COA) Layer 4 protocol S Reserved IP checksum IP address of MN Original sender IP address (if S=1) TCP/UDP/... payload Figure 3.7: A minimal IP encapsulation.

31 3.1 Mobility at the network layer 31 protect the Internet connections by checking both incomming and outgoing traffic. A common task is to check that the source address is topologically correct. If this is not the case, the firewall may discard these packets since they often are considered as being malicious. Consinder for example if the network the MN is connected to is protected by a firewall. When the MN sents a packet to a CN in another network, the source address is not topologically correct, hence the packet will be discarded by the firewall. The same problem occurs if a MN sents a packet to a node within its home network. The firewall protecting the home network discovers that the source address of the packet belongs to the network it is protecting, hence the packet is discarded. This technique is called IP spoofing and is frequently used by hackers. As another example consider the TTL field of the IP packet. When the MN is in its home network the TTL is set to a certain value. When the MN moves to a foreign network the TTL should be increased. But if it is necessary to adjust the TTL when moving around in the network, the mobility is not transparent any more, which was one of the goals of MIP. The solution to all these problems is reverse tunneling, which is an extension to MIP. Reverse tunneling is performed in the same way as forward tunneling. This implies that reverse tunneling also causes a triangular routing problem in the reverse direction. The reverse tunneling is set up between the FA (or MN in case of co-located COA) and the HA, since the CN should not deal with decapsulation of the packet. The introduction of tunnels raises several security issues, tunnels can for example be hijacked, hereby enabling intruders to enter the network. The security issues have not been solved yet (Sch03), however IP version 6 provides new techniques to handle mobile communication, that will solve some of these issues, see Section Agent discovery and registration When the MN moves around and shifts network, it has to connect to another FA. Before doing this the MN must discover that it has moved. These problems are dealt with in the agent discovery part of the MIP standard. The agent discovery is split into two groups: Agent Advertisement (AA) Agent Solicitation (AS) In Figure 3.8 the process of retrieving a COA and register it on the HA is illustrated. The discovery of a FA is accomplished by receiving an Agent Advertisement, which is broadcasted in a subnet on regular basis. If the MN is too impatient to wait for an Agent Advertisement an Agent Solicitation can be sent from the MN. These concepts will be discussed in the following subsections. When a COA address has been retrieved, the MN has to register it on the HA. This is accomplished during registration.

32 32 Chapter 3. Analysis MN FA AS MN AA FA AA Registration Request Registration Request [Time] Registration reply Registration reply a Sequens diagram of an Agent Advertisement b Sequence diagram of an Agent Solicitation Figure 3.8: The sequences of retrieving a COA and register it on the HA Agent Advertisement Foreign and home agents advertise there presence periodically using a special agent advertisement packet. The advertisement packets are broadcasted into the subnet and are based on an Internet control message protocol (ICMP) with some extensions - the packet structure is shown in Figure 3.9. The none shaded part of the structure in Figure 3.9 is the structure of the ICMP packet. The shaded part represents the mobility extension. The IP packet carrying the ICMP packet is configured as follows: The TTL is set to 1 in order to avoid forwarding the packet. Also the destination address of the IP packet is set to either multicast address for all systems on a link or broadcast address The configuration of the ICMP header shown in Figure 3.9 is descibed in Section D.1.1. Receiving AAs from either its HA or a FA is one way for the MN to discover its current location Agent Solicitation If the MN does not receive an AA the MN can broadcast an Agent Solicitation (AS). The basic idea of AS is to make the FAs aware of the MN being present. Nevertheless, care must be taken to ensure, that the MN does not overflow the network with AS - basically a MN can seek endlessly after a FA to connect to. Typically an AS is sent every

33 3.1 Mobility at the network layer Type #addresses Code Addr. size Router address 1 Preference level 1 Router address 2 Preference level 2... Checksum Lifetime Type = 16 Length Sequence number Registration lifetime R B H F M G r T Reserved COA 1 COA 2... Figure 3.9: The structure of an Agent advertisement. second for 3 seconds as it enters a network. If the MN does not receive any answer on its AS it must decrease the rate of transmission in order to avoid flooding the network (maximum decrease typically to about a minute). AS is also used when a MN is searching for a better connection. This is often the case when the MN is moving through different wireless networks. After receiving either an AA the MN gets a COA. The next step is registration with the HA Registration Having received a COA the MN has to register with the HA. The main purpose of the registration is to inform the HA of the MN s current address, so the HA can forward packets successfully. The registration can be done in two different ways depending on the location of the COA. If the COA is at a FA (MN in a foreign network), the registration is performed according to Figure The MN sends its registration request to the FA, which forwards it to the HA. The HA sets up a mobility binding containing the mobile node s home IP address and the current COA. The binding also include the lifetime of the binding, which is negotiated during the registration process. Upon expiration of the lifetime the registration is automatically deleted on the HA, so the MN should register a new binding before expiration. The automatic deletion of bindings ensures that no dead registrations is kept. After setting up the binding, the HA sends a reply to the FA, which forwards it to the MN. If the COA is co-located the registration is simpler as shown in Figure The MN sends a registration request directly to the HA, and the HA replies directly to the MN. UDP packets are used for registration requests. UDP is used because of the low overhead and better performance compared to TCP (Sch03). In Section D the registration request and reply are described.

34 34 Chapter 3. Analysis MN FA HA Registration request Registration request Registration reply Registration reply [Time] Figure 3.10: The registration process over a FA. MN HA Registration request Registration reply [Time] Figure 3.11: The registration process between a MN and a HA.

35 3.1 Mobility at the network layer IP version 6 - as regards mobility MIP was original designed for IP version 4 (IPv4). The introduction of IP version 6 (IPv6) makes mobility much easier (Sch03), since several of the mechanisms which had to be set up separately for IPv4 are included in the IPv6 protocol. Mechanisms for acquiring a COA is build in from start hereby elimination the need for FAs. The COA is instead located directly at the MN. Every IPv6 node can send binding updates to another node, so the MN is able to send its COA directly to the HA. This is achieved due to every node is given a topologically correct address, since the address space has been increased dramatically. Figure 3.12 shows an implementation of MIP running on an IPv6 network. COA Foreign Network 2 Home Network 1 HA Internet MN CN 3 Figure 3.12: MIP running on an IPv6 network. When a CN wants to send a packet to a MN, which is located in a foreign network, in an IPv6 network. The packet is send to the HA (1), which forwards the packet to the MN in the foreign network (2). If the MN wants to reply, it sends the reply packet directly to the CN (3) with the COA address (the current address of the MN), hence communication can henceforth take place directly between the CN and the MN. If the MN moves to another subnet and therefore obtains a new IP address, a binding update is send to both the HA and the nodes MN is communicating with, hence the CNs do not have to communicate through the HA although the MNs point of attachment has changed. Also, soft handovers is possible with IPv6. The MN sends its new COA to the old router servicing the MN at the old COA. Henceforth the old router will encapsulate packets addressed for the old COA and forward these to the new COA until all CNs have been updated. Although many things have been integrated in IPv6, additional mechanisms are still needed in order to offer MIP services. A CN must be able to process binding updates in order to create or update an entry in the routing cache; the MN must for example be able to decapsulate

36 36 Chapter 3. Analysis packets to detect when it needs a new COA; a HA must be able to encapsulate packets; hence MIP requires infrastructure to work also when MIP is used in a network running IPv Features of Mobile IP Some of the features of MIP will be reviewed in this section. One of the benefits of MIP is, that both the CN and the MN can be mobile since the MIP approach uses infrastructure (HA, FA etc.) which keeps track of the MN current address. If both a mobile CN and the MN decides to change their IP addresses simultaneously this does not cause problems since the HAs and FAs receive updates of the MNs current addresses, which enables communication to continue. Unfortunately, the infrastructure also causes disadvantages. Since all traffic between a MN and a CN has to pass through the HA and perhaps also a FA the scalability of MIP is not very good. If the HA/FA have many nodes to serve they may be overloaded resulting in bad performance. The triangular routing is also a potential bottleneck - particularly if the MN is geographically far away from the HA, since the packet has to pass many hubs in order to reach its destination. Since the MIP approach is transparent for layers higher than 3 there is no need for rewriting applications in order to run them in MIP networks. Furthermore no changes need to be applied to the sender network - only minor changes must be applied in the receiving network and on the MN. 3.2 Mobility at the transport layer At the transport layer, mobility can be achieved if both end of the connection always knows the IP addresses of the each other. If one of the endpoints changes location a IP address, it will have to inform the other endpoint about its new IP address. The most often used transport protocols in IP networks are the Transmission Control Protocol (TCP) and User Datagram Protocol (UDP). TCP is used for reliable data transfer over a network, and UDP, which is a much more simple protocol, is mostly used for multimedia services where small delay of packets are more important than reliablity. None of the protocols have the capability to support mobility directly, so it would be necessary to extend the protocols to support this. Under the Internet Engineering Task Force (IETF) another reliable transport protocol has been developed. The Stream Control Transmission Protocol (SCTP (IET00) (IET02a) (ALCJ03)) is working on the transport layer on top of for example an IP network connection, like the TCP and UDP, as shown on Figure SCTP works similar to TCP but extends this protocol with some additional features that makes SCTP more suitable for mobility than TCP. The SCTP makes it for example possible to use multiple networks interfaces for data transfer. But since the SCTP originally was developed to suit other needs, the protocol will also need some

37 3.2 Mobility at the transport layer 37 extension to support mobility. This chapter will first describe the SCTP protocol and after that the necessary extensions to make it support mobility, in the end of this chapter advantages and disadvantages of this protocol will be discussed. Upper layers (Layer 5, 6 and 7) Transport layer (Layer 4) Network layer (Layer 3) Data link layer (Layer 2) SCTP Physical layer (Layer 1) Upper layers (Layer 5, 6 and 7) Transport layer (Layer 4) Network layer (Layer 3) Data link layer (Layer 2) Figure 3.13: SCTP operates on Layer 4 in the OSI model Stream Control Transmission Protocol (SCTP) The SCTP is a reliable transport protocol that makes it possible to setup associations between two endpoints of a connection, and send data between the endpoints in different streams. The associations can consist of multiple IP addresses in both end of connection, so the protocol can take advantages of multihoming. Streams are virtual connections within an association, which can be used to transfer data through. Since an association can consist of multiple streams, it is possible to send data through multiple streams, and if data for some reason is blocked on one of these streams, the data flow can continue on the others. The protocol also has mechanisms for retransmission of packets, flow control and congestion avoidance.

38 38 Chapter 3. Analysis SOURCEPORT DESTINATIONPORT VERIFICATION TAG CHECKSUM TYPE FLAGS LENGTH CHUNK DATA SCTP COMMON HEADER CHUNK 1 CONTROL OR DATA TYPE FLAGS LENGTH CHUNK DATA CHUNK N CONTROL OR DATA Figure 3.14: SCTP packet construction A SCTP packet is divided into one or more chunks. Each chunk can either contain control information or user data. Figure 3.14 shows a SCTP packet. The packet starts by a common header, which combined with information from the IP header forms the destination of the packet. After the common header one or more data chunks can follow. Depending on the type of chunk an appropriate chunk header is added before the actual payload ***: Here should be a ref to an appendix with the SCTP headers Creating an association When an endpoint wants to exchange data with another endpoint, it initiates the creations of an association. The association can consist of multiple IP addresses belonging to different networks, in both ends of the association. Figure 3.15 shows an example of an association between two endpoints. If multiple IP addresses are used to provide redundancy in the network connection, they would have to be connected to the IP network from two different points of attachment. If the IP network was the internet the IP addresses could be obtained through different Internet Service Provider s (ISP) to provide redundancy in the internet connection. IP 1 IP 2 IP A IP B Figure 3.15: SCTP association In an association a primary path is chosen. This is done by the endpoints choosing one of the IP addresses provided by the other endpoint. The primary path will then be used to send all

39 3.2 Mobility at the transport layer 39 data through. Retransmission of data can be send through other paths to improve the reliability of reaching the endpoint. If sending data through the primary path continues to fail, all data will be send through the alternative paths, until the primary path is again available Initiating an association When a client wants to communicate with a server using the SCTP, it initiates an association. CLIENT SERVER INIT INIT ACK COOKIE ECHO COOKIE ACK ASSOCIATION CREATED Figure 3.16: SCTP initialization packet flow Initiating an association happens in four steps, Figure 3.16 shows the packet flow doing the initiation. A detailed description of the structure of the packages can be found in Appendix ***: ref to app. The client starts by sending an INIT packet to the server, which contains information about the IP addresses available and how many stream the endpoint can handle. The INIT package is answered with an INIT ACK that contains the same information for the server, but it also contains a verification tag and a cookie. The verification tag is send with all packages, so the server can distinguish between different SCTP communication. The cookie contains all the information the server needs to create the association. The information is encrypted by a key that only is known by the server, and the client will never know the information inside the cookie (IET99b) (IET99a). The client replies the INIT ACK with a

40 40 Chapter 3. Analysis COOKIE ECHO which echoes the cookie back to the server. The server decrypts the cookie and uses the information inside it to establish an association, when this is done a COOKIE ACK is returned to the client, which informs the client that it can use the association to send data through Transferring data through an association In a SCTP association data is transferred in streams, where an association can consist of multiple streams. Streams are independently virtual channels, which makes it possible to transfer data over a stream even if another channel is blocked. Web page transfer could for example benefit from the streams, since web pages usually is build up of different types of elements, for example text, pictures, or other multimedia elements. By using streams the elements can be transferred parallel and a block of one of the elements would not interfere with the other elements, this could give improved user experience. STREAM 0 STREAM 1 STREAM 0 Figure 3.17: SCTP streams Figure 3.17 shows an example of a multistreamed association between two endpoints. Each stream need to have an queue both at the sender side and the receiver side, so data packets can be send to the application in a sequenced order Acknowledge of received data Each data packet send through the association can consist of multiple chunks from different streams. Each data chunk is uniquely marked with a Transmission Sequence Number (TSN), which is used for retransmission purposes. Furthermore the chunks are marked with a Stream Identifier, to indicate which stream the chunk belongs to, and a Stream Sequence Number (SSN) that tells where in the stream sequence the chunk belongs. Each received packet is acknowledged with a SCTP ACK packet (Called a SACK) ***: Reference to appendiks. The SACK contains information of the last packet which was received in sequence, Cumulative Acknowledge (Cum), and also indicating package ranges received out of order (GapAck).

41 3.2 Mobility at the transport layer 41 HOST A HOST B TSN 7 TSN 6 TSN 8 TSN 9 SACK: Cum=6 SACK: Cum=6, GapAck 8-8 SACK: Cum=6, GapAck 8-9 Figure 3.18: SCTP data and retransmission packet flow Figure 3.18 shows a transmission where a packet is not received in order, and how the SACK tells which packages is missing Retransmission of data Retransmission of data packet occurs either from a timeout or from the reception of a SACK indicating packet loss. The timeout is based on estimate from the round trip delay and is adjusted throughout the communication based on the packet flow and the number of lost packages. Retransmission will only happen after the fourth SACK indicating packet loss, to reduce unnecessary retransmission. ***: Explain figure 2.17 in more details Flow and congestion control Flow and congestion control follows the TCP algorithms (IET99c). To avoid that a sender can flood a receiver, the receiver will return the remaining capacity of its receiver buffer, each time it sends back a SACK. At the sender side congestion control is controlled by maintaining a congestion control window, which indicates how many packets that can be sent into network before an ACK should be received. This will avoid unnecessary retransmission of data packets in a slow or heavily loaded network. The window is initialised by a slow start algorithm, which exponential raises the bound of the window, until a specified limit is exceeded. At this limit the window bound is controlled by a congestion avoidance algorithm. The congestion algorithm is expanded to support multihoming by maintaining congestion windows for each connection Example of multiple stream transmission The following shows an example on the functionality of the streams data transfer.

42 42 Chapter 3. Analysis A4 A3 A2 A1 SCTP Packet A2 B9 B8 B7 B7 C2 B6 C5 C4 C3 C2 C1 Figure 3.19: SCTP packet flow example Figure 3.19 shows an example of a stream data transfer. To the left the sender queues (A, B, C) are shown, the arrows on top of the queues shows the next packet that shall be sent. To the right the receiver queues are shown. When multiple streams in an association wants to send data, the data are put onto queues for each stream. The data in the queues are then gathered into a SCTP packet, which can consist of multiple data packets, in the example the SCTP packet consist of (B7, C2). At the receiver side the data are again put into queues, so it is possible to guarantee the sequence of the data, before it is delivered to the application. In the example the data packet marked A1 has been sent but has been lost, so no acknowledgement are received for the packet. Also the A2 packet has been sent but since there is missing packets it is positioned at the queue. A4 A3 A2 A1 SCTP Packet A2 B9 B8 A1 A3 B7 B6 C6 C5 C4 C3 C2 C1 Figure 3.20: SCTP packet flow example Figure 3.20 shows the next stage of the example. Since A1 has been lost it will be retransmitted, A3 will also be sent, and the next package to send in the A queue will be A4. Since B7 and C2 has been sent right and been acknowledged they can be removed from the sender queue. On the receiver side B and C queue are sequenced right, so packets can be transferred to the application. A6 A5 A4 SCTP Packet A3 A2, A1 B9 B8 A4 B8 B7 C6 C5 C4 C3 C2 Figure 3.21: SCTP packet flow example Figure 3.21 shows how the receiver queues are all sequenced right, and data can be transferred

43 3.2 Mobility at the transport layer 43 to the receiver application, while data packets are transferred through the streams Ending an association An association can be ended by both endpoints in two ways, either as an abort or a graceful termination. In an abort one of the endpoints sends the abort packet to the other endpoint, which immediately ends the association. A graceful termination is a three stage process. First the endpoint who wants to end the association flushes all queues so no packets are awaiting transmission. After flushing the queues, the endpoint sends a shutdown packet ***: ref to appendix. The other endpoint sends all packets waiting for transmission so no packets are left in the queues. When all packets are send amd acknowledged, a shutdown acknowledgement are sent, which is replied with a shutdown complete package. After this three way handshake the association is ended Extending SCTP for mobility Since SCTP originally was not developed for mobility, it is necessary to add some extensions to the protocol to achieve this. SCTP misses two important things to make it suitable for mobility, the ability to add and delete IP addresses for an association dynamically, and to choose which path should be the primary path. SCTP defines all IP addresses for an association doing initiation. Since mobile nodes usually can not predict which IP will be used doing an association, it will be necessary to extend the protocol with features that makes it possible to dynamically add and delete IP addresses from an association. The properties of the network interfaces used on a mobile node can have big differences. For example WLAN and GPRS could be the available interfaces, and these technologies have huge differences in bandwidth and cost. The endpoint in a SCTP association choose independently to what IP address in an association data packets shall be send. To extend SCTP to support mobility the endpoints should have the ability to choose for themselves what IP address the other endpoint should route traffic to SCTP dynamic address reconfiguration An internet draft provided by IETF (? ) suggests ways of implementing these extensions to SCTP so it can support mobility. The extension consists of a new chunk called Address Configuration Change Chunk (ASCONF), which can consist of an additionally set of new parameters to achieve the necessary functionality for mobility ***: raf to appendiks about the protocol packages. The chunk number is created in a way that will force the receiver to return an error, if it cannot understand the request; this will make some sort of compability between nodes that do not have the extension. The parameters of the chunk could be for deletion or adding of IP addresses to an association. Since it is possible to delete and add IP addresses not known by the receiver, the ASCONF package has a field so it is possible to determine to which

44 44 Chapter 3. Analysis association an ASCONF request belongs to. All ASCONF packages need to be acknowledged before the changes become effective. This means that if a mobile node changes its IP address it will have to delete its old IP address from the association, and add the new one and get the acknowledge of these changes before in can send data through the association again. The receiver of an ASCONF package can use the changes inside the packages immediately. The extension also makes it possible for an endpoint to send a package to the other endpoint to tell which IP address it should use as primary IP address when sending data Why use transport mobility To use the transport layer to enable mobility for users has some advantages and disadvantages. When using the transport layer instead of for example the network layer as with Mobile IP, both ends needs to know that a special protocol for mobility is used. This means that both ends of a connection need to be updated with compatible software, to support the mobility. Since the mobility is supported at the transport layer, it is not necessary to change the network infrastructure, and since all traffic does not need to be routed through certain points in the network, there are no problems with scalability. The price for not changing the network infrastructure is an additional complexity of the transport protocol, which might introduce some header overhead for the data packages. Since SCTP is based on streams and TCP on packages it is a difficult task to calculate the size of extra overhead introduced. It is trivial to calculate the extra overhead for a single data package, but since the size of the packages varies in size for a real life data transfer, it is hard to tell how much SCTP will benefit from sending multiple data packages in one SCTP package. If the network transfer consist of a lot of small independently packages SCTP might even be more efficient than TCP. A problem by using mobility at the transport layer is that the mobile nodes is not attached to the network at any fixed point and therefore contact to them can not be made through a static IP address. The extension to the SCTP partially solves this problem, by letting the mobile nodes add and delete IP addresses to the association. This solves scenarios where a mobile node changes it point of attachment to the network, but if both ends of the association changes their point of attachment simultaneously, they will have no chance to resume the association since none of them knows the IP address of each others. Most communication between mobile nodes depends on servers located at the internet, and uses these to establish communication between endpoints. In these cases the servers can be used to send the new IP addresses for the endpoints to, if directly communication with and endpoint can not be achieved. But there are scenarios where servers not are involved in the communication, and in these cases the transport mobility will fail if it is not extended with additional features that can solve these problems. A solution could be to have a dedicated static server on the Internet which is used for maintaining the IP addresses of the mobile nodes. So if two mobile nodes in an association both change their point of attachment, they can communicate their new IP address to the server, and the server can then buffer the requests for adding the new IP addresses to association, so when the endpoints are ready they will receive the requests. Different technologies can be used to

45 3.3 Mobility at the application layer 45 achieve this kind of feature, but all of them make a hybrid between mobility at the transport layer and mobility at the network layer. For example Mobile IP could be used to maintain a static IP address in an association which can be used when both ends of an association changes point of attachment. This will extend the advantages of a solution but will at the same time introduce disadvantages from both techniques. 3.3 Mobility at the application layer Mobility can also be achieved at the application layer. The principle idea by supporting mobility at the application layer is almost the same as on the transport layer, which is to always inform the correspondent nodes which IP address data packets should be send to. This is done by sending maintain packages which contains information about changes. Since the mobility is controlled at the application layer any transport protocol, that suit the packet flow best can be used for the communication. Application layer (Layer 7) Upper layers (Layer 5 and 6) Transport layer (Layer 4) Network layer (Layer 3) Data link layer (Layer 2) SIP Physical layer (Layer 1) Application layer (Layer 7) Upper layers (Layer 5 and 6) Transport layer (Layer 4) Network layer (Layer 3) Data link layer (Layer 2) Figure 3.22: SIP operates on Layer 7 in the OSI model. Since mobility is supported at the application layer, there is a certain amount of flexibility to create the support for this. But since it in most situations is convenient to use a standard protocol, so the created software is compatible with other kinds of software, different protocols to support the application layer mobility is available. One of these protocols is the Session Initiated Protocol (SIP) which is standardized by IETF (IET02b), for creating, modifying and terminating sessions, between one or more participants. Primarily it is used for multimedia sessions, for example Internet telephone calls, but can be used for other purposes. This protocol will be described in more details, so it is possible to point out the advantages and disadvantages by supporting mobility at the application layer.

46 (1) SIP REGISTER (2) SIP OK 46 Chapter 3. Analysis Session Initiated Protocol (SIP) The SIP consists of three main components (EW04), a user agent, a redirect server and a proxy server. The user agent is installed at the nodes participating in a SIP session. The user agent is responsible for listening for SIP packets at the node, and sending packets upon user action or to reply to the incoming packets. The redirect server is used for maintaining information about the location of the nodes attached to it. When a node changes it location it will send this information to redirect server which will store this. Other nodes can then use the redirect server to relocate the node how has changes its location. The proxy server can accomplish the same tasks as the redirect server, but it also has the ability to tunnel packages from the proxy server to a node. The servers in the SIP network enables mobility for the nodes, since a user of a node can register with the server no matter where it is located, and be found by other nodes even if the location or the device is shifted by the user. SIP is not using IP addresses to register nodes; instead domains and usernames are used for this. No matter where the user is located it will always be possible to find it, when the username and home domain is known. Redirect server (8) SIP REGISTER (9) SIP OK (3) SIP INVITE (4) SIP 302 (moved temporarily) (8) SIP INVITE (9) SIP OK (10) DATA CN (5) SIP INVITE (6) SIP OK (7) DATA MN Second location MN First location Figure 3.23: Example of data communication using SIP Figure 3.23 shows an example of how data transfer can happen by using SIP. The mobile node is announcing its presents by sending a registration to the registration server (redirect server) in the domain at which it is attached. When a correspondent node wants to communicate with a mobile node, it sends a SIP INVITE to the redirect server which is handling users of a specific domain. If the mobile node can be reached at the time the redirect serves answers with a package containing information about the current IP address of the mobile node. The correspondent node then sends a SIP INVITE package to the mobile node which is replying

47 3.4 Key features 47 with a SIP OK package, after this data between the two nodes can be send. If the mobile node is moving out of the network it was attached two and into another network, or the user of the mobile node changes to another device, the IP address at which the user can be reached will have changed. To resume the data transfer, the mobile node will send a new SIP INVITE to the correspondent node, which will reply with a SIP OK, and the data transfer can continue. The SIP INVITE package keeps, aside the location of the mobile node, also the location of the redirect server at which it is registrated. If it is not possible to send the new information of the current IP address, it is possible to resume the transfer by asking the redirect server of the nodes current location. The proxy server performs the same tasks as the redirect server, but instead of telling the correspondent node of the current location of the mobile node, it is forwarding all packages to the mobile node. In certain scenarios this kind data transfer can be preferred instead of the offered by the redirect server Why use application layer mobility One of the advantages of implementing mobility at the application layer is the free choice of which transport protocol that should be used for the data communication. Since the transport protocols have different properties regarding reliability verses overhead, it is possible to choice a transport protocol that fits the needs of the communication. Another advantage is the high mobility that is achieved by register users at fixed servers. When the servers always are aware of the location of the users, a session can continue even if both endpoint changes their location. If both endpoints changes location a node will not know the location of the other node, but can get this by asking the server at which the node is registrated, and the communication can continue. Since the session can be carried on as long as the user can register at the server, the communication can continue on other devices. If registration on the server is done by username and a password, or in scenarios where more security is needed by a key file know, it is easy to log into another device and get the communication transferred to this. This kind of mobility is most useful for multimedia session, since small delays can be allowed and the continuity of the communication is not dependent on what has happen before, in contrast to a file transfer where the success is dependent on gathering all the data packets into a file. One of the disadvantages by using application mobility is the extra servers needed to handle the user registration, since these will have to be deployed into the network. Another disadvantage is the fact that the mobility is archived at the application layer, so it is necessary to rewrite application to use this kind of mobility, or at least to have some kind of control software that controls the data flow to the applications and handles the SIP requests. 3.4 Key features In this chapter different techniques for gaining mobility in a network have been analyzed. Table 3.1 provides a quick summary of the key features for the different techniques.

48 48 Chapter 3. Analysis Category Migrating IP MIP msctp SIP OSI Layer Network Network Transport Application Network support Not required Required Not required Required Global mobility No Yes Yes Yes Software on CN Not required Not required Required Required Special Agents No Home Agent, No 1 Redirect Foreign Agent servers Notes Only mobility within the subnet Triangular routing or Proxy servers Table 3.1: Comparison of features of the 4 techniques analyzed in this chapter. ***: Find gerne flere sammenligningspunkter > skal tabellen beskrives i tekst? In the next section delimitation will be performed in order to reinforce focus on some of the techniques. 3.5 Delimitation of mobility techniques Due to the time schedule we have to delimit the number of mobility techniques which we want to implement and perform measurements on henceforth in the project. We have chosen to continue with the following: Migrating IP Mobile IP (MIP) msctp hence Session Initiated Protocol (SIP) has been skipped. Currently IP-lab does not have an implementation of SIP running, hence it will take awhile to perform the implementation. Already we have decided to look into SCTP which we will have to implement, since no running implementation is available. The reason for looking into SCTP is that we think SCTP has the potential to replace TCP, hence we find it interesting to gain insight to how it works.

49 4Mobility in reality The analysis did describe the theoretical part of the different concepts for achieving mobility in IP based networks. This chapter will look into the applications of the different concepts, and show that mobility has a range of different useful applications. Since the concepts have different features, it is advantageously to use them in different scenarios. All the concepts are based on the fact that the network the mobile nodes are used within, is offering network interfacing which supports mobility. Since the wireless interfaces are the common denominator for all the concepts, hence they will be discussed first. 4.1 Why and when to do a handover? When a user is mobile the point of attachment to the network can change all the time, and therefore a handover is needed between the points of attachment. A handover can be needed if the user moves geographically around, and it can even be necessary to achieve this by using a different kind of technology than the prior used, which will lead to a vertical handover ***: ref to preanalysis. Also equipment malfunction can lead to a handover to maintain attachment to the network. When different kind of technologies are used for the connection to the network also resource prioritizing can lead to a situation where a handover could be suitable, for example the bandwidth of the connection, the price for using the connection or the power consumption for maintaining the connection could be considered. Three kinds of technologies are commonly used to achieve wireless connection to a network, and these technologies have different features. ***: table ***: See the wireless class slides to correct and extend this table To choose the right technology to connect to the network all the time, the features of the technologies have to be taken into account, but this is not enough since the features are not constant. For example the utilization of a WLAN access point, and the distance to the access point can decrease the amount of bandwidth available. So the decision of when to make a vertical handover can be rather complex, and should be based on the current state of the network interface. A handover could be based on the following parameters, the actual amount of bandwidth available for the connections, the cost of using the connection and the consumption of power relative to the amount of power available. 49

50 50 Chapter 4. Mobility in reality Connectivity Bandwidth Cost Power consumption Wireless Groups of access High bandwidth. Free Relative high LAN points usually Up to 54Mbit/s (WLAN) covering up to hundreds of meters Bluetooth Usually stand Relative high Free Relative low alone access bandwidth Up to point covering 1Mbit/s 10m or 100m GPRS National mobile Relative low Priced per Depending on implementation network bandwidth Up to 170kbit/s time unit Table 4.1: Comparison of WLAN, Bluetooth and GPRS Mobility applications... Some types of network communication are better suited for certain mobility concepts, and for some types the existing protocols do not need any extensions to work in a mobile kind of way. It is only necessary to add mobility support to a node if continuously communication with another node is needed. For ordinary web browsing, the communication behavior usually are that the user sends a web request that will trigger the download of a webpage, after the download the user would spend some time looking at the page, before another page is downloaded. If a handover is performed doing the browsing, then when a new page is requested, this will be downloaded on the new interface and the browsing can continue. Even if the handover is performed while a web page is downloaded, the amount of data that is lost is so small that a new request of the webpage would not imply much more traffic or delay. For ordinary web browsing the need for supporting mobility is not that high, but other types of application would suffer if a handover implies that data would have to be retransmitted. For example if a voice over IP (VoIP) conversation is interrupted by a handover, the communication would have to be reestablished to continue the communication on another interface. Also gaming and other kinds of network application which require constant contact for not terminating the connection, can achieve a greater level of mobility by using one of the concepts already described. In larger private networks mobility can in some cases also be an advantage if different kind of servers is often used and the user of the network can benefit for moving physically around and still be attached to the network. An example could be a corporate network where users use different kind of servers which needs the users to be authorized when changing point of attachment; here the prior described mobility concepts would give the user mobility without the need for authorizing all the time.

51 4.2 Use cases Mobility interfacing In some scenarios the mobile nodes can be equipped with an interface card for each technology used for network connectivity, for example can a laptop have a Bluetooth, a WLAN and a wired LAN interface card, and switch between these interfaces when it is appropriate. In this kind of scenarios a handover can be initiated immediately if both interfaces are connected. If the handover is initiated so packets still are sent to the former used interface, while the new interface is getting ready to receive packets, the handover is called a soft handover. A soft handover requires that a connection to the network is established at all time. If the used interface certainly no longer can be used for transmission, for example because of equipment malfunction, there will be a gap in the flow of packets before the new interface is ready to receive packets; this type of handover is called a hard handover. Doing the hard handover the connection to the network is broken for a period of time. ***: Clear definition of handover If only one interface is used for connection to the network, handovers can still be performed between different networks. The handling of a handover is decided from the technology used, and therefore the time it takes to make a horizontal handover varies from technology to technology. In near future Software Defines Radio (SDR ***: ref to enabled devices will be available. This technology will make devices able to interface to an almost unlimited number of wireless sources, but to make a handover between two technologies will mean that the interface will have to be reconfigured, and the time will therefore be dependent of the implementation of the technology. The implementations ability to conduct a handover, the type of the handover, and the interfaces used in the handover, strongly influences the time a handover takes. Therefore lots of parameters can be adjusted to perform perfect handovers, but if the control of the parameters is not optimal, implementations, like the ability to achieve a new IP address, can lead to longer handover times. ***: This could be a chapter in the end of the analysis to round it off What should be measured and why? Hard or soft handovers? What can we really measure? How close is what we measure to a real life implementation? 4.2 Use cases Several techniques for gaining mobility in a network have been discussed. In this section use cases presenting the special features of the techniques will be presented.

52 52 Chapter 4. Mobility in reality Migrating IP Using migrating IP to gain mobility in a network is inexpensive, since only an additional IP address (VIP) is needed 1 compared to ordinary IP assignment. No special equipment is needed, since the migration is based on standard network principles which is frequently used in general purpose networks. Furthermore it is easy to implement a migrating IP handover since a simple program is able to do the job. Because of the use of standard network commands operating on Layer 2 in the OSI model only mobility within the subnet is possible. The above stated features of migrating IP makes this technique suitable for implementing mobility in for example private homes. Consider a private user, who has created a network in the house. The network is wire-based but the user also has the opportunity to connect to the network via a wireless connection. When the user wants to move around in the house or even go out in the garden with the mobile node, it is advantageously to handover the connectivity to the wireless interface, which a migrating script can perform. Since a home network most likely only consists of a single subnet, the limitation of migrating IP does not influence the mobility. The fact that it is free to gain mobility by migrating IP is also ideal in relation to private user. Another example where migrating IP is convenient to use is in companies, which have the need for mobility within a single subnet. Consider as an example Figure 4.1 which shows a subnet spread over a geographically large area. The subnet contains several access points using different network technologies, hence a handover between interfaces may be needed. The handover may also be favorable for example due to extreme traffic on one network technology, hence another technology may be able to offer a higher rate of bandwidth Mobile IP applications MIP is useful in a number of different scenarios. Because of the layout of MIP it is most useful for network owners to provide mobility to their users. MIP provides transparency from the network layer on the mobile node using it, and totally transparency for correspondent nodes. CN s do not need to be aware of the fact that they are communicating with a node which is mobile. But for MIP to function it is necessary that it is deployed in the network the nodes are connected to. These facts limit the use of MIP to provide mobility in larger networks, but MIP is still very powerful for certain types of applications. Basically MIP can be configured in two ways, which provides usability in two major groups of applications. In large corporate networks the deployment of MIP will give the users mobility in their attachment to the network. If the planning of the network takes into account that subnets do not interfere with each others, MN decapsulation can be used in the network, which will route traffic directly from the HA to the MN, so the FA only is used for registration and localizing 1 There are several ways to implement migrating IP. One can choose not to use an additional IP address (VIP). However, using an additional IP (VIP) address makes it very easy to migrate between interfaces.

53 4.2 Use cases 53 Subnet BT Figure 4.1: A single subnet with several access points using different network technologies. of the MN. By using the MN as the endpoint of the tunnel the overload in the network will be reduced, and so will the work needed by the FA. By implementing MIP in this way in the network, users will be able to take their laptops and connect to the network no matter where they are located. Even if a user is attending a meeting in another department, the connection to the network is achieved through the FA in the visited apartment, but the connection is granted by the HA so further authorizing is not needed in visited department. If the HA is accessible from the internet the users can maintain their connection to the network for example by using a GRPS connection. When users get out of range from the company network, traffic is routed to their GPRS connection, so already initiated session, for example server connection or VoIP sessions will not be interrupted. CN MN MN HA FA Internet GPRS Network X Hotspot X Figure 4.2: MIP scenario where FA decapsulation is used Figure 4.6 on page 58 shows an example where MN decapsulation is used. When the MN is moving to another department, an IP from their subnet will be obtained, and traffic send

54 54 Chapter 4. Mobility in reality to the old IP address of the MN, will be intercepted by the HA and tunnelled to the MN s new IP address. Since nodes can happen to communicate with servers in other departments, the IP address planning needs to take into consideration that IP addresses do not overlap. An overlap in IP addresses between nodes will also be fatal, since routing to specific nodes is not possible. The other main application where MIP can be used is for Internet Service Providers (ISP) to extend their services, so different kind of interfaces can be used for the internet connection. If the ISP for example offers connectivity through a national mobile network like GPRS, but also has WLAN hotspots at different locations, a fluent transition between the two networks can be offered to the user. If the different networks is connected through a HA or FA also working as a gateway towards the internet, it will be possible to connect to the HA from anywhere on the internet. If the agents are used as gateways FA decapsulation can be used, since it will not affect the overload in the network, and reduce the demands on the MN. When the agents are used as gateways, it will also be possible to use the traffic through these servers for price calculations. If the agents are reachable from the internet, the ISP could make roaming agreements with other ISP s so users also could use their network, which will extend the users probability to establish a good connection to the internet. DB SERVER MN Department X HA FA MN Department X CN Figure 4.3: MIP scenario where MN decapsulation is used Figure 4.3 shows an example where FA decapsulation is used. Traffic to the MN is routed to the HA where the traffic is tunnelled to the FA, at the FA the tunnel is decapsulated and packets is forwarded to the MN.

55 4.2 Use cases SCTP applications SCTP with the extension for mobility can be used in various sets of different applications. Since SCTP can be used, without the need for changing network infrastructure, it is advantageous to use this technology for applications developers who wants there applications to support mobility. Since SCTP only needs to be implemented on the endpoints, the dependency on which network provider is used and which services the network provider offers does not matter. Several different network providers can be used to achieve the connectivity that is wanted by the user. Since SCTP is independent from the network connections used, the developer of mobile applications do not need to consider the type of network connection used for the application. Connectivity can therefore be performed through several different network provides or even in an ad hoc networks. Since SCTP functions on the transport layer, and therefore is independent of the network connection used, it is necessary that both ends of the connection support Mobile SCTP, for the applications to function. The fact that SCTP is operating on the transport layer it is necessary to have a fixed host accessible in the network, so communication can be resumed by sending information about network connection changes to the fixed host. The fixed point could be one endpoint of the connection, if one of the endpoints does not need the mobility support. If mobility support is needed on both endpoints the communication can be lost if both endpoints changes attachment of connection at the same time. For the communication to be resumed it is necessary that a fixed host can be contacted to reestablish the communication. Because that SCTP is independent on the network layer, it is especial useful in applications where the connection between the endpoint uses different kind of network, where the network provider is unknown. The independence of the network which provides the connection between the endpoints makes it possible to establish connection both in network with infrastructure, like GPRS or WLAN hotspots, or ad hoc networks, where two nodes establish a network. An example of a SCTP mobility application is voice over IP (VoIP). A PDA with VoIP software which supports Mobile SCTP, could be used to make VoIP sessions which could continue even if the attachment to network changes. A VoIP session could be initiated while the PDA is connected to a GPRS network, and when it enters a WLAN hotspot that can be used for internet access, the VoIP session is handed over from the GPRS network to the WLAN. This could be done even if it is two different network providers with no roaming agreement with each other, as long as the users have access to use the networks. Figure ***: ref to pic shows the handover between a GPRS and a WLAN provider. The provider of the two services is not necessary the same company.

56 56 Chapter 4. Mobility in reality VoIP Internet VoIP GPRS Network Provider A Handover WLAN Hotspot Provider B Figure 4.4: VoIP scenario with SCTP mobility support Another useful application of SCTP is in multiuser gaming scenarios. SCTP s ability to work in any provided network implies that a game could be initiated in an ad hoc network established between two nodes. When the nodes are moving apart so it is not possible to maintain an ad-hoc connection between the nodes, the game session may continue if the nodes are handed over to another type of network, which could be GPRS or WLAN. For the game session to continue after the handover it is necessary that both nodes can contact a fixed server from the new network they are attached to. Figure ***: ref to pic shows the described example; where the game session is moved form the ad hoc network to a session through the internet.

57 4.2 Use cases 57 WLAN Hotspot Internet Registration Node 1 Game session Game server Handover Registration Node 1 Game session Node 2 Handover Node 2 Ad Hoc network GPRS Network Figure 4.5: Gaming scenario with SCTP mobility support Another usecase where the SCTP mobility can be used is in applications that need longer sessions with for example a database server. An example could be a salesman, who needs access to customer and price information from servers within the company, but still can visit customers or have meetings outside the company. By using SCTP mobility the connection to the company servers can be handed over between different internet connections, which could be established through GPRS, WLAN hotspots or even the internet connection available at the customer. Figure ***: ref to pic shows a scenario for the example.

58 58 Chapter 4. Mobility in reality Customer network Handover Database server Company network Internet WLAN Hotspot Handover GPRS Network Figure 4.6: Salesman scenario with SCTP mobility support

59 5Experimental implementation and measurements Chapter 5 will present the measurements and the implementation part of the mobility techniques. 5.1 Implementation notes In this section generale notes which have relevans regarding implementation and measuring will be stated Interfaces for measuring Two types of wireless technologies will be used during the measurements. An ordinary b Wireless LAN interface and a Bluetooth USB adapter using a PAN profile, so that it acts as a network interface. The reason for using these interfaces are, that they are available in IP lab, and that the bandwidth makes it possible to give a fairly ***: skal bakkes op af definitionen af seamless estimate of the handover time. Bluetooths bandwidth is approximately 700 kbits/s. When a packet size 1 of 10 bytes 2 are used the interpacket time is ***: do the math 200 b bytes/s > gange overskud ***: udregning der viser at BT båndbreden er tilstrækkelig for at vi opnår den ønskede nøjagtighed Operating system All implementations will be done on the open source operating system Fedora (Red Hat Linux destribution) (? ). Fedora is selected since it is open source hence providing a great deal of 1 UDP packet size 2 This size i chosen as the result of a compromise between a realistic packet size and that the interpacket time must be relative small. 59

60 60 Chapter 5. Experimental implementation and measurements modifiability. ***: The following should be deleted when the chapters are done!!! Chapter consist of three parts for Migrating IP, MIP and SCTP, each section should consist the following. SETUP: Describing the setup and why this is the setup. The description should be more precise than the one in the analysis, and cover network layout, and what hardware and software which is used... DESIGN: Analysis of how the software should be build and what it should take care of. A schematic describign the major building blocks and the logic relation of them could be a starting point. IMPLEMENTATION: This section could differ. But it could describe the existing software, if this is used, regarding what features is offered, what os used and so on. And how this existing sotware should be setup to run. Or it could describe the implementation of the software that should be made. MEASUREMENT SCENARIOS: Detailed measurement scenarios. Describing the scenarios, and what was measured. RESULTS: Graphs describing the results, and an explanation of rhe results. CONCLUSION: Analysis of the results, identifying problems, and suggesting solutions for this. Suggesting optimization. 5.2 Migrating IP The nature and use of migrating IP was described in Section In this section we will implement a measurement setup which is similar to the scenario presented in Section Setup The scenario which will be implemented is shown in Figure 5.1. The two NICs which are present in the laptop, maintains connectivity to a Bluetooth (BT) access point and a WLAN access point. IP addresses have been assigned to both interfaces. The VIP, which is migrating between eth1 and bnep0, is the static IP address The router, which connects subnet X to subnet X, is updated using gratuitous ARP as described in Appendix C. The stream server, which is running Iperf ***: hvilken streamer bruger vi streaming software, is continuously sending 125 UDP packets per second to the VIP, with a length of 10 bytes and occupying 100 kbit/s of bandwidth. These settings were selected since they do not overload the Bluetooth connection but still provide an appropriate accuracy of roughly 0.008s which will be used to calculate the handover time.

61 5.2 Migrating IP 61 Stream server WLAN access point BT access point WLAN (eth1) BT (bnep0) VIP: Figure 5.1: Setup to test Migrating IP Design In this section the software for migrating the VIP from the WLAN (eth1) to Bluetooth (bnep0) is designed. The activities of the VIP migration are shown in Figure 5.2. Loading script Setups interfaces Waiting for an input Checks input Migrate Input =1 Input!= 1 Migration completed Figure 5.2: Activity diagram for the migrating script. When the script has been loaded, the interfaces involved in the migration are set up. If present, VIP alias on the Bluetooth interfaces is initially disabled. Afterwards a VIP alias is added to the eth1 interface. The VIP association is broadcasted to routers and nodes using gratuitous ARP. When the initial setups have been completed, data can be streamed to the new VIP/in-

62 62 Chapter 5. Experimental implementation and measurements terface constellation. A migration is being conducted, when the user types 1. If any other character is typed, the script terminates. When migrating the VIP, the alias on eth1 is first deleted. Aterwards an alias is added to bnep0 and the new association is broadcasted using gratuitous ARP. The migration is now completed, and the script is termined. In Section the implementation of the script is discused Implementation The design of the migrating script was described in Section In this Section implementation aspects will be taken into consideration. The operating system on the laptop in Figure 5.1 is Fedora (Red Hat Linux distribution). ***: overvejes at slettes The migrating IP scenario can easily be implemented using Fedora s basic commands. Using a bash script even a GUI can be provided making it very easy to migrate a VIP between NICs. The bash script for migrating the VIP is shown in Appendix F.1. The script can also be found on the enclosed CD Measurement scenarios The measurements are conducted in the following way: 3 handovers from WLAN to Bluetooth and afterwards 3 handovers from Bluetooth to WLAN are conducted. Migrating from both WLAN and Bluetooth enables exclusion of interface related delays. The measurement scenarios were configured as described in Section 5.2.1, and the migrating script was developed as described in Section In order to measure the handover time, Ethereal was used to capture the packet flow on the laptop shown in Figure 5.1. Ethereal was set to monitor the interfaces in promiscuous mode, hence packets were packet on both interfaces The captured packets were afterwards reviewed in order to calculate the handover time Results Table 5.1 shows the 6 handover times achieved in the 6 experiments. ***: præcision: s ***: Layer 2 algoritme til at detektere at signalet er svag (trigger handoveret) skal på en eller anden måde med i denne beskrivelse - da dette mangler, og vil betyde et længere handover Table 5.1 shows that the handover times are far smaller than stated in Section 3.1.1, which was approximately 2 seconds. In these experiments only the handovers were measured. This explains a big part of the differences between the handover times stated in Table 5.1 and the 2 seconds, since in a real

63 5.2 Migrating IP 63 Experiment No WLAN to BT BT to WLAN Table 5.1: Handover times measured in 6 experiments. implementation the script should also continuously ping its counterpart in order to determine whether or not it is available. This task introduces a time interval before the handover should be conducted. Also it should be noted, that the decision of migrating the VIP should not be founded on the basis of a single failed ping reply. The threshold should probably be higher in order to avoid unnecessary migrations hereby introducing a larger handover time. However in cases where a migration is needed, the threshold only causes delay before the migration is being conducted, hence care must be taken setting the threshold value Analysis of measurement results In this Section an analysis of two measurements will be conducted. The selection of the two measurements was based on the fact that the 6 measurements are very similar, hence only two measurements is analysed in this Section Bluetooth to WLAN migration Figure 5.3 shows the relative time from packet number 1 was captured by Ethereal on the x-axis. The primary y-axis shows the interpacket time (time difference between two neighbour packets). The secondary y-axis shows the number of packets during the last second, which should be 125 packets per second. Figure 5.3a shows the captured packets during the period from 1 to 7 seconds, where the handover occurs in the area around 4s. This area is of great interest in this analysis, hence 5.3b shows a zoom of this area. When switching from one interface to the other, one notes that the interpacket time varies heavily. The variation is greater when packets are received on the Bluetooth connection than on the WLAN connection. However further analysis has to be conducted in order to determine if the interpacket time is greater than WLAN. ***: er det nødvendigt? Several reasons can cause this phenomenon. The design of the software driver, how the operating system is prioritizing the interfaces and network depend parameters (for example delays caused by the Bluetooth hub) all causes the interpacket time to change. The Iperf streaming software periodically produces spikes as shown in Figure 5.3. This spike is related to the distribution function of Iperf. The dots indicate the number of received packets the last second. The packets/sec value varies a bit. A possible explanation is that a packet may not be received in the same time interval

64 64 Chapter 5. Experimental implementation and measurements as it was send. Furthermore, Iperf probaly has a hard time distributing the packets uniformly, since unexpected actions take places all the time, sometimes making it hard to achive exactly 125 packets/second. Figure 5.3b shows a zoom of the area around the handover. The interpacket time falls immedially after the handover to WLAN, and the receiving of packets continous as shown in 5.3. No packets are dropped during the handover. This can be established by comparing the sequense number of the IP packets just before and just after the handover. If no packets were dropped the sequence number should be in sequence. 5.3 Mobile IP Setup Home network X Foreign network X Stream server HA Bluetooth WLAN WLAN FA Bluetooth WLAN Mobile Node Figure 5.5: MIP setup Figure 5.5 shows the setup used to measure the handover time in the mobile IP scenarios. The stream servers streams UDP packets towards the Mobile Node (MN). When the MN is located in the home network, the MN is registered at the HA so this know that packet can be routed

65 5.3 Mobile IP 65 Time difference between packets [s] 0, , , , , , , , , Relative time from pakcet no. 1 [s] Packet destribution [packet/s] a General view 0, , Time difference between packets [s] 0,04 0,03 0,02 Handover Packet destribution [packet/s] 114 0, ,6 3,7 3,8 3,9 4 4,1 4,2 4,3 4,4 Relative time from pakcet no. 1 [s] b Zoomed view of the handover area. The actual handover area is shaded Figure 5.3: Bluetooth (bnep0) to WLAN (eth1) migration.

66 66 Chapter 5. Experimental implementation and measurements 0, , Interpacket time [s] 0,08 0,06 0, Number of packets per second (dots) 114 0, Relative time to packet No. 1 [s] a General view 0, ,1 124 Interpacket time [s] 0,08 0,06 0,04 0,02 Handover Number of packets per second (dots) ,1 8,2 8,3 8,4 8,5 8,6 8,7 8,8 8,9 9 9,1 Relative time to packet No. 1 [s] b Zoomed view of the handover area. The actual handover area is shaded

67 5.3 Mobile IP 67 directly to the MN. When the MN is located in the foreign network, the MN is still registered at the HA, so it knows that packets to the MN shall be routed to the foreign network which is done through a tunnel to the FA. The setup makes it possible to make different kind of measurements. Since it is possible to connect to the home network either by Bluetooth or a WLAN access point, and it is possible to connect to the foreign network through a WLAN access point, two kinds of experiments can be conducted. By making a handover from the foreign network WLAN to the home network Bluetooth, a handover between multiple interfaces can be made. When making the handover between the WLAN access points a scenario where only one network interface is available can be made. A handover with only one network interface should take longer time, because it is necessary first to reconfigure the interface before the registration can begin, in opposite to a handover between multiple interfaces where the registration can start immediately Design Home agent Register MN Location of MN Forward Tunnel to FA Setup Virtual IP(VIP) Forward packets Foreign agent Register MN Forward registration to HA Forward Froward packet from tunnel Tunnel to HA Application Listening on specific ports Sending on specific ports Mobile node agent Watching Discover active and non active NIC Discover agents Setup Choose NIC Configure NIC Register at agent Update routes Update default route to new NIC Update default gateway Operating system Operating system Operating system NIC1 VIP LAN LAN NIC1 LAN NIC1 WLAN NIC2 BlueTooth NIC1 LAN Figure 5.6: Design of MIP agent software Figure 5.6 shows the basic building blocks for a MIP implementation. The software for the implementation is divided into three parts, a mobile node agent, a home agent and a foreign agent. Each of these agents is controlled by the operating system, which controls access to the network interface card (NIC) installed in the system. A more detailed description of the software will be given in the following sections Home agent The home agent needs to keep track on the mobile nodes and forward packets to them depending on their location. If the MN is located in the home network and is assigned its home IP

68 68 Chapter 5. Experimental implementation and measurements address, the HA does not need to intercept the packets, but if the MN has another IP address the HA needs to intercept the packets and forward them to the MN by encapsulate the packages. The package is then decapsulated at the MN. If the MN is located in a foreign network, the HA needs to intercept the packets send to the home address of the mobile node, to forward them to the mobile node. This can be done by establishing a tunnel to the FA in the network where the MN is located. The interception of the packets are done by setting up a virtual network interface which holds the home IP address of the mobile node, and letting the routes know that packets should be send to the HA instead of the MN (see Appendix C on page 89). To let mobile nodes know the presents of a HA, agent advertisement is regularly send out Foreign agent The foreign agent keeps track on mobile nodes located in the foreign network. If a mobile node is registering at the FA in the foreign network, the registration is forwarded to the HA in the home network of the mobile node. When a mobile node is located in the foreign network a tunnel from the HA to the FA is established. The FA needs to decapsulate the packages, and forwards them to the MN. In some cases it could be an advantage to tunnel packets from the MN in the foreign network back to the HA, and forward them from the HA to the destination. Like the HA the FA sends out agent advertisement to let mobile nodes know the presents of it Mobile node agent On the mobile node the agent is working in parallel with other applications which might use the network connection. The mobile node agent needs to maintain the network connection, so the other applications will not notice the changes in the network connection. The MN agent needs to continuously monitor the network connections to see if they are activated and can be used to connect to a HA or a FA, and also monitor them to see if they are deactivated and can no longer be used, so it is necessary to use another interface if available. The MN also needs to continuously listen for agent advertisements. Based on the information on active or inactive network interfaces and the presents of agents the mobile node needs to choose which interface should be used for communication. The choice of interface can also be extended with information of the quality of the link or other kind of priority of the interfaces, to make it more likely to choose the best network connection at all time. When a network interface has been chosen, the interface needs to be configured, for example the IP address and additional information needs to be added. When the interface is configured, a registration request to the HA or FA in the network is send. In order to keep the changes invisible to the applications running on the node, the operating systems routing table needs to be updated. The default route used for sending out packets from the mobile node needs to be set to the new interface. Also the default gateway needs to be set. If the MN is located in the foreign network and reverse tunneling is used, the default gateway is set to the FA. The FA will tunnel packets to

69 5.3 Mobile IP 69 the HA which will forward it to the destination. If the MN is located in its home network the default gateway could be set to the HA which could forward the packets, or the default gateway of the network Implementation Since the only interest for the project is to compare different kind of techniques to achieve mobility in IP networks, and working implementation of the Mobile IP software is developed, an existing software package will be used. The Dynamic Mobile IP System was developed at Helsinki University of Technology (HUT) and the implementation makes it possible to measure handover times in a Mobile IP environment. The Dynamics software is divided into the three agents, and has a number of features that makes it possible to try different scenarios. Two main scenarios can be made with the Dynamics software, one taking advantage of using MN decapsulation and co-located care of address, and another scenario where FA decapsulation is used. In chapter ***: ref to Mobility in Reality the applications of the two scenarios are discussed, and since the scenario can be used in different kind of applications, measurements on both will be conducted and analyzed. ***: Should the measurements be conducted with Birdstep also? Note from Lars: Synes godt vi kan fortælle, at Birdstep også er en mulighed, og at vi har lavet forsøg med denne. Hvorvidt vi skal inkludere disse forsøg er jeg lidt i tvivl om. Det er heller ikke sikkert, at det lige skal være i dette afsnit denne tekst skal være. Since the Dynamic software is developed to the Linux platform under the Generel Public License (GPL) the source code for the project is available, in case unexpected behavior occurs. Since the operating system used is Fedora, it is easier to make modifications to the OS if this is necessary. The setup of the Dynamics and configurations scripts for the HA, FA and the Mobile Node Agent can be found in appendix ***: ref to appendix, were also scripts for conducting different kind of handovers can be found Measurement scenarios Between the three access points in the setup a handover can be conducted. Since two kinds of main scenarios is investigated, and the handover can be made from one access point to the other, but also the other way, a total of 12 handovers can be conducted. Some of the handovers will be identically in the two main scenarios, and a further discussion on which handovers will be duplicates and why will be given when describing the main scenarios. The setup of the three different kind of handover which can be made, will be described further, after that the major scenarios and the handling of these will described.

70 70 Chapter 5. Experimental implementation and measurements Home Bluetooth to Home WLAN HA Stream server MIP registration WLAN Bluetooth Bluetooth WLAN Bluetooth WLAN Mobile Node Mobile Node Incoming stream packets Figure 5.7: Home Bluetooth to Home WLAN setup Figure 5.7 shows the setup where a handover is made between the two different access points in the home network. The handover is very similar to the handover made using the Migrating IP concept. Since a MIP agent is used to make the handover, and this needs to be informed about the changes in the network connection, the handover time can be different than the one measured with Migrating IP. Since only a limited amount of tasks needs to be done to conduct the handover, and two different interfaces is used for the handover, the handover time should be relatively low. To measure the handover it is necessary to monitor incoming stream packet flow at the network interfaces on the mobile node, and analyze these. To see the MIP registration sequence the packet flow on HA can be monitored.

71 5.3 Mobile IP Home Bluetooth to foreign WLAN HA Stream server MIP registration WLAN Bluetooth Bluetooth WLAN Bluetooth WLAN Mobile Node Mobile Node Incoming stream packets Figure 5.8: Home Bluetooth to foreign WLAN setup Figure 5.8 shows the setup for conducting a handover between the Bluetooth access point in the home network, and the WLAN access point in the foreign network. The handover introduces some of the features of the MIP, which can be observed in the network. The MIP registration can be monitored at the FA, where incoming packets from the MN and outgoing packets to the HA can be observed in the packet flow. To measure the handover time the streaming packets to MN can be monitored at the network interfaces on the MN. Since the handover is conducted between two different interfaces the handover time will be relative low, but since the handover is made between two different subnets and therefore requires more packets through the network, the handover time will probably be higher than in the first scenario.

72 72 Chapter 5. Experimental implementation and measurements Home WLAN to foreign WLAN HA Stream server MIP registration WLAN Bluetooth Bluetooth WLAN Bluetooth WLAN Mobile Node Mobile Node Incoming stream packets Figure 5.9: Home WLAN to foreign WLAN setup Figure 5.9 shows a setup to measure the handover time between WLAN access points in the subnets. This handover is similar to the prior described handover, except from the point that it is the same interface which is used. Since it takes some time to reconfigure the interface and associate it with the new access point, the handover will probably take longer time than in the cases where two interfaces are used. When two interfaces are used the MIP registration can start immediately because the other interface is already up and running, when only one interface is used the MIP registration can first be carried out when the interface is properly set up Scenarios with FA decapsulation The implementation of the Dynamics software simplifies the scenarios for using FA decapsulation, but makes it more difficult to make the IP address planning of the different subnets. When using FA decapsulation the network interface on the mobile node, statically needs to be assigned the home IP address. When the mobile node is located in the home network, packets are routed directly to the mobile node. When the MN is located in a foreign network, the HA encapsulates the intercepted packets to the MN and tunnels them to the FA, at the FA the packets are decapsulated and send out on the foreign subnet. Since the MN still have the same IP address as in the home network the destination IP address of the packet do not need to be changed. Always having the same IP also simplifies the sending of packets from the MN to another node, because when the MN is located in the foreign network the default router is set

73 5.3 Mobile IP 73 to the FA which encapsulates the packets and tunnels them to the HA. On the HA the packets are encapsulated and send out from the network. This simplifies the implementation because the sender or receiver fields in the IP packets, to or from the mobile node does not need to be altered. But the planning of the network needs to take into account that the IP address on the visiting MN in a foreign network does not overlap with a node in the foreign network. ***: Make a reference to the Dynamics Homepage The setup of the scenario using FA decapsulation is shown in figure ***: ref to picture. Figure 5.10 shows the packet flow in a handover between the home network and a foreign network. The correspondent node (CN) is streaming UDP packets to the MN, and the MN is handed over from the home network to the foreign network. CN HA MN FA UDP MN in home network MN in foreign network UDP UDP UDP UDP UDP UDP UDP UDP ARP UDP UDP UDP UDP ROUTER SOLICITATION MIP REG REQUEST MIP REG REPLY UDP TUNNEL AGENT ADVERTISMENT MIP REG REQUEST ARP MIP REG REPLY UDP UDP Dest: Source: ICMP Packet Dest: Source: ICMP Packet Dest: Source: Dest: Source: ARP Request Mobile IP Reg request Haddr= COA= Dest: Source: Mobile IP Reg request Haddr= COA= Dest: Source: Mobile IP Reg request NOT REAL Dest: Source: Mobile IP Reg Reply Haddr= Code=0 (Reg Accepted) Dest: Source: UDP NOT REAL Haddr= COA= Dest: Source: IPinIP Dest: Source: NOT REAL Figure 5.10: MIP FA decapsulation packet flow Figure ***: ref to ethereal dump MN and ***: ref to ethereal dump HA shows two screen dump of an Ethereal packet sniffing from a handover between the home network and the foreign network. ***: FIGURE: Dump of handover from the MN side, showing registration and tunnel ***: FIGURE: Dump of handover from the HA side, showing registration and tunnel The screen dumps show the packet flow during the handover. Since the packet flow from the CN to the MN can continue after the MN has been registered at the HA, it is possible to receive packets at the MN before a confirmation of the registration has been received at the MN.

74 74 Chapter 5. Experimental implementation and measurements Scenarios with MN decalsulation When using MN decapsulation the mobile node agent works like describes in the analysis. In the home network the MN can obtain an IP dynamically from the network, and packets are then forwarded through a tunnel from the HA and decapsulated at the MN, but to avoid the tunnel the MN can instead obtain the home address so packets will be routed directly to the MN, as in the scenario with FA decapsulation. When located in the foreign network the MN will register with the FA, which will forward the registration to the HA. When the registration is accepted, the HA will forward packets through a tunnel to the MN, which will decapsulate the packets. This will reduce the work needed by the FA, and reduce the overhead in the network, but it will increase the work at the MN and some of the applications which can be obtained with FA decapsulation will be lost. To avoid making the handover time dependent on the dhcp client and dhcp server implementation, static IP addresses are used both in the home network and the foreign network. In the home network the home address is used, and in the foreign network a statically assigned IP address will be used. ***: Skal der evt. være nogle screendumps her? Synes ikke det er nødvendigt med et packet flow som i den tidligere... ***: Skal der stå andre ting under MN decap? Results NOT FINISHED All result is based on a handover caused by a script. This means that both network interfaces is still available for packet receiving. The handover time is measured from the point where the packages is received in sequence on the interface, to the point where the packets is again received in sequence on the other interface. Handover time Temp Explanation Foreign WLAN to Home BlueTooth 0, , , Home BlueTooth to Foreign WLAN 0, , , Foreign WLAN to Hone WLAN 3, , , The mobile IP client does not know the change in IP, and therefor it will have to wait for a Agent Advertisement. Home WLAN to Foreign WLAN 1, , , Home BlueTooth to Home WLAN 0, , , Home WLAN to Home Bluetooth 0, , ,207433

75 5.3 Mobile IP 75 Graphs describing the results, and an explanation of the results Conclusion NOT FINISHED Analysis of the results, identifying problems, and suggesting solutions for this. Suggesting optimization.

76

77 6Results In this chapter the results of the measurements described in Chapter 5 will be presented. Also, this chapter includes analysis of the results. 6.1 Definitions First the definition of handover time will be stated. This definition is in force througout the whole project Handover time ***: Noget introducerende tekst mangler - hvorfor 5 pakker mv. This definition of handover time will be used in the remaining chapters of this report. A handover is started, when a packet is received out of sequence with respect to the last 5 received packets, and this out of sequence is motivated by a vertical handover, see Section 2.1. A handover is ended, when 5 packets are received in sequence on the interface whereto the handover was performed. If the packets stay in sequence although a handover has been performed, the handover time starts from the last packet received on the interface, which is handing its connection over to another. The handover is ended, when the first packet is received on the interface whereto the handover was performed Statistic The statistic which have been aplyed to the the measurement results are presented in Appendix??. 77

78 78 Chapter 6. Results 6.2 Migrating IP In this section the measurement results, which have been conducted using the setup described in Chapter 5 will be presented A single sample Figure 6.1 shows the packet flow during a handover from a Bluetooth (BT) to a WLAN connection. Figure 6.1 is an example of the 30 samples which have been measured and are the basis of determing the handover time Interpacket time Delay [s] Time [s] Figure 6.1: Packet flow during a handover from a Bluetooth to a WLAN connection. The X-axis shows the relative time from packet number 1 was captured. The y-axis shows

79 6.2 Migrating IP 79 the inter packet time between packets denoted in seconds. The handover 1 is highlighted by the two vertical bars in the area of 7th second relative time (red bars). The black bar indicates the time the handover is initiated and configuration of network interfaces is started. ***: color print The packet streamer sends 200 packets per second, hence the inter packet time is second. The inter packet time varies much more when the packets are streamed over the BT connection than over the WLAN interface. The BT variation is related to, that BT bundles packets - hence the inter packet time is sometimes very low (below the inter packet time the streamer sends them). ***: reason for high interpacket times. However the average inter packet time calculated for the packets received on the BT interface is second. It is not possible to determine the handover time with a precision greater than second, since this is the highest observed inter packet time. The variance is considerable lower for WLAN. The small discrepancies may be the result of two things ***: not completely finished thinking about this one: Traffic on the LAN segment; or it might be the packet streamer which is adjusting the sending rate for example due to some kind of system activities on the stream server (hence the stream software has been dispatched out). Figure 6.2 shows a handover which is performed from WLAN to BT. The axis s are the same as described above and so are the characteristic of the inter packet time on the two interfaces. As expected the graphs are very similar. 30 samples have been taken of each handover scheme. In the next section a closer look on these handover times will be conducted All measurements Figure 6.3 shows a histogram of the handover times vs. the number of measurements. The vertical bars show from the left the 99%, 95%, 90% confidence intervals and the mean of the handover times. Figure 6.3 shows that the average handover time is second with a standard deviation of Table 6.1 provides the values for the different confidence intervals. Figure 6.3 indicates that the handover times sometimes are smaller than second, which is the rate the packets are send with. This is due to the bundling mechanism on the BT interface, which we are handing over to, which causes a group of packets to arrive, hence ending the handover. ***: mangler wlan-bt has not been written yet ***: table Conclusion The average handover time from BT to WLAN was measured to seconds, and WLAN to BT took seconds. The relative low handover times were expected 1 Definition ***: ref til definition is used.

80 80 Chapter 6. Results 0.03 Interpacket time Delay [s] Time [s] Figure 6.2: Packet flow during a handover from a WLAN to Bluetooth connection.

81 6.2 Migrating IP 81 Figure 6.3: Histogram showing. For all 30 samples In sequence First packet Handover initiated Mean handover started Mean handover ended Mean Standard diviation Confidence interval 90% pos Confidence interval 90% neg Confidence interval 95% pos Confidence interval 95% neg Confidence interval 99% pos Confidence interval 99% neg Table 6.1: Details regarding BT to WLAN handover.