Chapter 7 of 13 · Part II · The research

第 7 章（共 13 章）· 第二部 · 研究

Tools of the trade: measurement campaigns, simulators and emulators研究工具：量測活動、模擬器與模擬平台

This chapter distinguishes measurement, packet simulation and emulation, and places the main LEO tools by fidelity and scale. You will identify their link and scheduling assumptions, estimate experimental cost, and assess simulated results before citation.本章區分量測、封包模擬與模擬平台，並依逼真度與規模定位主要 LEO 研究工具。你會辨識它們的鏈路與排程假設、估計實驗成本，並在引用前檢查模擬結果的適用範圍。

≈ 29 min · 1 panel · 8-question quiz≈ 29 分鐘 · 1 個面板 · 8 題測驗Jump to the quiz ↓跳到測驗 ↓

Before you start

開始之前

This chapter builds on Chapters 1, 2, 3 and 6. The tools use constellation geometry, link models, node and acquisition delays, and ground PoPs. Chapter 6’s transport studies also use the path emulator introduced here. Each term links to its definition.

本章延續第 1、2、3、6 章，使用星座幾何、鏈路模型、節點與擷取延遲，以及地面 PoP。第 6 章的傳輸研究也採用本章介紹的路徑模擬平台，各名詞的連結可帶你回到定義。

Walker patternWalker 星座1 +Grid+Grid2 Node delay節點延遲2 Acquisition擷取2 15-second reconfiguration15 秒重組週期3 PoPPoP3 Path emulator路徑模擬平台6

New terms in this chapter (6)本章新名詞（6）

Each link opens the term’s first definition.

每個名詞都在它第一次出現的段落中定義，點連結可跳過去。

Packet simulator封包模擬器 Software that advances a model network event by event in simulated time, with every protocol and link written as a model. 在模擬時間中逐一事件推進模型網路的軟體，每一個協定與鏈路都是寫出來的模型。
Emulator模擬平台（emulator） A testbed that runs original operating systems and applications in real time over links whose delay and rate are imposed by a model.以即時方式執行原版作業系統與應用程式，並用模型設定鏈路延遲與速率的測試平台。
Digital twin數位孿生 An emulation whose constellation, ground stations and link states are built from real data such as filings and TLEs. 由申報文件與 TLE 等真實資料建構星座、地面站與鏈路狀態的模擬平台。
Vantage point觀測點 A host from which measurements of the network are taken. 對網路進行量測的那一台主機。
TLE兩行軌道根數（TLE） Two-line element set: the public text format of a satellite's orbital elements at an epoch. 兩行軌道根數：某顆衛星在某個曆元時刻軌道根數的公開文字格式。
SGP4SGP4 The standard propagator that turns a TLE into a position and velocity at any later time. 把 TLE 轉換成之後任意時刻位置與速度的標準軌道推算器。

7.1Three ways to get a number: measure, simulate, emulate取得數字的三種方式：量測、模擬、模擬平台

Recall

回顧

Section 5.7 records the topology papers’ filing, terminal and instant-setup assumptions, with scheduling outside their models. Section 3.5 explains the measured fifteen-second reconfiguration. Section 6.3 describes event-aware controller evaluations in emulation and replay.

第 5.7 節記錄拓樸研究採用的申報、終端數與即時建立假設，排程則在模型範圍之外。第 3.5 節說明實測發現的十五秒重配，第 6.3 節則介紹感知事件控制器的模擬與重播評估。

The instrument determines what a quantitative claim measures. Measurement observes the deployed scheduler, queues and PoP placement from attached hosts, while operator configuration and satellite internals remain outside its control. A packet simulator advances coded links, queues and protocols through simulated events, giving control and repeatability within the mechanisms its authors implement. An emulator runs existing operating systems, routing daemons and applications in real time over modeled virtual links. Its software is real, while constellation geometry, delay and capacity still come from a model.

工具決定量化論斷衡量的範圍。量測由連上已部署網路的主機觀察排程器、佇列與 PoP，組態仍由營運商控制，衛星內部也在觀測範圍之外。封包模擬器在模擬時間中推進程式化的鏈路、佇列與協定事件，提供可控制、可重現的實驗，範圍由作者實作的機制決定。模擬平台則在模型化的虛擬鏈路上即時執行原版作業系統、路由常駐程式與應用程式。受測軟體是真實的，星座幾何、延遲與容量仍來自模型。

Figure 7.1 maps the trade between fidelity and scale. Measurement reaches the locations of its vantage points and observes the operator’s chosen topology. Packet simulation supports whole constellations and hypothetical designs, with cost growing with processed packets and realism defined by its models. Emulation retains a real network stack but uses memory and CPU for each node. The largest published examples therefore need several servers for a shell or constellation.

圖 7.1 呈現逼真度與規模的取捨。量測的地理範圍由觀測點位置決定，觀察的是營運商選定的拓樸。封包模擬可研究整個星座與假想設計，成本隨封包事件數成長，逼真度則由模型界定。模擬平台保留真實網路堆疊，但每個節點都占用記憶體與 CPU，因此最大規模的已發表案例需要多台伺服器支撐殼層或星座。

Figure 7.1. Fidelity and scale. Vertical placement is ordinal: measurement, emulation, then simulation. StarryNet runs routing daemons on a data-based digital twin, while hollow Celestial represents a star-shaped emulated network. The horizontal axis counts modeled satellites for tools and vantage points for measurement. HitchHiking’s 2,400 endpoints and the IPv6 scan’s 5.98 million routers observe one deployed network. StarryNet’s 4,408 containers instead represent satellites in a model.圖 7.1。逼真度與規模。縱軸依量測、模擬平台、封包模擬排列，代表序位。StarryNet 在真實資料建構的數位孿生上執行路由程式，Celestial 空心標記則表示星狀的模擬網路。橫軸對工具計算模型衛星數，對量測計算觀測點數。HitchHiking 的 2,400 個端點與 IPv6 掃描的 598 萬台路由器觀察同一已部署網路，StarryNet 的 4,408 個容器則代表模型中的衛星。Sources來源: ^{[6, §3.4]} ^{[40, Tab. 2]} ^{[79, §4]} ^{[80, §V]} ^{[67, §IV]} ^{[35, §6]} ^[50] ^[26] ^[81]

Original figure note原始圖說出處

Drawn for this primer from Kassing et al., IMC 2020, §3.4, Lai et al., NSDI 2023, Table 2, Pfandzelter & Bermbach, Middleware 2022, §4, Kassem & Sastry, IFIP Networking 2024, §V, Cao & Zhang, INFOCOM 2023, §IV, Izhikevich et al., SIGMETRICS 2024, §6, Zhao & Pan, MMSys 2024, Wang et al., arXiv 2412.18243 (preprint), Cionca et al., arXiv 2604.04498 (preprint).

Each method has an observation boundary. External probes measure RTT and can infer ISL use from delay, while satellite identities, laser hops and separate space–gateway queues require additional evidence. Simulation exposes only implemented mechanisms, which is why measurement first discovered the fifteen-second schedule. Emulation also abstracts the physical layer. StarryNet’s authors describe virtualization’s “limited ability to emulate physical layer (PHY) characteristics” ^{[40, §8]}. Figure 7.2 marks where observation gives way to modeling assumptions.

各種方法都有觀測邊界。外部探測可量測 RTT，並依延遲推論 ISL 使用情形，衛星身分、雷射跳數與太空、閘道的各佇列則需要額外證據。模擬只呈現已實作的機制，因此十五秒排程最先由量測發現。模擬平台也會抽象化實體層，StarryNet 作者稱虛擬化「模擬實體層（PHY）特性的能力有限」^{[40, §8]}。圖 7.2 標出觀測轉為建模假設的環節。

TLE and SGP4 supply the geometry behind simulation and emulation. Their position errors and update cadence also bound the timing precision of predicted events.

TLE 與 SGP4 提供模擬背後的幾何，位置誤差與更新頻率也界定事件預測的時間精度。

Orbital input formats and update assumptions
#	Reported values and conditions
1	Simulation and emulation both need an orbit for every satellite.
2	A TLE, or two-line element set, publishes mean orbital elements at a stated epoch. SGP4 converts it to later positions and velocities, including major perturbations such as oblateness and drag.
3	Hypatia creates TLEs from filing elements with WGS72 constants and checks positions against pyephem ^{[6, §3]}.
4	Celestial updates SGP4 positions every 2 s in its first evaluation and every 5 s in its second ^{[79, §4–5]}.
5	StarryNet collects public TLEs and warns that their errors can reach 12 km ^{[40, §8]}.
6	SaTCP shows their timing value: about 90% of handover errors fall within ±0.6 s despite three-hour public-data refreshes ^{[67, §V-B, Fig. 4]}.

軌道輸入格式與更新假設
#	數值、條件與證據
1	模擬器與模擬平台都需要各顆衛星的軌道。
2	TLE，即兩行軌道根數，公布指定曆元的平均軌道元素。
3	SGP4 將它轉為後續位置與速度，納入地球扁率、大氣阻力等主要攝動。
4	Hypatia 用 WGS72 常數把申報元素轉成 TLE，並與 pyephem 核對 ^{[6, §3]}。
5	Celestial 兩組評估各每 2 s、5 s 更新 SGP4 位置 ^{[79, §4–5]}。
6	StarryNet 收集公開 TLE，提醒誤差可能達 12 km ^{[40, §8]}。
7	SaTCP 展示了時間預測的用途：即使資料每三小時更新，約 90% 換手誤差仍落在 ±0.6 s ^{[67, §V-B, Fig. 4]}。

Figure 7.2. Three experimental pipelines. Thick amber outlines mark quantities modeled in place of externally observable operator details. Measurement observes the deployed network directly, with configuration controlled by the operator.圖 7.2。三條實驗流程。粗琥珀色外框標示以模型代替外界可觀測營運細節的環節。量測直接觀察已部署網路，其組態則由營運商控制。Sources來源: ^{[35, §4–5]} ^{[6, §3]} ^{[40, §4]} ^{[79, §3–4]} ^[57]

Original figure note原始圖說出處

Drawn for this primer from Izhikevich et al., SIGMETRICS 2024, §4–5, Kassing et al., IMC 2020, §3, Lai et al., NSDI 2023, §4, Pfandzelter & Bermbach, Middleware 2022, §3–4, Casparsen et al., arXiv 2601.08439 (preprint).

7.2Measurement platforms: dishes, Atlas, HitchHiking, LENS and IPv6 scans量測平台：碟形天線、Atlas、HitchHiking、LENS 與 IPv6 掃描

Recall

回顧

Section 3.4 gathers 2022–2025 measurements: idle RTT medians fell from 40–50 ms toward 25 ms, with roughly 10:1 download/upload rates. Section 3.3 explains PoP-driven 100–181 ms delays for laser-dependent users, including Nigeria and Seychelles.

第 3.4 節彙整了 2022–2025 年實測的 Starlink 數字，從由 40–50 ms 降向 25 ms 的閒置 RTT 中位數，到 10:1 的下載/上傳差距，第 3.3 節則解釋了為什麼依賴雷射鏈路的使用者，例如奈及利亞或塞席爾的使用者，會因為他們 PoP 的位置而看到 100–181 ms。

Owned dishes provide direct measurements but limited geography. LENS extends the record across PoPs and includes an ISL-dependent site whose PoP change exposes routing effects.

自有天線提供直接量測，地理範圍則有限。LENS 擴展跨 PoP 紀錄，依賴 ISL 的站點也透過 PoP 變更揭露路由效應。

Owned dishes and the LENS dataset
#	Reported values and conditions
1	An owned dish provides a direct vantage point.
2	Five months of Belgian QUIC transfers and RIPE Atlas pings exposed 0.40–1.96% Starlink loss against a nearly loss-free control ^{[48, §3]}.
3	LENS expands geography to 13 dishes and 7 PoPs: Seattle, New York, Chicago, Denver, Dallas, Frankfurt and Lagos.
4	Since November 2023 it records RTT, one-way delay and obstruction maps across three continents ^[50].
5	Its Seychelles dish relies entirely on lasers because the nearest ground station lies beyond 5,000 km.
6	On 8 December 2023, its PoP moved from Lagos to Frankfurt.
7	Minimum RTT rose, attributed to a longer European laser path, while variability fell ^{[50, §3.2, §4.4, Fig. 6]}.
8	This ISL-path observation comes from one dish.

自有天線與 LENS 資料集
#	數值、條件與證據
1	研究者自有的天線提供直接觀測點。
2	比利時五個月的 QUIC 與 RIPE Atlas ping 顯示 Starlink 遺失率 0.40–1.96%，對照路徑則接近零 ^{[48, §3]}。
3	LENS 擴展至三大洲 13 具天線、7 個 PoP：西雅圖、紐約、芝加哥、丹佛、達拉斯、法蘭克福與拉哥斯，自 2023 年 11 月持續記錄 RTT、單向延遲與遮蔽圖 ^[50]。
4	其塞席爾天線因最近地面站超過 5,000 km，完全依賴雷射。
5	2023 年 12 月 8 日，PoP 從拉哥斯移至法蘭克福，最小 RTT 上升，作者歸因於歐洲雷射路徑變長，變異則下降 ^{[50, §3.2, §4.4, Fig. 6]}。
6	這項 ISL 路徑觀察來自單一天線。

Shared platforms expand geography under participant-selected placement and test conditions. Their breadth complements owned dishes, while sampling cadence limits the events they resolve.

共享平台在參與者決定的位置與條件下擴展地理覆蓋，可補充自有天線，取樣頻率則界定可解析事件。

RIPE Atlas and M-Lab coverage
#	Reported values and conditions
1	Shared platforms extend geographic reach while leaving probe placement and timing to participants.
2	RIPE Atlas had 58 probes in 2023 ^{[35, §6.1.3]}, 98 in Mohan et al.’s 21-country study ^{[49, §3]}, and about 150 by mid-2024 ^[55].
4	Sampling is at most once per minute, and volunteers determine placement.
5	Izhikevich’s nearest Atlas Starlink probe was over 300 miles from the tested PoP (§6.1.3).
6	Mohan et al. added 19.2 million M-Lab tests from 34 countries (§3), gaining breadth under externally chosen test conditions.

RIPE Atlas 與 M-Lab 覆蓋
#	數值、條件與證據
1	共享平台擴大地理範圍，探針位置與量測時機則由參與者決定。
2	RIPE Atlas 在 2023 年有 58 個 Starlink 探針 ^{[35, §6.1.3]}，Mohan 等人的研究含 21 國 98 個 ^{[49, §3]}，2024 年中約有 150 個 ^[55]。
3	它最多每分鐘取樣一次，位置取決於志願者。
4	Izhikevich 測試的 PoP 距最近 Atlas Starlink 探針也超過 300 英里（§6.1.3）。
5	Mohan 等人另以 34 國、1,920 萬筆 M-Lab 測速補充（§3），取得更廣覆蓋，同時承接外部決定的測試條件。

HitchHiking subtracts terrestrial delay from externally probed customer paths. Its validation supports latency inference within the reachable exposed-service population.

HitchHiking 從外部探測的用戶路徑扣除地面延遲，驗證支持其對可達開放服務族群的延遲推論。

HitchHiking: method, accuracy and coverage
#	Reported values and conditions
1	HitchHiking measures Starlink from outside its network.
2	Censys finds exposed services in AS14593, reverse DNS selects customer addresses, and filtering removes performance-enhancing proxies.
3	Traceroute identifies the hops before and after the satellite segment.
4	Subtracting TTL-limited ping RTTs isolates the satellite portion (Izhikevich et al., Proc.
5	ACM Meas.
6	Anal.
7	Comput.
8	Syst. 8(1), SIGMETRICS 2024, §4–5).
9	The study covers about 2,400 customer addresses across 13 countries and 20 PoP cities.
10	Against a San Diego ground-truth dish, 96% of estimates fall within one standard deviation, about 10 ms, and half within 3 ms.
11	It captures every sustained spike with one false positive in about 10,000 s (§6.1).
12	The paper describes Hypatia accuracy gains as “up to 80%” and “1.8×”.
13	Atlas coverage comparisons use “an order of magnitude”, “>10×” and “28×”.
14	The method-specific figures are 1.8× and 28× (§6.1.2–6.1.3).
15	Coverage reaches about 0.1% of roughly two million customers, limited to exposed services.
16	Measurements provide latency, while MPLS internals and satellite or ground-station identities remain outside their scope (§8).

HitchHiking 的方法、準確度與覆蓋
#	數值、條件與證據
1	HitchHiking 從網路外部量測 Starlink。
2	它用 Censys 找出 AS14593 中的開放服務，以反向 DNS 選出用戶位址，再移除效能增強代理。
3	Traceroute 找出衛星段前後的跳點，將限制 TTL 的 ping RTT 相減，以分離衛星段 ^{[35, §4–5]}。
4	研究涵蓋 13 國、20 個 PoP 城市後方約 2,400 個位址。
5	對照聖地牙哥真值天線，96% 估計落在一個標準差、約 10 ms 內，一半落在 3 ms 內。
6	所有持續尖峰皆被捕捉，約 10,000 s 有一次誤報（§6.1）。
7	論文對 Hypatia 用「最多準確 80%」與「1.8 倍」，對 Atlas 用「多一個數量級」、「超過 10 倍」與「28 倍」。
8	與明確方法相連的數字是 1.8 倍與 28 倍（§6.1.2–6.1.3）。
9	它涵蓋約兩百萬用戶的 0.1%，限於開放服務者，提供延遲觀察，MPLS 內部、衛星與地面站身分仍在其範圍之外（§8）。

Address scanning and high-frequency probing answer separate questions about network coverage and event timing. Both reveal deployed behavior while leaving direct laser measurements open.

位址掃描與高頻探測依序回答覆蓋與事件時序問題，兩者揭露部署行為，直接雷射量測則仍待完成。

IPv6 census and high-frequency probing
#	Reported values and conditions
1	Newer methods extend scale and temporal resolution.
2	Wang et al. scanned GeoIP-derived IPv6 /56 prefixes with XMap.
3	On 29 December 2025 they found 5,975,440 active routers across 208 regions in 165 countries, identified 49 PoPs, and inferred 98 backbone links.
4	Six dishes supported the inter-PoP inference ^{[26, §III]}.
5	Casparsen et al. instead sampled one dish at 500 Hz.
6	They resolved a spike averaging 74 ms above the period mean in the first 140 ms. Another rise occurs in the final 75 ms ^{[57, Fig. 3]}.
7	Measurement first exposed mechanisms such as the fifteen-second schedule ^{[13, §3–4]}.
8	Direct laser rate, ISL hop count and satellite-internal delay remain open measurement quantities.

IPv6 普查與高頻探測
#	數值、條件與證據
1	新方法依序擴展規模與時間解析度。
2	Wang 等人以 XMap 掃描 GeoIP 列出的 IPv6 /56 前綴，在 2025 年 12 月 29 日找到 165 國、208 地區的 5,975,440 台活躍路由器，辨識 49 個 PoP，再用六具天線推論 98 條骨幹鏈路 ^{[26, §III]}。
3	Casparsen 等人以 500 Hz 量測單一天線，解析出週期開頭 140 ms 內平均高出均值 74 ms 的尖峰，以及最後 75 ms 的次要上升 ^{[57, Fig. 3]}。
4	十五秒排程等機制最先由量測揭露 ^{[13, §3–4]}。
5	直接的雷射速率、ISL 跳數與衛星內部延遲仍是待量測的量。

Question問題	Calculation算式	Result結果
Share of Starlink customers HitchHiking reachesHitchHiking 觸及的 Starlink 用戶比例	$2{,}400 / 2{,}000{,}000$	≈ 0.12%computed, inputs from ^{[35, §6.2]} and §8, which states "~0.1%"計算值，輸入來自 ^{[35, §6.2]} 與 §8，論文寫「約 0.1%」
Where the 28× vantage-point ratio comes from28 倍觀測點比例從何而來	$1{,}629 / 58$	≈ 28.1×computed, 1,629 exposed services after PEP removal on 10 May 2023 against 58 Atlas Starlink probes (§5, §6.1.3)計算值，2023 年 5 月 10 日移除 PEP 後的 1,629 個開放服務，對 58 個 Atlas Starlink 探針（§5、§6.1.3）
Fraction of each 15-s period inside the start-of-period spike每個 15 秒週期落在開頭尖峰內的比例	$0.140\,\text{s} / 15\,\text{s}$	0.93%computed, 140 ms window from ^{[57, Fig. 3]} (preprint)計算值，140 ms 視窗來自 ^{[57, Fig. 3]}（預印本）
Same, including the secondary rise in the last 75 ms同上，加上最後 75 ms 的第二次上升	$(0.140 + 0.075)\,\text{s} / 15\,\text{s}$	1.43%computed, same source計算值，同一來源

7.3Packet simulation: Hypatia封包模擬：Hypatia

Recall

回顧

Section 5.4 reports Hypatia’s median four path changes per 200 s on Shell 1. Section 6.1 shows a 16 ms shortening halving NewReno’s window through reordering while every packet arrives.

第 5.4 節用了 Hypatia 的發現：Starlink Shell 1 上每 200 s 的路徑變動次數中位數為四次，第 6.1 節則使用路徑縮短 16 ms 後，封包全數送達仍使 NewReno 視窗減半的發現。

Hypatia combines continuous orbital propagation with periodic shortest-path updates and modeled protocol stacks. Its geometry, link and handover assumptions define the network being studied.

Hypatia 結合連續軌道推算、週期最短路徑更新與模型協定堆疊，幾何、鏈路、換手假設共同界定受測網路。

Hypatia: model configuration
#	Reported values and conditions
1	Hypatia pairs an ns-3 module with a Cesium visualizer ^[6].
2	At this primer’s census it had 221 citations, including 47 in 2026.
3	It converts filing elements to TLEs and gives each satellite four static +Grid lasers: two intra-plane and one to each adjacent plane.
4	Floyd–Warshall recomputes shortest paths every 100 ms by default.
5	Propagation delay follows continuous satellite motion between updates, so packets can take a formerly shortest route (§3, §3.1).
6	The 100 most populous cities have static parabolic stations.
7	Minimum elevations are 25° for Starlink, 30° for Kuiper and 10° for Telesat, with lossless handover (§2.2, §5).
8	All ISLs and ground links use equal rates and 100-packet queues (§4.2).
9	On Kuiper K1, a 1,000 ms step misses changes for 6% of city pairs, against 0.4% at 100 ms (§5.3, Fig. 9).

Hypatia 模型設定
#	數值、條件與證據
1	Hypatia 是這個領域第一個會拿起來用的封包模擬器，在本教材的事實庫彙整時已有 221 次引用，其中 47 次在 2026 年，值得確切知道它裡面有什麼^[6]。
2	它是一個 ns-3 模組，搭配 Cesium 視覺化工具，以克卜勒軌道根數輸入星座，轉成 TLE，把每顆衛星接成四條靜態雷射鏈路的 +Grid（軌道面內兩條，對每個鄰接軌道面各一條），並預設每 100 ms 以 Floyd–Warshall 重新計算所有最短路徑，而在兩次更新之間，每條鏈路的傳播延遲會連續跟著衛星運動，因此封包可能沿著一條剛剛還是最短的路徑繞遠路（§3、§3.1）。
3	地面站是世界上人口最多的 100 座城市，每一座都是一具靜態拋物面天線，Starlink 的最低仰角為 25°、Kuiper 為 30°、Telesat 為 10°，並且在衛星之間無損換手（§2.2、§5）。
4	每一條 ISL 與地面鏈路都有 100 個封包的佇列與相同的均一速率（§4.2）。
5	100 ms 的路由間隔本身也是量測過的選擇，因為在 Kuiper K1 上，1,000 ms 的步長會漏掉 6% 城市對的路徑變動，而 100 ms 只漏掉 0.4%（§5.3，Fig. 9）。

Packet simulation cost rises with traffic rate because each packet creates events. Hypatia’s high-rate timing study therefore measures runtime, while its network experiments use a lower fixed rate.

每個封包都產生事件，使封包模擬成本隨速率增加。Hypatia 的高速率研究因此衡量執行時間，網路實驗則採較低固定速率。

Hypatia: packet-event cost
#	Reported values and conditions
1	Hypatia’s rate sweep measures computational cost.
2	It spans 1 Mbit/s–10 Gbit/s, while every RTT and TCP result uses 10 Mbit/s (§3.4, §4.2, §5.4).
3	Packet-event count drives runtime.
4	One simulated second of 9.2 Gbit/s TCP takes about 555 s, and 13.8 Gbit/s UDP about 269 s.
5	Ten simulated TCP seconds near 10 Gbit/s take about 100 min (§3.4, Fig. 2).
6	Thus a ten-minute, single-flow 9.2 Gbit/s experiment approaches four days.
7	Independently, xeoverse’s authors timed 60 simulated seconds of the 1,584-satellite shell at 698 s ^{[80, §V-A]}.
8	Hypatia throughput results describe dynamics at 10 Mbit/s.
9	SpaceX’s claimed 100–200 Gbps per laser company is three to four orders higher. The results support mechanism studies (fact base Part C, item 60).

Hypatia 封包事件成本
#	數值、條件與證據
1	Hypatia 的速率掃描衡量計算成本，範圍為 1 Mbit/s–10 Gbit/s，而所有 RTT 與 TCP 結果採 10 Mbit/s（§3.4、§4.2、§5.4）。
2	執行時間由封包事件數決定，9.2 Gbit/s TCP 每模擬一秒約需 555 s，13.8 Gbit/s UDP 約需 269 s，近 10 Gbit/s TCP 的十個模擬秒約需 100 min（§3.4，Fig. 2）。
3	因此單流十分鐘實驗接近四天。
4	xeoverse 作者另量得，1,584 顆殼層的 60 個模擬秒需 698 s ^{[80, §V-A]}。
5	其吞吐量結果描述 10 Mbit/s 動態，SpaceX 宣稱每雷射 100–200 Gbps（公司）則高三至四個數量級，因此適合作為機制研究的證據（事實庫 Part C，第 60 項）。

Question問題	Calculation算式	Result結果
Packet events per simulated second for one 9.2 Gbit/s flow of 1,500-byte packets一條 9.2 Gbit/s、1,500 位元組封包的流，每個模擬秒的封包事件數	$9.2\times10^{9} / (1{,}500\times 8)$	≈ 767,000 packets/scomputed, the 1,500-byte packet size is our assumption, the rate is from ^{[6, §3.4]}計算值，1,500 位元組的封包大小是我們的假設，速率來自 ^{[6, §3.4]}
Wall-clock time of a 10-minute experiment at 9.2 Gbit/s TCP9.2 Gbit/s TCP 下 10 分鐘實驗的牆鐘時間	$600\,\text{s} \times 555$	333,000 s ≈ 92.5 h ≈ 3.9 dayscomputed, 555 s per simulated second from ^{[6, §3.4, Fig. 2]}計算值，每模擬秒 555 s 來自 ^{[6, §3.4, Fig. 2]}
Cross-check with the 10-virtual-second figure以十個虛擬秒的數字交叉核對	$100\,\text{min} \times 60 / 10\,\text{s}$	600 s per simulated secondcomputed, same order as 555 s, since the 10-second runs were near 10 Gbit/s (§3.4)計算值，與 555 s 同一量級，因為十秒的執行接近 10 Gbit/s（§3.4）
Slowdown of Hypatia on the full 1,584-satellite shell, as timed by xeoversexeoverse 量測的 Hypatia 在完整 1,584 顆衛星殼層上的減速倍數	$698\,\text{s} / 60\,\text{s}$	≈ 11.6× slower than real timecomputed, Kassem & Sastry, IFIP Networking 2024, §V-A (traffic load set by their scalability test)計算值，Kassem & Sastry，IFIP Networking 2024，§V-A（流量負載依其擴展性測試設定）
A 10-minute experiment at that slowdown在該減速倍數下的 10 分鐘實驗	$600\,\text{s} \times 11.6$	≈ 6,980 s ≈ 1.9 hcomputed計算值

Hypatia explains how moving routes change RTT, hop count and packet order. These qualitative effects inform mechanism studies, with deployed-network magnitudes requiring additional validation.

Hypatia 解釋移動路徑如何改變 RTT、跳數與封包順序，定性效應可用於機制研究，部署網路量值則需要額外驗證。

Hypatia: mechanisms demonstrated
#	Reported values and conditions
1	Hypatia’s main contribution is its explanation of moving-path effects.
2	Kuiper K1 Manila–Dalian RTT ranges from 25 to 48 ms over 200 s.
3	Over 30% of Starlink connections have maximum RTT at least 20% above their minimum, and the median pair changes routes four times per 200 s.
4	Reordering after a shorter route can halve a loss-based window while every packet arrives.
5	The authors conclude that “both loss and delay can be poor signals for congestion control in LEO networks” (§4.1–4.2, §5.1–5.2, Figs. 3–8).
6	These effects follow modeled geometry and +Grid routing.
7	Their qualitative mechanisms can inform deployed-network studies, while numerical Starlink predictions require additional validation.

Hypatia 展示的機制
#	數值、條件與證據
1	Hypatia 的主要貢獻是解釋移動路徑的效應。
2	Kuiper K1 的馬尼拉–大連 RTT 在 200 s 內為 25–48 ms。
3	超過 30% Starlink 連線的最大 RTT 至少高於最小值 20%，中位城市對每 200 s 換路四次。
4	路徑縮短後的重排可在封包全數送達時讓遺失式視窗減半。
5	作者因而指出，LEO 網路中的遺失與延遲，對壅塞的指示能力都可能受限（§4.1–4.2、§5.1–5.2，Figs. 3–8）。
6	這些效應來自模型幾何與 +Grid 路由，定性機制可用於部署網路研究，Starlink 的量化預測則需要額外驗證。

Hypatia’s October 2020 publication predates public Starlink service, placing original validation within its modeled setting. The fact base marks claims of live-Starlink validation as unsupported (Part D, item 45). Izhikevich et al.’s later comparison found that modeled RTT missed sustained real-network spikes. HitchHiking was on average 1.8× more accurate, and Hypatia’s best second-nearest-ground-station configuration averaged 7.6 ms error ^{[35, §6.1.2, Fig. 6]}.

Hypatia’s scope omits antenna gain, interference, Doppler, weather, moving terminals and dynamic ISL reconfiguration (§7). Its lossless handoff assumption differs from later measurements (Part D, item 44). The subsequently discovered fifteen-second schedule also lies outside the model, making modeled tail latency a lower bound.

Hypatia 的驗證範圍與模型省略項目，決定其結果如何對照實際網路。表中整理後續比較的誤差及限制。

條件、數值與證據
#	條件與結果
1	Hypatia 於 2020 年 10 月發表，早於 Starlink 公眾服務，因此原始驗證限於模型設定。
2	事實庫將實際 Starlink 驗證的說法列為證據待補（Part D，第 45 項）。
3	Izhikevich 等人後來比較發現，模擬 RTT 漏掉實際持續尖峰，HitchHiking 平均準確 1.8 倍，Hypatia 最佳的第二近地面站設定平均誤差為 7.6 ms ^{[35, §6.1.2, Fig. 6]}。
4	Hypatia 省略天線增益、干擾、都卜勒、天氣、移動終端與動態 ISL 重配（§7）。
5	無損換手假設與後續量測有差異（Part D，第 44 項），後來發現的十五秒排程也在模型之外，因此模擬尾端延遲可視為下限。

7.4Emulation: StarryNet, Celestial, xeoverse and LeoEM模擬平台：StarryNet、Celestial、xeoverse 與 LeoEM

Recall

回顧

Section 6.3 reports SaTCP increasing San Diego–New York throughput from 34.3 to 138.1 Mbps. It also compares CUBIC, SaTCP, BBRv3 and LeoCC independently in LeoEM. These values come from an emulator described here.

第 6.3 節報告了 SaTCP 把聖地牙哥–紐約的流從 34.3 提高到 138.1 Mbps，以及在 LeoEM 上對 CUBIC、SaTCP、BBRv3 與 LeoCC 的獨立比較，這些數字都出自本節介紹的某一個模擬平台。

StarryNet uses data-based constellation inputs and real container stacks to support routing experiments. Its scale, hardware cost and user-configured laser rate define that capability.

StarryNet 以資料建構星座並執行真實容器堆疊，支援路由實驗，規模、硬體成本與使用者設定的雷射速率共同界定能力。

StarryNet: architecture, scale and validation
#	Reported values and conditions
1	Emulators differ in what they virtualize per satellite.
2	StarryNet’s digital twin draws constellation and ground data from filings, TLEs, station lists and user measurements.
3	Its Observer collects inputs, Synchronizer calculates geometry, and Orchestrator deploys Docker nodes across workers with Open vSwitch and tc links ^{[40, §4, Fig. 1]}.
4	Full stacks support BIRD routing daemons and OSPF comparisons across four architectures.
5	On Shell 1, a bent pipe averaged 183.25 ms and 97.00% reachability, against 86.11 ms and 97.50% for frequently updated ISL addresses (§7.1, Table 3).
6	Seven Dell R740 workers created 4,408-satellite Phase I in 21.2 min at 34–40% CPU (Table 2).
7	Laser parameters remained “still under internal test”, so capacity “is set by user-specific configurations” (§4.3.1, §8).
8	Fidelity evidence is visual CDF overlap with one live bent-pipe terminal, while Hypatia and StarPerf “underestimate the latency”.
9	The text gives a qualitative comparison rather than a numerical error (§6.2, Fig. 6).

StarryNet 的架構、規模與驗證
#	數值、條件與證據
1	模擬平台執行的是真實軟體，所以它的第一個設計問題是為每顆衛星虛擬化什麼，而常用的四個平台給出的答案差異大到它們適合各種實驗。
2	StarryNet 自稱數位孿生，其星座、地面站與鏈路狀態以真實資料建構：Observer 收集申報、TLE、站點與量測，Synchronizer 計幾何，Orchestrator 分布 Docker 容器，用 Open vSwitch 相連，再以 `tc` 設定^{[40, §4, Fig. 1]}。
3	因為每個容器都執行完整的堆疊，StarryNet 可以執行路由常駐程式，它的案例研究在 Starlink Shell 1 上以 BIRD 執行 OSPF，比較四種路由架構，例如彎管設計平均延遲 183.25 ms、可達率 97.00%，而頻繁更新位址的 ISL 設計為 86.11 ms 與 97.50%（§7.1，Table 3）。
4	七台 Dell R740 模擬 4,408 顆第一期衛星，建立需 21.2 min、CPU 34–40%。雷射參數「仍在內部測試」，ISL 容量因而由使用者設定（§4.3.1、§8）。
5	逼真度證據為其 CDF 與一個實際彎管終端重疊，Hypatia、StarPerf 則低估延遲，數值誤差仍待列出（§6.2，Fig. 6）。

Celestial lowers service-experiment cost by suspending out-of-region microVMs. Its emulated network topology and self-model validation limit the conclusions available for hop-by-hop laser transport.

Celestial 暫停區域外微型 VM，以降低服務實驗成本，模擬拓樸與自身模型驗證則界定逐跳雷射傳輸的結論範圍。

Celestial: edge-computing configuration
#	Reported values and conditions
1	Celestial, ACM/IFIP Middleware 2022, primarily supports edge-computing experiments.
2	Each satellite and station gets a Firecracker microVM.
3	SGP4 updates every 2–5 s, and tc-netem applies distance-over-c delays at 0.1 ms accuracy.
4	Uniform rates are 10 Gb/s in its first evaluation and 100 Mb/s in its second ^{[79, §2–5]}.
5	A bounding box suspends out-of-region microVMs while preserving constellation routing.
6	This supports 4,409 satellites on three 32-vCPU hosts, or 96 cores against an estimated requirement of 137.
7	A ten-minute run costs $3.30, against at least $539.66 for one cloud VM per satellite (§4).
8	Satellite services reduce mean end-to-end latency from 22–183 to 13–90 ms (§5.2, Fig. 11).
9	Validation compares with its own simulation (§6).
10	An April 2026 comparison identifies a star-shaped emulation with two-hop satellite reachability, while praising update speed and low CPU use ^[81].

Celestial 的邊緣運算設定
#	數值、條件與證據
1	Celestial 發表於 ACM/IFIP Middleware 2022，它首先是邊緣運算測試平台，其次才是網路模擬平台。
2	它為每顆衛星與每座地面站執行一個 Firecracker 微型虛擬機，每 2–5 s 重新以 SGP4 計算位置，以 `tc-netem` 套用距離除以光速的延遲、精度 0.1 ms，並使用固定的鏈路速率：第一組評估中 ISL 與無線電鏈路為 10 Gb/s，第二組為 100 Mb/s^{[79, §2–5]}。
3	它的招牌技巧是一個地理邊界框，把感興趣區域之外衛星的微型虛擬機暫停，同時仍在整個星座上計算路由，這讓作者以三台 32 vCPU 的雲端主機（共 96 核，而他們估計需要 137 核）模擬 4,409 顆衛星，十分鐘一次的執行成本為 3.30 美元，而每顆衛星一台雲端 VM 至少要 539.66 美元（§4）。
4	它的代表性結果是，由衛星承載的服務把平均端到端延遲從 22–183 ms 降到 13–90 ms（§5.2，Fig. 11），而它的準確度只對自己的模擬驗證過（§6）。
5	2026 年 4 月比較指出 Celestial 的星狀網路使任意衛星兩跳可達，逐跳 ISL 行為在其實作範圍之外，更新速度與 CPU 使用率則受肯定^[81]。

xeoverse precomputes predictable orbital changes and runs lightweight real Linux nodes. Its static routing and the paper’s differing timing statements require explicit context.

xeoverse 預算可預測軌道變化，執行輕量真實 Linux 節點，靜態路由與文中各種計時說法都需明確附上條件。

xeoverse: configuration and reported comparisons
#	Reported values and conditions
1	xeoverse, IFIP Networking 2024, exploits predictable orbits by precomputing topology and routes, then updating changed laser links.
2	Mininet supplies real Linux nodes for satellites, terminals and gateways.
3	A 26-core, 64 GB machine runs one modeled second per real second ^{[80, §III–V]}.
4	Shell 1 has 5,346 grid links at four per satellite, with configurable fixed ISL capacity whose value requires clarification.
5	ITU Ku/Ka models and live OpenWeatherMap data set ground-link Shannon capacities, and Dijkstra routes stay static.
6	Bent-pipe throughput differs from live Starlink by at most 2% in clear sky and 16% in rain (Fig. 6).
7	London–San Francisco hops rise from 18 to 21, with mean latency up 67.6%, an effect absent in Hypatia (§V-B).
8	The abstract reports 2.9× overall speed against Hypatia and 40× against StarryNet, while Fig. 3 reports 2.3× for updates.
9	Figure 4 gives 55 min precomputation against Hypatia’s 162 min, whereas §V-A calls it “approximately 2 times higher”.
10	Claimed capacity is 5,442 satellites, with 1,584 demonstrated (fact base Part C, item 44).

xeoverse 的設定與報告比較
#	數值、條件與證據
1	xeoverse 發表於 IFIP Networking 2024，它走相反的路，利用可預測性來擴展規模。
2	因為軌道事先已知，它預先計算拓樸與路由，只更新改變的雷射鏈路，並把每顆衛星、使用者終端與閘道都當成一個帶真實 Linux 堆疊的輕量 Mininet 節點即時執行，所以在單一台 26 核、64 GB 的機器上，一個模擬秒就花一個牆鐘秒^{[80, §III–V]}。
3	它的 Shell 1 有 5,346 條網格雷射鏈路，每顆衛星四條，ISL 容量固定且可設定，但數值待說明，地面鏈路的 Shannon 容量來自 ITU Ku/Ka 頻段模型與即時的 OpenWeatherMap 資料，路由則是靜態的 Dijkstra 路徑。
4	晴天、雨天的彎管吞吐與實際 Starlink 相差各至多 2%、16%（Fig. 6）。倫敦–舊金山跳數 18 增至 21，平均延遲增 67.6%，Hypatia 的對應模型省略此效應（§V-B）。
5	它的速度說法需要小心：摘要說總時間比 Hypatia 快 2.9 倍、比 StarryNet 快 40 倍，而 Fig. 3 給出的更新階段是 2.3 倍，它的預先計算在 Fig. 4 中是 55 min 對 Hypatia 的 162 min，但 §V-A 的正文卻說「大約高 2 倍」，它宣稱可容納 5,442 顆衛星，但只展示到 1,584 顆（Part C，第 44 項）。

LeoEM targets transport experiments on a single modeled path and includes scheduled hard and soft handovers. This scale suits congestion control while defining the scope of its results.

LeoEM 在單一路徑上研究傳輸，並加入排程的硬、軟換手，這種尺度適合壅塞控制，也界定結果範圍。

LeoEM: single-path handover model
#	Reported values and conditions
1	Cao and Zhang built LeoEM for SaTCP, and Chapter 6’s transport studies commonly use it. Mininet emulates one shortest Shell-1 path on a laptop, with 150 Mb/s link caps and 1,000-packet queues ^{[67, §IV, §VI-A]}.
2	The authors attribute a fifteen-second handoff interval to Starlink’s FCC filing.
3	A hard handover interrupts the old ingress link for 1.5 RTT and the new one for another 1.5 RTT.
4	A soft intermediate handover toggles affected interfaces, potentially losing packets on the dismantled route (§III-C, §IV).
5	LeoEM alone among these platforms includes this schedule.
6	Later work includes 1,650 Sussex-group experiments ^[75].
7	Its results describe capped single-path transport, with constellation-wide behavior requiring a broader model.

LeoEM 的單路徑換手模型
#	數值、條件與證據
1	LeoEM 是四者中最小的，也是第 6 章大多數論文實際使用的那一個。
2	它由 Cao 與 Zhang 為了評估 SaTCP 而建，是建立在 Mininet 上的路徑模擬平台，一次只計算穿過 Starlink Shell 1 的一條最短路徑，把每條鏈路限制在 150 Mb/s、佇列 1,000 個封包，並在一台普通筆電上執行^{[67, §IV, §VI-A]}。
3	它與眾各異之處在於它遵循作者歸於 Starlink FCC 申請文件的說法，「網路需要以 15 秒為間隔考慮換手」，把末端（硬）換手模擬成對舊入口衛星拆除鏈路 1.5 個 RTT、再對新入口衛星 1.5 個 RTT，把中間（軟）換手模擬成關閉再開啟受影響節點的網路介面，並可能在被拆除的路由上遺失封包（§III-C、§IV），這使它成為本章中唯一內建 15 秒排程的平台。
4	這就是為什麼後來的壅塞控制研究，包括 Sussex 團隊在 LeoEM 路徑上的 1,650 次實驗，把它當成事實上的標準測試平台^[75]，因此結果描述 150 Mb/s 上限下的單一路徑，星座整體則需要更廣模型。

Tool工具	Venue發表處	Scale shown展示的規模	ISL topologyISL 拓樸	Default ISL rate預設 ISL 速率	Latency model延遲模型	Setup delay建立延遲	15-s schedule15 秒排程	Live-Starlink validation對實際 Starlink 的驗證	Cost成本
Hypatia	IMC 2020	1,584 (Shell 1) and other shells, 100 cities1,584（Shell 1）及其他殼層，100 座城市	+Grid, 4 static+Grid，4 條靜態	uniform, 10 Mbit/s in all results (1 Mb/s–10 Gb/s cost sweep)均一，所有結果 10 Mbit/s（1 Mb/s–10 Gb/s 成本掃描）	propagation, continuous, routes every 100 ms, 100-packet queues, lossless handoff傳播，連續，每 100 ms 算路徑，100 封包佇列，無損換手	omitted省略	omitted, predates discovery省略，早於發現	none (predates service), misses sustained spikes, HitchHiking 1.8× more accurate早於服務，持續尖峰省略，HitchHiking 準確 1.8 倍	555 s per simulated s at 9.2 Gbit/s9.2 Gbit/s 下每模擬秒 555 s
StarryNet	NSDI 2023	4,408 (Phase I) on 7 servers4,408（第一期），7 台伺服器	+Grid 4, or motifs+Grid 4 條，或 motif	none, user-set由使用者設定	propagation by distance via `tc`, updates every 1–3 s, real stacks以 `tc` 依距離設定傳播延遲，每 1–3 s 更新，真實堆疊	omitted省略	omitted省略	visual CDF overlap with one bent-pipe terminal, numerical error pending與一個彎管終端的 CDF 目視重疊，資料待補誤差	7 Dell R740, 21.2 min to build7 台 Dell R740，建立 21.2 min
Celestial	Middleware 2022	4,409 on 3 hosts (bounding box)4,409，3 台主機（邊界框）	+Grid in model, star in emulation ^[81]模型中 +Grid，模擬中星狀^[81]	10 Gb/s (§4) or 100 Mb/s (§5), flat10 Gb/s（§4）或 100 Mb/s（§5），固定	SGP4 every 2–5 s, `tc-netem` at 0.1 ms, microVMs每 2–5 s SGP4，`tc-netem` 精度 0.1 ms，微型 VM	omitted省略	omitted省略	only against its own simulation只對自己的模擬驗證	$3.30 per 10-min run每次 10 分鐘執行 3.30 美元
xeoverse	IFIP Networking 2024	1,584 shown (5,442 claimed)展示 1,584（宣稱 5,442）	grid, 4 per satellite, 5,346 ISLs, static routes網格，每顆 4 條，5,346 條 ISL，靜態路由	fixed, configurable, value unspecified固定、可設定，數值待補	propagation, Shannon GSL with ITU models and weather, real time傳播，以 ITU 模型與天氣算 GSL 的 Shannon 容量，即時	omitted省略	omitted省略	bent-pipe throughput within 2% (clear) and 16% (rain)彎管吞吐量相差 2%（晴）與 16%（雨）以內	one 26-core, 64 GB machine一台 26 核、64 GB 機器
LeoEM	INFOCOM 2023	one path through Shell 1 (72×22)穿過 Shell 1（72×22）的一條路徑	+Grid 4, Dijkstra path+Grid 4 條，Dijkstra 路徑	150 Mb/s cap on every link每條鏈路 150 Mb/s 上限	propagation, hard handover tears link down 1.5 + 1.5 RTT, 1,000-packet queue傳播，硬換手拆除鏈路 1.5 + 1.5 RTT，1,000 封包佇列	omitted省略	yes, 15-s handoff有，15 秒換手	none, emulation only限模擬評估	one commodity laptop一台普通筆電

Sources: ^{[6, §3–5, §7]}, ^{[40, §4, §6, Tabs. 2–3]}, ^{[79, §2–6]}, ^{[80, §III–V]}, ^{[67, §IV–VI]}, ^{[35, §6.1.2]}, ^[81]. The 15-s column follows the fact base, Part C item 57.

來源： ^{[6, §3–5, §7]}， ^{[40, §4, §6, Tabs. 2–3]}， ^{[79, §2–6]}， ^{[80, §III–V]}， ^{[67, §IV–VI]}， ^{[35, §6.1.2]}， ^[81]。15 秒一欄依事實庫 Part C 第 57 項。

The platforms exchange scale, startup work, runtime and memory in separate ways. The resource records below help determine which experiment a group can actually repeat.

各平台對規模、建立作業、執行時間與記憶體各有取捨，下列資源紀錄可協助判斷團隊能重複哪種實驗。

Experimental resource costs
#	Reported values and conditions
1	Cost limits the experiments a group can run.
2	Celestial’s bounding box saves 164-fold against one VM per satellite.
3	StarryNet needs seven workers and about 0.29 s of startup per satellite. xeoverse runs a ten-minute experiment in ten minutes after the reported 55 min precomputation.
4	A 2026 comparison measured mainline StarryNet’s Docker startup at “almost 10x longer” than competitors.
5	A ten-hop path showed “between 200-300ms RTT” and was “very unstable”.
6	Netlink-based StarryNet-dev was “the best performing solution”, with a root filesystem still required ^[81].
7	HitchHiking’s comparison placed StarryNet’s RAM requirement above 2 TB, beyond its available resources ^{[35, §6.1.2]}.

實驗資源成本
#	數值、條件與證據
1	成本限制團隊可進行的實驗。
2	Celestial 邊界框相對每衛星一台 VM 節省 164 倍。
3	StarryNet 需七台工作機，每衛星建立約 0.29 s。
4	xeoverse 的十分鐘實驗以十分鐘執行，另加報告的 55 min 預先計算。
5	2026 年比較量得主線 StarryNet 的 Docker 建立「幾乎長 10 倍」，十跳路徑「RTT 在 200–300 ms 之間」，波動也較大。
6	Netlink 分支 StarryNet-dev 為「表現最好的方案」，根檔案系統仍待提供 ^[81]。
7	HitchHiking 的比較估計 StarryNet 需超過 2 TB RAM，超出其可用資源 ^{[35, §6.1.2]}。

Question問題	Calculation算式	Result結果
Celestial's saving per 10-minute run over one cloud VM per satelliteCelestial 每次 10 分鐘執行相對每顆衛星一台雲端 VM 的節省	$\$539.66 / \$3.30$	≥ 164×computed, both figures from ^{[79, §4]} ($3.30 includes a 5-min setup, $539.66 is for 4,409 f1-micro VMs and is a lower bound)計算值，兩個數字都來自 ^{[79, §4]}（3.30 美元含 5 分鐘建置，539.66 美元是 4,409 台 f1-micro VM，為下限）
Celestial's CPU oversubscriptionCelestial 的 CPU 超額配置	$137\ \text{cores estimated} / 96\ \text{cores used}$	≈ 1.43×computed, same source, §4計算值，同一來源，§4
StarryNet containers per worker for full Phase I完整第一期時 StarryNet 每台工作機的容器數	$4{,}408 / 7$	≈ 630computed, ^{[40, Tab. 2]}計算值，^{[40, Tab. 2]}
StarryNet bring-up time per satelliteStarryNet 每顆衛星的建立時間	$21.2\,\text{min}\times 60 / 4{,}408$	≈ 0.29 scomputed, same source計算值，同一來源
A 10-minute StarryNet experiment at 660 satellites, at the 79 s per simulated second xeoverse reports以 xeoverse 報告的每模擬秒 79 s 計，660 顆衛星的 10 分鐘 StarryNet 實驗	$600\,\text{s}\times 79$	47,400 s ≈ 13.2 hcomputed, 79 s from Kassem & Sastry, IFIP Networking 2024, §V-A, a third-party timing計算值，79 s 來自 Kassem & Sastry，IFIP Networking 2024，§V-A，為第三方量測
A 10-minute xeoverse experiment including pre-computation含預先計算的 10 分鐘 xeoverse 實驗	$55\,\text{min} + 10\,\text{min}$	≈ 65 mincomputed, 55 min at 100 ground segments and 50 flows from Fig. 4, which §V-A's text contradicts (Part C, item 44)計算值，100 個地面段、50 條流時的 55 min 來自 Fig. 4，而 §V-A 的正文與之矛盾（Part C，第 44 項）

The tool choice follows the research question. LeoEM’s single path suits congestion control and includes the handoff events that controllers must handle. StarryNet and Celestial support constellation-scale studies of routing and service placement. StarryNet uses user-defined laser capacity, while Celestial uses star-shaped emulation. xeoverse offers inexpensive real-time execution with static routes. This suits transport studies and limits routing studies.

工具選擇取決於研究問題。LeoEM 的單一路徑適合壅塞控制，也納入控制器必須面對的換手事件。StarryNet 與 Celestial 提供星座規模的路由或服務配置研究，前者由使用者設定雷射容量，後者則以星狀網路模擬。xeoverse 提供低成本即時執行與靜態路由，適合傳輸研究，也界定了其路由研究範圍。

7.5Shared assumptions: laser rate, topology and scheduling共同假設：雷射速率、拓樸與排程

Recall

回顧

Section 2.1 records assumed node delays of 1 or 10 ms, with direct measurement still open. Section 4.3 discusses the public-data gaps in laser rate, deployed topology and scheduling.

第 2.1 節記錄每跳 1 或 10 ms 的節點延遲假設，直接量測仍待完成。第 4.3 節討論雷射速率、部署拓樸與排程的公開資料缺口。

Laser capacity, topology and scheduling are model inputs. Throughput results require interpretation within those assumptions.

Conditions and reported evidence
#	Evidence record
1	Every tool requires assumptions about laser capacity, topology and scheduling.
2	Hypatia uses 10 Mbit/s, StarryNet user settings, Celestial 10 Gb/s or 100 Mb/s, xeoverse an unstated fixed rate, and LeoEM 150 Mb/s.
3	SpaceX’s press-reported claims are 100 Gbps sustained and 200 Gbps peak company.
4	The fact base therefore treats simulated throughput as dynamics evidence (Part C, item 60).

Tool models use four-link +Grids, while deployed satellites carry three terminals in an undisclosed arrangement. Scheduling appears in LeoEM/SaTCP, the HotNets 2024 study, LeoCC replay and OrbCC, while the other listed constellation tools omit it (Part C, item 57). Measurement observes their combined effects. Direct calibration of each causal quantity requires additional operator or experimental evidence.

雷射容量、拓樸與排程都是模型輸入。吞吐量結果須連同假設解讀，直接校準則需要額外量測。

條件、數值與證據
#	條件與結果
1	每種工具都需要假設雷射容量、拓樸與排程。
2	Hypatia 採 10 Mbit/s，StarryNet 由使用者設定，Celestial 採 10 Gb/s 或 100 Mb/s，xeoverse 採待說明的固定值，LeoEM 則限 150 Mb/s。
3	SpaceX 經媒體報告的數字是持續 100 Gbps、峰值 200 Gbps（公司），因此事實庫把模擬吞吐量視為動態證據（Part C，第 60 項）。
4	模型使用四鏈路 +Grid，部署衛星則有三具終端，排列方式仍待公開。
5	排程出現在 LeoEM／SaTCP、HotNets 2024、LeoCC 重播與 OrbCC，其餘所列星座工具則省略（Part C，第 57 項）。
6	量測觀察這些因素的綜合效果，各因果量的直接校準仍需額外營運或實驗證據。

Figure 7.3. Shared model assumptions and public-data gaps. Amber cells contain modeled substitutes, red cells indicate quantities outside a tool’s observation or implementation, and green cells show represented mechanisms. The dashed bottom row records deployed-network information. Its gaps limit direct validation of the modeled values above.圖 7.3。共同模型假設與公開資料缺口。琥珀格為建模替代值，紅格為工具觀測或實作範圍外的量，綠格為已呈現機制。虛線底列記錄部署網路資訊，其資料缺口也界定上方模型值可直接驗證的範圍。Sources來源: ^[33] ^[32]

Original figure note原始圖說出處

Drawn for this primer from the sources of the capability table in Section 7.4, SpaceX figures as relayed in the fact base, Chapter 2 and Part D item 13, node-delay assumptions from Chaudhry & Yanikomeroglu, OJCOMS 2022 (10 ms) and Bhattacharjee et al., arXiv 2301.05285 (1 ms).

Two 2026 studies examine agreement across tools and with live evidence. Cionca et al. compare StarryNet, OpenSN and Celestial on the same 72×22, 53° shell. They report discrepancies from real measurements and variable topology-update delays that can exceed the modeled interval ^[81]. Valentine et al. implement CUBIC, BBRv1/v3, SaTCP, LeoCC and Orca in OMNeT++/INET.

Adding pacing and RACK brings results closer to Mininet and LeoEM, with a residual gap ^{[82, Fig. 2]}. This is model-to-model calibration. It identifies missing implementations, while evidence about Starlink requires a deployed-network reference. Disagreement can reflect separate modeling choices, and agreement can reflect shared assumptions.

2026 年兩項研究檢查工具之間與實際證據的一致性。Cionca 等人在同一個 72×22、53° 殼層比較 StarryNet、OpenSN 與 Celestial，報告與實測的落差，以及可能超過模型時間間隔的變動更新延遲 ^[81]。Valentine 等人在 OMNeT++/INET 實作 CUBIC、BBRv1/v3、SaTCP、LeoCC 與 Orca，加入 pacing、RACK 後，結果更接近 Mininet 與 LeoEM，但仍有殘餘差距 ^{[82, Fig. 2]}。這屬模型對模型的校準，可辨識待補實作，Starlink 證據則需要部署網路作參考。工具差異可能反映建模選擇，一致也可能來自共享假設。

Panel 7.1 compares propagation with added node delay, scheduled spikes and retransmission. Its seeded trace and controls are listed below.

Conditions and reported evidence
#	Evidence record
1	Panel 7.1 illustrates assumption costs in user-to-PoP one-way delay.
2	A seeded ten-minute trace sends 100 packets per second over a bent pipe or a five-hop 72×22 ISL path.
3	Controls add per-satellite delay of 1 or 10 ms, the measured start-of-period spike, and boundary losses recovered by one retransmission.
4	The gray outline retains propagation and ground delay only.
5	Compare median and tail separately: a spike occupying 0.93% of time sits just beyond p99.

面板 7.1 比較純傳播與加入節點延遲、週期尖峰及重傳後的結果。表中保留軌跡設定與控制條件。

條件、數值與證據
#	條件與結果
1	面板 7.1 以使用者到 PoP 的單向延遲，說明假設的代價。
2	固定種子的十分鐘軌跡每秒傳送 100 個封包，採彎管或 72×22 殼層五跳 ISL 路徑。
3	控制項可加上每衛星 1 或 10 ms 延遲、量得的週期開頭尖峰，以及由一次重傳恢復的邊界遺失。
4	灰色外框只保留傳播與地面段，請分開觀察中位數與尾端，因為占時間 0.93% 的尖峰位於 p99 之外。

Panel 7.1面板 7.1

How wrong can a simulator be?模擬器可以錯多少？

Path路徑

Node delay per satellite每顆衛星的節點延遲

15-s scheduler spike15 秒排程器尖峰

Boundary-aligned loss與邊界對齊的遺失

View檢視

Random seed亂數種子

Median (p50)

中位數（p50）

p99

p99.9

Idealised simulator p50 / p99

理想化模擬器 p50 / p99

p99 underestimate by the ideal

理想化模擬器低估的 p99

Packets lost and resent

遺失並重傳的封包

The panel uses a reproducible workload to isolate geometry, node delay, scheduling and recovered loss. It separates these effects from loaded queues and actual laser capacity.

面板採可重現負載，依序檢視幾何、節點延遲、排程與恢復遺失的效果，並界定它與負載佇列、實際雷射容量的範圍。

Panel model: workload and delay components
#	Reported values and conditions
1	The seeded model sends 60,000 packets at 100 per second over 10 min.
2	Each fifteen-second period draws user and gateway slant ranges uniformly from 550 km overhead to 1,123 km at 25°.
3	The ISL route adds two 1,969 km intra-plane hops and three cross-plane hops drawn from 363–604 km, following Chapter 2’s 72×22 layout.
4	Each packet waits 0–1.333 ms for a user-link frame ^[42], then adds 5 ms gateway–PoP delay ^{[49, App. D]}.
8	Node delay applies once for a bent pipe and six times for the ISL path.
9	In the first 140 ms of each period, the spike adds 74 ms × U(0.5, 1.5) ^[57].
10	Enabled loss is 0.40% throughout ^[48], plus 50% within the spike window, interpreting Kassem et al.’s “up to 50%” bursts ^[46].
11	A lost packet arrives one RTT later.
12	The ideal model includes propagation and the 5 ms ground segment.
13	Loaded queueing, drop-front behavior, end-of-period rises, PoP changes and actual laser capacity lie outside its scope.

面板模型的負載與延遲組成
#	數值、條件與證據
1	這是本教材自己的模型，固定亂數種子，所以每個設定都可重現。
2	以每秒 100 個封包送出 10 min，共六萬個封包。
3	每個 15 秒週期抽一次新的幾何：使用者與閘道的斜距在 550 km（天頂）與 1,123 km（25° 仰角）之間均勻抽取，ISL 路徑則是兩跳 1,969 km 的軌道面內鏈路，加上三跳在 363 到 604 km 之間抽取的跨面鏈路，也就是第 2 章 72×22 的數值。
4	每個封包再加上等待下一個使用者鏈路訊框的 0–1.333 ms^[42]、閘道到 PoP 的 5 ms^{[49, App. D]}，以及經過的每顆衛星所選的節點延遲，彎管一顆、ISL 路徑六顆。
5	尖峰對每個週期前 140 ms 內送出的封包加上 74 ms × U(0.5, 1.5)^[57]。
6	開啟遺失時，各處皆有 0.40% 的遺失^[48]，尖峰視窗內再加 50%，這是我們對 Kassem et al.^[46]所見「最高 50%」遺失群聚的解讀，遺失的封包晚一個 RTT 抵達。
7	理想化模擬器只有傳播加上 5 ms 地面段。
8	此模型省略了負載下的排隊、drop-front 佇列、週期末的第二次上升、PoP 變更，以及任何真實的 ISL 速率。

Stop and think停下來想一想

Select the five-hop ISL route with 1 ms node delay and the spike enabled, then compare p99 with p99.9. Disable the spike and compare again. Explain the percentile responses, then enable boundary loss and examine p99. With the spike disabled, select 10 ms node delay. Which assumptions primarily affect medians, and which primarily affect tails?

選五跳 ISL、1 ms 節點延遲並開尖峰，比較 p99 與 p99.9，再關尖峰。請解釋兩百分位的反應，接著開邊界遺失觀察 p99。最後關尖峰並選 10 ms，說明哪些假設影響中位數，哪些影響尾端。

7.6Checklist for reading a simulated result閱讀模擬結果的檢查清單

Before citing a simulated number, establish the ten conditions below. They identify the model network, its implemented mechanisms and the evidence supporting its parameters. Conclusions transfer most directly when their mechanisms also occur in the deployed network, such as moving-grid geometry. Results that depend on assumed laser rate or node delay require those assumptions beside the citation.

引用模擬數字前，先建立下列十項條件，確認模型網路、已實作機制與參數證據。若結論依據的機制也存在於部署網路，例如移動網格的幾何，便較容易轉用於該網路。若結果依賴假設的雷射速率或節點延遲，引用時應一併列出這些條件。

#	Ask要問的問題	Why it matters為什麼重要	Evidence in this primer本教材中的證據
1	Which constellation geometry, from which filing or TLE epoch?哪一種星座幾何？來自哪一份申報或哪個 TLE 曆元？	The papers use three historical filings, each describing a planned shell with a separate deployment history.論文採用三份歷史申報，各自描述一個有其部署歷程的規劃殼層。	Section 1.4第 1.4 節, 5.75.7
2	How many laser links per satellite, in what pattern, and does the emulated network actually have them?每顆衛星幾條雷射鏈路？什麼排列？模擬出來的網路真的有這些鏈路嗎？	Every tool assumes a four-link +Grid while satellites carry three terminals, Celestial's emulated network is a star.每種工具都假設四條鏈路的 +Grid，而衛星帶的是三具終端，Celestial 模擬出來的網路是星狀的。	Section 2.5第 2.5 節, 7.47.4
3	What ISL rate, and is any throughput number more than a dynamics illustration?ISL 速率與吞吐量結果的適用範圍為何？	Simulated rates run from 10 Mbit/s to 10 Gb/s against 100–200 Gb/s claimed per laser.模擬的速率從 10 Mbit/s 到 10 Gb/s，而宣稱的每具雷射是 100–200 Gb/s。	Section 7.3第 7.3 節, 7.57.5
4	What node delay per satellite was assumed?假設每顆衛星的節點延遲是多少？	Direct measurement remains open. Assumptions of 0, 1 and 10 ms can change topology rankings.直接量測仍待完成，0、1、10 ms 的假設都可能改變拓樸排名。	Section 2.1第 2.1 節, 5.25.2, Panel 7.1面板 7.1
5	Is laser setup (acquisition) delay modelled?模型如何處理雷射建立、擷取延遲？	Acquisition takes 2–30 s, while path changes tolerate 2.3–80.63 ms. The listed tools omit acquisition cost.擷取需 2–30 s，路徑變化容忍值為 2.3–80.63 ms，所列工具均省略擷取成本。	Section 2.4第 2.4 節, 2.52.5
6	Is the 15-second schedule modelled, and does the paper report tails beyond p99?模型如何處理十五秒排程，尾端指標涵蓋哪些百分位？	Only LeoEM-family tools model it, the spike covers 0.93% of time and can hide just outside p99.只有 LeoEM 一系的工具模擬它，尖峰佔 0.93% 的時間，可以剛好藏在 p99 之外。	Section 3.5第 3.5 節, 7.57.5
7	How are ground links modelled: lossless handoff, weather, static stations, which PoP?地面鏈路如何模擬：無損換手、天氣、靜態地面站、哪一個 PoP？	Lossless handoff is a modelling assumption, and on the real network PoP placement dominates latency for ISL users.無損換手是建模假設，而在真實網路上，對 ISL 使用者而言 PoP 的位置主導延遲。	Section 3.3第 3.3 節, 7.37.3
8	How often are routes recomputed, and how long does the tool take to apply an update?多久重算一次路徑？工具套用一次更新要花多久？	Hypatia uses 100 ms and emulators 1–5 s, with variable emulator update delays that can exceed those intervals.Hypatia 為 100 ms，模擬平台為 1–5 s，平台更新延遲會變動，並可能超過這些間隔。	Section 5.4第 5.4 節, 7.57.5
9	Validated against what: live Starlink, another tool, or itself, and with a printed error?驗證參考是實際 Starlink、另一種工具，或自身模型？請確認報告的誤差。	Agreement between models establishes calibration. xeoverse also gives a numerical error against live-Starlink throughput.模型間一致可建立校準，xeoverse 另提供相對實際 Starlink 吞吐量的數值誤差。	Section 7.4第 7.4 節, 7.57.5
10	How large was the run, on what hardware, with what seeds and code, and could another group repeat it?實驗規模多大？用什麼硬體、什麼種子與程式碼？其他團隊能重做嗎？	A 10-minute run costs from about 1 h to almost 4 days or $3.30, depending on the tool.依工具而定，十分鐘實驗的成本介於約一小時與近四天，或為 3.30 美元。	Section 7.3第 7.3 節, 7.47.4

The checklist also applies to Part III’s orbital-computing and AI work, whose evaluations mostly use modeled links. A propagation-only inference model with at least 100 Gbps links or a federated-learning model at 16 Mb/s assumes answers to questions 3, 4 and 6. Chapters 9 and 12 depend on those conditions. Chapter 13 asks what an orbital-cluster emulator needs and what the planned 2027 two-satellite test should measure to replace the capacity assumption with evidence.

此清單也適用於第三部以模型鏈路評估的在軌運算與 AI 研究。只計傳播、每鏈路至少 100 Gbps 的推論模型，以及固定 16 Mb/s 的聯邦學習模型，都以假設回答第 3、4、6 題，第 9、12 章的結論也依賴這些條件。第 13 章討論軌道叢集平台的需求，以及預定 2027 年雙衛星測試應量測的內容，讓容量假設轉為實驗證據。

Chapter summary

本章摘要

LEO evidence comes from measurement, packet simulation and emulation, each with a fidelity–scale trade. Dishes, LENS, RIPE Atlas, HitchHiking and IPv6 scanning reveal deployed scheduling, queues and PoP behavior within their observation boundaries. Hypatia explains RTT variation, route changes and reordering through an idealized +Grid, with high-rate runtime limiting experiments. StarryNet provides containerized digital twins, Celestial supports low-cost edge services, xeoverse offers real-time static routes, and LeoEM models one scheduled path.

Their laser rate, topology and delay assumptions define each result’s scope. Model agreement supports calibration, while direct deployed-network evidence supports validation. Panel 7.1 shows why omissions can preserve medians yet shift tails by tens of milliseconds.

LEO 證據來自量測、封包模擬與模擬平台，各有逼真度與規模的取捨。天線、LENS、RIPE Atlas、HitchHiking 與 IPv6 掃描在各自範圍內揭露排程、佇列與 PoP 行為。Hypatia 透過理想化 +Grid 解釋 RTT、路徑與重排，高速率計算成本則限制實驗規模。StarryNet 提供容器數位孿生，Celestial 支援低成本邊緣服務，xeoverse 提供即時靜態路由，LeoEM 模擬單一排程路徑。雷射速率、拓樸與延遲假設界定各項結果，模型一致支持校準，部署證據則支持驗證。面板 7.1 顯示省略項可能保留中位數，卻讓尾端改變數十毫秒。

Where these ideas go next

這些概念接下來用在哪裡

Chapter 8 examines satellites as computers through measured heat and hardware behavior in orbit. Chapter 12 applies the checklist to LLM-inference preprints and their ISL-rate assumptions. Section 13.7 defines orbital-cluster emulator needs and measurements for an initial laser test.

第 8 章透過在軌散熱與硬體行為量測，把衛星當作電腦來研究。第 12 章用清單檢查 LLM 推論預印本與 ISL 速率假設。第 13.7 節則界定軌道叢集平台與初次雷射測試的量測需求。

Papers behind this chapter本章所依據的論文

IMC 2020Exploring the "Internet from Space" with Hypatia NSDI 2023StarryNet: Empowering Researchers to Evaluate Futuristic Integrated Space and Terrestrial Networks Middleware 2022Celestial: Virtual Software System Testbeds for the LEO Edge IFIP Networking 2024xeoverse: A Real-time Simulation Platform for Large LEO Satellite Mega-Constellations SIGMETRICS 2024Democratizing LEO Satellite Network Measurement INFOCOM 2023SaTCP: Link-Layer Informed TCP Adaptation for Highly Dynamic LEO Satellite Networks

Question問題	Calculation算式	Result結果
Share of Starlink customers HitchHiking reachesHitchHiking 觸及的 Starlink 用戶比例	\(2{,}400 / 2{,}000{,}000\)	≈ 0.12%computed, inputs from ^{[35, §6.2]} and §8, which states "~0.1%"計算值，輸入來自 ^{[35, §6.2]} 與 §8，論文寫「約 0.1%」
Where the 28× vantage-point ratio comes from28 倍觀測點比例從何而來	\(1{,}629 / 58\)	≈ 28.1×computed, 1,629 exposed services after PEP removal on 10 May 2023 against 58 Atlas Starlink probes (§5, §6.1.3)計算值，2023 年 5 月 10 日移除 PEP 後的 1,629 個開放服務，對 58 個 Atlas Starlink 探針（§5、§6.1.3）
Fraction of each 15-s period inside the start-of-period spike每個 15 秒週期落在開頭尖峰內的比例	\(0.140\,\text{s} / 15\,\text{s}\)	0.93%computed, 140 ms window from ^{[57, Fig. 3]} (preprint)計算值，140 ms 視窗來自 ^{[57, Fig. 3]}（預印本）
Same, including the secondary rise in the last 75 ms同上，加上最後 75 ms 的第二次上升	\((0.140 + 0.075)\,\text{s} / 15\,\text{s}\)	1.43%computed, same source計算值，同一來源

Question問題	Calculation算式	Result結果
Packet events per simulated second for one 9.2 Gbit/s flow of 1,500-byte packets一條 9.2 Gbit/s、1,500 位元組封包的流，每個模擬秒的封包事件數	\(9.2\times10^{9} / (1{,}500\times 8)\)	≈ 767,000 packets/scomputed, the 1,500-byte packet size is our assumption, the rate is from ^{[6, §3.4]}計算值，1,500 位元組的封包大小是我們的假設，速率來自 ^{[6, §3.4]}
Wall-clock time of a 10-minute experiment at 9.2 Gbit/s TCP9.2 Gbit/s TCP 下 10 分鐘實驗的牆鐘時間	\(600\,\text{s} \times 555\)	333,000 s ≈ 92.5 h ≈ 3.9 dayscomputed, 555 s per simulated second from ^{[6, §3.4, Fig. 2]}計算值，每模擬秒 555 s 來自 ^{[6, §3.4, Fig. 2]}
Cross-check with the 10-virtual-second figure以十個虛擬秒的數字交叉核對	\(100\,\text{min} \times 60 / 10\,\text{s}\)	600 s per simulated secondcomputed, same order as 555 s, since the 10-second runs were near 10 Gbit/s (§3.4)計算值，與 555 s 同一量級，因為十秒的執行接近 10 Gbit/s（§3.4）
Slowdown of Hypatia on the full 1,584-satellite shell, as timed by xeoversexeoverse 量測的 Hypatia 在完整 1,584 顆衛星殼層上的減速倍數	\(698\,\text{s} / 60\,\text{s}\)	≈ 11.6× slower than real timecomputed, Kassem & Sastry, IFIP Networking 2024, §V-A (traffic load set by their scalability test)計算值，Kassem & Sastry，IFIP Networking 2024，§V-A（流量負載依其擴展性測試設定）
A 10-minute experiment at that slowdown在該減速倍數下的 10 分鐘實驗	\(600\,\text{s} \times 11.6\)	≈ 6,980 s ≈ 1.9 hcomputed計算值

Question問題	Calculation算式	Result結果
Celestial's saving per 10-minute run over one cloud VM per satelliteCelestial 每次 10 分鐘執行相對每顆衛星一台雲端 VM 的節省	\(\$539.66 / \$3.30\)	≥ 164×computed, both figures from ^{[79, §4]} ($3.30 includes a 5-min setup, $539.66 is for 4,409 f1-micro VMs and is a lower bound)計算值，兩個數字都來自 ^{[79, §4]}（3.30 美元含 5 分鐘建置，539.66 美元是 4,409 台 f1-micro VM，為下限）
Celestial's CPU oversubscriptionCelestial 的 CPU 超額配置	\(137\ \text{cores estimated} / 96\ \text{cores used}\)	≈ 1.43×computed, same source, §4計算值，同一來源，§4
StarryNet containers per worker for full Phase I完整第一期時 StarryNet 每台工作機的容器數	\(4{,}408 / 7\)	≈ 630computed, ^{[40, Tab. 2]}計算值，^{[40, Tab. 2]}
StarryNet bring-up time per satelliteStarryNet 每顆衛星的建立時間	\(21.2\,\text{min}\times 60 / 4{,}408\)	≈ 0.29 scomputed, same source計算值，同一來源
A 10-minute StarryNet experiment at 660 satellites, at the 79 s per simulated second xeoverse reports以 xeoverse 報告的每模擬秒 79 s 計，660 顆衛星的 10 分鐘 StarryNet 實驗	\(600\,\text{s}\times 79\)	47,400 s ≈ 13.2 hcomputed, 79 s from Kassem & Sastry, IFIP Networking 2024, §V-A, a third-party timing計算值，79 s 來自 Kassem & Sastry，IFIP Networking 2024，§V-A，為第三方量測
A 10-minute xeoverse experiment including pre-computation含預先計算的 10 分鐘 xeoverse 實驗	\(55\,\text{min} + 10\,\text{min}\)	≈ 65 mincomputed, 55 min at 100 ground segments and 50 flows from Fig. 4, which §V-A's text contradicts (Part C, item 44)計算值，100 個地面段、50 條流時的 55 min 來自 Fig. 4，而 §V-A 的正文與之矛盾（Part C，第 44 項）

7.1Three ways to get a number: measure, simulate, emulate取得數字的三種方式：量測、模擬、模擬平台

7.2Measurement platforms: dishes, Atlas, HitchHiking, LENS and IPv6 scans量測平台：碟形天線、Atlas、HitchHiking、LENS 與 IPv6 掃描

7.3Packet simulation: Hypatia封包模擬：Hypatia

7.4Emulation: StarryNet, Celestial, xeoverse and LeoEM模擬平台：StarryNet、Celestial、xeoverse 與 LeoEM

7.5Shared assumptions: laser rate, topology and scheduling共同假設：雷射速率、拓樸與排程

How wrong can a simulator be?模擬器可以錯多少？

7.6Checklist for reading a simulated result閱讀模擬結果的檢查清單

Papers behind this chapter本章所依據的論文

Check your understanding檢驗你的理解