Digest · Simulation and emulation · read after Chapter 7
導讀 · 模擬與模擬平台 · 第 7 章後閱讀
Celestial: Virtual Software System Testbeds for the LEO EdgeCelestial：LEO 邊緣的虛擬軟體系統測試平台
This digest explains Celestial’s per-satellite virtual machines and how geographic suspension reduces their resource cost. It also defines the evidence needed to extend self-consistency checks to inter-satellite network validation.讀完後，你能說明為什麼做邊緣運算的研究者想要每顆衛星一台完整的虛擬機、Celestial 如何靠暫停服務範圍外的微型虛擬機讓 4,409 台維持在負擔得起的範圍，以及為什麼一個準確度只對照過自身模擬的測試平台回答星間鏈路問題仍需額外驗證。
Main result
主要結果
Celestial runs satellite software in bounded virtual machines and suspends nodes outside a geographic study region. Its application results use modeled paths and a self-consistency validation.
Celestial 在資源受限的虛擬機內執行衛星軟體，並暫停地理研究範圍外的節點，應用結果採用模型路徑及自我一致性驗證。
| Item項目 | Values數值 | Conditions and source條件與來源 |
|---|---|---|
| Evidence and scope | Qualitative scope | Celestial is a testbed for satellite software, with one operating-system image per emulated node. |
| Evidence and scope | 2–5 s | Each satellite and ground station runs a Firecracker microVM with its own kernel. Every 2–5 s, a coordinator uses SGP4 to update positions. It calculates available radio and laser links and their light-travel delays. |
| Reliability and accuracy | 0.1 ms | and tc-netem imposes those delays with 0.1 ms accuracy on the virtual links between microVMs |
| Evidence and scope | 4,409 | while a geographic bounding box suspends every microVM outside the region under study so that a 4,409-satellite Starlink constellation fits on three cloud hosts [79, §3, §4]. |
| Latency comparison | 16 ms · 80% · 46 ms · 22–183 ms · 13–90 ms | The main results concern edge applications. Satellite-hosted WebRTC keeps maximum RTT within 16 ms for at least 80% of a session, compared with 46 ms from Johannesburg [79, Fig. 4]. Satellite-hosted inference reduces end-to-end latency from 22–183 ms to 13–90 ms [79, Fig. 11]. |
| Evidence and scope | 3.30 · 539.66 | and a ten-minute run costs $3.30 against at least $539.66 for one cloud VM per satellite [79, §4.2]. |
| Evidence and scope | 2022 · 10.1145/3528535 | The venue is ACM/IFIP Middleware 2022, which the DOI prefix 10.1145/3528535 confirms, and the venue confirmed by its DOI. |
| Latency comparison | 10 Gb/s · 100 Mb/s · 2026 | Inter-satellite links are flat 10 Gb/s or 100 Mb/s pipes with acquisition delay and scheduling excluded, accuracy was validated only against the authors' own simulation. A 2026 comparison found that the network layer uses a star topology, which limits ISL fidelity [81] preprint. |
| 證據與範圍 | 定性範圍 | Celestial 以每個模擬節點一份作業系統映像，測試預計在衛星上執行的軟體。 |
| 證據與範圍 | 2–5 s · 0.1 ms · 4,409 | 每顆衛星與每個地面站都成為一台有自己核心的 Firecracker 微型虛擬機 (microVM)，協調器每 2–5 s 以 SGP4 傳播星座並算出哪些雷射與射頻鏈路存在、光要花多久穿越它們，tc-netem 再以 0.1 ms 的精度把這些延遲施加在微型虛擬機之間的虛擬鏈路上，而一個地理邊界框會暫停所有在研究區域之外的微型虛擬機，讓 4,409 顆衛星的 Starlink 星座能塞進三台雲端主機[79, §3, §4]。 |
| 延遲比較 | 80% · 16 ms · 46 ms · 22–183 ms · 13–90 ms · 3.30 · 539.66 | 主要結果是關於邊緣應用，網路本身則需要另外驗證：由衛星提供的 WebRTC 會議在至少 80% 的時段內把最大 RTT 維持在 16 ms，而從 Johannesburg 雲端區域提供則是 46 ms[79, Fig. 4]，衛星上的推論把端到端延遲從 22–183 ms 降到 13–90 ms[79, Fig. 11]，一次十分鐘的執行花費 $3.30，相較之下每顆衛星一台雲端 VM 至少要 $539.66[79, §4.2]。 |
| 證據與範圍 | 2022 · 10.1145/3528535 | 發表場合是 ACM/IFIP Middleware 2022，DOI 前綴 10.1145/3528535 可以確認，以 DOI 對應的會議為準。 |
| 容量與速率 | 10 Gb/s · 100 Mb/s · 2026 | 星間鏈路是平坦的 10 Gb/s 或 100 Mb/s 管線，擷取延遲與排程列於模型之外，準確度只對照過作者自己的模擬，而一份 2026 年的比較發現其網路層的星狀拓樸對 ISL 的模擬準確度有限[81]preprint。 |
1. Where this paper sits1. 這篇論文的位置
Celestial’s unit of emulation is an operating-system image, matching its edge-computing purpose. Network-model detail and software realism therefore follow separate design priorities.
Celestial 以作業系統映像為模擬單位，符合其邊緣運算目的，因此網路模型細節與軟體真實性各有設計重點。
| Item項目 | Values數值 | Conditions and source條件與來源 |
|---|---|---|
| Evidence and scope | Qualitative scope | Celestial comes from the middleware and cloud-computing community rather than from networking, and that origin explains both its strengths and its blind spots. |
| Model and compute | 2021 | Pfandzelter and Bermbach had been arguing since 2021 that LEO constellations could host an edge-computing tier. This paper is the tool they built to test applications for that tier. This explains why its unit of emulation is an operating system image rather than a protocol model. |
| Model and compute | 2022 · 3 · 72 · 22 | It appeared in 2022, before any of the Starlink measurement papers of Chapter 3, so like Hypatia it belongs to the modeling era. Its network model is accordingly the +Grid of the 72 × 22 filing with speed-of-light delays. |
| Orbital configuration | 8 · 9 | The paper connects to Chapter 8’s orbital edge computing and Chapter 9’s in-orbit services. It compares service latency from satellites and a cloud region. |
| Evidence and scope | 7 | Chapter 7 compares Celestial with Hypatia, StarryNet, and xeoverse. Those tools emphasize link modeling, while Celestial emphasizes software execution. |
| Evidence and scope | 10.1145/3528535.3531517 · 2022 | The paper appears in ACM/IFIP Middleware 2022, under DOI 10.1145/3528535.3531517. This primer uses that venue to resolve occasional ICDCS attributions. |
| 證據與範圍 | 定性範圍 | Celestial 來自中介軟體與雲端運算社群，這個出身同時解釋了它的長處與盲點。 |
| 證據與範圍 | 2021 | Pfandzelter 與 Bermbach 從 2021 年起就主張 LEO 星座可以承載一層邊緣運算，而這篇論文是他們為了測試那一層的應用所建的工具，所以它模擬的單位是一個作業系統映像，協定在其中實際執行。 |
| 證據與範圍 | 2022 · 3 · 72 · 22 | 它發表於 2022 年，早於第 3 章的任何 Starlink 量測論文，因此和 Hypatia 一樣屬於建模時代，網路模型也就是 72 × 22 申請文件的 +Grid 加上光速延遲。 |
| 證據與範圍 | 8 · 9 · 7 | 在這本教材裡，它的自然鄰居是第 8 章的軌道邊緣運算與第 9 章的在軌服務，因為它回答的問題是把服務放在衛星上對使用者如何比放在雲端區域更快，而第 7 章的工具則是它與 Hypatia、StarryNet、xeoverse 比較的地方，那三者對鏈路的建模都更仔細，對軟體的建模則較少。 |
| 證據與範圍 | 10.1145/3528535.3531517 · 2022 | 關於引用需要說明一點：這篇論文有時被歸到 ICDCS，但 DOI 10.1145/3528535.3531517 屬於 ACM/IFIP Middleware 2022 的論文集，本教材也以此引用。 |
2. The problem, measured2. 問題，用量測說話
Geographic suspension makes large software experiments affordable. The paper validates added delay against its own model, with a live-network comparison still requiring separate evidence.
地理範圍暫停讓大型軟體實驗的成本可負擔，論文以自身模型核對附加延遲，實際網路比較則仍需另外的證據。
| Item項目 | Values數值 | Conditions and source條件與來源 |
|---|---|---|
| Cost assumptions | Qualitative scope | Celestial aims to run realistic satellite applications at an affordable resource cost. |
| Software execution | Qualitative scope | Satellite edge applications run across thousands of nodes with changing links. The authors execute actual application binaries and kernels against that changing network. This goal requires software execution beyond protocol models. |
| Cloud execution cost | 4.2 · 4,409 · 539.66 · 3.30 | Section 4.2 prices one cloud VM per satellite. A ten-minute experiment with 4,409 f1-micro instances would cost at least $539.66. Celestial uses three N2-highcpu hosts and a coordinator for $3.30, including five minutes of setup [79, §4.2]. |
| Evidence and scope | 6.1 · 4,400 · 8 GB · 36 TB | Section 6.1 estimates about 36 TB of RAM for 4,400 satellites with 8 GB per microVM. Suspending inactive nodes reduces this requirement. |
| Reliability and accuracy | Qualitative scope | The paper's second measurement is of its own accuracy. |
| Latency comparison | 5 | Fig. 5 compares the latency the testbed produces with the latency the coordinator expected from distance over c |
| Evidence and scope | 1.37 ms · 3.86 ms | and finds that measured values track expected ones with a median processing overhead of 1.37 ms and a baseline processing standard deviation of 3.86 ms |
| Reliability and accuracy | 6 · 2022 | This accuracy result compares Celestial with the authors’ own simulation. Section 6 identifies access to real LEO traces as a validation requirement in 2022. |
| 證據與範圍 | 定性範圍 | Celestial 要解決的是如何以可負擔的資源執行接近真實的衛星應用。 |
| 證據與範圍 | 定性範圍 | 給衛星用的邊緣應用是一個數千節點、網路每秒都在變的分散式系統，作者希望讓真實的應用程式二進位檔帶著真實核心對著那個變動的網路執行，這就排除了只建模協定的封包模擬器。 |
| 證據與範圍 | 4.2 · 4,409 · 539.66 · 3.30 | 顯而易見的替代方案是每顆衛星一台雲端 VM，§4.2 算了它的價格：把 4,409 顆 Starlink 衛星模擬成 f1-micro 實例，論文所跑的十分鐘實驗至少要花 $539.66，而 Celestial 自己在三台 N2-highcpu 主機加一台協調器上的執行含五分鐘建置只要 $3.30[79, §4.2]。 |
| 證據與範圍 | 6.1 · 4,400 · 8 GB · 36 TB | §6.1 的記憶體算術從另一端說同一件事：一個 4,400 顆衛星的星座若每台微型虛擬機 8 GB，需要約 36 TB 的 RAM，所以系統需要暫停閒置節點。 |
| 證據與範圍 | 定性範圍 | 論文的第二項量測是它自己的準確度。 |
| 證據與範圍 | 5 · 1.37 ms · 3.86 ms · 6 · 2022 | Fig. 5 比較測試平台產生的延遲與協調器依距離除以 c 所預期的延遲，發現量測值貼著預期值，處理開銷中位數 1.37 ms、基準處理標準差 3.86 ms，這是論文裡唯一的準確度數字，而且如 §6 所承認的，這是對照作者自己的模擬，因為 2022 年他們取得真實 LEO 追蹤資料仍待完成。 |
3. The design3. 設計
The coordinator derives link state from orbital geometry, while hosts run resource-bounded microVMs. Suspended nodes remain in path calculations so traffic leaving the study region retains modeled delays.
協調器從軌道幾何推導鏈路狀態，主機執行資源受限的微型虛擬機。暫停節點仍參與路徑計算，使離開研究區域的流量保有模型延遲。
| Item項目 | Values數值 | Conditions and source條件與來源 |
|---|---|---|
| Evidence and scope | Qualitative scope | Figure A shows the two halves of the system. |
| Model and compute | Qualitative scope | The coordinator holds the constellation model |
| Evidence and scope | Qualitative scope | which the authors extended from the SILLEO-SCNS simulator to propagate orbits with SGP4 |
| Orbital configuration | Qualitative scope | The coordinator calculates active links and their lengths at each update. Its +Grid connects each satellite to its predecessor, successor, and one neighbor in each adjacent plane. A configurable altitude threshold determines whether line of sight permits each link. |
| Evidence and scope | Qualitative scope | while ground-station links exist above a configurable minimum elevation [79, §2.1, §3]. |
| Latency comparison | 0.1 ms · 0.2 ms | Delays are the light-time over the geometric distance, for lasers in vacuum and for radio links alike. The coordinator pushes them to the hosts, where tc-netem applies them with 0.1 ms accuracy after subtracting the measured 0.2 ms host-to-host delay [79, §3, §4.1]. |
| Evidence and scope | 2 · 512 MB · 4 · 1 · 1,024 MB · 5 | Each host runs a Firecracker microVM for every assigned satellite or ground station. Section 4 uses 2 vCPU and 512 MB per VM. Section 5 uses 1 vCPU and 1,024 MB. |
| Model and compute | Qualitative scope | with cgroups bounding CPU and memory so that a satellite's software stays within the compute budget that its hardware model allows |
| Evidence and scope | Qualitative scope | and with fault injection available to kill or degrade nodes [79, §3, §4.1, §5.1]. |
| Evidence and scope | Qualitative scope | A latitude–longitude bounding box limits active microVMs. VMs outside the box retain their state while suspended. Path calculations still cover the constellation, which preserves modeled delay for packets that cross the box boundary. |
| Evidence and scope | 4 · 137 · 96 · 10% · 20% | In Section 4, the coordinator estimated a requirement of 137 cores, and the experiment used 96. MicroVM CPU use stayed near 10%, with memory below 20% of host capacity [79, §3, §4.2, Figs. 7–8]. |
| Software and network updates | 2–5 s | The platform runs WebRTC, inference servers, and sensor pipelines as actual software. The modeled network beneath these applications changes every 2–5 s. |
| 證據與範圍 | 定性範圍 | 圖 A 畫出系統的兩半。 |
| 證據與範圍 | 定性範圍 | 協調器持有星座模型，作者從 SILLEO-SCNS 模擬器擴充而來並以 SGP4 傳播軌道，從中在每個更新間隔推導出存在的鏈路集合與其長度：星間鏈路預期採 +Grid，連到前後衛星與相鄰兩軌道面各一顆鄰居，當視線低於可設定的高度時就斷開，而地面站鏈路存在於可設定的最低仰角之上[79, §2.1, §3]。 |
| 證據與範圍 | 0.2 ms · 0.1 ms | 延遲是幾何距離上的光行時間，雷射在真空中與射頻鏈路一視同仁，協調器把它們推送到主機，tc-netem 在扣除量到的 0.2 ms 主機間延遲後以 0.1 ms 的精度施加[79, §3, §4.1]。 |
| 證據與範圍 | 4 · 2 · 512 MB · 5 · 1 · 1,024 MB | 主機是另一半：每台為每顆衛星或地面站執行一個 Firecracker 微型虛擬機，§4 實驗中配置 2 vCPU 與 512 MB，§5 案例研究中為 1 vCPU 與 1,024 MB，以 cgroups 限制 CPU 與記憶體，使衛星軟體運算量維持在硬體模型的允許範圍內，並提供故障注入來關閉或劣化節點[79, §3, §4.1, §5.1]。 |
| 證據與範圍 | 定性範圍 | 讓這個規模負擔得起的裝置是邊界框，一個經緯度矩形，框外的微型虛擬機暫停執行並保留狀態，而路徑計算仍涵蓋整個星座，所以離開框的封包仍看到正確的延遲。 |
| 證據與範圍 | 4 · 137 · 96 · 10% · 20% | 在 §4 實驗中協調器估計需要 137 個核心而實際使用 96 個，微型虛擬機的 CPU 維持在約 10%，記憶體低於主機的 20%[79, §3, §4.2, Figs. 7–8]。 |
| 證據與範圍 | 2–5 s | 結果是一個平台，原版的 WebRTC 堆疊、推論伺服器或感測器管線在上面跑起來就和在軌道上一樣，底下的網路則以 2–5 s 的節奏移動。 |
Original figure note原始圖說出處
Drawn for this primer from Pfandzelter & Bermbach, Middleware 2022, §3–§4.2 and §6.1.4. Evaluation setup4. 實驗設定
The experiments combine filed constellation geometry, fixed link-rate settings and real application software. Acquisition, detailed scheduling and external validation remain outside the stated model.
實驗結合申報星座幾何、固定鏈路速率設定與實際應用軟體，擷取、細部排程及外部驗證則列於所述模型範圍之外。
| Item項目 | Values數值 | Conditions and source條件與來源 |
|---|---|---|
| Evidence and scope | Qualitative scope | Celestial is emulation of software against a modeled network, and the table below collects the network assumptions a reader must carry. |
| Evidence and scope | 2.1 · 1 | The constellation of §2.1 and Fig. 1 is Starlink's Phase I as filed |
| Orbital configuration | 72 · 22 · 550 km · 53° · 1,600 · 400 · 375 · 450 · 1,110–1,325 km | The first shell has 72 planes of 22 satellites at 550 km and 53°. Four higher shells contain 1,600, 400, 375, and 450 satellites at 1,110–1,325 km. |
| Orbital configuration | 5 · 66 · 780 km · 90° | Section 5 uses an Iridium model with 66 satellites in six planes, at 780 km and 90° inclination. ISLs occupy one side of the seam [79, §2.1, §5]. |
| Latency comparison | 32 · 32 GB · 16 · 64 GB · 0.2 ms | The Starlink experiment uses three GCP N2-highcpu hosts, each with 32 vCPU and 32 GB. A C2 coordinator has 16 cores and 64 GB. Inter-host delay is 0.2 ms. The case study adds a fourth host [79, §4.1, §5.1]. |
| Latency comparison | 10 Gb/s · 4 · 100 Mb/s · 5 · 88 kb/s · 15 | The link model sets ISL and radio capacity to 10 Gb/s in Section 4 and 100 Mb/s in Section 5. Sensor links run at 88 kb/s. Latency includes light-travel time. Per-hop processing, laser acquisition, and the 15-second schedule require additional modeling. |
| Evidence and scope | 5 · 6 | Figure 5 validates measured delays against the coordinator’s own predictions. Section 6 identifies real LEO traces as a further validation requirement. |
| Dataset and workload | 2026 · 6 | The table's last row also records a 2026 finding that the emulated network is a star rather than a mesh, which Section 6 takes up. |
| 證據與範圍 | 定性範圍 | Celestial 是讓軟體對著建模網路執行的模擬平台，下表收集了讀者必須記得的網路假設。 |
| 軌道配置 | 2.1 · 1 · 550 km · 53° · 72 · 22 · 1,110–1,325 km · 1,600 · 400 · 375 · 450 · 5 · 66 · 780 km · 90° | §2.1 與 Fig. 1 的星座是申請文件中的 Starlink Phase I，第一層殼為 550 km、53° 的 72 個軌道面各 22 顆，另有 1,110–1,325 km 的四層較高殼層，各 1,600、400、375 與 450 顆，而 §5 的案例研究使用 Iridium 的 66 顆衛星，六個軌道面、780 km、90° 傾角，且ISL 侷限於接縫同側[79, §2.1, §5]。 |
| 證據與範圍 | 32 · 32 GB · 16 · 64 GB · 0.2 ms | Starlink 實驗的硬體是三台各 32 vCPU、32 GB 的 GCP N2-highcpu 主機加一台 16 核、64 GB 的 C2 協調器，主機之間有 0.2 ms 的延遲，案例研究則多加一台主機[79, §4.1, §5.1]。 |
| 容量與速率 | 4 · 10 Gb/s · 5 · 100 Mb/s · 88 kb/s · 15 · 6 | 鏈路模型是本教材的警語所適用之處：論文在 §4 給星間與射頻鏈路一律 10 Gb/s，在 §5 給 100 Mb/s 並搭配 88 kb/s 的感測器鏈路，延遲是純光行時間、每跳處理列於模型之外，雷射擷取與 15 秒排程的模型細節待補充，而唯一的驗證是 Fig. 5 把量測值與協調器自己的預期延遲比較，因為作者在 §6 說明他們取得真實 LEO 追蹤資料仍待完成。 |
| 證據與範圍 | 2026 · 6 | 表的最後一列也記下一項 2026 年的發現，即模擬出的網路採用星狀結構，第 6 節會談到。 |
| Assumption假設 | Celestial [79]Celestial[79] |
|---|---|
| Method方法 | MicroVM emulation. One Firecracker microVM per satellite or ground station. Coordinator pushes link state every 2 s [79, §4] or 5 s [79, §5]. Tc-netem delays. Bounding box suspension [79, §3]微型虛擬機模擬平台。每顆衛星或地面站一台 Firecracker 微型虛擬機。協調器每 2 s[79, §4]或 5 s[79, §5]推送鏈路狀態。tc-netem 延遲。邊界框暫停[79, §3] |
| Constellation星座 | Starlink Phase I shell 1 has 72×22 satellites at 550 km and 53°, totaling 1,584. Additional shells contain 1,600, 400, 375, and 450 satellites at 1,110, 1,130, 1,275, and 1,325 km, respectively. Section 4 emulates 4,409 satellites. Section 5 uses Iridium’s 66 satellites in six planes, at 780 km and 90° [79, §2.1, §5].Starlink Phase I：第一層殼 550 km、53° 的 72×22（1,584 顆），加上 1,110 / 1,130 / 1,275 / 1,325 km 的 1,600 / 400 / 375 / 450 顆，§4 模擬 4,409 顆。§5 為 Iridium 66 顆、6 個軌道面、780 km、90°[79, §2.1, §5] |
| ISL topologyISL 拓樸 | +Grid expected, four per satellite, dropped below a configurable altitude. ISLs restricted to each side of the seam for Iridium [79, §2.1, §3]. [81] find the emulated network is a star in which any satellite reaches any other in two hops preprint預期為每顆衛星四條的 +Grid，低於可設定高度時斷開。Iridium 鏈路侷限於接縫同側[79, §2.1, §3]。[81] 發現模擬出的網路是星狀，任兩顆衛星兩跳可達 preprint |
| Default ISL rate預設 ISL 速率 | Flat 10 Gb/s for ISLs and radio links in §4. 100 Mb/s ISL and ground links with 88 kb/s sensor links in §5§4 中 ISL 與射頻鏈路一律 10 Gb/s。§5 中 ISL 與地面鏈路 100 Mb/s、感測器鏈路 88 kb/s |
| Latency model延遲模型 | Light-time over geometric distance for lasers and RF alike, applied by tc-netem at 0.1 ms accuracy with the 0.2 ms host-to-host delay subtracted. Per-hop processing delay excluded [79, §3, §4.1]雷射與射頻一律以幾何距離的光行時間計算，由 tc-netem 以 0.1 ms 精度施加並扣除 0.2 ms 主機間延遲。每跳處理延遲列於模型之外[79, §3, §4.1] |
| Laser setup delay雷射建鏈延遲 | Scope unspecified. Links appear and disappear instantaneously at each update模型細節待補充。鏈路在每次更新時瞬間出現或消失 |
| 15-s schedule15 秒排程 | Scope unspecified. The paper pre-dates its discovery模型細節待補充。論文早於它被發現 |
| Validation vs live Starlink對照真實 Starlink 的驗證 | None. Accuracy checked only against the coordinator's own expected delays, median processing overhead 1.37 ms [79, §4.2, Fig. 5, §6]僅模型自洽檢查。準確度只對照協調器自己的預期延遲，處理開銷中位數 1.37 ms[79, §4.2, Fig. 5, §6] |
5. What was measured5. 量到了什麼
Application placement improves modeled conference and inference paths. These results demonstrate service execution at scale, while loaded-link capacity and operational Starlink timing need other experiments.
應用配置改善了模型中的會議及推論路徑，結果展示大規模服務執行能力，飽和鏈路容量及營運 Starlink 時序則需其他實驗。
| Item項目 | Values數值 | Conditions and source條件與來源 |
|---|---|---|
| Evidence and scope | 4.2 · 5.2 | The experiments are application studies, and the two that matter are the WebRTC conference of §4.2 and the inference case study of §5.2. |
| Latency comparison | 16 ms · 80% · 46 ms | The first case compares a server on the nearest satellite with a Johannesburg cloud server. Orbital service keeps maximum conference RTT within 16 ms for at least 80% of the session. Cloud service gives 46 ms [79, Fig. 4]. |
| Latency comparison | 22–183 ms · 13–90 ms | The second case carries sensor data through an Iridium-class constellation. The inference service runs either on satellites or at a ground station. Orbital inference reduces mean end-to-end latency from 22–183 ms to 13–90 ms [79, Fig. 11]. |
| Latency comparison | 550 km | Geometry explains the tested gains: a satellite overhead at 550 km can shorten the path compared with a distant cloud region. First-hop processing also saves the downlink. These cases demonstrate actual services on a constellation-scale testbed. |
| Latency comparison | 10 Gb/s · 100 Mb/s · 3 | The reported tests keep the 10 Gb/s and 100 Mb/s links below saturation, so loaded-network capacity requires separate evaluation. Predicting Starlink latency also requires gateway-to-PoP delay and the scheduler. Chapter 3 shows that those factors dominate the satellite propagation modeled here. |
| 證據與範圍 | 4.2 · 5.2 | 實驗是應用層面的研究，其中重要的兩個是 §4.2 的 WebRTC 會議與 §5.2 的推論案例研究。 |
| 延遲比較 | 80% · 16 ms · 46 ms | 在前者，一個區域內的參與者由最近衛星上的伺服器或 Johannesburg 的雲端伺服器服務，會議內的最大 RTT 在至少 80% 的時段內，由軌道提供時維持在 16 ms 以下，由雲端提供則為 46 ms[79, Fig. 4]。 |
| 證據與範圍 | 22–183 ms · 13–90 ms | 在後者，一個 Iridium 等級的星座把感測器資料送到位於衛星上或地面站的推論服務，把服務搬到軌道使平均端到端延遲從 22–183 ms 的範圍降到 13–90 ms[79, Fig. 11]。 |
| 軌道配置 | 550 km | 這兩個結果都直接來自幾何，因為頭頂 550 km 的衛星比任何地面區域都近，而放在第一跳衛星上的服務完全避開了下行鏈路，兩者作為測試平台能在星座規模執行真實服務的示範都是成立的。 |
| 容量與速率 | 10 Gb/s · 100 Mb/s · 3 | 報告中的 10 Gb/s 與 100 Mb/s 鏈路負載都低於飽和點，網路滿載容量仍需另外評估。預測 Starlink 實際延遲還需加入閘道到 PoP 的路段與排程器，第 3 章顯示這些因素比本工具建模的衛星傳播更具影響。 |
| Claim宣稱 | Setup and caveat設定與附註 |
|---|---|
| WebRTC conference max RTT ≤16 ms from satellite servers against 46 ms from a Johannesburg cloud region for ≥80% of the session [79, Fig. 4]WebRTC 會議由衛星伺服器提供時最大 RTT ≤16 ms，由 Johannesburg 雲端區域提供為 46 ms，涵蓋 ≥80% 的時段[79, Fig. 4] | Starlink Phase I twin, 10 Gb/s flat links, light-time delays only. A geometry result that assumes a server on every satelliteStarlink Phase I 分身、10 Gb/s 平坦鏈路、僅光行時間延遲。是假設每顆衛星都有伺服器的幾何結果 |
| Measured latency tracks expected latency with 1.37 ms median processing overhead, baseline stdev 3.86 ms [79, Fig. 5]量測延遲貼著預期延遲，處理開銷中位數 1.37 ms，基準標準差 3.86 ms[79, Fig. 5] | The paper's only accuracy figure, and it compares the testbed with its own model rather than with any live network [79, §6]論文唯一的準確度數字，而且是把測試平台與它自己的模型比較，，真實網路的比較則待完成[79, §6] |
| 4,409 satellites on three hosts. 137 cores estimated, 96 used. MicroVM CPU ≈10%, memory <20% of hosts [79, Figs. 7–8]三台主機上 4,409 顆衛星。估計需要 137 核、使用 96 核。微型虛擬機 CPU ≈10%，記憶體低於主機的 20%[79, Figs. 7–8] | Only the microVMs inside the bounding box run. The figure says nothing about full-constellation emulation, which §6.1 puts at ~36 TB of RAM at 8 GB each只有邊界框內的微型虛擬機在運作。這個數字描述了邊界框內的服務範圍，§6.1 估計每台 8 GB 時需約 36 TB RAM |
| $3.30 for a 10-min run plus 5-min setup against ≥$539.66 for 4,409 f1-micro VMs [79, §4.2]10 分鐘執行加 5 分鐘建置 $3.30，對比 4,409 台 f1-micro VM ≥$539.66[79, §4.2] | 2022 GCP list prices. The comparison is against the naive one-VM-per-satellite design, with emulator-to-emulator comparison left open2022 年的 GCP 定價。比較對象是每顆衛星一台 VM 的樸素設計，，其他模擬平台的比較則需另外評估 |
| Satellite-hosted inference cuts mean end-to-end latency from 22–183 ms to 13–90 ms [79, Fig. 11]衛星上的推論把平均端到端延遲從 22–183 ms 降到 13–90 ms[79, Fig. 11] | Iridium 66-satellite case study, 100 Mb/s ISL and ground links, 88 kb/s sensor links, 5 s updates. Compare Chapter 8's orbital edge computing framingIridium 66 顆衛星的案例研究，100 Mb/s ISL 與地面鏈路、88 kb/s 感測器鏈路、5 s 更新。可對照第 8 章的軌道邊緣運算框架 |
6. Limits and open questions6. 範圍與待解問題
- Cionca et al. examine Celestial, StarryNet, and OpenSN on a 72 × 22 shell. They report that Celestial uses a star network, with two-hop satellite paths and 80–90 ms RTT. This topology limits conclusions about ISL routing and multi-hop transport. Celestial also has the lowest CPU use, fastest eBPF updates, and VM startup of 2–300 ms [81] preprint.網路層是較弱的那一半。Cionca 等人在 72 × 22 的殼上把 Celestial 與 StarryNet、OpenSN 一起檢驗，發現它的網路模擬使用星狀拓樸，所以任兩顆衛星兩跳可達、RTT 為 80–90 ms，並下結論說它對 ISL 的模擬準確度有限，儘管它的 CPU 使用最低、透過 eBPF 的更新最快、VM 啟動只需 2–300 ms[81]preprint。任何在 Celestial 上產生的 ISL 路由或多跳傳輸結果都承襲了這個結構。
- The accuracy figure compares the testbed with the coordinator’s own distance-over-c prediction [79, Fig. 5]. Section 6 identifies real-trace validation as future work. Starlink’s measured 25–50 ms idle medians and Tanveer et al.’s 15-second structure provide external comparison targets [13]. The authors recognize residual accuracy limits in efficient emulation.驗證是循環的。唯一的準確度數字是把測試平台與協調器自己的距離除以 c 的預期比較[79, Fig. 5]，§6 則說明真實 LEO 追蹤資料待取得，所以 Celestial 仍待與 Starlink 實測的 25–50 ms 閒置中位數或 Tanveer 等人[13]的 15 秒結構比較。作者自己也寫道，高效的模擬測試平台都存在殘餘準確度限制。
- The model sets link rates to 10 Gb/s and 100 Mb/s. These values sit one to three orders below the company’s 100 Gbps sustained-per-laser claim company. Experiments keep links below saturation, so throughput at saturation requires separate evaluation. Chapter 7 therefore treats these cases as illustrations of network dynamics.鏈路數字只是佔位。§4 一律 10 Gb/s、§5 一律 100 Mb/s，比公司宣稱每條雷射持續 100 Gbps company 低了一到三個數量級，而且因為測試負載保持在鏈路容量以內，飽和負載下的吞吐量仍待研究。本教材第 7 章把這類結果歸為動態示意。
- The coordinator updates the active ISL set every 2–5 s, and tc applies each set immediately. Actual terminal acquisition takes 2–30 s [17, Tab. 1]. The four-laser +Grid comes from the 2019 filing. Starlink satellites carry three terminals, with detailed topology held by the operator [39, §6.1].鏈路瞬間切換。協調器每 2–5 s 重算哪些 ISL 存在，tc 立刻套用新集合，而真實終端需要 2–30 s 才能擷取[17, Tab. 1]，四條雷射的 +Grid 也是 2019 年的申請文件，，Starlink 實際搭載三個終端，拓樸則待公開[39, §6.1]。
- Section 6 lists resource interference between microVMs and state updates missed during suspension. The platform supports x86-64. Maneuvers, weather, and mobile ground stations require further models. Users supply routing and state management, including strategies for services that move against the orbit in Chapter 9.作者在 §6 自己列的清單很坦白：同一主機上微型虛擬機之間的資源干擾、在邊界框外被暫停的服務會錯過狀態更新、僅支援 x86-64、軌道機動、天氣與移動地面站列於範圍之外，路由與狀態管理策略則由使用者提供，這表示使用者必須自己回答第 9 章關於服務逆著軌道移動的問題。
- Citation and reporting details need care. The arXiv version leaves the venue and DOI open, which contributed to the ICDCS attribution. Its 4,409 satellites differ by one from StarryNet’s 4,408 under the same filing. Runtime per emulated second and error bars for the 16 versus 46 ms result require further reporting.缺少的數字與帳目：arXiv 文本省略了發表場合與 DOI，這正是 ICDCS 誤引的來源，同一份申請文件的 4,409 與 StarryNet 的 4,408 相差一顆，每模擬秒的實際時間待補充，16 對 46 ms 的結果也誤差範圍待補充。
7. How it connects7. 與其他內容的關聯
- Section 7.4: Celestial occupies the compute-realism corner of the chapter's fidelity–scale map, with the $3.30 run and the 4,409 satellites. The capability table records its flat ISL rate, missing setup delay and missing schedule.第 7.4 節：Celestial 佔據該章擬真度與規模地圖中運算真實性的那一角，包括 $3.30 的執行與 4,409 顆衛星，能力表則記錄它的平坦 ISL 速率、缺席的建鏈延遲與排程。
- Section 7.3: the contrast with Hypatia is the contrast between modeling protocols in ns-3 and running them in a kernel. Celestial can run a real WebRTC stack but requires a mesh link graph to show the reordering effects studied in Hypatia.第 7.3 節：與 Hypatia 的對比，就是在 ns-3 中建模協定與在核心中執行協定的對比。Celestial 能跑真實的 WebRTC 堆疊，若要呈現 Hypatia 研究的重排效應，則需將星狀鏈路圖改為網狀。
- Section 7.5 discusses Cionca et al.’s shared accuracy findings for Celestial, StarryNet, and OpenSN. Celestial illustrates the limits of validation against a system’s own model.第 7.5 節：Cionca 等人對實測吻合程度的質疑是在 Celestial、StarryNet 與 OpenSN 上一起得出的，而 Celestial 的循環驗證是這個盲點最清楚的案例。
- Section 5.4: a star-topology emulator requires another model to reproduce path churn. Thus, the routing results of that section should be checked on Hypatia, StarryNet or xeoverse rather than here.第 5.4 節：重現路徑變動需要網狀拓樸，所以該節的路由結果應在 Hypatia、StarryNet 或 xeoverse 上檢驗，以取得合適的網狀鏈路模型。
- Section 6.1: Celestial's microVMs run real kernel congestion controllers, while reproducing that section’s traces requires the 15-second schedule and loaded links.第 6.1 節：Celestial 的微型虛擬機能跑真實的核心壅塞控制器，重現該節追蹤則需要加入 15 秒排程及飽和負載。
- Related digests compare different modeling choices. Hypatia emphasizes links, StarryNet uses containers and an OVS mesh, and xeoverse runs Mininet in real time. Applications connect to orbital edge computing, the in-orbit computing thought experiment, and CollabLLM-LEO. Chapter 12 examines their link assumptions.同組導讀：Hypatia 建模鏈路，實際軟體執行則列於範圍之外。StarryNet 用容器與真實的 OVS 鏈路網狀。xeoverse 以即時方式執行 Mininet。應用面則連到軌道邊緣運算、在軌運算的思想實驗以及 CollabLLM-LEO 的推論系統，第 12 章會以同樣的鏈路假設評估它們。
Key numbers關鍵數字
| Number | 數字 | Meaning (setup) | 意義（設定） |
|---|---|---|---|
| 1 microVM | Per satellite or ground station, Firecracker with its own kernel. 2 vCPU / 512 MB in §4, 1 vCPU / 1,024 MB in §5 | 每顆衛星或地面站一台，Firecracker 自帶核心。§4 為 2 vCPU / 512 MB，§5 為 1 vCPU / 1,024 MB | |
| 2–5 s | Coordinator update interval for SGP4 positions and link state (2 s in §4, 5 s in §5) | 協調器更新 SGP4 位置與鏈路狀態的間隔[79, §4, §5] | |
| 0.1 ms | tc-netem delay accuracy after subtracting the 0.2 ms host-to-host delay [79, §3, §4.1] | 扣除 0.2 ms 主機間延遲後 tc-netem 的延遲精度[79, §3, §4.1] | |
| 10 Gb/s / 100 Mb/s | Flat ISL and radio link rates in §4 and §5. Sensor links 88 kb/s in §5 | §4 與 §5 中平坦的 ISL 與射頻鏈路速率。§5 感測器鏈路 88 kb/s | |
| 4,409 | Starlink Phase I satellites emulated on three 32-vCPU hosts. 137 cores estimated, 96 used [79, §4.2] | 三台 32 vCPU 主機上模擬的 Starlink Phase I 衛星數。估計需要 137 核、使用 96 核[79, §4.2] | |
| $3.30 vs ≥$539.66 | Cost of a 10-min run with 5-min setup against one f1-micro VM per satellite [79, §4.2] | 10 分鐘執行含 5 分鐘建置的成本，對比每顆衛星一台 f1-micro VM[79, §4.2] | |
| 16 vs 46 ms | Max WebRTC conference RTT for ≥80% of the session, satellite servers vs Johannesburg cloud [79, Fig. 4] | ≥80% 時段內 WebRTC 會議的最大 RTT，衛星伺服器對比 Johannesburg 雲端[79, Fig. 4] | |
| 1.37 ms | Median processing overhead between measured and expected latency. Baseline stdev 3.86 ms [79, Fig. 5] | 量測與預期延遲之間處理開銷的中位數。基準標準差 3.86 ms[79, Fig. 5] | |
| 22–183 → 13–90 ms | Mean end-to-end latency with inference moved from a ground station to the satellites, Iridium case [79, Fig. 11] | 推論從地面站搬到衛星後的平均端到端延遲，Iridium 案例[79, Fig. 11] | |
| ~36 TB | RAM a full 4,400-satellite run would need at 8 GB per microVM [79, §6.1] | 每台微型虛擬機 8 GB 時，全量 4,400 顆衛星執行所需的 RAM[79, §6.1] | |
| 2 hops | Any satellite to any other in Celestial's star-topology network layer, 80–90 ms RTT [81] | Celestial 星狀網路層中任兩顆衛星間的跳數，RTT 80–90 ms[81] |