JP2003169040A - データ通信システム、データ送信装置、データ受信装置、および方法、並びにコンピュータ・プログラム - Google Patents
データ通信システム、データ送信装置、データ受信装置、および方法、並びにコンピュータ・プログラムInfo
- Publication number
- JP2003169040A JP2003169040A JP2001369731A JP2001369731A JP2003169040A JP 2003169040 A JP2003169040 A JP 2003169040A JP 2001369731 A JP2001369731 A JP 2001369731A JP 2001369731 A JP2001369731 A JP 2001369731A JP 2003169040 A JP2003169040 A JP 2003169040A
- Authority
- JP
- Japan
- Prior art keywords
- data
- packet
- retransmission request
- retransmission
- processing
- 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
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F15/00—Digital computers in general; Data processing equipment in general
- G06F15/16—Combinations of two or more digital computers each having at least an arithmetic unit, a program unit and a register, e.g. for a simultaneous processing of several programs
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
- H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
- H04N21/442—Monitoring of processes or resources, e.g. detecting the failure of a recording device, monitoring the downstream bandwidth, the number of times a movie has been viewed, the storage space available from the internal hard disk
- H04N21/44209—Monitoring of downstream path of the transmission network originating from a server, e.g. bandwidth variations of a wireless network
-
- 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
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/1066—Session management
- H04L65/1101—Session protocols
-
- 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
- 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
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client
- H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
- H04N21/637—Control signals issued by the client directed to the server or network components
- H04N21/6375—Control signals issued by the client directed to the server or network components for requesting retransmission, e.g. of data packets lost or corrupted during transmission from server
-
- 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/30—Definitions, standards or architectural aspects of layered protocol stacks
- H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
- H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
- H04L69/324—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the data link layer [OSI layer 2], e.g. HDLC
Landscapes
- Engineering & Computer Science (AREA)
- Multimedia (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Hardware Design (AREA)
- Databases & Information Systems (AREA)
- Theoretical Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- General Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Physics & Mathematics (AREA)
- Business, Economics & Management (AREA)
- General Physics & Mathematics (AREA)
- General Business, Economics & Management (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
- Communication Control (AREA)
- Compression Or Coding Systems Of Tv Signals (AREA)
- Detection And Prevention Of Errors In Transmission (AREA)
Abstract
(57)【要約】
【課題】 ＡＲＱ機能による再送要求の効率的利用によ
り、高品質なデータ再生を可能とするデータ通信システ
ムを提供する。 【解決手段】 ＲＴＰ、ＵＤＰ等のデータ通信プロトコ
ルに従ったパケット伝送において、ＡＲＱ機能を付加
し、再送要求の処理タイミングとして、各フレームの先
頭パケットの受信時、各フレームの最終パケットの受信
時、最終処理期限、および一定間隔（τ）毎等の各種タ
イミングでロストパケットの検出処理を実行し、再送要
求を実行する。データ受信端末は、再生処理時間、伝播
遅延時間ＲＴＴを考慮し、再生処理に間に合わない場合
には、再生要求処理を実行しない構成とし、無駄な再送
要求パケットおよび再送パケットの出力が防止される。
り、高品質なデータ再生を可能とするデータ通信システ
ムを提供する。 【解決手段】 ＲＴＰ、ＵＤＰ等のデータ通信プロトコ
ルに従ったパケット伝送において、ＡＲＱ機能を付加
し、再送要求の処理タイミングとして、各フレームの先
頭パケットの受信時、各フレームの最終パケットの受信
時、最終処理期限、および一定間隔（τ）毎等の各種タ
イミングでロストパケットの検出処理を実行し、再送要
求を実行する。データ受信端末は、再生処理時間、伝播
遅延時間ＲＴＴを考慮し、再生処理に間に合わない場合
には、再生要求処理を実行しない構成とし、無駄な再送
要求パケットおよび再送パケットの出力が防止される。
Description
【０００１】
【発明の属する技術分野】本発明は、データ通信システ
ム、データ送信装置、データ受信装置、および方法、並
びにコンピュータ・プログラムに関する。さらに詳細に
は、ストリーミングデータ転送におけるエラー耐性を高
めたパケット送信構成を持つデータ通信システム、デー
タ送信装置、データ受信装置、および方法、並びにコン
ピュータ・プログラムに関する。
ム、データ送信装置、データ受信装置、および方法、並
びにコンピュータ・プログラムに関する。さらに詳細に
は、ストリーミングデータ転送におけるエラー耐性を高
めたパケット送信構成を持つデータ通信システム、デー
タ送信装置、データ受信装置、および方法、並びにコン
ピュータ・プログラムに関する。
【０００２】
【従来の技術】昨今、インターネット通信など、様々な
通信媒体を介した画像、音声データ等のデータ転送が盛
んに行われている。特に、近年においては、インターネ
ット上のデータ転送において、従来から利用されている
ダウンロード型伝送方式に加えて、ストリーム型伝送方
式によるサービスが増加してきている。ダウンロード型
伝送方式においては、映像ファイルや音声ファイルとい
ったマルチメディアデータを伝送する場合、配信サーバ
からデータファイルを一旦受信側端末の記憶媒体にダウ
ンロードして、その後、記憶媒体から再生することにな
る。よって、この方式ではファイルを完全に転送が終わ
るまでは再生できず、長時間再生やリアルタイム再生な
どには不向きである。
通信媒体を介した画像、音声データ等のデータ転送が盛
んに行われている。特に、近年においては、インターネ
ット上のデータ転送において、従来から利用されている
ダウンロード型伝送方式に加えて、ストリーム型伝送方
式によるサービスが増加してきている。ダウンロード型
伝送方式においては、映像ファイルや音声ファイルとい
ったマルチメディアデータを伝送する場合、配信サーバ
からデータファイルを一旦受信側端末の記憶媒体にダウ
ンロードして、その後、記憶媒体から再生することにな
る。よって、この方式ではファイルを完全に転送が終わ
るまでは再生できず、長時間再生やリアルタイム再生な
どには不向きである。
【０００３】一方、後者のストリーム型伝送方式では、
送信側から受信端末にデータ転送が行われている間に、
並列して受信データの再生処理を実行するものであり、
インターネット電話・遠隔テレビ会議・ビデオオンデマ
ンドといったインターネットサービスに利用されてい
る。
送信側から受信端末にデータ転送が行われている間に、
並列して受信データの再生処理を実行するものであり、
インターネット電話・遠隔テレビ会議・ビデオオンデマ
ンドといったインターネットサービスに利用されてい
る。
【０００４】ストリーム型伝送方式は、例えば画像デー
タのＭＰＥＧ圧縮処理により生成されるＭＰＥＧストリ
ームをＩＰ（Internet Protocol）パケットに格納して
インターネット上を転送させて、ＰＣやＰＤＡ、携帯電
話等の各通信端末において受信するシステム等において
使用され、開発が進んでいる。このような技術は、ビデ
オオンデマンドやライブ映像のストリーミング配信、あ
るいはビデオ会議、テレビ電話などのリアルタイム通信
において有効となる。
タのＭＰＥＧ圧縮処理により生成されるＭＰＥＧストリ
ームをＩＰ（Internet Protocol）パケットに格納して
インターネット上を転送させて、ＰＣやＰＤＡ、携帯電
話等の各通信端末において受信するシステム等において
使用され、開発が進んでいる。このような技術は、ビデ
オオンデマンドやライブ映像のストリーミング配信、あ
るいはビデオ会議、テレビ電話などのリアルタイム通信
において有効となる。
【０００５】このようなストリーム型伝送方式に適した
インターネット技術に、IETF RFC1889で規定されている
プロトコル：ＲＴＰ(Realtime Transport Protocol)が
ある。ＲＴＰに従ったデータ転送では、時間情報として
パケットにタイムスタンプを付加し、タイムスタンプの
参照により送信側と受信側の時間的関係の把握を行な
い、データ受信側において、パケット転送の遅延ゆらぎ
（ジッター）などの影響を受けずに同期をとった再生を
可能としている。
インターネット技術に、IETF RFC1889で規定されている
プロトコル：ＲＴＰ(Realtime Transport Protocol)が
ある。ＲＴＰに従ったデータ転送では、時間情報として
パケットにタイムスタンプを付加し、タイムスタンプの
参照により送信側と受信側の時間的関係の把握を行な
い、データ受信側において、パケット転送の遅延ゆらぎ
（ジッター）などの影響を受けずに同期をとった再生を
可能としている。
【０００６】ただし、ＲＴＰは実時間のデータ転送を保
証しているものではない。パケット配送の優先度や設
定、管理などはＲＴＰが提供するトランスポートサービ
スの範疇ではないため、ＲＴＰパケットは、他のパケッ
トと同様、ネットワーク上での配送遅延やパケット損失
がおきる可能性がある。しかし、このような事態が起こ
っても、受信側は期待する時間内に到着したパケットだ
けを利用してデータを再生することが可能である。これ
は、映像や音声データが多少のデータ欠損があったとし
ても、データ品質を落とした再生、あるいはデータ補正
処理による再生が可能となるからである。
証しているものではない。パケット配送の優先度や設
定、管理などはＲＴＰが提供するトランスポートサービ
スの範疇ではないため、ＲＴＰパケットは、他のパケッ
トと同様、ネットワーク上での配送遅延やパケット損失
がおきる可能性がある。しかし、このような事態が起こ
っても、受信側は期待する時間内に到着したパケットだ
けを利用してデータを再生することが可能である。これ
は、映像や音声データが多少のデータ欠損があったとし
ても、データ品質を落とした再生、あるいはデータ補正
処理による再生が可能となるからである。
【０００７】なお、再生に間に合わず遅延配送されたパ
ケットやエラーの発生したパケットは、受信側でそのま
ま破棄される。つまり、パケット損失やエラーが発生し
た場合は、高品質なデータ配信処理を行なっている場合
でも、受信側で品質を保持した再生が実行されないとい
う問題点がある。特に、有線区間で１０−５、無線区間
で１０−３以上のエラーがあるといわれている中では、
配信するメディアの品質保持を考慮すると、ＲＴＰをそ
のまま利用したデータ転送には問題がある。
ケットやエラーの発生したパケットは、受信側でそのま
ま破棄される。つまり、パケット損失やエラーが発生し
た場合は、高品質なデータ配信処理を行なっている場合
でも、受信側で品質を保持した再生が実行されないとい
う問題点がある。特に、有線区間で１０−５、無線区間
で１０−３以上のエラーがあるといわれている中では、
配信するメディアの品質保持を考慮すると、ＲＴＰをそ
のまま利用したデータ転送には問題がある。
【０００８】このようなＲＴＰに従ったデータ転送にお
ける問題点を解決する１つの案としては、データ転送に
信頼性が高いデータ転送プロトコルであるＴＣＰに従っ
てパケットの再送要求および再送パケット送信を行わせ
る方法が考えられる。しかし、ＴＣＰはエラーには強い
が、スループットが低く、遅延が大きいため、再送して
も再生時間に間に合わない可能性があり、リアルタイム
通信の実現を困難とするという問題がある。
ける問題点を解決する１つの案としては、データ転送に
信頼性が高いデータ転送プロトコルであるＴＣＰに従っ
てパケットの再送要求および再送パケット送信を行わせ
る方法が考えられる。しかし、ＴＣＰはエラーには強い
が、スループットが低く、遅延が大きいため、再送して
も再生時間に間に合わない可能性があり、リアルタイム
通信の実現を困難とするという問題がある。
【０００９】さらに、パケットエラー等に対応するエラ
ー訂正手法として、例えばＦＥＣ（Forward Error Corr
ection）という手段が考えられている。これは誤り訂正
を行うためのＦＥＣデータを冗長データとして送信し
て、エラーが発生した場合には、データ受信側におい
て、このＦＥＣデータをもとにエラーの修復を実行しよ
うとするものである。先のＡＲＱによるパケット再送処
理に比べると再送にかかる遅延がない分、遅延時間を低
く抑えられるが、冗長データを付加するためにスループ
ットが低下するという問題がある。また、ネットワーク
状況に合わせた最適な付加ＦＥＣデータを決定するのは
難しく、処理時間のオーバーヘッドが常につきまとうな
どの問題が存在する。
ー訂正手法として、例えばＦＥＣ（Forward Error Corr
ection）という手段が考えられている。これは誤り訂正
を行うためのＦＥＣデータを冗長データとして送信し
て、エラーが発生した場合には、データ受信側におい
て、このＦＥＣデータをもとにエラーの修復を実行しよ
うとするものである。先のＡＲＱによるパケット再送処
理に比べると再送にかかる遅延がない分、遅延時間を低
く抑えられるが、冗長データを付加するためにスループ
ットが低下するという問題がある。また、ネットワーク
状況に合わせた最適な付加ＦＥＣデータを決定するのは
難しく、処理時間のオーバーヘッドが常につきまとうな
どの問題が存在する。
【００１０】
【発明が解決しようとする課題】本発明は、上述の問題
点に鑑みてなされたものであり、ビデオオンデマンド
や、遠隔テレビ会議のような、リアルタイム再生が望ま
れるデータ転送処理を効率的に実行可能とかるととも
に、パケット損失等のエラー発生時にも品質の低下を抑
えて高品質なデータ再生を実現するデータ通信システ
ム、データ送信装置、データ受信装置、および方法、並
びにコンピュータ・プログラムを提供することを目的と
する。
点に鑑みてなされたものであり、ビデオオンデマンド
や、遠隔テレビ会議のような、リアルタイム再生が望ま
れるデータ転送処理を効率的に実行可能とかるととも
に、パケット損失等のエラー発生時にも品質の低下を抑
えて高品質なデータ再生を実現するデータ通信システ
ム、データ送信装置、データ受信装置、および方法、並
びにコンピュータ・プログラムを提供することを目的と
する。
【００１１】
【課題を解決するための手段】本発明の第１の側面は、
データ送信装置およびデータ受信装置からなり、ストリ
ーム型データ転送を実行するデータ通信システムであ
り、データ送信装置は、送信データを格納したデータパ
ケットを送信するパケット送信処理部と、データ受信装
置から受信する再送要求メッセージパケットに従って再
送すべきデータパケットの抽出処理を実行する再送制御
部とを有し、データ受信装置は、前記データ送信装置か
ら受信するデータパケットを受信するパケット受信処理
部と、前記データ送信装置から受信するデータパケット
のエラーまたはロスト・データパケットの検出に基づい
て、前記データ送信装置に対するデータパケット再送要
求としての再送要求メッセージパケットの送信可否を判
定する再送要求処理制御部とを有し、前記再送要求処理
制御部は、再送要求に基づく再送データパケット受信
が、再送データパケット格納データの再生に伴う処理開
始時間前に可能か否かを判定し、可能であるとの判定を
条件として、再送要求送信を決定する構成を有すること
を特徴とするデータ通信システムにある。
データ送信装置およびデータ受信装置からなり、ストリ
ーム型データ転送を実行するデータ通信システムであ
り、データ送信装置は、送信データを格納したデータパ
ケットを送信するパケット送信処理部と、データ受信装
置から受信する再送要求メッセージパケットに従って再
送すべきデータパケットの抽出処理を実行する再送制御
部とを有し、データ受信装置は、前記データ送信装置か
ら受信するデータパケットを受信するパケット受信処理
部と、前記データ送信装置から受信するデータパケット
のエラーまたはロスト・データパケットの検出に基づい
て、前記データ送信装置に対するデータパケット再送要
求としての再送要求メッセージパケットの送信可否を判
定する再送要求処理制御部とを有し、前記再送要求処理
制御部は、再送要求に基づく再送データパケット受信
が、再送データパケット格納データの再生に伴う処理開
始時間前に可能か否かを判定し、可能であるとの判定を
条件として、再送要求送信を決定する構成を有すること
を特徴とするデータ通信システムにある。
【００１２】さらに、本発明のデータ通信システムの一
実施態様において、前記データ・パケットの格納データ
は、符号化データであり、前記データ受信装置における
前記再送要求処理制御部は、再送要求に基づく再送デー
タパケット受信が、再送データパケット格納データの復
号処理を含む再生に伴う処理開始時間前に可能か否かを
判定する構成であることを特徴とする。
実施態様において、前記データ・パケットの格納データ
は、符号化データであり、前記データ受信装置における
前記再送要求処理制御部は、再送要求に基づく再送デー
タパケット受信が、再送データパケット格納データの復
号処理を含む再生に伴う処理開始時間前に可能か否かを
判定する構成であることを特徴とする。
【００１３】さらに、本発明のデータ通信システムの一
実施態様において、前記再送要求は、再送要求データパ
ケットの識別データとしてのシーケンス番号と、該シー
ケンス番号に対応するデータパケットの重複再送の指定
回数データを格納したメッセージパケットによって構成
され、前記データ送信装置は、再送要求メッセージパケ
ットに指定された重複再送の指定回数データに従って、
指定シーケンス番号のデータパケットの重複送信を実行
する構成を有することを特徴とする。
実施態様において、前記再送要求は、再送要求データパ
ケットの識別データとしてのシーケンス番号と、該シー
ケンス番号に対応するデータパケットの重複再送の指定
回数データを格納したメッセージパケットによって構成
され、前記データ送信装置は、再送要求メッセージパケ
ットに指定された重複再送の指定回数データに従って、
指定シーケンス番号のデータパケットの重複送信を実行
する構成を有することを特徴とする。
【００１４】さらに、本発明のデータ通信システムの一
実施態様において、前記データ送信装置とデータ受信装
置間で転送されるデータパケットは、動画像データであ
り、前記データ受信装置における前記再送要求処理制御
部は、動画像データの１画像フレームの構成データを格
納した複数のデータパケットの終端データパケットの受
信に応じて、該終端データパケットの属する画像フレー
ムの構成データを格納した複数のデータパケット中のエ
ラーまたはロスト・データパケットの検出処理を実行す
る構成であることを特徴とする。
実施態様において、前記データ送信装置とデータ受信装
置間で転送されるデータパケットは、動画像データであ
り、前記データ受信装置における前記再送要求処理制御
部は、動画像データの１画像フレームの構成データを格
納した複数のデータパケットの終端データパケットの受
信に応じて、該終端データパケットの属する画像フレー
ムの構成データを格納した複数のデータパケット中のエ
ラーまたはロスト・データパケットの検出処理を実行す
る構成であることを特徴とする。
【００１５】さらに、本発明のデータ通信システムの一
実施態様において、前記データ送信装置とデータ受信装
置間で転送されるデータパケットは、動画像データであ
り、前記データ受信装置における前記再送要求処理制御
部は、動画像データの１画像フレームの構成データを格
納した複数のデータパケットの先頭データパケットの受
信に応じて、該先頭データパケットの属する画像フレー
ムの前フレームの構成データを格納した複数のデータパ
ケット中のエラーまたはロスト・データパケットの検出
処理を実行する構成であることを特徴とする。
実施態様において、前記データ送信装置とデータ受信装
置間で転送されるデータパケットは、動画像データであ
り、前記データ受信装置における前記再送要求処理制御
部は、動画像データの１画像フレームの構成データを格
納した複数のデータパケットの先頭データパケットの受
信に応じて、該先頭データパケットの属する画像フレー
ムの前フレームの構成データを格納した複数のデータパ
ケット中のエラーまたはロスト・データパケットの検出
処理を実行する構成であることを特徴とする。
【００１６】さらに、本発明のデータ通信システムの一
実施態様において、前記データ受信装置における前記再
送要求処理制御部は、データパケット格納データの再生
処理開始時間に間に合うための再送要求最終期限に基づ
いて、受信データパケット中のエラーまたはロスト・デ
ータパケットの検出処理を実行する構成であることを特
徴とする。
実施態様において、前記データ受信装置における前記再
送要求処理制御部は、データパケット格納データの再生
処理開始時間に間に合うための再送要求最終期限に基づ
いて、受信データパケット中のエラーまたはロスト・デ
ータパケットの検出処理を実行する構成であることを特
徴とする。
【００１７】さらに、本発明のデータ通信システムの一
実施態様において、前記データ受信装置における前記再
送要求処理制御部は、定期的な時間間隔に基づいて、受
信データパケット中のエラーまたはロスト・データパケ
ットの検出処理を実行する構成であることを特徴とす
る。
実施態様において、前記データ受信装置における前記再
送要求処理制御部は、定期的な時間間隔に基づいて、受
信データパケット中のエラーまたはロスト・データパケ
ットの検出処理を実行する構成であることを特徴とす
る。
【００１８】さらに、本発明のデータ通信システムの一
実施態様において、前記データ受信装置における前記再
送要求処理制御部は、前記データ送信装置とデータ受信
装置における往復伝播遅延（ＲＴＴ）の計測処理のため
に前記データ送信装置に対するエコーパケットの送信お
よび該エコーパケットに対するエコーリプライパケット
の受信処理制御を実行し、該エコーパケットに基づいて
算出する往復伝播遅延（ＲＴＴ）に基づいて、再送要求
に基づく再送データパケット受信が、再送データパケッ
ト格納データの再生処理開始時間前に可能か否かを判定
する構成を有することを特徴とする。
実施態様において、前記データ受信装置における前記再
送要求処理制御部は、前記データ送信装置とデータ受信
装置における往復伝播遅延（ＲＴＴ）の計測処理のため
に前記データ送信装置に対するエコーパケットの送信お
よび該エコーパケットに対するエコーリプライパケット
の受信処理制御を実行し、該エコーパケットに基づいて
算出する往復伝播遅延（ＲＴＴ）に基づいて、再送要求
に基づく再送データパケット受信が、再送データパケッ
ト格納データの再生処理開始時間前に可能か否かを判定
する構成を有することを特徴とする。
【００１９】さらに、本発明のデータ通信システムの一
実施態様において、前記データ受信装置の生成する再送
要求メッセージパケットは、データパケットを指定する
シーケンス番号指定データ、またはパケットの属するタ
イムスタンプ指定データの少なくともいずれかと、再送
要求範囲を指定するオプション値によって構成され、前
記データ送信装置の再送制御部は、前記データ受信装置
から受信する再送要求メッセージパケットに格納された
データパケットを指定するシーケンス番号指定データ、
またはパケットの属するタイムスタンプ指定データの少
なくともいずれか、およびオプション値に基づいて１以
上の再送パケットの抽出処理を実行する構成を有するこ
とを特徴とする。
実施態様において、前記データ受信装置の生成する再送
要求メッセージパケットは、データパケットを指定する
シーケンス番号指定データ、またはパケットの属するタ
イムスタンプ指定データの少なくともいずれかと、再送
要求範囲を指定するオプション値によって構成され、前
記データ送信装置の再送制御部は、前記データ受信装置
から受信する再送要求メッセージパケットに格納された
データパケットを指定するシーケンス番号指定データ、
またはパケットの属するタイムスタンプ指定データの少
なくともいずれか、およびオプション値に基づいて１以
上の再送パケットの抽出処理を実行する構成を有するこ
とを特徴とする。
【００２０】さらに、本発明のデータ通信システムの一
実施態様において、前記データパケットは、データ転送
プロトコルとしてのＲＴＰに従ったフォーマットを有
し、前記再送要求は、制御プロトコルとしてのＲＴＣＰ
に従ったフォーマットを有することを特徴とする。
実施態様において、前記データパケットは、データ転送
プロトコルとしてのＲＴＰに従ったフォーマットを有
し、前記再送要求は、制御プロトコルとしてのＲＴＣＰ
に従ったフォーマットを有することを特徴とする。
【００２１】さらに、本発明のデータ通信システムの一
実施態様において、前記データ受信装置は、複数のデー
タパケットに関する再送要求を１つの再送要求メッセー
ジパケットとしてデータ送信装置に対して送信する構成
であることを特徴とする。
実施態様において、前記データ受信装置は、複数のデー
タパケットに関する再送要求を１つの再送要求メッセー
ジパケットとしてデータ送信装置に対して送信する構成
であることを特徴とする。
【００２２】さらに、本発明のデータ通信システムの一
実施態様において、記データ受信装置は、複数のデータ
パケットに関する受信確認を１つの受信確認メッセージ
パケットとしてデータ送信装置に対して送信する構成で
あることを特徴とする。
実施態様において、記データ受信装置は、複数のデータ
パケットに関する受信確認を１つの受信確認メッセージ
パケットとしてデータ送信装置に対して送信する構成で
あることを特徴とする。
【００２３】さらに、本発明の第２の側面は、ストリー
ム型データ送信を実行するデータ送信装置であり、送信
データを格納したデータパケットの送信処理を実行する
パケット送信処理部と、データ受信装置から受信する再
送要求に従って再送すべきデータパケットの抽出処理を
実行する再送制御部とを有し、前記再送制御部は、デー
タ受信装置から受信する再送要求メッセージパケットに
指定された重複再送の指定回数データに従って、指定デ
ータパケットの重複送信を実行する構成を有することを
特徴とするデータ送信装置にある。
ム型データ送信を実行するデータ送信装置であり、送信
データを格納したデータパケットの送信処理を実行する
パケット送信処理部と、データ受信装置から受信する再
送要求に従って再送すべきデータパケットの抽出処理を
実行する再送制御部とを有し、前記再送制御部は、デー
タ受信装置から受信する再送要求メッセージパケットに
指定された重複再送の指定回数データに従って、指定デ
ータパケットの重複送信を実行する構成を有することを
特徴とするデータ送信装置にある。
【００２４】さらに、本発明の第３の側面は、ストリー
ム型データ送信を実行するデータ送信装置であり、送信
データを格納したデータパケットの送信処理を実行する
パケット送信処理部と、データ受信装置から受信する再
送要求に従って再送すべきデータパケットの抽出処理を
実行する再送制御部とを有し、前記再送制御部は、前記
データ受信装置から受信する再送要求メッセージパケッ
トに格納されたデータパケットを指定するシーケンス番
号指定データ、またはパケットの属するタイムスタンプ
指定データの少なくともいずれか、およびオプション値
に基づいて１以上の再送パケットの抽出処理を実行する
構成を有することを特徴とするデータ送信装置にある。
ム型データ送信を実行するデータ送信装置であり、送信
データを格納したデータパケットの送信処理を実行する
パケット送信処理部と、データ受信装置から受信する再
送要求に従って再送すべきデータパケットの抽出処理を
実行する再送制御部とを有し、前記再送制御部は、前記
データ受信装置から受信する再送要求メッセージパケッ
トに格納されたデータパケットを指定するシーケンス番
号指定データ、またはパケットの属するタイムスタンプ
指定データの少なくともいずれか、およびオプション値
に基づいて１以上の再送パケットの抽出処理を実行する
構成を有することを特徴とするデータ送信装置にある。
【００２５】さらに、本発明の第４の側面は、ストリー
ム型データ受信を実行するデータ受信装置であり、デー
タ送信装置から受信するデータパケットを受信するパケ
ット受信処理部と、前記データ送信装置から受信するデ
ータパケットのエラーまたはロスト・データパケットの
検出に基づいて、前記データ送信装置に対するデータパ
ケット再送要求としての再送要求メッセージパケットの
送信可否を判定する再送要求処理制御部とを有し、前記
再送要求処理制御部は、再送要求に基づく再送データパ
ケット受信が、再送データパケット格納データの再生に
伴う処理開始時間前に可能か否かを判定し、可能である
との判定を条件として、再送要求送信を決定する構成を
有することを特徴とするデータ受信装置にある。
ム型データ受信を実行するデータ受信装置であり、デー
タ送信装置から受信するデータパケットを受信するパケ
ット受信処理部と、前記データ送信装置から受信するデ
ータパケットのエラーまたはロスト・データパケットの
検出に基づいて、前記データ送信装置に対するデータパ
ケット再送要求としての再送要求メッセージパケットの
送信可否を判定する再送要求処理制御部とを有し、前記
再送要求処理制御部は、再送要求に基づく再送データパ
ケット受信が、再送データパケット格納データの再生に
伴う処理開始時間前に可能か否かを判定し、可能である
との判定を条件として、再送要求送信を決定する構成を
有することを特徴とするデータ受信装置にある。
【００２６】さらに、本発明のデータ受信装置の一実施
態様において、前記データ・パケットの格納データは、
符号化データであり、前記再送要求処理制御部は、再送
要求に基づく再送データパケット受信が、再送データパ
ケット格納データの復号処理を含む再生に伴う処理開始
時間前に可能か否かを判定する構成であることを特徴と
する。
態様において、前記データ・パケットの格納データは、
符号化データであり、前記再送要求処理制御部は、再送
要求に基づく再送データパケット受信が、再送データパ
ケット格納データの復号処理を含む再生に伴う処理開始
時間前に可能か否かを判定する構成であることを特徴と
する。
【００２７】さらに、本発明のデータ受信装置の一実施
態様において、前記データ受信装置は、再送要求データ
パケットの識別データとしてのシーケンス番号と、該シ
ーケンス番号に対応するデータパケットの重複再送の指
定回数データを格納した再送要求メッセージパケットを
生成して前記データ送信装置に送信する構成を有するこ
とを特徴とする。
態様において、前記データ受信装置は、再送要求データ
パケットの識別データとしてのシーケンス番号と、該シ
ーケンス番号に対応するデータパケットの重複再送の指
定回数データを格納した再送要求メッセージパケットを
生成して前記データ送信装置に送信する構成を有するこ
とを特徴とする。
【００２８】さらに、本発明のデータ受信装置の一実施
態様において、前記データ受信装置の受信するデータパ
ケットは、動画像データであり、前記再送要求処理制御
部は、動画像データの１画像フレームの構成データを格
納した複数のデータパケットの終端データパケットの受
信に応じて、該終端データパケットの属する画像フレー
ムの構成データを格納した複数のデータパケット中のエ
ラーまたはロスト・データパケットの検出処理を実行す
る構成であることを特徴とする。
態様において、前記データ受信装置の受信するデータパ
ケットは、動画像データであり、前記再送要求処理制御
部は、動画像データの１画像フレームの構成データを格
納した複数のデータパケットの終端データパケットの受
信に応じて、該終端データパケットの属する画像フレー
ムの構成データを格納した複数のデータパケット中のエ
ラーまたはロスト・データパケットの検出処理を実行す
る構成であることを特徴とする。
【００２９】さらに、本発明のデータ受信装置の一実施
態様において、前記データ受信装置の受信するデータパ
ケットは、動画像データであり、前記再送要求処理制御
部は、動画像データの１画像フレームの構成データを格
納した複数のデータパケットの先頭データパケットの受
信に応じて、該先頭データパケットの属する画像フレー
ムの前フレームの構成データを格納した複数のデータパ
ケット中のエラーまたはロスト・データパケットの検出
処理を実行する構成であることを特徴とする。
態様において、前記データ受信装置の受信するデータパ
ケットは、動画像データであり、前記再送要求処理制御
部は、動画像データの１画像フレームの構成データを格
納した複数のデータパケットの先頭データパケットの受
信に応じて、該先頭データパケットの属する画像フレー
ムの前フレームの構成データを格納した複数のデータパ
ケット中のエラーまたはロスト・データパケットの検出
処理を実行する構成であることを特徴とする。
【００３０】さらに、本発明のデータ受信装置の一実施
態様において、前記再送要求処理制御部は、データパケ
ット格納データの再生処理開始時間に間に合うための再
送要求最終期限に基づいて、受信データパケット中のエ
ラーまたはロスト・データパケットの検出処理を実行す
る構成であることを特徴とする。
態様において、前記再送要求処理制御部は、データパケ
ット格納データの再生処理開始時間に間に合うための再
送要求最終期限に基づいて、受信データパケット中のエ
ラーまたはロスト・データパケットの検出処理を実行す
る構成であることを特徴とする。
【００３１】さらに、本発明のデータ受信装置の一実施
態様において、前記再送要求処理制御部は、定期的な時
間間隔に基づいて、受信データパケット中のエラーまた
はロスト・データパケットの検出処理を実行する構成で
あることを特徴とする。
態様において、前記再送要求処理制御部は、定期的な時
間間隔に基づいて、受信データパケット中のエラーまた
はロスト・データパケットの検出処理を実行する構成で
あることを特徴とする。
【００３２】さらに、本発明のデータ受信装置の一実施
態様において、前記再送要求処理制御部は、前記データ
送信装置とデータ受信装置における往復伝播遅延（ＲＴ
Ｔ）の計測処理のために前記データ送信装置に対するエ
コーパケットの送信および該エコーパケットに対するエ
コーリプライパケットの受信処理制御を実行し、該エコ
ーパケットに基づいて算出する往復伝播遅延（ＲＴＴ）
に基づいて、再送要求に基づく再送データパケット受信
が、再送データパケット格納データの再生処理開始時間
前に可能か否かを判定する構成を有することを特徴とす
る。
態様において、前記再送要求処理制御部は、前記データ
送信装置とデータ受信装置における往復伝播遅延（ＲＴ
Ｔ）の計測処理のために前記データ送信装置に対するエ
コーパケットの送信および該エコーパケットに対するエ
コーリプライパケットの受信処理制御を実行し、該エコ
ーパケットに基づいて算出する往復伝播遅延（ＲＴＴ）
に基づいて、再送要求に基づく再送データパケット受信
が、再送データパケット格納データの再生処理開始時間
前に可能か否かを判定する構成を有することを特徴とす
る。
【００３３】さらに、本発明のデータ受信装置の一実施
態様において、前記データ受信装置は、再送要求データ
パケットの識別データとしてのシーケンス番号、または
パケットの属するタイムスタンプ指定データの少なくと
もいずれかと、再送要求範囲を指定するオプションを格
納した再送要求メッセージパケットを生成して前記デー
タ送信装置に送信する構成を有することを特徴とする。
態様において、前記データ受信装置は、再送要求データ
パケットの識別データとしてのシーケンス番号、または
パケットの属するタイムスタンプ指定データの少なくと
もいずれかと、再送要求範囲を指定するオプションを格
納した再送要求メッセージパケットを生成して前記デー
タ送信装置に送信する構成を有することを特徴とする。
【００３４】さらに、本発明のデータ受信装置の一実施
態様において、前記データパケットは、データ転送プロ
トコルとしてのＲＴＰに従ったフォーマットを有し、前
記再送要求は、制御プロトコルとしてのＲＴＣＰに従っ
たフォーマットを有することを特徴とする。
態様において、前記データパケットは、データ転送プロ
トコルとしてのＲＴＰに従ったフォーマットを有し、前
記再送要求は、制御プロトコルとしてのＲＴＣＰに従っ
たフォーマットを有することを特徴とする。
【００３５】さらに、本発明のデータ受信装置の一実施
態様において、前記データ受信装置は、複数のデータパ
ケットに関する再送要求を１つの再送要求メッセージパ
ケットとしてデータ送信装置に対して送信する構成であ
ることを特徴とする。
態様において、前記データ受信装置は、複数のデータパ
ケットに関する再送要求を１つの再送要求メッセージパ
ケットとしてデータ送信装置に対して送信する構成であ
ることを特徴とする。
【００３６】さらに、本発明のデータ受信装置の一実施
態様において、前記データ受信装置は、複数のデータパ
ケットに関する受信確認を１つの受信確認メッセージパ
ケットとしてデータ送信装置に対して送信する構成であ
ることを特徴とする。
態様において、前記データ受信装置は、複数のデータパ
ケットに関する受信確認を１つの受信確認メッセージパ
ケットとしてデータ送信装置に対して送信する構成であ
ることを特徴とする。
【００３７】さらに、本発明の第５の側面は、データ送
信装置およびデータ受信装置からなり、ストリーム型デ
ータ転送を実行するデータ通信方法であり、データ送信
装置において、送信データを格納したデータパケットを
送信するパケット送信処理ステップと、データ受信装置
から受信する再送要求メッセージパケットに従って再送
すべきデータパケットの抽出処理を実行する再送制御処
理ステップとを有し、データ受信装置は、前記データ送
信装置から受信するデータパケットを受信するパケット
受信処理ステップと、前記データ送信装置から受信する
データパケットのエラーまたはロスト・データパケット
の検出に基づいて、前記データ送信装置に対するデータ
パケット再送要求としての再送要求メッセージパケット
の送信可否を判定する再送要求処理制御ステップとを有
し、前記再送要求処理制御ステップは、再送要求に基づ
く再送データパケット受信が、再送データパケット格納
データの再生に伴う処理開始時間前に可能か否かを判定
し、可能であるとの判定を条件として、再送要求送信を
決定することを特徴とするデータ通信方法にある。
信装置およびデータ受信装置からなり、ストリーム型デ
ータ転送を実行するデータ通信方法であり、データ送信
装置において、送信データを格納したデータパケットを
送信するパケット送信処理ステップと、データ受信装置
から受信する再送要求メッセージパケットに従って再送
すべきデータパケットの抽出処理を実行する再送制御処
理ステップとを有し、データ受信装置は、前記データ送
信装置から受信するデータパケットを受信するパケット
受信処理ステップと、前記データ送信装置から受信する
データパケットのエラーまたはロスト・データパケット
の検出に基づいて、前記データ送信装置に対するデータ
パケット再送要求としての再送要求メッセージパケット
の送信可否を判定する再送要求処理制御ステップとを有
し、前記再送要求処理制御ステップは、再送要求に基づ
く再送データパケット受信が、再送データパケット格納
データの再生に伴う処理開始時間前に可能か否かを判定
し、可能であるとの判定を条件として、再送要求送信を
決定することを特徴とするデータ通信方法にある。
【００３８】さらに、本発明のデータ通信方法の一実施
態様において、前記データ・パケットの格納データは、
符号化データであり、前記データ受信装置における前記
再送要求処理制御ステップは、再送要求に基づく再送デ
ータパケット受信が、再送データパケット格納データの
復号処理を含む再生に伴う処理開始時間前に可能か否か
を判定するステップを含むことを特徴とする。
態様において、前記データ・パケットの格納データは、
符号化データであり、前記データ受信装置における前記
再送要求処理制御ステップは、再送要求に基づく再送デ
ータパケット受信が、再送データパケット格納データの
復号処理を含む再生に伴う処理開始時間前に可能か否か
を判定するステップを含むことを特徴とする。
【００３９】さらに、本発明のデータ通信方法の一実施
態様において、前記再送要求は、再送要求データパケッ
トの識別データとしてのシーケンス番号と、該シーケン
ス番号に対応するデータパケットの重複再送の指定回数
データを格納したメッセージパケットによって構成さ
れ、前記データ送信装置は、再送要求メッセージパケッ
トに指定された重複再送の指定回数データに従って、指
定シーケンス番号のデータパケットの重複送信を実行す
ることを特徴とする。
態様において、前記再送要求は、再送要求データパケッ
トの識別データとしてのシーケンス番号と、該シーケン
ス番号に対応するデータパケットの重複再送の指定回数
データを格納したメッセージパケットによって構成さ
れ、前記データ送信装置は、再送要求メッセージパケッ
トに指定された重複再送の指定回数データに従って、指
定シーケンス番号のデータパケットの重複送信を実行す
ることを特徴とする。
【００４０】さらに、本発明のデータ通信方法の一実施
態様において、前記データ送信装置とデータ受信装置間
で転送されるデータパケットは、動画像データであり、
前記データ受信装置における前記再送要求処理制御ステ
ップは、動画像データの１画像フレームの構成データを
格納した複数のデータパケットの終端データパケットの
受信に応じて、該終端データパケットの属する画像フレ
ームの構成データを格納した複数のデータパケット中の
エラーまたはロスト・データパケットの検出処理を実行
するステップを含むことを特徴とする。
態様において、前記データ送信装置とデータ受信装置間
で転送されるデータパケットは、動画像データであり、
前記データ受信装置における前記再送要求処理制御ステ
ップは、動画像データの１画像フレームの構成データを
格納した複数のデータパケットの終端データパケットの
受信に応じて、該終端データパケットの属する画像フレ
ームの構成データを格納した複数のデータパケット中の
エラーまたはロスト・データパケットの検出処理を実行
するステップを含むことを特徴とする。
【００４１】さらに、本発明のデータ通信方法の一実施
態様において、前記データ送信装置とデータ受信装置間
で転送されるデータパケットは、動画像データであり、
前記データ受信装置における前記再送要求処理制御ステ
ップは、動画像データの１画像フレームの構成データを
格納した複数のデータパケットの先頭データパケットの
受信に応じて、該先頭データパケットの属する画像フレ
ームの前フレームの構成データを格納した複数のデータ
パケット中のエラーまたはロスト・データパケットの検
出処理を実行するステップを含むことを特徴とする。
態様において、前記データ送信装置とデータ受信装置間
で転送されるデータパケットは、動画像データであり、
前記データ受信装置における前記再送要求処理制御ステ
ップは、動画像データの１画像フレームの構成データを
格納した複数のデータパケットの先頭データパケットの
受信に応じて、該先頭データパケットの属する画像フレ
ームの前フレームの構成データを格納した複数のデータ
パケット中のエラーまたはロスト・データパケットの検
出処理を実行するステップを含むことを特徴とする。
【００４２】さらに、本発明のデータ通信方法の一実施
態様において、前記データ受信装置における前記再送要
求処理制御ステップは、データパケット格納データの再
生処理開始時間に間に合うための再送要求最終期限に基
づいて、受信データパケット中のエラーまたはロスト・
データパケットの検出処理を実行するステップを含むこ
とを特徴とする。
態様において、前記データ受信装置における前記再送要
求処理制御ステップは、データパケット格納データの再
生処理開始時間に間に合うための再送要求最終期限に基
づいて、受信データパケット中のエラーまたはロスト・
データパケットの検出処理を実行するステップを含むこ
とを特徴とする。
【００４３】さらに、本発明のデータ通信方法の一実施
態様において、前記データ受信装置における前記再送要
求処理制御ステップは、定期的な時間間隔に基づいて、
受信データパケット中のエラーまたはロスト・データパ
ケットの検出処理を実行するステップを含むことを特徴
とする。
態様において、前記データ受信装置における前記再送要
求処理制御ステップは、定期的な時間間隔に基づいて、
受信データパケット中のエラーまたはロスト・データパ
ケットの検出処理を実行するステップを含むことを特徴
とする。
【００４４】さらに、本発明のデータ通信方法の一実施
態様において、前記データ受信装置は、さらに、前記デ
ータ送信装置とデータ受信装置における往復伝播遅延
（ＲＴＴ）の計測処理のために前記データ送信装置に対
するエコーパケットの送信および該エコーパケットに対
するエコーリプライパケットの受信処理制御ステップを
実行し、前記再送要求処理制御ステップは、該エコーパ
ケットに基づいて算出する往復伝播遅延（ＲＴＴ）に基
づいて、再送要求に基づく再送データパケット受信が、
再送データパケット格納データの再生処理開始時間前に
可能か否かを判定するステップを含むことを特徴とす
る。
態様において、前記データ受信装置は、さらに、前記デ
ータ送信装置とデータ受信装置における往復伝播遅延
（ＲＴＴ）の計測処理のために前記データ送信装置に対
するエコーパケットの送信および該エコーパケットに対
するエコーリプライパケットの受信処理制御ステップを
実行し、前記再送要求処理制御ステップは、該エコーパ
ケットに基づいて算出する往復伝播遅延（ＲＴＴ）に基
づいて、再送要求に基づく再送データパケット受信が、
再送データパケット格納データの再生処理開始時間前に
可能か否かを判定するステップを含むことを特徴とす
る。
【００４５】さらに、本発明のデータ通信方法の一実施
態様において、前記データ受信装置の生成する再送要求
メッセージパケットは、データパケットを指定するシー
ケンス番号指定データ、またはパケットの属するタイム
スタンプ指定データの少なくともいずれかと、再送要求
範囲を指定するオプション値によって構成され、前記デ
ータ送信装置の再送制御ステップは、前記データ受信装
置から受信する再送要求メッセージパケットに格納され
たデータパケットを指定するシーケンス番号指定デー
タ、またはパケットの属するタイムスタンプ指定データ
の少なくともいずれか、およびオプション値に基づいて
１以上の再送パケットの抽出処理を実行することを特徴
とする。
態様において、前記データ受信装置の生成する再送要求
メッセージパケットは、データパケットを指定するシー
ケンス番号指定データ、またはパケットの属するタイム
スタンプ指定データの少なくともいずれかと、再送要求
範囲を指定するオプション値によって構成され、前記デ
ータ送信装置の再送制御ステップは、前記データ受信装
置から受信する再送要求メッセージパケットに格納され
たデータパケットを指定するシーケンス番号指定デー
タ、またはパケットの属するタイムスタンプ指定データ
の少なくともいずれか、およびオプション値に基づいて
１以上の再送パケットの抽出処理を実行することを特徴
とする。
【００４６】さらに、本発明のデータ通信方法の一実施
態様において、前記データパケットは、データ転送プロ
トコルとしてのＲＴＰに従ったフォーマットを有し、前
記再送要求は、制御プロトコルとしてのＲＴＣＰに従っ
たフォーマットを有することを特徴とする。
態様において、前記データパケットは、データ転送プロ
トコルとしてのＲＴＰに従ったフォーマットを有し、前
記再送要求は、制御プロトコルとしてのＲＴＣＰに従っ
たフォーマットを有することを特徴とする。
【００４７】さらに、本発明のデータ通信方法の一実施
態様において、前記データ受信装置は、さらに、複数の
データパケットに関する再送要求を１つの再送要求メッ
セージパケットとしてデータ送信装置に対して送信する
ステップを実行することを特徴とする。
態様において、前記データ受信装置は、さらに、複数の
データパケットに関する再送要求を１つの再送要求メッ
セージパケットとしてデータ送信装置に対して送信する
ステップを実行することを特徴とする。
【００４８】さらに、本発明のデータ通信方法の一実施
態様において、前記データ受信装置は、さらに、複数の
データパケットに関する受信確認を１つの受信確認メッ
セージパケットとしてデータ送信装置に対して送信する
ステップを実行することを特徴とする。
態様において、前記データ受信装置は、さらに、複数の
データパケットに関する受信確認を１つの受信確認メッ
セージパケットとしてデータ送信装置に対して送信する
ステップを実行することを特徴とする。
【００４９】さらに、本発明の第６の側面は、ストリー
ム型データ受信処理を実行するコンピュータ・プログラ
ムであって、データ送信装置から受信するデータパケッ
トを受信するパケット受信処理ステップと、前記データ
送信装置から受信するデータパケットのエラーまたはロ
スト・データパケットの検出に基づいて、前記データ送
信装置に対するデータパケット再送要求としての再送要
求メッセージパケットの送信可否を判定する再送要求処
理制御ステップとを有し、前記再送要求処理制御ステッ
プは、再送要求に基づく再送データパケット受信が、再
送データパケット格納データの再生に伴う処理開始時間
前に可能か否かを判定し、可能であるとの判定を条件と
して、再送要求送信を決定するステップを含むことを特
徴とするコンピュータ・プログラムにある。
ム型データ受信処理を実行するコンピュータ・プログラ
ムであって、データ送信装置から受信するデータパケッ
トを受信するパケット受信処理ステップと、前記データ
送信装置から受信するデータパケットのエラーまたはロ
スト・データパケットの検出に基づいて、前記データ送
信装置に対するデータパケット再送要求としての再送要
求メッセージパケットの送信可否を判定する再送要求処
理制御ステップとを有し、前記再送要求処理制御ステッ
プは、再送要求に基づく再送データパケット受信が、再
送データパケット格納データの再生に伴う処理開始時間
前に可能か否かを判定し、可能であるとの判定を条件と
して、再送要求送信を決定するステップを含むことを特
徴とするコンピュータ・プログラムにある。
【００５０】なお、本発明のコンピュータ・プログラム
は、例えば、様々なプログラム・コードを実行可能な汎
用コンピュータ・システムに対して、コンピュータ可読
な形式で提供する記憶媒体、通信媒体、例えば、ＣＤや
ＦＤ、ＭＯなどの記録媒体、あるいは、ネットワークな
どの通信媒体によって提供可能なコンピュータ・プログ
ラムである。このようなプログラムをコンピュータ可読
な形式で提供することにより、コンピュータ・システム
上でプログラムに応じた処理が実現される。
は、例えば、様々なプログラム・コードを実行可能な汎
用コンピュータ・システムに対して、コンピュータ可読
な形式で提供する記憶媒体、通信媒体、例えば、ＣＤや
ＦＤ、ＭＯなどの記録媒体、あるいは、ネットワークな
どの通信媒体によって提供可能なコンピュータ・プログ
ラムである。このようなプログラムをコンピュータ可読
な形式で提供することにより、コンピュータ・システム
上でプログラムに応じた処理が実現される。
【００５１】本発明のさらに他の目的、特徴や利点は、
後述する本発明の実施例や添付する図面に基づくより詳
細な説明によって明らかになるであろう。なお、本明細
書においてシステムとは、複数の装置の論理的集合構成
であり、各構成の装置が同一筐体内にあるものには限ら
ない。
後述する本発明の実施例や添付する図面に基づくより詳
細な説明によって明らかになるであろう。なお、本明細
書においてシステムとは、複数の装置の論理的集合構成
であり、各構成の装置が同一筐体内にあるものには限ら
ない。
【００５２】
【発明の実施の形態】［システム及びデータ送受信概
要］まず、図１を参照して、本発明のシステム概要及び
データ送受信処理の概要について説明する。
要］まず、図１を参照して、本発明のシステム概要及び
データ送受信処理の概要について説明する。
【００５３】図１のデータ通信システムにおいて、送信
側端末１０４は受信側端末１２１に対して画像、音声等
のデータをパケット化して送信する。転送データは、例
えばビデオカメラ１０１によって取得された画像、音声
データである。なお、転送データは、ＣＤ，ＤＶＤ等の
記憶媒体から入力されるデータ、あるいは外部ネットワ
ーク、衛星等から受信するデータ等であってもよい。な
お、以下の説明では、１つの例として送信側端末１０４
から受信側端末１２１へビデオカメラ１０１によって取
得された動画像データを転送する構成を中心として説明
する。
側端末１０４は受信側端末１２１に対して画像、音声等
のデータをパケット化して送信する。転送データは、例
えばビデオカメラ１０１によって取得された画像、音声
データである。なお、転送データは、ＣＤ，ＤＶＤ等の
記憶媒体から入力されるデータ、あるいは外部ネットワ
ーク、衛星等から受信するデータ等であってもよい。な
お、以下の説明では、１つの例として送信側端末１０４
から受信側端末１２１へビデオカメラ１０１によって取
得された動画像データを転送する構成を中心として説明
する。
【００５４】ビデオカメラ１０１によって取得された動
画像データは、送信側端末１０４の符号化装置１０２に
より符号化、例えばＭＰＥＧ圧縮処理等による符号化が
なされて、バッファ１０３に蓄積される。バッファ１０
３に蓄積された符号化データは、リアルタイム・トラン
スポート・プロトコル：ＲＴＰ（Real-time Transport
Protocol）に従ったデータ・パケット（以下パケットと
称する）を生成するＲＴＰパケット作成部１０６に出力
され、符号化データを格納したＲＴＰパケットのパケッ
ト生成処理が実行される。ＲＴＰパケット作成部１０６
において生成された符号化データを格納したＲＴＰパケ
ットは、ＲＴＰプロトコルを通じてＲＴＰパケット出力
ポート１１０からＩＰネットワーク１１１に送出され
る。送信側端末１０４のＲＴＰパケット作成部１０６お
よびＲＴＰパケット出力ポートによってパケット送信処
理部が構成される。
画像データは、送信側端末１０４の符号化装置１０２に
より符号化、例えばＭＰＥＧ圧縮処理等による符号化が
なされて、バッファ１０３に蓄積される。バッファ１０
３に蓄積された符号化データは、リアルタイム・トラン
スポート・プロトコル：ＲＴＰ（Real-time Transport
Protocol）に従ったデータ・パケット（以下パケットと
称する）を生成するＲＴＰパケット作成部１０６に出力
され、符号化データを格納したＲＴＰパケットのパケッ
ト生成処理が実行される。ＲＴＰパケット作成部１０６
において生成された符号化データを格納したＲＴＰパケ
ットは、ＲＴＰプロトコルを通じてＲＴＰパケット出力
ポート１１０からＩＰネットワーク１１１に送出され
る。送信側端末１０４のＲＴＰパケット作成部１０６お
よびＲＴＰパケット出力ポートによってパケット送信処
理部が構成される。
【００５５】ＲＴＰパケット作成部１０６は、符号化デ
ータをペイロードとしたパケットを生成する処理を実行
する。ペイロードデータに対して、ＲＴＰヘッダを付加
しパケット化する。ＲＴＰパケット構成を図２に示す。
ＲＴＰヘッダには、バージョン番号（ｖ）、パディング
（Ｐ）、拡張ヘッダ（Ｘ）の有無、送信元数（Ｃｏｕｎ
ｔｅｒ）、マーカ情報（ｍａｒｋｅｒ ｂｉｔ）、ペイ
ロードタイプ（Ｐａｙｌｏａｄ ｔｙｐｅ）、シーケン
ス番号、タイムスタンプ、同期ソース（送信元）識別子
（ＳＳＲＣ）および貢献ソース（送信元）識別子（ＣＳ
ＲＣ）の各フィールドが設けられている。データ受信側
において、ＲＴＰヘッダに付与されたタイムスタンプに
よりＲＴＰパケットの展開時に処理時間の制御が実行さ
れ、リアルタイム画像、または音声の再生制御が可能と
なる。なお、例えば動画像データの符号化データを格納
したＲＴＰパケットにおいては、１つの画像フレームに
属する複数のＲＴＰパケットに共通のタイムスタンプが
設定され、各フレームを構成する終端パケットには、終
端であることを示す識別フラグがＲＴＰヘッダに格納さ
れる。
ータをペイロードとしたパケットを生成する処理を実行
する。ペイロードデータに対して、ＲＴＰヘッダを付加
しパケット化する。ＲＴＰパケット構成を図２に示す。
ＲＴＰヘッダには、バージョン番号（ｖ）、パディング
（Ｐ）、拡張ヘッダ（Ｘ）の有無、送信元数（Ｃｏｕｎ
ｔｅｒ）、マーカ情報（ｍａｒｋｅｒ ｂｉｔ）、ペイ
ロードタイプ（Ｐａｙｌｏａｄ ｔｙｐｅ）、シーケン
ス番号、タイムスタンプ、同期ソース（送信元）識別子
（ＳＳＲＣ）および貢献ソース（送信元）識別子（ＣＳ
ＲＣ）の各フィールドが設けられている。データ受信側
において、ＲＴＰヘッダに付与されたタイムスタンプに
よりＲＴＰパケットの展開時に処理時間の制御が実行さ
れ、リアルタイム画像、または音声の再生制御が可能と
なる。なお、例えば動画像データの符号化データを格納
したＲＴＰパケットにおいては、１つの画像フレームに
属する複数のＲＴＰパケットに共通のタイムスタンプが
設定され、各フレームを構成する終端パケットには、終
端であることを示す識別フラグがＲＴＰヘッダに格納さ
れる。
【００５６】ＲＴＰヘッダを付加されたパケットはさら
にＩＰヘッダが付与される。図３にＩＰパケットの構成
中のＩＰヘッダの詳細を示す。ＩＰｖ４、ＩＰｖ６等の
バージョンを示すバージョン、ヘッダ長、さらに、優先
度情報を格納したＴＯＳ（Type of Service）フィール
ド、パケットの長さ、パケットの識別子、ＩＰ層でのデ
ータ分割（フラグメント）に関する制御情報としてのフ
ラグ、分割（フラグメント）されたデータの場所を示す
断片オフセット、データの破棄までの時間情報を示すＴ
ＴＬ（Time to Live）、上位層で利用されるプロトコル
（４：ＩＰ，ＴＣＰ：７，ＵＤＰ：１７…）ヘッダのチ
ェックサム、送信元ＩＰアドレス、宛て先ＩＰアドレス
を有する。
にＩＰヘッダが付与される。図３にＩＰパケットの構成
中のＩＰヘッダの詳細を示す。ＩＰｖ４、ＩＰｖ６等の
バージョンを示すバージョン、ヘッダ長、さらに、優先
度情報を格納したＴＯＳ（Type of Service）フィール
ド、パケットの長さ、パケットの識別子、ＩＰ層でのデ
ータ分割（フラグメント）に関する制御情報としてのフ
ラグ、分割（フラグメント）されたデータの場所を示す
断片オフセット、データの破棄までの時間情報を示すＴ
ＴＬ（Time to Live）、上位層で利用されるプロトコル
（４：ＩＰ，ＴＣＰ：７，ＵＤＰ：１７…）ヘッダのチ
ェックサム、送信元ＩＰアドレス、宛て先ＩＰアドレス
を有する。
【００５７】図１に戻り、データ受信処理について説明
する。受信側端末１２１のＲＴＰパケット入力ポート１
１２は、ＩＰネットワーク１１１を介して送信側端末１
０４からのＲＴＰパケットを受信する。受信したＲＴＰ
パケットは、パケット解析部１１４においてパケットの
解析が実行される。受信側端末１２１のＲＴＰパケット
入力ポート１１２および、パケット解析部１１４によっ
てパケット受信処理部が構成される。パケット解析部１
１４は、具体的にはパケット内のヘッダ部、データ部に
ついての解析が実行される。パケットから取り出された
ペイロードとしてのデータ、すなわち、符号化データ
は、バッファ１１７に蓄積される。また、パケットから
抽出されたデータのバッファの蓄積位置を示す位置デー
タや、各データに対応するパケットのヘッダ情報は、イ
ンデックスリスト１１８として蓄積される。
する。受信側端末１２１のＲＴＰパケット入力ポート１
１２は、ＩＰネットワーク１１１を介して送信側端末１
０４からのＲＴＰパケットを受信する。受信したＲＴＰ
パケットは、パケット解析部１１４においてパケットの
解析が実行される。受信側端末１２１のＲＴＰパケット
入力ポート１１２および、パケット解析部１１４によっ
てパケット受信処理部が構成される。パケット解析部１
１４は、具体的にはパケット内のヘッダ部、データ部に
ついての解析が実行される。パケットから取り出された
ペイロードとしてのデータ、すなわち、符号化データ
は、バッファ１１７に蓄積される。また、パケットから
抽出されたデータのバッファの蓄積位置を示す位置デー
タや、各データに対応するパケットのヘッダ情報は、イ
ンデックスリスト１１８として蓄積される。
【００５８】バッファ１１７に蓄積された符号化データ
は、インデックスリスト１１８に蓄積されたヘッダ情報
に基づく時間制御の下にデコーダ１２０に渡され、デコ
ーダ１２０によって復号処理が実行される。例えば動画
像を構成する各画像フレームは、複数のパケットに格納
されたデータによって構成され、１つの画像フレームを
構成するデータを格納した複数のＲＴＰパケットのヘッ
ダには、同一のタイムスタンプが格納されるので、イン
デックスリスト１１８に蓄積されたヘッダ情報のタイム
スタンプを参照して同一タイムスタンプを持つパケット
を１つの画像フレームを構成する符号化データの集合と
して、デコーダ１２０に渡すことが可能となり、デコー
ダ１２０は、フレーム毎に復号処理を実行することがで
きる。デコーダ１２０において復号されたデータは、再
生装置としてのディスプレイ１２３、またはスピーカ１
２２へ渡され、出力再生される。
は、インデックスリスト１１８に蓄積されたヘッダ情報
に基づく時間制御の下にデコーダ１２０に渡され、デコ
ーダ１２０によって復号処理が実行される。例えば動画
像を構成する各画像フレームは、複数のパケットに格納
されたデータによって構成され、１つの画像フレームを
構成するデータを格納した複数のＲＴＰパケットのヘッ
ダには、同一のタイムスタンプが格納されるので、イン
デックスリスト１１８に蓄積されたヘッダ情報のタイム
スタンプを参照して同一タイムスタンプを持つパケット
を１つの画像フレームを構成する符号化データの集合と
して、デコーダ１２０に渡すことが可能となり、デコー
ダ１２０は、フレーム毎に復号処理を実行することがで
きる。デコーダ１２０において復号されたデータは、再
生装置としてのディスプレイ１２３、またはスピーカ１
２２へ渡され、出力再生される。
【００５９】送信側端末１０４から受信側端末１２１へ
転送されるパケットが全て滞りなく、また、エラーのな
い状態で送信されれば、受信側端末１２１におけるリア
ルタイムデータ再生は問題なく実行される。しかし、実
際は、ネットワーク上でのパケット損失の発生、遅延、
転送パケットのデータエラー等、様々な要因に基づく再
生エラーあるいは再生データの品質低下が発生し得る。
転送されるパケットが全て滞りなく、また、エラーのな
い状態で送信されれば、受信側端末１２１におけるリア
ルタイムデータ再生は問題なく実行される。しかし、実
際は、ネットワーク上でのパケット損失の発生、遅延、
転送パケットのデータエラー等、様々な要因に基づく再
生エラーあるいは再生データの品質低下が発生し得る。
【００６０】本発明のシステムにおいては、受信側端末
１２１のＲＴＰパケット解析部１１４においてパケット
損失等のエラーの発生を検出し、パケット損失等のエラ
ー発生が検出された際には、ＡＲＱ（Auto Repeat reQu
est）判定部１１９において、リアルタイム再生シーケ
ンスを考慮したパケット再送要求の可否判定処理を実行
する。ＡＲＱ（Auto Repeat reQuest）判定部１１９
は、データ送信装置から受信するデータパケットのエラ
ーまたはロスト・データパケットの検出に基づいて、デ
ータ送信装置に対するデータパケット再送要求としての
再送要求メッセージパケットの送信可否を判定する再送
要求処理制御部として機能する。ＡＲＱ判定部１１９に
おける具体的な処理については後述する。
１２１のＲＴＰパケット解析部１１４においてパケット
損失等のエラーの発生を検出し、パケット損失等のエラ
ー発生が検出された際には、ＡＲＱ（Auto Repeat reQu
est）判定部１１９において、リアルタイム再生シーケ
ンスを考慮したパケット再送要求の可否判定処理を実行
する。ＡＲＱ（Auto Repeat reQuest）判定部１１９
は、データ送信装置から受信するデータパケットのエラ
ーまたはロスト・データパケットの検出に基づいて、デ
ータ送信装置に対するデータパケット再送要求としての
再送要求メッセージパケットの送信可否を判定する再送
要求処理制御部として機能する。ＡＲＱ判定部１１９に
おける具体的な処理については後述する。
【００６１】ＡＲＱ判定部１１９において、再送要求を
実行するとの判定がなされた場合、受信側端末１２１
は、再送要求パケットを識別するデータを格納した再送
要求ＮＡＣＫ（Negative ACKnowledge)−ＲＴＣＰ（Rea
l-time Transport Control Protocol）パケットをＲＴ
ＣＰパケット作成装置１１６にて作成し、ＲＴＣＰパケ
ット入出力ポート１１３を介して、送信側端末１０４に
対して出力する。
実行するとの判定がなされた場合、受信側端末１２１
は、再送要求パケットを識別するデータを格納した再送
要求ＮＡＣＫ（Negative ACKnowledge)−ＲＴＣＰ（Rea
l-time Transport Control Protocol）パケットをＲＴ
ＣＰパケット作成装置１１６にて作成し、ＲＴＣＰパケ
ット入出力ポート１１３を介して、送信側端末１０４に
対して出力する。
【００６２】送信側端末１０４のＲＴＣＰパケット入出
力ポート１０９において、受信側端末１２１からの再送
要求を示すＮＡＣＫ−ＲＴＣＰパケットを受信すると、
受信したＮＡＣＫ−ＲＴＣＰパケットをＲＴＣＰパケッ
ト解析部１０８において解析し、解析結果をＡＲＱ処理
部１０５へ渡す。ＡＲＱ処理部１０５では、再送要求に
応じたパケットの再送を実行するため、ＮＡＣＫ−ＲＴ
ＣＰパケットにおいて指定されたパケットをバッファ１
０３から抽出し、抽出したパケットを、ＲＴＰパケット
出力ポート１１０を介して再送する制御処理を実行す
る。ＡＲＱ処理部１０５は、データ受信端末装置から受
信する再送要求メッセージパケットに従って再送すべき
データパケットの抽出処理を実行する再送制御部として
機能する。なお、ＮＡＣＫ−ＲＴＣＰパケットに基づく
再送要求に応じたパケット再送処理において、送信側端
末１０４は、ＮＡＣＫ−ＲＴＣＰパケットに重複送信の
指定がある場合等、必要に応じてＡＲＱ処理部１０５の
判断により再送パケットを重複して送る場合もある。こ
れらの処理の詳細については、後述する。
力ポート１０９において、受信側端末１２１からの再送
要求を示すＮＡＣＫ−ＲＴＣＰパケットを受信すると、
受信したＮＡＣＫ−ＲＴＣＰパケットをＲＴＣＰパケッ
ト解析部１０８において解析し、解析結果をＡＲＱ処理
部１０５へ渡す。ＡＲＱ処理部１０５では、再送要求に
応じたパケットの再送を実行するため、ＮＡＣＫ−ＲＴ
ＣＰパケットにおいて指定されたパケットをバッファ１
０３から抽出し、抽出したパケットを、ＲＴＰパケット
出力ポート１１０を介して再送する制御処理を実行す
る。ＡＲＱ処理部１０５は、データ受信端末装置から受
信する再送要求メッセージパケットに従って再送すべき
データパケットの抽出処理を実行する再送制御部として
機能する。なお、ＮＡＣＫ−ＲＴＣＰパケットに基づく
再送要求に応じたパケット再送処理において、送信側端
末１０４は、ＮＡＣＫ−ＲＴＣＰパケットに重複送信の
指定がある場合等、必要に応じてＡＲＱ処理部１０５の
判断により再送パケットを重複して送る場合もある。こ
れらの処理の詳細については、後述する。
【００６３】送信側端末１０４において送信すべきスト
リームデータが終了したのを検知した場合には、送信側
端末１０４のＲＴＣＰパケット作成部１０７の生成した
ＥＯＳ（End Of Stream）メッセージを持つＲＴＣＰパ
ケットを受信側端末１２１へ送り、データストリームの
終了を明示する。
リームデータが終了したのを検知した場合には、送信側
端末１０４のＲＴＣＰパケット作成部１０７の生成した
ＥＯＳ（End Of Stream）メッセージを持つＲＴＣＰパ
ケットを受信側端末１２１へ送り、データストリームの
終了を明示する。
【００６４】本発明のシステムにおいては、ＡＲＱ処理
部１０５において、リアルタイム再生を考慮して、ロス
トパケットに関する再送要求の実行／非実行の処理を決
定する。データ転送における自動再送要求方式であるＡ
ＲＱ（Automatic Repeat reQuest）は非常に有効な誤り
訂正機能として知られている。ＡＲＱの具体的方式とし
ては、例えばＳＡＷ（Stop And Wait）方式、ＧＢＮ（G
o Back N）方式、ＳＲ（Selective Repeat）方式など種
々の方法が提案され実現されている。本実施例において
は、ＡＲＱ基本アルゴリズムとして、スループット特性
が高い選択再送ＳＲ（Selective Repeat）方式エラー訂
正機能として使用する例について説明する。
部１０５において、リアルタイム再生を考慮して、ロス
トパケットに関する再送要求の実行／非実行の処理を決
定する。データ転送における自動再送要求方式であるＡ
ＲＱ（Automatic Repeat reQuest）は非常に有効な誤り
訂正機能として知られている。ＡＲＱの具体的方式とし
ては、例えばＳＡＷ（Stop And Wait）方式、ＧＢＮ（G
o Back N）方式、ＳＲ（Selective Repeat）方式など種
々の方法が提案され実現されている。本実施例において
は、ＡＲＱ基本アルゴリズムとして、スループット特性
が高い選択再送ＳＲ（Selective Repeat）方式エラー訂
正機能として使用する例について説明する。
【００６５】ＳＲ方式の場合、理想的には送信側と受信
側で無限のバッファを用意する必要がある。そのため、
受信側のバッファオーバーフローが起こった時点または
起こりそうな時点でＳＲ方式から別の再送方式に変更す
る方法やパケットのコピー伝送を通常から行いオーバー
フローを回避する方法などが提案されている。しかしな
がら、本実施例におけるエラー訂正機能においては、Ｐ
ＨＳ、ＴＣＰ、データリンク層などに代表される完全に
データを送信することを第一優先にしているＡＲＱと異
なり、データ受信側で実行される受信データの再生処理
時間から想定されるパケット受信最終許容時間までに、
できるだけ必要なデータの受信を実現する事を優先して
いる。よって、ＳＲ方式からＳＴ方式やＧＢＮ方式には
移行せず、ＳＲ方式のままＡＲＱを行う構成としてい
る。また、バッファフローオーバーにならないよう受信
側はバッファ制御を行い効率よくデータを送信する構成
とする。
側で無限のバッファを用意する必要がある。そのため、
受信側のバッファオーバーフローが起こった時点または
起こりそうな時点でＳＲ方式から別の再送方式に変更す
る方法やパケットのコピー伝送を通常から行いオーバー
フローを回避する方法などが提案されている。しかしな
がら、本実施例におけるエラー訂正機能においては、Ｐ
ＨＳ、ＴＣＰ、データリンク層などに代表される完全に
データを送信することを第一優先にしているＡＲＱと異
なり、データ受信側で実行される受信データの再生処理
時間から想定されるパケット受信最終許容時間までに、
できるだけ必要なデータの受信を実現する事を優先して
いる。よって、ＳＲ方式からＳＴ方式やＧＢＮ方式には
移行せず、ＳＲ方式のままＡＲＱを行う構成としてい
る。また、バッファフローオーバーにならないよう受信
側はバッファ制御を行い効率よくデータを送信する構成
とする。
【００６６】本発明の１つの実施例では、送信中にロス
トしてしまったパケットの再送要求は、RFC1889 で規定
されているＲＴＣＰ（Real-time Transport Control Pr
otocol）に従って、ＮＡＣＫ（Negative ACKnowledge)
を送ることで実現する。RFC1889ではＲＴＣＰパケット
の連続送信間隔を５秒以上あける事を推奨している。こ
こで再送要求を５秒以上間隔を空けたとすると、受信側
のバッファ溢れが生じるだけでなく、そもそもメディア
の再生時間に間に合うように再送することができない。
ストリーミングはリアルタイム性が強い分、＊できるだ
け早く再送要求を出す＊再送要求を受信したらできるだ
け早いうちに再送するという動作を可能な時間内に実施
しなければならない。そのために、ＡＲＱに用いるＮＡ
ＣＫパケットは、データ受信側において能動的に随時必
要に応じてデータ送信側に対して送信することが必要と
なり、推奨値を本発明の場合は適用せず、任意タイミン
グでのＮＡＣＫパケット送信を実行するものとする。
トしてしまったパケットの再送要求は、RFC1889 で規定
されているＲＴＣＰ（Real-time Transport Control Pr
otocol）に従って、ＮＡＣＫ（Negative ACKnowledge)
を送ることで実現する。RFC1889ではＲＴＣＰパケット
の連続送信間隔を５秒以上あける事を推奨している。こ
こで再送要求を５秒以上間隔を空けたとすると、受信側
のバッファ溢れが生じるだけでなく、そもそもメディア
の再生時間に間に合うように再送することができない。
ストリーミングはリアルタイム性が強い分、＊できるだ
け早く再送要求を出す＊再送要求を受信したらできるだ
け早いうちに再送するという動作を可能な時間内に実施
しなければならない。そのために、ＡＲＱに用いるＮＡ
ＣＫパケットは、データ受信側において能動的に随時必
要に応じてデータ送信側に対して送信することが必要と
なり、推奨値を本発明の場合は適用せず、任意タイミン
グでのＮＡＣＫパケット送信を実行するものとする。
【００６７】また、RFC1889ではＲＴＣＰのバンド幅を
５％以内になるよう規定している。本発明の実施例に係
る構成の再送パケットは最小単位で１６ｂｙｔｅと小さ
いため、再送要求によって帯域を圧迫するほどのもので
はないと考えられる。なお、画像データ等の実データ自
体の伝送には、RFC1889で規定されているＲＴＰ（パケ
ットフォーマットは図２参照）を用いる例について説明
するが、パケット毎にシーケンス番号を記述しておけ
ば、ＵＤＰ（User Datagram Protocol）等、他のプロト
コルに従った処理も可能である。
５％以内になるよう規定している。本発明の実施例に係
る構成の再送パケットは最小単位で１６ｂｙｔｅと小さ
いため、再送要求によって帯域を圧迫するほどのもので
はないと考えられる。なお、画像データ等の実データ自
体の伝送には、RFC1889で規定されているＲＴＰ（パケ
ットフォーマットは図２参照）を用いる例について説明
するが、パケット毎にシーケンス番号を記述しておけ
ば、ＵＤＰ（User Datagram Protocol）等、他のプロト
コルに従った処理も可能である。
【００６８】リアルタイム再生を実現するデータ転送で
は、処理時間が限定されるため、送信と受信における往
復伝播遅延（ＲＴＴ）が重要なパラメータとなる。往復
伝播遅延（ＲＴＴ）が大きい場合、データ受信端末から
データ送信端末に対して再送要求を出しても、再送要求
パケットがデータ送信端末側に到着するまでの時間、デ
ータ送信端末において指定データを格納した再送パケッ
トを抽出して再送処理を実行するまでの時間、再送パケ
ットをデータ受信端末が受信するまでの時間、これらの
処理に時間を要すると、その後、データ受信端末におい
て、デコーダに受信データを渡して復号を行なっても、
リアルタイム再生に間に合わない場合が発生する。無
論、間に合う間に合わないかかわらず再送要求を出して
おく方が、訂正率の向上が達成される可能性は大となる
が、再送要求パケットの送信、再送パケットの再送によ
るネットワークトラフィックの混雑が発生することにな
り、これらの冗長データの伝送によるオーバーヘッドの
問題が発生することになる。
は、処理時間が限定されるため、送信と受信における往
復伝播遅延（ＲＴＴ）が重要なパラメータとなる。往復
伝播遅延（ＲＴＴ）が大きい場合、データ受信端末から
データ送信端末に対して再送要求を出しても、再送要求
パケットがデータ送信端末側に到着するまでの時間、デ
ータ送信端末において指定データを格納した再送パケッ
トを抽出して再送処理を実行するまでの時間、再送パケ
ットをデータ受信端末が受信するまでの時間、これらの
処理に時間を要すると、その後、データ受信端末におい
て、デコーダに受信データを渡して復号を行なっても、
リアルタイム再生に間に合わない場合が発生する。無
論、間に合う間に合わないかかわらず再送要求を出して
おく方が、訂正率の向上が達成される可能性は大となる
が、再送要求パケットの送信、再送パケットの再送によ
るネットワークトラフィックの混雑が発生することにな
り、これらの冗長データの伝送によるオーバーヘッドの
問題が発生することになる。
【００６９】また、送信と受信における往復伝播遅延
（ＲＴＴ）をデータ受信端末において、あらかじめ把握
することにより、データ受信端末において、再送要求を
行なってから再送パケットを受信するまでの時間の把握
が可能となり、データ受信端末においてリアルタイム再
生を行なうために必要な最終再送要求時間を割り出すこ
とが可能なる。本発明のシステムでは、受信端末のＡＲ
Ｑ判定部において、往復伝播遅延（ＲＴＴ）に基づく最
終再送要求時間を判定し、判定に基づいて、再送要求と
してのＮＡＣＫ−ＲＴＣＰの送信を実行する。
（ＲＴＴ）をデータ受信端末において、あらかじめ把握
することにより、データ受信端末において、再送要求を
行なってから再送パケットを受信するまでの時間の把握
が可能となり、データ受信端末においてリアルタイム再
生を行なうために必要な最終再送要求時間を割り出すこ
とが可能なる。本発明のシステムでは、受信端末のＡＲ
Ｑ判定部において、往復伝播遅延（ＲＴＴ）に基づく最
終再送要求時間を判定し、判定に基づいて、再送要求と
してのＮＡＣＫ−ＲＴＣＰの送信を実行する。
【００７０】このように、ＡＲＱにおいてリアルタイム
性を保持するためには、常に送信と受信における往復伝
播遅延（ＲＴＴ）を計測しておく必要がある。本発明の
システムでは、データ受信側端末は、能動的にＲＴＴを
計測し、ネットワーク状況等において変化する送信と受
信における往復伝播遅延（ＲＴＴ）の更新を実行し、最
新のＲＴＴに基づいて再送要求としてのＮＡＣＫ−ＲＴ
ＣＰの送信の実行可否を判定する。
性を保持するためには、常に送信と受信における往復伝
播遅延（ＲＴＴ）を計測しておく必要がある。本発明の
システムでは、データ受信側端末は、能動的にＲＴＴを
計測し、ネットワーク状況等において変化する送信と受
信における往復伝播遅延（ＲＴＴ）の更新を実行し、最
新のＲＴＴに基づいて再送要求としてのＮＡＣＫ−ＲＴ
ＣＰの送信の実行可否を判定する。
【００７１】なお、ＲＴＣＰに規定されたＳＲ（Sender
Report）とＲＲ（Receiver Report）により送信側はＲ
ＴＴの算出が可能となるが、リアルタイム再生の進行状
況に基づいて、再送要求としてのＮＡＣＫ−ＲＴＣＰパ
ケットを送出するかしないかを判定するのは、データ受
信側端末であり、データ受信側端末において、逐次、ネ
ットワーク状況を反映したＲＴＴ情報を取得可能とする
構成が好ましい。従って、本発明のシステムにおいて
は、データ受信端末側から能動的にＲＴＴを算出可能な
構成としている。具体的には、データ受信端末における
ＥＣＨＯパケットの送信、ＥＣＨＯ−ＲＥＰＬＹパケッ
トの受信により、ＲＴＴの算出を行なう。これらの処理
については、後段で詳細に説明する。
Report）とＲＲ（Receiver Report）により送信側はＲ
ＴＴの算出が可能となるが、リアルタイム再生の進行状
況に基づいて、再送要求としてのＮＡＣＫ−ＲＴＣＰパ
ケットを送出するかしないかを判定するのは、データ受
信側端末であり、データ受信側端末において、逐次、ネ
ットワーク状況を反映したＲＴＴ情報を取得可能とする
構成が好ましい。従って、本発明のシステムにおいて
は、データ受信端末側から能動的にＲＴＴを算出可能な
構成としている。具体的には、データ受信端末における
ＥＣＨＯパケットの送信、ＥＣＨＯ−ＲＥＰＬＹパケッ
トの受信により、ＲＴＴの算出を行なう。これらの処理
については、後段で詳細に説明する。
【００７２】データ送信端末は、データ受信端末からの
パケット再送要求としてのＮＡＣＫ−ＲＴＣＰパケット
を受信すると、ＮＡＣＫ−ＲＴＣＰパケットに指定され
た再送要求パケットを、現在配信中のパケットと共に送
信する。ただし、データ送信端末は、プライオリティを
用いた配信スケジューリング機能を実行し、パケットの
再送は、配信スケジューリングに従って実行される。
パケット再送要求としてのＮＡＣＫ−ＲＴＣＰパケット
を受信すると、ＮＡＣＫ−ＲＴＣＰパケットに指定され
た再送要求パケットを、現在配信中のパケットと共に送
信する。ただし、データ送信端末は、プライオリティを
用いた配信スケジューリング機能を実行し、パケットの
再送は、配信スケジューリングに従って実行される。
【００７３】受信端末側から送信端末への応答パケット
として、パケット再送要求としてのＮＡＣＫ−ＲＴＣＰ
パケットのみを使用する構成としても、自動再送要求方
式としてのＡＲＱ（Automatic Repeat reQuest）を有効
に活用することができるが、本実施例においては、受信
端末側からのパケット受信確認応答としてのＡＣＫ（AC
Knowledge）メッセージもデータ送信端末に対する応答
パケットとして送信する。このＡＣＫ送信により、再送
要求に対応してパケットを保持する送信側のバッファを
能動的に早めにクリアすることが可能となり、バッファ
溢れの恐れを低下させることが可能となる。
として、パケット再送要求としてのＮＡＣＫ−ＲＴＣＰ
パケットのみを使用する構成としても、自動再送要求方
式としてのＡＲＱ（Automatic Repeat reQuest）を有効
に活用することができるが、本実施例においては、受信
端末側からのパケット受信確認応答としてのＡＣＫ（AC
Knowledge）メッセージもデータ送信端末に対する応答
パケットとして送信する。このＡＣＫ送信により、再送
要求に対応してパケットを保持する送信側のバッファを
能動的に早めにクリアすることが可能となり、バッファ
溢れの恐れを低下させることが可能となる。
【００７４】また、ストリーミング配信されるデータが
終了したことを明示的に示すＥＯＳ（End Of Stream）
メッセージを送信端末側は利用できる。ＥＯＳメッセー
ジを使うことにより、受信側がストリーミング配信デー
タの終了を認識可能となる。従って、受信側が最終フレ
ームを受け取っているにもかかわらず、次のフレームが
到着しないことによるＮＡＣＫ送出動作を防ぐことがで
きる。
終了したことを明示的に示すＥＯＳ（End Of Stream）
メッセージを送信端末側は利用できる。ＥＯＳメッセー
ジを使うことにより、受信側がストリーミング配信デー
タの終了を認識可能となる。従って、受信側が最終フレ
ームを受け取っているにもかかわらず、次のフレームが
到着しないことによるＮＡＣＫ送出動作を防ぐことがで
きる。
【００７５】受信端末側は、受信端末側で保持するタイ
マーにより、データ受信間隔、ＮＡＣＫ送出後の経過時
間等を計測可能であり、タイマーによる計測時間が閾値
以上となったことにより、データ終了と判定する処理が
可能であるが、ＥＯＳメッセージの受信により、ストリ
ーミング配信データの終了確認が可能となる。従って、
タイマーより先に受信完了状態とすることができる。逆
に、ＥＯＳメッセージを利用しない、またはＥＯＳがロ
ストしてしまった場合は、ＮＡＣＫを送出しても送信側
から再送パケットが送られてこないため、タイマーによ
って受信完了状態に移ることになる。
マーにより、データ受信間隔、ＮＡＣＫ送出後の経過時
間等を計測可能であり、タイマーによる計測時間が閾値
以上となったことにより、データ終了と判定する処理が
可能であるが、ＥＯＳメッセージの受信により、ストリ
ーミング配信データの終了確認が可能となる。従って、
タイマーより先に受信完了状態とすることができる。逆
に、ＥＯＳメッセージを利用しない、またはＥＯＳがロ
ストしてしまった場合は、ＮＡＣＫを送出しても送信側
から再送パケットが送られてこないため、タイマーによ
って受信完了状態に移ることになる。
【００７６】［データ送信端末における処理］以下、図
面を参照しながら、データ送信端末における処理の詳細
について説明する。
面を参照しながら、データ送信端末における処理の詳細
について説明する。
【００７７】データ送信端末の処理手順を図４に示すフ
ローチャートを参照して説明する。図４に示す処理は、
図１の送信側端末１０４において実行される処理を説明
したフローである。送信側端末は、例えばビデオカメ
ラ、あるいはＤＶＤ、ＣＤ、ハードディスク等の記憶媒
体から撮り込んだデータをエンコーダにおいてＭＰＥＧ
圧縮等の符号化処理を実行し、その後、符号化データを
ペイロードとしたパケットを生成する。図４に示すフロ
ーは、このパケット生成処理以降の処理を示している。
ローチャートを参照して説明する。図４に示す処理は、
図１の送信側端末１０４において実行される処理を説明
したフローである。送信側端末は、例えばビデオカメ
ラ、あるいはＤＶＤ、ＣＤ、ハードディスク等の記憶媒
体から撮り込んだデータをエンコーダにおいてＭＰＥＧ
圧縮等の符号化処理を実行し、その後、符号化データを
ペイロードとしたパケットを生成する。図４に示すフロ
ーは、このパケット生成処理以降の処理を示している。
【００７８】データ送信端末は、ステップＳ２０１にお
いて、送信データをペイロードとしたＲＴＰパケット生
成処理を実行する。ＲＴＰパケットは、先に図２を参照
して説明した構成を有しタイムスタンプをヘッダ中に持
つ。例えば動画像データを送信する場合は、同一画像フ
レームに属する符号化データを格納したパケットには同
一のタイムスタンプが設定され、後続フレームに進むに
従って、増分されたタイムスタンプが設定される。
いて、送信データをペイロードとしたＲＴＰパケット生
成処理を実行する。ＲＴＰパケットは、先に図２を参照
して説明した構成を有しタイムスタンプをヘッダ中に持
つ。例えば動画像データを送信する場合は、同一画像フ
レームに属する符号化データを格納したパケットには同
一のタイムスタンプが設定され、後続フレームに進むに
従って、増分されたタイムスタンプが設定される。
【００７９】図５に示すパケット送信に係るタイムシー
ケンス図を参照して、タイムスタンプの設定例を説明す
る。データ送信側（Ｓｅｎｄｅｒ）に示すタイムスタン
プ１２０００は、１つの画像フレームを構成する符号化
データをペイロードとして格納した複数のＲＴＰパケッ
ト（シーケンス番号＝１〜６）に付与されるタイムスタ
ンプである。その後のタイムスタンプ１５０００は、後
続画像フレームを構成するＲＴＰパケット（シーケンス
番号＝７〜１２）と、データ受信側からＮＡＣＫ−ＲＴ
ＣＰパケットによる再送要求があり、再送するパケット
（シーケンス番号＝４，５）とに設定されるタイムスタ
ンプである。このように、データ送信端末では、例えば
画像フレームを構成するパケットの集合に１つのタイム
スタンプを設定してＲＴＰパケットを生成する。
ケンス図を参照して、タイムスタンプの設定例を説明す
る。データ送信側（Ｓｅｎｄｅｒ）に示すタイムスタン
プ１２０００は、１つの画像フレームを構成する符号化
データをペイロードとして格納した複数のＲＴＰパケッ
ト（シーケンス番号＝１〜６）に付与されるタイムスタ
ンプである。その後のタイムスタンプ１５０００は、後
続画像フレームを構成するＲＴＰパケット（シーケンス
番号＝７〜１２）と、データ受信側からＮＡＣＫ−ＲＴ
ＣＰパケットによる再送要求があり、再送するパケット
（シーケンス番号＝４，５）とに設定されるタイムスタ
ンプである。このように、データ送信端末では、例えば
画像フレームを構成するパケットの集合に１つのタイム
スタンプを設定してＲＴＰパケットを生成する。
【００８０】図４に戻り、データ送信端末の処理につい
て説明を続ける。ステップＳ２０１で生成したＲＴＰパ
ケットは、ステップＳ２０２において、ＲＴＰパケット
出力ポートを介して受信端末に向けてＩＰネットワーク
に出力される。なお、ＲＴＰパケットはさらに、先に図
３を用いて説明したＩＰヘッダが付与され、ＩＰヘッダ
に設定されたアドレスに向けて配信されることになる。
ステップＳ２０１、Ｓ２０２のパケット生成、パケット
送信処理は、ストリーミング配信されるデータが終了し
たことを明示的に示すＥＯＳ（End Of Stream）を配信
し、予め設定した時間をタイマーで計測して、タイマー
での計測時間が設定時間を超えた場合に、処理を終了す
る。
て説明を続ける。ステップＳ２０１で生成したＲＴＰパ
ケットは、ステップＳ２０２において、ＲＴＰパケット
出力ポートを介して受信端末に向けてＩＰネットワーク
に出力される。なお、ＲＴＰパケットはさらに、先に図
３を用いて説明したＩＰヘッダが付与され、ＩＰヘッダ
に設定されたアドレスに向けて配信されることになる。
ステップＳ２０１、Ｓ２０２のパケット生成、パケット
送信処理は、ストリーミング配信されるデータが終了し
たことを明示的に示すＥＯＳ（End Of Stream）を配信
し、予め設定した時間をタイマーで計測して、タイマー
での計測時間が設定時間を超えた場合に、処理を終了す
る。
【００８１】図４に示すステップＳ２０３のパケット再
送要求としてのＮＡＣＫ−ＲＴＣＰパケットの受信判定
処理、ステップＳ２０４のパケット受信確認応答として
のＡＣＫ−ＲＴＣＰパケットの受信判定処理、ステップ
Ｓ２０５のＲＴＴ時間計測用のＥＣＨＯ−ＲＴＣＰパケ
ットの受信判定処理は、ＲＴＰパケットによる実データ
送信中の割込み処理としてＲＴＰパケットによる実デー
タ送信に並行して逐次実行される処理である。
送要求としてのＮＡＣＫ−ＲＴＣＰパケットの受信判定
処理、ステップＳ２０４のパケット受信確認応答として
のＡＣＫ−ＲＴＣＰパケットの受信判定処理、ステップ
Ｓ２０５のＲＴＴ時間計測用のＥＣＨＯ−ＲＴＣＰパケ
ットの受信判定処理は、ＲＴＰパケットによる実データ
送信中の割込み処理としてＲＴＰパケットによる実デー
タ送信に並行して逐次実行される処理である。
【００８２】ステップＳ２０３の処理は、データ受信端
末からのパケット再送要求であるＮＡＣＫ−ＲＴＣＰパ
ケットの受信判定処理である。データ受信端末からのパ
ケット再送要求であるＮＡＣＫ−ＲＴＣＰパケットを受
信した場合は、ステップＳ２１１〜Ｓ２１５の処理を実
行する。このステップＳ２１１〜Ｓ２１５の処理は、図
１に示すＡＲＱ処理部１０５における処理として実行さ
れる。
末からのパケット再送要求であるＮＡＣＫ−ＲＴＣＰパ
ケットの受信判定処理である。データ受信端末からのパ
ケット再送要求であるＮＡＣＫ−ＲＴＣＰパケットを受
信した場合は、ステップＳ２１１〜Ｓ２１５の処理を実
行する。このステップＳ２１１〜Ｓ２１５の処理は、図
１に示すＡＲＱ処理部１０５における処理として実行さ
れる。
【００８３】ステップＳ２１１においては、データ送信
装置は、ＮＡＣＫ−ＲＴＣＰパケットを受信する。図６
にデータ受信端末において生成し、データ送信端末の受
信するパケット再送要求であるＮＡＣＫ−ＲＴＣＰパケ
ットの構成を示す。
装置は、ＮＡＣＫ−ＲＴＣＰパケットを受信する。図６
にデータ受信端末において生成し、データ送信端末の受
信するパケット再送要求であるＮＡＣＫ−ＲＴＣＰパケ
ットの構成を示す。
【００８４】ＮＡＣＫ−ＲＴＣＰパケットは、図６に示
すようにヘッダ（ＨＥＡＤ）、フォーマット（ＦＯＲＭ
ＡＴ）、パケットタイプ、パケット長、送信同期ソース
識別子（ＲＴＣＰ）、タイムスタンプの情報に加えて、
再送要求対象となるパケットの識別子としての再送指定
シーケンス番号、さらに、各再送指定シーケンス番号に
対応するデータとして、「再送回数」、「オプショ
ン」、「重複指定回数」が設定可能である。
すようにヘッダ（ＨＥＡＤ）、フォーマット（ＦＯＲＭ
ＡＴ）、パケットタイプ、パケット長、送信同期ソース
識別子（ＲＴＣＰ）、タイムスタンプの情報に加えて、
再送要求対象となるパケットの識別子としての再送指定
シーケンス番号、さらに、各再送指定シーケンス番号に
対応するデータとして、「再送回数」、「オプショ
ン」、「重複指定回数」が設定可能である。
【００８５】前述したように、本発明の提案するＡＲＱ
を適用したシステムでは、ＲＴＣＰに従ったコントロー
ル・パケットとして再送要求としてのＮＡＣＫ、受信確
認としてのＡＣＫ、ストリーミング配信されるデータが
終了したことを明示的に示すＥＯＳ、送信と受信におけ
る往復伝播遅延（ＲＴＴ）を計測する際に使用されるＥ
ＣＨＯ、およびＥＣＨＯ−ＲＥＰＬＹのパケットが利用
される。これらの各ＲＴＣＰパケットそれぞれのフォー
マットタイプを一制御メッセージとして、すなわちＲＴ
ＣＰヘッダのＰＴ（Payload Type）として区別をするの
は汎用的ではない。よって、制御メッセージとしては、
フィードバックメッセージ（FM：Feedback Message）と
して定義しＰＴ（Payload Type）に指定する。かつ、Ｒ
ＴＣＰヘッダ内の［フォーマット］フィールドであるＦ
ＭＴ (Feedback Message Format)にそのパケットフォー
マットの指定をすることで、どのようなフィードバック
メッセージかを決定できる構成とする。
を適用したシステムでは、ＲＴＣＰに従ったコントロー
ル・パケットとして再送要求としてのＮＡＣＫ、受信確
認としてのＡＣＫ、ストリーミング配信されるデータが
終了したことを明示的に示すＥＯＳ、送信と受信におけ
る往復伝播遅延（ＲＴＴ）を計測する際に使用されるＥ
ＣＨＯ、およびＥＣＨＯ−ＲＥＰＬＹのパケットが利用
される。これらの各ＲＴＣＰパケットそれぞれのフォー
マットタイプを一制御メッセージとして、すなわちＲＴ
ＣＰヘッダのＰＴ（Payload Type）として区別をするの
は汎用的ではない。よって、制御メッセージとしては、
フィードバックメッセージ（FM：Feedback Message）と
して定義しＰＴ（Payload Type）に指定する。かつ、Ｒ
ＴＣＰヘッダ内の［フォーマット］フィールドであるＦ
ＭＴ (Feedback Message Format)にそのパケットフォー
マットの指定をすることで、どのようなフィードバック
メッセージかを決定できる構成とする。
【００８６】図６に示すように、１つのＮＡＣＫパケッ
トには１つ以上の再送要求対象となるパケットの識別子
としてのシーケンス番号を付与することができる構成を
持つ。つまり一度のＮＡＣＫパケットの送信処理で複数
のパケットについての再送要求が可能になる。また、再
送要求パケットのシーケンス番号各々に対して付加され
る「再送回数」は、何回目の再送要求かを明記するフィ
ールドであり、「重複指定回数」は、再送する場合の多
重回数の指定を明記するフィールドであり、「オプショ
ン」はその他の任意の情報を格納するフィールドとして
使用される。
トには１つ以上の再送要求対象となるパケットの識別子
としてのシーケンス番号を付与することができる構成を
持つ。つまり一度のＮＡＣＫパケットの送信処理で複数
のパケットについての再送要求が可能になる。また、再
送要求パケットのシーケンス番号各々に対して付加され
る「再送回数」は、何回目の再送要求かを明記するフィ
ールドであり、「重複指定回数」は、再送する場合の多
重回数の指定を明記するフィールドであり、「オプショ
ン」はその他の任意の情報を格納するフィールドとして
使用される。
【００８７】例えば、「重複指定回数」に［３］をいれ
ておけば、ＮＡＣＫを受信したデータ送信側は、同じデ
ータを格納した再送パケットを［３］つ連続で送る処理
を実行する。重要データを格納したパケットについて
は、重複再送を要求することで、再送パケットの受信の
確実性を高めることが可能となる。また、繰り返し、同
一パケットについての再送要求としてのＮＡＣＫを送信
しているにもかかわらず、受信に成功しない場合や、リ
アルタイム再生に間に合うための再送可能最終時間に出
されるＮＡＣＫにおいて、「重複指定回数」の設定数を
増加させてデータ送信側に送信することにより、再送パ
ケットの受信の確実性を高めることが可能となり、デー
タ再生品質を向上させることが可能となる。データ受信
側は、このようなＮＡＣＫ−ＲＴＣＰパケットを送信し
て、データ送信側は、受信したＮＡＣＫ−ＲＴＣＰパケ
ットに基づくパケット再送処理を実行する。
ておけば、ＮＡＣＫを受信したデータ送信側は、同じデ
ータを格納した再送パケットを［３］つ連続で送る処理
を実行する。重要データを格納したパケットについて
は、重複再送を要求することで、再送パケットの受信の
確実性を高めることが可能となる。また、繰り返し、同
一パケットについての再送要求としてのＮＡＣＫを送信
しているにもかかわらず、受信に成功しない場合や、リ
アルタイム再生に間に合うための再送可能最終時間に出
されるＮＡＣＫにおいて、「重複指定回数」の設定数を
増加させてデータ送信側に送信することにより、再送パ
ケットの受信の確実性を高めることが可能となり、デー
タ再生品質を向上させることが可能となる。データ受信
側は、このようなＮＡＣＫ−ＲＴＣＰパケットを送信し
て、データ送信側は、受信したＮＡＣＫ−ＲＴＣＰパケ
ットに基づくパケット再送処理を実行する。
【００８８】なお、ＲＴＰパケットフォーマットやペイ
ロードフォーマット、または受信端末の利用者が意図的
に指定した場合など、パケットに優先度が与えられてい
る場合、優先度が高いパケットやデータに関しての再送
は多重再送処理を行なうことで、再送パケットの受信確
率を高めるようコントロール可能である。また、「再送
回数」フィールドにおいて何回目の再送要求かを明記す
ることで、ＮＡＣＫ自身が損失したことを送信側が検知
できる。
ロードフォーマット、または受信端末の利用者が意図的
に指定した場合など、パケットに優先度が与えられてい
る場合、優先度が高いパケットやデータに関しての再送
は多重再送処理を行なうことで、再送パケットの受信確
率を高めるようコントロール可能である。また、「再送
回数」フィールドにおいて何回目の再送要求かを明記す
ることで、ＮＡＣＫ自身が損失したことを送信側が検知
できる。
【００８９】「オプション」フィールドには、フィール
ド設定値に従って、例えば図７に示す処理指定を行なう
ことが可能となる。すなわち、 オプション設定値＝０ 指定シーケンス番号を持つパケットのみの再送要求（デ
フォルト） オプション設定値＝１ フレーム先頭パケットから指定シーケンス番号を持つパ
ケットまでの一括再送要求 オプション設定値＝２ 指定シーケンス番号からフレーム最後尾までのパケット
の一括再送要求 オプション設定値＝３ 指定タイムスタンプの付与されたパケットの一括再送要
求 オプション設定値＝４ タイムスタンプを無視してシーケンス番号のみで検索し
て検索結果のパケットの再送を要求
ド設定値に従って、例えば図７に示す処理指定を行なう
ことが可能となる。すなわち、 オプション設定値＝０ 指定シーケンス番号を持つパケットのみの再送要求（デ
フォルト） オプション設定値＝１ フレーム先頭パケットから指定シーケンス番号を持つパ
ケットまでの一括再送要求 オプション設定値＝２ 指定シーケンス番号からフレーム最後尾までのパケット
の一括再送要求 オプション設定値＝３ 指定タイムスタンプの付与されたパケットの一括再送要
求 オプション設定値＝４ タイムスタンプを無視してシーケンス番号のみで検索し
て検索結果のパケットの再送を要求
【００９０】画像データ等の符号化データは、先に図２
を参照して説明したように、タイムスタンプとシーケン
ス番号をセットとしたヘッダを持つ１つのＲＴＰパケッ
トに格納した構成を有するが、データ転送処理におい
て、タイムスタンプの変わり目を含んた連続的なエラー
としてのバーストエラーが起こった場合、あるいは、バ
ーストエラーの発生により、フレーム単位でパケットの
損失が発生した場合などにおいては、受信端末側では、
パケット損失の発生したパケットに対応するタイムスタ
ンプとシーケンス番号のセットを特定できない場合が発
生する。このような場合において、特定可能なタイムス
タンプ、あるいはシーケンス番号のいずれか一方のみを
指定して、上記のオプション設定値を設定することによ
り、フレキシブルな態様で再送の必要な１以上のパケッ
ト指定が可能となる。
を参照して説明したように、タイムスタンプとシーケン
ス番号をセットとしたヘッダを持つ１つのＲＴＰパケッ
トに格納した構成を有するが、データ転送処理におい
て、タイムスタンプの変わり目を含んた連続的なエラー
としてのバーストエラーが起こった場合、あるいは、バ
ーストエラーの発生により、フレーム単位でパケットの
損失が発生した場合などにおいては、受信端末側では、
パケット損失の発生したパケットに対応するタイムスタ
ンプとシーケンス番号のセットを特定できない場合が発
生する。このような場合において、特定可能なタイムス
タンプ、あるいはシーケンス番号のいずれか一方のみを
指定して、上記のオプション設定値を設定することによ
り、フレキシブルな態様で再送の必要な１以上のパケッ
ト指定が可能となる。
【００９１】このように、データ受信端末では、様々な
態様での再送要求パケットの指定が可能であり、ＮＡＣ
Ｋ−ＲＴＣＰパケットを受信したデータ送信端末のＡＲ
Ｑ処理部１０５は、オプションフィールドの設定値に従
って、バッファ１０３に格納済みのパケットから指定パ
ケットを抽出して、再送処理を実行する。
態様での再送要求パケットの指定が可能であり、ＮＡＣ
Ｋ−ＲＴＣＰパケットを受信したデータ送信端末のＡＲ
Ｑ処理部１０５は、オプションフィールドの設定値に従
って、バッファ１０３に格納済みのパケットから指定パ
ケットを抽出して、再送処理を実行する。
【００９２】図４に戻り、データ送信端末の処理につい
て説明する。ステップＳ２１２では、ステップＳ２１１
で受信したＮＡＣＫ−ＲＴＣＰパケットに指定された再
送要求パケットに対応するシーケンス番号を抽出し、ス
テップＳ２１３では、オプション指定の抽出を実行す
る。上述したように再送要求パケットの指定態様は、シ
ーケンス番号の直接指定のみならず、タイムスタンプ等
による指定等、様々であり、データ送信端末装置のＡＲ
Ｑ処理部１０５では、受信したＮＡＣＫ−ＲＴＣＰパケ
ットに指定されたオプション指定、およびタイムスタン
プ、シーケンス番号を参照して、再送要求パケットを特
定する処理を実行する。
て説明する。ステップＳ２１２では、ステップＳ２１１
で受信したＮＡＣＫ−ＲＴＣＰパケットに指定された再
送要求パケットに対応するシーケンス番号を抽出し、ス
テップＳ２１３では、オプション指定の抽出を実行す
る。上述したように再送要求パケットの指定態様は、シ
ーケンス番号の直接指定のみならず、タイムスタンプ等
による指定等、様々であり、データ送信端末装置のＡＲ
Ｑ処理部１０５では、受信したＮＡＣＫ−ＲＴＣＰパケ
ットに指定されたオプション指定、およびタイムスタン
プ、シーケンス番号を参照して、再送要求パケットを特
定する処理を実行する。
【００９３】ステップＳ２１４では、特定された再送要
求パケットをバッファ１０３から抽出する。バッファ１
０３には、再送要求に備えて所定時間、送信済みのパケ
ットが保持格納されており、これらの格納パケットから
再送指定のあったパケットを抽出する処理を実行する。
ステップＳ２１５で、ＲＴＰパケット出力ポートから抽
出パケットが送信される。
求パケットをバッファ１０３から抽出する。バッファ１
０３には、再送要求に備えて所定時間、送信済みのパケ
ットが保持格納されており、これらの格納パケットから
再送指定のあったパケットを抽出する処理を実行する。
ステップＳ２１５で、ＲＴＰパケット出力ポートから抽
出パケットが送信される。
【００９４】ステップＳ２０３において、ＮＡＣＫ−Ｒ
ＴＣＰパケットを受信しない場合は、ステップＳ２０４
でパケット受信応答としてのＡＣＫ−ＲＴＣＰパケット
の受信確認を行ない、ＡＣＫ−ＲＴＣＰパケットの受信
に基づいて、ステップＳ２０８で、受信の確認されたパ
ケットをバッファ１０３からクリア（削除）する。この
ＡＣＫにより、再送要求に対応してパケットを保持する
送信側のバッファを能動的に早めにクリアすることが可
能となり、バッファ溢れの恐れを低下させることが可能
となる。
ＴＣＰパケットを受信しない場合は、ステップＳ２０４
でパケット受信応答としてのＡＣＫ−ＲＴＣＰパケット
の受信確認を行ない、ＡＣＫ−ＲＴＣＰパケットの受信
に基づいて、ステップＳ２０８で、受信の確認されたパ
ケットをバッファ１０３からクリア（削除）する。この
ＡＣＫにより、再送要求に対応してパケットを保持する
送信側のバッファを能動的に早めにクリアすることが可
能となり、バッファ溢れの恐れを低下させることが可能
となる。
【００９５】図８にデータ受信端末において生成し、デ
ータ送信端末の受信するパケット受信確認応答であるＡ
ＣＫ−ＲＴＣＰパケットの構成を示す。
ータ送信端末の受信するパケット受信確認応答であるＡ
ＣＫ−ＲＴＣＰパケットの構成を示す。
【００９６】ＡＣＫ−ＲＴＣＰパケットは、図８に示す
ようにヘッダ（ＨＥＡＤ）、フォーマット（ＦＯＲＭＡ
Ｔ）、パケットタイプ、パケット長、送信同期ソース識
別子（ＲＴＣＰ）、タイムスタンプの情報に加えて、受
信パケットの識別子としての受信済みシーケンス番号が
格納される。
ようにヘッダ（ＨＥＡＤ）、フォーマット（ＦＯＲＭＡ
Ｔ）、パケットタイプ、パケット長、送信同期ソース識
別子（ＲＴＣＰ）、タイムスタンプの情報に加えて、受
信パケットの識別子としての受信済みシーケンス番号が
格納される。
【００９７】なお、シーケンス番号を指定せず、タイム
スタンプ（TIMESTAMP）のみ指定する構成とすることも
可能であり、この場合には、そのタイムスタンプ（TIME
STAMP）の設定されたパケットすべてを受け取った事を
示す。よってこのような場合にはシーケンス番号をすべ
て指定する必要はないため、ＡＣＫ−ＲＴＣＰパケット
サイズを小さくすることが可能となり、ネットワークト
ラフィックの増大を低減できる。
スタンプ（TIMESTAMP）のみ指定する構成とすることも
可能であり、この場合には、そのタイムスタンプ（TIME
STAMP）の設定されたパケットすべてを受け取った事を
示す。よってこのような場合にはシーケンス番号をすべ
て指定する必要はないため、ＡＣＫ−ＲＴＣＰパケット
サイズを小さくすることが可能となり、ネットワークト
ラフィックの増大を低減できる。
【００９８】図４に戻り、データ送信端末の処理の説明
を続ける。データ送信端末は、ステップＳ２０５におい
て、ＥＣＨＯ−ＲＴＣＰパケットの受信確認を行ない、
データ受信端末からＥＣＨＯ−ＲＴＣＰパケットを受信
した場合は、ステップＳ２０９において、ＥＣＨＯ−Ｒ
ＥＰＬＹ−ＲＴＣＰパケットをＥＣＨＯ−ＲＴＣＰパケ
ットを送信してきたデータ受信端末に対して送信する処
理を実行する。
を続ける。データ送信端末は、ステップＳ２０５におい
て、ＥＣＨＯ−ＲＴＣＰパケットの受信確認を行ない、
データ受信端末からＥＣＨＯ−ＲＴＣＰパケットを受信
した場合は、ステップＳ２０９において、ＥＣＨＯ−Ｒ
ＥＰＬＹ−ＲＴＣＰパケットをＥＣＨＯ−ＲＴＣＰパケ
ットを送信してきたデータ受信端末に対して送信する処
理を実行する。
【００９９】ＥＣＨＯ−ＲＴＣＰパケットと、ＥＣＨＯ
−ＲＥＰＬＹ−ＲＴＣＰパケットは、送信端末と受信端
末における往復伝播遅延（ＲＴＴ）をデータ受信端末に
おいて把握するために用いるＲＴＣＰパケットである。
このパケットの送受信によって、データ受信端末におい
て、再送要求を行なってから再送パケットを受信するま
での時間の把握が可能となり、データ受信端末において
リアルタイム再生を行なうために必要な最終再送要求時
間を割り出すことが可能なる。
−ＲＥＰＬＹ−ＲＴＣＰパケットは、送信端末と受信端
末における往復伝播遅延（ＲＴＴ）をデータ受信端末に
おいて把握するために用いるＲＴＣＰパケットである。
このパケットの送受信によって、データ受信端末におい
て、再送要求を行なってから再送パケットを受信するま
での時間の把握が可能となり、データ受信端末において
リアルタイム再生を行なうために必要な最終再送要求時
間を割り出すことが可能なる。
【０１００】本発明のシステムでは、受信端末のＡＲＱ
判定部において、往復伝播遅延（ＲＴＴ）に基づく最終
再送要求時間を判定し、判定に基づいて、再送要求とし
てのＮＡＣＫ−ＲＴＣＰの送信の実行可否を決定する。
この判定処理に必要な送信端末と受信端末における往復
伝播遅延（ＲＴＴ）の最新情報を取得するため、データ
受信端末側は、任意タイミングで、能動的にＥＣＨＯ−
ＲＴＣＰパケットをデータ送信端末に送信し、データ送
信端末は、ＥＣＨＯ−ＲＴＣＰパケットの受信に応答し
てＥＣＨＯ−ＲＥＰＬＹ−ＲＴＣＰパケットをＥＣＨＯ
−ＲＴＣＰパケットを送信してきたデータ受信端末に対
して送信する。
判定部において、往復伝播遅延（ＲＴＴ）に基づく最終
再送要求時間を判定し、判定に基づいて、再送要求とし
てのＮＡＣＫ−ＲＴＣＰの送信の実行可否を決定する。
この判定処理に必要な送信端末と受信端末における往復
伝播遅延（ＲＴＴ）の最新情報を取得するため、データ
受信端末側は、任意タイミングで、能動的にＥＣＨＯ−
ＲＴＣＰパケットをデータ送信端末に送信し、データ送
信端末は、ＥＣＨＯ−ＲＴＣＰパケットの受信に応答し
てＥＣＨＯ−ＲＥＰＬＹ−ＲＴＣＰパケットをＥＣＨＯ
−ＲＴＣＰパケットを送信してきたデータ受信端末に対
して送信する。
【０１０１】データ受信端末では、データ送信端末から
の応答として受信するＥＣＨＯ−ＲＥＰＬＹ−ＲＴＣＰ
パケットを解析することによって、送信端末と受信端末
における往復伝播遅延（ＲＴＴ）を算出する。このＲＴ
Ｔ算出処理については、後段のデータ受信端末の処理の
項目で説明する。
の応答として受信するＥＣＨＯ−ＲＥＰＬＹ−ＲＴＣＰ
パケットを解析することによって、送信端末と受信端末
における往復伝播遅延（ＲＴＴ）を算出する。このＲＴ
Ｔ算出処理については、後段のデータ受信端末の処理の
項目で説明する。
【０１０２】図９にデータ受信端末において生成し、デ
ータ送信端末の受信するＥＣＨＯ−ＲＴＣＰパケットの
構成、および、データ送信端末において生成し、データ
受信端末に対して送信するＥＣＨＯ−ＲＥＰＬＹ−ＲＴ
ＣＰパケットの構成を示す。
ータ送信端末の受信するＥＣＨＯ−ＲＴＣＰパケットの
構成、および、データ送信端末において生成し、データ
受信端末に対して送信するＥＣＨＯ−ＲＥＰＬＹ−ＲＴ
ＣＰパケットの構成を示す。
【０１０３】ＥＣＨＯ−ＲＴＣＰパケットは、図９
（ａ）に示すようにヘッダ（ＨＥＡＤ）、フォーマット
（ＦＯＲＭＡＴ）、パケットタイプ、パケット長、送信
同期ソース識別子（ＲＴＣＰ）、およびＥＣＨＯパケッ
トの識別データとしてのＥＣＨＯ−ＩＤが格納される。
ＥＣＨＯ−ＲＥＰＬＹ−ＲＴＣＰパケットは、図９
（ｂ）に示すようにヘッダ（ＨＥＡＤ）、フォーマット
（ＦＯＲＭＡＴ）、パケットタイプ、パケット長、送信
同期ソース識別子（ＲＴＣＰ）、およびＥＣＨＯ−ＲＴ
ＣＰパケットに対応するＥＣＨＯ−ＩＤ、および、サー
バ処理時間が格納される。
（ａ）に示すようにヘッダ（ＨＥＡＤ）、フォーマット
（ＦＯＲＭＡＴ）、パケットタイプ、パケット長、送信
同期ソース識別子（ＲＴＣＰ）、およびＥＣＨＯパケッ
トの識別データとしてのＥＣＨＯ−ＩＤが格納される。
ＥＣＨＯ−ＲＥＰＬＹ−ＲＴＣＰパケットは、図９
（ｂ）に示すようにヘッダ（ＨＥＡＤ）、フォーマット
（ＦＯＲＭＡＴ）、パケットタイプ、パケット長、送信
同期ソース識別子（ＲＴＣＰ）、およびＥＣＨＯ−ＲＴ
ＣＰパケットに対応するＥＣＨＯ−ＩＤ、および、サー
バ処理時間が格納される。
【０１０４】ＥＣＨＯ−ＩＤをＥＣＨＯ−ＲＴＣＰパケ
ットとＥＣＨＯ−ＲＥＰＬＹ−ＲＴＣＰパケットに入れ
ることにより、データ受信端末側がＥＣＨＯ−ＲＥＰＬ
Ｙを受け取った際に、いつ送信したＥＣＨＯ−ＲＴＣＰ
パケットに対応する返事（ＥＣＨＯ−ＲＥＰＬＹ）かを
識別することが可能となる。ＥＣＨＯ−ＲＥＰＬＹ−Ｒ
ＴＣＰパケットに格納されるサーバ処理時間は、データ
送信端末がデータ受信端末からの再送要求（ＮＡＣＫ−
ＲＴＣＰ）を受信してからパケットをデータ送信端末か
ら出力するまでに要する処理時間に相当する時間であ
る。このサーバ処理時間は、ＥＣＨＯ−ＲＴＣＰパケッ
トを受信した時間からＥＣＨＯ−ＲＥＰＬＹ−ＲＴＣＰ
パケットを送信するまでの時間として設定するか、ある
いは、予めデータ送信端末において過去の履歴データと
して、実際に、データ送信端末がデータ受信端末からの
再送要求（ＮＡＣＫ−ＲＴＣＰ）を受信してからパケッ
トをデータ送信端末から出力するまでに要した時間をメ
モリに格納し、この格納データを適用してもよいし、あ
るいは、ＥＣＨＯ−ＲＴＣＰパケットを受信した時点に
おけるサーバ（データ送信端末）における処理負荷を算
出して、処理負荷に基づいて算出される予測処理時間を
サーバ処理時間として設定する構成としてもよい。
ットとＥＣＨＯ−ＲＥＰＬＹ−ＲＴＣＰパケットに入れ
ることにより、データ受信端末側がＥＣＨＯ−ＲＥＰＬ
Ｙを受け取った際に、いつ送信したＥＣＨＯ−ＲＴＣＰ
パケットに対応する返事（ＥＣＨＯ−ＲＥＰＬＹ）かを
識別することが可能となる。ＥＣＨＯ−ＲＥＰＬＹ−Ｒ
ＴＣＰパケットに格納されるサーバ処理時間は、データ
送信端末がデータ受信端末からの再送要求（ＮＡＣＫ−
ＲＴＣＰ）を受信してからパケットをデータ送信端末か
ら出力するまでに要する処理時間に相当する時間であ
る。このサーバ処理時間は、ＥＣＨＯ−ＲＴＣＰパケッ
トを受信した時間からＥＣＨＯ−ＲＥＰＬＹ−ＲＴＣＰ
パケットを送信するまでの時間として設定するか、ある
いは、予めデータ送信端末において過去の履歴データと
して、実際に、データ送信端末がデータ受信端末からの
再送要求（ＮＡＣＫ−ＲＴＣＰ）を受信してからパケッ
トをデータ送信端末から出力するまでに要した時間をメ
モリに格納し、この格納データを適用してもよいし、あ
るいは、ＥＣＨＯ−ＲＴＣＰパケットを受信した時点に
おけるサーバ（データ送信端末）における処理負荷を算
出して、処理負荷に基づいて算出される予測処理時間を
サーバ処理時間として設定する構成としてもよい。
【０１０５】データ受信端末は、ＥＣＨＯ−ＲＥＰＬＹ
−ＲＴＣＰパケットに格納されたサーバ処理時間と、Ｅ
ＣＨＯ−ＲＴＣＰパケット送信からＥＣＨＯ−ＲＥＰＬ
Ｙ−ＲＴＣＰの受信までの時間とに基づいて、送信端末
と受信端末における往復伝播遅延（ＲＴＴ）を算出す
る。このＲＴＴ算出処理については、後段のデータ受信
端末の処理の項目で説明する。
−ＲＴＣＰパケットに格納されたサーバ処理時間と、Ｅ
ＣＨＯ−ＲＴＣＰパケット送信からＥＣＨＯ−ＲＥＰＬ
Ｙ−ＲＴＣＰの受信までの時間とに基づいて、送信端末
と受信端末における往復伝播遅延（ＲＴＴ）を算出す
る。このＲＴＴ算出処理については、後段のデータ受信
端末の処理の項目で説明する。
【０１０６】図４に戻り、データ送信端末の処理の説明
を続ける。データ送信端末は、ステップＳ２０６におい
て、送信対象となるストリーミングデータのパケット送
信がすべて終了したかを判定し、終了と判定した場合
は、ステップＳ２１０において、データストリームの終
了を明示するＥＯＳ（End Of Stream）メッセージを持
つＲＴＣＰパケットを受信側端末へ送信する処理を実行
する。
を続ける。データ送信端末は、ステップＳ２０６におい
て、送信対象となるストリーミングデータのパケット送
信がすべて終了したかを判定し、終了と判定した場合
は、ステップＳ２１０において、データストリームの終
了を明示するＥＯＳ（End Of Stream）メッセージを持
つＲＴＣＰパケットを受信側端末へ送信する処理を実行
する。
【０１０７】図１０にデータ送信端末において生成し、
データ受信端末の受信するＥＯＳ−ＲＴＣＰパケットの
構成を示す。
データ受信端末の受信するＥＯＳ−ＲＴＣＰパケットの
構成を示す。
【０１０８】ＥＯＳ−ＲＴＣＰパケットは、図１０に示
すようにヘッダ（ＨＥＡＤ）、フォーマット（ＦＯＲＭ
ＡＴ）、パケットタイプ、パケット長、送信同期ソース
識別子（ＲＴＣＰ）、およびタイムスタンプ（ＴＩＭＥ
ＳＴＡＭＰ）が格納される。データ受信端末は、ＥＯＳ
−ＲＴＣＰパケットをデータ送信端末から受信すること
により、ストリーミング配信されるデータの終了を認識
する。受信端末はこの認識処理により、次フレームが到
着しないことによる誤ったＮＡＣＫ送出動作を防ぐこと
ができる。
すようにヘッダ（ＨＥＡＤ）、フォーマット（ＦＯＲＭ
ＡＴ）、パケットタイプ、パケット長、送信同期ソース
識別子（ＲＴＣＰ）、およびタイムスタンプ（ＴＩＭＥ
ＳＴＡＭＰ）が格納される。データ受信端末は、ＥＯＳ
−ＲＴＣＰパケットをデータ送信端末から受信すること
により、ストリーミング配信されるデータの終了を認識
する。受信端末はこの認識処理により、次フレームが到
着しないことによる誤ったＮＡＣＫ送出動作を防ぐこと
ができる。
【０１０９】図４に戻り、データ送信端末の処理の説明
を続ける。データ送信端末は、ステップＳ２０７におい
て、予め設定した時間を計測するタイマーでの計測時間
が設定時間を超えたか否かを判定して、タイマーが設定
時間を超えていない場合は、ステップＳ２０３以下の処
理、すなわち、ステップＳ２０３のパケット再送要求と
してのＮＡＣＫ−ＲＴＣＰパケットの受信判定処理以下
の処理を継続して実行する。これは、全パケット送出後
においても、一定時間は、データ受信側からのパケット
再送要求としてのＮＡＣＫ−ＲＴＣＰパケット、また
は、受信確認応答としてのＡＣＫ−ＲＴＣＰパケット、
または、ＥＣＨＯ−ＲＴＣＰパケットを受信する可能性
があり、これらのパケット受信に対する処理を実行する
ためである。タイマーにおいて、予め設定した時間が経
過した時点で、データ送信を終了する。
を続ける。データ送信端末は、ステップＳ２０７におい
て、予め設定した時間を計測するタイマーでの計測時間
が設定時間を超えたか否かを判定して、タイマーが設定
時間を超えていない場合は、ステップＳ２０３以下の処
理、すなわち、ステップＳ２０３のパケット再送要求と
してのＮＡＣＫ−ＲＴＣＰパケットの受信判定処理以下
の処理を継続して実行する。これは、全パケット送出後
においても、一定時間は、データ受信側からのパケット
再送要求としてのＮＡＣＫ−ＲＴＣＰパケット、また
は、受信確認応答としてのＡＣＫ−ＲＴＣＰパケット、
または、ＥＣＨＯ−ＲＴＣＰパケットを受信する可能性
があり、これらのパケット受信に対する処理を実行する
ためである。タイマーにおいて、予め設定した時間が経
過した時点で、データ送信を終了する。
【０１１０】［データ受信端末における処理］次に、デ
ータ受信端末の処理手順を図１１に示すフローチャート
を参照して説明する。図１１に示す処理は、図１の受信
側端末１２１において実行される処理を説明したフロー
である。
ータ受信端末の処理手順を図１１に示すフローチャート
を参照して説明する。図１１に示す処理は、図１の受信
側端末１２１において実行される処理を説明したフロー
である。
【０１１１】データ受信端末は、ステップＳ３００にお
いて、データ送信端末からの送信開始通知を受信後、ス
テップＳ３０１において、データ送信端末からの送信パ
ケット、すなわち符号化データをペイロードとして格納
したＲＴＰパケットを順次、受信する。ＲＴＰパケット
は、先に、図２を参照して説明したように、タイムスタ
ンプがヘッダ情報中に格納されている。データ受信端末
は、タイムスタンプに基づいて受信するパケットに含ま
れるフレームを判別することができる。先に説明したよ
うに、動画像データをＲＴＰパケットに符号化データと
して格納して送信する場合、同一の画像フレームに属す
る複数のＲＴＰパケットには同一のタイムスタンプが設
定され、データ受信側端末は、タイムスタンプを参照し
て、フレームの判別が可能となる。
いて、データ送信端末からの送信開始通知を受信後、ス
テップＳ３０１において、データ送信端末からの送信パ
ケット、すなわち符号化データをペイロードとして格納
したＲＴＰパケットを順次、受信する。ＲＴＰパケット
は、先に、図２を参照して説明したように、タイムスタ
ンプがヘッダ情報中に格納されている。データ受信端末
は、タイムスタンプに基づいて受信するパケットに含ま
れるフレームを判別することができる。先に説明したよ
うに、動画像データをＲＴＰパケットに符号化データと
して格納して送信する場合、同一の画像フレームに属す
る複数のＲＴＰパケットには同一のタイムスタンプが設
定され、データ受信側端末は、タイムスタンプを参照し
て、フレームの判別が可能となる。
【０１１２】データ受信端末は、ステップＳ３０２にお
いて、受信したパケットが、ｎフレーム目（ｎ=１，
２...）の終端パケットであるか否かを判定する。ま
た、ステップＳ３０３において、受信したパケットが、
ｎ＋１フレーム目の先頭パケットであるか否かを判定す
る。受信したパケットが、ｎフレーム目（ｎ=１，
２...）の終端パケットである場合、または、ｎ＋１フ
レーム目の先頭パケットである場合には、ステップＳ３
０９に進む。
いて、受信したパケットが、ｎフレーム目（ｎ=１，
２...）の終端パケットであるか否かを判定する。ま
た、ステップＳ３０３において、受信したパケットが、
ｎ＋１フレーム目の先頭パケットであるか否かを判定す
る。受信したパケットが、ｎフレーム目（ｎ=１，
２...）の終端パケットである場合、または、ｎ＋１フ
レーム目の先頭パケットである場合には、ステップＳ３
０９に進む。
【０１１３】ステップＳ３０９においては、ｎフレーム
内に未受信のパケット、すなわちロストパケット、ある
いはエラーパケットがあるか否かを判定する。図５を参
照して、ステップＳ３０９におけるエラーパケットまた
はロストパケットの検出処理について説明する。
内に未受信のパケット、すなわちロストパケット、ある
いはエラーパケットがあるか否かを判定する。図５を参
照して、ステップＳ３０９におけるエラーパケットまた
はロストパケットの検出処理について説明する。
【０１１４】図５は、送信側と受信側で実際にＲＴＰ、
ＲＴＣＰパケットのデータ転送が行われている例であ
る。図の右方向に時間が流れているとする。ここでは、
９０ＫＨｚクロックで、動画像データについて、３０ｆ
ｐｓ（フレーム／秒）のレートでサンプリングして符号
化データをＲＴＰパケットに格納して送信すると仮定し
ている。この場合、ＲＴＰパケットのタイムスタンプの
値は、同一画像フレーム内の場合には同じ値になり、９
０Ｋ/３０＝３００００ずつカウントアップされる。受
信側は、最小刻みタイマτを実装する。この例では、当
画像データの圧縮フォーマットとして、MOTION JPEG200
0に従った符号化データを伝送しているものとし、フレ
ームにおける最終端パケットが、データ受信端末のＲＴ
Ｐパケット解析部１１４にて検知できる。
ＲＴＣＰパケットのデータ転送が行われている例であ
る。図の右方向に時間が流れているとする。ここでは、
９０ＫＨｚクロックで、動画像データについて、３０ｆ
ｐｓ（フレーム／秒）のレートでサンプリングして符号
化データをＲＴＰパケットに格納して送信すると仮定し
ている。この場合、ＲＴＰパケットのタイムスタンプの
値は、同一画像フレーム内の場合には同じ値になり、９
０Ｋ/３０＝３００００ずつカウントアップされる。受
信側は、最小刻みタイマτを実装する。この例では、当
画像データの圧縮フォーマットとして、MOTION JPEG200
0に従った符号化データを伝送しているものとし、フレ
ームにおける最終端パケットが、データ受信端末のＲＴ
Ｐパケット解析部１１４にて検知できる。
【０１１５】図５において、タイムスタンプ１２０００
の設定されたパケットは、パケットのシーケンス番号１
〜６であり、これらが同一フレーム、例えばフレームｎ
に属するパケットである。データ受信端末では、シーケ
ンス番号６のパケットを受信した時点で、ステップＳ３
０２の判定がＹｅｓとなり、ステップＳ３０９のロスト
パケット検出処理を実行することになる。この時点で、
データ受信端末は、図５に示すようにシーケンス番号１
〜３，６のパケットを受信しており、シーケンス番号
４，５のロストパケットがあると判定する。なお、ここ
では、ロストパケットについてのみ記載しているが、受
信したパケットについてのエラーパケットとして範囲さ
れた場合についても、ロストパケットと同様の処理、す
なわち再送要求を実行することが可能である。
の設定されたパケットは、パケットのシーケンス番号１
〜６であり、これらが同一フレーム、例えばフレームｎ
に属するパケットである。データ受信端末では、シーケ
ンス番号６のパケットを受信した時点で、ステップＳ３
０２の判定がＹｅｓとなり、ステップＳ３０９のロスト
パケット検出処理を実行することになる。この時点で、
データ受信端末は、図５に示すようにシーケンス番号１
〜３，６のパケットを受信しており、シーケンス番号
４，５のロストパケットがあると判定する。なお、ここ
では、ロストパケットについてのみ記載しているが、受
信したパケットについてのエラーパケットとして範囲さ
れた場合についても、ロストパケットと同様の処理、す
なわち再送要求を実行することが可能である。
【０１１６】ロスとパケットまたはエラーパケットが検
出されると、ステップＳ３１２以下の処理に進み、再送
要求処理としてのＮＡＣＫ−ＲＴＣＰパケットの送信判
定処理、および判定に基づくＮＡＣＫ−ＲＴＣＰパケッ
トの送信処理が実行される。これらの判定処理の詳細に
ついては、後述する。ここでは、シーケンス番号４，５
のロストパケットに関するＮＡＣＫ−ＲＴＣＰパケット
が生成され、先に図６を参照して説明したＮＡＣＫ−Ｒ
ＴＣＰパケットの再送指定シーケンス番号として４，５
を設定したパケットを再送要求パケットとしてデータ送
信端末に対して送信する。図５におけるＮＡＣＫ−ＲＴ
ＣＰパケット送信処理５０１がこれに相当する。
出されると、ステップＳ３１２以下の処理に進み、再送
要求処理としてのＮＡＣＫ−ＲＴＣＰパケットの送信判
定処理、および判定に基づくＮＡＣＫ−ＲＴＣＰパケッ
トの送信処理が実行される。これらの判定処理の詳細に
ついては、後述する。ここでは、シーケンス番号４，５
のロストパケットに関するＮＡＣＫ−ＲＴＣＰパケット
が生成され、先に図６を参照して説明したＮＡＣＫ−Ｒ
ＴＣＰパケットの再送指定シーケンス番号として４，５
を設定したパケットを再送要求パケットとしてデータ送
信端末に対して送信する。図５におけるＮＡＣＫ−ＲＴ
ＣＰパケット送信処理５０１がこれに相当する。
【０１１７】ＮＡＣＫ−ＲＴＣＰパケット送信の際にタ
イムスタンプ（TIMESTAMP）とシーケンス番号の組み合
わせがはっきりしない場合には、先に図７を参照して説
明したオプションを指定して送信する。データ受信端末
では、パケットの送受信情報を随時記録することで、パ
ケットロス率の割り出しが可能となる。このロス率が一
定値以上になった場合には、ＮＡＣＫ−ＲＴＣＰパケッ
ト自体の損失の可能性が考えられるため、おなじＮＡＣ
Ｋ−ＲＴＣＰパケットを複数回、重ねて送信する処理を
行なうことで、再送成功率を高めることが可能となる。
あるいは、ＮＡＣＫ−ＲＴＣＰパケットに重複指定回数
を増分して設定する。
イムスタンプ（TIMESTAMP）とシーケンス番号の組み合
わせがはっきりしない場合には、先に図７を参照して説
明したオプションを指定して送信する。データ受信端末
では、パケットの送受信情報を随時記録することで、パ
ケットロス率の割り出しが可能となる。このロス率が一
定値以上になった場合には、ＮＡＣＫ−ＲＴＣＰパケッ
ト自体の損失の可能性が考えられるため、おなじＮＡＣ
Ｋ−ＲＴＣＰパケットを複数回、重ねて送信する処理を
行なうことで、再送成功率を高めることが可能となる。
あるいは、ＮＡＣＫ−ＲＴＣＰパケットに重複指定回数
を増分して設定する。
【０１１８】データ送信端末は、ＮＡＣＫ−ＲＴＣＰパ
ケットを受信すると、次のタイムスタンプを設定したフ
レームデータに併せて、再送パケットを送信する。ここ
では、タイムスタンプ：１５０００のフレームデータ
（シーケンス番号７〜１２）に併せて再送パケット（シ
ーケンス番号４，５）を送信する。なお、再送タイミン
グは、このように次のフレームデータになるとは限ら
ず、処理タイミングによっては、さらに次のあるいはさ
らに遅れたフレームデータとともになる場合もある。こ
れらの再送処理タイミングについては、データ受信端末
側がＥＣＨＯ−ＲＴＣＰパケット、およびＥＣＨＯ−Ｒ
ＥＰＬＹ−ＲＴＣＰの送受信を実行することにより、送
信端末と受信端末における往復伝播遅延（ＲＴＴ）を算
出して推測可能となる。この処理については、後述す
る。
ケットを受信すると、次のタイムスタンプを設定したフ
レームデータに併せて、再送パケットを送信する。ここ
では、タイムスタンプ：１５０００のフレームデータ
（シーケンス番号７〜１２）に併せて再送パケット（シ
ーケンス番号４，５）を送信する。なお、再送タイミン
グは、このように次のフレームデータになるとは限ら
ず、処理タイミングによっては、さらに次のあるいはさ
らに遅れたフレームデータとともになる場合もある。こ
れらの再送処理タイミングについては、データ受信端末
側がＥＣＨＯ−ＲＴＣＰパケット、およびＥＣＨＯ−Ｒ
ＥＰＬＹ−ＲＴＣＰの送受信を実行することにより、送
信端末と受信端末における往復伝播遅延（ＲＴＴ）を算
出して推測可能となる。この処理については、後述す
る。
【０１１９】図５において、各フレーム、すなわち、タ
イムスタンプ＝１２０００〜２４０００…において、そ
の最終パケットまたは先頭パケットをデータ受信端末が
受信した場合において、図１１のステップＳ３０２また
はステップＳ３０３の判定が、Ｙｅｓとなり、ステップ
Ｓ３０９のロストパケット検出処理を実行し、ステップ
Ｓ３１２以下の処理に進み、再送要求処理としてのＮＡ
ＣＫ−ＲＴＣＰパケットの送信判定処理、および判定に
基づくＮＡＣＫ−ＲＴＣＰパケットの送信処理が実行さ
れる。
イムスタンプ＝１２０００〜２４０００…において、そ
の最終パケットまたは先頭パケットをデータ受信端末が
受信した場合において、図１１のステップＳ３０２また
はステップＳ３０３の判定が、Ｙｅｓとなり、ステップ
Ｓ３０９のロストパケット検出処理を実行し、ステップ
Ｓ３１２以下の処理に進み、再送要求処理としてのＮＡ
ＣＫ−ＲＴＣＰパケットの送信判定処理、および判定に
基づくＮＡＣＫ−ＲＴＣＰパケットの送信処理が実行さ
れる。
【０１２０】ステップＳ３１２の再送要求処理としての
ＮＡＣＫ−ＲＴＣＰパケットの送信判定処理について説
明する。リアルタイム再生処理を実現するためには、再
生タイミングに間に合うように、再送要求パケットが受
信端末に届くことが必要となる。ステップＳ３１２の再
送要求処理としてのＮＡＣＫ−ＲＴＣＰパケットの送信
判定処理は、ＮＡＣＫ−ＲＴＣＰパケットを送信した場
合、リアルタイム再生処理に間に合うタイミングで、再
送パケットが受信可能か否かを判定するものである。
ＮＡＣＫ−ＲＴＣＰパケットの送信判定処理について説
明する。リアルタイム再生処理を実現するためには、再
生タイミングに間に合うように、再送要求パケットが受
信端末に届くことが必要となる。ステップＳ３１２の再
送要求処理としてのＮＡＣＫ−ＲＴＣＰパケットの送信
判定処理は、ＮＡＣＫ−ＲＴＣＰパケットを送信した場
合、リアルタイム再生処理に間に合うタイミングで、再
送パケットが受信可能か否かを判定するものである。
【０１２１】この判定のためには、前述したように、送
信端末と受信端末間における往復伝播遅延（ＲＴＴ）が
重要なパラメータとなる。往復伝播遅延（ＲＴＴ）が大
きい場合、データ受信端末からデータ送信端末に対して
再送要求を出しても、再送要求を発信して、再送パケッ
トがデータ送信端末から再送され、データ受信端末にお
いて受信するまでに時間を要すると、その後デコーダに
渡して復号を行なってリアルタイム再生に間に合わない
場合が発生する。本発明のシステムでは、データ受信端
末において、往復伝播遅延（ＲＴＴ）をあらかじめ把握
し、往復伝播遅延（ＲＴＴ）に基づいて、ＮＡＣＫ−Ｒ
ＴＣＰパケットの送信判定処理を行なう。
信端末と受信端末間における往復伝播遅延（ＲＴＴ）が
重要なパラメータとなる。往復伝播遅延（ＲＴＴ）が大
きい場合、データ受信端末からデータ送信端末に対して
再送要求を出しても、再送要求を発信して、再送パケッ
トがデータ送信端末から再送され、データ受信端末にお
いて受信するまでに時間を要すると、その後デコーダに
渡して復号を行なってリアルタイム再生に間に合わない
場合が発生する。本発明のシステムでは、データ受信端
末において、往復伝播遅延（ＲＴＴ）をあらかじめ把握
し、往復伝播遅延（ＲＴＴ）に基づいて、ＮＡＣＫ−Ｒ
ＴＣＰパケットの送信判定処理を行なう。
【０１２２】本発明のシステムにおいては、データ受信
端末側が、任意タイミングで、往復伝播遅延（ＲＴＴ）
の計測を実行することを可能な構成としている。具体的
には、データ受信端末から、先に説明した図９に示すＥ
ＣＨＯ−ＲＴＣＰパケットを送信し、ＥＣＨＯ−ＲＥＰ
ＬＹ−ＲＴＣＰパケットを受信して、ＲＴＴの算出を行
なう。
端末側が、任意タイミングで、往復伝播遅延（ＲＴＴ）
の計測を実行することを可能な構成としている。具体的
には、データ受信端末から、先に説明した図９に示すＥ
ＣＨＯ−ＲＴＣＰパケットを送信し、ＥＣＨＯ−ＲＥＰ
ＬＹ−ＲＴＣＰパケットを受信して、ＲＴＴの算出を行
なう。
【０１２３】図１２を参照して、データ受信端末で実行
するＥＣＨＯ−ＲＴＣＰパケットの送信、ＥＣＨＯ−Ｒ
ＥＰＬＹ−ＲＴＣＰパケットの受信、往復伝播遅延（Ｒ
ＴＴ）の算出処理について説明する。
するＥＣＨＯ−ＲＴＣＰパケットの送信、ＥＣＨＯ−Ｒ
ＥＰＬＹ−ＲＴＣＰパケットの受信、往復伝播遅延（Ｒ
ＴＴ）の算出処理について説明する。
【０１２４】図１２（ａ）は、ＥＣＨＯ−ＲＴＣＰパケ
ットの送信処理フローである。ＥＣＨＯ−ＲＴＣＰパケ
ットの送信は、データ受信端末が任意タイミングで能動
的に実行することが可能である。
ットの送信処理フローである。ＥＣＨＯ−ＲＴＣＰパケ
ットの送信は、データ受信端末が任意タイミングで能動
的に実行することが可能である。
【０１２５】ステップＳ５０１における、ＲＴＣＰパケ
ットの送信待機状態において、ＲＴＴの計測要請が発生
した場合、ステップＳ５０２のＥＣＨＯ−ＲＴＣＰパケ
ットの生成処理に移行する。ＲＴＴの計測は、データ受
信が開始された後、例えば図１１の処理フローにおい
て、ステップＳ３００の送信開始通知を受信した以降、
定期的に実行する等の設定が可能であり、データ受信側
端末に保有するタイマーで予め定めた計測間隔が経過し
たか否かを計測し、予め定めた計測間隔に対応する時間
が経過した場合に、ＡＲＱ判定部１１９が、ＥＣＨＯ−
ＲＴＣＰパケットの生成要求をパケット作成部１１６に
出力し、パケット作成部１１６がステップＳ５０２のＥ
ＣＨＯ−ＲＴＣＰパケットの生成処理を実行するなどの
設定が可能である。この他にも、パケットのロスト状況
を解析し、ロスト状況に応じてＥＣＨＯ−ＲＴＣＰパケ
ットの生成、送信を実行する構成としてもよく、いずれ
にしても、データ受信端末は、任意タイミングで、ＥＣ
ＨＯ−ＲＴＣＰパケットの生成、送信が可能であり、常
に最新の往復伝播遅延（ＲＴＴ）の算出が可能となる。
ットの送信待機状態において、ＲＴＴの計測要請が発生
した場合、ステップＳ５０２のＥＣＨＯ−ＲＴＣＰパケ
ットの生成処理に移行する。ＲＴＴの計測は、データ受
信が開始された後、例えば図１１の処理フローにおい
て、ステップＳ３００の送信開始通知を受信した以降、
定期的に実行する等の設定が可能であり、データ受信側
端末に保有するタイマーで予め定めた計測間隔が経過し
たか否かを計測し、予め定めた計測間隔に対応する時間
が経過した場合に、ＡＲＱ判定部１１９が、ＥＣＨＯ−
ＲＴＣＰパケットの生成要求をパケット作成部１１６に
出力し、パケット作成部１１６がステップＳ５０２のＥ
ＣＨＯ−ＲＴＣＰパケットの生成処理を実行するなどの
設定が可能である。この他にも、パケットのロスト状況
を解析し、ロスト状況に応じてＥＣＨＯ−ＲＴＣＰパケ
ットの生成、送信を実行する構成としてもよく、いずれ
にしても、データ受信端末は、任意タイミングで、ＥＣ
ＨＯ−ＲＴＣＰパケットの生成、送信が可能であり、常
に最新の往復伝播遅延（ＲＴＴ）の算出が可能となる。
【０１２６】ステップＳ５０２で生成するＥＣＨＯ−Ｒ
ＴＣＰパケットは、先に図９（ａ）を参照して説明した
構成を有する。パケットには、各パケット固有の識別子
としてのＥＣＨＯ−ＩＤが設定される。ステップＳ５０
３で、生成したＥＣＨＯ−ＲＴＣＰパケットが、ＲＴＣ
Ｐ入出力ポート１１３を介して、データ送信端末１０４
に対して送信される。ステップＳ５０４では、ＥＣＨＯ
−ＲＴＣＰパケットを送信した送信時間、および、パケ
ットに設定されたＥＣＨＯ−ＩＤがメモリに記録され
る。
ＴＣＰパケットは、先に図９（ａ）を参照して説明した
構成を有する。パケットには、各パケット固有の識別子
としてのＥＣＨＯ−ＩＤが設定される。ステップＳ５０
３で、生成したＥＣＨＯ−ＲＴＣＰパケットが、ＲＴＣ
Ｐ入出力ポート１１３を介して、データ送信端末１０４
に対して送信される。ステップＳ５０４では、ＥＣＨＯ
−ＲＴＣＰパケットを送信した送信時間、および、パケ
ットに設定されたＥＣＨＯ−ＩＤがメモリに記録され
る。
【０１２７】図１２（ｂ）は、ＥＣＨＯ−ＲＥＰＬＹ−
ＲＴＣＰパケットの受信およびＲＴＴ算出処理フローで
ある。ステップＳ６０１における、ＲＴＣＰパケットの
送信待機状態において、ＥＣＨＯ−ＲＥＰＬＹ−ＲＴＣ
Ｐパケットが受信されたと判定（ステップＳ６０２でＹ
ｅｓ）されると、ステップＳ６０３において、ＥＣＨＯ
−ＲＥＰＬＹ−ＲＴＣＰパケットの受信時刻がメモリに
記録される。受信するＥＣＨＯ−ＲＥＰＬＹ−ＲＴＣＰ
パケットは、先に図９（ｂ）を参照して説明した構成を
有する。パケットには、応答対象となった対応するＥＣ
ＨＯ−ＲＴＣＰパケットと同一の識別子としてのＥＣＨ
Ｏ−ＩＤが設定され、さらに、データ送信端末において
算出したサーバ処理時間が格納される。
ＲＴＣＰパケットの受信およびＲＴＴ算出処理フローで
ある。ステップＳ６０１における、ＲＴＣＰパケットの
送信待機状態において、ＥＣＨＯ−ＲＥＰＬＹ−ＲＴＣ
Ｐパケットが受信されたと判定（ステップＳ６０２でＹ
ｅｓ）されると、ステップＳ６０３において、ＥＣＨＯ
−ＲＥＰＬＹ−ＲＴＣＰパケットの受信時刻がメモリに
記録される。受信するＥＣＨＯ−ＲＥＰＬＹ−ＲＴＣＰ
パケットは、先に図９（ｂ）を参照して説明した構成を
有する。パケットには、応答対象となった対応するＥＣ
ＨＯ−ＲＴＣＰパケットと同一の識別子としてのＥＣＨ
Ｏ−ＩＤが設定され、さらに、データ送信端末において
算出したサーバ処理時間が格納される。
【０１２８】ステップＳ６０４では、受信したＥＣＨＯ
−ＲＥＰＬＹ−ＲＴＣＰパケットからサーバ処理時間が
抽出され、ステップＳ６０５において、受信したＥＣＨ
Ｏ−ＲＥＰＬＹ−ＲＴＣＰパケットに設定されたＥＣＨ
Ｏ−ＩＤから対応するＥＣＨＯ−ＲＴＣＰパケットの送
信時間が検索される。
−ＲＥＰＬＹ−ＲＴＣＰパケットからサーバ処理時間が
抽出され、ステップＳ６０５において、受信したＥＣＨ
Ｏ−ＲＥＰＬＹ−ＲＴＣＰパケットに設定されたＥＣＨ
Ｏ−ＩＤから対応するＥＣＨＯ−ＲＴＣＰパケットの送
信時間が検索される。
【０１２９】ステップＳ６０６では、ステップＳ６０３
において取得したＥＣＨＯ−ＲＥＰＬＹ−ＲＴＣＰパケ
ットの受信時刻、ステップＳ６０４において取得したサ
ーバ処理時間、ステップＳ６０３において取得したＥＣ
ＨＯ−ＲＴＣＰパケットの送信時間に基づいて、往復伝
播遅延（ＲＴＴ）の算出処理が実行される。往復伝播遅
延（ＲＴＴ）の算出は、下式に基づいて実行される。 往復伝播遅延（ＲＴＴ）＝(ECHO-REPLAY受信時刻)-(ECH
O送信時刻)-(サーバ処理時間)
において取得したＥＣＨＯ−ＲＥＰＬＹ−ＲＴＣＰパケ
ットの受信時刻、ステップＳ６０４において取得したサ
ーバ処理時間、ステップＳ６０３において取得したＥＣ
ＨＯ−ＲＴＣＰパケットの送信時間に基づいて、往復伝
播遅延（ＲＴＴ）の算出処理が実行される。往復伝播遅
延（ＲＴＴ）の算出は、下式に基づいて実行される。 往復伝播遅延（ＲＴＴ）＝(ECHO-REPLAY受信時刻)-(ECH
O送信時刻)-(サーバ処理時間)
【０１３０】なお、ＲＴＴの計測を実行する際に送受信
するＥＣＨＯ，ＥＣＨＯ−ＲＥＰＬＹパケットも損失す
ることが考えられる。またＲＴＴもネットワークの状況
により常に変動するため、データ受信端末は一定間隔で
ＥＣＨＯ，ＥＣＨＯ−ＲＥＰＬＹパケットの送受信処理
を実行してＲＴＴを計測する。
するＥＣＨＯ，ＥＣＨＯ−ＲＥＰＬＹパケットも損失す
ることが考えられる。またＲＴＴもネットワークの状況
により常に変動するため、データ受信端末は一定間隔で
ＥＣＨＯ，ＥＣＨＯ−ＲＥＰＬＹパケットの送受信処理
を実行してＲＴＴを計測する。
【０１３１】図１１のフローに戻り、データ受信端末側
の処理について説明を続ける。図１１のフローにおい
て、ステップＳ３１２では、再送要求としてのＮＡＣＫ
−ＲＴＣＰを出力した場合、リアルタイム再生処理に間
に合うタイミングで再送要求パケットの受信が可能か否
かを判定する。上述したＥＣＨＯ，ＥＣＨＯ−ＲＥＰＬ
Ｙパケットの送受信処理により計測されたＲＴＴ値と、
各フレームの処理タイミングを計測しているタイマーの
期限に基づいて、再送要求としてのＮＡＣＫ−ＲＴＣＰ
パケットを出しても間に合わないと判断した場合（Ｓ３
１２でＮｏ）には、ＮＡＣＫ−ＲＴＣＰパケットの送信
処理は実行しない。
の処理について説明を続ける。図１１のフローにおい
て、ステップＳ３１２では、再送要求としてのＮＡＣＫ
−ＲＴＣＰを出力した場合、リアルタイム再生処理に間
に合うタイミングで再送要求パケットの受信が可能か否
かを判定する。上述したＥＣＨＯ，ＥＣＨＯ−ＲＥＰＬ
Ｙパケットの送受信処理により計測されたＲＴＴ値と、
各フレームの処理タイミングを計測しているタイマーの
期限に基づいて、再送要求としてのＮＡＣＫ−ＲＴＣＰ
パケットを出しても間に合わないと判断した場合（Ｓ３
１２でＮｏ）には、ＮＡＣＫ−ＲＴＣＰパケットの送信
処理は実行しない。
【０１３２】たとえば、パケット損失の存在する該当フ
レームの符号化データの処理開始までの時間Ｔａ＝１０
０ｍｍｓｅｃである場合、すなわち１００ｍｍｓｅｃ後
にデコーダにデータを渡して復号処理が開始されること
がタイマーの計測により明らかとなっている場合、計測
された最新のＲＴＴ値が、該当フレームの符号化データ
の処理開始までの時間Ｔａより大きい値であった場合、
すなわち、１００ｍｍｓｅｃ以上であった場合には、再
送要求としてのＮＡＣＫ−ＲＴＣＰパケットを送信して
も、再送パケットの受信が、デコード処理開始タイミン
グに間に合わないものと判断して、ＮＡＣＫ−ＲＴＣＰ
パケットの送信処理を実行しない。ただし、ＲＴＴ値が
処理開始までの時間Ｔａ以上であっても、ＲＴＴ値と時
間：Ｔａの非常に近い値を持つ場合には、ぎりぎり間に
合う可能性もあるためＮＡＣＫを送出する構成としても
よい。このＮＡＣＫ送出判定の閾値は実装依存である。
レームの符号化データの処理開始までの時間Ｔａ＝１０
０ｍｍｓｅｃである場合、すなわち１００ｍｍｓｅｃ後
にデコーダにデータを渡して復号処理が開始されること
がタイマーの計測により明らかとなっている場合、計測
された最新のＲＴＴ値が、該当フレームの符号化データ
の処理開始までの時間Ｔａより大きい値であった場合、
すなわち、１００ｍｍｓｅｃ以上であった場合には、再
送要求としてのＮＡＣＫ−ＲＴＣＰパケットを送信して
も、再送パケットの受信が、デコード処理開始タイミン
グに間に合わないものと判断して、ＮＡＣＫ−ＲＴＣＰ
パケットの送信処理を実行しない。ただし、ＲＴＴ値が
処理開始までの時間Ｔａ以上であっても、ＲＴＴ値と時
間：Ｔａの非常に近い値を持つ場合には、ぎりぎり間に
合う可能性もあるためＮＡＣＫを送出する構成としても
よい。このＮＡＣＫ送出判定の閾値は実装依存である。
【０１３３】一方、計測された最新のＲＴＴ値が、パケ
ット損失の存在する該当フレームの符号化データの処理
開始までの時間Ｔａ以下であった場合には、再送要求と
してのＮＡＣＫ−ＲＴＣＰパケットを送信して再送パケ
ットを受信するまでの時間が、デコード処理開始タイミ
ングまでの時間以下であるので、再送パケット受信が処
理に間に合うものと判断して、ステップＳ３１３におい
て、ＮＡＣＫ−ＲＴＣＰパケットの送信処理を実行す
る。
ット損失の存在する該当フレームの符号化データの処理
開始までの時間Ｔａ以下であった場合には、再送要求と
してのＮＡＣＫ−ＲＴＣＰパケットを送信して再送パケ
ットを受信するまでの時間が、デコード処理開始タイミ
ングまでの時間以下であるので、再送パケット受信が処
理に間に合うものと判断して、ステップＳ３１３におい
て、ＮＡＣＫ−ＲＴＣＰパケットの送信処理を実行す
る。
【０１３４】ステップＳ３０９のロストパケットの検出
処理は、ステップＳ３０２の各フレームの終端パケット
受信、ステップＳ３０３の各フレームの先頭パケット受
信時のみではなく、ステップＳ３０４の各フレームの最
終再送時間の判定でＹｅｓの場合、およびステップＳ３
０５のタイマーの最小計測時間τの経過判定でＹｅｓの
場合に実行される。
処理は、ステップＳ３０２の各フレームの終端パケット
受信、ステップＳ３０３の各フレームの先頭パケット受
信時のみではなく、ステップＳ３０４の各フレームの最
終再送時間の判定でＹｅｓの場合、およびステップＳ３
０５のタイマーの最小計測時間τの経過判定でＹｅｓの
場合に実行される。
【０１３５】図５を参照して、ステップＳ３０４の各フ
レームの最終再送時間の判定処理、およびステップＳ３
０５のタイマーの最小計測時間τの経過判定処理につい
て説明する。
レームの最終再送時間の判定処理、およびステップＳ３
０５のタイマーの最小計測時間τの経過判定処理につい
て説明する。
【０１３６】ステップＳ３０４の各フレームの最終再送
時間の判定処理は、再送要求としてのＮＡＣＫ−ＲＴＣ
Ｐを出力した場合、リアルタイム再生処理に間に合う最
終時間判定処理である。各フレームについて、各フレー
ムの符号化データの処理開始までの時間Ｔａが計測され
ているＲＴＴ値と等しくなったとき、すなわち、Ｔａ＝
ＲＴＴとなった場合に、ステップＳ３０４の判定がＹｅ
ｓとなり、ステップＳ３０９の該当フレームに対するロ
ストパケットの検出処理が実行される。これは、最後の
再送要求可能タイミングにロストパケットを検出して、
検出された場合に最後の再送要求を送信するための処理
である。
時間の判定処理は、再送要求としてのＮＡＣＫ−ＲＴＣ
Ｐを出力した場合、リアルタイム再生処理に間に合う最
終時間判定処理である。各フレームについて、各フレー
ムの符号化データの処理開始までの時間Ｔａが計測され
ているＲＴＴ値と等しくなったとき、すなわち、Ｔａ＝
ＲＴＴとなった場合に、ステップＳ３０４の判定がＹｅ
ｓとなり、ステップＳ３０９の該当フレームに対するロ
ストパケットの検出処理が実行される。これは、最後の
再送要求可能タイミングにロストパケットを検出して、
検出された場合に最後の再送要求を送信するための処理
である。
【０１３７】図５において、右下部に示してあるよう
に、タイムスタンプ＝１２０００の処理開始までの時間
Ｔａ＝ＲＴＴとなったとき、ステップＳ３０４におい
て、タイムスタンプ＝１２０００に対応するフレームに
ついての最終再送時間の判定処理がＹｅｓと判定され、
ステップＳ３０９において、タイムスタンプ＝１２００
０のフレームに対するロストパケットの検出処理が実行
され、ロストパケットが検出された場合に、ステップＳ
３１３において最後の再送要求を送信する。図５におけ
るＮＡＣＫ−ＲＴＣＰパケット送信処理５０５がこれに
相当する。
に、タイムスタンプ＝１２０００の処理開始までの時間
Ｔａ＝ＲＴＴとなったとき、ステップＳ３０４におい
て、タイムスタンプ＝１２０００に対応するフレームに
ついての最終再送時間の判定処理がＹｅｓと判定され、
ステップＳ３０９において、タイムスタンプ＝１２００
０のフレームに対するロストパケットの検出処理が実行
され、ロストパケットが検出された場合に、ステップＳ
３１３において最後の再送要求を送信する。図５におけ
るＮＡＣＫ−ＲＴＣＰパケット送信処理５０５がこれに
相当する。
【０１３８】ステップＳ３０５のタイマーの最小計測時
間τの経過判定処理は、データ受信端末の有するタイマ
ーの計測最小時間：τ毎に、ステップＳ３０５の判定が
Ｙｅｓとなり、ステップＳ３０９の該当フレームに対す
るロストパケットの検出処理が実行される。これは、各
計測最小時間：τに対応する受信フレームについて、各
フレームの先頭パケット、最終パケットの検出がなされ
ない場合でもロストパケットを確実に検出して、再送要
求を実行しようとするための処理である。図５における
ＮＡＣＫ−ＲＴＣＰパケット送信処理５０２，５０３が
これに相当する。
間τの経過判定処理は、データ受信端末の有するタイマ
ーの計測最小時間：τ毎に、ステップＳ３０５の判定が
Ｙｅｓとなり、ステップＳ３０９の該当フレームに対す
るロストパケットの検出処理が実行される。これは、各
計測最小時間：τに対応する受信フレームについて、各
フレームの先頭パケット、最終パケットの検出がなされ
ない場合でもロストパケットを確実に検出して、再送要
求を実行しようとするための処理である。図５における
ＮＡＣＫ−ＲＴＣＰパケット送信処理５０２，５０３が
これに相当する。
【０１３９】図５におけるＮＡＣＫ−ＲＴＣＰパケット
送信処理５０２は、そのタイミングまでに受信済みのタ
イムスタンプのフレームを構成するパケット中のロスト
パケットとして、パケット（シーケンス番号＝５，１
２）を抽出し、シーケンス番号５，１２のロストパケッ
トに関するＮＡＣＫ−ＲＴＣＰパケットが生成され、先
に図６を参照して説明したＮＡＣＫ−ＲＴＣＰパケット
の再送指定シーケンス番号として５，１２を設定したパ
ケットを再送要求パケットとしてデータ送信端末に対し
て送信する。なお、シーケンス番号５の再送要求は、２
回目となるので、ＮＡＣＫ−ＲＴＣＰパケットのシーケ
ンス番号５に対応する「再送回数」フィールドには、
［２］が設定される。
送信処理５０２は、そのタイミングまでに受信済みのタ
イムスタンプのフレームを構成するパケット中のロスト
パケットとして、パケット（シーケンス番号＝５，１
２）を抽出し、シーケンス番号５，１２のロストパケッ
トに関するＮＡＣＫ−ＲＴＣＰパケットが生成され、先
に図６を参照して説明したＮＡＣＫ−ＲＴＣＰパケット
の再送指定シーケンス番号として５，１２を設定したパ
ケットを再送要求パケットとしてデータ送信端末に対し
て送信する。なお、シーケンス番号５の再送要求は、２
回目となるので、ＮＡＣＫ−ＲＴＣＰパケットのシーケ
ンス番号５に対応する「再送回数」フィールドには、
［２］が設定される。
【０１４０】図５におけるＮＡＣＫ−ＲＴＣＰパケット
送信処理５０３は、そのタイミングまでに受信済みのタ
イムスタンプのフレームを構成するパケット中のロスト
パケットとして、パケット（シーケンス番号＝５）を抽
出し、シーケンス番号５のロストパケットに関するＮＡ
ＣＫ−ＲＴＣＰパケットを生成して送信する。なお、シ
ーケンス番号５の再送要求は、３回目となるので、ＮＡ
ＣＫ−ＲＴＣＰパケットのシーケンス番号５に対応する
「再送回数」フィールドには、［３］が設定される。
送信処理５０３は、そのタイミングまでに受信済みのタ
イムスタンプのフレームを構成するパケット中のロスト
パケットとして、パケット（シーケンス番号＝５）を抽
出し、シーケンス番号５のロストパケットに関するＮＡ
ＣＫ−ＲＴＣＰパケットを生成して送信する。なお、シ
ーケンス番号５の再送要求は、３回目となるので、ＮＡ
ＣＫ−ＲＴＣＰパケットのシーケンス番号５に対応する
「再送回数」フィールドには、［３］が設定される。
【０１４１】このように、データ受信端末では、ステッ
プＳ３０２の各フレームの終端パケット受信、ステップ
Ｓ３０３の各フレームの先頭パケット受信時、ステップ
Ｓ３０４の各フレームの最終再送時間の判定、およびス
テップＳ３０５のタイマーの最小計測時間τの経過判定
の各タイミングにおいて、ステップＳ３０９のロストパ
ケットの検出処理を実行する。なお、これらステップＳ
３０２〜Ｓ３０５の４種類のタイミングのいずれかのみ
を実行する構成としてもよい。
プＳ３０２の各フレームの終端パケット受信、ステップ
Ｓ３０３の各フレームの先頭パケット受信時、ステップ
Ｓ３０４の各フレームの最終再送時間の判定、およびス
テップＳ３０５のタイマーの最小計測時間τの経過判定
の各タイミングにおいて、ステップＳ３０９のロストパ
ケットの検出処理を実行する。なお、これらステップＳ
３０２〜Ｓ３０５の４種類のタイミングのいずれかのみ
を実行する構成としてもよい。
【０１４２】ステップＳ３０９の各フレームのロストパ
ケット検出処理において、ロストパケットが検出されな
かった場合は、各パケットに格納された符号化データの
デコード（復号）処理がデコーダ１２０において実行さ
れる。ステップＳ３１１では、受信済みパケットについ
ての受信確認パケットとしてのＡＣＫ−ＲＴＣＰパケッ
トの生成、送信が行われる。ＡＣＫ−ＲＴＣＰパケット
は、先に図８を参照して説明した通り、受信済みシーケ
ンス番号を格納したパケットである。このＡＣＫ−ＲＴ
ＣＰパケットを受信したデータ送信端末は、ＡＣＫ−Ｒ
ＴＣＰパケットに記録された受信済みシーケンス番号に
対応するパケットをバッファ１０３からクリアする。
ケット検出処理において、ロストパケットが検出されな
かった場合は、各パケットに格納された符号化データの
デコード（復号）処理がデコーダ１２０において実行さ
れる。ステップＳ３１１では、受信済みパケットについ
ての受信確認パケットとしてのＡＣＫ−ＲＴＣＰパケッ
トの生成、送信が行われる。ＡＣＫ−ＲＴＣＰパケット
は、先に図８を参照して説明した通り、受信済みシーケ
ンス番号を格納したパケットである。このＡＣＫ−ＲＴ
ＣＰパケットを受信したデータ送信端末は、ＡＣＫ−Ｒ
ＴＣＰパケットに記録された受信済みシーケンス番号に
対応するパケットをバッファ１０３からクリアする。
【０１４３】図５のタイムシーケンス図では、受信端末
から送信端末へのＡＣＫ−ＲＴＣＰパケットの送信は、
タイムスタンプ＝１５０００のフレームデータに関して
は、ＡＣＫ−ＲＴＣＰパケット送信処理５１１において
実行され、タイムスタンプ＝１８０００のフレームデー
タに関しては、ＡＣＫ−ＲＴＣＰパケット送信処理５１
２において実行され、タイムスタンプ＝２１０００のフ
レームデータに関しては、ＡＣＫ−ＲＴＣＰパケット送
信処理５１３において実行されている。
から送信端末へのＡＣＫ−ＲＴＣＰパケットの送信は、
タイムスタンプ＝１５０００のフレームデータに関して
は、ＡＣＫ−ＲＴＣＰパケット送信処理５１１において
実行され、タイムスタンプ＝１８０００のフレームデー
タに関しては、ＡＣＫ−ＲＴＣＰパケット送信処理５１
２において実行され、タイムスタンプ＝２１０００のフ
レームデータに関しては、ＡＣＫ−ＲＴＣＰパケット送
信処理５１３において実行されている。
【０１４４】図１１に示すフローのステップＳ３０６で
は、各フレームのタイマー期限切れを確認する。このタ
イマー期限は、リアルタイム再生処理の開始期限を計測
するタイマーによって設定される期限であり、各フレー
ム毎にそのタイミングが設定される。ｎフレームのタイ
マー期限切れであると判定された場合には、ロストパケ
ットがあった場合であっても、ステップＳ３１０のデコ
ード処理に移行することになる。
は、各フレームのタイマー期限切れを確認する。このタ
イマー期限は、リアルタイム再生処理の開始期限を計測
するタイマーによって設定される期限であり、各フレー
ム毎にそのタイミングが設定される。ｎフレームのタイ
マー期限切れであると判定された場合には、ロストパケ
ットがあった場合であっても、ステップＳ３１０のデコ
ード処理に移行することになる。
【０１４５】ステップＳ３０７では、データ送信端末か
ら、データストリームの終了を明示するＥＯＳ（End Of
Stream）メッセージを持つＲＴＣＰパケットを受信し
たか否かを判定し、ＥＯＳ−ＲＴＣＰパケット受信でな
い場合は、ステップＳ３０１以下の処理を繰り返す。
ら、データストリームの終了を明示するＥＯＳ（End Of
Stream）メッセージを持つＲＴＣＰパケットを受信し
たか否かを判定し、ＥＯＳ−ＲＴＣＰパケット受信でな
い場合は、ステップＳ３０１以下の処理を繰り返す。
【０１４６】ＥＯＳ−ＲＴＣＰパケット受信である場合
は、ステップＳ３０８において、各フレームのタイマー
期限切れを確認する。このタイマー期限は、リアルタイ
ム再生処理の開始期限を計測するタイマーによって設定
される期限であり、各フレーム毎にそのタイミングが設
定される。タイマー期限切れでない場合は、ステップＳ
３１４に進み、再送要求されているロストパケットに関
する再送パケットを受信待機状態であるか否かを判定し
て、待機状態である場合は、ステップＳ３１５に進み、
再送パケットの受信待機状態として、ステップＳ３０１
のパケット受信以下の処理を実行する。
は、ステップＳ３０８において、各フレームのタイマー
期限切れを確認する。このタイマー期限は、リアルタイ
ム再生処理の開始期限を計測するタイマーによって設定
される期限であり、各フレーム毎にそのタイミングが設
定される。タイマー期限切れでない場合は、ステップＳ
３１４に進み、再送要求されているロストパケットに関
する再送パケットを受信待機状態であるか否かを判定し
て、待機状態である場合は、ステップＳ３１５に進み、
再送パケットの受信待機状態として、ステップＳ３０１
のパケット受信以下の処理を実行する。
【０１４７】ステップＳ３０８における各フレームのタ
イマー期限切れの確認処理において、Ｙｅｓと判定され
た場合、および、ステップＳ３１４において、再送パケ
ット受信待機状態でないと判定された場合は、デコー
ド、再生処理へ移行すべき未受信のパケットデータは存
在しないと判定され、受信処理を完了する。
イマー期限切れの確認処理において、Ｙｅｓと判定され
た場合、および、ステップＳ３１４において、再送パケ
ット受信待機状態でないと判定された場合は、デコー
ド、再生処理へ移行すべき未受信のパケットデータは存
在しないと判定され、受信処理を完了する。
【０１４８】このように、本発明のシステムにおいて
は、リアルタイム配信に適するものの信頼性を保証しな
いＲＴＰ等のデータ通信プロトコルに従ったパケット伝
送において、ＡＲＱ機能を付加することで、エラー耐性
のある信頼性の高いデータ伝送、リアルタイム再生が可
能となる。なお、上述の実施例では、ＲＴＰパケットに
符号化データを格納する構成例を中心として説明した
が、ＲＴＰパケットフォーマットに限らず、ＵＤＰ等、
他のデータ通信プロトコルフォーマットに従ったパケッ
トを用いたデータ通信構成においても、上述の実施例と
同様の各種のコントロールパケットを用いた再送要求処
理を行なうことにより、上述の実施例と同様の構成を実
現可能である。
は、リアルタイム配信に適するものの信頼性を保証しな
いＲＴＰ等のデータ通信プロトコルに従ったパケット伝
送において、ＡＲＱ機能を付加することで、エラー耐性
のある信頼性の高いデータ伝送、リアルタイム再生が可
能となる。なお、上述の実施例では、ＲＴＰパケットに
符号化データを格納する構成例を中心として説明した
が、ＲＴＰパケットフォーマットに限らず、ＵＤＰ等、
他のデータ通信プロトコルフォーマットに従ったパケッ
トを用いたデータ通信構成においても、上述の実施例と
同様の各種のコントロールパケットを用いた再送要求処
理を行なうことにより、上述の実施例と同様の構成を実
現可能である。
【０１４９】上述したように本発明の構成では、再送要
求の処理タイミングとして、各フレームの先頭パケット
の受信時、各フレームの最終パケットの受信時、最終処
理期限、および一定間隔（τ）毎等の各種タイミングで
ロストパケットの検出処理を実行する構成としたので、
確実なロストパケットの検出が可能となる。
求の処理タイミングとして、各フレームの先頭パケット
の受信時、各フレームの最終パケットの受信時、最終処
理期限、および一定間隔（τ）毎等の各種タイミングで
ロストパケットの検出処理を実行する構成としたので、
確実なロストパケットの検出が可能となる。
【０１５０】また、データ受信端末は、再生処理時間、
伝播遅延時間ＲＴＴを考慮したデータ再送要求処理を実
行するので、無駄な再送要求パケットおよび再送パケッ
トを出すことを防ぐ事ができ、ネットワークの帯域を再
送によって狭めることがない。また、データ受信端末
が、パケットの送受信情報を随時記録し、パケットロス
率の割り出しにより、ロス率が一定値以上になった場
合、おなじＮＡＣＫ−ＲＴＣＰパケットを複数回、重ね
て送信することで、再送成功率を高めることが可能とな
る。
伝播遅延時間ＲＴＴを考慮したデータ再送要求処理を実
行するので、無駄な再送要求パケットおよび再送パケッ
トを出すことを防ぐ事ができ、ネットワークの帯域を再
送によって狭めることがない。また、データ受信端末
が、パケットの送受信情報を随時記録し、パケットロス
率の割り出しにより、ロス率が一定値以上になった場
合、おなじＮＡＣＫ−ＲＴＣＰパケットを複数回、重ね
て送信することで、再送成功率を高めることが可能とな
る。
【０１５１】また、受信端末において送信する再送要求
としてのＮＡＣＫ−ＲＴＣＰパケットに重複指定回数の
設定を可能としたので、ネットワーク状況に応じて、ま
た受信側の要求に応じて再送パケットの重複送信を要求
することが可能となり、重要データの受信成功率を高め
ることが可能となる。例えば、再生に間に合うための最
終的な再送パケットについて重複再送を要求すること
で、高品質なデータ再生が可能となる。
としてのＮＡＣＫ−ＲＴＣＰパケットに重複指定回数の
設定を可能としたので、ネットワーク状況に応じて、ま
た受信側の要求に応じて再送パケットの重複送信を要求
することが可能となり、重要データの受信成功率を高め
ることが可能となる。例えば、再生に間に合うための最
終的な再送パケットについて重複再送を要求すること
で、高品質なデータ再生が可能となる。
【０１５２】また、データ受信端末側から受信パケット
に関するＡＣＫメッセージを、例えば画像のフレーム
毎、またはあるブロック毎に応じて送信側に送信する構
成としたので、パケット毎のＡＣＫ送信による帯域の寡
占状態の発生が防止され、また、データ送信側は、デー
タ受信側から受信するＡＣＫパケットに基づいて、再送
処理のためのパケット格納バッファから、該当パケット
を能動的に破棄でき、バッファ溢れ、バッファ欠如を防
ぐことができる。
に関するＡＣＫメッセージを、例えば画像のフレーム
毎、またはあるブロック毎に応じて送信側に送信する構
成としたので、パケット毎のＡＣＫ送信による帯域の寡
占状態の発生が防止され、また、データ送信側は、デー
タ受信側から受信するＡＣＫパケットに基づいて、再送
処理のためのパケット格納バッファから、該当パケット
を能動的に破棄でき、バッファ溢れ、バッファ欠如を防
ぐことができる。
【０１５３】［データ送受信端末装置構成例］上述の実
施例で述べた一連の処理は、ハードウェア、またはソフ
トウェア、あるいは両者の複合構成によって実行するこ
とが可能である。ソフトウェアによる処理を実行する場
合は、処理シーケンスを記録したプログラムを、専用の
ハードウェアに組み込まれたデータ処理装置内のメモリ
にインストールして実行させるか、あるいは、各種処理
が実行可能な汎用コンピュータにプログラムをインスト
ールして実行させることが可能である。一連の処理をソ
フトウェアによって行う場合には、そのソフトウェアを
構成するプログラムが、例えば汎用のコンピュータやマ
イクロコンピュータ等にインストールされる。
施例で述べた一連の処理は、ハードウェア、またはソフ
トウェア、あるいは両者の複合構成によって実行するこ
とが可能である。ソフトウェアによる処理を実行する場
合は、処理シーケンスを記録したプログラムを、専用の
ハードウェアに組み込まれたデータ処理装置内のメモリ
にインストールして実行させるか、あるいは、各種処理
が実行可能な汎用コンピュータにプログラムをインスト
ールして実行させることが可能である。一連の処理をソ
フトウェアによって行う場合には、そのソフトウェアを
構成するプログラムが、例えば汎用のコンピュータやマ
イクロコンピュータ等にインストールされる。
【０１５４】図１３に、上述の実施例で述べた一連の処
理を実行するデータ送信端末装置、データ受信端末装置
のシステム構成例を示す。本発明のシステムで送受信さ
れるデータは、符号化データであり、データ送信装置で
はエンコード（符号化）処理が実行され、データ受信装
置ではデコード（復号）処理が実行される。符号化され
たデータはパケットとしてネットワークを介して送受信
する。そのため、データ送信側では、パケット生成（パ
ケタイズ処理）を実行し、データ受信側ではパケット展
開（デパケタイズ処理）を実行する。
理を実行するデータ送信端末装置、データ受信端末装置
のシステム構成例を示す。本発明のシステムで送受信さ
れるデータは、符号化データであり、データ送信装置で
はエンコード（符号化）処理が実行され、データ受信装
置ではデコード（復号）処理が実行される。符号化され
たデータはパケットとしてネットワークを介して送受信
する。そのため、データ送信側では、パケット生成（パ
ケタイズ処理）を実行し、データ受信側ではパケット展
開（デパケタイズ処理）を実行する。
【０１５５】図１３に示すデータ送受信装置（ｅｘ．Ｐ
Ｃ）８５０は、エンコード（符号化）処理、デコード
（復号）処理を実行するとともにパケット生成、展開処
理を実行するコーデック８５１、通信ネットワークとの
インタフェースとして機能するネットワークインタフェ
ース８５２、マウス８３７、キーボード８３６等の入力
機器との入出力インタフェース８５３、ビデオカメラ８
３３、マイク８３４、スピーカ８３５等のＡＶデータ入
出力機器からのデータ入出力を行なうＡＶインタフェー
ス８５４、ディスプレイ８３２に対するデータ出力イン
タフェースとしてのディスプレイ・インタフェース８５
５、各データ入出力インタフェース、コーデック８５
１、ネットワークインタフェース８５２間のデータ転送
制御、その他各種プログラム制御を実行するＣＰＵ８５
６、ＣＰＵ８５６により制御実行される各種プログラム
の格納、データの格納、ＣＰＵ８５６のワークエリアと
して機能するＲＡＭ、ＲＯＭからなるメモリ８５７、デ
ータ格納、プログラム格納用の記憶媒体としてのＨＤＤ
８５８を有し、それぞれＰＣＩバス８５９に接続され、
相互のデータ送受信が可能な構成を持つ。
Ｃ）８５０は、エンコード（符号化）処理、デコード
（復号）処理を実行するとともにパケット生成、展開処
理を実行するコーデック８５１、通信ネットワークとの
インタフェースとして機能するネットワークインタフェ
ース８５２、マウス８３７、キーボード８３６等の入力
機器との入出力インタフェース８５３、ビデオカメラ８
３３、マイク８３４、スピーカ８３５等のＡＶデータ入
出力機器からのデータ入出力を行なうＡＶインタフェー
ス８５４、ディスプレイ８３２に対するデータ出力イン
タフェースとしてのディスプレイ・インタフェース８５
５、各データ入出力インタフェース、コーデック８５
１、ネットワークインタフェース８５２間のデータ転送
制御、その他各種プログラム制御を実行するＣＰＵ８５
６、ＣＰＵ８５６により制御実行される各種プログラム
の格納、データの格納、ＣＰＵ８５６のワークエリアと
して機能するＲＡＭ、ＲＯＭからなるメモリ８５７、デ
ータ格納、プログラム格納用の記憶媒体としてのＨＤＤ
８５８を有し、それぞれＰＣＩバス８５９に接続され、
相互のデータ送受信が可能な構成を持つ。
【０１５６】コーデック８５１は、図１３に示すよう
に、例えばビデオカメラ８３３からの画像データ、マイ
ク８３４からの音声データを入力し、符号化処理、パケ
ット生成処理（パケタイズ）を実行し、最終的に符号化
データをペイロードとしたパケットを生成する。生成さ
れたパケットは、ＰＣＩバス８５９上に出力され、ネッ
トワークインタフェース８５２を介してネットワークに
出力され、パケットのヘッダに設定された宛先アドレス
に配信される。
に、例えばビデオカメラ８３３からの画像データ、マイ
ク８３４からの音声データを入力し、符号化処理、パケ
ット生成処理（パケタイズ）を実行し、最終的に符号化
データをペイロードとしたパケットを生成する。生成さ
れたパケットは、ＰＣＩバス８５９上に出力され、ネッ
トワークインタフェース８５２を介してネットワークに
出力され、パケットのヘッダに設定された宛先アドレス
に配信される。
【０１５７】また、ＨＤＤ８５８またはメモリ８５７に
格納されたソフトウェアエンコードプログラムに従って
ＣＰＵ８５６の制御により、ビデオカメラ８３３からの
画像データ、マイク８３４からの音声データを符号化し
てネットワークインタフェース８５２を介してネットワ
ークに出力する処理も実行する構成としてもよい。
格納されたソフトウェアエンコードプログラムに従って
ＣＰＵ８５６の制御により、ビデオカメラ８３３からの
画像データ、マイク８３４からの音声データを符号化し
てネットワークインタフェース８５２を介してネットワ
ークに出力する処理も実行する構成としてもよい。
【０１５８】一方、ネットワークを介して入力するＩＰ
パケット化されたデータは、ネットワークインタフェー
ス８５２を介して、バス８５６上に出力されて、コーデ
ック８５１に入力される。コーデック８５１では入力デ
ータのパケット展開処理（デパケタイズ）を実行し、ペ
イロードとして格納された符号化データを抽出後、復号
処理を実行して、ディスプレイ８３２、スピーカ８３５
において再生、出力する。
パケット化されたデータは、ネットワークインタフェー
ス８５２を介して、バス８５６上に出力されて、コーデ
ック８５１に入力される。コーデック８５１では入力デ
ータのパケット展開処理（デパケタイズ）を実行し、ペ
イロードとして格納された符号化データを抽出後、復号
処理を実行して、ディスプレイ８３２、スピーカ８３５
において再生、出力する。
【０１５９】上述の実施例における処理対象となる画像
等のデータは、カメラ他の入力機器、例えばスキャナ等
のデータ入力装置、あるいはフロッピー（登録商標）デ
ィスク、ＣＤ−ＲＯＭ(Compact Disc Read Only Memor
y)，ＭＯ(Magneto optical)ディスク，ＤＶＤ(Digital
Versatile Disc)、磁気ディスク、半導体メモリなどの
リムーバブル記録媒体から入力可能である。
等のデータは、カメラ他の入力機器、例えばスキャナ等
のデータ入力装置、あるいはフロッピー（登録商標）デ
ィスク、ＣＤ−ＲＯＭ(Compact Disc Read Only Memor
y)，ＭＯ(Magneto optical)ディスク，ＤＶＤ(Digital
Versatile Disc)、磁気ディスク、半導体メモリなどの
リムーバブル記録媒体から入力可能である。
【０１６０】また、ＣＰＵ８５６は、ＲＯＭ格納プログ
ラムに限らず、ハードディスクに格納されているプログ
ラム、衛星若しくはネットワークから転送され、受信さ
れてインストールされたプログラム等を、ＲＡＭ(Rando
m Access Memory)等のメモリにロードして実行すること
も可能である。
ラムに限らず、ハードディスクに格納されているプログ
ラム、衛星若しくはネットワークから転送され、受信さ
れてインストールされたプログラム等を、ＲＡＭ(Rando
m Access Memory)等のメモリにロードして実行すること
も可能である。
【０１６１】ここで、本明細書において、プログラム
は、１つのコンピュータにより処理されるものであって
も良いし、複数のコンピュータによって分散処理される
ものであっても良い。さらに、プログラムは、遠方のコ
ンピュータに転送されて実行されるものであっても良
い。
は、１つのコンピュータにより処理されるものであって
も良いし、複数のコンピュータによって分散処理される
ものであっても良い。さらに、プログラムは、遠方のコ
ンピュータに転送されて実行されるものであっても良
い。
【０１６２】以上、特定の実施例を参照しながら、本発
明について詳解してきた。しかしながら、本発明の要旨
を逸脱しない範囲で当業者が該実施例の修正や代用を成
し得ることは自明である。すなわち、例示という形態で
本発明を開示してきたのであり、限定的に解釈されるべ
きではない。本発明の要旨を判断するためには、冒頭に
記載した特許請求の範囲の欄を参酌すべきである。
明について詳解してきた。しかしながら、本発明の要旨
を逸脱しない範囲で当業者が該実施例の修正や代用を成
し得ることは自明である。すなわち、例示という形態で
本発明を開示してきたのであり、限定的に解釈されるべ
きではない。本発明の要旨を判断するためには、冒頭に
記載した特許請求の範囲の欄を参酌すべきである。
【０１６３】
【発明の効果】以上、説明してきたように、本発明の構
成によれば、ＲＴＰ、ＵＤＰ等のデータ通信プロトコル
に従ったパケット送信において、ＡＲＱ機能を付加し、
再送要求の処理タイミングとして、各フレームの先頭パ
ケットの受信時、各フレームの最終パケットの受信時、
最終処理期限、および一定間隔（τ）毎等の各種タイミ
ングでロストパケットの検出処理を実行し、再送要求を
実行する構成としたので、確実なロストパケットの検出
が可能となり、エラー耐性のある信頼性の高いデータ伝
送、リアルタイム再生が可能となる。
成によれば、ＲＴＰ、ＵＤＰ等のデータ通信プロトコル
に従ったパケット送信において、ＡＲＱ機能を付加し、
再送要求の処理タイミングとして、各フレームの先頭パ
ケットの受信時、各フレームの最終パケットの受信時、
最終処理期限、および一定間隔（τ）毎等の各種タイミ
ングでロストパケットの検出処理を実行し、再送要求を
実行する構成としたので、確実なロストパケットの検出
が可能となり、エラー耐性のある信頼性の高いデータ伝
送、リアルタイム再生が可能となる。
【０１６４】また、本発明の構成によれば、データ受信
端末において、再生処理時間、伝播遅延時間ＲＴＴを考
慮し、デコード処理等を含む再生処理に間に合わない場
合には、再生要求パケットの送信を実行しない構成とし
たので、無駄な再送要求パケットおよび再送パケットを
出すことを防ぐ事ができ、ネットワークの帯域を再送処
理の多発によって狭めてしまうことを防止することが可
能となる。
端末において、再生処理時間、伝播遅延時間ＲＴＴを考
慮し、デコード処理等を含む再生処理に間に合わない場
合には、再生要求パケットの送信を実行しない構成とし
たので、無駄な再送要求パケットおよび再送パケットを
出すことを防ぐ事ができ、ネットワークの帯域を再送処
理の多発によって狭めてしまうことを防止することが可
能となる。
【０１６５】また、本発明の構成において、データ受信
端末でパケットの送受信情報を随時記録しパケットロス
率の割り出しを可能とした構成においては、データ受信
端末の検出したロス率が一定値以上になった場合に、デ
ータ受信端末が能動的におなじＮＡＣＫパケットを複数
回、重ねて送信する処理を行なうことで、再送成功率を
高めることが可能となる。
端末でパケットの送受信情報を随時記録しパケットロス
率の割り出しを可能とした構成においては、データ受信
端末の検出したロス率が一定値以上になった場合に、デ
ータ受信端末が能動的におなじＮＡＣＫパケットを複数
回、重ねて送信する処理を行なうことで、再送成功率を
高めることが可能となる。
【０１６６】また、本発明の構成において、受信端末に
おいて送信する再送要求としてのＮＡＣＫパケットに重
複指定回数の設定を可能としたため、ネットワーク状況
に応じて、また受信側の要求に応じて再送パケットの重
複送信を要求することが可能となり、重要データの受信
成功率を高めることが可能となる。特に、再生時間に間
に合うための最終的な再送パケットにおいては、そのパ
ケットが万が一損失した場合には、データ不完全のまま
再生することになるため、受信側から重複再送を要求
し、再送成功率を高めることで高品質なデータ再生が可
能となる。
おいて送信する再送要求としてのＮＡＣＫパケットに重
複指定回数の設定を可能としたため、ネットワーク状況
に応じて、また受信側の要求に応じて再送パケットの重
複送信を要求することが可能となり、重要データの受信
成功率を高めることが可能となる。特に、再生時間に間
に合うための最終的な再送パケットにおいては、そのパ
ケットが万が一損失した場合には、データ不完全のまま
再生することになるため、受信側から重複再送を要求
し、再送成功率を高めることで高品質なデータ再生が可
能となる。
【０１６７】また、本発明の構成において、データ受信
端末側から受信パケットに関するＡＣＫメッセージを、
画像のフレーム毎、ブロック毎等、パケット単位ではな
く複数パケット毎に送信する構成とすることで、ＡＣＫ
パケットによる帯域の寡占状態の発生を防止し、また、
データ送信側では、データ受信側から受信するＡＣＫパ
ケットに基づいて、再送処理のためのパケット格納バッ
ファから、該当パケットを能動的に破棄でき、バッファ
溢れ、バッファ欠如を防ぐことが可能となる。
端末側から受信パケットに関するＡＣＫメッセージを、
画像のフレーム毎、ブロック毎等、パケット単位ではな
く複数パケット毎に送信する構成とすることで、ＡＣＫ
パケットによる帯域の寡占状態の発生を防止し、また、
データ送信側では、データ受信側から受信するＡＣＫパ
ケットに基づいて、再送処理のためのパケット格納バッ
ファから、該当パケットを能動的に破棄でき、バッファ
溢れ、バッファ欠如を防ぐことが可能となる。
【図１】本発明のデータ通信システムの構成を示す図で
ある。
ある。
【図２】本発明のデータ通信システムにおいて転送され
るＲＴＰパケットフォーマットを示す図である。
るＲＴＰパケットフォーマットを示す図である。
【図３】本発明のデータ通信システムにおいて転送され
るＩＰパケットヘッダフォーマットを示す図である。
るＩＰパケットヘッダフォーマットを示す図である。
【図４】本発明のデータ通信システムにおけるデータ送
信端末の処理フローを示す図である。
信端末の処理フローを示す図である。
【図５】本発明のデータ通信システムにおけるデータ送
信端末およびデータ受信端末のデータ通信処理を説明す
るタイムシーケンス図である。
信端末およびデータ受信端末のデータ通信処理を説明す
るタイムシーケンス図である。
【図６】本発明のデータ通信システムにおいて転送され
るＮＡＣＫ−ＲＴＣＰパケットフォーマットを示す図で
ある。
るＮＡＣＫ−ＲＴＣＰパケットフォーマットを示す図で
ある。
【図７】本発明のデータ通信システムにおいて転送され
るＮＡＣＫ−ＲＴＣＰパケットにおけるオプション値の
機能について説明する図である。
るＮＡＣＫ−ＲＴＣＰパケットにおけるオプション値の
機能について説明する図である。
【図８】本発明のデータ通信システムにおいて転送され
るＡＣＫ−ＲＴＣＰパケットフォーマットを示す図であ
る。
るＡＣＫ−ＲＴＣＰパケットフォーマットを示す図であ
る。
【図９】本発明のデータ通信システムにおいて転送され
るＥＣＨＯ−ＲＴＣＰ、およびＥＣＨＯ−ＲＥＰＬＹ−
ＲＴＣＰパケットフォーマットを示す図である。
るＥＣＨＯ−ＲＴＣＰ、およびＥＣＨＯ−ＲＥＰＬＹ−
ＲＴＣＰパケットフォーマットを示す図である。
【図１０】本発明のデータ通信システムにおいて転送さ
れるＥＯＳ−ＲＴＣＰパケットフォーマットを示す図で
ある。
れるＥＯＳ−ＲＴＣＰパケットフォーマットを示す図で
ある。
【図１１】本発明のデータ通信システムにおけるデータ
受信端末の処理フローを示す図である。
受信端末の処理フローを示す図である。
【図１２】本発明のデータ通信システムにおけるデータ
受信端末のＥＣＨＯ−ＲＴＣＰ、およびＥＣＨＯ−ＲＥ
ＰＬＹ−ＲＴＣＰパケットを適用したＲＴＴ計測処理フ
ローを示す図である。
受信端末のＥＣＨＯ−ＲＴＣＰ、およびＥＣＨＯ−ＲＥ
ＰＬＹ−ＲＴＣＰパケットを適用したＲＴＴ計測処理フ
ローを示す図である。
【図１３】データ送信端末装置およびデータ受信端末装
置のシステム構成例を示す図である。
置のシステム構成例を示す図である。
１０１ ビデオカメラ
１０２ エンコーダ
１０３ バッファ
１０４ 送信側端末
１０５ ＡＲＱ処理部
１０６ ＲＴＰパケット作成部
１０７ ＲＴＣＰパケット作成部
１０８ ＲＴＣＰパケット解析部
１０９ ＲＴＣＰ入出力ポート
１１０ ＲＴＰパケット出力ポート
１１１ ＩＰネットワーク
１１２ ＲＴＰパケット入力ポート
１１３ ＲＴＣＰ入出力ポート
１１４ ＲＴＰパケット解析部
１１５ ＲＴＣＰパケット解析部
１１６ ＲＴＣＰパケット作成部
１１６ ＡＲＱ判定部
１１７ バッファ
１１８ インデックスリスト
１１９ ＡＲＱ判定部
１２０ デコーダ
８０９ ＰＣＩバス
８３２ ディスプレイ
８３３ ビデオカメラ
８３４ マイク
８３５ スピーカ
８３７ マウス
８３８ キーボード
８５０ データ送受信装置
８５１ コーデック
８５２ ネットワークインタフェース
８５３ 入出力インタフェース
８５４ ＡＶインタフェース
８５５ ディスプレイインタフェース
８５６ ＣＰＵ
８５７ メモリ
８５８ ＨＤＤ
フロントページの続き
Ｆターム(参考） 5C059 KK01 RB02 RF02 RF04 RF23
SS06 SS20 SS26 TA76 TC22
TD13 UA02 UA05 UA38 UA39
5K014 AA01 DA02 FA04 GA01
5K030 GA03 HA08 HB02 HB21 HC01
JT10 LA01 LD08 MB13
5K034 AA02 CC02 DD01 EE11 FF02
FF08 FF11 FF13 HH01 HH02
MM03 MM18
Claims (39)
- 【請求項１】データ送信装置およびデータ受信装置から
なり、ストリーム型データ転送を実行するデータ通信シ
ステムであり、 データ送信装置は、 送信データを格納したデータパケットを送信するパケッ
ト送信処理部と、 データ受信装置から受信する再送要求メッセージパケッ
トに従って再送すべきデータパケットの抽出処理を実行
する再送制御部とを有し、 データ受信装置は、 前記データ送信装置から受信するデータパケットを受信
するパケット受信処理部と、 前記データ送信装置から受信するデータパケットのエラ
ーまたはロスト・データパケットの検出に基づいて、前
記データ送信装置に対するデータパケット再送要求とし
ての再送要求メッセージパケットの送信可否を判定する
再送要求処理制御部とを有し、 前記再送要求処理制御部は、 再送要求に基づく再送データパケット受信が、再送デー
タパケット格納データの再生に伴う処理開始時間前に可
能か否かを判定し、可能であるとの判定を条件として、
再送要求送信を決定する構成を有することを特徴とする
データ通信システム。 - 【請求項２】前記データ・パケットの格納データは、符
号化データであり、 前記データ受信装置における前記再送要求処理制御部
は、 再送要求に基づく再送データパケット受信が、再送デー
タパケット格納データの復号処理を含む再生に伴う処理
開始時間前に可能か否かを判定する構成であることを特
徴とする請求項１に記載のデータ通信システム。 - 【請求項３】前記再送要求は、再送要求データパケット
の識別データとしてのシーケンス番号と、該シーケンス
番号に対応するデータパケットの重複再送の指定回数デ
ータを格納したメッセージパケットによって構成され、 前記データ送信装置は、再送要求メッセージパケットに
指定された重複再送の指定回数データに従って、指定シ
ーケンス番号のデータパケットの重複送信を実行する構
成を有することを特徴とする請求項１に記載のデータ通
信システム。 - 【請求項４】前記データ送信装置とデータ受信装置間で
転送されるデータパケットは、動画像データであり、 前記データ受信装置における前記再送要求処理制御部
は、 動画像データの１画像フレームの構成データを格納した
複数のデータパケットの終端データパケットの受信に応
じて、該終端データパケットの属する画像フレームの構
成データを格納した複数のデータパケット中のエラーま
たはロスト・データパケットの検出処理を実行する構成
であることを特徴とする請求項１に記載のデータ通信シ
ステム。 - 【請求項５】前記データ送信装置とデータ受信装置間で
転送されるデータパケットは、動画像データであり、 前記データ受信装置における前記再送要求処理制御部
は、 動画像データの１画像フレームの構成データを格納した
複数のデータパケットの先頭データパケットの受信に応
じて、該先頭データパケットの属する画像フレームの前
フレームの構成データを格納した複数のデータパケット
中のエラーまたはロスト・データパケットの検出処理を
実行する構成であることを特徴とする請求項１に記載の
データ通信システム。 - 【請求項６】前記データ受信装置における前記再送要求
処理制御部は、 データパケット格納データの再生処理開始時間に間に合
うための再送要求最終期限に基づいて、受信データパケ
ット中のエラーまたはロスト・データパケットの検出処
理を実行する構成であることを特徴とする請求項１に記
載のデータ通信システム。 - 【請求項７】前記データ受信装置における前記再送要求
処理制御部は、 定期的な時間間隔に基づいて、受信データパケット中の
エラーまたはロスト・データパケットの検出処理を実行
する構成であることを特徴とする請求項１に記載のデー
タ通信システム。 - 【請求項８】前記データ受信装置における前記再送要求
処理制御部は、 前記データ送信装置とデータ受信装置における往復伝播
遅延（ＲＴＴ）の計測処理のために前記データ送信装置
に対するエコーパケットの送信および該エコーパケット
に対するエコーリプライパケットの受信処理制御を実行
し、 該エコーパケットに基づいて算出する往復伝播遅延（Ｒ
ＴＴ）に基づいて、再送要求に基づく再送データパケッ
ト受信が、再送データパケット格納データの再生処理開
始時間前に可能か否かを判定する構成を有することを特
徴とする請求項１に記載のデータ通信システム。 - 【請求項９】前記データ受信装置の生成する再送要求メ
ッセージパケットは、 データパケットを指定するシーケンス番号指定データ、
またはパケットの属するタイムスタンプ指定データの少
なくともいずれかと、再送要求範囲を指定するオプショ
ン値によって構成され、 前記データ送信装置の再送制御部は、 前記データ受信装置から受信する再送要求メッセージパ
ケットに格納されたデータパケットを指定するシーケン
ス番号指定データ、またはパケットの属するタイムスタ
ンプ指定データの少なくともいずれか、およびオプショ
ン値に基づいて１以上の再送パケットの抽出処理を実行
する構成を有することを特徴とする請求項１に記載のデ
ータ通信システム。 - 【請求項１０】前記データパケットは、データ転送プロ
トコルとしてのＲＴＰに従ったフォーマットを有し、前
記再送要求は、制御プロトコルとしてのＲＴＣＰに従っ
たフォーマットを有することを特徴とする請求項１に記
載のデータ通信システム。 - 【請求項１１】前記データ受信装置は、 複数のデータパケットに関する再送要求を１つの再送要
求メッセージパケットとしてデータ送信装置に対して送
信する構成であることを特徴とする請求項１に記載のデ
ータ通信システム。 - 【請求項１２】前記データ受信装置は、 複数のデータパケットに関する受信確認を１つの受信確
認メッセージパケットとしてデータ送信装置に対して送
信する構成であることを特徴とする請求項１に記載のデ
ータ通信システム。 - 【請求項１３】ストリーム型データ送信を実行するデー
タ送信装置であり、 送信データを格納したデータパケットの送信処理を実行
するパケット送信処理部と、 データ受信装置から受信する再送要求に従って再送すべ
きデータパケットの抽出処理を実行する再送制御部とを
有し、 前記再送制御部は、 データ受信装置から受信する再送要求メッセージパケッ
トに指定された重複再送の指定回数データに従って、指
定データパケットの重複送信を実行する構成を有するこ
とを特徴とするデータ送信装置。 - 【請求項１４】ストリーム型データ送信を実行するデー
タ送信装置であり、 送信データを格納したデータパケットの送信処理を実行
するパケット送信処理部と、 データ受信装置から受信する再送要求に従って再送すべ
きデータパケットの抽出処理を実行する再送制御部とを
有し、 前記再送制御部は、 前記データ受信装置から受信する再送要求メッセージパ
ケットに格納されたデータパケットを指定するシーケン
ス番号指定データ、またはパケットの属するタイムスタ
ンプ指定データの少なくともいずれか、およびオプショ
ン値に基づいて１以上の再送パケットの抽出処理を実行
する構成を有することを特徴とするデータ送信装置。 - 【請求項１５】ストリーム型データ受信を実行するデー
タ受信装置であり、 データ送信装置から受信するデータパケットを受信する
パケット受信処理部と、 前記データ送信装置から受信するデータパケットのエラ
ーまたはロスト・データパケットの検出に基づいて、前
記データ送信装置に対するデータパケット再送要求とし
ての再送要求メッセージパケットの送信可否を判定する
再送要求処理制御部とを有し、 前記再送要求処理制御部は、 再送要求に基づく再送データパケット受信が、再送デー
タパケット格納データの再生に伴う処理開始時間前に可
能か否かを判定し、可能であるとの判定を条件として、
再送要求送信を決定する構成を有することを特徴とする
データ受信装置。 - 【請求項１６】前記データ・パケットの格納データは、
符号化データであり、 前記再送要求処理制御部は、 再送要求に基づく再送データパケット受信が、再送デー
タパケット格納データの復号処理を含む再生に伴う処理
開始時間前に可能か否かを判定する構成であることを特
徴とする請求項１５に記載のデータ受信装置。 - 【請求項１７】前記データ受信装置は、 再送要求データパケットの識別データとしてのシーケン
ス番号と、該シーケンス番号に対応するデータパケット
の重複再送の指定回数データを格納した再送要求メッセ
ージパケットを生成して前記データ送信装置に送信する
構成を有することを特徴とする請求項１５に記載のデー
タ受信装置。 - 【請求項１８】前記データ受信装置の受信するデータパ
ケットは、動画像データであり、 前記再送要求処理制御部は、 動画像データの１画像フレームの構成データを格納した
複数のデータパケットの終端データパケットの受信に応
じて、該終端データパケットの属する画像フレームの構
成データを格納した複数のデータパケット中のエラーま
たはロスト・データパケットの検出処理を実行する構成
であることを特徴とする請求項１５に記載のデータ受信
装置。 - 【請求項１９】前記データ受信装置の受信するデータパ
ケットは、動画像データであり、 前記再送要求処理制御部は、 動画像データの１画像フレームの構成データを格納した
複数のデータパケットの先頭データパケットの受信に応
じて、該先頭データパケットの属する画像フレームの前
フレームの構成データを格納した複数のデータパケット
中のエラーまたはロスト・データパケットの検出処理を
実行する構成であることを特徴とする請求項１５に記載
のデータ受信装置。 - 【請求項２０】前記再送要求処理制御部は、 データパケット格納データの再生処理開始時間に間に合
うための再送要求最終期限に基づいて、受信データパケ
ット中のエラーまたはロスト・データパケットの検出処
理を実行する構成であることを特徴とする請求項１５に
記載のデータ受信装置。 - 【請求項２１】前記再送要求処理制御部は、 定期的な時間間隔に基づいて、受信データパケット中の
エラーまたはロスト・データパケットの検出処理を実行
する構成であることを特徴とする請求項１５に記載のデ
ータ受信装置。 - 【請求項２２】前記再送要求処理制御部は、 前記データ送信装置とデータ受信装置における往復伝播
遅延（ＲＴＴ）の計測処理のために前記データ送信装置
に対するエコーパケットの送信および該エコーパケット
に対するエコーリプライパケットの受信処理制御を実行
し、 該エコーパケットに基づいて算出する往復伝播遅延（Ｒ
ＴＴ）に基づいて、再送要求に基づく再送データパケッ
ト受信が、再送データパケット格納データの再生処理開
始時間前に可能か否かを判定する構成を有することを特
徴とする請求項１５に記載のデータ受信装置。 - 【請求項２３】前記データ受信装置は、 再送要求データパケットの識別データとしてのシーケン
ス番号、またはパケットの属するタイムスタンプ指定デ
ータの少なくともいずれかと、再送要求範囲を指定する
オプションを格納した再送要求メッセージパケットを生
成して前記データ送信装置に送信する構成を有すること
を特徴とする請求項１５に記載のデータ受信装置。 - 【請求項２４】前記データパケットは、データ転送プロ
トコルとしてのＲＴＰに従ったフォーマットを有し、前
記再送要求は、制御プロトコルとしてのＲＴＣＰに従っ
たフォーマットを有することを特徴とする請求項１５に
記載のデータ受信装置。 - 【請求項２５】前記データ受信装置は、 複数のデータパケットに関する再送要求を１つの再送要
求メッセージパケットとしてデータ送信装置に対して送
信する構成であることを特徴とする請求項１５に記載の
データ受信装置。 - 【請求項２６】前記データ受信装置は、 複数のデータパケットに関する受信確認を１つの受信確
認メッセージパケットとしてデータ送信装置に対して送
信する構成であることを特徴とする請求項１５に記載の
データ受信装置。 - 【請求項２７】データ送信装置およびデータ受信装置か
らなり、ストリーム型データ転送を実行するデータ通信
方法であり、 データ送信装置において、 送信データを格納したデータパケットを送信するパケッ
ト送信処理ステップと、 データ受信装置から受信する再送要求メッセージパケッ
トに従って再送すべきデータパケットの抽出処理を実行
する再送制御処理ステップとを有し、 データ受信装置は、 前記データ送信装置から受信するデータパケットを受信
するパケット受信処理ステップと、 前記データ送信装置から受信するデータパケットのエラ
ーまたはロスト・データパケットの検出に基づいて、前
記データ送信装置に対するデータパケット再送要求とし
ての再送要求メッセージパケットの送信可否を判定する
再送要求処理制御ステップとを有し、 前記再送要求処理制御ステップは、 再送要求に基づく再送データパケット受信が、再送デー
タパケット格納データの再生に伴う処理開始時間前に可
能か否かを判定し、可能であるとの判定を条件として、
再送要求送信を決定することを特徴とするデータ通信方
法。 - 【請求項２８】前記データ・パケットの格納データは、
符号化データであり、 前記データ受信装置における前記再送要求処理制御ステ
ップは、 再送要求に基づく再送データパケット受信が、再送デー
タパケット格納データの復号処理を含む再生に伴う処理
開始時間前に可能か否かを判定するステップを含むこと
を特徴とする請求項２７に記載のデータ通信方法。 - 【請求項２９】前記再送要求は、再送要求データパケッ
トの識別データとしてのシーケンス番号と、該シーケン
ス番号に対応するデータパケットの重複再送の指定回数
データを格納したメッセージパケットによって構成さ
れ、 前記データ送信装置は、 再送要求メッセージパケットに指定された重複再送の指
定回数データに従って、指定シーケンス番号のデータパ
ケットの重複送信を実行することを特徴とする請求項２
７に記載のデータ通信方法。 - 【請求項３０】前記データ送信装置とデータ受信装置間
で転送されるデータパケットは、動画像データであり、 前記データ受信装置における前記再送要求処理制御ステ
ップは、 動画像データの１画像フレームの構成データを格納した
複数のデータパケットの終端データパケットの受信に応
じて、該終端データパケットの属する画像フレームの構
成データを格納した複数のデータパケット中のエラーま
たはロスト・データパケットの検出処理を実行するステ
ップを含むことを特徴とする請求項２７に記載のデータ
通信方法。 - 【請求項３１】前記データ送信装置とデータ受信装置間
で転送されるデータパケットは、動画像データであり、 前記データ受信装置における前記再送要求処理制御ステ
ップは、 動画像データの１画像フレームの構成データを格納した
複数のデータパケットの先頭データパケットの受信に応
じて、該先頭データパケットの属する画像フレームの前
フレームの構成データを格納した複数のデータパケット
中のエラーまたはロスト・データパケットの検出処理を
実行するステップを含むことを特徴とする請求項２７に
記載のデータ通信方法。 - 【請求項３２】前記データ受信装置における前記再送要
求処理制御ステップは、 データパケット格納データの再生処理開始時間に間に合
うための再送要求最終期限に基づいて、受信データパケ
ット中のエラーまたはロスト・データパケットの検出処
理を実行するステップを含むことを特徴とする請求項２
７に記載のデータ通信方法。 - 【請求項３３】前記データ受信装置における前記再送要
求処理制御ステップは、 定期的な時間間隔に基づいて、受信データパケット中の
エラーまたはロスト・データパケットの検出処理を実行
するステップを含むことを特徴とする請求項２７に記載
のデータ通信方法。 - 【請求項３４】前記データ受信装置は、さらに、 前記データ送信装置とデータ受信装置における往復伝播
遅延（ＲＴＴ）の計測処理のために前記データ送信装置
に対するエコーパケットの送信および該エコーパケット
に対するエコーリプライパケットの受信処理制御ステッ
プを実行し、 前記再送要求処理制御ステップは、 該エコーパケットに基づいて算出する往復伝播遅延（Ｒ
ＴＴ）に基づいて、再送要求に基づく再送データパケッ
ト受信が、再送データパケット格納データの再生処理開
始時間前に可能か否かを判定するステップを含むことを
特徴とする請求項２７に記載のデータ通信方法。 - 【請求項３５】前記データ受信装置の生成する再送要求
メッセージパケットは、 データパケットを指定するシーケンス番号指定データ、
またはパケットの属するタイムスタンプ指定データの少
なくともいずれかと、再送要求範囲を指定するオプショ
ン値によって構成され、 前記データ送信装置の再送制御ステップは、 前記データ受信装置から受信する再送要求メッセージパ
ケットに格納されたデータパケットを指定するシーケン
ス番号指定データ、またはパケットの属するタイムスタ
ンプ指定データの少なくともいずれか、およびオプショ
ン値に基づいて１以上の再送パケットの抽出処理を実行
することを特徴とする請求項２７に記載のデータ通信方
法。 - 【請求項３６】前記データパケットは、データ転送プロ
トコルとしてのＲＴＰに従ったフォーマットを有し、前
記再送要求は、制御プロトコルとしてのＲＴＣＰに従っ
たフォーマットを有することを特徴とする請求項２７に
記載のデータ通信方法。 - 【請求項３７】前記データ受信装置は、さらに、 複数のデータパケットに関する再送要求を１つの再送要
求メッセージパケットとしてデータ送信装置に対して送
信するステップを実行することを特徴とする請求項２７
に記載のデータ通信方法。 - 【請求項３８】前記データ受信装置は、さらに、 複数のデータパケットに関する受信確認を１つの受信確
認メッセージパケットとしてデータ送信装置に対して送
信するステップを実行することを特徴とする請求項２７
に記載のデータ通信方法。 - 【請求項３９】ストリーム型データ受信処理を実行する
コンピュータ・プログラムであって、 データ送信装置から受信するデータパケットを受信する
パケット受信処理ステップと、 前記データ送信装置から受信するデータパケットのエラ
ーまたはロスト・データパケットの検出に基づいて、前
記データ送信装置に対するデータパケット再送要求とし
ての再送要求メッセージパケットの送信可否を判定する
再送要求処理制御ステップとを有し、 前記再送要求処理制御ステップは、 再送要求に基づく再送データパケット受信が、再送デー
タパケット格納データの再生に伴う処理開始時間前に可
能か否かを判定し、可能であるとの判定を条件として、
再送要求送信を決定するステップを含むことを特徴とす
るコンピュータ・プログラム。
Priority Applications (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2001369731A JP3912091B2 (ja) | 2001-12-04 | 2001-12-04 | データ通信システム、データ送信装置、データ受信装置、および方法、並びにコンピュータ・プログラム |
| KR20020076260A KR100967377B1 (ko) | 2001-12-04 | 2002-12-03 | 데이터 통신 시스템, 데이터 송신 장치, 데이터 수신 장치, 데이터 통신 방법, 및 컴퓨터 프로그램을 기록한 매체 |
| US10/310,212 US7315898B2 (en) | 2001-12-04 | 2002-12-04 | Data communication system, data transmission apparatus, data reception apparatus, data communication method, and computer program |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2001369731A JP3912091B2 (ja) | 2001-12-04 | 2001-12-04 | データ通信システム、データ送信装置、データ受信装置、および方法、並びにコンピュータ・プログラム |
Publications (3)
| Publication Number | Publication Date |
|---|---|
| JP2003169040A true JP2003169040A (ja) | 2003-06-13 |
| JP2003169040A5 JP2003169040A5 (ja) | 2005-03-17 |
| JP3912091B2 JP3912091B2 (ja) | 2007-05-09 |
Family
ID=19179073
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2001369731A Expired - Lifetime JP3912091B2 (ja) | 2001-12-04 | 2001-12-04 | データ通信システム、データ送信装置、データ受信装置、および方法、並びにコンピュータ・プログラム |
Country Status (3)
| Country | Link |
|---|---|
| US (1) | US7315898B2 (ja) |
| JP (1) | JP3912091B2 (ja) |
| KR (1) | KR100967377B1 (ja) |
Cited By (24)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2003244695A (ja) * | 2002-02-14 | 2003-08-29 | Kddi Corp | 映像情報伝送方式、それに用いられる装置およびプログラム |
| JP2005006340A (ja) * | 2003-06-13 | 2005-01-06 | Microsoft Corp | ネットワーク通信のための時間指向、ベストエフォート的、穴埋め型再試行方法およびシステム |
| JP2005198055A (ja) * | 2004-01-08 | 2005-07-21 | Sony Corp | 受信装置および方法、プログラム、並びに記録媒体 |
| JP2005303927A (ja) * | 2004-04-15 | 2005-10-27 | Sony Corp | 情報処理システム、情報処理装置および方法、記録媒体、並びにプログラム |
| JP2006319423A (ja) * | 2005-05-10 | 2006-11-24 | Toshiba Corp | 送信機及び受信機 |
| JP2007019705A (ja) * | 2005-07-06 | 2007-01-25 | Sony Corp | 通信システム、送信装置、送信方法、およびプログラム |
| JP2007053745A (ja) * | 2005-07-22 | 2007-03-01 | Sanyo Electric Co Ltd | 受信機及びプログラム |
| JP2007325077A (ja) * | 2006-06-02 | 2007-12-13 | Mitsubishi Electric Corp | データ受信装置及びデータ受信方法 |
| JP2008079334A (ja) * | 2004-09-21 | 2008-04-03 | Hitachi Communication Technologies Ltd | ノード装置、パケット制御装置、無線通信装置および送信制御方法 |
| JP2008079150A (ja) * | 2006-09-22 | 2008-04-03 | Canon Inc | 通信機器及びデータ転送方法 |
| WO2008041329A1 (en) * | 2006-10-04 | 2008-04-10 | Fujitsu Limited | Data transfer method |
| JP2009027740A (ja) * | 2008-09-09 | 2009-02-05 | Ntt Docomo Inc | 移動通信システム、移動端末及びネットワーク側対向装置 |
| US7539174B2 (en) | 2004-03-09 | 2009-05-26 | Ntt Docomo, Inc. | Mobile communication system, mobile station device, and network-side device |
| JP2011015214A (ja) * | 2009-07-02 | 2011-01-20 | Canon Inc | 送信装置、送信方法、及びコンピュータプログラム |
| WO2011086952A1 (ja) * | 2010-01-14 | 2011-07-21 | 住友電気工業株式会社 | 動画像符号化データの表示方法、装置及び通信システム |
| JP2011259183A (ja) * | 2010-06-09 | 2011-12-22 | Nippon Telegr & Teleph Corp <Ntt> | データ配信システムおよびデータ配信方法 |
| JP2012170010A (ja) * | 2011-02-16 | 2012-09-06 | Fujitsu Ltd | 通信方法、通信プログラム、および、通信装置 |
| WO2013011545A1 (ja) * | 2011-07-15 | 2013-01-24 | 三菱電機株式会社 | 送信装置、受信装置、通信装置、通信システムおよび送信方法 |
| JP2014039136A (ja) * | 2012-08-15 | 2014-02-27 | Nippon Hoso Kyokai <Nhk> | 無線通信を行う送信装置、受信装置、送信方法、受信方法及びプログラム |
| US8731069B2 (en) | 2005-08-25 | 2014-05-20 | Canon Kabushiki Kaisha | Remote display system and method |
| JP2015080198A (ja) * | 2013-09-11 | 2015-04-23 | パナソニックＩｐマネジメント株式会社 | 通信制御装置および通信制御方法 |
| JP2016541210A (ja) * | 2013-09-26 | 2016-12-28 | コーヒレント・ロジックス・インコーポレーテッド | 次世代放送システム及び方法 |
| WO2020174994A1 (ja) | 2019-02-26 | 2020-09-03 | パナソニックＩｐマネジメント株式会社 | カメラ映像伝送再生システム、それを構成するカメラおよびビューア |
| JP2022093387A (ja) * | 2019-03-15 | 2022-06-23 | オムロン株式会社 | 制御システム、装置および制御方法 |
Families Citing this family (138)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7576770B2 (en) * | 2003-02-11 | 2009-08-18 | Raymond Metzger | System for a plurality of video cameras disposed on a common network |
| US7698450B2 (en) | 2000-11-17 | 2010-04-13 | Monroe David A | Method and apparatus for distributing digitized streaming video over a network |
| US6996624B1 (en) * | 2001-09-27 | 2006-02-07 | Apple Computer, Inc. | Reliable real-time transport protocol |
| KR100460970B1 (ko) * | 2002-01-10 | 2004-12-09 | 삼성전자주식회사 | 데이터 송수신 시스템 및 방법 |
| US7542471B2 (en) | 2002-10-30 | 2009-06-02 | Citrix Systems, Inc. | Method of determining path maximum transmission unit |
| US7616638B2 (en) | 2003-07-29 | 2009-11-10 | Orbital Data Corporation | Wavefront detection and disambiguation of acknowledgments |
| US8233392B2 (en) * | 2003-07-29 | 2012-07-31 | Citrix Systems, Inc. | Transaction boundary detection for reduction in timeout penalties |
| US8270423B2 (en) | 2003-07-29 | 2012-09-18 | Citrix Systems, Inc. | Systems and methods of using packet boundaries for reduction in timeout prevention |
| US7630305B2 (en) | 2003-07-29 | 2009-12-08 | Orbital Data Corporation | TCP selective acknowledgements for communicating delivered and missed data packets |
| US7689709B2 (en) * | 2002-12-13 | 2010-03-30 | Sap Ag | Native format tunneling |
| JP2004289711A (ja) * | 2003-03-25 | 2004-10-14 | Toshiba Corp | 送信装置及び受信装置 |
| JP3825416B2 (ja) * | 2003-04-14 | 2006-09-27 | 国立大学法人北陸先端科学技術大学院大学 | データ同期方法、データ同期システム及びデータ同期プログラム |
| CN1276672C (zh) * | 2003-05-16 | 2006-09-20 | 株式会社Ntt都科摩 | 分组通讯系统、基站和移动站 |
| US8798015B2 (en) * | 2003-07-11 | 2014-08-05 | Koninklijke Philips N.V. | Transmission of data packets from a transmitter to a receiver |
| US8432800B2 (en) | 2003-07-29 | 2013-04-30 | Citrix Systems, Inc. | Systems and methods for stochastic-based quality of service |
| US7656799B2 (en) | 2003-07-29 | 2010-02-02 | Citrix Systems, Inc. | Flow control system architecture |
| US7698453B2 (en) * | 2003-07-29 | 2010-04-13 | Oribital Data Corporation | Early generation of acknowledgements for flow control |
| US8437284B2 (en) | 2003-07-29 | 2013-05-07 | Citrix Systems, Inc. | Systems and methods for additional retransmissions of dropped packets |
| US8238241B2 (en) | 2003-07-29 | 2012-08-07 | Citrix Systems, Inc. | Automatic detection and window virtualization for flow control |
| US7417989B1 (en) * | 2003-07-29 | 2008-08-26 | Sprint Spectrum L.P. | Method and system for actually identifying a media source in a real-time-protocol stream |
| EP1667395A4 (en) * | 2003-09-18 | 2010-05-26 | Nomura Res Inst Co Ltd | COMMUNICATION SYSTEM, COMMUNICATION DEVICE AND DATA TRANSFER CONTROL METHOD |
| US8104065B2 (en) * | 2003-11-13 | 2012-01-24 | Arris Group, Inc. | System to provide markers to affect rendering and navigation of content on demand |
| US20070097987A1 (en) * | 2003-11-24 | 2007-05-03 | Rey Jose L | Feedback provision using general nack report blocks and loss rle report blocks |
| WO2005086520A1 (ja) | 2004-03-09 | 2005-09-15 | Matsushita Electric Industrial Co., Ltd. | ランダムアクセス方法及び無線通信端末装置 |
| US8359349B2 (en) * | 2004-03-18 | 2013-01-22 | Nokia Corporation | System and associated terminal, method and computer program product for uploading content |
| US8296436B2 (en) * | 2004-03-22 | 2012-10-23 | Nokia Corporation | Conveying parameters for broadcast/multicast sessions via a communication protocol |
| US7839844B2 (en) * | 2004-07-30 | 2010-11-23 | Sony Corporation | System and method for dynamically determining retransmit buffer time |
| US7643503B2 (en) * | 2004-07-30 | 2010-01-05 | Sony Corporation | System and method for dynamically determining retransmit buffer time |
| US7702750B2 (en) | 2004-09-29 | 2010-04-20 | Citrix Systems, Inc. | System and method for event detection and re-direction over a network using a presentation level protocol |
| US8069226B2 (en) | 2004-09-30 | 2011-11-29 | Citrix Systems, Inc. | System and method for data synchronization over a network using a presentation level protocol |
| US8130633B2 (en) * | 2004-10-22 | 2012-03-06 | Research In Motion Limited | Method for transferring data in a wireless network |
| US7522528B2 (en) * | 2004-11-18 | 2009-04-21 | Qvidium Technologies, Inc. | Low-latency automatic repeat request packet recovery mechanism for media streams |
| US7675872B2 (en) | 2004-11-30 | 2010-03-09 | Broadcom Corporation | System, method, and apparatus for displaying pictures |
| US8634413B2 (en) * | 2004-12-30 | 2014-01-21 | Microsoft Corporation | Use of frame caching to improve packet loss recovery |
| US8169908B1 (en) * | 2005-01-29 | 2012-05-01 | Lsi Corporation | Method for discarding corrupted data packets in a reliable transport fabric |
| JP2006211602A (ja) * | 2005-01-31 | 2006-08-10 | Toshiba Corp | データ送信機及びプログラム |
| JP2006245834A (ja) * | 2005-03-02 | 2006-09-14 | Nec Corp | Ｉｐ網の通信装置 |
| US7752532B2 (en) * | 2005-03-10 | 2010-07-06 | Qualcomm Incorporated | Methods and apparatus for providing linear erasure codes |
| CN1845611A (zh) * | 2005-04-08 | 2006-10-11 | 华为技术有限公司 | 基于h.264的视频传输保护方法 |
| US7957363B2 (en) * | 2005-05-26 | 2011-06-07 | International Business Machines Corporation | System, method, and service for dynamically selecting an optimum message pathway |
| US20060291452A1 (en) * | 2005-06-24 | 2006-12-28 | Motorola, Inc. | Method and apparatus for providing reliable communications over an unreliable communications channel |
| US20070061831A1 (en) * | 2005-09-09 | 2007-03-15 | Sbc Knowledge Ventures L.P. | IPTV channel usage and video delivery path monitoring architecture |
| TWI277325B (en) * | 2005-10-28 | 2007-03-21 | Ind Tech Res Inst | Packet transmitting method of wireless network |
| US7743152B2 (en) * | 2005-10-31 | 2010-06-22 | Qualcomm Incorporated | Method and apparatus for detecting the presence of a terminal in a data session |
| US8363675B2 (en) * | 2006-03-24 | 2013-01-29 | Samsung Electronics Co., Ltd. | Method and system for transmission of uncompressed video over wireless communication channels |
| US20070234170A1 (en) * | 2006-03-29 | 2007-10-04 | Samsung Electronics Co., Ltd. | Method and system for communication of video information over wireless channels |
| US8432938B2 (en) * | 2006-03-29 | 2013-04-30 | Samsung Electronics Co., Ltd. | Method and system for video stream transmission over wireless channels |
| JP4798495B2 (ja) * | 2006-05-30 | 2011-10-19 | 日本電気株式会社 | 映像配信品質測定システム、装置および方法 |
| JP4930691B2 (ja) * | 2006-05-30 | 2012-05-16 | 日本電気株式会社 | 再現システム、再現装置、再現方法、及びプログラム |
| US20070280217A1 (en) * | 2006-06-01 | 2007-12-06 | Texas Instruments Incorporated | Inter-nodal robust mode for real-time media streams in a network |
| JP4509068B2 (ja) * | 2006-07-24 | 2010-07-21 | 富士通株式会社 | パケット処理装置 |
| JP4921064B2 (ja) * | 2006-07-31 | 2012-04-18 | キヤノン株式会社 | 通信装置、通信方法、通信装置を制御するためのプログラム及びプログラムを格納した記憶媒体 |
| JP2008040347A (ja) * | 2006-08-09 | 2008-02-21 | Toshiba Corp | 画像表示装置、画像表示方法および画像表示プログラム |
| US8799918B2 (en) * | 2006-09-11 | 2014-08-05 | Microsoft Corporation | Dynamic network load balancing using roundtrip heuristic |
| JP4176122B2 (ja) * | 2006-10-24 | 2008-11-05 | 株式会社東芝 | サーバ端末、画面共有方法およびプログラム |
| FR2911234B1 (fr) * | 2007-01-05 | 2009-02-20 | Thales Sa | Procede d'envoi de paquets de donnees d'un serveur vers un client, le client utilisant simultanement a un debit constant d les donnees qu'il recoit |
| KR100920516B1 (ko) | 2007-01-10 | 2009-10-09 | 한국전자통신연구원 | 데이터 전송 장치 및 방법 |
| KR100859499B1 (ko) * | 2007-01-15 | 2008-09-22 | 강릉대학교산학협력단 | 데이터 송수신 방법 및 그에 따른 통신 시스템 |
| US8296662B2 (en) * | 2007-02-05 | 2012-10-23 | Brother Kogyo Kabushiki Kaisha | Image display device |
| US8170023B2 (en) * | 2007-02-20 | 2012-05-01 | Broadcom Corporation | System and method for a software-based TCP/IP offload engine for implementing efficient digital media streaming over internet protocol networks |
| US8139487B2 (en) * | 2007-02-28 | 2012-03-20 | Microsoft Corporation | Strategies for selecting a format for data transmission based on measured bandwidth |
| US7877514B2 (en) * | 2007-05-03 | 2011-01-25 | Samsung Electronics Co., Ltd. | System and method for time-constrained transmission of video in a communication system |
| EP2026580A1 (en) * | 2007-06-12 | 2009-02-18 | British Telecommunications public limited company | Video processing |
| US7908624B2 (en) * | 2007-06-18 | 2011-03-15 | Broadcom Corporation | System and method for just in time streaming of digital programs for network recording and relaying over internet protocol network |
| US7782851B2 (en) * | 2007-06-26 | 2010-08-24 | At&T Intellectual Property I, L.P. | System and method of detecting lost video data packets |
| JP4983435B2 (ja) * | 2007-06-27 | 2012-07-25 | 富士通株式会社 | パケット通信品質計測装置及び方法 |
| KR100862971B1 (ko) * | 2007-07-26 | 2008-10-13 | 강릉대학교산학협력단 | 무선 센서 네트워크의 노드들에 대한 펌웨어 업데이트 방법 |
| JP4447028B2 (ja) * | 2007-08-10 | 2010-04-07 | 富士通株式会社 | 通信制御方法、送信装置、およびコンピュータプログラム |
| US7969921B2 (en) * | 2007-08-29 | 2011-06-28 | Samsung Electronics Co., Ltd. | Method and system for data packet communication in wireless communication systems |
| ATE554584T1 (de) * | 2007-10-19 | 2012-05-15 | Voxer Ip Llc | Verfahren und vorrichtung zur echtzeitmediensynchronisierung über einem netzwerk |
| US8782274B2 (en) * | 2007-10-19 | 2014-07-15 | Voxer Ip Llc | Method and system for progressively transmitting a voice message from sender to recipients across a distributed services communication network |
| US8699383B2 (en) * | 2007-10-19 | 2014-04-15 | Voxer Ip Llc | Method and apparatus for real-time synchronization of voice communications |
| US8250181B2 (en) * | 2007-10-19 | 2012-08-21 | Voxer Ip Llc | Method and apparatus for near real-time synchronization of voice communications |
| US8099512B2 (en) * | 2007-10-19 | 2012-01-17 | Voxer Ip Llc | Method and system for real-time synchronization across a distributed services communication network |
| US8559319B2 (en) * | 2007-10-19 | 2013-10-15 | Voxer Ip Llc | Method and system for real-time synchronization across a distributed services communication network |
| US8205126B2 (en) * | 2007-11-27 | 2012-06-19 | Samsung Electronics Co., Ltd. | System and method for wireless communication of uncompressed video using selective retransmission |
| US8255753B2 (en) * | 2007-12-04 | 2012-08-28 | Intel Corporation | Encoding/decoding technique for rebroadcasting lost packets |
| KR20090061247A (ko) * | 2007-12-11 | 2009-06-16 | 삼성전자주식회사 | 디지털 방송 수신 장치의 ｏｓｄ 인터페이스 |
| US9112632B2 (en) * | 2008-01-25 | 2015-08-18 | Cisco Technology, Inc. | Supporting efficient and accurate sync/followup timestamps |
| JP5632834B2 (ja) | 2008-06-23 | 2014-11-26 | コーニンクレッカ フィリップス エヌ ヴェ | ネットワークで通信するための方法及び関連する無線局 |
| EP2151940A1 (en) * | 2008-08-05 | 2010-02-10 | Nokia Siemens Networks OY | Communication network element and method transmitting data |
| EP2314011B1 (en) | 2008-08-11 | 2016-06-22 | Koninklijke Philips N.V. | Method for communicating in a network, a secondary station and a system therefor |
| KR100998830B1 (ko) | 2008-08-27 | 2010-12-06 | 주식회사 엘지유플러스 | 무선 네트워크에서의 유디피를 이용한 데이터 전송 시스템및 그 방법 |
| CA2735728A1 (en) * | 2008-08-28 | 2010-03-04 | Sumitomo Electric Industries, Ltd. | Moving-picture image data-distribution method |
| JP5207895B2 (ja) * | 2008-09-17 | 2013-06-12 | キヤノン株式会社 | 送信装置、受信装置、及び方法、プログラム |
| KR101048865B1 (ko) | 2009-03-16 | 2011-07-13 | 주식회사 팬택 | 전송계층 성능 향상을 위한 전송계층 제어장치 및 전송속도와 신뢰성을 동시에 보장할 수 있는 패킷 송신 방법 |
| AU2010232634B2 (en) * | 2009-04-01 | 2015-06-04 | Qualcomm Incorporated | Managing transmissions among nodes communicating over a shared communication medium |
| JP5332854B2 (ja) * | 2009-04-20 | 2013-11-06 | ソニー株式会社 | 無線送信機、無線送信方法、無線受信機および無線受信方法 |
| JP5508819B2 (ja) * | 2009-11-13 | 2014-06-04 | オリンパス株式会社 | 受信装置 |
| US8661166B2 (en) * | 2009-12-16 | 2014-02-25 | Intel Corporation | DFX software debug feature for IO and other non-memory typed transactions |
| WO2011104847A1 (ja) * | 2010-02-25 | 2011-09-01 | 三菱電機株式会社 | 通信装置およびアドレス学習方法 |
| EP2375614B1 (en) * | 2010-04-09 | 2014-05-07 | Alcatel Lucent | Method for broadcasting multimedia content |
| JP5696854B2 (ja) * | 2010-05-19 | 2015-04-08 | 日本電気株式会社 | パケット再送制御装置とパケット再送制御方法 |
| JP5465106B2 (ja) * | 2010-06-21 | 2014-04-09 | オリンパス株式会社 | 表示装置及び表示システム |
| US20110321015A1 (en) * | 2010-06-23 | 2011-12-29 | Yen Hsiang Chew | Hardware triggering mechanism for software debugger |
| US9372719B2 (en) * | 2010-11-05 | 2016-06-21 | Nec Corporation | Information processing device for correcting procedure |
| US9461777B2 (en) * | 2011-11-21 | 2016-10-04 | Qualcomm Incorporated | Hybrid networking system with seamless path switching of streams |
| WO2013100783A1 (en) | 2011-12-29 | 2013-07-04 | Intel Corporation | Method and system for control signalling in a data path module |
| IL217306A (en) * | 2012-01-01 | 2016-05-31 | Video Flow Ltd | Package recovery system and method |
| JP5722264B2 (ja) * | 2012-03-23 | 2015-05-20 | 株式会社日立ハイテクノロジーズ | データ処理装置、データ容量増加抑制方法 |
| US20140073352A1 (en) * | 2012-09-11 | 2014-03-13 | Qualcomm Incorporated | Method for precise location determination |
| KR102022042B1 (ko) * | 2012-09-28 | 2019-09-18 | 삼성전자주식회사 | 데이터 전송 방법 및 시스템 |
| WO2014083739A1 (ja) * | 2012-11-28 | 2014-06-05 | パナソニック株式会社 | 受信端末および受信方法 |
| US9722943B2 (en) | 2012-12-17 | 2017-08-01 | Qualcomm Incorporated | Seamless switching for multihop hybrid networks |
| CN103152223B (zh) * | 2013-03-15 | 2016-08-03 | 华为技术有限公司 | 网络性能监测方法及装置 |
| US9990246B2 (en) * | 2013-03-15 | 2018-06-05 | Intel Corporation | Memory system |
| JP2014195158A (ja) * | 2013-03-28 | 2014-10-09 | Canon Inc | 通信装置と、当該通信装置を含む通信システム、及びその制御方法とプログラム |
| KR102025757B1 (ko) * | 2013-07-10 | 2019-09-27 | 삼성전자주식회사 | 데이터 전송 방법 및 장치, 데이터 수신 방법 및 장치 및 기록 매체 |
| KR102171117B1 (ko) * | 2013-08-30 | 2020-10-29 | 삼성전자주식회사 | 패킷 송수신 방법 및 그에 따른 단말, 그에 따른 시스템 |
| US10331583B2 (en) | 2013-09-26 | 2019-06-25 | Intel Corporation | Executing distributed memory operations using processing elements connected by distributed channels |
| US9747048B2 (en) | 2014-06-02 | 2017-08-29 | Micron Technology, Inc. | Systems and methods for packing data in a scalable memory system protocol |
| US9787852B2 (en) * | 2014-06-04 | 2017-10-10 | Alcatel-Lucent Usa Inc. | Sequence number reuse for CDR transport using GTP' |
| US10834065B1 (en) | 2015-03-31 | 2020-11-10 | F5 Networks, Inc. | Methods for SSL protected NTLM re-authentication and devices thereof |
| CN105072485B (zh) * | 2015-08-26 | 2018-11-13 | 小米科技有限责任公司 | 时延控制方法及装置 |
| US10404698B1 (en) | 2016-01-15 | 2019-09-03 | F5 Networks, Inc. | Methods for adaptive organization of web application access points in webtops and devices thereof |
| US10148964B2 (en) * | 2016-11-03 | 2018-12-04 | Ujet, Inc. | Image quality management |
| US10558575B2 (en) | 2016-12-30 | 2020-02-11 | Intel Corporation | Processors, methods, and systems with a configurable spatial accelerator |
| US10515046B2 (en) | 2017-07-01 | 2019-12-24 | Intel Corporation | Processors, methods, and systems with a configurable spatial accelerator |
| US10515049B1 (en) | 2017-07-01 | 2019-12-24 | Intel Corporation | Memory circuits and methods for distributed memory hazard detection and error recovery |
| US10496574B2 (en) | 2017-09-28 | 2019-12-03 | Intel Corporation | Processors, methods, and systems for a memory fence in a configurable spatial accelerator |
| US11086816B2 (en) | 2017-09-28 | 2021-08-10 | Intel Corporation | Processors, methods, and systems for debugging a configurable spatial accelerator |
| US20190104169A1 (en) * | 2017-10-03 | 2019-04-04 | Synology Inc. | Methods and computer program products for transceiving files through networks and apparatuses using the same |
| US10565134B2 (en) * | 2017-12-30 | 2020-02-18 | Intel Corporation | Apparatus, methods, and systems for multicast in a configurable spatial accelerator |
| US10564980B2 (en) | 2018-04-03 | 2020-02-18 | Intel Corporation | Apparatus, methods, and systems for conditional queues in a configurable spatial accelerator |
| US11307873B2 (en) | 2018-04-03 | 2022-04-19 | Intel Corporation | Apparatus, methods, and systems for unstructured data flow in a configurable spatial accelerator with predicate propagation and merging |
| US10891240B2 (en) | 2018-06-30 | 2021-01-12 | Intel Corporation | Apparatus, methods, and systems for low latency communication in a configurable spatial accelerator |
| US10853073B2 (en) | 2018-06-30 | 2020-12-01 | Intel Corporation | Apparatuses, methods, and systems for conditional operations in a configurable spatial accelerator |
| US11200186B2 (en) | 2018-06-30 | 2021-12-14 | Intel Corporation | Apparatuses, methods, and systems for operations in a configurable spatial accelerator |
| US10678724B1 (en) | 2018-12-29 | 2020-06-09 | Intel Corporation | Apparatuses, methods, and systems for in-network storage in a configurable spatial accelerator |
| US10817291B2 (en) | 2019-03-30 | 2020-10-27 | Intel Corporation | Apparatuses, methods, and systems for swizzle operations in a configurable spatial accelerator |
| US10965536B2 (en) | 2019-03-30 | 2021-03-30 | Intel Corporation | Methods and apparatus to insert buffers in a dataflow graph |
| US10915471B2 (en) | 2019-03-30 | 2021-02-09 | Intel Corporation | Apparatuses, methods, and systems for memory interface circuit allocation in a configurable spatial accelerator |
| US11029927B2 (en) | 2019-03-30 | 2021-06-08 | Intel Corporation | Methods and apparatus to detect and annotate backedges in a dataflow graph |
| US11037050B2 (en) | 2019-06-29 | 2021-06-15 | Intel Corporation | Apparatuses, methods, and systems for memory interface circuit arbitration in a configurable spatial accelerator |
| CN110730053A (zh) * | 2019-09-09 | 2020-01-24 | 晶晨半导体（深圳）有限公司 | 一种基于ts格式和udp传输方式的网络丢包重传方法 |
| US11907713B2 (en) | 2019-12-28 | 2024-02-20 | Intel Corporation | Apparatuses, methods, and systems for fused operations using sign modification in a processing element of a configurable spatial accelerator |
| CN114095796A (zh) * | 2020-07-30 | 2022-02-25 | 中国移动通信集团终端有限公司 | 无效重传包减少方法、装置、设备及计算机存储介质 |
| US20240048277A1 (en) * | 2022-08-03 | 2024-02-08 | Google Llc | Early Retransmission for Hardware Reliable Transport |
Citations (16)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH04170239A (ja) * | 1990-11-02 | 1992-06-17 | Nec Corp | データ伝送受信装置 |
| JPH05160811A (ja) * | 1991-12-06 | 1993-06-25 | Hitachi Ltd | データ転送方式 |
| JPH07202856A (ja) * | 1993-11-30 | 1995-08-04 | At & T Corp | パケット再送信装置 |
| JPH07283757A (ja) * | 1994-04-14 | 1995-10-27 | Matsushita Electric Ind Co Ltd | 音声データ通信装置 |
| JPH07283782A (ja) * | 1994-04-08 | 1995-10-27 | Matsushita Electric Ind Co Ltd | 移動通信システム |
| JPH09191314A (ja) * | 1996-01-10 | 1997-07-22 | Mitsubishi Electric Corp | 連続データ伝送方法および連続データ伝送装置 |
| JPH09247132A (ja) * | 1996-03-08 | 1997-09-19 | Yazaki Corp | 無線パケット通信装置及び送信装置 |
| JPH10200897A (ja) * | 1997-01-08 | 1998-07-31 | Nippon Telegr & Teleph Corp <Ntt> | 動画像伝送装置 |
| JPH1132077A (ja) * | 1997-07-10 | 1999-02-02 | Mitsubishi Electric Corp | 送信制御装置、受信制御装置、通信制御システム及び通信制御方法 |
| JPH11262054A (ja) * | 1998-03-13 | 1999-09-24 | Toshiba Corp | 無線通信システム及び加入者用無線機 |
| JPH11331839A (ja) * | 1998-05-13 | 1999-11-30 | Matsushita Electric Ind Co Ltd | 映像伝送再送の装置及び方法 |
| JP2001111618A (ja) * | 1999-10-08 | 2001-04-20 | Nippon Telegr & Teleph Corp <Ntt> | 通信システムとその通信方法、ならびにそのプログラムを記録した媒体 |
| JP2001119437A (ja) * | 1998-11-30 | 2001-04-27 | Matsushita Electric Ind Co Ltd | データ伝送方法，データ送信装置，データ受信装置，及びパケットデータ構造 |
| JP2001218276A (ja) * | 2000-02-04 | 2001-08-10 | Ntt Docomo Inc | 移動通信システムにおけるデータ通信方法及び装置 |
| JP2001298407A (ja) * | 2000-04-13 | 2001-10-26 | Ntt Docomo Inc | マルチキャストサービス提供システムにおける再送制御方法、情報配信装置及び無線端末 |
| JP2003515289A (ja) * | 1999-11-15 | 2003-04-22 | コーニンクレッカ フィリップス エレクトロニクス エヌ ヴィ | ストリーミングデータ受信器における復号器バッファの遅延割当量を制御するためのシステムと方法 |
Family Cites Families (13)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH06237451A (ja) * | 1993-02-10 | 1994-08-23 | Hitachi Ltd | 動画通信方式および端末装置 |
| KR0156856B1 (ko) * | 1995-12-30 | 1998-11-16 | 김광호 | 다중 메세지 재전송 처리장치 및 방법 |
| DE69736684T2 (de) * | 1996-01-23 | 2007-09-13 | Ntt Mobile Communications Network Inc. | Kommunikationsanordnung und Übertragungsstation mit Fehlerdetektion und Wiederübertragung |
| US5768527A (en) * | 1996-04-23 | 1998-06-16 | Motorola, Inc. | Device, system and method of real-time multimedia streaming |
| US5918002A (en) * | 1997-03-14 | 1999-06-29 | Microsoft Corporation | Selective retransmission for efficient and reliable streaming of multimedia packets in a computer network |
| US6275471B1 (en) * | 1998-05-12 | 2001-08-14 | Panasonic Technologies, Inc. | Method for reliable real-time multimedia streaming |
| US6507582B1 (en) * | 1999-05-27 | 2003-01-14 | Qualcomm Incorporated | Radio link protocol enhancements for dynamic capacity wireless data channels |
| JP3391316B2 (ja) * | 1999-10-22 | 2003-03-31 | 日本電気株式会社 | ネットワークシステム |
| US20020095636A1 (en) * | 2000-11-06 | 2002-07-18 | Hidenori Tatsumi | Transmitter, receiver and broadcast data delivering method |
| US6907460B2 (en) * | 2001-01-18 | 2005-06-14 | Koninklijke Philips Electronics N.V. | Method for efficient retransmission timeout estimation in NACK-based protocols |
| US7117521B2 (en) * | 2001-08-31 | 2006-10-03 | Intel Corporation | Method to measure the perceived quality of streaming media |
| US8880709B2 (en) * | 2001-09-12 | 2014-11-04 | Ericsson Television Inc. | Method and system for scheduled streaming of best effort data |
| US6996624B1 (en) * | 2001-09-27 | 2006-02-07 | Apple Computer, Inc. | Reliable real-time transport protocol |
-
2001
- 2001-12-04 JP JP2001369731A patent/JP3912091B2/ja not_active Expired - Lifetime
-
2002
- 2002-12-03 KR KR20020076260A patent/KR100967377B1/ko not_active IP Right Cessation
- 2002-12-04 US US10/310,212 patent/US7315898B2/en active Active
Patent Citations (16)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH04170239A (ja) * | 1990-11-02 | 1992-06-17 | Nec Corp | データ伝送受信装置 |
| JPH05160811A (ja) * | 1991-12-06 | 1993-06-25 | Hitachi Ltd | データ転送方式 |
| JPH07202856A (ja) * | 1993-11-30 | 1995-08-04 | At & T Corp | パケット再送信装置 |
| JPH07283782A (ja) * | 1994-04-08 | 1995-10-27 | Matsushita Electric Ind Co Ltd | 移動通信システム |
| JPH07283757A (ja) * | 1994-04-14 | 1995-10-27 | Matsushita Electric Ind Co Ltd | 音声データ通信装置 |
| JPH09191314A (ja) * | 1996-01-10 | 1997-07-22 | Mitsubishi Electric Corp | 連続データ伝送方法および連続データ伝送装置 |
| JPH09247132A (ja) * | 1996-03-08 | 1997-09-19 | Yazaki Corp | 無線パケット通信装置及び送信装置 |
| JPH10200897A (ja) * | 1997-01-08 | 1998-07-31 | Nippon Telegr & Teleph Corp <Ntt> | 動画像伝送装置 |
| JPH1132077A (ja) * | 1997-07-10 | 1999-02-02 | Mitsubishi Electric Corp | 送信制御装置、受信制御装置、通信制御システム及び通信制御方法 |
| JPH11262054A (ja) * | 1998-03-13 | 1999-09-24 | Toshiba Corp | 無線通信システム及び加入者用無線機 |
| JPH11331839A (ja) * | 1998-05-13 | 1999-11-30 | Matsushita Electric Ind Co Ltd | 映像伝送再送の装置及び方法 |
| JP2001119437A (ja) * | 1998-11-30 | 2001-04-27 | Matsushita Electric Ind Co Ltd | データ伝送方法，データ送信装置，データ受信装置，及びパケットデータ構造 |
| JP2001111618A (ja) * | 1999-10-08 | 2001-04-20 | Nippon Telegr & Teleph Corp <Ntt> | 通信システムとその通信方法、ならびにそのプログラムを記録した媒体 |
| JP2003515289A (ja) * | 1999-11-15 | 2003-04-22 | コーニンクレッカ フィリップス エレクトロニクス エヌ ヴィ | ストリーミングデータ受信器における復号器バッファの遅延割当量を制御するためのシステムと方法 |
| JP2001218276A (ja) * | 2000-02-04 | 2001-08-10 | Ntt Docomo Inc | 移動通信システムにおけるデータ通信方法及び装置 |
| JP2001298407A (ja) * | 2000-04-13 | 2001-10-26 | Ntt Docomo Inc | マルチキャストサービス提供システムにおける再送制御方法、情報配信装置及び無線端末 |
Cited By (39)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2003244695A (ja) * | 2002-02-14 | 2003-08-29 | Kddi Corp | 映像情報伝送方式、それに用いられる装置およびプログラム |
| JP2005006340A (ja) * | 2003-06-13 | 2005-01-06 | Microsoft Corp | ネットワーク通信のための時間指向、ベストエフォート的、穴埋め型再試行方法およびシステム |
| JP4694152B2 (ja) * | 2003-06-13 | 2011-06-08 | マイクロソフト コーポレーション | ネットワーク通信のための時間指向、ベストエフォート的、穴埋め型再試行方法およびシステム |
| JP2005198055A (ja) * | 2004-01-08 | 2005-07-21 | Sony Corp | 受信装置および方法、プログラム、並びに記録媒体 |
| US8155035B2 (en) | 2004-01-08 | 2012-04-10 | Sony Corporation | Reception apparatus and method, program, and recording medium |
| US7539174B2 (en) | 2004-03-09 | 2009-05-26 | Ntt Docomo, Inc. | Mobile communication system, mobile station device, and network-side device |
| JP2005303927A (ja) * | 2004-04-15 | 2005-10-27 | Sony Corp | 情報処理システム、情報処理装置および方法、記録媒体、並びにプログラム |
| JP2008079334A (ja) * | 2004-09-21 | 2008-04-03 | Hitachi Communication Technologies Ltd | ノード装置、パケット制御装置、無線通信装置および送信制御方法 |
| US8068500B2 (en) | 2004-09-21 | 2011-11-29 | Hitachi, Ltd. | Node device, packet control device, radio communication device, and transmission control method |
| JP4571967B2 (ja) * | 2004-09-21 | 2010-10-27 | 株式会社日立製作所 | ノード装置、パケット制御装置、無線通信装置および送信制御方法 |
| JP2006319423A (ja) * | 2005-05-10 | 2006-11-24 | Toshiba Corp | 送信機及び受信機 |
| JP4688566B2 (ja) * | 2005-05-10 | 2011-05-25 | 富士通東芝モバイルコミュニケーションズ株式会社 | 送信機及び受信機 |
| JP2007019705A (ja) * | 2005-07-06 | 2007-01-25 | Sony Corp | 通信システム、送信装置、送信方法、およびプログラム |
| JP4517294B2 (ja) * | 2005-07-06 | 2010-08-04 | ソニー株式会社 | 通信システム、送信装置、送信方法、およびプログラム |
| JP2007053745A (ja) * | 2005-07-22 | 2007-03-01 | Sanyo Electric Co Ltd | 受信機及びプログラム |
| US8731069B2 (en) | 2005-08-25 | 2014-05-20 | Canon Kabushiki Kaisha | Remote display system and method |
| JP2007325077A (ja) * | 2006-06-02 | 2007-12-13 | Mitsubishi Electric Corp | データ受信装置及びデータ受信方法 |
| US8792520B2 (en) | 2006-09-22 | 2014-07-29 | Canon Kabushiki Kaisha | Communication apparatus and method of transferring data |
| JP2008079150A (ja) * | 2006-09-22 | 2008-04-03 | Canon Inc | 通信機器及びデータ転送方法 |
| WO2008041329A1 (en) * | 2006-10-04 | 2008-04-10 | Fujitsu Limited | Data transfer method |
| JP4625119B2 (ja) * | 2008-09-09 | 2011-02-02 | 株式会社エヌ・ティ・ティ・ドコモ | 移動通信システム、移動端末及びネットワーク側対向装置 |
| JP2009027740A (ja) * | 2008-09-09 | 2009-02-05 | Ntt Docomo Inc | 移動通信システム、移動端末及びネットワーク側対向装置 |
| JP2011015214A (ja) * | 2009-07-02 | 2011-01-20 | Canon Inc | 送信装置、送信方法、及びコンピュータプログラム |
| CN102714728A (zh) * | 2010-01-14 | 2012-10-03 | 住友电气工业株式会社 | 视频图像编码数据的显示方法、设备和通信系统 |
| CN102714728B (zh) * | 2010-01-14 | 2015-04-29 | 住友电气工业株式会社 | 视频图像编码数据的显示方法、设备和通信系统 |
| JP5549681B2 (ja) * | 2010-01-14 | 2014-07-16 | 住友電気工業株式会社 | 動画像符号化データの表示方法、装置及び通信システム |
| WO2011086952A1 (ja) * | 2010-01-14 | 2011-07-21 | 住友電気工業株式会社 | 動画像符号化データの表示方法、装置及び通信システム |
| US9219925B2 (en) | 2010-01-14 | 2015-12-22 | Sumitomo Electric Industries, Ltd. | Video image coded data display method, device, and communications system |
| JP2011259183A (ja) * | 2010-06-09 | 2011-12-22 | Nippon Telegr & Teleph Corp <Ntt> | データ配信システムおよびデータ配信方法 |
| JP2012170010A (ja) * | 2011-02-16 | 2012-09-06 | Fujitsu Ltd | 通信方法、通信プログラム、および、通信装置 |
| WO2013011545A1 (ja) * | 2011-07-15 | 2013-01-24 | 三菱電機株式会社 | 送信装置、受信装置、通信装置、通信システムおよび送信方法 |
| JPWO2013011545A1 (ja) * | 2011-07-15 | 2015-02-23 | 三菱電機株式会社 | 送信装置、受信装置、通信装置、通信システムおよび送信方法 |
| JP2014039136A (ja) * | 2012-08-15 | 2014-02-27 | Nippon Hoso Kyokai <Nhk> | 無線通信を行う送信装置、受信装置、送信方法、受信方法及びプログラム |
| JP2015080198A (ja) * | 2013-09-11 | 2015-04-23 | パナソニックＩｐマネジメント株式会社 | 通信制御装置および通信制御方法 |
| JP2016541210A (ja) * | 2013-09-26 | 2016-12-28 | コーヒレント・ロジックス・インコーポレーテッド | 次世代放送システム及び方法 |
| WO2020174994A1 (ja) | 2019-02-26 | 2020-09-03 | パナソニックＩｐマネジメント株式会社 | カメラ映像伝送再生システム、それを構成するカメラおよびビューア |
| JP2022093387A (ja) * | 2019-03-15 | 2022-06-23 | オムロン株式会社 | 制御システム、装置および制御方法 |
| US11811547B2 (en) | 2019-03-15 | 2023-11-07 | Omron Corporation | Control system in which a plurality of apparatuses in time synchronization with one another are connected to a network |
| JP7396393B2 (ja) | 2019-03-15 | 2023-12-12 | オムロン株式会社 | 制御システム、装置および制御方法 |
Also Published As
| Publication number | Publication date |
|---|---|
| JP3912091B2 (ja) | 2007-05-09 |
| KR100967377B1 (ko) | 2010-07-05 |
| KR20030045643A (ko) | 2003-06-11 |
| US20030120802A1 (en) | 2003-06-26 |
| US7315898B2 (en) | 2008-01-01 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP3912091B2 (ja) | データ通信システム、データ送信装置、データ受信装置、および方法、並びにコンピュータ・プログラム | |
| JP3757857B2 (ja) | データ通信システム、データ送信装置、データ受信装置、および方法、並びにコンピュータ・プログラム | |
| US7263644B2 (en) | Data transmitting/receiving system and method thereof | |
| US7164680B2 (en) | Scheme for supporting real-time packetization and retransmission in rate-based streaming applications | |
| JP3450771B2 (ja) | データ伝送方法，及びデータ送信装置 | |
| JP4452983B2 (ja) | 受信装置および方法、プログラム、並びに記録媒体 | |
| US20030206549A1 (en) | Method and apparatus for multicast delivery of information | |
| US20040098748A1 (en) | MPEG-4 live unicast video streaming system in wireless network with end-to-end bitrate-based congestion control | |
| JP2003338841A (ja) | プロトコル、情報処理システムおよび方法、情報処理装置および方法、記録媒体、並びにプログラム | |
| KR20080059508A (ko) | 데이터 통신시스템, 데이터 송신장치, 데이터 송신방법 및패킷 사이즈 및 용장도 결정방법 | |
| WO2005112382A1 (en) | Cooperation between packetized data bit-rate adaptation and data packet re-transmission | |
| JP2007134836A (ja) | パケット送信装置、通信システム及びプログラム | |
| EP1235414B1 (en) | Data transmitting apparatus and data receiving apparatus | |
| JP2005045469A (ja) | マルチメディアコンテンツ受信装置及びマルチメディアコンテンツ受信方法 | |
| JP2003179662A (ja) | データ通信システム、データ送信装置、データ受信装置、および方法、並びにコンピュータ・プログラム | |
| JP2003324496A (ja) | データ伝送方法，及びパケットデータ構造 | |
| JP4433281B2 (ja) | 受信装置および方法、記録媒体、並びにプログラム | |
| EP1450535A1 (en) | A relay for hierarchical retransmissions in multimedia streaming | |
| JP2008141633A (ja) | データ通信システム、データ受信装置、データ受信方法、データ送信装置およびデータ送信方法 | |
| JP2003163691A (ja) | データ通信システム、データ送信装置、データ受信装置、および方法、並びにコンピュータ・プログラム | |
| JP3735352B2 (ja) | データ伝送方法，データ送信装置，及びデータ受信装置 | |
| JP2005136547A (ja) | 通信システム、受信装置および方法、送信装置および方法、記録媒体、並びにプログラム | |
| JP2001320407A (ja) | データ通信装置、データ通信用拡張ボード及びデータ通信方法 | |
| JP2006067410A (ja) | 送信装置および方法、プログラム、並びに送受信システム |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20040423 |
|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20040423 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20051205 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20060110 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20060309 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20060704 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20060714 |
|
| 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: 20070109 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20070122 |
|
| R151 | Written notification of patent or utility model registration |
Ref document number: 3912091 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R151 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100209 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110209 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110209 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120209 Year of fee payment: 5 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120209 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130209 Year of fee payment: 6 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130209 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20140209 Year of fee payment: 7 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| EXPY | Cancellation because of completion of term |