Question regarding the MQTT-SN sleep mode

[Franz Schnyder]

Hello

I’m working on implementing a MQTT-SN client on Arduino[1] and a MQTT-SN gateway[2] on raspberry pi, which communicate over a nRF24L01+ Transceivers. I now want to implement the sleep mode and have questions regarding the sleep mode I myself could find the answers in the MQTT-SN Protocol Specification:

1) How does the gateway send the buffered messages to the client when the client does a CONNECT out of the Asleep mode? I understood the sequence when the client does a PING REQ out of the Asleep mode, where the gateway sends all buffered messages and terminates them with a PING RES message. Does the gateways send the buffered message when he receives the CONNECT message and terminates them with a CONNACK message analogous to the PING REQ and PING RES sequence?

2) When a client send a CONNECT out of the Asleep mode which field are required or considered? Does the ClientId have to be included and what happens if it does not match the ClientId of the initial CONNECT? Can the Will flag be set and the gateway must do the WILLTOPICREQ and WILLTOPIC round-trips also when he receives the CONNECT out of the Asleep mode.

Thanks for any insight.

Regards

Franz

 

[1] https://github.com/bittailor/BtMqttSn#btmqttsn

[2] https://github.com/bittailor/BtEmbedded#btmqttsngateway

[AlemV]

1) How does the gateway send the buffered messages to the client when the client does a CONNECT out of the Asleep mode? I understood the sequence when the client does a PING REQ out of the Asleep mode, where the gateway sends all buffered messages and terminates them with a PING RES message. Does the gateways send the buffered message when he receives the CONNECT message and terminates them with a CONNACK message analogous to the PING REQ and PING RES sequence?

I have asked the same question some time ago, but had never got an answer. I solved this problem exactly as you described: the gateway receives the CONNECT message, sends the buffered PUBLISH messages, and ends with the CONNACK message[1].

When a client send a CONNECT out of the Asleep mode which field are required or considered? Does the ClientId have to be included and what happens if it does not match the ClientId of the initial CONNECT?

I suppose the ClientId field have to be included, otherwise how does the gateway recognize the client?

Can the Will flag be set and the gateway must do the WILLTOPICREQ and WILLTOPIC round-trips also when he receives the CONNECT out of the Asleep mode.

If the client sets the Will flag in the CONNECT message the gateway have to send the WILLTOPICREQ and WILLTOPIC messages.

Vladimir Alemasov

[1] https://github.com/homewsn/whsnbg/wiki/Sensors-connection-procedures

[Franz Schnyder]

Hi Vladimir

Thanks for your replay. I already nearly gave up on getting any response for my MQTT-SN questions. I hope this is the right group to ask MQTT-SN questions. 

1) How does the gateway send the buffered messages to the client when the client does a CONNECT out of the Asleep mode? I understood the sequence when the client does a PING REQ out of the Asleep mode, where the gateway sends all buffered messages and terminates them with a PING RES message. Does the gateways send the buffered message when he receives the CONNECT message and terminates them with a CONNACK message analogous to the PING REQ and PING RES sequence?

I have asked the same question some time ago, but had never got an answer. I solved this problem exactly as you described: the gateway receives the CONNECT message, sends the buffered PUBLISH messages, and ends with the CONNACK message[1].

Cool so we have at least 2 implementations doing it like that.

When a client send a CONNECT out of the Asleep mode which field are required or considered? Does the ClientId have to be included and what happens if it does not match the ClientId of the initial CONNECT?

I suppose the ClientId field have to be included, otherwise how does the gateway recognize the client?

Since after a successful connect the other messages like PUBLISH or SUBSCRIBE also do not contain the ClientId i use the 'address' or 'node id' of the sensor network as the key to find the client. Therefore I thought I also could use that on the connect from sleep since in my sensor network the client keeps the same 'node id' even when it sleeps, but maybe that is not the case in all possible sensor networks. But I think at least as long as a client is in the Active state it should not change its  'address' or 'node id' since this is the only key to identify it. 

Can the Will flag be set and the gateway must do the WILLTOPICREQ and WILLTOPIC round-trips also when he receives the CONNECT out of the Asleep mode.

If the client sets the Will flag in the CONNECT message the gateway have to send the WILLTOPICREQ and WILLTOPIC messages.

Yes sounds reasonable. 

Thanks again for your insides.

Regards

Franz 

[AlemV]

Hi, Franz,

 

When a client send a CONNECT out of the Asleep mode which field are required or considered? Does the ClientId have to be included and what happens if it does not match the ClientId of the initial CONNECT?

I suppose the ClientId field have to be included, otherwise how does the gateway recognize the client?

Since after a successful connect the other messages like PUBLISH or SUBSCRIBE also do not contain the ClientId i use the 'address' or 'node id' of the sensor network as the key to find the client. Therefore I thought I also could use that on the connect from sleep since in my sensor network the client keeps the same 'node id' even when it sleeps, but maybe that is not the case in all possible sensor networks. But I think at least as long as a client is in the Active state it should not change its  'address' or 'node id' since this is the only key to identify it. 

 I use an IP address and port of the client's UDP connection to identify the clients between CONNECT and DISCONNECT messages. But after the client sends the DISCONNECT message, it may change an IP address or/and port. So I am needed to use ClientId in all CONNECT messages.


I have another difficulty. My wireless sensors are based on the microcontrollers with a fairly limited ROM and RAM capacity. Therefore MQTT-SN client should be programmed as a simple state machine with the pre-defined states. This means that the client have to know what it should do each time it receives the message from the gateway: send the response message to the gateway or go to the sleep mode.
Everything seems ok, except the SUBACK message from the gateway. It is unclear  whether the client may continue the initial connection procedure or it must wait for the PUBLISH messages from the gateway. I see two options to resolve this problem:
1. The SUBACK and PUBLISH messages should have some additional information about the number of buffered messages that a gateway has in its outbound queue.
2. The gateway should not send the PUBLISH messages in the same CONNECT-DISCONNECT session, where it receives the SUBSCRIBE message.

Have you another ideas?

Thanks and

Best Regards,
Vladimir

[Franz Schnyder]

 

I have another difficulty. My wireless sensors are based on the microcontrollers with a fairly limited ROM and RAM capacity. Therefore MQTT-SN client should be programmed as a simple state machine with the pre-defined states. This means that the client have to know what it should do each time it receives the message from the gateway: send the response message to the gateway or go to the sleep mode.
Everything seems ok, except the SUBACK message from the gateway. It is unclear  whether the client may continue the initial connection procedure or it must wait for the PUBLISH messages from the gateway. I see two options to resolve this problem:
1. The SUBACK and PUBLISH messages should have some additional information about the number of buffered messages that a gateway has in its outbound queue.
2. The gateway should not send the PUBLISH messages in the same CONNECT-DISCONNECT session, where it receives the SUBSCRIBE message.

Have you another ideas?

I'm not sure I correctly understand this. I think a SUBACK from the gateway is the answer to a SUBSCRIBE initiated from the client so why should there be a SUBACK during the connection procedure? I also think that there might not be a PUBLISH on the just subscribed topic at all so I don't see a need to wait for a PUBLISH. And for 

1.) I don't see any dependency from SUBACK to the buffered messages. And I think if the send out of the buffered messages is implemented that the PINGRESP or the CONNACK mark the end of the buffered messages then there is no need to include the number of remaining buffered messages in the messages.

2.) I think a gateway can not know if client will ever go to sleep again and therefore can not hold back the PUBLISH messages while the client is Active.

But maybe I did not grasp your problem yet.       

Regards

Franz 

[AlemV]

By "the initial connection procedure" I meant the sequence of commands when the sensor is first connected to the gateway, beginning the CONNECT message and ending the DISCONNECT message. You can see this sequence on the top picture here[1]. One of commands from the sensor is a SUBSCRIBE. The gateway answers with the SUBACK message. At this time for the sensor there is an uncertainty - whether to wait for the PUBLISH command from the gateway (if the gateway has the actual data with the Retain flag) or to continue initialization procedure and then go to sleep.

[1] https://github.com/homewsn/whsnbg/wiki/Sensors-connection-procedures

Best Regards,
Vladimir