Server Publishing messages every minute

[nish]

Good day, 

I am using the ANNA-B112 BLE device from ublox in a custom design. The ANNA-B112 interfaces with a host MCU over UART. The ANNA=B112 is flashed with Soft Device S132 and is set up for mesh networking.

The way my design works, is that Host MCU will wake up from a sleep stage every minute or two, take some data readings from sensors, and then the ANNA B112 (mesh) publishes a packet to the Client node. The system then goes to sleep, and in this state the ANNA-B112 is actually powered off. So every time MCu wakes up, the ANNA-B112 is powered back on again. 

The issue I am experiencing, is that after some time, the server fails to successfully publish and packets. I have verified that it is indeed attempting to publish packets, using access_model_publish(); which is returning with error code NRF_ERROR_FORBIDDEN. Following the function access_model_publish() to identify what exactly is going wrong, I can see that the error code comes from a function in the net_state.c file, particularly in the following function call:

uint32_t net_state_seqnum_alloc(uint32_t * p_seqnum)
{
    if (m_net_state.seqnum < m_net_state.seqnum_max_available)
    {
        /* Check if we've reached the seqnum threshold for a state transition. */
        uint32_t threshold = NETWORK_SEQNUM_IV_UPDATE_START_THRESHOLD;
        if (m_net_state.iv_update.state == NET_STATE_IV_UPDATE_IN_PROGRESS)
        {
            threshold = NETWORK_SEQNUM_IV_UPDATE_END_THRESHOLD;
        }
        bool ivu_triggered = false;
        if (m_net_state.seqnum >= threshold)
        {
            m_net_state.iv_update.pending = true;
            ivu_triggered = iv_update_trigger_if_pending();
        }

        if (!ivu_triggered && m_net_state.seqnum >= m_net_state.seqnum_max_available - NETWORK_SEQNUM_FLASH_BLOCK_THRESHOLD)
        {
            seqnum_block_allocate();
        }
        /* Get the sequence number after doing the state updates, as they might
         * trigger changes to it. */
        uint32_t was_masked;
        _DISABLE_IRQS(was_masked);
        *p_seqnum = m_net_state.seqnum++;
        _ENABLE_IRQS(was_masked);

        return NRF_SUCCESS;
    }
    else
    {
        seqnum_block_allocate();
        return NRF_ERROR_FORBIDDEN;
    }
}

My question is, why is it happening that (m_net_state.seqnum > m_net_state.seqnum_max_available), which is causing the publish to fail. and how can i recover from this? Powering down and powering the ANNA-B112 does not help. The only way i have recovered from this is to unprovision the server, and provision again. But this is not practical for the application.

Thank you in advance for your assistance.

Regards, 

Nishant

[Hung Bui]

Hi NIshant, 

Could you let me know the SDK version you are using ? 

The reason you are getting this issue is that the IV update was not performed resulting in the sequence number reached max sequence number. And the root cause was that your device was sleeping most of the time and didn't catch or didn't perform an IV index update.

Normally a mesh node is designed to stay active and listen all the time. For your use, a LPN node is a better solution. 

I'm checking with the team to see what would be the best solution for this. 

[nish]

Hi Hung, 

Since the mesh node should stay powered all teh time, Would calling nrf_mesh_disable() and then putting the NRF to sleep (as opposed to power off), and then wake up from external interrupt and nrf_mesh_enable() work? Will the NRF do a chip reset on wake up? or will it continue from where it went to sleep?

Thus hopefully meaning the chip will not reset, and hence the sequence number will not reach the maximum so quickly?

[Hung Bui]

That can help a little bit as the sequence number will not be increased on each reset a NETWORK_SEQNUM_FLASH_BLOCK_SIZE. But it will still end up in the same situation if you don't keep the device long enough to receive and perform IV index update. 

If you plan to have the device running on battery, you should use set it up as LPN node instead of normal node. 

I'm still waiting for the reply from our team. 

[nish]

Thanks Hung, 

I initially started from the Light Switch example and have built my firmware a long way from there. 
My question is, that i see the LPN has only an "experimental" example. What exactly would be involved to now convert my project to use LPN instead of normal?

[Hung Bui]

Hi Nishant, 

From SDK v4.1 LPN has been pulled out of experimental. 
When it's experimental it meant that it's not fully tested and not qualified. But please use the latest SDK v4.1 if possible. 

[nish]

Hi Hung, 

I have been reading on the LPN feature and network topology that include LPN's & normal nodes. 

From my understanding, in order to use the LPN feature, you are required to have a Friend node. This friend node can for example be the light switch server example , does this mean that the friend node will be permanently powered?

In my use case, I actually have one Client node and three servers nodes. All nodes are supposed to run off a battery and should be sleeping and wake up periodically to send a message to the client. 

If I understand correctly, in order to use LPN feature, I will need one friend node that is permanently powered and that friend node has a friendship with each server node as well as the client node. 
Please advise if this is the correct network topology for my use case?

Thanks. 

[Hung Bui]

Yes, your understanding is correct. The friend node has to be main powered. 

But I'm not sure why you need a mesh network if your network is comprised of only a "central" node and a few "server" nodes that inside the central's range. It's a star network and you can easily do it with normal Bluetooth Low Energy. This would make it much more simple. And the client/central node can run on low energy as well.