(57)【要約】【課題】複数の通信経路を同時に利用する場合であっても映像の乱れや制御不良などアプリケーションレベルでの品質劣化を防止することができる通信システム及び通信方法を提供する。【解決手段】通信ノードは１００、自身が生成した又は他の送信ノード４００から受信したパケットを検査し、その検査結果に基づいて選択的にパケットの複製要否を判断し、複製が必要なパケットは複製して複数の通信インタフェースを介して受信ノード２００へ送信し、複製が不要なパケットは何れか一つの通信インタフェースを介して受信ノード２００へ送信することを特徴とする。【選択図】図２
2019029688.tif 000002
【特許請求の範囲】
【請求項１】
複数の通信インタフェースを備えるとともに自身が生成した又は他の送信ノードから受信したパケットを前記複数の通信インタフェースを介して受信ノードに対して送信する通信ノードを有する通信システムであって、
前記通信ノードは、自身が生成した又は他の送信ノードから受信したパケットを検査し、その検査結果に基づいて選択的にパケットの複製要否を判断し、複製が必要なパケットは複製して複数の通信インタフェースを介して受信ノードへ送信し、複製が不要なパケットは何れか一つの通信インタフェースを介して受信ノードへ送信する
ことを特徴とする通信システム。
【請求項２】
自身が生成した又は他の送信ノードから受信したパケットの検査ルールを管理する検査ルール管理部と、
前記検査ルール管理部から取得した検査ルールに基づいてパケットを検査しパケットの複製要否を判断するパケット検査部と、
前記パケット検査部から通知されるパケットの複製要否に基づいて、複製が必要なパケットは複製して複数の通信インタフェースを介して受信ノードへ送信し、複製が不要なパケットは何れか一つの通信インタフェースを介して受信ノードへ送信するパケット処理部と、を備えた
ことを特徴とする請求項１記載の通信システム。
【請求項３】
前記パケット検査部は、パケットの内容に基づき、当該パケットが、区切りパケット，パラメタセットを含むパケット，キーフレームを含むパケット，メタデータを含むパケットの何れか或いは任意の組み合わせに該当するかを判断し、当該パケットの複製要否を決定する
ことを特徴とする請求項２記載の通信システム。
【請求項４】
複数の異なる種別のパケットを自身が生成し又は他の送信ノードから受信して受信ノードに送信する通信システムであって、
前記通信ノードは、パケットを検査する場合に、検査するパケットの情報を記録し、検査するパケットとは異なる種別のパケットに関する記録済のパケット情報を取得して照合した結果に基づいて選択的にパケットの複製要否を判断し、複製が必要なパケットは複製して複数の通信インタフェースを介して受信ノードへ送信し、複製が不要なパケットはい何れか一つの通信インタフェースを介して受信ノードへ送信する
ことを特徴とする請求項１記載の通信システム。
【請求項５】
自ら生成又は他から受信するパケットの検査ルールを管理する検査ルール管理部と、
前記検査ルール管理部から取得する検査ルールに基づいてパケットを検査しパケットの複製要否を判断するパケット検査部と、
記録すべきパケットの情報をパケットデータ保持ルールとして管理するパケットデータ保持ルール管理部と、
前記パケットデータ保持ルール管理部から取得するパケットデータ保持ルールに基づいてパケットの情報を記録するパケットデータ保持部と、
検査するパケットを前記パケット検査部とパケットデータ保持部前記に通知する前処理部と、
複製が必要なパケットは複製して複数の通信インタフェースを介して受信ノードへ送信し、複製が不要なパケットは何れか一つの通信インタフェースを介して受信ノードへ送信するパケット処理部と、を備えた、
ことを特徴とする請求項４記載の通信システム。
【請求項６】
前記パケットデータ保持部は、パケットの持つ時刻情報，シーケンス番号情報，フラグ情報，測定量情報の何れか又はその任意の組み合わせをパケットデータとして保持し、
前記パケット検査部は、パケットを、前記パケットデータ保持部に保持されているパケットデータと照合した結果に基づいて当該パケットの複製要否を決定する
ことを特徴とする請求項５記載の通信システム。
【請求項７】
複製が必要なパケットを複製する場合に、利用可能な通信インタフェースの状態と送信しようとするパケットのサイズを参照し、当該パケットの送信に利用する１つ以上の通信インタフェースを決定し、決定した通信インタフェースを介して当該パケットを送信するパケット処理部を備えた
ことを特徴とする請求項１乃至６何れか１項記載の通信システム。
【請求項８】
複数の通信インタフェースを備える通信ノードが、自身が生成した又は他の送信ノードから受信したパケットを前記複数の通信インタフェースを介して受信ノードに対して送信する通信方法であって、
前記通信ノードは、自身が生成した又は他の送信ノードから受信したパケットを検査し、その検査結果に基づいて選択的にパケットの複製要否を判断し、複製が必要なパケットは複製して複数の通信インタフェースを介して受信ノードへ送信し、複製が不要なパケットは何れか一つの通信インタフェースを介して受信ノードへ送信する
ことを特徴とする通信方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワークを介して、リアルタイム性が重要な映像・音声・制御信号・フィードバック信号等を含むデータを、通信品質が変動するネットワークを介して送受する通信ノードの間に、２つ以上の異なる通信経路を持たせて同時に利用することで、通信の帯域や信頼性の向上を実現するための、通信システム及び通信方法に関する。
【背景技術】
【０００２】
昨今、ネットワークへ接続して通信を行い、サービスを利用するための接続手段は多様化しており、さらにそれら複数の接続手段を同時に利用することで、単一の接続手段のみを利用する場合に比べて、通信帯域の拡大、ネットワーク負荷の低減、通信断に対する耐性の向上を図る技術が利用されている。
【０００３】
このような既存技術の代表的な例として、データの欠損やエラーを許容しないアプリケーションに好適であるＴＣＰ（Transmission Control Protocol）を拡張したＭＰＴＣＰ（Multipath TCP）（非特許文献１参照）や、映像や音声のリアルタイム通信に多く用いられるＲＴＰ（Real-time Transport Protocol）の拡張技術であるＭＰＲＴＰ（Multipath RTP）がある（非特許文献２，非特許文献３参照）。
【０００４】
これらの技術は、送信しようとするパケットを、利用可能な通信経路のうち何れか１つを選択して送信する。複数の通信経路で通信を経路分散することで、複数の通信経路の通信帯域を合算して合計帯域を増加させたり、ある帯域を消費する通信を複数経路に分散させることで経路毎の帯域消費を削減してネットワーク負荷を軽減したり、ある通信経路に生じた通信品質の悪化がもたらすパケットの喪失やエラーをその通信経路を流れるパケットのみに限定して通信経路途絶に対するエンドツーエンドの耐性を向上させることができる、などの利点が得られる。
【０００５】
またこのうちＭＰＴＣＰは、ｒｅｄｕｎｄａｎｔモードで動作させることで、全てのパケットを利用可能なすべての通信経路に複製して送信することもできる。このようにすることで、通信帯域を犠牲にする一方、データの通信遅延を少なくする確率を高める。
【先行技術文献】
【非特許文献】
【０００６】
【非特許文献１】A. Ford, 他3名, "TCP Extensions for Multipath Operation with Multiple Addresses", RFC6824, IETF, 2013年1月
【非特許文献２】V. Singh，他4名，"Multipath RTP (MPRTP)", draft-ietf-avtcore-mprtp-03, AVT Core Working Group, Internet-Draft, IETF, 2016年7月8日, [online], [平成29年6月22日検索], インターネット<URL:https://tools.ietf.org/html/draft-ietf-avtcore-mprtp-03>
【非特許文献３】V. Singh，他2名，"MPRTP: Multipath Considerations for Real-time Media", ACM Multimedia Systems, MMSys, 2013年
【発明の概要】
【発明が解決しようとする課題】
【０００７】
しかし、送信されるパケットは、全ての利用可能な通信経路に一律に複製されて送信されるわけではなく、送信しようとするパケットのサイズ、通信経路毎の遅延、帯域、パケットロス率をもとに、何れかの通信経路を選択して送信される。例えば、サイズが大きいデータパケットであれば、遅延に対する帯域の割合が最も大きく、かつロス率が小さい通信経路を選択する。
【０００８】
ある経路に通信品質の悪化が生じた場合、その経路を流れるパケットが喪失したりエラーが発生したりすることがあるが、既存技術では、喪失やエラーが発生することによる影響の大きさを考慮せず経路を択一的に選択するため、そのようなパケットが流れる経路に問題が生じると、受信側で重要なパケットが正しく受信できず、大きな悪影響が生じるおそれがある。
【０００９】
図２７に示すように、例えばＨ．２６４のようなフレーム間圧縮を行う映像コーデックを利用した映像データの場合では、ＩＤＲフレーム／Ｉフレームを含むパケットが流れる通信経路に通信品質の悪化が生じた場合に、他方の通信経路に生じた場合に比べて大きな映像の乱れが生じる。
【００１０】
また、ＪＰＥＧ（Joint Photographic Experts Group）のようにフレーム間圧縮を行わない画像コーデックにおいても、リスタートマーカ及び量子化テーブルを含むパケットが欠損すると、データの欠落に対する復号精度が低下する。
【００１１】
また、図２８に示すように、映像中の動体検知や顔認識、音声検知などのメタデータを映像データに埋め込む、又は映像データを参照するタイムスタンプなどを付与して別データとして送信する場合では、メタデータ等を含むパケットが流れる通信経路に通信品質が悪化した場合に、検知結果が映像と併せて失われたり、検知結果のみが残りそれを示す映像データが失われる、又は反対に、映像のみが残り検知結果が失われる、などの問題が生じる。そして、これにより検知結果に応じて動作するシステム（監視システムなど）の動作に不良をきたすおそれがある。
【００１２】
単純にデータを全て複製して利用可能な通信経路の全てで送信する場合、このような問題が発生するリスクを低減することが可能だが、通信帯域の消費が非効率的となる。
【００１３】
本発明は上記事情に鑑みてなされたものであり、その目的とするところは、複数の通信経路を同時に利用する場合であっても映像の乱れや制御不良などアプリケーションレベルでの品質劣化を防止することができる通信システム及び通信方法を提供することにある。
【課題を解決するための手段】
【００１４】
上記目的を達成するために、出願人は、一つの元となるデータを分割したパケット列の中でも、パケットが含む内容の重要性に相違がある場合があることに着眼し、重要性の高いデータを含むパケットについて複数経路を重複的に利用しつつ、そうではないパケットは通信経路を択一的に選択して送信することで、ネットワーク負荷の上昇を抑えつつ、受信ノードへの当該パケットの到達性を向上させる技術を発明した。
【００１５】
本願発明は、複数の通信インタフェースを備えるとともに自身が生成した又は他の送信ノードから受信したパケットを前記複数の通信インタフェースを介して受信ノードに対して送信する通信ノードを有する通信システムであって、前記通信ノードは、自身が生成した又は他の送信ノードから受信したパケットを検査し、その検査結果に基づいて選択的にパケットの複製要否を判断し、複製が必要なパケットは複製して複数の通信インタフェースを介して受信ノードへ送信し、複製が不要なパケットは何れか一つの通信インタフェースを介して受信ノードへ送信することを特徴とする。
【発明の効果】
【００１６】
本発明によれば、データを複数の通信経路を同時に利用する通信システムにおいて、一部の通信経路に通信品質の悪化が生じた場合であっても、重要なデータを含むパケットについてはリアルタイム性を失うことなく受信ノードすることができるので、映像の乱れの抑制や制御不良の防止が可能となる。
【図面の簡単な説明】
【００１７】
【図１】本発明に係る通信システムの全体構成図
【図２】第１の実施の形態に係る通信システムの動作説明図
【図３】第１の実施の形態に係る通信ノードの機能ブロック図
【図４】パケット検査部の動作フロー
【図５】パケット検査部の詳細動作フロー
【図６】パケット処理部の動作フロー
【図７】第１の実施の形態に係る通信システムの動作シーケンス
【図８】実施例１に係るパケット検査部の動作フロー
【図９】実施例１に係る検査ルール情報の一例
【図１０】実施例２に係るパケット検査部の動作フロー
【図１１】実施例２に係る検査ルール情報の一例
【図１２】実施例３に係るパケット検査部の動作フロー
【図１３】実施例３に係る検査ルール情報の一例
【図１４】実施例４に係る送信ルール情報の一例
【図１５】第２の実施の形態に係る通信システムの動作説明図
【図１６】第２の実施の形態に係る通信ノードの機能ブロック図
【図１７】前処理部の動作フロー
【図１８】パケットデータ保持部の動作フロー
【図１９】パケットデータ保持部の詳細動作フロー
【図２０】パケット検査部の動作フロー
【図２１】パケット検査部の詳細動作フロー
【図２２】第２の実施の形態に係る通信システムの動作シーケンス
【図２３】実施例５に係るパケット連関情報の一例
【図２４】実施例６に係るパケットデータ保持ルールの一例
【図２５】実施例７に係るパケットデータの一例
【図２６】実施例８に係る検査ルール情報の一例
【図２７】従来技術における問題点を説明する図
【図２８】従来技術における他の問題点を説明する図
【発明を実施するための形態】
【００１８】
（第１の実施の形態）
本発明の第１の実施の形態に係る通信システムについて図面を参照して説明する。図１は本発明に係る通信システムの全体構成図、図２は第１の実施の形態に係る通信システムの動作を説明する図である。
【００１９】
本願発明において「パケット」とは、ＯＳＩ（Open Systems Interconnection）参照モデルの第３層であるネットワーク層におけるパケットであるものとする。すなわち、本願発明はネットワーク層におけるパケット転送を制御する手法に関するものであり、ＯＳＩ参照モデルのトランスポート層以上における処理に関するものである。
【００２０】
図１において、通信ノード１００は、本願発明の機能、プログラムが動作し、複数のネットワーク３００に接続する論理的又は物理的な通信インタフェースを複数保持し、ネットワークに接続し、受信ノード２００に対してパケットを生成して送信、又は他から受信したパケットを転送する装置である。すなわち、通信ノード１００は送信ノード及び中継ノードの何れか一方又は双方として機能する。通信ノード１００は、物理的な装置であっても、あるいは仮想的な装置であってもよい。接続するネットワーク３００は物理的には同じものであっても異なるものの組合せであってもよい。
【００２１】
受信ノード２００は、ネットワーク３００に接続し、送信ノード（図１では通信ノード１００又は送信ノード４００）から送信されるパケットを受信する装置である。受信ノード２００は、物理的な装置であっても、仮想的な装置であってもよい。
【００２２】
送信ノード４００は、ネットワーク５００に接続し、パケットを生成して送信する装置である。送信ノード４００は、物理的な装置であっても、仮想的な装置であってもよい。
【００２３】
通信ノード１００が専ら自身で生成したパケットのみを送信する装置の場合、ネットワーク構成は図１（ａ）に示すものとなる。一方、通信ノード１００が他の送信ノード４００で生成されたパケットを転送する装置の場合、ネットワーク構成は図１（ｂ）に示すものとなる。なお、図１（ｂ）において、送信ノード４００と通信ノード１００との間はノードをさらに多段構成とすることもできる。
【００２４】
本実施の形態は、通信ノード１００が単種のパケットを送信（転送）する場合の実施形態である。ここで単種のパケットとは、送信ノードと受信ノードとの間の上位レイヤ（例えばアプリケーション層）でのデータ通信が単一の種類のデータストリーム（パケット列）により行われる場合の、当該データストリームに係るパケットを意味する。例えば、ＲＴＰ（Real-time Transport Protocol）を用いたＨ．２６４コーデック映像データ送信に係るパケット、ＲＴＰを用いたＪＰＥＧ画像データ送信に係るパケット、動体検知結果などをメタデータとしてＲＴＰヘッダ中に含むＲＴＰデータ送信に係るパケットなどが挙げられる。通信システムの全体構成は、図１（ａ）及び（ｂ）のどちらであってもよい。本実施の形態では、図１（ａ）の構成を例にして説明する。
【００２５】
本実施の形態に係る通信システムは、図２に示すように、生成する（又は受信する）パケット列の内容を検査し、その検査結果に基づいてパケットの複製要否を決定し、複製が必要なパケットを複製して複数の通信インタフェースを介して送信するとともに、複製が不要なパケットは複数の通信インタフェースの中から何れか１つを介して送信するものである。
【００２６】
次に、図３を参照して通信ノード１００の構成について詳述する。図３は第１の実施の形態に係る通信ノードの機能ブロック図である。図３に示すように、通信ノード１００は、パケット生成部１０１と、パケット受信部１０２と、パケット検査部１０３と、検査ルール管理部１０４と、パケット処理部１０５と、送信ルール管理部１０６と、パケット送信部１０７と、複数（図３の例では３つ）の通信インタフェース１９０とを備えている。なお、通信ノード１００を構成する各部は、ハードウェアとして実装しても物理装置又は仮想装置にプログラムインストールして実装してもよいし、これらの実装技術を組み合わせてもよい。
【００２７】
パケット生成部１０１は、映像などの元データ、すなわち送信対象データをパケット化する機能ブロックである。このパケット生成部１０１は、通信ノード１００を送信ノードとして自らパケットを生成する場合に動作する。
【００２８】
パケット受信部１０２は、映像などの元データ、すなわち送信対象データをパケットとして外部の送信ノード４００から受け取る機能ブロックである。このパケット受信部１０２は、転送ノードとして受信したパケットに対して本発明の技術が利用される場合に動作する。
【００２９】
パケット検査部１０３は、パケット生成部１０１又はパケット受信部１０２からパケットを受け取り、検査ルール管理部１０４から取得したルール情報に基づいてパケットの内容を検査し、複製転送の要否を決定する機能ブロックである。
【００３０】
検査ルール管理部１０４は、パケット検査部１０３が行う検査内容をルール情報として保持する機能ブロックである。検査ルール管理部１０４は、外部のデータベースとネットワークを通じて接続しルール情報を取得する構成であってもよい。
【００３１】
パケット処理部１０５は、パケット検査部１０３の検査結果に基づいて、パケットの複製、識別子の付与処理、及び当該パケットの送信に用いる通信インタフェース１９０の決定を行う機能ブロックである。ここで、パケット処理部１０５は、後述する送信ルール情報に基づき、利用可能な通信インタフェース１９０の状態と送信しようとするパケットのサイズを参照し、パケットの送信に用いる通信インタフェース１９０の決定を行う。また、識別子の付与処理とは、パケットを送信する通信インタフェースごとに異なる識別子（サブフロー識別子）を設定し、かつそのサブフローごとのパケットロスの計測などを可能にするために、サブフロー単位のパケットのシーケンス番号を設定し、これを付加情報としてパケットヘッダに付与する処理である。
【００３２】
送信ルール管理部１０６は、パケット処理部１０５がパケットの複製、送信する通信インタフェース１９０の決定を行う際に用いるルール情報を保持する機能ブロックである。送信ルール管理部１０６は、外部のデータベースとネットワークを通じて接続しルール情報を取得する構成であってもよい。
【００３３】
パケット送信部１０７は、パケット処理部１０５が処理を行ったパケットを、通信インタフェース１９０を介して送信する機能ブロックである。
【００３４】
通信インタフェース１９０は、ネットワーク３００との接続インタフェースである。通信インタフェース１９０の規格としては種々のものを用いることができる。例えば、Ｅｔｈｅｒｎｅｔ（登録商標）、無線ＬＡＮ（Local Area Network）、ＧＳＭ（Global System for Mobile communications）、ＵＭＴＳ（Universal Mobile Telecommunications Service）、ＬＴＥ（Long Term Evolution）などが挙げられる。通信インタフェース１９０は、物理的なインタフェースであっても、あるいは論理的な通信インタフェースであってもよい。
【００３５】
パケット検査部１０３の動作について図４を参照して説明する。パケット検査部１０３は、起動すると検査ルール管理部１０４から検査ルールを取得し（ステップＳ１）、パケットを受け取ると（ステップＳ２）、受け取ったパケットを、取得した検査ルールに照合し（ステップＳ３）、マッチする場合は複製パケットとしてパケット処理部１０５に通知し（ステップＳ４）、マッチしない場合は非複製パケット（通常のパケット）としてパケット処理部１０５に通知する（ステップＳ５）。
【００３６】
パケット検査部１０３の詳細な動作について図５を参照して説明する。図５において図４と同じ動作については同一の符号を付した。本詳細動作は、検査ルールとして「パケットの欠損による影響が大きなものとして、同一グループの区切りパケットであるもの（映像フレームの末尾など）（ステップＳ３−１）、復号パラメタ（量子化テーブル、符号化テーブルなど）を含むもの（ステップＳ３−２）、被参照データ（映像コーデックにおけるキーフレーム、独立スライスセグメントなど）のパケットであるもの（ステップＳ３−３）、メタデータ（顔認識情報など）を有するもの（ステップＳ３−４）、を複製対象と判定する」というものを適用したものである。なお、複製対象と判定する基準は、上記の任意の一部であってもよい（図５は全てを用いる場合を例示）。また判定の順序は上記の例に限定されない。
【００３７】
パケット処理部１０５の動作について図６を参照して説明する。パケット処理部１０５は、起動すると送信ルール管理部１０６から送信ルール情報を取得し（ステップＳ１１）、パケット検査部１０３からパケット及び検査結果を受け取る（ステップＳ１２）。パケット処理部１０５は、取得した送信ルール情報に基づき、当該パケットの検査結果が複製パケットの場合、利用可能な通信インタフェース１９０のうちパケットの複製数分だけインタフェースを選択し（ステップＳ１３，Ｓ１４）、パケットを複製する（ステップＳ１５）。そして、パケットに付加情報を付与し（ステップＳ１６）、パケット送信部１０７を介して送信対象の通信インタフェース１９０へパケットを渡す（ステップＳ１７）。ここでステップＳ１６及びＳ１７の処理は、パケットの複製数分だけ実施する。当該パケットの検査結果が複製パケットではない場合、パケット処理部１０５は、利用可能な通信インタフェース１９０から送信に用いるインタフェースを一つ選択し（ステップＳ１３，Ｓ１８）、パケット送信部１０７を介して送信対象の通信インタフェース１９０へパケットを渡す（ステップＳ１７）。
【００３８】
このような構成により、本実施の形態に係る通信システムの動作シーケンスは図７に示すようなものとなる。なお、図７では、説明の簡単のため、通信ノード１００が元データを生成する場合についてのみ記載した。
【００３９】
［実施例１］
実施例１として、本実施の形態に係る通信ノード１００が、ＲＴＰを用いたＨ．２６４コーデック映像データに対して動作する場合のパケット検査部１０３の動作フロー例を図８に示す。また、本実施例１における検査ルール情報の例を図９に示す。図８において図４と同じ動作については同一の符号を付した。
【００４０】
本実施例１は、欠損すると受信側で大きな影響が出るパケットとして、フレーム末尾のデータを含むパケット、ＳＰＳ（Sequence Parameter Set）又はＰＰＳ（Picture Parameter Set）又はＩＤＲピクチャに属するデータを持つパケット、ＳＥＩ（Supplemental Enhancement Information）データを持つパケット、を複製パケットと判断する場合の例である。これらは何れもＲＦＣ６１８４で定義される設定値である。
【００４１】
具体的には、図８及び図９に示すように、パケット検査部１０３は、マーカビットが１のパケット（ステップＳ３−１１）、ＮＲＩが１１又は１０のパケット（ステップＳ３−１２）、ＮＡＬ  Ｕｎｉｔ  Ｔｙｐｅが６のパケット（ステップＳ３−１３）、を複製対象として判定する。
【００４２】
なお、図８及び図９において、Ｍは、ＲＴＰヘッダのマーカビットの値であり、ＲＴＰヘッダに設定されるものである。また、ＮＲＩは、ＮＡＬ  Ｒｅｆｅｒｅｎｃｅ  ＩＤＣの値であり、ＲＴＰペイロード中のＮＡＬ  Ｕｎｉｔヘッダに設定されるものである。また、ＮＡＬＵ＿ＴＹＰＥは、ＮＡＬ  Ｕｎｉｔ  Ｔｙｐｅの値であり、ＲＴＰペイロード中のＮＡＬ  Ｕｎｉｔヘッダに設定されるものである。
【００４３】
［実施例２］
実施例２として、本実施の形態に係る通信ノード１００が、ＲＴＰを用いたＪＰＥＧ画像データに対して動作する場合のパケット検査部１０３の動作フロー例を図１０に示す。また、本実施例２における検査ルール情報の例を図１１に示す。図１０において図４と同じ動作については同一の符号を付した。
【００４４】
本実施例２は、欠損すると受信側で大きな影響が出るパケットとして、フレーム末尾のデータを含むパケット、量子化テーブル・ハフマン符号テーブルを持つパケット、リスタートマーカを持つパケット、を複製パケットと判断する場合の例である。これらは何れもＲＦＣ２４８５で定義される値である。
【００４５】
具体的には、図１０及び図１１に示すように、パケット検査部１０３は、マーカビットが１のパケット（ステップＳ３−２１）、Ｔｙｐｅが６４以上１２７以下のパケット（ステップＳ３−２２）、Ｑが１２８以上２５５以下であり（ステップＳ３−２３）且つＦｒａｇｍｅｎｔ  Ｏｆｆｓｅｔが０のパケット（ステップＳ３−２４）、を複製対象として判定する。
【００４６】
なお、図１０及び図１１において、ＭはＲＴＰヘッダのマーカビットの値であり、ＲＴＰヘッダに設定されるものである。また、ＴＹＰＥは、ＲＴＰペイロード中のＪＰＥＧメインヘッダに設定されるものであり、ＪＰＥＧデータ種別を表す値である。また、Ｑは、ＲＴＰペイロード中のＪＰＥＧメインヘッダに設定される、量子化テーブル番号を表す値である。また、Ｆｒａｇｍｅｎｔ  Ｏｆｆｓｅｔは、ＲＴＰペイロード中のＪＰＥＧメインヘッダに設定される、同一フレーム内における当該ＲＴＰパケットのフレーム中の最初の画像データからのオフセット値である。
【００４７】
［実施例３］
実施例３として、本実施の形態に係る通信ノード１００が、動体検知（例えば顔検出）結果などをメタデータとしてＲＴＰヘッダ中に含むＲＴＰデータに対して動作する場合の、パケット検査部１０３の動作フロー例を図１２に示す。また、本実施例３における検査ルール情報の例を図１３に示す。図１２において図４と同じ動作については同一の符号を付した。
【００４８】
本実施例２は、欠損すると検知結果が失われて受信側で大きな影響が出るパケットとして、フレーム末尾のデータを含むパケット、ＲＴＰ拡張ヘッダに検知数が１以上であることを示す情報が設定されているパケット、を複製パケットと判断する場合の例である。
【００４９】
具体的には、図１２及び図１３に示すように、パケット検査部１０３は、マーカビットが１のパケット（ステップＳ３−３１）、Ｘが１（ステップＳ３−３２）且つ顔検出のＩＤ（ステップＳ３−３３）且つ検出数＞０（ステップＳ３−３４）のパケット、を複製対象として判定する。
【００５０】
なお、図１２及び図１３において、Ｍは、ＲＴＰヘッダのマーカビットの値であり、ＲＴＰヘッダに設定されるものである。また、Ｘは、ＲＴＰヘッダのエクステンションの値であり、ＲＴＰヘッダに設定されるものである。また、ＩＤは、ＲＴＰ拡張ヘッダ中に設定される検出結果の検出種別を示す識別子である。ここでは、値が０ｘ０００Ｆであり、顔検出結果が設定されていることを示す場合の例である。また、ｄｅｔｅｃｔｅｄＮｕｍは、検出された顔の数を示す値である。なお、上記ＩＤ及びｄｅｔｅｃｔｅｄＮｕｍは検出結果の表現形式の一つであり、特定の仕様又は技術によらない。
【００５１】
［実施例４］
実施例４として、前記送信ルール管理部１０６で管理する送信ルール情報の一例を図１４に示す。図１４において、Ｃｏｐｉｅｄは、パケットが複製パケット（Ｙｅｓ）か非複製パケット（Ｎｏ）かを示す。また、ＩＦは、利用可能な通信インタフェースの中から当該パケットの送信に利用するインタフェースの数を示す。また、Ｃｒｉｔｅｒｉａは、利用可能な通信インタフェースの中から当該パケットの送信に利用するインタフェースを選ぶ基準を示す。ＲＲはラウンドロビン方式、Ｂａｎｄｗｉｄｔｈ（ＤＥＳＣ）は通信インタフェースの帯域幅の降順をそれぞれ示し、複製しないパケットはラウンドロビンにより選択し、複製パケットは帯域幅の降順でＮ個のＩＦを選択する、という例を示す。
【００５２】
（第２の実施の形態）
本発明の第２の実施の形態に係る通信システムについて図面を参照して説明する。図１５は第２の実施の形態に係る通信システムの動作を説明する図である。ここで、第１の実施の形態との相違点について詳述する。なお、本実施の形態では、第１の実施の形態と同一の機能については同一の符号を付して、その説明は省略する。
【００５３】
本実施の形態は、通信ノード６００が異なる種類のパケットが混合して送信（転送）する場合の実施形態である。ここで異なる種類のパケットが混合している場合とは、送信ノードと受信ノードとの間の上位レイヤ（例えばアプリケーション層）でのデータ通信が複数の種類のデータストリーム（パケット列）に別れて行われる場合の、各データストリームに係るパケットが混合した状態で通信ノード６００において処理される場合を意味する。例えば、映像データと、映像中の動体検知結果などのメタデータが、同一パケットではなく、異なる種類のパケットとして別々にネットワークを流れる場合が挙げられる。通信システムの全体構成は、前述した図１（ａ）及び（ｂ）のどちらであってもよい。本実施の形態では、図１（ｂ）の構成を例にして説明する。
【００５４】
本実施の形態に係る通信システムは、図１５に示すように、複数の異なるパケット列を生成又は受信し、パケットの内容を記録し、パケットの内容を当該の記録に照合して検査し、その検査結果に基づいてパケットの複製要否を決定し、複製が必要なパケットを複製して複数の通信インタフェースを介して送信するとともに、複製が不要なパケットは複数の通信インタフェースの中から何れか１つを介して送信するものである。
【００５５】
次に、図１６を参照して通信ノード６００の構成について詳述する。図１６は第２の実施の形態に係る通信ノードの機能ブロック図である。図１６に示すように、通信ノード６００は、パケット生成部１０１と、パケット受信部１０２と、パケット検査部６０１と、検査ルール管理部１０４と、パケット処理部１０５と、送信ルール管理部１０６と、パケット送信部１０７と、複数（図１６の例では３つ）の通信インタフェース１９０とを備えている。以上の構成は、パケット検査部６０１の動作以外は第１の実施の形態と同様である。本実施の形態に係る通信ノード６００は、さらに、前処理部６０２と、パケットデータ保持部６０３と、パケットデータ保持ルール管理部６０４と、パケット連関情報管理部６０５とを備えている。なお、通信ノード６００を構成する各部は、ハードウェアとして実装しても物理装置又は仮想装置にプログラムインストールして実装してもよいし、これらの実装技術を組み合わせてもよい。
【００５６】
前処理部６０２は、パケット生成部１０１又はパケット受信部１０２から受け取ったパケットを、パケットデータ保持部６０３とパケット検査部６０１に渡す機能ブロックである。
【００５７】
パケットデータ保持部６０３は、前処理部６０２から受け取ったパケットを読み込み、パケット検査部６０１がパケット検査に使用するパケットデータを記録保持する機能ブロックである。
【００５８】
パケットデータ保持ルール管理部６０４は、パケットデータ保持部６０３が、受け取ったパケットの情報のうち何を保持すべきかをルールとして保持する機能ブロックである。外部のデータベースとネットワークを通じて接続しルール情報を取得する構成であってもよい。
【００５９】
パケット検査部６０１は、前処理部６０２から受け取ったパケットを読み込み、検査ルール及びパケットデータ保持部６０３が保持するパケットデータを使用してパケット複製要否を判断する機能ブロックである。
【００６０】
パケット連関情報管理部６０５は、パケット検査部６０１が受け取る異なる種類のパケットの間の連関情報を保持する機能ブロックである。外部のデータベースとネットワークを通じて接続しルール情報を取得する構成であってもよい。
【００６１】
前処理部６０２の動作について図１７を参照して説明する。前処理部６０２は、起動してパケットを受け取ると（ステップＳ２１）、当該パケットを、パケット検査部６０１とパケットデータ保持部６０３へそれぞれ並列して渡す（ステップＳ２２，Ｓ２３）。
【００６２】
パケットデータ保持部６０３の動作について図１８を参照して説明する。パケットデータ保持部６０３は、起動するとパケットデータ保持ルール管理部６０４から保持ルールを取得し（ステップＳ３１）、前処理部６０２からパケットを受け取り（ステップＳ３２）、保持ルールに合致するパケットデータを保持する（ステップＳ３３）。
【００６３】
パケットデータ保持部６０３の詳細動作について図１９を参照して説明する。図１９において図１８と同じ動作については同一の符号を付した。本詳細動作は、パケットデータ保持ルール管理部６０４で管理するパケットデータ保持ルールとして、パケット種別ごとに保持条件を定義するとともに、当該保持条件に一致したパケットについて、そのパケットが持つ時刻情報，シーケンス番号情報，フラグ情報，測定量情報の保持要否及び保持する場合の保持形式を定義しておく。ここで、時刻情報とはパケットのヘッダまたはペイロードに設定される、そのパケットの生成時刻、送信時刻または転送時刻を表す値を意味する。例えばＲＴＰパケットでは、ヘッダに設定されるＲＴＰタイムスタンプの値が該当する。またシーケンス番号情報とはパケットのヘッダまたはペイロードに設定される、複数パケットの間の順序性を示す値を意味する。例えばＲＴＰパケットでは、ヘッダに設定されるＲＴＰシーケンス番号の値が該当する。またフラグ情報とはパケットのヘッダまたはペイロードに設定される、機能の有無、処理結果の成否、状態の良否などの二値を示す値を意味する。例えばＲＴＰパケットでは、ヘッダに設定されるＲＴＰマーカビットの値が該当する。また、測定量情報とはパケットのヘッダまたはペイロードに設定される、速度、加速度、温度、湿度、光度などの物理量、工業量その他の量を示す値を意味する。例えば、物体検知機能を有するカメラが送信するＲＴＰパケットのペイロードに設定される、撮像画像中に存在する物体の種別を解析した結果の確からしさ（尤度）を０から１までの実数値で表現した値が該当する。
【００６４】
パケットデータ保持部６０３は、前処理部６０２から受け取ったパケットが前記保持条件に一致する場合（ステップＳ３３−１）、前記時刻情報，シーケンス番号情報，フラグ情報，測定量情報の保持が必要ならば、それぞれを保持形式に従ってパケットデータとして保持する（ステップＳ３３−２，…，Ｓ３３−９）。
【００６５】
パケット検査部６０１の動作について図２０を参照して説明する。パケット検査部６０１は、起動すると検査ルール管理部１０４から検査ルールを取得し（ステップＳ４１）、パケット連関情報管理部６０５からパケット連関情報を取得する（ステップＳ４２）。次に、パケット検査部６０１は、前処理部６０２からパケットを受け取ると（ステップＳ４３）、受け取ったパケット単体で検査ルールにマッチする場合は複製要としてパケット処理部１０５に通知する（ステップＳ４４，Ｓ４８）。
【００６６】
マッチしない場合、パケット検査部６０１は、パケット連関情報を基づき受取パケットとは異なる種別のパケットの保持済パケットデータを取得対象として決定し（ステップＳ４５）、当該パケットデータをパケットデータ保持部６０３から取得する（ステップＳ４６）。そしてパケット検査部６０１は、当該パケットデータと受取パケットの対応する情報がマッチするかどうかをチェックし（ステップＳ４７）、マッチする場合は複製要としてパケット処理部１０５に通知する（ステップＳ４８）。一方、マッチしない場合は非複製パケット（通常のパケット）としてパケット処理部１０５に通知する（ステップＳ４９）。
【００６７】
パケット検査部６０１の詳細な動作について図２１を参照して説明する。図２１において図２０と同じ動作については同一の符号を付した。本詳細動作は、検査するパケットと、パケット連関情報に基づいて取得するパケットデータとの間で、時刻情報，シーケンス番号情報，フラグ情報，測定量情報の何れか又はその組合せについて、検査ルールとして保持する指定条件に合致するか否かを判定し、合致する場合に複製要とする（ステップＳ４７−１，…Ｓ４７−４）。
【００６８】
なお、図２１の例では、時刻情報，シーケンス番号情報，フラグ情報，測定量情報の全てを判定に利用する例を記載しているが、一部であってもよく、判定の順番も限定しない。また、図２１の例では、各指定条件との合致判定をＡＮＤ条件で最終的な複製要否を判定する例を記載しているが、ＯＲ条件やＡＮＤ条件とＯＲ条件の組合せを含むその他の判定論理を用いてもよく、特定の判定論理に限定しない。
【００６９】
このような構成により、本実施の形態に係る通信システムの動作シーケンスは図２２に示すようなものとなる。なお、図２２では、説明の簡単のため、上記第１の実施の形態と同様の箇所は一部記載を省略した。
【００７０】
［実施例５］
実施例５として、前記パケット連関情報管理部６０５で管理するパケット連関情報の一例を図２３に示す。図２３は、パケット種別Ａとパケット種別Ｂが連関関係にあることを示す場合の一例である。このようなパケット連関情報により、パケット種別Ａを受信した場合、パケット種別Ｂのパケットデータを取得して検査に利用する必要があること、あるいはその反対に、パケット種別Ｂを受信した場合、パケット種別Ａのパケットデータを取得して検査に利用する必要があることが分かる。
【００７１】
［実施例６］
実施例６として、前記パケットデータ保持ルール管理部６０４で管理するパケットデータ保持ルールの一例を図２４に示す。図２４は、パケット種別Ａ（Ｈ．２６４／ＲＴＰの映像パケット）については、ＲＴＰマーカビットが１のパケットについてはフラグ情報としてＭ＝１を、ＲＴＰマーカビットが０だがＮＲＩが１０又は１１の何れかであるパケットについてはフラグ情報としてＭ＝０をそれぞれ保持し、時刻情報としてはいずれもＲＴＰタイムスタンプ値を、シーケンス番号情報としてはいずれもＲＴＰシーケンス番号の値を、測定量情報としてはいずれもＮＲＩの値を保持する、という場合の一例である。
【００７２】
一方、パケット種別Ｂ（ＸＭＬ形式の物体検知メタデータ）については、何かしらの物体が検知されたことを示す（ＸＭＬのｔｔ：Ｏｂｊｅｃｔ要素が存在する）パケットについてのみ、時刻情報とＸＭＬのｔｔ：Ｆｒａｍｅ要素のＵｔｃＴｉｍｅアトリビュートの値を、測定量情報としてＸＭＬのｔｔ：Ｔｙｐｅ要素の値（検知された物体の一般名称）及びｔｔ：Ｌｉｋｅｌｉｈｏｏｄの値（検知の尤度）を存在する分だけ保持し、シーケンス番号情報及びフラグ情報は保持しない、という場合の一例である。
【００７３】
［実施例７］
実施例７として、前記パケットデータ保持部６０３で保持するパケットデータの一例を図２５に示す。図２５は、前記実施例６で例示したパケットデータ保持ルールに基づき保持されたパケットデータの例を示す。パケット種別Ｂ（物体検知メタデータ）については、例えばキーフレームの又は復号パラメタを含む（ＮＲＩが１０以上）重要な映像パケットと等しい（又は近しい）時刻情報を持つメタデータパケットを連関的に重要とみなし複製要と判断することが可能となる。
【００７４】
また同様に、パケット種別Ａ（映像）については、例えば人間が一定の尤度以上で検知されたことを示すメタデータと等しい（又は近しい）時刻情報を持つ映像パケットを連関的に重要とみなし複製要と判断することが可能となる。
【００７５】
［実施例８］
実施例８として、図２１を参照して上述したパケット検査部６０１の詳細動作の場合における検査ルール情報の例を図２６に示す。この検査ルール情報は、まず、パケット単体の検査ルールとして、図１３を参照して上述した実施例３と同様の検査ルールを持つ。そして、そのパケット単体の検査ルールに合致しなかった場合に実施するパケット種別Ｂ（物体検知メタデータ）のパケットデータとの突合による検査ルールとして、人物（Ｈｕｍａｎ）が尤度（Ｌｉｋｅｌｉｈｏｏｄ）０．８以上で検知されたことを示す種別Ｂのメタデータと誤差Ｅ以内に収まる時刻情報を持つ種別Ａのパケットを複製要と判断する、という場合の一例である。
【００７６】
このような検査ルール情報により、人物が一定以上の尤度で検知された映像フレームに一致するあるいは近しい映像フレームのパケットを重要と判断して複製転送することができる。
【００７７】
以上、本発明の実施の形態及び実施例について詳述したが、本発明はこれに限定されるものではない。例えば、送信ノード・受信ノード間の上位レイヤにおけるデータ通信のプロトコルやアプリケーションはその一例にすぎず、他のプロトコルやアプリケーションであっても本発明を適用できる。また、上記実施の形態及び実施例において詳述した検査ルール情報、送信ルール情報、パケットデータ保持ルール、パケット連関情報のデータ構造やパラメタ等はその一例にすぎず、送信ノード・受信ノード間の上位レイヤにおけるデータ通信のプロトコルやアプリケーションに応じて適宜選択することができる。
【符号の説明】
【００７８】
１００，６００…通信ノード
１０１…パケット受信部
１０２…パケット受信部
１０３，６０１…パケット検査部
１０４…検査ルール管理部
１０５…パケット処理部
１０６…送信ルール管理部
１０７…パケット送信部
１９０…通信インタフェース
２００…受信ノード
３００，５００…ネットワーク
４００…送信ノード
６０２…前処理部
６０３…パケットデータ保持部
６０４…パケットデータ保持ルール管理部
６０５…パケット連関情報管理部
【図１】
2019029688.tif 000003
【図２】
2019029688.tif 000004
【図３】
2019029688.tif 000005
【図４】
2019029688.tif 000006
【図５】
2019029688.tif 000007
【図６】
2019029688.tif 000008
【図７】
2019029688.tif 000009
【図８】
2019029688.tif 000010
【図９】
2019029688.tif 000011
【図１０】
2019029688.tif 000012
【図１１】
2019029688.tif 000013
【図１２】
2019029688.tif 000014
【図１３】
2019029688.tif 000015
【図１４】
2019029688.tif 000016
【図１５】
2019029688.tif 000017
【図１６】
2019029688.tif 000018
【図１７】
2019029688.tif 000019
【図１８】
2019029688.tif 000020
【図１９】
2019029688.tif 000021
【図２０】
2019029688.tif 000022
【図２１】
2019029688.tif 000023
【図２２】
2019029688.tif 000024
【図２３】
2019029688.tif 000025
【図２４】
2019029688.tif 000026
【図２５】
2019029688.tif 000027
【図２６】
2019029688.tif 000028
【図２７】
2019029688.tif 000029
【図２８】
2019029688.tif 000030