Relay forwarding task is executed 2 seconds after the transmission, instead of 50 milliseconds

[adriansmares]

When LBM is compiled with relay RX support, the 'relaying' task (which re-transmits the uplink message from the end device) is executed 2 seconds after the transmission end, instead of 50 milliseconds after the transmission end:

SWL2001/smtc_modem_core/modem_services/relay_service/lorawan_relay_rx_service.c

Lines 187 to 208 in c4f386a

	void lorawan_relay_rx_fwd_uplink( uint8_t stack_id, const uint8_t* data, uint8_t data_len, uint32_t time_tx,
	bool is_join )
	{
	IS_VALID_STACK_ID( stack_id );
	IS_SERVICE_INITIALIZED( );
	// SMTC_MODEM_HAL_TRACE_PRINTF( "Relay RX service add fwd ul task %d\n", smtc_modem_hal_get_time_in_ms( ) );
	smodem_task task_relay = {
	.id = relay_rx_obj.task_id,
	.stack_id = stack_id,
	.priority = TASK_HIGH_PRIORITY,
	.time_to_execute_s = smtc_modem_hal_get_time_in_s( ) + 2,
	};
	SMTC_MODEM_HAL_PANIC_ON_FAILURE( modem_supervisor_add_task( &task_relay ) == TASK_VALID );
	memcpy( relay_rx_obj.buffer, data, data_len );
	relay_rx_obj.buffer_len = data_len;
	relay_rx_obj.time_to_tx = time_tx;
	relay_rx_obj.service_state = ( is_join == true ) ? SERVICE_FWD_FWD_JOIN : SERVICE_FWD_FWD_UL;
	relay_stop( true );
	}

The enqueuing itself is done correctly - it uses the receive timestamp + 50 milliseconds:

SWL2001/smtc_modem_core/lr1mac/src/relay/relay_rx/relay_rx.c

Lines 1299 to 1301 in c4f386a

	lorawan_relay_rx_fwd_uplink(
	RELAY_STACK_ID, buffer, info->buffer_length + RELAY_FWD_UPLINK_BYTE_ORDER_UPLINK_PAYLOAD,
	info->rx_uplink_timestamp_ms + RELAY_FWD_DELAY, ( wor->wor_type == WOR_MSG_TYPE_JOIN_REQUEST ? true : false ) );

I guess this change from the specification is done in order to avoid the relay interfering with the RX1 and RX2 of the original transmission, and to be honest it sort of makes sense (although it assumes RX1=1), but I think that either the delay in the regional parameters should be updated or this delay should be somehow controllable - it makes deduplication on the Network Server significantly harder if we want to keep all downlink paths, and the 2 seconds seem arbitrary.

[lbm-team]

Hello @adriansmares ,

This 2s delay was introduce for some tests and should have not made it to the release.
This would be fixed in the next release.

In the meantime, you could remove the "+2" in the task_relay variable.

[lbm-team]

Hello,

This issue was solved in the release v4.4.0-feature-relay.