JP3912091B2 - データ通信システム、データ送信装置、データ受信装置、および方法、並びにコンピュータ・プログラム - Google Patents
データ通信システム、データ送信装置、データ受信装置、および方法、並びにコンピュータ・プログラム Download PDFInfo
- Publication number
- JP3912091B2 JP3912091B2 JP2001369731A JP2001369731A JP3912091B2 JP 3912091 B2 JP3912091 B2 JP 3912091B2 JP 2001369731 A JP2001369731 A JP 2001369731A JP 2001369731 A JP2001369731 A JP 2001369731A JP 3912091 B2 JP3912091 B2 JP 3912091B2
- Authority
- JP
- Japan
- Prior art keywords
- data
- packet
- retransmission request
- retransmission
- data packet
- 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.)
- Expired - Lifetime
Links
Images
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/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/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/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)
- Computer Security & Cryptography (AREA)
- Theoretical Computer Science (AREA)
- Databases & Information Systems (AREA)
- General Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Physics & Mathematics (AREA)
- General Business, Economics & Management (AREA)
- General Physics & Mathematics (AREA)
- Business, Economics & Management (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Communication Control (AREA)
- Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
- Compression Or Coding Systems Of Tv Signals (AREA)
- Detection And Prevention Of Errors In Transmission (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は、データ通信システム、データ送信装置、データ受信装置、および方法、並びにコンピュータ・プログラムに関する。さらに詳細には、ストリーミングデータ転送におけるエラー耐性を高めたパケット送信構成を持つデータ通信システム、データ送信装置、データ受信装置、および方法、並びにコンピュータ・プログラムに関する。
【０００２】
【従来の技術】
昨今、インターネット通信など、様々な通信媒体を介した画像、音声データ等のデータ転送が盛んに行われている。特に、近年においては、インターネット上のデータ転送において、従来から利用されているダウンロード型伝送方式に加えて、ストリーム型伝送方式によるサービスが増加してきている。ダウンロード型伝送方式においては、映像ファイルや音声ファイルといったマルチメディアデータを伝送する場合、配信サーバからデータファイルを一旦受信側端末の記憶媒体にダウンロードして、その後、記憶媒体から再生することになる。よって、この方式ではファイルを完全に転送が終わるまでは再生できず、長時間再生やリアルタイム再生などには不向きである。
【０００３】
一方、後者のストリーム型伝送方式では、送信側から受信端末にデータ転送が行われている間に、並列して受信データの再生処理を実行するものであり、インターネット電話・遠隔テレビ会議・ビデオオンデマンドといったインターネットサービスに利用されている。
【０００４】
ストリーム型伝送方式は、例えば画像データのＭＰＥＧ圧縮処理により生成されるＭＰＥＧストリームをＩＰ（Internet Protocol）パケットに格納してインターネット上を転送させて、ＰＣやＰＤＡ、携帯電話等の各通信端末において受信するシステム等において使用され、開発が進んでいる。このような技術は、ビデオオンデマンドやライブ映像のストリーミング配信、あるいはビデオ会議、テレビ電話などのリアルタイム通信において有効となる。
【０００５】
このようなストリーム型伝送方式に適したインターネット技術に、IETF RFC1889で規定されているプロトコル：ＲＴＰ(Realtime Transport Protocol)がある。ＲＴＰに従ったデータ転送では、時間情報としてパケットにタイムスタンプを付加し、タイムスタンプの参照により送信側と受信側の時間的関係の把握を行ない、データ受信側において、パケット転送の遅延ゆらぎ（ジッター）などの影響を受けずに同期をとった再生を可能としている。
【０００６】
ただし、ＲＴＰは実時間のデータ転送を保証しているものではない。パケット配送の優先度や設定、管理などはＲＴＰが提供するトランスポートサービスの範疇ではないため、ＲＴＰパケットは、他のパケットと同様、ネットワーク上での配送遅延やパケット損失がおきる可能性がある。しかし、このような事態が起こっても、受信側は期待する時間内に到着したパケットだけを利用してデータを再生することが可能である。これは、映像や音声データが多少のデータ欠損があったとしても、データ品質を落とした再生、あるいはデータ補正処理による再生が可能となるからである。
【０００７】
なお、再生に間に合わず遅延配送されたパケットやエラーの発生したパケットは、受信側でそのまま破棄される。つまり、パケット損失やエラーが発生した場合は、高品質なデータ配信処理を行なっている場合でも、受信側で品質を保持した再生が実行されないという問題点がある。特に、有線区間で１０−５、無線区間で１０−３以上のエラーがあるといわれている中では、配信するメディアの品質保持を考慮すると、ＲＴＰをそのまま利用したデータ転送には問題がある。
【０００８】
このようなＲＴＰに従ったデータ転送における問題点を解決する１つの案としては、データ転送に信頼性が高いデータ転送プロトコルであるＴＣＰに従ってパケットの再送要求および再送パケット送信を行わせる方法が考えられる。しかし、ＴＣＰはエラーには強いが、スループットが低く、遅延が大きいため、再送しても再生時間に間に合わない可能性があり、リアルタイム通信の実現を困難とするという問題がある。
【０００９】
さらに、パケットエラー等に対応するエラー訂正手法として、例えばＦＥＣ（Forward Error Correction）という手段が考えられている。これは誤り訂正を行うためのＦＥＣデータを冗長データとして送信して、エラーが発生した場合には、データ受信側において、このＦＥＣデータをもとにエラーの修復を実行しようとするものである。先のＡＲＱによるパケット再送処理に比べると再送にかかる遅延がない分、遅延時間を低く抑えられるが、冗長データを付加するためにスループットが低下するという問題がある。また、ネットワーク状況に合わせた最適な付加ＦＥＣデータを決定するのは難しく、処理時間のオーバーヘッドが常につきまとうなどの問題が存在する。
【００１０】
【発明が解決しようとする課題】
本発明は、上述の問題点に鑑みてなされたものであり、ビデオオンデマンドや、遠隔テレビ会議のような、リアルタイム再生が望まれるデータ転送処理を効率的に実行可能とかるとともに、パケット損失等のエラー発生時にも品質の低下を抑えて高品質なデータ再生を実現するデータ通信システム、データ送信装置、データ受信装置、および方法、並びにコンピュータ・プログラムを提供することを目的とする。
【００１１】
【課題を解決するための手段】
本発明の第１の側面は、
データ送信装置およびデータ受信装置からなり、ストリーム型データ転送を実行するデータ通信システムであり、
データ送信装置は、
送信データを格納したデータパケットを送信するパケット送信処理部と、
データ受信装置から受信する再送要求メッセージパケットに従って再送すべきデータパケットの抽出処理を実行する再送制御部とを有し、
データ受信装置は、
前記データ送信装置から受信するデータパケットを受信するパケット受信処理部と、
前記データ送信装置から受信するデータパケットのエラーまたはロスト・データパケットの検出に基づいて、前記データ送信装置に対するデータパケット再送要求としての再送要求メッセージパケットの送信可否を判定する再送要求処理制御部とを有し、
前記再送要求処理制御部は、
再送要求に基づく再送データパケット受信が、再送データパケット格納データの再生に伴う処理開始時間前に可能か否かを判定し、可能であるとの判定を条件として、前記再送要求メッセージの送信処理を実行すると共に、
再送データパケット受信が、再送データパケット格納データの再生に伴う処理開始時間前に可能となる予め計測済みの最終期限において、最終的なロスト・データパケットの検出処理を実行し、前記最終期限においてロスト・データパケットの検出がなされた場合には、最終的な前記再送要求メッセージの送信処理を実行する構成を有することを特徴とするデータ通信システムにある。
【００２５】
さらに、本発明の第２の側面は、
ストリーム型データ受信を実行するデータ受信装置であり、
データ送信装置から受信するデータパケットを受信するパケット受信処理部と、
前記データ送信装置から受信するデータパケットのエラーまたはロスト・データパケットの検出に基づいて、前記データ送信装置に対するデータパケット再送要求としての再送要求メッセージパケットの送信可否を判定する再送要求処理制御部とを有し、
前記再送要求処理制御部は、
再送要求に基づく再送データパケット受信が、再送データパケット格納データの再生に伴う処理開始時間前に可能か否かを判定し、可能であるとの判定を条件として、前記再送要求メッセージの送信処理を実行すると共に、
再送データパケット受信が、再送データパケット格納データの再生に伴う処理開始時間前に可能となる予め計測済みの最終期限において、最終的なロスト・データパケットの検出処理を実行し、前記最終期限においてロスト・データパケットの検出がなされた場合には、最終的な前記再送要求メッセージの送信処理を実行する構成を有することを特徴とするデータ受信装置にある。
【００２６】
さらに、本発明のデータ受信装置の一実施態様において、前記データ・パケットの格納データは、符号化データであり、前記再送要求処理制御部は、再送要求に基づく再送データパケット受信が、再送データパケット格納データの復号処理を含む再生に伴う処理開始時間前に可能か否かを判定する構成であることを特徴とする。
【００２７】
さらに、本発明のデータ受信装置の一実施態様において、前記データ受信装置は、再送要求データパケットの識別データとしてのシーケンス番号と、該シーケンス番号に対応するデータパケットの重複再送の指定回数データを格納した再送要求メッセージパケットを生成して前記データ送信装置に送信する構成を有することを特徴とする。
【００２８】
さらに、本発明のデータ受信装置の一実施態様において、前記データ受信装置の受信するデータパケットは、動画像データであり、前記再送要求処理制御部は、動画像データの１画像フレームの構成データを格納した複数のデータパケットの終端データパケットの受信に応じて、該終端データパケットの属する画像フレームの構成データを格納した複数のデータパケット中のエラーまたはロスト・データパケットの検出処理を実行する構成であることを特徴とする。
【００２９】
さらに、本発明のデータ受信装置の一実施態様において、前記データ受信装置の受信するデータパケットは、動画像データであり、前記再送要求処理制御部は、動画像データの１画像フレームの構成データを格納した複数のデータパケットの先頭データパケットの受信に応じて、該先頭データパケットの属する画像フレームの前フレームの構成データを格納した複数のデータパケット中のエラーまたはロスト・データパケットの検出処理を実行する構成であることを特徴とする。
【００３０】
さらに、本発明のデータ受信装置の一実施態様において、前記再送要求処理制御部は、データパケット格納データの再生処理開始時間に間に合うための再送要求最終期限に基づいて、受信データパケット中のエラーまたはロスト・データパケットの検出処理を実行する構成であることを特徴とする。
【００３１】
さらに、本発明のデータ受信装置の一実施態様において、前記再送要求処理制御部は、定期的な時間間隔に基づいて、受信データパケット中のエラーまたはロスト・データパケットの検出処理を実行する構成であることを特徴とする。
【００３２】
さらに、本発明のデータ受信装置の一実施態様において、前記再送要求処理制御部は、前記データ送信装置とデータ受信装置における往復伝播遅延（ＲＴＴ）の計測処理のために前記データ送信装置に対するエコーパケットの送信および該エコーパケットに対するエコーリプライパケットの受信処理制御を実行し、該エコーパケットに基づいて算出する往復伝播遅延（ＲＴＴ）に基づいて、再送要求に基づく再送データパケット受信が、再送データパケット格納データの再生処理開始時間前に可能か否かを判定する構成を有することを特徴とする。
【００３３】
さらに、本発明のデータ受信装置の一実施態様において、前記データ受信装置は、再送要求データパケットの識別データとしてのシーケンス番号、またはパケットの属するタイムスタンプ指定データの少なくともいずれかと、再送要求範囲を指定するオプションを格納した再送要求メッセージパケットを生成して前記データ送信装置に送信する構成を有することを特徴とする。
【００３４】
さらに、本発明のデータ受信装置の一実施態様において、前記データパケットは、データ転送プロトコルとしてのＲＴＰに従ったフォーマットを有し、前記再送要求は、制御プロトコルとしてのＲＴＣＰに従ったフォーマットを有することを特徴とする。
【００３５】
さらに、本発明のデータ受信装置の一実施態様において、前記データ受信装置は、複数のデータパケットに関する再送要求を１つの再送要求メッセージパケットとしてデータ送信装置に対して送信する構成であることを特徴とする。
【００３６】
さらに、本発明のデータ受信装置の一実施態様において、前記データ受信装置は、複数のデータパケットに関する受信確認を１つの受信確認メッセージパケットとしてデータ送信装置に対して送信する構成であることを特徴とする。
さらに、本発明の第３の側面は、
ストリーム型データ受信を実行するデータ受信装置であり、
データ送信装置から受信するデータパケットを受信するパケット受信処理部と、
前記データ送信装置から受信するデータパケットのエラーまたはロスト・データパケットの検出に基づいて、前記データ送信装置に対するデータパケット再送要求としての再送要求メッセージパケットの送信可否を判定する再送要求処理制御部とを有し、
前記再送要求処理制御部は、
再送要求に基づく再送データパケット受信が、再送データパケット格納データの再生に伴う処理開始時間前に可能か否かを判定し、可能であるとの判定を条件として、前記再送要求メッセージパケットの送信処理を実行し、当該送信処理に際して、前記データパケット受信時におけるパケットロス率に基づいて前記再送要求メッセージパケットの送信回数を変化させ、パケットロス率が一定値以上になった場合は、前記再送要求メッセージパケットの送信回数を増加させる処理を行なう構成を有すると共に、
データパケット格納データの再生処理開始時間に間に合うための再送要求最終期限に基づいて、受信データパケット中のエラーまたはロスト・データパケットの検出処理を実行する構成を有することを特徴とするデータ受信装置にある。
さらに、本発明の第４の側面は、
ストリーム型データ受信を実行するデータ受信装置であり、
データ送信装置から受信するデータパケットを受信するパケット受信処理部と、
前記データ送信装置から受信するデータパケットのエラーまたはロスト・データパケットの検出に基づいて、前記データ送信装置に対するデータパケット再送要求としての再送要求メッセージパケットの送信可否を判定する再送要求処理制御部とを有し、
前記再送要求処理制御部は、
再送要求に基づく再送データパケット受信が、再送データパケット格納データの再生に伴う処理開始時間前に可能か否かを判定し、可能であるとの判定を条件として、再送要求送信を決定すると共に、前記再送要求メッセージパケットに対して該再送要求メッセージパケットの再送回数を記述する構成を有するとともに、
データパケット格納データの再生処理開始時間に間に合うための再送要求最終期限に基づいて、受信データパケット中のエラーまたはロスト・データパケットの検出処理を実行する構成を有することを特徴とするデータ受信装置にある。
【００３７】
さらに、本発明の第５の側面は、
ストリーム型データ受信を実行するデータ受信方法であり、
データ送信装置から受信するデータパケットを受信するパケット受信処理ステップと、
前記データ送信装置から受信するデータパケットのエラーまたはロスト・データパケットの検出に基づいて、前記データ送信装置に対するデータパケット再送要求としての再送要求メッセージパケットの送信可否を判定する再送要求処理制御ステップとを有し、
前記再送要求処理制御ステップは、
再送要求に基づく再送データパケット受信が、再送データパケット格納データの再生に伴う処理開始時間前に可能か否かを判定し、可能であるとの判定を条件として、前記再送要求メッセージの送信処理を実行すると共に、
再送データパケット受信が、再送データパケット格納データの再生に伴う処理開始時間前に可能となる予め計測済みの最終期限において、最終的なロスト・データパケットの検出処理を実行し、前記最終期限においてロスト・データパケットの検出がなされた場合には、最終的な前記再送要求メッセージの送信処理を実行するステップを有することを特徴とするデータ受信方法にある。
【００４９】
さらに、本発明の第６の側面は、
データ受信装置において、ストリーム型データ受信処理を実行させるコンピュータ・プログラムであって、
データ送信装置から受信するデータパケットを受信するパケット受信処理ステップと、
前記データ送信装置から受信するデータパケットのエラーまたはロスト・データパケットの検出に基づいて、前記データ送信装置に対するデータパケット再送要求としての再送要求メッセージパケットの送信可否を判定する再送要求処理制御ステップとを有し、
前記再送要求処理制御ステップは、
再送要求に基づく再送データパケット受信が、再送データパケット格納データの再生に伴う処理開始時間前に可能か否かを判定し、可能であるとの判定を条件として、前記再送要求メッセージの送信処理を実行すると共に、
再送データパケット受信が、再送データパケット格納データの再生に伴う処理開始時間前に可能となる予め計測済みの最終期限において、最終的なロスト・データパケットの検出処理を実行し、前記最終期限においてロスト・データパケットの検出がなされた場合には、最終的な前記再送要求メッセージの送信処理を実行させるステップを有することを特徴とするコンピュータ・プログラムにある。
【００５０】
なお、本発明のコンピュータ・プログラムは、例えば、様々なプログラム・コードを実行可能な汎用コンピュータ・システムに対して、コンピュータ可読な形式で提供する記憶媒体、通信媒体、例えば、ＣＤやＦＤ、ＭＯなどの記録媒体、あるいは、ネットワークなどの通信媒体によって提供可能なコンピュータ・プログラムである。このようなプログラムをコンピュータ可読な形式で提供することにより、コンピュータ・システム上でプログラムに応じた処理が実現される。
【００５１】
本発明のさらに他の目的、特徴や利点は、後述する本発明の実施例や添付する図面に基づくより詳細な説明によって明らかになるであろう。なお、本明細書においてシステムとは、複数の装置の論理的集合構成であり、各構成の装置が同一筐体内にあるものには限らない。
【００５２】
【発明の実施の形態】
［システム及びデータ送受信概要］
まず、図１を参照して、本発明のシステム概要及びデータ送受信処理の概要について説明する。
【００５３】
図１のデータ通信システムにおいて、送信側端末１０４は受信側端末１２１に対して画像、音声等のデータをパケット化して送信する。転送データは、例えばビデオカメラ１０１によって取得された画像、音声データである。なお、転送データは、ＣＤ，ＤＶＤ等の記憶媒体から入力されるデータ、あるいは外部ネットワーク、衛星等から受信するデータ等であってもよい。なお、以下の説明では、１つの例として送信側端末１０４から受信側端末１２１へビデオカメラ１０１によって取得された動画像データを転送する構成を中心として説明する。
【００５４】
ビデオカメラ１０１によって取得された動画像データは、送信側端末１０４の符号化装置１０２により符号化、例えばＭＰＥＧ圧縮処理等による符号化がなされて、バッファ１０３に蓄積される。バッファ１０３に蓄積された符号化データは、リアルタイム・トランスポート・プロトコル：ＲＴＰ（Real-time Transport Protocol）に従ったデータ・パケット（以下パケットと称する）を生成するＲＴＰパケット作成部１０６に出力され、符号化データを格納したＲＴＰパケットのパケット生成処理が実行される。ＲＴＰパケット作成部１０６において生成された符号化データを格納したＲＴＰパケットは、ＲＴＰプロトコルを通じてＲＴＰパケット出力ポート１１０からＩＰネットワーク１１１に送出される。送信側端末１０４のＲＴＰパケット作成部１０６およびＲＴＰパケット出力ポートによってパケット送信処理部が構成される。
【００５５】
ＲＴＰパケット作成部１０６は、符号化データをペイロードとしたパケットを生成する処理を実行する。ペイロードデータに対して、ＲＴＰヘッダを付加しパケット化する。ＲＴＰパケット構成を図２に示す。ＲＴＰヘッダには、バージョン番号（ｖ）、パディング（Ｐ）、拡張ヘッダ（Ｘ）の有無、送信元数（Ｃｏｕｎｔｅｒ）、マーカ情報（ｍａｒｋｅｒ ｂｉｔ）、ペイロードタイプ（Ｐａｙｌｏａｄ ｔｙｐｅ）、シーケンス番号、タイムスタンプ、同期ソース（送信元）識別子（ＳＳＲＣ）および貢献ソース（送信元）識別子（ＣＳＲＣ）の各フィールドが設けられている。データ受信側において、ＲＴＰヘッダに付与されたタイムスタンプによりＲＴＰパケットの展開時に処理時間の制御が実行され、リアルタイム画像、または音声の再生制御が可能となる。なお、例えば動画像データの符号化データを格納したＲＴＰパケットにおいては、１つの画像フレームに属する複数のＲＴＰパケットに共通のタイムスタンプが設定され、各フレームを構成する終端パケットには、終端であることを示す識別フラグがＲＴＰヘッダに格納される。
【００５６】
ＲＴＰヘッダを付加されたパケットはさらにＩＰヘッダが付与される。図３にＩＰパケットの構成中のＩＰヘッダの詳細を示す。ＩＰｖ４、ＩＰｖ６等のバージョンを示すバージョン、ヘッダ長、さらに、優先度情報を格納したＴＯＳ（Type of Service）フィールド、パケットの長さ、パケットの識別子、ＩＰ層でのデータ分割（フラグメント）に関する制御情報としてのフラグ、分割（フラグメント）されたデータの場所を示す断片オフセット、データの破棄までの時間情報を示すＴＴＬ（Time to Live）、上位層で利用されるプロトコル（４：ＩＰ，ＴＣＰ：７，ＵＤＰ：１７…）ヘッダのチェックサム、送信元ＩＰアドレス、宛て先ＩＰアドレスを有する。
【００５７】
図１に戻り、データ受信処理について説明する。受信側端末１２１のＲＴＰパケット入力ポート１１２は、ＩＰネットワーク１１１を介して送信側端末１０４からのＲＴＰパケットを受信する。受信したＲＴＰパケットは、パケット解析部１１４においてパケットの解析が実行される。受信側端末１２１のＲＴＰパケット入力ポート１１２および、パケット解析部１１４によってパケット受信処理部が構成される。パケット解析部１１４は、具体的にはパケット内のヘッダ部、データ部についての解析が実行される。パケットから取り出されたペイロードとしてのデータ、すなわち、符号化データは、バッファ１１７に蓄積される。また、パケットから抽出されたデータのバッファの蓄積位置を示す位置データや、各データに対応するパケットのヘッダ情報は、インデックスリスト１１８として蓄積される。
【００５８】
バッファ１１７に蓄積された符号化データは、インデックスリスト１１８に蓄積されたヘッダ情報に基づく時間制御の下にデコーダ１２０に渡され、デコーダ１２０によって復号処理が実行される。例えば動画像を構成する各画像フレームは、複数のパケットに格納されたデータによって構成され、１つの画像フレームを構成するデータを格納した複数のＲＴＰパケットのヘッダには、同一のタイムスタンプが格納されるので、インデックスリスト１１８に蓄積されたヘッダ情報のタイムスタンプを参照して同一タイムスタンプを持つパケットを１つの画像フレームを構成する符号化データの集合として、デコーダ１２０に渡すことが可能となり、デコーダ１２０は、フレーム毎に復号処理を実行することができる。デコーダ１２０において復号されたデータは、再生装置としてのディスプレイ１２３、またはスピーカ１２２へ渡され、出力再生される。
【００５９】
送信側端末１０４から受信側端末１２１へ転送されるパケットが全て滞りなく、また、エラーのない状態で送信されれば、受信側端末１２１におけるリアルタイムデータ再生は問題なく実行される。しかし、実際は、ネットワーク上でのパケット損失の発生、遅延、転送パケットのデータエラー等、様々な要因に基づく再生エラーあるいは再生データの品質低下が発生し得る。
【００６０】
本発明のシステムにおいては、受信側端末１２１のＲＴＰパケット解析部１１４においてパケット損失等のエラーの発生を検出し、パケット損失等のエラー発生が検出された際には、ＡＲＱ（Auto Repeat reQuest）判定部１１９において、リアルタイム再生シーケンスを考慮したパケット再送要求の可否判定処理を実行する。ＡＲＱ（Auto Repeat reQuest）判定部１１９は、データ送信装置から受信するデータパケットのエラーまたはロスト・データパケットの検出に基づいて、データ送信装置に対するデータパケット再送要求としての再送要求メッセージパケットの送信可否を判定する再送要求処理制御部として機能する。ＡＲＱ判定部１１９における具体的な処理については後述する。
【００６１】
ＡＲＱ判定部１１９において、再送要求を実行するとの判定がなされた場合、受信側端末１２１は、再送要求パケットを識別するデータを格納した再送要求ＮＡＣＫ（Negative ACKnowledge)−ＲＴＣＰ（Real-time Transport Control Protocol）パケットをＲＴＣＰパケット作成装置１１６にて作成し、ＲＴＣＰパケット入出力ポート１１３を介して、送信側端末１０４に対して出力する。
【００６２】
送信側端末１０４のＲＴＣＰパケット入出力ポート１０９において、受信側端末１２１からの再送要求を示すＮＡＣＫ−ＲＴＣＰパケットを受信すると、受信したＮＡＣＫ−ＲＴＣＰパケットをＲＴＣＰパケット解析部１０８において解析し、解析結果をＡＲＱ処理部１０５へ渡す。ＡＲＱ処理部１０５では、再送要求に応じたパケットの再送を実行するため、ＮＡＣＫ−ＲＴＣＰパケットにおいて指定されたパケットをバッファ１０３から抽出し、抽出したパケットを、ＲＴＰパケット出力ポート１１０を介して再送する制御処理を実行する。ＡＲＱ処理部１０５は、データ受信端末装置から受信する再送要求メッセージパケットに従って再送すべきデータパケットの抽出処理を実行する再送制御部として機能する。なお、ＮＡＣＫ−ＲＴＣＰパケットに基づく再送要求に応じたパケット再送処理において、送信側端末１０４は、ＮＡＣＫ−ＲＴＣＰパケットに重複送信の指定がある場合等、必要に応じてＡＲＱ処理部１０５の判断により再送パケットを重複して送る場合もある。これらの処理の詳細については、後述する。
【００６３】
送信側端末１０４において送信すべきストリームデータが終了したのを検知した場合には、送信側端末１０４のＲＴＣＰパケット作成部１０７の生成したＥＯＳ（End Of Stream）メッセージを持つＲＴＣＰパケットを受信側端末１２１へ送り、データストリームの終了を明示する。
【００６４】
本発明のシステムにおいては、ＡＲＱ処理部１０５において、リアルタイム再生を考慮して、ロストパケットに関する再送要求の実行／非実行の処理を決定する。データ転送における自動再送要求方式であるＡＲＱ（Automatic Repeat reQuest）は非常に有効な誤り訂正機能として知られている。ＡＲＱの具体的方式としては、例えばＳＡＷ（Stop And Wait）方式、ＧＢＮ（Go Back N）方式、ＳＲ（Selective Repeat）方式など種々の方法が提案され実現されている。本実施例においては、ＡＲＱ基本アルゴリズムとして、スループット特性が高い選択再送ＳＲ（Selective Repeat）方式エラー訂正機能として使用する例について説明する。
【００６５】
ＳＲ方式の場合、理想的には送信側と受信側で無限のバッファを用意する必要がある。そのため、受信側のバッファオーバーフローが起こった時点または起こりそうな時点でＳＲ方式から別の再送方式に変更する方法やパケットのコピー伝送を通常から行いオーバーフローを回避する方法などが提案されている。しかしながら、本実施例におけるエラー訂正機能においては、ＰＨＳ、ＴＣＰ、データリンク層などに代表される完全にデータを送信することを第一優先にしているＡＲＱと異なり、データ受信側で実行される受信データの再生処理時間から想定されるパケット受信最終許容時間までに、できるだけ必要なデータの受信を実現する事を優先している。よって、ＳＲ方式からＳＴ方式やＧＢＮ方式には移行せず、ＳＲ方式のままＡＲＱを行う構成としている。また、バッファフローオーバーにならないよう受信側はバッファ制御を行い効率よくデータを送信する構成とする。
【００６６】
本発明の１つの実施例では、送信中にロストしてしまったパケットの再送要求は、RFC1889 で規定されているＲＴＣＰ（Real-time Transport Control Protocol）に従って、ＮＡＣＫ（Negative ACKnowledge)を送ることで実現する。RFC1889ではＲＴＣＰパケットの連続送信間隔を５秒以上あける事を推奨している。ここで再送要求を５秒以上間隔を空けたとすると、受信側のバッファ溢れが生じるだけでなく、そもそもメディアの再生時間に間に合うように再送することができない。ストリーミングはリアルタイム性が強い分、
＊できるだけ早く再送要求を出す
＊再送要求を受信したらできるだけ早いうちに再送する
という動作を可能な時間内に実施しなければならない。そのために、ＡＲＱに用いるＮＡＣＫパケットは、データ受信側において能動的に随時必要に応じてデータ送信側に対して送信することが必要となり、推奨値を本発明の場合は適用せず、任意タイミングでのＮＡＣＫパケット送信を実行するものとする。
【００６７】
また、RFC1889ではＲＴＣＰのバンド幅を５％以内になるよう規定している。本発明の実施例に係る構成の再送パケットは最小単位で１６ｂｙｔｅと小さいため、再送要求によって帯域を圧迫するほどのものではないと考えられる。なお、画像データ等の実データ自体の伝送には、RFC1889で規定されているＲＴＰ（パケットフォーマットは図２参照）を用いる例について説明するが、パケット毎にシーケンス番号を記述しておけば、ＵＤＰ（User Datagram Protocol）等、他のプロトコルに従った処理も可能である。
【００６８】
リアルタイム再生を実現するデータ転送では、処理時間が限定されるため、送信と受信における往復伝播遅延（ＲＴＴ）が重要なパラメータとなる。往復伝播遅延（ＲＴＴ）が大きい場合、データ受信端末からデータ送信端末に対して再送要求を出しても、再送要求パケットがデータ送信端末側に到着するまでの時間、データ送信端末において指定データを格納した再送パケットを抽出して再送処理を実行するまでの時間、再送パケットをデータ受信端末が受信するまでの時間、これらの処理に時間を要すると、その後、データ受信端末において、デコーダに受信データを渡して復号を行なっても、リアルタイム再生に間に合わない場合が発生する。無論、間に合う間に合わないかかわらず再送要求を出しておく方が、訂正率の向上が達成される可能性は大となるが、再送要求パケットの送信、再送パケットの再送によるネットワークトラフィックの混雑が発生することになり、これらの冗長データの伝送によるオーバーヘッドの問題が発生することになる。
【００６９】
また、送信と受信における往復伝播遅延（ＲＴＴ）をデータ受信端末において、あらかじめ把握することにより、データ受信端末において、再送要求を行なってから再送パケットを受信するまでの時間の把握が可能となり、データ受信端末においてリアルタイム再生を行なうために必要な最終再送要求時間を割り出すことが可能なる。本発明のシステムでは、受信端末のＡＲＱ判定部において、往復伝播遅延（ＲＴＴ）に基づく最終再送要求時間を判定し、判定に基づいて、再送要求としてのＮＡＣＫ−ＲＴＣＰの送信を実行する。
【００７０】
このように、ＡＲＱにおいてリアルタイム性を保持するためには、常に送信と受信における往復伝播遅延（ＲＴＴ）を計測しておく必要がある。本発明のシステムでは、データ受信側端末は、能動的にＲＴＴを計測し、ネットワーク状況等において変化する送信と受信における往復伝播遅延（ＲＴＴ）の更新を実行し、最新のＲＴＴに基づいて再送要求としてのＮＡＣＫ−ＲＴＣＰの送信の実行可否を判定する。
【００７１】
なお、ＲＴＣＰに規定されたＳＲ（Sender Report）とＲＲ（Receiver Report）により送信側はＲＴＴの算出が可能となるが、リアルタイム再生の進行状況に基づいて、再送要求としてのＮＡＣＫ−ＲＴＣＰパケットを送出するかしないかを判定するのは、データ受信側端末であり、データ受信側端末において、逐次、ネットワーク状況を反映したＲＴＴ情報を取得可能とする構成が好ましい。従って、本発明のシステムにおいては、データ受信端末側から能動的にＲＴＴを算出可能な構成としている。具体的には、データ受信端末におけるＥＣＨＯパケットの送信、ＥＣＨＯ−ＲＥＰＬＹパケットの受信により、ＲＴＴの算出を行なう。これらの処理については、後段で詳細に説明する。
【００７２】
データ送信端末は、データ受信端末からのパケット再送要求としてのＮＡＣＫ−ＲＴＣＰパケットを受信すると、ＮＡＣＫ−ＲＴＣＰパケットに指定された再送要求パケットを、現在配信中のパケットと共に送信する。ただし、データ送信端末は、プライオリティを用いた配信スケジューリング機能を実行し、パケットの再送は、配信スケジューリングに従って実行される。
【００７３】
受信端末側から送信端末への応答パケットとして、パケット再送要求としてのＮＡＣＫ−ＲＴＣＰパケットのみを使用する構成としても、自動再送要求方式としてのＡＲＱ（Automatic Repeat reQuest）を有効に活用することができるが、本実施例においては、受信端末側からのパケット受信確認応答としてのＡＣＫ（ACKnowledge）メッセージもデータ送信端末に対する応答パケットとして送信する。このＡＣＫ送信により、再送要求に対応してパケットを保持する送信側のバッファを能動的に早めにクリアすることが可能となり、バッファ溢れの恐れを低下させることが可能となる。
【００７４】
また、ストリーミング配信されるデータが終了したことを明示的に示すＥＯＳ（End Of Stream）メッセージを送信端末側は利用できる。ＥＯＳメッセージを使うことにより、受信側がストリーミング配信データの終了を認識可能となる。従って、受信側が最終フレームを受け取っているにもかかわらず、次のフレームが到着しないことによるＮＡＣＫ送出動作を防ぐことができる。
【００７５】
受信端末側は、受信端末側で保持するタイマーにより、データ受信間隔、ＮＡＣＫ送出後の経過時間等を計測可能であり、タイマーによる計測時間が閾値以上となったことにより、データ終了と判定する処理が可能であるが、ＥＯＳメッセージの受信により、ストリーミング配信データの終了確認が可能となる。従って、タイマーより先に受信完了状態とすることができる。逆に、ＥＯＳメッセージを利用しない、またはＥＯＳがロストしてしまった場合は、ＮＡＣＫを送出しても送信側から再送パケットが送られてこないため、タイマーによって受信完了状態に移ることになる。
【００７６】
［データ送信端末における処理］
以下、図面を参照しながら、データ送信端末における処理の詳細について説明する。
【００７７】
データ送信端末の処理手順を図４に示すフローチャートを参照して説明する。図４に示す処理は、図１の送信側端末１０４において実行される処理を説明したフローである。送信側端末は、例えばビデオカメラ、あるいはＤＶＤ、ＣＤ、ハードディスク等の記憶媒体から撮り込んだデータをエンコーダにおいてＭＰＥＧ圧縮等の符号化処理を実行し、その後、符号化データをペイロードとしたパケットを生成する。図４に示すフローは、このパケット生成処理以降の処理を示している。
【００７８】
データ送信端末は、ステップＳ２０１において、送信データをペイロードとしたＲＴＰパケット生成処理を実行する。ＲＴＰパケットは、先に図２を参照して説明した構成を有しタイムスタンプをヘッダ中に持つ。例えば動画像データを送信する場合は、同一画像フレームに属する符号化データを格納したパケットには同一のタイムスタンプが設定され、後続フレームに進むに従って、増分されたタイムスタンプが設定される。
【００７９】
図５に示すパケット送信に係るタイムシーケンス図を参照して、タイムスタンプの設定例を説明する。データ送信側（Ｓｅｎｄｅｒ）に示すタイムスタンプ１２０００は、１つの画像フレームを構成する符号化データをペイロードとして格納した複数のＲＴＰパケット（シーケンス番号＝１〜６）に付与されるタイムスタンプである。その後のタイムスタンプ１５０００は、後続画像フレームを構成するＲＴＰパケット（シーケンス番号＝７〜１２）と、データ受信側からＮＡＣＫ−ＲＴＣＰパケットによる再送要求があり、再送するパケット（シーケンス番号＝４，５）とに設定されるタイムスタンプである。このように、データ送信端末では、例えば画像フレームを構成するパケットの集合に１つのタイムスタンプを設定してＲＴＰパケットを生成する。
【００８０】
図４に戻り、データ送信端末の処理について説明を続ける。ステップＳ２０１で生成したＲＴＰパケットは、ステップＳ２０２において、ＲＴＰパケット出力ポートを介して受信端末に向けてＩＰネットワークに出力される。なお、ＲＴＰパケットはさらに、先に図３を用いて説明したＩＰヘッダが付与され、ＩＰヘッダに設定されたアドレスに向けて配信されることになる。ステップＳ２０１、Ｓ２０２のパケット生成、パケット送信処理は、ストリーミング配信されるデータが終了したことを明示的に示すＥＯＳ（End Of Stream）を配信し、予め設定した時間をタイマーで計測して、タイマーでの計測時間が設定時間を超えた場合に、処理を終了する。
【００８１】
図４に示すステップＳ２０３のパケット再送要求としてのＮＡＣＫ−ＲＴＣＰパケットの受信判定処理、ステップＳ２０４のパケット受信確認応答としてのＡＣＫ−ＲＴＣＰパケットの受信判定処理、ステップＳ２０５のＲＴＴ時間計測用のＥＣＨＯ−ＲＴＣＰパケットの受信判定処理は、ＲＴＰパケットによる実データ送信中の割込み処理としてＲＴＰパケットによる実データ送信に並行して逐次実行される処理である。
【００８２】
ステップＳ２０３の処理は、データ受信端末からのパケット再送要求であるＮＡＣＫ−ＲＴＣＰパケットの受信判定処理である。データ受信端末からのパケット再送要求であるＮＡＣＫ−ＲＴＣＰパケットを受信した場合は、ステップＳ２１１〜Ｓ２１５の処理を実行する。このステップＳ２１１〜Ｓ２１５の処理は、図１に示すＡＲＱ処理部１０５における処理として実行される。
【００８３】
ステップＳ２１１においては、データ送信装置は、ＮＡＣＫ−ＲＴＣＰパケットを受信する。図６にデータ受信端末において生成し、データ送信端末の受信するパケット再送要求であるＮＡＣＫ−ＲＴＣＰパケットの構成を示す。
【００８４】
ＮＡＣＫ−ＲＴＣＰパケットは、図６に示すようにヘッダ（ＨＥＡＤ）、フォーマット（ＦＯＲＭＡＴ）、パケットタイプ、パケット長、送信同期ソース識別子（ＲＴＣＰ）、タイムスタンプの情報に加えて、再送要求対象となるパケットの識別子としての再送指定シーケンス番号、さらに、各再送指定シーケンス番号に対応するデータとして、「再送回数」、「オプション」、「重複指定回数」が設定可能である。
【００８５】
前述したように、本発明の提案するＡＲＱを適用したシステムでは、ＲＴＣＰに従ったコントロール・パケットとして再送要求としてのＮＡＣＫ、受信確認としてのＡＣＫ、ストリーミング配信されるデータが終了したことを明示的に示すＥＯＳ、送信と受信における往復伝播遅延（ＲＴＴ）を計測する際に使用されるＥＣＨＯ、およびＥＣＨＯ−ＲＥＰＬＹのパケットが利用される。これらの各ＲＴＣＰパケットそれぞれのフォーマットタイプを一制御メッセージとして、すなわちＲＴＣＰヘッダのＰＴ（Payload Type）として区別をするのは汎用的ではない。よって、制御メッセージとしては、フィードバックメッセージ（FM：Feedback Message）として定義しＰＴ（Payload Type）に指定する。かつ、ＲＴＣＰヘッダ内の［フォーマット］フィールドであるＦＭＴ (Feedback Message Format)にそのパケットフォーマットの指定をすることで、どのようなフィードバックメッセージかを決定できる構成とする。
【００８６】
図６に示すように、１つのＮＡＣＫパケットには１つ以上の再送要求対象となるパケットの識別子としてのシーケンス番号を付与することができる構成を持つ。つまり一度のＮＡＣＫパケットの送信処理で複数のパケットについての再送要求が可能になる。また、再送要求パケットのシーケンス番号各々に対して付加される「再送回数」は、何回目の再送要求かを明記するフィールドであり、「重複指定回数」は、再送する場合の多重回数の指定を明記するフィールドであり、「オプション」はその他の任意の情報を格納するフィールドとして使用される。
【００８７】
例えば、「重複指定回数」に［３］をいれておけば、ＮＡＣＫを受信したデータ送信側は、同じデータを格納した再送パケットを［３］つ連続で送る処理を実行する。重要データを格納したパケットについては、重複再送を要求することで、再送パケットの受信の確実性を高めることが可能となる。また、繰り返し、同一パケットについての再送要求としてのＮＡＣＫを送信しているにもかかわらず、受信に成功しない場合や、リアルタイム再生に間に合うための再送可能最終時間に出されるＮＡＣＫにおいて、「重複指定回数」の設定数を増加させてデータ送信側に送信することにより、再送パケットの受信の確実性を高めることが可能となり、データ再生品質を向上させることが可能となる。データ受信側は、このようなＮＡＣＫ−ＲＴＣＰパケットを送信して、データ送信側は、受信したＮＡＣＫ−ＲＴＣＰパケットに基づくパケット再送処理を実行する。
【００８８】
なお、ＲＴＰパケットフォーマットやペイロードフォーマット、または受信端末の利用者が意図的に指定した場合など、パケットに優先度が与えられている場合、優先度が高いパケットやデータに関しての再送は多重再送処理を行なうことで、再送パケットの受信確率を高めるようコントロール可能である。また、「再送回数」フィールドにおいて何回目の再送要求かを明記することで、ＮＡＣＫ自身が損失したことを送信側が検知できる。
【００８９】
「オプション」フィールドには、フィールド設定値に従って、例えば図７に示す処理指定を行なうことが可能となる。すなわち、
オプション設定値＝０
指定シーケンス番号を持つパケットのみの再送要求（デフォルト）
オプション設定値＝１
フレーム先頭パケットから指定シーケンス番号を持つパケットまでの一括再送要求
オプション設定値＝２
指定シーケンス番号からフレーム最後尾までのパケットの一括再送要求
オプション設定値＝３
指定タイムスタンプの付与されたパケットの一括再送要求
オプション設定値＝４
タイムスタンプを無視してシーケンス番号のみで検索して検索結果のパケットの再送を要求
【００９０】
画像データ等の符号化データは、先に図２を参照して説明したように、タイムスタンプとシーケンス番号をセットとしたヘッダを持つ１つのＲＴＰパケットに格納した構成を有するが、データ転送処理において、タイムスタンプの変わり目を含んた連続的なエラーとしてのバーストエラーが起こった場合、あるいは、バーストエラーの発生により、フレーム単位でパケットの損失が発生した場合などにおいては、受信端末側では、パケット損失の発生したパケットに対応するタイムスタンプとシーケンス番号のセットを特定できない場合が発生する。このような場合において、特定可能なタイムスタンプ、あるいはシーケンス番号のいずれか一方のみを指定して、上記のオプション設定値を設定することにより、フレキシブルな態様で再送の必要な１以上のパケット指定が可能となる。
【００９１】
このように、データ受信端末では、様々な態様での再送要求パケットの指定が可能であり、ＮＡＣＫ−ＲＴＣＰパケットを受信したデータ送信端末のＡＲＱ処理部１０５は、オプションフィールドの設定値に従って、バッファ１０３に格納済みのパケットから指定パケットを抽出して、再送処理を実行する。
【００９２】
図４に戻り、データ送信端末の処理について説明する。ステップＳ２１２では、ステップＳ２１１で受信したＮＡＣＫ−ＲＴＣＰパケットに指定された再送要求パケットに対応するシーケンス番号を抽出し、ステップＳ２１３では、オプション指定の抽出を実行する。上述したように再送要求パケットの指定態様は、シーケンス番号の直接指定のみならず、タイムスタンプ等による指定等、様々であり、データ送信端末装置のＡＲＱ処理部１０５では、受信したＮＡＣＫ−ＲＴＣＰパケットに指定されたオプション指定、およびタイムスタンプ、シーケンス番号を参照して、再送要求パケットを特定する処理を実行する。
【００９３】
ステップＳ２１４では、特定された再送要求パケットをバッファ１０３から抽出する。バッファ１０３には、再送要求に備えて所定時間、送信済みのパケットが保持格納されており、これらの格納パケットから再送指定のあったパケットを抽出する処理を実行する。ステップＳ２１５で、ＲＴＰパケット出力ポートから抽出パケットが送信される。
【００９４】
ステップＳ２０３において、ＮＡＣＫ−ＲＴＣＰパケットを受信しない場合は、ステップＳ２０４でパケット受信応答としてのＡＣＫ−ＲＴＣＰパケットの受信確認を行ない、ＡＣＫ−ＲＴＣＰパケットの受信に基づいて、ステップＳ２０８で、受信の確認されたパケットをバッファ１０３からクリア（削除）する。このＡＣＫにより、再送要求に対応してパケットを保持する送信側のバッファを能動的に早めにクリアすることが可能となり、バッファ溢れの恐れを低下させることが可能となる。
【００９５】
図８にデータ受信端末において生成し、データ送信端末の受信するパケット受信確認応答であるＡＣＫ−ＲＴＣＰパケットの構成を示す。
【００９６】
ＡＣＫ−ＲＴＣＰパケットは、図８に示すようにヘッダ（ＨＥＡＤ）、フォーマット（ＦＯＲＭＡＴ）、パケットタイプ、パケット長、送信同期ソース識別子（ＲＴＣＰ）、タイムスタンプの情報に加えて、受信パケットの識別子としての受信済みシーケンス番号が格納される。
【００９７】
なお、シーケンス番号を指定せず、タイムスタンプ（TIMESTAMP）のみ指定する構成とすることも可能であり、この場合には、そのタイムスタンプ（TIMESTAMP）の設定されたパケットすべてを受け取った事を示す。よってこのような場合にはシーケンス番号をすべて指定する必要はないため、ＡＣＫ−ＲＴＣＰパケットサイズを小さくすることが可能となり、ネットワークトラフィックの増大を低減できる。
【００９８】
図４に戻り、データ送信端末の処理の説明を続ける。データ送信端末は、ステップＳ２０５において、ＥＣＨＯ−ＲＴＣＰパケットの受信確認を行ない、データ受信端末からＥＣＨＯ−ＲＴＣＰパケットを受信した場合は、ステップＳ２０９において、ＥＣＨＯ−ＲＥＰＬＹ−ＲＴＣＰパケットをＥＣＨＯ−ＲＴＣＰパケットを送信してきたデータ受信端末に対して送信する処理を実行する。
【００９９】
ＥＣＨＯ−ＲＴＣＰパケットと、ＥＣＨＯ−ＲＥＰＬＹ−ＲＴＣＰパケットは、送信端末と受信端末における往復伝播遅延（ＲＴＴ）をデータ受信端末において把握するために用いるＲＴＣＰパケットである。このパケットの送受信によって、データ受信端末において、再送要求を行なってから再送パケットを受信するまでの時間の把握が可能となり、データ受信端末においてリアルタイム再生を行なうために必要な最終再送要求時間を割り出すことが可能なる。
【０１００】
本発明のシステムでは、受信端末のＡＲＱ判定部において、往復伝播遅延（ＲＴＴ）に基づく最終再送要求時間を判定し、判定に基づいて、再送要求としてのＮＡＣＫ−ＲＴＣＰの送信の実行可否を決定する。この判定処理に必要な送信端末と受信端末における往復伝播遅延（ＲＴＴ）の最新情報を取得するため、データ受信端末側は、任意タイミングで、能動的にＥＣＨＯ−ＲＴＣＰパケットをデータ送信端末に送信し、データ送信端末は、ＥＣＨＯ−ＲＴＣＰパケットの受信に応答してＥＣＨＯ−ＲＥＰＬＹ−ＲＴＣＰパケットをＥＣＨＯ−ＲＴＣＰパケットを送信してきたデータ受信端末に対して送信する。
【０１０１】
データ受信端末では、データ送信端末からの応答として受信するＥＣＨＯ−ＲＥＰＬＹ−ＲＴＣＰパケットを解析することによって、送信端末と受信端末における往復伝播遅延（ＲＴＴ）を算出する。このＲＴＴ算出処理については、後段のデータ受信端末の処理の項目で説明する。
【０１０２】
図９にデータ受信端末において生成し、データ送信端末の受信するＥＣＨＯ−ＲＴＣＰパケットの構成、および、データ送信端末において生成し、データ受信端末に対して送信するＥＣＨＯ−ＲＥＰＬＹ−ＲＴＣＰパケットの構成を示す。
【０１０３】
ＥＣＨＯ−ＲＴＣＰパケットは、図９（ａ）に示すようにヘッダ（ＨＥＡＤ）、フォーマット（ＦＯＲＭＡＴ）、パケットタイプ、パケット長、送信同期ソース識別子（ＲＴＣＰ）、およびＥＣＨＯパケットの識別データとしてのＥＣＨＯ−ＩＤが格納される。ＥＣＨＯ−ＲＥＰＬＹ−ＲＴＣＰパケットは、図９（ｂ）に示すようにヘッダ（ＨＥＡＤ）、フォーマット（ＦＯＲＭＡＴ）、パケットタイプ、パケット長、送信同期ソース識別子（ＲＴＣＰ）、およびＥＣＨＯ−ＲＴＣＰパケットに対応するＥＣＨＯ−ＩＤ、および、サーバ処理時間が格納される。
【０１０４】
ＥＣＨＯ−ＩＤをＥＣＨＯ−ＲＴＣＰパケットとＥＣＨＯ−ＲＥＰＬＹ−ＲＴＣＰパケットに入れることにより、データ受信端末側がＥＣＨＯ−ＲＥＰＬＹを受け取った際に、いつ送信したＥＣＨＯ−ＲＴＣＰパケットに対応する返事（ＥＣＨＯ−ＲＥＰＬＹ）かを識別することが可能となる。ＥＣＨＯ−ＲＥＰＬＹ−ＲＴＣＰパケットに格納されるサーバ処理時間は、データ送信端末がデータ受信端末からの再送要求（ＮＡＣＫ−ＲＴＣＰ）を受信してからパケットをデータ送信端末から出力するまでに要する処理時間に相当する時間である。このサーバ処理時間は、ＥＣＨＯ−ＲＴＣＰパケットを受信した時間からＥＣＨＯ−ＲＥＰＬＹ−ＲＴＣＰパケットを送信するまでの時間として設定するか、あるいは、予めデータ送信端末において過去の履歴データとして、実際に、データ送信端末がデータ受信端末からの再送要求（ＮＡＣＫ−ＲＴＣＰ）を受信してからパケットをデータ送信端末から出力するまでに要した時間をメモリに格納し、この格納データを適用してもよいし、あるいは、ＥＣＨＯ−ＲＴＣＰパケットを受信した時点におけるサーバ（データ送信端末）における処理負荷を算出して、処理負荷に基づいて算出される予測処理時間をサーバ処理時間として設定する構成としてもよい。
【０１０５】
データ受信端末は、ＥＣＨＯ−ＲＥＰＬＹ−ＲＴＣＰパケットに格納されたサーバ処理時間と、ＥＣＨＯ−ＲＴＣＰパケット送信からＥＣＨＯ−ＲＥＰＬＹ−ＲＴＣＰの受信までの時間とに基づいて、送信端末と受信端末における往復伝播遅延（ＲＴＴ）を算出する。このＲＴＴ算出処理については、後段のデータ受信端末の処理の項目で説明する。
【０１０６】
図４に戻り、データ送信端末の処理の説明を続ける。データ送信端末は、ステップＳ２０６において、送信対象となるストリーミングデータのパケット送信がすべて終了したかを判定し、終了と判定した場合は、ステップＳ２１０において、データストリームの終了を明示するＥＯＳ（End Of Stream）メッセージを持つＲＴＣＰパケットを受信側端末へ送信する処理を実行する。
【０１０７】
図１０にデータ送信端末において生成し、データ受信端末の受信するＥＯＳ−ＲＴＣＰパケットの構成を示す。
【０１０８】
ＥＯＳ−ＲＴＣＰパケットは、図１０に示すようにヘッダ（ＨＥＡＤ）、フォーマット（ＦＯＲＭＡＴ）、パケットタイプ、パケット長、送信同期ソース識別子（ＲＴＣＰ）、およびタイムスタンプ（ＴＩＭＥＳＴＡＭＰ）が格納される。データ受信端末は、ＥＯＳ−ＲＴＣＰパケットをデータ送信端末から受信することにより、ストリーミング配信されるデータの終了を認識する。受信端末はこの認識処理により、次フレームが到着しないことによる誤ったＮＡＣＫ送出動作を防ぐことができる。
【０１０９】
図４に戻り、データ送信端末の処理の説明を続ける。データ送信端末は、ステップＳ２０７において、予め設定した時間を計測するタイマーでの計測時間が設定時間を超えたか否かを判定して、タイマーが設定時間を超えていない場合は、ステップＳ２０３以下の処理、すなわち、ステップＳ２０３のパケット再送要求としてのＮＡＣＫ−ＲＴＣＰパケットの受信判定処理以下の処理を継続して実行する。これは、全パケット送出後においても、一定時間は、データ受信側からのパケット再送要求としてのＮＡＣＫ−ＲＴＣＰパケット、または、受信確認応答としてのＡＣＫ−ＲＴＣＰパケット、または、ＥＣＨＯ−ＲＴＣＰパケットを受信する可能性があり、これらのパケット受信に対する処理を実行するためである。タイマーにおいて、予め設定した時間が経過した時点で、データ送信を終了する。
【０１１０】
［データ受信端末における処理］
次に、データ受信端末の処理手順を図１１に示すフローチャートを参照して説明する。図１１に示す処理は、図１の受信側端末１２１において実行される処理を説明したフローである。
【０１１１】
データ受信端末は、ステップＳ３００において、データ送信端末からの送信開始通知を受信後、ステップＳ３０１において、データ送信端末からの送信パケット、すなわち符号化データをペイロードとして格納したＲＴＰパケットを順次、受信する。ＲＴＰパケットは、先に、図２を参照して説明したように、タイムスタンプがヘッダ情報中に格納されている。データ受信端末は、タイムスタンプに基づいて受信するパケットに含まれるフレームを判別することができる。先に説明したように、動画像データをＲＴＰパケットに符号化データとして格納して送信する場合、同一の画像フレームに属する複数のＲＴＰパケットには同一のタイムスタンプが設定され、データ受信側端末は、タイムスタンプを参照して、フレームの判別が可能となる。
【０１１２】
データ受信端末は、ステップＳ３０２において、受信したパケットが、ｎフレーム目（ｎ=１，２...）の終端パケットであるか否かを判定する。また、ステップＳ３０３において、受信したパケットが、ｎ＋１フレーム目の先頭パケットであるか否かを判定する。受信したパケットが、ｎフレーム目（ｎ=１，２...）の終端パケットである場合、または、ｎ＋１フレーム目の先頭パケットである場合には、ステップＳ３０９に進む。
【０１１３】
ステップＳ３０９においては、ｎフレーム内に未受信のパケット、すなわちロストパケット、あるいはエラーパケットがあるか否かを判定する。図５を参照して、ステップＳ３０９におけるエラーパケットまたはロストパケットの検出処理について説明する。
【０１１４】
図５は、送信側と受信側で実際にＲＴＰ、ＲＴＣＰパケットのデータ転送が行われている例である。図の右方向に時間が流れているとする。ここでは、９０ＫＨｚクロックで、動画像データについて、３０ｆｐｓ（フレーム／秒）のレートでサンプリングして符号化データをＲＴＰパケットに格納して送信すると仮定している。この場合、ＲＴＰパケットのタイムスタンプの値は、同一画像フレーム内の場合には同じ値になり、９０Ｋ/３０＝３００００ずつカウントアップされる。受信側は、最小刻みタイマτを実装する。この例では、当画像データの圧縮フォーマットとして、MOTION JPEG2000に従った符号化データを伝送しているものとし、フレームにおける最終端パケットが、データ受信端末のＲＴＰパケット解析部１１４にて検知できる。
【０１１５】
図５において、タイムスタンプ１２０００の設定されたパケットは、パケットのシーケンス番号１〜６であり、これらが同一フレーム、例えばフレームｎに属するパケットである。データ受信端末では、シーケンス番号６のパケットを受信した時点で、ステップＳ３０２の判定がＹｅｓとなり、ステップＳ３０９のロストパケット検出処理を実行することになる。この時点で、データ受信端末は、図５に示すようにシーケンス番号１〜３，６のパケットを受信しており、シーケンス番号４，５のロストパケットがあると判定する。なお、ここでは、ロストパケットについてのみ記載しているが、受信したパケットについてのエラーパケットとして範囲された場合についても、ロストパケットと同様の処理、すなわち再送要求を実行することが可能である。
【０１１６】
ロスとパケットまたはエラーパケットが検出されると、ステップＳ３１２以下の処理に進み、再送要求処理としてのＮＡＣＫ−ＲＴＣＰパケットの送信判定処理、および判定に基づくＮＡＣＫ−ＲＴＣＰパケットの送信処理が実行される。これらの判定処理の詳細については、後述する。ここでは、シーケンス番号４，５のロストパケットに関するＮＡＣＫ−ＲＴＣＰパケットが生成され、先に図６を参照して説明したＮＡＣＫ−ＲＴＣＰパケットの再送指定シーケンス番号として４，５を設定したパケットを再送要求パケットとしてデータ送信端末に対して送信する。図５におけるＮＡＣＫ−ＲＴＣＰパケット送信処理５０１がこれに相当する。
【０１１７】
ＮＡＣＫ−ＲＴＣＰパケット送信の際にタイムスタンプ（TIMESTAMP）とシーケンス番号の組み合わせがはっきりしない場合には、先に図７を参照して説明したオプションを指定して送信する。データ受信端末では、パケットの送受信情報を随時記録することで、パケットロス率の割り出しが可能となる。このロス率が一定値以上になった場合には、ＮＡＣＫ−ＲＴＣＰパケット自体の損失の可能性が考えられるため、おなじＮＡＣＫ−ＲＴＣＰパケットを複数回、重ねて送信する処理を行なうことで、再送成功率を高めることが可能となる。あるいは、ＮＡＣＫ−ＲＴＣＰパケットに重複指定回数を増分して設定する。
【０１１８】
データ送信端末は、ＮＡＣＫ−ＲＴＣＰパケットを受信すると、次のタイムスタンプを設定したフレームデータに併せて、再送パケットを送信する。ここでは、タイムスタンプ：１５０００のフレームデータ（シーケンス番号７〜１２）に併せて再送パケット（シーケンス番号４，５）を送信する。なお、再送タイミングは、このように次のフレームデータになるとは限らず、処理タイミングによっては、さらに次のあるいはさらに遅れたフレームデータとともになる場合もある。これらの再送処理タイミングについては、データ受信端末側がＥＣＨＯ−ＲＴＣＰパケット、およびＥＣＨＯ−ＲＥＰＬＹ−ＲＴＣＰの送受信を実行することにより、送信端末と受信端末における往復伝播遅延（ＲＴＴ）を算出して推測可能となる。この処理については、後述する。
【０１１９】
図５において、各フレーム、すなわち、タイムスタンプ＝１２０００〜２４０００…において、その最終パケットまたは先頭パケットをデータ受信端末が受信した場合において、図１１のステップＳ３０２またはステップＳ３０３の判定が、Ｙｅｓとなり、ステップＳ３０９のロストパケット検出処理を実行し、ステップＳ３１２以下の処理に進み、再送要求処理としてのＮＡＣＫ−ＲＴＣＰパケットの送信判定処理、および判定に基づくＮＡＣＫ−ＲＴＣＰパケットの送信処理が実行される。
【０１２０】
ステップＳ３１２の再送要求処理としてのＮＡＣＫ−ＲＴＣＰパケットの送信判定処理について説明する。リアルタイム再生処理を実現するためには、再生タイミングに間に合うように、再送要求パケットが受信端末に届くことが必要となる。ステップＳ３１２の再送要求処理としてのＮＡＣＫ−ＲＴＣＰパケットの送信判定処理は、ＮＡＣＫ−ＲＴＣＰパケットを送信した場合、リアルタイム再生処理に間に合うタイミングで、再送パケットが受信可能か否かを判定するものである。
【０１２１】
この判定のためには、前述したように、送信端末と受信端末間における往復伝播遅延（ＲＴＴ）が重要なパラメータとなる。往復伝播遅延（ＲＴＴ）が大きい場合、データ受信端末からデータ送信端末に対して再送要求を出しても、再送要求を発信して、再送パケットがデータ送信端末から再送され、データ受信端末において受信するまでに時間を要すると、その後デコーダに渡して復号を行なってリアルタイム再生に間に合わない場合が発生する。本発明のシステムでは、データ受信端末において、往復伝播遅延（ＲＴＴ）をあらかじめ把握し、往復伝播遅延（ＲＴＴ）に基づいて、ＮＡＣＫ−ＲＴＣＰパケットの送信判定処理を行なう。
【０１２２】
本発明のシステムにおいては、データ受信端末側が、任意タイミングで、往復伝播遅延（ＲＴＴ）の計測を実行することを可能な構成としている。具体的には、データ受信端末から、先に説明した図９に示すＥＣＨＯ−ＲＴＣＰパケットを送信し、ＥＣＨＯ−ＲＥＰＬＹ−ＲＴＣＰパケットを受信して、ＲＴＴの算出を行なう。
【０１２３】
図１２を参照して、データ受信端末で実行するＥＣＨＯ−ＲＴＣＰパケットの送信、ＥＣＨＯ−ＲＥＰＬＹ−ＲＴＣＰパケットの受信、往復伝播遅延（ＲＴＴ）の算出処理について説明する。
【０１２４】
図１２（ａ）は、ＥＣＨＯ−ＲＴＣＰパケットの送信処理フローである。ＥＣＨＯ−ＲＴＣＰパケットの送信は、データ受信端末が任意タイミングで能動的に実行することが可能である。
【０１２５】
ステップＳ５０１における、ＲＴＣＰパケットの送信待機状態において、ＲＴＴの計測要請が発生した場合、ステップＳ５０２のＥＣＨＯ−ＲＴＣＰパケットの生成処理に移行する。ＲＴＴの計測は、データ受信が開始された後、例えば図１１の処理フローにおいて、ステップＳ３００の送信開始通知を受信した以降、定期的に実行する等の設定が可能であり、データ受信側端末に保有するタイマーで予め定めた計測間隔が経過したか否かを計測し、予め定めた計測間隔に対応する時間が経過した場合に、ＡＲＱ判定部１１９が、ＥＣＨＯ−ＲＴＣＰパケットの生成要求をパケット作成部１１６に出力し、パケット作成部１１６がステップＳ５０２のＥＣＨＯ−ＲＴＣＰパケットの生成処理を実行するなどの設定が可能である。この他にも、パケットのロスト状況を解析し、ロスト状況に応じてＥＣＨＯ−ＲＴＣＰパケットの生成、送信を実行する構成としてもよく、いずれにしても、データ受信端末は、任意タイミングで、ＥＣＨＯ−ＲＴＣＰパケットの生成、送信が可能であり、常に最新の往復伝播遅延（ＲＴＴ）の算出が可能となる。
【０１２６】
ステップＳ５０２で生成するＥＣＨＯ−ＲＴＣＰパケットは、先に図９（ａ）を参照して説明した構成を有する。パケットには、各パケット固有の識別子としてのＥＣＨＯ−ＩＤが設定される。ステップＳ５０３で、生成したＥＣＨＯ−ＲＴＣＰパケットが、ＲＴＣＰ入出力ポート１１３を介して、データ送信端末１０４に対して送信される。ステップＳ５０４では、ＥＣＨＯ−ＲＴＣＰパケットを送信した送信時間、および、パケットに設定されたＥＣＨＯ−ＩＤがメモリに記録される。
【０１２７】
図１２（ｂ）は、ＥＣＨＯ−ＲＥＰＬＹ−ＲＴＣＰパケットの受信およびＲＴＴ算出処理フローである。ステップＳ６０１における、ＲＴＣＰパケットの送信待機状態において、ＥＣＨＯ−ＲＥＰＬＹ−ＲＴＣＰパケットが受信されたと判定（ステップＳ６０２でＹｅｓ）されると、ステップＳ６０３において、ＥＣＨＯ−ＲＥＰＬＹ−ＲＴＣＰパケットの受信時刻がメモリに記録される。受信するＥＣＨＯ−ＲＥＰＬＹ−ＲＴＣＰパケットは、先に図９（ｂ）を参照して説明した構成を有する。パケットには、応答対象となった対応するＥＣＨＯ−ＲＴＣＰパケットと同一の識別子としてのＥＣＨＯ−ＩＤが設定され、さらに、データ送信端末において算出したサーバ処理時間が格納される。
【０１２８】
ステップＳ６０４では、受信したＥＣＨＯ−ＲＥＰＬＹ−ＲＴＣＰパケットからサーバ処理時間が抽出され、ステップＳ６０５において、受信したＥＣＨＯ−ＲＥＰＬＹ−ＲＴＣＰパケットに設定されたＥＣＨＯ−ＩＤから対応するＥＣＨＯ−ＲＴＣＰパケットの送信時間が検索される。
【０１２９】
ステップＳ６０６では、ステップＳ６０３において取得したＥＣＨＯ−ＲＥＰＬＹ−ＲＴＣＰパケットの受信時刻、ステップＳ６０４において取得したサーバ処理時間、ステップＳ６０３において取得したＥＣＨＯ−ＲＴＣＰパケットの送信時間に基づいて、往復伝播遅延（ＲＴＴ）の算出処理が実行される。往復伝播遅延（ＲＴＴ）の算出は、下式に基づいて実行される。
往復伝播遅延（ＲＴＴ）＝(ECHO-REPLAY受信時刻)-(ECHO送信時刻)-(サーバ処理時間)
【０１３０】
なお、ＲＴＴの計測を実行する際に送受信するＥＣＨＯ，ＥＣＨＯ−ＲＥＰＬＹパケットも損失することが考えられる。またＲＴＴもネットワークの状況により常に変動するため、データ受信端末は一定間隔でＥＣＨＯ，ＥＣＨＯ−ＲＥＰＬＹパケットの送受信処理を実行してＲＴＴを計測する。
【０１３１】
図１１のフローに戻り、データ受信端末側の処理について説明を続ける。図１１のフローにおいて、ステップＳ３１２では、再送要求としてのＮＡＣＫ−ＲＴＣＰを出力した場合、リアルタイム再生処理に間に合うタイミングで再送要求パケットの受信が可能か否かを判定する。上述したＥＣＨＯ，ＥＣＨＯ−ＲＥＰＬＹパケットの送受信処理により計測されたＲＴＴ値と、各フレームの処理タイミングを計測しているタイマーの期限に基づいて、再送要求としてのＮＡＣＫ−ＲＴＣＰパケットを出しても間に合わないと判断した場合（Ｓ３１２でＮｏ）には、ＮＡＣＫ−ＲＴＣＰパケットの送信処理は実行しない。
【０１３２】
たとえば、パケット損失の存在する該当フレームの符号化データの処理開始までの時間Ｔａ＝１００ｍｍｓｅｃである場合、すなわち１００ｍｍｓｅｃ後にデコーダにデータを渡して復号処理が開始されることがタイマーの計測により明らかとなっている場合、計測された最新のＲＴＴ値が、該当フレームの符号化データの処理開始までの時間Ｔａより大きい値であった場合、すなわち、１００ｍｍｓｅｃ以上であった場合には、再送要求としてのＮＡＣＫ−ＲＴＣＰパケットを送信しても、再送パケットの受信が、デコード処理開始タイミングに間に合わないものと判断して、ＮＡＣＫ−ＲＴＣＰパケットの送信処理を実行しない。ただし、ＲＴＴ値が処理開始までの時間Ｔａ以上であっても、ＲＴＴ値と時間：Ｔａの非常に近い値を持つ場合には、ぎりぎり間に合う可能性もあるためＮＡＣＫを送出する構成としてもよい。このＮＡＣＫ送出判定の閾値は実装依存である。
【０１３３】
一方、計測された最新のＲＴＴ値が、パケット損失の存在する該当フレームの符号化データの処理開始までの時間Ｔａ以下であった場合には、再送要求としてのＮＡＣＫ−ＲＴＣＰパケットを送信して再送パケットを受信するまでの時間が、デコード処理開始タイミングまでの時間以下であるので、再送パケット受信が処理に間に合うものと判断して、ステップＳ３１３において、ＮＡＣＫ−ＲＴＣＰパケットの送信処理を実行する。
【０１３４】
ステップＳ３０９のロストパケットの検出処理は、ステップＳ３０２の各フレームの終端パケット受信、ステップＳ３０３の各フレームの先頭パケット受信時のみではなく、ステップＳ３０４の各フレームの最終再送時間の判定でＹｅｓの場合、およびステップＳ３０５のタイマーの最小計測時間τの経過判定でＹｅｓの場合に実行される。
【０１３５】
図５を参照して、ステップＳ３０４の各フレームの最終再送時間の判定処理、およびステップＳ３０５のタイマーの最小計測時間τの経過判定処理について説明する。
【０１３６】
ステップＳ３０４の各フレームの最終再送時間の判定処理は、再送要求としてのＮＡＣＫ−ＲＴＣＰを出力した場合、リアルタイム再生処理に間に合う最終時間判定処理である。各フレームについて、各フレームの符号化データの処理開始までの時間Ｔａが計測されているＲＴＴ値と等しくなったとき、すなわち、Ｔａ＝ＲＴＴとなった場合に、ステップＳ３０４の判定がＹｅｓとなり、ステップＳ３０９の該当フレームに対するロストパケットの検出処理が実行される。これは、最後の再送要求可能タイミングにロストパケットを検出して、検出された場合に最後の再送要求を送信するための処理である。
【０１３７】
図５において、右下部に示してあるように、タイムスタンプ＝１２０００の処理開始までの時間Ｔａ＝ＲＴＴとなったとき、ステップＳ３０４において、タイムスタンプ＝１２０００に対応するフレームについての最終再送時間の判定処理がＹｅｓと判定され、ステップＳ３０９において、タイムスタンプ＝１２０００のフレームに対するロストパケットの検出処理が実行され、ロストパケットが検出された場合に、ステップＳ３１３において最後の再送要求を送信する。図５におけるＮＡＣＫ−ＲＴＣＰパケット送信処理５０５がこれに相当する。
【０１３８】
ステップＳ３０５のタイマーの最小計測時間τの経過判定処理は、データ受信端末の有するタイマーの計測最小時間：τ毎に、ステップＳ３０５の判定がＹｅｓとなり、ステップＳ３０９の該当フレームに対するロストパケットの検出処理が実行される。これは、各計測最小時間：τに対応する受信フレームについて、各フレームの先頭パケット、最終パケットの検出がなされない場合でもロストパケットを確実に検出して、再送要求を実行しようとするための処理である。図５におけるＮＡＣＫ−ＲＴＣＰパケット送信処理５０２，５０３がこれに相当する。
【０１３９】
図５におけるＮＡＣＫ−ＲＴＣＰパケット送信処理５０２は、そのタイミングまでに受信済みのタイムスタンプのフレームを構成するパケット中のロストパケットとして、パケット（シーケンス番号＝５，１２）を抽出し、シーケンス番号５，１２のロストパケットに関するＮＡＣＫ−ＲＴＣＰパケットが生成され、先に図６を参照して説明したＮＡＣＫ−ＲＴＣＰパケットの再送指定シーケンス番号として５，１２を設定したパケットを再送要求パケットとしてデータ送信端末に対して送信する。なお、シーケンス番号５の再送要求は、２回目となるので、ＮＡＣＫ−ＲＴＣＰパケットのシーケンス番号５に対応する「再送回数」フィールドには、［２］が設定される。
【０１４０】
図５におけるＮＡＣＫ−ＲＴＣＰパケット送信処理５０３は、そのタイミングまでに受信済みのタイムスタンプのフレームを構成するパケット中のロストパケットとして、パケット（シーケンス番号＝５）を抽出し、シーケンス番号５のロストパケットに関するＮＡＣＫ−ＲＴＣＰパケットを生成して送信する。なお、シーケンス番号５の再送要求は、３回目となるので、ＮＡＣＫ−ＲＴＣＰパケットのシーケンス番号５に対応する「再送回数」フィールドには、［３］が設定される。
【０１４１】
このように、データ受信端末では、ステップＳ３０２の各フレームの終端パケット受信、ステップＳ３０３の各フレームの先頭パケット受信時、ステップＳ３０４の各フレームの最終再送時間の判定、およびステップＳ３０５のタイマーの最小計測時間τの経過判定の各タイミングにおいて、ステップＳ３０９のロストパケットの検出処理を実行する。なお、これらステップＳ３０２〜Ｓ３０５の４種類のタイミングのいずれかのみを実行する構成としてもよい。
【０１４２】
ステップＳ３０９の各フレームのロストパケット検出処理において、ロストパケットが検出されなかった場合は、各パケットに格納された符号化データのデコード（復号）処理がデコーダ１２０において実行される。ステップＳ３１１では、受信済みパケットについての受信確認パケットとしてのＡＣＫ−ＲＴＣＰパケットの生成、送信が行われる。ＡＣＫ−ＲＴＣＰパケットは、先に図８を参照して説明した通り、受信済みシーケンス番号を格納したパケットである。このＡＣＫ−ＲＴＣＰパケットを受信したデータ送信端末は、ＡＣＫ−ＲＴＣＰパケットに記録された受信済みシーケンス番号に対応するパケットをバッファ１０３からクリアする。
【０１４３】
図５のタイムシーケンス図では、受信端末から送信端末へのＡＣＫ−ＲＴＣＰパケットの送信は、タイムスタンプ＝１５０００のフレームデータに関しては、ＡＣＫ−ＲＴＣＰパケット送信処理５１１において実行され、タイムスタンプ＝１８０００のフレームデータに関しては、ＡＣＫ−ＲＴＣＰパケット送信処理５１２において実行され、タイムスタンプ＝２１０００のフレームデータに関しては、ＡＣＫ−ＲＴＣＰパケット送信処理５１３において実行されている。
【０１４４】
図１１に示すフローのステップＳ３０６では、各フレームのタイマー期限切れを確認する。このタイマー期限は、リアルタイム再生処理の開始期限を計測するタイマーによって設定される期限であり、各フレーム毎にそのタイミングが設定される。ｎフレームのタイマー期限切れであると判定された場合には、ロストパケットがあった場合であっても、ステップＳ３１０のデコード処理に移行することになる。
【０１４５】
ステップＳ３０７では、データ送信端末から、データストリームの終了を明示するＥＯＳ（End Of Stream）メッセージを持つＲＴＣＰパケットを受信したか否かを判定し、ＥＯＳ−ＲＴＣＰパケット受信でない場合は、ステップＳ３０１以下の処理を繰り返す。
【０１４６】
ＥＯＳ−ＲＴＣＰパケット受信である場合は、ステップＳ３０８において、各フレームのタイマー期限切れを確認する。このタイマー期限は、リアルタイム再生処理の開始期限を計測するタイマーによって設定される期限であり、各フレーム毎にそのタイミングが設定される。タイマー期限切れでない場合は、ステップＳ３１４に進み、再送要求されているロストパケットに関する再送パケットを受信待機状態であるか否かを判定して、待機状態である場合は、ステップＳ３１５に進み、再送パケットの受信待機状態として、ステップＳ３０１のパケット受信以下の処理を実行する。
【０１４７】
ステップＳ３０８における各フレームのタイマー期限切れの確認処理において、Ｙｅｓと判定された場合、および、ステップＳ３１４において、再送パケット受信待機状態でないと判定された場合は、デコード、再生処理へ移行すべき未受信のパケットデータは存在しないと判定され、受信処理を完了する。
【０１４８】
このように、本発明のシステムにおいては、リアルタイム配信に適するものの信頼性を保証しないＲＴＰ等のデータ通信プロトコルに従ったパケット伝送において、ＡＲＱ機能を付加することで、エラー耐性のある信頼性の高いデータ伝送、リアルタイム再生が可能となる。なお、上述の実施例では、ＲＴＰパケットに符号化データを格納する構成例を中心として説明したが、ＲＴＰパケットフォーマットに限らず、ＵＤＰ等、他のデータ通信プロトコルフォーマットに従ったパケットを用いたデータ通信構成においても、上述の実施例と同様の各種のコントロールパケットを用いた再送要求処理を行なうことにより、上述の実施例と同様の構成を実現可能である。
【０１４９】
上述したように本発明の構成では、再送要求の処理タイミングとして、各フレームの先頭パケットの受信時、各フレームの最終パケットの受信時、最終処理期限、および一定間隔（τ）毎等の各種タイミングでロストパケットの検出処理を実行する構成としたので、確実なロストパケットの検出が可能となる。
【０１５０】
また、データ受信端末は、再生処理時間、伝播遅延時間ＲＴＴを考慮したデータ再送要求処理を実行するので、無駄な再送要求パケットおよび再送パケットを出すことを防ぐ事ができ、ネットワークの帯域を再送によって狭めることがない。また、データ受信端末が、パケットの送受信情報を随時記録し、パケットロス率の割り出しにより、ロス率が一定値以上になった場合、おなじＮＡＣＫ−ＲＴＣＰパケットを複数回、重ねて送信することで、再送成功率を高めることが可能となる。
【０１５１】
また、受信端末において送信する再送要求としてのＮＡＣＫ−ＲＴＣＰパケットに重複指定回数の設定を可能としたので、ネットワーク状況に応じて、また受信側の要求に応じて再送パケットの重複送信を要求することが可能となり、重要データの受信成功率を高めることが可能となる。例えば、再生に間に合うための最終的な再送パケットについて重複再送を要求することで、高品質なデータ再生が可能となる。
【０１５２】
また、データ受信端末側から受信パケットに関するＡＣＫメッセージを、例えば画像のフレーム毎、またはあるブロック毎に応じて送信側に送信する構成としたので、パケット毎のＡＣＫ送信による帯域の寡占状態の発生が防止され、また、データ送信側は、データ受信側から受信するＡＣＫパケットに基づいて、再送処理のためのパケット格納バッファから、該当パケットを能動的に破棄でき、バッファ溢れ、バッファ欠如を防ぐことができる。
【０１５３】
［データ送受信端末装置構成例］
上述の実施例で述べた一連の処理は、ハードウェア、またはソフトウェア、あるいは両者の複合構成によって実行することが可能である。ソフトウェアによる処理を実行する場合は、処理シーケンスを記録したプログラムを、専用のハードウェアに組み込まれたデータ処理装置内のメモリにインストールして実行させるか、あるいは、各種処理が実行可能な汎用コンピュータにプログラムをインストールして実行させることが可能である。一連の処理をソフトウェアによって行う場合には、そのソフトウェアを構成するプログラムが、例えば汎用のコンピュータやマイクロコンピュータ等にインストールされる。
【０１５４】
図１３に、上述の実施例で述べた一連の処理を実行するデータ送信端末装置、データ受信端末装置のシステム構成例を示す。本発明のシステムで送受信されるデータは、符号化データであり、データ送信装置ではエンコード（符号化）処理が実行され、データ受信装置ではデコード（復号）処理が実行される。符号化されたデータはパケットとしてネットワークを介して送受信する。そのため、データ送信側では、パケット生成（パケタイズ処理）を実行し、データ受信側ではパケット展開（デパケタイズ処理）を実行する。
【０１５５】
図１３に示すデータ送受信装置（ｅｘ．ＰＣ）８５０は、エンコード（符号化）処理、デコード（復号）処理を実行するとともにパケット生成、展開処理を実行するコーデック８５１、通信ネットワークとのインタフェースとして機能するネットワークインタフェース８５２、マウス８３７、キーボード８３６等の入力機器との入出力インタフェース８５３、ビデオカメラ８３３、マイク８３４、スピーカ８３５等のＡＶデータ入出力機器からのデータ入出力を行なうＡＶインタフェース８５４、ディスプレイ８３２に対するデータ出力インタフェースとしてのディスプレイ・インタフェース８５５、各データ入出力インタフェース、コーデック８５１、ネットワークインタフェース８５２間のデータ転送制御、その他各種プログラム制御を実行するＣＰＵ８５６、ＣＰＵ８５６により制御実行される各種プログラムの格納、データの格納、ＣＰＵ８５６のワークエリアとして機能するＲＡＭ、ＲＯＭからなるメモリ８５７、データ格納、プログラム格納用の記憶媒体としてのＨＤＤ８５８を有し、それぞれＰＣＩバス８５９に接続され、相互のデータ送受信が可能な構成を持つ。
【０１５６】
コーデック８５１は、図１３に示すように、例えばビデオカメラ８３３からの画像データ、マイク８３４からの音声データを入力し、符号化処理、パケット生成処理（パケタイズ）を実行し、最終的に符号化データをペイロードとしたパケットを生成する。生成されたパケットは、ＰＣＩバス８５９上に出力され、ネットワークインタフェース８５２を介してネットワークに出力され、パケットのヘッダに設定された宛先アドレスに配信される。
【０１５７】
また、ＨＤＤ８５８またはメモリ８５７に格納されたソフトウェアエンコードプログラムに従ってＣＰＵ８５６の制御により、ビデオカメラ８３３からの画像データ、マイク８３４からの音声データを符号化してネットワークインタフェース８５２を介してネットワークに出力する処理も実行する構成としてもよい。
【０１５８】
一方、ネットワークを介して入力するＩＰパケット化されたデータは、ネットワークインタフェース８５２を介して、バス８５６上に出力されて、コーデック８５１に入力される。コーデック８５１では入力データのパケット展開処理（デパケタイズ）を実行し、ペイロードとして格納された符号化データを抽出後、復号処理を実行して、ディスプレイ８３２、スピーカ８３５において再生、出力する。
【０１５９】
上述の実施例における処理対象となる画像等のデータは、カメラ他の入力機器、例えばスキャナ等のデータ入力装置、あるいはフロッピーディスク、ＣＤ−ＲＯＭ(Compact Disc Read Only Memory)，ＭＯ(Magneto optical)ディスク，ＤＶＤ(Digital Versatile Disc)、磁気ディスク、半導体メモリなどのリムーバブル記録媒体から入力可能である。
【０１６０】
また、ＣＰＵ８５６は、ＲＯＭ格納プログラムに限らず、ハードディスクに格納されているプログラム、衛星若しくはネットワークから転送され、受信されてインストールされたプログラム等を、ＲＡＭ(Random Access Memory)等のメモリにロードして実行することも可能である。
【０１６１】
ここで、本明細書において、プログラムは、１つのコンピュータにより処理されるものであっても良いし、複数のコンピュータによって分散処理されるものであっても良い。さらに、プログラムは、遠方のコンピュータに転送されて実行されるものであっても良い。
【０１６２】
以上、特定の実施例を参照しながら、本発明について詳解してきた。しかしながら、本発明の要旨を逸脱しない範囲で当業者が該実施例の修正や代用を成し得ることは自明である。すなわち、例示という形態で本発明を開示してきたのであり、限定的に解釈されるべきではない。本発明の要旨を判断するためには、冒頭に記載した特許請求の範囲の欄を参酌すべきである。
【０１６３】
【発明の効果】
以上、説明してきたように、本発明の構成によれば、ＲＴＰ、ＵＤＰ等のデータ通信プロトコルに従ったパケット送信において、ＡＲＱ機能を付加し、再送要求の処理タイミングとして、各フレームの先頭パケットの受信時、各フレームの最終パケットの受信時、最終処理期限、および一定間隔（τ）毎等の各種タイミングでロストパケットの検出処理を実行し、再送要求を実行する構成としたので、確実なロストパケットの検出が可能となり、エラー耐性のある信頼性の高いデータ伝送、リアルタイム再生が可能となる。
【０１６４】
また、本発明の構成によれば、データ受信端末において、再生処理時間、伝播遅延時間ＲＴＴを考慮し、デコード処理等を含む再生処理に間に合わない場合には、再生要求パケットの送信を実行しない構成としたので、無駄な再送要求パケットおよび再送パケットを出すことを防ぐ事ができ、ネットワークの帯域を再送処理の多発によって狭めてしまうことを防止することが可能となる。
【０１６５】
また、本発明の構成において、データ受信端末でパケットの送受信情報を随時記録しパケットロス率の割り出しを可能とした構成においては、データ受信端末の検出したロス率が一定値以上になった場合に、データ受信端末が能動的におなじＮＡＣＫパケットを複数回、重ねて送信する処理を行なうことで、再送成功率を高めることが可能となる。
【０１６６】
また、本発明の構成において、受信端末において送信する再送要求としてのＮＡＣＫパケットに重複指定回数の設定を可能としたため、ネットワーク状況に応じて、また受信側の要求に応じて再送パケットの重複送信を要求することが可能となり、重要データの受信成功率を高めることが可能となる。特に、再生時間に間に合うための最終的な再送パケットにおいては、そのパケットが万が一損失した場合には、データ不完全のまま再生することになるため、受信側から重複再送を要求し、再送成功率を高めることで高品質なデータ再生が可能となる。
【０１６７】
また、本発明の構成において、データ受信端末側から受信パケットに関するＡＣＫメッセージを、画像のフレーム毎、ブロック毎等、パケット単位ではなく複数パケット毎に送信する構成とすることで、ＡＣＫパケットによる帯域の寡占状態の発生を防止し、また、データ送信側では、データ受信側から受信するＡＣＫパケットに基づいて、再送処理のためのパケット格納バッファから、該当パケットを能動的に破棄でき、バッファ溢れ、バッファ欠如を防ぐことが可能となる。
【図面の簡単な説明】
【図１】本発明のデータ通信システムの構成を示す図である。
【図２】本発明のデータ通信システムにおいて転送されるＲＴＰパケットフォーマットを示す図である。
【図３】本発明のデータ通信システムにおいて転送されるＩＰパケットヘッダフォーマットを示す図である。
【図４】本発明のデータ通信システムにおけるデータ送信端末の処理フローを示す図である。
【図５】本発明のデータ通信システムにおけるデータ送信端末およびデータ受信端末のデータ通信処理を説明するタイムシーケンス図である。
【図６】本発明のデータ通信システムにおいて転送されるＮＡＣＫ−ＲＴＣＰパケットフォーマットを示す図である。
【図７】本発明のデータ通信システムにおいて転送されるＮＡＣＫ−ＲＴＣＰパケットにおけるオプション値の機能について説明する図である。
【図８】本発明のデータ通信システムにおいて転送されるＡＣＫ−ＲＴＣＰパケットフォーマットを示す図である。
【図９】本発明のデータ通信システムにおいて転送されるＥＣＨＯ−ＲＴＣＰ、およびＥＣＨＯ−ＲＥＰＬＹ−ＲＴＣＰパケットフォーマットを示す図である。
【図１０】本発明のデータ通信システムにおいて転送されるＥＯＳ−ＲＴＣＰパケットフォーマットを示す図である。
【図１１】本発明のデータ通信システムにおけるデータ受信端末の処理フローを示す図である。
【図１２】本発明のデータ通信システムにおけるデータ受信端末のＥＣＨＯ−ＲＴＣＰ、およびＥＣＨＯ−ＲＥＰＬＹ−ＲＴＣＰパケットを適用したＲＴＴ計測処理フローを示す図である。
【図１３】データ送信端末装置およびデータ受信端末装置のシステム構成例を示す図である。
【符号の説明】
１０１ ビデオカメラ
１０２ エンコーダ
１０３ バッファ
１０４ 送信側端末
１０５ ＡＲＱ処理部
１０６ ＲＴＰパケット作成部
１０７ ＲＴＣＰパケット作成部
１０８ ＲＴＣＰパケット解析部
１０９ ＲＴＣＰ入出力ポート
１１０ ＲＴＰパケット出力ポート
１１１ ＩＰネットワーク
１１２ ＲＴＰパケット入力ポート
１１３ ＲＴＣＰ入出力ポート
１１４ ＲＴＰパケット解析部
１１５ ＲＴＣＰパケット解析部
１１６ ＲＴＣＰパケット作成部
１１６ ＡＲＱ判定部
１１７ バッファ
１１８ インデックスリスト
１１９ ＡＲＱ判定部
１２０ デコーダ
８０９ ＰＣＩバス
８３２ ディスプレイ
８３３ ビデオカメラ
８３４ マイク
８３５ スピーカ
８３７ マウス
８３８ キーボード
８５０ データ送受信装置
８５１ コーデック
８５２ ネットワークインタフェース
８５３ 入出力インタフェース
８５４ ＡＶインタフェース
８５５ ディスプレイインタフェース
８５６ ＣＰＵ
８５７ メモリ
８５８ ＨＤＤ
【発明の属する技術分野】
本発明は、データ通信システム、データ送信装置、データ受信装置、および方法、並びにコンピュータ・プログラムに関する。さらに詳細には、ストリーミングデータ転送におけるエラー耐性を高めたパケット送信構成を持つデータ通信システム、データ送信装置、データ受信装置、および方法、並びにコンピュータ・プログラムに関する。
【０００２】
【従来の技術】
昨今、インターネット通信など、様々な通信媒体を介した画像、音声データ等のデータ転送が盛んに行われている。特に、近年においては、インターネット上のデータ転送において、従来から利用されているダウンロード型伝送方式に加えて、ストリーム型伝送方式によるサービスが増加してきている。ダウンロード型伝送方式においては、映像ファイルや音声ファイルといったマルチメディアデータを伝送する場合、配信サーバからデータファイルを一旦受信側端末の記憶媒体にダウンロードして、その後、記憶媒体から再生することになる。よって、この方式ではファイルを完全に転送が終わるまでは再生できず、長時間再生やリアルタイム再生などには不向きである。
【０００３】
一方、後者のストリーム型伝送方式では、送信側から受信端末にデータ転送が行われている間に、並列して受信データの再生処理を実行するものであり、インターネット電話・遠隔テレビ会議・ビデオオンデマンドといったインターネットサービスに利用されている。
【０００４】
ストリーム型伝送方式は、例えば画像データのＭＰＥＧ圧縮処理により生成されるＭＰＥＧストリームをＩＰ（Internet Protocol）パケットに格納してインターネット上を転送させて、ＰＣやＰＤＡ、携帯電話等の各通信端末において受信するシステム等において使用され、開発が進んでいる。このような技術は、ビデオオンデマンドやライブ映像のストリーミング配信、あるいはビデオ会議、テレビ電話などのリアルタイム通信において有効となる。
【０００５】
このようなストリーム型伝送方式に適したインターネット技術に、IETF RFC1889で規定されているプロトコル：ＲＴＰ(Realtime Transport Protocol)がある。ＲＴＰに従ったデータ転送では、時間情報としてパケットにタイムスタンプを付加し、タイムスタンプの参照により送信側と受信側の時間的関係の把握を行ない、データ受信側において、パケット転送の遅延ゆらぎ（ジッター）などの影響を受けずに同期をとった再生を可能としている。
【０００６】
ただし、ＲＴＰは実時間のデータ転送を保証しているものではない。パケット配送の優先度や設定、管理などはＲＴＰが提供するトランスポートサービスの範疇ではないため、ＲＴＰパケットは、他のパケットと同様、ネットワーク上での配送遅延やパケット損失がおきる可能性がある。しかし、このような事態が起こっても、受信側は期待する時間内に到着したパケットだけを利用してデータを再生することが可能である。これは、映像や音声データが多少のデータ欠損があったとしても、データ品質を落とした再生、あるいはデータ補正処理による再生が可能となるからである。
【０００７】
なお、再生に間に合わず遅延配送されたパケットやエラーの発生したパケットは、受信側でそのまま破棄される。つまり、パケット損失やエラーが発生した場合は、高品質なデータ配信処理を行なっている場合でも、受信側で品質を保持した再生が実行されないという問題点がある。特に、有線区間で１０−５、無線区間で１０−３以上のエラーがあるといわれている中では、配信するメディアの品質保持を考慮すると、ＲＴＰをそのまま利用したデータ転送には問題がある。
【０００８】
このようなＲＴＰに従ったデータ転送における問題点を解決する１つの案としては、データ転送に信頼性が高いデータ転送プロトコルであるＴＣＰに従ってパケットの再送要求および再送パケット送信を行わせる方法が考えられる。しかし、ＴＣＰはエラーには強いが、スループットが低く、遅延が大きいため、再送しても再生時間に間に合わない可能性があり、リアルタイム通信の実現を困難とするという問題がある。
【０００９】
さらに、パケットエラー等に対応するエラー訂正手法として、例えばＦＥＣ（Forward Error Correction）という手段が考えられている。これは誤り訂正を行うためのＦＥＣデータを冗長データとして送信して、エラーが発生した場合には、データ受信側において、このＦＥＣデータをもとにエラーの修復を実行しようとするものである。先のＡＲＱによるパケット再送処理に比べると再送にかかる遅延がない分、遅延時間を低く抑えられるが、冗長データを付加するためにスループットが低下するという問題がある。また、ネットワーク状況に合わせた最適な付加ＦＥＣデータを決定するのは難しく、処理時間のオーバーヘッドが常につきまとうなどの問題が存在する。
【００１０】
【発明が解決しようとする課題】
本発明は、上述の問題点に鑑みてなされたものであり、ビデオオンデマンドや、遠隔テレビ会議のような、リアルタイム再生が望まれるデータ転送処理を効率的に実行可能とかるとともに、パケット損失等のエラー発生時にも品質の低下を抑えて高品質なデータ再生を実現するデータ通信システム、データ送信装置、データ受信装置、および方法、並びにコンピュータ・プログラムを提供することを目的とする。
【００１１】
【課題を解決するための手段】
本発明の第１の側面は、
データ送信装置およびデータ受信装置からなり、ストリーム型データ転送を実行するデータ通信システムであり、
データ送信装置は、
送信データを格納したデータパケットを送信するパケット送信処理部と、
データ受信装置から受信する再送要求メッセージパケットに従って再送すべきデータパケットの抽出処理を実行する再送制御部とを有し、
データ受信装置は、
前記データ送信装置から受信するデータパケットを受信するパケット受信処理部と、
前記データ送信装置から受信するデータパケットのエラーまたはロスト・データパケットの検出に基づいて、前記データ送信装置に対するデータパケット再送要求としての再送要求メッセージパケットの送信可否を判定する再送要求処理制御部とを有し、
前記再送要求処理制御部は、
再送要求に基づく再送データパケット受信が、再送データパケット格納データの再生に伴う処理開始時間前に可能か否かを判定し、可能であるとの判定を条件として、前記再送要求メッセージの送信処理を実行すると共に、
再送データパケット受信が、再送データパケット格納データの再生に伴う処理開始時間前に可能となる予め計測済みの最終期限において、最終的なロスト・データパケットの検出処理を実行し、前記最終期限においてロスト・データパケットの検出がなされた場合には、最終的な前記再送要求メッセージの送信処理を実行する構成を有することを特徴とするデータ通信システムにある。
【００２５】
さらに、本発明の第２の側面は、
ストリーム型データ受信を実行するデータ受信装置であり、
データ送信装置から受信するデータパケットを受信するパケット受信処理部と、
前記データ送信装置から受信するデータパケットのエラーまたはロスト・データパケットの検出に基づいて、前記データ送信装置に対するデータパケット再送要求としての再送要求メッセージパケットの送信可否を判定する再送要求処理制御部とを有し、
前記再送要求処理制御部は、
再送要求に基づく再送データパケット受信が、再送データパケット格納データの再生に伴う処理開始時間前に可能か否かを判定し、可能であるとの判定を条件として、前記再送要求メッセージの送信処理を実行すると共に、
再送データパケット受信が、再送データパケット格納データの再生に伴う処理開始時間前に可能となる予め計測済みの最終期限において、最終的なロスト・データパケットの検出処理を実行し、前記最終期限においてロスト・データパケットの検出がなされた場合には、最終的な前記再送要求メッセージの送信処理を実行する構成を有することを特徴とするデータ受信装置にある。
【００２６】
さらに、本発明のデータ受信装置の一実施態様において、前記データ・パケットの格納データは、符号化データであり、前記再送要求処理制御部は、再送要求に基づく再送データパケット受信が、再送データパケット格納データの復号処理を含む再生に伴う処理開始時間前に可能か否かを判定する構成であることを特徴とする。
【００２７】
さらに、本発明のデータ受信装置の一実施態様において、前記データ受信装置は、再送要求データパケットの識別データとしてのシーケンス番号と、該シーケンス番号に対応するデータパケットの重複再送の指定回数データを格納した再送要求メッセージパケットを生成して前記データ送信装置に送信する構成を有することを特徴とする。
【００２８】
さらに、本発明のデータ受信装置の一実施態様において、前記データ受信装置の受信するデータパケットは、動画像データであり、前記再送要求処理制御部は、動画像データの１画像フレームの構成データを格納した複数のデータパケットの終端データパケットの受信に応じて、該終端データパケットの属する画像フレームの構成データを格納した複数のデータパケット中のエラーまたはロスト・データパケットの検出処理を実行する構成であることを特徴とする。
【００２９】
さらに、本発明のデータ受信装置の一実施態様において、前記データ受信装置の受信するデータパケットは、動画像データであり、前記再送要求処理制御部は、動画像データの１画像フレームの構成データを格納した複数のデータパケットの先頭データパケットの受信に応じて、該先頭データパケットの属する画像フレームの前フレームの構成データを格納した複数のデータパケット中のエラーまたはロスト・データパケットの検出処理を実行する構成であることを特徴とする。
【００３０】
さらに、本発明のデータ受信装置の一実施態様において、前記再送要求処理制御部は、データパケット格納データの再生処理開始時間に間に合うための再送要求最終期限に基づいて、受信データパケット中のエラーまたはロスト・データパケットの検出処理を実行する構成であることを特徴とする。
【００３１】
さらに、本発明のデータ受信装置の一実施態様において、前記再送要求処理制御部は、定期的な時間間隔に基づいて、受信データパケット中のエラーまたはロスト・データパケットの検出処理を実行する構成であることを特徴とする。
【００３２】
さらに、本発明のデータ受信装置の一実施態様において、前記再送要求処理制御部は、前記データ送信装置とデータ受信装置における往復伝播遅延（ＲＴＴ）の計測処理のために前記データ送信装置に対するエコーパケットの送信および該エコーパケットに対するエコーリプライパケットの受信処理制御を実行し、該エコーパケットに基づいて算出する往復伝播遅延（ＲＴＴ）に基づいて、再送要求に基づく再送データパケット受信が、再送データパケット格納データの再生処理開始時間前に可能か否かを判定する構成を有することを特徴とする。
【００３３】
さらに、本発明のデータ受信装置の一実施態様において、前記データ受信装置は、再送要求データパケットの識別データとしてのシーケンス番号、またはパケットの属するタイムスタンプ指定データの少なくともいずれかと、再送要求範囲を指定するオプションを格納した再送要求メッセージパケットを生成して前記データ送信装置に送信する構成を有することを特徴とする。
【００３４】
さらに、本発明のデータ受信装置の一実施態様において、前記データパケットは、データ転送プロトコルとしてのＲＴＰに従ったフォーマットを有し、前記再送要求は、制御プロトコルとしてのＲＴＣＰに従ったフォーマットを有することを特徴とする。
【００３５】
さらに、本発明のデータ受信装置の一実施態様において、前記データ受信装置は、複数のデータパケットに関する再送要求を１つの再送要求メッセージパケットとしてデータ送信装置に対して送信する構成であることを特徴とする。
【００３６】
さらに、本発明のデータ受信装置の一実施態様において、前記データ受信装置は、複数のデータパケットに関する受信確認を１つの受信確認メッセージパケットとしてデータ送信装置に対して送信する構成であることを特徴とする。
さらに、本発明の第３の側面は、
ストリーム型データ受信を実行するデータ受信装置であり、
データ送信装置から受信するデータパケットを受信するパケット受信処理部と、
前記データ送信装置から受信するデータパケットのエラーまたはロスト・データパケットの検出に基づいて、前記データ送信装置に対するデータパケット再送要求としての再送要求メッセージパケットの送信可否を判定する再送要求処理制御部とを有し、
前記再送要求処理制御部は、
再送要求に基づく再送データパケット受信が、再送データパケット格納データの再生に伴う処理開始時間前に可能か否かを判定し、可能であるとの判定を条件として、前記再送要求メッセージパケットの送信処理を実行し、当該送信処理に際して、前記データパケット受信時におけるパケットロス率に基づいて前記再送要求メッセージパケットの送信回数を変化させ、パケットロス率が一定値以上になった場合は、前記再送要求メッセージパケットの送信回数を増加させる処理を行なう構成を有すると共に、
データパケット格納データの再生処理開始時間に間に合うための再送要求最終期限に基づいて、受信データパケット中のエラーまたはロスト・データパケットの検出処理を実行する構成を有することを特徴とするデータ受信装置にある。
さらに、本発明の第４の側面は、
ストリーム型データ受信を実行するデータ受信装置であり、
データ送信装置から受信するデータパケットを受信するパケット受信処理部と、
前記データ送信装置から受信するデータパケットのエラーまたはロスト・データパケットの検出に基づいて、前記データ送信装置に対するデータパケット再送要求としての再送要求メッセージパケットの送信可否を判定する再送要求処理制御部とを有し、
前記再送要求処理制御部は、
再送要求に基づく再送データパケット受信が、再送データパケット格納データの再生に伴う処理開始時間前に可能か否かを判定し、可能であるとの判定を条件として、再送要求送信を決定すると共に、前記再送要求メッセージパケットに対して該再送要求メッセージパケットの再送回数を記述する構成を有するとともに、
データパケット格納データの再生処理開始時間に間に合うための再送要求最終期限に基づいて、受信データパケット中のエラーまたはロスト・データパケットの検出処理を実行する構成を有することを特徴とするデータ受信装置にある。
【００３７】
さらに、本発明の第５の側面は、
ストリーム型データ受信を実行するデータ受信方法であり、
データ送信装置から受信するデータパケットを受信するパケット受信処理ステップと、
前記データ送信装置から受信するデータパケットのエラーまたはロスト・データパケットの検出に基づいて、前記データ送信装置に対するデータパケット再送要求としての再送要求メッセージパケットの送信可否を判定する再送要求処理制御ステップとを有し、
前記再送要求処理制御ステップは、
再送要求に基づく再送データパケット受信が、再送データパケット格納データの再生に伴う処理開始時間前に可能か否かを判定し、可能であるとの判定を条件として、前記再送要求メッセージの送信処理を実行すると共に、
再送データパケット受信が、再送データパケット格納データの再生に伴う処理開始時間前に可能となる予め計測済みの最終期限において、最終的なロスト・データパケットの検出処理を実行し、前記最終期限においてロスト・データパケットの検出がなされた場合には、最終的な前記再送要求メッセージの送信処理を実行するステップを有することを特徴とするデータ受信方法にある。
【００４９】
さらに、本発明の第６の側面は、
データ受信装置において、ストリーム型データ受信処理を実行させるコンピュータ・プログラムであって、
データ送信装置から受信するデータパケットを受信するパケット受信処理ステップと、
前記データ送信装置から受信するデータパケットのエラーまたはロスト・データパケットの検出に基づいて、前記データ送信装置に対するデータパケット再送要求としての再送要求メッセージパケットの送信可否を判定する再送要求処理制御ステップとを有し、
前記再送要求処理制御ステップは、
再送要求に基づく再送データパケット受信が、再送データパケット格納データの再生に伴う処理開始時間前に可能か否かを判定し、可能であるとの判定を条件として、前記再送要求メッセージの送信処理を実行すると共に、
再送データパケット受信が、再送データパケット格納データの再生に伴う処理開始時間前に可能となる予め計測済みの最終期限において、最終的なロスト・データパケットの検出処理を実行し、前記最終期限においてロスト・データパケットの検出がなされた場合には、最終的な前記再送要求メッセージの送信処理を実行させるステップを有することを特徴とするコンピュータ・プログラムにある。
【００５０】
なお、本発明のコンピュータ・プログラムは、例えば、様々なプログラム・コードを実行可能な汎用コンピュータ・システムに対して、コンピュータ可読な形式で提供する記憶媒体、通信媒体、例えば、ＣＤやＦＤ、ＭＯなどの記録媒体、あるいは、ネットワークなどの通信媒体によって提供可能なコンピュータ・プログラムである。このようなプログラムをコンピュータ可読な形式で提供することにより、コンピュータ・システム上でプログラムに応じた処理が実現される。
【００５１】
本発明のさらに他の目的、特徴や利点は、後述する本発明の実施例や添付する図面に基づくより詳細な説明によって明らかになるであろう。なお、本明細書においてシステムとは、複数の装置の論理的集合構成であり、各構成の装置が同一筐体内にあるものには限らない。
【００５２】
【発明の実施の形態】
［システム及びデータ送受信概要］
まず、図１を参照して、本発明のシステム概要及びデータ送受信処理の概要について説明する。
【００５３】
図１のデータ通信システムにおいて、送信側端末１０４は受信側端末１２１に対して画像、音声等のデータをパケット化して送信する。転送データは、例えばビデオカメラ１０１によって取得された画像、音声データである。なお、転送データは、ＣＤ，ＤＶＤ等の記憶媒体から入力されるデータ、あるいは外部ネットワーク、衛星等から受信するデータ等であってもよい。なお、以下の説明では、１つの例として送信側端末１０４から受信側端末１２１へビデオカメラ１０１によって取得された動画像データを転送する構成を中心として説明する。
【００５４】
ビデオカメラ１０１によって取得された動画像データは、送信側端末１０４の符号化装置１０２により符号化、例えばＭＰＥＧ圧縮処理等による符号化がなされて、バッファ１０３に蓄積される。バッファ１０３に蓄積された符号化データは、リアルタイム・トランスポート・プロトコル：ＲＴＰ（Real-time Transport Protocol）に従ったデータ・パケット（以下パケットと称する）を生成するＲＴＰパケット作成部１０６に出力され、符号化データを格納したＲＴＰパケットのパケット生成処理が実行される。ＲＴＰパケット作成部１０６において生成された符号化データを格納したＲＴＰパケットは、ＲＴＰプロトコルを通じてＲＴＰパケット出力ポート１１０からＩＰネットワーク１１１に送出される。送信側端末１０４のＲＴＰパケット作成部１０６およびＲＴＰパケット出力ポートによってパケット送信処理部が構成される。
【００５５】
ＲＴＰパケット作成部１０６は、符号化データをペイロードとしたパケットを生成する処理を実行する。ペイロードデータに対して、ＲＴＰヘッダを付加しパケット化する。ＲＴＰパケット構成を図２に示す。ＲＴＰヘッダには、バージョン番号（ｖ）、パディング（Ｐ）、拡張ヘッダ（Ｘ）の有無、送信元数（Ｃｏｕｎｔｅｒ）、マーカ情報（ｍａｒｋｅｒ ｂｉｔ）、ペイロードタイプ（Ｐａｙｌｏａｄ ｔｙｐｅ）、シーケンス番号、タイムスタンプ、同期ソース（送信元）識別子（ＳＳＲＣ）および貢献ソース（送信元）識別子（ＣＳＲＣ）の各フィールドが設けられている。データ受信側において、ＲＴＰヘッダに付与されたタイムスタンプによりＲＴＰパケットの展開時に処理時間の制御が実行され、リアルタイム画像、または音声の再生制御が可能となる。なお、例えば動画像データの符号化データを格納したＲＴＰパケットにおいては、１つの画像フレームに属する複数のＲＴＰパケットに共通のタイムスタンプが設定され、各フレームを構成する終端パケットには、終端であることを示す識別フラグがＲＴＰヘッダに格納される。
【００５６】
ＲＴＰヘッダを付加されたパケットはさらにＩＰヘッダが付与される。図３にＩＰパケットの構成中のＩＰヘッダの詳細を示す。ＩＰｖ４、ＩＰｖ６等のバージョンを示すバージョン、ヘッダ長、さらに、優先度情報を格納したＴＯＳ（Type of Service）フィールド、パケットの長さ、パケットの識別子、ＩＰ層でのデータ分割（フラグメント）に関する制御情報としてのフラグ、分割（フラグメント）されたデータの場所を示す断片オフセット、データの破棄までの時間情報を示すＴＴＬ（Time to Live）、上位層で利用されるプロトコル（４：ＩＰ，ＴＣＰ：７，ＵＤＰ：１７…）ヘッダのチェックサム、送信元ＩＰアドレス、宛て先ＩＰアドレスを有する。
【００５７】
図１に戻り、データ受信処理について説明する。受信側端末１２１のＲＴＰパケット入力ポート１１２は、ＩＰネットワーク１１１を介して送信側端末１０４からのＲＴＰパケットを受信する。受信したＲＴＰパケットは、パケット解析部１１４においてパケットの解析が実行される。受信側端末１２１のＲＴＰパケット入力ポート１１２および、パケット解析部１１４によってパケット受信処理部が構成される。パケット解析部１１４は、具体的にはパケット内のヘッダ部、データ部についての解析が実行される。パケットから取り出されたペイロードとしてのデータ、すなわち、符号化データは、バッファ１１７に蓄積される。また、パケットから抽出されたデータのバッファの蓄積位置を示す位置データや、各データに対応するパケットのヘッダ情報は、インデックスリスト１１８として蓄積される。
【００５８】
バッファ１１７に蓄積された符号化データは、インデックスリスト１１８に蓄積されたヘッダ情報に基づく時間制御の下にデコーダ１２０に渡され、デコーダ１２０によって復号処理が実行される。例えば動画像を構成する各画像フレームは、複数のパケットに格納されたデータによって構成され、１つの画像フレームを構成するデータを格納した複数のＲＴＰパケットのヘッダには、同一のタイムスタンプが格納されるので、インデックスリスト１１８に蓄積されたヘッダ情報のタイムスタンプを参照して同一タイムスタンプを持つパケットを１つの画像フレームを構成する符号化データの集合として、デコーダ１２０に渡すことが可能となり、デコーダ１２０は、フレーム毎に復号処理を実行することができる。デコーダ１２０において復号されたデータは、再生装置としてのディスプレイ１２３、またはスピーカ１２２へ渡され、出力再生される。
【００５９】
送信側端末１０４から受信側端末１２１へ転送されるパケットが全て滞りなく、また、エラーのない状態で送信されれば、受信側端末１２１におけるリアルタイムデータ再生は問題なく実行される。しかし、実際は、ネットワーク上でのパケット損失の発生、遅延、転送パケットのデータエラー等、様々な要因に基づく再生エラーあるいは再生データの品質低下が発生し得る。
【００６０】
本発明のシステムにおいては、受信側端末１２１のＲＴＰパケット解析部１１４においてパケット損失等のエラーの発生を検出し、パケット損失等のエラー発生が検出された際には、ＡＲＱ（Auto Repeat reQuest）判定部１１９において、リアルタイム再生シーケンスを考慮したパケット再送要求の可否判定処理を実行する。ＡＲＱ（Auto Repeat reQuest）判定部１１９は、データ送信装置から受信するデータパケットのエラーまたはロスト・データパケットの検出に基づいて、データ送信装置に対するデータパケット再送要求としての再送要求メッセージパケットの送信可否を判定する再送要求処理制御部として機能する。ＡＲＱ判定部１１９における具体的な処理については後述する。
【００６１】
ＡＲＱ判定部１１９において、再送要求を実行するとの判定がなされた場合、受信側端末１２１は、再送要求パケットを識別するデータを格納した再送要求ＮＡＣＫ（Negative ACKnowledge)−ＲＴＣＰ（Real-time Transport Control Protocol）パケットをＲＴＣＰパケット作成装置１１６にて作成し、ＲＴＣＰパケット入出力ポート１１３を介して、送信側端末１０４に対して出力する。
【００６２】
送信側端末１０４のＲＴＣＰパケット入出力ポート１０９において、受信側端末１２１からの再送要求を示すＮＡＣＫ−ＲＴＣＰパケットを受信すると、受信したＮＡＣＫ−ＲＴＣＰパケットをＲＴＣＰパケット解析部１０８において解析し、解析結果をＡＲＱ処理部１０５へ渡す。ＡＲＱ処理部１０５では、再送要求に応じたパケットの再送を実行するため、ＮＡＣＫ−ＲＴＣＰパケットにおいて指定されたパケットをバッファ１０３から抽出し、抽出したパケットを、ＲＴＰパケット出力ポート１１０を介して再送する制御処理を実行する。ＡＲＱ処理部１０５は、データ受信端末装置から受信する再送要求メッセージパケットに従って再送すべきデータパケットの抽出処理を実行する再送制御部として機能する。なお、ＮＡＣＫ−ＲＴＣＰパケットに基づく再送要求に応じたパケット再送処理において、送信側端末１０４は、ＮＡＣＫ−ＲＴＣＰパケットに重複送信の指定がある場合等、必要に応じてＡＲＱ処理部１０５の判断により再送パケットを重複して送る場合もある。これらの処理の詳細については、後述する。
【００６３】
送信側端末１０４において送信すべきストリームデータが終了したのを検知した場合には、送信側端末１０４のＲＴＣＰパケット作成部１０７の生成したＥＯＳ（End Of Stream）メッセージを持つＲＴＣＰパケットを受信側端末１２１へ送り、データストリームの終了を明示する。
【００６４】
本発明のシステムにおいては、ＡＲＱ処理部１０５において、リアルタイム再生を考慮して、ロストパケットに関する再送要求の実行／非実行の処理を決定する。データ転送における自動再送要求方式であるＡＲＱ（Automatic Repeat reQuest）は非常に有効な誤り訂正機能として知られている。ＡＲＱの具体的方式としては、例えばＳＡＷ（Stop And Wait）方式、ＧＢＮ（Go Back N）方式、ＳＲ（Selective Repeat）方式など種々の方法が提案され実現されている。本実施例においては、ＡＲＱ基本アルゴリズムとして、スループット特性が高い選択再送ＳＲ（Selective Repeat）方式エラー訂正機能として使用する例について説明する。
【００６５】
ＳＲ方式の場合、理想的には送信側と受信側で無限のバッファを用意する必要がある。そのため、受信側のバッファオーバーフローが起こった時点または起こりそうな時点でＳＲ方式から別の再送方式に変更する方法やパケットのコピー伝送を通常から行いオーバーフローを回避する方法などが提案されている。しかしながら、本実施例におけるエラー訂正機能においては、ＰＨＳ、ＴＣＰ、データリンク層などに代表される完全にデータを送信することを第一優先にしているＡＲＱと異なり、データ受信側で実行される受信データの再生処理時間から想定されるパケット受信最終許容時間までに、できるだけ必要なデータの受信を実現する事を優先している。よって、ＳＲ方式からＳＴ方式やＧＢＮ方式には移行せず、ＳＲ方式のままＡＲＱを行う構成としている。また、バッファフローオーバーにならないよう受信側はバッファ制御を行い効率よくデータを送信する構成とする。
【００６６】
本発明の１つの実施例では、送信中にロストしてしまったパケットの再送要求は、RFC1889 で規定されているＲＴＣＰ（Real-time Transport Control Protocol）に従って、ＮＡＣＫ（Negative ACKnowledge)を送ることで実現する。RFC1889ではＲＴＣＰパケットの連続送信間隔を５秒以上あける事を推奨している。ここで再送要求を５秒以上間隔を空けたとすると、受信側のバッファ溢れが生じるだけでなく、そもそもメディアの再生時間に間に合うように再送することができない。ストリーミングはリアルタイム性が強い分、
＊できるだけ早く再送要求を出す
＊再送要求を受信したらできるだけ早いうちに再送する
という動作を可能な時間内に実施しなければならない。そのために、ＡＲＱに用いるＮＡＣＫパケットは、データ受信側において能動的に随時必要に応じてデータ送信側に対して送信することが必要となり、推奨値を本発明の場合は適用せず、任意タイミングでのＮＡＣＫパケット送信を実行するものとする。
【００６７】
また、RFC1889ではＲＴＣＰのバンド幅を５％以内になるよう規定している。本発明の実施例に係る構成の再送パケットは最小単位で１６ｂｙｔｅと小さいため、再送要求によって帯域を圧迫するほどのものではないと考えられる。なお、画像データ等の実データ自体の伝送には、RFC1889で規定されているＲＴＰ（パケットフォーマットは図２参照）を用いる例について説明するが、パケット毎にシーケンス番号を記述しておけば、ＵＤＰ（User Datagram Protocol）等、他のプロトコルに従った処理も可能である。
【００６８】
リアルタイム再生を実現するデータ転送では、処理時間が限定されるため、送信と受信における往復伝播遅延（ＲＴＴ）が重要なパラメータとなる。往復伝播遅延（ＲＴＴ）が大きい場合、データ受信端末からデータ送信端末に対して再送要求を出しても、再送要求パケットがデータ送信端末側に到着するまでの時間、データ送信端末において指定データを格納した再送パケットを抽出して再送処理を実行するまでの時間、再送パケットをデータ受信端末が受信するまでの時間、これらの処理に時間を要すると、その後、データ受信端末において、デコーダに受信データを渡して復号を行なっても、リアルタイム再生に間に合わない場合が発生する。無論、間に合う間に合わないかかわらず再送要求を出しておく方が、訂正率の向上が達成される可能性は大となるが、再送要求パケットの送信、再送パケットの再送によるネットワークトラフィックの混雑が発生することになり、これらの冗長データの伝送によるオーバーヘッドの問題が発生することになる。
【００６９】
また、送信と受信における往復伝播遅延（ＲＴＴ）をデータ受信端末において、あらかじめ把握することにより、データ受信端末において、再送要求を行なってから再送パケットを受信するまでの時間の把握が可能となり、データ受信端末においてリアルタイム再生を行なうために必要な最終再送要求時間を割り出すことが可能なる。本発明のシステムでは、受信端末のＡＲＱ判定部において、往復伝播遅延（ＲＴＴ）に基づく最終再送要求時間を判定し、判定に基づいて、再送要求としてのＮＡＣＫ−ＲＴＣＰの送信を実行する。
【００７０】
このように、ＡＲＱにおいてリアルタイム性を保持するためには、常に送信と受信における往復伝播遅延（ＲＴＴ）を計測しておく必要がある。本発明のシステムでは、データ受信側端末は、能動的にＲＴＴを計測し、ネットワーク状況等において変化する送信と受信における往復伝播遅延（ＲＴＴ）の更新を実行し、最新のＲＴＴに基づいて再送要求としてのＮＡＣＫ−ＲＴＣＰの送信の実行可否を判定する。
【００７１】
なお、ＲＴＣＰに規定されたＳＲ（Sender Report）とＲＲ（Receiver Report）により送信側はＲＴＴの算出が可能となるが、リアルタイム再生の進行状況に基づいて、再送要求としてのＮＡＣＫ−ＲＴＣＰパケットを送出するかしないかを判定するのは、データ受信側端末であり、データ受信側端末において、逐次、ネットワーク状況を反映したＲＴＴ情報を取得可能とする構成が好ましい。従って、本発明のシステムにおいては、データ受信端末側から能動的にＲＴＴを算出可能な構成としている。具体的には、データ受信端末におけるＥＣＨＯパケットの送信、ＥＣＨＯ−ＲＥＰＬＹパケットの受信により、ＲＴＴの算出を行なう。これらの処理については、後段で詳細に説明する。
【００７２】
データ送信端末は、データ受信端末からのパケット再送要求としてのＮＡＣＫ−ＲＴＣＰパケットを受信すると、ＮＡＣＫ−ＲＴＣＰパケットに指定された再送要求パケットを、現在配信中のパケットと共に送信する。ただし、データ送信端末は、プライオリティを用いた配信スケジューリング機能を実行し、パケットの再送は、配信スケジューリングに従って実行される。
【００７３】
受信端末側から送信端末への応答パケットとして、パケット再送要求としてのＮＡＣＫ−ＲＴＣＰパケットのみを使用する構成としても、自動再送要求方式としてのＡＲＱ（Automatic Repeat reQuest）を有効に活用することができるが、本実施例においては、受信端末側からのパケット受信確認応答としてのＡＣＫ（ACKnowledge）メッセージもデータ送信端末に対する応答パケットとして送信する。このＡＣＫ送信により、再送要求に対応してパケットを保持する送信側のバッファを能動的に早めにクリアすることが可能となり、バッファ溢れの恐れを低下させることが可能となる。
【００７４】
また、ストリーミング配信されるデータが終了したことを明示的に示すＥＯＳ（End Of Stream）メッセージを送信端末側は利用できる。ＥＯＳメッセージを使うことにより、受信側がストリーミング配信データの終了を認識可能となる。従って、受信側が最終フレームを受け取っているにもかかわらず、次のフレームが到着しないことによるＮＡＣＫ送出動作を防ぐことができる。
【００７５】
受信端末側は、受信端末側で保持するタイマーにより、データ受信間隔、ＮＡＣＫ送出後の経過時間等を計測可能であり、タイマーによる計測時間が閾値以上となったことにより、データ終了と判定する処理が可能であるが、ＥＯＳメッセージの受信により、ストリーミング配信データの終了確認が可能となる。従って、タイマーより先に受信完了状態とすることができる。逆に、ＥＯＳメッセージを利用しない、またはＥＯＳがロストしてしまった場合は、ＮＡＣＫを送出しても送信側から再送パケットが送られてこないため、タイマーによって受信完了状態に移ることになる。
【００７６】
［データ送信端末における処理］
以下、図面を参照しながら、データ送信端末における処理の詳細について説明する。
【００７７】
データ送信端末の処理手順を図４に示すフローチャートを参照して説明する。図４に示す処理は、図１の送信側端末１０４において実行される処理を説明したフローである。送信側端末は、例えばビデオカメラ、あるいはＤＶＤ、ＣＤ、ハードディスク等の記憶媒体から撮り込んだデータをエンコーダにおいてＭＰＥＧ圧縮等の符号化処理を実行し、その後、符号化データをペイロードとしたパケットを生成する。図４に示すフローは、このパケット生成処理以降の処理を示している。
【００７８】
データ送信端末は、ステップＳ２０１において、送信データをペイロードとしたＲＴＰパケット生成処理を実行する。ＲＴＰパケットは、先に図２を参照して説明した構成を有しタイムスタンプをヘッダ中に持つ。例えば動画像データを送信する場合は、同一画像フレームに属する符号化データを格納したパケットには同一のタイムスタンプが設定され、後続フレームに進むに従って、増分されたタイムスタンプが設定される。
【００７９】
図５に示すパケット送信に係るタイムシーケンス図を参照して、タイムスタンプの設定例を説明する。データ送信側（Ｓｅｎｄｅｒ）に示すタイムスタンプ１２０００は、１つの画像フレームを構成する符号化データをペイロードとして格納した複数のＲＴＰパケット（シーケンス番号＝１〜６）に付与されるタイムスタンプである。その後のタイムスタンプ１５０００は、後続画像フレームを構成するＲＴＰパケット（シーケンス番号＝７〜１２）と、データ受信側からＮＡＣＫ−ＲＴＣＰパケットによる再送要求があり、再送するパケット（シーケンス番号＝４，５）とに設定されるタイムスタンプである。このように、データ送信端末では、例えば画像フレームを構成するパケットの集合に１つのタイムスタンプを設定してＲＴＰパケットを生成する。
【００８０】
図４に戻り、データ送信端末の処理について説明を続ける。ステップＳ２０１で生成したＲＴＰパケットは、ステップＳ２０２において、ＲＴＰパケット出力ポートを介して受信端末に向けてＩＰネットワークに出力される。なお、ＲＴＰパケットはさらに、先に図３を用いて説明したＩＰヘッダが付与され、ＩＰヘッダに設定されたアドレスに向けて配信されることになる。ステップＳ２０１、Ｓ２０２のパケット生成、パケット送信処理は、ストリーミング配信されるデータが終了したことを明示的に示すＥＯＳ（End Of Stream）を配信し、予め設定した時間をタイマーで計測して、タイマーでの計測時間が設定時間を超えた場合に、処理を終了する。
【００８１】
図４に示すステップＳ２０３のパケット再送要求としてのＮＡＣＫ−ＲＴＣＰパケットの受信判定処理、ステップＳ２０４のパケット受信確認応答としてのＡＣＫ−ＲＴＣＰパケットの受信判定処理、ステップＳ２０５のＲＴＴ時間計測用のＥＣＨＯ−ＲＴＣＰパケットの受信判定処理は、ＲＴＰパケットによる実データ送信中の割込み処理としてＲＴＰパケットによる実データ送信に並行して逐次実行される処理である。
【００８２】
ステップＳ２０３の処理は、データ受信端末からのパケット再送要求であるＮＡＣＫ−ＲＴＣＰパケットの受信判定処理である。データ受信端末からのパケット再送要求であるＮＡＣＫ−ＲＴＣＰパケットを受信した場合は、ステップＳ２１１〜Ｓ２１５の処理を実行する。このステップＳ２１１〜Ｓ２１５の処理は、図１に示すＡＲＱ処理部１０５における処理として実行される。
【００８３】
ステップＳ２１１においては、データ送信装置は、ＮＡＣＫ−ＲＴＣＰパケットを受信する。図６にデータ受信端末において生成し、データ送信端末の受信するパケット再送要求であるＮＡＣＫ−ＲＴＣＰパケットの構成を示す。
【００８４】
ＮＡＣＫ−ＲＴＣＰパケットは、図６に示すようにヘッダ（ＨＥＡＤ）、フォーマット（ＦＯＲＭＡＴ）、パケットタイプ、パケット長、送信同期ソース識別子（ＲＴＣＰ）、タイムスタンプの情報に加えて、再送要求対象となるパケットの識別子としての再送指定シーケンス番号、さらに、各再送指定シーケンス番号に対応するデータとして、「再送回数」、「オプション」、「重複指定回数」が設定可能である。
【００８５】
前述したように、本発明の提案するＡＲＱを適用したシステムでは、ＲＴＣＰに従ったコントロール・パケットとして再送要求としてのＮＡＣＫ、受信確認としてのＡＣＫ、ストリーミング配信されるデータが終了したことを明示的に示すＥＯＳ、送信と受信における往復伝播遅延（ＲＴＴ）を計測する際に使用されるＥＣＨＯ、およびＥＣＨＯ−ＲＥＰＬＹのパケットが利用される。これらの各ＲＴＣＰパケットそれぞれのフォーマットタイプを一制御メッセージとして、すなわちＲＴＣＰヘッダのＰＴ（Payload Type）として区別をするのは汎用的ではない。よって、制御メッセージとしては、フィードバックメッセージ（FM：Feedback Message）として定義しＰＴ（Payload Type）に指定する。かつ、ＲＴＣＰヘッダ内の［フォーマット］フィールドであるＦＭＴ (Feedback Message Format)にそのパケットフォーマットの指定をすることで、どのようなフィードバックメッセージかを決定できる構成とする。
【００８６】
図６に示すように、１つのＮＡＣＫパケットには１つ以上の再送要求対象となるパケットの識別子としてのシーケンス番号を付与することができる構成を持つ。つまり一度のＮＡＣＫパケットの送信処理で複数のパケットについての再送要求が可能になる。また、再送要求パケットのシーケンス番号各々に対して付加される「再送回数」は、何回目の再送要求かを明記するフィールドであり、「重複指定回数」は、再送する場合の多重回数の指定を明記するフィールドであり、「オプション」はその他の任意の情報を格納するフィールドとして使用される。
【００８７】
例えば、「重複指定回数」に［３］をいれておけば、ＮＡＣＫを受信したデータ送信側は、同じデータを格納した再送パケットを［３］つ連続で送る処理を実行する。重要データを格納したパケットについては、重複再送を要求することで、再送パケットの受信の確実性を高めることが可能となる。また、繰り返し、同一パケットについての再送要求としてのＮＡＣＫを送信しているにもかかわらず、受信に成功しない場合や、リアルタイム再生に間に合うための再送可能最終時間に出されるＮＡＣＫにおいて、「重複指定回数」の設定数を増加させてデータ送信側に送信することにより、再送パケットの受信の確実性を高めることが可能となり、データ再生品質を向上させることが可能となる。データ受信側は、このようなＮＡＣＫ−ＲＴＣＰパケットを送信して、データ送信側は、受信したＮＡＣＫ−ＲＴＣＰパケットに基づくパケット再送処理を実行する。
【００８８】
なお、ＲＴＰパケットフォーマットやペイロードフォーマット、または受信端末の利用者が意図的に指定した場合など、パケットに優先度が与えられている場合、優先度が高いパケットやデータに関しての再送は多重再送処理を行なうことで、再送パケットの受信確率を高めるようコントロール可能である。また、「再送回数」フィールドにおいて何回目の再送要求かを明記することで、ＮＡＣＫ自身が損失したことを送信側が検知できる。
【００８９】
「オプション」フィールドには、フィールド設定値に従って、例えば図７に示す処理指定を行なうことが可能となる。すなわち、
オプション設定値＝０
指定シーケンス番号を持つパケットのみの再送要求（デフォルト）
オプション設定値＝１
フレーム先頭パケットから指定シーケンス番号を持つパケットまでの一括再送要求
オプション設定値＝２
指定シーケンス番号からフレーム最後尾までのパケットの一括再送要求
オプション設定値＝３
指定タイムスタンプの付与されたパケットの一括再送要求
オプション設定値＝４
タイムスタンプを無視してシーケンス番号のみで検索して検索結果のパケットの再送を要求
【００９０】
画像データ等の符号化データは、先に図２を参照して説明したように、タイムスタンプとシーケンス番号をセットとしたヘッダを持つ１つのＲＴＰパケットに格納した構成を有するが、データ転送処理において、タイムスタンプの変わり目を含んた連続的なエラーとしてのバーストエラーが起こった場合、あるいは、バーストエラーの発生により、フレーム単位でパケットの損失が発生した場合などにおいては、受信端末側では、パケット損失の発生したパケットに対応するタイムスタンプとシーケンス番号のセットを特定できない場合が発生する。このような場合において、特定可能なタイムスタンプ、あるいはシーケンス番号のいずれか一方のみを指定して、上記のオプション設定値を設定することにより、フレキシブルな態様で再送の必要な１以上のパケット指定が可能となる。
【００９１】
このように、データ受信端末では、様々な態様での再送要求パケットの指定が可能であり、ＮＡＣＫ−ＲＴＣＰパケットを受信したデータ送信端末のＡＲＱ処理部１０５は、オプションフィールドの設定値に従って、バッファ１０３に格納済みのパケットから指定パケットを抽出して、再送処理を実行する。
【００９２】
図４に戻り、データ送信端末の処理について説明する。ステップＳ２１２では、ステップＳ２１１で受信したＮＡＣＫ−ＲＴＣＰパケットに指定された再送要求パケットに対応するシーケンス番号を抽出し、ステップＳ２１３では、オプション指定の抽出を実行する。上述したように再送要求パケットの指定態様は、シーケンス番号の直接指定のみならず、タイムスタンプ等による指定等、様々であり、データ送信端末装置のＡＲＱ処理部１０５では、受信したＮＡＣＫ−ＲＴＣＰパケットに指定されたオプション指定、およびタイムスタンプ、シーケンス番号を参照して、再送要求パケットを特定する処理を実行する。
【００９３】
ステップＳ２１４では、特定された再送要求パケットをバッファ１０３から抽出する。バッファ１０３には、再送要求に備えて所定時間、送信済みのパケットが保持格納されており、これらの格納パケットから再送指定のあったパケットを抽出する処理を実行する。ステップＳ２１５で、ＲＴＰパケット出力ポートから抽出パケットが送信される。
【００９４】
ステップＳ２０３において、ＮＡＣＫ−ＲＴＣＰパケットを受信しない場合は、ステップＳ２０４でパケット受信応答としてのＡＣＫ−ＲＴＣＰパケットの受信確認を行ない、ＡＣＫ−ＲＴＣＰパケットの受信に基づいて、ステップＳ２０８で、受信の確認されたパケットをバッファ１０３からクリア（削除）する。このＡＣＫにより、再送要求に対応してパケットを保持する送信側のバッファを能動的に早めにクリアすることが可能となり、バッファ溢れの恐れを低下させることが可能となる。
【００９５】
図８にデータ受信端末において生成し、データ送信端末の受信するパケット受信確認応答であるＡＣＫ−ＲＴＣＰパケットの構成を示す。
【００９６】
ＡＣＫ−ＲＴＣＰパケットは、図８に示すようにヘッダ（ＨＥＡＤ）、フォーマット（ＦＯＲＭＡＴ）、パケットタイプ、パケット長、送信同期ソース識別子（ＲＴＣＰ）、タイムスタンプの情報に加えて、受信パケットの識別子としての受信済みシーケンス番号が格納される。
【００９７】
なお、シーケンス番号を指定せず、タイムスタンプ（TIMESTAMP）のみ指定する構成とすることも可能であり、この場合には、そのタイムスタンプ（TIMESTAMP）の設定されたパケットすべてを受け取った事を示す。よってこのような場合にはシーケンス番号をすべて指定する必要はないため、ＡＣＫ−ＲＴＣＰパケットサイズを小さくすることが可能となり、ネットワークトラフィックの増大を低減できる。
【００９８】
図４に戻り、データ送信端末の処理の説明を続ける。データ送信端末は、ステップＳ２０５において、ＥＣＨＯ−ＲＴＣＰパケットの受信確認を行ない、データ受信端末からＥＣＨＯ−ＲＴＣＰパケットを受信した場合は、ステップＳ２０９において、ＥＣＨＯ−ＲＥＰＬＹ−ＲＴＣＰパケットをＥＣＨＯ−ＲＴＣＰパケットを送信してきたデータ受信端末に対して送信する処理を実行する。
【００９９】
ＥＣＨＯ−ＲＴＣＰパケットと、ＥＣＨＯ−ＲＥＰＬＹ−ＲＴＣＰパケットは、送信端末と受信端末における往復伝播遅延（ＲＴＴ）をデータ受信端末において把握するために用いるＲＴＣＰパケットである。このパケットの送受信によって、データ受信端末において、再送要求を行なってから再送パケットを受信するまでの時間の把握が可能となり、データ受信端末においてリアルタイム再生を行なうために必要な最終再送要求時間を割り出すことが可能なる。
【０１００】
本発明のシステムでは、受信端末のＡＲＱ判定部において、往復伝播遅延（ＲＴＴ）に基づく最終再送要求時間を判定し、判定に基づいて、再送要求としてのＮＡＣＫ−ＲＴＣＰの送信の実行可否を決定する。この判定処理に必要な送信端末と受信端末における往復伝播遅延（ＲＴＴ）の最新情報を取得するため、データ受信端末側は、任意タイミングで、能動的にＥＣＨＯ−ＲＴＣＰパケットをデータ送信端末に送信し、データ送信端末は、ＥＣＨＯ−ＲＴＣＰパケットの受信に応答してＥＣＨＯ−ＲＥＰＬＹ−ＲＴＣＰパケットをＥＣＨＯ−ＲＴＣＰパケットを送信してきたデータ受信端末に対して送信する。
【０１０１】
データ受信端末では、データ送信端末からの応答として受信するＥＣＨＯ−ＲＥＰＬＹ−ＲＴＣＰパケットを解析することによって、送信端末と受信端末における往復伝播遅延（ＲＴＴ）を算出する。このＲＴＴ算出処理については、後段のデータ受信端末の処理の項目で説明する。
【０１０２】
図９にデータ受信端末において生成し、データ送信端末の受信するＥＣＨＯ−ＲＴＣＰパケットの構成、および、データ送信端末において生成し、データ受信端末に対して送信するＥＣＨＯ−ＲＥＰＬＹ−ＲＴＣＰパケットの構成を示す。
【０１０３】
ＥＣＨＯ−ＲＴＣＰパケットは、図９（ａ）に示すようにヘッダ（ＨＥＡＤ）、フォーマット（ＦＯＲＭＡＴ）、パケットタイプ、パケット長、送信同期ソース識別子（ＲＴＣＰ）、およびＥＣＨＯパケットの識別データとしてのＥＣＨＯ−ＩＤが格納される。ＥＣＨＯ−ＲＥＰＬＹ−ＲＴＣＰパケットは、図９（ｂ）に示すようにヘッダ（ＨＥＡＤ）、フォーマット（ＦＯＲＭＡＴ）、パケットタイプ、パケット長、送信同期ソース識別子（ＲＴＣＰ）、およびＥＣＨＯ−ＲＴＣＰパケットに対応するＥＣＨＯ−ＩＤ、および、サーバ処理時間が格納される。
【０１０４】
ＥＣＨＯ−ＩＤをＥＣＨＯ−ＲＴＣＰパケットとＥＣＨＯ−ＲＥＰＬＹ−ＲＴＣＰパケットに入れることにより、データ受信端末側がＥＣＨＯ−ＲＥＰＬＹを受け取った際に、いつ送信したＥＣＨＯ−ＲＴＣＰパケットに対応する返事（ＥＣＨＯ−ＲＥＰＬＹ）かを識別することが可能となる。ＥＣＨＯ−ＲＥＰＬＹ−ＲＴＣＰパケットに格納されるサーバ処理時間は、データ送信端末がデータ受信端末からの再送要求（ＮＡＣＫ−ＲＴＣＰ）を受信してからパケットをデータ送信端末から出力するまでに要する処理時間に相当する時間である。このサーバ処理時間は、ＥＣＨＯ−ＲＴＣＰパケットを受信した時間からＥＣＨＯ−ＲＥＰＬＹ−ＲＴＣＰパケットを送信するまでの時間として設定するか、あるいは、予めデータ送信端末において過去の履歴データとして、実際に、データ送信端末がデータ受信端末からの再送要求（ＮＡＣＫ−ＲＴＣＰ）を受信してからパケットをデータ送信端末から出力するまでに要した時間をメモリに格納し、この格納データを適用してもよいし、あるいは、ＥＣＨＯ−ＲＴＣＰパケットを受信した時点におけるサーバ（データ送信端末）における処理負荷を算出して、処理負荷に基づいて算出される予測処理時間をサーバ処理時間として設定する構成としてもよい。
【０１０５】
データ受信端末は、ＥＣＨＯ−ＲＥＰＬＹ−ＲＴＣＰパケットに格納されたサーバ処理時間と、ＥＣＨＯ−ＲＴＣＰパケット送信からＥＣＨＯ−ＲＥＰＬＹ−ＲＴＣＰの受信までの時間とに基づいて、送信端末と受信端末における往復伝播遅延（ＲＴＴ）を算出する。このＲＴＴ算出処理については、後段のデータ受信端末の処理の項目で説明する。
【０１０６】
図４に戻り、データ送信端末の処理の説明を続ける。データ送信端末は、ステップＳ２０６において、送信対象となるストリーミングデータのパケット送信がすべて終了したかを判定し、終了と判定した場合は、ステップＳ２１０において、データストリームの終了を明示するＥＯＳ（End Of Stream）メッセージを持つＲＴＣＰパケットを受信側端末へ送信する処理を実行する。
【０１０７】
図１０にデータ送信端末において生成し、データ受信端末の受信するＥＯＳ−ＲＴＣＰパケットの構成を示す。
【０１０８】
ＥＯＳ−ＲＴＣＰパケットは、図１０に示すようにヘッダ（ＨＥＡＤ）、フォーマット（ＦＯＲＭＡＴ）、パケットタイプ、パケット長、送信同期ソース識別子（ＲＴＣＰ）、およびタイムスタンプ（ＴＩＭＥＳＴＡＭＰ）が格納される。データ受信端末は、ＥＯＳ−ＲＴＣＰパケットをデータ送信端末から受信することにより、ストリーミング配信されるデータの終了を認識する。受信端末はこの認識処理により、次フレームが到着しないことによる誤ったＮＡＣＫ送出動作を防ぐことができる。
【０１０９】
図４に戻り、データ送信端末の処理の説明を続ける。データ送信端末は、ステップＳ２０７において、予め設定した時間を計測するタイマーでの計測時間が設定時間を超えたか否かを判定して、タイマーが設定時間を超えていない場合は、ステップＳ２０３以下の処理、すなわち、ステップＳ２０３のパケット再送要求としてのＮＡＣＫ−ＲＴＣＰパケットの受信判定処理以下の処理を継続して実行する。これは、全パケット送出後においても、一定時間は、データ受信側からのパケット再送要求としてのＮＡＣＫ−ＲＴＣＰパケット、または、受信確認応答としてのＡＣＫ−ＲＴＣＰパケット、または、ＥＣＨＯ−ＲＴＣＰパケットを受信する可能性があり、これらのパケット受信に対する処理を実行するためである。タイマーにおいて、予め設定した時間が経過した時点で、データ送信を終了する。
【０１１０】
［データ受信端末における処理］
次に、データ受信端末の処理手順を図１１に示すフローチャートを参照して説明する。図１１に示す処理は、図１の受信側端末１２１において実行される処理を説明したフローである。
【０１１１】
データ受信端末は、ステップＳ３００において、データ送信端末からの送信開始通知を受信後、ステップＳ３０１において、データ送信端末からの送信パケット、すなわち符号化データをペイロードとして格納したＲＴＰパケットを順次、受信する。ＲＴＰパケットは、先に、図２を参照して説明したように、タイムスタンプがヘッダ情報中に格納されている。データ受信端末は、タイムスタンプに基づいて受信するパケットに含まれるフレームを判別することができる。先に説明したように、動画像データをＲＴＰパケットに符号化データとして格納して送信する場合、同一の画像フレームに属する複数のＲＴＰパケットには同一のタイムスタンプが設定され、データ受信側端末は、タイムスタンプを参照して、フレームの判別が可能となる。
【０１１２】
データ受信端末は、ステップＳ３０２において、受信したパケットが、ｎフレーム目（ｎ=１，２...）の終端パケットであるか否かを判定する。また、ステップＳ３０３において、受信したパケットが、ｎ＋１フレーム目の先頭パケットであるか否かを判定する。受信したパケットが、ｎフレーム目（ｎ=１，２...）の終端パケットである場合、または、ｎ＋１フレーム目の先頭パケットである場合には、ステップＳ３０９に進む。
【０１１３】
ステップＳ３０９においては、ｎフレーム内に未受信のパケット、すなわちロストパケット、あるいはエラーパケットがあるか否かを判定する。図５を参照して、ステップＳ３０９におけるエラーパケットまたはロストパケットの検出処理について説明する。
【０１１４】
図５は、送信側と受信側で実際にＲＴＰ、ＲＴＣＰパケットのデータ転送が行われている例である。図の右方向に時間が流れているとする。ここでは、９０ＫＨｚクロックで、動画像データについて、３０ｆｐｓ（フレーム／秒）のレートでサンプリングして符号化データをＲＴＰパケットに格納して送信すると仮定している。この場合、ＲＴＰパケットのタイムスタンプの値は、同一画像フレーム内の場合には同じ値になり、９０Ｋ/３０＝３００００ずつカウントアップされる。受信側は、最小刻みタイマτを実装する。この例では、当画像データの圧縮フォーマットとして、MOTION JPEG2000に従った符号化データを伝送しているものとし、フレームにおける最終端パケットが、データ受信端末のＲＴＰパケット解析部１１４にて検知できる。
【０１１５】
図５において、タイムスタンプ１２０００の設定されたパケットは、パケットのシーケンス番号１〜６であり、これらが同一フレーム、例えばフレームｎに属するパケットである。データ受信端末では、シーケンス番号６のパケットを受信した時点で、ステップＳ３０２の判定がＹｅｓとなり、ステップＳ３０９のロストパケット検出処理を実行することになる。この時点で、データ受信端末は、図５に示すようにシーケンス番号１〜３，６のパケットを受信しており、シーケンス番号４，５のロストパケットがあると判定する。なお、ここでは、ロストパケットについてのみ記載しているが、受信したパケットについてのエラーパケットとして範囲された場合についても、ロストパケットと同様の処理、すなわち再送要求を実行することが可能である。
【０１１６】
ロスとパケットまたはエラーパケットが検出されると、ステップＳ３１２以下の処理に進み、再送要求処理としてのＮＡＣＫ−ＲＴＣＰパケットの送信判定処理、および判定に基づくＮＡＣＫ−ＲＴＣＰパケットの送信処理が実行される。これらの判定処理の詳細については、後述する。ここでは、シーケンス番号４，５のロストパケットに関するＮＡＣＫ−ＲＴＣＰパケットが生成され、先に図６を参照して説明したＮＡＣＫ−ＲＴＣＰパケットの再送指定シーケンス番号として４，５を設定したパケットを再送要求パケットとしてデータ送信端末に対して送信する。図５におけるＮＡＣＫ−ＲＴＣＰパケット送信処理５０１がこれに相当する。
【０１１７】
ＮＡＣＫ−ＲＴＣＰパケット送信の際にタイムスタンプ（TIMESTAMP）とシーケンス番号の組み合わせがはっきりしない場合には、先に図７を参照して説明したオプションを指定して送信する。データ受信端末では、パケットの送受信情報を随時記録することで、パケットロス率の割り出しが可能となる。このロス率が一定値以上になった場合には、ＮＡＣＫ−ＲＴＣＰパケット自体の損失の可能性が考えられるため、おなじＮＡＣＫ−ＲＴＣＰパケットを複数回、重ねて送信する処理を行なうことで、再送成功率を高めることが可能となる。あるいは、ＮＡＣＫ−ＲＴＣＰパケットに重複指定回数を増分して設定する。
【０１１８】
データ送信端末は、ＮＡＣＫ−ＲＴＣＰパケットを受信すると、次のタイムスタンプを設定したフレームデータに併せて、再送パケットを送信する。ここでは、タイムスタンプ：１５０００のフレームデータ（シーケンス番号７〜１２）に併せて再送パケット（シーケンス番号４，５）を送信する。なお、再送タイミングは、このように次のフレームデータになるとは限らず、処理タイミングによっては、さらに次のあるいはさらに遅れたフレームデータとともになる場合もある。これらの再送処理タイミングについては、データ受信端末側がＥＣＨＯ−ＲＴＣＰパケット、およびＥＣＨＯ−ＲＥＰＬＹ−ＲＴＣＰの送受信を実行することにより、送信端末と受信端末における往復伝播遅延（ＲＴＴ）を算出して推測可能となる。この処理については、後述する。
【０１１９】
図５において、各フレーム、すなわち、タイムスタンプ＝１２０００〜２４０００…において、その最終パケットまたは先頭パケットをデータ受信端末が受信した場合において、図１１のステップＳ３０２またはステップＳ３０３の判定が、Ｙｅｓとなり、ステップＳ３０９のロストパケット検出処理を実行し、ステップＳ３１２以下の処理に進み、再送要求処理としてのＮＡＣＫ−ＲＴＣＰパケットの送信判定処理、および判定に基づくＮＡＣＫ−ＲＴＣＰパケットの送信処理が実行される。
【０１２０】
ステップＳ３１２の再送要求処理としてのＮＡＣＫ−ＲＴＣＰパケットの送信判定処理について説明する。リアルタイム再生処理を実現するためには、再生タイミングに間に合うように、再送要求パケットが受信端末に届くことが必要となる。ステップＳ３１２の再送要求処理としてのＮＡＣＫ−ＲＴＣＰパケットの送信判定処理は、ＮＡＣＫ−ＲＴＣＰパケットを送信した場合、リアルタイム再生処理に間に合うタイミングで、再送パケットが受信可能か否かを判定するものである。
【０１２１】
この判定のためには、前述したように、送信端末と受信端末間における往復伝播遅延（ＲＴＴ）が重要なパラメータとなる。往復伝播遅延（ＲＴＴ）が大きい場合、データ受信端末からデータ送信端末に対して再送要求を出しても、再送要求を発信して、再送パケットがデータ送信端末から再送され、データ受信端末において受信するまでに時間を要すると、その後デコーダに渡して復号を行なってリアルタイム再生に間に合わない場合が発生する。本発明のシステムでは、データ受信端末において、往復伝播遅延（ＲＴＴ）をあらかじめ把握し、往復伝播遅延（ＲＴＴ）に基づいて、ＮＡＣＫ−ＲＴＣＰパケットの送信判定処理を行なう。
【０１２２】
本発明のシステムにおいては、データ受信端末側が、任意タイミングで、往復伝播遅延（ＲＴＴ）の計測を実行することを可能な構成としている。具体的には、データ受信端末から、先に説明した図９に示すＥＣＨＯ−ＲＴＣＰパケットを送信し、ＥＣＨＯ−ＲＥＰＬＹ−ＲＴＣＰパケットを受信して、ＲＴＴの算出を行なう。
【０１２３】
図１２を参照して、データ受信端末で実行するＥＣＨＯ−ＲＴＣＰパケットの送信、ＥＣＨＯ−ＲＥＰＬＹ−ＲＴＣＰパケットの受信、往復伝播遅延（ＲＴＴ）の算出処理について説明する。
【０１２４】
図１２（ａ）は、ＥＣＨＯ−ＲＴＣＰパケットの送信処理フローである。ＥＣＨＯ−ＲＴＣＰパケットの送信は、データ受信端末が任意タイミングで能動的に実行することが可能である。
【０１２５】
ステップＳ５０１における、ＲＴＣＰパケットの送信待機状態において、ＲＴＴの計測要請が発生した場合、ステップＳ５０２のＥＣＨＯ−ＲＴＣＰパケットの生成処理に移行する。ＲＴＴの計測は、データ受信が開始された後、例えば図１１の処理フローにおいて、ステップＳ３００の送信開始通知を受信した以降、定期的に実行する等の設定が可能であり、データ受信側端末に保有するタイマーで予め定めた計測間隔が経過したか否かを計測し、予め定めた計測間隔に対応する時間が経過した場合に、ＡＲＱ判定部１１９が、ＥＣＨＯ−ＲＴＣＰパケットの生成要求をパケット作成部１１６に出力し、パケット作成部１１６がステップＳ５０２のＥＣＨＯ−ＲＴＣＰパケットの生成処理を実行するなどの設定が可能である。この他にも、パケットのロスト状況を解析し、ロスト状況に応じてＥＣＨＯ−ＲＴＣＰパケットの生成、送信を実行する構成としてもよく、いずれにしても、データ受信端末は、任意タイミングで、ＥＣＨＯ−ＲＴＣＰパケットの生成、送信が可能であり、常に最新の往復伝播遅延（ＲＴＴ）の算出が可能となる。
【０１２６】
ステップＳ５０２で生成するＥＣＨＯ−ＲＴＣＰパケットは、先に図９（ａ）を参照して説明した構成を有する。パケットには、各パケット固有の識別子としてのＥＣＨＯ−ＩＤが設定される。ステップＳ５０３で、生成したＥＣＨＯ−ＲＴＣＰパケットが、ＲＴＣＰ入出力ポート１１３を介して、データ送信端末１０４に対して送信される。ステップＳ５０４では、ＥＣＨＯ−ＲＴＣＰパケットを送信した送信時間、および、パケットに設定されたＥＣＨＯ−ＩＤがメモリに記録される。
【０１２７】
図１２（ｂ）は、ＥＣＨＯ−ＲＥＰＬＹ−ＲＴＣＰパケットの受信およびＲＴＴ算出処理フローである。ステップＳ６０１における、ＲＴＣＰパケットの送信待機状態において、ＥＣＨＯ−ＲＥＰＬＹ−ＲＴＣＰパケットが受信されたと判定（ステップＳ６０２でＹｅｓ）されると、ステップＳ６０３において、ＥＣＨＯ−ＲＥＰＬＹ−ＲＴＣＰパケットの受信時刻がメモリに記録される。受信するＥＣＨＯ−ＲＥＰＬＹ−ＲＴＣＰパケットは、先に図９（ｂ）を参照して説明した構成を有する。パケットには、応答対象となった対応するＥＣＨＯ−ＲＴＣＰパケットと同一の識別子としてのＥＣＨＯ−ＩＤが設定され、さらに、データ送信端末において算出したサーバ処理時間が格納される。
【０１２８】
ステップＳ６０４では、受信したＥＣＨＯ−ＲＥＰＬＹ−ＲＴＣＰパケットからサーバ処理時間が抽出され、ステップＳ６０５において、受信したＥＣＨＯ−ＲＥＰＬＹ−ＲＴＣＰパケットに設定されたＥＣＨＯ−ＩＤから対応するＥＣＨＯ−ＲＴＣＰパケットの送信時間が検索される。
【０１２９】
ステップＳ６０６では、ステップＳ６０３において取得したＥＣＨＯ−ＲＥＰＬＹ−ＲＴＣＰパケットの受信時刻、ステップＳ６０４において取得したサーバ処理時間、ステップＳ６０３において取得したＥＣＨＯ−ＲＴＣＰパケットの送信時間に基づいて、往復伝播遅延（ＲＴＴ）の算出処理が実行される。往復伝播遅延（ＲＴＴ）の算出は、下式に基づいて実行される。
往復伝播遅延（ＲＴＴ）＝(ECHO-REPLAY受信時刻)-(ECHO送信時刻)-(サーバ処理時間)
【０１３０】
なお、ＲＴＴの計測を実行する際に送受信するＥＣＨＯ，ＥＣＨＯ−ＲＥＰＬＹパケットも損失することが考えられる。またＲＴＴもネットワークの状況により常に変動するため、データ受信端末は一定間隔でＥＣＨＯ，ＥＣＨＯ−ＲＥＰＬＹパケットの送受信処理を実行してＲＴＴを計測する。
【０１３１】
図１１のフローに戻り、データ受信端末側の処理について説明を続ける。図１１のフローにおいて、ステップＳ３１２では、再送要求としてのＮＡＣＫ−ＲＴＣＰを出力した場合、リアルタイム再生処理に間に合うタイミングで再送要求パケットの受信が可能か否かを判定する。上述したＥＣＨＯ，ＥＣＨＯ−ＲＥＰＬＹパケットの送受信処理により計測されたＲＴＴ値と、各フレームの処理タイミングを計測しているタイマーの期限に基づいて、再送要求としてのＮＡＣＫ−ＲＴＣＰパケットを出しても間に合わないと判断した場合（Ｓ３１２でＮｏ）には、ＮＡＣＫ−ＲＴＣＰパケットの送信処理は実行しない。
【０１３２】
たとえば、パケット損失の存在する該当フレームの符号化データの処理開始までの時間Ｔａ＝１００ｍｍｓｅｃである場合、すなわち１００ｍｍｓｅｃ後にデコーダにデータを渡して復号処理が開始されることがタイマーの計測により明らかとなっている場合、計測された最新のＲＴＴ値が、該当フレームの符号化データの処理開始までの時間Ｔａより大きい値であった場合、すなわち、１００ｍｍｓｅｃ以上であった場合には、再送要求としてのＮＡＣＫ−ＲＴＣＰパケットを送信しても、再送パケットの受信が、デコード処理開始タイミングに間に合わないものと判断して、ＮＡＣＫ−ＲＴＣＰパケットの送信処理を実行しない。ただし、ＲＴＴ値が処理開始までの時間Ｔａ以上であっても、ＲＴＴ値と時間：Ｔａの非常に近い値を持つ場合には、ぎりぎり間に合う可能性もあるためＮＡＣＫを送出する構成としてもよい。このＮＡＣＫ送出判定の閾値は実装依存である。
【０１３３】
一方、計測された最新のＲＴＴ値が、パケット損失の存在する該当フレームの符号化データの処理開始までの時間Ｔａ以下であった場合には、再送要求としてのＮＡＣＫ−ＲＴＣＰパケットを送信して再送パケットを受信するまでの時間が、デコード処理開始タイミングまでの時間以下であるので、再送パケット受信が処理に間に合うものと判断して、ステップＳ３１３において、ＮＡＣＫ−ＲＴＣＰパケットの送信処理を実行する。
【０１３４】
ステップＳ３０９のロストパケットの検出処理は、ステップＳ３０２の各フレームの終端パケット受信、ステップＳ３０３の各フレームの先頭パケット受信時のみではなく、ステップＳ３０４の各フレームの最終再送時間の判定でＹｅｓの場合、およびステップＳ３０５のタイマーの最小計測時間τの経過判定でＹｅｓの場合に実行される。
【０１３５】
図５を参照して、ステップＳ３０４の各フレームの最終再送時間の判定処理、およびステップＳ３０５のタイマーの最小計測時間τの経過判定処理について説明する。
【０１３６】
ステップＳ３０４の各フレームの最終再送時間の判定処理は、再送要求としてのＮＡＣＫ−ＲＴＣＰを出力した場合、リアルタイム再生処理に間に合う最終時間判定処理である。各フレームについて、各フレームの符号化データの処理開始までの時間Ｔａが計測されているＲＴＴ値と等しくなったとき、すなわち、Ｔａ＝ＲＴＴとなった場合に、ステップＳ３０４の判定がＹｅｓとなり、ステップＳ３０９の該当フレームに対するロストパケットの検出処理が実行される。これは、最後の再送要求可能タイミングにロストパケットを検出して、検出された場合に最後の再送要求を送信するための処理である。
【０１３７】
図５において、右下部に示してあるように、タイムスタンプ＝１２０００の処理開始までの時間Ｔａ＝ＲＴＴとなったとき、ステップＳ３０４において、タイムスタンプ＝１２０００に対応するフレームについての最終再送時間の判定処理がＹｅｓと判定され、ステップＳ３０９において、タイムスタンプ＝１２０００のフレームに対するロストパケットの検出処理が実行され、ロストパケットが検出された場合に、ステップＳ３１３において最後の再送要求を送信する。図５におけるＮＡＣＫ−ＲＴＣＰパケット送信処理５０５がこれに相当する。
【０１３８】
ステップＳ３０５のタイマーの最小計測時間τの経過判定処理は、データ受信端末の有するタイマーの計測最小時間：τ毎に、ステップＳ３０５の判定がＹｅｓとなり、ステップＳ３０９の該当フレームに対するロストパケットの検出処理が実行される。これは、各計測最小時間：τに対応する受信フレームについて、各フレームの先頭パケット、最終パケットの検出がなされない場合でもロストパケットを確実に検出して、再送要求を実行しようとするための処理である。図５におけるＮＡＣＫ−ＲＴＣＰパケット送信処理５０２，５０３がこれに相当する。
【０１３９】
図５におけるＮＡＣＫ−ＲＴＣＰパケット送信処理５０２は、そのタイミングまでに受信済みのタイムスタンプのフレームを構成するパケット中のロストパケットとして、パケット（シーケンス番号＝５，１２）を抽出し、シーケンス番号５，１２のロストパケットに関するＮＡＣＫ−ＲＴＣＰパケットが生成され、先に図６を参照して説明したＮＡＣＫ−ＲＴＣＰパケットの再送指定シーケンス番号として５，１２を設定したパケットを再送要求パケットとしてデータ送信端末に対して送信する。なお、シーケンス番号５の再送要求は、２回目となるので、ＮＡＣＫ−ＲＴＣＰパケットのシーケンス番号５に対応する「再送回数」フィールドには、［２］が設定される。
【０１４０】
図５におけるＮＡＣＫ−ＲＴＣＰパケット送信処理５０３は、そのタイミングまでに受信済みのタイムスタンプのフレームを構成するパケット中のロストパケットとして、パケット（シーケンス番号＝５）を抽出し、シーケンス番号５のロストパケットに関するＮＡＣＫ−ＲＴＣＰパケットを生成して送信する。なお、シーケンス番号５の再送要求は、３回目となるので、ＮＡＣＫ−ＲＴＣＰパケットのシーケンス番号５に対応する「再送回数」フィールドには、［３］が設定される。
【０１４１】
このように、データ受信端末では、ステップＳ３０２の各フレームの終端パケット受信、ステップＳ３０３の各フレームの先頭パケット受信時、ステップＳ３０４の各フレームの最終再送時間の判定、およびステップＳ３０５のタイマーの最小計測時間τの経過判定の各タイミングにおいて、ステップＳ３０９のロストパケットの検出処理を実行する。なお、これらステップＳ３０２〜Ｓ３０５の４種類のタイミングのいずれかのみを実行する構成としてもよい。
【０１４２】
ステップＳ３０９の各フレームのロストパケット検出処理において、ロストパケットが検出されなかった場合は、各パケットに格納された符号化データのデコード（復号）処理がデコーダ１２０において実行される。ステップＳ３１１では、受信済みパケットについての受信確認パケットとしてのＡＣＫ−ＲＴＣＰパケットの生成、送信が行われる。ＡＣＫ−ＲＴＣＰパケットは、先に図８を参照して説明した通り、受信済みシーケンス番号を格納したパケットである。このＡＣＫ−ＲＴＣＰパケットを受信したデータ送信端末は、ＡＣＫ−ＲＴＣＰパケットに記録された受信済みシーケンス番号に対応するパケットをバッファ１０３からクリアする。
【０１４３】
図５のタイムシーケンス図では、受信端末から送信端末へのＡＣＫ−ＲＴＣＰパケットの送信は、タイムスタンプ＝１５０００のフレームデータに関しては、ＡＣＫ−ＲＴＣＰパケット送信処理５１１において実行され、タイムスタンプ＝１８０００のフレームデータに関しては、ＡＣＫ−ＲＴＣＰパケット送信処理５１２において実行され、タイムスタンプ＝２１０００のフレームデータに関しては、ＡＣＫ−ＲＴＣＰパケット送信処理５１３において実行されている。
【０１４４】
図１１に示すフローのステップＳ３０６では、各フレームのタイマー期限切れを確認する。このタイマー期限は、リアルタイム再生処理の開始期限を計測するタイマーによって設定される期限であり、各フレーム毎にそのタイミングが設定される。ｎフレームのタイマー期限切れであると判定された場合には、ロストパケットがあった場合であっても、ステップＳ３１０のデコード処理に移行することになる。
【０１４５】
ステップＳ３０７では、データ送信端末から、データストリームの終了を明示するＥＯＳ（End Of Stream）メッセージを持つＲＴＣＰパケットを受信したか否かを判定し、ＥＯＳ−ＲＴＣＰパケット受信でない場合は、ステップＳ３０１以下の処理を繰り返す。
【０１４６】
ＥＯＳ−ＲＴＣＰパケット受信である場合は、ステップＳ３０８において、各フレームのタイマー期限切れを確認する。このタイマー期限は、リアルタイム再生処理の開始期限を計測するタイマーによって設定される期限であり、各フレーム毎にそのタイミングが設定される。タイマー期限切れでない場合は、ステップＳ３１４に進み、再送要求されているロストパケットに関する再送パケットを受信待機状態であるか否かを判定して、待機状態である場合は、ステップＳ３１５に進み、再送パケットの受信待機状態として、ステップＳ３０１のパケット受信以下の処理を実行する。
【０１４７】
ステップＳ３０８における各フレームのタイマー期限切れの確認処理において、Ｙｅｓと判定された場合、および、ステップＳ３１４において、再送パケット受信待機状態でないと判定された場合は、デコード、再生処理へ移行すべき未受信のパケットデータは存在しないと判定され、受信処理を完了する。
【０１４８】
このように、本発明のシステムにおいては、リアルタイム配信に適するものの信頼性を保証しないＲＴＰ等のデータ通信プロトコルに従ったパケット伝送において、ＡＲＱ機能を付加することで、エラー耐性のある信頼性の高いデータ伝送、リアルタイム再生が可能となる。なお、上述の実施例では、ＲＴＰパケットに符号化データを格納する構成例を中心として説明したが、ＲＴＰパケットフォーマットに限らず、ＵＤＰ等、他のデータ通信プロトコルフォーマットに従ったパケットを用いたデータ通信構成においても、上述の実施例と同様の各種のコントロールパケットを用いた再送要求処理を行なうことにより、上述の実施例と同様の構成を実現可能である。
【０１４９】
上述したように本発明の構成では、再送要求の処理タイミングとして、各フレームの先頭パケットの受信時、各フレームの最終パケットの受信時、最終処理期限、および一定間隔（τ）毎等の各種タイミングでロストパケットの検出処理を実行する構成としたので、確実なロストパケットの検出が可能となる。
【０１５０】
また、データ受信端末は、再生処理時間、伝播遅延時間ＲＴＴを考慮したデータ再送要求処理を実行するので、無駄な再送要求パケットおよび再送パケットを出すことを防ぐ事ができ、ネットワークの帯域を再送によって狭めることがない。また、データ受信端末が、パケットの送受信情報を随時記録し、パケットロス率の割り出しにより、ロス率が一定値以上になった場合、おなじＮＡＣＫ−ＲＴＣＰパケットを複数回、重ねて送信することで、再送成功率を高めることが可能となる。
【０１５１】
また、受信端末において送信する再送要求としてのＮＡＣＫ−ＲＴＣＰパケットに重複指定回数の設定を可能としたので、ネットワーク状況に応じて、また受信側の要求に応じて再送パケットの重複送信を要求することが可能となり、重要データの受信成功率を高めることが可能となる。例えば、再生に間に合うための最終的な再送パケットについて重複再送を要求することで、高品質なデータ再生が可能となる。
【０１５２】
また、データ受信端末側から受信パケットに関するＡＣＫメッセージを、例えば画像のフレーム毎、またはあるブロック毎に応じて送信側に送信する構成としたので、パケット毎のＡＣＫ送信による帯域の寡占状態の発生が防止され、また、データ送信側は、データ受信側から受信するＡＣＫパケットに基づいて、再送処理のためのパケット格納バッファから、該当パケットを能動的に破棄でき、バッファ溢れ、バッファ欠如を防ぐことができる。
【０１５３】
［データ送受信端末装置構成例］
上述の実施例で述べた一連の処理は、ハードウェア、またはソフトウェア、あるいは両者の複合構成によって実行することが可能である。ソフトウェアによる処理を実行する場合は、処理シーケンスを記録したプログラムを、専用のハードウェアに組み込まれたデータ処理装置内のメモリにインストールして実行させるか、あるいは、各種処理が実行可能な汎用コンピュータにプログラムをインストールして実行させることが可能である。一連の処理をソフトウェアによって行う場合には、そのソフトウェアを構成するプログラムが、例えば汎用のコンピュータやマイクロコンピュータ等にインストールされる。
【０１５４】
図１３に、上述の実施例で述べた一連の処理を実行するデータ送信端末装置、データ受信端末装置のシステム構成例を示す。本発明のシステムで送受信されるデータは、符号化データであり、データ送信装置ではエンコード（符号化）処理が実行され、データ受信装置ではデコード（復号）処理が実行される。符号化されたデータはパケットとしてネットワークを介して送受信する。そのため、データ送信側では、パケット生成（パケタイズ処理）を実行し、データ受信側ではパケット展開（デパケタイズ処理）を実行する。
【０１５５】
図１３に示すデータ送受信装置（ｅｘ．ＰＣ）８５０は、エンコード（符号化）処理、デコード（復号）処理を実行するとともにパケット生成、展開処理を実行するコーデック８５１、通信ネットワークとのインタフェースとして機能するネットワークインタフェース８５２、マウス８３７、キーボード８３６等の入力機器との入出力インタフェース８５３、ビデオカメラ８３３、マイク８３４、スピーカ８３５等のＡＶデータ入出力機器からのデータ入出力を行なうＡＶインタフェース８５４、ディスプレイ８３２に対するデータ出力インタフェースとしてのディスプレイ・インタフェース８５５、各データ入出力インタフェース、コーデック８５１、ネットワークインタフェース８５２間のデータ転送制御、その他各種プログラム制御を実行するＣＰＵ８５６、ＣＰＵ８５６により制御実行される各種プログラムの格納、データの格納、ＣＰＵ８５６のワークエリアとして機能するＲＡＭ、ＲＯＭからなるメモリ８５７、データ格納、プログラム格納用の記憶媒体としてのＨＤＤ８５８を有し、それぞれＰＣＩバス８５９に接続され、相互のデータ送受信が可能な構成を持つ。
【０１５６】
コーデック８５１は、図１３に示すように、例えばビデオカメラ８３３からの画像データ、マイク８３４からの音声データを入力し、符号化処理、パケット生成処理（パケタイズ）を実行し、最終的に符号化データをペイロードとしたパケットを生成する。生成されたパケットは、ＰＣＩバス８５９上に出力され、ネットワークインタフェース８５２を介してネットワークに出力され、パケットのヘッダに設定された宛先アドレスに配信される。
【０１５７】
また、ＨＤＤ８５８またはメモリ８５７に格納されたソフトウェアエンコードプログラムに従ってＣＰＵ８５６の制御により、ビデオカメラ８３３からの画像データ、マイク８３４からの音声データを符号化してネットワークインタフェース８５２を介してネットワークに出力する処理も実行する構成としてもよい。
【０１５８】
一方、ネットワークを介して入力するＩＰパケット化されたデータは、ネットワークインタフェース８５２を介して、バス８５６上に出力されて、コーデック８５１に入力される。コーデック８５１では入力データのパケット展開処理（デパケタイズ）を実行し、ペイロードとして格納された符号化データを抽出後、復号処理を実行して、ディスプレイ８３２、スピーカ８３５において再生、出力する。
【０１５９】
上述の実施例における処理対象となる画像等のデータは、カメラ他の入力機器、例えばスキャナ等のデータ入力装置、あるいはフロッピーディスク、ＣＤ−ＲＯＭ(Compact Disc Read Only Memory)，ＭＯ(Magneto optical)ディスク，ＤＶＤ(Digital Versatile Disc)、磁気ディスク、半導体メモリなどのリムーバブル記録媒体から入力可能である。
【０１６０】
また、ＣＰＵ８５６は、ＲＯＭ格納プログラムに限らず、ハードディスクに格納されているプログラム、衛星若しくはネットワークから転送され、受信されてインストールされたプログラム等を、ＲＡＭ(Random Access Memory)等のメモリにロードして実行することも可能である。
【０１６１】
ここで、本明細書において、プログラムは、１つのコンピュータにより処理されるものであっても良いし、複数のコンピュータによって分散処理されるものであっても良い。さらに、プログラムは、遠方のコンピュータに転送されて実行されるものであっても良い。
【０１６２】
以上、特定の実施例を参照しながら、本発明について詳解してきた。しかしながら、本発明の要旨を逸脱しない範囲で当業者が該実施例の修正や代用を成し得ることは自明である。すなわち、例示という形態で本発明を開示してきたのであり、限定的に解釈されるべきではない。本発明の要旨を判断するためには、冒頭に記載した特許請求の範囲の欄を参酌すべきである。
【０１６３】
【発明の効果】
以上、説明してきたように、本発明の構成によれば、ＲＴＰ、ＵＤＰ等のデータ通信プロトコルに従ったパケット送信において、ＡＲＱ機能を付加し、再送要求の処理タイミングとして、各フレームの先頭パケットの受信時、各フレームの最終パケットの受信時、最終処理期限、および一定間隔（τ）毎等の各種タイミングでロストパケットの検出処理を実行し、再送要求を実行する構成としたので、確実なロストパケットの検出が可能となり、エラー耐性のある信頼性の高いデータ伝送、リアルタイム再生が可能となる。
【０１６４】
また、本発明の構成によれば、データ受信端末において、再生処理時間、伝播遅延時間ＲＴＴを考慮し、デコード処理等を含む再生処理に間に合わない場合には、再生要求パケットの送信を実行しない構成としたので、無駄な再送要求パケットおよび再送パケットを出すことを防ぐ事ができ、ネットワークの帯域を再送処理の多発によって狭めてしまうことを防止することが可能となる。
【０１６５】
また、本発明の構成において、データ受信端末でパケットの送受信情報を随時記録しパケットロス率の割り出しを可能とした構成においては、データ受信端末の検出したロス率が一定値以上になった場合に、データ受信端末が能動的におなじＮＡＣＫパケットを複数回、重ねて送信する処理を行なうことで、再送成功率を高めることが可能となる。
【０１６６】
また、本発明の構成において、受信端末において送信する再送要求としてのＮＡＣＫパケットに重複指定回数の設定を可能としたため、ネットワーク状況に応じて、また受信側の要求に応じて再送パケットの重複送信を要求することが可能となり、重要データの受信成功率を高めることが可能となる。特に、再生時間に間に合うための最終的な再送パケットにおいては、そのパケットが万が一損失した場合には、データ不完全のまま再生することになるため、受信側から重複再送を要求し、再送成功率を高めることで高品質なデータ再生が可能となる。
【０１６７】
また、本発明の構成において、データ受信端末側から受信パケットに関するＡＣＫメッセージを、画像のフレーム毎、ブロック毎等、パケット単位ではなく複数パケット毎に送信する構成とすることで、ＡＣＫパケットによる帯域の寡占状態の発生を防止し、また、データ送信側では、データ受信側から受信するＡＣＫパケットに基づいて、再送処理のためのパケット格納バッファから、該当パケットを能動的に破棄でき、バッファ溢れ、バッファ欠如を防ぐことが可能となる。
【図面の簡単な説明】
【図１】本発明のデータ通信システムの構成を示す図である。
【図２】本発明のデータ通信システムにおいて転送されるＲＴＰパケットフォーマットを示す図である。
【図３】本発明のデータ通信システムにおいて転送されるＩＰパケットヘッダフォーマットを示す図である。
【図４】本発明のデータ通信システムにおけるデータ送信端末の処理フローを示す図である。
【図５】本発明のデータ通信システムにおけるデータ送信端末およびデータ受信端末のデータ通信処理を説明するタイムシーケンス図である。
【図６】本発明のデータ通信システムにおいて転送されるＮＡＣＫ−ＲＴＣＰパケットフォーマットを示す図である。
【図７】本発明のデータ通信システムにおいて転送されるＮＡＣＫ−ＲＴＣＰパケットにおけるオプション値の機能について説明する図である。
【図８】本発明のデータ通信システムにおいて転送されるＡＣＫ−ＲＴＣＰパケットフォーマットを示す図である。
【図９】本発明のデータ通信システムにおいて転送されるＥＣＨＯ−ＲＴＣＰ、およびＥＣＨＯ−ＲＥＰＬＹ−ＲＴＣＰパケットフォーマットを示す図である。
【図１０】本発明のデータ通信システムにおいて転送されるＥＯＳ−ＲＴＣＰパケットフォーマットを示す図である。
【図１１】本発明のデータ通信システムにおけるデータ受信端末の処理フローを示す図である。
【図１２】本発明のデータ通信システムにおけるデータ受信端末のＥＣＨＯ−ＲＴＣＰ、およびＥＣＨＯ−ＲＥＰＬＹ−ＲＴＣＰパケットを適用したＲＴＴ計測処理フローを示す図である。
【図１３】データ送信端末装置およびデータ受信端末装置のシステム構成例を示す図である。
【符号の説明】
１０１ ビデオカメラ
１０２ エンコーダ
１０３ バッファ
１０４ 送信側端末
１０５ ＡＲＱ処理部
１０６ ＲＴＰパケット作成部
１０７ ＲＴＣＰパケット作成部
１０８ ＲＴＣＰパケット解析部
１０９ ＲＴＣＰ入出力ポート
１１０ ＲＴＰパケット出力ポート
１１１ ＩＰネットワーク
１１２ ＲＴＰパケット入力ポート
１１３ ＲＴＣＰ入出力ポート
１１４ ＲＴＰパケット解析部
１１５ ＲＴＣＰパケット解析部
１１６ ＲＴＣＰパケット作成部
１１６ ＡＲＱ判定部
１１７ バッファ
１１８ インデックスリスト
１１９ ＡＲＱ判定部
１２０ デコーダ
８０９ ＰＣＩバス
８３２ ディスプレイ
８３３ ビデオカメラ
８３４ マイク
８３５ スピーカ
８３７ マウス
８３８ キーボード
８５０ データ送受信装置
８５１ コーデック
８５２ ネットワークインタフェース
８５３ 入出力インタフェース
８５４ ＡＶインタフェース
８５５ ディスプレイインタフェース
８５６ ＣＰＵ
８５７ メモリ
８５８ ＨＤＤ
Claims (17)
- データ送信装置およびデータ受信装置からなり、ストリーム型データ転送を実行するデータ通信システムであり、
データ送信装置は、
送信データを格納したデータパケットを送信するパケット送信処理部と、
データ受信装置から受信する再送要求メッセージパケットに従って再送すべきデータパケットの抽出処理を実行する再送制御部とを有し、
データ受信装置は、
前記データ送信装置から受信するデータパケットを受信するパケット受信処理部と、
前記データ送信装置から受信するデータパケットのエラーまたはロスト・データパケットの検出に基づいて、前記データ送信装置に対するデータパケット再送要求としての再送要求メッセージパケットの送信可否を判定する再送要求処理制御部とを有し、
前記再送要求処理制御部は、
再送要求に基づく再送データパケット受信が、再送データパケット格納データの再生に伴う処理開始時間前に可能か否かを判定し、可能であるとの判定を条件として、前記再送要求メッセージの送信処理を実行すると共に、
再送データパケット受信が、再送データパケット格納データの再生に伴う処理開始時間前に可能となる予め計測済みの最終期限において、最終的なロスト・データパケットの検出処理を実行し、前記最終期限においてロスト・データパケットの検出がなされた場合には、最終的な前記再送要求メッセージの送信処理を実行する構成を有することを特徴とするデータ通信システム。 - ストリーム型データ受信を実行するデータ受信装置であり、
データ送信装置から受信するデータパケットを受信するパケット受信処理部と、
前記データ送信装置から受信するデータパケットのエラーまたはロスト・データパケットの検出に基づいて、前記データ送信装置に対するデータパケット再送要求としての再送要求メッセージパケットの送信可否を判定する再送要求処理制御部とを有し、
前記再送要求処理制御部は、
再送要求に基づく再送データパケット受信が、再送データパケット格納データの再生に伴う処理開始時間前に可能か否かを判定し、可能であるとの判定を条件として、前記再送要求メッセージの送信処理を実行すると共に、
再送データパケット受信が、再送データパケット格納データの再生に伴う処理開始時間前に可能となる予め計測済みの最終期限において、最終的なロスト・データパケットの検出処理を実行し、前記最終期限においてロスト・データパケットの検出がなされた場合には、最終的な前記再送要求メッセージの送信処理を実行する構成を有することを特徴とするデータ受信装置。 - 前記データパケットの格納データは、符号化データであり、
前記再送要求処理制御部は、
再送要求に基づく再送データパケット受信が、再送データパケット格納データの復号処理を含む再生に伴う処理開始時間前に可能か否かを判定する構成であることを特徴とする請求項２に記載のデータ受信装置。 - 前記データ受信装置は、
再送要求データパケットの識別データとしてのシーケンス番号と、該シーケンス番号に対応するデータパケットの重複再送の指定回数データを格納した再送要求メッセージパケットを生成して前記データ送信装置に送信する構成を有することを特徴とする請求項２に記載のデータ受信装置。 - 前記データ受信装置の受信するデータパケットは、動画像データであり、
前記再送要求処理制御部は、
動画像データの１画像フレームの構成データを格納した複数のデータパケットの終端データパケットの受信に応じて、該終端データパケットの属する画像フレームの構成データを格納した複数のデータパケット中のエラーまたはロスト・データパケットの検出処理を実行する構成であることを特徴とする請求項２に記載のデータ受信装置。 - 前記データ受信装置の受信するデータパケットは、動画像データであり、
前記再送要求処理制御部は、
動画像データの１画像フレームの構成データを格納した複数のデータパケットの先頭データパケットの受信に応じて、該先頭データパケットの属する画像フレームの前フレームの構成データを格納した複数のデータパケット中のエラーまたはロスト・データパケットの検出処理を実行する構成であることを特徴とする請求項２に記載のデータ受信装置。 - 前記再送要求処理制御部は、
データパケット格納データの再生処理開始時間に間に合うための再送要求最終期限に基づいて、受信データパケット中のエラーまたはロスト・データパケットの検出処理を実行する構成であることを特徴とする請求項２に記載のデータ受信装置。 - 前記再送要求処理制御部は、
定期的な時間間隔に基づいて、受信データパケット中のエラーまたはロスト・データパケットの検出処理を実行する構成であることを特徴とする請求項２に記載のデータ受信装置。 - 前記再送要求処理制御部は、
前記データ送信装置とデータ受信装置における往復伝播遅延（ＲＴＴ）の計測処理のために前記データ送信装置に対するエコーパケットの送信および該エコーパケットに対するエコーリプライパケットの受信処理制御を実行し、
該エコーパケットに基づいて算出する往復伝播遅延（ＲＴＴ）に基づいて、再送要求に基づく再送データパケット受信が、再送データパケット格納データの再生処理開始時間前に可能か否かを判定する構成を有することを特徴とする請求項２に記載のデータ受信装置。 - 前記データ受信装置は、
再送要求データパケットの識別データとしてのシーケンス番号、またはパケットの属するタイムスタンプ指定データの少なくともいずれかと、再送要求範囲を指定するオプションを格納した再送要求メッセージパケットを生成して前記データ送信装置に送信する構成を有することを特徴とする請求項２に記載のデータ受信装置。 - 前記データパケットは、データ転送プロトコルとしてのＲＴＰに従ったフォーマットを有し、前記再送要求は、制御プロトコルとしてのＲＴＣＰに従ったフォーマットを有することを特徴とする請求項２に記載のデータ受信装置。
- 前記データ受信装置は、
複数のデータパケットに関する再送要求を１つの再送要求メッセージパケットとしてデータ送信装置に対して送信する構成であることを特徴とする請求項２に記載のデータ受信装置。 - 前記データ受信装置は、
複数のデータパケットに関する受信確認を１つの受信確認メッセージパケットとしてデータ送信装置に対して送信する構成であることを特徴とする請求項２に記載のデータ受信装置。 - ストリーム型データ受信を実行するデータ受信装置であり、
データ送信装置から受信するデータパケットを受信するパケット受信処理部と、
前記データ送信装置から受信するデータパケットのエラーまたはロスト・データパケットの検出に基づいて、前記データ送信装置に対するデータパケット再送要求としての再送要求メッセージパケットの送信可否を判定する再送要求処理制御部とを有し、
前記再送要求処理制御部は、
再送要求に基づく再送データパケット受信が、再送データパケット格納データの再生に伴う処理開始時間前に可能か否かを判定し、可能であるとの判定を条件として、前記再送要求メッセージパケットの送信処理を実行し、当該送信処理に際して、前記データパケット受信時におけるパケットロス率に基づいて前記再送要求メッセージパケットの送信回数を変化させ、パケットロス率が一定値以上になった場合は、前記再送要求メッセージパケットの送信回数を増加させる処理を行なう構成を有すると共に、
データパケット格納データの再生処理開始時間に間に合うための再送要求最終期限に基づいて、受信データパケット中のエラーまたはロスト・データパケットの検出処理を実行する構成を有することを特徴とするデータ受信装置。 - ストリーム型データ受信を実行するデータ受信装置であり、
データ送信装置から受信するデータパケットを受信するパケット受信処理部と、
前記データ送信装置から受信するデータパケットのエラーまたはロスト・データパケットの検出に基づいて、前記データ送信装置に対するデータパケット再送要求としての再送要求メッセージパケットの送信可否を判定する再送要求処理制御部とを有し、
前記再送要求処理制御部は、
再送要求に基づく再送データパケット受信が、再送データパケット格納データの再生に伴う処理開始時間前に可能か否かを判定し、可能であるとの判定を条件として、再送要求送信を決定すると共に、前記再送要求メッセージパケットに対して該再送要求メッセージパケットの再送回数を記述する構成を有するとともに、
データパケット格納データの再生処理開始時間に間に合うための再送要求最終期限に基づいて、受信データパケット中のエラーまたはロスト・データパケットの検出処理を実行する構成を有することを特徴とするデータ受信装置。 - ストリーム型データ受信を実行するデータ受信方法であり、
データ送信装置から受信するデータパケットを受信するパケット受信処理ステップと、
前記データ送信装置から受信するデータパケットのエラーまたはロスト・データパケットの検出に基づいて、前記データ送信装置に対するデータパケット再送要求としての再送要求メッセージパケットの送信可否を判定する再送要求処理制御ステップとを有し、
前記再送要求処理制御ステップは、
再送要求に基づく再送データパケット受信が、再送データパケット格納データの再生に伴う処理開始時間前に可能か否かを判定し、可能であるとの判定を条件として、前記再送要求メッセージの送信処理を実行すると共に、
再送データパケット受信が、再送データパケット格納データの再生に伴う処理開始時間前に可能となる予め計測済みの最終期限において、最終的なロスト・データパケットの検出処理を実行し、前記最終期限においてロスト・データパケットの検出がなされた場合には、最終的な前記再送要求メッセージの送信処理を実行するステップを有することを特徴とするデータ受信方法。 - データ受信装置において、ストリーム型データ受信処理を実行させるコンピュータ・プログラムであって、
データ送信装置から受信するデータパケットを受信するパケット受信処理ステップと、
前記データ送信装置から受信するデータパケットのエラーまたはロスト・データパケットの検出に基づいて、前記データ送信装置に対するデータパケット再送要求としての再送要求メッセージパケットの送信可否を判定する再送要求処理制御ステップとを有し、
前記再送要求処理制御ステップは、
再送要求に基づく再送データパケット受信が、再送データパケット格納データの再生に伴う処理開始時間前に可能か否かを判定し、可能であるとの判定を条件として、前記再送要求メッセージの送信処理を実行すると共に、
再送データパケット受信が、再送データパケット格納データの再生に伴う処理開始時間前に可能となる予め計測済みの最終期限において、最終的なロスト・データパケットの検出処理を実行し、前記最終期限においてロスト・データパケットの検出がなされた場合には、最終的な前記再送要求メッセージの送信処理を実行させるステップを有することを特徴とするコンピュータ・プログラム。
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 JP2003169040A (ja) | 2003-06-13 |
| JP2003169040A5 JP2003169040A5 (ja) | 2005-03-17 |
| JP3912091B2 true 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) |
Families Citing this family (161)
| 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 | 삼성전자주식회사 | 데이터 송수신 시스템 및 방법 |
| JP3900413B2 (ja) * | 2002-02-14 | 2007-04-04 | Ｋｄｄｉ株式会社 | 映像情報伝送方式およびプログラム |
| 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 |
| US8270423B2 (en) | 2003-07-29 | 2012-09-18 | Citrix Systems, Inc. | Systems and methods of using packet boundaries for reduction in timeout prevention |
| US8233392B2 (en) * | 2003-07-29 | 2012-07-31 | Citrix Systems, Inc. | Transaction boundary detection for reduction in timeout penalties |
| 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都科摩 | 分组通讯系统、基站和移动站 |
| US7076717B2 (en) * | 2003-06-13 | 2006-07-11 | Microsoft Corporation | Time-aware best-effort hole-filling retry method and system for network communications |
| WO2005006640A1 (en) * | 2003-07-11 | 2005-01-20 | Philips Intellectual Property & Standards Gmbh | Transmission of data packets from a transmitter to a receiver |
| 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 |
| 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 |
| 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 |
| US8238241B2 (en) | 2003-07-29 | 2012-08-07 | Citrix Systems, Inc. | Automatic detection and window virtualization for flow control |
| 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 |
| JP4452983B2 (ja) * | 2004-01-08 | 2010-04-21 | ソニー株式会社 | 受信装置および方法、プログラム、並びに記録媒体 |
| PL2615883T3 (pl) * | 2004-03-09 | 2019-04-30 | Optis Wireless Technology Llc | Sposób dostępu bezpośredniego i urządzenie terminala komunikacji radiowej |
| JP4268076B2 (ja) | 2004-03-09 | 2009-05-27 | 株式会社エヌ・ティ・ティ・ドコモ | 移動通信システム、移動端末及びネットワーク側対向装置 |
| 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 |
| JP2005303927A (ja) * | 2004-04-15 | 2005-10-27 | Sony Corp | 情報処理システム、情報処理装置および方法、記録媒体、並びにプログラム |
| US7643503B2 (en) * | 2004-07-30 | 2010-01-05 | Sony Corporation | System and method for dynamically determining retransmit buffer time |
| US7839844B2 (en) * | 2004-07-30 | 2010-11-23 | Sony Corporation | System and method for dynamically determining retransmit buffer time |
| WO2006033201A1 (ja) * | 2004-09-21 | 2006-03-30 | Hitachi Communication Technologies, Ltd. | ノード装置、パケット制御装置、無線通信装置および送信制御方法 |
| 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的视频传输保护方法 |
| JP4688566B2 (ja) * | 2005-05-10 | 2011-05-25 | 富士通東芝モバイルコミュニケーションズ株式会社 | 送信機及び受信機 |
| 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 |
| 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 |
| 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 |
| JP2007325077A (ja) * | 2006-06-02 | 2007-12-13 | Mitsubishi Electric Corp | データ受信装置及びデータ受信方法 |
| 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 |
| JP2008079150A (ja) * | 2006-09-22 | 2008-04-03 | Canon Inc | 通信機器及びデータ転送方法 |
| WO2008041329A1 (en) * | 2006-10-04 | 2008-04-10 | Fujitsu Limited | Data transfer method |
| 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 |
| 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 |
| US8099512B2 (en) * | 2007-10-19 | 2012-01-17 | Voxer Ip Llc | Method and system for real-time synchronization 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 |
| US8559319B2 (en) * | 2007-10-19 | 2013-10-15 | Voxer Ip Llc | Method and system for real-time synchronization across a distributed services communication network |
| US8250181B2 (en) * | 2007-10-19 | 2012-08-21 | Voxer Ip Llc | Method and apparatus for near real-time synchronization of voice communications |
| JP5500385B2 (ja) * | 2007-10-19 | 2014-05-21 | ヴォクサー アイピー エルエルシー | ネットワークを介したリアルタイムメディア同期の方法およびシステム |
| 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 |
| KR101999852B1 (ko) * | 2008-08-11 | 2019-07-15 | 코닌클리케 필립스 엔.브이. | 네트워크에서 통신하기 위한 방법, 제 2 스테이션 및 이를 위한 시스템 |
| KR100998830B1 (ko) | 2008-08-27 | 2010-12-06 | 주식회사 엘지유플러스 | 무선 네트워크에서의 유디피를 이용한 데이터 전송 시스템및 그 방법 |
| CN102138336B (zh) * | 2008-08-28 | 2014-07-16 | 住友电气工业株式会社 | 动态图像数据的分配方法 |
| JP4625119B2 (ja) * | 2008-09-09 | 2011-02-02 | 株式会社エヌ・ティ・ティ・ドコモ | 移動通信システム、移動端末及びネットワーク側対向装置 |
| JP5207895B2 (ja) * | 2008-09-17 | 2013-06-12 | キヤノン株式会社 | 送信装置、受信装置、及び方法、プログラム |
| KR101048865B1 (ko) | 2009-03-16 | 2011-07-13 | 주식회사 팬택 | 전송계층 성능 향상을 위한 전송계층 제어장치 및 전송속도와 신뢰성을 동시에 보장할 수 있는 패킷 송신 방법 |
| ES2608667T3 (es) * | 2009-04-01 | 2017-04-12 | Qualcomm Incorporated | Gestión de las transmisiones entre los nodos que se comunican a través de un medio de comunicación compartido |
| JP5332854B2 (ja) * | 2009-04-20 | 2013-11-06 | ソニー株式会社 | 無線送信機、無線送信方法、無線受信機および無線受信方法 |
| JP5522987B2 (ja) * | 2009-07-02 | 2014-06-18 | キヤノン株式会社 | 送信装置、送信方法、及びコンピュータプログラム |
| 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 |
| BR112012017465A2 (pt) * | 2010-01-14 | 2019-09-24 | Sumitomo Electric Industries | método de exibição de dados codificados de imagem de vídeo , dispositvo, e sistema de comunicação |
| EP2541842B1 (en) * | 2010-02-25 | 2018-05-23 | Mitsubishi Electric Corporation | Communications device and address learning method |
| EP2375614B1 (en) * | 2010-04-09 | 2014-05-07 | Alcatel Lucent | Method for broadcasting multimedia content |
| WO2011145557A1 (ja) * | 2010-05-19 | 2011-11-24 | 日本電気株式会社 | パケット再送制御装置とパケット再送制御方法 |
| JP5074557B2 (ja) * | 2010-06-09 | 2012-11-14 | 日本電信電話株式会社 | データ配信システムおよびデータ配信方法 |
| 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 |
| JP5728999B2 (ja) * | 2011-02-16 | 2015-06-03 | 富士通株式会社 | 通信方法、通信プログラム、および、通信装置 |
| KR101581515B1 (ko) * | 2011-07-15 | 2016-01-11 | 미쓰비시덴키 가부시키가이샤 | 송신 장치, 수신 장치, 통신 장치, 통신 시스템 및 송신 방법 |
| 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 | 株式会社日立ハイテクノロジーズ | データ処理装置、データ容量増加抑制方法 |
| JP6014411B2 (ja) * | 2012-08-15 | 2016-10-25 | 日本放送協会 | 無線通信を行う受信装置、受信方法及びプログラム |
| 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 |
| CN104981872B (zh) * | 2013-03-15 | 2018-11-06 | 英特尔公司 | 存储系统 |
| CN103152223B (zh) * | 2013-03-15 | 2016-08-03 | 华为技术有限公司 | 网络性能监测方法及装置 |
| 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 | 삼성전자주식회사 | 패킷 송수신 방법 및 그에 따른 단말, 그에 따른 시스템 |
| CN104426636A (zh) * | 2013-09-11 | 2015-03-18 | 松下电器产业株式会社 | 通信控制装置及通信控制方法 |
| JP6496740B2 (ja) * | 2013-09-26 | 2019-04-03 | コーヒレント・ロジックス・インコーポレーテッド | 次世代放送システム及び方法 |
| US10331583B2 (en) | 2013-09-26 | 2019-06-25 | Intel Corporation | Executing distributed memory operations using processing elements connected by distributed channels |
| US9600191B2 (en) | 2014-06-02 | 2017-03-21 | Micron Technology, Inc. | Systems and methods for reordering packet transmissions 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 |
| US11086816B2 (en) | 2017-09-28 | 2021-08-10 | Intel Corporation | Processors, methods, and systems for debugging a configurable spatial accelerator |
| US10496574B2 (en) | 2017-09-28 | 2019-12-03 | Intel Corporation | Processors, methods, and systems for a memory fence in 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 |
| US11200186B2 (en) | 2018-06-30 | 2021-12-14 | Intel Corporation | Apparatuses, methods, and systems for operations 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 |
| US10891240B2 (en) | 2018-06-30 | 2021-01-12 | Intel Corporation | Apparatus, methods, and systems for low latency communication 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 |
| JPWO2020174994A1 (ja) | 2019-02-26 | 2020-09-03 | ||
| JP7059973B2 (ja) | 2019-03-15 | 2022-04-26 | オムロン株式会社 | 制御システム、装置および制御方法 |
| US11029927B2 (en) | 2019-03-30 | 2021-06-08 | Intel Corporation | Methods and apparatus to detect and annotate backedges in a dataflow graph |
| 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 |
| US10817291B2 (en) | 2019-03-30 | 2020-10-27 | Intel Corporation | Apparatuses, methods, and systems for swizzle operations in a configurable spatial accelerator |
| 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 | 中国移动通信集团终端有限公司 | 无效重传包减少方法、装置、设备及计算机存储介质 |
Family Cites Families (29)
| 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 | データ転送方式 |
| JPH06237451A (ja) * | 1993-02-10 | 1994-08-23 | Hitachi Ltd | 動画通信方式および端末装置 |
| US5444718A (en) * | 1993-11-30 | 1995-08-22 | At&T Corp. | Retransmission protocol for wireless communications |
| 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 | 音声データ通信装置 |
| KR0156856B1 (ko) * | 1995-12-30 | 1998-11-16 | 김광호 | 다중 메세지 재전송 처리장치 및 방법 |
| JPH09191314A (ja) * | 1996-01-10 | 1997-07-22 | Mitsubishi Electric Corp | 連続データ伝送方法および連続データ伝送装置 |
| EP0786880B1 (en) * | 1996-01-23 | 2006-09-20 | Ntt Mobile Communications Network Inc. | Communication system and transmission station with error detection and retransmission |
| JPH09247132A (ja) * | 1996-03-08 | 1997-09-19 | Yazaki Corp | 無線パケット通信装置及び送信装置 |
| US5768527A (en) * | 1996-04-23 | 1998-06-16 | Motorola, Inc. | Device, system and method of real-time multimedia streaming |
| JPH10200897A (ja) * | 1997-01-08 | 1998-07-31 | Nippon Telegr & Teleph Corp <Ntt> | 動画像伝送装置 |
| US5918002A (en) * | 1997-03-14 | 1999-06-29 | Microsoft Corporation | Selective retransmission for efficient and reliable streaming of multimedia packets in a computer network |
| JP3349926B2 (ja) * | 1997-07-10 | 2002-11-25 | 三菱電機株式会社 | 受信制御装置、通信制御システム及び通信制御方法 |
| JP3794663B2 (ja) * | 1998-03-13 | 2006-07-05 | 株式会社東芝 | 無線通信システム |
| US6275471B1 (en) * | 1998-05-12 | 2001-08-14 | Panasonic Technologies, Inc. | Method for reliable real-time multimedia streaming |
| JPH11331839A (ja) * | 1998-05-13 | 1999-11-30 | Matsushita Electric Ind Co Ltd | 映像伝送再送の装置及び方法 |
| JP3450771B2 (ja) * | 1998-11-30 | 2003-09-29 | 松下電器産業株式会社 | データ伝送方法，及びデータ送信装置 |
| US6507582B1 (en) * | 1999-05-27 | 2003-01-14 | Qualcomm Incorporated | Radio link protocol enhancements for dynamic capacity wireless data channels |
| JP2001111618A (ja) * | 1999-10-08 | 2001-04-20 | Nippon Telegr & Teleph Corp <Ntt> | 通信システムとその通信方法、ならびにそのプログラムを記録した媒体 |
| JP3391316B2 (ja) * | 1999-10-22 | 2003-03-31 | 日本電気株式会社 | ネットワークシステム |
| US6700893B1 (en) * | 1999-11-15 | 2004-03-02 | Koninklijke Philips Electronics N.V. | System and method for controlling the delay budget of a decoder buffer in a streaming data receiver |
| JP2001218276A (ja) * | 2000-02-04 | 2001-08-10 | Ntt Docomo Inc | 移動通信システムにおけるデータ通信方法及び装置 |
| JP3683468B2 (ja) * | 2000-04-13 | 2005-08-17 | 株式会社エヌ・ティ・ティ・ドコモ | マルチキャストサービス提供システムにおける再送制御方法、情報配信装置及び無線端末 |
| WO2002037763A1 (fr) * | 2000-11-06 | 2002-05-10 | Matsushita Electric Industrial Co., Ltd. | Emetteur, recepteur, et procede de distribution de donnees radiodiffusees |
| 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
Also Published As
| Publication number | Publication date |
|---|---|
| US20030120802A1 (en) | 2003-06-26 |
| US7315898B2 (en) | 2008-01-01 |
| JP2003169040A (ja) | 2003-06-13 |
| KR20030045643A (ko) | 2003-06-11 |
| KR100967377B1 (ko) | 2010-07-05 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP3912091B2 (ja) | データ通信システム、データ送信装置、データ受信装置、および方法、並びにコンピュータ・プログラム | |
| JP3757857B2 (ja) | データ通信システム、データ送信装置、データ受信装置、および方法、並びにコンピュータ・プログラム | |
| US7263644B2 (en) | Data transmitting/receiving system and method thereof | |
| JP4000905B2 (ja) | 情報処理システムおよび方法、情報処理装置および方法、記録媒体、並びにプログラム | |
| JP4452983B2 (ja) | 受信装置および方法、プログラム、並びに記録媒体 | |
| JP3450771B2 (ja) | データ伝送方法，及びデータ送信装置 | |
| US20020181506A1 (en) | Scheme for supporting real-time packetization and retransmission in rate-based streaming applications | |
| US20040098748A1 (en) | MPEG-4 live unicast video streaming system in wireless network with end-to-end bitrate-based congestion control | |
| EP2053858A1 (en) | Communication processing device, communication control method, and computer program | |
| EP1235414B1 (en) | Data transmitting apparatus and data receiving apparatus | |
| JP3871661B2 (ja) | マルチメディアコンテンツ受信装置及びマルチメディアコンテンツ受信方法 | |
| JP2005051299A (ja) | パケット送信装置、パケット受信装置、パケット送信方法及びパケット受信方法 | |
| JP2003324496A (ja) | データ伝送方法，及びパケットデータ構造 | |
| KR20080062692A (ko) | 스트림 녹화 방법, 장치 및 시스템 | |
| JP4433281B2 (ja) | 受信装置および方法、記録媒体、並びにプログラム | |
| JP2008141633A (ja) | データ通信システム、データ受信装置、データ受信方法、データ送信装置およびデータ送信方法 | |
| JP2003163691A (ja) | データ通信システム、データ送信装置、データ受信装置、および方法、並びにコンピュータ・プログラム | |
| JP3735352B2 (ja) | データ伝送方法，データ送信装置，及びデータ受信装置 | |
| Huszák et al. | Source controlled and delay sensitive selective retransmission scheme for multimedia streaming | |
| JP2005136547A (ja) | 通信システム、受信装置および方法、送信装置および方法、記録媒体、並びにプログラム | |
| Huszák et al. | DCCP-based multiple retransmission technique for multimedia streaming | |
| 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 |