(57)【要約】【課題】各クライアント端末における受信品質に基いてそのストリーム配信を制御したストリーム配信方法、クライアント端末、装置、システム及びプログラム並びに該プログラムを記録した記録媒体の提供。【解決手段】ストリーム配信装置２からストリームデータパケットを受信しパケット損失がないかを確認するデータ受信部４２、データ受信部４２によりパケット損失の通知があると、一定期間毎にパケット損失数を計数し、その値が閾値を超えたか否かを判断し、閾値以下であればパケット再送を要求する一方、閾値超過であれば帯域変更制御パケットを送信するクライアント制御部４１ａを備えたクライアント端末４を一以上と、ストリーム配信装置２を一以上とをＩＰネットワーク５で相互交信接続自在とし、かつストリーム配信装置２に対して同一コンテンツに対して複数の帯域でストリームデータを配信するサーバ１とでシステム構築した特徴的構成手段の採用。【選択図】図６
2004048450.tif 000002
【特許請求の範囲】
【請求項１】
一以上のストリーム配信装置がストリームデータを一以上のクライアント端末に配信する方法であって、
当該クライアント端末各々において、一定期間毎にパケット損失数を計数して、当該パケット損失数を当該クライアント端末毎の閾値と比較し、当該比較の結果、損失したパケットの再送を要求するか又は前記ストリーム配信装置から受信するストリームデータの帯域の減少を要求するかの何れの要求を行うか決定して、当該決定した要求を行う、
ことを特徴とするストリーム配信方法。
【請求項２】
一以上のストリーム配信装置がストリームデータを一以上のクライアント端末に配信する方法であって、
当該クライアント端末各々において、パケットの損失を検知すると、当該クライアント端末に前記ストリームデータを配信した前記ストリーム配信装置に対してパケット損失を通知する一方、
当該通知を受けたストリーム配信装置において、一定期間毎にパケット損失数を計数し、当該通知をなしたクライアント端末毎の閾値と比較した結果、損失したパケットを再送するか又は当該通知を発したクライアント端末に対して送信する際の帯域を現時点での帯域より減少するかの何れを行うかを決定して、当該決定に従う、
ことを特徴とするストリーム配信方法。
【請求項３】
前記閾値は、
前記クライアント端末毎に、一定期間毎のパケット損失数その他の品質データに基いて自動的に可変に設定された値である、
ことを特徴とする請求項１又は２に記載のストリーム配信方法。
【請求項４】
前記決定は、
前記計数したパケット損失数に加えて、前記クライアント端末が受信した総データ量、平均伝送速度、当該クライアント端末が受けたパケット再送の成功数の内一以上の品質データをも加味して行われる、
ことを特徴とする請求項１、２又は３に記載のストリーム配信方法。
【請求項５】
ストリーム配信装置からストリームデータを受ける端末であって、
前記ストリーム配信装置からストリームデータパケットを受信すると共に、パケット損失がないかを確認するデータ受信部と、
前記ストリーム配信装置と一旦確立したセッション中において前記データ受信部によりパケット損失の通知があると、一定期間毎にパケット損失数を計数すると共に、当該計数した値が自己固有の閾値を超えたか否かを判断し、閾値以下であれば当該ストリーム配信装置にパケット再送を要求する一方、閾値超過であれば当該ストリーム配信装置に帯域変更を要求するクライアント制御部と、を具備した、
ことを特徴とするストリーム配信クライアント端末。
【請求項６】
前記クライアント制御部は、
前記閾値を、パケット損失数その他の品質データに基いて自動に可変に設定できる、
ことを特徴とする請求項５に記載のストリーム配信クライアント端末。
【請求項７】
請求項５又は６に記載のストリーム配信クライアント端末を一以上と、前記要求に応じるストリーム配信装置を一以上とをネットワークで接続自在とし、かつ当該ストリーム配信装置に対して同一コンテンツに対して複数の帯域でストリームデータを配信するサーバとでシステム構築した、
ことを特徴とするストリーム配信システム。
【請求項８】
一以上のクライアント端末に対してストリーム配信を行う装置であって、
前記クライアント端末毎にストリームデータパケットを送信するデータ送信部と、
前記クライアント端末からパケット損失の通知があると、一定期間毎にパケット損失数を計数すると共に、当該計数した値が当該クライアント端末毎の閾値を超えたか否かを判断し、閾値以下であれば前記データ送信部にパケット再送を指示する一方、閾値超過であれば帯域変更を行う配信装置制御部と、を具備した、
ことを特徴とするストリーム配信装置。
【請求項９】
前記配信装置制御部は、
前記閾値を、パケット損失数その他の品質データに基いて自動的に可変に設定できる、
ことを特徴とする請求項８に記載のストリーム配信装置。
【請求項１０】
請求項８又は９に記載のストリーム配信装置を一以上と、当該ストリーム配信装置の一装置からストリーム配信を受け、前記パケット損失の通知を行える前記クライアント端末を一以上とをネットワークで接続自在とし、かつ当該ストリーム配信装置に対して同一コンテンツに対して複数の帯域でストリームデータを配信するサーバとでシステム構築した、
ことを特徴とするストリーム配信システム。
【請求項１１】
ストリーム配信を受けるクライアント端末に格納されて利用に供されるプログラムであって、
配信されたストリームデータを受信するデータ受信部からストリームデータのパケット損失の通知を受けたか否かの第一判断を行う手順と、
前記第一判断手順にて肯定の場合には、パケット損失カウンタをインクリーメントした後に、当該パケット損失カウンタの値が自己固有の閾値を超えているか否かを判断し、ストリーム配信装置に対して、当該判断において、肯定の場合には帯域変更要求を、否定の場合にはパケット再送の要求をそれぞれ行う手順と、
前記第一判断手順にて否定の場合には、単位時間を経過したか否かを判断し、経過している場合に限り、当該プログラム内の変数の初期化を行う手順と、
以上の手順を繰返し実行する、
ことを特徴とするストリーム配信プログラム。
【請求項１２】
サーバから複数の帯域にてストリームデータを受信し、一以上のクライアント端末に対して当該受信したストリームデータを配信するストリーム配信装置に格納されて利用に供されるプログラムであって、
前記クライアント端末からストリームデータのパケット損失の通知を受けたか否かの第一判断を行う手順と、
前記第一判断手順にて肯定の場合には、パケット損失カウンタをインクリーメントした後に、当該パケット損失カウンタの値がクライアント端末毎の閾値を超えているか否かを判断し、ストリーム配信装置内のデータ送信部に対して、当該判断において、肯定の場合には帯域変更を、否定の場合にはパケット再送を、それぞれ行うことを通知する手順と、
前記第一判断手順にて否定の場合には、単位時間を経過したか否かを判断し、経過している場合に限り、当該プログラム内の変数についての初期化を行う手順と、
以上の手順を繰返し実行する、
ことを特徴とするストリーム配信プログラム。
【請求項１３】
前記プログラムは、
前記第一判断手順にて否定の場合に行う判断にて単位時間を経過している場合には、単位時間に関する変数のみ初期化し、前記閾値を、単位時間毎のパケット損失数の平均値を計算してそれを元に変更設定する手順をも含む、
ことを特徴とする請求項１１又は１２に記載のストリーム配信プログラム。
【請求項１４】
請求項１１、１２又は１３に記載のストリーム配信プログラムを記録媒体に実録した、
ことを特徴とするストリーム配信プログラムを記録した記録媒体。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、ストリーム配信（音声、映像の何れか又は双方を含ん行われる配信）においてネットワークの品質劣化に強いストリーム配信方法、クライアント端末、装置、システム及びプログラム並びに該プログラムを記録した記録媒体に関するものである。
【０００２】
【従来の技術】
従来、ストリーム配信（サービス）においては、クライアントがストリーム配信装置に対して伝送速度（帯域、帯域幅）と共に最初に視聴したいコンテンツを要求することにより、視聴が開始されている。
通常、ストリーム配信は、ネットワーク経由でクライアントに配信されるところ、ネットワークの輻輳その他の影響により、ストリームデータが廃棄される結果、クライアントにおける再生映像の品質に劣化をきたすことがあった。
【０００３】
このような現状を回避する為に、従来においては、クライアントは受信品質を検出する機能を具備し、（α）損失パケットの再送をストリーム配信装置に要求する手法、（β）ネットワークの込み具合にあわせて配信する伝送速度（配信帯域）を上下する要求をストリーム配信装置に送信し、ストリーム配信装置側において伝送速度（配信帯域）をその都度変更する手法、という各手法により対応されていた。
【０００４】
なお、（β）のストリーム帯域変更制御は、Ｒｅａｌ　Ｎｅｔｗｏｒｋｓ社のＳｕｒｅ　Ｓｔｒｅａｍ、Ｍｉｃｒｏｓｏｆｔ社のＩｎｔｅｌｌｉｇｅｎｔ　Ｓｔｒｅａｍが一般的であり、共にマルチビームレートでストリームコンテンツを構成し、状況にあわせてレートを変更できる、というものである。
【０００５】
【発明が解決しようとする課題】
しかしながら、従来の技術にあっては次のような点が問題となる。
第一に、パケット損失の少ない場合は（α）の手法により、ストリーム品質を維持することが得策である。また、パケット損失が多くなった場合は（β）の手法によりレートダウンすることでストリーム品質を犠牲にする代わりにパケット損失数を減らしていた。
【０００６】
この点、理想的には、できるだけ（α）の手法で品質を維持すべきであるが、従来の手法では品質劣化を判定してレートダウンする基準（閾値）が全てのクライアントに対して同一となっていた。
【０００７】
よって、ネットワーク品質が低い（即ち、パケット損失数が多い）ネットワークに接続されたクライアントは、（α）の手法でもって品質を維持できるにも拘わらずレートダウンする確率が高いという問題がある（従って、レートダウンするか否かの判断基準は、その端末に接続されたネットワークの品質実績値をベースに規定すべきことになる。）。
【０００８】
第二に、クライアント毎に（β）の手法によりレートダウンする基準は実際に測定した結果からしか決定できないところ、エンドユーザがその値をチューニングするのは専門的な知識が要求されることになるので、現実的ではないという問題がある（そこで、ストリーム配信装置又はクライアントが測定した品質実績値をベースに自動的に決定する必要があるということになる。）。
【０００９】
第三に、レート変更の判断は、クライアント側で行うケースとストリーム配信装置側で行うケースとが考えられるところ、従来にあってはクライアント側で実施されている。しかしそれでは、クライアントはコンテンツのビットレートが大きい場合、映像データのデコード処理や描画処理にＣＰＵパワーを必然的に大きく消費させなければならないという問題がある（そこで、ストリーム配信装置側へかかる処理を分担させた方がクライアント側の負荷を軽くすることにつながる。）。
【００１０】
ここにおいて、本発明の解決すべき主要な目的は以下の通りである。
即ち、本発明の第１の目的は、ストリーム配信（サービス）において、各クライアント端末における受信品質に基いてストリーム配信品質を制御する、ストリーム配信方法、クライアント端末、装置、システム及びプログラム並びに該プログラムを記録した記録媒体を提供するものである。
【００１１】
本発明の第２の目的は、各クライアント端末とストリーム配信装置との間の通信網とか通信回線の時間的な変動に対応できる、ストリーム配信方法、クライアント端末、装置、システム及びプログラム並びに該プログラムを記録した記録媒体を提供するものである。
【００１２】
本発明の第３の目的は、各クライアント端末における処理負担を可及的に低減した、ストリーム配信方法、クライアント端末、装置、システム及びプログラム並びに該プログラムを記録した記録媒体を提供するものである。
【００１３】
本発明の他の目的は、明細書、図面、特に特許請求の範囲における各請求項の記載から自ずと明らかとなろう。
【００１４】
【課題を解決するための手段】
本発明方法は、上記課題の解決に当たり、クライアント端末各々において、一定期間毎にパケット損失数を計数して、当該パケット損失数を当該クライアント端末毎の閾値と比較した結果、損失したパケットの再送を要求するか又は帯域の減少を要求するかの何れの要求を行うかを決定してその要求を行うか、又は、クライアント端末各々において、パケットの損失を検知すると、当該クライアント端末にストリームデータを配信したストリーム配信装置に対してパケット損失を通知する一方、当該通知を受けたストリーム配信装置において、一定期間毎にパケット損失数を計数し、当該通知をなしたクライアント端末毎の閾値と比較した結果、損失したパケットを再送するか又は帯域減少処理の何れを行うかを決定してそれを実施する、という特徴的構成手法を講ずる。
【００１５】
本発明端末は、上記課題の解決に当たり、ストリーム配信装置からストリームデータパケットを受信すると共に、パケット損失がないかを確認するデータ受信部と、ストリーム配信装置と一旦確立したセッション中においてデータ受信部によりパケット損失の通知があると、一定期間毎にパケット損失数を計数すると共に、当該計数した値が自己固有の閾値を超えたか否かを判断し、閾値以下であれば当該ストリーム配信装置にパケット再送を要求する一方、閾値超過であれば当該ストリーム配信装置に帯域変更制御パケットを送信するクライアント制御部と、を具備する、という特徴的構成手段を講じる。
【００１６】
本発明装置は、上記課題の解決に当たり、クライアント端末毎にストリームデータパケットを送信するデータ送信部と、当該クライアント端末からパケット損失の通知があると、一定期間毎にパケット損失数を計数すると共に、当該計数した値が当該クライアント端末毎の閾値を超えたか否かを判断し、閾値以下であればデータ送信部にパケット再送を指示する一方、閾値超過であれば帯域変更を行う配信装置制御部とを具備した、という特徴的構成手段を講ずる。
【００１７】
本発明システムは、上記課題の解決に当たり、本発明端末を一以上とそれに対応したストリーム配信装置を一以上ネットワークで接続自在に、又は本発明装置を一以上とそれに対応したクライアント端末を一以上ネットワークで接続自在に、かつストリーム配信装置又は本発明装置の何れかに対して同一コンテンツに対して複数の帯域でストリームデータを配信するサーバとでシステム構築した、という特徴的構成手段を講ずる。
【００１８】
本発明プログラムは、上記課題の解決に当たり、本発明方法をクライアント端末、ストリーム配信装置に対応して実行させる手順をプログラム化した、という特徴的構成手順を講じる。
【００１９】
本発明記録媒体は、上記課題の解決に当たり、本発明プログラム手順を記録媒体を通して実践するよう実録した、という特徴的構成手続を講じる。
【００２０】
更に、具体的詳細に述べると、当該課題の解決では、本発明が次に列挙する新規な特徴的構成手法、手段、手順又は手続を採用することにより、上記目的を達成するようになされる。
【００２１】
本発明方法の第１の特徴は、一以上のストリーム配信装置がストリームデータを一以上のクライアント端末に配信する方法であって、当該クライアント端末各々において、一定期間毎にパケット損失数を計数して、当該パケット損失数を当該クライアント端末毎の閾値と比較し、当該比較の結果、損失したパケットの再送を要求するか又は前記ストリーム配信装置から受信するストリームデータの帯域の減少を要求するかの何れの要求を行うか決定して、当該決定した要求を行ってなる、ストリーム配信方法の構成採用にある。
【００２２】
本発明方法の第２の特徴は、一以上のストリーム配信装置がストリームデータを一以上のクライアント端末に配信する方法であって、当該クライアント端末各々において、パケットの損失を検知すると、当該クライアント端末に前記ストリームデータを配信した前記ストリーム配信装置に対してパケット損失を通知する一方、当該通知を受けたストリーム配信装置において、一定期間毎にパケット損失数を計数し、当該通知をなしたクライアント端末毎の閾値と比較した結果、損失したパケットを再送するか又は当該通知を発したクライアント端末に対して送信する際の帯域を現時点での帯域より減少するかの何れを行うかを決定して、当該決定に従ってなる、ストリーム配信方法の構成採用にある。
【００２３】
本発明方法の第３の特徴は、上記本発明方法の第１又は第２の特徴における前記閾値が、前記クライアント端末毎に、一定期間毎のパケット損失数その他の品質データに基いて自動的に可変に設定された値である、ストリーム配信方法の構成採用にある。
【００２４】
本発明方法の第４の特徴は、上記本発明方法の第１、第２又は第３の特徴における前記決定が、前記計数したパケット損失数に加えて、前記クライアント端末が受信した総データ量、平均伝送速度、当該クライアント端末が受けたパケット再送の成功数の内一以上の品質データをも加味して行われてなる、ストリーム配信方法の構成採用にある。
【００２５】
本発明端末の第１の特徴は、ストリーム配信装置からストリームデータを受ける端末であって、前記ストリーム配信装置からストリームデータパケットを受信すると共に、パケット損失がないかを確認するデータ受信部と、前記ストリーム配信装置と一旦確立したセッション中において前記データ受信部によりパケット損失の通知があると、一定期間毎にパケット損失数を計数すると共に、当該計数した値が自己固有の閾値を超えたか否かを判断し、閾値以下であれば当該ストリーム配信装置にパケット再送を要求する一方、閾値超過であれば当該ストリーム配信装置に帯域変更を要求するクライアント制御部と、を具備してなる、ストリーム配信クライアント端末の構成採用にある。
【００２６】
本発明端末の第２の特徴は、上記本発明端末の第１の特徴における前記クライアント制御部が、前記閾値を、パケット損失数その他の品質データに基いて自動に可変に設定できてなる、ストリーム配信クライアント端末の構成採用にある。
【００２７】
本発明システムの第１の特徴は、本発明端末であるストリーム配信クライアント端末を一以上と、前記要求に応じるストリーム配信装置を一以上とをネットワークで接続自在とし、かつ当該ストリーム配信装置に対して同一コンテンツに対して複数の帯域でストリームデータを配信するサーバとでシステム構築してなる、ストリーム配信システムの構成採用にある。
【００２８】
本発明装置の第１の特徴は、一以上のクライアント端末に対してストリーム配信を行う装置であって、前記クライアント端末毎にストリームデータパケットを送信するデータ送信部と、前記クライアント端末からパケット損失の通知があると、一定期間毎にパケット損失数を計数すると共に、当該計数した値が当該クライアント端末毎の閾値を超えたか否かを判断し、閾値以下であれば前記データ送信部にパケット再送を指示する一方、閾値超過であれば帯域変更を行う配信装置制御部と、を具備してなる、ストリーム配信装置の構成採用にある。
【００２９】
本発明装置の第２の特徴は、上記本発明装置第１の特徴における前記配信装置制御部が、前記閾値を、パケット損失数その他の品質データに基いて自動的に可変に設定できる、ストリーム配信装置の構成採用にある。
【００３０】
本発明システムの第２の特徴は、本発明装置であるストリーム配信装置を一以上と、当該ストリーム配信装置の一装置からストリーム配信を受け、前記パケット損失の通知を行える前記クライアント端末を一以上とをネットワークで接続自在とし、かつ当該ストリーム配信装置に対して同一コンテンツに対して複数の帯域でストリームデータを配信するサーバとでシステム構築してなる、ストリーム配信システムの構成採用にある。
【００３１】
本発明プログラムの第１の特徴は、ストリーム配信を受けるクライアント端末に格納されて利用に供されるプログラムであって、配信されたストリームデータを受信するデータ受信部からストリームデータのパケット損失の通知を受けたか否かの第一判断を行う手順と、前記第一判断手順にて肯定の場合には、パケット損失カウンタをインクリーメントした後に、当該パケット損失カウンタの値が自己固有の閾値を超えているか否かを判断し、ストリーム配信装置に対して、当該判断において、肯定の場合には帯域変更要求を、否定の場合にはパケット再送の要求をそれぞれ行う手順と、前記第一判断手順にて否定の場合には、単位時間を経過したか否かを判断し、経過している場合に限り、当該プログラム内の変数の初期化を行う手順と、以上の手順を繰返し実行してなる、ストリーム配信プログラムの構成採用にある。
【００３２】
本発明プログラムの第２の特徴は、サーバから複数の帯域にてストリームデータを受信し、一以上のクライアント端末に対して当該受信したストリームデータを配信するストリーム配信装置に格納されて利用に供されるプログラムであって、前記クライアント端末からストリームデータのパケット損失の通知を受けたか否かの第一判断を行う手順と、前記第一判断手順にて肯定の場合には、パケット損失カウンタをインクリーメントした後に、当該パケット損失カウンタの値がクライアント端末毎の閾値を超えているか否かを判断し、ストリーム配信装置内のデータ送信部に対して、当該判断において、肯定の場合には帯域変更を、否定の場合にはパケット再送を、それぞれ行うことを通知する手順と、前記第一判断手順にて否定の場合には、単位時間を経過したか否かを判断し、経過している場合に限り、当該プログラム内の変数についての初期化を行う手順と、以上の手順を繰返し実行してなる、ストリーム配信プログラムの構成採用にある。
【００３３】
本発明プログラムの第３の特徴は、上記本発明プログラムの第１又は第２の特徴における前記プログラムが、前記第一判断手順にて否定の場合に行う判断にて単位時間を経過している場合には、単位時間に関する変数のみ初期化し、前記閾値を、単位時間毎のパケット損失数の平均値を計算してそれを元に変更設定する手順をも含んでなる、ストリーム配信プログラムの構成採用にある。
【００３４】
本発明記録媒体の第１の特徴は、上記本発明プログラムを記録媒体に実録してなる、ストリーム配信プログラムを記録した記録媒体の構成採用にある。
【００３５】
【発明の実施の形態】
以下、本発明の実施の形態を説明するに際して、最初にその概要を説明し、その後、それを具現化したシステム例、方法例、装置例、プログラム例及び記録媒体例の順に、該当図面を参照して説明する。
【００３６】
（概要）
本発明は、パケット再送処理及びレート変更処理の切替ポイントとなる閾値を、クライアント毎に決定する、ということにある。
この点を説明すると、以下のようになる。
【００３７】
［第一コンセプト］
第一コンセプトとしては、クライアントは、その値（閾値）と受信したパケットの損失数を比較することにより、パケット再送要求かレート変更要求の何れをストリーム配信装置に送信するように構成する。
【００３８】
これにより、クライアント毎に、受信ストリームデータの帯域を現時点での帯域から減少する基準となる閾値を設定できることになる。よって、品質劣化が大きいネットワークが本来パケットの再送により元の品質でもって配信できたにも拘わらず、受信ストリームデータの帯域を減少（つまり、品質を低下）させてしまう確率を低く抑えることができる。
【００３９】
［第二コンセプト］
第二コンセプトとしては、基本的なコンセプトは前述の第一コンセプトと同じであるものの、クライアントは、パケット損失（数）のみをストリーム配信装置に通知するようにし、当該通知を受けたストリーム配信装置がクライアントからの再送に応じるか又はレートを変更するかの判断を行うように構成する。
【００４０】
これにより、第一コンセプトと異なり、クライアント側にあっては、パケット損失という品質データをストリーム配信装置に送信する構成で足りることから、クライアントにおける負荷を低減させることができる。
【００４１】
［第三コンセプト］
第三コンセプトとしては、かかる二つのコンセプトを更に推し進め、クライアント毎にそのクライアントのパケット損失数の計算値を元にして、各クライアントに適したパケット再送処理とレート変更処理とを切り替える切替ポイント（切替基準）である閾値を自動的に決定するように構成する。
【００４２】
これにより、各クライアントとストリーム配信装置の間において計数した一定の期間当たりのパケット損失数の実績値をベースにして、受信ストリームデータの帯域を現時点の帯域から減少する閾値を自動的に設定することができるようになるので、ネットワークの伝送品質が変化してもその変化に追従できるようになる。
【００４３】
［第四コンセプト］
第四コンセプトとしては、品質劣化を示すパラメータとして、パケット損失数の他に、クライアントが受信した総データ量、平均帯域、クライアントが受けたパケット再送の成功数など、その他のクライアント品質データを利用するように構成する。これにより、より性能のよいストリーム配信が実現できるようになる。
【００４４】
前述の概要を具現化した本発明の一実施形態につき説明するも、原則的に前述の第一コンセプトに関する発明につき説明し、その他のコンセプトに関する発明はそれとの相違を説明することにする。
【００４５】
（システム例）
図１は、本発明の一実施形態であるストリーム配信装置及びクライアント端末を構成要素とするストリーム配信システムにおける接続概念構成図である。
図中、１はサーバ、２はストリーム配信装置、３はネットワーク回線、４はクライアント端末である。
【００４６】
図１を用いて、ストリーム配信システムの基本的な考えを説明する。
ストリーム配信装置２（尚、ストリーム配信装置２の数は一以上の任意の数である。）は、サーバ１から同一コンテンツに対して、複数の種類のストリームデータ（ここでは、例えば、５００ｋｂｐｓ、３００ｋｂｐｓ、１００ｋｂｐｓという三種類のストリームデータを例として以下説明することにする。）を受信している（図１の様にストリーム配信装置２が二台あればその其々が受信している）。
【００４７】
各クライアント端末１の接続要求に対して当初５００ｋｂｐｓの帯域で接続するが、品質が十分保証（補償）できない場合は、ストリーム配信装置２又はクライアント端末４の何れか一方の手段がイニシアティブをもって（第一コンセプトでは後者によって）判断してレート（伝送速度）を３００ｋｂｐｓ又は１００ｋｂｐｓまで落すように装置・システム構築される。
【００４８】
また、各ストリーム配信装置２と各クライアント端末４との間は、ネットワーク回線３により接続されており、ネットワーク回線３上で輻輳などが発生した場合には、パケット損失が発生する可能性があり、かような場合は、（ａ）各クライアント端末４が損失したパケットに係る再送要求を出し、当該再送要求を受けたストリーム配信装置２は、要求されたパケットを再度送り直すように装置構成されている。
【００４９】
又は（ｂ）各クライアント端末４が損失したパケットについてストリーム配信装置２に通知し、当該通知を受けたストリーム配信装置２が、再度その損失したパケットを送り直すように装置構成されている（第一コンセプトにおいては（ａ）を行う。）。
なお、本発明の一実施形態でもある、ストリーム配信装置、クライアント端末（ストリーム配信クライアント端末）の詳細については、後述することにする。
【００５０】
（方法例）
ここで、本発明の一実施形態であるストリーム配信方法につき、前述した事項を踏まえて説明する。
図２乃至４は、本発明の一実施形態におけるストリーム配信方法を説明する為の、ストリーム配信装置とクライアント端末との間の制御、転送シーケンス図であり、図２は接続―ストリームデータ転送―切断という一連のシーケンス図、図３はパケット再送シーケンス図、図４は帯域変更制御シーケンス図である。
【００５１】
▲１▼最初に、ストリーム配信装置２、クライアント端末４との間での、接続―ストリームデータ転送―切断の一連のシーケンスについて説明する。
図２の様に、クライアント端末４は、ＳＴ１−１として接続要求パケットにより５００ｋｂｐｓのコンテンツを要求し、ＳＴ１−２として接続応答パケットを返答し、ＳＴ１−３としてそれに呼応して、ストリーム配信装置２が５００ｋｂｐｓのストリームデータパケットの送信を開始する。
【００５２】
ＳＴ１−３乃至ＳＴ１−９として、ストリームデータパケットのシーケンス番号は、例えば、「０、１、２、・・・、３１、０、１、２、・・・」の様にモジュロ３１で、連続的に変化するものとすることでもって、ストリームデータパケットのシーケンス番号により、パケットがネットワーク中で損失したかどうかを判断することができる（パケット損失の検出手法）。また、クライアント端末４とストリーム配信装置２は、ストリームコンテンツ名、帯域、クライアントアドレスの組合わせを識別するセッション番号にリンケージして管理するものとする。
【００５３】
クライアント端末４がストリーム受信を終了する場合は、ＳＴ１−１０としてクライアント端末４から切断要求を送信し、ＳＴ１−１１として当該切断要求に応答して、当該セッション番号で配信されていたストリームの受信を終了する。
【００５４】
▲２▼次に、かかるストリームデータ転送中（クライアント端末４がストリームデータ受信中）に、ストリームデータパケットの損失を既に述べた手法により検出した場合、クライアント端末４が当該パケットの再送要求をストリーム配信装置２に要求するパケット再送手順のシーケンスについて説明する。
【００５５】
図３の様に、シーケンス番号＝３のパケットが損失したことをクライアント端末４が検出した為、ＳＴ２−１として、クライアント端末４が当該パケットの再送をストリーム配信装置２へ要求し、ＳＴ２−２としてストリーム配信装置２が当該パケットを再度送信する。
【００５６】
▲３▼更に、クライアント端末４が、パケット損失数が多く、再送により品質が回復しないと判断した場合においては、クライアント端末４が起動する帯域変更要求シーケンスにつき説明する。
図４に示す様に、ＳＴ３−１として、クライアント端末４が５００ｋｂｐｓから３００ｋｂｐｓへ受信中のコンテンツの帯域を変更要求し、ＳＴ３−２としてそれに応答する。
【００５７】
ここで、図２乃至４の各シーケンスにおいて用いた制御パケット及びストリームデータパケットが含むパラメータについて整理すると図５の通りである。
【００５８】
なお、図３、４は、基本的に前述の第一コンセプトを基調とした、即ち、（ａ）各クライアント端末４は損失したパケットの再送要求することが前提となっているものの、前述の第二コンセプトの様に、即ち、（ｂ）各クライアント端末４が損失したパケットを通知するのみで、ストリーム配信装置２が再送するか、伝送速度を変更するかを決定する場合には、図３のＳＴ２−１はセッション番号、シーケンス番号＝３をパラメータに持つパケット損失の旨の通知であり、図４のＳＴ３−１に相当する手順は不要ということになる。
【００５９】
（装置例）
ここで、以上の説明を踏まえて、クライアント端末、ストリーム配信装置の具体的な構成について説明する。
図６は、本発明の一実施形態であるクライアント端末とストリーム配信装置の内部構成図であり、同時に、サーバ、ＩＰネットワークと共にシステム化したシステム構成図でもある。
【００６０】
図中、１、２、４は前述同様サーバ、ストリーム配信装置、クライアント端末であり、２１は配信装置制御部、２２はデータ送信部、４１はクライアント制御部、４２はデータ受信部、４３はデコーダ、４４はディスプレイ（一般には出力手段）、５はＩＰネットワークである。
ここで、ストリーム配信装置２は、サーバ１と接続され、サーバ１から例えば三種類の帯域のストリームデータ（５００ｋｂｐｓ、３００ｋｂｐｓ、１００ｋｂｐｓ）を受信していると仮定する。
【００６１】
［クライアント端末の構成］
クライアント端末４は、クライアント制御部４１（クライアント制御部４１ａ）、データ受信部４２、デコーダ４３、ディスプレイ４４から構成され、ＩＰネットワーク５を経由して、データｃｈと制御ｃｈとによりストリーム配信装置２と接続されている。
【００６２】
クライアント制御部４１は、接続要求、切断要求の各シーケンスを起動し、ストリーム配信装置２との間のセッションの設定・解放を実行する機能を持つ。
また、クライアント制御部４１は、一旦確立したセッション中にパケット損失があったことをデータ受信部４２から通知されると、当該損失パケットのシーケンス番号を用いてパケット再送要求を発行する。
【００６３】
更に、クライアント制御部４１は、帯域変更制御シーケンスにより、帯域を変更することができる。
なお、パケット再送及び帯域変更の処理の流れについては後述参照のこと。
【００６４】
データ受信部４２は、ストリームデータパケットを受信し、蓄積し、シーケンス抜けがないことを確認する。抜けがない場合は、デコーダ４３へ当該データを転送する一方、抜けが発生している場合は、抜けているパケットのシーケンス番号をクライアント制御部４１へ通知する。
デコーダ４３は、ストリームデータパケットを音声・映像信号に変換し、ディスプレイ４４（その他の出力手段）へその信号を中継する。
ディスプレイ４４は、音声・映像信号を表示する。
【００６５】
［ストリーム配信装置の構成］
配信装置制御部２１は、クライアント制御部４１と接続、切断、パケット再送要求、帯域変更制御の各シーケンスを実行すると共に、クライアント端末４毎に配信管理データを管理する。この配信管理データ（又はそれを格納したテーブル）は、セッション確立、帯域変更、セッション切断のトリガーによりクライアント端末４毎に維持管理される。図７は、かかる配信管理データの構成図である。
【００６６】
また、配信装置制御部２１は、確立、変更、解放されたセッション情報をデータ送信部２２へセッションデータとして伝える。図８は、かかるセッションデータの構成図である。
【００６７】
データ送信部２２は、コンテンツ毎、帯域毎にサーバ１から受信するバッファを持っている。そして、受信したパケットのコンテンツ名と帯域を検出して、図８に例示したセッションデータテーブルで当該コンテンツの配信先クライアントＩＰアドレス及びクライアントセッション番号を参照してストリームデータパケットの宛先を変換し、データｃｈ経由で当該クライアント端末４へストリームデータを送信する。
【００６８】
［パケット再送処理］
ここで、配信装置制御部２１とデータ送信部２２とにおいてなされるパケット再送処理につき説明する。
【００６９】
データ送信部２２のバッファはモジュロ数分のパケットを格納することができ、配信装置制御部２１がパケット再送要求をクライアント端末４から受信した場合、データ送信部２２に対して当該再送要求されたパケットをパケット再送要求に載っているクライアントセッション番号、クライアントアドレス及びシーケンス番号から引当て、当該パケットをデータｃｈ経由にてクライアント端末４へ送信する。
【００７０】
［帯域変更制御処理］
ここで、配信装置制御部２１とデータ送信部２２とにおいてなされる帯域変更制御処理につき説明する。
【００７１】
配信装置制御部２１はクライアント端末４から受信した帯域変更制御パケットを解析し、当該クライアント端末４向け、当該コンテンツの帯域情報を配信管理データテーブル（図７参照）上で修正し、そのデータをセッションデータとしてデータ送信部２２へ伝える。これにより、データ送信部２２は、セッションデータを書き換えることにより、今までとは異なる帯域のストリームデータを引当て、データｃｈ経由でクライアント端末４へ送信する。
【００７２】
（プログラム例及び記録媒体例）
ところで、クライアント端末４（クライアント制御部４１ａ）は、パケット再送と帯域変更の何れをなすか判断するわけであるところ、かかる判断を行う手順につき、それをプログラム化したものを、プログラム例として説明する。
【００７３】
なお、ここにおいては、この点に限りプログラム例として説明するも、今まで説明した点を、手順化、プログラム化して、以下説明するプログラム例に包含させても構わない。また、かかるプログラムを記録媒体に記録媒体に記録したものが、本発明の一実施形態である記録媒体例である（ここでの注は、以下同様。）。
【００７４】
図９は、本発明の一実施形態であるクライアント端末における、閾値が固定の場合の、クライアント端末のパケット再送及び帯域変更制御の処理（プログラム）の流れ図である。なお、同流れ図においては、Ｔ０は単位時間、ＴはＴ０内の経過時間、ＣはＴ０内のパケット損失数カウンタ、Ｃ０はクライアント端末毎に決定された閾値、を示す変数又は定数である。なお、Ｔについてはクロック機能などにより自動的に増加する変数である。
【００７５】
先ず、変数初期化の為、Ｃ＝０、Ｔ＝０を設定する（ＳＴＥＰ１−１）。
次に、パケット損失があるかどうか（第一判断）を判断して（ＳＴＥＰ１−２）、有り（Ｙｅｓ）の場合は、パケット損失数カウンタＣをインクリーメント（ＳＴＥＰ１−３）し、その後パケット損失数カウンタＣが閾値Ｃ０を超えたかどうかを判定し（ＳＴＥＰ１−４）、超過の湯合は、帯域変更制御を起動（ＳＴＥＰ１−５）、超えていない場合は当該パケットに関するパケット再送要求を送信（ＳＴＥＰ１−６）して、制御を最初（ＳＴＥＰ１−２）に戻す。
【００７６】
一方、ＳＴＥＰ１−２でパケット損失がなかった（ＳＴＥＰ１−２でＮｏの）場合でかつ経過時間Ｔが単位時間Ｔ０を超過していない（ＳＴＥＰ１−７でＮｏの）場合は、制御を最初（ＳＴＥＰ１−２）に戻しパケット損失のチェックを繰返す。
経過時間Ｔが単位時間Ｔ０を超過した（ＳＴＥＰ１−７でＹｅｓの）場合、パケット損失カウンタＣ及びＴ０内の経過時間Ｔの値を更新し（ＳＴＥＰ１−８）、制御を最初（ＳＴＥＰ１−２）に戻す。
【００７７】
かかる処理により、単位時間Ｔ０の間にパケット損失数Ｃが閾値Ｃ０を超えない内は、パケット再送により、レートを落さずに品質を維持することができる一方、パケット損失数Ｃが閾値Ｃ０を超過した場合は、かなりパケット損失が継続的に発生している為、レートを落した方が得策と判断して、レートを下げることになる。
【００７８】
（その他の実施の形態１）
［方法例］
その他の実施の形態１として、前述の第二コンセプトに対応するものを挙げる。その点自体は既に説明ずみであるので、ここでは、システム・装置、プログラム・記録媒体の相違点について説明すれば、第一コンセプトに準じていることが分かるであろう。
【００７９】
［システム・装置］
図１０は、本発明の一実施形態であるクライアント端末とストリーム配信装置の内部構成図であり、同時に、サーバとＩＰネットワークと共にシステム化したシステム構成図でもある。
なお、装置例の図６と比較すると、基本的な内部構成、システム構成は同一であり、相違点についてのみここでは説明することにする。
【００８０】
装置例（図６）においては、帯域変更制御パケットをクライアント端末４が生成してストリーム配信装置２へ送付していたのに対し、その他の実施の形態１（図１０）においては、クライアント端末４は、制御ｃｈを使って、パケット損失の事実をストリーム配信装置２へ送付し、ストリーム配信装置２がその送付された当該クライアント端末４のパケット損失をカウントし閾値と比較して帯域変更制御を実行するかどうか判断する点で流れが異なる（なお、カウントするまでの処理は、クライアント端末４で行い、カウンタが更新されると、ストリーム配信装置２に送付するようにしてもよい。）。
【００８１】
これにより、▲１▼「クライアント端末４からストリーム配信装置２へ伝わるデータ」が「パケット損失の事実（又はクライアント端末でカウントした数）」となり、▲２▼「帯域変更制御を実行する判断」が「ストリーム配信装置２側」となるように内部構成要素を一部変更した装置・システム構成である。かかる構成により、クライアント端末４で判断処理する負荷が軽減されるというメリットがある。
【００８２】
［プログラム・記録媒体］
図１１は、本発明の一実施形態であるストリーム配信装置における、閾値が固定の場合の、ストリーム配信装置のパケット再送及び帯域変更制御の処理（プログラム）の流れ図である。なお、流れ図は基本的に図１０と同等のものであるのでここでは相違点のみ説明する。
【００８３】
即ち、ＳＴＥＰ１−５に対応するＳＴＥＰ２−５の処理が、「帯域変更制御パケットをストリーム配信装置２に送付する」代わりに、「ストリーム配信装置２自体が帯域変更制御を実行する」ことになる。
【００８４】
また、ＳＴＥＰ１−６に対応するＳＴＥＰ２−６の処理が、「パケット送信要求をストリーム配信装置２へ送信」する代わりに、「ストリーム配信装置２自体が再送パケット送信処理を実行する」ことになる。それ以外の部分はＳＴＥＰ１−１乃至ＳＴＥＰ１−４、ＳＴＥＰ１−７、ＳＴＥＰ１−８の処理がそれぞれＳＴＥＰ２−１乃至ＳＴＥＰ２−４、ＳＴＥＰ２−７、ＳＴＥＰ２−８に対応する。
【００８５】
（その他の実施の形態２）
［方法］
その他の実施の形態２として、前述の第三コンセプトに対応するものを挙げる。その点自体は既に説明ずみであるので、ここでは、システム・装置、プログラム・記録媒体の相違点について説明すれば、第一コンセプトをどの様に改良することになるかが分かるであろう。
【００８６】
［システム・装置］
図１２は、本発明の一実施形態であるクライアント端末とストリーム配信装置の内部構成図であり、同時に、サーバとＩＰネットワークと共にシステム化したシステム構成図でもある。
なお、装置例（図６）と比較すると、基本的な内部構成、システム構成は同一であり、相違点についてのみここでは説明することにする。
【００８７】
その他の実施の形態２（図１２）においては、クライアント制御部４１ｂで管理している閾値Ｃ０を固定値ではなく可変にしていることが、装置例（図６）と異なる点である。
従って、クライアント制御部４１ｂは、装置例（プログラム例及び記録媒体例）での変数・定数に加えて、ＮはＴ０経過回数、ＳはＣの累積値、Ａは安全係数という変数・定数を用いて処理を行うことになる。
【００８８】
即ち、かかる新しい変数又は定数も加味して、単位時間Ｔ０毎にパケット損失数Ｃの平均値（＝Ｓ／Ｎ）を計算し、その値に安全係数Ａを積算した結果を閾値Ｃ０として再計算する。これにより、パケット損失数の実績値に近い値である閾値Ｃ０を自動的に予想することができるようになる。
【００８９】
［プログラム例及び記録媒体例］
図１３は、本発明の一実施形態であるクライアント端末における、閾値が可変の場合の、クライアント端末のパケット再送及び帯域変更制御の処理（プログラム）の流れ図である。
【００９０】
先ず、変数初期化の為、Ｎ＝１、Ｓ＝０、Ｃ＝０、Ｔ＝０を設定する（ＳＴＥＰ３−１）。
次に、パケット損失があるかどうかを判定し（ＳＴＥＰ３−２）、有りの場合は、パケット損失数カウンタＣをインクリーメント（ＳＴＥＰ３−３）する。
【００９１】
その後、パケット損失数カウンタＣが閾値Ｃ０を超えたかどうかを判定し（ＳＴＥＰ３−４）、超過の場合は、帯域変更制御を起動（ＳＴＥＰ３−５）、超えていない場合は当該パケットに関するパケット再送要求を送信（ＳＴＥＰ３−６）して、制御を最初（ＳＴＥＰ３−２）に戻す。
【００９２】
一方、ＳＴＥＰ３−２でパケット損失がなかった（ＳＴＥＰ３−２でＮｏの）場合でかつ経過時間ＴがＴ０を超過していない（ＳＴＥＰ３−７でＮｏの）場合は、制御を最初（ＳＴＥＰ３−２）に戻しパケット損失のチェックを繰返す。
ＳＴＥＰ３−７において、経過時間ＴがＴ０を超過した（Ｙｅｓの）場合、Ｔ＝０とし、閾値ＣＯの値をＣのカウントの累積値ＳをＮで除算した値に安全係数Ａを積算することにより、更新し（ＳＴＥＰ３−８）、制御を最初（ＳＴＥＰ３−２）に戻す。
【００９３】
なお、この処理の流れは、ストリーム配信装置２側でレートダウンを判断する場合の処理の流れにも適用できることは、いうまでもなく、その適用場面については、その他の実施の形態１及び２の双方を取り込むことで達成できる。
即ち、ＳＴＥＰ３−５の処理を「帯域変更制御の処理を実行する」、ＳＴＥＰ３−６の処理を「再送パケット送信処理を実行する」と読み替えればよい。
【００９４】
（その他の実施の形態３）
ところで、概要において前述しておいた、クライアント端末４の品質データにつき説明を加える。
今までの説明において、品質データをパケット損失数として考えているところを、クライアント端末４の品質データとして、受信した総データ量、平均帯域、クライアント端末４が受けたパケット再送の成功数なども指標とすることができる。
【００９５】
以上、本発明の実施の形態につき、その概要、システム例、方法例、装置例、プログラム例、記録媒体例並びにその他の実施の形態１乃至３を説明したことから分かる様に、第一に、クライアント端末毎に閾値Ｃ０を設定できる為、クライアント端末４のネットワークの状況に適合した基準で、帯域変更制御を起動することができる。つまり、パケット再送により最良の品質（前述の例においては５００ｋｂｐｓ）を維持できたにも拘わらず、閾値の設定が小さすぎた為、帯域変更制御が起動し、品質が悪くなるような確率を低く抑えることが可能となる。
【００９６】
第二に、この閾値Ｃ０はネットワークの状態に応じて学習しながら更新することにより、品質がよい場合は小さなＣ０、品質が悪い場合は大きなＣ０を自動的に再計算することにより、固定閾値を用いる場合と比較して、更に品質が悪くなる確率を低く抑えることができる。
【００９７】
なお、以上の本発明の実施の形態は例示であり、本発明の目的を達し下記する効果を奏する範囲において適宜変更して実施可能である。
また、本明細書及び図面において、「帯域」、「ビットレート」、「伝送速度」は同一の概念であり、「帯域幅」とも一般にいわれている。
【００９８】
【発明の効果】
本発明によれば、ストリーム配信装置がベストエフォート網を経由してクライアント端末に映像などのストリームデータを配信する場合に、当該クライアント端末宛にてネットワーク経由で生じる品質劣化の度合いに応じた品質制御が可能となり、以って、良好な品質で配信できる確率を高くすることができる。
【００９９】
しかも、ネットワークの品質は時々刻々と変化するので、その変化を学習し、更に良好な品質にて配信することができ、以って、現在のベストエフォートＩＰ網を用いた高品質なストリーム配信（サービス）を経済的に提供できるといった極めて優れた効果を発揮する。
【図面の簡単な説明】
【図１】本発明一実施形態であるストリーム配信システムの構成図である。
【図２】本発明一実施形態であるストリーム配信装置とクライアント端末間の、接続―データストリーム転送―切断の一連のシーケンス図である。
【図３】本発明一実施形態であるストリーム配信装置とクライアント端末間での、パケット再送シーケンス図である。
【図４】本発明一実施形態であるストリーム配信装置とクライアント端末間での、帯域変更制御シーケンス図である。
【図５】図２乃至４の各シーケンスにおいて用いた制御パケット及びストリームデータパケットが含まれるパラメータ一覧表である。
【図６】本発明一実施形態であるストリーム配信装置、クライアント端末の各内部構成と共に示した、ストリーム配信システム構成図である。
【図７】本発明一実施形態であるサーバ配信装置の配信装置制御部において管理される配信管理データの構成図の一例である。
【図８】本発明一実施形態であるサーバ配信装置の配信装置制御部からデータ送信部に伝えられるセッションデータの構成図の一例である。
【図９】本発明一実施形態である、固定閾値・クライアント判断型のストリーム配信プログラムであって、クライアント端末に格納されて利用された場合の、クライアント端末においてなされる処理の流れ図である。
【図１０】本発明一実施形態で図６とは異なる、ストリーム配信装置、クライアント端末の各内部構成と共に示した、ストリーム配信システム構成図である。
【図１１】本発明一実施形態である、固定閾値・ストリーム配信装置判断型のストリーム配信プログラムであって、ストリーム配信装置に格納されて利用された場合の、ストリーム配信装置においてなされる処理の流れ図である。
【図１２】本発明一実施形態で図６、図１０とは異なる、ストリーム配信装置、クライアント端末の各内部構成と共に示した、ストリーム配信システム構成図である。
【図１３】本発明一実施形態である、可変閾値・クライアント判断型のストリーム配信プログラムであって、クライアント端末に格納されて利用された場合の、クライアント端末いおいてなされる処理の流れ図である。
【符号の説明】
１…サーバ
２…ストリーム配信装置
２１、２１ａ…配信装置制御部
２２…データ送信部
３…ネットワーク回線
４…クライアント端末
４１、４１ａ、４１ｂ…クライアント制御部
４２…データ受信部
４３…デコーダ
４４…ディスプレイ
５…ＩＰネットワーク
【図１】
2004048450.tif 000003
【図２】
2004048450.tif 000004
【図３】
2004048450.tif 000005
【図４】
2004048450.tif 000006
【図５】
2004048450.tif 000007
【図６】
2004048450.tif 000008
【図７】
2004048450.tif 000009
【図８】
2004048450.tif 000010
【図９】
2004048450.tif 000011
【図１０】
2004048450.tif 000012
【図１１】
2004048450.tif 000013
【図１２】
2004048450.tif 000014
【図１３】
2004048450.tif 000015