IP over Unanswered GSM Ring Signals (IPoUGRS)

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 3 October 2026.¶

Copyright Notice

Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.¶

Table of Contents

1. Introduction

The history of networking is, in large part, a history of transmitting Internet Protocol datagrams over substrates that were not designed for this purpose. IP has been transmitted over avian carriers [RFC1149], over avian carriers with Quality of Service extensions [RFC2549], over avian carriers adapted for IPv6 [RFC6214], and over social networks [RFC5514], and over coffee pots [RFC2324]. A recurring theme emerges: if a medium can carry any information at all, someone will eventually carry IP over it.¶

The GSM ring signal has, to date, escaped this treatment. The authors consider this an oversight.¶

A telephone ring is binary. Within a defined interval, a phone either rings or it does not. This observation, while not novel in isolation — it has been the basis of a significant informal communications culture documented extensively in the sociological literature [DONNER2007] — has not previously been formalized into a protocol capable of transmitting arbitrary IP datagrams.¶

IPoUGRS rectifies this.¶

The protocol operates by deploying N parallel telephone receivers at each endpoint, where N is the desired word width in bits. The reference implementation uses N=8, yielding one octet per time slot. A bit is encoded as 1 if the corresponding receiver rings during the slot, and 0 if it does not. The caller hangs up before the call is answered. This is not considered rude. It is the physical layer.¶

The authors note that this architecture is superficially similar to spatial multiplexing schemes employed in modern MIMO wireless systems. The similarity is intentional. The authors further note that IPoUGRS achieves zero inter-channel interference, a property that RF MIMO systems have spent approximately forty years failing to achieve.¶

This document specifies the frame format, timing requirements, error correction scheme, and operational guidelines necessary for interoperable IPoUGRS implementations. Questions regarding why anyone would implement this are considered out of scope.¶

2. Conventions and Definitions

The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

RING:

The condition in which a receiving device produces an audible or electronic alert in response to an incoming call attempt, prior to the call being answered. A RING represents the logical value 1. RING events MUST be distinguished from SILENCE events. In practice, this distinction is made by whether the phone is making noise.¶

SILENCE:

The absence of a RING within a defined SLOT_DURATION. SILENCE represents the logical value 0. SILENCE MUST NOT be confused with a dropped call, a failed call setup, or a general network outage, though the authors acknowledge that the distinction is, under certain operational conditions, immaterial.¶

SLOT:

A fixed-duration time interval during which the presence or absence of a RING is observed. A SLOT produces exactly one bit of information. SLOT boundaries MUST be synchronized between communicating peers. See Section 5.¶

PEER:

An endpoint operating N RECEIVER devices and N TRANSMITTER devices, capable of transmitting and receiving simultaneously. A PEER is full-duplex by construction, a property that the authors believe distinguishes IPoUGRS favorably from several commercial protocols that shall remain nameless.¶

TRANSMITTER:

A device capable of initiating a voice call and terminating it prior to answer. In the reference implementation, this is a GSM module. In more austere deployments, it may be a human being with sufficient patience.¶

RECEIVER:

A device capable of detecting an incoming call attempt without answering it. The RECEIVER observes ring events. The RECEIVER MUST NOT answer the call. If the RECEIVER answers the call, the peer SHOULD hang up and reconsider its choices.¶

FLASH HANGUP:

The act of terminating an outgoing call before the remote party answers. The FLASH HANGUP is the fundamental operation of the IPoUGRS physical layer. It is free. This is the point.¶

CARRIER:

In this document, CARRIER refers exclusively to mobile network operators. The term does not refer to pigeons, homing or otherwise, which are addressed in [RFC1149].¶

3. Protocol Overview

IPoUGRS is a synchronous, parallel, octet-oriented protocol operating over the GSM circuit-switched signaling plane.¶

Communication proceeds as follows. Both peers agree, by out-of-band means, on a set of SLOT_DURATION and EPOCH values (see Section 5). Each peer maintains N=8 TRANSMITTER devices paired with N=8 RECEIVER phone numbers at the remote peer.¶

To transmit an octet, the sending peer examines each bit in the octet from the most significant to the least significant bit. For each bit position i where the bit value is 1, the peer initiates a voice call from TRANSMITTER[i] to the remote RECEIVER[i] at the beginning of the SLOT. The call is terminated via FLASH HANGUP after RING_DURATION seconds. For each bit position i where the bit value is 0, no call is initiated.¶

The receiving peer, during the same SLOT, monitors all N RECEIVER devices. For each RECEIVER[i] that experiences a RING event, bit i is recorded as 1. For each RECEIVER[i] that remains SILENT, bit i is recorded as 0. At the end of the SLOT, the N bits are assembled into one octet.¶

Because each peer independently operates a TRANSMITTER bank and a RECEIVER bank, transmission in both directions proceeds simultaneously. IPoUGRS is inherently full-duplex. This was not originally intended; it emerged naturally from the decision to use separate devices for sending and receiving, which itself emerged from the observation that a phone cannot simultaneously place and receive a call on the same number.¶

Multiple octets are transmitted in successive SLOTs, forming a frame. The frame format is described in Section 4.¶

4. Frame Format

An IPoUGRS frame consists of a preamble, a header, a payload, and a frame check sequence.¶

                     IPoUGRS Frame Structure

  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |  PREAMBLE (0xAA)              |  VERSION      |  FLAGS        |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |  SEQUENCE NUMBER (2 octets)                   |  LENGTH       |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |  PAYLOAD (variable)                                           |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |  FCS (CRC-8)                  |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

PREAMBLE:

The value 0xAA (10101010 in binary) is transmitted first in every frame. The alternating pattern allows the receiver to verify slot boundary alignment before interpreting payload data. If the received preamble does not equal 0xAA, the receiver SHOULD check its clock. If the clock appears correct, the receiver SHOULD check the other peer's clock. If both clocks appear correct, the receiver SHOULD consider the possibility of cosmic ray bit-flip, which at 1.6 bps has a proportionally greater impact than at higher data rates.¶

VERSION:

The protocol version. Currently 0x01. Future versions are anticipated with a degree of optimism the authors find personally surprising.¶

FLAGS:

Eight bits reserved for future use. MUST be set to zero. Implementors who find creative uses for these bits are encouraged to submit a revised Internet-Draft, but are advised that the review process may outlast the utility of the protocol.¶

SEQUENCE NUMBER:

A two-octet unsigned integer, incremented by one for each frame transmitted. Sequence numbers allow detection of lost frames. At 1.6 bps, a frame that takes 10 seconds to transmit is not so much "lost" as "still arriving." Implementors are advised to exercise patience.¶

LENGTH:

Length of the PAYLOAD field in octets. The maximum payload length is 255 octets. Transmitting 255 octets at 1.6 bps requires approximately 1,275 seconds. The authors recommend keeping messages concise.¶

FCS:

An 8-bit CRC computed over the VERSION, FLAGS, SEQUENCE NUMBER, LENGTH, and PAYLOAD fields using the polynomial x^8 + x^2 + x + 1. A frame failing the FCS check SHOULD be retransmitted. The decision to retransmit MUST be weighed against the observation that retransmission doubles the time cost of the error.¶

5. Timing and Synchronization

IPoUGRS is a synchronous protocol. All SLOT boundaries MUST be derived from a common time reference. SLOT boundaries are defined as moments where:¶

   unix_timestamp(t) mod SLOT_DURATION == 0

The RECOMMENDED value of SLOT_DURATION is 5 seconds for VoLTE deployments and 10 seconds for 2G GSM deployments. The choice of SLOT_DURATION MUST account for:¶

1. Call setup latency (1.5-2.5 seconds on VoLTE; 6-8 seconds on GSM; see Section 7).¶
2. RING_DURATION: the time the caller allows the call to ring before FLASH HANGUP. RECOMMENDED value: SLOT_DURATION / 2.¶
3. A guard interval of no less than 0.5 seconds to accommodate network jitter. Implementations that omit the guard interval will encounter difficult-to-diagnose bit errors that the authors have provisionally termed "jitter rot."¶

Both endpoints MUST maintain synchronized clocks. The RECOMMENDED synchronization method is NTP, which achieves approximately 10-50 milliseconds of accuracy under normal internet conditions. The authors acknowledge the irony of requiring internet connectivity to synchronize a protocol designed for use when internet connectivity is unavailable. GPS-disciplined oscillators achieve sub-microsecond accuracy and are RECOMMENDED for deployments where the authors' irony is unwelcome.¶

Implementations SHOULD transmit a SYNC frame — defined as a frame with PAYLOAD equal to the ASCII string "ARE YOU THERE" — at the beginning of each session. The receiving peer SHOULD respond with a SYNC_ACK frame containing the ASCII string "YES". This exchange SHALL constitute proof of synchronization. The authors note that this exchange requires approximately 210 seconds at 1.6 bps and are prepared to discuss alternatives.¶

6. Error Detection and Correction

IPoUGRS operates over an environment subject to several classes of errors:¶

Timing errors:

Caused by network jitter exceeding the guard interval. A RING that arrives in the wrong SLOT is indistinguishable from a correct RING. Implementors are advised that this is also true of network jitter in most other protocols; IPoUGRS merely makes the problem more visible by operating at a timescale where individual errors are personally meaningful.¶

False positive errors:

Caused by a third party calling one of the RECEIVER phone numbers for reasons unrelated to IPoUGRS. This constitutes an unintentional injection of a logical 1 into the data stream. Mitigation strategies are addressed in Section 10.¶

Call setup failures:

Caused by network congestion, temporary unavailability, or the general indifference of the infrastructure to the operator's intentions. Observed rate: 2-10% of call attempts. This error rate is notable in the context of a protocol that provides, in its baseline configuration, 1.6 bits per second.¶

IPoUGRS RECOMMENDS the use of Extended Hamming(8,4) error correcting code. This code maps four data bits to eight coded bits, adding three parity bits and one overall parity bit. At N=8, a single IPoUGRS time slot carries exactly one Hamming codeword. The authors consider this alignment elegant. It is the most elegant thing about IPoUGRS, and the authors are prepared to defend this assessment at length.¶

The Hamming code corrects all single-bit errors and detects all double-bit errors. In the context of IPoUGRS, a single-bit error means exactly one of the eight phones either rang when it should not have, or failed to ring when it should have. The code handles this gracefully. The code does not handle the scenario in which someone accidentally calls all eight phones at once. This scenario is considered a denial of service attack and is addressed in Section 10.¶

Implementations employing Extended Hamming(8,4) will observe an effective data rate of 0.8 bits per second. Implementations that regard 0.8 bits per second as unacceptably slow are directed to Section 7 and encouraged to recalibrate their expectations.¶

7. Throughput Analysis

   Throughput = N / SLOT_DURATION  (bits per second)

   Throughput = 8 / 5 = 1.6 bps

   RING_DURATION = 0.0s: symbol 00 (no call placed)
   RING_DURATION = 1.0s: symbol 01 (flash ring)
   RING_DURATION = 3.0s: symbol 10 (short ring)
   RING_DURATION = 5.0s: symbol 11 (long ring)

   Throughput = 8 / 3 = 2.67 bps

8. Applicability and Use Cases

IPoUGRS is suitable for a specific class of deployment scenarios: those in which the IP data plane is unavailable but the GSM circuit-switched signaling plane remains operational.¶

Mobile network architectures route voice calls through the Mobile Switching Center (MSC) via the SS7 signaling plane, while IP data traverses the Serving GPRS Support Node (SGSN) and Gateway GPRS Support Node (GGSN). These are architecturally distinct paths. Events that disable the data plane do not necessarily disable the signaling plane.¶

The authors observe, without elaboration, that such events have been documented in multiple countries across multiple continents in recent years. Readers wishing to understand the specific contexts in which a data plane is disabled while the signaling plane remains operational are encouraged to consult general news sources from the period 2019 to present. The authors make no further comment on this matter, as this is an Informational RFC and not an editorial.¶

Secondary use cases include:¶

• Emergency communications following natural disasters, where voice congestion renders the protocol largely useless (see Section 9.1), but where the visual spectacle of 16 phones simultaneously ringing and not being answered may attract the attention of emergency responders.¶
• Situations where available bandwidth is genuinely not a constraint, such as transmission of very short messages containing very low information content. The authors estimate this encompasses approximately 40% of current internet traffic.¶
• Educational demonstrations of OSI layer concepts, in which the physical layer is made, perhaps excessively, concrete.¶

9. Operational Considerations

10. Security Considerations

IPoUGRS has a rich security surface.¶

Eavesdropping:

IPoUGRS transmits data by placing telephone calls. Call detail records (CDRs) — including originating number, destination number, timestamp, and duration — are logged by mobile operators as a routine business function and retained for periods ranging from months to years. An adversary with access to CDR data can reconstruct the complete IPoUGRS bitstream. Encryption of the payload is STRONGLY RECOMMENDED. The authors suggest not relying on IPoUGRS for operational security.¶

Bit Injection:

Any party with knowledge of the RECEIVER phone numbers may introduce arbitrary bits into the data stream by placing calls to those numbers. This attack is known in security literature as "calling someone." It has been commercially refined since approximately 2009, is available as a service, and affects approximately 60% of mobile phone users daily. Defence is considered out of scope, as no satisfactory defence has been found for the broader problem.¶

Bit Suppression:

An adversary with the ability to cause calls to fail — by, for example, administering the mobile network — can suppress logical 1 bits. Combined with the observations in Section 8, the authors note that this attack vector may be exercised by the same party that creates the conditions under which IPoUGRS is deployed. The authors find this recursive quality architecturally interesting, if operationally discouraging.¶

Replay Attacks:

Not applicable. Nobody is going to replay 1.6 bps traffic.¶

11. IANA Considerations

This protocol requires no new protocol numbers, no port assignments, no registry entries, and no IANA action of any kind.¶

The authors consider this the protocol's most significant technical achievement, and request that it be noted.¶

Acknowledgements

The author thanks the operators of the GSM networks used in testing, who were not consulted and would likely not consent if they were.¶

The author thanks the Bergen Linux User Group for demonstrating that some RFCs should be implemented, and that doing so is funny.¶

The author thanks the inventors of the Extended Hamming code, who are in no way responsible for its application here.¶

No pigeons were involved in this work. One was consulted, but was unavailable.¶

Author's Address