説明

データ配信方法、データ配信装置及びデータ配信プログラム

【課題】使用する帯域を容易に減らすことができるデータ配信方法、データ配信装置及びデータ配信プログラムを提供することを課題とする。
【解決手段】受信した複数種類のデータをネットワークに配信するデータ配信装置12によって実行されるデータ配信方法であって、ネットワークに配信したデータを受信する受信機14から、必要なデータの種類を必要情報として受信し、受信したデータの種類を解析し、受信したデータを必要情報に基づき必要なデータの種類で再構築してネットワークに配信することで上記課題を解決する。

【発明の詳細な説明】
【技術分野】
【0001】
本発明は受信したデータを配信するデータ配信方法、データ配信装置及びデータ配信プログラムに関する。
【背景技術】
【0002】
日本におけるIPTV(Internet Protocol TeleVision)の仕様は一般社団法人IPTVフォーラム(http://www.iptvforum.jp/)により策定され、標準技術となっている。IP放送サービスは、IPTVの技術を利用して、IPネットワークを通じて、放送のように番組を配信するものである。IP放送サービスは普及しつつある。
【0003】
IP放送では、地上デジタル放送をIPプロトコルに乗せて配信するなど、HD(High Definition)コンテンツの配信も行われている。HDコンテンツを配信するには広い帯域が必要となるため、通常FTTH(Fiber To The Home)を使用して配信される。
【0004】
HDコンテンツを配信する仕組みは、RTP(Real-time Transport Protocol)マルチキャストと呼ばれる方式が利用される。RTPとは音声や映像をストリーミング再生するための伝送プロトコルである。
【0005】
HDコンテンツを配信する上記の仕組みでは、Join/Leaveと呼ばれる配信要求/停止要求にしたがって、その配信要求/停止要求を出したホームネットワークに対するストリームの配信/停止を決定する。上記の仕組みでは、あるストリームを配信するか停止するかを決めるだけなので、配信要求を出した各家庭のホームネットワークに同じストリームが配信されることになる。
【0006】
また、ストリーミングされるHDコンテンツ等のコンテンツは、地上デジタル放送と同様、MPEG2システム(MPEG2-TTS)と呼ばれるフォーマットを使用して、映像や音声が暗号化されて送られることが多い。
【0007】
図1はコンテンツを配信するシステムの一例の構成図である。システム1はIPTV用サーバ10、Webサーバ11、無線/有線LANゲートウェイ12、PC13、IPTV対応プレイヤ14、ネットワーク15及び16を含む。IPTV用サーバ10及びWebサーバ11はネットワーク15を介して無線/有線LANゲートウェイ12にデータ通信可能に接続されている。PC13及びIPTV対応プレイヤ14はネットワーク16を介して無線/有線LANゲートウェイ12にデータ通信可能に接続されている。
【0008】
家庭までのネットワーク15はFTTHなどの広帯域のネットワークが使用されていることが多い。また、宅内のホームネットワークであるネットワーク16は、無線LANなどの狭帯域のネットワークが使用されていることが多い。一方で、近年では、PC13の他、TVやゲーム機などホームネットワークであるネットワーク16に接続できる機器が増加している。
【0009】
そのため、システム1ではIPTV対応プレイヤ14で高ビットレートのIP放送を見ると、ホームネットワークであるネットワーク16の帯域を占有してしまい、PC13などの他の機器のネットワークアクセスが遅くなったり、できなくなったりすることがあるという問題があった。そこで、従来は、ホームネットワークで使用する帯域を減らす方法が求められていた(例えば特許文献1参照)。
【先行技術文献】
【特許文献】
【0010】
【特許文献1】特開平10−200494号公報
【発明の概要】
【発明が解決しようとする課題】
【0011】
しかしながら、ホームネットワークで使用する帯域を減らす従来の方法は各パケットのパケット識別子とパケット優先度との対応関係をフィルタリング情報テーブルとして作成しておき、ストリームの各パケットから抽出されるパケット識別子をもとに、フィルタリング情報テーブルを参照して各パケットの送信又は破棄を判定するものである。
【0012】
ホームネットワークで使用する帯域を減らす従来の方法は破棄と判定されたパケットの分だけ帯域を減らすことができるが、パケットの優先度付けを適切に行わなければ、使用する帯域を効果的に減らすことができない。しかし、パケットの優先度付けを適切に行うことは容易でないという問題があった。
【0013】
なお、マルチキャスト配信は、例えばIPTV用サーバ10から各家庭のホームネットワークに同じストリームを配信するものである。したがって、IPTV用サーバ10は各家庭のホームネットワークに応じたストリームを個別に配信することができない。
【0014】
本実施形態は使用する帯域を容易に減らすことができるデータ配信方法、データ配信装置及びデータ配信プログラムを提供することを目的とする。
【課題を解決するための手段】
【0015】
上記課題を解決するため、本実施形態は、受信した複数種類のデータをネットワークに配信するデータ配信装置によって実行されるデータ配信方法であって、前記ネットワークに配信した前記データを受信する受信機から、必要なデータの種類を必要情報として受信し、前記受信したデータの種類を解析し、前記受信したデータを前記必要情報に基づき前記必要なデータの種類で再構築し、前記再構築したデータを前記ネットワークに配信することを特徴とする。
【0016】
なお、本実施形態の構成要素、表現又は構成要素の任意の組合せを、方法、装置、システム、コンピュータプログラム、記録媒体、データ構造などに適用したものも本発明の態様として有効である。
【発明の効果】
【0017】
本実施形態によれば使用する帯域を容易に減らすことができるデータ配信方法、データ配信装置及びデータ配信プログラムを提供可能である。
【図面の簡単な説明】
【0018】
【図1】コンテンツを配信するシステムの一例の構成図である。
【図2】コンテンツを配信するシステムの一実施例の構成図である。
【図3】コンテンツを配信するシステムの一実施例の処理ブロック図である。
【図4】無線/有線LANゲートウェイの一実施例のハードウェア構成図である。
【図5】無線/有線LANゲートウェイの処理手順を表した一実施例のフローチャートである。
【図6】PIDパケット種別対応テーブルの一実施例の構成図である。
【図7】無線/有線LANゲートウェイ及びIPTV対応プレイヤの処理手順を表した一実施例のフローチャートである。
【図8】必要情報の一例の構成図である。
【図9】必要性規則テーブルの一実施例の構成図である。
【図10】コンテンツを配信するシステムの他の実施例の処理ブロック図である。
【図11】必要PIDテーブルの一実施例の構成図である。
【図12】必要PIDの一例の構成図である。
【図13】複数のIPTV対応プレイヤに対応する必要性規則テーブルの一実施例の構成図である。
【図14】複数のIPTV対応プレイヤに対応する必要情報の一例の構成図である。
【図15】複数のチャンネル(コンテンツストリーム)に対応する必要性規則テーブルの一実施例の構成図である。
【図16】複数のIPTV対応プレイヤ及びチャンネルに対応する必要情報の一例の構成図である。
【発明を実施するための形態】
【0019】
次に、本発明を実施するための形態を、以下の実施例に基づき図面を参照しつつ説明していく。なお、本実施例ではデータ配信装置の一例として無線/有線LANゲートウェイを説明するが、受信したデータを配信する他の機器、装置であってもよい。
【0020】
図2はコンテンツを配信するシステムの一実施例の構成図である。システム2はIPTV用サーバ10、無線/有線LANゲートウェイ12、IPTV対応プレイヤ14及び21、ネットワーク15及び16を含む。IPTV用サーバ10はネットワーク15を介して無線/有線LANゲートウェイ12にデータ通信可能に接続されている。また、IPTV用サーバ10はネットワーク15を介してIPTV対応プレイヤ21にデータ通信可能に接続されている。IPTV対応プレイヤ14はネットワーク16を介して無線/有線LANゲートウェイ12にデータ通信可能に接続されている。
【0021】
家庭までのネットワーク15はNGN(Next Generation Network)やFTTHなどの広帯域のネットワークが使用されているものとする。また、宅内のホームネットワークであるネットワーク16は、無線LANなどの狭帯域のネットワークが使用されているものとする。IPTV対応プレイヤ14及び21は例えば別の家庭に設置されている。
【0022】
IPTV用サーバ10はIP放送のコンテンツをマルチキャスト配信する。無線/有線LANゲートウェイ12は宅外のFTTH等の広帯域のネットワーク15と宅内のホームネットワーク等の狭帯域のネットワーク16を繋ぐ。無線/有線LANゲートウェイ12は複数のインタフェースを持ち、複数のネットワークを接続する機器の一例である。
【0023】
IPTV対応プレイヤ14、21はIP放送のコンテンツを受信して再生する機器(受信機)の一例である。なお、IPTV対応プレイヤ14、21はIPTV対応のチューナやレコーダなど、他の機器であってもよい。
【0024】
図2のシステム2は例えば以下のような手順で処理を行う。IPTV対応プレイヤ14はIP放送の配信要求をIPTV用サーバ10に送信する。言い換えれば、IPTV対応プレイヤ14はRTPマルチキャストにJoinする。RTPマルチキャストによるストリーム(RTPマルチキャストストリーム)がIPTV用サーバ10から、配信要求を出したIPTV対応プレイヤ14に送信されるように、IPTV用サーバ10と無線/有線LANゲートウェイ12との間にあるルータ機器(エッジルータ)は状態を移行する。
【0025】
無線/有線LANゲートウェイ12はRTPマルチキャストストリームを受信し、そのRTPマルチキャストストリームを後述のように再構築したあと、ホームネットワークであるネットワーク16に再配信する。IPTV対応プレイヤ14はRTPマルチキャストストリームを受信する。
【0026】
RTPマルチキャストストリームは、RTPヘッダとRTPペイロードとを含むRTPパケットが、UDP通信と同様にIPヘッダやUDPヘッダを付けられてIPパケットにされた上で、連続して配信されるものである。
【0027】
また、RTPペイロードにはMPEG2−TTSパケットが複数個(7個程度)、含まれる。例えばネットワークのMTU(最大転送単位)が通常1500バイトであり、MPEG2−TTSパケットが192バイトであるとき、RTPペイロードはMPEG2−TTSパケットを最大7個含めることができる。
【0028】
MPEG2−TTSパケットには、映像データ、音声データ、番組表などの作成に使用するデータが記述されているパケットに加えて、映像データや音声データが記述されているパケットがどのPIDを持つかを記述しているパケット(パケット種別:PMT)、PMTのパケットがどのPIDを持つかを記述しているパケット(パケット種別:PAT)が存在する。逆に言えば、PAT/PMTのパケットを解析することで、映像データ、音声データ、番組表などの作成に使用するデータが記述されているパケットのPIDは知ることができる。そこで、IP放送のコンテンツを再生する際、IPTV対応プレイヤ14はPAT/PMTのパケットを利用する。
【0029】
図3はコンテンツを配信するシステムの一実施例の処理ブロック図である。IPTV用サーバ10はマルチキャスト送信部31を有する。無線/有線LANゲートウェイ12はマルチキャスト受信部32、RTP解析部33、MPEG解析部34、PIDパケット種別対応テーブル更新部35、PID必要性対応づけ実施部36、パケット蓄積部37、RTP再構築部38、マルチキャスト配信部39、必要情報受信部40、必要性規則変更部41、PIDパケット種別対応テーブル記憶部42、必要性規則テーブル記憶部43、MPEG2−TTSパケット記憶部44を有する。
【0030】
また、IPTV対応プレイヤ14は録画部45、表示部46、制御部47、必要情報判定部48、必要情報通知部49、マルチキャスト受信部50を有する。なお、図3の処理ブロック図は本実施例の説明に不要な一部構成を省略している。図3の処理ブロック図において、無線/有線LANゲートウェイ12はマルチキャスト受信部32の前段に、RTPマルチキャストストリームと、その他のパケットとを振り分ける処理ブロックを設けるようにしてもよい。
【0031】
IPTV用サーバ10のマルチキャスト送信部31はRTPマルチキャストストリームを送信する。無線/有線LANゲートウェイ12のマルチキャスト受信部32はRTPマルチキャストストリームを受信し、RTPマルチキャストストリームからRTPパケットを取り出す。RTP解析部33はRTPパケットを解析し、RTPペイロードに含まれるMPEG2−TTSパケットを抽出する。
【0032】
MPEG解析部34はMPEG2−TTSパケットを解析し、パケット種別ごとのPIDを検出する。PIDパケット種別対応テーブル更新部35はパケット種別とPIDとの対応づけを行い、PIDパケット種別対応テーブルを更新する。PID必要性対応づけ実施部36はPIDパケット種別対応テーブル、必要性規則テーブルに基づき、PIDと必要性との対応づけを実施する。
【0033】
パケット蓄積部37は、PIDと必要性との対応づけにより必要と判定されたMPEG2−TTSパケットをMPEG2−TTSパケット記憶部44に蓄積する。RTP再構築部38は蓄積されたMPEG2−TTSパケットが一定数存在する場合、RTPパケットを再構築する。マルチキャスト配信部39は再構築したRTPパケットを含むRTPマルチキャストストリームをIPTV対応プレイヤ14に送信する。
【0034】
必要情報受信部40はIPTV対応プレイヤ14から後述の必要情報を受信する。必要性規則変更部41は必要情報に基づき、必要性規則テーブルを更新する。PIDパケット種別対応テーブル記憶部42はPIDパケット種別対応テーブルを記憶する。必要性規則テーブル記憶部43は必要性規則テーブルを記憶する。MPEG2−TTSパケット記憶部44はMPEG2−TTSパケットを記憶する。
【0035】
録画部45はMPEG2−TTSパケットに基づき、コンテンツの録画を行う。表示部46はMPEG2−TTSパケットに基づき、コンテンツの表示を行う。制御部47はRTPパケットを解析し、RTPペイロードに含まれるMPEG2−TTSパケットを抽出する。制御部47はユーザ操作等により、MPEG2−TTSパケットを録画部45や表示部46に送信して、コンテンツの録画や表示を行う。
【0036】
必要情報判定部48はユーザ操作や自動的な動作により後述の必要情報を判定する。必要情報通知部49は、必要情報を無線/有線LANゲートウェイ12に通知する。マルチキャスト受信部50はRTPマルチキャストストリームを受信し、RTPマルチキャストストリームからRTPパケットを取り出す。
【0037】
図4は無線/有線LANゲートウェイの一実施例のハードウェア構成図である。図4に示す無線/有線LANゲートウェイ12は、CPU61、ROM62、RAM63、第1インタフェース(I/F)64、第2インタフェース(I/F)65、I/O66、表示部67、キー部68を有する。
【0038】
第1I/F64はFTTHなどの広帯域のネットワーク15に対するインタフェースである。また、第2I/F65は無線LANなどの狭帯域のネットワーク16に対するインタフェースである。CPU61は無線/有線LANゲートウェイ12の処理を全体制御する。ROM62及びRAM63はプログラム、データなどを記憶する。
【0039】
表示部67及びキー部68はI/O66を介して接続されている。表示部67は情報を表示する。キー部68はユーザからの操作を受け付ける。第1I/F64はネットワーク15側からデータを受信し、データの内容をCPU61に渡す。また、第1I/F64はCPU61からの指示に応じてネットワーク15側にデータを送信する。第2I/F65はネットワーク16側からデータを受信し、データの内容をCPU61に渡す。また、第2I/F65はCPU61からの指示に応じてネットワーク16側にデータを送信する。
【0040】
例えばROM62には無線/有線LANゲートウェイ12を制御するプログラムの一部として、データ配信プログラムが記憶されている。そして、CPU61はデータ配信プログラムをROM62から読み出して実行する。データ配信プログラムは、ROM62以外のCPU61とアクセス可能な記憶部に記憶されていても良い。
【0041】
データ配信プログラムは読み取り可能な記録媒体に記録しておくことができる。記録媒体には磁気記録媒体、光ディスク、光磁気記録媒体、半導体メモリなどがある。磁気記録媒体には、HDD、フレキシブルディスク(FD)、磁気テープ(MT)などがある。光ディスクには、DVD(Digital Versatile Disc)、DVD−RAM、CD−ROM(Compact Disc − Read Only Memory)、CD−R(Recordable)/RW(ReWritable)などがある。また、光磁気記録媒体には、MO(Magneto − Optical disk)などがある。
【0042】
データ配信プログラムを流通させる場合は例えばデータ配信プログラムが記録されたDVD、CD−ROMなどの可搬型の記録媒体を販売することが考えられる。データ配信プログラムを実行する無線/有線LANゲートウェイ12は例えば記録媒体読取装置(図示せず)が記録媒体からデータ配信プログラムを読み出す。CPU61は、読み出されたデータ配信プログラムをRAM63に格納する。
【0043】
そして、CPU61はRAM63からデータ配信プログラムを読み取り、データ配信プログラムに従った処理を実行する。CPU61はデータ配信プログラムに従って、各種処理を実現している。
【0044】
図5は無線/有線LANゲートウェイの処理手順を表した一実施例のフローチャートである。ステップS1において、マルチキャスト受信部32はIPTV用サーバ10のマルチキャスト送信部31から送信されたRTPマルチキャストストリームを受信し、RTPマルチキャストストリームからRTPパケットを取り出す。ステップS2において、RTP解析部33はRTPパケットを解析し、RTPペイロードに含まれるMPEG2−TTSパケットを抽出する。ステップS3において、MPEG解析部34はMPEG2−TTSパケットを解析し、パケット種別ごとのPIDを検出する。
【0045】
ステップS4において、PIDパケット種別対応テーブル更新部35はパケット種別とPIDとの対応づけを行い、PIDパケット種別対応テーブルを更新する。ステップS5において、PID必要性対応づけ実施部36はPIDパケット種別対応テーブル、必要性規則テーブルに基づき、PIDと必要性との対応づけを行う。PIDと必要性との対応づけは、どのPIDのMPEG2−TTSパケットが必要かを判定する為のものである。
【0046】
ステップS6において、パケット蓄積部37はPIDと必要性との対応づけにより必要と判定されたMPEG2−TTSパケットをMPEG2−TTSパケット記憶部44に蓄積する。ステップS7において、RTP再構築部38は蓄積されたMPEG2−TTSパケットが一定数存在する場合、RTPパケットを再構築する。ステップS8において、マルチキャスト配信部39は再構築したRTPパケットを含むRTPマルチキャストストリームを配信する。
【0047】
PMTのパケット、映像データ又は音声データのパケットはPIDが変更されることもある。したがって、無線/有線LANゲートウェイ12は基本的に、PAT/PMTのパケットを受信する毎に、図5のフローチャートの処理が必要となる。なお、PAT/PMTのパケットの解析は、負荷を下げるために、所定時間ごとに行うようにしてもよい。
【0048】
図5のフローチャートに示した処理により、システム2は不要なMPEG2−TTSパケットを取り除いたRTPパケットを含むRTPマルチキャストストリームを配信することができる。RTPパケットの生成は、複数のMPEG2−TTSパケットを連続してRTPパケットのペイロードとして、RTPヘッダをRTPプロトコルにしたがって付ければよい。
【0049】
図6はPIDパケット種別対応テーブルの一実施例の構成図である。PIDパケット種別対応テーブルはデータ項目として、例えばパケット種別、対応ユーザ要求、PID(パケット識別子)を有している。
【0050】
図6のパケット種別としてはPAT/PMT/BIT/NIT/EIT/CDT/SDTT/PES(映像/音声/データカルーセル)等が考えられる。なお、PES(データカルーセル)とは地上デジタル放送で行われているデータ放送のようなデータを送信するために使用されるパケットのパケット種別である。
【0051】
通常、PAT/BIT/NIT/EIT/CDT/SDTTのパケットのPIDは固定である。一方、PMT/PESのパケットのPIDはPAT/PMTを解析することで得ることができる。図6のPIDパケット種別対応テーブルの固定でないPMT/PESのパケットのPIDは、PAT/PMTを解析した結果で埋められる。
【0052】
なお、PIDパケット種別対応テーブルは後述の必要情報によって得られる情報と対応づけるために、データ項目として対応ユーザ要求を定義している。なお、PIDパケット種別対応テーブルは、パケット種別と対応ユーザ要求との対応づけを例えばユーザが変更できるようにしてもよい。
【0053】
図7は無線/有線LANゲートウェイ及びIPTV対応プレイヤの処理手順を表した一実施例のフローチャートである。ステップS11において、IPTV対応プレイヤ14の必要情報判定部48は画面表示/録画などの動作上、必要となる情報が何であるかを判定する。
【0054】
必要情報判定部48は、例えば録画予約状態時、放送時間変更を確認するために番組表用のデータが必要となると判定する。必要情報判定部48は番組表を表示(なお、音声は出力されるが、映像は出ない)しようとする場合は、番組表用のデータと音声用のデータとが必要となると判定する。2ヶ国語放送で第一音声を出力している場合は音声1データが必要となると判定する。音声を第一音声から第二音声に切り替えた場合は音声2データが必要となると判定する。
【0055】
上記のように、IPTV対応プレイヤ14において必要となる情報は状況に応じて変化する。そして、ステップS12において、必要情報通知部49は必要となる情報を必要情報として無線/有線LANゲートウェイ12の必要情報受信部40に送信する。
【0056】
ステップS13において、無線/有線LANゲートウェイ12の必要情報受信部40はIPTV対応プレイヤ14から情報の必要・不要に関する必要情報を受信する。ステップS14において、必要性規則変更部41は必要情報に基づき、必要性規則テーブルを更新する。
【0057】
必要情報として情報のやりとりをするパラメータ、および、必要性規則テーブルで必要・不要に対応づけるパラメータとしては以下のものが考えられる。必要性規則テーブルを更新する処理は、IPTV対応プレイヤ14から必要情報を受信する毎に実行することになる。したがって、IPTV対応プレイヤ14からの必要情報に応じて、無線/有線LANゲートウェイ12が行うマルチキャスト配信に含まれるMPEG2−TTSパケットのパケット種別は変わることになる。
【0058】
例えば番組表と音声1データとが必要情報として要求された場合は、無線/有線LANゲートウェイ12が行うマルチキャスト配信に含まれるMPEG2−TTSパケットのパケット種別に番組表と音声1データとが必要であるように必要性規則テーブルを更新することになる。
【0059】
具体的に、IPTV対応プレイヤ14で録画予約状態のとき、必要情報としては放送時間変更を確認するため、番組表用のデータが含まれる。IPTV対応プレイヤ14で番組表を表示するとき、必要情報としては番組表用のデータが含まれる。IPTV対応プレイヤ14で第一音声を出力しているとき、必要情報としては音声1データが含まれる。
【0060】
図8は必要情報の一例の構成図である。図8に示すように、必要情報はIPTV対応プレイヤ14の動作に応じて必要となる情報を指定するものである。図8の例では番組表用のデータ(EPG)と第一音声のデータ(Audio1)とが必要となる情報として指定されている。図8の例では映像のデータ、マルチ音声の第一音声以降のデータ、データ放送のデータが不要であることを表している。
【0061】
図9は必要性規則テーブルの一実施例の構成図である。必要性規則テーブルはデータ項目として、例えば対応ユーザ要求、必要・不要を有している。なお、図9において、対応ユーザ要求「Always」は必ず送信が必要であることを表している。「EPG」は番組表のデータを表している。
【0062】
「Logo」は放送局ロゴアイコンのデータを表している。「Download」はソフトウェア更新のためのデータを表している。「Video」は映像のデータを表している。「Audio」は音声のデータを表している。「Data」はデータ放送のデータを表している。
【0063】
図9の必要性規則テーブルではデータ項目「必要・不要」が「True」になっているところがIPTV対応プレイヤ14の動作に応じて必要となる情報(必要情報)を表している。
【0064】
図10はコンテンツを配信するシステムの他の実施例の処理ブロック図である。IPTV用サーバ10はマルチキャスト送信部71を有する。無線/有線LANゲートウェイ12はマルチキャスト受信部72、RTP解析部73、MPEG2ヘッダ解析部74、PID判定部75、パケット蓄積部76、RTP再構築部77、マルチキャスト配信部78、必要PID受信部79、必要PIDテーブル記憶部80、MPEG2−TTSパケット記憶部81を有する。
【0065】
また、IPTV対応プレイヤ14は必要情報判定部82、必要性規則変更部83、PID必要性対応づけ実施部84、必要PID送信部85、必要性規則テーブル86、PIDパケット種別対応テーブル87、録画部88、表示部89、制御部90、RTP解析部91、MPEG2解析部92、PIDパケット種別対応テーブル更新部93、マルチキャスト受信部94を有する。なお、図10の処理ブロック図は本実施例の説明に不要な一部構成を省略している。また、図10の処理ブロック図は図3の処理ブロック図と同一な部分を含むため、同一な部分について適宜説明を省略している。
【0066】
IPTV用サーバ10のマルチキャスト送信部71はRTPマルチキャストストリームを送信する。無線/有線LANゲートウェイ12のマルチキャスト受信部72はRTPマルチキャストストリームを受信し、RTPマルチキャストストリームからRTPパケットを取り出す。RTP解析部73はRTPパケットを解析し、RTPペイロードに含まれるMPEG2−TTSパケットを抽出する。
【0067】
MPEG2ヘッダ解析部74はMPEG2−TTSパケットのヘッダ部を解析してPIDを検出する。PID判定部75は必要PIDテーブルに基づき、検出したPIDが必要か否かを判定する。パケット蓄積部76は必要と判定されたMPEG2−TTSパケットをMPEG2−TTSパケット記憶部81に蓄積する。RTP再構築部77は蓄積されたMPEG2−TTSパケットが一定数存在する場合、RTPパケットを再構築する。マルチキャスト配信部78は再構築したRTPパケットをIPTV対応プレイヤ14にマルチキャスト配信する。
【0068】
必要PID受信部79はIPTV対応プレイヤ14から必要PIDを受信し、必要PIDに基づき、必要PIDテーブルを更新する。必要PIDテーブル記憶部80は必要PIDテーブルを記憶する。MPEG2−TTSパケット記憶部81はMPEG2−TTSパケットを記憶する。
【0069】
必要情報判定部82はユーザ操作や自動的な動作により必要情報を判定する。必要性規則変更部83は必要情報に基づき、必要性規則テーブルを更新する。PID必要性対応づけ実施部84はPIDパケット種別対応テーブル、必要性規則テーブルに基づき、PIDと必要性との対応づけを実施する。必要PID送信部85は対応づけにより必要と判定されたPIDを必要PIDとして無線/有線LANゲートウェイ12に通知する。
【0070】
必要性規則テーブル記憶部86は必要性規則テーブルを記憶する。PIDパケット種別対応テーブル記憶部87はPIDパケット種別対応テーブルを記憶する。録画部88はMPEG2−TTSパケットに基づき、コンテンツの録画を行う。表示部89は、MPEG2−TTSパケットに基づき、コンテンツの表示を行う。
【0071】
制御部90はRTPパケットを解析し、RTPペイロードに含まれるMPEG2−TTSパケットを抽出する。制御部90はユーザ操作等により、MPEG2−TTSパケットを録画部88や表示部89に送信して、コンテンツの録画や表示を行う。RTP解析部91はRTPパケットを解析し、RTPペイロードに含まれるMPEG2−TTSパケットを抽出する。MPEG2解析部92はMPEG2−TTSパケットを解析し、パケット種別ごとのPIDを検出する。
【0072】
PIDパケット種別対応テーブル更新部93はパケット種別とPIDとの対応づけを行い、PIDパケット種別対応テーブルを更新する。マルチキャスト受信部94はRTPマルチキャストストリームを受信し、RTPマルチキャストストリームからRTPパケットを取り出す。
【0073】
図11は必要PIDテーブルの一実施例の構成図である。図11の必要PIDテーブルはIPTV対応プレイヤ14から受信した必要PIDを蓄積したものである。必要PIDテーブルを利用することにより、図10の無線/有線LANゲートウェイ12はIPTV対応プレイヤ14で不要なMPEG2−TTSパケットを取り除いたRTPパケットをマルチキャスト配信できる。
【0074】
図12は必要PIDの一例の構成図である。図12に示すように、必要PIDはIPTV対応プレイヤ14の動作に応じて必要となるMPEG2−TTSパケットのPIDを指定するものである。例えば図12の例ではPIDが0x0001、0x0024、0x0010、0x0012のMPEG2−TTSパケットが必要なことを示している。
【0075】
IPTV対応プレイヤ14から受信した図12の必要PIDにより、無線/有線LANゲートウェイ12の必要PIDテーブルは書き換えられる。したがって、無線/有線LANゲートウェイ12は、IPTV対応プレイヤ14側の状況に応じた対応を行うことができる。
【0076】
無線/有線LANゲートウェイ12は、IPTV対応プレイヤ14側の状況の変化に応じて必要となるMPEG2−TTSパケットのPIDを必要PIDとして受信することにより、不要なMPEG2−TTSパケットを削除し、必要なMPEG2−TTSパケットをマルチキャスト配信できる。
【0077】
図10のコンテンツを配信するシステムは必要性規則テーブル86、PIDパケット種別対応テーブル87をIPTV対応プレイヤ14側に有している。図10のコンテンツを配信するシステムはIPTV対応プレイヤ14側でRTPマルチキャストストリームを解析して、IPTV対応プレイヤ14側の状況の変化に応じて必要となるMPEG2−TTSパケットのPIDを必要PIDとして無線/有線LANゲートウェイ12に要求することができる。
【0078】
図13は複数のIPTV対応プレイヤに対応する必要性規則テーブルの一実施例の構成図である。図13の必要性規則テーブルは図9の必要性規則テーブルの必要情報をIPTV対応プレイヤ14毎に管理するように拡張した例である。図13の必要性規則テーブルはIPTV対応プレイヤ14が増えた場合、列を増やすことで対応できる。
【0079】
図13の必要性規則テーブルはIPTV対応プレイヤ14を識別するための情報を持つことが必要である。IPTV対応プレイヤ14を識別する方法は一般的に使用されている方法でよい。例えば図13の必要性規則テーブルは機器ID(deviceid)が「2001::1」のIPTV対応プレイヤ14と機器IDが「2001::2」のIPTV対応プレイヤ14とに対応する必要情報を表している。なお、図13の必要性規則テーブルは、どちらか一方が必要を表す「True」になっている場合、必要を意味する。
【0080】
例えば図3のコンテンツを配信するシステムではIPTV対応プレイヤ14を識別する情報を、例えば図14に示すように必要情報を拡張して通知する。図14は複数のIPTV対応プレイヤに対応する必要情報の一例の構成図である。図14の必要情報では図8の必要情報に加えて、deviceidと呼ばれる属性を設定し、そのdeviceid属性にIPTV対応プレイヤ14を識別するための情報の一例としてIPTV対応プレイヤ14のIPv6アドレスを使用している。なお、IPv6アドレスは他の機器と重複することがない。その他、IPTV対応プレイヤ14を識別するための情報はMACアドレスを使用してもよい。
【0081】
また、図10のコンテンツを配信するシステムではIPTV対応プレイヤ14を識別する情報を、例えば図12に示すPID情報を拡張して通知する。図12に示すPID情報を拡張して、IPTV対応プレイヤ14を識別する情報を通知する場合は、例えばdeviceid属性を設定するなど同様に拡張して、必要PIDテーブルにIPTV対応プレイヤ14ごとのPIDを記憶すればよい。
【0082】
このように、図3及び図10のコンテンツを配信するシステムは、複数のIPTV対応プレイヤ14がホームネットワーク上に存在する場合であっても、適切に動作することができる。
【0083】
図15は複数のチャンネル(コンテンツストリーム)に対応する必要性規則テーブルの一実施例の構成図である。図15の必要性規則テーブルは、図13の必要性規則テーブルの必要情報をIPTV対応プレイヤ14及びチャンネル毎に管理するように拡張した例である。
【0084】
複数のIPTV対応プレイヤ14が存在する場合、各IPTV対応プレイヤ14は異なるチャンネルを表示している状況がある。また、IPTV対応プレイヤ14が一つしか存在しない場合であっても、別々のチャンネルを同時に録画及び表示する場合もある。このような場合、図15の必要性規則テーブルはIPTV対応プレイヤ14及びチャンネルに対応する列を増やすことで対応できる。
【0085】
図15の必要性規則テーブルは、チャンネルを識別するための情報を持つことが必要である。チャンネルを識別する方法は一般的に使用されている方法でよい。例えばチャンネルを識別する方法は、ソースアドレスと呼ばれるRTP配信要求をする際に指定されるIPアドレスを使用することが容易である。ソースアドレスは、実際に配信されているRTPマルチキャストストリームのヘッダ部を見ることでも確認できる。IPTV対応プレイヤ14が指定して配信要求をするため、無線/有線LANゲートウェイ12及びIPTV対応プレイヤ14はソースアドレスで一意にチャンネルを識別できる。
【0086】
例えば図15の必要性規則テーブルは、IPTV対応プレイヤ14及びチャンネル毎に対応する必要情報を表している。なお、図15の必要性規則テーブルは、何れかが必要を表す「True」になっている場合、必要を意味する。言い換えれば、IPTV対応プレイヤ14及びチャンネルの組み合わせの何れかが必要である情報はマルチキャスト配信される。
【0087】
例えば図3のコンテンツを配信するシステムではチャンネルを識別するための情報を例えば図16に示すように必要情報を拡張して通知する。図16は複数のIPTV対応プレイヤ及びチャンネルに対応する必要情報の一例の構成図である。図16の必要情報では図14の必要情報に加えて、channelidと呼ばれる属性を設定し、そのchannelid属性にチャンネルを識別するための情報の一例としてソースアドレスを使用している。なお、チャンネルを識別するための情報はソースアドレス以外を使用してもかまわない。
【0088】
以上、本実施例のコンテンツを配信するシステムによれば、IPTV対応プレイヤ14で不要なMPEG2−TTSパケットを無線/有線LANゲートウェイ12で取り除いて配信できるので、ホームネットワークで使用する帯域を減らすことができる。
【0089】
また、本実施例のコンテンツを配信するシステムによれば、ユーザのIPTV対応プレイヤ14の使用状況に応じて必要なMPEG2−TTSパケットを自動的に判定し、動的に配信するMPEG2−TTSパケットを変更するため、ユーザは負担を感じない。
【0090】
また、本実施例のコンテンツを配信するシステムは、PIDとパケット種別との対応づけを行うため、PIDが固定でない場合にも利用できる。また、本実施例のコンテンツを配信するシステムは、複数のIPTV対応プレイヤ14が存在しても、必要性規則テーブルを変更することにより、対応することができる。さらに、本実施例のコンテンツを配信するシステムは、複数のチャンネルが存在し、複数のチャンネルを同時に利用する場合であっても、必要性規則テーブルを変更することにより、対応することができる。
【0091】
なお、本実施例のコンテンツを配信するシステムのホームネットワークにおける帯域の削減効果は、通常のテレビ放送を基準とすると以下のようになる。例えばマルチ編成として複数(2〜3)の番組がひとつのRTPマルチキャストストリームに含まれる場合にはホームネットワークにおける帯域を1/3程度に削減できる。また、通常のテレビ放送において、データ放送のデータは最大1割程度含まれる。データ放送が不要なとき、データ放送のデータを削減することで、ホームネットワークにおける帯域は最大1割程度、削減できる。
【0092】
また、マルチビューとよばれる複数の映像がひとつのRTPマルチキャストストリームに含まれる場合には、ひとつの映像にすることで、ホームネットワークにおける帯域を最大1/2程度に削減できる。さらに、IPTV対応プレイヤ14で予約録画をしている場合には番組の時間変更を確認するため、SI情報(番組情報)が必要となる。このような場合は、映像・音声・データ放送のデータをすべて削減できるため、ホームネットワークにおける帯域を9割以上、削減できる。
【0093】
本発明は、以下に記載する付記のような構成が考えられる。
(付記1)
受信した複数種類のデータをネットワークに配信するデータ配信装置によって実行されるデータ配信方法であって、
前記ネットワークに配信した前記データを受信する受信機から、必要なデータの種類を必要情報として受信し、
前記受信したデータの種類を解析し、
前記受信したデータを前記必要情報に基づき前記必要なデータの種類で再構築し、
前記再構築したデータを前記ネットワークに配信する
ことを特徴とするデータ配信方法。
(付記2)
前記受信したデータを前記必要情報に基づき前記必要なデータの種類で再構築する処理は、前記必要情報に基づき変更される記憶部に記憶された前記必要なデータの種類を表すテーブルに従って、前記受信したデータを前記必要なデータの種類で再構築する
ことを特徴とする付記1記載のデータ配信方法。
(付記3)
前記テーブルは前記受信機ごとに、前記必要なデータの種類を表す
ことを特徴とする付記2記載のデータ配信方法。
(付記4)
前記テーブルは前記受信機及び前記受信機で選択可能なチャンネルごとに、前記必要なデータの種類を表す
ことを特徴とする付記2記載のデータ配信方法。
(付記5)
必要なデータの種類を必要情報として受信する処理は、前記必要情報として前記データの識別子を受信し、
前記受信したデータの種類を解析する処理は、前記データの識別子を解析し、
前記受信したデータを前記必要情報に基づき前記必要なデータの種類で再構築する処理は、前記受信したデータの識別子と前記必要情報として受信した前記データの識別子とに基づき、前記必要情報として受信した前記識別子のデータで前記受信したデータを再構築する
ことを特徴とする付記3又は4記載のデータ配信方法。
(付記6)
必要なデータの種類を必要情報として受信する処理は、前記必要情報として前記データの種別を受信し、
前記受信したデータの種類を解析する処理は、前記データの識別子を解析し、
前記受信したデータを前記必要情報に基づき前記必要なデータの種類で再構築する処理は、前記受信したデータの識別子と前記必要情報として受信した前記データの種別とに基づき、前記必要情報に基づき変更される記憶部に記憶された前記必要なデータの種別と前記データの識別子とを対応づけるテーブルに従って、前記必要情報として受信した前記種別のデータで前記受信したデータを再構築する
ことを特徴とする付記3又は4記載のデータ配信方法。
(付記7)
受信した複数種類のデータをネットワークに配信するデータ配信装置であって、
前記ネットワークに配信した前記データを受信する受信機から、必要なデータの種類を必要情報として受信する受信手段と、
前記受信したデータの種類を解析する解析手段と、
前記受信したデータを前記必要情報に基づき前記必要なデータの種類で再構築する再構築手段と、
前記再構築したデータを前記ネットワークに配信する配信手段と
を有することを特徴とするデータ配信装置。
(付記8)
受信した複数種類のデータをネットワークに配信するデータ配信装置に、
前記ネットワークに配信した前記データを受信する受信機から、必要なデータの種類を必要情報として受信し、
前記受信したデータの種類を解析し、
前記受信したデータを前記必要情報に基づき前記必要なデータの種類で再構築し、
前記再構築したデータを前記ネットワークに配信する
処理を実行させるデータ配信プログラム。
【0094】
本実施例におけるデータ配信プログラムは、パッケージソフトの他、WEBサービス等によっても提供可能である。なお、上記の特許請求の範囲に記載した記憶部は例えばRAM63に相当し、受信手段は例えば必要情報受信部40に相当し、解析手段はMPEG解析部34に相当し、再構築手段はRTP再構築部38に相当し、配信手段はマルチキャスト配信部39に相当する。
【符号の説明】
【0095】
1 システム
10 IPTV用サーバ
11 Webサーバ
12 無線/有線LANゲートウェイ
13 PC
14、21 IPTV対応プレイヤ
15、16 ネットワーク
31、71 マルチキャスト送信部
32、72 マルチキャスト受信部
33、73、91 RTP解析部
34 MPEG解析部
35、93 PIDパケット種別対応テーブル更新部
36、84 PID必要性対応づけ実施部
37、76 パケット蓄積部
38、77 RTP再構築部
39、78 マルチキャスト配信部
40 必要情報受信部
41、83 必要性規則変更部
42、87 PIDパケット種別対応テーブル記憶部
43、86 必要性規則テーブル記憶部
44、81 MPEG2−TTSパケット記憶部
45、88 録画部
46、89 表示部
47、90 制御部
48、82 必要情報判定部
49 必要情報通知部
50、94 マルチキャスト受信部
61 CPU
62 ROM
63 RAM
64 第1インタフェース(I/F)
65 第2インタフェース(I/F)
66 I/O
67 表示部
68 キー部
74 MPEG2ヘッダ解析部
75 PID判定部
79 必要PID受信部
80 必要PIDテーブル記憶部
85 必要PID送信部
92 MPEG2解析部

【特許請求の範囲】
【請求項1】
受信した複数種類のデータをネットワークに配信するデータ配信装置によって実行されるデータ配信方法であって、
前記ネットワークに配信した前記データを受信する受信機から、必要なデータの種類を必要情報として受信し、
前記受信したデータの種類を解析し、
前記受信したデータを前記必要情報に基づき前記必要なデータの種類で再構築し、
前記再構築したデータを前記ネットワークに配信する
ことを特徴とするデータ配信方法。
【請求項2】
前記受信したデータを前記必要情報に基づき前記必要なデータの種類で再構築する処理は、前記必要情報に基づき変更される記憶部に記憶された前記必要なデータの種類を表すテーブルに従って、前記受信したデータを前記必要なデータの種類で再構築する
ことを特徴とする請求項1記載のデータ配信方法。
【請求項3】
前記テーブルは前記受信機ごとに、前記必要なデータの種類を表す
ことを特徴とする請求項2記載のデータ配信方法。
【請求項4】
前記テーブルは前記受信機及び前記受信機で選択可能なチャンネルごとに、前記必要なデータの種類を表す
ことを特徴とする請求項2記載のデータ配信方法。
【請求項5】
受信した複数種類のデータをネットワークに配信するデータ配信装置であって、
前記ネットワークに配信した前記データを受信する受信機から、必要なデータの種類を必要情報として受信する受信手段と、
前記受信したデータの種類を解析する解析手段と、
前記受信したデータを前記必要情報に基づき前記必要なデータの種類で再構築する再構築手段と、
前記再構築したデータを前記ネットワークに配信する配信手段と
を有することを特徴とするデータ配信装置。
【請求項6】
受信した複数種類のデータをネットワークに配信するデータ配信装置に、
前記ネットワークに配信した前記データを受信する受信機から、必要なデータの種類を必要情報として受信し、
前記受信したデータの種類を解析し、
前記受信したデータを前記必要情報に基づき前記必要なデータの種類で再構築し、
前記再構築したデータを前記ネットワークに配信する
処理を実行させるデータ配信プログラム。

【図1】
image rotate

【図2】
image rotate

【図3】
image rotate

【図4】
image rotate

【図5】
image rotate

【図6】
image rotate

【図7】
image rotate

【図8】
image rotate

【図9】
image rotate

【図10】
image rotate

【図11】
image rotate

【図12】
image rotate

【図13】
image rotate

【図14】
image rotate

【図15】
image rotate

【図16】
image rotate


【公開番号】特開2012−119741(P2012−119741A)
【公開日】平成24年6月21日(2012.6.21)
【国際特許分類】
【出願番号】特願2010−264997(P2010−264997)
【出願日】平成22年11月29日(2010.11.29)
【出願人】(000005223)富士通株式会社 (25,993)
【Fターム(参考)】