Skylo Messaging Protocol

SMP Document v1.8: Nov 13, 2023

SMP Protocol Version: 2

‍

Purpose : This document covers SMP Message structure for messaging, that is exchanged over satellite between Mobile app using compatible D2D device and cloud platform. SMP is a message structure designed for handheld devices to send uplink & Downlink messages over Satellite Network.

Satellite network uses a Narrow band network and to make sure the devices are making efficient use of satellite resources and there is an optimal usage of bandwidth, this protocol was designed.

Disclaimer : This document is shared under strict NDA and should not be shared otherwise. This protocol was create to optimise the entire satellite network bandwidth.

SMP Protocol Version: 2

Overview

This specification uses SMP protocol version as 2

This document covers SMP Message structure for messaging, that is exchanged over satellite between Mobile app using compatible D2D device and cloud platform. Application End points (mobile/platform) shall support both acknowledge and non-acknowledgement message type.

SMP Header Structure

SMP header contains standard fields common to all messages. Significance of each field is explained below. These are application level message exchanges and hence SMP payload parsing and any retry mechanism is solely managed for the end-points.

Data Structure: [SMP Header(8 bytes)]  + [Datagram Payload]

Endianness: Big Endian

SMP Version and Flags

This field represent SMP version and Control flags information in 1 byte. Bits are represented from B7 to B0 (Higher Nibble to Lower Nibble)

• First 5 bits (B4 to B0) represents Message protocol version.
• Remaining 3 bits are used for control flags.
  • B5 (6th bit) used for confirm and non-confirm message. That informs the system if the application is expecting Network Acknowledgement
    • 0 - Non-Confirm
    • 1 - Confirm (When this flag is set, the acknowledgement will be sent through SMP Message Type “NetworkAck”. Explained in section ContentNetworkAck below
  • B6, B7 bits are currently reserved for Future purposes. For now these values will always be 0.

Examples

• If protocol version is 2 and application is not expecting the ack, then the this byte will be formed as below
  • Version Bits (B4-B0): 00010
  • Network Ack Bit ( B5): 0
  • Bits: 0 0 0 0 0 0 1 0 ==> Byte Value: 0x02
• If protocol version is 2 and application is  expecting the ack, then the this byte will be formed as below
  • Version Bits (B4-B0): 00010
  • Network Ack Bit ( B5): 1
  • Bits: 0 0 1 0 0 0 0 1 ==> Byte Value: 0x22

SMP Message Types

APN Mapping

• During customer onboarding, each customer is assigned unique APN(a.k.a app-id) for it's application.
• During SIM activation, each IMSI is activated for an APN in Skylo Core Network.
• DMP maintains the mapping of APN and its associated protocol (SMP or Non-SMP) as part of its Register Notification APIs. This mapping is used to decide whether Upstream data to be parsed and Downstream data to be encoded in SMP format or not.

Skylo assigns APN to each customer application. During sim activation process each IMSI will be mapped to their APN. SIM profile will carry the APN identifier. This APN identifier will be used as App ID.

‍

Content Definitions

Content Data for different message types shall be formatted as per the order defined in this section

Note: All the content structures will follow “Big Endian” format.

ContentTextMessage

ContentLocation

ContentTextMessageAndLocation

ContentDeliveryReceipt

ContentReadReceipt

ContentSendReceipt

ContentUndeliveredReceipt

ContentOpenSOS

ContentTextMessageAndOpenSOS

ContentCloseSOS

Empty Payload

‍

ContentCheckIn

ContentPredefinedMessage

ContentOtherMessages

If the application has a specific requirement of message type, which doesn’t fit into any of the above content types. Application owner can use this type to customise the message content according to their needs.

ContentNetworkAck

ContentHeartBeat

ContentUpdateIMSI

Message Control Flag

Message control flag is a 1 byte field. We use a bit or combination of bits to represent certain details about the content. Bits here are named B7 to B0 (Higher Nibble to Lower Nibble)

• B0, B1 represents Receipt
  • 0 - No Receipt required
  • 1 - Only Delivery Receipt Required
  • 2 - Delivery and Read Receipt Required
  • This value can be determined by User Settings.
• B2 represents GPS Fix value. This value must be updated for ContentLocation, ContentOpenSOS, ContentCheckIn types. For other message types, this value defaults to 0.
  • 0 - GPS Fix is 0
  • 1 - GPS Fix is 1
• B3 to B7 are reserved - Default to 0

Example

• User expecting a read receipt for the same over the satellite.
  • B0, B1 should map to value 2
  • B2 - B7 default value
  • Bits: 0 0 0 0 0 0 1 0 ==> Byte Value: 0x02

Message Id Generation

SenderID - OriginalEventTimeStamp - Message Counter
Bytes: 7 + 1 +  4 + 1 +  2
Sample Message ID: ABCDEABCDE-FFFFFFFF-AAAA

Example

• Sender User ID : 919999999999, Time stamp: 1657127077 (2022-Jul-6, 17:04:37 GMT), Message Counter : 120,
  • Sender ID: 919999999999 ==> 0x00D63445EFFF
  • Time stamp: 1657127077 ==> 0x62C5C0A5
  • Message Counter: 120 ==> 0x0078
  • Hiphen/Minus : 45  ==> 0x2D
  • Message ID: 0x00D63445EFFF 2D 62C5C0A5 2D 0078

• Sender User ID : 327700040349753, Time stamp: 1657127077 (2022-Jul-6, 17:04:37 GMT), Message Counter : 120,
  • Sender ID: 919999999999 ==> 0x012A0A9C7F7839
  • Time stamp: 1657127077 ==> 0x62C5C0A5
  • Message Counter: 120 ==> 0x0078
  • Hiphen/Minus : 45  ==> 0x2D
  • Message ID: 0x012A0A9C7F7839 2D 62C5C0A5 2D 0078

‍

END