(57)【要約】【課題】  リアルタイム性が要求されるデータのデータ送信間隔を一定に保つように制御することで、安定したデータ送信を実現することができるデータ配信装置及びその制御方法、プログラムを提供する。【解決手段】  データ配信装置の処理負荷を監視し、その監視結果に基づいて、データを配信先に一括して配信する一括配信データ数を制御する。【選択図】  図３
2006135793.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークを介して、データの配信先への配信を制御するデータ配信装置であって、
データを前記配信先へ送信する送信手段と、
前記データ配信装置の処理負荷を監視する監視手段と、
前記監視手段の監視結果に基づいて、データを前記配信先に一括して配信する一括配信データ数を制御する制御手段と
を備えることを特徴とするデータ配信装置。
【請求項２】
前記監視手段の監視の結果、前記処理負荷が閾値を越える場合、前記制御手段は、前記一括配信データ数を大きくし、前記処理負荷が閾値を下回る場合、前記一括配信データ数を小さくする
ことを特徴とする請求項１に記載のデータ配信装置。
【請求項３】
前記閾値は、第１閾値及びそれよりも小さい第２閾値を含む少なくとも２つの閾値からなり、
前記監視手段の監視の結果、前記処理負荷が前記第１閾値を越える場合、前記制御手段は、前記一括転送データ数を大きくし、前記処理負荷が前記第２閾値を下回る場合、前記一括配信データ数を小さくする
ことを特徴とする請求項１に記載のデータ配信装置。
【請求項４】
前記閾値は、段階的に大きくなる複数の閾値を有し、かつ前記送信単位は、前記複数の閾値に対応して段階的に大きくなる一括配信データ数を有し、
前記制御手段は、前記監視手段の監視結果に基づいて、前記処理負荷が越える段階の閾値に対応する一括配信データ数を設定する
ことを特徴とする請求項１に記載のデータ配信装置。
【請求項５】
前記データは、音声データである
ことを特徴とする請求項１に記載のデータ配信装置。
【請求項６】
当該データ配信装置は、前記ネットワークを介して、複数の端末と接続可能であり、
前記監視手段は、当該データ配信装置に対する接続端末数を、前記処理負荷として監視する
ことを特徴とする請求項１に記載のデータ配信装置。
【請求項７】
前記監視手段は、当該データ配信装置のオペレーティングシステムの機能によって測定される処理負荷率を、前記処理負荷として監視する
ことを特徴とする請求項１に記載のデータ配信装置。
【請求項８】
ネットワークを介して、配信部によるデータの配信先への配信を制御するデータ配信装置の制御方法であって、
前記データ配信装置の処理負荷を監視する監視工程と、
前記監視工程の監視結果に基づいて、データを前記配信先に一括して配信する一括配信データ数を制御する制御工程と
を備えることを特徴とするデータ配信装置の制御方法。
【請求項９】
ネットワークを介して、配信部によるデータの配信先への配信を制御するデータ配信装置の制御を実現するプログラムであって、
前記データ配信装置の処理負荷を監視する監視工程のプログラムコードと、
前記監視工程の監視結果に基づいて、データを前記配信先に一括して配信する一括配信データ数を制御する制御工程のプログラムコードと
を備えることを特徴とするプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワークを介して、データの配信先への配信を制御するデータ配信装置及びその制御方法、プログラムに関するものである。
【背景技術】
【０００２】
近年、ＩＰ（Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）ネットワークを利用したライブ配信システムやビデオ会議システム等、リアルタイム性が要求されるデータ配信システムが提案されている。
【０００３】
一般に、ライブ配信システムやビデオ会議システムを多人数で使用すると、映像がコマ落ちとして見えたり、音声が途切れたりする場合がある。また、映像と音声の同期をとっている製品は少なく、長時間使用すると映像と音声の同期がずれてくるシステムもある。これらは、映像と音声のデータの性質が異なることが原因である。
【０００４】
ＭｏｔｉｏｎＪＰＥＧ方式に代表される圧縮方法を使用する映像配信は、多量のデータを短時間に送信しなければならない。このため、多人数にリアルタイム性を重視したライブ配信等の配信元の端末となるサーバのＣＰＵ負荷が高い場合、必ずしも全員に全データを送信することはできず、再生側の端末となるクライアントでは、多少のコマ落ちが発生した状態で映像を再生することになってしまう。動画は、多少コマ落ちしても人間の目にはわかりづらいため、このようなベストエフォート型の送信方法が採用されている。
【０００５】
一方、ＶｏＩＰ（Ｖｏｉｃｅ  ｏｖｅｒ  ＩＰ）等に代表される音声配信は、映像と比べ少量のデータを時間を掛けて一定間隔である程度以上の間隔をあけずに送信しなければならない。また、多人数配信等の配信元の端末となるサーバのＣＰＵ負荷が高い場合でも、やはり全員に全データを一定間隔である程度以上の間隔をあけずに送信する必要がある。なぜなら、その理由の１つとして再生側の端末となるクライアントでは、音途切れ、エコーなど不快な音として再生されてしまうことが上げられるからである。
【０００６】
また、通常、再生側の端末では、受信バッファを持っており、ネットワーク上での遅延などを考慮して、音声データをある程度バッファリングしてから音声の再生を行う。しかしながら、リアルタイム性を重視したライブ配信では、数百ミリ秒〜数秒程度しかバッファリングしない。そのため、配信側の端末（サーバ）は、音声データをなるべく小さい単位で、かつ、ある程度以上の間隔を空けずに一定間隔で送信する必要がある。
【０００７】
また、データ配信制御に関する文献としては、特許文献１がある。
【特許文献１】特開平１１−１９１８８３号公報
【発明の開示】
【発明が解決しようとする課題】
【０００８】
同時に多人数に対して音声の配信処理等を行うと、サーバ側のＣＰＵ負荷が高くなる。このような状況では、例えば、音声データがネットワークに送信されるタイミングが待たされてしまったり、同じクライアント宛てのデータでも一括して送信されることによって、クライアント側での受信バッファで吸収できずに、音途切れとして聞こえてしまったりしてしまい、かえって不都合な問題が発生してしまう。
【０００９】
本発明は上記の課題を解決するためになされたものであり、リアルタイム性が要求されるデータのデータ送信間隔を一定に保つように制御することで、安定したデータ送信を実現することができるデータ配信装置及びその制御方法、プログラムを提供することを目的とする。
【課題を解決するための手段】
【００１０】
上記の目的を達成するための本発明によるデータ配信装置は以下の構成を備える。即ち、
ネットワークを介して、データの配信先への配信を制御するデータ配信装置であって、
データを前記配信先へ送信する送信手段と、
前記データ配信装置の処理負荷を監視する監視手段と、
前記監視手段の監視結果に基づいて、データを前記配信先に一括して配信する一括配信データ数を制御する制御手段と
を備える。
【００１１】
上記の目的を達成するための本発明によるデータ配信装置の制御方法は以下の構成を備える。即ち、
ネットワークを介して、データの送信先への送信を制御するデータ配信装置の制御方法であって、
ネットワークを介して、送信部によるデータの送信先への送信を制御するデータ配信装置の制御方法であって、
ネットワークを介して、配信部によるデータの配信先への配信を制御するデータ配信装置の制御方法であって、
前記データ配信装置の処理負荷を監視する監視工程と、
前記監視工程の監視結果に基づいて、データを前記配信先に一括して配信する一括配信データ数を制御する制御工程と
を備える。
【００１２】
上記の目的を達成するための本発明によるプログラムは以下の構成を備える。即ち、
ネットワークを介して、送信部によるデータの送信先への送信を制御するデータ配信装置の制御を実現するプログラムであって、
ネットワークを介して、配信部によるデータの配信先への配信を制御するデータ配信装置の制御を実現するプログラムであって、
前記データ配信装置の処理負荷を監視する監視工程のプログラムコードと、
前記監視工程の監視結果に基づいて、データを前記配信先に一括して配信する一括配信データ数を制御する制御工程のプログラムコードと
を備える。
【発明の効果】
【００１３】
本発明によれば、リアルタイム性が要求されるデータのデータ送信間隔を一定に保つように制御することで、安定したデータ送信を実現することができるデータ配信装置及びその制御方法、プログラムを提供できる。
【発明を実施するための最良の形態】
【００１４】
以下、本発明の実施の形態について図面を用いて詳細に説明する。
【００１５】
（実施形態１）
図１は本発明の実施形態１のデータ配信システムの構成を示す図である。
【００１６】
図１で示すデータ配信システムは、配信サーバ１０２と複数のクライアント１０９とがネットワーク１０８を介して相互に接続されている。
【００１７】
配信サーバ１０２において、１０４は、撮像装置１００からの映像データを受信して、データ圧縮する映像データ処理部である。１０３は、音声入力装置１０１からの音声データを受信して、所定サイズのデータ（パケット）にデータ圧縮する音声データ処理部である。１０５は、演算や処理の制御を行う中央処理装置（以下、ＣＰＵ）である。
【００１８】
１０６は、システムを立ち上げるのに必要なプログラムやデータが記憶されるメモリである。メモリ１０６は、例えば、ＲＡＭ、ＲＯＭ等から構成され、ＲＡＭはデータの作業領域や一時退避領域として機能し、ＲＯＭは初期データや各種パラメータ、プログラム等を記憶する。１０７は、ネットワーク１０８とデータを送受信するネットワーク部である。
【００１９】
また、撮像装置１００や音声入力装置１０１は、配信サーバ１０２内に存在する構成であっても良い。
【００２０】
尚、ネットワーク１０８は、典型的にはインターネットやＬＡＮやＷＡＮや電話回線、専用デジタル回線、ＡＴＭやフレームリレー回線、通信衛星回線、ケーブルテレビ回線、データ放送用無線回線等のいずれか、またはこれらの組み合わせにより実現されるいわゆる通信ネットワークであり、データの送受信が可能であれば良い。
【００２１】
次に、配信サーバ１０２の通常のデータ配信動作シーケンスについて、図２を用いて説明する。
【００２２】
図２は本発明の実施形態１の配信サーバの通常のデータ配信動作シーケンスを示す図である。
【００２３】
配信サーバ１０２において、ＣＰＵ１０５には、大きく３つの機能がある。具体的には、映像配信を制御する機能である映像制御部２０３と、音声配信を制御する機能である音声制御部２０４と、そして、ＣＰＵ負荷を監視する機能であるＣＰＵ負荷監視部２０５である。この３つの機能は、実施形態１において、同じＣＰＵ資源を共有して使用しているものとする。
【００２４】
映像制御部２０３と音声制御部２０４は、クライアント１０９からの配信要求をネットワーク部２０６から受信すると、次のように、映像データと音声データを配信する。
【００２５】
映像配信に関しては、まず、映像データ処理部１０４は、入力された映像信号を圧縮して画像データを生成する。映像制御部２０３は、ネットワーク部２０６に画像送信を実行するように要求する。この時、配信要求先のクライアントすべて（図２では、ａ＋１台あるいはユーザ）に画像データの送信を行う。ネットワーク部１０７は、送信要求に従って、送信先のクライアント１０９へデータを送信する。
【００２６】
音声配信に関しては、まず、音声データ処理部１０３は、入力された音声信号を圧縮して音声データを生成する。音声制御部２０４では、リアルタイム性を損なわない程度のデータ数Ｎ（図２では、Ｎ＝２）まで音声データを蓄積し、Ｎ個の音声データを一括してネットワーク部１０７に対して配信要求先のクライアントに音声送信するように要求する。この時、配信要求先のクライアントすべて（図２では、ａ＋１台あるいはユーザ）に音声送信を行う。ネットワーク部１０７は、送信要求に従って、送信先のクライアント１０９へデータを送信する。
【００２７】
次に、実施形態１の特徴的な音声配信動作シーケンスについて、図３を用いて説明する。
【００２８】
図３は本発明の実施形態１の音声配信動作シーケンスを示す図である。
【００２９】
ＣＰＵ１０５では、上述の映像配信処理と音声配信処理を制御すると同時に、ＣＰＵ負荷監視部２０５において、現在のＣＰＵ負荷がどの程度なのかを常に監視している。
【００３０】
ここで、ＣＰＵ負荷は、例えば、配信サーバ１０２に接続しているクライアント数（あるいはユーザ数）に比例して負荷が大きくなると示すことができ、一定数を越えるとＣＰＵ負荷は高い、一定数を下回るとＣＰＵ負荷は低いと表すことができる。
【００３１】
実施形態１では、ＣＰＵ負荷監視部２０５は、接続クライアント数がある所定閾値を越えると、ＣＰＵ負荷が高いと判定し、音声制御部３０４にその旨を通知する。音声制御部３０４は、ＣＰＵ負荷が高いという通知を受信すると、一括して送信すべき音声データの送信データ数を増やす。例えば送信データ数Ｍ＝Ｎ＋ｎ（ｎ＞＝１、図３では、ｎ＝２）に変更し、Ｍ個蓄積するまでデータ送信処理を禁止する。
【００３２】
尚、送信個数は、音声データの送信単位が途中で変更されても、予め情報として取得しておいたクライアント１０９側の受信メモリバッファの容量で吸収できる範囲で決定されるものである。この場合、クライアント１０９側で受信する音声データの音途切れを防止して、リアルタイム性も損なわれないようにすることができる。
【００３３】
このように、音声制御部２０４からネットワーク部１０７へ一括に送信する音声データの送信個数を大きくすることにより、ネットワーク部１０７からクライアント１０９への送信回数を減らすことができる。これは、音声制御部２０４での処理に必要なＣＰＵ占有時間が減り、ＣＰＵ占有時間が少ないことによる送信間隔のずれを低減できることを意味する。
【００３４】
音声制御部２０４は、ＣＰＵ負荷管理部２０５から、ＣＰＵ負荷が小さいという通知を受信するまで、送信個数Ｍ個毎にデータ送信を実行する。そして、音声制御部２０４は、ＣＰＵ負荷管理部２０５から、ＣＰＵ負荷が小さくなったという通知を受信した後は、また、元のＮ個毎にデータ送信を実施する。
【００３５】
次に、実施形態１の音声配信動作について、図４を用いて説明する。
【００３６】
図４は本発明の実施形態１の音声配信動作を示すフローチャートである。
【００３７】
ステップＳ１０１で、音声制御部２０４は、音声データ処理部１０３から受信した音声データを、所定の一括データ転送数で、ネットワーク部１０７を介して各クライアントへ配信する。
【００３８】
ステップＳ１０２で、ＣＰＵ負荷監視部２０５の監視の結果に基づいて、配信サーバ１０２の処理負荷（ＣＰＵ負荷）が閾値を越えているか否かを判定する。閾値を越えていない場合（ステップＳ１０２でＮＯ）、ステップＳ１０１に戻る。一方、閾値を越えている場合（ステップＳ１０２でＹＥＳ）、現在の一括データ転送数を大きくして、音声データをネットワーク部１０７を介して各クライアントに配信し、ステップＳ１０２に戻る。
【００３９】
以上説明したように、実施形態１によれば、配信サーバ１０２のＣＰＵ負荷が高くなった場合には、音声データの送信単位を大きくすることにより、送信間隔のずれを低減することができ、クライアント１０９側での音途切れを解消することができる。
【００４０】
つまり、配信サーバ１０２のＣＰＵ負荷が一定の閾値を超えた場合には、音声の送信単位を大きくし、送信処理回数を減らすことによって、音声データの送信間隔のずれを最小限に抑えることができる。
【００４１】
（実施形態２）
実施形態１では、ＣＰＵ負荷の閾値として一定値を用いており、この閾値を超えた場合に、ＣＰＵ負荷が高いという通知を出力する構成としたが、ＣＰＵ負荷が高いと判定する基準とＣＰＵ負荷が低いという基準が同じ値である必要はなく、ＣＰＵ負荷が低いと判定する第１判定基準（第１閾値）を設け、この第１判定基準を、ＣＰＵ負荷が高いと判定する第２判定基準（第２閾値）より低くすることによって、頻繁に送信単位が変更してしまうことを防ぐことができる。
【００４２】
つまり、同じ判定基準を用いると、ＣＰＵ負荷が、閾値近辺で上がったり下がったりした場合に、音声データの送信単位が例えば、Ｎ個とＭ個と短期間に何度も変化してしまうことにより、クライアント１０９にとっては、送信間隔が一定とならず、音声データを受信するための受信バッファがアンダーフローを起こし、音途切れが発生する可能性がある。
【００４３】
これに対し、判定基準が異なると、ＣＰＵ負荷が高いと判定する基準値近辺で上がったり下がったりした場合でも、送信単位がＮ個、Ｍ個と何度も変わることがなくなる。つまり、一度送信単位が変更されると、簡単には再度変更されることがなくなるため、クライアントにとっても、送信間隔がすぐに一定になり、受信バッファがアンダーフローを起こす可能性が低くすることができる。
【００４４】
（実施形態３）
実施形態１や２では、ＣＰＵ負荷の閾値として一つしか用いなかったが、ＣＰＵ負荷の閾値が一つである必要はなく、複数の閾値を設定することにより、送信単位がＮ個からＭ個へ変わる時の瞬間的な送信間隔の誤差を減らすことができる。
【００４５】
例えば、ＣＰＵ負荷が７０％でいきなり、送信単位が４０ｍｓから８０ｍｓに変更されると、クライアント１０９では、瞬間的に４０ｍｓの送信誤差が発生したような処理になる。しかしながら、ＣＰＵ負荷が６０％、７０％、８０％、９０％と上昇した場合には、送信単位を５０ｍｓ、６０ｍｓ、７０ｍｓ、８０ｍｓとすることで、クライアントでの瞬間送信誤差が１０ｍｓで収まり、より受信バッファがオーバフローを起こす可能性が低くすることができる。
【００４６】
つまり、段階的に大きくなる複数の閾値を設けて、各閾値を基準に、送信単位を段階的に変更する（大きくする）ことで、瞬間的な送信間隔の誤差を減らすことができる。
【００４７】
（実施形態４）
実施形態１〜３では、ＣＰＵ負荷を、配信サーバ１０２に対する接続クライアント数として監視しているが、ＣＰＵ負荷の監視はこれに限定されるものではない。例えば、配信サーバ１０２に搭載されるＯＳの機能によって測定される処理負荷率を、ＣＰＵ負荷として監視する構成としても良い。例えば、装置内部の各処理にCPU負荷の割合いを示す数字を算出し、この割合の和をＣＰＵ負荷として定義してもよい。
【００４８】
以上、実施形態例を詳述したが、本発明は、例えば、システム、装置、方法、プログラムもしくは記憶媒体等としての実施態様をとることが可能であり、具体的には、複数の機器から構成されるシステムに適用しても良いし、また、一つの機器からなる装置に適用しても良い。
【００４９】
尚、本発明は、前述した実施形態の機能を実現するソフトウェアのプログラム（実施形態では図に示すフローチャートに対応したプログラム）を、システムあるいは装置に直接あるいは遠隔から供給し、そのシステムあるいは装置のコンピュータが該供給されたプログラムコードを読み出して実行することによっても達成される場合を含む。
【００５０】
従って、本発明の機能処理をコンピュータで実現するために、該コンピュータにインストールされるプログラムコード自体も本発明を実現するものである。つまり、本発明は、本発明の機能処理を実現するためのコンピュータプログラム自体も含まれる。
【００５１】
その場合、プログラムの機能を有していれば、オブジェクトコード、インタプリタにより実行されるプログラム、ＯＳに供給するスクリプトデータ等の形態であっても良い。
【００５２】
プログラムを供給するための記録媒体としては、例えば、フロッピー（登録商標）ディスク、ハードディスク、光ディスク、光磁気ディスク、ＭＯ、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＣＤ−ＲＷ、磁気テープ、不揮発性のメモリカード、ＲＯＭ、ＤＶＤ（ＤＶＤ−ＲＯＭ，ＤＶＤ−Ｒ）などがある。
【００５３】
その他、プログラムの供給方法としては、クライアントコンピュータのブラウザを用いてインターネットのホームページに接続し、該ホームページから本発明のコンピュータプログラムそのもの、もしくは圧縮され自動インストール機能を含むファイルをハードディスク等の記録媒体にダウンロードすることによっても供給できる。また、本発明のプログラムを構成するプログラムコードを複数のファイルに分割し、それぞれのファイルを異なるホームページからダウンロードすることによっても実現可能である。つまり、本発明の機能処理をコンピュータで実現するためのプログラムファイルを複数のユーザに対してダウンロードさせるＷＷＷサーバも、本発明に含まれるものである。
【００５４】
また、本発明のプログラムを暗号化してＣＤ−ＲＯＭ等の記憶媒体に格納してユーザに配布し、所定の条件をクリアしたユーザに対し、インターネットを介してホームページから暗号化を解く鍵情報をダウンロードさせ、その鍵情報を使用することにより暗号化されたプログラムを実行してコンピュータにインストールさせて実現することも可能である。
【００５５】
また、コンピュータが、読み出したプログラムを実行することによって、前述した実施形態の機能が実現される他、そのプログラムの指示に基づき、コンピュータ上で稼動しているＯＳなどが、実際の処理の一部または全部を行ない、その処理によっても前述した実施形態の機能が実現され得る。
【００５６】
さらに、記録媒体から読み出されたプログラムが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれた後、そのプログラムの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部または全部を行ない、その処理によっても前述した実施形態の機能が実現される。
【図面の簡単な説明】
【００５７】
【図１】本発明の実施形態１のデータ配信システムの構成を示す図である。
【図２】本発明の実施形態１の配信サーバの通常のデータ配信動作シーケンスを示す図である。
【図３】本発明の実施形態１の音声配信動作シーケンスを示す図である。
【図４】本発明の実施形態１の音声配信動作を示すフローチャートである。
【符号の説明】
【００５８】
３００  音声データ処理部
３０１  映像データ処理部
３０２  ＣＰＵ
３０３  映像制御部
３０４  音声制御部
３０５  ＣＰＵ負荷監視部
３０６  ネットワーク部
【図１】
2006135793.tif 000003
【図２】
2006135793.tif 000004
【図３】
2006135793.tif 000005
【図４】
2006135793.tif 000006