1 Introduction
2 Related work
2.1 Broadcasting protocols
2.2 Geocasting protocols
2.3 Discussion
Forwarding strategy | Messages per hop | Simulated scenarios | Assumptions | ||||||
---|---|---|---|---|---|---|---|---|---|
Protocol | Probabilistic | Distance | Straight road | Intersection | Multi-sessions | GPS | Map | RSU | |
SAB [13] | ✓ | One (broadcast) | ✓ | ||||||
Weighted p-persistence [7] | ✓ | One (broadcast) | ✓ | ✓ | |||||
Slotted 1-persistence [7] | ✓ | One (broadcast) | ✓ | ✓ | |||||
IF [8] | ✓ | ✓ | One (broadcast) | ✓ | ✓ | ||||
PREDAT [14] | ✓ | ✓ | One (broadcast + periodic beacons) | ✓ | ✓ | ✓ | ✓ | ||
DRIVE [15] | ✓ | One (broadcast) | ✓ | ✓ | ✓ | ✓ | |||
DOT [12] | ✓ | One (broadcast + periodic beacons) | ✓ | ✓ | |||||
IVG [9] | ✓ | One (broadcast, with rebroadcast overhearing) | ✓ | ✓ | |||||
DRG [10] | ✓ | One (broadcast, with rebroadcast overhearing) | ✓ | ✓ | ✓ | ||||
EDB [6] | ✓ | Two (broadcast request, ack) | ✓ | ✓ | ✓ | ✓ | |||
TSM [11] | ✓ | Three (broadcast + periodic beacons) | ✓ | ✓ | ✓ | ||||
UMB [4] | ✓ | Four (broadcast RTS, CTS, data, ack) | ✓ | ✓ | ✓ | ✓ | ✓ | ||
SB [5] | Four (broadcast RTS, CTS, data, ack) | ✓ | ✓ | ||||||
Route finding [17] | ✓ | Two (broadcast request, unicast reply) | ✓ | ✓ | ✓ | ✓ | |||
Geocache [16] | ✓ | Two (broadcast request, unicast reply) | ✓ | ✓ | ✓ |
3 Road traffic collecting (RTC) protocol
3.1 Model
3.2 Query dissemination
-
Source node id S id .
-
Query sequence number S n .
-
Coordinate of the source node L s =(x s ,y s ) and the coordinate of destination location L d =(x d ,y d ).
-
Set of target road segments \(\mathcal {E}_{T}\).
-
Set of 0–1 flag variables \(\mathcal {F} = \{F_{e}\}, e=1,2, \ldots, |\mathcal {E}_{T}|\) to indicate whether the query has been over road segment \(e \in \mathcal {E}_{T}\).
-
Road traffic information: a set of tuples \(\mathcal {I} = \{(v_{j},\boldsymbol {L}_{j})\}\) of all nodes j that forwards this TC message, where v j is the velocity of node j and L j is the position of node j when receiving the TC message from the previous forwarding node. This set is initially empty and grows as the query is forward in the network.
3.2.1 Selection of next forwarding node
3.2.2 Response to neighbor probing message
3.2.3 Query reply
RTCMessageHandling
in the background to handle NP messages. The cache \(\mathcal {C}\) to keep track of sessions the node has seen is initially empty. A node receiving an NP message may acknowledge several times in case the NP message sender did not receive acknowledgement due to channel collision and rebroadcast the NP message. If the node is chosen as the next forwarding node, it executes NextForwardSelection()
to continue to query dissemination. It will return the query reply message to the query source if it fails to find a next forwarding node.4 Performance evaluation
4.1 Simulation model
RTC protocol parameters | |
Neighbor’s response timeout (T
np
) | 10 ms |
Number of NP message retries | 6 |
δ for ZoQ | 0.2 |
Number of shortest paths in ZoQ | 5 |
Network parameters | |
Transmission power | 2 mW |
Path-loss model | Two-ray ground model |
with path-loss | |
exponent 4.0 | |
Network topology | 4×42 and 8×82
|
Mobility parameters | |
Maximum vehicle speed | 17.7 km/h |
Vehicle acceleration | 0.674 m/s2
|
Vehicle deceleration | −0.687 m/s2
|
Vehicle length | 5 m |
Minimum gap between vehicle | 2.5 m |
Car-following model | SUMOKrauß |
-
Percentage of target road segment coverage: The ratio of the number of road segments traversed by the query message of the RTC protocol and the total number of target road segments \(\mathcal {E}_{T}\).
-
Query response time: The time taken from the query message has been sent by a source until the time of the last query reply message received by the source node.