Let's say I have a mesh of sensors forming a wireless ad-hoc network.

If one sensor wants to send data to the sink, it will transmit a packet via WiFi for example.

My assumption is that there's no direction to the sending, and so all other sensors within range of the sending nodes signal will receive the packet and attempt to forward it.

How can sensor networks like this ever operate efficiently? Surely this results in explosive duplication of packets across the network?


Based on some reading, I've found that the MAC addresses used in the layer 2 frames are used by receiving nodes to determine if the frame is for that node.

I.e. Node A, B, and C are all within each others radio diameter. If we assume they already know each other's MAC addresses.

  1. A creates IP packets with src AIpAddress and dest BDestAddress
  2. Packet is encapsulated by layer 2 frame. The MAC address of A is set as the source, and the MAC address of B is set as the destination.
  3. Node A sends radio signal containing this data

At C:

  1. Layer 2 decodes frame, sees that the dest mac address isn't for it, and discards the packet.

At B:

  1. Layer 2 decodes frame, sees that the dest MAC address is it's own MAC address, and passes the frame payload up to layer 3.

  2. Layer 3 interprets the frame payload as an IP packet.

If this is correct, then would this be viable in an ad-hoc network in order to route IP packets via a specific node, rather than all neighbouring nodes attempting to forward the message?

  • Do you have a WiFi mesh or ad-hoc network? Those are different things. ad-hoc is a point-to-point system -- A can only talk to radios with its range. Other nodes relaying traffic to out-of-range nodes is a mesh. How the mesh works depends on how the mesh is setup. (i.e. what is its routing protocol)
    – Ricky
    Commented Mar 31, 2019 at 20:59
  • Did any answer help you? If so, you should accept the answer so that the question doesn't keep popping up forever, looking for an answer. Alternatively, you can provide and accept your own answer.
    – Ron Maupin
    Commented Dec 15, 2019 at 1:27

1 Answer 1


Yes your assumption is correct when traditional routing is used(proactive routing). If you used traditional routing, it create routing table before packet is sent.

  • Maintenance of routing tables requires much bandwidth
  • Dynamic topology much of the routing information is never used Waste of capacity
  • Flat topology- No aggregation

But when you used reactive routing that problem is being solved. because

  • Reactive routing find a route destination when sending file.

But it makes small delay before sent first file. In addition to that flooding is being used by reactive routing to find routing path.

However Reactive routing is more efficient than traditional proactive routing. You can use

  • Dynamic Source Routing (DSR)

  • Ad-hoc On-demand Distance Vector Routing(AODV) protocols

  • In layer two I've read that the MAC address is used at the receiving end to determine if the packet was meant for that node, and that allows all receiving nodes to determine if it was actually for them. Could this mechanism be used to limit this broadcast behaviour? Commented Mar 31, 2019 at 17:14
  • Not fully understand what you asked??? Layer2 devices use mac addresses, that is true. But layer 2 devices use broadcast to find mac address. they maintain mac address table instead of routing table. However layer 3 devices more intelligent than layer2 devices.
    – infra
    Commented Mar 31, 2019 at 18:19
  • I'll add a better description to the question Commented Mar 31, 2019 at 18:41
  • 1
    brianstorti.com/tcp-flow-control refer this link you will understand. your explanation is related to TCP Ip flow control. It is a conceptual modal of data transmission. sure problem will be solved when you read this article.
    – infra
    Commented Apr 1, 2019 at 3:52
  • 1
    youtube.com/… this video provided excellent explanation and this is what i followed in the beginning
    – infra
    Commented Apr 1, 2019 at 3:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.