(57)【要約】【課題】ソースとシンクとの間でプロトコル変換が必要となる場合に、適切なデータ長を推定することにより、メモリの消費量の削減、低遅延及びパケットのペーシングを実現することを目的とする。【解決手段】ソースからシンクにデータを転送するデータ転送装置は、データをフラグメント化して送信する第１のプロトコルを用いて、前記ソースから送信されるデータのフラグメントを受信する第１プロトコル関連機能部と、前記受信したフラグメントのメタ情報に基づいて、前記ソースから送信されるデータのデータ長を推定し、当該推定されたデータ長を示すヘッダ情報を出力するヘッダ情報出力機能部と、データ長を指定してデータを送信する第２のプロトコルを用いて、前記出力されたヘッダ情報を、前記ソースから送信されるデータの中の先頭のフラグメントに付与して前記シンクに送信する第２プロトコル関連機能部とを有する。【選択図】図３
2019029728.tif 000002
【特許請求の範囲】
【請求項１】
ソースからシンクにデータを転送するデータ転送装置であって、
データをフラグメント化して送信する第１のプロトコルを用いて、前記ソースから送信されるデータのフラグメントを受信する第１プロトコル関連機能部と、
前記受信したフラグメントのメタ情報に基づいて、前記ソースから送信されるデータのデータ長を推定し、当該推定されたデータ長を示すヘッダ情報を出力するヘッダ情報出力機能部と、
データ長を指定してデータを送信する第２のプロトコルを用いて、前記出力されたヘッダ情報を、前記ソースから送信されるデータの中の先頭のフラグメントに付与して前記シンクに送信する第２プロトコル関連機能部と、
を有するデータ転送装置。
【請求項２】
前記ヘッダ情報出力機能部は、前記ソースから送信されるデータを転送するために十分な長さのデータ長を推定し、
前記第２プロトコル関連機能部は、前記推定されたデータ長に満たない部分を所定のバイト列で埋める、請求項１に記載のデータ転送装置。
【請求項３】
前記ヘッダ情報出力機能部は、前記ソースから過去に送信されたデータのデータ長の平均値及び分散に基づいて、前記ソースから送信されるデータのデータ長を推定する、請求項１又は２に記載のデータ転送装置。
【請求項４】
前記ソースから送信されるデータのデータ長に影響を与える外部情報を取得する外部情報取得部を更に有し、
前記ヘッダ情報出力機能部は、前記外部情報に更に基づいて、前記ソースから送信されるデータのデータ長を推定する、請求項１乃至３のうちいずれか１項に記載のデータ転送装置。
【請求項５】
前記ヘッダ情報出力機能部は、学習データを用いて構築されたモデルを用いて、前記ソースから送信されるデータのデータ長を推定する、請求項１乃至４のうちいずれか１項に記載のデータ転送装置。
【請求項６】
ソースからシンクにデータを転送するデータ転送装置におけるデータ転送方法であって、
データをフラグメント化して送信する第１のプロトコルを用いて、前記ソースから送信されるデータのフラグメントを受信するステップと、
前記受信したフラグメントのメタ情報に基づいて、前記ソースから送信されるデータのデータ長を推定し、当該推定されたデータ長を示すヘッダ情報を出力するステップと、
データ長を指定してデータを送信する第２のプロトコルを用いて、前記出力されたヘッダ情報を、前記ソースから送信されるデータの中の先頭のフラグメントに付与して前記シンクに送信するステップと、
を有するデータ転送方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、データ転送装置及びデータ転送方法に関する。
【背景技術】
【０００２】
デバイスの高度化によって、音声や映像等のデータストリームを送信する利用形態が増加している。
【０００３】
音声や映像等のデータストリームをリアルタイムに送信するためのプロトコルやフレームワークとして、RTP（Real Time Protocol）、RTSP（Real Time Streaming Protocol）、WebRTC（Web Real-Time Communication）等が存在する。このようなプロトコルでは、データはフラグメント化されて送信される。
【０００４】
一方、利便性の観点から、HTTP（Hypertext Transfer Protocol）、MQTT（Message Queue Telemetry Transport）、ROS（Robot Operating System）等のプロトコルやフレームワークも用いられている。
【０００５】
例えば、HTTP1.1では、ストリーム的にデータを送信するために、Content-type:multipartを用いることができる。図１に、HTTP1.1においてContent-type:multipartを用いる場合のシーケンスを示す。この方式では、クライアントからの１つのリクエストに対して、サーバは複数のリソース（例えば、複数の映像フレーム）を特定のバウンダリー（boundary）を用いて表現し、各バウンダリーの最初にデータ長（Content-length）を指定して複数のリソースのデータを連続的に送信することができる（非特許文献１及び２参照）。
【先行技術文献】
【非特許文献】
【０００６】
【非特許文献１】RFC 1341, "MIME (Multipurpose Internet Mail Extensions): Mechanism for Specifying and Describing the Format of Internet Message Bodies", June 1992
【非特許文献２】RFC 2616, "Hypertext Transfer Protocol - HTTP 1.1", June 1999
【発明の概要】
【発明が解決しようとする課題】
【０００７】
今後、データストリームを伴うデバイスが普及し、データストリームの利用目的の多様化が加速することが期待される。データストリームを送信するソースにおいては、RTSP、RTP、WebRTC等のようなリアルタイム性に優れたプロトコルやフレームワークが用いられることが想定される。一方、データストリームを受信するシンクにおいては、HTTP、MQTT、ROS等のような利便性に優れたプロトコルやフレームワークが用いられることが想定される。このような利用形態では、ソースとシンクとの間にプロトコル変換を行う装置が必要となる。
【０００８】
図２は、ソースとシンクとの間でプロトコル変換が必要となる例を示す図である。例えば、ソースにおいてRTP等のようなプロトコルが用いられ、映像フレーム等のデータを細かくフラグメント化して送信する場合、フラグメント毎にヘッダが付与され、フラグメント長が与えられる。例えば、シンクにおいてHTTP等のようなプロトコルが用いられる場合、ストリーム的にデータを送信するためには、最初にデータ長を指定する必要がある。しかし、データ長を指定するためには、ソースとシンクとの間の装置において、ソースからのデータをメモリにバッファリングしてデータ全体の長さを決定する必要がある。
【０００９】
その結果、ソースとシンクとの間の装置において、メモリの使用量が増加し、バッファ分の遅延が増加し、ピーキーなトラヒック発生を誘因する可能性がある。
【００１０】
本発明は、ソースとシンクとの間でプロトコル変換が必要となる場合に、適切なデータ長を推定することにより、メモリの消費量の削減、低遅延及びパケットのペーシングを実現することを目的とする。
【課題を解決するための手段】
【００１１】
本発明の一形態に係るデータ転送装置は、
ソースからシンクにデータを転送するデータ転送装置であって、
データをフラグメント化して送信する第１のプロトコルを用いて、前記ソースから送信されるデータのフラグメントを受信する第１プロトコル関連機能部と、
前記受信したフラグメントのメタ情報に基づいて、前記ソースから送信されるデータのデータ長を推定し、当該推定されたデータ長を示すヘッダ情報を出力するヘッダ情報出力機能部と、
データ長を指定してデータを送信する第２のプロトコルを用いて、前記出力されたヘッダ情報を、前記ソースから送信されるデータの中の先頭のフラグメントに付与して前記シンクに送信する第２プロトコル関連機能部と、
を有することを特徴とする。
【００１２】
また、本発明の一形態に係るデータ転送方法は、
ソースからシンクにデータを転送するデータ転送装置におけるデータ転送方法であって、
データをフラグメント化して送信する第１のプロトコルを用いて、前記ソースから送信されるデータのフラグメントを受信するステップと、
前記受信したフラグメントのメタ情報に基づいて、前記ソースから送信されるデータのデータ長を推定し、当該推定されたデータ長を示すヘッダ情報を出力するステップと、
データ長を指定してデータを送信する第２のプロトコルを用いて、前記出力されたヘッダ情報を、前記ソースから送信されるデータの中の先頭のフラグメントに付与して前記シンクに送信するステップと、
を有することを特徴とする。
【発明の効果】
【００１３】
本発明によれば、ソースとシンクとの間でプロトコル変換が必要となる場合に、適切なデータ長を推定することにより、メモリの消費量の削減、低遅延及びパケットのペーシングを実現することが可能になる。
【図面の簡単な説明】
【００１４】
【図１】HTTP1.1においてContent-type:multipartを用いる場合のシーケンスである。
【図２】ソースとシンクとの間でプロトコル変換が必要となる例を示す図である。
【図３】本発明の実施例に係るデータ転送装置の概略図である。
【図４】本発明の実施例に係るデータ転送装置の機能ブロック図である。
【図５】本発明の実施例に係るデータ転送装置の処理を示すシーケンス図である。
【図６】ヘッダ情報出力機能部における処理を示すフローチャートである。
【図７】本発明の実施例に係るデータ転送装置のハードウェア構成例を示す図である。
【発明を実施するための形態】
【００１５】
以下、図面を参照して本発明の実施例について説明する。
【００１６】
図３は、本発明の実施例に係るデータ転送装置１００の概略図である。
【００１７】
データ転送装置１００は、ソースとシンクとの間に位置し、ソースからシンクにデータを転送するネットワーク装置である。ソースに対してはRTP等のプロトコルAを用い、シンクに対してはHTTP等のプロトコルBを用いる。なお、プロトコルA及びプロトコルBの組み合わせはRTP及びHTTPに限定されず、他のプロトコルの組み合わせが用いられてもよい。プロトコルAは、映像フレーム等のデータをフラグメント化して送信するプロトコルであり、フラグメント毎にメタ情報を含むヘッダが付与され、フラグメント長が与えられる。プロトコルBは、データ長を指定してデータを送信するプロトコルであり、指定したデータ長のデータが連続的に送信される。
【００１８】
データ転送装置１００は、プロトコルAを用いてソースから受信したフラグメントのメタ情報に基づいて、データ長を推定する。メタ情報には、フラグメントの属性情報が含まれており、例えば、ソースがRTPを用いて映像フレームを送信する場合、データ転送装置１００は、メタ情報に含まれるタイムスタンプ及びシーケンス番号から、受信したフラグメントがどの映像フレームの何番目のフラグメントであるかを認識することができる。また、メタ情報からフラグメント長を認識することができる。例えば、データ転送装置１００は、映像フレーム毎にデータ長の統計値を求め、ソースから送信されるデータを転送するために十分な長さのデータ長を推定する。
【００１９】
データ転送装置１００は、推定したデータ長を先頭のフラグメントに付与してシンクに送信する。なお、データを転送するために十分な長さのデータ長が推定されているため、推定されたデータ長に満たない部分が発生する。この部分は、所定のバイト列で埋めてもよい。
【００２０】
次に、データ転送装置１００の具体的な構成及び動作について説明する。図４は、本発明の実施例に係るデータ転送装置１００の機能ブロック図であり、図５は、本発明の実施例に係るデータ転送装置１００の処理を示すシーケンス図である。
【００２１】
図４に示すように、データ転送装置１００は、プロトコルAを用いてソースと通信するためのプロトコルA関連機能部１０１と、プロトコルBを用いてシンクと通信するためのプロトコルB関連機能部１０２と、ソースからのデータをシンクに転送するための転送機能部１０３と、ソースからのデータをシンクに転送するときのヘッダ情報を出力するためのヘッダ情報出力機能部１０４とを含む。また、データ転送装置１００は、データ長に影響を与える外部情報を取得するための外部情報取得部１０５を更に含んでもよい。なお、図４は単なるデータ転送装置１００の構成の一例であり、例えば、転送機能部１０３とヘッダ情報出力機能部１０４とが同じ機能部として実現されてもよい。
【００２２】
まず、プロトコルA関連機能部１０１は、プロトコルAを用いて、ソースから送信されるデータのフラグメントを受信する（Ｓ１０１）。このフラグメントには、どのデータの何番目のフラグメントであるかを識別するためのメタ情報が付与されている。プロトコルA関連機能部１０１は、フラグメントに付与されたプロトコルAのヘッダ情報等を除去し、フラグメントと、データ長の推定に使用されるフラグメントのメタ情報とを転送機能部１０３に送信する（Ｓ１０２）。転送機能部１０３は、フラグメントのメタ情報をヘッダ情報出力機能部１０４に送信する（Ｓ１０３）。
【００２３】
ヘッダ情報出力機能部１０４は、フラグメントのメタ情報に基づいて、ソースから送信されるデータのデータ長を推定し、推定されたデータ長を示すヘッダ情報を出力する。ヘッダ情報は、転送機能部１０３に戻される（Ｓ１０４）。ヘッダ情報出力機能部１０４における処理について以下に説明する。
【００２４】
図６は、ヘッダ情報出力機能部１０４における処理を示すフローチャートである。ヘッダ情報出力機能部１０４は、フラグメントのメタ情報を受信すると、フラグメントのメタ情報から、データの中の何番目のフラグメントであるかを出力する関数fを用いて、フラグメント番号を求める（Ｓ２０１）。ただし、データの中の先頭のフラグメントのフラグメント番号を0とする。例えば、RTPがプロトコルAとして用いられる場合、タイムスタンプ及びシーケンス番号から、フラグメントが属するデータと、そのデータの中のフラグメント番号を求めることができる。
【００２５】
フラグメント番号が0でない場合（Ｓ２０２：ＹＥＳ）、すなわち、先頭のフラグメントでない場合、ヘッダ情報にデータ長を付与する必要はないため、ヘッダ情報=Nullとする（Ｓ２０３）。
【００２６】
フラグメント番号が0である場合（Ｓ２０２：ＮＯ）、すなわち、先頭のフラグメントである場合、ヘッダ情報出力機能部１０４は、フラグメントのメタ情報、外部情報等を入力として、付加すべきヘッダ情報を出力するための関数gを用いて、ヘッダ情報を求める（Ｓ２０４）。上記のように、ヘッダ情報出力機能部１０４は、フラグメントのメタ情報に基づいて、受信したフラグメントがどの映像フレームの何番目のフラグメントであるかを認識することができ、フラグメント長を認識することができる。ヘッダ情報出力機能部１０４は、ソースから過去に送信されたフラグメントのフラグメント長から、データ長の統計値を求め、ソースから送信されるデータを転送するために十分な長さのデータ長を推定する。例えば、ソースから過去に送信されたN個のデータのデータ長の平均値及び分散を求め、平均値＋分散をデータ長として推定してもよい。
【００２７】
また、データ長の推定のために、外部情報取得部１０５により取得された、データ長に影響を与える外部情報が更に用いられてもよく、時刻が更に用いられてもよい。例えば、ソースが監視カメラである場合、昼間と夜間ではデータの圧縮率が異なり、データ長が変化する可能性がある。このようなデータ長に影響を与える外部情報又は時刻が与えられる場合、データ長の推定精度を高めることができる。
【００２８】
また、データ長の推定のために、ヘッダ情報出力機能部１０４は、機械学習を用いることも可能である。機械学習では、過去のデータ長、外部情報、時刻等の学習データを用いて予めモデルを構築しておき、フラグメントを受信する毎に、フラグメントのメタ情報、外部情報、時刻等を入力してデータ長を推定することができる。
【００２９】
再び図５を参照すると、ヘッダ情報出力機能部１０４は、上記のように推定されたデータ長を示すヘッダ情報を転送機能部１０３に送信する（Ｓ１０４）。ヘッダ情報出力機能部１０４は、ヘッダ情報及びフラグメントをプロトコルB関連機能部１０２に送信する（Ｓ１０５）。なお、先頭のフラグメントである場合、ヘッダ情報がプロトコルB関連機能部１０２に送信されるが、先頭のフラグメントでない場合、ヘッダ情報はNullとなっているため、ヘッダ情報はプロトコルB関連機能部１０２に送信されない。プロトコルB関連機能部１０２は、データ長を示すヘッダ情報を、ソースから送信されるデータの中の先頭のフラグメントに付与してシンクに送信する（Ｓ１０６）。また、プロトコルB関連機能部１０２は、推定されたデータ長に満たない部分を所定のバイト列で埋めてシンクに送信する。
【００３０】
このように、シンクにおいてプロトコルAが用いられない場合であっても、シンクにおいてプロトコルAのリアルタイム性を享受することができる。
【００３１】
＜本発明の実施例の効果＞
本発明の実施例によれば、データ転送装置１００は、ソースから受信したデータをシンクに転送するときに、データ長を推定した上で、必要十分なデータ長とするために、少し大きめにデータ長を決定する。そして、データ長を指定してストリーム的にシンクに送信する。このため、ソースから受信したデータをほぼリアルタイムにシンクに転送することができ、データ転送装置１００におけるメモリの消費量を削減することができ、低遅延及びパケットのペーシングを実現することが可能になる。
【００３２】
また、データ長に影響を与える外部情報又は時刻が与えられる場合、データ長の推定精度を高めることができる。
【００３３】
＜ハードウェア構成例＞
図７に、本発明の実施例に係るデータ転送装置１００のハードウェア構成例を示す。データ転送装置１００は、ＣＰＵ（Central Processing Unit）１５１等のプロセッサ、ＲＡＭ（Random Access Memory）やＲＯＭ（Read Only Memory）等のメモリ装置１５２、ハードディスク等の記憶装置１５３等から構成されたコンピュータでもよい。例えば、データ転送装置１００の機能及び処理は、記憶装置１５３又はメモリ装置１５２に格納されているデータやプログラムをＣＰＵ１５１が実行することによって実現される。また、データ転送装置１００へのデータの入力は、入出力インタフェース装置１５４から行われ、データ転送装置１００からのデータの出力は、入出力インタフェース装置１５４から行われてもよい。
【００３４】
＜補足＞
説明の便宜上、本発明の実施例に係るデータ転送装置１００は機能的なブロック図を用いて説明しているが、本発明の実施例に係るデータ転送装置１００は、ハードウェア、ソフトウェア又はそれらの組み合わせで実現されてもよい。例えば、本発明の実施例は、コンピュータに対して本発明の実施例に係るデータ転送装置１００の機能を実現させるプログラム、コンピュータに対して本発明の実施例に係る方法の各手順を実行させるプログラム等により、実現されてもよい。また、各機能部が必要に応じて組み合わせて使用されてもよい。また、本発明の実施例に係る方法は、実施例に示す順序と異なる順序で実施されてもよい。
【００３５】
以上、ソースとシンクとの間でプロトコル変換が必要となる場合に、適切なデータ長を推定することにより、メモリの消費量の削減、低遅延及びパケットのペーシングを実現するための手法について説明したが、本発明は、上記の実施例に限定されることなく、特許請求の範囲内において、種々の変更・応用が可能である。
【符号の説明】
【００３６】
１００  データ転送装置
１０１  プロトコルA関連機能部
１０２  プロトコルB関連機能部
１０３  転送機能部
１０４  ヘッダ情報出力機能部
１０５  外部情報取得部
【図１】
2019029728.tif 000003
【図２】
2019029728.tif 000004
【図３】
2019029728.tif 000005
【図４】
2019029728.tif 000006
【図５】
2019029728.tif 000007
【図６】
2019029728.tif 000008
【図７】
2019029728.tif 000009