JP2011182061A - 通信端末およびデータ配信方式切り替えプログラム - Google Patents
通信端末およびデータ配信方式切り替えプログラム Download PDFInfo
- Publication number
- JP2011182061A JP2011182061A JP2010042260A JP2010042260A JP2011182061A JP 2011182061 A JP2011182061 A JP 2011182061A JP 2010042260 A JP2010042260 A JP 2010042260A JP 2010042260 A JP2010042260 A JP 2010042260A JP 2011182061 A JP2011182061 A JP 2011182061A
- Authority
- JP
- Japan
- Prior art keywords
- program data
- distribution
- communication terminal
- delivery
- switching
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Landscapes
- Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
- Information Transfer Between Computers (AREA)
Abstract
【課題】バッファに蓄積される番組データ量の低減を抑制するとともに、回線帯域の利用効率を高めることが可能なP2Pの通信端末を提供する。
【解決手段】通信端末1は、端末間の受信状態を計測する受信状態計測手段26と、受信状態に基づいて番組データの配信元との配信方式をプル型またはプッシュ型の配信方式のいずれかに切り替える判定を行う切替判定手段271と、配信方式の切り替えを番組データの配信元に要求する切替要求手段272と、配信元の通信端末との配信方式で番組データを取得する番組データ取得手段25と、番組データの配信先である他の通信端末から配信方式の切り替えの要求を受け付け、要求のあった他の通信端末への番組データの配信形式を切り替える切替要求受付手段243と、配信先の通信端末との配信方式で番組データを配信する番組データ配信手段24と、を備えることを特徴とする。
【選択図】図3
【解決手段】通信端末1は、端末間の受信状態を計測する受信状態計測手段26と、受信状態に基づいて番組データの配信元との配信方式をプル型またはプッシュ型の配信方式のいずれかに切り替える判定を行う切替判定手段271と、配信方式の切り替えを番組データの配信元に要求する切替要求手段272と、配信元の通信端末との配信方式で番組データを取得する番組データ取得手段25と、番組データの配信先である他の通信端末から配信方式の切り替えの要求を受け付け、要求のあった他の通信端末への番組データの配信形式を切り替える切替要求受付手段243と、配信先の通信端末との配信方式で番組データを配信する番組データ配信手段24と、を備えることを特徴とする。
【選択図】図3
Description
本発明は、P2P(ピア・ツー・ピア;Peer to Peer)ストリーミングによって番組コンテンツを配信するコンテンツ配信システムにおける通信端末およびデータ配信方式切り替えプログラムに関する。
近年、通信回線の大容量化に伴って、通信回線を介して、動画等の放送番組(番組コンテンツ)をストリーミングデータとして配信するコンテンツ配信が盛んに行われている。このような通信回線を介したコンテンツ配信では、コンテンツ配信サーバの負荷を軽減するため、P2Pストリーミング技術が用いられている(非特許文献1参照)。
ここで、P2Pストリーミングは、番組コンテンツを一定時間間隔(例えば、1秒)に分割した番組データを受信した端末が、アプリケーション層で接続関係を持つ端末に、自身が受信した番組データを送信することで、通信網を介した番組コンテンツの配信を実現するものである。なお、P2Pストリーミングでは、個々の端末(ピア)は、番組データを送信する側、受信する側といった役割が固定的に決まっておらず、状況に応じてその役割が変動する対等な関係にある。そこで、P2Pストリーミングでは、番組データを送信する際の端末をサーバピア、番組データを受信する際の端末をクライアントピアと呼ぶ。
この従来のP2Pストリーミングは、番組データの配信方式によって、プッシュ型配信とプル型配信に分類される(図17,図18参照)。
プッシュ型配信は、図17に示すようなツリー状の配信網を有し、ツリーに従って、下流の端末(ピア)1Bに番組コンテンツの最初の番組データから順次中継される形態である。このプッシュ型配信では、サーバピア(上流の端末1B)に受信された番組データは、クライアントピア(下流の端末1B)からの要求の有無に係わらず、即座にサーバピアからクライアントピアに送信される。このときクライアントピアは、1台のサーバピアから番組データを受信する。
プッシュ型配信は、図17に示すようなツリー状の配信網を有し、ツリーに従って、下流の端末(ピア)1Bに番組コンテンツの最初の番組データから順次中継される形態である。このプッシュ型配信では、サーバピア(上流の端末1B)に受信された番組データは、クライアントピア(下流の端末1B)からの要求の有無に係わらず、即座にサーバピアからクライアントピアに送信される。このときクライアントピアは、1台のサーバピアから番組データを受信する。
プル型配信は、図18に示すようなメッシュ状の配信網を有し、クライアントピア(任意の端末1B)が、複数のサーバピアから、自身が保持していない番組データを取得する形態である。このプル型配信では、クライアントピアは、サーバピアから、当該サーバピアが現在どの番組データを保持しているかを示す番組データ保持情報を取得し、自身が保持していない番組データをサーバピアに要求する。このときクライアントピアは、複数のサーバピアに対して、並列して番組データを要求する。
また、P2Pストリーミングにおいて、端末の接続関係を構築する技術が、種々提案されている。例えば、端末間の距離や登録済みの端末の処理負荷によって、距離が短い、あるいは、負荷が少ない端末を、接続先として決定する技術が開示されている(特許文献1参照)。また、例えば、端末のコネクション数(接続関係)が少ない端末にコネクションを構築したり、コネクション数が予め定めた最小コネクション数よりも少ない場合は、コネクションを再構築したりすることで、コネクション数の均等化や分断化防止を行う技術が開示されている(特許文献2参照)。
江崎浩 監修、"P2P(ピア・ツー・ピア)教科書"、インプレスR&D、2007年12月22日
前記したプッシュ型配信では、クライアントピアは、1台のサーバピアから番組データを受信するため、番組データを受信する際の平均伝送速度が番組コンテンツを視聴する際のビットレート以上のサーバピアと接続関係を構築しなければならない。もし、サーバピアとの間でこのビットレートが確保できなければ、クライアントピアのバッファに蓄積される番組データは、時間の経過とともに減少し、最終的には、バッファの番組データが枯渇し、番組コンテンツの再生が停止してしまうという問題がある。
また、前記したプル型配信では、サーバピアで受信した番組データは、サーバピアのバッファに蓄積され、クライアントピアからの要求に基づいてクライアントピアに送信される。このため、番組データがクライアントピアに受信されるまでの処理遅延が大きい。また、この遅延を補うため、クライアントピアは、平均伝送速度が番組コンテンツのビットレートを大きく上回る高速回線を持つ複数のサーバピアと接続関係を構築し、番組データを受信する必要がある。しかし、プル型配信では、複数のサーバピアから番組データを受信するため、高速回線を持つサーバピアの上り回線帯域の利用効率が悪いという問題がある。
また、前記した特許文献1や特許文献2に開示されている端末の接続関係を構築する技術は、端末間の接続関係を構築する時点において、処理負荷やコネクション数が最適な接続関係を構築するものである。しかし、インターネット等の通信回線は、通信品質が一定ではないため、接続関係を構築した段階において、最適化されていたとしても、番組データの受信を開始した以降において、その有効性が保障されないという問題がある。
本発明は、以上のような問題点に鑑みてなされたものであり、P2Pストリーミングによって番組コンテンツを配信する際に、バッファに蓄積される番組データのデータ量の低減を抑制するとともに、回線帯域の利用効率を高めることが可能なコンテンツ配信システムにおける通信端末およびデータ配信方式切り替えプログラムを提供することを課題とする。
本発明は、前記課題を解決するために創案されたものであり、まず、請求項1に記載の通信端末は、番組コンテンツを所定時間の番組データに分割して、前記番組データの送受信の接続関係が予め構築されている通信端末間で、逐次、バッファに分割された前記番組データを蓄積しながらP2Pストリーミングで配信する通信端末において、受信状態計測手段と、切替判定手段と、切替要求手段と、番組データ取得手段と、切替要求受付手段と、番組データ配信手段と、を備える構成とした。
かかる構成において、通信端末は、受信状態計測手段によって、番組データを取得する際の通信端末間の受信状態が良好であるか否かの指標となる1以上の受信指標値を計測する。この受信指標値は、例えば、番組データを取得する際のスループット等である。
そして、通信端末は、切替判定手段によって、番組データの配信元である他の通信端末(サーバピア)との配信方式を、プル型またはプッシュ型の配信方式のいずれかに切り替える判定を行う。この切替判定手段は、配信元からの配信方式がプル型配信のときに、受信指標値のすべてが予め定めた基準値を上回った場合に、受信状態が良好であると認定し、プッシュ型配信に配信方式を切り替える判定を行う。また、切替判定手段は、配信元からの配信方式がプッシュ型配信のときに、受信指標値の少なくとも1つが基準値を下回った場合に、受信状態が悪化したと認定し、プル型配信に配信方式を切り替える判定を行う。
そして、通信端末は、切替要求手段によって、切替判定手段で判定された配信方式への切り替えを、番組データの配信元である他の通信端末(サーバピア)に対して要求する。また、通信端末は、番組データ取得手段によって、配信元の通信端末との前記いずれかの配信方式により、当該配信元の通信端末から番組データを取得する。
これによって、通信端末は、クライアントピアとして機能する際に、受信状態に応じてサーバピアとの配信方式を切り替えて、サーバピアから番組データを取得する。
これによって、通信端末は、クライアントピアとして機能する際に、受信状態に応じてサーバピアとの配信方式を切り替えて、サーバピアから番組データを取得する。
また、通信端末は、切替要求受付手段によって、番組データの配信先である他の通信端末(クライアントピア)から前記いずれかの配信方式への切り替えの要求を受け付け、切り替えの要求があった他の通信端末への配信方式を他の配信方式に切り替える。そして、通信端末は、番組データ配信手段によって、配信先の通信端末(クライアントピア)との配信方式で当該配信先の通信端末に番組データを配信する。
これによって、通信端末は、サーバピアとして機能する際に、クライアントピアからの要求に応じて配信方式を切り替えて、クライアントピアに番組データを送信する。
これによって、通信端末は、サーバピアとして機能する際に、クライアントピアからの要求に応じて配信方式を切り替えて、クライアントピアに番組データを送信する。
また、請求項2に記載の通信端末は、請求項1に記載の通信端末において、前記受信状態計測手段が、スループット計測手段を備える構成とした。
かかる構成において、通信端末は、スループット計測手段によって、番組データを取得する際の単位時間あたりのデータ量であるスループットを、受信指標値の1つとして計測する。これによって、通信端末は、スループット値が予め定めた基準値よりを上回ったか否かを判定基準として、配信方式の切り替えを行うことができる。
また、請求項3に記載の通信端末は、請求項1または請求項2に記載の通信端末において、前記受信状態計測手段が、基準超過回数計測手段を備える構成とした。
かかる構成において、通信端末は、基準超過回数計測手段によって、番組データを取得する際の単位時間あたりのデータ量であるスループットが予め定めた基準値を連続して上回った回数を、受信指標値の1つとして計測する。これによって、通信端末は、スループットが予め定めた基準値を連続して上回った回数が予め定めた基準値を上回ったか否かを判定基準として、配信方式の切り替えを行うことができる。
また、請求項4に記載の通信端末は、請求項1から請求項3のいずれか一項に記載の通信端末において、前記受信状態計測手段が、累積データ量計測手段を備える構成とした。
かかる構成において、通信端末は、累積データ量計測手段によって、番組データを取得する際の単位時間あたりのデータ量であるスループットが予め定めた基準値を連続して上回った際の番組データの累積データ量を、受信指標値の1つとして計測する。これによって、通信端末は、スループットが予め定めた基準値を連続して上回った際の番組データの累積データ量が予め定めた基準値を上回ったか否かを判定基準として、配信方式の切り替えを行うことができる。
さらに、請求項5に記載の通信端末は、請求項1から請求項4のいずれか一項に記載の通信端末において、前記受信状態計測手段が、蓄積量計測手段を備える構成とした。
かかる構成において、通信端末は、蓄積量計測手段によって、バッファに蓄積されている番組データの蓄積量を、受信指標値の1つとして計測する。これによって、通信端末は、番組データの蓄積量が予め定めた基準値を上回ったか否かを判定基準として、配信方式の切り替えを行うことができる。
また、請求項6に記載の通信端末は、前記番組データ取得手段が、欠損データ検出手段と、欠損データ要求手段と、を備える構成とした。
かかる構成において、通信端末は、欠損データ検出手段によって、配信元からの配信方式がプッシュ型配信のときに、番組データに予め付与されているシーケンス番号によって、欠損した番組データを検出する。そして、通信端末は、欠損データ要求手段によって、欠損データ検出手段で検出した欠損した番組データを、予め接続関係にある他の配信元の通信端末に要求する。これによって、通信端末は、プッシュ型配信によって番組データを取得している場合であっても、番組データが欠落した場合、プル型配信によって、他の通信端末から番組データを取得することができる。
さらに、請求項7に記載のデータ配信方式切り替えプログラムは、番組コンテンツを所定時間の番組データに分割して、前記番組データの送受信の接続関係が予め構築されている通信端末間で、逐次、バッファに分割された前記番組データを蓄積しながらP2Pストリーミングで配信する通信端末において、通信端末間の受信状態に応じて前記番組データの配信方式をプル型配信またはプッシュ型配信に切り替えるために、前記通信端末のコンピュータを、受信状態計測手段、切替判定手段、切替要求手段、番組データ取得手段、切替要求受付手段、番組データ配信手段、として機能させる構成とした。
かかる構成において、データ配信方式切り替えプログラムは、受信状態計測手段によって、番組データを取得する際の通信端末間の受信状態が良好であるか否かの指標となる1以上の受信指標値を計測する。そして、当該プログラムは、切替判定手段によって、番組データの配信元である他の通信端末(サーバピア)との配信方式を、プル型またはプッシュ型の配信方式のいずれかに切り替える判定を行う。この切替判定手段は、配信元からの配信方式がプル型配信のときに、受信指標値のすべてが予め定めた基準値を上回った場合に、受信状態が良好であると認定し、プッシュ型配信に配信方式を切り替える判定を行う。また、切替判定手段は、配信元からの配信方式がプッシュ型配信のときに、受信指標値の少なくとも1つが基準値を下回った場合に、受信状態が悪化したと認定し、プル型配信に配信方式を切り替える判定を行う。
そして、当該プログラムは、切替要求手段によって、切替判定手段で判定された配信方式への切り替えを、番組データの配信元である他の通信端末(サーバピア)に対して要求する。また、当該プログラムは、番組データ取得手段によって、配信元の通信端末との前記いずれかの配信方式により、当該配信元の通信端末から番組データを取得する。
また、当該プログラムは、切替要求受付手段によって、番組データの配信先である他の通信端末(クライアントピア)から前記いずれかの配信方式への切り替えの要求を受け付け、切り替えの要求があった他の通信端末への配信方式を他の配信方式に切り替える。そして、当該プログラムは、番組データ配信手段によって、配信先の通信端末(クライアントピア)との配信方式で当該配信先の通信端末に番組データを配信する。
本発明は、以下に示す優れた効果を奏するものである。
請求項1,7に記載の発明によれば、番組データを取得する際の受信状態が基準値に対して良好であれば、プッシュ型配信で番組データを取得することができる。これによって、本発明に係る通信端末は、受信状態が良好であれば、プル型配信のように配信元に個々の番組データの要求を行う必要がないため、回線帯域の利用効率を高めることができる。
また、請求項1,7に記載の発明によれば、番組データを取得する際の受信状態が基準値に対して良好でなければ、プル型配信で番組データを取得することができる。これによって、本発明に係る通信端末は、受信状態が良好でなければ、プッシュ型配信のように1つの配信元からではなく複数の配信元から番組データを取得することができるため、バッファに蓄積される番組データのデータ量の低減を抑制することができる。
請求項1,7に記載の発明によれば、番組データを取得する際の受信状態が基準値に対して良好であれば、プッシュ型配信で番組データを取得することができる。これによって、本発明に係る通信端末は、受信状態が良好であれば、プル型配信のように配信元に個々の番組データの要求を行う必要がないため、回線帯域の利用効率を高めることができる。
また、請求項1,7に記載の発明によれば、番組データを取得する際の受信状態が基準値に対して良好でなければ、プル型配信で番組データを取得することができる。これによって、本発明に係る通信端末は、受信状態が良好でなければ、プッシュ型配信のように1つの配信元からではなく複数の配信元から番組データを取得することができるため、バッファに蓄積される番組データのデータ量の低減を抑制することができる。
請求項2に記載の発明によれば、番組データを取得する際のスループットによって受信状態を判定するため、通信回線の回線スピードに応じて、複雑な伝送手順を要しないプッシュ型配信によって効率的に上流端末から番組データを取得することができる。
請求項3に記載の発明によれば、スループットが基準値を連続して上回った回数によって受信状態が良好であるか否かを判定するため、通信回線の回線スピードが速い状態が継続していることを把握することができ、的確に配信方式を切り替えることができる。
請求項4に記載の発明によれば、スループットが基準値を連続して上回った際の番組データの累積データ量によって受信状態が良好であるか否かを判定するため、大量の番組データが配信される状態で、かつ、通信回線の回線スピードが速い状態が継続していることを把握することができ、的確に配信方式を切り替えることができる。
請求項5に記載の発明によれば、バッファに蓄積されている番組データの蓄積量によって受信状態が良好であるか否かを判定するため、バッファ内おける番組データの枯渇が発生しないように的確に配信方式を切り替えることができる。
請求項6に記載の発明によれば、プッシュ型配信によって番組データを取得している場合であっても、欠損した番組データを他の通信端末から取得することができるため、対障害性に優れている。
以下、本発明の実施形態について図面を参照して説明する。
[コンテンツ配信システムの概要]
まず、図1および図2を参照して、本発明の実施形態に係るコンテンツ配信システムの概要について説明する。
[コンテンツ配信システムの概要]
まず、図1および図2を参照して、本発明の実施形態に係るコンテンツ配信システムの概要について説明する。
コンテンツ配信システムSは、図1に示すように、コンテンツ配信サーバSvから、P2Pストリーミングによって、動画等の放送番組(以下、番組コンテンツという)を、ネットワーク(通信回線)Nを介して接続された複数のコンテンツ受信装置1に配信するものである。
コンテンツ配信サーバSvは、番組コンテンツを一定時間間隔(例えば、1秒)で分割した番組データを、アプリケーション層で接続関係を有するコンテンツ受信装置1に配信するものである。このコンテンツ配信サーバSvは、番組コンテンツを配信する事業者、例えば、放送局の設備として設置される。なお、番組コンテンツの配信時間等の編成情報は、予めコンテンツ受信装置1に配信されているものとする。
コンテンツ受信装置(通信端末)1は、コンテンツ配信サーバSvから配信される番組データを、番組データの送受信の接続関係が予め構築されているコンテンツ受信装置1間で、逐次、バッファに番組データを蓄積しながらP2Pストリーミングとして送受信するものである。すなわち、コンテンツ受信装置1は、番組データを受信するクライアントピアとしての機能と、番組データを送信するサーバピアとしての機能とを有している。なお、以下の説明において、コンテンツ受信装置1を、番組データの受信側として説明する場合はクライアントピア、番組データの送信側として説明する場合はサーバピアと呼称する場合がある。このコンテンツ受信装置1は、番組コンテンツを視聴する視聴者の宅内に設置される。
なお、コンテンツ受信装置1は、番組コンテンツが配信される時刻等を示す編成情報や、同一の番組コンテンツを受信する他のコンテンツ受信装置1の情報(端末ID等)を、管理サーバ(図示せず)等から、予め取得しているものとする。
このように構成されたコンテンツ配信システムSは、図2に示すように、個々のコンテンツ受信装置1において、P2Pにおけるプル型配信およびプッシュ型配信のいずれかに適宜配信方式を切り替えて番組データを配信する。
ここでは、コンテンツ配信システムSは、基本的には、プル型配信によって番組データを配信する。しかし、コンテンツ配信システムSは、コンテンツ受信装置1間のネットワークの通信品質が良好(例えば、スループットが予め定めた基準値より高い)である場合、当該区間においてはプッシュ型配信によって番組データを配信する。
ここでは、コンテンツ配信システムSは、基本的には、プル型配信によって番組データを配信する。しかし、コンテンツ配信システムSは、コンテンツ受信装置1間のネットワークの通信品質が良好(例えば、スループットが予め定めた基準値より高い)である場合、当該区間においてはプッシュ型配信によって番組データを配信する。
すなわち、コンテンツ配信システムSは、ネットワークの通信品質に応じて、適宜コンテンツ受信装置1間の番組データの配信を、プル型配信からプッシュ型配信、あるいは、プッシュ型配信からプル型配信に切り替えることで、プル型配信およびプッシュ型配信の利点を併せ持った配信方式を実現するものである。
以下、コンテンツ受信装置1の構成および動作について説明を行う。
以下、コンテンツ受信装置1の構成および動作について説明を行う。
[コンテンツ受信装置の構成]
最初に、図3を参照して、本発明の実施形態に係るコンテンツ受信装置1の構成について説明を行う。ここでは、コンテンツ受信装置(通信端末)1は、記憶部10と、P2P制御部20と、送受信部30と、を備えている。
なお、図3では、番組コンテンツ(番組データ)を受信(または送信)するために必要な構成を示し、それ以外の構成、例えば、番組コンテンツを再生する再生手段等については、一般的なものであるため、図示を省略している。
最初に、図3を参照して、本発明の実施形態に係るコンテンツ受信装置1の構成について説明を行う。ここでは、コンテンツ受信装置(通信端末)1は、記憶部10と、P2P制御部20と、送受信部30と、を備えている。
なお、図3では、番組コンテンツ(番組データ)を受信(または送信)するために必要な構成を示し、それ以外の構成、例えば、番組コンテンツを再生する再生手段等については、一般的なものであるため、図示を省略している。
記憶部10は、コンテンツ受信装置(通信端末)1において必要となる各種情報や、配信された番組データ等を一時的に記憶するものである。ここでは、記憶部10は、端末情報記憶手段11と、バッファ12と、を備えている。
端末情報記憶手段(端末識別情報記憶手段、端末接続関係情報記憶手段)11は、同じ番組コンテンツを視聴するコンテンツ受信装置1(コンテンツ配信サーバを含む)から、番組データを受信するために必要な端末情報を記憶するものである。この端末情報記憶手段11は、半導体メモリ等の一般的な記憶媒体である。また、端末情報は、他のコンテンツ受信装置1を特定するための端末識別情報、現在の他のコンテンツ受信装置1との接続関係を示す端末接続関係情報を含んでいる。
ここで、図4を参照して、端末情報記憶手段11に記憶される情報の内容について説明する。図4(a)は、他のコンテンツ受信装置1を特定するための情報である端末識別情報のデータ構造の一例である。ここで、「端末ID」は、端末固有に予め定められた識別子である。また、「IPアドレス」は、当該端末のネットワークアドレスである。また、「ポート番号」は、P2Pのアプリケーションを識別するための番号である。
この端末識別情報は、同じ時間帯に同じ番組コンテンツを受信するコンテンツ受信装置1の情報を示し、複数のコンテンツ受信装置1の情報が記述されている。この端末識別情報は、番組コンテンツの配信先を管理する管理サーバ(図示せず)から予め取得したものが記憶されているものとする。
この端末識別情報は、同じ時間帯に同じ番組コンテンツを受信するコンテンツ受信装置1の情報を示し、複数のコンテンツ受信装置1の情報が記述されている。この端末識別情報は、番組コンテンツの配信先を管理する管理サーバ(図示せず)から予め取得したものが記憶されているものとする。
図4(b)は、他のコンテンツ受信装置1との接続関係を示す端末接続関係情報のデータ構造の一例である。ここで、「端末ID」は、図4(a)と同様、端末固有に予め定められた識別子である。また、「接続関係」は、他のコンテンツ受信装置1との間で接続関係があるか否かを示す情報である。また、接続関係がある場合、その接続先が、サーバピアであるのか、クライアントピアであるのかを示している。また、「配信方式」は、接続関係にあるコンテンツ受信装置1との間で番組データを配信する方式が、プッシュ型であるのかプル型であるのかを示す情報である。
この端末接続関係情報は、後記する接続関係構築手段22によって設定される。
図3に戻って、コンテンツ受信装置1の構成について説明を続ける。
この端末接続関係情報は、後記する接続関係構築手段22によって設定される。
図3に戻って、コンテンツ受信装置1の構成について説明を続ける。
バッファ12は、サーバピアから受信した番組データを蓄積するものである。このバッファ12は、半導体メモリ等の一般的な記憶媒体である。
このバッファ12は、サーバピアから受信した番組コンテンツを分割した番組データを順次、番組データの順番を示すシーケンス番号とともに蓄積し、再生時間が過ぎた段階で先頭の番組データから順次削除するバッファである。このバッファ12には、当該コンテンツ受信装置1が、クライアントピアとの間でプル型配信を行っている場合、クライアントピアから要求される番組データを一時的に保持する。
このバッファ12は、サーバピアから受信した番組コンテンツを分割した番組データを順次、番組データの順番を示すシーケンス番号とともに蓄積し、再生時間が過ぎた段階で先頭の番組データから順次削除するバッファである。このバッファ12には、当該コンテンツ受信装置1が、クライアントピアとの間でプル型配信を行っている場合、クライアントピアから要求される番組データを一時的に保持する。
例えば、バッファ12には、図5に示すように、シーケンス番号(S1〜Sn)に対応付けて番組データ(D1〜DN)が記憶される。また、リングバッファとしての先頭位置も記憶される。このバッファ12は、図示を省略したバッファ更新手段によって、一定時間間隔で、先頭の番組データから順次削除され、先頭位置も更新されることとする。
また、バッファ12に未取得の番組データがある場合、シーケンス番号には、実在しないシーケンス番号(例えば、NULL)が設定されるものとする。もちろん、取得の有無を示すフラグを別途設けてもよい。
なお、ここでは、バッファ12を、リングバッファとする例で説明したが、リングバッファに限定する必要はなく、先頭の番組を削除した段階で、順次後続の番組データをシフトし、常にバッファ12の先頭アドレスから番組データを保持する形態であっても構わない。
また、バッファ12に未取得の番組データがある場合、シーケンス番号には、実在しないシーケンス番号(例えば、NULL)が設定されるものとする。もちろん、取得の有無を示すフラグを別途設けてもよい。
なお、ここでは、バッファ12を、リングバッファとする例で説明したが、リングバッファに限定する必要はなく、先頭の番組を削除した段階で、順次後続の番組データをシフトし、常にバッファ12の先頭アドレスから番組データを保持する形態であっても構わない。
P2P制御部20は、番組データを、サーバピアから取得し、クライアントピアに配信するP2Pストリーミングの制御を行うものである。ここでは、P2P制御部20は、ピア選択手段21と、接続関係構築手段22と、番組データ保持情報送信手段23と、番組データ配信手段24と、番組データ取得手段25と、受信状態計測手段26と、配信方式選択手段27と、を備えている。
ピア選択手段21は、端末情報記憶手段11に記憶されている端末識別情報を参照して、接続関係を構築する複数のコンテンツ受信装置(サーバピア)1を選択するものである。このサーバピアの選択手法は任意のものでよい。例えば、ランダムに予め定めた数のサーバピアを選択することとしてもよいし、端末情報記憶手段11に記憶されている端末識別情報のリストで先頭から予め定めた数だけ選択することとしてもよい。
このピア選択手段21は、選択した複数のサーバピアを特定する情報(例えば、端末ID、IPアドレス等)を、接続関係構築手段22に出力する。
このピア選択手段21は、選択した複数のサーバピアを特定する情報(例えば、端末ID、IPアドレス等)を、接続関係構築手段22に出力する。
接続関係構築手段22は、番組データを取得するサーバピアや、番組データを配信するクライアントピアとの接続関係を構築するものである。ここでは、接続関係構築手段22は、接続関係構築要求手段221と、接続関係構築要求受付手段222と、を備える。
接続関係構築要求手段221は、ピア選択手段21で選択されたコンテンツ受信装置1をサーバピアとし、自身をクライアントピアとする接続関係を構築するものである。この接続関係構築要求手段221は、ピア選択手段21で選択されたコンテンツ受信装置1に対して、サーバピアとして接続関係を構築する旨の要求を示す接続関係構築要求メッセージを、送受信部30を介して送信する。そして、接続関係構築要求手段221が接続関係を了承する旨の応答を示すOKメッセージを受信することで、接続関係が成立したことになる。
なお、接続関係構築要求手段221は、接続関係が成立したコンテンツ受信装置1をサーバピアとし、端末情報記憶手段11の端末接続関係情報(図4(b)参照)にその旨を設定する。また、この設定段階(初期段階)では、接続関係構築要求手段221は、端末接続関係情報(図4(b)参照)に、サーバピアとの配信方式をプル型に設定する。
接続関係構築要求受付手段222は、他のコンテンツ受信装置1をクライアントピアとし、自身をサーバピアとする接続関係を構築するものである。この接続関係構築要求受付手段222は、他のコンテンツ受信装置1から、接続関係構築要求メッセージを送受信部30を介して受信し、要求に応じる場合、OKメッセージを要求のあったコンテンツ受信装置1に送信する。そして、接続関係構築要求受付手段222は、接続関係構築要求メッセージを送信したコンテンツ受信装置1をクライアントピアとし、端末情報記憶手段11の端末接続関係情報(図4(b)参照)にその旨を設定する。また、この設定段階(初期段階)では、接続関係構築要求受付手段222は、端末接続関係情報(図4(b)参照)に、クライアントピアとの配信方式をプル型に設定する。
なお、接続関係構築要求受付手段222は、予め接続関係を構築できる上限数を設けている場合に、接続要求の数がその上限数に達した場合、接続関係を拒否する旨の応答であるRejectメッセージを、接続関係構築要求メッセージを送信したコンテンツ受信装置1に送信することとする。
これによって、接続関係構築手段22は、コンテンツ受信装置1へ番組データを配信するサーバピアと、コンテンツ受信装置1から番組データを配信するクライアントピアとの間で接続関係を構築することができる。
これによって、接続関係構築手段22は、コンテンツ受信装置1へ番組データを配信するサーバピアと、コンテンツ受信装置1から番組データを配信するクライアントピアとの間で接続関係を構築することができる。
番組データ保持情報送信手段23は、現在、コンテンツ受信装置1が、バッファ12にどの番組データを保持しているかを示す番組データ保持情報を生成し、クライアントピアにメッセージとして通知するものである。この番組データ保持情報送信手段23は、バッファ12に記憶されている個々の番組データの有無をフラグで示した番組データ保持情報を含んだメッセージ(番組データ保持情報メッセージ)を、予め定めた時間間隔(例えば、1秒間隔)で、端末情報記憶手段11の端末接続関係情報(図4(b)参照)を参照し、クライアントピアに送信する。
この番組データ保持情報送信手段23は、例えば、図6に示した形式で、番組データ保持情報メッセージを生成する。
図6に示した番組データ保持情報メッセージは、当該メッセージが番組データ保持情報メッセージであることを示す固有の識別子であるメッセージIDと、自身のコンテンツ受信装置1の識別子である端末IDと、番組データ保持情報とを含んでいる。
ここで、番組データ保持情報は、現在、バッファ12に記憶されている番組データの先頭のシーケンス番号と、後続するデータのデータ長(ビット長)と、先頭のシーケンス番号から順に、番組データを保持しているか否かを示すフラグ(保持していない場合“0”、保持している場合“1”)を含んでいる。
これによって、コンテンツ受信装置1は、クライアントピアに対して、現在保持している番組データを通知することができる。
図6に示した番組データ保持情報メッセージは、当該メッセージが番組データ保持情報メッセージであることを示す固有の識別子であるメッセージIDと、自身のコンテンツ受信装置1の識別子である端末IDと、番組データ保持情報とを含んでいる。
ここで、番組データ保持情報は、現在、バッファ12に記憶されている番組データの先頭のシーケンス番号と、後続するデータのデータ長(ビット長)と、先頭のシーケンス番号から順に、番組データを保持しているか否かを示すフラグ(保持していない場合“0”、保持している場合“1”)を含んでいる。
これによって、コンテンツ受信装置1は、クライアントピアに対して、現在保持している番組データを通知することができる。
番組データ配信手段24は、サーバピアから取得した番組データを、クライアントピアに配信するものである。ここでは、番組データ配信手段24は、番組データ送信手段241と、番組データ要求受付手段242と、を備えている。
番組データ送信手段241は、クライアントピアに対する配信方式に応じて、プル型配信またはプッシュ型配信によって、番組データを送受信部30を介してクライアントピアに送信するものである。
この番組データ送信手段241は、端末情報記憶手段11の端末接続関係情報(図4(b)参照)を参照し、クライアントピアとの配信方式がプッシュ型である場合、後記する番組データ取得手段25で番組データを取得した段階で、その番組データをクライアントピアに送信する。
この番組データ送信手段241は、端末情報記憶手段11の端末接続関係情報(図4(b)参照)を参照し、クライアントピアとの配信方式がプッシュ型である場合、後記する番組データ取得手段25で番組データを取得した段階で、その番組データをクライアントピアに送信する。
一方、クライアントピアとの配信方式がプル型である場合、番組データ送信手段241は、後記する番組データ要求受付手段242によって、クライアントピアから番組データの要求があった段階で、バッファ12から、要求のあった番組データを読み出してクライアントピアに送信する。
この番組データ送信手段241は、例えば、図7に示した形式で、番組データを送信するメッセージを生成し、クライアントピアに送信する。
図7に示した番組データメッセージは、当該メッセージが番組データメッセージであることを示す固有の識別子であるメッセージIDと、自身のコンテンツ受信装置1の識別子である端末IDと、番組データのシーケンス番号と、番組データのデータ長と、番組データ本体とを含んでいる。
図7に示した番組データメッセージは、当該メッセージが番組データメッセージであることを示す固有の識別子であるメッセージIDと、自身のコンテンツ受信装置1の識別子である端末IDと、番組データのシーケンス番号と、番組データのデータ長と、番組データ本体とを含んでいる。
番組データ要求受付手段242は、クライアントピアから番組データの要求(番組データ送信要求メッセージ)を受け付けるものである。この番組データ要求受付手段242は、要求のあった番組データのシーケンス番号を、番組データ送信手段241に通知する。
なお、番組データ送信要求メッセージは、例えば、図8に示した形式とする。
図8に示した番組データ送信要求メッセージは、当該メッセージが番組データ送信要求メッセージであることを示す固有の識別子であるメッセージIDと、番組データを要求したクライアントピアの識別子である端末IDと、番組データ要求情報とを含んでいる。
なお、番組データ送信要求メッセージは、例えば、図8に示した形式とする。
図8に示した番組データ送信要求メッセージは、当該メッセージが番組データ送信要求メッセージであることを示す固有の識別子であるメッセージIDと、番組データを要求したクライアントピアの識別子である端末IDと、番組データ要求情報とを含んでいる。
ここで、番組データ要求情報は、クライアントピアのバッファ12に記憶されている番組データの先頭のシーケンス番号と、後続するデータのデータ長(ビット長)と、先頭のシーケンス番号から順に、番組データを要求するか否かを示すフラグ(要求する番組データを“1”、要求しない番組データを“0”)を含んでいる。
番組データ取得手段25は、サーバピアから番組データを取得するものである。ここでは、番組データ取得手段25は、番組データ受信手段251と、番組データ要求手段252と、欠損データ検出手段253と、欠損データ要求手段254と、を備えている。
番組データ受信手段251は、サーバピアから送受信部30を介して番組データを受信するものである。この番組データ受信手段251は、受信した番組データのシーケンス番号に対応付けて、バッファ12に番組データを書き込み、保持する。なお、番組データ受信手段251は、例えば、図7に示した番組データメッセージによって、番組データを受信することとする。
また、番組データ受信手段251は、番組データを受信した際に、端末情報記憶手段11の端末接続関係情報(図4(b)参照)を参照し、プッシュ型の配信方式であるクライアントピアが存在する場合、受信した番組データを番組データ送信手段241に出力する。これによって、プッシュ型の配信方式であるクライアントピアには、遅延なく番組データが送信される。
番組データ要求手段252は、サーバピアに対して、番組データの送信を要求するものである。この番組データ要求手段252は、端末情報記憶手段11の端末接続関係情報(図4(b)参照)を参照し、サーバピアとの配信方式がプル型である場合、サーバピアから定期的に送信される番組データ保持情報メッセージ(図6参照)の番組データ保持情報と、バッファ12に記憶されている番組データとを比較し、サーバピアが保持し、かつ、バッファ12に記憶されていない番組データについて、サーバピアに要求する。
なお、サーバピアとの配信方式で1つでもプッシュ型が存在する場合は、そのサーバピアから連続して番組データが送信されてくるため、他のサーバピアに対して番組データの要求を行わないこととする。
なお、サーバピアとの配信方式で1つでもプッシュ型が存在する場合は、そのサーバピアから連続して番組データが送信されてくるため、他のサーバピアに対して番組データの要求を行わないこととする。
この番組データ要求手段252は、例えば、図8に示した形式の番組データ送信要求メッセージを生成し、サーバピアに送信する。すなわち、番組データ要求手段252は、バッファ12に記憶されている番組データの先頭のシーケンス番号と、当該シーケンス番号以降の番組データのうちで、サーバピアが保持し、バッファ12に保持されていない番組データについてのみ、番組データを要求するフラグを設定(“1”に設定)し、番組データ送信要求メッセージを生成する。
なお、番組データ要求手段252は、複数のサーバピアから番組データを取得する場合、個々のサーバピアに分散して、番組データを並行して要求することとし、その数だけ、番組データ送信要求メッセージを生成することとする。
なお、番組データ要求手段252は、複数のサーバピアから番組データを取得する場合、個々のサーバピアに分散して、番組データを並行して要求することとし、その数だけ、番組データ送信要求メッセージを生成することとする。
欠損データ検出手段253は、サーバピアから、プッシュ型配信によって番組データを受信している際に、番組データに付与されているシーケンス番号によって、欠損した番組データを検出するものである。すなわち、欠損データ検出手段253は、端末情報記憶手段11の端末接続関係情報(図4(b)参照)を参照し、サーバピアとの配信方式がプッシュ型である場合、未受信の番組データを、シーケンス番号の欠落によって検出する。
この欠損データ検出手段253は、検出した欠損分の番組データのシーケンス番号を欠損データ要求手段254に通知する。
この欠損データ検出手段253は、検出した欠損分の番組データのシーケンス番号を欠損データ要求手段254に通知する。
欠損データ要求手段254は、プッシュ型配信によって番組データを配信しているサーバピアに対して、欠損分の番組データを要求するものである。この欠損データ要求手段254は、欠損データ検出手段253から通知されたシーケンス番号の番組データを要求する旨の番組データ送信要求メッセージ(図8参照)を生成し、サーバピアに送信する。
これによって、サーバピアとの配信方式がプッシュ型であった場合でも、欠損した番組データを取得することができ、安定した番組データの配信が可能になる。
これによって、サーバピアとの配信方式がプッシュ型であった場合でも、欠損した番組データを取得することができ、安定した番組データの配信が可能になる。
受信状態計測手段26は、番組データを受信する際の端末間の受信状態が良好であるか否かの指標となる受信指標値を計測するものである。ここでは、受信状態計測手段26は、スループット計測手段261と、基準超過回数計測手段262と、累積データ量計測手段263と、蓄積量計測手段264と、を備えている。
スループット計測手段261は、番組データを受信する際の単位時間あたりのデータ量であるスループットを、受信指標値の1つとして計測するものである。このスループット計測手段261は、サーバピアの配信方式がプル型の場合に、番組データ要求手段252が番組データを要求した時刻と、番組データ受信手段251が番組データを受信し終わった時刻とを、図示を省略した計時手段により計時し、その時間内に受信した番組データのデータサイズに基づいて、スループットの値を計算する。
このスループット計測手段261は、計測したスループット値が予め定めた基準値を上回った場合に、その旨を配信方式選択手段27に通知する。このスループット値は、その値が大きいほど回線スピードが速く、サーバピアとの通信品質が良好であることを意味する。よって、このスループット値は、受信状態を知るための指標の1つとなる。
基準超過回数計測手段262は、番組データを受信する際の単位時間あたりのデータ量であるスループットが予め定めた基準値を連続して上回った回数(基準超過回数)を、受信指標値の1つとして計測するものである。この基準超過回数計測手段262は、サーバピアの配信方式がプル型の場合に、スループットが予め定めた基準値を連続して上回った回数を計測し、その回数が予め定めた回数(基準値)を上回った場合に、その旨を配信方式選択手段27に通知する。この基準超過回数は、その数が多いほど、通信回線の回線スピードが速い状態が継続し、サーバピアとの通信品質が安定していることを意味する。よって、この基準超過回数は、受信状態を知るための指標の1つとなる。
なお、基準超過回数計測手段262は、スループットを独自に計測してもよいし、スループット計測手段261が計測したスループットを利用することとしてもよい。
なお、基準超過回数計測手段262は、スループットを独自に計測してもよいし、スループット計測手段261が計測したスループットを利用することとしてもよい。
累積データ量計測手段263は、番組データを受信する際の単位時間あたりのデータ量であるスループットが予め定めた基準値を連続して上回った際の番組データの累積データ量を、受信指標値の1つとして計測するものである。この累積データ量計測手段263は、サーバピアの配信方式がプル型の場合に、スループットが予め定めた基準値を連続して上回った場合に、逐次、受信した番組データのデータ量を累積し、その累積データ量が予め定めた基準値を上回った場合に、その旨を配信方式選択手段27に通知する。この累積データ量は、そのデータ量が多いほど、大量の番組データが配信される状態で、かつ、通信回線の回線スピードが速い状態が継続し、サーバピアとの通信品質が安定していることを意味する。よって、この累積データ量は、受信状態を知るための指標の1つとなる。
なお、累積データ量計測手段263は、スループットを独自に計測してもよいし、スループット計測手段261が計測したスループットを利用することとしてもよい。
なお、累積データ量計測手段263は、スループットを独自に計測してもよいし、スループット計測手段261が計測したスループットを利用することとしてもよい。
以上説明したスループット計測手段261、基準超過回数計測手段262および累積データ量計測手段263における処理について、図10を参照(適宜図3参照)して具体的に説明する。
図10は、スループット計測手段261、基準超過回数計測手段262および累積データ量計測手段263がそれぞれ計測するデータを、番組データの受信時間に沿って記述したものである。
ここで、「番組データ送信要求時刻」は、番組データ要求手段252が番組データを要求した時刻を示す。「番組データ受信時刻」は、番組データ受信手段251が、要求した番組データを受信し終わった時刻を示す。「番組データサイズ」は、番組データ送信要求時刻と番組データ受信時刻との間に受信した番組データのデータサイズを示す。「番組データ受信所要時間」は、番組データを受信するために要した時間を示している。
ここで、「番組データ送信要求時刻」は、番組データ要求手段252が番組データを要求した時刻を示す。「番組データ受信時刻」は、番組データ受信手段251が、要求した番組データを受信し終わった時刻を示す。「番組データサイズ」は、番組データ送信要求時刻と番組データ受信時刻との間に受信した番組データのデータサイズを示す。「番組データ受信所要時間」は、番組データを受信するために要した時間を示している。
また、「スループット」は、スループット計測手段261が計測したスループットの値を示す。「基準超過回数」は、基準超過回数計測手段262が計測したスループットが基準値を連続して上回った回数を示す。「累積データ量」は、累積データ量計測手段263が計測したスループットが基準値を連続して上回った際の番組データのデータ量を示す。なお、「基準超過回数」および「累積データ量」は、初期値として“0”が設定されているものとする。
ここで、例えば、番組データを要求した時刻を“00(時):00(分):05(秒)”、番組データを受信し終わった時刻を“00:00:07”、番組データサイズを“3.5M(bit)”としたとき、番組データ受信所要時間は、“2秒”であるため、スループット計測手段261は、スループットを、「3.5M/2=1.75M」と計算する。
このとき、スループットの予め定めた基準値を“1.5M”とすると、スループットが“1.75M”であり基準値を上回っているため、基準超過回数計測手段262は、基準超過回数をインクリメントし“1”とする。また、累積データ量計測手段263は、スループットが基準値を上回っているため、番組データサイズを累積データ量に加算し“3.5M”とする。
以下、同様に、スループット計測手段261は、番組データの要求のたびに、スループットを計測する。また、基準超過回数計測手段262は、スループットが基準値を連続して超過するたびに、基準超過回数をインクリメンする。また、累積データ量計測手段263は、スループットが基準値を連続して超過するたびに、番組データサイズを累積データ量に加算する。
ここで、番組データ送信要求時刻“00:00:18”、番組データ受信時刻“00:00:22”において、スループットが、基準値を下回った“1.0M”であったとすると、基準超過回数計測手段262は、基準超過回数を初期値“0”とし、累積データ量計測手段263は、累積データ量を初期値“0”とする。
図3に戻って、コンテンツ受信装置1の構成について説明を続ける。
図3に戻って、コンテンツ受信装置1の構成について説明を続ける。
蓄積量計測手段264は、バッファ12に蓄積されている番組データの蓄積量を、受信指標値の1つとして計測するものである。この蓄積量計測手段264は、バッファ12に蓄積される番組データの蓄積量が予め定めた基準値を超過した場合に、あるいは、一旦基準値を超過した後、基準値を下回った場合に、その旨を配信方式選択手段27に通知する。この蓄積量計測手段264は、サーバピアの配信方式が、プル型およびプッシュ型のいずれにおいても計測を行うこととする。
このバッファ12に蓄積される番組データの蓄積量は、その量が多いほど、サーバピアから配信された番組データが多く、データが高速に通信可能であり、受信状態を知るための指標となる。
このように、受信状態計測手段26は、種々の受信指標値を計測し、基準値との比較結果を配信方式選択手段27に通知する。
このように、受信状態計測手段26は、種々の受信指標値を計測し、基準値との比較結果を配信方式選択手段27に通知する。
配信方式選択手段27は、サーバピアやクライアントピアとの配信方式を、プル型またはプッシュ型のいずれかに選択して切り替えるものである。ここでは、配信方式選択手段27は、切替判定手段271と、切替要求手段272と、切替要求受付手段273と、を備えている。
切替判定手段271は、受信状態計測手段26で計測された受信状態に基づいて、サーバピアとの配信方式を切り替えるか否か判定するものである。
ここでは、切替判定手段271は、端末情報記憶手段11の端末接続関係情報(図4(b)参照)を参照し、現在のサーバピアとの配信方式がプル型配信であり、以下の(1)〜(4)の条件を満たしたときに、サーバピアとの配信方式をプッシュ型配信に切り替える判定を行う。
ここでは、切替判定手段271は、端末情報記憶手段11の端末接続関係情報(図4(b)参照)を参照し、現在のサーバピアとの配信方式がプル型配信であり、以下の(1)〜(4)の条件を満たしたときに、サーバピアとの配信方式をプッシュ型配信に切り替える判定を行う。
(1)サーバピアから番組データを受信する際のスループットが基準値を超えた。すなわち、スループット計測手段261から、計測したスループット値が基準値を上回った旨の通知があった。
(2)スループットが連続して基準値を超えた回数が予め定めた基準値(基準回数)を超えた。すなわち、基準超過回数計測手段262から、スループットが基準値を連続して上回った回数が基準回数を上回った旨の通知があった。
(3)スループットが連続して基準値を超えた際の番組データの累積データ量が予め定めた基準値を超えた。すなわち、累積データ量計測手段263から、累積データ量が基準値を上回った旨の通知があった。
(4)バッファ12に蓄積される番組データの蓄積量が予め定めた基準値を超えた。すなわち、蓄積量計測手段264から、バッファ12の蓄積量が基準値を上回った旨の通知があった。
(2)スループットが連続して基準値を超えた回数が予め定めた基準値(基準回数)を超えた。すなわち、基準超過回数計測手段262から、スループットが基準値を連続して上回った回数が基準回数を上回った旨の通知があった。
(3)スループットが連続して基準値を超えた際の番組データの累積データ量が予め定めた基準値を超えた。すなわち、累積データ量計測手段263から、累積データ量が基準値を上回った旨の通知があった。
(4)バッファ12に蓄積される番組データの蓄積量が予め定めた基準値を超えた。すなわち、蓄積量計測手段264から、バッファ12の蓄積量が基準値を上回った旨の通知があった。
以上の条件を満たした場合、切替判定手段271は、サーバピアとの配信方式をプッシュ型配信に切り替える判定を行い、切替要求手段272にその旨を通知する。
また、切替判定手段271は、現在のサーバピアとの配信状態がプッシュ型配信である場合に、バッファ12に蓄積される番組データの蓄積量が予め定めた基準値を下回った場合に、サーバピアとの配信方式をプル型配信に切り替える判定を行う。すなわち、切替判定手段271は、サーバピアとの配信状態がプッシュ型配信であるときに、蓄積量計測手段264から、バッファ12の蓄積量が基準値を下回った旨の通知があった場合、プル型配信に切り替える判定を行い、その旨を切替要求手段272に通知する。また、このとき、切替判定手段271は、基準超過回数計測手段262に対して基準超過回数を初期化(“0”に設定)する旨の指示を行い、累積データ量計測手段263に対して累積データ量を初期化(“0”に設定)する旨の指示を行うこととする。
また、切替判定手段271は、現在のサーバピアとの配信状態がプッシュ型配信である場合に、バッファ12に蓄積される番組データの蓄積量が予め定めた基準値を下回った場合に、サーバピアとの配信方式をプル型配信に切り替える判定を行う。すなわち、切替判定手段271は、サーバピアとの配信状態がプッシュ型配信であるときに、蓄積量計測手段264から、バッファ12の蓄積量が基準値を下回った旨の通知があった場合、プル型配信に切り替える判定を行い、その旨を切替要求手段272に通知する。また、このとき、切替判定手段271は、基準超過回数計測手段262に対して基準超過回数を初期化(“0”に設定)する旨の指示を行い、累積データ量計測手段263に対して累積データ量を初期化(“0”に設定)する旨の指示を行うこととする。
切替要求手段272は、切替判定手段271から通知される配信方式の切り替え指示に基づいて、サーバピアとの間で配信方式の切り替えを行うものである。
この切替要求手段272は、切替判定手段271から、あるサーバピアに対してプッシュ型配信へ切り替える旨の指示があった場合、当該サーバピアに対して、番組データをプッシュ型で配信するように要求する。例えば、切替要求手段272は、図9に示した形式のプッシュ型配信要求メッセージによって、プッシュ型配信の要求を行う。この図9に示したプッシュ型配信要求メッセージのメッセージIDは、当該メッセージがプッシュ型配信要求メッセージであることを示す固有の識別子であり、端末IDは、プッシュ型で配信する旨の要求を行う自身(クライアントピア)の識別子である。
この切替要求手段272は、切替判定手段271から、あるサーバピアに対してプッシュ型配信へ切り替える旨の指示があった場合、当該サーバピアに対して、番組データをプッシュ型で配信するように要求する。例えば、切替要求手段272は、図9に示した形式のプッシュ型配信要求メッセージによって、プッシュ型配信の要求を行う。この図9に示したプッシュ型配信要求メッセージのメッセージIDは、当該メッセージがプッシュ型配信要求メッセージであることを示す固有の識別子であり、端末IDは、プッシュ型で配信する旨の要求を行う自身(クライアントピア)の識別子である。
また、切替要求手段272は、プッシュ型配信の要求を行ったサーバピア以外のサーバピアに対しては、他のサーバピアでプッシュ型配信を開始した旨の通知を行う。例えば、切替要求手段272は、図9に示した形式のプッシュ型配信開始メッセージによって、他のサーバピアによってプッシュ型配信を開始した旨の通知を行う。この図9に示したプッシュ型配信開始メッセージのメッセージIDは、当該メッセージがプッシュ型配信開始メッセージであることを示す固有の識別子であり、端末IDは、自身(クライアントピア)の識別子である。
一方、切替要求手段272は、切替判定手段271から、プル型配信へ切り替える旨の指示があった場合、プッシュ型配信を行っていたサーバピアに対して、プッシュ型配信を終了し、プル型配信に切り替えるように要求する。例えば、切替要求手段272は、図9に示した形式のプッシュ型配信終了メッセージによって、プル型配信への切り替えを要求する。この図9に示したプッシュ型配信終了メッセージのメッセージIDは、当該メッセージがプッシュ型配信終了メッセージであることを示す固有の識別子であり、端末IDは、プル型配信を要求する自身(クライアントピア)の識別子である。
また、切替要求手段272は、プル型配信の要求を行ったサーバピア以外のサーバピアに対しては、プル型配信を開始する旨の通知を行う。例えば、切替要求手段272は、図9に示した形式のプル型配信開始メッセージによって、プル型配信を開始する旨の通知を行う。この図9に示したプル型配信開始メッセージのメッセージIDは、当該メッセージがプル型配信開始メッセージであることを示す固有の識別子であり、端末IDは、自身(クライアントピア)の識別子である。
このように、切替要求手段272は、受信状態に応じて、サーバピアに対して、番組データをプッシュ型配信するのか、プル型配信するのかの切り替えを要求する。このとき、切替要求手段272は、配信方式の切り替えを要求した後、端末情報記憶手段11の配信方式(図4(b)参照)を更新することとする。
切替要求受付手段273は、クライアントピアから、配信方式の切り替えの要求(プッシュ型配信要求メッセージ、プッシュ型配信開始メッセージ、プッシュ型配信終了メッセージ、プル型配信開始メッセージ)を受け付けるものである。
この切替要求受付手段273は、クライアントピアから、プッシュ型配信要求メッセージを受信した場合、当該クライアントピアに対する配信方式をプッシュ型配信方式に切り替える。具体的には、切替要求受付手段273は、プッシュ型配信要求メッセージ(図9参照)を受信後、当該メッセージに記述されている端末IDに基づいて、図4(b)に示した端末情報記憶手段11の端末接続関係情報の配信方式を、プル型からプッシュ型に書き換える。これによって、番組データ送信手段241は、クライアントピアに、プッシュ型配信によって番組データを送信することになる。
また、切替要求受付手段273は、クライアントピアから、プッシュ型配信終了メッセージを受信した場合、当該クライアントピアに対する配信方式をプル型配信方式に切り替える。具体的には、切替要求受付手段273は、プッシュ型配信終了メッセージ(図9参照)を受信後、当該メッセージに記述されている端末IDに基づいて、図4(b)に示した端末情報記憶手段11の端末接続関係情報を配信方式を、プッシュ型からプル型に書き換える。これによって、番組データ送信手段241は、クライアントピアから番組データを要求された際に番組データを送信することになる。
なお、本実施形態において、他のサーバピアがプッシュ型配信に切り替わったことを示すプッシュ型配信開始メッセージや、他のサーバピアがプッシュ型からプル型に切り替わったことを示すプル型配信開始メッセージは、必ずしも必要ではない。しかし、これらのメッセージは、例えば、コンテンツ受信装置1が同じクライアントピアに番組データを配信している他のサーバピアの状態を管理するために使用することができる。例えば、他のサーバピアがプッシュ型で配信しているときに、当該コンテンツ受信装置1に同じクライアントピアから、プッシュ型配信の要求があった場合に、クライアントピアに2重に番組データが配信されることから、エラーメッセージを送信するといった処理も可能である。
送受信部30は、ネットワークNを介して、コンテンツ受信装置1間で、番組データや各種メッセージを送受信するものである。この送受信部30は、一般的な通信制御回路等によって実現することができる。
以上説明したようにコンテンツ受信装置1を構成することで、コンテンツ受信装置1は、P2Pストリーミングによって、番組コンテンツを番組データごとに逐次受信する形態において、受信状態に応じて、各コンテンツ受信装置1間の配信方式を、プル型配信からプッシュ型配信に切り替えたり、プッシュ型配信からプル型配信に切り替えたりすることができる。
以上説明したコンテンツ受信装置1は、図示を省略したCPUやメモリを搭載した一般的なコンピュータで実現することができる。このとき、コンテンツ受信装置1は、コンピュータを、前記した各手段として機能させるデータ配信方式切り替えプログラムによって動作する。
[コンテンツ受信装置の動作]
次に、図11〜図16を参照(構成については、適宜図3参照)して、本発明の実施形態に係るコンテンツ受信装置1の動作について説明を行う。ここでは、図11に示すように、番組データDを受信するクライアントピア1C(コンテンツ受信装置1)が、3台のサーバピア1S1,1S2,1S3(コンテンツ受信装置1)との間で接続関係を有し、番組データを受信する例で動作を説明することとする。
次に、図11〜図16を参照(構成については、適宜図3参照)して、本発明の実施形態に係るコンテンツ受信装置1の動作について説明を行う。ここでは、図11に示すように、番組データDを受信するクライアントピア1C(コンテンツ受信装置1)が、3台のサーバピア1S1,1S2,1S3(コンテンツ受信装置1)との間で接続関係を有し、番組データを受信する例で動作を説明することとする。
(P2Pストリーミング全体動作)
最初に、図12を参照(適宜、図3、図11参照)して、コンテンツ受信装置1におけるP2Pストリーミングの全体動作について説明する。
まず、クライアントピア1Cは、ピア選択手段21によって、端末情報記憶手段11に記憶されている端末識別情報を参照して、接続関係を構築する複数のサーバピア(ここでは、3台のサーバピア1S1,1S2,1S3)を選択する。そして、クライアントピア1Cは、接続関係構築要求手段221によって、サーバピアとして接続関係を構築する旨の要求を示す接続関係構築要求メッセージを、送受信部30を介して、サーバピア1S1,1S2,1S3に送信する(ステップS1)。
最初に、図12を参照(適宜、図3、図11参照)して、コンテンツ受信装置1におけるP2Pストリーミングの全体動作について説明する。
まず、クライアントピア1Cは、ピア選択手段21によって、端末情報記憶手段11に記憶されている端末識別情報を参照して、接続関係を構築する複数のサーバピア(ここでは、3台のサーバピア1S1,1S2,1S3)を選択する。そして、クライアントピア1Cは、接続関係構築要求手段221によって、サーバピアとして接続関係を構築する旨の要求を示す接続関係構築要求メッセージを、送受信部30を介して、サーバピア1S1,1S2,1S3に送信する(ステップS1)。
一方、サーバピア1S1,1S2,1S3は、接続関係構築手段22の接続関係構築要求受付手段222によって、接続関係構築要求メッセージを受信し、接続関係構築要求メッセージを送信したクライアントピア1Cとの接続関係を“クライアントピア”、配信方式を“プル型”として、端末情報記憶手段11の端末接続関係情報(図4(b)参照)に設定する(ステップS2)。
この後、クライアントピア1Cは、サーバピア1S1,1S2,1S3から、プル型配信によって、番組データを取得する(ステップS3;プル型配信処理)。なお、このステップS3の詳細な動作については、後で図13を参照して説明を行う。
そして、クライアントピア1Cは、受信状態計測手段26によって、受信状態を示す受信指標値を計測し、配信方式選択手段27の切替判定手段271によって、受信指標値に基づいて、配信方式をプッシュ型に切り替えるか否かの判定を行う(ステップS4)。なお、このステップS4の詳細な動作については、後で図16を参照して説明を行う。
そして、このステップS4において、プル型からプッシュ型に配信方式の切り替えを行う旨の判定があった場合(ステップS5でYes)、クライアントピア1Cは、ステップS6に動作を進める。一方、配信方式の切り替えを行わない(配信方式の維持)判定であった場合(ステップS5でNo)、クライアントピア1Cは、ステップS3に戻って、サーバピア1S1,1S2,1S3から、プル型配信によって番組データを取得する。
プル型からプッシュ型に配信方式の切り替えを行う旨の判定があった場合(ステップS5でYes)、クライアントピア1Cは、サーバピア1S1,1S2,1S3に対して、いずれかのサーバピア(ここでは、1S2とする)に対して、プル型からプッシュ型に配信方式を切り替える処理を行う(ステップS6;プッシュ型配信切り替え処理)。そして、クライアントピア1Cは、プッシュ型に切り替えられたサーバピア1S2から、プッシュ型配信によって番組データを取得する(ステップS7;プッシュ型配信処理)。なお、このステップS6およびS7の詳細な動作については、後で図14を参照して説明を行う。
そして、クライアントピア1Cは、受信状態計測手段26によって、受信状態を示す受信指標値を計測し、配信方式選択手段27の切替判定手段271によって、受信指標値に基づいて、配信方式をプル型に切り替えるか否かの判定を行う(ステップS8)。なお、このステップS8の詳細な動作については、後で図16を参照して説明を行う。
そして、このステップS8において、プッシュ型からプル型に配信方式の切り替えを行う旨の判定があった場合(ステップS9でYes)、クライアントピア1Cは、ステップS10に動作を進める。一方、配信方式の切り替えを行わない判定(配信方式の維持)であった場合(ステップS9でNo)、クライアントピア1Cは、ステップS7に戻って、サーバピア1S2から、プッシュ型配信によって番組データを取得する。
プッシュ型からプル型に配信方式の切り替えを行う旨の判定があった場合(ステップS9でYes)、クライアントピア1Cは、サーバピア1S1,1S2,1S3に対して、プル型の配信方式に切り替える処理を行う(ステップS10;プル型配信切り替え処理)。なお、このステップS10の詳細な動作については、後で図15を参照して説明を行う。
その後、クライアントピア1Cは、ステップS3に戻って、プル型配信によって、サーバピア1S1,1S2,1S3から番組データを取得する(ステップS3)。
その後、クライアントピア1Cは、ステップS3に戻って、プル型配信によって、サーバピア1S1,1S2,1S3から番組データを取得する(ステップS3)。
以上説明したように、クライアントピア1Cは、サーバピア1S1,1S2,1S3との間の番組データの受信状態に応じて、プル型配信またはプッシュ型配信のいずれかに配信方式を切り替えて番組データを取得する。
(プル型配信処理動作)
次に、図13を参照(適宜、図3、図11参照)して、コンテンツ受信装置1の番組データのプル型配信処理動作について説明する、なお、このプル型配信処理動作は、図12のステップS3の動作に相当する。
次に、図13を参照(適宜、図3、図11参照)して、コンテンツ受信装置1の番組データのプル型配信処理動作について説明する、なお、このプル型配信処理動作は、図12のステップS3の動作に相当する。
まず、サーバピア1S1,1S2,1S3は、番組データ保持情報送信手段23によって、バッファ12にどの番組データを保持しているかを示す番組データ保持情報P1,P2,P3を含んだ番組データ保持情報メッセージを生成し、定期的(例えば、1秒間隔)にクライアントピア1Cに送信する(ステップS31)。
一方、クライアントピア1Cは、番組データ取得手段25において番組データ保持情報メッセージを受信し(ステップS32)、番組データ要求手段252によって、番組データ保持情報と、バッファ12に記憶されている番組データとを比較し、サーバピア1S1,1S2,1S3が保持し、かつ、バッファ12に記憶されていない番組データについて、サーバピア1S1,1S2,1S3に要求(番組データ送信要求メッセージを送信)する(ステップS33)。
その後、サーバピア1S1,1S2,1S3は、番組データ要求受付手段242によって、クライアントピア1Cから番組データの要求(番組データ送信要求メッセージ)を受信し(ステップS34)、番組データ送信手段241によって、要求のあった番組データをバッファ12から読み出し、クライアントピア1Cに送信する(ステップS35)。
そして、クライアントピア1Cは、番組データ受信手段251によって、サーバピア1S1,1S2,1S3から番組データを受信する(ステップS36)。
このように、プル型配信においては、クライアントピア1Cは、複数のサーバピア1S1,1S2,1S3に番組データをそれぞれ要求し、取得する。
このように、プル型配信においては、クライアントピア1Cは、複数のサーバピア1S1,1S2,1S3に番組データをそれぞれ要求し、取得する。
(プッシュ型配信切り替え処理動作およびプッシュ型配信処理動作)
次に、図14を参照(適宜、図3、図11参照)して、コンテンツ受信装置1におけるプッシュ型に配信方式を切り替えるプッシュ型配信切り替え処理動作および番組データのプッシュ型配信処理動作について説明する、なお、このプッシュ型配信切り替え処理動作は、図12のステップS6の動作に相当し、プッシュ型配信処理動作は、図12のステップS7の動作に相当する。
次に、図14を参照(適宜、図3、図11参照)して、コンテンツ受信装置1におけるプッシュ型に配信方式を切り替えるプッシュ型配信切り替え処理動作および番組データのプッシュ型配信処理動作について説明する、なお、このプッシュ型配信切り替え処理動作は、図12のステップS6の動作に相当し、プッシュ型配信処理動作は、図12のステップS7の動作に相当する。
まず、プッシュ型配信切り替え処理動作(ステップS6)について説明する。
プル型からプッシュ型に配信方式の切り替えの判定がなされた後、クライアントピア1Cは、切替要求手段272によって、切替判定手段271から通知されるどのサーバピアとの間の配信方式を切り替えるかを示す切り替え指示に基づいて、指示のあったサーバピア(ここでは、サーバピア1S2とする)に対して、番組データをプッシュ型で配信する旨の要求(プッシュ型配信要求メッセージの送信)を行う(ステップS61)。
そして、サーバピア1S2は、切替要求受付手段273によって、クライアントピア1Cから、プッシュ型配信要求メッセージを受信する(ステップS62)。このとき、切替要求受付手段273は、当該メッセージに記述されている端末IDに基づいて、端末情報記憶手段11の端末接続関係情報の配信方式を、プル型からプッシュ型に書き換える。
プル型からプッシュ型に配信方式の切り替えの判定がなされた後、クライアントピア1Cは、切替要求手段272によって、切替判定手段271から通知されるどのサーバピアとの間の配信方式を切り替えるかを示す切り替え指示に基づいて、指示のあったサーバピア(ここでは、サーバピア1S2とする)に対して、番組データをプッシュ型で配信する旨の要求(プッシュ型配信要求メッセージの送信)を行う(ステップS61)。
そして、サーバピア1S2は、切替要求受付手段273によって、クライアントピア1Cから、プッシュ型配信要求メッセージを受信する(ステップS62)。このとき、切替要求受付手段273は、当該メッセージに記述されている端末IDに基づいて、端末情報記憶手段11の端末接続関係情報の配信方式を、プル型からプッシュ型に書き換える。
そして、クライアントピア1Cは、切替要求手段272によって、サーバピア1S2以外のサーバピア1S1,1S3に対して、サーバピア1S2でプッシュ型配信を開始した旨の通知(プッシュ型配信開始メッセージの送信)を行う(ステップS63)。
一方、サーバピア1S1,1S3は、切替要求受付手段273によって、クライアントピア1Cから、プッシュ型配信開始メッセージを受信する(ステップS64)。
これによって、クライアントピア1Cは、サーバピア1S2との間で、プッシュ型配信で番組データを受信する配信方式に移行したことになる。
一方、サーバピア1S1,1S3は、切替要求受付手段273によって、クライアントピア1Cから、プッシュ型配信開始メッセージを受信する(ステップS64)。
これによって、クライアントピア1Cは、サーバピア1S2との間で、プッシュ型配信で番組データを受信する配信方式に移行したことになる。
次に、プッシュ型配信処理動作(ステップS7)について説明する。
サーバピア1S2は、プッシュ型に配信方式が切り替わった後、番組データ送信手段241によって、番組データ取得手段25で番組データを取得した段階で、その番組データをクライアントピア1Cに送信する(ステップS71)。
サーバピア1S2は、プッシュ型に配信方式が切り替わった後、番組データ送信手段241によって、番組データ取得手段25で番組データを取得した段階で、その番組データをクライアントピア1Cに送信する(ステップS71)。
そして、クライアントピア1Cは、番組データ受信手段251によって、サーバピア1S2から番組データを受信する(ステップS72)。このように、プッシュ型配信に切り替わった後も、サーバピア1S1,1S2,1S3は、番組データ保持情報送信手段23によって、バッファ12にどの番組データを保持しているかを示す番組データ保持情報P1,P2,P3を含んだ番組データ保持情報メッセージを生成し、定期的(例えば、1秒間隔)にクライアントピア1Cに送信する(ステップS73)。
そして、クライアントピア1Cは、番組データ取得手段25において番組データ保持情報メッセージを受信する(ステップS74)。なお、クライアントピア1Cは、欠損データ検出手段253によって、未受信の番組データを、シーケンス番号の欠落によって検出し、欠損データ要求手段254によって、当該番組データを保持しているサーバピア1S1,1S3に欠損分の番組データを要求する(図示せず)。
このように、プッシュ型配信においては、サーバピア1S2は、クライアントピア1Cからの要求を待たずに番組データを配信する。
このように、プッシュ型配信においては、サーバピア1S2は、クライアントピア1Cからの要求を待たずに番組データを配信する。
なお、クライアントピア1Cは、ステップS72において、下流のピアとの配信方式がプッシュ型であれば、番組データ送信手段241によって、順次番組データを下流のピア送信する(図示せず)。また、下流のピアとの配信方式がプル型であれば、クライアントピア1Cは、バッファ12に番組データを蓄積し、番組データ配信手段24が、下流のピアから要求があった場合に、番組データを送信する(図示せず)。
(プル型配信切り替え処理動作)
次に、図15を参照(適宜、図3、図11参照)して、コンテンツ受信装置1におけるプル型に配信方式を切り替えるプル型配信切り替え処理動作について説明する、なお、このプル型配信切り替え処理動作は、図12のステップS10の動作に相当する。
次に、図15を参照(適宜、図3、図11参照)して、コンテンツ受信装置1におけるプル型に配信方式を切り替えるプル型配信切り替え処理動作について説明する、なお、このプル型配信切り替え処理動作は、図12のステップS10の動作に相当する。
クライアントピア1Cは、プッシュ型からプル型に配信方式の切り替えの判定がなされた後、切替要求手段272によって、切替判定手段271から通知されるどのサーバピアとの間の配信方式を切り替えるかを示す切り替え指示に基づいて、指示のあったサーバピア(ここでは、サーバピア1S2)に対して、プッシュ型の配信を終了する旨の要求(プッシュ型配信終了メッセージの送信)を行う(ステップS101)。
そして、サーバピア1S2は、切替要求受付手段273によって、クライアントピア1Cから、プッシュ型配信終了メッセージを受信する(ステップS102)。このとき、サーバピア1S2は、切替要求受付手段273によって、当該メッセージに記述されている端末IDに基づいて、端末情報記憶手段11の端末接続関係情報の配信方式(図4(b)参照)を、プッシュ型からプル型に書き換える。
続いて、クライアントピア1Cは、切替要求手段272によって、サーバピア1S2以外のサーバピア1S1,1S3に対して、サーバピア1S2でプッシュ型配信が終了し、プル型配信を開始した旨の通知(プル型配信開始メッセージの送信)を行う(ステップS103)。
そして、サーバピア1S1,1S3は、切替要求受付手段273によって、クライアントピア1Cから、プル型配信開始メッセージを受信する(ステップS104)。
以上の動作によって、クライアントピア1Cは、サーバピア1S1,1S2,1S3との間で、プル型配信で番組データを受信する配信方式に移行したことになる。
以上の動作によって、クライアントピア1Cは、サーバピア1S1,1S2,1S3との間で、プル型配信で番組データを受信する配信方式に移行したことになる。
(配信切り替え判定動作)
次に、図16を参照(適宜、図3、図11参照)して、コンテンツ受信装置1における配信方式の切り替え判定を行う配信切り替え判定動作について説明する、なお、この配信切り替え判定動作は、図12のステップS4,S8の動作に相当する。
次に、図16を参照(適宜、図3、図11参照)して、コンテンツ受信装置1における配信方式の切り替え判定を行う配信切り替え判定動作について説明する、なお、この配信切り替え判定動作は、図12のステップS4,S8の動作に相当する。
まず、クライアントピア1Cは、切替判定手段271によって、端末情報記憶手段11の端末接続関係情報(図4(b)参照)を参照し、サーバピア1S1,1S2,1S3との配信方式がすべてプル型配信であるか否かを判定する(ステップS41)。
そして、サーバピア1S1,1S2,1S3との配信方式がプル型配信である場合(ステップS41でYes)、クライアントピア1Cは、切替判定手段271によって、以下の手順で、プッシュ型に配信方式を切り替えるか否かを判定する。
すなわち、切替判定手段271は、スループット計測手段261の計測結果において、スループットが基準値を上回ったか否かを判定する(ステップS42)。
すなわち、切替判定手段271は、スループット計測手段261の計測結果において、スループットが基準値を上回ったか否かを判定する(ステップS42)。
そして、スループット値が基準値を上回った場合(ステップS42でYes)、切替判定手段271は、基準超過回数計測手段262の計測結果において、スループットが基準値を連続して上回った回数が基準回数を上回ったか否かを判定する(ステップS43)。
また、スループットが基準値を連続して上回った回数が基準回数を上回った場合(ステップS43でYes)、切替判定手段271は、累積データ量計測手段263の計測結果において、累積データ量が基準値を上回ったか否かを判定する(ステップS44)。
また、スループットが基準値を連続して上回った回数が基準回数を上回った場合(ステップS43でYes)、切替判定手段271は、累積データ量計測手段263の計測結果において、累積データ量が基準値を上回ったか否かを判定する(ステップS44)。
さらに、累積データ量が基準値を上回った場合(ステップS44でYes)、切替判定手段271は、蓄積量計測手段264の計測結果において、バッファ12の蓄積量が基準値を上回ったか否かを判定する(ステップS45)。
そして、バッファ12の蓄積量が基準値を上回った場合(ステップS45でYes)、切替判定手段271は、プル型からプッシュ型に配信方式を切り替える旨の判定を行う(ステップS46)。
そして、バッファ12の蓄積量が基準値を上回った場合(ステップS45でYes)、切替判定手段271は、プル型からプッシュ型に配信方式を切り替える旨の判定を行う(ステップS46)。
なお、ステップS42〜S45において、各測定結果が基準値に達していない場合(ステップS42〜S45の各ステップでNo)、切替判定手段271は、プル型を継続する旨の判定を行う(ステップS47)。
一方、サーバピア1S1,1S2,1S3といずれかの配信方式がプッシュ型配信である場合(ステップS41でNo)、クライアントピア1Cは、切替判定手段271によって、蓄積量計測手段264の計測結果において、バッファ12の蓄積量が基準値を下回った(回復した)か否かを判定する(ステップS48)。
そして、バッファ12の蓄積量が基準値を下回った場合(ステップS48でYes)、切替判定手段271は、プッシュ型からプル型に配信方式を切り替える旨の判定を行う(ステップS49)。一方、バッファ12の蓄積量が基準値を上回ったままの場合(ステップS48でNo)、切替判定手段271は、プッシュ型を継続する旨の判定を行う(ステップS50)。
以上の動作によって、クライアントピア1Cは、切替判定手段271によって、サーバピア1S1,1S2,1S3との番組データの受信状態(通信品質)に応じて、プル型およびプッシュ型のいずれかに配信方式を切り替えるか否かを判定することができる。
以上説明したように、本発明の実施形態に係るコンテンツ受信装置1は、番組データの受信状態に応じて、適応的にプル型およびプッシュ型のいずれかに配信方式を切り替えることができ、プル型およびプッシュ型の利点を同時に活用し、安定かつ効率的なP2Pストリーミングを実現することができる。
以上、本発明の実施形態に係るコンテンツ受信装置1の構成および動作について説明したが、本発明は、この実施形態に限定されるものではない。
例えば、本実施形態では、スループット計測手段261、基準超過回数計測手段262、累積データ量計測手段263および蓄積量計測手段264の4つ手段によって受信状態を計測し、その計測結果を配信方式の切り替え判定に用いたが、これらの構成は、少なくとも1つあればよい。
例えば、本実施形態では、スループット計測手段261、基準超過回数計測手段262、累積データ量計測手段263および蓄積量計測手段264の4つ手段によって受信状態を計測し、その計測結果を配信方式の切り替え判定に用いたが、これらの構成は、少なくとも1つあればよい。
また、ここでは、切替判定手段271が、プッシュ型からプル型に配信方式を切り替える条件を、受信指標値の1つであるバッファ12の蓄積量が基準値を下回ったことのみで判定したが、各受信指標値の少なくとも1つが基準値を下回ったことで、プル型に配信方式を切り替えることとしてもよい。例えば、プッシュ型からプル型に配信方式を切り替える条件を、スループットが基準値を下回ったことのみを条件としてもよい。あるいは、バッファ12の蓄積量およびスループットがともに基準値を下回ったことを条件としてもよい。
1 コンテンツ受信装置(通信端末、サーバピア、クライアントピア)
10 記憶部
11 端末情報記憶手段(端末識別情報記憶手段、端末接続関係情報記憶手段)
12 バッファ
20 P2P制御部
21 ピア選択手段
22 接続関係構築手段
221 接続関係構築要求手段
222 接続関係構築要求受付手段
23 番組データ保持情報送信手段
24 番組データ配信手段
241 番組データ送信手段
242 番組データ要求受付手段
25 番組データ取得手段
251 番組データ受信手段
252 番組データ要求手段
253 欠損データ検出手段
254 欠損データ要求手段
26 受信状態計測手段
261 スループット計測手段
262 基準超過回数計測手段
263 累積データ量計測手段
264 蓄積量計測手段
27 配信方式選択手段
271 切替判定手段
272 切替要求手段
273 切替要求受付手段
30 送受信部
10 記憶部
11 端末情報記憶手段(端末識別情報記憶手段、端末接続関係情報記憶手段)
12 バッファ
20 P2P制御部
21 ピア選択手段
22 接続関係構築手段
221 接続関係構築要求手段
222 接続関係構築要求受付手段
23 番組データ保持情報送信手段
24 番組データ配信手段
241 番組データ送信手段
242 番組データ要求受付手段
25 番組データ取得手段
251 番組データ受信手段
252 番組データ要求手段
253 欠損データ検出手段
254 欠損データ要求手段
26 受信状態計測手段
261 スループット計測手段
262 基準超過回数計測手段
263 累積データ量計測手段
264 蓄積量計測手段
27 配信方式選択手段
271 切替判定手段
272 切替要求手段
273 切替要求受付手段
30 送受信部
Claims (7)
- 番組コンテンツを所定時間の番組データに分割して、前記番組データの送受信の接続関係が予め構築されている通信端末間で、逐次、バッファに分割された前記番組データを蓄積しながらP2Pストリーミングで配信する通信端末において、
前記番組データを取得する際の通信端末間の受信状態が良好であるか否かの指標となる1以上の受信指標値を計測する受信状態計測手段と、
この受信状態計測手段で計測した受信指標値に基づいて、前記番組データの配信元である他の通信端末との配信方式を、プル型またはプッシュ型の配信方式のいずれかに切り替える判定を行う切替判定手段と、
この切替判定手段で判定された配信方式への切り替えを、前記番組データの配信元である他の通信端末に対して要求する切替要求手段と、
配信元の通信端末との前記いずれかの配信方式により、当該配信元の通信端末から前記番組データを取得する番組データ取得手段と、
前記番組データの配信先である他の通信端末から前記いずれかの配信方式への切り替えの要求を受け付け、切り替えの要求があった他の通信端末への配信方式を他の配信方式に切り替える切替要求受付手段と、
配信先の通信端末との前記いずれかの配信方式により、当該配信先の通信端末に前記番組データを配信する番組データ配信手段と、を備え、
前記切替判定手段は、
前記配信元からの配信方式がプル型配信のときには、前記受信指標値のすべてが予め定めた基準値を上回った場合に、配信方式をプッシュ型配信に切り替える判定を行い、
前記配信元からの配信方式がプッシュ型配信のときには、前記受信指標値の少なくとも1つが前記基準値を下回った場合に、配信方式をプル型配信に切り替える判定を行うことを特徴とする通信端末。 - 前記受信状態計測手段は、
前記番組データを取得する際の単位時間あたりのデータ量であるスループットを、前記受信指標値の1つとして計測するスループット計測手段を備えること、
を特徴とする請求項1に記載の通信端末。 - 前記受信状態計測手段は、
前記番組データを取得する際の単位時間あたりのデータ量であるスループットが予め定めた基準値を連続して上回った回数を、前記受信指標値の1つとして計測する基準超過回数計測手段を備えること、
を特徴とする請求項1または請求項2に記載の通信端末。 - 前記受信状態計測手段は、
前記番組データを取得する際の単位時間あたりのデータ量であるスループットが予め定めた基準値を連続して上回った際の前記番組データの累積データ量を、前記受信指標値の1つとして計測する累積データ量計測手段を備えること、
を特徴とする請求項1から請求項3のいずれか一項に記載の通信端末。 - 前記受信状態計測手段は、
前記バッファに蓄積されている番組データの蓄積量を、前記受信指標値の1つとして計測する蓄積量計測手段を備えること、
を特徴とする請求項1から請求項4のいずれか一項に記載の通信端末。 - 前記番組データ取得手段は、
前記配信元からの配信方式がプッシュ型配信のときに、前記番組データに予め付与されているシーケンス番号によって、欠損した番組データを検出する欠損データ検出手段と、
この欠損データ検出手段で検出した欠損した番組データを、予め接続関係にある他の配信元の通信端末に要求する欠損データ要求手段と、
を備えることを特徴とする請求項1から請求項5のいずれか一項に記載の通信端末。 - 番組コンテンツを所定時間の番組データに分割して、前記番組データの送受信の接続関係が予め構築されている通信端末間で、逐次、バッファに分割された前記番組データを蓄積しながらP2Pストリーミングで配信する通信端末において、通信端末間の受信状態に応じて前記番組データの配信方式をプル型配信またはプッシュ型配信に切り替えるために、前記通信端末のコンピュータを、
前記番組データを取得する際の通信端末間の受信状態が良好であるか否かの指標となる1以上の受信指標値を計測する受信状態計測手段、
この受信状態計測手段で計測した受信指標値に基づいて、前記番組データの配信元である他の通信端末との配信方式を、プル型またはプッシュ型の配信方式のいずれかに切り替える判定を行う切替判定手段、
この切替判定手段で判定された配信方式への切り替えを、前記番組データの配信元である他の通信端末に対して要求する切替要求手段、
配信元の通信端末との前記いずれかの配信方式により、当該配信元の通信端末から前記番組データを取得する番組データ取得手段、
前記番組データの配信先である他の通信端末から前記いずれかの配信方式への切り替えの要求を受け付け、切り替えの要求があった他の通信端末への配信方式を他の配信方式に切り替える切替要求受付手段、
配信先の通信端末との前記いずれかの配信方式により、当該配信先の通信端末に前記番組データを配信する番組データ配信手段、として機能させ、
前記切替判定手段は、
前記配信元からの配信方式がプル型配信のときには、前記受信指標値のすべてが予め定めた基準値を上回った場合に、配信方式をプッシュ型配信に切り替える判定を行い、
前記配信元からの配信方式がプッシュ型配信のときには、前記受信指標値の少なくとも1つが前記基準値を下回った場合に、配信方式をプル型配信に切り替える判定を行うことを特徴とするデータ配信方式切り替えプログラム。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2010042260A JP2011182061A (ja) | 2010-02-26 | 2010-02-26 | 通信端末およびデータ配信方式切り替えプログラム |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2010042260A JP2011182061A (ja) | 2010-02-26 | 2010-02-26 | 通信端末およびデータ配信方式切り替えプログラム |
Publications (1)
Publication Number | Publication Date |
---|---|
JP2011182061A true JP2011182061A (ja) | 2011-09-15 |
Family
ID=44693141
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2010042260A Pending JP2011182061A (ja) | 2010-02-26 | 2010-02-26 | 通信端末およびデータ配信方式切り替えプログラム |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP2011182061A (ja) |
Cited By (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2013187638A (ja) * | 2012-03-06 | 2013-09-19 | Nippon Hoso Kyokai <Nhk> | P2pネットワークサービスに用いる端末装置及びプログラム |
JP2013186583A (ja) * | 2012-03-06 | 2013-09-19 | Nippon Hoso Kyokai <Nhk> | P2pネットワークサービスに用いる端末装置、通信システム及びプログラム |
JP2015216498A (ja) * | 2014-05-09 | 2015-12-03 | Kddi株式会社 | コンテンツ配信ネットワークの通信装置、クライアント装置及びプログラム |
JP2018516500A (ja) * | 2015-04-17 | 2018-06-21 | テレフオンアクチーボラゲット エルエム エリクソン(パブル) | 動的パッケージャネットワークベースのabrメディア配布および配信 |
Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2008084096A1 (en) * | 2007-01-12 | 2008-07-17 | Thomson Licensing | System and method for combining pull and push modes |
JP2009134676A (ja) * | 2006-12-15 | 2009-06-18 | Sanyo Electric Co Ltd | コンテンツ通信方法ならびにそれを利用したコンテンツ送信装置およびコンテンツ受信装置 |
JP2009211158A (ja) * | 2008-02-29 | 2009-09-17 | Brother Ind Ltd | コンテンツ再生装置及びそのプログラム、コンテンツ配信システム、コンテンツ配信方法 |
JP2011008709A (ja) * | 2009-06-29 | 2011-01-13 | Brother Industries Ltd | 情報処理装置、コンテンツ配信システム、コンテンツ配信制御方法及びプログラム |
-
2010
- 2010-02-26 JP JP2010042260A patent/JP2011182061A/ja active Pending
Patent Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2009134676A (ja) * | 2006-12-15 | 2009-06-18 | Sanyo Electric Co Ltd | コンテンツ通信方法ならびにそれを利用したコンテンツ送信装置およびコンテンツ受信装置 |
WO2008084096A1 (en) * | 2007-01-12 | 2008-07-17 | Thomson Licensing | System and method for combining pull and push modes |
JP2009211158A (ja) * | 2008-02-29 | 2009-09-17 | Brother Ind Ltd | コンテンツ再生装置及びそのプログラム、コンテンツ配信システム、コンテンツ配信方法 |
JP2011008709A (ja) * | 2009-06-29 | 2011-01-13 | Brother Industries Ltd | 情報処理装置、コンテンツ配信システム、コンテンツ配信制御方法及びプログラム |
Cited By (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2013187638A (ja) * | 2012-03-06 | 2013-09-19 | Nippon Hoso Kyokai <Nhk> | P2pネットワークサービスに用いる端末装置及びプログラム |
JP2013186583A (ja) * | 2012-03-06 | 2013-09-19 | Nippon Hoso Kyokai <Nhk> | P2pネットワークサービスに用いる端末装置、通信システム及びプログラム |
JP2015216498A (ja) * | 2014-05-09 | 2015-12-03 | Kddi株式会社 | コンテンツ配信ネットワークの通信装置、クライアント装置及びプログラム |
JP2018516500A (ja) * | 2015-04-17 | 2018-06-21 | テレフオンアクチーボラゲット エルエム エリクソン(パブル) | 動的パッケージャネットワークベースのabrメディア配布および配信 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN104137505B (zh) | 实现对分段内容流式传输的网络发起的控制的方法和装置 | |
US8059560B2 (en) | Tree-type network system, node device, broadcast system, broadcast method, and the like | |
KR100813972B1 (ko) | 컨텐츠 스트리밍 클라이언트 장치 및 방법, 그 방법을수행하는 프로그램을 기록한 컴퓨터 판독 가능한 기록매체 | |
WO2012011450A1 (ja) | コンテンツ配信装置、コンテンツ再生装置、コンテンツ配信システム、コンテンツ配信装置の制御方法、制御プログラム、および、記録媒体 | |
JP5673538B2 (ja) | 配信システム | |
US20110087915A1 (en) | Hybrid reliable streaming protocol for peer-to-peer multicasting | |
CN113422818B (zh) | 一种数据级联传输方法、系统及节点设备 | |
KR102198701B1 (ko) | 멀티미디어 시스템에서 정보를 송수신하는 방법 및 장치 | |
JP2010028812A (ja) | 通信制御装置及び通信制御方法 | |
US8811180B2 (en) | Communication apparatus and communication method | |
JP5724139B2 (ja) | セッション数によりp2pのツリー構造を形成するp2p方式のインターネットライブ放送サービスシステム及び方法 | |
KR20160106701A (ko) | 세그먼트들로 분할된 멀티미디어 콘텐츠를 수신하도록 구성된 클라이언트 단말에 의해 네트워크 정보를 획득하기 위한 방법 | |
JP2011182061A (ja) | 通信端末およびデータ配信方式切り替えプログラム | |
JP5014244B2 (ja) | 映像配信装置及びその制御方法、映像配信システム、プログラム | |
US20120072604A1 (en) | technique for delivering content to a user | |
JP2011135207A (ja) | ストリーム配信装置、方法及びプログラム | |
KR101252947B1 (ko) | 비디오 청크 분포에 적응적인 푸쉬-풀 혼성 스트리밍 방법 및 장치 | |
WO2023226949A1 (zh) | 实时流媒体数据传输的方法、设备及存储介质 | |
JP5205783B2 (ja) | コンテンツ配信システム | |
JP2007183714A (ja) | コンテンツ配信システム、中継サーバ及び中継管理サーバ | |
US20170311046A1 (en) | Method of Broadcasting Contents by Streaming in a Peer-to-Peer Network | |
JP2008278261A (ja) | 中継装置、中継装置制御方法、通信システムおよび中継プログラム | |
JP6166445B1 (ja) | アプリケーション層マルチキャスト配信方法 | |
JP7413827B2 (ja) | 配信システム、配信装置、プログラム及び配信方法 | |
CN109951717A (zh) | 一种快速开播方法及装置 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20120321 |
|
A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20130513 |
|
A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20131008 |