(57)【要約】  低遅延な音声通話を実現し、かつ音声データの劣化を防止できる送信装置、受信装置および中継装置を提供する。送信装置は、分割されたデータを１つまたは複数のＴＣＰコネクションに振り分けるデータ振分手段１と、通信ネットワークの状態を監視するネットワーク状態監視手段２と、ネットワーク状態監視手段２の監視結果である通信ネットワークの状態に応じてデータの分割方法および分割されたデータの送信方法を変更する送信方法決定手段３とを備える。
2014207978.tif 000002
【特許請求の範囲】
【請求項１】
送信対象のデータを分割して受信装置に送信する送信装置であって、
分割されたデータを１つまたは複数のＴＣＰコネクションに振り分けるデータ振分手段と、
通信ネットワークの状態を監視するネットワーク状態監視手段と、
前記ネットワーク状態監視手段の監視結果である前記通信ネットワークの状態に応じて前記データの分割方法および前記分割されたデータの送信方法を変更する送信方法決定手段とを備える
ことを特徴とする送信装置。
【請求項２】
送信方法決定手段は、通信ネットワークの状態に基づいてデータを分割する単位を変更する
請求項１記載の送信装置。
【請求項３】
データ振分手段は、分割されたデータを複数のＴＣＰコネクションに振り分け、
送信方法決定手段は、通信ネットワークの状態に基づいて前記ＴＣＰコネクションの数を変更する
請求項１または請求項２記載の送信装置。
【請求項４】
データ振分手段は、同じ分割されたデータを複数のＴＣＰコネクションに振り分ける
請求項３記載の送信装置。
【請求項５】
データ振分手段は、複数パケットから計算した冗長データをＴＣＰコネクションに振り分ける
請求項３または請求項４記載の送信装置。
【請求項６】
送信対象のデータが分割されて１つまたは複数のＴＣＰコネクションで送信装置から送信された分割データを受信する受信装置であって、
受信した分割データを合成するデータ合成手段と、
通信ネットワークの状態を監視するネットワーク状態監視手段と、
前記ネットワーク状態監視手段の監視結果である前記通信ネットワークの状態に応じて前記分割データの受信方法および前記分割データの合成方法を変更する受信方法決定手段とを備える
ことを特徴とする受信装置。
【請求項７】
データ合成手段は、所定の遅延時間内に受信できなかった分割データを損失データとして扱い、
受信方法決定手段は、通信ネットワークの状態に基づいて前記所定の遅延時間を変更する
請求項６記載の受信装置。
【請求項８】
受信方法決定手段は、通信ネットワークの状態に基づいてＴＣＰコネクションの数を変更する
請求項６または請求項７記載の受信装置。
【請求項９】
データ合成手段は、損失データとして扱った分割データに対してデータ補間を行う
請求項７記載の受信装置。
【請求項１０】
送信対象のデータが分割されて１つまたは複数のＴＣＰコネクションで送信装置から送信された分割データを受信し、データを受信装置に送信する中継装置であって、
受信した分割データを合成するデータ合成手段と、
通信ネットワークの状態を監視するネットワーク状態監視手段と、
前記ネットワーク状態監視手段の監視結果である前記通信ネットワークの状態に応じて前記分割データの受信方法および前記分割データの合成方法を変更する受信方法決定手段とを備える
ことを特徴とする中継装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ）コネクションを利用してリアルタイムメディアデータを低遅延かつ高品質に送受信する送信装置、受信装置および中継装置に関する。
【背景技術】
【０００２】
ＩＰ（Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）ネットワークを利用して音声データを送受信するＩＰ電話が普及している。インターネットやモバイルインターネットの普及およびそれらの通信の高速化に伴い、品質が保証されていないインターネットやモバイルインターネットを経由したＩＰ電話も利用されている。【０００３】
音声通話では、相手とリアルタイムに通話できることが重要である。しかし、ＩＰ電話では一般的な回線交換式の電話に比べて音声遅延が大きく、音声通話品質が悪い。安定したＩＰ電話通信サービス提供のため、総務省は、ＩＰ電話サービス事業者のサービス基準を定めている。そのサービス基準において、例えば、ＩＰ電話におけるエンド−エンドの音声遅延時間の目安は、４００ミリ秒未満である。【０００４】
インターネットやモバイルネットワークを利用したＩＰ電話では上記の品質基準が適用されず、音声遅延時間が４００ミリ秒未満の音声通話が実現されないことも多い。しかし、インターネットやモバイルネットワークを利用したＩＰ電話においても品質が維持されるためには、できるだけ低遅延の音声通話が実現されることが重要である。【０００５】
音声データを低遅延で相手に伝送するために、多くのＩＰ電話は、ＵＤＰ（Ｕｓｅｒ  Ｄａｔａｇｒａｍ  Ｐｒｏｔｏｃｏｌ）上のＲＴＰ（Ｒｅａｌｔｉｍｅ  Ｔｒａｎｓｐｏｒｔ  Ｐｒｏｔｏｃｏｌ）を利用して音声データの伝送をしている。【０００６】
ＵＤＰを使用する場合、データが相手に到達することは保証されない。その代わりに、低遅延なデータ伝送が実現される。よって、ＵＤＰは、リアルタイム性を要求するマルチメディア通信に利用される。しかし、ＵＤＰによるデータ転送には、ＮＡＴ（Ｎｅｔｗｏｒｋ  Ａｄｄｒｅｓｓ  Ｔｒａｎｓｌａｔｉｏｎ）やファイアウォールを通過できないという欠点がある。【０００７】
ＮＡＴは、グローバルＩＰアドレスを持たない端末をインターネットに接続させるために利用される技術である。ＮＡＴの外部の機器は、ＮＡＴの内部の端末のＩＰアドレスを知ることができない。このため、ＮＡＴの外部の機器は、ＮＡＴの内部の端末に直接ＵＤＰでデータを送ることができない。また、多くのファイアウォールは、外部からの通信ネットワーク攻撃を防ぐため、外部からのＵＤＰ通信を内部に通さないようにしている。【０００８】
外部からのＵＤＰによるデータをＮＡＴ内の機器やファイアウォール内の機器に送信するためには、ＮＡＴやファイアウォールに特殊な設定をしたり、ＩＥＴＦ（Ｉｎｔｅｒｎｅｔ  Ｅｎｇｉｎｅｅｒｉｎｇ  Ｔａｓｋ  Ｆｏｒｃｅ）で定められているＲＦＣ５３８９  Ｓｅｓｓｉｏｎ  Ｔｒａｖｅｒｓａｌ  Ｕｔｉｌｉｔｉｅｓ  ｆｏｒ  ＮＡＴ（ＳＴＵＮ）などの特別なプロトコルを利用したりすることが求められる。しかし、上記の対応方法には、通信ネットワーク攻撃耐性が弱くなる、特別なプロトコルに対応するためにコストがかかるなどの欠点がある。【０００９】
インターネットやモバイルインターネットでは、利用端末がＮＡＴやファイアウォールの内部にあることが多いため、一部のインターネット向けＩＰ電話サービスは、ＮＡＴやファイアウォールを容易に越えることができるＴＣＰを利用して音声データを送信する。【００１０】
ＴＣＰを使用する場合、ロスしたパケットの再送制御やフロー制御が行われるため、相手端末へのデータ到達性が保証される。その代わりに、低遅延なデータ通信は、考慮されない。よって通常、ＴＣＰは、リアルタイム性を要求する音声通話などのサービスには利用されていない。ＴＣＰを利用したＩＰ電話サービスには、接続性を確保できるというメリットがあるが、音声遅延が大きいというデメリットもある。【００１１】
上記の課題に対して、特許文献１にＴＣＰを利用して低遅延にデータ通信を行うための技術が記載されている。特許文献１に記載されている通信装置は、以下のような構成を取ることで、ＴＣＰを利用した低遅延なデータ通信を実現する。【００１２】
特許文献１に記載されている送信装置は、送信装置と受信装置との間で複数のＴＣＰコネクションを確立し、音声データなどの送信対象データを複数のパケットに分割し、複数のパケットを確立済みの別々のＴＣＰコネクションに振り分けて送信する。このため、受信装置は、ある一つのＴＣＰコネクションに振り分けられたパケットがロスしそのパケットの到着が遅延しても、他のＴＣＰコネクションに振り分けられたパケットを遅延なく受信できる。【００１３】
特許文献１に記載されている通信装置は、パケットロスにより遅れて到着したパケットをロスパケットとして扱うことで、低遅延な音声通話を実現する。ロスパケットとして扱われたパケット分の音声データは受信側で利用されないため、受信装置で再生される音声データは送信前のデータと比較して劣化したデータになる。
【先行技術文献】
【特許文献】
【００１４】
【特許文献１】特開２００９−１００１１８号公報
【特許文献２】特開２０１１−１４２６２２号公報
【特許文献３】特開２０１１−２２８８２３号公報
【非特許文献】
【００１５】
【非特許文献１】Ｖｉｎａｙ  Ｊ．  Ｒｉｂｅｉｒｏ，  Ｒｕｄｏｌｆ  Ｈ．  Ｒｉｅｄｉ，  Ｒｉｃｈａｒｄ  Ｇ．  Ｂａｒａｎｉｕｋ，  Ｊｉｒｉ  Ｎａｖｒａｔｉｌ ａｎｄ  Ｌｅｓ  Ｃｏｔｔｒｅｌｌ，“ｐａｔｈＣｈｉｒｐ：Ｅｆｆｉｃｉｅｎｔ  ａｖａｉｌａｂｌｅ  Ｂａｎｄｗｉｄｔｈ  Ｅｓｔｉｍａｔｉｏｎ  ｆｏｒ  Ｎｅｔｗｏｒｋ  Ｐａｔｈｓ，”ｉｎ  Ｐｒｏｃ  ｏｆ  Ｐａｓｓｉｖｅ  ａｎｄ  Ａｃｔｉｖｅ  Ｍｅａｓｕｒｅｍｅｎｔ  Ｗｏｒｋｓｈｏｐ  ２００３．
【発明の概要】
【発明が解決しようとする課題】
【００１６】
しかし、特許文献１に記載されている通信装置は、最適なＴＣＰコネクションの本数、音声データを複数パケットに分割する分割方法、および受信装置に到着するパケットの許容遅延時間の最適値を考慮していない。さらに、特許文献１に記載されている通信装置は、低遅延な音声通話を実現することのみを考慮しており、音声データの劣化を考慮していない。【００１７】
そこで、本発明は、低遅延な音声通話を実現し、かつ音声データの劣化を防止できる送信装置、受信装置および中継装置を提供することを目的とする。
【課題を解決するための手段】
【００１８】
本発明による送信装置は、分割されたデータを１つまたは複数のＴＣＰコネクションに振り分けるデータ振分手段と、通信ネットワークの状態を監視するネットワーク状態監視手段と、ネットワーク状態監視手段の監視結果である通信ネットワークの状態に応じてデータの分割方法および分割されたデータの送信方法を変更する送信方法決定手段とを備えることを特徴とする。【００１９】
本発明による受信装置は、受信した分割データを合成するデータ合成手段と、通信ネットワークの状態を監視するネットワーク状態監視手段と、ネットワーク状態監視手段の監視結果である通信ネットワークの状態に応じて分割データの受信方法および分割データの合成方法を変更する受信方法決定手段とを備えることを特徴とする。【００２０】
本発明による中継装置は、受信した分割データを合成するデータ合成手段と、通信ネットワークの状態を監視するネットワーク状態監視手段と、ネットワーク状態監視手段の監視結果である通信ネットワークの状態に応じて分割データの受信方法および分割データの合成方法を変更する受信方法決定手段とを備えることを特徴とする。
【発明の効果】
【００２１】
本発明によれば、低遅延な音声通話を実現し、かつ音声データの劣化を防止できる。
【図面の簡単な説明】
【００２２】
【図１】本発明による送信装置および受信装置を含むメディア通信システムの第１の実施形態の構成例を示すシステム構成図である。
【図２】送信装置と受信装置との通信形態の例を示す説明図である。
【図３】送信装置と受信装置の第１の実施形態の構成例を示すブロック図である。
【図４】送信装置のメディアデータ送信処理の動作を示すフローチャートである。
【図５】受信装置のメディアデータ再生処理の動作を示すフローチャートである。
【図６】一つのＴＣＰコネクションを用いた場合のパケット通信の様子の一例を示す説明図である。
【図７】一つのＴＣＰコネクションを用いた場合のパケット通信の様子の一例を示す説明図である。
【図８】二つのＴＣＰコネクションを用いた場合のパケット通信の様子の一例を示す説明図である。
【図９】二つのＴＣＰコネクションを用いた場合のパケット通信の様子の一例を示す説明図である。
【図１０】メディア通信システムによる効果を評価するために用いられるシステムの構成を示すシステム構成図である。
【図１１】パケットロス率と平均ＰＥＳＱ評価値の関係を許容遅延ごとのグラフとして示す説明図である。
【図１２】パケットロス率と平均ＰＥＳＱ評価値の関係を並列コネクション数ごとのグラフとして示す説明図である。
【図１３】パケットロス率と平均ＰＥＳＱ評価値の関係をパケット送信間隔ごとのグラフとして示す説明図である。
【図１４】二つのＴＣＰコネクションを用いた場合の冗長通信の様子の一例を示す説明図である。
【図１５】二つのＴＣＰコネクションを用いた場合の冗長通信の様子の一例を示す説明図である。
【図１６】本発明による送信装置の概要を示すブロック図である。
【図１７】本発明による受信装置の概要を示すブロック図である。
【図１８】本発明による中継装置の概要を示すブロック図である。
【発明を実施するための形態】
【００２３】
実施形態１．
以下、本発明の第１の実施形態を図面を参照して説明する。図１は、本発明による送信装置および受信装置を含むメディア通信システムの第１の実施形態の構成例を示すシステム構成図である。
【００２４】
図１に示すメディア通信システム１０は、送信装置１００と、受信装置２００と、マルチメディアデータ記憶部４００とを含む。送信装置１００は、ＩＰネットワーク３００を介して受信装置２００と通信可能に接続されている。
【００２５】
送信装置１００は、ＩＰネットワーク３００を介して受信装置２００に、マルチメディアデータ記憶部４００に記憶されているマルチメディアデータ５００を送信する。
【００２６】
マルチメディアデータ５００は、例えば、マイクロフォン（以下、マイクという。）やカメラからリアルタイムに取得されるマルチメディアデータである。また、マルチメディアデータ５００は、外部記憶媒体や別の装置により管理される記憶装置に蓄積されたマルチメディアファイルでもよい。本実施形態では、マルチメディアデータ５００は、マイクから入力されたリアルタイム音声データであるとする。
【００２７】
送信装置１００は、ＩＰネットワーク３００を介して受信装置２００へマルチメディアデータ５００を送信する情報処理装置である。送信装置１００は、中央処理装置（ＣＰＵ；Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）（図示せず）、メモリおよびＨＤＤ（Ｈａｒｄ  Ｄｉｓｋ  Ｄｒｉｖｅ）などの記憶装置（図示せず）を備える。送信装置１００は、記憶装置に記憶されているプログラムを実行する場合に、後述する機能を実現するように構成されている。このように構成されていることで、送信装置１００は、マルチメディアデータの通信を実現する。
【００２８】
受信装置２００は、ＩＰネットワーク３００を介して送信装置１００と接続されている。受信装置２００は、中央処理装置（ＣＰＵ）（図示せず）および、メモリおよびＨＤＤなどの記憶装置（図示せず）を備える。受信装置２００は、記憶装置に記憶されているプログラムを実行する場合に、後述する機能を実現するように構成されている。このように構成されていることで、受信装置２００は、マルチメディアデータの受信および再生を実現する。
【００２９】
送信装置１００が送信するマルチメディアデータ５００は、外部記憶媒体や別の装置により管理される記憶装置に保存されたマルチメディアファイルでもよい。また、マルチメディアデータ５００は、マイクやカメラからリアルタイムに取得されるマルチメディアデータでもよい。
【００３０】
本実施形態のメディア通信システムでは、マイクからリアルタイムに入力された音声データであるマルチメディアデータ５００を、できるだけ低遅延に、かつ高品質に送信装置１００から受信装置２００に伝送することが想定されている。
【００３１】
しかし、本実施形態のメディア通信システムは、マイクから入力された音声データの他にも、カメラからリアルタイムに入力された映像データ、映像データと音声データの両方、マイクやカメラではなく別装置から伝送された音声データや映像データ、または記憶装置に蓄積されたマルチメディアデータなど、マルチメディアデータを送信するサービスであればどのようなサービスにも適用可能である。
【００３２】
ＩＰネットワーク３００は、ＩＰに準拠した通信を行う任意の通信ネットワークである。ＩＰネットワーク３００は、ルータなどの中継装置など（図示せず）を含む。また、ＩＰネットワーク３００は、有線通信により実現されてもよい。また、ＩＰネットワーク３００は、その一部又は全部が無線通信により実現されてもよい。
【００３３】
ＩＰネットワーク３００が無線通信により実現される場合、無線通信には、第三世代のモバイルネットワーク（３Ｇ）、ＨＳＰＡ（Ｈｉｇｈ  Ｓｐｅｅｄ  Ｐａｃｋｅｔ  Ａｃｃｅｓｓ）網、またはＬＴＥ（Ｌｏｎｇ  Ｔｅｒｍ  Ｅｖｏｌｕｔｉｏｎ）網などのモバイルネットワークが利用される。また、無線通信には、無線ＬＡＮ（Ｌｏｃａｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）（例えば、Ｗｉ−Ｆｉ（登録商標））が利用されてもよい。送信装置１００と受信装置２００とは、ＩＰに準拠した通信を行うことが可能である任意の無線通信により通信可能に接続されてもよい。
【００３４】
なお、本実施形態では、送信装置１００は音声を入力して送信する装置であり、受信装置２００は音声を受信して再生する装置であるが、送信装置１００および受信装置２００は、音声を入力したり再生したりする装置ではなく、音声データを中継するだけの装置でもよい。
【００３５】
図２は、送信装置１００と受信装置２００との通信形態の例を示す説明図である。図２に示す「１．直接ＵＤＰ」および「２．直接ＴＣＰ」のように、送信装置１００と受信装置２００との間で直接ＵＤＰ通信またはＴＣＰ通信が行われる場合、中継装置６００は不要である。
【００３６】
しかし、送信装置１００または受信装置２００がＮＡＴ内やファイアウォール内に存在する場合、ＮＡＴやファイアウォールの外部の装置は直接ＵＤＰ通信を行うことができないことが多い。そのような場合には、図２に示す「３．片側ＴＣＰ」のように、途中の中継装置６００と送信装置１００とをＴＣＰコネクションで通信可能に接続させ、中継装置６００と受信装置２００とをＵＤＰで通信可能に接続させてもよい。
【００３７】
また、図２に示す「４．両側ＴＣＰ」のように、送信装置１００と受信装置２００との間でＴＣＰコネクションを中継する中継装置６００が設けられてもよい。また、図２に示す「５．多段ＴＣＰ」のように、送信装置１００および受信装置２００との間には、中継装置が２つ以上存在してもよい。中継装置６００は、少なくとも、以下で詳述される受信装置２００の機能を有し、合成したデータを受信装置に送信する。
【００３８】
次に、送信装置１００と受信装置２００の詳細な構成を図３を参照して説明する。図３は、送信装置１００と受信装置２００の第１の実施形態の構成例を示すブロック図である。
【００３９】
図３に示す送信装置１００は、メディア入力手段１０１と、符号化手段１０２と、データ分割手段１０３と、データ振分手段１０４と、送信手段１０５１〜１０５ｎと、送信側コネクション管理手段１０６と、送信側ネットワーク状態監視手段１０７と、送信方法決定手段１０８とを含む。なお、ｎは自然数を意味する。
【００４０】
図３に示す受信装置２００は、受信手段２０１１〜２０１ｎと、データ合成手段２０２と、再生手段２０３と、受信側コネクション管理手段２０４と、受信側ネットワーク状態監視手段２０５と、受信方法決定手段２０６とを含む。
【００４１】
送信装置１００の送信手段１０５１〜１０５ｎと、受信装置２００の受信手段２０１１〜２０１ｎは、ＴＣＰコネクション３０１１〜３０１ｎでそれぞれ接続されている。送信装置１００の送信手段の数、受信装置２００の受信手段の数、およびＴＣＰコネクションの数はすべて同一である。本実施形態では便宜上、それぞれの手段とＴＣＰコネクションの添字を統一する。送信手段１０５ｍは、受信手段２０１ｍとＴＣＰコネクション３０１ｍで接続されているとする（ｍ＝１〜ｎ）。
【００４２】
メディア入力手段１０１は、メディア信号を入力する機能を有する。
【００４３】
符号化手段１０２は、メディア入力手段１０１が入力したメディア信号を特定の符号化方式で符号化する機能を有する。
【００４４】
データ分割手段１０３は、符号化手段１０２が符号化したメディア信号を設定されたデータ量ごとに分割する機能を有する。
【００４５】
データ振分手段１０４は、データ分割手段１０３が分割したデータを、送信手段１０５１〜１０５ｎのうちの適切な送信手段に振り分ける機能を有する。
【００４６】
送信手段１０５１〜１０５ｎは、データ振分手段１０４から振り分けられたデータをＴＣＰコネクション３０１１〜３０１ｎを介し、受信手段２０１１〜２０１ｎへ送信する機能を有する。
【００４７】
送信側コネクション管理手段１０６は、送信手段１０５１〜１０５ｎの状態を監視する機能を有する。送信側コネクション管理手段１０６は、送信手段１０５１〜１０５ｎの状態を送信側ネットワーク状態監視手段１０７に伝達する。
【００４８】
送信側ネットワーク状態監視手段１０７は、送信側コネクション管理手段１０６の情報や、通信ネットワーク状態を通知する手段の情報に基づき、現在の通信ネットワーク状態または近い未来の通信ネットワーク状態を推定または予測する機能を有する。
【００４９】
送信側ネットワーク状態監視手段１０７が利用する通信ネットワーク状態を推定する基本的な方法には、例えば、ＩＣＭＰ（Ｉｎｔｅｒｎｅｔ  Ｃｏｎｔｒｏｌ  Ｍｅｓｓａｇｅ  Ｐｒｏｔｏｃｏｌ）パケットを利用してｐｉｎｇを連続的に送受信することによって、パケットロス率およびパケットの到達遅延を測定できる方法がある。
【００５０】
また、通信ネットワーク状態の推定方法または予測方法は、上記の他にも、特許文献２に記載されている複数のパケットを連続的に送信し受信時間を測定することによって現在利用可能な周波数帯域を推定する方法や、特許文献３に記載されている確率モデルからパケットロス率を推定する方法でもよい。また、非特許文献１に記載されているｐａｔｈＣｈｉｒｐを使用する方法でもよい。
【００５１】
送信側ネットワーク状態監視手段１０７が推定または予測する通信ネットワーク状態は、例えば、パケットロス率である。パケットロス率は、例えば、送信側ネットワーク状態監視手段１０７が特許文献２や非特許文献１に記載されている方式などで可用帯域を推定できた場合、可用帯域の時間的な変動を観測し、可用帯域が少なくなってきたら通常よりもパケットロスが発生している可能性が高いと判断することによって予測される。
【００５２】
また、コネクション管理手段で管理しているＴＣＰ／ＩＰを監視する方法でも、パケットロス率は推定される。具体的には、送信側の送信側コネクション管理手段１０６は、ＴＣＰ／ＩＰの送信バッファ量が増加しているとパケットロスが発生していることが分かる。受信側の受信側コネクション管理手段２０４は、定期的に受信できるはずのデータが受信できていない場合に、パケットロス率が増大していると判断できる。
【００５３】
なお、上記では送信側ネットワーク状態監視手段１０７がパケットロス率を推定または予測するとしているが、パケットロス率とパケット到達遅延や可用帯域とは密接に関係している。すなわち、送信側ネットワーク状態監視手段１０７は、パケット到達遅延が増加すればパケットロス率が高くなるという予測、または可用帯域が少なくなればパケットロス率が高くなるという予測もできる。よって、送信側ネットワーク状態監視手段１０７は、パケット到達遅延や可用帯域を推定または予測してもよい。
【００５４】
送信方法決定手段１０８は、送信側ネットワーク状態監視手段１０７で推定または予測された通信ネットワーク状態に基づき、データを分割する最適なデータ量および最適なコネクション数を決定する機能を有する。送信方法決定手段１０８は、決定した内容をデータ分割手段１０３と、データ振分手段１０４と、送信側コネクション管理手段１０６とに通知する。
【００５５】
データを分割するデータ量が変更された場合、データ分割手段１０３は、入力されるメディアデータの分割単位を変更する。
【００５６】
コネクション数が増加される場合、送信側コネクション管理手段１０６は、新たな送信手段から受信装置２００の受信手段に対して新たなＴＣＰコネクションを張る。その後、新たな送信手段と新たな受信手段との間で通信が開始される。
【００５７】
また、コネクション数が減少される場合、送信側コネクション管理手段１０６は、任意の送信手段１０５ｍを切断する。データ振分手段１０４は、コネクション数が変更された後の新たな送信手段に対してデータを振り分けるように動作する。
【００５８】
受信手段２０１１〜２０１ｎは、送信装置１００の送信手段１０５１〜１０５ｎから送信されたデータパケットを受信する機能を有する。
【００５９】
データ合成手段２０２は、複数の受信手段が受信したデータパケットを再構成し、複合する機能を有する。
【００６０】
データ合成手段２０２は、受信手段２０１１〜２０１ｎが受信したデータパケットの到着時間が、許容される遅延時間内であるか否かを判別する。パケットが許容遅延時間内に到着した場合、データ合成手段２０２は、到着したパケットを復号する。パケットが許容遅延時間内に到着しなかった場合、データ合成手段２０２は、到着しなかったパケットをロスパケットとして扱う。
【００６１】
再生手段２０３は、データ合成手段２０２で復号されたメディアデータを再生する機能を有する。
【００６２】
受信側コネクション管理手段２０４は、受信手段２０１１〜２０１ｎの状態を監視する機能を有する。受信側コネクション管理手段２０４は、受信手段２０１１〜２０１ｎの状態を受信側ネットワーク状態監視手段２０５に伝達する。
【００６３】
受信側ネットワーク状態監視手段２０５は、受信側コネクション管理手段２０４の情報や、通信ネットワーク状態を通知する手段の情報に基づき、現在の通信ネットワーク状態または近い未来の通信ネットワーク状態を推定または予測する機能を有する。
【００６４】
受信側ネットワーク状態監視手段２０５による通信ネットワーク状態の推定方法または予測方法は、例えば、送信側ネットワーク状態監視手段１０７が使用する方法と同じ方法である。また、受信側ネットワーク状態監視手段２０５による通信ネットワーク状態の推定内容または予測内容は、例えば、パケットロス率である。
【００６５】
受信方法決定手段２０６は、受信側ネットワーク状態監視手段２０５で推定または予測された通信ネットワーク状態に基づき、データ受信に最適なコネクション数およびデータ合成手段２０２でデータ合成時に許容する遅延時間を決定する機能を有する。受信方法決定手段２０６は、決定した内容をデータ合成手段２０２と、受信側コネクション管理手段２０４とに通知する。
【００６６】
許容遅延時間が変更された場合、データ合成手段２０２は、データ合成時に到着したパケットをロスパケットとして扱うかどうか判定する際の判定時間を変更する。
【００６７】
コネクション数が増加される場合、受信側コネクション管理手段２０４は、新たな受信手段から送信装置１００の送信手段に対して新たなＴＣＰコネクションを張る。その後、新たな送信手段と新たな受信手段との間で通信が開始される。
【００６８】
また、コネクション数が減少される場合、受信側コネクション管理手段２０４は、任意の受信手段２０１ｍを切断する。
【００６９】
以下、本実施形態における送信装置１００が入力したメディアデータを送信する時の動作を図４のフローチャートを参照して説明する。図４は、送信装置１００の第１の実施形態のメディアデータ送信処理の動作を示すフローチャートである。
【００７０】
ここでは、マイクから入力された音声データを送信装置１００が受信装置２００に送信する場合を想定する。
【００７１】
送信装置１００のメディア入力手段１０１は、処理単位分の音声データをマイクから入力する（ステップＳ００１）。音声データの処理単位は、特に定められない。
【００７２】
メディア入力手段１０１が、例えば、マイクから入力される音声通話の音声データを８ｋＨｚでサンプリングし、１６ｂｉｔで量子化したＰＣＭ（Ｐｕｌｓｅ−Ｃｏｄｅ  Ｍｏｄｕｌａｔｉｏｎ）データとして入力するとする。この設定で１０ミリ秒ごとに音声データが入力される場合、メディア入力手段１０１には、１０ミリ秒ごとに１６０バイトのＰＣＭデータが入力される。
【００７３】
符号化手段１０２は、マイクから入力された音声データを所定の方式で符号化する（ステップＳ００２）。ここで、符号化手段１０２が利用する符号化方式は任意であり、ＰＣＭデータをそのまま使用する方式でもよい。
【００７４】
また、符号化手段１０２が利用する符号化方式は、ＩＴＵ−Ｔ（Ｉｎｔｅｒｎａｔｉｏｎａｌ  Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎ  Ｕｎｉｏｎ  Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎ  Ｓｔａｎｄａｒｄｉｚａｔｉｏｎ  Ｓｅｃｔｏｒ）で定められたＧ．７１１やＧ．７２９、３ＧＰＰ（３ｒｄ  Ｇｅｎｅｒａｔｉｏｎ  Ｐａｒｔｎｅｒｓｈｉｐ  Ｐｒｏｊｅｃｔ）で定められたＡＭＲ（Ａｄａｐｔｉｖｅ  Ｍｕｌｔｉ  Ｒａｔｅ）、およびＩＳＯ（Ｉｎｔｅｒｎａｔｉｏｎａｌ  Ｏｒｇａｎｉｚａｔｉｏｎ  ｆｏｒ  Ｓｔａｎｄａｒｄｉｚａｔｉｏｎ）で定められたＡＡＣ（Ａｄｖａｎｃｅｄ  Ａｕｄｉｏ  Ｃｏｄｉｎｇ）などの符号化方式でもよい。
【００７５】
ここでは、符号化手段１０２がＧ．７１１で音声データを符号化することを想定する。この場合、１０ミリ秒ごとの１６０バイトのＰＣＭデータが、１０ミリ秒ごとの８０バイトのＧ．７１１ストリームに符号化される。
【００７６】
次いで、データ分割手段１０３は、符号化されたＧ．７１１ストリームを送信するパケット単位にまとめる（ステップＳ００３）。送信装置１００は、１０ミリ秒のデータをそのままパケットとして送信してもよい。また、送信装置１００は、いくつかの１０ミリ秒のデータのパケットをまとめて送信してもよい。
【００７７】
図４に示す例では、６個の１０ミリ秒のＧ．７１１データが、まとめて一つのパケットにされている。パケットをまとめずに送信した場合、受信装置２００側にパケット作成のための待ち時間が少ないというメリットがある。しかし、送信するパケットが多くなり送受信の負荷が高くなったりパケットヘッダの比率が多くなったりするため、通信ネットワークの負荷が高くなるという欠点がある。
【００７８】
パケットをまとめて送信した場合、送受信の負荷や通信ネットワークの負荷が低くなるというメリットがある。しかし、パケットがまとめられることで、パケット到達の遅延時間が長くなるという欠点がある。
【００７９】
データ振分手段１０４は、符号化済みデータがまとめられて生成されたパケットを複数の送信手段に振り分ける。送信手段は、振り分けられたパケットを送出する（ステップＳ００４）。
【００８０】
データ振分手段１０４は、１番目のパケットを送信手段１０５１に、２番目のパケットを送信手段１０５２に、ｎ番目のパケットを送信手段１０５ｎに、（ｎ＋１）番目のパケットを送信手段１０５１にというように、パケットごとに順番に送信手段を割り当ててもよい。また、データ振分手段１０４は、送信手段ごとの状態を監視し、送信遅延が少ない送信手段を優先して利用するようにしてもよい。
【００８１】
データ振分手段１０４が送信するパケットに順番に送信手段を割り当てる場合、受信装置２００もパケットを順番に受信することによってパケットを再構成できる。データ振分手段１０４が送信するパケットに送信遅延が少ない送信手段を優先して割当てる場合、受信側でパケットの再構成がされるように、送信パケットにはタイムスタンプ情報が付されていることが求められる。
【００８２】
以後、送信装置１００は、入力された音声データに対して送信処理を繰り返す。音声データが入力されなくなった場合、送信装置１００は、メディアデータ送信処理を終了する。
【００８３】
次に、本実施形態における受信装置２００が受信したメディアデータを再生する時の動作を図５のフローチャートを参照して説明する。図５は、受信装置２００の第１の実施形態のメディアデータ再生処理の動作を示すフローチャートである。
【００８４】
ここでは、送信装置１００から送信されたマイクから入力された音声データを、受信装置２００が再生する場合を想定する。
【００８５】
受信装置２００の受信手段は、到着したデータパケットを受信する（ステップＳ１０１）。
【００８６】
次いで、データ合成手段２０２は、到着したパケットの到着時間から、パケットが許容遅延時間に間に合っているか、それとも遅れて到着したかを判定する（ステップＳ１０２）。
【００８７】
例えば、許容遅延時間が１００ミリ秒である場合、データ合成手段２０２は、最初の音声データから１秒後（１０００ミリ秒後）の音声データが、再生が開始されたタイミングから１．１秒以内（１１００ミリ秒以内）に届けば許容遅延時間に間に合ったと判定する。音声データが再生開始のタイミングから１．１秒以内に届かなかった場合、データ合成手段２０２は、パケットの到着が遅すぎると判断する。
【００８８】
データ合成手段２０２は、到着が許容遅延時間より遅れたと判断（ステップＳ１０２のＹｅｓ）したパケットを破棄する（ステップＳ１０３）。また、データ合成手段２０２は、到着が許容遅延時間に間に合ったと判断した（ステップＳ１０２のＮｏ）パケットをバッファに蓄積する（ステップＳ１０４）。以後、データ合成手段２０２は、受信手段から入力されるパケットに対して、判定処理を繰り返す。
【００８９】
バッファに蓄積されたパケットは、タイムスタンプに従って順番に読み出される（ステップＳ１０５）。パケットを順番に読み出す時、データ合成手段２０２は、例えば、６０ミリ秒単位で生成されていたパケットを、再生するために必要な単位のパケットデータに分割して処理してもよい。再生するために必要な単位は、例えば、１０ミリ秒単位である。
【００９０】
データ合成手段２０２は、バッファから読み出したパケットを復号する（ステップＳ１０６）。データ合成手段２０２は、例えば、Ｇ．７１１で符号化されていたパケットをＰＣＭデータに復号する。
【００９１】
パケットが複合される時、ステップＳ１０３において許容遅延時間に到着が間に合わなかったパケットは破棄されているので、パケットの間が抜けている場合がある。この場合、データ合成手段２０２は、破棄されたパケットを無音として、パケットが抜けている箇所にデータが０である１０ミリ秒分のＰＣＭデータを挿入してもよい。
【００９２】
また、データ合成手段２０２は、Ｇ．７１１  Ａｐｐｅｎｄｉｘ  Ｉで定められているようなパケットロス隠蔽処理（ＰＬＣ；Ｐａｃｋｅｔ  Ｌｏｓｓ  Ｃｏｎｃｅａｌｍｅｎｔ）をすることによって、破棄された部分の音声データを目立たなくしてもよい。
【００９３】
再生手段２０３は、データ合成手段２０２によって復号、およびＰＬＣにより補間された音声データを再生する（ステップＳ１０７）。以後、データ合成手段２０２はバッファに蓄積されたパケットを読み出し、合成処理を繰り返す。バッファに蓄積されたパケットが無くなった場合、受信装置２００は、再生処理を終了する。
【００９４】
以下、本実施形態における複数のＴＣＰコネクションを用いたデータ通信方法およびデータ合成方法を、図６から図９を参照して説明する。図６は、一つのＴＣＰコネクションを用いた場合のパケット通信の様子の一例を示す説明図である。図７は、一つのＴＣＰコネクションを用いた場合のパケット通信の様子の他の一例を示す説明図である。
【００９５】
図６に示すように、送信装置１００において、「送信アプリ」と記載されたメディア入力手段１０１から送信手段１０５１までのデータ通信処理を行うアプリケーションが動作する。
【００９６】
ＴＣＰコネクションを利用したデータ通信の場合、ソケットと呼ばれる抽象化インタフェースが利用されてデータ通信が行われる。ＯＳ（Ｏｐｅｒａｔｉｎｇ  Ｓｙｓｔｅｍ）上のアプリケーションである送信アプリは、ソケットのバッファに対して送信したいパケットデータを書き込む。
【００９７】
ソケット通信は、ＯＳのライブラリやカーネルに実装されている。バッファに書き込まれたパケットデータは、アプリケーションのソケットバッファへの書き込みとは独立したタイミングでＩＰネットワーク３００へ送信される。
【００９８】
図６に示すように、受信装置２００でもソケットインタフェースを利用している。受信装置２００では、「受信アプリ」と記載された受信手段２０１１から再生手段２０３までのデータ再生処理を行うアプリケーションが動作している。
【００９９】
音声データが再生されるまでの手順は、まずＩＰネットワーク３００から届いたパケットデータを受信ソケットが受け取り、受信ソケットがパケットデータを受信バッファに書き込む。受信ソケットがパケットデータを受信バッファに書き込むと、受信アプリに対して割り込みなどのイベントが発生する。発生したイベントを受けて、受信アプリがパケットデータを受信バッファから受け取り、再生処理を行うという手順になる。
【０１００】
図６には、１０個のパケットが途中でパケットロスすることなく、定期的に送信アプリが受信アプリにパケットを送信する様子が示されている。送信アプリがそれぞれのパケットを送信バッファに書き込むと、それぞれのパケットが順番にソケットを経由して受信アプリに送信される。ＴＣＰコネクションではパケットロスのないデータ通信が行われるため、受信ソケットは「どこまで受信できたか」を定期的にＡＣＫ（ＡＣＫｎｏｗｌｅｄｇｅｍｅｎｔ）パケットとして返す。図６に示す例において、受信ソケットは３パケットを受信すると一回ＡＣＫパケットを返している。
【０１０１】
図７には、途中でパケットロスが発生し、パケット２が受信装置２００に届かない例が示されている。送信装置１００は、パケット１、パケット２、パケット３・・・の順序でパケットを送信している。しかし、パケット２がロスしているため、受信装置２００にはパケット１が受信された後、パケット３が届いたことになる。
【０１０２】
ここで、受信装置２００の受信ソケットは、送信装置１００の送信ソケットに対して、「パケット２が届いていない」ことを伝えるＡＣＫパケットを返す。一般に送信ソケットは、「パケットが届かない」というＡＣＫパケットを一度受信しただけでは、届いていないパケットの再送を行わない。送信ソケットは、ＡＣＫパケットを数回受信しないとロスしたパケットを再送しない。
【０１０３】
図７に示す例では、受信ソケットにパケット４、パケット５が届いたタイミングで、それぞれ「パケット２が届いていない」ことを伝えるＡＣＫパケットが送信されている。その結果、送信ソケットに「パケット２が届いていない」ことが３回伝えられたため、送信ソケットは、パケット２を再送している。受信装置２００には、パケット６が到着した後にパケット２が到着している。
【０１０４】
ＴＣＰコネクションを利用したデータ通信の場合、データが正しい順序に並べられてからアプリケーション上にイベントが発生する。すなわち、受信バッファに到着しているパケット３からパケット６は、パケット２が到着してからようやく利用される。
【０１０５】
通常のデータ通信では、少々の到達遅延は大きな問題にならない。しかし、リアルタイムデータの通信では、このパケット再送による到達遅延が音声品質の劣化の原因になる。図７に示す例において、パケットが２０ミリ秒単位で送られているとすれば、パケット２は約８０ミリ秒以上の遅れで届くことになる。このように、一つのＴＣＰコネクションのみを用いてリアルタイムデータ通信を実現することは困難である。
【０１０６】
図８は、二つのＴＣＰコネクションを用いた場合のパケット通信の様子の一例を示す説明図である。図９は、二つのＴＣＰコネクションを用いた場合のパケット通信の様子の他の一例を示す説明図である。
【０１０７】
送信装置１００は、送信手段１０５１を使用して奇数番パケットを送信し、送信手段１０５２を使用して偶数番パケットを送信するようにパケットを振り分ける。受信手段２０１１は、奇数番パケットを受信する。また、受信手段２０１２は、偶数番パケットを受信する。
【０１０８】
図８に示す例ではパケットロスが発生していないので、送信手段１０５１および送信手段１０５２で送信されたパケットが、遅滞なく受信手段２０１１および受信手段２０１２で受信される。受信手段２０１１および受信手段２０１２で受信されたパケットは、データ合成手段２０２に渡される。データ合成手段２０２は、渡されたパケットをパケット順に再構成する。再生手段２０３は、再構成された音声を再生する。
【０１０９】
図９に示す例ではパケットロスが発生している。送信装置１００は、図８に示す例と同様に、二本のＴＣＰコネクションを利用して、奇数番パケット、偶数番パケットをそれぞれ送信手段１０５１、送信手段１０５２に振り分ける。
【０１１０】
図９に示す例では、ＴＣＰコネクション３０１１ではパケットロスが発生していないため、奇数番パケットは遅滞なく受信手段２０１１で受信される。これに対して、ＴＣＰコネクション３０１２ではパケット２のロスが発生しているため、パケットの再送遅延が発生する。受信手段２０１２には、パケット２、パケット４、パケット６が遅れて到着する。
【０１１１】
データ合成手段２０２は、許容遅延時間内に届かないパケットをロスパケットとして扱う。図９に示す例では、１パケット分到着が遅れたパケットがロスパケットとして扱われるように設定されている。よって、データ合成手段２０２は、届いたパケットから順にデータ合成処理を行い、許容遅延時間内に届かないパケット２、パケット４、パケット６をロスパケットとして扱う。データ合成手段２０２は、合成時にＰＬＣによりロスパケットを目立たなくする。再生手段２０３は、そのように合成されたデータを再生する。
【０１１２】
上記のように構成されることで、本実施形態のメディア通信システムは、複数のＴＣＰコネクションを利用した場合、特定のＴＣＰコネクションのパケットの到着に遅延が発生したとしても、遅延パケットをロスパケットとして扱うことで、データの再生処理を遅延なく行うことができる。また、ロスパケットを目立たなくする場合、メディア通信システムは、音質劣化を防ぐことができる。
【０１１３】
以下、本実施形態における送信装置１００と受信装置２００との間のＴＣＰコネクション数、データ分割手段１０３におけるデータ分割の間隔、およびデータ合成手段２０２における許容遅延時間の決定方法をそれぞれ説明する。
【０１１４】
まず、許容遅延時間の決定方法を、以下に説明する。上記で説明した通り、パケットロスが発生すると、受信装置２００に到着するパケットが遅延する。すなわち、パケットロスが多く発生する環境では、許容遅延時間より遅く到着するパケットが増加する。データ合成手段２０２は、許容遅延時間より遅く到着したパケットをロスパケットとしてデータを合成する。
【０１１５】
音声パケットが届かない場合、届かないロスパケットの箇所において音質劣化が発生する。図９に示す例などではＰＬＣにより音質劣化を目立たないようにしているが、できるだけパケットロスを発生させないように制御する方が再生する音声が高音質になる。このため、許容遅延時間の決定方法として、パケットロスが少ない場合はデータ合成手段２０２における許容遅延時間を短くし、パケットロスが多くなる程に許容遅延時間を長くするという決定方法がある。
【０１１６】
具体的には、例えば、パケットロス率が１％程度までは許容遅延時間を１００ミリ秒程度に設定し、パケットロス率が１０％では、許容遅延時間を総務省の定めるＩＰ電話の遅延時間の限界である４００ミリ秒にまで長くするという方法である。
【０１１７】
次に、ＴＣＰコネクション数の決定方法を、以下に説明する。パケットロス発生時には、ＴＣＰコネクション数を多くした方が遅延を少なくできる。その理由は、上記で説明した通り、あるＴＣＰコネクションでパケットロスが発生し、ＴＣＰパケットの再送により到着遅延が生じたとしても、他のＴＣＰコネクションで後続のパケットが到着している場合は、音声データ全体の遅延は生じないからである。
【０１１８】
このため、ＴＣＰコネクション数の決定方法には、パケットロスが多くなる程にＴＣＰコネクション数を多くする方法が望ましい。具体的には、例えば、パケットロス率が１％程度ではＴＣＰコネクション数を２本程度とし、パケットロスが多くなる程にＴＣＰコネクション数を５本程度にまで増加するという方法である。
【０１１９】
次に、データ分割間隔の決定方法を、以下に説明する。データ分割間隔は、例えば、音声入力間隔が１０ミリ秒だった場合に、１０ミリ秒ごとに音声データを各ＴＣＰコネクションに振り分けて送信するか、６個まとめて６０ミリ秒ごとに音声データを各ＴＣＰコネクションに振り分けるかを決定するパラメータである。
【０１２０】
パケットロスが少ない場合は、パケットロスによる遅延が少ないのでデータ分割間隔は任意でよい。この場合、遅延が許す範囲で分割間隔を長くした方がパケットロスの個数が少なくなり、音質劣化が目立たなくなる傾向にある。
【０１２１】
上記に対して、パケットロスが多い場合は、分割間隔を短くし、パケット数を多くした方がよい。その理由は、送信するパケット数が多いと、パケットロスが発生した場合でもパケット再送までの時間が短くなるからである。
【０１２２】
上記ではパケットロスの発生状況からＴＣＰコネクション数、データ分割の間隔およびデータ合成手段２０２における許容遅延時間を決定する方法をそれぞれ説明したが、送信側ネットワーク状態監視手段１０７、受信側ネットワーク状態監視手段２０５がそれぞれパケットロス率を測定し、ＴＣＰコネクション数、データ分割間隔および許容遅延時間の決定を実現してもよい。
【０１２３】
また、受信装置２００の受信手段がパケットの到着遅延や同時到着パケット数を観測し、到着遅延の状況や、本来所定の間隔で到着すべきパケットが同時に到着することを検知することによって、パケットロスが発生していることを推定してもよい。
【０１２４】
また、ＴＣＰ／ＩＰのＩＰレイヤで監視することによって、実際のＴＣＰ／ＩＰのロス数、再送を行った回数、ＡＣＫパケットによる再送要求の回数、および送信バッファや受信バッファへのデータ蓄積量などを監視し、これらの監視項目からパケットロス数を推定してもよい。
【０１２５】
以下、図１０から図１３を用いて、送信方法および受信方法を変更すると、音質を向上させることができることを説明する。図１０は、本実施形態のメディア通信システムによる効果を評価するために用いられたシステムの構成を示すシステム構成図である。図１０に示すように、送信装置１００は、マルチメディアデータ記憶部４００からデータを読み出す。そして、送信装置１００は、読み出したデータを、ネットワークエミュレータ３０２を経由して受信装置２００に送信する。
【０１２６】
マルチメディアデータ記憶部４００に記憶されているデータは、ＩＴＵ−Ｔ  Ｐ．５０１  “Ｔｅｓｔ  ｓｉｇｎａｌｓ  ｆｏｒ  ｕｓｅ  ｉｎ  ｔｅｌｅｐｈｏｎｏｍｅｔｒｙ”で入手可能な、１１ヶ国語の男女２名ずつの音声シーケンス、計４４サンプルをつなぎあわせた６分４３秒の音声データが８ｋＨｚにサンプリングされ、ＩＴＵ−Ｔ  Ｇ．７１１  μ−ｌａｗにて符号化されたデータである。符号化済みのマルチメディアデータは、６４ｋｂｐｓの音声データになる。
【０１２７】
送信装置１００は、マルチメディアデータ記憶部４００からデータを定期的に読み出しながら、データを受信装置２００に送信する。送信装置１００は、読み出す時間間隔を１０ミリ秒、２０ミリ秒、３０ミリ秒、４０ミリ秒、６０ミリ秒の５パターンで変更しながらデータを送信した。これは、送信装置１００がそれぞれ、８０バイト、１６０バイト、２４０バイト、３２０バイト、４８０バイトでマルチメディアデータを分割しながら送信することに相当する。また、送信装置１００と受信装置２００はＴＣＰコネクションで接続されている。送信装置１００は、ＴＣＰコネクションの本数を１本から５本まで変更しながらデータを送信した。
【０１２８】
受信装置２００は、一つまたは複数のＴＣＰコネクションから受信したデータパケットの許容遅延時間を変更しながら、マルチメディアデータを再構成した。そして、受信装置２００は、再構成したデータをマルチメディアデータ記憶部４０１に保存した。受信装置２００は、許容遅延時間を１００ミリ秒、２００ミリ秒、４００ミリ秒と変更した。
【０１２９】
音質の評価方法には、マルチメディアデータ記憶部４００に記憶されている送信前のデータとマルチメディアデータ記憶部４０１に記憶されている再構成されたデータをそれぞれＰＣＭデータに復号し、ＩＴＵ−Ｔ  Ｐ．８６２  “Ｐｅｒｃｅｐｔｕａｌ  ｅｖａｌｕａｔｉｏｎ  ｏｆ  ｓｐｅｅｃｈ  ｑｕａｌｉｔｙ（ＰＥＳＱ）：Ａｎ  ｏｂｊｅｃｔｉｖｅ  ｍｅｔｈｏｄ  ｆｏｒ  ｅｎｄ−ｔｏ−ｅｎｄ  ｓｐｅｅｃｈ  ｑｕａｌｉｔｙ  ａｓｓｅｓｓｍｅｎｔ  ｏｆ  ｎａｒｒｏｗ−ｂａｎｄ  ｔｅｌｅｐｈｏｎｅ  ｎｅｔｗｏｒｋｓ  ａｎｄ  ｓｐｅｅｃｈ  ｃｏｄｅｃｓ”を用いて、音質の劣化度を測定する方法を使用した。
【０１３０】
ＰＥＳＱは、電話帯域の音声の劣化を客観的に測定する方式である。また、ＰＥＳＱは、人間の聴覚心理モデルに基づき、リファレンス音源（すなわち、マルチメディアデータ記憶部４００に記憶されているデータ）からの劣化度を推定する方式であり、主観品質であるＭＯＳ（Ｍｅａｎ  Ｏｐｉｎｉｏｎ  Ｓｃｏｒｅ）と高い相関がある。ＭＯＳの評点は１から５で評価され、５が一番よく、１が一番悪い。３が「普通（Ｆａｉｒ）」「やや劣化が気になる（Ｓｌｉｇｈｔｌｙ  ａｎｎｏｙｉｎｇ）」になる。よってここでは、ＰＥＳＱによる評価が３以上であれば、音質に問題がないと評価する。
【０１３１】
ネットワークエミュレータ３０２は、パケットロス率と通信ネットワーク遅延時間を変更する。変更することによって、通信ネットワーク状態の変化が再構成されたマルチメディアデータの音質（ＰＥＳＱ評価値）に与える影響が測定される。ネットワークエミュレータ３０２は、パケットロス率を０．１％から１０％まで、また通信ネットワーク遅延時間を２０ミリ秒、１００ミリ秒、４００ミリ秒とそれぞれ変化させた。
【０１３２】
図１１は、パケットロス率と平均ＰＥＳＱ評価値の関係を許容遅延ごとのグラフとして示す説明図である。横軸はパケットロス率（％）、縦軸は平均ＰＥＳＱ値である。図１１において、“１００”は、許容遅延時間が１００ミリ秒のときのパケットロス率と平均ＰＥＳＱ評価値の関係を表す。同様に、“２００”および“４００”は、許容遅延時間が２００ミリ秒、４００ミリ秒のときのパケットロス率と平均ＰＥＳＱ評価値の関係をそれぞれ表す。
【０１３３】
図１１は、通信ネットワーク遅延時間２０ミリ秒、パケット送信間隔２０ミリ秒、同時コネクション数５本でデータ送受信を行った場合を示す。図１１に示すように、パケットロス率にかかわらず、許容遅延時間が長くなるほど、平均ＰＥＳＱ値が高い、つまり音質が良いことがわかる。パケットロス率が１％以下の場合は許容遅延時間が１００ミリ秒でも平均ＰＥＳＱ値が３．５以上となり、低遅延で高音質の音声視聴が実現されることがわかる。
【０１３４】
また、パケットロス率が１０％になる場合、平均ＰＥＳＱ値が３以上になるためには、許容遅延時間を４００ミリ秒に設定することが求められる。このようにパケットロス率に応じて許容遅延時間を変化させることで、音声品質が維持される。
【０１３５】
図１２は、パケットロス率と平均ＰＥＳＱ評価値の関係を並列コネクション数ごとのグラフとして示す説明図である。横軸はパケットロス率（％）、縦軸は平均ＰＥＳＱ値である。図１２において、“１”は、並列コネクション数が１本のときのパケットロス率と平均ＰＥＳＱ評価値の関係を表す。同様に、“２”〜“５”は、並列コネクション数が２本〜５本のときのパケットロス率と平均ＰＥＳＱ評価値の関係をそれぞれ表す。
【０１３６】
図１２は、通信ネットワーク遅延時間２０ミリ秒、パケット送信間隔２０ミリ秒、許容遅延時間２００ミリ秒でデータ送受信を行った場合を示す。図１２に示すように、パケットロス率が３％以下の場合、コネクション数が少ないほど音質が高いことがわかる。また、パケットロス率が高くなると、コネクション数が多いほど平均ＰＥＳＱ値が高い。このように、パケットロス率に応じてコネクション数を変化させることで、音声品質が維持される。
【０１３７】
図１３は、パケットロス率と平均ＰＥＳＱ評価値の関係をパケット送信間隔ごとのグラフとして示す説明図である。横軸はパケットロス率（％）、縦軸は平均ＰＥＳＱ値である。図１３において、“１０”は、パケット送信間隔が１０ミリ秒のときのパケットロス率と平均ＰＥＳＱ評価値の関係を表す。同様に、“２０”〜“６０”は、パケット送信間隔が２０ミリ秒〜６０ミリ秒のときのパケットロス率と平均ＰＥＳＱ評価値の関係をそれぞれ表す。
【０１３８】
図１３は、通信ネットワーク遅延時間２０ミリ秒、コネクション数５本、許容遅延時間２００ミリ秒でデータ送受信を行った場合を示す。図１３に示すように、パケットロス率に関わらず、パケット送信間隔が１０ミリ秒の場合の平均ＰＥＳＱ値が最も高い。パケットロス率が低い場合、パケット送信間隔を長くしても音質劣化が少ないので、パケット送信間隔を短くしてパケット送信回数を減らすことで通信ネットワークの負荷を下げることが期待される。
【０１３９】
また、パケットロス率が高い場合、パケット送信間隔が長くなると音質劣化も激しくなるため、パケットロス率が高い場合はパケット送信間隔をできるだけ短くすることによって音声品質が維持される。
【０１４０】
本実施形態のメディア通信システムは、送信装置と受信装置との間で一つまたは複数のＴＣＰコネクションを確立し、送信対象であるメディアデータを複数のパケットに分割し、複数のパケットを確立済みの別々のＴＣＰコネクションに振り分けて送信し、受信装置で許容遅延時間内に届かないパケットをロスパケットとして扱い、メディアデータを再構成することによって、低遅延なメディア通信を実現できる。さらに、通信ネットワーク状態にもとづき、ＴＣＰコネクションの増減、パケット分割方法の変更、および許容遅延時間の変更を行うことで、高品質なメディア通信を実現する。
【０１４１】
実施形態２．
次に、本発明の第２の実施形態を説明する。なお、本発明の第２の実施形態におけるメディア通信システム１０の構成例は、第１の実施形態における説明と同様であるため説明を省略する。
【０１４２】
第１の実施形態では、データ分割手段１０３で入力された音声データを分割し、データ振分手段１０４により各送信手段１０５１〜１０５ｎに振り分けることでデータを送信していたが、本実施形態では分割した音声データをすべての送信手段１０５１〜１０５ｎに同時に振り分ける。
【０１４３】
上記の方法において、送信装置１００には、第１の実施形態と比較してｎ倍のデータ量を振り分けることが求められる。しかし、分割された音声データがすべての送信手段に同時に振り分けられることで、再送遅延によりパケットロスとして扱われるデータが少なくなるため、音質劣化が防止される。本実施形態における通信方式を冗長通信と呼ぶことにする。
【０１４４】
以下、本実施形態における冗長通信の動作例を図１４と図１５に示す。図１４は、二つのＴＣＰコネクションを用いた場合の冗長通信の様子の一例を示す説明図である。図１５は、二つのＴＣＰコネクションを用いた場合の冗長通信の様子の他の一例を示す説明図である。
【０１４５】
図１４は、二つのＴＣＰコネクションに同じパケットが送信された例を示す。送信手段１０５１および送信手段１０５２から同じパケットがほぼ同時に送信されているので、受信手段２０１１および受信手段２０１２には同じパケットがほぼ同時に届いている。データ合成手段２０２には受信された同じパケットが二つ届くが、データ合成手段２０２は、先に届いたパケットなど、どちらか一方のパケットのみを利用することによってデータを再構成できる。
【０１４６】
図１５は、ＴＣＰコネクション３０１２のパケット２がロスした場合を示す。パケット２がロスし、データ合成手段２０２において受信手段２０１２から到達するはずのパケット２からパケット６がロスパケットとなった場合でも、データ合成手段２０２には受信手段２０１１から同じパケットが届いているため、音質劣化は生じない。
【０１４７】
図１４および図１５に示す例では、同じデータを同時に二つのＴＣＰコネクションを用いて送信する方法が使用されているが、時間差で送る、同じデータをすべてのＴＣＰコネクションに送るのではなく別の一つ、または複数のＴＣＰコネクションのみに限って送る、データのコピーを送るのではなく行列演算により求めた冗長データを送る、などの方法が使用されることも考えられる。
【０１４８】
次に、本発明の概要を説明する。図１６は、本発明による送信装置の概要を示すブロック図である。本発明による送信装置は、分割されたデータを１つまたは複数のＴＣＰコネクションに振り分けるデータ振分手段１（例えば、データ振分手段１０４）と、通信ネットワークの状態を監視するネットワーク状態監視手段２（例えば、送信側ネットワーク状態監視手段１０７）と、ネットワーク状態監視手段２の監視結果である通信ネットワークの状態に応じてデータの分割方法および分割されたデータの送信方法を変更する送信方法決定手段３（例えば、送信方法決定手段１０８）とを備える。
【０１４９】
そのような構成により、送信装置は、低遅延な音声通話を実現し、かつ音声データの劣化を防止できる。
【０１５０】
送信方法決定手段３は、通信ネットワークの状態に基づいてデータを分割する単位を変更するように構成されていてもよい。
【０１５１】
そのような構成により、送信装置は、ロスパケットの個数を少なくしたり、パケット再送までの時間を短くしたりできる。
【０１５２】
データ振分手段１は、分割されたデータを複数のＴＣＰコネクションに振り分け、送信方法決定手段３は、通信ネットワークの状態に基づいてＴＣＰコネクションの数を変更するように構成されていてもよい。
【０１５３】
そのような構成により、送信装置は、音声データ全体の遅延が発生しないようにできる。
【０１５４】
データ振分手段１は、同じ分割されたデータを複数のＴＣＰコネクションに振り分けるように構成されていてもよい。
【０１５５】
そのような構成により、送信装置は、再送遅延によりロスパケットとして扱われるデータを少なくすることができる。
【０１５６】
データ振分手段１は、複数パケットから計算した冗長データをＴＣＰコネクションに振り分けるように構成されていてもよい。
【０１５７】
そのような構成により、送信装置は、行列演算により求めた冗長データを複数のＴＣＰコネクションに振り分けることができる。
【０１５８】
図１７は、本発明による受信装置の概要を示すブロック図である。本発明による受信装置は、受信した分割データを合成するデータ合成手段１１（例えば、データ合成手段２０２）と、通信ネットワークの状態を監視するネットワーク状態監視手段１２（例えば、受信側ネットワーク状態監視手段２０５）と、ネットワーク状態監視手段１２の監視結果である通信ネットワークの状態に応じて分割データの受信方法および分割データの合成方法を変更する受信方法決定手段１３（例えば、受信方法決定手段２０６）とを備える。
【０１５９】
そのような構成により、受信装置は、低遅延な音声通話を実現し、かつ音声データの劣化を防止できる。
【０１６０】
データ合成手段１１は、所定の遅延時間内に受信できなかった分割データを損失データとして扱い、受信方法決定手段１３は、通信ネットワークの状態に基づいて所定の遅延時間を変更するように構成されていてもよい。
【０１６１】
そのような構成により、受信装置は、できるだけパケットロスを発生させないように許容遅延時間を制御できる。
【０１６２】
受信方法決定手段１３は、通信ネットワークの状態に基づいてＴＣＰコネクションの数を変更するように構成されていてもよい。
【０１６３】
データ合成手段１１は、損失データとして扱った分割データに対してデータ補間を行うように構成されていてもよい。
【０１６４】
そのような構成により、受信装置は、ロスパケットを目立たなくし、音質劣化を防ぐことができる。
【０１６５】
データ合成手段１１は、同じ分割データを複数受信した場合、受信した一つの分割データ以外の分割データを破棄するように構成されていてもよい。
【０１６６】
データ合成手段１１は、受信した冗長データから損失データとして扱った分割データを生成してデータを合成してもよい。
【０１６７】
図１８は、本発明による中継装置の概要を示すブロック図である。本発明による中継装置は、受信した分割データを合成するデータ合成手段２１（例えば、データ合成手段２０２）と、通信ネットワークの状態を監視するネットワーク状態監視手段２２（例えば、受信側ネットワーク状態監視手段２０５）と、ネットワーク状態監視手段２２の監視結果である通信ネットワークの状態に応じて分割データの受信方法および分割データの合成方法を変更する受信方法決定手段２３（例えば、受信方法決定手段２０６）とを備える。
【０１６８】
中継装置は、例えば、ＵＤＰを利用する受信手段を含む。
【０１６９】
中継装置は、例えば、ＵＤＰを利用する送信手段を含む。
【０１７０】
以上、実施形態および実施例を参照して本願発明を説明したが、本願発明は上記実施形態および実施例に限定されるものではない。本願発明の構成や詳細には、本願発明のスコープ内で当業者が理解し得る様々な変更をすることができる。
【０１７１】
この出願は、２０１３年６月２６日に出願された日本特許出願２０１３−１３４０９５を基礎とする優先権を主張し、その開示の全てをここに取り込む。
【産業上の利用の可能性】
【０１７２】
本発明は、送信装置から受信装置に対して音声、映像などのマルチメディアデータを低遅延かつ高品質に通信する通信装置に適用される。
【符号の説明】
【０１７３】
１      データ振分手段
２      ネットワーク状態監視手段
３      送信方法決定手段
１１、２１  データ合成手段
１２、２２  ネットワーク状態監視手段
１３、２３   受信方法決定手段
１０    メディア通信システム
１００  送信装置
１０８  送信方法決定手段
１０７  送信側ネットワーク状態監視手段
２００  受信装置
２０６  受信方法決定手段
２０５  受信側ネットワーク状態監視手段
１０１  メディア入力手段
１０２  符号化手段
１０３  データ分割手段
１０４  データ振分手段
１０５１、１０５２、１０５ｍ、１０５ｎ  送信手段
１０６  送信側コネクション管理手段
２０１１、２０１２、２０１ｍ、２０１ｎ  受信手段
２０２  データ合成手段
２０３  再生手段
２０４  受信側コネクション管理手段
３００  ＩＰネットワーク
３０１１、３０１２、３０１ｍ、３０１ｎ  ＴＣＰコネクション
３０２  ネットワークエミュレータ
４００、４０１  マルチメディアデータ記憶部
５００  マルチメディアデータ
６００、６０１  中継装置
【図１】
2014207978.tif 000003
【図２】
2014207978.tif 000004
【図３】
2014207978.tif 000005
【図４】
2014207978.tif 000006
【図５】
2014207978.tif 000007
【図６】
2014207978.tif 000008
【図７】
2014207978.tif 000009
【図８】
2014207978.tif 000010
【図９】
2014207978.tif 000011
【図１０】
2014207978.tif 000012
【図１１】
2014207978.tif 000013
【図１２】
2014207978.tif 000014
【図１３】
2014207978.tif 000015
【図１４】
2014207978.tif 000016
【図１５】
2014207978.tif 000017
【図１６】
2014207978.tif 000018
【図１７】
2014207978.tif 000019
【図１８】
2014207978.tif 000020
【国際調査報告】
2014207978.tif 000021
2014207978.tif 000022
2014207978.tif 000023
2014207978.tif 000024