JP2004282538A - 送受信システム、送信装置および方法、受信装置および方法、記録媒体、並びにプログラム - Google Patents
送受信システム、送信装置および方法、受信装置および方法、記録媒体、並びにプログラム Download PDFInfo
- Publication number
- JP2004282538A JP2004282538A JP2003073075A JP2003073075A JP2004282538A JP 2004282538 A JP2004282538 A JP 2004282538A JP 2003073075 A JP2003073075 A JP 2003073075A JP 2003073075 A JP2003073075 A JP 2003073075A JP 2004282538 A JP2004282538 A JP 2004282538A
- Authority
- JP
- Japan
- Prior art keywords
- data
- control step
- packet
- transmission
- header
- 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.)
- Granted
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/22—Arrangements for detecting or preventing errors in the information received using redundant apparatus to increase reliability
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/64—Hybrid switching systems
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
- H04L12/40—Bus networks
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/40—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass for recovering from a failure of a protocol instance or entity, e.g. service redundancy protocols, protocol state redundancy or protocol service redirection
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Security & Cryptography (AREA)
- Multimedia (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Information Transfer Between Computers (AREA)
- Compression Or Coding Systems Of Tv Signals (AREA)
- Communication Control (AREA)
Abstract
【課題】通信の信頼性を向上させる。
【解決手段】ＲＴＰヘッダ１１２が付加されたＴＳパケット列１１１には、オーディオデータが含まれている。そのオーディオデータのみで構成されるＴＳパケット列が、ＴＳパケット列１２１である。このオーディオデータのみで構成されるパケット列１２１のＲＴＰヘッダは、ＲＴＰヘッダ１１２である。すなわち、この場合、“Ｓｅｑｕｅｎｃｅ Ｎｕｍｂｅｒ”として同一の“１２３５ｈ”という番号を有するＲＴＰパケットが、２回、連続して送信される。受信側では、２回送信されてきたＲＴＰパケットのうち１つでも受信できれば、オーディオデータに関しては欠落が生じないため、ユーザに提供する音声がとぎれてしまうといったような不都合を防ぐことが可能となる。本発明は、データの授受を行う送信機と受信機に適用できる。
【選択図】 図１５
【解決手段】ＲＴＰヘッダ１１２が付加されたＴＳパケット列１１１には、オーディオデータが含まれている。そのオーディオデータのみで構成されるＴＳパケット列が、ＴＳパケット列１２１である。このオーディオデータのみで構成されるパケット列１２１のＲＴＰヘッダは、ＲＴＰヘッダ１１２である。すなわち、この場合、“Ｓｅｑｕｅｎｃｅ Ｎｕｍｂｅｒ”として同一の“１２３５ｈ”という番号を有するＲＴＰパケットが、２回、連続して送信される。受信側では、２回送信されてきたＲＴＰパケットのうち１つでも受信できれば、オーディオデータに関しては欠落が生じないため、ユーザに提供する音声がとぎれてしまうといったような不都合を防ぐことが可能となる。本発明は、データの授受を行う送信機と受信機に適用できる。
【選択図】 図１５
Description
【０００１】
【発明の属する技術分野】
本発明は送受信システム、送信装置および方法、受信装置および方法、記録媒体、並びにプログラムに関し、特に、送受信されているパケットが欠落してしまったときに、その欠落を補う装置に用いて好適な送受信システム、送信装置および方法、受信装置および方法、記録媒体、並びにプログラムに関する。
【０００２】
【従来の技術】
ネットワークが普及し、そのネットワークを用いて提供されるサービスも、多岐にわたるようになってきている。ネットワーク自体の構成も、有線で構成されるものや、無線で構成されるものがある。
【０００３】
ネットワークが普及すると共に、そのネットワークにおける通信の信頼性を向上させるために、例えば、同一のデータを異なる経路で伝送するなどして、一方の経路で何らかの異常が発生しても、他方の経路で、通信を確保できるようにし、データの欠落などを防ぐ方法が提案されている。（例えば、特許文献１参照）
【０００４】
【特許文献１】
特開平１１−９８１６１号公報
【０００５】
【発明が解決しようとする課題】
近年では、家庭内におけるネットワークとして、有線によるものより、設置などが手軽な無線ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）が普及しつつある。しかしながら、無線ＬＡＮは、その特性から、有線ＬＡＮに比べて信頼性が劣るという問題があった。
【０００６】
例えば、無線ＬＡＮは、当然ながら、無線によりデータの送受信を行うが、無線で行うために、通信を行っている送信機と受信機の間を人が横切ったり、湿度などの環境の変化により、その通信状態が悪化することが考えられる。通信状態が悪化したために、送受信（通信）すべきデータが通信の途中で欠落するなどの不都合が発生することが考えられる。
【０００７】
映像の場合、何らかの原因で、送受信すべきデータが通信の途中で欠落しても、その欠落を補うような手法が実用化されている。例えば、ＭＰＥＧ（Ｍｏｖｉｎｇ Ｐｉｃｔｕｒｅ Ｅｘｐｅｒｔｓ Ｇｒｏｕｐ）方式によりエンコードされたデータがデコードされる場合、そのデコードされるビデオストリーム内のパケットに欠落があっても、そのパケットにかかわるフレームの前のフレーム、あるいは前のフレームの一部のブロックを補間することにより、ビデオストリームの再生が継続されるようにされている。
【０００８】
このようなエラーコンシールメント（エラー隠蔽）をする手法が、ビデオストリームを処理するデコーダ側に備わっていれば、ユーザに提供される映像が、とぎれてしまうといったような不都合が発生することを抑えることが可能となる。
【０００９】
しかしながら、音声の場合、映像と同じ手法により、パケット（データ）の欠落などによるエラーを隠蔽したとしても、その隠蔽は有効ではないため、音声のデータに対しては、そのようなエラー隠蔽のための手法は用いられていなかった。そのために、音声にかかわるパケットが欠落したりした場合、ユーザに提供される音声がとぎれるなどの不都合が発生するといった課題があった。
【００１０】
本発明はこのような状況に鑑みてなされたものであり、所定のデータを複数回送信する（冗長化して送信する）ことにより、ユーザ側に提供される映像や音声がとぎれるといったような不都合が発生することを防ぐことを目的とする。
【００１１】
【課題を解決するための手段】
本発明の送受信システムの送信装置は、データを取得する取得手段と、取得手段により取得されたデータを受信装置に送信する送信手段と、取得手段により取得されたデータを記憶する記憶手段と、記憶手段からデータを読み出し、送信手段に、読み出されたデータの送信を指示する指示手段とを備え、受信装置は、送信手段により送信されたデータを受信する受信手段と、受信手段により受信されたデータは、既に受信されたデータであるか否かを判断する判断手段と、判断手段により、受信されたデータは、既に受信されたデータであると判断された場合、そのデータを破棄し、受信されたデータは、既に受信されたデータではないと判断された場合、そのデータ記憶する記憶制御手段とを備えることを特徴とする。
【００１２】
本発明の送信装置は、データを取得する取得手段と、取得手段により取得されたデータを送信する送信手段と、取得手段により取得されたデータを記憶する記憶手段と、記憶手段からデータを読み出し、送信手段に、読み出されたデータの送信を指示する指示手段とを備えることを特徴とする送信装置。
【００１３】
前記指示手段は、送信手段によりデータが送信された後、所定の時間が経過すると、記憶手段からデータを読み出し、送信手段に、読み出されたデータの送信を指示するようにすることができる。
【００１４】
前記取得手段により取得されたデータ内に、所定のデータが含まれるか否かを判断する判断手段をさらに含み、記憶手段は、判断手段によりデータ内に、所定のデータが含まれていると判断された場合、その所定のデータを記憶し、指示手段は、記憶手段から所定のデータを読み出し、送信手段に送信させるようにすることができる。
【００１５】
前記取得手段により取得されたデータ内に、オーディオデータが含まれるか否かを判断する判断手段をさらに含み、記憶手段は、判断手段によりデータ内に、オーディオデータが含まれていると判断された場合、そのオーディオデータと、そのオーディオデータに付加されているヘッダを記憶し、指示手段は、記憶手段からヘッダとオーディオデータを読み出し、送信手段に送信させるようにすることができる。
【００１６】
前記ヘッダは、ＲＴＰヘッダであるようにすることができる。
【００１７】
本発明の送信方法は、データの取得を制御する取得制御ステップと、取得制御ステップの処理で取得が制御されたデータの送信を制御する送信制御ステップと、取得制御ステップの処理により取得が制御されたデータの記憶を制御する記憶制御ステップと、記憶制御ステップにより記憶が制御されたデータを読み出し、送信制御ステップの処理で、読み出されたデータが送信されるように指示する指示ステップとを含むことを特徴とする。
【００１８】
本発明の記録媒体のプログラムは、データの取得を制御する取得制御ステップと、取得制御ステップの処理で取得が制御されたデータの送信を制御する送信制御ステップと、取得制御ステップの処理により取得が制御されたデータの記憶を制御する記憶制御ステップと、記憶制御ステップにより記憶が制御されたデータを読み出し、送信制御ステップの処理で、読み出されたデータが送信されるように指示する指示ステップとを含むことを特徴とする。
【００１９】
本発明のプログラムは、データの取得を制御する取得制御ステップと、取得制御ステップの処理で取得が制御されたデータの送信を制御する送信制御ステップと、取得制御ステップの処理により取得が制御されたデータの記憶を制御する記憶制御ステップと、記憶制御ステップにより記憶が制御されたデータを読み出し、送信制御ステップの処理で、読み出されたデータが送信されるように指示する指示ステップとをコンピュータに実行させることを特徴とするプログラム。
【００２０】
本発明の受信装置は、データを受信する受信手段と、受信手段によりデータが受信されたとき、そのデータは、既に受信されているデータであるか否かを判断する判断手段と、判断手段により、受信手段により受信されたデータは、既に受信されているデータであると判断された場合、そのデータを破棄し、既に受信されているデータではないと判断された場合、そのデータ記憶する記憶制御手段とを備えることを特徴とする。
【００２１】
前記判断手段は、受信手段により受信されたデータに含まれるＲＴＰヘッダのＳｅｑｕｅｎｃｅ Ｎｕｍｂｅｒを参照し、データが、既に受信されたデータであるか否かを判断するようにすることができる。
【００２２】
本発明の受信方法は、データの受信を制御する受信制御ステップと、受信制御ステップの処理によりデータが受信されたとき、そのデータは、既に受信されているデータであるか否かを判断する判断ステップと、判断ステップの処理により、受信制御ステップの処理により受信されたデータは、既に受信されているデータであると判断された場合、そのデータを破棄し、既に受信されているデータではないと判断された場合、そのデータ記憶する記憶制御ステップとを含むことを特徴とする。
【００２３】
本発明の記録媒体のプログラムは、データの受信を制御する受信制御ステップと、受信制御ステップの処理によりデータが受信されたとき、そのデータは、既に受信されているデータであるか否かを判断する判断ステップと、判断ステップの処理により、受信制御ステップの処理により受信されたデータは、既に受信されているデータであると判断された場合、そのデータを破棄し、既に受信されているデータではないと判断された場合、そのデータ記憶する記憶制御ステップとを含むことを特徴とする。
【００２４】
本発明のプログラムは、データの受信を制御する受信制御ステップと、受信制御ステップの処理によりデータが受信されたとき、そのデータは、既に受信されているデータであるか否かを判断する判断ステップと、判断ステップの処理により、受信制御ステップの処理により受信されたデータは、既に受信されているデータであると判断された場合、そのデータを破棄し、既に受信されているデータではないと判断された場合、そのデータ記憶する記憶制御ステップとをコンピュータに実行させることを特徴とする。
【００２５】
本発明においては、所定のデータが複数回送信される。その複数回送信されるデータは、例えば、オーディオデータである。
【００２６】
本発明においては、複数回送信されてきた所定のデータのうち、既に受信されているデータに関しては、記憶されないように制御される。
【００２７】
【発明の実施の形態】
以下に、本発明の実施の形態について図面を参照して説明する。図１は、本発明を適用した送受信システムの一実施の形態の構成を示す図である。図１に示した送受信システムは、送信機１と受信機２から構成されている。送信機１は、アンテナ３により受信されたテレビジョン放送のデータを、受信機２に対して送信する。受信機２は、表示装置（例えば、ディスプレイ）や音声出力装置（例えば、スピーカ）を備えており、受信したデータに基づく画像や音声を出力するように構成されている。
【００２８】
ここでは、アナログ信号のテレビジョン放送が受信され、そのデータが、受信機２に送信されるとして説明するが、本発明は、アナログ信号のテレビジョン放送だけでなく、例えば、ＢＳ（Ｂｒｏａｄｃａｓｔｉｎｇ Ｓａｔｅｌｌｉｔｅ）放送、ＣＳ（Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ｓａｔｅｌｌｉｔｅ）放送、地上波デジタル放送などのデジタル信号のテレビジョン放送に対しても適用することが可能である。
【００２９】
また、例えば、ＶＴＲ（Ｖｉｄｅｏ Ｔａｐｅ Ｒｅｃｏｒｄｅｒ）やＤＶＤ（Ｄｉｇｉｔａｌ Ｖｅｒｓａｔｉｌｅ Ｄｉｓｃ）プレーヤなどが送信機１に接続され、それらの装置からのデータが、送受信されるようにしても良い。さらに、インターネットなどのネットワークに接続され、そのネットワークに接続されることにより得られる情報などの送受信が行われるようにしても良い。
【００３０】
送信機１と受信機２は、無線でデータの授受を行う。その無線による通信は、例えば、ＩＥＥＥ８０２．１１の規格に基づく方式で行われる。送信機１と受信機２は、無線によりデータの授受を行うため、例えば、ユーザは、送信機１を家の所定の場所に固定して設置し、受信機２を所望の場所まで持ち運び、その場所でテレビジョン放送を閲覧するといったことをできる。
【００３１】
図２は、送信機１の内部構成例を示す図である。図２に示した内部構成例は、主に、本発明にかかわり、説明に必要とされる部分を示し、説明に必要ない部分、例えば、受信したテレビジョン放送からユーザが指定した番組を抽出するチューナや、ＶＴＲやＤＶＤプレーヤなどを接続した際に、それらの装置からの入力を切り換えるスイッチャーなどは、省略してある。
【００３２】
送信機１は、アンテナ３により受信されたテレビジョン放送としてのデータ（信号）を入力する。入力される信号は、例えば、アナログ信号である。そのアナログ信号は、ＭＰＥＧ（Ｍｏｖｉｎｇ Ｐｉｃｔｕｒｅ Ｅｘｐｅｒｔｓ Ｇｒｏｕｐ）エンコーダ２１に入力される。ＭＰＥＧエンコーダ２１は、入力されたアナログ信号を、ＭＰＥＧ方式に基づく圧縮を施したデジタルデータに変換する。
【００３３】
なお、デジタル信号のテレビジョン放送のデータなどが入力される場合、ＭＰＥＧエンコーダ２１によりエンコードされる必要はないので、必ずしも、入力されたデータが、ＭＰＥＧエンコーダ２１を介する構成とされる必要はなく、適宜、入力されるデータにより、入力される部分が異なるようにしても良い。勿論、そのような入力されたデータの出力先を選択するためのスイッチャーなどが、図示はしないが、送信機１には備え付けられている。
【００３４】
ＭＰＥＧエンコーダ２１からの出力（トランスポートストリームパケット：以下、適宜、ＴＳパケットと記述する）は、ＲＴＰ（Ｒｅａｌ Ｔｉｍｅ Ｐｒｏｔｏｃｏｌ）ヘッダ付加部２２に供給される。ＲＴＰヘッダ付加部２２は、供給されたＴＳパケットを所定の個数、例えば、７個のパケットをまとめ、そのまとめたパケット（以下、適宜、ＴＳパケット列と記述する）にＲＴＰヘッダを付加し、ＵＤＰ（Ｕｓｅｒ Ｄａｔａｇｒａｍ Ｐｒｏｔｏｃｏｌ）付加部２３に供給する。ＲＴＰヘッダ付加部２２によりＲＴＰヘッダを付加されたＴＳパケット列を、適宜、ＲＴＰパケットと記述する。
【００３５】
ＵＤＰヘッダ付加部２３は、供給されたＲＴＰパケットに対して、さらに、ＵＤＰヘッダを付加して、ＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）ヘッダ付加部２４に供給する。ＵＤＰヘッダ付加部２３によりＵＤＰヘッダを付加されたＲＴＰパケットを、適宜、ＵＤＰパケットと記述する。
【００３６】
ＩＰヘッダ付加部２４は、供給されたＵＤＰパケットに対して、ＩＰヘッダを付加し、ＭＡＣ（Ｍｅｄｉａ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ）ヘッダ付加部２５に供給する。ＩＰヘッダ付加部２４によりＩＰヘッダを付加されたＵＤＰパケットを、適宜、ＩＰパケットと記述する。
【００３７】
ＭＡＣヘッダ付加部２５は、供給されたＩＰパケットに対して、ＭＡＣヘッダを付加し、通信部２６に供給する。ＭＡＣヘッダ付加部２５によりＭＡＣヘッダを付加されたＩＰパケットを、適宜、ＭＡＣパケットと記述する。
【００３８】
各部で、ヘッダを付加され、ＭＡＣパケットとされたＴＳパケットは、通信部２６により、受信機２に対して送信される。
【００３９】
冗長化制御部２７は、詳細は後述するが、所定のデータ（例えば、オーディオデータ）の複数回の送信を制御する（冗長化（重畳化）して送信するための制御を行う）ために設けられており、必要に応じ記憶部２８から、ＵＤＰヘッダ付加部２３に、パケットが供給されるように制御する。また、冗長化制御部２７は、ＲＴＰヘッダ付加部２２から供給されるＲＴＰパケットを記憶部２８に記憶させる。
【００４０】
記憶部２８には、このような所定のデータの冗長した送信を可能にするために、その複数回送信すべきデータと、そのデータに対応するＲＴＰヘッダが記憶されている。
【００４１】
図３は、ＭＰＥＧエンコーダ２１乃至ＭＡＣヘッダ付加部２５の各部が、処理を行うことにより、通信部２６に供給されるデータ（ＭＡＣパケット）を示す図である。図３に示すように、通信部２６に供給されるデータは、ＭＰＥＧエンコーダ２１によりエンコードされたＴＳパケット列４１を含む。上述したように、通信部２６に供給されるＭＡＣパケット内のＴＳパケット列４１には、ＴＳパケット５１−１乃至５１−７の７個のパケットが含まれている。１つのＴＳパケットは、１８８Ｂｙｔｅｓで構成されている。
【００４２】
ＴＳパケット列４１内の１つのパケットであるＴＳパケット５１−１は、ヘッダ部６１とデータ部６２から構成されている。ヘッダ部６１は、図４に示すデータを含み、データ部６２は、受信機２（図１）側で、映像または音声としてユーザに提供するためのビデオデータまたはオーディオデータを含む。
【００４３】
図４は、ＴＳパケット５１のヘッダ部６１のデータ構成を示す図である。ヘッダ部６１は、４Ｂｙｔｅｓで構成され、データ部６２は、１８４Ｂｙｔｅｓで構成される。ヘッダ部６１の“同期バイト”は、同期を取るために設けられており、固定値で、例えば、“４７ｈ”が設定されている。“Ｅｒｒｏｒ Ｆｌａｇ”は、ＴＳパケット５１の中に訂正できないｂｉｔ ｅｒｒｏｒがあるか否かを示すフラグである。
【００４４】
“Ｓｔａｒｔ Ｆｌａｇ”は、新しいＰＥＳ Ｐａｃｋｅｔあるいは新しいＴＳ−ＰＳＩ Ｓｅｃｔｉｏｎであることを示すフラグである。“Ｐｒｉｏｒｉｔｙ Ｆｌａｇ”は、パケットの優先度を示すフラグであり、このフラグ（ｂｉｔ）が、１に設定されていると、他のＴＳパケット５１より重要度が高いことを示す。“ＰＩＤ”は、ＴＳパケット５１のＰａｙｌｏａｄ部分（データ部６２）が、ビデオデータであるか、オーディオデータであるか、ＴＳ−ＰＳＩ（ＴＳ−Ｐｒｏｇｒａｍ Ｓｐｅｃｉｆｉｃ Ｉｎｆｏｒｍａｔｉｏｎ）であるか、あるいは、それら以外であるかを、それぞれを区別するために付与される、１３ｂｉｔで構成される数値（Ｉｄｅｎｔｉｆｉｅｒ）である。
【００４５】
“Ｓｃｒａｍｂｌｉｎｇ ｍｏｄｅ”は、データ部６２のＳｃｒａｍｂｌｉｎｇ ｍｏｄｅ（スクランブルモード）を示す情報である。“Ａｄａｐｔａｔｉｏｎ Ｆｉｅｌｄ ｆｌａｇ”は、ＰＣＲ（Ｐｒｏｇｒａｍ Ｃｌｏｃｋ Ｒｅｆｅｒｅｎｃｅ）などの情報が含まれているＡｄａｐｔａｔｉｏｎ Ｆｉｅｌｄの有無を示す情報である。“Ｃｏｎｔｉｎｕｉｔｙ Ｃｏｕｎｔｅｒ”は、同じＰＩＤを持つパケットで、１ずつ値が増加されるカウンタ値の情報である。
【００４６】
ＭＰＥＧエンコーダ２１（図２）では、入力されたアナログ信号をデジタルデータに変換し、ＭＰＥＧ方式の圧縮を施してデータ部６２を生成すると共に、図４に示したようなヘッダ部６１を生成し、１つのＴＳパケット５１を生成する。
【００４７】
このようなＴＳパケット５１が、この場合、７個含まれるのが、図３に示したＴＳパケット列４１である。ＲＴＰヘッダ４２（図３）は、ＲＴＰヘッダ付加部２２（図２）により付加されるヘッダであるが、そのデータ構成は、図５に示すように構成されている。
【００４８】
ＲＴＰヘッダ４２の“Ｖ”は、Ｖｅｒｓｉｏｎ Ｂｉｔを示し、ＲＴＰヘッダ４２のフォーマットのバージョンを示すバージョン番号の情報である。“Ｐ”は、Ｐａｄｄｉｎｇ Ｂｉｔを示し、パケットのサイズを調整するビットである。“Ｘ”は、Ｅｘｔｅｎｓｉｏｎ Ｂｉｔを示し、機能拡張時に指定される拡張ビットである。
【００４９】
“ＣＣ”は、ＣＳＲＣ Ｃｏｕｎｔを示し、リアルタイム転送に関わる送信元の数を示すカウンタの情報である。“Ｍ”は、Ｍａｒｋｅｒ Ｂｉｔを示し、１パケットにおけるフレームの境界を示すマーカービットである。“ＰＴ”は、Ｐａｙｌｏａｄ Ｔｙｐｅを示し、ペイロードの符号化の種類を示す情報である。“Ｓｅｑｕｅｎｃｅ Ｎｕｍｂｅｒ”は、ＲＴＰパケットの順番を示すシーケンス番号を示す情報である。
【００５０】
“ＴＩＭＥ ＳＴＡＭＰ”は、ＲＴＰヘッダ４２が作成された時刻を示すタイムスタンプの情報を示す。“ＳＳＲＣ”は、Ｓｙｎｃｈｒｏｎｉｚａｔｉｏｎ Ｓｏｕｒｃｅを示し、メッセージの最初の送信元（ソース）を識別する同期ソース識別子の情報である。“ＣＳＲＣ”は、Ｃｏｎｔｒｉｂｕｔｉｎｇ Ｓｏｕｒｃｅを示し、メッセージに含まれるパケット群の送信先（クライアント）を識別する貢献ソース識別子の情報である。
【００５１】
このような情報を含むＲＴＰヘッダ４２に対応するペイロード（Ｐａｙｌｏａｄ）に、ＴＳパケット列４１が挿入される。ＲＴＰヘッダ４２が付加されているＲＴＰパケットにＵＤＰヘッダ４３（図３）が、ＵＤＰヘッダ付加部２３（図２）により付加される。
【００５２】
図６は、ＵＤＰヘッダ４３のデータ構成を示す図である。ＵＤＰヘッダ４３の“ＳＲＣ ＰＯＲＴ”は、送信元のポート番号を指定する情報であり、“ＤＥＳＴ ＰＯＲＴ）は、送信先（宛先）のポート番号を指定する情報であり、共に、サービスを特定するための情報として用いられる。
【００５３】
“Ｌｅｎｇｔｈ”は、ＵＤＰヘッダ４３とその後に続くデータの長さ（バイト単位）の合計を示す情報である。“Ｃｈｅｃｋｓｕｍ”は、ＵＤＰヘッダの情報と、データ長を元にして算出された値の情報である。受信側では、送信側と同様の計算を行い、Ｃｈｅｃｋｓｕｍ（チェックサム）の値を算出し、その算出した値と、送信されてきたＵＤＰヘッダ４３に含まれるチェックサムの値が一致しているか否かを判断することで、途中で、パケットが壊れていないか否かを判断する。
【００５４】
このようなＵＤＰヘッダ４３が付加されたＵＤＰパケットに、ＩＰヘッダ４４（図３）が、ＩＰヘッダ付加部２４（図２）により付加される。図７は、ＩＰヘッダ４４のデータ構成を示す図である。図７に示したＩＰヘッダ４４のデータ構成は、基本ヘッダの部分だけを示し、オプションヘッダについては図示していない。
【００５５】
“Ｖｅｒ”は、インターネットプロトコル（ＩＰ）のバージョンを示す情報である。“ＩＨＬ”は、Ｉｎｔｅｒｎｅｔ Ｈｅａｄｅｒ Ｌｅｎｇｔｈを示し、このヘッダの長さを示す情報である。“ＴＯＳ”は、Ｔｙｐｅ Ｏｆ Ｓｅｒｖｉｃｅを示し、データの優先度の定義や、どのようなタイプの転送を行うかなどを指定する情報である。
【００５６】
“ＴＬ”は、Ｔｏｔａｌ Ｌｅｎｇｔｈを示し、ＩＰヘッダ４４と、ＩＰヘッダ４４以降のデータの合計の長さを示す情報である。“ＩＤ”は、このＩＰヘッダ４４で示されるＩＰパケットを識別するための情報である。“ＦＬ”は、ＩＰ層でデータを分割（フラグメント）した際の、その制御に関する情報である。
【００５７】
“ＦＯ”は、ＩＰ層でデータが分割された際のデータが、どこにあったかを示す情報である。“ＴＴＬ”は、Ｔｉｍｅ Ｔｏ Ｌｉｖｅを示し、このＩＰヘッダ４４を含むデータが、いつ破棄されるのかを示す情報である。“ＰＲＯＴ”は、ＩＰ層より上の層で用いられているプロトコルを示す情報である。
【００５８】
“ＨＣ”は、ＩＰヘッダ４４が送信中に壊れていないか否かを、受信側で確認するためのチェックサムの情報である。“ＳＡ”は、データの送信元のＩＰアドレスを示す情報である。“ＤＡ”は、データの送信先のＩＰアドレスを示す情報である。
【００５９】
このようなＩＰヘッダ４４が付加されたＩＰパケットに、ＭＡＣヘッダ４５（図３）が、ＭＡＣヘッダ付加部２５（図２）により付加される。図８は、ＭＡＣヘッダ４５のデータ構成を示す図である。
【００６０】
“ＰＡ”は、プリアンブルであり、クロックリカバリのためのＰＬＬをロックするさせるための情報である。“ＤＡ”は、送信先のＭＡＣアドレスを示す情報である。“ＳＡ”は、送信元のＭＡＣアドレスを示す情報である。“Ｔｙｐｅ”は、上位層のプロトコルを示し情報である。
【００６１】
“Ｌｅｎｇｔｈ”は、ペイロードのデータのバイト数を示す情報である。１つのＭＡＣヘッダ４５には、“Ｔｙｐｅ”または“Ｌｅｎｇｔｈ”のどちらか一方の情報が書き込まれる。“ＦＣＳ”は、エラーチェックのための情報である。
【００６２】
このような情報を含むＭＡＣヘッダ４５が付加されることにより、図３に示したようなデータ（ＭＡＣパケット）が生成される。
【００６３】
ここでは、図３に示した構成のデータが、送信機１から送信されるとして説明するが、ＲＴＰヘッダ４２が付加されていない構成のデータでも、受信機２側にデータを送信することは可能である。しかしながら、図３に示したように、本実施の形態においては、ＲＴＰヘッダ４２が付加されたデータを送信するようにする。
【００６４】
このように、ＲＴＰヘッダ４２が付加されたデータが送信されるようにするのは、所定のデータ（パケット）を複数回送信するために、ＲＴＰヘッダ４２内の情報（具体的には、図５に示した“Ｓｅｑｕｅｎｃｅ Ｎｕｍｂｅｒ”）が用いられるからである。
【００６５】
ＵＤＰヘッダ４３は、ＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）ヘッダに置き換えることが可能である（ＴＣＰヘッダにしても良い）。しかしながら、本実施の形態においては、図３に示したように、ＵＤＰヘッダ４３を用いる。
【００６６】
このように、ＴＣＰヘッダを付加するのではなく、ＵＤＰヘッダを付加するようにするのは、以下の理由からである。ＴＣＰヘッダは、トランスポート層のプロトコルとして、ＴＣＰが用いられたときに付加されるヘッダであり、ＵＤＰヘッダは、トランスポート層のプロトコルとして、ＵＤＰが用いられたときに付加されるヘッダである。
【００６７】
トランスポート層のプロトコルとして、ＴＣＰを用いるか、または、ＵＤＰを用いるかを決定する要因の１つとして、そのプロトコルを用いて行われる通信ではどのようなデータが送受信されるのかという要因がある。ＴＣＰは、コネクション型のプロトコルと称され、ＵＤＰはコネクションレス型のプロトコルと称されることがある。
【００６８】
ＴＣＰは、コネクション型のプロトコルであるので、データの授受にかかわる処理手順が複雑になるが、通信にかかわる信頼度は向上する。従って、主に、信頼度を優先させる通信に用いられる。ＴＣＰに対し、ＵＤＰは、コネクションレス型のプロトコルであるので、データの授受にかかわる処理手順は簡素化されているが、通信にかかる処理時間は短くなるため、処理速度を優先させる通信に用いられる。
【００６９】
本実施の形態においては、上述したように、送信機１が受信したテレビジョン放送のデータを、受信機２側に送信するので、その送信機１と受信機２との間のデータの授受にかかわるプロトコルは、信頼度より処理速度を優先させ、リアルタイムに処理できるようにした方が良いため、ＵＤＰを用いる。
【００７０】
しかしながらＵＤＰを用いて通信を行うと、送信機１が送信したデータが、何らかの原因で、受信機２側で受信されてなくても、送信機１側は、そのような状況に関係なく、データを順次送信し続ける。受信機２側で、欠落したデータを取得することなく、欠落した状態のまま処理を続けると、ユーザに提供される映像や音声がとぎれたり、乱れたりする。そのようなことは、できる限り発生しない方が好ましい。
【００７１】
そこで、本実施の形態においては、リアルタイムに処理が行われることを重視し、ＵＤＰを用いた通信を行ったとしても、何らかの原因で、受信側でデータを受信できないような状況が発生したとき、すなわち、データの欠落が生じたとき、その欠落したデータを補った処理を行えるようにすると共に、その処理を行うことにより、送信側および受信側でそれぞれ行われる処理自体が、多大な処理とならないようにする。
【００７２】
そのような機能を有し、図２に示したような構成を有する送信機１に対応する受信機２について説明する。図９は、受信機２の内部構成例を示す図である。受信機２の通信部８１は、送信機１からのデータを受信する。通信部８１により受信された送信機１からの、図３に示したような構成のデータは、ＭＡＣヘッダ抽出部８２に供給される。ＭＡＣヘッダ抽出部８２は、供給されたデータ（ＭＡＣパケット）から、ＭＡＣヘッダ４５（図３）を抽出（除去）し、ＩＰパケットをＩＰヘッダ抽出部８３に供給する。
【００７３】
ＩＰヘッダ抽出部８３は、供給されたＩＰパケットからＩＰヘッダ４４を抽出し、ＵＤＰパケットをＵＤＰヘッダ抽出部８４に供給する。ＵＤＰヘッダ抽出部８３は、供給されたＵＤＰパケットからＵＤＰヘッダ４３を抽出し、ＲＴＰパケットを順序再構成部８５に供給する。
【００７４】
順序再構成部８５は、ＲＴＰヘッダ４２に含まれる“Ｓｅｑｕｅｎｃｅ Ｎｕｍｂｅｒ”（図５）（以下、適宜、シークエンスナンバーと記述する）を参照しする。シークエンスナンバーは、送信機１側で、処理された順（生成されたＲＴＰヘッダ４２順）に、通常、昇順に割り振られる連続した番号である。なおここでは、昇順に割り振られるとして説明をするが、降順に割り振られるようにしても良い。
【００７５】
順序再構成部８５は、供給されたＲＴＰパケットのシークエンスナンバーを参照し、そのシークエンスナンバーと同一の番号を持つデータ（対応するデータ）が記憶部８７に記憶されているか否かを判断し、記憶されていると判断した場合、その供給されたＲＴＰパケットを破棄し、記憶されていないと判断した場合、その供給されたＲＴＰパケットをＲＴＰヘッダ抽出部８６に供給する。
【００７６】
ＲＴＰヘッダ抽出部８６は、供給されたＲＴＰパケットから、ＲＴＰヘッダ４２を抽出し、ＴＳパケット列４１を、記憶部８７に記憶させる。記憶部８７には、このようにして、ＴＳパケット列４１が記憶されるが、そのＴＳパケット列４１は、ＲＴＰヘッダ４２のシークエンスナンバーと関連付けられて記憶される。
【００７７】
記憶部８７には、通常、ＴＳパケット列４１、すなわち、この場合、７個のＴＳパケット５１が記憶されることになるが、エラーなどが発生した場合には、７個以下のＴＳパケット５１のみが記憶されるときがある。
【００７８】
記憶部８７は、バッファとしての役割を有し、順次記憶されているＴＳパケット５１を、ＭＰＥＧデコーダ８８に出力する。ＭＰＥＧデーコーダ８８は、順次、供給されたＴＳパケット５１に対し、ＭＰＥＧ方式に基づくデコードを施す。ＭＰＥＧデコーダ８８からの出力は、図示されていないディスプレイやスピーカに供給され、ユーザに映像や音声として提供される。
【００７９】
ここで、記憶部８７に記憶されているデータについて説明する。図１０は、記憶部８７に記憶されているデータのデータ構成を説明するための図である。上述したように、記憶部８７には、ＲＴＰヘッダ４２内に含まれるシークエンスナンバーと、そのシークエンスナンバーのＲＴＰパケットに含まれているＴＳパケットが関連付けられて記憶されている。
【００８０】
なお、記憶部８７に記憶させるシークエンスナンバーは、シークエンスナンバーそのものでも良いし、シークエンスナンバーを一意に導き出せるデータでも良い。
【００８１】
例えば、図１０に示したように、シークエンスナンバー“１”には、ＴＳパケット５１―１−１乃至５１−７―１（ここでの符号における最後の数字は、シークエンスナンバーを示す（同一の値）とする）が関連付けられて記憶されている。
【００８２】
これは、上述したように、本実施の形態においては、１つのＲＴＰパケット（受信機２側で受信されるＭＡＣパケット）には、７個のＴＳパケット５１−１乃至５１−７（図３）を含むと設定しているからであり、例えば、８個のＴＳパケットを含むと設定されている場合には、シークエンスナンバー“１”には、ＴＳパケット５１−１―１乃至５１−８―１の８個のＴＳパケットが関連付けられて記憶されることになる。
【００８３】
図１０に示した例を再度参照するに、同じくシークエンスナンバー“２”には、同じく７個のＴＳパケット５１−１―２乃至５１−７―２が関連付けられている。しかしながら、シークエンスナンバー“３”の欄には、本来ならば、ＴＳパケット５１−１―３乃至５１−７―３が関連付けられて記憶されるが、図１０に示した例では、ＴＳパケットが記憶されていない。これに対し、シークエンスナンバー“４”には、ＴＳパケット５１−１―４乃至５１―７−４が関連付けられて記憶されている。
【００８４】
このように、記憶部８７には、正常に受信され処理されると、シークエンスナンバーと関連付けられてＴＳパケット５１（ＴＳパケット列４１）が、所定の領域に記憶される。記憶部８７には、シークエンスナンバー順に、ＴＳパケットが所定の領域に記憶されるようになっている。一方、何らかの原因で、正常に受信が行われなかったシークエンスナンバーの領域（この場合、例えば、シークエンスナンバー“３”の領域）は、何も記憶されない状態で確保されている。
【００８５】
このように、記憶部８７には、ＴＳパケットが記憶されている領域を有するシークエンスナンバーと、ＴＳパケットが記憶されていない領域を有するシークエンスナンバーとが混在する。そこで、ＴＳパケットが記憶されているか否かを示すフラグを用いて、ＴＳパケットが記憶されている領域を有するシークエンスナンバーと、そうでないシークエンスナンバーとを区別できるようにしても良い。また、そのようなフラグを、後述する処理において用いるようにしても良い。
【００８６】
図２に示したような構成を有する送信機１と、図９に示したような構成を有する受信機２において、図３乃至８を参照して説明したデータが授受される際の送信機１と受信機２の動作について説明する。まず、送信機１の動作について説明する。
【００８７】
送信機１は、アンテナ３（図１）により受信されたテレビジョン放送のデータに、所定のヘッダを付加し、受信機２に対して送信するわけだが、その送信されるデータのうち、所定のデータは、複数回（ここでは、説明の都合上、２回として説明する）送信される。１回目の送信にかかわる処理について説明する。
【００８８】
まず、アンテナ３により受信されたテレビジョン放送のデータは、ＭＰＥＧエンコーダ２１により、ＭＰＥＧ方式に基づくエンコードが施され、ＴＳパケット５１として、ＲＴＰヘッダ付加部２２に出力される。ＲＴＰヘッダ付加部２２は、入力されたＴＳパケット５１を７個単位にまとめ、ＴＳパケット列４１を生成する。そして、ＲＴＰヘッダ付加部２２は、生成したＴＳパケット列４１に対してＲＴＰヘッダ４２を付加する。
【００８９】
ＲＴＰヘッダ４２が付加されたＲＴＰパケットは、ＵＤＰヘッダ付加部２３と冗長化制御部２７に供給される。ここで、ＵＤＰヘッダ付加部２３と冗長化制御部２７に供給されるＲＴＰパケットについて説明する。図１１と図１２は、ＲＴＰパケットの構成を示す図である。
【００９０】
図１１は、ＴＳパケット列１０１にＲＴＰヘッダ１０２が付加されたＲＴＰパケットの構成を示している。図１１に示したＲＴＰパケットに含まれるＴＳパケット列１０１は、ヘッダ１０３−１乃至１０３−７がそれぞれ付加されたビデオデータ１０４−１乃至１０４−７から構成されている。ヘッダ１０３−１乃至１０３−７は、図４に示したヘッダ部６１に示すようなデータを含むが、そのうち、“ＰＩＤ”のデータは、この場合、“１００ｈ”に設定されている。
【００９１】
図４を参照して説明したように、ヘッダ部６１に含まれる“ＰＩＤ”の値は、ヘッダ部６１に続くデータ部６２のデータに依存して決定される値である。この場合、データ部６２のデータがビデオデータである場合、ＰＩＤの値は、“１００ｈ”と設定されるとして説明し、データ部６２のデータがオーディオデータである場合、ＰＩＤの値は、“１０２ｈ”と設定されるとして説明する。
【００９２】
このＰＩＤの値は、送信機１と受信機２との間で識別できる値に設定されていればよい。また、このＰＩＤの値は、ＭＰＥＧエンコーダ２１で設定される。
【００９３】
図１１に示したＴＳパケット列１０１に含まるＴＳパケットのデータ部６２は、全てビデオデータであるので、それぞれのヘッダ１０３−１乃至１０３−７の“ＰＩＤ”は、全て“１００ｈ”に設定されている。
【００９４】
これに対し、図１２に示したＴＳパケット列１１１には、オーディオデータ１１４−３が含まれている。そのオーディオデータ１１４−３に付加されたヘッダ１１３−３の“ＰＩＤ”の値は、“１０２ｈ”と設定されている。
【００９５】
通常、ビデオにかかわるデータの方が、オーディオにかかわるデータよりも大きいサイズとなるため、図１１に示したように、ＴＳパケット列１０１に含まれるＴＳパケットは、ビデオデータにかかわるパケットのみから構成されるか、図１２に示したように、ＴＳパケット列１１１に含まれるＴＳパケットのうち、１個または複数個のパケットのみが、オーディオデータにかかわるパケットを含む構成とされることが多い。
【００９６】
図１１に示したＲＴＰパケットの“Ｓｅｑｕｅｎｃｅ Ｎｕｍｂｅｒ”は、“１２３４ｈ”と割り振られている。仮に、図１２に示すＲＴＰパケットが、図１１に示したＲＴＰパケットの時間的に直後に生成されるＲＴＰパケットである場合、ＲＴＰヘッダ１１２の“Ｓｅｑｕｅｎｃｅ Ｎｕｍｂｅｒ”は、“１２３５ｈ”と割り振られる。すなわち、連続した番号が割り振られる。
【００９７】
図１１に示したようなビデオデータのみから構成されるＲＴＰパケット、または、図１２に示したようなビデオデータとオーディオデータから構成されるＲＴＰパケットが、ＲＴＰヘッダ付加部２２により生成され、ＵＤＰヘッダ付加部２３と冗長化制御部２７に供給される。ＵＤＰヘッダ付加部２３は、供給されたＲＴＰパケットにＵＤＰヘッダを付加し、ＩＰヘッダ付加部２４に供給する。ＩＰヘッダ付加部２４は、供給されたＵＤＰパケットにＩＰヘッダを付加し、ＭＡＣヘッダ付加部２５に供給する。
【００９８】
ＭＡＣヘッダ付加部２５は、供給されたＩＰパケットにＭＡＣヘッダを付加し、通信部２６に供給する。通信部２６にＭＡＣパケットが供給されることにより、受信機２に対して１回目の送信が行われる。
【００９９】
次に、図１３のフローチャートを参照して、２回目の送信にかかわる送信機１の動作について説明する。図１３に示したフローチャートは、主に、冗長化制御部２７において行われる。また、図１３に示したフローチャートの処理は、ＲＴＰヘッダ付加部２２から出力されたＲＴＰパケット毎に行われる。更に、図１３に示したフローチャートの処理では、オーディオデータのみが２回目の送信の対象となるとして説明する。
【０１００】
ステップＳ１１において、冗長化制御部２７は、ＲＴＰヘッダ付加部２２から供給されたＲＴＰパケット内に、オーディオデータが含まれているか否かを判断する。冗長化制御部２７に供給されたＲＴＰパケットが、図１１に示すような、ビデオデータ１０４−１乃至１０４−７のみから構成されるＴＳパケット列１０１を含むようなＲＴＰパケットである場合、ステップＳ１１においては、ＮＯと判断される。
【０１０１】
冗長化制御部２７に供給されたＲＴＰパケットが、図１２に示すような、オーディオデータ１１４−３が含まれているＴＳパケット列１１１を含むＲＴＰパケットである場合、ステップＳ１１においては、ＹＥＳと判断される。
【０１０２】
冗長化制御部２７は、供給されたＲＴＰパケット内に、オーディオデータを含むか否かの判断を、各ＴＳパケットに含まれるヘッダの“ＰＩＤ”を参照することにより行う。すなわち、この場合、“ＰＩＤ”が、“１００ｈ”に設定されているＴＳパケットのデータは、ビデオデータであると判断され、“ＰＩＤ”が、“１０２ｈ”に設定されているＴＳパケットのデータは、オーディオデータであると判断される。
【０１０３】
ステップＳ１１において、冗長化制御部２７は、供給されたＲＴＰパケットに、オーディデータは含まれていないと判断した場合、そのＲＴＰパケットを破棄し、そのＲＴＰパケットに対する処理（図１３に示したフローチャートの処理）を終了する。
【０１０４】
一方、ステップＳ１１において、冗長化制御部２７は、供給されたＲＴＰパケットに、オーディデータが含まれていると判断した場合、ステップＳ１２に処理を進め、供給されたＲＴＰパケットから、ＲＴＰヘッダとオーディオデータ（そのオーディオデータを含むＴＳパケット）を抽出し、記憶部２８に記憶させる。
【０１０５】
この処理について図１４Ａおよび図１４Ｂを参照して説明する。図１４Ａは、図１２と同一のＲＴＰパケットを示している。図１４Ａに示したＲＴＰパケットのＴＳパケット列１１１には、オーディオデータ１１４−３（“ＰＩＤ”が“１０２ｈ”に設定されているヘッダ１１３−３）が含まれている。また、このオーディオデータ１１４−３を含むＴＳパケット列１１１のＲＴＰヘッダ１１２のシークエンスナンバーは、“１２３５ｈ”に設定されている。
【０１０６】
このようにＲＴＰパケットにオーディオデータ１１４−３が含まれているような場合、記憶部２８には、図１４Ｂに示すように、供給されたＲＴＰヘッダ１１２、オーディオデータ１１４−３、および、そのオーディオデータ１１４−３に付加されているヘッダ１１３−３が供給され、記憶される。
【０１０７】
また、記憶部２８に記憶される際、この場合、オーディオデータ１１４−３とヘッダ１１３−３のみを含むＴＳパケット列１２１が生成されて、ＲＴＰヘッダ１１２が付加された状態で記憶される。
【０１０８】
なお、冗長化制御部２７が、図１４Ａに示したＲＴＰパケットから、図１４Ｂに示したＲＴＰパケットを生成する際、不必要なデータ（この場合、ビデオデータとそのビデオデータに付加されているヘッダ）を除去することで生成するようにしても良いし、必要なデータ（この場合、オーディオデータとそのオーディオデータに付加されているヘッダ）を抽出することにより生成するようにしても良い。
【０１０９】
このようにして、記憶部２８にオーディオデータのみが含まれるＲＴＰパケットが記憶されると、ステップＳ１３において、冗長化制御部２７は、所定の数のＲＴＰパケットが出力されたか（供給されたか）の判断を行う。所定の数のＲＴＰパケットが供給されたか否かの判断は、冗長化制御部２７が、供給されたＲＴＰパケットの数をカウントすることによって行われるようにしても良い。
【０１１０】
または、ＲＴＰパケットのＲＴＰヘッダ４２に含まれるシークエンスナンバーが参照されて行われるようにしても良い。例えば、記憶部２８に記憶させたＲＴＰパケットのシークエンスナンバーの値に、所定の数を加算し、その加算した値のシークエンスナンバーを含むＲＴＰパケットが供給されたか否かを判断することにより、ステップＳ１３における処理が行われるようにしても良い。
【０１１１】
ステップＳ１３において、冗長化制御部２７が、所定の数のＲＴＰパケットが供給されたと判断すると、ステップＳ１４に処理が進められる。なお、このステップＳ１３における判断が行われている間に冗長化制御部２７に供給されたＲＴＰパケットに対しても、図１３に示したフローチャートの処理は実行されている。
【０１１２】
ステップＳ１４において、ステップＳ１２の処理で記憶部２８に記憶されたオーディオデータのみを含むＴＳパケット列を含むＲＴＰパケットが読み出される。この場合、例えば、図１４Ｂに示したようなＴＳパケット列１２１とそのＴＳパケット列１２１に付加されているＲＴＰヘッダ１１２が読み出される。
【０１１３】
読み出されたＲＴＰパケットは、ＵＤＰヘッダ付加部２３に供給される。このようにして、ＵＤＰヘッダ付加部２３にＲＴＰパケットが供給された後の処理は、上述した１回目の送信の場合と同様に行われる。
【０１１４】
すなわち、ステップＳ１５の処理として、ＵＤＰヘッダ付加部２３、ＩＰヘッダ付加部２４、およびＭＡＣヘッダ付加部２５の各部で、記憶部２８からのＲＴＰパケットに対してヘッダが付加される。そして、ステップＳ１６の処理として、通信部２６により、ＭＡＣパケットが受信機２に対して送信される。
【０１１５】
このようにして、２回目の送信が行われる。ここでは、図１２に示したようなＲＴＰパケットを含むデータ（ＭＡＣパケット）が送信された後、図１４Ｂに示したようなＲＴＰパケットを含むデータが送信されるため、オーディオデータ１１４−３は、２度、受信機２に対して送信されたことになる。
【０１１６】
このように、本実施の形態においては、受信機２に対して、同一のオーディオデータが、２度送信される。ここでは、２度送信されるとして説明するが、２回以上、送信されるようにしても良い。具体的には、ステップＳ１３乃至Ｓ１６の処理が、記憶部２８に記憶されている１つのＲＴＰパケットに対して、繰り返し行われることにより、複数回の送信が可能とされる。
【０１１７】
このようにして複数回、同一のオーディオデータが送信される理由について説明する。送信機１と受信機２との間の通信は、無線により行われるわけだが、無線で行われるために、有線で行われる場合と比較して、その通信の安定性は、劣るという欠点がある。例えば、送信機１と受信機２との間に、遮蔽物が存在するると、通信状態が悪化する可能性がある。また、そのために、通信しているデータが、受信機２側で受信できないといったことが発生する可能性がある。
【０１１８】
ビデオデータは、多少のデータの欠落があっても、ユーザ側に提供される映像がとぎれるといったような不都合があまり発生しないように、例えば、デコードの際に処理されるようになっている。しかしながら、オーディオデータは、欠落したデータがあると、たとえ、ビデオデータに施されるような処理が施されるようにしたとしても、ユーザ側に提供される音声がとぎれてしまうなどの不都合が発生する可能性が高かった。
【０１１９】
このような理由から、ビデオデータよりもオーディオデータの方が、データが欠落するとより影響がでやすいため、上述した実施の形態では、オーディオデータのみを複数回送信するように構成した。また、上述した実施の形態として、オーディオデータのみを複数回送信するようにしたのは、データ量にかかわる理由もある。
【０１２０】
すなわち、ビデオデータは、オーディオデータに対して、そのデータ量は大きい。そのため、仮に、ビデオデータまで複数回送信するようにすると、すなわち、全てのデータを複数回送信するようにすると、送信機１の送信能力または受信機２の受信能力、または、その両方の能力を超えてしまう可能性がある。
【０１２１】
送信機１の送信能力と、受信機２の受信能力が、それぞれ、全てのデータを複数回送信するだけの能力であれば、全てのデータを複数回送信する（受信する）ようにしても良い。
【０１２２】
全てのデータを複数回送信するようにした場合、図１３に示したフローチャートの処理のうち、ステップＳ１１における判断を行なわず、全てのＲＴＰパケットを、一旦、記憶部２８に記憶させるようにし、基本的に同様な処理が実行されるようにすれば、全てのデータの複数回の送信が可能となる。
【０１２３】
なお、全てのデータを複数回送信するようにした場合、ＲＴＰパケットではなく、ＭＡＣパケットが記憶部２８に記憶されるようにしても良い。すなわち、記憶部２８は、ＭＡＣヘッダ付加部２５から出力されるＭＡＣパケットを記憶し、その記憶されているＭＡＣパケットが、通信部２６に出力されるように送信機１が構成されるようにすればよい。
【０１２４】
ここでは、オーディオデータのみが複数回（２回）送信されるとして、説明を続ける。
【０１２５】
このように、送信機１からは、同一のオーディオデータが、少なくとも２回送信される。１回目の送信が行われた後（通常のタイミングで送信が行われた後）、２回目の送信が行われるタイミング（冗長化させるための送信が行われるタイミング）は、ステップ１３（図１３）の処理で決定（制御）される。
【０１２６】
図１５は、１回目の送信が行われた直後に、２回目の送信が行われた場合のＲＴＰパケットの並びを示す図である。ここでは、図１１に示したＲＴＰパケットが送信された後（冗長化制御部２７による処理が行われた後）に、図１２に示したＲＴＰパケットが送信されるとして説明する。
【０１２７】
図１１に示したＲＴＰパケットのＲＴＰヘッダ１０２のシークエンスナンバーは、“１２３４ｈ”である。このＲＴＰヘッダ１０２が付加されているのはＴＳパケット列１０１である。次に送信（処理）されるのは、図１２に示したＲＴＰパケットであるので、そのＲＴＰヘッダ１１２のシークエンスナンバーは、“１２３５ｈ”であり、そのＲＴＰヘッダ１１２が付加されているのは、ＴＳパケット列１１１である。
【０１２８】
図１２に示したＲＴＰパケットには、オーディオデータが含まれている。よって、冗長化制御部２７の制御により、記憶部２８には、図１４Ｂに示しようなＲＴＰパケットが記憶される。記憶されたＲＴＰパケット、すなわち、この場合、ＲＴＰヘッダ１１２が付加されたＴＳパケット列１２１は、図１５に示すように、ＴＳパケット列１１１の後に送信されるように制御される。
【０１２９】
図１５に示した例で、ＲＴＰヘッダだけに注目すると、同じシークエンスナンバー“１２３５ｈ”を有するＲＴＰヘッダ１１２が、連続して送信されることになる。このような場合、図１３に示したフローチャートの処理のうち、ステップＳ１３の処理が行われる必要はない。この場合、記憶部２８に記憶されたＲＴＰパケットが、同じシークエンスナンバーを有するＲＴＰパケットが、ＵＤＰヘッダ付加部２３から出力された直後に、ＵＤＰヘッダ付加部２３に供給されるように制御されればよい。
【０１３０】
しかしながら、何らかの原因で、受信機２側で送信されてきたデータが受信できないような状況、すなわち、パケットが欠落してしまうような状況は、すぐに改善されるものではないと考えられる。換言すれば、パケットの欠落が発生するような状況では、１つのパケットだけが欠落するのではなく、続けて複数のパケットが欠落すると考えられる。一例として、経験的な値を挙げると、パケットの欠落が発生したときは、１０乃至１５個のＲＴＰパケットが連続して欠落する可能性が高い。
【０１３１】
このようなことを考慮すると、パケットの欠落が発生したときに対応するために、少なくともオーディオデータだけは、複数回送信するようにしても、その送信するタイミングを考慮しなければ、意味のない送信処理となってしまう。
【０１３２】
例えば、図１５を再度参照するに、ＲＴＰヘッダ１１２が付加されているＲＴＰパケットが欠落したような場合、その直後に同一のＲＴＰヘッダ１１２が付加されているＲＴＰパケットを送信したとしても、その２度目の送信のＲＴＰパケット自体も欠落してまう可能性が高いことになる。よって結果として、欠落に対応するために送信したパケット自体も欠落してしまう可能性が高く、意味のない送信を繰り返すことになる可能性が高い。
【０１３３】
更に換言するならば、パケットの欠落が発生したときに対応するために、少なくともオーディオデータだけは、２回送信するようにした場合、１回目の送信が行われた後、例えば、１５個のＲＴＰパケットが送信された後に、２回目の送信が行われるようにする。このように１回目の送信と２回目の送信との間に、所定の間隔を設けることにより、１回目の送信により送信されたＲＴＰパケットが欠落してしまっても、２回目の送信により送信されたＲＴＰパケットが受信される可能性を高めることが可能となる。
【０１３４】
このようなことを考慮し、ステップＳ１３（図１３）の処理が設けられている。従って、ステップＳ１３における処理は、所定の数のＲＴＰパケットとして、例えば、１５個のＲＴＰパケットと設定され、１５個のＲＴＰパケットが供給されたか否かが冗長化制御部２７により判断されるようにすればよい。
【０１３５】
このように、所定の数のＲＴＰパケットが送信された後に、２回目の送信が行われるようにしたときのＲＴＰパケットの並びを図１６に示す。図１６に示した例で、ＲＴＰヘッダに注目すると、ＲＴＰヘッダ１０２、ＲＴＰヘッダ１１２、および、ＲＴＰヘッダ１３２の、それぞれのシークエンスナンバーは、その順序で、連続した値とされている。すなわち、処理された順に、送信されることを示す。
【０１３６】
そして、所定の数のＲＴＰパケットが送信された後に、再度、シークエンスナンバーが“１２３５ｈ”のＲＴＰヘッダ１１２が送信される。仮に、ＲＴＰヘッダ１０２が送信された直後のＲＴＰヘッダ１１２（ＴＳパケット列１１１）が、何らかの原因で、欠落したとしても、所定の数のＲＴＰパケットが送信された後送信される、同一のＲＴＰヘッダ１１２（ＴＳパケット列１２１）の方は、通信状態が改善され、受信される可能性が高い。
【０１３７】
よって、１回目の送信または２回目の送信により送信されたパケットのうち、少なくとも一方を受信できれば、この場合、オーディオデータの欠落は、実質的にないことになり、ユーザに提供される音声がとぎれるといったような不都合を防ぐことが可能となる。
【０１３８】
次に、このようにして、所定のデータが、複数回送信されてくる受信機２側の処理について説明する。図１７は、受信機２の動作について説明するためのフローチャートである。ステップＳ３１において、通信部８１（図９）により受信された送信機１から送信されたデータ（ＭＡＣパケット）は、ＭＡＣヘッダ抽出部８２に供給される。
【０１３９】
ＭＡＣヘッダ抽出部８２は、供給されたＭＡＣパケットからＭＡＣヘッダ４５を抽出し、ＩＰパケットをＩＰヘッダ抽出部８３に供給する。ＩＰヘッダ抽出部８３は、供給されたＩＰパケットからＩＰヘッダ４４を抽出し、ＵＤＰパケットをＵＤＰヘッダ抽出部８４に供給する。ＵＤＰヘッダ抽出部８４は、供給されたＵＤＰパケットからＵＤＰヘッダ４３を抽出し、ＲＴＰパケットを順序再構成部８５に供給する。
【０１４０】
このようにして、各部において各ヘッダが抽出される。各部は、抽出したヘッダを用いた所定の処理を行うが、本発明においては、その処理については直接的な関係がないため、その処理に関する説明は省略する。
【０１４１】
順序再構成部８５は、ステップＳ３２において、供給されたＲＴＰパケット内に含まれるＲＴＰヘッダ４２を参照する。このとき参照されるのは、ＲＴＰヘッダ４２内のシークエンスナンバー（Ｓｅｑｕｅｎｃｅ Ｎｕｍｂｅｒ）である。順序再構成部８５は、ステップＳ３３において、参照したシークエンスナンバーに関連付けられて、ＴＳパケットが既に記憶されているか否かを、記憶部８７を参照して判断する。
【０１４２】
図１０を参照して既に説明したように、記憶部８７には、シークエンスナンバーと、そのシークエンスナンバーを有するＲＴＰヘッダ４２が付加されていたＴＳパケット列４１（図３）が、関連付けられて記憶されている。そこで、順序再構成部８５は、ステップＳ３２およびステップＳ３３の処理として、供給されたＲＴＰパケットのＲＴＰヘッダ４２に含まれるシークエンスナンバーを参照し、そのシークエンスナンバーに関連付けられてＴＳパケット列４１が、記憶部８７に記憶されているか否かを判断する。
【０１４３】
ステップＳ３３において、供給されたＲＴＰヘッダ４２に含まれるシークエンスナンバーに関連付けられたＴＳパケット列４１は、記憶部８７に記憶されていないと判断すると、ステップＳ３４に処理が進められる。ステップＳ３４において、順序再構成部８５は、供給されたＲＴＰパケットをＲＴＰヘッダ抽出部８６に供給する。
【０１４４】
ＲＴＰヘッダ抽出部８６は、供給されたＲＴＰパケットからＲＴＰヘッダ４２を抽出し、ＴＳパケット列４１を記憶部８７に供給し、記憶させる。この際、ＲＴＰヘッダ４２に含まれるシークエンスナンバーに関連付けられて、ＴＳパケット列４１は記憶部８７に記憶される。
【０１４５】
この記憶までの処理について説明を加えるに、順序再構成部８５が、供給されたＲＴＰヘッダ４２のシークエンスナンバーに関連付けられ、ＴＳパケット列４１が、記憶部８７に記憶されてはいないと判断する状況としては、２つの状況が考えられる。
【０１４６】
１つ目の状況としては、新たに供給されたＲＴＰパケット（ＴＳパケット列４１）であるために、まだ、その時点では、記憶部８７には記憶されていないという状況である。２つ目の状況としては、既に、本来ならば受信され、処理され、記憶されているＴＳパケット列４１が、何らかの原因で、受信されなかったために、すなわち、そのＴＳパケット列４１が欠落したために、記憶部８７に記憶されていないという状況である。
【０１４７】
２つ目の状況では、既に、シークエンスナンバー自体は、記憶部８７に記憶されている状態である。図１０を再度参照するに、シークエンスナンバー“３”に関連付けて記憶されるＴＳパケット列４１（ＴＳパケット５１−１−３乃至５１−７−３）は、欠落したために記憶されていない状態である。このように、欠落したと判断されるパケットを記憶させるための領域は、シークエンスナンバーと関連付けられて管理されている（確保されている）。
【０１４８】
このような２つ目の状況のときにステップＳ３４に処理が進められたときには、順序再構成部８５（若しくは、ＲＴＰヘッダ抽出部８６）は、供給されたＲＴＰパケットに含まれるＴＳパケット列４１が、その供給されたＲＴＰパケットのＲＴＰヘッダ４２に含まれるシークエンスナンバーと関連付けられて記憶部８７に既に確保されている領域に記憶されるように制御する。
【０１４９】
すなわちこの場合、後に受信されたＴＳパケット列４１が、その時点で処理されているＴＳパケット列４１よりも先に、ＭＰＥＧデコーダ８８に供給されるような領域に記憶されることになる。
【０１５０】
ただし、後に受信される（２度目の送信で送信されてきた）ＴＳパケット列４１には、ここでは、オーディオデータしか含まれていないので、そのオーディオデータを含むＴＳパケット５１のみが記憶される。ビデオデータも複数回送信されるようにすれば、ビデオデータも記憶される（従って、ＴＳパケット列４１が記憶される）。
【０１５１】
このようにして、欠落したパケットであっても、後の時点で再度送信されてくるパケットが受信、処理されれば、記憶部８７に記憶されることになる。従って、パケットが欠落したような状況でも、その欠落による影響を受けないようにさせることが可能となる。
【０１５２】
図１７に示したフローチャートの説明に戻り、ステップＳ３３において、順序再構成部８５が、供給されたＲＴＰヘッダ４２に含まれるシークエンスナンバーに対応するＴＳパケット列４１は、既に、記憶部８７に記憶されていると判断した場合、ステップＳ３５に処理が進められる。
【０１５３】
このような状況は、再送されてきたパケットを受信したときであり、かつ、１回目の送信により送信されてきたパケットも正常に受信され、処理され、記憶された状態であることを示している。このような状況では、再度、記憶部８７に記憶させる処理を実行する必要はないので、ステップＳ３５の処理として、順序再構成部８５は、供給されたＲＴＰパケットを破棄する。
【０１５４】
このような処理が受信機２側で行われることにより、パケットの欠落が発生したような状況でも、再度送信されてくるパケットを受信し、処理すれば、その欠落による発生する影響を低減さえることが可能となり、かつ、パケットの欠落に対する処理に多大な能力をさくようなことを防ぐことも可能となる。
【０１５５】
ところで、上述した実施の形態においては、複数回（２回）送信されるとして説明したが、複数回送信される場合、その回数に制限を設ける必要がある。また、２回だけ送信される場合であっても、１回目の送信と、２回目の送信の間を、時間的にどの程度あけるかが問題となる。
【０１５６】
このようなことを考慮すべき理由について説明する。記憶部８７に記憶されているＴＳパケットは、順次、ＭＰＥＧデコーダ８８に供給される。
【０１５７】
図１０を再度参照するに、シークエンスナンバー“１”に関連付けられているＴＳパケット５１−１−１乃至５１−７−１が、ＭＰＥＧデコーダ８８に供給された後に、シークエンスナンバー“２”に関連付けられているＴＳパケット５１−１−２乃至５１−７−２がＭＰＥＧデコーダ８８に供給される。
【０１５８】
その後、シークエンスナンバー“３”に関連付けられているＴＳパケットが、ＭＰＥＧデコーダ８８に供給されるが、供給される時点で、記憶されていなければ、供給することができず、そのシークエンスナンバー“３”に関連付けられているＴＳパケットが供給されることなく、次のシークエンスナンバー“４”に関連付けられているＴＳパケット５１−１−４乃至５１−７−４が供給される。
【０１５９】
このようなことを換言すれば、シークエンスナンバー“４”に関連付けられているＴＳパケットがＭＰＥＧデコーダ８８に供給されるより前の時点までに、シークエンスナンバー“３”に関連付けられるＴＳパケットが、記憶部８７に記憶されなければ、その後の時点で、シークエンスナンバー“３”に関連付けられるＴＳパケットを取得する必要はなく、そのための処理も行われる必要はない。
【０１６０】
このようなことを考慮すれば、送信機１から複数回同一のパケットが送信されるようにした場合、その複数回送信される回数は、受信機２の記憶部８７が記憶できる容量に依存して、決定される必要がある。
【０１６１】
例えば、記憶部８７の記憶容量が、１秒間分のパケットデータを記憶できるだけの容量である場合、送信機１が、１秒以上経過した後に、同一のパケットを送信しても意味がないことになる。そこで、例えば、１００ミリ秒毎に、同一のパケットが送信される設定にされているような場合（ステップＳ１３（図１３）の処理で、１００ミリ秒の間に処理されるＲＴＰパケットの個数が設定されているような場合）、複数回の送信の回数として９回と設定されていればよい。
【０１６２】
すなわち、１０回目の送信は、たとえ送信が実行され、受信機２側で受信されても、意味のない処理が行われることになるので、その１０回目の送信が行われないような制限が設定されていればよい。また、２回だけ送信が行われると設定されているような場合、１秒間の間に２回の送信が行われる（完了する）ように設定されていればよい。
【０１６３】
なお、複数回送信する際の回数や、送信する間隔は、上述したことの他に、受信機２側で、パケットを受信してから記憶するまでの時間や、そのパケットの送受信にかかる時間なども考慮して設定される方が好ましい。
【０１６４】
ここで、受信機２の動作について更に説明を加える。上述した実施の形態においては、ステップＳ３３（図１７）の処理は、順序再構成部８５が、記憶部８７を参照することにより行うとして説明したが、記憶部８７が参照されずに行われるようにしても良い。そのようにした場合について説明する。
【０１６５】
順序再構成部８５は、供給されたＲＴＰパケットのＲＴＰヘッダ４２のうち、シークエンスナンバーを参照する。そこで、その参照したシークエンスナンバーを記憶する機能を順序再構成部８５自体が備えるようにする。そのようにすれば、順序再構成部８５は、供給されたＲＴＰヘッダ４２に含まれるシークエンスナンバーは、既に自己が記憶しているシークエンスナンバーであるか否かを判断することにより、ステップＳ３３の処理を行うことができる。
【０１６６】
このようにした場合でも、その他の処理は、基本的に、既に説明した場合と同様であるので、その説明は省略する。
【０１６７】
また順序再構成部８５が、供給されたＲＴＰヘッダ４２のシークエンスナンバーを参照することを用い、以下のような処理で、ステップＳ３３の処理が行われるようにしても良い。すなわち、まず、順序再構成部８５は、供給されたＲＴＰヘッダ４２に含まれるシークエンスナンバーが、１つ前の時点で供給されたＲＴＰヘッダ４２に含まれるシークエンスナンバーに連続した番号であるか否かを判断する。
【０１６８】
シークエンスナンバーは、送信機１側で、処理した順に、昇順（または降順、ここでは、昇順として説明する）の番号が割り振られ、その順で送信される。従って、受信機２側では、送信された順に受信され、処理される。しかしながら、パケットの欠落が発生すると、シークエンスナンバーの番号が飛ぶことになる。すなわち、連続性がとぎれることになる。
【０１６９】
そこで、順序再構成部８５が、シークエンスナンバーの連続性を判断するようにし、連続性がとぎれたと判断した場合、そのとぎれた部分に存在すべきシークエンスナンバーの番号を算出し、記憶する。また、順序再構成部８５は、連続性がとぎれたと判断したときには、その時点で自己が記憶している番号内に、供給されているＲＴＰヘッダ４２のシークエンスナンバーと一致する番号が存在するか否かを判断する。
【０１７０】
このような判断を経て、順序再構成部８５が、供給されたＲＴＰヘッダ４２のシークエンスナンバーと一致する番号が、自己が記憶している番号内に存在すると判断した場合、すなわち、欠落したパケットだが、再送されてきたことにより受信できたパケットであると判断した場合、その供給されたＲＴＰパケットに含まれるＴＳパケット列４１が、記憶部８７の所定の領域に記憶されるように制御が行われる。
【０１７１】
このようにして、複数回送信されてきたパケットに対する処理が行われるようにしても良い。
【０１７２】
上述した実施の形態では、オーディオデータが複数回送信されるとして説明したが、ビデオデータが複数回送信されるようにしてもよいし、ビデオデータも複数回送信されるようにしても良い。また、オーディオデータやビデオデータと異なる、他のデータ（例えば、ヘッダに含まれる情報など）が、複数回送信されるようにしても良い。
【０１７３】
例えば、文字放送用のデータやＥＰＧ（Ｅｌｅｃｔｒｏｎｉｃ Ｐｒｏｇｒａｍ Ｇｕｉｄｅ）のデータなどのデータが、複数回送信されるようにしても良い。オーディオデータ以外の所定のデータを複数回送信するようにした場合、図１３のステップＳ１１の処理として、その所定のデータが含まれるか否かが判断されるようにすればよい。そして、上述したような、ステップＳ１１以下の処理が行われるようにすれば良い。
【０１７４】
この複数回送信されるデータとしては、上述した実施の形態では、オーディオデータとしたが、オーディオデータを複数回送信するようにしたのは、オーディオデータの方がビデオデータに対して、そのデータ量は小さく、複数回送信したとしても、その処理に係る処理により、他の処理に影響与えることが少ないと考えられるからである。
【０１７５】
そのような考えにもとづくと、本発明の一実施の形態としては、比較的データ量の小さいデータを複数回送信することになる。よって、オーディオデータに限らず、データ量の小さいデータを複数回送信する場合にも本発明を適用することができる。
【０１７６】
データ量の小さいデータを判断するのは、予めデータ量が比較的小さいとされる種類のデータを設定しておき（上述した実施の形態ではオーディオデータといる種類）、その種類のデータが、取得されたデータ内に含まれているか否かを判断するようにしても良い。または、所定のデータ量を設定しておき（閾値を設定しておき）、その設定されている所定のデータ量以下のデータを含むか否かを判断するようにしても良い。
【０１７７】
そして、判断された結果、記憶されるデータが、複数回送信されるようにしても良い。
【０１７８】
上述したように、所定のデータを時間的にずらしたタイミングで、複数回送信するようにすることで、データの欠落が発生したようなときでも、ユーザに提供される映像や音声がとぎれるといった不都合が発生することを低減させることが可能となる。もって、送信機１と受信機２の間で行われる通信の信頼性を向上させることが可能となる。
【０１７９】
上述した一連の処理は、それぞれの機能を有するハードウェアにより実行させることもできるが、ソフトウェアにより実行させることもできる。一連の処理をソフトウェアにより実行させる場合には、そのソフトウェアを構成するプログラムが専用のハードウェアに組み込まれているコンピュータ、または、各種のプログラムをインストールすることで、各種の機能を実行することが可能な、例えば汎用のパーソナルコンピュータなどに、記録媒体からインストールされる。
【０１８０】
記録媒体の説明をする前に、簡便にパーソナルコンピュータについて説明する。図１８は、汎用のパーソナルコンピュータの内部構成例を示す図である。パーソナルコンピュータのＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）２０１は、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）２０２に記憶されているプログラムに従って各種の処理を実行する。ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）２０３には、ＣＰＵ２０１が各種の処理を実行する上において必要なデータやプログラムなどが適宜記憶される。入出力インタフェース２０５は、キーボードやマウスから構成される入力部２０６が接続され、入力部２０６に入力された信号をＣＰＵ２０１に出力する。また、入出力インタフェース２０５には、ディスプレイやスピーカなどから構成される出力部２０７も接続されている。
【０１８１】
さらに、入出力インタフェース２０５には、ハードディスクなどから構成される記憶部２０８、および、インターネットなどのネットワークを介して他の装置とデータの授受を行う通信部２０９も接続されている。ドライブ２１０は、磁気ディスク２２１、光ディスク２２２、光磁気ディスク２２３、半導体メモリ２２４などの記録媒体からデータを読み出したり、データを書き込んだりするときに用いられる。
【０１８２】
記録媒体は、図１８に示すように、パーソナルコンピュータとは別に、ユーザにプログラムを提供するために配布される、プログラムが記録されている磁気ディスク２２１（フレキシブルディスクを含む）、光ディスク２２２（ＣＤ−ＲＯＭ（Ｃｏｍｐａｃｔ Ｄｉｓｃ−Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ），ＤＶＤ（Ｄｉｇｉｔａｌ Ｖｅｒｓａｔｉｌｅ Ｄｉｓｃ）を含む）、光磁気ディスク２２３（ＭＤ（Ｍｉｎｉ−Ｄｉｓｃ）（登録商標）を含む）、若しくは半導体メモリ２２４などよりなるパッケージメディアにより構成されるだけでなく、コンピュータに予め組み込まれた状態でユーザに提供される、プログラムが記憶されているＲＯＭ２０２や記憶部２０８が含まれるハードディスクなどで構成される。
【０１８３】
なお、本明細書において、媒体により提供されるプログラムを記述するステップは、記載された順序に従って、時系列的に行われる処理は勿論、必ずしも時系列的に処理されなくとも、並列的あるいは個別に実行される処理をも含むものである。
【０１８４】
また、本明細書において、システムとは、複数の装置により構成される装置全体を表すものである。
【０１８５】
【発明の効果】
本発明によれば、通信の信頼性を高めることが可能となる。
【０１８６】
本発明によれば、データの欠落が発生しても、そのデータを補うことが可能となる。もって、ユーザに提供される映像や音声にとぎれや乱れが発生するようなことを抑えることが可能となる。
【図面の簡単な説明】
【図１】本発明を適用した送受信システムの一実施の形態の構成を示す図である。
【図２】送信機の内部構成例を示す図である。
【図３】送信機から送信されるデータについて説明するための図である。
【図４】ＴＳパケットのヘッダについて説明するための図である。
【図５】ＲＴＰヘッダについて説明するための図である。
【図６】ＵＤＰヘッダについて説明するための図である。
【図７】ＩＰヘッダについて説明するための図である。
【図８】ＭＡＣヘッダについて説明するための図である。
【図９】受信機の内部構成例を示す図である。
【図１０】記憶部に記憶されているデータについて説明するための図である。
【図１１】パケットの構成について説明する図である。
【図１２】パケットの構成について説明する図である。
【図１３】冗長化処理について説明するフローチャートである。
【図１４】パケットの構成について説明する図である。
【図１５】パケットの構成について説明する図である。
【図１６】パケットの構成について説明する図である。
【図１７】記憶にかかわる処理について説明するフローチャートである。
【図１８】媒体を説明する図である。
【符号の説明】
１ 送信機， ２１ ＭＰＥＧエンコーダ， ２２ ＲＴＰヘッダ付加部， ２３ ＵＤＰヘッダ付加部， ２４ ＩＰヘッダ付加部， ２５ ＭＡＣヘッダ付加部， ２６ 通信部， ２７ 再送制御部， ２８ 記憶部， ８１ 通信部， ８２ ＭＡＣヘッダ抽出部， ８３ ＩＰヘッダ抽出部， ８４ ＵＤＰヘッダ抽出部， ８５ 順序再構成部， ８６ ＲＴＰヘッダ抽出部， ８７ 記憶部， ８８ ＭＰＥＧデコーダ
【発明の属する技術分野】
本発明は送受信システム、送信装置および方法、受信装置および方法、記録媒体、並びにプログラムに関し、特に、送受信されているパケットが欠落してしまったときに、その欠落を補う装置に用いて好適な送受信システム、送信装置および方法、受信装置および方法、記録媒体、並びにプログラムに関する。
【０００２】
【従来の技術】
ネットワークが普及し、そのネットワークを用いて提供されるサービスも、多岐にわたるようになってきている。ネットワーク自体の構成も、有線で構成されるものや、無線で構成されるものがある。
【０００３】
ネットワークが普及すると共に、そのネットワークにおける通信の信頼性を向上させるために、例えば、同一のデータを異なる経路で伝送するなどして、一方の経路で何らかの異常が発生しても、他方の経路で、通信を確保できるようにし、データの欠落などを防ぐ方法が提案されている。（例えば、特許文献１参照）
【０００４】
【特許文献１】
特開平１１−９８１６１号公報
【０００５】
【発明が解決しようとする課題】
近年では、家庭内におけるネットワークとして、有線によるものより、設置などが手軽な無線ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）が普及しつつある。しかしながら、無線ＬＡＮは、その特性から、有線ＬＡＮに比べて信頼性が劣るという問題があった。
【０００６】
例えば、無線ＬＡＮは、当然ながら、無線によりデータの送受信を行うが、無線で行うために、通信を行っている送信機と受信機の間を人が横切ったり、湿度などの環境の変化により、その通信状態が悪化することが考えられる。通信状態が悪化したために、送受信（通信）すべきデータが通信の途中で欠落するなどの不都合が発生することが考えられる。
【０００７】
映像の場合、何らかの原因で、送受信すべきデータが通信の途中で欠落しても、その欠落を補うような手法が実用化されている。例えば、ＭＰＥＧ（Ｍｏｖｉｎｇ Ｐｉｃｔｕｒｅ Ｅｘｐｅｒｔｓ Ｇｒｏｕｐ）方式によりエンコードされたデータがデコードされる場合、そのデコードされるビデオストリーム内のパケットに欠落があっても、そのパケットにかかわるフレームの前のフレーム、あるいは前のフレームの一部のブロックを補間することにより、ビデオストリームの再生が継続されるようにされている。
【０００８】
このようなエラーコンシールメント（エラー隠蔽）をする手法が、ビデオストリームを処理するデコーダ側に備わっていれば、ユーザに提供される映像が、とぎれてしまうといったような不都合が発生することを抑えることが可能となる。
【０００９】
しかしながら、音声の場合、映像と同じ手法により、パケット（データ）の欠落などによるエラーを隠蔽したとしても、その隠蔽は有効ではないため、音声のデータに対しては、そのようなエラー隠蔽のための手法は用いられていなかった。そのために、音声にかかわるパケットが欠落したりした場合、ユーザに提供される音声がとぎれるなどの不都合が発生するといった課題があった。
【００１０】
本発明はこのような状況に鑑みてなされたものであり、所定のデータを複数回送信する（冗長化して送信する）ことにより、ユーザ側に提供される映像や音声がとぎれるといったような不都合が発生することを防ぐことを目的とする。
【００１１】
【課題を解決するための手段】
本発明の送受信システムの送信装置は、データを取得する取得手段と、取得手段により取得されたデータを受信装置に送信する送信手段と、取得手段により取得されたデータを記憶する記憶手段と、記憶手段からデータを読み出し、送信手段に、読み出されたデータの送信を指示する指示手段とを備え、受信装置は、送信手段により送信されたデータを受信する受信手段と、受信手段により受信されたデータは、既に受信されたデータであるか否かを判断する判断手段と、判断手段により、受信されたデータは、既に受信されたデータであると判断された場合、そのデータを破棄し、受信されたデータは、既に受信されたデータではないと判断された場合、そのデータ記憶する記憶制御手段とを備えることを特徴とする。
【００１２】
本発明の送信装置は、データを取得する取得手段と、取得手段により取得されたデータを送信する送信手段と、取得手段により取得されたデータを記憶する記憶手段と、記憶手段からデータを読み出し、送信手段に、読み出されたデータの送信を指示する指示手段とを備えることを特徴とする送信装置。
【００１３】
前記指示手段は、送信手段によりデータが送信された後、所定の時間が経過すると、記憶手段からデータを読み出し、送信手段に、読み出されたデータの送信を指示するようにすることができる。
【００１４】
前記取得手段により取得されたデータ内に、所定のデータが含まれるか否かを判断する判断手段をさらに含み、記憶手段は、判断手段によりデータ内に、所定のデータが含まれていると判断された場合、その所定のデータを記憶し、指示手段は、記憶手段から所定のデータを読み出し、送信手段に送信させるようにすることができる。
【００１５】
前記取得手段により取得されたデータ内に、オーディオデータが含まれるか否かを判断する判断手段をさらに含み、記憶手段は、判断手段によりデータ内に、オーディオデータが含まれていると判断された場合、そのオーディオデータと、そのオーディオデータに付加されているヘッダを記憶し、指示手段は、記憶手段からヘッダとオーディオデータを読み出し、送信手段に送信させるようにすることができる。
【００１６】
前記ヘッダは、ＲＴＰヘッダであるようにすることができる。
【００１７】
本発明の送信方法は、データの取得を制御する取得制御ステップと、取得制御ステップの処理で取得が制御されたデータの送信を制御する送信制御ステップと、取得制御ステップの処理により取得が制御されたデータの記憶を制御する記憶制御ステップと、記憶制御ステップにより記憶が制御されたデータを読み出し、送信制御ステップの処理で、読み出されたデータが送信されるように指示する指示ステップとを含むことを特徴とする。
【００１８】
本発明の記録媒体のプログラムは、データの取得を制御する取得制御ステップと、取得制御ステップの処理で取得が制御されたデータの送信を制御する送信制御ステップと、取得制御ステップの処理により取得が制御されたデータの記憶を制御する記憶制御ステップと、記憶制御ステップにより記憶が制御されたデータを読み出し、送信制御ステップの処理で、読み出されたデータが送信されるように指示する指示ステップとを含むことを特徴とする。
【００１９】
本発明のプログラムは、データの取得を制御する取得制御ステップと、取得制御ステップの処理で取得が制御されたデータの送信を制御する送信制御ステップと、取得制御ステップの処理により取得が制御されたデータの記憶を制御する記憶制御ステップと、記憶制御ステップにより記憶が制御されたデータを読み出し、送信制御ステップの処理で、読み出されたデータが送信されるように指示する指示ステップとをコンピュータに実行させることを特徴とするプログラム。
【００２０】
本発明の受信装置は、データを受信する受信手段と、受信手段によりデータが受信されたとき、そのデータは、既に受信されているデータであるか否かを判断する判断手段と、判断手段により、受信手段により受信されたデータは、既に受信されているデータであると判断された場合、そのデータを破棄し、既に受信されているデータではないと判断された場合、そのデータ記憶する記憶制御手段とを備えることを特徴とする。
【００２１】
前記判断手段は、受信手段により受信されたデータに含まれるＲＴＰヘッダのＳｅｑｕｅｎｃｅ Ｎｕｍｂｅｒを参照し、データが、既に受信されたデータであるか否かを判断するようにすることができる。
【００２２】
本発明の受信方法は、データの受信を制御する受信制御ステップと、受信制御ステップの処理によりデータが受信されたとき、そのデータは、既に受信されているデータであるか否かを判断する判断ステップと、判断ステップの処理により、受信制御ステップの処理により受信されたデータは、既に受信されているデータであると判断された場合、そのデータを破棄し、既に受信されているデータではないと判断された場合、そのデータ記憶する記憶制御ステップとを含むことを特徴とする。
【００２３】
本発明の記録媒体のプログラムは、データの受信を制御する受信制御ステップと、受信制御ステップの処理によりデータが受信されたとき、そのデータは、既に受信されているデータであるか否かを判断する判断ステップと、判断ステップの処理により、受信制御ステップの処理により受信されたデータは、既に受信されているデータであると判断された場合、そのデータを破棄し、既に受信されているデータではないと判断された場合、そのデータ記憶する記憶制御ステップとを含むことを特徴とする。
【００２４】
本発明のプログラムは、データの受信を制御する受信制御ステップと、受信制御ステップの処理によりデータが受信されたとき、そのデータは、既に受信されているデータであるか否かを判断する判断ステップと、判断ステップの処理により、受信制御ステップの処理により受信されたデータは、既に受信されているデータであると判断された場合、そのデータを破棄し、既に受信されているデータではないと判断された場合、そのデータ記憶する記憶制御ステップとをコンピュータに実行させることを特徴とする。
【００２５】
本発明においては、所定のデータが複数回送信される。その複数回送信されるデータは、例えば、オーディオデータである。
【００２６】
本発明においては、複数回送信されてきた所定のデータのうち、既に受信されているデータに関しては、記憶されないように制御される。
【００２７】
【発明の実施の形態】
以下に、本発明の実施の形態について図面を参照して説明する。図１は、本発明を適用した送受信システムの一実施の形態の構成を示す図である。図１に示した送受信システムは、送信機１と受信機２から構成されている。送信機１は、アンテナ３により受信されたテレビジョン放送のデータを、受信機２に対して送信する。受信機２は、表示装置（例えば、ディスプレイ）や音声出力装置（例えば、スピーカ）を備えており、受信したデータに基づく画像や音声を出力するように構成されている。
【００２８】
ここでは、アナログ信号のテレビジョン放送が受信され、そのデータが、受信機２に送信されるとして説明するが、本発明は、アナログ信号のテレビジョン放送だけでなく、例えば、ＢＳ（Ｂｒｏａｄｃａｓｔｉｎｇ Ｓａｔｅｌｌｉｔｅ）放送、ＣＳ（Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ｓａｔｅｌｌｉｔｅ）放送、地上波デジタル放送などのデジタル信号のテレビジョン放送に対しても適用することが可能である。
【００２９】
また、例えば、ＶＴＲ（Ｖｉｄｅｏ Ｔａｐｅ Ｒｅｃｏｒｄｅｒ）やＤＶＤ（Ｄｉｇｉｔａｌ Ｖｅｒｓａｔｉｌｅ Ｄｉｓｃ）プレーヤなどが送信機１に接続され、それらの装置からのデータが、送受信されるようにしても良い。さらに、インターネットなどのネットワークに接続され、そのネットワークに接続されることにより得られる情報などの送受信が行われるようにしても良い。
【００３０】
送信機１と受信機２は、無線でデータの授受を行う。その無線による通信は、例えば、ＩＥＥＥ８０２．１１の規格に基づく方式で行われる。送信機１と受信機２は、無線によりデータの授受を行うため、例えば、ユーザは、送信機１を家の所定の場所に固定して設置し、受信機２を所望の場所まで持ち運び、その場所でテレビジョン放送を閲覧するといったことをできる。
【００３１】
図２は、送信機１の内部構成例を示す図である。図２に示した内部構成例は、主に、本発明にかかわり、説明に必要とされる部分を示し、説明に必要ない部分、例えば、受信したテレビジョン放送からユーザが指定した番組を抽出するチューナや、ＶＴＲやＤＶＤプレーヤなどを接続した際に、それらの装置からの入力を切り換えるスイッチャーなどは、省略してある。
【００３２】
送信機１は、アンテナ３により受信されたテレビジョン放送としてのデータ（信号）を入力する。入力される信号は、例えば、アナログ信号である。そのアナログ信号は、ＭＰＥＧ（Ｍｏｖｉｎｇ Ｐｉｃｔｕｒｅ Ｅｘｐｅｒｔｓ Ｇｒｏｕｐ）エンコーダ２１に入力される。ＭＰＥＧエンコーダ２１は、入力されたアナログ信号を、ＭＰＥＧ方式に基づく圧縮を施したデジタルデータに変換する。
【００３３】
なお、デジタル信号のテレビジョン放送のデータなどが入力される場合、ＭＰＥＧエンコーダ２１によりエンコードされる必要はないので、必ずしも、入力されたデータが、ＭＰＥＧエンコーダ２１を介する構成とされる必要はなく、適宜、入力されるデータにより、入力される部分が異なるようにしても良い。勿論、そのような入力されたデータの出力先を選択するためのスイッチャーなどが、図示はしないが、送信機１には備え付けられている。
【００３４】
ＭＰＥＧエンコーダ２１からの出力（トランスポートストリームパケット：以下、適宜、ＴＳパケットと記述する）は、ＲＴＰ（Ｒｅａｌ Ｔｉｍｅ Ｐｒｏｔｏｃｏｌ）ヘッダ付加部２２に供給される。ＲＴＰヘッダ付加部２２は、供給されたＴＳパケットを所定の個数、例えば、７個のパケットをまとめ、そのまとめたパケット（以下、適宜、ＴＳパケット列と記述する）にＲＴＰヘッダを付加し、ＵＤＰ（Ｕｓｅｒ Ｄａｔａｇｒａｍ Ｐｒｏｔｏｃｏｌ）付加部２３に供給する。ＲＴＰヘッダ付加部２２によりＲＴＰヘッダを付加されたＴＳパケット列を、適宜、ＲＴＰパケットと記述する。
【００３５】
ＵＤＰヘッダ付加部２３は、供給されたＲＴＰパケットに対して、さらに、ＵＤＰヘッダを付加して、ＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）ヘッダ付加部２４に供給する。ＵＤＰヘッダ付加部２３によりＵＤＰヘッダを付加されたＲＴＰパケットを、適宜、ＵＤＰパケットと記述する。
【００３６】
ＩＰヘッダ付加部２４は、供給されたＵＤＰパケットに対して、ＩＰヘッダを付加し、ＭＡＣ（Ｍｅｄｉａ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ）ヘッダ付加部２５に供給する。ＩＰヘッダ付加部２４によりＩＰヘッダを付加されたＵＤＰパケットを、適宜、ＩＰパケットと記述する。
【００３７】
ＭＡＣヘッダ付加部２５は、供給されたＩＰパケットに対して、ＭＡＣヘッダを付加し、通信部２６に供給する。ＭＡＣヘッダ付加部２５によりＭＡＣヘッダを付加されたＩＰパケットを、適宜、ＭＡＣパケットと記述する。
【００３８】
各部で、ヘッダを付加され、ＭＡＣパケットとされたＴＳパケットは、通信部２６により、受信機２に対して送信される。
【００３９】
冗長化制御部２７は、詳細は後述するが、所定のデータ（例えば、オーディオデータ）の複数回の送信を制御する（冗長化（重畳化）して送信するための制御を行う）ために設けられており、必要に応じ記憶部２８から、ＵＤＰヘッダ付加部２３に、パケットが供給されるように制御する。また、冗長化制御部２７は、ＲＴＰヘッダ付加部２２から供給されるＲＴＰパケットを記憶部２８に記憶させる。
【００４０】
記憶部２８には、このような所定のデータの冗長した送信を可能にするために、その複数回送信すべきデータと、そのデータに対応するＲＴＰヘッダが記憶されている。
【００４１】
図３は、ＭＰＥＧエンコーダ２１乃至ＭＡＣヘッダ付加部２５の各部が、処理を行うことにより、通信部２６に供給されるデータ（ＭＡＣパケット）を示す図である。図３に示すように、通信部２６に供給されるデータは、ＭＰＥＧエンコーダ２１によりエンコードされたＴＳパケット列４１を含む。上述したように、通信部２６に供給されるＭＡＣパケット内のＴＳパケット列４１には、ＴＳパケット５１−１乃至５１−７の７個のパケットが含まれている。１つのＴＳパケットは、１８８Ｂｙｔｅｓで構成されている。
【００４２】
ＴＳパケット列４１内の１つのパケットであるＴＳパケット５１−１は、ヘッダ部６１とデータ部６２から構成されている。ヘッダ部６１は、図４に示すデータを含み、データ部６２は、受信機２（図１）側で、映像または音声としてユーザに提供するためのビデオデータまたはオーディオデータを含む。
【００４３】
図４は、ＴＳパケット５１のヘッダ部６１のデータ構成を示す図である。ヘッダ部６１は、４Ｂｙｔｅｓで構成され、データ部６２は、１８４Ｂｙｔｅｓで構成される。ヘッダ部６１の“同期バイト”は、同期を取るために設けられており、固定値で、例えば、“４７ｈ”が設定されている。“Ｅｒｒｏｒ Ｆｌａｇ”は、ＴＳパケット５１の中に訂正できないｂｉｔ ｅｒｒｏｒがあるか否かを示すフラグである。
【００４４】
“Ｓｔａｒｔ Ｆｌａｇ”は、新しいＰＥＳ Ｐａｃｋｅｔあるいは新しいＴＳ−ＰＳＩ Ｓｅｃｔｉｏｎであることを示すフラグである。“Ｐｒｉｏｒｉｔｙ Ｆｌａｇ”は、パケットの優先度を示すフラグであり、このフラグ（ｂｉｔ）が、１に設定されていると、他のＴＳパケット５１より重要度が高いことを示す。“ＰＩＤ”は、ＴＳパケット５１のＰａｙｌｏａｄ部分（データ部６２）が、ビデオデータであるか、オーディオデータであるか、ＴＳ−ＰＳＩ（ＴＳ−Ｐｒｏｇｒａｍ Ｓｐｅｃｉｆｉｃ Ｉｎｆｏｒｍａｔｉｏｎ）であるか、あるいは、それら以外であるかを、それぞれを区別するために付与される、１３ｂｉｔで構成される数値（Ｉｄｅｎｔｉｆｉｅｒ）である。
【００４５】
“Ｓｃｒａｍｂｌｉｎｇ ｍｏｄｅ”は、データ部６２のＳｃｒａｍｂｌｉｎｇ ｍｏｄｅ（スクランブルモード）を示す情報である。“Ａｄａｐｔａｔｉｏｎ Ｆｉｅｌｄ ｆｌａｇ”は、ＰＣＲ（Ｐｒｏｇｒａｍ Ｃｌｏｃｋ Ｒｅｆｅｒｅｎｃｅ）などの情報が含まれているＡｄａｐｔａｔｉｏｎ Ｆｉｅｌｄの有無を示す情報である。“Ｃｏｎｔｉｎｕｉｔｙ Ｃｏｕｎｔｅｒ”は、同じＰＩＤを持つパケットで、１ずつ値が増加されるカウンタ値の情報である。
【００４６】
ＭＰＥＧエンコーダ２１（図２）では、入力されたアナログ信号をデジタルデータに変換し、ＭＰＥＧ方式の圧縮を施してデータ部６２を生成すると共に、図４に示したようなヘッダ部６１を生成し、１つのＴＳパケット５１を生成する。
【００４７】
このようなＴＳパケット５１が、この場合、７個含まれるのが、図３に示したＴＳパケット列４１である。ＲＴＰヘッダ４２（図３）は、ＲＴＰヘッダ付加部２２（図２）により付加されるヘッダであるが、そのデータ構成は、図５に示すように構成されている。
【００４８】
ＲＴＰヘッダ４２の“Ｖ”は、Ｖｅｒｓｉｏｎ Ｂｉｔを示し、ＲＴＰヘッダ４２のフォーマットのバージョンを示すバージョン番号の情報である。“Ｐ”は、Ｐａｄｄｉｎｇ Ｂｉｔを示し、パケットのサイズを調整するビットである。“Ｘ”は、Ｅｘｔｅｎｓｉｏｎ Ｂｉｔを示し、機能拡張時に指定される拡張ビットである。
【００４９】
“ＣＣ”は、ＣＳＲＣ Ｃｏｕｎｔを示し、リアルタイム転送に関わる送信元の数を示すカウンタの情報である。“Ｍ”は、Ｍａｒｋｅｒ Ｂｉｔを示し、１パケットにおけるフレームの境界を示すマーカービットである。“ＰＴ”は、Ｐａｙｌｏａｄ Ｔｙｐｅを示し、ペイロードの符号化の種類を示す情報である。“Ｓｅｑｕｅｎｃｅ Ｎｕｍｂｅｒ”は、ＲＴＰパケットの順番を示すシーケンス番号を示す情報である。
【００５０】
“ＴＩＭＥ ＳＴＡＭＰ”は、ＲＴＰヘッダ４２が作成された時刻を示すタイムスタンプの情報を示す。“ＳＳＲＣ”は、Ｓｙｎｃｈｒｏｎｉｚａｔｉｏｎ Ｓｏｕｒｃｅを示し、メッセージの最初の送信元（ソース）を識別する同期ソース識別子の情報である。“ＣＳＲＣ”は、Ｃｏｎｔｒｉｂｕｔｉｎｇ Ｓｏｕｒｃｅを示し、メッセージに含まれるパケット群の送信先（クライアント）を識別する貢献ソース識別子の情報である。
【００５１】
このような情報を含むＲＴＰヘッダ４２に対応するペイロード（Ｐａｙｌｏａｄ）に、ＴＳパケット列４１が挿入される。ＲＴＰヘッダ４２が付加されているＲＴＰパケットにＵＤＰヘッダ４３（図３）が、ＵＤＰヘッダ付加部２３（図２）により付加される。
【００５２】
図６は、ＵＤＰヘッダ４３のデータ構成を示す図である。ＵＤＰヘッダ４３の“ＳＲＣ ＰＯＲＴ”は、送信元のポート番号を指定する情報であり、“ＤＥＳＴ ＰＯＲＴ）は、送信先（宛先）のポート番号を指定する情報であり、共に、サービスを特定するための情報として用いられる。
【００５３】
“Ｌｅｎｇｔｈ”は、ＵＤＰヘッダ４３とその後に続くデータの長さ（バイト単位）の合計を示す情報である。“Ｃｈｅｃｋｓｕｍ”は、ＵＤＰヘッダの情報と、データ長を元にして算出された値の情報である。受信側では、送信側と同様の計算を行い、Ｃｈｅｃｋｓｕｍ（チェックサム）の値を算出し、その算出した値と、送信されてきたＵＤＰヘッダ４３に含まれるチェックサムの値が一致しているか否かを判断することで、途中で、パケットが壊れていないか否かを判断する。
【００５４】
このようなＵＤＰヘッダ４３が付加されたＵＤＰパケットに、ＩＰヘッダ４４（図３）が、ＩＰヘッダ付加部２４（図２）により付加される。図７は、ＩＰヘッダ４４のデータ構成を示す図である。図７に示したＩＰヘッダ４４のデータ構成は、基本ヘッダの部分だけを示し、オプションヘッダについては図示していない。
【００５５】
“Ｖｅｒ”は、インターネットプロトコル（ＩＰ）のバージョンを示す情報である。“ＩＨＬ”は、Ｉｎｔｅｒｎｅｔ Ｈｅａｄｅｒ Ｌｅｎｇｔｈを示し、このヘッダの長さを示す情報である。“ＴＯＳ”は、Ｔｙｐｅ Ｏｆ Ｓｅｒｖｉｃｅを示し、データの優先度の定義や、どのようなタイプの転送を行うかなどを指定する情報である。
【００５６】
“ＴＬ”は、Ｔｏｔａｌ Ｌｅｎｇｔｈを示し、ＩＰヘッダ４４と、ＩＰヘッダ４４以降のデータの合計の長さを示す情報である。“ＩＤ”は、このＩＰヘッダ４４で示されるＩＰパケットを識別するための情報である。“ＦＬ”は、ＩＰ層でデータを分割（フラグメント）した際の、その制御に関する情報である。
【００５７】
“ＦＯ”は、ＩＰ層でデータが分割された際のデータが、どこにあったかを示す情報である。“ＴＴＬ”は、Ｔｉｍｅ Ｔｏ Ｌｉｖｅを示し、このＩＰヘッダ４４を含むデータが、いつ破棄されるのかを示す情報である。“ＰＲＯＴ”は、ＩＰ層より上の層で用いられているプロトコルを示す情報である。
【００５８】
“ＨＣ”は、ＩＰヘッダ４４が送信中に壊れていないか否かを、受信側で確認するためのチェックサムの情報である。“ＳＡ”は、データの送信元のＩＰアドレスを示す情報である。“ＤＡ”は、データの送信先のＩＰアドレスを示す情報である。
【００５９】
このようなＩＰヘッダ４４が付加されたＩＰパケットに、ＭＡＣヘッダ４５（図３）が、ＭＡＣヘッダ付加部２５（図２）により付加される。図８は、ＭＡＣヘッダ４５のデータ構成を示す図である。
【００６０】
“ＰＡ”は、プリアンブルであり、クロックリカバリのためのＰＬＬをロックするさせるための情報である。“ＤＡ”は、送信先のＭＡＣアドレスを示す情報である。“ＳＡ”は、送信元のＭＡＣアドレスを示す情報である。“Ｔｙｐｅ”は、上位層のプロトコルを示し情報である。
【００６１】
“Ｌｅｎｇｔｈ”は、ペイロードのデータのバイト数を示す情報である。１つのＭＡＣヘッダ４５には、“Ｔｙｐｅ”または“Ｌｅｎｇｔｈ”のどちらか一方の情報が書き込まれる。“ＦＣＳ”は、エラーチェックのための情報である。
【００６２】
このような情報を含むＭＡＣヘッダ４５が付加されることにより、図３に示したようなデータ（ＭＡＣパケット）が生成される。
【００６３】
ここでは、図３に示した構成のデータが、送信機１から送信されるとして説明するが、ＲＴＰヘッダ４２が付加されていない構成のデータでも、受信機２側にデータを送信することは可能である。しかしながら、図３に示したように、本実施の形態においては、ＲＴＰヘッダ４２が付加されたデータを送信するようにする。
【００６４】
このように、ＲＴＰヘッダ４２が付加されたデータが送信されるようにするのは、所定のデータ（パケット）を複数回送信するために、ＲＴＰヘッダ４２内の情報（具体的には、図５に示した“Ｓｅｑｕｅｎｃｅ Ｎｕｍｂｅｒ”）が用いられるからである。
【００６５】
ＵＤＰヘッダ４３は、ＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）ヘッダに置き換えることが可能である（ＴＣＰヘッダにしても良い）。しかしながら、本実施の形態においては、図３に示したように、ＵＤＰヘッダ４３を用いる。
【００６６】
このように、ＴＣＰヘッダを付加するのではなく、ＵＤＰヘッダを付加するようにするのは、以下の理由からである。ＴＣＰヘッダは、トランスポート層のプロトコルとして、ＴＣＰが用いられたときに付加されるヘッダであり、ＵＤＰヘッダは、トランスポート層のプロトコルとして、ＵＤＰが用いられたときに付加されるヘッダである。
【００６７】
トランスポート層のプロトコルとして、ＴＣＰを用いるか、または、ＵＤＰを用いるかを決定する要因の１つとして、そのプロトコルを用いて行われる通信ではどのようなデータが送受信されるのかという要因がある。ＴＣＰは、コネクション型のプロトコルと称され、ＵＤＰはコネクションレス型のプロトコルと称されることがある。
【００６８】
ＴＣＰは、コネクション型のプロトコルであるので、データの授受にかかわる処理手順が複雑になるが、通信にかかわる信頼度は向上する。従って、主に、信頼度を優先させる通信に用いられる。ＴＣＰに対し、ＵＤＰは、コネクションレス型のプロトコルであるので、データの授受にかかわる処理手順は簡素化されているが、通信にかかる処理時間は短くなるため、処理速度を優先させる通信に用いられる。
【００６９】
本実施の形態においては、上述したように、送信機１が受信したテレビジョン放送のデータを、受信機２側に送信するので、その送信機１と受信機２との間のデータの授受にかかわるプロトコルは、信頼度より処理速度を優先させ、リアルタイムに処理できるようにした方が良いため、ＵＤＰを用いる。
【００７０】
しかしながらＵＤＰを用いて通信を行うと、送信機１が送信したデータが、何らかの原因で、受信機２側で受信されてなくても、送信機１側は、そのような状況に関係なく、データを順次送信し続ける。受信機２側で、欠落したデータを取得することなく、欠落した状態のまま処理を続けると、ユーザに提供される映像や音声がとぎれたり、乱れたりする。そのようなことは、できる限り発生しない方が好ましい。
【００７１】
そこで、本実施の形態においては、リアルタイムに処理が行われることを重視し、ＵＤＰを用いた通信を行ったとしても、何らかの原因で、受信側でデータを受信できないような状況が発生したとき、すなわち、データの欠落が生じたとき、その欠落したデータを補った処理を行えるようにすると共に、その処理を行うことにより、送信側および受信側でそれぞれ行われる処理自体が、多大な処理とならないようにする。
【００７２】
そのような機能を有し、図２に示したような構成を有する送信機１に対応する受信機２について説明する。図９は、受信機２の内部構成例を示す図である。受信機２の通信部８１は、送信機１からのデータを受信する。通信部８１により受信された送信機１からの、図３に示したような構成のデータは、ＭＡＣヘッダ抽出部８２に供給される。ＭＡＣヘッダ抽出部８２は、供給されたデータ（ＭＡＣパケット）から、ＭＡＣヘッダ４５（図３）を抽出（除去）し、ＩＰパケットをＩＰヘッダ抽出部８３に供給する。
【００７３】
ＩＰヘッダ抽出部８３は、供給されたＩＰパケットからＩＰヘッダ４４を抽出し、ＵＤＰパケットをＵＤＰヘッダ抽出部８４に供給する。ＵＤＰヘッダ抽出部８３は、供給されたＵＤＰパケットからＵＤＰヘッダ４３を抽出し、ＲＴＰパケットを順序再構成部８５に供給する。
【００７４】
順序再構成部８５は、ＲＴＰヘッダ４２に含まれる“Ｓｅｑｕｅｎｃｅ Ｎｕｍｂｅｒ”（図５）（以下、適宜、シークエンスナンバーと記述する）を参照しする。シークエンスナンバーは、送信機１側で、処理された順（生成されたＲＴＰヘッダ４２順）に、通常、昇順に割り振られる連続した番号である。なおここでは、昇順に割り振られるとして説明をするが、降順に割り振られるようにしても良い。
【００７５】
順序再構成部８５は、供給されたＲＴＰパケットのシークエンスナンバーを参照し、そのシークエンスナンバーと同一の番号を持つデータ（対応するデータ）が記憶部８７に記憶されているか否かを判断し、記憶されていると判断した場合、その供給されたＲＴＰパケットを破棄し、記憶されていないと判断した場合、その供給されたＲＴＰパケットをＲＴＰヘッダ抽出部８６に供給する。
【００７６】
ＲＴＰヘッダ抽出部８６は、供給されたＲＴＰパケットから、ＲＴＰヘッダ４２を抽出し、ＴＳパケット列４１を、記憶部８７に記憶させる。記憶部８７には、このようにして、ＴＳパケット列４１が記憶されるが、そのＴＳパケット列４１は、ＲＴＰヘッダ４２のシークエンスナンバーと関連付けられて記憶される。
【００７７】
記憶部８７には、通常、ＴＳパケット列４１、すなわち、この場合、７個のＴＳパケット５１が記憶されることになるが、エラーなどが発生した場合には、７個以下のＴＳパケット５１のみが記憶されるときがある。
【００７８】
記憶部８７は、バッファとしての役割を有し、順次記憶されているＴＳパケット５１を、ＭＰＥＧデコーダ８８に出力する。ＭＰＥＧデーコーダ８８は、順次、供給されたＴＳパケット５１に対し、ＭＰＥＧ方式に基づくデコードを施す。ＭＰＥＧデコーダ８８からの出力は、図示されていないディスプレイやスピーカに供給され、ユーザに映像や音声として提供される。
【００７９】
ここで、記憶部８７に記憶されているデータについて説明する。図１０は、記憶部８７に記憶されているデータのデータ構成を説明するための図である。上述したように、記憶部８７には、ＲＴＰヘッダ４２内に含まれるシークエンスナンバーと、そのシークエンスナンバーのＲＴＰパケットに含まれているＴＳパケットが関連付けられて記憶されている。
【００８０】
なお、記憶部８７に記憶させるシークエンスナンバーは、シークエンスナンバーそのものでも良いし、シークエンスナンバーを一意に導き出せるデータでも良い。
【００８１】
例えば、図１０に示したように、シークエンスナンバー“１”には、ＴＳパケット５１―１−１乃至５１−７―１（ここでの符号における最後の数字は、シークエンスナンバーを示す（同一の値）とする）が関連付けられて記憶されている。
【００８２】
これは、上述したように、本実施の形態においては、１つのＲＴＰパケット（受信機２側で受信されるＭＡＣパケット）には、７個のＴＳパケット５１−１乃至５１−７（図３）を含むと設定しているからであり、例えば、８個のＴＳパケットを含むと設定されている場合には、シークエンスナンバー“１”には、ＴＳパケット５１−１―１乃至５１−８―１の８個のＴＳパケットが関連付けられて記憶されることになる。
【００８３】
図１０に示した例を再度参照するに、同じくシークエンスナンバー“２”には、同じく７個のＴＳパケット５１−１―２乃至５１−７―２が関連付けられている。しかしながら、シークエンスナンバー“３”の欄には、本来ならば、ＴＳパケット５１−１―３乃至５１−７―３が関連付けられて記憶されるが、図１０に示した例では、ＴＳパケットが記憶されていない。これに対し、シークエンスナンバー“４”には、ＴＳパケット５１−１―４乃至５１―７−４が関連付けられて記憶されている。
【００８４】
このように、記憶部８７には、正常に受信され処理されると、シークエンスナンバーと関連付けられてＴＳパケット５１（ＴＳパケット列４１）が、所定の領域に記憶される。記憶部８７には、シークエンスナンバー順に、ＴＳパケットが所定の領域に記憶されるようになっている。一方、何らかの原因で、正常に受信が行われなかったシークエンスナンバーの領域（この場合、例えば、シークエンスナンバー“３”の領域）は、何も記憶されない状態で確保されている。
【００８５】
このように、記憶部８７には、ＴＳパケットが記憶されている領域を有するシークエンスナンバーと、ＴＳパケットが記憶されていない領域を有するシークエンスナンバーとが混在する。そこで、ＴＳパケットが記憶されているか否かを示すフラグを用いて、ＴＳパケットが記憶されている領域を有するシークエンスナンバーと、そうでないシークエンスナンバーとを区別できるようにしても良い。また、そのようなフラグを、後述する処理において用いるようにしても良い。
【００８６】
図２に示したような構成を有する送信機１と、図９に示したような構成を有する受信機２において、図３乃至８を参照して説明したデータが授受される際の送信機１と受信機２の動作について説明する。まず、送信機１の動作について説明する。
【００８７】
送信機１は、アンテナ３（図１）により受信されたテレビジョン放送のデータに、所定のヘッダを付加し、受信機２に対して送信するわけだが、その送信されるデータのうち、所定のデータは、複数回（ここでは、説明の都合上、２回として説明する）送信される。１回目の送信にかかわる処理について説明する。
【００８８】
まず、アンテナ３により受信されたテレビジョン放送のデータは、ＭＰＥＧエンコーダ２１により、ＭＰＥＧ方式に基づくエンコードが施され、ＴＳパケット５１として、ＲＴＰヘッダ付加部２２に出力される。ＲＴＰヘッダ付加部２２は、入力されたＴＳパケット５１を７個単位にまとめ、ＴＳパケット列４１を生成する。そして、ＲＴＰヘッダ付加部２２は、生成したＴＳパケット列４１に対してＲＴＰヘッダ４２を付加する。
【００８９】
ＲＴＰヘッダ４２が付加されたＲＴＰパケットは、ＵＤＰヘッダ付加部２３と冗長化制御部２７に供給される。ここで、ＵＤＰヘッダ付加部２３と冗長化制御部２７に供給されるＲＴＰパケットについて説明する。図１１と図１２は、ＲＴＰパケットの構成を示す図である。
【００９０】
図１１は、ＴＳパケット列１０１にＲＴＰヘッダ１０２が付加されたＲＴＰパケットの構成を示している。図１１に示したＲＴＰパケットに含まれるＴＳパケット列１０１は、ヘッダ１０３−１乃至１０３−７がそれぞれ付加されたビデオデータ１０４−１乃至１０４−７から構成されている。ヘッダ１０３−１乃至１０３−７は、図４に示したヘッダ部６１に示すようなデータを含むが、そのうち、“ＰＩＤ”のデータは、この場合、“１００ｈ”に設定されている。
【００９１】
図４を参照して説明したように、ヘッダ部６１に含まれる“ＰＩＤ”の値は、ヘッダ部６１に続くデータ部６２のデータに依存して決定される値である。この場合、データ部６２のデータがビデオデータである場合、ＰＩＤの値は、“１００ｈ”と設定されるとして説明し、データ部６２のデータがオーディオデータである場合、ＰＩＤの値は、“１０２ｈ”と設定されるとして説明する。
【００９２】
このＰＩＤの値は、送信機１と受信機２との間で識別できる値に設定されていればよい。また、このＰＩＤの値は、ＭＰＥＧエンコーダ２１で設定される。
【００９３】
図１１に示したＴＳパケット列１０１に含まるＴＳパケットのデータ部６２は、全てビデオデータであるので、それぞれのヘッダ１０３−１乃至１０３−７の“ＰＩＤ”は、全て“１００ｈ”に設定されている。
【００９４】
これに対し、図１２に示したＴＳパケット列１１１には、オーディオデータ１１４−３が含まれている。そのオーディオデータ１１４−３に付加されたヘッダ１１３−３の“ＰＩＤ”の値は、“１０２ｈ”と設定されている。
【００９５】
通常、ビデオにかかわるデータの方が、オーディオにかかわるデータよりも大きいサイズとなるため、図１１に示したように、ＴＳパケット列１０１に含まれるＴＳパケットは、ビデオデータにかかわるパケットのみから構成されるか、図１２に示したように、ＴＳパケット列１１１に含まれるＴＳパケットのうち、１個または複数個のパケットのみが、オーディオデータにかかわるパケットを含む構成とされることが多い。
【００９６】
図１１に示したＲＴＰパケットの“Ｓｅｑｕｅｎｃｅ Ｎｕｍｂｅｒ”は、“１２３４ｈ”と割り振られている。仮に、図１２に示すＲＴＰパケットが、図１１に示したＲＴＰパケットの時間的に直後に生成されるＲＴＰパケットである場合、ＲＴＰヘッダ１１２の“Ｓｅｑｕｅｎｃｅ Ｎｕｍｂｅｒ”は、“１２３５ｈ”と割り振られる。すなわち、連続した番号が割り振られる。
【００９７】
図１１に示したようなビデオデータのみから構成されるＲＴＰパケット、または、図１２に示したようなビデオデータとオーディオデータから構成されるＲＴＰパケットが、ＲＴＰヘッダ付加部２２により生成され、ＵＤＰヘッダ付加部２３と冗長化制御部２７に供給される。ＵＤＰヘッダ付加部２３は、供給されたＲＴＰパケットにＵＤＰヘッダを付加し、ＩＰヘッダ付加部２４に供給する。ＩＰヘッダ付加部２４は、供給されたＵＤＰパケットにＩＰヘッダを付加し、ＭＡＣヘッダ付加部２５に供給する。
【００９８】
ＭＡＣヘッダ付加部２５は、供給されたＩＰパケットにＭＡＣヘッダを付加し、通信部２６に供給する。通信部２６にＭＡＣパケットが供給されることにより、受信機２に対して１回目の送信が行われる。
【００９９】
次に、図１３のフローチャートを参照して、２回目の送信にかかわる送信機１の動作について説明する。図１３に示したフローチャートは、主に、冗長化制御部２７において行われる。また、図１３に示したフローチャートの処理は、ＲＴＰヘッダ付加部２２から出力されたＲＴＰパケット毎に行われる。更に、図１３に示したフローチャートの処理では、オーディオデータのみが２回目の送信の対象となるとして説明する。
【０１００】
ステップＳ１１において、冗長化制御部２７は、ＲＴＰヘッダ付加部２２から供給されたＲＴＰパケット内に、オーディオデータが含まれているか否かを判断する。冗長化制御部２７に供給されたＲＴＰパケットが、図１１に示すような、ビデオデータ１０４−１乃至１０４−７のみから構成されるＴＳパケット列１０１を含むようなＲＴＰパケットである場合、ステップＳ１１においては、ＮＯと判断される。
【０１０１】
冗長化制御部２７に供給されたＲＴＰパケットが、図１２に示すような、オーディオデータ１１４−３が含まれているＴＳパケット列１１１を含むＲＴＰパケットである場合、ステップＳ１１においては、ＹＥＳと判断される。
【０１０２】
冗長化制御部２７は、供給されたＲＴＰパケット内に、オーディオデータを含むか否かの判断を、各ＴＳパケットに含まれるヘッダの“ＰＩＤ”を参照することにより行う。すなわち、この場合、“ＰＩＤ”が、“１００ｈ”に設定されているＴＳパケットのデータは、ビデオデータであると判断され、“ＰＩＤ”が、“１０２ｈ”に設定されているＴＳパケットのデータは、オーディオデータであると判断される。
【０１０３】
ステップＳ１１において、冗長化制御部２７は、供給されたＲＴＰパケットに、オーディデータは含まれていないと判断した場合、そのＲＴＰパケットを破棄し、そのＲＴＰパケットに対する処理（図１３に示したフローチャートの処理）を終了する。
【０１０４】
一方、ステップＳ１１において、冗長化制御部２７は、供給されたＲＴＰパケットに、オーディデータが含まれていると判断した場合、ステップＳ１２に処理を進め、供給されたＲＴＰパケットから、ＲＴＰヘッダとオーディオデータ（そのオーディオデータを含むＴＳパケット）を抽出し、記憶部２８に記憶させる。
【０１０５】
この処理について図１４Ａおよび図１４Ｂを参照して説明する。図１４Ａは、図１２と同一のＲＴＰパケットを示している。図１４Ａに示したＲＴＰパケットのＴＳパケット列１１１には、オーディオデータ１１４−３（“ＰＩＤ”が“１０２ｈ”に設定されているヘッダ１１３−３）が含まれている。また、このオーディオデータ１１４−３を含むＴＳパケット列１１１のＲＴＰヘッダ１１２のシークエンスナンバーは、“１２３５ｈ”に設定されている。
【０１０６】
このようにＲＴＰパケットにオーディオデータ１１４−３が含まれているような場合、記憶部２８には、図１４Ｂに示すように、供給されたＲＴＰヘッダ１１２、オーディオデータ１１４−３、および、そのオーディオデータ１１４−３に付加されているヘッダ１１３−３が供給され、記憶される。
【０１０７】
また、記憶部２８に記憶される際、この場合、オーディオデータ１１４−３とヘッダ１１３−３のみを含むＴＳパケット列１２１が生成されて、ＲＴＰヘッダ１１２が付加された状態で記憶される。
【０１０８】
なお、冗長化制御部２７が、図１４Ａに示したＲＴＰパケットから、図１４Ｂに示したＲＴＰパケットを生成する際、不必要なデータ（この場合、ビデオデータとそのビデオデータに付加されているヘッダ）を除去することで生成するようにしても良いし、必要なデータ（この場合、オーディオデータとそのオーディオデータに付加されているヘッダ）を抽出することにより生成するようにしても良い。
【０１０９】
このようにして、記憶部２８にオーディオデータのみが含まれるＲＴＰパケットが記憶されると、ステップＳ１３において、冗長化制御部２７は、所定の数のＲＴＰパケットが出力されたか（供給されたか）の判断を行う。所定の数のＲＴＰパケットが供給されたか否かの判断は、冗長化制御部２７が、供給されたＲＴＰパケットの数をカウントすることによって行われるようにしても良い。
【０１１０】
または、ＲＴＰパケットのＲＴＰヘッダ４２に含まれるシークエンスナンバーが参照されて行われるようにしても良い。例えば、記憶部２８に記憶させたＲＴＰパケットのシークエンスナンバーの値に、所定の数を加算し、その加算した値のシークエンスナンバーを含むＲＴＰパケットが供給されたか否かを判断することにより、ステップＳ１３における処理が行われるようにしても良い。
【０１１１】
ステップＳ１３において、冗長化制御部２７が、所定の数のＲＴＰパケットが供給されたと判断すると、ステップＳ１４に処理が進められる。なお、このステップＳ１３における判断が行われている間に冗長化制御部２７に供給されたＲＴＰパケットに対しても、図１３に示したフローチャートの処理は実行されている。
【０１１２】
ステップＳ１４において、ステップＳ１２の処理で記憶部２８に記憶されたオーディオデータのみを含むＴＳパケット列を含むＲＴＰパケットが読み出される。この場合、例えば、図１４Ｂに示したようなＴＳパケット列１２１とそのＴＳパケット列１２１に付加されているＲＴＰヘッダ１１２が読み出される。
【０１１３】
読み出されたＲＴＰパケットは、ＵＤＰヘッダ付加部２３に供給される。このようにして、ＵＤＰヘッダ付加部２３にＲＴＰパケットが供給された後の処理は、上述した１回目の送信の場合と同様に行われる。
【０１１４】
すなわち、ステップＳ１５の処理として、ＵＤＰヘッダ付加部２３、ＩＰヘッダ付加部２４、およびＭＡＣヘッダ付加部２５の各部で、記憶部２８からのＲＴＰパケットに対してヘッダが付加される。そして、ステップＳ１６の処理として、通信部２６により、ＭＡＣパケットが受信機２に対して送信される。
【０１１５】
このようにして、２回目の送信が行われる。ここでは、図１２に示したようなＲＴＰパケットを含むデータ（ＭＡＣパケット）が送信された後、図１４Ｂに示したようなＲＴＰパケットを含むデータが送信されるため、オーディオデータ１１４−３は、２度、受信機２に対して送信されたことになる。
【０１１６】
このように、本実施の形態においては、受信機２に対して、同一のオーディオデータが、２度送信される。ここでは、２度送信されるとして説明するが、２回以上、送信されるようにしても良い。具体的には、ステップＳ１３乃至Ｓ１６の処理が、記憶部２８に記憶されている１つのＲＴＰパケットに対して、繰り返し行われることにより、複数回の送信が可能とされる。
【０１１７】
このようにして複数回、同一のオーディオデータが送信される理由について説明する。送信機１と受信機２との間の通信は、無線により行われるわけだが、無線で行われるために、有線で行われる場合と比較して、その通信の安定性は、劣るという欠点がある。例えば、送信機１と受信機２との間に、遮蔽物が存在するると、通信状態が悪化する可能性がある。また、そのために、通信しているデータが、受信機２側で受信できないといったことが発生する可能性がある。
【０１１８】
ビデオデータは、多少のデータの欠落があっても、ユーザ側に提供される映像がとぎれるといったような不都合があまり発生しないように、例えば、デコードの際に処理されるようになっている。しかしながら、オーディオデータは、欠落したデータがあると、たとえ、ビデオデータに施されるような処理が施されるようにしたとしても、ユーザ側に提供される音声がとぎれてしまうなどの不都合が発生する可能性が高かった。
【０１１９】
このような理由から、ビデオデータよりもオーディオデータの方が、データが欠落するとより影響がでやすいため、上述した実施の形態では、オーディオデータのみを複数回送信するように構成した。また、上述した実施の形態として、オーディオデータのみを複数回送信するようにしたのは、データ量にかかわる理由もある。
【０１２０】
すなわち、ビデオデータは、オーディオデータに対して、そのデータ量は大きい。そのため、仮に、ビデオデータまで複数回送信するようにすると、すなわち、全てのデータを複数回送信するようにすると、送信機１の送信能力または受信機２の受信能力、または、その両方の能力を超えてしまう可能性がある。
【０１２１】
送信機１の送信能力と、受信機２の受信能力が、それぞれ、全てのデータを複数回送信するだけの能力であれば、全てのデータを複数回送信する（受信する）ようにしても良い。
【０１２２】
全てのデータを複数回送信するようにした場合、図１３に示したフローチャートの処理のうち、ステップＳ１１における判断を行なわず、全てのＲＴＰパケットを、一旦、記憶部２８に記憶させるようにし、基本的に同様な処理が実行されるようにすれば、全てのデータの複数回の送信が可能となる。
【０１２３】
なお、全てのデータを複数回送信するようにした場合、ＲＴＰパケットではなく、ＭＡＣパケットが記憶部２８に記憶されるようにしても良い。すなわち、記憶部２８は、ＭＡＣヘッダ付加部２５から出力されるＭＡＣパケットを記憶し、その記憶されているＭＡＣパケットが、通信部２６に出力されるように送信機１が構成されるようにすればよい。
【０１２４】
ここでは、オーディオデータのみが複数回（２回）送信されるとして、説明を続ける。
【０１２５】
このように、送信機１からは、同一のオーディオデータが、少なくとも２回送信される。１回目の送信が行われた後（通常のタイミングで送信が行われた後）、２回目の送信が行われるタイミング（冗長化させるための送信が行われるタイミング）は、ステップ１３（図１３）の処理で決定（制御）される。
【０１２６】
図１５は、１回目の送信が行われた直後に、２回目の送信が行われた場合のＲＴＰパケットの並びを示す図である。ここでは、図１１に示したＲＴＰパケットが送信された後（冗長化制御部２７による処理が行われた後）に、図１２に示したＲＴＰパケットが送信されるとして説明する。
【０１２７】
図１１に示したＲＴＰパケットのＲＴＰヘッダ１０２のシークエンスナンバーは、“１２３４ｈ”である。このＲＴＰヘッダ１０２が付加されているのはＴＳパケット列１０１である。次に送信（処理）されるのは、図１２に示したＲＴＰパケットであるので、そのＲＴＰヘッダ１１２のシークエンスナンバーは、“１２３５ｈ”であり、そのＲＴＰヘッダ１１２が付加されているのは、ＴＳパケット列１１１である。
【０１２８】
図１２に示したＲＴＰパケットには、オーディオデータが含まれている。よって、冗長化制御部２７の制御により、記憶部２８には、図１４Ｂに示しようなＲＴＰパケットが記憶される。記憶されたＲＴＰパケット、すなわち、この場合、ＲＴＰヘッダ１１２が付加されたＴＳパケット列１２１は、図１５に示すように、ＴＳパケット列１１１の後に送信されるように制御される。
【０１２９】
図１５に示した例で、ＲＴＰヘッダだけに注目すると、同じシークエンスナンバー“１２３５ｈ”を有するＲＴＰヘッダ１１２が、連続して送信されることになる。このような場合、図１３に示したフローチャートの処理のうち、ステップＳ１３の処理が行われる必要はない。この場合、記憶部２８に記憶されたＲＴＰパケットが、同じシークエンスナンバーを有するＲＴＰパケットが、ＵＤＰヘッダ付加部２３から出力された直後に、ＵＤＰヘッダ付加部２３に供給されるように制御されればよい。
【０１３０】
しかしながら、何らかの原因で、受信機２側で送信されてきたデータが受信できないような状況、すなわち、パケットが欠落してしまうような状況は、すぐに改善されるものではないと考えられる。換言すれば、パケットの欠落が発生するような状況では、１つのパケットだけが欠落するのではなく、続けて複数のパケットが欠落すると考えられる。一例として、経験的な値を挙げると、パケットの欠落が発生したときは、１０乃至１５個のＲＴＰパケットが連続して欠落する可能性が高い。
【０１３１】
このようなことを考慮すると、パケットの欠落が発生したときに対応するために、少なくともオーディオデータだけは、複数回送信するようにしても、その送信するタイミングを考慮しなければ、意味のない送信処理となってしまう。
【０１３２】
例えば、図１５を再度参照するに、ＲＴＰヘッダ１１２が付加されているＲＴＰパケットが欠落したような場合、その直後に同一のＲＴＰヘッダ１１２が付加されているＲＴＰパケットを送信したとしても、その２度目の送信のＲＴＰパケット自体も欠落してまう可能性が高いことになる。よって結果として、欠落に対応するために送信したパケット自体も欠落してしまう可能性が高く、意味のない送信を繰り返すことになる可能性が高い。
【０１３３】
更に換言するならば、パケットの欠落が発生したときに対応するために、少なくともオーディオデータだけは、２回送信するようにした場合、１回目の送信が行われた後、例えば、１５個のＲＴＰパケットが送信された後に、２回目の送信が行われるようにする。このように１回目の送信と２回目の送信との間に、所定の間隔を設けることにより、１回目の送信により送信されたＲＴＰパケットが欠落してしまっても、２回目の送信により送信されたＲＴＰパケットが受信される可能性を高めることが可能となる。
【０１３４】
このようなことを考慮し、ステップＳ１３（図１３）の処理が設けられている。従って、ステップＳ１３における処理は、所定の数のＲＴＰパケットとして、例えば、１５個のＲＴＰパケットと設定され、１５個のＲＴＰパケットが供給されたか否かが冗長化制御部２７により判断されるようにすればよい。
【０１３５】
このように、所定の数のＲＴＰパケットが送信された後に、２回目の送信が行われるようにしたときのＲＴＰパケットの並びを図１６に示す。図１６に示した例で、ＲＴＰヘッダに注目すると、ＲＴＰヘッダ１０２、ＲＴＰヘッダ１１２、および、ＲＴＰヘッダ１３２の、それぞれのシークエンスナンバーは、その順序で、連続した値とされている。すなわち、処理された順に、送信されることを示す。
【０１３６】
そして、所定の数のＲＴＰパケットが送信された後に、再度、シークエンスナンバーが“１２３５ｈ”のＲＴＰヘッダ１１２が送信される。仮に、ＲＴＰヘッダ１０２が送信された直後のＲＴＰヘッダ１１２（ＴＳパケット列１１１）が、何らかの原因で、欠落したとしても、所定の数のＲＴＰパケットが送信された後送信される、同一のＲＴＰヘッダ１１２（ＴＳパケット列１２１）の方は、通信状態が改善され、受信される可能性が高い。
【０１３７】
よって、１回目の送信または２回目の送信により送信されたパケットのうち、少なくとも一方を受信できれば、この場合、オーディオデータの欠落は、実質的にないことになり、ユーザに提供される音声がとぎれるといったような不都合を防ぐことが可能となる。
【０１３８】
次に、このようにして、所定のデータが、複数回送信されてくる受信機２側の処理について説明する。図１７は、受信機２の動作について説明するためのフローチャートである。ステップＳ３１において、通信部８１（図９）により受信された送信機１から送信されたデータ（ＭＡＣパケット）は、ＭＡＣヘッダ抽出部８２に供給される。
【０１３９】
ＭＡＣヘッダ抽出部８２は、供給されたＭＡＣパケットからＭＡＣヘッダ４５を抽出し、ＩＰパケットをＩＰヘッダ抽出部８３に供給する。ＩＰヘッダ抽出部８３は、供給されたＩＰパケットからＩＰヘッダ４４を抽出し、ＵＤＰパケットをＵＤＰヘッダ抽出部８４に供給する。ＵＤＰヘッダ抽出部８４は、供給されたＵＤＰパケットからＵＤＰヘッダ４３を抽出し、ＲＴＰパケットを順序再構成部８５に供給する。
【０１４０】
このようにして、各部において各ヘッダが抽出される。各部は、抽出したヘッダを用いた所定の処理を行うが、本発明においては、その処理については直接的な関係がないため、その処理に関する説明は省略する。
【０１４１】
順序再構成部８５は、ステップＳ３２において、供給されたＲＴＰパケット内に含まれるＲＴＰヘッダ４２を参照する。このとき参照されるのは、ＲＴＰヘッダ４２内のシークエンスナンバー（Ｓｅｑｕｅｎｃｅ Ｎｕｍｂｅｒ）である。順序再構成部８５は、ステップＳ３３において、参照したシークエンスナンバーに関連付けられて、ＴＳパケットが既に記憶されているか否かを、記憶部８７を参照して判断する。
【０１４２】
図１０を参照して既に説明したように、記憶部８７には、シークエンスナンバーと、そのシークエンスナンバーを有するＲＴＰヘッダ４２が付加されていたＴＳパケット列４１（図３）が、関連付けられて記憶されている。そこで、順序再構成部８５は、ステップＳ３２およびステップＳ３３の処理として、供給されたＲＴＰパケットのＲＴＰヘッダ４２に含まれるシークエンスナンバーを参照し、そのシークエンスナンバーに関連付けられてＴＳパケット列４１が、記憶部８７に記憶されているか否かを判断する。
【０１４３】
ステップＳ３３において、供給されたＲＴＰヘッダ４２に含まれるシークエンスナンバーに関連付けられたＴＳパケット列４１は、記憶部８７に記憶されていないと判断すると、ステップＳ３４に処理が進められる。ステップＳ３４において、順序再構成部８５は、供給されたＲＴＰパケットをＲＴＰヘッダ抽出部８６に供給する。
【０１４４】
ＲＴＰヘッダ抽出部８６は、供給されたＲＴＰパケットからＲＴＰヘッダ４２を抽出し、ＴＳパケット列４１を記憶部８７に供給し、記憶させる。この際、ＲＴＰヘッダ４２に含まれるシークエンスナンバーに関連付けられて、ＴＳパケット列４１は記憶部８７に記憶される。
【０１４５】
この記憶までの処理について説明を加えるに、順序再構成部８５が、供給されたＲＴＰヘッダ４２のシークエンスナンバーに関連付けられ、ＴＳパケット列４１が、記憶部８７に記憶されてはいないと判断する状況としては、２つの状況が考えられる。
【０１４６】
１つ目の状況としては、新たに供給されたＲＴＰパケット（ＴＳパケット列４１）であるために、まだ、その時点では、記憶部８７には記憶されていないという状況である。２つ目の状況としては、既に、本来ならば受信され、処理され、記憶されているＴＳパケット列４１が、何らかの原因で、受信されなかったために、すなわち、そのＴＳパケット列４１が欠落したために、記憶部８７に記憶されていないという状況である。
【０１４７】
２つ目の状況では、既に、シークエンスナンバー自体は、記憶部８７に記憶されている状態である。図１０を再度参照するに、シークエンスナンバー“３”に関連付けて記憶されるＴＳパケット列４１（ＴＳパケット５１−１−３乃至５１−７−３）は、欠落したために記憶されていない状態である。このように、欠落したと判断されるパケットを記憶させるための領域は、シークエンスナンバーと関連付けられて管理されている（確保されている）。
【０１４８】
このような２つ目の状況のときにステップＳ３４に処理が進められたときには、順序再構成部８５（若しくは、ＲＴＰヘッダ抽出部８６）は、供給されたＲＴＰパケットに含まれるＴＳパケット列４１が、その供給されたＲＴＰパケットのＲＴＰヘッダ４２に含まれるシークエンスナンバーと関連付けられて記憶部８７に既に確保されている領域に記憶されるように制御する。
【０１４９】
すなわちこの場合、後に受信されたＴＳパケット列４１が、その時点で処理されているＴＳパケット列４１よりも先に、ＭＰＥＧデコーダ８８に供給されるような領域に記憶されることになる。
【０１５０】
ただし、後に受信される（２度目の送信で送信されてきた）ＴＳパケット列４１には、ここでは、オーディオデータしか含まれていないので、そのオーディオデータを含むＴＳパケット５１のみが記憶される。ビデオデータも複数回送信されるようにすれば、ビデオデータも記憶される（従って、ＴＳパケット列４１が記憶される）。
【０１５１】
このようにして、欠落したパケットであっても、後の時点で再度送信されてくるパケットが受信、処理されれば、記憶部８７に記憶されることになる。従って、パケットが欠落したような状況でも、その欠落による影響を受けないようにさせることが可能となる。
【０１５２】
図１７に示したフローチャートの説明に戻り、ステップＳ３３において、順序再構成部８５が、供給されたＲＴＰヘッダ４２に含まれるシークエンスナンバーに対応するＴＳパケット列４１は、既に、記憶部８７に記憶されていると判断した場合、ステップＳ３５に処理が進められる。
【０１５３】
このような状況は、再送されてきたパケットを受信したときであり、かつ、１回目の送信により送信されてきたパケットも正常に受信され、処理され、記憶された状態であることを示している。このような状況では、再度、記憶部８７に記憶させる処理を実行する必要はないので、ステップＳ３５の処理として、順序再構成部８５は、供給されたＲＴＰパケットを破棄する。
【０１５４】
このような処理が受信機２側で行われることにより、パケットの欠落が発生したような状況でも、再度送信されてくるパケットを受信し、処理すれば、その欠落による発生する影響を低減さえることが可能となり、かつ、パケットの欠落に対する処理に多大な能力をさくようなことを防ぐことも可能となる。
【０１５５】
ところで、上述した実施の形態においては、複数回（２回）送信されるとして説明したが、複数回送信される場合、その回数に制限を設ける必要がある。また、２回だけ送信される場合であっても、１回目の送信と、２回目の送信の間を、時間的にどの程度あけるかが問題となる。
【０１５６】
このようなことを考慮すべき理由について説明する。記憶部８７に記憶されているＴＳパケットは、順次、ＭＰＥＧデコーダ８８に供給される。
【０１５７】
図１０を再度参照するに、シークエンスナンバー“１”に関連付けられているＴＳパケット５１−１−１乃至５１−７−１が、ＭＰＥＧデコーダ８８に供給された後に、シークエンスナンバー“２”に関連付けられているＴＳパケット５１−１−２乃至５１−７−２がＭＰＥＧデコーダ８８に供給される。
【０１５８】
その後、シークエンスナンバー“３”に関連付けられているＴＳパケットが、ＭＰＥＧデコーダ８８に供給されるが、供給される時点で、記憶されていなければ、供給することができず、そのシークエンスナンバー“３”に関連付けられているＴＳパケットが供給されることなく、次のシークエンスナンバー“４”に関連付けられているＴＳパケット５１−１−４乃至５１−７−４が供給される。
【０１５９】
このようなことを換言すれば、シークエンスナンバー“４”に関連付けられているＴＳパケットがＭＰＥＧデコーダ８８に供給されるより前の時点までに、シークエンスナンバー“３”に関連付けられるＴＳパケットが、記憶部８７に記憶されなければ、その後の時点で、シークエンスナンバー“３”に関連付けられるＴＳパケットを取得する必要はなく、そのための処理も行われる必要はない。
【０１６０】
このようなことを考慮すれば、送信機１から複数回同一のパケットが送信されるようにした場合、その複数回送信される回数は、受信機２の記憶部８７が記憶できる容量に依存して、決定される必要がある。
【０１６１】
例えば、記憶部８７の記憶容量が、１秒間分のパケットデータを記憶できるだけの容量である場合、送信機１が、１秒以上経過した後に、同一のパケットを送信しても意味がないことになる。そこで、例えば、１００ミリ秒毎に、同一のパケットが送信される設定にされているような場合（ステップＳ１３（図１３）の処理で、１００ミリ秒の間に処理されるＲＴＰパケットの個数が設定されているような場合）、複数回の送信の回数として９回と設定されていればよい。
【０１６２】
すなわち、１０回目の送信は、たとえ送信が実行され、受信機２側で受信されても、意味のない処理が行われることになるので、その１０回目の送信が行われないような制限が設定されていればよい。また、２回だけ送信が行われると設定されているような場合、１秒間の間に２回の送信が行われる（完了する）ように設定されていればよい。
【０１６３】
なお、複数回送信する際の回数や、送信する間隔は、上述したことの他に、受信機２側で、パケットを受信してから記憶するまでの時間や、そのパケットの送受信にかかる時間なども考慮して設定される方が好ましい。
【０１６４】
ここで、受信機２の動作について更に説明を加える。上述した実施の形態においては、ステップＳ３３（図１７）の処理は、順序再構成部８５が、記憶部８７を参照することにより行うとして説明したが、記憶部８７が参照されずに行われるようにしても良い。そのようにした場合について説明する。
【０１６５】
順序再構成部８５は、供給されたＲＴＰパケットのＲＴＰヘッダ４２のうち、シークエンスナンバーを参照する。そこで、その参照したシークエンスナンバーを記憶する機能を順序再構成部８５自体が備えるようにする。そのようにすれば、順序再構成部８５は、供給されたＲＴＰヘッダ４２に含まれるシークエンスナンバーは、既に自己が記憶しているシークエンスナンバーであるか否かを判断することにより、ステップＳ３３の処理を行うことができる。
【０１６６】
このようにした場合でも、その他の処理は、基本的に、既に説明した場合と同様であるので、その説明は省略する。
【０１６７】
また順序再構成部８５が、供給されたＲＴＰヘッダ４２のシークエンスナンバーを参照することを用い、以下のような処理で、ステップＳ３３の処理が行われるようにしても良い。すなわち、まず、順序再構成部８５は、供給されたＲＴＰヘッダ４２に含まれるシークエンスナンバーが、１つ前の時点で供給されたＲＴＰヘッダ４２に含まれるシークエンスナンバーに連続した番号であるか否かを判断する。
【０１６８】
シークエンスナンバーは、送信機１側で、処理した順に、昇順（または降順、ここでは、昇順として説明する）の番号が割り振られ、その順で送信される。従って、受信機２側では、送信された順に受信され、処理される。しかしながら、パケットの欠落が発生すると、シークエンスナンバーの番号が飛ぶことになる。すなわち、連続性がとぎれることになる。
【０１６９】
そこで、順序再構成部８５が、シークエンスナンバーの連続性を判断するようにし、連続性がとぎれたと判断した場合、そのとぎれた部分に存在すべきシークエンスナンバーの番号を算出し、記憶する。また、順序再構成部８５は、連続性がとぎれたと判断したときには、その時点で自己が記憶している番号内に、供給されているＲＴＰヘッダ４２のシークエンスナンバーと一致する番号が存在するか否かを判断する。
【０１７０】
このような判断を経て、順序再構成部８５が、供給されたＲＴＰヘッダ４２のシークエンスナンバーと一致する番号が、自己が記憶している番号内に存在すると判断した場合、すなわち、欠落したパケットだが、再送されてきたことにより受信できたパケットであると判断した場合、その供給されたＲＴＰパケットに含まれるＴＳパケット列４１が、記憶部８７の所定の領域に記憶されるように制御が行われる。
【０１７１】
このようにして、複数回送信されてきたパケットに対する処理が行われるようにしても良い。
【０１７２】
上述した実施の形態では、オーディオデータが複数回送信されるとして説明したが、ビデオデータが複数回送信されるようにしてもよいし、ビデオデータも複数回送信されるようにしても良い。また、オーディオデータやビデオデータと異なる、他のデータ（例えば、ヘッダに含まれる情報など）が、複数回送信されるようにしても良い。
【０１７３】
例えば、文字放送用のデータやＥＰＧ（Ｅｌｅｃｔｒｏｎｉｃ Ｐｒｏｇｒａｍ Ｇｕｉｄｅ）のデータなどのデータが、複数回送信されるようにしても良い。オーディオデータ以外の所定のデータを複数回送信するようにした場合、図１３のステップＳ１１の処理として、その所定のデータが含まれるか否かが判断されるようにすればよい。そして、上述したような、ステップＳ１１以下の処理が行われるようにすれば良い。
【０１７４】
この複数回送信されるデータとしては、上述した実施の形態では、オーディオデータとしたが、オーディオデータを複数回送信するようにしたのは、オーディオデータの方がビデオデータに対して、そのデータ量は小さく、複数回送信したとしても、その処理に係る処理により、他の処理に影響与えることが少ないと考えられるからである。
【０１７５】
そのような考えにもとづくと、本発明の一実施の形態としては、比較的データ量の小さいデータを複数回送信することになる。よって、オーディオデータに限らず、データ量の小さいデータを複数回送信する場合にも本発明を適用することができる。
【０１７６】
データ量の小さいデータを判断するのは、予めデータ量が比較的小さいとされる種類のデータを設定しておき（上述した実施の形態ではオーディオデータといる種類）、その種類のデータが、取得されたデータ内に含まれているか否かを判断するようにしても良い。または、所定のデータ量を設定しておき（閾値を設定しておき）、その設定されている所定のデータ量以下のデータを含むか否かを判断するようにしても良い。
【０１７７】
そして、判断された結果、記憶されるデータが、複数回送信されるようにしても良い。
【０１７８】
上述したように、所定のデータを時間的にずらしたタイミングで、複数回送信するようにすることで、データの欠落が発生したようなときでも、ユーザに提供される映像や音声がとぎれるといった不都合が発生することを低減させることが可能となる。もって、送信機１と受信機２の間で行われる通信の信頼性を向上させることが可能となる。
【０１７９】
上述した一連の処理は、それぞれの機能を有するハードウェアにより実行させることもできるが、ソフトウェアにより実行させることもできる。一連の処理をソフトウェアにより実行させる場合には、そのソフトウェアを構成するプログラムが専用のハードウェアに組み込まれているコンピュータ、または、各種のプログラムをインストールすることで、各種の機能を実行することが可能な、例えば汎用のパーソナルコンピュータなどに、記録媒体からインストールされる。
【０１８０】
記録媒体の説明をする前に、簡便にパーソナルコンピュータについて説明する。図１８は、汎用のパーソナルコンピュータの内部構成例を示す図である。パーソナルコンピュータのＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）２０１は、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）２０２に記憶されているプログラムに従って各種の処理を実行する。ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）２０３には、ＣＰＵ２０１が各種の処理を実行する上において必要なデータやプログラムなどが適宜記憶される。入出力インタフェース２０５は、キーボードやマウスから構成される入力部２０６が接続され、入力部２０６に入力された信号をＣＰＵ２０１に出力する。また、入出力インタフェース２０５には、ディスプレイやスピーカなどから構成される出力部２０７も接続されている。
【０１８１】
さらに、入出力インタフェース２０５には、ハードディスクなどから構成される記憶部２０８、および、インターネットなどのネットワークを介して他の装置とデータの授受を行う通信部２０９も接続されている。ドライブ２１０は、磁気ディスク２２１、光ディスク２２２、光磁気ディスク２２３、半導体メモリ２２４などの記録媒体からデータを読み出したり、データを書き込んだりするときに用いられる。
【０１８２】
記録媒体は、図１８に示すように、パーソナルコンピュータとは別に、ユーザにプログラムを提供するために配布される、プログラムが記録されている磁気ディスク２２１（フレキシブルディスクを含む）、光ディスク２２２（ＣＤ−ＲＯＭ（Ｃｏｍｐａｃｔ Ｄｉｓｃ−Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ），ＤＶＤ（Ｄｉｇｉｔａｌ Ｖｅｒｓａｔｉｌｅ Ｄｉｓｃ）を含む）、光磁気ディスク２２３（ＭＤ（Ｍｉｎｉ−Ｄｉｓｃ）（登録商標）を含む）、若しくは半導体メモリ２２４などよりなるパッケージメディアにより構成されるだけでなく、コンピュータに予め組み込まれた状態でユーザに提供される、プログラムが記憶されているＲＯＭ２０２や記憶部２０８が含まれるハードディスクなどで構成される。
【０１８３】
なお、本明細書において、媒体により提供されるプログラムを記述するステップは、記載された順序に従って、時系列的に行われる処理は勿論、必ずしも時系列的に処理されなくとも、並列的あるいは個別に実行される処理をも含むものである。
【０１８４】
また、本明細書において、システムとは、複数の装置により構成される装置全体を表すものである。
【０１８５】
【発明の効果】
本発明によれば、通信の信頼性を高めることが可能となる。
【０１８６】
本発明によれば、データの欠落が発生しても、そのデータを補うことが可能となる。もって、ユーザに提供される映像や音声にとぎれや乱れが発生するようなことを抑えることが可能となる。
【図面の簡単な説明】
【図１】本発明を適用した送受信システムの一実施の形態の構成を示す図である。
【図２】送信機の内部構成例を示す図である。
【図３】送信機から送信されるデータについて説明するための図である。
【図４】ＴＳパケットのヘッダについて説明するための図である。
【図５】ＲＴＰヘッダについて説明するための図である。
【図６】ＵＤＰヘッダについて説明するための図である。
【図７】ＩＰヘッダについて説明するための図である。
【図８】ＭＡＣヘッダについて説明するための図である。
【図９】受信機の内部構成例を示す図である。
【図１０】記憶部に記憶されているデータについて説明するための図である。
【図１１】パケットの構成について説明する図である。
【図１２】パケットの構成について説明する図である。
【図１３】冗長化処理について説明するフローチャートである。
【図１４】パケットの構成について説明する図である。
【図１５】パケットの構成について説明する図である。
【図１６】パケットの構成について説明する図である。
【図１７】記憶にかかわる処理について説明するフローチャートである。
【図１８】媒体を説明する図である。
【符号の説明】
１ 送信機， ２１ ＭＰＥＧエンコーダ， ２２ ＲＴＰヘッダ付加部， ２３ ＵＤＰヘッダ付加部， ２４ ＩＰヘッダ付加部， ２５ ＭＡＣヘッダ付加部， ２６ 通信部， ２７ 再送制御部， ２８ 記憶部， ８１ 通信部， ８２ ＭＡＣヘッダ抽出部， ８３ ＩＰヘッダ抽出部， ８４ ＵＤＰヘッダ抽出部， ８５ 順序再構成部， ８６ ＲＴＰヘッダ抽出部， ８７ 記憶部， ８８ ＭＰＥＧデコーダ
Claims (14)
- データを送信する送信装置と、前記送信装置から送信された前記データを受信する受信装置から構成される送受信システムにおいて、
前記送信装置は、
前記データを取得する取得手段と、
前記取得手段により取得された前記データを前記受信装置に送信する送信手段と、
前記取得手段により取得された前記データを記憶する記憶手段と、
前記記憶手段から前記データを読み出し、前記送信手段に、前記読み出されたデータの送信を指示する指示手段と
を備え、
前記受信装置は、
前記送信手段により送信された前記データを受信する受信手段と、
前記受信手段により前記データが受信されたとき、そのデータは、既に受信されているデータであるか否かを判断する判断手段と、
前記判断手段により、前記受信手段により受信された前記データは、既に受信されたデータであると判断された場合、そのデータを破棄し、既に受信されたデータではないと判断された場合、そのデータ記憶する記憶制御手段と
を備える
ことを特徴とする送受信システム。 - データを取得する取得手段と、
前記取得手段により取得された前記データを送信する送信手段と、
前記取得手段により取得された前記データを記憶する記憶手段と、
前記記憶手段から前記データを読み出し、前記送信手段に、前記読み出されたデータの送信を指示する指示手段と
を備えることを特徴とする送信装置。 - 前記指示手段は、前記送信手段により前記データが送信された後、所定の時間が経過すると、前記記憶手段から前記データを読み出し、前記送信手段に、前記読み出されたデータの送信を指示する
ことを特徴とする請求項２に記載の送信装置。 - 前記取得手段により取得された前記データ内に、所定のデータが含まれるか否かを判断する判断手段を
さらに含み、
前記記憶手段は、前記判断手段により前記データ内に、前記所定のデータが含まれていると判断された場合、その所定のデータを記憶し、
前記指示手段は、前記記憶手段から前記所定のデータを読み出し、前記送信手段に送信させる
ことを特徴とする請求項２に記載の送信装置。 - 前記取得手段により取得された前記データ内に、オーディオデータが含まれるか否かを判断する判断手段を
さらに含み、
前記記憶手段は、前記判断手段により前記データ内に、オーディオデータが含まれていると判断された場合、そのオーディオデータと、そのオーディオデータに付加されているヘッダを記憶し、
前記指示手段は、前記記憶手段から前記ヘッダと前記オーディオデータを読み出し、前記送信手段に送信させる
ことを特徴とする請求項２に記載の送信装置。 - 前記ヘッダは、ＲＴＰヘッダである
ことを特徴とする請求項５に記載の送信装置。 - データの取得を制御する取得制御ステップと、
前記取得制御ステップの処理で取得が制御された前記データの送信を制御する送信制御ステップと、
前記取得制御ステップの処理により取得が制御された前記データの記憶を制御する記憶制御ステップと、
前記記憶制御ステップにより記憶が制御された前記データを読み出し、前記送信制御ステップの処理で、前記読み出されたデータが送信されるように指示する指示ステップと
を含むことを特徴とする送信方法。 - データの取得を制御する取得制御ステップと、
前記取得制御ステップの処理で取得が制御された前記データの送信を制御する送信制御ステップと、
前記取得制御ステップの処理により取得が制御された前記データの記憶を制御する記憶制御ステップと、
前記記憶制御ステップにより記憶が制御された前記データを読み出し、前記送信制御ステップの処理で、前記読み出されたデータが送信されるように指示する指示ステップと
を含むことを特徴とするコンピュータが読み取り可能なプログラムが記録されている記録媒体。 - データの取得を制御する取得制御ステップと、
前記取得制御ステップの処理で取得が制御された前記データの送信を制御する送信制御ステップと、
前記取得制御ステップの処理により取得が制御された前記データの記憶を制御する記憶制御ステップと、
前記記憶制御ステップにより記憶が制御された前記データを読み出し、前記送信制御ステップの処理で、前記読み出されたデータが送信されるように指示する指示ステップと
をコンピュータに実行させることを特徴とするプログラム。 - データを受信する受信手段と、
前記受信手段により前記データが受信されたとき、そのデータは、既に受信されているデータであるか否かを判断する判断手段と、
前記判断手段により、前記受信手段により受信された前記データは、既に受信されているデータであると判断された場合、そのデータを破棄し、既に受信されているデータではないと判断された場合、そのデータ記憶する記憶制御手段と
を備えることを特徴とする受信装置。 - 前記判断手段は、前記受信手段により受信された前記データに含まれるＲＴＰヘッダのＳｅｑｕｅｎｃｅ Ｎｕｍｂｅｒを参照し、前記データが、既に受信されたデータであるか否かを判断する
ことを特徴とする請求項１０に記載の受信装置。 - データの受信を制御する受信制御ステップと、
前記受信制御ステップの処理により前記データが受信されたとき、そのデータは、既に受信されているデータであるか否かを判断する判断ステップと、
前記判断ステップの処理により、前記受信制御ステップの処理により受信された前記データは、既に受信されているデータであると判断された場合、そのデータを破棄し、既に受信されているデータではないと判断された場合、そのデータ記憶する記憶制御ステップと
を含むことを特徴とする受信方法。 - データの受信を制御する受信制御ステップと、
前記受信制御ステップの処理により前記データが受信されたとき、そのデータは、既に受信されているデータであるか否かを判断する判断ステップと、
前記判断ステップの処理により、前記受信制御ステップの処理により受信された前記データは、既に受信されているデータであると判断された場合、そのデータを破棄し、既に受信されているデータではないと判断された場合、そのデータ記憶する記憶制御ステップと
を含むことを特徴とするコンピュータが読み取り可能なプログラムが記録されている記録媒体。 - データの受信を制御する受信制御ステップと、
前記受信制御ステップの処理により前記データが受信されたとき、そのデータは、既に受信されているデータであるか否かを判断する判断ステップと、
前記判断ステップの処理により、前記受信制御ステップの処理により受信された前記データは、既に受信されているデータであると判断された場合、そのデータを破棄し、既に受信されているデータではないと判断された場合、そのデータ記憶する記憶制御ステップと
をコンピュータに実行させることを特徴とするプログラム。
Priority Applications (6)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2003073075A JP3994388B2 (ja) | 2003-03-18 | 2003-03-18 | 送受信システム、送信装置および方法、記録媒体、並びにプログラム |
| US10/549,879 US7536466B2 (en) | 2003-03-18 | 2004-03-12 | Sending-receiving system, sender apparatus, sending method, receiver apparatus, receiving method, recording medium, and program for improving communication reliability |
| KR1020057017484A KR20050120652A (ko) | 2003-03-18 | 2004-03-12 | 송수신 시스템, 송신 장치 및 방법, 수신 장치 및 방법,기록 매체, 및 프로그램 |
| EP20040720219 EP1605659A1 (en) | 2003-03-18 | 2004-03-12 | Transmission/reception system, transmission device and method, reception device and method, recording medium, and program |
| PCT/JP2004/003350 WO2004084516A1 (ja) | 2003-03-18 | 2004-03-12 | 送受信システム、送信装置および方法、受信装置および方法、記録媒体、並びにプログラム |
| CNA2004800050734A CN1757214A (zh) | 2003-03-18 | 2004-03-12 | 发送/接收系统、发送装置和方法、接收装置和方法、记录介质和程序 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2003073075A JP3994388B2 (ja) | 2003-03-18 | 2003-03-18 | 送受信システム、送信装置および方法、記録媒体、並びにプログラム |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2004282538A true JP2004282538A (ja) | 2004-10-07 |
| JP3994388B2 JP3994388B2 (ja) | 2007-10-17 |
Family
ID=33027785
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2003073075A Expired - Fee Related JP3994388B2 (ja) | 2003-03-18 | 2003-03-18 | 送受信システム、送信装置および方法、記録媒体、並びにプログラム |
Country Status (6)
| Country | Link |
|---|---|
| US (1) | US7536466B2 (ja) |
| EP (1) | EP1605659A1 (ja) |
| JP (1) | JP3994388B2 (ja) |
| KR (1) | KR20050120652A (ja) |
| CN (1) | CN1757214A (ja) |
| WO (1) | WO2004084516A1 (ja) |
Cited By (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2007007526A1 (ja) * | 2005-07-12 | 2007-01-18 | Matsushita Electric Industrial Co., Ltd. | 映像ストリーム処理装置、集積回路装置、及び方法 |
| WO2007007509A1 (ja) * | 2005-07-12 | 2007-01-18 | Matsushita Electric Industrial Co., Ltd. | 映像ストリーム受信装置及びその方法 |
| KR100749840B1 (ko) | 2005-08-26 | 2007-08-16 | 경희대학교 산학협력단 | 무선 통신 데이터를 끊어짐 없이 연속하여 재생하는 방법및 그 장치 |
| KR100767502B1 (ko) | 2006-01-23 | 2007-10-17 | 주식회사 팬택앤큐리텔 | 약전계시 비디오 끊김 현상을 방지하는 ｄｍｂ 재생 시스템 |
| JP2009500925A (ja) * | 2005-06-30 | 2009-01-08 | クゥアルコム・インコーポレイテッド | 無線システムにおける多くの同時通信におけるコンフリクトを解決するためのシステム及び方法 |
| JP2009182628A (ja) * | 2008-01-30 | 2009-08-13 | Oki Electric Ind Co Ltd | 誤り訂正符号生成装置、誤り訂正符号生成プログラム、データ提供装置及びデータ提供システム |
Families Citing this family (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20090031370A1 (en) * | 2007-07-23 | 2009-01-29 | The Directv Group, Inc. | Method and system for communicating broadband content availability through a satellite |
| US8582491B2 (en) * | 2008-05-02 | 2013-11-12 | Lockheed Martin Corporation | Method and apparatus for routing communications using active and passive end-to-end quality-of-service reservations based on node mobility profiles |
| US7920569B1 (en) * | 2008-05-05 | 2011-04-05 | Juniper Networks, Inc. | Multi-link transport protocol translation |
| CN102651230A (zh) * | 2011-02-23 | 2012-08-29 | 瑞轩科技股份有限公司 | 无线音讯与视讯同步播放的方法及其播放系统 |
| IL217305A0 (en) * | 2012-01-01 | 2012-02-29 | Video Flow Ltd | Transport over udp system and method |
| US11245890B2 (en) * | 2018-04-04 | 2022-02-08 | Sony Interactive Entertainment Inc. | Communication apparatus, generated data size control method, communication method, and program |
| WO2019193668A1 (ja) | 2018-04-04 | 2019-10-10 | 株式会社ソニー・インタラクティブエンタテインメント | 通信装置、生成データサイズ制御方法及びプログラム |
| CN108784685B (zh) * | 2018-05-24 | 2021-04-02 | 北京维康恒科技有限公司 | 心电波形数据处理方法及装置 |
| US11163478B2 (en) * | 2018-09-18 | 2021-11-02 | International Business Machines Corporation | Reducing the amount of data transferred to remote storage locations for modified objects |
Family Cites Families (10)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| DE69525895T2 (de) | 1994-10-11 | 2002-09-05 | Nippon Telegraph & Telephone | System für Sendewiederholung in der Datenkommunikation |
| JP2861895B2 (ja) * | 1994-10-11 | 1999-02-24 | 日本電信電話株式会社 | データ通信再送方法および装置 |
| JP2861953B2 (ja) * | 1996-07-03 | 1999-02-24 | 日本電信電話株式会社 | データ通信再送方法及び装置 |
| JPH11225161A (ja) | 1998-02-05 | 1999-08-17 | Matsushita Electric Ind Co Ltd | データ処理方法およびデータ処理装置 |
| JPH11234249A (ja) * | 1998-02-18 | 1999-08-27 | Matsushita Electric Ind Co Ltd | データ通信装置 |
| JP2001268121A (ja) | 2000-03-21 | 2001-09-28 | Nec Corp | 音声パケット送信方式及びその方法 |
| US7035285B2 (en) * | 2000-04-07 | 2006-04-25 | Broadcom Corporation | Transceiver method and signal therefor embodied in a carrier wave for a frame-based communications network |
| JP3752137B2 (ja) | 2000-08-31 | 2006-03-08 | 三菱電機株式会社 | データ送信装置及びデータ送信方法 |
| JP2002247134A (ja) | 2001-02-20 | 2002-08-30 | Nippon Hoso Kyokai <Nhk> | 通信制御方式、受信装置、および、送信装置 |
| JP2002262286A (ja) | 2001-03-02 | 2002-09-13 | Canon Inc | データ伝送方法、データ伝送装置、再生方法及び再生装置 |
-
2003
- 2003-03-18 JP JP2003073075A patent/JP3994388B2/ja not_active Expired - Fee Related
-
2004
- 2004-03-12 WO PCT/JP2004/003350 patent/WO2004084516A1/ja active Application Filing
- 2004-03-12 KR KR1020057017484A patent/KR20050120652A/ko not_active Application Discontinuation
- 2004-03-12 EP EP20040720219 patent/EP1605659A1/en not_active Withdrawn
- 2004-03-12 US US10/549,879 patent/US7536466B2/en not_active Expired - Fee Related
- 2004-03-12 CN CNA2004800050734A patent/CN1757214A/zh active Pending
Cited By (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2009500925A (ja) * | 2005-06-30 | 2009-01-08 | クゥアルコム・インコーポレイテッド | 無線システムにおける多くの同時通信におけるコンフリクトを解決するためのシステム及び方法 |
| US8705515B2 (en) | 2005-06-30 | 2014-04-22 | Qualcomm Incorporated | System and method for resolving conflicts in multiple simultaneous communications in a wireless system |
| WO2007007526A1 (ja) * | 2005-07-12 | 2007-01-18 | Matsushita Electric Industrial Co., Ltd. | 映像ストリーム処理装置、集積回路装置、及び方法 |
| WO2007007509A1 (ja) * | 2005-07-12 | 2007-01-18 | Matsushita Electric Industrial Co., Ltd. | 映像ストリーム受信装置及びその方法 |
| KR100749840B1 (ko) | 2005-08-26 | 2007-08-16 | 경희대학교 산학협력단 | 무선 통신 데이터를 끊어짐 없이 연속하여 재생하는 방법및 그 장치 |
| KR100767502B1 (ko) | 2006-01-23 | 2007-10-17 | 주식회사 팬택앤큐리텔 | 약전계시 비디오 끊김 현상을 방지하는 ｄｍｂ 재생 시스템 |
| JP2009182628A (ja) * | 2008-01-30 | 2009-08-13 | Oki Electric Ind Co Ltd | 誤り訂正符号生成装置、誤り訂正符号生成プログラム、データ提供装置及びデータ提供システム |
Also Published As
| Publication number | Publication date |
|---|---|
| EP1605659A1 (en) | 2005-12-14 |
| US20060179151A1 (en) | 2006-08-10 |
| KR20050120652A (ko) | 2005-12-22 |
| WO2004084516A1 (ja) | 2004-09-30 |
| CN1757214A (zh) | 2006-04-05 |
| US7536466B2 (en) | 2009-05-19 |
| JP3994388B2 (ja) | 2007-10-17 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP5141197B2 (ja) | 符号化装置 | |
| US11895357B2 (en) | Broadcasting signal transmission device, broadcasting signal reception device, broadcasting signal transmission method, and broadcasting signal reception method | |
| KR101001514B1 (ko) | 송수신 시스템 및 수신 장치 | |
| JP6523249B2 (ja) | パケットヘッダを圧縮する方法及び装置 | |
| JP4321284B2 (ja) | ストリーミングデータ送信装置、および情報配信システム | |
| JP3994388B2 (ja) | 送受信システム、送信装置および方法、記録媒体、並びにプログラム | |
| US20170272691A1 (en) | Broadcast signal transmission device, broadcast signal reception device, broadcast signal transmission method, and broadcast signal reception method | |
| JP2002141945A (ja) | データ送信装置、およびデータ送信方法、並びにプログラム記憶媒体 | |
| CN111163111B (zh) | 发送设备及其信号处理方法 | |
| JP2005210219A (ja) | 送受信システム、送信装置および方法、受信装置および方法、記録媒体、並びにプログラム | |
| JP2007184702A (ja) | 放送コンテンツ伝送装置、放送コンテンツ受信装置、放送コンテンツ伝送方法、放送コンテンツ受信方法およびプログラム | |
| JP7397916B2 (ja) | 受信方法および端末 | |
| JP2005012753A (ja) | パケット中継装置及びその方法と、パケット受信装置及びその方法と、パケット中継プログラム及びそのプログラムを記録した記録媒体と、パケット受信プログラム及びそのプログラムを記録した記録媒体 | |
| JP2006270463A (ja) | パケットストリーム受信装置 | |
| JP6333969B2 (ja) | 放送送受信装置および放送送受信方法 | |
| JP3730977B2 (ja) | データ伝送方法およびデータ処理方法 | |
| CN111263197B (zh) | 发送设备及其信号处理方法 | |
| JP5159973B1 (ja) | 伝送パケットの配信方法 | |
| JP2004254084A (ja) | ディジタル放送受信装置及び受信方法、並びに、再生装置及び再生方法 | |
| JP2009049530A (ja) | データ送信装置、データ中継装置及びデータ受信装置 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20060831 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20061030 |
|
| A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20070416 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20070615 |
|
| A911 | Transfer to examiner for re-examination before appeal (zenchi) |
Free format text: JAPANESE INTERMEDIATE CODE: A911 Effective date: 20070621 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20070706 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20070719 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100810 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100810 Year of fee payment: 3 |
|
| LAPS | Cancellation because of no payment of annual fees |