Independent Submission J.P. Hanley Internet-Draft Myelin Networks LLC Intended status: Informational 20 October 2026 Expires: 23 April 2027 Regulatory Spectrum Discrete Global Grid System (RSDGGS) draft-hanley-rsdggs-00 Abstract This document defines the Regulatory Spectrum Discrete Global Grid System (RSDGGS), a hierarchical geographic indexing scheme designed to encode the regulatory jurisdiction applicable to Industrial, Scientific, and Medical (ISM) radio band usage at any location on Earth. RSDGGS represents geographic location as a variable-length byte array of 1 to 8 octets. The length of the array implicitly encodes the spatial resolution of the index, eliminating the need for an explicit resolution field. Truncation of the array yields a coarser representation, enabling privacy-preserving location compaction without loss of structural integrity. The grid is rooted in a spherical dodecahedron whose twelve pentagonal faces are aligned to approximate the three ITU Radio Regions, with face indices 1, 2, and 3 corresponding directly to ITU Regions 1, 2, and 3 respectively. Each face is recursively subdivided using a hierarchy of isosceles golden gnomon triangles, with 2-bit child indices packed into successive octets. The system supports both fixed IoT deployments for automated regulatory provisioning during manufacturing and mobile IoT devices that acquire regulatory context through GPS, tethered devices, or peer-assisted discovery. A beacon mechanism is defined whereby location-aware devices broadcast their RSDGGS index within ISM band transmissions, enabling location-unaware peers to derive applicable regulatory parameters including frequency allocation, power limits, duty cycle, dwell interval, channelization, and permitted modulation. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Hanley Expires 23 April 2027 [Page 1] Internet-Draft RSDGGS October 2026 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 23 April 2027. 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 . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 3. Motivation and Design Goals . . . . . . . . . . . . . . . . . 8 4. Dodecahedral Grid Geometry . . . . . . . . . . . . . . . . . 9 4.1. Rationale for the Dodecahedron . . . . . . . . . . . . . 9 4.1.1. Face Count and ITU Region Containment . . . . . . . . 10 4.1.2. Map Projection Distortion at Face Boundaries . . . . 11 4.1.3. Summary of Design Decision . . . . . . . . . . . . . 12 4.2. Face Topology and ITU Region Alignment . . . . . . . . . 13 4.3. Face Center Orientation . . . . . . . . . . . . . . . . . 15 4.4. Pentagonal Face Subdivision . . . . . . . . . . . . . . . 17 4.5. Isosceles Triangle Hierarchy . . . . . . . . . . . . . . 17 4.6. RSDGGS Dodecahedron Net — ISM Band Regulatory Coverage Map . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 4.6.1. ISM Band Color Coding . . . . . . . . . . . . . . . . 19 4.6.2. Face Assignments and Regulatory Bodies . . . . . . . 20 4.6.3. Net Topology and Construction . . . . . . . . . . . . 22 5. Index Encoding . . . . . . . . . . . . . . . . . . . . . . . 22 5.1. Octet Array Format . . . . . . . . . . . . . . . . . . . 22 5.2. Resolution by Length . . . . . . . . . . . . . . . . . . 24 5.3. Bit-Field Layout . . . . . . . . . . . . . . . . . . . . 25 5.4. Privacy Truncation . . . . . . . . . . . . . . . . . . . 26 6. Coordinate Encoding Algorithm . . . . . . . . . . . . . . . . 26 Hanley Expires 23 April 2027 [Page 2] Internet-Draft RSDGGS October 2026 6.1. Face Assignment . . . . . . . . . . . . . . . . . . . . . 26 6.2. Triangle Assignment Within Face . . . . . . . . . . . . . 27 6.3. Recursive Subdivision . . . . . . . . . . . . . . . . . . 27 7. CBOR Wire Encoding . . . . . . . . . . . . . . . . . . . . . 28 7.1. Compact Form . . . . . . . . . . . . . . . . . . . . . . 28 7.2. Tagged Form . . . . . . . . . . . . . . . . . . . . . . . 28 7.3. CDDL Schema . . . . . . . . . . . . . . . . . . . . . . . 28 8. Regulatory Database Structure . . . . . . . . . . . . . . . . 29 8.1. Band Entry Schema . . . . . . . . . . . . . . . . . . . . 29 8.2. Resolution Sufficiency Levels . . . . . . . . . . . . . . 30 8.3. Exception Overlay Table . . . . . . . . . . . . . . . . . 31 8.4. Regulatory Database Validity Limitations . . . . . . . . 32 9. ISM Band Reference . . . . . . . . . . . . . . . . . . . . . 34 9.1. 433.05-434.79 MHz (Center: 433.92 MHz) . . . . . . . . . 34 9.2. 863-870 MHz (ETSI SRD Sub-bands) . . . . . . . . . . . . 34 9.3. 902-928 MHz (Center: 915 MHz) . . . . . . . . . . . . . . 35 9.4. 920-928 MHz Regional Variants . . . . . . . . . . . . . . 36 9.5. TV Whitespace Bands (174-216 MHz, 470-608 MHz) . . . . . 37 10. Regulatory Boundary Zones and Adaptive Compliance . . . . . . 37 10.1. Cross-Border Spectrum Governance Framework . . . . . . . 37 10.1.1. ITU Radio Regulations . . . . . . . . . . . . . . . 38 10.1.2. Bilateral and Multilateral Coordination Agreements . . . . . . . . . . . . . . . . . . . . . 38 10.1.3. Technical Mitigation Mechanisms . . . . . . . . . . 39 10.2. Coordination Zone Geometry and RSDGGS Resolution . . . . 40 10.3. Boundary Proximity Function . . . . . . . . . . . . . . 41 10.4. Adaptive Power Control at Regulatory Boundaries . . . . 42 10.4.1. Power Reduction Profile . . . . . . . . . . . . . . 42 10.4.2. Duty Cycle and Dwell Constraints . . . . . . . . . . 43 10.5. RSDGGS Resolution Escalation Near Boundaries . . . . . . 44 10.6. CDDL Schema for Boundary-Aware Operation . . . . . . . . 45 11. Peer-Assisted Location Discovery . . . . . . . . . . . . . . 46 11.1. Beacon Frame Format . . . . . . . . . . . . . . . . . . 46 11.2. Channel Scanning Protocol . . . . . . . . . . . . . . . 47 11.3. Regulatory Bootstrap Procedure . . . . . . . . . . . . . 47 12. Manufacturing Provisioning Use Case . . . . . . . . . . . . . 48 13. Cooperative Localization . . . . . . . . . . . . . . . . . . 50 13.1. Localization Method Hierarchy . . . . . . . . . . . . . 50 13.2. RSDGGS Cell Intersection . . . . . . . . . . . . . . . . 51 13.3. Round-Trip RSSI Range Estimation . . . . . . . . . . . . 52 13.3.1. Round-Trip RSSI Exchange Procedure . . . . . . . . . 52 13.3.2. Range Estimation . . . . . . . . . . . . . . . . . . 52 13.4. IEEE 802.15.4a/z UWB Precision Ranging . . . . . . . . . 53 13.4.1. Double-Sided Two-Way Ranging (DS-TWR) . . . . . . . 53 13.4.2. STS Authentication (802.15.4z) . . . . . . . . . . . 54 13.4.3. Phase Difference of Arrival (PDOA) Angle Estimation . . . . . . . . . . . . . . . . . . . . . 54 13.5. RSDGGS as Position State Space . . . . . . . . . . . . . 55 Hanley Expires 23 April 2027 [Page 3] Internet-Draft RSDGGS October 2026 13.6. Weighted Multilateration Engine . . . . . . . . . . . . 56 13.6.1. Measurement Model . . . . . . . . . . . . . . . . . 56 13.6.2. Weighted Least Squares Position Update . . . . . . . 56 13.7. Extended Kalman Filter Integration . . . . . . . . . . . 57 13.7.1. State Vector . . . . . . . . . . . . . . . . . . . . 57 13.7.2. Prediction Step . . . . . . . . . . . . . . . . . . 57 13.7.3. Update Step . . . . . . . . . . . . . . . . . . . . 58 13.8. Security Considerations for Cooperative Ranging . . . . 58 14. IEEE 802.15.4 Information Element Encoding . . . . . . . . . 59 14.1. IE Structure and Constraints . . . . . . . . . . . . . . 59 14.2. RSDGGS Location Sub-IE Definition . . . . . . . . . . . 60 14.3. SUN Device Description Integration . . . . . . . . . . . 61 14.4. MAC-Layer Regulatory Bootstrap . . . . . . . . . . . . . 61 15. IPv6 Geographic Addressing . . . . . . . . . . . . . . . . . 62 15.1. Address Structure . . . . . . . . . . . . . . . . . . . 62 15.2. Prefix Hierarchy and Aggregation . . . . . . . . . . . . 63 15.3. Geographic Greedy Forwarding . . . . . . . . . . . . . . 65 15.4. Regulatory-Aware Channel Selection for Forwarding . . . 66 15.5. Relationship to Existing Standards . . . . . . . . . . . 66 16. Relationship to Prior Geographic Addressing Work . . . . . . 67 16.1. RFC 2009: GPS-Based Addressing and Routing . . . . . . . 68 16.1.1. RFC 2009 Technical Approach . . . . . . . . . . . . 68 16.1.2. Gaps Addressed by RSDGGS . . . . . . . . . . . . . . 68 16.2. RFC 5870: The 'geo' URI Scheme . . . . . . . . . . . . . 69 16.2.1. RFC 5870 Technical Approach . . . . . . . . . . . . 69 16.2.2. Gaps Addressed by RSDGGS . . . . . . . . . . . . . . 70 16.3. RFC 6442: Location Conveyance for SIP . . . . . . . . . 70 16.3.1. RFC 6442 Technical Approach . . . . . . . . . . . . 71 16.3.2. Gaps Addressed by RSDGGS . . . . . . . . . . . . . . 71 16.4. RFC 9179: A YANG Grouping for Geographic Locations . . . 72 16.4.1. RFC 9179 Technical Approach . . . . . . . . . . . . 72 16.4.2. Gaps Addressed by RSDGGS . . . . . . . . . . . . . . 72 16.5. RFC 9632: Finding and Using Geofeed Data . . . . . . . . 73 16.5.1. RFC 9632 Technical Approach . . . . . . . . . . . . 73 16.5.2. Gaps Addressed by RSDGGS . . . . . . . . . . . . . . 73 16.6. RFC 8805: A Format for Self-Published IP Geolocation Feeds . . . . . . . . . . . . . . . . . . . . . . . . . 74 16.6.1. RFC 8805 Technical Approach . . . . . . . . . . . . 75 16.6.2. Gaps Addressed by RSDGGS . . . . . . . . . . . . . . 75 16.7. RFC 5808: Requirements for a Location-by-Reference Mechanism . . . . . . . . . . . . . . . . . . . . . . . 76 16.7.1. RFC 5808 Technical Approach . . . . . . . . . . . . 76 16.7.2. Gaps Addressed by RSDGGS . . . . . . . . . . . . . . 76 16.8. RFC 5491: GEOPRIV PIDF-LO Usage Clarification, Considerations, and Recommendations . . . . . . . . . . 77 16.8.1. RFC 5491 Technical Approach . . . . . . . . . . . . 77 16.8.2. Gaps Addressed by RSDGGS . . . . . . . . . . . . . . 77 Hanley Expires 23 April 2027 [Page 4] Internet-Draft RSDGGS October 2026 16.9. RFC 6280: An Architecture for Location and Location Privacy in Internet Applications . . . . . . . . . . . 78 16.9.1. RFC 6280 Technical Approach . . . . . . . . . . . . 78 16.9.2. Gaps Addressed by RSDGGS . . . . . . . . . . . . . . 79 16.10. RFC 6772: Geolocation Policy: A Document Format for Expressing Privacy Preferences for Location Information . . . . . . . . . . . . . . . . . . . . . . 79 16.10.1. RFC 6772 Technical Approach . . . . . . . . . . . . 80 16.10.2. Gaps Addressed by RSDGGS . . . . . . . . . . . . . 80 16.11. Gap Analysis Summary . . . . . . . . . . . . . . . . . . 81 17. Backward Citations: Relevant References Within Cited Documents . . . . . . . . . . . . . . . . . . . . . . . . 83 17.1. GPSR — Greedy Perimeter Stateless Routing (from US 10,812,365) . . . . . . . . . . . . . . . . . . . . . . 83 17.2. IEEE 802.11d — Country Information Elements (from US 10,306,400 family) . . . . . . . . . . . . . . . . . . . 83 17.3. IEEE 802.11h — DFS and TPC (from US 10,306,400 family) . . . . . . . . . . . . . . . . . . . . . . . . 84 17.4. RFC 3693 — GEOPRIV Requirements (from RFC 6442 and RFC 6280) . . . . . . . . . . . . . . . . . . . . . . . . . 84 17.5. RFC 3825 — DHCP Geodetic Location Option (from RFC 5870 and RFC 5808) . . . . . . . . . . . . . . . . . . . . . 85 17.6. RFC 4632 — CIDR: Classless Inter-Domain Routing (from RFC 9632) . . . . . . . . . . . . . . . . . . . . . . . . . 86 17.7. RFC 6269 — Issues with IP Address Sharing (from RFC 9632) . . . . . . . . . . . . . . . . . . . . . . . . . 86 17.8. GeoCast — Geographic Addressing and Routing (from RFC 2009) . . . . . . . . . . . . . . . . . . . . . . . . . 86 17.9. Summary of Newly Identified References . . . . . . . . . 87 18. Freedom to Operate and Prior Art Considerations . . . . . . . 89 18.1. Expired Patents — Public Domain Prior Art . . . . . . . 89 18.1.1. US Patent 4,939,726 — Metricom, Inc. (Expired 2007) . . . . . . . . . . . . . . . . . . . . . . . . 89 18.1.2. US Patent 6,982,966 — Status Unconfirmed . . . . . . 90 18.2. Active Patents — Detailed Analysis . . . . . . . . . . . 90 18.2.1. US Patent 10,306,400 / Application 2014/0162692 — Wirelesss Regulatory Compliance (Active until ~2035) 90 18.2.2. US Patent 10,812,365 — Geohyperbolic Routing (Northeastern University, Active until 2037) . . . . 91 18.2.3. US Patent 11,652,742 — Ghost Routing (Microsoft, Active until 2041) . . . . . . . . . . . . . . . . . 92 18.2.4. CN101923801B — Method for Generating a Regular Dodecahedron Map Projection (Expired) . . . . . . . . 93 18.3. RFC Citation Improvement Opportunities . . . . . . . . . 96 18.3.1. RFC 2009 — GPS-Based Addressing (1996, Experimental/ Legacy) . . . . . . . . . . . . . . . . . . . . . . . 96 18.3.2. RFC 5870 — geo URI Scheme (2010, Standards Track) . 97 Hanley Expires 23 April 2027 [Page 5] Internet-Draft RSDGGS October 2026 18.3.3. RFC 6442 — Location Conveyance for SIP (2011, Standards Track) . . . . . . . . . . . . . . . . . . 97 18.3.4. RFC 9179 — YANG Grouping for Geographic Locations (2022, Standards Track) . . . . . . . . . . . . . . . 98 18.3.5. RFC 9632 / RFC 8805 — Geofeed Data (2024 / 2020) . . 98 18.3.6. RFC 5808 — Location-by-Reference Requirements (2010, Informational) . . . . . . . . . . . . . . . . . . . 98 18.3.7. RFC 5491 — PIDF-LO Usage (2009, Standards Track) . . 99 18.3.8. RFC 6280 — GEOPRIV Architecture (2011, BCP) . . . . 99 18.3.9. RFC 6772 — Geolocation Policy (2013, Standards Track) . . . . . . . . . . . . . . . . . . . . . . . 99 18.4. Summary of Improvement Opportunities . . . . . . . . . . 100 18.5. Recommended Clearance Actions . . . . . . . . . . . . . 101 19. Reference Implementation (Rust Pseudocode) . . . . . . . . . 103 19.1. Crate Structure and Types . . . . . . . . . . . . . . . 103 19.2. Compile-Time Constants . . . . . . . . . . . . . . . . . 104 19.3. Coordinate Conversion Primitives . . . . . . . . . . . . 108 19.4. Face Assignment . . . . . . . . . . . . . . . . . . . . 109 19.5. Pentagon Sector Assignment . . . . . . . . . . . . . . . 110 19.6. Recursive Subdivision . . . . . . . . . . . . . . . . . 111 19.7. Top-Level Encode Function . . . . . . . . . . . . . . . 112 19.8. Decode Function . . . . . . . . . . . . . . . . . . . . 114 19.9. Boundary Proximity Helper . . . . . . . . . . . . . . . 115 19.10. Worked Example . . . . . . . . . . . . . . . . . . . . . 117 20. Security Considerations . . . . . . . . . . . . . . . . . . . 118 21. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 119 22. Normative References . . . . . . . . . . . . . . . . . . . . 120 23. Informative References . . . . . . . . . . . . . . . . . . . 120 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 122 1. Introduction Radio devices operating in ISM bands must comply with regulatory requirements specific to their geographic location. These requirements vary significantly across jurisdictions and include constraints on frequency allocation, radiated power, duty cycle, dwell interval, channelization, and permitted modulation schemes. A device deployed globally may encounter any of dozens of distinct regulatory frameworks depending on where it operates. Existing geographic indexing systems such as Uber H3 [H3], Google S2 [S2], and OpenLocationCode [OLC] are designed for general-purpose spatial indexing and do not provide a hierarchical structure aligned to regulatory boundaries. They also lack a mechanism for embedding regulatory context within the index itself. Hanley Expires 23 April 2027 [Page 6] Internet-Draft RSDGGS October 2026 RSDGGS addresses this gap by defining a hierarchical grid whose coarsest level directly encodes ITU Radio Region membership, and whose progressive refinement resolves national and sub-national regulatory jurisdictions at resolutions appropriate to the regulatory complexity of each geographic area. The variable-length encoding allows a single-octet index to carry sufficient information to determine ISM band availability for the majority of the world's surface area, while the full eight-octet form provides sub-decimeter resolution adequate for the most complex geopolitical edge cases. 2. Terminology 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. RSDGGS: Regulatory Spectrum Discrete Global Grid System. The indexing scheme defined by this document. Cell: A geographic region represented by an RSDGGS index. The spatial extent of a cell is determined by the length of its index. Face: One of the twelve pentagonal faces of the spherical dodecahedron forming the coarsest level of the grid hierarchy. RSL (Resolution Sufficiency Level): The minimum index length, in octets, required to unambiguously identify the regulatory rule set applicable at a given location for a given ISM band. Rule Set: The complete collection of regulatory parameters applicable to a specific ISM band at a specific location, including frequency bounds, power limits, duty cycle, dwell interval, channelization, and modulation constraints. Golden Gnomon Triangle: An isosceles triangle with apex angle 36 degrees and base angles 72 degrees each, in which the ratio of leg length to base length equals the golden ratio phi (~1.618). These triangles tile the pentagonal faces of the dodecahedron. Beacon Device: An IoT device that has determined its regulatory context, either through GPS, tethered smartphone, or prior bootstrap, and broadcasts its RSDGGS index within ISM band transmissions to assist peers. Hanley Expires 23 April 2027 [Page 7] Internet-Draft RSDGGS October 2026 Naive Device: An IoT device that has not yet determined its regulatory context and performs channel scanning to discover a Beacon Device. 3. Motivation and Design Goals The design of RSDGGS is driven by the following goals: G1 — Regulatory Alignment: The coarsest index level MUST correspond to ITU Radio Region boundaries. Face indices 1, 2, and 3 SHALL correspond to ITU Regions 1, 2, and 3 respectively, enabling a single-octet lookup to determine gross band availability for most ISM bands. G2 — Self-Describing Resolution: The length of the index in octets SHALL implicitly encode its resolution. No explicit resolution field is required. This enables resolution to be communicated through the CBOR byte string length header at zero additional cost. G3 — Privacy Truncation: Truncating the index from the right SHALL yield a valid, coarser-resolution index. Devices MAY share a truncated index to disclose only the precision required for the intended purpose, protecting precise location from unnecessary disclosure. G4 — Embedded Deployment: The encoding and decoding algorithms SHALL be implementable in constrained environments with no heap allocation (no_std, no_alloc in Rust; fixed stack in C). The index fits within a uint64_t. G5 — CBOR Integration: The index SHALL serialize naturally as a CBOR byte string (major type 2), with the CBOR length header providing resolution information to the receiver at no additional encoding cost. G6 — Peer-Assisted Discovery: Location-unaware devices SHALL be able to derive their applicable regulatory parameters by receiving a beacon from a location-aware peer, using only the ISM channels permitted at the beacon device's location. G7 — Manufacturing Provisionability: Fixed-deployment IoT devices SHALL be provisionable with their RSDGGS index at manufacturing time, enabling a single hardware SKU to configure itself correctly based on deployment location without firmware variants. G8 — Decentralized, Infrastructure-Independent Operation: RSDGGS regulatory context discovery MUST NOT require any centralized server, directory, or management system. All mechanisms for a device to Hanley Expires 23 April 2027 [Page 8] Internet-Draft RSDGGS October 2026 acquire its RSDGGS cell index and associated regulatory rule set SHALL be fully operational in the absence of any network infrastructure beyond the device and its immediate radio neighbors. This precludes DHCP, DNS, and any client-server configuration protocol as a required element of the regulatory bootstrap path. In particular, DHCPv6 introduces a single point of failure: if the DHCP server is unavailable, onboarding nodes cannot be configured. RSDGGS instead follows the model of IPv6 SLAAC (Stateless Address Autoconfiguration) and Neighbor Discovery: a device SHALL be able to determine its own regulatory context from the devices around it, with no dependence on reachability to any server. Tethered devices such as smartphones used for provisioning, and infrastructure systems such as manufacturing databases or cloud enrollment services, are permitted as optional accelerators of the bootstrap process but MUST NOT be required for correct operation. A Naive Device with no tethering, no GPS, no DHCP, and no pre-provisioned cell index SHALL converge on a valid regulatory context solely through the peer- assisted mechanism defined in Section 11. G9 — Extraterrestrial Extensibility: The RSDGGS index format SHALL be extensible to celestial bodies beyond Earth without changing the wire format, adding version bits, or breaking backward compatibility with existing Earth indices. The four most-significant bits of Octet 0 are designated as the celestial body selector, allowing up to 16 independent dodecahedral grids (one per body) to coexist within a single 8-octet index space. A body selector value of 0x0 (Earth) is the default and preserves full backward compatibility: all RSDGGS indices generated before the body selector field was defined decode identically as Earth face indices. This design goal is motivated by the increasing operational relevance of wireless communications on the Moon (Artemis Program), Mars (long-duration missions), and other bodies where radio frequency coordination under the Outer Space Treaty (1967) will require a compact, self-describing location encoding. 4. Dodecahedral Grid Geometry 4.1. Rationale for the Dodecahedron The choice of a regular dodecahedron as the root polyhedron for RSDGGS is determined by two coupled geometric requirements: the need to contain ITU Radio Regions as coherent single-face units at the coarsest resolution level, and the minimization of map projection distortion variance across cell boundaries relative to the triangular-face alternative. Hanley Expires 23 April 2027 [Page 9] Internet-Draft RSDGGS October 2026 4.1.1. Face Count and ITU Region Containment Two Platonic solids with spherically projected faces are viable candidates for a global regulatory grid: the regular icosahedron (20 equilateral triangular faces) and the regular dodecahedron (12 regular pentagonal faces). The pair are duals of each other on the unit sphere. The International Telecommunication Union defines three primary Radio Regions. A grid whose coarsest level directly encodes ITU Region membership requires that each Region be representable as a single face, with face indices numerically matching Region numbers. This constraint drives the face count requirement: Icosahedron — 20 triangular faces: Face area ≈ 1/20 of sphere ≈ 25,500,000 km² ITU Region 2 (Americas) area ≈ 24,700,000 km² → Region 2 barely fits in one triangular face → Remaining 17 faces: over-partitions ITU regions at level 0 → 3 faces assigned to ITU Regions; 17 faces available for sub-regions — excessive granularity at coarsest level → Triangle shape forces boundary cuts through regulatory zones at 60-degree corner angles Dodecahedron — 12 pentagonal faces: Face area ≈ 1/12 of sphere ≈ 42,000,000 km² ITU Region 2 (Americas) area ≈ 24,700,000 km² → Region 2 fits within one pentagonal face with ~17,300,000 km² margin — accommodates coastal and island territories without boundary cuts → 3 faces centred on the most populous zone of each ITU Region (face indices 1, 2, 3) → 9 further faces; the two low-order bits of every face index give its ITU Region (Section 4.2) Figure 1 The icosahedron's 20 faces would require fragmenting each ITU Region across multiple faces at the coarsest level, destroying the direct face-to-region correspondence that is a primary design goal (G1) of RSDGGS. The dodecahedron's 12 faces provide the minimum face count that satisfies the ITU Region alignment constraint while leaving sufficient faces for sub-region differentiation. The nine extension faces (0 and 4 through 11) are numbered so that the two low-order bits of every face index give the ITU Region of the face's principal population: faces 5 and 9 (Region 1: Africa and the Middle East, West Africa), faces 6 and 10 (Region 2: South America, Hanley Expires 23 April 2027 [Page 10] Internet-Draft RSDGGS October 2026 the Central Pacific), and faces 7 and 11 (Region 3: Eastern Australia, the North Pacific). Faces 0, 4, and 8 cover Antarctica and the southern oceans and carry no Region. Section 4.2 lists the assignments. Twelve faces give each Region exactly three face indices; with the icosahedron's 20 faces the same scheme would leave most indices covering open ocean. 4.1.2. Map Projection Distortion at Face Boundaries All polyhedral global grids introduce map projection distortion when spherical regions are represented by planar polygons. The distortion is zero at the face center and increases toward the face boundary. For geographic grid systems used in regulatory compliance, the relevant quantity is the distortion variance across the face: specifically, the ratio of maximum distortion (at face corners) to minimum distortion (at edge midpoints). A lower ratio means cells near boundaries experience more uniform distortion, reducing the magnitude of cell shape irregularity in geographic space. For gnomonic projection (great circles map to straight lines, the natural projection for spherical polygons), the scale factor at angular distance theta from the face center is 1/cos^2(theta). The distortion ratio between the farthest and nearest boundary points of each face type is computed from the angular radii to the vertex and edge midpoint respectively. Icosahedron triangular face: Angular radius, face center to edge midpoint: ~20.9 deg Angular radius, face center to vertex: ~41.8 deg Gnomonic scale at edge midpoint: 1/cos²(20.9°) ≈ 1.15 Gnomonic scale at vertex: 1/cos²(41.8°) ≈ 1.80 Vertex-to-midpoint distance ratio: 2.00 Distortion ratio (vertex/midpoint scale): 1.57 Dodecahedron pentagonal face: Angular radius, face center to edge midpoint: ~31.7 deg Angular radius, face center to vertex: ~41.8 deg Gnomonic scale at edge midpoint: 1/cos²(31.7°) ≈ 1.38 Gnomonic scale at vertex: 1/cos²(41.8°) ≈ 1.80 Vertex-to-midpoint distance ratio: 1.24 Distortion ratio (vertex/midpoint scale): 1.30 Figure 2 Both polyhedra produce identical maximum distortion at their vertices (~1.80x gnomonic scale factor at ~41.8 degrees angular radius), because the vertices of the dodecahedron and the vertices of its dual icosahedron lie at the same angular distance from their respective Hanley Expires 23 April 2027 [Page 11] Internet-Draft RSDGGS October 2026 face centers on the unit sphere. The critical difference is the vertex-to-edge-midpoint distance ratio: 2.00 for the equilateral triangle versus 1.24 for the regular pentagon. The consequence for grid cells near the face boundary is that triangular faces concentrate high distortion at sharp 60-degree corners, with a steep distortion gradient between corner-adjacent cells and edge-midpoint-adjacent cells. The 1.57x distortion ratio means cells within one subdivision level of a triangle corner have substantially different shape distortion from cells of the same level near an edge midpoint. This heterogeneity propagates into the subdivision hierarchy: any subdivision level that places a cell boundary near a triangle corner inherits the distortion spike. Pentagonal faces distribute boundary distortion more uniformly. The 108-degree interior angle of the regular pentagon produces a shallower boundary curvature, and the 1.30x distortion ratio means corner-adjacent cells and edge-midpoint-adjacent cells experience only 30 percent more scale variation. The progressive 4-fold triangular subdivision of each pentagonal sector (Section 4.5) places triangle apices at the face center — a fixed interior point — rather than at face corners, further reducing the population of high- distortion boundary cells in the subdivision hierarchy. For regulatory compliance applications, distortion at cell boundaries is specifically relevant at the Resolution Sufficiency Level (RSL, Section 8.2): a cell straddling a regulatory border must resolve the boundary accurately. The more uniform distortion of pentagonal faces means RSL cells near national borders embedded in face boundaries have more predictable shape, reducing the error in determining which side of a border a device is on. 4.1.3. Summary of Design Decision +=============+====================+=================+==============+ | Property | Icosahedron (20 | Dodecahedron | Winner | | | triangles) | (12 | | | | | pentagons) | | +=============+====================+=================+==============+ | Face count | 20 faces / 3 | 12 faces / 3 | Dodecahedron | | vs. ITU | regions (excess) | regions | | | Regions | | (correct) | | +-------------+--------------------+-----------------+--------------+ | Extension | 17 (over- | 9 (two more | Dodecahedron | | faces for | partitioned) | per Region, | | | sub-regions | | three with | | | | | none) | | +-------------+--------------------+-----------------+--------------+ Hanley Expires 23 April 2027 [Page 12] Internet-Draft RSDGGS October 2026 | Face area | ~25.5M km² (tight | ~42M km² | Dodecahedron | | vs. Region | fit) | (ample | | | 2 | | margin) | | +-------------+--------------------+-----------------+--------------+ | Max | 1.80x (same) | 1.80x (same) | Tie | | boundary | | | | | distortion | | | | +-------------+--------------------+-----------------+--------------+ | Distortion | 1.57x (high | 1.30x (low | Dodecahedron | | ratio | variation) | variation) | | | vertex/ | | | | | midpoint | | | | +-------------+--------------------+-----------------+--------------+ | Interior | 60 degrees (sharp) | 108 degrees | Dodecahedron | | angle at | | (obtuse) | | | boundary | | | | | corner | | | | +-------------+--------------------+-----------------+--------------+ | Subdivision | Triangle (direct) | Triangle | Tie | | primitive | | (derived, | (different | | | | apex at | placement) | | | | center) | | +-------------+--------------------+-----------------+--------------+ Table 1: Icosahedron vs. Dodecahedron The dodecahedron satisfies both requirements that the icosahedron fails: it provides the correct face count for direct ITU Region alignment, and it produces lower distortion variance at face boundaries due to its obtuse pentagonal corner angles and smaller vertex-to-edge-midpoint distance ratio. These properties are intrinsic to the dodecahedral geometry and are not achievable by orientation adjustment of the icosahedron. 4.2. Face Topology and ITU Region Alignment The RSDGGS grid is rooted in a regular dodecahedron projected onto the surface of a unit sphere. A regular dodecahedron has twelve pentagonal faces. RSDGGS assigns these faces as follows: +======+============+=============+==============+==================+ | Face | ITU Region | Primary | Anchor | Primary Bodies | | | (face & | Name | Authority | | | | 0x3) | | | | +======+============+=============+==============+==================+ | 0 | — | Antarctica | ITU Special | Antarctic | | | | / New | Zone | Treaty, ITU Art. | | | | Zealand | | 48; RSM (NZ) | Hanley Expires 23 April 2027 [Page 13] Internet-Draft RSDGGS October 2026 +------+------------+-------------+--------------+------------------+ | 1 | R1 | ITU Region | ETSI / CEPT | ETSI, Ofcom, | | | | 1 — Europe | | ARCEP, BNetzA | +------+------------+-------------+--------------+------------------+ | 2 | R2 | ITU Region | FCC / ISED / | FCC (US), ISED | | | | 2 — North | IFT | (CA), IFT (MX) | | | | America | | | +------+------------+-------------+--------------+------------------+ | 3 | R3 | ITU Region | MIC / MIIT / | MIC (JP), MIIT | | | | 3 — Asia | KCC | (CN), KCC (KR), | | | | | | WPC/DoT (IN) | +------+------------+-------------+--------------+------------------+ | 4 | — | South | ICASA | ICASA (ZA) | | | | Atlantic | | | +------+------------+-------------+--------------+------------------+ | 5 | R1 | Region 1 — | ATU East / | CA (ET), CCK | | | | Africa / | ASMG | (KE), TCRA (TZ), | | | | Middle | | MCIT (SA), TRA | | | | East | | (AE) | +------+------------+-------------+--------------+------------------+ | 6 | R2 | Region 2 — | ANATEL / | Anatel (BR), | | | | South | ENACOM | ENACOM (AR) | | | | America | | | +------+------------+-------------+--------------+------------------+ | 7 | R3 | Region 3 — | ACMA | ACMA (AU), SPC | | | | Eastern | | | | | | Australia | | | +------+------------+-------------+--------------+------------------+ | 8 | — | Southern | ACMA | ACMA (AU: | | | | Indian | | Melbourne, | | | | Ocean | | Adelaide, Perth) | +------+------------+-------------+--------------+------------------+ | 9 | R1 | Region 1 — | ATU West | ARTP, ARCEP | | | | West | | (SN), NCC (NG), | | | | Africa | | ATU west | +------+------------+-------------+--------------+------------------+ | 10 | R2 | Region 2 — | FCC | FCC (US: Hawaii) | | | | Central | | | | | | Pacific | | | +------+------------+-------------+--------------+------------------+ | 11 | R3 | Region 3 — | MIC / | MIC (JP), | | | | North | Roskomnadzor | Roskomnadzor | | | | Pacific | | (RU), FCC (US: | | | | | | Alaska) | +------+------------+-------------+--------------+------------------+ Table 2: Face Assignments Hanley Expires 23 April 2027 [Page 14] Internet-Draft RSDGGS October 2026 Face indices 1, 2, and 3 carry the ITU Region number directly, establishing a direct correspondence between a single-octet RSDGGS index and ITU Region membership for the most populous zone of each Region. Every other face follows the same rule through its two low- order bits: the ITU Region at single-octet resolution is face & 0x3 (equivalently, Octet 0 & 0x03), where 0 means no Region. The rule gives the Region of the face's principal population; a face may also contain land of another Region (for example, north-east Brazil on face 9, Iran on face 1, and Alaska on face 11), and there the regulatory database, not the face index, determines the Region and the rules. Face 11 also carries Region exceptions at triangle level (Section 8.3): triangles 2 to 4 (Alaska and the Yukon) are Region 2, and triangle 0 (the Russian Far East) is Region 1, so a two-octet index resolves the Region there. Face 0 holds the largest part of Antarctica, which is subject to ITU Article 48 special coordination procedures rather than national regulatory frameworks; faces 4 and 8 hold most of the rest. Face 0 also contains New Zealand, whose rules come from the regulatory database like those of any other jurisdiction. 4.3. Face Center Orientation The dodecahedron is constructed as the dual of the unit icosahedron. The twelve face centers of the dodecahedron correspond to the twelve vertices of the icosahedron after normalization to the unit sphere. The icosahedron is defined by the golden ratio phi = (1 + sqrt(5)) / 2, with twelve vertices at the normalized forms of (0, +-1, +-phi), (+-1, +-phi, 0), and (+-phi, 0, +-1). The orientation places the three most populous regulatory zones each on a single face: Europe on face 1, North America on face 2, and the core of ITU Region 3 (China, India, Japan, Korea, and their neighbours) on face 3. It is fixed by two parameters, the position of the face 1 center and the bearing from it to the face 2 center: Hanley Expires 23 April 2027 [Page 15] Internet-Draft RSDGGS October 2026 Face 1 center: 60.0000N, 26.5000E Face 2 center: initial bearing 304.0000 deg (true) from the face 1 center, at the angular distance between adjacent face centers, arctan(2) = 63.4349 deg 1. Take any icosahedron vertex A and an adjacent vertex B, so that dot(A, B) = 1/sqrt(5). 2. Rotate the icosahedron by the rotation that maps A to the face 1 center and B to the face 2 center: the rotation taking the orthonormal frame (A, B', A x B') to (F1, F2', F1 x F2'), where B' and F2' are B and F2 made orthogonal to A and F1 and normalized. The icosahedral rotation group acts simply transitively on ordered pairs of adjacent vertices, so the choice of A and B does not matter. 3. The rotated vertices are the twelve face centers. Number them as below (each face is the one whose center is nearest the listed position). 4. The dodecahedron's vertices are the normalized centroids of the twenty rotated icosahedron triangles. A face's five vertices are those nearest its center; they are ordered counter-clockwise as seen from outside the sphere, starting with the vertex at the smallest bearing (clockwise from true north) from the face center. Triangle k of a face is (center, v[k], v[(k+1) mod 5]). Resulting face centers: Face 0 60.00S, 153.50W Antarctica / New Zealand Face 1 60.00N, 26.50E Europe (Region 1) Face 2 39.60N, 79.28W North America (Region 2) Face 3 23.76N, 104.10E Asia (Region 3) Face 4 54.80S, 1.18E South Atlantic Face 5 1.89S, 44.32E Africa / Middle East (Region 1) Face 6 23.76S, 75.90W South America (Region 2) Face 7 6.43S, 161.32E Eastern Australia (Region 3) Face 8 39.60S, 100.72E Southern Indian Ocean Face 9 6.43N, 18.68W West Africa (Region 1) Face 10 1.89N, 135.68W Central Pacific (Region 2) Face 11 54.80N, 178.82W North Pacific (Region 3) Figure 3 Weighted by the population of the Natural Earth populated places dataset (version 5.1.2), face 1 holds 99.6 percent of the population of Europe (including European Russia and Turkey), face 2 holds 99.4 percent of that of the United States, Canada, and Mexico, and face 3 holds 93 percent of that of the Region 3 core. The parts of these zones on other faces are the Canary Islands, Madeira, and the Azores (face 9); Hawaii (face 10); most of Alaska and the far north-west of Hanley Expires 23 April 2027 [Page 16] Internet-Draft RSDGGS October 2026 Canada (face 11); and, for Region 3, Iran (mostly face 1), northern Japan (face 11), Australia (faces 7 and 8), and New Zealand (face 0). Australia and New Zealand cannot share face 3: Sydney is 74 degrees from its center, twice a face's circumradius of 37.38 degrees. Puerto Rico and the US Virgin Islands are on face 2. This rotation procedure is normative for the purpose of independently verifying or regenerating the FACE_CENTERS and FACE_PENTAGON_VERTS compile-time constants defined in Section 18.2, and for deriving face orientations for non-Earth celestial bodies (Section 5.5). Implementations MUST use the precomputed constants in Section 18.2 for all runtime face and triangle assignment. The rotation itself is never performed at runtime. The reference implementation generates its constants with tools/gen_constants.py. 4.4. Pentagonal Face Subdivision Each pentagonal face of the dodecahedron is divided into five congruent isosceles triangles by connecting the face center to each of the five pentagon vertices. Each triangle has its apex at the face center and its base along one edge of the pentagon. This subdivision produces five triangular sectors per face, indexed 0 through 4. The five sectors are identified within the RSDGGS index by a 4-bit field in the high nibble of Octet 1, with values 5 through 15 reserved. The 4-bit width keeps every subdivision level within a single octet (Section 5.1). 4.5. Isosceles Triangle Hierarchy The isosceles triangles produced by pentagonal subdivision are golden gnomon triangles: the ratio of their leg length to base length equals the golden ratio phi. These triangles admit a natural 4-fold recursive subdivision by connecting the midpoints of all three sides, producing four congruent child triangles. apex /\ / \ / 0 \ Child 0: apex sub-triangle /------\ Child 1: left base sub-triangle /\ mid /\ Child 2: right base sub-triangle / \ / \ Child 3: central inverted triangle / 1 \ / 2 \ / \/ \ /--------3--------\ Figure 4 Hanley Expires 23 April 2027 [Page 17] Internet-Draft RSDGGS October 2026 Child 3, the central inverted triangle, has inverted orientation relative to its parent. This inversion is intrinsic to 4-fold triangle subdivision and must be tracked for correct neighbor computation. Each child triangle is geometrically similar to the parent, scaled by one-half in linear dimension and one-quarter in area. The 2-bit child index values are defined as follows: 00 denotes the apex child, 01 denotes the left base child, 10 denotes the right base child, and 11 denotes the central inverted child. 4.6. RSDGGS Dodecahedron Net — ISM Band Regulatory Coverage Map Figure 5 shows the RSDGGS dodecahedron as a cut-and-fold net. The net shows all twelve faces in their correct topological adjacency, with shared fold edges indicated by dashed lines and free cut edges indicated by solid lines with outlined glue tabs. Each pentagonal face is rendered using a gnomonic projection centered on that face's sphere center, ensuring that geographic features are continuous across every fold edge: a coastline, national border, or regulatory boundary that crosses from one face to an adjacent face appears as an unbroken line on both faces. Geographic continuity across all eleven fold edges was verified to within 0.006° of arc (numerical precision only). The net is a drawing; see the HTML or PDF rendering of this document, or the image files listed below. Figure 5: RSDGGS Dodecahedron Net, ISM Band Coverage (Black and White) In this document the net is drawn in black and white, as the SVG profile for RFCs requires, with the ISM bands shown as hatching (Section 4.6.1). To keep it readable, countries with the same bands are merged, small islands are omitted, and the net carries no city names. The full-colour net, with the most populous cities on every face, and its reference key are at https://github.com/dgtlrift/RSDGGS/blob/main/images/ rsdggs_net_page1.png and https://github.com/dgtlrift/RSDGGS/blob/main/images/ rsdggs_net_page2.png. Vector (SVG) versions are in the same directory, and black-and-white versions of both are in https://github.com/dgtlrift/RSDGGS/tree/main/images/bw. https://github.com/dgtlrift/RSDGGS/tree/main/images/faces has the twelve faces one per page for building a larger model, with each glue tab labelled with the face and triangle of the edge it is glued to; https://github.com/dgtlrift/RSDGGS/tree/main/images/bw/faces has the same pages in black and white. Hanley Expires 23 April 2027 [Page 18] Internet-Draft RSDGGS October 2026 The world map on each face is colored according to ISM band regulatory allowance. Countries are colored by the sub-GHz ISM band or bands permitted under their national regulatory framework. Where only the 2.4 GHz band is universally allocated (most of Asia/ Pacific), a lighter blue-grey fill indicates the absence of sub-GHz ISM allocation. Countries where multiple sub-GHz bands are simultaneously permitted display the primary band as the fill color with diagonal hatching in the secondary band color. In the black- and-white versions, each sub-GHz band has its own hatching, and where several bands are permitted their hatchings are overlaid. 4.6.1. ISM Band Color Coding The following color scheme, and the hatching of the black-and-white versions, is used consistently across all twelve faces of the net: +=========+===========+========+=================+=================+ |Color |Black and |Band | Frequency Range | Primary | | |white | | | Coverage | +=========+===========+========+=================+=================+ |Deep red |Diagonal |Band A | 433.050–434.790 | ITU Region 1: | |(#CC2222)|lines, | | MHz | Europe, Africa, | | |rising to | | | Middle East, | | |the right | | | Russia, Central | | |(/) | | | Asia, Indian | | | | | | Subcontinent | +---------+-----------+--------+-----------------+-----------------+ |Deep teal|Diagonal |Band B | 863–870 MHz | EU/CEPT/EEA | |(#1A7A5E)|lines, | | (ETSI SRD) | member states | | |falling to | | | and ETSI- | | |the right | | | aligned partner | | |(\); on the| | | nations | | |map only | | | | | |with Band A| | | | +---------+-----------+--------+-----------------+-----------------+ |Orange |Horizontal |Band C | 902–928 MHz | ITU Region 2 | |(#D4780A)|lines | | | (Americas) plus | | | | | | Australia, New | | | | | | Zealand, | | | | | | Taiwan, and | | | | | | Japan (920–928 | | | | | | MHz only) | +---------+-----------+--------+-----------------+-----------------+ |Navy blue|None |Band D | 2400–2500 MHz | Global | |(#1A3580)|(available | | | allocation — | | |everywhere)| | | all countries | | | | | | (informational | | | | | | baseline, | Hanley Expires 23 April 2027 [Page 19] Internet-Draft RSDGGS October 2026 | | | | | universal) | +---------+-----------+--------+-----------------+-----------------+ |Steel |Dots |2.4 GHz | 2400–2500 MHz | No sub-GHz ISM | |blue | |only | | band allocated | |(#B0C8DC)| | | | (most of Asia/ | | | | | | Pacific) | +---------+-----------+--------+-----------------+-----------------+ |Primary +|Overlaid |Multiple| Two bands | Primary fill = | |diagonal |hatching |bands | concurrent | first band; | |hatch |(433 + 868 | | | hatch color = | | |MHz: | | | second band | | |crossed | | | (e.g., EU: red | | |diagonals) | | | fill + teal | | | | | | hatch for 433 + | | | | | | 868 MHz) | +---------+-----------+--------+-----------------+-----------------+ Table 3: ISM Band Color Coding 4.6.2. Face Assignments and Regulatory Bodies Each face of the RSDGGS dodecahedron is labeled with its face index (0–11). The face index is the RSDGGS encoding value returned for any coordinate within that face at 1-byte resolution. The following table maps each face index to its geographic coverage and the principal national regulatory bodies whose ISM band rules apply within that face. +======+============+=============+==============+=================+ | Face | Geographic | ITU | Principal | ISM Bands | | | Region | Designation | Regulatory | | | | | | Bodies | | +======+============+=============+==============+=================+ | F0 | Antarctica | Special (no | Antarctic | Antarctica: | | | / New | Region) | Treaty · RSM | coordination | | | Zealand | | (NZ) | required; NZ: | | | | | | 915–928 + 2.4 | | | | | | GHz | +------+------------+-------------+--------------+-----------------+ | F1 | Europe | ITU Region | ETSI · Ofcom | 433 + 868 + 2.4 | | | | 1 | (UK) · ARCEP | GHz; 433 + 2.4 | | | | | (FR) · | GHz (RU, TR, | | | | | BNetzA (DE) | Maghreb) | +------+------------+-------------+--------------+-----------------+ | F2 | North | ITU Region | FCC (US) · | 902–928 + 2.4 | | | America | 2 | ISED (CA) · | GHz | | | | | IFT (MX) | | +------+------------+-------------+--------------+-----------------+ Hanley Expires 23 April 2027 [Page 20] Internet-Draft RSDGGS October 2026 | F3 | Asia | ITU Region | MIC (JP) · | 2.4 GHz; JP | | | | 3 | MIIT (CN) · | 920–928 MHz; TW | | | | | KCC (KR) · | 902–928 MHz; | | | | | NCC (TW) · | some: 920–925 | | | | | WPC/DoT (IN) | MHz (IN, SG, | | | | | | MY, ID) | +------+------------+-------------+--------------+-----------------+ | F4 | South | None | ICASA (ZA) | 433 + 2.4 GHz | | | Atlantic | | | (ZA); | | | | | | Antarctica: | | | | | | coordination | | | | | | required | +------+------------+-------------+--------------+-----------------+ | F5 | Africa / | ITU Region | ATU East · | 433 + 2.4 GHz | | | Middle | 1 | ASMG · CCK | | | | East | | (KE) · TCRA | | | | | | (TZ) · MCIT | | | | | | (SA) · TRA | | | | | | (AE) | | +------+------------+-------------+--------------+-----------------+ | F6 | South | ITU Region | Anatel (BR) | 902–928 + 2.4 | | | America | 2 | · ENACOM | GHz; BR split- | | | | | (AR) · | band | | | | | SUBTEL (CL) | | +------+------------+-------------+--------------+-----------------+ | F7 | Eastern | ITU Region | ACMA (AU) · | 915–928 MHz | | | Australia | 3 | MCIT (PG) | (AU) + 2.4 GHz | +------+------------+-------------+--------------+-----------------+ | F8 | Southern | None | ACMA (AU) | 915–928 MHz | | | Indian | | | (AU) + 2.4 GHz; | | | Ocean | | | Antarctica: | | | | | | coordination | | | | | | required | +------+------------+-------------+--------------+-----------------+ | F9 | West | ITU Region | ATU West · | 433 + 2.4 GHz; | | | Africa | 1 | NCC (NG) · | north-east | | | | | OFCOM (GH) · | Brazil: 902–928 | | | | | ANRT (MA) | + 2.4 GHz | +------+------------+-------------+--------------+-----------------+ | F10 | Central | ITU Region | FCC (US: | 902–928 + 2.4 | | | Pacific | 2 | Hawaii) | GHz | +------+------------+-------------+--------------+-----------------+ | F11 | North | ITU Region | MIC (JP) · | JP 920–928 MHz; | | | Pacific | 3 | Roskomnadzor | RU 433 + 2.4 | | | | | (RU) · FCC | GHz; AK 902–928 | | | | | (US: Alaska) | + 2.4 GHz | +------+------------+-------------+--------------+-----------------+ Hanley Expires 23 April 2027 [Page 21] Internet-Draft RSDGGS October 2026 Table 4: Face Assignments and Regulatory Bodies 4.6.3. Net Topology and Construction The net uses a topologically valid unfolding of the dodecahedron. All twelve faces remain connected through their shared fold edges; no face requires cutting and reattaching. It consists of two groups of six faces, face 0 with its five neighbours and face 1 with its five, joined across the edge between faces 6 and 2. The net topology was verified against the true 3D dodecahedron face adjacency graph: each pair of faces in the net that shares a fold edge is confirmed to share a geometric edge in the 3D dodecahedron. Construction proceeds by: (1) printing on US Letter stock, portrait, at 100% scale (do not fit to page); (2) cutting along all solid outer edges; (3) scoring all dashed fold lines firmly with a stylus; (4) folding each face upward along the scored lines; (5) applying adhesive to each grey GLUE tab; and (6) pressing each tab against the inner surface of the mating face. The last fold closes the final seam. The gnomonic projection used for each face maps great-circle arcs to straight line segments. Since the shared edge between any two adjacent dodecahedron faces lies on a great circle of the sphere, that edge projects as a straight line in both adjacent face projections. After alignment of the shared-edge endpoints, geographic features cross the fold edge continuously without discontinuity, distortion artifact, or gap. The net is sized for US Letter, portrait, at 100% scale, which gives each pentagon a circumradius of 25 mm (37.38 degrees of arc). The reference key carries the ISM band legend, the face index table, the construction instructions and a band quick reference. 5. Index Encoding 5.1. Octet Array Format An RSDGGS index is a byte array of 1 to 8 octets. The interpretation of each octet is as follows: Hanley Expires 23 April 2027 [Page 22] Internet-Draft RSDGGS October 2026 Octet 0: Bits 7-4: Celestial body selector, values 0-15. 0x0 = Earth (default; backward compatible). 0x1 = Moon. 0x2 = Mars. 0x3-0xE = Reserved. 0xF = Reserved. Bits 3-0: Face index [0..11] on the selected body. Values 12-15 are reserved. Octet 1: Bits 7-4: Triangle index within face, values 0-4. Values 5-15 are reserved. Bits 3-2: Subdivision level 1 (2-bit child index). Bits 1-0: Subdivision level 2 (2-bit child index). Octets 2-7: Packed subdivision levels, 2 bits per level, MSB-first. Each octet carries exactly 4 complete levels: octet n (n >= 2) carries levels 4n-5 through 4n-2. No level straddles an octet boundary. See Section 5.3 for the complete bit-field layout. Figure 6 When stored as a uint64_t for in-memory computation, Octet 0 occupies the most significant byte (big-endian octet order). Every bit of an index of a given length is significant; there are no unused bits. When an index is held in a wider container (for example, a uint64_t), the octets beyond its length MUST be zero and MUST be ignored by receivers. A receiver MUST reject an index whose triangle index is a reserved value (5-15). The four-bit celestial body selector in bits 7-4 of Octet 0 partitions the RSDGGS index space into sixteen independent dodecahedral grids, one per celestial body. Body 0x0 (Earth) is the default and backward-compatible value: all existing RSDGGS indices have Octet 0 in the range 0x00-0x0B, which corresponds to body=0, face=0-11. Implementations that predate this field definition will continue to decode these indices correctly as Earth face indices. The body selector enables RSDGGS to serve as a unified location encoding for operations on the Moon, Mars, and future celestial bodies where wireless regulatory coordination may be required under the Outer Space Treaty (1967) and subsequent ITU coordination frameworks. The dodecahedral grid geometry is body-agnostic: the same 12-face topology and subdivision hierarchy applies to any approximately spherical body, with face assignments and regulatory databases defined independently per body. New body selector values are assigned by IANA under the "RSDGGS Celestial Body Selector" sub- registry defined in Section 20. Hanley Expires 23 April 2027 [Page 23] Internet-Draft RSDGGS October 2026 5.2. Resolution by Length The spatial resolution of an RSDGGS index is determined entirely by its length in octets. Each octet after Octet 1 adds four subdivision levels, reducing the linear cell size by a factor of 16. Cell sizes vary across a face; the values below were measured at 39°N 98°W with the reference implementation, for a dodecahedron face area of approximately 42 million square kilometers: +==========+=============+===============+===================+ | Length | Subdivision | Approx. Cell | Primary Use | | (octets) | Levels | Diameter | | +==========+=============+===============+===================+ | 1 | 0 (face | ~7,000 km | ITU Region / band | | | only) | | availability | +----------+-------------+---------------+-------------------+ | 2 | 2 | ~1,000 km | Sub-regional | | | | | regulatory bloc | +----------+-------------+---------------+-------------------+ | 3 | 6 | ~65 km | Country-level | | | | | jurisdiction (RSL | | | | | for most) | +----------+-------------+---------------+-------------------+ | 4 | 10 | ~4 km | Border zones, | | | | | enclaves | +----------+-------------+---------------+-------------------+ | 5 | 14 | ~260 m | Urban regulatory | | | | | exceptions (HK, | | | | | SG) | +----------+-------------+---------------+-------------------+ | 6 | 18 | ~16 m | Finest exception | | | | | cases (Ceuta, | | | | | BVI) | +----------+-------------+---------------+-------------------+ | 7 | 22 | ~1 m | Precision | | | | | location services | +----------+-------------+---------------+-------------------+ | 8 | 26 | ~6 cm | Survey-grade, | | | | | sub-decimeter | +----------+-------------+---------------+-------------------+ Table 5: Resolution by Length Hanley Expires 23 April 2027 [Page 24] Internet-Draft RSDGGS October 2026 5.3. Bit-Field Layout The following table provides the normative bit-field definition for a maximum-resolution 8-octet RSDGGS index stored as a uint64_t. Octet 0 occupies bits 63-56 (most significant byte, big-endian). Bits 63-60 of Octet 0 carry the four-bit celestial body selector; bits 59-56 carry the four-bit face index. The triangle index occupies the high nibble of Octet 1, and every subdivision level lies entirely within one octet. All 64 bits are significant. Bits 63-60: Octet 0 bits 7-4 — Celestial body selector [0..15] Bits 59-56: Octet 0 bits 3-0 — Face index [0..11] on selected body Bits 55-52: Octet 1 bits 7-4 — Triangle index [0..4]; 5-15 reserved Bits 51-50: Subdivision level 1 Bits 49-48: Subdivision level 2 Bits 47-46: Subdivision level 3 Bits 45-44: Subdivision level 4 Bits 43-42: Subdivision level 5 Bits 41-40: Subdivision level 6 Bits 39-38: Subdivision level 7 Bits 37-36: Subdivision level 8 Bits 35-34: Subdivision level 9 Bits 33-32: Subdivision level 10 Bits 31-30: Subdivision level 11 Bits 29-28: Subdivision level 12 Bits 27-26: Subdivision level 13 Bits 25-24: Subdivision level 14 Bits 23-22: Subdivision level 15 Bits 21-20: Subdivision level 16 Bits 19-18: Subdivision level 17 Bits 17-16: Subdivision level 18 Bits 15-14: Subdivision level 19 Bits 13-12: Subdivision level 20 Bits 11-10: Subdivision level 21 Bits 9-8: Subdivision level 22 Bits 7-6: Subdivision level 23 Bits 5-4: Subdivision level 24 Bits 3-2: Subdivision level 25 Bits 1-0: Subdivision level 26 Figure 7 At 26 subdivision levels, the minimum triangle area is approximately 9 square centimeters, representing a linear cell dimension of roughly 3 centimeters on Earth's surface. Hanley Expires 23 April 2027 [Page 25] Internet-Draft RSDGGS October 2026 5.4. Privacy Truncation An RSDGGS index MAY be truncated to any shorter length to reduce precision. The resulting truncated index is a valid RSDGGS index at the coarser resolution corresponding to its new length. No metadata is lost by truncation, as the resolution is fully recoverable from the length of the remaining bytes. Truncation is performed by removing trailing octets; no bits of the remaining octets change. Because no subdivision level spans an octet boundary, the truncated index is identical to the index that would be produced by encoding the original point at the shorter length, and every cell has exactly one encoding at each length. An index is contained in another if and only if the other is a prefix of it. Implementations sharing location information with peers SHOULD use the minimum resolution necessary for the intended regulatory purpose. For ISM band availability determination, 1 octet is sufficient for most locations. For country-level rule set selection, 3 octets are RECOMMENDED. For border zone and enclave disambiguation, 4 to 6 octets MAY be required. Implementations MUST NOT infer more precise location information from a truncated index than its resolution supports. The geographic region corresponding to a truncated index is the entire cell at that resolution, not the point within it from which the index was derived. 6. Coordinate Encoding Algorithm 6.1. Face Assignment Given a geographic coordinate (latitude, longitude) in decimal degrees, the face index is determined by finding the dodecahedron face whose center has the maximum dot product with the unit vector corresponding to the coordinate. This is equivalent to finding the nearest face center on the unit sphere. 1. Convert (lat, lon) to unit Cartesian vector: x = cos(lat) * cos(lon) y = cos(lat) * sin(lon) z = sin(lat) 2. For each face i in [0..11]: d_i = dot(point, face_center[i]) 3. face = argmax(d_i) Figure 8 Hanley Expires 23 April 2027 [Page 26] Internet-Draft RSDGGS October 2026 Face centers are precomputed from the rotated icosahedron vertex positions as described in Section 4.3. Implementations SHOULD store all twelve face center vectors as compile-time constants to avoid runtime trigonometric computation on constrained devices. 6.2. Triangle Assignment Within Face After determining the face, the coordinate is assigned to one of the five triangular sectors within the face. Each sector is bounded by the face center and two adjacent pentagon vertices. Assignment is performed using spherical excess tests on the unit sphere. For each of the five triangles T_k (k = 0..4), defined by vertices (face_center, pentagon_vertex_k, pentagon_vertex_{k+1 mod 5}), the point is contained in T_k if and only if it lies on the correct side of all three great-circle arcs bounding the triangle. The side test for an arc defined by two unit vectors A and B is given by the sign of the triple scalar product dot(cross(A, B), P), where P is the point under test. The pentagon vertex positions for each face are derived from the dodecahedron geometry and MUST be stored as precomputed constants. 6.3. Recursive Subdivision Given the face and triangle sector, the coordinate is recursively assigned to child triangles to the depth required by the desired index length. At each level, the three edge midpoints of the current triangle are computed by normalizing the mean of the two endpoint vectors: mid(A, B) = normalize(A + B) Children of triangle (apex, left, right): Child 0: (apex, mid(apex,left), mid(apex,right)) Child 1: (mid(apex,left), left, mid(left,right)) Child 2: (mid(apex,right), mid(left,right), right ) Child 3: (mid(left,right), mid(apex,right), mid(apex,left)) [inverted orientation] Figure 9 The child containing the point is determined by the same spherical excess containment test used in Section 6.2. The 2-bit child index is appended to the index bit stream. This process repeats until the required number of subdivision levels have been encoded. Hanley Expires 23 April 2027 [Page 27] Internet-Draft RSDGGS October 2026 Implementations targeting constrained environments SHOULD use integer approximations of the normalized midpoint computation, such as fixed- point arithmetic with sufficient precision for the target resolution depth. For resolutions of 4 octets or fewer, 32-bit fixed-point arithmetic is sufficient. For resolutions of 6 octets or greater, 64-bit arithmetic is RECOMMENDED. 7. CBOR Wire Encoding 7.1. Compact Form An RSDGGS index is encoded as a CBOR byte string (major type 2) [RFC8949]. The byte string length provides the resolution information at no additional cost, satisfying design goal G5. The compact form is suitable for resource-constrained IoT messages where protocol overhead must be minimized. 0x41 0x02 -- 1-byte index, face 2 (ITU Region 2) 0x43 0x02 0x21 0xF7 -- 3-byte index, 39N 98W, country-level 0x48 ... -- 8-byte index, maximum resolution Figure 10 7.2. Tagged Form Implementations requiring explicit type identification SHOULD use a CBOR tag to mark the byte string as an RSDGGS index. A private-use tag in the range 65536-15309735 SHOULD be used pending IANA assignment. The recommended placeholder tag value is 0xC24D52 (pending registration). 0xC2 0x4D 0x52 0x43 0x02 0x21 0xF7 -- Tagged RSDGGS, 3-byte index Figure 11 7.3. CDDL Schema The following CDDL [RFC8610] schema defines the wire format for RSDGGS-bearing messages: Hanley Expires 23 April 2027 [Page 28] Internet-Draft RSDGGS October 2026 rsdggs-cell = bstr .size (1..8) location = { cell: rsdggs-cell, ? alt-m: float16, ; altitude in meters, optional } ism-context = { location: location, band-khz: uint, ; center frequency in kHz ? ruleset: uint, ; resolved rule set ID, optional } beacon-frame = { cell: rsdggs-cell, ; RSDGGS index at RSL depth band-khz: uint, ; transmitting center frequency ruleset: uint, ; rule set ID in effect power-dbm: int, ; transmit power in dBm ? seq: uint, ; sequence number, optional } Figure 12 8. Regulatory Database Structure 8.1. Band Entry Schema The regulatory database maps RSDGGS cells to rule sets. Each rule set entry contains the complete regulatory parameters for one ISM band in one jurisdiction. Regulatory databases are body-specific: an Earth database contains only Earth cell indices (Octet 0 body selector = 0x0), and a future Lunar database would contain only Lunar cell indices (body selector = 0x1). Implementations MUST NOT apply an Earth regulatory database to a non-Earth RSDGGS index. The body selector in Octet 0 MUST be checked before any database lookup, and an unknown body selector MUST result in an error response rather than a default or fallback regulatory rule set. The following CDDL schema defines a band entry: Hanley Expires 23 April 2027 [Page 29] Internet-Draft RSDGGS October 2026 band-entry = { band-id: uint, authority: tstr, ; regulatory body name citation: tstr, ; rule citation (e.g. "FCC Part 15.247") freq-lo-khz: uint, freq-hi-khz: uint, power-mw: uint, power-ref: power-reference, duty-cycle: nil / float, ; fraction 0.0-1.0, nil = unrestricted dwell-s: nil / float, ; max dwell in seconds, nil = unrestricted lbt: bool, ; listen-before-talk required hop-required: bool, ; frequency hopping required min-hop-set: nil / uint, ; minimum hopping channel set size channels: nil / [+ channel-entry], modulation: nil / [+ modulation-type], whitespace-db: nil / tstr, ; URL for dynamic lookup if required available: bool, ; false = band illegal in this cell exception: bool, ; true = consult exception overlay } power-reference = &(erp: 0, eirp: 1, conducted: 2) channel-entry = { cf-khz: uint, bw-khz: uint, } modulation-type = &( fsk: 0, gfsk: 1, lora: 2, dsss: 3, ofdm: 4, ook: 5, bpsk: 6, any: 255 ) Figure 13 8.2. Resolution Sufficiency Levels The Resolution Sufficiency Level (RSL) for a given face and band specifies the minimum index length at which the regulatory rule set is unambiguous. Devices MUST acquire an index of at least RSL octets before performing a regulatory lookup for that band. Hanley Expires 23 April 2027 [Page 30] Internet-Draft RSDGGS October 2026 +============+=========+=========+==========+===========+===========+ | Band |Face 2 |Face 1 |Faces | Faces 5/9 | RU/ME | | |(N. Am.)|(EU) |3/7/11 | (Africa) | (within | | | | |(Asia/ | | faces 1, | | | | |Pac) | | 3, 5, 11) | +============+=========+=========+==========+===========+===========+ | 433 MHz |RSL 1 |RSL 2 |RSL 1 | RSL 3 | RSL 2 | | |(illegal)| |(illegal) | | | +------------+---------+---------+----------+-----------+-----------+ | 863 MHz |RSL 1 |RSL 2 |RSL 1 | RSL 3 | RSL 2 | | |(illegal)| |(illegal) | | | +------------+---------+---------+----------+-----------+-----------+ | 902 MHz |RSL 1 |RSL 1 |RSL 3 | RSL 3 | RSL 1 | | | |(illegal)| | | (illegal) | +------------+---------+---------+----------+-----------+-----------+ | 920 MHz |RSL 1 |RSL 1 |RSL 3 | RSL 3 | RSL 1 | | |(902 |(illegal)| | | (illegal) | | |band) | | | | | +------------+---------+---------+----------+-----------+-----------+ | Whitespace |RSL 1 (US|RSL 1 |RSL 1 | RSL 1 | RSL 1 | | |only) |(illegal)|(illegal) | (illegal) | (illegal) | +------------+---------+---------+----------+-----------+-----------+ Table 6: Resolution Sufficiency Levels For faces where a band is universally illegal, RSL 1 is sufficient: the face byte alone enables immediate determination that the band is unavailable, and no further index bytes are required for regulatory validation purposes. 8.3. Exception Overlay Table Certain jurisdictions cannot be fully resolved by the regular grid at any practical resolution due to their small geographic extent, enclave status, or face-level regulatory misassignment. These locations are addressed by an exception overlay table consulted after the primary database lookup when the band-entry exception flag is set. +================+===========+=========================+===========+ | Location | Face | Issue | Min RSL | | | | | for | | | | | Exception | +================+===========+=========================+===========+ | Hong Kong | 3 | 920-925 MHz, 100 mW vs. | 5 | | (OFCA) | | CN illegal | | +----------------+-----------+-------------------------+-----------+ | Macau (DSRT) | 3 | ETSI framework in | 5 | Hanley Expires 23 April 2027 [Page 31] Internet-Draft RSDGGS October 2026 | | | Region 3 face | | +----------------+-----------+-------------------------+-----------+ | Singapore | 3 | 920-925 MHz, 500 mW; | 4-5 | | (IMDA) | | ~50 km state | | +----------------+-----------+-------------------------+-----------+ | British Virgin | 2 | ICTA rules adjacent to | 5 | | Islands | | USVI (FCC) | | +----------------+-----------+-------------------------+-----------+ | French Guiana | 9 | ETSI rules in West | 4 | | (ARCEP) | | Africa face, beside | | | | | Brazil | | +----------------+-----------+-------------------------+-----------+ | Ceuta / | 1 | EU enclaves bordering | 6 | | Melilla (ETSI) | | Morocco | | +----------------+-----------+-------------------------+-----------+ | Guam / CNMI | 7 | FCC rules in Region 3 | 4 | | (FCC) | | face | | +----------------+-----------+-------------------------+-----------+ | Alaska / Yukon | 11, | Region 2 rules in | 2 | | (FCC, ISED) | triangles | Region 3 face; the | | | | 2–4 | triangles hold no other | | | | | land | | +----------------+-----------+-------------------------+-----------+ | Russian Far | 11, | Region 1 rules in | 2 | | East | triangle | Region 3 face; triangle | | | (Roskomnadzor) | 0 | 0 is 97% Russian land | | +----------------+-----------+-------------------------+-----------+ | Alaska North | 11, | Region 2 inside the | 5 | | Slope, | triangle | triangle 0 Region 1 | | | Canadian | 0 | exception; the | | | Arctic (FCC, | | US–Russia border passes | | | ISED) | | between the Diomede | | | | | Islands, 3.8 km apart | | +----------------+-----------+-------------------------+-----------+ | French Pacific | 7, 10 | ETSI rules in Pacific | 4 | | (ARCEP) | | faces | | +----------------+-----------+-------------------------+-----------+ Table 7: Exception Overlay Table 8.4. Regulatory Database Validity Limitations The regulatory database embedded in an RSDGGS implementation is a point-in-time snapshot of applicable regulations at the time of compilation or last update. Implementers and operators MUST be aware of the following limitations inherent to any static regulatory database. Hanley Expires 23 April 2027 [Page 32] Internet-Draft RSDGGS October 2026 *Regulatory change:* National spectrum regulations, ITU Radio Regulation allocations, and bilateral coordination agreements change over time through legislative action, treaty revision, ITU World Radiocommunication Conference (WRC) decisions, and emergency administrative orders. A database that was accurate at device manufacture may no longer correctly represent the regulatory environment at the time of deployment. RSDGGS provides no mechanism to detect or signal database staleness; this is an architectural limitation of the static-database approach required by constrained devices. *Legacy device risk:* Devices with non-updateable firmware or regulatory databases, or devices operating long past their original certification period, may carry regulatory parameters that have been superseded. Regulatory authorities have in some cases changed permitted power levels, introduced listen-before-talk requirements, or restricted previously available frequency ranges. An operator deploying legacy devices with stale RSDGGS databases MUST independently verify that the embedded regulatory parameters remain compliant with current law in the jurisdiction of deployment. This document cannot and does not guarantee the perpetual accuracy of the example band entries in Section 9. *Storage-constrained implementations:* Highly constrained devices (Class 0 and Class 1 per RFC 7228, typically less than 10 KB RAM and less than 100 KB flash) may be unable to store complete regulatory databases for all twelve RSDGGS faces. Permissible approaches include: (1) storing only the rule set for the expected operating region (single-face database); (2) storing only the face-level (1-byte) rule set and querying a trusted peer for sub-face details via the bootstrap mechanism in Section 11; (3) storing a minimal safe-mode rule set representing the most restrictive applicable parameters and operating at reduced power until a full database is available. Implementations using approach (1) MUST treat reception of an RSDGGS cell index for an unknown face as a compliance failure requiring the device to cease transmission until it has obtained a valid rule set for that face. *No warranty of compliance:* RSDGGS is an informational aid to regulatory self-assessment by constrained IoT devices. Use of a current, accurate RSDGGS database does not constitute a regulatory authorization, does not relieve operators of the obligation to hold any required spectrum licenses, and does not substitute for type approval or certification under the applicable national regulatory framework. Operators remain legally responsible for the compliance of their deployments. Hanley Expires 23 April 2027 [Page 33] Internet-Draft RSDGGS October 2026 Implementations intended for safety-critical or licensed-spectrum applications SHOULD implement a database version timestamp field and a configurable maximum database age, defaulting to a deployment- class-appropriate value (for example, 365 days for fixed infrastructure, 90 days for mobile equipment). Implementations SHOULD expose the database version and age to management interfaces so that operators can audit fleet-wide database currency. 9. ISM Band Reference 9.1. 433.05-434.79 MHz (Center: 433.92 MHz) This band is designated for ISM use exclusively within ITU Region 1 (Europe, Africa, Middle East, and parts of the former USSR). It is not available as an ISM band in ITU Regions 2 or 3. A single-octet RSDGGS index is sufficient to determine unavailability for all Region 2 and Region 3 faces. +=================+=============+=======+========+================+ | Authority | Power Limit | Power | Duty | Notes | | | | Ref. | Cycle | | +=================+=============+=======+========+================+ | ETSI EN 300 220 | 10 mW | ERP | 10% | Standard EU | | [ETSI-220] (EU) | | | | SRD allocation | +-----------------+-------------+-------+--------+----------------+ | Ofcom IR 2030 | 10 mW | ERP | 10% | Post-Brexit | | (UK) | | | | mirrors ETSI | +-----------------+-------------+-------+--------+----------------+ | Roskomnadzor | 10 mW | — | None | GOST-R | | (RU) | | | stated | framework | +-----------------+-------------+-------+--------+----------------+ | UCRF (UA) | 10 mW | ERP | 10% | EU-aligned | | | | | | post-2022 | +-----------------+-------------+-------+--------+----------------+ | Most of Africa | — | — | — | No harmonized | | | | | | ISM rule | +-----------------+-------------+-------+--------+----------------+ Table 8: 433.05-434.79 MHz (Center: 433.92 MHz) 9.2. 863-870 MHz (ETSI SRD Sub-bands) This band is the primary short-range device allocation for ITU Region 1 and is governed by ETSI EN 300 220 [ETSI-220]. It is not available in Regions 2 or 3. The band is internally divided into sub-bands with significantly different duty cycle and power parameters. Hanley Expires 23 April 2027 [Page 34] Internet-Draft RSDGGS October 2026 +=================+========+=====================+=================+ | Sub-band | Power | Duty Cycle / Access | Primary Use | +=================+========+=====================+=================+ | 863.0-865.0 MHz | 25 mW | 0.1% | Alarms, EN 300 | | | ERP | | 220-2 | +-----------------+--------+---------------------+-----------------+ | 865.0-868.6 MHz | 25 mW | 1% | General SRD | | | ERP | | | +-----------------+--------+---------------------+-----------------+ | 868.6-868.7 MHz | 25 mW | <1% | Alarms | | | ERP | | | +-----------------+--------+---------------------+-----------------+ | 868.7-869.2 MHz | 25 mW | 0.1% | General SRD | | | ERP | | | +-----------------+--------+---------------------+-----------------+ | 869.2-869.4 MHz | 10 mW | <0.1% | Alarms, social | | | ERP | | alarms | +-----------------+--------+---------------------+-----------------+ | 869.4-869.65 | 500 mW | 10% or LBT | High-power SRD, | | MHz | ERP | | LoRa gateway | +-----------------+--------+---------------------+-----------------+ | 869.65-869.7 | 25 mW | <0.1% | Alarms | | MHz | ERP | | | +-----------------+--------+---------------------+-----------------+ | 869.7-870.0 MHz | 5 mW | — | Non-specific | | | ERP | | SRD | +-----------------+--------+---------------------+-----------------+ Table 9: 863-870 MHz (ETSI SRD Sub-bands) 9.3. 902-928 MHz (Center: 915 MHz) This band is governed primarily by FCC Part 15 Subpart C [FCC-15] in the United States and equivalent national regulations in the Americas and selected Asia-Pacific jurisdictions. This band is the primary sub-GHz ISM allocation for ITU Region 2 and selected Region 3 jurisdictions. It is not available in ITU Region 1 (occupied by GSM-R and other licensed services) or in most of Region 3. Hanley Expires 23 April 2027 [Page 35] Internet-Draft RSDGGS October 2026 +=================+============+=======+=======+================+ | Authority | Allocation | Power | Duty | Channelization | | | | | Cycle | / Hopping | +=================+============+=======+=======+================+ | FCC (US) Part | 902-928 | 1 W | None | Hop >= 50 | | 15.247 [FCC-15] | MHz | EIRP | | channels, min | | | | | | 25 kHz | +-----------------+------------+-------+-------+----------------+ | ISED (CA) | 902-928 | 1 W | None | Mirrors FCC | | RSS-210 | MHz | EIRP | | | +-----------------+------------+-------+-------+----------------+ | IFT (MX) | 902-928 | 1 W | None | Mirrors FCC | | | MHz | EIRP | | | +-----------------+------------+-------+-------+----------------+ | Anatel (BR) REF | 902-907.5 | 30 mW | 1% | Fixed or | | 680 | + 915-928 | EIRP | | hopping | | | MHz | | | | +-----------------+------------+-------+-------+----------------+ | ENACOM (AR) | 902-928 | 1 W | None | FCC-aligned | | | MHz | EIRP | | | +-----------------+------------+-------+-------+----------------+ | Subtel (CL) | 902-928 | 1 W | None | FCC-aligned | | | MHz | EIRP | | | +-----------------+------------+-------+-------+----------------+ | ACMA (AU) AS/ | 915-928 | 1 W | None | FCC-aligned | | NZS 4268 | MHz | EIRP | | | +-----------------+------------+-------+-------+----------------+ | RSM (NZ) | 915-928 | 1 W | None | Mirrors ACMA | | | MHz | EIRP | | | +-----------------+------------+-------+-------+----------------+ Table 10: 902-928 MHz (Center: 915 MHz) 9.4. 920-928 MHz Regional Variants +======================+============+========+=======+==============+ | Authority | Allocation | Power | Duty | Modulation / | | | | | Cycle | Notes | +======================+============+========+=======+==============+ | MIC (JP) ARIB | 920.5-928 | 20 mW | 1% | GFSK, 250 | | STD-T108 [ARIB-T108] | MHz | EIRP | | kHz channels | +----------------------+------------+--------+-------+--------------+ | NCC (TW) | 920-925 | 500 | None | Restricted | | | MHz | mW | | bandwidth | | | | EIRP | | | +----------------------+------------+--------+-------+--------------+ | IMDA (SG) | 920-925 | 500 | None | City-state; | | | MHz | mW | | RSL 4-5 | Hanley Expires 23 April 2027 [Page 36] Internet-Draft RSDGGS October 2026 | | | EIRP | | | +----------------------+------------+--------+-------+--------------+ | OFCA (HK) | 920-925 | 100 | None | Enclave; RSL | | | MHz | mW | | 5 required | | | | EIRP | | | +----------------------+------------+--------+-------+--------------+ Table 11: 920-928 MHz Regional Variants The 920-928 MHz band variants are governed by national standards including ARIB STD-T108 [ARIB-T108] in Japan and equivalent regulations in Australia, New Zealand, and other Asia-Pacific jurisdictions. 9.5. TV Whitespace Bands (174-216 MHz, 470-608 MHz) TV whitespace bands are available only within the United States (FCC Part 15 Subpart H) and Canada (ISED RSS-222) under Face 2. Unlike static ISM allocations, whitespace channel availability is geofenced and determined dynamically by a regulatory database query at the time of operation. An RSDGGS cell MUST NOT be used as a static lookup key for whitespace band availability. The RSDGGS index for whitespace-capable devices SHALL be used only to determine whether a whitespace database query is required (RSL 1 sufficient: Face 2 only), and as a location parameter passed to the whitespace database query endpoint. The whitespace database response governs actual channel availability. 10. Regulatory Boundary Zones and Adaptive Compliance Radio frequency energy does not respect political borders. A device operating lawfully under one regulatory framework may radiate a signal that crosses into a neighboring jurisdiction where the same frequency is prohibited or subject to different power and channelization rules. This section defines how RSDGGS encodes proximity to regulatory boundaries, and how the grid index drives adaptive power control and resolution escalation to ensure that IoT devices operating near such boundaries maintain compliance under both the local and neighboring regulatory frameworks. 10.1. Cross-Border Spectrum Governance Framework The international legal framework for managing cross-border spectrum interference operates at four levels, each relevant to the RSDGGS boundary model: Hanley Expires 23 April 2027 [Page 37] Internet-Draft RSDGGS October 2026 10.1.1. ITU Radio Regulations The ITU Radio Regulations [ITU-RR] (RR), maintained as a binding international treaty, constitute the supreme global authority for spectrum coordination. Article 15 of the RR specifies procedures for resolving harmful interference between member administrations, requiring administrations to cooperate in detection and elimination. The Master International Frequency Register (MIFR) provides international recognition and interference protection for registered assignments. ITU Radio Regulation footnote 5.150 designates ISM bands globally; footnote 5.138 designates specific bands in specific regions. Footnote 5.280 specifically notes that the 433.05-434.79 MHz band is designated for ISM applications in a named subset of European countries, establishing that this designation is not universal even within ITU Region 1. For RSDGGS purposes, ITU Region boundaries define the level-0 (single-byte) cell boundaries. Devices at these boundaries encounter the most severe regulatory discontinuities: bands that are legal on one side (e.g., 902-928 MHz in Region 2) are occupied by primary licensed services on the other (GSM-R railways in Region 1). These boundaries are face-edge boundaries in the dodecahedron geometry and are detectable from the face byte of the RSDGGS index. 10.1.2. Bilateral and Multilateral Coordination Agreements Below the ITU level, neighboring administrations negotiate bilateral arrangements governing specific bands along their shared borders. These agreements establish coordination zones — geographic areas on both sides of the border within which proposed assignments require prior approval from the neighboring administration. The zone extent varies by band and agreement: Hanley Expires 23 April 2027 [Page 38] Internet-Draft RSDGGS October 2026 US-Canada (FCC / ISED, per 47 CFR § 1.928 and Arrangements A-Q): Coordination zone: 100-140 km either side of border 800 MHz band zone: 110 km (47 CFR § 90.619) Power limit: ERP and antenna height tables (varies by antenna height above terrain) PFD limit at border: -107 dB(W/m²) for 896-940 MHz US-Mexico (FCC / IFT, per 47 CFR § 90.619): Sharing zone: 110 km from US/Mexico border 800 MHz primary: Channels divided US/MX primary access PFD limit at border: -107 dB(W/m²) for 896-940 MHz Sub-5W stations: Coordinated only on request EU internal borders (CEPT/ECC): ETSI EN 300 220 harmonized across EU — no coordination required for intra-EU 868 MHz SRD operation EU/Russia border: coordination required; no harmonization Figure 14 The 47 CFR § 90.619 power-flux-density limit of -107 dB(W/m²) at the US/Mexico border for the 896-940 MHz band is directly applicable to ISM-adjacent operations. The 110 km coordination zone for 800 MHz band operations represents a precision requirement of approximately 3-4 bytes of RSDGGS resolution to determine border-zone membership accurately. 10.1.3. Technical Mitigation Mechanisms Within coordination zones, administrations enforce technical constraints to limit signal spillover. These mechanisms have direct analogs in RSDGGS-driven adaptive compliance: Hanley Expires 23 April 2027 [Page 39] Internet-Draft RSDGGS October 2026 +===============+==========================+========================+ | Mechanism | Traditional | RSDGGS IoT Analog | | | Deployment | | +===============+==========================+========================+ | Power flux- | Fixed limit at | Computed from distance | | density limit | border line (e.g., | to boundary cell edge | | | -107 dBW/m²) | + TX power | +---------------+--------------------------+------------------------+ | ERP reduction | Graduated by | Graduated by RSDGGS | | | antenna height | resolution steps to | | | above terrain | boundary | +---------------+--------------------------+------------------------+ | Directional | Beam steering away | Not applicable to omni | | antenna null | from border | IoT devices | +---------------+--------------------------+------------------------+ | Antenna | Lowers line-of- | 802.15.4 TX power | | height | sight range | reduction achieves | | restriction | | equivalent range limit | +---------------+--------------------------+------------------------+ | Duty cycle | Border-zone | Tighter duty cycle | | restriction | operational limit | from neighboring rule | | | | set applied | +---------------+--------------------------+------------------------+ Table 12: Technical Mitigation Mechanisms For IoT devices operating under IEEE 802.15.4, directional antenna nulling is generally not available. The primary adaptive mechanism is transmit power reduction, which reduces the effective propagation range and thereby limits the power flux-density at the boundary. RSDGGS provides the geographic trigger for this reduction by computing the distance from the device's current cell to the nearest boundary cell between conflicting rule sets. 10.2. Coordination Zone Geometry and RSDGGS Resolution Coordination zone extents established by bilateral agreements map directly to RSDGGS resolution levels. A device must know its position within the applicable coordination zone to apply the correct power limits. The following table maps representative coordination zone radii to the RSDGGS resolution required for unambiguous zone membership determination: Hanley Expires 23 April 2027 [Page 40] Internet-Draft RSDGGS October 2026 +=============+===================+=======+===================+ | Zone radius | RSDGGS resolution | Bytes | Example agreement | | | needed | | | +=============+===================+=======+===================+ | 140 km | 3 bytes (~65 km | 3 | US-Canada above | | | cells) | | 30 MHz | +-------------+-------------------+-------+-------------------+ | 120 km | 3 bytes (~65 km | 3 | Canada transmit | | | cells) | | sites near border | +-------------+-------------------+-------+-------------------+ | 110 km | 3 bytes (~65 km | 3 | US-Mexico 800 MHz | | | cells) | | sharing zone | +-------------+-------------------+-------+-------------------+ | 30 km | 4 bytes (~4 km | 4 | London, ON | | | cells) | | protection zone | +-------------+-------------------+-------+-------------------+ | 12 nm | 5 bytes (~260 m | 5 | Territorial sea | | | cells) | | boundary | +-------------+-------------------+-------+-------------------+ | < 5 km | 6 bytes (~16 m | 6 | Land border | | | cells) | | crossing point | +-------------+-------------------+-------+-------------------+ Table 13: Coordination Zone Geometry and RSDGGS Resolution The 3-byte resolution (RSL 3, ~65 km cells) is sufficient to determine whether a device is within the 110-140 km coordination zones established by the FCC-ISED and FCC-IFT bilateral agreements. This aligns with the RSL values defined in Section 8.2 for most regulatory jurisdictions. For the innermost protection zones (e.g., the 30 km London, Ontario zone in the FCC-ISED 700 MHz arrangement), 4-byte resolution is required. Maritime territorial sea boundaries require 5-byte resolution. 10.3. Boundary Proximity Function RSDGGS defines a boundary proximity function B(cell, band) that returns the distance in RSDGGS resolution steps between a given cell and the nearest cell boundary at which the applicable rule set for the specified band changes. The function is evaluated against the regulatory database exception table (Section 8.3) and the bilateral coordination zone table. Hanley Expires 23 April 2027 [Page 41] Internet-Draft RSDGGS October 2026 B(cell, band): Input: cell — RSDGGS cell index at current resolution R band — ISM band identifier Output: steps — number of subdivision levels to nearest rule-set-changing boundary 0 = boundary within current cell 1 = boundary in adjacent cell at level R N = boundary N levels away If B(cell, band) == 0: Current cell straddles a regulatory boundary. Device MUST increase resolution until B > 0, or apply the more restrictive of the two rule sets. If B(cell, band) <= THRESHOLD_STEPS: Device is in a coordination zone. Apply boundary_power_profile(cell, band, B). If B(cell, band) > THRESHOLD_STEPS: Device is not in a coordination zone. Apply standard rule set for current cell. Recommended THRESHOLD_STEPS by coordination zone: ITU Region face boundary: B <= 2 (face-edge cells) 110-140 km bilateral zone: B <= 3 (3-byte resolution) 30 km protection zone: B <= 4 (4-byte resolution) 12 nm territorial sea: B <= 5 (5-byte resolution) Figure 15 10.4. Adaptive Power Control at Regulatory Boundaries When a device determines that B(cell, band) <= THRESHOLD_STEPS, it enters boundary-aware operation and applies a graduated power reduction profile. The profile scales transmit power based on the proximity function value, reducing power as the device approaches the boundary such that the power flux-density at the boundary line remains below the applicable coordination threshold. 10.4.1. Power Reduction Profile The transmitted power at proximity step B is: Hanley Expires 23 April 2027 [Page 42] Internet-Draft RSDGGS October 2026 P_tx(B) = min(P_max_local, P_max_neighbor) - G(B) Where: P_max_local = maximum EIRP permitted by local rule set P_max_neighbor = maximum EIRP permitted by neighboring rule set G(B) = graduated reduction factor by proximity step Recommended G(B) values: B >= THRESHOLD: G = 0 dB (no reduction, interior operation) B = 3: G = 3 dB (half power; outer coordination zone) B = 2: G = 6 dB (quarter power; inner zone) B = 1: G = 10 dB (1/10 power; adjacent to boundary) B = 0: G = P_max_local - P_max_neighbor (take minimum of both rule sets) The G(B) values above are RECOMMENDED defaults. Implementations MAY substitute a continuous function: G(d) = 20 * log10(d_0 / d) dB where d is the estimated distance to the boundary in meters and d_0 is the coordination zone radius in meters. This continuous form requires 5-byte resolution to evaluate with adequate precision (cell diameter ~260 m). Figure 16 The minimum neighbor power constraint (taking the minimum of the two rule sets at B=0) is the most conservative applicable interpretation of cross-border coordination obligations. It corresponds to the principle that a device straddling a boundary cannot claim the more permissive of two jurisdictions and must comply with both simultaneously. 10.4.2. Duty Cycle and Dwell Constraints In addition to power reduction, boundary-aware operation applies the more restrictive duty cycle and dwell constraints of the two adjacent rule sets. This is particularly significant at EU/non-EU boundaries where the ETSI 868 MHz sub-band duty cycle limits (0.1% to 10%) differ materially from non-EU frameworks that may impose no duty cycle constraint. Hanley Expires 23 April 2027 [Page 43] Internet-Draft RSDGGS October 2026 At B = 0 (boundary cell), apply: duty_cycle = min(DC_local, DC_neighbor) dwell_s = min(dwell_local, dwell_neighbor) lbt = local_lbt OR neighbor_lbt Example: EU/Russia border, 868 MHz band EU: duty_cycle = 1%, lbt = false (EN 300 220) Russia: duty_cycle = none, lbt = false (GOST-R) → Apply DC = 1%, lbt = false Example: EU/Switzerland border, 868 MHz band EU: ETSI EN 300 220 in full Switzerland: ETSI-aligned (OFCOM, independent) → Effectively identical, no reduction needed → Exception table entry flags as RSL 5 for verification Figure 17 10.5. RSDGGS Resolution Escalation Near Boundaries The closer a device is to a regulatory boundary, the finer the resolution required to accurately determine its position relative to that boundary. RSDGGS defines a resolution escalation requirement: the device MUST maintain a RSDGGS index at a resolution sufficient to resolve its boundary proximity function to at least one non-zero value. Resolution escalation rule: If current_resolution < RSL(face, band): Increase resolution to RSL(face, band). If B(cell, band) == 0 at current_resolution: // Boundary is within current cell — ambiguous Increase resolution by one byte. Re-evaluate B(cell, band). Repeat until B > 0 or resolution == 8 bytes. If resolution == 8 bytes and B == 0: // Device is within ~6 cm of the boundary line // (sub-decimeter precision — effectively on the line) Apply conservative rule: use minimum of both rule sets. Log condition for operator review. Maximum practical resolution for boundary determination: 5 bytes (~260 m) — adequate for bilateral zone classification 6 bytes (~16 m) — adequate for most land borders 7 bytes (~1 m) — adequate for all practical land borders Hanley Expires 23 April 2027 [Page 44] Internet-Draft RSDGGS October 2026 Figure 18 The resolution escalation requirement means that a device moving toward a regulatory boundary will autonomously increase its index precision as it approaches, consuming more power in the cooperative localization process (Section 12) but ensuring that its compliance determination remains accurate. For fixed devices, this escalation occurs once at commissioning and the resulting high-resolution index is stored permanently. The escalation is bounded: for the vast majority of IoT deployments, 3-byte resolution is sufficient for all regulatory decisions and boundary detection. Resolution escalation beyond 5 bytes is only required for devices within approximately 260 m of a land border between jurisdictions with conflicting ISM band rules — a scenario that affects only a small fraction of deployed devices. 10.6. CDDL Schema for Boundary-Aware Operation The following CDDL extensions define the data structures for boundary-aware operation: boundary-context = { cell: rsdggs-cell, ; cell at escalated resolution B: uint, ; boundary proximity steps rule-local: uint, ; rule set ID for current cell rule-neighbor: nil / uint, ; rule set ID of nearest neighbor ; nil if B > THRESHOLD p-tx-dbm: int, ; applied TX power in dBm p-reduction-db: uint, ; dB reduction from P_max_local dc-applied: nil / float, ; applied duty cycle fraction lbt-required: bool, ; LBT enforced } boundary-entry = { ; in regulatory database cell-a: rsdggs-cell, ; cell on one side of boundary cell-b: rsdggs-cell, ; cell on other side band-id: uint, agreement: tstr, ; treaty/agreement citation zone-km: uint, ; coordination zone radius in km pfd-limit-dbwm2: int, ; PFD limit at boundary dB(W/m²) p-max-a-dbm: int, ; max EIRP in cell-a p-max-b-dbm: int, ; max EIRP in cell-b dc-a: nil / float, ; duty cycle in cell-a dc-b: nil / float, ; duty cycle in cell-b } Figure 19 Hanley Expires 23 April 2027 [Page 45] Internet-Draft RSDGGS October 2026 The boundary-entry table in the regulatory database is indexed by the pair (cell-a, cell-b) at the finest resolution at which the two cells are adjacent cells. For face-edge boundaries (ITU Region boundaries), the index is at byte 0 (face only). For bilateral coordination zone boundaries, the index is at bytes 3-4. For land border crossing point exceptions, the index may be at bytes 5-6. The boundary-entry pfd-limit-dbwm2 field enables a device with knowledge of its antenna characteristics and propagation environment to compute the maximum transmit power that keeps its signal below the applicable PFD limit at the boundary. For IoT devices using typical isotropic or near-isotropic antennas, a simplified free-space path loss model is sufficient for this computation. Implementations SHOULD implement the free-space PFD computation as a compile-time table indexed by (distance-to-boundary-km, P_tx-dBm) to avoid floating-point computation on constrained devices. 11. Peer-Assisted Location Discovery Many IoT devices lack GPS receivers or smartphone tethering and have no independent means of determining their geographic location. In conformance with design goal G8 (Section 3), RSDGGS is designed so that a device with no external connectivity — no DHCP server, no DNS, no cloud enrollment, no smartphone tether — SHALL be capable of full regulatory self-configuration through peer interaction alone. RSDGGS defines a peer-assisted discovery mechanism enabling such Naive Devices to derive their applicable regulatory parameters from beacons transmitted by location-aware Beacon Devices in the vicinity. This mechanism is the primary regulatory bootstrap path, not a fallback: centralized provisioning systems such as DHCP servers are optional accelerators, not dependencies. 11.1. Beacon Frame Format A Beacon Device that has resolved its regulatory context SHALL periodically transmit a beacon frame on its active ISM channel. The beacon frame is encoded as a CBOR map and MUST include the beacon- frame structure defined in Section 7.3. The RSDGGS cell in the beacon frame SHALL be encoded at no greater than RSL depth for the band in use, as a privacy measure for the Beacon Device. The transmitted RSDGGS cell inherently encodes which ISM channels are legal at the Beacon Device's location, since the Beacon Device, by definition, is transmitting on a legal channel for its jurisdiction. A Naive Device receiving the beacon on that channel can infer that the channel is legal at the Beacon Device's location. If the Naive Device is in the same RSDGGS cell as the Beacon Device at RSL depth, it MAY apply the same rule set. Hanley Expires 23 April 2027 [Page 46] Internet-Draft RSDGGS October 2026 11.2. Channel Scanning Protocol A Naive Device that has not resolved its regulatory context SHALL implement the following scanning procedure to discover Beacon Devices: 1. The Naive Device MUST scan all channels across the candidate ISM bands for the broadest possible regulatory region. For a device manufactured for global deployment, this includes all of: 433.05-434.79 MHz, 863-870 MHz, 902-928 MHz, and 920-928 MHz. 2. The Naive Device SHALL dwell on each candidate channel for a duration sufficient to receive at least one beacon frame from a Beacon Device operating on that channel, accounting for the maximum permitted beacon interval. 3. Upon receiving a valid beacon frame, the Naive Device SHALL extract the RSDGGS cell and perform a regulatory database lookup to determine the rule set applicable at that cell. 4. If the Naive Device can independently verify that it is within the same RSDGGS cell as the Beacon Device at RSL depth (for example, by RF signal characteristics or approximate location knowledge), it MAY adopt the Beacon Device's rule set and begin operation. 5. If the Naive Device cannot independently verify co-location, it SHALL continue scanning until it receives beacons from multiple Beacon Devices with consistent RSDGGS cells, or until it acquires independent location information. The maximum beacon interval SHALL be no greater than 60 seconds for devices operating in regulatory environments where initial channel selection is required within that interval. Implementations MAY use longer intervals in environments where the regulatory context is known to be stable. 11.3. Regulatory Bootstrap Procedure The complete regulatory bootstrap procedure for a Naive Device is as follows: 1. Power on. No regulatory context assumed. 2. Begin channel scan as defined in Section 10.2. 3. On receiving a beacon frame with a valid RSDGGS cell: Hanley Expires 23 April 2027 [Page 47] Internet-Draft RSDGGS October 2026 a. Extract cell bytes. b. Perform database lookup: is the received channel legal for the cell's rule set? c. If legal: tentatively adopt rule set. Increment confidence counter. d. If illegal: discard beacon. This may indicate the Beacon Device is non-compliant or the Naive Device is in a different jurisdiction. 4. When confidence threshold is reached (RECOMMENDED: 3 consistent beacons from 1 or more Beacon Devices within the same RSL cell): a. Adopt rule set as operational regulatory context. b. Store RSDGGS cell in non-volatile memory. c. Begin normal operation on permitted channels. 5. Periodically re-validate regulatory context by continuing to receive beacons. If the device moves (as determined by a change in the received RSDGGS cell at RSL depth), restart the bootstrap procedure. 12. Manufacturing Provisioning Use Case RSDGGS enables a single global hardware SKU to be provisioned with location-specific regulatory parameters at manufacturing time, eliminating the need for hardware or firmware variants differentiated by target market. Pre-provisioning at manufacturing time is one of three equally valid provisioning paths; the others are peer-assisted bootstrap (Section 11) and tethered-device provisioning (Section 11.3). In all three cases, the provisioned RSDGGS cell is stored in non-volatile device memory and does not require ongoing connectivity to any server to be applied. This section does not preclude optional use of infrastructure-based provisioning mechanisms such as DHCPv6 (analogous to RFC 3825, which defines a DHCP option for geodetic coordinates) or cloud enrollment APIs using device authorization flows such as those defined in [RFC8628]. However, in conformance with design goal G8, infrastructure-based provisioning MUST NOT be the only path to regulatory compliance. Any device provisioned via DHCP or cloud enrollment MUST also be capable of regulatory self-configuration via peer discovery if the infrastructure becomes unavailable. Hanley Expires 23 April 2027 [Page 48] Internet-Draft RSDGGS October 2026 The manufacturing provisioning procedure is as follows: 1. The deployment location is determined at order entry, warehouse assignment, or installation scheduling. The RSDGGS cell for the deployment location is computed at RSL depth for the intended ISM band. 2. The RSDGGS cell (1 to 4 octets for most fixed deployments) is written to the device's non-volatile configuration store during manufacturing or pre-shipment provisioning, alongside the target band identifier. 3. At first boot, the device performs a regulatory database lookup using the stored cell to retrieve the applicable rule set. The device configures its radio stack with the retrieved parameters: center frequency, channel plan, transmit power, duty cycle timer, dwell timer, LBT engine, and modulation. 4. The device MAY verify its provisioned cell against independently acquired location information (GPS, beacon scan) if such capability is available. Mismatches SHOULD be flagged for operator review. This approach yields several manufacturing benefits: * A single firmware image supports all markets. Regulatory differentiation is entirely data-driven. * The RSDGGS cell is human-readable as a short hex string and can be included in the device's bill of materials and shipping documentation. * Privacy is inherent: a 3-byte cell (country-level precision) stored in the device does not disclose the precise installation address. * Regulatory database updates are decoupled from firmware updates. Changes to national power limits or channelization can be distributed as database patches without reflashing devices. * Devices deployed in regions requiring only a 1-byte cell (e.g., anywhere in North America for 902 MHz) can be provisioned with a single byte, minimizing configuration data. Hanley Expires 23 April 2027 [Page 49] Internet-Draft RSDGGS October 2026 13. Cooperative Localization A Naive Device that has no independent means of determining its geographic location MAY infer its position through cooperative localization: a process by which the device aggregates RSDGGS cell assertions, signal strength measurements, and precision ranging measurements from multiple peers to derive a position estimate expressed as an RSDGGS cell at the finest resolution consistent with the accumulated measurement uncertainty. This section defines the localization method hierarchy, the procedures for each method, the RSDGGS-native position state space, and the integration of these methods into a unified estimation engine. IEEE 802.15.4a HRP UWB ranging [IEEE802154a] and IEEE 802.15.4z enhanced ranging [IEEE802154z] are defined as the highest- precision input to the estimation engine and are treated in detail. 13.1. Localization Method Hierarchy Three localization methods are defined, ordered from coarsest to finest achievable precision. The methods are composable: a device SHOULD apply all available methods simultaneously, using each as a weighted input to the unified estimation engine defined in Section 11.6. +=================+===============+===================+============+ | Method | Input | Typical Precision | 802.15.4 | | | | | Primitive | +=================+===============+===================+============+ | M1 — Cell | RSDGGS cells | Cell resolution | Beacon / | | Intersection | from peers | of peers | Enhanced | | | | | Beacon | +-----------------+---------------+-------------------+------------+ | M2 — RSSI | Round-trip | 10–50 m | Data frame | | Multilateration | RSSI + path | (outdoor), 20–100 | + Enhanced | | | loss model | m (indoor) | ACK | +-----------------+---------------+-------------------+------------+ | M3 — UWB | DS-TWR | 0.1–0.5 m (LoS), | HRP UWB | | Ranging | timestamps | 0.3–1 m (NLoS) | ranging | | | (802.15.4a/z) | | exchange | +-----------------+---------------+-------------------+------------+ Table 14: Localization Method Hierarchy Hanley Expires 23 April 2027 [Page 50] Internet-Draft RSDGGS October 2026 A device with access only to Method M1 can resolve its RSDGGS cell to the intersection of its peers' cells, typically 2–4 bytes of resolution. A device with M2 capability can typically achieve 6-byte resolution (~16 m cells) in outdoor environments. A device with M3 capability can achieve 7–8 byte resolution (~1 m to ~6 cm cells) in line-of-sight conditions. 13.2. RSDGGS Cell Intersection Each beacon received from a peer carries an RSDGGS cell at the RSL depth for the transmitting channel. The Naive Device accumulates received cells and maintains the geographic intersection of all received cells as a constraint on its own position. The intersection of two RSDGGS cells is defined as the longest common prefix of their bit representations. If two cells share a common prefix of length L bits, then any point within both cells must lie within the geographic region represented by that L-bit prefix. The intersection cell is that prefix, truncated to the nearest byte boundary. Every octet boundary is a subdivision-level boundary (Section 5.1), so the truncated prefix is always a valid index. Cell intersection algorithm: received_cells: list of (cell_bytes, peer_id) intersection: uint64_t initialized to 0 valid_bits: uint = 64 for each (cell, peer) in received_cells: cell_u64 = cell padded to 8 bytes (zero-extended) xor = intersection XOR cell_u64 // find highest differing bit diff_bit = 64 - clz(xor) // clz = count leading zeros if diff_bit < valid_bits: valid_bits = diff_bit intersection = cell_u64 & ~((1 << diff_bit) - 1) resolution_bytes = valid_bits / 8 // floor inferred_cell = intersection >> (64 - resolution_bytes*8) Figure 20 As additional peers are heard, valid_bits can only decrease or remain constant, monotonically converging toward the finest common prefix. When peers at higher resolution (more bytes) are heard, the intersection tightens. A Naive Device SHOULD advertise its inferred cell at the current resolution once it has received cells from at least three peers, to assist other Naive Devices in the vicinity. Hanley Expires 23 April 2027 [Page 51] Internet-Draft RSDGGS October 2026 13.3. Round-Trip RSSI Range Estimation RSSI-based range estimation uses the log-distance path loss model to convert measured signal strength to a distance estimate. The round- trip exchange eliminates first-order asymmetric fading bias by averaging path loss in both directions. 13.3.1. Round-Trip RSSI Exchange Procedure Initiator A Responder B | | |-- Data(cell_A, req_rssi) -->>| RSSI_B_rx = RSSI of frame at B | | |<<--- Enhanced ACK(RSSI_B_rx) -------| RSSI_A_rx = RSSI of ACK at A | | |-- RSSI Report(RSSI_A_rx) -------->>| | | Both nodes now hold (RSSI_B_rx, RSSI_A_rx) Path loss = (RSSI_tx_A - RSSI_B_rx + RSSI_tx_B - RSSI_A_rx) / 2 Figure 21 13.3.2. Range Estimation The range estimate from bidirectional path loss is computed using the log-distance model. Path loss exponent n and reference path loss PL(d0) at reference distance d0 are environmental parameters stored in device configuration. PL = (TX_power_A - RSSI_B_rx + TX_power_B - RSSI_A_rx) / 2 [dB] Range estimate: d = d0 * 10 ^ ((PL_measured - PL(d0)) / (10 * n)) [meters] Range uncertainty (1-sigma): sigma_d = (ln(10) / (10*n)) * d * sigma_PL sigma_PL: shadowing standard deviation, typically 4-8 dB Recommended defaults (absent site survey): d0 = 1.0 m PL(d0)= 40.0 dB (2.4 GHz free space at 1 m) n = 2.7 (light indoor / suburban) sigma = 6.0 dB Figure 22 Hanley Expires 23 April 2027 [Page 52] Internet-Draft RSDGGS October 2026 The range estimate d and uncertainty sigma_d from each peer constitute one range measurement for input to the multilateration engine in Section 11.6. Multiple round-trip exchanges with the same peer SHOULD be averaged to reduce the contribution of sigma_PL. The minimum recommended number of exchanges per peer before using the range in multilateration is three. 13.4. IEEE 802.15.4a/z UWB Precision Ranging IEEE 802.15.4a defines the High-Rate Pulse (HRP) UWB physical layer and the ranging primitives used to achieve centimeter-class range measurements. IEEE 802.15.4z augments these with the Scrambled Timestamp Sequence (STS) for cryptographic binding of timestamps to a shared session key, preventing range manipulation by adversarial nodes. 13.4.1. Double-Sided Two-Way Ranging (DS-TWR) Double-Sided Two-Way Ranging eliminates the first-order clock offset bias present in Single-Sided TWR. It requires three messages: Poll, Response, and Final, with optional Report for enhanced bias cancellation. Initiator A Responder B | | |== Poll (SP1/SP3, STS) =============>>| t1(A), t2(B) | | |<<= Response (SP1/SP3, STS) =========| t3(B), t4(A) | | |== Final (SP1/SP3, STS) =============>>| t5(A), t6(B) | | |<<= Report (optional) ===============| B sends t2,t3,t6 to A | | Single-sided ToF (A's perspective): ToF_A = ((t4 - t1) - (t3 - t2)) / 2 Double-sided ToF (eliminates clock offset): ToF = ((t4-t1)(t6-t3) - (t3-t2)(t5-t4)) / (2 * ((t4-t1) + (t6-t3))) Range = ToF * c (c = 299,792,458 m/s) Typical precision: +/- 10 cm LoS, +/- 30-50 cm NLoS Figure 23 Hanley Expires 23 April 2027 [Page 53] Internet-Draft RSDGGS October 2026 13.4.2. STS Authentication (802.15.4z) The Scrambled Timestamp Sequence (STS) field, defined in IEEE 802.15.4z, is a pseudorandom sequence generated from a shared session key known only to legitimate peers. The STS is embedded in the UWB pulse train immediately before the ranging timestamp. A receiver can authenticate that the timestamp was generated by a node holding the shared key, preventing a malicious node from injecting false timestamps to manipulate range estimates. Implementations using cooperative localization for regulatory compliance MUST use SP1 or SP3 packet formats with STS enabled when UWB ranging is available. The STS session key SHALL be derived from the network join credentials established during PAN association, ensuring that only authenticated PAN members can contribute ranging measurements to the localization engine. Implementations MUST reject ranging measurements from peers that fail STS authentication. A pattern of STS authentication failures from a specific peer SHOULD be reported to the application layer as a potential ranging attack. 13.4.3. Phase Difference of Arrival (PDOA) Angle Estimation Devices equipped with two or more UWB antennas separated by a known baseline d_ant MAY compute the angle of arrival of a UWB signal using the phase difference between antennas. The angle estimate provides a directional constraint that supplements the scalar range measurement. PDOA angle estimation: delta_phi: measured phase difference between antennas [radians] d_ant: antenna separation [meters] lambda: UWB center wavelength [meters] theta = arcsin(delta_phi * lambda / (2 * pi * d_ant)) [radians] Uncertainty: sigma_theta = sigma_phi * lambda / (2 * pi * d_ant * cos(theta)) Typical: +/- 5 degrees at 50 cm baseline, +/- 2 degrees at 1.25 m Figure 24 Hanley Expires 23 April 2027 [Page 54] Internet-Draft RSDGGS October 2026 The PDOA angle theta and uncertainty sigma_theta from each UWB- capable peer constitute an angular measurement for input to the multilateration engine. The combination of DS-TWR range and PDOA angle from a single peer provides a 2D position fix relative to that peer, without requiring a second ranging peer. 13.5. RSDGGS as Position State Space Rather than maintaining a floating-point latitude/longitude position estimate, the cooperative localization engine represents position state natively as an RSDGGS cell index at the finest resolution consistent with the current position uncertainty. This representation is exact within the quantization of the cell size, requires no floating-point arithmetic at the application layer, and directly produces the regulatory cell needed for ISM band validation. +======================+============+========================+ | Position Uncertainty | RSDGGS | Primary Source | | (1-sigma) | Resolution | | +======================+============+========================+ | > 7,000 km | 1 byte | No measurement; prior | | | (face) | only | +----------------------+------------+------------------------+ | 1,000 – 7,000 km | 2 bytes | Cell intersection (1-2 | | | | peers) | +----------------------+------------+------------------------+ | 65 – 1,000 km | 3 bytes | Cell intersection (3+ | | | | peers), RSL sufficient | +----------------------+------------+------------------------+ | 4 – 65 km | 4 bytes | Cell intersection | | | | (dense); coarse RSSI | +----------------------+------------+------------------------+ | 260 m – 4 km | 5 bytes | RSSI multilateration | | | | (outdoor) | +----------------------+------------+------------------------+ | 16 – 260 m | 6 bytes | RSSI multilateration | | | | (dense urban) | +----------------------+------------+------------------------+ | 1 – 16 m | 7 bytes | UWB NLoS / dense RSSI | +----------------------+------------+------------------------+ | < 1 m | 8 bytes | UWB DS-TWR LoS | | | (max) | | +----------------------+------------+------------------------+ Table 15: RSDGGS as Position State Space Hanley Expires 23 April 2027 [Page 55] Internet-Draft RSDGGS October 2026 The position uncertainty is maintained as a single integer sigma_cells, representing the radius of the position uncertainty ellipse in units of RSDGGS cells at the current resolution. When sigma_cells falls below 1 at the current resolution, the resolution is incremented (one byte added) and sigma_cells is recomputed in terms of the finer cells. When sigma_cells grows beyond a threshold (RECOMMENDED: 4 cells), the resolution is decremented (one byte removed). This adaptive quantization ensures that the RSDGGS cell always represents the region within which the device's true position lies with high probability, without overstating precision. A device reporting its cell at 3-byte resolution is asserting that its position is within the corresponding 65 km cell; a device reporting at 7-byte resolution is asserting position within 1 m. 13.6. Weighted Multilateration Engine The multilateration engine fuses M1 (cell intersection), M2 (RSSI range), and M3 (UWB range and angle) measurements into a unified position estimate in RSDGGS space. The engine operates iteratively, updating the position state each time a new measurement arrives. 13.6.1. Measurement Model Each peer P_i contributes one or more of the following measurements: * Cell assertion C_i: the RSDGGS cell of P_i, known from beacon reception. Constrains the device position to the intersection of C_i and the current position cell. * RSSI range r_i with uncertainty sigma_i: derived from round-trip RSSI exchange per Section 11.3. * UWB range R_i with uncertainty epsilon_i: derived from DS-TWR per Section 11.4.1. * PDOA angle theta_i with uncertainty delta_i: derived from PDOA per Section 11.4.3. 13.6.2. Weighted Least Squares Position Update Given ranges {r_i} or {R_i} to N peers at known cells {C_i}, the position update minimizes the weighted sum of squared residuals: Hanley Expires 23 April 2027 [Page 56] Internet-Draft RSDGGS October 2026 Minimize: sum_i ( w_i * (d(pos, C_i_center) - r_i)^2 ) w_i = 1 / sigma_i^2 (RSSI) or 1 / epsilon_i^2 (UWB) d(.,.) = great-circle distance between RSDGGS cell centers Cell center of an RSDGGS cell: Midpoint of the bounding isosceles triangle at that resolution, computed from the triangle vertex positions on the unit sphere. Minimum peers required for 2D fix: M1 only: 3 peers (for non-degenerate intersection) M2 (RSSI range only): 3 peers (trilateration) M3 (UWB range only): 2 peers (+ PDOA) or 3 peers (range only) M3 (range + PDOA): 1 peer (2D fix relative to peer) Figure 25 For constrained devices, a closed-form linearized solution is RECOMMENDED over iterative nonlinear solvers. The linearization uses the current position estimate as the operating point and applies a first-order Taylor expansion of the range function, reducing the problem to a linear least squares system solvable by the normal equations. This requires only integer arithmetic in RSDGGS cell units and is implementable on Cortex-M0 class devices. 13.7. Extended Kalman Filter Integration For mobile devices, the multilateration engine is augmented with a discrete-time Extended Kalman Filter (EKF) that propagates the position estimate through time using a motion model and updates it with incoming measurements. 13.7.1. State Vector State vector x = [cell_index, velocity_cells_per_sec, sigma_cells] cell_index: uint64_t, RSDGGS cell at current resolution velocity: signed integer, cells/second at resolution zero for fixed devices sigma_cells: uint16_t, position uncertainty radius in cells Figure 26 13.7.2. Prediction Step Hanley Expires 23 April 2027 [Page 57] Internet-Draft RSDGGS October 2026 Prediction (between measurements, interval dt seconds): x_pred = x + velocity * dt [cell index advance] P_pred = P + Q * dt [covariance propagation] Q: process noise covariance Fixed device: Q = 0 (no motion expected) Pedestrian: Q corresponds to ~1.5 m/s max velocity Vehicle: Q corresponds to ~30 m/s max velocity Cell adjacency graph used for index advance: neighbor cell in direction of velocity vector derived from dodecahedron subdivision adjacency Figure 27 13.7.3. Update Step Each incoming measurement (RSSI range, UWB range, PDOA angle, or cell assertion) constitutes a Kalman update. The measurement Jacobian H maps from the state vector to the expected measurement, evaluated at the current predicted state. The Kalman gain weights the measurement relative to the predicted state uncertainty. Cell assertions from Method M1 are incorporated as a hard constraint: if the current predicted position cell is inconsistent with the received peer cell, the position state is reset to the intersection cell and the uncertainty sigma_cells is set to reflect the intersection cell size. This prevents the EKF from drifting outside the hard geographic bounds established by peer cell assertions. For fixed devices, the EKF reduces to a static estimator. The prediction step adds no uncertainty (Q = 0) and successive measurements monotonically reduce sigma_cells until the RSDGGS resolution stabilizes at 7–8 bytes for UWB-capable deployments, or 5–6 bytes for RSSI-only deployments. 13.8. Security Considerations for Cooperative Ranging Cooperative localization introduces attack surfaces that are not present in GPS-based positioning or static provisioning. An adversarial node could transmit false RSDGGS cells, false RSSI values, or manipulated UWB timestamps to induce a Naive Device to believe it is in a different regulatory jurisdiction, potentially causing it to operate on illegal channels. Hanley Expires 23 April 2027 [Page 58] Internet-Draft RSDGGS October 2026 Cell Assertion Spoofing: A malicious peer could broadcast a false RSDGGS cell, causing the Naive Device to adopt an incorrect regulatory rule set. Mitigation: require cell assertions from a minimum of three independent peers before adopting a regulatory context (Section 10.3). Cells from multiple independent peers that are mutually consistent are significantly harder to spoof collectively. RSSI Manipulation: A high-power transmitter could present an artificially strong RSSI, causing the localization engine to place the Naive Device's position erroneously close to the adversary. Mitigation: apply a maximum plausible range gradient filter; discard measurements where round-trip RSSI implies an implausibly large or small range given the known transmit power. UWB Timestamp Manipulation: Without STS authentication, a malicious node could inject false timestamps in the DS-TWR exchange, inducing a false range measurement. Mitigation: use STS-authenticated ranging (SP1 or SP3 packet formats) as REQUIRED in Section 11.4.2. Discard all UWB range measurements from peers that fail STS authentication. Regulatory Boundary Induction: A coordinated attack by multiple adversarial nodes could attempt to place a Naive Device's inferred cell at a regulatory boundary, inducing the device to apply an incorrect rule set. Mitigation: when the inferred cell straddles a regulatory boundary (as indicated by the exception flag in the regulatory database), require UWB-authenticated ranging to at least one peer before committing to a regulatory context. 14. IEEE 802.15.4 Information Element Encoding 14.1. IE Structure and Constraints IEEE 802.15.4-2020 defines two classes of Information Elements (IEs) that may be included in MAC frames. Header IEs carry type 0 with IDs in the range 0x00 to 0x7E and a maximum payload of 127 octets. Payload IEs carry type 1 with Group IDs in the range 0x00 to 0x0F and a maximum payload of 2047 octets. Payload IEs may contain nested Sub-IEs. The MLME Payload IE (Group ID 0x01) is the standard container for MAC-layer management sub-elements including the SUN (Smart Utility Network) Device Description Sub-IEs defined in IEEE 802.15.4g and extended in IEEE 802.15.4-2020 Section 7.4. RSDGGS location information is carried as a new Sub-IE nested within this container. The Sub-IE header structure is two octets: Hanley Expires 23 April 2027 [Page 59] Internet-Draft RSDGGS October 2026 Sub-IE Header (2 octets): Bits [15:8] Sub-IE ID (8 bits) — assigned by IEEE RA Bits [7:0] Length (8 bits) — payload length in octets Sub-IE Payload (1-8 octets): RSDGGS cell bytes, variable length The Length field value equals the number of RSDGGS cell octets and therefore directly encodes the spatial resolution of the index, consistent with the CBOR encoding defined in Section 7. Figure 28 14.2. RSDGGS Location Sub-IE Definition The RSDGGS Location Sub-IE is defined as follows. The Sub-IE ID value is pending assignment by the IEEE Registration Authority. The placeholder value 0x9A is used in this document. +============+======+==========+==================================+ | Field | Bits | Value | Description | +============+======+==========+==================================+ | Sub-IE ID | 15:8 | 0x9A | RSDGGS Location Sub-IE | | | | (TBD) | identifier | +------------+------+----------+----------------------------------+ | Length | 7:0 | 0x01 to | Number of RSDGGS cell octets; | | | | 0x08 | encodes resolution | +------------+------+----------+----------------------------------+ | Cell[0] | — | variable | Celestial body selector (bits | | | | | 7-4) and dodecahedron face index | | | | | 0-11 (bits 3-0); mandatory | +------------+------+----------+----------------------------------+ | Cell[1..7] | — | variable | Triangle index (Cell[1] bits | | | | | 7-4) and subdivision levels, | | | | | present per Length field | +------------+------+----------+----------------------------------+ Table 16: RSDGGS Location Sub-IE Definition A receiver MUST interpret the Length field as the RSDGGS resolution level. A Length of 1 indicates face-only resolution. A Length of 0 is invalid and MUST be rejected. A Length greater than 8 is invalid and MUST be rejected. Reserved face values (0xC to 0xF in Cell[0] bits 3-0) MUST be treated as an error condition. A Length of 2 or more with a reserved triangle index (Cell[1] bits 7-4 in the range 0x5 to 0xF) MUST be treated as an error condition. Hanley Expires 23 April 2027 [Page 60] Internet-Draft RSDGGS October 2026 The Sub-IE MAY appear in any MAC frame type that permits Payload IEs, including Beacon frames, Enhanced Beacon frames, Data frames, and Command frames. It SHALL appear in the SUN Device Description payload of Enhanced Beacon frames transmitted by devices that have resolved their regulatory context. 14.3. SUN Device Description Integration The SUN Device Description IE (Sub-IE ID 0x08 within the MLME Payload IE group) is transmitted by SUN devices during PAN formation and association to advertise device capabilities. The RSDGGS Location Sub-IE SHALL be included in the SUN Device Description payload of any device that has resolved its regulatory context. The resolution at which the RSDGGS cell is encoded in the Sub-IE SHALL be the Resolution Sufficiency Level (RSL) for the ISM band on which the frame is transmitted, as defined in Section 8.2. This ensures that the regulatory cell carried in the IE is sufficient for a receiving device to determine the applicable rule set, while not disclosing more precise location than required for regulatory purposes. The Sub-IE Length field thus serves three simultaneous functions: it specifies the IE payload length as required by the 802.15.4 framing specification; it encodes the RSDGGS resolution level implicitly; and it signals the privacy posture of the transmitting device (a shorter cell = coarser location = more privacy-preserving). Enhanced Beacon Frame (abbreviated): MHR Payload IE: Group ID = 0x01 (MLME) Sub-IE: ID = 0x08 (SUN Device Description) ... capability fields ... Sub-IE: ID = 0x9A (RSDGGS Location) Length = 0x03 (3 octets, country-level RSL) Cell = 0x02 0x21 0xF7 ^^^^ face 2 = ITU Region 2 / N. America ^^^^ ^^^^ triangle 2, 6 levels: ~65 km cell MFR Figure 29 14.4. MAC-Layer Regulatory Bootstrap The inclusion of RSDGGS location in the SUN Device Description enables regulatory bootstrap at the MAC layer, prior to any application stack initialization. The procedure is as follows: Hanley Expires 23 April 2027 [Page 61] Internet-Draft RSDGGS October 2026 1. A Naive Device scans for Enhanced Beacon frames on candidate ISM channels as defined in Section 10.2. 2. On receiving an Enhanced Beacon containing a SUN Device Description with an RSDGGS Location Sub-IE, the Naive Device extracts the cell bytes. 3. The Naive Device performs a regulatory database lookup using the received cell at the encoded resolution level. 4. If the channel on which the beacon was received is consistent with the rule set for the received cell, the Naive Device MAY adopt the rule set as its operational regulatory context and join the PAN. 5. The PAN coordinator, upon receiving an Association Request from a Naive Device, SHOULD validate that the requesting device's RSDGGS Location Sub-IE (if present) is consistent with the coordinator's own cell at RSL depth. Devices whose cells are inconsistent with the PAN coordinator's cell at RSL depth SHOULD NOT be admitted to the PAN without operator override, as they may be operating under a different regulatory framework. This MAC-layer integration enables fully automated regulatory provisioning during PAN formation, with no application-layer involvement. A device joining a well-managed SUN PAN will have its regulatory context resolved as a side effect of the standard association procedure. 15. IPv6 Geographic Addressing The full 8-octet RSDGGS index fits precisely within the 64-bit Interface Identifier (IID) field of an IPv6 address. This alignment enables a class of IPv6 addresses in which the IID encodes a geographic cell rather than a hardware identifier, enabling geographic routing without a routing table. 15.1. Address Structure An RSDGGS Geographic IPv6 address is structured as follows: Hanley Expires 23 April 2027 [Page 62] Internet-Draft RSDGGS October 2026 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RSDGGS Geographic Prefix (64 bits) | | Identifies this as a geographic address space | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RSDGGS Cell Index — Interface Identifier (64 bits) | | [face][triangle][subdiv level 1]..[subdiv level 26][rsvd] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 30 The upper 64 bits form the network prefix, which identifies the address as belonging to the RSDGGS geographic address space. This prefix is to be assigned from the IANA Special-Purpose Address Registry [RFC6890] for use with this specification. The placeholder prefix GEO::/64 is used in this document pending IANA assignment. The lower 64 bits are the RSDGGS cell index in the 8-octet encoding defined in Section 5, with the most significant byte (Octet 0, the face byte) placed in the most significant octet of the IID. Unused subdivision bits in the terminal resolution level are set to zero. The address is self-describing at any prefix length: the geographic region corresponding to a /N prefix is the set of RSDGGS cells sharing the same upper N bits of their IID. This is directly equivalent to RSDGGS index truncation at the corresponding resolution level. 15.2. Prefix Hierarchy and Aggregation The RSDGGS hierarchical structure maps directly onto IPv6 prefix aggregation. The following prefix lengths correspond to RSDGGS resolution levels: Hanley Expires 23 April 2027 [Page 63] Internet-Draft RSDGGS October 2026 +=============+=============+===============+=====================+ | IPv6 Prefix | RSDGGS Bits | Cell Diameter | Geographic Scope | +=============+=============+===============+=====================+ | /72 | 8 (body + | ~7,000 km | ITU Region / | | | face) | | dodecahedron face | +-------------+-------------+---------------+---------------------+ | /76 | 8 + 4 | ~4,500 km | Triangle sector | | | (triangle) | | within face | +-------------+-------------+---------------+---------------------+ | /80 | 16 (2 | ~1,000 km | Equivalent to | | | octets) | | 2-byte RSDGGS | +-------------+-------------+---------------+---------------------+ | /88 | 24 (3 | ~65 km | Country-level | | | octets) | | (3-byte RSDGGS RSL) | +-------------+-------------+---------------+---------------------+ | /96 | 32 (4 | ~4 km | Metro area (4-byte | | | octets) | | RSDGGS) | +-------------+-------------+---------------+---------------------+ | /104 | 40 (5 | ~260 m | Block level (5-byte | | | octets) | | RSDGGS) | +-------------+-------------+---------------+---------------------+ | /112 | 48 (6 | ~16 m | Building (6-byte | | | octets) | | RSDGGS) | +-------------+-------------+---------------+---------------------+ | /120 | 56 (7 | ~1 m | Device location | | | octets) | | (7-byte RSDGGS) | +-------------+-------------+---------------+---------------------+ | /128 | all 64 bits | ~6 cm | Precise device | | | | | address | +-------------+-------------+---------------+---------------------+ Table 17: Prefix Hierarchy and Aggregation A /72 prefix encompasses all devices in a single ITU Region. A /88 prefix encompasses all devices within a single country-scale cell. This aggregation is lossless: any RSDGGS cell address is aggregatable at any of the above prefix boundaries without loss of hierarchical information. Routing tables for geographic address spaces can therefore aggregate aggressively. A continental backbone router needs only /72 or /80 routes. A national backbone router needs only /88 routes. A metropolitan router needs only /96 routes. Leaf-level routing to specific devices uses the full /128. Hanley Expires 23 April 2027 [Page 64] Internet-Draft RSDGGS October 2026 15.3. Geographic Greedy Forwarding A forwarder holding an RSDGGS Geographic IPv6 address for itself and receiving a packet destined for another geographic address can make a forwarding decision purely from address arithmetic, without a routing table. Forwarding algorithm: G_self = local RSDGGS cell (from own address IID) G_dest = destination RSDGGS cell (from packet dest IID) G_next = next-hop RSDGGS cell (from neighbor table) common_prefix_len(A, B): count of matching most-significant bits in IID of A and B progress(A, B, target): common_prefix_len(A, target) > common_prefix_len(B, target) For each candidate next hop N in neighbor table: if progress(G_next[N], G_self, G_dest): forward to N // N is geographically closer to destination If no progress possible: invoke void handling (perimeter routing or buffer-and-wait) Figure 31 The progress metric is purely a comparison of common prefix lengths. No trigonometric computation is required at forwarding time. The geographic distance relationship is encoded in the shared prefix structure of the RSDGGS hierarchy: a longer common prefix means a smaller shared cell means geographic proximity. This forwarding algorithm is equivalent to greedy geographic forwarding as used in GPSR [GPSR] and similar protocols, but operates on the RSDGGS index structure directly rather than on Euclidean or great-circle distance. The computational cost at each hop is a bitwise XOR and leading-zero count — operations available as single instructions on all target architectures including constrained microcontrollers. Hanley Expires 23 April 2027 [Page 65] Internet-Draft RSDGGS October 2026 15.4. Regulatory-Aware Channel Selection for Forwarding The geographic address carries implicit regulatory information through the face byte of the IID. A forwarder can extract the face byte of the destination address to determine the ITU Region of the destination, and therefore the ISM band availability at the destination. When a packet is forwarded toward a destination in a different regulatory cell, the forwarding node SHOULD select a transmission channel that is legal in both its own regulatory cell and the next- hop's regulatory cell. If no such channel exists (for example, forwarding from an EU 868 MHz network toward a US 915 MHz network), the forwarder MUST NOT transmit on a channel that is illegal in either jurisdiction. In practice, cross-regulatory-region forwarding at the ISM layer requires either a gateway device provisioned for both regulatory environments, or an application-layer relay. The geographic address structure makes this boundary explicit and machine-readable: a mismatch in the face byte of the IID between source and destination indicates a cross-regulatory-region path that requires special handling. Regulatory boundary detection: src_face = (src_IID >> 56) & 0x0F dest_face = (dest_IID >> 56) & 0x0F if src_face != dest_face: // Cross-face (potentially cross-regulatory) forward // Consult RSL table for band compatibility // Select channel legal in both faces or flag for gateway Figure 32 15.5. Relationship to Existing Standards The RSDGGS Geographic IPv6 addressing scheme intersects with the following existing standards and efforts, from which it draws and to which it contributes: Hanley Expires 23 April 2027 [Page 66] Internet-Draft RSDGGS October 2026 RFC 4944 / RFC 6282 (6LoWPAN): The IID derivation from EUI-64 defined in RFC 4944 is not applicable to geographic addresses. Implementations using RSDGGS Geographic addressing over 802.15.4 SHALL use the RSDGGS cell as the IID directly and MUST NOT apply the EUI-64 IID derivation procedure. The 6LoWPAN header compression schemes defined in RFC 6282 are applicable to geographic addresses with the understanding that the IID carries geographic rather than hardware identity. RFC 6775 (6LoWPAN-ND): The Neighbor Discovery optimization defined in RFC 6775 for low-power networks applies to geographic addresses. The geographic IID provides a natural mechanism for duplicate address detection in dense deployments: two devices with the same geographic cell at maximum resolution are, by definition, co-located within approximately 3 centimeters and may legitimately share an address for aggregated sensing applications. RFC 9854 (AODV-RPL): Geographic greedy forwarding as defined in Section 13.3 eliminates the need for route discovery in dense geographic deployments. AODV-RPL route discovery MAY be used as a fallback void-handling mechanism when greedy forwarding cannot make progress, for example in sparse networks with geographic holes. The RSDGGS cell can serve as the position metric in AODV-RPL's P2P route discovery in place of GPS coordinates, enabling route discovery on devices without GPS receivers. ETSI EN 302 931 (GeoNetworking): The European ITS GeoNetworking standard defines geographic addressing over 802.11p and LTE for vehicular networks. RSDGGS Geographic IPv6 addressing is an alternative approach designed for low-power ISM-band IoT networks rather than vehicular ITS, with the additional property of encoding regulatory jurisdiction within the address structure. IEEE 802.15.4 SUN: The MAC-layer integration defined in Section 12 and the IPv6 geographic addressing defined in this section are complementary. A SUN network using RSDGGS Location Sub-IEs at the MAC layer and RSDGGS Geographic IPv6 addresses at the network layer achieves end-to-end geographic addressing from the MAC frame through the IP datagram, with regulatory context embedded at both layers. 16. Relationship to Prior Geographic Addressing Work Several IETF documents address geographic location representation, conveyance, and routing. This section compares each to RSDGGS, identifying the gaps that RSDGGS addresses and the areas where these prior works remain authoritative and complementary. Hanley Expires 23 April 2027 [Page 67] Internet-Draft RSDGGS October 2026 The fundamental distinction between RSDGGS and all prior work is axis of design: the existing RFCs treat geographic location as a property to be conveyed alongside an application or network protocol, using coordinate systems (WGS-84 latitude/longitude) designed for human- readable precision. RSDGGS treats geographic location as a self- describing, hierarchical index whose structure directly encodes regulatory jurisdiction, enables address-arithmetic routing, and is optimized for constrained IoT devices operating without floating- point arithmetic or external infrastructure. 16.1. RFC 2009: GPS-Based Addressing and Routing RFC 2009 [RFC2009] (Imielinski and Navas, 1996) is the earliest IETF treatment of geographic addressing and routing. It is categorized as Experimental and carries Legacy status, meaning it was published before formal source tracking and has no standing in the IETF standards process. Despite its age, it establishes several concepts directly relevant to RSDGGS. 16.1.1. RFC 2009 Technical Approach RFC 2009 proposes extending IP routing to support geographic destination addressing using GPS coordinates. The core concept is the Geographic Service Area: each router is assigned a bounding polygon defined in GPS coordinates (latitude/longitude pairs) representing the geographic region it serves. A new protocol, IGPSMP (Internet GPS Management Protocol), allows routers to exchange service area descriptions using six message types: set-service-area, confirm-service-area, geographic-service-area-query, service-area- report, and related management primitives. For indoor environments where GPS is unavailable, RFC 2009 proposes weak radio beacons that broadcast a GPS address, allowing mobile devices to adopt the beacon's address as their own. This is structurally analogous to the peer-assisted discovery mechanism defined in Section 10 of this document. RFC 2009 also proposes a DNS-based application-layer solution, adding a geographic first-level domain with hierarchical sub-domains for states, counties, and polygons of interest. Routing to a geographic address involves translating the destination polygon into a sequence of router hops based on IGPSMP service area tables. 16.1.2. Gaps Addressed by RSDGGS Hanley Expires 23 April 2027 [Page 68] Internet-Draft RSDGGS October 2026 Dimension RFC 2009 RSDGGS ─────────────────── ──────────────────────── ───────────────────────── Coordinate system WGS-84 lat/lon polys Dodecahedral cell index Wire encoding Float-point GPS coord 1-8 byte int (uint64_t) Constrained devices Not considered no_std, no_alloc, no FPU Routing metric Polygon intersection Prefix len (XOR+CLZ) Regulatory context Absent Primary design goal Indoor location Beacon GPS addr copy Cell + UWB ranging Privacy Not addressed Truncation gradient Status Experimental / Legacy Informational (this doc) Figure 33 RFC 2009's polygon-based service areas require floating-point computation for containment tests and polygon intersection, making them unsuitable for the Cortex-M0 class devices that constitute the majority of 802.15.4 IoT deployments. The IGPSMP protocol requires routers to maintain geographic routing tables that grow with network size, whereas RSDGGS geographic addressing enables stateless forwarding decisions from address arithmetic alone. RFC 2009 does not address regulatory spectrum management, band availability, or the use of geographic addressing to encode regulatory jurisdiction. RSDGGS is the first specification to treat these as primary design goals of a geographic addressing system. 16.2. RFC 5870: The 'geo' URI Scheme RFC 5870 [RFC5870] (Mayrhofer and Spanring, 2010) defines the 'geo' URI scheme for identifying geographic locations in a coordinate reference system. It is a Standards Track document. The scheme is widely deployed in web contexts, QR codes, mapping applications, and messaging systems. 16.2.1. RFC 5870 Technical Approach A 'geo' URI encodes a point location in WGS-84 (default) or an alternative CRS using the syntax geo:lat,lon[,alt][;crs=...][;u=uncertainty]. The coordinate values are decimal degrees (latitude and longitude) with optional altitude in meters. An optional uncertainty parameter u= specifies the radius of the location in meters. The number of decimal digits in the coordinate values MUST NOT be interpreted as an indication of accuracy; uncertainty is carried only in the explicit u= parameter. Hanley Expires 23 April 2027 [Page 69] Internet-Draft RSDGGS October 2026 The scheme is CRS-agnostic: while WGS-84 is the default, alternative coordinate reference systems may be specified using the crs= parameter. The scheme is protocol-independent and may appear in any context supporting arbitrary URIs. 16.2.2. Gaps Addressed by RSDGGS Dimension RFC 5870 'geo' URI RSDGGS ─────────────────── ──────────────────────── ───────────────────────── Representation 'geo:48.2,16.4;u=40' Binary: 0x01 0x2D 0x35 Encoding size 20-30 bytes typical 1-8 bytes Uncertainty Float param (u=) Implicit in byte length Privacy control Digit trunc (lossy) Byte trunc (lossless) Regulatory context Absent Primary design goal Routing use Not defined See Section 13 Constrained devices Text parsing required Integer extraction only Hierarchical index None Full hier. in bits Figure 34 RFC 5870 explicitly states that the number of decimal digits in coordinate values MUST NOT be interpreted as an indication of accuracy. RSDGGS takes the opposite position: the number of bytes in the index IS the precision indicator, by design. This makes the RSDGGS encoding self-describing in a way that 'geo' URIs are not. The 'geo' URI text encoding (typically 20-30 bytes for a full coordinate) is impractical for 802.15.4 MAC frames and CBOR-encoded IoT messages where wire efficiency is critical. The RSDGGS 1-8 byte binary encoding is 4-30 times more compact for equivalent precision. RSDGGS MAY expose a 'geo' URI mapping for interoperability: an RSDGGS cell center can be expressed as a 'geo' URI with the u= parameter set to the cell radius. This mapping is lossy (the 'geo' URI does not encode the cell boundary shape) but suitable for human-readable display and web interoperability contexts. Implementations SHOULD provide this mapping for diagnostic and display purposes. 16.3. RFC 6442: Location Conveyance for SIP RFC 6442 [RFC6442] (Polk, Rosen, and Peterson, 2011) defines mechanisms for conveying geographic location information within the Session Initiation Protocol (SIP). It is a Standards Track document. The primary use case is emergency services (E9-1-1, E1-1-2) and presence-based location sharing. It mandates use of the PIDF-LO (Presence Information Data Format — Location Object, RFC 4119) as the location representation format. Hanley Expires 23 April 2027 [Page 70] Internet-Draft RSDGGS October 2026 16.3.1. RFC 6442 Technical Approach RFC 6442 introduces a Geolocation SIP header field that carries either a location-by-value (a PIDF-LO object embedded in the SIP message body) or a location-by-reference (a URI from which a PIDF-LO can be retrieved, typically via HTTP or SIP SUBSCRIBE/NOTIFY). A new 424 (Bad Location Information) SIP response code is defined for cases where the location cannot be processed by the recipient. PIDF-LO is an XML format carrying WGS-84 coordinates (point, circle, ellipse, polygon, or civic address). It includes uncertainty representation, confidence levels, and method-of-determination metadata (GPS, manual, cell-tower, etc.). SIP intermediaries are prohibited from modifying or deleting location data in transit. User consent is required before a UAC may include location in a SIP request. 16.3.2. Gaps Addressed by RSDGGS Dimension RFC 6442 / PIDF-LO RSDGGS ─────────────────── ──────────────────────── ───────────────────────── Target protocol SIP (session signal.) 802.15.4 MAC, CBOR, IPv6 Location format PIDF-LO (~500 bytes) CBOR bstr (1-8 bytes) Regulatory context Absent Primary design goal Device class SIP UA (smartphone) Constrained IoT (M) Routing use Geoloc-Routing hdr See Section 13 Privacy Consent/by-ref URI Trunc., RSL disclosure Uncertainty PIDF-LO conf/method Implicit in byte length Acquisition method GPS, cell-tower, manual Sec.11 coop. local. Figure 35 RFC 6442's PIDF-LO XML representation is orders of magnitude larger than RSDGGS and requires XML parsing infrastructure wholly impractical on constrained IoT devices. The consent model defined in RFC 6442, requiring user authorization before location disclosure, addresses a real privacy concern. RSDGGS addresses the same concern through the truncation model: devices share only the resolution necessary for the purpose, with no infrastructure required to enforce the policy. RFC 6442's Geolocation-Routing header enables SIP routing based on location. This is a routing hint at the application layer, not an address-arithmetic property of the network address itself. RSDGGS geographic IPv6 addressing (Section 13) achieves location-based routing at the network layer without any signaling overhead, as the routing metric is embedded in the destination address. Hanley Expires 23 April 2027 [Page 71] Internet-Draft RSDGGS October 2026 The two specifications are complementary: a SIP-capable IoT gateway MAY translate an RSDGGS cell to a PIDF-LO for interfaces toward SIP- based emergency services infrastructure, and vice versa. The translation is defined by the cell-center-to-lat/lon mapping with uncertainty equal to the cell radius. 16.4. RFC 9179: A YANG Grouping for Geographic Locations RFC 9179 [RFC9179] (Hopps, 2022) defines a reusable YANG grouping for geographic location data, intended for inclusion in YANG data models for network management. It is a Standards Track document. It is explicitly designed for YANG-managed network elements such as routers, switches, and base stations, not for constrained IoT endpoints. 16.4.1. RFC 9179 Technical Approach The geo-location YANG grouping includes: a reference-frame specifying the astronomical body and geodetic datum (defaulting to WGS-84 Earth); a location choice between ellipsoidal coordinates (latitude as decimal64 with 16 fraction-digits, longitude as decimal64 with 16 fraction-digits, optional height in meters) or Cartesian coordinates (x, y, z in meters); a velocity vector (v-north, v-east, v-up in meters per second with 12 fraction-digits); and timestamp and valid- until fields. Coordinate accuracy is carried as a separate decimal64 field in meters. The design is notable for its explicit support for non-Earth astronomical bodies (Mars, the Moon, etc.) through the reference- frame mechanism, and for velocity as a first-class field. It is intended as a reusable module embedded in other YANG models, not as a standalone protocol. 16.4.2. Gaps Addressed by RSDGGS Dimension RFC 9179 YANG grouping RSDGGS ─────────────────── ──────────────────────── ───────────────────────── Target context YANG/NETCONF mgmt 802.15.4 / CBOR / IPv6 Encoding XML/JSON (NETCONF) CBOR bstr (1-8 bytes) Precision decimal64 (16 frac) 6 cm at 8 bytes Regulatory context Absent Primary design goal Routing use Not defined See Section 13 Constrained devices Not applicable Primary target Uncertainty coord-accuracy (m) Implicit in byte length Velocity v-north, v-east, v-up EKF state (Sec.11) Figure 36 Hanley Expires 23 April 2027 [Page 72] Internet-Draft RSDGGS October 2026 RFC 9179's decimal64 latitude and longitude fields (16 fraction- digits) provide sub-nanometer theoretical precision, far exceeding GPS capability. RSDGGS at 8 bytes provides 6 cm precision, which matches or exceeds operational GPS accuracy for IoT applications. The YANG encoding overhead (XML or JSON field names plus decimal values) is typically 60-100 bytes per location fix versus 1-8 bytes for RSDGGS. RFC 9179 does not define a hierarchical structure for location data and provides no support for location-based routing. The RSDGGS cell index has no analog in the RFC 9179 model. An RSDGGS extension to the RFC 9179 grouping is a potential future work item, adding an optional rsdggs-cell leaf of type binary with length constraint 1..8 to the geo-location grouping, enabling network elements to carry RSDGGS regulatory context alongside their WGS-84 coordinates in YANG data models. 16.5. RFC 9632: Finding and Using Geofeed Data RFC 9632 [RFC9632] (Bush, Candela, Kumari, and Housley, 2024) specifies how IP address holders publish authoritative geographic location data for their address space using geofeed CSV files, and how consumers discover and authenticate these files using RPSL inetnum objects and RPKI signatures. It obsoletes RFC 9092. The underlying geofeed format is defined in RFC 8805. 16.5.1. RFC 9632 Technical Approach A geofeed file is a CSV document published at a stable HTTPS URL, containing rows of the form: IP-prefix, country-code, region-code, city-name, postal-code (deprecated). The file maps IP address prefixes to political-administrative geographic designators (ISO 3166-1 country codes, ISO 3166-2 region codes). Discovery is via a geofeed: attribute in the RPSL inetnum: object for the relevant address range. Authentication uses RPKI Resource Certificates with CMS signatures; a new EE certificate is generated for each file version. Geofeed granularity is at the IP prefix level: a /24 prefix may be mapped to a city, a /16 to a country. The most specific inetnum: object with a geofeed reference governs, and geofeed data may have finer granularity than the inetnum: block itself. The format intentionally omits precise coordinate data: the mapping is to political-administrative units, not WGS-84 coordinates. 16.5.2. Gaps Addressed by RSDGGS Hanley Expires 23 April 2027 [Page 73] Internet-Draft RSDGGS October 2026 Dimension RFC 9632 Geofeed RSDGGS ─────────────────── ──────────────────────── ───────────────────────── Address space IP prefixes (BGP) 802.15.4 / 6LoWPAN / CBOR Loc. granularity Country/region/city 6cm-continental (8B) Format CSV file (HTTPS) Binary (1-8B in-frame) Discovery RPSL inetnum + RPKI MAC bcn/RSDGGS IPv6 Regulatory context Absent Primary design goal Real-time use Batch/periodic fetch Per-frame/per-packet Device class BGP routers, servers Constrained IoT (M) Routing Not defined See Section 13 Figure 37 RFC 9632 and RSDGGS address fundamentally different layers of the same problem. RFC 9632 maps IP address blocks — which are administratively assigned and may not correspond to the physical location of the device using them — to geographic designators, for the purpose of correcting commercial geolocation database errors. RSDGGS encodes the physical location of an IoT device directly in a binary index that travels with every message the device sends, for the purpose of regulatory compliance determination at the MAC layer. A meaningful integration point exists: RSDGGS-IPv6 geographic addresses (Section 13) are by definition location-accurate. An operator deploying RSDGGS-IPv6 addresses could publish a geofeed file trivially, as the address prefix directly encodes the geographic region. A /72 RSDGGS-IPv6 prefix geofeed entry maps to a single dodecahedron face (ITU Region); a /88 prefix maps to a country-scale cell. This makes RSDGGS-IPv6 deployments inherently geofeed- compliant without the mismatch that arises when administratively assigned IP prefixes are spread across multiple geographic regions. 16.6. RFC 8805: A Format for Self-Published IP Geolocation Feeds RFC 8805 [RFC8805] (Kline, Duleba, Szamonek, Moser, and Kumari, 2020) defines the geofeed CSV format that RFC 9632 subsequently standardized discovery for. It is an Independent Submission Informational RFC. The format was developed at Google to address cases where regional network operators needed to rapidly publish corrections to commercial geolocation database errors. Hanley Expires 23 April 2027 [Page 74] Internet-Draft RSDGGS October 2026 16.6.1. RFC 8805 Technical Approach A geofeed file is a UTF-8 CSV text file published at a stable HTTPS URL. Each non-comment line has the form: ip_prefix, alpha2code, region, city, postal_code. The IP prefix field is required; all others are optional. The format intentionally only allows coarse- level location — political-administrative designators (ISO 3166-1 country code, ISO 3166-2 region code, city name) rather than precise coordinates. Postal code is included for backward compatibility but its use is deprecated. The file is self-published by the IP address holder and consumed by geolocation data pipeline operators on a polling schedule. RFC 8805 is the predecessor to RFC 9632 and directly defines the data format that RFC 9632 provides discovery mechanisms for. The two documents form a coupled pair: RFC 8805 is the format specification; RFC 9632 is the discovery and authentication specification. 16.6.2. Gaps Addressed by RSDGGS Dimension RFC 8805 Geofeed Format RSDGGS ─────────────────── ──────────────────────── ───────────────────────── Target IP prefix holders IoT device manufacturers Granularity Country/region/city 6cm-continental (8B) Format CSV text (HTTPS poll) Binary (1-8B in-frame) Update mechanism Periodic HTTP fetch Per-frame dynamic Regulatory context Absent Primary design goal Constrained devices Not applicable Primary target Precision Administrative boundary Physical loc, metered Figure 38 RFC 8805 and RSDGGS share the property of being self-published: an IP address holder publishes a geofeed file asserting the location of their prefix, and an IoT device encodes its RSDGGS cell asserting its own location. The trust models differ significantly: geofeed authenticity in RFC 8805 relies on RPKI (via RFC 9632) binding the file to the address holder's certificate; RSDGGS cell authenticity in peer-assisted scenarios relies on the MAC-layer STS authentication defined in Section 11.4.2 and the multi-peer confidence model of Section 10.3. As noted in Section 15.5, RSDGGS-IPv6 geographic addresses (Section 13) are inherently geofeed-compatible: the address prefix encodes geographic location by definition, eliminating the mismatch between administratively assigned IP prefixes and their physical locations that RFC 8805 was designed to correct. Hanley Expires 23 April 2027 [Page 75] Internet-Draft RSDGGS October 2026 16.7. RFC 5808: Requirements for a Location-by-Reference Mechanism RFC 5808 [RFC5808] (Marshall, 2010) is an Informational document from the IETF GEOPRIV working group that defines requirements for Location-by-Reference (LbyR) mechanisms. It is part of the GEOPRIV architecture family that includes RFC 6280, RFC 5491, and RFC 6772. It explicitly leaves Location-by-Value (LbyV) out of scope. 16.7.1. RFC 5808 Technical Approach RFC 5808 defines the LbyR lifecycle as comprising four stages: Location URI Creation (at a Location Information Server, LIS); Location URI Distribution (via a Location Configuration Protocol, LCP, from LIS to Target); Location URI Conveyance (from Target to Location Recipient via a signaling protocol such as SIP); and Location URI Dereferencing (Location Recipient resolves the URI to obtain a PIDF-LO). The dereference protocol must support URI-form location references, must authenticate both client and server, and must return a well-formed PIDF-LO document. The motivation for LbyR is that in mobile networks it is not efficient for an end host to periodically query a LIS for up-to-date location. Instead, the LIS holds the current location and the Target carries only a URI reference, which can be dereferenced by authorized recipients to obtain the current location at the time of dereference. 16.7.2. Gaps Addressed by RSDGGS Dimension RFC 5808 LbyR Req. RSDGGS ─────────────────── ──────────────────────── ───────────────────────── Architecture LIS + LCP + dereference Self-contained index Infrastructure req. Location Info. Server None (no server) Location currency Via dereference Carried in-frame, updated Constrained devices Not addressed Primary target Regulatory context Absent Primary design goal Privacy model Rule Maker + LIS policy Structural (truncation) Location form PIDF-LO (after deref) CBOR bstr (direct) Figure 39 The LbyR architecture requires persistent network connectivity to a Location Information Server for location dereferencing. This is fundamentally incompatible with the operational model of 802.15.4 IoT devices, which may operate in disconnected or intermittently connected environments, cannot carry TCP/TLS stacks required for HTTPS dereferencing, and must determine regulatory context before establishing any network connection at all. Hanley Expires 23 April 2027 [Page 76] Internet-Draft RSDGGS October 2026 RSDGGS takes the Location-by-Value position for IoT: the location index is carried directly in the MAC frame or IPv6 address. The RSDGGS cooperative localization mechanism (Section 11) is analogous to the LIS in the RFC 5808 architecture, but is fully distributed and requires no server infrastructure: the network of peers collectively provides the location determination function that RFC 5808 centralizes in a LIS. 16.8. RFC 5491: GEOPRIV PIDF-LO Usage Clarification, Considerations, and Recommendations RFC 5491 [RFC5491] (Winterbottom, Thomson, and Tschofenig, 2009) is a Standards Track document that clarifies usage rules for the PIDF-LO format originally defined in RFC 4119. It is part of the GEOPRIV family and serves as the normative usage guide for the location object format that underlies RFC 6442, RFC 5808, RFC 6280, and RFC 6772. 16.8.1. RFC 5491 Technical Approach RFC 5491 defines seven rules for constructing PIDF-LO documents. The key rules relevant to RSDGGS comparison are: Rule 4 specifies that providing more than one location chunk in a single location-info element should be avoided; Rules 5 and 6 govern when compound location is permitted, requiring that multiple chunks come from the same source at the same time by the same determination method; Rule 7 requires that coarse location be provided before fine location in compound representations. RFC 5491 defines two location representation types within PIDF-LO: geodetic location (WGS-84 coordinates, GML geometry shapes including Point, Circle, Ellipse, ArcBand, Polygon) and civic location (structured address: country, administrative regions A1-A6, street, floor, room). The GML subset defined for geodetic location requires mandatory implementation for location-based routing applications. 16.8.2. Gaps Addressed by RSDGGS Dimension RFC 5491 PIDF-LO Usage RSDGGS ─────────────────── ──────────────────────── ───────────────────────── Location types Geodetic + civic (addr.) Geographic cell only Compound location Rules 4-7 (XML elems) Single hier. index Uncertainty GML shape (poly/circle) Implicit in byte length Coarse-to-fine Rule 7 (explicit) Structural (MSB→LSB) Encoding XML/GML (~2000 bytes) Binary (1-8 bytes) Floor / room Civic element supported Not defined Regulatory context Absent Primary design goal Constrained devices Not addressed Primary target Hanley Expires 23 April 2027 [Page 77] Internet-Draft RSDGGS October 2026 Figure 40 RFC 5491's Rule 7 — coarse location MUST precede fine location in compound PIDF-LO — is structurally expressed in RSDGGS by the bit layout itself: Byte 0 (coarsest) precedes Byte 7 (finest), and truncation from the right always yields the coarser representation. RSDGGS embodies Rule 7 as an invariant property of the encoding rather than an application-layer behavioral requirement. RFC 5491 supports civic location (floor number, room identifier) as a compound element alongside geodetic coordinates. RSDGGS does not encode civic location. For indoor deployments requiring floor-level regulatory distinction (which is uncommon for ISM band rules but relevant for UWB power limits in some jurisdictions), a civic layer MAY be carried as a separate CBOR field alongside the RSDGGS cell, using the PIDF-LO civic format or a simplified representation. 16.9. RFC 6280: An Architecture for Location and Location Privacy in Internet Applications RFC 6280 [RFC6280] (Barnes, Lepinski, Cooper, Morris, Tschofenig, and Schulzrinne, 2011) is a Best Current Practice document that describes the GEOPRIV architecture for privacy-preserving location-based services. It consolidates and expands on the original GEOPRIV requirements from RFC 3693 and serves as the architectural foundation for the entire GEOPRIV family of specifications. 16.9.1. RFC 6280 Technical Approach The central component of the GEOPRIV architecture is the Location Object (LO), which binds location information to user-specified privacy rules. The architecture defines five roles: Location Generator (LG), which produces raw location measurements; Location Server (LS), which stores location objects and enforces privacy rules; Rule Maker (RM), which is the user or device owner who specifies privacy preferences; Target, the entity whose location is being described; and Location Recipient (LR), which consumes location information. A central feature of the GEOPRIV architecture is that location information is always bound to privacy rules. These rules govern who may receive the location, how precisely, and under what conditions. The privacy protections rely on recipients honoring the rules they receive alongside the location data; RFC 6280 acknowledges that technical enforcement is inherently limited and relies on legal and contractual mechanisms for compliance assurance. Hanley Expires 23 April 2027 [Page 78] Internet-Draft RSDGGS October 2026 16.9.2. Gaps Addressed by RSDGGS Dimension RFC 6280 GEOPRIV Arch. RSDGGS ─────────────────── ──────────────────────── ───────────────────────── Privacy model Rule-based (RM+LS+LR) Struct. byte trunc. Infrastructure LG + LS + LR servers None required Enforcement Honor-system + legal No over-disclosure Location binding LO + privacy rules obj. Single CBOR byte string Constrained devices Not addressed Primary target Regulatory context Absent Primary design goal Rule distribution XCAP/presence protocol Not applicable Trust model Centralized (LS) Distributed (peer mesh) Figure 41 The GEOPRIV architecture's privacy model requires that the Rule Maker express privacy preferences, that the Location Server enforce them, and that Location Recipients honor them. This three-party trust model requires persistent infrastructure that is unavailable to constrained IoT devices operating in disconnected environments. RSDGGS replaces the GEOPRIV rule-based privacy model with structural privacy: a device that shares a 3-byte RSDGGS cell is physically incapable of disclosing more than country-level location, regardless of recipient behavior. No rules, servers, or trust relationships are required to enforce this property. The privacy level is determined by the sender's choice of index length, not by the recipient's compliance with transmitted rules. This structural approach is both stronger (cannot be violated by a non-compliant recipient) and weaker (cannot express nuanced rules like 'share with spouse but not employer') than the GEOPRIV model. For ISM regulatory compliance, where the only required disclosure is 'am I in ITU Region 2?', the structural model is entirely sufficient. RSDGGS implementations that require nuanced privacy rules for non- regulatory purposes MAY layer a RFC 6772 geolocation policy document alongside the RSDGGS cell in application-layer CBOR messages. 16.10. RFC 6772: Geolocation Policy: A Document Format for Expressing Privacy Preferences for Location Information RFC 6772 [RFC6772] (Schulzrinne, Tschofenig, Cuellar, Polk, Morris, and Thomson, 2013) is a Standards Track document that defines an XML document format for expressing location privacy preferences within the GEOPRIV architecture. It extends the Common Policy schema (RFC 4745) with location-specific conditions and transformations. Hanley Expires 23 April 2027 [Page 79] Internet-Draft RSDGGS October 2026 16.10.1. RFC 6772 Technical Approach A geolocation authorization document is an XML document with MIME type application/auth-policy+xml, using the namespace urn:ietf:params:xml:ns:geolocation-policy. Documents are structured as sets of rules, each containing a condition, an action, and a transformation component. Conditions may include identity-based conditions (who is requesting) and location-based conditions (where the target is). Transformations specify how the location information should be modified before delivery — for example, reducing precision by replacing a precise geodetic coordinate with a less precise one, or replacing geodetic coordinates with a civic address. Documents are stored and managed using XCAP (XML Configuration Access Protocol, RFC 4825) at a Location Server or Presence Server. The Rule Maker uses XCAP to create, modify, and delete authorization policies. Location-based conditions allow policies such as 'when I am at work, share my location with my employer at city-level precision; when I am at home, share with family at room-level precision.' 16.10.2. Gaps Addressed by RSDGGS Dimension RFC 6772 Geoloc. Policy RSDGGS ─────────────────── ──────────────────────── ───────────────────────── Privacy mechanism XML policy rules + XCAP Struct. byte trunc. Infrastructure XCAP server + LS req. None Loc. obfuscation Precision reduction Byte trunc. (binary) Enforcement Recipient compliance Structural impossib. Constrained devices Not addressed Primary target Encoding XML (hundreds of bytes) N/A (no policy doc) Regulatory context Absent Primary design goal Policy expressive. High (identity+loc.) Single dim (resolution) Figure 42 RFC 6772's location obfuscation mechanism — reducing precision in the transformation element of a policy rule — is conceptually identical to RSDGGS truncation, but implemented through a server-side XML transformation rather than a structural property of the encoding. The RFC 6772 approach requires a Location Server to apply the transformation rule; the RSDGGS approach requires the transmitting device to select an index length. The RSDGGS approach is implementable on a 32-byte RAM microcontroller with no server dependency. Hanley Expires 23 April 2027 [Page 80] Internet-Draft RSDGGS October 2026 RFC 6772's location-based conditions — rules that apply differently depending on where the Target is — have a direct analogy in RSDGGS: the RSL (Resolution Sufficiency Level) table defines location- dependent disclosure requirements for regulatory purposes. A device in Face 2 (North America) needs to disclose only 1 byte to establish 902 MHz legality; a device in Face 3 (East Asia) needs 3 bytes to distinguish Japan from China. The RSDGGS RSL table is a regulatory- specific, infrastructure-free analog to RFC 6772's location-based policy conditions. The two mechanisms are composable for deployments requiring both regulatory compliance and user privacy management: RSDGGS provides the minimum regulatory disclosure at the MAC layer; a separate RFC 6772 geolocation policy governs higher-precision disclosure for application-layer services requiring richer location context. 16.11. Gap Analysis Summary The following table summarizes the key gaps across all ten reviewed specifications and the RSDGGS response to each. Each entry corresponds to the detailed comparison in the preceding subsections (16.1 through 16.10): Hanley Expires 23 April 2027 [Page 81] Internet-Draft RSDGGS October 2026 +===============+===========================+=====================+ | Specification | Primary Gap vs RSDGGS | RSDGGS Response | +===============+===========================+=====================+ | RFC 2009 (GPS | No ISM regulatory | Binary cell index; | | Routing) | context; float GPS coords | regulatory DB per | | | | cell | +---------------+---------------------------+---------------------+ | RFC 5870 (geo | Text encoding; no | 1-8 bytes; implicit | | URI) | regulatory context | uncertainty by | | | | length | +---------------+---------------------------+---------------------+ | RFC 6442 (SIP | SIP-only; PIDF-LO XML; no | MAC-layer IE; CBOR; | | Location) | IoT path | 802.15.4 native | +---------------+---------------------------+---------------------+ | RFC 9179 | NETCONF/RESTCONF only; no | No YANG model; | | (YANG | constrained IoT | future work | | Location) | | candidate | +---------------+---------------------------+---------------------+ | RFC 9632 | IP prefixes; batch fetch; | Per-frame binary; | | (Geofeed) | not real-time | MAC-layer bootstrap | +---------------+---------------------------+---------------------+ | RFC 8805 (IP | Administrative boundary | Physical cell; 6 cm | | Geofeed fmt) | only; not IoT | resolution at 8 | | | | bytes | +---------------+---------------------------+---------------------+ | RFC 5808 | Requires LIS | No infrastructure; | | (LbyR Reqs) | infrastructure; not | peer mesh bootstrap | | | decentralized | | +---------------+---------------------------+---------------------+ | RFC 5491 | XML/GML encoding; not | CBOR bstr; 1-8 | | (PIDF-LO | constrained IoT | bytes; 802.15.4 IE | | Usage) | | | +---------------+---------------------------+---------------------+ | RFC 6280 | Requires LS/LG/LR | Fully | | (GEOPRIV | servers; centralized | decentralized; | | Arch.) | | peer-assisted | +---------------+---------------------------+---------------------+ | RFC 6772 | XML policy engine; not | Structural privacy | | (Geoloc. | implementable on MCU | via byte truncation | | Policy) | | | +---------------+---------------------------+---------------------+ Table 18: Gap Analysis Summary Hanley Expires 23 April 2027 [Page 82] Internet-Draft RSDGGS October 2026 RSDGGS does not supersede any of the five referenced specifications. Each addresses a distinct protocol layer or use case for which it remains the appropriate standard. RSDGGS fills the gap at the intersection of geographic addressing, regulatory compliance encoding, constrained IoT communication, and MAC-layer integration — a combination not addressed by any prior IETF work. Implementations are encouraged to support translation between RSDGGS cells and the formats defined in RFC 5870 ('geo' URI) and RFC 9179 (YANG grouping) for interoperability with infrastructure-side systems. The RSDGGS cell center coordinates provide the lat/lon values for these translations; the cell radius provides the uncertainty parameter. 17. Backward Citations: Relevant References Within Cited Documents Each patent and RFC examined in Section 16 carries its own citation list. This section identifies references within those backward citation chains that are independently relevant to RSDGGS — documents cited by the cited documents that surface additional prior art, gaps, or informative context not already addressed in the specification. 17.1. GPSR — Greedy Perimeter Stateless Routing (from US 10,812,365) Karp, B. and H.T. Kung, 'GPSR: Greedy Perimeter Stateless Routing for Wireless Networks', MobiCom 2000. Cited as primary prior art in US 10,812,365 (geohyperbolic routing patent). Relevance to RSDGGS: GPSR is the canonical geographic greedy forwarding algorithm for wireless networks. It defines two components: greedy forwarding (advance toward destination by geographic distance) and perimeter routing (traverse face of a planar graph when greedy forwarding is stuck at a void). RSDGGS Section 15.3 defines geographic greedy forwarding using common- prefix-length as the proximity metric but does not define a void- handling mechanism. GPSR's perimeter routing is a direct gap in RSDGGS. Implementations in sparse networks where geographic voids may exist SHOULD implement a fallback void handler; GPSR's perimeter routing or AODV-RPL (RFC 9854) route discovery are the recommended candidates. This gap should be documented as a known limitation in Section 15.3. 17.2. IEEE 802.11d — Country Information Elements (from US 10,306,400 family) IEEE 802.11d-2001, 'Amendment: Specifications for Operation in Additional Regulatory Domains'. Surfaced through the wireless regulatory compliance patent family (US 10,306,400, US 9,654,965). Hanley Expires 23 April 2027 [Page 83] Internet-Draft RSDGGS October 2026 Relevance to RSDGGS: IEEE 802.11d defines country information elements (Country IE) in Wi-Fi beacon frames. Each Country IE contains a 3-character country string and per-channel maximum transmit power tables. This is the direct 802.11 predecessor of the RSDGGS 802.15.4 Location Sub-IE defined in Section 14. The comparison is instructive: 802.11d uses a flat country string as the regulatory identifier, limiting it to coarse national granularity with no hierarchy, no privacy truncation, and no regulatory parameter encoding beyond max power per channel. RSDGGS replaces the flat country string with a hierarchical cell index that encodes ITU Region at 1 byte, country-scale at 3 bytes, and sub-national detail at 4-6 bytes, while the regulatory database carries the full parameter set. The RSDGGS Sub-IE should be cited as a hierarchical extension of the 802.11d Country IE concept to 802.15.4 with ITU-regional alignment. 17.3. IEEE 802.11h — DFS and TPC (from US 10,306,400 family) IEEE 802.11h-2003, 'Spectrum and Transmit Power Management Extensions'. Also surfaced through the wireless regulatory compliance patent family. Relevance to RSDGGS: IEEE 802.11h defines Dynamic Frequency Selection (DFS) for radar avoidance and Transmit Power Control (TPC) for regulatory compliance in the 5 GHz band. TPC specifically defines a negotiated reduction of transmit power between stations based on measured path loss, with the goal of keeping transmit power at the minimum needed for link quality. This is the direct 802.11 predecessor of RSDGGS Section 10.4 (adaptive power control at regulatory boundaries). The key difference: 802.11h TPC is link- quality-driven and reactive, reducing power when the link permits. RSDGGS boundary power control is geography-driven and proactive, reducing power as a device approaches a regulatory boundary regardless of link quality. The two mechanisms are complementary and both should apply in deployments near regulatory boundaries. 17.4. RFC 3693 — GEOPRIV Requirements (from RFC 6442 and RFC 6280) Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J. Polk, 'Geopriv Requirements', RFC 3693, February 2004. Cited as the foundational requirements document by both RFC 6442 and RFC 6280. Relevance to RSDGGS: RFC 3693 defines the concept of a 'using protocol': any protocol that transmits or acts on location information must satisfy GEOPRIV's authorization, integrity, and privacy requirements. RSDGGS's 802.15.4 MAC bootstrap (Section 14) qualifies as a using protocol under RFC 3693's definition: it transmits location information (the RSDGGS cell) in MAC frames and acts on it to configure regulatory parameters. RSDGGS satisfies RFC Hanley Expires 23 April 2027 [Page 84] Internet-Draft RSDGGS October 2026 3693's privacy requirement through structural truncation (G3, G8) rather than policy rules, satisfies the integrity requirement through STS-authenticated ranging (Section 13.4.2) rather than digital signatures, and satisfies the authorization requirement through the MAC association process (only devices that have joined the PAN receive beacon location information). RFC 3693 should be cited as an informative reference in Section 14. 17.5. RFC 3825 — DHCP Geodetic Location Option (from RFC 5870 and RFC 5808) Polk, J., Schnizlein, J., and M. Linsner, 'Dynamic Host Configuration Protocol Option for Coordinate-based Location Configuration Information', RFC 3825, July 2004. Cited as a location provisioning mechanism in RFC 5870 and RFC 5808. Relevance and limitation: RFC 3825 defines a DHCP option carrying WGS-84 latitude and longitude for device location provisioning. A DHCPv6 analog carrying an RSDGGS cell index would provide a convenient provisioning path for fixed-infrastructure deployments where DHCP already runs. However, RFC 3825 and any DHCPv6 RSDGGS extension are explicitly excluded from serving as a required provisioning mechanism by design goal G8. The reason is structural: DHCP is a client-server protocol with a centralized server as a single point of failure. If the DHCPv6 server is unavailable — due to server failure, network partition, or initial bootstrap before any infrastructure is established — onboarding devices cannot acquire their regulatory configuration. This violates G8's requirement for complete independence from any centralized server. IPv6 Stateless Address Autoconfiguration (SLAAC, RFC 4862) and Neighbor Discovery (RFC 4861) demonstrate the correct architectural model: a device derives its IPv6 address from its MAC address and the subnet prefix advertised by neighboring routers, with no server dependency. RSDGGS follows the same model: a device derives its regulatory cell from the RSDGGS cells of neighboring devices (Section 11), with no server dependency. RFC 3825 / DHCPv6 RSDGGS options MAY be implemented as optional accelerators in managed infrastructure deployments where the DHCP server is always available before devices are deployed. They MUST NOT be implemented as the sole or primary regulatory provisioning path. Any RSDGGS implementation that supports DHCPv6 provisioning MUST also implement the peer-assisted bootstrap of Section 11 as a fallback, and MUST fall back to peer-assisted bootstrap automatically if the DHCP server does not respond within a configurable timeout. Hanley Expires 23 April 2027 [Page 85] Internet-Draft RSDGGS October 2026 17.6. RFC 4632 — CIDR: Classless Inter-Domain Routing (from RFC 9632) Fuller, V. and T. Li, 'Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan', BCP 122, RFC 4632, August 2006. Cited as background in RFC 9632's geofeed discovery context. Relevance to RSDGGS: CIDR defines prefix-based aggregation of IPv4 address space into routing hierarchies, where a /16 prefix aggregates 65,536 /32 host addresses into a single routing entry. RSDGGS-IPv6 geographic addressing (Section 15) implements the same concept with geographic cells: a /72 RSDGGS-IPv6 prefix aggregates all devices in a single dodecahedron face (ITU Region) into a single routing entry; a /88 prefix aggregates all devices in a country-scale cell. The mathematical relationship is direct — RSDGGS-IPv6 is CIDR for geography rather than administrative address allocation. RFC 4632 should be cited as an informative reference in Section 15.2 to establish this conceptual lineage. 17.7. RFC 6269 — Issues with IP Address Sharing (from RFC 9632) Ford, M., Boucadair, M., Durand, A., Levis, P., and P. Roberts, 'Issues with IP Address Sharing', RFC 6269, June 2011. Cited in RFC 9632's introduction as motivation for geofeed. Relevance to RSDGGS: RFC 6269 documents the problem that commercial IP geolocation databases are unreliable when IP addresses are shared (NAT, CGN, mobile carrier address pools) because a shared address maps to many physical locations. RFC 9632 geofeed was designed as a partial solution — operators can publish authoritative location for their IP prefix. RSDGGS-IPv6 geographic addressing solves this problem categorically for devices using RSDGGS addresses: the lower 64 bits of the IPv6 address encode the device's geographic cell, making location-by-address exact by construction rather than inferred. This should be noted in Section 15 as one of the concrete advantages of RSDGGS-IPv6 over commercial geolocation. 17.8. GeoCast — Geographic Addressing and Routing (from RFC 2009) Navas, J.C. and T. Imielinski, 'GeoCast: Geographic Addressing and Routing', MobiCom 1997. Cited in RFC 2009 as the companion paper describing geographic multicast. Relevance to RSDGGS: GeoCast defines geographic multicast: delivering a packet to all nodes currently within a specified geographic polygon. RSDGGS-IPv6 prefix aggregation enables a direct implementation of GeoCast: a packet addressed to a /72 RSDGGS-IPv6 prefix is a GeoCast to all devices in a single ITU Region; a packet Hanley Expires 23 April 2027 [Page 86] Internet-Draft RSDGGS October 2026 addressed to a /88 prefix is a GeoCast to a country-scale cell. This is lossless GeoCast — the cell boundary is exact, not approximated by a polygon. GeoCast should be cited as an informative reference in Section 15 as an ancestor of RSDGGS geographic multicast capability. 17.9. Summary of Newly Identified References The following references, surfaced from the backward citation chains of documents already examined, should be added to Section 21 (References) of this draft as informative references: Hanley Expires 23 April 2027 [Page 87] Internet-Draft RSDGGS October 2026 +================+============+=========+=========================+ | Reference | Surfaced | Section | Relevance | | | From | to Cite | | | | | In | | +================+============+=========+=========================+ | Karp & Kung, | US | Section | Void handling gap in | | GPSR (MobiCom | 10,812,365 | 15.3 | geographic forwarding | | 2000) | | | | +----------------+------------+---------+-------------------------+ | IEEE | US | Section | 802.11 predecessor of | | 802.11d-2001 | 10,306,400 | 14 | RSDGGS 802.15.4 Sub-IE | | | family | | | +----------------+------------+---------+-------------------------+ | IEEE | US | Section | 802.11 predecessor of | | 802.11h-2003 | 10,306,400 | 10.4 | RSDGGS boundary power | | | family | | control | +----------------+------------+---------+-------------------------+ | RFC 3693 | RFC 6442, | Section | Using protocol | | (GEOPRIV | RFC 6280 | 14 | requirements; RSDGGS | | Requirements) | | | compliance | +----------------+------------+---------+-------------------------+ | RFC 3825 (DHCP | RFC 5870, | Section | Infrastructure | | Geodetic) | RFC 5808 | 12 | provisioning path; | | | | | single point of failure | +----------------+------------+---------+-------------------------+ | RFC 4862 | Design | Section | Serverless | | (SLAAC) | goal G8 | 11, 12 | autoconfiguration model | +----------------+------------+---------+-------------------------+ | RFC 4861 | Design | Section | Serverless neighbor- | | (Neighbor | goal G8 | 11 | based discovery model | | Discovery) | | | | +----------------+------------+---------+-------------------------+ | RFC 4632 | RFC 9632 | Section | Prefix aggregation | | (CIDR) | | 15.2 | conceptual ancestor | +----------------+------------+---------+-------------------------+ | RFC 6269 (IP | RFC 9632 | Section | Problem RSDGGS-IPv6 | | address | | 15 | solves categorically | | sharing) | | | | +----------------+------------+---------+-------------------------+ | Navas & | RFC 2009 | Section | Geographic multicast | | Imielinski, | | 15 | ancestor | | GeoCast (1997) | | | | +----------------+------------+---------+-------------------------+ Table 19: Summary of Newly Identified References Hanley Expires 23 April 2027 [Page 88] Internet-Draft RSDGGS October 2026 Of these, RFC 3825 with its DHCP single-point-of-failure limitation, IEEE 802.11d as the direct predecessor of the RSDGGS 802.15.4 Sub-IE, and RFC 4862/4861 as the SLAAC/ND model that G8 follows are the highest-priority additions. The GPSR void-handling gap is the most significant technical limitation currently undocumented in the specification. 18. Freedom to Operate and Prior Art Considerations This section provides a comprehensive analysis of all patents and RFC standards examined during the development of RSDGGS. For each, it identifies the technical relationship to RSDGGS, evaluates freedom to operate, and identifies any improvement opportunity that the prior work suggests for RSDGGS. Improvement opportunities are RSDGGS- applicable enhancements that are either enabled by, or would have been blocked by, the referenced work. All patent analyses are informational only and do not constitute legal advice. 18.1. Expired Patents — Public Domain Prior Art The following patents are expired and their full technical disclosures are in the public domain. They constitute prior art against any third-party attempt to patent the techniques they disclose, and RSDGGS implementations may freely use these techniques without license. 18.1.1. US Patent 4,939,726 — Metricom, Inc. (Expired 2007) Title: Method for Routing Packets in a Packet Communication Network. Inventors: Flammer, Kalkwarf. Assignee: Metricom, Inc. (later Proxim Wireless Corp.). Filed 1989, granted July 3, 1990, expired 2007. Companion patent US 5,115,433 (Baran, Flammer, Kalkwarf — Metricom, 1992) is also expired. Key claims (now public domain): Claim 1: Node identifier indicative of geographic location referenced to a terrestrial coordinate grid Claim 1: Routing by maximum forward geographic progress without routing directory or table Claim 3: Lock table with neighbor link quality factor based on distance, power, retry, throughput, delay Claim 5: Weighted link quality factor for preferred paths US 5,115,433 adds (also public domain): Selection of forwarding node by minimum power required Link quality criteria include: net data rate, network delay, data priority — richer than Claim 3 of 4,939,726 Hanley Expires 23 April 2027 [Page 89] Internet-Draft RSDGGS October 2026 Figure 43 RSDGGS improvement opportunity — Link Quality Weighted Forwarding: US 4,939,726 Claim 3 and US 5,115,433 define a link quality (LQ) factor incorporating distance, power, retry history, throughput, and delay. RSDGGS Section 15.3 defines geographic greedy forwarding using only common-prefix-length as the progress metric. Incorporating a link quality weighting that prefers the LQ-best neighbor among those making geographic progress would improve real-world routing performance in dense ISM-band deployments where RSSI and retry rates vary significantly. This enhancement is freely implementable from the expired public domain claims and should be noted as a normative extension candidate for follow-on standards-track work. 18.1.2. US Patent 6,982,966 — Status Unconfirmed This number was not definitively identified in patent database searches. If this patent was cited in relation to geographic routing or MANET protocols, the Metricom prior art (4,939,726 and 5,115,433, both expired 2007 and 2009 respectively) predates any 2006-era geographic routing patent by 15+ years and establishes the core concepts as public domain. Independent verification at patents.uspto.gov is still recommended. 18.2. Active Patents — Detailed Analysis 18.2.1. US Patent 10,306,400 / Application 2014/0162692 — Wirelesss Regulatory Compliance (Active until ~2035) Title: Systems and Methods for Enforcing Wireless Regulatory Compliance. Assignee not publicly confirmed from application number alone; the issued patent US 10,306,400 covers a thermostat and home network device context. Filed as US Application 20140162692 approximately 2013-2014. The issued patent family includes related grants US 9,794,738 and US 9,654,965. Active. Hanley Expires 23 April 2027 [Page 90] Internet-Draft RSDGGS October 2026 Core claim element (all related patents): Determining geographic location of a device Configuring device to operate on a channel set based on location VERIFYING location by analyzing AC power line frequency (50 Hz = European / Region 1; 60 Hz = American / Region 2) Re-configuring if verification fails Claim 7: Explicitly covers devices devoid of cellular and GPS US 9,654,965 adds: Lookup table / database mapping location to regulations Table may be stored locally or downloaded from network Location determined from GNSS, MCC, AP country codes, indirect AP location, or cell tower information Figure 44 RSDGGS freedom to operate: RSDGGS does not use power line frequency as a location verification mechanism. The core novelty of this patent family is the AC frequency verification step, which is absent from RSDGGS entirely. RSDGGS derives location from: pre-provisioned cell index (Section 12), peer-received RSDGGS beacons (Section 11), or cooperative ranging (Section 13). None of these mechanisms involve power line analysis. No claim element reads on RSDGGS. RSDGGS improvement opportunity — Lookup Table Architecture: US 9,654,965 explicitly discloses the architecture of a location-to- regulations lookup table stored locally on the device, optionally small enough to fit in embedded memory, potentially updated from network. This is directly analogous to the RSDGGS regulatory database architecture defined in Section 8. The patent discloses this as a WLAN channel compliance mechanism; RSDGGS generalizes it to ISM bands with a hierarchical geographic index as the lookup key. Because 9,654,965 is active, RSDGGS implementations MUST NOT incorporate AC power line frequency as a location verification step alongside the lookup table. The lookup table architecture itself predates 9,654,965 as prior art (RFC 2009 describes location-to- routing-table mapping from 1996), but the specific combination of local storage + network update + GNSS/MCC/AP location sources for the lookup key is a design pattern that RSDGGS implementations should credit to this work in any patent prosecution. 18.2.2. US Patent 10,812,365 — Geohyperbolic Routing (Northeastern University, Active until 2037) Title: Geohyperbolic Routing and Addressing Schemes for Networks. Inventors: Dmitri Krioukov, Ivan Voitalov. Assignee: Northeastern University, Boston. Filed November 16, 2017. Granted October 20, 2020. Active, expires December 25, 2037. Hanley Expires 23 April 2027 [Page 91] Internet-Draft RSDGGS October 2026 Core claim elements: Network address = (r_i, theta_i, phi_i) in 3D hyperbolic space theta_i, phi_i = lat/lon mapped to angular coordinates r_i = centrality derived from population density zone rank Routing = greedy forwarding minimizing HYPERBOLIC DISTANCE Topology construction = connect to m geographically nearest neighbors; network reproduces Internet power-law topology CPC H04L2101/69: geographic information in network address CPC H04W40/20: route selection based on geographic position RSDGGS distinguishing elements (no infringement): No hyperbolic space — RSDGGS uses integer cell index No radial centrality component — no population density Forwarding metric = common-prefix-length (XOR+CLZ), not hyperbolic distance Topology independent of population density zone ranking Face assignment = ITU regulatory zones, not Internet-scale power-law topology reproduction Figure 45 RSDGGS improvement opportunity — None applicable: The geohyperbolic model is specifically optimized for large-scale Internet backbone topology reproduction, using population-density centrality to reproduce power-law degree distributions. RSDGGS targets constrained 802.15.4 IoT mesh networks with no backbone topology requirements and no population-density data available at compile time on embedded devices. The mathematical approaches are incompatible at a fundamental level: hyperbolic geometry requires floating-point (r, theta, phi) arithmetic, whereas RSDGGS's design goal G4 requires no- FPU integer arithmetic. No improvement opportunity from this patent is applicable to RSDGGS. Backward citations of interest: US 10,812,365 cites US 8,284,788 (Krioukov et al., hyperbolic network embedding, 2012) as a predecessor. The academic paper by Krioukov et al. 'Hyperbolic Geometry of Complex Networks' (Physical Review E, 2010) is the underlying research. Both establish that hyperbolic geometry for Internet-scale routing is a well-developed research area distinct from RSDGGS's approach. 18.2.3. US Patent 11,652,742 — Ghost Routing (Microsoft, Active until 2041) Title: Ghost Routing. Assignee: Microsoft Technology Licensing LLC. Inventors: Padhye, Jayaraman, Bai, Singh, Beckett, et al. Filed October 16, 2020. Granted May 16, 2023. Active, expires January 1, 2041. Hanley Expires 23 April 2027 [Page 92] Internet-Draft RSDGGS October 2026 Core claim elements: Production network logically partitioned into: Main segment: live traffic, config set A Ghost segment: test traffic, config set B, same hardware Segmentation via VRF (Virtual Routing and Forwarding) PBR (policy-based routing) on DSCP bits selects segment Debugging software verifies ghost routing/forwarding tables Change promotion: ghost -> main after verification CPC H04L43/50: network testing arrangements CPC H04L45/586: virtual router association RSDGGS relationship: ZERO OVERLAP No VRF, no PBR, no DSCP, no forwarding table verification No datacenter/cloud concepts of any kind This is a cloud network change management patent Figure 46 RSDGGS improvement opportunity — None: Ghost routing addresses verification of network configuration changes in cloud datacenter switching infrastructure. It has no technical concepts, no claim elements, and no CPC classifications that overlap with RSDGGS. The name superficially resembles geographic routing but the technical subject matter is entirely unrelated. No improvement opportunity exists. 18.2.4. CN101923801B — Method for Generating a Regular Dodecahedron Map Projection (Expired) Assignee: Wuhan University (WHU), Wuhan, China. Inventors: Hu Peng, Li Yunxiang, Zhu Fuli. Application number: CN2009100626550A. Filing and priority date: 10 June 2009. Grant date: 29 February 2012. Jurisdiction: China only (no PCT application, no US, EP, or other national-phase equivalents identified). Legal status: Expired — Fee Related. Anticipated statutory expiration: 10 June 2029 (20-year term from filing). Actual status: lapsed prior to statutory expiration due to non-payment of annual maintenance fees. Hanley Expires 23 April 2027 [Page 93] Internet-Draft RSDGGS October 2026 Legal status note: 'Expired — Fee Related' = patent lapsed due to non-payment of annual maintenance fees under Chinese patent law. The claims entered the public domain at the date of lapse. The 2029 anticipated expiration date is the statutory maximum; the actual lapse occurred earlier. The patent is unenforceable and cannot be asserted against any implementer anywhere. Jurisdiction note: CN101923801B is a Chinese national patent only. No PCT (international) application was filed. No US, EP, JP, KR, or other national-phase equivalents exist. Even if the patent were active, its territorial scope would be limited to China and could not be enforced in the United States, European Union, or other IETF-relevant jurisdictions. Figure 47 The method disclosed in CN101923801B describes a cartographic rendering pipeline for producing physical dodecahedron map products. The claimed method orients the dodecahedron so that one vertex coincides with the Earth's geographic North Pole and the antipodal vertex with the South Pole, selects a user-defined region of interest to determine each face's central meridian, applies a gnomonic projection per face to transform geographic vector data, clips the result to each pentagonal boundary, and outputs twelve pentagonal paper maps for assembly into a physical dodecahedron. The implementation is explicitly tied to ArcGIS and ESRI Shapefile data formats as the required geographic data pipeline. Hanley Expires 23 April 2027 [Page 94] Internet-Draft RSDGGS October 2026 Core claim elements (CN101923801B): Step 1: Orient dodecahedron with North Pole vertex at geographic north pole, South Pole vertex at geographic south pole Step 2: User selects region of interest; central meridian of that face = meridian nearest region geometric center Step 3: Extract ArcGIS/ESRI Shapefile geographic data; compute vertex lat/lon via projection formula; generate edge Shapefile files in ArcMap environment Step 4: Project geographic data face-by-face using coordinate transformation formula; rewrite Shapefile coordinates Step 5: Clip to pentagon boundary; output 12 pentagonal maps Step 6: Assemble 12 pentagonal maps into physical dodecahedron Output artifact: visual cartographic map product (paper maps) Data pipeline: ArcGIS / ArcMap / ESRI Shapefile (.lyr, .shp) Purpose: Geographic visualization and education RSDGGS distinguishing elements — no claim reads on RSDGGS: D1: Orientation — RSDGGS orients Face 2 at 39°N, 98°W (ITU Region 2 anchor); not North/South Pole alignment D2: Face assignment — RSDGGS faces are fixed to ITU Radio Regions; no user-selected region of interest or central meridian determination step exists in RSDGGS D3: Output — RSDGGS produces a 1-8 byte integer cell index; it produces no map, no Shapefile, no visual output D4: Pipeline — RSDGGS uses no ArcGIS, ArcMap, or ESRI Shapefile; encoding is pure arithmetic on a unit sphere D5: Purpose — RSDGGS encodes regulatory jurisdiction for IoT ISM band compliance; CN101923801B renders maps D6: Physical artifact — RSDGGS specifies no physical object; CN101923801B explicitly claims a paper map assembly step Figure 48 Freedom to operate conclusion: CN101923801B presents no freedom-to- operate concern for RSDGGS on three independent grounds, each sufficient alone. First, the patent is expired due to fee non- payment and its claims are in the public domain — no enforcement is possible regardless of claim scope. Second, the patent is China- jurisdiction only with no international equivalents, so even if active it could not be enforced in the United States, European Union, Japan, or any other IETF-process jurisdiction. Third, no claim element of CN101923801B reads on RSDGGS: the patent covers a cartographic rendering pipeline for producing visual map products from geographic vector data using ArcGIS tooling, whereas RSDGGS is a binary integer encoding scheme for IoT device regulatory context with no map output, no GIS pipeline, and no physical artifact. The shared concept of using a dodecahedron as an Earth reference surface is Hanley Expires 23 April 2027 [Page 95] Internet-Draft RSDGGS October 2026 established prior art predating CN101923801B by decades, with the gnomonic polyhedral map projection appearing in academic cartography literature since at least the 1940s (Fuller, 1944, US Patent 2,393,676, expired 1963) and in peer-reviewed cartographic literature through the 1990s. Prior art note: CN101923801B itself acknowledges that dodecahedron map projection is a known concept by framing its contribution as 'breaking through the limitation that the previous projection surface is a plane and a developable surface.' The gnomonic projection of the Earth onto a regular dodecahedron is explicitly not novel to CN101923801B — the claimed novelty is the specific ArcGIS-based rendering workflow and the face-by-face data extraction pipeline. RSDGGS's use of the dodecahedron as a hierarchical geographic index is therefore independently supported by prior art that predates CN101923801B, in addition to the non-infringement analysis above. 18.3. RFC Citation Improvement Opportunities The following analysis reviews each RFC cited in Section 16 (Relationship to Prior Geographic Addressing Work) and Section 21 (References) for improvement opportunities: technical details in those RFCs that RSDGGS could incorporate, extend, or more precisely differentiate from. 18.3.1. RFC 2009 — GPS-Based Addressing (1996, Experimental/Legacy) Improvement opportunity — Weak beacon concept: RFC 2009 Section 5.2 defines 'weak radio beacons' that broadcast a GPS address enabling indoor devices without GPS to adopt the beacon's address. This is structurally identical to RSDGGS Section 11's peer-assisted location discovery, but RFC 2009's approach is address adoption (the Naive Device copies the beacon's address) rather than address derivation (RSDGGS derives its own cell from the beacon's cell via intersection and ranging). RSDGGS should explicitly note this distinction: RFC 2009's approach loses geographic uniqueness for devices sharing an adopted address, whereas RSDGGS's intersection-and-ranging approach preserves geographic uniqueness. This distinction strengthens the novelty claim of Section 11. Improvement opportunity — IGPSMP protocol gap: RFC 2009 proposes IGPSMP (Internet GPS Management Protocol) for router-to-router geographic service area exchange, with a polygon boundary representation. RSDGGS explicitly avoids polygon boundaries in favor of cell prefix hierarchy. Noting that RSDGGS's approach eliminates IGPSMP entirely (routing decisions from address arithmetic, no management protocol needed) more precisely characterizes RSDGGS's architectural simplification relative to RFC 2009. Hanley Expires 23 April 2027 [Page 96] Internet-Draft RSDGGS October 2026 18.3.2. RFC 5870 — geo URI Scheme (2010, Standards Track) Improvement opportunity — Uncertainty parameter alignment: RFC 5870 Section 3.4 defines the u= parameter as the uncertainty radius in meters, explicitly stating that it represents the uncertainty of the location rather than a desired precision. RSDGGS's truncation model produces cells with a defined radius (cell diameter / 2), which is conceptually equivalent to u= but is structural rather than declared. The RSDGGS-to-geo-URI translation proposed in Section 16.2 should map cell radius to u=, but must note that RFC 5870 explicitly states u= MUST NOT be interpreted as a request for a certain level of precision from a location server. The cell radius is a guaranteed precision bound, not a request — a stronger property than RFC 5870's u= semantics. Improvement opportunity — CRS extensibility: RFC 5870 Section 3.5 defines a crs= parameter for alternative coordinate reference systems (default WGS-84). A future RSDGGS-aware geo URI extension could define crs=rsdggs as a CRS identifier, with the URI carrying the RSDGGS cell hex string as the coordinate value. This would enable geo URI interoperability for RSDGGS cell references in web and messaging contexts without loss of the RSDGGS hierarchical structure. This is a concrete future work item for Section 21 of the draft. 18.3.3. RFC 6442 — Location Conveyance for SIP (2011, Standards Track) Improvement opportunity — 424 error code applicability: RFC 6442 Section 6 defines the 424 (Bad Location Information) SIP response code for cases where location cannot be processed. For RSDGGS-SIP integration (a gateway translating RSDGGS cells to PIDF-LO for emergency services), this error code should be returned when the RSDGGS cell's resolution is insufficient for the requested service (e.g., a 1-byte cell when the SIP application requires country-level precision). Defining an RSDGGS-specific error sub-code for 'insufficient cell resolution' would improve SIP gateway interoperability. Improvement opportunity — Geolocation-Routing header: RFC 6442 Section 8 defines a Geolocation-Routing SIP header that can be set to 'yes' to indicate that the location should influence routing. RSDGGS geographic IPv6 addresses (Section 15) embed routing information in the address itself, making the Geolocation-Routing header redundant for RSDGGS-addressed traffic. Explicitly noting this in the draft strengthens the architectural case for RSDGGS-IPv6 as a simplification over SIP-based geographic routing. Hanley Expires 23 April 2027 [Page 97] Internet-Draft RSDGGS October 2026 18.3.4. RFC 9179 — YANG Grouping for Geographic Locations (2022, Standards Track) Improvement opportunity — Velocity field: RFC 9179 Section 5 defines velocity as a first-class field in the geo-location grouping: v-north, v-east, and v-up in meters/second with 12 fraction-digits precision. RSDGGS Section 13.7 (Extended Kalman Filter) defines a velocity component in the EKF state vector as cells-per-second, but the CDDL schema in Section 7.3 does not expose velocity externally. Adding an optional velocity field to the RSDGGS CBOR encoding — expressed in EKF cell units for constrained devices or as an RFC 9179-compatible (v-north, v-east) pair for gateway contexts — would improve interoperability with YANG-managed network infrastructure. Improvement opportunity — Altitude encoding: RFC 9179 defines height above WGS-84 ellipsoid in meters as a decimal64 field. RSDGGS Section 7.3 includes an optional alt-m float16 field in the location CDDL. Float16 provides only ~3 significant decimal digits of altitude precision (~1 meter at low altitude, degrading above 1 km). For applications requiring RFC 9179-compatible altitude precision, the CDDL should provide an alternative float32 or decimal encoding. This is a minor schema enhancement that should be noted as a future revision item. 18.3.5. RFC 9632 / RFC 8805 — Geofeed Data (2024 / 2020) Improvement opportunity — RSDGGS-IPv6 geofeed compliance: RFC 8805 Section 2.1 defines the geofeed CSV format with fields: ip_prefix, alpha2code, region, city, postal_code. RFC 9632 Section 4 defines how geofeed files are discovered via RPSL inetnum objects. RSDGGS- IPv6 addresses are inherently geofeed-compatible, as noted in Section 15, but the specific mapping has not been formalized. A concrete improvement: define a RSDGGS-IPv6 geofeed profile where ip_prefix encodes the RSDGGS face (/72) or country-scale cell (/88), alpha2code is derived from the face's ITU Region, and region is the face name from the RSDGGS face table. This profile would make RSDGGS-IPv6 deployments automatically RFC 9632-compliant without any additional geofeed file maintenance. 18.3.6. RFC 5808 — Location-by-Reference Requirements (2010, Informational) Improvement opportunity — Dereference latency requirement: RFC 5808 Section 4.3 requires that a location URI dereference return the current location at the time of dereference, not the location at the time the URI was created. This requirement is irrelevant to RSDGGS LbyV (Location-by-Value) encoding, but it highlights a gap: RSDGGS does not define a staleness indicator for the cell index. A device Hanley Expires 23 April 2027 [Page 98] Internet-Draft RSDGGS October 2026 that provisioned its cell at manufacturing time (Section 12) and has never moved still carries a potentially stale index. Adding an optional timestamp or age field to the CBOR encoding would allow receivers to determine whether the cell index is current-position or provisioned-position, analogous to RFC 5808's dereference-time semantics. This is a concrete CDDL enhancement for the next draft revision. 18.3.7. RFC 5491 — PIDF-LO Usage (2009, Standards Track) Improvement opportunity — Confidence level encoding: RFC 5491 Section 5.5 defines a confidence attribute in PIDF-LO location shapes, expressing the probability (as a percentage) that the described region contains the true location. RSDGGS implicitly expresses 100% confidence that the true location is within the stated cell (by construction of the encoding: the cell is computed from the true coordinate, so it always contains that coordinate). However, for RSDGGS cells derived from peer-assisted localization (Section 13) where the cell is inferred rather than computed, the confidence may be lower. Adding an optional confidence field (uint8, percentage) to the CBOR location encoding would align RSDGGS with RFC 5491's confidence model and would be particularly useful for cells derived from the cell intersection method of Section 13.2. 18.3.8. RFC 6280 — GEOPRIV Architecture (2011, BCP) Improvement opportunity — Rule Maker analog: RFC 6280 Section 5 defines the Rule Maker role: the entity (typically the device owner) who specifies what location information may be disclosed to whom. RSDGGS's structural privacy model (byte truncation) does not support rule-based disclosure. For deployments where different recipients should receive different resolution (e.g., a regulatory compliance server receives 3 bytes, a fleet tracking application receives 7 bytes), an application-layer resolution selection mechanism is needed. Defining a CBOR map structure that carries multiple truncated cells at different resolutions, labeled by intended recipient type, would provide a RSDGGS-native analog to RFC 6280's Rule Maker mechanism without requiring XCAP or a Location Server. 18.3.9. RFC 6772 — Geolocation Policy (2013, Standards Track) Improvement opportunity — Location-based condition analog: RFC 6772 Section 8 defines location-based conditions in policy rules: rules that apply only when the Target is within a specified geographic region. RSDGGS's RSL (Resolution Sufficiency Level) table in Section 8.2 is a regulatory-driven analog to RFC 6772's location- based conditions, but applies uniformly without per-device policy variation. For deployments with site-specific privacy requirements Hanley Expires 23 April 2027 [Page 99] Internet-Draft RSDGGS October 2026 (e.g., a factory that requires higher location precision within its boundary but coarser precision outside), an RSDGGS extension could define per-cell RSL overrides stored in the regulatory database exception table (Section 8.3). This would be the RSDGGS-native equivalent of RFC 6772's location-based policy conditions without XML or XCAP infrastructure. 18.4. Summary of Improvement Opportunities The following table consolidates all actionable improvement opportunities identified from the cited patents and RFCs, categorized by implementation priority. +============+=====================+=============+==================+ | Source | Opportunity | Section | Priority | | | | Affected | | +============+=====================+=============+==================+ | US | Link quality | Section | High — routing | | 4,939,726 | weighted | 15.3 | performance | | / | forwarding | | | | 5,115,433 | (distance + | | | | | power + retry) | | | +------------+---------------------+-------------+------------------+ | US | Explicit credit | Section 8, | Medium — FTO | | 10,306,400 | of lookup table | Patent | documentation | | / | architecture | prosecution | | | 9,654,965 | pattern | | | +------------+---------------------+-------------+------------------+ | RFC 2009 | Distinguish | Section 11 | Medium — novelty | | | address adoption | intro | clarity | | | vs address | | | | | derivation in | | | | | peer location | | | +------------+---------------------+-------------+------------------+ | RFC 5870 | crs=rsdggs URI | Section 21 | Low — | | | extension as | future work | interoperability | | | future work item | | | +------------+---------------------+-------------+------------------+ | RFC 6442 | 424 sub-code for | Section | Low — SIP | | | insufficient | 16.3 / | integration | | | cell resolution | gateway | | | | at SIP gateway | spec | | +------------+---------------------+-------------+------------------+ | RFC 9179 | Velocity field | Section 7.3 | Medium — YANG | | | in CBOR location | CDDL | interop | | | encoding | | | +------------+---------------------+-------------+------------------+ | RFC 9179 | Float32 altitude | Section 7.3 | Low — schema | Hanley Expires 23 April 2027 [Page 100] Internet-Draft RSDGGS October 2026 | | option for | CDDL | extension | | | precision | | | | | applications | | | +------------+---------------------+-------------+------------------+ | RFC 9632 / | Formalize | Section 15 | High — | | 8805 | RSDGGS-IPv6 | / new | deployment | | | geofeed profile | appendix | utility | | | mapping | | | +------------+---------------------+-------------+------------------+ | RFC 5808 | Optional | Section 7.3 | Medium — LbyV | | | staleness/ | CDDL | semantics | | | timestamp field | | | | | in CBOR encoding | | | +------------+---------------------+-------------+------------------+ | RFC 5491 | Confidence | Section 7.3 | Medium — | | | percentage field | CDDL | cooperative | | | for peer-derived | | location | | | cells | | | +------------+---------------------+-------------+------------------+ | RFC 6280 | Multi-resolution | Section 7 / | Medium — privacy | | | CBOR map for | new section | model | | | per-recipient | | | | | disclosure | | | +------------+---------------------+-------------+------------------+ | RFC 6772 | Per-cell RSL | Section 8.3 | Low — policy | | | override in | / 10 | extension | | | exception table | | | +------------+---------------------+-------------+------------------+ Table 20: Summary of Improvement Opportunities The highest-priority improvements — link quality weighted forwarding, RSDGGS-IPv6 geofeed profile, and the staleness field — represent concrete enhancements to the core specification that should be incorporated in the -01 revision. The medium-priority items are suitable for informational notes or future work statements in the current -00 draft. The low-priority items are candidates for companion specifications or implementation guidance documents. 18.5. Recommended Clearance Actions Prior to commercial deployment or patent prosecution based on RSDGGS, the following actions are recommended: Hanley Expires 23 April 2027 [Page 101] Internet-Draft RSDGGS October 2026 1. US 10,812,365 (Northeastern/Krioukov, active until 2037): No infringement risk identified. The hyperbolic geometry, radial centrality, and population-density zone ranking in every claim are completely absent from RSDGGS. No action required beyond documenting the technical distinction in any patent prosecution filings. 2. US 11,652,742 (Microsoft, active until 2041): No infringement risk. Ghost routing is a cloud datacenter network verification technique with zero overlap with RSDGGS. No action required. 3. US 10,306,400 / application family (active until ~2035): No infringement risk from current RSDGGS specification. RSDGGS MUST NOT add AC power line frequency as a location verification mechanism. Any patent prosecution should distinguish the lookup table architecture using RFC 2009 (1996) as prior art predating US 9,654,965. 4. US 4,939,726 and US 5,115,433 (both expired): Freely implementable. The link quality weighted forwarding enhancement described in Section 17.3 above should be incorporated in the -01 revision and explicitly credited to these expired patents as the enabling prior art in any prosecution. 5. Search CPC class H04W16/14 (channel plan based on geography) and H04B1/3827 (ISM band operation) for active patents not identified here. This search should be conducted by patent counsel before commercial deployment. 6. Search for continuation patents based on US Application 2014/0162692 beyond the identified US 10,306,400, US 9,794,738, and US 9,654,965. The application family may have additional continuations with broader claims. 7. For the RSDGGS-IPv6 geofeed profile (improvement opportunity from RFC 9632 / 8805): verify that no active patent covers the specific combination of hierarchical geographic grid prefix as an IP geofeed CSV entry. This combination appears novel but has not been searched. 8. RFC publication of draft-hanley-rsdggs-00 establishes a prior art date for all disclosed subject matter including the improvement opportunities listed in Section 17.4. This is a significant benefit of early publication even before normative follow-on work is complete. Hanley Expires 23 April 2027 [Page 102] Internet-Draft RSDGGS October 2026 19. Reference Implementation (Rust Pseudocode) This section provides a complete reference implementation of the RSDGGS encoder in Rust pseudocode. The implementation is structured as a no_std, no_alloc crate suitable for deployment on constrained 802.15.4 devices. All algorithms are expressed in terms that map directly to the mathematical definitions in the preceding sections. Floating-point arithmetic (f64) is used for the encode path; a fixed- point variant suitable for devices without FPU is noted where applicable. This is pseudocode intended to specify behavior precisely. A production implementation would require additional error handling, const evaluation of intermediate values, and platform-specific optimizations. The worked example at Section 20.10 provides a concrete verification vector. 19.1. Crate Structure and Types Hanley Expires 23 April 2027 [Page 103] Internet-Draft RSDGGS October 2026 #![no_std] #![no_implicit_prelude] // rsdggs/src/lib.rs // // RSDGGS — Regulatory Spectrum Discrete Global Grid System // Encodes a WGS-84 (latitude, longitude) coordinate into a // 1-to-8 byte RSDGGS cell index. use core::f64::consts::PI; /// An RSDGGS cell index. Length in [1..=8] bytes. /// Byte 0: face index [0..11]. /// Byte 1: pentagon sector [0..4] in bits [7:5], /// subdivision levels 1–2 in bits [4:1], /// subdivision level 3 high bit in bit [0]. /// Bytes 2–7: subdivision levels packed 2 bits per level, MSB-first. #[derive(Copy, Clone, Debug, PartialEq, Eq)] pub struct RsdggsCell { pub bytes: [u8; 8], pub len: u8, // 1..=8 } /// WGS-84 coordinate in decimal degrees. #[derive(Copy, Clone, Debug)] pub struct LatLon { pub lat: f64, // -90.0 .. +90.0 pub lon: f64, // -180.0 .. +180.0 } /// Unit vector on the unit sphere. type Vec3 = [f64; 3]; Figure 49 19.2. Compile-Time Constants The twelve face center unit vectors and the sixty pentagon vertex unit vectors are precomputed constants derived from the dodecahedron orientation procedure defined in Section 4.3: face 1 centered at (60.0N, 26.5E), with face 2's center at bearing 304.0 degrees from it. These constants are reproduced here to 15 decimal places and MUST be used by all conforming implementations. The rotation algorithm from Section 4.3 is not invoked at runtime. Hanley Expires 23 April 2027 [Page 104] Internet-Draft RSDGGS October 2026 /// Dodecahedron face center unit vectors, in RSDGGS face index order. /// The two low-order bits of a face index give its ITU Region /// (1, 2, 3), or 0 for none (Section 4.2). const FACE_CENTERS: [Vec3; 12] = [ // face 0: Antarctica / New Zealand (60.00S, 153.50W) [-0.447467180801013, -0.223098906554904, -0.866025403784439], // face 1: Europe (Region 1) (60.00N, 26.50E) [ 0.447467180801013, 0.223098906554904, 0.866025403784439], // face 2: North America (Region 2) (39.60N, 79.28W) [ 0.143335330773340, -0.757103386787452, 0.637377003559956], // face 3: Asia (Region 3) (23.76N, 104.10E) [-0.222927725022592, 0.887676795997717, 0.402905864022206], // face 4: South Atlantic (54.80S, 1.18E) [ 0.576250379942283, 0.011826692425747, -0.817187633877705], // face 5: Africa / Middle East (Region 1) (1.89S, 44.32E) [ 0.715023395428751, 0.698323830480811, -0.032944980985703], // face 6: South America (Region 2) (23.76S, 75.90W) [ 0.222927725022592, -0.887676795997717, -0.402905864022206], // face 7: Eastern Australia (Region 3) (6.43S, 161.32E) [-0.941386412734036, 0.318206226502688, -0.111966152629545], // face 8: Southern Indian Ocean (39.60S, 100.72E) [-0.143335330773340, 0.757103386787452, -0.637377003559956], // face 9: West Africa (Region 1) (6.43N, 18.68W) [ 0.941386412734036, -0.318206226502688, 0.111966152629545], // face 10: Central Pacific (Region 2) (1.89N, 135.68W) [-0.715023395428751, -0.698323830480811, 0.032944980985703], // face 11: North Pacific (Region 3) (54.80N, 178.82W) [-0.576250379942283, -0.011826692425747, 0.817187633877705], ]; /// Pentagon vertices per face, counter-clockwise as seen from outside /// the sphere, starting at the smallest bearing from the face center. /// Triangle k of a face is (center, v[k], v[(k+1) % 5]). const FACE_PENTAGON_VERTS: [[Vec3; 5]; 12] = [ // face 0 [ [-0.394117982078212, -0.758862120210154, -0.518458579553611], [-0.882512279371043, -0.253030942615585, -0.396418237267655], [-0.642706558944036, 0.357476419605567, -0.677597881133273], [-0.006104175730659, 0.228959542245713, -0.973416800272773], [ 0.147532013987386, -0.460975618311830, -0.875063302950622], ], // face 1 [ [-0.147532013987386, 0.460975618311830, 0.875063302950622], [ 0.006104175730659, -0.228959542245713, 0.973416800272773], [ 0.642706558944036, -0.357476419605567, 0.677597881133273], [ 0.882512279371043, 0.253030942615585, 0.396418237267655], Hanley Expires 23 April 2027 [Page 105] Internet-Draft RSDGGS October 2026 [ 0.394117982078212, 0.758862120210154, 0.518458579553611], ], // face 2 [ [ 0.642706558944036, -0.357476419605567, 0.677597881133273], [ 0.006104175730659, -0.228959542245713, 0.973416800272773], [-0.481525193076291, -0.615468299264912, 0.623964951766360], [-0.146294333698268, -0.982860725412106, 0.112172912818419], [ 0.548519100282137, -0.823412974961158, 0.145319886083393], ], // face 3 [ [-0.147532013987386, 0.460975618311830, 0.875063302950622], [ 0.394117982078212, 0.758862120210154, 0.518458579553611], [ 0.146294333698268, 0.982860725412106, -0.112172912818419], [-0.548519100282137, 0.823412974961158, -0.145319886083393], [-0.730113769942115, 0.500870240550808, 0.464825650186699], ], // face 4 [ [ 0.936532906629690, 0.164408687494709, -0.309638334635768], [ 0.730113769942115, -0.500870240550808, -0.464825650186699], [ 0.147532013987386, -0.460975618311830, -0.875063302950622], [-0.006104175730659, 0.228959542245713, -0.973416800272773], [ 0.481525193076291, 0.615468299264912, -0.623964951766360], ], // face 5 [ [ 0.394117982078212, 0.758862120210154, 0.518458579553611], [ 0.882512279371043, 0.253030942615585, 0.396418237267655], [ 0.936532906629690, 0.164408687494709, -0.309638334635768], [ 0.481525193076291, 0.615468299264912, -0.623964951766360], [ 0.146294333698268, 0.982860725412106, -0.112172912818419], ], // face 6 [ [ 0.548519100282137, -0.823412974961158, 0.145319886083393], [-0.146294333698268, -0.982860725412106, 0.112172912818419], [-0.394117982078212, -0.758862120210154, -0.518458579553611], [ 0.147532013987386, -0.460975618311830, -0.875063302950622], [ 0.730113769942115, -0.500870240550808, -0.464825650186699], ], // face 7 [ [-0.936532906629690, -0.164408687494709, 0.309638334635768], [-0.730113769942115, 0.500870240550808, 0.464825650186699], [-0.548519100282137, 0.823412974961158, -0.145319886083393], [-0.642706558944036, 0.357476419605567, -0.677597881133273], Hanley Expires 23 April 2027 [Page 106] Internet-Draft RSDGGS October 2026 [-0.882512279371043, -0.253030942615585, -0.396418237267655], ], // face 8 [ [-0.548519100282137, 0.823412974961158, -0.145319886083393], [ 0.146294333698268, 0.982860725412106, -0.112172912818419], [ 0.481525193076291, 0.615468299264912, -0.623964951766360], [-0.006104175730659, 0.228959542245713, -0.973416800272773], [-0.642706558944036, 0.357476419605567, -0.677597881133273], ], // face 9 [ [ 0.882512279371043, 0.253030942615585, 0.396418237267655], [ 0.642706558944036, -0.357476419605567, 0.677597881133273], [ 0.548519100282137, -0.823412974961158, 0.145319886083393], [ 0.730113769942115, -0.500870240550808, -0.464825650186699], [ 0.936532906629690, 0.164408687494709, -0.309638334635768], ], // face 10 [ [-0.481525193076291, -0.615468299264912, 0.623964951766360], [-0.936532906629690, -0.164408687494709, 0.309638334635768], [-0.882512279371043, -0.253030942615585, -0.396418237267655], [-0.394117982078212, -0.758862120210154, -0.518458579553611], [-0.146294333698268, -0.982860725412106, 0.112172912818419], ], // face 11 [ [ 0.006104175730659, -0.228959542245713, 0.973416800272773], [-0.147532013987386, 0.460975618311830, 0.875063302950622], [-0.730113769942115, 0.500870240550808, 0.464825650186699], [-0.936532906629690, -0.164408687494709, 0.309638334635768], [-0.481525193076291, -0.615468299264912, 0.623964951766360], ], ]; /// Subdivision child indices (2 bits each). /// 0b00 = apex child (toward face center apex of parent triangle) /// 0b01 = left base child /// 0b10 = right base child /// 0b11 = central inverted child const CHILD_APEX: u8 = 0b00; const CHILD_LEFT: u8 = 0b01; const CHILD_RIGHT: u8 = 0b10; const CHILD_CENTRAL: u8 = 0b11; Figure 50 Hanley Expires 23 April 2027 [Page 107] Internet-Draft RSDGGS October 2026 19.3. Coordinate Conversion Primitives /// Convert WGS-84 decimal degrees to unit Cartesian vector. /// lat in [-90.0, +90.0], lon in [-180.0, +180.0]. #[inline] fn to_cart(lat: f64, lon: f64) -> Vec3 { let phi = lat.to_radians(); // elevation angle from equator let lam = lon.to_radians(); // azimuth from prime meridian let cos_phi = phi.cos(); [cos_phi * lam.cos(), cos_phi * lam.sin(), phi.sin()] } /// Dot product of two unit vectors. #[inline] fn dot(a: Vec3, b: Vec3) -> f64 { a[0]*b[0] + a[1]*b[1] + a[2]*b[2] } /// Cross product of two vectors. #[inline] fn cross(a: Vec3, b: Vec3) -> Vec3 { [a[1]*b[2] - a[2]*b[1], a[2]*b[0] - a[0]*b[2], a[0]*b[1] - a[1]*b[0]] } /// Normalize a vector to unit length. #[inline] fn normalize(v: Vec3) -> Vec3 { let len = (v[0]*v[0] + v[1]*v[1] + v[2]*v[2]).sqrt(); [v[0]/len, v[1]/len, v[2]/len] } /// Spherical midpoint (normalized mean) of two unit vectors. /// Used at each subdivision level to find child triangle vertices. #[inline] fn sph_mid(a: Vec3, b: Vec3) -> Vec3 { normalize([a[0]+b[0], a[1]+b[1], a[2]+b[2]]) } /// Sign of the scalar triple product [a×b · p]. /// Positive if p is on the left side (CCW) of the arc a→b. #[inline] fn signed_angle(p: Vec3, a: Vec3, b: Vec3) -> f64 { dot(cross(a, b), p) } Hanley Expires 23 April 2027 [Page 108] Internet-Draft RSDGGS October 2026 /// Test whether point p lies within the spherical triangle (a, b, c). /// The winding of (a, b, c) must be consistent (all CCW or all CW). #[inline] fn in_sph_tri(p: Vec3, a: Vec3, b: Vec3, c: Vec3) -> bool { let s1 = signed_angle(p, a, b); let s2 = signed_angle(p, b, c); let s3 = signed_angle(p, c, a); (s1 > 0.0 && s2 > 0.0 && s3 > 0.0) || (s1 < 0.0 && s2 < 0.0 && s3 < 0.0) } Figure 51 19.4. Face Assignment Face assignment uses a nearest-face-center lookup via dot product. The face whose center unit vector has the maximum dot product with the query point is the face containing the point. This is equivalent to finding the face whose center is closest in angular distance, and requires no table lookup or coordinate transformation beyond the initial Cartesian conversion. /// Return the RSDGGS face index [0..11] for a WGS-84 coordinate. pub fn face_for(ll: LatLon) -> u8 { let p = to_cart(ll.lat, ll.lon); let mut best_face = 0u8; let mut best_dot = f64::NEG_INFINITY; for (i, &fc) in FACE_CENTERS.iter().enumerate() { let d = dot(p, fc); if d > best_dot { best_dot = d; best_face = i as u8; } } best_face } // NOTE: On devices without FPU, replace dot() with a 32-bit fixed-point // dot product using Q2.30 format. The FACE_CENTERS values are all in // [-1.0, +1.0], representable exactly in Q2.30. The comparison requires // only finding the maximum of 12 products — no sqrt, no trig. Figure 52 Hanley Expires 23 April 2027 [Page 109] Internet-Draft RSDGGS October 2026 19.5. Pentagon Sector Assignment Each face is divided into 5 golden gnomon triangular sectors by connecting the face center to each of the 5 pentagon vertices. The pentagon vertices are the centroids of the 5 icosahedron triangles surrounding the face's corresponding icosahedron vertex. These vertices are precomputed as constants for each face. For the reference implementation, the pentagon vertices are derived from the icosahedron face topology at compile time. The sector is found by testing the query point against each of the 5 spherical triangles (face_center, pv[i], pv[(i+1)%5]). /// Pentagon vertices for each RSDGGS face. /// PENTAGON_VERTS[face][sector] = unit vector of pentagon vertex. /// Vertices ordered CCW when viewed from outside the sphere. /// Precomputed from icosahedron face topology. const PENTAGON_VERTS: [[Vec3; 5]; 12] = [ // face 0 (Antarctic) — vertices omitted for brevity // [[ ... ], [ ... ], [ ... ], [ ... ], [ ... ]], // ... // face 2 (N. America) — computed pentagon vertices [ [ 0.3546, -0.5742, 0.7378], // pv[0] ~(47.6°N, 58.2°W) [ 0.5936, -0.7722, 0.2235], // pv[1] ~(12.9°N, 52.5°W) [ 0.6204, -0.7726, 0.1376], // pv[2] ~( 7.9°N, 51.3°W) [-0.3546, -0.8986, -0.2586], // pv[3] ~(15.0°S, 111.6°W) [ 0.0523, -0.9954, 0.0805], // pv[4] ~( 4.6°N, 86.9°W) ], // ... other faces similarly ]; /// Return the pentagon sector [0..4] within the given face /// for a query point p (unit vector). fn sector_for(face: u8, p: Vec3) -> u8 { let fc = FACE_CENTERS[face as usize]; let pvs = &PENTAGON_VERTS[face as usize]; for i in 0..5usize { let next = (i + 1) % 5; if in_sph_tri(p, fc, pvs[i], pvs[next]) { return i as u8; } } // Point is on a sector boundary; assign to sector 0 // (boundary points are vanishingly rare in practice) 0 } Hanley Expires 23 April 2027 [Page 110] Internet-Draft RSDGGS October 2026 Figure 53 19.6. Recursive Subdivision Given the face and sector, the query point is recursively assigned to child triangles. At each level the triangle is split into 4 children by connecting the midpoints of all three sides. The child containing the point is identified by the spherical containment test and its 2-bit index is recorded. The tangent-frame projection used in the reference encoder (projecting onto the north/east tangent plane at the face center) is replaced here by exact spherical triangle subdivision. The spherical midpoint function is used to compute child vertices exactly on the sphere, eliminating distortion accumulation across subdivision levels. /// Recursive subdivision state: current triangle vertices. #[derive(Copy, Clone)] struct Triangle { apex: Vec3, // top vertex (toward face center at level 0) left: Vec3, // left base vertex right: Vec3, // right base vertex inv: bool, // true if this is an inverted (central) child } /// Subdivide triangle into 4 children and return the one /// containing point p, plus the 2-bit child index. fn subdivide(tri: Triangle, p: Vec3) -> (Triangle, u8) { let m_al = sph_mid(tri.apex, tri.left); // midpoint apex-left let m_ar = sph_mid(tri.apex, tri.right); // midpoint apex-right let m_lr = sph_mid(tri.left, tri.right); // midpoint left-right // Child triangles (consistent CCW winding): let apex_child = Triangle { apex: tri.apex, left: m_al, right: m_ar, inv: false }; let left_child = Triangle { apex: m_al, left: tri.left, right: m_lr, inv: false }; let right_child = Triangle { apex: m_ar, left: m_lr, right: tri.right, inv: false }; let central_child = Triangle { apex: m_lr, left: m_ar, right: m_al, inv: true // inverted }; // Test containment in order: apex, left, right, central. Hanley Expires 23 April 2027 [Page 111] Internet-Draft RSDGGS October 2026 // Central is last — it contains any point not in the other three. if in_sph_tri(p, ac.apex, ac.left, ac.right) { return (apex_child, CHILD_APEX); } if in_sph_tri(p, lc.apex, lc.left, lc.right) { return (left_child, CHILD_LEFT); } if in_sph_tri(p, rc.apex, rc.left, rc.right) { return (right_child, CHILD_RIGHT); } (central_child, CHILD_CENTRAL) } /// Return the initial triangle for a face + sector. /// apex = face center, left/right = adjacent pentagon vertices. fn initial_triangle(face: u8, sector: u8) -> Triangle { let fc = FACE_CENTERS[face as usize]; let pvs = &PENTAGON_VERTS[face as usize]; let s = sector as usize; Triangle { apex: fc, left: pvs[s], right: pvs[(s + 1) % 5], inv: false, } } Figure 54 19.7. Top-Level Encode Function The encode function takes a WGS-84 coordinate and a desired length in bytes (1 to 8) and returns a populated RsdggsCell. The length parameter controls the resolution: 1 byte encodes face only; byte 1 carries the 4-bit sector and 2 subdivision levels, and each additional byte adds 4 subdivision levels (2 bits per level). /// Encode a WGS-84 coordinate as an RSDGGS cell index. /// /// # Arguments /// * \x60ll\x60 — latitude/longitude in decimal degrees (WGS-84) /// * \x60len\x60 — desired index length in bytes, 1..=8 /// /// # Returns /// An RsdggsCell with the first \x60len\x60 bytes populated. /// Remaining bytes are zero. pub fn encode(ll: LatLon, len: u8) -> RsdggsCell { debug_assert!(len >= 1 && len <= 8); Hanley Expires 23 April 2027 [Page 112] Internet-Draft RSDGGS October 2026 debug_assert!(ll.lat >= -90.0 && ll.lat <= 90.0); debug_assert!(ll.lon >= -180.0 && ll.lon <= 180.0); let mut cell = RsdggsCell { bytes: [0u8; 8], len }; let p = to_cart(ll.lat, ll.lon); // ── Byte 0: face index ────────────────────────────────────────── let face = face_for(ll); cell.bytes[0] = face; if len == 1 { return cell; } // ── Byte 1 [7:4]: pentagon sector ─────────────────────────────── let sector = sector_for(face, p); // Byte 1 layout: // bits [7:4] sector (4 bits, values 0-4; 5-15 reserved) // bits [3:2] subdiv level 1 // bits [1:0] subdiv level 2 // Bytes 2..len hold 4 levels each. let sub_levels = 2 + (len as usize - 2) * 4; let mut tri = initial_triangle(face, sector); let mut sub_bits = [0u8; 26]; // max 26 subdivision levels for level in 0..sub_levels { let (child_tri, child_idx) = subdivide(tri, p); sub_bits[level] = child_idx; tri = child_tri; } // Sector then levels, MSB first: exactly 8 * (len - 1) bits, // filling bytes 1..len with no remainder. let mut bits: u64 = sector as u64; for level in 0..sub_levels { bits = (bits << 2) | sub_bits[level] as u64; } for b in 1..len as usize { cell.bytes[b] = (bits >> (8 * (len as usize - 1 - b))) as u8; } cell } Figure 55 Hanley Expires 23 April 2027 [Page 113] Internet-Draft RSDGGS October 2026 19.8. Decode Function The decode function extracts the face, sector, and subdivision level sequence from a populated RsdggsCell. It does not reconstruct the precise geographic coordinate — it returns the cell information sufficient for regulatory database lookup. Geographic coordinate recovery (computing the cell center) is a separate operation not required for regulatory compliance. /// Decoded RSDGGS cell contents. #[derive(Debug)] pub struct DecodedCell { pub face: u8, pub sector: u8, pub sub_bits: [u8; 26], // 2 bits each, packed as 0b00..0b11 pub sub_levels: usize, } pub fn decode(cell: &RsdggsCell) -> DecodedCell { let face = cell.bytes[0] & 0x0F; let len = cell.len as usize; if len == 1 { return DecodedCell { face, sector: 0, sub_bits: [0u8; 26], sub_levels: 0 }; } let sector = cell.bytes[1] >> 4; // 5-15 reserved: reject // Extract sub_bits from byte 1 [3:0] and bytes 2..len let mut sub_bits = [0u8; 26]; let sub_levels = 2 + (len - 2) * 4; sub_bits[0] = (cell.bytes[1] >> 2) & 0x03; sub_bits[1] = cell.bytes[1] & 0x03; let mut sl = 2usize; for b in 2..len { sub_bits[sl ] = (cell.bytes[b] >> 6) & 0x03; sub_bits[sl + 1] = (cell.bytes[b] >> 4) & 0x03; sub_bits[sl + 2] = (cell.bytes[b] >> 2) & 0x03; sub_bits[sl + 3] = (cell.bytes[b] ) & 0x03; sl += 4; } DecodedCell { face, sector, sub_bits, sub_levels } } Hanley Expires 23 April 2027 [Page 114] Internet-Draft RSDGGS October 2026 Figure 56 19.9. Boundary Proximity Helper The boundary proximity function B(cell, band) from Section 9.3 is implemented as a database lookup returning the number of RSDGGS resolution steps to the nearest rule-set-changing boundary. The function signature is shown; the database backend is implementation- defined. Hanley Expires 23 April 2027 [Page 115] Internet-Draft RSDGGS October 2026 /// Regulatory band identifier. #[repr(u8)] #[derive(Copy, Clone, Debug)] pub enum IsmBand { Mhz433 = 0, // 433.05-434.79 MHz Mhz868 = 1, // 863-870 MHz Mhz915 = 2, // 902-928 MHz Mhz920 = 3, // 920-928 MHz regional } /// Result of a regulatory lookup for a given cell and band. #[derive(Debug)] pub struct RuleSet { pub available: bool, pub power_dbm: i8, // max EIRP pub duty_cycle: Option, // None = unrestricted pub lbt_required: bool, pub boundary_prox: u8, // steps to nearest conflict boundary } /// Look up the regulatory rule set for a cell and band. /// This is a trait to allow different database backends /// (flash-resident table, remote lookup, etc.) pub trait RegDatabase { fn lookup(&self, cell: &RsdggsCell, band: IsmBand) -> RuleSet; } /// Apply adaptive power reduction based on boundary proximity. /// Returns the adjusted maximum EIRP in dBm. pub fn boundary_power_dbm(rule: &RuleSet, nbr_pwr: i8) -> i8 { let p_max = rule.power_dbm.min(neighbor_power_dbm); let reduction_db: i8 = match rule.boundary_prox { 0 => { // On boundary: use neighbor power if more restrictive return p_max; } 1 => 10, 2 => 6, 3 => 3, _ => 0, }; rule.power_dbm - reduction_db } Figure 57 Hanley Expires 23 April 2027 [Page 116] Internet-Draft RSDGGS October 2026 19.10. Worked Example The following verification vector is derived from the reference implementation. Implementations MUST produce identical byte values for this input to be considered conformant. // Input: // latitude = 37.7749° N (San Francisco, CA, USA) // longitude = 122.4194° W // length = 4 bytes let sf = LatLon { lat: 37.7749, lon: -122.4194 }; let cell = encode(sf, 4); // Expected output: // cell.bytes[0] = 0x02 face 2 (ITU Region 2, N. America) // cell.bytes[1] = 0x25 sector 2 [7:4]=0010; sub_bits[0]=1 [3:2]=01; // sub_bits[1]=1 [1:0]=01 // cell.bytes[2] = 0xE0 sub_bits[2..6]: 0b11 0b10 0b00 0b00 // cell.bytes[3] = 0xC3 sub_bits[6..10]: 0b11 0b00 0b00 0b11 // cell.len = 4 assert_eq!(cell.bytes[0], 0x02); assert_eq!(cell.bytes[1], 0x25); assert_eq!(cell.bytes[2], 0xE0); assert_eq!(cell.bytes[3], 0xC3); assert_eq!(cell.len, 4); // Verify face lookup for additional reference points: // London (51.51°N, 0.13°W) → face 1 (ITU Region 1, Europe) // Tokyo (35.68°N, 139.69°E) → face 3 (ITU Region 3, Asia) // Beijing (39.91°N, 116.39°E) → face 3 (ITU Region 3, Asia) // São Paulo (23.55°S, 46.63°W) → face 6 (ITU Region 2, S. America) // Sydney (33.87°S, 151.21°E) → face 7 (Region 3, E. Australia) // // Note: Tokyo is 1.3 degrees inside face 3; Sapporo, further north, // is on face 11 (North Pacific). Both faces carry Region 3 in their // low two bits (3 & 0x3 = 11 & 0x3 = 3). // 1-byte truncation (privacy / regulatory coarse lookup): let coarse = RsdggsCell { bytes: [0x02, 0,0,0,0,0,0,0], len: 1 }; // A 1-byte index encodes only the face (ITU Region 2). // Sufficient to determine that 902-928 MHz is legal at this location. Figure 58 Hanley Expires 23 April 2027 [Page 117] Internet-Draft RSDGGS October 2026 The worked example demonstrates the encode path from floating-point coordinate to structured byte sequence. The face-0x02 byte is the ITU Region 2 determination made at single-byte resolution. Truncating to 1 byte is sufficient for ISM band availability determination anywhere in North America, as specified in Section 9 (RSL for 902 MHz, Face 2 = 1 byte). The note on Tokyo illustrates that face assignment is driven by geometry: a jurisdiction near a face boundary can span two faces. The regulatory database is the authoritative source for rule set assignment; the face index is a lookup key, and its two low-order bits give the ITU Region of the face's principal population, not an encoding of administrative boundaries. 20. Security Considerations RSDGGS indexes are location-bearing data. Implementers must consider the following security properties: Location Privacy: The variable-length encoding provides a natural privacy gradient. Implementations SHOULD share the minimum resolution necessary for the intended purpose. For regulatory validation purposes, 1 to 3 octets is typically sufficient and reveals no more than country-level location. Full 8-octet indexes SHOULD be treated as sensitive location data. Beacon Authenticity: The peer-assisted discovery mechanism defined in Section 10 assumes that Beacon Devices transmit their correct regulatory context. A malicious device transmitting a beacon with a false RSDGGS cell could cause Naive Devices to adopt incorrect regulatory parameters, potentially causing interference. Implementations in security-sensitive deployments SHOULD implement beacon authentication using a shared key or public key infrastructure, and SHOULD cross-validate received cells against RF propagation models or approximate location data. Database Integrity: The regulatory database is a critical dependency. Database updates SHOULD be authenticated using code-signing mechanisms. Implementations SHOULD validate database integrity at boot using a stored hash. Regulatory Compliance: RSDGGS is an informational tool to assist devices in determining applicable regulatory parameters. It does not constitute a formal regulatory authorization. Operators remain responsible for ensuring their devices comply with applicable regulations in their jurisdiction of deployment, independent of the RSDGGS-derived rule set. Hanley Expires 23 April 2027 [Page 118] Internet-Draft RSDGGS October 2026 Database Currency: The regulatory database is a snapshot of regulations as of its compilation date. Spectrum regulations change through national legislation, WRC decisions, and bilateral coordination agreements. Implementations MUST NOT treat an embedded database as permanently authoritative. Deployments in jurisdictions undergoing active regulatory change are at elevated risk of non- compliance if database updates are unavailable. See Section 8.4 for normative guidance on database validity limitations and recommended mitigations. Legacy and Long-Lived Devices: Devices deployed for extended operational lifetimes, common in industrial IoT and infrastructure monitoring, face growing risk of regulatory non-compliance as their embedded databases age. Operators of long-lived deployments SHOULD establish a database maintenance program and SHOULD prefer implementations that support authenticated over-the-air database updates. Devices that cannot receive updates SHOULD be audited against current regulations at intervals appropriate to the regulatory environment of the deployment region. Storage-Constrained Devices: Highly constrained devices that cannot store a complete regulatory database for all RSDGGS faces MUST implement a defined failure mode for cells with no database entry: either refuse transmission, adopt the most restrictive rule set available, or escalate to a trusted peer for regulatory context via the bootstrap mechanism in Section 11. Silently operating under incorrect or absent regulatory parameters is not a permitted failure mode. 21. IANA Considerations This document requests registration of a CBOR tag for the RSDGGS cell type in the CBOR Tags registry. The requested tag value is in the first-come-first-served range. The tag is used to identify a CBOR byte string as an RSDGGS cell index as defined in this document. Hanley Expires 23 April 2027 [Page 119] Internet-Draft RSDGGS October 2026 +===========+==========================================+ | Field | Value | +===========+==========================================+ | Tag | TBD (first-come-first-served range) | +-----------+------------------------------------------+ | Data item | byte string | +-----------+------------------------------------------+ | Semantics | RSDGGS geographic cell index, 1-8 octets | +-----------+------------------------------------------+ | Reference | This document | +-----------+------------------------------------------+ Table 21: CBOR Tag Registration 22. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, May 2017, . [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", RFC 8949, December 2020, . [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data Definition Language (CDDL)", RFC 8610, June 2019, . 23. Informative References [H3] Brodsky, I. and N. Greenfeld, "H3: Uber's Hexagonal Hierarchical Spatial Index", See Uber Engineering Blog, 2018, 2018. [ITU-RR] International Telecommunication Union, "Radio Regulations, Edition of 2020", See ITU, 2020, 2020. [RFC5491] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV Presence Information Data Format Location Object (PIDF-LO) Usage Clarification, Considerations, and Recommendations", RFC 5491, DOI 10.17487/RFC5491, March 2009, . Hanley Expires 23 April 2027 [Page 120] Internet-Draft RSDGGS October 2026 [RFC5808] Marshall, R., Ed., "Requirements for a Location-by- Reference Mechanism", RFC 5808, DOI 10.17487/RFC5808, May 2010, . [RFC6280] Barnes, R., Lepinski, M., Cooper, A., Morris, J., Tschofenig, H., and H. Schulzrinne, "An Architecture for Location and Location Privacy in Internet Applications", BCP 160, RFC 6280, DOI 10.17487/RFC6280, July 2011, . [RFC6772] Schulzrinne, H., Ed., Tschofenig, H., Ed., Cuellar, J., Polk, J., Morris, J., and M. Thomson, "Geolocation Policy: A Document Format for Expressing Privacy Preferences for Location Information", RFC 6772, DOI 10.17487/RFC6772, January 2013, . [RFC8805] Kline, E., Duleba, K., Szamonek, Z., Moser, S., and W. Kumari, "A Format for Self-Published IP Geolocation Feeds", RFC 8805, DOI 10.17487/RFC8805, August 2020, . [RFC2009] Imielinski, T. and J. Navas, "GPS-Based Addressing and Routing", RFC 2009, DOI 10.17487/RFC2009, November 1996, . [RFC5870] Mayrhofer, A. and C. Spanring, "A Uniform Resource Identifier for Geographic Locations ('geo' URI)", RFC 5870, DOI 10.17487/RFC5870, June 2010, . [RFC6442] Polk, J., Rosen, B., and J. Peterson, "Location Conveyance for the Session Initiation Protocol", RFC 6442, DOI 10.17487/RFC6442, December 2011, . [RFC9179] Hopps, C., "A YANG Grouping for Geographic Locations", RFC 9179, DOI 10.17487/RFC9179, February 2022, . [RFC9632] Bush, R., Candela, M., Kumari, W., and R. Housley, "Finding and Using Geofeed Data", RFC 9632, DOI 10.17487/RFC9632, August 2024, . [ETSI-220] ETSI, "ETSI EN 300 220-1 V3.1.1: Short Range Devices (SRD); Radio equipment 25 MHz to 1000 MHz", See ETSI Standard, 2017, 2017. Hanley Expires 23 April 2027 [Page 121] Internet-Draft RSDGGS October 2026 [FCC-15] Federal Communications Commission, "Code of Federal Regulations, Title 47, Part 15", See FCC, current edition. [ARIB-T108] Association of Radio Industries and Businesses (ARIB), "920 MHz-Band Telemeter, Telecontrol and Data Transmission Radio Equipment", See ARIB STD-T108, 2012, 2012. [GPSR] Karp, B. and H.T. Kung, "GPSR: Greedy Perimeter Stateless Routing for Wireless Networks", See ACM MobiCom 2000, August 2000, 2000. [IEEE802154a] IEEE, "IEEE Std 802.15.4a-2007: Low-Rate Wireless Networks Amendment 1: Enhanced UWB PHYs", See IEEE, 2007, 2007. [IEEE802154z] IEEE, "IEEE Std 802.15.4z-2020: Low-Rate Wireless Networks Amendment 1: Enhanced UWB PHYs", See IEEE, 2020, 2020. [OLC] Sheppard, D., "Open Location Code: A Modest Proposal for Encoding Location Using Short Alphanumeric Codes", See Google Research, 2015, 2015. [RFC6890] Cotton, M., Vegoda, L., Bonica, R., Ed., and B. Haberman, "Special-Purpose IP Address Registries", BCP 153, RFC 6890, DOI 10.17487/RFC6890, April 2013, . [S2] Google LLC, "S2 Geometry Library", See https://s2geometry.io, 2011, 2011. [RFC8628] Denniss, W., Bradley, J., Jones, M., and H. Tschofenig, "OAuth 2.0 Device Authorization Grant", RFC 8628, DOI 10.17487/RFC8628, August 2019, . Author's Address James Patrick Hanley Myelin Networks LLC Email: James.Hanley@DGtlRift.com Hanley Expires 23 April 2027 [Page 122]