The following sections detail notional diagrams of the sequences involved in sending data from the LTE-M Module up to the Link Labs Cloud Server (“uplink”), and from the Cloud Server down to the LTE-M Module (“downlink”). Please refer to the Command and Response specifications in the following section for exact details and parameters.
Note that the Cloud Server is accessible from any internet enabled device with the proper access credentials, effectively creating a secure wireless Internet-Of-Things network with any LTE-M Module that is in an LTE-M coverage area.
The following sequence diagram illustrates the events involved in the successful uplink of a packet from the host processor through the LTE-M Module to the Link Labs Cloud Server
The sequence begins by the host sending the uplink payload over the UART in the UPLINK_SEND command. Immediately after that, the LTE-M module will respond with an ACK code (typically indicating success) as well as a Packet ID that is to be associated with this uplink attempt instance in the events that follow. As is shown in the diagram, a success code received at this point only indicates a successful queueing of the uplink payload, not a successful delivery to the cloud destination. If an error is returned, then the uplink payload was not able to be queued and the uplink attempt is terminated. The host should at that point determine if it should try again immediately or wait until a later time.
If the UPLINK_SEND command returns a success code, the LTE-M Module will then attempt to push the message up to the cloud server. In a properly configured device this will typically be successful, unless the device is out of the coverage area of the LTE-M network. All further events in this sequence are optional and purely for information purposes or for system optimization purposes (e.g.- the Notify GPIO allows a host processor to enter a low power Wake From Interrupt state).
Regardless of the uplink attempt result, the LTE-M Module will always generate a status report on the uplink attempt. First, the Host Notify flag is set. The expected action from the host at that point is to send the INTERRUPT FLAGS command. The response to that command will be “TX_DONE” if the uplink attempt is finished, or some other flag if a different event has occurred.
If the “TX_DONE” flag is set, the host is expected to send the UPLINK_STATUS command, to find out the result of the uplink attempt. This command will return an ACK Code (success, or an error code indicating the reason for failure), a Packet ID (specifying exactly which uplink attempt instance is being reported on this will match the Packet ID returned in the UPLINK_SEND command) and a Transit Time (how long the uplink sequence took from the reception of the initial UPLINK_SEND command until a confirmation from the Cloud server was received).
Downlink (Always On)
Downlink (Mailbox Mode)
The LTE-M module contains a downlink mode referred to as “Mailbox” mode. In this mode, any internet enabled device can send a message to an LTE-M Module, through the Cloud server. The message is cached in the Cloud server, and remains there until the LTE-M Module is commanded locally to “check its mailbox”. This command triggers the LTE-M module to query the Cloud Server, for the presence of a cached message.
The mailbox mode sequence is very similar to the Uplink sequence. The Mailbox Request is treated as an uplink message, although there is no uplink payload to deliver. Hence, the Mailbox Request update is given a Packet ID and an uplink status report, identically to that of an uplink message. Additionally, if a downlink message is present in the Cloud Server, the “RX_DONE” Interrupt Flag will be set as shown in Figure 4. If the RX_DONE flag is set, the host is expected to send the MESSAGE_RECEIVE command, in order to extract the downlink message.