Digest · Simulation and emulation · read after Chapter 7
導讀 · 模擬與模擬平台 · 第 7 章後閱讀
StarryNet: Empowering Researchers to Evaluate Futuristic Integrated Space and Terrestrial NetworksStarryNet：讓研究者能評估下一代整合式天地網路
This digest explains StarryNet’s container-based digital twin, its resource costs, and the scope of its validation. It also shows how user-selected ISL capacity affects the results.讀完後，你能說明星座的容器「數位分身」是什麼、為什麼在 4,408 顆模擬衛星上跑真實路由程式要花數分鐘建置與七台伺服器的三分之一資源，以及為什麼 StarryNet 的星間鏈路容量是你由使用者輸入。
Main result
主要結果
StarryNet runs real network stacks and optional flight hardware within a container-based constellation twin. Public inputs define geometry, while users supply the ISL capacity.
StarryNet 在容器星座分身中執行真實網路堆疊，也可接入飛行硬體，公開輸入決定幾何，ISL 容量則由使用者指定。
| Item項目 | Values數值 | Conditions and source條件與來源 |
|---|---|---|
| Evidence and scope | Qualitative scope | Hypatia simulates its own protocol models. StarryNet runs real implementations, allowing OSPF daemons, kernel TCP stacks and satellite flight computers inside a modeled constellation. |
| Evidence and scope | Qualitative scope | Regulatory filings, TLEs and ground-station lists define the digital twin. Skyfield computes position, visibility and distance-based delay. Docker supplies one container per satellite or station, connected through Open vSwitch. The tc utility applies link conditions. BIRD, iperf and real CubeSat hardware can therefore participate [40, §4]. |
| Latency comparison | 4,408 · 21.2 · 35–40% | On eight Dell R740 servers it brings up Starlink's full 4,408-satellite Phase I in 21.2 min using seven workers at roughly 35–40% CPU. Its latency distributions visually match a live Starlink terminal where Hypatia and StarPerf underestimate [40, Tab. 2, Fig. 6], with numeric error left unspecified. |
| Latency comparison | 15 | The authors state that Starlink lasers were "still under internal test". ISL capacity is "set by user-specific configurations". Acquisition and the 15-second schedule lie outside the stated model [40, §4.3.1, §8]. |
| 證據與範圍 | 定性範圍 | StarryNet 提供了 Hypatia 協定模型之外的能力：封包模擬器跑的是它自己的協定模型，所以想測試真實 OSPF 程式、核心 TCP 堆疊或衛星飛行電腦的研究者需要能執行實際程式的平台。 |
| 資料集與工作負載 | 定性範圍 | 這個工具把監管申請文件、公開 TLE 與地面站清單爬成一個「數位分身」，用 Skyfield 算出位置、可見性與依距離決定的延遲，然後為每顆衛星與每個地面站建立一個 Docker 容器，透過 Open vSwitch 連線並以 tc 施加鏈路條件，讓 BIRD、iperf 或一顆真實的 CubeSat 都能坐進模擬出的星座裡[40, §4]。 |
| 證據與範圍 | 35–40% · 21.2 · 4,408 | 在八台 Dell R740 伺服器上，它以七個工作節點、約 35–40% 的 CPU，花 21.2 分鐘建起 Starlink 完整的 4,408 顆 Phase I 星座，而它的延遲分布在圖上與一台真實 Starlink 終端吻合，Hypatia 與 StarPerf 則低估[40, Tab. 2, Fig. 6]，數值誤差則待補充。 |
| 證據與範圍 | 15 | 誠實的註腳在限制一節：因為 Starlink 的雷射「仍在內部測試」，星間容量「由使用者自訂設定」，而雷射建鏈延遲與 15 秒排程在均列於模型範圍之外[40, §4.3.1, §8]。 |
1. Where this paper sits1. 這篇論文的位置
StarryNet links data-based constellation models to real protocol implementations. Its later use in routing studies makes model scope and external validation central to interpreting results.
StarryNet 將資料驅動星座模型與真實協定實作連接起來，後續路由研究使用它時，模型範圍與外部驗證便成為解讀重點。
| Item項目 | Values數值 | Conditions and source條件與來源 |
|---|---|---|
| Evidence and scope | 2023 · 3 | StarryNet arrived in April 2023, eighteen months after Starlink began selling terminals and a few months after the first measurement papers of Chapter 3. Thus, it stands at the hinge between the modeling era and the measurement era. |
| Emulator goals | Qualitative scope | The authors describe live satellites as offering realism with limited flexibility, and simulators as offering flexibility with limited realism. They seek four properties: public-data constellation consistency, real system/network stacks, scalable flexible operation, and an open low-cost interface [40, §1, §3.1, Tab. 1]. |
| Evidence and scope | 1,741 | The Tsinghua group later develops SHORT and LeoCC. TinyLEO uses StarryNet for routing results on a 1,741-satellite emulation [39]. The platform therefore supports much of this Chinese LEO systems research. |
| Evidence and scope | 7 | It is also the first tool in this group to show a figure with live Starlink data on it. This explains why Chapter 7 treats it as the moment emulators started to be judged against the real network rather than against each other. |
| 證據與範圍 | 2023 · 4 · 3 | StarryNet 於 2023 年 4 月問世，距 Starlink 開始銷售終端已十八個月，也在第 3 章最早幾篇量測論文之後幾個月，所以它站在建模時代與量測時代的轉折點上。 |
| 證據與範圍 | 定性範圍 | 清華的作者們把這個領域的工具處境描述成一個兩難，真實衛星「有真實性但缺乏彈性」，模擬器「有彈性但缺乏真實性」，於是他們為任何想逃出這個兩難的工具訂下四項要求：與公開資料一致的星座、系統與網路協定堆疊的真實性、彈性且可擴展的環境，以及開放低成本的介面[40, §1, §3.1, Tab. 1]。 |
| 證據與範圍 | 1,741 | 同一團隊後來做出 SHORT 路由階層與 LeoCC 壅塞控制器，並把 StarryNet 當成 TinyLEO 的評估平台，該論文的路由結果建立在一次 1,741 顆衛星的模擬上[39]，這使 StarryNet 成為如今大多數中國 LEO 系統文獻所依賴的模擬平台。 |
| 證據與範圍 | 7 | 它也是這一組工具中第一個在圖上放進真實 Starlink 資料的，因此第 7 章把它視為模擬平台開始以真實網路作為評判標準的起點。 |
2. The problem, measured2. 問題，用量測說話
The validation overlays modeled and measured access-path distributions. It supports a qualitative ground-segment comparison, while numeric error and laser-link validation remain open.
驗證將模型與實測接入路徑分布疊圖比較，支持定性的地面段核對，數值誤差及雷射鏈路驗證則待補充。
| Item項目 | Values數值 | Conditions and source條件與來源 |
|---|---|---|
| Evidence and scope | Qualitative scope | The paper's measurement of the problem is a measurement of other tools. |
| Evidence and scope | 1 | Table 1 lines up live LEO networks, orbital analysis packages such as STK and GMAT, network simulators such as SNS3, Hypatia and StarPerf |
| Evidence and scope | Qualitative scope | and generic emulators such as Mininet, DieCast and Etalon |
| Evidence and scope | Qualitative scope | Each alternative leaves part of the requirements open. Orbital packages exclude network stacks, while simulators replace real stacks with models. |
| Orbital configuration | Qualitative scope | and the generic emulators require an external orbit model [40, §3.1, Tab. 1]. |
| Latency comparison | 6.2 · 6 · 50 · 70 · 90 | Section 6.2 compares live Starlink RTT with StarryNet, Hypatia and StarPerf. Figure 6 shows means and 50th, 70th and 90th percentiles. StarryNet tracks the curve, while the simulators "underestimate the latency". |
| Latency comparison | 7 · 8 · 9 · 4B | Figure 7 compares throughput, and Fig. 8 compares ISL-topology latency CDFs. StarryNet is "slightly higher than other simulators". Figure 9 compares emulated CoreMark scores with Raspberry Pi 4B and Jetson TX2. |
| Dataset and workload | 20 · 200 | All comparisons come from plots, with millisecond error unspecified. Live validation uses one bent-pipe terminal with trace-derived 20 Mbps uplink and 200 Mbps downlink [40]. This supports ground-segment fidelity, while ISL assumptions require separate validation. |
| 證據與範圍 | 定性範圍 | 這篇論文對問題的量測，其實是對其他工具的量測。 |
| 證據與範圍 | 1 | Table 1 把真實 LEO 網路、STK 與 GMAT 等軌道分析套件、SNS3、Hypatia 與 StarPerf 等網路模擬器，以及 Mininet、DieCast 與 Etalon 等通用模擬平台排在一起，發現各工具都僅滿足部分要求，因為軌道套件將網路堆疊列於範圍之外，模擬器把堆疊抽象成模型，而通用模擬平台需要外部軌道模型[40, §3.1, Tab. 1]。 |
| 延遲比較 | 6.2 · 6 · 50 · 70 · 90 | §6.2 的擬真度實驗接著把這件事變成某種數字，Fig. 6 並列一台真實 Starlink 終端的平均與第 50、70、90 百分位 RTT 以及 StarryNet、Hypatia 與 StarPerf，StarryNet 貼著實測曲線，而兩個模擬器「低估了延遲」。 |
| 證據與範圍 | 7 · 8 · 9 · 4B | Fig. 7 對吞吐量做同樣的事，Fig. 8 則是 ISL 拓樸的延遲 CDF，StarryNet 在那裡「略高於其他模擬器」，Fig. 9 比較模擬節點與 Raspberry Pi 4B 及 Jetson TX2 的 CoreMark 分數。 |
| 證據與範圍 | 20 · 200 | 這些比較每一項都是從圖上讀出來的，因為正文的毫秒誤差待補充，而真實對照是一台終端的彎管路徑，上下行依追蹤資料設成 20 Mbps 與 200 Mbps[40]，所以這個吻合證明的是地面段模型合理，，ISL 假設則需另行檢驗。 |
3. The design3. 設計
The observer gathers public inputs, the synchronizer computes geometry and link conditions, and the orchestrator applies them to containers. Hardware can replace an emulated node through the same interface.
觀察器蒐集公開輸入，同步器計算幾何及鏈路條件，協調器再將其套用到容器，硬體也能經相同介面替換模擬節點。
| Item項目 | Values數值 | Conditions and source條件與來源 |
|---|---|---|
| Evidence and scope | Qualitative scope | Figure A shows the three components that the paper names and the data flow between them. |
| Orbital configuration | Qualitative scope | Constellation Observer gathers filings, TLEs, station lists and user measurements. Its digital twin represents a particular filed or deployed constellation at a specific time. This differs from an idealized Walker pattern [40, §4.1]. |
| Latency comparison | Qualitative scope | Constellation Synchronizer computes time-varying positions, visibility and delay. Four models cover constellation, ground stations, networking and computation. Skyfield propagates orbits [40, §4.2–4.3, §5]. |
| Latency comparison | Qualitative scope | Constellation Orchestrator deploys a container per satellite or station across worker machines. Open vSwitch connects containers, with VLAN isolation across machines. The tc utility applies computed delay and capacity. A unified API and the sn shell load software, inject failures and collect traces. |
| Evidence and scope | 6,500 | The whole system is about 6,500 lines of Python [40, §4.4, §5]. |
| Orbital configuration | 2019 | ISLs use +Grid or CoNEXT 2019 motifs. The +Grid connects two same-orbit neighbors and one neighbor in each adjacent orbit. Stations select the nearest satellite or longest remaining contact [40, §4.3.1]. |
| Power and thermal conditions | 7.3 · 3 · 1,583 · 2.83 W · 5.46 W · 100–1,000 | Container nodes can be replaced by hardware. Section 7.3 connects a 3U CubeSat prototype to a 1,583-node shell. Power rises from 2.83 W idle to 5.46 W at 100–1,000 Mbps [40, Tab. 4]. |
| 證據與範圍 | 定性範圍 | 圖 A 畫出論文命名的三個元件以及它們之間的資料流。 |
| 資料集與工作負載 | 定性範圍 | 星座觀察器 (Constellation Observer) 收集公開輸入，也就是規劃幾何的監管申請文件、已在飛行衛星的 TLE、地面站清單與使用者量測，這正是作者所謂數位分身的意思：被模擬的網路應該是某個特定真實或已申請星座在特定時間的複本，，理想 Walker 圖樣則是另一種輸入[40, §4.1]。 |
| 證據與範圍 | 定性範圍 | 星座同步器 (Constellation Synchronizer) 透過星座、地面站、網路與運算四個模型，把這些輸入轉成位置、可見關係與鏈路延遲的時間序列，軌道傳播由 Skyfield 完成[40, §4.2–4.3, §5]。 |
| 證據與範圍 | 定性範圍 | 星座協調器 (Constellation Orchestrator) 接著在叢集上實現每個時間步，每顆衛星或地面站一個 Docker 容器，分散在多台工作機上，容器之間以 Open vSwitch 連線並跨機器用 VLAN 隔離，tc 施加同步器算出的延遲與容量，而統一的 API 與名為 sn 的互動式 shell 讓研究者載入軟體、注入故障並收集追蹤。 |
| 證據與範圍 | 6,500 | 整個系統約 6,500 行 Python[40, §4.4, §5]。 |
| 證據與範圍 | 2019 | 星間鏈路採 +Grid，每顆衛星連到同軌道的兩顆鄰居與相鄰兩軌道各一顆，或改用 CoNEXT 2019 論文的 motif 圖樣，地面站則連到最近的衛星或剩餘可見時間最長的那一顆[40, §4.3.1]。 |
| 電力與熱條件 | 7.3 · 3 · 1,583 · 2.83 W · 100–1,000 · 5.46 W | 因為每個節點都是容器，硬體可以取代任一節點，論文 §7.3 的案例研究把一個 3U CubeSat 原型接進 1,583 個節點的模擬殼層，量到它閒置時 2.83 W、在 100–1,000 Mbps 時升到 5.46 W 的功耗[40, Tab. 4]。 |
Original figure note原始圖說出處
Drawn for this primer from Lai et al., NSDI 2023, Fig. 1, §4–§6.1 and Table 2.4. Evaluation setup4. 實驗設定
Real software runs against a user-configured network on a server cluster. Live comparison covers a bent-pipe terminal path, while ISL settings and acquisition need additional evidence.
實際軟體在伺服器叢集上搭配使用者設定網路執行，真實對照涵蓋彎管終端路徑，ISL 設定及擷取則需額外證據。
| Item項目 | Values數值 | Conditions and source條件與來源 |
|---|---|---|
| Dataset and workload | Qualitative scope | StarryNet is emulation, so its results are measurements of real software running against a modeled network, and the table below records what that network is. |
| Evidence and scope | 5222 · 3.8 · 32 GB · 50% · 20.04 | Eight Dell R740 servers run Ubuntu 20.04. Each has two four-core Intel Xeon 5222 processors at 3.8 GHz and eight 32 GB DDR4 modules. Resource caps permit 50% of each machine's CPU and memory [40, §6]. |
| Orbital configuration | 2 · 351 · 4,408 | The constellations in Table 2 are the usual frozen filings, from Telesat's 351-satellite T1 shell to the full five-shell Starlink Phase I of 4,408 satellites. |
| Evidence and scope | Qualitative scope | Two cells in the table deserve emphasis. |
| Capacity and rate | Qualitative scope | The inter-satellite link rate is a user input. The authors state that Starlink's laser parameters were "still under internal test" and therefore "link capacity is set by user-specific configurations". Thus, every throughput number across an ISL path in a StarryNet study is a consequence of whatever the user typed [40, §4.3.1, §8]. |
| Dataset and workload | 20 · 200 | Live validation overlays RTT and throughput CDFs from one bent-pipe terminal. Trace-derived rates are 20 Mbps up and 200 Mbps down [40, Fig. 6, Fig. 7]. This checks ground-segment behavior, leaving lasers, acquisition and scheduling outside the validation scope. |
| 證據與範圍 | 定性範圍 | StarryNet 是模擬平台 (emulation)，所以它的結果是真實軟體對著建模出來的網路跑出的量測，下表記錄那個網路是什麼。 |
| 證據與範圍 | 3.8 · 5222 · 32 GB · 50% · 20.04 | 測試平台是八台 Dell R740 伺服器，每台有兩顆 3.8 GHz 的四核心 Intel Xeon 5222 處理器與八條 32 GB DDR4 記憶體，每台機器的 CPU 與記憶體上限設為 50%，作業系統為 Ubuntu 20.04[40, §6]。 |
| 證據與範圍 | 2 · 351 · 4,408 | Table 2 的星座是一貫的凍結申請文件，從 Telesat 351 顆的 T1 殼到完整五層殼、4,408 顆的 Starlink Phase I。 |
| 證據與範圍 | 定性範圍 | 表中有兩格值得強調。 |
| 證據與範圍 | 定性範圍 | 論文待補充星間鏈路速率，因為作者說明 Starlink 的雷射參數「仍在內部測試」，因此「鏈路容量由使用者自訂設定」，所以任何 StarryNet 研究中跨 ISL 路徑的吞吐量數字，都是使用者輸入了什麼的結果[40, §4.3.1, §8]。 |
| 延遲比較 | 20 · 200 | 而對照真實 Starlink 的驗證，是把單一終端在彎管路徑上的 RTT 與吞吐量 CDF 疊在圖上，上下行依追蹤資料本身設為 20 與 200 Mbps[40, Fig. 6, Fig. 7]，這是對地面段模型合理的檢查，雷射鏈路、擷取與排程器則需另外驗證，這三項仍待模型細節補充。 |
| Assumption假設 | StarryNet [40]StarryNet[40] |
|---|---|
| Method方法 | Container emulation. One Docker container per node, Open vSwitch links, tc for delay and rate. Real stacks such as BIRD/OSPF. Hardware in the loop [40, §4, §5]容器模擬平台。每個節點一個 Docker 容器，Open vSwitch 鏈路，tc 設定延遲與速率。BIRD/OSPF 等真實堆疊。硬體在環[40, §4, §5] |
| Constellation星座 | Starlink S1 72×22 at 550 km, 53° (1,584). S2 72×22 at 540 km, 53.2°. Full Phase I 4,408 in five shells. Kuiper K1 34×34 at 630 km, 51.9°. Telesat T1 27×13 at 1,015 km, 98.98° [40, Tab. 2]Starlink S1 於 550 km、53° 的 72×22（1,584 顆）。S2 於 540 km、53.2° 的 72×22。完整 Phase I 五層殼 4,408 顆。Kuiper K1 於 630 km、51.9° 的 34×34。Telesat T1 於 1,015 km、98.98° 的 27×13[40, Tab. 2] |
| ISL topologyISL 拓樸 | +Grid with four ISLs per satellite, or motif patterns. GS attachment by shortest distance or longest remaining visibility [40, §4.3.1]每顆衛星四條 ISL 的 +Grid，或 motif 圖樣。地面站依最短距離或最長剩餘可見時間連線[40, §4.3.1] |
| Default ISL rate預設 ISL 速率 | None. "set by user-specific configurations" because Starlink lasers were "still under internal test". Live comparison used 20/200 Mbps up/down on the ground link [40, §4.3.1, §8]使用者指定。因 Starlink 雷射「仍在內部測試」而「由使用者自訂設定」。真實對照在地面鏈路使用 20/200 Mbps 上下行[40, §4.3.1, §8] |
| Latency model延遲模型 | Propagation delay from the physical distance between link ends, applied by tc and refreshed at a 1–3 s update interval. PHY effects excluded [40, §4.3.1, §6.1, §8]以鏈路兩端的物理距離計算傳播延遲，由 tc 施加並以 1–3 s 的更新間隔刷新。PHY 效應列於範圍之外[40, §4.3.1, §6.1, §8] |
| Laser setup delay雷射建鏈延遲 | Scope unspecified anywhere in the paper全文將此項留待指定 |
| 15-s schedule15 秒排程 | Scope unspecified anywhere in the paper全文將此項留待指定 |
| Validation vs live Starlink對照真實 Starlink 的驗證 | Qualitative: average and p50/p70/p90 RTT and throughput CDFs of one terminal on a bent-pipe path overlaid on StarryNet, Hypatia and StarPerf. Printed error pending [40, §6.2, Figs. 6–7]定性：單一終端在彎管路徑上的平均與 p50/p70/p90 RTT 及吞吐量 CDF，疊在 StarryNet、Hypatia 與 StarPerf 上。誤差數字待補充[40, §6.2, Figs. 6–7] |
5. What was measured5. 量到了什麼
The routing case study shows how architecture and OSPF convergence interact. Its latency and reachability results belong to the selected model and link configuration.
路由案例顯示架構與 OSPF 收斂如何互相影響，延遲及可達性結果應依所選模型與鏈路配置解讀。
| Item項目 | Values數值 | Conditions and source條件與來源 |
|---|---|---|
| Evidence and scope | 7.1 | The paper's own results divide into scalability, fidelity and three case studies. The most instructive of these is the routing comparison in §7.1. This occurs because it is the kind of experiment only an emulator with real daemons can run. |
| Evidence and scope | 1 | BIRD runs OSPF in each Starlink shell 1 container. Four architectures use ground-only satellite relay, ground-assisted satellite relay, ground-station-centric ISLs, and distributed ISLs with frequent address updates. |
| Latency comparison | 183.25 · 313.39 · 106.91 · 86.11 ms · 97.00 · 51.00 · 57.40 · 97.50% | In that order, mean latencies are 183.25, 313.39, 106.91 and 86.11 ms. Reachability is 97.00%, 51.00%, 57.40% and 97.50%. The authors find tradeoffs across the four architectures [40, Tab. 3]. |
| Evidence and scope | 3 · 25–50 ms | The absolute latencies are large by the standards of Chapter 3's 25–50 ms measured medians |
| OSPF and configured links | Qualitative scope | and they depend on OSPF convergence behavior over a topology refreshed every few seconds and on user-chosen link parameters |
| Latency comparison | Qualitative scope | The comparison demonstrates interactions between architecture and protocol dynamics. These modeled outcomes require separate evidence before predicting deployed Starlink latency. |
| 證據與範圍 | 7.1 | 論文自己的結果分為可擴展性、擬真度與三個案例研究，其中最有教育意義的是 §7.1 的路由比較，因為那是只有帶著真實路由程式的模擬平台才能跑的實驗。 |
| 證據與範圍 | 定性範圍 | 四種路由架構被部署在 Starlink 第一層殼上，每個容器內以 BIRD 執行 OSPF：僅用地面鏈路 的衛星中繼設計、有地面站協助的衛星中繼設計、走 ISL 的地面站中心設計，以及走 ISL 且頻繁更新位址的分散式設計。 |
| 證據與範圍 | 183.25 · 313.39 · 106.91 · 86.11 ms · 97.00 · 51.00 · 57.40 · 97.50% | 平均端到端延遲各自為 183.25、313.39、106.91 與 86.11 ms，可達性各自為 97.00、51.00、57.40 與 97.50%，作者認為四種架構各有取捨[40, Tab. 3]。 |
| 證據與範圍 | 3 · 25–50 ms | 以第 3 章實測中位數 25–50 ms 的標準來看，這些絕對延遲都很大，而且它們取決於 OSPF 在每幾秒刷新一次的拓樸上的收斂行為以及使用者選定的鏈路參數，所以這張表最好讀成一個示範，證明架構選擇會與協定動態以超出純傳播計算範圍的方式互動，，Starlink 實際延遲則需另外的驗證。 |
| Claim宣稱 | Setup and caveat設定與附註 |
|---|---|
| Full Starlink Phase I, 4,408 satellites, created in 21.2 min on 7 workers at 39.6/37.0/34.3% CPU and 10.4/9.1/8.9% memory for 1/2/3 s update intervals [40, Tab. 2]完整 Starlink Phase I 4,408 顆，7 台工作機上 21.2 分鐘建成，1/2/3 s 更新間隔下 CPU 39.6/37.0/34.3%、記憶體 10.4/9.1/8.9%[40, Tab. 2] | Dell R740 cluster with 50% resource cap. Creation time, creation time, with emulation speed separate. Xeoverse later measured StarryNet at up to 79 s per emulated second at 660 satellites [80]資源上限 50% 的 Dell R740 叢集。這是建置時間，模擬速度則另計。xeoverse 後來量到 StarryNet 在 660 顆衛星時每模擬秒最多需要 79 s[80] |
| Starlink S1, 1,584 satellites, on 2 workers in 10.5 min (5.9 min nodes + 4.6 min links) at 7.2/7.0/6.3% CPU [40, Tab. 2]Starlink S1 1,584 顆，2 台工作機 10.5 分鐘（節點 5.9 + 鏈路 4.6），CPU 7.2/7.0/6.3%[40, Tab. 2] | Shows that link creation is almost half the cost. TinyLEO later ran 1,741 satellites on the same platform [39]顯示鏈路建立幾乎佔一半成本。TinyLEO 後來在同一平台上跑了 1,741 顆衛星[39] |
| RTT average and p50/p70/p90 match live Starlink while Hypatia and StarPerf underestimate [40, Fig. 6]RTT 平均與 p50/p70/p90 吻合真實 Starlink，而 Hypatia 與 StarPerf 低估[40, Fig. 6] | One terminal, bent pipe, 20/200 Mbps configured from the trace. Read from a plot, numeric error pending單一終端、彎管、依追蹤資料設定 20/200 Mbps。從圖上讀出，數值誤差待補充 |
| Four routing designs over OSPF/BIRD: 183.25 / 313.39 / 106.91 / 86.11 ms average latency, 97.00 / 51.00 / 57.40 / 97.50% reachability [40, Tab. 3]四種 OSPF/BIRD 路由設計：平均延遲 183.25 / 313.39 / 106.91 / 86.11 ms，可達性 97.00 / 51.00 / 57.40 / 97.50%[40, Tab. 3] | Starlink shell 1. The two ISL-based designs are the ones whose numbers depend on the user-set ISL capacityStarlink 第一層殼。兩個走 ISL 的設計其數字取決於使用者設定的 ISL 容量 |
| Random satellite failures at 10/20/30%: OSPF recovery time grows with constellation size and failure ratio, and latency "dramatically increases" at 30% [40, Figs. 11–12]10/20/30% 的隨機衛星故障：OSPF 復原時間隨星座規模與故障比例成長，30% 時延遲「急遽增加」[40, Figs. 11–12] | Values appear only in figures. A result about OSPF rather than about any flown recovery mechanism數值僅見於圖。這是關於 OSPF 的結果，，實際飛行復原機制仍需另外驗證 |
| Hardware in the loop: 1,583 emulated nodes plus one 3U CubeSat drawing 2.83 W idle to 5.46 W at 100–1,000 Mbps [40, Tab. 4]硬體在環：1,583 個模擬節點加一顆 3U CubeSat，閒置 2.83 W 到 100–1,000 Mbps 時 5.46 W[40, Tab. 4] | Demonstrates the interface rather than a networking result. The exact column mapping of Table 4 is hard to recover from the PDF展示的是介面，網路結果則待量測。Table 4 的欄位對應難以從 PDF 精確還原 |
6. Limits and open questions6. 範圍與待解問題
- ISL capacity is user-configured because Starlink lasers were "still under internal test" [40, §4.3.1, §8]. Acquisition delay and range cutoff remain unspecified. The default +Grid therefore has four permanently available lasers at the selected rate. Current Starlink has three terminals and proprietary topology [39, §6.1]. Chapter 5 treats this wiring as a legacy baseline.星間鏈路是一個由使用者填入的空格。因為 Starlink 的雷射「仍在內部測試」，所以預設容量待指定，論文也雷射建鏈延遲與 ISL 距離上限待指定[40, §4.3.1, §8]，因此每一個 StarryNet 的 ISL 研究實際評估的，都是四條永遠亮著、速率由實驗者任意輸入的 +Grid。目前的 Starlink 衛星只有三個終端且拓樸待公開[39, §6.1]，這把預設佈線放進了第 5 章的過時欄位。
- The live comparison uses one bent-pipe terminal with trace-fitted ground rates. CDF overlap is assessed visually, with printed error pending [40, §6.2, Figs. 6–7]. The 15-second schedule governing measured variability lies outside the model [13]. Agreement therefore covers the propagation-plus-queue envelope, while temporal structure needs separate validation.擬真度的宣稱是定性且狹窄的。真實對照是單一終端在彎管路徑上、地面鏈路依追蹤資料設定，以肉眼判斷 CDF 重疊且誤差待補充[40, §6.2, Figs. 6–7]，而主導實測變動的 15 秒排程[13]列於模型範圍之外，所以吻合的是傳播加佇列的包絡，，使用者實際經歷的時間結構則需另行驗證。
- Xeoverse reports up to 79 s per simulated second at 660 satellites, with 1,323 threads. A Linux bridge limit caps one machine near 1,023 containers [80, §V-A]. Cionca et al. find mainline Docker-CLI setup "almost 10x longer" than alternatives. A ten-hop ISL path gives "very unstable" 200–300 ms RTT. StarryNet-dev performs best using Netlink, with its root filesystem supplied separately [81] preprint.獨立的重新評估顯示速度與穩定性受限。xeoverse 量到 StarryNet 在 660 顆衛星時模擬一秒最多要 79 s，產生 1,323 個執行緒，而且因為 Linux bridge 的限制在單機上的規模上限約為 1,023 個容器[80, §V-A]，Cionca 等人則發現主線 StarryNet 以 Docker CLI 啟動比其他模擬平台「慢了近 10 倍」，一條十跳的 ISL 路徑顯示 200–300 ms 且「大幅變動」的 RTT，而以 Netlink 為基礎的 StarryNet-dev 分支表現最好，根檔案系統則需另行提供[81]preprint。
- Cionca et al. find each existing emulator differs from real-world measurements. They also find constellation update delays can exceed fixed bounds [81] preprint. Updating thousands of tc rules every 1–3 s therefore requires timing validation. The emulated state must be checked against the state computed by the synchronizer.同一比較發現，每個現有模擬平台的結果都與真實量測存在差距，且星座更新延遲可超出固定界限[81]preprint，這直接套用了第 7 章的盲點：一個每 1–3 s 在數千個容器上更新 tc 規則的模擬平台，需要時序驗證才能確認在任一瞬間模擬出的網路處於同步器算出的狀態。
- Public TLE position error can reach 12 km. Virtualization has limited fidelity for spectrum adaptation and dish detection, and cluster resources bound scale [40, §8]. Cite the 86–313 ms routing latencies and 51–97.5% reachability as OSPF behavior on a modeled topology.作者自己的限制說得坦白：公開 TLE 誤差可達 12 km，虛擬化重現頻譜調適或天線偵測時間等實體層行為的能力有限，規模受叢集資源限制[40, §8]。因此路由案例研究中 86–313 ms 的延遲與 51–97.5% 的可達性，應該被引用為建模拓樸上的 OSPF 行為，其證據範圍限於該模型。
- The authors leave live-comparison error, ISL rate, per-hop delay and wall-clock cost per simulated second unspecified. Later studies measure computational cost independently.缺少的數字：真實對照的毫秒誤差、ISL 速率、每跳處理延遲，以及作者叢集每模擬秒的實際耗時都待補充，而後續論文因此自行量測這些數值。
7. How it connects7. 與其他內容的關聯
- Section 7.4 lists StarryNet with 4,408 satellites created in 21.2 min. ISL rate is user-set, while acquisition and scheduling lie outside the model.第 7.4 節：StarryNet 是該章模擬平台表的第一列，包括 21.2 分鐘內的 4,408 顆衛星、使用者設定的 ISL 速率以及缺席的建鏈延遲與排程。
- Section 7.3: the Fig. 6 comparison in which Hypatia underestimates live RTT is the chapter's bridge from packet simulation to emulation.第 7.3 節：Fig. 6 中 Hypatia 低估真實 RTT 的比較，是該章從封包模擬過渡到模擬平台的橋。
- Section 7.5 pairs the "under internal test" laser statement with Cionca et al.'s validation assessment. Both identify the validation and parameter gap.第 7.5 節：「仍在內部測試」這句話是文獻中對雷射速率待確認最清楚的承認，Cionca 等人對量測差距的評估則是由第三方說出的共同盲點。
- Section 5.4 compares four routing architectures using real OSPF daemons. TinyLEO also produces its SRv6 anycast results on this platform.第 5.4 節：四種架構的 OSPF 研究是唯一以真實路由程式發表的路由架構對決，TinyLEO 的 SRv6 anycast 結果也是在這個平台上產生的。
- Section 6.1 explains kernel congestion-control experiments. Reproducing measured RTT steps and capacity swings requires adding the 15-s schedule. LeoEM provides that transport-focused model.第 6.1 節：容器模擬平台能跑核心層的壅塞控制器，重現這些追蹤還需加入 15 秒排程，才能涵蓋該章實測追蹤中的 RTT 階躍與容量擺盪，這正是 傳輸層社群選用 LeoEM 作為測試平台的原因。
- Sibling digests: Hypatia is the packet simulator StarryNet positions itself against. Celestial makes the opposite trade, microVMs for compute realism with a simplified link graph. xeoverse claims 40× StarryNet's speed by pre-computing topology. TinyLEO is the largest study built on StarryNet, and SaTCP / LeoEM is the emulator that does model the 15-s schedule.同組導讀：Hypatia 是 StarryNet 用來對照的封包模擬器。Celestial 做了相反的取捨，以微型虛擬機換取運算真實性而簡化鏈路圖。xeoverse 宣稱靠預先計算拓樸達到 StarryNet 40 倍的速度。TinyLEO 是建立在 StarryNet 上規模最大的研究，SaTCP / LeoEM 則是確實建模 15 秒排程的模擬平台。
Key numbers關鍵數字
| Number | 數字 | Meaning (setup) | 意義（設定） |
|---|---|---|---|
| 4,408 | Satellites in the full Starlink Phase I twin, five shells, on 7 workers [40, Tab. 2] | 完整 Starlink Phase I 分身的衛星數，五層殼，7 台工作機[40, Tab. 2] | |
| 21.2 min | Creation time for the 4,408-node twin. 10.5 min for the 1,584-node S1 shell on 2 workers [40, Tab. 2] | 4,408 節點分身的建置時間。1,584 節點 S1 殼在 2 台工作機上為 10.5 分鐘[40, Tab. 2] | |
| 39.6–34.3% | CPU on 7 workers for the full twin at 1–3 s update intervals. Memory 10.4–8.9% [40, Tab. 2] | 完整分身在 1–3 s 更新間隔下 7 台工作機的 CPU。記憶體 10.4–8.9%[40, Tab. 2] | |
| 8 × R740 | Testbed: Dell R740, 2× Xeon 5222 (4-core, 3.8 GHz), 8×32 GB each, 50% resource cap [40, §6] | 測試平台：Dell R740，每台 2× Xeon 5222（4 核、3.8 GHz）、8×32 GB，資源上限 50%[40, §6] | |
| user-set | ISL capacity, because Starlink lasers were "still under internal test" [40, §4.3.1, §8] | ISL 容量，因為 Starlink 雷射「仍在內部測試」[40, §4.3.1, §8] | |
| 20 / 200 Mbps | Up/down ground-link rates configured from the trace for the live comparison [40] | 真實對照中依追蹤資料設定的地面鏈路上下行速率[40] | |
| 86.11–313.39 ms | Average latency across four OSPF routing architectures on shell 1. Reachability 51.00–97.50% [40, Tab. 3] | 第一層殼上四種 OSPF 路由架構的平均延遲。可達性 51.00–97.50%[40, Tab. 3] | |
| ≤12 km | Position error the authors attribute to public TLEs [40, §8] | 作者歸因於公開 TLE 的位置誤差[40, §8] | |
| 79 s | Wall-clock time per emulated second at 660 satellites, measured by xeoverse [80] | 660 顆衛星時每模擬秒的實際時間，由 xeoverse 量測[80] | |
| 2.83–5.46 W | Power draw of the hardware-in-the-loop 3U CubeSat from idle to 100–1,000 Mbps [40, Tab. 4] | 硬體在環 3U CubeSat 從閒置到 100–1,000 Mbps 的功耗[40, Tab. 4] |