#Starlink の視界が遮られる場所での間欠通信を考える

#Starlink

大瀧隆太

2022.11.12

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

ども、大瀧です。

西日本や札幌でもサービスを開始したStarlinkの注文は皆さんお済みですか(挨拶)。Starlinkは天頂から天頂角50度付近までの良好な視界を要件とし、建物や遮蔽物があると数分間隔で通信断が起きる様子を以前のブログ記事で紹介しました。一方で視界が大きく遮られる劣悪な設置環境でどの程度通信できるのかが気になったので、いくつか試してみた様子と間欠で通信するための考察をご紹介します。

劣悪な設置環境での検証

以前はビルの屋上で試しましたが、今回はマンションのベランダに設置して検証します。一般的な集合住宅のベランダは天井によって天頂付近が遮られ、屋外方向におおむね半分の視界が開けた状態になるでしょうか。また今回はベランダの手すりから近いところに置いたため、手すりによって低い角度が遮られる以下のような視界要件になります。

StarlinkアプリではOFFLINEと表示され、視界要件を満たさないために接続出来ていない様子がわかります。

一方で[STATISTICS]をタップして通信状態の履歴を確認すると、大部分がUPTIME 0%でSearching(衛星の探索中)を指す水色なのに対して、時折UPTIMEの値が上昇するタイミングがあることも見て取れます。

いくつかの軌道を周回するたくさんのStarlink衛星のうち、一部の衛星が狭い視界を通過するタイミングで通信できているのでしょうか。少し希望が見えてきました。試しに連続でpingコマンドでICMPリクエストをインターネット越しのホスト宛てに送ってみると。。。

$ ping 1.1.1.1
PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.
64 bytes from 1.1.1.1: icmp_seq=276 ttl=54 time=335 ms
64 bytes from 1.1.1.1: icmp_seq=275 ttl=54 time=1359 ms
64 bytes from 1.1.1.1: icmp_seq=277 ttl=54 time=21.1 ms
64 bytes from 1.1.1.1: icmp_seq=278 ttl=54 time=20.0 ms
64 bytes from 1.1.1.1: icmp_seq=279 ttl=54 time=45.7 ms
64 bytes from 1.1.1.1: icmp_seq=280 ttl=54 time=28.1 ms
64 bytes from 1.1.1.1: icmp_seq=281 ttl=54 time=21.4 ms
64 bytes from 1.1.1.1: icmp_seq=282 ttl=54 time=53.2 ms
64 bytes from 1.1.1.1: icmp_seq=283 ttl=54 time=25.3 ms
64 bytes from 1.1.1.1: icmp_seq=284 ttl=54 time=23.1 ms
64 bytes from 1.1.1.1: icmp_seq=285 ttl=54 time=41.6 ms
64 bytes from 1.1.1.1: icmp_seq=286 ttl=54 time=27.0 ms
64 bytes from 1.1.1.1: icmp_seq=647 ttl=54 time=29.9 ms
64 bytes from 1.1.1.1: icmp_seq=648 ttl=54 time=47.2 ms
64 bytes from 1.1.1.1: icmp_seq=649 ttl=54 time=24.2 ms
64 bytes from 1.1.1.1: icmp_seq=650 ttl=54 time=36.0 ms
64 bytes from 1.1.1.1: icmp_seq=651 ttl=54 time=21.6 ms
64 bytes from 1.1.1.1: icmp_seq=652 ttl=54 time=156 ms
$

多くは応答がないのですが、いくつか返答が返ってきています！icmp_seqがICMPリクエスト数と同等なので、1〜275回は返答が返っていないけど、276〜286回まで返ってきてそれからしばらくはまた返答なし、という感じです。

また、返答は2つ以上の連番になることが多く、通信可能な時間が数秒間あるように見て取れました。これならICMPだけでなく一般的なデータ転送もできるのではと考え、以下のシェルスクリプトを作成し実行してみました。

#!/bin/bash

while :
do
  ping -c 1 -W 1 1.1.1.1 > /dev/zero 2>&1 && aws s3 cp ./1m.dat s3://<S3バケット名>/`date +%s`.dat
done

安定した通信ができる回線で上記スクリプトを実行すると大量のファイルがS3にアップロードされ、S3の利用金額が高額になる恐れがあります。不用意にスクリプトを実行するのは避けてください。

無限ループでさきほどと同じpingコマンドを試行し、返答があった場合に続けてAWS CLI(awsコマンド)でAmazon S3に1MBのファイルをアップロードする処理です。S3に保存するファイル名にはUNIXタイムスタンプを指定しているので、アップロードに成功するとファイルが増えていく格好です。半日ほど置いてAWS管理コンソールを確認してみると...

おおー、S3へのファイルアップロードが出来ていますね。

使いどころの考察

ここまでの検証の様子をまとめてみます。

ほとんどの時間は通信不可
数分から数十分の間に数秒ほど通信可能な時間がある
ICMPリプライの受信のほか、HTTPSによる1MBのファイルアップロードができた

インターネットへの常時接続環境としては落第点ですが、他の通信手段の無い僻地で例えばIoT用途でセンサーデータをまとめて送るようなケースであれば十分使えるような印象を持ちました。また、良好な視界を確保できる遠隔地に配置していてなんらか遮蔽物によって視界が遮られるトラブルがあった場合も、視界の一部が残っていれば通信の試行を繰り返すことである程度のデータ送信ができそうです。

残念ながらオフライン時にWi-FiルーターがICMPリプライを返すような挙動は見受けられなかったので、オフラインの検知は一般的な通信のタイムアウトで判断することになりそうです。一方で非公開ながらStarlinkキットにはgRPC APIがあるので、こちらから通信状態に関するメトリクスを収集するのもありかもしれません。gRPC APIとメトリクスの収集は、こちらの記事が詳しいです。

まとめ

視界が大きく遮られる劣悪な設置環境でどの程度Starlinkの通信できるのかを試してみた様子と間欠で通信する用途や可能性を考察してみました。一般的な通信回線では認証など接続のための手続きを経てオンラインになるので、Starlinkでもある程度の視界を確保しないとオンラインにならないかなぁと勘ぐっていたのですが、視界が悪いところでも少しだけ通信できることに驚きました。複数の衛星とかわるがわる通信する仕組みから接続手続きがシンプルなのか、はたまた広帯域ゆえに手続きがごく短い時間で済むのか内情はわかりませんが、ひとつの興味深い特性として覚えておくと良いのかなと思いました。