Starlink Mini の衛星ハンドオーバーを実際に確認してみた
ウィスキー、シガー、パイプをこよなく愛する大栗です。
最近のお客様と話をする中で、遠隔地で高速な通信が必要になる場合には衛星回線も選択肢になるのではないか、と考えるようになりました。Starlink のような LEO（低軌道）衛星は高度が低いため遅延が小さく、地上回線に近い感覚で使えます。
一方で LEO 衛星は数分で頭上を通り過ぎてしまうため、通信中に衛星を切り替えるハンドオーバーが避けられません。Starlink はこの切り替えを 15 秒ごとに行っているという研究報告があります。実際にどの程度の影響があるのか気になったので、手元の Starlink Mini と東京リージョンの EC2 の間で 1 時間計測してみました。
Starlink の 15 秒周期
CoNEXT 2023 で発表された上記の論文では、アメリカとヨーロッパに置いた 4 台の Starlink 端末を高頻度で計測し、Starlink のスケジューリングの挙動を分析しています。ポイントは次の 2 つです。
- Starlink は中央集権的な制御方式で、15 秒周期で衛星の選択・経路・フローテーブルを全体更新している
- その境界は毎分 12 秒、27 秒、42 秒、57 秒付近に揃っている
端末から見ると、15 秒ごとに通信相手の衛星やビームが切り替わる可能性があるということです。切り替わった瞬間にはレイテンシの悪化や短時間のパケットロスが起きるはずで、切り替わった後は別の衛星を経由するのでベースのレイテンシそのものが変わるはずです。この 2 点を実測で確認するのが今回の目的です。
検証の構成
構成は以下のとおりです。計測クライアントの Mac を Starlink Mini に有線で接続し、東京リージョンの EC2 に向けて計測パケットを送り続けます。
[Mac (有線 LAN)] 計測クライアント irtt client / ping / starlink-grpc-tools の dish_grpc_text.py (端末統計)
|
| USB Ethernet
v
[Starlink Mini] 192.168.100.1:9200 (gRPC)
|
| 衛星通信
v
[Starlink PoP (東京)]
|
| インターネット
v
[EC2 ap-northeast-1] 計測サーバ
irtt server
3 種類のデータを計測します。
| データ | 取得元 | 粒度 | 見えるもの |
|---|---|---|---|
| 端末統計（pop_ping_latency_ms / pop_ping_drop_rate） | Starlink 端末の gRPC API | 1 秒 | アンテナから PoP までの品質 |
| irtt（RTT / 片方向遅延 / ロスの方向） | Mac から EC2 への UDP | 100 ms | エンドツーエンド通信状況 |
| ping（RTT / ロス） | Mac から EC2 への ICMP | 200 ms | irtt の確認 |
Starlink 端末は LAN 側に gRPC API を公開しており、starlink-grpc-tools を使うと 1 秒粒度の統計を取り出せます。ただし公式にドキュメント化された API ではなく、ファームウェア更新で変わる可能性がある点に注意してください。
irtt は UDP で等間隔にパケットを送り、RTT に加えて片方向遅延とロスの方向を記録できるツールです。衛星回線では上りと下りで挙動が違う可能性があるので、ping ではなく irtt をメインにしました。
構成上のポイントは以下の 3 つです。
- 東京リージョンを選ぶ : 日本の Starlink の PoP は東京の大手町にあります。EC2 も東京に置くと地上区間の遅延が最小になり、計測値の大半が衛星区間になります。
- 有線で接続する : Wi-Fi のジッタが混ざると衛星由来の変動と区別できなくなります。
- Starlink 側から計測を開始する : ROAM - 100GB の契約をしているためパブリック IP は無く CGNAT 配下で IPv4 の着信ができません。計測はすべて Mac から EC2 へのアウトバウンドで開始します。
前提条件は以下です。
| 項目 | 値 |
|---|---|
| 衛星アンテナ | Starlink Mini（mini1_pez_proto1） |
| ファームウェア | 2026.08.31.mr85832 |
| 設置 | 神奈川県横浜市某所、屋外、晴天、遮蔽なし（obstructionStats.fractionObstructed は 0、アラートなし） |
| 計測日時 | 2026年9月13日 14:45〜15:47 JST（無負荷） |
| 計測クライアント | Apple M4（macOS 26.6.2）、USB Ethernet で有線接続 |
| EC2 | ap-northeast-1a（apne1-az4）、m8a.xlarge、Ubuntu 24.04 |
| プロトコル | IPv4 |
本検証はデータ転送を行わない無負荷（無通信時）で実施しています。帯域を大きく消費する高負荷時の挙動は対象外です。
Starlink Mini は実際にはこんな感じで置いていました。
準備し始めはこの様な天気（魚眼レンズで取ってみました）で少し曇りがちでしたが、計測開始時には概ね晴れていました。
やってみる
EC2 側の準備
EC2 には irtt のサーバを立てるだけです。Security Group は https://checkip.amazonaws.com で確認した IP アドレスに対してトラフィックを計測時間中だけ開けておきます。
必要なツールを導入して時刻同期を行います。
$ sudo apt update && sudo apt install -y irtt iperf3 chrony tmux
$ chronyc tracking
$ tmux new -d -s irtt 'irtt server -i 10ms -d 3h -l 1500'
$ tmux new -d -s iperf 'iperf3 -s'
-i 10ms はクライアントに許可する最小送信間隔、-d 3h は最大テスト時間です。既定値のままだと長時間・短間隔の計測がサーバ側で拒否されるので緩めておきます。
Mac 側の準備
Homebrew で計測ツールを入れます。irtt は Homebrew に formula が無い模様なので go install で入れます。
$ brew install grpcurl iperf3 mtr tmux go python@3.12
$ go install github.com/heistp/irtt/cmd/irtt@latest
$ echo 'export PATH="$PATH:$HOME/go/bin:/opt/homebrew/sbin"' >> ~/.zshrc && source ~/.zshrc
starlink-grpc-tools は clone して venv に依存関係を入れます。
$ git clone https://github.com/sparky8512/starlink-grpc-tools.git
$ cd starlink-grpc-tools
$ python3 -m venv .venv && source .venv/bin/activate
$ pip install --upgrade -r requirements.txt
$ pip install pandas matplotlib # 解析用
時刻同期を行います。
sudo sntp -sd time.apple.com
sntp time.apple.com
Starlink Mini の LAN ポートに Mac を有線接続して、gRPC API に到達できるか確認します。grpcurl で get_status を叩くと端末の状態が JSON で返ってきます。
$ grpcurl -plaintext -d '{"get_status":{}}' 192.168.100.1:9200 SpaceX.API.Device.Device/Handle
{
"apiVersion": "43",
"dishGetStatus": {
"deviceInfo": {
"id": "1234567890-12345678-12345678",
"hardwareVersion": "mini1_pez_proto1",
"softwareVersion": "2026.08.31.mr85832",
"countryCode": "JP",
...
},
"deviceState": {
"uptimeS": "623"
},
"obstructionStats": {
"validS": 577,
"patchesValid": 2114
},
"alerts": {},
"downlinkThroughputBps": 10292.822,
"uplinkThroughputBps": 53737.42,
"popPingLatencyMs": 25.54012,
"boresightElevationDeg": 81.441124,
...
}
}
popPingLatencyMs が端末から PoP までの RTT です。無負荷で 25 ms 前後でした。obstructionStats に fractionObstructed が出ていないのは値が 0 のためで、遮蔽なしで設置できています。
ここでハマったのが Cloudflare WARP です。クライアントに導入していたので、計測中は Wi-Fi と共に無効にしました。
計測スクリプト
3 つの計測を tmux で並列に走らせるスクリプトを用意しました。ポイントは以下です。
- Mac がスリープしないように
caffeinate -i経由で起動する - macOS の
pingには Linux の-D（epoch 表示）が無いので、--apple-timeとTZ=UTCで各行に UTC の時刻を付ける - アンテナ統計は
dish_grpc_text.py -t 60 bulk_historyで 60 秒ごとに新規サンプルだけを CSV に追記する
run.sh
1 分間のテスト計測
1 時間回す前に、1 分だけ動かして出力を確認しました。
$ ./run.sh <EC2 IPv4> 1 test
started: /path-to/measure/data/20260913T053901Z_test (duration 1 min)
watch: tmux ls / tail -f /path-to/measure/data/20260913T053901Z_test/irtt_v4.txt
stop: tmux kill-server
1 分でロスはゼロ、RTT の中央値は 27.49 ms でした。RTT の時系列を見ると、スパイクが 4 回、それも 05:39:12、05:39:27、05:39:42、05:39:57 の直前にきれいに並んでいます。縦線が「秒 mod 15 = 12」の位置です。
Min Mean Median Max Stddev
--- ---- ------ --- ------
RTT 16.93ms 28.42ms 27.49ms 100.7ms 7.57ms
send delay 22.44ms 30.88ms 30.32ms 103ms 7.42ms
receive delay -5.87ms -2.46ms -2.82ms 2.41ms 1.52ms
IPDV (jitter) 5.71µs 5.73ms 4ms 72.44ms 7.42ms
send IPDV 1.36µs 5.75ms 3.98ms 72.78ms 7.37ms
receive IPDV 16ns 1.31ms 518µs 7.2ms 1.68ms
send call time 28.3µs 113µs 340µs 31µs
timer error 541ns 265µs 1.12ms 190µs
server proc. time 670ns 1.15µs 8.18µs 1.04µs
duration: 1m0s (wait 302.1ms)
packets sent/received: 598/598 (0.00% loss)
server packets received: 598/598 (0.00%/0.00% loss up/down)
bytes sent/received: 102856/102856
send/receive rate: 13.7 Kbps / 13.7 Kbps
timer stats: 2/600 (0.33%) missed, 0.26% error
たった 1 分で論文の記述どおりの挙動が見えてしまいました。これは 1 時間回す価値がありそうです。
60 分計測する
本番は 60 分です。日中の無負荷状態で実行しました。
$ ./run.sh <EC2 IPv4> 60 idle-day
started: /path-to/measure/data/20260913T054545Z_idle-day (duration 60 min)
後は 1 時間ゆっくり待ちます。遮蔽物がない見晴らしが良い場所で計測していたので、ウィスキー、シガー、パイプでも楽しみましょう。
irtt のサマリは以下のとおりです。100 ms 間隔で 35,957 パケットを送り、ロスは 0.08% でした。
Min Mean Median Max Stddev
--- ---- ------ --- ------
RTT 15.67ms 30.98ms 28.29ms 183.4ms 9.79ms
send delay 9.72ms 68.5ms 76.77ms 234ms 25.61ms
receive delay -69.96ms -37.52ms -47.47ms 28.15ms 24.4ms
IPDV (jitter) 104ns 6.51ms 4.01ms 158.9ms 8.68ms
send IPDV 120ns 6.08ms 3.75ms 143.8ms 8.45ms
receive IPDV 20ns 1.86ms 639µs 25.71ms 2.48ms
send call time 13.5µs 117µs 1.2ms 26.9µs
timer error 42ns 415µs 2.77ms 309µs
server proc. time 300ns 1.26µs 24.6µs 1.16µs
duration: 1h0m0s (wait 550.3ms)
packets sent/received: 35957/35928 (0.08% loss)
server packets received: 35934/35957 (0.06%/0.02% loss up/down)
late (out-of-order) pkts: 1 (0.00%)
bytes sent/received: 6184604/6179616
send/receive rate: 13.7 Kbps / 13.7 Kbps
timer stats: 42/35999 (0.12%) missed, 0.42% error
server packets received を見ると、上り（アンテナから EC2）で 0.06%、下り（EC2 からアンテナ）で 0.02% と、ロスは上下で差があるようです。
解析する
3 つのデータを突き合わせる解析スクリプト analyze.py を用意しました。データのディレクトリを渡すと、全体統計、15 秒位相ごとの統計、ロスの連続長を Markdown の表にまとめた summary.md と、グラフの PNG を生成します。スクリプト全体は長いので Gist に置いています。
analyze.py
$ .venv/bin/python3 analyze.py ~/measure/data/20260913T054545Z_idle-day
メイン部分を抜粋します。irtt の JSON から送信時刻と RTT を取り出し、送信時刻（UTC）の 15 秒周期として集計しているだけです。論文の記述どおりなら、境界である位相 12 の付近に山ができるはずです。
import json, numpy as np, pandas as pd
j = json.load(open("irtt_v4.json"))
rows = []
for rt in j["round_trips"]:
t = rt["timestamps"]["client"]["send"]["wall"] / 1e9 # 送信時刻（UTC epoch 秒）
rtt = rt["delay"]["rtt"] / 1e6 if "rtt" in rt.get("delay", {}) else np.nan
rows.append({"t": t, "rtt_ms": rtt, "lost": rt["lost"] != "false"})
df = pd.DataFrame(rows)
df["phase"] = np.floor(df["t"]).astype("int64") % 15 # 秒 mod 15 = 位相
print(df.groupby("phase").agg(loss_pct=("lost", lambda s: 100 * s.mean()),
rtt_p50=("rtt_ms", "median"),
rtt_p99=("rtt_ms", lambda s: s.quantile(.99))))
端末統計の CSV は dish_grpc_text.py -H bulk_history で列名を確認できます。時刻は UTC なので、irtt と同じ epoch 秒に変換すれば秒単位で突き合わせられます。
結果
全体の数字
まず 1 時間の全体統計です。
| 計測 | サンプル数 | ロス率 | RTT p50 | RTT p95 | RTT p99 | RTT 最大 |
|---|---|---|---|---|---|---|
| irtt（UDP、エンドツーエンド） | 35,957 | 0.08% | 28.3 ms | 47.9 ms | 68.1 ms | 183.4 ms |
| ping（ICMP、エンドツーエンド） | 17,908 | 0.10% | 25.2 ms | 43.7 ms | 58.1 ms | 145.7 ms |
| アンテナ統計（アンテナから PoP、1 秒間隔） | 3,663 | 0.03% | 24.4 ms | 31.1 ms | 35.3 ms | 39.9 ms |
中央値で見ると、端末から PoP までが 24 ms、エンドツーエンドが 25〜28 ms です。PoP から EC2 までの地上区間は 1〜4 ms しか増えていないので、東京リージョンを使用すると計測値のほぼ全てが衛星区間だと言えます。
p99 になると端末統計とエンドツーエンドの差が開きます。アンテナ統計は 1 秒平均なので、100 ms 単位のスパイクが平均れてしまうためです。
全体の時系列は以下です。上段が RTT（青が irtt、橙が端末統計）、中段がロス率、下段がスループットです。
15 秒位相との相関
各サンプルの送信時刻（UTC）の秒を 15 で割った余りを「位相」として、位相ごとに統計を取りました。論文の記述どおりなら、境界である位相 12 の付近に山ができるはずです。
| 位相 | サンプル数 | ロス率 | RTT p50 | RTT p99 | RTT 最大 |
|---|---|---|---|---|---|
| 9 | 2,399 | 0.04% | 28.7 ms | 57.8 ms | 89.8 ms |
| 10 | 2,397 | 0.04% | 27.5 ms | 55.7 ms | 84.7 ms |
| 11 | 2,399 | 0.33% | 28.1 ms | 96.7 ms | 183.4 ms |
| 12 | 2,398 | 0.13% | 27.5 ms | 57.0 ms | 83.8 ms |
| 13 | 2,397 | 0.08% | 27.5 ms | 54.6 ms | 75.8 ms |
| 14 | 2,398 | 0.17% | 27.7 ms | 55.3 ms | 89.1 ms |
位相 11、つまり 12 秒・27 秒・42 秒・57 秒の直前 1 秒だけが明らかに異なります。RTT の p99 は他の位相が 55〜70 ms のところ 96.7 ms、ロス率は他の位相が 0〜0.17% のところ 0.33% です。p50 は位相によらず 27〜30 ms でほぼ一定なので、中央値は変わらず裾が遅くなっています。
境界の 1 秒前に山が出る理由は、位相 11 に送信したパケットが衛星を経由して戻ってくる間に境界を跨ぐためだと考えています。ping（オレンジ）でも同じ位相 11 と 12 に山が出ており、irtt 固有の現象ではありません。
拡大して確認する
ロスと p99 が最も悪かった 2 分間を拡大したのが以下の図です。縦線が 15 秒境界（秒 mod 15 = 12）です。
この図で特徴的な状況を確認できます。境界のスパイクだけでなく、15 秒ごとに RTT の段が切り替わっているのが見えます。05:48:12 で 45〜60 ms のばらついた区間に入り、05:48:27 でぴたりと 27 ms の平坦な区間に切り替わり、05:48:42 でまたばらつきが戻る、という具合です。15 秒ごとに別の衛星やビームに割り当て直され、その衛星までの距離や混雑状況で RTT の水準が異なることが見て取れます。オレンジの端末統計（1 秒平均）もゆるやかに同じ段を追いかけています。
通信はどのくらい途切れるのか
ハンドオーバーで通信が途切れるときは、実際にどのくらいの時間途切れるのでしょうか。また、上りと下りのどちらで落ちるのでしょうか。irtt の結果からこの 2 点を見ます。
まず落ちたパケットの数と通信断の回数を分けて数えます。100 ms 間隔で送っているので、連続して落ちたパケットをまとめて 1 回の通信断と数えると、通信断 1 回の長さが分かります。
| 項目 | 値 |
|---|---|
| 送信したパケット | 35,957 個 |
| 落ちたパケット | 29 個（0.08%） |
| 断の回数（連続したロスを 1 回と数える） | 26 回 |
| うち 2 パケット連続（約 200 ms） | 3 回 |
| 3 パケット以上の連続（300 ms 以上） | 0 回 |
| 落ちたパケットのうち位相 11・12 に入るもの | 11 個（37.9%） |
通信断の長さは最長でも 200 ms、つまり 100 ms 間隔のパケットが 2 発続けて落ちる程度で、1 秒を超えることは 60 分間で一度もありませんでした。
落ちたパケットの位相を見ると、15 段階のうち位相 11 と 12 の 2 段階だけで全体の 38% を占めています。前の節で見た RTT のスパイクと同じく、ロスもハンドオーバーの境界に集まっていると言えます。
次は方向を確認します。irtt はパケットごとに、サーバに届かなければ上り（Mac から EC2）のロス、サーバは受け取ったのに Mac に戻ってこなければ下り（EC2 から Mac）のロスと判定します。
| 方向 | 落ちたパケット |
|---|---|
| 上り（Mac から EC2） | 23 個 |
| 下り（EC2 から Mac） | 6 個 |
ロスは上りに偏っていました。端末から衛星へ送る側の方が切り替えの影響を受けやすいようです。とは言え全体のロス率は 0.08％ であり、再送制御がある TCP であれば問題ないと言えるレベルです。
国際標準の基準に照らしてみる
ここまでの数字を、IP ネットワークの品質目標を定めた国際標準 ITU-T Y.1541 に照らしてみます。
Y.1541 は、IP 網の品質を遅延・遅延変動・損失率の 3 つで測り、用途ごとに満たすべき上限を「QoS クラス」として定めた勧告です。通信事業者が網の品質を約束するときの共通言語で、値は次のように決められています。
| パラメータ | クラス 0 / 1 | クラス 2 / 3 | クラス 4 | クラス 5 |
|---|---|---|---|---|
| IPTD（IPパケット転送遅延） | 100 ms / 400 ms | 100 ms / 400 ms | 1 s | 規定なし |
| IPDV（IPパケット遅延変動：片道遅延の 99.9 パーセンタイルと最小値の差） | 50 ms | 規定なし | 規定なし | 規定なし |
| IPLR（IPパケット損失率） | 10⁻³ | 10⁻³ | 10⁻³ | 規定なし |
| 想定用途 | VoIP、ビデオ会議などジッタに敏感なリアルタイム通信 | トランザクション、シグナリング | 動画配信、バルク転送 |
評価は 1 分ごとに行い、観測したどの 1 分も基準を満たすことが求められます。遅延変動が上りと下りで別々に定義されています。irtt は片道遅延を記録しているので、上りと下りを分けて評価できます。
今回の 60 分のデータを 1 分ごとに評価した結果です。
| パラメータ | 実測値 | 判定 |
|---|---|---|
| IPTD | 平均 15.5 ms（RTT の半分で近似）。 最悪の 1 分でも 18.3 ms |
クラス 0 の 100 ms を大きく下回る |
| IPDV（下り） | 中央値 13.7 ms、最大 50.8 ms。 50 ms を超えたのは 60 分中 1 分 |
クラス 0 / 1 の 50 ms をほぼ満たす |
| IPDV（上り） | 中央値 64.1 ms、最大 135 ms。 60 分中 60 分で 50 ms を超過 |
クラス 0 / 1 を満たさない |
| IPLR | 60 分全体で 8.1×10⁻⁴。 1 分単位では 60 分中 14 分が 10⁻³ を超過 |
全体ではクラス 0〜4 を満たすが、1 分ごとの条件では満たさない |
遅延の絶対値はクラス 0 相当です。片道 15 ms 前後は地上の固定回線と比べても大きな問題はなく、片道 250 ms を超える静止衛星とは別物と言ってよいと思います。
一方で、最上位のクラス 0 / 1 に届かない理由は遅延変動、特に上りの遅延変動です。下りの変動は 14 ms とクラス 0 の水準に収まっていますが、上りは 64 ms と基準の 1.3 倍あります。前の節でロスが上りに偏っていたことと合わせると、ハンドオーバーの影響を受けているのは主に端末から衛星へ送る側だと言えそうです。
損失率は境界線上です。1 時間の平均では基準内ですが、ハンドオーバーの境界にロスが集まるため、1 分単位で見ると 4 分の 1 の区間で基準を超えます。
まとめると、無負荷の Starlink Mini はクラス 2〜4（トランザクション、動画配信、バルク転送）の基準は安定して満たし、クラス 0 / 1（VoIP、ビデオ会議）は上りの遅延変動のために満たしません。VoIP が使えないという意味ではなく、Y.1541 が想定するネットワーク側で変動を 50 ms 以内に収める保証がないので、端末側のジッタバッファで吸収する設計が必要、ということです。
なお、この評価には注意があります。Y.1541 は 99.9 パーセンタイルを評価するために 1 分あたり 1,000 パケット以上を求めていますが、今回は 100 ms 間隔で約 600 パケットしか無いため損失率の 1 分判定は特に粗くなっています。規格どおりに評価するには 50 ms 以下の間隔で再計測する必要があります。また Y.1541 は本来、通信事業者のネットワーク品質を UNI 間で評価するものなので、今回のように Mac や EC2 のホスト内処理を含む計測とは前提が少し異なります。
製造現場の設計に影響するか
今回の結果を、現場の機器をクラウドにつなぐ設計に当てはめると次のようになると思います。ただし以下の設計方針は無負荷時の実測値に基づく目安です。実際にワークロードではではジッタやロス率が変わる可能性があるため、本番構成での負荷テストを推奨します。
| プロトコル・用途 | 15 秒周期の影響 | 設計の考え方 |
|---|---|---|
| TCP 全般（HTTPS、MQTT over TCP） | 200 ms 以下の通信断はリトライで吸収される。RTT の重くなる分はスループットはわずかに落ちる | keepalive を極端に短くしない。数百 ms の再送を「異常」扱いしない |
| MQTT の keepalive / セッション | 1 秒超の通信断が無かったので、keepalive が数十秒なら切断は起きない | QoS 1 と永続セッションで対応可能 |
| ストリーミング/UDP 系（映像、音声、一部の産業プロトコル） | 15 秒ごとに数十〜百数十 ms のジッタ、100〜200 ms のロス | ジッタバッファを 200 ms 以上取る。ロスを前提にした符号化・前方誤り訂正 |
| 上り主体のセンサーデータ | ロスは上りに偏る | 送信側（現場）にバッファと再送を置く |
注意点
- 神奈川県横浜市某所で Starlink Mini を使用した測定結果です。計測場所やアンテナにより結果が変わる可能性があります。
- 今回の結果は 1 地点・1 回・昼間 60 分の無負荷計測です。夜間の混雑時間帯や天候により変わる可能性があります。
- 遮蔽の無い設置場所で計測しています。遮蔽があると遮蔽由来の切断が混ざり、ハンドオーバー由来の断と区別できなくなります。
- Starlink 端末の gRPC API は非公式です。ファームウェア更新でフィールド名や挙動が変わることがあります。
- iperf3 で帯域を使い切った状態での挙動は今回の範囲外です。別記事にする予定です。
さいごに
最近 Amazon Leo に興味があり、衛星通信に関する情報を調べていました。通信品質に衛星間ハンドオーバーが影響すると考えていましたが、論文に 15 秒周期という高頻度に行なうと出ており驚いていました。実際に計測してみるとハッキリと 15 秒周期の影響を計測できました。
一方で、その影響は最長 200 ms のロスと、p99 で 100 ms 程度の RTT がありつつも、ロス率が 0.08％ で平均レイテンシが 30ms 程度と十分に高品質なネットワーク回線と言えます。TCP ベースのプロトコルであれば意識せずに使える水準で、LEO 衛星通信は製造現場の回線として十分実用的だと感じています。ジッタに敏感な UDP 系と、上りのセンサーデータなどでは今回の数字を前提に設計しておくのが良いと思います。
次は、屋外で Starlink Mini を実際に動作させるための機材についてまとめた記事を書こうかと思います。
