IPoUGRS is a protocol for transmitting IP datagrams over the GSM ring signal. Eight phones ring in parallel — a ring is a 1, silence is a 0 — producing one octet per time slot at a theoretical maximum of 1.6 bits per second. The caller hangs up before anyone answers. This is not considered rude. It is the physical layer.
The protocol is specified as an IETF Internet-Draft (draft-papadopoulos-ipougrs-00 ) in the tradition of RFC 1149 (IP over Avian Carriers) and RFC 2324 (HTCPCP).
Overview
| Aspect | Details |
|---|---|
| Protocol | Synchronous, parallel, octet-oriented over GSM signaling plane |
| Throughput | 1.6 bps (baseline), 0.8 bps (with Hamming FEC), 2.67 bps (5G optimized), 10.67 bps (SIP/32-channel) |
| Error Correction | Extended Hamming(8,4) — single-bit correction, double-bit detection |
| Hardware | 8x GSM transmitters + 8x GSM receivers per peer, or 32x SIP DIDs (recommended) |
| Duplex | Full-duplex by construction |
| Synchronization | NTP or GPS-disciplined oscillator |
| Slot Duration | 5s (VoLTE), 10s (2G GSM), 3s (SIP/VoNR) |
| Max Payload | 255 octets per frame (~21 minutes at 1.6 bps, ~3 minutes at 10.67 bps) |
| Draft | draft-papadopoulos-ipougrs-00 |
How It Works
Each endpoint deploys 8 parallel phone receivers and 8 transmitters. To transmit an octet, the sender examines each bit position from MSB to LSB — if the bit is 1, it places a call to the corresponding receiver and hangs up before anyone answers (FLASH HANGUP). If the bit is 0, no call is placed. The receiver observes which phones rang during the time slot and assembles the octet.
Because each peer independently operates a transmitter bank and a receiver bank, transmission in both directions proceeds simultaneously — IPoUGRS is inherently full-duplex.
Sender (8 GSM modules) Receiver (8 phones)
┌───┐ ┌───┐ ┌───┐ ┌───┐ ┌───┐ ┌───┐ ┌───┐ ┌───┐
│ T0│ │ T1│ │ T2│ │ T3│ │ R0│ │ R1│ │ R2│ │ R3│
│ 1 │ │ 0 │ │ 1 │ │ 0 │ GSM │ R │ │ │ │ R │ │ │
└───┘ └───┘ └───┘ └───┘ ──────► └───┘ └───┘ └───┘ └───┘
┌───┐ ┌───┐ ┌───┐ ┌───┐ ┌───┐ ┌───┐ ┌───┐ ┌───┐
│ T4│ │ T5│ │ T6│ │ T7│ │ R4│ │ R5│ │ R6│ │ R7│
│ 0 │ │ 0 │ │ 1 │ │ 0 │ │ │ │ │ │ R │ │ │
└───┘ └───┘ └───┘ └───┘ └───┘ └───┘ └───┘ └───┘
Byte transmitted: 10100010 = 0xA2
SIP/VoIP Implementation (Recommended)
The reference implementation uses physical GSM modules, but the recommended deployment path is SIP trunks with DID numbers. This is not a compromise. It is strictly better.
32 DID numbers from a SIP provider cost approximately €5/month. 32 physical SIM cards cost hundreds of euros plus ongoing line rental. The SIP approach is purely software — Asterisk or FreePBX running on the same Raspberry Pi as everything else, no hardware beyond an internet connection.
More importantly, N is no longer constrained by the number of phones on your desk. Want 32-bit word width? Buy 32 DIDs. The throughput scales linearly:
Throughput = N / SLOT_DURATION
N=8, 3s slots (VoNR): 2.67 bps — original spec
N=32, 3s slots (VoNR): 10.67 bps — SIP reference implementation
N=64, 3s slots (VoNR): 21.33 bps — for the truly committed
At N=32 with SMAZ2 compression, a typical short text message fits in a single frame. This is not fast. It is faster than a pigeon.
SIP Reference Stack
MeshSat Bridge
│
▼
Asterisk / FreePBX
│
├── SIP trunk (internet) ──► SIP provider DIDs ──► IPoUGRS
│
└── PSTN gateway (analog) ──► telephone network ──► IPoUGRS
(survives internet outage)
The PSTN fallback path is the serious part. SIP trunks route over internet. An Asterisk box with an analog line (FXO card, ~€30) routes over the public telephone network. The telephone network survives events that kill internet connectivity. Section 8 of the RFC does not elaborate on what those events are. Readers are encouraged to consult general news sources.
Section 9.1 Revisited
The original RFC warns that IPoUGRS call patterns are indistinguishable from robocallers and will be blocked by carriers within hours. SIP providers are considerably more tolerant of automated call patterns, particularly when you own the DIDs on both ends. The authors consider this a material improvement over the physical SIM approach, while acknowledging that “considerably more tolerant” is doing significant work in that sentence.
Frame Format
Each IPoUGRS frame consists of:
| Field | Size | Description |
|---|---|---|
| Preamble | 1 octet | 0xAA — alternating bit pattern for slot alignment |
| Version | 1 octet | Currently 0x01 |
| Flags | 1 octet | Reserved, must be zero |
| Sequence Number | 2 octets | Frame loss detection |
| Length | 1 octet | Payload length (max 255 octets) |
| Payload | variable | The actual IP datagram |
| FCS | 1 octet | CRC-8 frame check sequence |
MeshSat Integration
IPoUGRS is a channel adapter in MeshSat — the open source multi-channel communications bridge. This means a message arriving on any other MeshSat channel (Iridium SBD, Meshtastic LoRa, APRS, MQTT, SMS, TAK/CoT) can be routed via IPoUGRS when all other channels are unavailable.
In practice this means: if the internet is down, satellite is down, and LoRa mesh has no coverage — but the telephone network is still up — MeshSat will route your message over unanswered phone calls.
The authors consider this the most over-engineered fallback channel in the history of emergency communications. It is listed in the MeshSat channel matrix as experimental.
Use Cases
IPoUGRS targets scenarios where the IP data plane is unavailable but GSM circuit-switched signaling remains operational. Mobile networks route voice calls through the MSC via SS7, while IP data traverses the SGSN/GGSN — architecturally distinct paths. Events that disable the data plane do not necessarily disable the signaling plane.
Secondary use cases include emergency communications, transmission of very short messages, and educational demonstrations of OSI layer concepts in which the physical layer is made, perhaps excessively, concrete.
Kickstarter
The hardware kit is coming to Kickstarter.
Read the Draft
The full Internet-Draft is available here:
- HTML version — formatted, readable in browser
Status
| Milestone | Status |
|---|---|
| Internet-Draft written | Done |
| SIP/VoIP reference implementation design | Done |
| MeshSat channel adapter spec | Done |
| Kickstarter campaign | Pending |
| Proof-of-concept build (SIP) | Pending |
| Proof-of-concept build (physical GSM) | Pending |
| YouTube video | Pending |
| IETF submission | Pending |
| Field study publication ([PAPADOPOULOS2026]) | Pending |
Affiliated with Nuclear Lighters Network and MeshSat . No pigeons were involved in this work — those are covered by RFC 1149 . One was consulted, but was unavailable.
