Network Earth Position Protocol (NEPP)
Earth Date Synchronization and Location-Local Solar Phase
draft-iwata-nepp-02
Intended status: Experimental
Kenichi Iwata, Tottori University
31 August 2026
Status of This Memo
This is an author working draft for discussion, not an Internet-Draft submitted to the IETF. It is not an Internet Standard. The Version 2 layout, field codes, and astronomical profile below are proposed and have not been implemented or independently validated. Publication does not assert interoperability.
The English edition is authoritative. The Japanese edition is for reference.
Draft revision -02, protocol Version 2, and application version 0.0.2 are
independent identifiers. Revisions -00 and -01 remain historical documents.
This revision contains the complete proposed NEPP specification for both V1 and V2. Earlier revisions are not prerequisites. References to external astronomical standards remain necessary; unresolved realization details are identified here rather than delegated to an earlier NEPP draft.
Abstract
NEPP synchronizes Earth Date (ED), a continuous calendar coordinate based on apparent geocentric solar longitude. This revision proposes a Version 2 exchange that also supplies a reference solar phase and its local rate. A client combines the reference phase with a locally selected longitude to describe the daily solar cycle without sending its location to the server.
The design separates a globally shared instant from a place-dependent daily phase. It does not redefine apparent solar time, replace atomic timekeeping, or prescribe civil time zones. Version 1 remains available to existing clients.
1. Changes and Scope
Compared with -01, this revision:
- retains the Earth Date definition and Version 1 exchange;
- proposes Version 2 with solar phase, validity, quality, and request correlation;
- specifies version dispatch and fallback independently of packet-layout reuse;
- defines a longitude-only, model solar phase and its observational limitations;
- distinguishes Earth Date quality from solar phase availability;
- documents related work, privacy, downgrade risks, and unresolved validation work.
The wire format distributes instantaneous state, not a service for sending GPS coordinates or scheduling appointments. Sunrise, sunset, solar altitude, maps, time-zone conversion, and authentication framing are outside this revision.
2. Requirements Language
The capitalized key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL are interpreted as in BCP 14 (RFC 2119 and RFC 8174). In this working draft, these words specify the proposed protocol, not capabilities of deployed code.
3. Two Coordinates, Two Purposes
3.1. Earth Date and Earth Year
Earth Date is:
lambda is apparent geocentric solar longitude in the adopted NEPP astronomical
profile, normalized to [0, 360) degrees. Earth Year Y begins at its March
equinox crossing and uses the Gregorian year containing that crossing as its
integer label. Before that crossing, the previous Earth Year applies.
The orbital fraction is angular, not an elapsed fraction of a fixed-length year. Quarter-turn seasonal markers are associated with equinoxes and solstices; their physical-time intervals are unequal. Seasons experienced locally also depend on hemisphere, latitude, and climate.
Solar phase is a separate, cyclic coordinate. ED is the same for all observers of the same instant and model; local phase depends on the selected longitude. ED alone does not supply a rotation angle by taking its fractional part.
Neither a constant number of days per Earth Year nor a constant number of SI seconds per solar-phase turn is defined. SI seconds remain the units of network delay, oscillator elapsed time, and local interpolation rates.
3.2. Earth Date Astronomical Profile 1
ED Model ID 1 identifies the experimental NEPP Astronomical Profile 1 in both
versions. Its definition uses the apparent direction of the Sun as seen from
the center of the Earth, not the direction at a particular observing site.
The adopted reference geometry uses the IAU definition of the ecliptic,
IAU 2006 precession, IAU 2000A nutation, and transformations consistent with
the IERS Conventions. Longitude increases in the direction of apparent annual
solar motion from the March-equinox direction and is normalized to [0, 360).
A Profile 1 realization SHALL:
- Obtain Earth and Sun states from a high-precision solar-system ephemeris at an identified epoch in the time scale required by that ephemeris.
- Determine the geocentric solar direction, including light-time, aberration, and other apparent-place corrections required by the adopted models.
- Apply consistent precession/nutation and reference-frame transformations.
- Construct the applicable ecliptic plane and equinox origin, project the apparent direction onto that plane, and compute the oriented longitude.
- Determine the Earth Year from the March-equinox crossing, and encode ED using Section 4.2 rather than an elapsed fraction of a civil year.
- Evaluate and report a local ED rate and an uncertainty appropriate to the ephemeris, transformations, timestamping, and prediction being used.
A constant circular-orbit model or an uncorrected two-body Keplerian ellipse MUST NOT be substituted for the normative astronomical definition. SOFA-consistent algorithms are RECOMMENDED reference tools, not a required programming language. Different ephemerides may implement the profile only if their differences fit the reported uncertainty; sharing a Model ID alone does not demonstrate agreement.
The exact pinned ephemeris, ecliptic/equinox realization, numerical procedure,
and independently checked accuracy remain open work in Section 13. This is an
explicit incompleteness of the experimental profile, not a reference to missing
rules in -01. Implementations MUST identify their realization in documentation
and MUST NOT claim validated astronomical interoperability on the identifier alone.
3.3. Time Scales and Earth Date Rate
Physical elapsed time is measured in SI seconds. TT/TDB and other time scales are used where required by the astronomical algorithms; UTC may supply the input epoch after appropriate conversion. Earth Date has no leap-day or leap-second insertion of its own, but a realization using UTC MUST correctly handle UTC leap seconds and MUST NOT introduce an artificial ED discontinuity.
The local rate is R = dED/dt in ED per SI second. It supports interpolation
and delay estimation; it does not define ED. Rate estimates crossing a March
equinox MUST use continuous full ED values rather than a wrapped fraction.
Long-range prediction requires an astronomical model, not indefinite linear
extrapolation. The local-linear synchronization approximation and holdover
behavior are specified in Section 8.
4. Version 1 Specification
This section specifies V1 independently of previous revisions. V2's token, 128-octet length, zero-padding rules, and solar fields MUST NOT be required of V1 clients. The V1 packet format and field meanings remain unchanged.
4.1. Base Layout and Version Dispatch
All integers are big endian; signed integers use two's complement.
The common Flags octet is Status:2 | Version:3 | Mode:3, most significant
bits first. Version is extracted as (flags >> 3) & 7.
| Offset | Octets | Field |
|---|---|---|
| 0 | 1 | Flags |
| 1 | 1 | Stratum |
| 2 | 1 | Poll (signed) |
| 3 | 1 | Precision (signed) |
| 4 | 4 | Root Delay |
| 8 | 4 | Root Dispersion |
| 12 | 4 | Reference ID |
| 16 | 12 | Reference Earth Date |
| 28 | 12 | Origin Earth Date |
| 40 | 12 | Receive Earth Date |
| 52 | 12 | Transmit Earth Date |
| 64 | 8 | Earth Date Rate |
| 72 | 4 | Model ID |
A V1 base packet is 76 octets with Version 1. A datagram shorter than 76 octets is invalid. Additional octets are extension data, not V2 fields. No extension type/length framing or critical-extension mechanism is defined by this document. A base-only V1 implementation ignores the trailing data and emits a 76-octet base response; it MUST NOT interpret a trailer as authentication or solar state. An extension-aware implementation needs a separately specified extension agreement. This draft does not make such an agreement a V1 prerequisite.
4.2. Timestamp and Rate Encoding
A timestamp is signed 32-bit Earth Year followed by unsigned 64-bit fraction
U = floor(F * 2^64). Decode as Y + U / 2^64. All-zero timestamps mean absent
where permitted, not a trustworthy synchronization epoch. Differences MUST be
computed as complete ED values, including crossings of an Earth Year boundary.
Earth Date Rate is signed 64-bit round(R * 2^63), decoded as ED per SI second.
Status values are 0 synchronized, 1 degraded, 2 holdover, and 3 unsynchronized;
they are not NTP leap indicators. Client Mode is 3 and Server Mode is 4.
Stratum 0 denotes a reference source, 1 a primary server, 2 through 15 secondary
servers, and 16 unsynchronized; 17 through 255 are reserved. A network source
used for synchronization has Stratum 1 through 15.
Poll recommends an interval of 2^Poll SI seconds. Precision describes nominal
ED resolution 2^Precision, not guaranteed accuracy. Root Delay and Root
Dispersion are unsigned 16.16 SI seconds representing accumulated round-trip
delay and synchronization uncertainty, respectively. Reference ID identifies a
source; Model ID identifies the ED astronomical profile defined in Section 3.2.
4.3. Field Semantics
Status 0 indicates a synchronized ED source; 1 indicates degraded astronomical source quality; 2 indicates prediction-only or holdover operation; 3 means ED is unsynchronized and MUST NOT be used for synchronization. Clients may reject degraded or holdover sources according to their quality policy.
Mode codes are 0 reserved, 1 symmetric active, 2 symmetric passive, 3 client, 4 server, 5 broadcast, and 6/7 reserved. Only client/server operation is specified here. A basic implementation MUST support 3/4 and MUST NOT infer a working symmetric or broadcast protocol from the other assigned names.
A primary server computes ED from astronomical reference data; secondary servers derive it through upstream NEPP servers. Stratum is logical source distance, not an accuracy or authenticity guarantee. Sources at Stratum 0 include ephemerides and astronomical calculation systems, not ordinary network servers.
Poll and Precision cover signed 8-bit values -128..127. Poll 6 recommends
64 SI seconds. Clients MUST bound actual polling and resource use by local policy
rather than blindly exponentiating an untrusted recommendation.
For Root Delay or Root Dispersion, an unsigned wire integer W represents
W / 65536 SI seconds. The range is 0 through 65535 + 65535/65536 seconds.
Root Delay estimates accumulated round-trip communication delay to the reference;
Root Dispersion is an upper estimate of accumulated synchronization uncertainty.
Astronomical uncertainty MUST be included in Root Dispersion or a separately
specified extension understood by the client. In the base-only exchange it
belongs in Root Dispersion. Zero MUST NOT be treated as a special unknown marker.
An unrepresentable uncertainty cannot be claimed as a finite accurate bound;
the source must be treated as unusable for synchronization.
Reference ID is a 32-bit source identifier. At Stratum 1 it identifies a source or profile; at secondary strata it can identify an upstream source and help detect loops. There is no global registry defined here. It is not necessarily an IPv4 address, and an ASCII label does not prove traceability. ED Model ID is an unsigned 32-bit profile identifier; 1 has the definition in Section 3.2. An unknown model cannot safely be assumed equivalent to Profile 1.
4.4. V1 Request and Response
The four exchange events are client transmit E1, server receive E2, server transmit E3, and client destination E4. E4 is recorded locally, not transmitted. A client sends Version 1, Mode 3, Transmit = E1, and zero Origin and Receive. Reference is implementation-defined or zero. An unsynchronized/bootstrap client uses Status 3 and Stratum 16 and MAY set E1 to zero when no ED estimate exists. Client poll/precision describe its policy; response-only information may be zero. V1 has no random Request Token and MUST NOT acquire V2's extra request checks.
A server records E2 upon receipt, copies request Transmit bytes into response Origin, and records E3 as near transmission as practical. The response uses Version 1, Mode 4, its own status/stratum/source/quality information, Receive = E2, Transmit = E3, and a local ED rate. Reference denotes the reference ED state used for synchronization, or zero if not supplied. The server SHOULD evaluate or propagate the ED rate to the response transmit epoch. A base-only response is 76 octets, even if the request included ignored extension data.
The client records E4 from its ED clock on receipt. Normal exchanges use Section 8.1. Bootstrap with no E1/E4 uses the ED-only parts of Section 8.2; no solar terms exist in V1. A zero Origin can correlate a zero-E1 request but provides little protection against forged or replayed responses. Implementations MUST NOT invent solar state from a V1 response.
4.5. V1 Acceptance, Errors, and Minimum Implementation
A V1 client MUST NOT synchronize from an unsupported Version, non-server Mode, unsynchronized Status, Origin different from the sent E1, malformed timestamp, packet shorter than 76 octets, prohibited reserved value, or Root Dispersion above its acceptance threshold. Clients MUST validate the request/response Origin association; they SHOULD also match the selected network endpoint, discard duplicates, and reject implausible timing or source information. No V2 token check, V2 exact-length check, or V2 solar check applies.
Servers silently discard malformed packets, unsupported versions, and modes they do not implement. A response from the wrong version is not version negotiation. Transport is the UDP request/response service in Sections 7.1 and 11; a basic V1 exchange does not require continuous connectivity.
A basic V1 server implements Profile 1 ED calculation, E2/E3 timestamping, ED rate, stratum, delay, and dispersion. A basic synchronizing V1 client implements E1/E4 capture when available, Origin validation, offset estimation, clock discipline, and holdover. A bootstrap-only display is a limited client, not evidence of full synchronization accuracy. Quality and source-selection behavior for either version is described in Section 8.4. Existing implementation gaps are not repaired merely by publishing this specification.
5. Reference and Local Solar Phase
5.1. Definition
Define frac(x) = x - floor(x), including for negative inputs. For the proposed
Solar Model 1, let alpha_app(t) be the apparent geocentric solar right ascension
in the true equator/equinox-of-date system, and let GAST(t) be Greenwich apparent
sidereal time in the matching system. Express both as angles in radians.
H_G(t) = GAST(t) - alpha_app(t)
P_G(t) = frac(0.5 + H_G(t) / (2*pi))
P_L(t, L) = frac(P_G(t) + L / 360 degrees)
L is east-positive longitude relative to the Greenwich reference meridian;
west longitude is negative. A client SHOULD normalize it to [-180, 180) degrees.
The reference meridian is the adopted coordinate origin, not a civil time zone
or a claim about a particular historical physical meridian marker.
The resulting P_L is in [0, 1). At model upper meridian transit it is 0.5
(local model apparent noon); at lower transit it wraps from almost 1 to 0.
This is apparent solar time expressed in turns, using the hour-angle definition
described by USNO, not a newly discovered
astronomical time scale.
GAST MUST NOT be replaced by Earth Rotation Angle while retaining equinox-based right ascension. A CIO-based alternative must transform both quantities consistently. Units, reference origin, and sign conventions MUST agree.
5.2. Scope of the Longitude-Only Model
Solar Model 1 is an idealized geocentric, longitude-only apparent solar phase. Clients normally obtain geodetic longitude from the device's location service (commonly WGS 84), or use a manually selected longitude. The longitude is applied directly by the formula above. Observer-specific polar-motion corrections, topocentric parallax, local vertical deflection, elevation, and atmospheric refraction are not applied to this phase model.
Consequently 0.5 denotes model transit, not a guarantee of an exact observed
solar culmination at every site. Full terrestrial-to-celestial transformations
involve polar motion as described in the
IERS Conventions, Chapter 5.
A model requiring those corrections may need latitude and additional state and
is not silently interchangeable with this longitude-only model.
Neither 0.25 nor 0.75 is defined as sunrise or sunset. Determining daylight
also needs latitude, solar declination, and horizon assumptions. A phase value
does not prove that the Sun is above the horizon, including in polar regions.
At a geographic pole, location-derived longitude has no unique physical meaning;
a client MUST use an explicitly selected reference longitude or mark local phase
unavailable rather than suggest a uniquely determined local noon.
5.3. Astronomy and Earth Orientation
The proposed Solar Model ID 1 uses apparent geocentric solar direction, IAU 2006 precession, IAU 2000A nutation, and a matching GAST computation. It is a separate identifier namespace from the ED Model ID, even when both identifiers equal 1. It remains provisional pending a pinned realization and independent vectors.
The server derives UT1 using UT1-UTC from an IERS Earth orientation product.
UT1 governs Earth rotation; TT and, as needed, TDB are used for the astronomical
calculations appropriate to each algorithm. UT1-UTC is a time-scale offset in
seconds, not a phase offset. It MUST NOT be added directly to P_G.
IERS Bulletin A products provide rapid determinations and predictions. A current result may rely on a prediction, not a final observation of the current instant. Interpolation MUST respect UTC leap-second boundaries; naïvely interpolating through a jump in UT1-UTC is invalid. Unknown correction data MUST NOT silently mean UT1 = UTC.
Servers SHOULD cache ephemeris and Earth orientation data, refresh it outside the packet-processing path, and retain provenance and error estimates. A failed download does not invalidate still-usable cached data, but MUST NOT reset its age or extend the source's supported prediction horizon. Authenticated retrieval and atomic cache replacement are RECOMMENDED. SOFA's time-scale and astronomy guidance is relevant.
Implementations MUST disclose their ephemeris, software/model release, EOP product and release, interpolation method, coverage, and uncertainty policy in operational documentation. The packet carries a compact quality summary, not the full provenance record. No particular Python package is normative.
5.4. Rate and Common Epoch
Let Q = d(unwrapped P_G)/dt, in turns per SI second. A numerical derivative
MUST unwrap phase around 0/1 before differencing. A fixed 1/86400 is a useful
rough magnitude, not the normative rate.
Reference phase P_G, phase rate Q, ED E3, and ED rate R in an accepted
V2 response MUST refer to the same server transmit instant t3. Servers MAY
interpolate cached astronomical state to t3 within their advertised bounds.
Combining ED from one instant with phase from another without propagating both
to a common epoch is invalid.
6. Version 2 Packet Proposal
V2 uses exactly 128 octets for both request and response, on the same configured UDP endpoint as V1. It reuses offsets 0 through 75 from Section 4, except that the Version bits equal 2. This reuse simplifies implementation, but a V2 packet MUST NOT be parsed as V1. The following fields complete the V2 packet:
| Offset | Octets | Field | Encoding |
|---|---|---|---|
| 76 | 16 | Request Token | Opaque random octets, echoed |
| 92 | 1 | Solar Status | Unsigned enumeration |
| 93 | 3 | Reserved | Zero |
| 96 | 8 | Reference Solar Phase | Unsigned fraction, units 2^-64 turns |
| 104 | 8 | Solar Phase Rate | Signed integer, units 2^-63 turns/s |
| 112 | 4 | Solar Uncertainty | Unsigned fraction, units 2^-32 turns |
| 116 | 4 | Solar Validity | Unsigned whole SI seconds from t3 |
| 120 | 4 | EOP Data Age | Unsigned whole SI seconds, or unknown |
| 124 | 4 | Solar Model ID | Unsigned model identifier |
All multi-octet integers use network byte order. V2 in this proposal has no extension trailer: shorter or longer datagrams MUST be rejected as V2. Reserved octets MUST be sent as zero and nonzero values MUST cause V2 packet rejection. Future format changes require an explicit specification, not heuristic parsing.
6.1. Request Token
A client MUST generate a fresh, nonzero 128-bit token using a cryptographically secure random generator for each new request, including retries. A server MUST echo it byte-for-byte. Clients MUST accept it only for the matching outstanding request and consume it after one response. The token is useful even during bootstrap when E1 is absent. It does not authenticate the server or defeat an on-path adversary. Tokens MUST NOT contain stable device identifiers.
6.2. Phase and Rate Encoding
Encode reference phase as floor(P_G * 2^64) and decode by dividing by 2^64.
Zero is a valid phase, not a missing-value marker. Availability is determined
by Solar Status. Encode rate as round(Q * 2^63) and decode by multiplying by
2^-63; round-to-nearest, ties-to-even is used for this new field. A usable
Solar Model 1 rate MUST be positive. Encoders MUST reject overflow rather than
wrap it; clients SHOULD enforce model-appropriate sanity limits.
The fine fixed-point resolution is not a claim of equivalent physical accuracy. Phase differences use circular arithmetic; rates use an unwrapped phase.
6.3. Independent Solar Status
| Value | Meaning |
|---|---|
| 0 | Unavailable; no usable solar state |
| 1 | Evaluated using observed/final or rapid EOP values over the validity interval |
| 2 | At least part of the validity interval uses published EOP predictions |
| 3 | Holdover/extrapolation beyond the source's supplied coverage, with an explicit bound |
| 4–255 | Reserved |
The classification covers all data supporting the phase, derivative, and advertised validity interval; the least favorable applicable class is used. An observed bracket combined with a predicted bracket is class 2, not class 1. Class 3 MUST NOT be used without a justified extrapolation error bound.
The Flags Status and Stratum describe the ED service. Solar Status is independent: an ED-synchronized server may return Solar Status 0. Failure of solar data alone MUST NOT force a switch to V1 or discard otherwise usable ED.
For Solar Status 0, phase, rate, uncertainty, validity, and Solar Model ID MUST
be zero; EOP Data Age MUST be 0xffffffff (unknown). Clients MUST NOT display
these zero phase bytes as solar midnight. Unknown Solar Status or Solar Model
ID makes the solar block unusable but need not invalidate a valid ED exchange.
6.4. Uncertainty, Validity, and Age
Solar Uncertainty encodes ceil(B * 2^32), where B is a conservative estimate
of the maximum circular phase error throughout the validity interval when
using the transmitted phase and linear rate. It includes astronomical model,
EOP prediction, computation, quantization, server epoch error, and interpolation
errors relative to the defined model. It is not a statistical confidence level.
It excludes client longitude error and client/network propagation error.
Physical effects intentionally outside Solar Model 1 are also outside this bound.
0xffffffff means unknown uncertainty. For a usable solar block, the encoded
bound MUST be less than 0x80000000 (half a turn), and Solar Validity MUST be
between 1 and 3600 seconds inclusive. The actual interval SHOULD be short
(for example 60 seconds) unless an error analysis supports a longer interval.
A server unable to provide such a bound and interval MUST send Solar Status 0.
Solar Validity is the interval 0 <= t - t3 <= V, not a freshness duration
starting at receipt. A client MUST account for estimated packet age and timing
uncertainty, and stop presenting the state as valid once that bound can exceed V.
Outside it, clients MAY show explicitly stale information or a separately
identified local prediction, but MUST NOT extend the server's validity claim.
EOP Data Age is the ceiling of elapsed SI seconds from the publication epoch
of the EOP product used to t3. For multiple products, use the oldest relevant
publication. 0xffffffff means unknown or unrepresentable age. Download time
MUST NOT substitute for publication time. Age is descriptive, not a guarantee
of accuracy: a recent product may contain predictions and an older product may
contain good historical observations. Clients MAY reject solar state based on
their own age, quality, and uncertainty limits.
7. Requests, Responses, and Validation
7.1. Version Dispatch and Amplification
A dual-version server MUST inspect the Version bits before choosing a parser. An empty datagram, unsupported version, malformed request, or unsupported mode is silently discarded. This proposal defines no version-negotiation error packet.
For V1 requests, return the unchanged V1 response. For V2 requests, return V2, including when solar state is unavailable. A server MUST NOT send V2 in response to V1. V1 clients are not expected to understand V2.
A V2 request MUST be 128 octets; a 76-octet packet with its Version bits changed to 2 is not a valid V2 request. Each accepted unicast request elicits at most one response, whose UDP payload MUST NOT exceed the request payload. Rate limits, bounded caches, and bounded per-request computation are REQUIRED. Equal-sized payloads reduce amplification but do not eliminate spoofed-source reflection.
7.2. V2 Client Request
Set Flags to Status 3, Version 2, Mode 3 (0xd3), Stratum to 16, Poll to a
locally chosen value (6 by default), and Precision to 0. Set E1 in Transmit
Earth Date if available; otherwise use twelve zero octets for bootstrap.
Set a fresh Request Token. All other request fields MUST be zero. Servers
MUST reject a V2 request not following these rules.
Record a local monotonic send instant m1. The server records receive ED E2,
copies request Transmit into response Origin unchanged, and evaluates transmit
ED E3, R, and solar state at t3. The response carries the server's ED
status, stratum, source information, Poll recommendation, and Precision.
Reference ED identifies the last successful reference update, or zero if absent.
The response token is copied from the request. Reserved bytes remain zero.
7.3. Client Acceptance
Record monotonic receive instant m4 and destination ED E4, if available.
Before using a V2 response, a client MUST check:
- exact length 128, Version 2, Server Mode 4, and zero Reserved bytes;
- source IP address and UDP port match the selected request endpoint;
- token matches an unconsumed outstanding V2 request;
- Origin matches the request Transmit bytes, including a bootstrap zero;
- Flags Status is not 3, Stratum is 1 through 15, and ED Model ID is supported;
- E2 and E3 are present, R is positive, and timing/dispersion values meet policy.
Solar Status, Solar Model ID, positive Q, uncertainty, and validity are then checked separately. A malformed or unsupported solar block MUST NOT be used as phase state; clients MAY retain the validated ED portion. Unknown solar support is not evidence that the server lacks V2.
Model disagreement, excessive delay, or implausible changes SHOULD cause sample rejection. Advertised precision and stratum are not evidence of trust.
8. Synchronization and Display
8.1. Four-Coordinate ED Synchronization
Where ED rates are locally compatible over the exchange:
Positive theta means the client is behind. Conversion of delta_ED into SI seconds uses the applicable local ED rate, not a universal year length. Clients requiring better accuracy MUST use a common physical-time mapping or a higher order model. These estimates inherit the delay-asymmetry limitation of NTP-style exchanges; they are not exact one-way delay measurements.
8.2. Bootstrap and a Common Local Anchor
With absent E1/E4, the client MUST NOT insert zero into the four-coordinate formula as though it were a valid ED epoch. A limited bootstrap estimate can use:
d_total = m4 - m1
d_server ~= (E3 - E2) / R
d_path = d_total - d_server
d_oneway_estimate = d_path / 2
ED_at_receive ~= E3 + R * d_oneway_estimate
P_G_at_receive ~= frac(P_G_at_transmit + Q * d_oneway_estimate)
This approximation requires a stable monotonic oscillator, locally valid R/Q, and nonnegative delays within measurement uncertainty. Inconsistent samples MUST be rejected; small negative residuals may only be clamped within a stated measurement tolerance. One-half path delay is a symmetry assumption. A client MUST allow for asymmetry; the full nonnegative path delay plus measurement uncertainty provides a conservative transit-age upper estimate, not half alone.
Use the same elapsed-time anchor for ED and phase. If elapsed monotonic time
since receipt is u, advance each using its own rate. For the local display:
Changing longitude changes the local display, not ED or the server state.
Server validity requires the upper estimate of age since t3, including u,
to remain within Solar Validity. Clients add timing uncertainty multiplied by
the phase rate and longitude uncertainty divided by 360 degrees to the phase
error budget. Time corrections, sleep/resume, or oscillator discontinuities
require re-evaluation or a fresh sample. A wall-clock step MUST NOT be interpreted
as a physical elapsed interval.
8.3. Presentation and Appointments
Clients SHOULD distinguish ED synchronization, solar quality, selected location, and stale state. A manual reference location MUST be labeled as such. Location permission denial need not disable ED. A circular display naturally represents the 1-to-0 wrap; an application MUST NOT call that normal wrap a clock fault.
A bare local phase does not uniquely identify an instant: it recurs every solar cycle. An appointment requires a place/reference longitude and an identified occurrence, such as an ED search interval. Conversion to a future ED requires an astronomical prediction; a current packet's short validity interval is not a long-range scheduling guarantee. Selecting Shibuya rather than the current GPS location is a client choice, not a new protocol time zone.
8.4. ED Holdover, Clock Discipline, and Multiple Sources
For either protocol version, an ED client may retain the last synchronized
anchor (ED0, R0) and use ED ~= ED0 + R0 * delta_t over a short interval.
For longer intervals it SHOULD use a justified higher-order model, such as
ED0 + R0*delta_t + 0.5*A0*delta_t^2, or an astronomical prediction. Here
A0 = dR/dt; it is not transmitted by either base packet in this draft.
Clients MUST NOT require continuous connectivity, but MUST distinguish a new synchronized measurement from prediction/holdover. They SHOULD track growth of uncertainty and stop claiming usable synchronization when local quality limits are exceeded. V1 has no explicit validity field: absence of that field is not permission to extrapolate forever. V2 Solar Validity limits solar state only and does not define an ED holdover lifetime.
Repeated exchanges SHOULD discipline the ED clock. Small corrections normally should be smoothed; large corrections may require a step and re-establishment of the common local anchor. Under normal operation a live ED display SHOULD not move backward. A deliberate correction must not be hidden by reporting a false accuracy. Phase wrapping and location changes are distinct from ED steps.
Higher-reliability clients SHOULD use independent sources. Selection may consider stratum, root delay/dispersion, measured delay, historical stability, model ID, astronomical provenance, and source independence. Different hostnames do not necessarily mean independent models or observations. A materially inconsistent source SHOULD be excluded unless the discrepancy fits explained uncertainty or model differences. Multiple unauthenticated sources do not by themselves create cryptographic trust; synchronization loops and shared source failures remain risks.
9. Version Compatibility and Fallback
| Client | Server | Result |
|---|---|---|
| V1 | V1 | Existing ED exchange |
| V1 | Dual V1/V2 | Unchanged V1 ED exchange |
| V2-capable | Dual V1/V2 | V2 ED and solar state, or ED with solar unavailable |
| V2-capable | V1 | V2 unanswered; explicit V1 request supplies ED only |
A V2 client SHOULD first try V2. A RECOMMENDED initial timeout is two seconds, followed by a separate V1 request if availability policy permits. A timeout means no usable V2 response arrived; it does not prove lack of support. A V1 packet arriving in reply to a V2 attempt MUST NOT be accepted as a downgrade. Fallback uses a separately tracked V1 transaction with the rules in Section 4.
Clients SHOULD avoid probing V2 on every V1 poll; a suggested retry interval is 15 minutes with jitter, or after a network/server change. Version preferences are cached per endpoint with a bounded lifetime, not permanently by hostname. Clients MAY require V2 and decline fallback. Failure of a solar block within a valid V2 response is not a reason to downgrade.
Dropping V2 traffic can force an availability-oriented client toward V1. This is an unauthenticated downgrade risk and MUST be documented. Neither version provides integrity simply because a successful response was received.
10. Related Work and Design Rationale
10.1. UTC, TAI, and UT1
UTC/TAI provide atomic-time foundations; UT1 represents Earth rotation. NEPP distributes an astronomical coordinate rather than replacing these inputs. Its independence from a fixed seconds-per-year definition is not independence from time metrology in a realization. See BIPM Time Metrology.
10.2. NTP and PTP
NTPv4 provides the direct precedent for four-event offset/delay estimates, polling, strata, and clock discipline. NEPP adapts that pattern to a nonuniform ED coordinate and transmits rates. Its 96-bit timestamps and flags are not wire-compatible with NTP, and it MUST NOT use the NTP service port as if it were NTP.
IEEE 1588/PTP coordinates clocks within a time-distribution system. NEPP does not claim to match PTP accuracy, implement its mechanisms, or make a high-quality underlying clock unnecessary. NTP/PTP can support the host clock used for astronomical evaluation; ED and solar phase describe what coordinates are then distributed.
10.3. Unix Time and Julian Date
POSIX seconds since the Epoch and Julian Date already express dates numerically. NEPP does not claim novelty merely for replacing a calendar string with a number. Julian Date is a day count with a fractional part; precise use requires identifying the underlying time scale. ED instead assigns its fraction to solar longitude, preserving orbital phase rather than uniform elapsed time.
10.4. Decimal Time and Swatch Internet Time
Decimal subdivision alone is not a new contribution. A display in tenths or thousandths can be applied to many time conventions without changing their physical definition. Swatch Internet Time divides a conventional 24-hour day into 1000 beats referenced to Biel Mean Time. NEPP's local solar phase instead depends continuously on selected longitude and apparent solar motion. It is not a fixed civil day rescaled into decimal units.
10.5. Mean and Apparent Solar Time; Civil Time Zones
Mean solar time regularizes solar motion; apparent solar time follows the Sun's hour angle. Their difference includes the equation of time. The proposed phase is a normalized expression of the latter, not UTC plus longitude alone. The astronomical distinction is described by USNO.
Civil zones provide useful shared schedules at the cost of differences from local solar time. NEPP neither assigns civil authority nor requires abolishing zones. It separates global instant exchange from local daily context. The contribution proposed here is the combination of ED synchronization, explicit reference phase/rate/quality, and private client-side localization, not the invention of solar time or proof that society should adopt it.
11. Security, Privacy, and Operations
Both versions in this draft are unauthenticated. Spoofing, replay, malicious source selection, delay manipulation, false uncertainty, and denial of service remain possible. V2's random token improves off-path correlation but is not a MAC, signature, or source authentication mechanism. V1's Origin correlation is particularly weak during zero-timestamp bootstrap. These limitations MUST NOT be described as secure synchronization.
Network Time Security is a relevant NTP security precedent, not a protocol automatically usable with NEPP packets. Authenticated NEPP framing and downgrade protection require separate design. High-integrity uses need an appropriate authenticated, reviewed mechanism.
Requests contain no latitude, longitude, place name, or persistent user ID. Clients MUST NOT encode location in the token or reserved/request padding. Location services and manual-place storage remain client-side. The server still sees source IP addresses and query times; it MUST NOT claim network anonymity. Operators SHOULD minimize retained logs and bound transient rate-limit state.
Servers SHOULD perform version/length checks and rate limiting before expensive
astronomy. EOP retrieval SHOULD be scheduled independently, with an explicit
failure policy. Unavailability of solar data must not unnecessarily interrupt
the established V1 ED service. Transport uses a configurable experimental
dynamic/private UDP port; 56377 is a deployment choice, not an IANA assignment.
12. Encoding Examples and Validation Plan
The following are synthetic arithmetic examples, not astronomical predictions:
| Quantity | Input | Expected result |
|---|---|---|
| V2 bootstrap flags | Status 3, Version 2, Mode 3 | d3 |
| V2 synchronized server flags | Status 0, Version 2, Mode 4 | 14 |
| Reference phase wire | P_G = 0.5 |
80 00 00 00 00 00 00 00 |
| Reference phase wire | P_G = 0.25 |
40 00 00 00 00 00 00 00 |
| Local phase | P_G = 0.9, L = +90 degrees |
0.15 |
| Local phase | P_G = 0.1, L = -90 degrees |
0.85 |
| Exact rate test | Q = 2^-16 turns/s |
signed integer 2^47 |
| Exact uncertainty test | B = 2^-20 turns |
unsigned integer 4096 |
A synthetic 128-octet bootstrap request has byte 0 = d3, byte 1 = 10,
byte 2 = 06, token bytes 76 through 91 = 01 02 ... 10, and all other bytes
zero. That fixed token is for an encoding test only, never production randomness.
Required tests before deployment include:
- Exact field offsets, signedness, sizes, and short/oversized packet rejection.
- V1 regression: unchanged requests/responses and continued iOS 0.0.1 operation.
- Unknown version/mode, nonzero reserved bytes, wrong endpoint/token/Origin, duplicate and late replies, and equal request/response payload lengths.
- ED bootstrap without using absent coordinates in offset formulas; year wrap.
- Solar wrap in both longitude signs, derivative unwrapping, and shared epoch.
- Solar unavailable, reserved status, unsupported model, and ED-only operation.
- Expired validity including packet age, clock jumps, suspend/resume, EOP download failure, prediction boundaries, and leap-second-safe interpolation.
- All combinations in Section 9, including timeout that was caused by loss.
Astronomical vectors MUST identify epoch and time scale, UTC/TAI/UT1 conversion inputs, EOP product/version, ephemeris, celestial reference system, model/software version, GAST, apparent solar right ascension, ED/R, P_G/Q, longitude, and expected local phase with tolerances. Vectors MUST include noon, wrap, seasonal points, and observed/predicted transitions. Independent computation is REQUIRED before calling them normative interoperability vectors. None are supplied as validated astronomical vectors by this revision.
13. Implementation Status and Open Questions
The repository contains an experimental V1 Python server/client and iOS client; the author has reported successful public-server and TestFlight use of iOS 0.0.1. This is operational experience, not independent verification of the full astronomical profile. V2 and the proposed solar feature are not implemented. This draft alone changes neither the running server nor the app.
Before freezing V2, review:
- the 128-octet layout and quality/validity encodings;
- a reproducible ED Profile 1 realization, including reference geometry;
- pinned solar-model algorithms, supported epochs, and ephemeris versions;
- justified model/rate/clock uncertainty bounds and extrapolation limits;
- a client timing policy for bootstrap, asymmetry, and location error;
- whether a future higher-precision model should include polar motion;
- authentication, authenticated version negotiation, and registry policy.
The longitude-only simplification is deliberate and reviewable. An exact observational-noon claim or a numerical accuracy claim must wait for a model and error analysis that supports it.
14. IANA Considerations
This working revision requests no IANA action. Version 2 and Solar Model ID 1 are experimental proposal values, not IANA registrations. Future work may request a service port and registries for astronomical models and extensions.
15. References
15.1. Definition and Model References
- BCP 14: RFC 2119, RFC 8174.
- IERS Conventions (2010), Technical Note 36, including IAU 2006/2000A celestial models and time/rotation transformations.
- USNO: The Equation of Time, for the apparent solar time/hour-angle convention.
15.2. Informative and Operational References
-
NEPP revision -01, historical comparison only; not required to implement the specification in this document.
- IERS rapid service / Bulletin A products.
- BIPM Time Metrology.
- RFC 5905: NTPv4.
- RFC 8915: Network Time Security.
- NIST: IEEE 1588 Systems.
- POSIX: Seconds Since the Epoch.
- USNO: Julian Date.
- Swatch: Internet Time.
Author
Kenichi Iwata
Tottori University, Japan
Project: nepp.kenic.jp
Contact: support@kenic.jp