投稿日

セッション切断APIの公開とその使いどころ

ソラコムの江木です。

今日は少しマニアックではありますが、SORACOMを使いこなす際にお役に立てて頂けるであろうAPIを公開したことをお知らせしたいと思います。

セッション切断APIを公開

セッション切断APIとは何かといいますと、その名の通り、呼ぶと指定した端末の3G/LTEセッションをネットワーク側から切断することが出来るAPIです。

API Referenceから実際に呼んでみていただくことが出来ます。

API Reference

あるいは、SORACOM CLIを最新版に更新して頂ければ、下記のように呼び出すことが出来ます。

  $ soracom subscribers delete-session --imsi <対象のSIMのIMSI>

実際にお試し頂くと、お気づきになるかと思うのですが、何も起こらなかったように見えると思います。これは多くの端末で、ネットワーク側からの切断の場合には即座に再接続を試行するように設定されているためです。つまり、APIを呼んだ直後、

  1. ネットワーク側からセッションを切断
  2. 端末から再接続

という動作が行われています。期待通り動作したかどうか確認するには、セッション履歴を見てみる必要があります。実際見てみると、 DeletedCreated というイベントがAPIを読んだ直後に記録されていると思います。(デモをしたり動作を説明するのにこんなにわかりにくいAPIも珍しいと思うくらいです…)

セッション切断APIの使いどころ

さて、見せにくいし効果もよくわからないと思われるかもしれないセッション切断APIなのですが、一体どんなときに役に立つのでしょうか?「何でせっかく繋がってるのにわざわざ切るの?しかもすぐまた再接続されるのに」という声が聞こえてきそうですが、それはとても良い質問です。

SORACOM AirのSIMが入った端末の設定を更新する際、スピードクラスやステータスの変更などを含め、多くの設定はAPIコールと同時に即時反映されるようになっています。しかし、セッションごとに独立している設定についてはAPIコールの後即時反映はされず、次のセッション開始時から適用されるものがあります。例えば、カスタムDNS設定、Virtual Private Gateway (VPG)の使用有無やそのIDなどがこれに該当します。

これらの設定変更を反映するには、端末側で一旦セッションを切って再接続(スマートフォンやタブレットなら機内モードのOn/Off、USBドングル等ならPPPの切断と再ダイアルアップなど)が必要なのですが、いつも端末側を操作できるとは限らないかと思います。

例えば、リファレンスアーキテクチャでも紹介されている、SORACOM APIを使って認証済み端末とそうでない端末でアクセス制限を変えるような仕組みを実装するような場合には、認証が通ったタイミングでネットワーク側からの指示でセッションの再確立を促したい場合があると思います。その場合には一旦SIMの状態を inactive にするAPIコールをして、直後に active に戻すという操作で実現する方法があります。多くの3G/LTE端末はネットワーク側からのセッション切断の場合、即座に再接続を試行するため、一旦 inactive にすることで切断すれば、端末側からの自動再接続でセッション設定が更新されるというわけです(下図の4, 5)。

認証ポータルのリファレンスアーキテクチャ

もうお気づきかもしれませんが、セッション切断APIを使用すると、上記のステータス変更による方法では2回必要だったAPIコールが1度で済みます。また、新規セッションの確立を拒否する inactive のステータスになる瞬間がないため、 active に戻すまでに間が空いてしまったなどの理由でステータスが inactive の間に端末が再接続を試みることで失敗してしまうというリスクも無くせるので、セッションに関係する設定を更新して反映させたい場合に適した操作が出来るというわけです。

なお、上記のような仕組みを実現する意味でも、無通信状態が続いたことによる切断や万が一のネットワーク側の障害への対応の意味でも、オンライン状態を続ける必要があるデバイスについてはセッションが切れたら再接続をするように設定されているかどうかご確認頂くのは重要です。スマートフォンやタブレットなどは特に意識する必要はないかもしれませんが、USBドングルや通信モジュールを使ってラズベリーパイやPCなどを接続している場合には、再接続を試みる設定になっているか予め確認しておくのがおすすめです。

セッション切断API開発の裏話

海外から日本にやってくる旅行者の方々がスマートフォンなどを利用できるよう、プリペイド型のデータ通信用SIMカードを販売されているeConnect Japanさんです。

eConnect JapanさんはSORACOMをローンチ当時から活用してくださっていて、「チャージ済みのデータ容量を使い切ったら、追加のデータ容量を購入できるチャージ専用サイトへカスタムDNSで誘導する」という仕組みを実際に構築運用されています。それこそカスタムDNS機能ができたてほやほやの頃からお使い頂いてきました。1月に開催したSORACOM Conference Connected.では、CEOの小山さんがご登壇下さり、 そのノウハウを惜しみなく発表してくださいました。

そんなeConnect Japanさんで実際に開発を担当されていて、SORACOM APIの一番のヘビーユーザのうちの一人と言っても過言ではないCTOの多田さんから頂いたのは::

「eConnectのユースケースだと、カスタムDNSでeConnectサイトにしか接続できない状態のお客さまがチャージしてくれた際に、セッション再確立ができずにオフライン状態が続いてしまうことがある」

というご相談でした。

可能性としては上述の、 inactive になっている間に端末が再接続を試行して、その後の試行までに間が空いてしまうという問題が考えられました。また、そもそも上記目的のために2回APIコールをしてもらうのはお客さまにとって2度手間です。そこで今回発表したセッション切断APIの開発と公開に至ったというわけです。

API公開にあたって、多田さんから以下のようなコメントを頂きました。


こんにちは、eConnect Japanの多田です。
セッション切断APIのおかげでオフライン問題もすぐに解決し、今では弊社サービスを支える最も重要なAPIの1つとなっています。せっかくの機会ですので、実際に導入して感じているメリットをご紹介させてください。

  • どんな端末でも安定してセッション再確立ができるようになった
  • セッション再確立にかかる時間が短縮された(セッション切断後ほぼ一瞬で再通信できています。遅い端末でも数秒程度です)
  • APIコールが1回だけになったことで、大量のSIMを連続処理する時間が短縮された

セッションの切断は、カスタムDNSを反映させたいときなど重要な場面で行われるため、上記のメリットは私たちにとって非常にありがたいものでした。

また、上述のオフライン問題をソラコム安川さんに相談したところ、翌日には「セッション切断APIを検討します」とのお返事をいただき、わずか2週間後にはデプロイされていました…。
こういったとんでもないスピードでの進化や、私たちユーザの声を大切にしてくれるところもSORACOMの大きな魅力です!


まとめ

今回、ある意味非常に玄人向けなSORACOMのサービスを使い込んでいる方、あるいはこれから使い込もうとしてくださっている方向けの発表でしたが、いかがでしたでしょうか?

最後の開発に至った背景にもある通り、SORACOMは皆様のご要望やフィードバックを受けてより良いプラットフォームになれるように進化していきます。どうぞ皆様、使い込んでいただいて、お気づきの点やご要望などありましたらお聞かせ下さい!