Multi-hop

[danieladriano]

Hi,

Artery implements any type of forwarding for multi-hop, like Greedy Forwarding or Contention Based Forwarding ?

Regards,
Daniel

[riebl]

Artery itself does not provide any forwarding algorithms, however, it integrates Vanetza for this task. Vanetza supports all forwarding algorithms given by EN 302 636-4-1 including Greedy Forwarding and Contention Based Forwarding.

[danieladriano]

Hi @riebl

Thanks for the help. I try to use Vanetza routing for multi-hop, but I can't make it work. Do you have an example on how to use any Vanetza forwarding algorithms with Artery?

Regards,
Daniel

[riebl]

From the perspective of an Artery service there is not much to do: Any packet with transport type set to "GBC" (GeoBroadcast) will be subject to forwarding operations by artery.networking.Router.
So far there is no Router module parameter to change the routing algorithm, however, you can easily override the setting in code at MIB setup by setting itsGnAreaForwardingAlgorithm and itsGnNonAreaForwardingAlgorithm. Feel free to make those configurable via module parameters :-)

[danieladriano]

Hi @riebl

I set the settings at MIB setup to:

mib.itsGnAreaForwardingAlgorithm = vanetza::geonet::BroadcastForwarding::CBF;
mib.itsGnNonAreaForwardingAlgorithm = vanetza::geonet::UnicastForwarding::Greedy;

In my scenario, the source node are outside the destination area, so when I send a packet two hops are executed using vanetza::geonet::UnicastForwarding::Greedy. In the third hop the node are inside the destination area, but he don't execute the CBF for disseminate the packet inside.

I have been debugging the vanetza::geonet::router.cpp and read the ETSI EN 302 636-4-1 V1.2.1 , but I don't be able to find the problem.

Can you help me?

Regards,
Daniel

[riebl]

@danieladriano Can you share your scenario with me, possibly sending it confidentially via e-mail? Your selection of forwarding algorithms is actually Vanetza's default setup, so that is not changing anything.

[danieladriano]

Hi @riebl

Of course! Can you send me a e-mail and then I send back to you with my scenario. My e-mail:

[email protected]

Thanks for helping me!

Regards,
Daniel

[riebl]

Note to the public: Daniel and me have investigated this issue further and we currently believe that Artery is behaving correctly according to ETSI specification. A possible (not yet standardised) solution is work-in-progress.

[ruisonghan]

Hi, @danieladriano and @riebl

I am also very interested in this issue and if you need a hand, I would like to take part in the discussion and test.

[ruisonghan]

Hi, @riebl

I think I may face the same problem as @danieladriano .

Could u tell if there is any progress for this problem?

[riebl]

@ruisonghan I am still working on this. In the meantime, you may work-around multi-hop routing issues by repeating transmissions (see the repetition field in vanetza::btp::DataRequestB's GeoNet parameters).

[ruisonghan]

@ruisonghan I am still working on this. In the meantime, you may work-around multi-hop routing issues by repeating transmissions (see the repetition field in vanetza::btp::DataRequestB's GeoNet parameters).

Hi, Riebl and Daniel

I think my problem is different from Daniel's and I am trying to get the reason. I defined my own scenario and DEN use cases called TranssecRiskLevel and TranssecRiskLevelReceiver. The basic function of them is sending an alert to other vehicles and makING other vehicles evacuate.

Currently, I found that when my own use cases were used with the DEN use case "ImpactReductionContainerExchange", multi-hop GBC worked normally. However, when "TrafficJamAhead" was used with my use cases, multi-hop didn't work.

<?xml version="1.0" encoding="UTF-8"?>
<usecases>
    <usecase type="artery.application.den.TranssecRiskLevel">
      <filters><name pattern="truck0.0" /></filters>
    </usecase>
    <usecase type="artery.application.den.TranssecRiskLevelReceiver">
      <filters><name pattern="truck0.0" match="inverse"/></filters>
    </usecase>

    <usecase type="artery.application.den.TrafficJamAhead" />  
    <!--  <usecase type="artery.application.den.ImpactReductionContainerExchange" /> -->
</usecases>

I am a little confused with why the DEN use cased may affect the multi-hop communication. I will contact you when I find a clue.

[riebl]

@ruisonghan Maybe too many messages are generated by your station, i.e. DCC may enqueue them. I have recently added a NoRateControlDccEntity which you could try. You can enable this entity by adding **.vanetza.dcc.typename = "NoRateControlDccEntity" to your omnetpp.ini.

[ruisonghan]

@ruisonghan Maybe too many messages are generated by your station, i.e. DCC may enqueue them. I have recently added a NoRateControlDccEntity which you could try. You can enable this entity by adding **.vanetza.dcc.typename = "NoRateControlDccEntity" to your omnetpp.ini.

Hi, @riebl

Currently, I found 2 ways to temporarily solve my problems, but I still don't know the reasons.

1. By setting the sampleDuration of TrafficJamAhead to 10s (from 120s to 10s) in src/artery/application/den/TrafficJamUseCase.ned

2. By setting the request.gn.traffic_class.tc_id(0); of TrafficJamAhead::createRequest() in src/artery/application/den/TrafficJamUseCase.cc. This setting was previously request.gn.traffic_class.tc_id(1);

For 2, I think my problem is related to the communication congestion, but when testing my use case with TrafficJamEndOfQueue, multi-hop worked fine. And the communication frequency of TrafficJamEndOfQueue is higher than TrafficJamAhead. This is very weird since it seems the less frequent use case and message will affect my use case.

I am still working on it and hope to find an answer.

[riebl]

Regarding 1), these limits are just set as required by C2C-CC's Triggering Conditions. Possibly these conditions simply do not trigger with a longer sample buffer in your scenario.
2) TC ID 0 (a.k.a. DCC DP0) is used for bursty packets ("emergency packets"). DP1 is used for normal DENMs.