ちょうど二年前のIT Pro ExpoでIoTプラットフォームSORACOMをローンチしたのですが、その当時はサービスもSORACOM AirとSORACOM Beamのみで、対応する無線通信技術もセルラーのみでした。それが今となってはA-Jの合計11のサービスをラインアップし、対応する無線技術もセルラーに加えて話題のLPWAN技術LoRaWANやSigfoxに対応し、8,000を超えるお客様にご愛顧いただけるようになりました。
今回、発表以来3回目となる今年のIT Pro Expoでは、ローンチ当初からご愛顧いただいてきたSORACOM Air for CellularとSORACOM Beam、またSORACOM Beamの兄弟サービスともいえるSORACOM Funnel, SORACOM Harvestに新たな機能をお届けできることをこのブログでご報告します！
進化したSORACOM Air for Cellularのインフラストラクチャ
少し裏側の話をしますと、サービス開始当初のSORACOMのインフラストラクチャにはいわゆるMVNOとしてキャリア様のネットワークと相互接続するのに最低限必要なパケット交換機能のみを実装しておりました。それに加え、今回こちらのブログでお伝えしたとおり、加入者管理機能HLRを独自に実装し、SORACOMインフラストラクチャに組み込んだことで、これまでは実現できなかったSIMの状態管理やより柔軟な料金体系の提供、自由なSIMプロダクトの展開に至ることが出来ました。
実はもう一つ、今回のローンチに合わせてSORACOMインフラストラクチャに実装、導入された機能コンポーネントがあります。それがSMS送受信を行うネットワークコンポーネントであるSMSCです。HLRに加え、SMSCを独自に実装し、SORACOMが従来から持つAPIサービスと連携させたことで実現したのがこのブログで紹介する新機能です。では順をおってみていきましょう！
SMSをreinvent：APIによるセキュアなSMS活用を可能にするSORACOM Air SMS API
SMSは皆様ご存知の通り、昔からある枯れた技術でもありながら、今もなおモバイルコミュニケーションの中の根幹を担っているメッセージング技術です。日本だと歴史的経緯からあまり広くコンシューマの間に広まってはいないと感じますし、スマートフォン向けのプッシュ通知が充実してきた昨今ではアプリでのメッセージングの方がより広く使われている傾向は日本に限らず見られますが、広い目で見るとSMSは長らく日常の人々のテキストメッセージはもちろんのこと、Machine-to-machine (M2M)通信や、モバイルペイメントの仕組みの1つとして、また多要素認証のためのワンタイムパスワードをインターネットに依存しない形で送る仕組みとしてなど、ありとあらゆる場面で活用されています。
なぜSMSはこうも多様な場面で活用されるのでしょうか？他にもいろいろあると思いますが、IoTプラットフォームを提供するソラコムの観点から特に注目すると、以下の3つの点が他のメッセージング手段にない利点を持っているからだと考えます。
- モデムを低消費電力なドーマントモードにしておいても基地局からのページングシグナルを受けて起こして受信することができる
- IP通信に依存せず、セルラーネットワークのシグナリングだけで送受信できる
- SIMカードによる認証を行っており、送信者や受信者が詐称できない
特に、1の特徴はサーバ側からのプッシュ通知を容易にしてくれるため、IPデータ通信に頼った場合に課題となる常時オンでのデバイス運用やポーリングを行わないとサーバ側からのプッシュ通知が出来ず、バッテリのライフタイムや通信量のオーバーヘッドに関して不利になってしまう問題に対する1つの解を与えてくれます。
また、2の特徴は、IPデータ通信セッションを確立するオーバーヘッドが無視できないようなユースケースや、デバイス側の制約でIP通信が難しいような場合でも通信を可能にできる可能性をもたらします。
一方で、SMSは番号さえわかれば相手に送ることができるため、IoTのユースケースを考えると、デバイスの番号を推測してアタックすることで誤動作や不必要なバッテリの消費などを促す可能性があるという側面も持ち合わせていました。
そこで様々なユースケースをお客様にヒアリングしながら設計し、この度リリースしたのがSORACOM Air SMS APIです。
上図にある通り、SORACOM APIの一部として、JSONドキュメントをPOSTするだけでSMSを送信できるAPIを用意しました。これにより、必要な時にWebコンソールやCLIからAPIコールをするだけでデバイスに対してメッセージの送信が可能となります。
1つの特徴は、デバイスにSMSを送信可能なのはそのSIMを所有するOperatorあるいはそのSAMユーザのみとしている点です。所有していないSIMを指定してAPIコールをしてもリクエストは拒否されます。また、先述のセキュリティ面の懸念を考慮し、例えデバイスの電話番号が漏れたり推測されたりとしても、外部からSMSを受信することはない設計のため、想定していないメッセージを受信して誤動作やバッテリ消耗をする心配も減らせます。
デバイス同士のSMSのやり取りについても、そのSIMを所有するOperatorのSIM同士に限定しているため、デバイス間通信をSMSで行う場合でも同様に想定外のメッセージを受け取ったり、想定外の宛先にメッセージを届けてしまう心配がありません。
SMS APIの使いどころ
SORACOMではサービスや機能を提供し、それに対するお客様のフィードバックを基に新機能を考えるという流れで開発を行っています。SORACOM Airを公開して以来、特にGlobal版をリリースしてからSMSに関しても多くのご要望を頂いてきました。
特にSMSの活用についてはGlobalのお客様からご要望が多かったのですが、それらを大別すると以下の3つに分けられました。
どれもSMSの利点を活用していて、他にそれを超えるうまいやり方も見当たらないことからSORACOMとしてもSMS APIの提供に至ったユースケースといえます。
特に一番上のスリープモードのデバイスを起こすユースケースなんかは正にSMSの利点を活かした使い方だと思います。
また、二番目の設定情報の投入も、IPデータ通信セッションが張られる前で他に外からメッセージを送る手がない状態でも使えるので、これもSMSの使い方として面白いなと思います。実際お客様のお話を聞いていると、現状は機器に設定を入れるのにスマホで一つ一つ送っていて大変という声があり、それを自動化してあげたいと思ったのも今回API提供に至った理由の1つでした。
三番目もセキュアなチャネルをオンデマンドで張る、しかもそれをトリガするのはIPですらない、SMS通信で行うと言ったあたりがエレガントな仕組みだなと思いました。
SMS APIはWeb ConsoleやCLIを使って呼ぶことができ、Public Betaで本日から利用可能です！Public Beta期間中は料金は無料ですので、この機会に使い勝手を見ていただけると幸いです。
SORACOM Beam, Funnel, HarvestがSMS Inputに対応
先述のSMS APIは主にサーバからデバイスへの送信が中心でしたが、デバイスからの送信についてはどうでしょうか？それについてもSORACOMならではの機能を今回発表いたしました。
デバイスからデータをクラウド側に送信する際、Public Endpointに対する転送をセキュアに実現するSORACOM Beamや、AWS、GCP、Azureを始め、各種クラウドサービスにデータを転送するアダプタを提供するSORACOM Funnel、SORACOM上でデータを収集・可視化するサービスであるSORACOM Harvestがそれぞれ、SMSによるデータ転送に対応しました！
各サービスにはそれぞれ対応するSMS用の番号が下記のように割り当てられていますので、端末からはそれぞれの番号に対して送るだけでデータをクラウドに送ることができます。
- SORACOM Beam → 901011
- SORACOM Funnel → 901021
- SORACOM Harvest → 901031
なお、以下を指定してください
- NAI: Nature of Address Indicator (TON: Type of Number) = 0 (Unknown)
- NPI: Numbering Plan Indicator = 9 (Private)
設定も他のプロトコルの場合と同様、簡単です。SORACOM Beam以外は特に特別な設定も必要ありません。
SMSを使ったデータ送信を行う場合の利点としては、
- データ通信セッションを起動することなくデータ送信可能であることからオーバーヘッド削減による省電力化が見込めること
- データ通信に対応していないデバイス/エリアでも動作することからより制約の多いデバイスやモジュールでもデータ送信に対応できること
などが挙げられるかと思います。バイナリフォーマットを使うことで140 バイトまで送信可能であることも、昨今のLPWANのペイロードサイズなどを鑑みるとすごく余裕がある数字に見えます。
じゃあ全部SMSで済ませればいいかというと、実際はデータ通信単価という観点で考えるとIPデータ通信で同量のデータを送るのに比べて割高になりがちなので、データを高頻度で送信する場合や、双方向での通信が必要になる場合には今まで通りIPデータ通信を活用していただくのを検討していただいた方がよいかと思います。SMSの利用はデバイス側の制約があったり、バッテリのライフタイムがクリティカルなユースケース、IPデータ通信が使えない場合のバックアップとしての利用が適切かなと思います。
このあたり含め、実際にPublic Beta期間中に試して「こういうところで役に立ちそう！」と言ったフィードバックや、改善のご要望などいただければ幸いです！