図面 (/)

技術 ストリーミングデータ通信システム、ストリーミングデータ通信装置及び適正ビットレート検出方法

出願人 パナソニック株式会社
発明者 渡辺紳一
出願日 2003年12月1日 (16年11ヶ月経過) 出願番号 2003-402224
公開日 2005年6月23日 (15年5ヶ月経過) 公開番号 2005-167514
状態 未査定
技術分野 CATV、双方向TV等 双方向TV,動画像配信等 広域データ交換 通信制御
主要キーワード 初期帯域 ポート番 赤外線インターフェイス リモコン処理 マークビット ビットレート検出 指定チャネル 送出ビットレート
関連する未来課題
重要な関連分野

この項目の情報は公開日時点(2005年6月23日)のものです。
また、この項目は機械的に抽出しているため、正しく解析できていない場合があります

図面 (20)

課題

ネットワーク上のSTBに適したビットレートを検出すること。

解決手段

ストリーミングデータを配信する放送サーバ101と、ストリーミングデータを受信するストリーミングデータ通信装置(STB)102〜106と、を具備するストリーミングデータ通信システムにおいて、放送サーバ101は、ストリーミングデータ通信装置(STB)102〜106の適正なビットレートを検出するためのビットレートを変えたテストデータパケット送出し、ストリーミングデータ通信装置(STB)102〜106は、このテストデータパケットから検出されたパケットロスに応じて適正なビットレートを判断する。

概要

背景

従来、ADSL、FTTH等の公衆ブロードバンドネットワークを利用し、IPマルチキャストによるストリーミング放送が実現されている(例えば、特許文献1)。しかし、セットトップボックス(以下、「STB(Set Top Box)」という)を設置する利用者側では、ネットワーク環境モデムルータ、ハブ等)とこのSTBの性能が必ずしも同一でないことから、パケットロスによる画像の乱れが発生する事態が生じている。

このような問題に対する対策として、ビットレート転送レート)を調整するプロトコルとしてRTCP(RTP control protocol)が存在する。このRTCPは、サーバとSTBとの間でパケット廃棄統計情報交換することで、サーバの送出ビットレートストリーミング再生中に動的に調整する。

また、事前にビットレートを調整し、IPマルチキャストのストリーミングのビットレートを変更する方法も考えられる。
特開2001−69483号公報

概要

ネットワーク上のSTBに適したビットレートを検出すること。ストリーミングデータを配信する放送サーバ101と、ストリーミングデータを受信するストリーミングデータ通信装置(STB)102〜106と、を具備するストリーミングデータ通信システムにおいて、放送サーバ101は、ストリーミングデータ通信装置(STB)102〜106の適正なビットレートを検出するためのビットレートを変えたテストデータパケット送出し、ストリーミングデータ通信装置(STB)102〜106は、このテストデータパケットから検出されたパケットロスに応じて適正なビットレートを判断する。

目的

本発明は、かかる問題点に鑑みて為されたものであり、ネットワーク上のSTBに適したビットレートを検出することができるストリーミングデータ通信システム、ストリーミングデータ通信装置及び適正ビットレート検出方法を提供することを目的とする。

効果

実績

技術文献被引用数
0件
牽制数
2件

この技術が所属する分野

(分野番号表示ON)※整理標準化データをもとに当社作成

ライセンス契約や譲渡などの可能性がある特許掲載中! 開放特許随時追加・更新中 詳しくはこちら

請求項1

ストリーミングデータを配信するサーバと、前記ストリーミングデータを受信するストリーミングデータ通信装置と、を具備するストリーミングデータ通信システムであって、前記サーバは、前記ストリーミングデータ通信装置の適正なビットレートを検出するためのビットレートを変えたテストデータパケット送出し、前記ストリーミングデータ通信装置は、前記テストデータパケットから検出されたパケットロスに応じて適正なビットレートを判断することを特徴とするストリーミングデータ通信システム。

請求項2

前記サーバは、前記テストデータパケットのビットレートを順次繰り上げて送出し、前記ストリーミングデータ通信装置は、パケットロスを検出したビットレートの直前のビットレートが適正なビットレートであると判断することを特徴とする請求項1記載のストリーミングデータ通信システム。

請求項3

前記サーバは、前記テストデータパケットのビットレートを繰り上げる度に当該テストデータパケットのヘッダに含まれるマークビットを変更し、前記ストリーミングデータ通信装置は、当該マークビットを検出して前記テストデータパケットのビットレートの変化を認識することを特徴とする請求項2記載のストリーミングデータ通信システム。

請求項4

配信されるストリーミングデータを受信するストリーミングデータ通信装置であって、前記ストリーミングデータを配信するサーバから適正なビットレートを検出するためのビットレートを変えたテストデータパケットを受信する受信手段と、前記テストデータパケットのパケットロスを検出する検出手段と、前記パケットロスの検出結果に応じて適正なビットレートを判断する制御手段と、を具備することを特徴とするストリーミングデータ通信装置。

請求項5

前記受信手段は、ビットレートを順次繰り上げたテストデータパケットを受信し、前記制御手段は、パケットロスが検出されたビットレートの直前のビットレートが適正なビットレートであると判断することを特徴とする請求項4記載のストリーミングデータ通信装置。

請求項6

前記制御手段は、ビットレートを繰り上げる度に変更されるテストデータパケットのヘッダ内のマークビットを検出することで前記テストデータパケットのビットレートの変化を認識することを特徴とする請求項5記載のストリーミングデータ通信装置。

請求項7

ストリーミングデータをストリーミングデータ通信装置に配信するサーバ装置であって、前記ストリーミングデータを配信する配信手段と、前記ストリーミングデータに先立って前記ストリーミングデータ通信装置の適正なビットレートを検出するためのビットレートを変えたテストデータパケットを送出する送出手段と、を具備することを特徴とするサーバ装置。

請求項8

前記送出手段は、前記テストデータパケットのビットレートを順次繰り上げて送出することを特徴とする請求項7記載のサーバ装置。

請求項9

前記送出手段は、前記テストデータパケットのビットレートを繰り上げる度に当該テストデータパケットのヘッダに含まれるマークビットを変更することを特徴とする請求項8記載のサーバ装置。

請求項10

サーバからストリーミングデータの配信を受けるストリーミングデータ通信装置における適正ビットレート検出方法であって、前記サーバから前記ストリーミングデータに先立って前記ストリーミングデータ通信装置の適正なビットレートを検出するためのビットレートを変えたテストデータパケットを送出し、前記ストリーミングデータ通信装置で前記テストデータパケットのパケットロスを検出し、前記パケットロスの検出結果に応じて適正なビットレートを判断することを特徴とする適正ビットレート検出方法。

請求項11

前記サーバから前記テストデータパケットのビットレートを順次繰り上げて送出し、前記ストリーミングデータ通信装置でパケットロスを検出したビットレートの直前のビットレートが適正なビットレートであると判断することを特徴とする請求項10記載の適正ビットレート検出方法。

請求項12

前記サーバで前記テストデータパケットのビットレートを繰り上げる度に当該テストデータパケットのヘッダに含まれるマークビットを変更し、前記ストリーミングデータ通信装置で当該マークビットを検出して前記テストデータパケットのビットレートの変化を認識することを特徴とする請求項11記載の適正ビットレート検出方法。

技術分野

背景技術

0002

従来、ADSL、FTTH等の公衆ブロードバンドネットワークを利用し、IPマルチキャストによるストリーミング放送が実現されている(例えば、特許文献1)。しかし、セットトップボックス(以下、「STB(Set Top Box)」という)を設置する利用者側では、ネットワーク環境モデムルータ、ハブ等)とこのSTBの性能が必ずしも同一でないことから、パケットロスによる画像の乱れが発生する事態が生じている。

0003

このような問題に対する対策として、ビットレート転送レート)を調整するプロトコルとしてRTCP(RTP control protocol)が存在する。このRTCPは、サーバとSTBとの間でパケット廃棄統計情報交換することで、サーバの送出ビットレートストリーミング再生中に動的に調整する。

0004

また、事前にビットレートを調整し、IPマルチキャストのストリーミングのビットレートを変更する方法も考えられる。
特開2001−69483号公報

発明が解決しようとする課題

0005

しかしながら、上記のようにRTCPを用いた方法では、パケット廃棄を行った後に動的に送出ビットレートを調整するものであることから、画像の乱れを事前に防止することができないという問題がある。また、動的にビットレートを変更する場合、途中から画質が低下、或いは、向上することになり、チャネルに対する画質の均質化という面でも問題が発生する。さらに、既に受信中のSTBに対しても、同様な問題が発生するだけでなく、動的なビットレートの変化(可変ビットレート)に対応できないSTBの場合、画像の乱れや画像が表示できない等の問題が発生する可能性がある。

0006

また、マルチキャストではなく、ユニキャストで各STBに対してビットレートを事前に調整し、配信することも考えられる。しかし、全てのSTBのネットワーク環境を考慮して個別に対応することは現実的に不可能であり、また、ユニキャストを用いた方法では配信サーバ受信端末装置とが1対1の関係でデータを配信することからネットワーク上のトラフィックが大きくなり、配信速度が低下するという問題が発生する。

0007

このような問題を解消するため、マルチキャスト方式を用いてネットワーク上のSTBに適したビットレートでストリーミングデータを配信できるようにすることが望ましいが、かかる場合にはネットワーク上のSTBに適したビットレートを検出することが困難であるという問題がある。

0008

本発明は、かかる問題点に鑑みて為されたものであり、ネットワーク上のSTBに適したビットレートを検出することができるストリーミングデータ通信システム、ストリーミングデータ通信装置及び適正ビットレート検出方法を提供することを目的とする。

課題を解決するための手段

0009

本発明は、ストリーミングデータを配信するサーバと、ストリーミングデータを受信するストリーミングデータ通信装置と、を具備するストリーミングデータ通信システムにおいて、サーバは、ストリーミングデータ通信装置の適正なビットレートを検出するためのビットレートを変えたテストデータパケット送出し、ストリーミングデータ通信装置は、このテストデータパケットから検出されたパケットロスに応じて適正なビットレートを判断するものである。

発明の効果

0010

本発明に係るストリーミングデータ通信システム、ストリーミングデータ通信装置及び適正ビットレート検出方法によれば、ネットワーク上のSTBに適したビットレートを検出することができる。

発明を実施するための最良の形態

0011

本発明の第1の態様に係るストリーミングデータ通信システムは、ストリーミングデータを配信するサーバと、前記ストリーミングデータを受信するストリーミングデータ通信装置と、を具備するストリーミングデータ通信システムであって、前記サーバは、前記ストリーミングデータ通信装置の適正なビットレートを検出するためのビットレートを変えたテストデータパケットを送出し、前記ストリーミングデータ通信装置は、前記テストデータパケットから検出されたパケットロスに応じて適正なビットレートを判断する構成を採る。

0012

この構成によれば、ストリーミングデータ通信装置において、サーバから送出されたテストデータパケットから検出されたパケットロスに応じて適正なビットレートを判断するので、ネットワーク上のストリーミングデータ通信装置に適したビットレートを検出することができる。

0013

本発明の第2の態様は、第1の態様に係るストリーミングデータ通信システムにおいて、前記サーバは、前記テストデータパケットのビットレートを順次繰り上げて送出し、前記ストリーミングデータ通信装置は、パケットロスを検出したビットレートの直前のビットレートが適正なビットレートであると判断する構成を採る。

0014

この構成によれば、ビットレートが繰り上げられて送出されるテストデータパケットにおいてパケットロスを検出した場合、当該ビットレートの直前のビットレートが適正なビットレートと判断するので、パケットロスを検出するという簡単な制御を行うだけで適正なビットレートを容易に検出することができる。

0015

本発明の第3の態様は、第2の態様に係るストリーミングデータ通信システムにおいて、前記サーバは、前記テストデータパケットのビットレートを繰り上げる度に当該テストデータパケットのヘッダに含まれるマークビットを変更し、前記ストリーミングデータ通信装置は、当該マークビットを検出して前記テストデータパケットのビットレートの変化を認識する構成を採る。

0016

この構成によれば、マークビットを検出することでテストデータパケットのビットレートの変化を認識することができるので、マークビットのみを検出するという簡単な制御を行うだけでビットレートの変化を容易に認識することができる。

0017

本発明の第4の態様に係るストリーミングデータ通信装置は、配信されるストリーミングデータを受信するストリーミングデータ通信装置であって、前記ストリーミングデータを配信するサーバから適正なビットレートを検出するためのビットレートを変えたテストデータパケットを受信する受信手段と、前記テストデータパケットのパケットロスを検出する検出手段と、前記パケットロスの検出結果に応じて適正なビットレートを判断する制御手段と、を具備する構成を採る。

0018

この構成によれば、サーバから送出されたテストデータパケットのパケットロスの検出結果に応じて適正なビットレートを判断するので、ネットワーク上のストリーミングデータ通信装置に適したビットレートを検出することができる。

0019

本発明の第5の態様は、第4の態様に係るストリーミングデータ通信装置において、前記受信手段は、ビットレートを順次繰り上げたテストデータパケットを受信し、前記制御手段は、パケットロスが検出されたビットレートの直前のビットレートが適正なビットレートであると判断する構成を採る。

0020

この構成によれば、ビットレートが繰り上げられて送出されるテストデータパケットにおいてパケットロスを検出した場合、当該ビットレートの直前のビットレートが適正なビットレートと判断するので、パケットロスを検出するという簡単な制御を行うだけで適正なビットレートを容易に検出することができる。

0021

本発明の第6の態様は、第5の態様に係るストリーミングデータ通信装置において、前記制御手段は、ビットレートを繰り上げる度に変更されるテストデータパケットのヘッダ内のマークビットを検出することで前記テストデータパケットのビットレートの変化を認識する構成を採る。

0022

この構成によれば、マークビットを検出することでテストデータパケットのビットレートの変化を認識することができるので、マークビットのみを検出するという簡単な制御を行うだけでビットレートの変化を容易に認識することができる。

0023

本発明の第7の態様に係るサーバ装置は、ストリーミングデータをストリーミングデータ通信装置に配信するサーバ装置であって、前記ストリーミングデータを配信する配信手段と、前記ストリーミングデータに先立って前記ストリーミングデータ通信装置の適正なビットレートを検出するためのビットレートを変えたテストデータパケットを送出する送出手段と、を具備する構成を採る。

0024

この構成によれば、ストリーミングデータに先立って前記ストリーミングデータ通信装置の適正なビットレートを検出するためのビットレートを変えたテストデータパケットを送出するので、ストリーミングデータ通信装置において、このテストデータパケットから検出されたパケットロスに応じて適正なビットレートを判断することにより、ネットワーク上のストリーミングデータ通信装置に適したビットレートを検出することができる。

0025

本発明の第8の態様は、第7の態様に係るサーバ装置において、前記送出手段は、前記テストデータパケットのビットレートを順次繰り上げて送出する構成を採る。

0026

この構成によれば、テストデータパケットのビットレートを順次繰り上げて送出されるので、ストリーミングデータ通信装置において、このテストデータパケットにおいてパケットロスを検出した場合に当該ビットレートの直前のビットレートが適正なビットレートと判断することにより、パケットロスを検出するという簡単な制御を行うだけで適正なビットレートを容易に検出することができる。

0027

本発明の第9の態様は、第8の態様に係るサーバ装置において、前記送出手段は、前記テストデータパケットのビットレートを繰り上げる度に当該テストデータパケットのヘッダに含まれるマークビットを変更する構成を採る。

0028

この構成によれば、ビットレートを繰り上げる度にテストデータパケットのヘッダに含まれるマークビットを変更するので、ストリーミングデータ通信装置において、このマークビットを検出することでテストデータパケットのビットレートの変化を認識することにより、マークビットのみを検出するという簡単な制御を行うだけでビットレートの変化を容易に認識することができる。

0029

本発明の第10の態様に係る適正ビットレート検出方法は、サーバからストリーミングデータの配信を受けるストリーミングデータ通信装置における適正ビットレート検出方法であって、前記サーバから前記ストリーミングデータに先立って前記ストリーミングデータ通信装置の適正なビットレートを検出するためのビットレートを変えたテストデータパケットを送出し、前記ストリーミングデータ通信装置で前記テストデータパケットのパケットロスを検出し、前記パケットロスの検出結果に応じて適正なビットレートを判断するものである。

0030

本発明の第11の態様は、第10の態様に係る適正ビットレート検出方法において、前記サーバから前記テストデータパケットのビットレートを順次繰り上げて送出し、前記ストリーミングデータ通信装置でパケットロスを検出したビットレートの直前のビットレートが適正なビットレートであると判断するものである。

0031

本発明の第12の態様は、第11の態様に係る適正ビットレート検出方法において、前記サーバで前記テストデータパケットのビットレートを繰り上げる度に当該テストデータパケットのヘッダに含まれるマークビットを変更し、前記ストリーミングデータ通信装置で当該マークビットを検出して前記テストデータパケットのビットレートの変化を認識するものである。

0032

以下、本発明の実施の形態について、図面を参照して詳細に説明する。

0033

図1は、本発明の一実施の形態に係るストリーミングデータ通信システムが適用されるネットワークの構成を示す図である。

0034

図1に示すように、本実施の形態に係るストリーミングデータ通信システムが適用されるネットワークは、ストリーミングデータを配信する放送サーバ101と、放送サーバ101から配信されるストリーミングデータを、インターネットを介して受信する複数のストリーミングデータ通信装置としてのセットトップボックス(以下、「STB(Set Top Box)」という」102〜106とから構成される。各STB102〜106には、ストリーミングデータが表示されるディスプレイ107〜111が接続されている。

0035

放送サーバ101は、TVチューナー112を備える。TVチューナー112は、衛星放送等から受信したアナログデータをMPEG等のデジタルデータに変換する。放送サーバ101は、この変換後のデジタルデータをストリーミングデータとして、インターネットを介してSTB102〜106に配信する。

0036

図2は、本実施の形態に係るストリーミングデータ通信システムにおけるSTB102〜106周辺のネットワーク環境を示すブロック図である。なお、STB102〜106周辺のネットワーク環境のうち、STB102周辺のネットワーク環境を代表して説明し、他のSTB103〜106周辺のネットワーク環境については省略する。

0037

図2に示すように、STB102周辺のネットワーク環境においては、ADSLやFTTH(以下、「ADSL等」という)201がモデム202を介してルータ/ハブ203に接続されている。このルータ/ハブ203は、ディスプレイ107に接続されたSTB102及びパーソナルコンピュータ(以下、「PC」という)204に接続されている。ADSL等201においては、通常、予め帯域保証されているが、モデム202やルータ/ハブ203は利用者によって様々な製造業者のものが用いられるため、ADSL等201のみによってはSTB102の使用帯域を決定することは困難である。

0038

図3は、本実施の形態に係るストリーミングデータ通信システムにおけるSTB102〜106の構成を示すブロック図である。なお、STB102〜106は、同様の構成を有するため、STB102の構成について説明し、他のSTB103〜106の構成については省略する。

0039

図3に示すように、STB102は、CPU301、メモリ302、赤外線インターフェイス(I/F)303、記憶装置304、TVインターフェイス(I/F)305及びネットワークインターフェイス(I/F)306を備える。

0040

CPU301は、装置全体の動作を制御する。メモリ302には、CPU301が装置全体の制御の際に実行するプログラム、並びに制御の際に必要なデータが格納される。赤外線I/F303は、リモートコントローラからの操作入力受け付ける。記憶装置304には、放送サーバ101から受信したストリーミングデータが保存される。TVI/F305は、接続されたディスプレイと装置本体とをインターフェイスを介して接続する。ネットワークI/F306は、インターネットと装置本体とをインターフェイスを介して接続する。

0041

図4は、本実施の形態に係るストリーミングデータ通信システムにおけるSTB102が備えるCPU301の機能ブロック図である。

0042

図4に示すように、CPU301は、ストリーミング処理部401、TV再生部402、通信品質測定部403及びリモコン処理部404を備える。

0043

ストリーミング処理部401は、ネットワークI/F306を介して入力されたストリーミングデータを受信する。受信したストリーミングデータをTV再生部402及び通信品質測定部403に渡す。TV再生部402は、ストリーミング処理部401から得たデジタルデータをアナログデータに変換し、TVI/F305を介して当該アナログデータをディスプレイで再生する。

0044

通信品質測定部403は、ストリーミングデータ処理部401から得たストリーミングデータの通信品質を測定する。具体的には、後述するように、受信したパケット喪失チェックする。リモコン処理部404は、赤外線I/F303を介して受け付けた操作入力を処理し、通信品質測定部403に通知する。

0045

図5は、本実施の形態に係るストリーミングデータ通信システムにおける放送サーバ101の構成を示すブロック図である。

0046

図5に示すように、放送サーバ101は、ビットレート変換部501、パケット送出部502及びSTB通信部503を備える。

0047

ビットレート変換部501は、TVチューナー112によって変換されたMPEG等のデジタルデータのビットレートの変換を行う。ビットレート変換部501が変換を行うビットレートは、STB通信部503が配信先であるSTBとの間で決定したビットレートに従う。

0048

パケット送出部502は、ビットレート変換部501により変換されたビットレートのパケットを、インターネットを介して配信先であるSTBに送出する。STB通信部503は、ビットレート変換部501で変換するビットレートを決定するために必要なデータパケットを配信先であるSTBとの間で通信する。STB通信部503で決定されたビットレートは、ビットレート変換部501に通知される。

0049

以下、上記構成を有する本ストリーミングデータ通信システムにおける動作について説明する。まず、本実施の形態に係るストリーミングデータ通信システムにおけるSTBの起動処理について説明する。

0050

図6は、本実施の形態に係るストリーミングデータ通信システムにおけるSTBの起動処理を説明するためのシーケンス図である。ここでは、STB102が起動する場合の動作について説明するものとする。

0051

図6に示すように、STB102が起動すると、STB102は、予め認識しておいた自己のネットワーク環境の通信帯域を放送サーバ101に通知する。例えば、STB102は、ADSL等201で保証された通信帯域を通知する。ここで通知される通信帯域は、実際に使用される、現在のネットワーク環境で最適な通信帯域(以下、「最終帯域」という)を決定する際に上限として用いるのみであるので、大雑把な値で構わない。

0052

この通信帯域の通知を受けると、放送サーバ101は、この通信帯域を上限としてビットレートを変更してSTB102に最適なビットレートを決定するためのデータパケット(以下、「テストパケット」という)の通信を開始する。具体的には、まず、テストパケットを送信するレート情報及びその送信の際に用いるポートをSTB102に通知する。

0053

ここで、テストパケットを送信するレート情報について説明する。図7は、レート情報の一例を示す図である。レート情報は、テストパケットのビットレートの単位を通知するための情報である。図7においては、2Mbpsから8Mbpsまで1Mbps単位で送信することを通知する場合について示している。

0054

図8は、本実施の形態に係るストリーミングデータ通信システムにおいて、STB102が放送サーバ101からテストパケットを受信する処理を説明するためのシーケンス図である。

0055

放送サーバ101からテストパケットを受信する場合、STB102は、まず、放送サーバ101から指定されたポートに対してTCP(Transmission Control Protocol)に従って接続(以下、「TCP接続」という)し、RTSP(Real Time Streaming Protocol)に定められた”DESCRIBE”を送出する。

0056

この”DESCRIBE”には、テストパケットの受信を識別するための識別子(以下、「テスト用ID」という)に対応するURLが含まれている。これに対して放送サーバ101は、RTSPに定められた”SDP”をSTB102に送出する。この”SDP”には、SETP用のURLが含まれている。

0057

放送サーバ101から”SDP”を受信すると、STB102は、当該”SDP”の解析を行い、RTSPに定められた”SETUP”を送出する。これに応じて放送サーバ101は、RTPアドレス/ポートをSTB102に送出する。この応答を受けると、STB102は、RTSPに定められた”PLAY”を送出する。これに応じて放送サーバ101は、”rtptime”を送出する。

0058

”rtptime”を送出すると、放送サーバ101は、図9に示すように、RTPストリームをSTB102に送出する。このRTPストリームは、上述のレート情報に示したビットレート単位に応じて送出される。すなわち、上述のレート情報では1Mbps単位が指定されているので、2Mbps、3Mbps・・・8MbpsのRTPストリームがSTB102に送出される。

0059

ここで、放送サーバ101から送出されるRTPストリーミングを構成するパケットについて図10を用いて説明する。放送サーバ101から送出されるRTPパケットは、図10に示すように、イーサヘッダ、IPヘッダUDPヘッダRTPヘッダ及びテストデータを含む。RTPヘッダは、RFC1889に準拠した1ビットのマークビット及びシーケンス番号を含んでいる。

0060

マークビットは、レート情報におけるビットレートを繰り上げた場合に変更される。上述の例でいえば、2Mbpsではマークビットを”0”で送出し、2Mbpsから3Mbpsにビットレートを変更する場合にマークビットを”1”に変更して送出する。また、3Mbpsから4Mbpsにビットレートを変更する場合にマークビットを”0”に変更して送出する。STB102側では、このマークビットの値を検出することでテストパケットの通信帯域が切り替わったことを検知する。テストデータとしては、特にその内容は限定されず、如何なるデータであってもよい。

0061

図9の例を用いて説明する。放送サーバ101は、まず、2MbpsのRTPストリームをSTB102に送出する。そして、当該RTPストリームの送出から一定時間経過後にレート情報に基づいてビットレートを1Mbps上げ、3MbpsのRTPストリームを送出する。このとき、放送サーバ101は、RTPヘッダのマークビットを”0”から”1”に変更する。

0062

STB102においては、RTPヘッダのマークビットが変更されたことを検出して、通信帯域が切り替わったことを検知する。同時に、RTPヘッダのシーケンス番号の連続性を検出することで、パケットの喪失(パケットロス)をチェックする。

0063

このような処理をレート情報に示された8MbpsのRTPストリームまで繰り返す。そして、8MbpsのRTPストリームまで完了したならば、パケットロスが発生する直前の通信帯域を利用者側の初期帯域として登録する。ここで、初期帯域とは、STB102の最終帯域を決定するために起動処理で予め決めておく通信帯域をいう。そして、TCPに従って切断する。例えば、パケットロスが5MbpsのRTPストリームで発生した場合には、4Mbpsが初期帯域として登録されることとなる。

0064

以下、初期帯域が登録されたSTBの要求に応じてストリーミングデータが配信される場合の動作について図11を用いて説明する。図11は、本実施の形態に係るストリーミングデータ通信システムにおいて、STBの要求に応じてストリーミングデータが配信される動作を説明するためのフロー図である。

0065

図11に示すように、STBがストリーミングデータの配信を要求する場合、STBから配信を希望するチャネル番号及び当該STBに登録された初期帯域が放送サーバ101に送出される。放送サーバ101は、このチャネル番号及び初期帯域を受け付ける(ST1101)。

0066

チャネル番号及び初期帯域を受け付けたならば、放送サーバ101は、放送サーバ101が現在割り当てることができる通信帯域に初期帯域以上の空きがあるか判断する(ST1102)。通信帯域の空きは、図12に示すチャネルテーブルに設定されたビットレート及びSTBから送出された初期帯域の和と、放送サーバ101が有する通信帯域とを比較することで判断される。なお、このチャネルテーブルは、放送サーバ101で管理される。

0067

図12に示すように、チャネルテーブルには、放送サーバ101が提供するコンテンツに対応するチャネル番号に対応して、その種別、ビットレート、マルチキャストアドレス/ポート、最新使用日時及びアクセス数が記録されている。各チャネル番号におけるビットレートは、STBからの要求に応じてチャネルテーブルに設定されていく。最新使用日時には、当該エントリを最後に使用された日時が記録される。アクセス数には、当該エントリを現在使用しているSTBの数が記録される。

0068

放送サーバ101が現在割り当てることができる通信帯域に初期帯域以上の空きがある場合には、放送サーバ101は、当該ストリーミングデータの配信を要求してきたSTBの最終帯域を決定する(ST1103)。この最終帯域を決定する処理については後述する。

0069

最終帯域を決定したならば、STBからその最終帯域が送出されるので、放送サーバ101は、これを受け付ける(ST1104)。そして、最終帯域のストリームを生成し(ST1105)、生成したストリームによってパケットをSTBに送出する(ST1106)。なお、生成されたストリームの通信帯域(ビットレート)は、チャネルテーブルに新たに設定される。

0070

一方、放送サーバ101が現在割り当てることができる通信帯域に初期帯域以上の空きがない場合には、放送サーバ101は、チャネルテーブルから指定されたチャネル番号(以下、「指定チャネル番号」という)の最大帯域(ビットレート)を取得する(ST1107)。図12において指定チャネル番号が”100”であるとすると、最大帯域は”8Mbps”である。そして、放送サーバ101が現在割り当てることができる通信帯域に最大帯域以上の空きがあるか判断する(ST1108)。

0071

放送サーバ101が現在割り当てることができる通信帯域に最大帯域以上の空きがある場合には、割り当てることができる分だけの通信帯域のストリームを生成し(ST1109)、生成したストリームによってパケットをSTBに送出する(ST1110)。なお、生成されたストリームの通信帯域(ビットレート)は、チャネルテーブルに設定される。

0072

これに対して、放送サーバ101が現在割り当てることができる通信帯域に最大帯域以上の空きがない場合には、指定された初期帯域に最も近い通信帯域(ビットレート)のストリームを選択し(ST1111)、選択したストリームによってパケットをSTBに送出する(ST1112)。

0073

ここで、放送サーバ101が現在割り当てることができる通信帯域に応じて具体例を用いて説明する。具体例としては、放送サーバ101が現在割り当てることができる通信帯域に初期帯域以上の空きがある場合(図13)及び放送サーバ101が現在割り当てることができる通信帯域に初期帯域以上の空きがない場合(図18図21)について説明する。特に、初期帯域以上の空きがない場合は、放送サーバ101が現在割り当てることができる通信帯域に指定チャネル番号の最大帯域以上の空きがない場合(図18)及び放送サーバ101が現在割り当てることができる通信帯域に指定チャネル番号の最大帯域以上の空きがある場合(図21)について説明する。

0074

図13は、放送サーバ101が現在割り当てることができる通信帯域に初期帯域以上の空きがある場合の一例を示す図である。図13においては、放送サーバ101が12Mbpsの通信帯域を有するものとする。また、現在、STB102及びSTB103がストリーミングデータの配信を受けているものとし、STB104が新たにストリーミングデータの配信を要求するものとする。なお、STB102の最終帯域は、2.2Mbpsであり、STB103の最終帯域は、1.5Mbpsであるものとする。すなわち、放送サーバ101は、現在割り当てることができる通信帯域として8.3Mbpsの空きを有している。さらに、STB104の初期帯域は、5Mbpsであるものとし、最終帯域は5.9Mbpsであるものとする。

0075

図14図17は、放送サーバ101が現在割り当てることができる通信帯域に初期帯域以上の空きがある場合にストリーミングデータを配信する場合のシーケンス図である。以下、図13に示す具体例を用いて説明する。

0076

図14に示すように、ストリーミングデータの配信を要求する場合、STB104は、放送サーバ101にチャネル番号及び初期帯域を通知する。図13に示す例では、STB104から初期帯域として5Mbpsが通知される。

0077

この通知を受けると、放送サーバ101は、上述のように、現在割り当てることができる通信帯域に初期帯域以上の空きがあるか判断する。図13に示す例では、現在割り当てることができる通信帯域として8.3Mbpsの空きがあるので、STB104の初期帯域(5Mbps)以上の空きがあると判断される。

0078

続いて、放送サーバ101は、通信帯域の空きから最終的に割り当てることができる通信帯域を決定する。すなわち、STB104の最終帯域を決定する動作に移行する。その際、放送サーバ101は、まず、テストパケットを送信するレート情報及びその送信の際に用いるポートをSTB104に通知する。

0079

レート情報には、初期帯域を決定する際と同様にテストパケットのビットレートの単位が示されるが、1Mbps単位で送信することを通知する初期帯域の場合とは異なり、100Kbps単位で送信することが通知される。なお、かかるレート情報におけるテストパケットのビットレートの単位は、任意に変更可能である。

0080

このレート情報及びポート番号を受信すると、STB104は、図15に示すように、放送サーバ101から指定されたポートに対してTCP接続し、RTSP(Real Time Streaming Protocol)に定められた”DESCRIBE”を送出する。この”DESCRIBE”には、テスト用IDに対応するURLが含まれている。これに対して放送サーバ1010は、RTSPに定められた”SDP”をSTB104に送出する。この”SDP”には、SETUP用のURLが含まれている。

0081

放送サーバ101から”SDP”を受信すると、STB104は、当該”SDP”の解析を行い、RTSPに定められた”SETUP”を送出する。これに応じて放送サーバ101は、RTPアドレス/ポートをSTB104に送出する。この応答を受けると、STB104は、RTSPに定められた”PLAY”を送出する。これに応じて放送サーバ101は、”rtptime”を送出する。

0082

”rtptime”を送出すると、放送サーバ101は、図16に示すように、RTPストリームをSTB104に送出する。このRTPストリームは、上述のレート情報に示した単位に応じて送出される。すなわち、上述のレート情報では100Kbps単位が指定されているので、初期帯域+100Kbps、初期帯域+200Kbps・・・初期帯域+1000KbpsのRTPストリームがSTB104に送出される。

0083

RTPパケットのマークビットは、初期帯域の場合と同様に、レート情報におけるビットレートを繰り上げた場合に変更され、このマークビットの値を検出することでテストパケットの通信帯域が切り替わったことをSTB104側で検知する。同時に、RTPヘッダのシーケンス番号の連続性を検出することで、パケットロスをチェックする。そして、パケットロスが発生する直前の通信帯域を利用者側の最終帯域として登録する。最後に、TCPに従って切断する。図13に示す例では、初期帯域である5Mbps+1000Kbpsでパケットロスが発生し、5.9MbpsがSTB104の最終帯域として登録されることとなる。

0084

最終帯域が登録されたならば、STB104は、図17に示すように、これを放送サーバ101に通知する。最終帯域を受け取ったならば、放送サーバ101は、指定チャネル番号の最終帯域のマルチキャストストリームを生成し、RTPパケットをIPルータに送信する。そして、チャネルテーブルにエントリを追加し、アクセス数をインクリメントする。

0085

その後、放送サーバ101は、指定チャネル番号のマルチキャストアドレス・ポートをSTB104に通知する。この通知を受けると、STB104は、IPルータに対し、IGMP(Internet Gateway Multicast Protocol)プロトコルに定められたJOINパケットを送出する。なお、このJOINパケットには、STBが配信を希望するストリーミングデータが送られてくるマルチキャストアドレスが指定されている。

0086

IPルータは、このJOINパケットを受信すると、指定されたマルチキャストアドレスに対応するゲートを開く。これにより、放送サーバ101から当該マルチキャストアドレスで配信されるRTPパケットをSTB104で受信することができるようになる。

0087

STB104では、このRTPパケットを受信して再生する。そして、所望の再生が完了したならば、IGMPプロトコルに定められたLEVEパケットを送出する。このLEAVEパケットを受信すると、IPルータが先のマルチキャストアドレスに対応するゲートを閉じる。これにより、RTPパケットをSTBで受信することができなくなる。

0088

最後に、STB104は、放送サーバ101に対して受信終了を通知する。受信終了を受信すると、放送サーバ101は、チャネルテーブルの指定チャネル番号のアクセス数をデクリメントして処理を終了する。

0089

このように放送サーバ101が現在割り当てることができる通信帯域に初期帯域以上の空きがある場合には、STB104の最終帯域を決定し、その最終帯域のマルチキャストストリームを生成してストリーミングデータを配信する。

0090

このように本実施の形態に係るストリーミングデータ通信システムによれば、STB104において、放送サーバ101から送出されたテストパケットから検出されたパケットロスに応じて適正なビットレート(最終帯域)を判断するので、ネットワーク上のSTB104に適したビットレートを検出することができる。

0091

また、本実施の形態に係るストリーミングデータ通信システムによれば、ビットレートが繰り上げられて送出されるテストパケットにおいてパケットロスを検出した場合、当該ビットレートの直前のビットレートが適正なビットレート(最終帯域)と判断するので、パケットロスを検出するという簡単な制御を行うだけで適正なビットレートを容易に検出することができる。

0092

さらに、本実施の形態に係るストリーミングデータ通信システムによれば、テストパケットのヘッダに含まれるマークビットを検出することでテストパケットのビットレートの変化を認識することができるので、マークビットのみを検出するという簡単な制御を行うだけでビットレートの変化を容易に認識することができる。

0093

図18は、放送サーバ101が現在割り当てることができる通信帯域に初期帯域以上の空きがない場合の一例を示す図である。特に、図18は、放送サーバ101が現在割り当てることができる通信帯域に指定チャネル番号の最大帯域以上の空きがない場合の一例を示す図である。

0094

なお、図18においては、STB102及び103の最終帯域がそれぞれ6Mbps及び4Mbpsである点、並びに、STB104の初期帯域が8Mbpsである点で図13に示す例と相違する。すなわち、放送サーバ101は、現在割り当てることができる通信帯域として2Mbpsの空きを有している。なお、STB102及びSTB103は、STB104による指定チャネル番号と同一のチャネル番号のストリーミングデータの配信を受けているものとし、この指定チャネル番号においては他のビットレートは設定されていないものとする。

0095

図19及び図20は、放送サーバ101が現在割り当てることができる通信帯域に初期帯域以上の空きがない場合にストリーミングデータを配信する場合のシーケンス図である。以下、図18に示す具体例を用いて説明する。

0096

図19に示すように、ストリーミングデータの配信を要求する場合、STB104は、放送サーバ101にチャネル番号及び初期帯域を通知する。図18に示す例では、STB104から初期帯域として8Mbpsが通知される。

0097

この通知を受けると、放送サーバ101は、上述のように、現在割り当てることができる通信帯域に初期帯域以上の空きがあるか判断する。図18に示す例では、現在割り当てることができる通信帯域として2Mbpsしか空きがないので、STB104の初期帯域(8Mbps)以上の空きがないと判断される。

0098

次に、放送サーバ101は、現在割り当てることができる通信帯域に、STB104による指定チャネル番号の最大帯域以上の空きがあるか判断する。図18に示す例では、STB104による指定チャネル番号の最大帯域が6Mbpsであるものとする。このため、放送サーバ101は、現在割り当てることができる通信帯域に6Mbps以上の空きがあるか判断する。ここでは、現在割り当てることができる通信帯域として2Mbpsしか空きがないので、STB104による指定チャネル番号の最大帯域(6Mbps)以上の空きがないと判断される。

0099

この場合、放送サーバ101は、STB104の初期帯域(8Mbps)未満で最も近い通信帯域のエントリを取得する。ここでは、STB102が受信している6Mbpsが最も近い。このため、放送サーバ101は、6Mbpsのエントリを取得する。同時に、チャネルテーブルにおけるこのエントリのアクセス数をインクリメントする。

0100

続いて、放送サーバ101は、図20に示すように、指定チャネル番号のマルチキャストアドレス・ポートをSTB104に通知する。この通知を受けると、STB104は、IPルータに対し、IGMPプロトコルに定められたJOINパケットを送出する。なお、このJOINパケットには、STBが配信を希望するストリーミングデータが送られてくるマルチキャストアドレスが指定されている。

0101

このJOINパケットを受信すると、IPルータは、指定されたマルチキャストアドレスに対応するゲートを開く。これにより、放送サーバ101から当該マルチキャストアドレスで配信されるRTPパケットをSTB104で受信することができるようになる。

0102

STB104では、このRTPパケットを受信して再生する。再生が完了したならば、IGMPプロトコルに定められたLEAVEパケットを送出する。このLEAVEパケットを受信すると、IPルータが先のマルチキャストアドレスに対応するゲートを閉じる。これにより、RTPパケットをSTBで受信することができなくなる。

0103

最後に、STB104は、放送サーバ101に対して受信終了を通知する。受信終了を受信すると、放送サーバ101は、チャネルテーブルの指定チャネル番号のアクセス数をデクリメントして処理を終了する。

0104

このように放送サーバ101が現在割り当てることができる通信帯域に初期帯域以上の空きがない場合であって、指定チャネル番号の最大帯域以上の空きがない場合には、現在、設定されている通信帯域(ビットレート)のうち、最も初期帯域に近いものを選択して当該マルチキャストストリームを用いてストリーミングデータを配信する。

0105

図21は、放送サーバ101が現在割り当てることができる通信帯域に初期帯域以上の空きがない場合の一例を示す図である。特に、図21は、放送サーバ101が現在割り当てることができる通信帯域に指定チャネル番号の最大帯域以上の空きがある場合の一例を示す図である。

0106

なお、図21においては、STB102及び103の最終帯域がそれぞれ4Mbps及び3Mbpsである点、並びに、STB104の初期帯域が6Mbpsである点で図13に示す例と相違する。すなわち、放送サーバ101は、現在割り当てることができる通信帯域として5Mbpsの空きを有している。なお、STB102及びSTB103は、STB104による指定チャネル番号と同一のチャネル番号のストリーミングデータの配信を受けているものとし、この指定チャネル番号においては他のビットレートは設定されていないものとする。

0107

図22及び図23は、放送サーバ101が現在割り当てることができる通信帯域に初期帯域以上の空きがない場合にストリーミングデータを配信する場合のシーケンス図である。以下、図21に示す具体例を用いて説明する。

0108

図22に示すように、ストリーミングデータの配信を要求する場合、STB104は、放送サーバ101にチャネル番号及び初期帯域を通知する。図21に示す例では、STB104から初期帯域として6Mbpsが通知される。

0109

この通知を受けると、放送サーバ101は、上述のように、現在割り当てることができる通信帯域に初期帯域以上の空きがあるか判断する。図21に示す例では、現在割り当てることができる通信帯域として5Mbpsしか空きがないので、STB104の初期帯域(6Mbps)以上の空きがないと判断される。

0110

次に、放送サーバ101は、現在割り当てることができる通信帯域に、STB104による指定チャネル番号の最大帯域以上の空きがあるか判断する。図21に示す例では、STB104による指定チャネル番号の最大帯域が4Mbpsであるものとする。このため、放送サーバ101は、現在割り当てることができる通信帯域に4Mbps以上の空きがあるか判断する。ここでは、現在割り当てることができる通信帯域として5Mbpsの空きがあるので、STB104による指定チャネル番号の最大帯域(4Mbps)以上の空きがあると判断される。

0111

STB104による指定チャネル番号の最大帯域(4Mbps)以上の空きがあると判断したならば、図23に示すように、放送サーバ101は、空き帯域のビットレート(5Mbps)で指定チャネル番号のマルチキャストストリームを生成し、RTPパケットをIPルータに送信する。そして、チャネルテーブルにエントリを追加し、アクセス数をインクリメントする。

0112

その後、放送サーバ101は、指定チャネル番号のマルチキャストアドレス・ポートをSTB104に通知する。この通知を受けると、STB104は、IPルータに対し、IGMPプロトコルに定められたJOINパケットを送出する。なお、このJOINパケットには、STBが配信を希望するストリーミングデータが送られてくるマルチキャストアドレスが指定されている。

0113

このJOINパケットを受信すると、IPルータは、指定されたマルチキャストアドレスに対応するゲートを開く。これにより、放送サーバ101から当該マルチキャストアドレスで配信されるRTPパケットをSTB104で受信することができるようになる。

0114

STB104では、このRTPパケットを受信して再生する。そして、所望の再生が完了したならば、IGMPプロトコルに定められたLEAVEパケットを送出する。このLEAVEパケットを受信すると、IPルータが先のマルチキャストアドレスに対応するゲートを閉じる。これにより、RTPパケットをSTBで受信することができなくなる。

0115

最後に、STB104は、放送サーバ101に対して受信終了を通知する。受信終了を受信すると、放送サーバ101は、チャネルテーブルの指定チャネル番号のアクセス数をデクリメントして処理を終了する。

0116

このように放送サーバ101が現在割り当てることができる通信帯域に初期帯域以上の空きがない場合であって、指定チャネル番号の最大帯域以上の空きがある場合には、その空き帯域のビットレートのマルチキャストストリームを生成してストリーミングデータを配信する。

0117

このように本実施の形態に係るストリーミングデータ通信システムによれば、放送サーバ101が現在割り当てることができる通信帯域に初期帯域以上の空きがある場合には、STB104の最終帯域のマルチキャストストリームを生成してストリーミングデータを配信する。また、放送サーバ101が現在割り当てることができる通信帯域に初期帯域以上の空きがない場合であって、指定チャネル番号の最大帯域以上の空きがない場合には、現在、設定されている通信帯域(ビットレート)のうち、最も初期帯域に近いものを選択して当該マルチキャストストリームを用いてストリーミングデータを配信する。さらに、放送サーバ101が現在割り当てることができる通信帯域に初期帯域以上の空きがない場合であって、指定チャネル番号の最大帯域以上の空きがある場合には、その空き帯域のビットレートのマルチキャストストリームを生成してストリーミングデータを配信する。このため、ストリーミングデータの配信先のSTBのネットワーク環境に対応しつつ、放送サーバ101の通信帯域をより効率的に利用してストリーミングデータを配信することができる。

0118

なお、以上説明したように本実施の形態に係るストリーミングデータ通信システムにおいては、ストリーミングデータの配信先のSTBのネットワーク環境に対応しつつ、放送サーバ101の通信帯域をより効率的に利用してストリーミングデータを配信する。すなわち、ストリーミングデータの配信先のSTBのネットワーク環境に応じたビットレートのマルチキャストストリームを生成してストリーミングデータを配信する。

0119

しかしながら、ストリーミングデータの配信先のSTBのネットワーク環境が変化した場合には、変更前のネットワーク環境に応じてビットレートのマルチキャストストリームを配信し続けることは好ましくない。このため、本実施の形態に係るストリーミングデータ通信システムにおいては、チャネルテーブル上で一定時間アクセス数がないエントリを自動的に削除する。

0120

図24は、本実施の形態に係るストリーミングデータ通信システムにおいて、チャネルテーブル上で一定時間アクセス数がないエントリを自動的に削除する動作を説明するためのフロー図である。

0121

図24に示すように、放送サーバ101は、一定時間の経過を監視している(ST2401)。そして、一定時間が経過したならば、チャネルテーブルの検索を行い(ST2402)、アクセス数が”0”であるエントリがあるか判断する(ST2403)。

0122

ここで、アクセス数が”0”であるエントリがあった場合には、当該エントリの最終アクセス時間から一定時間が経過しているか判断する(ST2404)。最終アクセス時間からの一定時間の経過の判断は、チャネルテーブル上の最新使用日時と現在時刻とを比較することで行う。

0123

当該エントリの最終アクセス時間から一定時間が経過している場合には、放送サーバ101は、当該エントリを削除する(ST2405)。そして、当該エントリのビットレートによるマルチキャストストリームの生成を停止する(ST2406)。これにより、当該エントリのビットレートによるマルチキャストストリームの配信が停止される。

0124

そして、放送サーバ101は、全てのエントリに対して当該削除処理を完了したか判断する(ST2407)。全てのエントリに対して完了している場合には処理を終了し、完了していない場合には処理をST2402に戻し、再びST2402以降の処理を繰り返す。

0125

なお、ST2403においてアクセス数が”0”のエントリがない場合、あるいは、ST2404においてアクセス数が”0”のエントリの最終アクセス時間から一定時間が経過していない場合には、放送サーバ101は、処理をST2407に以降し、全てのエントリに対して当該削除処理を完了したか判断する。

0126

このように本実施の形態に係るストリーミングデータ通信システムによれば、チャネルテーブル上で一定時間アクセス数がないエントリを自動的に削除する。このため、当該エントリのビットレート(通信帯域)によるマルチキャストストリームの生成が停止される。したがって、その通信帯域の分だけさらに他のSTBに割り当てることが可能となる。この結果、通信帯域を必要とするSTBに新たに割り当てることができるので、ストリーミングデータの配信先のSTBのネットワーク環境に対応しつつ、放送サーバ101の通信帯域をより効率的に利用することができる。

0127

また、本発明は、当業者に明らかなように、上記実施の形態に記載した技術に従ってプログラムされた一般的な市販のデジタルコンピュータおよびマイクロプロセッサを使って実施することができる。また、当業者に明らかなように、本発明は、上記実施の形態に記載した技術に基づいて当業者により作成されるコンピュータプログラム包含する。

0128

また、本発明を実施するコンピュータをプログラムするために使用できる命令を含む記憶媒体であるコンピュータプログラム製品が本発明の範囲に含まれる。この記憶媒体は、フロッピー(R)ディスク光ディスクCDROM及び磁気ディスク等のディスク、ROM、RAM、EPROM、EEPROM、磁気光カードメモリカードまたはDVD等であるが、特にこれらに限定されるものではない。

0129

本発明に係るストリーミングデータ通信システム、ストリーミングデータ通信装置及び適正ビットレート検出方法によれば、ネットワーク上のSTBに適したビットレートを検出し、その検出結果に応じてストリーミングデータの配信に活用することで放送サーバが有する通信帯域を効率的に利用できる点で有用である。

図面の簡単な説明

0130

本発明の一実施の形態に係るストリーミングデータ通信システムが適用されるネットワークの構成を示す図
上記実施の形態に係るストリーミングデータ通信システムにおけるSTB周辺のネットワーク環境を示すブロック図
上記実施の形態に係るストリーミングデータ通信システムにおけるSTBの構成を示すブロック図
上記実施の形態に係るストリーミングデータ通信システムにおけるSTBが備えるCPUの機能ブロック図
上記実施の形態に係るストリーミングデータ通信システムにおける放送サーバの構成を示すブロック図
上記実施の形態に係るストリーミングデータ通信システムにおけるSTBの起動処理を説明するためのシーケンス図
上記実施の形態に係るストリーミングデータ通信システムにおいて、放送サーバから送信されるレート情報の一例を示す図
上記実施の形態に係るストリーミングデータ通信システムにおいて、STBが放送サーバからテストパケットを受信する処理を説明するためのシーケンス図
上記実施の形態に係るストリーミングデータ通信システムにおいて、STBが放送サーバからテストパケットを受信する処理を説明するためのシーケンス図
上記実施の形態に係るストリーミングデータ通信システムにおいて、放送サーバから送出されるRTPストリーミングを構成するパケットについて示す図
上記実施の形態に係るストリーミングデータ通信システムにおいて、STBの要求に応じてストリーミングデータが配信される動作を説明するためのフロー図
上記実施の形態に係るストリーミングデータ通信システムにおいて、放送サーバが登録するチャネルテーブルの一例について示す図
上記実施の形態に係るストリーミングデータ通信システムにおいて、放送サーバが現在割り当てることができる通信帯域に初期帯域以上の空きがある場合の一例を示す図
上記実施の形態に係るストリーミングデータ通信システムにおいて、放送サーバが現在割り当てることができる通信帯域に初期帯域以上の空きがある場合にストリーミングデータを配信する場合のシーケンス図
上記実施の形態に係るストリーミングデータ通信システムにおいて、放送サーバが現在割り当てることができる通信帯域に初期帯域以上の空きがある場合にストリーミングデータを配信する場合のシーケンス図
上記実施の形態に係るストリーミングデータ通信システムにおいて、放送サーバが現在割り当てることができる通信帯域に初期帯域以上の空きがある場合にストリーミングデータを配信する場合のシーケンス図
上記実施の形態に係るストリーミングデータ通信システムにおいて、放送サーバが現在割り当てることができる通信帯域に初期帯域以上の空きがある場合にストリーミングデータを配信する場合のシーケンス図
上記実施の形態に係るストリーミングデータ通信システムにおいて、放送サーバが現在割り当てることができる通信帯域に初期帯域以上の空きがない場合の一例を示す図
上記実施の形態に係るストリーミングデータ通信システムにおいて、放送サーバが現在割り当てることができる通信帯域に初期帯域以上の空きがない場合にストリーミングデータを配信する場合のシーケンス図
上記実施の形態に係るストリーミングデータ通信システムにおいて、放送サーバが現在割り当てることができる通信帯域に初期帯域以上の空きがない場合にストリーミングデータを配信する場合のシーケンス図
上記実施の形態に係るストリーミングデータ通信システムにおいて、放送サーバが現在割り当てることができる通信帯域に初期帯域以上の空きがない場合の一例を示す図
上記実施の形態に係るストリーミングデータ通信システムにおいて、放送サーバが現在割り当てることができる通信帯域に初期帯域以上の空きがない場合にストリーミングデータを配信する場合のシーケンス図
上記実施の形態に係るストリーミングデータ通信システムにおいて、放送サーバが現在割り当てることができる通信帯域に初期帯域以上の空きがない場合にストリーミングデータを配信する場合のシーケンス図
上記実施の形態に係るストリーミングデータ通信システムにおいて、チャネルテーブル上で一定時間アクセス数がないエントリを自動的に削除する動作を説明するためのフロー図

符号の説明

0131

101放送サーバ
102〜106 STB(セットトップボックス)
107〜111ディスプレイ
112TVチューナー
202モデム
203ルータ/ハブ
301 CPU
302メモリ
304記憶装置
401ストリーミング処理部
402 TV再生部
403通信品質測定部
404リモコン処理部
501ビットレート変換部
502パケット送出部
503 STB通信部

ページトップへ

この技術を出願した法人

この技術を発明した人物

ページトップへ

関連する挑戦したい社会課題

関連する公募課題

ページトップへ

技術視点だけで見ていませんか?

この技術の活用可能性がある分野

分野別動向を把握したい方- 事業化視点で見る -

(分野番号表示ON)※整理標準化データをもとに当社作成

ページトップへ

おススメ サービス

おススメ astavisionコンテンツ

新着 最近 公開された関連が強い技術

この 技術と関連性が強い人物

関連性が強い人物一覧

この 技術と関連する社会課題

関連する挑戦したい社会課題一覧

この 技術と関連する公募課題

関連する公募課題一覧

astavision 新着記事

サイト情報について

本サービスは、国が公開している情報(公開特許公報、特許整理標準化データ等)を元に構成されています。出典元のデータには一部間違いやノイズがあり、情報の正確さについては保証致しかねます。また一時的に、各データの収録範囲や更新周期によって、一部の情報が正しく表示されないことがございます。当サイトの情報を元にした諸問題、不利益等について当方は何ら責任を負いかねることを予めご承知おきのほど宜しくお願い申し上げます。

主たる情報の出典

特許情報…特許整理標準化データ(XML編)、公開特許公報、特許公報、審決公報、Patent Map Guidance System データ