Skip to content

TODO

Jump to bottom
taihei edited this page Mar 1, 2026 · 3 revisions

TODO / 今後の開発課題

本ページでは 対応状況 に基づく今後の開発課題を優先度別に整理する。

🔴 高優先度（実用上の制約）

S1AP/NGAP メッセージ

  1. NGSetupResponse の動的構築 (※1)

    • 現状: 41 バイト固定テンプレート
    • 課題: AMF Name・ServedGUAMIList・RelativeAMFCapacity を S1AP に反映
    • 影響: eNB 側で AMF 情報が取得できない

  2. InitialContextSetupRequest パラメータの動的抽出 (※2)

    • 現状: AMBR (100 Mbps), QCI (9), UE Security Capabilities (0xE000), E-RAB 数 (1) が固定
    • 課題: NGAP から実際の値を抽出して S1AP に反映
    • 影響: QoS や複数ベアラ設定が制限される

  3. InitialContextSetupFailure の NGAP 転送 (※3)

    • 現状: S1AP 受信・ログのみ、NGAP 送信なし
    • 課題: NGAP InitialContextSetupFailure を構築して AMF へ送信
    • 影響: AMF が ICS 失敗を検知できない

  4. UEContextReleaseComplete の NGAP 転送 (※4)

    • 現状: S1AP 受信・状態リセットのみ、NGAP 送信なし
    • 課題: NGAP UEContextReleaseComplete を構築して AMF へ送信
    • 影響: AMF がコンテキスト解放完了を検知できない

NAS メッセージ

  1. UE Security Capability の動的抽出 (※5)

    • 現状: 固定値 (5G-NEA/NIA: 0xF0/0x70, EPS-EEA/EIA: 0xF0/0x70)
    • 課題: 4G NAS (Attach Request, TAU Request) から実際の capability を抽出
    • 影響: UE がサポートしないアルゴリズムが設定される可能性

  2. Authentication Response 鍵導出の動的化 (※6)

    • 現状: PLMN ID (MCC=001, MNC=01) とアルゴリズム (EIA2/EEA2) が固定
    • 課題: Registration Request から PLMN を抽出、Security Mode Command からアルゴリズムを抽出
    • 参照: auth_response_4g_to_5g.c L149 (TODO コメント)
    • 影響: PLMN 依存の鍵導出が誤動作

  3. TAU Request の 5G-GUTI 依存解消 (※7)

    • 現状: 5G-GUTI キャッシュが必須、未保持時は変換失敗
    • 課題: キャッシュなしでも変換可能にする、または Attach へフォールバック
    • 影響: TAU 失敗時に UE が再接続できない

  4. Registration Accept の動的構築 (※8)

    • 現状: QCI=9, PDN=192.168.100.2, PCO 固定パターン
    • 課題: 5G NAS 復号または AMF からの情報取得
    • 影響: UE に正しい PDN アドレスや QoS が設定されない

🟡 中優先度（機能拡張）

S1AP/NGAP メッセージ

  1. UEContextReleaseCommand 対応

    • AMF → eNB の解放指示を受信して処理

  2. Paging 対応

    • AMF → eNB のページング要求を受信して eNB へ転送

  3. Handover 関連メッセージ対応

    • HandoverRequired / Request / Notify
    • eNB 間ハンドオーバの実装

  4. E-RAB/PDU Session 制御メッセージ対応

    • Setup / Modify / Release
    • デフォルト以外のベアラ/セッション制御

NAS メッセージ

  1. Detach / Deregistration 対応

    • UE の明示的切断処理

  2. Service Request 対応

    • Idle → Connected 復帰

  3. Identity Request / Response 対応

    • UE の識別情報取得

  4. SMS over NAS 対応

    • Uplink / Downlink NAS Transport

GTP-U

  1. GTP-U 拡張ヘッダ処理 (※10)

    • PDU Session Container からの動的 QFI 抽出
    • 複数 QoS Flow の同時利用対応

  2. Error Indication / End Marker 対応

    • type 26 / type 254 の処理実装

セキュリティ

  1. auth_keys.yaml によるマスター鍵集中管理の解消 ⚠️ アーキテクチャ課題

    • 現状: コンバーターが全 UE の Ki・OPc を config/auth_keys.yaml で保持
    • 問題: コンバーター侵害時に全加入者クレデンシャルが漏洩するリスク
    • 根本原因: 4G RES → 5G RES* 変換に Milenage 再計算 (Ki, OPc, RAND) が必要なため
    • 本来の設計: Ki・OPc は UDM/AUSF のみが保有すべき
    • 根本的解決の制約:
      • Ki・OPc を s1n2 から排除するには UDM/AUSF が CK/IK を外部提供する必要があるが、5GC 規格上そのようなインターフェースは存在しない
      • → 5GC 改修なしでの「鍵計算の委託」は構造的に不可能
      • → ただし auth_keys.yaml 自体の廃止は可能: Ki・OPc は Open5GS の MongoDB にすでに保存されており、auth_keys.yaml はその複製に過ぎない
    • 現実的な対策 (5GC 改修なし):
      1. Open5GS MongoDB から Ki・OPc を動的取得 ← 推奨 ★
        • auth_keys.yaml を廃止し、認証時に MongoDB (subscribers コレクション) から IMSI をキーに Ki・OPc を取得
        • Ki・OPc の単一の信源が MongoDB になり、二重管理が解消される
        • WebUI で加入者を登録すれば即座に s1n2 に反映され、設定ファイルの同期漏れがなくなる
        • 5GC 側は一切改修不要 (既存 DB を読むだけ)
        • 課題: libmongoc 等の MongoDB クライアントライブラリの組み込み、接続設定の追加
      2. 外部シークレット管理 (sops) への移行
        • auth_keys.yaml を sops 暗号化ファイルに置き換え、平文ファイルをなくす
        • 策 1 と組み合わせると MongoDB 接続情報自体を sops で保護できる
      3. auth_module を独立コンテナ (auth-agent) に分離
        • auth_module を専用 Docker コンテナとして切り出し、最小権限で実行
        • コンバーター本体が侵害されても Ki・OPc への直接アクセス不可
    • 推奨ロードマップ: 策 1 (MongoDB 直接取得) で auth_keys.yaml を廃止 → 策 2 (sops) で接続情報を保護
    • 影響: テスト・開発環境限定 の根拠がここにある (README の WARNING)

  2. SNOW 3G / ZUC アルゴリズム実装 (※11)

    • NIA1 / NEA1 (SNOW 3G)
    • NIA3 / NEA3 (ZUC)
    • 現状: 定義のみ、実装なし

  3. SUCI (Subscription Concealed Identifier) 対応

    • Profile A (ECIES Curve25519)
    • Profile B (ECIES secp256r1)
    • 現状: 平文 SUPI のみ

🟢 低優先度（検証・最適化）

ハードウェア検証

  1. 他ハードウェアでの動作確認

    • Mac 等の他ホストマシン
    • 他の 4G 基地局 (Baicells 以外)
    • iPhone / Android (Pixel 以外) / IoT デバイス

  2. マルチ接続対応の検証

    • 複数 eNB 同時接続
    • マルチ UE 同時接続 (負荷テスト)

ソフトウェア検証

  1. 他 OS での動作確認

    • Ubuntu の他バージョン
    • macOS
    • Windows (WSL2)

  2. 他 5GC との互換性検証

    • free5GC
    • OAI-CN5G
    • 商用 5GC

  3. Open5GS 新バージョン対応

    • v2.7 以降のリリースへの追従

🟣 将来的な拡張機能

ネットワーク手続き

  1. Emergency Attach 対応

    • 緊急接続の実装

  2. 複数 PLMN / ネットワークスライス対応

    • 現状: 単一のみ
    • マルチ PLMN・マルチスライス環境への対応

  3. Dedicated Bearer / QoS Flow 制御

    • デフォルト以外のベアラ設定変更

  4. Configuration Update Command 対応

    • UE への設定更新配信

  5. 位置情報レポート対応

    • LocationReportingControl / LocationReport

高度な機能

  1. RAN 構成更新対応

    • eNBConfigurationUpdate / AMFConfigurationUpdate

  2. 緊急警報 (PWS) 対応

    • WriteReplaceWarningRequest

  3. トレース制御対応

    • TraceStart / DeactivateTrace

  4. 輻輳制御対応

    • OverloadStart / Stop

  5. UE 能力情報通知対応

    • UECapabilityInfoIndication

📋 コード品質改善

リファクタリング

  1. ハードコード値の設定ファイル化

    • PLMN ID, QCI, AMBR, PDN アドレス等を設定ファイルから読み込み
    • 環境変数での柔軟な設定

  2. エラーハンドリング強化

    • ErrorIndication の NGAP → S1AP 方向対応
    • 各種エラーケースの網羅的処理

  3. ログ・デバッグ機能拡充

    • レベル別ログ出力
    • パケットダンプ機能

  4. テストカバレッジ向上

    • 単体テスト・結合テストの追加
    • CI/CD パイプライン構築

  5. ドキュメント整備

    • API ドキュメント
    • アーキテクチャ図の更新
    • トラブルシューティングガイド

  6. ASN.1 コードの Open5GS 依存解消（ライセンス自由化）

    • 背景: 現在のビルドは以下の Open5GS 由来コードをリンクしており、AGPL-3.0 の伝播対象となっている
      • include/s1ap/ — Open5GS fork の asn1c で生成された S1AP ASN.1 コード
      • open5gs/lib/asn1c/ngap/ — Open5GS の NGAP ASN.1 コード（ビルド時 fetch）
    • 変換ロジック自体（src/ 以下）はオリジナルなので、ASN.1 部分を切り離せれば Apache-2.0 等より自由なライセンスを選択できる
    • 課題:
      • include/s1ap/ は Open5GS fork 版 asn1c（非公開ビルド）で生成されたもの。標準の asn1c v0.9.28 では asn1/S1AP.asn のパースエラーが発生し、現状はビルド時自動生成が不可
      • open5gs/lib/asn1c/ngap/ も同様に Open5GS の asn1c fork が必要
    • 対応方針候補:
      1. Open5GS の asn1c fork を Dockerfile に組み込み、asn1/S1AP.asn / asn1/NGAP.asn からビルド時に自動生成
      2. free5GC 等の別実装の ASN.1 ライブラリへ移行（言語変更を伴う）
      3. ASN.1 エンコード・デコード部分のみを自前実装
    • 優先度: 低（動作上の問題ではなく、公開ライセンス方針の問題）

関連資料

s1n2-Gateway Wiki

Getting Started

  1. Home
  2. eNB Setup Guide
  3. eSIM Setup Guide

Documentation

  1. Project Structure
  2. Architecture
  3. Module Design
  4. Coding Conventions
  5. Support Status
  6. TODO

Clone this wiki locally