How to identify dulicate messages

[Hugh Miles]

I have a problem collating model publish events arriving at two different nodes in my mesh.

My application is an array of sensors publishing through generic on off and generic level models. Two (or more) nodes in my mesh are “gateways” that report model events from the mesh to an observer computer via UDP over ethernet. Here is my architecture in ASCII art.

Sensor 1 <------------> Gateway 1    ===wired==
(unicast 0x0010)        (unicast 0x0030)        |
    ^    \            /                         |
    |     --------\  /                          v
    |               /                   Observer computer
    |     ---------/ \                          ^
    V    /            \                         |
Sensor 2 <------------> Gateway 2    ===wired===
(unicast 0x0020)        (unicast 0x0040)

So, a sensor reading on Sensor 1 is published as an event. It is published to a group address subscribed to by both Gateway 1 and Gateway 2. Each receives the event and reports it back to the observer computer. How does the observer computer recognize the two messages as relating to the same event?

Using nRF SDK for Mesh 3.1.0, I wrote this client event handler for the level status event:

static void app_gen_level_client_status_cb(
    const generic_level_client_t * p_self,
    const access_message_rx_meta_t * p_meta,
    const generic_level_status_params_t * p_in) {

    // my function for reporting the event via UDP
    tx_model_event(
        p_meta->src.value,
        p_in->present_level,
        p_meta->p_core_metadata->params.scanner.timestamp);
}

However, I did not get the results I expected. The UDP messages arrived from both gateways, but had different timestamps on them. I dug around a bit and found that the timestamp part of the metadata is applied in the *receiver* (i.e. independently by each gateway) in scanner.c in the function radio_handle_end_event().

I’ve poked around in the debugger and cannot find any sequence number, token or ID that identifies the event message. I guess there *must* be some way that the mesh avoids delivering the message twice to a node through two routes (e.g. Sensor 1 -> Gateway 1, Sensor 1 -> Sensor 2 -> Gateway 1).

How do I uniquely identify a message from e.g. Sensor 1 so that the observer computer doesn't process it twice when it arrives from different gateways?

Can anyone help me?

[Hung Bui]

Hi Hugh, 

In theory this issue can be solved by the TID (transaction ID) that should be unique for each message. However it's not included in the Generic On Off Status message definition. I can see in our code that we have the generic_onoff_state_t struct that contain the on_off status and the transaction ID. But we haven't used it.

 
I would need to double check with the Mesh team to see if there is anything defined in the spec about this. 

Otherwise you would need to send it as a proprietary access packet. Or create your own model for the purpose. 

[Hung Bui]

Hi Hugh, 

Just an update from our team. The status message doesn't have an TID and it's not supposed to have one. It's just a packet represent the latest status of the bulb. 

In mesh we do have a way to detect a message that's already received. It's called message caching. And a sequence number is used to detect the message. The sequence number is not forwarded to the access layer. If you really need to detect the duplicated messages you can modify the upper_transport_packet_in() function in transport.c to forward the sequence number of the packet into access layer (upper_transport_access_packet_in() function).

The sequence number is inside network_packet_metadata_t struct, which you can find in p_metadata->net

Another solution, which I think maybe easier is to simply discard status packet that you receive from the gateway if the value doesn't change from the period status.