JP7177873B2 - ゲートウェイ装置、データ送信方法、及びプログラム - Google Patents

Description

本発明は、ＩｏＴ端末をクラウドに接続させる技術に関連するものである。

ＩｏＴ端末（例：センサー、トラッカー）からのデータ（稼働状態、位置、温湿度など）をクラウドに送信し、クラウドの機能を使ってデータ収集、蓄積、データマネジメントを行う付加価値サービスが増加している。

上記付加価値サービスを提供するにあたり、ＩｏＴ端末において、クラウド接続情報のキッティングや、クラウドが提供するインタフェースの処理に合わせた実装や設定が必要となる。また、クラウドの新規機能に対応する度に、ＩｏＴ端末の設定やアプリケーション実装を適合させていく必要がある。

ＷＯ２０１９／０５９０３４

従来技術では、ＩｏＴ端末側でクラウド接続に必要な実装や設定を行う必要があるため、大きなコストがかかるとともに、拡張や変更に対する柔軟性が欠如しているという課題があった。

本発明は上記の点に鑑みてなされたものであり、クラウド固有の設定に依存することなく共通の端末設定で任意のクラウドへＩｏＴ端末から出力されるデータを送信するための技術を提供することを目的とする。

開示の技術によれば、端末とクラウドとの間に備えられるゲートウェイ装置であって、
前記端末から送信されたヘッダ付きデータを受信し、当該ヘッダ付きデータのヘッダを外してデータを取得する端末接続部と、
前記データを宛先クラウドへ送信するための処理を前記データに施すことにより送信データを生成し、当該送信データを前記宛先クラウドへ送信するクラウド接続部と、
前記端末接続部により取得された前記データを格納するキューイング部と、を備え、
前記クラウド接続部は、前記キューイング部から前記データを取得する
ゲートウェイ装置が提供される。

開示の技術によれば、クラウド固有の設定に依存することなく共通の端末設定で任意のクラウドへＩｏＴ端末から出力されるデータを送信するための技術が提供される。

本発明の実施の形態におけるシステム構成図である。 プロトコル変換ＧＷ装置の構成図である。 管理装置の構成図である。 システムの動作を説明するためのシーケンス図である。 装置のハードウェア構成図である。

以下、図面を参照して本発明の実施の形態（本実施の形態）を説明する。以下で説明する実施の形態は一例に過ぎず、本発明が適用される実施の形態は、以下の実施の形態に限られるわけではない。例えば、以下の説明では、データの送信元となる端末としてＩｏＴ端末が使用されるが、データの送信元となる端末はＩｏＴ端末に限定されるわけではなく、例えば、ＰＣ、スマートフォン等の端末がデータの送信元になってもよい。

（システム構成例）
図１に、本発明の実施の形態における通信システムの全体構成例を示す。図１に示すように、本実施の形態の通信システムは、プロトコル変換ＧＷ（ゲートウェイ）装置１００、ロードバランサ３００、管理装置４００を有する。プロトコル変換ＧＷ装置１００は、ロードバランサ３００と管理装置４００のそれぞれと通信可能である。プロトコル変換ＧＷ装置１００、ロードバランサ３００、管理装置４００はいずれも、物理マシンにより実現されてもよいし、クラウド上の仮想マシンにより実現されてもよい。なお、プロトコル変換ＧＷ装置１００をゲートウェイ装置と呼んでもよい。

アクセス網２００には複数のＩｏＴ端末１が接続されている。プロトコル変換ＧＷ装置１００は、複数のクラウドと通信可能である。図１の例では、クラウドＡ、Ｂ、Ｃが示されている。

ＩｏＴ端末１は、例えば、センサ、トラッカー等である。本実施の形態では、ＩｏＴ端末１の処理能力が低いことを想定しており、ＩｏＴ端末１はデータを暗号化しないで送信する。ＩｏＴ端末１は、例えば無線ＬＡＮあるいは携帯電話網を介してアクセス網２００に接続される。アクセス網２００は、例えば地域のＩＰ網である。

図１には、プロトコル変換ＧＷ装置１００が１台のみ示されているが、これは例であり、複数台のプロトコル変換ＧＷ装置１００が備えられてもよい。複数台のプロトコル変換ＧＷ装置１００が備えられている場合において、ロードバランサ３００は、ＩｏＴ端末１からのアクセスをいずれかのプロトコル変換ＧＷ装置１００へ振り分けることができる。

また、ロードバランサ３００は、ＩｏＴ端末１から送信されたデータに付加されているポート番号に従って、当該データを、プロトコル変換ＧＷ装置１００における対応するブローカへ振り分けることができる。プロトコル変換ＧＷ装置１００の詳細については後述する。

プロトコル変換ＧＷ装置１００に接続される各クラウドは、具体的には、仮想マシンやその上で動作するサービス等である。なお、プロトコル変換ＧＷ装置１００の接続先はクラウドに限定されるわけではなく、物理サーバであってもよい。

管理装置４００は、ユーザ（ユーザ端末）に対してＷｅｂ画面等の設定画面を表示し、設定画面から入力された設定情報（サービスオーダと呼んでもよい）を受信し、保持する。また、管理装置４００は、設定情報に基づいて、装置設定情報を生成し、管理する。装置設定情報は、例えば、アクセス回線と個別識別子とのマッピング情報、個別識別子とクラウドとの接続のための情報とのマッピング等である。

（装置構成例）
次に、プロトコル変換ＧＷ装置１００及び管理装置４００の機能構成と動作の概要を説明する。ここでは動作の概要を説明し、詳細については、シーケンスのところで説明する。

図２に、プロトコル変換ＧＷ装置１００の機能構成例を示す。図２に示すように、プロトコル変換ＧＷ装置１００は、端末接続部１１０、キューイング部１２０、クラウド接続部１３０、設定部１４０を有する。

端末接続部１１０は、ＩｏＴ端末１から送信されたデータを受信する機能部である。なお、本実施の形態において、特に断らない限り、「データ」は、アプリケーションデータを意味する。当該データに、プロトコル対応のヘッダが付されることで、当該データは当該プロトコルで送信される。ヘッダ付きのデータをパケットと呼んでもよい。

図２に示すように、端末接続部１１０は、プロトコル毎の処理部（本実施の形態では「ブローカ」と呼ぶ）を有している。図２の例では、ＩｏＴ端末１からＭＱＴＴで送信されたデータを受信するＭＱＴＴブローカ、ＩｏＴ端末１からＨＴＴＰで送信されたデータを受信するＨＴＴＰブローカ、ＩｏＴ端末１からＴＣＰで送信されたデータを受信するＴＣＰブローカ、ＩｏＴ端末１からＵＤＰで送信されたデータを受信するＵＤＰブローカが示されている。これらのブローカは一例であり、これら以外のプロトコルに対応したブローカが備えられてもよい。

各ブローカは、該当のプロトコルに対応したポート番号が割り当てられたポートを有する。ＩｏＴ端末１からあるプロトコルで送信されるデータのヘッダには、当該プロトコルに対応したポート番号が含まれており、ロードバランサ３００は、当該ポート番号に従って、ＩｏＴ端末１から送信されたデータを、宛先のブローカへ振り分ける。

各ブローカは、受信したデータのヘッダを外し、当該データに個別識別子を付加したデータをキューイング部１２０に渡す。個別識別子を「識別子」と呼んでもよい。

キューイング部１２０は、個別識別子が付されたデータを蓄積するキュー（バッファ）を有する。キューイング部１２０は、１つだけのキューを備えてもよいし、複数のキューを備えてもよい。図２には、複数のキュー１２１、１２２、１２３が備えられる例が示されている。複数のキューを備える場合において、どのデータをどのキューに格納するかについて、つまり、グループ分けについては、例えば、ＩｏＴ端末１が属する企業単位（例えば１企業が１グループ）としてもよいし、企業毎に、接続先クラウド単位としてもよいし、企業と関係なく、接続先クラウド単位としてもよいし、これら以外の単位でグループ分けしてもよい。また、グループ分けについては、例えば、ユーザから管理装置４００のユーザＩＦ４１０に対して指示された内容に沿って設定される。

クラウド接続部１３０は、個別識別子に基づいて、キューに格納されているデータを取得し、メタデータを付加して、暗号化処理を行って、送信データを生成し、送信データを宛先のクラウドへ送信する。クラウド接続部１３０は、クラウドとの間のプロトコル毎の複数の処理部（接続モジュール）を有する。接続モジュールをクラウド接続モジュールと呼んでもよい。

図２の例では、ＭＱＴＴＳでデータを送信するＭＱＴＴＳ接続モジュール、ＨＴＴＰＳでデータを送信するＨＴＴＰＳ接続モジュール等が示されている。これらの接続モジュールは一例であり、これら以外のプロトコルに対応した接続モジュールが備えられてもよい。端末接続部１１０では、アプリケーションデータ部分を抽出しているため、例えば、ＩｏＴ端末１がＭＱＴＴを利用していても、クラウド接続モジュールはＨＴＴＰＳでデータを送信するといったＩｏＴ端末１とクラウドＡ間で異なるプロトコルでのデータ送信が可能である。

設定部１４０は、管理装置４００からの装置設定情報に基づいて、端末接続部１１０、キューイング部１２０、及びクラウド接続部１３０への設定を行う。

端末接続部１１０における各ブローカ、及びクラウド接続部１３０における各接続モジュールはそれぞれ、例えばコンテナにより実装される。コンテナを利用することで、ＣＩ／ＣＤ（継続的インテグレーション／継続的デリバリー）、オートスケールアップ、オートリカバリー等が可能となり、耐障害性を高めることができる。なお、コンテナを使用することは一例であり、コンテナを使用せずに実装することとしてもよい。ただし、コンテナを利用することで、後述する図５に示すようなハードウェア構成を抽象化でき、各モジュールを自社オンプレ開発だけでなくクラウド事業者のＰａａＳ上に展開することも可能となり、最適なプラットフォームで動作させることが可能になる。

図３に、管理装置４００の機能構成例を示す。図３に示すように、管理装置４００は、ユーザＩＦ４１０、情報管理部４２０、記憶部４３０、設定制御部４４０を有する。ユーザＩＦ４１０は、ユーザ（ユーザ端末）に設定画面を表示し、設定画面から入力された設定情報を受信する。また、ユーザＩＦ４１０は設定画面だけでなくアプリケーションから設定を参照/変更できるＡＰＩ(Application Programming Interface)も具備している。情報管理部４２０は、設定情報を記憶部４３０に格納するとともに、設定情報に基づいて、プロトコル変換ＧＷ装置１００への設定に使用する装置設定情報を生成する。設定制御部４４０は、装置設定情報をプロトコル変換ＧＷ装置１００へ送信する。

なお、上記のようにプロトコル変換ＧＷ装置１００へ装置設定情報を送信することで設定を行うこととしてもよいし、プロトコル変換ＧＷ装置１００からのルックアップに応じて、装置設定情報を送信することとしてもよい。

（システムの動作例）
次に、図４のシーケンス図を参照して、システム（特にプロトコル変換ＧＷ装置１００）の動作を詳細に説明する。図４は、ＩｏＴ端末１からクラウドＡにデータを送信する場合のシーケンスを示している。なお、クラウドＡからＩｏＴ端末１への方向の通信に関しては、一旦、図４のシーケンスによりＩｏＴ端末１からクラウドＡへの接続が確立した後に行われる。

Ｓ１０１において、ＩｏＴ端末１からヘッダ付きデータが送信される。このヘッダは、ＩｏＴ端末１が使用するプロトコルに対応したヘッダであり、当該プロトコルに対応したポート番号が含まれている。例えば、当該プロトコルがＨＴＴＰである場合、ＨＴＴＰヘッダとＴＣＰポート番号がヘッダに含まれる。

本シーケンスの例においては、ＩｏＴ端末１は携帯電話網に接続し、携帯電話網を介してアクセス網２００にアクセスする。なお、個々のＩｏＴ端末１が携帯電話網に接続するかわりに、複数のＩｏＴ端末を収容するアクセスポイントが携帯電話網に接続することとしてもよい。携帯電話網に接続するための回線をアクセス回線と呼ぶ。アクセス回線は、携帯電話番号、ＭＳＩＳＤＮ、ＩＭＳＩ等により識別される回線である。

アクセス網２００において、ヘッダ付きデータに、アクセス回線に対応するＩＰアドレスが付与される。どのアクセス回線にどのＩＰアドレスを対応付けるかについては、管理装置４００により管理されている。以降、ヘッダ付きデータにおけるヘッダに、このＩＰアドレスが含まれるものとして説明する。プロトコル変換ＧＷ装置１００の端末接続部１１０は、このＩＰアドレスにより、受信したデータのアクセス回線を識別できる。

なお、アクセス回線を識別するために、ＩＰアドレスを使用することは一例であり、ＩＰアドレスを使用する方法以外の方法でアクセス回線を識別してもよい。

ヘッダ付きデータを受信したロードバランサ３００は、受信したヘッダ付きデータのヘッダに含まれるポート番号に基づいて、ヘッダ付きデータを、ポート番号に対応するブローカへ振り分ける（Ｓ１０３）。

ヘッダ付きデータを受信した端末接続部１１０のブローカは、ヘッダ付きデータからヘッダを外し、データのみを取り出す（Ｓ１０４）。主要なプロトコルに対応した各ブローカのＳ１０４における動作は下記のとおりである。

ＨＴＴＰブローカは、ＩＰ／ＴＣＰ／ＨＴＴＰヘッダを除くデータを取得する。ＭＱＴＴブローカは、ＩＰ／ＴＣＰ／ＭＱＴＴヘッダを除くデータを取得する。ＴＣＰブローカは、ＩＰ／ＴＣＰヘッダを除くデータを取得する。ＵＤＰブローカは、ＩＰ／ＵＤＰヘッダを除くデータを取得する。

ヘッダ付きデータからヘッダを外し、データのみを取り出したブローカは、Ｓ１０５において、データに対して個別識別子を付与する。なお、個別識別子を改めて付与することは必須ではない。例えば、上記のＩＰアドレスを個別識別子として使用してもよい。

個別識別子は、クラウド接続部１３０において、データの宛先クラウド、及び当該宛先クラウドにデータを送信する際のプロトコル、及び送信方法（暗号化方法、メタデータ等）を識別するために使用される識別子である。

個別識別子等は、例えば次のようにしてプロトコル変換ＧＷ装置１００に設定される。例えば、管理装置４００は、ユーザから、ＩｏＴ端末１のアクセス回線情報（例：携帯電話番号等の加入者情報）、当該ＩｏＴ端末１から送出されるデータの宛先クラウドの情報、当該宛先クラウドにデータを送信する際のプロトコルの情報、送信方法の情報（暗号化処理のための証明書情報、メタデータ等）を設定情報として受信する。

管理装置４００は、この設定情報に基づいて、アクセス回線に対応するＩＰアドレスと、それに対応する個別識別子と、当該個別識別子に対応する「宛先クラウド、プロトコル、送信方法」とを装置設定情報として生成し、記憶部４３０に格納するとともに、当該装置設定情報をプロトコル変換ＧＷ装置１００に送信する。

プロトコル変換ＧＷ装置１００の設定部１４０は、ＩＰアドレス（アクセス回線）と個別識別子との対応情報を端末接続部１１０に通知し、端末接続部１１０は、この対応情報を例えばテーブルとして保持する。各ブローカは、ヘッダに含まれているＩＰアドレスと、当該テーブルの情報とから、データに付すべき個別識別子を取得することができる。

なお、これは一例である。上記のようなテーブルを保持することに代えて、各ブローカが、データへの個別識別子の付加を行う際に、管理装置４００へのルックアップ（ＩＰアドレスを用いた情報要求と、対応する個別識別子の取得）を行うこととしてもよい。クラウド接続部１３０の設定については後述する。

図４のＳ１０６において、端末接続部１１０におけるブローカは、個別識別子付きデータをキューイング部１２０に渡す。キューイング部１２０において、個別識別子付きデータがキューに格納される（Ｓ１０７）。キューがグループ分けされている場合、キューイング部１２０は、個別識別子に対応するグループのキューに当該個別識別子付きデータを格納する。

例えば、管理装置４００からの設定により、キューと個別識別子との対応情報がテーブルとしてキューイング部１２０に備えられる。キューイング部１２０は、個別識別子付きデータにおける個別識別子と、当該テーブルの情報とに基づいて、当該個別識別子付きデータを格納すべきキューを決定し、決定したキューに当該個別識別子付きデータを格納する。

なお、本実施の形態において、キューイング部１２０を備えている理由は下記のとおりである。

端末接続部１１０のブローカが、ヘッダを外したデータをそのままクラウド接続部１３０における対応する接続モジュールに渡す構成とする場合、ブローカ単位にクラウド接続モジュールを紐付けることが必要になる。しかし、このような紐付けを行う構成では、ブローカから出力されるデータに対するクラウド接続プロトコルを変更あるいは拡張することが容易ではなくなり、プロトコルの拡張性が低下する。

そこで、本実施の形態では、ブローカからクラウド接続モジュールにデータを渡す前に、一旦データをキューイングすることで、変換前プロトコルと変換後プロトコルの組み合わせの拡張を容易に行うことを可能としている。

キューイング部１２０を備えることで上記の効果を得ることができるが、例えば頻繁な変更や拡張を必要としない用途においては、キューング部１２０を備えない構成とすることも可能である。

Ｓ１０８において、クラウド接続部１３０における接続モジュールは、キューに格納されている個別識別子付きデータにおける個別識別子を参照することにより、自身のプロトコルでの送信に対応する個別識別子が付された個別識別子付きデータをキューから取得する。例えば、ＭＱＴＴＳ接続モジュールは、ＭＱＴＴＳに対応する個別識別子が付された個別識別子付きデータをキューから取得する。

なお、ブローカが受信するデータのプロトコルと、当該ブローカによりキューに格納され、読み出されたデータがクラウド向けに送信される際のプロトコルは同一である必要はない。例えば、ＭＱＴＴでＩｏＴ端末１から送信されたデータが、ＨＴＴＰＳでクラウドＡに送信されてもよい。

Ｓ１０９、Ｓ１１０において、個別識別子に対応する宛先のクラウドに、個別識別子に対応するプロトコル、及び送信方法でデータを送信する。

上記の「送信方法」に対応する処理には、例えば、宛先のクラウド向けインタフェースにおいて必要となる暗号化の処理、メタデータの付与などが含まれる。Ｓ１０９の送信データの作成は、該当プロトコルのヘッダ付与、暗号化処理、メタデータ付与等を行うことを示している。

メタデータとしては、例えば、オリジナルのデータのアクセス回線情報（例：ＭＳＩＳＤＮ、ＩＭＳＩ）、アクセス回線と接続するデバイスの機体情報（例：モバイル機器の場合、ＩＭＥＩ）、ＩＰアドレス等がある。また、メタデータは任意に設定したものを付与することとしてもよい。なお、個別識別子は内部識別子であるためデータから外される。

メタデータ付与の例として次のようなものがある。例えば、ＨＴＴＰＳ接続モジュールは、暗号化処理前のＨＴＴＰヘッダにメタデータを付与する。ＭＱＴＴＳ接続モジュールは、暗号化処理前のＭＱＴＴトピックにメタデータを付与する。Ｓｙｓｌｏｇ接続モジュールは、暗号化処理前のＳｙｓｌｏｇアプリケーションデータにメタデータを付与する。これらの例において、メタデータが付加された後にデータに対して暗号化処理が行われる。

上記のような処理を可能とするための設定処理の例を次に説明する。プロトコル変換ＧＷ装置１００の設定部１４０は、管理装置４００から受信した装置設定情報に含まれる、個別識別情報と「宛先クラウド、プロトコル、送信方法」との対応情報をクラウド接続部１３０に通知し、クラウド接続部１３０は、この対応情報を例えばテーブルとして保持する。なお、メタデータは、「送信方法」の情報に含まれる。

クラウド接続部１３０における各接続モジュールは、キューに格納されている個別識別子付きデータにおける個別識別子と、当該テーブルの情報とから、自身に対応するプロトコルのデータを取得するととともに、取得したデータに対する宛先クラウド及び送信方法を決定することができる。

なお、これは一例である。上記のようなテーブルを保持することに代えて、各接続モジュールが、データのクラウドへの送信を行う際に、管理装置４００へのルックアップ（個別識別子を用いた情報要求と、対応する「宛先クラウド、プロトコル、送信方法」の取得）を行うこととしてもよい。

（ハードウェア構成例）
プロトコル変換ＧＷ装置１００、管理装置４００はいずれも、例えば、コンピュータにプログラムを実行させることにより実現できる。このコンピュータは、物理的なコンピュータであってもよいし、クラウド上の仮想マシンであってもよい。プロトコル変換ＧＷ装置１００、管理装置４００を総称して「装置」と呼ぶ。なお、以下で説明するようなハードウェア構成にてプロトコル変換ＧＷ装置１００や管理装置４００を実現することは一例である。前述したように、本実施の形態では、プロトコル変換ＧＷ装置１００をコンテナアプリケーションとして動作させるため、物理的ハードウェアを抽象化したＰａａＳ上で動作可能である。

すなわち、当該装置は、コンピュータに内蔵されるＣＰＵやメモリ等のハードウェア資源を用いて、当該装置で実施される処理に対応するプログラムを実行することによって実現することが可能である。上記プログラムは、コンピュータが読み取り可能な記録媒体（可搬メモリ等）に記録して、保存したり、配布したりすることが可能である。また、上記プログラムをインターネットや電子メール等、ネットワークを通して提供することも可能である。

図５は、上記コンピュータのハードウェア構成例を示す図である。図５のコンピュータは、それぞれバスＢＳで相互に接続されているドライブ装置１０００、補助記憶装置１００２、メモリ装置１００３、ＣＰＵ１００４、インタフェース装置１００５、表示装置１００６、入力装置１００７、出力装置１００８等を有する。なお、これらのうち、一部の装置を備えないこととしてもよい。例えば、表示を行わない場合、表示装置１００６を備えなくてもよい。

当該コンピュータでの処理を実現するプログラムは、例えば、ＣＤ－ＲＯＭ又はメモリカード等の記録媒体１００１によって提供される。プログラムを記憶した記録媒体１００１がドライブ装置１０００にセットされると、プログラムが記録媒体１００１からドライブ装置１０００を介して補助記憶装置１００２にインストールされる。但し、プログラムのインストールは必ずしも記録媒体１００１より行う必要はなく、ネットワークを介して他のコンピュータよりダウンロードするようにしてもよい。補助記憶装置１００２は、インストールされたプログラムを格納すると共に、必要なファイルやデータ等を格納する。

メモリ装置１００３は、プログラムの起動指示があった場合に、補助記憶装置１００２からプログラムを読み出して格納する。ＣＰＵ１００４は、メモリ装置１００３に格納されたプログラムに従って、当該装置に係る機能を実現する。インタフェース装置１００５は、ネットワークに接続するためのインタフェースとして用いられ、送信部及び受信部として機能する。表示装置１００６はプログラムによるＧＵＩ（Ｇｒａｐｈｉｃａｌ Ｕｓｅｒ Ｉｎｔｅｒｆａｃｅ）等を表示する。入力装置１００７はキーボード及びマウス、ボタン、又はタッチパネル等で構成され、様々な操作指示を入力させるために用いられる。出力装置１００８は演算結果を出力する。

（実施の形態のまとめ）
以下、実施の形態のまとめとして、詳細な課題や効果の例について説明する。実施の形態で説明した技術の効果を説明するために、まず、効果に対応する、従来技術の詳細な課題を説明する。ここでの従来技術は、ＩｏＴ端末側でクラウド接続に必要な実装や設定、暗号化処理等を行う技術であることを想定している。

なお、以下では複数の課題と、それらに対応する複数の効果を詳細に説明しているが、これら複数の効果は本実施の形態に係る技術で得られる効果の例であり、本発明の実施技術において、以下で説明する複数の効果のうちの１つ又は複数の効果が得られないこととしてもよい。

＜ＩｏＴ端末のトラフィック量増加によるコストの肥大化＞
アクセス回線としてモバイル（セルラー）回線を利用する場合に、実際に送りたい生データに対して暗号化処理で付与されるオーバーヘッドによって送信するデータ自体が大きくなる。そのため、モバイル回線が従量課金の場合、利用料／コストが大きくなる。

＜ＩｏＴ端末にて暗号化処理を実現するコスト＞
ＩｏＴ端末に暗号化処理を搭載する場合、下記の対応が不可欠となるため、ＩｏＴ端末そのものが高コスト化する。

（１）暗号化ライブラリーを処理できるＣＰＵ、Ｍｅｍｏｒｙ実装等のためのハードコストが増加する。

（２）暗号化処理を意識してのデバイス実装／アプリケーション開発が必要となる。

＜ＩｏＴ端末へのプロビジョニング作業の肥大化による懸念＞
ＩｏＴ端末内のデータをクラウドに送信する場合に、クラウド設定情報のＩｏＴ端末へのプロビジョニングが必要となるが、ＩｏＴ端末が大量に増えた場合に、膨大な作業量となる。

＜接続先クラウドのインタフェースへの依存＞
クラウドサービスによっては、ＨＴＴＰＳやＭＱＴＴＳなどの暗号化インタフェースしか提供していないなど、ＩｏＴ端末側でアプリケーションの暗号化を求められるものが存在する。一方でクラウドサービスが追加する新たなアプリケーションやプロトコルへの早期対応が求められる。

＜対応プロトコルを拡張する場合の柔軟性の課題＞
送信元となるＩｏＴ端末はデプロイ後の設定変更等が必要であり、ＩｏＴ端末が増大するほど、オペレーションコストが高くなる。一方で、利用するクラウドサービスを変更したい場合や、クラウドのインタフェースとして既存ＩｏＴ端末で利用しているプロトコルとは違うものを使いたいケースにおいては、ＩｏＴ端末側とクラウド側で異なるプロトコル変換機能を都度実装する必要があり、柔軟な拡張が難しい。

＜接続先クラウドの新規機能への対応と商用環境構築に関するコスト＞
クラウドサービスは日々更新され、新たなプロトコル／インタフェースへの早急な対応が求められるため、マイクロサービスとしてのアプリケーション開発から商用へ適用するためのデプロイ作業に関する人的コストの増大が発生する。

＜ベンダーロックイン／最初にデプロイした環境への依存＞
新たなアプリケーションを開発し、サービス提供していくにあたって、最初に構築したハードウェアのスペック等、アプリケーションを構築するオンプレミスやＰａａＳ等のプラットフォーム動作環境から他のプラットフォームへの移設が困難となり、将来初期構築時とは違うプラットフォームのほうがコスト最適な場合でも、既存のデプロイ環境から抜け出せないロックイン状態となるリスクも存在する。

上記のような課題に対応して、既に詳細に説明したように、本実施の形態では、ＩｏＴ端末側にクラウド接続情報や暗号化処理機能を持たせずに、簡易かつセキュアにＩｏＴ端末とクラウド間の通信を行うためのプロトコル変換機能及びクラウドアダプタ機能を、プロトコル変換ＧＷ装置１００により実現している。

（１）プロトコル変換機能
本実施の形態のように、アクセス回線として、モバイル（セルラー）回線を利用する場合には、ＩｏＴ端末（あるいはモデム等のアクセスポイント）とモバイル網間は暗号化されているため、ＩｏＴ端末が送信するアプリケーションのデータ自体はＨＴＴＰＳやＭＱＴＴＳではなく、ＨＴＴＰ、ＭＱＴＴの形でよい。

プロトコル変換機能を構成しているプロトコル変換ＧＷ装置１００におけるブローカがアプリケーションデータのみ抽出して、個別識別子を付与し、キューイング／データストアを経由して、クラウドアダプタ機能としてのクラウド接続部１３０に渡す。

（２）クラウドアダプタ機能
クラウド毎に異なる接続方式、鍵管理、メタデータ付与をプロトコル変換ＧＷ装置１００で代理提供することとしており、これにより、各種クラウドサービスへの柔軟な接続を実現している。

クラウドアダプタ機能により、ＩｏＴ端末追加時に必要となる作業を簡略化することができる。クラウドアダプタ機能（クラウド接続部１３０）において、必要に応じて利用プロトコルのアプリケーションデータフォーマットに合わせたアプリケーションデータの生成を行って、メタデータの付与と暗号化処理を施した後、インターネットあるいは閉域網経由でクラウドのインタフェースに併せて変換したデータを送信する。なお、クラウドアダプタ機能（クラウド接続部１３０）からクラウドへ暗号化したインタフェースでデータ送信を行うことができるので、閉域接続を行わなくてもよい。

（３）コンテナベースのアプリケーション開発
プロトコル変換ＧＷ装置１００を実現するためのソフトウェア（ブローカ、接続モジュール等）については、例えば、ＯＳＳ（Open Source Software）ベースのKubernetes（登録商標）をプラットフォームとしたコンテナを利用する。

上記により、開発環境であるステージング環境と、商用のプロダクション環境をアプリケーションから見て同じプラットフォームで構築し、デプロイすることが可能となる。これにより、ＣＩ／ＣＤを可能とし、かつコンテナオーケストレータの機能を利用することで、オートスケール／オートリカバリーといった自動拡張や自動復旧によるオペレーションの簡素化を併せて実現することが可能となる。なお、管理装置４００がコンテナオーケストレータの機能を有することとしてもよい。

ＯＳＳベースのコンテナ上でアプリケーションを開発することで、オンプレミスやＰａａＳ（Platform as a Service）の動作環境をアプリケーションから隠蔽／抽象化することができ、初期構築時のプラットフォームからの移植性が向上する。

以下、上記のような機能を備えるプロトコル変換ＧＷ装置１００を導入することにより、前述した課題が解決されることについて、前述した課題毎に説明する。

＜ＩｏＴ端末のトラフィック量増加によるコストの肥大化＞
ＩｏＴ端末とクラウドの間にあるプロトコル変換ＧＷ装置１００が暗号化処理を行うため、ＩｏＴ端末側でアプリケーションの暗号化処理が不要となる。これによりＩｏＴ端末から発信されるデータのトラフィック量を軽減できる。

＜ＩｏＴ端末にて暗号化処理を実現するコスト＞
ＩｏＴ端末とクラウドの間にあるプロトコル変換ＧＷ装置１００が暗号化処理を行うため、ＩｏＴ端末側でアプリケーションの暗号化処理が不要となる。そのためＩｏＴ端末のハードコストを削減できる。

＜ＩｏＴ端末へのプロビジョニング作業の肥大化による懸念＞
ＩｏＴ端末からの送信先を一律プロトコル変換ＧＷ装置１００とすることで、ＩｏＴ端末毎に異なる設定値を必要とせず、ＩｏＴ端末へ統一したキッティング情報をセットすればよいため、プロビジョニング作業の簡素化が図れる。ＩｏＴ端末のデータ自体は、例えば端末単位に紐づいたクラウド設定情報を基に目的のクラウドへプロトコル変換ＧＷ装置１００から送信することができる。

＜接続先クラウドのインタフェースへの依存＞
接続先クラウドに依存するインタフェースについての処理は、プロトコル変換ＧＷ装置１００における対応プロトコルの接続モジュールが実行する。そのため、ＩｏＴ端末はＨＴＴＰやＭＱＴＴなどの一般的なプロトコルを利用して、同一の宛先であるプロトコル変換ＧＷ装置１００へデータ送信すればよい。

＜対応プロトコルを拡張する場合の柔軟性の課題＞
プロトコル変換ＧＷ装置１００において、ＩｏＴ端末と通信しアプリケーションデータを抽出するブローカ部分と、データを格納するキューイング部分と、クラウドと通信しクラウドのインタフェースに合わせてデータを生成するクラウド接続モジュールとに分離した構成を採用したことで、ＩｏＴ端末とプロトコル変換ＧＷ装置１００との間で利用するプロトコルと、クラウドとプロトコル変換ＧＷ装置１００との間で利用するプロトコルとを分離できるようになり、ＩｏＴ端末が利用するプロトコルに依らずに、クラウドに対して所望のプロトコルでデータ送信を行うことが可能となる。

＜接続先クラウドの新規機能への対応と商用環境構築に関するコスト＞
プロトコル変換ＧＷ装置１００において使用されるブローカやクラウド接続モジュールは、例えばKubernetes（登録商標）をプラットフォームとしたコンテナとして作成される。よって、ステージング環境とプロダクション環境双方でアプリケーションの動作環境を統一することができ、アプリケーションのデプロイの簡素化を実現することができる。

また、コンテナに付随するオーケストレーション機能を利用することが可能となり、オートスケールやオートリカバリーといったリソース需要の拡大に伴う自動拡張や、コンテナ障害時の自動復旧などと、オペレーションコストの削減とを両立することができる。

＜ベンダーロックイン／最初にデプロイした環境への依存＞
本実施の形態に係るプロトコル変換ＧＷ装置１００において、ＯＳＳベースのコンテナ上のアプリケーションモジュールを使用する場合には、モジュールが動作するプラットフォームの動作環境を隠蔽／抽象化することが可能となり、初期構築するプラットフォームがオンプレミスであっても、ＰａａＳ等のクラウド環境でも、モジュールの移植性が容易になり、コスト最適なプラットフォームでのサービス提供が可能となる。

（付記）
本明細書には、少なくとも下記の各項に記載したゲートウェイ装置、データ送信方法、及びプログラムが記載されている。
（第１項）
端末とクラウドとの間に備えられるゲートウェイ装置であって、
前記端末から送信されたヘッダ付きデータを受信し、当該ヘッダ付きデータのヘッダを外してデータを取得する端末接続部と、
前記データを宛先クラウドへ送信するための処理を前記データに施すことにより送信データを生成し、当該送信データを前記宛先クラウドへ送信するクラウド接続部と
を備えるゲートウェイ装置。
（第２項）
前記端末接続部により取得された前記データを格納するキューイング部を更に備え、
前記クラウド接続部は、前記キューイング部から前記データを取得する
第１項に記載のゲートウェイ装置。
（第３項）
前記端末接続部は、前記データに識別子を付与し、識別子付きデータを前記キューイング部に格納し、前記クラウド接続部は、前記識別子に基づいて、前記送信データを生成する
第２項に記載のゲートウェイ装置。
（第４項）
前記端末接続部は、前記端末と前記ゲートウェイ装置との間でデータの送信に使用されるプロトコル毎にブローカを備え、あるプロトコルで送信されたデータは、当該プロトコルに対応するブローカが受信する
第１項ないし第３項のうちいずれか１項に記載のゲートウェイ装置。
（第５項）
前記クラウド接続部は、前記ゲートウェイ装置と前記クラウドとの間でデータの送信に使用されるプロトコル毎に接続モジュールを備え、あるプロトコルに対応する接続モジュールは、当該プロトコルに対応する送信データを生成する
第１項ないし第４項のうちいずれか１項に記載のゲートウェイ装置。
（第６項）
前記データを宛先クラウドへ送信するための前記処理は、メタデータの付与及び暗号化処理を含む
第１項ないし第５項のうちいずれか１項に記載のゲートウェイ装置。
（第７項）
端末とクラウドとの間に備えられるゲートウェイ装置が実行するデータ送信方法であって、
前記端末から送信されたヘッダ付きデータを受信し、当該ヘッダ付きデータのヘッダを外してデータを取得するステップと、
前記データを宛先クラウドへ送信するための処理を前記データに施すことにより送信データを生成し、当該送信データを前記宛先クラウドへ送信するステップと
を備えるデータ送信方法。
（第８項）
コンピュータを、第１項ないし第６項のうちいずれか１項に記載の前記ゲートウェイ装置における各部として機能させるためのプログラム。

以上、本実施の形態について説明したが、本発明はかかる特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。

１ ＩｏＴ端末
１００ プロトコル変換ＧＷ装置
１１０ 端末接続部
１２０ キューイング部
１２１～１２３ キュー
１３０ クラウド接続部
１４０ 設定部
２００ アクセス網
３００ ロードバランサ
４００ 管理装置
４１０ ユーザＩＦ
４２０ 情報管理部
４３０ 記憶部
４４０ 設定制御部
１０００ ドライブ装置
１００１ 記録媒体
１００２ 補助記憶装置
１００３ メモリ装置
１００４ ＣＰＵ
１００５ インタフェース装置
１００６ 表示装置
１００７ 入力装置
１００８ 出力装置

Claims (10)

1. 端末とクラウドとの間に備えられるゲートウェイ装置であって、
   前記端末から送信されたヘッダ付きデータを受信し、当該ヘッダ付きデータのヘッダを外してデータを取得する端末接続部と、
   前記データを宛先クラウドへ送信するための処理を前記データに施すことにより送信データを生成し、当該送信データを前記宛先クラウドへ送信するクラウド接続部と、
   前記端末接続部により取得された前記データを格納するキューイング部と、を備え、
   前記クラウド接続部は、前記キューイング部から前記データを取得する
   ゲートウェイ装置。
2. 前記端末接続部は、前記データに識別子を付与し、識別子付きデータを前記キューイング部に格納し、前記クラウド接続部は、前記識別子に基づいて、前記送信データを生成する
   請求項１に記載のゲートウェイ装置。
3. 端末とクラウドとの間に備えられるゲートウェイ装置であって、
   前記端末から送信されたヘッダ付きデータを受信し、当該ヘッダ付きデータのヘッダを外してデータを取得する端末接続部と、
   前記データを宛先クラウドへ送信するための処理を前記データに施すことにより送信データを生成し、当該送信データを前記宛先クラウドへ送信するクラウド接続部と、を備え、
   前記端末接続部は、前記端末と前記ゲートウェイ装置との間でデータの送信に使用されるプロトコル毎にブローカを備え、あるプロトコルで送信されたデータは、当該プロトコルに対応するブローカが受信する
   ゲートウェイ装置。
4. 端末とクラウドとの間に備えられるゲートウェイ装置であって、
   前記端末から送信されたヘッダ付きデータを受信し、当該ヘッダ付きデータのヘッダを外してデータを取得する端末接続部と、
   前記データを宛先クラウドへ送信するための処理を前記データに施すことにより送信データを生成し、当該送信データを前記宛先クラウドへ送信するクラウド接続部と、を備え、
   前記クラウド接続部は、前記ゲートウェイ装置と前記クラウドとの間でデータの送信に使用されるプロトコル毎に接続モジュールを備え、あるプロトコルに対応する接続モジュールは、当該プロトコルに対応する送信データを生成する
   ゲートウェイ装置。
5. 端末とクラウドとの間に備えられるゲートウェイ装置であって、
   前記端末から送信されたヘッダ付きデータを受信し、当該ヘッダ付きデータのヘッダを外してデータを取得する端末接続部と、
   前記データを宛先クラウドへ送信するための処理を前記データに施すことにより送信データを生成し、当該送信データを前記宛先クラウドへ送信するクラウド接続部と、を備え、
   前記データを宛先クラウドへ送信するための前記処理は、メタデータの付与及び暗号化処理を含む
   ゲートウェイ装置。
6. 端末とクラウドとの間に備えられるゲートウェイ装置が実行するデータ送信方法であって、
   前記端末から送信されたヘッダ付きデータを受信し、当該ヘッダ付きデータのヘッダを外してデータを取得する端末接続ステップと、
   前記端末接続ステップにより取得された前記データをキューイング部に格納するキューイングステップと、
   前記データを宛先クラウドへ送信するための処理を前記データに施すことにより送信データを生成し、当該送信データを前記宛先クラウドへ送信するクラウド接続ステップと、を備え、
   前記クラウド接続ステップにおいて、前記キューイング部から前記データを取得する
   データ送信方法。
7. 端末とクラウドとの間に備えられるゲートウェイ装置が実行するデータ送信方法であって、
   前記端末から送信されたヘッダ付きデータを受信し、当該ヘッダ付きデータのヘッダを外してデータを取得する端末接続ステップと、
   前記データを宛先クラウドへ送信するための処理を前記データに施すことにより送信データを生成し、当該送信データを前記宛先クラウドへ送信するステップと、を備え、
   前記ゲートウェイ装置は、前記端末と前記ゲートウェイ装置との間でデータの送信に使用されるプロトコル毎にブローカを備え、前記端末接続ステップにおいて、あるプロトコルで送信されたデータは、当該プロトコルに対応するブローカが受信する
   データ送信方法。
8. 端末とクラウドとの間に備えられるゲートウェイ装置が実行するデータ送信方法であって、
   前記端末から送信されたヘッダ付きデータを受信し、当該ヘッダ付きデータのヘッダを外してデータを取得するステップと、
   前記データを宛先クラウドへ送信するための処理を前記データに施すことにより送信データを生成し、当該送信データを前記宛先クラウドへ送信するクラウド接続ステップと、を備え、
   前記ゲートウェイ装置は、前記ゲートウェイ装置と前記クラウドとの間でデータの送信に使用されるプロトコル毎に接続モジュールを備え、前記クラウド接続ステップにおいて、あるプロトコルに対応する接続モジュールは、当該プロトコルに対応する送信データを生成する
   データ送信方法。
9. 端末とクラウドとの間に備えられるゲートウェイ装置が実行するデータ送信方法であって、
   前記端末から送信されたヘッダ付きデータを受信し、当該ヘッダ付きデータのヘッダを外してデータを取得するステップと、
   前記データを宛先クラウドへ送信するための処理を前記データに施すことにより送信データを生成し、当該送信データを前記宛先クラウドへ送信するステップと、を備え
   前記データを宛先クラウドへ送信するための前記処理は、メタデータの付与及び暗号化処理を含む
   データ送信方法。
10. コンピュータを、請求項１ないし５のうちいずれか１項に記載の前記ゲートウェイ装置における各部として機能させるためのプログラム。

Images