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

AspectDetails
ProtocolSynchronous, parallel, octet-oriented over GSM signaling plane
Throughput1.6 bps (baseline), 0.8 bps (with Hamming FEC), 2.67 bps (5G optimized), 10.67 bps (SIP/32-channel)
Error CorrectionExtended Hamming(8,4) — single-bit correction, double-bit detection
Hardware8x GSM transmitters + 8x GSM receivers per peer, or 32x SIP DIDs (recommended)
DuplexFull-duplex by construction
SynchronizationNTP or GPS-disciplined oscillator
Slot Duration5s (VoLTE), 10s (2G GSM), 3s (SIP/VoNR)
Max Payload255 octets per frame (~21 minutes at 1.6 bps, ~3 minutes at 10.67 bps)
Draftdraft-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

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:

FieldSizeDescription
Preamble1 octet0xAA — alternating bit pattern for slot alignment
Version1 octetCurrently 0x01
Flags1 octetReserved, must be zero
Sequence Number2 octetsFrame loss detection
Length1 octetPayload length (max 255 octets)
PayloadvariableThe actual IP datagram
FCS1 octetCRC-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.

Back IPoUGRS on Kickstarter

Read the Draft

The full Internet-Draft is available here:

Status

MilestoneStatus
Internet-Draft writtenDone
SIP/VoIP reference implementation designDone
MeshSat channel adapter specDone
Kickstarter campaignPending
Proof-of-concept build (SIP)Pending
Proof-of-concept build (physical GSM)Pending
YouTube videoPending
IETF submissionPending
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.