Digest · Simulation and emulation · read after Chapter 7
導讀 · 模擬與模擬平台 · 第 7 章後閱讀
xeoverse: A Real-time Simulation Platform for Large LEO Satellite Mega-Constellationsxeoverse：大型 LEO 衛星巨型星座的即時模擬平台
Real Linux software needs simulated network time to match the wall clock. xeoverse precomputes predictable topology and updates only changed links. Its ground-link validation and ISL-path experiments cover separate parts of the model.原版 Linux 軟體需要模擬網路時間與牆鐘同步。xeoverse 預先計算可預測的拓樸，執行時只更新有變化的鏈路。地面鏈路驗證與 ISL 路徑實驗各自涵蓋模型的一部分。
If you read nothing else
只讀這一段也可以
| Measure or comparison參數或比較項目 | Values, conditions and evidence數值、條件與證據 |
|---|---|
| Constellation configuration | Kassem and Sastry built xeoverse to run a full Starlink shell in real time. One simulated second takes one wall-clock second on a 26-core, 64 GB machine. Lightweight Mininet nodes represent satellites, user terminals and gateways. Unmodified Linux software includes iperf, ping, traceroute, BBR, CUBIC and HTTP/3. [80, §III] |
| Evaluation conditions | Predictable orbits permit offline topology and static Dijkstra computation. Runtime updates apply only changed inter-satellite and ground links. The default 1 s step can decrease to 1 ms. |
| Model configuration | On Starlink Shell 1, modeled as 72 planes of 22 satellites with a four-ISL grid of 5,346 ISLs |
| ISL rate and latency model | a fixed user-configured ISL capacity and propagation-only latency |
| Simulation runtime | the paper reports a total simulation time 2.9× shorter than Hypatia and 40× shorter than StarryNet |
| Ground-link throughput validation | bent-pipe throughput within 2% of a live Starlink terminal on clear days and within 16% in rain |
| London–San Francisco result | and a London–San Francisco path change from 18 to 21 hops that raised mean latency by 67.6%, which Hypatia failed to reproduce [80, §V, Figs. 3–6]. |
| Reporting and model scope | The caveats teach as much as the results. The update-phase figure gives 2.3×, while the abstract gives 2.9×. Pre-computation appears as 55 versus 162 min and as about twice Hypatia's time. The introduction claims a 5,442-satellite scale, while demonstrations reach only 1,584 satellites. The model omits the 15-second scheduler, laser setup delay and any measured ISL rate. |
| 星座配置 | Kassem 與 Sastry 打造 xeoverse，是為了即時執行一整個 Starlink 殼層，也就是在一台 26 核心、64 GB 的機器上，模擬的一秒只花牆鐘的一秒，讓 iperf、ping、traceroute、BBR、CUBIC 與 HTTP/3 等原版 Linux 工具，能在代表衛星、使用者終端與閘道的輕量 Mininet 節點上執行[80, §III]。 |
| 評估條件 | 方法是利用軌道的可預測性：離線預先計算拓樸與靜態 Dijkstra 路由，然後只套用有變化的星間與地面鏈路，預設步長 1 秒，可縮短到 1 ms。 |
| 軌道面配置 | 在 Starlink Shell 1 上，以 72 個軌道面、每面 22 顆衛星建模，採四條 ISL 的網格共 5,346 條 ISL、使用者設定的固定 ISL 容量與只計傳播的延遲，論文回報總模擬時間比 Hypatia 短 2.9 倍、比 StarryNet 短 40 倍，彎管吞吐量在晴天與真實 Starlink 終端相差 2% 以內、雨天 16% 以內，以及一條倫敦–舊金山路徑從 18 跳變為 21 跳、使平均延遲上升 67.6%，而 Hypatia 重現狀態仍待確認這一點（摘要、§V、Figs. 3–6）。 |
| 星座配置 | 這些附帶條件與結果一樣有教育意義：更新階段的圖給出的是 2.3 倍，相較之下摘要給出 2.9 倍，預先計算既被報告為 55 對 162 分鐘、又被說成約為 Hypatia 的兩倍，引言宣稱的 5,442 顆衛星規模展示範圍僅達 1,584 顆，而模型也省略了 15 秒排程器、雷射建鏈延遲與任何量得的 ISL 速率。 |
1. Where this paper sits1. 這篇論文的位置
Chapter 7 arranges the tools along a fidelity–scale trade-off, and xeoverse is an attempt to sit in a corner that its predecessors left empty. Other work has since used xeoverse, including the SpaceCDN study by Bose et al. [89]. SpaceCDN simulated satellite caching on Shell 1 in xeoverse.第 7 章把工具沿著保真度與規模的取捨排列，而 xeoverse 試圖佔據前人留下的空角落。Celestial[79]則以每顆衛星一個 Firecracker microVM 追求邊緣運算的真實性，搭配簡化的鏈路圖。xeoverse 保留了 StarryNet 執行真實協定堆疊的承諾，但以 Mininet 網路命名空間取代容器，並把拓樸工作移到離線，依本教材的解讀，這讓它很適合用真實核心做壅塞控制實驗，而對其支援較有限：路由協定研究，因為它的路由是靜態的（tools_transport 筆記，推論）。此後它也成為其他研究的基礎，尤其是 Bose 等人的 SpaceCDN 研究[89]，在 xeoverse 中於 Shell 1 上模擬了衛星快取。
| Measure or comparison參數或比較項目 | Values, conditions and evidence數值、條件與證據 |
|---|---|
| Model configuration | Hypatia [6] is an ns-3 packet simulator that runs its own protocol models. The tool scales to a full shell but runs slowly at high rates. Simulating one second of 9.2 Gbit/s TCP takes about 555 s. Thus, its transport results are all at 10 Mbit/s [80, §3–3.4] . |
| Constellation configuration | StarryNet [40] runs real software in a Docker container per node. It reached 4,408 satellites using seven servers and 21.2 min of setup. Celestial [79] uses a Firecracker microVM per satellite and a simplified link graph. The xeoverse design instead combines real stacks, Mininet namespaces and offline topology computation. The primer therefore sees it as suitable for real-kernel congestion-control experiments. Its static routes provide limited support for routing-protocol studies (tools_transport notes, inference). |
| 模型配置 | Hypatia[6]是一個 ns-3 封包模擬器，執行的是它自己的協定模型，因此能擴展到整個殼層，但在高速率下很慢：9.2 Gbit/s TCP 的一秒要花約 555 秒，這也是它的傳輸層結果全部停在 10 Mbit/s 的原因[6, §3–3.4]。 |
| 星座配置 | StarryNet[40]以每個節點一個 Docker 容器執行真實軟體，達到 4,408 顆衛星，但需要七台伺服器與 21.2 分鐘的建置。 |
2. The problem, measured2. 問題，用量測說話
The paper's case for a new tool is a set of scaling measurements on its two baselines. Real software follows the machine's clock. Kernel retransmission timers, BBR probes and application frame clocks advance independently of network-simulation progress. Thus, an emulator that runs slower than real time hands that software a network whose delays and rates are distorted in time.論文提出新工具的理由，是對兩個基準工具所做的一組擴展性量測。真實軟體依牆鐘時間運作，因為核心的重傳計時器、BBR 的頻寬探測與應用程式的幀時鐘都隨機器時鐘前進，周圍網路模擬的進度則獨立於這些時鐘，所以一個比即時慢的模擬平台，交給這些軟體的是一個延遲與速率在時間上被扭曲的網路。
| Measure or comparison參數或比較項目 | Values, conditions and evidence數值、條件與證據 |
|---|---|
| Constellation configuration | On the authors' measurements, Hypatia took 266.76 s to simulate 60 s of a 660-satellite constellation and 698 s at 1,584 satellites |
| StarryNet runtime | while StarryNet took up to 79 s to emulate a single second at 660 satellites |
| StarryNet threads | spawned 1,323 threads |
| Single-machine container limit | and reached a limit of about 1,023 containers on one machine because of a Linux bridge limit [80, §V-A, Figs. 3–4]. |
| Constellation configuration | At 660 satellites, Hypatia ran about 4.4 times slower than real time, and StarryNet reached 79 times slower (computed below). Both distorted timing for full-shell congestion-control experiments on one machine. |
| 星座配置 | 依作者的量測，Hypatia 模擬 660 顆衛星星座的 60 秒要 266.76 秒，在 1,584 顆衛星時要 698 秒。 |
| 星座配置 | StarryNet 在 660 顆衛星時模擬一秒最多要 79 秒，產生 1,323 個執行緒，而且受 Linux bridge 限制，在一台機器上上限約為 1,023 個容器[80, §V-A, Figs. 3–4]。 |
| 星座配置 | 因此在 660 顆衛星時，Hypatia 約比即時慢 4.4 倍，StarryNet 最多慢 79 倍（見下方計算），兩者在單機承載整個殼層的壅塞控制實驗時，皆會產生時序失真。 |
3. The design3. 設計
xeoverse rests on three ideas that all follow from the fact that orbits are predictable. The first is pre-computation. Before execution, xeoverse computes satellite positions, ground-link visibility and static Dijkstra routes for each time step. It also computes the four-ISL grid, with same-orbit-only ISLs available as an option.
The second mechanism is incremental update. Each step applies changed ISLs and ground links, then installs new routes as ordinary ip route entries. The default 1 s step can decrease to 1 ms. The third is focus. The simulator concentrates its work on links relevant to the simulated traffic [80, §III] . Each satellite, user terminal and gateway is a Mininet node.
These Linux network namespaces share the host kernel and cost less than containers or microVMs. Each link receives its propagation delay as latency. Ground-link capacity follows the Shannon formula, RF parameters, ITU Ku- and Ka-band channel models, and live OpenWeatherMap weather. These models add detail beyond the ISL model.
A terminal selects the nearest satellite or the satellite with the longest remaining visibility. In comparison, the ISL capacity is a single fixed value that the user configures [80, §III-B].
xeoverse 建立在三個想法上，而它們都源自軌道可預測這個事實。第一是預先計算：在執行開始前，就為每個時間步算好衛星位置、四條 ISL 的網格（或作為選項，只有同軌道面的 ISL）、地面鏈路可見性與靜態 Dijkstra 路由。第二是增量更新：即時迴圈在每一步只套用自上一步以來有變化的 ISL 與地面鏈路，並把新路由以一般的 ip route 項目安裝，預設步長 1 秒，可降到 1 ms。第三是聚焦：模擬器集中處理與模擬流量相關的鏈路，以減少維護其餘鏈路的成本[80, §III]。
每顆衛星、使用者終端與閘道都是一個 Mininet 節點，也就是共用主機核心的 Linux 網路命名空間，因此比容器或 microVM 便宜得多，而鏈路延遲設為各鏈路上的傳播延遲。地面鏈路的建模比 ISL 豐富：其容量由 Shannon 公式加上射頻參數、ITU Ku 與 Ka 頻段通道模型以及 OpenWeatherMap 的即時天氣得出，終端則連到最近的衛星或剩餘可見時間最長的衛星。相對地，ISL 容量是使用者設定的單一固定值[80, §III-B]。
Original figure note原始圖說出處
Drawn for this primer from Kassem & Sastry, arXiv 2406.11366 (IFIP Networking 2024), Abstract, §III, §V-A, Figs. 3–4.| Question | 問題 | Formula | 公式 | Result | 結果 |
|---|---|---|---|---|---|
| How many satellites are in the 72 × 22 Shell 1 model?72 × 22 的 Shell 1 模型有多少顆衛星？ | \( N = 72 \times 22 \) | 1,584 computed. Geometry from §III-B, the Aug 2019 filing used by most tools (factbase Part C item 12).計算值。幾何取自 §III-B，即多數工具採用的 2019 年 8 月申請（事實庫 Part C 第 12 項）。 | |||
| How many undirected links does a four-ISL grid on 1,584 satellites have?1,584 顆衛星的四 ISL 網格有多少條無向鏈路？ | \( L = \dfrac{1{,}584 \times 4}{2} \) | 3,168 computed. The paper prints 5,346 ISLs, which differs from both this count and the 6,336 directed-link count. The paper as read leaves the derivation open.計算值。論文印出 5,346 條 ISL，與此數及 6,336 條有向鏈路皆有差異，而所讀版本將其數字推導保留為待補。 | |||
| How much slower than real time was Hypatia at 660 satellites?在 660 顆衛星時，Hypatia 比即時慢多少？ | \( \dfrac{266.76\ \text{s}}{60\ \text{s}} \) | 4.4× computed from the run time reported in §V-A. StarryNet's "up to 79 s per simulated second" is 79× by the same measure.由 §V-A 回報的執行時間計算。StarryNet「每模擬一秒最多 79 秒」以同一尺度即為 79 倍。 | |||
| How much did the hop count grow on the London–San Francisco path, compared with the 67.6% latency rise?倫敦–舊金山路徑的跳數增加多少？與 67.6% 的延遲上升相比如何？ | \( \dfrac{21 - 18}{18} \) | +16.7% computed. Hops and latency from §V-B, Fig. 5. Latency grew four times faster than hop count, so the new route must also be geometrically longer.計算值。跳數與延遲取自 §V-B，Fig. 5。延遲增幅是跳數增幅的四倍，因此新路由在幾何上也必然更長。 | |||
| How far beyond the demonstrated scale is the 5,442-satellite claim?5,442 顆衛星的宣稱比已展示的規模超出多少？ | \( \dfrac{5{,}442}{1{,}584} \) | 3.4× computed. Claim from the introduction, largest experiment 1,584 satellites (factbase Part C item 44).計算值。宣稱取自引言，最大實驗為 1,584 顆衛星（事實庫 Part C 第 44 項）。 |
4. Evaluation setup4. 實驗設定
xeoverse is a simulator that runs real software, which the chapter classes with emulation, and its evaluation has three parts.xeoverse 是一個執行真實軟體的模擬器，本章把它歸在模擬平台一類，其評估分為三部分。
| Measure or comparison參數或比較項目 | Values, conditions and evidence數值、條件與證據 |
|---|---|
| Plane configuration | Scalability tests use Starlink Shell 1 with 72 planes of 22 satellites, at an unspecified altitude. Tests include 20–100 ground segments and 10–50 flows. One machine provides 26 cores and 64 GB RAM. Baselines are Hypatia (ns-3) and StarryNet (Docker). Celestial appears only in related work. [80, §V-A] |
| Latency comparison | The topology is a four-ISL grid with 5,346 ISLs and static Dijkstra routes. ISL latency includes pure propagation, with zero per-hop node delay. ISL capacity is fixed and configurable, with experimental values unspecified in the notes. Laser setup delay and the 15-second Starlink schedule lie outside the model. |
| Throughput | Fidelity runs compare bent-pipe downlink throughput from the simulator with a single live Starlink terminal on clear and rainy days [80, Fig. 6] . Case studies include a London–San Francisco ISL path. A Paris–Sydney flow fell from 77.3 to 8 Mbps at 51 s. [80, §V-B] |
| Memory | Pre-computation peaked at 57% CPU, about twelve times Hypatia's use. The update phase used 15.9% CPU and 8.5% memory. Hypatia used 31.8% memory. [80, Fig. 7] |
| 軌道面配置 | 擴展性實驗使用 72 個軌道面、每面 22 顆衛星的 Starlink Shell 1，其高度須查程式碼或設定，搭配 20–100 個地面節點與 10–50 條流，在一台 26 核心、64 GB 記憶體的機器上執行，以 Hypatia（ns-3）與 StarryNet（Docker）為基準，Celestial 只出現在相關研究中[80, §V-A]。 |
| 延遲比較 | 拓樸是 5,346 條 ISL 的四 ISL 網格，路由由靜態 Dijkstra 固定，ISL 延遲是純傳播延遲、逐跳節點延遲設定為零，ISL 容量是可設定的固定值，筆記記載實驗中數值仍待說明，雷射建鏈延遲及 Starlink 的 15 秒排程皆位於模型範圍之外。 |
| 吞吐量 | 保真度實驗把模擬器的彎管下行吞吐量與單一真實 Starlink 終端在晴天與雨天的結果比較[80, Fig. 6]，案例研究則追蹤一條經 ISL 的倫敦–舊金山路徑，以及一條吞吐量在第 51 秒從 77.3 降到 8 Mbps 的巴黎–雪梨流[80, §V-B]。 |
| 記憶體 | 資源使用也有量測：預先計算的 CPU 峰值為 57%，約是 Hypatia 的十二倍，更新階段使用 15.9% CPU 與 8.5% 記憶體，Hypatia 的記憶體則為 31.8%[80, Fig. 7]。 |
Original figure note原始圖說出處
Drawn for this primer from Kassem & Sastry, arXiv 2406.11366, §III-B, §V-B, Figs. 5–6. 3 terminals and undisclosed topology from factbase Part C items 13 and 55.5. What was measured5. 量到了什麼
| Claim宣稱 | Setup and caveat設定與附註 |
|---|---|
| Total simulation time 2.9× shorter than Hypatia and 40× shorter than StarryNet (Abstract)總模擬時間比 Hypatia 短 2.9 倍、比 StarryNet 短 40 倍（摘要） | The update-phase figure gives 2.3× against Hypatia [80, Fig. 3]. Scale up to 1,584 satellites更新階段的圖對 Hypatia 給出 2.3 倍[80, Fig. 3]。規模最多 1,584 顆衛星 |
| Pre-computation 55 min vs 162 min for Hypatia at 100 ground segments and 50 flows [80, Fig. 4]在 100 個地面節點與 50 條流下，預先計算 55 分鐘對 Hypatia 162 分鐘[80, Fig. 4] | §V-A also says xeoverse's pre-compute is "approximately 2 times higher" than Hypatia's§V-A 也說 xeoverse 的預先計算比 Hypatia「高約 2 倍」 |
| Bent-pipe throughput within 2% of live Starlink on clear days, 16% in rain [80, Fig. 6]彎管吞吐量晴天與真實 Starlink 相差 2% 以內、雨天 16%[80, Fig. 6] | One terminal. Rain accuracy limited by ITU models. ISL paths validation pending單一終端。雨天準確度受 ITU 模型限制。ISL 路徑驗證仍待完成 |
| London–San Francisco hops 18 → 21 raise mean latency 67.6%, outside the changes Hypatia reproduced [80, §V-B, Fig. 5]倫敦–舊金山 18 → 21 跳使平均延遲上升 67.6%，Hypatia 的重現結果範圍之外[80, §V-B, Fig. 5] | Static Dijkstra on a 4-ISL grid. ISL path validation requires measured ground truth四 ISL 網格上的靜態 Dijkstra。ISL 路徑真實基準待補 |
| Paris–Sydney throughput 77.3 → 8 Mbps at 51 s after a path change [80, §V-B]巴黎–雪梨吞吐量在第 51 秒路徑改變後從 77.3 降到 8 Mbps[80, §V-B] | Depends on the configured ISL capacity, whose value is absent from the record取決於設定的 ISL 容量，實驗數值須另查來源 |
| StarryNet up to 79 s per simulated second at 660 satellites, 1,323 threads, ~1,023-container limit. Hypatia 266.76 s per 60 s at 660 and 698 s at 1,584 [80, §V-A]StarryNet 在 660 顆衛星時每模擬一秒最多 79 秒、1,323 個執行緒、約 1,023 個容器上限。Hypatia 在 660 顆時每 60 秒要 266.76 秒、1,584 顆時 698 秒[80, §V-A] | Third-party measurements of competing tools by the xeoverse authors, on their hardware由 xeoverse 作者在自己的硬體上對競爭工具所做的第三方量測 |
| Update phase 15.9% CPU and 8.5% memory vs Hypatia's 31.8% memory. Pre-compute CPU peak 57%, ~12× Hypatia [80, Fig. 7]更新階段 15.9% CPU 與 8.5% 記憶體，Hypatia 記憶體 31.8%。預先計算 CPU 峰值 57%，約為 Hypatia 的 12 倍[80, Fig. 7] | Single 26-core, 64 GB machine單一 26 核心、64 GB 機器 |
6. Limits and open questions6. 限制與待解的問題
- The headline numbers are internally inconsistent. The abstract gives a 2.9× speedup over Hypatia, while the update-phase figure gives 2.3×. Pre-computation is 55 versus 162 min in Fig. 4. Section V-A instead calls it 'approximately 2 times higher' than Hypatia's. The introduction claims 5,442 satellites, while tests reach 1,584. Shell 1 has 5,346 printed ISLs, compared with 3,168 in a four-ISL grid (calculation table). The fact base records the first three as Part C item 44 and directs authors to quote both values with their locations.主要數字內部差異。摘要中對 Hypatia 的 2.9 倍加速，在更新階段的圖中變成 2.3 倍。預先計算在 Fig. 4 是 55 對 162 分鐘，在 §V-A 卻比 Hypatia「高約 2 倍」。引言宣稱的 5,442 顆衛星能力測試範圍僅達 1,584 顆。而 Shell 1 印出的 5,346 條 ISL 也與四 ISL 網格的 3,168 條鏈路存在差異（見計算表）。事實庫把前三項記為 Part C 第 44 項，並要求作者引用兩個數值及其出處。
- Validation covers the part that uses ground links exclusively. The 2% and 16% agreement covers bent-pipe downlink throughput from one terminal. Ground-link capacity follows RF and weather models. ISL results show a 67.6% latency rise and a throughput collapse from 77.3 to 8 Mbps. Their validation requires ground truth. They depend on fixed ISL capacity, grid topology and static routing selected by the model or user. A disagreement with Hypatia on such a path is therefore a disagreement between two models. This is the shared blind spot that Cionca et al. summarise as "none of the existing satellite constellation emulators can match real-world measurements" preprint .驗證涵蓋的是僅採地面鏈路 的部分。2% 與 16% 的吻合比較的是單一終端的彎管下行吞吐量，其地面鏈路容量由射頻與天氣模型計算。而使 xeoverse 與 Hypatia 呈現差異的 ISL 路徑結果，也就是 67.6% 的延遲上升與 77.3 降到 8 Mbps 的吞吐量崩落，真實基準仍待補充，且取決於使用者或模型所選的固定 ISL 容量、網格拓樸與靜態路由。因此在這種路徑上與 Hypatia 的分歧，是兩個模型之間的分歧，也正是 Cionca 等人所總結的共同盲點：「現有的衛星星座模擬平台沒有一個能吻合真實世界的量測」預印本。
- Outdated topology assumptions. The four-ISL grid follows the 2018 filing. Starlink satellites carry three laser terminals. The in-orbit topology remains proprietary (factbase Part C items 13 and 55). The ISLs are instantly reconfigurable, which ignores the 2–30 s laser setup time recorded for modern terminals (Part C items 18 and 56). Static Dijkstra routes fix routing behavior outside protocol convergence dynamics. This limits the tool for the routing questions of Chapter 5.過時的拓樸假設。四 ISL 網格沿用 2018 年的申請，而 Starlink 衛星搭載三個雷射終端，在軌拓樸仍屬專有資訊（事實庫 Part C 第 13 與 55 項）。ISL 被視為可瞬間重組，忽略了現代終端 2–30 秒的雷射建鏈時間（Part C 第 18 與 56 項）。靜態 Dijkstra 路由將路由協定收斂與錯誤行為排除於模型之外，限制了這個工具在第 5 章路由問題上的用途。
- Scheduler behavior and measured ISL rate remain open. The model excludes the 15-second reconfiguration that dominates Starlink transport behavior. Thus, a congestion-control study on xeoverse must script it, as only LeoEM among the emulators does by default (Part C item 57). ISL capacity uses one value whose source remains open. SpaceX separately claims 100 Gbps sustained and 200 Gbps peak per laser, a company statement (Part C items 14 and 60). Throughput results over ISLs are therefore illustrations of dynamics, with prediction accuracy requiring separate validation.排程器行為與實測 ISL 速率仍待補充。在 Starlink 上主導傳輸協定所見現象的 15 秒重組位於模型範圍之外，所以在 xeoverse 上做壅塞控制研究必須自行加入腳本，而模擬平台中只有 LeoEM 預設具備這一點（Part C 第 57 項）。ISL 容量是一個來源仍待確認的單一數值，對照 SpaceX 宣稱的每具雷射持續 100 Gbps、峰值 200 Gbps 公司（Part C 第 14 與 60 項）。因此經 ISL 的吞吐量結果是動態的示意，預測準確度則須另行驗證。
- Baselines measured by the authors. The xeoverse authors measured StarryNet and Hypatia on their own hardware. StarryNet's original paper used seven servers, while this benchmark uses one and excludes Celestial. The 40× comparison therefore reflects a single-machine constraint that favors the proposed design. The venue is taken from the IFIP digital-library listing rather than from the paper text. The numbers here come from the arXiv version.基準由作者自行量測。StarryNet 與 Hypatia 的執行時間由 xeoverse 作者在自己的硬體上量得，StarryNet 原論文使用七台伺服器，對照本文的單機設定，Celestial 則位於評測範圍之外，所以 40 倍這個數字是在有利於被提出設計的單機限制下比較工具。發表場合取自 IFIP 數位圖書館的列表，論文正文則須另行核對，此處數字則來自 arXiv 版本。
7. How it connects7. 與其他內容的關聯
- Section 7.4 lists xeoverse with fixed ISL capacity, setup delay outside the model and the 15-s schedule outside the model. Figure 7.1 places its 2.9×/40× speedups on the fidelity–scale map.第 7.4 節：xeoverse 是模擬平台能力表中的一列，包括其固定 ISL 容量、缺席的建鏈延遲與 15 秒排程，而 2.9 倍/40 倍的加速則位於圖 7.1 的保真度–規模地圖上。
- Section 7.5 : the shared blind spot. The London–San Francisco comparison tests two modeling choices against each other. Public SpaceX evidence is still needed for laser rate, topology and scheduling.第 7.5 節：共同的盲點，因為倫敦–舊金山與 Hypatia 的分歧，是兩組建模選擇之間的較量，對象是一個速率、拓樸與排程器仍待 SpaceX 公開資料的的雷射網路。
- Section 7.3: Hypatia's 555 s per second of 9.2 Gbit/s TCP is the cost that motivates a real-time design.第 7.3 節：Hypatia 模擬 9.2 Gbit/s TCP 一秒要 555 秒，正是促成即時設計的代價。
- Section 5.7: the table of what topology papers assume, where xeoverse joins the tools that still model a four-ISL grid with instant links.第 5.7 節：拓樸論文假設的整理表，xeoverse 在此與其他仍以瞬時鏈路建模四 ISL 網格的工具並列。
- Section 6.1 explains real-time experiments with kernel BBR or CUBIC. Reproducing measured capacity and RTT swings requires adding the 15-s step.第 6.1 節：即時工具能跑核心層的 BBR 或 CUBIC，重現量測結果時須加入 15 秒階躍，涵蓋該章量測到的 RTT 擺盪。
- Sibling digests cover Hypatia and StarryNet as baselines, and Celestial as the microVM alternative outside the benchmark. SaTCP / LeoEM uses Mininet and models the 15-s schedule. SpaceCDN uses xeoverse to simulate caching.同組導讀：Hypatia 與 StarryNet 是兩個基準，Celestial 是它評測範圍之外的 microVM 替代方案，SaTCP / LeoEM 是另一個 Mininet 即時模擬平台，也是確實建模 15 秒排程的那一個，SpaceCDN 則是快取結果在 xeoverse 中模擬得出的研究。
Key numbers關鍵數字
| Number | 數字 | Meaning (setup) | 意義（設定） |
|---|---|---|---|
| 1 s = 1 s | Real time: one simulated second per wall-clock second, step 1 s default down to 1 ms [80, §III] | 即時：牆鐘每一秒模擬一秒，預設步長 1 秒、可降到 1 ms[80, §III] | |
| 72 × 22 · 5,346 | Shell 1 planes × satellites. ISLs printed for the four-ISL grid (§III-B. 3,168 by computation) | Shell 1 軌道面數 × 每面衛星數。四 ISL 網格印出的 ISL 數（§III-B。計算得 3,168） | |
| 2.9× · 40× | Total-time speedup over Hypatia and StarryNet (Abstract). 2.3× over Hypatia for the update phase [80, Fig. 3] | 相對 Hypatia 與 StarryNet 的總時間加速（摘要）。更新階段對 Hypatia 2.3 倍[80, Fig. 3] | |
| 2% · 16% | Bent-pipe throughput error against one live Starlink terminal, clear vs rain [80, Fig. 6] | 相對單一真實 Starlink 終端的彎管吞吐量誤差，晴天對雨天[80, Fig. 6] | |
| 18 → 21 · +67.6% | London–San Francisco hop change and mean-latency rise, outside the changes Hypatia reproduced [80, §V-B] | 倫敦–舊金山的跳數變化與平均延遲上升，Hypatia 的重現結果範圍之外[80, §V-B] | |
| 55 vs 162 min | Pre-computation, xeoverse vs Hypatia, 100 ground segments and 50 flows [80, Fig. 4], contradicted in §V-A | 預先計算時間，xeoverse 對 Hypatia，100 個地面節點與 50 條流[80, Fig. 4]，與 §V-A 矛盾 | |
| 1,584 vs 5,442 | Largest demonstrated vs claimed satellite count (factbase Part C item 44) | 最大已展示衛星數對宣稱衛星數（事實庫 Part C 第 44 項） | |
| 79 s · ~1,023 | StarryNet time per simulated second at 660 satellites, and its per-machine container limit, as measured by the xeoverse authors [80, §V-A] | StarryNet 在 660 顆衛星時每模擬一秒所需時間，以及其單機容器上限，由 xeoverse 作者量測[80, §V-A] | |
| 26 cores · 64 GB | The single machine that hosts every experiment [80, §V-A] | 承載所有實驗的單一機器[80, §V-A] |