Setting NETWORK_TRANSMIT_COUNT , config_publication_state_t and access_publish_period_t makes no difference!

RE: Setting NETWORK_TRANSMIT_COUNT , config_publication_state_t and access_publish_period_t makes no difference!

Mttrinh — Fri, 28 May 2021 16:21:54 GMT

Hi,

1. Correct. The network layer implements a message cache, so a message will be filtered out if the seqnum is in the cache (https://github.com/NordicSemiconductor/nRF5-SDK-for-Mesh/blob/master/mesh/core/src/net_packet.c#L128-L137)

2. Retransmissions of relayed packets is controlled by Relay Retransmit state (section 4.2.20 of the mesh specification). NETWORK_TRANSMIT_COUNT doesn't affect this. To control this, you need to call config_client_relay_set. The default value can be changed through CORE_TX_REPEAT_RELAY_DEFAULT.

2.1. If the message's SeqNum is in the cache, it won't be relayed the second time, so this is correct. But the amount of re-transmissions of the relayed packed can be configured separately through Relay Retransmit state.

3. The original message (access PDU) is re-transmitted with different SeqNum, so they will be treated by the relaying nodes as a different message, that is correct.
Just for the note. To avoid message's duplication at the access layer, some models implement a field called as Transaction Identifier (TID) (see section 1.4.2.1 of the mesh model spec).

3.1. The relaying node will forward the relayed packet the amount of times defined by Relay Retransmit state. The default value defined in CORE_TX_REPEAT_RELAY_DEFAULT and it is 1.

4. Correct. There will be 3 messages with different SeqNum that are retransmitted 3 times. And then relayed the amount of times defined in Relay Retransmit state.

5. We are working on such paper right now. But maybe this one could give more insights: ieeexplore.ieee.org/.../9035389

RE: Setting NETWORK_TRANSMIT_COUNT , config_publication_state_t and access_publish_period_t makes no difference!

EAn — Wed, 26 May 2021 17:35:32 GMT

Greetings to @all and Mttrinh!

I finally made it to revisiting this post and looking with more attention to these settings. A few doubts have emerged, and I would be very grateful if you or someone knowledgable could help shed light into the matter.

All messages repeated due to the NETWORK TRANSMIT COUNT should have the same sequence number, therefore other nodes will treat the repetitions as the same message and will discard any replays. Correct?
Does the NETWORK TRANSMIT COUNT affect all PDUs/messages in the network, including when they are being relayed?
1. I guess they would be relayed only once since the sequence number is the same for all messages re-transmitted at the network level. That is, if it is set to 2, then the messages will be transmitted 3 times by the source element, and they will always be relayed once by the relaying nodes. Correct?
Another thing I didn't quite understand is: the Re-transmit Count, forces the access layer of the sender element and model instance to send the message 1+Packet Retransmit Count times. However, only the sender gets to do that, right? The relaying nodes forward each repeated message once, but since the original message was re-transmitted with a different SEQ num, they will be treated by the relaying nodes as a different message. correct?
1. Therefore, each relaying node will forward once each transmitted PDU. Am I wrong?
Finally, What is the sum effect of having both of these variables set? Take the following configuration scenario:
1. NETWORK TRANSMIT COUNT = 2
  generic_on_off retransmit_count = 2
  Does that mean that each message will be transmited 3 times by the network layer, and 3 times by the access layer, therefore 3x3 = 9 times in total for each PDU!?
Can anyone please point me to a good-practice manual/reference guide for bluetooth mesh tunning!? In my experience a small network has a very different set of needs from a big network (above 10 nodes). I'm losing more packets as the number of nodes grows in the network....

Thank you very much for making it all the way here! I'm looking forward for all the helpful pointers! If anyone wants to answer partially, please do!

Best Regards!

RE: Setting NETWORK_TRANSMIT_COUNT , config_publication_state_t and access_publish_period_t makes no difference!

EAn — Wed, 31 Mar 2021 11:10:43 GMT

Thank you very much Mttrinh! Your reply was indeed very informative and complete. I still have to perform some tweaks and tests with this new knowledge and will reply when I do so!

Thank you!

RE: Setting NETWORK_TRANSMIT_COUNT , config_publication_state_t and access_publish_period_t makes no difference!

Mttrinh — Wed, 24 Mar 2021 10:10:20 GMT

Hi,

1. You send a segmented message with 4 PDUs. The segmentation and reassembly happens at the transport layer. Which means that the whole packet will be split into 4 segments at the transport layer and then will be transferred to the network layer.

transport_packet_in() is called by the network layer, when the packet is received. The also happens when the packet is targeted to a group address which the node is subscribed to (by loopback mechanism). I assume that the destination in your scenario is a group address since you say that p_rx_metadata->source is set to NRF_MESH_RX_SOURCE_LOOPBACK.

There needs to be considered that the network layer has a cache (see msg_cache_entry_exists()), which prevents the message with the same sequence number be processed twice.

upper_transport_tx() in turn is called before the message being sent by the access layer is segmented by the transport layer.

Two things needs to be clarified now:

NETWORK_TRANSMIT_COUNT configures number of messages transmissions at the network layer. In other words, how many times a network PDU with the same sequence number will be transmitted.
retransmit_count (called RPC by customer) configures the message publication at the access layer. In other words, how many times an access PDU will be retransmitted.

So e.g. if you have retransmit_count = 1, you will see the message sent twice in upper_transport_tx(). The first one is the original publication and the second one is the republished message.

In the mean time, no matter how big NETWORK_TRANSMIT_COUNT value is, if the destination of the message is a group address and the node is subscribed to that address, it will see each network PDU only once in transport_packet_in(). Considering the fact that you send a segmented message, you should see it 4 times (since 4 PDUs). Not sure why you see the message 5 times in transport_packet_in(). Probably, the message is split not to 4, but 5 PDUs. You can add log in transport.c::trs_sar_packet_out() to see how many segments in the message.

To the conclusion. To log the incoming and outgoing messages:

at the access layer, use mesh_msg_handle() and nrf_mesh_packet_send() (see access.c);
at the transport layer, use transport_packet_in() and sar_segment_send() for segmented messages or unsegmented_packet_tx() for unsegmented messages (see transport.c);
at the network layer, use network_packet_in() and network_packet_send() (see network.c);

2.a and 2.b: NETWORK_TRANSMIT_COUNT configures number of transmissions of a network PDU at the network layer while NETWORK_TRANSMIT_INTERVAL_STEPS configures the interval between those transmissions. (see the mesh profile specification v1.0.1, section 4.2.19).

2.c publish_period configures the interval at which messages are published by a model at the access layer (see the mesh profile specification v1.0.1, section 4.2.2.2).

2.d publish_retransmit configures retransmissions of the message at the access layer (see the mesh profile specification v1.0.1, section 4.2.2.6, 4.2.2.7).

3. This depends on your use case. If you wants to see the message once, you need to set publish_rentrasmit and publish_period to 0, and log the incoming message in mesh_msg_handle() in access.c. I also suggest to try out the nRF5 Mesh mobile app. This may also help to clarify how this works.

RE: Setting NETWORK_TRANSMIT_COUNT , config_publication_state_t and access_publish_period_t makes no difference!

EAn — Fri, 19 Mar 2021 15:08:47 GMT

Thank you Mttrinh! It will be very helpful.
Best regards!

//EA

RE: Setting NETWORK_TRANSMIT_COUNT , config_publication_state_t and access_publish_period_t makes no difference!

Mttrinh — Fri, 19 Mar 2021 14:57:51 GMT

Hi,

Sorry for the late response.

I have reached out the team regarding this, will give you an update as soon as I get a response.