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: 55 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 0.1 Nomenclature Preliminary analysis Introductory What is a handover? Horizontal handover Vertical handover Analysis Mobility at the network layer 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 Mobility in reality Why and when to do a handover? Mobility applications Mobility interfacing Definition of handover time Mobile IP applications Experimental implementation and measurements Migrating IP

6 6 CONTENTS Setup Design Implementation Measurement scenarios Results Mobile IP Setup Design Implementation Measurement scenarios Results Conclusion Bibliography 53 Appendices 55 A Preliminary measurement 57 B Address Resolution Protocol 59 B.1 ARP and gratuitous ARP B.2 ARP packet structure C Mobile IP packets 63 C.1 Mobile IP C.1.1 Agent Advertisement C.1.2 Registration D SCTP packets 67 D.1 SCTP header and chunks D.1.1 Payload data D.1.2 INIT

7 CONTENTS 7 D.1.3 INIT ACK D.1.4 SACK E Source code 73 E.1 Migrating IP script

8

9 List of Figures 1.1 Difference in mobile generations Horizontal handover between two antennas Vertical handover between a GPRS and a WLAN network MIP and Migrating IP are operating on layer 3 in the OSI model 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 SCTP packet flow example SCTP packet flow example SCTP packet flow example Example of data communication using SIP MIP scenario where FA decapsulation is used MIP scenario where MN decapsulation is used Setup to test Migrating IP Activity diagram for the migrating script Bluetooth (bnep0) to WLAN (eth1) migration WLAN (eth1) to Bluetooth (bnep0) migration MIP setup Design of MIP agent software Home Bluetooth to Home WLAN setup Home Bluetooth to foreign WLAN setup

10 10 LIST OF FIGURES 4.9 Home WLAN to foreign WLAN setup MIP FA decapsulation packet flow A.1 Test setup of the preliminary measurement B.1 Sequence of an ARP request and reply B.2 Sequence of a gratuitous ARP request B.3 Packet structure of an ARP request C.1 The structure of an Agent Advertisement C.2 The structure of the registration request fields in a UDP packet C.3 The structure of the registration reply fields in a UDP packet D.1 SCTP packet structure D.2 SCTP Payload packet structure D.3 SCTP INIT packet structure D.4 SCTP INIT ACK packet structure D.5 SCTP SACK packet structure

11 List of Tables 4.1 Handover times measured in 6 experiments C.1 Registration reply codes (Sch03) Nomenclature 11

12

13 Preliminary problem statement The purpose of this project is to investigate performance when a vertical handover is being performed between a Wireless Local Area Network (WLAN) and a Bluetooth connection. It is important that handovers are performed seamless to the user. Interruptions in data or speak streams is often unacceptable, hence an investigation is required. If the investigations show the need of improvements an analysis will be performed in order to give a suggestion on a possible optimal solution. The investigation is conducted experimental and by using exsisting technologies regarding hardware as well as software. From the problem mentioned here the following initiating problem is stated: An experimental investigation of the performance during vertical handover between WLAN and Bluetooth is being performed. 13

14

15 1Preliminary analysis 1.1 Introductory People have always had a need to communicate, and through time our needs has 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: Difference in 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 will give the user high speed data on the mobile phone; witch will make it possible to make Video calls. Fourth generation will bind different wireless technologies together, so the user always will have access to fastest or 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 not noticeable, and different kind of existing techniques can be used for this approach. ***: Her kunne der godt være et billede af et fiktivt 4G netværk, samt en lille tekst derunder... 15

16 16 Chapter 1. Preliminary analysis 1.2 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 1.2. 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. Figure 1.2: Horizontal handover between two antennas. 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

17 1.2 What is a handover? 17 communication technology may be to achieve higher bandwidth or to use a less expensive communication technology. Figure 1.3 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 connected. Often networks consisting of more than one communication technology is denoted heterogeneous networks. GPRS WLAN Figure 1.3: 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. ***: Section about obtainment of IP address

18

19 2Analysis 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 the features of mobility on the network layer will be analysed by using the Mobile IP and Migrating as reference. Next theory of mobility on the transport layer will be analyzed. 2.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 2.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. 2.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 19

20 20 Chapter 2. Analysis Upper layers (layer 5, 6, 7) Transport layer (layer 4) Network layer (layer 3) Data link layer (layer 2) Mobile IP Migrating IP Physical layer (layer 1) Upper layers (layer 5, 6, 7) Transport layer (layer 4) Network layer (layer 3) Data link layer (layer 2) Figure 2.1: MIP and Migrating IP are operating on layer 3 in the OSI model. 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 2.2. 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 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, 7 in the OSI model) Transport layer (layer 4 in the OSI model) Network layer (layer 3 in the OSI model) Datalink layer (layer 2 in the OSI model) SCTP Physical layer (layer 1 in the OSI model) Upper layers (layer 5, 6, 7 in the OSI model) Transport layer (layer 4 in the OSI model) Network layer (layer 3 in the OSI model) Datalink layer (layer 2 in the OSI model) Figure 2.2: 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

21 2.2 Mobility at the transport layer 21 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 transmit 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 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 2.3: SCTP packet construction A SCTP packet is divided into one or more chunks. Each chunk can either contain control information or user data. Figure 2.3 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 2.4 on the next page 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.

22 22 Chapter 2. Analysis IP 1 IP 2 IP A IP B Figure 2.4: 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 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 2.5: SCTP initialization packet flow

23 2.2 Mobility at the transport layer 23 Initiating an association happens in four steps, Figure 2.5 on the facing page 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 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 2.6: SCTP streams Figure 2.6 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

24 24 Chapter 2. Analysis 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). 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 2.7: SCTP data and retransmission packet flow Figure 2.7 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 transmitted 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

25 2.2 Mobility at the transport layer 25 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. A4 A3 A2 A1 SCTP Packet A2 B9 B8 B7 B7 C2 B6 C5 C4 C3 C2 C1 Figure 2.8: SCTP packet flow example Figure 2.8 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 transmitted. 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 transmitted but has been lost, so no acknowledgement are received for the packet. Also the A2 packet has been transmitted 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 2.9: SCTP packet flow example Figure 2.9 shows the next stage of the example. Since A1 has been lost it will be retransmitted, A3 will also be transmitted, and the next package to send in the A queue will be A4. Since B7 and C2 has been transmitted 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.

26 26 Chapter 2. Analysis A6 A5 A4 SCTP Packet A3 A2, A1 B9 B8 A4 B8 B7 C6 C5 C4 C3 C2 Figure 2.10: SCTP packet flow example Figure 2.10 shows how the receiver queues are all sequenced right, and data can be transferred 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 transmitted, 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.

27 2.2 Mobility at the transport layer 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 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

28 28 Chapter 2. Analysis 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 transmit 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 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. 2.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. ***: Layer picture with application highlighted 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 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

29 (1) SIP REGISTER (2) SIP OK 2.3 Mobility at the application layer 29 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 2.11: Example of data communication using SIP Figure 2.11 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 with a SIP OK package, after this data between the two nodes can be transmitted. 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

30 30 Chapter 2. Analysis 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.

31 3Mobility 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. 3.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. 31

32 32 Chapter 3. 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 ***: TABEL ***: 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 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

33 3.1 Why and when to do a handover? 33 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 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 transmitted 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 Definition of handover time ***: Noget introducerende tekst mangler - hvorfor 5 pakker mv.

34 34 Chapter 3. Mobility in reality 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 1.2. 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. ***: 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? 3.2 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 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

35 3.2 Mobile IP applications 35 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 3.1: MIP scenario where FA decapsulation is used Figure 3.1 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 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.