Regulatory Spectrum Discrete Global Grid System (RSDGGS)

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.¶

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)

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

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 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:¶

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)

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 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--------\

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).¶

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.¶

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.¶

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:¶

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.

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.¶

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:¶

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

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.¶

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.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)

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]

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.¶

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.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

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

7.3. CDDL Schema

The following CDDL [RFC8610] schema defines the wire format for RSDGGS-bearing messages:¶

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
}

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:¶

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
)

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.¶

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.¶

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.¶

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.¶

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.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.¶

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.¶

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.¶

9.4. 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.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:¶

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

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:¶

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.¶

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)

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.¶

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).

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

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

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
}

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.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.¶

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:¶

   1. Extract cell bytes.¶
   2. Perform database lookup: is the received channel legal for the cell's rule set?¶
   3. If legal: tentatively adopt rule set. Increment confidence counter.¶
   4. 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):¶

   1. Adopt rule set as operational regulatory context.¶
   2. Store RSDGGS cell in non-volatile memory.¶
   3. 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.¶

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.¶

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)

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.¶

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.¶

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

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

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.¶

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

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

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.¶

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.¶

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)

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.¶

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

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

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.¶

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.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:¶

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.

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.¶

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.¶

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

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:¶

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.1. Address Structure

An RSDGGS Geographic IPv6 address is structured as follows:¶

 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]    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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:¶

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.¶

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)

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.¶

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

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:¶

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.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.¶

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)

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.¶

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

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.¶

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.

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.¶

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)

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.¶

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

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.¶

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

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.¶

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)

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.¶

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

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.¶

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)

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.¶

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)

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):¶

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.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).¶

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 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.¶

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 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:¶

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.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.¶

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

18.2. Active Patents — Detailed Analysis

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

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

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

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.

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

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.4. Summary of Improvement Opportunities

The following table consolidates all actionable improvement opportunities identified from the cited patents and RFCs, categorized by implementation priority.¶

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:¶

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.¶

19.1. Crate Structure and Types

#![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];

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.¶

/// 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],
        [ 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],
        [-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;

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)
}

/// 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)
}

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.

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
}

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.
    // 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,
    }
}

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);
    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
}

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 }
}

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.¶

/// 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<f32>,  // 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
}

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.

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.¶