GeoNetworking packet forwarding erroneous?

[fysch]

I currently have problems with GN packet forwarding, and I am uncertain if this is desired behavior, an error in Vanetza or an error in the standard.

My test scenario looks like this (v0 = Vehicle_0, ...), the vehicles do not move:

----------------------------------------
 v0 ----- v1 ----- v2 ----- v3 ----- v4
----------------------------------------

1. v0 sends a GeoBroadcast with a large destination area, such that all 5 vehicles are within that area
2. v1-v4 receive the packet
3. Since I use contention-based forwarding, v4 forwards the packet
4. v0-v3 receive the packet
5. v1-v3 discard it
6. v0 does not discard it because there is nothing to discard in its CBF packet buffer
7. v0 forwards its own packet, which it has received from v4
8. goto (2.)

I have also tested this with Topo-Scoped Broadcast and the SN-based duplicate packet detection (A.2 in EN 302 636-4-1).

As far as I can tell, all duplicate packet detection measures fail to detect packets that were originally sent by the ego vehicle. In my opinion, vehicles should immediately discard packets, if their Source Position Vector matches the one in the received packet. I also tested this, and then everything seemed fine.

Am I missing something?

[riebl]

No, you are not missing something; it is indeed the specified behaviour. Vanetza's MIB has vanetzaFadingCbfCounter, which partially fixes the issue in the sense that the re-transmission of v0 does not trigger further forwardings (v1 to v3 have already discarded the packet, v4 has just forwarded: they would start all over again…). Nevertheless, the source station is currently not rejecting the forwarding of its own packets. However, in combination with SCF, the source station may be a legitimate forwarder; it is hard to say that the source shall never participate in forwarding its own packets. There is room for improvement, though.

[fysch]

Thank you very much for this clarification.