than other algorithms; for example, it is found that the throughput .... The CTS frame can prevent collision from a hidden node. 51 ...... DRRSA< DDPSA< DTCC.
جامعة الموصل كمية الهندسة
تحسين أداء كـفاءة النقـل لمشبكـات غير الممركزة الالسمكيـة المتعددة القفزات
سعد أحمد أيوب السالمي أطروحة دكتوراه
الهندسة الكهربائية /االتصاالت بإشراف
االستاذ المساعد الدكتور
عبداإللو عبد الجبار عبد اهلل
1432ه
2011م
University of Mosul College of Engineering
Improving the Throughput Performance of Multi-hop Wireless Ad-hoc Networks
Saad Ahmed Ayoob Alsalami
Ph.D. Thesis Electrical Engineering/Communication Engineering Supervised by
Assistant Professor Dr. A.I.A. Jabbar
2011 A.D.
1432 A.H.
Abstract Multi-hop wireless ad-hoc networks with different topologies proved to be a feasible solution for low-cost deployment of computer networks. It provides quick and easy networking in circumstances that require temporary network services or when cabling is difficult to be installed. On other hand, this type of networks is a popular case of a mesh networks and is subjected to transmission control protocol (TCP) instability and unfairness between the flows which are regarded as main problems in multi-hop ad-hoc networks. In this thesis, these problems are taken into account in the design of a novel model of multi-hop wireless ad-hoc networks using Simevents tools and OPNET software (for validation purpose). In addition, distributed packet scheduling algorithm (DPSA) and TCP congestion control (TCC) algorithms are applied to minimize the effect of these problems. Another algorithm called Round Robin scheduling algorithm (RRSA) is proposed and implemented efficiently especially in multi-hop ad-hoc networks cross-topology. RRSA shows higher throughput, less delay and better stability than other algorithms; for example, it is found that the throughput percentage variation of this algorithm is equal to 29.7% relative to the average throughput of TCC. On the other hand, the latter has a throughput percentage variation that equals to 25.1% relative to the average throughput of DPSA. Simulation results with cross-topology also show that at the first intermediate node, the queue length and the buffering delay of four-hop model with this algorithm are equal to (queue length < 0.14 packet , delay < 43 msec.). These values are better-off than those obtained either with TCC (queue length < 0.41 packet, delay < 66 msec.) or DPSA (queue length< 0.18 packet, delay < 62 msec.) algorithms. I
List of Abbreviation Abb. ACDH ACK AODV AP
Details Average Contention Delay per Hop acknowledgment Ad-hoc On demand Distance Vector Access Point
ARS
Active Relinquish Scheme
ATCP
Ad-hoc Transmission Control Protocol
BPSK
Binary Phase Shift Keying
BSS BSSID CCK
Basic Service Set BSS Identity Complementary Code Keying
CD
Contention Delay
CDF
Contention Delay Field
CDH
Contention Delay per Hop
CSMA/CA Carrier Sense Multiple Access with Collision Avoidance CSMA/CD Carrier Sense Multiple Access with Collision Detection CTMAC
Concurrent Transmission protocol
CTS
Clear To Send
CW
Contention Window
cwnd
Congestion window
DA
Destination Address
DCF
Distributed Coordination Function
II
Abb.
Details
DIFS
DCF Interframe Space
DPSA
Distributed Packet Scheduling Algorithm
DS DSDV
Distribution System Destination-Sequenced Distance Vector
DSR
Dynamic Source Routing
DSSS
Direct Sequence Spread Spectrum
DV EECA
Distance Vector Energy Efficient and Channel Aware
ESS
Extended Service Set
FBA
Fair Backoff algorithm
FCS
Frame Check Sum
FHSS
Frequency Hopping Spread Spectrum
FIFO
First In First Out
FSK
Frequency Shift Keying
HOL
Head-Of-Line
HR -DSSS High-Rate DSSS IBSS IP
Independent Basic Service Set Internet Protocol
ISM
Industrial, Scientific and Medical
ISO
International Organization of Standardization
LAN
Local Area Network
LLC
Logical Link Control
LRED
Link Random Early Detection
III
Abb. LS
Details Link State
MAC
Medium Access Control
MANETs
Mobile Ad-hoc networks
MPDU
MAC Protocol Data Unit
MPR MSDU NAV
Multipoint Relays MAC Service Data Unit Network Allocation Vector
OFDM
Orthogonal Frequency Division Multiplexing
OLSR
Optimized Link State Routing
OPET
Optimum Packet scheduling for Each Traffic flow
OPNET
Optimum Network Simulator
OSI
Open System Interconnection
PCF
Point Coordination Function
PHY
Physical Layer Device
PPM
Pulse Position Modulation
PSK
Phase Shift Keying
QoS
Quality of Service
QPSK
Quadrature Phase Shift Keying
rcwnd
Received congestion window
RERR
Route Error
RIP
Routing Information Protocol
RR
Round Robin
RREP
route replay
IV
Abb. RREQ
Details Route request
RRF
Round Robin Fashion
RRS
Round Robin Scheduling
RRSA
Round Robin Scheduling Algorithm
RTO
Retransmission Time Out
RTR
Request To Receive
RTS
Request To Send
RTT
Round Trip Time
rwnd
New of receiver congestion window
SA
Source Address
SFD
Start of Frame Delimiter
SIFS
Short Interframe Space
SNR
Signal-to-Noise Ratio
swnd
Send congestion window
TC
Topology Control
TCC
TCP Congestion Control
TCP
Transport Control Protocol
TCP-LBA TCP Loss based ACK UDP
User Datagram Protocol
VANETs
Vehicular Ad-hoc Networks
VQA
Various Queuing Algorithms
WCCP WEP
Wireless Congestion Control Protocol Wired Equivalent Privacy
V
Abb.
Details
WLAN
Wireless Local Area Network
WMNs
Wireless Mesh Networks
WSNs
Wireless Sensor Networks
List of Figures Figure No.
Figure caption
Figure 2.1 Figure 2.2 Figure 2.3 Figure 2.4 Figure 2.5 Figure 2.6
802.11 Logical Architecture. Physical layer of IEEE 802.11 DSSS. Physical layer of IEEE 802.11b. PHY and MAC layers in IEEE 802.11 standard. Timing in CSMA/CA. Flowchart of CSMA/CA (Basic access mechanism). Flowchart of CSMA/CA (RTS/CTS access mechanism). Timing in CSMA/CA using RTS/CTS mechanism. Infrastructure Mode Topology. Extended service set (ESS). Ad-hoc Mode Topology. Two hop (Multi-hop ad hoc networks). Bringing up an ad-hoc network. Active scanning. Passive scanning. Management frame format. RTS frame format. Frame control field.
Figure 2.7 Figure 2.8 Figure 2.9 Figure 2.10 Figure 2.11 Figure 2.12 Figure 2.13 Figure 2.14 Figure 2.15 Figure 2.16 Figure 2.17 Figure 2.18
VI
Page No. 13 14 15 16 16 17 19 20 22 22 23 23 25 26 27 27 28 29
Figure No. Figure 2.19 Figure 2.20 Figure 2.21 Figure 2.22 Figure 2.23 Figure 3.1 Figure 3.2 Figure 3.3 Figure 3.4 Figure 3.5 Figure 3.6 Figure 3.7 Figure 3.8 Figure 3.9 Figure 3.10 Figure 3.11 Figure 3.12 Figure 3.13 Figure 3.14 Figure 3.15 Figure 3.16
Page No. CTS frame format. 29 ACK frame format. 30 Data frame format of ad-hoc network. 30 Three periods (Ī, B , and Ū). 33 Markov Chain model for the backoff window size. 39 Multi-hop wireless ad-hoc networks (Chain-topology). 47 Nodes B and C are hidden from each other with 50 respect to A. The CTS frame can prevent collision from a hidden 51 node. Node C is exposed to transmission from A to B 51 The CTS frame cannot prevent collision from exposed 52 node. Network partition scenario. 54 New TCP connection reaches ACK from sink to 54 sender. Route table entries for the destination node 15. 56 Flowchart of the process of route discovery in AODV. 58 Route discovery in AODV. 59 Generation of an RREP by node 3 that has a route to node D and sends an RREP to node S and unnecessary 59 RREP to node D. Flowchart of how to maintain a route from S to D. 60 The link between node 5 and node D has broken, and 61 node 5 generates an RERR. Dynamic Source Routing (DSR). 63 An example of flooding using MPR nodes. 65 Figure caption
The TCP/IP (left) and the cross-layer architecture (right).
VII
67
Figure No. Figure 3.17 Figure 3.18 Figure 3.19 Figure 3.20 Figure 3.21 Figure 3.22 Figure 3.23 Figure 3.24 Figure 4.1 Figure 4.2 Figure 4.3 Figure 4.4 Figure 4.5 Figure 4.6 Figure 4.7 Figure 4.8
Figure caption Cross-layer optimizations involving PHY, MAC, NET and TRA Layers. A single TCP flow (Four-hop chain-topology). Queue build up in the single TCP flow. Intra-flow instability cycle. Multiple TCP flows (two-connections) in a cross topology Markov chain model for the channel around the node x. Markov chain model for the node x. Illustration of hidden nodes and communication in multi-hop. The relationship between throughput and offered load A simple scenario with four user nodes and one destination. Different cases of network-layer queue. Multi-hop wireless ad-hoc networks (Chain-topology) Optimum packet scheduling for chain-topology The algorithm of how TCP_Contention can be calculated.
69 72 73 74 75 79 82 83 89 90 91 95 97 100
The optional field in the MAC Protocol Data Unit.
101
The flowchart of TCC cross layer algorithm.
104
The modeling of TCC algorithm using Simevents technique. Subsystem 1, which contains the generation of packets Figure 4.10 and some process of TCC algorithm. Figure 4.9
Figure 4.11
Page No.
Subsystem 1, which contains the comparison of the number of packets departure and (CPRTT).
VIII
106 107
108
Figure caption
Figure No. Figure 4.12 Subsystem 2 and 3, realization of condition (∆C). Figure 4.13 GerLes block, the end of packet. Figure 4.14 Different node stages in a FBA scheme. Multiple TCP flows (two connections) in a crossFigure 4.15 topology. Figure 4.16 Example of Round Robin Scheduling (RRS) process. Figure 4.17 The output of switch for equal data rate using (RRS). Figure 4.18 Output of switch for unequal data rate using (RRS). Proposed modeling of a single-hop ad-hoc wireless Figure 5.1 network using Simevents tools. The proposed structure of a Source based on Figure 5.2 Simevents tools. Figure 5.3 The structure of subsystem 1 in Source node. Figure 5.4 The structure of subsystem A in subsystem 1. Figure 5.5 The structure of subsystem 3 in source node. Figure 5.6 The proposed modeling of wireless channel. Figure 5.7 The proposed modeling of destination node. Figure 5.8 The details of (Calculation the # collision) block. Figure 5.9 The flowchart of a typical intermediate node. Figure 5.10 The flowchart of the backoff algorithm. The proposed modeling of the intermediate node using Figure 5.11 Simevents. Figure 5.12 The details of "check destination 2" block. The flowchart of a channel in multi-hop ad-hoc Figure 5.13 networks. Figure 5.14 The proposed channel in multi-hop ad-hoc networks. Figure 5.15 Example of two TCP connections in a cross-topology The proposed Sub-channel 1 in cross-topology multiFigure 5.16 hop ad-hoc networks. The proposed Sub-channel 2 in cross-topology multiFigure 5.17 hop ad-hoc networks. The modified source in chain-topology multi-hop adFigure 5.18 hoc networks (Four-hops).
IX
Page No. 109 110 110 113 114 115 115 118 119 120 121 122 124 126 127 129 130 131 132 133 134 135 137 139 141
Figure No.
Figure caption
Figure 5.19 Figure 5.20 Figure 5.21 Figure 5.22 Figure 5.23
The details of modified Subsystem 1. The proposed source node with TCC algorithm. The details of TCP unit. The details of the "Calculation data rate" block. The proposed intermediate node with TCC algorithm. The subsystem 1 of intermediate node with TCC algorithm. The proposed destination node with TCC algorithm. The details of the Decision unit. The structure of ACDH subsystem. The proposed source node with RRSA algorithm. The details of Round Robin control subsystem. The last scenario for the modeling of the single-hop ad-hoc network. The relationship of the throughput with the number of nodes in the case of a single-hop ad-hoc network. The types of delays versus the number of nodes in the single-hop ad-hoc network. The number of hops versus simulation time. Wireless network connection status and wireless properties. The window of Wireless network connection properties. IBSS mode is 802.11b and data rate is equal to 2 Mbps. The sharing folder steps. Two laptops are connected practically as a single-hop wireless ad-hoc network. Packet generating tool by CommView. Network matrix by IP in CommView. The packets received by user2. The packets received by user 2 with variable data rates.
Figure 5.24 Figure 5.25 Figure 5.26 Figure 5.27 Figure 5.28 Figure 5.29 Figure 6.1 Figure 6.2 Figure 6.3 Figure 6.4 Figure 6.5 Figure 6.6 Figure 6.7 Figure 6.8 Figure 6.9 Figure 6.10 Figure 6.11 Figure 6.12 Figure 6.13
X
Page No. 142 144 145 146 147 148 149 150 150 152 153 157 158 159 160 161 162 163 164 165 166 167 167 168
Figure No.
Figure caption
Figure 6.14 Average throughput of user 2 versus data rate. The relationship between the instantaneous channel Figure 6.15 utilization with simulation time using Simevents. Figure 6.16 Channel utilization of user 2 versus data rate. The instantaneously throughput of the first scenario Figure 6.17 using Wireshark. Figure 6.18 The practical WLAN of a single-hop ad-hoc network. Figure 6.19 The six computers appeared in the network. The IP and MAC addresses of six computers in the Figure 6.20 network. The instantaneously throughput using Wireshark (IO) Figure 6.21 graphs for the fifth scenario (six computers). The throughput performance as a function of the Figure 6.22 number of nodes. The throughput versus the probability P' when packet Figure 6.23 size is equal to 1460B. The throughput versus the probability P' when packet Figure 6.24 size is equal to 500 B. The maximum throughput versus the number of Figure 6.25 nodes. The completed model of multi-hop wireless ad-hoc Figure 6.26 networks (chain-topology with two-hop) using Simevents. The completed model of multi-hop wireless ad-hoc Figure 6.27 networks (chain-topology with two-hop) using OPNET. The throughput with variable data rates for two-hop Figure 6.28 model. shows an example of the iterations of the first and Figure 6.29 second hops for two-hop model. The buffer capacity of node 2 with variable data rates Figure 6.30 for two-hop modes using OPNET and Simevents. The instantaneous end-to-end delay at data rate =125 Figure 6.31 packet/sec for two-hop modes using Simevents.
XI
Page No. 169 170 170 171 172 173 173 174 175 176 176 178 179
180 181 182 183 184
Figure No. Figure 6.32 Figure 6.33 Figure 6.34
Figure 6.35 Figure 6.36 Figure 6.37 Figure 6.38 Figure 6.39 Figure 6.40 Figure 6.41 Figure 6.42 Figure 6.43 Figure 6.44 Figure 6.45 Figure 6.46
Figure caption The instantaneous end-to-end delay at data rate =125 packet/sec for two-hop modes using OPNET. The relationship between the average end-to-end delay and data rates for two-hop models. The completed model of multi-hop wireless ad-hoc networks (chain-topology with three-hop) using OPNET. The completed model of multi-hop wireless ad-hoc networks (chain-topology with three-hop) using Simevents. The average throughput as a function of data rate of the three-hops model. The buffer queue of nodes 2 and 3 with variable data rates of the three-hop modes using OPNET and Simevents. The average delay with variable data rates for threehop models using OPNET and Simevents. The completed model of the multi-hop wireless adhoc networks (chain-topology with three-hop) using OPNET. The completed model of multi-hop wireless ad-hoc networks (chain-topology with four-hops). The relationship between the average throughput and the variable data rates of the four-hop model. The queue size of nodes 2 and 3 as a function of the data rate of the three-hop model using OPNET and Simevents. The instantaneous results of chain-topology. The relationship between the average delay of node 2 and variable data rates for four-hop model. An example of four-hop model showing the iterations of first, second, third and four hops as a function of time. Proposed model of four-hop ad-hoc networks using OPNET (cross-topology).
XII
Page No. 184 185 186
187 188 189 190 191 192 193 194 195 196 197 197
Figure No. Figure 6.47 Figure 6.48
Figure 6.49
Figure 6.50 Figure 6.51 Figure 6.52 Figure 6.53 Figure 6.54 Figure 6.55 Figure 6.56 Figure 6.57 Figure 6.58 Figure 6.59 Figure 6.60 Figure 6.61
Figure caption The proposed model of four-hop ad-hoc networks using Simevents (Cross-topology). The relationship between throughput and the number of hops of cross-topology four-hop ad-hoc networks at various data rates. The queue length of nodes 1, 3 and 5 as a function of the data rate of the cross-topology model using OPNET and Simevents. The average delay of node 1 as a function of the time of simulation of the cross-topology at a data rate equal to 100 packet/sec. The average throughput as a function of the data rate for chain-topology using DPSA. The instantaneous results of the chain-topology with DPSA. The average queue size of node 2 as a function of the data rate for chain-topology with and without DPSA. The average delay of node 2 as a function of the data rate for chain-topology with and without DPSA. The average end-to-end delay as a function of the data rate for chain-topology with and without DPSA. The average throughput as a function of the data rate for TCP flow 1 using DPSA. The average throughput as a function of the data rate for TCP flow 2 using DPSA. The average queue length of node 1 as a function of the data rate for cross-topology with and without DPSA. The results of four-hop model using DPSA are as follows. The average delay of node 1 as a function of the simulation time for cross-topology with and without DPSA. The average throughput as a function of the number of hops for chain-topology using TCC.
XIII
Page No. 198 199
201
202 203 204 205 206 206 207 208 208 209 210 211
Figure No.
Figure caption
Page No.
Figure 6.62
The results of the four-hop model with TCC are as follows.
212
Figure 6.63 Figure 6.64 Figure 6.65 Figure 6.66 Figure 6.67 Figure 6.68 Figure 6.69 Figure 6.70 Figure 6.71 Figure 6.72 Figure 6.73 Figure 6.74 Figure 6.75 Figure 6.76 Figure 6.77
The average delay of node 2 versus the simulation time for chain-topology with and without TCC. The average end-to-end delay versus the simulation time for chain-topology with and without TCC. The average throughput as a function of the number of hops for TCP 1 in cross-topology using TCC. The average throughput as a function of the number of hops for TCP 2 in cross-topology using TCC. The average queue length of nodes 1, 3 and 5 as a function of the simulation time for cross-topology with TCC. The average delay of node 1 versus the simulation time for cross-topology with and without TCC. The average throughput as a function of the data rate for TCP flow 1 using RRSA. The average throughput as a function of the data rate for TCP flow 2 using RRSA. The average throughput as a function of the number of hops for TCP flow 1 with various data rates using RRSA. The results of the four-hop model with RRSA are as follows. The average delay of node 1 versus the simulation time for cross-topology with and without RRSA. The average throughput as a function of the number of hops for various algorithms in chain-topology. The average throughput as a function of the number of hops for various algorithms in cross-topology. The average queue length of node 1 as a function of simulation time for cross-topology with various algorithms. The average delay of node 1 as a function of simulation time for cross-topology with various algorithms.
XIV
213 214 215 215 216 217 218 219 219 221 222 223 223 224 225
List of Tables
Table No.
Table caption
Table 2-1 Table 2-2 Table 2-3 Table 6-1 Table 6-2
Physical layers. Address field contents. Various state probabilities. The parameters used in the analytical model. The parameters used in the analytical model. The relationship between packet length, the probability P', the number of nodes and the maximum throughput. The overall throughput with variable data rate for twoflow, and the throughput variation percentage of each flow.
Table 6-3
Table 6-4
Page No. 14 31 36 155 156 177
200
List of Symbols A B cv D D(N) H Ī lACK lCTS ldata lRTS M N
Area. The mean value of the duration of a busy period. the coefficient of variation of the service time. The total delay. The head-of-line delay. Header length (bit). The mean value of the duration of an Idle period. The transmission times of ACK. The transmission times of CTS. The transmission times of data. The transmission times of RTS. The mean number of nodes that belong to the shared channel. Number of nodes.
XV
NTP/B P p P' Pc PCI Pcoll pdf PI Pil Pis Ps ps Pss Psuc Ptr PWC PWS PWS(r) PWW R Ra RE remax S T TACK TBi Tc Tcoll TCTS TD
The random variable represents the number of transmissions per busy period. Packet length (bit). The conditional collision probability A waiting node transmits a packet with this probability. Probability that a collision occurs in a slot. The limiting probability of the channel to be idle. Probability that a given node’s transmission is unsuccessful (i.e. packet collides). Probability distribution function. Probability that a slot is idle. The transition probability from Idle state to Long state. The transition probability from Idle state to Short state. Probability that a given node’s transmission is successful. The probability that a node begins a successful four-way handshake at the beginning of a slot. The probability that a transmission on the channel is successful. Probability that a slot contains the start of a successful transmission. Probability that at least one transmission is initiated in a slot. The transition probability from wait to collision states. The transition probability from wait to succeed states. The probability density function of PWS. The probability of the node stays in wait state. Data rate. Transmission and reception range. The random variable represents the number of retransmissions. The maximum allowable number of retransmissions. The throughput. The data transmission time. Transmission time of ACK frame. the random variable denoting the number of slots a node spends in backoff at the ith backoff stage. The time of the channel which is subjected to a collision. The busy time for the node x in the collision state. Transmission time of CTS frame. Duration transmission time.
XVI
Tidle Tlong Ts Tshort Tsucc Tt Twait Ū W N α γ δ λ μ πi πl πs ρ σ τ υ
The duration of channel is idle state. The busy time of the channel in long time state. The time of the channel occupied by a successful transmission. The busy time for the channel in short time state. The busy time of the node x in the successful state. Transmission time of data or management frame. The duration of node x is a wait state. The mean value of the duration of a useful period. The average waiting time. The maximum propagation delay. The collision period. The average physical time between each two decrements of the backoff counter. The arrival rate. The service rate. The steady state probability of idle state. The steady state probability of long state. The steady state probability of short state. The traffic intensity. Slot time. The stationary probability. Density of nodes.
XVII
Contents Content Chapter One: Introduction 1.1 Literature Review 1.2 Thesis Contributions 1.3 Thesis Layout Chapter Two: Wireless LAN background 2.1 Introduction 2.2 PHY Layer 2.2.1 IEEE 802.11 DSSS 2.2.2 IEEE 802.11b DSSS 2.3 MAC Functions 2.4 CSMA/CA and Wireless Networks 2.5 IEEE 802.11 Architectures 2.5.1 Infrastructure mode 2.5.2 Ad hoc networks 2.6 Ad hoc performance principles 2.6.1 Management function 2.6.2 Control function 2.6.3 Data transmission 2.7 IEEE 802.11 throughput Analysis of a single-hop Adhoc networks 2.7.1 System model assumptions 2.7.2 Throughput analysis 2.7.3 Packet Transmission Probability 2.7.4 Delay analysis Chapter Three: Multi-hop Wireless Ad-hoc Networks 3.1 Introduction 3.2 TCP in multi-hop wireless ad-hoc networks 3.2.1 Lossy channels 3.2.2 Hidden and Exposed nodes 3.2.3 Path asymmetry 3.2.4 Network partition
XVIII
Page No. 1 4 10 11 13 13 13 14 15 15 18 21 21 22 24 26 28 30 31 32 32 36 41 47 47 48 49 49 53 53
3.2.5 Routing failures 3.2.6 Power constraints 3.3 Conventional routing protocols in multi-hop wireless ad-hoc networks 3.4 Advanced routing protocols 3.4.1 On-Demand Routing Protocols 3.4.2 Table-Driven Routing Protocols 3.5 Cross layer in multi-hop ad-hoc networks 3.6 Cross Layer Examples 3.7 TCP Instability in Multi-hop Ad hoc Networks 3.7.1 TCP Intra-flow Instability 3.7.2 TCP Inter-flow Instability 3.8 Throughput analysis of multi-hop ad-hoc networks 3.8.1 Approximate throughput performance analysis Chapter Four: Design of TCP and Fairness Algorithms for Multi-hop Wireless Ad-hoc Networks 4.1 Introduction 4.2 Various Queuing Algorithms (VQA) 4.2.1 Isolate the originating traffic 4.2.2 Different weight on the relayed traffic 4.2.3 Per-flow queuing 4.3 Distributed Packet Scheduling Algorithm (DPSA) 4.4 Cross-layer algorithm 4.4.1 TCP Contention Control (TCC) cross layer algorithm 4.4.2 Fair Backoff algorithm (FBA) 4.5 Round Robin Scheduling Algorithm (RRSA) Chapter Five: Design of a Single-hop and Multi-hop Wireless Ad-hoc Networks using Simevents 5.1 Introduction 5.2 Design of a single-hop ad-hoc network using Simevents 5.2.1 Source unit
XIX
55 55 55 57 57 63 66 68 70 71 74 76 77 87 87 88 90 93 94 94 97 97 110 114 117 117 117 118
5.2.2 The channel unit 5.2.3 The destination unit 5.3 Design of multi-hop ad-hoc networks using Simevents 5.3.1 The intermediate node 5.3.2 The channel 5.4 Design of cross-topology multi-hop ad-hoc networks 5.4.1 Sub-channel 1 model 5.4.2 Sub-channel 2 model 5.5 Design of the proposed DPSA algorithm 5.6 Design of the proposed TCC algorithm 5.6.1 The source node with TCC algorithm 5.6.2 The intermediate node with TCC algorithm 5.6.3 The destination node with TCC algorithm 5.7 Design of the proposed RRSA algorithm Chapter Six: Simulation and Results
123 125 127 127 132 135 136 138 140 143 143 146 148 151 154
6.1 Introduction 6.2 Simulation of a single-hop ad-hoc network 6.3 A practical single-hop wireless ad-hoc network 6.3.1 The first scenario 6.3.2 The fifth scenario 6.4 Simulation of multi-hop ad-hoc networks 6.4.1 The analytical model results 6.4.2 Multi-hop ad-hoc model results using Simevents and OPNET 6.5 Simulation of multi-hop ad-hoc networks (crosstopology) 6.6 Simulation of Distributed Packet Scheduling Algorithm 6.6.1 The throughput curves of DPSA for chaintopology 6.6.2 The queue length of intermediate nodes for chain-topology
154 154 160 161 172 175 175
6.6.3 The delay of node 2 and end-to-end delay of chain-topology
205
XX
179 197 202 203 204
6.6.4 The throughput curves of DPSA for crosstopology 6.7 Simulation of TCP Contention Control (TCC) algorithm 6.7.1 The throughput of chain-topology with TCC 6.7.2 The queue length of intermediate nodes for chain-topology 6.7.3 The delay performance of chain-topology with TCC 6.7.4 The throughput curves of TCC for crosstopology 6.8 Simulation of Round Robin Scheduling algorithm (RRSA) 6.8.1 The throughput curves of RRSA for crosstopology 6.8.2 The queue length of intermediate nodes for cross-topology 6.8.3 The delay at node 1 of the cross-topology with RRSA 6.9 A comparison between the presented algorithms 6.9.1 The throughput 6.9.2 The average queue length of node 1 in crosstopology 6.9.3 The average delay of node 1 in cross-topology Chapter Seven: Conclusions and Suggestions for Future
207 210 211 212 213 214 217 218 220 221 222 222 224 224 226
Works 7.1 Conclusions 7.2 Suggestions for Future Works References
XXI
226 229 230
Chapter One Introduction
The development of IEEE 802.11 standards for wireless LAN began in the late 1980. It initially specified data rates of 1 and 2 Mbps, while the data rate of some of the recent versions like 802.11 a, b and g may reach 54 Mbps. Infrastructure and ad-hoc architectures are
used
practically.
Infrastructure
wireless
LANs
provide
communication between users through a central controller called Access Point (AP) [1]. The main goal of wireless ad-hoc networks is to allow a group of computers to communicate with each other without the support of a base station or a central controller. Wireless ad-hoc networks
are
useful
for
situations
that
require
quick
or
infrastructureless local network deployment, such as crisis response, conference meetings, military applications, hospitals environments, and office networks. It is also useful for Internet connectivity in both urban and rural areas [2]. Ad-hoc wireless networks include Mobile Ad-hoc networks (MANETs), Wireless Sensor Networks (WSNs), Wireless Mesh Networks (WMNs), and Vehicular Ad-hoc Networks (VANETs) [3]. It is worth to mention that a multi-hop wireless ad-hoc network is adopted in this study, which is a type of WMNs. Ad-hoc network posses traffic routing and relaying ability. This fact can be considered as the main difference between the ad-hoc network and the cellular technology [4].
(1)
Recently, IEEE 802.11 WLANs have become the dominant technology for wireless networking. It is worth to mention that there is an increment into the demands for mobile data services in urban environment; in addition, a larger coverage area is needed. Due to the limitation of the protocol, single-hop transmission range is not exceeding a couple of miles and is not sufficient for mobile subscribers. On the other hand, the cost for IEEE 802.16e [5] is still relatively expensive because of the equipment itself and associated fees for operating in licensed frequency bands. Thus, multi-hop wireless networks become a necessary take for mobile users. In addition, due to the limited transmission range of wireless network interfaces, multiple hops are needed to exchange data between nodes in the network [6]. Multi-hop wireless Ad-hoc provides easy networking in circumstances that require temporary application or when cabling is difficult. Although ad-hoc has Point Coordination Function (PCF) and Distributed Coordination Function (DCF) modes of operation the latter which is a contention based decentralized protocol utilizing the so called Carrier Sense Multiple Access with Collision Avoidance (CSMA/CA), is the most popular MAC protocol used in wireless adhoc networks [7]. It is found that the creation of a connection using TCP (Transmission Control Protocol) in multi-hop ad-hoc network has the following problems: 1. The difficulty of providing end-to-end reliable delivery of userlevel data, (i.e each TCP packet must traverse one or more intermediate hops successfully till the destination). 2. Contention problems from "hidden nodes" and "exposed nodes" in the wireless network that limit the number of TCP data (2)
packets from source to destination. These problems limit the TCP throughput performance over a multi-hop path [8]. 3. Interferences are location-dependent. For a traffic flow from a source node to a destination node, the nodes in the middle of the path have to contend with more nodes when forwarding the traffic of the flow. To obtain low level of contention, the source node may inject more traffic into the path than can be forwarded by the later nodes. This may cause excessive packet losses and re-routing instability [9]. 4. Fairness is a problem when network resources are unable to satisfy demand. They should be divided fairly between the clients of the network; this means that there are multiple flows, and unfairness may also arise when some flows experience higher contention than other flows [10]. Some algorithms are proposed recently to overcome these problems using layering algorithms such as ad-hoc TCP (ATCP) which is implemented as a thin layer between Internet protocol and standard TCP that corrects these problems and maintains high end-toend TCP throughput [11]. Adpative_Pause is also layering algorithm which is a simple and distributed scheme that only needs little communication and processing overhead. Each node in this algorithm monitors the occupation of the channel due to its emissions and dynamically determines whether it should pause a time interval in order to avoid channel capture [12]. In cross-layering algorithms, protocols use the state information flowing throughout the stack to adapt their behavior accordingly. For example, given a channel and network conditions,
(3)
the physical layer can select properly the rate, power, and coding to meet application requirements [13]. One of the famous cross-layering algorithm is called cross layer optimized video streaming algorithm over multi-hop mobile adhoc networks. The control parameters of this algorithm (i.e. physical mode and retransmission limit) are determined based on the available information at application, Media Access Control (MAC), and physical layers in order to satisfy the end-to-end delay constraint and maintain packet loss rate in an acceptable level at the receiver [14]. In this thesis, chain and cross-topologies models are proposed using Simevents tools to illustrate the problems of multi-hop ad-hoc networks. OPNET simulator is used to validate these modes. Four-hop model is considered, based on the fact that these problems can be demonstrated in four hops (five nodes) [15-17]. Some algorithms are proposed using layering and cross-layering algorithms to improve the throughput stability and to reduce the delay in multihop wireless ad-hoc networks. The layering algorithms are Distributed Packet Scheduling Algorithm (DPSA) and Round Robin Scheduling Algorithm (RRSA), while the cross-layer algorithm is TCP Congestion Control (TCC).
1.1 Literature Review: 1. In 2000, G. Bianchi proposed a Markov process to demonstrate a simple analytical model to compute the saturation throughput of single-hop 802.11-based networks. It consisted of finite number of terminals and ideal channel conditions. The proposed analysis was applied to both the packet transmission schemes employed by
(4)
DCF, namely the basic access and the virtual (Request To Send/Clear To Send (RTS/CTS)) access mechanisms [18]. 2. In 2002, J. Li, Z. J. Haas and M. Sheng showed the performance of multi-hop ad-hoc networks for different network sizes. They presented the scaling laws of the throughput for large ad-hoc networks based on the 802.11 MAC if the number of nodes in the network ranges from 100 to 300, the guaranteed end-to-end throughputs per node for randomly distributed traffic model are 4.27~1.44 kbps with the 2 Mbps channel rate [4]. 3. In 2002, S. Rahman derived a general analytical model for DCF that may be used to find throughput under various traffic loads. He showed that this model could take hidden stations in static environments into account and provides limited results in dynamic environments where wireless stations may move arbitrarily [19]. 4. In 2003, Z. Fu, P. Zerfos et al studied the effect of multi-hop wireless link (shared medium) on TCP throughput and loss behavior for several simple network configurations and flow patterns based on IEEE 802.11 standard. They showed that the throughput of TCP improved significantly if it operates around certain Contention Window (CW) that achieves highest special channel reuse. They also proposed two algorithms, Link Random Early Detection (LRED) and Adaptive Pacing, which improved the throughput of standard TCP flows by 30% [20]. 5. In 2004, C. Ng, and S. C. Liew showed that there was a possibility to eliminate the re-routing instability and unfairness problems by controlling the offered load at the sources. They also estimated the optimal offered load that maximizes the throughput of a multi-hop ad-hoc traffic flow. In addition, they proved that when the carrier(5)
sensing range was larger than two times of the transmission range, RTS/CTS would no longer be needed [21]. 6. In 2004, H. Zhai, J. Wang and Y. Fang presented a framework of multi-hop packet scheduling to achieve maximum throughput for traffic flows in the shared channel environment. Based on the observation that in the IEEE 802.11 MAC protocol, the maximum throughput for chain-topology was 1/4 of the channel bandwidth and its optimum packet scheduling would allow simultaneous transmissions at nodes, which are four hops away [22]. 7. In 2005, E. Hamadani and V. Rakocevic showed that medium access contention and congestion losses were the dominant causes of packet drops in chain-topology multi-hop ad-hoc network. Then a modification to both TCP and IEEE802.11 MAC was proposed and evaluated. The basic concept behind the modification was that in order to minimize the packet contention drop, packets should be recovered at each hop rather than from TCP sender. It also showed that this modification could eliminate TCP throughput instability [23]. 8. In 2006, D. Kliazovich and F. Granelli proposed a novel method (a cross-layer congestion avoidance scheme) based on TCP to improve congestion control over multi-hop wireless networks, by providing means to effectively measure bandwidth and delay on the data path. In addition, they proposed optional field support to the existing IEEE 802.11 protocol in order to support the presented congestion control solution as well as many of other similar approaches [24]. 9. In 2007, C. Que, X. Zhang et al provided a simple analytical model to characterize the unfairness of 802.11 DCF. The effect of (6)
this model on the stability of the route in ad hoc networks was also studied. If the data rate was larger than the capacity of the route, conflicts and route broken messages usually generated in the first few nodes. The flow was very stable in the last few nodes. They investigated the traffic patterns of ad hoc networks in a singlechain environment with five nodes (four hops) [25]. 10. In 2007, H. Zhai, X. Chen, and Y. Fang illustrate that in the case of severe medium contention and congestion, the TCP’s congestion control algorithm would be disfunctioned causing a throughput instability and excessively long delay. They proposed a systematic solution named Wireless Congestion Control Protocol (WCCP) to address unfairness problem in both layers. WCCP used channel busyness ratio to allocate the shared resource and accordingly adjusts the sender’s rate so that the channel capacity could be fully utilized and fairness is improved [26]. 11. In 2008, W. Bo, S. Fei et al provided an analytical throughput model to compute the 802.11 DCF multi-hop networks throughput. This model is suited in non-saturated and finite number terminals conditions. It is different from previous network models. First, it considered wireless network in multi-hop and non-saturated
situation
Second;
this
analytical
model
quantitatively computed the impact of packet discard ratio factor in the network model analysis [27]. 12. In 2008, Y. Lien and Y. Yu proposed a hop-by-hop TCP protocol that makes every intermediate node in the transmission path of a TCP execute a local TCP (one-hop TCP) to guarantee the transmission of each packet on each link. The retransmission of a lost packet was right at the transmitting end of the link where the (7)
packet was lost. It took less time in average to deliver a packet in a high error rate environment. The fairness requirement was also achieved [28]. 13. In 2008, A. Valletta, A. Todini and A. Baiocchi showed, through simulation, that the competition between TCP flows in a multi-hop wireless network led to an unfairness performance. They studied the effect of hidden node collisions on the performance of multihop TCP flows; the source of the unfairness was related to the collisions between RTS frames belonging to the starved flow and long data frames sent by the active flow. Such collisions led to a rapid increase of the MAC contention window at the TCP sender of the starved flow; this, in conjunction with TCP’s congestion control algorithm, allowed the running flow to hold the channel for a long time, until the situation was reversed [29]. 14. In 2009, R. Verma, A. Prakash et al proposed a model for improving the throughput of multi-hop static ad-hoc networks chain-topology by using a Concurrent Transmission protocol (CTMAC). The simulation results showed the significant improvements of nearly 100% in the case of concurrent transmission protocol in multi-hop environment compared to that of IEEE 802.11 MAC protocol [17]. 15. In 2009, L. Wu, Y. Fu and L. Dong proposed a simple and efficient algorithm called Active Relinquish Scheme (ARS) to enhance the end-to-end throughput of multi-hop ad hoc networks. The idea behind this scheme was to equalize the throughput of each node through a multi-hop flow. Consequently, the fairness of the network was improved. Simulation results through OPNET
(8)
showed that this scheme gave good results for different kinds of topologies [30]. 16. In 2009, K. Saravanan proposed a cross-layer based on MAC protocol to completely utilize the channel bandwidth and to increase the fairness of each flow without causing congestion. In this protocol, the available bandwidth along each path (source to destination) was estimated based on a probing technique. The destination node sent probe packets to the source node so that the source node could estimate the available bandwidth and the contention level between them. Then the source selected the path that had enough bandwidth and the least contention, using a multipath routing protocol. In addition to this, a centralized flow scheduler was designed to overcome the overheads and drawbacks of the IEEE 802.11. The simulation results showed that the proposed protocol achieved high throughput and fairness [31]. 17. In 2010, W. Long and W. Zhenkai proposed a new acknowledgment (ACK) mechanism, called TCP Loss based ACK (TCP-LBA) to improve TCP performance in wireless networks. In TCP-LBA, TCP Receiver replied with ACK packet only when TCP Sender finished sending all pieces within the same TCP Window and there were packets lost during transmission. This scheme greatly reduced the ACK packets number, eliminating the bad influence of delayed ACK packets on the efficiency of the data transportation and kept transporting effective. Simulation results showed that this proposed scheme could significantly improve TCP throughput and reduce delay over wireless networks [32].
(9)
18. In 2010, T. Sugimoto, N. Komuro et al introduced a novel approach to the analysis of throughput for networks that used RTS/CTS by considering one-way flow in string multi-hop networks. The end-to-end network maximum throughput was obtained by analyzing the maximum throughput of bottleneck nodes. This analysis provided the transmission failure probability considering not only RTS-RTS collisions but also the influence of the Network Allocation Vector (NAV). The maximum throughput was evaluated using analytical and through a simulation techniques [33]. 19. In 2011, R. Pal Singh and D. K. Lobiyal presented an analytical model based upon discrete time Markov chain analysis of receiver-initiated protocols for multi-hop Ad-hoc networks. The effect of hidden terminals has been considered. The results showed that the receiver-initiated collision avoidance scheme achieved higher throughput than the sender- initiated collision avoidance scheme including short data packet as well as long data packet [34].
1.2 Thesis Contributions: The aim of this thesis is to improve the throughput performance of multi-hop wireless ad-hoc networks using proposed algorithms. On the other hand, this thesis has the following contributions: 1- A model for a single-hop wireless network with sub-layer MAC are proposed using Simevents tools given in Matlab software and validated practically.
(10)
2- A novel model of multi-hop wireless network with chain and cross-topologies is proposed using Simevents tools and validated using OPNET software.
3- Distributed Packet Scheduling Algorithm (DPSA) is designed and implemented using Simevents for the first time in this field of research.
4- TCP Congestion Control (TCC) as a cross layer algorithm is modeled using Simevents tools.
5- A new algorithm called Round Robin Scheduling Algorithm (RRSA) is proposed to stabilize the throughput performance of multi-hop wireless ad-hoc networks reliably.
1.3 Thesis Layout: The thesis consists of seven chapters including this introductory chapter; the following is a brief description of the following chapters: Chapter Two presents the background of wireless local area network. It begins with a description of Physical (PHY) layer and MAC sub-layer then a detail of CSMA/CA protocol is introduced. In addition, the types of IEEE 802.11 architectures are illustrated. Finally, IEEE 802.11 throughput and a delay of a single-hop ad-hoc network are analyzed mathematically.
(11)
Chapter Three is devoted to the theory of multi-hop wireless adhoc networks. Some of the challenges and problems are illustrated. Cross-layer solutions to these problems are introduced. Finally, a throughput analysis of multi-hop ad-hoc networks is performed. Chapter Four deals with the design of TCP and fairness algorithms for multi-hop wireless ad-hoc networks. Chapter Five deals with the design of various networks and algorithms such as single-hop, chain and cross-topologies multihop ad-hoc networks, DPSA, TCC and RRSA algorithms. Chapter Six presents the simulation results of the different proposed single and multi-hops ad-hoc models using Simevents and OPNET. It also includes the results of multi-hop ad-hoc wireless networks with the proposed algorithms. Finally, the conclusions and the suggested future work are given in Chapter Seven.
(12)
Chapter Two Wireless LAN background 2.1 Introduction: The 802.11 wireless standards cover the PHY and MAC layers as shown in Figure (2.1); the upper part of the Data Link layer (Open System Interconnection (OSI) Layer 2) is provided by Logical Link Control (LLC) services specified in the 802.2 standard. It provides the link to the Network layer and higher layer protocols [35].
3
2
1
Network Layer
Data Link Layer
Logical Link Control (LLC) Medium Access Control (MAC)
Physical Layer
Physical Layer (PHY)
OSI Model Layers
802.11 specifications
Figure (2.1): 802.11 Logical Architecture
The MAC sublayer is used to establish a network or join a pre-existing network and to transmit data through the Logical Link Control (LLC) [36]. 2.2 PHY Layer: The initial 802.11 standard recommends three alternative PHY layers; frequency hopping and direct sequence spread spectrum
(13)
in the 2.4 GHz band as well as an infrared PHY. All three PHYs delivered data rates of 1 and 2 Mbps. Table (2-1) shows physical layers with various IEEE 802.11 standards. Table (2-1): Physical layers. IEEE
Technique
Band
Modulation
Rate (Mbps)
802.11
FHSS
2.4GHz
FSK
1 and 2
DSSS
2.4GHz
PSK
1 and 2
Infrared
PPM
1 and 2
802.11a
OFDM
5.725GHz
PSK or QAM
6 to 54
802.11b
DSSS
2.4GHz
PSK
5.5 and 11
802.11g
OFDM
2.4GHz
Different
22 and 54
2.2.1 IEEE 802.11 DSSS: It uses the Direct Sequence Spread Spectrum (DSSS) technique. DSSS uses the 2.4-GHz Industrial, Scientific and Medical (ISM) band. The modulation technique in this specification is Phase Shift Keying (PSK) at 1 Mbaud/s. The system allows 1 or 2 bits/baud (Binary PSK or Quadrature PSK), which results in a data rate of 1 or 2 Mbps, as shown in Figure (2.2) [37].
1 or 2 Mbps Digital data
Modulation 11- Chip Barker sequence
11 or 22 Mbps
BPSK or QPSK
Figure (2.2): Physical layer of IEEE 802.11 DSSS
(14)
11 MHz Analog signal
2.2.2 IEEE 802.11b DSSS: It describes the High-Rate DSSS (HR DSSS) method for signal generation in the 2.4-GHz ISM band. HRDSSS is similar to DSSS except for the encoding method, which is called Complementary Code Keying (CCK). CCK encodes 4 or 8 bits to one CCK symbol. To be backward compatible with DSSS, HR-DSSS defines four data rates: 1, 2, 5.5, and 11 Mbps. The first two use the same modulation techniques as DSSS. The 5.5-Mbps version uses BPSK and transmits at 1.375 Mbaud/s with 4-bit CCK encoding. The 11-Mbps version uses QPSK and transmits at 1.375 Mbps with 8-bit CCK encoding. Figure (2.3) shows the modulation technique for this standard [38].
1 or 2 Mbps Digital data
1:4 or 1:8
5.5 Mbps: 2bits 11 Mbps: 6bits
CCK selector
Modulation QPSK
2 bits
11 MHz Analog signal
Figure (2.3): Physical layer of IEEE 802.11b
2.3 MAC Functions: IEEE 802.11 defines two MAC sublayers: the DCF and PCF. Figure (2.4) shows the relationship between the two MAC sublayers, the LLC sublayer, and the physical layer. It is worth to mention that DCF uses the protocol Carrier Sense Multiple Access with Collision Avoidance for the wireless channel access.
(15)
LLC sublayer
IEEE 802.2 Contention-free service
Data link layer
Contention service
Point coordination function (PCF) MAC sublayer
Distributed coordination function (DCF) 802.11 802.11 802.11 802.11b 802.11a 802.11g FHSS DSSS Infrared DSSS OFDM DSSS
Physical layer
Figure (2.4): PHY and MAC layers in IEEE 802.11 standard
Figure (2.5) shows the timing diagram of the CSMA/CA protocol, while Figure (2.6) shows the basic procedure of this protocol [39-41].
Contention Window
Station A
Slot time
DIFS 2
1
Defer Access
Data
Busy medium
0
Ack
DIFS
17 16 15 14
SIFS
Idle medium Station B Busy medium 9 8 7
6
5
DIFS
Slot time 5: frozen backoff time
4
3
2
1
Figure (2.5): Timing in CSMA/CA
(16)
0
Data
Start K=0
No Idle channel? Yes Wait IFS time No Still idle? Yes Contention window size is 2K-1
Choose a random number R between 0 and 2K-1
After each slot: If it is idle, continue. If it is busy, halt and continue when idle
Wait R slot Send frame Wait time-out
No K > 15?
No K=K+1
Yes
ACK received? Yes
Abort
Success
Figure (2.6): Flowchart of CSMA/CA (Basic access mechanism)
(17)
2.4 CSMA/CA and Wireless Networks: The procedure described in Figure (2.6), however, is not sophisticated enough to handle some particular issues related to wireless networks, such as hidden terminals or exposed terminals. These issues can be solved by augmenting the above protocol with hand-shaking features. 1.
Before sending a frame, the source station senses the medium by checking the energy level at the carrier frequency. a. The channel uses a persistence strategy with backoff until the channel is idle. b. After the station is found to be idle, the station waits the time DCF Interframe Space (DIFS); then the station sends a control frame called the request to send (RTS).
2.
After receiving the (RTS) and waiting the time Short Interframe Space (SIFS), the destination station sends a control frame, called the clear to send (CTS), to the source station. This control frame indicates that the destination station is ready to receive data.
3.
The source station sends data after waiting certain time that equals to (SIFS).
4.
The destination station, after waiting an amount of time that equals to (SIFS), sends an acknowledgment (ACK) to show that the frame has been received. ACK is needed in this protocol because the station does not have any means to check for the successful arrival of its data at the destination. On the other hand, the lack of collision in CSMA/CA is a kind of indication to the source that data have arrived [37]. Figure (2.7) shows the flowchart of CSMA/CA with RTS/CTS mechanism. (18)
Start Set backoff to zero Persistence strategy Wait DIFS Send RTS Set a timer
No
CTS received before time-out
Yes Wait SIFS
Wait backoff time
Send the frame Set a timer
No Backoff limit?
Increment backoff
No
Ack received before time-out
Yes
Yes
Success
Abort
Figure (2.7): Flowchart of CSMA/CA (RTS/CTS access mechanism)
(19)
It is important to mention that RTS frame includes the duration of time needed to occupy the channel. The stations that are affected by this transmission create a timer called a Network Allocation Vector (NAV) that shows time span necessary to access the channel. Each time a station accesses the system and sends an RTS frame, other stations start their NAV. In other words, each station, before sensing the physical medium to see if it is idle, first checks its NAV to see if it has expired. Figure (2.8) shows the idea of NAV and it also shows the exchange of data and control frames in time domain [37, 41].
Station A DIFS 2
1
RTS
Data
0
Station B
Other station
DIFS
SIFS
SIFS
Contention Window
Ack
CTS NAV (RTS) NAV (CTS)
NAV (Data)
Backoff and defer
Deferred access Figure (2.8): Timing in CSMA/CA using RTS/CTS mechanism Finally, the possibility of collision only has existed during the time when RTS or CTS control frames are in transition, and is often called the handshaking period. Two or more stations may try to send RTS frames at the same time. These control frames may collide. (20)
However, because there is no mechanism for collision detection, the sender assumes there has been a collision if it has not received a CTS frame from the receiver. The backoff strategy is employed, and the sender tries again.
2.5 IEEE 802.11 Architectures: The standard defines two kinds of services; the Basic Service Set (BSS) and the Extended Service Set (ESS). The standard also defines two modes of operation for the BSS, as follows:
2.5.1 Infrastructure mode: According to this mode of operation all communication between stations in a BSS goes through the access point, even if two wireless stations in the same cell need to communicate with each other. A simple example of a BSS in infrastructure mode is shown in Figure (2.9). The benefits of using a BSS rather than an Independent Basic Service Set (IBSS) is that the access point can buffer data if the receiving station is in a standby mode, temporarily out of range or switched off. In infrastructure mode, the access point takes on the role of broadcasting beacon frames. The access point will also be connected to a distribution system which will usually be a wired network, but could also be a wireless bridge to other WLAN cells. In this case, the cell supported by each access point is a BSS and if two or more such cells exist on a LAN, the combined set is known as an extended service set (ESS); see Figure (2.10) [37].
(21)
Distribution system (DS) connection AP Basic Service Set (BSS)
Figure (2.9): Infrastructure Mode Topology
Server or Gateway Distribution system
BSS
BSS
BSS
Figure (2.10): Extended service set (ESS)
2.5.2 Ad hoc networks: It is a collection of wireless mobile nodes which can communicate together without the need of access point or any type of controllers. Each node in a wireless ad hoc network functions as both a host and a router, and the control of the network is distributed among the nodes. Under ad-hoc mode, the service set is called an independent basic service set (IBSS), and in an IBSS all
(22)
stations broadcast beacon packets, and use a randomly generated BSS Identity (BSSID) [1]. Ad hoc networks can be either single-hop or multi-hop networks. The most basic Single-hop ad hoc network consists of two stations which communicate directly with each other. An example for a single-hop can be found in Figure (2.11) and for multi-hop ad hoc networks in Figure (2.12) [42-43].
Node B Node A Independent Basic Service Set (IBSS)
Node C
Figure (2.11): Ad-hoc Mode Topology
Node A as source
Node C as destination
Node B as router One hop
Two hop
Figure (2.12): Two hop (Multi-hop ad-hoc networks)
This mode of operation is used for the following purposes:
(23)
a. Mobility: Services demands increase when people have access to data in any location within the operating range of the WLAN [44]. b. Low implementation costs: ad hoc networks are easy to set up, manage, change and relocate. Networks that frequently change can benefit from WLAN ease of implementation. Adhoc networks can operate in location where installation of wiring may be impractical [44]. c. Installation and network expansion: installing the ad hoc network can be fast, easy and can eliminate the need to pull cable through walls and ceilings. Ad hoc networks technology allows the network to go where wires cannot go even outside the home or the office [44]. d. Scalability: Ad hoc networks can be configured in a variety of ways to meet the needs of specific applications and installations [44].
2.6 Ad hoc performance principles: An ad hoc network begins with at least two nodes broadcasting their presence (beaconing) with the irrespective address information. If node A is able to establish direct communication with node B in Figure (2.13), verified by exchanging suitable control messages between them, they will both update their routing tables. When a third node C joins the network with its beacon signal, two scenarios are possible and as follows:
1. Both A and B determine that single-hop communication with C is feasible. (24)
2. Only one of the nodes, say B, recognizes the beacon signal from
C
and
establishes
the
availability
of
direct
communication with C.
The three nodes must update topology (address and route) immediately afterwards. This is achieved according to the following cases: 1. 2.
Making all routes direct. Figure (2.13) shows that the route between B and C must be updated firstly then between B and A, after that between B and C, confirming the mutual reach ability between A and C via B [45].
Node A
Node B
Node C
(Topology update)
(Topology update) (Topology update)
(Topology update)
Figure (2.13): Bringing up an ad-hoc network (25)
The ad hoc performance functions can be divided into: 2.6.1 Management function: The beacon management frame is a special type of frame used in IEEE 802.11 networks. This frame is often referred to as the beacon. In an ad hoc wireless network (IBSS), all the stations take turns broadcasting the beacon frame. This is because there is no access point in an independent basic service set (IBSS). Beacon frames can be used by client stations seeking wireless network to join, or these client stations may scan for a wireless LAN using other types of frames known as probe request and probe response frames, as follow [45]: a. Active scanning uses probe request and probe response frames instead of the beacon frame to find a WLAN to join. A client station can use either of two general methods to find the WLAN. The first is to specify the BSSID of the network being sought, and the second is to seek for any BSS that may be able to hear and respond to the probe request. Figure (2.14) shows active scanning [46]. Probe response Probe request Probe response
Client
Probe response Figure (2.14): Active scanning (26)
b. In passive scanning the new station listens to each channel for a predetermined period and detects beacon frames transmitted by other stations. The beacon frame will provide a time synchronization mark and other PHY layer parameters, such as frequency hopping pattern; to allow the two stations to communicate [35]. Both methods are valid. A method is chosen according to the power consumption/performance trade-off. Figure (2.15) shows passive scanning, while Figure (2.16) shows management frame format [47].
Figure (2.15): Passive scanning
Octets: 2 Frame control
2 Duration
6
6
Destination address
Source address
(DA)
(SA)
6 BSSID
2
0-2312
Sequence control
Frame body
MAC header Figure (2.16): Management frame format
(27)
4 Frame check sum (FCS)
2.6.2 Control function: A node wishing to send data initiates the process by sending a Request to Send frame (RTS). The destination node replies with a Clear To Send frame (CTS). Any other node receiving the RTS or CTS frame should refrain from sending data for a given time (solving the hidden node problem). The amount of time the node should wait before trying to get access to the medium is included in both the RTS and the CTS frames. This protocol is designed under the assumption that all nodes have the same transmission range. It is obvious that the control functions rely on the following frames [1, 47]: a. RTS frame: The format of the RTS frame is shown in Figure (2.17). The destination address field of the RTS frame is the address of the intended immediate node which receives the directed data or management frame. The source address field is the address of the node transmitting the RTS frame.
Octets: 2
2
6
Frame Duration Destination control address
6
4
Source address
Frame check sum (FCS)
MAC header Figure (2.17): RTS frame format
The duration value is equal to: TD = Tt + TCTS + TACK + 3 ∗ SIFS ………. (2.1) Where: TD: Duration transmission time.
(28)
Tt : Transmission time of data or management frame. TCTS: Transmission time of CTS frame. TACK: Transmission time of ACK frame. If the calculated duration time includes a fractional microsecond, that value is rounded up to the next higher integer. The subfields within the Frame control field of control frames are set as illustrated in Figure (2.18).
Subtype
Type
B0 Protocol version
Bits:
To DS
Pwrm More From More Order DS Frag. Retry gt data WEP B15
Control
Subtype
0
0
0
0
Pwr mgt
0
0
0
2
4
1
1
1
1
1
1
1
1
2
Figure (2.18): Frame control field
b. CTS frame: The frame format of the CTS frame is as shown in Figure (2.19). The source address field of the CTS frame is copied from the source address
field of the immediately
previous RTS frame. Octets: 2 Frame control
2
6
Duration
Source address
4 Frame check sum
MAC header Figure (2.19): CTS frame format
(29)
c. ACK frame: The frame format of the ACK frame is as shown in Figure (2.20). The source address field of the ACK frame is copied from the Address 2 field of the immediately previous directed management. The More Fragment bit in the frame control field has two state:
1. If it is set to 1, then more fragments will follow. 2. If it is set to 0, then no more fragments will follow. Octets: 2 Frame control
2
6
Duration
Source address
4 Frame check sum
MAC header Figure (2.20): ACK frame format 2.6.3 Data transmission: The frame format of the data frame is independent of the subtypes, it is as defined in Figure (2.21).
Octets: 2 Frame control
2 Duration
6 Address1
6 Address2
6
2
Address3 Sequence control
6
0-2312
Address4 not used
Frame body
4 FCS
MAC header Figure (2.21): Data frame format of ad-hoc network
The content of the Address fields of the data frame is dependent upon the values of the "To DS" and "From DS" bits which is equal to zero in ad hoc network as shown in Table (2-2) [37].
(30)
Table (2.2): Address field contents. To DS
From DS
0
0
Address1 Address2 Address3 Address4 DA
SA
BSSID
N/A
The field which is known as not applicable (N/A) is omitted. Note that Address 1 always holds the receiver address of the intended receiver, and Address 2 always holds the address of the station that is transmitting the frame. Address 3 field contains a group address, the BSSID also is validated to ensure that the broadcast or multicast originated in the same BSS. A node uses the contents of Address 2 field to direct the acknowledgment if it is necessary. The DA field is the destination address of the MAC Service Data Unit (MSDU) in the frame body field. The SA field is the source address of the MAC entity that initiated the MSDU in the frame body field.
2.7 IEEE 802.11 throughput Analysis of a single-hop Ad-hoc networks: The analysis is divided into two distinct parts. First, the behavior of a single station with a Markov model is be studied and how to obtain the stationary probability (τ) that the station transmits a packet in a generic (i.e., randomly chosen) slot time. This probability does not depend on the employed access mechanism (i.e., Basic or RTS/CTS). The second one takes into account the study of the events that can occur within a generic slot time, the throughput of both
(31)
Basic and RTS/CTS access methods must be expressed as a function of the computed value (τ).
2.7.1 System model assumptions: 1. A system of N nodes, which is uniformly distributed over an a*a m2 is to be considered in this study (a = 100m). 2. All terminals equipped with omni-directional antennas and with IEEE802.11 cards that use basic access mechanism (the default mode of operation for most wireless cards). 3. The time is slotted and the duration of each time slot is σ. 4. Each packet has a fixed length and consists of (P) data bits and (H) header bits. 5. ACK packets have fixed length. 6. The maximum propagation delay in the network is equal to (α). 7. The data rate (R) is fixed and is not affected by any changes in the transmit power. 8. A single-hop ad hoc network (a network without hidden terminal problem) is assumed.
2.7.2 Throughput analysis: The throughput (S) is defined as the fraction of a cycle (busy + idle intervals) where the channel is utilized to send useful data. The maximum load that a network can handle in stable conditions is defined as the saturation throughput and is the limit that the system throughput reaches as the offered load increases [48]. The duration of an idle period is I (with a mean I ), the duration of a busy period is B (with a mean B), and the duration of a (32)
useful period is U, (with a mean U), the throughput S is given by [49] : S=
U B+I ….. (2.2)
To find the throughput, the transmission time is divided into three periods (I , B , and U) as shown in Figure (2.22) [50]. For a slotted CSMA network of N nodes and slot duration (σ), the probability that an idle period lasts for (k) slots is given by: Pr I = kσ = 1 − 1 − p N )( 1 − p
N k−1
….. (2.3) Where p is the conditional collision probability (which is to be calculated later) [18]. Successful transmission period
T
Idle period
Unsuccessful transmission period
Idle period
γ
Time σ Figure (2.22): Three periods (I , B , and U) (33)
The average value of I is obtained by [18]: I=
k kPr (i
= kσ)
..…(2.4)
where: i is represented the iteration of the packet
I=
σ 1 − (1 − p)N ….. (2.5) On the other hand, Ts denotes the time of the channel
occupied by a successful transmission, and Tc is the time of the channel which is subjected to a collision, accordingly [18]: Ts = DIFS +
H P ACK + + α + SIFS + +α R R R ….. (2.6)
Tc = DIFS +
H P + +α R R …… (2.7)
To simplify the analysis, the following approximation can be applied: Tc ≈ Ts
…… (2.8)
The probability that a busy period contains k transmissions is given by [18]: Pr B = k ∗ Ts = (1 − p)N (1 − 1 − p N )k−1 …… (2.9) The average of B is thus obtained by taking [49]: B=
kPr(B = kσ) k
(34)
…… (2.10) B=
Ts (1 − p)N ….. (2.11) The useful period is that period where the channel is being
used to send data. If T denotes the data transmission time, T is given by: T=
P R ….. (2.12) Assume that Pss denotes the probability that a transmission
on the channel is successful, Pss is therefore given by [49]: Np(1 − p)N−1 Pss = 1 − (1 − p)N …… (2.13) The average useful transmission, U, time is given by: U=T∗
B ∗ Pss Ts ..….. (2.14)
U=
TNp (1 − p)(1 − 1 − p )N …….. (2.15)
The throughput expression for a single hop network of N nodes is then given by [49]: TNp(1 − p)N−1 S N = Ts + (σ − Ts)(1 − p)N …..… (2.16) To complete the analysis, the collision period γ which depends on the retransmission probability can be found as follow: (35)
2.7.3 Packet Transmission Probability: The analysis is based on the assumption that: a) Each station has immediately a packet available for transmission,
after
the
completion
of
each
successful
transmission b) Each packet needs to wait for the time DIFS before transmitting [18]. The state probabilities, for a network consisting of N nodes, at steady state, are given in Table (2-3) [49]. Note that the number of nodes that appears at the sending node is equal to (N-1), and the state probabilities would have to be modified accordingly. Table (2-3): Various state probabilities. Probability that at least one
Ptr = 1-(1-p)N
transmission is initiated in a slot. PI = 1-Ptr=(1-p)N
Probability that a slot is idle. Probability that a collision occurs
Pc = Ptr(1-Ps)
in a slot. Probability that a given node’s
Ps = (1-p)N-1
transmission is successful. Probability that a given node’s
Pcoll = 1-(1-p)N-1
transmission is unsuccessful (i.e. packet collides). Probability that a slot contains the
start
of
a
successful
transmission.
(36)
Psuc = Np(1-p)N-1
Let b(t) be the stochastic process representing the backoff time counter for a given station. Assume that: t and t+1 are the beginning of two consecutive slot times, and the backoff time counter of each station decrements at the beginning of each slot time. It is worth to mention that the backoff time decrement must be stopped when the channel is sensed busy [18], see Figure (2.7). Since the value of the backoff counter of each station depends also on its transmission history (e.g., how many retransmissions a packet has suffered), the stochastic process b(t) is non-Markovian and W can be expressed by W=CWmin. It is also possible to use CWmax=2mW to represent the “maximum backoff stage”. It is easy to conclude that the notation, Wi=2iW where i ∈ (0,m), represents any “backoff stage”. Let s(t) be the stochastic process representing the backoff stage (0,…,m) of the station at time t. At each transmission attempt, and regardless of the number of retransmissions suffered, each packet has constant and independent probability p of collision. With this assumption, the results are more accurate as long as W and N get larger, p will be referred to as conditional collision probability, meaning that this is the probability of a collision seen by a packet being transmitted on the channel. Also p is supposed to be a constant value, it is possible to model the bidimensional process {s(t), b(t)} with the discrete-time Markov chain depicted in Figure (2.23). In this Markov chain, the only non null one-step transition probabilities are [18]:
(37)
P i, k\i, k + 1 = 1 1−p P 0, k\i, 0 = W0 p P i, k\i − 1,0 = Wi p P m, k\m, 0 = Wm
k ∈ 0, Wi − 2 k ∈ 0, Wi − 1 k ∈ 0, Wi − 1
i ∈ 0, m i ∈ 0, m i ∈ 1, m
k ∈ 0, Wm − 1 .... (2.17)
The first equation in (2.17) accounts for the fact that, at the beginning of each time slot, the backoff time is decremented. The second equation accounts for the fact that a new packet following a successful packet transmission starts with backoff stage 0, and thus the backoff is initially uniformly chosen in the range (0,W0-1). The third equation of (2.17) shows that when an unsuccessful transmission occurs at backoff stage, the backoff stage increases, and the new initial backoff value is uniformly chosen in the range. Finally, the fourth case models the fact that once the backoff stage reaches the value m, it is not increased in subsequent packet transmissions [18].
Let bi,k =limt→∞ P{s(t)=I, b(t)=k}, i ∈ (0,m), k ∈ (0,Wi-1) be the stationary distribution of the chain. Now, to obtain a closedform solution for this Markov chain [18, 51, 52], first, note that: bi−1,0 ∙ p = bi,0 → bi,0 = pi b0,0
0 1
ACDH(M) ACDH(M − 1)
Yes
if ∆T ≥ 1
Yes
No
if ∆C ≥ 1
Yes
TCP_Contention = TCP_Contention + MSS
3
TCP_Contention = 2 ∗ MSS
TCP_Contention = TCP_Contention −
4
TCP_Contention = TCP_Contention +
MSS ∗ MSS TCP_Contention
MSS ∗ MSS TCP_Contention
4
3
if M = 𝑅
No
Yes End
Figure (4.8): The flowchart of TCC cross layer algorithm.
(104)
2
The most important task is how to send the value of TCP_Contention from destination to source. It is worth mentioning that the TCP sender advertises the received congestion window (rcwnd) of its own receiver (available receiving buffer size) in order to avoid saturation by a fast connection (flow control). The uses of rcwnd to accommodate the value of TCP_Contention allow the receiver to control the transmission rate of the TCP sender. Therefore, when TCC is used, the new value of the received window (rwnd) becomes the minimum of TCP_Contention and
the
available
buffer
size
in
the
receiver
is
(available_receiver_buffer).
rwnd = min { available_receiver_buffer , rcwnd }
....(4.5)
The TCP_Contention remains fixed (between two changes) to make sure the packets received by the receiver are sent into the network after the sender has applied the changes imposed by the receiver.
In this thesis, TCC as a cross layer algorithm is implemented using Simevents tools. Figure (4.9) shows the Simevents modeling of this algorithm.
(105)
DeltaC=1
Delta T A1
In1
Out1
p
OUT1
IN
OUT2
Conn1
LG
DeltaT=1
OUT
IN
OUT2
Get Attribute1 Output Switch In1
Subsystem1
p
Out1
OUT1
DeltaC=1 IN
OUT2
Conn1
GG
pp4 GERGER Output Switch2
Figure (4.9): The modeling of TCC algorithm using Simevents technique. (106)
As shown in Figure (4.9), the model of TCC consists of the following blocks: 1. Subsystem 1: Figure (4.10) shows the details of this subsystem which consists of the following blocks: a) RTT, CPRTT and Generator blocks: These blocks represent a generator for random time of RTT, random number of packets in one RTT and the generation of events respectively. The generation of events in this case means generation of packets. b) Signal Latch block: It is used to introduce delay or resample signals based on events (not time). In addition, this block is used as a control unit to manage the signals.
wvc out
A2
Out1
In1
Out2
In2
A1
Comparison
in Signal Latch RTT
A3
A2
wvc out
A4
in
A3
Signal Latch1 CPRTT
A8 A4
No. of packets in one RTT tr A9
#d
IN
OUT IN
OUT
A5
Entity Departure Counter1
A10
A6 A11 A7 A12
Attribute Function
Attribute Function1 OUT
OUT
IN
1 output1
Get Attribute Generator of packets
Set Attribute
Figure (4.10): Subsystem 1, which contains the generation of packets and some process of TCC algorithm.
(107)
c) Set attribute block: This block accepts an entity, assigns data to it, and then outputs it. The assigned data is stored in attributes of the entity, where each attribute has a name and a value. d) Get attribute block: This block outputs signals using data from attributes of entities. For each arriving entity, the block updates the signal at the signal output ports using values of the attributes named in the block dialog box. The block also outputs the unchanged entity. e) Comparison block: This block is used to check the number of packets (CPRTT) in each RTT through a comparison bteween the number of packets departure and (CPRTT). Figure (4.11) shows the structure of this block. 1 1 1
Out1
In1
Initial Value1 =
1 Out1
1 Constant2 Relational Operator 1 Constant1
Figure (4.12): Subsystem 2 and 3, realization of condition (∆C).
3. Output switch block: This block receives entities, which depart through one of the multiple entity output ports. The selected port can be changed during the simulation based on the port (p) situation. 4. LesLes, LesGer,GerLes and GerGer blocks: These blocks consist of two main blocks: Get attribute and Entitiy Sink Block which provide a way to terminate an entity path. Figure (4.13) shows the structure of one of these blocks. (109)
A1
1
GL
IN
Discrete Event Signal to Workspace
1
Conn1
Constant1 OUT
IN
Get Attribute
#a
1 GL
Entity Sink
Figure (4.13): GerLes block, the end of packet. 4.4.2 Fair Backoff algorithm (FBA): This Algorithm is proposed to address the inter-flow instability. It can tackle the instability encountered by multiple flows sharing the channel while avoiding any control message exchange between competing nodes. It is simple and can be implemented practically. Since the contention window is the main parameter used in each node to access the channel, each node using FBA can be defined by three different stages shown in Figure (4.14) and as follows:
Normal Successful channel access
Failed channel access Failed channel access Successful access
channel
Greedy
Restrictive
Failed channel access
Successful channel access
Figure (4.14): Different node stages in a FBA scheme.
(110)
Normal: A station has entered this stage when firstly has stored data to send and secondly it has either recovered back from a failed channel access or failed to gain the channel after a successful transmission. The main purposes of this stage are [79]: 1. Improving short-term fairness and thus instability. 2. Decreasing the number of collisions between contending nodes by assigning relatively large CW in this stage.
Restrictive: After a successful channel access in the Normal stage, the node enters a Restrictive stage where the probability of node’s channel access decreases with respect to the number of consecutive channel access events and increases with its buffer size. This stage has been designed to force the successful nodes to release the channel in favor of others while giving higher priority to the congested node compared to non-congested ones [79].
Greedy: if the node at normal stage is unsuccessful after choosing its initial backoff then, it will enter the Greedy stage where the station takes high priority to access the channel by choosing relatively smaller CW compared to successful stations. This stage will help to prevent nodes from getting starved while avoiding further collisions by the station [79]. Each node then chooses an appropriate CW according to the following equation: CW = CWmin
CWmin ∗ Tradeoff_co ∗ [1 + Nsuccess ∗ (1 − buffer_co) CWmin ∗ Nfailed
Normal Restrictive Greedy ….. (4.6)
(111)
Where Nsuccess and Nfailed are the number of consecutive successful and consecutive failed channel access tries (and not necessarily failed transmission try) seen by each node, respectively. Also it defines two other variables called Tradeoff Coefficient (Tradeoff_co) and Buffer Coefficient (Buffer_co) which are both critical to the performance of the algorithm.
1. Tradeoff_co is an integer number between 1 (i.e. CW= CWmin) and 33 (i.e. CW=CWmax). It assigns relatively large CW to the nodes with high probability of collisions between them when they are in normal stage. This will cause smaller number of packet collisions and will improve short-term fairness as it gives equal opportunity to nodes coming from different stages regardless of their prior stage. On the other hand, a large value of Tradeoff_co will lead to a greater number of idle slots in the channel which obviously degrades the achieved throughput. Therefore, the value of Tradeoff_co can be seen as the tradeoff between the achieved fairness and the throughput.
2. Buffer_co is a number that lies between 0 and 1 and gives higher priority to nodes in a more congested area of the network. To understand Buffer_co in the restrictive stage, consider again cross topology as shown in Figure (4.15) where ideally the probability of accessing channel by node C should be higher than other relaying nodes. This is related to the function of C which routes packets from two connections. Buffer_co is defined as follows [79]:
(112)
0 Buffer_co =
buffer −Thresh min Thresh max −Thresh min
Buffer ≤ Threshmin Threshmin < 𝐵𝑢𝑓𝑓𝑒𝑟 < Threshmax
1
Buffer ≥ Threshmax
…..(4.7)
Where Buffer is the current number of packets inside the MAC buffer; Threshmax and Threshmin are chosen to be 20% and 80% of the maximum buffer size, respectively. It should be noted that Buffer_co is used to measure the contention around each node. This is because the amount of contention around each node reflects its buffer occupancy ratio.
Source 2 Connection 2
F
G Destination 1
Source 1
A
B
C
D
E
Connection 1
H Destination 2
I
Figure (4.15): Multiple TCP flows (two connections) in a cross-topology.
(113)
4.5 Round Robin Scheduling Algorithm (RRSA): Round Robin Scheduling (RRS) is one of the simplest scheduling algorithms; it assigns time slot to each process in equal portions and in a circular order, and treats all processes without priority. It is successfully applied to data packet scheduling in computer networks. It can easily be proved that RRS results in max-min fairness if the data packets are equally sized. This is related to the fact that the data flow which has waited the longest time is given scheduling priority; Figure (4.16) shows an example of how to apply RRS by a Switch to select in sequence four types (sets) of entities stored in First In First Out (FIFO) buffers.
OUT
Entity Generator 1
IN
OUT
Set Attribute1
IN
OUT
IN1
FIFO Queue1
[Type=1]
OUT
Entity Generator 2
IN
OUT
Set Attribute2
IN
OUT
IN2
FIFO Queue2
[Type=2]
OUT
IN
OUT
Single Server OUT
Entity Generator 3
IN
OUT
Set Attribute3
IN
OUT
IN Attribute Scope
IN3
FIFO Queue3
[Type=3]
OUT
Entity Generator 4
IN
OUT
Set Attribute4
IN
OUT
IN4
FIFO Queue4
[Type=4] Input Switch
Figure (4.16): Example of Round Robin Scheduling (RRS) process.
(114)
When the switch selects an entity, it makes other entities unavailable, regardless of how long it takes for an entity to arrive at the selected port. Figure (4.17) and Figure (4.18) show the output of attribute scope for the cases of equal and unequal data rate of all entities.
Figure (4.17): The output of switch for equal data rate using (RRS).
Figure (4.18): The output of switch for unequal data rate using (RRS).
(115)
It is easily to conclude from the Figures that RRS is suitable for cross-topology in multi-hop ad-hoc networks. For a single-hop flow, the source node may continuously transmit multiple packets generated from the same application if using FIFO scheduling because the source node could have as many packets as the application injects into the queue. This is unfair to other flows, which may pass through this node leading to a significant deterioration in their throughput performance. On the other hand, if the RRS is adopted in each node then two or more flows can be passed efficiently. Figure (4.15) shows how two flows can cross node C. It is obvious that node C can apply Round Robin Fashion (RRF) to obtain the required fairness (i.e. It could alleviate the unfairness by multiplexing the flows cross the channel). As mentioned before, and according to DPSA, each multihop flow at the source node and the following forwarding nodes should wait for the next few hops to finish forwarding the received packets before transmitting new ones; this will cause the intra-flow contentions to be avoided. RRSA is proposed to combine distributed packet scheduling algorithm (achieve optimum packet scheduling for chain topology and avoid severe intra-flow contention in each flow) and Round Robin Scheduling to improve the performance of cross topology of multihop ad-hoc networks. The implementation of the proposed algorithm (RRSA) using Simevents tools will be detailed in Chapter 5.
(116)
Chapter Five Design of a Single-hop and Multi-hop Wireless Adhoc Networks using Simevents
5.1 Introduction: This Chapter attempts to design various networks and algorithms such as single-hop, chain-topology multi-hop, crosstopology multi-hop ad-hoc networks, DPSA, TCC and RRSA algorithm.
5.2 Design of a single-hop ad-hoc network using Simevents: Figure (5.1) shows a single-hop wireless ad-hoc network which is based on Simevent tools given in Matlab software version (2011a). This model is based on the following assumptions: 1. The transmission range is set to 100 m according to the IEEE 802.11 standard [23, 91]. 2. In physical layer, the Direct Sequence Spread Spectrum (DSSS) technology with 2 Mbps data rate is adopted [92]. 3. A free-space channel with no external noise is considered. 4. Each node has a 20 packet MAC layer buffer pool. 5. The application operates with the condition that there are always ready packets for transmission. The scheduling of packet transmission is FIFO. 6. Packet size is assumed to be fixed at 1460B. 7. The maximum number of retransmissions at MAC layer is set to 16 for all packets.
(117)
8. All scenarios consist of nodes without any mobility. 9. ACK size is assumed to be 14B (as specified in IEEE 802.11 MAC standard). 10. The sender cannot receive during the data transmission.
#Collisions 1 #collision
#Collisions 5
Packets Send2 [C1]
[ok1]
in
coll1
en1 #collisions
From_d1
#success
From_ch1
hops Source en
hops
[ok1] Goto_a
[C1]
collision
From_coll7
In1
#Reciev ed collision
T ch1
[ok1]
[C1] Goto_N
Packets Received1 Conn1
en Out1
From_a F ch1
Rx_ack to node3 Conn4
Tx_ack
Packets send to node 3
Source Channel1 Destination
Figure (5.1): Proposed modeling of a single-hop ad-hoc wireless network using Simevents tools. As shown in Figure (5.1), the model consists of three main blocks (two computers and one channel); the first computer represents the source (sender) and the second one represents the destination (receiver).The details of these blocks are as follows: 5.2.1 Source unit: This unit consists of several blocks and three subsystems as shown in Figure (5.2) and as follows: a) Packet generator: This block is designed to generate packets using intergeneration times, which is the time (exponential distribution) between two successive generation events.
(118)
b) Enable gate: It represents a gate that is opened whenever the control signal at the en input port is positive, and closes whenever the signal is zero or negative. It is worth to mention that the Initial Value block provides an initial value of 1 that opens the gate to permit the first packet to pass when the simulation starts; the remaining packets pass through this gate when the en input port is positive. In this model, the en is positive when receiving a packet or ACK. 1 [en1]
[ok]
en
In1
From_ok
From
[fail]
OUT
Initial Value OUT
IN
Conn2
IN
pck_send
#d
In2
From_fail
OUT1
Conn1
OUT
IN
OUT
1 T ch1
IN OUT2
Packet Generator
Enabled Gate
Conn3
Set Attribute
Replicate (send to channel)
Subsystem 1
Start Timer
#collision 1
#sum
A1
SrcAddr
1
A1
coll1
OUT
Goto_fail
A2
#collision
A3
collision
2 F ch1
IN
A1
#collision1
A2 OUT
Entity Sink2
throughput1
OUT
OUT4
Infinite Server (zero delay)
[ok]
succ
IN
IN Set Attribute1
IN
Get Attribute1
#a
Entity Sink1 OUT3
Backoff Controller OUT
Set Attribute Collision
IN
#success [ok] Goto_ok
IN
A3
bckof f Time
IN2 Path Combiner1
2
route
OUT2
IN
IN1 OUT
OUT1
[fail]
#f ailure
Output Switch
From_ok1 [en1]
Throughput 1 ack1 Conn1
#d en
Goto OUT1
p
ack2 Conn2
IN
Check Destination
OUT IN
OUT
IN
OUT
Throughput 2 Get Attribute Subsystem 3
2
A2
hops OUT2
In1
en IN
3 throughput2
Out1
A1
Enabled Gate1
Infinite Server ( zero delay)
Output Switch1
Figure (5.2): The proposed structure of a Source based on Simevents tools.
c) Subsystem 1 unit: It is used to buffer the newly generated packets and to introduce delay to the failed packets. It consists of several blocks and subsystem A as shown in Figure (5.3) and as follows:
(119)
Constant (Source Address) #tx
1 1
#success
In1 2
state
1
#f ailure
In2 Subsystem A
en
IN1
Conn1
#d
OUT
IN
OUT
A1 len
in OUT
3
IN
Conn3
buffer Scope1
IN
OUT
2 Conn2
IN2
Single Server (Current TX packet)
IN
OUT
Transmission Buffer
IN
OUT
Set Attribute Transmission Control (Initialize TX info)
Path Combiner1
Server
Figure (5.3): The structure of subsystem 1 in Source node.
1. Transmission Buffer: This block stores up to N entities simultaneously, where N is the capacity parameter value (in this thesis, N=20 packets). It attempts to output an entity through the out port, but retains the entity if the out port is blocked. In the case of storing multiple entities, the entities depart in a FIFO fashion. 2. Server: This block serves one entity for a given period of time, and then attempts to output the entity through the out port. If the out port is blocked, then the entity stays in this block until the port becomes unblocked. The service time can be specified, which is the duration of service, via a parameter, attribute, or signal, depending on the service time from parameter value. In this place, the service time equals zero. 3. Transmission Control: It is similar to enable gate, and (#d) represents the number of sent packets.
(120)
4. Path Combiner 1: This block accepts entities (old or new packets) from any entity input port and outputs them through a single entity output port. The number of entity input ports is specified using the number of entity input ports parameter. 5. Constant: This block generates a real or complex constant value. In this study, the value of the constant represents source address which equals to 1. 6. Single Server: It is similar to a Server, but in this study, the service time is assumed to be equal to the Backoff time. New packet has Backoff time equal to zero while the packet which suffers from collisions has a backoff time equal to a specific value. 7. Subsystem A: The function of this subsystem is to delay the new packet until the old packet is transmitted successfully, or dropped if the number of retransmissions exceeds the maximum allowable value. Figure (5.4) shows the structure of this block. 1 Constant 1 1
#tx
1 state
2 Initial Value
#success 3 #failure Subtract
Figure (5.4): The structure of subsystem A in subsystem 1.
d) Replicate block: It delivers a copy of the arriving entity through each entity output port that is not blocked. According to the (121)
number of entity output ports parameter, the number of copies is specified. e) Subsystem 2: It represents the backoff algorithm for CSMA/CA which is similar to the backoff algorithm of CSMA/CD. f) Start Timer: This block associates a named timer with each arriving entity independently and starts the timer. It is used with Read Timer block to calculate the end-to-end delay of each packet. g) Subsystem 3: The throughput and delay are calculated by this block as shown in Figure (5.5). -CThroughput calculation #a
1 succ
Entity Sink1
Signal Scope
Product1
in
et
2
IN
throughput2
#a Product2
1 Conn1
Received ack from node1
1 throughput1
IN
IN
Entity Sink2
OUT
2 Conn2
Read Timer1
Figure (5.5): The structure of subsystem 3 in source node. 1. Entity sink: It provides a way to terminate an entity path; on the other hand, it is sinking for the packets. (#a) represents the number of entities (packets) that this block has accepted. 2. Read Timer 1: This block reads the value of a timer that the Start Timer block previously associated with the arriving entity. By using the report elapsed time (et) and report average elapsed time (w) parameters, the configuration of this block can be achieved.
(122)
3. Throughput calculation block: It is used to calculate the throughput. In any LAN, the throughput depends on the number of successful packets through a given time. In WLAN, the throughput does not depend on the number of successful packets through a given time only but also depends on arriving ACK to the source of the packet. Therefore, the number of ACK packets represents the successful packets. In this thesis, the time of simulation is equal (300 Second) and the throughput is calculated as follows: S=
The number of ACK ∗Size of packet Time of simulation
=
The number of ACK ∗1460 ∗8 300
(bps)
…… (5.1) 5.2.2 The channel unit: The modeling of wireless channel is proposed as shown in Figure (5.6). The channel is divided into two parts: a) The packet path: The arrival packet enters the channel from port (In 1) then the source address is checked to drop the unwanted packet in the entity sink, while the wanted packet is delayed by (DIFS) to represent the basic mechanism of IEEE 802.11. After that, the packet takes a random number that represents the random number of time slots then this packet will enter the contention process as shown in Appendix B. The contention process carries the address number of winner node (enable signal), and the number of collisions of the packet using the get attribute block which will extract the attributes (source en and collision). Finally, the packet is delayed according to
(123)
the chosen number of time slots and the following equation [45], then the packet exits from out port 1: A1 Check source b1 A1
In1
p
Out1
OUT1
IN A2
2
OUT
Entity Sink
IN
b2
In1 OUT
IN
Get Attribute1
OUT2
IN
IN
Set Attribute
DIFS
Output Switch
A1
OUT
1 Source en
IN
A2
2 collision
OUT
IN
OUT
IN
OUT
1 Out1
Contention
Get Attribute 2
3
OUT
Slot time Server
IN
Single Server
4
Rx_ack
Tx_ack ACK Server
Figure (5.6): The proposed modeling of wireless channel.
Delay = Packet transmission time + propagation delay …… (5.2) Where : Packet transmission time = (Packet length / Data Rate) propagation delay = (Distance between two nodes/ speed of signal in air) b) The ACK path: The arriving ACK packet enters the channel from port (Tx_ack) then it will be delayed by the server according to equation (5.2) taking into account that the ACK packet length is equal to (14B). In single-hop, the ACK packet does not suffer from collision while this is not the case in multi-hop ad-hoc where the hidden terminal problem may cause collision between data and ACK packets.
(124)
5.2.3 The destination unit: Figure (5.7) shows the details of this unit which consists of the following main blocks: a) FIFO Queue 1: This block is used to store the arrival packets, which comes from a channel. The packet remains in the queue until the signal enable is activated which will open the gate (Enable Gate 1), then a server will delay the packet by SIFS. b) Replicate: This block outputs a copy of the arriving entity through each entity output port that is not blocked. The number of copies is specified by the number of entity output ports parameter. Three copies can be specified as follows: 1. OUT' 1: It represents the original arrival packet, which enters from the Output Switch block. The packet has the following two probabilities (based on the destination address within the packet): a) If the destination address is similar to the desired destination address, the packet enters Read Timer block, Delay of the packet from source to destination is measured. b) If the destination address is different from the desired destination address then the packet will enter (Enable Gate 2) block and is terminated by the sink block. 2. OUT' 2: It initiates the ACK packet generation using the (Set Attribute) block then the already received source and destination addresses will be exchanged, after that a timer is added to the ACK packet and then is directed to the buffer. Subsystem 3 is used to check the destination address of the ACK packet before transmitting it. (125)
Signal Scope1
Output Switch #d 1
In1
Out1
2
en
in
#Recieved
et
en1 Subsystem1
OUT
IN
OUT
IN
A1
In1
Out1
p
OUT1
IN OUT
D_buffer1
Subsystem2
IN
SIFS
len 1 Conn1
Read Timer
OUT
to Workspace2
IN Entity Sink
en
Enabled Gate1
Get Attribute1
OUT
IN
IN
OUT
OUT2
IN
#a
3 to node3
IN Entity Sink1
FIFO Queue1
Enabled Gate2
' OUT1
IN
#d IN
OUT
Set Attribute1
' OUT2
to Workspace1 IN
len OUT
IN
OUT
D_buffer2
IN A1
' OUT3 OUT Set Attribute
IN
Start Timer
p
OUT1
IN
IN
OUT2
Entity Sink3
FIFO Queue Get Attribute
2
Out1
Subsystem3 OUT
Replicate
In1
Output Switch2
In1 Out1
collision Conn1
1
2
#collisions
Conn4
Calculation the # colision
Figure (5.7): The proposed modeling of destination node. (126)
3. OUT' 3: It will deliver the packet to (Calculation the # collision) block. c) Calculation the # collision block: Figure (5.8) shows the details of this subsystem. It is used only to calculate the number of collisions using the counter block. After that, the packet is terminated by the sink block. d) Subsystem 1 and 2: The first block is used to check the source address while the second one is devoted to check the destination address.
1
In1
Out1
1 Out1
In1
OUT
Subsystem A 1
A1
tr
IN
IN OUT
IN
Conn1 Entity Departure Counter
Get Attribute2
Entity Sink2
Figure (5.8): The details of (Calculation the # collision) block.
5.3 Design of multi-hop ad-hoc networks using Simevents: In this thesis, the design of multi-hop ad-hoc networks is proposed. It is worth mentioning that this section is devoted to the additional sub-systems which are not mentioned previously and as follows: 5.3.1 The intermediate node: Multi-hop ad-hoc networks require intermediate nodes to complete the transmission of data between source and destination nodes. These nodes behave like routers; therefore, the design should contain several specific blocks such as
(127)
Replicate, Path combiner and Switch. A flowchart of how to design this node is illustrated in Figure (5.9).
Start Packet generate (node1) or arrival (other nodes) Set attribute for packet 1-Sequence of packet 2- Packet size (pck=11680 bit) Buffer
Success signal
Failed signal
Gate controller
5
4
Enable
Enable Set attribute for packet 1- Source Address 2- Backoff time = 0 3- Number of collision=0
Retry packet
6
Path combiner Server (service time = backoff time)
Replicate
No
If address of destination = address of node
Yes
Sink packet
Set attribute for ack 1- Source address 2- Destination address 3- Ack size(ack=112bit) Enable Gate controller Replicate
2
RX _ok
Buffer
Path combiner
Send to Channel 2
1
Send to Channel 1
Continue. (128)
3
2
1 Get attribute for ack Destination address
If destination ≥ address of node
No Sink of packet
Yes
Enable from Channel 1 Enable
Check destination
Gate controller Ack from Channel 2
Send to Channel 2
Enable from Channel 2
Path combiner Number of collision from Channel 1 Set attribute Number of collision
Get attribute
Adder Number of collision from Channel 2
1- Source address 2- Backoff time 3- Number of collisions
Backoff system
4
Failure Route Number of collision Backoff time
Infinite server (service time=0) Set attribute 1- Route 2- Number of collision 3- Backoff time
Switch
RX _ ok TX _ ok Failure Retry
Route 1
3
Route 2 Route 3 Route 4
Sink of packet
5
Sink of packet
6
Figure (5.9): The flowchart of a typical intermediate node.
(129)
Figure (5.10) shows the flowchart of the CSMA/CD backoff algorithm which is to be implemented using Simevents tools.
Backoff algorithm If Source Address = address of node
No
RX
If Yes collision = 0 Route 1 Route 3
No
Yes
TX
No
If Yes collision = 0 Route 2
RX _ ok
RX _ fail
No
If Number of retry ≤ 15
Route 3 TX _fail
TX _ ok Yes Route 4 TX _Retry
Figure (5.10): The flowchart of the backoff algorithm.
Figure (5.11) shows the details of the proposed model of the intermediate node using Simevents tools. The model in this thesis represents the Data link and Network (the contention and the routing) layers. It consists of several subsystems and blocks as follows: 1. Replicate 1: It is used with set attribute block to make a copy a packet which is to be used as ACK packet (this ACK packet is not the destination ACK). The ACK packet will enter after that the path combiner. (130)
Output Switch IN # received packet In1
[ok02]
p
Out1
OUT1
Entity Sink
In1
From_ok2 -T-
Check Destination
#d
From_fail2
OUT1
en
In2
OUT IN
Conn2
A1
OUT1
IN
OUT
IN
OUT2
IN
IN OUT2
Conn1
OUT 1
Enabled Gate
Set Attribute1
IN
Replicate (send to channel)
#d
Conn3
Get Attribute1
F ch1
OUT2
Subsystem1
IN OUT Set Attribute
Replicate1
#sum
A1 4
A2 OUT
route
A1
#collision1
A2
OUT2 A3
OUT
collision
OUT
[ok02] Goto_ok2
Entity Sink2 OUT3
Backoff Controller
IN
Get Attribute2
IN
Set Attribute2
OUT
1
In1
en1 2
In2
en2
IN
OUT4
Infinite Server5
T ch1
#a
Path Combiner2 Set Attribute Collision
4
#success2
IN
IN
IN2
IN
A3
bckof f Time
OUT F ch2
2
Goto_fail2 #collision
IN
IN1
OUT1
-T-
#f ailure
3 coll22
#collision2 1
SrcAddr
A1
coll11
3
2 T ch2
Entity Sink3
Output Switch1
Out1
IN
OUT1
p
en
Check Destination2 OUT
Out1
In1
A1
IN1 IN
Check Destination1 Entity Sink1
IN
OUT2
IN
OUT
Enabled Gate1 Output Switch2
Get Attribute
OUT IN2 Path Combiner1
Figure (5.11): The proposed modeling of the intermediate node using Simevents. (131)
OUT
IN
FIFO Queue
2. Path Combiner 1: This block accepts entities from any entity input port and outputs them through a single entity output port. This block has two inputs; the first represents the received data packet successfully (the ACK packet either comes from next intermediate or from destination) while the second one represents the ACK packet from this intermediate node. 3. Check Destination 2: This block consists of several blocks as shown in Figure (5.12). The (In1) and (In2) represent the enable signals from channel 1 and channel 2 respectively.
1 In1
== ==
1 Out1
Relational Operator1
2 Constant1
Relational Operator3 ==
2
1
0
Constant2
Constant3
In2 Relational Operator2
Figure (5.12): The details of "check destination 2" block.
5.3.2 The channel: It contains several packets, which come from the different sources (previous node, the next node, .. etc). From the simulation point of view, this channel is different from the channel of single-hop.
(132)
Figure (5.13) shows the flowchart of this channel while Figure (5.14) shows the proposed channel for multi-hop ad-hoc networks.
Packet from node 2
Ack from destination
ACK Packet from node 3
Path combiner
Get attribute 1- Packet size 2- Source address No
Packet size>112 Yes
Delay
No
100*14*8/3e8+14*8/2e6
Source address ≤ Channel address
Yes
Set attribute b1 1- b1 (Random number) 2- b2 (Random number) 3-CH (Channel address)
Sink
Send to node 2
b2
Delay Send to node 3 100*1460*8/3e8+1460*8/2e6
No
b1 < b2 Yes
No b2 < b1 Yes Collision to node 2 & 3
Enable to node 2
Enable to node 3
Figure (5.13): The flowchart of a channel in multi-hop ad-hoc networks.
(133)
A1 Check source A1
In1
Out1
b1 p
OUT1
IN A2
2
Entity Sink
IN
OUT
b2
In1 OUT
IN
OUT2
IN
OUT
IN
Single Server2
Get Attribute1
Set Attribute
Output Switch
A1
1 Source en
IN
A2
2 collision
OUT
Function1
OUT
IN
OUT
1 Out1
Contention
IN1
3
IN
Get Attribute
OUT
IN
Slot time server
OUT1
p
In1
A1
Check Destination1
Server pck
OUT
Out1
Single Server
IN
Rx_ack
4 Tx_ack
IN2
Path Combiner
OUT Server ack
IN
OUT2
IN
Output Switch1
OUT
Get Attribute3
Figure (5.14): The proposed channel in multi-hop ad-hoc networks.
It is important to declare that the input port (Tx_ack) contains two types of packets. The first one is ACK packet from the next node and the second packet is ACK from destination. Figure (5.14) shows that the servers pck and ack are used for introducing delay to the ACK packet and ACK respectively. The Contention block contains a program which is used to find the successful and collided written packets using Matlab instructions for multi-hop ad-hoc networks; Appendix B shows the details of this program.
(134)
It is worth to mention that multi-hop ad-hoc networks are also simulated using OPNET software to validate this model [93].
5.4 Design of cross-topology multi-hop ad-hoc networks: The problems (TCP instability and unfairness) of the multihop ad-hoc networks become more complicated in networks with cross-topology. To study the throughput performance of crosstopology multi-hop wireless ad-hoc networks, the model given in Figure (5.15) is proposed and simulated using Simevents tools Node 2
Node 1
Destination 2
Source 1 Node 1
Source 2
Node 4
Node 5
Destination 1
TCP flow 1 TCP flow 2
Figure (5.15): Example of two TCP connections in a cross-topology Figure (5.15) shows that node 1 represents the cross point of TCP flow 1 and TCP flow 2, therefore the design will focus on this
(135)
node and the nodes around it. The five nodes will contend with each other to occupy the channel which is divided into two sub-channels for the simplicity of the proposed model. 5.4.1 Sub-channel 1 model: It represents the contention between source 1, source 2 and node 1 while the sub-channel 2 represents the contention between nodes 1, 2 and node 4. Figure (5.16) shows the details of the proposed model of sub-channel 1. This section includes the additional blocks as follow: 1. Path combiner 1 block: Input 1 (represents the TCP flow 1) and Input 2 (represents the TCP flow 2) of this block are changed with equal probability from parallel to series modes. 2. Blocks of b1, b2 and b3: These blocks generate random variables, which represent signs for source 1, source 2 and node 1 respectively. 3. Output switch 2 block: The changing from series to parallel modes is achieved in this block based on TCP flows. The outputs 1 and 2 are going to the sources 1 and 2 respectively.
(136)
A1 b1 A1
1 Source en
A2 b2 OUT
IN
A2
Check source 2
A1
IN1
In1
Out1
p
OUT1
A5
IN
Input 1 OUT
2 collision
b3
Entity Sink
IN
Function1
OUT
IN
OUT
1 Output 3
5
IN2
OUT
IN
OUT2
IN
OUT
Single Server
IN
Get Attribute
Input 2
Contention of cross-topology
Single Server2 Path Combiner1
3
OUT1
p
Output Switch
Get Attribute1
Out1
In1
A1
Set Attribute
IN1
OUT
IN
OUT1
p
Out1
In1
A1
Output 1 Check TCP flow
IN
Check Destination1
OUT
IN
Server ack
4 Input 3
6
OUT2
IN
OUT
IN2
OUT
IN
OUT2
IN
OUT
Output 2 Output Switch2
Get Attribute2
Path Combiner
Server pck
Output Switch1
Get Attribute3
Figure (5.16): The proposed Sub-channel 1 in cross-topology multi-hop ad-hoc networks. (137)
5.4.2 Sub-channel 2 model: The details of this sub-channel are shown in Figure (5.17), the main blocks are as follows:
1. Output switch 3 block: The changing from series to parallel modes is achieved in this block based on TCP flows. The outputs 1 and 2 are going to node 2 and 4 respectively. 2. Path combiner 1 block: Input 1 (represents the ACK packets of TCP flow 1) and Input 2 (represents the ACK packets of TCP flow 2) of this block are changed with equal probability from parallel to series modes.
2. Blocks of b1, b2 and b3: These blocks generate random variables, which represent signs for node 1, node 2 and node 4 respectively.
(138)
A1 b1
A1
1 Source en
A2 b2
OUT
IN
A2
Entity Sink
Check source
2 collision
A5 A1
In1
Out1
p
OUT1
A1
b3 2
Function1
OUT
IN
OUT
In1 IN OUT2
p
OUT1
IN
OUT
Single Server
IN
Check TCP
IN OUT
IN OUT2
Output Switch
IN1
Single Server2
OUT
IN
Contention of cross-topology
Set Attribute
OUT1
p
Out1
In1
Get Attribute2
A1 IN1
3
Check Destination1
OUT
IN
Server pck
acks
IN2 IN2
OUT
IN
OUT2
IN
4 ack 2
OUT
OUT
6 ack 1
Path Combiner 1 Path Combiner 2
Server ack
Output Switch1
Get Attribute3
Figure (5.17): The proposed Sub-channel 2 in cross-topology multi-hop ad-hoc networks.
(139)
5 Output 1
Get Attribute Get Attribute1
1 Output 2
IN OUT
In1 Out1
IN
Output Switch3
5.5 Design of the proposed DPSA algorithm: Distributed Packet Scheduling Algorithm (DPSA) is to be implemented using Simevents tools. The assumptions: 1. A high channel access priority can be assigned to each intermediate node when it just receives a packet. 2. The source node tries to hold the succeeding packets until the preceding packet is transmitted out of its interference range. Which are mention in Chapter (4), must be included in the proposed model of multi-hop ad-hoc networks to achieve optimum scheduling for one-way traffic in the regular chain topology. Figure (5.18) shows the modified source node. Three blocks are added to the chain-topology as follows:
1. Scheduling block: It represents a server, it provides a delay equal the time of four packets. It is used to hold the succeeding packets until the preceding packet is transmitted out of its interference range. This block is added to the source node only, as shown in Figure (5.18).
(140)
[ok]
1 [en1] en
From
In1
From_ok [fail]
#d In2
OUT
pck_send
IN
Conn2
From_fail
Initial Value
OUT1
Conn1
OUT OUT
IN
OUT
IN
OUT
1 T ch1
OUT2
Conn3
Set Attribute
Subsystem 1 Scheduling
Time-Based Entity Generator1
IN
IN
Replicate (send to channel)
Enabled Gate
Start Timer
#collision 1
#sum
A1
SrcAddr
2
A1 OUT
F ch1
A1
#collision1
A2
OUT2 A3
OUT
route
#collision
IN
IN1 2
2
Goto_fail
A2
coll1
OUT1
[fail]
#f ailure
IN
IN
Entity Sink1
A3
bckof f Time
IN2 Path Combiner1
succ throughput1
Set Attribute Collision
Set Attribute1
Get Attribute1
IN
ack2 Conn2
Output Switch OUT1
Entity Sink2 [en1]
OUT2
p
#d
Goto
en
Out1
1
In1
A1
throughput3
ack3 Conn3
OUT3
ack4 Conn4
OUT4
ack5 Conn5
OUT5
Check Destination
OUT
A2 IN
hops IN
throughput5
en IN
3 throughput4
Throughput 4
OUT4
Infinite Server (zero delay)
throughput2
Throughput 3
OUT
IN
From_ok1 Conn1
Throughput 2
IN
[ok] ack1
Throughput 1
OUT
IN
OUT Get Attribute
Enabled Gate1
Infinite Server ( zero delay)
Throughput 5 Subsystem 3
Goto_ok
OUT3
Backoff Controller
OUT
#a
[ok] OUT
collision
IN
#success
Output Switch1
Figure (5.18): The modified source in chain-topology multi-hop ad-hoc networks (Four-hops). (141)
2. Set attribute and Priority Queue blocks: These blocks are added into subsystem 1 which is shown in Figure (5.11). The modified subsystem 1 is shown in Figure (5.19).
in
len 3
IN
OUT
drop2
1
drop2
In1 2
to Workspace1
#success state
#d
IN
OUT
#f ailure
Subsystem A OUT
IN
Transmission Buffer1 Set Attribute Set (pri)
OUT
IN
OUT DIFS
Start Timer1
Transmission Control
A1
Constant (Node Address)
en
In2
IN
Conn3
2
#tx
in OUT
IN1
buffer Scope2
len
buffer2
IN OUT Set Attribute (Initialize TX info)
1
IN
to Workspace2
IN2 OUT
Conn1
IN
OUT
2 Conn2
Path Combiner1 Priority Queue
Single Server (Current TX packet)
Figure (5.19): The details of modified Subsystem 1.
It is added to all intermediate nodes. Figure (5.19) shows Set attribute block that gives an attribute (pri) to the received packets (pri represents priority in buffer) and Priority Queue block that selects the successfully received packets according to the attribute (pri). It is worth to mention that the steps of adding DPSA into cross-topology are similar to the chain-topology multi-hop ad-hoc networks.
(142)
5.6 Design of the proposed TCC algorithm: The inclusion of the TCC algorithm to the model of multihop ad-hoc networks requires mainly the building of TCP (Transport layer). This algorithm is based on three strategies as mentioned in Chapter 4: Monitoring process, Make a decision and Control transmission rate, therefore the implementation of this algorithm will change all nodes in the model.
The steps of changing will be
performed in each node as follows:
5.6.1 The source node with TCC algorithm: Figure (5.20) shows the details of the proposed source node with TCC algorithm. The main structure of this node is as follows: 1. TCP unit: It is used for transmission rate control strategy; Figure (5.21) shows the details of this unit.
(143)
[en1]
[ok]
1 en
From
OUT
Initial Value
In1
#d
From_ok [fail]
In2
pck_send
IN
Conn2
From_fail
OUT1
Conn1
[tcp]
win
IN
Conn1
OUT
Enabled Gate
1
OUT2 Set Attribute
Subsystem1
TCP
OUT
Conn1
Conn3
From2
IN
IN Start Timer
Replicate (send to channel)
#collision 1
#sum
A1
#f ailure
2
A1 A2
coll1 IN
A3 OUT
A1
#collision1
A2
bckof f Time
A3
OUT Set Attribute Collision
Backoff Controller
Conn2 IN
#a
Goto_ok1
ack1
[en1] OUT1
#a
Goto_ok2
IN
IN
#a
Goto_ok3
IN
IN #a
IN
Entity Sink5
OUT3
IN
p
OUT5
IN
en
Out1
In1
1 en
A3
Check Destination OUT
OUT
IN
Get Attribute Enabled Gate1
OUT Read Timer1
A2
Goto2
OUT4 IN
ack5
Output Switch
hops
OUT3
[tcp] ack4
OUT4 #d
A1
3 ack3
Entity Sink6
OUT2
Entity Sink4 et
pck5
ack2
Entity Sink3
pck4
Entity Sink7
Goto
Entity Sink2
pck3
IN
IN
OUT
#a
[ok] Goto_ok
Infinite Server (zero delay)
Entity Sink1 pck2
IN
IN
Set Attribute1 Get Attribute1
2
Goto_ok4
#success
OUT
collision
IN
IN2
delay of ack
2
route
#collision
IN1
in
[fail] Goto_fail
OUT2 OUT
Path Combiner1
OUT1
SrcAddr
Output Switch1
Figure (5.20): The proposed source node with TCC algorithm. (144)
OUT
IN
Infinite Server ( zero delay)
1
A1 wid
win
Goto1
In1
t
Out1
Calculation data rate
OUT
Time-Based Entity Generator
IN
OUT
#d
A2
OUT
IN
OUT
IN
Infinite Server (Zero delay) Start Timer 1
Set Attribute2
-CCPRTT Constant2
Product1
A1
-CCPRTT1 Constant4
A2
OUT
A1 IN
1 Conn1
Product3 OUT
IN
Get Attribute1
Set Attribute1
Figure (5.21): The details of TCP unit.
As shown in Figure (5.21), the input signal (win) represents the new (recommend) value of the received window (rwnd) that will be extracted from the attribute in ACK. The (win) signal is used to calculate the transmission rate (Packet/s) as shown in Figure (5.22). It is worth to mention that MSS equal to five packets is assumed in this model. Start Timer 1 block is used to calculate the delay time of the packet and other blocks in TCP unit which are used to extract necessary attributes such as CPRTT (that represents a number of packets in each RTT) and CPRTT1 (which represents a number of packets in current RTT). Finally, the signal (wid) is used in the calculation of throughput.
(145)
0.2 1/MSS
1
1 Out1
1
Constant2 1 1
Initial Value2
In1
Product
Initial Value1 Product1
Figure (5.22): The details of the "Calculation data rate" block.
2. Start Timer: It is used with Read Timer block in destination node to calculate average delay of the packet. 3. Read Timer 1: It is used with Start Timer block in destination node to calculate the ACK average delay. 5.6.2 The intermediate node with TCC algorithm: Figure (5.23) shows the details of the proposed intermediate node with TCC algorithm. The main structures of this node are as follows: 1. Subsystem 1 block: Start Timer cd2, which is used to calculate the contention delay (CD) is now introduced in the subsystem 1, see Figure (5.3). Figure (5.24) shows the location of this block within subsystem 1. 2. Read Timer cd2: It is used with Start Timer cd2 block in subsystem 1 to calculate CD of a node; the same method can be used to calculate CD of the intermediate nodes. With this method TCC can be used to monitor the delay of each node. 3. Set attribute 3: The insertion of CD to a packet is completed using this block as shown in Figure (5.23). (146)
[ok02] From_ok2 -T-
1
Subsystem A1
In1
Out1
p
OUT1 Entity Sink
Conn2
IN
en OUT OUT
OUT1
IN
OUT
IN OUT2
IN OUT2
2 Conn2
IN Set Attribute3
Read Timer cd2
Gate2
A2 OUT
From_ok3
OUT
Enabled Gate
Conn1 Subsystem1
Get Attribute1
Set Attribute1
IN
Output Switch
Replicate (send to channel)
#d OUT2
IN OUT
IN
Set Attribute
OUT
IN1
FIFO Queue
Replicate
A1 OUT
IN
#sum
A1
coll11
SrcAddr
#collision2
A2 OUT
#collision
IN
#collision1
A3
Path Combiner2
Set Attribute Collision
Backoff Controller
IN
IN
OUT2
Output Switch2
2
4
#success2
Conn4
Entity Sink4
Goto_ok2
[ok02] IN
A3 OUT3
IN
IN
1
In1
en1 Entity Sink6
Set Attribute2 Get Attribute2
IN
#a
IN
A2 OUT
bckof f Time
OUT
Conn3
A1
collision
IN
IN2
OUT1
Entity Sink1
OUT
Path Combiner Get Attribute
fail2 OUT2
IN1 OUT
route
OUT1
-T-
A1
coll22
p
Out1
1
#f ailure
3
In1
Subsystem2
IN2 4
3
A1 [ok02]
IN
IN
IN
Conn3
et OUT
Initial Value1 OUT1
Conn1
1
en
From_ok1
In2
From_fail2
[en2]
IN
In1
OUT
OUT4
2
[en2]
Out1 In2
Goto_ok1
en2 Check Destination2
Infinite Server5
Output Switch1
Figure (5.23): The proposed intermediate node with TCC algorithm. (147)
in
drop2 in
to Workspace1
drop2
buffer2
buffer Scope2
to Workspace2
len 3
IN
OUT
IN
Conn3
len OUT
IN
Transmission Buffer1 Set Attribute Set (pri)
1
#success state
IN OUT
IN
2 en
#d
OUT
Start Timer1 DIFS
Priority Queue
#tx
In1 2
OUT
A1
Constant (Node Address)
#f ailure
OUT IN
IN1
In2 Subsystem A
IN
OUT
OUT
Set Attribute (Initialize TX info) 1 Conn1
OUT
2 Conn2
IN2
Transmission Control
IN
Single Server (Current TX packet)
Path Combiner1
Figure (5.24): The subsystem 1 of intermediate node with TCC algorithm.
5.6.3 The destination node with TCC algorithm: Figure (5.25) shows the details of the proposed intermediate node with TCC algorithm. The main structures of this node are as follows: 1. Read Timer 1: It is used with Start Timer block in source node to calculate average delay of a packet. 2. Start Timer: It is used with Read Timer block in source node to calculate ACK average delay. 3. Decision unit: The essential part of TCC algorithm is the decision unit which can be used to monitor (Throughput and delay) and control transmission rate of source. Figure (5.26) shows the blocks of this unit which are as follows:
(148)
2 IN
#Recieved In1
p
Out1
OUT1 Entity Sink
check D #d en #d 1
In1
Out1
OUT
A2 IN
en
OUT
IN
OUT2
en1
IN
OUT
OUT
IN
et
A3
OUT
IN
OUT
IN
OUT1
A1
3
Sink
Set Attribute1 Output Switch
IN
Conn1 FIFO Queue1
OUT2
Enabled Gate1 Read Timer
Set Attribute2
OUT
in
to ack
A4
#d
IN
OUT
IN Decision OUT3
IN
OUT
IN
OUT
Get Attribute1
Out1
FIFO Queue
Set Attribute for ack
Throughput 2
Start Timer
OUT4 Out2
2 Replicate
Throughput 3
In1 Out1
tr
coll56
A1 OUT
sum coll IN
Out3
1 #collisions
IN OUT
IN
Throughput 4
IN
OUT1
p Out1
Out4
Throughput 5
#a
to node6
Enabled Gate Check D
1
IN
IN
Entity Sink3
Subsystem to calculate Throughput
2
OUT2
In1
Subsystem1
IN
Entity Departure Counter
A1 IN OUT
Conn4 Output Switch2
Get Attribute
Figure (5.25): The proposed destination node with TCC algorithm. (149)
Get Attribute2 Entity Sink2
RTT
A1 A1 pck5
A2
From_ok3 A1
A2 A3
ACDH A2
cd2
OUT
IN
In1
A4 A3 1
IN
A3
cd3
In2
Out1
A1
A5
in
A1 cd4 A4
OUT
In3
OUT
IN
OUT Set Attribute OUT Get Attribute1
IN
OUT
Attribute Function1
1 to ack
IN IN
Get Attribute
IN
Get Attribute2
Entity Sink
Single Server zero time Set Attribute2
Figure (5.26): The details of the Decision unit.
1. ACDH subsystem: It is used to find the average contention delay per hop (ACDH) as shown in Figure (5.27). 1 In1 2
1
In2 3
Out1
3
In3
Constant1 Product
Figure (5.27): The structure of ACDH subsystem.
2. Attribute Function 1: It is used to write a program that represents the process of TCC algorithm. This program is detailed in Appendix B.
(150)
5.7 Design of the proposed RRSA algorithm: It is simple to be implemented using Simevents tools; Figure (5.28) shows the position of the Round Robin control block within the DPSA structure, while Figure (5.29) shows the details of the Round Robin control subsystem which consists of the following blocks: 1. Round Robin switch: It is used to apply Round Robin Fashion (RRF) as shown in Figure (5.29). 2. Blocks of Goto: These blocks are used to send the enable signals (according to the sequence of RRF) to the cross node and its neighboring nodes. It is worth mentioning that cross node (n1) takes two chances instead of one, so that the two flows will pass through it.
(151)
[ok]
1
In1
[en1]
From_ok [fail]
OUT1 OUT
IN
OUT
OUT
A1
OUT
IN
OUT
IN
OUT
1 Conn1
IN OUT2
Set Attribute
FIFO Queue Replicate (send to channel)
Enabled Gate OUT
Conn3
Transmission Control
Set Attribute2
Start Timer
IN
IN
Conn2 Conn1
#d IN
IN
OUT1
Initial Value
In2
From_fail pck_gen
en
From
OUT2 Time-Based Entity Generator1
scheduling #collision
Conn2
Replicate
#sum
A1
#f ailure
Round Robin control throughput1
2
[ok]
succ
A1 A2
coll1 OUT
Conn1
OUT
OUT1 2
throughput2
Throughput 2
ack2 Conn2
p
Conn2
IN
Conn3
A3
IN
Set Attribute Collision
Path Combiner1
ack4 Conn4
Throughput 4
3 OUT4
Conn5
Output Switch Out1
In1
A2
1 en
OUT
Check Destination
OUT OUT
IN
Get Attribute Enabled Gate1
Output Switch1
Figure (5.28): The proposed source node with RRSA algorithm. (152)
IN Entity Sink6
OUT OUT4
Throughput 5 Calculation throughput
OUT3 IN
Infinite Server (zero delay)
hops
OUT5
Entity Sink8
IN
Set Attribute1
en
#a
A3
Backoff Controller IN
IN
#success [ok]
OUT
collision
IN throughput5
A2
A1
IN ack5
#collision1
#d
IN throughput4
OUT
Goto
OUT3
A1
bckof f Time
Get Attribute1 [en1]
ack3
Throughput 3
2
fail
IN2
OUT2
throughput3
[fail]
route
#collision
IN1 ack1
OUT1
OUT2
From_ok1 Throughput 1
1
SrcAddr
Infinite Server ( zero delay)
Goto_ok
OUT1
IN
#a
S1 Goto_ok4
Entity Sink4
OUT2
IN
#a
n1 Goto_ok1
Entity Sink1
OUT3
IN
#a
n4 Goto_ok2
1
IN
Entity Sink2
Conn2 OUT4
IN
#a
S2 Goto_ok3
Entity Sink3
OUT5
IN
#a
n1 Goto_ok5
Entity Sink5
OUT6
IN
#a
n2 Goto_ok6
Round Robin Switch
Entity Sink6
Figure (5.29): The details of Round Robin control subsystem.
(153)
Chapter Six Simulation and Results
6.1 Introduction: This Chapter presents the simulation results of the different proposed single and multi-hops ad-hoc wireless networks models using Simevent programming and Optimum Network Simulator (OPNET Modeler) which is one of the most famous simulators. The first model presented in this study is a single-hop ad-hoc wireless network; its performance is validated using analytical model in addition to other simulation models; the other model under consideration deals with multi-hop ad-hoc wireless networks with different topology. The results also include the multi-hop ad-hoc wireless networks with several algorithms of the proposed models. It is known that the performance of networks can be evaluated using throughput, delay, stability, etc.
6.2 Simulation of a single-hop ad-hoc network: As mentioned before, the analytical model of a single-hop ad-hoc network is based on basic access method. The parameters of this model are summarized in Table (6-1).
(154)
Table (6-1): The parameters used in the analytical model. The parameters
The values
Transmission rate (R)
2 Mbps
Packet length (P)
1460 B
MAC header (H)
224 bit
ACK length
112 bit
DIFS
50 μs
SIFS
10 μs
Slot time (σ)
20 μs
Propagation delay (α)
0.33μs
Minimum contention window (Wmin) 32
The mathematical equation (2.26) of this model depends on the relationship between the number of contending nodes, the conditional collision probability (p) and the probability (τ) (that a packet is transmitted in a randomly selected slot).
Table (6-2) shows that the throughput of the basic access scheme is strongly dependent on the number of nodes in the network.
(155)
Table (6-2): The parameters used in the analytical model. Number of
Conditional collision
The
Throughput
nodes
probability
probability
(kbps)
(N)
(p)
(τ)
(S)
2
0.00641
0.0064
1395.8
3
0.01484
0.0074
697.68
4
0.0233
0.0078
451.5
5
0.0318
0.0080
325.66
6
0.0553
0.0113
246.75
7
0.0605
0.0103
200.5
8
0.0693
0.0102
154.79
9
0.0728
0.0094
134.18
The results of the analytical model are compared with the results of the same model (a single-hop ad-hoc network) using OPNET modeler simulator. The model deals with eight scenarios, the first scenario consists of two nodes only; the first node is considered as a source while the second one represents the destination. The second scenario consists of three nodes, which have been located in the same range. Other scenarios follow the following equation: Si = (i + 1) n ….. (6.1) Where: Si=Scenario number. (i+1) n = number of nodes in the scenario. i=1→ 8
(156)
In each scenario, the throughput and delay are measured. The last scenario is shown in Figure (6.1). The parameters of this model using OPNET modeler are shown in Appendix C.
Figure (6.1): The last scenario for the modeling of the single-hop adhoc network.
Figure (6.2) shows the total achievable network throughput as a function of the number of competing nodes in the single-hop wireless ad-hoc network using analytical model and OPNET. All
(157)
nodes are within the range of each other, and send packets as fast as 802.11 allows. Throughput vs. Number of nodes (single-hop ad-hoc netwok) 1400
Throughput (kbps)
1200
Theoretical Simultion (OPNET)
1000
800
600
400
200
1
2
3
4
5 6 number of nodes
7
8
9
10
Figure (6.2): The relationship of the throughput with the number of nodes in the case of a single-hop ad-hoc network.
The Figure declares that the throughput decreases as the number of nodes increases. This is related to the fact that the number of nodes increases inside the same network and the contention between them will rapidly increase too. On the other hand, only one node can transmit a packet successfully in a given time. In both cases (analytical and simulation) the results are in a satisfactory agreement between them.
(158)
The waiting function W(N), head-of-line D(N) and the total delays which are mentioned in Chapter 2 are now calculated as shown in Figure (6.3). The Delay versus Number of nodes (single-hop ad-hoc network) 80 Theoretical W(N) Theoretical D(N) Theoretical Dt Simultion (OPNET) Dt
70
The Delay (mSec.)
60 50 40 30 20 10 0
1
2
3
4 5 6 7 number of contending nodes
8
9
10
Figure (6.3): The types of delays versus the number of nodes in the single-hop ad-hoc network. For a small number of contended nodes, D(N) is very small and will start to increase gradually as the number of nodes increases. The total delay (Dt) increases in almost a linear relationship as the number of the contending stations increases. This result can be related to the fact that in large networks, packets experience greater number of collisions; and consequently the stations will choose higher backoff stages yielding longer delays.
(159)
It is observed that the simulation results of Dt agree to a large extent with the theoretical values. Figure (6.4) shows the number of hops versus the simulation time.
Figure (6.4): The number of hops versus simulation time.
Figure (6.4) illustrates also that the number of hops is one for all nodes, which means the network works as a single-hop wireless ad-hoc network.
6.3 A practical single-hop wireless ad-hoc network: A single-hop wireless ad-hoc network is implemented practically in computer and a communication networks laboratory with five scenarios. In this section, the details of the first and fifth scenarios are as follows:
(160)
6.3.1 The first scenario: Two laptops are connected practically in this scenario. The following setting is made for the WLAN card of each laptop: 1- Wireless connection status is on as shown in Figure (6.5). This means that the wireless properties are selected to be open.
Figure (6.5): Wireless network connection status and wireless properties.
(161)
2- From the properties page shown in Figure (6.6), the IP is fixed and the Configure icon is selected to open the connection configuration of the WLAN card.
Figure (6.6): The window of Wireless network connection properties.
3- From advanced menu, the mode and speed are selected and from the value list, the IBSS mode is chosen as shown in Figure (6.7). At this point, the WLAN card of the laptop will work at (IBSS mode, 2 Mbps).
(162)
Figure (6.7): IBSS mode is 802.11b and data rate is equal to 2 Mbps. (163)
The sharing folders are selected arbitrarily in the two laptops as shown in Figure (6.8).
Figure (6.8): The sharing folder steps. (164)
It is worth to mention that the setting of the (HomeGroup) function through the path: Control Panel → Network and Internet → HomeGroup will complete the setting process. From the change HomeGroup settings, the network discovery, file and printer sharing, public folder sharing, and file sharing connections are turn on while password protected sharing is turn off. Figure (6.9) shows the two laptops as they appear in the wireless network after the setting process is completed.
Network name
Two laptops are shown in the network
Figure (6.9): Two laptops are connected practically as a single-hop wireless ad-hoc network. From the software point of view, CommView 6.1 is used to generate the packets as shown in Figure (6.10) [94]:
(165)
Figure (6.10): Packet generating tool by CommView.
After completing the different setting, this scenario is implemented according to the following assumptions: 1. Packet size is selected to be (1460 B) (as in mathematical and simulation models). 2. The transmission data rate range of each user is (10-130) packet/sec. 3. Users transmit packets according to the following scenario: user 1 (Dell-1, which has IP= 1.1.1.3) send to user 2 (Dell-2, which has IP= 1.1.1.4) (half-duplex). 4. Figure (6.11) shows the connections of the users.
(166)
Figure (6.11): Network matrix by IP in CommView. Figure (6.12) shows the details of some of the packets being received by user 2 while Figure (6.13) shows the packets received by user 2 with variable rates.
Figure (6.12): The packets received by user2.
(167)
10
30
70
100
120
130 packet/sec
Figure (6.13): The packets received by user 2 with variable data rates.
The average throughput and channel utilization as a function of the transmission data rate are shown in Figure (6.14) and (6.15) respectively. Figure (6.14) declares that the average throughput increases as the data rate increases up to the data rate which is equal to (125 packet/sec). After that, the throughput remains at this value, the reason of that is related to the contention and overhead packets which prevent the throughput to increase.
(168)
Throughput vsersus data rate (single-hop ad-hoc netwok) 2000 Simevents OPNET Practical
1800 1600
Throughput (kbps)
1400 1200 1000 800 600 400 200
20
40
60 80 100 Data rate (packet/sec)
120
Figure (6.14): Average throughput of user 2 versus data rate. (169)
140
Figure (6.15) shows the channel utilization of a single-hop ad-hoc network at data rate=100 packet/sec using Simevents tools.
Figure (6.15): The relationship between the instantaneous channel utilization with simulation time using Simevents.
The maximum channel utilization is achieved when the same data rate of the maximum throughput (125 packet/sec) is used. Channel utilization vsersus data rate (single-hop ad-hoc netwok) 100 90
Channel utilization ( % )
80 70 60 50 40 30
Simultion (Simevents) Practical (CommView)
20 10 0
20
40
60 80 100 Data rate (packet/sec)
120
140
Figure (6.16): Channel utilization of user 2 versus data rate. (170)
In this case study, Wireshark program is used which is a network packet analyzer. A network packet analyzer will capture network packets and tries to display the details of the packet data. Wireshark provides a wide range of network statistics which can be accessed via the statistics menu. Statistics of the captured WLAN traffic are used [95]. Figure (6.17) shows the instantaneously throughput using Wireshark input/output (IO) graphs for the two laptops experiment.
Figure (6.17): The instantaneously throughput of the first scenario using Wireshark.
It is easy to find that the average value of the instantaneous throughput of the first scenario is equal to 1415 kbps.
(171)
6.3.2 The fifth scenario: According to this scenario, three laptops (Dell-1, Dell-2 and Dell-3) and three desktops (A, B and Pc99) computers are connected with each other practically to form a wireless LAN as shown in Figure (6.18). The laptops use windows seven while the desktops use window XP with D-Link AirPuls G520 (as adapter WLAN card). The six computers of the wireless network after the setting process is shown in Figure (6.19).
Figure (6.18): The practical WLAN of the single-hop ad-hoc network.
(172)
Figure (6.19): The six computers appeared in the network.
Figure (6.20) shows the IP addresses, the MAC addresses and the connections of the six users.
Figure (6.20): The IP and MAC addresses of six computers in the network. (173)
The Figure declares that three computers which use D-Link adapter representing the desktop computers while the rest computers (without D-Link adapter) are laptops. The
instantaneously
throughput
performance
using
Wireshark (IO) graphs for six computers is shown in Figure (6.21). It is clear that the average value of the instantaneous throughput of this scenario is equal to 180 kbps. On the other hand, the average throughput of the first scenario (1415 kbps) is around eigpht times greater than the throughput of the fifth scenario (180 kbps); the reasons behind that are related to the increment of the overhead and the contentions between the six computers of scenario 5 as compared with the two computers of scenario 1.
Figure (6.21): The instantaneously throughput using Wireshark (IO) graphs for the fifth scenario (six computers). Finally, Figure (6.22) shows a comparison between the throughput performance of mathematical, OPNET and the practical results. (174)
It is obvious from the Figure that there is an excellent agreement between the throughput performance of the three types of results. Throughput vs. Number of nodes (single-hop ad-hoc netwok) 1400
Throughput (kbps)
1200 Theoretical Simultion (OPNET) Practical (wireshark)
1000
800
600
400
200
1
2
3
4
5 6 number of nodes
7
8
9
10
Figure (6.22): The throughput performance as a function of the number of nodes.
6.4 Simulation of multi-hop ad-hoc networks: The simulation results of multi-hop ad-hoc networks are divided into two sub-sections; the first one deals with the analytical model which is described in Chapter 3. The second one consists of two parts; the proposed model, which is described in details in Chapter 5, and the proposed model which is based on the OPNET modeler. Finally, a comparison between the results of these models is considered. 6.4.1 The analytical model results: According to this model, the relationship between the throughput (S) and the probability P' (that a waiting node transmits a packet with this probability) are shown in Figures (6.23) and (6.24). (175)
Throughput versus attempt probability (P‘)
Throughput versus The probability (P‘) 1800 Throughput versus The probability (P‘) 1600 Throughput versus The probability (P‘) 1400 Throughput versus The probability (P‘)
5
3
5
N=2 N=3 N=5 N=10
1200 1000 800 600 400 200 0
0
0.1
0.2
0.3
0.4 0.5 0.6 The probability (P‘)
0.7
0.8
0.9
1
Figure (6.23): The throughput versus the probability P' when packet size is equal to 1460B. Figure (6.23) shows the throughput results of relatively large data packets (1460B) as a function of P' and for different number of nodes. For relatively small data packets (500B), the relationship between 0.2
0.3
0.4
0.5
0.6
0.7
0.8
0.9
1
0.2 0.2 0.2
0.3 0.4 0.5 0.6 0.7 0.8 0.9 1 The (P‘) 0.3 0.4 probability 0.5 The0.6 0.7 attempt 0.8probability0.9 1 Throughput versus probability Throughput versus(P‘) (P‘) 800 0.5 0.3 The 0.4probability 0.6 0.7 (P‘)0.8 0.9 1 (P‘) Throughput versus The probability The versus probability 700 Throughput The (P‘) probability (P‘) N=2 N=3 Throughput versus The probability (P‘) 600 N=5 500 N=10
the throughput and the probability P' is shown in Figure (6.24). The probability (P‘)
The throughput (kbps)
0.1
0.1 5 0.1 x 10 5 0.1 x 10 5 x 10 5 x 10 4
5
The throughput (kbps)
0 5 0 5 0 5 10
400 300 200 100 0
0
0.1
0.2
0.3
0.4 0.5 0.6 The probability (P‘)
0.7
0.8
0.9
1
2
Figure (6.24): The throughput versus the probability P' when packet size is equal to 500 B.
5
(176)
1
Table (6.3) displays the maximum throughput which can be obtained in different cases.
Table (6.3): The relationship between packet length, the probability P', the number of nodes and the maximum throughput. Packet length
Probability
Number of
Maximum
(Byte)
(P')
nodes (N)
throughput (kbps)
1460
0.201
2
1613
1460
0.141
3
1217
1460
0.101
4
951
1460
0.081
5
726
1460
0.061
6
575
1460
0.061
7
485
1460
0.061
8
412
1460
0.041
9
353
1460
0.061
10
300
500
0.161
2
697
500
0.121
3
479
500
0.081
4
350
500
0.061
5
267
500
0.061
6
212
500
0.061
7
178
500
0.041
8
151
500
0.041
9
131
500
0.041
10
111
(177)
Figure (6.25) shows the relationship between the maximum throughput and the number of nodes for the cases (packet length=500B and packet length=1460B).
Theoretically the maximum throughput value at (N=2) should be (2 Mbps) but due to the overheads and the contention problem this value reduces to (1.6 Mbps).
On the other hand, smaller value of throughput is expected in the case of packet length=500B; this can be related to the fact that the time of contention to occupy the channel is independent of the packet length and consequently the throughput will be in direct relationship with the packet length before reaching the saturation of the channel.
Throughput versus the number of nodes (N) Packet size = 1460 B Packet size = 500 B
1600 1400
The throughput (kbps)
1200 1000 800 600 400 200 0
1
2
3
4
5 6 7 8 The number of nodes (N)
9
10
11
Figure (6.25): The maximum throughput versus the number of nodes.
(178)
6.4.2 Multi-hop ad-hoc model results using Simevents and OPNET: Based on the proposed models given in section (5.3), complete models of multi-hop ad-hoc networks can be obtained as follows:
6.4.2.1 Two-hop model results: The model consists of three nodes, the first one represents the source; the second one is intermediate (like a router) and the third node is destination. This model is implemented using Simevents and OPNET as shown in Figure (6.26) and (6.27) respectively. node2
Source
[ok1] #collision
en1 #collision2
From_a1 #Collisions 1
[ok1]
Destination
[ok45] From_d1
#Collisions 2
[ok23]
en
From_a
#Collisions 3
en1 #collisions
en2
From_b2 #success
Packets Send2
-T-
#success2
-T-
coll22
coll56
From_coll7
Packets Send3
From_coll2 hops
#Reciev ed
in
Packets Received1 hops
-T-
coll11
From_ch11 Source en
Conn1
T ch2
[ok1]
Source en
Goto_a T ch1
-T-
coll1
In1
Goto_b2
In1 collision
From_ch1
-T-
F ch1
[ok23]
collision
Goto_N
-TGoto_coll2 to node6
Out1
Out1 F ch2 F ch1
Rx_ack
Rx_ack
T ch1
Conn4
Packets send to node 3
Tx_ack Tx_ack
Channel2 Channel1
Figure (6.26): The completed model of multi-hop wireless ad-hoc networks (chain-topology with two-hop) using Simevents.
(179)
In both models (Simevents or OPNET), it is assumed that the range of each node equals to (100 m) and the destination node is out of range of the transmission source node.
Figure (6.27): The completed model of multi-hop wireless ad-hoc networks (chain-topology with two-hop) using OPNET.
Figure (6.28) shows the relationship between the average throughput and the variable data rate of two-hop ad-hoc networks. The overall throughput increases when the data rate increases until (50 packet/sec), after that the throughput remains almost constant. This is related to node 2 which reaches the stable condition of performance (i.e., it has not the capability of delivering more than 187 kbps).
(180)
Throughput versus data rate of Two-hop ad-hoc networks 1400
1200
Throughput (Kbps)
1000
800 OPNET (Between the source and node 2) Simevents (Between the source and node 2) OPNET (Between node 2 and the Destination) Simevents (Between node 2 and the Destination)
600
400
200
0
0
20
40
60 80 Date rate (packet/sec)
100
120
140
Figure (6.28): The throughput with variable data rates for two-hop model.
For the two-hop model, the number of iterations for the first hop is greater than that of the second hop; for example, the number of iterations of the first hop is equal to (44) while it is equal to (12) for the second hop for the same duration time (250 sec. to 250.5 sec.) as shown in Figure (6.29). The greater number of iterations of the first hop is related to the fact that the source node sends more packets than the intermediate node; consequently, the buffer in this node will be subjected to more load than the buffers of the other nodes. Figure (6.30) shows the buffer capacity of the intermediate node (node 2) with variable data rates.
(181)
Figure (6.29): shows an example of the iterations of the first and second hops for two-hop model.
(182)
The capacity buffer of node 2 versus data rate of Two-hop ad-hoc networks OPNET (Two-hop model) Simevents (Two-hop model)
1.6
The capacity buffer (packet)
1.4 1.2 1 0.8 0.6 0.4 0.2 0
0
20
40
60 80 Date rate (packet/sec)
100
120
Figure (6.30): The buffer capacity of node 2 with variable data rates for two-hop modes using OPNET and Simevents.
It is clear from Figure (6.30) that the maximum value of the buffer which can be reached is (1.5 packets), while the buffer capacity in each node as mentioned before is 20 packets; therefore, this value is much smaller than the buffer capacity and cannot be considered as a problem (intra-flow problem); consequently, the two-hop model will not suffer from instability. Figure (6.31) shows the instantaneous end-to-end delay of two-hop model at a data rate that equal to 125 packet/sec using Simevents while Figure (6.32) illustrates the instantaneous end-to-end delay at the same data rate using OPNET.
(183)
Figure (6.31): The instantaneous end-to-end delay at data rate =125 packet/sec for two-hop modes using Simevents.
Figure (6.32): The instantaneous end-to-end delay at data rate =125 packet/sec for two-hop modes using OPNET.
Although the instantaneous end-to-end delays as a function of simulation time shown in Figures (6.31& 6.32) are different, but the average end-to-end delays are approximately equal to (0.081sec.). Figure (6.33) shows the relationship between the average end-to-end delay and variable data rates of the two-hop models.
(184)
The aeverag delay versus data rate of Two-hop ad-hoc networks 90 OPNET Simevents
The average end-end delay (msec)
80 70 60 50 40 30 20 10 0
0
20
40
60 80 Date rate (packet/sec)
100
120
Figure (6.33): The relationship between the average end-to-end delay and data rates for two-hop models.
(185)
As expected when the average delay increases the data rate will increase too; the reason of that is related to the additional packets which will cause more collisions and long backoff process time.
6.4.2.2 Three-hop model results: This model includes two intermediate nodes instead of one node. This model is also implemented using OPNET and Simevents as shown in Figure (6.34) and (6.35) respectively.
The model which uses OPNET has a network scale equal to (400*300 m) and (wireless_lan_adv) is used as the implementation technology. It is obvious that the transmitted packets from the source will require three-hops to reach the destination.
Figure (6.34): The completed model of multi-hop wireless ad-hoc networks (chain-topology with three-hop) using OPNET.
(186)
Source
node3
node2
Destination [ok1]
#collision
[ok23]
en1
en1
From_c
From_a1
#collision3
#collision2
#Collisions 1
#Collisions 3
#Collisions 2 [ok1]
en
From_a
[ok23] #success
[ok34]
en2
Packets Send2 coll22
[ok1] Goto_a
In1
-T-
coll33
Packets Send4
From_coll3
collision
coll1
-T-
Source en coll11 T ch2
From_ch11
collision
-T-
[ok23]
en coll22
coll56
collision
-T-
Conn1
Goto4 Out1
Out1 Rx_ack F ch2 T ch1
Packets Received D
Conn1
Out1
Tx_ack
#Reciev ed
In1
Goto_coll2
Rx_ack
[ok34] Goto5
Conn2
-T-
F ch1
From_ch1
-T-
Goto_b2 From_coll1
In1
Goto_N
F ch1
-TFrom_coll7
hops Source en
T ch1
-TPackets Send3
From_coll2 hops
#collisions
en2
#success3
#success2
-T-
From_d1
#Collisions 5
en1
From_c1
From_b2
in
[ok34]
Conn3
Rx_ack Tx_ack
Conn4
Tx_ack
to node5 Conn4
Packets send to node 5
Channel3 Channel1
Channel2
Figure (6.35): The completed model of multi-hop wireless ad-hoc networks (chain-topology with three-hop) using Simevents.
(187)
Figure (6.36) shows the relationship between the average throughput of the first, second and third hops (which represent the average throughput of nodes 2, 3 and destination respectively) and the variable data rates. It is clear that in this model, the hidden node problem becomes more effective; for example, the channel capacity is equal (2 Mbps) while the maximum throughput value of the first hop is no more than (1045 kbps) at a data rate equal to (125 packet/sec.).
Throughput versus data rates 2000 OPNET (First hop) Simevents(First hop) OPNET (Second hop) Simevents(Second hop) OPNET (Third hop) Simevents(Third hop)
1800 1600
Throughput (Kbps)
1400 1200 1000 800 600 400 200 0
0
20
40
60 80 Date rate (packet/sec)
100
120
140
Figure (6.36): The average throughput as a function of data rate of the three-hops model.
The range of the throughput of the destination is between 101 and 80 kbps, from the control point of view. These values are
(188)
acceptable and will cause a semi-stable performance (the change percentage is approximately equal to 20%). Figure (6.37) shows the relationship between the buffer capacity of nodes (2 and 3) and the variable data rates. The maximum number of packets in the buffers of intermediate nodes are 2.8 (for node 2) and 0.15 packet (for node 3) at a data rate equal to 125 packet/sec.
The buffer capacity of nodes 2 and 3 versus data rate of Three-hop ad-hoc networks 3.5 OPNET (buffer capacity of node 2) Simevents (buffer capacity of node 2) OPNET (buffer capacity of node 3) Simevents (buffer capacity of node 3)
The buffer capacity (packet)
3
2.5
2
1.5
1
0.5
0 0
20
40
60 80 Date rate (packet/sec)
100
120
Figure (6.37): The buffer queue of nodes 2 and 3 with variable data rates of the three-hop modes using OPNET and Simevents.
The relationship between the average end-to-end delay and the variable data rates is shown in Figure (6.38). The bottleneck in this Figure is the average delay of node 2 which will suffer more than
(189)
other nodes from TCP intra-flow instability problem as mentioned in Chapter 3. It is worth mentioning that the queue of node 2 will increase slowly between the data rate range (10-75) packet/sec., after that the queue will increase rapidly. As a consequence, the delay in this node will increase rapidly as shown in Figure (6.38). The aeverag delay versus data rate of Three-hop ad-hoc networks 350
The average delay (msec)
300
250
OPNET (total delay) Simevents (total delay) OPNET (delay of node 2) Simevents (delay of node 2)
200
150
100
50
0
0
20
40
60 80 Date rate (packet/sec)
100
120
Figure (6.38): The average delay with variable data rates for three-hop models using OPNET and Simevents.
6.4.2.3 Four-hop model results: This model contains three intermediate nodes, in addition to the source and destination nodes. This model is also implemented using OPNET and Simevents as shown in Figure (6.39) and (6.40) respectively.
(190)
The model which uses OPNET has a network scale equal to (500*300 m) and (wireless_lan_adv) is used as the implementation technology. It is clear that the transmitted packets from the source will require four-hops to reach the destination.
Figure (6.39): The completed model of the multi-hop wireless ad-hoc networks (chain-topology with four-hop) using OPNET.
As mentioned in Chapter 3, the TCP intra-flow instability problem will appear clearly when the five nodes are connected to form a chain topology; therefore, the expected average throughput will be small and unstable while the queue of the buffer will be large. Figure (6.41) shows the relationship between the average throughput and the variable data rate of the four-hop model using Simevents and OPNET.
(191)
node2
Source
node3 [ok1] #collision
Destination
node4
en1 #collision2
From_a1 #Collisions 1
[ok23]
en1
[ok34]
#collision3
From_c
#Collisions 2
From_c2
en1
[ok45]
#collision4
#Collisions 3 [ok1]
[ok23]
en
From_a
#Collisions 4
en2
[ok34]
From_b2
#success
en2
[ok45]
From_c1 Packets Send2
en2
Packets Send3
-T-
Packets Send4
-T-
From_coll3
in
-T-
#success4 coll33
coll44
Packets Send5
From6
#Reciev ed
-T-
-T-
coll1
coll11
-TT ch2
[ok1] From_ch11
collision
From_ch1
F ch1
-TConn2
en
-TGoto_coll2
F ch2
collision Conn1
T ch1
From5
coll33
en Conn2
-TGoto4
Packets Received1
[ok45] Goto7
In1 collision
Conn1
-TGoto6
Conn1 Out1
Out1
Rx_ack
Conn3 Tx_ack
[ok34] Goto5
Out1
Rx_ack Tx_ack
coll22
From_coll1
In1
Out1 F ch1
[ok23] Goto_b2
collision
-TGoto_N
Source en In1
Goto_a
In1
coll56
From_coll7
hops
T ch1
#collisions
From_c3 #success3
coll22
From_coll2
Source en
#Collisions 5
en1
#success2
-Thops
From_d1
Conn4
Rx_ack to node6
Rx_ack Tx_ack
Conn3 Conn4
Tx_ack
Conn4
Channel4 Channel1
Channel2
Channel3
Figure (6.40): The completed model of multi-hop wireless ad-hoc networks (chain-topology with four-hops).
(192)
Packets send to node 6
The average throughput of Four-hop model using OPNET and Simevents 700
600
Average throughput (Kbps)
500
400 OPNET (First-hop) Simevents (First-hop) OPNET (Fouth-hop) Simevents (Fouth-hop)
300
200
100
0
0
20
40
60 80 100 Date rate (packet/sec)
120
140
Figure (6.41): The relationship between the average throughput and the variable data rates of the four-hop model.
As expected, the overall throughput of the destination is small ( between 70 and 36 kbps) with a change percentage equal to 48.5% using Simevents; on the other hand, the throughput is between 62 and 32 kbps with a change percentage equal to 48.4% using OPNET. These values are unacceptable and will cause instability problem. Figure (6.42) shows the relationship between the queue size of nodes (2, 3 and 4) and the variable data rates. The maximum queue
(193)
of intermediate nodes 2, 3 and 4 are 8.3, 0.4 and 4.5 packets respectively. The value of the queue for node 2 is high when it is compared with the buffer capacity of this node; therefore, this value will seriously limit the performance of multi-hop ad-hoc networks especially in terms of end-to-end throughput as shown before.
The average queue size of Four-hop model using OPNET and Simevents 9 OPNET (node 2) Simevents (node 2) OPNET (node 4) Simevents (node 4) OPNET (node 3) Simevents (node 3)
The average queue size (packet)
8 7 6 5 4 3 2 1 0
0
20
40
60 80 Date rate (packet/sec)
100
120
140
Figure (6.42): The queue size of nodes 2 and 3 as a function of the data rate of the four-hop model using OPNET and Simevents.
The instantaneous queue length of intermediate nodes are shown in Figure (6.43) at data rate equal (100 packet/sec). The instantaneous number of dropped packets at node 2 (which suffers from congestion more than other nodes) is shown in Figure (6.43-b).
(194)
a)
b)
c) d) Figure (6.43): The instantaneous results of chain-topology: a) The instantaneous queue length of nodes 2. b) The instantaneous dropped packets of node 2. c) The instantaneous queue length of node 3. d) The instantaneous queue length of node 4.
Figure (6.44) shows the relationship between the average delay of node 2 and the variable data rates. After a data rate equal to (25 packet/sec.), the average delay in this node will increase rapidly. This is related to the fact that the received packets will be stored into large queue and waits until node 2 can retransmit the first received
(195)
packet successfully. On the other hand, the congestion in this node certainly degrades the performance of multi-hop ad-hoc networks especially under heavy load using chain topology.
The average delay of node 2 (msec.)
The average delay of node 2 in Four-hop model using OPNET and Simevents 300
250
200
150
100 OPNET (node 2) Simevents (node 2) 50
0
0
20
40
60 80 100 Date rate (packet/sec)
120
140
Figure (6.44): The relationship between the average delay of node 2 and variable data rates for four-hop model.
For the four-hop model, the number of iterations for the first hop is greater than that of the second hop, the latter is greater than that of the third hop and so on. For example, the number of iterations of the first, second, third and four hops are equal to 27, 7, 3 and 1 respectively during the same duration range (288 sec. to 288.5 sec.) as shown in Figure (6.45). As mentioned before, the larger number of iterations of the first hop is proportional to the number of packets send by the source node, consequently, the congestion becomes effective in this model and the intra-flow problem can be completely addressed.
(196)
Figure (6.45): An example of four-hop model showing the iterations of first, second, third and four hops as a function of time.
6.5 Simulation of multi-hop ad-hoc networks (cross-topology): The cross topology of multi-hop ad-hoc networks is an essential task in this study. Figures (6.46 & 6.47) show the complete proposed models of the four-hop for each TCP flow in cross-topology using OPNET and Simevents.
Figure (6.46): Proposed model of four-hop ad-hoc networks using OPNET (cross-topology). (197)
D2
source1
node3
node2
#Collisions 10
#collision
[ok23] #Collisions 1
[ok1]
#collision3
From_c4
#Collisions 8
[ok45]
en1 #collision4
From_c6
node1
#success
From_a
[ok34]
[ok1] in
hops
[ok45]
en2
From_c5
Packets Send2 en1 #collision2
From_a1
Goto2
From_coll6 -T-
[ok23]
Conn1
en2
[ok34]
en
-T-
en
From2
-TGoto1
Conn2
From_coll4
#Reciev ed
-T-
In1
Packets Received2
coll33 Conn2
From1
Conn1
-T-
collision
Goto3
From_b2 Out1
Conn1
Packets Send3
From_ch1 Input 1Source en
[ok1]
-T-
Conn1 Out1
Rx_ack
#success2 Conn2
Conn3
coll11
Source en
Goto_a From_coll2
[ok23]
Conn4
Conn3
Tx_ack
Output 1collision
Packets Send1
-T-
-T-
coll22
Goto_N From_ch11
Tx_ack
Goto9
D1
Conn2
Conn1 ack 2
#Collisions 5
Conn3 Output 2 Input 3
acks
Output 1
ack 1
#success3 coll33
hops
in hops 1
en
From_d1
-T-
-T-
#success4 coll44
Packets Send5
From6 -T-
coll22 Conn2
From_coll1
collision
-T-
en
Conn2
collision
Goto4
-T-
-T-
Conn3
Conn3 Conn4
Rx_ack Tx_ack
Tx_ack
Channel3
Channel4
Figure (6.47): The proposed model of four-hop ad-hoc networks using Simevents (Cross-topology).
(198)
#Reciev ed
Packets Received1 Conn1
Goto6
Out1
Conn2
coll56
Out1
Rx_ack Conn4
-TFrom_coll7
Conn1
Conn1
From_ch2
#collisions
Goto7
In1
coll33
From5
en1
#Collisions 4
en2
Goto5 In1
Conn1 coll1
-T-
From_coll3
#collision4
From_c3
Packets Send4
Channel1 Channel2
#Collisions 3
-T-
en1
From_c2 -T-
From_c1 -T-
#success
#collision3
en2
Conn4
en
-T-
en1
From_c -T-
#collision
node5
node4 [ok23]
Input 2 Output 3
Channel6
-T-
Output 2
#Collisions 6 source2
Packets send to node 1
Conn4
Channel5 collision
to node6 Conn4
Rx_ack
Goto_b1 In1
-T-
coll56
From_coll8 [ok45] Goto8
collision
coll22
-T-
Packets Send8
#success4 coll44
In1
#Collisions 2
coll1
From_a2
#collisions
en2
From_c7
Packets Send7 #success3 coll33
-T-
hops
[ok1]
en1
From_d2 #Collisions 9
en
-T-
[ok34]
en1
to node6 Conn4
Packets send to node 6
The relationship between the throughput and the number of hops of these models for each TCP flow is shown in Figure (6. 48) at various data rates. Throughput & Number of hops at data rate = 50 packet/sec 400
150
100
TCP TCP TCP TCP
350 300 Throughput (kbps)
Throughput (kbps)
Throughput & Number of hops at data rate = 10 packet/sec 250 TCP flow 1 Simevents TCP flow 1 OPNET TCP flow 2 Simevents 200 TCP flow 2 OPNET
flow 1 Simevents flow 1 OPNET flow 2 Simevents flow 2 OPNET
250 200 150 100
50 50
0
0
1
2 3 Number of hops (hop)
4
0
5
0
1
(a)
200 150
300
200 150
50
50
4
0
5
(c)
flow 1 Simevents flow 1 OPNET flow 2 Simevents flow 2 OPNET
250
100
2 3 Number of hops (hop)
TCP TCP TCP TCP
350
100
1
5
Throughput & Number of hops at data rate = 120 packet/sec 400
Throughput (kbps)
Throughput (kbps)
250
0
4
(b)
Throughput & Number of hops at data rate = 100 packet/sec 400 TCP flow 1 Simevents 350 TCP flow 1 OPNET TCP flow 2 Simevents 300 TCP flow 2 OPNET
0
2 3 Number of hops (hop)
0
1
2 3 Number of hops (hop)
4
5
(d)
Figure (6.48): The relationship between throughput and the number of hops of cross-topology four-hop ad-hoc networks at various data rates.
It is obvious from Figure (6.48) that the throughput of these models is smaller than the throughput of chain-topology for the same number of hops. This is expected because of the presence of two(199)
flows in cross-topology. The throughputs of first-hop are 180, 280, 290 and 290 kbps for data rates equal 10, 50, 100 and 120 packet/sec. respectively. It is possible to conclude that the throughput will increase when the data rate increases until (100 packet/sec.), after that and due to the contention between the two flows the throughput remains almost constant. It is worth mentioning that the overall throughput with variable data rate for each flow is unstable as shown in Table (6.4).
Table (6.4): The overall throughput with variable data rate for two-flow, and the throughput variation percentage of each flow. Data rate (packet/sec.)
10
25
50
66.6 100
120
Throughput (kbps) of TCP flow 1 22.5 29 21.6 24.5 15.5 24.5 (Simevents) Throughput (kbps) of TCP flow 1 26 32 27.7 24.7 16.7 29.7 (OPNET) Throughput (kbps) of TCP flow 2 25 23 15 25.1 34 24.1 (Simevents) Throughput (kbps) of TCP flow 2 23 21.5 14 33.6 33 31 (OPNET)
The throughput variation percentage % 46.6%
47.8 %
55.9%
58.3 %
The unfairness problem between two-flows is clear from the comparison between the change percentage of flows 1 and 2 as shown in Table (6.4). Figure (6.49) shows the relationship between the queue length of nodes (1, 3 and 5) and the variable data rates. The maximum
(200)
queue of intermediate nodes 1, 3 and 5 are 15.9, 8.7 and 7.4 packets respectively. The value of the queue for node 1 is very high when it is compared to the buffer capacity of this node; therefore, this value will seriously limit the performance of multi-hop ad-hoc networks especially in terms of the end-to-end throughput.
The average queue length (packet)
The average queue length of cross-topology four-hop ad-hoc networks using OPNET and Simevents 20 OPNET (cross-point (node 1)) Simevents (cross-point (node 1)) 18 OPNET (TCP flow1 (node 3)) Simevents (TCP flow1 (node 3)) 16 OPNET (TCP flow2 (node 5)) 14 Simevents (TCP flow2 (node 5)) 12 10 8 6 4 2 0
0
20
40
60 80 Date rate (packet/sec)
100
120
Figure (6.49): The queue length of nodes 1, 3 and 5 as a function of the data rate of the cross-topology model using OPNET and Simevents.
Figure (6.50) shows the relationship between the average delay of node 1 and the time of simulation of the cross-topology using Simevents and OPNET at a data rate equal to 100 packet/sec. It is obvious from Figure (6.50) that the average delay of node 1 is more than the delay of the same node but in the case of chain topology, this can be illustrated as follows: node 1 in the case of crosstopology will suffer from the intra-flow and inter-flow problems. As
(201)
expected, the high delay of node 1 will cause instability problem and the congestion of this node will certainly degrade the performance of multi-hop ad-hoc networks. Delay of Node1 using Simevents and OPNET for cross-topology 800 Simevents OPNET
700
Delay in node 1 (msec.)
600 500 400 300 200 100 0
0
50
100
150 200 Time simulation (sec.)
250
300
350
Figure (6.50): The average delay of node 1 as a function of the time of simulation of the cross-topology at a data rate equal to 100 packet/sec.
6.6 Simulation of Distributed Packet Scheduling Algorithm: This algorithm is designed to alleviate the congestion and to reduce the TCP intra-flow problem that is resulted from the contention between nodes at the same flow; consequently, the performance of multi-hop ad-hoc networks will be inproved (especially under heavy load) using chain topology. This algorithm is implemented on the four-hop model which suffered from instability more than other models. The results of this algorithm are arranged as follows:
(202)
6.6.1 The throughput curves of DPSA for chain-topology: Figure (6.51) shows the relationship between the average throughput and the variable data rate of the four-hop model using DPSA. As expected, the end-to-end throughput of the four-hop model is improved in two directions; the first one is the value which changes from 70 to 75 kbps for the same model without and with DPSA respectively. The second one is the stability where the throughput variation percentage is equal to 48.5% without DPSA and becomes equal to 16% with DPSA. It is possible to conclude that the DPSA has the capability to improve the throughput of the last-hop and to regulate the throughput performance of the remaining hops as shown in Figure (6.51). The relationship between throughput and variable data rate of four-hop chain-topology 800 First-hop Second-hop Third-hop Four-hop
700
Throughput (Kbps)
600
500
400 300
200
100
0
0
20
40
60
80 100 Date rate (packet/sec)
120
140
160
Figure (6.51): The average throughput as a function of the data rate for chain-topology using DPSA.
(203)
6.6.2 The queue length of intermediate nodes for chain-topology: The instantaneous queue length of intermediate nodes after the application of DPSA into four-hop model are shown in Figure (6.52) at a data rate equal (100 packet/sec). The instantaneous number of dropped packets at node 2 is shown in Figure (6.52-b).
a)
b)
c)
d)
Figure (6.52): The instantaneous results of the chain-topology with DPSA: a) The instantaneous queue length of node 2 using DPSA. b) The instantaneous dropped packets of node 2 using DPSA. c) The instantaneous queue length of node 3 using DPSA. d) The instantaneous queue length of node 4 using DPSA.
(204)
Figure (6.53) shows the relationship between the queue size of nodes 2 and the variable data rates with and without DPSA. The maximum queue of intermediate node 2 is equal to 0.015 packets when DPSA is used. This value is very small compared to the buffer capacity of this node; therefore, this algorithm will improve the performance of multi-hop ad-hoc networks especially in terms of intra-flow problem. The average queue size of node 2 9 8
The average queue size (packet)
7 6 5 4 OPNET without DPSA Simevents without DPSA Simevents with DPSA
3 2 1 0
0
20
40
60 80 Date rate (packet/sec)
100
120
140
Figure (6.53): The average queue size of node 2 as a function of the data rate for chain-topology with and without DPSA.
6.6.3 The delay of node 2 and end-to-end delay of chain-topology: Figure (6.54) shows the relationship between the average delay of node 2 and the variable data rates. For chain-topology with DPSA, the congestion in this node has no effect on the performance of multi-hop ad-hoc networks especially under heavy load.
(205)
The average delay of node 2 in Four-hop model
The average delay of node 2 (msec.)
250
200
150
OPNET without DPSA Simevents without DPSA Simevents with DPSA
100
50
0
0
20
40
60 80 100 Date rate (packet/sec)
120
140
Figure (6.54): The average delay of node 2 as a function of the data rate for chain-topology with and without DPSA. Figure (6.55) shows the relationship between the average endto-end delay of four-hop model and the variable data rates. It is worth mentioning that the DPSA reduces efficiently the delays of all intermediate nodes as well as reducing the queue size of all nodes too; therefore, the end-to-end delay is reduced approximately to half the maximum value of the four-hop model without DPSA. The average end-to-end delay of Four-hop model
The average end-to-end delay (msec.)
500
400
300
200
100
0
OPNET without DPSA Simevents without DPSA Simevents with DPSA 0
20
40
60 80 100 Date rate (packet/sec)
120
140
Figure (6.55): The average end-to-end delay as a function of the data rate for chain-topology with and without DPSA. (206)
6.6.4 The throughput curves of DPSA for cross-topology: Figures (6.56 & 6.57) show the relationship between the average throughput of TCP flows (1 & 2) and the variable data rate of the four-hop model using cross-topology with DPSA. The overall throughput of flow is improved (the throughput is changed from 29 to 45 kbps at data rate equal to 25 packet/sec.) while the throughput of TCP flow 2 is changed from 34 to 52.4 kbps at a data rate equal to (100 packet/sec.). The average throughput versus the variable data rate of TCP flow 1 for cross topology 350
The average throughput (kbps)
300 First-hop Second-hop Third-hop Fourth-hop
250
200
150
100
50
0
0
20
40
60 80 100 120 Data Rate (packet/sec.)
140
160
Figure (6.56): The average throughput as a function of the data rate for TCP flow 1 using DPSA.
(207)
The average throughput versus the variable data rate of TCP flow 2 for cross topology 350
The average throughput (kbps)
300 First-hop Second-hop Third-hop Fourth-hop
250
200
150
100
50
0
0
20
40
60 80 100 120 Data Rate (packet/sec.)
140
160
Figure (6.57): The average throughput as a function of the data rate for TCP flow 2 using DPSA.
The DPSA improves acceptably the fairness between the two flows but cannot solve completely the TCP instability problem where the average queue length of nodes 1, 3 and 5 have the values o.18, 0.57 and 0.74 packets respectively at a data rate equal to 100 packet/sec as shown in Figure (6.58). The average queue length of node 1 with and without DPSA 16
The average queue length (packet)
14 12 10 8 OPNET without DPSA Simevents without DPSA Simevents with DPSA
6 4 2 0
0
20
40
60 80 Date rate (packet/sec)
100
120
Figure (6.58): The average queue length of node 1 as a function of the data rate for cross-topology with and without DPSA. (208)
The instantaneous queue lengths of some of the intermediate nodes (node 5 which is located on TCP flow 1 while node 3 is located on TCP flow 2) are shown in Figure (6.59) at data rate equal (100 packet/sec). The instantaneous number of dropped packets at node 2 is shown in Figure (6.59-b).
a)
b)
d)
c)
Figure (6.59): The results of four-hop model using DPSA are as follows: a) Instantaneous queue length of node 1 as a function of simulation time. b) Instantaneous dropped packets of node 1 as a function of simulation time. c) Instantaneous queue length of node 3 as a function of simulation time. d) Instantaneous queue length of node 5 as a function of simulation time.
(209)
It is possible to conclude that DPSA can reduce efficiently the delays of all intermediate nodes as well as reducing the delay of node 1 (which represents the cross point of the two TCP flows). Figure (6.60) shows the relationship between the average delay of node 1 and the simulation time. Delay of Node1 with and without DPSA for cross-topology 550 500 450
Delay of node 1 (msec.)
400 Simevents without DPSA OPNET without DPSA Simevents with DPSA
350 300 250 200 150 100 50 0
0
50
100
150 200 Time simulation (sec.)
250
300
350
Figure (6.60): The average delay of node 1 as a function of the simulation time for cross-topology with and without DPSA.
6.7 Simulation of TCP Contention Control (TCC) algorithm: TCP instability can be treated by controlling the amount of network overload; (TCC) cross layer algorithm is proposed and is simulated using the Simevent tools; consequently, the performance of chain or cross topologies multi-hop ad-hoc networks will be inproved especially under heavy load condition.
(210)
This algorithm is implemented to improve the four-hop model which suffered from instability more than other models. The results of this algorithm are arranged as follows: 6.7.1 The throughput of chain-topology with TCC: Figure (6.61) shows the relationship between the average throughput and the number of hops of the four-hop model with TCC. The average throughput versus the number of hops with and without TCC
The average throughput (kbps)
900 800
Simevents with TCC OPNET without TCC Simevents without TCC
700 600 500 400 300 200 100 0 0
1
2 3 Number of hops (hop)
4
5
Figure (6.61): The average throughput as a function of the number of hops for chain-topology using TCC.
As expected, the improvement of the end-to-end throughput performance of the four-hop model includes the followings: 1. The value of the throughput changes from 55 to 82.7 kbps for the same model without and with TCC respectively. 2. The improved throughput percentage is equal to 33.5%.
(211)
3. The stability of chain-topology results show that the throughput variation percentage is equal to 48.5% without TCC while with TCC, the throughput variation percentage will be 7.5%. 4. It maintains the stability during the transmission of the data. 6.7.2 The queue length of intermediate nodes for chain-topology: The instantaneous queue length of the intermediate nodes after the application of TCC into the four-hop model is shown in Figure (6.62). The instantaneous number of dropped packets at node 2 is shown in Figure (6.62-b). It is worth mentioning that this algorithm has reduced the unnecessary buffering of packets in the network.
(a)
(b)
(c)
(d)
Figure (6.62): The results of the four-hop model with TCC are as follows: (a) The instantaneous queue length of node 2 as a function of simulation time. (b) The instantaneous dropped packets of node 2 as a function of simulation time. (c) The instantaneous queue length of node 3 as a function of simulation time. (d) The instantaneous queue length of node 4 as a function of simulation time.
(212)
6.7.3 The delay performance of chain-topology with TCC: Figure (6.63) shows the relationship between the average delay of node 2 and the simulation time. For chain-topology, TCC will reduce the congestion in this node for all values of the time of simulation greater than 150 sec. On other hand, TCC decreases the data rate of the source to alleviate the delay which results from the contention between nodes and from the delay of the waiting packets in the buffer of node 2. The average delay of node 2 in four-hop model
The average delay of node 2 (msec.)
250
200 OPNET without TCC Simevents without TCC Simevents with TCC
150
100
50
0
0
50
100
150 200 Simulation time (sec.)
250
300
Figure (6.63): The average delay of node 2 versus the simulation time for chain-topology with and without TCC.
Figure (6.64) shows the relationship between the average end-to-end delay of the four-hop model and the time of simulation. It is worth mentioning that TCC reduces very efficiently the delays of all intermediate nodes as well as reducing the queue size of all nodes.
(213)
Finally, it is possible to conclude that the end-to-end delay is reduced approximately to less than half the maximum value of the four-hop model without TCC as shown in Figure (6.64). The average end-to-end delay of the four-hop model 550
The average end-to-end delay (msec.)
500 450 400 350 300 250 200 150 100
OPNET without TCC Simevents without TCC Simevents with TCC
50 0
0
50
100
150 200 Simulation time (sec.)
250
300
Figure (6.64): The average end-to-end delay versus the simulation time for chain-topology with and without TCC.
6.7.4 The throughput curves of TCC for cross-topology: Figures (6.65 & 6.66) show the average throughput of TCP flows (1 & 2) versus the number of hops of the four-hop model using cross-topology with TCC. The total throughput of each flow is improved significantly (the throughput of flow 1 is changed from 29 to 70 kbps while the throughput of TCP flow 2 is changed from 34 to 66.7 kbps) as compared with the case of without TCC.
(214)
The average throughput versus the number of hops for TCP 1 with and without TCC
The average throughput (kbps)
400
Simevents with TCC OPNET without TCC Simevents without TCC
350 300 250 200 150 100 50 0 0
1
2 3 Number of hops (hop)
4
5
Figure (6.65): The average throughput as a function of the number of hops for TCP 1 in cross-topology using TCC.
The average throughput versus the number of hops for TCP 2 with and without TCC Simevents with TCC OPNET without TCC Simevents without TCC
The average throughput (kbps)
400 350 300 250 200 150 100 50 0 0
1
2 3 Number of hops (hop)
4
5
Figure (6.66): The average throughput as a function of the number of hops for TCP 2 in cross-topology using TCC.
(215)
TCC improves acceptably the fairness between the two flows but it cannot solve completely the TCP instability problem (the average queue length of nodes 1, 3 and 5 have the values o.41, 0.55 and 0.4 packets respectively), see Figure (6.67). The average queue length of nodes 1, 3 and 5 with TCC
The average queue length (packet)
0.6
0.5
0.4
0.3
Node 1 Node 3 Node 5
0.2
0.1
0
0
50
100
150 200 Simulation time (sec.)
250
300
350
Figure (6.67): The average queue length of nodes 1, 3 and 5 as a function of the simulation time for cross-topology with TCC.
TCC algorithm can reduce acceptably the delays of all intermediate nodes besides reducing the delay of node 1 (which represents the cross point of the two TCP flows). Figure (6.68) shows the relationship between the average delay of node 1 and the simulation time. It is obvious that TCC has the capability to reduce the congestion in this node for cross-topology and to improve the performance of multi-hop ad-hoc networks especially
(216)
when the time of simulation exceeds 100 sec. On other hand, TCC decreases the data rate of the source to alleviate the delay which results from the contention between nodes and from the waiting packets in the buffer of node 1. Delay of node1 with and without TCC for cross-topology 550 500 450
Delay of node 1 (msec.)
400 Simevents without TCC OPNET without TCC Simevents with TCC
350 300 250 200 150 100 50 0
0
50
100
150 200 Simulation time (sec.)
250
300
350
Figure (6.68): The average delay of node 1 versus the simulation time for cross-topology with and without TCC.
6.8 Simulation of Round Robin Scheduling algorithm (RRSA): As mentioned before, the distributed packet scheduling algorithm is used to achieve optimum packet scheduling for chaintopology and to avoid severe intra-flow contention in each flow while the Round Robin Scheduling algorithm can be used to achieve fairness for cross-topology and to avoid severe inter-flow contention between the flows. RRSA (proposed) is the combination of the two algorithms which can be used to improve the performance of cross-topology of
(217)
multi-hop ad-hoc networks. It is worth to mention that the performance of RRSA is similar to the performance of DPSA for chain-topology; therefore, the results of RRSA for chain-topology are not mentioned in this section. This algorithm is applied to the four-hop model which suffered from instability more than other models. The results of this algorithm are arranged as follows: 6.8.1 The throughput curves of RRSA for cross-topology: Figures (6.69 & 6.70) show the relationship between the average throughput of TCP flows (1 & 2) and the variable data rate of the four-hop model using cross-topology with RRSA. The overall throughput of flow 1 is improved (the throughput is changed from 29 to 77.9 kbps at data rate equal to 25 packet/sec.) while the throughput of TCP flow 2 is changed from 34 to 100.4 kbps at a data rate equal to (100 packet/sec.). The average throughput versus the variable data rate of TCP flow 1 for cross topology First-hop Second-hop Third-hop Fourth-hop
The average throughput (kbps)
350 300 250 200 150 100 50 0
0
20
40
60 80 100 Data Rate (packet/sec.)
120
140
160
Figure (6.69): The average throughput as a function of the data rate for TCP flow 1 using RRSA. (218)
The average throughput versus the variable data rate of TCP flow 2 for cross topology First-hop Second-hop Third-hop Fourth-hop
The average throughput (kbps)
350 300 250 200 150 100 50 0
0
20
40
60 80 100 120 Data Rate (packet/sec.)
140
160
Figure (6.70): The average throughput as a function of the data rate for TCP flow 2 using RRSA.
Figures (6.71) show the relationship between the average throughput of TCP flow 1 and the number of hops for different data rates of the cross-topology four-hop model with RRSA. The average throughput versus the number of hops for TCP flow 1 in cross-topology 150 packet/sec. 125 packet/sec. 100 packet/sec. 75 packet/sec. 50 packet/sec. 25 packet/sec. 10 packet/sec.
The average throughput (kbps)
350 300 250 200 150 100 50 0
0
1
2 3 Number of hops (hop)
4
5
Figure (6.71): The average throughput as a function of the number of hops for TCP flow 1 with various data rates using RRSA. (219)
It is clear from Figure (6.71) that the throughput values increases as the data rate increases up to the data rate which is equal to (100 packet/sec.) after which no significant improvement is measured. The reason of that is related to the contention, overhead packets which prevent the throughput from increasing and the capability of RRSA which reaches the stable condition of performance. 6.8.2 The queue length of intermediate nodes for cross-topology: RRSA improves efficiently the fairness between the two flows and solves completely the TCP instability problem (for example, the average queue length of nodes 1, 3 and 5 have the small values o.129, 0.088 and 0.125 packets respectively at a data rate equal to 100 packet/sec.). In addition, the two flows pass through this node independently. On other hand, this node is similar to the access point in the infrastructue mode which has a centralized control. The instantaneous queue length of some intermediate nodes after the application of RRSA into the four-hop model with crosstopology is shown in Figure (6.72). The instantaneous number of dropped packets at node 1 is shown in Figure (6.72-b). It is obvious that this algorithm has reduced the unnecessary buffering of packets in the network.
(220)
(a)
(b)
(c)
(d)
Figure (6.72): The results of the four-hop model with RRSA are as follows: (a) The instantaneous queue length of node 1 as a function of simulation time. (b) The instantaneous dropped packets of node 1 as a function of simulation time. (c) The instantaneous queue length of node 3 as a function of simulation time. (d) The instantaneous queue length of node 5 as a function of simulation time.
6.8.3 The delay at node 1 of the cross-topology with RRSA: Figure (6.73) shows the relationship between the average delay of node 1 and the simulation time. It is possible to conclude that RRSA can reduce efficiently the delays of all intermediate nodes as well as reducing the delay of node 1 although this node applies round robin fashion (RRF) which adds very small delay time.
(221)
Delay of node1 with and without RRSA for cross-topology 550 500
Delay of node 1 (msec.)
450 400 350
Simevents without RRSA OPNET without RRSA Simevents with RRSA
300 250 200 150 100 50 0
0
50
100
150 200 Simulation time (sec.)
250
300
350
Figure (6.73): The average delay of node 1 versus the simulation time for cross-topology with and without RRSA. 6.9 A comparison between the presented algorithms: The comparison between the different algorithms has taken into the throughput, queue length and delay and as follows: 6.9.1 The throughput: For chain-topology, the best algorithm regarding the average end-to-end throughput is found to be TCC, as shown in Figure (6.74); the throughput improved percentage variation is equal to 15.3% relative to the average throughput of DPSA or RRSA. For cross-topology, RRSA is the best, the throughput improved percentage variation is equal to 29.7% relative to the average throughput of TCC, the latter has an improvement in the throughput percentage variation equal to 25.1% relative to the average throughput of DPSA, see Figure (6.75).
(222)
The average throughput versus number of hops for chain-topology
Throughput (Kbps)
800
DPSA TCC RRSA
600
400
200
0
0
1
2 3 Number of hops (hop)
4
5
Figure (6.74): The average throughput as a function of the number of hops for various algorithms in chain-topology.
The average throughput versus number of hops for cross-topology
DPSA TCC RRSA
Throughput (Kbps)
400
300
200
100
0
0
1
2 3 Number of hops (hop)
4
5
Figure (6.75): The average throughput as a function of the number of hops for various algorithms in cross-topology.
(223)
6.9.2 The average queue length of node 1 in cross-topology: Figure (6.76) shows the relationship between the average queue length of node 1 and simulation time for cross-topology with various algorithms. The minimum queue length of the various algorithms follow the relationship: QRRSA< QDPSA< QTCC Form the results, QRRSA = 0.14 packet, QDPSA = 0.18 packet and QTCC = 0.41 packet. The average queue length of node 1 versus simulation time with various algorithms DPSA TCC RRSA
The average queue length (packet)
0.5
0.4
0.3
0.2
0.1
0
0
50
100
150 200 Simulation time (sec.)
250
300
350
Figure (6.76): The average queue length of node 1 as a function of simulation time for cross-topology with various algorithms.
6.9.3 The average delay of node 1 in cross-topology: Figure (6.77) shows the relationship between the average delay of node 1 and the simulation time for cross-topology with
(224)
various algorithms. The minimum delay of the different algorithms follows the relationship given below: DRRSA< DDPSA< DTCC Where DRRSA= 43 msec., DDPSA= 62 msec. and DTCC= 66 msec. The delay percentage with RRSA is equal to 32.4% relative to the delay of DPSA, the latter delay percentage is equal to 6.7% relative to the delay of TCC, see Figure (6.75).
Delay of node1 versus simulation time for cross-topology with various algorithms
80
Delay of node 1 (msec.)
70 60 50 40 DPSA TCC RRSA
30 20 10 0
0
50
100
150 200 Simulation time (sec.)
250
300
350
Figure (6.77): The average delay of node 1 as a function of simulation time for cross-topology with various algorithms.
(225)
Chapter Seven Conclusions and Suggestions for Future Works This Chapter deals with the conclusion of the results being obtained from the various network topologies and algorithms during this study. It includes single-hop, chain-topology multi-hop, crosstopology multi-hop wireless ad-hoc networks, DPSA, TCC and RRSA algorithms. In addition, it presents suggestions for some future works.
7.1 Conclusions: In this thesis, the various problems and their impact on the throughput and delay performances of multi-hop wireless ad-hoc networks, like TCP instability and unfairness problems are studied and analyzed in detail; therefore, it is easy to conclude the followings:
1. For multi-hop wireless ad-hoc networks, the large number of hops will cause the throughput to be degraded due to the high RTT delay, hidden stations and the large number of contentions between nodes.
2. In chain-topology, the increment of the data rate has a small effect on the queue length of the two-hop model; this effect will increase when the number of hops increases. The result shows that the queue length of three-hop model will be significantly incremented at (data rate ≥ 75 packet/sec.) while in the case of four hops, the queue length will be incremented at (data rate ≥ 25 packet/sec.);
(226)
this means that increasing the number of hops will make the model more sensitive to the increment of the data rate.
3. The end-to-end throughput between any two nodes in the chain is independent of the queue length of the intermediate queues.
4. The results show that TCP intra-flow instability problem is more serious in the case of three hops or more; this fact justifies the use of four hops models in this thesis.
5. The first intermediate node will suffer more than other nodes from TCP intra-flow instability problem in chain-topology models. It is also found that this node will suffer severely from TCP inter-flow if the two flows pass through it, (this is the worst case in multi-hop wireless ad-hoc networks). For these reasons, RRSA algorithm is proposed in this thesis to solve the TCP flows problems.
6. A simple modification is required to implement DPSA with Simevents while complex modification is required to apply TCC (cross-layer algorithm) in the case of four hops model.
7. TCC contains feedback control; therefore, it has the capability to automatically regulate the data rate based on the statuses of the contending nodes. Consequently, it is recommended to use TCC in cross-topology having two sources with different data rates.
8. For cross-topology with RRSA, the two flows that pass through the intercept node are independent of each other. In fact, this node (227)
is similar to the access point in the infrastructue mode with centralized control.
9. In chain-topology, TCC is the best regarding the average end-toend throughput percentage variation; the results show that this percentage is equal to 15.3% relative to the average throughput of DPSA or RRSA. While in cross-topology, RRSA is the best where the throughput percentage variation is equal to 29.7% relative to the average throughput of TCC; on the other hand, the latter has the throughput improvement percentage variation equal to 25.1% relative to the average throughput of DPSA.
10.Simulation results show that the queue length and delay follow the following relationships:
QRRSA< QDPSA< QTCC for queue length. DRRSA< DDPSA< DTCC for delay in the first intermediate. 11. RRSA provides the optimum fairness between the TCP flows as compared with other algorithms especially in cross-topology multi-hop wireless ad-hoc networks.
(228)
7.2 Suggestions for Future Works: The area of multi-hop wireless networks is still an exciting field of research, and hence, there are several possible directions in which this research work could be extended in the future. The suggestions for future works include:
1. Studying the effect of other routing protocols like Dynamic Source routing (DSR) and Optimized Link State Routing (OLSR) on the performance of multi-hop ad-hoc networks using Simevents and OPNET simulators.
2. Applying the algorithms, Various Queuing Algorithms (VQA) and Fair Backoff algorithm (FBA) to improve the performance of multihop ad-hoc networks using Simevents and OPNET.
3. Introducing mobility effect (i.e. time changing topology) on the endto-end throughput in multi-hop ad-hoc networks.
4. Analysing and designing different congestion control and power control schemes using cross-layer algorithms to improve the performance of multi-hop ad-hoc networks.
5. Designing a new medium access control (MAC) protocol for quality-of-service (QoS) support in multi-hop ad-hoc wireless networks.
(229)
References [1] IEEE Standard 802.11," Part 11: Wireless LAN medium access control (MAC) and physical layer (PHY) specifications", 1999. [2] Raja Jurdak," Wireless Ad Hoc and Sensor Networks", Springer Series on signals and communications technology, 2007. [3] E. S. Biagioni," Algorithms for communication in Wireless multi-hop ad hoc Networks using Broadcasts in Opportunistic Large Arrays (OLA)", Proc. of 16th International Conference on Computer Communications and Networks (ICCCN), pp. 1111–1116, 13-16 Aug. 2007. [4] J. Li, Z. J. Haas and M. Sheng," Capacity evaluation of multi-channel multi-hop ad hoc networks,", International Conference on Personal Wireless Communications (ICPWC), pp. 211- 214, New York , USA, 15-17 Dec. 2002. [5] IEEE Standard 802.16e, "Part 16: Air Interface for Fixed and Mobile Broadband Wireless Access Systems", 2005. [6] P. Mahasukhon, H. Sharif, M. Hempel, T. Zhou, W. Wang, and T. Wysocki," Performance Analysis of Multi-hop IEEE 802.11 DCF Backhaul Networks", International Conference on Wireless and Mobile Computing on Networking and Communications (WiMOB), pp. 69-74, 12-14 Oct. 2008. [7] J. Bergs, D. Naudts, C. Blondia, N. V. Wijngaert, I. Moerman and P. Demeester," A Wireless Network for Emergency Services: a MultiChannel Ad-Hoc Approach", published in Proceedings of RECOM2007, the Wireless Rural and Emergency Communications Conference, Rome, Italy, 01-02 October 2007. Available on: http://webserver8.intec.ugent.be/index.php/getpdf/3124?file=public.pdf
[8] A. Gupta, I. Wormsbecker, C. Williamson," Experimental Evaluation of TCP Performance in Multi-hop Wireless Ad Hoc Networks", Proceedings of IEEE/ACM MASCOTS, pp. 3-11, Volendam, Netherlands, October 2004.
(230)
[9]
P. Chung Ng and S. Chang Liew," Throughput Analysis of IEEE802.11 Multi-Hop Ad Hoc Networks", IEEE/ACM transaction on networking, vol. 15, no. 2, April 2007.
[10] J. Jun and M. L. Sichitiu," Fairness and QoS in Multihop Wireless Networks", Vehicular Technology Conference (VTC) IEEE 58th, vol. 5, pp. 2936-2940 vol. 5, 6-9 Oct. 2003. [11] J. Liu and S. Singh, “ATCP: TCP for mobile ad hoc networks,” IEEE J-SAC, vol. 19, no. 7, pp. 1300–1315, 2001. [12] L. Dong, Y. Shu, M. Sanadidi and M. Gerla," A Method for Improving the TCP Fairness in Wireless Ad Hoc Networks", 4th International Conference on Wireless Communications, Networking and Mobile Computing (WiCOM), pp. 1-4, 12-14 Oct. 2008. [13] M. Conti, G. Maselli and S. Giordano," Cross-Layering in Mobile Ad Hoc Network Design", IEEE Computer Society, vol. 37, no. 2, pp. 48–51, February 2004. [14] G. Cheol Lee and H. Song," Cross Layer Optimized Video Streaming based on IEEE 802.11 Multi-rate over Multi-hop Mobile Ad Hoc Networks", Springer, Mobile Netw Appl, vol. 15, pp. 652–663, 2010. [15] K. Chen, Y. Xue, S. H. Shah and K. Nahrstedt," Understanding bandwidth-delay product in mobile ad hoc networks", Computer Communications, vol. 27, no. 10, pp. 923–934, June 2004. [16] R. de Oliveira and T. Braun," A Dynamic Adaptive Acknowledgment Strategy for TCP over Multihop Wireless Networks", In Proceedings of Twenty-Fourth Annual Joint Conference of the IEEE Computer and Communications Societies (INFOCOM), vol. 3, March 2005. [17] R. Verma, A. Prakash, R. Tripathi and N. Tyagi," Throughput enhancement of multi-hop static ad-hoc networks through concurrent transmission", IEEE computer society, First International Conference on Computational Intelligence, Communication Systems and Networks, pp. 482-485, 2009. [18] G. Bianchi," Performance analysis of the IEEE 802.11 distributed coordination function", IEEE Journal on Selected Area in Communications, vol. 18, no. 3, pp. 535– 547, 2000. (231)
[19] S. Rahman," Throughput Analysis of IEEE 802.11 Distributed Coordination Function in Presence of Hidden Stations", Stanford CA USA.2002. Available on: www.stanford.edu/class/ee384y/projects/download03/shahriar2.pdf
[20] Z. Fu, P. Zerfos, H. Luo, S. Lu, L. Zhang and M. Gerla," The impact of multi-hop wireless channel on TCP throughput and loss", Proceedings of IEEE INFOCOM 2003, San Francisco (California), March 30. April 3, 2003. [21] C. Ng, and S. C. Liew," Offered load control in IEEE 802.11 multihop ad-hoc networks", Proc. of the 1st IEEE International Conference on Mobile Ad-hoc and Sensor System (MAHSS), pp. 80- 89, 25-27 Oct. 2004. [22] H. Zhai, J. Wang and Y. Fang," Distributed Packet Scheduling for Multi-hop Flows in Ad Hoc Networks", Wireless Communications and Networking Conference (WCNC), vol. 2, pp. 1081- 1086, 21-25 March 2004. [23] E Hamadani and V Rakocevic, "Evaluating and Improving TCP Performance Against Contention Losses in Multihop Ad Hoc Networks", International Conference on Mobile and Wireless Communication Networks (IFIP), Marrakech, Morocco, September 2005. [24] D. Kliazovich and F. Granelli, “Cross-Layer Congestion Control in Ad Hoc Wireless Networks”, Ad Hoc Networks, vol. 4, no. 6, pp. 687708, 2006. [25] C. Que, X. Zhang, Y. Liu, Y. Huang," Performance Analysis of Chain Topology in IEEE 802.11 Multi-hop Ad hoc Networks", International Conference on Convergence Information Technology (ICCIT), pp. 1880-1883, 21-23 Nov. 2007. [26] H. Zhai, X. Chen, and Y. Fang," Improving Transport Layer Performance in Multi-hop Ad Hoc Networks by Exploiting MAC Layer Information", IEEE transaction on wireless communication, vol. 6, no. 5, pp.: 1692-1700, May 2007. [27] W. Bo, S. Fei, Z. Sidong and Z. Hongke, " Throughput modeling analysis of IEEE 802.11 DCF mechanism in multi-hop non-saturated (232)
wireless ad-hoc networks", International Conference on Communications Circuits and Systems (ICCCAS), pp. 383-387, 25-27 May 2008. [28] Y. Lien and Y. Yu," Hop-by-Hop TCP over MANET", Asia-Pacific Services Computing Conference (APSCC), pp. 1150-1155, 9-12 Dec. 2008. [29] A. Valletta, A. Todini and A. Baiocchi ," On the unfairness among TCP flows in IEEE 802.11 multi-hop ad-hoc networks", Telecommunication Networking Workshop on QoS in Multiservice IP Networks (IT-NEWS), 4th International , pp. 53-59, 13-15 Feb. 2008. [30] L. Wu, Y. Fu and L. Dong," End-to-End Throughput Optimization in Multi-hop Wireless Ad Hoc Networks", IEEE, Proceedings of the 15th Asia-Pacific Conference on Communications (APCC 2009), pp. 40-43, 8-10 Oct. 2009. [31] K. Saravanan," A Cross-Layer Based High Throughput MAC Protocol for 802.11 Multihop Adhoc Networks", European Journal of Scientific Research, ISSN 1450-216X, vol. 33, no. 4 pp. 575-584, 2009. Available on: http://www.eurojournals.com/ejsr.htm
[32] W. Long and W. Zhenkai," Performance Analysis of Improved TCP over Wireless Networks", IEEE computer society, Second International Conference on Computer Modeling and Simulation, (ICCMS), vol. 1, pp .239-242, 22-24 Jan. 2010. [33] T. SUGIMOTO, N. KOMURO, H. SEKIYA, S. SAKATA and K. YAGYU, " Maximum Throughput Analysis for RTS/CTS-used IEEE 802.11 DCF in Wireless Multi-hop Networks", International Conference on Computer and Communication Engineering (ICCCE 2010), Kuala Lumpur, Malaysia, 11-13 May 2010. [34] R. Pal Singh and D. K. Lobiyal," Throughput Analysis of Receiver Initiated Collision Avoidance in Multi hop Wireless Networks", International Journal of Computer Applications, vol. 16, no .6, pp. 4852, February 2011. [35] Steve Rackley, "Wireless Networking Technology", Elsevier Inc., Britain , 2007. (233)
[36] Katrin Bilstrup," A Survey Regarding Wireless Communication Standards Intended for a High-Speed Vehicle Environment", Technical Report IDE0712, Halmstad University, Sweden. February 2007. [37] Behrouz A. Forouzan," Data communications and networking", Fourth Edition, McGraw-Hill, Forouzan Networking Series, 2007. [38] J. Mikulka and S. Hanus," CCK and Barker Coding Implementation in IEEE 802.11b Standard", 17th International Conference on Radioelektronika, pp. 1-4, 24-25 April 2007. [39] Q. Nasir and M. Albalt," History Based Adaptive Backoff (HBAB) IEEE 802.11 MAC Protocol", Communication Networks and Services Research Conference (CNSR), 6th Annual , pp. 533-538, 5-8 May 2008. [40] Vijay K. Garg," Wireless communications and networking", Elsevier Inc., Britain , 2007. [41] H. Wu, Y. Peng, K. Long, S. Cheng and J. Ma," Performance of reliable transport protocol over IEEE 802.11 wireless LAN: analysis and enhancement", Twenty-First Annual Joint Conference of the IEEE Computer and Communications Societies (INFOCOM), vol. 2, pp. 599- 607, 2002. [42] C. Kanta Sama," TCP performance through simulation and testbed in Multi-Hop Mobile Ad hoc Network", International journal of Computer Networks & Communications (IJCNC), vol. 2, no. 4, pp. 109-124, (DOAJ), July 2010. [43] U. G. Swarnapriyaa, V. Vinodhini, S. Anthoniraj and R. Anand, "Auto configuration in Mobile Ad hoc Networks", National Conference on Innovations in Emerging Technology (NCOIET), pp. 61-66, 17-18 Feb. 2011. [44] G. Breed," Wireless Ad-hoc networks: Basic Concepts", High Frequency Electronics, AD HOC NETWORKS, pp. 44-46, March 2007. [45] Mohammad Ilyas," The handbook of Ad-hoc wireless networks", CRC Press, Florida Atlantic University, 2002. (234)
[46] D. Akin, K. Sandlin, S. Turner, R. Nicholas, J. McCord, J. Jones, S. Brooks, B. Waldo and B. Oxford," Certified Wireless Network Administrator", Planet3 Wireless, Inc., P.O. Box 412, Bremen Georgia, United States of America, 2002. [47] IEEE Standard, "Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications", IEEE 802.11, 2005. [48] P. Chatzimisios, V. Vitsas and A. C. Boucouvalas," Throughput and delay analysis of IEEE 802.11 protocol," IEEE Proceedings 5th International Workshop on Networked Appliances, Liverpool, pp. 168- 174, 30-31 Oct. 2002. [49] R. Khalaf I. Rubin," Throughput and Delay Analysis in Single Hop and Multihop IEEE 802.11 Networks", 3rd International Conference on Broadband Communications Networks and Systems (BROADNETS), pp. 1-9, 1-5 Oct. 2006. [50] R. Rom, M. Sidi," Multiple access protocols: Performance and analysis ", Springer-Verlag, New York, 1990. [51] F. Hung and I. Marsic," Analysis of non-saturation and saturation performance of IEEE 802.11 DCF in the presence of hidden stations", IEEE 66th Vehicular Technology Conference, VTC-2007 Fall (VETECF), pp. 230-234, Sept. 30 2007-Oct. 2007. [52] M. Tahir, S. K. Mazumder," Markov Chain Model for Performance Analysis of Transmitter Power Control in Wireless MAC Protocol: Towards Delay Minimization in Power-network Control," 21st International Conference on Advanced Information Networking and Applications (AINA '07), pp. 909-916, 21-23 May 2007. [53] S. Xu, S. Papavassiliou, S. Narayanan," Layer-2 multi-hop IEEE 802.11 architecture: design and performance analysis," IEE Proc.Commun., vol. 151, no. 5, October 2004. [54] Lan Tien Nguyen, Razvan Beuran and Yoichi Shinoda, "Performance Analysis of IEEE 802.11 in Multi-hop Wireless Networks", Proc. of the 3rd international conference on Mobile ad-hoc and sensor networks (MSN), Springer-Verlag Berlin, Heidelberg, 2007. (235)
[55] M. kumar.S and S. Prakash.K," Wireless congestion control protocol for multi hop ad hoc networks", International Journal of Computer Science and Information Security (IJCSIS), vol. 7, no. 1, 2010. Available on: http://sites.google.com/site/ijcsis/ [56] H. Touati, I. Lengliz and F. Kamoun," Adapting TCP exponential backoff to multihop ad hoc networks", IEEE Symposium on Computers and Communications (ISCC), pp. 612-617, 5-8 July 2009. [57] Ahmad Al Hanbali, Eitan Altman, Philippe Nain, "A Survey of TCP over Ad Hoc Networks", B.P. 93, 06902 Sophia Antipolis Cedex, France. 2005. [58] Y. M. Omar, H. I. Sigiuk, H. Ben Salem, and T. T. Hamdan, " Improving TCP throughput stability in wireless multi-hop Ad hoc networks", 3rd International Conference on Signals, Circuits and Systems (SCS), pp. 1-6, 6-8 Nov. 2009. [59] A.Tsertou and D. I. Laurenson," Modeling the Effect of BEB for a Hidden Terminal Topology from a New Perspective", 3rd Annual IEEE Communications Society on Sensor and Ad Hoc Communications and Networks (SECON), vol. 2, pp. 607-614, 28-28 Sept. 2006. [60] Li-Chun Wang; Chung-Wei Wang; Yin-Chih Lu; Chuan-Ming Liu; , "A Concurrent Transmission MAC Protocol for Enhancing Throughout and Avoiding Spectrum Sensing in Cognitive Radio," Wireless Communications and Networking Conference (WCNC), pp. 121-126, 11-15 March 2007. [61] F. Ducatelle," Adaptive Routing in Ad Hoc Wireless Multi-hop Networks", Ph. D. Thesis. Lugano, Switzerland, May 2007. [62] Singh, B.; Mani, N.; Kadyan, S.; Deosarkar, B.; Shekhar, C.; , "Wireless Ad-Hoc Network: Analysis for Power Control Architecture," Second International Conference on Network Applications Protocols and Services (NETAPPS), pp. 72-77, 22-23 Sept. 2010.
(236)
[63] Maham, B.; Hjorungnes, A.," Minimum power allocation for cooperative routing in multihop wireless networks", IEEE, Sarnoff Symposium (SARNOFF), pp. 1-5, March 30 2009. [64] R. Ehrenreich Thorup," Implementing and Evaluating the DYMO Routing Protocol". M.Sc. Thesis, University of Aarhus, Denmark, Feb., 2007. [65] T. Larsson," Routing protocols in wireless ad-hoc networks- a simulation study", M.Sc. Thesis, Lulea Tekniska University, 1998. [66] K. Manoj, Parmanand, S. C. Sharma and S.P. Singh, "Performance of QoS Parameter in Wireless Ad hoc Network (IEEE 802.11b)", Proceedings of the World Congress on Engineering and Computer Science (WCECS), vol. 1, October 20-22, San Francisco, USA, 2009. [67] M. Velempini and M. E. Dlodlo," A Virtual Ad Hoc Routing Algorithm for MANETs", 2nd International Conference on Wireless Broadband and Ultra Wideband Communications (AUSWireless), pp. 22, 27-30 Aug. 2007. [68] Georgios Rodolakis," Analytical Models and Performance Evaluation in Massive Mobile Ad Hoc Networks". Ph.D. thesis, Macquarie University, 2006. [69] Marco Di Felice," Cross-Layer Optimizations in Multi-Hop Ad Hoc Networks", Ph.D. thesis, Department of Computer Science, University of Bologna, Italy, March 2008. [70] V. Kawadia and P. R. Kumar," A cautionary perspective on crosslayer design", IEEE Wireless Communications (MWC), vol. 12, no. 1, pp. 3-11, February 2005. [71] V. Srivastava and M. Motani," Cross-Layer Design: A Survey and the Road Ahead", IEEE Communications Magazine, vol. 43, no. 12, pp. 112–119, Dec. 2005. [72] S. Xu, T. Saadawi. "Does IEEE 802.11 MAC Protocol Work Well in Multi-hop Wireless Ad Hoc Networks?" IEEE Communication Magzine, vol. 39, no. 6, pp. 130-137, June 2001.
(237)
[73] M. Conti, G. Maselli and S. Giordano," Cross-Layering in Mobile Ad Hoc Network Design", IEEE Computer Society, vol. 37, no. 2, pp. 48–51, February 2004. [74] Z. Wu and D. Raychaudhuri," D-LSMA: Distributed Link Scheduling Multiple Access Protocol for QoS in Ad-hoc Networks", Global Telecommunications Conference (GLOBECOM), vol. 3, 29 Nov.-3 Dec. 2004. [75] S. Xuebin and Z. Zheng, " Energy conservation and routing efficiency tradeoff in multi-hop wireless ad hoc networks" International Conference on Communication Technology (ICCT), vol. 2, pp. 12781281, 9-11 April 2003. [76] C. Barrett, M. Drozda, and A. Marathe," Charactering the interaction between routing and MAC protocols in ad-hoc networks". In Proc. Of MOBIHOC 2002, pp.: 92–103. Lausanne, Switzerland, 2002. [77] S. Roy and D. Saha," A network-aware MAC and routing protocol for effective load balancing in ad hoc wireless networks with directional antenna". In Proc. of ACM Symposium on Mobile Ad Hoc Networking. Annapolis, USA, 2003. [78] D. Le, X. Fu and D. Hogrefe," A Cross-Layer Approach for Improving TCP Performance in Mobile Environments", Springer, Institute of Computer Science, University of Göttingen, Lotzestr. 16-18, 37083 Gottingen, Germany, 2008. [79] E. Hamadani and V. Rakocevic," A Cross layer Analysis of TCP Instability in Multihop Ad hoc Networks", Mobile Network Research Group, London EC1V 0HB, UK 2007. [80] E. Hamadani and V. Rakocevic," A Cross Layer Solution to Address TCP Intra-flow Performance Degradation in Multihop Ad hoc Networks", Journal of Internet Engineering, vol. 2, no. 1, pp. 146-156, 2008. [81] Z. Li, S. Nandi and A. K. Gupta," Modeling the Short-term Unfairness of IEEE 802.11 in Presence of Hidden Terminals", Springerlink, International Federation for Information Processing (IFIP), NETWORKING 2004, vol. 3042, pp. 613-625, 2004. Available on: http://www.cs.jhu.edu/~zfli/markov.pdf
(238)
[82] Y. Wang and J.J. Garcia-Luna-Aceves," Collision Avoidance in MultiHop Ad Hoc Networks", 10th IEEE International Symposium on Modeling, Analysis and Simulation of Computer and Telecommunications Systems (MASCOTS), pp. 145- 154, 2002. [83] Y. Wang J.J. Garcia-Luna-Aceves," Modeling of Collision Avoidance Protocols in Single-Channel Multihop Wireless Networks," Wireless Networks, Kluwer Academic Publishers, Netherlands. vol. 10, pp. 495–506, 2004. [84] Y. Wang, N. Yan and T. Li," Throughput Analysis of IEEE 802.11 in Multi-Hop Ad Hoc Networks", International Conference on Wireless Communications, Networking and Mobile Computing (WiCOM), pp. 1-4, 22-24 Sept. 2006. [85] H. Takagi and L. Kleinrock, "Optimal transmission range for randomly distributed packet radio terminals", IEEE Transactions on Communications, vol. 32, no. 3, pp. 246–257, 1984. [86] N. Nandiraju, K. Chowdhury, D. P. Agrawal, "Investigation of MAC and Network layer Fairness for Multihop Wireless Ad-Hoc Networks,” Published in OPNETWORK 2005, Washington, August 21-27, 2005. [87] H. Zhai, and U. Fang," Distributed Flow Control and Medium Access in Multi-hop Ad Hoc Networks", IEEE Transactions on Mobile Computing, vol. 5, no. 11, pp. 1503-1514, Nov. 2006.
[88] J. Li, C. Blake, D. Couto, H. Lee and R. Morris, "Capacity of ad hoc wireless network" Proceedings of the 7th annual international conference on Mobile computing and networking (Mobicom), July 2001. [89] Matlab software, version 7.11.0.584 (R2010b). Available on: http://www.mathworks.com/products/simevents
[90] D. Kliazovich and F. Granelli," Cross-layer congestion control in ad hoc wireless networks", Elsevier B. V., Ad Hoc Networks Journal, vol. 4, no. 6, pp. 687–708, 2006.
(239)
[91] Y. Cheng, Y. Lee and S. Sheu," Multi-Rate Transmissions in Infrastructure Wireless LAN Based on IEEE 802.11b Protocol", IEEE pp. 2609-2612, 2001. [92] Felicia Brych," Wireless Local Area Networks and the 802.11 Standard", Ph.D. thesis, Plamen Nedeltchev, March 31, 2001. [93] www.opnet.com [94] CommView 6.1 software. Available on: http://software-files-l.cnet.com/s/software/
[95] Wireshark program. Available on: http://www.wireshark.org/download/win32/wireshark-win32-1.5.1.exe
(240)
Appendix (A) 1. Route Request (RREQ) message: The format of the route request message is shown in Figure (A.1).
Type (8-bit)
Reserved (16-bit)
Hop count (8-bit)
Broadcast ID (32-bit) Destination IP address (32-bit) Destination sequence number (32-bit) Source IP address (32-bit) Source sequence number (32-bit) Figure (A.1): Route request message format. Type: Type of message. Reserved: Reserved for future use. Currently sent as 0 and ignored on reception. Hop count: Number of hops from the source IP address to the node handling the request. Broadcast ID: A sequence number identifying the particular the number request uniquely when taken conjunction with the source nodes address. Destination IP address: IP address of the destination for which a route is required. Destination sequence number: The last sequence number received in the past by the source for a route towards the destination.
(A-1)
Source IP address: IP address of the node that originated the request. Source sequence number: Current sequence number for route information generated by the source the route request. 2. Route Reply (RREP) message: The format of the route request message is shown in Figure (A.2).
Type (8-bit)
L
Reserved (15-bit)
Hop count (8-bit)
Destination IP address (32-bit) Destination sequence number (32-bit) Life time (32-bit) Figure (A.2): Route reply message format. L: If the L-bit is set the message is a hello message and contain a list of the nodes neighbors. Life time: time for which nodes receiving the Reply consider the route to be valid. 3. Hello messages: They are a special case Route reply messages. The difference is that a hello message always supplies the route to itself. This means that the hop count field is set to 0, the destination address set to the node IP address and the destination sequence number set to the nodes latest sequence number. 4. Link failure messages: They are also a special case Route reply messages, but in this case, the destination reflects the route that has broken. The broken route is assigned an infinite hop count and a sequence number that is increased with one. (A-2)
Appendix (B) 1- Attribute Function block of TCC algorithm (Ch4-p113): function [out_CDHT,out_ACDHO1,out_R,out_CPRTTO,out_RTTO, out_ACDH, out_ACDHO,out_DeltaC,out_DeltaT] = fcn (M,R,CDT, N,CPRTT,RTT,ACDHO, CPRTTO, RTTO,CDHT,ACDHO1) if (M == 1) R = R + 1; else end for I = 1 : N-1 CD = rand(1) * 0.01; CDT = CDT + CD; end CDH = CDT/(N-1); CDHT = CDHT+CDH; if M == 1 ACDH = CDHT/CPRTT; else ACDH = ((CDHT/CPRTT)+ACDHO)/2; end DeltaC = 0; DeltaT = 0; if (M == CPRTT)&&(R == 1) ACDHO1 = ACDH; elseif (M == CPRTT)&&(R > 1) DeltaC = ACDH/ACDHO1; ACDHO1 = ACDH; else DeltaC = 0; end if (R > M)&&(M == 1) DeltaT = (CPRTT*RTTO)/(CPRTTO*RTT); end if M == CPRTT ACDH = 0; else end RTTO = RTT; out_ACDHO1 = ACDHO1; out_DeltaC = DeltaC; out_CDHT = CDHT; out_R = R; out_ACDH = ACDH; out_CPRTTO = CPRTT; out_RTTO = RTTO; out_ACDHO = ACDHO; out_DeltaT = DeltaT; end
(B-1)
2- Channel1/Contention (single-hop) (Ch5-p127): function [out_S1,out_coll,out_slot] = fcn(CH,N,b1,b2) c1 = ceil(b1); b1 = c1; c2 = ceil(b2); b2 = c2; coll=0; if (CH==1) if (b1b2) S=CH+1; out_S1=S; out_slot=b2 * 2e-5; else S=0; coll=coll+1; out_S1=S; out_slot=32 * 2e-5; end elseif (CH>1)&& (CH
