(57)【要約】【課題】本発明の目的は、放送サーバが最大帯域幅でデータを送信できるようにするＩＰＴＶ放送サービスのトラフィック制御方法を提供することである。【解決手段】放送サーバが最大バッファ量を設定する第１ステップと、前記放送サーバがネットワークの状態をモニタリングして、ネットワークの許容する最大帯域幅でデータを送信する第２ステップと、前記放送サーバが送信されたバッファ量が最大バッファに到達したか否かを判断する第３ステップと、送信されたバッファ量が最大バッファ量に到達すると、前記放送サーバがセットトップボックスのプレー速度に応じて帯域幅を調節しデータを送信する第４ステップと、送信されたバッファリング量が最大バッファリング量に達しないと、前記放送サーバがネットワークの許容する最大帯域幅でデータを送信する第５ステップとを備えて、前記放送サーバが最大帯域幅でデータを送信できるように主導的にトラフィックを制御することによって、セットトップボックスが中断なしで放送を再生できるようにしたものである。【選択図】図１
2011501478.tif 000002
【特許請求の範囲】
【請求項１】
放送サーバがセットトップボックスの現在バッファ量に応じて送信帯域幅を調節しデータ送信量を可変調節して、前記セットトップボックスの現在バッファ量が前記放送サーバの設定した目標バッファ量を維持するようにするＩＰＴＶ放送サービスのトラフィック制御方法であって、
前記放送サーバが前記セットトップボックスの目標バッファ量を設定する第１ステップと、
前記放送サーバがネットワークの状態をモニタリングして、ネットワークの許容する限度内で最大帯域幅で前記セットトップボックスにデータを送信する第２ステップと、
前記放送サーバが前記セットトップボックスの現在バッファ量を確認する第３ステップと、
前記セットトップボックスの現在バッファ量が前記目標バッファ量に到達すると、前記放送サーバが前記セットトップボックスのプレー速度に合せて送信帯域幅を調節しデータ送信量を減らす第４ステップと
を含むことを特徴とするＩＰＴＶ放送サービスのトラフィック制御方法。
【請求項２】
前記目標バッファ量が、
ネットワークの状態変化に応じる前記放送サーバからのデータ送信量の変化に影響を受けずに前記セットトップボックスがコンテンツを中断及び遅延無しで安定してプレーするために確保しなければならないバッファ量である
ことを特徴とする請求項１に記載のＩＰＴＶ放送サービスのトラフィック制御方法。
【請求項３】
前記第３ステップが、
前記放送サーバが、前記放送サーバの送信帯域幅、送信時間及び前記セットトップボックスのプレー時間を利用して、前記セットトップボックスの現在バッファ量を算出する第３−１ステップを含む
ことを特徴とする請求項１に記載のＩＰＴＶ放送サービスのトラフィック制御方法。
【請求項４】
前記第４ステップにおいて、
前記放送サーバが、前記セットトップボックスにおいて処理及びプレーされる量だけデータを送信する
ことを特徴とする請求項１に記載のＩＰＴＶ放送サービスのトラフィック制御方法。
【請求項５】
前記第４ステップ以後に、
前記放送サーバが前記セットトップボックスの現在バッファ量を確認する第５ステップと、
前記セットトップボックスの現在バッファ量が前記目標バッファ量以下に減少すると、前記放送サーバが前記ネットワークの許容する限度内で最大帯域幅でデータを送信する第６ステップとをさらに含む
ことを特徴とする請求項１に記載のＩＰＴＶ放送サービスのトラフィック制御方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、インターネットプロトコルテレビ（以下、ＩＰＴＶとする）のためのデータ送信技術に関し、さらに詳細には、放送サーバがセットトップボックスへのデータ送信量を可変的に調節してセットトップボックスのバッファ量を一定水準に維持することによって、ネットワークの状態にかかわらずセットトップボックスにおいてコンテンツを遅延無しで安定してプレーできるようにするＩＰＴＶ放送サービスのトラフィック制御方法に関する。
【背景技術】
【０００２】
一般に、ＩＰＴＶは、品質、保安及び信頼性の保障されたＩＰ網を介して提供されるテレビ、ビデオ、オーディオ、文書、グラフィック及びデータサービスなどのようなマルチメディアサービスと定義しており、マルチキャスト方式で送信が行われるライブ放送ＴＶサービスと、ユニキャスト方式で送信が行われるＶＯＤのような格納されたビデオ（ｓｔｏｒｅｄ  ｖｉｄｅｏ）サービスを含む。
【０００３】
通常、ＩＰＴＶシステムは、コンテンツ（プログラム）をＩＰ網に送出する放送サーバと、ＩＰ網からコンテンツを受信して再生するＩＰＴＶセットトップボックス（ＳＴＢ）とから構成されるが、ＩＰ網を介して送信されるビデオ信号は、ＭＰＥＧ２やＭＰＥＧ４のような圧縮方式に従って符号化されたビートストリームであって、生放送ＴＶサービスは、ＩＧＭＰｖ２プロトコルに従ってマルチキャストストリームに接続して放送を視聴でき、ＶＯＤサービスの場合は、ＲＴＳＰプロトコルに従ってユニキャスト方式でビデオコンテンツを視聴することができる。
【０００４】
一定の帯域幅（ｂａｎｄｗｉｄｔｈ）でデータを送信し、セットトップボックス（ＳＴＢ）は、これを受信してバッファリング及びプレーする。したがって、ネットワークの状態が良好であるという仮定下において放送サーバのデータ送信、セットトップボックスのバッファリング、及びプレーは同様に行われる。すなわち、例えば、放送サーバから送信されるデータをセットトップボックスでバッファリングしてプレーするのに３秒がかかると、放送サーバとセットトップボックス（ＳＴＢ）とは３秒の遅延間隔をおいてコンテンツを送信及びプレーし続けるようになる。このような従来のＩＰＴＶ放送サービスにおいてトラフィック制御過程は、図９に示されている。
図９に示すように、従来のＩＰＴＶ放送サービスでは、セットトップボックス２００が自身の受信バッファをチェックして余裕があると、放送サーバ１００にデータ（コンテンツ）の送信を要請する（Ｓ１、Ｓ２、Ｓ４）。放送サーバ１００は、セットトップボックス２００から送信要請が受信されれば、一定帯域幅でデータ（コンテンツ）を送信する（Ｓ６、Ｓ７）。一方、ステップＳ２にてセットトップボックス２００の受信バッファに余裕がない場合、セットトップボックスは、受信バッファのデータを処理して、ある程度余裕が生じるまで待機した後、余裕が生じると、送信を要請するようになる（Ｓ５）。
【０００５】
このように、従来のＩＰＴＶ放送サービスでは、セットトップボックスを中心にトラフィック制御及びバッファリングが行われるので、ネットワークの状態が良好であって放送サーバからより大きな帯域幅で多量のデータを送信できても、セットトップボックスにおいて要請される分だけ（セットトップボックスでプレーされる量分だけ）のみデータを送信せざるをえなかった。そのため、ネットワーク資源を效率的に活用できないという問題点があった。また、放送サーバが常に一定帯域幅でデータを送信するからセットトップボックスでは充分なバッファ量を確保できないので、万一、ネットワークの状態が不安定になるなどの理由で放送サーバからのデータの送信量が減少する場合、一定量のデータが受信されるまでセットトップボックスでのプレーが遅れるという問題点があった。
【発明の概要】
【発明が解決しようとする課題】
【０００６】
本発明は、上記の問題点を解決するために提案されたものであって、本発明の目的は、ネットワークの状態に影響を受けずにセットトップボックスにおいてコンテンツを安定してプレーできるバッファ量の目標バッファ量を設定し、放送サーバでトラフィックを制御してセットトップボックスへのデータ送信量を可変的に調節することによって、セットトップボックスが目標バッファ量を維持してコンテンツを遅延無しで安定してプレーできるようにする、ＩＰＴＶ放送サービスのトラフィック制御方法を提供することにある。
【０００７】
また、本発明の他の目的は、放送サーバから送信できる最大帯域幅で最大限データを送信してセットトップボックスのバッファ量を目標バッファ量分だけ確保し、セットトップボックスのバッファ量が減少すると、再度最大帯域幅で最大限データを送信してセットトップボックスのバッファ量を目標バッファ量分だけ維持し続けるようにすることによって、セットトップボックスが充分なバッファ量を確保してネットワークの不安定などにより放送サーバからのデータ送信量が減少しても、コンテンツのプレーが遅れるのを防止できるＩＰＴＶ放送サービスのトラフィック制御方法を提供することにある。
【課題を解決するための手段】
【０００８】
上記の目的を達成すべく、本発明の方法は、放送サーバが最大バッファ量を設定する第１ステップと、前記放送サーバがネットワークの状態をモニタリングして、ネットワークの許容する最大帯域幅でデータを送信する第２ステップと、前記放送サーバが送信されたバッファ量が最大バッファに到達したか否かを判断する第３ステップと、送信されたバッファ量が最大バッファ量に到達すると、前記放送サーバがセットトップボックスのプレー速度に応じて帯域幅を調節しデータを送信する第４ステップと、送信されたバッファリング量が最大バッファリング量に達しないと、前記放送サーバがネットワークの許容する最大帯域幅でデータを送信する第５ステップとを備えることを特徴とする。
【発明の効果】
【０００９】
本発明によれば、放送サーバがセットトップボックスのバッファ量に応じて送信帯域幅を調節してデータの送信量を可変調節することによって、放送サーバを中心にトラフィックの制御及びバッファリングが行われるので、ネットワークの状態が良好な場合より大きな帯域幅で多量のデータを送信して効率性を高めることができ、ネットワークの状態が良くなくてもセットトップボックスで予めバッファ量を十分に確保することによって、コンテンツの中断及び遅延無しで安定してプレーできるという顕著な効果がある。
【００１０】
言い換えれば、放送サーバがセットトップボックスの目標バッファ量を設定し、セットトップボックスのバッファ量が目標バッファ量に達しない場合、ネットワークが許容する限度で最大帯域幅でデータを最大限送信し、セットトップボックスのバッファ量が目標バッファ量に到達する場合、セットトップボックスでプレーされる量だけ適切な帯域幅でデータを送信するので、ネットワーク資源（特に、トラフィック）を效率的に活用できる。また、ネットワークの状態が悪くなって放送サーバから送信されるデータ量が減少しても、セットトップボックスが既に目標バッファ量分だけ十分な量のデータをバッファリングしているので、中断又は遅延無しでコンテンツをプレーできるようになる。
【図面の簡単な説明】
【００１１】
【図１】一般的なＩＰＴＶ網の全体構成を示す概略図である。
【図２】ライブコンテンツを送信するためのＩＰマルチキャスト網の構成例である。
【図３】マルチキャストにおいて主に用いられるＵＤＰフォーマットの例である。
【図４】マルチキャストにおいて用いられるＩＧＭＰフォーマットの例である。
【図５】ＩＧＭＰによるチャネル設定手順の例である。
【図６】ユニキャストにおいて主に用いられるＴＣＰセグメントの例である。
【図７】ユニキャストにおいて主に用いられるＲＴＳＰによるチャネル設定手順の例である。
【図８】本発明によるＩＰＴＶ放送サービスにおけるトラフィック制御方法のフローチャートである。
【図９】従来の技術によるＩＰＴＶ放送サービスにおけるトラフィック制御方法のフローチャートである。
【発明を実施するための形態】
【００１２】
以下、添付された図面を参照して、本発明の好ましい実施の形態を詳細に説明する。
図１は、一般的なＩＰＴＶ網の全体構成を示す概略図であって、インターネット１０を介してテレビ放送サービスを提供するＩＰＴＶ放送サーバ１００と、インターネット１０に接続されており、ユーザのリモコン２０２の操作によって動作されて、ＩＰＴＶ放送サーバ１００が提供する生放送テレビ放送を受信するか、又はＶＯＤコンテンツを受信してディスプレイ装置３００を介して出力するＩＰＴＶセットトップボックス２００とから構成される。
【００１３】
図１に示すように、ＩＰＴＶ放送サーバ１００は、格納されたビデオコンテンツ１０２やライブコンテンツ（ＴＶ放送プログラム；１０４）をインターネット１０を介して提供するためのストリーミングサーバ１１０と、ウェブサービスを提供するためのウェブサーバ１２０と、コンテンツを保護するためのユーザ接近制限及び著作権管理（ＣＡＳ／ＤＲＭ）サーバ１３０と、放送プログラムをガイドするためのＥＰＧ（Ｅｌｅｃｔｒｏｎｉｃ  Ｐｒｏｇｒａｍ  Ｇｕｉｄｅ）サーバ１４０と、加入者を管理するための加入者管理サーバ１５０と、課金のための課金サーバ１６０などとから構成される。ここで、「ＣＡＳ」とは、Ｃｏｎｄｉｔｉｏｎａｌ  Ａｃｃｅｓｓ  Ｓｙｓｔｅｍの略字であって、有料ＴＶシステムにおいて資格を有した加入者のみが該当チャネルを視聴できるようにするコンテンツセキュリティー技術であり、「ＤＲＭ」とは、Ｄｉｇｉｔａｌ  Ｒｉｇｈｔ  Ｍａｎａｇｅｍｅｎｔの略字であって、インターネット上でコンテンツの不法複製を防止するためのコンテンツ保護技術である。
ＩＰＴＶセットトップボックス２００は、インターネット１０を介してウェブサービスを利用するためのウェブブラウザと動画を再生するためのマルチメディア再生機とを搭載しており、ユーザのリモコン２０２操作によってテレビ放送を受信するか、又はウェブページを受信してディスプレイ装置３００に出力する。ディスプレイ装置３００は、通常のＣＲＴ、ＬＣＤ、ＰＤＰテレビ又はモニターである。
【００１４】
図２は、ライブコンテンツを送信するためのＩＰマルチキャスト網の構成例であり、図３は、マルチキャストに主に用いられるＵＤＰフォーマットの例であり、図４は、マルチキャストにおいて用いられるＩＧＭＰフォーマットの例であり、図５は、ＩＧＭＰによるチャネル設定手順の例である。
【００１５】
インターネット１０は、ルータにより接続するネットワークの組合体であって、一つのパケットが発信地（ｓｏｕｒｃｅ）から目的地（ｄｅｓｔｉｎａｔｉｏｎ）まで進むとき、ルーチングテーブルによって最適の経路を介して伝達される。インターネット１０において送信方式はＩＰｖ４方式の場合、ユニキャスト、マルチキャスト、ブロードキャストがあり、ＩＰｖ６方式では、Ａｎｙｃａｓｔ、ユニキャスト、マルチキャストがある。また、ルーチングは、単一発信地から他の単一目的地へ向かうユニキャストルーチングと、一つの発信地から他の目的地グループへ向かうマルチキャストルーチングとに区分される。通常、ＩＰＴＶにおいて生放送コンテンツは、マルチキャスト方式で送信され、格納されたコンテンツは、ユニキャスト方式で送信される。そして、マルチキャスト方式では、クラスＤアドレスを使用するが、非接続型のＵＤＰプロトコルが適し、ユニキャスト方式には接続型サービスであるＴＣＰプロトコルが適している。
【００１６】
ＩＰマルチキャスト網１０は、図２に示すように、セットトップボックス２００が接続するエッジルータ１４と高速でパケットをスイッチングするコアルータ１２とから具現されるが、ルータの間では、ＰＩＭ（Ｐｒｏｔｏｃｏｌ  Ｉｎｄｅｐｅｎｄｅｎｔ  Ｍｕｌｔｉｃａｓｔ）プロトコルが使用され、エッジルータ１４とセットトップボックス２００との間では、ＩＧＭＰ（Ｉｎｔｅｒｎｅｔ  Ｇｒｏｕｐ  Ｍａｎａｇｅｍｅｎｔ  Ｐｒｏｔｏｃｏｌ）プロトコルが使用される。ＩＧＭＰは、グループ管理プロトコルであり、ＩＧＭＰｖ２においてメッセージは、クエリメッセージ（ｑｕｅｒｙ  ｍｅｓｓａｇｅ）と会員報告（ｍｅｍｂｅｒｓｈｉｐ  ｒｅｐｏｒｔ）メッセージ、及び脱退報告（ｌｅａｖｅ  ｒｅｐｏｒｔ）メッセージがある。ＩＧＭＰｖ２メッセージ形式は、図４に示すように、８ビットのタイプ、８ビットの最大応答時間、１６ビットの検査和、３２ビットのグループアドレスからなる。
【００１７】
マルチキャストにおいてチャネルの変更は、図５に示すように、セットトップボックス２００が会員報告メッセージをエッジルータ１４に送信して新しいグループに参加することによって行われ、エッジルータ１４は、グループに参加した会員にオーディオとビデオストリームとを提供する。そして、セットトップボックス２００が脱退報告メッセージをエッジルータ１４に送信すると、グループ脱退が行われる。
【００１８】
このようなマルチキャストの送信層プロトコルには、非接続型、非信頼性プロトコルであるユーザデータグラムプロトコル（ＵＤＰ）が適しているが、ＵＤＰは、図３に示すように、８バイトのヘッダとデータとからなり、ヘッダは、１６ビットの発信地ポート番号と１６ビットの目的地ポート番号、１６ビットの長さ、１６ビットの検査和からなる。
【００１９】
図６は、本発明によってユニキャストにおいて主に用いられるＴＣＰセグメントの例であり、図７は、ユニキャストにおいて主に用いられるＲＴＳＰによるチャネル設定手順の例である。
【００２０】
ユニキャストでは、単一発信地と単一目的地とが存在し、プロセス間の伝達を担当する送信層には、ストリーム接続指向と信頼性とのあるプロトコルであるＴＣＰを使用する。ＴＣＰも送信層のアドレスとしてポート番号を使用し、送信及び受信プロセスは、全く同じ速度でデータを作り処理することができないので、格納のためにバッファを使用する。また、ＴＣＰは、セグメントというパケットで多数のバイトを縛ってグループ化し、エラー及び流れを制御するために順序番号と確認応答番号とを利用する。ＴＣＰセグメントの形式は、図６に示すように、２０〜６０バイトのヘッダとデータとからなり、ヘッダは、１６ビットの発信地ポートアドレスと１６ビットの目的地ポートアドレス、３２ビットの順序番号、３２ビットの確認応答番号、４ビットのヘッダ長、６ビットの制御ビートＵＲＧ、ＡＣＫ、ＰＳＨ、ＲＳＴ、ＳＹＮ、ＦＩＮ、１６ビットのウィンドウ大きさ、１６ビットの検査和、１６ビットの緊急指示子、オプション項目からなる。このようなＴＣＰは、全二重モードでデータを送信し、ＳＹＮ、ＳＹＮ＋ＡＣＫ、ＡＣＫからなる三方向ハンドシェークにより接続を設定する。
【００２１】
また、ＴＣＰストリーミング処理のためのＲＴＳＰ（Ｒｅａｌ−Ｔｉｍｅ  Ｓｔｒｅａｍｉｎｇ  Ｐｒｏｔｏｃｏｌ）は、図７に示すような手順を介してチャネルを変更する。図７に示すように、ＩＰＴＶセットトップボックス２００は、該当メタファイルを利用して「ＳＥＴ  ＵＰ」メッセージでストリーミングサーバ１１０に接続を設定した後、「ＲＥＳＰＯＮＳＥ」を受信すると、「ＰＬＡＹ」メッセージを送信してオーディオ／ビデオストリーミングを要請する。これにより、ストリーミングサーバ１１０は、該当オーディオ／ビデオストリーミングを提供してメディアプレーヤーが再生できるようにし、「ＴＥＡＲ  ＤＯＷＮ」メッセージを介して解除を要請すると、接続を終了する。
【００２２】
図８は、本発明によるＩＰＴＶ放送サービスにおけるトラフィック制御方法のフローチャートである。図８に示すように、本発明によるＩＰＴＶ放送サービスにおけるトラフィック制御過程について説明すると、以下のとおりである。
【００２３】
セットトップボックス２００が放送サーバ１００に接続して放送受信を要請すると、放送サーバ１００は、該当セットトップボックスがネットワークの状態に影響を受けずにコンテンツを安定してプレーできるバッファ量である目標バッファ量を設定する（Ｓ１１）。このとき、目標バッファ量は、ネットワーク不安定などで放送サーバ１００からのデータ送信量が減少しても、コンテンツを遅延無しでプレーできるようにセットトップボックス２００において予め確保可能なバッファ量であって、一種のコンテンツの安定的な再生を行うための最小限のバッファ量に該当する。例えば、該当セットトップボックス２００において最大限確保できるバッファ量を１００％とするとき、目標バッファ量として８０％又は９０％などと設定できる。目標バッファ量は、該当セットトップボックス２００において確保できる最大値１００％と設定できることはもちろんである。このような目標バッファ量は、セットトップボックス２００ごとに個別的に設定するか、又は放送サーバ１００に接続した全体セットトップボックスに対して一括的に同様に設定できる。また、各セットトップボックス２００が接続したネットワークの状態及び要請コンテンツなどを勘案して等級を分けて差別的に設定することもできる。一方、目標バッファ量は、ネットワークの種類及び状態、コンテンツを利用する時点（曜日及び時間等）などによって予め収集された統計データを利用して設定できる。このような統計データは、ネットワークの種類及び状態、そして、コンテンツを利用した曜日及び時間帯に応じて、セットトップボックスにおいてコンテンツを遅延無しでプレーするために確保すべきバッファ量に対する経験値により累積されたデータであって、好ましくは、放送サーバ１００により収集／算出及び管理されるようにする。この場合、放送サーバ１００は、放送サービスを提供する時点とネットワークの種類／状態を代入して、統計データから目標バッファ量を算出できるようになる。
【００２４】
放送サーバ１００は、ネットワークの状態をモニタリングした後、ネットワークと交渉してネットワークの許容する最大帯域幅（すなわち、トラフィック）でデータを送信する（Ｓ１２、Ｓ１３）。すなわち、放送サーバ１００は、ネットワークが許容する限度内で最大帯域幅でデータを最大限に送信することによって、セットトップボックス２００が目標バッファ量を確保することができるようにする。具体的に、放送サーバ１００が最大帯域幅でデータを最大量送信するので、セットトップボックス２００において放送サーバ１００から送信されるデータ（コンテンツ）を処理及びプレーしても、セットトップボックスの処理量より放送サーバのデータ送信量がより多く、これにより、一定時間が経過すると、セットボックスが目標バッファ量を確保できるようになる。一方、ステップＳ１３にて放送サーバ１００が最大帯域幅でデータを送信しなく、セットトップボックスにおいて処理及びプレーされる量以上のデータを送信するように構成することもできる。
【００２５】
放送サーバ１００は、セットトップボックス２００との交信を介してセットトップボックスの現在バッファ量が目標バッファ量に到達したか否かを確認する（Ｓ１４）。ステップＳ１４にてセットトップボックス２００の現在バッファ量は、放送サーバ１００の送信帯域幅と送信時間、そしてセットトップボックスのプレー時間などを考慮して、放送サーバが算出しうる。また、セットトップボックス２００が受信されたバッファ量を測定して、放送サーバ１００に知らせることもできる。
【００２６】
セットトップボックス２００の現在バッファ量が目標バッファ量に到達すると、もうこれ以上最大帯域幅でデータを送信する必要がなく、セットトップボックスにおいて処理及びプレーされる量だけデータを送信しても、セットトップボックスのバッファ量を目標バッファ量に維持できる。したがって、放送サーバ１００は、セットトップボックス２００のプレー速度に合せて送信帯域幅（すなわち、トラフィック）を調節し、セットトップボックスにおいて処理及びプレーされる量だけのデータを送信する（Ｓ１５）。従って、セットトップボックス２００では、プレーされる量だけデータを補充できるので、目標バッファ量を維持するようになる。一方、ステップＳ１５にてセットトップボックス２００のプレー速度は、放送サーバ１００がＥＰＧ（電子プログラムガイド）に含まれたコンテンツの再生時間などを考慮して算出できる。また、トリックプレーなどが行われることもできるので、放送サーバ１００は、セットトップボックス２００にプレー速度／量及び現在のバッファ量を要請して獲得することもできる。
【００２７】
以後、放送サーバ１００は、セットトップボックス２００のバッファ量を確認し続けてセットトップボックスの現在バッファ量が目標バッファ量以下に減少すると、再度ネットワークが許容する最大帯域幅でデータを送信して、セットトップボックスが目標バッファ量を維持し続けるようにする。このとき、放送サーバ１００は、一定周期（時間間隔）、例えば１０秒間隔でセットトップボックス２００のバッファ量を確認することができる。
したがって、ネットワークの状態が突然に劣悪になって放送サーバ１００のデータ送信量が顕著に減少しても、セットトップボックス２００は、既に放送サーバが設定した目標バッファ量分だけ十分にバッファリングしているので、コンテンツの遅延又は中断なしで安定してプレーできるようになる。また、以後にネットワークの状態が回復すると、放送サーバ１００が再度最大帯域幅でデータを送信して、セットボックス２００のバッファ量を目標バッファ量分だけ回復するので、ネットワークの状態に影響を受けずにセットトップボックスにおいてコンテンツを安定してプレーできるようになる。
【００２８】
以上、本発明を具体的な実施の形態を介して詳細に説明したが、本発明は、上述した実施の形態に限定されずに技術的思想が許容する範囲内で本発明の属する技術分野における通常の知識を有した者によって多様に変更されて実施されうる。
【符号の説明】
【００２９】
１０      インターネット
１２      コアルータ
１４      エッジルータ
１００      ＩＰＴＶ放送サーバ
１０２      格納コンテンツ
１０４      ライブコンテンツ
１１０      ストリーミングサーバ
１２０      ウェブサーバ
１３０      ＣＡＳ／ＤＲＭサーバ
１４０      ＥＰＧサーバ
１５０      加入者管理サーバ
１６０      課金サーバ
２００      ＩＰＴＶセットトップボックス
２０２      リモコン
３００      ディスプレイ装置
【図１】
2011501478.tif 000003
【図２】
2011501478.tif 000004
【図３】
2011501478.tif 000005
【図４】
2011501478.tif 000006
【図５】
2011501478.tif 000007
【図６】
2011501478.tif 000008
【図７】
2011501478.tif 000009
【図８】
2011501478.tif 000010
【図９】
2011501478.tif 000011
【国際調査報告】
2011501478.tif 000012
2011501478.tif 000013