CYCLIC_OFFER_TIMER is not respected

[splywaczyk]

CYCLIC_OFFER_TIMER is not respected between last OFFER in the repetition phase and the first one in the main phase:

In the example above repetition_max=4

Here are the details:

1. When the service discovery is started also a main phase timer is started. When this timer expires nothing happens as long as service discovery is not in the main phase - timer is just restarted.

2. When the last OFFER in the repetition phase is sent, then next OFFER is sent in the main phase, but the delay of this OFFER depends on the remaining time of the main phase timer:

• If the remaining time of the main phase timer is bigger than half of CYCLIC_OFFER_TIMER (2s) then delay is set to CYCLIC_OFFER_TIMER and there is a switch to the main phase.

Example:
 Last OFFER in the repetition phase sent.
 Remaining main phase timer = 1,5s
 -> Switch to the main phase will be in CYCLIC_OFFER_TIMER <- after that main phase timer matters
 -> Next OFFER will be sent when main phase timer expires (in 0,5s since enter to the main phase)
 => This means that there will be 2,5s between subsequent offers. After that, every next OFFER will be sent every CYCLIC_OFFER_TIMER (maintained by the main phase timer).

• If the remaining time of the main phase timer is smaller than half of CYCLIC_OFFER_TIMER (2s) there is no delay but switch to main phase.

Example:
 Last OFFER in the repetition phase sent.
 Remaining timer = 0,5s
 -> Immediate switch to main phase <- after that main phase timer matters
 -> Next OFFER will be sent when main phase timer expires (in 1,5s since enter to the main phase)
 => This means that there will be 1,5s between subsequent offers. After that, every next OFFER will be sent every CYCLIC_OFFER_TIMER (maintained by the main phase timer).

This behavior is introduced in vsomeip 2.5.0 and has not been changed till now (3.1.20.3). Assuming CYCLIC_OFFER_TIMER = 2s this time can be between ~1s - ~3s

Is it implemented by purpose? Are the AUTOSAR requirements which describe this deviation?

[LccGitHub]

CYCLIC_OFFER_TIMER is not respected between last OFFER in the repetition phase and the first one in the main phase:

In the example above repetition_max=4

Here are the details:

1. When the service discovery is started also a main phase timer is started. When this timer expires nothing happens as long as service discovery is not in the main phase - timer is just restarted.
2. When the last OFFER in the repetition phase is sent, then next OFFER is sent in the main phase, but the delay of this OFFER depends on the remaining time of the main phase timer:

• If the remaining time of the main phase timer is bigger than half of CYCLIC_OFFER_TIMER (2s) then delay is set to CYCLIC_OFFER_TIMER and there is a switch to the main phase.

Example:
 Last OFFER in the repetition phase sent.
 Remaining main phase timer = 1,5s
 -> Switch to the main phase will be in CYCLIC_OFFER_TIMER <- after that main phase timer matters
 -> Next OFFER will be sent when main phase timer expires (in 0,5s since enter to the main phase)
 => This means that there will be 2,5s between subsequent offers. After that, every next OFFER will be sent every CYCLIC_OFFER_TIMER (maintained by the main phase timer).

• If the remaining time of the main phase timer is smaller than half of CYCLIC_OFFER_TIMER (2s) there is no delay but switch to main phase.

Example:
 Last OFFER in the repetition phase sent.
 Remaining timer = 0,5s
 -> Immediate switch to main phase <- after that main phase timer matters
 -> Next OFFER will be sent when main phase timer expires (in 1,5s since enter to the main phase)
 => This means that there will be 1,5s between subsequent offers. After that, every next OFFER will be sent every CYCLIC_OFFER_TIMER (maintained by the main phase timer).

This behavior is introduced in vsomeip 2.5.0 and has not been changed till now (3.1.20.3). Assuming CYCLIC_OFFER_TIMER = 2s this time can be between ~1s - ~3s

Is it implemented by purpose? Are the AUTOSAR requirements which describe this deviation?

this issue is similar as SOMEIPSRV_SD_BEHAVIOR_03 case in TC8 , enter main phase, first timer coms on, but not send offer service mesage, if fix false to true, this case is passed

[chw-eng]

Any update on why it is implemented this way? According to [PRS_SOMEIPSD_00411]"After entering the Main Phase, the provider *shall wait 1CYCLIC_OFFER_DELAY** before sending the first offer entry message". The delay should be fixed to CYCLIC_OFFER_DELAY and shouldn't be between 1/2 ~ 1 1/2 CYCLIC_OFFER_DELAY