Challenge One: match a network to small messages

Telnet’s Challenge One launched from Baikonur on a Soyuz-2 rocket on 22 March 2021. The company’s launch account describes connecting ground objects through LoRa radio technology. The archive identifies the spacecraft as ChallengeOne. Its purpose was associated with the Internet of Things: small devices exchanging useful measurements or status messages. That is a different service problem from delivering continuous video or ordinary broadband internet.

The launch report also contains forecasts about design life and the future connected-device market. Those are historical expectations, not measurements of how the mission subsequently performed. A useful lesson can explain the design aim without inheriting every promotional claim. Evaluate a communications system through delivered messages, delay, energy use and availability for the intended devices.

Imagine 200 sensors, each producing a 24-byte reading once per hour. Their raw payload totals 4,800 bytes each hour. Over a day that becomes 115,200 bytes. This invented example counts only application data. Device identifiers, timestamps, error checks, radio framing and retransmissions increase the actual amount sent. The arithmetic is a starting point for planning, not a complete radio link budget.

Now double the reporting rate while keeping the message size and device count unchanged. The offered payload doubles as well. More frequent readings might be useful, but they also require more transmission opportunities and energy. If several sensors attempt to transmit together, the network must handle competing messages. A small data volume does not automatically mean every device can send at any moment.

Size the traffic before promising a service

A remote tank sensor might tolerate a periodic update, whereas a rapidly changing hazard could require a much shorter delay. State the required update interval and acceptable loss before judging the system. Retry policies must also make sense: retransmitting an old observation repeatedly can consume capacity without improving the freshness of information available to the user. Keep observation identifiers so the receiving system can recognize repeats.

Challenge One connects local engineering capability to these practical network choices. The same lesson applies when a team evaluates any satellite IoT proposal: identify who measures, what is transmitted, how often it is needed and how the result reaches an application. A successful launch enables testing those questions in space. It does not by itself establish a continuous service or a particular number of supported customers.