# Network Earth Position Protocol（NEPP）

## Earth Dateの同期と、場所に応じた太陽位相

### draft-iwata-nepp-02 日本語参考版

Intended status: Experimental  
Kenichi Iwata, Tottori University  
2026年8月31日

## この文書の位置づけ

**[英語版](draft-iwata-nepp-02.md)が正本です。この日本語版は参考資料であり、
内容・解釈に相違がある場合は英語版を優先してください。**

本書は著者による議論用の作業草案であり、IETFへ提出済みのInternet-Draftでも、
Internet Standardでもありません。以下のVersion 2パケット配置、符号値、天文
プロファイルは提案段階で、未実装・独立検証前です。相互運用性を保証しません。

草案改訂番号`-02`、プロトコルVersion 2、アプリ版`0.0.2`は別の番号です。
`-00`・`-01`は過去版として保存します。

本版はV1・V2両方の提案仕様を収録し、旧版を読むことを前提にしません。
外部の天文標準への参照は残りますが、未決の実現手順は本書内の未決事項として
明示し、旧NEPP草案へ委ねません。

## 概要

NEPPは、地心視太陽黄経に基づく連続的な暦座標Earth Date（ED）を同期します。
本版は、基準太陽位相とその局所的な変化率も配信するVersion 2を提案します。
クライアントは、位置をサーバーに送ることなく、基準位相に手元の経度を加えて
その場所の太陽の日周運動を表現します。

地球共通の瞬間と場所に依存する日内位相を分離する設計です。視太陽時を新しく
発明するものでも、原子時の基盤や民用タイムゾーンを置き換える規定でもありません。
既存クライアントのため、Version 1も引き続き提供します。

## 1. 変更点と範囲

`-01`からの変更点は以下です。

- EDの定義とV1交換を維持する。
- 太陽位相、有効期間、品質、要求照合を持つV2を提案する。
- パケット配置の再利用とは別に、版の判別とV1への切り替えを定義する。
- 経度のみで求めるモデル上の太陽位相と、観測上の限界を明示する。
- EDの品質と太陽位相の利用可否を分ける。
- 関連技術、位置情報保護、ダウングレードの危険、未検証事項を記載する。

配信するのは瞬間の状態です。GPS座標を送るサービスや予定管理サービスではありません。
日の出・日没、太陽高度、地図、タイムゾーン変換、認証のパケット形式は本版の範囲外です。

## 2. 要求事項の表現

英語正本の大文字のMUST、MUST NOT、SHOULD、MAYなどは、BCP 14の
[RFC 2119](https://www.rfc-editor.org/rfc/rfc2119.html)と
[RFC 8174](https://www.rfc-editor.org/rfc/rfc8174.html)に従います。
本書の要求事項は提案する仕様を表し、現在の実装が満たしているとの宣言ではありません。

## 3. 二つの座標と二つの役割

### 3.1. Earth DateとEarth Year

```text
ED(t) = Y + lambda(t) / 360度
```

`lambda`は採用したNEPP天文プロファイルの地心視太陽黄経で、範囲は`[0, 360)`度です。
Earth Year `Y`は春分の0度通過から始まり、その春分を含むグレゴリオ暦年を整数ラベルに
使います。春分前は前年のEarth Yearになります。

小数部は角度であり、固定長の一年に対する経過時間の割合ではありません。
春分・夏至・秋分・冬至に対応する四分の一周の間隔も、物理時間では等間隔ではありません。
その場所で経験する季節は、半球・緯度・気候にも依存します。

太陽位相は、これとは別の周期座標です。同じ瞬間・同じモデルのEDは全員共通ですが、
局所位相は選んだ経度によって変わります。EDの小数部を取っても自転位相にはなりません。

一年あたりの日数も、太陽位相一周あたりのSI秒数も定数として定義しません。
SI秒は通信遅延、局所発振器の経過時間、補間速度の単位として引き続き使用します。

### 3.2. ED天文プロファイル1

ED Model ID 1は、両プロトコル版で実験的なNEPP Astronomical Profile 1を示します。
基準は地球中心から見た太陽の視方向であり、特定の観測地点での方向ではありません。
IAUの黄道定義、IAU 2006歳差、IAU 2000A章動、IERS Conventionsに整合する
変換を使います。黄経は春分点方向から見かけの年周運動方向に増加し、`[0, 360)`度とします。

Profile 1の実現は、次を行う必要があります。

1. 高精度太陽系天体暦から、必要な時系で指定した時点の地球・太陽状態を取得する。
2. 光行時間、光行差など、採用モデルが必要とする視位置補正を適用して地心視方向を求める。
3. 整合した歳差・章動・座標系変換を適用する。
4. 黄道面と春分点原点を構成し、視方向をその面へ投影して有向黄経を求める。
5. 春分通過からEarth Yearを決め、第4.2節の方法でEDを符号化する。
   民用年の経過割合で代用しない。
6. 天体暦、変換、時刻付与、予測に見合う局所ED速度と不確かさを評価・報告する。

等速円運動や、補正していない二体ケプラー楕円で規範的定義を代用してはいけません。
SOFAに整合する算法を参照手段として推奨しますが、特定の言語を要求しません。
異なる天体暦を使う場合、その差が報告する不確かさの範囲に収まる必要があります。
同じModel IDであることだけでは一致の証明になりません。

固定する天体暦、黄道・春分点の実現、数値手順、独立検証した精度は第13節の未決事項です。
これは実験的プロファイル自体の未完成部分であり、`-01`に答えがあるという意味では
ありません。実装は採用した実現を文書化し、識別子だけで天文学的相互運用性を検証済みと
主張してはいけません。

### 3.3. 時系とED変化率

物理的経過時間はSI秒で測ります。算法に応じてTT/TDBなどを使い、UTCは適切に変換して
入力時点に使えます。ED自体には閏日・閏秒の挿入はありませんが、UTCを使う実現では
UTC閏秒を正しく処理し、人工的なEDの不連続を作ってはいけません。

局所速度は`R = dED/dt`、単位はED/SI秒です。補間と遅延推定のための量であり、
EDそのものを定義しません。春分をまたぐ微分は循環する小数部でなく完全なEDを使います。
長期予測には天文モデルが必要で、線形補間を無期限に延長しません。同期近似と自走保持は
第8節で定義します。

## 4. Version 1仕様

本節でV1を旧版への依存なしに定義します。V2のトークン、128オクテット長、ゼロ埋め、
太陽フィールドをV1クライアントに要求してはいけません。V1の形式と意味は維持します。

### 4.1. 基本配置と版の判別

整数はbig endian、符号付き整数は2の補数です。先頭Flagsオクテットは上位から
`Status:2 | Version:3 | Mode:3`で、Versionは`(flags >> 3) & 7`で取り出します。

| Offset | Octets | Field |
|---:|---:|---|
| 0 | 1 | Flags |
| 1 | 1 | Stratum |
| 2 | 1 | Poll（符号付き） |
| 3 | 1 | Precision（符号付き） |
| 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 |

V1基本パケットは76オクテット、Versionは1です。76未満は不正です。
後続オクテットは拡張データでありV2フィールドではありません。本書は拡張の型・長さ形式や
critical拡張の機構を定義しません。基本形式だけを扱うV1実装は後続を無視し、76オクテットの
応答を返します。後続を認証や太陽情報と解釈してはいけません。拡張を理解する実装には
別途明示された仕様合意が必要ですが、それをV1基本実装の前提とはしません。

### 4.2. 時刻印と変化率の符号化

時刻印は符号付き32ビットEarth Yearと符号なし64ビット小数部で、
`U = floor(F * 2^64)`、復号値は`Y + U / 2^64`です。許された箇所の全ゼロは
時刻印なしを示し、信頼できる同期時点ではありません。年境界を含む差分は、
年と小数部を独立に引かず、完全なED値として求めます。

ED Rateは符号付き64ビット`round(R * 2^63)`で、復号単位はED/SI秒です。
Statusは0＝同期、1＝劣化、2＝自走保持、3＝未同期で、NTPの閏秒フラグではありません。
Modeはクライアント3、サーバー4です。Stratumは0＝基準源、1＝一次サーバー、
2〜15＝二次サーバー、16＝未同期、17〜255＝予約です。同期に使うネットワーク
サーバーのStratumは1〜15です。

Pollは`2^Poll` SI秒の推奨間隔、Precisionは`2^Precision` EDの公称分解能です。
Precisionは精度保証ではありません。Root DelayとRoot Dispersionは符号なし16.16
固定小数点のSI秒で、累積往復遅延と同期不確かさを表します。Reference IDとModel IDは
それぞれ基準源と、第3.2節のED天文プロファイルを示します。

### 4.3. フィールドの意味

Status 0は同期したED源、1は天文源品質の劣化、2は予測のみ・自走保持、3は未同期です。
3を同期に使ってはいけません。受信側は品質方針に従い1・2を拒否しても構いません。

Modeは0予約、1 symmetric active、2 symmetric passive、3 client、4 server、
5 broadcast、6・7予約です。本書は3・4のみの動作を定義し、基本実装はそれらに対応します。
他の名前から対称同期やbroadcastの動作仕様を推測してはいけません。

一次サーバーは天文基準からEDを計算し、二次サーバーは上流NEPPから導きます。
Stratumは論理的な距離であり、精度・認証の保証ではありません。Stratum 0は天体暦や
天文計算システムなどの基準源で、通常のネットワークサーバーではありません。

PollとPrecisionは符号付き8ビットの`-128..127`です。Poll 6は64 SI秒を推奨します。
実際の問い合わせ間隔と資源利用は局所方針で制限し、不審な指数値を無制限に使用しません。

Root Delay・Root Dispersionの符号なし整数Wは`W / 65536` SI秒で、
範囲は0から`65535 + 65535/65536`秒です。前者は基準までの累積往復遅延、後者は
累積同期不確かさの上側見積もりです。天文モデルの不確かさもRoot Dispersion、または
クライアントが理解する別仕様の拡張で伝える必要があります。基本交換ではRoot Dispersionに
含めます。ゼロは「不明」の特別値ではありません。表現できない不確かさを有限の正しい上限と
主張できず、その基準源は同期に利用できないものとして扱います。

Reference IDは32ビットの基準源識別子で、一次では源やプロファイル、二次では上流源や
ループ検出の補助に使えます。世界共通レジストリは定義しません。必ずしもIPv4アドレスではなく、
ASCIIラベルだけで追跡可能性が証明されるわけでもありません。ED Model IDは符号なし32ビットで、
1の定義は第3.2節にあります。未知のモデルをProfile 1と同じと仮定できません。

### 4.4. V1要求と応答

クライアント送信E1、サーバー受信E2、サーバー送信E3、クライアント受信E4を使います。
E4は手元で記録し、送信しません。要求はVersion 1・Mode 3で、TransmitにE1、
OriginとReceiveにゼロを設定します。Referenceは実装依存値またはゼロです。
初期取得・未同期ではStatus 3・Stratum 16とし、ED未取得ならE1にゼロを使えます。
Poll・Precisionはクライアントの方針、応答専用情報はゼロで構いません。
V1には乱数トークンはなく、V2の追加要求検査を適用しません。

サーバーは受信時にE2を記録し、要求TransmitをそのままOriginにコピーし、送信に可能な限り
近い時点でE3を記録します。応答はVersion 1・Mode 4で、自身の状態・Stratum・基準源・
品質情報、ReceiveにE2、TransmitにE3、局所ED速度を返します。Referenceは同期に使った
基準ED状態、未提供ならゼロです。ED速度は応答送信時点へ評価・補間することを推奨します。
要求に無視する拡張が付いていても、基本形式の応答は76オクテットです。

受信側は自分のED時計でE4を記録し、通常は第8.1節を使います。E1/E4なしの初期取得では
第8.2節のED部分だけを使用し、V1には太陽の項はありません。ゼロOriginとゼロE1は
照合できますが、偽装・再送に対する保護は弱いものです。V1応答から太陽状態を捏造しては
いけません。

### 4.5. V1の受け入れ・エラー・最小実装

非対応Version、Server以外のMode、未同期Status、要求E1と異なるOrigin、不正な時刻印、
76オクテット未満、禁止された予約値、許容上限超過のRoot Dispersionは同期に使えません。
Origin照合は必須です。さらに選択したネットワーク相手との一致、重複の破棄、時間や基準情報の
妥当性確認を推奨します。V2のトークン・固定長・太陽検査は適用しません。

サーバーは不正なパケット、未知の版、実装しないModeへ応答せず破棄します。
別版の応答は版交渉ではありません。UDPは第7.1節・第11節の要求応答方式を使い、
連続した接続を前提としません。

基本V1サーバーはProfile 1計算、E2/E3、ED速度、Stratum、遅延、分散を実装します。
基本同期クライアントは可能な場合のE1/E4記録、Origin照合、オフセット推定、時計制御、
自走保持を実装します。初期取得だけの表示は限定的クライアントであり、完全な同期精度の
証明ではありません。品質管理と基準源選択は第8.4節を参照します。
仕様を書いただけで既存コードの不足が解消されるわけではありません。

## 5. 基準太陽位相と局所太陽位相

### 5.1. 定義

負の値も含めて`frac(x) = x - floor(x)`とします。提案するSolar Model 1において、
`alpha_app(t)`を真赤道・真春分点（of date）に基づく地心視太陽赤経、`GAST(t)`を
同じ基準系に対応するグリニッジ視恒星時とし、どちらもラジアンで表します。

```text
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度)
```

`L`はグリニッジ基準子午線に対して東経正・西経負の経度です。
クライアントでは`[-180, 180)`度への正規化を推奨します。これは座標系の基準であり、
民用タイムゾーンや歴史的な特定の子午線標識そのものを意味しません。

`P_L`は`[0, 1)`で、モデル上の上方子午線通過で0.5、下方通過で1直前から0へ戻ります。
これは[USNOの視太陽時の定義](https://aa.usno.navy.mil/faq/eqtime)を一周1で表したもので、
新しい天文学的時系の発明ではありません。

春分点基準の赤経を維持したまま、GASTだけをEarth Rotation Angleに置き換えては
いけません。CIO基準を使う場合は両方を整合して変換します。単位・原点・符号の一致が
必要です。

### 5.2. 経度だけで求めるモデルの範囲

Solar Model 1は、経度だけを使う理想化した地心モデルです。通常は端末の位置情報が
返す測地経度（一般にWGS 84）、または手動選択した経度を直接適用します。
観測者ごとの極運動補正、地心視差の地表補正、鉛直線偏差、標高、大気差は適用しません。

従って0.5はモデル上の正午であり、あらゆる場所で観測した太陽の頂点時刻との厳密な
一致を保証しません。完全な地球固定系・天球系変換には
[IERS Conventions第5章](https://iers-conventions.obspm.fr/content/chapter5/icc5.pdf)
に記載された極運動なども関係します。緯度や追加状態を使う高精度モデルを導入する場合、
この経度のみのモデルと黙って入れ替えてはいけません。

0.25・0.75は日の出・日没と定義しません。昼夜の判定には緯度、太陽赤緯、地平線条件も
必要です。白夜・極夜も含め、位相だけでは太陽が地平線より上にあるか分かりません。
地理的な極では経度は一意の物理的意味を持たないため、明示的な基準経度を選ぶか、
局所位相を利用不可とし、一意の現地正午が求まったように表示しないことが必要です。

### 5.3. 天文モデルと地球姿勢データ

提案するSolar Model ID 1は地心視太陽方向、IAU 2006歳差、IAU 2000A章動と、
整合するGAST計算を使います。ED Model IDとは別の識別子空間です。番号が同じ1でも
同じフィールドではありません。固定した実現手順と独立テストベクトルができるまでは
暫定プロファイルです。

サーバーはIERSの`UT1-UTC`からUT1を求めます。自転にはUT1、天文計算には各算法に
応じてTTやTDBを使います。UT1-UTCの単位は秒であり、位相へ直接加える値ではありません。

[IERS Bulletin A系データ](https://maia.usno.navy.mil/products/bulletin-a)には速報値と
予測値があります。「今」は確定観測ではなく予測に基づく場合があります。
補間ではUTC閏秒境界を扱い、UT1-UTCの段差を単純に直線補間してはいけません。
補正値が不明な場合、黙ってUT1＝UTCとみなしてはいけません。

天体暦とEOPはキャッシュし、パケット処理とは別に更新することを推奨します。
ダウンロード失敗でも有効なキャッシュは使えますが、データの年齢をリセットしたり、
配信元の予測範囲を延ばしたりしてはいけません。認証された取得経路とキャッシュの
不可分な差し替えを推奨します。[SOFAの資料](https://www.iausofa.org/cookbooks)も参照できます。

実装は天体暦、モデル・ソフトウェア版、EOP製品と公開版、補間方法、対応期間、
不確かさの方針を運用文書で公開する必要があります。パケットは品質の要約であり、
完全な出典記録ではありません。特定のPythonパッケージは規範としません。

### 5.4. 変化率と共通の時点

`Q = d(unwrapped P_G)/dt`とし、単位は周/SI秒です。数値微分は0/1境界を展開して
から行います。`1/86400`は大きさの目安であり、規範的な定数ではありません。

V2応答の`P_G`・`Q`・送信ED `E3`・ED Rate `R`は、同じサーバー送信時点`t3`に
対応しなければなりません。キャッシュ状態を誤差範囲内で`t3`まで補間しても構いません。
異なる時点のEDと位相を、同一時点へ進めず組み合わせることは禁止します。

## 6. Version 2パケット案

要求・応答ともに**128オクテット固定**で、V1と同じ設定済みUDPエンドポイントを使います。
先頭76オクテットは第4節を再利用しますが、Versionは2です。V1として解析しては
いけません。残りの配置は次のとおりです。

| Offset | Octets | Field | Encoding |
|---:|---:|---|---|
| 76 | 16 | Request Token | ランダムなオクテット列をそのまま返信 |
| 92 | 1 | Solar Status | 符号なし列挙値 |
| 93 | 3 | Reserved | ゼロ |
| 96 | 8 | Reference Solar Phase | 符号なし、単位`2^-64`周 |
| 104 | 8 | Solar Phase Rate | 符号付き、単位`2^-63`周/秒 |
| 112 | 4 | Solar Uncertainty | 符号なし、単位`2^-32`周 |
| 116 | 4 | Solar Validity | `t3`からの整数SI秒 |
| 120 | 4 | EOP Data Age | 整数SI秒、または不明 |
| 124 | 4 | Solar Model ID | 符号なしモデル識別子 |

複数オクテット整数はnetwork byte orderです。本案のV2には拡張トレーラーを設けず、
128オクテットより短い・長いデータグラムは拒否します。Reservedは送信時ゼロとし、
受信値が非ゼロならパケットを拒否します。将来の形式変更は明示的に仕様化します。

### 6.1. Request Token

再試行を含む新しい要求ごとに、暗号学的に安全な乱数生成器で非ゼロの128ビット
トークンを生成します。サーバーはそのまま返し、クライアントは未消費の要求と一致した
応答を一度だけ受け入れます。E1がない初期取得でも照合できます。
これは認証ではなく、通信経路上の攻撃者を防ぐものでもありません。
端末固有IDを入れてはいけません。

### 6.2. 位相と変化率の符号化

位相は`floor(P_G * 2^64)`、復号は`2^64`で割ります。ゼロも有効な位相であり、
欠損はSolar Statusで判断します。変化率は`round(Q * 2^63)`で符号化し、復号時に
`2^-63`を掛けます。この新規フィールドの丸めは最近接・中間値偶数丸めです。
Solar Model 1の利用可能なQは正でなければなりません。オーバーフローを巡回させず
エラーとし、受信側もモデルに応じた妥当範囲を確認することを推奨します。

ビット数の多さは物理的な精度の保証ではありません。位相差は円周上で扱い、
変化率は周期境界を展開して求めます。

### 6.3. 独立したSolar Status

| 値 | 意味 |
|---:|---|
| 0 | 利用不可 |
| 1 | 有効期間全体で観測・確定値または速報EOPに基づく |
| 2 | 有効期間の少なくとも一部で配信元のEOP予測を使う |
| 3 | 配信元の対応範囲外への自走保持・外挿で、明示的な誤差上限を持つ |
| 4〜255 | 予約 |

位相、微分、有効期間に必要な全データのうち最も条件の悪い区分を採用します。
観測値と予測値の間を補間する場合は2です。正当な外挿誤差の上限なしに3を使えません。

Flags StatusとStratumはEDサービスを示し、Solar Statusとは独立です。
EDが同期していてもSolar Status 0を返せます。太陽データだけの失敗でV1へ切り替えたり、
正常なEDを捨てたりする必要はありません。

Solar Status 0では位相・変化率・不確かさ・有効期間・Solar Model IDをゼロ、
EOP Data Ageを`0xffffffff`にします。このゼロ位相を深夜として表示してはいけません。
未知のSolar StatusやSolar Model IDでは太陽情報を使えませんが、正常なEDは利用できます。

### 6.4. 不確かさ・有効期間・データ年齢

Solar Uncertaintyは`ceil(B * 2^32)`です。Bは、配信位相と線形速度で補間する場合の
有効期間全体の最大円周位相誤差について、保守的に見積もった上限です。
モデル、EOP予測、計算、量子化、サーバー時点の誤差、補間誤差を含みます。
統計的な信頼水準ではありません。クライアント経度誤差と通信・端末側の時間誤差、
Solar Model 1が意図的に対象外とした観測効果は含みません。

`0xffffffff`は不明です。利用可能な太陽情報の符号化上限は`0x80000000`（半周）未満、
Solar Validityは1〜3600秒でなければなりません。誤差評価が長時間を裏付けない限り、
例えば60秒程度の短い期間を推奨します。この条件を満たせなければSolar Status 0とします。

Solar Validityは`0 <= t - t3 <= V`を表し、受信からV秒ではありません。
受信側はパケットの経過時間と推定誤差も考慮し、その上限がVを超える可能性があれば
有効表示を止めます。期限後に古い情報や独自予測を表示するなら、その旨を明示し、
サーバーの保証期間を勝手に延長してはいけません。

EOP Data Ageは、使用したEOP製品の公開時点から`t3`までのSI秒を切り上げた値です。
複数製品では関係する最古の公開時点を使います。不明・表現不能は`0xffffffff`です。
ダウンロード時刻で代用してはいけません。新しい製品にも予測値があり、古い製品にも
良い過去観測があるため、年齢は精度保証ではありません。クライアントは独自の年齢・品質・
不確かさの許容条件で太陽情報を拒否しても構いません。

## 7. 要求・応答・検証

### 7.1. 版の判別と増幅対策

サーバーはVersionビットを見てから解析器を選びます。空、未知の版、不正な要求、
非対応Modeは応答せず破棄します。本案では版交渉のエラーパケットを定義しません。

V1要求には従来どおりV1、V2要求には太陽情報の有無にかかわらずV2を返します。
V1要求にV2を返してはいけません。旧クライアントがV2を読める必要はありません。

V2要求は128オクテットです。76オクテットのVersionだけ2へ変えた要求は不正です。
ユニキャスト要求に対して最大1応答とし、応答UDPペイロードは要求より大きくしては
いけません。レート制限、キャッシュや要求ごとの処理量の上限が必要です。
同じ長さにしても、送信元詐称による反射攻撃そのものはなくなりません。

### 7.2. V2クライアント要求

FlagsはStatus 3・Version 2・Mode 3（`0xd3`）、Stratumは16、Pollは選択値
（既定6）、Precisionは0です。Transmit EDへE1を設定し、未取得なら12ゼロの
初期取得要求とします。新しいRequest Tokenを設定し、他はすべてゼロにします。
この形式に従わないV2要求は拒否します。

クライアントは単調時計の送信時点`m1`を記録します。サーバーは受信ED `E2`を記録し、
要求Transmitを応答Originへそのままコピーします。送信時点`t3`にE3、R、太陽状態を
評価します。応答にはサーバーのED状態、Stratum、基準情報、推奨Poll、Precisionを載せます。
Reference EDは最後の正常な基準更新時点で、不明ならゼロです。トークンは要求をコピーし、
Reservedはゼロのままとします。

### 7.3. 応答の受け入れ

単調時計の受信時点`m4`と、可能なら受信ED `E4`を記録します。使用前に以下を確認します。

- 長さ128、Version 2、Server Mode 4、Reservedがゼロ。
- 送信元IPアドレスとUDPポートが問い合わせたエンドポイントと一致する。
- トークンが未消費のV2要求と一致する。
- Originが要求Transmitと一致する（初期取得のゼロも含む）。
- Flags Statusが3以外、Stratumが1〜15、ED Model IDが対応範囲内。
- E2・E3が存在し、Rが正で、時間・分散の値が許容条件を満たす。

続いて太陽情報のStatus、モデル、正のQ、不確かさ、有効期間を独立に確認します。
不正・非対応の太陽情報を位相に使ってはいけませんが、検証済みEDは残して構いません。
太陽モデルが不明なことと、V2非対応は別です。

モデル不一致、過大な遅延、不自然な変化はサンプル拒否の理由とすべきです。
精度やStratumの自己申告だけで相手を信用できるわけではありません。

## 8. 同期と表示

### 8.1. EDの4座標同期

交換中のED速度が局所的に整合する場合、次を使います。

```text
theta_ED = ((E2 - E1) + (E3 - E4)) / 2
delta_ED = (E4 - E1) - (E3 - E2)
```

thetaが正ならクライアントが遅れています。delta_EDのSI秒への換算にはその時点の
ED速度を使い、固定の一年秒数を使いません。高精度が必要なら共通の物理時間への写像や
高次モデルが必要です。NTP型の推定と同様、経路非対称性の限界があり、片道遅延の
厳密な測定ではありません。

### 8.2. 初期取得と共通のローカル基準

E1/E4がない場合、そのゼロを実在のEDとして4座標式へ代入してはいけません。
限定的な初期推定では次を使えます。

```text
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)
```

安定した単調時計、局所的に有効なR/Q、測定誤差内で非負の遅延が前提です。
矛盾するサンプルは拒否します。小さな負の残差は、明示した測定許容幅内でのみゼロへ
丸められます。半往復遅延は対称経路の仮定です。受信までの経過時間の保守的な上限には、
半分だけでなく非負の経路往復遅延全体と測定誤差を考慮します。

EDと位相は同じ単調時間の基準から、それぞれの速度で進めます。受信からの経過をuとすると、

```text
P_L(now) = frac(P_G_at_receive + Q * u + L(now) / 360度)
```

経度を変えてもEDやサーバー状態は変わりません。有効性は`t3`からの時間上限
（通信中の経過とuを含む）がSolar Validity内にあることを確認します。
端末の位相誤差評価には、時間誤差×位相速度、経度誤差÷360度も加えます。
時計補正、スリープ復帰、発振器の不連続では再評価または再取得が必要です。
壁時計の変更を物理的経過時間として扱ってはいけません。

### 8.3. 表示と予定

ED同期、太陽品質、選択した場所、期限切れを区別して表示することを推奨します。
手動選択した場所はその旨を明示します。位置許可を拒否してもEDは利用できます。
1から0への循環は正常であり、時計故障ではありません。

局所位相だけでは、毎周繰り返すため瞬間を一意に指定できません。待ち合わせには
基準場所・経度と、EDの探索区間などで「どの回か」の指定も必要です。
将来のEDへの変換には天文予測が必要で、短い有効期間のパケットは長期の予定計算を
保証しません。渋谷を選ぶかGPS現在地を使うかはクライアントの選択であり、新しい
プロトコルのタイムゾーンを作るわけではありません。

### 8.4. ED自走保持・時計制御・複数基準源

両版とも最後の同期状態`(ED0, R0)`を保持し、短期間は`ED ~= ED0 + R0 * delta_t`と
推定できます。長期間では、根拠ある高次モデル
`ED0 + R0*delta_t + 0.5*A0*delta_t^2`や天文予測を推奨します。
`A0 = dR/dt`であり、本書のどちらの基本パケットにもA0は載りません。

常時接続を要求してはいけませんが、新しい同期測定と予測・自走保持は区別します。
不確かさの増加を追跡し、品質上限を超えたら有効な同期との表示を止めることを推奨します。
V1に有効期間フィールドがないことは、無期限外挿の許可ではありません。
V2 Solar Validityも太陽状態専用で、EDの自走保持期間を規定するものではありません。

繰り返しの交換でED時計を制御することを推奨します。小さな補正は通常滑らかに、大きな
補正は時刻の飛びと共通基準の再設定が必要になる場合があります。通常のED表示は後退させない
ことを推奨しますが、虚偽の精度で補正を隠してはいけません。位相の循環や場所変更はED補正とは
別の現象です。

信頼性が必要な場合は独立した複数源を推奨します。Stratum、遅延・分散、測定遅延、
過去の安定性、モデル、天文的出典、基準源の独立性などで選択します。ホスト名が違うだけでは
モデルや観測が独立とは限りません。不確かさやモデル差で説明できない不一致源は除外することを
推奨します。複数の未認証源を使っても暗号学的な信頼は生まれず、同期ループや共通障害も残ります。

## 9. バージョン互換性と切り替え

| クライアント | サーバー | 結果 |
|---|---|---|
| V1 | V1 | 従来のED交換 |
| V1 | V1/V2両対応 | 変更のないV1 ED交換 |
| V2対応 | V1/V2両対応 | V2でEDと太陽情報、または太陽利用不可のED |
| V2対応 | V1 | V2には無応答。別のV1要求でEDのみ取得 |

まずV2を試すことを推奨します。初期タイムアウトの推奨値は2秒で、その後、可用性を
優先する方針なら別のV1要求を送ります。無応答は非対応の証明ではありません。
V2要求に届いたV1応答をダウングレードとして受け入れず、V1は別に追跡するトランザクション
として第4節のルールに従います。

V1の毎回の問い合わせでV2を試さず、例えば15分に揺らぎを加えた間隔や、回線・
サーバー変更時に再確認することを推奨します。記憶する版の選択はエンドポイント単位・
有限期間とし、ホスト名だけで永久保存しません。V2必須の設定も可能です。
正常なV2応答で太陽情報だけが使えないことは切り替え理由にしません。

攻撃者がV2通信を落とすとV1へ誘導できるため、未認証のダウングレードリスクを
文書化する必要があります。どちらの版も、応答があっただけで完全性は保証されません。

## 10. 関連技術と設計意図

### 10.1. UTC・TAI・UT1

UTC/TAIは原子時の基盤、UT1は地球の自転を表します。NEPPはそれらを不要にするのではなく、
その基盤から求めた天文座標を配ります。固定の一年秒数で定義しないことと、実装で
時間計量に依存しないことは別です。
[BIPM Time Metrology](https://www.bipm.org/en/time-metrology)を参照してください。

### 10.2. NTP・PTP

[NTPv4](https://www.rfc-editor.org/rfc/rfc5905.html)から、4イベントによる遅延・
オフセット推定、ポーリング、Stratum、時計制御の考え方を継承します。NEPPは非等速の
EDに応用し、変化率も配信します。96ビット時刻印やFlagsはNTP互換ではなく、
NTPポートでNTPとして提供してはいけません。

[IEEE 1588/PTP](https://www.nist.gov/el/intelligent-systems-division-73500/ieee-1588-systems)
は時間配信システム内の時計を協調させます。NEPPはPTPと同等の精度や仕組みを主張せず、
良質な基礎時計を不要にしません。NTP/PTPは天文計算のホスト時計を支えられ、
NEPPはその上で配る座標を定めます。

### 10.3. Unix time・Julian Date

[POSIXのEpochからの秒数](https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html#tag_04_16)
や[Julian Date](https://aa.usno.navy.mil/data/JulianDate)も日時を数値で表します。
数値化そのものを新規性とはしません。Julian Dateは日数とその小数部であり、精密利用には
時系の指定が必要です。EDの小数部は等速の経過時間ではなく、太陽黄経に対応します。

### 10.4. 十進時刻・Swatch Internet Time

十進数で分割するだけでは新しい提案ではありません。
[Swatch Internet Time](https://www.swatch.com/th-th/internet-time.html)は、Biel Mean Timeを
基準に通常の24時間の日を1000 beatsに分割します。NEPPの局所太陽位相は選択した経度と
見かけの太陽運動に従って変わり、固定の民用日を十進数へ換算するものではありません。

### 10.5. 平均太陽時・視太陽時・民用タイムゾーン

平均太陽時は太陽運動を平均化し、視太陽時は太陽の時角に従います。両者には均時差があり、
本案は視太陽時を正規化したものです。UTCに経度を加えるだけではありません。
[USNOの解説](https://aa.usno.navy.mil/faq/eqtime)を参照してください。

民用タイムゾーンは局所太陽時からずれる代わりに共通の生活時間を提供します。
NEPPはその廃止や法的な時間を規定せず、世界共通の瞬間と、その場所の日周の意味を分けます。
提案するのはED同期、基準位相・速度・品質の配信、私的な端末内経度適用の組み合わせです。
太陽時自体の発明や、社会的採用の正しさを証明するものではありません。

## 11. セキュリティ・プライバシー・運用

両版とも未認証です。偽装、再送、不正な基準源、遅延操作、偽の不確かさ、DoSが可能です。
V2乱数は経路外からの応答照合を強めますが、MAC・署名・認証ではありません。
V1のOrigin照合は特にゼロ時刻印の初期取得で弱く、安全な同期と宣伝してはいけません。

[Network Time Security](https://www.rfc-editor.org/rfc/rfc8915.html)はNTPの先行技術であり、
NEPPへ自動的に適用できるものではありません。NEPPの認証形式と版切り替え保護は別の
設計が必要です。高い完全性が必要な用途には、適切に検討された認証手段を使います。

要求には緯度・経度・地名・永続的利用者IDを含めません。トークンや予約領域などへ
位置を埋め込んではいけません。位置サービスや手動地点保存は端末内に置きます。
一方サーバーからは送信元IPと問い合わせ時刻が見えるため、ネットワーク匿名性は
主張しません。記録を最小限にし、一時的なレート制限状態にも上限を設けることを推奨します。

高コストの天文計算より先に長さ・版の確認とレート制限を行い、EOP更新を別処理にして
失敗時方針を定めます。太陽情報の不調で既存のV1サービスを不要に停止させない設計とします。
実験用の設定可能なdynamic/private UDPポートを使い、`56377`は配備上の選択であって
IANAの割り当てではありません。

## 12. 符号化例と検証計画

次は合成した算術例で、天文予測値ではありません。

| 対象 | 入力 | 期待値 |
|---|---|---|
| V2初期要求Flags | Status 3・Version 2・Mode 3 | `d3` |
| V2同期サーバーFlags | Status 0・Version 2・Mode 4 | `14` |
| 基準位相符号 | `P_G = 0.5` | `80 00 00 00 00 00 00 00` |
| 基準位相符号 | `P_G = 0.25` | `40 00 00 00 00 00 00 00` |
| 局所位相 | `P_G = 0.9`, `L = +90度` | `0.15` |
| 局所位相 | `P_G = 0.1`, `L = -90度` | `0.85` |
| 厳密速度例 | `Q = 2^-16周/秒` | 符号付き整数`2^47` |
| 厳密不確かさ例 | `B = 2^-20周` | 符号なし整数`4096` |

128オクテットの合成初期要求は、byte 0を`d3`、1を`10`、2を`06`、
76〜91のトークンを`01 02 ... 10`、他をゼロとします。固定トークンは符号化試験専用で、
実運用の乱数として使ってはいけません。

配備前に次を試験します。

1. 配置、符号、サイズ、短すぎる・長すぎるパケットの拒否。
2. V1回帰試験と、既存iOS 0.0.1の継続動作。
3. 未知の版・Mode、予約領域、誤った相手・トークン・Origin、重複・遅延応答、増幅なし。
4. 欠損時刻印を式へ入れない初期取得、EDの年境界。
5. 東西経度の循環、位相微分の展開、EDと位相の同一時点。
6. 太陽情報なし、予約状態、未知のモデル、EDのみの継続。
7. 通信経過を含む期限、時計変更、スリープ復帰、EOP更新失敗、予測境界、閏秒補間。
8. 第9節の組み合わせと、非対応ではなく通信損失によるタイムアウト。

天文ベクトルには時点と時系、UTC/TAI/UT1変換入力、EOP製品版、天体暦、座標系、
モデル・ソフトウェア版、GAST、地心視赤経、ED/R、P_G/Q、経度、局所位相と許容差を
含めます。正午、循環、季節点、観測・予測の切り替えを対象にします。
規範的な相互運用ベクトルとする前に独立計算が必要です。本版には、検証済みの
天文数値ベクトルはまだ含まれません。

## 13. 実装状況と未決事項

リポジトリには実験的なV1のPython server/clientとiOSクライアントが存在し、
著者は公開サーバー・TestFlightでのiOS 0.0.1動作を確認しています。ただしこれは
完全な天文プロファイルの独立検証ではありません。V2と太陽機能は未実装です。
この草案だけで稼働中のサーバーやアプリは変更されません。

V2を固定する前に検討すべき事項：

- 128オクテット配置、品質・有効期間の符号化。
- 基準座標系を含む、再現可能なED Profile 1実現手順。
- 太陽モデルの固定算法、対応時代、天体暦の版。
- モデル・速度・時計の誤差上限と外挿限界の裏付け。
- 初期取得、通信非対称性、経度誤差を扱うクライアント方針。
- 将来の高精度モデルでの極運動対応。
- 認証、認証された版交渉、識別子レジストリ。

経度のみの簡略化は意図した設計であり、見直し可能です。観測上の正午との厳密一致や
数値的精度の主張は、その根拠となるモデルと誤差分析が完成してから行います。

## 14. IANA Considerations

本版ではIANAへの要求はありません。Version 2とSolar Model ID 1は実験的な提案値で、
IANA登録済みの値ではありません。将来はポート、モデル、拡張のレジストリを検討します。

## 15. 参考文献

### 15.1. 定義・モデルに関する資料

- BCP 14：[RFC 2119](https://www.rfc-editor.org/rfc/rfc2119.html)、
  [RFC 8174](https://www.rfc-editor.org/rfc/rfc8174.html)。
- [IERS Conventions (2010), Technical Note 36](https://iers-conventions.obspm.fr/conventions/content/tn36.pdf)。
- [USNO: The Equation of Time](https://aa.usno.navy.mil/faq/eqtime)。

### 15.2. 関連技術・運用資料

- [NEPP英語版-01](draft-iwata-nepp-01.md)：過去版との比較用。本書の実装に必読ではありません。

- [IAU SOFA cookbooks](https://www.iausofa.org/cookbooks)。
- [IERS rapid service / Bulletin A](https://maia.usno.navy.mil/products/bulletin-a)。
- [BIPM Time Metrology](https://www.bipm.org/en/time-metrology)。
- [RFC 5905: NTPv4](https://www.rfc-editor.org/rfc/rfc5905.html)。
- [RFC 8915: Network Time Security](https://www.rfc-editor.org/rfc/rfc8915.html)。
- [NIST: IEEE 1588 Systems](https://www.nist.gov/el/intelligent-systems-division-73500/ieee-1588-systems)。
- [POSIX: Seconds Since the Epoch](https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html#tag_04_16)。
- [USNO: Julian Date](https://aa.usno.navy.mil/data/JulianDate)。
- [Swatch: Internet Time](https://www.swatch.com/th-th/internet-time.html)。

## 著者

Kenichi Iwata  
Tottori University, Japan  
Project: [nepp.kenic.jp](https://nepp.kenic.jp/)  
Contact: support@kenic.jp