JP2004266504A - 送受信システム、送信装置および方法、受信装置および方法、記録媒体、並びにプログラム - Google Patents
送受信システム、送信装置および方法、受信装置および方法、記録媒体、並びにプログラム Download PDFInfo
- Publication number
- JP2004266504A JP2004266504A JP2003053796A JP2003053796A JP2004266504A JP 2004266504 A JP2004266504 A JP 2004266504A JP 2003053796 A JP2003053796 A JP 2003053796A JP 2003053796 A JP2003053796 A JP 2003053796A JP 2004266504 A JP2004266504 A JP 2004266504A
- Authority
- JP
- Japan
- Prior art keywords
- data
- sequence number
- missing
- information
- retransmission
- 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.)
- Pending
Links
- 230000005540 biological transmission Effects 0.000 title claims abstract description 69
- 238000000034 method Methods 0.000 title claims description 68
- 238000012545 processing Methods 0.000 claims description 99
- 239000000284 extract Substances 0.000 claims description 10
- 238000005259 measurement Methods 0.000 claims description 2
- 230000006854 communication Effects 0.000 abstract description 45
- 238000004891 communication Methods 0.000 abstract description 44
- 238000010586 diagram Methods 0.000 description 22
- 238000000605 extraction Methods 0.000 description 9
- 230000006870 function Effects 0.000 description 4
- 230000001174 ascending effect Effects 0.000 description 3
- 239000000203 mixture Substances 0.000 description 3
- 238000012546 transfer Methods 0.000 description 3
- 230000006978 adaptation Effects 0.000 description 2
- 239000003550 marker Substances 0.000 description 2
- 230000003287 optical effect Effects 0.000 description 2
- 230000004044 response Effects 0.000 description 2
- 239000004065 semiconductor Substances 0.000 description 2
- 230000005856 abnormality Effects 0.000 description 1
- 230000006835 compression Effects 0.000 description 1
- 238000007906 compression Methods 0.000 description 1
- 238000012790 confirmation Methods 0.000 description 1
- 230000006866 deterioration Effects 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 238000011084 recovery Methods 0.000 description 1
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/12—Arrangements for detecting or preventing errors in the information received by using return channel
- H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
- H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
-
- 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/12—Arrangements for detecting or preventing errors in the information received by using return channel
- H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
- H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
- H04L1/1829—Arrangements specially adapted for the receiver end
- H04L1/1835—Buffer management
-
- 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
- H04L65/60—Network streaming of media packets
- H04L65/65—Network streaming protocols, e.g. real-time transport protocol [RTP] or real-time control protocol [RTCP]
-
- 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/12—Arrangements for detecting or preventing errors in the information received by using return channel
- H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
- H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
- H04L1/1829—Arrangements specially adapted for the receiver end
- H04L1/1848—Time-out mechanisms
-
- 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/12—Arrangements for detecting or preventing errors in the information received by using return channel
- H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
- H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
- H04L1/1867—Arrangements specially adapted for the transmitter end
- H04L1/1874—Buffer management
-
- 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
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/80—Responding to QoS
-
- 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/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
- H04L69/164—Adaptation or special uses of UDP protocol
-
- 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/22—Parsing or analysis of headers
-
- 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
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/40—Network security protocols
-
- 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/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Multimedia (AREA)
- Computer Security & Cryptography (AREA)
- Communication Control (AREA)
- Detection And Prevention Of Errors In Transmission (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Mobile Radio Communication Systems (AREA)
Abstract
【課題】通信の信頼性を向上させる。
【解決手段】トランスポート層としてＵＤＰを用いる通信において、ＲＴＰヘッダが付加されているものが授受される。受信機は、受信したＲＴＰヘッダ内のシークエンスナンバーを参照し、その番号の連続性を確認する。連続したシークエンスナンバーを含むデータが受信されなかったとき、データが欠落したと判断し、その欠落したと判断されるシークエンスナンバーのデータを再送するように、送信機に対して要求を出す。その要求に対応して、送信機が再送してきたデータを受信機が受信することにより、受信機は、欠落したデータを取得する。本発明は、データを送信する送信機と、データを受信する受信機に適用することができる。
【選択図】 図１１
【解決手段】トランスポート層としてＵＤＰを用いる通信において、ＲＴＰヘッダが付加されているものが授受される。受信機は、受信したＲＴＰヘッダ内のシークエンスナンバーを参照し、その番号の連続性を確認する。連続したシークエンスナンバーを含むデータが受信されなかったとき、データが欠落したと判断し、その欠落したと判断されるシークエンスナンバーのデータを再送するように、送信機に対して要求を出す。その要求に対応して、送信機が再送してきたデータを受信機が受信することにより、受信機は、欠落したデータを取得する。本発明は、データを送信する送信機と、データを受信する受信機に適用することができる。
【選択図】 図１１
Description
【０００１】
【発明の属する技術分野】
本発明は送受信システム、送信装置および方法、受信装置および方法、記録媒体、並びにプログラムに関し、特に、送受信されているパケットが欠落してしまったときに、その欠落を補う装置に用いて好適な送受信システム、送信装置および方法、受信装置および方法、記録媒体、並びにプログラムに関する。
【０００２】
【従来の技術】
ネットワークが普及し、そのネットワークを用いて提供されるサービスも、多岐にわたるようになってきている。ネットワーク自体の構成も、有線で構成されるものや、無線で構成されるものがある。
【０００３】
ネットワークが普及すると共に、そのネットワークにおける通信の信頼性を向上させるために、例えば、同一のデータを異なる経路で伝送するなどして、一方の経路で何らかの異常が発生しても、他方の経路で、通信を確保できるようにし、データの欠落などを防ぐ方法が提案されている。（例えば、特許文献１参照）
【０００４】
【特許文献１】
特開平１１−９８１６１号公報
【０００５】
【発明が解決しようとする課題】
近年では、家庭内におけるネットワークとして、有線によるものより、設置などが手軽な無線ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）が普及しつつある。しかしながら、無線ＬＡＮは、その特性から、有線ＬＡＮに比べて信頼性が劣るという問題があった。
【０００６】
例えば、無線ＬＡＮは、当然ながら、無線によりデータの送受信が行われるが、無線で行うために、通信を行っている送信機と受信機の間を人が横切ったり、湿度などの環境の変化により、その通信状態が悪化することが考えられる。通信状態が悪化したために、送受信（通信）すべきデータが通信の途中で欠落するなどの不都合が発生することが考えられる。
【０００７】
そのような不都合に対応するために、無線によるデータの送受信においては、再送制御が行われている。具体的には、送信側が送信したデータを受信した受信側は、受信したことを示すＡＣＫ（Ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ）信号を送信側に出すようにし、そのＡＣＫ信号を送信側が受信するまで、送信側は同一のデータを所定の回数だけ送信し続ける（再送し続ける）といったことが行われていた。
【０００８】
このような再送制御は、送信側で、受信側の状態をチェックし、再送を行っていることになる。送信側では、所定の回数だけ、同一のデータを再送し続けることにより、換言すれば、他のデータを送信せずに、同一のデータを送信し続けることにより、遅延が蓄積され、送信すべきデータを、送信すべきタイミングで送信できないといった問題が発生する可能性があった。
【０００９】
また、受信側では、送信側からのデータを正常に受信し、その結果としてＡＣＫ信号を送信したにもかかわらず、データを送信した送信側で、そのＡＣＫ信号を受信できなかったために、送信側では、再送の処理が実行されてしまうことも考えられる。このような再送は、送信側にとっては、無駄な送信の処理であるとともに、そのために、遅延などが発生するのは、通信の信頼性を低下させるといった問題があった。
【００１０】
また、受信側でも、正常に受信したデータが、再送されてくることになり、その再送されたデータも処理しなくてはならず、無駄な処理を繰り返すことになるという問題があった。
【００１１】
このような再送の制御（送信したデータが受信側で正常に受信されたか否かの確認）は、そのデータの送受信において、例えば、ＯＳＩ層モデルにおけるトランスポート層に属するＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）が用いられた場合には行われるが、同じく、ＯＳＩ層モデルにおけるトランスポート層に属するＵＤＰ（Ｕｓｅｒ Ｄａｔａｇｒａｍ Ｐｒｏｔｏｃｏｌ）が用いられた場合には行われない。
【００１２】
従って、ＵＤＰが用いられたデータの送受信においては、受信側が、受信できなかったデータがあっても、その受信できなかったデータを送信側から取得するといったことはできないといった問題があった。
【００１３】
本発明はこのような状況に鑑みてなされたものであり、受信側で、何らかの原因で、受信できなかったデータを、受信側からの再送要求によって送信側から取得できるようにすることを目的とする。
【００１４】
【課題を解決するための手段】
本発明の送受信システムの送信装置は、データを取得する取得手段と、取得手段により取得されたデータに、データの順序を示す情報を付加する付加手段と、付加手段により情報が付加されたデータを記憶する記憶手段と、付加手段により情報が付加されたデータを受信装置に送信する送信手段と、送信手段により送信されたデータの再送が、受信装置から要求された場合、その再送が要求されたデータを記憶手段から読み出し、送信手段に、読み出されたデータの再送を指示する再送手段とを備え、受信装置は、送信手段により送信されたデータを受信する受信手段と、受信手段により受信されたデータに含まれる情報を抽出し、その情報を用いて、データの欠落があるか否かを判断する判断手段と、判断手段により、データの欠落があると判断された場合、欠落していると判断されるデータを特定する特定手段と、特定手段により特定された欠落していると判断されるデータの再送を送信装置に要求する要求手段とを備えることを特徴とする。
【００１５】
本発明の送信装置は、データを取得する取得手段と、取得手段により取得されたデータに、データの順序を示す情報を付加する付加手段と、付加手段により情報が付加されたデータを記憶する記憶手段と、付加手段により情報が付加されたデータを送信する送信手段と、送信手段により送信されたデータの再送が、他の装置から要求された場合、その再送が要求されたデータを記憶手段から読み出し、送信手段に、読み出されたデータの再送を指示する再送手段とを備えることを特徴とする。
【００１６】
前記付加手段は、情報として、ＲＴＰに基づくヘッダを少なくとも付加し、記憶手段は、ＲＴＰのヘッダが付加されたデータを記憶するようにすることができる。
【００１７】
前記他の装置からのデータの再送の要求には、ＲＴＰに基づくヘッダに含まれるＳｅｑｕｅｎｃｅ Ｎｕｍｂｅｒの情報が含まれ、再送手段は、ヘッダに含まれるＳｅｑｕｅｎｃｅ Ｎｕｍｂｅｒの情報と一致するＳｅｑｕｅｎｃｅ Ｎｕｍｂｅｒを含むヘッダが付加されたデータを記憶手段から読み出すようにすることができる。
【００１８】
本発明の送信方法は、データの取得を制御する取得制御ステップと、取得制御ステップの処理で取得が制御されたデータに、データの順序を示す情報を付加する付加ステップと、付加ステップの処理で情報が付加されたデータの記憶を制御する記憶制御ステップと、付加ステップの処理で情報が付加されたデータの送信を制御する送信制御ステップと、送信制御ステップの処理で送信が制御されたデータの再送が、他の装置から要求された場合、その再送が要求されたデータを記憶制御ステップの処理で記憶が制御されたデータ内から読み出し、送信制御ステップの処理に、読み出されたデータの再送を指示する再送ステップとを含むことを特徴とする。
【００１９】
本発明の記録媒体のプログラムは、データの取得を制御する取得制御ステップと、取得制御ステップの処理で取得が制御されたデータに、データの順序を示す情報を付加する付加ステップと、付加ステップの処理で情報が付加されたデータの記憶を制御する記憶制御ステップと、付加ステップの処理で情報が付加されたデータの送信を制御する送信制御ステップと、送信制御ステップの処理で送信が制御されたデータの再送が、他の装置から要求された場合、その再送が要求されたデータを記憶制御ステップの処理で記憶が制御されたデータ内から読み出し、送信制御ステップの処理に、読み出されたデータの再送を指示する再送ステップとを含むことを特徴とする。
【００２０】
本発明のプログラムは、データの取得を制御する取得制御ステップと、取得制御ステップの処理で取得が制御されたデータに、データの順序を示す情報を付加する付加ステップと、付加ステップの処理で情報が付加されたデータの記憶を制御する記憶制御ステップと、付加ステップの処理で情報が付加されたデータの送信を制御する送信制御ステップと、送信制御ステップの処理で送信が制御されたデータの再送が、他の装置から要求された場合、その再送が要求されたデータを記憶制御ステップの処理で記憶が制御されたデータ内から読み出し、送信制御ステップの処理に、読み出されたデータの再送を指示する再送ステップとを含む処理をコンピュータに実行させることを特徴とする。
【００２１】
本発明の受信装置は、データを受信する受信手段と、受信手段により受信されたデータに含まれる所定の情報を抽出し、その情報を用いて、データの欠落があるか否かを判断する判断手段と、判断手段により、データの欠落があると判断された場合、欠落していると判断されるデータを特定する特定手段と、特定手段により特定された欠落していると判断されるデータの再送をデータを送信してきた他の装置に要求する要求手段とを備えることを特徴とする。
【００２２】
前記要求手段により要求が出されたときから計時を開始する計時手段と、計時手段による計時が、所定の時間を経過する毎に、再度要求を出すように要求手段に指示する指示手段とをさらに含むようにすることができる。
【００２３】
前記判断手段は、所定の情報としてデータに含まれるＲＴＰに基づくヘッダを抽出し、そのヘッダに含まれるＳｅｑｕｅｎｃｅ Ｎｕｍｂｅｒの情報を用いて、データの欠落があるか否かを判断することを特徴とする。
【００２４】
前記判断手段は、ヘッダに含まれていたＳｅｑｕｅｎｃｅ Ｎｕｍｂｅｒのうち、最も大きい番号の第１のＳｅｑｕｅｎｃｅ Ｎｕｍｂｅｒを記憶し、その記憶している第１のＳｅｑｕｅｎｃｅ Ｎｕｍｂｅｒと、新たに供給されたヘッダに含まれる第２のＳｅｑｕｅｎｃｅ Ｎｕｍｂｅｒが連続している番号ではなく、かつ、第１のＳｅｑｕｅｎｃｅ Ｎｕｍｂｅｒの方が第２のＳｅｑｕｅｎｃｅ Ｎｕｍｂｅｒより小さい番号であると判断したとき、データが欠落していると判断し、特定手段は、第１のＳｅｑｕｅｎｃｅ Ｎｕｍｂｅｒから第２のＳｅｑｕｅｎｃｅ Ｎｕｍｂｅｒまでに位置する番号の第３のＳｅｑｕｅｎｃｅ Ｎｕｍｂｅｒをヘッダに含むデータを、欠落していると判断されるデータであると特定し、要求手段は、欠落されていると判断されるデータの再送を、第３のＳｅｑｕｅｎｃｅ Ｎｕｍｂｅｒの情報を含むデータを他の装置に送信することにより要求するようにすることができる。
【００２５】
前記要求手段は、第３のＳｅｑｕｅｎｃｅ Ｎｕｍｂｅｒの情報を含むデータを、ＴＣＰに基づいて送信するようにすることができる。
【００２６】
前記判断手段は、第１のＳｅｑｕｅｎｃｅ Ｎｕｍｂｅｒと、第２のＳｅｑｕｅｎｃｅ Ｎｕｍｂｅｒが連続している番号ではなく、かつ、第１のＳｅｑｕｅｎｃｅ Ｎｕｍｂｅｒの方が第２のＳｅｑｕｅｎｃｅ Ｎｕｍｂｅｒより大きい番号であると判断したとき、その第２のＳｅｑｕｅｎｃｅ Ｎｕｍｂｅｒを含むデータは、再送されてきたデータであると判断するようにすることができる。
【００２７】
本発明の受信方法は、データの受信を制御する受信制御ステップと、受信制御ステップの処理で受信されたデータに含まれる所定の情報を抽出し、その情報を用いて、データの欠落があるか否かを判断する判断ステップと、判断ステップの処理により、データの欠落があると判断された場合、欠落していると判断されるデータを特定する特定ステップと、特定ステップの処理で特定された欠落していると判断されるデータの再送をデータを送信してきた他の装置に要求する要求ステップとを含むことを特徴とする。
【００２８】
本発明の記録媒体のプログラムは、データの受信を制御する受信制御ステップと、受信制御ステップの処理で受信されたデータに含まれる所定の情報を抽出し、その情報を用いて、データの欠落があるか否かを判断する判断ステップと、判断ステップの処理により、データの欠落があると判断された場合、欠落していると判断されるデータを特定する特定ステップと、特定ステップの処理で特定された欠落していると判断されるデータの再送をデータを送信してきた他の装置に要求する要求ステップとを含むことを特徴とする。
【００２９】
本発明のプログラムは、データの受信を制御する受信制御ステップと、受信制御ステップの処理で受信されたデータに含まれる所定の情報を抽出し、その情報を用いて、データの欠落があるか否かを判断する判断ステップと、判断ステップの処理により、データの欠落があると判断された場合、欠落していると判断されるデータを特定する特定ステップと、特定ステップの処理で特定された欠落していると判断されるデータの再送をデータを送信してきた他の装置に要求する要求ステップとを含む処理をコンピュータに実行させることを特徴とする。
【００３０】
本発明においては、データの送受信の過程で、受信装置が、データを受信できなかった場合、受信装置が、送信装置に対して欠落したデータの再送を要求する。
【００３１】
本発明においては、データを送信する側が、データを送信すると共に、そのデータを記憶し、受信する側から、既に送信したデータの再送が要求されたときには、その記憶されているデータが再送される。
【００３２】
本発明においては、データを受信する側が、欠落したデータがあると判断した場合、その欠落したデータを特定するための情報を、送信側に送信する。
【００３３】
【発明の実施の形態】
以下に、本発明の実施の形態について図面を参照して説明する。図１は、本発明を適用した送受信システムの一実施の形態の構成を示す図である。図１に示した送受信システムは、送信機１と受信機２から構成されている。送信機１は、アンテナ３により受信されたテレビジョン放送のデータを、受信機２に対して送信する。受信機２は、表示装置（例えば、ディスプレイ）や音声出力装置（例えば、スピーカ）を備えており、受信したデータに基づく画像や音声を出力するように構成されている。
【００３４】
ここでは、アナログ信号のテレビジョン放送が受信され、そのデータが、受信機２に送信されるとして説明するが、本発明は、アナログ信号のテレビジョン放送だけでなく、例えば、ＢＳ（Ｂｒｏａｄｃａｓｔｉｎｇ Ｓａｔｅｌｌｉｔｅ）放送、ＣＳ（Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ｓａｔｅｌｌｉｔｅ）放送、地上波デジタル放送などのデジタル信号のテレビジョン放送に対しても適用することが可能である。
【００３５】
また、例えば、ＶＴＲ（Ｖｉｄｅｏ Ｔａｐｅ Ｒｅｃｏｒｄｅｒ）やＤＶＤ（Ｄｉｇｉｔａｌ Ｖｅｒｓａｔｉｌｅ Ｄｉｓｃ）プレーヤなどが送信機１に接続され、それらの装置からのデータが、送受信されるようにしても良い。さらに、インターネットなどのネットワークに接続され、そのネットワークに接続されることにより得られる情報などの送受信が行われるようにしても良い。
【００３６】
送信機１と受信機２は、無線でデータの授受を行う。その無線による通信は、例えば、ＩＥＥＥ８０２．１１ａの規格に基づく方式で行われる。送信機１と受信機２は、無線によりデータの授受を行うため、例えば、ユーザは、送信機１を家の所定の場所に固定して設置し、受信機２を所望の場所まで持ち運び、その場所でテレビジョン放送を閲覧するといったことをできる。
【００３７】
図２は、送信機１の内部構成例を示す図である。図２に示した内部構成例は、主に、本発明にかかわり、説明に必要とされる部分を示し、説明に必要ない部分、例えば、受信したテレビジョン放送からユーザが指定した番組を抽出するチューナや、ＶＴＲやＤＶＤプレーヤなどを接続した際に、それらの装置からの入力を切り換えるスイッチャーなどは、省略してある。
【００３８】
送信機１は、アンテナ３により受信されたテレビジョン放送としてのデータ（信号）を入力する。入力される信号は、例えば、アナログ信号である。そのアナログ信号は、ＭＰＥＧ（Ｍｏｖｉｎｇ Ｐｉｃｔｕｒｅ Ｅｘｐｅｒｔｓ Ｇｒｏｕｐ）エンコーダ２１に入力される。ＭＰＥＧエンコーダ２１は、入力されたアナログ信号を、ＭＰＥＧ方式に基づく圧縮を施したデジタルデータに変換する。
【００３９】
なお、デジタル信号のテレビジョン放送のデータなどが入力される場合、ＭＰＥＧエンコーダ２１によりエンコードされる必要はないので、必ずしも、入力されたデータが、ＭＰＥＧエンコーダ２１を介する構成とされる必要はなく、適宜、入力されるデータにより、入力される部分が異なるようにしても良い。勿論、そのような入力されたデータの出力先を選択するためのスイッチャーなどが、図示はしないが、送信機１には備え付けられている。
【００４０】
ＭＰＥＧエンコーダ２１からの出力（トランスポートストリームパケット：以下、適宜、ＴＳパケットと記述する）は、ＲＴＰ（Ｒｅａｌ Ｔｉｍｅ Ｐｒｏｔｏｃｏｌ）ヘッダ付加部２２に供給される。ＲＴＰヘッダ付加部２２は、供給されたＴＳパケットを所定の個数、例えば、７個のパケットをまとめ、そのまとめたパケットにＲＴＰヘッダを付加し、ＵＤＰ（Ｕｓｅｒ Ｄａｔａｇｒａｍ Ｐｒｏｔｏｃｏｌ）付加部２３に供給する。ＲＴＰヘッダ付加部２２によりＲＴＰヘッダを付加されたＴＳパケットを、適宜、ＲＴＰパケットと記述する。
【００４１】
ＵＤＰヘッダ付加部２３は、供給されたＲＴＰパケットに対して、さらに、ＵＤＰヘッダを付加して、ＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）ヘッダ付加部２４に供給する。ＵＤＰヘッダ付加部２３によりＵＤＰヘッダを付加されたＲＴＰパケットを、適宜、ＵＤＰパケットと記述する。
【００４２】
ＩＰヘッダ付加部２４は、供給されたＵＤＰパケットに対して、ＩＰヘッダを付加し、ＭＡＣ（Ｍｅｄｉａ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ）ヘッダ付加部２５に供給する。ＩＰヘッダ付加部２４によりＩＰヘッダを付加されたＵＤＰパケットを、適宜、ＩＰパケットと記述する。
【００４３】
ＭＡＣヘッダ付加部２５は、供給されたＩＰパケットに対して、ＭＡＣヘッダを付加し、通信部２６に供給する。ＭＡＣヘッダ付加部２５によりＭＡＣヘッダを付加されたＩＰパケットを、適宜、ＭＡＣパケットと記述する。
【００４４】
各部で、ヘッダを付加され、ＭＡＣパケットとされたＴＳパケットは、通信部２６により、受信機２に対して送信される。通信部２６は、受信機２に対してＭＡＣパケット（データ）を送信するだけでなく、受信機２からのデータも受信する。受信機２からのデータとしては、後述するように、受信機２側でデータを受信できなかった場合に出力される再送要求のデータがある。そのような再送要求のデータが受信された場合、そのデータは、再送制御部２７に供給される。
【００４５】
再送制御部２７は、供給されたデータに基づき、再送要求のあったデータを特定し、その特定したデータが、記憶部２８から、ＵＤＰヘッダ付加部２３に供給されるように制御する。記憶部２８には、このように、再送の指示がされたときのためのデータが記憶されている。記憶部２８には、ＲＴＰヘッダ付加部２２によりＲＴＰヘッダが付加されているＲＴＰパケットが記憶される。
【００４６】
図３は、ＭＰＥＧエンコーダ２１乃至ＭＡＣヘッダ付加部２５の各部が、処理を行うことにより、通信部２６に供給されるデータ（ＭＡＣパケット）を示す図である。図３に示すように、通信部２６に供給されるデータは、ＭＰＥＧエンコーダ２１によりエンコードされたＴＳパケット４１を含む。上述したように、通信部２６に供給されるＭＡＣパケット内のＴＳパケット４１には、ＴＳパケット４１−１乃至４１−７の７個のパケットが含まれている。１つのＴＳパケットは、１８８Ｂｙｔｅｓで構成されている。
【００４７】
１つのＴＳパケット４１（例えばＴＳパケット４１−１）は、ヘッダ部５１とデータ部５２から構成されている。ヘッダ部５１は、図４に示すデータを含み、データ部５２は、受信機２（図１）側で、画像または音声としてユーザに提供するためのビデオデータまたはオーディオデータを含む。
【００４８】
図４は、ＴＳパケット４１のヘッダ部５１のデータ構成を示す図である。ヘッダ部５１は、４Ｂｙｔｅｓで構成され、データ部５２は、１８４Ｂｙｔｅｓで構成される。ヘッダ部５１の“同期バイト”は、同期を取るために設けられており、固定値で、例えば、４７ｈが設定されている。“Ｅｒｒｏｒ Ｆｌａｇ”は、ＴＳパケット４１の中に訂正できないｂｉｔ ｅｒｒｏｒがあるか否かを示すフラグである。
【００４９】
“Ｓｔａｒｔ Ｆｌａｇ”は、新しいＰＥＳ Ｐａｃｋｅｔあるいは新しいＴＳ−ＰＳＩ Ｓｅｃｔｉｏｎであることを示すフラグである。“Ｐｒｉｏｒｉｔｙ Ｆｌａｇ”は、パケットの優先度を示すフラグであり、このフラグ（ｂｉｔ）が、１に設定されていると、他のＴＳパケット４１より重要度が高いことを示す。“ＰＩＤ”は、ＴＳパケット４１のＰａｙｌｏａｄ部分（データ部５２）が、ビデオデータであるか、オーディオデータであるか、あるいは、ＴＳ−ＰＳＩ（ＴＳ−Ｐｒｏｇｒａｍ Ｓｐｅｃｉｆｉｃ Ｉｎｆｏｒｍａｔｉｏｎ）であるかを、それぞれを区別するために付与される、１３ｂｉｔで構成される数値（Ｉｄｅｎｔｉｆｉｅｒ）である。
【００５０】
“Ｓｃｒａｍｂｌｉｎｇ ｍｏｄｅ”は、データ部５２のＳｃｒａｍｂｌｉｎｇ ｍｏｄｅ（スクランブルモード）を示す情報である。“Ａｄａｐｔａｔｉｏｎ Ｆｉｅｌｄ ｆｌａｇ”は、ＰＣＲ（Ｐｒｏｇｒａｍ Ｃｌｏｃｋ Ｒｅｆｅｒｅｎｃｅ）などの情報が含まれているＡｄａｐｔａｔｉｏｎ Ｆｉｅｌｄの有無を示す情報である。“Ｃｏｎｔｉｎｕｉｔｙ Ｃｏｕｎｔｅｒ”は、同じＰＩＤを持つパケットで、１ずつ値が増加されるカウンタ値の情報である。
【００５１】
ＭＰＥＧエンコーダ２１（図２）では、入力されたアナログ信号をデジタルデータに変換し、ＭＰＥＧ方式の圧縮を施してデータ部５２を生成すると共に、図４に示したようなヘッダ部５１を生成し、１つのＴＳパケット４１を生成する。
【００５２】
このようなＴＳパケット４１が、この場合、７個含まれるのが、図３に示したＴＳパケット４１である。ＲＴＰヘッダ４２（図３）は、ＲＴＰヘッダ付加部２２（図２）により付加されるヘッダであるが、そのデータ構成は、図５に示すように構成されている。
【００５３】
ＲＴＰヘッダ４２の“Ｖ”は、Ｖｅｒｓｉｏｎ Ｂｉｔを示し、ＲＴＰヘッダ４２のフォーマットのバージョンを示すバージョン番号の情報である。“Ｐ”は、Ｐａｄｄｉｎｇ Ｂｉｔを示し、パケットのサイズを調整するビットである。“Ｘ”は、Ｅｘｔｅｎｓｉｏｎ Ｂｉｔを示し、機能拡張時に指定される拡張ビットである。
【００５４】
“ＣＣ”は、ＣＳＲＣ Ｃｏｕｎｔを示し、リアルタイム転送に関わる送信元の数を示すカウンタの情報である。“Ｍ”は、Ｍａｒｋｅｒ Ｂｉｔを示し、１パケットにおけるフレームの境界を示すマーカービットである。“ＰＴ”は、Ｐａｙｌｏａｄ Ｔｙｐｅを示し、ペイロードの符号化の種類を示す情報である。“Ｓｅｑｕｅｎｃｅ Ｎｕｍｂｅｒ”は、ＲＴＰパケットの順番を示すシーケンス番号を示す情報である。
【００５５】
“ＴＩＭＥ ＳＴＡＭＰ”は、ＲＴＰヘッダ４２が作成された時刻を示すタイムスタンプの情報を示す。“ＳＳＲＣ”は、Ｓｙｎｃｈｒｏｎｉｚａｔｉｏｎ Ｓｏｕｒｃｅを示し、メッセージの最初の送信元（ソース）を識別する同期ソース識別子の情報である。“ＣＳＲＣ”は、Ｃｏｎｔｒｉｂｕｔｉｎｇ Ｓｏｕｒｃｅを示し、メッセージに含まれるパケット群の送信先（クライアント）を識別する貢献ソース識別子の情報である。
【００５６】
このような情報を含むＲＴＰヘッダ４２に対応するペイロード（Ｐａｙｌｏａｄ）に、ＴＳパケット４１が挿入される。ＲＴＰヘッダ４２が付加されているＲＴＰパケットにＵＤＰヘッダ４３（図３）が、ＵＤＰヘッダ付加部２３（図２）により付加される。
【００５７】
図６は、ＵＤＰヘッダ４３のデータ構成を示す図である。ＵＤＰヘッダ４３の“ＳＲＣ ＰＯＲＴ”は、送信元のポート番号を指定する情報であり、“ＤＥＳＴ ＰＯＲＴ）は、送信先（宛先）のポート番号を指定する情報であり、共に、サービスを特定するための情報として用いられる。
【００５８】
“Ｌｅｎｇｔｈ”は、ＵＤＰヘッダ４３とその後に続くデータの長さ（バイト単位）の合計を示す情報である。“Ｃｈｅｃｋｓｕｍ”は、ＵＤＰヘッダの情報と、データ長を元にして算出された値の情報である。受信側では、送信側と同様の計算を行い、Ｃｈｅｃｋｓｕｍ（チェックサム）の値を算出し、その算出した値と、送信されてきたＵＤＰヘッダ４３に含まれるチェックサムの値が一致しているか否かを判断することで、途中で、パケットが壊れていないか否かを判断する。
【００５９】
このようなＵＤＰヘッダ４３が付加されたＵＤＰパケットに、ＩＰヘッダ４４（図３）が、ＩＰヘッダ付加部２４（図２）により付加される。図７は、ＩＰヘッダ４４のデータ構成を示す図である。図７に示したＩＰヘッダ４４のデータ構成は、基本ヘッダの部分だけを示し、オプションヘッダについては図示していない。
【００６０】
“Ｖｅｒ”は、インターネットプロトコル（ＩＰ）のバージョンを示す情報である。“ＩＨＬ”は、Ｉｎｔｅｒｎｅｔ Ｈｅａｄｅｒ Ｌｅｎｇｔｈを示し、このヘッダの長さを示す情報である。“ＴＯＳ”は、Ｔｙｐｅ Ｏｆ Ｓｅｒｖｉｃｅを示し、データの優先度の定義や、どのようなタイプの転送を行うかなどを指定する情報である。
【００６１】
“ＴＬ”は、Ｔｏｔａｌ Ｌｅｎｇｔｈを示し、ＩＰヘッダ４４と、ＩＰヘッダ４４以降のデータの合計の長さを示す情報である。“ＩＤ”は、このＩＰヘッダ４４で示されるＩＰパケットを識別するための情報である。“ＦＬ”は、ＩＰ層でデータを分割（フラグメント）した際の、その制御に関する情報である。
【００６２】
“ＦＯ”は、ＩＰ層でデータが分割された際のデータが、どこにあったかを示す情報である。“ＴＴＬ”は、Ｔｉｍｅ Ｔｏ Ｌｉｖｅを示し、このＩＰヘッダ４４を含むデータが、いつ破棄されるのかを示す情報である。“ＰＲＯＴ”は、ＩＰ層より上の層で用いられているプロトコルを示す情報である。
【００６３】
“ＨＣ”は、ＩＰヘッダ４４が送信中に壊れていないか否かを、受信側で確認するためのチェックサムの情報である。“ＳＡ”は、データの送信元のＩＰアドレスを示す情報である。“ＤＡ”は、データの送信先のＩＰアドレスを示す情報である。
【００６４】
このようなＩＰヘッダ４４が付加されたＩＰパケットに、ＭＡＣヘッダ４５（図３）が、ＭＡＣヘッダ付加部２５（図２）により付加される。図８は、ＭＡＣヘッダ４５のデータ構成を示す図である。
【００６５】
“ＰＡ”は、プリアンブルであり、クロックリカバリのためのＰＬＬをロックするさせるための情報である。“ＤＡ”は、送信先のＭＡＣアドレスを示す情報である。“ＳＡ”は、送信元のＭＡＣアドレスを示す情報である。“Ｔｙｐｅ”は、上位層のプロトコルを示し情報である。
【００６６】
“Ｌｅｎｇｔｈ”は、ペイロードのデータのバイト数を示す情報である。１つのＭＡＣヘッダ４５には、“Ｔｙｐｅ”または“Ｌｅｎｇｔｈ”のどちらか一方の情報が書き込まれる。“ＦＣＳ”は、エラーチェックのための情報である。
【００６７】
このような情報を含むＭＡＣヘッダ４５が付加されることにより、図３に示したようなデータ（ＭＡＣパケット）が生成される。
【００６８】
ここでは、図３に示した構成のデータが、送信機１から送信されるとして説明するが、ＲＴＰヘッダ４２が付加されていない構成のデータでも、受信機２側にデータを送信することは可能である。しかしながら、図３に示したように、本実施の形態においては、ＲＴＰヘッダ４２が付加されたデータを送信するようにする。
【００６９】
このように、ＲＴＰヘッダ４２が付加されたデータが送信されるようにするのは、詳細は後述するが、受信機２側で、送信機１から送信されたデータを、何らかの原因により、受信できなかったときに、ＲＴＰヘッダ４２内の情報（具体的には、図５に示した“Ｓｅｑｕｅｎｃｅ Ｎｕｍｂｅｒ”）が用いられるからである。
【００７０】
ＵＤＰヘッダ４３は、ＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）ヘッダに置き換えることが可能である（ＴＣＰヘッダにしても良い）。しかしながら、本実施の形態においては、図３に示したように、ＵＤＰヘッダ４３を用いる。
【００７１】
このように、ＴＣＰヘッダを付加するのではなく、ＵＤＰヘッダを付加するようにするのは、以下の理由からである。ＴＣＰヘッダは、トランスポート層のプロトコルとして、ＴＣＰが用いられたときに付加されるヘッダであり、ＵＤＰヘッダは、トランスポート層のプロトコルとして、ＵＤＰが用いられたときに付加されるヘッダである。
【００７２】
トランスポート層のプロトコルとして、ＴＣＰを用いるか、または、ＵＤＰを用いるかを決定する要因の１つとして、そのプロトコルを用いて行われる通信ではどのようなデータが送受信されるのかという要因がある。ＴＣＰは、コネクション型のプロトコルと称され、ＵＤＰはコネクションレス型のプロトコルと称されることがある。
【００７３】
ＴＣＰは、コネクション型のプロトコルであるので、データの授受にかかわる処理手順が複雑になるが、通信にかかわる信頼度は向上する。従って、主に、信頼度を優先させる通信に用いられる。ＴＣＰに対し、ＵＤＰは、コネクションレス型のプロトコルであるので、データの授受にかかわる処理手順は簡素化されているが、通信にかかる処理時間は短くなるため、処理速度を優先させる通信に用いられる。
【００７４】
本実施の形態においては、上述したように、送信機１が受信したテレビジョン放送のデータを、受信機２側に送信するので、その送信機１と受信機２との間のデータの授受にかかわるプロトコルは、信頼度より処理速度を優先させ、リアルタイムに処理できるようにした方が良いため、ＵＤＰを用いる。
【００７５】
しかしながらＵＤＰを用いて通信を行うと、送信機１が送信したデータが、何らかの原因で、受信機２側で受信されてなくても、送信機１側は、そのような状況に関係なく、データを順次送信し続ける。従って、受信機２側では、欠落したデータを取得することができない。受信機２が、欠落したデータを取得することなく、欠落したまま処理を続けると、ユーザに提供される映像や音声がとぎれたり、乱れたりする。そのようなことは、できる限り発生しない方が好ましい。
【００７６】
そこで、本実施の形態においては、ＵＤＰを用いた通信においても、何らかの原因で、受信側でデータを受信できなかったとき、すなわち、データの欠落が生じたとき、その欠落したデータを受信側で取得できるようにする。そのような機能を有する受信機２について説明する。
【００７７】
図９は、受信機２の内部構成例を示す図である。受信機２の通信部６１は、送信機１からのデータを受信すると共に、送信機１に対して所定のデータを送信する。通信部６１により受信された送信機１からの、図３に示したような構成のデータは、ＭＡＣヘッダ抽出部６２に供給される。ＭＡＣヘッダ抽出部６２は、供給されたデータ（ＭＡＣパケット）から、ＭＡＣヘッダ４５（図３）を抽出（除去）し、ＩＰパケットをＩＰヘッダ抽出部６３に供給する。
【００７８】
ＩＰヘッダ抽出部６３は、供給されたＩＰパケットからＩＰヘッダ４４を抽出し、ＵＤＰパケットをＵＤＰヘッダ抽出部６４に供給する。ＵＤＰヘッダ抽出部６３は、供給されたＵＤＰパケットからＵＤＰヘッダ４３を抽出し、ＲＴＰパケットをナンバーチェック部６５に供給する。
【００７９】
ナンバーチェック部６５は、ＲＴＰヘッダ４２に含まれる“Ｓｅｑｕｅｎｃｅ Ｎｕｍｂｅｒ”（図５）（以下、適宜、シークエンスナンバーと記述する）を参照し、そのシークエンスナンバーをチェックする。シークエンスナンバーは、送信機１側で、処理された順（生成されたＲＴＰヘッダ４２順）に、通常、昇順に割り振られる連続した番号である。なおここでは、昇順に割り振られるとして説明をするが、降順に割り振られるようにしても良い。
【００８０】
ナンバーチェック部６５は、チェックしたシークエンスナンバーが連続した番号である場合、供給されたＲＴＰパケットを、順序構成部６６に供給し、チェックした番号が連続でない場合、供給されたＲＴＰパケットを、順序構成部６６に供給すると共に、再送制御部７０に対して、欠落したデータの再送を要求するように指示を出す。再送制御部７０は、所定のＲＴＰパケットを含むパケットの再送を要求する指示を受けた場合、通信部６１に対して、再送の要求を示すデータを送信機１に対して送信させる。
【００８１】
一方、順序構成部６６は、供給されたＲＴＰパケットのシークエンスナンバーを参照し、そのシークエンスナンバーと同一の番号を持つデータ（対応するデータ）が記憶部６８に記憶されているか否かを判断し、記憶されていると判断した場合、その供給されたＲＴＰパケットを破棄し、記憶されていないと判断した場合、その供給されたＲＴＰパケットをＲＴＰヘッダ抽出部６７に供給する。
【００８２】
ＲＴＰヘッダ抽出部６７は、供給されたＲＴＰパケットから、ＲＴＰヘッダ４２を抽出し、ＴＳパケット４１を、記憶部６８に記憶させる。記憶部６８には、このようにして、ＴＳパケット４１が記憶されるが、そのＴＳパケット４１は、ＲＴＰヘッダ４２内のデータとしてのシークエンスナンバーと関連付けられて記憶される。
【００８３】
記憶部６８は、バッファとしての役割を有し、順次記憶されているＴＳパケット４１を、ＭＰＥＧデコーダ６９に出力する。ＭＰＥＧデーコーダ６９は、順次、供給されたＴＳパケット４１に対し、ＭＰＥＧ方式に基づくデコードを施す。ＭＰＥＧデコーダ６９からの出力は、図示されていないディスプレイやスピーカに供給され、ユーザに映像や音声として提供される。
【００８４】
計時部７１は、計時する手段を有し、所定のタイミングで、記憶部６８に記憶されているＴＳパケット４１を監視する。計時部７１は、記憶部６８に、欠落しているＴＳパケット４１（データ）があると判断した場合、再送制御部７０に、その欠落しているＴＳパケット４１を再送する要求を出すように指示を出す。
【００８５】
ここで、記憶部６８に記憶されているデータについて説明する。図１０は、記憶部６８に記憶されているデータのデータ構成を説明するための図である。上述したように、記憶部６８には、ＲＴＰヘッダ４２内に含まれるシークエンスナンバーと、そのシークエンスナンバーのＲＴＰパケットに含まれているＴＳパケットが関連付けられて記憶されている。
【００８６】
なお、記憶部６８に記憶させるシークエンスナンバーは、シークエンスナンバーそのものでも良いし、シークエンスナンバーを一意に導き出せるデータでも良い。
【００８７】
例えば、図１０に示したように、シークエンスナンバー“１”には、ＴＳパケット１−１乃至１−７が関連付けられて記憶されている。これは、上述したように、本実施の形態においては、１つのＲＴＰパケット（受信機２側で受信されるＭＡＣパケット）には、７個のＴＳパケットを含むと設定しているからであり、例えば、８個のＴＳパケットを含むと設定されている場合には、シークエンスナンバー“１”には、ＴＳパケット１−１乃至１−８の８個のＴＳパケットが関連付けられて記憶されることになる。
【００８８】
図１０に示した例を再度参照するに、同じくシークエンスナンバー“２”には、同じく７個のＴＳパケット２−１乃至２−７が関連付けられている。しかしながら、シークエンスナンバー“３”の欄には、本来ならば、ＴＳパケット３−１乃至３−７が関連付けられて記憶されるが、図１０に示した例では、ＴＳパケットが記憶されていない。これに対し、シークエンスナンバー“４”には、ＴＳパケット４−１乃至４−７が関連付けられて記憶されている。
【００８９】
このように、記憶部６８には、正常に受信され処理されると、シークエンスナンバーと関連付けられてＴＳパケットが、所定の領域に記憶される。記憶部６８には、シークエンスナンバー順に、ＴＳパケットが所定の領域に記憶されるようになっている。一方、何らかの原因で、正常に受信が行われなかったシークエンスナンバーの領域（この場合、シークエンスナンバー“３”の領域）は、何も記憶されない状態とされる。
【００９０】
このように、記憶部６８には、ＴＳパケットが記憶されている領域を有するシークエンスナンバーと、ＴＳパケットが記憶されていない領域を有するシークエンスナンバーとが混在する。そこで、ＴＳパケットが記憶されているか否かを示すフラグを用いて、ＴＳパケットが記憶されている領域を有するシークエンスナンバーと、そうでないシークエンスナンバーとを区別できるようにしても良い。また、そのようなフラグを、後述する処理において用いるようにしても良い。
【００９１】
このように、記憶部６８に記憶されないＴＳパケットが存在しているとき、換言すれば、シークエンスナンバーが飛んでいるようなときには、ナンバーチェック部６５または計時部７１の処理により、その記憶されていないＴＳパケット（欠落しているＴＳパケット）の再送を要求するためのデータを出すように、再送制御部７０に指示が出される。
【００９２】
なお、付言するに、図９に示した受信機２の構成では、ナンバーチェック部６５が、供給されたＲＴＰヘッダ４２内のシークエンスナンバーが飛んでいるか否かを判断し、計時部７１が、記憶部６８を参照し、記憶部６８に記憶されていないＴＳパケットが存在しているか否かを判断し、順序再構成部６６が、記憶部６８に記憶されているＴＳパケットを参照して、シークエンスナンバー順に、ＴＳパケットが記憶されるように、ＴＳパケットの順序を再構成する。
【００９３】
このような指示が出される際の処理について、図１１と図１２のフローチャートを参照して説明する。ステップＳ１１において初期値が設定される。この初期値の設定の処理は、ナンバーチェック部６５において行われる。初期値の設定は、受信機２の電源がオンにされたときなどに行われる。すなわち、新たなデータを受信したと判断したとき（新たなＲＴＰパケットが供給されたと判断されたとき）に行われる。
【００９４】
新たなデータを受信したときとは、ＲＴＰヘッダ４２に含まれているシークエンスナンバー（Ｓｅｑｕｅｎｃｅ Ｎｕｍｂｅｒ）が、新たな番号になっていると判断されたときである。新たな番号になっているか否かの判断は、ナンバーチェック部６５が、自己が管理（記憶）しているシークエンスナンバー（番号）と、供給されたＲＴＰパケットに含まれるＲＴＰヘッダ４２内のシークエンスナンバーを比較することにより行われる。
【００９５】
このような比較、および、後述する処理を行うために、ナンバーチェック部６５は、常に、供給されたＲＴＰパケット内のＲＴＰヘッダ４２のシークエンスナンバー（番号）を記憶し、その記憶している番号を、ＲＴＰパケットが供給される毎に更新する。なお、この更新は、通常（初期値が設定されるとき以外のとき）は、記憶している番号より大きい番号のシークエンスナンバーであると判断されたときのみ行われる。そのため、常に、その時点で、最も大きい番号のシークエンスナンバーが記憶されていることになる。
【００９６】
しかしながら、初期値の設定のときには、そのような制限にかかわらず、設定が行われる。その設定は、ナンバーチェック部６５に管理されている番号と、供給されたＲＴＰヘッダ４２のシークエンスナンバーを比較し、その値の差が大きい（予め設定されている値以上の差がある）場合、新たなデータの受信が開始されたと判断し、管理されている番号が更新されることにより行われる。
【００９７】
なお、このような初期値の設定の処理は、通常のときでも行われる可能性がある。例えば、何らかの原因で、送信機１からのデータを比較的長時間、受信できなかったときなど、シークエンスナンバーの連続性がとぎれることになる。その結果、ナンバーチェック部６５に管理されている番号と、供給されたＲＴＰヘッダ４２のシークエンスナンバーとの差が大きくなり、初期値の設定と同様の処理が実行される可能性がある。
【００９８】
このようにして、初期値が設定された後は、通常の処理が実行される。通常の処理とは、ステップＳ１２以降の処理である。なお、図１１、図１２に示したフローチャートの処理は、データが受信される毎に、そのデータに対して行われるが、初期値の設定が行われた後には、ステップＳ１２以降の処理から行われれば良く、ステップＳ１１の処理を省略することが可能である。
【００９９】
初期値の設定が終了されると、ステップＳ１２において、受信されたＭＡＣパケット内に含まれるＲＴＰヘッダ４２のシークエンスナンバーは、連続しているか否かが判断される。この判断も、ナンバーチェック部６５において行われる。上述したように、ナンバーチェック部６５は、供給されたＲＴＰパケット内のＲＴＰヘッダ４２に含まれるシークエンスナンバーが、その時点で最も大きい番号を管理している。
【０１００】
基本的に、シークエンスナンバーは、送信機１のＲＴＰヘッダ付加部２２により、ＲＴＰヘッダ４２が生成された順に番号（通常、昇順）が割り振られ、その生成された順番で、通信部２６から出力される。よって、基本的に、受信機２のナンバーチェック部６５においても、順次、連続したシークエンスナンバーのＲＴＰパケットが供給される。ここで、“基本的に”と記述したのは、何らかの原因で、シークエンスナンバーの番号順に送信されない、または、受信されないことがあるからである。そのような状況が発生した場合に対しても、後述する処理により対応できるようになっている。
【０１０１】
図１１のフローチャートの説明に戻り、ステップＳ１２において、ナンバーチェック部６５は、受信した（供給された）ＲＴＰパケットのＲＴＰヘッダ４２内のシークエンスナンバーは、管理している番号に１だけ加算した値である（すなわち、連続している番号である）か否かを判断する。
【０１０２】
ステップＳ１２において、供給されたＲＴＰパケットのＲＴＰヘッダ４２内のシークエンスナンバーは、連続している番号であると判断された場合、ステップＳ１３に処理が進められる。ステップＳ１２において、このように判断されるのは、正常に送信機１からのデータが受信され、処理されているときである。従って、正常に受信され、処理されているデータ（ＴＳパケット）が記憶部６８に記憶される処理が、ステップＳ１３において実行される。
【０１０３】
ナンバーチェック部６５は、供給されたＲＴＰパケットのＲＴＰヘッダ４２内のシークエンスナンバーは、連続している番号であると判断した場合、そのＲＴＰパケットを、順番再構成部６６に供給する。順番再構成部６６は、ＲＴＰパケットが供給されたとき、そのＲＴＰパケットのＲＴＰヘッダ４２を参照し、シークエンスナンバーを読み出す。その読み出したシークエンスナンバーに対応するＴＳパケットが、記憶部６８に記憶されているか否かをチェックする。
【０１０４】
この場合、連続している番号であると判断されたＲＴＰパケットであり、このことを換言すれば、新たに受信されたＲＴＰパケットであると判断されたことになる。従って、順番再構成部６６は、供給されたＲＴＰパケット内のＴＳパケットは、記憶部６８に記憶されていないと判断する。このような判断がされたときには、ＲＴＰパケットが、ＲＴＰヘッダ抽出部６７に供給される。
【０１０５】
ＲＴＰヘッダ抽出部６７は、供給されたＲＴＰパケットからＲＴＰヘッダ４２を抽出し、ＴＳパケットを、記憶部６８に供給し、記憶させる。この際、上述したように、ＴＳパケットは、ＲＴＰヘッダ４２に含まれるシークエンスナンバーと関連付けられて記憶される。
【０１０６】
一方、ステップＳ１２において、ナンバーチェック部６５が、供給されたＲＴＰヘッダ４２内のシークエンスナンバーは、管理している番号に、連続する番号ではないと判断した場合、ステップＳ１４に処理が進められる。ステップＳ１４において、ナンバーチェック部６５は、供給されたＲＴＰパケットに含まれるＲＴＰヘッダ４２内のシークエンスナンバーは、管理している番号より大きい番号であるか否かを判断する。
【０１０７】
ステップＳ１４において、ナンバーチェック部６５が、供給されたＲＴＰパケットに含まれるＲＴＰヘッダ４２内のシークエンスナンバーは、管理している番号より大きい番号ではないと判断した場合、換言すれば、小さい番号であると判断した場合、ステップＳ１５に処理が進められる。
【０１０８】
上述したように、送信機２から送信されてきたデータは、基本的に、シークエンスナンバーの番号順に受信され、処理されるので、ステップＳ１４において、ナンバーチェック部６５が、供給されたＲＴＰパケットに含まれるＲＴＰヘッダ４２内のシークエンスナンバーは、管理している番号より大きい番号ではないと判断することはない。しかしながら、何らかの原因で、送信される順番または、受信され、処理される順番が入れ違ってしまったために、このように、ステップＳ１４においてＮＯと判断され、ステップＳ１５に処理が進められることが考えられる。
【０１０９】
また、後述するステップＳ１７の処理が行われた結果、送信機１側から、その時点で、送信すべきシークエンスナンバーのデータよりも、若い番号のシークエンスナンバーのデータが再送されることがある。そのような再送が行われた結果、番号の若いシークエンスナンバーのデータが受信機２に、正常に受信され、処理されると、ステップＳ１４において、ＮＯと判断され、ステップＳ１５において処理が進められる場合もある。
【０１１０】
ステップＳ１４において、ナンバーチェック部６５は、供給されたＲＴＰヘッダ４２内のシークエンスナンバーは、管理している番号より大きい番号ではないと判断した場合、供給されたＲＴＰパケットを、順序再構成部６６に供給する。順序再構成部６６は、ステップＳ１５において、供給されたＲＴＰパケットに含まれているＴＳパケットは、既に、記憶部６８に記憶されているか否かを、記憶部６８を参照することにより判断する。
【０１１１】
図１０を参照して説明したように、記憶部６８には、正常に処理されたＴＳパケットが、シークエンスナンバーと関連付けられて記憶されている。そこで、順序再構成部６６は、供給されたＲＴＰヘッダ４２内のシークエンスナンバーを読み出し、その読み出したシークエンスナンバーに関連付けられたＴＳパケットが、記憶部６８に記憶されているか否かを判断する。
【０１１２】
このような処理を設ける理由について、図１３を参照して説明する。図１３Ａは、正常に、送受信が行われている状態を示している。図１３Ａに示すように、正常に送受信が行われている状態では、シークエンスナンバーが連続しているパケット（データ）が送信機１から送信され、受信機２で受信され処理される。図１３Ａに示した状態は、シークエンスナンバーが“９７”乃至“１０２”のパケットが、その順番で、送受信されていることを意味する。
【０１１３】
このような正常に送受信が行われている状態に対し、何らかの原因で、正常に送受信が行われていない状態を図１３Ｂに示す。図１３Ｂにおいては、シークエンスナンバー“９７”の後に、シークエンスナンバー“９９”のパケットが受信されている。このような状態が発生したとき、すなわち、シークエンスナンバーが連続せず、かつ、番号が、大きい番号に飛んだとき、再送要求が出される。この再送要求については、ステップＳ１７の処理として後述する。
【０１１４】
その後、シークエンスナンバー“１００”のパケットが受信される。シークエンスナンバー“１００”のパケットの次は、シークエンスナンバー“１０１”のパケットが受信されるはずであるが、シークエンスナンバー“９８”のパケットが受信されている。このシークエンスナンバー“９８”のパケットは、上述した再送要求が出された結果、送信機１からシークエンスナンバー“９８”のパケットが再送信され、受信機２に受信されたパケットであるか、または、送信機１側または受信機２側で、何らかの原因により、処理の順序が入れ替わってしまったために、シークエンスナンバー“１００”のパケットの後に受信されたパケットである。
【０１１５】
いずれにせよ、この時点では、シークエンスナンバー“９８”のパケットは、受信機２側では、始めて受信され、処理されたことになるため、記憶部６８には記憶されていない。すなわち、ステップＳ１５において、順序再構成部６６の処理により、記憶部６８には記憶されていないと判断されることになる。
【０１１６】
図１３Ｂを再度参照するに、シークエンスナンバー“９８”のパケットが記憶部６８に記憶された後、シークエンスナンバー“１０１”のパケットが受信され、記憶され、さらに、その後、シークエンスナンバー“９８”のパケットが受信される。このときのシークエンスナンバー“９８”のパケットも、上述したように、再送要求の結果により受信されたパケット、または、処理の入れ替わりが発生した結果により受信されたパケットである。
【０１１７】
いずれにせよ、シークエンスナンバー“１０１”のパケットの後に処理されるシークエンスナンバー“９８”のパケットと同一のパケットは、既に、シークエンスナンバー“１００”のパケットの後に受信され、処理され、記憶部６８に記憶されている。従って、このような場合、ステップＳ１５において、順序再構成部６６により、記憶部６８に記憶されていると判断されることになる。
【０１１８】
このように、同じシークエンスナンバーのパケットが、受信機２に受信され、処理される可能性があるために、ステップＳ１５の処理が行われる。ステップＳ１５において、記憶部６８に記憶されていると判断されたパケットは、上述した例では、シークエンスナンバー“９８”のパケットは、再度、記憶部６８に記憶させる必要はないので、ステップＳ１６に処理が進められ破棄される。
【０１１９】
一方、記憶部６８に記憶されていないと判断されたパケットは、ステップＳ１３に処理が進められ記憶部６８に記憶される。記憶部６８にパケットが記憶される際、その領域は、予めそのパケットが記憶されるとして用意されていた領域（その時点で記憶されているシークエンスナンバーに対応する領域）に記憶される。換言すれば、後に受信されたパケットも、本来受信されるべきタイミングで受信されたかのように、順番が入れ替えられて、記憶部６８に記憶される。この記憶の制御は、順序再構成部６６により行われる。
【０１２０】
次に、再送要求について説明する。再送要求の処理は、ステップＳ１７（図１１）において行われるが、ステップＳ１７に処理が進められるのは、ステップＳ１２において、ナンバーチェック部６５により、供給されたＲＴＰパケットのＲＴＰヘッダ４２に含まれるシークエンスナンバーは、管理している番号に連続する番号ではないと判断され、かつ、ステップＳ１４において、そのシークエンスナンバーは、管理している番号より大きい番号であると判断されたときである。
【０１２１】
図１３Ｂを再度参照するに、ナンバーチェック部６５に、シークエンスナンバー“９７”のＲＴＰパケットが供給された後に、シークエンスナンバー“９９”のＲＴＰパケットが供給された場合、このような判断が行われ、ステップＳ１７に処理が進められる。このような状況は、供給されるべきシークエンスナンバー“９８”のＲＴＰパケットが、供給されなかった（欠落した）状況を示している。
【０１２２】
ステップＳ１７において、再送要求の処理が実行される。ステップＳ１７において行われる再送要求の処理について、図１２のフローチャートを参照して説明する。この再送要求の処理とは、供給されるべきシークエンスナンバーのＲＴＰパケット、すなわち、欠落したと判断されるＲＴＰパケットを取得するために、送信機１に対して、その欠落していると判断されるＲＴＰパケットを再送するように要求を出す処理である。
【０１２３】
ナンバーチェック部６５は、ステップＳ３１において、欠落していると判断した番号を判断し、その判断した番号に関するデータを、ステップＳ３２の処理として、再送制御部７０に通知する。換言すると、ナンバーチェック部６５は、管理している番号から、供給されたＲＴＰパケットのシークエンスナンバーまでの番号を、欠落しているパケットの番号（シークエンスナンバー）として決定し、その決定した番号に関するデータを、再送制御部７０に通知する。
【０１２４】
例えば、図１３Ｂに示したような状況の場合、シークエンスナンバー“９８”が、欠落している番号として再送制御部７０に通知される。また、図示はしないが、例えば、管理している番号が“９７”で、供給されたＲＴＰパケットのシークエンスナンバーが“１２０”であるような場合、“９８”乃至“１１９”が、欠落している番号として再送制御部７０に通知される。すなわち、再送制御部７０に通知される番号は、１つとは限らない。
【０１２５】
再送制御部７０は、ナンバーチェック部６５からのデータを入力すると、ステップＳ３３において、計時部７１に計時を開始させる。再送制御部７０は、計時部７１に計時を開始させる際、欠落していると判断された番号に関するデータも供給する。そして、再送制御部７０は、ステップＳ３４において、送信機１に対して再送を要求するデータを、通信部６１により送信させる。
【０１２６】
通信部６１により送信される、再送を要求するデータについて説明する。このデータは、トランスポート層のプロトコルとして、ＴＣＰが用いられたパケットとして送信される。上述したように、送信機１から、図３に示したようなデータ（ＭＡＣパケット）が送信される際には、トランスポート層のプロトコルとしてＵＤＰが用いられたが、受信機２から送信される再送を要求するデータとしてのパケットは、ＴＣＰが用いられたものとされる。
【０１２７】
これは、確実に再送要求を、送信機１側に送信させるようにするためである。勿論、ＵＤＰを用いて再送要求を出すようにしても良いが、その再送要求自体が、確実に送信機１側に送信されたか否かを判断できない状況は好ましくない状況であると考えられる。そこで、本実施の形態においては、再送要求は、ＵＤＰではなく、ＴＣＰが用いられるとして説明する。
【０１２８】
ＴＣＰを用いて送信される再送要求のデータには、ステップＳ３１、ステップＳ３２の処理において、欠落した番号として判断された番号のデータとして、再送制御部７０に通知されたデータが少なくとも含まれる。
【０１２９】
このような再送要求のデータが送信機１に対して送信されると、ステップＳ１８（図１１）に処理が進められる。ステップＳ１８において、計時部７１は、所定の時間が経過したか否かを判断する。計時部７１は、上述したように、再送制御部７０の指示により、送信機１に対して送信要求が出された時点から、計時を開始している。
【０１３０】
その計時している時間が、一定の値になったか否かが、ステップＳ１８において判断される。ステップＳ１８において一定の時間が経過したと判断されると、ステップＳ１９に処理が進められる。ステップＳ１９において、計時部７１は、再送制御部７０から供給された欠落していると判断された番号に関するデータを参照し、その番号（シークエンスナンバー）に関連付けられて、ＴＳパケットが、記憶部６８に記憶されているか否かを判断する。
【０１３１】
ステップＳ１９において行われる判断について説明する。図１１と図１２に示したフローチャートを参照して説明している処理は、受信機２により受信されたデータ（ＭＡＣパケット）毎に行われている。従って、ステップＳ１８において、所定の時間が経過したか否かの判断が行われるが、その所定の時間が経過する間にも、受信機２には、パケットが順次受信され、図１１と図１２に示したフローチャートの処理が、その受信されたパケット毎に行われている。
【０１３２】
その順次受信され、処理されるパケット内には、ステップＳ１７の処理により出された再送要求に対応する処理として、送信機１が再送してきたパケットも含まれる可能性がある。再送が正常に行われ、正常に受信、処理されれば、記憶部６８に、その再送されてきたＴＳパケットが記憶されることになる。そこで、ステップＳ１９においては、そのように、再送要求に対応して再送されてきたＴＳパケットが、記憶部６８に記憶されているか否かが判断される。
【０１３３】
ステップＳ１９において、計時部７１が、記憶部６８には、再送されてきたＴＳパケットは記憶されていないと判断した場合、ステップＳ１７に処理が戻され、再度、再送要求が出される。この際、再送要求が出されるのは、記憶されていないＴＳパケットに対してのみである。
【０１３４】
すなわち、例えば、欠落していると判断されたパケットのシークエンスナンバーが、“１００”乃至“１２０”であり、その“１００”乃至“１２０”に対するパケットの再送要求が出された結果、ステップＳ１９の処理が実行される時点で、“１００”乃至“１１０”に対応するＴＳパケットが記憶部６８に記憶されているような場合には、“１１１”乃至“１２０”に対応するＴＳパケットの再送を要求する再送要求が、再度出される。
【０１３５】
このように、再送要求自体を、繰り返し出すようにすることにより、より確実に、欠落したパケット（データ）を取得できるようにする。
【０１３６】
ここで、図１１に示していないが、ステップＳ１９の処理の前または後に、ステップＳ１９の処理を打ち切るような判断の処理を入れる必要がある。ステップＳ１９において、再送要求したＴＳパケットが記憶部６８に記憶されていると判断されるまで、再送要求が繰り返し出される一方で、記憶部６８に記憶されているＴＳパケットは、順次、ＭＰＥＧデコーダ６９に供給される。
【０１３７】
図１０を再度参照するに、シークエンスナンバー“１”に関連付けられているＴＳパケット１−１乃至１−７が、ＭＰＥＧデコーダ６９に供給された後に、シークエンスナンバー“２”に関連付けられているＴＳパケット２−１乃至２−７がＭＰＥＧデコーダ６９に供給される。
【０１３８】
その後、シークエンスナンバー“３”に関連付けられているＴＳパケットが、ＭＰＥＧデコーダ６９に供給されるが、供給される時点で、記憶されていなければ、供給することができず、そのシークエンスナンバー“３”に関連付けられているＴＳパケットが供給されることなく、次のシークエンスナンバー“４”に関連付けられているＴＳパケット４−１乃至４−７が供給される。
【０１３９】
このようなことを換言すれば、シークエンスナンバー“４”に関連付けられているＴＳパケットがＭＰＥＧデコーダ６９に供給されるより前の時点までに、シークエンスナンバー“３”に関連付けられるＴＳパケットが、記憶部６８に記憶されなければ、その後の時点で、シークエンスナンバー“３”に関連付けられるＴＳパケットを取得する必要はなく、そのための処理も行われる必要はない。
【０１４０】
このようなことを考慮すれば、計時部７１により出される再送要求の処理は、欠落していると判断されているパケットを取得するまで繰り返えされる必要性はない。そこで、ステップＳ１９の前の処理として、例えば、所定の回数だけ、再送要求が出されたか否かを判断する処理を設ける。そして、所定の回数だけ、再送要求が出されたと判断された場合には、ステップＳ１９の処理を省略し、図１１，１２に示したフローチャートの処理を終了させる。すなわち、再送要求を出すという処理が中断される。
【０１４１】
または、ステップＳ１９の後に、所定の回数だけ、再送要求が出されたか否かの判断をする処理を設けても良い。ステップＳ１９の後に、そのような処理を設けたとしても、基本的に、上述した、ステップＳ１９の前に設けた場合と同様にして、再送要求を出すという処理が中断される。
【０１４２】
所定の回数の決定の仕方だが、記憶部６８の容量に基づいて決定される。例えば、記憶部６８には、１秒間分のデータが記憶できるだけの容量があり、ステップＳ１８における処理で用いられる所定の時間として１００ミリ秒と計時部７１に設定されている場合、１秒間の間に、１０回、ステップＳ１８の処理が行われることになる。
【０１４３】
よって、この場合、再送要求を中断するための判断が、ステップＳ１９の前に行われる場合、または、ステップＳ１９の後に行われる場合（ステップＳ１９でＮＯと判断された後に行われる場合）、その判断は、“１０回目の再送要求か？”といった判断となる。
【０１４４】
すなわち、１０回目の再送要求を出したとしても、その１０回目の再送要求に対応する処理として、データが受信されたとしても、既に、そのデータを必要とする処理は、そのデータがない状態のまま、ＭＰＥＧデコーダ６９で行われているため、１０回目の再送要求を出すのは無駄な処理となってしまう。よって、この場合、１０回目の再送要求が出されることなく、再送要求が中断されるような判断が、行われるようにすればよい。
【０１４５】
このように、再送要求を中断させるための判断として、再送要求を出した回数により制限をかけることも可能であるが、時間により制限をかけるようにしても良い。例えば、記憶部６８の記憶容量が、１秒間分のデータを記憶できるだけの容量である場合、計時部７１が計時を開始してから、１秒以上経過した後に出される再送要求は、実質的に、無駄な処理となることになる。
【０１４６】
そこで、計時部７１が、計時を開始してから所定の時間（この場合、１秒）だけ経過したか否かを、例えば、ステップＳ１８の処理とあわせて判断するようにし、時間により、再送要求を中断させるための判断を行うようにしても良い。
【０１４７】
なお、上述した実施の形態においては、計時部７１は、再送制御部７０からの指示があると計時を開始し、所定の時間が経過後、再送要求したＴＳパケットが記憶部６８に記憶されていなければ、再度、再送要求を出すとしたが、計時部７１は、再送制御部７０からの指示にかかわらず、計時を行うようにしても良い。
【０１４８】
計時部７１が、常に計時を行うようにした場合、所定の周期毎（例えば、１００ミリ秒毎）に、記憶部６８を参照し、シークエンスナンバーは記憶されているが、そのシークエンスナンバーに関連付けられてＴＳパケットは記憶されていないと判断されるシークエンスナンバーを抽出するようにする。そして、抽出されたシークエンスナンバーのデータが再送制御部７０に供給されると共に、再送要求を出すように指示が出されるようにしても良い。
【０１４９】
このようにして、受信機２側で、欠落しているパケット（データ）を判断し、その欠落しているパケットを取得するために、その欠落しているパケットを再度送信するように再送要求が、送信機１側に出される。このような再送要求が出されることにより、何らかの原因で、受信機２側がパケットを受信（処理）できなかったとしても、その欠落したパケットを取得することが可能となる。
【０１５０】
また、欠落したパケットを受信機２側で判断することにより、送信機１側で、欠落したパケットを判断するより（例えば、ＡＣＫ信号を受信したか否かを判断することにより、欠落したパケットを判断するより）、送信側および受信側の双方で、再送にかかわる無駄な処理が実行されてしまうようなことを防ぐことが可能となる。換言すれば、より適切に再送の処理を送信側および受信側で行えるようになる。
【０１５１】
このような処理が、受信機２側で行われるようにするには、送信機１側は、再送要求が出されたときに、その再送が要求されたデータを送信できるように構成されていなければならない。そこで、図２に示したように、送信機１は、再送するためのデータを記憶するための記憶部２８を有している。
【０１５２】
図１４のフローチャートを参照して、送信機１が行う、再送要求に対応する処理について説明する。ステップＳ５１において、送信機１は、ＲＴＰヘッダ付加部２２から出力されたＲＴＰパケットを、記憶部２８に記憶する。記憶部２８は、受信機２の記憶部６８がＴＳパケットを記憶する容量と同じ、または、それ以上の容量を有する。
【０１５３】
記憶部２８は、上述したように、ＲＴＰパケットを記憶する。従って、ＲＴＰパケット内のＲＴＰヘッダ４２のシークエンスナンバーにより、記憶されているＲＴＰパケットを識別することが可能である。なお、記憶部２８に記憶されているＲＴＰパケットは、順次、若い番号のシークエンスナンバーを有するＲＴＰパケットから削除され、新たなＲＴＰパケットが記憶できるように構成されている。その削除されるタイミングやデータ量は、記憶部２８の容量を考慮して決定されればよい。
【０１５４】
ＲＴＰヘッダ付加部２２からのＲＴＰパケットは、ＵＤＰヘッダ２３、ＩＰヘッダ付加部２４、およびＭＡＣヘッダ付加部２５の各部で、それぞれのヘッダが付加される。
【０１５５】
そして、通信部２６により、受信機２側に、ＭＡＣパケットとして送信される。このような送信が行われた後も、記憶部２８には、送信されたＭＡＣパケットに含まれるＲＴＰパケットが記憶されている。
【０１５６】
ステップＳ５２において、再送要求を受けたか否かが判断される。この判断は、通信部２６において受信されたデータを、再送制御部２７が参照することにより行われる。このデータは、上述したように、ＴＣＰに基づく通信により受信機２から送信されてきたデータである。
【０１５７】
ステップＳ５２において、受信されたデータは、再送を要求するデータであると判断された場合、ステップＳ５３に処理が進められる。ステップＳ５３において、受信されたデータ内が解析されることにより、再送が要求されているシークエンスナンバー（番号）が特定される。
【０１５８】
シークエンスナンバーの特定が、再送制御部２７により行われると、ステップＳ５４において、その特定されたシークエンスナンバーを有するＲＴＰパケットが、記憶部２８から読み出される。記憶部２８から読み出されたＲＴＰパケットは、ＵＤＰヘッダ付加部２３に供給される。このような制御は、再送制御部２７により行われる。
【０１５９】
ＵＤＰヘッダ付加部２３に供給されたＲＴＰパケットは、ＵＤＰヘッダ付加部２３以降の各部において、ヘッダが付加され、通信部２６により受信機２に対して送信される（ステップＳ５５，Ｓ５６）。
【０１６０】
このようにして、送信機１は、再送の要求があったときに、その要求に対応するために、記憶部２８からＲＴＰパケットを読み出し、再度、受信機２に対して送信を行う。このような処理が、送信機１側で行われることにより、受信機２側では、欠落したと判断されるパケットを取得することができる。
【０１６１】
このように、本発明によれば、ＵＤＰを用いた通信を行うことにより、通信にかかる処理を軽減させることが可能になり、リアルタイムな処理を要求される通信にも対応することが可能となるとともに、受信機２側で、欠落したパケットを取得するための処理が実行されることにより、その通信の信頼性を向上させることが可能となる。
【０１６２】
なお、上述した実施の形態においては、ＲＴＰヘッダ４２に含まれるシークエンスナンバーが用いられて、欠落したパケットが取得されるための処理が行われるとして説明した。このように、ＲＴＰヘッダ４２に含まれるシークエンスナンバーが用いられて、欠落したパケットが取得されるための処理が行われるようにすることにより、通信の過程で発生するパケット落ちだけでなく、送信機１または受信機２の予期されぬ不具合により発生したパケット落ちに対しても対処することができるようになる。
【０１６３】
仮に、送信機１側で、不具合が発生したために、所定の番号のシークエンスナンバーを含むデータが、受信機２側に送信されなかったとする。または、受信機２側で、不具合が発生したために、所定の番号のシークエンスナンバーを含むデータが受信されなかったとする。
【０１６４】
そのような場合、本発明を適用した受信機２は、上述したように、受信できなかったシークエンスナンバーを含むデータを再送するように要求を出すようになっている。しかしながら、ＲＴＰを用いず、従って、シークエンスナンバーを用いずに、通信が行われた場合、受信されなかったデータ（再送を要求するデータ）を特定することができない。従って、仮に、受信機２側から、再送要求を出したしても、送信機１側では、どのデータを再送すれば良いかわからず、結果として、再送できないということなる。
【０１６５】
再送の要求だけなら、無線にかかわるプロトコルにおけるリトライの処理だけでも行うことは可能であるが、再送させるデータを特定するというのは、無線にかかわるプロトコルではカバーできない。よって、本実施の形態のように、ＲＴＰを用いた通信を行うことで、上述したような、再送の処理を実行させることが可能となり、より確実に、欠落したデータを取得できるようにすることにより、より通信の信頼性を向上させることが可能となる。
【０１６６】
また、“Ｓｅｑｕｅｎｃｅ Ｎｕｍｂｅｒ”と“Ｔｉｍｅ Ｓｔａｍｐ”（図５）を併用することにより、図１１のステップＳ１１において、初期値の設定を行うために、受信されたデータが、新しいストリーミングのものであるか否かの判断、すなわち、新たなストリーミングの識別を容易に行うことが可能となる。
【０１６７】
例えば、シークエンスナンバーが連続していても、“Ｔｉｍｅ Ｓｔａｍｐ”が不連続になっているような場合には、新たなストリーミングであると識別することができる。また、複数のストリーミングが同時に流れているような環境下で、送信機１が、各ストリーミングに対して、“Ｔｉｍｅ Ｓｔａｍｐ”をずらした状態で、送信することで、受信機２は、受信された複数のストリーミングから、選択的に、１つのストリーミングを選択し、かつ、上述したような再送の要求を出すことが可能となる。
【０１６８】
なお、上述した実施の形態においては、送信機１は、アナログ信号のテレビジョン放送を受信し、処理するとして説明したが、デジタル信号のテレビジョン放送を受信し、処理する装置であっても良く、そのようにした場合でも、本発明を適用することが可能である。
【０１６９】
送信機１を、デジタル信号のテレビジョン放送を受信し、処理するようにした場合、受信するデータ自体が、既にパケット化されており、また、複数のヘッダが付加されている状態であるので、エンコードや所定のヘッダを付加する処理などを省略し、それらのヘッダのうちの所定の内容を書き換えるなどの処理を施すことにより、上述した発明を適用することが可能である。
【０１７０】
上述した一連の処理（例えば、再送にかかわる処理）は、それぞれの機能を有するハードウェアにより実行させることもできるが、ソフトウェアにより実行させることもできる。一連の処理をソフトウェアにより実行させる場合には、そのソフトウェアを構成するプログラムが専用のハードウェアに組み込まれているコンピュータ、または、各種のプログラムをインストールすることで、各種の機能を実行することが可能な、例えば汎用のパーソナルコンピュータなどに、記録媒体からインストールされる。
【０１７１】
記録媒体について説明する前に、記録媒体をデータを書き込む、または、読み出すパーソナルコンピュータについて説明する。図１５は、汎用のパーソナルコンピュータの内部構成例を示す図である。パーソナルコンピュータのＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）１０１は、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）１０２に記憶されているプログラムに従って各種の処理を実行する。ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）１０３には、ＣＰＵ１０１が各種の処理を実行する上において必要なデータやプログラムなどが適宜記憶される。入出力インタフェース１０５は、キーボードやマウスから構成される入力部１０６が接続され、入力部１０６に入力された信号をＣＰＵ１０１に出力する。また、入出力インタフェース１０５には、ディスプレイやスピーカなどから構成される出力部１０７も接続されている。
【０１７２】
さらに、入出力インタフェース１０５には、ハードディスクなどから構成される記憶部１０８、および、インターネットなどのネットワークを介して他の装置とデータの授受を行う通信部１０９も接続されている。ドライブ１１０は、磁気ディスク１２１、光ディスク１２２、光磁気ディスク１２３、半導体メモリ１２４などの記録媒体からデータを読み出したり、データを書き込んだりするときに用いられる。
【０１７３】
記録媒体は、図１５に示すように、パーソナルコンピュータとは別に、ユーザにプログラムを提供するために配布される、プログラムが記録されている磁気ディスク１２１（フレキシブルディスクを含む）、光ディスク１２２（ＣＤ−ＲＯＭ（Ｃｏｍｐａｃｔ Ｄｉｓｃ−Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ），ＤＶＤ（Ｄｉｇｉｔａｌ Ｖｅｒｓａｔｉｌｅ Ｄｉｓｃ）を含む）、光磁気ディスク１２３（ＭＤ（Ｍｉｎｉ−Ｄｉｓｃ）（登録商標）を含む）、若しくは半導体メモリ１２４などよりなるパッケージメディアにより構成されるだけでなく、コンピュータに予め組み込まれた状態でユーザに提供される、プログラムが記憶されているＲＯＭ１０２や記憶部１０８が含まれるハードディスクなどで構成される。
【０１７４】
なお、本明細書において、媒体により提供されるプログラムを記述するステップは、記載された順序に従って、時系列的に行われる処理は勿論、必ずしも時系列的に処理されなくとも、並列的あるいは個別に実行される処理をも含むものである。
【０１７５】
また、本明細書において、システムとは、複数の装置により構成される装置全体を表すものである。
【０１７６】
【発明の効果】
本発明によれば、何らかの原因で、送信または受信できなかったデータを、受信側で取得することができる。
【０１７７】
また、本発明によれば、何らかの原因で、送信または受信できなかったデータを、特定して、受信側から、送信側に対して、再送するように要求を出すことができる。その要求に送信側の装置が対応することにより、受信側は、受信できなかったデータを取得することができる。
【０１７８】
さらに、本発明によれば、ＵＤＰを用いた通信においても、欠落したパケットを、受信側で、取得することが可能となる。
【図面の簡単な説明】
【図１】本発明を適用した送受信システムの一実施の形態の構成を示す図である。
【図２】送信機の内部構成例を示す図である。
【図３】送信機から送信されるデータについて説明するための図である。
【図４】ＴＳパケットのヘッダについて説明するための図である。
【図５】ＲＴＰヘッダについて説明するための図である。
【図６】ＵＤＰヘッダについて説明するための図である。
【図７】ＩＰヘッダについて説明するための図である。
【図８】ＭＡＣヘッダについて説明するための図である。
【図９】受信機の内部構成例を示す図である。
【図１０】記憶部に記憶されているデータについて説明するための図である。
【図１１】受信機において行われる再送要求にかかわる処理について説明するためのフローチャートである。
【図１２】図１１に示したフローチャートのステップＳ１７における処理について説明するためのフローチャートである。
【図１３】受信されるシークエンスナンバーの関係について説明するための図である。
【図１４】送信機において行われる再送要求にかかわる処理について説明するためのフローチャートである。
【図１５】媒体を説明する図である。
【符号の説明】
１ 送信機， ２１ ＭＰＥＧエンコーダ， ２２ ＲＴＰヘッダ付加部， ２３ ＵＤＰヘッダ付加部， ２４ ＩＰヘッダ付加部， ２５ ＭＡＣヘッダ付加部， ２６ 通信部， ２７ 再送制御部， ２８ 記憶部， ６１ 通信部， ６２ ＭＡＣヘッダ抽出部， ６３ ＩＰヘッダ抽出部， ６４ ＵＤＰヘッダ抽出部， ６５ ナンバーチェック部， ６６ 順序再構成部， ６７ ＲＴＰヘッダ抽出部， ６８ 記憶部， ６９ ＭＰＥＧデコーダ， ７０ 再生制御部， ７１ 計時部
【発明の属する技術分野】
本発明は送受信システム、送信装置および方法、受信装置および方法、記録媒体、並びにプログラムに関し、特に、送受信されているパケットが欠落してしまったときに、その欠落を補う装置に用いて好適な送受信システム、送信装置および方法、受信装置および方法、記録媒体、並びにプログラムに関する。
【０００２】
【従来の技術】
ネットワークが普及し、そのネットワークを用いて提供されるサービスも、多岐にわたるようになってきている。ネットワーク自体の構成も、有線で構成されるものや、無線で構成されるものがある。
【０００３】
ネットワークが普及すると共に、そのネットワークにおける通信の信頼性を向上させるために、例えば、同一のデータを異なる経路で伝送するなどして、一方の経路で何らかの異常が発生しても、他方の経路で、通信を確保できるようにし、データの欠落などを防ぐ方法が提案されている。（例えば、特許文献１参照）
【０００４】
【特許文献１】
特開平１１−９８１６１号公報
【０００５】
【発明が解決しようとする課題】
近年では、家庭内におけるネットワークとして、有線によるものより、設置などが手軽な無線ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）が普及しつつある。しかしながら、無線ＬＡＮは、その特性から、有線ＬＡＮに比べて信頼性が劣るという問題があった。
【０００６】
例えば、無線ＬＡＮは、当然ながら、無線によりデータの送受信が行われるが、無線で行うために、通信を行っている送信機と受信機の間を人が横切ったり、湿度などの環境の変化により、その通信状態が悪化することが考えられる。通信状態が悪化したために、送受信（通信）すべきデータが通信の途中で欠落するなどの不都合が発生することが考えられる。
【０００７】
そのような不都合に対応するために、無線によるデータの送受信においては、再送制御が行われている。具体的には、送信側が送信したデータを受信した受信側は、受信したことを示すＡＣＫ（Ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ）信号を送信側に出すようにし、そのＡＣＫ信号を送信側が受信するまで、送信側は同一のデータを所定の回数だけ送信し続ける（再送し続ける）といったことが行われていた。
【０００８】
このような再送制御は、送信側で、受信側の状態をチェックし、再送を行っていることになる。送信側では、所定の回数だけ、同一のデータを再送し続けることにより、換言すれば、他のデータを送信せずに、同一のデータを送信し続けることにより、遅延が蓄積され、送信すべきデータを、送信すべきタイミングで送信できないといった問題が発生する可能性があった。
【０００９】
また、受信側では、送信側からのデータを正常に受信し、その結果としてＡＣＫ信号を送信したにもかかわらず、データを送信した送信側で、そのＡＣＫ信号を受信できなかったために、送信側では、再送の処理が実行されてしまうことも考えられる。このような再送は、送信側にとっては、無駄な送信の処理であるとともに、そのために、遅延などが発生するのは、通信の信頼性を低下させるといった問題があった。
【００１０】
また、受信側でも、正常に受信したデータが、再送されてくることになり、その再送されたデータも処理しなくてはならず、無駄な処理を繰り返すことになるという問題があった。
【００１１】
このような再送の制御（送信したデータが受信側で正常に受信されたか否かの確認）は、そのデータの送受信において、例えば、ＯＳＩ層モデルにおけるトランスポート層に属するＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）が用いられた場合には行われるが、同じく、ＯＳＩ層モデルにおけるトランスポート層に属するＵＤＰ（Ｕｓｅｒ Ｄａｔａｇｒａｍ Ｐｒｏｔｏｃｏｌ）が用いられた場合には行われない。
【００１２】
従って、ＵＤＰが用いられたデータの送受信においては、受信側が、受信できなかったデータがあっても、その受信できなかったデータを送信側から取得するといったことはできないといった問題があった。
【００１３】
本発明はこのような状況に鑑みてなされたものであり、受信側で、何らかの原因で、受信できなかったデータを、受信側からの再送要求によって送信側から取得できるようにすることを目的とする。
【００１４】
【課題を解決するための手段】
本発明の送受信システムの送信装置は、データを取得する取得手段と、取得手段により取得されたデータに、データの順序を示す情報を付加する付加手段と、付加手段により情報が付加されたデータを記憶する記憶手段と、付加手段により情報が付加されたデータを受信装置に送信する送信手段と、送信手段により送信されたデータの再送が、受信装置から要求された場合、その再送が要求されたデータを記憶手段から読み出し、送信手段に、読み出されたデータの再送を指示する再送手段とを備え、受信装置は、送信手段により送信されたデータを受信する受信手段と、受信手段により受信されたデータに含まれる情報を抽出し、その情報を用いて、データの欠落があるか否かを判断する判断手段と、判断手段により、データの欠落があると判断された場合、欠落していると判断されるデータを特定する特定手段と、特定手段により特定された欠落していると判断されるデータの再送を送信装置に要求する要求手段とを備えることを特徴とする。
【００１５】
本発明の送信装置は、データを取得する取得手段と、取得手段により取得されたデータに、データの順序を示す情報を付加する付加手段と、付加手段により情報が付加されたデータを記憶する記憶手段と、付加手段により情報が付加されたデータを送信する送信手段と、送信手段により送信されたデータの再送が、他の装置から要求された場合、その再送が要求されたデータを記憶手段から読み出し、送信手段に、読み出されたデータの再送を指示する再送手段とを備えることを特徴とする。
【００１６】
前記付加手段は、情報として、ＲＴＰに基づくヘッダを少なくとも付加し、記憶手段は、ＲＴＰのヘッダが付加されたデータを記憶するようにすることができる。
【００１７】
前記他の装置からのデータの再送の要求には、ＲＴＰに基づくヘッダに含まれるＳｅｑｕｅｎｃｅ Ｎｕｍｂｅｒの情報が含まれ、再送手段は、ヘッダに含まれるＳｅｑｕｅｎｃｅ Ｎｕｍｂｅｒの情報と一致するＳｅｑｕｅｎｃｅ Ｎｕｍｂｅｒを含むヘッダが付加されたデータを記憶手段から読み出すようにすることができる。
【００１８】
本発明の送信方法は、データの取得を制御する取得制御ステップと、取得制御ステップの処理で取得が制御されたデータに、データの順序を示す情報を付加する付加ステップと、付加ステップの処理で情報が付加されたデータの記憶を制御する記憶制御ステップと、付加ステップの処理で情報が付加されたデータの送信を制御する送信制御ステップと、送信制御ステップの処理で送信が制御されたデータの再送が、他の装置から要求された場合、その再送が要求されたデータを記憶制御ステップの処理で記憶が制御されたデータ内から読み出し、送信制御ステップの処理に、読み出されたデータの再送を指示する再送ステップとを含むことを特徴とする。
【００１９】
本発明の記録媒体のプログラムは、データの取得を制御する取得制御ステップと、取得制御ステップの処理で取得が制御されたデータに、データの順序を示す情報を付加する付加ステップと、付加ステップの処理で情報が付加されたデータの記憶を制御する記憶制御ステップと、付加ステップの処理で情報が付加されたデータの送信を制御する送信制御ステップと、送信制御ステップの処理で送信が制御されたデータの再送が、他の装置から要求された場合、その再送が要求されたデータを記憶制御ステップの処理で記憶が制御されたデータ内から読み出し、送信制御ステップの処理に、読み出されたデータの再送を指示する再送ステップとを含むことを特徴とする。
【００２０】
本発明のプログラムは、データの取得を制御する取得制御ステップと、取得制御ステップの処理で取得が制御されたデータに、データの順序を示す情報を付加する付加ステップと、付加ステップの処理で情報が付加されたデータの記憶を制御する記憶制御ステップと、付加ステップの処理で情報が付加されたデータの送信を制御する送信制御ステップと、送信制御ステップの処理で送信が制御されたデータの再送が、他の装置から要求された場合、その再送が要求されたデータを記憶制御ステップの処理で記憶が制御されたデータ内から読み出し、送信制御ステップの処理に、読み出されたデータの再送を指示する再送ステップとを含む処理をコンピュータに実行させることを特徴とする。
【００２１】
本発明の受信装置は、データを受信する受信手段と、受信手段により受信されたデータに含まれる所定の情報を抽出し、その情報を用いて、データの欠落があるか否かを判断する判断手段と、判断手段により、データの欠落があると判断された場合、欠落していると判断されるデータを特定する特定手段と、特定手段により特定された欠落していると判断されるデータの再送をデータを送信してきた他の装置に要求する要求手段とを備えることを特徴とする。
【００２２】
前記要求手段により要求が出されたときから計時を開始する計時手段と、計時手段による計時が、所定の時間を経過する毎に、再度要求を出すように要求手段に指示する指示手段とをさらに含むようにすることができる。
【００２３】
前記判断手段は、所定の情報としてデータに含まれるＲＴＰに基づくヘッダを抽出し、そのヘッダに含まれるＳｅｑｕｅｎｃｅ Ｎｕｍｂｅｒの情報を用いて、データの欠落があるか否かを判断することを特徴とする。
【００２４】
前記判断手段は、ヘッダに含まれていたＳｅｑｕｅｎｃｅ Ｎｕｍｂｅｒのうち、最も大きい番号の第１のＳｅｑｕｅｎｃｅ Ｎｕｍｂｅｒを記憶し、その記憶している第１のＳｅｑｕｅｎｃｅ Ｎｕｍｂｅｒと、新たに供給されたヘッダに含まれる第２のＳｅｑｕｅｎｃｅ Ｎｕｍｂｅｒが連続している番号ではなく、かつ、第１のＳｅｑｕｅｎｃｅ Ｎｕｍｂｅｒの方が第２のＳｅｑｕｅｎｃｅ Ｎｕｍｂｅｒより小さい番号であると判断したとき、データが欠落していると判断し、特定手段は、第１のＳｅｑｕｅｎｃｅ Ｎｕｍｂｅｒから第２のＳｅｑｕｅｎｃｅ Ｎｕｍｂｅｒまでに位置する番号の第３のＳｅｑｕｅｎｃｅ Ｎｕｍｂｅｒをヘッダに含むデータを、欠落していると判断されるデータであると特定し、要求手段は、欠落されていると判断されるデータの再送を、第３のＳｅｑｕｅｎｃｅ Ｎｕｍｂｅｒの情報を含むデータを他の装置に送信することにより要求するようにすることができる。
【００２５】
前記要求手段は、第３のＳｅｑｕｅｎｃｅ Ｎｕｍｂｅｒの情報を含むデータを、ＴＣＰに基づいて送信するようにすることができる。
【００２６】
前記判断手段は、第１のＳｅｑｕｅｎｃｅ Ｎｕｍｂｅｒと、第２のＳｅｑｕｅｎｃｅ Ｎｕｍｂｅｒが連続している番号ではなく、かつ、第１のＳｅｑｕｅｎｃｅ Ｎｕｍｂｅｒの方が第２のＳｅｑｕｅｎｃｅ Ｎｕｍｂｅｒより大きい番号であると判断したとき、その第２のＳｅｑｕｅｎｃｅ Ｎｕｍｂｅｒを含むデータは、再送されてきたデータであると判断するようにすることができる。
【００２７】
本発明の受信方法は、データの受信を制御する受信制御ステップと、受信制御ステップの処理で受信されたデータに含まれる所定の情報を抽出し、その情報を用いて、データの欠落があるか否かを判断する判断ステップと、判断ステップの処理により、データの欠落があると判断された場合、欠落していると判断されるデータを特定する特定ステップと、特定ステップの処理で特定された欠落していると判断されるデータの再送をデータを送信してきた他の装置に要求する要求ステップとを含むことを特徴とする。
【００２８】
本発明の記録媒体のプログラムは、データの受信を制御する受信制御ステップと、受信制御ステップの処理で受信されたデータに含まれる所定の情報を抽出し、その情報を用いて、データの欠落があるか否かを判断する判断ステップと、判断ステップの処理により、データの欠落があると判断された場合、欠落していると判断されるデータを特定する特定ステップと、特定ステップの処理で特定された欠落していると判断されるデータの再送をデータを送信してきた他の装置に要求する要求ステップとを含むことを特徴とする。
【００２９】
本発明のプログラムは、データの受信を制御する受信制御ステップと、受信制御ステップの処理で受信されたデータに含まれる所定の情報を抽出し、その情報を用いて、データの欠落があるか否かを判断する判断ステップと、判断ステップの処理により、データの欠落があると判断された場合、欠落していると判断されるデータを特定する特定ステップと、特定ステップの処理で特定された欠落していると判断されるデータの再送をデータを送信してきた他の装置に要求する要求ステップとを含む処理をコンピュータに実行させることを特徴とする。
【００３０】
本発明においては、データの送受信の過程で、受信装置が、データを受信できなかった場合、受信装置が、送信装置に対して欠落したデータの再送を要求する。
【００３１】
本発明においては、データを送信する側が、データを送信すると共に、そのデータを記憶し、受信する側から、既に送信したデータの再送が要求されたときには、その記憶されているデータが再送される。
【００３２】
本発明においては、データを受信する側が、欠落したデータがあると判断した場合、その欠落したデータを特定するための情報を、送信側に送信する。
【００３３】
【発明の実施の形態】
以下に、本発明の実施の形態について図面を参照して説明する。図１は、本発明を適用した送受信システムの一実施の形態の構成を示す図である。図１に示した送受信システムは、送信機１と受信機２から構成されている。送信機１は、アンテナ３により受信されたテレビジョン放送のデータを、受信機２に対して送信する。受信機２は、表示装置（例えば、ディスプレイ）や音声出力装置（例えば、スピーカ）を備えており、受信したデータに基づく画像や音声を出力するように構成されている。
【００３４】
ここでは、アナログ信号のテレビジョン放送が受信され、そのデータが、受信機２に送信されるとして説明するが、本発明は、アナログ信号のテレビジョン放送だけでなく、例えば、ＢＳ（Ｂｒｏａｄｃａｓｔｉｎｇ Ｓａｔｅｌｌｉｔｅ）放送、ＣＳ（Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ｓａｔｅｌｌｉｔｅ）放送、地上波デジタル放送などのデジタル信号のテレビジョン放送に対しても適用することが可能である。
【００３５】
また、例えば、ＶＴＲ（Ｖｉｄｅｏ Ｔａｐｅ Ｒｅｃｏｒｄｅｒ）やＤＶＤ（Ｄｉｇｉｔａｌ Ｖｅｒｓａｔｉｌｅ Ｄｉｓｃ）プレーヤなどが送信機１に接続され、それらの装置からのデータが、送受信されるようにしても良い。さらに、インターネットなどのネットワークに接続され、そのネットワークに接続されることにより得られる情報などの送受信が行われるようにしても良い。
【００３６】
送信機１と受信機２は、無線でデータの授受を行う。その無線による通信は、例えば、ＩＥＥＥ８０２．１１ａの規格に基づく方式で行われる。送信機１と受信機２は、無線によりデータの授受を行うため、例えば、ユーザは、送信機１を家の所定の場所に固定して設置し、受信機２を所望の場所まで持ち運び、その場所でテレビジョン放送を閲覧するといったことをできる。
【００３７】
図２は、送信機１の内部構成例を示す図である。図２に示した内部構成例は、主に、本発明にかかわり、説明に必要とされる部分を示し、説明に必要ない部分、例えば、受信したテレビジョン放送からユーザが指定した番組を抽出するチューナや、ＶＴＲやＤＶＤプレーヤなどを接続した際に、それらの装置からの入力を切り換えるスイッチャーなどは、省略してある。
【００３８】
送信機１は、アンテナ３により受信されたテレビジョン放送としてのデータ（信号）を入力する。入力される信号は、例えば、アナログ信号である。そのアナログ信号は、ＭＰＥＧ（Ｍｏｖｉｎｇ Ｐｉｃｔｕｒｅ Ｅｘｐｅｒｔｓ Ｇｒｏｕｐ）エンコーダ２１に入力される。ＭＰＥＧエンコーダ２１は、入力されたアナログ信号を、ＭＰＥＧ方式に基づく圧縮を施したデジタルデータに変換する。
【００３９】
なお、デジタル信号のテレビジョン放送のデータなどが入力される場合、ＭＰＥＧエンコーダ２１によりエンコードされる必要はないので、必ずしも、入力されたデータが、ＭＰＥＧエンコーダ２１を介する構成とされる必要はなく、適宜、入力されるデータにより、入力される部分が異なるようにしても良い。勿論、そのような入力されたデータの出力先を選択するためのスイッチャーなどが、図示はしないが、送信機１には備え付けられている。
【００４０】
ＭＰＥＧエンコーダ２１からの出力（トランスポートストリームパケット：以下、適宜、ＴＳパケットと記述する）は、ＲＴＰ（Ｒｅａｌ Ｔｉｍｅ Ｐｒｏｔｏｃｏｌ）ヘッダ付加部２２に供給される。ＲＴＰヘッダ付加部２２は、供給されたＴＳパケットを所定の個数、例えば、７個のパケットをまとめ、そのまとめたパケットにＲＴＰヘッダを付加し、ＵＤＰ（Ｕｓｅｒ Ｄａｔａｇｒａｍ Ｐｒｏｔｏｃｏｌ）付加部２３に供給する。ＲＴＰヘッダ付加部２２によりＲＴＰヘッダを付加されたＴＳパケットを、適宜、ＲＴＰパケットと記述する。
【００４１】
ＵＤＰヘッダ付加部２３は、供給されたＲＴＰパケットに対して、さらに、ＵＤＰヘッダを付加して、ＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）ヘッダ付加部２４に供給する。ＵＤＰヘッダ付加部２３によりＵＤＰヘッダを付加されたＲＴＰパケットを、適宜、ＵＤＰパケットと記述する。
【００４２】
ＩＰヘッダ付加部２４は、供給されたＵＤＰパケットに対して、ＩＰヘッダを付加し、ＭＡＣ（Ｍｅｄｉａ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ）ヘッダ付加部２５に供給する。ＩＰヘッダ付加部２４によりＩＰヘッダを付加されたＵＤＰパケットを、適宜、ＩＰパケットと記述する。
【００４３】
ＭＡＣヘッダ付加部２５は、供給されたＩＰパケットに対して、ＭＡＣヘッダを付加し、通信部２６に供給する。ＭＡＣヘッダ付加部２５によりＭＡＣヘッダを付加されたＩＰパケットを、適宜、ＭＡＣパケットと記述する。
【００４４】
各部で、ヘッダを付加され、ＭＡＣパケットとされたＴＳパケットは、通信部２６により、受信機２に対して送信される。通信部２６は、受信機２に対してＭＡＣパケット（データ）を送信するだけでなく、受信機２からのデータも受信する。受信機２からのデータとしては、後述するように、受信機２側でデータを受信できなかった場合に出力される再送要求のデータがある。そのような再送要求のデータが受信された場合、そのデータは、再送制御部２７に供給される。
【００４５】
再送制御部２７は、供給されたデータに基づき、再送要求のあったデータを特定し、その特定したデータが、記憶部２８から、ＵＤＰヘッダ付加部２３に供給されるように制御する。記憶部２８には、このように、再送の指示がされたときのためのデータが記憶されている。記憶部２８には、ＲＴＰヘッダ付加部２２によりＲＴＰヘッダが付加されているＲＴＰパケットが記憶される。
【００４６】
図３は、ＭＰＥＧエンコーダ２１乃至ＭＡＣヘッダ付加部２５の各部が、処理を行うことにより、通信部２６に供給されるデータ（ＭＡＣパケット）を示す図である。図３に示すように、通信部２６に供給されるデータは、ＭＰＥＧエンコーダ２１によりエンコードされたＴＳパケット４１を含む。上述したように、通信部２６に供給されるＭＡＣパケット内のＴＳパケット４１には、ＴＳパケット４１−１乃至４１−７の７個のパケットが含まれている。１つのＴＳパケットは、１８８Ｂｙｔｅｓで構成されている。
【００４７】
１つのＴＳパケット４１（例えばＴＳパケット４１−１）は、ヘッダ部５１とデータ部５２から構成されている。ヘッダ部５１は、図４に示すデータを含み、データ部５２は、受信機２（図１）側で、画像または音声としてユーザに提供するためのビデオデータまたはオーディオデータを含む。
【００４８】
図４は、ＴＳパケット４１のヘッダ部５１のデータ構成を示す図である。ヘッダ部５１は、４Ｂｙｔｅｓで構成され、データ部５２は、１８４Ｂｙｔｅｓで構成される。ヘッダ部５１の“同期バイト”は、同期を取るために設けられており、固定値で、例えば、４７ｈが設定されている。“Ｅｒｒｏｒ Ｆｌａｇ”は、ＴＳパケット４１の中に訂正できないｂｉｔ ｅｒｒｏｒがあるか否かを示すフラグである。
【００４９】
“Ｓｔａｒｔ Ｆｌａｇ”は、新しいＰＥＳ Ｐａｃｋｅｔあるいは新しいＴＳ−ＰＳＩ Ｓｅｃｔｉｏｎであることを示すフラグである。“Ｐｒｉｏｒｉｔｙ Ｆｌａｇ”は、パケットの優先度を示すフラグであり、このフラグ（ｂｉｔ）が、１に設定されていると、他のＴＳパケット４１より重要度が高いことを示す。“ＰＩＤ”は、ＴＳパケット４１のＰａｙｌｏａｄ部分（データ部５２）が、ビデオデータであるか、オーディオデータであるか、あるいは、ＴＳ−ＰＳＩ（ＴＳ−Ｐｒｏｇｒａｍ Ｓｐｅｃｉｆｉｃ Ｉｎｆｏｒｍａｔｉｏｎ）であるかを、それぞれを区別するために付与される、１３ｂｉｔで構成される数値（Ｉｄｅｎｔｉｆｉｅｒ）である。
【００５０】
“Ｓｃｒａｍｂｌｉｎｇ ｍｏｄｅ”は、データ部５２のＳｃｒａｍｂｌｉｎｇ ｍｏｄｅ（スクランブルモード）を示す情報である。“Ａｄａｐｔａｔｉｏｎ Ｆｉｅｌｄ ｆｌａｇ”は、ＰＣＲ（Ｐｒｏｇｒａｍ Ｃｌｏｃｋ Ｒｅｆｅｒｅｎｃｅ）などの情報が含まれているＡｄａｐｔａｔｉｏｎ Ｆｉｅｌｄの有無を示す情報である。“Ｃｏｎｔｉｎｕｉｔｙ Ｃｏｕｎｔｅｒ”は、同じＰＩＤを持つパケットで、１ずつ値が増加されるカウンタ値の情報である。
【００５１】
ＭＰＥＧエンコーダ２１（図２）では、入力されたアナログ信号をデジタルデータに変換し、ＭＰＥＧ方式の圧縮を施してデータ部５２を生成すると共に、図４に示したようなヘッダ部５１を生成し、１つのＴＳパケット４１を生成する。
【００５２】
このようなＴＳパケット４１が、この場合、７個含まれるのが、図３に示したＴＳパケット４１である。ＲＴＰヘッダ４２（図３）は、ＲＴＰヘッダ付加部２２（図２）により付加されるヘッダであるが、そのデータ構成は、図５に示すように構成されている。
【００５３】
ＲＴＰヘッダ４２の“Ｖ”は、Ｖｅｒｓｉｏｎ Ｂｉｔを示し、ＲＴＰヘッダ４２のフォーマットのバージョンを示すバージョン番号の情報である。“Ｐ”は、Ｐａｄｄｉｎｇ Ｂｉｔを示し、パケットのサイズを調整するビットである。“Ｘ”は、Ｅｘｔｅｎｓｉｏｎ Ｂｉｔを示し、機能拡張時に指定される拡張ビットである。
【００５４】
“ＣＣ”は、ＣＳＲＣ Ｃｏｕｎｔを示し、リアルタイム転送に関わる送信元の数を示すカウンタの情報である。“Ｍ”は、Ｍａｒｋｅｒ Ｂｉｔを示し、１パケットにおけるフレームの境界を示すマーカービットである。“ＰＴ”は、Ｐａｙｌｏａｄ Ｔｙｐｅを示し、ペイロードの符号化の種類を示す情報である。“Ｓｅｑｕｅｎｃｅ Ｎｕｍｂｅｒ”は、ＲＴＰパケットの順番を示すシーケンス番号を示す情報である。
【００５５】
“ＴＩＭＥ ＳＴＡＭＰ”は、ＲＴＰヘッダ４２が作成された時刻を示すタイムスタンプの情報を示す。“ＳＳＲＣ”は、Ｓｙｎｃｈｒｏｎｉｚａｔｉｏｎ Ｓｏｕｒｃｅを示し、メッセージの最初の送信元（ソース）を識別する同期ソース識別子の情報である。“ＣＳＲＣ”は、Ｃｏｎｔｒｉｂｕｔｉｎｇ Ｓｏｕｒｃｅを示し、メッセージに含まれるパケット群の送信先（クライアント）を識別する貢献ソース識別子の情報である。
【００５６】
このような情報を含むＲＴＰヘッダ４２に対応するペイロード（Ｐａｙｌｏａｄ）に、ＴＳパケット４１が挿入される。ＲＴＰヘッダ４２が付加されているＲＴＰパケットにＵＤＰヘッダ４３（図３）が、ＵＤＰヘッダ付加部２３（図２）により付加される。
【００５７】
図６は、ＵＤＰヘッダ４３のデータ構成を示す図である。ＵＤＰヘッダ４３の“ＳＲＣ ＰＯＲＴ”は、送信元のポート番号を指定する情報であり、“ＤＥＳＴ ＰＯＲＴ）は、送信先（宛先）のポート番号を指定する情報であり、共に、サービスを特定するための情報として用いられる。
【００５８】
“Ｌｅｎｇｔｈ”は、ＵＤＰヘッダ４３とその後に続くデータの長さ（バイト単位）の合計を示す情報である。“Ｃｈｅｃｋｓｕｍ”は、ＵＤＰヘッダの情報と、データ長を元にして算出された値の情報である。受信側では、送信側と同様の計算を行い、Ｃｈｅｃｋｓｕｍ（チェックサム）の値を算出し、その算出した値と、送信されてきたＵＤＰヘッダ４３に含まれるチェックサムの値が一致しているか否かを判断することで、途中で、パケットが壊れていないか否かを判断する。
【００５９】
このようなＵＤＰヘッダ４３が付加されたＵＤＰパケットに、ＩＰヘッダ４４（図３）が、ＩＰヘッダ付加部２４（図２）により付加される。図７は、ＩＰヘッダ４４のデータ構成を示す図である。図７に示したＩＰヘッダ４４のデータ構成は、基本ヘッダの部分だけを示し、オプションヘッダについては図示していない。
【００６０】
“Ｖｅｒ”は、インターネットプロトコル（ＩＰ）のバージョンを示す情報である。“ＩＨＬ”は、Ｉｎｔｅｒｎｅｔ Ｈｅａｄｅｒ Ｌｅｎｇｔｈを示し、このヘッダの長さを示す情報である。“ＴＯＳ”は、Ｔｙｐｅ Ｏｆ Ｓｅｒｖｉｃｅを示し、データの優先度の定義や、どのようなタイプの転送を行うかなどを指定する情報である。
【００６１】
“ＴＬ”は、Ｔｏｔａｌ Ｌｅｎｇｔｈを示し、ＩＰヘッダ４４と、ＩＰヘッダ４４以降のデータの合計の長さを示す情報である。“ＩＤ”は、このＩＰヘッダ４４で示されるＩＰパケットを識別するための情報である。“ＦＬ”は、ＩＰ層でデータを分割（フラグメント）した際の、その制御に関する情報である。
【００６２】
“ＦＯ”は、ＩＰ層でデータが分割された際のデータが、どこにあったかを示す情報である。“ＴＴＬ”は、Ｔｉｍｅ Ｔｏ Ｌｉｖｅを示し、このＩＰヘッダ４４を含むデータが、いつ破棄されるのかを示す情報である。“ＰＲＯＴ”は、ＩＰ層より上の層で用いられているプロトコルを示す情報である。
【００６３】
“ＨＣ”は、ＩＰヘッダ４４が送信中に壊れていないか否かを、受信側で確認するためのチェックサムの情報である。“ＳＡ”は、データの送信元のＩＰアドレスを示す情報である。“ＤＡ”は、データの送信先のＩＰアドレスを示す情報である。
【００６４】
このようなＩＰヘッダ４４が付加されたＩＰパケットに、ＭＡＣヘッダ４５（図３）が、ＭＡＣヘッダ付加部２５（図２）により付加される。図８は、ＭＡＣヘッダ４５のデータ構成を示す図である。
【００６５】
“ＰＡ”は、プリアンブルであり、クロックリカバリのためのＰＬＬをロックするさせるための情報である。“ＤＡ”は、送信先のＭＡＣアドレスを示す情報である。“ＳＡ”は、送信元のＭＡＣアドレスを示す情報である。“Ｔｙｐｅ”は、上位層のプロトコルを示し情報である。
【００６６】
“Ｌｅｎｇｔｈ”は、ペイロードのデータのバイト数を示す情報である。１つのＭＡＣヘッダ４５には、“Ｔｙｐｅ”または“Ｌｅｎｇｔｈ”のどちらか一方の情報が書き込まれる。“ＦＣＳ”は、エラーチェックのための情報である。
【００６７】
このような情報を含むＭＡＣヘッダ４５が付加されることにより、図３に示したようなデータ（ＭＡＣパケット）が生成される。
【００６８】
ここでは、図３に示した構成のデータが、送信機１から送信されるとして説明するが、ＲＴＰヘッダ４２が付加されていない構成のデータでも、受信機２側にデータを送信することは可能である。しかしながら、図３に示したように、本実施の形態においては、ＲＴＰヘッダ４２が付加されたデータを送信するようにする。
【００６９】
このように、ＲＴＰヘッダ４２が付加されたデータが送信されるようにするのは、詳細は後述するが、受信機２側で、送信機１から送信されたデータを、何らかの原因により、受信できなかったときに、ＲＴＰヘッダ４２内の情報（具体的には、図５に示した“Ｓｅｑｕｅｎｃｅ Ｎｕｍｂｅｒ”）が用いられるからである。
【００７０】
ＵＤＰヘッダ４３は、ＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）ヘッダに置き換えることが可能である（ＴＣＰヘッダにしても良い）。しかしながら、本実施の形態においては、図３に示したように、ＵＤＰヘッダ４３を用いる。
【００７１】
このように、ＴＣＰヘッダを付加するのではなく、ＵＤＰヘッダを付加するようにするのは、以下の理由からである。ＴＣＰヘッダは、トランスポート層のプロトコルとして、ＴＣＰが用いられたときに付加されるヘッダであり、ＵＤＰヘッダは、トランスポート層のプロトコルとして、ＵＤＰが用いられたときに付加されるヘッダである。
【００７２】
トランスポート層のプロトコルとして、ＴＣＰを用いるか、または、ＵＤＰを用いるかを決定する要因の１つとして、そのプロトコルを用いて行われる通信ではどのようなデータが送受信されるのかという要因がある。ＴＣＰは、コネクション型のプロトコルと称され、ＵＤＰはコネクションレス型のプロトコルと称されることがある。
【００７３】
ＴＣＰは、コネクション型のプロトコルであるので、データの授受にかかわる処理手順が複雑になるが、通信にかかわる信頼度は向上する。従って、主に、信頼度を優先させる通信に用いられる。ＴＣＰに対し、ＵＤＰは、コネクションレス型のプロトコルであるので、データの授受にかかわる処理手順は簡素化されているが、通信にかかる処理時間は短くなるため、処理速度を優先させる通信に用いられる。
【００７４】
本実施の形態においては、上述したように、送信機１が受信したテレビジョン放送のデータを、受信機２側に送信するので、その送信機１と受信機２との間のデータの授受にかかわるプロトコルは、信頼度より処理速度を優先させ、リアルタイムに処理できるようにした方が良いため、ＵＤＰを用いる。
【００７５】
しかしながらＵＤＰを用いて通信を行うと、送信機１が送信したデータが、何らかの原因で、受信機２側で受信されてなくても、送信機１側は、そのような状況に関係なく、データを順次送信し続ける。従って、受信機２側では、欠落したデータを取得することができない。受信機２が、欠落したデータを取得することなく、欠落したまま処理を続けると、ユーザに提供される映像や音声がとぎれたり、乱れたりする。そのようなことは、できる限り発生しない方が好ましい。
【００７６】
そこで、本実施の形態においては、ＵＤＰを用いた通信においても、何らかの原因で、受信側でデータを受信できなかったとき、すなわち、データの欠落が生じたとき、その欠落したデータを受信側で取得できるようにする。そのような機能を有する受信機２について説明する。
【００７７】
図９は、受信機２の内部構成例を示す図である。受信機２の通信部６１は、送信機１からのデータを受信すると共に、送信機１に対して所定のデータを送信する。通信部６１により受信された送信機１からの、図３に示したような構成のデータは、ＭＡＣヘッダ抽出部６２に供給される。ＭＡＣヘッダ抽出部６２は、供給されたデータ（ＭＡＣパケット）から、ＭＡＣヘッダ４５（図３）を抽出（除去）し、ＩＰパケットをＩＰヘッダ抽出部６３に供給する。
【００７８】
ＩＰヘッダ抽出部６３は、供給されたＩＰパケットからＩＰヘッダ４４を抽出し、ＵＤＰパケットをＵＤＰヘッダ抽出部６４に供給する。ＵＤＰヘッダ抽出部６３は、供給されたＵＤＰパケットからＵＤＰヘッダ４３を抽出し、ＲＴＰパケットをナンバーチェック部６５に供給する。
【００７９】
ナンバーチェック部６５は、ＲＴＰヘッダ４２に含まれる“Ｓｅｑｕｅｎｃｅ Ｎｕｍｂｅｒ”（図５）（以下、適宜、シークエンスナンバーと記述する）を参照し、そのシークエンスナンバーをチェックする。シークエンスナンバーは、送信機１側で、処理された順（生成されたＲＴＰヘッダ４２順）に、通常、昇順に割り振られる連続した番号である。なおここでは、昇順に割り振られるとして説明をするが、降順に割り振られるようにしても良い。
【００８０】
ナンバーチェック部６５は、チェックしたシークエンスナンバーが連続した番号である場合、供給されたＲＴＰパケットを、順序構成部６６に供給し、チェックした番号が連続でない場合、供給されたＲＴＰパケットを、順序構成部６６に供給すると共に、再送制御部７０に対して、欠落したデータの再送を要求するように指示を出す。再送制御部７０は、所定のＲＴＰパケットを含むパケットの再送を要求する指示を受けた場合、通信部６１に対して、再送の要求を示すデータを送信機１に対して送信させる。
【００８１】
一方、順序構成部６６は、供給されたＲＴＰパケットのシークエンスナンバーを参照し、そのシークエンスナンバーと同一の番号を持つデータ（対応するデータ）が記憶部６８に記憶されているか否かを判断し、記憶されていると判断した場合、その供給されたＲＴＰパケットを破棄し、記憶されていないと判断した場合、その供給されたＲＴＰパケットをＲＴＰヘッダ抽出部６７に供給する。
【００８２】
ＲＴＰヘッダ抽出部６７は、供給されたＲＴＰパケットから、ＲＴＰヘッダ４２を抽出し、ＴＳパケット４１を、記憶部６８に記憶させる。記憶部６８には、このようにして、ＴＳパケット４１が記憶されるが、そのＴＳパケット４１は、ＲＴＰヘッダ４２内のデータとしてのシークエンスナンバーと関連付けられて記憶される。
【００８３】
記憶部６８は、バッファとしての役割を有し、順次記憶されているＴＳパケット４１を、ＭＰＥＧデコーダ６９に出力する。ＭＰＥＧデーコーダ６９は、順次、供給されたＴＳパケット４１に対し、ＭＰＥＧ方式に基づくデコードを施す。ＭＰＥＧデコーダ６９からの出力は、図示されていないディスプレイやスピーカに供給され、ユーザに映像や音声として提供される。
【００８４】
計時部７１は、計時する手段を有し、所定のタイミングで、記憶部６８に記憶されているＴＳパケット４１を監視する。計時部７１は、記憶部６８に、欠落しているＴＳパケット４１（データ）があると判断した場合、再送制御部７０に、その欠落しているＴＳパケット４１を再送する要求を出すように指示を出す。
【００８５】
ここで、記憶部６８に記憶されているデータについて説明する。図１０は、記憶部６８に記憶されているデータのデータ構成を説明するための図である。上述したように、記憶部６８には、ＲＴＰヘッダ４２内に含まれるシークエンスナンバーと、そのシークエンスナンバーのＲＴＰパケットに含まれているＴＳパケットが関連付けられて記憶されている。
【００８６】
なお、記憶部６８に記憶させるシークエンスナンバーは、シークエンスナンバーそのものでも良いし、シークエンスナンバーを一意に導き出せるデータでも良い。
【００８７】
例えば、図１０に示したように、シークエンスナンバー“１”には、ＴＳパケット１−１乃至１−７が関連付けられて記憶されている。これは、上述したように、本実施の形態においては、１つのＲＴＰパケット（受信機２側で受信されるＭＡＣパケット）には、７個のＴＳパケットを含むと設定しているからであり、例えば、８個のＴＳパケットを含むと設定されている場合には、シークエンスナンバー“１”には、ＴＳパケット１−１乃至１−８の８個のＴＳパケットが関連付けられて記憶されることになる。
【００８８】
図１０に示した例を再度参照するに、同じくシークエンスナンバー“２”には、同じく７個のＴＳパケット２−１乃至２−７が関連付けられている。しかしながら、シークエンスナンバー“３”の欄には、本来ならば、ＴＳパケット３−１乃至３−７が関連付けられて記憶されるが、図１０に示した例では、ＴＳパケットが記憶されていない。これに対し、シークエンスナンバー“４”には、ＴＳパケット４−１乃至４−７が関連付けられて記憶されている。
【００８９】
このように、記憶部６８には、正常に受信され処理されると、シークエンスナンバーと関連付けられてＴＳパケットが、所定の領域に記憶される。記憶部６８には、シークエンスナンバー順に、ＴＳパケットが所定の領域に記憶されるようになっている。一方、何らかの原因で、正常に受信が行われなかったシークエンスナンバーの領域（この場合、シークエンスナンバー“３”の領域）は、何も記憶されない状態とされる。
【００９０】
このように、記憶部６８には、ＴＳパケットが記憶されている領域を有するシークエンスナンバーと、ＴＳパケットが記憶されていない領域を有するシークエンスナンバーとが混在する。そこで、ＴＳパケットが記憶されているか否かを示すフラグを用いて、ＴＳパケットが記憶されている領域を有するシークエンスナンバーと、そうでないシークエンスナンバーとを区別できるようにしても良い。また、そのようなフラグを、後述する処理において用いるようにしても良い。
【００９１】
このように、記憶部６８に記憶されないＴＳパケットが存在しているとき、換言すれば、シークエンスナンバーが飛んでいるようなときには、ナンバーチェック部６５または計時部７１の処理により、その記憶されていないＴＳパケット（欠落しているＴＳパケット）の再送を要求するためのデータを出すように、再送制御部７０に指示が出される。
【００９２】
なお、付言するに、図９に示した受信機２の構成では、ナンバーチェック部６５が、供給されたＲＴＰヘッダ４２内のシークエンスナンバーが飛んでいるか否かを判断し、計時部７１が、記憶部６８を参照し、記憶部６８に記憶されていないＴＳパケットが存在しているか否かを判断し、順序再構成部６６が、記憶部６８に記憶されているＴＳパケットを参照して、シークエンスナンバー順に、ＴＳパケットが記憶されるように、ＴＳパケットの順序を再構成する。
【００９３】
このような指示が出される際の処理について、図１１と図１２のフローチャートを参照して説明する。ステップＳ１１において初期値が設定される。この初期値の設定の処理は、ナンバーチェック部６５において行われる。初期値の設定は、受信機２の電源がオンにされたときなどに行われる。すなわち、新たなデータを受信したと判断したとき（新たなＲＴＰパケットが供給されたと判断されたとき）に行われる。
【００９４】
新たなデータを受信したときとは、ＲＴＰヘッダ４２に含まれているシークエンスナンバー（Ｓｅｑｕｅｎｃｅ Ｎｕｍｂｅｒ）が、新たな番号になっていると判断されたときである。新たな番号になっているか否かの判断は、ナンバーチェック部６５が、自己が管理（記憶）しているシークエンスナンバー（番号）と、供給されたＲＴＰパケットに含まれるＲＴＰヘッダ４２内のシークエンスナンバーを比較することにより行われる。
【００９５】
このような比較、および、後述する処理を行うために、ナンバーチェック部６５は、常に、供給されたＲＴＰパケット内のＲＴＰヘッダ４２のシークエンスナンバー（番号）を記憶し、その記憶している番号を、ＲＴＰパケットが供給される毎に更新する。なお、この更新は、通常（初期値が設定されるとき以外のとき）は、記憶している番号より大きい番号のシークエンスナンバーであると判断されたときのみ行われる。そのため、常に、その時点で、最も大きい番号のシークエンスナンバーが記憶されていることになる。
【００９６】
しかしながら、初期値の設定のときには、そのような制限にかかわらず、設定が行われる。その設定は、ナンバーチェック部６５に管理されている番号と、供給されたＲＴＰヘッダ４２のシークエンスナンバーを比較し、その値の差が大きい（予め設定されている値以上の差がある）場合、新たなデータの受信が開始されたと判断し、管理されている番号が更新されることにより行われる。
【００９７】
なお、このような初期値の設定の処理は、通常のときでも行われる可能性がある。例えば、何らかの原因で、送信機１からのデータを比較的長時間、受信できなかったときなど、シークエンスナンバーの連続性がとぎれることになる。その結果、ナンバーチェック部６５に管理されている番号と、供給されたＲＴＰヘッダ４２のシークエンスナンバーとの差が大きくなり、初期値の設定と同様の処理が実行される可能性がある。
【００９８】
このようにして、初期値が設定された後は、通常の処理が実行される。通常の処理とは、ステップＳ１２以降の処理である。なお、図１１、図１２に示したフローチャートの処理は、データが受信される毎に、そのデータに対して行われるが、初期値の設定が行われた後には、ステップＳ１２以降の処理から行われれば良く、ステップＳ１１の処理を省略することが可能である。
【００９９】
初期値の設定が終了されると、ステップＳ１２において、受信されたＭＡＣパケット内に含まれるＲＴＰヘッダ４２のシークエンスナンバーは、連続しているか否かが判断される。この判断も、ナンバーチェック部６５において行われる。上述したように、ナンバーチェック部６５は、供給されたＲＴＰパケット内のＲＴＰヘッダ４２に含まれるシークエンスナンバーが、その時点で最も大きい番号を管理している。
【０１００】
基本的に、シークエンスナンバーは、送信機１のＲＴＰヘッダ付加部２２により、ＲＴＰヘッダ４２が生成された順に番号（通常、昇順）が割り振られ、その生成された順番で、通信部２６から出力される。よって、基本的に、受信機２のナンバーチェック部６５においても、順次、連続したシークエンスナンバーのＲＴＰパケットが供給される。ここで、“基本的に”と記述したのは、何らかの原因で、シークエンスナンバーの番号順に送信されない、または、受信されないことがあるからである。そのような状況が発生した場合に対しても、後述する処理により対応できるようになっている。
【０１０１】
図１１のフローチャートの説明に戻り、ステップＳ１２において、ナンバーチェック部６５は、受信した（供給された）ＲＴＰパケットのＲＴＰヘッダ４２内のシークエンスナンバーは、管理している番号に１だけ加算した値である（すなわち、連続している番号である）か否かを判断する。
【０１０２】
ステップＳ１２において、供給されたＲＴＰパケットのＲＴＰヘッダ４２内のシークエンスナンバーは、連続している番号であると判断された場合、ステップＳ１３に処理が進められる。ステップＳ１２において、このように判断されるのは、正常に送信機１からのデータが受信され、処理されているときである。従って、正常に受信され、処理されているデータ（ＴＳパケット）が記憶部６８に記憶される処理が、ステップＳ１３において実行される。
【０１０３】
ナンバーチェック部６５は、供給されたＲＴＰパケットのＲＴＰヘッダ４２内のシークエンスナンバーは、連続している番号であると判断した場合、そのＲＴＰパケットを、順番再構成部６６に供給する。順番再構成部６６は、ＲＴＰパケットが供給されたとき、そのＲＴＰパケットのＲＴＰヘッダ４２を参照し、シークエンスナンバーを読み出す。その読み出したシークエンスナンバーに対応するＴＳパケットが、記憶部６８に記憶されているか否かをチェックする。
【０１０４】
この場合、連続している番号であると判断されたＲＴＰパケットであり、このことを換言すれば、新たに受信されたＲＴＰパケットであると判断されたことになる。従って、順番再構成部６６は、供給されたＲＴＰパケット内のＴＳパケットは、記憶部６８に記憶されていないと判断する。このような判断がされたときには、ＲＴＰパケットが、ＲＴＰヘッダ抽出部６７に供給される。
【０１０５】
ＲＴＰヘッダ抽出部６７は、供給されたＲＴＰパケットからＲＴＰヘッダ４２を抽出し、ＴＳパケットを、記憶部６８に供給し、記憶させる。この際、上述したように、ＴＳパケットは、ＲＴＰヘッダ４２に含まれるシークエンスナンバーと関連付けられて記憶される。
【０１０６】
一方、ステップＳ１２において、ナンバーチェック部６５が、供給されたＲＴＰヘッダ４２内のシークエンスナンバーは、管理している番号に、連続する番号ではないと判断した場合、ステップＳ１４に処理が進められる。ステップＳ１４において、ナンバーチェック部６５は、供給されたＲＴＰパケットに含まれるＲＴＰヘッダ４２内のシークエンスナンバーは、管理している番号より大きい番号であるか否かを判断する。
【０１０７】
ステップＳ１４において、ナンバーチェック部６５が、供給されたＲＴＰパケットに含まれるＲＴＰヘッダ４２内のシークエンスナンバーは、管理している番号より大きい番号ではないと判断した場合、換言すれば、小さい番号であると判断した場合、ステップＳ１５に処理が進められる。
【０１０８】
上述したように、送信機２から送信されてきたデータは、基本的に、シークエンスナンバーの番号順に受信され、処理されるので、ステップＳ１４において、ナンバーチェック部６５が、供給されたＲＴＰパケットに含まれるＲＴＰヘッダ４２内のシークエンスナンバーは、管理している番号より大きい番号ではないと判断することはない。しかしながら、何らかの原因で、送信される順番または、受信され、処理される順番が入れ違ってしまったために、このように、ステップＳ１４においてＮＯと判断され、ステップＳ１５に処理が進められることが考えられる。
【０１０９】
また、後述するステップＳ１７の処理が行われた結果、送信機１側から、その時点で、送信すべきシークエンスナンバーのデータよりも、若い番号のシークエンスナンバーのデータが再送されることがある。そのような再送が行われた結果、番号の若いシークエンスナンバーのデータが受信機２に、正常に受信され、処理されると、ステップＳ１４において、ＮＯと判断され、ステップＳ１５において処理が進められる場合もある。
【０１１０】
ステップＳ１４において、ナンバーチェック部６５は、供給されたＲＴＰヘッダ４２内のシークエンスナンバーは、管理している番号より大きい番号ではないと判断した場合、供給されたＲＴＰパケットを、順序再構成部６６に供給する。順序再構成部６６は、ステップＳ１５において、供給されたＲＴＰパケットに含まれているＴＳパケットは、既に、記憶部６８に記憶されているか否かを、記憶部６８を参照することにより判断する。
【０１１１】
図１０を参照して説明したように、記憶部６８には、正常に処理されたＴＳパケットが、シークエンスナンバーと関連付けられて記憶されている。そこで、順序再構成部６６は、供給されたＲＴＰヘッダ４２内のシークエンスナンバーを読み出し、その読み出したシークエンスナンバーに関連付けられたＴＳパケットが、記憶部６８に記憶されているか否かを判断する。
【０１１２】
このような処理を設ける理由について、図１３を参照して説明する。図１３Ａは、正常に、送受信が行われている状態を示している。図１３Ａに示すように、正常に送受信が行われている状態では、シークエンスナンバーが連続しているパケット（データ）が送信機１から送信され、受信機２で受信され処理される。図１３Ａに示した状態は、シークエンスナンバーが“９７”乃至“１０２”のパケットが、その順番で、送受信されていることを意味する。
【０１１３】
このような正常に送受信が行われている状態に対し、何らかの原因で、正常に送受信が行われていない状態を図１３Ｂに示す。図１３Ｂにおいては、シークエンスナンバー“９７”の後に、シークエンスナンバー“９９”のパケットが受信されている。このような状態が発生したとき、すなわち、シークエンスナンバーが連続せず、かつ、番号が、大きい番号に飛んだとき、再送要求が出される。この再送要求については、ステップＳ１７の処理として後述する。
【０１１４】
その後、シークエンスナンバー“１００”のパケットが受信される。シークエンスナンバー“１００”のパケットの次は、シークエンスナンバー“１０１”のパケットが受信されるはずであるが、シークエンスナンバー“９８”のパケットが受信されている。このシークエンスナンバー“９８”のパケットは、上述した再送要求が出された結果、送信機１からシークエンスナンバー“９８”のパケットが再送信され、受信機２に受信されたパケットであるか、または、送信機１側または受信機２側で、何らかの原因により、処理の順序が入れ替わってしまったために、シークエンスナンバー“１００”のパケットの後に受信されたパケットである。
【０１１５】
いずれにせよ、この時点では、シークエンスナンバー“９８”のパケットは、受信機２側では、始めて受信され、処理されたことになるため、記憶部６８には記憶されていない。すなわち、ステップＳ１５において、順序再構成部６６の処理により、記憶部６８には記憶されていないと判断されることになる。
【０１１６】
図１３Ｂを再度参照するに、シークエンスナンバー“９８”のパケットが記憶部６８に記憶された後、シークエンスナンバー“１０１”のパケットが受信され、記憶され、さらに、その後、シークエンスナンバー“９８”のパケットが受信される。このときのシークエンスナンバー“９８”のパケットも、上述したように、再送要求の結果により受信されたパケット、または、処理の入れ替わりが発生した結果により受信されたパケットである。
【０１１７】
いずれにせよ、シークエンスナンバー“１０１”のパケットの後に処理されるシークエンスナンバー“９８”のパケットと同一のパケットは、既に、シークエンスナンバー“１００”のパケットの後に受信され、処理され、記憶部６８に記憶されている。従って、このような場合、ステップＳ１５において、順序再構成部６６により、記憶部６８に記憶されていると判断されることになる。
【０１１８】
このように、同じシークエンスナンバーのパケットが、受信機２に受信され、処理される可能性があるために、ステップＳ１５の処理が行われる。ステップＳ１５において、記憶部６８に記憶されていると判断されたパケットは、上述した例では、シークエンスナンバー“９８”のパケットは、再度、記憶部６８に記憶させる必要はないので、ステップＳ１６に処理が進められ破棄される。
【０１１９】
一方、記憶部６８に記憶されていないと判断されたパケットは、ステップＳ１３に処理が進められ記憶部６８に記憶される。記憶部６８にパケットが記憶される際、その領域は、予めそのパケットが記憶されるとして用意されていた領域（その時点で記憶されているシークエンスナンバーに対応する領域）に記憶される。換言すれば、後に受信されたパケットも、本来受信されるべきタイミングで受信されたかのように、順番が入れ替えられて、記憶部６８に記憶される。この記憶の制御は、順序再構成部６６により行われる。
【０１２０】
次に、再送要求について説明する。再送要求の処理は、ステップＳ１７（図１１）において行われるが、ステップＳ１７に処理が進められるのは、ステップＳ１２において、ナンバーチェック部６５により、供給されたＲＴＰパケットのＲＴＰヘッダ４２に含まれるシークエンスナンバーは、管理している番号に連続する番号ではないと判断され、かつ、ステップＳ１４において、そのシークエンスナンバーは、管理している番号より大きい番号であると判断されたときである。
【０１２１】
図１３Ｂを再度参照するに、ナンバーチェック部６５に、シークエンスナンバー“９７”のＲＴＰパケットが供給された後に、シークエンスナンバー“９９”のＲＴＰパケットが供給された場合、このような判断が行われ、ステップＳ１７に処理が進められる。このような状況は、供給されるべきシークエンスナンバー“９８”のＲＴＰパケットが、供給されなかった（欠落した）状況を示している。
【０１２２】
ステップＳ１７において、再送要求の処理が実行される。ステップＳ１７において行われる再送要求の処理について、図１２のフローチャートを参照して説明する。この再送要求の処理とは、供給されるべきシークエンスナンバーのＲＴＰパケット、すなわち、欠落したと判断されるＲＴＰパケットを取得するために、送信機１に対して、その欠落していると判断されるＲＴＰパケットを再送するように要求を出す処理である。
【０１２３】
ナンバーチェック部６５は、ステップＳ３１において、欠落していると判断した番号を判断し、その判断した番号に関するデータを、ステップＳ３２の処理として、再送制御部７０に通知する。換言すると、ナンバーチェック部６５は、管理している番号から、供給されたＲＴＰパケットのシークエンスナンバーまでの番号を、欠落しているパケットの番号（シークエンスナンバー）として決定し、その決定した番号に関するデータを、再送制御部７０に通知する。
【０１２４】
例えば、図１３Ｂに示したような状況の場合、シークエンスナンバー“９８”が、欠落している番号として再送制御部７０に通知される。また、図示はしないが、例えば、管理している番号が“９７”で、供給されたＲＴＰパケットのシークエンスナンバーが“１２０”であるような場合、“９８”乃至“１１９”が、欠落している番号として再送制御部７０に通知される。すなわち、再送制御部７０に通知される番号は、１つとは限らない。
【０１２５】
再送制御部７０は、ナンバーチェック部６５からのデータを入力すると、ステップＳ３３において、計時部７１に計時を開始させる。再送制御部７０は、計時部７１に計時を開始させる際、欠落していると判断された番号に関するデータも供給する。そして、再送制御部７０は、ステップＳ３４において、送信機１に対して再送を要求するデータを、通信部６１により送信させる。
【０１２６】
通信部６１により送信される、再送を要求するデータについて説明する。このデータは、トランスポート層のプロトコルとして、ＴＣＰが用いられたパケットとして送信される。上述したように、送信機１から、図３に示したようなデータ（ＭＡＣパケット）が送信される際には、トランスポート層のプロトコルとしてＵＤＰが用いられたが、受信機２から送信される再送を要求するデータとしてのパケットは、ＴＣＰが用いられたものとされる。
【０１２７】
これは、確実に再送要求を、送信機１側に送信させるようにするためである。勿論、ＵＤＰを用いて再送要求を出すようにしても良いが、その再送要求自体が、確実に送信機１側に送信されたか否かを判断できない状況は好ましくない状況であると考えられる。そこで、本実施の形態においては、再送要求は、ＵＤＰではなく、ＴＣＰが用いられるとして説明する。
【０１２８】
ＴＣＰを用いて送信される再送要求のデータには、ステップＳ３１、ステップＳ３２の処理において、欠落した番号として判断された番号のデータとして、再送制御部７０に通知されたデータが少なくとも含まれる。
【０１２９】
このような再送要求のデータが送信機１に対して送信されると、ステップＳ１８（図１１）に処理が進められる。ステップＳ１８において、計時部７１は、所定の時間が経過したか否かを判断する。計時部７１は、上述したように、再送制御部７０の指示により、送信機１に対して送信要求が出された時点から、計時を開始している。
【０１３０】
その計時している時間が、一定の値になったか否かが、ステップＳ１８において判断される。ステップＳ１８において一定の時間が経過したと判断されると、ステップＳ１９に処理が進められる。ステップＳ１９において、計時部７１は、再送制御部７０から供給された欠落していると判断された番号に関するデータを参照し、その番号（シークエンスナンバー）に関連付けられて、ＴＳパケットが、記憶部６８に記憶されているか否かを判断する。
【０１３１】
ステップＳ１９において行われる判断について説明する。図１１と図１２に示したフローチャートを参照して説明している処理は、受信機２により受信されたデータ（ＭＡＣパケット）毎に行われている。従って、ステップＳ１８において、所定の時間が経過したか否かの判断が行われるが、その所定の時間が経過する間にも、受信機２には、パケットが順次受信され、図１１と図１２に示したフローチャートの処理が、その受信されたパケット毎に行われている。
【０１３２】
その順次受信され、処理されるパケット内には、ステップＳ１７の処理により出された再送要求に対応する処理として、送信機１が再送してきたパケットも含まれる可能性がある。再送が正常に行われ、正常に受信、処理されれば、記憶部６８に、その再送されてきたＴＳパケットが記憶されることになる。そこで、ステップＳ１９においては、そのように、再送要求に対応して再送されてきたＴＳパケットが、記憶部６８に記憶されているか否かが判断される。
【０１３３】
ステップＳ１９において、計時部７１が、記憶部６８には、再送されてきたＴＳパケットは記憶されていないと判断した場合、ステップＳ１７に処理が戻され、再度、再送要求が出される。この際、再送要求が出されるのは、記憶されていないＴＳパケットに対してのみである。
【０１３４】
すなわち、例えば、欠落していると判断されたパケットのシークエンスナンバーが、“１００”乃至“１２０”であり、その“１００”乃至“１２０”に対するパケットの再送要求が出された結果、ステップＳ１９の処理が実行される時点で、“１００”乃至“１１０”に対応するＴＳパケットが記憶部６８に記憶されているような場合には、“１１１”乃至“１２０”に対応するＴＳパケットの再送を要求する再送要求が、再度出される。
【０１３５】
このように、再送要求自体を、繰り返し出すようにすることにより、より確実に、欠落したパケット（データ）を取得できるようにする。
【０１３６】
ここで、図１１に示していないが、ステップＳ１９の処理の前または後に、ステップＳ１９の処理を打ち切るような判断の処理を入れる必要がある。ステップＳ１９において、再送要求したＴＳパケットが記憶部６８に記憶されていると判断されるまで、再送要求が繰り返し出される一方で、記憶部６８に記憶されているＴＳパケットは、順次、ＭＰＥＧデコーダ６９に供給される。
【０１３７】
図１０を再度参照するに、シークエンスナンバー“１”に関連付けられているＴＳパケット１−１乃至１−７が、ＭＰＥＧデコーダ６９に供給された後に、シークエンスナンバー“２”に関連付けられているＴＳパケット２−１乃至２−７がＭＰＥＧデコーダ６９に供給される。
【０１３８】
その後、シークエンスナンバー“３”に関連付けられているＴＳパケットが、ＭＰＥＧデコーダ６９に供給されるが、供給される時点で、記憶されていなければ、供給することができず、そのシークエンスナンバー“３”に関連付けられているＴＳパケットが供給されることなく、次のシークエンスナンバー“４”に関連付けられているＴＳパケット４−１乃至４−７が供給される。
【０１３９】
このようなことを換言すれば、シークエンスナンバー“４”に関連付けられているＴＳパケットがＭＰＥＧデコーダ６９に供給されるより前の時点までに、シークエンスナンバー“３”に関連付けられるＴＳパケットが、記憶部６８に記憶されなければ、その後の時点で、シークエンスナンバー“３”に関連付けられるＴＳパケットを取得する必要はなく、そのための処理も行われる必要はない。
【０１４０】
このようなことを考慮すれば、計時部７１により出される再送要求の処理は、欠落していると判断されているパケットを取得するまで繰り返えされる必要性はない。そこで、ステップＳ１９の前の処理として、例えば、所定の回数だけ、再送要求が出されたか否かを判断する処理を設ける。そして、所定の回数だけ、再送要求が出されたと判断された場合には、ステップＳ１９の処理を省略し、図１１，１２に示したフローチャートの処理を終了させる。すなわち、再送要求を出すという処理が中断される。
【０１４１】
または、ステップＳ１９の後に、所定の回数だけ、再送要求が出されたか否かの判断をする処理を設けても良い。ステップＳ１９の後に、そのような処理を設けたとしても、基本的に、上述した、ステップＳ１９の前に設けた場合と同様にして、再送要求を出すという処理が中断される。
【０１４２】
所定の回数の決定の仕方だが、記憶部６８の容量に基づいて決定される。例えば、記憶部６８には、１秒間分のデータが記憶できるだけの容量があり、ステップＳ１８における処理で用いられる所定の時間として１００ミリ秒と計時部７１に設定されている場合、１秒間の間に、１０回、ステップＳ１８の処理が行われることになる。
【０１４３】
よって、この場合、再送要求を中断するための判断が、ステップＳ１９の前に行われる場合、または、ステップＳ１９の後に行われる場合（ステップＳ１９でＮＯと判断された後に行われる場合）、その判断は、“１０回目の再送要求か？”といった判断となる。
【０１４４】
すなわち、１０回目の再送要求を出したとしても、その１０回目の再送要求に対応する処理として、データが受信されたとしても、既に、そのデータを必要とする処理は、そのデータがない状態のまま、ＭＰＥＧデコーダ６９で行われているため、１０回目の再送要求を出すのは無駄な処理となってしまう。よって、この場合、１０回目の再送要求が出されることなく、再送要求が中断されるような判断が、行われるようにすればよい。
【０１４５】
このように、再送要求を中断させるための判断として、再送要求を出した回数により制限をかけることも可能であるが、時間により制限をかけるようにしても良い。例えば、記憶部６８の記憶容量が、１秒間分のデータを記憶できるだけの容量である場合、計時部７１が計時を開始してから、１秒以上経過した後に出される再送要求は、実質的に、無駄な処理となることになる。
【０１４６】
そこで、計時部７１が、計時を開始してから所定の時間（この場合、１秒）だけ経過したか否かを、例えば、ステップＳ１８の処理とあわせて判断するようにし、時間により、再送要求を中断させるための判断を行うようにしても良い。
【０１４７】
なお、上述した実施の形態においては、計時部７１は、再送制御部７０からの指示があると計時を開始し、所定の時間が経過後、再送要求したＴＳパケットが記憶部６８に記憶されていなければ、再度、再送要求を出すとしたが、計時部７１は、再送制御部７０からの指示にかかわらず、計時を行うようにしても良い。
【０１４８】
計時部７１が、常に計時を行うようにした場合、所定の周期毎（例えば、１００ミリ秒毎）に、記憶部６８を参照し、シークエンスナンバーは記憶されているが、そのシークエンスナンバーに関連付けられてＴＳパケットは記憶されていないと判断されるシークエンスナンバーを抽出するようにする。そして、抽出されたシークエンスナンバーのデータが再送制御部７０に供給されると共に、再送要求を出すように指示が出されるようにしても良い。
【０１４９】
このようにして、受信機２側で、欠落しているパケット（データ）を判断し、その欠落しているパケットを取得するために、その欠落しているパケットを再度送信するように再送要求が、送信機１側に出される。このような再送要求が出されることにより、何らかの原因で、受信機２側がパケットを受信（処理）できなかったとしても、その欠落したパケットを取得することが可能となる。
【０１５０】
また、欠落したパケットを受信機２側で判断することにより、送信機１側で、欠落したパケットを判断するより（例えば、ＡＣＫ信号を受信したか否かを判断することにより、欠落したパケットを判断するより）、送信側および受信側の双方で、再送にかかわる無駄な処理が実行されてしまうようなことを防ぐことが可能となる。換言すれば、より適切に再送の処理を送信側および受信側で行えるようになる。
【０１５１】
このような処理が、受信機２側で行われるようにするには、送信機１側は、再送要求が出されたときに、その再送が要求されたデータを送信できるように構成されていなければならない。そこで、図２に示したように、送信機１は、再送するためのデータを記憶するための記憶部２８を有している。
【０１５２】
図１４のフローチャートを参照して、送信機１が行う、再送要求に対応する処理について説明する。ステップＳ５１において、送信機１は、ＲＴＰヘッダ付加部２２から出力されたＲＴＰパケットを、記憶部２８に記憶する。記憶部２８は、受信機２の記憶部６８がＴＳパケットを記憶する容量と同じ、または、それ以上の容量を有する。
【０１５３】
記憶部２８は、上述したように、ＲＴＰパケットを記憶する。従って、ＲＴＰパケット内のＲＴＰヘッダ４２のシークエンスナンバーにより、記憶されているＲＴＰパケットを識別することが可能である。なお、記憶部２８に記憶されているＲＴＰパケットは、順次、若い番号のシークエンスナンバーを有するＲＴＰパケットから削除され、新たなＲＴＰパケットが記憶できるように構成されている。その削除されるタイミングやデータ量は、記憶部２８の容量を考慮して決定されればよい。
【０１５４】
ＲＴＰヘッダ付加部２２からのＲＴＰパケットは、ＵＤＰヘッダ２３、ＩＰヘッダ付加部２４、およびＭＡＣヘッダ付加部２５の各部で、それぞれのヘッダが付加される。
【０１５５】
そして、通信部２６により、受信機２側に、ＭＡＣパケットとして送信される。このような送信が行われた後も、記憶部２８には、送信されたＭＡＣパケットに含まれるＲＴＰパケットが記憶されている。
【０１５６】
ステップＳ５２において、再送要求を受けたか否かが判断される。この判断は、通信部２６において受信されたデータを、再送制御部２７が参照することにより行われる。このデータは、上述したように、ＴＣＰに基づく通信により受信機２から送信されてきたデータである。
【０１５７】
ステップＳ５２において、受信されたデータは、再送を要求するデータであると判断された場合、ステップＳ５３に処理が進められる。ステップＳ５３において、受信されたデータ内が解析されることにより、再送が要求されているシークエンスナンバー（番号）が特定される。
【０１５８】
シークエンスナンバーの特定が、再送制御部２７により行われると、ステップＳ５４において、その特定されたシークエンスナンバーを有するＲＴＰパケットが、記憶部２８から読み出される。記憶部２８から読み出されたＲＴＰパケットは、ＵＤＰヘッダ付加部２３に供給される。このような制御は、再送制御部２７により行われる。
【０１５９】
ＵＤＰヘッダ付加部２３に供給されたＲＴＰパケットは、ＵＤＰヘッダ付加部２３以降の各部において、ヘッダが付加され、通信部２６により受信機２に対して送信される（ステップＳ５５，Ｓ５６）。
【０１６０】
このようにして、送信機１は、再送の要求があったときに、その要求に対応するために、記憶部２８からＲＴＰパケットを読み出し、再度、受信機２に対して送信を行う。このような処理が、送信機１側で行われることにより、受信機２側では、欠落したと判断されるパケットを取得することができる。
【０１６１】
このように、本発明によれば、ＵＤＰを用いた通信を行うことにより、通信にかかる処理を軽減させることが可能になり、リアルタイムな処理を要求される通信にも対応することが可能となるとともに、受信機２側で、欠落したパケットを取得するための処理が実行されることにより、その通信の信頼性を向上させることが可能となる。
【０１６２】
なお、上述した実施の形態においては、ＲＴＰヘッダ４２に含まれるシークエンスナンバーが用いられて、欠落したパケットが取得されるための処理が行われるとして説明した。このように、ＲＴＰヘッダ４２に含まれるシークエンスナンバーが用いられて、欠落したパケットが取得されるための処理が行われるようにすることにより、通信の過程で発生するパケット落ちだけでなく、送信機１または受信機２の予期されぬ不具合により発生したパケット落ちに対しても対処することができるようになる。
【０１６３】
仮に、送信機１側で、不具合が発生したために、所定の番号のシークエンスナンバーを含むデータが、受信機２側に送信されなかったとする。または、受信機２側で、不具合が発生したために、所定の番号のシークエンスナンバーを含むデータが受信されなかったとする。
【０１６４】
そのような場合、本発明を適用した受信機２は、上述したように、受信できなかったシークエンスナンバーを含むデータを再送するように要求を出すようになっている。しかしながら、ＲＴＰを用いず、従って、シークエンスナンバーを用いずに、通信が行われた場合、受信されなかったデータ（再送を要求するデータ）を特定することができない。従って、仮に、受信機２側から、再送要求を出したしても、送信機１側では、どのデータを再送すれば良いかわからず、結果として、再送できないということなる。
【０１６５】
再送の要求だけなら、無線にかかわるプロトコルにおけるリトライの処理だけでも行うことは可能であるが、再送させるデータを特定するというのは、無線にかかわるプロトコルではカバーできない。よって、本実施の形態のように、ＲＴＰを用いた通信を行うことで、上述したような、再送の処理を実行させることが可能となり、より確実に、欠落したデータを取得できるようにすることにより、より通信の信頼性を向上させることが可能となる。
【０１６６】
また、“Ｓｅｑｕｅｎｃｅ Ｎｕｍｂｅｒ”と“Ｔｉｍｅ Ｓｔａｍｐ”（図５）を併用することにより、図１１のステップＳ１１において、初期値の設定を行うために、受信されたデータが、新しいストリーミングのものであるか否かの判断、すなわち、新たなストリーミングの識別を容易に行うことが可能となる。
【０１６７】
例えば、シークエンスナンバーが連続していても、“Ｔｉｍｅ Ｓｔａｍｐ”が不連続になっているような場合には、新たなストリーミングであると識別することができる。また、複数のストリーミングが同時に流れているような環境下で、送信機１が、各ストリーミングに対して、“Ｔｉｍｅ Ｓｔａｍｐ”をずらした状態で、送信することで、受信機２は、受信された複数のストリーミングから、選択的に、１つのストリーミングを選択し、かつ、上述したような再送の要求を出すことが可能となる。
【０１６８】
なお、上述した実施の形態においては、送信機１は、アナログ信号のテレビジョン放送を受信し、処理するとして説明したが、デジタル信号のテレビジョン放送を受信し、処理する装置であっても良く、そのようにした場合でも、本発明を適用することが可能である。
【０１６９】
送信機１を、デジタル信号のテレビジョン放送を受信し、処理するようにした場合、受信するデータ自体が、既にパケット化されており、また、複数のヘッダが付加されている状態であるので、エンコードや所定のヘッダを付加する処理などを省略し、それらのヘッダのうちの所定の内容を書き換えるなどの処理を施すことにより、上述した発明を適用することが可能である。
【０１７０】
上述した一連の処理（例えば、再送にかかわる処理）は、それぞれの機能を有するハードウェアにより実行させることもできるが、ソフトウェアにより実行させることもできる。一連の処理をソフトウェアにより実行させる場合には、そのソフトウェアを構成するプログラムが専用のハードウェアに組み込まれているコンピュータ、または、各種のプログラムをインストールすることで、各種の機能を実行することが可能な、例えば汎用のパーソナルコンピュータなどに、記録媒体からインストールされる。
【０１７１】
記録媒体について説明する前に、記録媒体をデータを書き込む、または、読み出すパーソナルコンピュータについて説明する。図１５は、汎用のパーソナルコンピュータの内部構成例を示す図である。パーソナルコンピュータのＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）１０１は、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）１０２に記憶されているプログラムに従って各種の処理を実行する。ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）１０３には、ＣＰＵ１０１が各種の処理を実行する上において必要なデータやプログラムなどが適宜記憶される。入出力インタフェース１０５は、キーボードやマウスから構成される入力部１０６が接続され、入力部１０６に入力された信号をＣＰＵ１０１に出力する。また、入出力インタフェース１０５には、ディスプレイやスピーカなどから構成される出力部１０７も接続されている。
【０１７２】
さらに、入出力インタフェース１０５には、ハードディスクなどから構成される記憶部１０８、および、インターネットなどのネットワークを介して他の装置とデータの授受を行う通信部１０９も接続されている。ドライブ１１０は、磁気ディスク１２１、光ディスク１２２、光磁気ディスク１２３、半導体メモリ１２４などの記録媒体からデータを読み出したり、データを書き込んだりするときに用いられる。
【０１７３】
記録媒体は、図１５に示すように、パーソナルコンピュータとは別に、ユーザにプログラムを提供するために配布される、プログラムが記録されている磁気ディスク１２１（フレキシブルディスクを含む）、光ディスク１２２（ＣＤ−ＲＯＭ（Ｃｏｍｐａｃｔ Ｄｉｓｃ−Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ），ＤＶＤ（Ｄｉｇｉｔａｌ Ｖｅｒｓａｔｉｌｅ Ｄｉｓｃ）を含む）、光磁気ディスク１２３（ＭＤ（Ｍｉｎｉ−Ｄｉｓｃ）（登録商標）を含む）、若しくは半導体メモリ１２４などよりなるパッケージメディアにより構成されるだけでなく、コンピュータに予め組み込まれた状態でユーザに提供される、プログラムが記憶されているＲＯＭ１０２や記憶部１０８が含まれるハードディスクなどで構成される。
【０１７４】
なお、本明細書において、媒体により提供されるプログラムを記述するステップは、記載された順序に従って、時系列的に行われる処理は勿論、必ずしも時系列的に処理されなくとも、並列的あるいは個別に実行される処理をも含むものである。
【０１７５】
また、本明細書において、システムとは、複数の装置により構成される装置全体を表すものである。
【０１７６】
【発明の効果】
本発明によれば、何らかの原因で、送信または受信できなかったデータを、受信側で取得することができる。
【０１７７】
また、本発明によれば、何らかの原因で、送信または受信できなかったデータを、特定して、受信側から、送信側に対して、再送するように要求を出すことができる。その要求に送信側の装置が対応することにより、受信側は、受信できなかったデータを取得することができる。
【０１７８】
さらに、本発明によれば、ＵＤＰを用いた通信においても、欠落したパケットを、受信側で、取得することが可能となる。
【図面の簡単な説明】
【図１】本発明を適用した送受信システムの一実施の形態の構成を示す図である。
【図２】送信機の内部構成例を示す図である。
【図３】送信機から送信されるデータについて説明するための図である。
【図４】ＴＳパケットのヘッダについて説明するための図である。
【図５】ＲＴＰヘッダについて説明するための図である。
【図６】ＵＤＰヘッダについて説明するための図である。
【図７】ＩＰヘッダについて説明するための図である。
【図８】ＭＡＣヘッダについて説明するための図である。
【図９】受信機の内部構成例を示す図である。
【図１０】記憶部に記憶されているデータについて説明するための図である。
【図１１】受信機において行われる再送要求にかかわる処理について説明するためのフローチャートである。
【図１２】図１１に示したフローチャートのステップＳ１７における処理について説明するためのフローチャートである。
【図１３】受信されるシークエンスナンバーの関係について説明するための図である。
【図１４】送信機において行われる再送要求にかかわる処理について説明するためのフローチャートである。
【図１５】媒体を説明する図である。
【符号の説明】
１ 送信機， ２１ ＭＰＥＧエンコーダ， ２２ ＲＴＰヘッダ付加部， ２３ ＵＤＰヘッダ付加部， ２４ ＩＰヘッダ付加部， ２５ ＭＡＣヘッダ付加部， ２６ 通信部， ２７ 再送制御部， ２８ 記憶部， ６１ 通信部， ６２ ＭＡＣヘッダ抽出部， ６３ ＩＰヘッダ抽出部， ６４ ＵＤＰヘッダ抽出部， ６５ ナンバーチェック部， ６６ 順序再構成部， ６７ ＲＴＰヘッダ抽出部， ６８ 記憶部， ６９ ＭＰＥＧデコーダ， ７０ 再生制御部， ７１ 計時部
Claims (16)
- データを送信する送信装置と、前記送信装置から送信された前記データを受信する受信装置から構成される送受信システムにおいて、
前記送信装置は、
前記データを取得する取得手段と、
前記取得手段により取得された前記データに、前記データの順序を示す情報を付加する付加手段と、
前記付加手段により前記情報が付加された前記データを記憶する記憶手段と、
前記付加手段により前記情報が付加された前記データを前記受信装置に送信する送信手段と、
前記送信手段により送信された前記データの再送が、前記受信装置から要求された場合、その再送が要求されたデータを前記記憶手段から読み出し、前記送信手段に、前記読み出されたデータの再送を指示する再送手段と
を備え、
前記受信装置は、
前記送信手段により送信された前記データを受信する受信手段と、
前記受信手段により受信された前記データに含まれる前記情報を抽出し、その情報を用いて、前記データの欠落があるか否かを判断する判断手段と、
前記判断手段により、前記データの欠落があると判断された場合、欠落していると判断されるデータを特定する特定手段と、
前記特定手段により特定された前記欠落していると判断されるデータの再送を前記送信装置に要求する要求手段と
を備える
ことを特徴とする送受信システム。 - データを取得する取得手段と、
前記取得手段により取得された前記データに、前記データの順序を示す情報を付加する付加手段と、
前記付加手段により前記情報が付加された前記データを記憶する記憶手段と、前記付加手段により前記情報が付加された前記データを送信する送信手段と、前記送信手段により送信された前記データの再送が、他の装置から要求された場合、その再送が要求されたデータを前記記憶手段から読み出し、前記送信手段に、前記読み出されたデータの再送を指示する再送手段と
を備えることを特徴とする送信装置。 - 前記付加手段は、前記情報として、ＲＴＰに基づくヘッダを少なくとも付加し、
前記記憶手段は、前記ＲＴＰのヘッダが付加された前記データを記憶する
ことを特徴とする請求項２に記載の送信装置。 - 前記他の装置からの前記データの再送の要求には、前記ＲＴＰに基づくヘッダに含まれるＳｅｑｕｅｎｃｅ Ｎｕｍｂｅｒの情報が含まれ、
前記再送手段は、前記ヘッダに含まれる前記Ｓｅｑｕｅｎｃｅ Ｎｕｍｂｅｒの情報と一致するＳｅｑｕｅｎｃｅ Ｎｕｍｂｅｒを含むヘッダが付加された前記データを前記記憶手段から読み出す
ことを特徴とする請求項３に記載の送信装置。 - データの取得を制御する取得制御ステップと、
前記取得制御ステップの処理で取得が制御された前記データに、前記データの順序を示す情報を付加する付加ステップと、
前記付加ステップの処理で前記情報が付加された前記データの記憶を制御する記憶制御ステップと、
前記付加ステップの処理で前記情報が付加された前記データの送信を制御する送信制御ステップと、
前記送信制御ステップの処理で送信が制御された前記データの再送が、他の装置から要求された場合、その再送が要求されたデータを前記記憶制御ステップの処理で記憶が制御された前記データ内から読み出し、前記送信制御ステップの処理に、前記読み出されたデータの再送を指示する再送ステップと
を含むことを特徴とする送信方法。 - データの取得を制御する取得制御ステップと、
前記取得制御ステップの処理で取得が制御された前記データに、前記データの順序を示す情報を付加する付加ステップと、
前記付加ステップの処理で前記情報が付加された前記データの記憶を制御する記憶制御ステップと、
前記付加ステップの処理で前記情報が付加された前記データの送信を制御する送信制御ステップと、
前記送信制御ステップの処理で送信が制御された前記データの再送が、他の装置から要求された場合、その再送が要求されたデータを前記記憶制御ステップの処理で記憶が制御された前記データ内から読み出し、前記送信制御ステップの処理に、前記読み出されたデータの再送を指示する再送ステップと
を含むことを特徴とするコンピュータが読み取り可能なプログラムが記録されている記録媒体。 - データの取得を制御する取得制御ステップと、
前記取得制御ステップの処理で取得が制御された前記データに、前記データの順序を示す情報を付加する付加ステップと、
前記付加ステップの処理で前記情報が付加された前記データの記憶を制御する記憶制御ステップと、
前記付加ステップの処理で前記情報が付加された前記データの送信を制御する送信制御ステップと、
前記送信制御ステップの処理で送信が制御された前記データの再送が、他の装置から要求された場合、その再送が要求されたデータを前記記憶制御ステップの処理で記憶が制御された前記データ内から読み出し、前記送信制御ステップの処理に、前記読み出されたデータの再送を指示する再送ステップと
を含む処理をコンピュータに実行させることを特徴とするプログラム。 - データを受信する受信手段と、
前記受信手段により受信された前記データに含まれる所定の情報を抽出し、その情報を用いて、前記データの欠落があるか否かを判断する判断手段と、
前記判断手段により、前記データの欠落があると判断された場合、欠落していると判断されるデータを特定する特定手段と、
前記特定手段により特定された前記欠落していると判断されるデータの再送を前記データを送信してきた他の装置に要求する要求手段と
を備えることを特徴とする受信装置。 - 前記要求手段により前記要求が出されたときから計時を開始する計時手段と、
前記計時手段による計時が、所定の時間を経過する毎に、再度要求を出すように前記要求手段に指示する指示手段と
をさらに含むことを特徴とする請求項８に記載の受信装置。 - 前記判断手段は、前記所定の情報として前記データに含まれるＲＴＰに基づくヘッダを抽出し、そのヘッダに含まれるＳｅｑｕｅｎｃｅ Ｎｕｍｂｅｒの情報を用いて、前記データの欠落があるか否かを判断する
ことを特徴とする請求項８に記載の受信装置。 - 前記判断手段は、前記ヘッダに含まれていた前記Ｓｅｑｕｅｎｃｅ Ｎｕｍｂｅｒのうち、最も大きい番号の第１のＳｅｑｕｅｎｃｅ Ｎｕｍｂｅｒを記憶し、その記憶している第１のＳｅｑｕｅｎｃｅ Ｎｕｍｂｅｒと、新たに供給されたヘッダに含まれる第２のＳｅｑｕｅｎｃｅ Ｎｕｍｂｅｒが連続している番号ではなく、かつ、前記第１のＳｅｑｕｅｎｃｅ Ｎｕｍｂｅｒの方が前記第２のＳｅｑｕｅｎｃｅ Ｎｕｍｂｅｒより小さい番号であると判断したとき、前記データが欠落していると判断し、
前記特定手段は、前記第１のＳｅｑｕｅｎｃｅ Ｎｕｍｂｅｒから前記第２のＳｅｑｕｅｎｃｅ Ｎｕｍｂｅｒまでに位置する番号の第３のＳｅｑｕｅｎｃｅ Ｎｕｍｂｅｒを前記ヘッダに含む前記データを、欠落していると判断されるデータであると特定し、
前記要求手段は、前記欠落されていると判断されるデータの再送を、前記第３のＳｅｑｕｅｎｃｅ Ｎｕｍｂｅｒの情報を含むデータを前記他の装置に送信することにより要求する
ことを特徴とする請求項１０に記載の受信装置。 - 前記要求手段は、前記前記第３のＳｅｑｕｅｎｃｅ Ｎｕｍｂｅｒの情報を含むデータを、ＴＣＰに基づいて送信する
ことを特徴とする請求項１１に記載の受信装置。 - 前記判断手段は、前記第１のＳｅｑｕｅｎｃｅ Ｎｕｍｂｅｒと、前記第２のＳｅｑｕｅｎｃｅ Ｎｕｍｂｅｒが連続している番号ではなく、かつ、前記第１のＳｅｑｕｅｎｃｅ Ｎｕｍｂｅｒの方が前記第２のＳｅｑｕｅｎｃｅ Ｎｕｍｂｅｒより大きい番号であると判断したとき、その第２のＳｅｑｕｅｎｃｅ Ｎｕｍｂｅｒを含むデータは、再送されてきたデータであると判断する
ことを特徴とする請求項１０に記載の受信装置。 - データの受信を制御する受信制御ステップと、
前記受信制御ステップの処理で受信された前記データに含まれる所定の情報を抽出し、その情報を用いて、前記データの欠落があるか否かを判断する判断ステップと、
前記判断ステップの処理により、前記データの欠落があると判断された場合、欠落していると判断されるデータを特定する特定ステップと、
前記特定ステップの処理で特定された前記欠落していると判断されるデータの再送を前記データを送信してきた他の装置に要求する要求ステップと
を含むことを特徴とする受信方法。 - データの受信を制御する受信制御ステップと、
前記受信制御ステップの処理で受信された前記データに含まれる所定の情報を抽出し、その情報を用いて、前記データの欠落があるか否かを判断する判断ステップと、
前記判断ステップの処理により、前記データの欠落があると判断された場合、欠落していると判断されるデータを特定する特定ステップと、
前記特定ステップの処理で特定された前記欠落していると判断されるデータの再送を前記データを送信してきた他の装置に要求する要求ステップと
を含むことを特徴とするコンピュータが読み取り可能なプログラムが記録されている記録媒体。 - データの受信を制御する受信制御ステップと、
前記受信制御ステップの処理で受信された前記データに含まれる所定の情報を抽出し、その情報を用いて、前記データの欠落があるか否かを判断する判断ステップと、
前記判断ステップの処理により、前記データの欠落があると判断された場合、欠落していると判断されるデータを特定する特定ステップと、
前記特定ステップの処理で特定された前記欠落していると判断されるデータの再送を前記データを送信してきた他の装置に要求する要求ステップと
を含む処理をコンピュータに実行させることを特徴とするプログラム。
Priority Applications (6)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2003053796A JP2004266504A (ja) | 2003-02-28 | 2003-02-28 | 送受信システム、送信装置および方法、受信装置および方法、記録媒体、並びにプログラム |
| KR1020057015943A KR101001514B1 (ko) | 2003-02-28 | 2004-02-19 | 송수신 시스템 및 수신 장치 |
| CNA2004800054453A CN1754364A (zh) | 2003-02-28 | 2004-02-19 | 发射/接收系统、发射设备和方法及接收设备和方法 |
| US10/547,212 US20060245428A1 (en) | 2003-02-28 | 2004-02-19 | Transmisssion/reception system, transmitting device and method, and receiving device and method |
| EP04712757A EP1599003A4 (en) | 2003-02-28 | 2004-02-19 | SENDING / RECEIVING SYSTEM, TRANSMISSION DEVICE AND METHOD AND RECEPTION DEVICE AND METHOD |
| PCT/JP2004/001947 WO2004077780A1 (ja) | 2003-02-28 | 2004-02-19 | 送受信システム、送信装置および方法、受信装置および方法 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2003053796A JP2004266504A (ja) | 2003-02-28 | 2003-02-28 | 送受信システム、送信装置および方法、受信装置および方法、記録媒体、並びにプログラム |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| JP2004266504A true JP2004266504A (ja) | 2004-09-24 |
Family
ID=32923446
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2003053796A Pending JP2004266504A (ja) | 2003-02-28 | 2003-02-28 | 送受信システム、送信装置および方法、受信装置および方法、記録媒体、並びにプログラム |
Country Status (6)
| Country | Link |
|---|---|
| US (1) | US20060245428A1 (ja) |
| EP (1) | EP1599003A4 (ja) |
| JP (1) | JP2004266504A (ja) |
| KR (1) | KR101001514B1 (ja) |
| CN (1) | CN1754364A (ja) |
| WO (1) | WO2004077780A1 (ja) |
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2008060817A (ja) * | 2006-08-30 | 2008-03-13 | Ttt Kk | 通信システム、ウェブサーバ装置、クライアント装置、通信を行うための通信プログラム及びプログラムを記録した記録媒体 |
| EP1959602A2 (en) | 2007-02-13 | 2008-08-20 | Seiko Epson Corporation | Transmitting and receiving method, transmitting and receiving system, transmitting apparatus, and receiving apparatus |
| JP2011223269A (ja) * | 2010-04-08 | 2011-11-04 | Central Res Inst Of Electric Power Ind | 監視制御方法及び監視制御システム |
Families Citing this family (25)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7792134B2 (en) * | 2004-04-30 | 2010-09-07 | Alcatel-Lucent Usa Inc. | Method and apparatus for detecting an uplink packet data channel in a CDMA wireless communications system |
| US8755407B2 (en) * | 2005-02-18 | 2014-06-17 | Qualcomm Incorporated | Radio link protocols for enhancing efficiency of multi-link communication systems |
| US7808985B2 (en) * | 2006-11-21 | 2010-10-05 | Gigle Networks Sl | Network repeater |
| TWI307226B (en) * | 2006-02-23 | 2009-03-01 | Ind Tech Res Inst | Multicast packet transmitting method of wireless network |
| JP2008098798A (ja) * | 2006-10-10 | 2008-04-24 | Nec Corp | 通信システムにおけるデータ伝送状況判定方法および通信装置 |
| US8520673B2 (en) * | 2006-10-23 | 2013-08-27 | Telcordia Technologies, Inc. | Method and communication device for routing unicast and multicast messages in an ad-hoc wireless network |
| CN101174995B (zh) * | 2006-11-03 | 2010-05-12 | 中兴通讯股份有限公司 | 一种多媒体服务性能监测的方法和系统 |
| CN1972166B (zh) * | 2006-11-30 | 2011-05-25 | 中兴通讯股份有限公司 | 一种移动多媒体广播系统的音频流传送方法 |
| US7680090B2 (en) * | 2007-02-28 | 2010-03-16 | Freescale Semiconductor, Inc. | System and method for monitoring network traffic |
| CN101227497B (zh) * | 2008-02-03 | 2012-05-02 | 北京天碁科技有限公司 | MAC-e PDU构造和解析方法 |
| US8346218B2 (en) * | 2008-05-02 | 2013-01-01 | International Business Machines Corporation | Avoiding redundant transmissions of data during multimedia mobile phone communications |
| WO2010034528A1 (en) * | 2008-09-26 | 2010-04-01 | Telefonaktiebolaget Lm Ericsson (Publ) | Techniques for uplink cooperation of access nodes |
| CN101800632A (zh) * | 2009-02-09 | 2010-08-11 | 中兴通讯股份有限公司 | 用户数据报协议传输模式下丢包补偿方法与装置 |
| US8385338B2 (en) * | 2009-04-24 | 2013-02-26 | Futurewei Technologies, Inc. | Implementation to avoid the acknowledgement-implosion in a multicast group |
| CN102130763B (zh) * | 2011-03-18 | 2014-08-13 | 中兴通讯股份有限公司 | 以太网传输的线序调整装置和方法 |
| JP6064522B2 (ja) * | 2012-10-30 | 2017-01-25 | 富士通株式会社 | 通信装置及び通信方法 |
| KR101533056B1 (ko) * | 2014-06-25 | 2015-07-01 | (주)넷텐션 | 안정성 향상을 위한 사용자 데이터그램 프로토콜 네트워킹 방법 |
| CN106603481A (zh) * | 2016-07-22 | 2017-04-26 | 深圳曼塔智能科技有限公司 | 数据传输方法及装置 |
| CN107979449B (zh) * | 2016-10-25 | 2020-11-20 | 杭州海康威视数字技术股份有限公司 | 一种数据传输方法及装置 |
| CN109842856A (zh) * | 2017-11-29 | 2019-06-04 | 成都鼎桥通信技术有限公司 | 一种屏蔽上行丢包的方法和设备 |
| CN110659247A (zh) * | 2018-06-13 | 2020-01-07 | 中国移动通信集团江西有限公司 | 话单文件连续性检测方法、装置、设备及介质 |
| TW202101946A (zh) * | 2019-06-14 | 2021-01-01 | 日商索尼半導體解決方案公司 | 通信裝置及通信方法以及程式 |
| US11778306B2 (en) * | 2020-01-08 | 2023-10-03 | Innolux Corporation | Method for editing an image |
| KR102334877B1 (ko) * | 2020-07-14 | 2021-12-03 | 주식회사 픽스트리 | 실시간 전송 프로토콜 패킷 재정렬 시스템 및 방법 |
| US11711320B2 (en) * | 2021-07-12 | 2023-07-25 | Mellanox Technologies, Ltd. | Network device safety protocol |
Family Cites Families (31)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US733439A (en) * | 1903-01-10 | 1903-07-14 | Nicholson File Company | Machine for grinding file-blanks or the like. |
| JP2769012B2 (ja) * | 1990-02-28 | 1998-06-25 | 富士通株式会社 | セル抜け誤配送検出および訂正方法 |
| JPH07111503A (ja) * | 1993-10-12 | 1995-04-25 | Hitachi Ltd | データ伝送方法およびデータ伝送システム |
| US5754754A (en) * | 1995-07-26 | 1998-05-19 | International Business Machines Corporation | Transmission order based selective repeat data transmission error recovery system and method |
| US5862133A (en) * | 1996-08-02 | 1999-01-19 | Golden Bridge Technology | Packet-switched spread-spectrum system |
| US5918002A (en) * | 1997-03-14 | 1999-06-29 | Microsoft Corporation | Selective retransmission for efficient and reliable streaming of multimedia packets in a computer network |
| JPH10262093A (ja) | 1997-03-19 | 1998-09-29 | Hitachi Ltd | 伝送制御方法 |
| US6031818A (en) * | 1997-03-19 | 2000-02-29 | Lucent Technologies Inc. | Error correction system for packet switching networks |
| US6076114A (en) * | 1997-04-18 | 2000-06-13 | International Business Machines Corporation | Methods, systems and computer program products for reliable data transmission over communications networks |
| US6701372B2 (en) * | 1997-08-22 | 2004-03-02 | Canon Kabushiki Kaisha | Data communication apparatus and method |
| JPH11225182A (ja) * | 1998-02-06 | 1999-08-17 | Kokusai Electric Co Ltd | 情報表示システム及びその制御方法 |
| US6081847A (en) * | 1998-02-27 | 2000-06-27 | Lsi Logic Corporation | System and method for efficient initialization of a ring network |
| US6076181A (en) * | 1998-03-03 | 2000-06-13 | Nokia Mobile Phones Limited | Method and apparatus for controlling a retransmission/abort timer in a telecommunications system |
| DE69938094T2 (de) * | 1998-11-30 | 2009-02-05 | Matsushita Electric Industries Co. Ltd., Kadoma | Paketwiederübertragungskontrolle mit Prioritätsinformationen |
| KR100424654B1 (ko) * | 1999-08-02 | 2004-03-24 | 삼성전자주식회사 | 이동 통신시스템에서 라디오링크프로토콜에 따른 데이터 재전송 장치 및 방법 |
| JP2001211145A (ja) | 2000-01-25 | 2001-08-03 | Mitsubishi Electric Corp | 伝送システム及び伝送方法 |
| DE10007602A1 (de) * | 2000-02-18 | 2001-08-30 | Siemens Ag | Verfahren zum Übertragen von Paketdateninformationen in einem Funk-Kommunikationssystem |
| JP2001298479A (ja) * | 2000-04-12 | 2001-10-26 | Nec Corp | インターネット電話装置 |
| JP3866196B2 (ja) * | 2000-06-23 | 2007-01-10 | 三菱電機株式会社 | パケット再送システムおよびパケット再送方法 |
| JP3348080B1 (ja) * | 2000-07-07 | 2002-11-20 | 松下電器産業株式会社 | データ送信装置とデータ受信装置及びデータ送受信方法 |
| JP3821778B2 (ja) * | 2000-10-05 | 2006-09-13 | 三菱電機株式会社 | パケット再送方式及び送信装置及び受信装置及びパケット再送方法及びパケット送信方法及びパケット受信方法 |
| US6807156B1 (en) * | 2000-11-07 | 2004-10-19 | Telefonaktiebolaget Lm Ericsson (Publ) | Scalable real-time quality of service monitoring and analysis of service dependent subscriber satisfaction in IP networks |
| FR2825865A1 (fr) * | 2001-06-06 | 2002-12-13 | Koninkl Philips Electronics Nv | Retransmission selective de paquets avec controle temporel a l'emission |
| JP4767443B2 (ja) * | 2001-07-04 | 2011-09-07 | 富士通株式会社 | ネットワーク蓄積型ビデオカメラシステム |
| US7117521B2 (en) * | 2001-08-31 | 2006-10-03 | Intel Corporation | Method to measure the perceived quality of streaming media |
| SE0103506D0 (sv) * | 2001-10-19 | 2001-10-19 | Ericsson Telefon Ab L M | HARQ stall avoidance |
| JP2003152544A (ja) * | 2001-11-12 | 2003-05-23 | Sony Corp | データ通信システム、データ送信装置、データ受信装置、および方法、並びにコンピュータ・プログラム |
| JP3799285B2 (ja) * | 2002-03-29 | 2006-07-19 | Ｎｅｃインフロンティア株式会社 | 無線ｌａｎ基地局、無線端末およびプログラム |
| US7233573B2 (en) * | 2003-02-08 | 2007-06-19 | Hewlett-Packard Development Company, L.P. | Apparatus and method for receiving data from a network |
| US20040165585A1 (en) * | 2003-02-25 | 2004-08-26 | Koji Imura | Packet transmission apparatus and packet transmission method |
| US20060029367A1 (en) * | 2004-08-03 | 2006-02-09 | Takuya Kosugi | Sequence header identification |
-
2003
- 2003-02-28 JP JP2003053796A patent/JP2004266504A/ja active Pending
-
2004
- 2004-02-19 WO PCT/JP2004/001947 patent/WO2004077780A1/ja active Application Filing
- 2004-02-19 US US10/547,212 patent/US20060245428A1/en not_active Abandoned
- 2004-02-19 CN CNA2004800054453A patent/CN1754364A/zh active Pending
- 2004-02-19 EP EP04712757A patent/EP1599003A4/en not_active Withdrawn
- 2004-02-19 KR KR1020057015943A patent/KR101001514B1/ko not_active IP Right Cessation
Cited By (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2008060817A (ja) * | 2006-08-30 | 2008-03-13 | Ttt Kk | 通信システム、ウェブサーバ装置、クライアント装置、通信を行うための通信プログラム及びプログラムを記録した記録媒体 |
| EP1959602A2 (en) | 2007-02-13 | 2008-08-20 | Seiko Epson Corporation | Transmitting and receiving method, transmitting and receiving system, transmitting apparatus, and receiving apparatus |
| US7769014B2 (en) | 2007-02-13 | 2010-08-03 | Seiko Epson Corporation | Transmitting and receiving system, transmitting apparatus, and receiving apparatus |
| JP2011223269A (ja) * | 2010-04-08 | 2011-11-04 | Central Res Inst Of Electric Power Ind | 監視制御方法及び監視制御システム |
Also Published As
| Publication number | Publication date |
|---|---|
| KR20050113618A (ko) | 2005-12-02 |
| EP1599003A1 (en) | 2005-11-23 |
| CN1754364A (zh) | 2006-03-29 |
| EP1599003A4 (en) | 2011-07-27 |
| WO2004077780A1 (ja) | 2004-09-10 |
| US20060245428A1 (en) | 2006-11-02 |
| KR101001514B1 (ko) | 2010-12-14 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP2004266504A (ja) | 送受信システム、送信装置および方法、受信装置および方法、記録媒体、並びにプログラム | |
| JP4000905B2 (ja) | 情報処理システムおよび方法、情報処理装置および方法、記録媒体、並びにプログラム | |
| JP3757857B2 (ja) | データ通信システム、データ送信装置、データ受信装置、および方法、並びにコンピュータ・プログラム | |
| TWI388170B (zh) | 網路中串流資料內容之方法及裝置 | |
| JP4118617B2 (ja) | ストリームメディアに対する交渉方式の／動的なエラー訂正 | |
| US7710941B2 (en) | Method and device for the synchronised restitution of data flows | |
| JP4874250B2 (ja) | データストリーム通信装置及びデータストリーム通信方法 | |
| EP1601161B1 (en) | Network interface card for supporting multi-streaming format and method thereof | |
| US20170034589A1 (en) | Adaptive profile switching system and method for media streaming over ip networks | |
| JP2008048182A (ja) | 通信処理装置、および通信制御方法、並びにコンピュータ・プログラム | |
| JP3994388B2 (ja) | 送受信システム、送信装置および方法、記録媒体、並びにプログラム | |
| JP2005210219A (ja) | 送受信システム、送信装置および方法、受信装置および方法、記録媒体、並びにプログラム | |
| JP4176402B2 (ja) | 通信管理方法、通信管理プログラム、通信管理プログラムを記録した記録媒体、ならびに通信局 | |
| WO2012011473A1 (ja) | 送信装置、送信方法、受信装置、受信方法、通信システム、データ構造、プログラム、及び、記憶媒体 | |
| US20050083970A1 (en) | Apparatus, system and method of transmitting data | |
| WO2002056549A1 (fr) | Dispositif de communication et procede de communication | |
| JP4737243B2 (ja) | 集積回路装置及びデータ伝送システム | |
| JP5082715B2 (ja) | 受信装置、受信方法およびコンピュータプログラム | |
| JP2004007172A (ja) | 情報配信システム、情報配信装置および方法、情報端末装置および情報処理方法、記録媒体、並びにプログラム | |
| JP4433281B2 (ja) | 受信装置および方法、記録媒体、並びにプログラム | |
| JP5159973B1 (ja) | 伝送パケットの配信方法 | |
| JP2009027327A (ja) | データ送受信装置 | |
| JP2005191735A (ja) | 圧縮データ送信装置、圧縮データ送信システム、圧縮データ送信方法及びプログラム | |
| TWI559761B (zh) | Application of Data Synchronization in Multimedia Synchronization | |
| JP2005269236A (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 |
|
| A912 | Re-examination (zenchi) completed and case transferred to appeal board |
Free format text: JAPANESE INTERMEDIATE CODE: A912 Effective date: 20070713 |