(57)【要約】    【課題】      ネットワーク上のＳＴＢに適したビットレートを検出すること。    【解決手段】  ストリーミングデータを配信する放送サーバ１０１と、ストリーミングデータを受信するストリーミングデータ通信装置（ＳＴＢ）１０２〜１０６と、を具備するストリーミングデータ通信システムにおいて、放送サーバ１０１は、ストリーミングデータ通信装置（ＳＴＢ）１０２〜１０６の適正なビットレートを検出するためのビットレートを変えたテストデータパケットを送出し、ストリーミングデータ通信装置（ＳＴＢ）１０２〜１０６は、このテストデータパケットから検出されたパケットロスに応じて適正なビットレートを判断する。  【選択図】      図１
2005167514.tif 000002
【特許請求の範囲】
【請求項１】
ストリーミングデータを配信するサーバと、前記ストリーミングデータを受信するストリーミングデータ通信装置と、を具備するストリーミングデータ通信システムであって、前記サーバは、前記ストリーミングデータ通信装置の適正なビットレートを検出するためのビットレートを変えたテストデータパケットを送出し、前記ストリーミングデータ通信装置は、前記テストデータパケットから検出されたパケットロスに応じて適正なビットレートを判断することを特徴とするストリーミングデータ通信システム。
【請求項２】
前記サーバは、前記テストデータパケットのビットレートを順次繰り上げて送出し、前記ストリーミングデータ通信装置は、パケットロスを検出したビットレートの直前のビットレートが適正なビットレートであると判断することを特徴とする請求項１記載のストリーミングデータ通信システム。
【請求項３】
前記サーバは、前記テストデータパケットのビットレートを繰り上げる度に当該テストデータパケットのヘッダに含まれるマークビットを変更し、前記ストリーミングデータ通信装置は、当該マークビットを検出して前記テストデータパケットのビットレートの変化を認識することを特徴とする請求項２記載のストリーミングデータ通信システム。
【請求項４】
配信されるストリーミングデータを受信するストリーミングデータ通信装置であって、前記ストリーミングデータを配信するサーバから適正なビットレートを検出するためのビットレートを変えたテストデータパケットを受信する受信手段と、前記テストデータパケットのパケットロスを検出する検出手段と、前記パケットロスの検出結果に応じて適正なビットレートを判断する制御手段と、を具備することを特徴とするストリーミングデータ通信装置。
【請求項５】
前記受信手段は、ビットレートを順次繰り上げたテストデータパケットを受信し、前記制御手段は、パケットロスが検出されたビットレートの直前のビットレートが適正なビットレートであると判断することを特徴とする請求項４記載のストリーミングデータ通信装置。
【請求項６】
前記制御手段は、ビットレートを繰り上げる度に変更されるテストデータパケットのヘッダ内のマークビットを検出することで前記テストデータパケットのビットレートの変化を認識することを特徴とする請求項５記載のストリーミングデータ通信装置。
【請求項７】
ストリーミングデータをストリーミングデータ通信装置に配信するサーバ装置であって、前記ストリーミングデータを配信する配信手段と、前記ストリーミングデータに先立って前記ストリーミングデータ通信装置の適正なビットレートを検出するためのビットレートを変えたテストデータパケットを送出する送出手段と、を具備することを特徴とするサーバ装置。
【請求項８】
前記送出手段は、前記テストデータパケットのビットレートを順次繰り上げて送出することを特徴とする請求項７記載のサーバ装置。
【請求項９】
前記送出手段は、前記テストデータパケットのビットレートを繰り上げる度に当該テストデータパケットのヘッダに含まれるマークビットを変更することを特徴とする請求項８記載のサーバ装置。
【請求項１０】
サーバからストリーミングデータの配信を受けるストリーミングデータ通信装置における適正ビットレート検出方法であって、前記サーバから前記ストリーミングデータに先立って前記ストリーミングデータ通信装置の適正なビットレートを検出するためのビットレートを変えたテストデータパケットを送出し、前記ストリーミングデータ通信装置で前記テストデータパケットのパケットロスを検出し、前記パケットロスの検出結果に応じて適正なビットレートを判断することを特徴とする適正ビットレート検出方法。
【請求項１１】
前記サーバから前記テストデータパケットのビットレートを順次繰り上げて送出し、前記ストリーミングデータ通信装置でパケットロスを検出したビットレートの直前のビットレートが適正なビットレートであると判断することを特徴とする請求項１０記載の適正ビットレート検出方法。
【請求項１２】
前記サーバで前記テストデータパケットのビットレートを繰り上げる度に当該テストデータパケットのヘッダに含まれるマークビットを変更し、前記ストリーミングデータ通信装置で当該マークビットを検出して前記テストデータパケットのビットレートの変化を認識することを特徴とする請求項１１記載の適正ビットレート検出方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ストリーミングデータ通信システム、ストリーミングデータ通信装置及び適正ビットレート検出方法に関する。
【背景技術】
【０００２】
従来、ＡＤＳＬ、ＦＴＴＨ等の公衆ブロードバンドネットワークを利用し、ＩＰマルチキャストによるストリーミング放送が実現されている（例えば、特許文献１）。しかし、セットトップボックス（以下、「ＳＴＢ（Set Top Box）」という）を設置する利用者側では、ネットワーク環境（モデム、ルータ、ハブ等）とこのＳＴＢの性能が必ずしも同一でないことから、パケットロスによる画像の乱れが発生する事態が生じている。
【０００３】
このような問題に対する対策として、ビットレート（転送レート）を調整するプロトコルとしてＲＴＣＰ（RTP control protocol）が存在する。このＲＴＣＰは、サーバとＳＴＢとの間でパケット廃棄の統計情報を交換することで、サーバの送出ビットレートをストリーミング再生中に動的に調整する。
【０００４】
また、事前にビットレートを調整し、ＩＰマルチキャストのストリーミングのビットレートを変更する方法も考えられる。
【特許文献１】特開２００１−６９４８３号公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
しかしながら、上記のようにＲＴＣＰを用いた方法では、パケット廃棄を行った後に動的に送出ビットレートを調整するものであることから、画像の乱れを事前に防止することができないという問題がある。また、動的にビットレートを変更する場合、途中から画質が低下、或いは、向上することになり、チャネルに対する画質の均質化という面でも問題が発生する。さらに、既に受信中のＳＴＢに対しても、同様な問題が発生するだけでなく、動的なビットレートの変化（可変ビットレート）に対応できないＳＴＢの場合、画像の乱れや画像が表示できない等の問題が発生する可能性がある。
【０００６】
また、マルチキャストではなく、ユニキャストで各ＳＴＢに対してビットレートを事前に調整し、配信することも考えられる。しかし、全てのＳＴＢのネットワーク環境を考慮して個別に対応することは現実的に不可能であり、また、ユニキャストを用いた方法では配信サーバと受信端末装置とが１対１の関係でデータを配信することからネットワーク上のトラフィックが大きくなり、配信速度が低下するという問題が発生する。
【０００７】
このような問題を解消するため、マルチキャスト方式を用いてネットワーク上のＳＴＢに適したビットレートでストリーミングデータを配信できるようにすることが望ましいが、かかる場合にはネットワーク上のＳＴＢに適したビットレートを検出することが困難であるという問題がある。
【０００８】
本発明は、かかる問題点に鑑みて為されたものであり、ネットワーク上のＳＴＢに適したビットレートを検出することができるストリーミングデータ通信システム、ストリーミングデータ通信装置及び適正ビットレート検出方法を提供することを目的とする。
【課題を解決するための手段】
【０００９】
本発明は、ストリーミングデータを配信するサーバと、ストリーミングデータを受信するストリーミングデータ通信装置と、を具備するストリーミングデータ通信システムにおいて、サーバは、ストリーミングデータ通信装置の適正なビットレートを検出するためのビットレートを変えたテストデータパケットを送出し、ストリーミングデータ通信装置は、このテストデータパケットから検出されたパケットロスに応じて適正なビットレートを判断するものである。
【発明の効果】
【００１０】
本発明に係るストリーミングデータ通信システム、ストリーミングデータ通信装置及び適正ビットレート検出方法によれば、ネットワーク上のＳＴＢに適したビットレートを検出することができる。
【発明を実施するための最良の形態】
【００１１】
本発明の第１の態様に係るストリーミングデータ通信システムは、ストリーミングデータを配信するサーバと、前記ストリーミングデータを受信するストリーミングデータ通信装置と、を具備するストリーミングデータ通信システムであって、前記サーバは、前記ストリーミングデータ通信装置の適正なビットレートを検出するためのビットレートを変えたテストデータパケットを送出し、前記ストリーミングデータ通信装置は、前記テストデータパケットから検出されたパケットロスに応じて適正なビットレートを判断する構成を採る。
【００１２】
この構成によれば、ストリーミングデータ通信装置において、サーバから送出されたテストデータパケットから検出されたパケットロスに応じて適正なビットレートを判断するので、ネットワーク上のストリーミングデータ通信装置に適したビットレートを検出することができる。
【００１３】
本発明の第２の態様は、第１の態様に係るストリーミングデータ通信システムにおいて、前記サーバは、前記テストデータパケットのビットレートを順次繰り上げて送出し、前記ストリーミングデータ通信装置は、パケットロスを検出したビットレートの直前のビットレートが適正なビットレートであると判断する構成を採る。
【００１４】
この構成によれば、ビットレートが繰り上げられて送出されるテストデータパケットにおいてパケットロスを検出した場合、当該ビットレートの直前のビットレートが適正なビットレートと判断するので、パケットロスを検出するという簡単な制御を行うだけで適正なビットレートを容易に検出することができる。
【００１５】
本発明の第３の態様は、第２の態様に係るストリーミングデータ通信システムにおいて、前記サーバは、前記テストデータパケットのビットレートを繰り上げる度に当該テストデータパケットのヘッダに含まれるマークビットを変更し、前記ストリーミングデータ通信装置は、当該マークビットを検出して前記テストデータパケットのビットレートの変化を認識する構成を採る。
【００１６】
この構成によれば、マークビットを検出することでテストデータパケットのビットレートの変化を認識することができるので、マークビットのみを検出するという簡単な制御を行うだけでビットレートの変化を容易に認識することができる。
【００１７】
本発明の第４の態様に係るストリーミングデータ通信装置は、配信されるストリーミングデータを受信するストリーミングデータ通信装置であって、前記ストリーミングデータを配信するサーバから適正なビットレートを検出するためのビットレートを変えたテストデータパケットを受信する受信手段と、前記テストデータパケットのパケットロスを検出する検出手段と、前記パケットロスの検出結果に応じて適正なビットレートを判断する制御手段と、を具備する構成を採る。
【００１８】
この構成によれば、サーバから送出されたテストデータパケットのパケットロスの検出結果に応じて適正なビットレートを判断するので、ネットワーク上のストリーミングデータ通信装置に適したビットレートを検出することができる。
【００１９】
本発明の第５の態様は、第４の態様に係るストリーミングデータ通信装置において、前記受信手段は、ビットレートを順次繰り上げたテストデータパケットを受信し、前記制御手段は、パケットロスが検出されたビットレートの直前のビットレートが適正なビットレートであると判断する構成を採る。
【００２０】
この構成によれば、ビットレートが繰り上げられて送出されるテストデータパケットにおいてパケットロスを検出した場合、当該ビットレートの直前のビットレートが適正なビットレートと判断するので、パケットロスを検出するという簡単な制御を行うだけで適正なビットレートを容易に検出することができる。
【００２１】
本発明の第６の態様は、第５の態様に係るストリーミングデータ通信装置において、前記制御手段は、ビットレートを繰り上げる度に変更されるテストデータパケットのヘッダ内のマークビットを検出することで前記テストデータパケットのビットレートの変化を認識する構成を採る。
【００２２】
この構成によれば、マークビットを検出することでテストデータパケットのビットレートの変化を認識することができるので、マークビットのみを検出するという簡単な制御を行うだけでビットレートの変化を容易に認識することができる。
【００２３】
本発明の第７の態様に係るサーバ装置は、ストリーミングデータをストリーミングデータ通信装置に配信するサーバ装置であって、前記ストリーミングデータを配信する配信手段と、前記ストリーミングデータに先立って前記ストリーミングデータ通信装置の適正なビットレートを検出するためのビットレートを変えたテストデータパケットを送出する送出手段と、を具備する構成を採る。
【００２４】
この構成によれば、ストリーミングデータに先立って前記ストリーミングデータ通信装置の適正なビットレートを検出するためのビットレートを変えたテストデータパケットを送出するので、ストリーミングデータ通信装置において、このテストデータパケットから検出されたパケットロスに応じて適正なビットレートを判断することにより、ネットワーク上のストリーミングデータ通信装置に適したビットレートを検出することができる。
【００２５】
本発明の第８の態様は、第７の態様に係るサーバ装置において、前記送出手段は、前記テストデータパケットのビットレートを順次繰り上げて送出する構成を採る。
【００２６】
この構成によれば、テストデータパケットのビットレートを順次繰り上げて送出されるので、ストリーミングデータ通信装置において、このテストデータパケットにおいてパケットロスを検出した場合に当該ビットレートの直前のビットレートが適正なビットレートと判断することにより、パケットロスを検出するという簡単な制御を行うだけで適正なビットレートを容易に検出することができる。
【００２７】
本発明の第９の態様は、第８の態様に係るサーバ装置において、前記送出手段は、前記テストデータパケットのビットレートを繰り上げる度に当該テストデータパケットのヘッダに含まれるマークビットを変更する構成を採る。
【００２８】
この構成によれば、ビットレートを繰り上げる度にテストデータパケットのヘッダに含まれるマークビットを変更するので、ストリーミングデータ通信装置において、このマークビットを検出することでテストデータパケットのビットレートの変化を認識することにより、マークビットのみを検出するという簡単な制御を行うだけでビットレートの変化を容易に認識することができる。
【００２９】
本発明の第１０の態様に係る適正ビットレート検出方法は、サーバからストリーミングデータの配信を受けるストリーミングデータ通信装置における適正ビットレート検出方法であって、前記サーバから前記ストリーミングデータに先立って前記ストリーミングデータ通信装置の適正なビットレートを検出するためのビットレートを変えたテストデータパケットを送出し、前記ストリーミングデータ通信装置で前記テストデータパケットのパケットロスを検出し、前記パケットロスの検出結果に応じて適正なビットレートを判断するものである。
【００３０】
本発明の第１１の態様は、第１０の態様に係る適正ビットレート検出方法において、前記サーバから前記テストデータパケットのビットレートを順次繰り上げて送出し、前記ストリーミングデータ通信装置でパケットロスを検出したビットレートの直前のビットレートが適正なビットレートであると判断するものである。
【００３１】
本発明の第１２の態様は、第１１の態様に係る適正ビットレート検出方法において、前記サーバで前記テストデータパケットのビットレートを繰り上げる度に当該テストデータパケットのヘッダに含まれるマークビットを変更し、前記ストリーミングデータ通信装置で当該マークビットを検出して前記テストデータパケットのビットレートの変化を認識するものである。
【００３２】
以下、本発明の実施の形態について、図面を参照して詳細に説明する。
【００３３】
図１は、本発明の一実施の形態に係るストリーミングデータ通信システムが適用されるネットワークの構成を示す図である。
【００３４】
図１に示すように、本実施の形態に係るストリーミングデータ通信システムが適用されるネットワークは、ストリーミングデータを配信する放送サーバ１０１と、放送サーバ１０１から配信されるストリーミングデータを、インターネットを介して受信する複数のストリーミングデータ通信装置としてのセットトップボックス（以下、「ＳＴＢ（Set Top Box）」という」１０２〜１０６とから構成される。各ＳＴＢ１０２〜１０６には、ストリーミングデータが表示されるディスプレイ１０７〜１１１が接続されている。
【００３５】
放送サーバ１０１は、ＴＶチューナー１１２を備える。ＴＶチューナー１１２は、衛星放送等から受信したアナログデータをＭＰＥＧ等のデジタルデータに変換する。放送サーバ１０１は、この変換後のデジタルデータをストリーミングデータとして、インターネットを介してＳＴＢ１０２〜１０６に配信する。
【００３６】
図２は、本実施の形態に係るストリーミングデータ通信システムにおけるＳＴＢ１０２〜１０６周辺のネットワーク環境を示すブロック図である。なお、ＳＴＢ１０２〜１０６周辺のネットワーク環境のうち、ＳＴＢ１０２周辺のネットワーク環境を代表して説明し、他のＳＴＢ１０３〜１０６周辺のネットワーク環境については省略する。
【００３７】
図２に示すように、ＳＴＢ１０２周辺のネットワーク環境においては、ＡＤＳＬやＦＴＴＨ（以下、「ＡＤＳＬ等」という）２０１がモデム２０２を介してルータ／ハブ２０３に接続されている。このルータ／ハブ２０３は、ディスプレイ１０７に接続されたＳＴＢ１０２及びパーソナルコンピュータ（以下、「ＰＣ」という）２０４に接続されている。ＡＤＳＬ等２０１においては、通常、予め帯域が保証されているが、モデム２０２やルータ／ハブ２０３は利用者によって様々な製造業者のものが用いられるため、ＡＤＳＬ等２０１のみによってはＳＴＢ１０２の使用帯域を決定することは困難である。
【００３８】
図３は、本実施の形態に係るストリーミングデータ通信システムにおけるＳＴＢ１０２〜１０６の構成を示すブロック図である。なお、ＳＴＢ１０２〜１０６は、同様の構成を有するため、ＳＴＢ１０２の構成について説明し、他のＳＴＢ１０３〜１０６の構成については省略する。
【００３９】
図３に示すように、ＳＴＢ１０２は、ＣＰＵ３０１、メモリ３０２、赤外線インターフェイス（Ｉ／Ｆ）３０３、記憶装置３０４、ＴＶインターフェイス（Ｉ／Ｆ）３０５及びネットワークインターフェイス（Ｉ／Ｆ）３０６を備える。
【００４０】
ＣＰＵ３０１は、装置全体の動作を制御する。メモリ３０２には、ＣＰＵ３０１が装置全体の制御の際に実行するプログラム、並びに制御の際に必要なデータが格納される。赤外線Ｉ／Ｆ３０３は、リモートコントローラからの操作入力を受け付ける。記憶装置３０４には、放送サーバ１０１から受信したストリーミングデータが保存される。ＴＶＩ／Ｆ３０５は、接続されたディスプレイと装置本体とをインターフェイスを介して接続する。ネットワークＩ／Ｆ３０６は、インターネットと装置本体とをインターフェイスを介して接続する。
【００４１】
図４は、本実施の形態に係るストリーミングデータ通信システムにおけるＳＴＢ１０２が備えるＣＰＵ３０１の機能ブロック図である。
【００４２】
図４に示すように、ＣＰＵ３０１は、ストリーミング処理部４０１、ＴＶ再生部４０２、通信品質測定部４０３及びリモコン処理部４０４を備える。
【００４３】
ストリーミング処理部４０１は、ネットワークＩ／Ｆ３０６を介して入力されたストリーミングデータを受信する。受信したストリーミングデータをＴＶ再生部４０２及び通信品質測定部４０３に渡す。ＴＶ再生部４０２は、ストリーミング処理部４０１から得たデジタルデータをアナログデータに変換し、ＴＶＩ／Ｆ３０５を介して当該アナログデータをディスプレイで再生する。
【００４４】
通信品質測定部４０３は、ストリーミングデータ処理部４０１から得たストリーミングデータの通信品質を測定する。具体的には、後述するように、受信したパケットの喪失をチェックする。リモコン処理部４０４は、赤外線Ｉ／Ｆ３０３を介して受け付けた操作入力を処理し、通信品質測定部４０３に通知する。
【００４５】
図５は、本実施の形態に係るストリーミングデータ通信システムにおける放送サーバ１０１の構成を示すブロック図である。
【００４６】
図５に示すように、放送サーバ１０１は、ビットレート変換部５０１、パケット送出部５０２及びＳＴＢ通信部５０３を備える。
【００４７】
ビットレート変換部５０１は、ＴＶチューナー１１２によって変換されたＭＰＥＧ等のデジタルデータのビットレートの変換を行う。ビットレート変換部５０１が変換を行うビットレートは、ＳＴＢ通信部５０３が配信先であるＳＴＢとの間で決定したビットレートに従う。
【００４８】
パケット送出部５０２は、ビットレート変換部５０１により変換されたビットレートのパケットを、インターネットを介して配信先であるＳＴＢに送出する。ＳＴＢ通信部５０３は、ビットレート変換部５０１で変換するビットレートを決定するために必要なデータパケットを配信先であるＳＴＢとの間で通信する。ＳＴＢ通信部５０３で決定されたビットレートは、ビットレート変換部５０１に通知される。
【００４９】
以下、上記構成を有する本ストリーミングデータ通信システムにおける動作について説明する。まず、本実施の形態に係るストリーミングデータ通信システムにおけるＳＴＢの起動処理について説明する。
【００５０】
図６は、本実施の形態に係るストリーミングデータ通信システムにおけるＳＴＢの起動処理を説明するためのシーケンス図である。ここでは、ＳＴＢ１０２が起動する場合の動作について説明するものとする。
【００５１】
図６に示すように、ＳＴＢ１０２が起動すると、ＳＴＢ１０２は、予め認識しておいた自己のネットワーク環境の通信帯域を放送サーバ１０１に通知する。例えば、ＳＴＢ１０２は、ＡＤＳＬ等２０１で保証された通信帯域を通知する。ここで通知される通信帯域は、実際に使用される、現在のネットワーク環境で最適な通信帯域（以下、「最終帯域」という）を決定する際に上限として用いるのみであるので、大雑把な値で構わない。
【００５２】
この通信帯域の通知を受けると、放送サーバ１０１は、この通信帯域を上限としてビットレートを変更してＳＴＢ１０２に最適なビットレートを決定するためのデータパケット(以下、「テストパケット」という)の通信を開始する。具体的には、まず、テストパケットを送信するレート情報及びその送信の際に用いるポートをＳＴＢ１０２に通知する。
【００５３】
ここで、テストパケットを送信するレート情報について説明する。図７は、レート情報の一例を示す図である。レート情報は、テストパケットのビットレートの単位を通知するための情報である。図７においては、２Ｍｂｐｓから８Ｍｂｐｓまで１Ｍｂｐｓ単位で送信することを通知する場合について示している。
【００５４】
図８は、本実施の形態に係るストリーミングデータ通信システムにおいて、ＳＴＢ１０２が放送サーバ１０１からテストパケットを受信する処理を説明するためのシーケンス図である。
【００５５】
放送サーバ１０１からテストパケットを受信する場合、ＳＴＢ１０２は、まず、放送サーバ１０１から指定されたポートに対してＴＣＰ（Transmission Control Protocol）に従って接続（以下、「ＴＣＰ接続」という）し、ＲＴＳＰ(Real Time Streaming Protocol)に定められた”ＤＥＳＣＲＩＢＥ”を送出する。
【００５６】
この”ＤＥＳＣＲＩＢＥ”には、テストパケットの受信を識別するための識別子（以下、「テスト用ＩＤ」という）に対応するＵＲＬが含まれている。これに対して放送サーバ１０１は、ＲＴＳＰに定められた”ＳＤＰ”をＳＴＢ１０２に送出する。この”ＳＤＰ”には、ＳＥＴＵＰ用のＵＲＬが含まれている。
【００５７】
放送サーバ１０１から”ＳＤＰ”を受信すると、ＳＴＢ１０２は、当該”ＳＤＰ”の解析を行い、ＲＴＳＰに定められた”ＳＥＴＵＰ”を送出する。これに応じて放送サーバ１０１は、ＲＴＰアドレス／ポートをＳＴＢ１０２に送出する。この応答を受けると、ＳＴＢ１０２は、ＲＴＳＰに定められた”ＰＬＡＹ”を送出する。これに応じて放送サーバ１０１は、”ｒｔｐｔｉｍｅ”を送出する。
【００５８】
”ｒｔｐｔｉｍｅ”を送出すると、放送サーバ１０１は、図９に示すように、ＲＴＰストリームをＳＴＢ１０２に送出する。このＲＴＰストリームは、上述のレート情報に示したビットレート単位に応じて送出される。すなわち、上述のレート情報では１Ｍｂｐｓ単位が指定されているので、２Ｍｂｐｓ、３Ｍｂｐｓ・・・８ＭｂｐｓのＲＴＰストリームがＳＴＢ１０２に送出される。
【００５９】
ここで、放送サーバ１０１から送出されるＲＴＰストリーミングを構成するパケットについて図１０を用いて説明する。放送サーバ１０１から送出されるＲＴＰパケットは、図１０に示すように、イーサヘッダ、ＩＰヘッダ、ＵＤＰヘッダ、ＲＴＰヘッダ及びテストデータを含む。ＲＴＰヘッダは、ＲＦＣ１８８９に準拠した１ビットのマークビット及びシーケンス番号を含んでいる。
【００６０】
マークビットは、レート情報におけるビットレートを繰り上げた場合に変更される。上述の例でいえば、２Ｍｂｐｓではマークビットを”０”で送出し、２Ｍｂｐｓから３Ｍｂｐｓにビットレートを変更する場合にマークビットを”１”に変更して送出する。また、３Ｍｂｐｓから４Ｍｂｐｓにビットレートを変更する場合にマークビットを”０”に変更して送出する。ＳＴＢ１０２側では、このマークビットの値を検出することでテストパケットの通信帯域が切り替わったことを検知する。テストデータとしては、特にその内容は限定されず、如何なるデータであってもよい。
【００６１】
図９の例を用いて説明する。放送サーバ１０１は、まず、２ＭｂｐｓのＲＴＰストリームをＳＴＢ１０２に送出する。そして、当該ＲＴＰストリームの送出から一定時間経過後にレート情報に基づいてビットレートを１Ｍｂｐｓ上げ、３ＭｂｐｓのＲＴＰストリームを送出する。このとき、放送サーバ１０１は、ＲＴＰヘッダのマークビットを”０”から”１”に変更する。
【００６２】
ＳＴＢ１０２においては、ＲＴＰヘッダのマークビットが変更されたことを検出して、通信帯域が切り替わったことを検知する。同時に、ＲＴＰヘッダのシーケンス番号の連続性を検出することで、パケットの喪失（パケットロス）をチェックする。
【００６３】
このような処理をレート情報に示された８ＭｂｐｓのＲＴＰストリームまで繰り返す。そして、８ＭｂｐｓのＲＴＰストリームまで完了したならば、パケットロスが発生する直前の通信帯域を利用者側の初期帯域として登録する。ここで、初期帯域とは、ＳＴＢ１０２の最終帯域を決定するために起動処理で予め決めておく通信帯域をいう。そして、ＴＣＰに従って切断する。例えば、パケットロスが５ＭｂｐｓのＲＴＰストリームで発生した場合には、４Ｍｂｐｓが初期帯域として登録されることとなる。
【００６４】
以下、初期帯域が登録されたＳＴＢの要求に応じてストリーミングデータが配信される場合の動作について図１１を用いて説明する。図１１は、本実施の形態に係るストリーミングデータ通信システムにおいて、ＳＴＢの要求に応じてストリーミングデータが配信される動作を説明するためのフロー図である。
【００６５】
図１１に示すように、ＳＴＢがストリーミングデータの配信を要求する場合、ＳＴＢから配信を希望するチャネル番号及び当該ＳＴＢに登録された初期帯域が放送サーバ１０１に送出される。放送サーバ１０１は、このチャネル番号及び初期帯域を受け付ける（ＳＴ１１０１）。
【００６６】
チャネル番号及び初期帯域を受け付けたならば、放送サーバ１０１は、放送サーバ１０１が現在割り当てることができる通信帯域に初期帯域以上の空きがあるか判断する（ＳＴ１１０２）。通信帯域の空きは、図１２に示すチャネルテーブルに設定されたビットレート及びＳＴＢから送出された初期帯域の和と、放送サーバ１０１が有する通信帯域とを比較することで判断される。なお、このチャネルテーブルは、放送サーバ１０１で管理される。
【００６７】
図１２に示すように、チャネルテーブルには、放送サーバ１０１が提供するコンテンツに対応するチャネル番号に対応して、その種別、ビットレート、マルチキャストアドレス／ポート、最新使用日時及びアクセス数が記録されている。各チャネル番号におけるビットレートは、ＳＴＢからの要求に応じてチャネルテーブルに設定されていく。最新使用日時には、当該エントリを最後に使用された日時が記録される。アクセス数には、当該エントリを現在使用しているＳＴＢの数が記録される。
【００６８】
放送サーバ１０１が現在割り当てることができる通信帯域に初期帯域以上の空きがある場合には、放送サーバ１０１は、当該ストリーミングデータの配信を要求してきたＳＴＢの最終帯域を決定する（ＳＴ１１０３）。この最終帯域を決定する処理については後述する。
【００６９】
最終帯域を決定したならば、ＳＴＢからその最終帯域が送出されるので、放送サーバ１０１は、これを受け付ける（ＳＴ１１０４）。そして、最終帯域のストリームを生成し（ＳＴ１１０５）、生成したストリームによってパケットをＳＴＢに送出する（ＳＴ１１０６）。なお、生成されたストリームの通信帯域（ビットレート）は、チャネルテーブルに新たに設定される。
【００７０】
一方、放送サーバ１０１が現在割り当てることができる通信帯域に初期帯域以上の空きがない場合には、放送サーバ１０１は、チャネルテーブルから指定されたチャネル番号（以下、「指定チャネル番号」という）の最大帯域（ビットレート）を取得する（ＳＴ１１０７）。図１２において指定チャネル番号が”１００”であるとすると、最大帯域は”８Ｍｂｐｓ”である。そして、放送サーバ１０１が現在割り当てることができる通信帯域に最大帯域以上の空きがあるか判断する（ＳＴ１１０８）。
【００７１】
放送サーバ１０１が現在割り当てることができる通信帯域に最大帯域以上の空きがある場合には、割り当てることができる分だけの通信帯域のストリームを生成し（ＳＴ１１０９）、生成したストリームによってパケットをＳＴＢに送出する（ＳＴ１１１０）。なお、生成されたストリームの通信帯域（ビットレート）は、チャネルテーブルに設定される。
【００７２】
これに対して、放送サーバ１０１が現在割り当てることができる通信帯域に最大帯域以上の空きがない場合には、指定された初期帯域に最も近い通信帯域（ビットレート）のストリームを選択し（ＳＴ１１１１）、選択したストリームによってパケットをＳＴＢに送出する（ＳＴ１１１２）。
【００７３】
ここで、放送サーバ１０１が現在割り当てることができる通信帯域に応じて具体例を用いて説明する。具体例としては、放送サーバ１０１が現在割り当てることができる通信帯域に初期帯域以上の空きがある場合（図１３）及び放送サーバ１０１が現在割り当てることができる通信帯域に初期帯域以上の空きがない場合（図１８、図２１）について説明する。特に、初期帯域以上の空きがない場合は、放送サーバ１０１が現在割り当てることができる通信帯域に指定チャネル番号の最大帯域以上の空きがない場合（図１８）及び放送サーバ１０１が現在割り当てることができる通信帯域に指定チャネル番号の最大帯域以上の空きがある場合（図２１）について説明する。
【００７４】
図１３は、放送サーバ１０１が現在割り当てることができる通信帯域に初期帯域以上の空きがある場合の一例を示す図である。図１３においては、放送サーバ１０１が１２Ｍｂｐｓの通信帯域を有するものとする。また、現在、ＳＴＢ１０２及びＳＴＢ１０３がストリーミングデータの配信を受けているものとし、ＳＴＢ１０４が新たにストリーミングデータの配信を要求するものとする。なお、ＳＴＢ１０２の最終帯域は、２．２Ｍｂｐｓであり、ＳＴＢ１０３の最終帯域は、１．５Ｍｂｐｓであるものとする。すなわち、放送サーバ１０１は、現在割り当てることができる通信帯域として８．３Ｍｂｐｓの空きを有している。さらに、ＳＴＢ１０４の初期帯域は、５Ｍｂｐｓであるものとし、最終帯域は５．９Ｍｂｐｓであるものとする。
【００７５】
図１４〜図１７は、放送サーバ１０１が現在割り当てることができる通信帯域に初期帯域以上の空きがある場合にストリーミングデータを配信する場合のシーケンス図である。以下、図１３に示す具体例を用いて説明する。
【００７６】
図１４に示すように、ストリーミングデータの配信を要求する場合、ＳＴＢ１０４は、放送サーバ１０１にチャネル番号及び初期帯域を通知する。図１３に示す例では、ＳＴＢ１０４から初期帯域として５Ｍｂｐｓが通知される。
【００７７】
この通知を受けると、放送サーバ１０１は、上述のように、現在割り当てることができる通信帯域に初期帯域以上の空きがあるか判断する。図１３に示す例では、現在割り当てることができる通信帯域として８．３Ｍｂｐｓの空きがあるので、ＳＴＢ１０４の初期帯域（５Ｍｂｐｓ）以上の空きがあると判断される。
【００７８】
続いて、放送サーバ１０１は、通信帯域の空きから最終的に割り当てることができる通信帯域を決定する。すなわち、ＳＴＢ１０４の最終帯域を決定する動作に移行する。その際、放送サーバ１０１は、まず、テストパケットを送信するレート情報及びその送信の際に用いるポートをＳＴＢ１０４に通知する。
【００７９】
レート情報には、初期帯域を決定する際と同様にテストパケットのビットレートの単位が示されるが、１Ｍｂｐｓ単位で送信することを通知する初期帯域の場合とは異なり、１００Ｋｂｐｓ単位で送信することが通知される。なお、かかるレート情報におけるテストパケットのビットレートの単位は、任意に変更可能である。
【００８０】
このレート情報及びポート番号を受信すると、ＳＴＢ１０４は、図１５に示すように、放送サーバ１０１から指定されたポートに対してＴＣＰ接続し、ＲＴＳＰ(Real Time Streaming Protocol)に定められた”ＤＥＳＣＲＩＢＥ”を送出する。この”ＤＥＳＣＲＩＢＥ”には、テスト用ＩＤに対応するＵＲＬが含まれている。これに対して放送サーバ１０１０は、ＲＴＳＰに定められた”ＳＤＰ”をＳＴＢ１０４に送出する。この”ＳＤＰ”には、ＳＥＴＵＰ用のＵＲＬが含まれている。
【００８１】
放送サーバ１０１から”ＳＤＰ”を受信すると、ＳＴＢ１０４は、当該”ＳＤＰ”の解析を行い、ＲＴＳＰに定められた”ＳＥＴＵＰ”を送出する。これに応じて放送サーバ１０１は、ＲＴＰアドレス／ポートをＳＴＢ１０４に送出する。この応答を受けると、ＳＴＢ１０４は、ＲＴＳＰに定められた”ＰＬＡＹ”を送出する。これに応じて放送サーバ１０１は、”ｒｔｐｔｉｍｅ”を送出する。
【００８２】
”ｒｔｐｔｉｍｅ”を送出すると、放送サーバ１０１は、図１６に示すように、ＲＴＰストリームをＳＴＢ１０４に送出する。このＲＴＰストリームは、上述のレート情報に示した単位に応じて送出される。すなわち、上述のレート情報では１００Ｋｂｐｓ単位が指定されているので、初期帯域＋１００Ｋｂｐｓ、初期帯域＋２００Ｋｂｐｓ・・・初期帯域＋１０００ＫｂｐｓのＲＴＰストリームがＳＴＢ１０４に送出される。
【００８３】
ＲＴＰパケットのマークビットは、初期帯域の場合と同様に、レート情報におけるビットレートを繰り上げた場合に変更され、このマークビットの値を検出することでテストパケットの通信帯域が切り替わったことをＳＴＢ１０４側で検知する。同時に、ＲＴＰヘッダのシーケンス番号の連続性を検出することで、パケットロスをチェックする。そして、パケットロスが発生する直前の通信帯域を利用者側の最終帯域として登録する。最後に、ＴＣＰに従って切断する。図１３に示す例では、初期帯域である５Ｍｂｐｓ＋１０００Ｋｂｐｓでパケットロスが発生し、５．９ＭｂｐｓがＳＴＢ１０４の最終帯域として登録されることとなる。
【００８４】
最終帯域が登録されたならば、ＳＴＢ１０４は、図１７に示すように、これを放送サーバ１０１に通知する。最終帯域を受け取ったならば、放送サーバ１０１は、指定チャネル番号の最終帯域のマルチキャストストリームを生成し、ＲＴＰパケットをＩＰルータに送信する。そして、チャネルテーブルにエントリを追加し、アクセス数をインクリメントする。
【００８５】
その後、放送サーバ１０１は、指定チャネル番号のマルチキャストアドレス・ポートをＳＴＢ１０４に通知する。この通知を受けると、ＳＴＢ１０４は、ＩＰルータに対し、ＩＧＭＰ（Internet Gateway Multicast Protocol）プロトコルに定められたＪＯＩＮパケットを送出する。なお、このＪＯＩＮパケットには、ＳＴＢが配信を希望するストリーミングデータが送られてくるマルチキャストアドレスが指定されている。
【００８６】
ＩＰルータは、このＪＯＩＮパケットを受信すると、指定されたマルチキャストアドレスに対応するゲートを開く。これにより、放送サーバ１０１から当該マルチキャストアドレスで配信されるＲＴＰパケットをＳＴＢ１０４で受信することができるようになる。
【００８７】
ＳＴＢ１０４では、このＲＴＰパケットを受信して再生する。そして、所望の再生が完了したならば、ＩＧＭＰプロトコルに定められたＬＥＡＶＥパケットを送出する。このＬＥＡＶＥパケットを受信すると、ＩＰルータが先のマルチキャストアドレスに対応するゲートを閉じる。これにより、ＲＴＰパケットをＳＴＢで受信することができなくなる。
【００８８】
最後に、ＳＴＢ１０４は、放送サーバ１０１に対して受信終了を通知する。受信終了を受信すると、放送サーバ１０１は、チャネルテーブルの指定チャネル番号のアクセス数をデクリメントして処理を終了する。
【００８９】
このように放送サーバ１０１が現在割り当てることができる通信帯域に初期帯域以上の空きがある場合には、ＳＴＢ１０４の最終帯域を決定し、その最終帯域のマルチキャストストリームを生成してストリーミングデータを配信する。
【００９０】
このように本実施の形態に係るストリーミングデータ通信システムによれば、ＳＴＢ１０４において、放送サーバ１０１から送出されたテストパケットから検出されたパケットロスに応じて適正なビットレート（最終帯域）を判断するので、ネットワーク上のＳＴＢ１０４に適したビットレートを検出することができる。
【００９１】
また、本実施の形態に係るストリーミングデータ通信システムによれば、ビットレートが繰り上げられて送出されるテストパケットにおいてパケットロスを検出した場合、当該ビットレートの直前のビットレートが適正なビットレート（最終帯域）と判断するので、パケットロスを検出するという簡単な制御を行うだけで適正なビットレートを容易に検出することができる。
【００９２】
さらに、本実施の形態に係るストリーミングデータ通信システムによれば、テストパケットのヘッダに含まれるマークビットを検出することでテストパケットのビットレートの変化を認識することができるので、マークビットのみを検出するという簡単な制御を行うだけでビットレートの変化を容易に認識することができる。
【００９３】
図１８は、放送サーバ１０１が現在割り当てることができる通信帯域に初期帯域以上の空きがない場合の一例を示す図である。特に、図１８は、放送サーバ１０１が現在割り当てることができる通信帯域に指定チャネル番号の最大帯域以上の空きがない場合の一例を示す図である。
【００９４】
なお、図１８においては、ＳＴＢ１０２及び１０３の最終帯域がそれぞれ６Ｍｂｐｓ及び４Ｍｂｐｓである点、並びに、ＳＴＢ１０４の初期帯域が８Ｍｂｐｓである点で図１３に示す例と相違する。すなわち、放送サーバ１０１は、現在割り当てることができる通信帯域として２Ｍｂｐｓの空きを有している。なお、ＳＴＢ１０２及びＳＴＢ１０３は、ＳＴＢ１０４による指定チャネル番号と同一のチャネル番号のストリーミングデータの配信を受けているものとし、この指定チャネル番号においては他のビットレートは設定されていないものとする。
【００９５】
図１９及び図２０は、放送サーバ１０１が現在割り当てることができる通信帯域に初期帯域以上の空きがない場合にストリーミングデータを配信する場合のシーケンス図である。以下、図１８に示す具体例を用いて説明する。
【００９６】
図１９に示すように、ストリーミングデータの配信を要求する場合、ＳＴＢ１０４は、放送サーバ１０１にチャネル番号及び初期帯域を通知する。図１８に示す例では、ＳＴＢ１０４から初期帯域として８Ｍｂｐｓが通知される。
【００９７】
この通知を受けると、放送サーバ１０１は、上述のように、現在割り当てることができる通信帯域に初期帯域以上の空きがあるか判断する。図１８に示す例では、現在割り当てることができる通信帯域として２Ｍｂｐｓしか空きがないので、ＳＴＢ１０４の初期帯域（８Ｍｂｐｓ）以上の空きがないと判断される。
【００９８】
次に、放送サーバ１０１は、現在割り当てることができる通信帯域に、ＳＴＢ１０４による指定チャネル番号の最大帯域以上の空きがあるか判断する。図１８に示す例では、ＳＴＢ１０４による指定チャネル番号の最大帯域が６Ｍｂｐｓであるものとする。このため、放送サーバ１０１は、現在割り当てることができる通信帯域に６Ｍｂｐｓ以上の空きがあるか判断する。ここでは、現在割り当てることができる通信帯域として２Ｍｂｐｓしか空きがないので、ＳＴＢ１０４による指定チャネル番号の最大帯域（６Ｍｂｐｓ）以上の空きがないと判断される。
【００９９】
この場合、放送サーバ１０１は、ＳＴＢ１０４の初期帯域（８Ｍｂｐｓ）未満で最も近い通信帯域のエントリを取得する。ここでは、ＳＴＢ１０２が受信している６Ｍｂｐｓが最も近い。このため、放送サーバ１０１は、６Ｍｂｐｓのエントリを取得する。同時に、チャネルテーブルにおけるこのエントリのアクセス数をインクリメントする。
【０１００】
続いて、放送サーバ１０１は、図２０に示すように、指定チャネル番号のマルチキャストアドレス・ポートをＳＴＢ１０４に通知する。この通知を受けると、ＳＴＢ１０４は、ＩＰルータに対し、ＩＧＭＰプロトコルに定められたＪＯＩＮパケットを送出する。なお、このＪＯＩＮパケットには、ＳＴＢが配信を希望するストリーミングデータが送られてくるマルチキャストアドレスが指定されている。
【０１０１】
このＪＯＩＮパケットを受信すると、ＩＰルータは、指定されたマルチキャストアドレスに対応するゲートを開く。これにより、放送サーバ１０１から当該マルチキャストアドレスで配信されるＲＴＰパケットをＳＴＢ１０４で受信することができるようになる。
【０１０２】
ＳＴＢ１０４では、このＲＴＰパケットを受信して再生する。再生が完了したならば、ＩＧＭＰプロトコルに定められたＬＥＡＶＥパケットを送出する。このＬＥＡＶＥパケットを受信すると、ＩＰルータが先のマルチキャストアドレスに対応するゲートを閉じる。これにより、ＲＴＰパケットをＳＴＢで受信することができなくなる。
【０１０３】
最後に、ＳＴＢ１０４は、放送サーバ１０１に対して受信終了を通知する。受信終了を受信すると、放送サーバ１０１は、チャネルテーブルの指定チャネル番号のアクセス数をデクリメントして処理を終了する。
【０１０４】
このように放送サーバ１０１が現在割り当てることができる通信帯域に初期帯域以上の空きがない場合であって、指定チャネル番号の最大帯域以上の空きがない場合には、現在、設定されている通信帯域（ビットレート）のうち、最も初期帯域に近いものを選択して当該マルチキャストストリームを用いてストリーミングデータを配信する。
【０１０５】
図２１は、放送サーバ１０１が現在割り当てることができる通信帯域に初期帯域以上の空きがない場合の一例を示す図である。特に、図２１は、放送サーバ１０１が現在割り当てることができる通信帯域に指定チャネル番号の最大帯域以上の空きがある場合の一例を示す図である。
【０１０６】
なお、図２１においては、ＳＴＢ１０２及び１０３の最終帯域がそれぞれ４Ｍｂｐｓ及び３Ｍｂｐｓである点、並びに、ＳＴＢ１０４の初期帯域が６Ｍｂｐｓである点で図１３に示す例と相違する。すなわち、放送サーバ１０１は、現在割り当てることができる通信帯域として５Ｍｂｐｓの空きを有している。なお、ＳＴＢ１０２及びＳＴＢ１０３は、ＳＴＢ１０４による指定チャネル番号と同一のチャネル番号のストリーミングデータの配信を受けているものとし、この指定チャネル番号においては他のビットレートは設定されていないものとする。
【０１０７】
図２２及び図２３は、放送サーバ１０１が現在割り当てることができる通信帯域に初期帯域以上の空きがない場合にストリーミングデータを配信する場合のシーケンス図である。以下、図２１に示す具体例を用いて説明する。
【０１０８】
図２２に示すように、ストリーミングデータの配信を要求する場合、ＳＴＢ１０４は、放送サーバ１０１にチャネル番号及び初期帯域を通知する。図２１に示す例では、ＳＴＢ１０４から初期帯域として６Ｍｂｐｓが通知される。
【０１０９】
この通知を受けると、放送サーバ１０１は、上述のように、現在割り当てることができる通信帯域に初期帯域以上の空きがあるか判断する。図２１に示す例では、現在割り当てることができる通信帯域として５Ｍｂｐｓしか空きがないので、ＳＴＢ１０４の初期帯域（６Ｍｂｐｓ）以上の空きがないと判断される。
【０１１０】
次に、放送サーバ１０１は、現在割り当てることができる通信帯域に、ＳＴＢ１０４による指定チャネル番号の最大帯域以上の空きがあるか判断する。図２１に示す例では、ＳＴＢ１０４による指定チャネル番号の最大帯域が４Ｍｂｐｓであるものとする。このため、放送サーバ１０１は、現在割り当てることができる通信帯域に４Ｍｂｐｓ以上の空きがあるか判断する。ここでは、現在割り当てることができる通信帯域として５Ｍｂｐｓの空きがあるので、ＳＴＢ１０４による指定チャネル番号の最大帯域（４Ｍｂｐｓ）以上の空きがあると判断される。
【０１１１】
ＳＴＢ１０４による指定チャネル番号の最大帯域（４Ｍｂｐｓ）以上の空きがあると判断したならば、図２３に示すように、放送サーバ１０１は、空き帯域のビットレート（５Ｍｂｐｓ）で指定チャネル番号のマルチキャストストリームを生成し、ＲＴＰパケットをＩＰルータに送信する。そして、チャネルテーブルにエントリを追加し、アクセス数をインクリメントする。
【０１１２】
その後、放送サーバ１０１は、指定チャネル番号のマルチキャストアドレス・ポートをＳＴＢ１０４に通知する。この通知を受けると、ＳＴＢ１０４は、ＩＰルータに対し、ＩＧＭＰプロトコルに定められたＪＯＩＮパケットを送出する。なお、このＪＯＩＮパケットには、ＳＴＢが配信を希望するストリーミングデータが送られてくるマルチキャストアドレスが指定されている。
【０１１３】
このＪＯＩＮパケットを受信すると、ＩＰルータは、指定されたマルチキャストアドレスに対応するゲートを開く。これにより、放送サーバ１０１から当該マルチキャストアドレスで配信されるＲＴＰパケットをＳＴＢ１０４で受信することができるようになる。
【０１１４】
ＳＴＢ１０４では、このＲＴＰパケットを受信して再生する。そして、所望の再生が完了したならば、ＩＧＭＰプロトコルに定められたＬＥＡＶＥパケットを送出する。このＬＥＡＶＥパケットを受信すると、ＩＰルータが先のマルチキャストアドレスに対応するゲートを閉じる。これにより、ＲＴＰパケットをＳＴＢで受信することができなくなる。
【０１１５】
最後に、ＳＴＢ１０４は、放送サーバ１０１に対して受信終了を通知する。受信終了を受信すると、放送サーバ１０１は、チャネルテーブルの指定チャネル番号のアクセス数をデクリメントして処理を終了する。
【０１１６】
このように放送サーバ１０１が現在割り当てることができる通信帯域に初期帯域以上の空きがない場合であって、指定チャネル番号の最大帯域以上の空きがある場合には、その空き帯域のビットレートのマルチキャストストリームを生成してストリーミングデータを配信する。
【０１１７】
このように本実施の形態に係るストリーミングデータ通信システムによれば、放送サーバ１０１が現在割り当てることができる通信帯域に初期帯域以上の空きがある場合には、ＳＴＢ１０４の最終帯域のマルチキャストストリームを生成してストリーミングデータを配信する。また、放送サーバ１０１が現在割り当てることができる通信帯域に初期帯域以上の空きがない場合であって、指定チャネル番号の最大帯域以上の空きがない場合には、現在、設定されている通信帯域（ビットレート）のうち、最も初期帯域に近いものを選択して当該マルチキャストストリームを用いてストリーミングデータを配信する。さらに、放送サーバ１０１が現在割り当てることができる通信帯域に初期帯域以上の空きがない場合であって、指定チャネル番号の最大帯域以上の空きがある場合には、その空き帯域のビットレートのマルチキャストストリームを生成してストリーミングデータを配信する。このため、ストリーミングデータの配信先のＳＴＢのネットワーク環境に対応しつつ、放送サーバ１０１の通信帯域をより効率的に利用してストリーミングデータを配信することができる。
【０１１８】
なお、以上説明したように本実施の形態に係るストリーミングデータ通信システムにおいては、ストリーミングデータの配信先のＳＴＢのネットワーク環境に対応しつつ、放送サーバ１０１の通信帯域をより効率的に利用してストリーミングデータを配信する。すなわち、ストリーミングデータの配信先のＳＴＢのネットワーク環境に応じたビットレートのマルチキャストストリームを生成してストリーミングデータを配信する。
【０１１９】
しかしながら、ストリーミングデータの配信先のＳＴＢのネットワーク環境が変化した場合には、変更前のネットワーク環境に応じてビットレートのマルチキャストストリームを配信し続けることは好ましくない。このため、本実施の形態に係るストリーミングデータ通信システムにおいては、チャネルテーブル上で一定時間アクセス数がないエントリを自動的に削除する。
【０１２０】
図２４は、本実施の形態に係るストリーミングデータ通信システムにおいて、チャネルテーブル上で一定時間アクセス数がないエントリを自動的に削除する動作を説明するためのフロー図である。
【０１２１】
図２４に示すように、放送サーバ１０１は、一定時間の経過を監視している（ＳＴ２４０１）。そして、一定時間が経過したならば、チャネルテーブルの検索を行い（ＳＴ２４０２）、アクセス数が”０”であるエントリがあるか判断する（ＳＴ２４０３）。
【０１２２】
ここで、アクセス数が”０”であるエントリがあった場合には、当該エントリの最終アクセス時間から一定時間が経過しているか判断する（ＳＴ２４０４）。最終アクセス時間からの一定時間の経過の判断は、チャネルテーブル上の最新使用日時と現在時刻とを比較することで行う。
【０１２３】
当該エントリの最終アクセス時間から一定時間が経過している場合には、放送サーバ１０１は、当該エントリを削除する（ＳＴ２４０５）。そして、当該エントリのビットレートによるマルチキャストストリームの生成を停止する（ＳＴ２４０６）。これにより、当該エントリのビットレートによるマルチキャストストリームの配信が停止される。
【０１２４】
そして、放送サーバ１０１は、全てのエントリに対して当該削除処理を完了したか判断する（ＳＴ２４０７）。全てのエントリに対して完了している場合には処理を終了し、完了していない場合には処理をＳＴ２４０２に戻し、再びＳＴ２４０２以降の処理を繰り返す。
【０１２５】
なお、ＳＴ２４０３においてアクセス数が”０”のエントリがない場合、あるいは、ＳＴ２４０４においてアクセス数が”０”のエントリの最終アクセス時間から一定時間が経過していない場合には、放送サーバ１０１は、処理をＳＴ２４０７に以降し、全てのエントリに対して当該削除処理を完了したか判断する。
【０１２６】
このように本実施の形態に係るストリーミングデータ通信システムによれば、チャネルテーブル上で一定時間アクセス数がないエントリを自動的に削除する。このため、当該エントリのビットレート（通信帯域）によるマルチキャストストリームの生成が停止される。したがって、その通信帯域の分だけさらに他のＳＴＢに割り当てることが可能となる。この結果、通信帯域を必要とするＳＴＢに新たに割り当てることができるので、ストリーミングデータの配信先のＳＴＢのネットワーク環境に対応しつつ、放送サーバ１０１の通信帯域をより効率的に利用することができる。
【０１２７】
また、本発明は、当業者に明らかなように、上記実施の形態に記載した技術に従ってプログラムされた一般的な市販のデジタルコンピュータおよびマイクロプロセッサを使って実施することができる。また、当業者に明らかなように、本発明は、上記実施の形態に記載した技術に基づいて当業者により作成されるコンピュータプログラムを包含する。
【０１２８】
また、本発明を実施するコンピュータをプログラムするために使用できる命令を含む記憶媒体であるコンピュータプログラム製品が本発明の範囲に含まれる。この記憶媒体は、フロッピー（Ｒ）ディスク、光ディスク、ＣＤＲＯＭ及び磁気ディスク等のディスク、ＲＯＭ、ＲＡＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭ、磁気光カード、メモリカードまたはＤＶＤ等であるが、特にこれらに限定されるものではない。
【産業上の利用可能性】
【０１２９】
本発明に係るストリーミングデータ通信システム、ストリーミングデータ通信装置及び適正ビットレート検出方法によれば、ネットワーク上のＳＴＢに適したビットレートを検出し、その検出結果に応じてストリーミングデータの配信に活用することで放送サーバが有する通信帯域を効率的に利用できる点で有用である。
【図面の簡単な説明】
【０１３０】
【図１】本発明の一実施の形態に係るストリーミングデータ通信システムが適用されるネットワークの構成を示す図
【図２】上記実施の形態に係るストリーミングデータ通信システムにおけるＳＴＢ周辺のネットワーク環境を示すブロック図
【図３】上記実施の形態に係るストリーミングデータ通信システムにおけるＳＴＢの構成を示すブロック図
【図４】上記実施の形態に係るストリーミングデータ通信システムにおけるＳＴＢが備えるＣＰＵの機能ブロック図
【図５】上記実施の形態に係るストリーミングデータ通信システムにおける放送サーバの構成を示すブロック図
【図６】上記実施の形態に係るストリーミングデータ通信システムにおけるＳＴＢの起動処理を説明するためのシーケンス図
【図７】上記実施の形態に係るストリーミングデータ通信システムにおいて、放送サーバから送信されるレート情報の一例を示す図
【図８】上記実施の形態に係るストリーミングデータ通信システムにおいて、ＳＴＢが放送サーバからテストパケットを受信する処理を説明するためのシーケンス図
【図９】上記実施の形態に係るストリーミングデータ通信システムにおいて、ＳＴＢが放送サーバからテストパケットを受信する処理を説明するためのシーケンス図
【図１０】上記実施の形態に係るストリーミングデータ通信システムにおいて、放送サーバから送出されるＲＴＰストリーミングを構成するパケットについて示す図
【図１１】上記実施の形態に係るストリーミングデータ通信システムにおいて、ＳＴＢの要求に応じてストリーミングデータが配信される動作を説明するためのフロー図
【図１２】上記実施の形態に係るストリーミングデータ通信システムにおいて、放送サーバが登録するチャネルテーブルの一例について示す図
【図１３】上記実施の形態に係るストリーミングデータ通信システムにおいて、放送サーバが現在割り当てることができる通信帯域に初期帯域以上の空きがある場合の一例を示す図
【図１４】上記実施の形態に係るストリーミングデータ通信システムにおいて、放送サーバが現在割り当てることができる通信帯域に初期帯域以上の空きがある場合にストリーミングデータを配信する場合のシーケンス図
【図１５】上記実施の形態に係るストリーミングデータ通信システムにおいて、放送サーバが現在割り当てることができる通信帯域に初期帯域以上の空きがある場合にストリーミングデータを配信する場合のシーケンス図
【図１６】上記実施の形態に係るストリーミングデータ通信システムにおいて、放送サーバが現在割り当てることができる通信帯域に初期帯域以上の空きがある場合にストリーミングデータを配信する場合のシーケンス図
【図１７】上記実施の形態に係るストリーミングデータ通信システムにおいて、放送サーバが現在割り当てることができる通信帯域に初期帯域以上の空きがある場合にストリーミングデータを配信する場合のシーケンス図
【図１８】上記実施の形態に係るストリーミングデータ通信システムにおいて、放送サーバが現在割り当てることができる通信帯域に初期帯域以上の空きがない場合の一例を示す図
【図１９】上記実施の形態に係るストリーミングデータ通信システムにおいて、放送サーバが現在割り当てることができる通信帯域に初期帯域以上の空きがない場合にストリーミングデータを配信する場合のシーケンス図
【図２０】上記実施の形態に係るストリーミングデータ通信システムにおいて、放送サーバが現在割り当てることができる通信帯域に初期帯域以上の空きがない場合にストリーミングデータを配信する場合のシーケンス図
【図２１】上記実施の形態に係るストリーミングデータ通信システムにおいて、放送サーバが現在割り当てることができる通信帯域に初期帯域以上の空きがない場合の一例を示す図
【図２２】上記実施の形態に係るストリーミングデータ通信システムにおいて、放送サーバが現在割り当てることができる通信帯域に初期帯域以上の空きがない場合にストリーミングデータを配信する場合のシーケンス図
【図２３】上記実施の形態に係るストリーミングデータ通信システムにおいて、放送サーバが現在割り当てることができる通信帯域に初期帯域以上の空きがない場合にストリーミングデータを配信する場合のシーケンス図
【図２４】上記実施の形態に係るストリーミングデータ通信システムにおいて、チャネルテーブル上で一定時間アクセス数がないエントリを自動的に削除する動作を説明するためのフロー図
【符号の説明】
【０１３１】
１０１  放送サーバ
１０２〜１０６  ＳＴＢ（セットトップボックス）
１０７〜１１１  ディスプレイ
１１２  ＴＶチューナー
２０２  モデム
２０３  ルータ／ハブ
３０１  ＣＰＵ
３０２  メモリ
３０４  記憶装置
４０１  ストリーミング処理部
４０２  ＴＶ再生部
４０３  通信品質測定部
４０４  リモコン処理部
５０１  ビットレート変換部
５０２  パケット送出部
５０３  ＳＴＢ通信部
【図１】
2005167514.tif 000003
【図２】
2005167514.tif 000004
【図３】
2005167514.tif 000005
【図４】
2005167514.tif 000006
【図５】
2005167514.tif 000007
【図６】
2005167514.tif 000008
【図７】
2005167514.tif 000009
【図８】
2005167514.tif 000010
【図９】
2005167514.tif 000011
【図１０】
2005167514.tif 000012
【図１１】
2005167514.tif 000013
【図１２】
2005167514.tif 000014
【図１３】
2005167514.tif 000015
【図１４】
2005167514.tif 000016
【図１５】
2005167514.tif 000017
【図１６】
2005167514.tif 000018
【図１７】
2005167514.tif 000019
【図１８】
2005167514.tif 000020
【図１９】
2005167514.tif 000021
【図２０】
2005167514.tif 000022
【図２１】
2005167514.tif 000023
【図２２】
2005167514.tif 000024
【図２３】
2005167514.tif 000025
【図２４】
2005167514.tif 000026