aodv modification

[Jihad Ismail]

hello ns-3 users :)
I`m trying to modify aodv protocol so that when a node get out of neighbor`s range, neighbor immediately detect that and modify its routing table to get the shortest path for the node with out any packet loss. i try to let the moving node send  a msg (hello) just before moving so that any neighbor modify its routing table with the new shortest path. can any one help me with an idea about how to implement such modification ?
thanks 

[Tommaso Pecorella]

Hi,

this is not an ns-3 problem, this is a feasibility thing (in ns-3 or in a real system).

I have one good news (and one bad news).

The good news is that if you manage to do what you described without resorting to black magic or selling your soul (and the one of all your ancestors and descendants) to the devil, you'll achieve honor and glory, and your name will be forever remembered in the telecommunications books.

Guess what's the bad news ?

The problem is: you can't reliably predict when you'll be out of radio range. You could do it only in these two cases:

1) perfect knowledge of the Tx/Rx antenna positions, and

2) perfect knowledge of the channel propagation effects.

Both are, of course, ideal conditions that can be met only in open space (let's say: on the moon is not enough).

The best you can do is to monitor the RSSI, and even that is not that good, because you have to consider the UE speed. You may measure one thing and, by the time you decide it's time to say goodbye and the time you can do that... it's too late.

You could, of course, be conservative and say goodbye earlier, but you'll loose a lot of radio coverage. Plus, the RSSi is not linear, and you have to measure it anyway (overhead!)

Summarizing...

Good luck, you'll need it.

T.

[Jihad Ismail]

Thanks Tommaso :)
but it could happen by modifying the aodv-routing protocol class at "processHello()" method that if the hello msg is from a node that is not a neighbor so send a Rreq again and that's it. :) 

--
You received this message because you are subscribed to a topic in the Google Groups "ns-3-users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/ns-3-users/MOCHVYWPapo/unsubscribe.
To unsubscribe from this group and all its topics, send an email to ns-3-users+...@googlegroups.com.
To post to this group, send email to ns-3-...@googlegroups.com.
Visit this group at http://groups.google.com/group/ns-3-users.
For more options, visit https://groups.google.com/d/optout.

[Konstantinos]

In order to receive a HELLO and thus calling ProcessHello(), a node has to be within the com. range, so it is regarded as neighobr. You can not receive a hello from non-neigbors.

To unsubscribe from this group and all its topics, send an email to ns-3-users+unsubscribe@googlegroups.com.

[Tommaso Pecorella]

Please explain me again. I'm quite confused, and I can't figure out how can you transmit an Hello packet when you're not in radio range. Or to not be a neighbor if you're in radio range.

Anyway, not my business. If you want to try it out, be my guest. I just hope you'll not claim to have done something that is physically impossible.

T.

[Jihad Ismail]

that is what i`m trying to do and what i mean by changing its place, the request again msg will help to detect the shortest path so no packet loss occurs.
​ 

[Konstantinos]

The image confused me even more.

What is the first and what is the second case? What is the red node? Who is the sender, who the receiver?

What do the lines indicate, that a node is neighbor to the linked one? What about the two nodes on the right hand side in the first image? 

Please provide more details of your problem you want to solve.  

To unsubscribe from this group and all its topics, send an email to ns-3-users+unsubscribe@googlegroups.com.