improvement of wireless network …gtu.ac.in/uploads/119997111007_vyomal_pandya.pdfimprovement of...

IMPROVEMENT OF WIRELESS NETWORK

EFFICIENCY

A Thesis submitted to Gujarat Technological University

For the Award of

DOCTOR OF PHILOSOPHY

in

ELECTRONICS & COMMUNICATION ENGINEERING

by

PANDYA VYOMAL NAISHADHKUMAR

119997111007

Under supervision of

DR. PRASHANT M. DOLIA

GUJARAT TECHNOLOGICAL UNIVERSITY

AHMEDABAD

December - 2016

i

DECLARATION

I declare that the thesis entitled “Improvement of Wireless Network Efficiency” submitted by

me for the degree of Doctor of Philosophy is the record of research work carried out by me

during the period from Sept 2011 to October 2016 under the supervision of Dr. Prashant M.

Dolia and this has not formed the basis for the award of any degree, diploma, associateship,

fellowship, titles in this or any other University or other institution of higher learning.

I further declare that the material obtained from other sources has been duly acknowledged in

the thesis. I shall be solely responsible for any plagiarism or other irregularities, if noticed in

the thesis.

Signature of the Research Scholar: ............................. Date………….....

Name of Research Scholar: Pandya Vyomal Naishadhkumar

Place: Surat

ii

CERTIFICATE

I certify that the work incorporated in the thesis “Improvement of Wireless Network

Efficiency” submitted by Mr. Pandya Vyomal Naishadhkumar was carried out by the

candidate under my supervision. To the best of my knowledge: (i) the candidate has not

submitted the same research work to any other institution for any degree/ diploma,

Associateship, Fellowship or other similar titles (ii) the thesis submitted is a record of original

research work done by the Research Scholar during the period of study under my supervision,

and (iii) the thesis represents independent research work on the part of the research scholar.

Signature of Supervisor: ............................. Date………….....

Name of Supervisor: Dr. Prashant M. Dolia

Place: Bhavnagar

iii

ORIGINALITY REPORT CERTIFICATE

It is certified that PhD Thesis titled “Improvement of Wireless Network Efficiency” by

Pandya Vyomal Naishadhkumar has been examined by us. We undertake the following:

a: Thesis has significant new work / knowledge as compared already published or are under

consideration to be published elsewhere. No sentence, equation, diagram, table, paragraph or

section has been copied verbatim from previous work unless it is placed under quotation marks

and duly referenced.

b: The work presented is original and own work of the author (i.e. there is no plagiarism). No

ideas, processes, results, or words of others have been presented as an Author own work.

c: There is no fabrication of data or results which have been compiled / analyzed.

d: There is no falsification by manipulating research materials, equipment or processes, or

changing or omitting data or results such that the research is not accurately represented in the

research record.

e: The thesis has been checked using Plagiarism Checker X (copy of originality report

attached) and found within limits as per GTU Plagiarism Policy and instructions issued from

time to time.

Signature of the Research Scholar: …………………………… Date: ….………


Place : Surat

Signature of Supervisor: ……………………………… Date: ………………


Place: Bhavnagar

vi

PhD THESIS Non-Exclusive License to

GUJARAT TECHNOLOGICAL UNIVERSITY

In consideration of being a PhD Research Scholar at GTU and in the interests of the facilitation

of research at GTU and elsewhere, I, Pandya Vyomal Naishadhkumar having 119997111007

hereby grant a non-exclusive, royalty free and perpetual license to GTU on the following terms:

a) GTU is permitted to archive, reproduce and distribute my thesis, in whole or in part,

and/or my abstract, in whole or in part (referred to collectively as the Work”) anywhere

in the world, for non-commercial purposes, in all forms of media;

b) GTU is permitted to authorize, sub-lease, sub-contract or procure any of the acts

mentioned in paragraph (a);

c) GTU is authorized to submit the Work at any National / International Library, under

the authority of their “Thesis Non-Exclusive License”;

d) The Universal Copyright Notice (©) shall appear on all copies made under the authority

of this license;

e) I undertake to submit my thesis, through my University, to any Library and Archives.

Any abstract submitted with the thesis will be considered to form part of the thesis.

f) I represent that my thesis is my original work, does not infringe any rights of others,

including privacy rights, and that I have the right to make the grant conferred by this

non-exclusive license.

g) If third party copyrighted material was included in my thesis for which, under the terms

of the Copyright Act, written permission from the copyright owners is required, I have

obtained such permission from the copyright owners to do the acts mentioned in

paragraph (a) above for the full term of copyright protection.

vii

h) I retain copyright ownership and moral rights in my thesis, and may deal with the

copyright in my thesis, in any way consistent with rights granted by me to my

University in this non-exclusive license.

i) I further promise to inform any person to whom I may hereafter assign or license my

copyright in my thesis of the rights granted by me to my University in this non-

exclusive license.

j) I am aware of and agree to accept the conditions and regulations of PhD including all

policy matters related to authorship and plagiarism.

Signature of the Research Scholar: …………………………… Date: ….………


Place : Surat

Signature of Supervisor: ……………………………… Date: ………………


Place: Bhavnagar

viii

THESIS APPROVAL FORM

The viva-voce of the PhD Thesis submitted by Mr. Pandya Vyomal Naishadhkumar

(Enrollment No. 119997111007) entitled “Improvement of Wireless Network Efficiency”

was conducted on (day and date) at Gujarat Technological University.

(Please tick any one of the following option)

□ We recommend that he/she be awarded the Ph.D. Degree.

□ We recommend that the viva-voce be re-conducted after incorporating the following

suggestions:

(briefly specify the modification suggested by the panel)

□ The performance of the candidate was unsatisfactory. We recommend that he/she should not

be awarded the Ph.D. Degree.

(The panel must give justifications for rejecting the research work)

Name and Signature of Supervisor with Seal 1) External Examiner 1 Name and Signature

2) External Examiner 2 Name and Signature 3) External Examiner 3 Name and Signature

ix

ABSTRACT

From its modest beginnings, the Internet has emerged as an imperative infrastructure servicing

the data communication demands of the new generation. Both the proliferation of IEEE 802.11

based hand-held wireless terminals (e.g. laptops, PDAs, advanced cellular phones etc.) and the

growing popularity of wireless Internet applications, led to the extensive deployment of

wireless communication networks like WLAN in public domain.

Now a day networks are facing problem with Intermittent Connectivity, Long or Variable

Delay, asymmetric data rates & High Error Rates. Delay Tolerant Network (DTN) may

overcome these problems by using sore – and – forward message switching. The storage places

can hold messages indefinitely. They are called persistence storage, as opposed to very short

term storage provided by memory chips. DTN routers need persistence storage to store the

packet until the next hope information is available with it.

DTN will allow BUNDLE layer on the top of transport layer. This will give node – to – node

retransmissions by means of custody transfers. Such transfers are arranged between the bundle

layers of successive nodes, at the initial request of the source application.

The aim of this research is to enhance the performance of DTN routing protocols. This benefits

the networks with either long delays or very lossy links. For path containing many lossy links,

retransmission requirements are much lower for hop – by – hop retransmissions than for end –

to – end retransmissions.

To apply the same DTN protocols in the network in which vehicles are moving very fast and

changing the topology after every second, Vehicular Delay Tolerant Network (VDTN) is

developed.

In VDTN, spray and wait protocol is giving better performance in any condition. To enhance

the performance of Spray and Wait protocol the proposed algorithm is to transmit 70% of data

to the nearby node instead of sending 50% data. This enables the node to transmit more data

compared to the previous algorithm. This results in more delivery probability. Hence this

modification not only reduces the chance of loss of data but also increases the possibility of

delivery. Due to custody transfer transmitter is not over burdened by retransmission.

x

Author has first checked the performance of Mobile Ad-Hoc Networks protocols in different

scenarios. After that author found that these protocols are not performing better in this

scenarios. So we switched to Delay Tolerant Network protocols. Author has introduced

different routing protocols of DTN in VDTN. For that author has taken two city maps. Author

has changed different parameters for the simulations and found that Spray and Wait protocol

is good in terms of performance.

After finding the proper protocol author has tried to enhance performance of Spray and wait

protocol. Author has suggested some modifications in the existing protocol. Suggestion is to

allow sender to send more data instead of 50% of data in Binary mode of Spray and Wait.

Algorithm is changed and performance is simulated. After exhaustive simulations author found

that modified algorithm is performing better than existing algorithm.

xi

ACKNOWLEDGEMENT

I wish to express my sincere appreciation to those who have contributed to this thesis and

supported me in one way or the other during this amazing journey.

First, I am extremely grateful to my supervisor, Dr. Prashant M. Dolia, Associate Professor,

Department of Computer Science, Maharaja Krishnakumar Sinhji Bhavnagar University,

Bhavnagar, Gujarat for his guidance and all the useful discussions and brainstorming sessions,

especially during the difficult conceptual development stage. His deep insights helped me at

various phases of my research. His invaluable suggestions and constructive criticisms from

time to time enabled me to complete my work successfully.

The completion of this work would not have been possible without, the Doctorate Progress

Committee (DPC) members: Dr. Chandresh. K. Khumbharana, Head and Professor,

Department of Computer Science, Saurashtra University, Rajkot and Retr. Professor Dr. V. R.

Rathod, Ex. HOD, Department of Computer Science, Bhavnagar University, Bhavnagar. I am

thankful for their rigorous examinations and precious suggestions during my research.

I would also like to take this opportunity to thank HOD & Associate Professor Shri S. R.

Dwivedi, Department of Computer Science, Maharaja Krishnakumar Sinhji Bhavnagar

University, Bhavnagar for their very helpful comments and suggestions.

My gratitude goes out to the assistance and support of Dr. Akshai Aggarwal, Ex. Vice

Chancellor, Dr. Rajul K. Gajjar, I/c Vice Chancellor, Shri J. C. Lilani, Registrar, Mr. Dhaval

Gohil, Data Entry Operator and other staff members of PhD Section, GTU.

This is one more opportunity for me to thank one person second time. My M.E. is completed

in the guidance of Dr. Purvang Dalal, Associate Professor, Dharmsinh Desai University. I

would like to thank him for continuously guiding me in this field of networking.

xii

I would like to thank Chintan Desai, Sharmila Rana and Sonal Gandhi for many discussions

and for the joint work which resulted in a publication. At this stage, I would also like to

acknowledge guidance and support provided by each and every member of C. K. Pithawalla

College of Engineering and Technology, Surat. Without that it may not be possible to reach

at this stage of my journey in the field of research.

Finally, I would like to thank my mother Mrs. Harsha N. Pandya and my father Mr.

Naishadhkumar J. Pandya. They supported me without questioning any of the decisions I

made throughout this process. They were always unconditional in extending their trust and

belief in me. I would also like to thank my beloved wife Khyati and my son Nibhish for

unconditional love and support in my hard times during this journey. I owe everything to them,

without their everlasting love, this thesis would never be completed.

Pandya Vyomal Naishadhkumar

xiii

Contents

DECLARATION .......................................................................................................................................... i

CERTIFICATE ............................................................................................................................................ ii

ORIGINALITY REPORT CERTIFICATE ...................................................................................................... iii

PhD THESIS Non-Exclusive License to GUJARAT TECHNOLOGICAL UNIVERSITY ................................. vi

THESIS APPROVAL FORM .................................................................................................................... viii

ABSTRACT .............................................................................................................................................. ix

ACKNOWLEDGEMENT ........................................................................................................................... xi

List of Figure ........................................................................................................................................ xvii

List of Table........................................................................................................................................... xix

Chapter 1 ................................................................................................................................................. 1

INTRODUCTION ....................................................................................................................................... 1

1.1 Introduction ................................................................................................................................. 1

1.2 TCP Performance Issues .............................................................................................................. 2

1.3 Need of Delay Tolerant Network and Vehicular Delay Tolerant Network .................................. 4

1.4 Need of Vehicular Ad-hoc Network (VANET) .............................................................................. 7

1.5 VDTN Routing Problems .............................................................................................................. 9

1.6 Motivation of Research ............................................................................................................. 10

1.7 Definition of Problem ................................................................................................................ 11

1.8 Objective and Scope of Work .................................................................................................... 11

1.9 Research Contribution ............................................................................................................... 11

1.10 Composition of Thesis ............................................................................................................... 12

1.11 SUMMARY ................................................................................................................................. 12

Chapter 2 ............................................................................................................................................... 13

LITRATURE REVIEW ............................................................................................................................... 13

2.1 Protocol Layers in Conventional Internet .................................................................................. 13

2.2 Packet Encapsulation in Conventional Network ....................................................................... 14

2.3 Conventional Protocol in Conventional Internet....................................................................... 15

2.4 Mutual Information Based Approaches .................................................................................... 17

2.5 Need of Delay Tolerant Network (DTN) .................................................................................... 18

2.6 Bundle Layer .............................................................................................................................. 19

2.6.1 Bundles ...................................................................................................................... 20

2.6.2 Bundle Structure ....................................................................................................... 21

2.6.3 Administrative Payload ............................................................................................. 21

2.6.4 Bundles and Bundle Encapsulation ........................................................................... 21

xiv

2.7 DTN Nodes ................................................................................................................................. 22

2.8 Store and Forward Message Switching ..................................................................................... 23

2.9 Custody Transfer........................................................................................................................ 24

2.10 Regions and Nodes .................................................................................................................... 26

2.11 Routing in DTN ........................................................................................................................... 26

2.12 Routing Problems in Traditional Vehicular Ad-hoc Network .................................................... 27

2.13 Knowledge Based Classification of DTN Routing Protocol ........................................................ 27

2.13.1 Deterministic Routing ............................................................................................... 29

2.13.2 Stochastic Routing ..................................................................................................... 30

2.14 Introduction of VANET ............................................................................................................... 35

2.15 Concept of VDTN ....................................................................................................................... 36

2.16 Vehicle Traffic Model ................................................................................................................. 37

2.16.1 Vehicle – Roadside Data Access ................................................................................ 38

2.16.2 A Model for the Vehicle – Roadside Data Access ...................................................... 39

2.16.3 Roadside Unit Scheduling Scheme ............................................................................ 40

2.16.4 Vehicle – Vehicle Data Access Model ........................................................................ 43

2.16.5 Concept of Vehicle Assisted Data Delivery Protocol ................................................. 44

2.17 SUMMARY ................................................................................................................................. 46

Chapter 3 ............................................................................................................................................... 47

3.1 Traffic Analysis of SURAT City .................................................................................................... 47

3.2 The ONE (The Opportunistic Network Environment) Simulator ............................................... 48

3.2.1 Node Capabilities ...................................................................................................... 49

3.2.2 Mobility Modelling .................................................................................................... 50

3.2.3 Routing ...................................................................................................................... 52

3.2.4 Application Support .................................................................................................. 52

3.2.5 Interfaces................................................................................................................... 53

3.2.6 Reporting and Visualization ...................................................................................... 53

3.2.7 Creating Simulation Scenario .................................................................................... 54

3.3 Simulation Parameter Setup Information ................................................................................. 55

3.3.1 Interface Setup Information ...................................................................................... 56

3.3.2 Grouping of Vehicles ................................................................................................. 57

3.4 Quality Assessment Parameters ................................................................................................ 60

3.5 SUMMARY ................................................................................................................................. 61

Chapter 4 ............................................................................................................................................... 62

PERFORMANCE COMPARISON OF ROUTING PROTOCOLS IN VDTN ..................................................... 62

4.1 Introduction ............................................................................................................................... 62

xv

4.2 Performance Metrics ................................................................................................................. 65

4.3 Simulation Result Analysis for SURAT City ................................................................................ 66

4.3.1 Successful Transmission Ratio ................................................................................... 66

4.3.2 Packet Delivery Probability ....................................................................................... 67

4.3.3 Channel Overhead Ratio ........................................................................................... 68

4.3.4 Average Latency ........................................................................................................ 68

4.3.5 Average Hop Count ................................................................................................... 69

4.3.6 Average Message Buffer Time .................................................................................. 70

4.4 Simulation Result Analysis of SURAT City with BRTS and Shortest Path Implementation ........ 70

4.4.1 Successful Transmission Ratio ................................................................................... 71

4.4.2 Packet Delivery Probability ....................................................................................... 71

4.4.3 Channel Overhead Ratio ........................................................................................... 72

4.4.4 Average Latency ........................................................................................................ 72

4.4.5 Average Hop Count ................................................................................................... 73

4.4.6 Average Message Buffer Time .................................................................................. 73

4.5 Performance Analysis for Different Routing Protocols in VDTN for SURAT City ....................... 74

4.6 Simulation Result for Performance Enhancement .................................................................... 76

4.7 Simulation Result for Performance Assessment of Improved VDTN in Node Variation

Environment ......................................................................................................................................... 81

4.8 Simulation Results for Performance Assessment of Improved VDTN in Traffic Variation

Environment ......................................................................................................................................... 84

4.9 SUMMARY ................................................................................................................................. 85

Chapter 5 ............................................................................................................................................... 86

5.1 Difference with Existing Binary Mode Spray And Wait Protocol............................................... 86

5.2 Algorithm and Explanation of Algorithm ................................................................................... 87

5.3 Simulation Results of Improved VDTN with Modified Spray And Wait Protocol ...................... 88

5.4 SUMMARY ................................................................................................................................. 93

Chapter 6 ............................................................................................................................................... 94

RESULT ANALYSIS, CONCLUSION AND FUTURE SCOPE ......................................................................... 94

6.1 Result Analysis in Terms of Delivery Probability for Modified Spray And Wait Protocol in

Different Scenarios ............................................................................................................................... 94

6.2 Result Analysis in Terms of Buffer Time for Modified Spray And Wait Protocol in Different

Scenarios ............................................................................................................................................... 97

6.3 Result Analysis in Terms of Overhead Ratio for Modified Spray And Wait Protocol in Different

Scenarios ............................................................................................................................................... 99

6.4 CONCLUSION ........................................................................................................................... 102

6.5 FUTURE SCOPE ........................................................................................................................ 104

xvi

List of Publication ................................................................................................................................ 105

REFERENCES ........................................................................................................................................ 106

APPENDIX ............................................................................................................................................ 114

xvii

List of Figure Figure – 2.1.1 Protocol Layers mechanism for Conventional Internet [43]. ........................................ 14

Figure – 2.2.1 Layer by Layer Data Encapsulation Process in Conventional Internet [43]. ................. 15

Figure – 2.4.1 Packet Switching Strategy in Conventional Internet [9]. .............................................. 17

Figure – 2.5.1 Such Situations where Delay Tolerant Network is required [9]. ................................... 18

Figure – 2.6.1 Comparisons of Internet Protocol Layers and DTN Protocol Layers [43]. ................... 20

Figure – 2.6.2.1 Bundle Structure of DTN ........................................................................................... 21

Figure – 2.6.4.1 Bundle Encapsulation in Delay Tolerant Network (DTN) [43]. ................................ 22

Figure – 2.7.1 DTN Nodes [43] ............................................................................................................ 23

Figure – 2.8.1 Store-And-Forward Message Strategy in Delay Tolerant Network. ............................. 24

Figure – 2.9.1 Custody Transfer in DTN [43]. ..................................................................................... 25

Figure – 2.13.1 Knowledge Based Classification of DTN Routing Protocols .................................... 28

Figure – 2.15.1 Concept of Vehicular Delay Tolerant Networks. ........................................................ 36

Figure – 2.16.2.1 An Architecture of Vehicle – Roadside Data Access Module .................................. 39

Figure – 2.16.3.1 Service ratio for FCFS, FDF, and SDF schemes. ..................................................... 42

Figure – 2.16.5.1 Architecture of Vehicle assisted Data Delivery Model ............................................ 44

Figure – 2.16.5.2 Transmission Mode in VADD. ................................................................................. 46

Figure - 3.2.1 Overview of the ONE Simulation Environment [76]. .................................................... 48

Figure – 3.3.1 The Open Street Map of Surat City. .............................................................................. 55

Figure – 3.3.2 The Surat City Map in Well Known Text Format. ........................................................ 56

Figure – 4.3.1 Successful Transmission Comparison Chart. ................................................................ 67

Figure – 4.3.2 Average Packet Delivery Probability Comparison Chart. ............................................. 67

Figure – 4.3.3 Channel Overhead Ratio Comparison Chart. ................................................................ 68

Figure – 4.3.4 Average Latency Comparison Chart. ............................................................................ 69

Figure – 4.3.5 Average Hop Count Comparison Chart. ........................................................................ 69

Figure – 4.3.6 Average Message Buffer Time Comparison Chart. ...................................................... 70

Figure – 4.4.1 Successful Transmission Comparison Chart. ................................................................ 71

Figure – 4.4.2 Average Packet Delivery Probability Comparison Chart. ............................................. 71

Figure – 4.4.3 Channel Overhead Ratio Comparison Chart. ................................................................ 72

Figure – 4.4.4 Average Latency Comparison Chart. ............................................................................ 73

Figure – 4.4.5 Average Hop Count Comparison Chart. ........................................................................ 73

Figure – 4.4.6 Average Message Buffer Time Comparison Chart. ...................................................... 74

Figure - 4.5.1 Delivery probability vs. Transmission data rate graph for analysis ............................... 74

Figure - 4.5.2 Overhead ratio vs. Transmission data rate graph for analysis ........................................ 75

Figure - 4.6.1 Delivery Probability vs. No. of copies graph for Spray and Wait protocol in normal

mode ...................................................................................................................................................... 77

Figure - 4.6.2 Delivery Probability vs. No. of copies graph for Spray and Wait protocol in binary

mode ...................................................................................................................................................... 78

Figure - 4.6.3 Overhead ratio vs. No. of copies graph for Spray and Wait protocol in normal mode .. 79

Figure - 4.6.4 Overhead ratio vs. No. of copies graph for Spray and wait protocol in binary mode. ... 80

Figure - 4.7.1 Delivery Probability vs. No. of Nodes graph in Node variation environment ............... 82

Figure - 4.7.2 Overhead Ratio vs. No. of Nodes graph in Node variation environment ....................... 83

Figure - 4.8.1 Delivery Probability vs. Message Traffic graph in Traffic variation environment ........ 84

Figure - 4.8.2 Overhead Ratio vs. Message Traffic in Traffic variation environment .......................... 85

Figure - 5.2.1 Algorithm for the modification in spray and wait protocol. ........................................... 87

Figure - 5.3.1 Delivery Probability vs. No. of Message copies graph for modify spray and wait

protocols with compare to existing binary spray and wait protocol. .................................................... 89

xviii

Figure - 5.3.2 Overhead Ratio vs. No. of Message copies graph for modify spray and wait protocols

with compare to existing binary spray and wait protocol. .................................................................... 90

Figure - 5.3.3 Comparison of Delivery probability for different routing protocol with different buffer

size and different mobility movement model. ...................................................................................... 91

Figure - 5.3.4 Comparison of overhead ratio for different routing protocol with different buffer size

and different mobility movement model. .............................................................................................. 92

Figure - 5.3.5 Comparison of Buffer time for different routing protocol with different buffer size and

different mobility movement model. .................................................................................................... 93

Figure - 6.1.1 Comparison of Delivery Probability for Modified SW, Binary SW and SW Normal for

varying number of copies of message and buffer size 2. ...................................................................... 95


varying number of copies of message and Buffer size 5. ..................................................................... 95


varying number of copies of message and Buffer size 10. ................................................................... 96



Figure - 6.2.1 Comparison of Buffer time for Modified SW, Binary SW and SW Normal for varying

number of copies of message and Buffer size 2. ................................................................................... 97


number of copies of message and Buffer size 5. ................................................................................... 98


number of copies of message and Buffer size 10. ................................................................................. 98


number of copies of message and Buffer size 20. ................................................................................. 99

Figure - 6.3.1 Comparison of Overhead Ratio for Modified SW, Binary SW and SW Normal for





varying number of copies of message and Buffer size 10. ................................................................. 101


varying number of copies of message and Buffer size 20. ................................................................. 101

xix

List of Table Table - 3.1.1 Traffic Analysis Data of Surat City. .............................................................................. 47

Table - 3.3.1.1 Configuration Details of Several Standard Interfaces. ................................................. 57

Table – 3.3.2.1 Configuration Detail for the group of Car or Four wheeler. ........................................ 58

Table – 3.3.2.2 Configuration Detail for the Group of Auto Rickshaw. ............................................... 58

Table – 3.3.2.3 Configuration Detail for the Group of City Bus. ......................................................... 59

Table – 3.3.2.4 Configuration Detail for the Group of BRTS Bus. ...................................................... 60

Table - 4.5.1 Delivery probability vs. Transmission data rate resultant data ........................................ 75

Table - 4.5.2 Overhead ratio vs. Transmission data rate resultant data. ............................................... 76

Table - 4.6.1 Delivery Probability vs. No. of copies resultant data for Spray and wait protocol in

normal mode. ........................................................................................................................................ 77

Table - 4.6.2 Delivery Probability vs. No. of copies resultant data for Spray and Wait protocol in

binary mode. ......................................................................................................................................... 78

Table - 4.6.3 Overhead ratio vs. No. of copies resultant data for Spray and Wait protocol in normal

mode ...................................................................................................................................................... 80

Table - 4.6.4 Overhead ratio vs. No. of copies resultant data for Spray and Wait protocol in binary

mode ...................................................................................................................................................... 81

Table - 4.7.1 Delivery Probability vs. No. of Nodes resultant data in Node variation environment .... 82

Table - 4.7.2 Overhead Ratio vs. No. of Nodes resultant data in Node variation environment ............ 83

Table - 4.8.1 Delivery Probability vs. Message Traffic resultant data in Traffic variation environment

.............................................................................................................................................................. 84

Table - 4.8.2 Overhead Ratio vs. Message Traffic resultant data in Traffic variation environment ..... 85

Table - 5.3.1 Delivery Probability vs. No. of Nodes resultant data for modify spray and wait protocols

with compare to existing binary spray and wait protocol ..................................................................... 89

Table - 5.3.2 Overhead Ratio vs. No. of Nodes resultant data for modify spray and wait protocols with

compare to existing binary spray and wait protocol ............................................................................. 91

INTRODUCTION

1

Chapter 1

INTRODUCTION

1.1 Introduction

In recent scenario, IEEE 802.11 [1] has emerged as the most imperative solution for wireless

Internet access. It is confirmed by relatively large number of Wi-Fi hotspots in public domains

and proliferation of Wi-Fi enabled cellular handsets and portable devices [2, 3], together with

the constant progress in protocol modification and optimization. More than 85% of Internet

traffic [4] (including the most popular applications like Web (HTTP), File Transfer (FTP),

email (SMTP), etc.) uses Transmission Control Protocol (TCP) [5] at transport layer for reliable

data transfer [6], which has successfully ensured stable and robust network operations over

wired networks. Apparently, the wireless networks must also use TCP for extending similar

Internet services [7, 8]. However, there are several performance issues when the conventional

TCP is employed in the Internet to operate over a network comprising of IEEE 802.11 wireless

links. Unlike wired links, these links are susceptible to channel noise and many a times become

unavailable because of contention and channel fading [9-10]. This leads to frequent

transmission losses and unpredictable delay variations.

In the recent wireless technologies, the link recovery mechanism is unable to shield TCP

completely from transmission losses [11]. The performance issue arises when TCP

misinterprets wireless transmission losses as a congestion indicator and attempts loss recovery

using retransmissions at the reduced rate as per the convention [12]. This restricts TCP from

immediate utilization of the available bandwidth, so as to achieve upper limit for throughput

[13]. Several TCP schemes are proposed in literature [9, 14-16] to avoid inappropriate

reduction in the size of congestion control parameters at the sender (i.e. congestion window

(cwnd) and slow start threshold (ssthresh)) and hence the sending rate, in response to the

wireless packet loss. Besides, a TCP flow may encounter the transitory delay variations, mostly

TCP Performance Issues

2

due to link retransmissions in an Infrastructure WLAN [17]. These delay variations reflect into

Round Trip Time (RTT) estimate and are inappropriately correlated with the network

congestion [18-19]. Since, the TCP’s throughput is limited by the growth in cwnd per RTT

[20], the efficiency of the well-known TCP schemes largely depends upon the correct RTT

estimation, in addition to the size of cwnd in service [21].

In absence of any guaranteed approach for discrimination, the non-congestion losses and delays

render the protocol incapable of utilizing the available network bandwidth to its functioning

capacity. Considering the wide-spread use of wireless Internet services, it is vital for TCP to

offer identical application performance irrespective of the communication technology in use.

The above demand for additional efforts in designing of a certain TCP variant that could

gracefully provide an appropriate response to the packet losses and delay variations over

wireless networks in general and over the WLAN environment in particular.

1.2 TCP Performance Issues

Latency is an important parameter, when designing and evaluating TCP mechanisms for loss

recovery and congestion control [32]. Metric that is frequently used to capture network

dormancy is RTT [32]. Abstractly, the RTT represents the interval between the sending of a

packet and the receipt of its acknowledgement. The end-to-end RTT estimation at TCP sender

mainly includes packet queuing delay, transmission time, and propagation delay over various

links [13] and it is believed that any variation to it correctly deduces congestion in the end-to-

end network path.

As described in previous section, the diverse characteristics of wireless network may also cause

RTT variations, in addition to those related to the network congestion. In absence of any

sophisticated approach, TCP inappropriately relates the resultant RTT variations to the network

congestion and trigger incorrect response. The impact of false RTT on TCP’s efficiency for

bandwidth utilization is summarized as follows:

i) It leads to incorrect estimate for BDP of the end to end path. When the estimated

BDP of the path increases, TCP sender opens up a large size of cwnd in order to

maintain high utilization of bandwidth, resulting into buffer overflows due to false

congestion estimation. On the other hand, if the estimated BDP of the path

INTRODUCTION

3

decreases, the TCP sender waste network bandwidth due to inferior size of cwnd in

service [30].

ii) The delay variations translate to acknowledgement compression (ack-compression)

and give rise to multiple losses and associated retransmissions, resulting into further

back-offs and timeouts [33-34].

iii) The TCP sender sacrifices network utilization due to diminished growth in sending

rate (ack-clocking), particularly when the increase in delay for TCP

acknowledgement arrival (ack-arrival) is not linked to the network congestion [35].

This restricts the upper bound for end-to-end TCP performance to a lower value in

an erroneous environment [13].

iv) The additional delay in ack-arrival may give birth to futile TCP retransmissions for

the packets those are merely delayed but not lost [36]. TCP response to false packet

loss detection is referred as spurious TCP response. Consequently, sender attempts

unwanted retransmissions and unnecessarily consumes larger portion of bandwidth

[34], which is a scarce resource in wireless network.

v) The route failures may lead to packet-reordering [29]. With persistent and

substantial packet-reordering, TCP spuriously retransmits segments and waste

network bandwidth.

The TCP sender determines a packet loss either on arrival of 3 Duplicate Acknowledgements

(DupAcks) or on expiration of a Retransmission TimeOut (RTO) [37], and provides reliability

by retransmitting lost packets [14]. Based on its primary design assumptions, TCP believes the

packet loss as a sign of network congestion and hence it attempts loss recovery at reduced rate

by limiting the size of cwnd. It also revises its estimate of usable network bandwidth, i.e.

ssthresh. Unfortunately, when packet is lost in the network for reasons other than congestion

(such packet loss is mentioned as non-congestion packet loss), these measures result in an

unnecessary reduction in end-to-end throughput as follows.

i) TCP will take at least one RTT for the source to learn whether a congestion state is

released, and more time will be taken by the TCP source to restore its normal cwnd.

In both cases, the network bandwidth is wasted. In fact, immediate loss detection

and quick network utilization to its usable capacity are desired for TCP´s efficiency

in wireless networks.

Need of Delay Tolerant Network and Vehicular Delay Tolerant Network

4

ii) High BER, route failures and network partitioning may result in to loss of either

TCP retransmissions or TCP acknowledgements (DupAcks or a new TCP

acknowledgement (TCP-ack)), leading to RTO at sender [14]. The RTOs caused by

non-congestion events have been reported as one of the major factors for TCP

performance degradation in wireless networks due to several reasons;

The rate probing using the minimum size of cwnd as a consequence, leads to severe inefficiency

in networks with large RTT [38][39].

The uncorrelated reduction in ssthresh cause quick termination of slow start phase and sender

prematurely enters into congestion avoidance, leading to inferior network utilization [40].

Loss recovery after RTO forces TCP sender to remain inactive for prolonged duration in

absence of congestion [34].

To sum up, TCP’s reaction to both; false RTT estimate and non-congestion packet loss, is

inappropriate and greatly decreases the end-to-end throughput by lowering the effective

sending rate. A considerable amount of research work has been done in last two decades for

improving TCP performance in terms of end-to-end bandwidth utilization over a wireless

network in general and WLAN in particular.

1.3 Need of Delay Tolerant Network and Vehicular Delay Tolerant

Network

These networks are introduced due to following characteristics that conventional internet

routing protocols (TCP/IP) fail to work.

Absence of Connectivity: Suppose that, there is no direct end-to-end path between two nodes

(i.e. partitioned network), then communication cannot possible using the TCP/IP protocols.

Hence Delay-Tolerant Networks (DTNs) derives very useful by allowing transfer in such

condition.

Irregular transfer Delays: variable and asymmetric delays in transfer of message bundles

cause the TCP/IP protocol to work incorrectly. Transmission delay between nodes contains

queuing delay at each node that depend on return of acknowledgement. This can be overcome

using DTNs.

INTRODUCTION

5

Unequal Bidirectional Data Rates: if asymmetries of bidirectional data rate are moderate then

conventional protocols can work. But if asymmetries are large, they cannot work easily and

properly.

These challenged networks interrupt the assumptions of the Internet and hence TCP/IP

protocols cannot work efficiently here. That’s why DTNs are introduced because they allow

communication even in absence of end-to-end connectivity. DTNs make possible transfer of

data with storage of message bundles in node buffer by using store-carry-and forward (SCF)

paradigm.

All-time and unlimited connectivity to the Internet seems to be fairly common for a great

number of mobile and fixed devices. However, the truth is that tireless connectivity is not the

rule everywhere or even in certain environments not unavoidably obligatory. Thus, further

research and technical explanations are needed in order to overawe the lack of connectivity to

enable the communications between nodes and applications in troublesome circumstances.

DTNs are networks that enable communication where connectivity issues like scarce and

sporadic connectivity, long and variable delay, high latency, high error rates, highly

asymmetric data rate, and even no end-to-end connectivity exist.

Vehicular networks have attracted much research consideration in recent years due to a wide-

range of potential applications. Road safety, traffic monitoring, driving assistance,

entertainment, and delivering connectivity to rural/remote communities or catastrophe-hit areas

are just a few examples of the many applications planned for these networks.

Routing in vehicular networks presents a particularly challenging problem due to the unique

features of these networks. In specific, they have a highly dynamic topology, variable node

density, and are characterized by short contact durations. Limited transmission ranges, radio

obstacles, and intrusions, make these networks prone to sporadic connectivity, and significant

loss rates. Because of these issues, vehicular networks are prone to frequent partition (or

disconnection), which makes the use of conventional ad hoc routing protocols designed for

connected networks inadequate. These single characteristics motivate the use of an

opportunistic routing model known as the SCF paradigm in the context of DTN. The idea

behind SCF is to buffer and forward messages (called bundles) hop-by-hop by intermediate

nodes until reaching its destination. Data communication is made possible by mobile nodes

that physically carry data across the network partitions.

Need of Delay Tolerant Network and Vehicular Delay Tolerant Network

6

Researchers have more and more been interested in spread over DTN techniques to vehicular

networks. These networks are usually called vehicular delay-tolerant networks (VDTNs).

VDTN network architecture follows a control and data plane departure principle and employs

a SCF operation to achieve reliable transportations of data in vehicular environments. Various

SCF routing protocols that have been proposed over the years for DTN-based networks can be

applied in VDTNs. Most of these protocols use data on node contacts, location, or movement

and can be secret in two categories as single-copy or multiple-copy depending on whether they

allow data replication within the network.

Vehicular networks have also been projected to implement fleeting networks to benefit

developing societies and tragedy recapture networks. As an example, consider a web-based

telematics application in a vehicle, where the driver wants to receive relevant information when

entering a hilly region. Is there snow or other adverse weather conditions? Where is the

cheapest nearby filling station? If there was good cellular network coverage, the telematics

device in the vehicle could send a request to some server. A typical request would require one

round-trip time (RTT) to resolve a server name to an address, another RTT to establish a

Transmission Control Protocol (TCP) connection, another RTT to send an Hypertext Transfer

Protocol (HTTP) request, and when the answer was received and interpreted, additional

requests would be sent to retrieve additional necessary objects requiring several RTTs and

some transfer time. Then the connection could be closed, taking an additional RTT. If the

network connectivity is sporadic, such sequence of protocol communications may never

complete successfully. A solution might be pushing together a request message to resolve the

address and get all the parts of the answer. This bundle would be sent connectionless, solving

the RTT problem to a single RTT. But then there is the problem of finding a route for end-to-

end data transfer. If there is no network infrastructure available, the vehicle has to carry the

message until there is a contact opportunity. These contacts may be with other vehicles or

infrastructure nodes. If one of them has the answer to the initial request, the problem is solved.

If it does not, it might be worth checking if a path can be established through this vehicle taking

some hops to the destination. But if the vehicle density is low, no end-to-end path will be

available. So, there is a dilemma: should the bundle be transferred to this vehicle, or kept

waiting for a better contact opportunity? An alternative that increases the delivery probability

and decreases the delay is to transfer the bundle and keep a copy. So, there is a bundle

replication that spends transmission and storage resources. This replication can be repeated

again and again with the same costs and possible benefits, that tend to decrease, so at least an

INTRODUCTION

7

expiration time should exist to delete the bundle copies after some time. When the bundle

reaches the destination, an answer bundle is created and the process starts again to send it back.

The store-and-forward networking paradigm that evolved to a packet switching paradigm has

an alternative that is a store, carry and forward paradigm, where bundles may also be carried

by network nodes from a place to another, increasing communications efficiency

1.4 Need of Vehicular Ad-hoc Network (VANET)

Vehicular Ad hoc Networks (VANETs) have been a significant research topic for many years

[41]. It is an allowance of Mobile Ad hoc Networks (MANETs) to vehicle systems, crossing

to planes, trains, boats, automobiles and robots.

MANETs have a set of qualities and necessities:

1) Self-organization: a MANET does not depend on a prior structure but, rather creates one

within the wireless network itself; the nodes are both router and terminal;

2) Mobility: nodes move and conventions have to adapt to this;

3) Multi hopping: certain nodes can be reached only by hopping over other nodes;

4) Energy upkeep: nodes are typically small devices with a limited power supply;

5) Scalability: applications can grow at any moment, increasing difficulty; and

6) Security: due to their wireless nature, security is complex and a major issue.

VANETs have special characteristics:

1) Foreseeable mobility: movements are not accidental, since vehicles have to stay on the road,

for example; Bike, Bus, Auto.

2) High mobility: the network topology changes rapidly because of vehicle speed;

3) Variable topology in time and place: the network topology evolves depending on time (e.g.,

traffic jams) and location (urban, rural);

4) Large scale: all vehicles are potential nodes;

5) Partitioned networks: the hop range in a wireless car-to-car network is about 1000 m,

limiting the communication range of vehicles;

Need of Vehicular Ad-hoc Network (VANET)

8

6) No significant power of calculation restraints: a vehicle can generate sufficient power. An

exception is for stationary nodes, which may be battery operated.

The main difference between VANETs and VDTNs is that VANETs assume that end-to-end

connection occurs through some path, while VDTNs do not. So, VANETs notions are more

appropriate for dense networks, while VDTNs accept also sparse networks through its store-

carry-forward paradigm.

VDTNs extend VANETs with DTN competences to support long disturbances in network

connectivity. The DTN concepts are useful as vehicular networks are characterized by scarce

broadcast opportunities and intermittent connectivity, particularly in rural or mountainous

areas. A recent study shows that the duration of contacts between cars using IEEE 802.11g

crossing at 20 Km/h is about 40 s, at 40 Km/h is about 15s and at 60 Km/h is about 11 s. If

TCP is used at60 Km/h, the good put is very low (average of 80 KB) and in 4 out of 10

experiments no data was transferred at all. UDP gives better results, with about 2 MB

transferred in a contact at 60 Km/h. Most of the problems in vehicular networks arise from the

mobility and speed of vehicles that are responsible for a highly dynamic network topology and

short contact durations. Limited transmission ranges, radio obstacles due to physical factors

(e.g., buildings, tunnels, terrain and vegetation), and intrusions (i.e., high congestion channels

caused by high density of nodes), lead to disruption, intermittent connectivity, and significant

loss rates. All these conditions make vehicular networks subject to frequent

fragmentation/partition (i.e., end to-end connectivity may not exist), resultant in small effective

network diameter. Additionally, vehicular networks have the potential to grow to a large-scale,

and its node density, which is pretentious by location and time, can be highly flexible. For

example, a vehicular network can be categorized as being dense in a traffic jam, where as in

suburban traffic it can be sparse. In fact, in rural areas, the network can be extremely sparse.

For all these scenarios, DTN mechanisms provide a significant advantage. This leads us to find

a solution for appropriate routing protocol in VDTN. The routing protocols used in DTN are

facing problems regarding delivery of data efficiently.

The estimated number of deaths is about 1.5 million people yearly worldwide and of injuries

are about fifty times of the previous number due to vehicle traffic accidents, without forgetting

the traffic congestion that makes a huge waste of time and fuel. With the developments in

wireless communications technology, the concept of VANETs has taken the consideration all

over the world. Such network is expected to be one of the most valuable technology for

INTRODUCTION

9

improving efficiency and safety of the future transportations [42]. Thus, several ongoing

research projects supported by industry, governments and academia, have established standards

for VANETs.

VANET is a Vehicle to Vehicle (Inter-vehicle communication-IVC) and Roadside to Vehicle

(RVC) communication system. The technology in VANET integrates WLAN/cellular and Ad-

hoc networks to achieve the continuous connectivity. The ad-hoc network is put forth with the

novel objectives of providing safety and comfort related services to vehicle users. Collision

warning, traffic congestion alarm, lane-change warning, road blockade alarm (due to the

construction work etc.) are among the major safety related services, vehicle users are equipped

with Internet and Multimedia connectivity. The major research challenges in the area lies in

design of routing protocol, data sharing, security and privacy, network formation etc.

1.5 VDTN Routing Problems

Though the connectivity of nodes is not constantly maintained, it is still desirable to allow

message between nodes. Therefore, it is necessary to provide a routing protocol which tries to

route packets during the times the link is available among the nodes. But this cannot be done

by standard routing algorithms which accept that the network is connected most of the time.

In a typical network, since the nodes are connected most of the time, the routing protocol

forwards the packets in a simple way. The cost of links between nodes are mostly known or

easily estimated so that the routing protocol computes the best path to the terminus in terms of

cost and tries to send the packets over this path. Furthermore, the packet is only sent to a single

node because the reliability of paths is assumed relatively high and mostly the packets are

successfully delivered. However, in VDTN like networks, routing becomes challenging

because the nodes are mobile and connectivity is rarely maintained.

The temporary network connectivity needs to be of primary concern in the design of routing

algorithms for VDTNs. Therefore, routing of the packets is based on SCF paradigm. That is,

when a node receives a message but if there is no path to the destination or even a connection

to any other node, the message should be buffered in this current node and the upcoming

opportunities to meet other nodes should be waited. Furthermore, even a node meets with

another node, it should carefully decide on whether to forward its message to that node. It is

obvious that to forward a message to multiple nodes increases the delivery probability of a

Motivation of Research

10

message. However, this may not be the right choice because it can cause a huge messaging

overhead in the network which then causes redundant energy and resource consumption. On

the other hand, sending a copy of the message to a few number of nodes uses the network

resources efficiently but the message delivery probability becomes lower and the delivery delay

gets longer. Consequently, it is clearly seen that there is a tradeoff between the message

delivery ratio and the energy consumption and delivery delay in the network. Hence, while

designing a routing protocol for delay tolerant networks, the important consideration is the

delivery of data by shortest path and quick delivery.

1.6 Motivation of Research

VDTN has many challenges compared to other wireless networks. VDTNs are scarce and

segregated, because of less density and distance between two nodes is usually large. Hence

there are very less and rare chances of communication for network nodes. This results a less

communication opportunities and variable transfer delays. As considering, highly dynamic

mobility of vehicles, VDTNs have small contact intervals and speedy change in topology. The

vehicles mobility pattern has direct effects on inter contact time deliveries. And there are many

other features like, restricted communication range, physical hurdles, contribute to

discontinuous connectivity and error rates normally detected in these types of networks. All

these features control the number of message bundles transferred between nodes during

contact.

To allow bundles transfer in such surroundings, long-standing storage of message bundles is

required with efficient routing techniques. VDTNs make possible transfer of data with storage

of message bundles in node buffer by using SCF paradigm. Routing techniques aim to increase

consistency and decrease the dormancy, by increased storage buffer size on nodes and bundle

transfer overhead. However, VDTNs have limited resources, so, routing techniques results

quick exhaustion of buffer space and bandwidth.

Today we all use internet during travelling in vehicles, we mostly experience an interrupted

network connectivity due to continue changes in speed of vehicles and numbers of the reasons

as discussed above.

INTRODUCTION

11

1.7 Definition of Problem

In VANET routing protocols like AODV (Ad-hoc On Demand Distance Vector), DSDV

(Destination Sequenced Distance Vector) and DSR (Dynamic Source Routing) are failed to

serve in DTN. Researchers have performed experiments to use these protocols, but were not

successful. For VANET kind of networks for better performance of network, we may use DTN

protocols.

We must place a routing protocol in presence which serve our main goal to provide upgraded

wireless network efficiency. The proposed algorithm must be proficient to overcome the issues

of routing faced by VANET protocols.

1.8 Objective and Scope of Work

1) To implement the existing DTN routing protocols in VDTN. Using different movement

model.

2) To simulate all routing protocols in different scenarios. For this we have used maps of

different cities.

3) Try to find best performing protocol in existing routing protocol and to enhance its

performance in terms of improvement of network efficiency.

1.9 Research Contribution

The thesis studies an extensive literature on VDTN routing protocols and addresses the

unresolved problem of routing in VDTN. This thesis considers the following significant

contributions to achieve the objectives

1) In-depth evaluation of the behaviour of different routing protocols techniques in

different scenarios for VDTN.

2) Development of a routing protocol that will lead to have better performance in any

network condition.

3) To fulfil above goal study of Spray and Wait routing protocol. And to modify Spray

and Wait protocol such that it provide enrich performance.

Composition of Thesis

12

4) Testing of the modified SNW is done on the basis of different scenarios of networks

for two different city maps. To do so, different movement models are used. Performance of the

modification is tested for different buffer size and different number of nodes in the network.

1.10 Composition of Thesis

Rest of the chapters are organised as follow.

Chapter 2 focuses on the literature survey of the existing MANET and the VDTN routing

protocols. Why MANET routing protocols are not used in VDTN.

Chapter 3 discusses simulation methodology. We have discussed the traffic pattern of Surat

city. We have focused on the need of VDTN in Surat city area. Overview of THE ONE

simulator is also given in the same chapter.

Chapter 4 presents simulation results and a modification in Spray and Wait routing protocol

for VDTNs. It shows the code modification in existing protocol.

Chapter 5 describes the performance of proposed modification for Surat city and Chennai city

map. It integrates Chapter 3 and Chapter 4 and shows that proposed scheme is performing

better.

Chapter 6 concludes the thesis and shows the future modifications and the future scope in the

field.

1.11 SUMMARY

In this chapter researcher has given a brief introduction of different network protocols.

Researcher has focused on recent trends in the networking field. We have found that present

protocols are having capability to perform better. But in MANET some routing protocols are

having issues to give proper performance. DTN is upcoming technology, which will help the

data communication for temporary network. Researcher has also given a brief introduction to

VANET. For VANET researcher has suggested DTN protocols. Brief of the upcoming chapter

is also given in this chapter.

LITRATURE REVIEW

13

Chapter 2

LITRATURE REVIEW

The internet has been a great success at interconnecting communication devices across the

globe. It has done this by using a homogeneous set of communication protocols, called the

TCP/IP protocol suite. All devices on the hundreds of thousands of subnets that make up the

internet use these protocols for routing data and insuring the reliability of the message

exchanges. This chapter mainly covers the in-depth explanation of protocol layer

architecture of conventional network, packet encapsulation and packet switching

methodology in conventional network and need of Delay Tolerant Networks (DTN) concept

2.1 Protocol Layers in Conventional Internet

Messages are moved through the Internet by protocol layers, a set of functions performed by

network nodes on data communicated between nodes. Computers or other communicating

devices that are the sources or destinations of messages usually implement at least five

protocol layers, which perform the following functions:

i) Application Layer: Generates or consumes user data (messages).

ii) Transport Layer: Source to destination (end to end) segmentation of messages in

to message pieces and reassembly in to complete messages, with error control

and flow control. On the internet, the Transmission Control Protocol (TCP) is

used.

iii) Network Layer: Source to destination routing of addressed message pieces

through intermediate nodes, with fragmentation and reassembly if required. On

the Internet, the Internet Protocol (IP) is used.

iv) Link Layer: ink to link transmission and reception of addressed message pieces,

with error control. Common link layer protocols include Ethernet for Local Area

Packet Encapsulation in Conventional Network

14

Networks (LANs) and Point to Point Protocol (PPP) for dial up modems or very

high speed links.

v) Physical Layer: Link to link transmission and reception of bit streams. Common

physical media include category 5 (cat5) cables, unshielded twisted pair (UTP)

telephone cable, coaxial cable, fiber optic cable, and RF.

Figure – 2.1.1 Protocol Layers mechanism for Conventional Internet [43].

Figure – 2.1.1 shows the basic protocol layers mechanism for today’s internet. As shown in

Figure.-2.1.1, each hop on a path can use a different link layer and physical layer technology,

but the IP protocols runs on all nodes and the TCP protocol runs only on source and

destination end points. Generally routers implement only lower three protocol layers.

However, routers also implement the higher layers for the routing table maintenance and

other management purpose. Several other internet protocols and applications are also used

to provide routing path discovery, path selection, name resolution and error recovery

services.

2.2 Packet Encapsulation in Conventional Network

The term packet is applied to the objects actually sent over the physical links of a network.

They are often called IP packets because the IP protocol is the only protocol which is used

by all the nodes on the path for directing the packets node by node from source to destination

along their entire path.

Packets consist of a hierarchy of data-object encapsulations that are performed by the

protocols layers. During transmission, higher level data and its header are enclosed in a lower

layer data object, which is given its own header. The headers are used by their respective

LITRATURE REVIEW

15

protocol layers to control the source as user data moves down the layer structure from source

application to physical layer. Headers are removed at the destination end as data moves up

the layer structure to the destination application.

TCP breaks user data into pieces called segments. IP encapsulates the TCP segments into

datagrams, and it may break the segments into pieces called fragments. The link layer

protocol encapsulates IP datagrams into frames. The physical layer then transmits and

receives a sequence of frames as a continuous bit stream. The layer by layer data

encapsulation process is shown in Figure – 2.2.1

Figure – 2.2.1 Layer by Layer Data Encapsulation Process in Conventional Internet [43].

2.3 Conventional Protocol in Conventional Internet

The TCP protocol is said to be conversational (interactive), because a complete one way

message involves many source to destination signaling round trips:

i) Set Up : A three way “ HELLO ” handshake/

ii) Segment Transfer and Acknowledgement: Each TCP segment sent by the source

is acknowledged by the destination.

Conventional Protocol in Conventional Internet

16

iii) Take Down: A four way “ GOOD BYE ” handshake.

The complete conversational process is shown in the Figure – 2.3.1

Figure – 2.3.1 A Complete Conversational Process in Conventional Internet [43].

The use of positive or negative acknowledgements to control retransmission of lost or

corrupt segments is called as Automatic Repeat request (ARQ) protocol.

LITRATURE REVIEW

17

2.4 Mutual Information Based Approaches

Communication on the internet is based on packet switching. Packets are pieces of a

complete block of user data that travel independently from source to destination through a

network of links connected by routers. The source, destination, and routers are collectively

called nodes.

Figure – 2.4.1 Packet Switching Strategy in Conventional Internet [9].

Each packet that makes up a message can take a different path through the network. If one

link is disconnected, packets take another link. Packets contain both application-program

user data and a header. The header contains a destination address and other information that

determines how the packet is switched from one router to another. The packets in a given

message may arrive out of order, but the destination’s transport mechanism reassembles

them incorrect order.

The usability of the internet depends on some important assumptions:

i) Continuous, Bidirectional End to End Path: A continuously available

bidirectional connection between source and destination to support end to end

interaction.

ii) Short Round Trips: Small and relatively consistent network delay in sending data

packets and receiving the corresponding acknowledgement packets.

iii) Symmetric Data Rates: Relatively consistent data rates in both directions

between source and destination.

Need of Delay Tolerant Network (DTN)

18

Low Error Rates: Relatively little loss or corruption of data on each link

2.5 Need of Delay Tolerant Network (DTN)

In general, Wireless Mobile Ad-hoc Network is a network composed of an autonomous

collection of mobile users that communicate wirelessly, without the need to use any existing

network infrastructure such as base stations, wires or fixed routers. The term ad-hoc comes

from that the fact that the network is formed dynamically as the need arises and mobile

comes from the fact that the nodes can move freely. Since no fixed infrastructure are assumed

to be used and the nodes making up the network are changing continuously as nodes ether

and leave the network, MANETs need to be decentralized. All network activities are

performed by the nodes themselves, e.g. detecting nodes to communicate with and routing

and forwarding messages through the network to other nodes. This is a change from the more

centralized and fixed composition of normal networks using infrastructure.

Generally, traditional MANETs operate under several assumptions which are explained in

previous topic. But these assumptions do not hold in many wireless applications, because

the environment is uncontrolled and nodes are truly autonomous. Wireless connections

between nodes are usually unstable with high error rates resulting in intermittent

connectivity between nodes which in turn leads to partitioning of the network and its turn to

large delays. Such situations are exhibits in Figure – 2.5.1

Figure – 2.5.1 Such Situations where Delay Tolerant Network is required [9].

As shown in Figure – 2.5.1, such evolving and potential networks are characterized by:

LITRATURE REVIEW

19

i) Intermittent Connectivity: If there is no end to end path between source and

destination-called network partitioning-end to end communication using the

TCP/IP protocols does not work. Other protocols are required.

ii) Long or Variable Delay: in addition to intermittent connectivity, long

propagation delays between nodes and variable queuing delays at nodes

contribute to end to end path delays that can defeat internet protocols and

applications that rely on quick return of acknowledgements or data.

iii) Asymmetric Data Rates: the internet supports moderate asymmetries of

bidirectional data rate for users with cable TV or asymmetric DSL access. But if

asymmetries are large, they defeat conversational protocols.

iv) High Error Rates: bit errors on links require correction or retransmission of the

entire packet. For a given link error rate, fewer retransmissions are needed for

hop by hop than for end to end retransmission.

A DTN is a network of regional networks. It is an overly on top of regional networks,

including the internet.

2.6 Bundle Layer

The key part in DTN is the bundling protocol described by Delay Tolerant Network

Architecture [10]. The bundling protocol allows hosts that normally cannot communicate

with each other, due to network partitioning or because they do not have the same protocol

set, to be able to communicate. This is done using message switching, which means that only

adjacent nodes needs to share the same protocol set, and multiple protocol set are only

required in nodes bridging protocol borders.

The protocol uses existing transport protocols for data transmission but also acts as a

transport protocol to applications, making it noncompliant with the traditional layer model

for internet communication. Instead of categorizing the building protocol as a transport layer

protocol, a new layer, called ‘Bundle Layer’, is added between the application and transport

layers, which are shown in Figure – 2.6.1

The DTN architecture implements store and forward message switching by overlying a new

protocol layer-called the bundle layer-on top of heterogeneous region specific lower layers.

Bundles

20

The bundle layer ties together the region specific lower layers so that application programs

can communicate across multiple regions [43].

The bundle layer stores and forwards entire bundles between nodes. A single bundle layer

protocol is used across all networks that make up a DTN. By contrast, the layers below the

bundle layer (the transport layer and below) are chosen for their appropriateness to the

communication environment of each region. Fig. – 2.6.1 illustrate the bundling overly (top)

and compare internet protocol layers with DTN protocol layers (bottom).

Figure – 2.6.1 Comparisons of Internet Protocol Layers and DTN Protocol Layers [43].

2.6.1 Bundles

As with all information transmission the data must be packaged before transmission. In DTN

this entity is called a bundle. The bundle is used to attach additional information to the

payload, needed by nodes to correctly transfer the data. In addition to the source and

destination fields, fields for delivery options and handling can be included. Generally,

bundles are also called messages as the DTN supports message switching terminology

LITRATURE REVIEW

21

2.6.2 Bundle Structure

Each bindle consist of one or more headers, stacked after each other, as illustrated in Figure

– 2.6.2.1 The first one, the primary header contains delivery options and references to

address stored in a succeeding dictionary header. Other possible headers can follow in a non-

specific order, with the only exception that the payload header is placed at the very end.

Payload is last to allow for dynamic fragmentation in case of a link failure during

transmission, which means that in case of a link drop out at the end of a transmission only

the last part needs to be resent. This can be used to always maximize link usage. Because of

this, the payload header has no information about any trailing header, whereas other headers

include this next header information.

Figure – 2.6.2.1 Bundle Structure of DTN

2.6.3 Administrative Payload

A node sending a bundle can request reports of what happens to the bundle during its journey

to the destination. These so called status report are placed in the payload of a new bundle.

As a different payload type, and sent to a specified report to address.

2.6.4 Bundles and Bundle Encapsulation

Bundles consist of three things:

DTN Nodes

22

(1) A source-application’s user data.

(2) Control information, provided by the source application for the destination

application, describing how to process, store, dispose of, and otherwise handle the

user data.

A bundle header, inserted by the bundle layer. Like application-program user data, bundles

can be arbitrarily long.

Figure – 2.6.4.1 Bundle Encapsulation in Delay Tolerant Network (DTN) [43].

Bundles extend the hierarchy of data object encapsulation performed by the internet

protocols. Figure – 2.6.4.1 show how bundle layer encapsulation works in the context of

lower layer TCP/IP protocols. Generally, a bundle layer may break whole bundles (whole

messages) into fragments just as an IP layer may break whole datagrams into fragments. If

bundles are fragmented, the bundle layer at the final destination reassembles them.

2.7 DTN Nodes

In a DTN, A node is an entity with a bundle layer. Figure – 2.7.1 represent the different types

of DTN nodes. A node may be a host, router or gateway acting as a source, destination or

forwarder of bundles [43]:

1) Host: Sends and/or receives bundles, but does not forward them. A host can be a

source or destination of a bundle transfer. The bundle layers of hosts that operate

LITRATURE REVIEW

23

over long delay links require persistent storage in which to queue bundles until

outbound links are available. Hosts may optionally support custody transfers.

2) Router: forward bundles with in a single DTN region and may optionally be a host.

The bundle layers of routers that operate over long delay links require persistent

storage in which to queue bundles until outbound links are available. Routers may

optionally support custody transfers.

3) Gateway: Forwards bundles between two or more DTN regions and may optionally

be a host. The bundle layers of gateways must have persistent storage and support

custody transfers. Gateways provide conversions between the lower layer protocols

of the regions they span.

Figure – 2.7.1 DTN Nodes [43]

2.8 Store and Forward Message Switching

DTN overcome the problems associated with intermittent connectivity, long or variable

delay, asymmetric data rates, and high error rates by using store-and-forward message

switching. This is an old method, used by pony express and postal systems since ancient

times. Whole messages or pieces of such messages are moved from a storage place on one

node to a storage place on another node, along a path that eventually reaches the destination.

Store-and-forwarding methods are also used in today’s voicemail and email systems,

although these systems are not one way relays but rather star relays; both the source and

destination independently contact a central storage device at the centre of the links.

Custody Transfer

24

Figure – 2.8.1 Store-And-Forward Message Strategy in Delay Tolerant Network.

The storage places (such as hard disk) can hold messages indefinitely. They are called

persistent storage, as opposed to very short term storage provided by memory chips. Internet

routers use memory chips to store incoming packets for a few milliseconds while they are

waiting for their next hop routing table lookup and an available outgoing route port.

DTN routers need persistent storage for their queues for one or more of the following

reasons:

1) A communication link to the next hop may be available for a long time.

2) One node in a communication pair may send or receive data much faster or more

reliably than the other node.

3) A message, once transmitted, may need to be retransmitted if an error occurs at an

upstream node or link, or if an upstream node declines acceptance of a forwarded

message.

By moving whole messages in a single transfer, the message switching technique provides

network nodes with immediate knowledge of the size of message, and therefore the

requirements for intermediate storage space and retransmission bandwidth.

2.9 Custody Transfer

DTN support node to node retransmission of lost or corrupt data at both the transport layer

and the bundle layer. However, because no single transport layer protocol operates end to

end across a DTN, end to end reliability can only be implemented at the bundle layer.

The bundle layer supports node to node retransmission by means of custody transfers. Such

transfers are arranged between the bundle layers of successive nodes, at the initial request of

the source application. When the current bundle layer custodian sends a bundle to the next

LITRATURE REVIEW

25

node, it requests a custody transfer and starts a time-to-acknowledge retransmission timer.

If the next hop bundle layer accepts custody, it returns an acknowledgement to the sender.

If no acknowledge is returned before the sender’s time-to-acknowledge expires, the sender

transmits the bundle. The value assigned to the time-to-acknowledge retransmission timer

can either be distributed to nodes with routing information or computed locally, based on

past experience transmitting to a particular node.

A bundle custodian must store a bundle until either (1) another node accepts custody, or (2)

expiration of the bundle’s time-to-live, which is intended to be much longer than a

custodian’s time-to-acknowledge. However, the time-to-acknowledge should be large

enough to give the underlying transport protocols every opportunity to complete reliable

transmission [9]. Figure – 2.9.1 exhibit the custody transfer process in the Delay Tolerant

Network (DTN).

Figure – 2.9.1 Custody Transfer in DTN [43].

Custody transfers do not provide guaranteed end-to-end reliability. This can only be done if

a source requests both custody transfer and return receipt. In that case, the source must retain

a copy of the bundle until receiving a return receipt, and it will retransmit if it does not

receive the return receipt.

Regions and Nodes

26

2.10 Regions and Nodes

A large DTN network can consist of nodes from several different network topologies, each

with a different addressing scheme. The use of different network addressing schemes is

usually a reason why nodes from different networks are unable to communicate.

DTN solves this problem by defining a region part in the endpoint ID, the DTN addressing

scheme. DTN regions are defined in Delay-Tolerant Network Architecture [43] and a region

can be described as a group of nodes in a network, using the same protocol set for

communication.

Since nodes in different regions often use different protocol sets, consequently using

different addressing schemes, only the region part of the endpoint ID is meaningful until the

bundle has arrived somewhere within the destination region, where the other, administrative

part of the endpoint ID can be interpreted correct delivery. The naming scheme used in the

region part of the endpoint ID is similar to the DNS topology, i.e. a tree structure with the

root last.

2.11 Routing in DTN

In DTN, routing is primarily done on the region part of the endpoint ID and then according

to local rules used by each network topology. It is not defined isn detail how routing should

be done in practice; instead this is left for the implementation, since it is not necessarily done

consistently and can depend on network characteristics.

As an aid in defining rules for routing decision, a few different contact types have been

defined:

1) Persistent Contacts: Used between nodes that has a persistent network connection,

e.g. node connecting through a DSL connection.

2) On-demand Contacts: Used by a node that can establish a connection when needed,

for instance using a dial-up connection. It is of course only the node that cans

instantiate the connection that sees it as an on-demand contact.

3) Intermittent-Scheduled Contacts: Used to define nodes that are available for

communication at certain predetermined times, like a low orbit satellite.

LITRATURE REVIEW

27

4) Intermittent-Opportunistic Contacts: Used for irregular connection where no

assumptions are made regarding when it will be available.

5) Predicted Contacts: Used as a hybrid between scheduled and opportunistic contacts

where a possible future connection is predicted based on a mobile node’s current

movement pattern.

Till today so many efficient routing protocols are proposed for the Delay Tolerant Networks.

However it is not possible to classify each of the routing scheme into exactly one of the many

classes. This chapter mainly focuses on classification of DTN routing algorithms which is

decided according to the broadness of the knowledge of the network available at nodes.

Before that, the routing problems in traditional VANET is discussed.

2.12 Routing Problems in Traditional Vehicular Ad-hoc Network

The existing TCP/IP based Internet, operates assuming end-to-end communication using a

concatenation of various data-link layer technologies. The set of rules specifying the

mapping of IP packets into network specific data link layers frames at each router provides

the required level of interoperability. IP protocol still makes a number of key assumptions

regarding the lower layer technologies making seamless IP layer communications smooth.

These are: (i) there is an end to end path between two communicating end systems. (ii) the

round trip time between communicating end systems is not absurdly high and (iii) the end to

end packet loss probability is rather small. Unfortunately, in DTN networks one or more of

the above mentioned assumptions are violated due to mobility, power conservation schedule

or excessive bit error rate. As a result, classic protocols of the TCP/IP protocol stack are not

appropriate for such environments [12].

A key reason why end to end communication is difficult in conventional network is that IP

packet delivery works only when the end to end path is available. In general, according to

classic IP routing mechanism an IP packet is dropped at the intermediate system where no

link to the next hop currently exists. Such design restricts the end to end communication.

2.13 Knowledge Based Classification of DTN Routing Protocol

It has been almost a decade since the initiating talk [44] of Kevin Fall about delay tolerant

networks. The primary focus of researchers studying on DTNs has been routing problem.

Knowledge Based Classification of DTN Routing Protocol

28

Many studies have been performed on how to handle the sporadic connectivity between the

nodes of the DTN and provide a successful and efficient delivery of messages to the

destination. It is possible to classify the DTN routing protocols according to the broadness

of the knowledge of the network available at nodes. In some studies, it is assumed that each

node in the network has exact knowledge of node trajectories, or node meeting times and

durations. Therefore, the messages are routed over predetermined paths deterministically.

But these algorithms which assume the existence of oracles giving future information are

unrealistic because the intermittent connectivity between the mobile nodes in delay tolerant

networks does not allow nodes to have such information. On the other hand there is also

significant number of studies assuming zero knowledge about the aforementioned features

of the nodes. These algorithms either forward the message randomly or use the meeting

history of nodes and forward the message over different paths in a nondeterministic manner

[45].

Based on the knowledge routing in DTNs could be classified as Deterministic Routing and

Stochastic Routing. In deterministic routing the network topology and/or its characteristics

are assumed to be known. Contrarily, for stochastic routing no exact knowledge of topology

is assumed. Figure – 2.13.1 exhibits the knowledge based classification of several Delay

Tolerant Routing protocols.

Figure – 2.13.1 Knowledge Based Classification of DTN Routing Protocols

LITRATURE REVIEW

29

2.13.1 Deterministic Routing

The main idea in computing the optimal route from a source to a destination in deterministic

routing protocols is based on completely knowledge or predictable information about nodes

future mobility patterns and links availability between them. Deterministic routing protocols

could be divided into following four approaches. Most of those are special modification of

well-known algorithms.

2.13.1.1 Oracles Based Routing

Several oracle-based deterministic routing algorithms taking the advantage of predictable

information about network topology and traffic characteristics have been suggested by jain

et al. (2004). Based on the amount of information they need to compute routes, the oracle-

based algorithms are classified into complete knowledge and partial knowledge. Complete

knowledge protocols utilize all information regarding traffic demands, schedules of contacts,

and queuing in the forwarding process. However, in practical applications this knowledge is

partially missing and routing needs to utilize available information. The author in [46]

purposed their routing framework by modifying the Dijkstra's shortest path algorithm

assuming four knowledge oracles: (I) Contact summary oracle provides the knowledge about

aggregated statistics of contacts. (ii) Contact oracle maintains information regarding the

links between two nodes at any given time. (iii) Queuing oracle presenting the queuing

information in each node instantaneously, and (iv) Traffic demand oracle provides the

knowledge about the current and future traffic characteristics. Oracle-based algorithms are

mostly suitable for networks with controlled topology or with existing full or partial

information about that [46][47].

2.13.1.2 Link State Based Routing

Gnawali et al. (2005) presented a modification of link state routing (LSR) protocol for use

in deep-space networks, entitled “positional link-trajectory state” (PLS) protocol. PLS is a

position based routing mechanism that predicts the satellite or other spacecraft’s moving

paths to make routing decision. In the suggested routing protocol, flooding is performed at

first and then the predicted trajectory of nodes. Links availability and their characteristics

such as latency, error and rate through the network and link states are updated. Finally, each

node independently re-computes its own routing table using a modified Dijkstra algorithm

[48].

Stochastic Routing

30

2.13.1.3 Space Time Based Routing

Merugu et al. (2004) suggested a routing framework, which unlike conventional routing

tables using only connectivity information, provides a space-time routing table relying on

information about destination and arrival time of messages. These two metrics are used to

choose the next hop in a route. The underlying reason behind this approach is that in wireless

networks with mobile nodes, the network topology changes with time and choosing the best

route depends not only on destination but also on the topology evolution. The forwarding

table in each intermediate node is a two dimensional matrix composed of destination address

and instances of time when this route has been obtained. The forwarding decision is a

function of both destination and time [49].

2.13.1.4 Tree Based Routing

Handorean et an. (2005) presented a tree based routing algorithm based on the knowledge

about motion and availability patterns of mobile nodes. Depending on how the routing

information is obtained they classified the path selection mechanism into three cases: (i) the

source node initially has complete information about speed and direction of motion of all

other nodes and has the ability to estimate route trees for data delivery to destination nodes.

(ii) The source originally has no information about other nodes motions and each node

exchanges its own information with its neighbours and learns the path to a destination

whenever they meet. The second method is useful in applications where nodes have highly

mobile patterns and obtaining the global knowledge is difficult. (iii) The future trajectory of

nodes is predicted relaying on the past recorded knowledge [50]. The tree based routing

protocol requires maintenance algorithms to somehow keep the tree alive.

2.13.2 Stochastic Routing

When there is no information about nodes mobility patterns obtained via deterministic

predictions or historic information stochastic routing mechanism needs to be used.

Depending on whether nodes dynamically adapt their trajectories or mobility patterns to

improve the routing process, routing protocols based on stochastic techniques could be

classified into passive or active protocols.

LITRATURE REVIEW

31

2.13.2.1 Active Routing Protocols

In this category of routing protocols, moving paths of some nodes are controlled in order to

increase the message delivery probability. In these schemes mobile nodes act as natural

“message carriers” and after picking up and storing the messages from the source node move

toward the destination node to deliver them. Very often the active routing methods are more

complicated and costly in terms or resources that are not related to communications

compared to the passive routing techniques. However, they may drastically improve the

overall performance of system in terms of delay and loss metrics [51]. Active routing

techniques could be implemented in those DTNs where no direct communication

opportunities between end systems are expected by default. E.g. emergency and military

networks. Buses, unmanned aerial vehicles (VAV) or other types of mobile nodes can be

used as ferry nodes in different DTN environments [52].

2.13.2.1.1 Meet and Visit Routing

Burns et al. (2005) suggested the so-called meet and visit strategy for forwarding messages

in structures with mobile source and fixed destination nodes. This scheme actively explores

information about meeting of peer nodes and their visiting locations. The knowledge

regarding meetings and visiting places is stored at each node and used to estimate message

delivery probabilities. Three important assumptions are introduced in the meet and visit

protocol: (i) Nodes have unlimited buffer space. (ii) There is infinite link capacity and (iii)

destination nodes are fixed [53].

2.13.2.1.2 Message Ferrying (MF) Routing

Zhao et al. (2004) described the so-called message ferrying method which uses mobile nodes

with stable mobility patterns as collections and carriers of messages. The ferry nodes could

provide connectivity among nodes in a network, where there are no possibilities for direct

communication between end systems. Because of fixed moving path of ferry nodes, each

node can save information about the ferries' mobility patterns and may adapt its future

trajectory to come into contact with ferry nodes to have sending or receiving messages.

Depending on the entity initiating transactions, two forwarding schemes can be used for

message delivery: node-initiated message ferrying (NIMF) and ferry-initiated message

ferrying (FIMF). According to the first approach the ferry nodes chooses their path using a

predefined mobility pattern known by other nodes. Whenever the nodes want to send

message via the ferries, they need to adjust their trajectories to move towards the ferry nodes.

Stochastic Routing

32

The nodes can be informed about ferries' path using broadcasting messages originated by

ferry nodes or using predefined schedules. In the FIMF, nodes broadcast call-for-service

request whenever they need to send or receive messages. The nearest ferry node responsible

for responding them and moving towards the nodes to pick up the messages [54].

2.13.2.2 Passive Routing Protocols

Protocols falling in to this category assume that the moving path of nodes does not change

in order to dynamically adapt to the routing and forwarding process of messages. The basic

idea of these mechanisms is to combine routing with forwarding by flooding multiple copies

of a message to the network by a source and waiting for successful reception. Obviously, the

more the copies of the message on available links, the more the probability of the message

delivery. As one can see this scheme may provide low delay at the expense of worse resource

utilization. This approach is useful in those networks, where forwarding and storage

resources of nodes mobility.

2.13.2.2.1 Epidemic Routing

Epidemic routing algorithm was the method which firstly introduced by Demers et al. [47]

to synchronize database which use replication mechanism. This algorithm was modified by

Vahdat et al. (2000) and proposed as a flooding-based forwarding algorithm for DTNs. In

the epidemic routing scheme, the node receiving a message, forwards a copy of it to all nodes

it encounters. Thus, the message is spread throughout the network by mobile nodes and

eventually all nodes will have the same data. Although no delivery guarantees are provided,

this algorithm can be seen as the best effort approach to reach the destination. Each message

and its unique identifier are saved in the node's buffer. The list of them is called the summary

vector. Whenever, two adjacent nodes get opportunity to communicate with each other, they

exchange and compare their summary vectors to identify which message they do not have

and subsequently request them. To avoid multiple connections between the same nodes, the

history of recent contacts is maintained in the nodes caches [55].

Assuming sufficient resources such as node buffers and communication bandwidth between

nodes, the epidemic routing protocol finds the optimal path for message delivery to

destinations with the smallest delay. The reason is that the epidemic routing explores all

available communication paths to deliver messages [48] and provides strong redundancy

against node failures [56]. The major disadvantage of epidemic routing is wastage of

resources such as buffer, bandwidth and nodes power due to forwarding of multiple copies

LITRATURE REVIEW

33

of the same message. It causes contentions when resources are limited, leading to dropping

of messages. It is especially useful in those conditions when there are no better algorithms

to deliver messages.

2.13.2.2.2 Spray and Wait Routing

Wasteful resource consumption in the epidemic routing, could be significantly reduced if the

level of distribution is somehow controlled. Spyropoulos et al. (2005) proposed the spray

and wait mechanism to control the level of spreading of messages throughout the network.

Similar to the epidemic routing, the spray and wait protocol assumes no knowledge of

network topology and nodes mobility patterns and simply forwards multiple copies of

received messages using flooding technique. The difference between this protocol and the

epidemic routing scheme is that it only spreads L copies of the message. The authors in [57]

proved that the minimum level of L to get the expected delay for message delivery depends

on the number of nodes in the network and is independent of the network size and the range

of transmission.

The spray and wait method consists of two phases, spray and wait phase. In the spray phase

the source node after forwarding L copies of message to the first L encountered nodes, goes

to wait phase, waiting for delivery confirmation. In the wait phase all nodes that received a

copy of the message wait to meet the destination node directly to deliver data to it. Once data

is delivered confirmation is sent back using the same principle.

To improve the performance of the algorithm Spyropoulos et al. (2005) purposed the binary

spray and wait scheme. This method provides the best results if all the nodes' mobility

patterns in the network are independent and identically distributed with the same probability

distribution. According to the binary spray and wait, the source node creates L copies of the

original message and then, whenever the next node is encountered, hands over half of them

to it and keeping the remained copies. This process is continued with other relay nodes until

only one copy of the message is left. When this happens the source node waits to meet the

destination directly to carry out the direct transmission [57].

2.13.2.2.3 PROPHET Routing

The probabilistic routing protocol using history of encounters and transitivity (PROPHET)

is a probabilistic routing protocol developed by Lindgren et al. (2003). The basic assumption

in the PROPHET is that mobility of nodes is not purely random, but it has a number of

deterministic properties e.g. repeating behaviour. In the PROPHET scheme, it is assumed

Stochastic Routing

34

that the mobile nodes tend to pass through some locations more than others, implying that

passing through previously visited locations is highly probable. As a result, the nodes that

met each other in the past are more likely to meet in the future [58]. The first step in this

method is the estimation of a probabilistic metric called delivery predictability P(a,b). This

metric estimates the probability of the node A to be able to deliver a message to the

destination node B. Similar to epidemic routing, whenever a node comes in to contact with

other nodes in the network, they exchange summary vectors. The difference is that in the

PROPHET method the summary vectors also contain the delivery predictability values for

destination known by each node. Each node further requests messages it does not have and

updates its internal delivery predictability vector to identify which node has greater delivery

predictability to a given destination [58]. The operation of PROPHET protocol could be

classified in two phases: Calculation of delivery predictabilities and forwarding strategies.

2.13.2.2.4 MobySpace Routing

Leguay et al. (2005) suggested a mobility pattern space routing method called MobySpace.

The major principle behind their proposal is that the two nodes with similar trajectories will

meet each other with high probability. According to this method, each node forwards the

received messages to the encountered nodes provided that they have similar mobility

patterns with the destination node. The title of this protocol comes from a virtual Euclidean

space used for taking decision on the message forwarding process. In this virtual space each

nodes is specified using its mobility pattern, called MobyPoint and routing is done towards

nodes having similar MobyPoint with the destination node [59]. Each axis in the MobySpace

defines the possible contact and the distance from each axis presents the communication

probability between nodes. In the MobySpace the closer nodes have higher probability to

communicate with each other , so in the routing process the messages are forwarded toward

the nodes that are as close to the destination node as possible [60].

The MobySpace protocol demonstrates better results whenever nodes' mobility patterns are

fixed. However, two nodes with similar mobility patterns may never communicate if they

are separated in time. In other words, the nodes with similar trajectories could meet each

other provided that is in the same time dimension [52].

LITRATURE REVIEW

35

2.14 Introduction of VANET

In many commercial applications and in road safety systems, vehicular delay-tolerant

networks have been envisioned to be useful. For example, a vehicular ad hoc network

(VANET) can be used to alert drivers of traffic jams ahead, help balance traffic loads, and

reduce travelling time. It can also be used to propagate emergency warnings to drivers behind

the vehicles in an accident in order to prevent compounding on accident that has already

taken place. Transportation safety issues have been addressed in [61] and [62], where

vehicles communicate with each other and with static network nodes such as traffic lights,

bus shelters, and traffic cameras.

The Federal Communications Commission (FCC) has allocated 75 MHz of spectrum for

short-range vehicle-to-vehicle or vehicle-to-roadside communications. IEEE is working on

standard specifications for inter-vehicle communication. In the near future, inter-vehicle

communication will be enabled by communication devices equipped in general vehicles and

form a large-scale VANET.

The cost of a wireless infrastructure is high and may not be possible when such an

infrastructure does not exist or is damaged. Although services can be supported by a wireless

infrastructure, from the service provider point of view, setting up a wireless LAN is very

cheap, but the cost of connecting it to the Internet or the wireless infrastructure is high. From

the user point of view, the cost of accessing data through a wireless carrier is still high and

most cellular phone users are limited to voice services. Moreover, in the event of a disaster,

the wireless infrastructure may be damaged, whereas wireless LANs and vehicular networks

can be used to provide important traffic, rescue, and evacuation information to the users.

Many researchers and industry players believe that the benefit of vehicular networks for

traffic safety and many commercial applications1–3 should be able to justify the cost,

although the cost of setting up vehicular networks is high. In the near future, many of the

proposed delay-tolerant data delivery applications can be supported with such a vehicular

delay-tolerant network already in place.

The fact that vehicular networks are highly mobile and sometimes sparse complicates

multihop delay tolerant data delivery through VANETs. The network density is related to

traffic density. Traffic density is affected by location and time. It is low in rural areas and at

night time, but very high in largely populated areas and during rush hours.

Concept of VDTN

36

Finding an end-to-end connection is very difficult for a sparsely connected network.

Opportunities for mobile vehicles to connect with each other intermittently while moving is

introduced by the high mobility of vehicular networks. There are ample opportunities for

moving vehicles to set up a short path with few hops in a highway model, as shown by

Namboodiri et al. [63]. A moving vehicle can carry a packet and forward it to the next

vehicle. The message can be delivered to the destination without an end-to-end connection

for delay-tolerant applications through store-carry-and-forward.

2.15 Concept of VDTN

Figure – 2.15.1 Concept of Vehicular Delay Tolerant Networks.

The whole concept of VDTN is explained in Figure – 2.15.1. To apply the DTN concept on

vehicular network, in depth knowledge of several routing protocols of DTN is required. After

selecting the appropriate routing protocol for VDTN, it is necessary to have the complete

knowledge of vehicle traffic model. In the general sense, a vehicle traffic model can be

characterized in two aspects: Vehicle-to-roadside (V2R) and Vehicle-to-vehicle (V2V). This

thesis mainly focuses on vehicle-to-vehicle communication only.

LITRATURE REVIEW

37

2.16 Vehicle Traffic Model

Vehicle traffic models are important for DTN routing in vehicle networks because the

performance of DTN routing protocols are closely related to the mobility model of the

network. The car-following model is used in civil engineering to describe traffic behaviour

on a single lane under both free-flow and congested traffic conditions [64]. This model

assumes that each driver in the following vehicle maintains a safe distance from the leading

vehicle and the deceleration factor is also taken into account for braking performance and

drivers’ behaviour. The complete mathematical model is given by,

S' = L+ β' V + γV2 2.1

Where S' is the headway spacing from rear bumper to rear bumper, L is the effective vehicle

length in meters, and V is the vehicle speed in meters/second. β' is driver reaction time in

seconds, and the γ coefficient is the reciprocal of twice the maximum average deceleration

of a following vehicle. Both the β' parameter and the γ coefficient are introduced to ensure

that the following vehicle can come to a complete stop if the leading vehicle suddenly brakes.

As in many other civil engineering studies, we use a so-called “good driving” rule, which

assumes that each vehicle has similar braking performance. In this case, the car following

model can be simplified as,

S' = L+ β' V. 2.2

The car-following model has some limitations in modelling freeway traffic behaviour for the

purpose of wireless networking research, but is one of the most popular models in civil

engineering. These limitations can be summarized as follows:

The car-following model is limited to the situation where driver reaction time is believed to

be a dominant factor. Therefore, it is only an appropriate model under free-flow traffic or

heavy traffic scenarios. Empirical studies [65] confirm that during rush hour β' is typically a

small number that represents the reaction time of a driver, following a log-normal

distribution [66]. However, in light to moderate traffic, β' can be as large as 50 to 100 sec

and cannot be interpreted as driver reaction time [66]. Instead, interarrival time between

vehicles should be used to describe this spacing.

This is the focus of vehicular safety research in civil engineering. Therefore, the car-

following model describes headway spacing between two adjacent vehicles of the same lane

(i.e., lane-level spacing). From the network connectivity standpoint, however, we observe

Vehicle – Roadside Data Access

38

that the most relevant metric is spacing from the leading vehicle to the nearest following

vehicle on a multilane road (i.e., road-level spacing), regardless of whether the following

vehicle is on the same lane or on a different lane from the leading vehicle.

To address both of the aforementioned limitations, the car-following model is extended to

the road level by replacing the lane-level reaction time β' with a road-level inter arrival time

b (the inter arrival time of vehicles on any lane on the same road as observed from a fixed

observation point). The lane-level car-following model can be generalized as,

S' = Lmin+ β' V 2.3

Where Lmin is the minimum spacing between any two adjacent vehicles, which is assumed

to be zero in this study. By focusing on road-level inter vehicle spacing S, the proposed

model not only models rush-hour heavy traffic but also captures the sparse or intermediate

traffic during non-rush hour times.

2.16.1 Vehicle – Roadside Data Access

Although a lot of research has been carried out on intervehicle communication, vehicle–

roadside data access is also an important issue in vehicle DTN network. Medium access

control (MAC) issues have been addressed in Refs. [67], [68], and [69], where slot-

reservation MAC protocols [68],[69] and congestion control policies for emergency warning

[67] are studied.

In a recent paper on vehicle–roadside data access [70], the roadside unit (RSU) can act as a

router in a delay-tolerant network or as an access point for vehicles to access the Internet.

Although this can bring many benefits to drivers, the deployment cost and maintenance cost

are very high. As another option, RSU can also be used as a buffer point (or data island)

between vehicles. This section focuses on the latter paradigm due to its low cost and easy

deployment.

All data on the RSUs are uploaded or downloaded by vehicles in this paradigm. For example,

some data, especially those with special /temporal constraints, only need to be stored and

used locally. Applications that also belong to this case where the data is buffered at the RSUs

and will not be sent to the Internet include the following:

1) Real-time traffic. Vehicles can observe real-time traffic observations and report them

to nearby RSUs. The traffic data are stored at RSUs, providing real-time query and

LITRATURE REVIEW

39

notification services to other vehicles. The data can be used to provide traffic

conditions and alerts such as road congestion and accidents.

2) Value-added advertisement. To provide efficient advertisements, stores may want to

advertise their sale or activity information in nearby area. Without Internet

connection, they can ask the running vehicles to carry and upload the advertisement

information to nearby RSUs. At the same time, other vehicles driving around can

download these advertisements and visit the stores.

3) Digital map downloading. It is impossible for vehicles to install all the most up-to-

date digital maps before traveling. This would help to solve the storage limitations

of memory cards and changes resulting from frequent road construction. Hence,

vehicles driving to a new area may update map data locally for travel guidance.

Vehicles are moving and they only stay in the RSU area for a short period of time. This

makes vehicle networks different from traditional data access systems in which users can

always wait for the service from the data server. As a result, there is always a time constraint

associated with each request. Meanwhile, to make the best use of the RSU and to share the

information with as many vehicles as possible, RSUs are often set at roadway intersections

or areas with high traffic. In these areas, download (query) requests retrieve data from the

RSU, and upload (update) requests upload data to the RSU. Both download and upload

requests compete for the same limited bandwidth. As the number of users increases, deciding

which request to serve at which time will be critical to system performance. Hence, it is

important to design an efficient scheduling algorithm for vehicle–roadside data access.

2.16.2 A Model for the Vehicle – Roadside Data Access

Figure – 2.16.2.1 An Architecture of Vehicle – Roadside Data Access Module

An architecture of vehicle–roadside service scheduling is shown in Figure – 2.16.2.1, where

a large number of vehicles retrieve (or upload) their data from (or to) the RSU when they

Roadside Unit Scheduling Scheme

40

are in communication range. The RSU (server) maintains a service cycle, which is non-

preemptive; that is, a service cannot be interrupted until it finishes. When one vehicle enters

the RSU area, it listens to the wireless channel.

All vehicles can send requests to the RSU if they want to access the data. Each request is

characterized by a 4-tuple: <v-id, d-id, op, deadline>, where v-id is the identifier of the

vehicle, d-id is the identifier of the requested data item, op is the operation that the vehicle

wants to do (upload or download), and deadline is the critical time constraint of the request,

beyond which the service becomes useless.

All requests are queued at the RSU server upon arrival. Based on the scheduling algorithm,

the server serves one request and removes it from the request queue. Unlike traditional

scheduling services, data access in vehicular networks has two unique features:

1) The arrival request is only active for a short period of time due to vehicle movement

and coverage limitations of RSUs. When vehicles move out of the RSU area, the

unserved requests have to be dropped.

2) Data items can be downloaded and uploaded from the RSU server. The download

and update requests compete for the service bandwidth.

It is assumed that each vehicle knows the service deadline of its request. This is reasonable

because when a vehicle with a GPS device enters the coverage area of a RSU, it can estimate

its departure time based on the knowledge of its driving velocity and its geographic position.

After a vehicle establishes connectivity with one RSU, it can get the geographic information

and radio range of the RSU through beacon messages. With its own driving velocity and

position information, the vehicle can estimate its departure time, which is its service

deadline.

2.16.3 Roadside Unit Scheduling Scheme

Giving more bandwidth to download requests can provide a higher download service ratio,

but a higher update drop ratio and hence low data quality. Therefore, achieving both high

service ratio and good data quality is very difficult. If update requests get more bandwidth,

the service ratio decreases.

LITRATURE REVIEW

41

There is always a trade-off between high service ratio and good data quality. Our focus now

switches to improving the service ratio. The primary goal of a scheduling scheme is to serve

as many requests as possible. We identify two parameters that can be used for scheduling

vehicle–roadside data access:

1. Deadline. The request is not useful and should be dropped if a request cannot be

served before its deadline. The request with an earlier deadline is more urgent than

the request with a later deadline.

2. DataSize. Usually, vehicles can communicate with the RSU at the same data

transmission rate. The data size decides how long the service will last.

Three naive schemes for roadside unit scheduling are as follows:

1. First Deadline First (FDF). In this scheme, the request with the most urgency will

be served first.

2. Smallest DataSize First (SDF). In this scheme, the data with a small size will be

served first.

3. First Come First Serve (FCFS). In this scheme, the request with the earliest arrival

time will be served first.

The service ratios under these three naive scheduling schemes are compared in Figure –

2.16.3.1. The interarrival time of the requests is determined by the percentage of vehicles

that will issue service requests, which is varied along the x-axis. As shown in the figure,

when the request arrival rate is low, FDF outperforms FCFS and SDF. This is because, when

the workload is low, the deadline factor has more impact on the performance.

After the urgent requests are served, other pending requests can still have the opportunity to

get services. However, when the request arrival rate increases, the service ratio of FDF drops

quickly while SDF performs relatively better. Because the system can always find short

requests for service, SDF can still keep a higher service ratio. FCFS does not take any

deadline or data size factors into account when making scheduling decisions. It has the worst

performance.

Data size and request deadlines are not considered in FCFS. FDF gives the highest priority

to the most urgent requests while neglecting the service time spent on those data items. SDF

takes the data size into account but ignores the request urgency. It is clearly shown in the

figure that FDF and SDF can only achieve good performance for certain workloads.

Roadside Unit Scheduling Scheme

42

This motivates the integration of the deadline and data size to improve the performance of

scheduling. None of them can provide a good scheduling as a result. D * S30 considers both

data size and deadlines when scheduling vehicle–roadside data access.

. From the above observations, there are two principles are:

1) Given two requests with the same deadline, the one asking for a small size of data

should be served first.

2) Given two requests asking for data with same size, the one with the earlier deadline

should be served first.

Figure – 2.16.3.1 Service ratio for FCFS, FDF, and SDF schemes.

Each request is given a service value based on its deadline and data size, called DS_value,

as its service priority weight:

DS_value = (Deadline - CurrentClock) * DataSize 2.4

In equation 5.4, the deadline and data size factors are multiplied because these two factors

have different measurement scales and/or units. With product, different metrologies will not

impose any negative effect on the comparison of two DS_values. At each scheduling time,

the D * S scheme always serves the requests with the minimum DS_value.

LITRATURE REVIEW

43

2.16.4 Vehicle – Vehicle Data Access Model

Although most of the existing work on vehicle networks is limited to 1-hop or short range

multi hop communication, vehicular delay-tolerant networks are useful to other scenarios.

For example, without Internet connection, a moving vehicle may want to query a data centre

ten miles away through a VANET. The widely deployed wireless LANs or infostations

[71],[72] can also be considered.

Vehicle delay-tolerant networks have many applications, such as delivering advertisements

and announcements regarding sale information or remaining stocks at a department store.

Information such as the available parking spaces in a parking lot, the meeting schedule at a

conference room, and the estimated bus arrival time at a bus stop can also be delivered by

vehicle delay-tolerant networks.

For the limited transmission range, only clients around the access point can directly receive

the data. However, this data may be beneficial to people in moving vehicles far away, as

people driving may want to query several department stores to decide where to go. A driver

may query the traffic cameras or parking lot information to make a better travel plan. A

passenger on a bus may query several bus stops to choose the best stop for bus transfer. All

these queries may be issued miles away from the broadcast site. With a vehicular delay-

tolerant network, the requester can send the query to the broadcast site and get a reply from

it. In these applications, the users can tolerate up to a minute of delay as long as the reply

eventually returns.

The problem of efficient data delivery in vehicular delay-tolerant networks is studied in this

section. Specifically, when a vehicle issues a delay-tolerant data query to some fixed site, it

is important to know how to efficiently route the packet to that site and receive the reply

with a reasonable delay.

Some of the carry-and-forwarding approaches both pose too much control or no control at

all on mobility, and hence are not suitable for vehicular networks. In contrast, VADD makes

use of predictable vehicle mobility, which is limited by the traffic pattern and road layout.

For example, the driving speed is regulated by the speed limit and the traffic density of the

road, the driving direction is predictable based on the road pattern, and the acceleration is

bounded by the engine speed. VADD exploits the vehicle mobility pattern to better assist

data delivery.

Concept of Vehicle Assisted Data Delivery Protocol

44

2.16.5 Concept of Vehicle Assisted Data Delivery Protocol

In the model assumed by the VADD protocol, vehicles communicate with each other through

a short-range wireless channel, and vehicles can find their neighbours through beacon

messages. The packet delivery information such as source ID, source location, packet

generation time, destination location, expiration time, and so on, are specified by the data

source and placed in the packet header. A vehicle knows its location by triangulation or

through a GPS device, which is already popular in new cars and will be common in the

future.

Figure – 2.16.5.1 Architecture of Vehicle assisted Data Delivery Model

Geographical information is also assumed to be available in the vehicles. Vehicles are

equipped with preloaded digital maps, which provide street-level maps and traffic statistics

such as traffic density and vehicle speed on roads at different times of the day. Such digital

maps have already been commercialized. The latest one is developed by Map Mechanics

[73], on each road. Yahoo! is also working on integrating traffic statistics in its new product

called SmartView [74], where real traffic reports of major U.S. cities are available.

It is expected that more detailed traffic statistics will be integrated into digital maps in the

near future. The cost of setting up such a vehicular network can be justified by its application

to many road safety and commercial applications, which are not limited to the proposed

delay-tolerant data-delivery applications.

LITRATURE REVIEW

45

The most important issue is to select a forwarding path with the smallest packet delivery

delay. VADD is based on the idea of carry and forward. Although geographical forwarding

approaches such as GPSR [75], which always chooses the next hop closer to the destination,

are very efficient for data delivery in ad hoc networks, they may not be suitable for sparsely

connected vehicular networks.

Suppose a driver approaches intersection Ia and he wants to send a request to the coffee shop

(to reserve a sandwich) at the corner of intersection Ib, as shown in Figure – 2.16.5.1. To

forward the request through Ia A Ic, Ic A Id, Id A Ib would be faster than forwarding through

Ia A Ib, even though the latter provides a geographically shortest-possible path. The reason

is that, in the case of disconnection, the packet has to be carried by the vehicle, whose moving

speed is significantly slower than the wireless communication. VADD follows the following

basic principles:

1) If the packet has to be carried through certain roads, the road with higher speed

should be chosen.

2) Transmit through wireless channels as much as possible.

3) Owing to the unpredictable nature of VANETs, the packet cannot be expected to be

successfully routed along the pre-computed optimal path, so dynamic path selection

should continuously be executed throughout the packet-forwarding process.

As shown in the Figure – 2.16.5.2, in Vehicle Assisted Data Delivery (VADD) has three

packet modes: Intersection, Straight Way, and Destination, based on the location of the

packet carrier (i.e., the vehicle that carries the packet.) By switching between these packet

modes, the packet carrier takes the best packet-forwarding path. Among the three modes, the

Intersection mode is the most critical and complicated one, because vehicles have more

choices at the intersection.

SUMMARY

46

Figure – 2.16.5.2 Transmission Mode in VADD.

2.17 SUMMARY

In this chapter researcher has given a detailed overview of the literature survey. Present

layers of TCP/IP scheme is facing problems with custody transfer. DTN will allow sender

to send data with custody transfer. In DTN intermediate node can take decision regarding

delivery of data. In worst conditions traditional transport protocol is not capable to have data

delivery with good throughput. So, DTN has given concept of Bundle Layer.

In next section researcher has given better idea of routing in DTN. WE have discussed

working of all routing protocols. We have also discussed different model for data transfer in

VDTN.

.

SIMULATION METHODOLOGY

47

Chapter 3


This chapter contains an implementation methodology of VDTN for Surat city. Further, the

detailed description of ‘The ONE’ simulator is given. Then after, the simulation parameter

setup information is given. At the end of this chapter, a detailed information of quality

measurement parameters is given.

3.1 Traffic Analysis of SURAT City

The main motive of this dissertation work is to apply the concept of DTN over any Vehicular

Network and advocate the performance of several DTN routing protocols over it. To better

judge the performance of this routing protocols, it is necessary that the generated vehicular

network should match the real time traffic scenario. So, to fulfill this motive, very first the

traffic of whole Surat city is analyzed. Based on those data the VDTN is generated and

further simulated in The ONE (The Opportunistic Network Environment) simulator. As The

ONE simulator support Direct Delivery, Epidemic and Spray and Wait DTN routing

algorithms, these three routing algorithms are chosen as a key routing protocols for the

comparison point of view. To advocate the performance of them over VDTN of Surat city,

a separate simulation is carried out and further they are analyzed and compared with the help

of several quality measurement parameters. Table – 3.1.1 contains the traffic analysis data

of Surat city.

Table - 3.1.1 Traffic Analysis Data of Surat City.

TYPES DATA

Analysis Time Period 10 Hour

Cars 400

City Bus 60

Auto 570

The ONE (The Opportunistic Network Environment) Simulator

48

Total BRTS Buses Assigned for whole BRTS Project 60 (According to SMC Data)

Total Expected BRTS Buses 40

3.2 The ONE (The Opportunistic Network Environment) Simulator

Figure - 3.2.1 Overview of the ONE Simulation Environment [76].

At its core, ONE is an agent-based discrete event simulation engine. At each simulation step

the engine updates a number of modules that implement the main simulation functions.

Figure - 3.2.1 gives the overview of The ONE simulation environment.

The main functions of the ONE simulator are the modeling of node movement, inter-node

contacts, routing and message handling. Result collection and analysis are done through

visualization, reports and post-processing tools. The elements and their interactions are

shown in figure 3.2.1. A detailed description of the simulator is available in [76] and the

ONE simulator project page [77] where the source code is also available.

Node movement is implemented by movement models. These are either synthetic models or

existing movement traces. Connectivity between the nodes is based on their location,

communication range and the bit-rate. The routing function is implemented by routing

modules that decide which messages to forward over existing contacts. Finally, the messages

themselves are generated through event generators. The messages are always unicast, having

a single source and destination host inside the simulation world.


49

Simulation results are collected primarily through reports generated by report modules

during the simulation run. Report modules receive events (e.g., message or connectivity

events) from the simulation engine and generate results based on them. The results generated

may be logs of events that are then further processed by the external post-processing tools,

or they may be aggregate statistics calculated in the simulator. Secondarily, the graphical

user interface (GUI) displays a visualization of the simulation state showing the locations,

active contacts and messages carried by the nodes.

3.2.1 Node Capabilities

The basic agents in the simulator are called nodes. A node models a mobile endpoint capable

of acting as a store-carry-forward router (e.g., a pedestrian, car or tram with the required

hardware). Simulation scenarios are built from groups of nodes in a simulation world. Each

group is configured with different capabilities.

Each node has a set of basic capabilities that are modelled. These are radio interface,

persistent storage, movement, energy consumption and message routing. Node capabilities

such as the radio interface and persistent storage that involve only simple modelling are

configured through parameterization (e.g., communication range, bitrate, peer scanning

interval and storage capacity). More complex capabilities such as movement and routing are

configured through specialized modules that implement a particular behaviour for the

capability (e.g., different mobility models).

Modules in each node have access to the node’s basic simulation parameters and state,

including the position, current movement path, and current neighbours. This allows

implementing, e.g., geographic routing and other context-specific algorithms. In addition,

modules can make any of their parameters available for other modules in the same node

through an inter module communication bus. This way, for example, a movement module

can change its behaviour depending on the router module’s state or a router module can

adjust the radio parameters based on the node inter contact times.

The focus of the simulator is on modelling the behaviour of store-carry-forward networking,

and hence we deliberately refrain from detailed modelling of the lower layer mechanisms

such as signal attenuation and congestion of the physical medium. Instead, the radio link is

abstracted to a communication range and bit-rate. These are statically configured and

typically assumed to remain constant over the simulation. However, the context awareness

Mobility Modelling

50

and dynamic link configuration mechanisms can be used to adjust both range and bitrate

depending on the surroundings, the distance between peers and the number of (active) nodes

nearby as suggested, e.g., in [78].

The node energy consumption model is based on an energy budget approach. Each node is

given an energy budget which is spent by energy consuming activities such as transmission

or scanning and can be filled by charging in certain locations (e.g., at home).

An inquiry mechanism allows other modules to obtain energy level readings and adjust their

actions (e.g., scanning frequency as in [79], forwarding activity, or transmission power)

accordingly.

3.2.2 Mobility Modelling

Node movement capabilities are implemented through mobility models. Mobility models

define the algorithms and rules that generate the node movement paths. Three types of

synthetic movement models are included: 1) random movement, 2) map-constrained random

movement, and 3) human behaviour based movement.

The simulator includes a framework for creating movement models as well as interfaces for

loading external movement data (see 3.5). Implementations of popular Random Walk (RW)

and Random Waypoint (RWP) are included. While these models are popular due to their

simplicity, they have various known shortcomings [80].

To better model real-world mobility, map-based mobility con- strains node movement to

predefined paths and routes derived from real map data. Further realism is added by the

Working Day Movement (WDM) model [81] that attempts to model typical human

movement patters during working weeks.

3.2.2.1 Map-Based Mobility

Map-based movement models constrain the node movement to paths defined in map data.

The ONE simulator release includes three map-based movement models: 1) Random Map-

Based Movement (MBM), 2) Shortest Path Map-Based Movement (SPMBM), and 3)

Routed Map-Based Movement (RMBM). Furthermore, the release contains map data of the

Helsinki downtown area (roads and pedestrian walkways) that the map-based movement

models can use. However, the movement models understand arbitrary map data defined in

(a subset of) Well -Known Text (WKT). Such data is typically converted from real-world


51

map data or created manually using Geographic Information System (GIS) programs such

as OpenJUMP.

In the simplest map-based model, MBM, nodes move randomly but always follow the paths

defined by the map data. This results in a random walk of the network defined by the map

data and thus may not be a very accurate approximation of real human mobility. A more

realistic model is the SPMBM where, instead of a completely random walk, the nodes choose

a random point on the map and then follow the shortest route to that point from their current

location. The points may be chosen completely randomly or from a list of Points of Interest

(POI). These POIs may be chosen to match popular real-world destinations such as tourist

attractions, shops or restaurants. Finally, nodes may have pre-determined routes that they

follow, resulting in the RMBM model. Such routes may be constructed to match, e.g., bus,

tram or train routes.

3.2.2.2 Working Day Movement Model (WDM)

While high-level movement models such as RWP, MBM, and SPMBM are simple to

understand and efficient to use in simulations they do not generate inter-contact time and

contact time distributions that match real-world traces, especially when the number of nodes

in the simulation is small. In order to increase the reality of (human) node mobility, we have

developed the Working Day Movement (WDM) model [81] for ONE.

The WDM model brings more reality to the node movement by modeling three major

activities typically performed by humans during a working week: 1) sleeping at home, 2)

working at the office, and 3) going out with friends in the evening. These three activities are

divided into corresponding sub-models between which the simulated nodes transition

depending on the time of the day.

Beyond the activities themselves, the WDM model includes three different transport models.

The nodes can move alone or in groups by walking, driving or riding a bus. The ability to

move alone or in groups at different speeds increases the heterogeneity of movement which

has impact on the performance of, e.g., routing protocols.

Finally, WDM introduces communities and social relationships which are not captured by

simpler models such as RWP. The communities are composed from nodes which work in

the same office, spend time in the same evening activity spots or live together.

Routing

52

We have shown that the inter-contact time and contact time distributions generated by the

WDM model follow closely the ones found in the traces from real-world measurements.

3.2.3 Routing

The message routing capability is implemented similarly to the movement capability: the

simulator includes a framework for defining the algorithms and rules used in routing and

comes with ready implementations of well-known DTN routing protocols.

There are six included routing protocols: 1) Direct Delivery (DD), 2) First Contact (FC), 3)

Spray-and-Wait, 4) PRoPHET, 5) MaxProp, and 6) Epidemic. This selection covers the most

important classes of DTN routing protocols: single-copy, n-copy and unlimited-copy

protocols, as well as estimation based protocols.

Direct Delivery and First Contact are single-copy routing protocols where only one copy of

each message exists in the network. In Direct Delivery, the node carries messages until it

meets their final destination. In First Contact routing the nodes forward messages to the first

node they encounter, which results in a “random walk” search for the destination node.

Whereas Epidemic, Spray and Wait, MaxProp are multi copy or n-copy routing protocols.

3.2.4 Application Support

The ONE simulator provides two ways to generate application messages inside the

simulation: 1) message generators, and 2) external event files. Messages may be

unidirectional or generate replies when they are received, approximating a request-response

type application. Furthermore, the messages may include application specific information

through generic (name, value) pairs attached to them.

The built-in message generator creates messages with a random or fixed source, destination,

size, and interval. A separate tool for generating message event files is also included. Any

number of such message event sources may be used concurrently in simulations. Messages

are either unidirectional or tagged to expect a response, with separate control of the response

size.


53

Application-specific headers and payloads may be attached to the messages and nodes may

be extended to support inspecting message headers and contents along the way so that

application aware forwarding can be realized, e.g., for content distribution.

3.2.5 Interfaces

An important feature of ONE is its ability to interact with other programs and data sources.

The simulator has interfaces, e.g., for node movement, connectivity and message routing

traces.

It is possible to generate node movement using an external program, such as TRANSIMS or

Bonn Motion, or from a real-world GPS trace such as the ones available from CRAWDAD.

Such a trace file needs to be converted to a suitable form for the External Movement module.

The distribution package contains a simple script that can convert TRANSIMS output to this

format.

Like node movement and connection traces, also message traces can be imported to ONE.

These may include message creation and deletion events, and starting and cancellation of

message transfers. This functionality is especially useful if ONE is used for analysing traces

generated by other DTN routing simulators or even real-world traces.

In addition to reading output of other programs, ONE can also generate input traces for them.

It has report modules whose output is compatible with dtnsim and dtnsim2 connectivity trace

input. In a similar fashion, it is also possible to create mobility traces using a mobility report

module. While report files are an easy way to interact with other programs, a report module

can also communicate in real time with them.

3.2.6 Reporting and Visualization

ONE is able to visualize results of the simulation in two ways: via an interactive Graphical

User Interface (GUI) and by generating images from the information gathered during the

simulation.

GUI display the simulation in real-time. Node locations, current paths, connections between

nodes, number of messages carried by a node, etc. are all visualized in the main window. If

Creating Simulation Scenario

54

a map-based movement model is used, also all the map paths are shown. The view allows

zooming and interactive adjusting of the simulation speed.

ONE includes report modules that can create Graphviz compatible graph files. Likewise,

for visualizing how messages are spread in the network as a function of time, a message

location report module can provide this data and an animator script will turn the data into a

GIF animation.

The simulator includes a message statistics report module that gathers statistics of overall

performance (amount of created messages, message delivery ratio, how long messages stay

in node buffers, etc.). A post processing script that plots the report module’s output is also

included.

3.2.7 Creating Simulation Scenario

Simulation scenarios are built by defining the simulated nodes and their capabilities. This

includes defining the basic parameters such as storage capacity, transmit range and bit-rates,

as well as selecting and parameterizing the specific movement and routing models to use.

Some simulation settings such as simulation duration and time granularity also need to be

defined.

The simulator is configured using simple text-based configuration files that contain the

simulation, user interface, event generation, and reporting parameters. All modules have

their high-level behaviour defined by their Java code implementation, but the details of their

behaviour is adjustable using the configuration subsystem. Many of the simulation

parameters are configurable separately for each node group but groups can also share a set

of parameters and only alter the parameters that are specific for the group. The configuration

system also allows defining of an array of values for each parameter hence enabling easy

sensitivity analysis: in batch runs, a different value is chosen for each run so that large

amounts of permutations are explored.

If configuring existing implementations of different modules is insufficient for creating a

specific scenario, ONE can also be extended with new code. Routing modules, movement

models, event generators and report modules are all dynamically loaded when the simulator

is started. Hence, when creating a new module, user only needs to create and compile a new

class, define its name in the configuration file, and the simulator automatically loads it when


55

the scenario is started. All these modules can also have any number of settings defined in

the configuration files and these settings are accessible to the module when it is loaded.

3.3 Simulation Parameter Setup Information

As the ONE simulator supports map integration of any city, in this dissertation work the

Surat city map is taken for the reference. Figure – 3.3.1 shows the Open Street Map (.osm

format) of Surat city which is integrated for the simulation in The ONE simulator. As

explained in above section, The ONE supports only Well Known Text (.wkt) format for the

integration of any map. So, it is necessary to convert the Surat city map from Open Street

Map (.osm) to Well Known Text (.wkt) format. Figure – 3.3.2 represents the Surat city map

in Well Known Text (.wkt) format.

Figure – 3.3.1 The Open Street Map of Surat City.

Interface Setup Information

56

Figure – 3.3.2 The Surat City Map in Well Known Text Format.

3.3.1 Interface Setup Information

As in ref [82], The ONE simulator also consists one sample VDTN implementation in which

the traffic of Helsinki city is analyzed. For their simulations, they have assumed

interpersonal communication between mobile users in a city using modern mobile phones or

similar devices, using Bluetooth at 2 Mbit/s net data rate with 10 m radio range. The mobile

devices have up to 100 MB of free buffer space for storing and forwarding messages (flash

memory may mostly be occupied by music or photos.)

But the fact is that thinking of mobile as a router is quite impractical. Most of the lower end

mobile phones have limited inbuilt memory (10 – 90 Mb only). So, it is difficult to provide

separate memory for DTN bundles transmission. The major limitation is the battery backup

for any mobile. Now a days, almost all windows based or android based smart phones

provides the very less battery backup (12 – 16 Hours only). So, thinking of them as a DTN

bundles router will reduces the battery backup to 4 – 7 Hours only. So, thinking of another

option in place of mobile is more preferable.

Now a days, most of the people installs touchscreen multimedia devices in their four

wheelers. In which most of the touchscreen devices comes with the GPS navigation facility.


57

So, if it is assumed that those devices also equipped with Bluetooth and WiFi connectivity

and capable to make an ad-hoc network to exchange information then by providing required

memory to it we can use them as a DTN bundles routers. This assumption will not only solve

the problem of buffer memory but also solve the battery problem, because those devices will

consumes the power from the battery of four wheelers.

In this dissertation work for the simulation, several standard interfaces are utilized. These

standard interfaces includes Bluetooth interface with version 2.0 + EDR (Enhance Data

Rate) and Wireless LAN 802.11 b/g/n. The complete configuration details of them are given

in Table – 3.3.1.1.

Table - 3.3.1.1 Configuration Details of Several Standard Interfaces.

Configuration Bluetooth WiFi – 1 WiFi - 2 WiFi – 3

Standard IEEE 802.15.1 IEEE 802.11 IEEE 802.11 IEEE 802.11

Version 2.0 + EDR 802.11 b 802.11 g 802.11 n

Frequency 2.4 Ghz 2.4 GHz 2.4 GHz 2.4/5 GHz

Modulation 8 DPSK DSSS DSSS, OFDM OFDM

Transmission

Range (m)

10 m Indoor- 35

Outdoor – 140

Indoor- 38

Outdoor - 140

Indoor- 70

Outdoor - 250

Data Rate

(in Mbps )

3 Mbps

(version 2.0 +

EDR)

11 Mbps 54 Mbps 150 Mbps

3.3.2 Grouping of Vehicles

For the implementation of VDTN, the whole traffic of Surat city is categorized in four major

groups: Four Wheelers, Auto Rickshaws, City buses and BRTS buses. The whole

configuration of each group is as follows:

A) Group – 1 (Car or four wheelers):

This group only contains cars or four wheelers. According to the analyzed data, here 400

hosts are assigned. Each host is assigned the speed limit of 10 – 60 Km/h. For making an ad-

hoc network and exchanging the data, total two interfaces are assigned: (1) Bluetooth

Interface with version 2.0 + EDR and (2) WiFi 802.11 b/g interface. The whole configuration

of this group is given in Table – 3.3.2.1.

Grouping of Vehicles

58

Table – 3.3.2.1 Configuration Detail for the group of Car or Four wheeler.

PARMETERS VALUE

Total no of Host 400

Speed Limit 10 – 60 Km/h

Speed Limit (in m/sec) 2.78 – 16.67 m/s

Buffer Capacity 500 Mb

Interface – 1 WiFi - 802.11

Maximum WiFi Bitrate 11 Mbps

WiFi Version IEEE 802.11 b/g

Transmit Range 70 m

Interface – 2 Bluetooth

Bluetooth Version 2.0 + EDR (Maximum Data Rate = 3 Mbps)

Bluetooth Class 2 ( Maximum Range = 10 m )

Transmit Range 10

Group ID C

B) Group – 2 (Auto Rikshow):

This group only contains auto rickshaws. According to the traffic analysis data, here 570

hosts are assigned. Each host is assigned the speed limit of 10 – 40 Km/h. Due to the limited

resources and facilities available in auto rickshaw, only Bluetooth interface is assigned to it.

Though Four Wheeler’s group and City bus group are also assigned Bluetooth interface,

Auto Rickshaw can communicate either with another Auto Rickshaw or with any Car or City

Bus through a Bluetooth Interface. The whole configuration of this group is given in Table

– 3.3.2.2.

Table – 3.3.2.2 Configuration Detail for the Group of Auto Rickshaw.

PARAMETERS VALUE

Total no of Host 570




Interface Bluetooth Interface



59


Transmit Range 10 m

Group ID A

C) Group – 3 (City Bus)

This group includes city buses only. According to Surat Municipal Corporation (SMC) data,

total 75 buses are assigned for different roots in Surat city. During the traffic analysis phase

of this dissertation work it was found that total 60 buses are assigned for the areas which

was analysed. So that, 60 hosts are assigned for this group. Each host is assigned the speed

limit of 10 – 50 Km/h. As similar to the four wheeler’s group, this group is also assigned

Bluetooth 2.0 + EDR and Wi-Fi 802.11 b/g interfaces. The whole configuration of this group

is given in Table – 3.3.2.3.

Table – 3.3.2.3 Configuration Detail for the Group of City Bus.

PARAMETERS VALUE

Total no of Host 60




Interface – 1 WiFi - 802.11


WiFi Version IEEE 802.11 b/g

Transmit Range 70 m




Transmit Range 10 m

Group ID CB

D) Group – 4 (BRTS)

BRTS project is running successfully in Ahmedabad city from last few years. Surat

Municipal Corporation (SMC) has also taken first step towards the implementation of BRTS

Quality Assessment Parameters

60

project in Surat city. Due to their efforts today BRTS project is under construction in Surat

city. According to their data total 60 buses will cover the whole BRTS roots. Among them

40 buses are assigned for the BRTS roots which are right now under construction and 20

buses are assigned for the roots which will be implemented after completion of the outer ring

road project.

Table – 3.3.2.4 Configuration Detail for the Group of BRTS Bus.

PARAMETERS VALUE

Total no of Host 40




Interface – 1 Wireless LAN (IEEE 802.11 n)


Transmit Range 150 m



Bluetooth Class 2 ( Maximum Transmit Range = 10 m )

Group ID B

In this dissertation work, the main concentration is given on the ongoing BRTS project only.

So, 40 BRTS buses are assigned for the simulation. Speed of each host is limited to 10 – 50

Km/h. Each host is assigned a dual interface: Bluetooth 2.0 + EDR and WiFi 802.11 n. The

whole configuration details of this group are provided in Table – 3.3.2.4.

3.4 Quality Assessment Parameters

In this dissertation work, as explained in above section, first the Vehicular Delay Tolerant

Network is generated according to the traffic analysis data of Surat city. To generate VDTN

for Surat city two strategies are adopted. In very first strategy, only four wheelers, auto

rickshaws and city buses are considered for the traffic analysis. In the second strategy the

BRTS is also included in implementation. Then after Direct Delivery, Epidemic and Spray

and Wait routing protocols are analysed over the both the generated VDTN scenarios. To


61

advocate the performance of these stochastic DTN routing protocols six quality assessment

parameters are utilized. The detailed description of these parameters are as follows:

Successful Transmission Ratio: It is the ratio of total number of successful transmission

between nodes to total number of transmissions started between network nodes.

Packet Delivery Probability: It is the ratio of total number of successfully delivered messages

to total number of messages created during the simulation.

Channel Overhead Ratio: Channel overhead ratio is used for the assessment of the bandwidth

efficiency. It indicates the actual occupancy of bandwidth.

Average Latency: It is the average time delay for each messages from its creation to

successful delivery.

Average Hop Count: It shows the average number of occupied hops from source to

destination during the message transmission.

Average Message Buffer Time: It is the average time that messages stayed in the buffer at

each node.

3.5 SUMMARY

In this chapter we have focused on simulator. We have given brief introduction of the

simulator we have used. The map of Surat City and traffic scenario of it is discussed.

According to the traffic scenario how different parameters are taken that is also shown in

this chapter.

Introduction

62

CHAPTER 4

PERFORMANCE COMPARISON OF ROUTING

PROTOCOLS IN VDTN

4.1 Introduction

As per previous chapter discussion. Whatever protocols are used for DTN they are also used

for VDTN. This section gives detail information of Spray and Wait protocol according to

information of [83]. Routing consists of a sequence of independent, local forwarding

decisions, based on current connectivity information and predictions of future connectivity

information. In other words, node mobility needs to be exploited in order to deliver a

message to its destination. However, there mobility is exploited in order to improve capacity,

while in that paper it is used to overcome the lack of end-to-end connectivity. Despite a large

number of existing proposals, there is no routing scheme that both achieves low delivery

delays and is energy-efficient (i.e. performs a small number of transmissions).

With considering these feature, in that authors introduce novel routing scheme called Spray

and Wait. Spray and Wait bounds the total number of copies and transmissions per message

without compromising performance.

Using theory and simulations they show that:

(i) Under low load, Spray and Wait results in much fewer transmissions and comparable or

smaller delays than flooding-based schemes,

(ii) Under high load, it yields significantly better delays and fewer transmissions than

flooding-based schemes,

(iii) It is highly scalable, exhibiting good and predictable performance for a large range of

network sizes, node densities and connectivity levels; what is more, as the size of the network

PERFORMANCE COMPARISON OF ROUTING PROTOCOLS IN VDTN

63

and the number of nodes increase, the number of transmissions per node that Spray and Wait

requires in order to achieve the same performance decreases, and

(iv) It can be easily tuned online to achieve given QoS requirements, even in unknown

networks.

Epidemic routing extends the concept of flooding in intermittently connected mobile

networks. It is one of the first schemes proposed to enable message delivery in such

networks. Each node maintains a list of all messages it carries, whose delivery is pending

[84]. Whenever it encounters another node, the two nodes exchange all messages that they

don’t have in common. This way, all messages are eventually “spread” to all nodes,

including their destination (in an epidemic manner). Although epidemic routing finds the

same path as the optimal scheme under no contention, it is very wasteful of network

resources. Furthermore, it creates a lot of contention for the limited buffer space and network

capacity of typical wireless networks, resulting in many message drops and retransmissions

[84]. This can have a detrimental effect on performance, as has been noted earlier in. One

simple approach to reduce the overhead of flooding and improve its performance is to only

forward a copy with some probability p < 1. A different, more sophisticated approach is that

of History-based or Utility-based Routing. Here, each node maintains a utility value for

every other node in the network, based on a timer indicating the time elapsed since the two

nodes last encountered each other. These utility values essentially carry indirect information

about relative node locations, which get diffused through nodes’ mobility [84]. Therefore, a

scheme can be designed, where nodes forward message copies only to nodes with a higher

utility by at least some pre-specified threshold value Uth for the message’s destination. Such

a scheme results in superior performance than flooding, and makes better forwarding

decisions than randomized routing. This method has also been found to be quite efficient in

the context of regular, connected, wireless networks [84]. Nevertheless, utility-based

schemes are still flooding-based in nature. What is worse, they are faced with an important

dilemma when choosing the utility threshold. Too small a threshold and the scheme behave

like pure flooding. Too high a threshold and the delay increase significantly.

Single-copy schemes generate and route only one copy per message (in contrast to flooding

schemes that essentially send a copy to every node), in order to significantly reduce the

number of transmissions. Although they might be useful in some situations, single-copy

schemes do not present desirable solutions for applications that require high probabilities of

Introduction

64

delivery and low delays. Finally, an optimal “oracle-based” algorithm is aware of all

future movement, and computes the optimal set of forwarding decisions (i.e. time and next

hop), which delivers a message to its destination in the minimum amount of time. This

algorithm is of course not implementable, but is quite useful to compare against proposed

practical schemes. The scheme, Spray and Wait, manages to significantly reduce the

transmission overhead of flooding-based schemes and have better performance with respect

to delivery delay in most scenarios, which is particularly pronounced when contention for

the wireless channel is high. Further, it does not require the use of any network information,

not even that of past encounters.

Feature of Spray and Wait Routing

Based on the previous exposition, we can identify a number of desirable design goals for a

routing protocol in intermittently connected mobile networks. Specifically, an efficient

routing protocol in this context should:

Perform significantly fewer transmissions than epidemic and other flooding-based

routing schemes, under all conditions.

Generate low contention, especially under high traffic loads.

Achieve a delivery delay that is better than existing single and multi-copy schemes, and

close to the optimal.

Highly scalable, that is, maintain the above performance behavior despite changes in

network size or node density.

Simple and require as little knowledge about the network as possible, in order to facilitate

implementation.

To this end, novel routing scheme, called Spray and Wait that is simple yet efficient, and

meets the above goals, as I will demonstrate in the next sections.

Spray and Wait routing decouples the number of copies generated per message, and therefore

the number of broadcasts done, from the network size. Spray and Wait protocol work in two

modes: Normal mode and Binary mode.

Spray and Wait Normal mode: Spray and Wait routing consists of the following two

phases:


65

Spray phase: for every message originating at a source node, L message copies are

initially spread – forwarded by the source and possibly other nodes receiving a copy to L

distinct “relays”.

Wait phase: if the destination is not found in the spraying phase, each of the L nodes

carrying a message copy performs direct transmission (i.e. will forward the message only to

its destination).

Spray and Wait combines the speed of epidemic routing with the simplicity and thriftiness

of direct transmission. It initially “jump-starts” spreading message copies in a manner

similar to epidemic routing. When enough copies have been spread to guarantee that at least

one of them will find the destination quickly (with high probability), it stops and lets each

node carrying a copy perform direct transmission.

In other words, Spray and Wait could be viewed as a tradeoff between single and multi-copy

schemes. Surprisingly, as we shall shortly see, its performance is better with respect to both

delivery probability and overhead ratio than all other practical single and multi-copy

schemes, in different transmission data speed(data rate) consideration.

The above definition of Spray and Wait leaves open the issue of how the L copies are to be

spread initially. A number of different “spraying” heuristics can be envisioned. For

example, the simplest way is to have the source node forward all L copies to the first L

distinct nodes it encounters (“Source Spray and Wait”). A better way is the following.

Binary Spray and Wait: The source of a message initially starts with L copies; any node A

that has n > 1 message copies (source or relay), and encounters another node B (with no

copies), hands over to B n/2 and keeps n/2 for itself; when it is left with only one copy, it

switches to direct transmission.

4.2 Performance Metrics

All performance parameter information according to [85] is,

Delivery Probability

It is the ratio of message received over message send. High probability means that more

messages are delivered to the destination. Objective of algorithm is to maximize the delivery

probability.

Simulation Result Analysis for SURAT City

66

Delivery Probability =Number of Message Received

Number of Message Send

Latency Average

It is sum of time when message is generated and when it is received. Mathematically can be

represented as

Latency Average = Message Receive Time - Message Generation Time

Objective of algorithm is to minimize the value of latency average

Overhead Ratio

This metric is used to estimate the extra number of packets needed by the routing protocol

for actual delivery of the data packets. Low value of overhead means less processing required

delivering the relayed messages. Mathematically it will define as

Overhead Ratio =Number of Packets Relayed - Number of Packets Delivered

Number of Packets Delivered

4.3 Simulation Result Analysis for SURAT City

In this simulation, only Four Wheelers, Auto Rickshaws and City buses are considered for

the traffic analysis. After generating the VDTN, performance of Direct Delivery, Epidemic

and Spray and Wait routing protocols are analysed with the help of several quality

measurement parameters. The detailed results analysis of this simulation are as follows:

4.3.1 Successful Transmission Ratio

After analysing the comparison chart it can be noticed that successful transmission ratio for

Direct Delivery and Spray and Wait routing is excellent as compared to Epidemic routing.

It means that in Direct Delivery and Spray and Wait routing each node reacts fast and

forwards packets rapidly whenever they are in contact of each other. So, packet forwarding

capability in Direct Delivery and Spray and Wait routing is slightly higher than Epidemic

routing.


67

Figure – 4.3.1 Successful Transmission Comparison Chart.

4.3.2 Packet Delivery Probability

After analysing the chart it can be noticed that Epidemic routing provides excellent packet

delivery probability. As Epidemic routing is a flooding based routing, it delivers almost all

packets which are generated. Spray and Wait also shows the 60 % of packet delivery.

Whereas Direct Delivery routing provides only 20 % packet delivery probability. So, in

terms of packet delivery probability Direct Delivery shows worst performance as compared

to Epidemic and Spray and Wait routing.

Figure – 4.3.2 Average Packet Delivery Probability Comparison Chart.

0.986

0.988

0.99

0.992

0.994

0.996

Direct DeliveryRouting

Epidemic Routing Spray And WaitRouting

0.996

0.9895

0.9949Tr

ansm

issi

on

Rat

io

DTN Routing Protocols

Successful Transmission Ratio

0

0.2

0.4

0.6

0.8

1



0.2068

0.9588

0.6054

Ave

rage

PD

F


Packet Delivery Probability

Channel Overhead Ratio

68

4.3.3 Channel Overhead Ratio

From the Figure – 4.3.3 it is clear that channel overhead ratio for Epidemic routing is much

higher than Direct Delivery and Spray and Wait routing. Channel overhead ratio is nothing

but the channel occupancy during transmission. As Epidemic routing is flooding based

routing, it generates maximum number of packets in network. So, channel occupancy is very

much high in Epidemic routing. Here, channel overhead ratio for the Spray and Wait routing

is quite low. Even though Spray and Wait is also flooding based routing it generates limited

number of packets in network. Whereas Direct Delivery is the hand to hand type routing

protocol. So, channel overhead ratio is zero for it.

Figure – 4.3.3 Channel Overhead Ratio Comparison Chart.

4.3.4 Average Latency

From Figure – 4.3.4 it can be concluded that average latency for Direct Delivery and Spry

and Wait routing is much higher as compared to Epidemic routing. Latency indicates the

time taken by a message from its creation to its delivery. Off course, latency of Direct

Delivery is higher, because Direct Delivery is the hand to hand delivery type routing. So, a

source node has to wait a lot to reach to meet to its destination node. Similarly, Spray and

Wait routing is a combination of Direct Delivery and Epidemic routing. So, latency is much

higher in it. But the Epidemic routing is flooding based routing. So that message reach to its

destination very rapidly. So, latency for Epidemic routing is very low.

0

200

400

600

800

1000

1200

1400



0

1253.1933

8.2095

Ove

rhe

ad R

atio




69

Figure – 4.3.4 Average Latency Comparison Chart.

4.3.5 Average Hop Count

Figure – 4.3.5 Average Hop Count Comparison Chart.

Average hop count is the measure of hop which are occupied during the transmission. From

the Figure – 4.3.5 it can be noticed that Epidemic routing requires more numbers of hop for

the successful message transmission. Though Epidemic routing is the flooding based routing,

it occupies more number of hops during the transmission. Whereas Direct Delivery and

Spray and Wait routing occupies very less number of hops during the transmission. It is fact

0

2000

4000

6000

8000



7469.8845

1442.4828

6331.3442

Ave

rage

Lat

en

cy


Average Latency

0

1

2

3

4

5

6

7

8



1

8

2Ho

p C

ou

nt

DTN Routing Prtocols

Average Hop Count

Average Message Buffer Time

70

that Direct Delivery routing requires only one hop, because it is a hand to hand delivery type

routing (from source to destination).

4.3.6 Average Message Buffer Time

Average message buffer time is the average time for which message has to buffer at any

intermediate node in between its transmission path. From the Figure – 4.3.6 it can be noticed

that average message buffer time for Epidemic routing is very much less. As it supports the

flooding approach, each message takes all the possible paths to reach to its destination.

Whereas in the Direct Delivery and Spray and Wait routing each packets has to buffered at

each and every intermediate nodes until it finds the another node to forward them. So,

message buffer time comparison point of view, Epidemic routing is the best choice as

compared to Direct Delivery and Spray and Wait routing.

Figure – 4.3.6 Average Message Buffer Time Comparison Chart.

4.4 Simulation Result Analysis of SURAT City with BRTS and Shortest

Path Implementation

In this simulation, BRTS traffic is also included and VDTN scenario generated with

assumption that each bus follows their assigned route and each vehicle takes the shortest

path to reach to its destination. Comparative analysis of Epidemic, Direct Delivery and Spray

and Wait routing with their previously explained results are as follows:

02000400060008000

1000012000140001600018000



17970.7475

6181.1668

17891.2109

Bu

ffe

r Ti

me




71

4.4.1 Successful Transmission Ratio

From the Figure – 4.4.1, it can be noticed that successful transmission ratio slightly increases

in Direct Delivery routing as compared to previous scenario. Whereas degradation is noticed

in Epidemic and Spray and Wait routing as compared to previous scenario.

Figure – 4.4.1 Successful Transmission Comparison Chart.

4.4.2 Packet Delivery Probability

Figure – 4.4.2 Average Packet Delivery Probability Comparison Chart.

0.9820.9840.9860.988

0.990.9920.9940.9960.998

1

DirectDelivery -without

BRTS

DirectDelivery -with BRTS

Epidemic -without

BRTS

Epidemic -with BRTS

Spray AndWait -

withoutBRTS

Spray AndWait - with

BRTS

0.996

1

0.98950.9886

0.9949

0.9892

Tran

smis

sio

n R

atio


Successful Transmission Ratio

0

0.2

0.4

0.6

0.8

1


BRTS


Epidemic -without

BRTS

Epidemic -with BRTS

Spray AndWait -

withoutBRTS


BRTS

0.2068

0.547

0.9588 0.9827

0.6054

0.9226

Ave

rage

PD

F


Packet Delivery Probability


72

From the Figure – 4.4.2, it can be conclude that improvement is noticed in each routing

protocols as compared to previous scenario in terms of packet delivery probability. But

especially in Direct Delivery and Spray and Wait routing improvement is excellent.

4.4.3 Channel Overhead Ratio

From the Figure – 4.4.3, it can be analysed that channel overhead ratio is decreased for Spray

and Wait routing as compared to previous scenario. Which is the improvement in the

performance of it. But for the Epidemic routing the channel overhead ratio is increased as

compare to previous scenario.

Figure – 4.4.3 Channel Overhead Ratio Comparison Chart.

4.4.4 Average Latency

A tremendous degradation is noticed in average latency for each routing protocols s compare

to previous scenario which indicates the improvement in performance.

0

500

1000

1500

2000

2500


BRTS


Epidemic -without

BRTS

Epidemic -with BRTS

Spray AndWait -

withoutBRTS


BRTS

0 0

1253.1933

2195.777

8.2095 5.3955Ove

rhe

ad R

atio




73

Figure – 4.4.4 Average Latency Comparison Chart.

4.4.5 Average Hop Count

From the Figure – 4.4.5, it can be noticed that the total number of hops required for

successful transmission is decreased by two hops in Epidemic routing as compared to

previous scenario. But at a same time it is increased by one in Spray and Wait routing.

Figure – 4.4.5 Average Hop Count Comparison Chart.

4.4.6 Average Message Buffer Time

From the Figure – 4.4.6 it can be noticed that average buffer time for message is decreased

almost 50 % as compared to previous scenario in Epidemic routing. But no improvement is

010002000300040005000600070008000


BRTS


Epidemic -without

BRTS

Epidemic -with BRTS

Spray AndWait -

withoutBRTS

Spray AndWait -

with BRTS

7469.88456593.8524

1442.4828589.0184

6331.3442

2537.5732

Ave

rage

Lat

en

cy


Average Latency

0

2

4

6

8


BRTS


Epidemic -without

BRTS

Epidemic -with BRTS

Spray AndWait -

withoutBRTS


BRTS

1 1

8

6

23

Ho

p C

ou

nt


Average Hop Count

Performance Analysis for Different Routing Protocols in VDTN for SURAT City

74

noticed for Direct Delivery and Spray and Wait routing in terms of average message buffer

time. In next session we have done simulations for the variations of different transmission

rate.

Figure – 4.4.6 Average Message Buffer Time Comparison Chart.

4.5 Performance Analysis for Different Routing Protocols in VDTN for

SURAT City

Performance analysis done for four protocols Direct Delivery, Epidemic, PRoPHET and

Spray and Wait. For each protocol report generated of delivery probability and overhead

ratio for different transmission data rate (100kB, 200kB, 300kB, 400kB, and 500kB).

Figure - 4.5.1 Delivery probability vs. Transmission data rate graph for analysis

0

5000

10000

15000

20000


BRTS


Epidemic -without

BRTS

Epidemic -with BRTS

Spray AndWait -

withoutBRTS


BRTS

17970.7475 17970.7689

6181.1668

3343.9285

17891.2109 17916.2721

Me

ssag

e B

uff

er

Tim

e



0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

100 200 300 400 500

Del

iver

y P

robab

ilit

y

Transmission DataRate (kBps)

DirectDelivery

Epidemic

PRoPHET

SprayAndWait


75

Table - 4.5.1 Delivery probability vs. Transmission data rate resultant data

Transmission

Data Rate


Direct Delivery Epidemic PRoPHET SprayAndWait

100 kB 0.0172 0.1817 0.1588 0.5409

200 kB 0.0254 0.1939 0.1882 0.6334

300 kB 0.0278 0.2079 0.2111 0.6809

400 kB 0.0311 0.216 0.1948 0.6768

500 kB 0.0336 0.2275 0.2054 0.6882

According to delivery probability graph and reported data table we can see that as in

transmission data rate increases for each protocol delivery probability going to increased and

highest delivery probability achieved for spray and wait protocol at each transmission data

rate observation point. By analysing overhead ratio graph and resultant data table, it can

observe that overhead ration changed with transmission data rate.

Figure - 4.5.2 Overhead ratio vs. Transmission data rate graph for analysis

For Direct Delivery protocol overhead ratio is zero but it gives us lowest delivery probability.

Epidemic and PRoPHET Protocols give somewhat more delivery probability than Direct

0

50

100

150

200

250

300

350

100 200 300 400 500

Over

hea

d R

atio

Transmission DataRate (kBps)

DirectDelivery

Epidemic

PRoPHET

SprayAndWait

Simulation Result for Performance Enhancement

76

Delivery protocol but both generate larger overhead ratio, which is not suitable for real time

application.

Table - 4.5.2 Overhead ratio vs. Transmission data rate resultant data.

Transmission

Data Rate

Overhead Ratio

DirectDelivery Epidemic PRoPHET SprayAndWait

100 kB 0 129.491 131.5155 5.8487

200 kB 0 223.6709 204.9174 6.7171

300 kB 0 270.6929 220.1512 6.607

400 kB 0 302.8106 271.6849 6.763

500 kB 0 298.7266 273.7012 6.7432

From these four protocols Spray and Wait is only one protocol that provides highest delivery

probability as well as lowest overhead ratio, which is most suitable for real time application.

All this happened due to increased transmission data rate. As transmission data rate increased

number of successful message transmission per second increased even in short contact

duration also. As number of successful message transmission per second increased, there is

increment in delivery probability and variation in overhead ratio. Because of this

observation and theoretical concept

4.6 Simulation Result for Performance Enhancement

As given in previous section I choose Spray and Wait protocol for dissertation and my

objective is again to improve performances of VDTN through increasing delivery probability

and reducing overhead ratio.

According to [85] delivery probability and overhead ratio will changed if number of copies

of message varies in spray and wait protocol in both normal and binary mode. In this thesis

we used same concept for improving performances of VDTN.

First we worked with normal mode of spray and wait protocol, using Random Way Point

movement model and measured delivery probability and overhead ratio for the different

number of copies(6,8,10,12,14,16,18,20).


77

Figure - 4.6.1 Delivery Probability vs. No. of copies graph for Spray and Wait protocol in normal

mode

Table - 4.6.1 Delivery Probability vs. No. of copies resultant data for Spray and wait

protocol in normal mode.

Then we changed movement model applying Map Based movement model and again

produced report for delivery probability and overhead ratio for the above different number

of copies. Observation is that delivery probability increased and overhead ratio reduced. This

occurred because of characteristics of Map Based movement model as given in [87]. In this

0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

6 8 10 12 14 16 18 20

De

livar

y P

rob

abili

ty

No. of copies

Spray and wait in Normal mode

RandomWayPointMovement

MapBased Movement

Shortestpath MapBasedMovment

No. of Copies


RandomWayPoint

Movement MapBased Movement

ShortestPathMapBased

Movement

6 0.0264 0.6104 0.9168

8 0.0255 0.6606 0.9308

10 0.0255 0.696 0.944

12 0.0255 0.7348 0.9481

14 0.0255 0.7488 0.9506

16 0.0255 0.7545 0.9506

18 0.0255 0.7669 0.9506

20 0.0255 0.7751 0.9514


78

movement model node contact will increased because all nodes are moving on the predefined

map based path instead of random manner, in which number of contact reduces due to

randomness movement nature of nodes.

Figure - 4.6.2 Delivery Probability vs. No. of copies graph for Spray and Wait protocol in binary

mode

Table - 4.6.2 Delivery Probability vs. No. of copies resultant data for Spray and Wait

protocol in binary mode.

No. of Copies


RandomWayPoint

Movement

MapBased

Movement


Movement

6 0.0288 0.6038 0.9259

8 0.0313 0.6713 0.9432

10 0.0321 0.715 0.9481

12 0.0329 0.7446 0.9506

14 0.0329 0.7702 0.9539

16 0.0338 0.7875 0.9572

18 0.0346 0.8056 0.9572

20 0.0329 0.813 0.9596

0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

6 8 10 12 14 16 18 20

De

livar

y P

rob

abilt

y

No. of copies

Spray and Wait in Binary Mode


MapBased Movement

Shortestpath MapBasedMovement


79

Again if we apply ShortestPathMapBased movement model for above same case, again

delivery probability increased and overhead ratio reduced. This happened because in this

movement model all nodes move according to map based as well as choose shortest path

among all available path between sources to destination. So number of contact increased as

well as sources to destination distances is also reduced, so number of message transmission

per second increased.

Now as applied all above cases with binary mode, as per belief we achieved increased

delivery probability and reduced overhead ratio, for all three cases of my VDTN program.

This was happened because of binary mode spray and wait concept as given in [83]. In binary

mode spray and wait protocol source node generate initially L copies: any node A that has

n>1 message copies (source or relay), and encounters another node B (with no copies), hand

over to B n/2 and keeps n/2 for itself, this process is repeated until single copy left within

node. While in normal mode source node transfer (n-1) copies to all n-1 encounter nodes, in

this message dropping probability going to increased nodes movement are not toward

destination. Source node has to again regenerate n copies if no one node has been successful

in transmitting message to destination.

Figure - 4.6.3 Overhead ratio vs. No. of copies graph for Spray and Wait protocol in normal mode

0

10

20

30

40

50

60

6 8 10 12 14 16 18 20

Ove

rhe

ad R

atio

No. of copies

Spray and wait in Normal mode


MapBased Movement



80

Table - 4.6.3 Overhead ratio vs. No. of copies resultant data for Spray and Wait

protocol in normal mode

No. of Copies

Overhead Ratio

RandomWayPoint


ShortestPath

MapBased Movement

6 55.875 8.0621 5.4007

8 57.9677 10.3666 7.4336

10 58.0323 12.555 9.4031

12 58.0323 14.4428 11.4188

14 58.0323 16.6205 13.4428

16 58.0323 18.8253 15.4957

18 58.0323 20.754 17.5381

20 58.0323 22.6344 19.561

Figure - 4.6.4 Overhead ratio vs. No. of copies graph for Spray and wait protocol in binary mode.

This will increase overhead ratio and transmission time. Increasing in transmission time

affects delivery probability. This all thing was not happened in binary mode spray and wait

protocol, so it provides better results than normal mode spray and wait.

0

10

20

30

40

50

60

70

80

90

6 8 10 12 14 16 18 20

Ove

rhe

ad R

atio

No. of copies

Spray and Wait in Binary Mode


MapBased Movement



81

Table - 4.6.4 Overhead ratio vs. No. of copies resultant data for Spray and Wait

protocol in binary mode

No. of

Copies

Overhead Ratio

RandomWayPoint



Movement

6 66.8 8.1378 5.3265

8 67.2308 10.2393 7.3153

10 71.4359 12.3053 9.3284

12 73.275 14.4049 11.364

14 77.925 16.4139 13.3705

16 78.2683 18.4843 15.3744

18 79.381 20.3916 17.401

20 85.675 22.5532 19.376

From above all graph and result of figure 4.6.1, figure 4.6.2, figure 4.6.3, figure 4.6.4, and

table 4.6.1, table 4.6.2, table 4.6.3, table 4.6.4, it can be observe that binary spray and wait

protocol with 6 message copies provides lowest overhead ratio in my VDTN than 20

message copies with appropriate delivery probability. While binary spray and wait protocol

with 20 copies provides highest delivery probability in VDTN than 6 message copies with

tolerable overhead ratio.

All applications which mainly focus on delivery probability and ignoring overhead ratio in

VDTN, binary mode spray and way protocols with ShortestPathMapBased movement with

20 message copies gives better result. The applications which mainly focus on overhead ratio

and ignoring delivery probability in VDTN, binary mode spray and way protocols with

ShortestPathMapBased movement with 6 message copies gives better result.

4.7 Simulation Result for Performance Assessment of Improved VDTN

in Node Variation Environment

In any network scenario, the number of nodes on the network was changed; it will affect

performance of the network. Main objective behind these simulations is to evaluate the

performance of the improved VDTN network with designed scenario as derived in section

4.6, in different number of node environment.

Simulation Result for Performance Assessment of Improved VDTN in Node Variation Environment

82

Figure - 4.7.1 Delivery Probability vs. No. of Nodes graph in Node variation environment

Table - 4.7.1 Delivery Probability vs. No. of Nodes resultant data in Node variation

environment

Number of Nodes Delivery Probability

6 copies 20 copies

100 0.6631 0.71

200 0.9267 0.9646

300 0.9226 0.9596

400 0.9259 0.9662

500 0.916 0.9662

Simulation result for performance assessment will obtained by running simulation with

different number of node case like 100,200,300,400,500 for both 6 message copies and 20

message copies. This number of node range is above and below my decided threshold value

of number of node i.e. 290 for performances enhancement. How number of node variation

affect the delivery probability and overhead ratio for both cases, these all shown in

simulation result graph and resultant data table.

As concentrating on graph and resultant data, we observed that for 100 number of node

network environment. Lower delivery probability and higher overhead ratio obtained than

in section 4.6 derived probabilities and overhead ratio respectively. It means that if small

0.6

0.65

0.7

0.75

0.8

0.85

0.9

0.95

1

100 200 300 400 500

De

livar

y P

rob

abili

ty

No. of Nodes

6 copies

20 copies


83

number of nodes in network will reduced delivery probability and increased overhead ratio.

This will happened because VDTN performance is characterized by opportunistic contacts,

where end to end connectivity may not exist and intermittent connectivity is common. In this

case small number of nodes will create less number of contacts, which will reduce the

successful transmission of message and also increases retransmission condition. These all

things reduced delivery probability and increased overhead ratio. For all other number of

nodes cases no much more variation in delivery probability and overhead ratio. That means

that whatever improved VDTN network is worked well if number of nodes either 200 or

higher than 200.

Figure - 4.7.2 Overhead Ratio vs. No. of Nodes graph in Node variation environment

Table - 4.7.2 Overhead Ratio vs. No. of Nodes resultant data in Node variation

environment

Number of Nodes Overhead Ratio

6 copies 20 copies

100 7.2609 22.2668

200 5.3004 19.1127

300 5.3705 19.3416

400 5.3488 19.3265

500 5.4074 19.3896

5

7

9

11

13

15

17

19

21

23

100 200 300 400 500

Ove

rhe

ad R

atio

No. of Nodes

6 copies

20 copies

Simulation Results for Performance Assessment of Improved VDTN in Traffic Variation Environment

84

4.8 Simulation Results for Performance Assessment of Improved VDTN

in Traffic Variation Environment

Now in this section we evaluated performance of designed improved VDTN network in

various traffic conditions. Here we run simulation and derived graphs for delivery

probability and overhead ratio for both cases, with 6 message copies and 20 message copies

in various traffic conditions like 1 new message in each 0-5 sec, 5-15 sec, 15-25 sec, 25-35

sec, 35-45 sec interval.

Figure - 4.8.1 Delivery Probability vs. Message Traffic graph in Traffic variation environment

Table - 4.8.1 Delivery Probability vs. Message Traffic resultant data in Traffic

variation environment

Message Traffic(1 New message

per time interval)

Delivery probability

6 copies 20 copies

0-5 sec 0.9055 0.852

5-15 sec 0.9201 0.9596

15-25 sec 0.9198 0.9624

25-35 sec 0.9259 0.9596

35-45 sec 0.9206 0.9636

As per observation from all graph and resultant data table for both 6 message copies and 20

message copies, it is found that in heavy traffic condition with 20 message copies, delivery

probability poor but overhead ratio is better. Except this case in all other traffic condition

cases both 6 message copies and 20 message copies cases have tolerable variation in delivery

0.8

0.82

0.84

0.86

0.88

0.9

0.92

0.94

0.96

0.98

0-5 sec 5-15 sec 15-25 sec 25-35 sec 35-45 sec

De

livar

y P

rob

abili

ty

Message Traffic (1 New message per time interval)

6 copies

20 copies


85

probability and overhead ratio. That means that my designed improved VDTN network will

work well with variable traffic condition except one discussed case.

Figure - 4.8.2 Overhead Ratio vs. Message Traffic in Traffic variation environment

Table - 4.8.2 Overhead Ratio vs. Message Traffic resultant data in Traffic variation

environment

Message Traffic(1 New message

per time interval)

Overhead Ratio

6 copies 20 copies

0-5 sec 5.4116 14.4974

5-15 sec 5.3657 19.345

15-25 sec 5.3663 19.3031

25-35 sec 5.3265 19.376

35-45 sec 5.3928 19.3707

4.9 SUMMARY

In this chapter there is one way to improved performance of VDTN network. Another way

is if we modify protocol according to our requirement than we again get improvement in

performance of VDTN. Using this way we can enhanced performance of VDTN in

satisfactory manner but if we combined both, means enhancement of performances

parameter as well as modify existing protocol then we can get excellence in performance

enhancement of VDTN network. This is reason which persuades me for working for chapter

5.

5

7

9

11

13

15

17

19

0-5 sec 5-15 sec 15-25 sec 25-35 sec 35-45 sec

Ove

rhe

ad R

atio

Traffic condition(1 New message per time interval)

6 copies

20 copies

Difference with Existing Binary Mode Spray And Wait Protocol

86

CHAPTER 5

MODIFICATION IN EXISTING PROTOCOL

5.1 Difference with Existing Binary Mode Spray And Wait Protocol

As per previous chapter discussion to enhance performances of VDTN one way is by

enhancing performance parameter using modifying value of design parameter and another

is by modifying existing protocol. In dissertation I choose spray and wait protocol for

performances enhancement, because of its simplicity and efficiency characteristic with

limited number of message copies. As per previous chapter discussion now I going to modify

existing spray and wait protocol and will apply this modified spray and wait protocol to my

derived improved VDTN network. This will give me more performance enhancement of

VDTN.

In existing binary spray and wait protocol the source of a message initially starts with L

copies. When it encounter first node with no copies then it handover (L/2) copies to that

node and keeps (L/2). Now this process is repeated for both source and relay that has L>1

message copies and when the node either is left with only one copy, it switches to wait phase

and wait till the direct transmission to the destination.

According to this it can say that in existing binary spray and wait when node encounter node

with no copies than it handover 50% copies to that node and keeps 50% . This process is

repeated. In modify spray and wait I changed this 50-50 % ratio with 70-70% and 80-80%.

This modification detail information is given in next section. Because of this modification

more number of message copy are spread in network for each new generated message. This

will increase chances of successful transmission and that will increased delivery probability.


87

5.2 Algorithm and Explanation of Algorithm

This section contain information regarding algorithm for both 70-70% modification ratio

and 80-80% modification ratio and flowchart for same given below.

Figure - 5.2.1 Algorithm for the modification in spray and wait protocol.

No

Store initial

no.of copies

Any node

encounter ?

Transfer 70%(80%) of message

copies to encounter node

Set remaining message copies of

Source(Relay) node to 70%(80%)

Source(Relay)

node still

contain no. of

message copies

Direct transfer message copies to

destination.

Yes

Yes

No

Simulation Results of Improved VDTN with Modified Spray And Wait Protocol

88

Algorithm

1) Set variable with initial number of copies

2) Check whether any node encounter

3) If yes

Transfer 70% or 80% of message copies to encounter node and

Set source/relay node contained message to 70% or 80% by setting number

of copies variable.

4) Else Go to step 5

5) Check whether source/relay node contain number of message copies > 1

6) If yes

Repeat step from 2 to 4

7) Else Direct transfer copy to destination only

In modify spray and wait protocol 1 (modified with 70-70 % ratio) and modify spray and

wait protocol 2 (modified with 80-80 % ratio) both have modification in java program

according to above given algorithm only in some portion only , reaming part of program as

per existing spray and wait protocol programs. In this algorithm to set source /relay node

contained copy initial number of copies stored into variable before transfer, then transfer

70% or 80% copies to encounter node and after transfer process number of message copies

variable adjust according to 70 % or 80 % of initial stored value. In this way both

source/relay as well as encounter node both contain 70% or 80% message copies

respectively.

5.3 Simulation Results of Improved VDTN with Modified Spray And

Wait Protocol

I run simulation same program designed for performance enhancement purpose, with

modified spray and wait protocol for 70-70% ratio and 80-80% ratio. The simulation

parameter environment remains same as given in section 4.3 Table 4.3.2. I measured delivery


89

probability and overhead ratio for different number of message copies and implement graph

as shown in figure 5.3.1 and 5.3.2 in comparison form.

Figure - 5.3.1 Delivery Probability vs. No. of Message copies graph for modify spray and wait

protocols with compare to existing binary spray and wait protocol.

If we concentrated on delivery probability vs. number of message copies graph and resultant

data table then we can observed that whatever delivery probability obtained with 8 message

copies in existing binary spray and wait, that was obtained in modify spray and wait for 70-

70% ratio with 6 message copies and whatever delivery probability obtained with 18

message copies in existing binary spray and wait that was obtained in modify spray and wait

for 80-80% ratio with 6 message copies.

Table - 5.3.1 Delivery Probability vs. No. of Nodes resultant data for modify spray

and wait protocols with compare to existing binary spray and wait protocol

No. of Message

copies


Binary SaW Modify SaW (70-70

%)

Modify SaW (80-80

%)

6 0.9259 0.9432 0.9572

0.91

0.92

0.93

0.94

0.95

0.96

0.97

6 8 10 12 14 16 18 20

Del

iver

y P

rob

ab

ilit

y

No. of Message Copies

Binary SaW

Modify SaW(70-70 %)

Modify SaW(80-80 %)


90

8 0.9432 0.9572 0.9629

10 0.9481 0.9572 0.9679

12 0.9506 0.9629 0.9662

14 0.9539 0.9629 0.9662

16 0.9572 0.9629 0.9423

18 0.9572 0.9679 0.9423

20 0.9596 0.9679 0.9349

Figure - 5.3.2 Overhead Ratio vs. No. of Message copies graph for modify spray and wait protocols

with compare to existing binary spray and wait protocol.

This same thing occurred in case of overhead ratio vs. number of message copies result also.

From all this discussion it can be declared that modify spray and wait protocol for both ratios

provides higher probability with lowest number of message copies, and it required small

memory in buffer means saving of buffer memory.

After having a look of above results it is clear that modified protocol is working fine for the

map of Surat city. But, for the testing of the modification some more simulations were done

for the map of Chennai city.

0

50

100

150

200

250

6 8 10 12 14 16 18 20

Ov

erh

ead

Ra

tio

No. of Message Copies

Binary SaW

Modify SaW(70-70 %)

Modify SaW(80-80 %)


91

In this simulations we have done an exhaustive simulation for comparison. We have changed

the number of nodes for the map. We have also changed the number of buffer in every node.

We have also given variation in the movement of the nodes. And in each variation the

modified protocol is tested.

Table - 5.3.2 Overhead Ratio vs. No. of Nodes resultant data for modify spray and

wait protocols with compare to existing binary spray and wait protocol

Figure - 5.3.3 Comparison of Delivery probability for different routing protocol with different

buffer size and different mobility movement model.

No. of Message

copies

Overhead Ratio

Binary SaW Modify SaW (70-70

%)

Modify SaW (80-80

%)

6 5.3265 7.3153 15.3744

8 7.3153 15.3744 31.4209

10 9.3284 15.3744 62.8111

12 11.364 31.4209 124.0904

14 13.3705 31.4209 124.0904

16 15.3744 31.4209 200.5787

18 17.401 62.811 200.5787

20 19.376 62.811 223.874

0.9

751

0.8

08

0.0

475

0.9

632

0.6

259

0.0

249

0.9

6

0.7

234

0.0

33

0.9

24

0.5

926

0.0

202

0.9

42

0.7

447

0.0

368

0.9

074

0.5

891

0.0

238

0.7

7

0.3

907

0.0

107

0.6

342

0.2

957

0.0

059

0.2

0.1

615

0.0

214

0.1

473

0.1

14

0.0

1310

.17

0.1

544

0.0

3 0.1

057

0.0

92

0.0

19

B U F F E R S I Z E 4 B U F F E R S I Z E 2

DELIVERY PROBABILITY

Spray and Wait $1 Spray and Wait Spray and Wait Binary

Direct Delivery PROPHET EPIDEMIC

MBM RWP SPMBM SPMBM MBM RWP


92

In Figure 5.3.3, we have made a comparison of different routing protocols. For this

assessment we have varied the number of buffer in each node. At the same time for more

proper outcome we have varied the movement mobility model, too. By looking at this figure

we have judged that for Random Way Point movement model (RWP), the modified protocol

is not assuring proper outcome. But, for Map-Based Movement model (MBM) and Shortest

Path Map-Based Movement (SPMBM) model, the modified protocol is working very nicely.

It is providing 0.1% of improvement in the delivery probability, which is a good amount of

improvement for the large number of data packets.

Figure 5.3.4, is showing the comparisons of the overhead ratio of the same network, under

the same scenario. All the parameters are same in this case. We can observe that the modified

version of the protocol is performing well in terms of overhead ratio. And that, too is because

the protocol is not having any space to transmit more and more packets. For the buffer size

of 2, modified protocol is having overhead ratio more compare to binary spray and wait. But,

for SPMBM for both cases modified protocol is providing better overhead ratio compare to

epidemic and PROPHET protocol.

Figure - 5.3.4 Comparison of overhead ratio for different routing protocol with different buffer

size and different mobility movement model.

Now, next we would like to have a brief look for the comparison of buffer time. This

phenomena is basically shows how much time a packet is lying ideal in the queue. So, for

7.1

23

8.5

9

75.9

7.2

392

11.0

93

122.3

3

5.1

6

4.0

15

60.0

7

3.2

404

5.0

441

85.3

5

3.1

7

4 60.4

516

3.2

997

5.0

645

83.2

0 0 0 0 0 0

5043

3110

1215

5189.4

597

3122.2

5

152.2

7

6391

3671.9

3 5305

8336.2

58

4470.6

2

264.4

3

B U F F E R

S I Z E 4

B U F F E R

S I Z E 2

OVERHEAD RATIOSpray and Wait $1 Spray and Wait Spray and Wait Binary

MB

MM

RW

PP

SPMB

MSPM

BM

MB

MRW

PP


93

the performance evaluation of different routing protocols, this criteria must be taken care.

This leads us to the Fig 5.3.4, which shows the buffer time comparison for the same scenario.

From this graph we can say that, buffer time of the modified protocol is less compared to

traditional routing protocol of DTN.

By looking at all these results it is clear that proposed modification of Spray and Wait routing

protocol is performing better in terms of Delivery Probability, Overhead Ratio and Buffer

time.

Figure - 5.3.5 Comparison of Buffer time for different routing protocol with different buffer size

and different mobility movement model.

5.4 SUMMARY

By looking all the above results we can conclude here, that if we want to improve the network

efficiency of VDTN network. We can implement it with suggested algorithm. This will lead

us to have a fully utilization of available network.

MBM RWP SPMBM SPMBM MBM RWP

7152.8

2

7125 8

911

3189

3211.0

3

5276.6

4

8871

11407

11067

4489

5421.7

3

6668

11299

11362

11267

5314

5461.7

6

6462

15259

15498

15923

7481

7906

8679

62.6

3

125.4

6

6448

42.3

1

86.2

4603

58

118.5

523

5305

42

86.6

4

3511

B U F F E R

S I Z E 4

B U F F E R

S I Z E 2

BUFFER TIME

Spray and Wait $1 Spray and Wait Spray and Wait Binary

Direct Delivery PROPHET EPIDEMIC

Result Analysis in Terms of Delivery Probability for Modified Spray And Wait Protocol in Different Scenarios

94

CHAPTER 6

RESULT ANALYSIS, CONCLUSION AND

FUTURE SCOPE

In this chapter we have presented simulation results for comparison. We have kept all three

variations of Spray and Wait algorithm in test bench. We have varied number of copies,

number of buffer unit and different movement model. First we will observe performance of

protocols in terms of Delivery Probability. Than we will observe Buffer time comparison.

And at the end we will discuss performance in terms of Overhead Ratio.

6.1 Result Analysis in Terms of Delivery Probability for Modified Spray

And Wait Protocol in Different Scenarios

In previous section we have seen that for the buffer size of 2 and 4 our modified Spray and

Wait Protocol is providing better performance. As we know, now a days there is a large

capacity of each node in terms of the buffer size, we did some simulations in which we have

varied the buffer size. This variation affected the result as shown in the following figures.

In Fig 6.1.1, we have kept the buffer size 2, and performed the simulation. By watching at

this graph we have observed that if we are increasing the number of copies at the sender,

modified protocol is not performing well. This is due to unavailability of the buffer at the

neighbouring node.

RESULT ANALYSIS, CONCLUSION AND FUTURE SCOPE

95

Figure - 6.1.1 Comparison of Delivery Probability for Modified SW, Binary SW and SW Normal

for varying number of copies of message and buffer size 2.


for varying number of copies of message and Buffer size 5.

Now, we have done the same experiment with the increasing number of buffer size and kept

it to 5. Fig 6.1.2 shows the comparison of the delivery probability, by varying number of

copies. In this we can see, modified protocol is having comparatively higher delivery

probability for less number of copies. As we increase the number of copies of message, once

again due to flooding effect modified protocol is failing.

2 4 6 8 10 12 14 16 18 20

SW N 0.8349 0.924 0.9489 0.962 0.9608 0.9691 0.9703 0.9715 0.9691 0.9667

SW B 0.8349 0.9074 0.9537 0.9632 0.9679 0.9691 0.9691 0.9739 0.9751 0.9727

SW Mod 0.8349 0.9632 0.9739 0.9139 0.9323 0.8409 0.8409 0.76 0.76 0.6817

0

0.2

0.4

0.6

0.8

1

1.2

Deli

very

Pro

babil

ity

Number of Copies

Delivery Probability When Buffer Size is 2

SW N SW B SW Mod

2 4 6 8 10 12 14 16 18 20

SW N 0.8967 0.9489 0.9644 0.9715 0.9762 0.9773 0.9786 0.9792 0.9796 0.981

SW B 0.8967 0.9466 0.9656 0.9762 0.9822 0.9829 0.9834 0.9842 0.9844 0.9846

SW Mod 0.8967 0.9762 0.9846 0.9869 0.9881 0.9881 0.9881 0.9763 0.9584 0.9584

0.84

0.86

0.88

0.9

0.92

0.94

0.96

0.98

1

Deli

very

Pro

babil

ity

Number of Copies


SW N SW B SW Mod

Result Analysis in Terms of Delivery Probability for Modified Spray And Wait Protocol in Different Scenarios

96



In Fig 6.1.3 we have taken buffer size 10. In this graph we can see that the modified protocol

is not facing any problem. Now a days there are no limitations of buffer size at any level.

This modification is giving comparatively better performance. Same results we can see for

the higher number of buffer size. We have taken buffer size 20 in Fig 6.1.4 and observed the

same thing.

In the next section we will discuss the effect of change of number of copies and buffer size

on Buffer time of all three protocols.



2 4 6 8 10 12 14 16 18 20

SW N 0.8967 0.9489 0.9644 0.9715 0.9751 0.9762 0.9768 0.9768 0.9798 0.9798

SW B 0.8967 0.9466 0.9656 0.9762 0.9822 0.9834 0.9834 0.9846 0.9846 0.9846

SW Mod 0.8967 0.9762 0.9846 0.9869 0.9881 0.9881 0.9881 0.9893 0.9893 0.9893

0.84

0.86

0.88

0.9

0.92

0.94

0.96

0.98

1

Deli

very

Pro

babil

ity

Number of Copies


SW N SW B SW Mod

2 4 6 8 10 12 14 16 18 20

SW N 0.8967 0.9466 0.9644 0.9652 0.9751 0.9763 0.9786 0.9787 0.979 0.9798

SW B 0.8967 0.9489 0.9656 0.9762 0.9822 0.981 0.9834 0.9846 0.9846 0.9846

SW Mod 0.8967 0.9762 0.9846 0.9857 0.9881 0.9886 0.9893 0.9884 0.9873 0.9869

0.85

0.9

0.95

1

Deli

very

Pro

babil

ity

Number of Copies


SW N SW B SW Mod


97

6.2 Result Analysis in Terms of Buffer Time for Modified Spray And

Wait Protocol in Different Scenarios

Till now we have understood that modified protocol is good in terms of delivery probability.

Fig 6.2.1, 6.2.2, 6.2.3 and 6.2.4 will show it is also providing less buffer time. This means,

the packets are not idle in the queue of any node. There is a very less time, it has to spend in

the que of any node. Because of this the node can deliver data quickly to the destination. All

the figures are indicating improvement in this factor.

We have observed if we increase the number of copies, comparative buffer time is also

decreased. This is just because as number of copies in the network is higher one of the copy

must be in the network. This reduces buffer time for more number of copies. Modification

suggested by us is providing good performance.

Figure - 6.2.1 Comparison of Buffer time for Modified SW, Binary SW and SW Normal for

varying number of copies of message and Buffer size 2.

2 4 6 8 10 12 14 16 18 20

SW N 7248.18 5341.78 3974.55 3162.87 2619.23 2216.15 1921.91 1700.6 1523.94 1384.05

SW B 7248.18 5314.91 4005.15 3189.79 2617.21 2226.55 1931.67 1714.1 1539 1394.59

SW Mod 7248.18 3189.79 1714.1 893.97 478.763 283.443 283.443 196.197 196.197 154.89

0

1000

2000

3000

4000

5000

6000

7000

8000

Bu

ffer

Tim

e

Number of Copies

Buffer Time When Buffer Size is 2

SW N SW B SW Mod

Result Analysis in Terms of Buffer Time for Modified Spray And Wait Protocol in Different Scenarios

98





2 4 6 8 10 12 14 16 18 20

SW N 16394.7 13767.7 11082.2 8984.69 7481.77 6981.24 5546.55 4730.2 4499.12 4169.32

SW B 16394.7 13671.4 11054.4 9018.33 7496.72 6213.69 5420.3 4681.33 4239.11 4029.77

SW Mod 16394.7 9018.33 4957.09 2566.37 1305.6 932.451 662.284 523.014 361.982 253.355

0

2000

4000

6000

8000

10000

12000

14000

16000

18000

Bu

ffer

Tim

e

Number of Copies


SW N SW B SW Mod

2 4 6 8 10 12 14 16 18 20

SW N 17948.8 17880.4 17506.8 16436 14630.3 12817.1 11325 10071.8 9023.27 8196.43

SW B 17948.8 17859.5 17431.4 16311.3 14563.1 12873 11341.4 10090.7 9109.16 8295.27

SW Mod 17948.8 16311.3 10090.5 5319.32 2716.41 1372.04 970.625 690.051 690.051 402.61

0

2000

4000

6000

8000

10000

12000

14000

16000

18000

20000

Bu

ffer

Tim

e

Number of Copies


SW N SW B SW Mod


99



6.3 Result Analysis in Terms of Overhead Ratio for Modified Spray And

Wait Protocol in Different Scenarios

Fig 6.3.1, 6.3.2, 6.3.3 and 6.3.4 are showing comparison of the overhead ratio. These figures

are showing the drawback of the modification. This shows, more number of copies will

overburdened network. Due to more number of copies the senders are being aggressive to

deliver their data. This leads to the more and more unnecessary transmissions. But for the

performance point of view given modification is appropriate. So, this draw back may be

neglected.

2 4 6 8 10 12 14 16 18 20

SW N 17958.5 17938.8 17921.4 17910.3 17891.7 17796.4 17756.4 17407.4 16543.2 15808.1

SW B 17958.5 17943.1 17930 17920.6 17910.5 17832.7 17769.3 17413.4 16643.2 15872.3

SW Mod 17958.5 17921 17413.4 11650.3 5523.8 4632.56 2792.29 1402.29 1139.5 717.89

0

2000

4000

6000

8000

10000

12000

14000

16000

18000

20000

Bu

ffer

Tim

e

Numer of Copies

Buffer Time When Buffe Size is 20

SW N SW B SW Mod

Result Analysis in Terms of Overhead Ratio for Modified Spray And Wait Protocol in Different Scenarios

100





2 4 6 8 10 12 14 16 18 20

SW N 1.1949 3.2404 5.2516 7.2432 9.3018 11.2377 13.2583 15.2311 17.2402 19.23

SW B 1.1949 3.2997 5.2217 7.2392 9.2282 11.239 13.2706 15.2341 17.1778 19.21

SW Mod 1.1949 7.2392 15.2341 31.0317 62.7032 119.69 119.69 193.031 193.031 276.578

0

50

100

150

200

250

300

Axis

Tit

le

Axis Title

Overhead Ratio When Buffer Size is 2

SW N SW B SW Mod

2 4 6 8 10 12 14 16 18 20

SW N 1.1126 3.1564 5.1712 7.1791 9.1813 11.269 13.2015 15.963 18.236 19.2203

SW B 1.1126 3.1631 5.1574 7.1436 9.0967 11.06 13.0845 15.712 18.347 19.027

SW Mod 1.1126 7.1436 15.0856 30.9061 62.2945 86.024 124.295 165.326 246.32 337.539

0

50

100

150

200

250

300

350

400

Axis

Tit

le

Axis Title


SW N SW B SW Mod


101





2 4 6 8 10 12 14 16 18 20

SW N 1.1126 3.1564 5.1712 7.1797 9.19 11.2105 13.2 15.2269 17.2267 19.2436

SW B 1.1126 3.1631 5.157 7.1436 9.0967 11.0821 13.0845 15.0856 17.0434 19.0277

SW Mod 1.1126 7.1436 15.0856 30.9061 62.3017 124.599 124.599 248.07 248.07 424.265

0

50

100

150

200

250

300

350

400

450

Axis

Tit

le

Axis Title


SW N SW B SW Mod

2 4 6 8 10 12 14 16 18 20

SW N 1.1126 3.156 5.1712 6.235 9.19 11.832 13.21 15.23 18.645 19.24

SW B 1.1126 3.1631 5.1574 6.134 9.1 11.365 13.085 15.08 18.214 19.03

SW Mod 1.1126 7.1436 15.09 29.541 62.31 86.35 124.65 248.93 360.74 484.65

0

100

200

300

400

500

600

Axis

Tit

le

Axis Title


SW N SW B SW Mod

CONCLUSION

102

6.4 CONCLUSION

The main motive of this thesis work is to apply the concept of Delay Tolerant Network

(DTN) over any Vehicular Network (VNET) and advocate the performance of several DTN

routing protocols over it. To fulfil this aim, a Vehicular Delay Tolerant Network (VDTN)

scenario is generated based on the traffic data of Surat city and Chennai city. The main

intention for considering the traffic of Surat city for the implementation of VDTN is that the

Surat is now can be placed in the category of metro city. As like in Chennai, now in Surat

city also a BRTS project is under construction. So, traffic of Surat city can be considered as

the best reference traffic for implementation of any Vehicular Network.

In this dissertation work, two strategies are implemented and simulated separately. In first

implementation strategy the BRTS traffic is excluded and in second strategy it is included

but with the consideration that each vehicle takes the shortest path to reach its destination

and each city bus and BRTS bus strictly follow their assigned routes. So, after analysing and

comparing all the simulation results it can be conclude that by applying the DTN concept it

is possible to make an ideal vehicular network. Especially in comparison of DTN routing

protocols it can be noticed that Epidemic routing and Spray and Wait routing performs very

well as compared to Direct Delivery routing. In depth comparison of Epidemic and Spray

and Wait routing pointing that Epidemic routing can able to provide best packet delivery

factor but though it is the flooding based approach it generates large number of copies in

network which further generates more congestion and packet traffics in network. Whereas

Spray and Wait routing protocol is the combination of Epidemic and Direct Delivery routing

protocols. In spray phase it floods L (where L is the specific number) number of message

copies in network and in the wait state it waits for the successful delivery of those messages.

Though L indicates the limited amount of message copies, it generates less amount of traffic

in the network. But contrary fact is that in Spray and Wait routing the average latency and

message buffer time is so much higher as compared to Epidemic routing.

Till today, so many improvement in Ad-hoc routing protocols are proposed to improve their

performance for vehicular network, but still the real time implementation of vehicular

network is infancy. Because the key reason is that vehicular network faces a unique problem.

Because of the non-uniform motion of the vehicles, a vehicular network is a highly

partitioned network. Due to the intermittent connectivity between two vehicles, all the ad-

hoc routing protocols fail to provide the acceptable performance. To judge this fact, two


103

separate simulations are carried out. In first simulation a random way point mobility is

assigned to each nodes and then ad-hoc routing protocols (DSDV, AODV, DSR) and DTN

stochastic routing protocols (Direct Delivery, Epidemic, Spray and Wait) are compared in

terms of Average Packet Delivery Probability. Similarly, in second simulation, these routing

protocols are compared over Manhattan mobility model. The outcomes of these two

simulations are attached in Appendix – A. These results are also pointing that application of

DTN concept and DTN routing protocols perform far better than the ad-hoc routing protocols

over any vehicular network.

As the outcome of this thesis work shows that the performance of Vehicular Delay Tolerant

Network (VDTN) is far better than Vehicular Ad-hoc network (VANET), this thesis chapter

2 and chapter 3 can be summarized as by applying the DTN concept and by improving such

DTN routing protocols it is possible to implement an ideal vehicular network in real time

also [P5] [P4].

As per the above discussion this thesis is mainly focusing on the routing protocols of VDTN.

Chapter 4 is focused on the performance comparison of different routing protocol. In this

chapter we have done simulations on the different network scenario and fount MANET

algorithms are not performing well [P4]. In the same chapter we have done simulations with

the changes in the number of message copies. And this shows Spray and Wait protocol is

performing better than any other routing protocol of VDTN [P3].

In chapter 5 we have suggested a change in the existing protocol of VDTN, and algorithm is

regenerated. In this we suggested modification in spray and wait protocol, such that we can

have better delivery probability and buffer time. This algorithm is first tested in Surat city

map. After that we once again have tested the modified algorithm for Chennai city map [P1]

[P2].

FUTURE SCOPE

104

6.5 FUTURE SCOPE

There are different way using them we can enhance performance of VDTNs as per our

application. We can enhance performance of VDTNs using different fragmentation

mechanisms, different dropping polices, and different message forwarding techniques, using

new protocol likes GeoSpray, Spray and Focus etc.

We can also enhance performance of VDTNs by changing hardware characteristics of delay

tolerant network like placing more number of relay nodes or by enhancing characteristics of

relay nodes in network.

List of Publication

105

List of Publication

P1. Pandya Vyomal N. & Dr. Prashant M. Dolia: Performance Comparision

of Modified Spray and Wait Protocol in VDTN for Different Scenario.

International Journal of Scientific Review and Research in Engineering

and Technology (IJSRRET), Vol-1 Issue-4. May-June-2016.

P2. Pandya Vyomal N. & Dr. Prashant M. Dolia: Modification in Spray and

Wait Protocol for VDTN. IEEE conference, International Conference on

Electrical, Electronics, Signals, Communication and Optimization, Jan-

2015.

P3. Pandya Vyomal N. & Dr. Prashant M. Dolia: Delay Tolerant Network.

International Journal of Emerging Technology and Advanced

Engineering (IJEATE). Vol-3 Issue-12. Dec-2013

P4. Pandya Vyomal N. & Dr. Prashant M. Dolia: Comparative Analysis of

Different Routing Protocols in Delay Tolerant Network. International

Journal of Computer Science and Engineering Technology (IJCSET).

Vol-4 Issue-3. March-2013

P5. Pandya Vyomal N. & Dr. Prashant M. Dolia: A survey on Knowledge

based Classification of Different Routing Protocols in Delay Tolerant

Network. International Journal of Computer Science and Mobile

Computing (IJCSMC). Vol-2 Issue-3, March-2013.

REFERENCES

106

REFERENCES

[1] IEEE Standard for Information Technology- Telecommunications and Information

Exchange between Systems-Local and Metropolitan Area Networks- Specific

Requirements-Part 11: Wireless LAN Medium Access Control (MAC) and Physical

Layer (PHY) Specifications, (R-2003), ANSI/IEEE Std. 802.11, 1999 Edition, I -

513, 2003. DOI:10.1109/IEEESTD.2003.95617.

[2] Rung-Shiang Cheng, Der-Jiunn Deng.: Congestion control with dynamic threshold

adaptation and Cross Layer response for TCP Vegas over IEEE 802.11 wireless

networks, International Journal of Communication Systems, Vol: 27, No: 1, pp:

2918-2930, 2014. DOI: 10.1002/dac.2515.

[3] Jorge Navarro-Ortiz, Pablo Ameigeiras, Juan J. Ramos-Munoz, Juan M. Lopez-

Soler.: Removing redundant TCP functionalities in wired-cum-wireless networks

with IEEE 802.11e HCCA support, International Journal of Communication

Systems, Vol: 27, No: 3, pp: 3352-3367, 2014. DOI: 10.1002/dac.2546.

[4] M. Usman et. al.: Energy efficiency of TCP: An analytical model and its application

to reduce energy consumption of the most diffused transport Protocol, International

Journal of Communication Systems, 2015, DOI: 10.1002/dac.2934

[5] M. Allman, V. Paxson and E. Blanton.: TCP Congestion Control, RFC 5681, 2009.

[6] Cisco, Cisco Visual Networking Index: Forecast and Methodology 2012-2017,

White Paper, 2012.

[7] Shah P A et al.: Performance comparison of end-to-end mobility management

protocols for TCP. Journal of Network and Computer Applications, Vol: 35, No: 6,

pp: 1657-1673, 2012. DOI: 10.1016/j.jnca.2012.05.002.

[8] Dorothy A. Rambim, Mjumo Mzyece, Karim Djouani.: Cross Layer Enhancement

to Support TCP-Based Traffics in WLANs, Wireless Personal Communication, Vol:

70, pp: 1827-1840, 2013. DOI: 10.1007 /s11277-012-0783-3.

[9] AM Al-Jubari, M Othman, BM Ali and NAWA Hamid.: TCP performance in multi-

hop wireless Adhoc networks: challenges and solution, EURASIP Journal on

Wireless Communications and Networking, 2011:198, pp: 1-20, 2011. DOI:

10.1186/1687-1499-2011-198.

REFERENCES

107

[10] Ka-Cheong Leung and Victor O. K. Li.: Transmission Control Protocol (TCP) in

Wireless Networks: Issues, Approaches, and Challenges, IEEE Communication

Surveys and Tutorials, Vol: 8, No: 4, pp: 64-79, 4th Quarter 2006. ISSN: 1553-877X.

[11] Haitao Lin and Das S.K.: Performance study of link layer and MAC layer protocols

to support TCP in 3G CDMA systems, IEEE Transactions on Mobile Computing,

Vol: 4, No: 5, pp: 489-501, 2005. DOI: 10.1109/TMC.2005.70.

[12] Henderson, et al.: The Newreno Modification to TCP’s Fast Recovery Algorithm,

RFC 6582, 2012.

[13] Cai, et al.: Decoupling congestion control from TCP (semi-TCP) for multi-hop

wireless networks, EURASIP Journal on Wireless Communications and

Networking, 2013:149, 2013. DOI: 10.1186/1687-1499-2013-149.

[14] Y. C. Chan, and C. Y. Ho.: Fast retransmit and fast recovery schemes of transport

protocols: a survey and taxonomy, Computer Networks, Vol: 2, No: 6, pp: 1308-

1327, 2008.

[15] F. Foukalas, V. Gazis and N. Alonistioti.: Cross Layer design proposals for wireless

mobile networks: a survey and taxonomy, IEEE Communication Surveys and

Tutorials, Vol: 10, No: 1, pp: 70-85, 2008. DOI: 10.1109/COMST.2008.4483671.

[16] Lar S.-u., Liao X.: An initiative for a classified bibliography on TCP/IP congestion

control, Journal of Network and Computer Applications, 2012. DOI:

10.1016/j.jnca.2012.04.003.

[17] Kliazovich D, Redana S, Granelli F.: Cross Layer error recovery in wireless access

networks: The ARQ proxy approach, International Journal of Communication

Systems, Vol: 25, No: 4, pp: 461-477, 2012. DOI: 10.1002/dac.1271.

[18] Hyungsoo Jung, Shin-gyu Kim, Yeom, H.Y., Sooyong Kang and Libman L.:

Adaptive delay-based congestion control for high bandwidth-delay product

networks, Proceedings of IEEE INFOCOM, pp: 2885-2893, 10-15 April 2011. DOI:

10.1109/INFCOM.2011.5935127.

[19] David Ros and Michael Welzl.: Less-than-Best-Effort Service: A Survey of End-to-

End Approaches. IEEE Communication Surveys and Tutorials, Vol: 15, No: 2, pp:

898-908, 2013.

[20] Ting-Chao Hou, Chih-Wei Hsu and Cheng-Shong Wu.: A delay-based transport

layer mechanism for fair TCP throughput over 802.11 multihop wireless mesh

networks, International Journal of Communication Systems, Vol: 24, pp: 1015–1032,

2011. DOI: 10.1002/Dac.1207.

REFERENCES

108

[21] Lim CH, Jang JW.: Robust end-to-end loss differentiation scheme for TCP over

wired/wireless networks, IET Communication, Vol: 2, No: 2, pp: 284–291, 2008.

[22] Tian, Y., Xu, K., and Ansari, N.: TCP in Wireless Environments: Problems and

Solutions, IEEE Communications Magazine, Vol: 43, No: 3, pp: 27- 32, 2005.

[23] J. Bicket, D. Aguayo, S. Biswas, and R. Morris.: Architecture and Evaluation of an

Unplanned 802.11b Mesh Network, Proceedings of the 11th annual International

Conference on Mobile Computing and Networking, ACM Press, New York, USA.

pp: 31- 42, 2005.

[24] Mast and Owens.: A survey of performance enhancement of transmission control

protocol (TCP) in wireless ad hoc networks, EURASIP Journal on Wireless

Communications and Networking, 2011:96. 2011. DOI: 10.1186/1687-1499-2011-

96.

[25] Ahmad Al Hanbali, Eitan Altman, and Philippe Nain.: A Survey of TCP Over Ad

Hoc Networks, IEEE Communications Surveys & Tutorials, Vol: 7, No: 3, pp: 22-

36, Third Quarter 2005.

[26] B Sardar and D Saha.: A survey of TCP enhancements for last-hop wireless

networks, IEEE Communication Surveys and Tutorials, Vol: 8, No: 3, pp: 20-34.

2006.

[27] Mun Choon Chan and Ramachandran Ramjee.: TCP/IP Performance over 3G

Wireless Links with Rate and Delay Variation, IEEE INFOCOM, 2004.

http://www.ieeeinfocom.org/2004/Papers/39 3.pdf.

[28] Hongqiang Zhai, Chen X and Yuguang Fang.: Alleviating intra-flow and inter-flow

contentions for reliable service in mobile ad hoc networks, IEEE Conference on

Military Communications, Vol: 3, pp: 1640-1646, 31 Oct.-3 Nov. 2004. DOI:

10.1109/MILCOM.2004.1495184.

[29] Ka-Cheong Leung, Victor O.K.Li and Daiqin Yang.: An Overview of Packet

Reordering in Transmission Control Protocol (TCP): Problems, Solutions, and

Challenges, IEEE Transactions on Parallel and Distributed Systems, Vol: 18, No: 4,

pp: 522-535, 2007.

[30] Cheng RS, Lin HT.: A Cross Layer design for TCP end-to-end performance

improvement in multi-hop wireless networks, Journal of Computer

Communications, Vol: 31, pp: 3145 - 3152, 2008.

[31] Adaptation and Cross Layer Design in Wireless Networks, CRC Press , Francis and

Taylor Group, 2008.

http://www.ieeeinfocom.org/2004/Papers/39%203.pdf

REFERENCES

109

[32] D. Ciullo, M. Mellia, and M. Meo.: Two schemes to reduce latency in short lived

TCP flows, IEEE Communications Letters, Vol: 13, No: 10, pp: 806-808, 2009.

[33] Mascolo, S. et al.: Performance Evaluation of Westwood+ TCP Congestion Control,

Journal Performance Evaluation-Internet performance symposium, Vol: 55, No: 1,

No: 2, pp: 93-111, 2004.

[34] R. Wang et al.: TCP With Sender-Side Intelligence to Handle Dynamic, Large,

Leaky Pipes, IEEE Journal on Selected Areas in Communications, Vol: 23, No: 2,

pp: 235-248, February 2005.

[35] Adnan Majeed, Nael B. Abu-Ghazaleh, Saquib Razak and Khaled A. Harras.:

Analysis of TCP performance on multi-hop wireless networks: A Cross Layer

approach, AdHoc Networks, Vol: 10, No: 3, pp: 586-603. 2012. ISSN 1570-8705.

[36] Euiyul Ko, Donghyeok An, Ikjun Yeom, and Hyunsoo Yoon.: Congestion control

for sudden bandwidth changes in TCP, International Journal of Communication

Systems, Vol: 25, pp: 1550-1567. 2012. DOI: 10.1002/dac.1322.

[37] Paxson V, Sargent M, Allman M, Chu J.: Computing TCP’s retransmission timer,

2011. RFC 6298.

[38] P Sarolahti et el.: Forward RTO-Recovery (F-RTO): An Algorithm for Detecting

Spurious Retransmission Timeouts with TCP, RFC 5682, Standards Track, 2009.

[39] Chu J, Dukkipati N, Cheng Y and Mathis M.: Increasing TCPs initial window, RFC

6928, Experimental, 2013.

[40] Xiao Lu, Ke Zhang, Chuan Heng Foh, and Cheng Peng Fu.: SSthreshless Start: A

Sender-Side TCP Intelligence for Long Fat Network. arXiv:1401.7146v1 [cs.NI],

2014.

[41] Paulo Rogerio Pereira, Member, IEEE, et.al “From Delay-Tolerant Networks to

Vehicular Delay-Tolerant Networks”, IEEE COMMUNICATIONS SURVEYS &

TUTORIALS, VOL. 14, NO. 4, FOURTH QUARTER 2012, Page No.-1166-1182

[42] Amit Kumar Saha and David B. Johnson: “Modeling mobility for vehicular ad-hoc

networks”, In VANET ’04: Proceedings of the 1st ACM international workshop on

Vehicular ad hoc networks, pages 91–92, New York, NY, USA, 2004. ACM Press.

[43] Forrest Warthman. Delay Tolerant Networks (DTNs): A tutorial v1.1, Mar-2003.

[44] K. fall: “ A Delay Tolerant Network Architecture for Challenged Internets ” Proc.

Of Annual Conf. Of the Special Interest Group on Data Communication ( ACM

SIGCOMM'03), pp. 27-34, Aug. 2003.

REFERENCES

110

[45] Eyuphan Bulut: “ Opportunistic Routing Algorithms in Delay Tolerant Networks ”,

A Thesis of DOCTOR OF PHILOSOPHY, submitted on May 2011.

[46] S. Jain, K. Fall, and R. Patra: “ Routing in Delay Tolerant Networks ”, In Proc. ACM

SIGCOMM, 2004.

[47] A. Demers, D. Greene, C. Houser, W. Irish, J. Larson, S. Shenker, H. Sturgis, D.

Swineheart, and D. Terry: “ Epidemic Algorithms for Replicated Database

Maintenance ”, ACM SIGPOS Operating system Review, V.22, N.1, Jan. 1988.

[48] O. Gnawali, M. Polyakov, P. Bose, R. Govindan, : Data centric, position-based

routing in space networks ”, In Proc. 26Th IEEE Aerospace Conference, pp. 1322-

1334, 2005.

[49] Merugu S., Ammar M., Zegura E.:”Routing in Space and Time in Networks with

Predictable Mobility ”, Tech. Report, GIT-CC-04-7, Georgia Institute of Tech.,2004.

Available at http://smartech.gatech.edu/handle/1853/6492.

[50] R. Handorean, C. Gill, G.-C. Roman: “ Accommodating transient connectivity in ad

hoc and mobile settings ”, LNCS, V. 3001/2004, Springer, pp. 305-322, Jan. 2004.

[51] C. B. Desai, V. N. Pandya, S. K. Hadia: “ Implementation and Performance

Evaluation of Different Routing Protocols for Wireless Ad-hoc networks”, IJDI-

ERET, vol 1, 2012, pp 36 – 41.

[52] I. Cardei, C. Liu, J. Wu: “ Routing in Wireless Networks with Intermittent

Connectivity”, Encyclopedia of Wireless and Mobile Communications, B. Furht

(ed.), CRC Press, Taylor and Francis Group, 2007.

[53] B. Burns, O. Brock, and B. N. Levine, “ MV routing and capacity building in

disruption tolerant networks ”, In proc. IEEE INFOCOM, pp. 398-408, March 2005.

[54] W. Zhao, M. Ammar, E. Zegura, “ A message Ferrying Approach for Data Delivery

in Sparse Mobile Ad Hoc Networks ”, In. Proc. Of 5th MobiHoc, pp. 113-117,2004.

[55] A. Vahdatand, D. Becker, “ Epidemic Routing for Partially Connected Ad Hoc

Networks ”, Duke Technical Report, CS-2000-06, July 2000. available at

issg.cs.duke.edu/epidemic/epidemic.pdf.

[56] Evan P. C. Jones and Paul A. S. Ward: “ Routing Strategies for Delay-Tolerant

Networks ”, 2006. available at citeseerx.ist.psu.edu

[57] T. Spyropoulos, K. Psounis, C. Raghavendra: “ Spray-and-Wait: Efficient routing

scheme for intermittently connected mobile networks ”, in ACM SIGCOMM

Workshop on Delay Tolerant Networking (WDTN), 2005.

http://smartech.gatech.edu/handle/1853/6492

REFERENCES

111

[58] A. Lindgren, A. Doria, O. Schelen, “ Probabilistic routing in intermittently connected

networks ”, ACM SIGMobile Computing and Communication Review, V.7, N.1,

July 2003.

[59] Jeremie Leguay, Timur Friedman, Vania Conan, “ Evaluting Mobility Pattern Space

Routing for DTNs ”, In Proc. IEEE INFOCOM , pp. 1-10, April 2006.

[60] Jian Zhang, Yuanzhu Peter Chen, Ivan Marsic, “ Networking Coding via

Opportunistic Forwarding in Wireless Mesh Networks ”, In Proc. WCNC, pp. 1775-

1780, 2008.

[61] Xu, Q., Mark, T., Ko, J., and Sengupta, R., Vehicle-to-Vehicle Safety Messaging in

DSRC, in Proc. of ACM VANET, 2004.

[62] Yin, J. et al., Performance Evaluation of Safety Applications Over DSRC Vehicular

Ad Hoc Networks, in Proc. of ACM VANET, 2004.

[63] Namboodiri, V., Agarwal, M., and Gao, L., A Study on the Feasibility of Mobile

Gateways for Vehicular Ad-Hoc Networks, in Proc. of ACM VANET, 2004.

[64] Wisitpongphan, N., Bai, F., Mudalige, P., Sadekar, V., and Tonguz, O.K., On the

Routing Problem in Disconnected Vehicular Networks, in Proc. of IEEE INFOCOM

Minisymposia, 2007.

[65] Highway Capacity Manual 2000, May 2000.

[66] Sahoo, P.K., Rao, S.K., and Kumar, V.M.: “A Study of Traffi c Characteristics on

Two Stretches of National Highway No 5, Indian Highways, Indian Road Congress,

1996”.

[67] Yang, X., Liu, J., Zhao, F., and Vaidya, N., A Vehicle-to-Vehicle Communication

Protocol for Cooperative Collision Warning, in Proc. of ACM MOBIQUITOUS,

August 2004.

[68] Verdone, R., Multi-Hop R-Aloha for Inter-Vehicle Communication at Millimeter

Waves, IEEE Transactions on Vehicular Technology, November 1997.

[69] Lott, M., Halmann, R., Schulz, E., and Radimirsch, M., Medium Access and Radio

Resource Management for Ad Hoc Networks Based on UTRA TDD, in Poster of

ACM MOBIHOC, 2001.

[70] Zhang, Y., Zhao, J., and Cao, G., On Scheduling Vehicle-Roadside Data Access, in

Proc. of ACM VANET, 2007.

[71] Frenkiel, R.H., Badrinath, B.R., Borras, J., and Yates, R., Th e Infostations

Challenge: (Balancing Cost and Uiquity in Delivering Wireless Data, IEEE Personal

Communications), April 2000.

REFERENCES

112

[72] Goodman, D., Borras, J., Mandayam, N., and Yates, R., INFOSTATIONS: A New

System Model for Data and Messaging Services, in Proc. of IEEE VTC, May 1997.

[73] U.S. Census Bureau, Tiger, Tiger/line and tiger-related products.

[74] SmartView, available at http://maps.yahoo.com/smartview.php.

[75] Karp, B. and Kung, H.T., GPSR: Greedy Perimeter Stateless Routing for Wireless

Networks, in Proc. of ACM MOBICOM, 2000.

[76] A. Ker ̈Anen, “opportunistic network environment simulator. Special assignment

report, helsinkiuniversity of technology,” Department of Communications and

Networking, May 2008.

[77] Tkk/Comnet. Project page of the ONE simulator. [Online]. Available:

http://www.netlab.tkk.fi/tutkimus/dtn/theone, 2009.

[78] JARDOSH, A. P., B ELDING-ROYER, E. M., A LMEROTH, K. C., and SURI, S.

Real-world environment models for mobile network evaluation. IEEE Journal on

Selected Areas in Communications 23, 3 (March 2005), 99–105.

[79] W ANG, W., S RINIVASAN, V., and MOTANI, M. Adaptive contact probing

mechanisms for delay tolerant applications. In Proc. of ACM MobiCom (September

2007).

[80] C AMP, T., B OLENG, J., and DAVIES, V. A Survey of Mobility Models for Ad

Hoc Network Research. Wireless Communications & Mobile Computing (WCMC):

Special issue on Mobile Ad Hoc Networking: Research, Trends and Applications 2,

5 (2002), 483–502.

[81] E KMAN, F., K ERÄNEN, A., K ARVO, J., AND OTT, J. Working day movement

model. In Proc. 1st ACM/SIGMOBILE Workshop on Mobility Models for

Networking Research (May 2008).

[82] Ari Keranen, Jorg Ott, Teemu Karkkainen, “The ONE Simulator for DTN Protocol

Evaluation”. Extended Report, Department of Communications and Networking,

Helsinki University of Technology (TKK).

[83] Thrasyvoulos Spyropoulos, et. al. “Spray and Wait: An Efficient Routing Scheme

for Intermittently Connected Mobile Networks”, In Proceedings of the 2005 ACM

SIGCOMM workshop on Delay-tolerant networking (August 2005), pp. 252-259.

[84] T. Spyropuos, K. Psounis, C. S. Raghavendra: “Spray and Wait : An Efficient

Routing Scheme for Intermittently Connected Mobile Networks”, SIGCOMM’05

Workshop, August-2005

http://maps.yahoo.com/smartview.php

REFERENCES

113

[85] Qaisar Ayub et.al., “The optimization of Spray and Wait routing Protocol by

prioritizing the message forwarding order” International Journal of Innovation and

Applied Studies ISSN 2028-9324 Vol. 3 No. 3 July 2013, pp. 794-801.

[86] Online Help “API Help” available from http://www.netlab.tkk.fi /tutkimus/ dtn/

theone/javadoc_v141

[87] V. Davies. Evaluating mobility models within an ad-hoc network. Master’s thesis,

2000.

114

APPENDIX

SprayAndWait Router Program Code

Class SprayAndWaitRouter

java.lang.Object

routing.MessageRouter

routing.ActiveRouter

routing.SprayAndWaitRouter

public class SprayAndWaitRouter

extends ActiveRouter

Field Summary

static java.lang.String BINARY_MODE

identifier for the binary-mode setting ("binaryMode")

protected int initialNrofCopies

protected Boolean isBinary

static java.lang.String MSG_COUNT_PROPERTY Message property key

static java.lang.String NROF_COPIES

identifier for the initial number of copies setting

("nrofCopies")

static java.lang.String SPRAYANDWAIT_NS

SprayAndWait router's settings name space

("SprayAndWaitRouter")

Fields inherited from class routing.ActiveRouter

DELETE_DELIVERED_S, deleteDelivered, RESPONSE_PREFIX, sendingConnections, TTL_C

HECK_INTERVAL

Fields inherited from class routing.MessageRouter

http://www.netlab.tkk.fi/tutkimus/dtn/theone/javadoc_v141/routing/MessageRouter.html

http://www.netlab.tkk.fi/tutkimus/dtn/theone/javadoc_v141/routing/ActiveRouter.html



http://www.netlab.tkk.fi/tutkimus/dtn/theone/javadoc_v141/routing/SprayAndWaitRouter.html#BINARY_MODE

http://www.netlab.tkk.fi/tutkimus/dtn/theone/javadoc_v141/routing/SprayAndWaitRouter.html#initialNrofCopies

http://www.netlab.tkk.fi/tutkimus/dtn/theone/javadoc_v141/routing/SprayAndWaitRouter.html#isBinary

http://www.netlab.tkk.fi/tutkimus/dtn/theone/javadoc_v141/routing/SprayAndWaitRouter.html#MSG_COUNT_PROPERTY

http://www.netlab.tkk.fi/tutkimus/dtn/theone/javadoc_v141/routing/SprayAndWaitRouter.html#NROF_COPIES

http://www.netlab.tkk.fi/tutkimus/dtn/theone/javadoc_v141/routing/SprayAndWaitRouter.html#SPRAYANDWAIT_NS


http://www.netlab.tkk.fi/tutkimus/dtn/theone/javadoc_v141/routing/ActiveRouter.html#DELETE_DELIVERED_S

http://www.netlab.tkk.fi/tutkimus/dtn/theone/javadoc_v141/routing/ActiveRouter.html#deleteDelivered

http://www.netlab.tkk.fi/tutkimus/dtn/theone/javadoc_v141/routing/ActiveRouter.html#RESPONSE_PREFIX

http://www.netlab.tkk.fi/tutkimus/dtn/theone/javadoc_v141/routing/ActiveRouter.html#sendingConnections

http://www.netlab.tkk.fi/tutkimus/dtn/theone/javadoc_v141/routing/ActiveRouter.html#TTL_CHECK_INTERVAL

http://www.netlab.tkk.fi/tutkimus/dtn/theone/javadoc_v141/routing/ActiveRouter.html#TTL_CHECK_INTERVAL


APPENDIX

115

B_SIZE_S, DENIED_NO_SPACE, DENIED_OLD, DENIED_TTL, DENIED_UNSPECIFIED, MSG

_TTL_S, msgTtl, Q_MODE_FIFO, Q_MODE_RANDOM, RCV_OK,SEND_QUEUE_MODE_S,

TRY_LATER_BUSY

Constructor Summary

SprayAndWaitRouter(Settings s)

protected SprayAndWaitRouter(SprayAndWaitRouter r)

Copy constructor.

Method Summary

boolean createNewMessage(Message msg)

Creates a new message to the router.

protected java.util.List<M

essage>

getMessagesWithCopiesLeft()

Creates and returns a list of messages this router is

currently carrying and still has copies left to distribute

(nrof copies > 1).

Message messageTransferred(java.lang.String id, DTNHost from)

This method should be called (on the receiving host)

after a message was successfully transferred.

int receiveMessage(Message m, DTNHost from)

Try to start receiving a message from another host.

SprayAndWaitRouter replicate()

Creates a replicate of this router.

protected void transferDone(Connection con)

Called just before a transfer is finalized

(by ActiveRouter.update()).

void update()

Checks out all sending connections to finalize the

ready ones and abort those whose connection went down.

Methods inherited from class routing.ActiveRouter

addToSendingConnections, canStartTransfer, changedConnection, checkReceiving, dro

pExpiredMessages, exchangeDeliverableMessages,getConnections, getMessagesForCo

http://www.netlab.tkk.fi/tutkimus/dtn/theone/javadoc_v141/routing/MessageRouter.html#B_SIZE_S

http://www.netlab.tkk.fi/tutkimus/dtn/theone/javadoc_v141/routing/MessageRouter.html#DENIED_NO_SPACE

http://www.netlab.tkk.fi/tutkimus/dtn/theone/javadoc_v141/routing/MessageRouter.html#DENIED_OLD

http://www.netlab.tkk.fi/tutkimus/dtn/theone/javadoc_v141/routing/MessageRouter.html#DENIED_TTL

http://www.netlab.tkk.fi/tutkimus/dtn/theone/javadoc_v141/routing/MessageRouter.html#DENIED_UNSPECIFIED

http://www.netlab.tkk.fi/tutkimus/dtn/theone/javadoc_v141/routing/MessageRouter.html#MSG_TTL_S

http://www.netlab.tkk.fi/tutkimus/dtn/theone/javadoc_v141/routing/MessageRouter.html#MSG_TTL_S

http://www.netlab.tkk.fi/tutkimus/dtn/theone/javadoc_v141/routing/MessageRouter.html#msgTtl

http://www.netlab.tkk.fi/tutkimus/dtn/theone/javadoc_v141/routing/MessageRouter.html#Q_MODE_FIFO

http://www.netlab.tkk.fi/tutkimus/dtn/theone/javadoc_v141/routing/MessageRouter.html#Q_MODE_RANDOM

http://www.netlab.tkk.fi/tutkimus/dtn/theone/javadoc_v141/routing/MessageRouter.html#RCV_OK

http://www.netlab.tkk.fi/tutkimus/dtn/theone/javadoc_v141/routing/MessageRouter.html#SEND_QUEUE_MODE_S

http://www.netlab.tkk.fi/tutkimus/dtn/theone/javadoc_v141/routing/MessageRouter.html#TRY_LATER_BUSY

http://www.netlab.tkk.fi/tutkimus/dtn/theone/javadoc_v141/routing/SprayAndWaitRouter.html#SprayAndWaitRouter(core.Settings)

http://www.netlab.tkk.fi/tutkimus/dtn/theone/javadoc_v141/core/Settings.html

http://www.netlab.tkk.fi/tutkimus/dtn/theone/javadoc_v141/routing/SprayAndWaitRouter.html#SprayAndWaitRouter(routing.SprayAndWaitRouter)

http://www.netlab.tkk.fi/tutkimus/dtn/theone/javadoc_v141/routing/SprayAndWaitRouter.html

http://www.netlab.tkk.fi/tutkimus/dtn/theone/javadoc_v141/routing/SprayAndWaitRouter.html#createNewMessage(core.Message)

http://www.netlab.tkk.fi/tutkimus/dtn/theone/javadoc_v141/core/Message.html



http://www.netlab.tkk.fi/tutkimus/dtn/theone/javadoc_v141/routing/SprayAndWaitRouter.html#getMessagesWithCopiesLeft()


http://www.netlab.tkk.fi/tutkimus/dtn/theone/javadoc_v141/routing/SprayAndWaitRouter.html#messageTransferred(java.lang.String, core.DTNHost)

http://www.netlab.tkk.fi/tutkimus/dtn/theone/javadoc_v141/core/DTNHost.html

http://www.netlab.tkk.fi/tutkimus/dtn/theone/javadoc_v141/routing/SprayAndWaitRouter.html#receiveMessage(core.Message, core.DTNHost)




http://www.netlab.tkk.fi/tutkimus/dtn/theone/javadoc_v141/routing/SprayAndWaitRouter.html#replicate()

http://www.netlab.tkk.fi/tutkimus/dtn/theone/javadoc_v141/routing/SprayAndWaitRouter.html#transferDone(core.Connection)

http://www.netlab.tkk.fi/tutkimus/dtn/theone/javadoc_v141/core/Connection.html

http://www.netlab.tkk.fi/tutkimus/dtn/theone/javadoc_v141/routing/ActiveRouter.html#update()

http://www.netlab.tkk.fi/tutkimus/dtn/theone/javadoc_v141/routing/SprayAndWaitRouter.html#update()


http://www.netlab.tkk.fi/tutkimus/dtn/theone/javadoc_v141/routing/ActiveRouter.html#addToSendingConnections(core.Connection)

http://www.netlab.tkk.fi/tutkimus/dtn/theone/javadoc_v141/routing/ActiveRouter.html#canStartTransfer()

http://www.netlab.tkk.fi/tutkimus/dtn/theone/javadoc_v141/routing/ActiveRouter.html#changedConnection(core.Connection)

http://www.netlab.tkk.fi/tutkimus/dtn/theone/javadoc_v141/routing/ActiveRouter.html#checkReceiving(core.Message)

http://www.netlab.tkk.fi/tutkimus/dtn/theone/javadoc_v141/routing/ActiveRouter.html#dropExpiredMessages()

http://www.netlab.tkk.fi/tutkimus/dtn/theone/javadoc_v141/routing/ActiveRouter.html#dropExpiredMessages()

http://www.netlab.tkk.fi/tutkimus/dtn/theone/javadoc_v141/routing/ActiveRouter.html#exchangeDeliverableMessages()

http://www.netlab.tkk.fi/tutkimus/dtn/theone/javadoc_v141/routing/ActiveRouter.html#getConnections()

http://www.netlab.tkk.fi/tutkimus/dtn/theone/javadoc_v141/routing/ActiveRouter.html#getMessagesForConnected()

116

nnected, getOldestMessage, init, isSending, isTransferring, makeRoomForMessage,mak

eRoomForNewMessage, requestDeliverableMessages, shuffleMessages, startTransfer,

transferAborted, tryAllMessages,tryAllMessagesToAllConnections, tryMessagesForCon

nected, tryMessagesToConnections

Methods inherited from class routing.MessageRouter

addApplication, addToMessages, compareByQueueMode, deleteMessage, getApplicati

ons, getBufferSize, getFreeBufferSize, getHost,getMessage, getMessageCollection, get

NrofMessages, getRoutingInfo, hasMessage, isDeliveredMessage, isIncomingMessage,

messageAborted, putToIncomingBuffer, removeFromIncomingBuffer, removeFromMes

sages, sendMessage, sortByQueueMode, toString

Methods inherited from class java.lang.Object

clone, equals, finalize, getClass, hashCode, notify, notifyAll, wait, wait, wait

Field Detail

NROF_COPIES

public static final java.lang.String NROF_COPIES

identifier for the initial number of copies setting ("nrofCopies")

BINARY_MODE

public static final java.lang.String BINARY_MODE

identifier for the binary-mode setting ("binaryMode")

SPRAYANDWAIT_NS

public static final java.lang.String SPRAYANDWAIT_NS

SprayAndWait router's settings name space("SprayAndWaitRouter")

MSG_COUNT_PROPERTY

public static final java.lang.String MSG_COUNT_PROPERTY

Message property key

http://www.netlab.tkk.fi/tutkimus/dtn/theone/javadoc_v141/routing/ActiveRouter.html#getMessagesForConnected()

http://www.netlab.tkk.fi/tutkimus/dtn/theone/javadoc_v141/routing/ActiveRouter.html#getOldestMessage(boolean)

http://www.netlab.tkk.fi/tutkimus/dtn/theone/javadoc_v141/routing/ActiveRouter.html#init(core.DTNHost, java.util.List)

http://www.netlab.tkk.fi/tutkimus/dtn/theone/javadoc_v141/routing/ActiveRouter.html#isSending(java.lang.String)

http://www.netlab.tkk.fi/tutkimus/dtn/theone/javadoc_v141/routing/ActiveRouter.html#isTransferring()

http://www.netlab.tkk.fi/tutkimus/dtn/theone/javadoc_v141/routing/ActiveRouter.html#makeRoomForMessage(int)

http://www.netlab.tkk.fi/tutkimus/dtn/theone/javadoc_v141/routing/ActiveRouter.html#makeRoomForNewMessage(int)

http://www.netlab.tkk.fi/tutkimus/dtn/theone/javadoc_v141/routing/ActiveRouter.html#makeRoomForNewMessage(int)

http://www.netlab.tkk.fi/tutkimus/dtn/theone/javadoc_v141/routing/ActiveRouter.html#requestDeliverableMessages(core.Connection)

http://www.netlab.tkk.fi/tutkimus/dtn/theone/javadoc_v141/routing/ActiveRouter.html#shuffleMessages(java.util.List)

http://www.netlab.tkk.fi/tutkimus/dtn/theone/javadoc_v141/routing/ActiveRouter.html#startTransfer(core.Message, core.Connection)

http://www.netlab.tkk.fi/tutkimus/dtn/theone/javadoc_v141/routing/ActiveRouter.html#transferAborted(core.Connection)

http://www.netlab.tkk.fi/tutkimus/dtn/theone/javadoc_v141/routing/ActiveRouter.html#tryAllMessages(core.Connection, java.util.List)

http://www.netlab.tkk.fi/tutkimus/dtn/theone/javadoc_v141/routing/ActiveRouter.html#tryAllMessagesToAllConnections()

http://www.netlab.tkk.fi/tutkimus/dtn/theone/javadoc_v141/routing/ActiveRouter.html#tryMessagesForConnected(java.util.List)

http://www.netlab.tkk.fi/tutkimus/dtn/theone/javadoc_v141/routing/ActiveRouter.html#tryMessagesForConnected(java.util.List)

http://www.netlab.tkk.fi/tutkimus/dtn/theone/javadoc_v141/routing/ActiveRouter.html#tryMessagesToConnections(java.util.List, java.util.List)


http://www.netlab.tkk.fi/tutkimus/dtn/theone/javadoc_v141/routing/MessageRouter.html#addApplication(core.Application)

http://www.netlab.tkk.fi/tutkimus/dtn/theone/javadoc_v141/routing/MessageRouter.html#addToMessages(core.Message, boolean)

http://www.netlab.tkk.fi/tutkimus/dtn/theone/javadoc_v141/routing/MessageRouter.html#compareByQueueMode(core.Message, core.Message)

http://www.netlab.tkk.fi/tutkimus/dtn/theone/javadoc_v141/routing/MessageRouter.html#deleteMessage(java.lang.String, boolean)

http://www.netlab.tkk.fi/tutkimus/dtn/theone/javadoc_v141/routing/MessageRouter.html#getApplications(java.lang.String)

http://www.netlab.tkk.fi/tutkimus/dtn/theone/javadoc_v141/routing/MessageRouter.html#getApplications(java.lang.String)

http://www.netlab.tkk.fi/tutkimus/dtn/theone/javadoc_v141/routing/MessageRouter.html#getBufferSize()

http://www.netlab.tkk.fi/tutkimus/dtn/theone/javadoc_v141/routing/MessageRouter.html#getFreeBufferSize()

http://www.netlab.tkk.fi/tutkimus/dtn/theone/javadoc_v141/routing/MessageRouter.html#getHost()

http://www.netlab.tkk.fi/tutkimus/dtn/theone/javadoc_v141/routing/MessageRouter.html#getMessage(java.lang.String)

http://www.netlab.tkk.fi/tutkimus/dtn/theone/javadoc_v141/routing/MessageRouter.html#getMessageCollection()

http://www.netlab.tkk.fi/tutkimus/dtn/theone/javadoc_v141/routing/MessageRouter.html#getNrofMessages()

http://www.netlab.tkk.fi/tutkimus/dtn/theone/javadoc_v141/routing/MessageRouter.html#getNrofMessages()

http://www.netlab.tkk.fi/tutkimus/dtn/theone/javadoc_v141/routing/MessageRouter.html#getRoutingInfo()

http://www.netlab.tkk.fi/tutkimus/dtn/theone/javadoc_v141/routing/MessageRouter.html#hasMessage(java.lang.String)

http://www.netlab.tkk.fi/tutkimus/dtn/theone/javadoc_v141/routing/MessageRouter.html#isDeliveredMessage(core.Message)

http://www.netlab.tkk.fi/tutkimus/dtn/theone/javadoc_v141/routing/MessageRouter.html#isIncomingMessage(java.lang.String)

http://www.netlab.tkk.fi/tutkimus/dtn/theone/javadoc_v141/routing/MessageRouter.html#messageAborted(java.lang.String, core.DTNHost, int)

http://www.netlab.tkk.fi/tutkimus/dtn/theone/javadoc_v141/routing/MessageRouter.html#putToIncomingBuffer(core.Message, core.DTNHost)

http://www.netlab.tkk.fi/tutkimus/dtn/theone/javadoc_v141/routing/MessageRouter.html#removeFromIncomingBuffer(java.lang.String, core.DTNHost)

http://www.netlab.tkk.fi/tutkimus/dtn/theone/javadoc_v141/routing/MessageRouter.html#removeFromMessages(java.lang.String)

http://www.netlab.tkk.fi/tutkimus/dtn/theone/javadoc_v141/routing/MessageRouter.html#removeFromMessages(java.lang.String)

http://www.netlab.tkk.fi/tutkimus/dtn/theone/javadoc_v141/routing/MessageRouter.html#sendMessage(java.lang.String, core.DTNHost)

http://www.netlab.tkk.fi/tutkimus/dtn/theone/javadoc_v141/routing/MessageRouter.html#sortByQueueMode(java.util.List)

http://www.netlab.tkk.fi/tutkimus/dtn/theone/javadoc_v141/routing/MessageRouter.html#toString()

APPENDIX

117

initialNrofCopies

protected int initialNrofCopies

isBinary

protected boolean isBinary

Constructor Detail

SprayAndWaitRouter

public SprayAndWaitRouter(Settings s)

SprayAndWaitRouter

protected SprayAndWaitRouter(SprayAndWaitRouter r)

Copy constructor.

Parameters:

r - The router prototype where setting values are copied from

Method Detail

receiveMessage

public int receiveMessage(Message m, DTNHost from)

Parameters:

m - Message to put in the receiving buffer

from - Who the message is from

Returns:Value zero if the node accepted the message (RCV_OK), value less than zero if

node rejected the message (e.g. DENIED_OLD), value bigger than zero if the other node

should try later (e.g. TRY_LATER_BUSY).

messageTransferred

public Message messageTransferred(java.lang.String id,

DTNHost from)

This method should be called (on the receiving host) after a message was

successfully transferred. The transferred message is put to the message

buffer unless this host is the final recipient of the message.

Parameters:

http://www.netlab.tkk.fi/tutkimus/dtn/theone/javadoc_v141/core/Settings.html






118

id - Id of the transferred message

from - Host the message was from (previous hop)

Returns:

The message that this host received

createNewMessage

public boolean createNewMessage(Message msg)

Creates a new message to the router.

Parameters:

msg - The message to create

Returns:

True if the creation succeeded, false if not (e.g. the message was too big

for the buffer)

update

public void update()

Checks out all sending connections to finalize the ready ones and abort those

whose connection went down. Also drops messages whose TTL <= 0

(checking every one simulated minute).

getMessagesWithCopiesLeft

protected java.util.List<Message> getMessagesWithCopiesLeft()

Creates and returns a list of messages this router is currently carrying and

still has copies left to distribute (nrof copies > 1).

Returns:

A list of messages that have copies left

transferDone

protected void transferDone(Connection con)

Called just before a transfer is finalized (by ActiveRouter.update()).

Reduces the number of copies we have left for a message. In binary Spray

and Wait, sending host is left with floor(n/2) copies, but in standard mode,

nrof copies left is reduced by one.



http://www.netlab.tkk.fi/tutkimus/dtn/theone/javadoc_v141/core/Connection.html

http://www.netlab.tkk.fi/tutkimus/dtn/theone/javadoc_v141/routing/ActiveRouter.html#update()

APPENDIX

119

Parameters:

con - The connection whose transfer was finalized

replicate

public SprayAndWaitRouter replicate()

Creates a replicate of this router. The replicate has the same settings as this

router but empty buffers and routing tables.

Returns:

The replicate

Explanations of report output

sim_time Simulation time

created Number of messages created during simulation Does

not include replicated messages.

started Number of transmissions started between network

nodes

relayed Number of successful transmissions between nodes

aborted Number of aborted transmissions

between nodes

dropped Number of messages dropped from nodes’ buffers

removed if delivered

then

true

else

drop from buffer

delivered Number of successfully delivered messages

delivery_prob Message delivery probability

overhead_ratio An assessment of bandwidth efficiency

latency_avg average message delay from creation to

delivery

latency_med median of average message delay


120

hopcount_avg Average number of hops between source and

destination nodes.

hopcount_med median of hop count average

buffertime_avg Average time that messages stayed in the buffer at

each node

buffertime_med median of buffer time average

improvement of wireless network …gtu.ac.in/uploads/119997111007_vyomal_pandya.pdfimprovement of...

Documents