トップ :: H 電気 :: H04 電気通信技術




【発明の名称】 映像信号受信装置
【発明者】 【氏名】宮地 悟史

【氏名】松本 修一
【要約】 【課題】RF受信できる信号形式が保たれてIP再送信された放送番組とIP網専用番組の双方に対応できる統合的な映像信号受信装置を提供すること。

【構成】IP再送信による放送番組とIP網専用番組の一部情報について共通化されたプロトコルスタックが設定されている１つのIPネットワークインタフェース11でIP再送信による放送番組とIP網専用番組を受ける。IP再送信による放送番組とIP網専用番組のTSパケットは、バッファ12,14とエラー訂正部13,15を介してデクリプタ16,17に入力され、ICカード18,19からの鍵で復号される。デマルチプレクサ20は、多重分離処理により各エレメンタリストリーム(ES)を分離して取り出す。デコーダ21,22は、各ESをデコードする。マルチメディアデータは、ブラウザ23で画面イメージ信号に変換され、加算器24でビデオ信号に重畳される。
【特許請求の範囲】
【請求項１】
ＲＦ受信できる信号形式が保たれてＩＰ再送信された放送番組およびＩＰ網専用番組を受ける１つのＩＰネットワークインタフェースと、
前記ＩＰネットワークインタフェースからＩＰ再送信による放送番組およびＩＰ網専用番組のＴＳパケットのそれぞれに対し誤り訂正処理を行う複数のエラー訂正部と、
前記複数のエラー訂正部の各々に接続され、各エラー訂正部から入力されるＴＳパケットの暗号復号処理を行う複数の暗号復号処理部と、
前記複数の暗号復号処理部の各々に対応して設けられ、暗号復号処理のための鍵を取得し、該鍵を対応する暗号復号処理部に与える複数の鍵供給部と、
前記複数の暗号復号処理部で暗号復号処理されたＴＳパケットを入力とし、ＴＳパケットの多重分離処理を行う１つのＴＳパケット多重分離部と、
前記ＴＳパケット多重分離部により分離された各エレメンタリストリームをデコードする復号部と、
前記ＴＳパケット多重分離部により分離されたマルチメディアデータを画面イメージ信号に変換するマルチメディアデータ変換部を備え、
前記ＩＰネットワークインタフェースは、同一ＩＰ上に構築され、ＩＰ再送信による放送番組およびＩＰ網専用番組の一部情報について共通化されたプロトコルスタックに従ってＩＰ再送信による放送番組およびＩＰ網専用番組を受けることを特徴とする映像信号受信装置。
【請求項２】
前記プロトコルスタックは、マルチメディアデータと限定受信のための視聴者ごとの契約情報とを除く情報について共通化されていることを特徴とする請求項１に記載の映像信号受信装置。
【請求項３】
前記複数のエラー訂正部と複数の暗号復号処理部の各々からなる複数の受信系統により、エラー訂正方式やそのパラメータが異なる、あるいは暗号化化方式が異なる幾つかの形式のパケットの受信に対応可能であることを特徴とする請求項１または２に記載の映像信号受信装置。
【請求項４】
前記復号部は、符号化方式が異なる幾つかの形式のパケットの受信に対応可能であることを特徴とする請求項１ないし３のいずれかに記載の映像信号受信装置。
【発明の詳細な説明】【技術分野】
【０００１】
本発明は、映像信号受信装置に関し、特に、IP再送信された放送番組および通信事業者などにより独自に制作されたIP網専用番組を受ける映像信号受信装置に関する。
【背景技術】
【０００２】
IPネットワークの普及に伴い、TV番組をIPネットワークを通して配信するIPTVによる番組配信サービスが行われるようになった。日本でのIPTVでは、ビデオオンデマンド(VOD)に加え、IPマルチキャストによるテレビ配信サービスが行われているが、法制度の問題などもあり、現在は通信事業者などのIPTVオペレータにより独自に制作されたIP網専用番組だけがIP上で配信許可されているという状況である。
【０００３】
このため、放送番組は、依然RF信号での受信(RF受信)によることとなり、映像信号受信装置は、IP網専用番組を受けるIPネットワークインターフェースの他、RF受信のためのRFインタフェース、つまりRFチューナを備えることが必要である。
【０００４】
図４は、IPネットワークインターフェースおよびRFチューナを備えた映像信号受信装置のアーキテクチャを示すブロック図である。以下では、映像信号受信装置をセットトップボックス(STBと記す)とし、IPネットワークインターフェースおよびRFチューナを備えた構成をハイブリッド型STBアーキテクチャと称する。
【０００５】
図４の上側部分は、放送番組をRF受信する受信系統である。RFチューナ41は、アンテナからのRF信号を受信し、MPGE-2 TS(transport stream)パケットを復調し、デクリプタ16に送る。デクリプタ16は、放送用ICカード18から送出されるスクランブル鍵KＳ１を用いてTSパケットを復号し、復号したTSパケットをデマルチプレクサ20に送る。すなわち、MPEG-2 TV信号(RF信号)のTSパケットは、RFチューナ41で復調され、デクリプタ16で復号される。なお、放送番組を伝送するためのTSパケットの形態は、MPEG-2システム規格(ISO/IEC 13813-1)や電波産業会(ARIB)の仕様の中で規定されている。
【０００６】
デマルチプレクサ20は、TSパケットを多重分離処理する。デマルチプレクサ20からはオーディオパケットおよびビデオパケットがエレメンタリストリーム(ES)として取り出され、さらにデータカルーセルにより繰り返し伝送されているマルチメディア(BML:broadcast markup language)データが取り出される。BMLデータは、データ放送における文字や図形情報などのグラフィック情報を含む。
【０００７】
デマルチプレクサ20から出力されるオーディオパケットは、オーディオデコーダ21に渡されてオーディオ信号に再生され、ビデオパケットは、ビデオデコーダ22に渡されてビデオ信号に再生される。また、マルチメディアデータは、ブラウザ23に渡されて画面イメージ信号に変換される。この画面イメージ信号は、加算部24でビデオデコーダ22からのビデオ信号に重畳されて出力される。
【０００８】
放送番組の限定受信(CAS:conditional access system)を制御するためのECM,EMMは、RFチューナ41を経由して受信され、デマルチプレクサ20から取り出される。ECMは、番組ごとの番組属性情報を含み、EMMは、視聴者ごとの契約情報を含む。なお、デクリプタ16は、スクランブル鍵KＳ１が与えられなければ、入力をそのまま出力する。デマルチプレクサ20から取り出されたECM,EMMは、放送用ICカード18に送られる。
【０００９】
放送用ICカード18は、デマルチプレクサ20から出力されるECM,EMMおよびICカードごとに固有のマスタ鍵を用いてスクランブル鍵KＳ１を生成し、デクリプタ16に送る。
【００１０】
図４の下側部分は、IP網専用番組を受信する受信系統である。IPネットワークインタフェース42は、IP網専用番組のIPマルチキャストパケットを受信し、それから取り出したTSパケットをバッファ14およびエラー訂正部15を介してデクリプタ17に送る。
【００１１】
IP網専用番組の受信手順は、基本的には、TSパケットを伝送するRF信号がIPパケットに置き換えられている以外は放送番組の受信手順と同じである。しかし、放送番組とIP網専用番組とではBMLデータおよびEMMの通信形態に差異があり、この差異により両者の受信処理に差異が生じる。BMLデータおよびEMMは、リクエストに従ってIPネットワークインタフェース41から取り出され、それぞれブラウザ23およびIPTV用ICカード19に送られる。
【００１２】
図５は、ハイブリッド型STBで使用されるプロトコルスタックを示す。上述のように、放送番組とIP網専用番組とではBMLデータおよびEMMの通信形態に差異があるので、ハイブリッド型STBでは、放送番組の受信ならびにIP網専用番組の受信のそれぞれに適するようプロトコルスタックを個別に設定する。これにより、IP網上でしか伝送されないIP網専用番組では、データカルーセルによる繰り返し伝送が不要となるなど、IP網を利用することのメリットを最大限活用して効率化が可能となる。
【００１３】
以上のとおり、ハイブリッド型STBアーキテクチャでは、放送番組の配信を受けるためのプロトコルスタック(以下、放送ポーションと称する）とIP網専用番組の配信を受けるためのプロトコルスタック(以下、IPポーションと称する）とが別個に共存する。
【発明の開示】
【発明が解決しようとする課題】
【００１４】
電波として配信された放送番組を一旦受信してサーバでIPパケットに変換し、IP網上に配信するIP再送信については、制度面や技術面で様々な検討が行われており、近い将来、サービスが開始される可能性が高い。
【００１５】
その際、IP再送信による放送番組を受ける枠組みとして、ハイブリッド型STBにおけるIPポーションを利用するのが望ましいと考えるのが普通である。しかしながら、ハイブリッド型STBにおけるIPポーションは、電波で配信される放送番組を受けることは考慮しておらず、IP網上のみで伝送されるIP網専用番組だけを受けるように考慮した仕様であるで、IP再送信による放送番組の受信には適用が難しいという問題がある。
【００１６】
放送番組は、STBを用いずにRF信号の放送番組をテレビ受信機で直接受信するケース、ならびにIP再送信による放送番組をIP網を経由して受信するケースの双方に対応可能な仕様、つまりRF受信できる信号形式が保たれてIP再送信が行われることが要求される。これは、IP再送信の場合、RF信号の場合には無く、IP網上での通信の場合のみに存在する利点を有効に利用できないことを意味する。
【００１７】
本発明の目的は、RF受信できる信号形式が保たれてIP再送信された放送番組およびIP網専用番組の双方に対応できる統合的な映像信号受信装置を提供することにある。
【課題を解決するための手段】
【００１８】
上記課題を解決するため、本発明は、RF受信できる信号形式が保たれてIP再送信された放送番組およびIP網専用番組を受ける１つのIPネットワークインタフェースと、前記IPネットワークインタフェースからIP再送信による放送番組およびＩＰ網専用番組のTSパケットのそれぞれに対し誤り訂正処理を行う複数のエラー訂正部と、前記複数のエラー訂正部の各々に接続され、各エラー訂正部から入力されるTSパケットの暗号復号処理を行う複数の暗号復号処理部と、前記複数の暗号復号処理部の各々に対応して設けられ、暗号復号処理のための鍵を取得し、該鍵を対応する暗号復号処理部に与える複数の鍵供給部と、前記複数の暗号復号処理部で暗号復号処理されたTSパケットを入力とし、TSパケットの多重分離処理を行う１つのTSパケット多重分離部と、前記TSパケット多重分離部により分離された各エレメンタリストリームをデコードする復号部と、前記TSパケット多重分離部により分離されたマルチメディアデータを画面イメージ信号に変換するマルチメディアデータ変換部を備え、前記IPネットワークインタフェースは、同一IP上に構築され、IP再送信による放送番組およびIP網専用番組の一部情報について共通化されたプロトコルスタックに従ってIP再送信による放送番組およびIP網専用番組を受ける点に第１の特徴がある。
【００１９】
また、本発明は、前記プロトコルスタックは、マルチメディアデータと限定受信のための視聴者ごとの契約情報とを除く情報について共通化されている点に第２の特徴がある。
【００２０】
また、本発明は、前記複数のエラー訂正部と複数の暗号復号処理部の各々からなる複数の受信系統により、エラー訂正方式やそのパラメータが異なる、あるいは暗号化化方式が異なる幾つかの形式のパケットの受信に対応可能である点に第３の特徴がある。
【００２１】
さらに、本発明は、前記復号部が、符号化方式が異なる幾つかの形式のパケットの受信に対応可能である点に第４の特徴がある。
【発明の効果】
【００２２】
本発明によれば、ブロードバンドネットワークを用いた映像配信サービスにおいて、RF受信できる信号形式が保たれてIP再送信された放送番組およびIP網専用番組の双方に対応できる統合的な映像信号受信装置を実現することができる。
【発明を実施するための最良の形態】
【００２３】
以下、図面を参照して本発明を説明する。図１は、本発明に係る映像信号受信装置の一実施形態のアーキテクチャを示すブロック図であり、本映像信号受信装置もSTBとして構成されている。なお、図４と同一あるいは同等部分には同じ符号を付してある。
【００２４】
本発明に係る映像信号受信装置は、１つのIPネットワークインタフェースを備え、RF受信できる信号形式が保たれてIP再送信された放送番組とIP網専用番組の双方に対応できるアーキテクチャを有する。この映像信号受信装置の構成は、オールIPモノリシック型STBアーキテクチャと呼ぶことができる。
【００２５】
図１において、IPネットワークインタフェース11は、RF受信できる信号形式が保たれてIP再送信された放送番組およびIP網専用番組のIPパケットを受信してTSパケットを取り出し、IP再送信による放送番組のTSパケットをバッファ12およびエラー訂正部13を介してデクリプタ16に送出し、IP網専用番組のTSパケットをバッファ14およびエラー訂正部15を介してデクリプタ17に送出する。ここでのTSパケットは暗号化されている。
【００２６】
なお、エラー訂正部13,14を別個に設けているのは、IP再送信による放送番組とIP網専用番組とではサービスで要求される品質が異なるためである。要求される品質条件により、パケットロスに対する耐性や遅延量への要求値はそれぞれ異なることとなる。このように、エラー訂正部を別個に設けることにより、それぞれの要求条件に応じたエラー訂正方式あるいはエラー訂正パラメータを用いることが可能となる。なお、一般には、IP網専用番組よりIP再送信による放送番組で要求される品質の方が高い。
【００２７】
デクリプタ16は、放送用ICカード18から送出されるスクランブル鍵KＳ１を用いてTSパケットを復号し、デクリプタ17は、IPTV用ICカード19から送出されるスクランブル鍵KＳ２を用いてTSパケットを復号する。
【００２８】
デマルチプレクサ20は、デクリプタ16,17で復号されたTSパケットを入力とし、多重分離処理する。デマルチプレクサ20からはオーディオパケットおよびビデオパケットがエレメンタリストリーム(ES)として取り出される。IP再送信による放送番組では、さらにデータカルーセルにより繰り返し伝送されているマルチメディア(BML)データがデマルチプレクサ20から取り出されるが、IP網専用番組ではリクエストに従ってIPネットワークインタフェース11から取り出される。
【００２９】
デマルチプレクサ20から出力されるオーディオパケットは、オーディオデコーダ21に渡されてオーディオ信号に再生され、ビデオパケットは、ビデオデコーダ22に渡されてビデオ信号に再生される。また、マルチメディアデータは、ブラウザ23に渡されて画面イメージに変換される。この画面イメージ信号は、加算部24でビデオデコーダ22からのビデオ信号に重畳されて出力される。
【００３０】
IP再送信による放送番組の限定受信(CAS)を制御するためのECM,EMMは、IPネットワークインタフェース11を経由して受信され、デマルチプレクサ20から取り出される。なお、デクリプタ16は、スクランブル鍵KＳ１が与えられなければ、入力をそのまま出力側に転送する。デマルチプレクサ20から取り出されたECM,EMMは、放送用ICカード18に送られる。
【００３１】
放送用ICカード18は、デマルチプレクサ20から出力されるECM,EMMおよびICカードごとに特有のマスタ鍵を用いてスクランブル鍵KＳ１を生成し、デクリプタ16に与える。
【００３２】
一方、IP再送信による放送番組の限定受信(CAS)を制御するためのECMは、デマルチプレクサ20から取り出されてIPTV用ICカード19に送られるが、EMMは、IPネットワークインタフェース11から取り出されてIPTV用ICカード19に送られる。
【００３３】
IPTV用ICカード19は、デマルチプレクサ20から出力されるECM、IPネットワークインタフェース11から出力されるEMMおよびICカードごとに固有のマスタ鍵を用いてスクランブル鍵KＳ２を生成し、デクリプタ14に送出する。
【００３４】
図２は、限定受信(CAS)を制御するための暗号化および復号での処理を示すブロック図である。送信側では、第１暗号化部31で番組信号(TSパケット)をスクランブル鍵KＳにより暗号化し、暗号化された番組信号を生成する。また、第２暗号化部32でスクランブル鍵KＳおよび番組属性情報をワーク鍵KＷにより暗号化し、ECMを生成する。番組属性情報は、番組ごとの情報であり、番組の有料/無料を示す情報、番組に対する視聴料金などが含まれる。
【００３５】
さらに、第３暗号化部33でワーク鍵KＷおよび視聴者ごとの契約情報をICカードごとに固有のマスタ鍵Kｍにより暗号化し、EMMを生成する。視聴者ごとの契約情報には、契約チャンネルや契約有効期限などが含まれる。以上により生成された暗号化された番組信号、ECMおよびEMMは、多重化され、IPパケットとして送信側からIP網を通して受信側に伝送される。
【００３６】
受信側では、暗号化された番組信号を第１復号部34に送り、ECM、EMMをそれぞれ第２復号部35、第３復号部36に送る。第３復号部36は、予めICカード内に保持されているマスタ鍵Kｍを用いてEMMを復号し、ワーク鍵KＷおよび視聴者ごとの契約情報を生成する。また、視聴者が未契約の場合には、契約を促すメッセージなどのEMMメッセージを生成することもできる。
【００３７】
第３復号部36で復号されたワーク鍵KＷは、第２復号部35に送られ、視聴者ごとの契約情報は、視聴可否判定部37に送られる。また、EMMメッセージは第１復号部34の出力側に送られる。
【００３８】
第２復号部35は、ワーク鍵KＷを用いてECMを復号し、スクランブル鍵KＳおよび番組属性情報を生成する。復号されたスクランブル鍵KＳは、第１復号部34に送られ、視聴者ごとの契約情報は、視聴可否判定部37に送られる。
【００３９】
視聴可否判定部37は、視聴者ごとの契約情報および番組属性情報に基づいて当該番組の視聴可否を判定し、この判定結果に従って第１および第２復号部34,35間に配設されたスイッチ部38を制御する。すなわち、無料の番組であれば視聴者ごとの契約情報にかかわらず、スイッチ部38はオンとなるが、有料の番組であれば該番組に対する契約が有効である視聴者ICカードである場合にスイッチ部38がオンとなる。
【００４０】
第１復号部24は、スクランブル鍵KＳが与えられると、送信側から送られた番組信号を復号し、復号された番組信号を送出する。
【００４１】
図３は、図１のアーキテクチャで使用できるプロトコルスタックを示す。図３に示すプロトコルスタックでは、IP網専用番組を扱う部分(IPポーション)とIP再送信による放送番組を扱う部分(放送ポーション)を同じIP上に構築している。
【００４２】
ここで、IPポーションは、図５のIPポーションと全く同じである。一方、放送ポーションは、番組を構成する一部情報についてIPポーションと共通化が図られている。図３では、BMLデータとEMMとを除く情報について共通化を図っており、これは最大限の共通化である。ビデオやオーディオといったストリームメディアは、現在送信されている瞬間のものを受信し再生すればよいが、BMLデータは１つのデータセットを受信開始タイミングにかかわらず確実に取得することが必要であること、また、EMMについては、受信装置に個別な情報を確実に取得する必要があること、から放送ポーションとIPポーションとで共通化が難しい部分となっている。このBMLデータとEMMは、放送番組とIP網専用番組とで通信形態に下記(1),(2)の差異がある。
【００４３】
(1)放送番組では、BMLデータは、RF受信では必ずしもデータセットの先頭から受信できるとは限らないので、MPEG-2 TSデータカルーセルにより繰り返し配信され、１つのデータセットが構築できるまでの１周期の間、受信を続ける。この方式では、受信者の存在有無とは独立に、一定の時間の中で繰り返し配信が続けられる。一方、IP網専用番組では、BMLデータは、効率の点からTCPユニキャストにより配信され、受信側での受信開始時に必ずデータセットの先頭から伝送されるよう送信側で制御することが可能である。このため、受信側で必要とされるタイミングで、必要とされる情報だけを効率よく伝送することが可能である。
【００４４】
(2)放送番組では、EMMは、セクション化されたMPEG-2 TSにより配信され、自受信装置向け以外の契約情報も配信されるので、受信側でのフィルタリングが必要である。一方、IP網専用番組では、EMMは、効率の点からTCPユニキャストにより伝送され、それぞれの受信装置に対して個別に情報が伝送されるので、受信側でのフィルタリングは不要である。
【００４５】
上記(1),(2)の差異を考慮し、BMLデータおよびEMMについてのプロトコルスタックは、放送ポーションとIPポーションとで異なっている。すなわち、BMLデータおよびEMMは、IPポーションでは、HTTPを使ってセキュア(暗号化)通信手順(TLS/SSL)によりTCP/IP上で通信されるものとなっているが、放送ポーションでは、セクション化(section)およびMPEG-2 TSパケット化されてRTP/UDP/IP上で配信されるようにする。なお、放送ポーションであっても、BMLデータのうちカルーセルによる繰り返し伝送を行う必要がないものは、PES化およびMPEG-2 TSパケット化されてRTP/UDP/IP上で配信されるようにする。IPポーションのSDP/RTSPは、ビデオオンデマンド(VOD)のリクエストを通信するコマンドであり、TLS/SSLによりTCP/IP上で配信されるものとなっている。
【００４６】
オーディオパケットおよびビデオパケット(Audio/Video)、限定受信(CAS)のためのECMおよびパケットID番号とメディア(Audio/Video/Multimedia)の対応関係を示す情報などの多重制御情報PSI(Program Specific Information)/電子番組表を示すSI(Service Information)については、放送ポーションをIPポーションと共通化している。すなわち、IP再送信による放送番組およびIP専用番組とも、Audio/Videoは、PES化およびMPEG-2 TSパケット化されてRTP/UDP/IP上で配信され、ECMおよびPSI/SIは、section化およびMPEG-2 TSパケット化されてRTP/UDP/IP上で配信される。
【００４７】
以上によれば、RF受信できる信号形式を変えることなくIP再送信された放送番組およびIP網専用番組をただ１つのIPネットワークインターフェースで受けることができる。
【００４８】
以上、実施形態について説明したが、本発明は、上記実施形態に限定されない。例えば、上記実施形態ではバッファ、エラー訂正部およびデクリプタからなる受信系統を２つとしたが、番組によってはエラー訂正方式や暗号化化方式が異なる幾つかの形式のパケットが送られる場合がある。このような場合には、それらを処理する受信系統を個別に設けたり、デクリプタでの暗号復号処理を選択的に切り替えられるようにしたりすることで対応できる。また、符号化方式が異なるパケットに対しても複数のデコーダを設けたり、デコーダ内での処理を切り換えたりすることで対応できる。
【００４９】
また、他の実施形態としては、IPプロトコルスタックの中にエラー訂正機能を持たせ、IPパケットレベルでエラー訂正を行った後、TSパケットを出力することも可能である。
【００５０】
なお、オールIPモノリシック型STBにおいては、複数のCASシステムを同時に扱う必要があることなどから、セキュリティプロセッサをベースとしたDownloadable CASを用いるのが望ましい。
【図面の簡単な説明】
【００５１】
【図１】本発明に係る映像受信装置の一実施形態のアーキテクチャを示すブロック図である。
【図２】限定受信(CAS)を制御するための暗号化および復号での処理を示すブロック図である。
【図３】図１のアーキテクチャで使用できるプロトコルスタックを示す説明図である。
【図４】IPネットワークインターフェースおよびRFチューナを備えた映像信号受信装置のアーキテクチャを示すブロック図である。
【図５】図４のアーキテクチャで使用されるプロトコルスタックを示す説明図である。
【符号の説明】
【００５２】
11,42・・・IPネットワークインタフェース、12,14・・・バッファ、13,15・・・エラー訂正部、16,17・・・デクリプタ、18・・・放送用ICカード、19・・・IPTV用ICカード、20・・・デマルチプレクサ、21・・・オーディオデコーダ、22・・・ビデオデコーダ、23・・・ブラウザ、24・・・加算部、31,32,33・・・暗号化部、34,35,36・・・復号部、37・・・視聴可否判定部、38・・・スイッチ部、41・・・RFチューナ
【出願人】 【識別番号】０００２０８８９１
【氏名又は名称】ＫＤＤＩ株式会社
【出願日】 平成１８年７月６日（２００６．７．６）
【代理人】 【識別番号】１０００８４８７０
【弁理士】
【氏名又は名称】田中 香樹

【識別番号】１０００７９２８９
【弁理士】
【氏名又は名称】平木 道人

【識別番号】１００１１９６８８
【弁理士】
【氏名又は名称】田邉 壽二
【公開番号】 特開２００８−１７２０７（Ｐ２００８−１７２０７Ａ）
【公開日】 平成２０年１月２４日（２００８．１．２４）
【出願番号】 特願２００６−１８６９５４（Ｐ２００６−１８６９５４）