要約

  • RFC 9699 はモバイル XR を、追跡、実世界モデル取得、位置合わせ、画像生成、伝送、表示が動く利用者を共に追う結合パイプラインとして扱う。
  • エッジへのオフロードは発熱と電池負荷を軽くするが、無線変動、待ち行列、実行、返送が同じ motion-to-photon 予算を使う。近さや平均値は end-to-end の受領証ではない。
  • RFC は運用パラメータの heavy tail と burst を想定する。各表示フレームを姿勢、モデル状態、計算、実体験へ結ぶ tail-aware な証拠が必要だ。

正常な平均の内側でずれた一枚

XR ヘッドセットを着けた来館者がアーチへ顔を向ける。直近一分の device-to-edge 平均は 11 ms。大半のフレームは滑らかだが、一枚だけが短い edge burst の後ろで待つ。送信時には正しかった頭・眼の姿勢は、返着時には古い。重ねる像はアーチの上ではなく横へ落ちる。

平均値は誤っていない。ただし、必要な証拠ではない。

2024年12月公開の IETF Informational 文書 RFC 9699 は、ロンドン塔を歩く観光客に歴史的な 3D 場面を重ねる用例を置く。処理は一個の「計算」ではない。tracking、実世界モデルの acquisition、registration が連続する。tracking は頭、眼、視野内の物体の六次元 pose を扱う。モデルは client-side mapping と server-side localisation を組み合わせ得る。registration は座標、明るさ、色を合わせ、occlusion、lens distortion、blur、noise も処理する。最後の situated visualisation は眼と頭の動きに temporal coherence を保たなければならない。

オフロードの価値と負債は同じ場所にある。リアルタイム映像処理と新規フレーム生成は端末を熱くし、電池を消費する。遠隔 cloud は引用された millisecond 級期限に遠すぎるため、計算を近い edge へ移す。しかし workload は消えず、端末、radio path、admission/queue、CPU/GPU、model store、return transport、display に分割される。

一つの期限に複数の時計

RFC がこの用例に引用する motion-to-photon は最大 20 ms、望ましくは 7–15 ms。display refresh と pixel switching が 12–13 ms を使い、sensor processing、rendering、device-edge RTT に残るのは 7–8 ms とする。これは全製品への保証ではない。重要なのは、network delay を compute time や pose age から切り離せないという算術だ。

オフロードの response time は computation と RTT の合計である。radio が目標を満たしても GPU queue が体験を壊せる。edge 実行が速くても、visual feature の追加 upload が uplink を延ばせる。最寄り site を選んでも world model が cold かもしれない。network SLO 内の frame でも、古い geometry や pose に登録され得る。どれも真実だが、次の層の代用にはならない。

移動は境界そのものを変える。無線帯域と遅延は変動し、link は失敗し、software component 間の論理関係も頻繁に変わる。edge は remote cloud より資源が少なく、団体客の集中で飽和する。「近い」とは、地図距離や導入時 hop count ではなく、その時点で要件を満たす短く大容量の path である。

tail も製品である

RFC は buffer occupancy、throughput、client-server latency、variable transmission time が heavy-tailed になり得るとし、sample mean の安定が遅く、variance や standard deviation が不適切な場合を警告する。大きな burst と長い gap、long-range dependence、self-similarity、millisecond 級 burstiness も扱う。6DoF video/point cloud の例は 200–1000 Mbps。burst と可変 queueing が jitter を生み、motion sickness に寄与し得る。

全 XR trace が同じ分布だという証明ではない。しかし平均だけの承認は否定される。11 ms の mean と、所属すべき pose を失った少数 frame は両立する。しかも handover、crowd arrival、model fetch、GPU contention という連続性が重要な瞬間に集中し得る。

受領証は frame identity から始める。sensor sample と timestamp、offload decision、radio/handover、admission/queue/execution、model と scene-state version、render completion、downlink、最終 registration の pose、display presentation、QoE を保存する。not observed は正当な状態であり、「edge success」で空欄を埋めてはならない。

RFC は dynamic placement、mobility support、energy management など managed edge-cloud の機能を示し、DetNet、reliable wireless、DiffServ、per-connection QoS も候補に挙げる。同時に economic viability を課題として残す。普遍的な frame receipt、特定 deployment の認証、prediction による不快感防止、地理的近接による tail 保証は与えない。結論は限定的だ。結合した経路全体を一つの製品として運用して初めて、XR の連続性を検証できる。

情報源

一次記録：RFC 9699、RFC Editor、IETF Datatracker、RFC 8939、RFC 9023、RFC 9450、3GPP XR study。編集上の公開レンズ：reality, not advocacy。