Problem with ETSI TR 103 299 V2.1.1 triggering conditions

[enioprates]

Hello.
According to ETSI TR 103 299 V2.1.1, the CAM triggering conditions varies from 0.03s to 0.1s. However, there is a limitation provided by /artery/extern/vanetza/vanetza/dcc/state_machine.cpp, where the minimum time between the states are 0.06s

Clock::duration Relaxed::transmission_interval() const
{
    return std::chrono::milliseconds(60); // 
}

If I reduce this value to milliseconds(30), everything works fine, but I am concerned about the remain time limitations of the system, like the ones presented in

void Active::update(double min_cl, double max_cl)
{
    assert(min_cl <= max_cl);

    static const std::array<double, sc_substates> channel_loads {{
        0.27, 0.35, 0.43, 0.51, 0.59
    }};

    auto state_up_it = std::upper_bound(channel_loads.begin(), channel_loads.end(), min_cl);
    auto state_up = std::distance(channel_loads.begin(), state_up_it);

    auto state_down_it = std::upper_bound(channel_loads.begin(), channel_loads.end(), max_cl);
    auto state_down = std::distance(channel_loads.begin(), state_down_it);

    m_substate = std::max(state_up, state_down);
    m_substate = std::min(sc_substates - 1, m_substate);
    assert(m_substate < sc_substates);
}

Clock::duration Active::transmission_interval() const
{
    static const std::array<Clock::duration, sc_substates> tx_intervals {{
        std::chrono::milliseconds(100),
        std::chrono::milliseconds(180),
        std::chrono::milliseconds(260),
        std::chrono::milliseconds(340),
        std::chrono::milliseconds(420),
    }};

    const std::size_t index = std::min(tx_intervals.size() - 1, m_substate);
    return tx_intervals[index];
}

Can you help me to guarantee the systems time limitations and understand about where comes the 60milisec limitation and if its fine to reduce it for 30?

[kenog]

Hi,

I hope I understood your question correctly. The lower limit of the Toff time is 25ms according to EN 302 571.
TS 102 687 specifies the reactive DCC mechanism. However, it does neither specify the amount of states nor the values. It only gives two examples in the (informative) annex. The Car2Car Communication Consortium demands Table A.2 of that document to be used (the values and amount of states differs from the values in your code snippet). But this of course is only relevant if you want to comply to their Basic System Profile.
If you don't, I see no issue in parametrising DCC the way you intended to.

Regards
Keno

[enioprates]

Thanks for your answer! The values that are in my code are the values from Vanetza files itself (with no changes).
In our research, we are analyzing the impact of the Basic System Profile in the platoon controller. So, we need to test the system using the BSP and in several different conditions. The ETSI TR 103 299 V2.1.1 was published in 2019 and there is no new version for the Car2Car Communication Consortium documents, about this new ETSI profile. I think that with this new minimum value of T_GenCamMin should lead to some changes in DCC?

[kenog]

Hi,

yes I saw the values in Vanetza, too. Not sure where they come from. Maybe from an older version of the specifications?

TR 103 299 is a Technical Report. That means it is purely informative and has normative character. Furthermore, it is just a pre- standardisation study. Therefore I am not sure you can expect the BSP to reflect the values any time soon. When (in a couple of years or so), there actually should be a normative specification for platooning beacons demanding shorter Toff times than currently in suggested in TS 102 687, this will to be changed in that document and the BSP, yes. I am just not sure how fast this will happen.

Regards
Keno

[riebl]

Seems like you are using an old version of Vanetza as the quoted DCC state machine code has been moved to fully_meshed_state_machine.hpp some time ago. Parameters of this state machine implementation follow the (deprecated) BSP v1.2 as noted in the comments. If you intend to stay with reactive DCC building upon a state-machine you should consult TS 102 687 for recent parameter settings. Those revised state machines are implemented by gradual_state_machine.hpp.
Of course, you can also use a custom state machine which may be optimised for C-ACC as long as it implements the vanetza::dcc::StateMachine interface.