project final thesis

PROJECT ID NUMBER OF MEMBERS

4

ANALYSIS OF MOBILE IP HANDOVER LATENCY AND PACKET LOSS ISSUES USING SIMULATION

SALMAN MUSTAFA

SALMAN SHABBIR

FAHID SARDAR

AWAIS MAQSOOD

FEB 2011

Department of Electrical Engineering

COMSATS INSTITUTE OF INFORMATION TECHNOLOGY

LAHORE – PAKISTAN

TITLE

SUPERVISOR NAME TERNAL / EXTERNAL

MEMBER NAME REG. NO. EMAIL ADDRESS

ASDD

ASD

CHECKLIST:

This work, entitled “ANALYSIS OF MOBILE IP HANDOVER LATENCY AND PACKET LOSS ISSUES USING SIMULATION” has been approved for the award of

Submission Form for Final-Year

PROJECT REPORT

Number of pages in this report

I/We have enclosed the soft-copy of this document along-with the codes and scripts created by myself/ourselves

YES / NO

My/Our supervisor has attested the attached document YES / NO

I/We confirm to state that this project is free from any type of plagiarism and misuse of copyrighted material

YES / NO

MEMBERS’ SIGNATURES

Supervisor’s Signature

Bachelors in Electrical Engineering

Date

31/01/2011

External Examiner:

Head of Department:

Department of Electrical Engineering

COMSATS INSTITUTE OF INFORMATION TECHNOLOGY

LAHORE – PAKISTAN

Declaration

“No portion of the work referred to in the dissertation has been submitted in support of an application for another degree or qualification of this or any other university/institute or other institution of learning”.

MEMBERS’ SIGNATURES

ACKNOWLEGEMENT

First of all, we are very thankful to ALLAH the almighty, who opened his doors of knowledge for us. Then we are very thankful to our advisor Sir Khurram Zaidi for all the supports, directions and motivation he provided to us. He was very flexible in allowing us to carry on our own research ideas. We are also very grateful to Sir Saim Ghafoor for their support for this research and for share his valuable skills to enhance our vision for this project. We would also like to take this opportunity to thank Dr. Hani Shaker, Engr.KhanAfsar& Engr. Adil Humaiyun for sparing their valuable time and for all the encouragement and support.

We would like to express our graduate to our parents for their incredible support in every moment of difficulty. They have done more than they could do to make sure that we could get the best education possible and have always encouraged us to try for the best. Finally we are especially thankful to our family without their moral support, it would have been impossible to finish this work.

ABSTRACT

MOBILE IP HANDOVER LATENCY AND PACKET LOSS ISSUES USING SIMILATION IN NS-2

The importance of mobile computing is increasing day by day because users desire to have continuous network connectivity to the internet having mobile node. The infrastructure of the internet is built on the collection of protocols called TCP/IP protocol suite. The basic protocols of this suit are transmission control protocol and internet protocol. Internet protocol needs the host location which is connected to internet. It is identified by an assigned IP address. Here a very important issue arose because when a user (host) changes its location, it has to change its IP address. But the protocols of higher level want the user to be fixed.

To solve this problem, internet engineering task force (IETF) [3] propose mobile internet protocol which is the extended form of internet protocol. Mobile IP allows the users to stay connected to the internet while moving and without changing their IP address. Now using mobile IP a user can change its location and the connection of the user will not be disturbed while moving. We will analyze about delay in mobile IP handover by implementing it with UDP (user datagram protocol) and TCP (transmission control protocol) in NS2. The issue of packet loss is also discussed.

Table of contents

CHAPTER 1

Introduction 12

1.1-Motivation 13

1.2-Analysis using simulations 13

1.3-Organizationof thesis 13

CHAPTER 2

Mobile IP2 14

2.1- Introduction 14

2.2- Hand off (Handover) 14

2.3-Types of handoff 15

2.3.1- Hard handoff 15

2.3.2- Soft handoff 15

2.3.3- Comparison 15

2.4- Protocol requirements 15

2.5- Goals 16

2.6- Assumptions 16

2.7- Mobile IP architecture 16

2.7.1- Entities and Terminologies 16

2.8- Mobile IP operation 18

2.8.1- Packets Delivery from MN 18

2.8.2- Packets Delivery to MN 18

2.9- Agent Discovery 19

2.9.1- Agent Advertisement 19

2.9.1.2- ICMP fields 20

2.9.2- Agent Solicitation 21

2.10- Registration 22

2.10.1- Registration Request 23

2.10.2- Registration Reply 24

2.10.3- Registration Successful 24

2.10.4- Registration denied by the foreign agent 24

2.10.5- Registration denied by the home agent 25

2.11- Tunneling and Encapsulation 25

2.11.1- IP-in-IP encapsulation 26

2.11.2- Minimal Encapsulation 27

2.11.3- Generic Routing Encapsulation 27

2.12- Triangular Routing 28

2.13- Route Optimization 29

2.13.1- Binding Request 29

2.13.2-Binding Update 29

2.13.3-Binding Acknowledgment 30

2.13.4-Binding Warning 30

2.14- Ingress Filtering problem 30

2.15- Reverse Tunneling 30

2.16- Mobile IPv6 30

CHAPTER 3

Network Simulator-2 32

3.1- Introduction 32

3.2- Programming Tools for NS-2 34

3.2.1- Object Oriented Tool Command Language 35

3.2.2- Event Scheduler 35

3.3- Components of Network 35

3.3.1- Routing and Nodes 35

3.3.1.1- Node Creation 35

3.3.1.2-Node Links 36

3.3.1.3-Description of Links 36

3.4- Tracing 37

3.4.1-Example of Packet Flow 37

3.5-Packet 38

3.6- Tools for NS Simulation 38

3.6.1-(Network Animator)NAM 38

3.6.2-AWK Script 39

3.6.2.1-AWK Program 39

3.6.2.2-Invocation Of AWK 39

3.7-GNU Plot 39

CHAPTER 4

Simulation of mobile IP in NS2 40

4.1-Introduction 40

4.2-Cases 42

4.2.1-CASE-1 42

4.2.1.1-Mobile IP Simulation (without Route Optimization) 43

4.2.1.2-Simulation results 43

4.2.1.3-More analysis of simulation 44

4.2.1.4-Latency Results 44

4.2.2-CASE-2 45

4.2.2.1-More Analysis 46

4.2.3-PACKET DELIVERY RATIO 47

4.2.3.1-PDR for TCP 47

4.2.3.2-PDR for UDP 48

CHAPTER 5

Conclusions and future work 51

5.1- Conclusions 51

5.2-Future work 51

List of abbreviations 52

References 53

Appendix 55

Table of Figures

Figure 1.1- Basic structure of mobile IP 12

Figure 2.1- Architecture of mobile IP 17

Figure 2.2- ICMP fields 19

Figure 2.3- Registration process 22

Figure 2.4- Registration request 23

Figure 2.5- Registration reply 24

Figure 2.6- IP encapsulation 26

Figure 2.7- IP-in-IP Encapsulation 26

Figure 2.8- GRE 28

Figure 2.9- Triangular routing. 29

Figure 2.10- Route optimization 31

Figure 3.1- NS user view 32

Figure 3.2- NS Simulation structure. 33

Figure 3.3- General Architecture of NS 34

Figure 3.4- Component in NS 36

Figure 3.5- Network animator 38

Figure 4.1-Mobile IP MN structure in NS-2 41

Figure 4.2- Mobile IP Structure of BS in NS-2 41

Figure 4.3-Mobile IP 42

Figure 4.4- TCP graph for Mobile IP handover 43

Figure 4.5- UDP graph for Mobile IP handover 45

Figure 4.6- Comparison of TCP and UDP 46

Figure 4.7- Graph for PDR of UDP and TCP 49

HAAA

CN

FA

MN

CHAPTER No 1

Introduction

1.1-Introduction:

The development in the field of wireless communication is rapidly increasing. The users demand that if they change their location continuously, the current communication session should carry on without any interruption. Due to this demand, IETF introduces Mobile IP to support the mobility of hosts.

The management of mobility of hosts done by mobile IP by using two network entities.One of which is home agent (HA) and the other is foreign agent (FA). Both foreign network and home network tell their current position continuously, both agents rapidly send agent advertisement messagein response .The MH checks out whether it is on its home network or foreign network by checking the agent advertisement message. If MH is in its home network it will use the normal IP to communicate with others. If MH is not in its home network then it will get an IP address named as Care of address (CoA) and then it will send registration message to home agent to tell it about its current location.The information sent by correspondent host (CH) to MH is transferred to MH’s home network normally. HA get this information and attach a new IP header, whose destination address is CoA and source address is HA’s address. This basic principal is shown in figure.

Mobile IP is very simple and effective scheme which provide mobility solution at network layer, but it also have two issues, Triangular routing and handoff. In this thesis, we will discuss the handoff issue.

Figure 1.1 Basic structure of mobile IP

1.2-Motivation:

Researchers and developers are doing a great job regarding the development of the technology for mobile agents. Due to their hard work, a number of different protocols are proposed in which Mobile IP the most is promising one.Mobile IP has been the key topic of research for the researchers in recent years. NS2 is the most popular real world network simulation tool. It also has support for Mobile IP in limited simulation environment.

1.3-Analysis using simulations:

In this project NS2 is the tool which is used for simulation. It is a free source and is the most popular real world network simulation tool. We can use NS2 to implement many different protocols e.g. TCP, UDP, Telnet, IP etc.

1.4-Organization of thesis:

The rest of the thesis is organized as follows.

Chapter 2 deals with the Mobile IP protocol and its requirements. Also it includes goals and assumptions of protocol. Thenext section explains the architecture of Mobile IP including all basic entities of the operations and protocol. The next section explains the packet delivery mechanisms and agent discovery and registration processes. The next section includes the types of encapsulation in Mobile IP. The last section covers the different issues in Mobile IP e.g. triangular routing and security issues etc…

Chapter 3 gives the brief introduction of NS2. The three sections explains OTcllanguage, event scheduling and network components respectively. Also it covers the detail of various simulation tools used with NS2.Chapter 4 describes the real work done in this project. In this chapter different parametric simulations of protocol (Mobile IP) including handover delay and packet loss. Also this chapter includes Tcl scripts used to simulate the topologies and also the AWK scripts to get results.

Chapter 5 gives the conclusions for the simulation results of chapter 4.

Chapter 2

Mobile IP

Mobile IP protocol defined by RFC 3344[1] explain in this chapter.Mobile IParchitecture, operation limitation, assumption,goal, requirements and Issues includes in this chapter.

2.1-Introduction:

The internet is the worldwide data communication network that connects which millions of user in the world.Every user inside the internet has unique IP address which is a globally unique address.End system sends and receives packets using IP addresses of the source and destination of packet in the header.Node makes the physical subnet when receive the packets.Node moved from its current subnet(if wired) to new subnet(if mobile node) then detached.New subnet requires a new IP address which is topological correct address.DHCH(Dynamic Host Configuration Protocol)[2] andDDNS (Dynamic Domain Name System) give solution when the Mobile Nodes are in millions this solution is invalid. The solution also invalid for real time application Mobile Node moves into a new network the connection break.Mobile IP is one of the better solutions.

Mobile IP Protocol proposed by IETE as RFC-3344(IP Mobility Support for IPV4,August 2002). The Protocol is basically designed for “supporting end system mobility while maintaining scalability, efficiency and compatibility with existing IP and application”.

2.2-Hand off

A mobile user who is calling within the range of only one base station will have no problem during call .but whenever he moves from one base station to another base station while calling the call should be transferred to the new base station. Otherwise call will be disconnected due to weak link with the current base station. This ability of call transferring is called handoff in mobile cellular system.At a time a mobile is linked to only one base station. The phenomenon of handoff starts when the signal strength of new base station at mobile is greater than current base station.The most basic form of handover is when a phonecall in progress is redirected from its current cell (called source) and its used channel in that cell to a new cell (called target) and a new channel. In terrestrial networks the source and the target cells may be served from two different cell sites or from one and the same cell site. Such a handover, in which the source and the target are different cells (even if they are on the same cell site) is called inter-cell handover. The purpose of inter-cell handover is to maintain the call as the subscriber is moving out of the area covered by the source cell and entering the area of the target cell.A special case is possible, in which the source and the target are one and the same cell and only the used channel is changed during the handover. Such a handover, in which the cell is not changed, is called intra-cell handover. The purpose of intra-cell handover is to change one channel, which may be interfered, or fading with a new clearer or less fading channel.

2.3-Types of Handoff:

There are two main types of handoff

Hard Handoff

Soft Handoff

2.3.1-Hard Handoff:

A hard handoff is that in which connection with the target cell cannot be established until the connection with the source cell isabolished; the hard handoff is also called as break before make. Hard handoff is instantaneous & used to minimize the distortion

2.3.2-Soft Handoff:

A soft handoff is that in which connection with the source cell is retained & used in parallel with the target cell. In this handoff connection is established before the connection is broken, so this handoff is called make before break.

2.3.3-Comparison:

An advantage of hard handoff is that only one channel is used during a single call. Another advantage of the hard handoff is that the phone's hardware does not need to be capable of receiving two or more channels in parallel, which makes it cheaper and simpler. Disadvantage of this handoff is that if it fails, the call may be terminated.

One advantage of the soft handovers is that the connection to the source cell is broken only when a reliable connection to the target cell has been established and therefore the chances that the call will be terminated abnormally due to a failed handovers are lower. However, by far a bigger advantage comes from the mere fact that simultaneously channels in multiple cells are maintained and the call could only fail if all of the channels are interfered or fade at the same time. Fading and interference in different channels are unrelated and therefore the probability of them taking place at one the same moment in all channels is very low. Thus the reliability of the connection becomes higher when the call is in a soft handover.

2.4-Protocol Requirements:

Protocol requirements by RFC 3344 are

A Mobile Node must be able to communicate with other nodes on the Internet when it changes its point of attachment to internet.

A Mobile Node must be able to communicate with other nodes which do not implement the mobility support.

All the messages used to update the nodes about the location of Mobile Node.

2.5-Goals:

The Node of Mobile IP (RFC 3344)with which we are dealing mostly is a Mobile node. Therefore it is attached with a wireless link. The bandwidth of wireless links is low and the bit error is high as compare to wired link. The basic purpose of the protocol is

“The number of administrative messages and control messages should be less and the size of both messages should be small”

2.6-Assumptions:

According to the protocol (RFC 3344) it is considered that,

The point of attachment of Mobile node should not change more than once in one second

The IP datagram (unicast)should be routed on the basis of destination address in the datagram header.

2.7-Mobile IP Architecture:

There are some basic entities and terminologies for Mobile IP which is given below.

2.7.1Entities and Terminologies:

Mobile Node:A node which changes its point of attachment once in one second from one subnet to another subnet is called Mobile node. The MN can change its point of attachment having same IP address.

Correspondent Node (CN): Any Mobile or wired node which communicates with MN is called CN.

Home Network: The network in which MN is present and connected to internet before any movement is the home network.

Foreign Network: The network in which the MN is entering after leaving its home network is foreign network. Foreign network is any network other than home network.

Home Agent: The home agent is the agent which contains the information about the Mobile node that what is the location of MN now. It also provides many other services to MN. We can implement HA in two ways.

a. We can implement HA in the default router in home network. In this case every packet which is passing through the router must pass through HA.

b. The other way is that HA can be implemented on any node in home network. In this method, there is a big disadvantage that the packet will pass through router twice. I.e. any packet sent by CN will come to router. Then the router will forward this packet to HA which will lead it to MN and then this packet will again pass through the router. This situation is called “Double-Crossing Problem”.

Foreign Agent (FA): Just like home agent, foreign agent is also a mobility agent in foreign network. FA is implemented in the default router. This provides many services to MN such as COA and security services etc…

MN MN

Internet

HAFA

CN

MN moves to FA

Tunnel

Home Agent (HoA): This is the IP address of the MN. HoA is fixed and it does not change even the MN moves to the foreign network. Home address is used to send and receive packets when a MN is present in its home network.

Care-of Address (CoA): When a MN moves from its home network to any other network that is called foreign network, a new IP address is assigned to MN which is called Care-of address or CoA. The MN uses this IP address to receive packets when it is in foreign network. CoA tells about the current location of MN. The CoA can be obtained in the following two ways.

a. Foreign Agent CoA: In this type of CoA, CoA is located on the foreign agent. The CoA is the IP address of FA which it now shares with the MN. In this type of CoA, FA is the tunnel end point.

b. CO-Located CoA: This type of CoA is not located at FA. Infect this is the correct IP address which a MN has got through DHCP. In this type of CoA, the tunnel end point is MN itself. In this type of CoA, there is no need of FA.

Figure 2.1, Architecture of mobile IP

2.8-Mobile IP Operation:

The basic architecture of Mobile IP is shown in above figure. In this figure all the entities are clearly shown such as HA, FA, CN, MN etc… there are two networks, the foreign network which the MN visits for some time and the home network of the MN. Both networks are connected to internet through routers with HA and FA is installed. A communication between CN and MN is described in the case when the MN is in foreign network.

The operation of mobile IP can be divided in to two parts.

a. Packets delivered by MN b. Packets delivered to MN

2.8.1-Packets delivered from MN:

When the MN is in foreign, it knows the IP address of the CN. So MN simply uses its own HoA (Home Address) as the address of source and the IP address of CN as the address of destination to send the packets to CN. The FA is used as a default router to forward the packets. It is important to keep in mind that while using the HoA of MN as source address we can face a problem called “Ingress Filtering” which will be explained in later section.

2.8.2-Packets delivered to MN:

A CN (correspondent node) sends packets to the HA which leads these packets to MN while communicating with MN. The source address of the packets is the IP address of the CN node and the address of MN is the destination address of the packets to send packets. There fore the mechanism used for routing of packets is ordinary one.

When the MN gets out of its home network and enters in to the foreign network, its IP address is changed with the IP address called Care-of address (CoA). This CoA may be FA CoA or it may me Co-located CoA. The CN still sending packets to the home network and it does not know that MN is moved to foreign network. In home network, HA receive these packets. The HA knows that the MN is now in foreign network because when MN moves to the foreign network, it sends a registration message to register its CoA with HA. There fore HA encapsulates the received packets for the MN and send those packets on the CoA of MN. Now the encapsulated packets are received either by directly MN or by the FA according to the type of CoA. The whole process is called tunneling. In tunneling the original message is encapsulated by HA and then sent through a tunnel and packets are received at the tunnel end point (FA or MN). Now at the tunnel end point, the packets are decapsulated. The summary of the whole process is given bellow.

MN move to foreign network and change HoA with CoA. MN registers the CoA with HA. CN sends packets to HoA of the MN and HA receives those packets. The HA encapsulates these packets and sends through a tunnel. The FA or MN receives the packets and decapsulate the packets. If FA receives the packets, packets are forward to MN and then decapsulated.

ICMP

Mobilityy

If we study above sections some questions arose in mind.

How the MN knows that it has moved to foreign network?

If MN knows that it has moved to foreign network then how it gets CoA?

The above questions points towards two basic mechanisms, agent advertisement and agent solicitation.

2.9-Agent Discovery:

When the MN moves from its home network to the foreign network, it requires some quick mechanism to detect the movement. There are two solutions for this problem provided by Mobile IP (RFC 3344).

2.9.1-Agent advertisement:

Router advertisement messages are repeatedly sent by FA and HA using ICMP (internet control message protocol) [5]. The advertisement messages carry the ICMP field and mobility extensions. The MN gets useful information from these messages which are required for detection of movement and for getting CoA.

There are two conditions for the agent advertisement message to be sent.

R bit is set in mobility extension in ICMP packet. The advertisement message is only sent in response to a certain agent solicitation message.

Figure 2.2 ICMP fields

2.9.1.1-ICMP Fields:

Type Code Checksum# addresses Address size Lifetime Router Address-1 Preference Level-1 Router Address-2 Preference Lvel-2 ---------------- --------------- ---------------Type = 16 Length Sequence NumberRegistration Lifetime R B H F M G V T X CoA-1 CoA-2 CoA-3 ---------- ---------- ----------

Type = 9, the field type is set to 9which tells us that the type of packet is ICMP. This is assigned by IANA (internet authority for assigning names and numbers)

Code: the code value tells the specific meaning. Its value may be 0 or 16. Code=0 if the packets are routed from MN and non-mobile nodes. Code =16 in this case packets are routed only from mobile node

Checksum: used for error correction. # addresses: used for the packets received by the MN Address size: the size of address which is advertised. 32 bit for IPv4. Lifetime: the duration for which address is valid. If this field becomes zero, the address

expires and can not be used. Router Address: the address which is advertised. Preference level: it is used for most desired router to get a new node. The router address

having highest preference level must be chose as CoA by MN. Mobility Extension Fields: Type = 16: specific for MN. Length: (6+4*N), in this 6 describes the number of bytes, sequence number, registration

lifetime, flags and reserved fields. N represents the care of address advertised. Sequence Number: it is the count of agent advertisement messages sent since the agent is

started. Registration Lifetime: it is the longest lifetime in seconds for which the agent is ready to

accept any registration request. The value 0xFFFF tells the infinity. This field is different from the lifetime field inside the ICMP router advertisement portion of agent advertisement.

R: indicates Registration request. Registration with this agent is required even when co-located care of address is used.

B: indication of busy. No registration will be accepted from additional MN by foreign agent. H: Home agent. It offers services as a home agent on link upon which the agent advertisement

message is sent. F: foreign agent. It offers services as a foreign agent on the link on which the agent

advertisement message is sent. M: minimal encapsulation. This agent deals with receiving tunneled datagram’s which use

minimal encapsulation. G: GRE encapsulation. This agent deals with receiving tunneled datagram’s which use GRE

encapsulation. r: sent as zero; ignored on reception. T: foreign agent supports reverse tunneling. X: Reserve for feature use. CoA’s,the advertised foreign agent care-of address (es) to provide by this foreign agent.If

the‘F’ bit is set then an agent advertisement must includes at least one care-of address.The number of care-of addresses present is finding the length field in the extent.

o All theAdvertisement messages are sent using source Address as that of the source

router whiles the destination address is set to either “limited broadcast” address (255.255.255.255) or the “multicast” address (224.0.0.1)

MN detects its movement when it gets an Agent Advertisement explain above MN is in the range of home network and not moved, when H bit is set. MN now in the range of FA and MUST register to the FA, when F bit set.

The RFC-3344 applies some limitations on these advertisement messages

The nominal interval at which Agent Advertisement are sent SHOULD be no larger than 1/3 of the advertisement lifetime given in the ICMP header. Interval may be shorter than 1/3 of the advertised lifetime. This allows a MN to miss three successive advertisements before deleting the agent from its list of valid Agents.

The transmission time for each advertisement SHOULD to be one by one order to avoid synchronization and subsequent collide to Agent

Advertisements sent by other Agents .This field has no relate to the “Registration lifetime” field within the MA Advertisements extension.

MN must process received Agent Advertisements. A MN can defferationate an Agent Advertisement message from other uses of the ICMP router Advertisement message by checking the number of advertised addresses and the total length field of the IP. When the IP total length of the ICMP message is larger than the number of Advertised Address, the left data is interpreted as one or more extensions.

If Advertised Address more than one,The MN SHOULD get the first address for its initial registration attempt. If registration attempt fails with a status code reject by the FA, The MN may retry the attempt with each subsequent Advertised Address in turn.

MN must ignore reserved bits in Agent Advertisements, do not allow to discarding this type of Advertisements. In this method new bits can be define later,without affecting the ability for MN to use Advertisements when the newly defined bits are not understood.

2.9.2-Agent Solicitation:

If the MN do not receive the Agent Advertisement message for some duration of time or the inter arrival time is too high of the Advertisement messages, and the MN do not got any CoA by DHCP, then MN will sent Agent solicitation messages. The operation of the message is also defined in RFC 1256 known as ICMP with mobility extension.MN may send an Agent solicitation to 224.0.0.1.1. All mobility Agents should respond to Agent Solicitations and Advertisement messages. If MN do not receive any response to the solicitation message, it must decrease the rate of solicitation exponentially to avoid the flooding the network otherwise it reaches a maximum interval b/w solicitation. The RFC-3344 defined some limitation on the solicitation process.

MA must limit the rate at which it sends multicast or broadcast Agent Advertisements ,The maximum rate SHOULD be select the Advertisements do not use extra network bandwidth.

MAreceives a router Solicitation must not require that the IP source address is address of neighbor.

MA may be configured to send Agent Advertisements is to response of an Agent Solicitation message

2.10-Registration:

After getting CoA now the next step is that to register CoA with HA. It is important to register CoA with HA because this registration tells HA the current location of MN. As there are two types of CoA also there are two ways of registration.

Registration Request

MN FA HA MN HA

Registration via FA (FA CoA) Direct Registration (Co-CoA)


Registration Reply

Registration Reply


Registration Reply

If the MN is using FA Care of address then the registration is done through FA. And if MN is using a co located Care of address then there is no use of FA. The MN will send the registration request message directly to HA which will create the mobility binding and then reply to the MN.

Both processes are explained in Figure below.

Figure 2.3 Registration process

2.10.1-Registration Request:

Now when MN have got CoA in foreign network, the MN using UDP datagram will send the registration request message to port 434. The care of address of MN is set as the source address of UDP packet and the destination address of UDP packet will be either FA (if registration is done via FA) or it will be HA (in case of registration).

32 Bits

Figure 2.4 Registration request

The different fields of registration request message are:

Type=1 this is for the registration request.

S: Simultaneous bindings. MN will request that the home agent will keep its previous mobility bindings when S bit is set.

B: Broadcast datagram. If B is set, it tells us that the mobile node request that the HA tunnel to MN any datagram which is received at home network.

D: Decapsulation by MN. For D the MN wills itself decapsulate the datagram’s which are sent on CoA.

M: Minimal encapsulation. It tells that the HA uses the minimal encapsulation for the datagram’s tunneled to MN.

G: GRE encapsulation. It tells that the HA uses the GRE encapsulation for the datagram’s tunneled to the MN.

R: Sent as zero and ignored when received. It should not assign for any other use.

T: Reserve tunneling request

X: Sent as zero and ignored on reception.

Lifetime: It is the time before the expiry of registration.

Home address: It is the IP address of MN.

Type 1 S B D M G R T X Lifetime

Home Address

Home Agent

Care-of Address

Identification

Extensions …

32 Bits

2.10.2-Registration reply:

Now when the HA has received the registration request, HA will reply back in response to the sender in form of registration reply message. The reply message is also a UDP packet. The source address of the registration request message become the destination address and the destination address of registration request message become the source address of registration reply message.

Figure 2.5 Registration reply

Type =3 for registration reply.

Code: it is a value which indicates the result of the registration request.

2.10.3-Registration Successful:

.0 for registration accepted. 1 for registration accepted but simultaneous mobility bindings unsupported

2.10.4-Registration denied by the foreign agent:

64 reason unspecified 65 administratively prohibited 66 insufficient resources 67 mobile node failed authentication 68 home agent failed authentication 69 requested lifetime too long 70 poorly formed request 71 poorly formed reply 72 requested encapsulation unavailable 73 reserved and unavailable 77 invalid care of address 78 registration timeout

Type 3 Code Lifetime

Home Address

Home Agent

Care-of Address

Identification

Extensions …

80 home network unreachable (ICMP error received) 81 home host unreachable (ICMP error received) 82 home agent port unreachable(ICMP error received) 88 home agent unreachable (ICMP error received)

2.10.5-Registration denied by the home agent:

128 reason unspecified 129 administratively prohibited 130 insufficient resources 131 mobile node failed authentication 132 foreign agent failed authentication 133registration identification mismatch 134 poorly formed request 135 too many simultaneous mobility bindings 136 unknown home agent address

The latest code values can be checked in IANA (internet authority of assigning numbers) [7]. The above code values are given in RFC3344

2.11-Tunneling and Encapsulation:

When a CN sends packets to the MN, they are received by HA. If MN is out of its home network, HA encapsulate the packets and then send them to MN through a tunnel.

The process of taking the packet having packet header and data in it and putting that packet into the data part of another packet is called encapsulation. This process is done at HA where HA receive the data packet from the CN and then put it into the data part of the new packet. That new packet has a home address of HA and CoA as a destination address.

In the figure, the packet which is on the top is the packet sent by CN which means that the source address is of CN and destination address is of MN. The next packet in the figure is the packet that is produced by HA in which source address is of HA and destination address is of CoA. The path that is followed by the encapsulated packet is called tunnel. A tunnel makes a virtual pipe for the data packets between a tunnel entry point and tunnel end point. In this case HA is the tunnel entry point and CoA is the tunnel end point.

MN CN Data

CoAHA Data

CoA HA MN CN Data

Destination Address

Source Address

IP Encapsulation

07152431

IP-in-IP Encapsulation

Figure 2.6 IP Encapsulation

2.11.1-IP-in-IP Encapsulation:

IP in IP encapsulation is a compulsory process for mobile IP. The figure below describes the encapsulated packet inside a tunnel. IPv4 standard is followed by the fields as proposed in RFC 791.

Figure 2.7 IP-in_IP Encapsulation

The important fields in above figure are explained below.

Ver, version. The value of this field is set 4 for IPv4.

OHL, outer header length. This field tells about the length of the outer header.

DS (TOS), Differentiated services (type of service).

Length, it contains the length of the whole encapsulated packet in data field of the outer packet.

Flags, used for fragmentation process.

Fragment offset, used in fragmentation.

TTL, time to live. This time must be high enough so that the packet can reach to the tunnel end point.

IP-in-IP, this is the representation of IP-in-IP encapsulation protocol. For IPv4, its value is set to 4.

IP checksum, used for error correction.

HA Address, IP address of HA of 32 bits.

CoA, it contains the destination address of the packet.

2.11.2-Minimal Encapsulation:

Minimal encapsulation is used to prevent or eliminate the fields which are not needed. For example the fragmentation field is not used normally. Minimal encapsulation is optional in Mobile IP.

2.11.3-Generic Routing Encapsulation:

IP-in-IP encapsulation and minimal encapsulation both are only applicable to IP packets. Generic routing encapsulation is applicable to IP packets as well as other network layer protocols. That’s why GRE is better than IP-in-IP and minimal encapsulation.

The figure 2.8 describes the basic method of GRE and also the new GRE header including the different fields of GRE encapsulated packet inside the tunnel. Here is a point to keep in mind that GRE is optional in mobile IP (RFC 3344).

Figure 2.8 GRE

2.12-Triangular Routing:

While using IPv4 protocol, the problem of triangular routing occurs. To more understand about Triangular Routing to revises sections in which we study about the delivery of packets end to and receive from the MN when it is away from its HN.We know from this part:

The packets sent by CN are first received by HA because packet contain HoA as source address and the HA pass these packets to MN through tunneling.

Then MN can send packets to CN directly to FA without involving HA by using HoA as source Address and CN IP address as destination address.

Above two points understanding into mind then explain with example A MN from UK and CN from Pakistan are shared data using their laptops in a conference at Lahore. Now the MN can use itsCoA send packet to CN which are delivered to CN by router which is also the default routerof the CN.But CN sends packets to MN the packets are first transferred to HA of MN (anywhere in UK) and HA forward these packets to CN in Pakistan.This issue is termed as “Triangular Routing”. This issue increases the Latency.

This problem causes latency and delays in communication then result very packet loss which cannot be afforded in real time applications. The solution this issue is called Route Optimization in Mobile IP

0 7 15 24 31

Ver IHL DS (TOS) LengthIP Identification Flags Fragment OffsetTTL GRE IP checksum HA IP address CoAC R S S re

cRsv ve

rProtocol

Checksum (Optional0 Offset (Optional) Key (Optional) Sequence number (Optional) Routing (Optional)

Ver IHL DS (TOS) Length

IP identification Flags Fragment Offset

TTL L4 Protocol IP Checksum

CN IP address

MN IP address

TCP/UDP Payload

HA CN

FA

MN

Triangular Routing

Figure 2.9 Triangular routing

2.13-Route Optimization:

The reason of this Triangular Routing problem in mobile IP is that the CN is sending the packets to the HN of MN while the MN has left its HN and has moved to FN. But CN does not know this.IfCN is informed about the current location of the MN or more important the CoA of the MN in FN so CN will send packets directly to CoA and not to HA.Thusthis issue is solved.This process of informing the CN about the CoA of the MN so directly sends packets to CoA is called Rout Optimization.Route Optimization introduction 4 new messages to mobile IP operation.

2.13.1-Binding Request:

The node want to know about the current location of the MN can send a binding request message to HA of the MN.The HA will check if the MN allows the permission of its current location. IfHA is allowed it will send a binding update message to the node.

2.13.2-Binding Update:

The HA sends this message to any CN in reply of binding request.The message contains the HoA of MN and the CoA.

2.13.3-Binding Acknowledgment:

CN MN FAold HA FAnew

1. Agent Solicitation

The binding acknowledgment message is send by the CN which receive the binding update message. It is send only if requested by the HA.

2.13.4-Binding Warning:

If HA send packets to MN but it has moved to FN, The FA which decapsulates packets for MN sends “Binding warning” to HA which contain the HoA of MN. The HA informed to other CN which has binding for that wrong CoA. The Binding Warning is send to CN if Rout Optimization is performed and packet contain the CN address rather than the HA address.

2.14-Ingress Filtering Problem:

“The ability of a router to accept packets only from those nodes which are using topologicallycorrects Address and drops all other packets”.This technique is implementing most of the routers.

The MN in a FN using a FA CoA sends packets to CN by using HoA as source address,problem is creates in some cases where router help Ingress Filtering mechanism.MN send a packets in which HoA is used source address and dropped by the routers because the HoA is not topologically correct in the FA.

2.15-Reverse Tunneling:

The Reverse Tunneling mechanism uses a Reverse Tunnel to forward packets to CN.The MN sends packets to CN indirectly via Reverse Tunnel using HA address as destination address and HoA as source address.HA encapsulates the packets for the MN.The encapsulation in the Reverse Tunnel uses CN address as destination address and source address as HA address. Thenthese packets are forwarded to CN.The HA address is now topologically correct address so those packets are not dropped router any where by implementing the ingress filter technique.

The reverse Tunnel Technique gives the facility to MN to participate in the multicast group inside the HN.Reverse Tunnel also increases the latency during packets transmission.

2.16-Mobile IPv6:

The new version of IP that is IPv6 was introduced by IETF in 1998. It provides the address space of 128 bits which is more than IPv4 and also there are many other methods which make life much easier. Many features were added in IPv6 as the extensions to support the IP mobility in IPv4 e.g. the new IPv6 mobility header and security using IPSec etc… There are many methods provided by IPv6 which makes the systems more efficient as compare to the Mobile IP. It gives a built in method to deal with the problem of triangular routing and ingress filtering problem. The feature IPSec provides the security for different mechanisms like registration messages. H. soliman, Flarion, and C. Castelluccia [3] proposed a new model of mobile IP to decrease the burden of signaling on the network.

Figure 2.10 Route Optimization

OTcl

Script

OTcl InterpreterNS Simulator Library

SimulationResults

Analysis

Chapter# 3

Network Simulator –2

3.1-Introduction:

NS is an open source simulator which drives the different events; it was developed at UC Berkeley which is famous for simulation of different IP networks. The network protocols implemented in NS are TCP (Transmission Control Protocol) and UDP (User Datagram Protocol).It also implements traffic source behavior such as FTP (File Transfer Protocol), Telnet, CBR (Constant Bit Rate) and VBR (Variable Bit Rate).

Multicasting and some of MAC layer protocols (CSMA/CA, CSMA/CD) for LAN simulations are also implemented in NS. NS is now used as a part of VINT project that develops tools for simulation results display, analysis and converters that convert network topologies generated by well known generators to NS formats. NS written in C++ and OTCL (Object Oriented Tool command language) which was developed at MIT is available. Basic structure of NS with examples is discussed in this document. Most of the figures used in describing the NS basic structure and network components are taken from the 5th VINT/NS simulator tutorial and the NS manual (formerly called” NS Notes and Documentation”).VINT project home page gives us more information about NS. Overall working model of NS-2 is shown in the figure. The TCL interpreter is used to interpret TCL script. Simulation results consist of two files, one is Trace file for graphical results and other one is NAM file for animation of network models.

Figure 3.1 NS user view

Event Schedulerns-2

Tclcl

Otcl NetworkComponenttcl8.0

NS Simulator Structure

Simplified user’s view is shown in Figure. Object Oriented Tcl is called OTcl. An OTcl script interpreter has a simulation event scheduler, network component object libraries and network setup (plumbing) module libraries. Plumbing modules are implemented as member functions of the base simulator object [19]. A user should write an OTcl script that initiates an event scheduler, set up the network topology using the network objects and plumbing functions in the library, and tell the traffic sources when to start an stop transmitting packets through the event scheduler. Above mentioned tasks are for the set up and run a simulation network. Network set up is termed as plumbing. In plumbing, possible data paths among network objects by setting the “neighbor” pointer of an object to the address of an appropriate object. When a user wants to make a new network object, user can make this object either by writing a new object or by making a compound object from the object library, at the end user plumb the data path through the object. In simple words, in NS-2, network is constructed using nodes which are connected using links; events are scheduled to pass between nodes through these links.

Figure 3.2 NS Simulator Structure

Major component of NS besides network objects is the event scheduler. Packet ID is the event in NS that is unique for path with scheduled time and pointer to an object that handles the event. An event scheduler keeps track of simulation time and fires all the events in the event queue scheduled for the current time. It is done by invoking appropriate network components, which usually are the ones who issued the events and let them do the proper action link with packet pointed by the event. Network components communicate with one another passing packet, however this don’t consume actual simulation time. Event scheduler is used to handle the packet delay issues. For example, a network switch component that simulate a switch with microseconds of switching delay issues an event for a packet to be switched to the scheduler as an event 20 microseconds later. The scheduler after 20 microseconds dequeues the event and fires it to the switch component, which then passes the packet to an appropriate output link component. Timer is very important for event scheduler. For example, TCP needs a timer to keep track of a packet transmission time out for retransmission which means transmission of a packet with same TCP packet number but different NS packet ID. Use of event scheduler by the timer is similar to the function of delay. The difference is that timer measures a time value associated with the packet and does an appropriate action related to that packet.

3.2-Programming Tools For NS:NS is written in C++ and OTcl. NS separates the data path implementations from the control path

implementations. For the reduction of packet and event processing time (not simulation time), the event scheduler and the basic network component objects in the data path are written and compiled in C++. The compiled objects are made available to the OTcl interpreter through an OTcl linkage that creates a matching OTcl object for each of the C++ objects and makes the control functions and the configurable variables specified by the C++ object act as member functions and member variables of the corresponding OTcl object. That’s the way to give the control of C++ object to OTcl. An object which is not in data path can be entirely implemented in OTcl.

Figure 3.3 General Architecture of NS

Above figure shows the general architecture of NS. A general user (not an NS developer) can be thought of standing at the left bottom corner, designing and running simulations in Tcl using the simulator objects in the OTcl library. The event scheduler and most of the network components are implemented in C++ and available to OTcl through an OTcl linkage that is implemented using tclcl (Tcl class library). The whole thing together makes NS, which is object oriented extended Tcl interpreter.

Figure shows, at the finishing of simulation, NS produces one or more text-based output files that contain detailed simulation data. The data can be used for simulation analysis or as an input to a graphical simulation display tool called Network Animator(NAM)that is developed as a part of VINT project.NAM has a fine graphical user interface similar to that of a CD player functions like play, fast forward, rewind, pause and so on ,it also has display speed controller. Moreover, it can graphically present information such as throughput and number of packet drops at each link accurate simulation analysis does not depend upon graphical information.

3.2.1-Object Oriented Tool Command Language (OTcl):

NS is an OTcl interpreter with network simulation object libraries, which is useful to know how to program in OTcl to use NS.

3.2.2-Event Scheduler:Discrete event schedulers are used in NS. The main user of an event scheduler is network components which simulate packet handling delay or that need timers. Figure shows each network object using an event scheduler. Note that a network object that issues an event is the one who handles the event later at scheduled time; also the data path between network objects is different from the event path.

NS Commands

o Create Scheduler-> $set ns [new simulator]o Schedule Event ->$set at <time><event>o Start Scheduler ->$ns run

3.3-Components of the Network:Mostly we use the compound network components. Ns have a partial OTcl class hierarchy. The root of hierarchy is the Tcl object class that is the super class of all OTcl library objects(scheduler, network components, timers and the other objects including NAM related ones).As an ancestor class of Tcl object, NS object class is the super class of all basic networks.

Component objects that handle packets, which may compose compound network objects such as nodes and links. The basic network components are further divided into two subclasses which are connector and classifier, based on the number of the possible output data paths. The basic network objects that have only one output data path are under the connector class and switching objects that have possible multiple output data paths are under the classified class.

3.3.1-Routing and Nodes:

A compound object composed of a node entry object and classifiers as shown in figure. There are two types of nodes in NS.

3.3.1.1-Node Creation

In NS-2, the network is constructed using nodes which are connected using links.

Following two command lines create two node objects and assign them the handles “n0” and “n1”.

set n0 [$ns node] set n1 [$ns node]

Application

Agent

Node# 1

Node# 2 LINK

The following command line creates 5 nodes, with handles n0 to n4.

for {set i 0} {$ i<5 } {incr i } {set n($i) [$ns node]}

To set the colour of the node.

$n0 color <colour>

Used colures are: black, red, blue, sea green.

3.3.1.2-Node Links:Two types of links are used:

a. A Simplex Link(one way)$ns simplex-link $n0 $n1 <bandwidth><delay><queue-type>

b. A Duplex Link(both way)$ns duplex-link $n0 $n1 <bandwidth><delay><queue-type>

3.3.1.3-Description of Links:

Another major compound object in NS is link. User creates a link using a duplex-link member function of a simulator object. Two simplex links in both directions are created as shown in figure. One thing to note is that an output queue of a node is actually implemented as a part of simplex link object. Packets defueled from a queue are passed to the delay objects that simulate the link delay, and packets dropped at a queue are sent to a Null Agent and are feed there. Finally, TTL object calculates time to live parameters for each packet received and updates the TTL field of the packet.

Figure 3.4 Components NS-2

3.4-Tracing:

Network activities are traced around simplex link. If a simulator is directed to trace network activities like specified using $ns trace-all file or $ns namtrace-all file, the links created after the command will have the following trace objects inserted as shown below. Users can also specifically create a trace object of type between given src (source) and dst (destination) nodes using the create-trace command. When each inserted trace object like EnqT, DeqT, DrpT and RecvT receives a packet, it will write to the specified trace file without consuming any simulation time and passes the packet to the next network object.A sample single line from trace file generated by NS-2 is followed as:

r200.481997774_2_AGT_72tcp 1060[13a 1 0 700]…… [0:0 1:0 32 1][32 0] 1 0

-*Different terms used in above statement are;

r: Packet received

200.48…: time stamp at which event occurred

_2_: node number

AGT: agent generated trace, it is a MAC information, other option include RTR, ifq

72: packet or event ID

TCP: packet used is tcp.

1060: packet size

[13a 1 0 800]: expected duration of packet transmission (13a (hex))

MAC id of the sender (1)

MAC id of the transmitter (0)

Packet type IP (800)

[0:0 1:0 32 1]: sender address; port# (0:0)

Receivers address; port# (1:0)

TTL (32)

Next hop address (1)

[32 0]: TCP sequence#, ack#

3.4.1-Example of Packet Flow:

Node and link are two most important network components. Consider a simple point to point network consists of two nodes n0 and n1 with addresses 0 and 1 respectively. Port 0 communicates with n0 communicate with TCP sink object attached to n1 port 0; FTP application is attached to TCP agent which asks to send data.

3.5-Packet

Stack of headers and an optional data space are in the composition of NS packet. A packet header format is initialized when a simulator object is created, where a stack of all registered headers such as the common header that is commonly used by any object as needed, IP header, TCP header, RTP header and trace header is defined. The offset of each header in the steak is recorded. What this means is that whether or not a desired header is used, a steak consist of all registered headers is created. When a packet is allocated by an agent, and a network object can access any header in the steak of a packet it compiles using the linked off set value. However if u want to implement an application that talks to another application cross the network. You might use this feature with the little alteration. Another for this to create a new header for the application and upgrading the underlying agent to writhe data received from the application to the new header.

3.6-Tools for NS simulation

a. NAMb. AWK script language

3.6.1-(Network Animator) NAM

Visual interpretation of network topology is provided by the NAM. It was developed as a part of VINT project. Features given below.

Visual interpretation of network topology. Execution directly from the Tcl script. Play, stop, fast forward, rewind, pause, display speed controller and a packet monitoring

facility like controls are used in NAM. Information like throughput and number of packets on each link is present. It also provides a drag and drop interface for creation of topologies.Figure shows the NAM application and ITS components.

Figure 3.5 Network animator

3.6.2-AWK Script

It is a test processing programming language. It is a utility for performing simple text processing tasks and it is a programming language for performing complex text processing tasks.

3.6.2.1-AWK Program

General form of AWK program.

BEGIN {<initializations>}

<Screen pattern > {<program actions>}

<Screen pattern > {<program actions>}

.

.

.

END {<final actions>}

3.6.2.2-Invocation of AWKInvocation as follows:

Awk [-F<ch>]{pgm} l {-f<pgm_file>}[<vars>][-l<data_file>]

Where:

Ch: field-separator character.

Pgm: awk command line program.

Pgm file: file containing an awk program.

Vars: awk variable initializations.

Data file: input data file.

3.7-GNU plot

GNU plot is software which is used for displaying different mathematical functions and numerical data. We can use experimental data to plot the graph. We will use GNU plot for the graph of simulation results.

Chapter 4

SIMULATION of MOBILE IP in NS2

4.1-Introduction:

We have used network simulator 2 (NS 2.34) for the simulation of mobile IP. Mobility model does not base on CMU’s mobility model instead it is based on wired model (links and nodes). It consists of Home Agent (HA), Foreign Agent (FA) & mobile host that moves b/w FA & HA. HA & FA are base station nodes while MH is basically the mobile NODE.

HA & FA are mobile nodes/MIPBS having a registering agent (regagent_) that sends Beacon out to the mobile nodes, sets up encapsulates&decapsulators, as required & replies to MH’s solicitation. The MH nodes are defined as mobile node/MIPMH, that also have (regagent_) but not have encapsulate&decapsulator, it also sends & receive beacons and sends out solicitation to HA or FA. SR node version of MH doesn’t have hierarchical classifier & RA agent forms the entry point of node.

Mobile Node/MIPBS broadcasts beacon or advertisement message to MH & MH also generates solicitation that is directly sent to requesting MH. The address of base station sends advertisement message when advertisement message is heard by MH, then care of address is used by MH. When MH moves from native to foreign domains its COA changes.

When reg-request (reply to ads) from MH, the base station checks its status that it is HA of MH. If it is not, it sets up its decapsulator& forwards the reg-request towards the HA of the MH. In other case base station is HA for the requesting MH, but COA doesn’t match its own, it sets up encapsulator& sends reg-request-reply back to the COA(address of the FA),who has forwarded the reg-request to it.

So all packets reached at the destination MH, HA would be tunneled through the encapsulator which encapsulates IP pkthdr with IPinIPhdr, now the destination is COA instead of MH. Foreign agent’s decapsulator receives these packets, removes the encapsulation and sends it to the MH. If the COA matches with HA, it just removes the encapsulation, and sends it to the MH. If the COA matches that of the HA, it removes the encapsulator and sends the reply back to MH, as MH has returned to its native domain. The mobile host sends out solicitations if it does not hear any AD’s from the base stations. When it receives AD’s, it changes it COA to the address of the HA/FA, it has heard the ad from, and replies back to the COA with the request for registration(reg-request).Initially MH may be in the range of HA and receives packets directly from its COA which is HA. Eventually when it moves from the range of HA to FA, the MH’s COA changes from it’s HA to that of FA. HA sets up encapsulator and tunnels all packets destined for MH towards for the FA. The FA decapsulatesthe packets and hands them over to MH. The data from MH destined for the world is always routed towards its current COA.

Figure 4.1 Mobile IP MH Structure in NS-2

Figure 4.2 Mobile IP Structure of BS in NS-2

4.2-CASES:

4.2.1-CASE 1:

In this case we use topology as shown in fig. The figure clearly illustrates the topology as two wired nodes W(0) & W(1), home agent(HA),a foreign agent(FA) and a mobile host(MH).The TCP session established between W(0) and MH. TheW(0) starts sending packets to MH for 10 seconds using FTP application. Then MH moves from home network to the foreign network for time 100 seconds, the MH moves with speed of 20 m/s. Then it moves again from foreign network to home network, then it also takes 100 seconds to move to home network. So this simulation stops at 250 seconds.

Figure 4.3 Mobile IP

4.2.1.1-Mobile IP SIMULATION (without Route Optimization):

This simulation explains the basic Mobile IP (MIPv4) without route optimization; this simulation consists of 1 mobile Node, 2 Correspondent nodes W (1) &W (2), a Home agent (HA) and a foreign agent. The TCP session creates between MN and W (1) and it still continued until the MN leaves its Home network.This simulation explains the packet loss occur during handover procedure.

4.2.1.2-Simulation results:

The above scripts generates a trace file named as final-out.tr and a nam trace file named as

Final-out.namfrom there we can get the results. We used Gnuplotfor graphical results.

AWK language script is used to extract information regarding registration delay from trace file.

GRAPH for the TCP:

Figure 4.4 TCP graph for Mobile IP handover Latency

The figure explains the graphical representation output of the simulation. The Y-axis shows the TCP packets transferred while the X-axis represents the Time in seconds. The connection breaks approximately at 113 seconds when the MN moves out of the range of the HA and enters into the range of foreign network. The packets loss is due to the delay in the CoA acquisition and registration process. The connection establishes at 163 seconds then MN again leave the foreign network and enters into the home network again, so the Graph shows packet loss which is due to the delay in the reregistration process and service. First delay is of 50 sec and the second delay is of 23 sec, which is a big delay and steps should be taken in order to reduce this delay.

4.2.1.3-More analysis of simulation:

The delay.tr file is further analyzed using an AWK script to calculate the where the MN received no packets (handover or registration delay). Thus the approximate time in seconds where packets are lost

At time= 113 seconds……………………………………..connection breaks

At time= 163 seconds……………………………………..connection reestablishes

Total delay= 50 seconds

At time =213 seconds……………………………………..connection breaks

At time=236 seconds………………………………………connection reestablishes

Total delay=23 seconds

The above analysis shows that the delay (Latency) during the Registration process is greater than the Deregistration process. This is because that the Deregistration mechanism is simpler, fast and efficient.

Packets Loss:

The packets sent by the CN and are passed through various paths and are delivered to the MN.

4.2.1.4-Packet Loss Results:

Packets send by W(0)toW(1):25450

Packets received by W(1) from W(0):25450

Packets Lost on this link:0

Packets send by W (1) to HA:25448

Packets received by HA from W(1):25448

Packets lost on this link:0

Packets send by W (1) to FA:7605

Packets received by W(1) from FA:7605

Packets lost on this link:0

Total Packets send by W(0) to MH:25450

Total Packets received by MH:25401

Packets Lost by MH:49

Packets send by W(0) to W(1) 25450Packets received by W(1) to W(0) 25450Packet lost on this link 0Packets send by W(1) to HA 25448Packets received by HA from W(1) 25448Packets lost on this link 0Packets send by W(1) to FA 7605Packets received by W(1) from FA 7605Packet lost on this link 0Total packets send by W(0) to MH 25450Total packets received by MH 25401Packets lost by MH 49

The above results show that there is no packet loss on the wired links as the wired links support the data rate set for the simulation. The total loss occurred at wireless channels .i.e. channel from HA to MH and channel from FA to MH. The analysis shows the net packet loss over the whole simulation time.

4.2.2-Case 2:

Now we use same scenario for the UDP delay, UDP agent and set up a CBR (Constant Bit Rate) application over UDP.REST of script is almost unchanged.

Gnuplot Graph:

Figure 4.5 UDP graph for Mobile IP handover Latency

The Graph clearly shows that using UDP and CBR application, we get handover delay are decreased up to a certain level. In this scenario, we have used the UDP traffic and because it doesn’t require any acknowledgement packets the packet overhead is quite low as compared to TCP. It shows basically that our voice traffic has lower delay in re-registering process as compared to TCP.

4.2.2.1-More Analysis:

The delay.tr file is further analyzed using an AWK script to calculate the time where MN received no packets that is called as handover. Thus approximate time where packets are lost.

At time = 113s………………Connection breaks

At time = 131s………………Connection reestablishes

Total Delay = 18seconds

At time = 212s………………Connection breaks

At time = 231s………………Connection reestablishes

Total delay = 19seconds

LATENCY:

Figure 4.6 Comparisons of TCP and UDP Latency

4.2.3-PACKET DELIVERY RATIO:

Total no of packets received by the sink over the total no of packets sent by the source.

We have compared the graphs of TCP and UDP in this project through the basic concept of packet delivery ratio. We have calculated the PDR at different instants. We have transferred packets at different time intervals and calculated the results, at every 50 seconds the packets sent & received checked by the script.

Table for TCP:

Time (Secs) Generated Packets

Received Packets Packet Delivery Ratio

END to END Delay

1-50 secs 12542 6326 50.43% 9839.05 ms

50-100 secs 28175 14211 50.43% 15957 ms

100-150 secs 32246 16254 50.40% 17462.4 ms

150-200 secs 43729 22151 50.65% 21932.7 ms

200-250 secs 51756 26175 50.573% 25024.6 ms

Table for UDP:

Time (Secs) Generated Packets

Received Packets Packet Delivery Ratio

END to END Delay

1-50 secs 10715 10710 100% 38.161 ms

50-100 secs 24209 24201 100% 19.36 ms

100-150 secs 37733 32010 84.83% 14.77 ms

150-200 secs 51229 45593 88.99% 10.75 ms

200-250 secs 64759 50964 78.69% 9.35 ms

4.2.3.1-PDR for TCP:

Now for the TCP, the results show the clear analysis, which protocol is best for the mobile IP HANDOVER.

At 1st 50 seconds for TCP:

Generated Packets = 12542Received Packets = 6326Packet Delivery Ratio = 50.4385%Average End-to-End Delay = 9839.05 ms

At 50 to 100 seconds for TCP:

Generated Packets = 28175Received Packets = 14211Packet Delivery Ratio = 50.4383%Average End-to-End Delay = 15957 ms






Generated Packets = 51756

Received Packets = 26175Packet Delivery Ratio = 50.5738%Average End-to-End Delay = 25024.6 ms

4.2.3.2-PDR for UDP:

Now for the UDP, the results show the clear analysis, which protocol is best for the mobile IP HANDOVER.

At 1st 50 seconds for UDP:

Generated Packets = 10715Received Packets= 10710Packet Delivery Ratio = 100.989%Average End-to-End Delay = 38.161 ms

At 50 to 100 seconds for UDP:








GNUPLOT Graph for the PDR:

Figure 4.7 Graph for PDR of UDP and TCP

The above figure shows the average packets delivery ratio through out the network. Both TCP and UDP flows are shown in the figure. When weanalysed the tcp flow the pdr line is stable at 50% value mostly during the run time, only a slight change has been noted for a while. That is quite low, but in tcp the packet overhead is large so we can justify this result to some extent, otherwise a new mechanism is needed in order to overcome this situation. While the second line shows the udp traffic and for intial 100 sec the pdr is at 100%, that is quite satisfactory, but after 100 th sec when the mobile node leaves the domain of HA, it tends to fall for some time, i.e. the re registration process. The overall PDR in case of UDP is better than TCP.

Chapter 5

Conclusions and future work

5.1-Conclusions:

This thesis describes the problem of handover delay analysis of a mobile agent in real world wireless application using simulation. The simulation is done in network simulator NS2. The different simulation models are developed through which the behavior of mobile agents in the different applications can be studied. The handover delay and the issues of packet loss in mobile IP inside different environments are explained here.

Through the simulation we have analyzed that the UDP Traffic has lower latency and higher packet delivery ratio, as compared to the TCP traffic flow. That is because of the higher packet overhead in case of TCP traffic. Steps should be taken in order to overcome the delay and lower Packet delivery ratio in case of TCP traffic. We will propose a mechanism for it, in our future work.

5.2-Future work:

The work done in this thesis may provide a stepping-stone for those who want to study the technology of mobile agent in different environments. After checking out the contribution of this thesis, the future extension can be,

In this thesis we simulate only the mobile IP for different parameters. This simulation can be extended for mobile IPv6 protocol. NS2.34 have no support for this protocol but Motorola labs have provided a module called MOBIWAN [22], in which mobile IPv6 can be simulated.

A big direction is to extend NS2 to support for Mobile IP in large networks. More work can be done to minimize the latency rate and packet loss issues while studying

this thesis.

List of Abbreviations

AGT Agent Generated Trace

CBR Constant bit rate

CN Correspondent node

CoA Care of address

DDNS Dynamic domain name system

DHCP Dynamic host configuration protocol

FA Foreign agent

FTP File transfer protocol

GRE Generic routing encapsulation

HA Home agent

HoA Home address

ICMP Internet control message protocol

IETF Internet engineering task force

IP Internet protocol

MD5 Message digits 5

MH Mobile host

MN Mobile node

NAM Network animator

NS Network simulator

OTcl Object oriented tcl

RFC Request for comments

Tcl Tool command language

Tclcl Tcl class library

TCP Transmission control protocol

TOS Type of service

References

[1] Perkins, C., Ed., "IP Mobility Support for IPv4", RFC 3344, August 2002.

[2] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.

[3] http:\\ www.iotf.org

[4] Postel, J., ed., "Transmission Control Protocol – DARPA Internet Program ProtocolSpecification", STD 7, RFC 793, USC/Information Sciences Institute, September 1981.

[5] Postel, J., "Internet Control Message Protocol - DARPA Internet Program ProtocolSpecification," RFC 792, USC/Information Science Institute, September 1981.

[6] Postel, J., "User Datagram Protocol", STD 6, RFC 768, USC/Information SciencesInstitute, August 1980.

[7] Postel, J., "Assigned Numbers," RFC 790, USC/Information SciencesInstitute, September 1981.

[8] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996.

[9] Perkins, C., "Minimal Encapsulation within IP", RFC 2004, October 1996.

[10] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 Specification", RFC 2473,December 1998.

[11] http:\\ www.linktionary.com\Tringular Routing

[12] http:\\ www.wikipedia.com\Routing Optimization

[13] http:\\www.wikipedia.com\Message Authentication

[14] Perkins, C., Ed., "IP Mobility Support for IPv4", RFC 3344, August 2002.

[15] S Deering, R Hinden, “Internet Protocol, Version 6 (IPv6) Specification” (December

1998), RFC2460 at http://www.ietf.org/rfc/rfc2460.txt

[16] D Johnson, C Perkins, J Arkko, “Mobility Support in IPv6 draft-ietf-mobileip-ipv6-24.txt”(June 30, 2003).Analysis of Mobile IP Handover Latency and Packet Loss using simulation Page 80

http://www.linktionary.com\Tringular

http://www.wikipedia.com\Routing

http://www.ietf.org/rfc/rfc2460.txt

http://www.iotf.org/

[17] The Network Animator [accessed 15 January 2003]. Available fromhttp://www.isi.edu/nsnam/nam/.

[18] UC Berkelay

[19] http:\\www.isi.edu/nsnam/ns/ns—documentation.html NS Manual

[20] http:\\www.isi.edu/nsnam/nam/NAM Network Animator

[21] http:\\www.xgraph.org/

[22] http:\\www.tracegraph.com/download.html

[23] http:\\www.vectorsite.net/tswk_1.html

[24] http:\\www.inrialpes.fr/planete/pub/mobiwan/

http://www.isi.edu/nsnam/nam/

APPENDIX:

#++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++# Script#++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++#“set opt(chan) Channel/WirelessChannel ;# channel type set opt(prop) Propagation/TwoRayGround ;# radio-propagation model set opt(netif) Phy/WirelessPhy ;# network interface type set opt(mac) Mac/802_11 ;# MAC type set opt(ifq) Queue/DropTail/PriQueue ;# interface queue type set opt(ll) LL ;# link layer type set opt(ant) Antenna/OmniAntenna ;# antenna model set opt(ifqlen) 50 ;# max packet in ifqset opt(nn) 1 ;# number of mobilenodessetnum_wired_nodes 2 ;# Number of Wired Nodes set opt(adhocRouting) DSDV ;# routing protocol set opt(x) 670 ;# x coordinate of topology set opt(y) 670 ;# y coordinate of topology

set opt(ftp1-start) 10.0 ;# Starting time of ftp set opt(stop) 250 ;# time to stop simulation

Mac/802_11 set dataRate_ 2.0e6 Mac/802_11 set RTSThreshold_ 3000

#===================================================================================================================================================# Set NS as simulatorset ns_ [new Simulator]$ns_ node-config -addressType set opt(chan) Channel/WirelessChannel ;# channel typeset opt(prop) Propagation/TwoRayGround ;# radio-propagation modelset opt(netif) Phy/WirelessPhy ;# network interface typeset opt(mac) Mac/802_11 ;# MAC typeset opt(ifq) Queue/DropTail/PriQueue ;# interface queue typeset opt(ll) LL ;# link layer typeset opt(ant) Antenna/OmniAntenna ;# antenna modelset opt(ifqlen) 50 ;# max packet in ifqset opt(nn) 1 ;# number of mobilenodessetnum_wired_nodes2 ;# Number of Wired Nodesset opt(adhocRouting) DSDV ;# routing protocolset opt(x) 670 ;# x coordinate of topologyset opt(y) 670 ;# y coordinate of topologyset opt(ftp1-start) 10.0 ;# Starting time of ftpset opt(stop) 250 ;# time to stop simulationMac/802_11 set dataRatehierarchicalAddrParams set domain_num_ 3 ;# number of domainslappendcluster_num 2 1 1 ;# number of clusters in each domainAddrParams set cluster_num_ $cluster_numlappendeilastlevel 1 1 2 1 ;# number of nodes in each cluster

AddrParams set nodes_num_ $eilastlevel ;# of each domain# Open trace and nam filessettracefd [open final-tcp.tr w]setnamtrace [open final-tcp.nam w]$ns_ trace-all $tracefd$ns_ namtrace-all-wireless $namtrace $opt(x) $opt(y)# Create topology objectsettopo [new Topography]$topoload_flatgrid $opt(x) $opt(y)# Create GOD objectcreate-god [expr $opt(nn) + 2]# Create Wired Nodesset temp {0.0.0 0.1.0} ;# hierarchical addressesfor {set i 0} {$i < $num_wired_nodes} {incr i} {set W($i) [$ns_ node [lindex $temp $i]]}# Configure for ForeignAgent and HomeAgent nodes$ns_ node-config -mobileIP ON \-adhocRouting $opt(adhocRouting) \-llType $opt(ll) \-macType $opt(mac) \-ifqType $opt(ifq) \-ifqLen $opt(ifqlen) \-antType $opt(ant) \-propType $opt(prop) \-phyType $opt(netif) \-channelType $opt(chan) \-topoInstance $topo \-wiredRouting ON \-agentTrace ON \-routerTrace OFF \-macTrace OFF# Create Home Agent and Foreign Agentset HA [$ns_ node 1.0.0]set FA [$ns_ node 2.0.0]$HA set X_ 1.00$HA set Y_ 2.00$HA set Z_ 0.00$FA set X_ 650.00$FA set Y_ 600.00$FA set Z_ 0.00# create links between wired and BaseStation nodes$ns_ duplex-link $W(0) $W(1) 5Mb 2ms DropTail$ns_ duplex-link $W(1) $HA 5Mb 2ms DropTail$ns_ duplex-link $W(1) $FA 5Mb 2ms DropTail$ns_ duplex-link-op $W(0) $W(1) orient down$ns_ duplex-link-op $W(1) $HA orient left-down$ns_ duplex-link-op $W(1) $FA orient right-down# create a mobile node (in the domain of the HA)# that is moving between HA and FA.$ns_ node-config –wired Routing OFFset MH [$ns_ node 1.0.1]setHAaddress [AddrParams addr2id [$HA node-addr]][$MH set regagent_] set home_agent_ $HAaddress$MH set Z_ 0.00

$MH set Y_ 2.00$MH set X_ 2.00# MH starts to move towards FA$ns_ at 100.00 "$MH setdest 640.00 610.00 20.00"# goes back to HA$ns_ at 200.00 "$MH setdest 2.00 2.00 20.00"# Define initial node position in nam$ns_ initial_node_pos $MH 20# Create Agents and establish a TCP session between nodesset tcp1 [new Agent/TCP]$tcp1 set class_ 2set sink1 [new Agent/TCPSink]$ns_ attach-agent $W(0) $tcp1$ns_ attach-agent $MH $sink1$ns_ connect $tcp1 $sink1set ftp1 [new Application/FTP]$ftp1 attach-agent $tcp1$ns_ at $opt(ftp1-start) "$ftp1 start"$ns_ at $opt(stop).0 "$MH reset";$ns_ at $opt(stop).0 "$HA reset";$ns_ at $opt(stop).0 "$FA reset";$ns_ at $opt(stop).0002 "puts \"NS EXITING...\" ; $ns_ halt"$ns_ at $opt(stop).0002 "finish"# Write a finish Procedureproc finish {} {global ns_ tracefdnamtraceclose $tracefdclose $namtraceexecnam final-out.nam&}

puts "Starting Simulation..."$ns_ run”

AWK Script:

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

BEGIN {

sim_end = 250; i=0;

while (i<=sim_end)

{ sec[i]=0; i+=1; };

}

{

if ($1=="r" && $7=="tcp" && $3=="_4_") {

sec [int($2)]+=$8;

};

}

END {

i=0;

While (i<=sim_end) {print i " " sec[i]*8; i+=1;};

}

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

For collection of Graphs, we used Gnuplot. The script for getting the graph is as under.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

set title "Mobile IP Handover"setxlabel "Time (Seconds) "setylabel "Packets Transfer "

setxrange [0:250]setyrange [0:1400000]

set grid

setboxwidth 20

plot "/home/salman/salman1/tcp/delay.tr" using 1:2 title 'TCP Flow' with lines points

set term post epsenhan "Times New Roman" 20

set out "tcp-delay.eps"; replot

=========================================================================

These are traced using an AWK Script to find the net packet loss.

===========================================================================

BEGIN {sent1=0; recv1=0; sent2=0; recv2=0; sent3=0; recv3=0; pktsent=0; pktrecv=0; pktlost=0;} {if ($1=="+" && $3=="0" && $4=="1" && $5=="tcp"){sent1 +=1;} if ($1=="-" && $3=="0" && $4=="1" && $5=="tcp"){recv1 +=1;}pktlost1=sent1-recv1;if ($1=="+" && $3=="1" && $4=="2" && $5=="tcp"){sent2 +=1;}if ($1=="-" && $3=="1" && $4=="2" && $5=="tcp"){recv2 +=1;}pktlost2=sent2-recv2;if ($1=="+" && $3=="1" && $4=="3" && $5=="tcp"){sent3 +=1;}if ($1=="-" && $3=="1" && $4=="3" && $5=="tcp"){recv3 +=1;}pktlost3=sent3-recv3;if ($1=="+" && $3=="0" && $4=="1" && $5=="tcp"){pktsent+=1;}if ($1=="r" && $3=="_4_" && $7=="tcp"){Pktrecv+=1 ;}Pktlost=pktsent-pktrecv;}END {print "\nPackets send by W(0) to W(1):" sent1;print "\nPackets received by W(1) from W(0):" recv1;print "\nPackets Lost on this link:" pktlost1;print "\nPackets send by W(1) to HA:" sent2;print "\nPackets received by HA from W(1):" recv2;print "\nPackets lost on this link:" pktlost2;print "\nPackets send by W(1) to FA:" sent3;print "\nPackets received by W(1) from FA:" recv3;print "\nPackets lost on this link:" pktlost3;print "\nTotal Packets send by W(0) to MH:" pktsent;print "\nTotal Packets received by MH:" pktrecv;print "\nPackets Lost by MH:" pktlost;}

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++======================================================================

TCL script for the PDR:

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

BEGIN {seqno = -1; droppedPackets = 0; receivedPackets = 0; count = 0;}

{#packet delivery ratioif($4 == "AGT" && $1 == "s" &&seqno< $6 && $2 <= 250)

{seqno = $6;}else if(($4 == "AGT") && ($1 == "r") && ($2 <= 250)) {receivedPackets++;} else if ($1 == "D" && $7 == "tcp" && $8 > 512 && $2 <= 250 ){droppedPackets++;}

#end-to-end delayif($4 == "AGT" && $1 == "s")

{start_time[$6] = $2;}else if(($7 == "tcp") && ($1 == "r")){end_time[$6] = $2;} else if($1 == "D" && $7 == "tcp"){end_time[$6] = -1;}}

END {for(i=0; i<=seqno; i++){if(end_time[i] > 0) {delay[i] = end_time[i] - start_time[i];count++;}else{delay[i] = -1;}}for(i=0; i<count; i++){if(delay[i] > 0) {n_to_n_delay = n_to_n_delay + delay[i];}}n_to_n_delay = n_to_n_delay/count;print "\n";print "GeneratedPackets = " seqno+1;print "ReceivedPackets = " receivedPackets;print "Packet Delivery Ratio = " receivedPackets/(seqno+1)*100"%";print "Total Dropped Packets = " droppedPackets;print "Average End-to-End Delay = " n_to_n_delay * 1000 " ms";print "\n";}

$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$

TCL SCRIPT for the PDR GRAPH:

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

set title "Mobile IP Handover"setxlabel "Time (Seconds) "setylabel "Packet Delivery Ratio (%)"

setxrange [0:250]setyrange [0:103]

set grid

setboxwidth 20

plot "/home/salman/salman1/pdr/pdr.tr" using 1:2 title 'TCP Flow' with linespoints, \ "/home/salman/salman1/pdr/pdr.tr" using 3:4 title 'UDP Flow' with linespoints

set term post epsenhan "Times New Roman" 20 set out "pdr.eps"; replot

project final thesis

Documents