図面 (/)

技術 伝送プロトコル変換方式およびプロトコル変換装置を用いたCATVネットワーク接続方式

出願人 株式会社日立製作所
発明者 三村到鈴木敏明柴田巧一
出願日 1997年9月5日 (23年3ヶ月経過) 出願番号 1997-240678
公開日 1999年3月30日 (21年8ヶ月経過) 公開番号 1999-088856
状態 特許登録済
技術分野 CATV、双方向TV等 TV信号の圧縮,符号化方式 双方向TV,動画像配信等 TV信号の圧縮,符号化方式 広域データ交換 通信制御
主要キーワード 障害波 接続地点 符号変換方式 タイムスタンプ信号 ネットワーク接続方式 データカプセル ルータ網 デジタル圧縮信号
関連する未来課題
重要な関連分野

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

図面 (16)

課題

MPEGトランスポートストリームを用いて映像信号送受信するCATVシステムインタワークユニットを使ってインタネットに接続し、インタネットを介して複数のCATVネットワーク相互接続する際に、1)インタネットプロトコルMPEG—TSプロトコルを効率的に変換する方式、、2)変換方式に対応したパケットへのデータのカプセル化方式が課題である。

解決手段

MPEGシステムで規定されているアダプテーションフィールドプライベートデータフィールドにインタネットプロトコル用のヘッダを格納して伝送する。プロトコル変換装置では、このプライベートデータにより伝送されたヘッダをそのまま使ってインターネットプロトコル用のパケットを構成する。

概要

背景

映像デジタル符号化して伝送するシステム国際標準規格として、"GENERICCODING OF MOVING PICTURESAND ASSOCIATED AUDIO: SYSTEMS"がISO/IEC13818−1、ITU−T(International Telecommunication Union) H.222.0勧告として規定されている。このMPEGシステム国際標準規格(以後、H.222.0と略記する)では、MPEG方式によって圧縮した画像信号を伝送する規格を定めている。H.222.0では、比較的ビットエラー発生の少ない蓄積媒体等からの伝送を想定したプログラムストリーム(以後、PSと略記する)形式と、伝送ビットエラーの発生が予想される通信回線を想定したトランスポートストリーム(以後、TSと略記する)形式の2種類のフォーマットを規定している。

本発明はTS形式圧縮映像信号を伝送する際の符号変換方式を対象とするため、ここで簡単にTS形式による画像伝送方式について従来技術の説明を行う。映像・音響符号化と伝送を対象としたMPEG方式では、入力されるテレビジョン等の映像信号デジタル化し、このデジタル信号離散コサイン変換可変長符号化等の手法を用いてデータ圧縮を行う。また、音響信号に関しては、手法は異なるもののデジタル化した後、冗長なデータを取り除くことで圧縮を行っている。これらの圧縮された信号はエレメンタリーストリーム(以後、ESと略記する)と呼ばれるもので、その言葉の通り画像・音響信号の要素となるデータである。なお、MPEGにおいてはこの画像・音響データを(ビットストリームという言葉を用いて表している。

MPEG映像信号を伝送するケーブルテレビ衛星通信回線、または非同期転送モード伝送路(以後、ATM回線と略記する)等では、データ伝送の際に比較的ビット誤りが多く発生することが想定されるので、伝送エラーによる障害波及の範囲を狭くするためESを小さなパケットに区切って伝送する。パケット化されたESはパケッタイズドエレメンタリストリーム(以後、PESと略記する)と呼ばれるものであり、ESにPESヘッダと呼ばれるヘッダ情報が付加した形式となっている。上記に例示した通信回線の伝送では、このPESをさらに小さなトランスポートパケットと呼ばれる188バイトのパケットに区切って伝送する。TSパケットは、図13に示すように4バイトのヘッダと、データを格納するための184バイトのペイロードから構成されるパケットである。図14はTSパケットのヘッダ構造を示す図である。TSヘッダは、1バイトの同期バイト(0x47)と、TSパケットの属性を表すフラグ(本説明では重要でないので個々のフラグの内容については説明を省略する)、13ビットのパケット識別子(以後PIDと略記する)、スクランブル制御識別子、アダプテーションフィールド識別子とパケットの連続性検査するのに用いる4ビットの巡回カウンタから構成される。またトランスポートストリームでは、アダプテーションフィールドと呼ばれるフィールドを映像データを格納するペイロードと呼ばれるデータフィールドに先立って伝送することができ、このフィールドにはシステムのクロック同期を目的としたプログラムクロックリファレンス(以後、PCRと略記する)やプライベートデータを格納することが可能である。なおTSパケットでアダプテーションフィールドを伝送する際は、TSヘッダのアダプテーションフィールド識別子にてその存在を指示することが規定されている。

MPEG方式はCATVデジタル衛星放送に対応して開発された方式であるが、最近ではコンピュータデータ通信を主目的に発展を遂げてきたインターネットと呼ばれるネットワークにおいてもMPEG画像を利用するサービスが提供されるようになってきた。インタネットにおける通信相互接続性を確保するため、Internet Engineering Task Force(以後、IETFと略記する)が規格化を進めており、MPEG画像伝送フォーマットの規格はRequest for Comment N0。2038:“RTP Payload Format forMPEG1/MPEG2 Video”(以後、RFC2038と略記する)により伝送方法やパケットのカプセル化方式が規格化されている。RFC2038では、伝送するパケットのフォーマットとしてMPEGのES、TS、もしくはPSを利用して伝送すること、配送遅延により画質劣化が生じることを回避するためRFC1889により仕様化された“RTP: A Transport Protocol for Real-Time Applications”(以後、RTPと略記する)により伝送することを定めている。なお、RTPパケットユーザデータグラムプロトコル(以後、UDPと略記する)によるパケットに格納し、さらにこのUDPパケットインタネットプロトコルパケット(以後、IPパケットと略記する)により伝送することを規定している。以上説明した従来技術によれば、CATV回線内部ではMPEG−TSパケットにより、またインタネット内部ではIPパケットによりMPEG映像を伝送することが可能である。

概要

MPEGトランスポートストリームを用いて映像信号を送受信するCATVシステムインタワークユニットを使ってインタネットに接続し、インタネットを介して複数のCATVネットワーク相互接続する際に、1)インタネットプロトコルとMPEG—TSプロトコルを効率的に変換する方式、、2)変換方式に対応したパケットへのデータのカプセル化方式が課題である。

MPEGシステムで規定されているアダプテーションフィールドのプライベートデータフィールドにインタネットプロトコル用のヘッダを格納して伝送する。プロトコル変換装置では、このプライベートデータにより伝送されたヘッダをそのまま使ってインターネットプロトコル用のパケットを構成する。

目的

効果

実績

技術文献被引用数
8件
牽制数
15件

この技術が所属する分野

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

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

請求項1

少なくともMoving Picture Experts Group-2(MPEG2)方式により圧縮されたデジタル映像信号伝送するCATVシステムであって、ITU−T(International Telecommunication Union)勧告H.222.0に規定された伝送プロトコルとInternet Engineering Task Force(IETF)が規定するインタネットプロトコル(RF791)により映像を伝送する方式を変換するインタワーク手段を有し、該インタワーク手段により2個以上のCATVネットワークをインタネットプロトコルを使ったネットワークを介して相互接続してMPEG映像信号を伝送することを特徴とするCATVシステム。

請求項2

ITU−T H.222.0勧告により規定されたMPEGトランスポートパケットデータカプセル化方式であって、該トランスポートストリームパケットアダプテーションフィールドプライベートデータとしてインタネットプロトコルのパケットヘッダ情報を構成するのに必要な情報をカプセル化し、そのデータカプセルを周期的に伝送することを特徴とするデータカプセル化方式とその伝送方法

請求項3

ITU−T H.222.0勧告により規定されたMPEGトランスポートストリームパケットのデータカプセル化方式であって、該トランスポートストリームのパケットのアダプテーションフィールドのプライベートデータとしてインタネットプロトコルパケットヘッダを格納し、そのインタネットプロトコルのパケットヘッダを含むトランスポートパケットを周期的に伝送することを特徴とするデータカプセル化方式とその伝送方法。

請求項4

少なくともMPEG方式により圧縮されたPES形式映像信号をインタネットプロトコルを用いて伝送する方式であって、このインタネットプロトコルにより構成されるIPパケットの大きさが、該IPパケットの大きさより2を減じた値が184の整数倍であることを特徴とするMPEG映像伝送方式

請求項5

少なくともMPEG方式により圧縮されたPES形式の映像信号をインタネットプロトコルを用いて伝送する方式であって、このインタネットプロトコルにより構成されるIPパケットの大きさが、該IPパケットの大きさより8を減じた値が184の整数倍であることを特徴とするMPEG映像伝送方式。

請求項6

請求項2に記載のMPEGトランスポートストリーム送出方法であって、アダプテーションフィールドのプライベートデータフィールドによりインタネットプロトコルパケットのヘッダ情報をカプセル化し、またプログラムクロックリファレンスPCR)信号をこのアダプテーションフィールド内に包含して伝送する方式であって、インタネットプロトコルとしてUDPプロトコルRTPプロトコルを使用しRTPプロトコルヘッダの32ビットタイムスタンプ信号に基本PCRデータビットの下位32ビットを複製して用いることを特徴とするMPEGプロトコルとインタネットプロトコルの変換方式

請求項7

TSパケット転送する第1のネットワークと、該第1のネットワークに接続されたビデオ供給源と、上記第1のネットワークおよびIPパケットを転送する第2のネットワークの双方に接続されたプロトコル変換装置とを有し、上記ビデオ供給源から上記第1のネットワークを介して上記プロトコル変換装置にビデオデータを伝送する際に、上記ビデオ供給源が、同一ビデオデータから形成される複数のTSパケットのうち少なくとも1つのTSパケットについてアダプテーションフィールドを挿入し、挿入したアダプテーションフィールド内にIPヘッダを格納して、各TSパケットを上記第1のネットワークに送出し、上記プロトコル変換装置が、アダプテーションフィールドが挿入されたTSパケットからIPヘッダを抽出し、抽出されたIPヘッダを用いてTSパケットをIPパケットに変換し、上記第2のネットワークに送出することを特徴とするCATVシステム。

請求項8

前記ビデオ供給源が、連続するTSパケットのN個に1個の割合で、アダプテーションフィールドを挿入しIPヘッダを格納することを特徴とする請求項7に記載のCATVシステム。

請求項9

前記プロトコル変換装置が、連続するN個のTSパケットを1個のIPパケットに変換することを特徴とする請求項8に記載のCATVシステム。

請求項10

TSパケットをIPパケットに変換するプロトコル変換方法であって、同一PID値を持つ複数のTSパケットのうちアダプテーションフィールドが挿入されたTSパケットからIPヘッダを抽出し、抽出されたIPヘッダと、IPヘッダが抽出されたTSパケットのペイロードのデータと、IPヘッダが抽出されたTSパケットに後続する少なくとも1つのTSパケットのペイロードのデータとを用いて、1つのIPパケットを形成することを特徴とするプロトコル変換方法。

技術分野

0001

本発明は、インタネットプロトコルを使ってMPEG画像伝送する方式およびそのシステムに関わり、特にMPE伝送プロトコルとインタネットプロトコルの変換処理を迅速に行う伝送方式変換装置を用いたネットワーク接続方式、および伝送するMPEGデータカプセル化方式に関する。

背景技術

0002

映像デジタル符号化して伝送するシステムの国際標準規格として、"GENERICCODING OF MOVING PICTURESAND ASSOCIATED AUDIO: SYSTEMS"がISO/IEC13818−1、ITU−T(International Telecommunication Union) H.222.0勧告として規定されている。このMPEGシステム国際標準規格(以後、H.222.0と略記する)では、MPEG方式によって圧縮した画像信号を伝送する規格を定めている。H.222.0では、比較的ビットエラー発生の少ない蓄積媒体等からの伝送を想定したプログラムストリーム(以後、PSと略記する)形式と、伝送ビットエラーの発生が予想される通信回線を想定したトランスポートストリーム(以後、TSと略記する)形式の2種類のフォーマットを規定している。

0003

本発明はTS形式圧縮映像信号を伝送する際の符号変換方式を対象とするため、ここで簡単にTS形式による画像伝送方式について従来技術の説明を行う。映像・音響符号化と伝送を対象としたMPEG方式では、入力されるテレビジョン等の映像信号デジタル化し、このデジタル信号離散コサイン変換可変長符号化等の手法を用いてデータ圧縮を行う。また、音響信号に関しては、手法は異なるもののデジタル化した後、冗長なデータを取り除くことで圧縮を行っている。これらの圧縮された信号はエレメンタリーストリーム(以後、ESと略記する)と呼ばれるもので、その言葉の通り画像・音響信号の要素となるデータである。なお、MPEGにおいてはこの画像・音響データを(ビットストリームという言葉を用いて表している。

0004

MPEG映像信号を伝送するケーブルテレビ衛星通信回線、または非同期転送モード伝送路(以後、ATM回線と略記する)等では、データ伝送の際に比較的ビット誤りが多く発生することが想定されるので、伝送エラーによる障害波及の範囲を狭くするためESを小さなパケットに区切って伝送する。パケット化されたESはパケッタイズドエレメンタリストリーム(以後、PESと略記する)と呼ばれるものであり、ESにPESヘッダと呼ばれるヘッダ情報が付加した形式となっている。上記に例示した通信回線の伝送では、このPESをさらに小さなトランスポートパケットと呼ばれる188バイトのパケットに区切って伝送する。TSパケットは、図13に示すように4バイトのヘッダと、データを格納するための184バイトのペイロードから構成されるパケットである。図14はTSパケットのヘッダ構造を示す図である。TSヘッダは、1バイトの同期バイト(0x47)と、TSパケットの属性を表すフラグ(本説明では重要でないので個々のフラグの内容については説明を省略する)、13ビットのパケット識別子(以後PIDと略記する)、スクランブル制御識別子、アダプテーションフィールド識別子とパケットの連続性検査するのに用いる4ビットの巡回カウンタから構成される。またトランスポートストリームでは、アダプテーションフィールドと呼ばれるフィールドを映像データを格納するペイロードと呼ばれるデータフィールドに先立って伝送することができ、このフィールドにはシステムのクロック同期を目的としたプログラムクロックリファレンス(以後、PCRと略記する)やプライベートデータを格納することが可能である。なおTSパケットでアダプテーションフィールドを伝送する際は、TSヘッダのアダプテーションフィールド識別子にてその存在を指示することが規定されている。

0005

MPEG方式はCATVデジタル衛星放送に対応して開発された方式であるが、最近ではコンピュータデータ通信を主目的に発展を遂げてきたインターネットと呼ばれるネットワークにおいてもMPEG画像を利用するサービスが提供されるようになってきた。インタネットにおける通信相互接続性を確保するため、Internet Engineering Task Force(以後、IETFと略記する)が規格化を進めており、MPEG画像伝送フォーマットの規格はRequest for Comment N0。2038:“RTP Payload Format forMPEG1/MPEG2 Video”(以後、RFC2038と略記する)により伝送方法やパケットのカプセル化方式が規格化されている。RFC2038では、伝送するパケットのフォーマットとしてMPEGのES、TS、もしくはPSを利用して伝送すること、配送遅延により画質劣化が生じることを回避するためRFC1889により仕様化された“RTP: A Transport Protocol for Real-Time Applications”(以後、RTPと略記する)により伝送することを定めている。なお、RTPパケットユーザデータグラムプロトコル(以後、UDPと略記する)によるパケットに格納し、さらにこのUDPパケットをインタネットプロトコルパケット(以後、IPパケットと略記する)により伝送することを規定している。以上説明した従来技術によれば、CATV回線内部ではMPEG−TSパケットにより、またインタネット内部ではIPパケットによりMPEG映像を伝送することが可能である。

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

0006

MPEG−TS方式により映像伝送を行うのは前述の通りデジタル衛星放送やデジタルCATVシステムである。これらのサービスのうち、デジタルCATVシステムは地域密着型のサービスであり比較的狭い地域サービス提供地域として構成されるのが一般的である。そのため各々のCATV事業者番組送出するためのCATVセンター(以後、ヘッドエンドと略記する)と映像を伝送するためのアクセスネットワークを保有し、ヘッドエンドにおいて受信した地上/衛星放送番組を再送信したり、ヘッドエンドに貯えた番組を必要に応じて送信している。このような従来のCATVサービスでは、放送されてきた番組以外の番組は、例えばVTR等に蓄積しておき番組編成に応じて再生する必要があった。近未来のCATVサービスとして期待されているビデオオンデマンド等も上記と同様にヘッドエンドに番組のデジタル圧縮信号を保有する形式で構築するのが一般的である。ところでビデオオンデマンドサービスでは、その番組コンテンツを保有するために再放送権(著作権)の購入、番組のデジタル圧縮処理、圧縮映像の蓄積などサービスを維持するためのコストも高く、できるだけ同一番組コンテンツ)に対するアクセス回数を多くしなければ採算が取れないといった課題がある。この課題を解決するには、例えば、複数のCATV事業者が共同でコンテンツを保有し、通信回線を使ってこのコンテンツを必要な時に伝送して利用する等の方法が効果的である。

0007

このようなシステムを構築するには複数のCATV事業者のヘッドエンド、ネットワークを通信回線を使って接続する必要がある。例えば、米国のCATVヘッドエンドと日本のCATV加入者映像受信機であるセットトップ端末(以後、STBと略記する)を接続するためには、少なくとも米国と日本の間の通信回線を利用して接続しなければならない。ところが、現状ではデジタルCATVで一般的に利用されているMPEG−TSをそのままの形式で伝送することは現実的ではない。すなわちMPEG−TSの映像伝送では、ATM回線や衛星回線等の専用通信回線を利用しなければならず、かつこの専用線通信料金が高いといった問題がある。また専用線であるため、契約地点常時接続して利用することが前提となっており、オンデマンドサービスのようにユーザの要求に応じてネットワークを占有するようなサービスに用いるにはコストパフォーマンスの点で大きな問題がある。

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

0008

上記の課題を解決するため、本発明では複数のCATVネットワークをインタネットにより接続する手段を用いる。インタネットは全世界に張り巡らされたネットワークであり、個々の端末ホストコンピュータに付与されたアドレスにより動的に接続変更が可能であるといった特徴をもつ。そのため予め接続地点を固定しておく必要もなく、映像を配信したい際にアドレスを使って接続するため、専用線では実現できない自由な接続設定、および低コスト映像通信が可能である。なお現状のインタネットでは伝送帯域幅等が狭いといった問題もあるが、ギガビットルータ帯域予約プロトコル(Resource reservation setup Protocol:RSVP)等により伝送帯域を確保することにより、帯域不足は近い将来問題とはならなくなり、グローバルネットワーク環境がインタネットにより実現されることは容易に予想できる。

0009

さらに上記のようにインターネットを用いてCATVネットワークを接続する際に新たに発生する課題:“CATVネットワークで用いているMPEG伝送プロトコルとインターネットで用いるIPプロトコルの間のプロトコル変換が必要である”に対して本発明では、MPEG−TSプロトコルとインターネットプロトコルを変換するインタワークユニットを設けることで解決する。このインタワークユニットにおいて処理の高速化と低価格化を実現しなければならないといった課題に対しては、MPEGネットワーク、IPネットワーク内部で伝送するパケットの構成方法変換方法を改良する手段を提供することによって解決する。

0010

具体的には、1)MPEG−TS方式で規定されたアダプテーションフィールドのプライベートデータ領域にIPパケットのヘッダを格納して伝送し、インタワークユニットではこのアダプテーション領域のプライベートデータを解析することなくそのままIPパケットのヘッダとしてインタネット内部を伝送するパケットを構成する手段、2)インタネットからMPEG映像信号を伝送する際には、送信するIPパケットの大きさをMPEG−TSに分割する時にあまることなくペイロードに収容可能なサイズの制約条件を設けて伝送するといった手段とを採用する。

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

0011

以下、本発明による実施例を図面を参照しながら詳細に説明する。

0012

——第1実施形態——
図9は、本発明によるCATVシステムの接続形態を示す実施例である。このCATVシステムは、2個所のCATVネットワーク61、56をインタネット50で接続する点に特徴がある。図示するように本CATVシステムは、ビデオサーバ60とそれに接続されたCATVネットワーク61、インタネット50、インタネット50とCATVネットワーク61を接続するためのインタワークユニット62、さらに第2のCATVネットワーク56と、そのネットワーク56とインタネット50を接続するインタワークユニット54から構成する。CATVネットワーク56には、映像を受信するためのSTB57が接続されている。 ビデオサーバ60からの映像信号はインタワークユニット62を介してインタネット50に伝送され、ルータ網によりインタワークユニット54に配送される。インタワークユニット54はインタネットを使って伝送された映像信号をCATVネットワーク56に供給し、これによりSTB57において映像受信を可能とする。

0013

ここでインタワーキングユニットの機能を簡単に説明する。CATVネットワークにおいては、従来技術の項で説明した通りMPEG−TS方式により映像信号を伝送している。これに対してインタネットではRFC2038に代表されるインタネットプロトコルによる画像伝送を行っている。異なるプロトコルを使用するネットワークを相互接続するインタワークユニット62は、MPEG−TSプロトコルからインタネットプロトコルに準拠した信号形式に変換する機能がある。一方、インタワークユニット54は、インタネットプロトコルにより伝送された画像信号をMPEG−TSプロトコルに変換する機能を有する。このようなインタワークユニット62、54を用いて異なるCATVネットワークをインタネットを介して接続することで、距離的に遠く離れたCATVのビデオサーバとSTBを容易に接続できるといったこれまでにない機能が実現できる。インタネットは全世界に発達したネットワークであり、この構成によれば全世界のビデオサーバとSTBの接続性を確保できるといった絶大な効果が得られる。

0014

なお、図9の実施例では映像信号を発生する装置としてビデオサーバを例にとり説明したが、本発明の趣旨はMPEGプロトコルで供給される映像信号をインタネットを介して配送することにあり、その信号供給源はビデオサーバのみに限定されるものではない。ビデオサーバ以外にMPEG信号を供給する装置としてはリアルタイムMPEGエンコーダや、衛星放送を受信してMPEG信号を出力するような受信設備があり、これらの装置であっても本発明の趣旨が満足されることは言うまでもない。

0015

さらに、本実施例では簡単のために2個所の異なるCATVネットワークを相互接続する例を説明したが、インタネットに接続されるCATVシステムは2個所以上であっても構わないことは言うに及ばない。本発明の趣旨は、インターワークユニットを用いてMPEG—TS方式で伝送された信号をインタネットにより伝送可能な形式に変換しこの変換された映像信号をインタネットにより伝送すること、及びインタネットを使って伝送された信号をインタワークユニットにより再びMPEG−TS信号に変換してCATVネットワークに伝送する点にある。

0016

——第2実施形態——
第2実施例では、第1実施例により説明したインタネット経由のCATV接続に加え、インタネット上のサーバからCATV上のSTBへの映像送信、CATV上の映像サーバからインタネット上のクライアントPCに対する映像送信をも考慮にいれた共用的な映像伝送プロトコルと、異なるネットワーク間のプロトコルを変換する方式を開示する。

0017

図8はCATV上のビデオサーバ55からインタネットのクライアント4への映像伝送と、インタネット上のサーバ52からCATVネットワーク上のSTB57の映像伝送をともに可能とするネットワーク構成の接続図である。

0018

まず、CATVネットワーク56に接続されたビデオサーバ55からインタネット上のクライアント4に映像を伝送する場合を説明する。なお、インタネット上のサーバからCATVネットワーク上のSTUに映像伝送する際のパケット化とプロトコル変換については第4実施例にて詳細に説明する。

0019

ビデオサーバ55からクライアント4に映像伝送する場合は、ビデオサーバ55は図1に示すパケット構成により映像送信を行う。この映像信号は、CATVネットワーク56によりMPEG−TS方式によりインタワークユニット62に達する。インタワークユニット62は後述する変換方式によってMPEG−TSにより運ばれた映像信号をインタネットプロトコルにより伝送可能なパケットにプロトコル変換しインタネット51に送信する。インタネット51ではIPプロトコルを利用してクライアント4に映像信号を配送する。なお、この信号はクライアント4に送信するのと同様な方法によりインタワークユニット54に送信することもできる。CATVネットワークの相互接続ではこのインタワークユニット54にてMPEG−TSに再度プロトコルの変換を行う。

0020

ここで図1に示したパケットのカプセル化の方法を詳細に説明する。図1は、図8のビデオサーバ55からインタネット50、およびCATV網56に接続されたSTB57、さらにはインタワークユニット54を介して接続される別CATVネットワーク上のSTBに送信するMPEG−TS信号の構成を示した実施例である。MPEG−TSでは、4バイトのTSヘッダー1に引き続き、データを格納するペイロードを伝送する場合と、アダプテーションフィールド2をペイロードに先立って伝送することが許容されている。本発明ではIPネットワークに信号を伝送する場合には、図1に示すように、IPヘッダを送信するTSではTSヘッダの直後に必ずアダプテーションフィールド2を挿入し、このアダプテーションフィールド2を使ってIPヘッダを伝送する。アダプテーションフィールド2は、伝送するデータの内容を示す2バイトのフラグ4と、プライベートデータ5を格納する。なお、プライベートデータ5を伝送するため、アダプテーションフィールドの内容を指示するフラグ(transport_private_data_flag)によりプライベートデータ5を伝送することを指示し、かつそのプライベートデータ5のサイズをフラグ内にプライベートデータ長(transport_private_data_length)として設定する。このプライベートデータ5として20バイトのIPパケットヘッダ6をそのままのビット配列で格納する。図7は、このプライベートデータ5に格納するIPパケットの内容を示した図である。IPパケットヘッダは、バージョンを示す4ビットのフィールド、ヘッダ長サービスタイプ、全パケット長、識別子や送信元IPアドレス宛先IPアドレスから構成され、オプションがない場合では20バイトから構成される。一般的な条件でオプションは使用しないので20バイトのフィールドを含むデータをそのままプライベートデータ領域に格納して伝送する。

0021

なお、アダプテーションフィールドに引き続いてTSのペイロードにはPESの形式でデータを格納する。PES形式で映像信号を伝送する理由については後に説明する。

0022

図1の実施例では、プライベートデータとしてIPパケットヘッダのみを含めて伝送する例を示したが、IPネットワークに接続される端末(クライアント)がサポートするプロトコルに応じて、UDPヘッダ、もしくはUDPヘッダとRTPヘッダの双方を包含する形式としても構わない。図2がプライベートデータとしてIPヘッダに引き続いてUDPヘッダを収容する場合の実施例、図3はプライベートデータとしてIPヘッダ、UDPヘッダとRTPヘッダを包含して伝送する場合の実施例である。本発明の特徴はIPネットワークにおいて使用されるプロトコルのパケットヘッダのデータをプライベートデータとして伝送することであり、特にUDP、RTP等のプロトコルに限定されない。現状では、リアルタイムの映像信号をインタネットで送信するにはRTPを利用するのが一番効果できであることから、図4に示したパケット構成が一番よい。また、図1図2図3の実施例では、IPヘッダ、UDPヘッダ、RTPヘッダをそのままプライベートデータとして伝送する場合を説明したが、例えばIPヘッダを構成するのに必要なデータを形を変形してプライベートデータとして伝送することももちろん可能である。ただし、この場合は、インタワークユニットにおいて伝送されたデータを元にIPヘッダ等を再構成する処理が必要となるので、そのままの形式で伝送することがもっとも効果的であることは容易に理解できる。

0023

ここで簡単にデータ形式としてPESを使用する理由を説明する。図8に示したようにビデオサーバ55はCATVネットワークに接続されたSTB57に対しても映像を送信する。インタネット50に送信する映像とSTB57に送信する映像は共用とすることがデータ作成コスト、システムコスト削減の観点から好ましく、従来のCATVで用いられているPES形式を採用するのが一番適している。なお、アダプテーションフィールドにカプセル化したIPヘッダの情報は、映像・音響信号とは個別に処理されるので従来のSTB57の映像再生に対してなんら影響を及ぼさない。PES形式とすることで従来のSTBとの信号互換性を保ちながらIPネットワークに映像信号を送信することが可能となる。なお、RFC2038においてはPES形式は規定されていないが、PESはESを複数のパケットに分割した後PESヘッダを付加した構成であるため、容易にESに変換できる。従ってESを受信し復号できるクライアントにおいては、ほとんど機能追加なしで復号可能である。

0024

ここでIPパケットの構成方法を補足する。イーサーネットでのIPパケットの最大サイズ(Maximum Transfer Unitサイズ) は1500バイトとなっている。従って、MPEG−TSの184バイトのペイロードは最大7個をパッキングできる。そこで、TSパケットを送信する際は、7TS周期でIPヘッダを含むTSパケットを送信する。インタワークユニットは、図6概念的に示したようにIPヘッダを含むパケットを受信してIPヘッダを構成し、その後引き続いて伝送されるTSパケットのペイロードのデータを接続してIPパケットを構成する。なお、イーサネットではMTUが1500バイトであるが、その外の物理ネットワークではMTUサイズが異なる場合があり、そのような場合は、MTUサイズに応じてIPヘッダの送出する周期を変更することはもちろん可能である。本発明では、“IPヘッダを含むTSパケットから次のIPヘッダを含むTSパケットを送信するまでの間のTSパケットペイロードの総合計バイトがMTUバイト数を超えなければよい“ということが条件になる。

0025

次に、図1図2図3に示したような構成でMPEG−TSパケットを構成し、それをインタワークユニットで処理してIPネットワークに伝送する方式について説明する。図12が、インターワークユニットにおける処理の流れを示す実施例である。なお、ここではCATVのビデオサーバは図2に示すようなカプセル化方式によりMPEG−TS信号を伝送するものとする。インタワークユニットでは図12処理手順に示されるように、伝送されたMPEG−TS信号(パケット)を入力し(手順100)、この中からIPネットワークに送信すべき信号を抽出する。MPEG−TSパケットの選択はTSパケットヘッダにあるPIDを検査することで行う。(手順102)IPネットワークに伝送するパケットでない場合はそのパケットを廃棄する(手順111)。IPネットワークに伝送するパケットである場合は、そのTSパケットヘッダにあるアダプテーションフィールドの有無を指示するフラグの検査を行う(手順104、105)。このフラグの結果、アダプテーションフィールドがある場合は、そのパケットのTSヘッダを削除し(手順106)、さらに引き続いてアダプテーションフィールドのフラグ情報を削除する(手順107)。その結果、アダプテーションフィールドのプライベートデータ部分とそれに引き続くペイロードの部分のデータが出力される(手順108)。TSヘッダのアダプテーションフィールドを指示するフラグを検査した結果(手順104、105)、アダプテーションフィールドがない場合には、そのTSパケットのTSヘッダのみを削除してペイロードデータを出力する(手順112)。この処理の結果、TSヘッダが削除され、プライベートデータに格納していたIPパケットヘッダとそれに引き続きペイロードとして画像データがインタワークユニットから送信されることになる。上述のように本実施例のカプセル化によれば、2つのフラグの検査(PIDの検査、アダプテーションあり/なしの検査)と不要データ部分の廃棄といった極めて単純な処理のみによってMPEG−TSからIPパケットを生成することができ、インタワークユニットを処理能力の低い、すなわち低コストなプロセッサで構成できるといった絶大な効果が得られる。

0026

次に図11を用いて、IPパケット化された映像信号を再度MPEG−TS信号に変換する処理について説明する。図8図9に示すインタワークユニット54にはIPヘッダ、UDPヘッダ、RTPヘッダとPESからなるデータを含むIPパケットが入力される。そこで、2バイトのアダプテーション関連のフラグとIP関連のヘッダ(IP、UDP、RTPヘッダ)をまとめたプライベートデータをアダプテーションフィールドとしてTSに格納する。このTSの残りのペイロードにはPESデータ充填し、最終的に188バイトのTSパケットを構成する。残りのIPパケットのペイロードは、184バイト毎に区切ってそれぞれをTSのペイロードに収容していく。CATVネットワーク内部では、IPヘッダを使うことはありえないが、IPヘッダを廃棄してペイロード部分のみをTSペイロードに格納するとデータバイト不足するTSが生じる。この場合不足したデータのパディング等の処理が必要になり、複雑化するので好ましくない。したがって、送信したCATVネットワーク内部と同じパケット構成に復元するのが良い。なお、実際にはバイト数のみ合致していれば問題がないので、IPヘッダと同バイト数のダミーデータを挿入することも可能である。前述したように、アダプテーションフィールド内のプライベートデータはSTBにおいて無視することが可能なため、無効データであっても構わない。

0027

——第3実施例——
図4は、本発明の第3の実施例を示す図である。本実施例を適用するネットワークの構成は第1の実施例と同様に図8、及び図9で示したネットワーク構成である。図4の実施例が図1図2図3の実施例と異なる点は、アダプテーションフィールドにプログラムクロックリファレンス(PCR)を同時に含めて送信する点と、プライベートデータとして伝送するIPパケットにRTPヘッダを含めて伝送する点である。RTPプロトコルでは、映像のようなリアルタイム性を必要とするデータ伝送を保証するためにパケットヘッダ内部に時刻情報タイムスタンプ)を記録するフィールドが設けてある。MPEG−TSを受信するCATVの端末においても復号回路システムクロックを再生するためにPCRを利用しており、かつRTPのタイムスタンプはPCRと同じく90kHzの基本周波数による時刻をデジタル化したものであるため、RTPのタイムスタンプとして利用することが可能である。図4の実施例では、アダプテーションフィールドのPCRフィールドで伝送されたPCRをRTPのタイムスタンプフィールドに使うことが特徴である。なお、RTPのタイムスタンプは32ビット、PCRの基本部分は33ビットのビット幅により時刻情報を表記しているので、PCRの下位32ビットをRTPのタイムスタンプとすれば、ビット幅を整合させることができる。このようにPCRで配送された時刻情報をRTPのタイムスタンプとして利用する利点としては、CATVネットワーク内部で発生したパケット配送ジッタ補正する目的からPCRを付け替えられたような場合にも、最終的に補正された正確な時刻情報をRTPヘッダに生め込むことが可能な点が挙げられる。

0028

——第4実施例——
図10はIPネットワークに接続されている図8のサーバ52からCATVネットワーク56に向けて画像配信を行う時のデータのカプセル化を示す実施例である。この画像の送受信の場合は、インタワークユニット54においてIPパケットで伝送されたMPEG画像信号(PES)をMPEG−TS信号に変換する操作が必要になる。この変換操作の処理を図10により説明する。IPパケットで画像を伝送する場合は、TSへの変換を容易にするためPES形式により映像データをカプセル化する。従ってこのIPパケットはIPヘッダとPES形式のペイロードから構成する。この変換操作においては、IPパケットの大きさ(IPヘッダとペイロードを含むデータの大きさ)を、そのパケットサイズから2を減じた値が184の整数倍となるようにIPパケットを構成してIPネットワークにあるサーバから送信する。IPパケットをMPEG−TS化する際には、IPパケットヘッダを含む先頭部分は、182バイトを取り出しそれにアダプテーションフィールドのフラグ(2バイト)を付加してMPEG−TSの184バイトのペイロードとして格納する。さらにこのペイロードにMPEG−TSヘッダを付与してMPEG−TSパケットを構成する。それ以後のIPパケットは184バイト毎に区切り、これにTSのパケットヘッダを付与してMPEG−TS化する。IPパケットのサイズが、184バイトの整数倍と182バイトの和となる条件があるので、IPパケットをMPEG−TSパケットのペイロードに格納しても余りバイトが出ることなくTSのペイロードに格納することが可能となる。以上説明したように本実施例の特徴は、MPEG画像を送信するIPネットワークのサーバから送信するIPパケットの大きさに制限を設けることでインタワークユニットにおけるパケットの分割・再構成が極めて単純になるといった点にある。

0029

なお、本実施例の変形としてRTPプロトコルを利用し、RTPのタイムスタンプをPCRとして挿入する場合には、アダプテーションフィールドに設けるPCRフィールド(6バイト)の分を案し、IPパケットの全体長を184バイトの整数倍に178バイトを加算した大きさとなるようにしておけば良い。

0030

——第5実施例——
第5実施例は、第2実施例の変形である。第2の実施例で用いた図1のIPパケットのカプセル化ではMPEG−TSのプライベートデータにIPヘッダを直接マップしたが、本実施例では、図15に示すように、プライベートデータの先頭バイトにプライベートデータの属性を示す領域150を設ける。この属性の領域にフラグを設けることで、プライベートデータとして送信している内容がIPヘッダであることを明示的に指示するようにする。インタワークユニットでは、このフラグを用いてIPパケットかの判定を行い、利用/廃棄の判断が可能となる。なお、属性領域のデータはIPネットワーク内では不要であるのでインタワークユニット内部でプロトコル変換の際に廃棄する必要がある。

0031

なお図15では、1バイトの属性領域を設ける例を説明したが、この領域は必ずしも1バイトである必要はなく、複数バイトであってもよいことは容易に理解できる。

発明の効果

0032

以上、本発明によればCATVネットワークをインタネットといったワールドワイドに接続されたネットワークを利用して相互接続することが可能となり、番組コンテンツの共同利用による運用コストの低減といった効果が得られる。また、インタネットとCATV回線を接続するために必要なプロトコル変換に必要な処理を大幅に削減することも達成でき、これにより低コストな処理装置でもインタワークユニットを構成することが可能となるといった絶大な効果が得られる。

図面の簡単な説明

0033

図1IPヘッダをMPEG−TSパケットにカプセル化して伝送する方式の実施例。
図2IPヘッダ、UDPヘッダをMPEG−TSパケットにカプセル化して伝送する方式の実施例。
図3IPヘッダ、UDPヘッダおよびRTPヘッダをMPEG−TSパケットにカプセル化して伝送する方式の実施例。
図4アダプテーションにPCRを含んでカプセル化する方法の実施例。
図5図4で伝送されたPCRをRTPのタイムスタンプに格納する実施例を説明する図。
図6TSパケットからIPパケットを構成する方法の実施例。
図7IPパケットヘッダの構造を説明する図。
図8インタネットを利用してCATVネットワークを接続するシステムの実施例。
図92つのCATVネットワークをインタネット接続するネットワーク構成の実施例。
図10IPネットワーク上のサーバから送出するIPパケットにより伝送された信号をMPEG−TSパケット化する実施例。
図11インタワーク装置によりIP化したパケットを再びMPEG−TS化する実施例。
図12インタワークユニットの信号処理フローを説明するフローチャート
図13MPEG−TSの構造を説明する図。
図14MPEG−TSのヘッダの構造を説明する図。
図15プライベートデータにIPパケットを指示するフラグを設けた実施例を説明する図。

--

0034

1…TSヘッダ、2…アダプテーションフィールド、3…ペイロード(PES)、4…アダプテーションフィールドフラグ、5…プライベートデータ、6…IPヘッダ、10…UDPヘッダ、14…RTPヘッダ、23…PCRベース、25…PCR拡張、26…RTPのタイムスタンプ、52…インタネット、51…インタネットルータ、52…インタネット画像サーバ、54…インタワークユニット、55…CATV画像サーバ、56…CATVネットワーク、57…STB、58…インタネット画像クライアント、62…インタワークユニット、80…IPパケットのペイロード、131…アダプテーションフィールド、180…フラグ。

ページトップへ

この技術を出願した法人

この技術を発明した人物

ページトップへ

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

関連する公募課題

ページトップへ

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

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

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

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

ページトップへ

おススメ サービス

おススメ astavisionコンテンツ

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

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

関連性が強い人物一覧

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

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

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

関連する公募課題一覧

astavision 新着記事

サイト情報について

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

主たる情報の出典

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