Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Multi-hop #58

Open
danieladriano opened this issue Dec 11, 2018 · 14 comments
Open

Multi-hop #58

danieladriano opened this issue Dec 11, 2018 · 14 comments

Comments

@danieladriano
Copy link

Hi,

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

Regards,
Daniel

@riebl
Copy link
Owner

riebl commented Dec 11, 2018

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
Copy link
Author

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
Copy link
Owner

riebl commented Dec 12, 2018

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
Copy link
Author

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
Copy link
Owner

riebl commented Dec 27, 2018

@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
Copy link
Author

Hi @riebl

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

daniel.dadriano@gmail.com

Thanks for helping me!

Regards,
Daniel

@riebl
Copy link
Owner

riebl commented Jan 10, 2019

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
Copy link

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
Copy link

Hi, @riebl

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

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

@riebl
Copy link
Owner

riebl commented Jan 25, 2019

@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
Copy link

ruisonghan commented Jan 26, 2019

@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
Copy link
Owner

riebl commented Jan 28, 2019

@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
Copy link

ruisonghan commented Jan 28, 2019

@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
Copy link
Owner

riebl commented Jan 28, 2019

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants