JP2019071573A - ＩｏＴ機器とのデータの送受信を行うための装置、方法及びプログラム - Google Patents

Abstract

【課題】IoTの普及を加速すべく、IoT機器とのデータの送受信を行うための装置において、オーバーヘッドの低減を図る。【解決手段】まず、IoT機器１１０において、何かしらのイベントが発生する。IoT機器１１０は、送信すべきメッセージを生成して、IoT機器１１０に記憶された第１のサーバ１０１の電話番号に対し、SMSにより送信する。第１のサーバ１０１は、当該メッセージを含むSMSデータを受信したことを必要に応じてIoT端末１１０に通知した後、第２のサーバ１０２に対し、当該SMSデータを受け渡す。第２のサーバ１０２は、当該SMSデータのメッセージに含まれる送信先識別子に基づいて、SMSデータに含まれ得る送信先識別子と送信先との対応づけを参照して、送信先を特定する。第２のサーバ１０２は、メッセージから送信先識別子を除いた部分又は送信先識別子を含めたメッセージの全体を第３の外部サーバ１２３に対して送信する。【選択図】図２

Description

本発明は、IoT機器とのデータの送受信を行うための装置、方法及びプログラムに関する。

センシング技術、通信技術の進展に伴い、コンピュータネットワークに接続される機器が増え、あらゆるモノがネットワーク化されるInternet of Thingsという考え方が広まっている。以下、インターネットに限らず、ネットワーク化された機器を「IoT機器」という。

IoT機器は、ネットワークに接続してサーバ、ストレージなどに収集したデータを送信したり、サーバからデータの配信を受けたりすることができるが、そのためには、サーバとの間にセキュアな接続が確立されなければならない。一つの方法としては、所定の通信方式で通信を行うための同一又は対応する認証情報をサーバと機器の両方に予め与えておき、たとえば、機器の電源をオンにした際に動作するソフトウェアが当該認証情報を用いて、サーバとの間の接続を確立するようにすることができる。

SIMカードが挿入されたIoT機器の電源がオンした際には、IoT機器は、当該SIMカードに書き込まれたIMSIのHLR/HSSによる認証を経て、セルラーネットワークにアタッチされた状態となる。セルラーネットワークにアタッチされた後、パケット交換によるデータ通信を行う場合には、追加でGTP接続が行われ、サーバとのIP通信によってデータの送受信を行うことができる。

しかしながら、上述の通信方式であると、本来送受信を行いたいデータに対して、大きなオーバーヘッドが発生している。一例として、GPSトラッキングが可能なIoT機器から、図１に示すような１１オクテットのログデータをサーバに送信することを考えた場合、GTP接続の確立、TCPソケットの確立、HTTP POSTリクエスト、HTTP POSTレスポンス、TCPソケットの切断、そして、GTP接続の切断という数百オクテットのデータ処理が必要となる。このオーバーヘッドはIoT機器における電力消費に直結し、連続稼働時間に大きな影響を与える。

本発明は、このような問題点に鑑みてなされたものであり、その目的は、IoTの普及を加速すべく、IoT機器とのデータの送受信を行うための装置、方法及びプログラムにおいて、オーバーヘッドの低減を図ることにある。

このような目的を達成するために、本発明の第１の態様は、IoT機器とのデータの送信又は受信を行うための装置であって、前記IoT機器から、メッセージを含むSMSデータを受信する第１のサーバと、前記SMSデータに基づいて、前記メッセージ又はこれに対応するデータの送信先を特定する第２のサーバとを備え、前記第２のサーバは、前記送信先とIPネットワーク上で通信を行うことを特徴とする。

また、本発明の第２の態様は、第１の態様において、前記送信先は、前記SMSデータに含まれ得る送信先識別子と送信先との対応づけを参照して特定されることを特徴とする。

また、本発明の第３の態様は、第２の態様において、前記送信先識別子は、前記SMSデータにメッセージの一部として含まれることを特徴とする。

また、本発明の第４の態様は、第３の態様において、前記送信先識別子は、所定の桁数又は所定の桁数以下の数字又は記号であることを特徴とする。

また、本発明の第５の態様は、第１から第４のいずれかの態様において、前記メッセージはバイナリフォーマットであることを特徴とする。

また、本発明の第６の態様は、第５の態様において、前記第２のサーバは、前記SMSメッセージをテキストフォーマットに展開してから前記送信先に送信することを特徴とする。

また、本発明の第７の態様は、第１から第６のいずれかの態様において、前記第２のサーバは、IPネットワーク上の通信により、外部サーバより前記IoT機器への命令が表現されたデータを受信して前記データを前記第１のサーバに受け渡し、前記第１のサーバは、前記データ又はこれに対応するデータをメッセージに含むSMSデータを前記IoT機器に向けて送信し、前記第１のサーバは、前記SMSデータを送信する時に前記IoT機器からのデータを所定時間以上受信していないことを特徴とする。

また、本発明の第８の態様は、IoT機器とのデータの送信又は受信を行うための装置であって、前記IoT機器から、セルラーネットワーク上のシグナリングによって、メッセージを含むシグナリングデータを受信する第１のサーバと、前記シグナリングデータに基づいて、前記メッセージ又はこれに対応するデータの送信先を特定する第２のサーバとを備え、前記第２のサーバは、前記送信先とIPネットワーク上で通信を行うことを特徴とする。

また、本発明の第９の態様は、IoT機器とのデータの送信又は受信を行うための方法であって、前記IoT機器から、セルラーネットワーク上のシグナリングによって、メッセージを含むシグナリングデータを受信するステップと、前記シグナリングデータに基づいて、前記メッセージ又はこれに対応するデータの送信先を特定するステップとを含み、前記送信先への送信は、IPネットワーク上で行うことを特徴とする。

また、本発明の第１０の態様は、コンピュータに、IoT機器とのデータの送信又は受信を行うための方法を実行させるためのプログラムであって、前記方法は、前記IoT機器から、セルラーネットワーク上のシグナリングによって、メッセージを含むシグナリングデータを受信するステップと、前記シグナリングデータに基づいて、前記メッセージ又はこれに対応するデータの送信先を特定するステップとを含み、前記送信先への送信は、IPネットワーク上で行うことを特徴とする。

このような目的を達成するために、本発明の一態様によれば、容量に制約のあるSMSをIoT機器と外部サーバとの通信に用いる際に、外部サーバのURL等の送信先をそのままSMSデータに記述するのではなく、所定の桁数又はそれ以下の数字又は記号の送信先識別子を導入し、当該識別子をSMSデータの受信側で送信先に変換することによって、さまざまな外部サービスとの連携を損なうことなく、大幅なオーバーヘッドの削減を実現することができる。

ＧＰＳトラッキングによるログデータの一例を示す図である。 本発明の第１の実施形態にかかる装置を示す図である。 本発明の第１の実施形態にかかるIoT機器から外部サーバへのデータ送信の流れを示す図である。 本発明の第２の実施形態にかかる、外部サーバからIoT機器への命令送信のシーケンスを示す図である。

以下、図面を参照して本発明の実施形態を詳細に説明する。

（第１の実施形態）
図２は、本発明の第１の実施形態にかかる装置を示す図である。IoT機器１１０にSIMカード１１１が挿入されている場合、発明者らは、オーバーヘッドの大きいIP通信ではなく、SMSを用いても、IP通信と同様に複雑な処理を行いつつ、オーバーヘッドの大幅な圧縮が可能であることを見出した。

装置１００は、SIMカード１１１が挿入されたIoT機器１１０からSMSデータを受信する第１のサーバ１０１と、当該SMSデータに基づいて、当該SMSデータに含まれるメッセージ又はこれに対応するデータの送信先を特定する第２のサーバ１０２とを備える。送信先としては、さまざまなサービスを提供する外部サーバが可能であり、複雑な処理を実現可能である。図２では、第１の外部サーバ１２１、第２の外部サーバ１２２、及び第３の外部サーバ１２３を示している。IoT機器１１０と装置１００との間はセルラーネットワークにおいてSMSにより通信を行う一方、装置１００と外部サーバとの間はIP通信とすることができる。

装置１００は、MNO（移動体通信事業者）の通信装置とすることができるほか、MNOの通信インフラに接続して無線通信サービスを提供する形態のMVNO（仮想移動体通信事業者）の通信装置とすることもできる。MNOとMVNOの間に、MVNOが円滑な事業を行うための支援サービスを提供するMVNE（仮想移動体通信サービス提供者）が介在し、MVNEがMNOの通信インフラに接続して無線通信サービスを提供するための通信インフラを有することもある。この場合には、装置１００は、MVNEの通信装置とすることができる。また、装置１００が備える第１のサーバ１０１はMNOの通信装置、第２のサーバ１０２はMVNE又はMVNOの通信装置というように、異なる事業者の通信インフラであることもある。

第１のサーバ１０１は、SMSセンター（SMSC）と呼ばれる、SMSメッセージを送信又は受信するためのサーバであり、第２のサーバ１０２は、メッセージをボディデータとして含むSMSデータを第１のサーバ１０１から受け取り、当該メッセージに対して適宜必要な処理を施して、これを適切な受け手に向けて送信する。第１のサーバ１０１及び第２のサーバ１０２は、それぞれパブリッククラウド又はプライベートクラウド上の１又は複数のインスタンスとすることができ、特に第２のサーバ１０２は、機能に応じて複数のインスタンスに分けて設計するのが適切なことがある。第２のサーバ１０２における機能の一部又は全てを第１のサーバ１０１において担うことも考えられる。

ここで、本明細書において「クラウド」とは、ネットワーク上で需要に応じてCPU、メモリ、ストレージ、ネットワーク帯域等のコンピューティングリソースを動的にプロビジョニングし、提供できるシステムを言う。たとえば、AWS等によりクラウドを利用することができる。また、「パブリッククラウド」とは、複数のテナントが利用可能なクラウドを言う。

IoT機器１１０は、所要の通信機能を有する任意の機器とすることができ、セルラーネットワークに接続するためのIMSIなどの識別番号を有していればよい。セルラーネットワークにおいてIP通信を行うためには、パケット交換ネットワーク（PS）への接続が必要であるところ、SMSによる通信のためには、回線交換ネットワーク（CS）に接続すれば足りることから、PSへの接続のために求められる機能を取り除いた簡素化された機器の採用が可能となる。

本明細書では、主にSIMカードがIoT機器１１０に挿入されている例を用いて説明をするが、IMSIなどの識別番号は、物理的なSIMカード１１１に記憶されるのみではなく、IoT機器１１０に組み込まれた半導体チップ（「eSIM」とも呼ばれる。）上に１又は複数のIMSIが記憶されること、IoT機器１１０のモジュール内のセキュアなエリアにソフトウェアを搭載し、当該ソフトウェア上に１又は複数のIMSIが記憶されることも可能であり、IoT機器１１０が直接的又は間接的に識別番号を保持する態様は、さまざま考えられる。IoT機器１１０には、IMSIなどの識別番号に加えて、自らのMSISDNなどの電話番号、さらにSMSCである第１のサーバ１０１のMSISDNなどの電話番号が記憶されている。

第１の外部サーバ１２１、第２の外部サーバ１２２及び第３の外部サーバ１２３は、それぞれ、さまざまな用途のものとすることができる。たとえば、IoT機器１１０を運用する企業の自社サーバにHTTPでのデータ送信を行ったり、SSL/TLS上のHTTPによりセキュアにデータ蓄積を行ったり、第2のサーバ１０２がクラウド上のインスタンスないしサーバである場合に同一クラウド又は別クラウドのインスタンスないしサーバにデータ転送を行ったりする用途が挙げられる。送信先のサーバやクレデンシャル、用いるプロトコル等の設定情報を装置１００においてSIMカードごとに保持し、その設定情報に従ってSMSで送信されたデータを転送する仕組みとすることができる。

本明細書において説明される各デバイスは、物理的に単一のデバイスに限られず、複数の相互にアクセス可能なデバイスとすることができる。また、第２のサーバ１０２について、通信インターフェースなどの通信部１０２−１と、プロセッサ、ＣＰＵ等の処理部１０２−２と、メモリ、ハードディスク等の記憶装置又は記憶媒体を含む記憶部１０２−３とを備え、記憶部１０２−３又は第２のサーバ１０２からアクセス可能な記憶装置又は記憶媒体に記憶された各処理を行うためのプログラムを処理部１０２−２において実行することによって各機能を実現することができるものとして図示しているように、その他のデバイスについても、同様のハードウェアによって実現することができる。上記プログラムは、１又は複数のプログラムを含むことがあり、また、コンピュータ読み取り可能な記憶媒体に記録して非一過性のプログラムプロダクトとすることができる。

図３に、本発明の第１の実施形態にかかる、IoT機器から外部サーバへのデータ送信のシーケンスを示す。まず、IoT機器１１０において、何かしらのイベントが発生する（Ｓ３０１）。たとえば、タイマが発動して、IoT機器１１０のセンサが取得した情報を第３の外部サーバ１２３に送信したいといった例が挙げられる。

IoT機器１１０は、取得した情報が記述されたメッセージを生成して、IoT機器１１０に予め記憶されている第１のサーバ１０１の電話番号に対し、SMSにより送信する（Ｓ３０２）。当該メッセージには、メッセージの少なくとも一部又はこれに対応するデータの送信先となる第３の外部サーバ１２３を識別するための送信先識別子が含まれる。送信先識別子は、１００１、１００２、１００３、２０００等のように４桁の数字とすることができ、より一般的に、所定の桁数又は所定の桁数以下の数字又は記号とすることができる。SMSにより送信可能なメッセージの容量は、１４０オクテット等と非常に限られているため、バイナリフォーマットとするのが望ましい。

第１のサーバ１０１は、当該メッセージを含むSMSデータを受信したことを必要に応じてIoT端末１１０に通知した後（Ｓ３０３）、第２のサーバ１０２に対し、当該SMSデータを受け渡す（Ｓ３０４）。この際、IoT端末１１０に記憶された識別番号又はこれに基づいて判定可能な送信元であるIoT端末１１０の電話番号をSMSデータに含めてもよい。

第２のサーバ１０２は、当該SMSデータのメッセージに含まれる送信先識別子に基づいて、SMSデータに含まれ得る送信先識別子と送信先との対応づけを参照して、送信先を特定する（Ｓ３０５）。送信先は、IPネットワーク上のURLとすることができ、数十オクテットとなることも少なくない。メッセージがバイナリフォーマットの場合、第２のサーバ１０２は、送信先である第３のサーバ１２３において扱いやすいように、一般にサーバ側で広く用いられるフォーマット、たとえばJSON、XML等のテキストベースのフォーマットに展開を行ってもよい（Ｓ３０６）。

第２のサーバ１０２は、メッセージから送信先識別子を除いた部分又は送信先識別子を含めたメッセージの全体を第３の外部サーバ１２３に対して送信する（S３０７）。送信は、一例として、メッセージの少なくとも一部又はこれに対応するデータをJSON形式等でHTTP POSTリクエストによって送信することができる。

各装置は、図３において点線で示すように、それぞれが行った送信に対して結果を受け取った際又は送信を行った際にインアクティブとしてもよい。各装置がアクティブな期間を縦長の矩形で示している。

容量に制約のあるSMSをIoT機器と外部サーバとの通信に用いることは、外部サーバのURL等の送信先が容量の大きな割合を占めてしまうことから非現実的であるところ、上述のように、所定の桁数又はそれ以下の数字又は記号の送信先識別子を導入し、当該識別子をSMSデータの受信側で送信先に変換することによって、SMSによる通信が現実的に可能となり、さまざまな外部サービスとの連携を損なうことなく、大幅なオーバーヘッドの削減がもたらされる。また、サーバ側が外部に公開されているような場合、認証のためのクレデンシャルをクライアントに要求することがセキュリティ上必要となるのが一般的であり、この情報もSMS上で伝送しようとするとオーバーヘッドとなるが、本実施形態では、サーバ側でこの情報を保持し、適宜適用することでこれを削減可能である。このためには、送信先又は送信先識別子とクレデンシャルとの対応づけを装置１００において保持しておけばよい。

上述の説明では、送信先識別子に基づいて送信先の特定を行っているが、送信先識別子に加えて、又は送信先識別子に代替して、SMSデータに包含又は付加された送信元の電話番号又はSMSデータのメッセージの少なくとも一部に基づいて、送信先の特定を行うようにしてもよい。

また、本実施形態では、IoT機器１１０から装置１００乃至第１のサーバ１０１へのデータ送信をセルラーネットワーク上のSMSにより行ったが、これは必ずしもSMSのみに本発明の精神を限定するものではなく、SMS以外のセルラーネットワーク上のシグナリングを採用することも考えられる。この場合、第１のサーバ１０１が受信するデータは、「シグナリングデータ」と呼び、より具体的には、クライアントから送信が可能で、受信したサーバ側で当該送信に使用された識別番号を一意に、かつセキュアに特定できるデータと定義することができる。たとえば、シグナリングデータは、USSDによるメッセージを含むことができる。

なお、「××のみに基づいて」、「××のみに応じて」、「××のみの場合」というように「のみ」との記載がなければ、本明細書においては、付加的な情報も考慮し得ることが想定されていることに留意されたい。

また、念のため、なんらかの方法、プログラム、端末、装置、サーバ又はシステム（以下「方法等」）において、本明細書で記述された動作と異なる動作を行う側面があるとしても、本発明の各態様は、本明細書で記述された動作のいずれかと同一の動作を対象とするものであり、本明細書で記述された動作と異なる動作が存在することは、当該方法等を本発明の各態様の範囲外とするものではないことを付言する。

（第２の実施形態）
第２の実施形態では、たとえば第１の実施形態において例示したセンサデータの送信の前提として、外部サーバから、データ取得等の命令を行う。命令に従った動作の結果として生じるデータは、第１の実施形態にて説明した流れで外部サーバに送信可能である。

図４に、本発明の第２の実施形態にかかる、外部サーバからIoT機器への命令の送信のシーケンスを示す。まず、第２の外部サーバ１２２において、何かしらのイベントが発生する（Ｓ４０１）。たとえば、IoT機器１１０の管理者が端末側の状況が気になったので、IoT機器１１０において、センサデータを取得する処理を実行させるためのボタンを押下するような状況が考えられる。

第２の外部サーバ１２２は、IoT機器１１０を識別する機器識別子をパラメータとして、上記命令をボディデータとして、IoT機器１１０に対する命令をWeb APIに渡す（Ｓ４０２）。機器識別子は、IoT機器１１０の電話番号とすることができるほか、IMSI等の識別番号、機器名等とすることもできる。

Web APIは、受け取った命令がテキストフォーマットの場合、必要に応じてこれをバイナリフォーマットに変換してもよい（Ｓ４０３）。そして、Web APIは、機器識別子が電話番号以外のときは、機器識別子と電話番号との対応づけを参照してIoT機器１１０の電話番号を特定して、第２のサーバ１０２にIoT機器１１０の電話番号及びIoT機器１１０に対する命令又はそれに対応するデータを渡す（Ｓ４０４）。図２では、Web APIを提供するサーバ又はインスタンスを図示していないが、これを第２のサーバ１０２と別個に設けてもよく、第２のサーバ１０２において提供してもよい。また、別個のサーバ又はインスタンス上のWeb APIを含めて、第２のサーバ１０２と捉えてもよい。

第２のサーバ１０２は、第１のサーバ１０１に対し、送信先をIoT機器１１０の電話番号、メッセージを受け取った命令又はそれに対応するデータとするSMSデータの送信要求を送信する（Ｓ４０５）。この際、SMSデータの送信元はSMSCである第１のサーバ１０１に付与された電話番号となるところ、命令を行った第２の外部サーバ１２２又は第２の外部サーバ１２２から命令を行った管理者を特定する外部送信元又はそれを表す識別子をメッセージに含めることもできる。

第１のサーバ１０１は、前記命令を表したデータ又はこれに対応するデータをメッセージに含むSMSデータをIoT機器１１０に送信する（Ｓ４０６）。IoT機器１１０は、必要に応じて受領確認応答を返し（Ｓ４０７）、命令に従った処理を実行する（Ｓ４０８）。

ここで、本実施形態にかかる方法では、IoT機器は、いつ飛んでくるか分からない命令乃至指示を受け取るために常にオンラインでいることが要求されないことを一つの特徴とする。SMSによる通信ではなく、IP通信である場合には、一般に、サーバとの間にNAT等の機器が介在し、サーバから直接アクセスすることができず、TCP/UDPセッションが確立されるたびに当該サーバおよび経路上のファイアウォール、NAT等の各機器においてステート情報を作成してこれを保持することで、サーバからのアクセスを可能としている。そして、ステート情報は一般に、ソフトステートでの実装であることが多く、有効期限が定められていることから、有効期限前に機器から空のデータを送信してステート情報を維持するkeepaliveと呼ばれる手法がしばしば用いられる。そして、keepaliveの必要性は、大きなオーバーヘッドとなっている。

これに対し、SMSによる通信では、ページングによってドーマントモードのモデムを起こしてメッセージの着信を知らせることができるため、本実施形態にかかる第１のサーバ１０１は、IoT機器１１０に定期的又は断続的なデータ送信をさせることなく、任意のタイミングでSMSデータを送信して命令を実行させることができる。第１のサーバ１０１の視点では、keepaliveが不要であることから、IoT機器１１０からのデータを所定時間以上受信していなくとも、SMSデータを送信することができる。たとえば、IP通信では数分以上又は数十分以上keepaliveを行わずに任意のタイミングでサーバからアクセスすることは困難であることも少なくないが、本実施形態によれば、IoT機器１１０は、そのような長期間に渡ってデータ送信をすることを必要としない。

より具体的には、keepaliveのためのデータ送信頻度は、ネットワークパス上の各機器におけるステート情報の有効期限に依存するため一概に決めることはできないが、自身が管理していないネットワークにおいては設定が変わり得ることなどから、安定して疎通性を維持するために最も短い機器に合わせて設定する必要がある。特にIoTでよく用いられるUDPでは、長時間セッションが持続するアプリケーションで多く用いられるTCPに比べてステートを維持するタイマが短いことが多く、keepaliveを数十秒から数分の高頻度で行う必要がある。

例として、OMA LWM2Mを用いて任意のタイミングでサーバからデータ取得コマンドを実行できるよう、１分ごとにサーバに対してkeepaliveとしてRegistration Updateリクエストを送るケースを考えてみる。

仮にリクエストサイズを８０オクテット、レスポンスサイズを８０オクテットとすると、１日当たりのkeepaliveのための通信量は２３万４０オクテットとなり、１月では約７ＭＢとなり、デバイス数が多い場合には無視できないコストを発生させる。

さらに、デバイスがバッテリ駆動の場合には、この通信を行うために常にデバイス及びモデムがアクティブでなければならず、バッテリライフタイムを大幅に短くする。スリープモードで命令乃至指示を待っていて、命令があったときにデータ送信のためにアクティブとなり、電力を消費するSMS通信と、常にアクティブであり、かつ、keepaliveのために高頻度でデータ送信を行い続けなければならないIP通信とでは数十倍、数百倍の差を生む。

１００ 装置
１０１ 第１のサーバ
１０２ 第２のサーバ
１０２−１ 通信部
１０２−２ 処理部
１０２−３ 記憶部
１１０ IoT機器
１１１ SIMカード
１２１ 第１の外部サーバ
１２２ 第２の外部サーバ
１２３ 第３の外部サーバ

Claims (10)

1. IoT機器とのデータの送信又は受信を行うための装置であって、
   前記IoT機器から、メッセージを含むSMSデータを受信する第１のサーバと、
   前記SMSデータに基づいて、前記メッセージ又はこれに対応するデータの送信先を特定する第２のサーバと
   を備え、
   前記第２のサーバは、前記送信先とIPネットワーク上で通信を行うことを特徴とする装置。
2. 前記送信先は、前記SMSデータに含まれ得る送信先識別子と送信先との対応づけを参照して特定されることを特徴とする請求項１に記載の装置。
3. 前記送信先識別子は、前記SMSデータにメッセージの一部として含まれることを特徴とする請求項２に記載の装置。
4. 前記送信先識別子は、所定の桁数又は所定の桁数以下の数字又は記号であることを特徴とする請求項３に記載の装置。
5. 前記メッセージはバイナリフォーマットであることを特徴とする請求項１から４のいずれかに記載の装置。
6. 前記第２のサーバは、前記SMSメッセージをテキストフォーマットに展開してから前記送信先に送信することを特徴とする請求項５に記載の装置。
7. 前記第２のサーバは、IPネットワーク上の通信により、外部サーバより前記IoT機器への命令が表現されたデータを受信して前記データを前記第１のサーバに受け渡し、
   前記第１のサーバは、前記データ又はこれに対応するデータをメッセージに含むSMSデータを前記IoT機器に向けて送信し、
   前記第１のサーバは、前記SMSデータを送信する時に前記IoT機器からのデータを所定時間以上受信していないことを特徴とする請求項１から６のいずれかに記載の装置。
8. IoT機器とのデータの送信又は受信を行うための装置であって、
   前記IoT機器から、セルラーネットワーク上のシグナリングによって、メッセージを含むシグナリングデータを受信する第１のサーバと、
   前記シグナリングデータに基づいて、前記メッセージ又はこれに対応するデータの送信先を特定する第２のサーバと
   を備え、
   前記第２のサーバは、前記送信先とIPネットワーク上で通信を行うことを特徴とする装置。
9. IoT機器とのデータの送信又は受信を行うための方法であって、
   前記IoT機器から、セルラーネットワーク上のシグナリングによって、メッセージを含むシグナリングデータを受信するステップと、
   前記シグナリングデータに基づいて、前記メッセージ又はこれに対応するデータの送信先を特定するステップと
   を含み、
   前記送信先への送信は、IPネットワーク上で行うことを特徴とする方法。
10. コンピュータに、IoT機器とのデータの送信又は受信を行うための方法を実行させるためのプログラムであって、前記方法は、
    前記IoT機器から、セルラーネットワーク上のシグナリングによって、メッセージを含むシグナリングデータを受信するステップと、
    前記シグナリングデータに基づいて、前記メッセージ又はこれに対応するデータの送信先を特定するステップと
    を含み、
    前記送信先への送信は、IPネットワーク上で行うことを特徴とするプログラム。

Images