Satellite NTN bills your data by the byte, taxes every transmission in energy, and delivers in windows, not milliseconds. Here's how those constraints reshape a product.
The development SIM that ships with a Nordic nRF9151 satellite kit carries a 50 KB data allowance, and Deutsche Telekom's NTN service bills it byte by byte. Wrap a 28-byte sensor reading in JSON, with field names, quotes, and brackets, and one message can spend 200 bytes to deliver 28 bytes of information. Every one of those extra bytes comes out of the budget. On 50 KB, sloppy encoding is the difference between a device that reports for months and one that goes quiet before the pilot ends.
That billing detail does more to shape good NTN firmware than anything on a datasheet. This post walks through the constraints that actually change product design: the message budget, payload encoding, the energy bill, latency, and what the recently frozen 3GPP Release 19 will eventually relax. It assumes you're past the "what is NTN" stage. If you're not, start here.
On terrestrial cellular, data volume is an afterthought. On NTN it's the first line of the spec, because the transport itself is narrow: on Deutsche Telekom's NB-IoT NTN service you get UDP, no TCP, at physical rates of 1 to 2 kbps. Every message also carries the 28-byte UDP/IP header, a fixed cost worth designing around: treat it as part of each message's price, and let batching amortize it.
On NTN, every byte is billed and every message carries a 28-byte header. Spend the budget on readings, not on wrappers, and make each message carry as much as it usefully can.
The design consequences follow directly. Report by exception rather than on a timer where you can. Aggregate on the device: one message carrying six hours of readings pays the header once instead of six times, and costs one transmission's energy instead of six. And decide your reporting cadence during product design, not after deployment, because the connectivity budget is a real bill of materials line, the same way the battery is.
None of this is exotic. Products already ship inside these limits on exactly this stack. The Digitanimal SAT Collar, a livestock tracker certified with Deutsche Telekom on Skylo, is a working example of a product designed around small, infrequent, high-value messages.
If you've built on ESP32 over Wi-Fi, you've probably been sending JSON without thinking about it. Over satellite, that habit is the first thing to go. Field names, quotes, and brackets are bytes you're paying for, and they carry no information the server couldn't reconstruct on its own.
The pattern that works is raw binary with a fixed layout. The device packs values into bytes in an agreed order, transmits, and the decoding logic lives server-side where bytes are free. Your firmware stays small, your messages stay small, and when you need to add a field you version the layout instead of inflating every message.
This is the pattern Blynk ships in its Deutsche Telekom NTN integration. The device sends raw bytes, and a JavaScript Data Converter on the IoT platform side unpacks them into datastreams. If you'd rather not hand-write the bit-shifting, the AI Platform Assistant built into the Blynk Console can draft that converter code from a description of your payload. Past that point, the rest of the low-code stack (dashboards, mobile apps, automations) has no idea the data came from orbit. The decode step is the only place in the pipeline that knows a satellite was involved, which is exactly where you want that knowledge concentrated.
Everyone knows satellite costs more power. Hard public numbers arrived in June 2026, when Qoitech measured an nRF9151 on a live NTN network against the same hardware on terrestrial cellular:
Three design rules fall out of those three lines. First, registration is nearly as expensive as a transmission, so avoid re-registering: Qoitech's setup used power saving mode with a one-hour TAU to keep the device attached between messages. Second, since each transmission carries a heavy fixed cost, batching readings pays twice, once in bytes saved on headers and again in milliwatt-hours. Third, the GNSS fix costs more than half a transmission by itself, so a tracker that fixes its position more often than it reports is burning battery for data it throws away.
For product planning, take the battery-life model from your cellular product and assume roughly an order of magnitude more energy per network event. If the numbers still close, you have an NTN product. If they only close at one message per day, that's your reporting rate, and the product design has to make one message per day feel like enough.
On the geostationary path Blynk's Deutsche Telekom integration uses, an uplink typically takes seconds to a couple of minutes to travel from device to dashboard, anywhere from about 5 seconds to 120 depending on connection quality. That's fine for monitoring, alerting, and tracking. It rules out real-time control, and it changes UI design in a subtle way: when data can be minutes old on arrival, showing message age matters more than showing a live-feeling gauge.
LEO constellations will tighten this, but today they add a different constraint: intermittency. Sateliot, for example, launched its first four commercial satellites in 2024, has five more planned for 2026, and a 16-satellite expansion funded behind them. Until constellations fill out, a LEO device sees passes, not coverage, and firmware has to hold data and retry rather than assume the network is there.
Release 19, frozen in December 2025, addresses this directly. It adds store-and-forward operation for IoT NTN, letting the satellite buffer your data when it has no ground link and deliver it later, plus TDD support for NB-IoT NTN. Store-and-forward moves the buffering burden from your firmware to the network, which is a genuine architectural shift for asset tracking and environmental sensing. But standards freeze years before modems and networks ship them. Design for today's constraints and treat Release 19 as the direction of travel rather than the spec you build against.
One more reason to build against the constraints rather than any single network: the proprietary and 3GPP satellite worlds are converging. Iridium is bringing its network to the 3GPP standard with NTN Direct, now in on-air trials with beta planned for 2026, and Deutsche Telekom is already an integration partner. Myriota runs a proprietary track and a 3GPP track side by side. Blynk's satellite partnerships already span this landscape, Deutsche Telekom on the 3GPP path, Myriota and Iridium (through Ground Control's RockBLOCK line) on the proprietary one, so the platform side of your product doesn't have to bet on a winner. Wherever the convergence lands, the same design discipline applies regardless of whose satellites carry the message.
That discipline is the durable part. Block-sized messages, binary payloads decoded server-side, an energy model with margin, and tolerance for delivery windows will serve a product on any of these networks, including ones that don't exist yet. A product designed to the constraints ports; a product designed to one network's quirks doesn't.
Nothing else on the platform side changes shape to accommodate orbit. Once the decode step turns raw bytes into datastreams, you're running the same production stack as any cellular or Wi-Fi fleet: role-based access control and user management for operations teams, firmware updates over Blynk.Air when the device has a terrestrial link (nobody pushes firmware through a 50 KB satellite budget), and white-label native mobile apps and a Mobile SDK at Enterprise tier, all on SOC 2 Type II certified infrastructure.
If you want to feel the constraints firsthand, the nRF9151 with an NTN SIM is the most direct way in, and Blynk's supported hardware and connectivity options already cover the decode-and-dashboard side, from ESP32 builds on the ESP-IDF SDK to Nordic modems over NTN. Start with the free tier and see what your product looks like on a 50 KB budget. The platform decoding those bytes is the same one running production fleets.
.png)
