Multicasting in Mobile Ad Hoc Networks Ravindra Vaishampayan Department of Computer Science...

Multicasting in Mobile Ad Hoc Networks

Ravindra VaishampayanDepartment of Computer Science

University of CaliforniaSanta Cruz, CA 95064, U.S.A.

Advisor: Prof. J. J. Garcia-Luna-Aceves

Dissertation Proposal

2

Presentation Outline

● Background and Design Challenges● Previous Work● Our Contribution

3

Mobile Ad Hoc NetworksMobile Ad Hoc Networks

● Formed on-demand without pre-existing infrastructure

● Multiple Wireless Hops

4

Mobile Ad Hoc NetworksMobile Ad Hoc Networks

● Mobility results in topology and route changes

• Applications: Disaster relief, Battlefield, Policing, Search and Rescue etc.

5

Multicasting

● One to many communication : Multiple Unicasting

S1

R1

R2 R3

CBA

JFE

IH

D

G

LK

6

Multicasting


S1

R1

R2 R3

CBA

FE

IH

D

G

J

LK

7

Multicasting


S1

R1

R2 R3

CBA

FE

IH

D

G

J

LK

8

Multicasting


S1

R1

R2 R3

CBA

FE

IH

D

G

J

LK

9

Multicasting


S1

R1

R2 R3

CBA

FE

IH

D

G

J

LK

10

Multicasting


S1

R1

R2 R3

CBA

FE

IH

D

G

J

LK

11

Multicasting


S1

R1

R2 R3

CBA

FE

IH

D

G

J

LK

12

Multicasting


S1

R1

R2 R3

CBA

FE

IH

D

G

Needs 8 Transmissions !

J

LK

13

Multicasting

● One to many communication : Multicasting

S1

R1

R2 R3

CBA

FE

IH

D

G

J

LK

14

Multicasting


S1

R1

R2 R3

CBA

FE

IH

D

G

J

LK

15

Multicasting


S1

R1

R2 R3

CBA

FE

IH

D

G

Needs just 3 Transmissions !

J

LK

16

Multicasting in Ad Hoc Networks

● Ad Hoc Networks cannot afford multiple unicasting as bandwidth is limited

● Most applications of ad hoc networks e.g. battlefield scenarios, search and rescue operations involve one to many communication

● Compared to multicasting in wired networks need to handle low link reliability, mobility, low battery life

● Can be classified as tree based or mesh based protocols

17

Tree Based Multicasting

R2R1 R3A

C

B

D E F G

H KI S1 L

R3 ONR4P

QTS

R5

U

18


R2R1 R3A

C

B

D E F G

H KI S1 L

R3 ONR4P

QTS

R5

U

19


R2R1 R3A

C

B

D E F G

H KI S1 L

R3 ONR4P

QTS

R5

U

20


R2R1 R3A

C

B

D E F G

H KI S1 L

R3 ONR4P

QTS

R5

U

● Packets flow from sender to receiver along a single path.● Exact shape of tree depends on protocol. E.g. shared vs source based

21

Mesh Based Multicasting

R2R1 R3A

C

B

D E F G

H KI S1 L

R3 ONR4P

QTS

R5

U

● Packets flow from sender to receiver along multiple paths. ● Due to multiple paths meshes are more tolerant of link breaks● Higher packet delivery ratio but also higher overhead.● Redundancy in mesh depends on protocol e.g. sender initiated vs receiver initiated.

22

Design Challenges

● Protocol should handle mobility well● Should have a low overhead because:

● Bandwidth is limited● Overhead is related to battery power, also limited

● The above two objectives are often contradictory

Previous Work

ODMRP Per sender control flood Sender initiated mesh construction may lead

to wasteful transmissions

MAODV Three step process for fixing links takes too

long and adds to much overhead

On Demand Multicast Routing Protocol (ODMRP)

S1

R2

N1 S2N2 N3

N7N5 N6N4

N10R3N9

N12

R1

N8

N16N15N14

N17

N13

N11

S3N19N18

● Mesh Based Routing Protocol


S1

R2

N1 S2N2 N3

N7N5 N6N4

N10R3N9

N12

R1

N8

N16N15N14

N17

N13

N11

S3N19N18


● Assume S1, S2, S3 are senders


S1

R2

N1 S2N2 N3

N7N5 N6N4

N10R3N9

N12

R1

N8

N16N15N14

N17

N13

N11

S3N19N18

● Mesh Based Routing Protocol● Assume S1, S2, S3 are senders● Assume R1, R2, R3 are receivers


S1

R2

N1 S2N2 N3

N7N5 N6N4

N10R3N9

N12

R1

N8

N16N15N14

N17

N13

N11

S3N19N18

● Mesh Based Routing Protocol● Assume S1, S2, S3 are senders● Assume R1, R2, R3 are receivers● Each sender floods JOIN Requests which set up a reverse path from each sender to each receiver.


S1

R2

N1 S2N2 N3

N7N5 N6N4

N10R3N9

N12

R1

N8

N16N15N14

N17

N13

N11

S3N19N18

● Mesh Based Routing Protocol● Assume S1, S2, S3 are senders● Assume R1, R2, R3 are receivers● Each sender floods JOIN Requests which set up a reverse path from each sender to each receiver. ● Receivers send out JOIN Tables along the reverse path to each sender.


S1

R2

N1 S2N2 N3

N7N5 N6N4

N10R3N9

N12

R1

N8

N16N15N14

N17

N13

N11

S3N19N18

● Mesh Based Routing Protocol● Assume S1, S2, S3 are senders● Assume R1, R2, R3 are receivers● Each sender floods JOIN Requests which set up a reverse path from each sender to each receiver. ● Receivers send out JOIN Tables along the reverse path to each sender.● Each node on a reverse path from sender to receiver defines the mesh


S1

R2

N1 S2N2 N3

N7N5 N6N4

N10R3N9

N12

R1

N8

N16N15N14

N17

N13

N11

S3N19N18

Drawbacks● Per-source flooding leads to significant overhead


S1

R2

N1 S2N2 N3

N7N5 N6N4

N10R3N9

N12

R1

N8

N16N15N14

N17

N13

N11

S3N19N18

Drawbacks● Per-source flooding leads to significant overhead● Sender-initiated mesh results in large number of wasted transmissions e.g. Nodes N4-N8 and N12 transmitting packets from S3wasteful (Only provide connectivity to S1 and S2)

Multicast Ad hoc On demand Distance Vector (MAODV)

S1

R2

N1 S2N2 N3

N7N5 N6N4

N10R3N9

N12

R1

N8

N16N15N14

N17

N13

N11

S3N19N18

● Tree Based Routing Protocol


S1

R2

N1 S2N2 N3

N7N5 N6N4

N10R3N9

N12

R1

N8

N16N15N14

N17

N13

N11

S3N19N18

● Tree Based Routing Protocol● Assume S1, S2, S3 are senders


S1

R2

N1 S2N2 N3

N7N5 N6N4

N10R3N9

N12

R1

N8

N16N15N14

N17

N13

N11

S3N19N18

● Tree Based Routing Protocol● Assume S1, S2, S3 are senders● First receiver joining the group becomes Group Leader, periodically broadcasting group-hello packets.

Group Leader


S1

R2

N1 S2N2 N3

N7N5 N6N4

N10R3N9

N12

R1

N8

N16N15N14

N17

N13

N11

S3N19N18

● Tree Based Routing Protocol● Assume S1, S2, S3 are senders● First receiver joining the group becomes Group Leader, periodically

broadcasting group-hello packets.● Additional receivers Join the tree based on a three step process : 1) RREQ 2) RREP 3) MACT

Group Leader


S1

R2

N1 S2N2 N3

N7N5 N6N4

N10R3N9

N12

R1

N8

N16N15N14

N17

N13

N11

S3N19N18

● Tree Based Routing Protocol● Assume S1, S2, S3 are senders● First receiver joining the group becomes Group Leader, periodically broadcasting group-hello packets. ● Additional receivers Join the tree based on a three step process : 1) RREQ 2) RREP 3) MACT● Senders also acquire routes to the tree using 1) RREQ 2) RREP 3) MACT ● Data packets are forwarded over activated links.

Group Leader


S1

R2

N1 S2N2 N3

N7N5 N6N4

N10R3N9

N12

R1

N8

N16N15N14

N17

N13

N11

S3N19N18

Drawbacks● Link Establishment / Link maintenance takes too long due to 3 steps, and has high overhead, leading to low PDR

Group Leader

Our Contribution ROMANT : First tree based protocol to give PDR comparable to mesh based protocols.

PUMA : Mesh based protocol with virtually fixed control overhead and high PDR

Adaptive Mesh Based Multicast : Best of both worlds

MODA : First protocol using DA’s increases transmission range for same energy consumption, reducing overhead.

CLAMMP : First protocol to reduce interference by distributed channel scheduling so that communicating nodes are on the same channel and non-communicating nodes are on different channels.

RObust Multicasting in Ad hoc Networks using Trees (ROMANT)

S1

R2

N1 S2N2 N3

N7N5 N6N4

N10R3N9

N12

R1

N8

N16N15N14

N17

N13

N11

S3N19N18

● Tree Based Routing Protocol


S1

R2

N1 S2N2 N3

N7N5 N6N4

N10R3N9

N12

R1

N8

N16N15N14

N17

N13

N11

S3N19N18

● Tree Based Routing Protocol● Assume S1, S2, S3 are senders


S1

R2

N1 S2N2 N3

N7N5 N6N4

N10R3N9

N12

R1

N8

N16N15N14

N17

N13

N11

S3N19N18

● Tree Based Routing Protocol● Assume S1, S2, S3 are senders● Like MAODV the first receiver joining the group is elected CORE of the group (highest ID wins if multiple join together)

Core


S1

R2

N1 S2N2 N3

N7N5 N6N4

N10R3N9

N12

R1

N8

N16N15N14

N17

N13

N11

S3N19N18

● Tree Based Routing Protocol● Assume S1, S2, S3 are senders● Like MAODV the first receiver joining the group is elected core of the group (highest ID wins if multiple join together)● Core periodically broadcasts a core announcement consisting of the following fields :

● Core ID● Distance To Core = 0● Group ID● Sequence Number

Core


S1

R2

N1 S2N2 N3

N7N5 N6N4

N10R3N9

N12

R1

N8

N16N15N14

N17

N13

N11

S3N19N18

● Intermediate nodes forward fresh core announcements (based on seq number) after incrementing distance to core by 1● Core announcements allow each node to learn its distance to core and next hop towards core (Node reporting lowest distance to core)

Core

2,N5

2,N5

2,N9

2,N13

2,N13 2,N13 2,N14 2,N15 2,N15

2,N15

2,N10

2,N7

2,N5 2,N6 2,N7 2,N7

1,R3

1,R31,R31,R3

1,R3

1,R3 1 1,R3


S1

R2

N1 S2N2 N3

N7N5 N6N4

N10R3N9

N12

R1

N8

N16N15N14

N17

N13

N11

S3N19N18

● Intermediate nodes forward fresh core announcements (based on seq number) after incrementing distance to core by 1● Core announcements allow each node to learn its distance to core and next hop towards core (Node reporting lowest distance to core)● Receivers send join announcements address of group and address of next-hop● Nodes receiving join announcements with their address as next-hop become tree members and also forward join announcements.

Core

2,N5

2,N5

2,N9

2,N13

2,N13 2,N13 2,N14 2,N15 2,N15

2,N15

2,N10

2,N7

2,N5 2,N6 2,N7 2,N7

1,R3

1,R31,R31,R3

1,R3

1,R3 1 1,R3


S1

R2

N1 S2N2 N3

N7N5 N6N4

N10R3N9

N12

R1

N8

N16N15N14

N17

N13

N11

S3N19N18

● Senders send data packets towards next-hops ● Once data packets reach tree members they are flooded within the tree with a Packet ID cache used to drop duplicates.

Core

2,N5

2,N5

2,N9

2,N13

2,N13 2,N13 2,N14 2,N15 2,N15

2,N15

2,N10

2,N7

2,N5 2,N6 2,N7 2,N7

1,R3

1,R31,R31,R3

1,R3

1,R3 1 1,R3


S1

R2

N1 S2N2 N3

N7N5 N6N4

N10R3N9

N12

R1

N8

N16N15N14

N17

N13

N11

S3N19N18

● Senders send data packets towards next-hops ● Once data packets reach tree members they are flooded within the tree with a Packet ID cache used to drop duplicates. ● Does not require 3 step route discovery as nodes already have next-hop information

Core

2,N5

2,N5

2,N9

2,N13

2,N13 2,N13 2,N14 2,N15 2,N15

2,N15

2,N10

2,N7

2,N5 2,N6 2,N7 2,N7

1,R3

1,R31,R31,R3

1,R3

1,R3 1 1,R3


S1

R2

N1 S2N2 N3

N7N5 N6N4

N10R3N9

N12

R1

N8

N16N15N14

N17

N13

N11

S3N19N18

● Senders send data packets towards next-hops ● Once data packets reach tree members they are flooded within the tree with a Packet ID cache used to drop duplicates. ● Does not require 3 step route discovery as nodes already have next-hop information● Fixing link breaks is quick e.g. if S2-N7 is broken S2 can send to N6, without a 3 step route discovery.

Core

2,N5

2,N5

2,N9

2,N13

2,N13 2,N13 2,N14 2,N15 2,N15

2,N15

2,N10

2,N7

2,N5 2,N6 2,N7 2,N7

1,R3

1,R31,R31,R3

1,R3

1,R3 1 1,R3

ROMANT Simulation Environment

• Ex-1 : Mobility varied 0 – 20 m/s

• Ex-2 : Senders varied from 1-20

• Ex-3 : Receivers varied from 5-40

• Ex-4 : Traffic Load varied from 1-50 pkt/sec

Packet Delivery Ratio

Exp ROMANT ODMRP MAODV

Mobility

0.977±0.009 0.975±0.008 0.792±0.282

Sender 0.993±0.003 0.872±0.133 0.997±0.001

Receiver

0.979±0.004 0.978±0.011 0.870±0.271

Traffic- Load

0.917±0.157 0.886±0.167 0.785±0.352

Control Overhead per node


Mobility 335.4±8.9 1813.8 ±40.0 5003.7 ±6544.8

Sender 333.5 ±0.6 2809 ±3006 252.1 ±8.0

Receiver 410.6 ±85.7

1879.5 ±921.0

3425.0 ±7098.5

Traffic- Load

326.6 ±14.6

1798.3 ±460.3

4098.5 ±6500.9

Total Overhead per node


Mobility

1297.9±125.1

4088.7±131.1 6521.6±6083

Senders 1128.5±12.2 4615.1±3574.6

2010.0±29.4

Receiver

1168.9±263.8

3975.0±1325.9

4806.5±6987.1

Traffic- Load

1558.9±1231.0

4470.5±2924.8

5293.2±6985.5

ROMANT : Publications

• R. Vaishampayan and J.J. Garcia-Luna-Aceves, "Robust Tree-based Multicasting in Ad-hoc Networks(ROMANT)", Workshop on Multihop Wireless Networks, 23 rd IEEE. International Performance Computing and Communications Conference, Phoenix, Arizona, April 14-17, 2004.

• R. Vaishampayan and J.J. Garcia-Luna-Aceves, "Robust multicasting in ad hoc networks using trees", International

Journal on Wireless and Mobile Computing(IJWMC)

Protocol for Unified Multicasting through Announcements (PUMA)

S1

R2

N1 S2N2 N3

N7N5 N6N4

N10R3N9

N12

R1

N8

N16N15N14

N17

N13

N11

S3N19N18



S1

R2

N1 S2N2 N3

N7N5 N6N4

N10R3N9

N12

R1

N8

N16N15N14

N17

N13

N11

S3N19N18

● Mesh Based Routing Protocol● Assume S1, S2, S3 are senders


S1

R2

N1 S2N2 N3

N7N5 N6N4

N10R3N9

N12

R1

N8

N16N15N14

N17

N13

N11

S3N19N18

● Mesh Based Routing Protocol● Assume S1, S2, S3 are senders● Assume R1, R2, R3 are receivers and R3 is elected as core similar to ROMANT● Cores in PUMA transmit a multicast announcement as opposed to a core announcement in ROMANT● Multicast announcements have an additional field called mesh member flag

Core

S1

R2

N1 S2N2 N3

N7N5 N6N4

N10R3N9

N12

R1

N8

N16N15N14

N17

N13

N11

S3N19N18

● Receivers set mesh member flag to TRUE by default● If a node has a neighbour which has member flag set and distance to core less than its own, then it considers itself a mesh member and sets mesh member flag to TRUE in its own multicast announcement. ● PUMA does not need a separate join announcement as in ROMANT. ● PUMA includes all shortest paths between each receiver and the core.

Core

2

2

2

2

2 2 2 2 2

2

2

2

2 2 2 2

1

111

1

1 1 1


S1

R2

N1 S2N2 N3

N7N5 N6N4

N10R3N9

N12

R1

N8

N16N15N14

N17

N13

N11

S3N19N18

● Data packets are sent towards the next-hops and flooded within the mesh as soon as they reach the first mesh member (Similar to ROMANT)

Core

2

2

2

2

2 2 2 2 2

2

2

2

2 2 2 2

1

111

1

1 1 1


S1

R2

N1 S2N2 N3

N7N5 N6N4

N10R3N9

N12

R1

N8

N16N15N14

N17

N13

N11

S3N19N18

PUMA vs ODMRP● Has only one flooding by the core, as opposed to ODMRP which has per source flooding● Restricts redundancy where receivers exist thus reducing wasteful transmissions. Core

2

2

2

2

2 2 2 2 2

2

2

2

2 2 2 2

1

111

1

1 1 1


Simulation Scenarios

• Simulation environment same as ROMANT.

• Experiments : Same as ROMANT + one where Multicast Groups varied from 1-10

Control Overhead per node

Exp PUMA ODMRP MAODV

Mobility 255.6±9.2 1813.8 ±40.0 5003.7 ±6544.8

Sender 253.6 ±0.4 2809 ±3006 252.1 ±8.0

Receiver 250.6 ±4.4 1879.5 ±921.0

3425.0 ±7098.5

Traffic- Load

246.6 ±12.2

1798.3 ±460.3

4098.5 ±6500.9

Groups 250.4 ±8.4 2062 ±1488 3237.9 ±5696.4



Mobility

0.984±0.008 0.975±0.008 0.792±0.282

Sender 0.988±0.002 0.872±0.133 0.997±0.001

Receiver

0.986±0.006 0.978±0.011 0.870±0.271

Traffic- Load

0.917±0.142 0.886±0.167 0.785±0.352

Groups 0.884±0.015 0.605±0.241 0.131±0.122

Total Overhead per node


Mobility

2732.7±18.5 4088.7±131.1 6521.6±6083

Senders 2718.9±12.8 4615.1±3574.6

2010.0±29.4

Receiver

2518±799 3975.0±1325.9

4806.5±6987.1

Traffic- Load

3260.2±3257

4470.5±2924.8

5293.2±6985.5

Groups 5594±416.0 9336±2794.0 28542±7328.1

PUMA : Publications

R. Vaishampayan and J.J. Garcia-Luna-Aceves, "Protocol for Unified Multicasting through Announcements(PUMA)", 1st IEEE International Conference on Mobile Ad-hoc and Sensor Systems (MASS), Fort Lauderdale, Florida, October 24-27, 2004.

R. Vaishampayan and J.J. Garcia-Luna-Aceves, "Protocol for Unified Multicasting through Announcements(PUMA)", IEEE/ACM Transactions on Networking (Under review)

Motivation for Adaptive Protocols

Mesh based protocols have higher overhead due to redundancy of path

Traditionally Mesh based protocols had significantly higher PDR

However ROMANT which is able to fix broken links quickly is provides comparable PDR to mesh based protocols, except for high mobility

We need a protocol which can adapt redundancy depending on network conditions.

Adaptive Mesh Based Multicast

1

2 3 4

56

7

8

9 10

11 12

1314

15

16

17

18

20

19

● Adaptive Protocol which adapts redundancy in mesh depending on network conditions

21


1

2 3 4

56

7

8

9 10

11 12

1314

15

16

17

18

20

19

● Adaptive Protocol which adapts redundancy in mesh depending on network conditions● Assume nodes 1, 8, 16, 17, 19, 20 are receivers, and node 8 is elected the core as in PUMA● The core in “Adaptive” sends out multicast announcements like in PUMA● In addition to the fields in PUMA multicast announcement has a field called parent

21

Core


1

2 3 4

56

7

8

9 10

11 12

1314

15

16

17

18

20

19

● Setting the parent field appropriately allows nodes to control the redundancy in the mesh● Nodes become “mesh members” if they have a neighbour who has a) Mesh member flag set b) greater distance to core c) Parent field less than equal to node’s own ID● Parent field determines number of parents included in mesh, hence mesh redundancy. ● E.g. Node 18 sets the parent field to 12, including parents 12, 14 but not 10

21

Core

4

88

15

8

88

6

15

12

12

13

13

11


1

2 3 4

56

7

8

9 10

11 12

1314

15

16

17

18

20

19

● Mesh Reliability Index● MRI = % of implicit acks received● If MRI < 0.92 then noOfParents++● If MRI > 0.95 then noOfParents--● 1<= noOfParents <= 321

Core

4

88

15

8

88

6

15

12

12

13

13

11

Adaptive Mesh Based Multicast● Simulation environment : Same as ROMANT and PUMA

Experiments : • Ex-1 : Mobility varied 0 – 200 m/s• Ex-2 : Senders varied from 1-20 • Ex-3 : Receivers varied from 5-40 • Ex-4 : Traffic Load varied from 1-50 pkt/sec• Ex-5 : Multicast Groups varied from 1-10• Ex-6 : Terrain Size varied from 800m X 800m to 1600m X 1600m.• Ex-7 : Same as Ex-1 except receivers 5 instead of 20• Ex-8 : Same as Ex-1 except receivers 10 instead of 20• Ex-9 : Same as Ex-1 except traffic load = 25 pkt/sec instead of 10 pkt/sec• Ex-10 : Same as Ex-1 except traffic load = 50 pkt/sec instead of 10 pkt/sec• Ex-11 : Same as Ex-1 except terrain-size = 1442m X 1442 m instead of 1000m X 1000m


Protocol Packet Delivery Ratio

Standard Deviation

Adaptive

0.83 0.15

V_1 0.78 0.16

V_All (PUMA)

0.86 0.15

ODMRP

0.82 0.18

Average Packets Txed

Protocol Average Packets Txed Per Node Per Experiment

Adaptive

3878.77

V_1 2683.66

V_All (PUMA)

6030.30

ODMRP

9263.47

Adaptive Mesh Based Multicast : Publications

R. Vaishampayan, J.J. Garcia-Luna-Aceves and Katia Obraczka, "An Adaptive Redundancy Protocol for Mesh Based Multicasting", 2005 International Symposium on Performance Evaluation of Computer and Telecommunication Systems (SPECTS '05).

R. Vaishampayan, J.J. Garcia-Luna-Aceves and Katia Obraczka, "Redundancy adaptation based on link reliability in Mesh Based Multicasting", Computer Communications Journal.

Multicasting Over Directional Antennas (MODA)

MOTIVATION ● Principal overhead in state of the art protocols is data packet overhead (DPO)● DPO can be reduced by transmitting packets over longer distances without increasing energy consumption using directional antennas’s (DA’s)


MOTIVATION ● Principal overhead in state of the art protocols is data packet overhead (DPO)● DPO can be reduced by transmitting packets over longer distances without increasing energy consumption using directional antennas’s (DA’s)● Assume Node 7 is a sender and nodes 10, 1, 2, 3, 16 are receivers. ● Omnidirectional transmission will require 15 transmissions !

1

9

8

7

5 6

43

2

10

11

14

12

13

15 16


MOTIVATION ● Principal overhead in state of the art protocols is data packet overhead (DPO)● DPO can be reduced by transmitting packets over longer distances without increasing energy consumption using directional antennas’s (DA’s)● Assume Node 7 is a sender and nodes 10, 1, 2, 3, 16 are receivers. ● Omnidirectional transmission will require 15 transmissions !● Directional transmission will need only 3 transmissions !

1

9

8

7

5 6

43

2

10

11

14

12

13

15 16


CHALLENGES ● The main challenge is the exchange of location information so that nodes know in what direction to beam-form their antennas. ● To do the above without incurring too much overhead.

1

9

8

7

5 6

43

2

10

11

14

12

13

15 16


● Involves two major steps a) omnidirectional tree construction and b) directional forwarding of data packets

1

23

4

6

5

107

89 11 12

1314 15

16

1917

18

20 21

22



OMNIDIRECTION TREE construction● Assume nodes 9, 17, 22, 21, 12, 16, 1, 2 are receivers and node 6 is a sender

1

23

4

6

5

107

89 11 12

1314 15

16

1917

18

20 21

22



OMNIDIRECTION TREE construction● Assume nodes 9, 17, 22, 21, 12, 16, 1, 2 are receivers and node 6 is a sender● Core election similar to PUMA except receiver closest to centre of network elected as core, node 9 is elected as core● Logically a tree is formed as every node chooses a parent and broadcasts it in the “parent” field of multicast announcement.

1

23

4

6

5

107

89 11 12

1314 15

16

1917

18

20 21

22


● In addition to fields in a PUMA multicast announcement MODA also includes list of children, and locations of the node, its children and parent.

● Hence all nodes in PUMA have location info about their grandparents as well as grandchildren

1

23

4

6

5

107

89 11 12

1314 15

16

1917

18

20 21

22


Directional Data Packet Forwarding • The main idea is that nodes transmit two hops instead of one whenever possible• Nodes also do not retransmit if they realize that the packet has already reached the destination.

1

23

4

6

5

107

89 11 12

1314 15

16

1917

18

20 21

22


Directional Data Packet Forwarding • The main idea is that nodes transmit two hops instead of one whenever possible• Nodes also do not retransmit if they realize that the packet has already reached the destination.• Node 8 does not retransmit as node 9 has already been reached.

1

23

4

6

5

107

89 11 12

1314 15

16

1917

18

20 21

22


Directional Data Packet Forwarding• The main idea is that nodes transmit two hops instead of one whenever possible• Nodes also do not retransmit if they realize that the packet has already reached the destination.• Node 3 does not retransmit as node 1 has already been reached.

1

23

4

6

5

107

89 11 12

1314 15

16

1917

18

20 21

22


Directional Data Packet Forwarding• The main idea is that nodes transmit two hops instead of one whenever possible• Nodes also do not retransmit if they realize that the packet has already reached the destination.• Node 11, 15 do not retransmit as nodes 12, 16 have already been reached.

1

23

4

6

5

107

89 11 12

1314 15

16

1917

18

20 21

22


Directional Data Packet Forwarding •The main idea is that nodes transmit two hops instead of one whenever possible• Nodes also do not retransmit if they realize that the packet has already reached the destination.• Node 17 does have to retransmit the packet because nodes 21 and 22, have not yet received the packet.

1

23

4

6

5

107

89 11 12

1314 15

16

1917

18

20 21

22


Directional Data Packet Forwarding• The main idea is that nodes transmit two hops instead of one whenever possible• Nodes also do not retransmit if they realize that the packet has already reached the destination.• Node 20 does have to retransmit the packet because nodes 22 has already received it.

1

23

4

6

5

107

89 11 12

1314 15

16

1917

18

20 21

22

MODA Performance Evaluation

Simulation Environment• Same as ROMANT and PUMA (Omndirectional settings)• Directional transmission performed with same energy level of omnidirectional transmission. • Beamforming Angle : 45 degrees.• Directional range : 2.45 x Omnidirectional RangeExperiments• Ex-1 : Mobility varied 0 – 20 m/s• Ex-2 : Senders varied from 1-20 • Ex-3 : Receivers varied from 5-40 • Ex-4 : Traffic Load varied from 1-50 pkt/sec• Ex-5 : Multicast Groups varied from 1-10.

MODA Performance Evaluation

Pkt Delivery Ratio

Total

Packets

Txed

Data Packets Txed

Control Packets Txed

MODA 0.88 ± 0.08

81191 ± 49708

66262 ± 49610

14928 ± 4438

PUMA(tree-mode)

0.90 ± 0.08

119591 ± 74714

106770 ± 74627

12820 ± 637

ODMRP

0.87±

0.18

510246 ± 296635

233690 ± 131442

276555 ± 252414

MODA Publications

R. Vaishampayan, J.J. Garcia-Luna-Aceves and Katia Obraczka, "Multicasting Over Directional Antennas(MODA)", 2nd IEEE International Conference on Mobile Ad-hoc and Sensor Systems (MASS 2005).

Cross Layer Ad hoc Multiple channel Multicasting Protocol (CLAMMP)

Motivation• Capacity improvement is important in MANET’s due to limited bandwidth. • 802.11a offers 13 orthogonal channels• Communication can occur simultaneously if communication occurs on orthogonal channels


Motivation• Capacity improvement is important in MANET’s due to limited bandwidth. • 802.11a offers 13 orthogonal channels• Communication can occur simultaneously if communication occurs on orthogonal channels• Assume nodes 1-11 are portions of three independent multicast trees, and are all in each others range• If all three trees operate on orthogonal channels then simultaneous data transmission is possible on all trees.

2

10

8

765

4

3

9

1

11


Design Challenges• Nodes interested in exchanging data should be on the same channel most of the time. • Nodes not exchanging data should be on different channels most of the time• Synchronization algorithm should be efficient (in terms of time as well as bandwidth)• Should adapt quickly to changes in traffic patterns (due to mobility and joining/leaving groups).


Design Challenges• Nodes interested in exchanging data should be on the same channel most of the time. • Nodes not exchanging data should be on different channels most of the time• Synchronization algorithm should be efficient (in terms of time as well as bandwidth)• Should adapt quickly to changes in traffic patterns (due to mobility and joining/leaving groups).• Reduce shared nodes as they reduce total capacity (Node 5 cannot be on different channels at the same time)

10

54

3

91


• Two layer protocol composed of CLAMMP-Routing / CLAMMP MAC.

C LAMMP-Routing• Tree based protocol based on PUMA• Builds trees so as to minimize number of shared nodes across multicast trees. • Forwards/receives data/control packets to/from CLAMMP-MAC

CLAMMP-Routing

CLAMMP-MAC

Transport Layer

Physical layer


C LAMMP-MAC• Time is split into equal size chunks called “slots”• Nodes have a channel-hopping schedule across slots. • Nodes try to match channel-hopping schedule with nodes they want to exchange data.


C LAMMP-MAC• Time is split into equal size chunks called “slots”• Nodes have a channel-hopping schedule across slots. • Nodes try to match channel-hopping schedule with nodes they want to exchange data. • Let no. of orthogonal channels = n, numbered 0 … n-1. • Channel hopping schedules are represented by a (channel, seed) pair. • new channel = (old channel + seed) mod n



• E.g. n = 13, channel seed pair = (8, 4)• Overall schedule is represented by 4 channel seed pairs.



• E.g. n = 13, channel seed pair = (8, 4)• Overall schedule is generally represented by 4 channel seed pairs.

• Schedule 1 : (8, 4) = 8,12,3,7,11,2,6,10,1,5,9,0,4,8 ….

• Schedule 2 : (9, 7) = 9,3,10,4,11,5,12,6,0,7,1,8,2,9 …

• Schedule 3 : (3,10) = 3,0,10,7,4,1,11,8,5,2,12,9,6,3 …• Schedule 4 : (4, 6) = 4,10,3,9,2,8,1,7,0,6,12,5,11,4 …• Overall schedule = 8, 9, 3, 4, 12, 3, 0, 10, 3, 10, 10, 3, 7, 4, 7, 9, 11, 11, 4, 2 …


Channel seed pair properties• If the channel, seed pair is the same the schedule is always the same• If channel, seed pairs are different then they share a channel once in an iteration. •


Channel seed pair properties• If the channel, seed pair is the same the schedule is always the same• If channel, seed pairs are different then they share a channel once in an iteration. Channel seed pair selection• Core’s randomly select 4 channel, seed pairs• As far as possible select nodes select same channel seed pairs as parents. •


Channel seed pair properties• If the channel, seed pair is the same the schedule is always the same.• If channel, seed pairs are different then they share a channel once in an iteration. Channel seed pair selection• Core’s randomly select 4 channel, seed pairs• As far as possible select nodes select same channel seed pairs as parents. • Nodes 1, 3, 4, 5 are always on the same channel, and nodes 2, 6, 7, 8 are always on the same channel. • Nodes 5, 6 are on the same channel once in 13 slots (enough for exchanging multicast announcements)

2

8

765

4

3

1


Shared Nodes• CLAMMP-Routing tries to minimize the number of nodes which are part of multiple multicast trees e.g. node 5• However when such nodes exist they partially synchronize with each parent• Nodes like node 5 are throughput bottlenecks as their throughputs are split between multiple groups.

10

54

3

91

[ A B C D ]

[ A B C D ]

[ A B C D ]

[A F C H]

[ E F G H ]

[ E F G H ]


Desynchronization• Different stores randomly choosing the same channel seed pair on a particular SLOT, though rare is possible. • Nodes detecting the same channel, seed pair pick a new one and broadcast it to the entire tree. (If a pair of nodes detect a collision on an even slot then the lower ID desynchronizes, otherwise the higher ID desynchronizes). • Nodes 5 and 6 detect collisions on SLOT’s 2 and 3. • 5 picks a new channel seed pair for position 2, and 6 picks a new channel seed pair for position 3, which is broadcast in their respective trees.

105

4

3

91

[ A B C D ]

[ A B C D ]

[ A B C D ]

6

[ E B C H ]

[ A B C D ]

[ E B C H ]

[ E B C H ][ A X C D ]

[ A X C D ]

[ A X C D ]

[ A X C D ][ E B Y H ]

[ E B Y H ]

[ E B Y H ]

CLAMMP – Simulation Environment

CLAMMP – ExperimentsEx-1 : Multicast groups varied from 1 – 20.Ex-2 : Nodes varied from 50-200. (20 groups)Ex-3 : Receivers varied from 5-30 per group (10 groups)Ex-4 : Mobility varied from 0-20 m/s. (10 groups)Ex-5 : Senders varied from 1-20 per group (10 groups)

CLAMMP – Results : Throughput (Mbps)

Groups CLAMMP

PUMA ODMRP

1 1.02 1.02 1.07

5 5.08 4.70 3.08

10 10.05 6.28 3.35

15 14.75 7.10 3.50

20 18.61 7.75 3.57

CLAMMP – Results : Packet Delivery Ratio

Nodes 50 100 150 200

CLAMMP

86.16 88.51 90.17 91.03

PUMA 35.88 35.99 36.09 34.22

ODMRP

16.53 16.19 15.86 15.50


Receivers per group

5 10 20 30

CLAMMP

93.15 92.85 93.06 92.91

PUMA 57.77 57.12 58.15 58.17

ODMRP

30.45 29.88 31.01 32.55


Mobility

0 5 10 15 20

CLAMMP

97.79 93.06

90.83

88.67

85.43

PUMA 59.73 58.15

57.23

55.97

55.22

ODMRP

31.45 31.01

31.07

30.87

30.56


Senders per group

1 5 10 15 20

CLAMMP

93.69 92.84

91.98

91.29

90.47

PUMA 58.75 58.05

57.44

56.83

56.22

ODMRP

56.45 31.01

21.07

13.87

8.92

CLAMMP Publications

R. Vaishampayan, J.J. Garcia-Luna-Aceves and Katia Obraczka, "Cross Layer Ad hoc Multiple channel Multicasting Protocol(CLAMMP)", The Seventh ACM International Symposium onMobile Ad Hoc Networking and Computing (Mobihoc 2006), Under Review.

Conclusions ROMANT : First tree based protocol to give PDR

comparable to mesh based protocols PUMA : Mesh based protocol with virtually fixed control

overhead and high PDR Adaptive Mesh Based Multicast : Best of both worlds MODA : Using DA’s increases transmission range for

same energy consumption. Reduces overhead. Overhead 0.68 times tree based PUMA and 0.16 times ODMRP

CLAMMP : Reduce interference by distributed channel scheduling so that communicating nodes are on the same channel and non-communicating nodes are on different channels. Throughput increase by a factor of 3 compared to PUMA and 5 compared to ODMRP.

Thank You !

Multicasting in Mobile Ad Hoc Networks Ravindra Vaishampayan Department of Computer Science...

Documents

Transcript of Multicasting in Mobile Ad Hoc Networks Ravindra Vaishampayan Department of Computer Science...