起こした MEC にアクセスしましょう
さて、先行記事（設定編） では KDDI 5G MEC （その実体は AWS Wavelength インスタンス）を構築するところまでを説明しました。うまくできたでしょうか。
今回は作成した Wavelength instance に KDDI 5G 端末から、ping による往復遅延の計測を行いましたので、まずその結果報告を行います。分析・考察は後で情報を集めながらやろうと思います。
測ってみた
機器構成
今回計測する KDDI MEC と端末側の機器構成を示します。
つまり、先行記事 で作成した KDDI 5G MEC に、5G 携帯およびモバイルルータでアクセスしよう、というものです。機材はそれぞれ以下の通りです。
Smartphone (Android) - Google Pixel 5
Mobile Router - Speed Wi-Fi 5G X01
手法
愚直に ping (ICMP Echo 往復) と traceroute (ICMP Time Exceeded) を行いました。ルータには Windows PC が繋がれており、WSL Ubuntu 18.04 環境の ping / traceroute コマンドを実行しています。Android Smartphone では traceroute コマンドではなく android-netdiag を使った自作アプリ（つまりアプリ自身が TTL をセットしたパケットを送出する）で計測しています。
計測対象は 設定編 で作成した EC2 Instance と Wavelength Instance です。但し今回はkix-Osaka, nrt-Tokyo Zone の両方に対してワンセットずつ作成しましたから、計測ごとに計 4 つのインスタンスに対して ping / traceroute を行ったことになります。
およそ 5G 接続されているときばかり計測しました。一部 4G になったときに同じ経路を通ることを確認するようなことはしましたが、全計測地点で 5G / 4G の変化を追うようなことはしていません。
計測地点
今回計測したのは "四条河原町交差点から少し東に入った" ところ。Apple Store 京都近辺です。
上のリンクがうまくたどれなくても、au の "エリアマップ" で「キーワード検索」に「京都府京都市下京区立売中之町」を指定すればこのあたりが表示されるでしょう。（上の表示は 2021/4/23 時点のものです。かなりこまめに変わります。）
Pixel 5 は Sub6 帯（3.6GHz〜）のみ対応。5G X01 は Sub6 とミリ波（30GHz〜）に対応しているのですが、今回は見ての通り Sub6 帯しかサービスされていないようなので、そこは違いとしては出ないと思われます。
結果
計測は Apple Store 前あたりを数カ所、数メートル程度移動しては計測しました。10箇所以上で計測したのですが、ここでは Wavelength instance で最も良い数字を出すことにします。逆に言えば、驚くほど良い数字が出たわけでは無い、ということです。とにかく見て下さい。
Best case (with 5G Mobile Router)
以下、5G Mobile Router による結果を示します。Wavelength instance への遅延計測では、Apple Store が入居している ゼロゲートというビルの出入り口前 あたりが、最も良い数字がでました。
PING 106.161.xxx.xxx (106.161.xxx.xxx) 56(84) bytes of data.
64 bytes from 106.161.xxx.xxx: icmp_seq=1 ttl=244 time=23.9 ms
64 bytes from 106.161.xxx.xxx: icmp_seq=2 ttl=244 time=45.4 ms
64 bytes from 106.161.xxx.xxx: icmp_seq=3 ttl=244 time=32.5 ms
64 bytes from 106.161.xxx.xxx: icmp_seq=4 ttl=244 time=33.3 ms
64 bytes from 106.161.xxx.xxx: icmp_seq=5 ttl=244 time=39.9 ms
64 bytes from 106.161.xxx.xxx: icmp_seq=6 ttl=244 time=45.1 ms
64 bytes from 106.161.xxx.xxx: icmp_seq=7 ttl=244 time=44.5 ms
64 bytes from 106.161.xxx.xxx: icmp_seq=8 ttl=244 time=31.6 ms
64 bytes from 106.161.xxx.xxx: icmp_seq=9 ttl=244 time=31.7 ms
64 bytes from 106.161.xxx.xxx: icmp_seq=10 ttl=244 time=41.0 ms
--- 106.161.xxx.xxx ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 1809ms
rtt min/avg/max/mdev = 23.989/36.949/45.482/6.914 ms
最短 23.9ms、平均で 36.9ms です。ただ、かなり振れ幅（ jitter ）が大きいと思えます。
全試行を通じて最も短い遅延数字が 17.8ms で、Apple Store の四条通をはさんだ向かい側あたりでした。但しその時の平均は 40ms で、このゼロゲート入り口前よりも若干悪くなっています。本当に偶発的に短い時間で返ってきた、と思える状況です。
そしてこのときの経路は、こんな感じでした。しばらく private IP address だなと思ったら、KDDI のネットワークに入り、そのまま KDDI の網のなかです。ping が返すホップ数（ 255-244 = 11 ）から、このすぐ後に Wavelength instance に到達しているものと思います。（通常の traceroute が出す時間情報は余り意味が無いので消して、代わりに whois で確認した所有者情報を手で付けています。）
traceroute to 106.161.xxx.xxx (106.161.xxx.xxx), 25 hops max, 60 byte packets
1 172.24.240.1 # private
2 192.168.128.1 # private
3 172.25.197.122 # private
4 172.25.195.1 # private
5 172.25.195.90 # private
6 27.86.109.101 # KDDI
7 27.86.109.97 # KDDI
8 175.135.250.213 # KDDI
9 175.135.250.169 # KDDI
10 * * *
11 * * *
12 * * *
...以下25hopまで返事なし...
Best case (with Smartphone)
ところが面白いことに、5G Mobile Router + PC より、Smartphone (Pixel5) の方が早い数字を出します。場所は同じくゼロゲート入り口前です。
PING 106.161.xxx.xxx (106.161.xxx.xxx) 56(84) bytes of data.
64 bytes from 106.161.xxx.xxx: icmp_seq=1 ttl=245 time=21.1 ms
64 bytes from 106.161.xxx.xxx: icmp_seq=2 ttl=245 time=21.1 ms
64 bytes from 106.161.xxx.xxx: icmp_seq=3 ttl=245 time=19.4 ms
64 bytes from 106.161.xxx.xxx: icmp_seq=4 ttl=245 time=17.9 ms
64 bytes from 106.161.xxx.xxx: icmp_seq=5 ttl=245 time=15.1 ms
64 bytes from 106.161.xxx.xxx: icmp_seq=6 ttl=245 time=13.2 ms
64 bytes from 106.161.xxx.xxx: icmp_seq=7 ttl=245 time=22.7 ms
64 bytes from 106.161.xxx.xxx: icmp_seq=8 ttl=245 time=18.5 ms
64 bytes from 106.161.xxx.xxx: icmp_seq=9 ttl=245 time=17.1 ms
64 bytes from 106.161.xxx.xxx: icmp_seq=10 ttl=245 time=14.9 ms
--- 106.161.xxx.xxx ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 1816ms
rtt min|avg|max|mdev = 13.242|18.147|22.768|2.916 ms
なんと最短 13.2ms、平均でも 18.1 ms。そして最大でも 22.7ms と、かなり安定しています。
なんだこれは、と思ってあと二回、この場所で続けて計測したのですが、結果は安定して、以下の通りでした。
rtt min|avg|max|mdev = 12.875|19.938|40.978|7.455 ms
rtt min|avg|max|mdev = 13.503|18.540|25.296|3.296 ms
他の地点、たとえば道路向かいでは平均で 30ms 程度になるなど、違いが出るところなどは Mobile Router のケースと同じなのですが、それでも全体に低遅延でした。
このときの経路は以下の通りです。
Traceroute :
1. *
2. 10.60.164.249 # private
3. 172.25.160.193 # private
4. 172.25.161.203 # private
5. 27.86.109.173 # KDDI
6. 27.86.109.169 # KDDI
7. 175.135.250.221 # KDDI
8. 175.135.250.173 # KDDI
9. *
10. *
11. 106.161.xxx.xxx # KDDI (target host)
private 領域を超えた先は Mobile Router のときと若干違いがありますが、まあ同じ経路をたどっているのでしょう。
分布
ちょっと分かりにくいグラフになってしまうのですが、何度も行った計測のうち、それぞれの地点での計測の結果がどのような分布になっているのか、またそれが Mobile Router と Smartphone でどのくらいの違いが出ているのか、ざっくり示します。
左半分の青い×印が Mobile Router での計測値。右半分のオレンジの×印が Smartphone での計測値です。
それぞれの地点で10回 ping で計測して、その結果を縦に並べて示しています。計測の時系列に右に並んでいますが、Mobile Router の左から何番目の地点が、Smartphone での左から何番目に対応する、といったことはありません。恐らく、ですが、少し時間を離して計測すればそれなりに違う結果が出ることが予想されるので、厳密な比較はちょっと意味が無いように思います。（それでも、5m 移動して計測するとかなり悪化し、5m 戻ってきたら比較的近い値が出る、という印象を持つ程度には安定しており、「完全な偶発」でも無いようです。）
それにしても Mobile Router より Smartphone の方が低遅延な数字が出るのはどういうことでしょう。計測環境（使っているツール）が異なるとは言え、しかし Mobile Router に繋がれている Windows PC + WSL でこんな何十ミリ秒もの遅れが出ないことは確認していますし、Smartphone の App が、何十ミリも短めの時間を報告することも無いでしょう。（see; android-netdiag ）
少しこの辺りのノウハウを、多くの環境、多くの端末で、事例として集めるのが良いように思えます。計測した人はぜひ結果をお知らせください。集積しましょう！
その他わかったこと
- 計測は Apple Store 前あたりで行いましたが、ほんの数メートル移動するだけで状況がかなり変わります。この地域が良いと思って試したのですが、実は余り良い環境では無かったのかも知れません。
- 計測は平日の深夜、1am 頃に行いました。昼間に一度試したのですが、夜間にやったときの方が 20-40% 程度低遅延で、振れ幅も低め、という印象です。
- 当然といえば当然ですが、kix-Osaka の Wavelength Zone のインスタンスの方が、nrt-Tokyo のそれよりレスポンスは早いです。
ToDo
- 5G Mobile Router と Smartphone の違いについて情報を集めなければ。
- 一箇所で継続的に測定して変化（安定度？）を見たい。
- もう少し組織的に何度も繰り返し計測できる仕組みを作ってローラー作戦的にデータを集めたい。5G/4G比較も。
- mineo の 5G オプションをつけたものを契約して試したが、これがどうやら閉域網を通らない。その結果をまとめなければ。
気になるお値段は
私にとってこれが（ほぼ）初めての AWS 利用で、現在はこの実験のためにしか AWS を利用していません。それでちょこちょこ遅延計測したところ、こんな感じになりました。
つまり私がちょこちょこ遅延計測した程度では $2.21 ⁄ day から上がりませんでした。三日ほど前からインスタンスを停止したところ、$0.44 程度に下がっています。インスタンスを削除してしまえばゼロになるわけなので、実験する前に作って、実験が終わったら停止するようにしてしまえば、まあお小遣い程度で気楽に試せるのではないかと思います。
au 5G smartphone をお持ちの方はぜひお試し下さい。
おわりに
今回最も気になったのは遅延の大きさそのものではなく、その揺れ（ jitter ）でした。パケットごとに随分違います。
現時点では KDDI の 5G 網は、4G 網の上に構築された NSA タイプです。つまり 5G 接続したとしても、アンテナからワンホップあたりでもう 4G 網に流合する形でパケットが MEC に届けられます。それでもインターネットに一度出たりすることはない、とのことですからまだマシなのでしょうが、大きめの遅延数字と、ちょっと見過ごせない大きな jitter が出ています。
今回の数字や傾向を、他の KDDI 5G MEC 経験のある方などに確認してみたのですが、おおよそ同様の数値とのことでした。私達のテストが何か大きく間違えているわけではない、ということでしょう。むしろ、東京などではこれほど短い数字を見ることがなかった、という話もあったので、やはり利用者が少ないときに試すのが良いようです。（私は現在のところ「悪くてもこのくらい」という数字が欲しいわけではなく、「最良でこのくらいになる」可能性を調べたいので。）
とりあえず現時点では「家庭の固定回線（ファイバ）からインターネット経由でアクセスした方が遙かに低遅延」な状況であることには間違い無いようです。「なんだ 5G MEC ってそんなもんなの？ 5ms くらいで考えてるんじゃ無いの」と思う人もいるでしょうが、私が興味があるのは、これが「交差点の信号機上にアンテナ、その脇の箱に MEC」という状況になったとき、走る車の端末との往復遅延がどのくらいまでその 5ms に近づくか、です。KDDI の Wavelength が SA 方式の経路上に置かれ、京都の最寄りの au 携帯基地局の中に設置されたとき、そのアンテナの近くでどんな数字が得られるか、です。
今回はまず、とりあえず測っただけ、という段階です。この数字が何を意味しているか、どう読み取れば良いか、といった分析・考察は後でもう少し情報を集めながらやろうと思います。