In part 8 on this series on the Garmin InReach Mini 2 and the Iridium network behind it, I’ve assembled a summary of the few pieces of technical background information that is available on the Internet. Iridium offers a number of different services such as voice telephony and SMS, and quite a bit of the higher layer protocols seem to be adapted from GSM. Looking at the messaging service provided by Garmin’s InReach Service, I came to the conclusion that it is most likely NOT based on Iridium SMS. Instead, it looks like the service might be based on the Short Burst Data (SBD) service. I can’t be sure because there is no documentation, but here’s how SBD works:
Based on the description of SBD in this video, starting at around 27 minutes (switch on auto-generated English subtitles in case you don’t speak German), and some further resources that can be found on the Internet with a search engine, here’s my take on it:
Outgoing Messages
There are several different types of data packets in Iridium, and ‘sub-type 2’ carries a lot of different services. Sub-type 09.02, for example, carries SMS (see video linked above just before the 27 minutes mark). Sub-type 76.08 contains Short Burst Data (SBD) frames. As shown in the screenshot at the beginning of this post (taken from the video), a single SBD message can be up to 1960 (MO) and 1890 (MT) bytes in length. That’s more than enough to hold the maximum number of 160 characters of an InReach message, plus all the destination addresses (eMail addresses, InReach addresses, mobile phone numbers) that a message should go to. And in addition to all of this, the GPS coordinates can also be put inside. Sending bytes over Iridium seems to be quite expensive, though. The video mentions $1 per kilobyte, and I also couldn’t find anything cheaper when looking around a bit.
If InReach used SBD, then I would understand why predefined messages with predefined distribution lists are included in the monthly fee, while ‘normal’ messages will cost extra beyond the monthly allowance: Predefined messages with distribution lists could just require a few bytes, as the content and the distribution addresses do not have to be sent. The only things required would be an ID that corresponds to predefined message and perhaps the GPS coordinates. A server on the ground would then add the rest and send the message to all recipients.
Incoming Messages
Incoming messages are ‘paged’ by the satellite on a Ring Alert channel. I guess ‘ring’ is a reference to a phone ringing for an incoming call. Here, things get a bit tricky, because Iridium needs to know where the device to be alerted is located. For that, the system needs to be aware of the approximate position of each active device. For an incoming message, the network then needs to calculate which satellite currently covers that location and over which spot beam(s) to send the ring alert. The ring alert channel uses a bit more power than other Iridium channels, so chances are higher the alert is received. On the device side, things are also a bit tricky, because observing the ring alert channel requires a lot of power. See my previous post on power consumption for details. InReach devices seem to observe the ring alert channel for 10 minutes after a message is sent and then go back to deep sleep. Once an hour, the device wakes up and polls the network for waiting SBD messages. When polling for waiting SBD messages, the device gets either an empty response if no messages are waiting, or one SBD message together with the number messages that are still waiting. The device then needs to poll each additional message separately.
And one more thing about the ring alert: The Internet knows that in case a device does not answer to a ring alert, another one will be sent 13 seconds later. If the second alert is also not answered, the SBD message will be put in the message waiting queue.
Forwarding SBD Messages to the Internet
It’s important to understand that Iridium just forwards SBD messages to an external server, it doesn’t do anything with the content inside. One way of forwarding an SBD message is to send an email for each (!) SBD message. The destination eMail address is linked to the IMEI of the device that has sent it. The second method is to open an TCP socket to a server on the Internet and deliver the SBD message that way. The IP address and TCP port is linked to the IMEI of the device that sends the message. So if Garmin’s InReach uses SBD, they must have a server somewhere on the Internet that receives the SBD messages from devices. The server will then do its service magic around it, i.e. distribute the message content via eMail, SMS, or as an outgoing SBD message back to Iridium. This is completely outside of Iridium’s network domain. Fun fact: Check Out Amazon’s AWS Iridum CloudConnect service for further info.
Some More Speculation
So, again, as far as the InReach service is concerned, all my musings here are pure speculation, but it fits into how SBD messages work. The important point here is that InReach is separate from Iridium, and the Internet links the Iridium satellite service with Garmin’s InReach messaging service. You better hope that both ends of that conversation over the Internet are super redundant. Unfortunately, no documentation is available, so it’s impossible to assess how fault redundant the setup is. But I could find out at least one thing: I could have a look where the eMails came from that an InReach message has triggered. Here’s a part of an SMTP header of such an eMail:
Received:from o1.inreacheml.garmin.com ([167.89.63.8]) by xxxxx (xxxx [xxx.xxx.xxx.xxx]) with ESMTPS (Nemesis) id xxxxxxxxxxxx for xxxsxxx.de; Tue, xx Nov 2022 13:24:58 +0200
When doing a ‘whois’ on the IP address, one gets the following:
OrgName: SendGrid, Inc.
OrgId: SENDG-12
Address: Twilio, Inc.
Address: 1801 California Street
Address: Suite 500
City: Denver
Doing a traceroute to that IP address (from Germany) reveals the following:
traceroute 167.89.63.8
traceroute to 167.89.63.8 (167.89.63.8), 30 hops max, 60 byte packets
1 fritz.box (xxx.xxx.xxx.xxx) 56.842 ms 58.092 ms 58.078 ms
2 xxxxxx.dip0.t-ipconnect.de (xxx.xxx.xxx.xxx) 72.479 ms 73.865 ms 73.853 ms
3 217.5.115.130 (217.5.115.130) 73.835 ms 74.009 ms 73.997 ms
4 217.5.115.130 (217.5.115.130) 73.981 ms 73.970 ms 74.442 ms
5 * * *
6 ae2.3610.edge1.Tustin1.level3.net (4.69.160.101) 222.586 ms 155.239 ms 172.317 ms
So based on the round trip time of hop 6, it’s definitely coming from the US. But SendGrid is not Garmin, so that doesn’t say anything about the location of Garmin’s core InReach infrastructure. But it does say that Garmin doesn’t deliver the email itself, it uses a 3rd party for this.
SDM Modems
And one final piece of technical detail I could find: There are SBD modem chips on the market and some people speculate that one of these is used in Garmin InReach devices. I couldn’t find a definite source, however, so this is highly speculative. But the interesting point here: These SBD modems send, receive and poll for messages with…. AT commands!
Summary
So here we go, that’s the technical background information I could find. Despite being all speculative, it gives me a much better idea of how my messages are probably delivered over the Iridium network to a Garmin server, back to Iridium or over the Internet to an SMS or eMail recipient.
And this concludes my InReach blog post series for the moment. Iridium and InReach are very interesting projects that have sparked my imagination. Obviously, though, I hope that I will just use my satellite messengers for educational purposes and that I will never need them for emergency communication when all terrestrial networks around me have failed. I’m keeping my fingers crossed!