[Microsoft Word format].doc

Final Year Dissertation – Seamless Roaming Between Wireless Networks

University of PortsmouthComputing & Mathematics Area

Final Year Dissertation undertaken in fulfilment of the requirements for the BSc (Honours) Degree in Computer

Science

Seamless Roaming Between Wireless Networks

By James Saunders (106228)

SupervisorDr Mo Adda

Project UnitPC.PJE40

May 2004

With Support from

Intel Corporation (UK) and Orange (PCS) Ltd


Abstract

This project is concerned with the research and development of a solution which would help mobile nodes to roam between different types of wireless network seamlessly.

The two wireless network protocols that are of interest in this project are 802.11b (WiFi), a wireless local area network which is increasingly being used in homes and offices, and GPRS, a wireless wide area network which works as a data extension to the GSM mobile phone network.

The project commences by researching current wireless network technologies and solutions. Subsequently the problem is discussed in further detail and a new software based solution, which would decrease network swapping errors, is proposed and documented.

The new solution, NetSwap, is implemented in network simulation software and tested against results from previous tests with encouraging results.


Acknowledgements

Thank you…

Dr. Mo Adda, from Portsmouth University for supervising the project and advice on networking knowledge.

Claire Hayward, my wonderful girlfriend, for her amazing love, encouragement and understanding as I stressed through parts of this project.

Mark Sage, from Orange (PCS) Ltd, for his support in providing GPRS for the duration of the project.

The whole of the ADC team from Intel, for their support during my work placement and for supplying me with Wireless networking hardware.

"Because you have so little faith. I tell you the truth, if you have faith as small as a mustard seed, you can say to this mountain, 'Move from here to there' and it

will move. Nothing will be impossible for you." --Matthew 17:20


Project SpecificationAims and Objectives

The aim of this project is to produce a solution which would reduce the packet loss and errors incurred while roaming between different types of wireless network; this in turn is hoped to increase the speed at which a mobile node switches when roaming between them.

In order to solve the problem, in depth research must be done as to exactly why it occurs and a study made of the current technology and solutions.

To measure the success of this project, comparisons will need to be made in order to measure the performance of the proposed solution against a scenario recreating the problem as described previously, as well as comparisons to existing solutions.

The end result should be a software based solution which could eventually be developed to run on any type of mobile node communicating with one or more types of wireless network. It should also take into consideration the possibility of newer wireless network technologies which are likely to be developed in the future.

ConstraintsResources

Hardware issues and limitations may restrict the progress of this project.

Software constraints may include a lack of functionality in prerequisite software such as drivers and simulation tools, problems with word processing and image software used in the creation of the project report, and programming language compiler problems.

Time

The project must be completed in time for the hand in deadline of the 4th May 2004.

Because of the author’s commitments to other university units, the time allocated to this project will require careful planning.

A presentation of the project may need to be given to Intel Corporation and Orange (PCS) Ltd, but no deadline has been given for this to date.

Knowledge

Networking Knowledge. At the start of this project the author’s knowledge on certain networking subjects may not be sufficient. It may become evident during the research stage that the author’s ideas are not viable.

The author may require further training and education concerning some aspects of programming, particularly those concerning networking and object orientation.


Project PlanningTime Management

Major activities to be undertaken in the course of the project:

Literature Survey - Perform background research and gain a knowledge network of protocols, packet headers and infrastructure.

Produce UML Diagrams - Produce class diagrams, sequence diagrams to help in the design process of the project.

Create Pseudo Code - Produce pseudo code to back up UML diagrams for both driver and gateway.

Produce Before Results - Test to gain a set of results for how long network swapping takes before the new design is implemented. These results can be used to compare to the new implementation and hopefully advantages of the new design.

Produce Driver and Gateway - In simulation or physical hardware.

Produce After Results - Create a set of results for the new design, testing ping times, packet loss and speed of roaming transition.

Write-up - Results, conclusion, evaluation, future ideas, improvements, problems.

Meetings with Supervisor - Regular meetings should be made over the period of this project with the project supervisor Dr. Mo Adda. These meeting will be used to discuss project progress, exchange ideas, perform tests and discuss report layout.


Project PlanningGantt Chart

The following Gantt chart shows a graphical representation of the duration of the tasks to be undergone during this project against the progression of time.

Oct Nov Dec Jan Feb Mar April May

1 Literature Survey30 Days 01/10/03 30/10/03

2 Produce UML Diagrams 7 Days 30/10/03 06/11/03

3 Create Pseudo Code7 Days 30/10/03 06/11/03

4 Produce Before Results 17 Days 06/11/03 23/11/03

5 Produce Driver70 Days 23/11/03 30/01/04

6 Produce Gateway70 Days 23/11/03 30/01/04

7 Produce Results20 Days 30/01/04 19/02/04

8 Write-up70 Days 19/02/04 17/04/04

9 Proof Read & Print Report 7 Days 18/04/04 01/05/04

10 Meetings With Supervisor Every 2 weeks

11 Hand In1 Day 04/05/04 04/05/04


Contents

Project Specification 4Aims and Objectives 4Constraints 4

Resources 4Time 4Knowledge 4

Project Planning 5Time Management 5Gantt chart 6

1. Introduction 91.1 Background 91.2 The Problem 10

2. Network Technology Research 112.1 Ethernet 11

2.1.1 Ethernet Background 112.1.2 Ethernet Frames 122.1.3 Ethernet Speeds 12

2.2 WiFi 802.11a/b 132.2.1 WiFi Background 132.2.2 WiFi Technology/Infrastructure 142.2.3 WiFi Frames 152.2.4 WiFi Speeds 15

2.3 GPRS (General Packet Radio Service) 162.3.1 GPRS Background 162.3.2 GPRS Technology/Infrastructure 182.3.3 GPRS Frames 192.3.4 GPRS Speeds 20

3. Current Solutions 213.1 Mobile IP 21

3.1.1 Mobile IP Detail 223.1.2 Problems with Mobile IP 23

3.2 Occasionally Connected Computing (OCC) 243.2.1 Problems with OOC 25

3.3 DSP Silicon Methods 263.3.1 System on Chip (SoC) 263.3.2 Software Defined Radio (SDR) 273.3.3 Problems with DSP Silicon Methods 27

4. Analysis and Design 284.1 Brief 28

4.1.1 The NetSwap Driver 294.1.2 The NetSwap Gateway 30

4.2 Class Diagrams 314.3 Sequence Diagrams 32

4.3.1 Simple Scenario 324.3.2 If things go wrong 33

4.4 Pseudo Code 345. Implementation 40

5.1 Physical Hardware Simulation 415.2 Physical Hardware Implementation 42

5.2.1 Software Used 425.2.2 Equipment Setup - Architecture 435.2.3 Simulating the effect of “Roaming” 445.2.4 Application Configuration 455.2.5 Recording Findings 45

5.3 Software Simulation of the NetSwap Idea 46


5.3.1 OPNET 475.3.2 QualNet 485.3.3 OMNeT++ 495.3.4 NS-2 50

5.4 NS-2 Implementation 515.4.1 Getting to know NS-2 515.4.2 Configuration 515.4.3 First NS-2 Tcl Script 525.4.4 Recreating problem in NS-2 545.4.5 Creating the NetSwap Agents 56

5.5 Problems and Restrictions of NS-2 625.5.1 Timer 625.5.2 Addressing Scheme 625.5.4 GPRS Patch 63

6. Testing and Evaluation 646.1 Physical Testing 64

6.1.1 Task Manager Network Monitor 656.1.2 CuteFTP 666.1.3 Streaming Audio using Microsoft Media Player 676.1.4 Ping 70

6.2 NS-2 Testing 716.2.1 FTP, before NetSwap implementation 726.2.2 FTP, after NetSwap implementation 73

6.3 Comparison of NS-2 & Physical Results 756.3.1 FTP Comparisons 756.3.2 Media Player Comparisons 756.3.3 Ping Comparisons 75

7. Conclusion and Future Work 767.1 Future Work 76

7.1.1 Real Hardware Implementation of NetSwap 767.1.2 Error Detection 767.1.3 Old IP address fallback 777.1.4 Changing of the return IP address 777.1.5 Multiple Users 77

8. Evaluation against the requirements 78

Bibliography 79

Glossary of Terms 81

Glossary of Symbols 82

Appendix A - Packet Headers 83IP Header 83TCP Header 84ICMP Header 86Ethernet Header & Trailer 87802.11 Wireless Header & Trailer 88RLC Downlink Header 89

Appendix B – NetSwap Classes 91

Appendix C - OSI Layers 92

Appendix D – Results 93

Appendix E – Main NS-2 NetSwap Code 94

Appendix F – NS-2 NetSwap Tcl Script 100


1. Introduction1.1 Background

The modern generation of subscribers do not want to be tied to a desk, study or office. Technologies such as mobile phones, PDA’s and laptop computers have become an everyday tool in people’s lives enabling them to become more mobile.

Mobile technology has advanced in recent years allowing people to communicate and access information via a number of methods. Internet, SMS and Chat/Messaging Services such as Microsoft Messenger, E-mail and VoIP, are some recently born methods of communication.

Technology trends such as these redefine the way in which people live, and create the need to connect mobile devices without wires; from this comes the birth of Wireless Networking.

There are a number of different types of wireless network protocols in existence today:

WiFi (Wireless Fidelity) or 802.11, a WLAN (Wireless Local Area Network) with a short range which works alongside Ethernet networks. To date, there are 3 varieties of WiFi (802.11a, 802.11b and 802.11g).

GPRS (General Packet Radio Service), a WWAN (Wireless Wide Area Network) which works as a data extension to the GSM mobile phone network, sometimes referred to as ‘GSM 2.5’.

UMTS or 3G, the third generation mobile phone network service developed by ETSI within the ITU standard named IMT-2000 (International Mobile Telecommunications-2000).

WiMAX, a Wireless Metropolitan standard for last-mile wireless technologies designed to provide broadband connectivity to homes. It is a joint effort from Intel and Alvarion, IEEE standard 802.16a.

Bluetooth, a PLAN (Personal Local Area Network), offers digital transmissions of both voice and data, used to replace many of the proprietary cables we use in the home and office to connect devices together such as PDA’s, Printers, Telephones, Keyboards etc.

HiperLAN/2, a specification developed by ETSI BRAN, which relies on cellular networking topology combined with an ad-hoc networking capability to provide a LAN service for office architecture or wider area networks.

As these protocols are all fairly new technologies developed by a variety of organisations for different purposes, not all of them are compatible and can therefore cause problems when roaming between them.

The two wireless network protocols which fall within the scope of this project are WiFi and GPRS.

http://portal.etsi.org/bran/home.asp


1.2 The Problem

Both the GPRS and WiFi wireless network types provide a degree of mobility. However, roaming between them is difficult. Take the following scenario:

An office worker, who begins working on his laptop in an office connected to a corporate WiFi network, may also wish to work while travelling home at the end of the day. On leaving the office, he also leaves the coverage range of the corporate WiFi network; he is still covered within range of a GPRS network. The worker may have to wait a considerable time while the computer detects the loss of one network connection (WiFi) and re-route all traffic to the new connection (GPRS). Due to the time delay, any network applications may timeout, throwing connection errors. The same problem may also occur when the worker reaches home and wants to change to his home WiFi network.

Fig 1.2a - Mobile Roaming Between WiFi and GPRS Networks

note: Throughout this project report the term ‘mobile node’ may be interchangeable with ‘laptop’, ‘mobile phone’ or ‘PDA’, and the term ‘WiFi’ may be interchangeable with ‘802.11a, b or g’.

The main problem, when roaming between different wireless network types, is that a mobile node must first detect the loss of a wireless connection and therefore its route to a destination. The mobile node then needs to find another available wireless connection, reset its routing tables and change protocol types, before it can then communicate across the new link.

During this process the correspondent node does not know when or where the mobile node has moved and therefore does not know where to send its replies.

This process takes time and may result in huge packet loss, during which any real-time network applications, such as streaming video and audio, file transfers and games may be likely to timeout.


2. Network Technology Research

The next two chapters contain background research into some of the networking technologies and mobility solutions which are of relevance to this project. This information will then be used later to help as a foundation in the Analysis and Design, Chapter 4.

2.1 Ethernet 2.1.1 Ethernet Background

Ethernet is a LAN (Local Area Network) technology invented by Robert Metcalfe and the combined efforts of Xerox, DEC and Intel in 1973. It was originally developed along with Xerox’s first ever laser printer as a means to connect many users to the same resource. Xerox needed a network fast enough to drive this high performance new printer, and to connect hundreds of computers within the same building.

The experimental Ethernet was used to link the computers (called “Altos”), servers and laser printers used in the Xerox building to each other. The signal clock for the experimental Ethernet interface was derived from the Alto's system clock. In initial experiments Ethernet gave an initial data transmission rate of 2.94 Mbps. [FERRERO99]

Metcalfe's first experimental network was called the Alto Aloha Network. He changed the name to "Ethernet," to make it clear that the system could support any computer, not just Altos, and also to point out that his new network mechanisms had evolved well beyond the Aloha system. He chose to base the name on the word "ether" as a way of describing an essential feature of the system; the physical medium (i.e. a cable) carries bits to all stations. “Ether”, or “Luminiferous Ether” was the hypothetical substance through which electromagnetic waves were thought to travel. This idea originated with the Greek philosopher Aristotle and was used in several optical theories as a way to explain propagation of light, which was believed to be impossible in “empty” space. Thus, the name Ethernet was born. [RAD04]

One of the reasons for Ethernet’s success was due to its simple design; a header containing a simple address, the payload data and a trailer checksum. The secret behind this simplicity is the background mechanism. Ethernet uses CSMA/CD (Carrier Sense Multiple Access/Collision Detect), a system whereby each device senses whether the line is idle and therefore available to be used. If it is free, the device begins to transmit its first frame. If another device has tried to send at the same time, a “collision” is said to occur and the frames from both systems are discarded. Each device then waits a random amount of time and retries until transmission has been successful. [FERRERO99]

Ethernet became an official standard in 1978 as the IEEE (Institute of Electrical and Electronic Engineers) released the standard 802.3.

Today Ethernet is used across the world and is the most widely used LAN technology, but not without a degree of evolution. Ethernet has evolved from its original incarnation of 10Base-T (IEEE 802.3) in 1978 to Fast Ethernet (IEEE 802.3u) in 1995, 1-Gigabit Ethernet (802.3z) in 1998 and 10-Gigabit Ethernet (802.3ae) in 2002. Ethernet has also been transmitted across various different mediums, including Coaxial Cable, CAT 5 Cable and Fibre Optic Cable. It has also been used as a base for the wireless standard 802.11b.


2.1.2 Ethernet Frames

An Ethernet frame has a maximum size of 1518 Bytes and a minimum size of 64 bytes so as to avoid the possibility of a sending device not detecting a collision. For this reason, an Ethernet frame contains a "pad field" in its trailer, which will be filled with junk if the data section does not make the frame at least 64 bytes long (excluding preamble and start delimiter). The structure of an IEEE 802.3 Ethernet frame is shown below:

Fig 2.1.2a - Ethernet FramesFor further information into the detail of the Headers see Appendix A

source: [CISCO03b]

The user data from the network application (e.g. Web Browser, e-mail client or file transfer system) is split into small segments. These are then appended with a TCP and IP header containing details of the source and destination of the data and the port number.

This frame is then passed onto the OSI data link layer where an Ethernet Header and Trailer are added. The Ethernet Header contains lower level source and destination addresses in the form of a MAC (Media Address Code) address. A MAC address is a unique 12 digit number assigned to each Ethernet Network Interface Card (NIC). This address is created by the card manufacturer. Each digit is a number from 0-9 or a letter from A-F. Sometimes the digits of a MAC address are separated by colons or dashes. (e.g. 00-02-B3-91-F7-34 or 00:02:B3:91:F7:34)

The Ethernet Trailer contains the Pad field and a CRC (Cyclic Redundancy Check) code which checks that the whole Ethernet frame is correct.

2.1.3 Ethernet Speeds

10Mbps Ethernet (IEEE 802.3) 100Mbps Fast Ethernet (IEEE 802.3u) 1000Mbps Gigabit Ethernet (IEEE 802.z/ab) 10000Mbps 10GbE (IEEE 802.3ae) Ethernet

IP Header

Application Layer

Transport Layer

Data Link Layer

Eth Header Eth Trailer

User Data

Network Layer

TCP Hdr

64 – 1518 Bytes


2.2 WiFi 802.11a/b2.2.1 WiFi Background

Around 1992, research began into the first Wireless LAN (WLAN) protocols operating in the unlicensed 2.4GHz frequency band. It was based on technology used by the military for mission-critical communication systems. Initially it was taken up by two business sectors – Healthcare and Education. Healthcare made the use of mobile computers which could be used in hospitals to gain access to patient information, while schools started installing wireless networks to avoid the high costs of wiring buildings.

In 1997, the IEEE (Institute of Electrical and Electronic Engineers) released the 802.11 standard for wireless networking.

Today several 802.11 standards exist. 802.11b is an expansion of the standard that allows transmission speeds of up to 11Mbps using FHSS (Frequency Hopping Spread Spectrum) and DSSS (Direct Sequence Spread Spectrum) in the 2.4Ghz radio frequency band. This radio band is free to use worldwide and has no licensing restrictions, thus it is widely used for other wireless devices like cordless phones, microwave ovens, garage doors and, more recently, Bluetooth - all of which can interfere with 802.11b. [ADDA03]

The next generation 802.11a is a bit more complex than 802.11b, but has greater benefits. Also known as WiFi5 for its use of the 5GHz band, 802.11a is based on OFDM (Orthogonal Frequency Division Multiplexing) technology, rather than DSSS. It operates in the 5.2GHz radio frequency band that has much less interference from other devices, resulting in its super fast data speeds of up to 54 Mbps or even higher.

[CISCO03c]

802.11g is the newest addition to the WiFi family and was officially registered as a final IEEE standard in June 2003. 802.11g supports speeds of up to 54Mbps but still works in the 2.4Ghz radio range.

Recently, the idea of “Hotspots” has been created to satisfy the need forwider, faster wireless internet access. The service industry sectors such as Hotels, Service Stations, Airports and Train Stations were amongst the first to provide wireless access on a pay per hour, subscription, scratch card or free ‘service-add’ basis.


2.2.2 WiFi Technology/Infrastructure

A wireless network consists of two main components – an access point and a wireless adapter. WiFi wireless networking works easily with any Ethernet network and can be installed by attaching an access point to existing switches. WiFi wireless adapters can work in two modes: Infrastructure mode works by having one or more base stations called access points. An access point acts as a wireless base to which many mobile devices can connect. They are then ordinarily connected to a standard Ethernet network. Wireless mobile devices can not talk directly to each other and can only communicate through an access point.

Fig 2.2.2a – Infrastructure Wireless Mode

Ad-Hoc mode allows Wireless Mobile Nodes to talk directly to each other without the need for an access point. Ad-Hoc mode is only ideal for two or three computers.

Fig 2.2.2b – Ad-Hoc Wireless Modesource: [KHADRA04a]


Frequency hopping works very much like its name implies. It takes the data signal and modulates it with a carrier signal that hops from frequency to frequency as a function of time over a wide band of frequencies. With frequency hopping spread spectrum, the carrier frequency changes periodically. This technique reduces interference because an interfering signal from a narrowband system will only affect the spread spectrum signal if both are transmitting at the same frequency simultaneously. Thus, the aggregate interference will be very low, resulting in little or no bit errors. A frequency hopping radio, for example, will hop the carrier frequency over the 2.4 GHz frequency band between 2.4 GHz and 2.483 GHz.

2.2.3 WiFi Frames

The 802.11 family uses a MAC layer known as CSMA/CA (Carrier Sense Multiple Access/Collision Avoidance). note: Classic Ethernet uses CSMA/CD (Collision Detection). CSMA/CA is, like all Ethernet protocols, peer-to-peer and there is no requirement for a master base station such as an access point.

Fig 2.2.3a – WiFi Frame Breakdown - For further information see Appendix Asource: [ZYTRAX03]

2.2.4 WiFi Speeds

54Mbps 5Ghz (IEEE 802.11a) 11Mbps 2.4Ghz (IEEE 802.11b) 54Mbps 2.4Ghz (IEEE 802.11g)

TCP HdrIP Header

Application Layer

Transport & Network Layer

Data Link Layer802.11b Hdr

User Data

802.11b CRC


2.3 GPRS (General Packet Radio Service)2.3.1 GPRS Background

The GPRS specification was written by the GSM association and is held by ETSI (European Telecommunications Standard Institute).

GPRS provides a wider variety of services for mobile devices like mobile phones and PDA’s, such as the ability to maintain voice and data communication simultaneously. The data service can be used for a number of applications such as;

E-commerce – banking, ticket purchasing, fast food ordering Location Based Applications – maps, place finder, train station

booking, advertising, games Office tasks – e-mail, calendar, converters

[GSMWORLD03]GPRS is an ‘always on’ service and therefore saves time connecting and dialling into an ISP. However, it does not constantly transfer data and for this reason many mobile service providers choose to charge on a pay per megabyte basis.

GPRS is a WWAN (Wireless Wide Area Network) which provides an IP based packet switching service over the GSM (Global System for Mobile communications) mobile phone circuit switched network, allowing for multiple users to share radio resources simultaneously.

The underlying architecture of the GSM network is a circuit switched service which requires a dedicated path to be setup before communication can commence. The best analogy of a circuit switched network is the PSTN (Public Switched Telephone Network), which requires a set of switches to physically connect two telephones.

Fig 2.3.1a – PSTN Showing Connection of GSM Mobile phone to POTS Phonesource: [ADDA03]

Although mobile phones operate using radio waves, the same principle exists in the GSM telephone system. Mobile phones require a dedicated circuit switched radio link to the cell base stations. As radio frequency space is limited, it is important to try and maximize the utilisation of the available radio resources. When making older MODEM connections to the internet through the GSM standard, a dedicated circuit switched phone call provides a fixed bandwidth and unique path from user to destination, but at a cost. Data is transmitted in intermittent bursts unlike a voice call. This is because the maximum bit rate is required throughout the duration of the call, which leaves resources under-utilised for a significant amount of time. GPRS works on top of the GSM standard using packet switching


Technology. Data is split into small packets and routed along with packets from other users. The paths taken by successive packets may not be the same, and therefore additional header information is added to the data to enable the network to route it correctly to the destination where packets are reassembled into the correct sequence.

Fig 2.3.1b - Packet Switching source: [ADDA03]

Data packets are split into radio bursts using TDMA (Time Division Multiple Access). Radio resources are broken down further into fixed ‘timeslots’ and these slots are cycled across the number of users allowing for upload or download of data in turn. This efficient use of radio resources means that large numbers of GPRS users can potentially share the same bandwidth and be served from a single cell at the same time. GPRS therefore lets network operators maximize the use of their network resources in a dynamic and flexible way. The network operator can also change their network resources given to a GPRS device by setting the number of radio timeslots a device can use to upload or download data.

A GSM channel contains eight timeslots; normally each timeslot is dedicated to one circuit switched mobile phone call. For GPRS the timeslots are assigned on an ad-hoc basis, and more than one timeslot can be assigned for a particular transmission depending on the network and/or the device. By using multiple timeslots, a user will experience data rates that would not be possible with a GSM circuit switched connection. The resulting baud rate is dependent on the number of slots utilized, the error-correction and the encryption overhead.

[NOVATEL03]


2.3.2 GPRS Technology/Infrastructure

As the GPRS network works simultaneously along side the GSM voice network, it must be able to separate voice from data. Fig 2.3.2a below shows the end to end parts of the GPRS network.

Fig 2.3.2a - GPRS Network Infrastructure source: [MOTOROLA02]

GPRS data transmission is analogous to a jigsaw puzzle. Starting with the mobile device, Internet (TCP/IP) and Voice data is broken down into small pieces. When the data is ready to be sent, the network assigns timeslots on a channel for the transmission. These pieces are then sent over the air (on one of three frequency ranges - 900MHz and 1800MHz in Europe and 1900MHz in the US) to the cell BSC (Base Station Controller) and routed to one of two destinations; Data is routed to the SGSN (Servicing GPRS Support Node) which is responsible for two things, firstly going to the HLR AUC for authorization and subscriber information which is to be used for billing. Then routing data to the GGSN (Gateway GPRS Support Node) where the pieces are reassembled into TCP/IP data, and then passed to the Internet for transport to the destination. Audio is routed to the MSC (Mobile Switching Center) authorised with the HLR AUC and routed out through the GMSC (Gateway Mobile Switching Center) to the PSTN (Public Switched Telephone Network). Its final destination is the analog POTS (Plain Old Telephone System).


2.3.3 GPRS Frames

In GPRS not only does the user data need to be split into TCP/IP packets to be routed across the internet, but each TCP/IP packet needs to be split further into smaller 114 bit chunks to be transmitted through radio timeslots to the cell and BSC.

Fig 2.3.3a – GPRS Frame Breakdownsource: [MOTOROLA02]

A ‘radio block’ is the term used to describe four consecutive TDMA bursts. Each TDMA burst contains one RLC (Radio Link Control) / MAC (Medium Access Control) block. This is then carried on a GPRS 52 timeslot multiframe. A 52 timeslot multiframe is a set of 52 TDMA bursts. One TDMA timeslot can carry up to 114 bits; therefore, each Radio block of four bursts can only carry up to 456 bits of data. The information carried in those bits is the user data and RLC coding headers. RLC headers provide error detection and error correction, and are essential for managing and reconstructing data transmitted across the radio interface.

IP Header

Application Layer


User Data

MAC Header CRC

Radio Burst 1

Radio Burst 2

Radio Burst 3

Radio Burst 4


Data Link Layer

Physical Layer

Next Pkt

~ 40 Bytes

114 bits114 bits 114 bits 114 bits

~ 40 Bytes~ 40 Bytes ~ 40 Bytes

Radio Block 456 bits

TDMA Burst - Timeslots

52 Timeslot Multiframe

This section shows a GPRS Class of “1 up”

i.e each TDMA section is uploading 4 radio blocks (1 in each TDMA sub-section).

For a Class of “2 up” each TDMA sub-section would have 2 radio blocks.

This is reversed for download or “1 down”

RLC Header

RLC Header

TCP Header


The coding scheme and the number of timeslots partially determine the theoretical data rate. For example, if eight timeslots and no error checking are used, a theoretical data rate of 171.2 kbps would result (21.4 kbps x 8 timeslots). However, due to issues such as interference and sharing of resources with other GPRS users, this speed would not be achievable under normal operating conditions.

2.3.4 GPRS Speeds

As discussed above, GPRS works on radio timeslots. The resulting bandwidth depends on the mobile device and/or the network provider. Below are a few combinations of timeslots and data rates.

12kbps Send, 24Kbps Receive Class 2 (One Up, Two Down) 12Kbps Send, 40Kbps Receive Class 8 (One Up, Four Down) 36Kbps Send, 24Kbps Receive Class 12 (Three Up, Two Down) 171.2Kbps Receive Theoretical Maximum of GPRS

(8 Time Slots with no error Checking) [GSMWORLD03]


3. Current Solutions3.1 Mobile IP

IP networks are based on stationary IP addresses in a similar way to which a letter is delivered to a geographically fixed address. Routing of data is the process of delivering packets to a unique IP address assigned by the network. The problem occurs when a mobile node roams away from one network and is no longer reachable using its original IP address.

A simplified explanation of how Mobile IP works can be represented in the following scenario:

Many students living at university tend to change their postal address as they change accommodation throughout their education. One particular student decides to get all his post sent to his parent’s permanent address. The parents, who are aware of the student’s current address, then forward the post onto him by writing "Please Redirect to...." with the current address at which he lives. No matter where the student moves he will still get his post as long as the parents are kept up to date with the current address.


3.1.1 Mobile IP Detail

Mobile IP is based at the Network Layer (OSI Layer 3) and has three principal components:

Mobile Node - A device such a Mobile Phone, PDA or Laptop Computer.The mobile node may roam between networks and change its point of contact to the internet (e.g. WiFi or GPRS) and still keep a constant IP address known as a Home Address.

Home Agent - A router on a base network serving as a base address to which all traffic can be delivered.Its responsibilities include: - Keeping a list called a binding table of the Mobile Node's current location on the Internet, also called its care-of address.- If the mobile node is away, all are intercepted and tunnelled to the Mobile Node's current location.

Foreign Agent - A router that can function as a point of attachment for the mobile node when it roams to a foreign network. Its responsibilities include:- Telling the Home Agent where the Mobile Node currently is. - Receiving all traffic forwarded from the Home agent and delivering it to the mobile node.- Functioning as a router for the mobile nodes that have registered with it.

Fig 3.1a - Mobile IP Infrastructuresource: [GIGAPORT02]

The home agent keeps track of its Mobile Node’s locations (whether it is connected to its home or a foreign network) in a table called a ‘Mobility Binding Table’. When the mobile node is ‘at home’, it is connected to the same network as the home agent, and all network traffic is routed as normal. When a mobile node roams and is connected to a foreign network, it continues to converse with any previous correspondents (e.g. web servers). However, it maintains the source address of all packets, setting them to the address of the home network and not that of the foreign network in which the node now resides. Changing the source address of a packet does not affect the way it is routed. This is because it is not read by routers and therefore delivered as usual.

Also, while the mobile node is visiting the foreign network the foreign agent of that network lets the home agent of the mobile node know where it currently resides and prompts the home agent to update its mobility binding table with a new ‘Care of Address’. This address is the IP address


of the foreign agent.

Mobile Node(Home Address)

Care of Address(Foreign Network)

192.168.0.1 10.10.1.1192.168.0.2 10.10.0.3192.168.0.8 10.10.0.3

Fig 3.1b - Example of a Mobility Binding Tablesource: [CISCO03a]

The correspondent will reply using the source address of the packets from the mobile node (which as far as it is concerned, is the mobile node’s home address). This reply is consequently delivered to the home agent network.

The Home Agent will then lookup the current ‘Care of Address’ for the Mobile Node in the Mobility Binding Table and forward the traffic from the correspondent onto the Foreign Agent at which the Mobile Node is currently residing. The Foreign agent in turn forwards the packets to the mobile node. Some companies currently working on Mobile IP products are Accenture, ipUnplugged, Adjungo and Icomera.

3.1.2 Problems with Mobile IP

Mobile IP is a good solution to wireless roaming, but it has its downfalls. Firstly, there is a need for more specialised hardware (foreign agent and home agent). This is because latency and routing inefficiencies are caused by having traffic sent to home network before being sent to mobile node.

Secondly, when a mobile node travels across a number of different wireless networks, it will build up a ‘daisy chain’ number of foreign agents. Traffic may have to be routed across this chain of different networks before it gets to the mobile node. This will add a large degree of latency and limit the bandwidth availability to the slowest link in the daisy chain.

http://www.icomera.com/

http://www.adjungonet.com/

http://www.ipunplugged.com/

http://www.ipunplugged.com/

http://www.accenture.com/


3.2 Occasionally Connected Computing (OCC)

Applications could be written a little more intelligently when a network connection cannot be found. A few applications offer you the option to "Work Offline/Online". For example, Microsoft Outlook will work offline, allowing a user to write an e-mail and send it. The e-mail will actually be sent the next time the user connects to the Internet and Outlook goes online. However, this is not done automatically. The user will have to tell Outlook to go online as and when needed, otherwise a whole array of networking errors may be encountered.

Fig 3.2a – Example of Online/Offline Error Messages

If an application was designed to automatically connect and disconnect to the internet ad-hoc through whatever connection was available, be it Ethernet Cable, WiFi or GPRS, it would reduce network/internet traffic. This reduction would occur because there would be no unused bandwidth taken up during idle periods. [INTEL03a]

The following explanation of OOC continues the postal scenario from section 3.1:

Another student decides to setup a PO Box with a post office. She gets all her post delivered to this PO Box and picks up her post as and when she is able to pass the post office. All outgoing mail is sent through the same post office. The sender has no knowledge of where the student is really living, but yet she is still able to get all her post.

Two companies are looking at an Application Layer (OSI Layer 7) idea, Intel in a project called OCC (Occasionally Connected Computing), and IBM on a project called MQ Anyplace. Both companies are creating network software which operates regardless of how or when it is connected to a network or the internet. [IBM03]

There are a few phases to the OCC model which can be classified according to their different levels of sophistication:

Good - The first level suggests that applications should work even if it is offline. An application should automatically detect if it has an open interface to the internet and connect. Conversely, if it has not got a connection it should not throw any errors but seamlessly work offline with the data it already has (e.g. cached web pages)

http://www-3.ibm.com/software/integration/wmqe/


http://cedar.intel.com/cgi-bin/ids.dll/content/content.jsp?cntKey=Generic%20Editorial::mobile_occasionalconnect&cntType=IDS_EDITORIAL&catCode=CVS



Better - At the second level, applications should be designed not only to seamlessly connect and disconnect, but also to retrieve enough data to carry on working. The application may be used as a daemon. This daemon can probe the network to establish when the device is online. This is a similar system to the existing "Hot-Sync" widely used with PDA's and Mobile Phones. Data synchronisations can occur frequently and completely transparent to the user. Application data can be broken down into small update chunks which would be connection or protocol independent.

Best - The third level not only provides the user with a seamless solution but a more accessible and trouble-free experience. Application data is cached on the mobile user’s machine and also on a transport file system; a server which sits on the Internet caching data between the mobile client and the end correspondent server. Any data that cannot be transmitted due to the lack of connection is stored until a connection is open. This is performed in the background without any user intervention. [FINDART04]

Fig 3.2b – Infrastructure of OCC Showing Transport Systemsource: [INTEL03a]

All applications built on the OCC model require asynchronous messaging that makes use of the times when the mobile device is online to refresh data, as well as queuing updates when the device is offline for later processing.

3.2.1 Problems with OOC

This works well for applications that operate on batch style processing, such as e-mail, file transfer or newsgroups, but would be less suitable for activities such as streaming media which require a constant real-time connection.


3.3 DSP Silicon Methods 3.3.1 System on Chip (SoC)

Intel, Nokia and a number of other organisations are developing SoC (System on Chip), a single piece of silicon which includes multiple DSP’s (Digital Signal Processors) along with high speed reconfigurable logic processors, in order to execute multiple wireless protocols.

A DSP is a processor which allows a computer to translate signals to and from digital data. In the case of wireless networks, these signals are electronic radio waves. More than one DSP processor may be integrated onto one SoC chip to translate signals from different frequencies using different modulation techniques (i.e. CDMA, DSSS, FHSS, OFDM).

A reconfigurable logic processor is a processor which can be configured to carry out different control tasks, including protocol processing and generation. The real benefit is that the logic is self reconfigurable to meet the needs of different wireless protocols.

The combination of these processors is known as System on Chip (or SoC). This is a data link layer (OSI Layer 2) solution. The idea is that one piece of silicon could be manufactured which would include support to connect to two or more wireless network types and allow for always-on connections, as well as the ability to switch automatically and transparently between networks types.

SoC is still in development, and research is being done in gradual stages. At the time of writing testing is being carried out on WiFi (802.11) and HiperLAN/2, which share similar protocols and are therefore easier to switch between. The eventual aim is to be able to swap between further protocols including GPRS and UMTS.

[SOC04]

Fig 3.3 – System on Chip Block Diagram

The ability to roam between different wireless network types is not the only advantage of SoC, Mobile devices can be cheaper to build, and develop because they require less silicon. They can also physically be smaller and consume less power.


3.3.2 Software Defined Radio (SDR)

SDR is similar in many ways to SoC in that it still relies on the power of DSP technology, and is a development which allows further radio flexibility. By simply modifying or replacing software programs or firmware, it can completely change the radio’s functionality, changing communications protocols and frequency bands. Such flexibility allows for easy upgrade to new modes and protocols without the need to totally replace hardware.

There is a great difference between a radio which uses software internally for some of its functions (e.g. the software in a GPRS radio which is responsible for dialling number) and a SDR radio which can be completely redefined through modification of its software.

[ARRL03]

The concept of SDR is rapidly gaining commercial popularity, not only for the GPRS and mobile phone industry, but also for wireless computer networks such as WiFi. Intel’s brand name for SDR is called ‘Radio Free’ and their aim is “to allow products with embedded silicon to connect to multiple networks, regardless of their respective protocols or requirements.”

[INTEL04B]

3.3.3 Problems with DSP Silicon Methods

Both SDR and SoC are still under development. Both would require new hardware to replace current wireless network devices. Mobile users who do not wish to replace their existing expensive hardware would need a software solution to work on top of their current setups.


4. Analysis and Design4.1 Brief

This chapter describes the mobility problem as well as some proposed solutions formulated by the author after previous work experience in the wireless networking area and studies of the problem. It then concludes with a discussion of a specific Network Layer (OSI Layer 3) solution to be further implemented.

note: For the rest of this report the name ‘NetSwap’ will be used to describe the proposed solution which would allow seamless swapping between wireless networks.

Put in simple terms, the NetSwap solution again has parallels with the conventional postal system, take the following scenario:

Another student living in Portsmouth decides to first post all his outgoing mail to his parents living in Eastbourne by putting all post within a second envelope addressed to the parents. On receiving any letters, the parents then take the original envelope containing the true receivers address out of the second envelope, and put it back in the post box. It would then appear to the receiver that the letter originated from Eastbourne due to the postal mark printed on the envelope.

As the receiver replies, they send all post back to Eastbourne as this is where they perceive it came from. The parents then forward any replies onto the student in Portsmouth by writing “Please Redirect to…” with the student’s current address.

The letters which the student posts onto their parents contained within a second envelope could be said to be encapsulated. The concept of encapsulation is one of the central ideas of the NetSwap solution.


There needs to be two main components in the NetSwap system:-

4.1.1 The NetSwap Driver

The NetSwap Driver is a piece of software which will represent a ‘virtual network interface’ in a Mobile Node. The driver sits on top of all other network device drivers. Its purpose is to fool any internet application into thinking that the mobile node has a constantly connected network device. The NetSwap driver will then act as a kind of ‘proxy’, utilising the other different network devices (e.g. GPRS and WiFi) depending on their availability.

There is a standard for communicating with most new network drivers called NDIS (Network Driver Interface Standard). NDIS is fast becoming an integral part of all Windows operating systems and all Windows compliant Network adapters are shipped with NDIS compatible drivers.

Fig 4.1.1a - NDIS - NetSwap Driver [SISECH03]

The NetSwap Driver is responsible for monitoring all connections. It routes the traffic from the application to one physical card at a time, depending on availability and priority order. Priority may be based on cost, routing metric, bandwidth, or it can be user defined. For example, WiFi may be of higher priority than GPRS due to it being a quicker connection.

The main job of the NetSwap Driver is to fool any applications into using the ‘virtual network interface’ before it uses any other network interface. One method of doing this would be to force the metric values for all other interfaces in the system up, thereby giving the virtual interface the lowest metric. For example, the driver could give itself a metric of 10 and move Ethernet to 11, Wireless to 31 and GPRS to 51. Therefore, an internet application sending network traffic will go through the NetSwap Driver with the new lower metric.

The NetSwap driver must then force all packets to be sent through a special router (see 4.2.1 – NetSwap Gateway) by encapsulating them in a second IP header. It should then communicate with the special router by letting it know which interfaces are currently available on the mobile node. This communication would be done at regular intervals while switching between interfaces.


4.1.2 The NetSwap Gateway

The NetSwap Gateway is a router sitting on the internet, which acts as a central point to relay all traffic through. As discussed earlier, the mobility problem occurs when a mobile node swaps between two networks and the correspondent server is unaware of where the mobile node has moved to, rendering it unable to reply.

The NetSwap Gateway must have a static IP address as it is used as a ‘known point’ and should not change. Its job is to forward all traffic to and from the mobile node’s current address. There is an ‘always on’ connection as far as any applications running on both the mobile node and the correspondent are concerned, and the fact that the traffic goes through the NetSwap gateway should be transparent to both ends.

Fig 4.1.2a - Switching Between Network Interfaces


4.2 Class Diagrams

The following two sections (4.2 and 4.3) detail the design for the NetSwap idea in the UML (Unified Modelling Language) design methodology. UML is an industry-standard language for specifying, visualizing, constructing, and documenting system designs. It has been chosen to document the NetSwap design as it simplifies the complex process of software design, making a “blueprint” for future implementation.

The UML Class diagram below shows the relationships between the different components in the NetSwap design.

Fig 4.2a – UML Class Diagram for NetSwapFor further details of the methods and Attributes see Appendix B

Some components build up on already available equipment; Inheritance and Composition Description:

The Mobile Node, Web Server and Gateway all inherit from a standard computer node

The Web Server contains one interface, the Gateway contains two interfaces, and the Mobile Node contains two interfaces of different types (GPRS and WiFi)

Both the GPRS and WiFi interface inherit from a standard Network Interface (for example the NDIS standard)

The NetSwap Gateway inherits from a standard Gateway/Router

Communication between all types of node (Web Server, Gateway and Mobile Node) is done via the ‘Network Cloud’. This network cloud would represent all the physical network equipment between the nodes, including Routers, Cables, Radio Links, GGSN, SGSN, Access Points, Switches etc. The network cloud represents all aspects of the system which relate to the external network. This encompasses all delays between nodes caused by propagation, processing or bandwidth restrictions.


4.3 Sequence Diagrams

The communications between the devices seen in the Class Diagram (see Section 4.2) can be represented in a UML sequence diagram which shows the order in which certain communications are done.

4.3.1 Simple Scenario

The scenario below represents a simple NetSwap session with no errors, communicating using the WiFi interface, sending and receiving only a single packet to the Correspondent Web Server.

Fig 4.3.1a – UML Sequence Diagram for NetSwapFor further details of the methods and Attributes see Appendix B


4.3.2 If things go wrong

The following scenario shows what would happen if one of the two interfaces was initially failed to respond, but it later becomes available midway through a session.

After polling both interfaces, the NetSwap Driver chooses the lowest metric interface available and updates the NetSwap gateway with the open interface address. In this case, it is initially the GPRS interface. This is due to the WiFi interface not responding to the earlier poll.

Communication starts between the Mobile Node and the Correspondent Web Server via the NetSwap gateway. Before the web server sends its response, the WiFi interface becomes available and the NetSwap gateway is updated with the new return address of the WiFi interface.

Fig 4.3.2b – UML Sequence Diagram for NetSwap while swappingFor further details of the methods and Attributes see Appendix B


4.4 Pseudo Code

The following pseudo code details what happens at each stage of the sequence diagram. This pseudo code could then be used to help implement parts of the NetSwap design in programming.

TestInterfaces()

The initial stage is to determine which interfaces are ‘online’ in the mobile node. Taking the scenario of a Mobile Node with two interfaces, namely GPRS and WiFi, the NetSwap driver needs to poll each in turn. See the Poll() code for more details.

Create NetSwapPollTable used to store online/offline interfaces;

If (Poll(WiFi) = OK) { Put interface in NetSwapPollTable; Put time of poll reply in NetSwapPollTable;} else if (Poll(GPRS) = FAILED) { Inferface poll failed;}

If (Poll(GPRS) = OK) { Put interface in NetSwapPollTable; Put time of poll reply in NetSwapPollTable;} else if (Poll(GPRS) = FAILED) { Inferface poll failed;}

Poll(interface)

The following code is used by the TestIntefaces() command above. There are a couple of different solutions to find out open interfaces.

The first solution is to send a specially generated ICMP packet (similar to a ping) to the different interfaces as a poll. A timer should be set (in this example for 3 seconds) and, if a PollReply() comes back before the timer runs out, the interface poll has been successful.

Generate special ICMP poll packet;Send to interface;StartTimer running for 3 sec;If (Reply from interface and timer still running) {

Return OK;} else If (Timer finished running) {

Return FAILED;}

PollReply()

On receiving a poll from the driver, each interface must reply with an acknowledgement before the timer runs out.

Receive ICMP poll request packet;Send(ACK) back to Driver;


The second solution to find out whether or not an interface is online is to use the already present API interrupts and signalling. Both Microsoft Windows and Linux Operating Systems provide them. There are many different signals and messages triggered by various events which occur during the running of an operating system. The NetSwap Driver could hook onto these event signals to determine which connections are available.

For Windows, there is a signal which triggers the "Network Connection Connected" bubbles which appear in the taskbar when network interfaces are connects/disconnected.

Fig 4.4a – Microsoft Windows interrupts to determine online interfaces

For Linux, the “ifup eth0” command can be used to determine if an interface is online or not:

Listen to OS interrupt signals relating to interface;Online = Ifup(interface);If (Online) {

Return OK;} else () {

Return FAILED;}

The advantage of using this second method is that it reduces unnecessary polling. In addition to this the NetSwap Driver is told of any change instantly, as and when the connections change instead of at timed poll intervals.


ChooseLowestMetric()

After determining which interfaces are available, the driver needs to decide through which interface it should forward all traffic. A metric order also needs to be decided, this could be chosen in a few different ways.

The first method could be based on the time taken to reply to the poll by reading the poll time recorded in TestInterfaces().

Read NetSwapPollTable time taken to reply for each interface;Choose Lowest time;Primary Interface = lowest;Secondary Interface = second lowest;Reset Routing Tables to reflect change;

The second method could be to read the values from the routing tables. In the case where a computer has two or more connections to the internet, there is a mechanism which forces any internet applications to send data through a preferred connection. TCP/IP uses ‘routing metrics’. A Metric is a numerical value which represents the priority order in which an application should send network traffic. This priority could be based on connection cost, speed, reliability (metrics were originally designed to represent the number of hops or router connections to a specific destination). This can be seen by typing “route PRINT” in a windows command line:

C:\>route PRINT =========================================================================== Interface List 0x1 ........................... MS TCP Loopback interface 0x2 ...00 04 23 46 8b 31 ...... Intel(R) PRO/Wireless LAN 2100 3B Mini PCI 0x3 ...00 40 ca c0 79 89 ...... Intel(R) PRO/100 VE Network Connection - =========================================================================== Active Routes: Network Destination Netmask Gateway Interface Metric 0.0.0.0 0.0.0.0 192.168.0.100 192.168.0.55 10 127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1 192.168.0.0 255.255.255.0 192.168.0.55 192.168.0.55 30 192.168.0.55 255.255.255.255 127.0.0.1 127.0.0.1 30 192.168.0.255 255.255.255.255 192.168.0.55 192.168.0.55 30 224.0.0.0 240.0.0.0 192.168.0.55 192.168.0.55 30 255.255.255.255 255.255.255.255 192.168.0.55 3 1 255.255.255.255 255.255.255.255 192.168.0.55 192.168.0.55 1 Default Gateway: 192.168.0.100 =========================================================================== Persistent Routes: None

The metric can be seen down the right hand column, and could be used to establish a priority. These numbers are different depending on the type of network interface. For example, an Ethernet connection may have a metric value of 10, a WiFi connection a metric value of 30 and GPRS a metric value of 50. If a computer had all these three connections installed and online at once, the default route for all traffic would be through the Ethernet connection with the lowest metric of 10.

Get metric values by reading OS routing table;Choose Lowest metric;Primary Interface = lowest;Secondary Interface = second lowest;

The third method of choosing the lowest metric could be user defined. The user of the mobile node could physically set some settings to decide the interface priority.


NetSwapAddressUpdate()

The NetSwap driver needs to let the NetSwap Gateway know which interface the mobile node is using each time it changes. Again there are a couple of possible solutions:

The first solution is to use ICMP (Internet Control Message Protocol). ICMP are special packets which contain error control messages, routing messages, session information, and operation messages between routers and gateways.

There are a number of different ICMP types which perform different tasks, such as announcing network errors (network unreachable or port numbers blocked), announcing network congestion (if a router is overwhelmed with packets and unable to transmit), announcing timeouts (if a packet's TTL field drops to zero). In the latter instance, the router discarding the packet will often generate an ICMP packet announcing this timeout. [STEVENS94]

A handful of the ICMP packet type numbers are listed in Appendix A. ICMP type numbers 1 and 2 are "Unassigned" to a particular task and could be used by the NetSwap Driver to let the NetSwap Gateway know of interface changes through specially constructed ICMP packets solely for this purpose.

Create Table of return address to MN named NetSwapGatewayTableReceive Packet;Read Data field in ICMP packet;NetSwapGatewayTable = Data field;Send(ACK) back to driver;

The second solution is opening a socket session on an unused port. The NetSwap Driver could open a socket session with the NetSwap Gateway on a special port (in this example port 5555 is used) which could have a program running listening for interface changes.

NetSwap Driveropen socket with the NetSwap Gateway on port 5555;send new interface ip address from NetSwapPollTable;wait for confirmation;

NetSwap GatewayCreate Table of return address to MN named NetSwapGatewayTableListen on port 5555 for the NetSwap Driver;receive ip address change;Set NetSwapGatewayTable with the address change;send confirmation of change;update return ip address table;

By updating the NetSwap Gateway using this method, scope could be included for multiple users each having to login and update through this program. One downside to this second method is that it is dangerous to have ports open on a gateway as it would leave it susceptible to hacking.

The NetSwap Gateway needs to be updated with any interface change on the Mobile Node as soon as possible to avoid packet loss. Therefore the method for updating the NetSwap Gateway has to be quick and still be able to get through even if congestion occurs.


NetSwapAddressUpdateOK(ACK packet)

An acknowledgement of address update is sent back to the NetSwap Driver to let it know that the update was successful; the driver now knows that further transmissions will be replied to through the new interface.

Receive Packet;Set return interface to address in packet;Send ACK;

Encapsulate(packet)

As discussed previously, all packets need to be sent via the NetSwap Gateway before getting to their final correspondent destination. This is done so that the NetSwap Gateway can change the return address contained in the packet to its own address so that the final destination can reply back to one static address, which will never change, even if the mobile node changes network. The second IP header literally goes on the outside of the original headers. For example:

Fig 4.4b – Encapsulation to force to NetSwap Gateway

As this encapsulated packet travels through the network/internet, any routers encountered will just read the outer IP address headers and route as if it were a normal packet. The current interface should be set as the source address in the new IP header. The encapsulation is later to be stripped off by the gateway and sent on to their original correspondent destination.

Receive Packet;Generate New Header to force to NetSwap Gateway { Destination = NetSwap Gateway Address; Source = Highest metric interface in NetSwapPollTable; Type = NetSwap packet;}E_packet = Encapsulate Packet with New Header;Send(e_Packet);

* e_packet is an encapsulated packet

The encapsulation works in a similar way to a VPN tunnel, which forces all packets to go a specified route by encapsulating them. The only difference is that the NetSwap design does not require encryption.

IP Header

NetSwap encapsulated IP

New IP Tail

Original IPIP Tail

New IP Hdr


Decapsulate(e_packet)

All packets coming from the Mobile Nodes NetSwap Driver to the Gateway will be encapsulated. These packets need to be decapsulated before they get resent. The reverse of Encapsulate() should be performed. The outer IP header is stripped off and the original packet is sent onto its final correspondent destination. The source address of the packet is also changed before sending.

Receive e_packet;packet = Remove outer IP herders(e_packet);ChangeSourceAdd(packet);Send(packet);

ChangeSourceAdd(packet)

The NetSwap Gateway needs to change the source IP addresses of the Packets from the Mobile Node after decapsulation. It needs to be changed to the IP address of the NetSwap Gateway. This is required to fool the correspondent into returning its reply back to the NetSwap Gateway which has prior knowledge of the Mobile Nodes current address…

GatewayAddress = 1.2.3.4;ReadIPHeader(packet){ Change SourceAddress = GatewayAddress;}

ChangeDestAdd(packet)

…the packet will then be forwarded back to the Mobile Node. This is done by changing the destination address of the correspondent reply back to the current open interface as set in the Table by the NetSwapAddressUpdate() command above.

Receive Packet;Change dest address of packet to the current open interface;

The aim of this process is to make the NetSwap Gateway appear transparent to both the Mobile Node and the end destination.


5. Implementation

The original plan had been to implement the design in two stages.

The first stage was to try and recreate some of the problems which occur when swapping between wireless networks using real network hardware. This would make it possible to gain some numeric results and gain a better knowledge of why the mobility problems occur.

In the second stage, network simulation software was to be used to implement the NetSwap idea, with which it was planned to produce some comparable results to the real hardware testing performed in the first stage.

This chapter outlines the methods used to implement the NetSwap idea.


5.1 Physical Hardware Simulation

In addition to using a simulation, it was decided that physically recreating the mobility issue using real hardware would offer a better understanding into the problem. It should also increase the possibility of finding smaller solutions or fixes.

Intel Corporation have supplied both a GPRS Adapter (Intel PRO/Wireless GPRS 3110 PC Card) and a 802.11b WiFi Network Adapter (PRO/Wireless LAN 2100 3B MiniPCI Adapter).

Orange (PCS), a UK mobile phone operator, have kindly donated a SIM card with a year’s subscription and unlimited connection to their GPRS network to this research project.

Fig 5.1a - Intel PRO/Wireless GPRS 3110 PC Card with Orange SIM card.

Fig 5.1b - Intel PRO/Wireless LAN 2100 3B MiniPCI Adapter.

Using this hardware, some simple tests can be done by running a few different network applications and observing what happens when network adapters lose connection during the swapping process (roaming).


5.2 Physical Hardware Implementation 5.2.1 Software Used

Microsoft Windows XP Professional SP1 – Operating SystemThe Microsoft Windows XP operating system was used due to its easy GUI access to control network interfaces. It also has Windows NDIS drivers (as described in section 4.1.1).

CuteFTP 5.0 – File Transfer ProgramTransfers files between computers over a network using the FTP protocol. FTP is a stateless protocol and therefore requires information to be passed between client and server each time a file transfer session is established.

Microsoft Windows Media Player 8.0 – Streaming MediaStreams sound from the internet whilst swapping between wireless interfaces. It uses a buffer which caches music ahead of play. This may increase the chances of a more seamless swap as interfaces swap.

Icomera 2.3 – Mobility ManagerSoftware which claims to combine different wireless links (i.e. Satellite, GSM, CDMA, etc) for optimal communication and performance. The different communication links can be configured to connect automatically according to defined parameters (e.g. speed, cost, availability and reliability).

Intel PROSet 7.0 – Network card drivers and configuration utilityA control panel which allows the user to view various statistics and modify settings for all kinds of Intel network adapters, including Ethernet, GPRS and WiFi. Some features include:

The ability to view radio signal strength for WiFi and GPRS cards On the fly setting of IP addresses, either manually or by DHCP Network Adapter Switching which apparently enables automatic

switching between two or more network adapters The ability to view other wireless networks which are in coverage

range

Ping – ICMP Polling Network ToolUses timed IP/ICMP ECHO_REQUEST and ECHO_REPLY packets to probe the “distance” to a target machine. As a correspondent is pinged, it would be useful to see if a reply can make its way back after an interface change.


5.2.2 Equipment Setup - Architecture

The GPRS and WiFi cards have been installed in a desktop PC of sufficient specification and configured with optimal settings. In order to ensure fair testing, both cards are from the same manufacturer (Intel) and have had external antennas connected to improve signal strength.

Fig 5.2.2a – Physical Equipment Antennas

An access point (Intel 2110B series) has been installed in an optimum position to provide sufficient wireless signal to the test equipment, and GPRS coverage from Orange is good. Before tests began, both WiFi and GPRS report full signal strength.

Fig 5.2.2b – Test Equipment Setup Architecture

Access to the internet is obtained through a Cisco 2611 router and a NTL cable modem.


5.2.3 Simulating the effect of “Roaming”

Since the GPRS and WiFi adapters have been installed in a desktop computer, the equipment setup is not very mobile. It is therefore not easy to roam between different wireless network types to get low signal etc.

Rather than move the wireless adapters out of radio range of the transmitters (access point and GPRS BSC), a preferable way to reduce signal is to cover the antennas up.

A tube covered in layers of aluminium foil, when placed over the antenna, was found to reduce signal to each interface enough to lose connection. This is an effective way of simulating losing range of a wireless network.

Fig 5.2.3a – Simulating Roaming with antenna sleeve

This approach can be used with both the WiFi and GPRS antennas and makes roaming tests fairer. Due to the fact that the equipment is staying in one place, signal strengths can be controlled more reliably and signal loss can be reproduced on demand.


5.2.4 Application Configuration

CuteFTP was setup to transfer files from a correspondent server on the internet. It was later found that most FTP connections are “stateless”. This means that connections between client and host are created and if connection is lost halfway through a file transfer the FTP server will have no knowledge of any clients trying to re-establish a transfer, therefore in normal circumstances after changing interfaces a new file transfer will need to be restarted again. The NetSwap solution should solve this problem by fooling each end into thinking there is an ‘always on’ connection even if the user swaps between the interfaces are swapped between.

Microsoft Windows Media Player which was used to stream audio from the online radio channel http://www.southernfm.com, was configured with the default buffer and performance settings found in

Tools -> Options -> Performance ->as follows:

Connection Speed = Detect connection speed Network Buffering = Use default buffering (5 seconds)

Icomera was used briefly by the author. It was configured with an Icomera Gateway and setup to use the Intel GPRS and WiFi interface cards. It was very simple to setup and did not need many extra settings. However, it was found to have a bug in the version used which prevented it from fully working with the Intel GPRS card. Consequently, it could not be used for any tests.

Intel PROSet was installed and the control panel was used to bring interfaces up and down to simulate the action of interfaces failing. IP addresses were manually assigned to the WiFi card to eliminate DHCP assignment problems.

Ping was used as a test tool to see if correspondent hosts on the internet were working or not. A couple of tests were done by running ping with the “no timeout” option, which would mean ping would keeps pinging until stopped by the user. This was done by using the –t parameter (e.g. “ping www.jlsnet.co.uk –t”)

5.2.5 Recording Findings and Recreating problem in Physical Hardware

As it is hard to measure lost packets in a real life scenario without protracted use of packet sniffing software, it was decided to simply measure the performance of the applications in time. This was measured using a stopwatch while running the various applications listed above in real life use-scenarios.

Three case scenarios were tested:

Starting with both WiFi and GPRS online and recording what happens when WiFi is taken down midway through a test

Switching WiFi back on while GPRS is online. Does it swap back to the faster, lower metric interface in the tests?

Starting with WiFi and GPRS on and switching GPRS off midway through a test

note: For the results of these tests, see Testing and Evaluation, Chapter 6

http://www.southernfm.com/


5.3 Software Simulation of the NetSwap Idea

The concluding part of this chapter will include brief comparisons of network simulation software and the installation, creation and simulation of the NetSwap idea using the designs in Chapter 4.

Networking technologies and ideas are often very hard to explain. Even with the use of many diagrams, pseudo code and long descriptions, it can still be hard to determine if an idea is going to work. It is easier to demonstrate an idea in an environment where it can be visualised.

Simulation is defined by foldoc.org as “Attempting to predict the aspects of the behaviour of some system by creating an approximate (mathematical) model of it”.

A simulator can therefore be used to produce results in research into the behaviour of a system. In the case of this project, a simulator needs to be chosen to simulate (predict) the actions of a computer network model.

Network simulation aims to recreate a live network system, calculating packet transfers across a network between two or more nodes and also simulating loss, queuing, delay, and processing time.

It must be decided which is the best simulator to use in recreating the NetSwap idea. There are 4 different software simulators of interest (OPNET, QuarlNet, OmNET++ and NS-2).


5.3.1 OPNET

OPNET is a widely used Windows based simulator. It is built on C++ and provides a virtual environment for modelling, analyzing and predicting the performance of networks. It includes scope for accurately modelling applications, servers and a wide variety of networking technologies. Updates for newer protocols and devices are regularly released to keep up with the fast moving network technology trends.

OPNET is used by many commercial and government organisations worldwide, as well as over 500 universities (including Portsmouth University). [ABOELELA03]

There are various different features available to users of OPNET. Some of these include:

Creating and editing networks and nodes Creating and editing processes running on the nodes Analysing the simulation results and producing performance charts Defining mathematical processes for use in the analysis tools

Fig 5.3.1a – Screenshot from OPNET simulation

The availability of these features makes OPNET very flexible and provides the ability to simulate virtually any type of communications network. Creating a simple network topology simulation is easy with the use of drag and drop components and pre defined settings. However, learning to utilize OPNET fully to implement new protocols is somewhat difficult for beginners; the user would need to be familiar with Object-oriented methodologies and languages such as C++, as well as low level networking knowledge.

Pros Extra modules/agents can be programmed using C++ Wide Industry User Base Support for Wireless

Cons Licence – a large payment is required to get the full version Over Complicated The Student version does not allow you to add C++ modules

http://www.isima.fr/opnet/image4zoom.jpg


5.3.2 QualNet

QualNet is a network simulator produced by SNT. It achieves new levels of scalability, with the ability to model very large networks consisting of thousands of nodes.

QualNet can be used to model both wireless and wired nodes. The suite includes tools such as:

Simulator, which claims to be the fastest for real-time traffic modelling

Animator, which allows the user to graphically design network models (using a wide library of components) and displays the results of simulation runs

Designer, which allows creation of Finite State Automata to describe the behaviour of a network

The Analyzer and Designer allow the user to interpret and make sense of simulation results. [QUALNET04]

Fig 5.3.2a – Screenshot from QualNet simulation

QualNet runs on both Windows and Linux. A trial version is available to download on request.

Pros Runs on both Windows and Linux Can handle large number of nodes

Cons Need Licence for full version Not very widely used


5.3.3 OMNeT++

OMNeT++ is a discrete event simulation environment. Its primary area of application is the simulation of communication networks, but because of its generic and flexible architecture, it has been successfully used in other areas simulating other complex IT systems. One distinguishing factor of OMNet++ is its strong component-oriented approach which promotes structured and reusable models.

As a result of its flexibility, OMNeT++ is rapidly becoming a popular simulation platform in scientific and industrial circles. [ONMET04]

Fig 5.3.3a - Screenshot from OMNeT++ simulation

OMNeT++ has extensive GUI support, with the ability to drag and drop network items and connect them together.

Pros Highly adaptable to all kinds of network simulations Visual traces of packets

Cons Lots of windows, flashing around, hard to see simple view Has the feel of being created with lots of bolt-ons and fixes added,

making it hard to navigate around


5.3.4 NS-2

NS is an event driven network simulator used to recreate a variety of IP networks and protocols. The original version was developed at UC Berkeley and later evolved into an improved version called NS-2 (version 2). The latter was taken on as part of the VINT project, a project that develops tools for simulation results display, analysis and converters.

NS-2 implements network protocols such as TCP and UPD and traffic application behaviour such as FTP, Telnet and HTTP. As well as routing protocols and queue management mechanisms such as Dijkstra algorithm, ad-hoc routing, Mobile IP, RED queues and more. NS-2 also implements multicasting and some of the MAC layer protocols for LAN simulations.

Fig 5.3.4 - Screenshot from NS-2 NAM Simulation

NS-2 runs on both Linux and UNIX and is freely available under the GNU licence which is intended to guarantee freedom to share and change free software. This means that changes and fixes can be easily submitted and added into newer versions of NS-2 by anyone.

Simulation scripts are created using the well know Tcl (Tool Command Language) scripting language. Results can be viewed using a piece of software called NAM which can animate network traffic and generate trace files containing packet flow information.

Pros Free – GNU Runs on Linux You can program new agents in C++ NS is written in C++ and OTcl (Object-oriented Tool Command

Language) Support for 802.11 and GPRS Simple topology display with NAM

Cons Still in testing stages Still has some bugs, although being fixed daily by GNU users. Mainly Command Line Based

http://bmrc.berkeley.edu/research/cmt/cmtdoc/otcl/index.html

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


5.4 NS-2 Implementation5.4.1 Getting to know NS-2

The NS-2 Simulator was chosen due to the fact that it allows for low level creation of ‘agents’. These agents can be used to create new protocols and applications and allow for easy creation of the NetSwap design.

At the start of this project, the latest version, NS 2.1b9a, was chosen and downloaded from http://www.isi.edu/nsnam/dist/.

Initially, NS-2 was quite daunting to install and get to grips with; there were a number of installation problems and what seemed like a large number of files to navigate.

Two sources of information were needed before any form of simulation could be started. The first was the “ns Manual” (formerly ns Notes and Documentation) located at http://www.isi.edu/nsnam/ns/ns-documentation.html. This document, maintained by ISI, is the main manual for NS-2. It contains commands, examples, explanations and FAQ’s. The second source of information was the [email protected] mailing list, located at http://mailman.isi.edu/mailman/listinfo/ns-users, which, once subscribed to, allows users to exchange questions and answers via an e-mail list.

Some working knowledge of the Tcl (Tool Command Language) scripting language was needed. With the version of the NS-2 chosen, comes Tcl version 8.3.2. After a few examples it is easy to learn and create useful simulations in minutes. [TCL04]

5.4.2 Configuration

A network simulation node layout, with a similar topology to that of the previous physical hardware setup in Fig 5.2.2b, needed to be created using the NS-2 simulator.

To reduce complexity, initially only wired links were used to represent the connections, including those of the Wireless and GPRS connections. The resulting layout was decided:

Fig 5.4.2a – NS-2 Initial NetSwap Layout

This layout was created by using a Tcl script which was fed into the NS-2 simulator. The Tcl can be written using any type of test editor and is a script that contains commands relating to creation of nodes, links between them and further commands to be used later in this project.

The following code examples are that of the Tcl script used to generate the topology in Fig 5.4.2a. Comments are included at each stage.

http://mailman.isi.edu/mailman/listinfo/ns-users

http://www.isi.edu/nsnam/ns/ns-documentation.html

http://www.isi.edu/nsnam/ns/ns-documentation.html

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


5.4.3 First NS-2 Tcl Script

The first thing required by NS-2 in all Tcl scripts is to setup a new simulator object. The following line creates a new simulator instance called ‘ns’.

set ns [new Simulator]

In the next lines, a file needs to be opened which will be used to store a packet trace – that is, a list of simulator activities. The first line opens the file 'out.nam' for writing and gives it the file handle 'nf'. In the second line, the simulator is told to send all relevant packet traces to that file.

set nf [open out.nam w]$ns namtrace-all $nf

The next step is to add a 'finish' procedure that closes the trace file as the simulation ends and display the results using the NAM viewer.

proc finish {} { global ns nf $ns flush-trace close $nf exec nam out.nam & exit 0}

The 8 nodes seen in Fig 5.4.2a are all types of generic node, which are later to have extra functionality added later. Each node is given a sensible name. They are created in the following lines.

# Create nodesset mn [$ns node]set ns_drv [$ns node]set eth0 [$ns node]set eth1 [$ns node]set router0 [$ns node]set router1 [$ns node]set ns_gw [$ns node]set correspondent [$ns node]

These nodes are basic nodes which will later to have ‘agents’ added to them. An agent is a kind of plug-in to the node which changes their functionality or adds features. A NetSwap Driver and Gateway agent will be created to add to these generic nodes, inheriting the extra features needed. These are namely those listed in the Design Class Diagram in section 4.2 of this report.


Next, the nodes need connecting. It can be observed that particular connections have different connection speed types.

#Create a duplex link between the nodes$ns duplex-link $mn $ns_drv 100Mb 10ms DropTail$ns duplex-link $ns_drv $eth0 36Kbps 10ms DropTail # GPRS $ns duplex-link $ns_drv $eth1 11Mb 10ms DropTail # WiFi$ns duplex-link $eth0 $router0 1Mb 10ms DropTail$ns duplex-link $eth1 $router1 1Mb 10ms DropTail$ns duplex-link $router0 $ns_gw 1Mb 10ms DropTail$ns duplex-link $router1 $ns_gw 1Mb 10ms DropTail$ns duplex-link $ns_gw $correspondent 100Mb 10ms DropTail

The next line tells the simulator object to execute the ‘finish’ procedure after 3.0 seconds of simulation time. NS-2 provides a very simple way to schedule events with the 'at' command.

$ns at 3.1 "finish"

The last line finally starts the simulation running.

$ns run


5.4.4 Recreating problem in NS-2

Before implementing the NetSwap idea, some quick tests were performed using the simulator by running a FTP session between the mobile node and the correspondent.

Both the mobile node and the correspondent had TCP and FTP agents attached to them.

# Setup a FTP session between Mobile Correspondent Nodes

# Attach TCP agent to Mobile Nodeset tcp [new Agent/TCP]$ns attach-agent $mn $tcp

# Attach FTP agent to Mobile Node’s TCP agentset FTP [new Application/FTP]$FTP attach-agent $tcp$FTP set type_ FTP

# Attach a FTP sink to the correspondent nodeset correspondent_agent [new Agent/TCPSink]$ns attach-agent $correspondent $correspondent_agent

# Connect Mobile Node’s TCP and Correspondents Sink agents$ns connect $tcp $correspondent_agent

# Schedule FTP Events – passing commands to agents$ns at 0.00 "$FTP start"# take link down for eth0 (WiFi)$ns rtmodel-at 1.00 down $eth0 $router0$ns rtmodel-at 1.00 down $eth0 $ns_drv$ns at 3.00 "$FTP stop"

Together with the Tcl script from section 5.4.3, the above script will run a simulation for 3 seconds. The simulation has three main events:

Time (sec) Event0.00 Start Simulation and FTP session running between

mobile mode and the correspondent.1.00 Take the link representing WiFi down. (note: you are

unable to take a node down in NS-2, so both links on either side of the node were taken down)

3.00 Stop FTP session and simulation, and then display output in NAM.


Fig 5.4.4a – Output of first NS-2 FTP simulationThe purpose of this quick simulation is to try and observe whether the “roaming” problem also occurs when swapping between network routes in the NS-2 simulator.

Initially the FTP session travelled across the lowest metric route, which in this case was via node 2 (representing WiFi).

The metric route within NS-2 network simulations can be seen by using the "$ns dump-routelogic-nh" command in the Tcl script. Here is an example of the output:

Dumping Routing Table: Next Hop Information 0 1 2 3 4 5 6 70 -- 1 1 1 1 1 1 11 0 -- 2 3 2 3 2 22 1 1 -- 1 4 1 4 4 3 1 1 1 -- 1 5 5 5 4 2 2 2 2 -- 6 6 65 3 3 3 3 6 -- 6 66 4 4 4 5 4 5 -- 7 7 6 6 6 6 6 6 6 --

This table can be used to calculate the quickest routes between two nodes on a network. The table is always read from the right hand side and is used thus:

Refer to the FTP session between the mobile node (node 0) and the correspondent (node 7). Starting from node 0 in the left hand column and looking across the row until node 7 is reached in the top row, this leads to node 1.

Next, taking node 1 in the left hand column and again running across to node 7 this yields node 2 (WiFi). This process is repeated until node 7 is reached.

This is highly relevant because, when the FTP session is started, the network looks at this table to decide which route it is going to take to send its packets. When the connection goes down this table is not updated instantly. This is the same problem that occurs in the real life physical setup. The routing tables take time to update and reflect changes, and, as a result, applications such as an FTP session will fail.

The results were as expected; The FTP session running between the mobile node and correspondent was terminated when the links went down.

note: For the results of these tests, see Testing and Evaluation, Chapter 6


5.4.5 Creating the NetSwap Agents

Poll The packets which the following code generates are ICMP packets with specific values set; ICMP packets have TYPE and CODE values. The TYPE defines the ICMP message that is being passed. In certain cases, a TYPE may have a sub message, called a CODE.

For example, a "destination unreachable" message might have a TYPE of 3 and a CODE of 3. This would be the ICMP message generated when a port on the target host is unreachable. When an ICMP message requires only a TYPE, the CODE will be set to 0.

There are a few ICMP TYPES and CODES which are unassigned for any current use. These could be used for the NetSwap poll packets. It was decided to use TYPE 8 and CODE 0 for this NetSwap implementation.

Further details on the ICMP packet contents and messages can be found in Appendix A.

// Generate Poll PacketPacket* pkt = allocpkt();hdr_netswap* hdrnsp = hdr_netswap::access(pkt);hdr_ip* hdrip = hdr_ip::access(pkt);int destination = atoi(argv[2]);hdrip->dst_.addr_ = destination;hdrip->src_.addr_ = here_.addr_;hdrip->proto_ = 1; // ICMP NetSwap protocolhdrnsp->type = 8;hdrnsp->code = 0;

printf("Sending Poll Request out at %f\n", Scheduler::instance().clock());

send(pkt, 0);

Poll Reply

Again, the poll acknowledgement packets are ICMP packets, this time of TYPE 0 and CODE 0. The following code also sets a flag in the packet to let the simulator know it is an ACK type packet.

// NetSwap Poll Request Packetif (hdrnsp->type == 8) { printf("%d Recieved Poll Request at %f - Sending Reply Back to %d\n",

here_.addr_,Scheduler::instance().clock(),pkt_ip_hdr->src_.addr_);

pkt_cmn_hdr->ptype_ = PT_ACK; pkt_ip_hdr->dst_.addr_ = pkt_ip_hdr->src_.addr_; pkt_ip_hdr->proto_ = 1; pkt_ip_hdr->src_.addr_ = here_.addr_; pkt_nsp_hdr->type = 0;

send(pkt,0); }

Choose Lowest Metric


The following code is responsible for deciding whether interfaces are up or not, and choosing the lowest metric. This is necessary due to problems experienced getting a timer working in NS-2. This timer was intended to measure how long or if a poll reply comes back from interfaces.

A workaround solution to the timer problem was to create a “control” node which would always be on and never be disconnected. This was then attached to the NetSwap driver node in the simulator. Every time a poll was sent to either the WiFi or GPRS interface nodes, another poll was also sent to the control node which was guaranteed to come back. Using this method, the control nodes link could be altered to add delay (e.g. 3 seconds for poll timeout) and a little bit of Boolean logic could be used to work out if WiFi or GPRS interfaces were up or not:

Control Interface Interface Up

1 1 Yes

1 0 No

0 1 Yes and still waiting for control to come back.

The same kind of procedure is used to determine which interfaces are quickest. If both interfaces are polled simultaneously; the quickest poll to come back will have the higher metric value set in a data structure called NetSwapPollTable::metric.

else if (hdrnsp->type == 0) { if (hdrnsp->code == 1 && NetSwapPollTable::reply != 1) { printf("Request timed out.\n"); } else if (hdrnsp->code == 1 && NetSwapPollTable::reply == 1) { printf("Ping successfull!\n"); } else if (hdrnsp->code == 0) { if (NetSwapPollTable::reply == 1) { // A Poll has come in before it, // therefore this one is slower NetSwapPollTable::node2 = pkt_ip_hdr->src_.addr_; NetSwapPollTable::node2_metric = 1; } else { // This is the first susseccfull poll in NetSwapPollTable::reply = 1; // Poll came in NetSwapPollTable::node1 = pkt_ip_hdr->src_.addr_; NetSwapPollTable::node1_metric = 1; } printf("%d Recieved Reply From %d at %f...\n", here_.addr_, pkt_ip_hdr->src_.addr_, Scheduler::instance().clock()); Packet::free(pkt); }}


NetSwap Address Update

The following code is for when the NetSwap gateway is updated with a new address. Receiving another specially constructed ICMP packet (TYPE 2 CODE 0), the gateway examines the data field of the ICMP packet. The data field has been filled by the NetSwap driver with the new return IP address to the mobile node. The gateway places this new address in a data structure called NetSwapGatewayTable::ReturnIP and puts the old value in NetSwapGatewayTable::OldReturnIP. (The old return IP is not used in this implementation but could be used in future, e.g. for a fallback interface).

All future communications and packet forwarding will use this new IP address.

else if (hdrnsp->type == 2) { printf("%d Recieved NetSwap Address Update From %d at %f, Update Data = %i \n", here_.addr_, pkt_ip_hdr->src_.addr_, Scheduler::instance().clock(), hdrnsp->data); NetSwapGatewayTable::OldReturnIP = NetSwapGatewayTable::ReturnIP; NetSwapGatewayTable::ReturnIP = hdrnsp->data; NetSwapGatewayTable::Online = 1; //0 = Offline, 1 = Online

// Create a new packet Packet* pktret = allocpkt(); // Access the NetSwap and IP headers for the new packet: hdr_netswap* hdrnsp_ret = hdr_netswap::access(pktret); hdr_ip* hdrip_ret = hdr_ip::access(pktret); hdr_cmn* hdrcmn_ret = hdr_cmn::access(pktret);

hdrcmn_ret->ptype_ = PT_ACK; //ICMP Type 7 not used hdrnsp_ret->type = 7; hdrnsp_ret->code = 0; //ICMP Code set to 0 (not used) hdrnsp_ret->checksum = "OK"; hdrip_ret->src_.addr_ = here_.addr_; hdrip_ret->dst_.addr_ = pkt_ip_hdr->src_.addr_; hdrip_ret->proto_ = 1;

send(pktret,0); Packet::free(pkt); }

NetSwap Address Update ACK

An acknowledgement is sent, from the Gateway code above back to the driver, letting it know the update was successful.

// A NetSwap Gateway Update Return Acknowledgement Receivedelse if (hdrnsp->type == 7) { printf("NetSwap Address Update ACK received OK!\n");}


Encapsulate

A second set of IP header information is created called enc_dst and enc_src. In the code below, the real header source and destination addresses for the packet are actually moved into the encapsulated headers (enc_src and enc_dst, as these are the inside headers). The new source and destination are placed within the outer normal IP headers (src_.addr_ and dst_.addr_).

Before Encapsulationsrc_.addr_ = 0 (mobile node)dst_.addr_ = 7 (correspondent)enc_src = not setenc_dst = not set

After Encapsulatonsrc_.addr_ = 0 (mobile node)dst_.addr_ = 6 (NetSwap Gateway)enc_src = 0 (mobile node)enc_dst = 7 (correspondent)

Further details on the IP packet contents can be found in Appendix A.

} else if (nodetype_ == 1) { pkt_cmn_hdr->addr_type_ = NS_AF_INET; pkt_cmn_hdr->next_hop_ = 3; printf("Normal Packet Recieved - Says Driver: %i So I'll Encapsulate it! the next hop is %i \n", here_.addr_,pkt_cmn_hdr->next_hop_); hdr_netswap* pkt_ipinip_hdr = hdr_netswap::access(pkt);

pkt_cmn_hdr->ptype_ = PT_ENCAPSULATED; pkt_ip_hdr->src_.addr_ = pkt_ip_hdr->src_.addr_; pkt_ip_hdr->dst_.addr_ = NetSwapPollTable::node1; //gateway address pkt_ip_hdr->proto_ = 94; pkt_ipinip_hdr->enc_src_ = pkt_ip_hdr->src_.addr_; pkt_ipinip_hdr->enc_dst_ = 7; pkt_ipinip_hdr->next_hop_ = 6; // Send the packet send(pkt, 0); }


Decapsulate and Change Source Address

The reverse happens as the packet is decapsulated at the Gateway. The original IP headers are restored from the enc_dst and enc_src addresses and, as in the designs, the source address is then amended to make it look to the correspondent as though the packet originated from the NetSwap gateway.

Before Decapsulationsrc_.addr_ = 0 (mobile node)dst_.addr_ = 6 (NetSwap Gateway)enc_src = 0 (mobile node)enc_dst = 7 (correspondent)

After Decapsulationsrc_.addr_ = 0 (mobile node)dst_.addr_ = 7 (correspondent)enc_src = not setenc_dst = not set

After Source Changesrc_.addr_ = 6 (NetSwap Gateway)dst_.addr_ = 7 (correspondent)enc_src = not setenc_dst = not set

//Protocol Number 94 for IPinIPelse if (pkt_ip_hdr->proto_ == 94 && nodetype_ == 2) { printf("Encapsulated Packet Recieved, So Ill unencapsulate it!\n"); hdr_netswap* pkt_ipinip_hdr = hdr_netswap::access(pkt);

pkt_cmn_hdr->ptype_ = PT_TCP; pkt_ip_hdr->src_.addr_ = here_.addr_; pkt_ip_hdr->dst_.addr_ = pkt_ipinip_hdr->enc_dst_; pkt_ip_hdr->proto_ = 65; send(pkt, 0);}

Change Destination Address

As the gateway receives the reply back from the correspondent, it modifies the destination address of the packet to the address stored within the NetSwapGatewayTable::ReturnIP data structure, finally sending it on its way back to the Mobile Node.

if (nodetype_ == 2) { printf("Normal Packet Recieved - I am the Gateway so send back to Mobile Node\n"); pkt_ip_hdr->ttl_ = 100; pkt_ip_hdr->src_.addr_ = 6; pkt_ip_hdr->dst_.addr_ = NetSwapGatewayTable::ReturnIP; printf("*** NetSwapGatewayTable::ReturnIP = %i ***\n", NetSwapGatewayTable::ReturnIP); send(pkt,0);}

note: For the results of these tests, see Testing and Evaluation, Chapter 6.


5.5 Problems and Restrictions of NS-25.5.1 Timer

As NS-2 is a discrete simulator it means that it has its own timers independent of the timers on the machine it is running on. Therefore it has its own set of routines and functions to access and utilise the time during the running of a simulation.

Timers can be implemented in both C++ code and in Tcl scripts, they are most often used in agents, but the framework is general enough to be used by other objects.

The use of timers was initially needed in the interface polling process of the NetSwap driver, the idea being a poll packet is sent out to an interface and a timer is set (for example 3 seconds) and if the poll reply came back within the time set the poll was successful, otherwise failed.

Each time a timer was implemented it would throw a “Segmentation Fault” at the point where a poll packet reached its destined interface node. This was a strange error, and the only explanation for this could be to do with the fact that the timer was initialised inside an object, which in this case is a NetSwap agent, and when this agent object gets deleted, so too does the timer, after its packets are finished with.

Fig 5.5.1 – solution to timer problems

After many failed attempts at getting a timer to successfully expire without the fault, it was decided to implement a different solution as seen in the code above.

5.5.2 Addressing Scheme

It was very surprising to find that NS-2 did not support 16-bit IP addresses (e.g. 192.168.0.56) as standard in its nodes; instead each node is simply numbered in sequence order with integer numbers (e.g. 3). This did not cause a problem in implementing the NetSwap agents but it would have been preferable to have had a hierarchical routing system and to be able to assign subnet ranges.

It was later found that NS-2 does have prevision for 16-bit IP addresses, but by this time the NetSwap solution had already progressed on the default addressing scheme.


5.5.4 GPRS Patch

A GPRS patch has been implemented by Richa Jain at IITB, which claims to include to ability add GPRS features to wireless nodes, so far the patch supports, mobile node to base station interactions.

The focus is on handling of the radio resources and on the network stack i.e. the Link Layer (LL), the Radio Link Control (RLC) and the Medium Access Control (MAC) (channels, TDMA slot structure, pkt tx and rx, call set-up and handling, slot handling, collisions, error model, handling ARPS) operating between the mobile node and the base station. [ISI04]

The problem with the GPRS patch is that it is not yet completed, and as a result it is very hard to install, and does not allow the user to create simulations which use GPRS as well as other wireless protocols such as WiFi, therefore it is not of much use in this project. Another problem is that it will only work on an older version of NS-2 (against NS 2.1b7a)

mailto:[email protected]


6. Testing and Evaluation6.1 Physical Testing

The following results show the effects that roaming between different wireless interface types has on applications using real physical hardware as described in the Implementation chapter 5. These results were produced to get a better idea of what effect roaming actually has on applications, taking special note of whether it could be classed as “seamless”.

note: Throughout the following tests using physical hardware, the simulation of “roaming” and “signal loss” was recreated, as shown in section 5.2.3 of this project, by covering the antennas of the wireless interfaces.

To ensure the figures in testing were not skewed by freak circumstances, each test was run five times. The graphs produced in this chapter have been produced from the average of the five results.


6.1.1 Task Manager Network Monitor

One freely available tool which comes with Microsoft Windows XP is the “Windows Task Manager”. This can be accessed in Windows by pressing “Ctrl + Alt + Del” at any time. It is a simple diagnostic tool which can be used to view running programs, processes, system performance and network statistics.

These statistics are very useful for viewing network interface utilisation. The following screen shot shows the output from Task Manager; two timeflow graphs which were captured over a session where the WiFi and GPRS interfaces were swapped between.

Fig 6.1.1a – Output from Tasks Manager showing network utilisation

As can be seen in the higher resolution graphs, at the point where a wireless interface goes down there is a short period of time before normal communication resumes on the second interface. During this, any of the tests performed timeout or take a great deal of time to recover, usually with adverse effects.


6.1.2 CuteFTP

The first test performed was to observe what happens when interfaces are swapped between during an FTP session. As expected, due to the stateless nature of FTP, the FTP session is unable to resume on a second interface after a wireless interface loses connection.

The graph below shows the utilisation of both the GRPS and WiFi wireless interfaces in the following scenario; Initially both WiFi and GPRS are connected and then WiFi looses radio range and, as a result, its network connection.

Fig 6.1.2a – FTP session using real hardware

At the beginning of this test, the FTP session was working across the WiFi interface (red line). As soon as WiFi looses connection, the FTP session is terminated and will not restart without user intervention. Therefore, GPRS (blue line) does not ever get utilised for this test.

As FTP is not a very good “seamless” protocol, it was decided to move onto an application which may perform a little better when network connection is lost. Windows Media Player was chosen to stream audio from an internet radio station.


6.1.3 Streaming Audio using Microsoft Media Player

The following tests produced some rather varied and unexpected results. Due to the fact that Media Player uses a buffer to read its audio stream ahead of what is actually being played, it was thought that this might offer a bit of leeway as interfaces were swapped between.

The first test was to observe the effects, when both WiFi and GPRS interfaces are online and the WiFi interface loses connection while streaming media.

Fig 6.1.3a – Streaming Media, WiFi > GPRS

These results were more as expected. Initially, Media Player was streaming media across WiFi due to its lower metric value. As the WiFi connection goes down, the buffer starts to run out. After the point where the buffer is empty, there is a delay while the routing tables are reset and a new route is established using GPRS. The buffer is then reloaded and streaming media resumed. This whole process takes approximately 26 seconds.

Had the Media Player buffer been longer, there is a possibility that, as the interfaces changed, it may have appeared to swap a little more seamlessly. This is due to the fact that, during the time where the buffer is being utilised after an interface goes down, the routing tables could be reset. If this process is done in time, before the extended buffer runs out, streaming can resume without a break.


The next graph shown the effect that a WiFi reconnection has on Media Player stream which is currently streaming over GPRS.

Fig 6.1.3b – Streaming Media, GPRS > WiFi > GPRS

The results are quite curious as they show that, at the point where WiFi is re-established, the buffer on GPRS is instantly cut and reloaded on WiFi. At the point where the WiFi buffer is fully loaded, it is again instantly cut and, strangely, reloads back on GPRS. The end result is that both WiFi and GPRS interfaces are online, but Media Player is still streaming its media across GPRS.

Due to this, a long period of time (157 seconds) passes before streaming media is resumed, albeit on the more expensive, slower metric, GPRS. It is not known why such an effect is produced.


Following on from the previous test with both WiFi and GPRS interfaces online and media streaming over GPRS, a GPRS connection loss is now simulated.

Fig 6.1.3c – Streaming Media, GPRS > WiFi

Showing the best Media Player results so far, the GPRS buffer runs out and the WiFi buffer reloads almost instantly. There is a total streaming media loss of approximately 15 seconds.


6.1.4 Ping

A quick test was performed using the Ping tool, in an attempt to discover how long it takes for it to start using another wireless connection after one goes down. The following is the command line output:

C:\>ping www.jlsnet.co.uk -t

Pinging www.jlsnet.co.uk [81.96.42.74] with 32 bytes of data:

Reply from 81.96.42.74: bytes=32 time=236ms TTL=244Reply from 81.96.42.74: bytes=32 time=46ms TTL=244Reply from 81.96.42.74: bytes=32 time=263ms TTL=244Reply from 81.96.42.74: bytes=32 time=46ms TTL=244Request timed out.Request timed out.Request timed out.Request timed out.Reply from 81.96.42.74: bytes=32 time=1642ms TTL=229Reply from 81.96.42.74: bytes=32 time=981ms TTL=229Reply from 81.96.42.74: bytes=32 time=1008ms TTL=229Reply from 81.96.42.74: bytes=32 time=749ms TTL=229Reply from 81.96.42.74: bytes=32 time=855ms TTL=229Reply from 81.96.42.74: bytes=32 time=667ms TTL=229Reply from 81.96.42.74: bytes=32 time=784ms TTL=229Reply from 81.96.42.74: bytes=32 time=1106ms TTL=229Reply from 81.96.42.74: bytes=32 time=659ms TTL=229Reply from 81.96.42.74: bytes=32 time=1053ms TTL=229Reply from 81.96.42.74: bytes=32 time=73ms TTL=244Reply from 81.96.42.74: bytes=32 time=47ms TTL=244Reply from 81.96.42.74: bytes=32 time=47ms TTL=244Reply from 81.96.42.74: bytes=32 time=51ms TTL=244Reply from 81.96.42.74: bytes=32 time=49ms TTL=244Reply from 81.96.42.74: bytes=32 time=48ms TTL=244Reply from 81.96.42.74: bytes=32 time=48ms TTL=244Reply from 81.96.42.74: bytes=32 time=62ms TTL=244Reply from 81.96.42.74: bytes=32 time=48ms TTL=244

Ping statistics for 81.96.42.74: Packets: Sent = 27, Received = 23, Lost = 4 (15% loss),Approximate round trip times in milli-seconds: Minimum = 65ms, Maximum = 1642ms, Average = 314ms

note: Blue represents GPRS and Red represents WiFi.

After the 4th ping poll, the WiFi antenna was covered simulating the loss of signal. There are four “Request timed outs” before the pings resume on GPRS. The default timeout for ping on the Windows XP Operating System is 750ms. Therefore, the total loss is 3000ms (3 seconds).


6.2 NS-2 Testing

The following results have been generated from tests performed using the NS-2 network simulator.

Two types of tests have been performed using an FTP simulator application. The first is a test to try and establish the similarities a NS-2 network simulation has with the physical FTP results in section 6.1.1. This will be done by running an FTP session from a node which has two interfaces and taking a connection down midway through an FTP session.

The second set of tests performed is the same FTP scenario but, this time, with the NetSwap solution in place within the simulation.


6.2.1 FTP, before NetSwap implementation

The following graph is produced from the results of a NS-2 simulation. The simulation was that of a normal FTP session between nodes 0 and 7.

Fig 6.2.1a – NS-2 Simulation showing FTP session failure

As discussed in section 5.4.4 the FTP session was terminated instantly as the link went down and not re-established over the new link.

Fig 6.2.1b – NS-2 graph representing FTP session failure

This is exactly the same behaviour as that recorded in the FTP session during the physical hardware testing in section 6.1.2 of this report. The FTP traffic is running over the WiFi connection which gets terminated as the link goes down (at 1 second) and does not get re-established on GPRS.

One thing that is to be noted in using the NS-2 FTP simulation, is that is does not seem to replicate the authentication process of a FTP session. When simulating a FTP session the only ‘handshaking’ process that appears to happen is an initial request SYN packet being sent and an ACK acknowledgement return, the ftp transfer will then commence. There is no username or password exchange in the simulation.

WiFi

GPRS

FTP Traffic


6.2.2 FTP, after NetSwap implementation

These are the most encouraging results, showing an almost instant changeover between the WiFi and GPRS connections.

In this simple scenario, the NetSwap gateway is sent an ICMP update address packet containing the GPRS address. This is done regardless of the fact that the WiFi link has not gone down, to test that the underlying encapsulation and address changing system works. As can be observed from the graph below, the FTP traffic gets transferred almost instantly through the GPRS connection.

Fig 6.2.2a – NS-2 NetSwap implementation Results

At the crossover point between WiFi and GPRS there are only 4 packets which are lost during the period where the NetSwap gateway is being updated with the new address. Any lost packets get re-transmitted thanks to the TCP/IP error recovery. This means that the FTP session carries on over the GPRS connection regardless.


The nest step of the NetSwap testing is to test the scenario of a connection actually going down.

The following graph shows the crossover between WiFi and GPRS. Initially, both connections are up and the FTP session is running across WiFi. The WiFi connection goes down at 1.00 seconds. After polling and determining that the WiFi connection is down, the NetSwap driver sends an update ICMP packet to the gateway. All new FTP traffic gets sent through the GPRS link and the gateway redirects any replies back through GPRS.

Fig 6.2.2b – NS-2 NetSwap implementation Results, with connection loss

Due to the time delay as the NetSwap driver polls its connections, and updates the gateway, there is a little more packet loss. However, this is still not enough to terminate the FTP session, which is again recovered by TCP/IP.


6.3 Comparison of NS-2 & Physical Results

In comparing the numeric results produced from the two stages of testing, it was a little difficult to find a direct relation between time of crossover and packet loss, because of the difficulty which has been previously discussed in recording packet loss in real hardware without the use of expensive packet sniffing tools. One thing which was comparable was the affects that a network connection loss has on both the real hardware and the simulations, and the time taken to swap between the network connections.

Comparisons of the physical results to the results gained from the NS-2 simulator highlighted the fact that without the implementation of the NetSwap solution, both sets of tests produced similar effects.

6.3.1 FTP Comparisons

While running an FTP session on the physical hardware, it was observed that the session was instantly terminated at the moment when the interface the session is running through looses wireless connection; this is the case even if there is another wireless connection available.

While running an FTP session within the NS-2 simulator the same behaviour was seen. This correlation between real hardware and simulation adds a little more confidence that the simulator is recreating the scenario correctly. With this in mind it is hoped that the NetSwap results may also prove correct if they were translated back to an implementation on real hardware.

6.3.2 Media Player Comparisons

Unfortunately, due to time constraints, streaming media tests on NS-2 were not done. NS-2 does have support for a RealMedia application add-ins, which can be attached to agents to simulate streaming media. This would have been used in a similar way to which the FTP NS-2 add-in was used.

It would have been useful to have run some RealMedia tests as a comparison to the Windows Media Player physical results.

6.3.3 Ping Comparisons

The physical ping tests which were run out of interest in section 6.2.4 did show the speed at which single ping packets are transferred between interfaces.

A ping packet is an ICMP packet and therefore can be compared to the NetSwap poll packets which were implemented in the NS-2 simulations.


7. Conclusion and Future Work

After implementation and testing of the NetSwap solution within the NS-2 simulator, some encouraging results were produced. These results proved that the NetSwap solution is able to cut down the packet loss and crossover time as a mobile node roams between different types of wireless network.

As the NetSwap solution is not protocol dependent it is not restricted to GPRS and WiFi protocols. The solution can be used with any type of IP based network interface, including wired connections such as Ethernet.

The NetSwap design is a software based solution, which means the driver could be implemented on any type of mobile node (including Laptops, PDA’s or Mobile Phones) and the gateway can be implemented on any type of router (e.g. Cisco router or Linux box). It could be provided as a feature set to add to routers.

7.1 Future Work 7.1.1 Real Hardware Implementation of NetSwap

Even though NS-2 is supposed to simulate a real network in every respect, including the way protocols work, delays, and data transport, it may be dangerous to assume that the NetSwap solution will work on real hardware.

In the future, the NetSwap solution could be implemented on real physical hardware, instead of in simulation. This may involve programming a NDIS driver which can be installed on a mobile node, and a gateway, such as a Linux box, to be programmed with the new NetSwap routing features.

It would have been slightly out of the scope of this honours project and it would have taken a great deal of time especially in programming to get a physical NetSwap artefact working.

Now that all designs have been documented clearly in pseudo code, UML etc, a physical implementation project for this solution is feasible.

7.1.2 Error Detection

Midway through an interface change, there may be some packet loss due to delay between interface change and the NetSwap Gateway being updated or connections going down midway through packet transfer. It may be safe to assume that TCP/IP will pick up any error correction and retransmit any lost packets, but for future designs of the NetSwap idea, error recovery could be built into the NetSwap Gateway. It could cache all packets until it is known that the Mobile Node has successfully received them, and retransmit any packets which are not known to have been successfully transferred due to interface change.


7.1.2 Old IP address fallback

If an ICMP address update packet sent from the NetSwap driver to the gateway gets lost or corrupt en route, it may be a good idea for the gateway to have a second backup address to which it could default if a route to the mobile node can not be found.

Future design additions to the NetSwap solution could include scope for storing previously known routes back to the mobile node in the gateway. This would be of advantage if a current route back to the mobile node is lost and no address packet is received. In such a situation, the gateway could attempt to fall back on the previous address in case the mobile node has roamed back to a previous wireless connection.

The initial phases of this were started in the implementation stages of this project (section 5.4.5), but not finished.

7.1.3 Changing of the return IP address

In the current solution the source IP address, which is set to fool the end correspondent into returning its reply back to the NetSwap gateway, is changed within the NetSwap gateway after the point where the packet is decapsulated. It would also be feasible for the NetSwap driver instead to change this source address in the original packet before it gets encapsulated and sent to the gateway.

In fact, this is very similar to the way in which MobileIP works, with the Mobile Node setting its return address to its Home Agent.

Without testing, it is hard to think of an advantage, either way, for setting this ‘return IP’.

7.1.4 Multiple Users

The current design of the NetSwap idea has only been tested for a single user scenario. In a case where there would be multiple mobile nodes wishing to use a single NetSwap gateway, a user identification system would be needed.

This may make things difficult and would mean that the gateway would need to keep track of all incoming and outgoing packets and who they are intended for. This tracking system may have to work in a similar way to which NAT (Network Address Translation) works, with multiple users behind one gateway.

NAT was designed to decrease a private network’s use of the now scarce public IP addresses. A NAT device takes a packet’s originating private IP address, converts that address into a public IP address, then sends the packet across the internet to its destination. NAT devices use an internal table to keep track of converted addresses. [WINNETMAG04]

The table which NAT uses could be the solution to having multiple NetSwap users.


8. Evaluation against the requirements

The aim of this project was to produce a solution which would reduce the packet loss and errors incurred when a mobile node roams between different wireless networks, making transfer more seamless.

This project has managed to outline the current solutions and technologies; from that knowledge, a newer solution (NetSwap) has been proposed.

A breakdown of the aims is as follows:- Research into technology and solutionsIn-depth research was made into three network technologies (Ethernet, WiFi and GPRS) and a study made into three current mobility solutions (MobileIP, OOC and SDR). This knowledge was used to gain a better understanding of why the mobility problem occurs, and used for future design of the new NetSwap idea.

Design of new ideaThe new solution (NetSwap) was discussed and designed. It was decided to use the UML methodology for documenting the idea due to its flexibility and wide industry use. Along with UML diagrams, pseudo code was used to go more in-depth to parts of the design.

Testing and comparisonsTesting on both real hardware and network simulation software has been performed. It was decided to use both implementations in testing to ensure that the simulation results would be more true to life. Comparisons were made in order to measure the performance of the proposed solution against a scenario recreating the problem.

Software based solutionThe end result is a software based solution which could eventually be developed to run on any type of mobile node communicating with one or more types of wireless network.

Within the project, the NetSwap solution has been designed and documented, and later implemented using NS-2 network simulation software. From this implementation some encouraging results have been gained that show the NetSwap solution to be a working and viable answer to the roaming problem.

The aims which were initially set at the beginning of this project have been met, the end product being a proposed alternative solution. However, although the solution has been found to work in simulation, there are a number of changes and addition which could be implemented for future developments.


Bibliography

[ABOELELA03] Emad Aboelela Ph.D, Network Simulation Experiments Manual, Morgan Kaufmann Publishers, 3003, Chapter 0, Preface, ISBN: 0-12-042171-2

[ADDA03] Mo Adda, Advanced Networking Lecture Notes, Portsmouth University, 2003, Page 3

[ARRL03] A Software-Defined Radio for the Masses,Retrieved from http://www.arrl.org/tis/info/pdf/020708qex013.pdf, Part 1, Page 13, Accessed 2003

[CISCO03a] Cisco – Introduction to Mobile IP,Retrieved from http://www.cisco.com/en/US/tech/tk827/tk369/technologies_white_paper09186a00800c9906.shtml, Accessed 2003

[CISCO03b] Cisco - Ethernet Encapsulation Cheat Sheet,Retrieved from http://www.cisco.com/warp/public/105/encheat.html, Accessed 2003

[CISCO03c] Jack Unger, Deploying Licence-Free Wireless Wide-Area Networks, Cisco Press, 2003, ISBN: 1587050692

[EGAN00] Michael Egan, Networking Theory 101: Introduction to Networking, Retrieved from http://mike.passwall.com/networking/icmppacket.html, Created 08.07.2000

[FERRERO99] Alexis Ferrero, Eternal Ethernet, Addison-Wesley Pub Co; 1st edition, 1999, Page 90, Chapter 6, ISBN: 0-202-36056-X

[FINDART04] Computer Technology Review: Occasionally connected computing,Retrieved from http://www.findarticles.com/cf_dls/m0BRZ/9_23/109082341/p1/article.jhtml, April 2004

[GIGAPORT02] Gigaport 2002, How Mobile IP Works,Retrieved from http://www.gigaport.nl/netwerk/access/ta/mip/en_mobileip.html, Accessed 2003

[GSMWORLD03] GSMWorld Web Site,Retrieved from http://www.gsmworld.com/technology/GPRS/class.shtml, Accessed 2003

[IBM03] MQ Anywhere,Retrieved from http://www-3.ibm.com/software/integration/wmqe/, Accessed 2003

[INTEL03a] Occasionally Connected ComputingRetrieved from http://cedar.intel.com/cgi-bin/ids.dll/content/content.jsp?cntKey=GenericEditorial::mobile_occasionalconnect&cntType=IDS_EDITORIAL&catCode=CVS, Accessed 2003

[INTEL04b] Radio Free Intel: Research and Development at IntelRetrieved from http://www.intel.com/labs/radio/ , Accessed 2004

[ISI04] The Network Simulator ns-2: Contributed Code,Retrieved from http://www.isi.edu/nsnam/ns/ns-contributed.htmlAccessed April 2004

[KHADRA04a] Fadi Khadra, Intergration of Wireless and GPRS Systems, Master of Science in Information Systems Project, Portsmouth University, 2004, Page 46, Adhoc AP Diagram

[KHADRA04b] Fadi Khadra, Intergration of Wireless and GPRS Systems, Master of Science in Information Systems Project, Portsmouth University, 2004, Page 12, SDR

[MOTOROLA02] Motorola, Corporate Training Manual, Introduction to GPRS, Version 1, Revision 8, 2002

[NOVATEL03] Novatel Wireless,Retrieved from http://www.novatelwireless.com/support/GPRS%20tech.html, Accessed 2003

[OMNET04] OMNeT++ Community Site - Make your Net Work,Retrieved from http://www.omnetpp.org/, Accessed 2004

http://www.omnetpp.org/

http://www.novatelwireless.com/support/gprs%20tech.html

http://www.novatelwireless.com/support/gprs%20tech.html

http://www.isi.edu/nsnam/ns/ns-contributed.html

http://www.intel.com/labs/radio/





http://www.gsmworld.com/technology/gprs/class.shtml

http://www.gigaport.nl/netwerk/access/ta/mip/en_mobileip.html

http://www.findarticles.com/cf_dls/m0BRZ/9_23/109082341/p1/article.jhtml

http://www.findarticles.com/cf_dls/m0BRZ/9_23/109082341/p1/article.jhtml

http://mike.passwall.com/networking/icmppacket.html

http://www.cisco.com/warp/public/105/encheat.html

http://www.cisco.com/en/US/tech/tk827/tk369/technologies_white_paper09186a00800c9906.shtml

http://www.cisco.com/en/US/tech/tk827/tk369/technologies_white_paper09186a00800c9906.shtml

http://www.arrl.org/tis/info/pdf/020708qex013.pdf


[QUALNET04] Scalable Network Technologies,Retrieved from http://www.scalable-networks.com/, Accessed 2004

[RAD04] Ethernet History,Retrieved from http://www2.rad.com/networks/2001/ethernet/hist.htmAccessed 2004

[RFC1700] RFC 1700 - Assignment of protocol parameters for IP suite, Retrieved from http://mike.passwall.com/networking/rfc/rfc1700.txt, Accessed 2003

[SISTECH03] What is NDIS?, SisTech - NDISOne,Retrieved from http://www.ndisone.com/whatisndis.html, Accessed 2003

[SOC04] SOC - System-On-Chip,Retrieved from http://soc.ece.ubc.ca/, April 2004

[STEVENS94] W. Richard Stevens, TCP/IP Illustrated Volume 1, Addison-Wesley, 1994, Page 69. ISBN: 0-201-63346-9

[TCL04]Getting Started with Tcl,Retrieved from http://dev.scriptics.com/scripting/, Accessed April 2004

[WINNETMAG04] NAT Transversal,Retrieved from http://www.winnetmag.com/Article/ArticleID/40597/40597.html,Accessed 2004

[ZYTRAX03] Zytrax ProductsRetrieved from http://www.zytrax.com/tech/wireless/802_mac.htm, Accessed 2003

http://www.zytrax.com/tech/wireless/802_mac.htm

http://www.winnetmag.com/Article/ArticleID/40597/40597.html

http://dev.scriptics.com/scripting/

http://soc.ece.ubc.ca/

http://www.ndisone.com/whatisndis.html

http://mike.passwall.com/networking/rfc/rfc1700.txt

http://www2.rad.com/networks/2001/ethernet/hist.htm

http://www.scalable-networks.com/


Glossary of Terms

2G Second Generation Mobile Phone Network

3G Third Generation Mobile Phone Network

Ad-HocWiFi Wireless Peer to Peer Mode

API Application Program Interface

BSC Base Station Controller – GPRS Infrastructure

CRC Cyclic Redundancy Check

CSMA/CD Carrier Sense Multiple Access/Collision Detect

DHCP Dynamic Host Configuration Protocol

DSP Digital Signal Processors

DSSS Direct Sequence Spread Spectrum - Wireless Radio Mode

ETSI European Telecommunications Standard Institute – Standards Council

FCS Frame Check Sum – Packet Checking

FHSS Frequency Hopping Spread Spectrum - Wireless Radio Mode

FTP File Transport Protocol

GGSN Gateway GPRS Support Node – GPRS Infrastructure

GMSC Gateway Mobile Switching Center – GPRS Infrastructure

GPRS General Packet Radio Service

GSM Global Mobile System

GUI Graphical User Interface

HLR AUCHolds information about the GSM subscriber, for Initial Registration and Authorization

ICMP Internet Control Message Protocol

IEEE Institute of Electrical and Electronics Engineers – Standards Council

ITU International Telecommunications Union

MAC Media Address Control

MSC Mobile Switching Center – GPRS Infrastructure

NDIS Network Device Interface Specification

NS-2 Network Simulator version 2

OFDM Orthogonal Frequency Division Multiplexing - Wireless Radio Mode

OPNET Optimum Network Performance

OSI Open Systems Interconnect

OTcl Object-oriented Tool Command Language

PDA Personal Digital Assistant

PDU Packet Data Unit

PO Box Post Office Box (real life postal system)

POTS Plain Old Telephone System

PSTN Public Switched Telephone Network

SGSNServicing GPRS Support Node – GPRS Infrastructure

Tcl Tool Command Language

TCP/IP Transport Control Protocol / Internet Protocol

TTL Time To Live

http://bmrc.berkeley.edu/research/cmt/cmtdoc/otcl/index.html


UML Unified Modelling Language

VoIP Voice Over IP

WiFi Wireless Fidelity


Glossary of Symbols

Desktop Node - Connected Via Ethernet

GPRS Cell Transmitter

Mobile Node

Network Cloud e.g. Internet

Packet

Router

Storage for Database

Wireless Access Point

Wireless Signal Connection


Antenna


Appendix A - Packet Headers

IP Header [STEVENS94]

Version (4 bit)

Header Length (4bit)

Type of Service (TOS)(8 bit)

Size of Datagram (16 bit)

Identification (16 bit)

Flags (3 bit)

Fragment Offset(13 bit)

Time to Live (TTL)(8 bit)

Protocol(8 bit)

Header Checksum(16 bit)

Source IP Address(32 bit)

Destination IP Address (32 bit)

OptionsData

Version Always set to the value 4, which is the current version of IP.

Header Length Number of 32-bit words forming the header, usually five.

Type of ServiceNow known as Differentiated Services Code Point (DSCP) (usually set to 0, but may indicate particular Quality of Service needs from the network, the DSCP defines one of a set of class of service.

Size of Datagram In bytes, this is the combined length of the header and the data.

Identification 16-bit number which together with the source address uniquely identifies this packet - used during reassembly of fragmented datagrams.

Flags A sequence of three flags (one of the 4 bits is unused) used to control whether routers are allowed to fragment a packet (i.e. the Don't Fragment, DF, flag), and to indicate the parts of a packet to the receiver.

Fragment Offset A byte count from the start of the original sent packet, set by any router which performs IP router fragmentation.

Time To Live Number of hops/links which the packet may be routed over, decremented by most routers - used to prevent accidental routing loops.

Protocol Service Access Point (SAP) indicates the type of transport packet being carried (e.g. 1=ICMP; 2=IGMP; 4=IpinIP; 6=TCP; 17=UDP; 94=IPinIP).

Header Checksum A 2's complement checksum inserted by the sender and updated whenever the packet header is modified by a router - Used to detect processing errors introduced into the packet inside a router where the packet is not protected by a link layer cyclic redundancy check. Packets with an invalid checksum are discarded by all nodes in an IP network.


Source IP Address The IP address of the original sender of the packet.

Destination IP Address The IP address of the final destination of the packet.

Options Not normally used, but when used the IP header length will be > 5 32-bit words to indicate the size of the options field.



TCP Header [STEVENS94]

Source Port Number(16 bit)

Destination Port Number(16 bit)

Sequence Number(32 bit)

Acknowledgement Number(32 bit)

Header Length(4 bit)

Reserved(6 bit)

URG

ACK

PSH

RST

SYN

FIN

Window Size(16 bit)

TCP Checksum(16 bit)

Urgent Pointer(16 bit)

OptionsData

Source Port Number16 bits. The source port number.

Destination Port Number16 bits The destination port number.

Sequence Number32 bits. The sequence number of the first data octet in this segment (except when SYN is present). If SYN is present the sequence number is the initial sequence number (ISN) and the first data octet is ISN+1.

Acknowledgment Number32 bits. If the ACK control bit is set this field contains the value of thenext sequence number the sender of the segment is expecting toreceive. Once a connection is established this is always sent.

Header Length4 bits. The number of 32 bit words in the TCP Header. This indicates where the data begins. The TCP header (even one including options) is anintegral number of 32 bits long.

Reserved6 bits. Reserved for future use. Must be zero.

Control Bits6 bits. (from left to right): URG: Urgent Pointer field significantACK: Acknowledgment field significantPSH: Push FunctionRST: Reset the connectionSYN: Synchronize sequence numbersFIN: No more data from sender

Window16 bits. The number of data octets beginning with the one indicated in theacknowledgment field which the sender of this segment is willing toaccept.


TCP Checksum16 bits. The checksum field is the 16 bit one's complement of the one'scomplement sum of all 16 bit words in the header and text. If asegment contains an odd number of header and text octets to becheck summed, the last octet is padded on the right with zeros toform a 16 bit word for checksum purposes. The pad is nottransmitted as part of the segment. While computing the checksum,the checksum field itself is replaced with zeros.

The checksum also covers a 96 bit pseudo header conceptuallyprefixed to the TCP header. This pseudo header contains the SourceAddress, the Destination Address, the Protocol, and TCP length.This gives the TCP protection against misrouted segments. Thisinformation is carried in the Internet Protocol and is transferredacross the TCP/Network interface in the arguments or results ofcalls by the TCP on the IP.

The TCP Length is the TCP header length plus the data length inoctets (this is not an explicitly transmitted quantity, but iscomputed), and it does not count the 12 octets of the pseudoheader.

Urgent Pointer16 bits this field communicates the current value of the urgent pointer as a positive offset from the sequence number in this segment. Theurgent pointer points to the sequence number of the octet followingthe urgent data. This field is only be interpreted in segments withthe URG control bit set.

Options



ICMP Header [EGAN00]

Type(8 bit)

Code(8 bit)

Checksum(16 bit)

Data

Type (8 bits): Is a kind of classification for grouping a "class" of communication types together.

Code (8 bits): These are various types of messages that fit into the classification of the types listed above. The Internet Control Message Protocol (ICMP) has many messages that are identified by a "type" field, a small selection...

Type Code

0 Echo Reply

1 Unassigned

2 Unassigned

3 Destination Unreachable

8 Echo

9 Router Advertisement

10 Router Selection

30 Traceroute

32 Mobile Host Redirect

for more information about other codes see [RFC1700]

Checksum (16 bits) this is a checksum that covers the header and data portion of an ICMP packet to allow the receiving host to verify the integrity of an incoming ICMP packet. The ICMP packet, is loaded with a predefined number in the checksum field, and then when the checksum is computed, then the checksum is written over the previous value. As it turns out, there is no "REQUIRED" or "SUGGESTED" for this procedure in the RFC on ICMP (as of this date AFAIK). Nevertheless, it is a good idea to at least properly compute the checksum for packets you send out. This is so that, if the remote system does drop ICMP packets with invalid checksum, yours will not always be dropped.

Data (Variable bits): As you might expect, this is the payload, or data portion of an ICMP packet. The payload includes type and code values referring to control information.



Ethernet Header & Trailer [CISCO03b]

Preamble(first 32 bits)

Preamble(last 32 bits)

Destination MAC(first 32 bits)

Destination MAC(last 16 bits)

Source MAC(first 16 bits)

Source MAC(last 32 bits)

Type / Length(16 bits)

Options

DataFrame Check Sum (CRC)

(32 bits)

Preamble 64 bit preamble is sequence of alternating 1 and 0 for receiver synchronization with signal.

Destination MAC The first six bytes of an Ethernet frame make up the Destination Address. This specifies to which adapter the data frame is being sent. A Destination Address of all ones (111.111.111.111) specifies a Broadcast Message that is read by all receiving Ethernet adapters. The first three bytes of the Destination Address are assigned by the IEEE to the vendor of the adapter and are specific to the vendor.

Source MAC The next six bytes of an Ethernet frame make up the Source Address. The Source Address specifies from which adapter the message originated. Like the Destination Address, the first three bytes specify the vendor of the card.

Type / Length Type is the type of data encapsulated, (e.g. IP, ARP, RARP, etc) 16-bits. Length is the length of the data.

Options

Data 0 - 2312 octets (bytes).

Frame Check Sum Frame Check Sequence (32 bit CRC). Defined in P802.11.



802.11 Wireless Header & Trailer [ZYTRAX03]

Frame Control(16 bits)

Duration / ID(16 bits)

Source Address(first 32 bits)

Source Address(last 16 bits)

Destination Address(first 16 bits)

Destination Address (last 32 bits)

Receiving station Address (destination wireless station)(first 32 bits)

Receiving station Address (destination wireless station)

(last 16 bits)

Sequence Control(16 bits)

Transmitting wireless station(first 32 bits)

Transmitting wireless station(last 16 bits) Data

DataFrame Check Sum (CRC)

(32 bits)

Frame ControlTypeSubtypeTo DS. 1 = to the distribution system.From DS. 1 = exit from the Distribution System.More Frag. 1 = more fragment frames to follow (last or unfragmented frame = 0)Retry. 1 = this is a re-transmission.Power Mgt. 1 = station in power save mode, 1 = active mode.More Data. 1 = additional frames buffered for the destination address (address x).WEP. 1 = data processed with WEP algorithm. 0 = no WEP.Order. 1 = frames must be strictly ordered.Duration ID For data frames = duration of frame. For Control Frames the associated identity of the transmitting station.

Source AddressAddress 1 Source address (6 bytes).

Destination AddressAddress 2 Destination address (6 bytes).

Receiving station AddressAddress 3 Receiving station address (destination wireless station)

Sequence Control

Transmitting wireless stationAddress 4 Transmitting wireless station.

DataFrame Body 0 - 2312 octets (bytes).

Frame Check Sequence (32 bit CRC). Defined in P802.11.



RLC Downlink Header [MOTOROLA02]

Payload Type(2 bits)

Related Reserved Block Period

(2 bits)

Supplementary/Polling(1 bit)

Uplink State Flag(3 bits)

Power Reduction(2 bits)

Temporary Flow Indicator(5 bits)

Final Block Indicator

(1 bit)

Block Sequence Number(7 bits)

Extension(1 bit)

Length Indicator(6 bits)

More(1 bit)

Countdown

Value(1 bit)

.

.

.

Length Indicator(6 bits)

More(1 bit)

Countdown

Value(1 bit)

Data

Payload TypeIndicates the type of RLC/MAC Block. That is, whether it contains a RLC data block or an RLC/MAC control block.

Related Reserved Block PeriodSpecifies the uplink radio block (relative to the block containing it) the Mobile Node can use to send an acknowledgement. When this field is valid, it means the network is polling the Mobile Node for packet acknowledgement or control acknowledgement.

Supplementary/Polling1 bit indicates whether the Related Reserved Block Period field is valid or not.

Uplink State FlagIndicated the owner of the next uplink radio block. It is used especially in 2-way data transfer to indicate whether the Mobile Node has the right to send an uplink data block.

Power ReductionIndicated the power reduction of the current RLC block.

Temporary Flow IdentifierIndicates the Temporary Block Flow (Allocated Radio Resource) to which the RLC data block belongs.

Final Block IndicatorIndicates that this is the last download RLC data block of the downlink.

Block Sequence NumberCarries the Sequence number of the of the RLC data block.


Extension 1 bit - Indicates the presence of an optional field (length indicator) in the RLC header.

Length IndicatorIndicates the number of Octets belonging to the LLC PDU’s in the RLC data block.

More1 bit - indicates whether another LLC PDU follows the current one within the RLC data block or not.


Countdown ValueIs the countdown procedure. The Network can calculate the number of RLC data blocks remaining for the current transfer by means of this countdown sent by the Mobile Node. Mobile Node sends every uplink data and its value will start decreasing when the amount of blocks to send goes below a threshold. This field will have a value of 0 for the last RLC data block belonging to this transfer.

Stall IndicatorIndicates whether the Mobile Nodes transmit window can advance or not (i.e. whether the window is full or not)

Retry1 bit - Indicates if one or more than channel requests messages were sent by the Mobile Node during channel access.

TLLI IndicatorIndicates whether the Temporary Logic Link Identity Field is present or not. TLLI contains the identity that will be used during contention resolution procedure. Only used for Uplink Header just before the Data.


Appendix B – NetSwap Classes

NetSwap Driver- packet- e_packet- ipAddress- GRPS_IP- WiFi_IP- openInterface+ TestInterfaces()+ ChooseLowestMetric()+ ResetRouting()+ Send()+ Timeout()+ NetSwapAddressUpdateOK()+ PollReply()+ Encapsulate()

NetSwap Gateway- openInterface- returnIP- packet- e_packet+ NetSwapAddressUpdate()+ Decapsulate()+ ChangeDestAddress()+ ChangeSourceAdd()+ Send()

GPRS Interface- packet- ipAddress- defaultGateway- subnetMask+ Poll()+ Send()

WiFi Interface- packet- ipAddress- defaultGateway- subnetMask+ Poll()+ Send()

Mobile Node- RoutingTable- packet+ Send() Web Server (Correspondent)

- ipAddress- packet- destAddress- webpage- reply+ Send()+ Recv()


Appendix C - OSI Layers

Seven layers are defined: 7) Application : Provides different services to the applications 6) Presentation : Converts the information 5) Session : Handles problems which are not communication issues 4) Transport : Provides end to end communication control 3) Network : Routes the information in the network 2) Data Link : Provides error control between adjacent nodes 1) Physical : Connects the entity to the transmission media

Source: [http://www2.rad.com/networks/1994/osi/layers.htm]


Appendix D – Results

802.11b > GPRS 802.11b and GPRS are on at Start - then 802.11b is turned offbuffer runout Reconnect buffer load8.289 12.143 5.62111.667 11.133 6.5078.038 10.732 8.4838.040 8.884 6.01810.181 8.583 5.884

GPRS > 802.11b When 802.11b is switched on while GPRS is Already Onbuffer reloads on 802.11b

buffer loads back to GPRS??

68.275 94.42668.478 92.74273.140 83.19272.309 82.30170.020 103.911

When GPRS is Switched Off8.469 Instant 6.39211.487 Instant 5.2537.121 Instant 6.1898.563 Instant 6.1018.598 Instant 7.408


Appendix E – Main NS-2 NetSwap Code

// Copyright (c) 2004 by James Saunders (JLSNet) for Portsmouth University UK// All rights reserved.//// PROJECT: NetSwap// DESCRIPTION: Seamless Roaming Between Wireless Networks // WEBSITE: http://www.jlsnet.co.uk/index.php?page=projects_netswap?tab=1// EMAIL: [email protected]

#include <unistd.h>#include "netswap.h"#include "connector.h"#include "packet.h"#include "timer-handler.h"#include "ns-process.h"#include "app.h"#include "route.h"#include "mip.h"#include <assert.h>#include "delay.h"#include "agent.h"#include "flags.h"#include "tcp-sink.h"#include "ip.h"

int hdr_netswap::offset_;

static class NetSwapHeaderClass : public PacketHeaderClass {public:

NetSwapHeaderClass() : PacketHeaderClass("PacketHeader/NetSwap", sizeof(hdr_netswap)) {

bind_offset(&hdr_netswap::offset_);}

} class_netswaphdr;

static class NetSwapClass : public TclClass {public:

NetSwapClass() : TclClass("Agent/NetSwap") {}TclObject* create(int, const char*const*) {

return (new NetSwapAgent());}

} class_netswap;

NetSwapAgent::NetSwapAgent() : Agent(PT_NETSWAP) {bind("packetSize_", &size_);

} void MyTimer::expire(Event* e){

printf("The Poll timer has expired at %f, The contents of the netswap table is : %i\n",

Scheduler::instance().clock(), NetSwapPollTable::reply);

a_->timeout(0);}


http://www.jlsnet.co.uk/index.php?page=projects_netswap?tab=1


int NetSwapAgent::command(int argc, const char*const* argv){if (argc == 2) { //one command passed in

if (strcmp(argv[1], "poll") == 0) {

// Create a new packetPacket* pkt = allocpkt();

// Access the ICMP and IP header for the new packet:hdr_netswap* hdrnsp = hdr_netswap::access(pkt);hdr_ip* hdrip = hdr_ip::access(pkt);hdrnsp->type = 8; //ICMP Type 8 used for PING Request

hdrnsp->code = 0; //ICMP Code set to 0 (not used)hdrnsp->checksum = "OK";hdrip->proto_ = 1;

// Send Packetsend(pkt, 0);

// Set Driver Poll Table to say poll request sent out.NetSwapPollTable::reply = 0;

// Start poll timeout Timer running.MyTimer timer;printf("Sending Poll Request out at %f\

n",Scheduler::instance().clock());double poll_timeout = 1.010513;timer.sched(poll_timeout); return (TCL_OK);

}

} else if (argc == 3) { //two commands passed inif (strcmp(argv[1], "update") == 0) {

//This is where packets to be sent to the NetSwap Gateway are Generated.

Packet* pkt = allocpkt();

hdr_cmn* hdrcmn = hdr_cmn::access(pkt);hdr_netswap* hdrnsp = hdr_netswap::access(pkt);hdr_ip* hdrip = hdr_ip::access(pkt);hdrnsp->type = 2; //ICMP Type 2 Unnassigned so using for

NetSwaphdrnsp->code = 0; //ICMP Code set to 0 (not used)hdrnsp->checksum = "OK";//hdrcmn->ptype_ = PT_ENCAPSULATED;;//hdrip->proto_ = 94;

hdrip->dst_.addr_ = NetSwapPollTable::node1;// Set Data Field to contain the address of the currently

active Interfacehdrnsp->data = NetSwapPollTable::node1;hdrnsp->next_hop_ = atoi(argv[2]);hdrnsp->enc_src_ = here_.addr_;hdrnsp->enc_dst_ = 7;

// Send Packetsend(pkt, 0);

return (TCL_OK);

} else if (strcmp(argv[1], "encap") == 0) {

// Generate Encapsulated PacketPacket* pkt = allocpkt();hdr_netswap* hdrnsp = hdr_netswap::access(pkt);hdr_ip* hdrip = hdr_ip::access(pkt);hdr_ipinip **phdrinip = (hdr_ipinip

**)hdr_ipinip::access(pkt);assert(phdrinip);

hdr_ip *hdrinip = &(*phdrinip)->hdr_;int destination = atoi(argv[2]);

//Remember to uncomment lines in 1671 to 1690 i//tcl/lib/ns-lib.tcl!! RE: slot error

hdrip->dst_.addr_ = destination;hdrip->proto_ = 94; // protocol number for IPinIPsend(pkt, 0);

return (TCL_OK);


} else if (strcmp(argv[1], "poll") == 0) {// Generate Poll PacketPacket* pkt = allocpkt();hdr_netswap* hdrnsp = hdr_netswap::access(pkt);hdr_ip* hdrip = hdr_ip::access(pkt);int destination = atoi(argv[2]);hdrip->dst_.addr_ = destination;hdrip->src_.addr_ = here_.addr_;hdrip->proto_ = 1; // ICMP NetSwap protocolhdrnsp->type = 8;hdrnsp->code = 0;

printf("Sending Poll Request out at %f\n",Scheduler::instance().clock());

send(pkt, 0);

// Generate Poll PacketPacket* pkt2 = allocpkt();hdr_netswap* hdrnsp2 = hdr_netswap::access(pkt2);hdr_ip* hdrip2 = hdr_ip::access(pkt2);

hdrip2->dst_.addr_ = 8;hdrip2->src_.addr_ = here_.addr_;hdrip2->proto_ = 1; // ICMP NetSwap protocolhdrnsp2->type = 8;hdrnsp2->code = 1;

send(pkt2,0); // Set Driver Poll Table to say poll request sent out.NetSwapPollTable::reply = 0;NetSwapPollTable::node1 = 0;// Start poll timeout Timer running.//MyTimer timer;

//double poll_timeout = 0.011513;//timer.sched(poll_timeout); return (TCL_OK);

} else if (strcmp(argv[1], "data") == 0) {// Generate Data PacketPacket* pkt = allocpkt();

hdr_cmn* hdrcmn_hdr = hdr_cmn::access(pkt);hdrcmn_hdr->ptype_ = PT_TCP;

hdr_netswap* hdrnsp = hdr_netswap::access(pkt);hdr_ip* hdrip = hdr_ip::access(pkt);int destination = atoi(argv[2]);hdrip->dst_.addr_ = destination;hdrip->src_.addr_ = here_.addr_;hdrip->proto_ = 66; // random protocolsend(pkt, 0);return (TCL_OK);

} else if (strcmp(argv[1], "newret") == 0) {NetSwapPollTable::node1 = atoi(argv[2]);

return (TCL_OK);

} else if (strcmp(argv[1], "nodetype") == 0) {if (strcmp(argv[2], "normal") == 0) {nodetype_ = 0;}if (strcmp(argv[2], "driver") == 0) {nodetype_ = 1;}if (strcmp(argv[2], "gateway") == 0) {nodetype_ = 2;}

if (strcmp(argv[2], "interface") == 0) {nodetype_ = 3;}return (TCL_OK);

}}

// If none of the commands from above then pass onto the main agent class.return (Agent::command(argc, argv));}


void NetSwapAgent::recv(Packet* pkt, Handler*){printf("The Agent Has Revieved a Packet...");// Access the headers for the received packet:hdr_ip* pkt_ip_hdr = hdr_ip::access(pkt);hdr_netswap* pkt_nsp_hdr = hdr_netswap::access(pkt);hdr_cmn* pkt_cmn_hdr = hdr_cmn::access(pkt);

if (pkt_nsp_hdr->next_hop_ != 0 && nodetype_ == 3){pkt_ip_hdr->dst_.addr_ = pkt_nsp_hdr->next_hop_;send(pkt,0);

}else//Added new field to /common/ip.h for protocol type called int proto_

//Protocol Number 1 for ICMPif (pkt_ip_hdr->proto_ == 1) {

// As It is an ICMP Packet Access the NetSwap header for the received packet

hdr_netswap* hdrnsp = hdr_netswap::access(pkt);

// printf("\nICMP Packet Recieved!!\n Type: %i\n Code: %i\n Checksum: %s\n Data: %s\n",

// hdrnsp->type, // hdrnsp->code,// hdrnsp->checksum, // hdrnsp->data);

// NetSwap Poll Request Packetif (hdrnsp->type == 8) {

printf("%d Recieved Poll Request at %f - Sending Reply Back to %d\n",

here_.addr_,Scheduler::instance().clock(),pkt_ip_hdr->src_.addr_);

pkt_cmn_hdr->ptype_ = PT_ACK;pkt_ip_hdr->dst_.addr_ = pkt_ip_hdr->src_.addr_;pkt_ip_hdr->proto_ = 1;pkt_ip_hdr->src_.addr_ = here_.addr_;pkt_nsp_hdr->type = 0;

send(pkt,0); }

// A NetSwap Poll Reply Type Packetelse if (hdrnsp->type == 0) {

if (hdrnsp->code == 1 && NetSwapPollTable::reply != 1) { printf("Request timed out.\n");

} else if (hdrnsp->code == 1 && NetSwapPollTable::reply == 1) {

printf("Ping successfull!\n");

} else if (hdrnsp->code == 0) {if (NetSwapPollTable::reply == 1) {

// A Poll has come in before it, therefore this one is slower

NetSwapPollTable::node2 = pkt_ip_hdr->src_.addr_;

NetSwapPollTable::node2_metric = 1;} else {

// This is the first susseccfull poll in

NetSwapPollTable::reply = 1; // Poll came in

NetSwapPollTable::node1 = pkt_ip_hdr->src_.addr_;

NetSwapPollTable::node1_metric = 1;}

printf("%d Recieved Reply From %d at %f...\n",here_.addr_,pkt_ip_hdr->src_.addr_,Scheduler::instance().clock());

Packet::free(pkt);


}}

// A NetSwap Gateway Update Type Packetelse if (hdrnsp->type == 2) {

printf("%d Recieved NetSwap Address Update From %d at %f, Update Data = %i \n",

here_.addr_, pkt_ip_hdr->src_.addr_, Scheduler::instance().clock(),hdrnsp->data);

NetSwapGatewayTable::OldReturnIP = NetSwapGatewayTable::ReturnIP;

NetSwapGatewayTable::ReturnIP = hdrnsp->data;NetSwapGatewayTable::Online = 1; //0 = Offline, 1 =

Online

// Create a new packetPacket* pktret = allocpkt();// Access the NetSwap and IP headers for the new packet:hdr_netswap* hdrnsp_ret = hdr_netswap::access(pktret);hdr_ip* hdrip_ret = hdr_ip::access(pktret);hdr_cmn* hdrcmn_ret = hdr_cmn::access(pktret);

hdrcmn_ret->ptype_ = PT_ACK;hdrnsp_ret->type = 7; //Type 7 not know what use is yet!!

temporary usehdrnsp_ret->code = 0; //ICMP Code set to 0 (not used)hdrnsp_ret->checksum = "OK";hdrip_ret->src_.addr_ = here_.addr_;hdrip_ret->dst_.addr_ = pkt_ip_hdr->src_.addr_;hdrip_ret->proto_ = 1;

send(pktret,0);Packet::free(pkt);

}

// A NetSwap Gateway Update Return Acknolegement Recievedelse if (hdrnsp->type == 7) {

printf("NetSwap Address Update ACK recieved OK!\n");}

}

//Protocol Number 94 for IPinIPelse if (pkt_ip_hdr->proto_ == 94 && nodetype_ == 2) {

printf("Encapsulated Packet Recieved, So Ill unencapsulate it!\n");//hdr_ipinip **pkt_ipinip_hdr=(hdr_ipinip

**)hdr_ipinip::access(pkt);hdr_netswap* pkt_ipinip_hdr = hdr_netswap::access(pkt);

pkt_cmn_hdr->ptype_ = PT_TCP;pkt_ip_hdr->src_.addr_ = here_.addr_; pkt_ip_hdr->dst_.addr_ = pkt_ipinip_hdr->enc_dst_;pkt_ip_hdr->proto_ = 65;

send(pkt, 0);} else if (pkt_ip_hdr->proto_ == 94 && nodetype_ == 3) {

printf("Im just working as the next hop! says: %d\n",here_.addr_);pkt_ip_hdr->dst_.addr_ = pkt_nsp_hdr->next_hop_;

send(pkt,0);}// Protocol Unknown This is a normal packet which needs redirecting via the

Gatewayelse {

if (nodetype_ == 2) {printf("Normal Packet Recieved - I am the Gateway so send

back to Mobile Node\n");pkt_ip_hdr->ttl_ = 100;pkt_ip_hdr->src_.addr_ = 6;//NetSwapGatewayTable::ReturnIP = 3; // Temporarily Set

Until Update Processpkt_ip_hdr->dst_.addr_ = NetSwapGatewayTable::ReturnIP; printf("*** NetSwapGatewayTable::ReturnIP = %i ***\n",

NetSwapGatewayTable::ReturnIP);send(pkt,0);


} else if (nodetype_ == 1) {pkt_cmn_hdr->addr_type_ = NS_AF_INET;pkt_cmn_hdr->next_hop_ = 3;printf("Normal Packet Recieved - Says Driver: %i So I'll

Encapsulate it! the next hop is %i \n",here_.addr_, pkt_cmn_hdr->next_hop_);hdr_netswap* pkt_ipinip_hdr = hdr_netswap::access(pkt);

pkt_cmn_hdr->ptype_ = PT_ENCAPSULATED;pkt_ip_hdr->src_.addr_ = pkt_ip_hdr->src_.addr_;pkt_ip_hdr->dst_.addr_ = NetSwapPollTable::node1;

//gateway addresspkt_ip_hdr->proto_ = 94;pkt_ipinip_hdr->enc_src_ = pkt_ip_hdr->src_.addr_;pkt_ipinip_hdr->enc_dst_ = 7; pkt_ipinip_hdr->next_hop_ = 6;// Send the packetsend(pkt, 0);

} else if (nodetype_ == 3) { printf("Interface Recieved a Packet! Need to forward onto

Driver\n");pkt_ip_hdr->dst_.addr_ = 0;pkt_ip_hdr->src_.addr_ = 1;send(pkt,0);

} else if (nodetype_ == 1) { printf("Driver Recieved a Packet! Need to forward onto

Driver\n"); pkt_ip_hdr->dst_.addr_ = 0;

send(pkt,0); }

}}


Appendix F – NS-2 NetSwap Tcl Script

# Copyright (c) 2004 by James Saunders (JLSNet) for Portsmouth University UK# All rights reserved.## PROJECT: NetSwap# DESCRIPTION: Seamless Roaming Between Wireless Networks # WEBSITE: http://www.jlsnet.co.uk/index.php?page=projects_netswap?tab=1# EMAIL: [email protected]

#Create a simulator objectset ns [new Simulator]

#Open the nam trace fileset nf [open out.nam w]$ns namtrace-all $nf

#Define a 'finish' procedureproc finish {} { global ns nf $ns flush-trace #Close the trace file close $nf #Execute nam on the trace file exec nam out.nam & exit 0}

Agent/NetSwap instproc recv {from rtt} { $self instvar node_

puts "interface $from is up!"}

$ns color 1 red$ns color 2 blue

#Create nodesset mn [$ns node]$mn label MobileNodeset ns_drv [$ns node]$ns_drv label NetSwapDriverset eth0 [$ns node]$eth0 label WiFiset eth1 [$ns node]$eth1 label GPRSset router0 [$ns node]set router1 [$ns node]set ns_gw [$ns node]$ns_gw label NetSwapGatewayset www [$ns node]$www label Correspondentset control [$ns node]

$control color purple$control shape hexagon

#Create a duplex link between the nodes$ns duplex-link $mn $ns_drv 1Mb 10ms DropTail$ns duplex-link $ns_drv $eth0 0.2Mb 10ms DropTail$ns duplex-link $ns_drv $eth1 1Mb 10ms DropTail$ns duplex-link $eth0 $router0 1Mb 10ms DropTail$ns duplex-link $eth1 $router1 1Mb 10ms DropTail$ns duplex-link $router0 $ns_gw 1Mb 10ms DropTail$ns duplex-link $router1 $ns_gw 1Mb 10ms DropTail$ns duplex-link $ns_gw $www 100Mb 10ms DropTail$ns duplex-link $ns_drv $control 1Mb 30ms DropTail

#Setup Node orientation for NAM$ns duplex-link-op $mn $ns_drv orient left$ns duplex-link-op $ns_drv $eth0 orient left-up$ns duplex-link-op $ns_drv $eth1 orient left-down$ns duplex-link-op $eth0 $router0 orient left$ns duplex-link-op $eth1 $router1 orient left


http://www.jlsnet.co.uk/index.php?page=projects_netswap?tab=1


$ns duplex-link-op $router0 $ns_gw orient left-down$ns duplex-link-op $router1 $ns_gw orient left-up$ns duplex-link-op $ns_gw $www orient left$ns duplex-link-op $control $ns_drv orient down

set control_agent [new Agent/NetSwap]$control_agent nodetype normal$ns attach-agent $control $control_agent

set eth0_agent [new Agent/NetSwap]$eth0_agent nodetype interface$ns attach-agent $eth0 $eth0_agent

set eth1_agent [new Agent/NetSwap]$eth1_agent nodetype interface$ns attach-agent $eth1 $eth1_agent

# Setup a TCP connection Between Mobile Node and Driverset tcp [new Agent/TCP]$ns attach-agent $mn $tcpset ftp [new Application/FTP]$ftp attach-agent $tcp$ftp set type_ FTPset ns_drv_agent1 [new Agent/NetSwap]$ns_drv_agent1 set fid_ 1$ns_drv_agent1 nodetype driver$ns attach-agent $ns_drv $ns_drv_agent1$ns connect $tcp $ns_drv_agent1

# Setup connection between the Correspondent (www) and the gatewayset www_agent [new Agent/TCPSink]$ns attach-agent $www $www_agentset ns_gw_agent3 [new Agent/NetSwap]$ns_gw_agent3 nodetype gateway$ns attach-agent $ns_gw $ns_gw_agent3$ns connect $ns_gw_agent3 $www_agent

$ns at 0.0 "$ns_drv_agent1 newret 3"$ns at 0.1 "$ftp start"$ns at 1.5 "$ns_drv_agent1 poll 2"$ns at 1.5 "$ns_drv_agent1 poll 3"$ns at 1.55 "$ns_drv_agent1 update 6"

$ns rtmodel-at 0.99 down $ns_drv $eth1$ns rtmodel-at 0.99 down $router1 $eth1$ns at 1.0 "$ns_drv_agent1 poll 2"$ns at 1.0 "$ns_drv_agent1 poll 3"#$ns at 1.0 "$ns_drv_agent1 newret 2"$ns at 1.05 "$ns_drv_agent1 update 6"

#$ns at 0.61 "$ns compute-routes"

$ns at 2.1 "$ftp stop"$ns at 3.0 "finish"

#Run the simulation$ns run

[Microsoft Word format].doc

Documents

Transcript of [Microsoft Word format].doc