WO2020170601A1 - データ圧縮伝送システム、中間サーバ、方法およびプログラム - Google Patents

データ圧縮伝送システム、中間サーバ、方法およびプログラム Download PDF

Info

Publication number
WO2020170601A1
WO2020170601A1 PCT/JP2019/050620 JP2019050620W WO2020170601A1 WO 2020170601 A1 WO2020170601 A1 WO 2020170601A1 JP 2019050620 W JP2019050620 W JP 2019050620W WO 2020170601 A1 WO2020170601 A1 WO 2020170601A1
Authority
WO
WIPO (PCT)
Prior art keywords
data
packet
server
intermediate server
devices
Prior art date
Application number
PCT/JP2019/050620
Other languages
English (en)
French (fr)
Inventor
雅 高木
雅裕 吉田
航哉 森
知洋 井上
田中　裕之
Original Assignee
日本電信電話株式会社
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 日本電信電話株式会社 filed Critical 日本電信電話株式会社
Priority to US17/432,303 priority Critical patent/US11470002B2/en
Priority to JP2021501640A priority patent/JP7025105B2/ja
Publication of WO2020170601A1 publication Critical patent/WO2020170601A1/ja

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/74—Address processing for routing
    • H04L45/745—Address table lookup; Address filtering
    • H04L45/7453—Address table lookup; Address filtering using hashing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/2803—Home automation networks
    • H04L12/283—Processing of data at an internetworking point of a home automation network
    • H04L12/2836—Protocol conversion between an external network and a home network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/565—Conversion or adaptation of application format or content
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/565—Conversion or adaptation of application format or content
    • H04L67/5651—Reducing the amount or size of exchanged application data
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/04—Protocols for data compression, e.g. ROHC
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/22—Parsing or analysis of headers
    • H—ELECTRICITY
    • H03—ELECTRONIC CIRCUITRY
    • H03M—CODING; DECODING; CODE CONVERSION IN GENERAL
    • H03M7/00—Conversion of a code where information is represented by a given sequence or number of digits to a code where the same, similar or subset of information is represented by a different sequence or number of digits
    • H03M7/30—Compression; Expansion; Suppression of unnecessary data, e.g. redundancy reduction
    • H03M7/40—Conversion to or from variable length codes, e.g. Shannon-Fano code, Huffman code, Morse code
    • H03M7/42—Conversion to or from variable length codes, e.g. Shannon-Fano code, Huffman code, Morse code using table look-up for the coding or decoding process, e.g. using read-only memory
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
    • H04L67/125—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks involving control of end-device applications over a network

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Automation & Control Theory (AREA)
  • Computer Security & Cryptography (AREA)
  • Multimedia (AREA)
  • Computing Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

リアルタイム性を損なうことなくデータを圧縮伝送する技術を提供する。複数のデバイスにより生成されたデータを、ネットワークを介して中央サーバで収集するためのデータ圧縮伝送システムにおいて、複数のデバイスと中央サーバとの間に中間サーバを配置し、複数のデバイスの各々が、生成したデータをキャッシュに基づいてハッシュ値に変換するパケットキャッシュ処理部を備え、中間サーバが、キャッシュに基づいてハッシュ値を元データに復元するパケットキャッシュ処理部と、データをまとめてロングパケットとして出力するバッファリング処理部と、データを圧縮して符号化データを生成する圧縮符号化処理部とを備えるようにした。

Description

データ圧縮伝送システム、中間サーバ、方法およびプログラム
　この発明の一態様は、複数のデバイスにより生成されたデータをネットワークを介して中央サーバで収集するためのデータ圧縮伝送システムと、当該システムで使用される中間サーバ、方法、およびプログラムに関する。
　近年のＩｏＴ（Internet of Things）の普及により、製造業、自動車業（自動運転支援）、農業などの分野で、様々なセンサを活用したデータ収集とその解析が進んでいる。その際、センサで測定した周辺状況や、センサを備えたＩｏＴデバイス（以下、単に「デバイス」と言う）自体の状態を把握するには、センサにより得られる情報をリアルタイムに中央サーバ（デバイスと同じ場所に設置された計算機や、インターネット上のクラウドなど）へ伝送して蓄積し、デバイスシャドウを作成する方式が有効となる。
　デバイスシャドウ（デバイスの影像）とは、中央サーバにリアルタイムに伝送され蓄積された、デバイスの状態を表す情報を指す。デバイスシャドウを使用すると、中央サーバの計算機資源を用いて、蓄積された情報を解析することで、デバイスの状態に合わせた柔軟な制御を実現することができる。
　ここで、データを生成するデバイスの種類は多様であり、デバイスの台数も膨大となる。また、センサから得られる情報は、１個あたりのデータのサイズが小さく、高頻度に生成されるという特徴を持つ。そのため、大量のセンサから情報を収集する場合は、通信トラヒックの増加だけでなく、パケット数の増加も問題となり、デバイスから中央サーバまでのネットワークに大きな負荷が発生する。そこで、中央サーバにセンサから得られる情報をリアルタイムに蓄積するために、高頻度に発生するショートパケットの効率的な圧縮技術が必要となる。
　デバイスが高頻度に発生するショートパケットを圧縮する技術として、パケットキャッシュが提案されている（例えば、非特許文献１参照）。パケットキャッシュとは、送受信される通信パケットのペイロードに含まれる時間的な冗長性を削減する方式である。デバイスは、周辺の状況に変化がない場合、同じ値を持つ情報を中央サーバに送信する。この場合、デバイスが生成した複数の通信パケットは、ペイロード部分が同じｂｉｔ列となる。複数の通信パケットに含まれるペイロードが同じｂｉｔ列の場合は、時間的な冗長性が発生したものとみなし、パケットキャッシュを用いてペイロードのサイズを圧縮することができる。
A. Anand et al., "Packet Caches on Routers: The Implications of Universal Redundant Traffic Elimination," in Proc. of ACM SIGCOMM’08, 2008.
　ところが、単にパケットキャッシュを適用するだけでは、リアルタイム性を担保しつつ通信トラヒックとパケット数の効果的な削減を達成することは容易ではなかった。
　この発明は上記事情に着目してなされたもので、その目的とするところは、リアルタイム性を損なうことなく通信トラヒックおよびパケット数を削減する技術を提供することにある。
　上記課題を解決するためにこの発明の第１の態様は、複数のデバイスにより生成されたデータをネットワークを介して中央サーバで収集するためのデータ圧縮伝送システムにあって、上記複数のデバイスと上記中央サーバとの間に配置された中間サーバを具備し、上記複数のデバイスの各々が、生成したデータをキャッシュに基づいてハッシュ値に変換するハッシュ化処理を行うハッシュ化処理部と、上記ハッシュ値を含むパケットを生成して上記中間サーバに送信する第１の送信部とを備え、上記中間サーバが、上記複数のデバイスの各々から送信された上記パケットを受信する受信部と、上記受信したパケットに含まれるハッシュ値を元データに復元するデータ復元部と、上記復元された元データを複数まとめて結合データとして出力するバッファリング処理を行うバッファリング処理部と、上記出力された結合データを圧縮して符号化データを生成する圧縮符号化処理を行う圧縮符号化処理部と、上記符号化データを上記中央サーバに送信する第２の送信部とを備えるようにしたものである。
　この発明の第１の態様によれば、データ伝送圧縮システムにおいて、データを生成し、生成したデータをキャッシュに基づいてハッシュ値に変換し、当該ハッシュ値を含むパケットを生成して送信する複数のデバイスと、当該複数のデバイスにより生成されたデータを収集する中央サーバとの間に、中間サーバが配置される。中間サーバは、複数のデバイスから受信されるパケットに含まれるハッシュ値を元データに復元する処理部と、復元された元データを複数まとめて結合データとして出力する処理部と、出力された結合データを圧縮して符号化データを生成する処理部と、符号化データを中央サーバに送信する送信部とを具備する。
　このように、複数のデバイスにおいてキャッシュに基づくハッシュ化処理を実行することにより、送信するパケットのデータサイズを削減し、デバイスと中間サーバとの間の通信トラヒックを低減することができる。また、複数のデバイスからデータを集約する中間サーバが、キャッシュに基づくハッシュ値の復元と、バッファリングと、圧縮符号化とを行うようにすることにより、中間サーバにおいて短時間で有効なデータサイズにまとめた上でデータ圧縮することが可能となり、中間サーバと中央サーバとの間の通信トラヒックおよびパケット数を低減することができる。したがって、第１および第４の態様では、複数のデバイスと、中央サーバと、それらの間に配置された中間サーバとを備えるデータ圧縮伝送システムにおいて、ＩｏＴデバイスからのデータ収集に求められるリアルタイム性を担保した上で、有効な通信トラヒックおよびパケット数の削減を実現することができる。
　すなわちこの発明によれば、リアルタイム性を損なうことなく通信トラヒックおよびパケット数を削減する技術を提供することができる。
図１は、この発明の一実施形態に係るデータ圧縮伝送システムの全体構成を示す図である。 図２は、図１に示したデータ圧縮伝送システムにおけるデバイスの機能構成を示すブロック図である。 図３は、図１に示したデータ圧縮伝送システムにおける中間サーバのハードウェア構成を示すブロック図である。 図４は、図３に示した中間サーバのソフトウェア構成を示すブロック図である。 図５は、図１に示したデータ圧縮伝送システムにおける中央サーバの機能構成を示すブロック図である。 図６は、図１に示したデータ圧縮伝送システムにおける制御サーバの機能構成を示すブロック図である。 図７Ａは、この発明の一実施形態に係るデータ圧縮伝送システム全体の機能構成とデータフローを示す図である。 図７Ｂは、図７Ａに示したデバイスに関するデータフローの詳細を示す図である。 図７Ｃは、図７Ａに示した中間サーバに関するデータフローの詳細を示す図である。 図７Ｄは、図７Ａに示した中央サーバに関するデータフローの詳細を示す図である。 図８は、パケットキャッシュの処理の流れを示す図である。 図９は、図６に示した制御サーバによる処理手順と処理内容を示すフローチャートである。
　以下、図面を参照して、この発明に係わる実施形態について説明する。
　上述のように、従来のシステムでは、リアルタイム性を担保しつつ通信トラヒックとパケット数の効果的な削減を達成することは困難であった。デバイスから高頻度に発生するショートパケットを圧縮するには、例えば、以下の３つの課題が想定される。
　［課題１］
　パケットキャッシュを適用することでショートパケットを圧縮できるため、通信トラヒックを削減することはできる。しかし、通信パケット数を削減することはできない。通信パケット数が多い場合は、優れたパケット処理性能を持つ高価な通信機器を、中央サーバの通信機器として設置しなければならないため、データを収集する際のコストが増加してしまう。また、ショートパケットに含まれるＴＣＰ／ＩＰやイーサネット（登録商標）などのヘッダのサイズも無視できなくなり、全体的な通信効率も低下してしまう。通信トラヒックと通信パケット数を同時に削減する手法が必要となる。
　［課題２］
　デバイス上でデータをバッファリングすることで、通信パケット数を削減することができる。通常、イーサネットでは１，５００Ｂｙｔｅまでのデータを１つのパケットに格納可能である。そこで、デバイス上でデータを１，５００Ｂｙｔｅ溜まるまでバッファリングして送信すれば、通信パケット数を削減することができる。しかし、デバイスが生成するデータをバッファリングする場合、データが十分に溜まるまで待つための遅延時間が発生する。リアルタイム性が重要なユースケースでは、高頻度に発生するデータをショートパケットのまま送信しなければならない。通信トラヒックと通信パケット数を同時に削減するだけでなく、リアルタイム性を損なわない方式が必要となる。
　［課題３］
　ＩｏＴなどの分野ではデバイスの台数は数億台規模となるため、デバイスと中央サーバの間に多数のネットワーク接続（コネクション）が生成される。中央サーバに多数のネットワーク接続が生成されると、Ｃ１０Ｍなどの接続問題が発生する。Ｃ１０Ｍとは、ハードウェアの性能上は問題がなくても、接続するクライアントの数が多くなるとサーバの処理負荷が処理能力を超える問題のことを言う。数百万を超えるコネクションに対応するプロセスやスレッドを生成すると、サーバのメモリ上にプロセスやスレッドの管理領域が確保され、使われるメモリサイズも大きくなり、接続を維持するためのコストが増加してしまう。多数のコネクション数が引き起こす問題を回避するために、中央サーバのネットワーク接続数を削減する必要がある。
　実施形態は、上記［課題１］～［課題３］に鑑み、リアルタイム性を損なうことなく通信トラヒックおよびパケット数を削減する技術を提供することを目的とする。
　［一実施形態］
　（構成）
　（１）システム
　図１は、この発明の一実施形態に係るデータ圧縮伝送システム１の全体構成の一例を示す図である。
　このシステム１は、無線アクセス網ＲＡＮを介して基地局ＢＳとの間で通信可能な複数のデバイス３０１，３０２，・・・３０ｎ（以下、まとめて「デバイス３０」と言う）と、基地局ＢＳとの間で有線アクセス網ＡＮＷ、有線コア網ＣＮＷおよびインターネット等を介して通信可能な中央サーバ２０とを備えている。基地局ＢＳには、有線アクセス網ＡＮＷを介して中間サーバ１０および制御サーバ４０が通信可能に接続される。なお、中央サーバ２０には、同時に複数の基地局ＢＳおよび中間サーバ１０が接続可能であるが、簡単のため１つの基地局ＢＳおよび１つの中間サーバ１０のみを図示している。
　無線アクセス網ＲＡＮは、例えば、３Ｇまたは４Ｇ等の規格の下で動作する携帯電話網であるが、ＬＡＮ（Local Area Network）に置き換えることも可能である。有線アクセス網ＡＮＷおよび有線コア網ＣＮＷは、例えば光ファイバを用いた有線網が使用される。ただし、図１に示した接続形式に限られるものではなく、任意の無線ネットワークおよび有線ネットワークを採用することができる。以下では、上記通信網を単にネットワークＮＷとも言う。
　デバイス３０は、例えば、心電計や血圧計などの複数のセンサを備えたウェアラブルデバイスであり、センサから出力された信号に基づいてセンシングデータを生成し、近距離無線通信機能またはインターネット通信機能によりデータを送信することができる。なお、デバイス３０１，３０２，・・・３０ｎは、それぞれ異なる情報を計測するセンサからの異なるセンシングデータを生成することが可能である。
　中央サーバ２０は、例えば、機器メーカーやサービス事業者により管理運営される、Ｗｅｂ上またはクラウド上のサーバコンピュータにより構成され、デバイス３０によって生成されたセンシングデータを収集し蓄積して所定の処理を行う。
　中間サーバ１０は、例えば、サーバコンピュータやパーソナルコンピュータにより構成され、デバイス３０と中央サーバ２０との間に配置される。一実施形態では、中間サーバ１０は、基地局ＢＳに通信可能に接続され、デバイス３０の各々から送信されたデータを受信し、圧縮処理を行ったのち、中央サーバ２０に送信する働きをする。
　制御サーバ４０は、例えば、サーバコンピュータやパーソナルコンピュータにより構成され、デバイス３０、中央サーバ２０および中間サーバ１０のＣＰＵやメモリの状態を監視し、各計算機の負荷状況に応じて各計算機の処理を制御する働きをする。制御サーバ４０は、ＬＡＮなどの有線アクセス網ＡＮＷを介して中間サーバ１０と通信可能に接続される。制御サーバ４０は、中間サーバ１０を介して複数のデバイス３０および中央サーバ２０との間で情報のやり取りを行うように構成されてもよいし、複数のデバイス３０および中央サーバ２０と直接通信可能なように構成されてもよい。
　各計算機の構成について、以下でさらに説明する。
　（２）デバイス
　図２は、図１に示した複数のデバイス３０１，３０２，・・・３０ｎを代表するデバイス３０のハードウェア構成にソフトウェア構成を追加して示した例を示すブロック図である。
　デバイス３０は、ハードウェアとして、例えば、ハードウェアプロセッサと、プログラムメモリと、データメモリ３３０と、通信インタフェース３１０と、センサインタフェース３１１と、入出力インタフェース３１２と、制御ユニット３２０とを備えている。
　入出力インタフェース３１２には、デバイス３０に付設される入力デバイス７１および出力デバイス７２が接続される。入出力インタフェース３１２は、キーボードやタッチパネル等の入力デバイス７１を通じてユーザが入力した操作情報を取り込むとともに、表示データを液晶または有機ＥＬ（Electro Luminescence）等を用いた出力デバイス７２へ出力して表示させる処理を行う。なお、入力デバイス７１および出力デバイス７２はデバイス３０に内蔵されたデバイスを使用してもよく、またネットワークを介して通信可能な他の情報端末の入力デバイスおよび表示デバイスを使用してもよい。
　センサインタフェース３１１は、センサ群６０を構成する各センサ６１～６ｋにより測定されたセンシング信号を受信し、受信したセンシング信号をＡ／Ｄ変換器によりディジタル信号に変換する。
　通信インタフェース３１０は、例えば１つ以上の有線または無線の通信インタフェースを含んでおり、制御ユニット３２０の制御の下、ネットワークＮＷを介して、基地局ＢＳやユーザが所持する携帯通信端末との間で情報の送受信を可能にする。有線インタフェースとしては、例えば有線ＬＡＮが使用され、また無線インタフェースとしては、例えば無線ＬＡＮやＢｌｕｅｔｏｏｔｈ（登録商標）などの小電力無線データ通信規格を採用したインタフェースが使用される。
　データメモリ３３０は、記憶媒体として、例えば、ＨＤＤ（Hard Disk Drive）またはＳＳＤ（Solid State Drive）等の随時書込みおよび読出しが可能な不揮発性メモリと、ＲＡＭ（Random Access Memory）等の揮発性メモリとを組み合わせて使用したもので、この実施形態を実現するために必要な記憶領域として、センシングデータ記憶部３３１と、対応表記憶部３３２とを備えている。
　センシングデータ記憶部３３１は、生成されたセンシングデータを記憶するために用いられる。
　対応表記憶部３３２は、元のデータと、当該データに所定のハッシュ関数を適用して得られるハッシュ値との対応関係を表す対応表を記憶するために用いられる。対応表記憶部３３２はまた、上記所定のハッシュ関数も記憶する。
　ただし、記憶部３３１～３３２は必須の構成ではなく、例えば、ＵＳＢメモリなどの外付け記憶媒体や、クラウドに配置されたデータベースサーバ等の記憶装置に設けられたものであってもよい。
　制御ユニット３２０は、ＣＰＵ等のハードウェアプロセッサと、プログラムメモリと、処理中のデータを一時的に保存する作業用メモリとにより構成され、ソフトウェアによる処理機能部として、センシングデータ生成部３２１と、パケットキャッシュとしてのハッシュ化処理部３２２と、パケット出力部３２３と、送信制御部３２４とを備えている。これらの処理機能部は、いずれもプログラムメモリに格納されたアプリケーションプログラムを上記ハードウェアプロセッサに実行させることにより実現される。制御ユニット３２０は、また、ＡＳＩＣ（Application Specific Integrated Circuit）やＦＰＧＡ（field-programmable gate array）などの集積回路を含む、他の多様な形式で実現されてもよい。
　センシングデータ生成部３２１は、センサインタフェース３１１を介してディジタル信号を取得し、所定のサンプリングレートでサンプリングしてセンシングデータを生成し、生成されたセンシングデータをセンシングデータ記憶部３３１に格納する処理を行う。
　ハッシュ化処理部３２２は、センシングデータ記憶部３３１から送信対象のデータを読み出し、キャッシュに基づいてハッシュ化するハッシュ化処理を行う。詳細には、ハッシュ化処理部３２２は、送信対象のデータが対応表記憶部３３２に格納された対応表に含まれるか否かを判定し、データが対応表に含まれる場合、当該データを対応表に基づいてハッシュ値に変換して、パケット出力部３２３に渡す。一方、送信対象のデータが対応表に含まれない場合、ハッシュ化処理部３２２は、例えば、対応表記憶部３３２に格納されたハッシュ関数を読み出し、データにハッシュ関数を適用してハッシュ値を得て、当該データとハッシュ値との対応関係を対応表に追加（更新）するとともに、ハッシュ化していない元のデータをパケット出力部３２３に渡す。
　パケット出力部３２３は、ハッシュ化処理部３２２から受け取ったハッシュ化されていない元データまたはハッシュ値に変換されたデータに対し、ヘッダ情報を付加して、データパケットとして、送信制御部３２４に渡す処理を行う。
　送信制御部３２４は、受け取ったデータパケットを通信インタフェース３１０によりネットワークＮＷを介して中間サーバ１０に送信する処理を行う。
　（３）中間サーバ
　（３－１）ハードウェア構成
　図３は、中間サーバ１０のハードウェア構成の一例を示すブロック図である。
　中間サーバ１０は、ハードウェアとして、例えば、ＣＰＵ（Central Processing Unit）やＭＰＵ（Micro Processing Unit）等のハードウェアプロセッサ１２Ａを有する。そして、このハードウェアプロセッサ１２Ａに対し、プログラムメモリ１２Ｂ、データメモリ１３、通信インタフェース１１を、バス５０を介して接続したものとなっている。
　通信インタフェース１１は、例えば１つ以上の有線または無線の通信インタフェースを含んでおり、ネットワークＮＷを介して基地局ＢＳまたはデバイス３０や中央サーバ２０との間で情報の送受信を可能にする。有線インタフェースとしては例えば有線ＬＡＮが使用され、無線インタフェースとしては例えば無線ＬＡＮが使用される。
　プログラムメモリ１２Ｂは、記憶媒体として、例えばＨＤＤ（Hard Disk Drive）やＳＳＤ（Solid State Drive）等の随時書込みおよび読出しが可能な不揮発性メモリと、ＲＯＭ等の不揮発性メモリとを組み合わせて使用したもので、一実施形態に係る各種制御処理を実行するために必要なプログラムが格納されている。
　データメモリ１３は、記憶媒体として、例えばＨＤＤまたはＳＳＤ等の随時書込みおよび読出しが可能な不揮発性メモリと、ＲＡＭ等の揮発性メモリとを組み合わせて使用したもので、処理の過程で取得および作成された各種データを記憶するために用いられる。
　（３－２）ソフトウェア構成
　図４は、この発明の一実施形態に係る中間サーバ１０のソフトウェア構成を、図３に示したハードウェア構成と関連付けて示したブロック図である。
　データメモリ１３の記憶領域には、データパケット記憶部１３１と、対応表記憶部１３２とが設けられている。
　データパケット記憶部１３１は、取得されたデータパケットを記憶するために用いられる。
　対応表記憶部１３２は、元のデータと、当該データに所定のハッシュ関数を適用して得られるハッシュ値との対応関係を表す対応表を記憶するために用いられる。対応表記憶部１３２はまた、上記所定のハッシュ関数も記憶する。
　ただし、記憶部１３１～１３２は必須の構成ではなく、例えば、ＵＳＢメモリなどの外付け記憶媒体や、クラウドに配置されたデータベースサーバ等の記憶装置に設けられたものであってもよい。
　制御ユニット１２は、上記ハードウェアプロセッサ１２Ａと、上記プログラムメモリ１２Ｂとから構成され、ソフトウェアによる処理機能部として、データパケット取得部１２１と、パケットキャッシュとしてのデータ復元部１２２と、バッファリング処理部１２３と、圧縮符号化処理部としてのパケット符号化部１２４と、送信制御部１２５とを備えている。これらの処理機能部は、いずれもプログラムメモリ１２Ｂに格納されたプログラムを、上記ハードウェアプロセッサ１２Ａに実行させることにより実現される。制御ユニット１２はまた、ＡＳＩＣやＦＰＧＡなどの集積回路を含む、他の多様な形式で実現されてもよい。
　データパケット取得部１２１は、受信部として、通信インタフェース１１を介してデバイス３０から送信されたデータパケットを取得し、取得したデータパケットをデータパケット記憶部１３１に格納する処理を行う。
　データ復元部１２２は、データパケット記憶部１３１からデータパケットを順次読み出し、ヘッダ情報を削除し、キャッシュに基づいて元のデータに復元する処理を行う。詳細には、データ復元部１２２は、対象のデータパケットからヘッダ情報を削除した残りのデータ（キー）が、対応表記憶部１３２に格納された対応表に含まれるか否かを判定する。データ復元部１２２は、当該キーが対応表に含まれる場合、対応表に基づいてハッシュ値を元のデータに変換して、バッファリング処理部１２３に渡す。一方、データが対応表に含まれない場合、データ復元部１２２は、例えば、当該データをバッファリング処理部１２３に渡すとともに、対応表記憶部１３２に格納されたハッシュ関数を読み出し、データにハッシュ関数を適用してハッシュ値を得て、当該データとハッシュ値との対応関係を対応表に追加（更新）する。
　バッファリング処理部１２３は、データ復元部１２２により復元された元データを複数まとめて、結合データとして出力する処理を行う。詳細には、バッファリング処理部１２３は、データ復元部１２２から受け取ったデータを一定のサイズになるまでバッファリングし、ロングパケットを生成して、パケット符号化部１２４に渡す処理を行う。バッファリング処理部１２３は、例えば、１つのイーサネットフレームに格納可能となるように、データのサイズが１，４４０Ｂｙｔｅになるまでバッファリングを実施する。
　パケット符号化部１２４は、圧縮符号化処理部として、バッファリング処理部１２３から受け取ったロングパケットに対し、ｇｚｉｐなどの情報源符号化アルゴリズムを用いた圧縮方式を適用して圧縮し、符号化データを生成して、送信制御部１２５に渡す処理を行う。
　送信制御部１２５は、送信部として、パケット符号化部１２４から受け取った符号化データを、通信インタフェース１１によりネットワークＮＷを介して中央サーバ２０に送信する処理を行う。
　（４）中央サーバ
　図５は、この発明の一実施形態に係る中央サーバ２０のハードウェア構成にソフトウェア構成を追加して示した例を示すブロック図である。
　中央サーバ２０は、ハードウェアとして、例えば、ハードウェアプロセッサと、プログラムメモリと、データメモリ２３０と、通信インタフェース２１０とを備えている。
　通信インタフェース２１０は、例えば有線または無線インタフェースを有しており、制御ユニット２２０の制御の下、ネットワークＮＷを介して外部機器との間で情報の送受信を可能にする。有線インタフェースとしては、例えば有線ＬＡＮが使用され、また無線インタフェースとしては、例えば無線ＬＡＮが使用される。
　データメモリ２３０は、記憶媒体として、例えばＨＤＤまたはＳＳＤ等の随時書込および読み出しが可能な不揮発性メモリとＲＡＭ等の揮発性メモリを用いたもので、この実施形態を実現するために必要な記憶領域として、符号化データ記憶部２３１と、元データ記憶部２３２とを備えている。
　符号化データ記憶部２３１は、中間サーバ１０から受信した符号化データを記憶するために使用される。
　元データ記憶部２３２は、復元された元のデータを記憶するために使用される。
　ただし、記憶部２３１～２３２は必須の構成ではなく、例えば、ＵＳＢメモリなどの外付け記憶媒体や、クラウドに配置されたデータベースサーバ等の記憶装置に設けられたものであってもよい。
　制御ユニット２２０は、ＣＰＵ等のハードウェアプロセッサと、プログラムメモリと、処理中のデータを一時的に保存する作業用メモリとにより構成され、ソフトウェアによる処理機能部として、符号化データ取得部２２１と、パケット復号部２２２と、元データ抽出部２２３と、出力制御部２２４とを備えている。これらの処理機能部は、いずれもプログラムメモリに格納されたアプリケーションプログラムを上記ハードウェアプロセッサに実行させることにより実現される。制御ユニット２２０は、また、ＡＳＩＣやＦＰＧＡなどの集積回路を含む、他の多様な形式で実現されてもよい。
　符号化データ取得部２２１は、中間サーバ１０から送信された符号化データを取得し、符号化データ記憶部２３１に格納する処理を行う。
　パケット復号部２２２は、符号化データ記憶部２３１に格納された符号化データを順次読出し、復号（解凍）して符号化前のロングパケットを生成し、元データ抽出部２２３に渡す処理を行う。
　元データ抽出部２２３は、生成されたロングパケットから元データを抽出し、元データ記憶部２３２に格納する処理を行う。
　出力制御部２２４は、オペレータ等の要請に応答して元データ記憶部２３２に蓄積されたデータを出力する処理を行う。
　（５）制御サーバ
　図６は、この発明の一実施形態に係る制御サーバ４０のハードウェア構成にソフトウェア構成を追加して示した例を示すブロック図である。
　制御サーバ４０は、ハードウェアとして、例えば、ハードウェアプロセッサと、プログラムメモリと、データメモリ４３０と、通信インタフェース４１０とを備えている。
　通信インタフェース４１０は、例えば有線または無線インタフェースを有しており、制御ユニット４２０の制御の下、ネットワークＮＷを介して外部機器との間で情報の送受信を可能にする。有線インタフェースとしては、例えば有線ＬＡＮが使用され、また無線インタフェースとしては、例えば無線ＬＡＮが使用される。
　データメモリ４３０は、記憶媒体として、例えばＨＤＤまたはＳＳＤ等の随時書込および読み出しが可能な不揮発性メモリとＲＡＭ等の揮発性メモリを用いたもので、この実施形態を実現するために必要な記憶領域として、負荷状態記憶部４３１と、制御信号記憶部４３２とを備えている。
　負荷状態記憶部４３１は、取得された各計算機の負荷状態を記憶するために使用される。
　制御信号記憶部４３２は、生成された制御信号を記憶するために使用される。
　ただし、記憶部４３１～４３２は必須の構成ではなく、例えば、ＵＳＢメモリなどの外付け記憶媒体や、クラウドに配置されたデータベースサーバ等の記憶装置に設けられたものであってもよい。
　制御ユニット４２０は、ＣＰＵ等のハードウェアプロセッサと、プログラムメモリと、処理中のデータを一時的に保存する作業用メモリとにより構成され、ソフトウェアによる処理機能部として、負荷状態取得部４２１と、パケットキャッシュ制御部４２２と、バッファリング制御部４２３と、パケット符号化制御部４２４と、制御信号出力制御部４２５とを備えている。これらの処理機能部は、いずれもプログラムメモリに格納されたアプリケーションプログラムを上記ハードウェアプロセッサに実行させることにより実現される。制御ユニット４２０は、また、ＡＳＩＣやＦＰＧＡなどの集積回路を含む、他の多様な形式で実現されてもよい。
　負荷状態取得部４２１は、監視対象である各計算機（デバイス３０、中央サーバ２０または中間サーバ１０）の負荷状態を取得して負荷状態記憶部４３１に格納する処理を行う。
　パケットキャッシュ制御部４２２、バッファリング制御部４２３、およびパケット符号化制御部４２４は、それぞれ、デバイス３０、中間サーバ１０および中央サーバ２０のＣＰＵおよびメモリの状態を監視し、各計算機の負荷状況に応じて、各計算機におけるキャッシュ、バッファリング、パケット符号化を行うかどうかを判断する機能を有する。
　パケットキャッシュ制御部４２２は、負荷状態記憶部４３１から情報を読み出し、パケットキャッシュによるデータ圧縮を実施すべきか否かを判定し、実施するか否かを切り替える処理を行う。パケットキャッシュによる圧縮には計算機資源（特にＣＰＵとメモリ）を利用するため、計算機資源に余剰がない状態のときに、計算機が過負荷状態となる。そこで、パケットキャッシュ制御部４２２は、デバイス３０、中間サーバ１０、中央サーバ２０等の計算機資源に余剰が無い場合は、パケットキャッシュを実施せずに非圧縮の状態でデータを次のサーバに転送するように制御する。
　バッファリング制御部４２３は、負荷状態記憶部４３１から情報を読み出し、バッファリングを実施すべきか否かを判定し、実施するか否かを切り替える処理を行う。バッファリングには計算機資源（特にメモリ）を利用するため、計算機資源に余剰がない状態のときに、計算機が過負荷状態となる。そこで、バッファリング制御部４２３は、デバイス３０、中間サーバ１０、中央サーバ２０等の計算機資源に余剰が無い場合は、データをバッファリングせずに小さいサイズのデータを次のサーバに転送するように制御する。
　パケット符号化制御部４２４は、負荷状態記憶部４３１から情報を読み出し、パケット符号化によるデータ圧縮を実施すべきか否かを判定し、実施するか否かを切り替える処理を行う。パケット符号化による圧縮には計算機資源（特にＣＰＵとメモリ）を利用するため、計算機資源に余剰がない状態のときに、計算機が過負荷状態となる。そこで、パケット符号化制御部４２４は、デバイス３０、中間サーバ１０、中央サーバ２０等の計算機資源に余剰が無い場合は、パケット符号化を実施せずに非圧縮の状態でデータを次のサーバに転送するように制御する。
　制御信号出力制御部４２５は、パケットキャッシュ制御部４２２、バッファリング制御部４２３、およびパケット符号化制御部４２４から上記判定の結果を受け取り、各処理の実行または停止を制御するための制御信号を生成し、制御信号記憶部４３２に履歴情報として格納するとともに、通信インタフェース４１０を介して出力し、各計算機に送信する処理を行う。
　（動作）
　（１）システム
　次に、以上のように構成されたデータ圧縮伝送システム１によるデータ圧縮伝送のための処理動作の概要を説明する。図７Ａ～７Ｄはデータ圧縮伝送処理の流れとその内容およびデータフローを示す図である。
　図７Ａは、データ圧縮伝送システム１全体による処理の流れの概要を示す。
　図７Ａでは、デバイス３０から中間サーバ１０までの区間は無線アクセス網、中間サーバ１０から中央サーバ２０までの区間はインターネットである。ただし、図７Ａの構成は一例にすぎず、一実施形態に係る発明を適用できるネットワーク形態は、無線ネットワークとインターネットに限られない（ＷｉＦｉ、ミリ波、光回線等の有線ネットワークに対しても同様に適用可能である）。
　上述したように、一実施形態に係るデータ圧縮伝送システム１は、複数のデバイス３０（３０１，３０２，・・・）と、中間サーバ１０と、中央サーバ２０と、制御サーバ４０とを備えている。またデータ圧縮伝送システム１は、各デバイス３０に、パケットキャッシュ機能としてのハッシュ化処理部３２２１，３２２２，・・・を備え、中間サーバ１０に、パケットキャッシュ機能としてのデータ復元部１２２と、バッファリング処理部１２３と、パケット符号化部１２４とを備え、中央サーバ２０にパケット復号部２２２を備え、制御サーバ４０に、パケットキャッシュ制御部４２２と、バッファリング制御部４２３と、パケット符号化制御部４２４とを備える。
　パケットキャッシュは、送受信されるデータをキャッシュし、同じデータが何回も送信される場合は、サイズが小さいハッシュに変換して送信することで、通信トラヒックを削減する機能を持つ。デバイス３０が中間サーバ１０に対して同じデータを何回も繰り返して送信する場合は、データに時間的な冗長性が発生するため、パケットキャッシュを用いて通信トラヒックを削減することができる。図７Ａの例では、パケットキャッシュにより、デバイス３０から中間サーバ１０までの区間である無線アクセス網のトラヒックを削減できることになる。
　ここで、パケットキャッシュを実行するには、あらかじめ送受信する装置（例えば、第１のデバイス３０１と中間サーバ１０）で共通の関数（ハッシュ関数）を持っておく必要がある。そして、初めてのデータが送信されたときには装置（デバイス３０１と中間サーバ１０）で同じハッシュ関数に基づいて当該データに対応するハッシュ値を求め、ハッシュ値とデータの対応表を各装置内に作成する。次に同じデータが来た場合、送信装置（デバイス３０１）では対応表に基づいてハッシュ値に変換され、受信装置（中間サーバ１０）では同じく対応表に基づいて元のデータに復元される。なお、一般に、ＩｏＴデバイス３０では、保管できる対応表の容量が多くないため、パケットキャッシュにより圧縮できるものは直近のデータのことが多くなる。
　次に、バッファリングは、送受信されるデータをバッファリングし、サイズが小さいデータをサイズの大きいデータに変換することで、複数の小さなデータを１つの大きなデータにまとめることができ、通信パケット数を削減する機能を持つ。デバイス３０が中央サーバ２０に対してショートパケットを何回も送信する場合には、ショートパケットをバッファリングしてロングパケットに変換することで、パケット数を削減することができる。
　パケット符号化は、ｇｚｉｐなどの情報源符号化アルゴリズムを用いた圧縮方式により、大きいサイズのデータを圧縮する機能を持つ。一般に、大きいサイズのデータについては、パケットキャッシュよりもパケット符号化の方が圧縮効率は高い。パケットキャッシュは、同じデータが過去に繰り返し送信されたか、という時間的な冗長性を圧縮する方式である。小さいサイズのデータであれば、同じデータが繰り返し送信される可能性が高くなるが、大きいサイズのデータの場合は、データが１Ｂｙｔｅでも異なると違うデータとして扱われるため、パケットキャッシュを用いた圧縮は有効に機能しない。そこで、バッファリングによってサイズが大きくなったデータに対して、パケット符号化による圧縮を施すことで、全体として効率的な圧縮を実現することができる。
　制御サーバ４０の各制御部４２２～４２４は、それぞれ、デバイス３０、中間サーバ１０および中央サーバ２０のＣＰＵおよびメモリの状態を監視し、各計算機の負荷状況に応じて、各計算機におけるキャッシュ、バッファリング、パケット符号化を行うかどうかを判断し、制御する機能を持つ。
　ただし、制御サーバ４０はデータ圧縮伝送システム１に必須の構成ではない。制御サーバ４０が備える、負荷状態取得部４２１、パケットキャッシュ制御部４２２、バッファリング制御部４２３、パケット符号化制御部４２４および制御信号出力制御部４２５は、データ圧縮伝送システム１内の任意の場所に配置されてよい。例えば、パケットキャッシュ制御部４２２、バッファリング制御部４２３およびパケット符号化制御部４２４のすべてが、中間サーバ１０の制御ユニット１２内に配置されてもよく、中央サーバ２０の制御ユニット２２０内に配置されてもよく、あるいはそれぞれ別個独立した装置として構成されてもよい。
　上述したように、中間サーバ１０は、デバイス３０と中央サーバ２０を接続する通信路上に設置されるサーバである。中間サーバ１０は、計算機機能を有し、パケットキャッシュとしてのデータ復元部１２２、バッファリング処理部１２３、パケット符号化部１２４に加え、パケットキャッシュ制御部４２２、バッファリング制御部４２３、パケット符号化制御部４２４などを動作させることもできる。中央サーバ２０の台数と比較して、中間サーバ１０の台数を増やすことができる。例えば、中間サーバ１０をモバイル網の無線基地局ＢＳに設置すると、日本全国で数十万台の中間サーバ１０を設置することができる。また、中間サーバ１０をデバイス３０の近傍に設置することで、数百万台の中間サーバ１０を設置することができる。
　なお、第１のデバイス３０１と第２のデバイス３０２は、それぞれ異なるパケットキャッシュを備えることができる。第１のデバイス３０１と第２のデバイス３０２が異なるデータを生成する場合、デバイス３０１と中間サーバ１０との間の通信トラヒックの削減率と、デバイス３０２と中間サーバ１０との間の通信トラヒックの削減率は異なるものとなる。
　以下で、システム１の動作について、デバイス３０に関する動作１－１、中間サーバ１０に関する動作１－２、および中央サーバ２０に関する動作１－３についてさらに詳細に説明する。
　（２）デバイス
　図７Ｂは、デバイス３０に関する動作１－１を、特に第１のデバイス３０１に関して示す図である。
　まずステップＳ１０１において、デバイス３０１は、センシングデータ生成部３２１の制御の下、センサ群６０を構成する各センサ６１～６ｋからセンサインタフェース３１１を介してセンシング信号を取り込み、所定のサンプリングレートでサンプリングして、１６Ｂｙｔｅの元データＯＤ１を生成する。なお、この１６Ｂｙｔｅというデータサイズは一例にすぎず、この実施形態を適用できるデータのサイズは１６Ｂｙｔｅに限定されない。
　次いで、デバイス３０１は、ハッシュ化処理部３２２の制御の下、生成した元データＯＤ１に対し、パケットキャッシュを適用する。
　図８は、パケットキャッシュの仕組みについて説明する処理フロー図である。　
　ここでは、帯域が太いネットワークＢＮ１を流れるトラヒックＴＦ１が、第１の装置ＰＣ１と第２の装置ＰＣ２との間の帯域が細いネットワークＮＮを経由して、再び帯域が太いネットワークＢＮ２を流れる例を考える。各々がパケットキャッシュ機能を有する第１の装置ＰＣ１と第２の装置ＰＣ２が、ネットワークの両端に設置されている。第１の装置ＰＣ１および第２の装置ＰＣ２の各々には、あらかじめ「キャッシュＡ」と「キャッシュＢ」が保存されている。
　第１の装置ＰＣ１と第２の装置ＰＣ２の２つの装置を経由するトラヒック（元のトラヒック）ＴＦ１に、「キャッシュＡ」と同一のデータが含まれる場合、２つの装置間で元のトラヒックＴＦ１をそのまま送受信するのではなく、元のトラヒックの中でキャッシュＡのデータと同一の部分を、キャッシュＡの索引情報（ハッシュ）ＨＡ１に変換して送受信する。
　索引情報（ハッシュまたはハッシュ値）とは、パケットキャッシュにおいて、特定のキャッシュを素早く参照できるように、各キャッシュを特定の順番に並べ、その項目が出現する物理的な位置を示す情報である。キャッシュ自体のデータと比較して、索引情報（ハッシュ）は小さくなることが一般的である。
　元のトラヒックＴＦ１に含まれるデータに、第１の装置ＰＣ１と第２の装置ＰＣ２が保持するキャッシュと同一のデータが含まれる場合、第１の装置ＰＣ１と第２の装置ＰＣ２の間で、冗長性が削減されたデータが送受信される。
　例えば、図８では、元のトラヒックＴＦ１の中で冗長性が削減されたデータＴＦ２を、第２の装置ＰＣ２が受信した場合、冗長性が削減されたデータに含まれるキャッシュＡの索引情報（ハッシュ）の部分を、キャッシュＡ自体のデータに復元し、元のトラヒックＴＦ３に戻すことができる。この効果により、元のトラヒックＴＦ１の情報量（意味）を失うことなく、２つの装置ＰＣ１とＰＣ２の間（すなわち、帯域が細いネットワークＮＮ）で、トラヒックを削減することができるようになる。
　図７Ｂにおいて、１６Ｂｙｔｅの元データＯＤ１がキャッシュされていない場合（すなわち、ハッシュ化処理部３２２１により、元データＯＤ１が対応表記憶部３３２に格納された対応表に存在しないと判定された場合）、デバイス３０１は、ステップＳ１０２（キャッシュミス）に移行し、ハッシュ化処理部３２２１の制御の下、対応表を更新する処理を行うとともに、データＯＤ１をパケット出力部３２３に渡す。そして、パケット出力部３２３の制御の下、１６ＢｙｔｅのデータＯＤ１に１Ｂｙｔｅのヘッダ情報を付加して、１７ＢｙｔｅのデータパケットＰＫＴ１を生成する。
　次いで、デバイス３０１は、ステップＳ１０３において、送信制御部３２４の制御の下、この生成されたデータパケットＰＫＴ１を中間サーバ１０に転送する。
　ハッシュ化処理部３２２１は、例えば、対応表に存在しないデータを受信するたびに、対応表から最も古い情報を削除して新たに得られたデータとハッシュ値との対応関係を追加することにより、対応表を更新することができる。なお、図７Ｂでは、説明を明りょうにする便宜上、ハッシュ化処理部３２２１内のデータとして、ハッシュ化処理部３２２１による処理の後にパケット出力部３２３によりパケット化されたデータまでを示している。
　一方、１６Ｂｙｔｅの元データＯＤ１がキャッシュされている場合（すなわち、ハッシュ化処理部３２２１により、元データＯＤ１が対応表記憶部３３２に格納された対応表に存在すると判定された場合）、デバイス３０１は、ステップＳ１０４（キャッシュヒット）に移行し、ハッシュ化処理部３２２１の制御の下、１６Ｂｙｔｅのデータを２Ｂｙｔｅのハッシュに変換し、パケット出力部３２３の制御の下、１Ｂｙｔｅのヘッダ情報を付加して合計３ＢｙｔｅのデータパケットＰＫＴ２を生成する。
　次いで、デバイス３０１は、ステップＳ１０５において、送信制御部３２４の制御の下、この生成されたデータパケットＰＫＴ２を中間サーバ１０に転送する。
　（３）中間サーバ
　図７Ｃは、中間サーバ１０に関する動作１－２の一例を示す図である。
　ステップＳ１０３において、中間サーバ１０がデバイス３０１からキャッシュミスとして生成された１７ＢｙｔｅのデータパケットＰＫＴ１を受信すると、ステップＳ１０６において、中間サーバ１０は、パケットキャッシュとしてのデータ復元部１２２の制御の下、受信した１７ＢｙｔｅのパケットＰＫＴ１から１Ｂｙｔｅのヘッダ情報を削除して、１６Ｂｙｔｅの元データＯＤ２を復元する。
　一方、ステップＳ１０５において、中間サーバ１０がデバイス３０１からキャッシュヒットとして生成された３ＢｙｔｅのデータパケットＰＫＴ２を受信すると、ステップＳ１０７において、中間サーバ１０は、パケットキャッシュとしてのデータ復元部１２２の制御の下、受信した３ＢｙｔｅのパケットＰＫＴ２から１Ｂｙｔｅのヘッダ情報を削除し、２Ｂｙｔｅのハッシュから対応表に基づいて１６Ｂｙｔｅの元データＯＤ２を復元する。なお、２Ｂｙｔｅというハッシュのサイズは一例であり、任意のサイズのハッシュを設定できる。
　デバイス３０（第１のデバイス３０１）と中間サーバ１０は、本来は１６Ｂｙｔｅのデータを送受信すれば良いのに対し、キャッシュミスの場合は、１７Ｂｙｔｅのデータを送受信するため、キャッシュミスが頻発するとデバイス３０と中間サーバ１０との間の通信トラヒックが増加してしまう。一方、キャッシュヒットの場合は、１６Ｂｙｔｅの代わりに３Ｂｙｔｅのデータを送受信するだけで良いため、キャッシュヒットが十分に発生する場合は、デバイス３０と中間サーバ１０との間の通信トラヒックを大幅に削減することができる。
　続いて、中間サーバ１０は、ステップＳ１０８において、バッファリング処理部１２３の制御の下、複数のデバイス３０（３０１～３０ｎ）が生成した１６Ｂｙｔｅのデータを一定のサイズになるまでバッファリングする。バッファリング処理部１２３は、例えば、１つのイーサネットフレームに格納可能となるように、データのサイズが１，４４０Ｂｙｔｅになるまでバッファリングを実施し、１，４４０ＢｙｔｅのロングパケットＬＰＫＴ１を生成する。
　ここで、中間サーバ１０上でバッファリングをする際に、複数のデバイス３０（３０１～３０ｎ）が生成した１６Ｂｙｔｅのデータをそのままバッファリングしてしまうと、バッファリングされた１６Ｂｙｔｅのデータが、どのデバイス３０が生成したものか判別がつかなくなる。そこで、１６Ｂｙｔｅのデータに２ＢｙｔｅのデバイスＩＤを付加することで、バッファリングされた１６Ｂｙｔｅのデータがどのデバイス３０が生成したものかを判別できるようにする。なお、デバイス３０と中間サーバ１０とが通信開始時の時点でデバイスＩＤに関する情報の交換を行うことで、中間サーバ１０は、各デバイス３０のデバイスＩＤを知ることができる。
　次いで、中間サーバ１０は、ステップＳ１０９において、パケット符号化部１２４の制御の下、バッファリング処理部１２３により生成された１，４４０ＢｙｔｅのロングパケットＬＰＫＴ１に対して、パケット符号化による圧縮処理を行う。ここで、パケット符号化部１２４は、情報源符号化方式を用いて１，４４０Ｂｙｔｅのデータの圧縮を試みるが、実際にどのくらいのサイズが圧縮されるかについては、データの内容（Ｂｙｔｅ列の並び方）に左右される。１００分の１程度まで圧縮できることもあれば、ほとんど圧縮できないこともある。ここでは、５分の１程度に圧縮できると仮定し、パケット符号化部１２４による圧縮後の符号化データＥＤ１のサイズを３００Ｂｙｔｅとする。
　中間サーバ１０は、次いで、ステップＳ１１０において、送信制御部１２５の制御の下、圧縮後の３００Ｂｙｔｅの符号化データＥＤ１を中央サーバ２０に転送する。
　（４）中央サーバ
　図７Ｄは、中央サーバ２０に関する動作１－３の一例を示す図である。
　ステップＳ１１０において中央サーバ２０が中間サーバ１０から３００Ｂｙｔｅの符号化データＥＤ１を受信すると、ステップＳ１１１において、パケット復号部２２２の制御の下、３００ＢｙｔｅのデータＥＤ１を、情報源復号化を用いて解凍する。解凍後のデータＬＰＫＴ２には、２ＢｙｔｅのデバイスＩＤと１６Ｂｙｔｅの元データの複数の組み合わせがバッファリングされている。
　次いで、中央サーバ２０は、ステップＳ１１２において、元データ抽出部２２３の制御の下、１６Ｂｙｔｅの元データをデバイスＩＤごとに振り分けることで、各デバイス３０が生成したデータを元に戻し、第１のデバイス３０１により生成された元データＯＤ３を得ることができる。
　（５）制御サーバ
　図９は、制御サーバ４０による制御信号生成の処理手順と処理内容の一例を示すフローチャートである。
　制御サーバ４０は、ステップＳ２０１において、処理を開始するトリガの有無を取得している。この状態で、例えば、一定時間ごとにトリガを発生するタイマー（図示せず）からのトリガを受け取ると、以下の処理を開始する。
　まず、制御サーバ４０は、ステップＳ２０２において、負荷状態取得部４２１の制御の下、監視対象である各計算機の負荷状態を取得し、負荷状態記憶部４３１に記憶させる。一実施形態では、制御サーバ４０は、中間サーバ１０と通信可能に接続されており、中間サーバ１０の負荷状態を中間サーバ１０から直接取得する。制御サーバ４０はまた、中間サーバ１０を介してデバイス３０および中央サーバ２０の負荷状態を取得することが可能である。この場合、中間サーバ１０は、デバイス３０および中央サーバ２０から定期的にＣＰＵ使用率やメモリ使用量などの負荷状態を取得するように構成される。あるいは、制御サーバ４０は、ネットワークＮＷを介してデバイス３０および中央サーバ２０と直接通信することによってそれぞれの負荷状態を取得するようにしてもよい。
　次いで、ステップＳ２０３において、制御サーバ４０は、パケットキャッシュ制御部４２２、バッファリング制御部４２３およびパケット符号化制御部４２４の制御の下、負荷状態記憶部４３１から負荷状態を読み出し、あらかじめ設定されたしきい値と比較することにより、各計算機について過負荷状態が検出されたか否かを判定する。例えば、制御サーバ４０は、いずれか特定の計算機のＣＰＵ使用率およびメモリ使用量の両方がそれぞれについてあらかじめ設定されたしきい値を下回るときには、過負荷状態ではないと判定するように構成される。制御サーバ４０がすべての計算機の過負荷状態を一括して判定するようにしてもよいし、各制御部４２２～４２４がそれぞれの基準に基づいて１つまたは複数の計算機の過負荷状態を判定するようにしてもよい。過負荷状態が検出されなければ、処理は終了し、次のトリガを受け取るまで待機する。
　一方、ステップＳ２０３において過負荷状態が検出された場合、制御サーバ４０は、ステップＳ２０４において、パケットキャッシュ制御部４２２、バッファリング制御部４２３およびパケット符号化制御部４２４の制御の下、あらかじめ設定された制御基準に基づく適切な制御を決定し、制御信号出力制御部４２５の制御の下、制御信号を生成して制御対象の計算機へと出力する。
　各制御部４２２～４２４における過負荷の判定および制御信号出力制御部４２５による制御信号を生成するための制御基準は、あらかじめシステム設計者等が任意に設定可能である。例えば、特定のデバイス３０１について過負荷状態が検出されたときには、当該デバイス３０１が接続する中間サーバ１０と、その中間サーバ１０に接続されたすべてのデバイス３０２，・・・３０ｎに対し、パケットキャッシュを停止してデータをハッシュ化せずそのまま送信するように指示する制御信号を生成し出力するようにしてもよい。一例として、パケットキャッシュ制御部４２２が、特定のデバイス３０１が過負荷状態にあると判定されたことに応じて、制御信号出力制御部４２５に対し、パケットキャッシュ機能を停止するようにとの指示を出力する。そして、この指示を受け取った制御信号出力制御部４２５が、対象とする計算機（デバイス３０１，３０２，・・・３０ｎと中間サーバ１０）に対し、ハッシュ化処理を実行せずにデータを送信するよう指示する制御信号を生成し送信することができる。
　あるいは、中間サーバ１０に過負荷状態が検出されたときには、当該中間サーバ１０に対して一定時間バッファリング処理を行わないように制御してもよい。または中間サーバ１０の過負荷状態が解消するまで、当該中間サーバ１０がバッファリング処理および符号化処理を行わずにデータを中央サーバ２０に転送するように制御してもよい。一例として、バッファリング制御部４２３およびパケット符号化制御部４２４が、中間サーバ１０が過負荷状態にあると判定されたことに応じて、制御信号出力制御部４２５に対し、バッファリング機能およびパケット符号化機能を停止するようにとの指示を出力する。そして、この指示を受け取った制御信号出力制御部４２５が、対象とする計算機（中間サーバ１０）に対し、バッファリング処理および圧縮符号化処理を実行せずにデータを送信するよう指示する制御信号を生成し送信することができる。
　また、中央サーバ２０に過負荷状態が検出されたときには、例えば、当該中央サーバ２０に接続された複数の中間サーバ１０のうち任意に選択された半数の中間サーバ１０に対して、符号化処理を行わずにデータを中央サーバ２０に転送するよう指示することもできる。あるいは、強化学習をはじめとする機械学習手法を用いて、計算機の負荷を軽減する最適解を得ることにより最適制御を行うようにしてもよい。
　（効果）
　以上詳述したように、この発明の一実施形態では、複数のデバイス３０により生成されたデータをネットワークＮＷを介して中央サーバ２０で収集するためのデータ圧縮伝送システム１であって、複数のデバイス３０と中央サーバ２０との間に配置された中間サーバ１０を具備するシステムが提供される。このデータ圧縮伝送システム１では、上記複数のデバイス３０の各々が、パケットキャッシュ機能により、元のデータから得られるハッシュ値と元のデータとの対応関係を表す対応表を記憶しておき、送信対象のデータが対応表に含まれる場合にはデータをハッシュ値に変換して、ヘッダ情報を付加してデータパケットとして出力する。また、上記データ圧縮伝送システム１では、中間サーバ１０が、パケットキャッシュ機能により、複数のデバイス３０の各々から送信されたデータパケットを取得し、取得したデータパケットからヘッダ情報を削除し、残りのデータにハッシュ値が含まれる場合にはハッシュ値を元のデータに変換してデータを復元する。中間サーバ１０はまた、バッファリング機能により、上記復元されたデータをバッファリングしてロングパケット（結合データ）として出力する。中間サーバ１０はまた、上記ロングパケットを圧縮符号化して符号化データとして出力する。
　中間サーバ１０を具備しない従来のシステムでは、パケットキャッシュの機能がデバイス３０と中央サーバ２０に配置されていた。また中間サーバ１０を具備しない従来のシステムでは、バッファリング機能もデバイス３０に配置されていた。ここで、第１のデバイス３０１と第２のデバイス３０２は、それぞれ異なるパケットキャッシュを備え、第１のデバイス３０１と第２のデバイス３０２が異なるデータを生成する場合、第１のデバイス３０１のパケットキャッシュと中央サーバ２０のパケットキャッシュの間の通信トラヒックの削減率と、第２のデバイス３０２のパケットキャッシュと中央サーバ２０のパケットキャッシュとの間の通信トラヒックの削減率は異なる。同様に、第１のデバイス３０１と第２のデバイス３０２は、それぞれ異なるバッファリング装置を備え、第１のデバイス３０１と第２のデバイス３０２が異なるデータを生成する場合、やはり第１のデバイス３０１のパケットキャッシュと中央サーバ２０のパケットキャッシュの間のパケット数の削減率と、第２のデバイス３０２のパケットキャッシュと中央サーバ２０のパケットキャッシュとの間のパケット数の削減率は異なるものとなる。
　このような従来のシステムでは、デバイス３０は、生成した１６Ｂｙｔｅのデータに対し、一定のサイズのパケットになるまでバッファリングしていた。例えば、１つのイーサネットフレームに格納可能となるように、データのサイズが１，４４０Ｂｙｔｅになるまでバッファリングを実施していた。そして、バッファリングした１，４４０Ｂｙｔｅのデータがパケットキャッシュに格納されていない場合（キャッシュミス）は、１，４４０Ｂｙｔｅのデータに１Ｂｙｔｅのヘッダ情報を付加して、１，４４１Ｂｙｔｅのデータとして中央サーバ２０に転送する。中央サーバ２０は、受信した１，４４１Ｂｙｔｅのデータから、１Ｂｙｔｅのヘッダ情報を削除して、元データを復元する。一方、バッファリングした１，４４０Ｂｙｔｅのデータがパケットキャッシュに格納されている場合（キャッシュヒット）は、１，４４０Ｂｙｔｅのデータを２Ｂｙｔｅのハッシュに変換し、１Ｂｙｔｅのヘッダ情報を付加して、３Ｂｙｔｅのデータとして中央サーバ２０に転送する。中央サーバ２０は、受信した３Ｂｙｔｅのデータから、１Ｂｙｔｅのヘッダ情報を削除して、ハッシュから元のデータを復元する。
　上記のように、パケットキャッシュは、同じデータが過去に繰り返し送信されたか、という時間的な冗長性を圧縮する方式である。小さいサイズのデータであれば、同じデータが繰り返し送信される可能性が高くなるが、大きいサイズのデータの場合は、データが１Ｂｙｔｅでも異なると違うデータとして扱われ、パケットキャッシュを用いた圧縮が有効に機能しなくなる。
　これに対し、一実施形態に係るデータ圧縮伝送システム１では、パケットキャッシュを、デバイス３０と中間サーバ１０に配置している。デバイス３０が中間サーバ１０に対して同じデータを何回も繰り返して送信する場合は、データに時間的な冗長性が発生するため、パケットキャッシュを用いることで通信トラヒックを削減することができる。
　また、一実施形態に係るデータ圧縮伝送システム１では、バッファリング処理部を中間サーバ１０に配置している。デバイス３０は、バッファリング処理部を具備せず、バッファリングなしのデータをパケットキャッシュにより圧縮し、中間サーバ１０にデータを送信する。中間サーバ１０では、複数のデバイス３０から受信したデータのバッファリングを行い、サイズの小さいデータ（ショートパケット）をサイズの大きいデータ（ロングパケット）に変換する。
　また、一実施形態に係るデータ圧縮伝送システム１では、パケット符号化部および復号部を中間サーバ１０と中央サーバ２０に配置している。中間サーバ１０でバッファリングしたデータをパケット符号化方式により圧縮し、中間サーバ１０から中央サーバ２０へデータを送信する。
　さらに、一実施形態に係るデータ圧縮伝送システム１は、パケットキャッシュ制御部、パケット符号化制御部、およびバッファリング制御部の３つの機能部を具備しており、デバイス３０と中間サーバ１０と中央サーバ２０が、データ圧縮やバッファリングの処理によって過負荷状態に陥ることを回避することができる。
　デバイス３０が生成するデータ量は時間ごとに変化する場合があり、デバイス３０が地理的に移動する場合は、中間サーバ１０に接続するデバイス３０の台数が中間サーバ１０ごとに偏ることもある。ＩｏＴなどの分野では、デバイス３０と中間サーバ１０と中央サーバ２０に発生する負荷が時時刻刻と変化するため、どのくらいの性能のハードウェアを用意すればよいかという点について一定の解がない。そのため、ハードウェアが過負荷状態の場合にはデータの圧縮やバッファリングを行わずに、データをそのまま転送することで、ハードウェアの過負荷状態を未然に防ぐことができる。また、ネットワークに大量のデータが流れていて、ネットワークが過負荷状態の場合には、計算負荷は高くなるがより圧縮効率の高いアルゴリズムに切り替えるなどの工夫をすることもできる。一実施形態に係るデータ圧縮伝送システムでは、計算機性能とネットワーク性能のバランスをとりながら、全体的なアーキテクチャの中で最適なデータ圧縮を実現することができる。
　また、ＩｏＴなどの分野において、デバイスが生成するデータのサイズは小さいことが多く、高頻度に生成されるという特徴を持つ。高頻度に生成される小さいサイズのデータを圧縮するには、パケットキャッシュを用いた圧縮が有効であるが、従来のパケットキャッシュだけではパケット数を削減することはできなかった。本発明では、従来のシステムに対して、デバイス３０と中央サーバ２０の間の区間に、パケットキャッシュとバッファリングとパケット符号化の機能を具備する中間サーバ１０を設置することで、通信トラヒックの削減と通信パケット数の削減とネットワーク接続数の削減をすべて兼ね備えるだけでなく、リアルタイム性も担保した全体アーキテクチャを実現することができる。
　また、従来のシステムにおいて、デバイス３０が具備していた機能を中間サーバ１０に具備させることで、デバイス３０の機能を簡素化でき、デバイス３０のコストやメンテナンス性を向上することができる。中間サーバ１０のコストやメンテナンス性は、デバイス３０のコストやメンテナンス性よりも優れているため、中間サーバ１０を活用したシステムは、事業化等を見据えた上で実現性の高い方式である。
　上記のような一実施形態に係るデータ圧縮伝送システム１により、従来のシステムの３つの課題が以下のように解決される。
　［課題１］の解決
　従来のシステムでは、デバイス３０と中央サーバ２０の間の通信にパケットキャッシュを適用することで、デバイス３０と中央サーバ２０の間の通信トラヒックを削減することはできる。しかし、通信パケット数は変わらないため、中央サーバ２０にデバイス３０のデータを収集する際のコストが増加する。
　これに対し、上記一実施形態に係るデータ圧縮伝送システム１では、デバイス３０と中間サーバ１０の間の区間はパケットキャッシュを行い、複数のデバイス３０のデータを中間サーバ１０でバッファリングし、パケット符号化部１２４を用いて圧縮することができる。すなわち、デバイス３０と中間サーバ１０の間の区間はパケットキャッシュによる圧縮を行い、中間サーバ１０と中央サーバ２０の間の区間はパケット符号化による圧縮を行う。デバイス３０と中間サーバ１０の間、および中間サーバ１０と中央サーバ２０の間のすべての区間において、データを圧縮することができるため、すべての通信路において通信トラヒックを削減することができる。
　さらに、データ圧縮伝送システム１では、中間サーバ１０と中央サーバ２０の間の区間では、パケット数を削減することができる。例えば、図７Ａ～７Ｄの例では、中間サーバ１０において８０台分のデバイスのデータをバッファリングする場合、中間サーバ１０において８０台分のデバイスが生成する１６Ｂｙｔｅのデータを、１つのパケット（１，４４０Ｂｙｔｅ）にまとめることで、中央サーバ２０に到着する通信パケット数を８０分の１にすることができる。このように、中間サーバ１０と中央サーバ２０の間の区間において、通信トラヒックを削減するだけでなく、パケット数も削減することができるようになる。
　また、データ圧縮伝送システム１では、デバイス３０と中間サーバ１０の間の区間は、従来のシステムと同様に、パケットキャッシュによる圧縮を行う。そのため、通信パケット数は変わらないため、全体で見たときに、デバイス３０と中間サーバ１０の間の区間の通信パケット数を削減することはできない。しかし、中間サーバ１０の台数は、中央サーバ２０の台数と比較してより多くの台数を設置することができる。例えば、中間サーバのない従来のシステムでは、デバイス３０の台数が１，０００台、中央サーバ２０が１台の場合は、１，０００台分のデバイス３０の通信パケットが中央サーバ２０に一斉に到着する。一方、上記データ圧縮伝送システム１では、デバイス３０の台数が１，０００台、中央サーバ２０が１台のときに、中間サーバ１０を１０台配置すれば、１，０００台分のデバイス３０通信パケットを１０台の中間サーバ１０に負荷分散できる。これにより、デバイス３０と中間サーバ１０の間の区間の通信パケット数を１０分の１にすることができる。
　このように、複数台のデバイス３０と１台の中央サーバ２０の間の区間に、複数台の中間サーバ１０を設置することで、中間サーバ１０で複数台の通信パケットのバッファリングを行いながら、通信トラヒックの削減と、通信パケット数の削減を両立することができるようになる。
　［課題２］の解決
　従来のシステムでは、デバイス３０上でデータをバッファリングすることで、通信パケット数を削減することができるが、データをバッファリングするための遅延時間が発生する。リアルタイム性が重要なユースケースでは、バッファリングにより通信パケット数を削減することはできなくなる。
　上記一実施形態に係るデータ圧縮伝送システム１では、デバイス３０上ではデータのバッファリングを行わず、中間サーバ１０上で複数台のデバイス３０のデータのバッファリングを行う。従来のシステムでは、１台のデバイスが生成するデータを、デバイス自身が十分なサイズが溜まるまでバッファリングするため、バッファリング遅延時間は大きくなる。一方、中間サーバ１０上で複数台のデバイス３０のデータを集約することで、短時間に大量のデータを受信してバッファリングすることができるため、バッファリングに要する遅延時間を小さくすることができる。例えば、１台のデバイス３０が毎秒１０Ｂｙｔｅのデータを生成する場合、１，０００Ｂｙｔｅの大きさになるまでバッファリングすると、バッファリング遅延時間は１００秒となる。一方、１，０００台のデバイス３０のデータを中間サーバ１０で集約する場合、バッファリング遅延時間は０．１秒となる。この効果により、上記データ圧縮伝送システム１では、リアルタイム性が重要なユースケースに対しても、バッファリングによる遅延時間の影響を抑えながら、通信トラヒックと通信パケット数を削減することができる。
　［課題３］の解決
　従来のシステムでは、中央サーバ２０はデバイス３０の台数分のネットワーク接続を維持する必要がある。ＩｏＴなどの分野ではデバイス３０の台数は数億台規模となるため、中央サーバ２０に多数のネットワーク接続が生成されると、Ｃ１０Ｍなどの接続問題が発生する。
　この発明の一実施形態では、複数台のデバイス３０の通信を中間サーバ１０で集約することができる。デバイス３０の台数が１，０００万台、中央サーバ２０が１台の場合に、１，０００万台分のデバイスが中央サーバ２０と直接接続する場合は、中央サーバ２０に発生するネットワーク接続の数は１，０００万本となる。一方、デバイス３０の台数が１，０００万台、中央サーバ２０が１台、中間サーバ１０が１，０００台の場合、中央サーバ２０に発生するネットワーク接続の数は１０００本となる。１，０００万台のデバイス３０の通信を１，０００台の中間サーバ１０で集約してバッファリングすることで、中間サーバ１０と中央サーバ２０に発生するネットワーク接続数を大幅に削減することができる。
　上記実施形態の一態様では、中央サーバ２０が、中間サーバ１０から送信された符号化データを復号して結合データを生成する復号部２２２を備えてもよい。
　この一態様によれば、中央サーバ２０は、中間サーバ１０によって圧縮符号化されたデータを復号し、符号化前の結合データを生成する。これにより、中間サーバ１０と中央サーバ２０との間の通信量を低減しつつ、中央サーバ２０において、符号化前のデータを収集し、蓄積することができる。
　上記実施形態の他の一態様では、上記データ圧縮伝送システム１が、複数のデバイス３０、上記中間サーバ１０および上記中央サーバ２０のうちの少なくとも１つについての負荷状態を取得する負荷状態取得部４２１と、上記取得された負荷状態に応じて、上記ハッシュ化処理を実行せずにデータを送信するよう指示する第１の制御信号、上記バッファリング処理を実行せずにデータを出力するよう指示する第２の制御信号、または上記圧縮符号化処理を実行せずにデータを送信するよう指示する第３の制御信号を生成して出力する処理制御部４２２、４２３または４２４とをさらに具備してもよい。
　この一態様によれば、複数のデバイス３０、中間サーバ１０および中央サーバ２０のうちの少なくとも１つについての負荷状態が取得され、取得された負荷状態に応じて、ハッシュ化処理、バッファリング処理または圧縮符号化処理を実行せずにデータを送信／出力するよう指示する制御信号が生成され出力される。これにより、各計算機の負荷状態に応じた圧縮処理の制御が可能となり、各計算機の負荷を軽減しながらデータ圧縮伝送を行うことができる。
　上記実施形態の他の一態様では、生成したデータをキャッシュに基づいてハッシュ値に変換し、当該ハッシュ値を含むパケットを生成して送信する複数のデバイス３０と、上記複数のデバイス３０により生成されたデータをネットワークを介して収集する中央サーバ２０との間に配置される中間サーバ１０が、上記複数のデバイス３０の各々から送信された上記ハッシュ値を含むパケットを受信する受信部１２１と、上記受信したパケットに含まれるハッシュ値を元データに復元するデータ復元部１２２と、上記復元された元データを複数まとめて結合データとして出力するバッファリング処理を行うバッファリング処理部１２３と、上記出力された結合データを圧縮して符号化データを生成する圧縮符号化処理を行う圧縮符号化処理部１２４と、上記符号化データを上記中央サーバに送信する送信部１２５とを備え得る。
　これにより、やはり、複数のデバイスと、中央サーバと、それらの間に配置された中間サーバとを備えるデータ圧縮伝送システムにおいて、ＩｏＴデバイスからのデータ収集に求められるリアルタイム性を担保した上で、有効な通信トラヒックおよびパケット数の削減を実現することができる。
　上記実施形態の他の一態様では、上記中間サーバ１０が、上記複数のデバイス３０、上記中間サーバ１０および上記中央サーバ２０のうちの少なくとも１つについての負荷状態を取得する、負荷状態取得部４２１と、上記取得された負荷状態に応じて、上記ハッシュ値に変換する処理を実行せずにデータを送信するよう指示する第１の制御信号、上記バッファリング処理を実行せずにデータを出力するよう指示する第２の制御信号、または上記圧縮符号化処理を実行せずにデータを送信するよう指示する第３の制御信号を生成して出力する処理制御部４２２、４２３または４２４とをさらに備えてもよい。
　これにより、やはり、各計算機の負荷状態に応じた圧縮処理の制御が可能となり、各計算機の負荷を軽減しながらデータ圧縮伝送を行うことができる。
　［他の実施形態］
　なお、この発明は上記実施形態に限定されるものではない。
　例えば、上述したように、制御サーバ４０は、データ圧縮伝送システム１に不可欠な構成ではない。制御サーバ４０が備える各機能部は、中間サーバ１０の制御ユニット１２内に設けることもでき、中央サーバ２０の制御ユニット２１２内に設けることもでき、あるいは他の複数のエッジサーバに分散配置することもできる。
　また、以上で説明したデバイス３０と中央サーバ２０との間のネットワーク接続形態および中間サーバ１０の接続形態は、一例にすぎず、上記の形態に限定されない。
　さらに、デバイス３０、中央サーバ２０および中間サーバ１０が備える各機能部を、クラウドコンピュータやエッジルータ等に分散配置し、これらの装置が互いに連携することにより処理を行うようにしてもよい。
　その他、ハッシュ化に用いる対応表のフォーマットや対応表更新のタイミング等についても、この発明の要旨を逸脱しない範囲で種々変形して実施可能である。
　上記処理を実現するプログラムは、コンピュータで読み取り可能な記録媒体（または記憶媒体）に格納して提供されてもよい。プログラムは、インストール可能な形式のファイルまたは実行可能な形式のファイルとして記録媒体に記憶される。記録媒体の例は、磁気ディスク、光ディスク（ＣＤ－ＲＯＭ、ＣＤ－Ｒ、ＤＶＤ－ＲＯＭ、ＤＶＤ－Ｒなど）、光磁気ディスク（ＭＯなど）、半導体メモリを含む。また、上記処理を実現するプログラムを、インターネットなどのネットワークに接続されたコンピュータ（サーバ）上に格納し、ネットワーク経由でコンピュータ（クライアント）にダウンロードさせてもよい。
　要するにこの発明は、上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合せにより種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施形態に亘る構成要素を適宜組み合せてもよい。
　１…データ圧縮伝送システム
　１０…中間サーバ
　１１…通信インタフェース
　１２…制御ユニット
　１２Ａ…ハードウェアプロセッサ
　１２Ｂ…プログラムメモリ
　１３…データメモリ
　２０…中央サーバ
　３０，３０１，３０２，３０ｎ…デバイス
　４０…制御サーバ
　５０…バス
　６０…センサ群
　６１～６ｋ…センサ
　７１…入力デバイス
　７２…出力デバイス
　１２１…データパケット取得部
　１２２…データ復元部
　１２３…バッファリング処理部
　１２４…パケット符号化部
　１２５…送信制御部
　１３１…データパケット記憶部
　１３２…対応表記憶部
　２１０…通信インタフェース
　２１２…制御ユニット
　２２０…制御ユニット
　２２１…符号化データ取得部
　２２２…パケット復号部
　２２３…元データ抽出部
　２２４…出力制御部
　２３０…データメモリ
　２３１…符号化データ記憶部
　２３２…元データ記憶部
　３１０…通信インタフェース
　３１１…センサインタフェース
　３１２…入出力インタフェース
　３２０…制御ユニット
　３２１…センシングデータ生成部
　３２２…ハッシュ化処理部
　３２３…パケット出力部
　３２４…送信制御部
　３３０…データメモリ
　３３１…セシングデータ記憶部
　３３２…対応表記憶部
　４１０…通信インタフェース
　４２０…制御ユニット
　４２１…負荷状態取得部
　４２２…パケットキャッシュ制御部
　４２３…バッファリング制御部
　４２４…パケット符号化制御部
　４２５…制御信号出力制御部
　４３０…データメモリ
　４３１…負荷状態記憶部
　４３２…制御信号記憶部
　３２２１，３２２２…ハッシュ化処理部

Claims (8)

  1. 　複数のデバイスにより生成されたデータをネットワークを介して中央サーバで収集するためのデータ圧縮伝送システムであって、
    　前記複数のデバイスと前記中央サーバとの間に配置された中間サーバを具備し、
    　前記複数のデバイスの各々は、
    　　生成したデータをキャッシュに基づいてハッシュ値に変換するハッシュ化処理を行うハッシュ化処理部と、
    　　前記ハッシュ値を含むパケットを生成して前記中間サーバに送信する第１の送信部と
    を備え、
    　前記中間サーバは、
    　　前記複数のデバイスの各々から送信された前記パケットを受信する受信部と、
    　　前記受信したパケットに含まれるハッシュ値を元データに復元するデータ復元部と、
    　　前記復元された元データを複数まとめて結合データとして出力するバッファリング処理を行うバッファリング処理部と、
    　　前記出力された結合データを圧縮して符号化データを生成する圧縮符号化処理を行う圧縮符号化処理部と、
    　　前記符号化データを前記中央サーバに送信する第２の送信部と
    を備える、データ圧縮伝送システム。
  2. 　前記中央サーバは、前記中間サーバから送信された前記符号化データを復号して前記結合データを生成する復号部を備える、請求項１に記載のデータ圧縮伝送システム。
  3. 　前記複数のデバイス、前記中間サーバおよび前記中央サーバのうちの少なくとも１つについての負荷状態を取得する負荷状態取得部と、
    　前記取得された負荷状態に応じて、前記ハッシュ化処理を実行せずにデータを送信するよう指示する第１の制御信号、前記バッファリング処理を実行せずにデータを出力するよう指示する第２の制御信号、または前記圧縮符号化処理を実行せずにデータを送信するよう指示する第３の制御信号を生成して出力する処理制御部とをさらに具備する、請求項１または２に記載のデータ圧縮伝送システム。
  4. 　生成したデータをキャッシュに基づいてハッシュ値に変換し、当該ハッシュ値を含むパケットを生成して送信する複数のデバイスと、前記複数のデバイスにより生成されたデータをネットワークを介して収集する中央サーバとの間に配置される中間サーバであって、
    　　前記複数のデバイスの各々から送信された前記ハッシュ値を含むパケットを受信する受信部と、
    　　前記受信したパケットに含まれるハッシュ値を元データに復元するデータ復元部と、
    　　前記復元された元データを複数まとめて結合データとして出力するバッファリング処理を行うバッファリング処理部と、
    　　前記出力された結合データを圧縮して符号化データを生成する圧縮符号化処理を行う圧縮符号化処理部と、
    　　前記符号化データを前記中央サーバに送信する送信部と
    を備える、中間サーバ。
  5. 　前記複数のデバイス、前記中間サーバおよび前記中央サーバのうちの少なくとも１つについての負荷状態を取得する負荷状態取得部と、
    　前記取得された負荷状態に応じて、前記ハッシュ値に変換する処理を実行せずにデータを送信するよう指示する第１の制御信号、前記バッファリング処理を実行せずにデータを出力するよう指示する第２の制御信号、または前記圧縮符号化処理を実行せずにデータを送信するよう指示する第３の制御信号を生成して出力する処理制御部とをさらに備える、請求項４に記載の中間サーバ。
  6. 　データを生成する複数のデバイスと、前記複数のデバイスにより生成されたデータをネットワークを介して収集する中央サーバと、前記複数のデバイスと前記中央サーバとの間に配置される中間サーバとを具備するデータ圧縮伝送システムが実行する、データ圧縮伝送方法であって、
    　前記複数のデバイスの各々が、生成したデータをキャッシュに基づいてハッシュ値に変換するハッシュ化処理を行う過程と、
    　前記複数のデバイスの各々が、前記ハッシュ値を含むパケットを生成して前記中間サーバに送信する過程と、
    　前記中間サーバが、前記複数のデバイスの各々から送信された前記パケットを受信する過程と、
    　前記中間サーバが、前記受信したパケットに含まれるハッシュ値を元データに復元する過程と、
    　前記中間サーバが、前記復元された元データを複数まとめて結合データとして出力するバッファリング処理を行う過程と、
    　前記中間サーバが、前記出力された結合データを圧縮して符号化データを生成する圧縮符号化処理を行う過程と、
    　前記中間サーバが、前記符号化データを前記中央サーバに送信する過程とを備える、
    データ圧縮伝送方法。
  7. 　キャッシュに基づいてデータをハッシュ値に変換し、当該ハッシュ値を含むパケットを生成して送信する複数のデバイスと、前記複数のデバイスにより生成されたデータをネットワークを介して収集する中央サーバとの間に配置される中間サーバが実行する、データ圧縮伝送方法であって、
    　　前記複数のデバイスの各々から送信された前記ハッシュ値を含むパケットを受信する過程と、
    　　前記受信したパケットに含まれるハッシュ値を元データに復元する過程と、
    　　前記復元された元データを複数まとめて結合データとして出力するバッファリング処理を行う過程と、
    　　前記出力された結合データを圧縮して符号化データを生成する圧縮符号化処理を行う過程と、
    　　前記符号化データを前記中央サーバに送信する過程と
    を備える、データ圧縮伝送方法。
  8. 　請求項４または５に記載の中間サーバの各部による処理をプロセッサに実行させるプログラム。
PCT/JP2019/050620 2019-02-22 2019-12-24 データ圧縮伝送システム、中間サーバ、方法およびプログラム WO2020170601A1 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
US17/432,303 US11470002B2 (en) 2019-02-22 2019-12-24 Data compression transmission system, intermediate server, method, and program
JP2021501640A JP7025105B2 (ja) 2019-02-22 2019-12-24 データ圧縮伝送システム、中間サーバ、方法およびプログラム

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2019-030553 2019-02-22
JP2019030553 2019-02-22

Publications (1)

Publication Number Publication Date
WO2020170601A1 true WO2020170601A1 (ja) 2020-08-27

Family

ID=72144055

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2019/050620 WO2020170601A1 (ja) 2019-02-22 2019-12-24 データ圧縮伝送システム、中間サーバ、方法およびプログラム

Country Status (3)

Country Link
US (1) US11470002B2 (ja)
JP (1) JP7025105B2 (ja)
WO (1) WO2020170601A1 (ja)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2016181461A1 (ja) * 2015-05-11 2016-11-17 富士通株式会社 転送装置、通信システム、通信方法、および、通信プログラム
WO2018015990A1 (ja) * 2016-07-19 2018-01-25 株式会社日立製作所 センサシステム及びデータ収集方法

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1729460B (zh) * 2002-12-20 2010-05-12 日本电信电话株式会社 通信方法、通信系统、中继系统、邮件发送的系统及方法
US20050138563A1 (en) * 2003-12-18 2005-06-23 International Business Machines Corporation Method and system for providing computer system software images
US8321385B2 (en) * 2010-03-12 2012-11-27 Lsi Corporation Hash processing in a network communications processor architecture
US8554745B2 (en) * 2009-04-27 2013-10-08 Netapp, Inc. Nearstore compression of data in a storage system
US9843412B2 (en) * 2010-10-06 2017-12-12 International Business Machines Corporation Optimizing routing of data across a communications network
US9639183B2 (en) * 2015-04-20 2017-05-02 Wacom Co., Ltd. System and method for bidirectional communication between stylus and stylus sensor controller
CN110050474A (zh) * 2016-12-30 2019-07-23 英特尔公司 用于物联网网络中的复合对象的子对象的类型命名和区块链

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2016181461A1 (ja) * 2015-05-11 2016-11-17 富士通株式会社 転送装置、通信システム、通信方法、および、通信プログラム
WO2018015990A1 (ja) * 2016-07-19 2018-01-25 株式会社日立製作所 センサシステム及びデータ収集方法

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
AKIHIRO SHIMIZU: "Packet processing architecture at IoT devices and its prototyping system", IEICE TECHNICAL REPORT, vol. 117, no. 4, 13 April 2017 (2017-04-13) *

Also Published As

Publication number Publication date
JP7025105B2 (ja) 2022-02-24
US20220141135A1 (en) 2022-05-05
US11470002B2 (en) 2022-10-11
JPWO2020170601A1 (ja) 2021-09-30

Similar Documents

Publication Publication Date Title
US8171124B2 (en) Systems and methods for GSLB remote service monitoring
US8677011B2 (en) Load distribution system, load distribution method, apparatuses constituting load distribution system, and program
US8275871B2 (en) Systems and methods for providing dynamic spillover of virtual servers based on bandwidth
US8706885B2 (en) Systems and methods for health based spillover
US8516113B1 (en) Selective compression for network connections
US10299164B2 (en) Protocol stack adaptation method and apparatus
Lumezanu et al. The effect of packet loss on redundancy elimination in cellular wireless networks
EP2962510B1 (en) Method for controlling user plane traffic flows in a wireless telecommunication network
KR101640105B1 (ko) 무선 액세스 네트워크에서의 콘텐츠 전달을 위한 방법 및 장치
CN102780712A (zh) 会话的切换方法及装置
WO2020170601A1 (ja) データ圧縮伝送システム、中間サーバ、方法およびプログラム
JPWO2015052867A1 (ja) 端末装置、端末装置制御方法および端末装置制御プログラム
US9456380B2 (en) Data compression in a communications network
KR101432719B1 (ko) 핸드오버를 지원하는 컨텐츠 전송 방법, 시스템 및 컴퓨터 판독 가능한 기록 매체
US20210160161A1 (en) Processing local area network diagnostic data
JP2014016758A (ja) ログデータ解凍装置、ログデータ圧縮装置、ログデータ解凍プログラム及びログデータ圧縮プログラム
US10659558B2 (en) Saving bandwidth in transmission of compressed data
Liu et al. Modeling response time of SOAP over HTTP
KR100964104B1 (ko) 무선 네트워크 데이터의 선별적 압축에 의한 최적화 전송시스템과 그 방법
AU2014204529B2 (en) A method of assigning a core to process a packet and a device for multicore processing
Arvidsson et al. Fast transport for edge computing in 5g networks
WO2023105647A1 (ja) フロー情報収集システム、フロー情報収集方法、および、フロー情報収集プログラム
KR101392479B1 (ko) 네트워크 장비의 로드 밸런싱 시스템 및 그 로드 밸런싱 방법
Seemakhupt et al. When should we use HTTP2 multiplexed stream?
CN101616164A (zh) 一种传输报文的方法和装置

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 19916532

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2021501640

Country of ref document: JP

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 19916532

Country of ref document: EP

Kind code of ref document: A1