JP3757857B2 - データ通信システム、データ送信装置、データ受信装置、および方法、並びにコンピュータ・プログラム - Google Patents
データ通信システム、データ送信装置、データ受信装置、および方法、並びにコンピュータ・プログラム Download PDFInfo
- Publication number
- JP3757857B2 JP3757857B2 JP2001378808A JP2001378808A JP3757857B2 JP 3757857 B2 JP3757857 B2 JP 3757857B2 JP 2001378808 A JP2001378808 A JP 2001378808A JP 2001378808 A JP2001378808 A JP 2001378808A JP 3757857 B2 JP3757857 B2 JP 3757857B2
- Authority
- JP
- Japan
- Prior art keywords
- data
- packet
- processing
- transmission
- network status
- 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 - Fee Related
Links
- 230000005540 biological transmission Effects 0.000 title claims abstract description 256
- 238000004891 communication Methods 0.000 title claims abstract description 50
- 238000000034 method Methods 0.000 title claims description 183
- 238000004590 computer program Methods 0.000 title claims description 10
- 238000012545 processing Methods 0.000 claims abstract description 272
- 238000012937 correction Methods 0.000 claims abstract description 88
- 238000012544 monitoring process Methods 0.000 claims abstract description 86
- 230000008859 change Effects 0.000 claims abstract description 21
- 230000008569 process Effects 0.000 claims description 127
- 238000012913 prioritisation Methods 0.000 claims description 41
- 238000012546 transfer Methods 0.000 claims description 24
- 238000004458 analytical method Methods 0.000 claims description 21
- 238000001514 detection method Methods 0.000 claims description 14
- 230000000694 effects Effects 0.000 claims description 7
- 238000010586 diagram Methods 0.000 description 16
- 238000003860 storage Methods 0.000 description 16
- 239000000872 buffer Substances 0.000 description 15
- 238000005259 measurement Methods 0.000 description 15
- 101000741965 Homo sapiens Inactive tyrosine-protein kinase PRAG1 Proteins 0.000 description 12
- 102100038659 Inactive tyrosine-protein kinase PRAG1 Human genes 0.000 description 12
- 230000000750 progressive effect Effects 0.000 description 11
- 230000004044 response Effects 0.000 description 11
- 238000009826 distribution Methods 0.000 description 9
- 230000006870 function Effects 0.000 description 8
- 238000004364 calculation method Methods 0.000 description 6
- 238000012790 confirmation Methods 0.000 description 6
- 238000000605 extraction Methods 0.000 description 5
- 230000006835 compression Effects 0.000 description 4
- 238000007906 compression Methods 0.000 description 4
- 238000005457 optimization Methods 0.000 description 4
- 238000005516 engineering process Methods 0.000 description 3
- 238000013507 mapping Methods 0.000 description 3
- 230000006978 adaptation Effects 0.000 description 2
- 230000008901 benefit Effects 0.000 description 2
- 230000006866 deterioration Effects 0.000 description 2
- 239000000284 extract Substances 0.000 description 2
- 239000012634 fragment Substances 0.000 description 2
- 239000003550 marker Substances 0.000 description 2
- 239000011159 matrix material Substances 0.000 description 2
- RPOCQUTXCSLYFJ-UHFFFAOYSA-N n-(4-ethylphenyl)-2-(2-methyl-3,5-dioxothiomorpholin-4-yl)acetamide Chemical compound C1=CC(CC)=CC=C1NC(=O)CN1C(=O)C(C)SCC1=O RPOCQUTXCSLYFJ-UHFFFAOYSA-N 0.000 description 2
- 238000004422 calculation algorithm Methods 0.000 description 1
- 238000013500 data storage Methods 0.000 description 1
- 230000006837 decompression Effects 0.000 description 1
- 230000003247 decreasing effect Effects 0.000 description 1
- 230000003111 delayed effect Effects 0.000 description 1
- 230000001419 dependent effect Effects 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 239000004973 liquid crystal related substance Substances 0.000 description 1
- 238000007726 management method Methods 0.000 description 1
- 239000000203 mixture Substances 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 238000002360 preparation method Methods 0.000 description 1
- 238000003672 processing method Methods 0.000 description 1
- 239000004065 semiconductor Substances 0.000 description 1
- 238000006467 substitution reaction Methods 0.000 description 1
- 230000001360 synchronised effect Effects 0.000 description 1
- 230000009466 transformation Effects 0.000 description 1
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/0001—Systems modifying transmission characteristics according to link quality, e.g. power backoff
- H04L1/0009—Systems modifying transmission characteristics according to link quality, e.g. power backoff by adapting the channel coding
-
- 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/60—Network streaming of media packets
- H04L65/75—Media network packet handling
- H04L65/756—Media network packet handling adapting media to device capabilities
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
- H04L69/161—Implementation details of TCP/IP or UDP/IP stack architecture; Specification of modified or new header fields
-
- 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/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
- H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
- H04N21/234—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs
- H04N21/2343—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements
- H04N21/234327—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements by decomposing into layers, e.g. base layer and one or more enhancement layers
-
- 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
- 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/45—Management operations performed by the client for facilitating the reception of or the interaction with the content or administrating data related to the end-user or to the client device itself, e.g. learning user preferences for recommending movies, resolving scheduling conflicts
- H04N21/462—Content or additional data management, e.g. creating a master electronic program guide from data received from the Internet and a Head-end, controlling the complexity of a video stream by scaling the resolution or bit-rate based on the client capabilities
- H04N21/4621—Controlling the complexity of the content stream or additional data, e.g. lowering the resolution or bit-rate of the video stream for a mobile client with a small screen
-
- 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/643—Communication protocols
- H04N21/6437—Real-time Transport Protocol [RTP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/004—Arrangements for detecting or preventing errors in the information received by using forward error control
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
- H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
- H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
Landscapes
- Engineering & Computer Science (AREA)
- Signal Processing (AREA)
- Multimedia (AREA)
- Computer Networks & Wireless Communication (AREA)
- Databases & Information Systems (AREA)
- Computer Security & Cryptography (AREA)
- Quality & Reliability (AREA)
- Communication Control (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Detection And Prevention Of Errors In Transmission (AREA)
- Compression Or Coding Systems Of Tv Signals (AREA)
- Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は、データ通信システム、データ送信装置、データ受信装置、および方法、並びにコンピュータ・プログラムに関する。さらに詳細には、ストリーミングデータ転送におけるエラー耐性を高めたパケット送信構成を持つデータ通信システム、データ送信装置、データ受信装置、および方法、並びにコンピュータ・プログラムに関する。
【０００２】
【従来の技術】
昨今、インターネット通信など、様々な通信媒体を介した画像、音声データ等のデータ転送が盛んに行われている。特に、近年においては、インターネット上のデータ転送において、従来から利用されているダウンロード型伝送方式に加えて、ストリーム型伝送方式によるサービスが増加してきている。ダウンロード型伝送方式においては、映像ファイルや音声ファイルといったマルチメディアデータを伝送する場合、配信サーバからデータファイルを一旦受信側端末の記憶媒体にダウンロードして、その後、記憶媒体から再生することになる。よって、この方式ではファイルを完全に転送が終わるまでは再生できず、長時間再生やリアルタイム再生などには不向きである。
【０００３】
一方、後者のストリーム型伝送方式では、送信側から受信端末にデータ転送が行われている間に、並列して受信データの再生処理を実行するものであり、インターネット電話・遠隔テレビ会議・ビデオオンデマンドといったインターネットサービスに利用されている。
【０００４】
ストリーム型伝送方式は、例えば画像データのＭＰＥＧ圧縮処理により生成されるＭＰＥＧストリームをＩＰ（Internet Protocol）パケットに格納してインターネット上を転送させて、ＰＣやＰＤＡ、携帯電話等の各通信端末において受信するシステム等において使用され、開発が進んでいる。このような技術は、ビデオオンデマンドやライブ映像のストリーミング配信、あるいはビデオ会議、テレビ電話などのリアルタイム通信において有効となる。
【０００５】
このようなストリーム型伝送方式に適したインターネット技術に、IETF RFC1889で規定されているプロトコル：ＲＴＰ(Realtime Transport Protocol)がある。ＲＴＰに従ったデータ転送では、時間情報としてパケットにタイムスタンプを付加し、タイムスタンプの参照により送信側と受信側の時間的関係の把握を行ない、データ受信側において、パケット転送の遅延ゆらぎ（ジッター）などの影響を受けずに同期をとった再生を可能としている。
【０００６】
ただし、ＲＴＰは実時間のデータ転送を保証しているものではない。パケット配送の優先度や設定、管理などはＲＴＰが提供するトランスポートサービスの範疇ではないため、ＲＴＰパケットは、他のパケットと同様、ネットワーク上での配送遅延やパケット損失がおきる可能性がある。しかし、このような事態が起こっても、受信側は期待する時間内に到着したパケットだけを利用してデータを再生することが可能である。これは、映像や音声データが多少のデータ欠損があったとしても、データ品質を落とした再生、あるいはデータ補正処理による再生が可能となるからである。
【０００７】
なお、再生に間に合わず遅延配送されたパケットやエラーの発生したパケットは、受信側でそのまま破棄される。つまり、パケット損失やエラーが発生した場合は、高品質なデータ配信処理を行なっている場合でも、受信側で品質を保持した再生が実行されないという問題点がある。特に、有線区間で１０-5、無線区間で１０-3以上のエラーがあるといわれている中では、配信するメディアの品質保持を考慮すると、ＲＴＰをそのまま利用したデータ転送には問題がある。
【０００８】
このようなＲＴＰに従ったデータ転送における問題点を解決する１つの案としては、データ転送に信頼性が高いデータ転送プロトコルであるＴＣＰに従ってパケットの再送要求および再送パケット送信を行わせる方法が考えられる。しかし、ＴＣＰはエラーには強いが、スループットが低く、遅延が大きいため、再送しても再生時間に間に合わない可能性があり、リアルタイム通信の実現を困難とするという問題がある。
【０００９】
さらに、パケットエラー等に対応するエラー訂正手法として、例えばＦＥＣ（Forward Error Correction）という手段が考えられている。これは誤り訂正を行うためのＦＥＣデータを冗長データとして送信して、エラーが発生した場合には、データ受信側において、このＦＥＣデータをもとにエラーの修復を実行しようとするものである。ランダム誤り訂正符号として、ＢＣＨ符号と畳み込み符号が用いられる。また、バースト誤り訂正符号では、リードソロモン符号（ＲＳ符号）が一般的によく利用されている。前述のＡＲＱに比べると再送にかかる遅延がない分、遅延時間を低く抑えられるが、冗長データを付加するためにパケット損失が非常に少ない伝送路においてはスループットは低下する。
【００１０】
ＦＥＣは、端末側での誤り検出と符号処理が複雑なため受信端末側の処理能力に依存してしまう。このように、ネットワーク状況と受信端末に合わせた最適な付加ＦＥＣデータを一意に決定して送信するのは難しく、処理時間のオーバーヘッドが常につきまとうなど問題が存在する。
【００１１】
【発明が解決しようとする課題】
本発明は、上述の問題点に鑑みてなされたものであり、ビデオオンデマンドや、遠隔テレビ会議のような、リアルタイム再生が望まれるデータ転送処理を効率的に実行可能とかるとともに、パケット損失等のエラー発生時にも品質の低下を抑えて高品質なデータ再生を実現するデータ通信システム、データ送信装置、データ受信装置、および方法、並びにコンピュータ・プログラムを提供することを目的とする。
【００１２】
【課題を解決するための手段】
本発明の第１の側面は、
データ送信装置およびデータ受信装置からなり、画像データのストリーム型データ転送を実行するデータ通信システムであり、
データ送信装置は、
送信画像データの階層符号化処理を実行する階層符号化部と、
前記送信画像データの元画像へのデータ損失による影響およびネットワークの損失率に基づき、前記階層符号化部において階層符号化された階層毎の優先度を設定する優先度付け処理部と、
前記階層符号化部により階層符号化された前記送信画像データを格納した送信画像データパケットを送信するパケット送信処理部と、
ネットワーク状況を監視するネットワーク状況監視部と、
前記優先度付け処理部により前記階層毎に設定された優先度に従って、前記ネットワーク状況監視部の監視するネットワーク状況に基づき、前記送信画像データパケットのエラー制御処理態様を制御するとともに、前記階層符号化部における前記送信画像データの符号化態様を設定してビットレートを制御するデータ送信側制御部と、
データ受信装置から受信する再送要求メッセージパケットに従って再送すべき送信画像データパケットの抽出処理を実行する再送制御部とを有し、
前記優先度付け処理部は、
前記ネットワーク状況監視部により検出されたネットワーク状況に応じて、前記階層毎の優先度を変更する構成であり、
データ受信装置は、
前記データ送信装置から受信する画像データパケットを受信するパケット受信処理部と、
ネットワーク状況を監視するネットワーク状況監視部と、
前記データ送信装置から受信する画像データパケットのエラーまたはパケットロスの検出を実行し、エラー対応処理を実行するエラー訂正制御部と、
前記データ送信装置から受信する画像データパケットのエラーまたはパケットロスの検出に基づいて、前記データ送信装置に対する画像データパケット再送要求としての再送要求メッセージパケットの送信可否を判定する再送要求処理制御部と、
前記ネットワーク状況監視部の監視結果に基づいて処理画像データの選択を実行する階層選択制御部とを有し、
前記階層選択制御部は、
前記ネットワーク状況監視部の解析結果に基づく処理画像データの選択を、前記階層符号化された画像データ毎に前記ネットワーク状況に応じて決定された前記優先度に従って実行する構成である、
ことを特徴とするデータ通信システムにある。
【００２２】
本発明の第２の側面は、
送信画像データのストリーム型データ送信を実行するデータ送信装置であり、
前記送信画像データの階層符号化処理を実行する階層符号化部と、
前記送信画像データの元画像へのデータ損失による影響およびネットワークの損失率に基づき、前記階層符号化部において階層符号化された階層毎の優先度を設定する優先度付け処理部と、
前記階層符号化部により階層符号化された前記送信画像データを格納した送信画像データパケットを送信するパケット送信処理部と、
ネットワーク状況を監視するネットワーク状況監視部と、
前記優先度付け処理部により前記階層毎に設定された優先度に従って、前記ネットワーク状況監視部の監視するネットワーク状況に基づき、前記送信画像データパケットのエラー制御処理態様を制御するとともに、前記階層符号化部における前記送信画像データの符号化態様を設定してビットレートを制御するデータ送信側制御部と、
データ受信装置から受信する再送要求メッセージパケットに従って再送すべき送信画像データパケットの抽出処理を実行する再送制御部とを有し、
前記優先度付け処理部は、
前記ネットワーク状況監視部により検出されたネットワーク状況に応じて、前記階層毎の優先度を変更する構成であることを特徴とするデータ送信装置にある。
【００２３】
さらに、本発明のデータ送信装置の一実施態様において、前記データ送信側制御部は、前記ネットワーク状況監視部の監視するネットワーク状況に基づいて、エラー制御方式としてのＦＥＣ(Forward Error Correction)の処理態様変更、またはデータ再送要求処理としてのＡＲＱ（Auto Repeat reQuest）処理態様の変更処理を実行する構成であることを特徴とする。
【００２４】
さらに、本発明のデータ送信装置の一実施態様において、前記ネットワーク状況監視部は、パケットロス率、伝送遅延時間、または前記データ受信装置からの再送要求に基づいてネットワーク状況解析を実行し、該解析結果を前記データ送信側制御部に出力し、前記データ送信側制御部は、該解析結果に基づいて、伝送パケットのエラー制御処理態様を制御する構成であることを特徴とする。
【００２６】
さらに、本発明のデータ送信装置の一実施態様において、前記データ送信装置において、前記データ送信側制御部は、前記ネットワーク状況監視部の監視するネットワーク状況に基づいて、エラー制御方式としてのＦＥＣ(Forward Error Correction)の処理態様変更、またはデータ再送要求処理としてのＡＲＱ（Auto Repeat reQuest）処理態様の変更処理を前記階層符号化部の設定した各階層の符号化送信画像データに対応して実行する構成であることを特徴とする。
【００２７】
さらに、本発明のデータ送信装置の一実施態様において、前記データ送信装置において、前記データ送信側制御部は、前記ネットワーク状況監視部の監視するネットワーク状況に基づいて、エラー制御方式としてのＦＥＣ(Forward Error Correction)の処理態様変更、またはデータ再送要求処理としてのＡＲＱ（Auto Repeat reQuest）処理態様の変更処理を前記優先度付け処理部の設定した各優先度に対応して実行する構成であることを特徴とする。
【００３２】
本発明の第３の側面は、
送信画像データのストリーム型データ送信を実行するデータ送信方法であって、
前記送信画像データの階層符号化処理を実行する階層符号化処理ステップと、
前記送信画像データの元画像へのデータ損失による影響およびネットワークの損失率に基づき、前記階層符号化処理ステップにおいて階層符号化された階層毎の優先度を設定する優先度付け処理ステップと、
前記階層符号化処理ステップにおいて階層符号化された前記送信画像データを格納した送信画像データパケットを送信するパケット送信処理ステップと、
ネットワーク状況を監視するネットワーク状況監視ステップと、
前記優先度付け処理ステップにおいて前記階層毎に設定された優先度に従って、前記ネットワーク状況監視ステップにおいて取得したネットワーク状況に基づき、前記送信画像データパケットのエラー制御処理態様を制御するとともに、前記階層符号化ステップにおける前記送信画像データの符号化態様を設定してビットレートを制御するデータ送信側制御ステップと、
データ受信装置から受信する再送要求メッセージパケットに従って再送すべき送信画像データパケットの抽出処理を実行する再送制御ステップとを有し、
前記優先度付け処理ステップは、
前記ネットワーク状況監視ステップにおいて検出されたネットワーク状況に応じて、前記階層毎の優先度の変更処理を行うことを特徴とするデータ送信方法にある。
【００４２】
本発明の第４の側面は、
送信画像データのストリーム型データ送信を実行するコンピュータ・プログラムであって、
前記送信画像データの階層符号化処理を実行する階層符号化処理ステップと、
前記送信画像データの元画像へのデータ損失による影響およびネットワークの損失率に基づき、前記階層符号化処理ステップにおいて階層符号化された階層毎の優先度を設定する優先度付け処理ステップと、
前記階層符号化処理ステップにおいて階層符号化された前記送信画像データを格納した送信画像データパケットを送信するパケット送信処理ステップと、
ネットワーク状況を監視するネットワーク状況監視ステップと、
前記優先度付け処理ステップにおいて前記階層毎に設定された優先度に従って、前記ネットワーク状況監視ステップにおいて取得したネットワーク状況に基づき、前記送信画像データパケットのエラー制御処理態様を制御するとともに、前記階層符号化ステップにおける前記送信画像データの符号化態様を設定してビットレートを制御するデータ送信側制御ステップと、
データ受信装置から受信する再送要求メッセージパケットに従って再送すべき送信画像データパケットの抽出処理を実行する再送制御ステップとを有し、
前記優先度付け処理ステップは、
前記ネットワーク状況監視ステップにおいて検出されたネットワーク状況に応じて、前記階層毎の優先度の変更処理を行うステップであることを特徴とするコンピュータ・プログラムにある。
【００４４】
なお、本発明のコンピュータ・プログラムは、例えば、様々なプログラム・コードを実行可能な汎用コンピュータ・システムに対して、コンピュータ可読な形式で提供する記憶媒体、通信媒体、例えば、ＣＤやＦＤ、ＭＯなどの記録媒体、あるいは、ネットワークなどの通信媒体によって提供可能なコンピュータ・プログラムである。このようなプログラムをコンピュータ可読な形式で提供することにより、コンピュータ・システム上でプログラムに応じた処理が実現される。
【００４５】
本発明のさらに他の目的、特徴や利点は、後述する本発明の実施例や添付する図面に基づくより詳細な説明によって明らかになるであろう。なお、本明細書においてシステムとは、複数の装置の論理的集合構成であり、各構成の装置が同一筐体内にあるものには限らない。
【００４６】
【発明の実施の形態】
［システム及びデータ送受信概要］
本発明のデータ通信システムのシステム構成例を図１に示す。本発明のデータ通信システムは、ビデオオンデマンドや、遠隔テレビ会議のような、リアルタイム再生が望まれるデータ転送処理をデータ送信処理を実行する送信側端末１００と、データ受信処理を実行する受信側端末１３０，１３１との間でＩＰネットワーク１３５を介して実行するシステムである。
【００４７】
図１には、１つの送信側端末１００と２つの受信側端末１３０，１３１が示してあるが、この他にも任意数の端末がＩＰネットワーク１３５を介してデータ送受信が実行される。また、データ送信側端末、受信側端末は、データの送信のみ、受信のみを実行するばかりでなく、データ送受信が可能な端末として構成可能である。
【００４８】
データ送信側端末１００は、カメラ１０９やマイク１１０より、画像、音声等のメディアデータをインターフェース（Ｉ／Ｆ）１０８などを通して記憶装置１０５、ＲＡＭ１０３に取り込む。撮り込まれたデータは、通信インターフェース１０６を介して、ＩＰネットワーク１３５に伝送される。ＩＰネットワーク１３５を介して設定される伝送路１３２，１３３，１３４は、有線路でも無線路でも構わない。これらの伝送路１３２，１３３，１３４を介して受信側端末１３０は、通信インターフェース１１２を通してデータを受信しＲＡＭ１１７にバッファリングする。
【００４９】
受信側端末１３０では、ＣＰＵ１１５による処理を経て、受信データを表示装置１１８において画像表示し、また再生装置１１４において音声の再生を実行する。受信端末１３１も受信端末１３０と同様に送信側端末１００からのデータを同時に受信し、同様の画像再生、音声再生を実行する。
【００５０】
図１の構成において、送信側端末１００、受信側端末１３０，１３１のそれぞれは例えば通信処理機能を持つＰＣ、あるいは携帯端末等によって構成される。各端末の詳細構成については、後段で説明するが、図１に示す送信側端末１００および受信側端末１３０，１３１の各処理部の機能の概略をまとめて説明する。
【００５１】
ＣＰＵ(Central processing Unit)１０１，１１５，１２３は、各種実行プログラム、ＯＳ（Operating System）を実行するプロセッサであり、後段で説明する。送受信データの再送制御、エラー訂正処理等のプログラムを実行する。ＲＯＭ（Read-Only-Memory）１０２，１１６，１２４は、ＣＰＵが実行するプログラム、あるいは演算パラメータとしての固定データを格納する。ＲＡＭ（Random Access Memory）１０２，１１７，１２５は、ＣＰＵの処理において実行されるプログラム、およびプログラム処理において適宜変化するパラメータの格納エリア、ワーク領域として使用される。
【００５２】
表示装置１０４，１１８，１２６は、例えばＣＲＴ、液晶ディスプレイ等であり、各種情報をテキストまたはイメージ等により表示する。外部記憶装置１０５，１１１，１１９はハードディスク、ＤＶＤ等の記憶媒体を持つ記憶装置であり、各種データ、プログラムを格納する。
【００５３】
通信Ｉ／Ｆ１０６，１１２，１２０は送信側端末と受信側端末間の通信処理を実行し、ＣＰＵの制御の下に、各記憶部から供給されたデータ、あるいはＣＰＵによって処理されたデータを送信したり、他端末からのデータを受信する処理を実行する。
【００５４】
入力装置１０７，１１３，１２１は、例えばキーボード、ポインティングデバイスを含む入力部であり、キーボードやマウス等を介してユーザによるデータまたはコマンドの入力が可能である。受信側端末１３０，１３１に示す再生装置１１４，１２２は前述したように音声再生を実行する例えばスピーカ等の装置である。
【００５５】
次に、図２以下を参照して、本発明のデータ通信システムにおけるデータ送受信処理の詳細を説明する。
【００５６】
図２のデータ通信システムにおいて、送信側端末２０１は受信側端末２０２に対して画像、音声等のデータをパケット化して送信する。転送データは、例えばビデオカメラ２０３によって取得された画像、音声データである。なお、転送データは、ＣＤ，ＤＶＤ等の記憶媒体から入力されるデータ、あるいは外部ネットワーク、衛星等から受信するデータ等であってもよい。なお、以下の説明では、１つの例として送信側端末２０１から受信側端末２０２へビデオカメラ２０３によって取得された動画像データを転送する構成を中心として説明する。
【００５７】
ビデオカメラ２０３によって取得された動画像データは、送信側端末２０１の符号化装置（エンコーダ）２０４により符号化、例えばＭＰＥＧ圧縮処理等による符号化がなされ、階層化部２０５、優先度付け処理部２０６において、送信するデータ、および端末側の再生能力などに応じてデータを階層化し、優先度付け処理を実行する。
【００５８】
階層化部２０５は、符号化がなされたデータの階層化処理を実行する。基本階層（ベースレイヤー）は画像の基本となる階層であり、受信側端末２０２は、基本階層のみ受信した場合であっても最低限の品質を確保できる。さらに、上位階層のデータを受信することでより高品質なデータ例えば画像再生が可能となる。階層化部２０５は、このように符号化データに応じた階層区分処理を行なう。
【００５９】
ビデオオンデマンドやライブ映像のストリーミング配信、あるいはビデオ会議、テレビ電話などのリアルタイム通信においては、異なる能力を持つ端末を受信端末として、データ送受信が行われることを想定する必要がある。例えば、１つの情報送信ソースからの送信データは、携帯電話などのような解像度の低いディスプレイと処理能力の低いＣＰＵを有する受信端末によって受信されディスプレイに表示する処理が実行され、かつ、デスクトップパソコンのように高解像度のモニターと高い処理能力のＣＰＵを有する受信端末によって受信されて表示処理が実行される。このように、処理能力の異なる様々な受信端末を相手としたデータ送信が行なわれる。このように様々な受信端末において処理能力等に応じた受信処理、表示処理を実行させる手法として、送受信するデータの符号化を階層化させて実行するものであり、階層化部２０５は、このように符号化データに応じた階層化処理を行なう。
【００６０】
階層符号化によるデータ配信により、例えば、高解像度のディスプレイを有する受信端末においてのみ処理する符号化データと、高解像度のディスプレイを有する受信端末および低解像度のディスプレイを有する受信端末の双方において共通に処理する符号化データとを、それぞれ区別可能な態様でパケット化して配信可能となり、受信側において、データを選別して処理できる。
【００６１】
階層符号化が可能な圧縮・伸張方式としては、例えばＭＰＥＧ４とＪＰＥＧ２０００によるビデオストリームをあげることができる。ＭＰＥＧ４ではＦｉｎｅＧｒａｎｕａｌｉｔｙ Ｓｃａｌａｂｉｌｉｔｙ技術を規格に取り込みプロファイル化する予定であり、この階層符号化技術によりスケーラブルに低いビットレートから高いビットレートまで配信することが可能と言われている。また、ウェーブレット（Ｗａｖｅｌｅｔ）変換をベースとするＪＰＥＧ２０００は、ウェーブレット（Ｗａｖｅｌｅｔ）変換の特徴を生かし、空間解像度をベースにパケット化することや、あるいは画質をベースに階層的にパケット化することが可能である。またＪＰＥＧ２０００は静止画だけでなく動画を扱えるＭｏｔｉｏｎ ＪＰＥＧ２０００（Ｐａｒｔ ３）規格により、階層化したデータをファイルフォーマットで保存することが可能である。上述の階層符号化処理の適用により、１つのファイルデータから異なる能力の端末へ同時にデータ配信を実行することが可能となる。
【００６２】
また、階層符号化の例としてＤＣＴ（Discrete Cosine Transform）ベースの技術を用いた構成も可能である。これは配信情報となる例えば画像データをＤＣＴ処理し、ＤＣＴ処理により高域と低域とを区別した階層化を実現し、高域と低域との階層で区分したパケットを生成してデータ配信を実行する方法である。エンコーダ２０４では、上述のＤＣＴ処理、あるいは、ウェーブレット変換のような階層化の可能な符号化方式を実行する。
【００６３】
エンコーダ２０４は上述の階層符号化をあらかじめ設定されたプログレッシブ順序でのプログレッシブ符号化処理を実行する。すなわち上記したフェーブレット変換等に対応する空間解像度によるプログレッシブ、あるいはＳＮＲ（Signal to Noise Ratio）、すなわち画質毎に設定した階層に対応するプログレッシブ、あるいはカラー成分（ＲＧＢやＹＣｂＣｒ）毎の階層に対応するプログレッシブ等、様々なデータ階層に応じたプログレッシブ符号化処理を実行する。
【００６４】
プログレッシプ符号化とは、インターネットの画像配信等において多用される符号化処理であり、データ受信端末側で粗い画像データを先に出力し、順次、細かい画像を出力して表示することを可能とするものである。例えば、空間解像度によるプログレッシブ符号化の場合は、粗い画像に対応する低周波画像データの符号化データから精細な画像に対応する高周波画像データの符号化データを生成する。データの復号、表示を実行する端末では、低周波画像データの符号化データの復号、表示処理をまず実行することで、短時間でディスプレイに粗い概略画像を表示することが可能となり、その後、高周波領域の符号化データを復号し、表示することで、徐々に精細な画像を表示することが可能となる。ＳＮＲ（Signal to Noise Ratio）、すなわち画質によるプログレッシブの場合は、低ＳＮＲ（低画質）の符号化データから高ＳＮＲ（高画質）を区別して符号化する。カラー成分（ＲＧＢやＹＣｂＣｒ）によるプログレッシブの場合は、カラー成分（ＲＧＢやＹＣｂＣｒ）毎の符号化を実行する。
【００６５】
一例としてウェーブレット変換による符号化データの階層化処理について説明する。ウェーブレット変換は、入力画像信号を、ローパスフィルタ、ハイパスフィルタによって帯域分割処理を複数段に渡って実行し、低域成分を階層的に帯域分割した帯域成分を順次生成する処理として実行される。図３は、レベル３まで２次元画像を帯域分割した結果得られる帯域成分を図示したものである。この図３に示す例では、先ずレベル１の帯域分割（水平・垂直方向）により４つの成分ＬＬ、ＬＨ、ＨＬ、ＨＨに分かれる。ここでＬＬは水平・垂直成分が共にＬであること、ＬＨは水平成分がＨで垂直成分がＬであることを意味している。次に、ＬＬ成分は再度帯域分割されて、ＬＬＬＬ、ＬＬＨＬ、ＬＬＬＨ、ＬＬＨＨが生成される。さらに、ＬＬＬＬ成分は再度帯域分割されて、ＬＬＬＬＬＬ、ＬＬＬＬＨＬ、ＬＬＬＬＬＨ、ＬＬＬＬＨＨが生成される。
【００６６】
図２に示すエンコーダ２０４は、例えば上述したウェーブレット変換処理等の階層符号化を実行し、階層化部２０５において、各階層毎に分類され、さらに、優先度付け処理部２０６において各階層毎の優先度付け処理が行なわれる。なお、エンコーダ２０４は、ビットレート制御部２１１からの情報に基づいて符号化態様の変更、例えば符号化階層数等の変更を行なう。ビットレート制御部２１１は、ネットワーク監視部２１５が監視するネットワーク状況を受信する階層エラー訂正優先度制御部２１２の設定した情報に基づいて、エンコーダ２０４の符号化態様の設定を行なう。例えばネットワークの混雑等によるパケットの遅延状況等をネットワーク監視部２１５が検出し、検出情報に基づいてエンコーダ２０４は、符号化階層数等の変更等、符号化態様を動的に変更する。
【００６７】
優先度付け処理部２０６においては、階層符号化データの階層毎の重要度に応じた優先度を付与する。上述したウェーブレット変換データの空間解像度による階層レベル分けを実行した場合において、もっとも重要度の高い階層レベルは、ディスプレイに粗い概略画像を表示するために必要となるデータであり、これは、図３に示す低域（３ＬＬ）データを含む符号化領域、すなわち１／８のサイズのＬＬＬＬＬＬ、ＬＬＬＬＨＬ、ＬＬＬＬＬＨ、ＬＬＬＬＨＨデータ領域３０１に相当する。次の重要度の階層レベルは、次の低域の１／４のサイズのデータ領域となり、ＬＬＬＬ、ＬＬＨＬ、ＬＬＬＨ、ＬＬＨＨデータ領域３０２で構成され、次の重要度の階層レベルは、次の低域の１／２のサイズのデータ領域となり、ＬＬ、ＬＨ、ＨＬ、ＨＨデータ領域３０３で構成される。
【００６８】
優先度付け処理部２０６も、ネットワーク監視部２１５が監視するネットワーク状況を受信する階層エラー訂正優先度制御部２１２の設定した情報に基づいて、設定する優先度を動的に変更可能な構成を持つ。例えばネットワークの混雑等によるパケットの遅延状況等をネットワーク監視部２１５が検出し、この検出情報に基づいて優先度付け処理部２０６は、各符号化データに対して設定する優先度を動的に変更する。
【００６９】
優先度の設定は、例えば図４に示すような設定として実行される。エンコーダ２０４によって階層符号化されたデータを、例えば５階層とした場合、階層０〜階層４までの階層別の符号化データに区分し、これらをそれぞれパケット６５〜６９の５つのパケットにペイロードとして格納する例を示している。
【００７０】
階層０の符号化データが最も重要度の高いデータであり、この階層０の符号化データをペイロードとするＩＰパケット６５のＲＴＰヘッダ（ＲＴＰＨ）には優先度［０］を設定し、また、ＩＰヘッダ（ＩＰＨ）には、優先度［０］を設定する。階層１の符号化データは、次に重要度の高いデータであり、この階層１の符号化データをペイロードとするＩＰパケット６６のＲＴＰヘッダ（ＲＴＰＨ）には優先度［１］を設定し、また、ＩＰヘッダ（ＩＰＨ）には、優先度［１］を設定する。以下、階層２の符号化データをペイロードとするＩＰパケット６７のＲＴＰヘッダには優先度［２］、ＩＰヘッダには優先度［１］、階層３の符号化データをペイロードとするＩＰパケット６８のＲＴＰヘッダには優先度［３］、ＩＰヘッダには優先度［２］、階層４の符号化データをペイロードとするＩＰパケット６９のＲＴＰヘッダには優先度［４］、ＩＰヘッダには優先度［２］を設定する。
【００７１】
このＩＰヘッダ、ＲＴＰヘッダに対する優先度設定処理は、優先度付け処理部２０６内の記憶手段に記憶した優先度設定マップに従って実行される。図５に優先度設定マップの構成例を示す。優先度設定マップは、エンコーダ２０４において符号化された階層毎にＲＴＰヘッダ、ＩＰヘッダに設定する優先度を対応付けたマップである。
【００７２】
図５に示す優先度設定マップの例は、ウェーブレット変換において設定された階層のレベル：０〜４をＲＴＰパケットの拡張ヘッダ（ＲＴＰ共通ヘッダに続くＲＴＰペイロードヘッダ）に設定する優先度：０〜４としてそのまま適用している。また、ＩＰヘッダに設定する優先度は、０〜２の３種類としＩＰネットワークから見た場合の優先度は３レベルとなる。このように階層レベルからＲＴＰのレベルへの優先度の対応付けとＲＴＰレベルからＩＰレベルへの優先度のマッピングを行うことにより、例えば次のような制御が可能となる。
【００７３】
ＲＴＰレベルにおいてはパケットのシーケンス番号を管理しており、インターネットでロスがあった場合にロスしたパケットを検出可能である。パケットロスを検出することにより、受信側は例えばデコーダにパケットロス位置を通知することによって、エラー制御方法を変更することができる。エラー制御方式としては、例えばＦＥＣ(Forward Error Correction)を使用する。ＦＥＣの手法としては、ＡＴＭのＡＡＬ１におけるパケットロスに対してＦＥＣを行う手法、ITU-T Recommendation I.363.1, B-ISDN ATM Adaptation Layer (AAL), types 1 and 2 specificationに記載のマトリックスを作って損失パケットのリードソロモン復号する手法に準じた方法等が適用可能である。
【００７４】
このような処理はすべての階層レベルのパケットに対して同等に処理する必要はなく、例えばネットワークの帯域に応じてＦＥＣ（フォワードエラーコレクション）の冗長度を変化させたり、再送回数を優先度に応じて重み付けする。
【００７５】
なお、図５に示す優先度設定マップは、ネットワーク状況に応じて動的に変更する構成を持つ。ネットワーク監視部２１が取得する帯域監視情報、ＲＴＣＰによる送信パケットの損失率情報等を用いて、送信可能な帯域、保証可能な品質を考慮してマッピング方法を変える。階層レベルをＲＴＰパケットの優先度レベルあるいはＩＰパケットの優先度レベルへマッピングする優先度設定マップを生成する場合、元画像へのロスによる影響をネットワークのロス率を考慮して優先度を決めることが可能である。
【００７６】
このように、本発明のデータ通信システムにおいては、ＲＴＰヘッダのＲＴＰペイロードヘッダ内に、符号化データの階層レベルに応じた優先度を設定した構成としたので、ＲＴＰパケットレベルで上層のアプリケーションに依存した優先度の把握が可能となる。この優先度の把握により、パケットロスに対する処理を変えることが可能である。
【００７７】
このような階層レベル毎の処理はアプリケーションに依存し、ＲＴＰパケットレベルでは優先度に応じてどう処理するかは、ＲＴＰパケットレベルだけで決定してよい。同様に、ＩＰパケットレベルで優先度をつけて処理方法を変えることも可能である。この場合、ＩＰパケットレベルではＤｉｆｆＳｅｒｖのようにネットワークが提供する機能であるからネットワークがサポートする、あるいはネットワークが規定した優先度をつけるためにＲＴＰパケットレベルの優先度からＩＰパケットレベルの優先度へマッピングする。
【００７８】
図５に示す優先度設定マップにおいてはＲＴＰパケットレベルで５段階の優先度を設定し、ＩＰパケットレベルで３段階の優先度を設定した例である。ＲＴＰパケットレベル１がＩＰパケットレベル１に、ＲＴＰパケットレベル２，３がＩＰパケットレベル２に、ＲＴＰパケットレベル４，５がＩＰパケットレベル３に対応している。ＤｉｆｆＳｅｒｖで扱える優先度の数は現状のＩＰｖ４フォーマットでは少ないが、本例のようなマッピングを適用して、３段階の優先度に対応する処理は可能である。
【００７９】
例えば、解像度に基づくプログレッシブ順序に従った符号化データについてのパケット化の場合、低解像度データの符号化データを格納したパケットの優先度が高く、高解像度の符号化データを格納したパケットの優先度が低く設定され、受信端末では、各パケットのＩＰヘッダまたはＲＴＰヘッダに付与された優先度を参照して、低域のパケットを優先して処理することが可能となり、例えばネットワークの輻輳があっても該当するパケットの廃棄される率が下がることにより画質が改善される。
【００８０】
なお、優先度設定マップは、この他にも、様々な態様の構成が可能である。このように、階層符号化されたデータの重要度に応じて、アプリケーションに依存した優先度をＲＴＰペイロードヘッダに設定し、さらに、ＩＰヘッダに優先度を設定することが可能であり、これらの複数の優先度情報を使ってレイヤー毎にエラー制御方法を変えたり、レート制御を実行するなどの処理が可能となる。
【００８１】
ＲＴＰペイロードヘッダに設定する優先度はアプリケーションやユーザの要求、受信側端末から受信する受信側端末情報に応じて動的に変更設定可能であり、ＩＰヘッダに設定する優先度は、ネットワーク状況、例えばネットワークの輻輳度合いに応じて動的に変更設定する。なお、送信側端末２０１のネットワーク監視部は、受信側端末２０２から受信側端末のデータ受信状況に関する情報を受信し、階層エラー訂正優先度制御部２１２は、この情報に基づいて、上述したように、エンコーダ２０４における符号化態様、階層化部２０５における階層設定処理態様、優先度付け処理部２０６における優先度設定処理態様を動的に変更するための制御情報を各処理部に出力する。
【００８２】
このように、優先度付け処理部２０６において、優先度付け処理が行なわれたデータはバッファ２０７ヘ出力され保存される。バッファ２０７に保存された符号化データは、ＦＥＣ(Forward Error Correction)処理部２０８において、エラー訂正のための冗長コードが必要に応じて付与される。ＦＥＣの手法としては、ＡＴＭのＡＡＬ１におけるパケットロスに対してＦＥＣを行う手法、ITU-T Recommendation I.363.1, B-ISDN ATM Adaptation Layer (AAL), types 1 and 2 specificationに記載のマトリックスを作って損失パケットのリードソロモン復号する手法に準じた方法等が適用可能である。なお、ＦＥＣ(Forward Error Correction)処理部２０８における、エラー訂正のための冗長コード付与処理は、個々のデータに基づく冗長コード付与ではなく、エラー耐性を高めるために複数のデータに渡るテータに基づいて冗長コードを付与する処理、すなわちインターリーブ処理を併せて実行する構成としてもよい。
【００８３】
このＦＥＣ(Forward Error Correction)処理部２０８における、エラー訂正のための冗長コード付与処理はすべての階層レベルのパケットに対して同等に処理する必要はなく、ＦＥＣ(Forward Error Correction)処理部２０８は、例えばネットワークの混雑等によるパケットの遅延状況、ネットワークの帯域等をネットワーク監視部２１５が検出し、この検出情報に基づいてＦＥＣ（フォワード・エラー・コレクション）の冗長度を変化させる等、処理を動的に変更する。
【００８４】
上述のように、送信側端末２０１は、ネットワーク監視部２１５の情報、すなわち、受信側端末２０２からの受信側端末のデータ受信状況に関する情報、ネットワーク状況に関する情報に基づいて、エンコーダ２０４における符号化態様、階層化部２０５における階層設定処理態様、優先度付け処理部２０６における優先度設定処理態様、ＦＥＣ(Forward Error Correction)処理部２０８における処理を動的に変更可能である。
【００８５】
上述した送信側端末の処理構成に基づいて、例えば符号化階層（レイヤー）毎に実行すべきエラー処理態様として、ＦＥＣ処理対象階層データとしたり、あるいは再生要求処理（ＡＲＱ：Auto Repeat reQuest）対象階層データとしての割り当てが可能となり、各階層において最適なエラー訂正とスループットを得ることが可能となる。つまり、伝送路状況がエラー率が高かったり遅延が大きいなどパケット再生処理（ＡＲＱ：Auto Repeat reQuest）に不利な状況ではＦＥＣでエラー訂正を実行する設定としたり、あるいは伝送遅延が小さいが冗長データを送りたくない場合には、ＦＥＣではなくＡＲＱを利用したエラー対応とするなど、送信側で任意のエラー対応設定としたデータパケットの送信が可能となる。
【００８６】
また、受信側端末においても同様のネットワーク監視部２２９を有しており、ネットワークの混雑等によるパケットの遅延状況、ネットワークの帯域等の情報に基づいて、ネットワーク状況が良い場合には、階層を上げてより高品質なデータを再生する等の動的な対応が可能となる。
【００８７】
図２の送信側端末２０１の構成について説明を続ける。ＦＥＣ処理部２０８において、必要に応じてエラー訂正用の冗長コードが付与されたデータは、リアルタイム・トランスポート・プロトコル：ＲＴＰ（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）方式など種々の方法が提案され実現されている。
【００９９】
本発明のシステムにおいては、上述のようにＦＥＣとＡＲＱを組み合わせて、よりエラー耐性の強いデータ伝送が実現される。受信側端末２０２では、ネットワーク状況とバッファ状況、再生状況によって階層を落とさなくても、ＦＥＣ処理およびＡＲＱ処理にてその階層の品質が得られるならば、エラー訂正によって処理し、処理対象データの階層を落とすことによるデータ品質低下はできるだけ行わないよう制御する。
【０１００】
また、受信側端末の階層選択制御部２３１は、ネットワーク状況を監視するネットワーク状況監視部２２９のネットワーク状況情報に基づく処理データの選択を実行し、送信側端末の設定した階層または優先度に従って処理データを選択して実行する。例えばネットワーク状況が悪くパケットロス、遅延が大きい場合には、基本階層のみあるいは、優先度の高いデータのみを選択して処理を実行したり、ネットワーク状況がよくパケットロス、遅延が少ない場合には、より高階層のデータあるいは、優先度の低いデータも選択して処理を実行するなど、ネットワーク状況に応じたデータ選択処理を実行する。
【０１０１】
図２のデータ通信システムにおける受信側端末２０２のエラー訂正制御部２２３の処理について、さらに説明する。エラー訂正制御部２２３は、ネットワーク監視部２２９によって監視されている現在のネットワーク状況を踏まえてエラー訂正を制御する。ネットワークの監視は、往復伝播遅延（ＲＴＴ）やパケットロス率などＲＴＣＰやＩＣＭＰなどの汎用のプロトコルを利用して取得する。ＡＲＱにおいてデータ再生におけるリアルタイム性を保持するためには、常に送信と受信における往復伝播遅延（ＲＴＴ）を計測しておく必要がある。本発明のシステムでは、データ受信側端末は、能動的にＲＴＴを計測し、ネットワーク状況等において変化する送信と受信における往復伝播遅延（ＲＴＴ）の更新を実行し、最新のＲＴＴに基づいて再送要求としてのＮＡＣＫ−ＲＴＣＰの送信の実行可否を判定する。
【０１０２】
送信と受信における往復伝播遅延（ＲＴＴ）をデータ受信端末において、あらかじめ把握することにより、データ受信端末において、再送要求を行なってから再送パケットを受信するまでの時間の把握が可能となり、データ受信端末においてリアルタイム再生を行なうために必要な最終再送要求時間を割り出すことが可能なる。本発明のシステムでは、受信端末のＡＲＱ判定部において、往復伝播遅延（ＲＴＴ）に基づく最終再送要求時間を判定し、判定に基づいて、再送要求としてのＮＡＣＫ−ＲＴＣＰの送信を実行する。これらの処理については、次の各端末の処理フローの説明において詳細に説明する。
【０１０３】
［データ送信端末における処理］
以下、図面を参照しながら、データ送信端末における処理の詳細について説明する。
【０１０４】
データ送信端末の処理手順を図８に示すフローチャートを参照して説明する。図８に示す処理は、図２の送信側端末２０１において実行される処理を説明したフローである。送信側端末は、例えばビデオカメラ、あるいはＤＶＤ、ＣＤ、ハードディスク等の記憶媒体から撮り込んだデータをエンコーダにおいてＭＰＥＧ圧縮等の符号化処理を実行し、その後、符号化データをペイロードとしたパケットを生成する。図８に示すフローは、このパケット生成処理以降の処理を示している。
【０１０５】
データ送信端末は、ステップＳ３０１において、送信データをペイロードとしたＲＴＰパケット生成処理を実行する。ＲＴＰパケットは、先に図６を参照して説明した構成を有しタイムスタンプをヘッダ中に持つ。例えば動画像データを送信する場合は、同一画像フレームに属する符号化データを格納したパケットには同一のタイムスタンプが設定され、後続フレームに進むに従って、増分されたタイムスタンプが設定される。
【０１０６】
ステップＳ３０１で生成したＲＴＰパケットは、ステップＳ３０２、ステップＳ３０３において、必要に応じてＦＥＣ(Forward Error Correction)処理部２０８が、エラー訂正のための冗長コード付与処理を実行する。先に説明したように、ＦＥＣ処理部２０８における処理は動的に変更され、例えばネットワークの混雑等によるパケットの遅延状況、ネットワークの帯域等をネットワーク監視部２１５が検出し、この検出情報に基づいてＦＥＣ（フォワード・エラー・コレクション）の冗長度を変化させたり、あるいは冗長コードの付与対象の階層を変更して処理を実行する。ＦＥＣ処理部における処理を実行しないデータに対しては、ステップＳ３０３を飛ばしてステップＳ３０４に進む。
【０１０７】
ＦＥＣ処理部２０８は、ネットワーク監視部２１５が検出したネットワーク状況情報に基づいて階層エラー訂正優先度制御部２１２が生成した制御情報を入力して、入力する制御情報に基づいて処理態様が決定される。なお、前述したように、ＦＥＣ処理部２０８におけるエラー訂正のための冗長コード付与処理は、個々のデータに基づく冗長コード付与ではなく、エラー耐性を高めるために複数のデータに渡るテータに基づいて冗長コードを付与する処理、すなわちインターリーブ処理が併せて実行される。
【０１０８】
次に、ステップＳ３０４において、ＲＴＰポートを介して受信端末に向けてＩＰネットワークに出力される。なお、ＲＴＰパケットはさらに、先に図７を用いて説明したＩＰヘッダが付与され、ＩＰヘッダに設定されたアドレスに向けて配信されることになる。パケット生成、パケット送信処理は、ストリーミング配信されるデータが終了したことを明示的に示すＥＯＳ（End Of Stream）を配信し、予め設定した時間をタイマーで計測して、タイマーでの計測時間が設定時間を超えた場合に、処理を終了する。
【０１０９】
図８に示すステップＳ３０５のパケット再送要求としてのＮＡＣＫ−ＲＴＣＰパケットの受信判定処理、ステップＳ３０６のパケット受信確認応答としてのＡＣＫ−ＲＴＣＰパケットの受信判定処理、ステップＳ３０７のＲＴＴ時間計測用のＥＣＨＯ−ＲＴＣＰパケットの受信判定処理は、ＲＴＰパケットによる実データ送信中の割込み処理としてＲＴＰパケットによる実データ送信に並行して逐次実行される処理である。
【０１１０】
ステップＳ３０５の処理は、データ受信端末からのパケット再送要求であるＮＡＣＫ−ＲＴＣＰパケットの受信判定処理である。データ受信端末からのパケット再送要求であるＮＡＣＫ−ＲＴＣＰパケットを受信した場合は、ステップＳ３１３〜Ｓ３１７の処理を実行する。このステップＳ３１３〜Ｓ３１７の処理は、図２に示すエラー訂正制御部２３０における処理として実行される。
【０１１１】
ステップＳ３１３においては、データ送信装置は、ＮＡＣＫ−ＲＴＣＰパケットを受信する。図９にデータ受信端末において生成し、データ送信端末の受信するパケット再送要求であるＮＡＣＫ−ＲＴＣＰパケットの構成を示す。
【０１１２】
ＮＡＣＫ−ＲＴＣＰパケットは、図９に示すようにヘッダ（ＨＥＡＤ）、フォーマット（ＦＯＲＭＡＴ）、パケットタイプ、パケット長、送信同期ソース識別子（ＲＴＣＰ）、タイムスタンプの情報に加えて、再送要求対象となるパケットの識別子としての再送指定シーケンス番号、さらに、各再送指定シーケンス番号に対応するデータとして、「再送回数」、「オプション」、「重複指定回数」が設定可能である。
【０１１３】
前述したように、本発明の提案するＡＲＱを適用したシステムでは、ＲＴＣＰに従ったコントロール・パケットとして再送要求としてのＮＡＣＫ、受信確認としてのＡＣＫ、ストリーミング配信されるデータが終了したことを明示的に示すＥＯＳ、送信と受信における往復伝播遅延（ＲＴＴ）を計測する際に使用されるＥＣＨＯ、およびＥＣＨＯ−ＲＥＰＬＹのパケットが利用される。これらの各ＲＴＣＰパケットそれぞれのフォーマットタイプを一制御メッセージとして、すなわちＲＴＣＰヘッダのＰＴ（Payload Type）として区別をするのは汎用的ではない。よって、制御メッセージとしては、フィードバックメッセージ（FM：Feedback Message）として定義しＰＴ（Payload Type）に指定する。かつ、ＲＴＣＰヘッダ内の［フォーマット］フィールドであるＦＭＴ (Feedback Message Format)にそのパケットフォーマットの指定をすることで、どのようなフィードバックメッセージかを決定できる構成とする。
【０１１４】
図９に示すように、１つのＮＡＣＫパケットには１つ以上の再送要求対象となるパケットの識別子としてのシーケンス番号を付与することができる構成を持つ。つまり一度のＮＡＣＫパケットの送信処理で複数のパケットについての再送要求が可能になる。また、再送要求パケットのシーケンス番号各々に対して付加される「再送回数」は、何回目の再送要求かを明記するフィールドであり、「重複指定回数」は、再送する場合の多重回数の指定を明記するフィールドであり、「オプション」はその他の任意の情報を格納するフィールドとして使用される。
【０１１５】
例えば、「重複指定回数」に［３］をいれておけば、ＮＡＣＫを受信したデータ送信側は、同じデータを格納した再送パケットを［３］つ連続で送る処理を実行する。重要データを格納したパケットについては、重複再送を要求することで、再送パケットの受信の確実性を高めることが可能となる。また、繰り返し、同一パケットについての再送要求としてのＮＡＣＫを送信しているにもかかわらず、受信に成功しない場合や、リアルタイム再生に間に合うための再送可能最終時間に出されるＮＡＣＫにおいて、「重複指定回数」の設定数を増加させてデータ送信側に送信することにより、再送パケットの受信の確実性を高めることが可能となり、データ再生品質を向上させることが可能となる。データ受信側は、このようなＮＡＣＫ−ＲＴＣＰパケットを送信して、データ送信側は、受信したＮＡＣＫ−ＲＴＣＰパケットに基づくパケット再送処理を実行する。
【０１１６】
なお、ＲＴＰパケットフォーマットやペイロードフォーマット、または受信端末の利用者が意図的に指定した場合など、パケットに優先度が与えられている場合、優先度が高いパケットやデータに関しての再送は多重再送処理を行なうことで、再送パケットの受信確率を高めるようコントロール可能である。また、「再送回数」フィールドにおいて何回目の再送要求かを明記することで、ＮＡＣＫ自身が損失したことを送信側が検知できる。
【０１１７】
「オプション」フィールドには、フィールド設定値に従って、例えば図１０に示す処理指定を行なうことが可能となる。すなわち、
オプション設定値＝０
指定シーケンス番号を持つパケットのみの再送要求（デフォルト）
オプション設定値＝１
フレーム先頭パケットから指定シーケンス番号を持つパケットまでの一括再送要求
オプション設定値＝２
指定シーケンス番号からフレーム最後尾までのパケットの一括再送要求
オプション設定値＝３
指定タイムスタンプの付与されたパケットの一括再送要求
オプション設定値＝４
タイムスタンプを無視してシーケンス番号のみで検索して検索結果のパケットの再送を要求
【０１１８】
画像データ等の符号化データは、先に図６を参照して説明したように、タイムスタンプとシーケンス番号をセットとしたヘッダを持つ１つのＲＴＰパケットに格納した構成を有するが、データ転送処理において、タイムスタンプの変わり目を含んた連続的なエラーとしてのバーストエラーが起こった場合、あるいは、バーストエラーの発生により、フレーム単位でパケットの損失が発生した場合などにおいては、受信端末側では、パケット損失の発生したパケットに対応するタイムスタンプとシーケンス番号のセットを特定できない場合が発生する。このような場合において、特定可能なタイムスタンプ、あるいはシーケンス番号のいずれか一方のみを指定して、上記のオプション設定値を設定することにより、フレキシブルな態様で再送の必要な１以上のパケット指定が可能となる。
【０１１９】
このように、データ受信端末では、様々な態様での再送要求パケットの指定が可能であり、ＮＡＣＫ−ＲＴＣＰパケットを受信したデータ送信端末のＡＲＱ制御部２１３は、オプションフィールドの設定値に従って、バッファ２０７に格納済みのパケットから指定パケットを抽出して、再送処理を実行する。
【０１２０】
図８に戻り、データ送信端末の処理について説明する。ステップＳ３１４では、ステップＳ３１２で受信したＮＡＣＫ−ＲＴＣＰパケットに指定された再送要求パケットに対応するシーケンス番号を抽出し、ステップＳ３１５では、オプション指定の抽出を実行する。上述したように再送要求パケットの指定態様は、シーケンス番号の直接指定のみならず、タイムスタンプ等による指定等、様々であり、データ送信端末装置のＡＲＱ制御部２１３では、受信したＮＡＣＫ−ＲＴＣＰパケットに指定されたオプション指定、およびタイムスタンプ、シーケンス番号を参照して、再送要求パケットを特定する処理を実行する。
【０１２１】
ステップＳ３１６では、特定された再送要求パケットをバッファ２０７から抽出する。バッファ２０７には、再送要求に備えて所定時間、送信済みのパケットが保持格納されており、これらの格納パケットから再送指定のあったパケットを抽出する処理を実行する。ステップＳ３１７で、ＲＴＰポートから抽出パケットが送信される。
【０１２２】
ステップＳ３０５において、ＮＡＣＫ−ＲＴＣＰパケットを受信しない場合は、ステップＳ３０６でパケット受信応答としてのＡＣＫ−ＲＴＣＰパケットの受信確認を行ない、ＡＣＫ−ＲＴＣＰパケットの受信に基づいて、ステップＳ３１１で、受信の確認されたパケットをバッファ２０７からクリア（削除）する。このＡＣＫにより、再送要求に対応してパケットを保持する送信側のバッファを能動的に早めにクリアすることが可能となり、バッファ溢れの恐れを低下させることが可能となる。
【０１２３】
図１１にデータ受信端末において生成し、データ送信端末の受信するパケット受信確認応答であるＡＣＫ−ＲＴＣＰパケットの構成を示す。
【０１２４】
ＡＣＫ−ＲＴＣＰパケットは、図１１に示すようにヘッダ（ＨＥＡＤ）、フォーマット（ＦＯＲＭＡＴ）、パケットタイプ、パケット長、送信同期ソース識別子（ＲＴＣＰ）、タイムスタンプの情報に加えて、受信パケットの識別子としての受信済みシーケンス番号が格納される。
【０１２５】
なお、シーケンス番号を指定せず、タイムスタンプ（TIMESTAMP）のみ指定する構成とすることも可能であり、この場合には、そのタイムスタンプ（TIMESTAMP）の設定されたパケットすべてを受け取った事を示す。よってこのような場合にはシーケンス番号をすべて指定する必要はないため、ＡＣＫ−ＲＴＣＰパケットサイズを小さくすることが可能となり、ネットワークトラフィックの増大を低減できる。
【０１２６】
図８に戻り、データ送信端末の処理の説明を続ける。データ送信端末は、ステップＳ３０７において、ＥＣＨＯ−ＲＴＣＰパケットの受信確認を行ない、データ受信端末からＥＣＨＯ−ＲＴＣＰパケットを受信した場合は、ステップＳ３１１において、ＥＣＨＯ−ＲＥＰＬＹ−ＲＴＣＰパケットをＥＣＨＯ−ＲＴＣＰパケットを送信してきたデータ受信端末に対して送信する処理を実行する。
【０１２７】
ＥＣＨＯ−ＲＴＣＰパケットと、ＥＣＨＯ−ＲＥＰＬＹ−ＲＴＣＰパケットは、送信端末と受信端末における往復伝播遅延（ＲＴＴ）をデータ受信端末において把握するために用いるＲＴＣＰパケットである。このパケットの送受信によって、データ受信端末において、再送要求を行なってから再送パケットを受信するまでの時間の把握が可能となり、データ受信端末においてリアルタイム再生を行なうために必要な最終再送要求時間を割り出すことが可能なる。
【０１２８】
本発明のシステムでは、受信端末のエラー訂正制御部２３０において、往復伝播遅延（ＲＴＴ）に基づく最終再送要求時間を判定し、判定に基づいて、再送要求としてのＮＡＣＫ−ＲＴＣＰの送信の実行可否を決定する。この判定処理に必要な送信端末と受信端末における往復伝播遅延（ＲＴＴ）の最新情報を取得するため、データ受信端末側は、任意タイミングで、能動的にＥＣＨＯ−ＲＴＣＰパケットをデータ送信端末に送信し、データ送信端末は、ＥＣＨＯ−ＲＴＣＰパケットの受信に応答してＥＣＨＯ−ＲＥＰＬＹ−ＲＴＣＰパケットをＥＣＨＯ−ＲＴＣＰパケットを送信してきたデータ受信端末に対して送信する。
【０１２９】
データ受信端末では、データ送信端末からの応答として受信するＥＣＨＯ−ＲＥＰＬＹ−ＲＴＣＰパケットを解析することによって、送信端末と受信端末における往復伝播遅延（ＲＴＴ）を算出する。このＲＴＴ算出処理については、後段のデータ受信端末の処理の項目で説明する。
【０１３０】
図１２にデータ受信端末において生成し、データ送信端末の受信するＥＣＨＯ−ＲＴＣＰパケットの構成、および、データ送信端末において生成し、データ受信端末に対して送信するＥＣＨＯ−ＲＥＰＬＹ−ＲＴＣＰパケットの構成を示す。
【０１３１】
ＥＣＨＯ−ＲＴＣＰパケットは、図１２（ａ）に示すようにヘッダ（ＨＥＡＤ）、フォーマット（ＦＯＲＭＡＴ）、パケットタイプ、パケット長、送信同期ソース識別子（ＲＴＣＰ）、およびＥＣＨＯパケットの識別データとしてのＥＣＨＯ−ＩＤが格納される。ＥＣＨＯ−ＲＥＰＬＹ−ＲＴＣＰパケットは、図１２（ｂ）に示すようにヘッダ（ＨＥＡＤ）、フォーマット（ＦＯＲＭＡＴ）、パケットタイプ、パケット長、送信同期ソース識別子（ＲＴＣＰ）、およびＥＣＨＯ−ＲＴＣＰパケットに対応するＥＣＨＯ−ＩＤ、および、サーバ処理時間が格納される。
【０１３２】
ＥＣＨＯ−ＩＤをＥＣＨＯ−ＲＴＣＰパケットとＥＣＨＯ−ＲＥＰＬＹ−ＲＴＣＰパケットに入れることにより、データ受信端末側がＥＣＨＯ−ＲＥＰＬＹを受け取った際に、いつ送信したＥＣＨＯ−ＲＴＣＰパケットに対応する返事（ＥＣＨＯ−ＲＥＰＬＹ）かを識別することが可能となる。ＥＣＨＯ−ＲＥＰＬＹ−ＲＴＣＰパケットに格納されるサーバ処理時間は、データ送信端末がデータ受信端末からの再送要求（ＮＡＣＫ−ＲＴＣＰ）を受信してからパケットをデータ送信端末から出力するまでに要する処理時間に相当する時間である。このサーバ処理時間は、ＥＣＨＯ−ＲＴＣＰパケットを受信した時間からＥＣＨＯ−ＲＥＰＬＹ−ＲＴＣＰパケットを送信するまでの時間として設定するか、あるいは、予めデータ送信端末において過去の履歴データとして、実際に、データ送信端末がデータ受信端末からの再送要求（ＮＡＣＫ−ＲＴＣＰ）を受信してからパケットをデータ送信端末から出力するまでに要した時間をメモリに格納し、この格納データを適用してもよいし、あるいは、ＥＣＨＯ−ＲＴＣＰパケットを受信した時点におけるサーバ（データ送信端末）における処理負荷を算出して、処理負荷に基づいて算出される予測処理時間をサーバ処理時間として設定する構成としてもよい。
【０１３３】
データ受信端末は、ＥＣＨＯ−ＲＥＰＬＹ−ＲＴＣＰパケットに格納されたサーバ処理時間と、ＥＣＨＯ−ＲＴＣＰパケット送信からＥＣＨＯ−ＲＥＰＬＹ−ＲＴＣＰの受信までの時間とに基づいて、送信端末と受信端末における往復伝播遅延（ＲＴＴ）を算出する。このＲＴＴ算出処理については、後段のデータ受信端末の処理の項目で説明する。
【０１３４】
図８に戻り、データ送信端末の処理の説明を続ける。データ送信端末は、ステップＳ３０６において、送信対象となるストリーミングデータのパケット送信がすべて終了したかを判定し、終了と判定した場合は、ステップＳ３１０において、データストリームの終了を明示するＥＯＳ（End Of Stream）メッセージを持つＲＴＣＰパケットを受信側端末へ送信する処理を実行する。
【０１３５】
図１３にデータ送信端末において生成し、データ受信端末の受信するＥＯＳ−ＲＴＣＰパケットの構成を示す。
【０１３６】
ＥＯＳ−ＲＴＣＰパケットは、図１３に示すようにヘッダ（ＨＥＡＤ）、フォーマット（ＦＯＲＭＡＴ）、パケットタイプ、パケット長、送信同期ソース識別子（ＲＴＣＰ）、およびタイムスタンプ（ＴＩＭＥＳＴＡＭＰ）が格納される。データ受信端末は、ＥＯＳ−ＲＴＣＰパケットをデータ送信端末から受信することにより、ストリーミング配信されるデータの終了を認識する。受信端末はこの認識処理により、次フレームが到着しないことによる誤ったＮＡＣＫ送出動作を防ぐことができる。
【０１３７】
図８に戻り、データ送信端末の処理の説明を続ける。データ送信端末は、ステップＳ３０９において、予め設定した時間を計測するタイマーでの計測時間が設定時間を超えたか否かを判定して、タイマーが設定時間を超えていない場合は、ステップＳ３０５以下の処理、すなわち、ステップＳ３０５のパケット再送要求としてのＮＡＣＫ−ＲＴＣＰパケットの受信判定処理以下の処理を継続して実行する。これは、全パケット送出後においても、一定時間は、データ受信側からのパケット再送要求としてのＮＡＣＫ−ＲＴＣＰパケット、または、受信確認応答としてのＡＣＫ−ＲＴＣＰパケット、または、ＥＣＨＯ−ＲＴＣＰパケットを受信する可能性があり、これらのパケット受信に対する処理を実行するためである。タイマーにおいて、予め設定した時間が経過した時点で、データ送信を終了する。
【０１３８】
［データ受信端末における処理］
次に、データ受信端末の処理手順を図１４に示すフローチャートを参照して説明する。図１４に示す処理は、図２の受信側端末２０２において実行される処理を説明したフローである。
【０１３９】
データ受信端末は、ステップＳ４００において、データ送信端末からの送信開始通知を受信後、ステップＳ４０１において、データ送信端末からの送信パケット、すなわち符号化データをペイロードとして格納したＲＴＰパケットを順次、受信する。ＲＴＰパケットは、先に、図６を参照して説明したように、タイムスタンプがヘッダ情報中に格納されている。データ受信端末は、タイムスタンプに基づいて受信するパケットに含まれるフレームを判別することができる。先に説明したように、動画像データをＲＴＰパケットに符号化データとして格納して送信する場合、同一の画像フレームに属する複数のＲＴＰパケットには同一のタイムスタンプが設定され、データ受信側端末は、タイムスタンプを参照して、フレームの判別が可能となる。
【０１４０】
データ受信端末は、ステップＳ４０２において、受信パケットがエラー訂正のための冗長コードが付与されているか否かを判定する。冗長コードが付与されている場合は、ステップＳ４１１に進み、エラー訂正制御部２３０において、データ送信側で実行したインターリーブ対応するインターリーブ処理を実行して、ステップＳ４１２において、損失パケットの有無を判定する。損失パケットが無い場合は、ステップＳ４１６のデコード処理に進む。損失パケットがある場合は、ステップＳ４１３で、ＦＥＣによるエラー訂正、すなわち冗長コードに基づくエラー訂正処理を実行し、エラー訂正により再生可能か否かを判定する。再生可能であると判定した場合は、ステップＳ４１６のデコード処理に進む。
【０１４１】
ステップＳ４１３においてＦＥＣによる処理のみでは、再生可能でないと判定した場合は、ステップＳ４１５に進む。ステップＳ４１５の再送要求処理としてのＮＡＣＫ−ＲＴＣＰパケットの送信判定処理について説明する。リアルタイム再生処理を実現するためには、再生タイミングに間に合うように、再送要求パケットが受信端末に届くことが必要となる。ステップＳ４１５の再送要求処理としてのＮＡＣＫ−ＲＴＣＰパケットの送信判定処理は、ＮＡＣＫ−ＲＴＣＰパケットを送信した場合、リアルタイム再生処理に間に合うタイミングで、再送パケットが受信可能か否かを判定するものである。
【０１４２】
この判定のためには、前述したように、送信端末と受信端末間における往復伝播遅延（ＲＴＴ）が重要なパラメータとなる。往復伝播遅延（ＲＴＴ）が大きい場合、データ受信端末からデータ送信端末に対して再送要求を出しても、再送要求を発信して、再送パケットがデータ送信端末から再送され、データ受信端末において受信するまでに時間を要すると、その後デコーダに渡して復号を行なってリアルタイム再生に間に合わない場合が発生する。本発明のシステムでは、データ受信端末において、往復伝播遅延（ＲＴＴ）をあらかじめ把握し、往復伝播遅延（ＲＴＴ）に基づいて、ＮＡＣＫ−ＲＴＣＰパケットの送信判定処理を行なう。
【０１４３】
本発明のシステムにおいては、データ受信端末側が、任意タイミングで、往復伝播遅延（ＲＴＴ）の計測を実行することを可能な構成としている。具体的には、データ受信端末から、先に説明した図１２に示すＥＣＨＯ−ＲＴＣＰパケットを送信し、ＥＣＨＯ−ＲＥＰＬＹ−ＲＴＣＰパケットを受信して、ＲＴＴの算出を行なう。
【０１４４】
図１５を参照して、データ受信端末で実行するＥＣＨＯ−ＲＴＣＰパケットの送信、ＥＣＨＯ−ＲＥＰＬＹ−ＲＴＣＰパケットの受信、往復伝播遅延（ＲＴＴ）の算出処理について説明する。
【０１４５】
図１５（ａ）は、ＥＣＨＯ−ＲＴＣＰパケットの送信処理フローである。ＥＣＨＯ−ＲＴＣＰパケットの送信は、データ受信端末が任意タイミングで能動的に実行することが可能である。
【０１４６】
ステップＳ５０１における、ＲＴＣＰパケットの送信待機状態において、ＲＴＴの計測要請が発生した場合、ステップＳ５０２のＥＣＨＯ−ＲＴＣＰパケットの生成処理に移行する。ＲＴＴの計測は、データ受信が開始された後、例えば図１４の処理フローにおいて、ステップＳ４００の送信開始通知を受信した以降、定期的に実行する等の設定が可能であり、データ受信側端末に保有するタイマーで予め定めた計測間隔が経過したか否かを計測し、予め定めた計測間隔に対応する時間が経過した場合に、エラー訂正制御部２３０が、ＥＣＨＯ−ＲＴＣＰパケットの生成要求をＲＴＣＰパケット生成部２２７に出力し、ＲＴＣＰパケット生成部２２７がステップＳ５０２のＥＣＨＯ−ＲＴＣＰパケットの生成処理を実行するなどの設定が可能である。この他にも、パケットのロスト状況を解析し、ロスト状況に応じてＥＣＨＯ−ＲＴＣＰパケットの生成、送信を実行する構成としてもよく、いずれにしても、データ受信端末は、任意タイミングで、ＥＣＨＯ−ＲＴＣＰパケットの生成、送信が可能であり、常に最新の往復伝播遅延（ＲＴＴ）の算出が可能となる。
【０１４７】
ステップＳ５０２で生成するＥＣＨＯ−ＲＴＣＰパケットは、先に図１２（ａ）を参照して説明した構成を有する。パケットには、各パケット固有の識別子としてのＥＣＨＯ−ＩＤが設定される。ステップＳ５０３で、生成したＥＣＨＯ−ＲＴＣＰパケットが、ＲＴＣＰポート２２５を介して、データ送信端末２０１に対して送信される。ステップＳ５０４では、ＥＣＨＯ−ＲＴＣＰパケットを送信した送信時間、および、パケットに設定されたＥＣＨＯ−ＩＤがメモリに記録される。
【０１４８】
図１５（ｂ）は、ＥＣＨＯ−ＲＥＰＬＹ−ＲＴＣＰパケットの受信およびＲＴＴ算出処理フローである。ステップＳ６０１における、ＲＴＣＰパケットの送信待機状態において、ＥＣＨＯ−ＲＥＰＬＹ−ＲＴＣＰパケットが受信されたと判定（ステップＳ６０２でＹｅｓ）されると、ステップＳ６０３において、ＥＣＨＯ−ＲＥＰＬＹ−ＲＴＣＰパケットの受信時刻がメモリに記録される。受信するＥＣＨＯ−ＲＥＰＬＹ−ＲＴＣＰパケットは、先に図１２（ｂ）を参照して説明した構成を有する。パケットには、応答対象となった対応するＥＣＨＯ−ＲＴＣＰパケットと同一の識別子としてのＥＣＨＯ−ＩＤが設定され、さらに、データ送信端末において算出したサーバ処理時間が格納される。
【０１４９】
ステップＳ６０４では、受信したＥＣＨＯ−ＲＥＰＬＹ−ＲＴＣＰパケットからサーバ処理時間が抽出され、ステップＳ６０５において、受信したＥＣＨＯ−ＲＥＰＬＹ−ＲＴＣＰパケットに設定されたＥＣＨＯ−ＩＤから対応するＥＣＨＯ−ＲＴＣＰパケットの送信時間が検索される。
【０１５０】
ステップＳ６０６では、ステップＳ６０３において取得したＥＣＨＯ−ＲＥＰＬＹ−ＲＴＣＰパケットの受信時刻、ステップＳ６０４において取得したサーバ処理時間、ステップＳ６０３において取得したＥＣＨＯ−ＲＴＣＰパケットの送信時間に基づいて、往復伝播遅延（ＲＴＴ）の算出処理が実行される。往復伝播遅延（ＲＴＴ）の算出は、下式に基づいて実行される。
往復伝播遅延（ＲＴＴ）
＝(ECHO-REPLAY受信時刻)-(ECHO送信時刻)-(サーバ処理時間)
【０１５１】
なお、ＲＴＴの計測を実行する際に送受信するＥＣＨＯ，ＥＣＨＯ−ＲＥＰＬＹパケットも損失することが考えられる。またＲＴＴもネットワークの状況により常に変動するため、データ受信端末は一定間隔でＥＣＨＯ，ＥＣＨＯ−ＲＥＰＬＹパケットの送受信処理を実行してＲＴＴを計測する。
【０１５２】
図１４のフローに戻り、データ受信端末側の処理について説明を続ける。図１４のフローにおいて、ステップＳ４１５では、再送要求としてのＮＡＣＫ−ＲＴＣＰを出力した場合、リアルタイム再生処理に間に合うタイミングで再送要求パケットの受信が可能か否かを判定する。上述したＥＣＨＯ，ＥＣＨＯ−ＲＥＰＬＹパケットの送受信処理により計測されたＲＴＴ値と、各フレームの処理タイミングを計測しているタイマーの期限に基づいて、再送要求としてのＮＡＣＫ−ＲＴＣＰパケットを出しても間に合わないと判断した場合（Ｓ４１５でＮｏ）には、ＮＡＣＫ−ＲＴＣＰパケットの送信処理は実行しない。
【０１５３】
たとえば、パケット損失の存在する該当フレームの符号化データの処理開始までの時間Ｔａ＝１００ｍｍｓｅｃである場合、すなわち１００ｍｍｓｅｃ後にデコーダにデータを渡して復号処理が開始されることがタイマーの計測により明らかとなっている場合、計測された最新のＲＴＴ値が、該当フレームの符号化データの処理開始までの時間Ｔａより大きい値であった場合、すなわち、１００ｍｍｓｅｃ以上であった場合には、再送要求としてのＮＡＣＫ−ＲＴＣＰパケットを送信しても、再送パケットの受信が、デコード処理開始タイミングに間に合わないものと判断して、ＮＡＣＫ−ＲＴＣＰパケットの送信処理を実行しない。ただし、ＲＴＴ値が処理開始までの時間Ｔａ以上であっても、ＲＴＴ値と時間：Ｔａの非常に近い値を持つ場合には、ぎりぎり間に合う可能性もあるためＮＡＣＫを送出する構成としてもよい。このＮＡＣＫ送出判定の閾値は実装依存である。
【０１５４】
一方、計測された最新のＲＴＴ値が、パケット損失の存在する該当フレームの符号化データの処理開始までの時間Ｔａ以下であった場合には、再送要求としてのＮＡＣＫ−ＲＴＣＰパケットを送信して再送パケットを受信するまでの時間が、デコード処理開始タイミングまでの時間以下であるので、再送パケット受信が処理に間に合うものと判断して、ステップＳ４１７において、ＮＡＣＫ−ＲＴＣＰパケットの送信処理を実行する。
【０１５５】
図１４のフローのステップＳ４０２において、ＦＥＣによる冗長コードんが付与されていないパケットであると判定した場合は、ステップＳ４０３において、受信したパケットが、ｎフレーム目（ｎ=１，２...）の終端パケットであるか否かを判定する。また、ステップＳ４０４において、受信したパケットが、ｎ＋１フレーム目の先頭パケットであるか否かを判定する。受信したパケットが、ｎフレーム目（ｎ=１，２...）の終端パケットである場合、または、ｎ＋１フレーム目の先頭パケットである場合には、ステップＳ４１４に進む。
【０１５６】
ステップＳ４１４においては、ｎフレーム内に未受信のパケット、すなわちロストパケット、あるいはエラーパケットがあるか否かを判定する。
【０１５７】
ロストパケットまたはエラーパケットが検出されると、ステップＳ４１５以下の処理に進み、再送要求処理としてのＮＡＣＫ−ＲＴＣＰパケットの送信判定処理、および判定に基づくＮＡＣＫ−ＲＴＣＰパケットの送信処理が実行される。これらの判定処理の詳細は、前述した通りである。
【０１５８】
ＮＡＣＫ−ＲＴＣＰパケット送信の際にタイムスタンプ（TIMESTAMP）とシーケンス番号の組み合わせがはっきりしない場合には、先に図１０を参照して説明したオプションを指定して送信する。データ受信端末では、パケットの送受信情報を随時記録することで、パケットロス率の割り出しが可能となる。このロス率が一定値以上になった場合には、ＮＡＣＫ−ＲＴＣＰパケット自体の損失の可能性が考えられるため、おなじＮＡＣＫ−ＲＴＣＰパケットを複数回、重ねて送信する処理を行なうことで、再送成功率を高めることが可能となる。あるいは、ＮＡＣＫ−ＲＴＣＰパケットに重複指定回数を増分して設定する。
【０１５９】
データ送信端末は、ＮＡＣＫ−ＲＴＣＰパケットを受信すると、次のタイムスタンプを設定したフレームデータに併せて、再送パケットを送信する。
【０１６０】
ステップＳ４１４のロストパケットの検出処理は、ステップＳ４０３の各フレームの終端パケット受信、ステップＳ４０４の各フレームの先頭パケット受信時のみではなく、ステップＳ４０５の各フレームの最終再送時間の判定でＹｅｓの場合、およびステップＳ４０６のタイマーの最小計測時間τの経過判定でＹｅｓの場合に実行される。
【０１６１】
ステップＳ４０５の各フレームの最終再送時間の判定処理は、再送要求としてのＮＡＣＫ−ＲＴＣＰを出力した場合、リアルタイム再生処理に間に合う最終時間判定処理である。各フレームについて、各フレームの符号化データの処理開始までの時間Ｔａが計測されているＲＴＴ値と等しくなったとき、すなわち、Ｔａ＝ＲＴＴとなった場合に、ステップＳ４０５の判定がＹｅｓとなり、ステップＳ４０９の該当フレームに対するロストパケットの検出処理が実行される。これは、最後の再送要求可能タイミングにロストパケットを検出して、検出された場合に最後の再送要求を送信するための処理である。
【０１６２】
ステップＳ４０６のタイマーの最小計測時間τの経過判定処理は、データ受信端末の有するタイマーの計測最小時間：τ毎に、ステップＳ４０６の判定がＹｅｓとなり、ステップＳ４１４の該当フレームに対するロストパケットの検出処理が実行される。これは、各計測最小時間：τに対応する受信フレームについて、各フレームの先頭パケット、最終パケットの検出がなされない場合でもロストパケットを確実に検出して、再送要求を実行しようとするための処理である。
【０１６３】
このように、データ受信端末では、ステップＳ４０３の各フレームの終端パケット受信、ステップＳ４０４の各フレームの先頭パケット受信時、ステップＳ４０５の各フレームの最終再送時間の判定、およびステップＳ４０６のタイマーの最小計測時間τの経過判定の各タイミングにおいて、ステップＳ４１４のロストパケットの検出処理を実行する。なお、これらステップＳ４０３〜Ｓ４０６の４種類のタイミングのいずれかのみを実行する構成としてもよい。
【０１６４】
ステップＳ４１４の各フレームのロストパケット検出処理において、ロストパケットが検出されなかった場合は、各パケットに格納された符号化データのデコード（復号）処理がデコーダ２２４において実行される。ステップＳ４１８では、受信済みパケットについての受信確認パケットとしてのＡＣＫ−ＲＴＣＰパケットの生成、送信が行われる。ＡＣＫ−ＲＴＣＰパケットは、先に図１１を参照して説明した通り、受信済みシーケンス番号を格納したパケットである。このＡＣＫ−ＲＴＣＰパケットを受信したデータ送信端末は、ＡＣＫ−ＲＴＣＰパケットに記録された受信済みシーケンス番号に対応するパケットをバッファ２２３からクリアする。
【０１６５】
図１４に示すフローのステップＳ４０７では、各フレームのタイマー期限切れを確認する。このタイマー期限は、リアルタイム再生処理の開始期限を計測するタイマーによって設定される期限であり、各フレーム毎にそのタイミングが設定される。ｎフレームのタイマー期限切れであると判定された場合には、ロストパケットがあった場合であっても、ステップＳ４１６のデコード処理に移行することになる。
【０１６６】
ステップＳ４０８では、データ送信端末から、データストリームの終了を明示するＥＯＳ（End Of Stream）メッセージを持つＲＴＣＰパケットを受信したか否かを判定し、ＥＯＳ−ＲＴＣＰパケット受信でない場合は、ステップＳ４０１以下の処理を繰り返す。
【０１６７】
ＥＯＳ−ＲＴＣＰパケット受信である場合は、ステップＳ４０９において、各フレームのタイマー期限切れを確認する。このタイマー期限は、リアルタイム再生処理の開始期限を計測するタイマーによって設定される期限であり、各フレーム毎にそのタイミングが設定される。タイマー期限切れでない場合は、ステップＳ４１９に進み、再送要求されているロストパケットに関する再送パケットを受信待機状態であるか否かを判定して、待機状態である場合は、ステップＳ４２０に進み、再送パケットの受信待機状態として、ステップＳ４０１のパケット受信以下の処理を実行する。
【０１６８】
ステップＳ４０９における各フレームのタイマー期限切れの確認処理において、Ｙｅｓと判定された場合、および、ステップＳ４１９において、再送パケット受信待機状態でないと判定された場合は、デコード、再生処理へ移行すべき未受信のパケットデータは存在しないと判定され、受信処理を完了する。
【０１６９】
このように、本発明のシステムにおいては、リアルタイム配信に適するものの信頼性を保証しないＲＴＰ等のデータ通信プロトコルに従ったパケット伝送において、ＦＥＣ処理によるエラー訂正、または再送要求としてのＡＲＱを選択的に実行することで、エラー耐性のある信頼性の高いデータ伝送、リアルタイム再生が可能となる。なお、上述の実施例では、ＲＴＰパケットに符号化データを格納する構成例を中心として説明したが、ＲＴＰパケットフォーマットに限らず、ＵＤＰ等、他のデータ通信プロトコルフォーマットに従ったパケットを用いたデータ通信構成においても、上述の実施例と同様の各種のコントロールパケットを用いた再送要求処理を行なうことにより、上述の実施例と同様の構成を実現可能である。
【０１７０】
上述したように本発明の構成では、再送要求の処理タイミングとして、各フレームの先頭パケットの受信時、各フレームの最終パケットの受信時、最終処理期限、および一定間隔（τ）毎等の各種タイミングでロストパケットの検出処理を実行する構成としたので、確実なロストパケットの検出が可能となる。
【０１７１】
また、本発明のデータ通信システムにおける送信側端末の階層エラー訂正優先度制御部２１２は、および受信側端末２０２のエラー訂正制御部２３０は、それぞれのネットワーク監視部２１５、２２９によって監視されている現在のネットワーク状況を踏まえてエラー訂正を制御する。ネットワークの監視は、ＲＴＴやパケットロス率などＲＴＣＰやＩＣＭＰなどの汎用のプロトコルを利用して取得する。受信側がＲＴＴを検知するために、受信側は、前述したＥＣＨＯパケットを送信側に送り、その返事であるＥＣＨＯ−ＲＥＰＬＹパケットを受け取ることにとって、ＲＴＴを計測し、確実なパケット再送処理が実現される。
【０１７２】
先に説明したように、ＲＴＰではパケット毎にシーケンス番号をつけており、番号とフレームの先頭と終端を示すフラグをペイロードにいれておくことにより、あるフレームを構成するパケット数を簡単に受信側は計算することができ、必要なパケット数に対してある時間内にどれだけ正当なパケットが届いたかを監視していれば、ある程度のエラー率を求めることができる。ここで得られたエラー率またはＲＦＣ１８８９で規定されているＲＴＣＰのＲＲ（Ｒｅｃｉｅｖｅｒ Ｒｅｐｏｒｔ）でのパケットロス率により、送信側はエラー率を知りＦＥＣのエラー訂正強度をあげたり、またはＦＥＣを施さないなどの処理態様の制御を実行する。
【０１７３】
エラー訂正処理として実行されるパケット再送要求（ＡＲＱ）は、再送要求ＮＡＣＫを送信し再送パケットが届くまでにＲＴＴ時間を要することになり、また、ＦＥＣ訂正においても送受信端末でインターリーブする処理のために一定時間が必要となる。それぞれの端末におけるネットワーク監視部の監視により得られるネットワーク状況に基づいて、例えば、ＲＴＴが短いならば、ＡＲＱによる再送が可能となるためＡＲＱによるエラー訂正を選択して実行し、ＲＴＴが長く、再送する時間がないほど送信側から受信側に転送時間がかかるというネットワーク状況である場合には、ＡＲＱではなくＦＥＣによるエラー訂正を選択する、といった動的なエラー訂正制御が可能となる。
【０１７４】
受信側端末のエラー監視部２２２では、ＲＴＰではパケット毎のシーケンス番号に基づいて、必要なパケット数に対してある時間内にどれだけ正当なパケットが届いたかのエラー率を求めることができ、また、送信側端末では、再送要求処理の数をカウントすることでエラー率を概算することが可能となる。エラー率が高く、ＦＥＣによるエラー訂正で訂正できないほどの高いエラー率であると判定した場合には、送信側端末２０１の階層エラー訂正優先度制御部２１２は、ＦＥＣ処理部における冗長コードの付与を停止し、すべて受信側端末からの再送要求（ＡＲＱ）に応答するのみの処理を選択したり、あるいは、よりエラー訂正の強いアルゴリズムのＦＥＣを選択するといったエラーに対する処理態様を動的に変更することが可能となる。
【０１７５】
また、これらのエラー制御態様は、伝送するデータ階層に応じた優先度に対応して選択的に設定可能であり、様々なエラー訂正ポリシーが決められる。例えば受信側端末２０２のネットワーク状況監視部２２９は、パケットロス率、または伝送遅延時間に基づくネットワーク状況解析を実行し、階層選択制御部２３１が、解析結果に基づいて処理データの選択を実行することが可能である。
【０１７６】
さらに、このエラー訂正ポリシーは、ネットワーク状況や送信および受信端末側の意図により変更可能なため、一意に決まるものとすることは必要でない。ある送信環境とメディアによっては、基本となる階層は必ず完全再生したいので、強めのＦＥＣ＋ＡＲＱで優先度を上げておく、音声データはＦＥＣのみで、オーバーヘッドは極力避けたいのでＦＥＣなしでＡＲＱとして再送回数１回まで、といったように自由な態様でのエラー制御態様を設定することができる。
【０１７７】
また、本発明のシステムでは、データ受信端末は、再生処理時間、伝播遅延時間ＲＴＴを考慮したデータ再送要求処理を実行するので、無駄な再送要求パケットおよび再送パケットを出すことを防ぐ事ができ、ネットワークの帯域を再送によって狭めることがない。また、データ受信端末が、パケットの送受信情報を随時記録し、パケットロス率の割り出しにより、ロス率が一定値以上になった場合、おなじＮＡＣＫ−ＲＴＣＰパケットを複数回、重ねて送信することで、再送成功率を高めることが可能となる。
【０１７８】
［データ送受信端末装置構成例］
上述の実施例で述べた一連の処理は、ハードウェア、またはソフトウェア、あるいは両者の複合構成によって実行することが可能である。ソフトウェアによる処理を実行する場合は、処理シーケンスを記録したプログラムを、専用のハードウェアに組み込まれたデータ処理装置内のメモリにインストールして実行させるか、あるいは、各種処理が実行可能な汎用コンピュータにプログラムをインストールして実行させることが可能である。一連の処理をソフトウェアによって行う場合には、そのソフトウェアを構成するプログラムが、例えば汎用のコンピュータやマイクロコンピュータ等にインストールされる。
【０１７９】
図１６に、上述の実施例で述べた一連の処理を実行するデータ送信端末装置、データ受信端末装置のシステム構成例を示す。本発明のシステムで送受信されるデータは、符号化データであり、データ送信装置ではエンコード（符号化）処理が実行され、データ受信装置ではデコード（復号）処理が実行される。符号化されたデータはパケットとしてネットワークを介して送受信する。そのため、データ送信側では、パケット生成（パケタイズ処理）を実行し、データ受信側ではパケット展開（デパケタイズ処理）を実行する。
【０１８０】
図１６に示すデータ送受信装置（ｅｘ．ＰＣ）８５０は、エンコード（符号化）処理、デコード（復号）処理を実行するとともにパケット生成、展開処理を実行するコーデック８５１、通信ネットワークとのインタフェースとして機能するネットワークインタフェース８５２、マウス８３７、キーボード８３６等の入力機器との入出力インタフェース８５３、ビデオカメラ８３３、マイク８３４、スピーカ８３５等のＡＶデータ入出力機器からのデータ入出力を行なうＡＶインタフェース８５４、ディスプレイ８３２に対するデータ出力インタフェースとしてのディスプレイ・インタフェース８５５、各データ入出力インタフェース、コーデック８５１、ネットワークインタフェース８５２間のデータ転送制御、その他各種プログラム制御を実行するＣＰＵ８５６、ＣＰＵ８５６により制御実行される各種プログラムの格納、データの格納、ＣＰＵ８５６のワークエリアとして機能するＲＡＭ、ＲＯＭからなるメモリ８５７、データ格納、プログラム格納用の記憶媒体としてのＨＤＤ８５８を有し、それぞれＰＣＩバス８５９に接続され、相互のデータ送受信が可能な構成を持つ。
【０１８１】
コーデック８５１は、図１６に示すように、例えばビデオカメラ８３３からの画像データ、マイク８３４からの音声データを入力し、符号化処理、パケット生成処理（パケタイズ）を実行し、最終的に符号化データをペイロードとしたパケットを生成する。生成されたパケットは、ＰＣＩバス８５９上に出力され、ネットワークインタフェース８５２を介してネットワークに出力され、パケットのヘッダに設定された宛先アドレスに配信される。
【０１８２】
また、ＨＤＤ８５８またはメモリ８５７に格納されたソフトウェアエンコードプログラムに従ってＣＰＵ８５６の制御により、ビデオカメラ８３３からの画像データ、マイク８３４からの音声データを符号化してネットワークインタフェース８５２を介してネットワークに出力する処理も実行する構成としてもよい。
【０１８３】
一方、ネットワークを介して入力するＩＰパケット化されたデータは、ネットワークインタフェース８５２を介して、バス８５６上に出力されて、コーデック８５１に入力される。コーデック８５１では入力データのパケット展開処理（デパケタイズ）を実行し、ペイロードとして格納された符号化データを抽出後、復号処理を実行して、ディスプレイ８３２、スピーカ８３５において再生、出力する。
【０１８４】
上述の実施例における処理対象となる画像等のデータは、カメラ他の入力機器、例えばスキャナ等のデータ入力装置、あるいはフロッピーディスク、ＣＤ−ＲＯＭ(Compact Disc Read Only Memory)，ＭＯ(Magneto optical)ディスク，ＤＶＤ(Digital Versatile Disc)、磁気ディスク、半導体メモリなどのリムーバブル記録媒体から入力可能である。
【０１８５】
また、ＣＰＵ８５６は、ＲＯＭ格納プログラムに限らず、ハードディスクに格納されているプログラム、衛星若しくはネットワークから転送され、受信されてインストールされたプログラム等を、ＲＡＭ(Random Access Memory)等のメモリにロードして実行することも可能である。
【０１８６】
ここで、本明細書において、プログラムは、１つのコンピュータにより処理されるものであっても良いし、複数のコンピュータによって分散処理されるものであっても良い。さらに、プログラムは、遠方のコンピュータに転送されて実行されるものであっても良い。
【０１８７】
以上、特定の実施例を参照しながら、本発明について詳解してきた。しかしながら、本発明の要旨を逸脱しない範囲で当業者が該実施例の修正や代用を成し得ることは自明である。すなわち、例示という形態で本発明を開示してきたのであり、限定的に解釈されるべきではない。本発明の要旨を判断するためには、冒頭に記載した特許請求の範囲の欄を参酌すべきである。
【０１８８】
【発明の効果】
以上、説明してきたように、本発明の構成によれば、ネットワーク監視部によって監視されている現在のネットワーク状況を踏まえてエラー訂正を制御することが可能であり、ＦＥＣによるエラー制御あるいは再送要求処理（ＡＲＱ）に基づくエラー制御等の態様をネットワークにおけるパケット損失、エラー発生状況に応じて動的に変更してパケット転送を実行することが可能となる。監視データとして、パケットエラー率またはＲＦＣ１８８９で規定されているＲＴＣＰのＲＲ（Ｒｅｃｉｅｖｅｒ Ｒｅｐｏｒｔ）でのパケットロス率等を取得し、送信側においてＦＥＣのエラー訂正強度をあげたり、またはＦＥＣを施さずＡＲＱ処理のみの対応とするなどの処理態様の制御が可能となる。
【０１８９】
また、本発明の構成によれば、ネットワーク監視部の監視により得られるネットワーク状況に基づいて、例えば、ＲＴＴが短いならば、ＡＲＱによる再送が可能となるためＡＲＱによるエラー訂正を選択して実行し、ＲＴＴが長く、再送する時間がないほど送信側から受信側に転送時間がかかるというネットワーク状況である場合には、ＡＲＱではなくＦＥＣによるエラー訂正を選択する、といった動的なエラー訂正制御が可能となる。
【０１９０】
また、これらのエラー制御態様は、伝送するデータ階層に応じた優先度に対応して選択的に設定可能となり、符号化データの階層レベルに応じて異なるエラー訂正処理を実行する構成とすることが可能である。例えば基本階層を、強めのＦＥＣ＋ＡＲＱで優先度を上げた設定とし、音声データはＦＥＣのみの対応としたり、オーバーヘッドは極力避けたいのでＦＥＣなしでＡＲＱとして再送回数を例えば１回までといったように再送回数の制限数の設定等、自由な態様でのエラー制御態様を設定することができる。
【図面の簡単な説明】
【図１】本発明のデータ通信システムの構成を示す図である。
【図２】本発明のデータ通信システムの送信側端末、受信側端末の構成を示す図である。
【図３】データの階層化処理例としてのウェーブレット変換について説明する図である。
【図４】本発明のデータ通信システムの送信側端末で実行する優先度付け処理例について説明する図である。
【図５】本発明のデータ通信システムの送信側端末で実行する優先度付け処理に持ついるマップについて説明する図である。
【図６】本発明のデータ通信システムにおいて転送されるＲＴＰパケットフォーマットを示す図である。
【図７】本発明のデータ通信システムにおいて転送されるＩＰパケットヘッダフォーマットを示す図である。
【図８】本発明のデータ通信システムにおけるデータ送信端末の処理フローを示す図である。
【図９】本発明のデータ通信システムにおいて転送されるＮＡＣＫ−ＲＴＣＰパケットフォーマットを示す図である。
【図１０】本発明のデータ通信システムにおいて転送されるＮＡＣＫ−ＲＴＣＰパケットにおけるオプション値の機能について説明する図である。
【図１１】本発明のデータ通信システムにおいて転送されるＡＣＫ−ＲＴＣＰパケットフォーマットを示す図である。
【図１２】本発明のデータ通信システムにおいて転送されるＥＣＨＯ−ＲＴＣＰ、およびＥＣＨＯ−ＲＥＰＬＹ−ＲＴＣＰパケットフォーマットを示す図である。
【図１３】本発明のデータ通信システムにおいて転送されるＥＯＳ−ＲＴＣＰパケットフォーマットを示す図である。
【図１４】本発明のデータ通信システムにおけるデータ受信端末の処理フローを示す図である。
【図１５】本発明のデータ通信システムにおけるデータ受信端末のＥＣＨＯ−ＲＴＣＰ、およびＥＣＨＯ−ＲＥＰＬＹ−ＲＴＣＰパケットを適用したＲＴＴ計測処理フローを示す図である。
【図１６】データ送信端末装置およびデータ受信端末装置のシステム構成例を示す図である。
【符号の説明】
１０１，１１５，１２３ ＣＰＵ
１０２，１１６，１２４ ＲＯＭ
１０３，１１７，１２５ ＲＡＭ
１０４，１１８，１２６ 表示装置
１０５，１１１，１１９ 外部記憶装置
１０６，１１２，１２０ 通信Ｉ／Ｆ
１０７，１１３，１２１ 入力装置
１０８ インタフェース
１０９ カメラ
１１０ マイク
１１４，１２２ 再生装置
１３２，１３３，１３４ 伝送路
１３５ ＩＰネットワーク
２０１ 送信側端末
２０２ 受信側端末
２０３ ビデオカメラ
２０４ エンコーダ
２０５ 階層化部
２０６ 優先度付け処理部
２０７ バッファ
２０８ ＦＥＣ処理部
２０９ ＲＴＰパケット生成部
２１０ ＲＴＰポート
２１１ ビットレート制御部
２１２ 階層エラー訂正優先度制御部
２１３ ＡＲＱ処理部
２１４ ＲＴＣＰパケット生成部
２１５ ネットワーク監視部
２１６ ＲＴＣＰパケット解析部
２１７ ＲＴＣＰポート
２１８ ＴＣＰ，ＲＴＣＰポート
２１９ ＩＰネットワーク
２２０ ＲＴＰポート
２２１ ＲＴＰパケット解析部
２２２ エラー監視部
２２３ バッファ
２２４ デコーダ
２２５ ＲＴＣＰポート
２２６ ＲＴＣＰパケット解析部
２２７ ＲＴＣＰパケット生成部
２２８ ＴＣＰ，ＲＴＣＰポート
２２９ ネットワーク監視部
２３０ エラー訂正制御部
２３１ 階層選択制御部
８０９ ＰＣＩバス
８３２ ディスプレイ
８３３ ビデオカメラ
８３４ マイク
８３５ スピーカ
８３７ マウス
８３８ キーボード
８５０ データ送受信装置
８５１ コーデック
８５２ ネットワークインタフェース
８５３ 入出力インタフェース
８５４ ＡＶインタフェース
８５５ ディスプレイインタフェース
８５６ ＣＰＵ
８５７ メモリ
８５８ ＨＤＤ
【発明の属する技術分野】
本発明は、データ通信システム、データ送信装置、データ受信装置、および方法、並びにコンピュータ・プログラムに関する。さらに詳細には、ストリーミングデータ転送におけるエラー耐性を高めたパケット送信構成を持つデータ通信システム、データ送信装置、データ受信装置、および方法、並びにコンピュータ・プログラムに関する。
【０００２】
【従来の技術】
昨今、インターネット通信など、様々な通信媒体を介した画像、音声データ等のデータ転送が盛んに行われている。特に、近年においては、インターネット上のデータ転送において、従来から利用されているダウンロード型伝送方式に加えて、ストリーム型伝送方式によるサービスが増加してきている。ダウンロード型伝送方式においては、映像ファイルや音声ファイルといったマルチメディアデータを伝送する場合、配信サーバからデータファイルを一旦受信側端末の記憶媒体にダウンロードして、その後、記憶媒体から再生することになる。よって、この方式ではファイルを完全に転送が終わるまでは再生できず、長時間再生やリアルタイム再生などには不向きである。
【０００３】
一方、後者のストリーム型伝送方式では、送信側から受信端末にデータ転送が行われている間に、並列して受信データの再生処理を実行するものであり、インターネット電話・遠隔テレビ会議・ビデオオンデマンドといったインターネットサービスに利用されている。
【０００４】
ストリーム型伝送方式は、例えば画像データのＭＰＥＧ圧縮処理により生成されるＭＰＥＧストリームをＩＰ（Internet Protocol）パケットに格納してインターネット上を転送させて、ＰＣやＰＤＡ、携帯電話等の各通信端末において受信するシステム等において使用され、開発が進んでいる。このような技術は、ビデオオンデマンドやライブ映像のストリーミング配信、あるいはビデオ会議、テレビ電話などのリアルタイム通信において有効となる。
【０００５】
このようなストリーム型伝送方式に適したインターネット技術に、IETF RFC1889で規定されているプロトコル：ＲＴＰ(Realtime Transport Protocol)がある。ＲＴＰに従ったデータ転送では、時間情報としてパケットにタイムスタンプを付加し、タイムスタンプの参照により送信側と受信側の時間的関係の把握を行ない、データ受信側において、パケット転送の遅延ゆらぎ（ジッター）などの影響を受けずに同期をとった再生を可能としている。
【０００６】
ただし、ＲＴＰは実時間のデータ転送を保証しているものではない。パケット配送の優先度や設定、管理などはＲＴＰが提供するトランスポートサービスの範疇ではないため、ＲＴＰパケットは、他のパケットと同様、ネットワーク上での配送遅延やパケット損失がおきる可能性がある。しかし、このような事態が起こっても、受信側は期待する時間内に到着したパケットだけを利用してデータを再生することが可能である。これは、映像や音声データが多少のデータ欠損があったとしても、データ品質を落とした再生、あるいはデータ補正処理による再生が可能となるからである。
【０００７】
なお、再生に間に合わず遅延配送されたパケットやエラーの発生したパケットは、受信側でそのまま破棄される。つまり、パケット損失やエラーが発生した場合は、高品質なデータ配信処理を行なっている場合でも、受信側で品質を保持した再生が実行されないという問題点がある。特に、有線区間で１０-5、無線区間で１０-3以上のエラーがあるといわれている中では、配信するメディアの品質保持を考慮すると、ＲＴＰをそのまま利用したデータ転送には問題がある。
【０００８】
このようなＲＴＰに従ったデータ転送における問題点を解決する１つの案としては、データ転送に信頼性が高いデータ転送プロトコルであるＴＣＰに従ってパケットの再送要求および再送パケット送信を行わせる方法が考えられる。しかし、ＴＣＰはエラーには強いが、スループットが低く、遅延が大きいため、再送しても再生時間に間に合わない可能性があり、リアルタイム通信の実現を困難とするという問題がある。
【０００９】
さらに、パケットエラー等に対応するエラー訂正手法として、例えばＦＥＣ（Forward Error Correction）という手段が考えられている。これは誤り訂正を行うためのＦＥＣデータを冗長データとして送信して、エラーが発生した場合には、データ受信側において、このＦＥＣデータをもとにエラーの修復を実行しようとするものである。ランダム誤り訂正符号として、ＢＣＨ符号と畳み込み符号が用いられる。また、バースト誤り訂正符号では、リードソロモン符号（ＲＳ符号）が一般的によく利用されている。前述のＡＲＱに比べると再送にかかる遅延がない分、遅延時間を低く抑えられるが、冗長データを付加するためにパケット損失が非常に少ない伝送路においてはスループットは低下する。
【００１０】
ＦＥＣは、端末側での誤り検出と符号処理が複雑なため受信端末側の処理能力に依存してしまう。このように、ネットワーク状況と受信端末に合わせた最適な付加ＦＥＣデータを一意に決定して送信するのは難しく、処理時間のオーバーヘッドが常につきまとうなど問題が存在する。
【００１１】
【発明が解決しようとする課題】
本発明は、上述の問題点に鑑みてなされたものであり、ビデオオンデマンドや、遠隔テレビ会議のような、リアルタイム再生が望まれるデータ転送処理を効率的に実行可能とかるとともに、パケット損失等のエラー発生時にも品質の低下を抑えて高品質なデータ再生を実現するデータ通信システム、データ送信装置、データ受信装置、および方法、並びにコンピュータ・プログラムを提供することを目的とする。
【００１２】
【課題を解決するための手段】
本発明の第１の側面は、
データ送信装置およびデータ受信装置からなり、画像データのストリーム型データ転送を実行するデータ通信システムであり、
データ送信装置は、
送信画像データの階層符号化処理を実行する階層符号化部と、
前記送信画像データの元画像へのデータ損失による影響およびネットワークの損失率に基づき、前記階層符号化部において階層符号化された階層毎の優先度を設定する優先度付け処理部と、
前記階層符号化部により階層符号化された前記送信画像データを格納した送信画像データパケットを送信するパケット送信処理部と、
ネットワーク状況を監視するネットワーク状況監視部と、
前記優先度付け処理部により前記階層毎に設定された優先度に従って、前記ネットワーク状況監視部の監視するネットワーク状況に基づき、前記送信画像データパケットのエラー制御処理態様を制御するとともに、前記階層符号化部における前記送信画像データの符号化態様を設定してビットレートを制御するデータ送信側制御部と、
データ受信装置から受信する再送要求メッセージパケットに従って再送すべき送信画像データパケットの抽出処理を実行する再送制御部とを有し、
前記優先度付け処理部は、
前記ネットワーク状況監視部により検出されたネットワーク状況に応じて、前記階層毎の優先度を変更する構成であり、
データ受信装置は、
前記データ送信装置から受信する画像データパケットを受信するパケット受信処理部と、
ネットワーク状況を監視するネットワーク状況監視部と、
前記データ送信装置から受信する画像データパケットのエラーまたはパケットロスの検出を実行し、エラー対応処理を実行するエラー訂正制御部と、
前記データ送信装置から受信する画像データパケットのエラーまたはパケットロスの検出に基づいて、前記データ送信装置に対する画像データパケット再送要求としての再送要求メッセージパケットの送信可否を判定する再送要求処理制御部と、
前記ネットワーク状況監視部の監視結果に基づいて処理画像データの選択を実行する階層選択制御部とを有し、
前記階層選択制御部は、
前記ネットワーク状況監視部の解析結果に基づく処理画像データの選択を、前記階層符号化された画像データ毎に前記ネットワーク状況に応じて決定された前記優先度に従って実行する構成である、
ことを特徴とするデータ通信システムにある。
【００２２】
本発明の第２の側面は、
送信画像データのストリーム型データ送信を実行するデータ送信装置であり、
前記送信画像データの階層符号化処理を実行する階層符号化部と、
前記送信画像データの元画像へのデータ損失による影響およびネットワークの損失率に基づき、前記階層符号化部において階層符号化された階層毎の優先度を設定する優先度付け処理部と、
前記階層符号化部により階層符号化された前記送信画像データを格納した送信画像データパケットを送信するパケット送信処理部と、
ネットワーク状況を監視するネットワーク状況監視部と、
前記優先度付け処理部により前記階層毎に設定された優先度に従って、前記ネットワーク状況監視部の監視するネットワーク状況に基づき、前記送信画像データパケットのエラー制御処理態様を制御するとともに、前記階層符号化部における前記送信画像データの符号化態様を設定してビットレートを制御するデータ送信側制御部と、
データ受信装置から受信する再送要求メッセージパケットに従って再送すべき送信画像データパケットの抽出処理を実行する再送制御部とを有し、
前記優先度付け処理部は、
前記ネットワーク状況監視部により検出されたネットワーク状況に応じて、前記階層毎の優先度を変更する構成であることを特徴とするデータ送信装置にある。
【００２３】
さらに、本発明のデータ送信装置の一実施態様において、前記データ送信側制御部は、前記ネットワーク状況監視部の監視するネットワーク状況に基づいて、エラー制御方式としてのＦＥＣ(Forward Error Correction)の処理態様変更、またはデータ再送要求処理としてのＡＲＱ（Auto Repeat reQuest）処理態様の変更処理を実行する構成であることを特徴とする。
【００２４】
さらに、本発明のデータ送信装置の一実施態様において、前記ネットワーク状況監視部は、パケットロス率、伝送遅延時間、または前記データ受信装置からの再送要求に基づいてネットワーク状況解析を実行し、該解析結果を前記データ送信側制御部に出力し、前記データ送信側制御部は、該解析結果に基づいて、伝送パケットのエラー制御処理態様を制御する構成であることを特徴とする。
【００２６】
さらに、本発明のデータ送信装置の一実施態様において、前記データ送信装置において、前記データ送信側制御部は、前記ネットワーク状況監視部の監視するネットワーク状況に基づいて、エラー制御方式としてのＦＥＣ(Forward Error Correction)の処理態様変更、またはデータ再送要求処理としてのＡＲＱ（Auto Repeat reQuest）処理態様の変更処理を前記階層符号化部の設定した各階層の符号化送信画像データに対応して実行する構成であることを特徴とする。
【００２７】
さらに、本発明のデータ送信装置の一実施態様において、前記データ送信装置において、前記データ送信側制御部は、前記ネットワーク状況監視部の監視するネットワーク状況に基づいて、エラー制御方式としてのＦＥＣ(Forward Error Correction)の処理態様変更、またはデータ再送要求処理としてのＡＲＱ（Auto Repeat reQuest）処理態様の変更処理を前記優先度付け処理部の設定した各優先度に対応して実行する構成であることを特徴とする。
【００３２】
本発明の第３の側面は、
送信画像データのストリーム型データ送信を実行するデータ送信方法であって、
前記送信画像データの階層符号化処理を実行する階層符号化処理ステップと、
前記送信画像データの元画像へのデータ損失による影響およびネットワークの損失率に基づき、前記階層符号化処理ステップにおいて階層符号化された階層毎の優先度を設定する優先度付け処理ステップと、
前記階層符号化処理ステップにおいて階層符号化された前記送信画像データを格納した送信画像データパケットを送信するパケット送信処理ステップと、
ネットワーク状況を監視するネットワーク状況監視ステップと、
前記優先度付け処理ステップにおいて前記階層毎に設定された優先度に従って、前記ネットワーク状況監視ステップにおいて取得したネットワーク状況に基づき、前記送信画像データパケットのエラー制御処理態様を制御するとともに、前記階層符号化ステップにおける前記送信画像データの符号化態様を設定してビットレートを制御するデータ送信側制御ステップと、
データ受信装置から受信する再送要求メッセージパケットに従って再送すべき送信画像データパケットの抽出処理を実行する再送制御ステップとを有し、
前記優先度付け処理ステップは、
前記ネットワーク状況監視ステップにおいて検出されたネットワーク状況に応じて、前記階層毎の優先度の変更処理を行うことを特徴とするデータ送信方法にある。
【００４２】
本発明の第４の側面は、
送信画像データのストリーム型データ送信を実行するコンピュータ・プログラムであって、
前記送信画像データの階層符号化処理を実行する階層符号化処理ステップと、
前記送信画像データの元画像へのデータ損失による影響およびネットワークの損失率に基づき、前記階層符号化処理ステップにおいて階層符号化された階層毎の優先度を設定する優先度付け処理ステップと、
前記階層符号化処理ステップにおいて階層符号化された前記送信画像データを格納した送信画像データパケットを送信するパケット送信処理ステップと、
ネットワーク状況を監視するネットワーク状況監視ステップと、
前記優先度付け処理ステップにおいて前記階層毎に設定された優先度に従って、前記ネットワーク状況監視ステップにおいて取得したネットワーク状況に基づき、前記送信画像データパケットのエラー制御処理態様を制御するとともに、前記階層符号化ステップにおける前記送信画像データの符号化態様を設定してビットレートを制御するデータ送信側制御ステップと、
データ受信装置から受信する再送要求メッセージパケットに従って再送すべき送信画像データパケットの抽出処理を実行する再送制御ステップとを有し、
前記優先度付け処理ステップは、
前記ネットワーク状況監視ステップにおいて検出されたネットワーク状況に応じて、前記階層毎の優先度の変更処理を行うステップであることを特徴とするコンピュータ・プログラムにある。
【００４４】
なお、本発明のコンピュータ・プログラムは、例えば、様々なプログラム・コードを実行可能な汎用コンピュータ・システムに対して、コンピュータ可読な形式で提供する記憶媒体、通信媒体、例えば、ＣＤやＦＤ、ＭＯなどの記録媒体、あるいは、ネットワークなどの通信媒体によって提供可能なコンピュータ・プログラムである。このようなプログラムをコンピュータ可読な形式で提供することにより、コンピュータ・システム上でプログラムに応じた処理が実現される。
【００４５】
本発明のさらに他の目的、特徴や利点は、後述する本発明の実施例や添付する図面に基づくより詳細な説明によって明らかになるであろう。なお、本明細書においてシステムとは、複数の装置の論理的集合構成であり、各構成の装置が同一筐体内にあるものには限らない。
【００４６】
【発明の実施の形態】
［システム及びデータ送受信概要］
本発明のデータ通信システムのシステム構成例を図１に示す。本発明のデータ通信システムは、ビデオオンデマンドや、遠隔テレビ会議のような、リアルタイム再生が望まれるデータ転送処理をデータ送信処理を実行する送信側端末１００と、データ受信処理を実行する受信側端末１３０，１３１との間でＩＰネットワーク１３５を介して実行するシステムである。
【００４７】
図１には、１つの送信側端末１００と２つの受信側端末１３０，１３１が示してあるが、この他にも任意数の端末がＩＰネットワーク１３５を介してデータ送受信が実行される。また、データ送信側端末、受信側端末は、データの送信のみ、受信のみを実行するばかりでなく、データ送受信が可能な端末として構成可能である。
【００４８】
データ送信側端末１００は、カメラ１０９やマイク１１０より、画像、音声等のメディアデータをインターフェース（Ｉ／Ｆ）１０８などを通して記憶装置１０５、ＲＡＭ１０３に取り込む。撮り込まれたデータは、通信インターフェース１０６を介して、ＩＰネットワーク１３５に伝送される。ＩＰネットワーク１３５を介して設定される伝送路１３２，１３３，１３４は、有線路でも無線路でも構わない。これらの伝送路１３２，１３３，１３４を介して受信側端末１３０は、通信インターフェース１１２を通してデータを受信しＲＡＭ１１７にバッファリングする。
【００４９】
受信側端末１３０では、ＣＰＵ１１５による処理を経て、受信データを表示装置１１８において画像表示し、また再生装置１１４において音声の再生を実行する。受信端末１３１も受信端末１３０と同様に送信側端末１００からのデータを同時に受信し、同様の画像再生、音声再生を実行する。
【００５０】
図１の構成において、送信側端末１００、受信側端末１３０，１３１のそれぞれは例えば通信処理機能を持つＰＣ、あるいは携帯端末等によって構成される。各端末の詳細構成については、後段で説明するが、図１に示す送信側端末１００および受信側端末１３０，１３１の各処理部の機能の概略をまとめて説明する。
【００５１】
ＣＰＵ(Central processing Unit)１０１，１１５，１２３は、各種実行プログラム、ＯＳ（Operating System）を実行するプロセッサであり、後段で説明する。送受信データの再送制御、エラー訂正処理等のプログラムを実行する。ＲＯＭ（Read-Only-Memory）１０２，１１６，１２４は、ＣＰＵが実行するプログラム、あるいは演算パラメータとしての固定データを格納する。ＲＡＭ（Random Access Memory）１０２，１１７，１２５は、ＣＰＵの処理において実行されるプログラム、およびプログラム処理において適宜変化するパラメータの格納エリア、ワーク領域として使用される。
【００５２】
表示装置１０４，１１８，１２６は、例えばＣＲＴ、液晶ディスプレイ等であり、各種情報をテキストまたはイメージ等により表示する。外部記憶装置１０５，１１１，１１９はハードディスク、ＤＶＤ等の記憶媒体を持つ記憶装置であり、各種データ、プログラムを格納する。
【００５３】
通信Ｉ／Ｆ１０６，１１２，１２０は送信側端末と受信側端末間の通信処理を実行し、ＣＰＵの制御の下に、各記憶部から供給されたデータ、あるいはＣＰＵによって処理されたデータを送信したり、他端末からのデータを受信する処理を実行する。
【００５４】
入力装置１０７，１１３，１２１は、例えばキーボード、ポインティングデバイスを含む入力部であり、キーボードやマウス等を介してユーザによるデータまたはコマンドの入力が可能である。受信側端末１３０，１３１に示す再生装置１１４，１２２は前述したように音声再生を実行する例えばスピーカ等の装置である。
【００５５】
次に、図２以下を参照して、本発明のデータ通信システムにおけるデータ送受信処理の詳細を説明する。
【００５６】
図２のデータ通信システムにおいて、送信側端末２０１は受信側端末２０２に対して画像、音声等のデータをパケット化して送信する。転送データは、例えばビデオカメラ２０３によって取得された画像、音声データである。なお、転送データは、ＣＤ，ＤＶＤ等の記憶媒体から入力されるデータ、あるいは外部ネットワーク、衛星等から受信するデータ等であってもよい。なお、以下の説明では、１つの例として送信側端末２０１から受信側端末２０２へビデオカメラ２０３によって取得された動画像データを転送する構成を中心として説明する。
【００５７】
ビデオカメラ２０３によって取得された動画像データは、送信側端末２０１の符号化装置（エンコーダ）２０４により符号化、例えばＭＰＥＧ圧縮処理等による符号化がなされ、階層化部２０５、優先度付け処理部２０６において、送信するデータ、および端末側の再生能力などに応じてデータを階層化し、優先度付け処理を実行する。
【００５８】
階層化部２０５は、符号化がなされたデータの階層化処理を実行する。基本階層（ベースレイヤー）は画像の基本となる階層であり、受信側端末２０２は、基本階層のみ受信した場合であっても最低限の品質を確保できる。さらに、上位階層のデータを受信することでより高品質なデータ例えば画像再生が可能となる。階層化部２０５は、このように符号化データに応じた階層区分処理を行なう。
【００５９】
ビデオオンデマンドやライブ映像のストリーミング配信、あるいはビデオ会議、テレビ電話などのリアルタイム通信においては、異なる能力を持つ端末を受信端末として、データ送受信が行われることを想定する必要がある。例えば、１つの情報送信ソースからの送信データは、携帯電話などのような解像度の低いディスプレイと処理能力の低いＣＰＵを有する受信端末によって受信されディスプレイに表示する処理が実行され、かつ、デスクトップパソコンのように高解像度のモニターと高い処理能力のＣＰＵを有する受信端末によって受信されて表示処理が実行される。このように、処理能力の異なる様々な受信端末を相手としたデータ送信が行なわれる。このように様々な受信端末において処理能力等に応じた受信処理、表示処理を実行させる手法として、送受信するデータの符号化を階層化させて実行するものであり、階層化部２０５は、このように符号化データに応じた階層化処理を行なう。
【００６０】
階層符号化によるデータ配信により、例えば、高解像度のディスプレイを有する受信端末においてのみ処理する符号化データと、高解像度のディスプレイを有する受信端末および低解像度のディスプレイを有する受信端末の双方において共通に処理する符号化データとを、それぞれ区別可能な態様でパケット化して配信可能となり、受信側において、データを選別して処理できる。
【００６１】
階層符号化が可能な圧縮・伸張方式としては、例えばＭＰＥＧ４とＪＰＥＧ２０００によるビデオストリームをあげることができる。ＭＰＥＧ４ではＦｉｎｅＧｒａｎｕａｌｉｔｙ Ｓｃａｌａｂｉｌｉｔｙ技術を規格に取り込みプロファイル化する予定であり、この階層符号化技術によりスケーラブルに低いビットレートから高いビットレートまで配信することが可能と言われている。また、ウェーブレット（Ｗａｖｅｌｅｔ）変換をベースとするＪＰＥＧ２０００は、ウェーブレット（Ｗａｖｅｌｅｔ）変換の特徴を生かし、空間解像度をベースにパケット化することや、あるいは画質をベースに階層的にパケット化することが可能である。またＪＰＥＧ２０００は静止画だけでなく動画を扱えるＭｏｔｉｏｎ ＪＰＥＧ２０００（Ｐａｒｔ ３）規格により、階層化したデータをファイルフォーマットで保存することが可能である。上述の階層符号化処理の適用により、１つのファイルデータから異なる能力の端末へ同時にデータ配信を実行することが可能となる。
【００６２】
また、階層符号化の例としてＤＣＴ（Discrete Cosine Transform）ベースの技術を用いた構成も可能である。これは配信情報となる例えば画像データをＤＣＴ処理し、ＤＣＴ処理により高域と低域とを区別した階層化を実現し、高域と低域との階層で区分したパケットを生成してデータ配信を実行する方法である。エンコーダ２０４では、上述のＤＣＴ処理、あるいは、ウェーブレット変換のような階層化の可能な符号化方式を実行する。
【００６３】
エンコーダ２０４は上述の階層符号化をあらかじめ設定されたプログレッシブ順序でのプログレッシブ符号化処理を実行する。すなわち上記したフェーブレット変換等に対応する空間解像度によるプログレッシブ、あるいはＳＮＲ（Signal to Noise Ratio）、すなわち画質毎に設定した階層に対応するプログレッシブ、あるいはカラー成分（ＲＧＢやＹＣｂＣｒ）毎の階層に対応するプログレッシブ等、様々なデータ階層に応じたプログレッシブ符号化処理を実行する。
【００６４】
プログレッシプ符号化とは、インターネットの画像配信等において多用される符号化処理であり、データ受信端末側で粗い画像データを先に出力し、順次、細かい画像を出力して表示することを可能とするものである。例えば、空間解像度によるプログレッシブ符号化の場合は、粗い画像に対応する低周波画像データの符号化データから精細な画像に対応する高周波画像データの符号化データを生成する。データの復号、表示を実行する端末では、低周波画像データの符号化データの復号、表示処理をまず実行することで、短時間でディスプレイに粗い概略画像を表示することが可能となり、その後、高周波領域の符号化データを復号し、表示することで、徐々に精細な画像を表示することが可能となる。ＳＮＲ（Signal to Noise Ratio）、すなわち画質によるプログレッシブの場合は、低ＳＮＲ（低画質）の符号化データから高ＳＮＲ（高画質）を区別して符号化する。カラー成分（ＲＧＢやＹＣｂＣｒ）によるプログレッシブの場合は、カラー成分（ＲＧＢやＹＣｂＣｒ）毎の符号化を実行する。
【００６５】
一例としてウェーブレット変換による符号化データの階層化処理について説明する。ウェーブレット変換は、入力画像信号を、ローパスフィルタ、ハイパスフィルタによって帯域分割処理を複数段に渡って実行し、低域成分を階層的に帯域分割した帯域成分を順次生成する処理として実行される。図３は、レベル３まで２次元画像を帯域分割した結果得られる帯域成分を図示したものである。この図３に示す例では、先ずレベル１の帯域分割（水平・垂直方向）により４つの成分ＬＬ、ＬＨ、ＨＬ、ＨＨに分かれる。ここでＬＬは水平・垂直成分が共にＬであること、ＬＨは水平成分がＨで垂直成分がＬであることを意味している。次に、ＬＬ成分は再度帯域分割されて、ＬＬＬＬ、ＬＬＨＬ、ＬＬＬＨ、ＬＬＨＨが生成される。さらに、ＬＬＬＬ成分は再度帯域分割されて、ＬＬＬＬＬＬ、ＬＬＬＬＨＬ、ＬＬＬＬＬＨ、ＬＬＬＬＨＨが生成される。
【００６６】
図２に示すエンコーダ２０４は、例えば上述したウェーブレット変換処理等の階層符号化を実行し、階層化部２０５において、各階層毎に分類され、さらに、優先度付け処理部２０６において各階層毎の優先度付け処理が行なわれる。なお、エンコーダ２０４は、ビットレート制御部２１１からの情報に基づいて符号化態様の変更、例えば符号化階層数等の変更を行なう。ビットレート制御部２１１は、ネットワーク監視部２１５が監視するネットワーク状況を受信する階層エラー訂正優先度制御部２１２の設定した情報に基づいて、エンコーダ２０４の符号化態様の設定を行なう。例えばネットワークの混雑等によるパケットの遅延状況等をネットワーク監視部２１５が検出し、検出情報に基づいてエンコーダ２０４は、符号化階層数等の変更等、符号化態様を動的に変更する。
【００６７】
優先度付け処理部２０６においては、階層符号化データの階層毎の重要度に応じた優先度を付与する。上述したウェーブレット変換データの空間解像度による階層レベル分けを実行した場合において、もっとも重要度の高い階層レベルは、ディスプレイに粗い概略画像を表示するために必要となるデータであり、これは、図３に示す低域（３ＬＬ）データを含む符号化領域、すなわち１／８のサイズのＬＬＬＬＬＬ、ＬＬＬＬＨＬ、ＬＬＬＬＬＨ、ＬＬＬＬＨＨデータ領域３０１に相当する。次の重要度の階層レベルは、次の低域の１／４のサイズのデータ領域となり、ＬＬＬＬ、ＬＬＨＬ、ＬＬＬＨ、ＬＬＨＨデータ領域３０２で構成され、次の重要度の階層レベルは、次の低域の１／２のサイズのデータ領域となり、ＬＬ、ＬＨ、ＨＬ、ＨＨデータ領域３０３で構成される。
【００６８】
優先度付け処理部２０６も、ネットワーク監視部２１５が監視するネットワーク状況を受信する階層エラー訂正優先度制御部２１２の設定した情報に基づいて、設定する優先度を動的に変更可能な構成を持つ。例えばネットワークの混雑等によるパケットの遅延状況等をネットワーク監視部２１５が検出し、この検出情報に基づいて優先度付け処理部２０６は、各符号化データに対して設定する優先度を動的に変更する。
【００６９】
優先度の設定は、例えば図４に示すような設定として実行される。エンコーダ２０４によって階層符号化されたデータを、例えば５階層とした場合、階層０〜階層４までの階層別の符号化データに区分し、これらをそれぞれパケット６５〜６９の５つのパケットにペイロードとして格納する例を示している。
【００７０】
階層０の符号化データが最も重要度の高いデータであり、この階層０の符号化データをペイロードとするＩＰパケット６５のＲＴＰヘッダ（ＲＴＰＨ）には優先度［０］を設定し、また、ＩＰヘッダ（ＩＰＨ）には、優先度［０］を設定する。階層１の符号化データは、次に重要度の高いデータであり、この階層１の符号化データをペイロードとするＩＰパケット６６のＲＴＰヘッダ（ＲＴＰＨ）には優先度［１］を設定し、また、ＩＰヘッダ（ＩＰＨ）には、優先度［１］を設定する。以下、階層２の符号化データをペイロードとするＩＰパケット６７のＲＴＰヘッダには優先度［２］、ＩＰヘッダには優先度［１］、階層３の符号化データをペイロードとするＩＰパケット６８のＲＴＰヘッダには優先度［３］、ＩＰヘッダには優先度［２］、階層４の符号化データをペイロードとするＩＰパケット６９のＲＴＰヘッダには優先度［４］、ＩＰヘッダには優先度［２］を設定する。
【００７１】
このＩＰヘッダ、ＲＴＰヘッダに対する優先度設定処理は、優先度付け処理部２０６内の記憶手段に記憶した優先度設定マップに従って実行される。図５に優先度設定マップの構成例を示す。優先度設定マップは、エンコーダ２０４において符号化された階層毎にＲＴＰヘッダ、ＩＰヘッダに設定する優先度を対応付けたマップである。
【００７２】
図５に示す優先度設定マップの例は、ウェーブレット変換において設定された階層のレベル：０〜４をＲＴＰパケットの拡張ヘッダ（ＲＴＰ共通ヘッダに続くＲＴＰペイロードヘッダ）に設定する優先度：０〜４としてそのまま適用している。また、ＩＰヘッダに設定する優先度は、０〜２の３種類としＩＰネットワークから見た場合の優先度は３レベルとなる。このように階層レベルからＲＴＰのレベルへの優先度の対応付けとＲＴＰレベルからＩＰレベルへの優先度のマッピングを行うことにより、例えば次のような制御が可能となる。
【００７３】
ＲＴＰレベルにおいてはパケットのシーケンス番号を管理しており、インターネットでロスがあった場合にロスしたパケットを検出可能である。パケットロスを検出することにより、受信側は例えばデコーダにパケットロス位置を通知することによって、エラー制御方法を変更することができる。エラー制御方式としては、例えばＦＥＣ(Forward Error Correction)を使用する。ＦＥＣの手法としては、ＡＴＭのＡＡＬ１におけるパケットロスに対してＦＥＣを行う手法、ITU-T Recommendation I.363.1, B-ISDN ATM Adaptation Layer (AAL), types 1 and 2 specificationに記載のマトリックスを作って損失パケットのリードソロモン復号する手法に準じた方法等が適用可能である。
【００７４】
このような処理はすべての階層レベルのパケットに対して同等に処理する必要はなく、例えばネットワークの帯域に応じてＦＥＣ（フォワードエラーコレクション）の冗長度を変化させたり、再送回数を優先度に応じて重み付けする。
【００７５】
なお、図５に示す優先度設定マップは、ネットワーク状況に応じて動的に変更する構成を持つ。ネットワーク監視部２１が取得する帯域監視情報、ＲＴＣＰによる送信パケットの損失率情報等を用いて、送信可能な帯域、保証可能な品質を考慮してマッピング方法を変える。階層レベルをＲＴＰパケットの優先度レベルあるいはＩＰパケットの優先度レベルへマッピングする優先度設定マップを生成する場合、元画像へのロスによる影響をネットワークのロス率を考慮して優先度を決めることが可能である。
【００７６】
このように、本発明のデータ通信システムにおいては、ＲＴＰヘッダのＲＴＰペイロードヘッダ内に、符号化データの階層レベルに応じた優先度を設定した構成としたので、ＲＴＰパケットレベルで上層のアプリケーションに依存した優先度の把握が可能となる。この優先度の把握により、パケットロスに対する処理を変えることが可能である。
【００７７】
このような階層レベル毎の処理はアプリケーションに依存し、ＲＴＰパケットレベルでは優先度に応じてどう処理するかは、ＲＴＰパケットレベルだけで決定してよい。同様に、ＩＰパケットレベルで優先度をつけて処理方法を変えることも可能である。この場合、ＩＰパケットレベルではＤｉｆｆＳｅｒｖのようにネットワークが提供する機能であるからネットワークがサポートする、あるいはネットワークが規定した優先度をつけるためにＲＴＰパケットレベルの優先度からＩＰパケットレベルの優先度へマッピングする。
【００７８】
図５に示す優先度設定マップにおいてはＲＴＰパケットレベルで５段階の優先度を設定し、ＩＰパケットレベルで３段階の優先度を設定した例である。ＲＴＰパケットレベル１がＩＰパケットレベル１に、ＲＴＰパケットレベル２，３がＩＰパケットレベル２に、ＲＴＰパケットレベル４，５がＩＰパケットレベル３に対応している。ＤｉｆｆＳｅｒｖで扱える優先度の数は現状のＩＰｖ４フォーマットでは少ないが、本例のようなマッピングを適用して、３段階の優先度に対応する処理は可能である。
【００７９】
例えば、解像度に基づくプログレッシブ順序に従った符号化データについてのパケット化の場合、低解像度データの符号化データを格納したパケットの優先度が高く、高解像度の符号化データを格納したパケットの優先度が低く設定され、受信端末では、各パケットのＩＰヘッダまたはＲＴＰヘッダに付与された優先度を参照して、低域のパケットを優先して処理することが可能となり、例えばネットワークの輻輳があっても該当するパケットの廃棄される率が下がることにより画質が改善される。
【００８０】
なお、優先度設定マップは、この他にも、様々な態様の構成が可能である。このように、階層符号化されたデータの重要度に応じて、アプリケーションに依存した優先度をＲＴＰペイロードヘッダに設定し、さらに、ＩＰヘッダに優先度を設定することが可能であり、これらの複数の優先度情報を使ってレイヤー毎にエラー制御方法を変えたり、レート制御を実行するなどの処理が可能となる。
【００８１】
ＲＴＰペイロードヘッダに設定する優先度はアプリケーションやユーザの要求、受信側端末から受信する受信側端末情報に応じて動的に変更設定可能であり、ＩＰヘッダに設定する優先度は、ネットワーク状況、例えばネットワークの輻輳度合いに応じて動的に変更設定する。なお、送信側端末２０１のネットワーク監視部は、受信側端末２０２から受信側端末のデータ受信状況に関する情報を受信し、階層エラー訂正優先度制御部２１２は、この情報に基づいて、上述したように、エンコーダ２０４における符号化態様、階層化部２０５における階層設定処理態様、優先度付け処理部２０６における優先度設定処理態様を動的に変更するための制御情報を各処理部に出力する。
【００８２】
このように、優先度付け処理部２０６において、優先度付け処理が行なわれたデータはバッファ２０７ヘ出力され保存される。バッファ２０７に保存された符号化データは、ＦＥＣ(Forward Error Correction)処理部２０８において、エラー訂正のための冗長コードが必要に応じて付与される。ＦＥＣの手法としては、ＡＴＭのＡＡＬ１におけるパケットロスに対してＦＥＣを行う手法、ITU-T Recommendation I.363.1, B-ISDN ATM Adaptation Layer (AAL), types 1 and 2 specificationに記載のマトリックスを作って損失パケットのリードソロモン復号する手法に準じた方法等が適用可能である。なお、ＦＥＣ(Forward Error Correction)処理部２０８における、エラー訂正のための冗長コード付与処理は、個々のデータに基づく冗長コード付与ではなく、エラー耐性を高めるために複数のデータに渡るテータに基づいて冗長コードを付与する処理、すなわちインターリーブ処理を併せて実行する構成としてもよい。
【００８３】
このＦＥＣ(Forward Error Correction)処理部２０８における、エラー訂正のための冗長コード付与処理はすべての階層レベルのパケットに対して同等に処理する必要はなく、ＦＥＣ(Forward Error Correction)処理部２０８は、例えばネットワークの混雑等によるパケットの遅延状況、ネットワークの帯域等をネットワーク監視部２１５が検出し、この検出情報に基づいてＦＥＣ（フォワード・エラー・コレクション）の冗長度を変化させる等、処理を動的に変更する。
【００８４】
上述のように、送信側端末２０１は、ネットワーク監視部２１５の情報、すなわち、受信側端末２０２からの受信側端末のデータ受信状況に関する情報、ネットワーク状況に関する情報に基づいて、エンコーダ２０４における符号化態様、階層化部２０５における階層設定処理態様、優先度付け処理部２０６における優先度設定処理態様、ＦＥＣ(Forward Error Correction)処理部２０８における処理を動的に変更可能である。
【００８５】
上述した送信側端末の処理構成に基づいて、例えば符号化階層（レイヤー）毎に実行すべきエラー処理態様として、ＦＥＣ処理対象階層データとしたり、あるいは再生要求処理（ＡＲＱ：Auto Repeat reQuest）対象階層データとしての割り当てが可能となり、各階層において最適なエラー訂正とスループットを得ることが可能となる。つまり、伝送路状況がエラー率が高かったり遅延が大きいなどパケット再生処理（ＡＲＱ：Auto Repeat reQuest）に不利な状況ではＦＥＣでエラー訂正を実行する設定としたり、あるいは伝送遅延が小さいが冗長データを送りたくない場合には、ＦＥＣではなくＡＲＱを利用したエラー対応とするなど、送信側で任意のエラー対応設定としたデータパケットの送信が可能となる。
【００８６】
また、受信側端末においても同様のネットワーク監視部２２９を有しており、ネットワークの混雑等によるパケットの遅延状況、ネットワークの帯域等の情報に基づいて、ネットワーク状況が良い場合には、階層を上げてより高品質なデータを再生する等の動的な対応が可能となる。
【００８７】
図２の送信側端末２０１の構成について説明を続ける。ＦＥＣ処理部２０８において、必要に応じてエラー訂正用の冗長コードが付与されたデータは、リアルタイム・トランスポート・プロトコル：ＲＴＰ（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）方式など種々の方法が提案され実現されている。
【００９９】
本発明のシステムにおいては、上述のようにＦＥＣとＡＲＱを組み合わせて、よりエラー耐性の強いデータ伝送が実現される。受信側端末２０２では、ネットワーク状況とバッファ状況、再生状況によって階層を落とさなくても、ＦＥＣ処理およびＡＲＱ処理にてその階層の品質が得られるならば、エラー訂正によって処理し、処理対象データの階層を落とすことによるデータ品質低下はできるだけ行わないよう制御する。
【０１００】
また、受信側端末の階層選択制御部２３１は、ネットワーク状況を監視するネットワーク状況監視部２２９のネットワーク状況情報に基づく処理データの選択を実行し、送信側端末の設定した階層または優先度に従って処理データを選択して実行する。例えばネットワーク状況が悪くパケットロス、遅延が大きい場合には、基本階層のみあるいは、優先度の高いデータのみを選択して処理を実行したり、ネットワーク状況がよくパケットロス、遅延が少ない場合には、より高階層のデータあるいは、優先度の低いデータも選択して処理を実行するなど、ネットワーク状況に応じたデータ選択処理を実行する。
【０１０１】
図２のデータ通信システムにおける受信側端末２０２のエラー訂正制御部２２３の処理について、さらに説明する。エラー訂正制御部２２３は、ネットワーク監視部２２９によって監視されている現在のネットワーク状況を踏まえてエラー訂正を制御する。ネットワークの監視は、往復伝播遅延（ＲＴＴ）やパケットロス率などＲＴＣＰやＩＣＭＰなどの汎用のプロトコルを利用して取得する。ＡＲＱにおいてデータ再生におけるリアルタイム性を保持するためには、常に送信と受信における往復伝播遅延（ＲＴＴ）を計測しておく必要がある。本発明のシステムでは、データ受信側端末は、能動的にＲＴＴを計測し、ネットワーク状況等において変化する送信と受信における往復伝播遅延（ＲＴＴ）の更新を実行し、最新のＲＴＴに基づいて再送要求としてのＮＡＣＫ−ＲＴＣＰの送信の実行可否を判定する。
【０１０２】
送信と受信における往復伝播遅延（ＲＴＴ）をデータ受信端末において、あらかじめ把握することにより、データ受信端末において、再送要求を行なってから再送パケットを受信するまでの時間の把握が可能となり、データ受信端末においてリアルタイム再生を行なうために必要な最終再送要求時間を割り出すことが可能なる。本発明のシステムでは、受信端末のＡＲＱ判定部において、往復伝播遅延（ＲＴＴ）に基づく最終再送要求時間を判定し、判定に基づいて、再送要求としてのＮＡＣＫ−ＲＴＣＰの送信を実行する。これらの処理については、次の各端末の処理フローの説明において詳細に説明する。
【０１０３】
［データ送信端末における処理］
以下、図面を参照しながら、データ送信端末における処理の詳細について説明する。
【０１０４】
データ送信端末の処理手順を図８に示すフローチャートを参照して説明する。図８に示す処理は、図２の送信側端末２０１において実行される処理を説明したフローである。送信側端末は、例えばビデオカメラ、あるいはＤＶＤ、ＣＤ、ハードディスク等の記憶媒体から撮り込んだデータをエンコーダにおいてＭＰＥＧ圧縮等の符号化処理を実行し、その後、符号化データをペイロードとしたパケットを生成する。図８に示すフローは、このパケット生成処理以降の処理を示している。
【０１０５】
データ送信端末は、ステップＳ３０１において、送信データをペイロードとしたＲＴＰパケット生成処理を実行する。ＲＴＰパケットは、先に図６を参照して説明した構成を有しタイムスタンプをヘッダ中に持つ。例えば動画像データを送信する場合は、同一画像フレームに属する符号化データを格納したパケットには同一のタイムスタンプが設定され、後続フレームに進むに従って、増分されたタイムスタンプが設定される。
【０１０６】
ステップＳ３０１で生成したＲＴＰパケットは、ステップＳ３０２、ステップＳ３０３において、必要に応じてＦＥＣ(Forward Error Correction)処理部２０８が、エラー訂正のための冗長コード付与処理を実行する。先に説明したように、ＦＥＣ処理部２０８における処理は動的に変更され、例えばネットワークの混雑等によるパケットの遅延状況、ネットワークの帯域等をネットワーク監視部２１５が検出し、この検出情報に基づいてＦＥＣ（フォワード・エラー・コレクション）の冗長度を変化させたり、あるいは冗長コードの付与対象の階層を変更して処理を実行する。ＦＥＣ処理部における処理を実行しないデータに対しては、ステップＳ３０３を飛ばしてステップＳ３０４に進む。
【０１０７】
ＦＥＣ処理部２０８は、ネットワーク監視部２１５が検出したネットワーク状況情報に基づいて階層エラー訂正優先度制御部２１２が生成した制御情報を入力して、入力する制御情報に基づいて処理態様が決定される。なお、前述したように、ＦＥＣ処理部２０８におけるエラー訂正のための冗長コード付与処理は、個々のデータに基づく冗長コード付与ではなく、エラー耐性を高めるために複数のデータに渡るテータに基づいて冗長コードを付与する処理、すなわちインターリーブ処理が併せて実行される。
【０１０８】
次に、ステップＳ３０４において、ＲＴＰポートを介して受信端末に向けてＩＰネットワークに出力される。なお、ＲＴＰパケットはさらに、先に図７を用いて説明したＩＰヘッダが付与され、ＩＰヘッダに設定されたアドレスに向けて配信されることになる。パケット生成、パケット送信処理は、ストリーミング配信されるデータが終了したことを明示的に示すＥＯＳ（End Of Stream）を配信し、予め設定した時間をタイマーで計測して、タイマーでの計測時間が設定時間を超えた場合に、処理を終了する。
【０１０９】
図８に示すステップＳ３０５のパケット再送要求としてのＮＡＣＫ−ＲＴＣＰパケットの受信判定処理、ステップＳ３０６のパケット受信確認応答としてのＡＣＫ−ＲＴＣＰパケットの受信判定処理、ステップＳ３０７のＲＴＴ時間計測用のＥＣＨＯ−ＲＴＣＰパケットの受信判定処理は、ＲＴＰパケットによる実データ送信中の割込み処理としてＲＴＰパケットによる実データ送信に並行して逐次実行される処理である。
【０１１０】
ステップＳ３０５の処理は、データ受信端末からのパケット再送要求であるＮＡＣＫ−ＲＴＣＰパケットの受信判定処理である。データ受信端末からのパケット再送要求であるＮＡＣＫ−ＲＴＣＰパケットを受信した場合は、ステップＳ３１３〜Ｓ３１７の処理を実行する。このステップＳ３１３〜Ｓ３１７の処理は、図２に示すエラー訂正制御部２３０における処理として実行される。
【０１１１】
ステップＳ３１３においては、データ送信装置は、ＮＡＣＫ−ＲＴＣＰパケットを受信する。図９にデータ受信端末において生成し、データ送信端末の受信するパケット再送要求であるＮＡＣＫ−ＲＴＣＰパケットの構成を示す。
【０１１２】
ＮＡＣＫ−ＲＴＣＰパケットは、図９に示すようにヘッダ（ＨＥＡＤ）、フォーマット（ＦＯＲＭＡＴ）、パケットタイプ、パケット長、送信同期ソース識別子（ＲＴＣＰ）、タイムスタンプの情報に加えて、再送要求対象となるパケットの識別子としての再送指定シーケンス番号、さらに、各再送指定シーケンス番号に対応するデータとして、「再送回数」、「オプション」、「重複指定回数」が設定可能である。
【０１１３】
前述したように、本発明の提案するＡＲＱを適用したシステムでは、ＲＴＣＰに従ったコントロール・パケットとして再送要求としてのＮＡＣＫ、受信確認としてのＡＣＫ、ストリーミング配信されるデータが終了したことを明示的に示すＥＯＳ、送信と受信における往復伝播遅延（ＲＴＴ）を計測する際に使用されるＥＣＨＯ、およびＥＣＨＯ−ＲＥＰＬＹのパケットが利用される。これらの各ＲＴＣＰパケットそれぞれのフォーマットタイプを一制御メッセージとして、すなわちＲＴＣＰヘッダのＰＴ（Payload Type）として区別をするのは汎用的ではない。よって、制御メッセージとしては、フィードバックメッセージ（FM：Feedback Message）として定義しＰＴ（Payload Type）に指定する。かつ、ＲＴＣＰヘッダ内の［フォーマット］フィールドであるＦＭＴ (Feedback Message Format)にそのパケットフォーマットの指定をすることで、どのようなフィードバックメッセージかを決定できる構成とする。
【０１１４】
図９に示すように、１つのＮＡＣＫパケットには１つ以上の再送要求対象となるパケットの識別子としてのシーケンス番号を付与することができる構成を持つ。つまり一度のＮＡＣＫパケットの送信処理で複数のパケットについての再送要求が可能になる。また、再送要求パケットのシーケンス番号各々に対して付加される「再送回数」は、何回目の再送要求かを明記するフィールドであり、「重複指定回数」は、再送する場合の多重回数の指定を明記するフィールドであり、「オプション」はその他の任意の情報を格納するフィールドとして使用される。
【０１１５】
例えば、「重複指定回数」に［３］をいれておけば、ＮＡＣＫを受信したデータ送信側は、同じデータを格納した再送パケットを［３］つ連続で送る処理を実行する。重要データを格納したパケットについては、重複再送を要求することで、再送パケットの受信の確実性を高めることが可能となる。また、繰り返し、同一パケットについての再送要求としてのＮＡＣＫを送信しているにもかかわらず、受信に成功しない場合や、リアルタイム再生に間に合うための再送可能最終時間に出されるＮＡＣＫにおいて、「重複指定回数」の設定数を増加させてデータ送信側に送信することにより、再送パケットの受信の確実性を高めることが可能となり、データ再生品質を向上させることが可能となる。データ受信側は、このようなＮＡＣＫ−ＲＴＣＰパケットを送信して、データ送信側は、受信したＮＡＣＫ−ＲＴＣＰパケットに基づくパケット再送処理を実行する。
【０１１６】
なお、ＲＴＰパケットフォーマットやペイロードフォーマット、または受信端末の利用者が意図的に指定した場合など、パケットに優先度が与えられている場合、優先度が高いパケットやデータに関しての再送は多重再送処理を行なうことで、再送パケットの受信確率を高めるようコントロール可能である。また、「再送回数」フィールドにおいて何回目の再送要求かを明記することで、ＮＡＣＫ自身が損失したことを送信側が検知できる。
【０１１７】
「オプション」フィールドには、フィールド設定値に従って、例えば図１０に示す処理指定を行なうことが可能となる。すなわち、
オプション設定値＝０
指定シーケンス番号を持つパケットのみの再送要求（デフォルト）
オプション設定値＝１
フレーム先頭パケットから指定シーケンス番号を持つパケットまでの一括再送要求
オプション設定値＝２
指定シーケンス番号からフレーム最後尾までのパケットの一括再送要求
オプション設定値＝３
指定タイムスタンプの付与されたパケットの一括再送要求
オプション設定値＝４
タイムスタンプを無視してシーケンス番号のみで検索して検索結果のパケットの再送を要求
【０１１８】
画像データ等の符号化データは、先に図６を参照して説明したように、タイムスタンプとシーケンス番号をセットとしたヘッダを持つ１つのＲＴＰパケットに格納した構成を有するが、データ転送処理において、タイムスタンプの変わり目を含んた連続的なエラーとしてのバーストエラーが起こった場合、あるいは、バーストエラーの発生により、フレーム単位でパケットの損失が発生した場合などにおいては、受信端末側では、パケット損失の発生したパケットに対応するタイムスタンプとシーケンス番号のセットを特定できない場合が発生する。このような場合において、特定可能なタイムスタンプ、あるいはシーケンス番号のいずれか一方のみを指定して、上記のオプション設定値を設定することにより、フレキシブルな態様で再送の必要な１以上のパケット指定が可能となる。
【０１１９】
このように、データ受信端末では、様々な態様での再送要求パケットの指定が可能であり、ＮＡＣＫ−ＲＴＣＰパケットを受信したデータ送信端末のＡＲＱ制御部２１３は、オプションフィールドの設定値に従って、バッファ２０７に格納済みのパケットから指定パケットを抽出して、再送処理を実行する。
【０１２０】
図８に戻り、データ送信端末の処理について説明する。ステップＳ３１４では、ステップＳ３１２で受信したＮＡＣＫ−ＲＴＣＰパケットに指定された再送要求パケットに対応するシーケンス番号を抽出し、ステップＳ３１５では、オプション指定の抽出を実行する。上述したように再送要求パケットの指定態様は、シーケンス番号の直接指定のみならず、タイムスタンプ等による指定等、様々であり、データ送信端末装置のＡＲＱ制御部２１３では、受信したＮＡＣＫ−ＲＴＣＰパケットに指定されたオプション指定、およびタイムスタンプ、シーケンス番号を参照して、再送要求パケットを特定する処理を実行する。
【０１２１】
ステップＳ３１６では、特定された再送要求パケットをバッファ２０７から抽出する。バッファ２０７には、再送要求に備えて所定時間、送信済みのパケットが保持格納されており、これらの格納パケットから再送指定のあったパケットを抽出する処理を実行する。ステップＳ３１７で、ＲＴＰポートから抽出パケットが送信される。
【０１２２】
ステップＳ３０５において、ＮＡＣＫ−ＲＴＣＰパケットを受信しない場合は、ステップＳ３０６でパケット受信応答としてのＡＣＫ−ＲＴＣＰパケットの受信確認を行ない、ＡＣＫ−ＲＴＣＰパケットの受信に基づいて、ステップＳ３１１で、受信の確認されたパケットをバッファ２０７からクリア（削除）する。このＡＣＫにより、再送要求に対応してパケットを保持する送信側のバッファを能動的に早めにクリアすることが可能となり、バッファ溢れの恐れを低下させることが可能となる。
【０１２３】
図１１にデータ受信端末において生成し、データ送信端末の受信するパケット受信確認応答であるＡＣＫ−ＲＴＣＰパケットの構成を示す。
【０１２４】
ＡＣＫ−ＲＴＣＰパケットは、図１１に示すようにヘッダ（ＨＥＡＤ）、フォーマット（ＦＯＲＭＡＴ）、パケットタイプ、パケット長、送信同期ソース識別子（ＲＴＣＰ）、タイムスタンプの情報に加えて、受信パケットの識別子としての受信済みシーケンス番号が格納される。
【０１２５】
なお、シーケンス番号を指定せず、タイムスタンプ（TIMESTAMP）のみ指定する構成とすることも可能であり、この場合には、そのタイムスタンプ（TIMESTAMP）の設定されたパケットすべてを受け取った事を示す。よってこのような場合にはシーケンス番号をすべて指定する必要はないため、ＡＣＫ−ＲＴＣＰパケットサイズを小さくすることが可能となり、ネットワークトラフィックの増大を低減できる。
【０１２６】
図８に戻り、データ送信端末の処理の説明を続ける。データ送信端末は、ステップＳ３０７において、ＥＣＨＯ−ＲＴＣＰパケットの受信確認を行ない、データ受信端末からＥＣＨＯ−ＲＴＣＰパケットを受信した場合は、ステップＳ３１１において、ＥＣＨＯ−ＲＥＰＬＹ−ＲＴＣＰパケットをＥＣＨＯ−ＲＴＣＰパケットを送信してきたデータ受信端末に対して送信する処理を実行する。
【０１２７】
ＥＣＨＯ−ＲＴＣＰパケットと、ＥＣＨＯ−ＲＥＰＬＹ−ＲＴＣＰパケットは、送信端末と受信端末における往復伝播遅延（ＲＴＴ）をデータ受信端末において把握するために用いるＲＴＣＰパケットである。このパケットの送受信によって、データ受信端末において、再送要求を行なってから再送パケットを受信するまでの時間の把握が可能となり、データ受信端末においてリアルタイム再生を行なうために必要な最終再送要求時間を割り出すことが可能なる。
【０１２８】
本発明のシステムでは、受信端末のエラー訂正制御部２３０において、往復伝播遅延（ＲＴＴ）に基づく最終再送要求時間を判定し、判定に基づいて、再送要求としてのＮＡＣＫ−ＲＴＣＰの送信の実行可否を決定する。この判定処理に必要な送信端末と受信端末における往復伝播遅延（ＲＴＴ）の最新情報を取得するため、データ受信端末側は、任意タイミングで、能動的にＥＣＨＯ−ＲＴＣＰパケットをデータ送信端末に送信し、データ送信端末は、ＥＣＨＯ−ＲＴＣＰパケットの受信に応答してＥＣＨＯ−ＲＥＰＬＹ−ＲＴＣＰパケットをＥＣＨＯ−ＲＴＣＰパケットを送信してきたデータ受信端末に対して送信する。
【０１２９】
データ受信端末では、データ送信端末からの応答として受信するＥＣＨＯ−ＲＥＰＬＹ−ＲＴＣＰパケットを解析することによって、送信端末と受信端末における往復伝播遅延（ＲＴＴ）を算出する。このＲＴＴ算出処理については、後段のデータ受信端末の処理の項目で説明する。
【０１３０】
図１２にデータ受信端末において生成し、データ送信端末の受信するＥＣＨＯ−ＲＴＣＰパケットの構成、および、データ送信端末において生成し、データ受信端末に対して送信するＥＣＨＯ−ＲＥＰＬＹ−ＲＴＣＰパケットの構成を示す。
【０１３１】
ＥＣＨＯ−ＲＴＣＰパケットは、図１２（ａ）に示すようにヘッダ（ＨＥＡＤ）、フォーマット（ＦＯＲＭＡＴ）、パケットタイプ、パケット長、送信同期ソース識別子（ＲＴＣＰ）、およびＥＣＨＯパケットの識別データとしてのＥＣＨＯ−ＩＤが格納される。ＥＣＨＯ−ＲＥＰＬＹ−ＲＴＣＰパケットは、図１２（ｂ）に示すようにヘッダ（ＨＥＡＤ）、フォーマット（ＦＯＲＭＡＴ）、パケットタイプ、パケット長、送信同期ソース識別子（ＲＴＣＰ）、およびＥＣＨＯ−ＲＴＣＰパケットに対応するＥＣＨＯ−ＩＤ、および、サーバ処理時間が格納される。
【０１３２】
ＥＣＨＯ−ＩＤをＥＣＨＯ−ＲＴＣＰパケットとＥＣＨＯ−ＲＥＰＬＹ−ＲＴＣＰパケットに入れることにより、データ受信端末側がＥＣＨＯ−ＲＥＰＬＹを受け取った際に、いつ送信したＥＣＨＯ−ＲＴＣＰパケットに対応する返事（ＥＣＨＯ−ＲＥＰＬＹ）かを識別することが可能となる。ＥＣＨＯ−ＲＥＰＬＹ−ＲＴＣＰパケットに格納されるサーバ処理時間は、データ送信端末がデータ受信端末からの再送要求（ＮＡＣＫ−ＲＴＣＰ）を受信してからパケットをデータ送信端末から出力するまでに要する処理時間に相当する時間である。このサーバ処理時間は、ＥＣＨＯ−ＲＴＣＰパケットを受信した時間からＥＣＨＯ−ＲＥＰＬＹ−ＲＴＣＰパケットを送信するまでの時間として設定するか、あるいは、予めデータ送信端末において過去の履歴データとして、実際に、データ送信端末がデータ受信端末からの再送要求（ＮＡＣＫ−ＲＴＣＰ）を受信してからパケットをデータ送信端末から出力するまでに要した時間をメモリに格納し、この格納データを適用してもよいし、あるいは、ＥＣＨＯ−ＲＴＣＰパケットを受信した時点におけるサーバ（データ送信端末）における処理負荷を算出して、処理負荷に基づいて算出される予測処理時間をサーバ処理時間として設定する構成としてもよい。
【０１３３】
データ受信端末は、ＥＣＨＯ−ＲＥＰＬＹ−ＲＴＣＰパケットに格納されたサーバ処理時間と、ＥＣＨＯ−ＲＴＣＰパケット送信からＥＣＨＯ−ＲＥＰＬＹ−ＲＴＣＰの受信までの時間とに基づいて、送信端末と受信端末における往復伝播遅延（ＲＴＴ）を算出する。このＲＴＴ算出処理については、後段のデータ受信端末の処理の項目で説明する。
【０１３４】
図８に戻り、データ送信端末の処理の説明を続ける。データ送信端末は、ステップＳ３０６において、送信対象となるストリーミングデータのパケット送信がすべて終了したかを判定し、終了と判定した場合は、ステップＳ３１０において、データストリームの終了を明示するＥＯＳ（End Of Stream）メッセージを持つＲＴＣＰパケットを受信側端末へ送信する処理を実行する。
【０１３５】
図１３にデータ送信端末において生成し、データ受信端末の受信するＥＯＳ−ＲＴＣＰパケットの構成を示す。
【０１３６】
ＥＯＳ−ＲＴＣＰパケットは、図１３に示すようにヘッダ（ＨＥＡＤ）、フォーマット（ＦＯＲＭＡＴ）、パケットタイプ、パケット長、送信同期ソース識別子（ＲＴＣＰ）、およびタイムスタンプ（ＴＩＭＥＳＴＡＭＰ）が格納される。データ受信端末は、ＥＯＳ−ＲＴＣＰパケットをデータ送信端末から受信することにより、ストリーミング配信されるデータの終了を認識する。受信端末はこの認識処理により、次フレームが到着しないことによる誤ったＮＡＣＫ送出動作を防ぐことができる。
【０１３７】
図８に戻り、データ送信端末の処理の説明を続ける。データ送信端末は、ステップＳ３０９において、予め設定した時間を計測するタイマーでの計測時間が設定時間を超えたか否かを判定して、タイマーが設定時間を超えていない場合は、ステップＳ３０５以下の処理、すなわち、ステップＳ３０５のパケット再送要求としてのＮＡＣＫ−ＲＴＣＰパケットの受信判定処理以下の処理を継続して実行する。これは、全パケット送出後においても、一定時間は、データ受信側からのパケット再送要求としてのＮＡＣＫ−ＲＴＣＰパケット、または、受信確認応答としてのＡＣＫ−ＲＴＣＰパケット、または、ＥＣＨＯ−ＲＴＣＰパケットを受信する可能性があり、これらのパケット受信に対する処理を実行するためである。タイマーにおいて、予め設定した時間が経過した時点で、データ送信を終了する。
【０１３８】
［データ受信端末における処理］
次に、データ受信端末の処理手順を図１４に示すフローチャートを参照して説明する。図１４に示す処理は、図２の受信側端末２０２において実行される処理を説明したフローである。
【０１３９】
データ受信端末は、ステップＳ４００において、データ送信端末からの送信開始通知を受信後、ステップＳ４０１において、データ送信端末からの送信パケット、すなわち符号化データをペイロードとして格納したＲＴＰパケットを順次、受信する。ＲＴＰパケットは、先に、図６を参照して説明したように、タイムスタンプがヘッダ情報中に格納されている。データ受信端末は、タイムスタンプに基づいて受信するパケットに含まれるフレームを判別することができる。先に説明したように、動画像データをＲＴＰパケットに符号化データとして格納して送信する場合、同一の画像フレームに属する複数のＲＴＰパケットには同一のタイムスタンプが設定され、データ受信側端末は、タイムスタンプを参照して、フレームの判別が可能となる。
【０１４０】
データ受信端末は、ステップＳ４０２において、受信パケットがエラー訂正のための冗長コードが付与されているか否かを判定する。冗長コードが付与されている場合は、ステップＳ４１１に進み、エラー訂正制御部２３０において、データ送信側で実行したインターリーブ対応するインターリーブ処理を実行して、ステップＳ４１２において、損失パケットの有無を判定する。損失パケットが無い場合は、ステップＳ４１６のデコード処理に進む。損失パケットがある場合は、ステップＳ４１３で、ＦＥＣによるエラー訂正、すなわち冗長コードに基づくエラー訂正処理を実行し、エラー訂正により再生可能か否かを判定する。再生可能であると判定した場合は、ステップＳ４１６のデコード処理に進む。
【０１４１】
ステップＳ４１３においてＦＥＣによる処理のみでは、再生可能でないと判定した場合は、ステップＳ４１５に進む。ステップＳ４１５の再送要求処理としてのＮＡＣＫ−ＲＴＣＰパケットの送信判定処理について説明する。リアルタイム再生処理を実現するためには、再生タイミングに間に合うように、再送要求パケットが受信端末に届くことが必要となる。ステップＳ４１５の再送要求処理としてのＮＡＣＫ−ＲＴＣＰパケットの送信判定処理は、ＮＡＣＫ−ＲＴＣＰパケットを送信した場合、リアルタイム再生処理に間に合うタイミングで、再送パケットが受信可能か否かを判定するものである。
【０１４２】
この判定のためには、前述したように、送信端末と受信端末間における往復伝播遅延（ＲＴＴ）が重要なパラメータとなる。往復伝播遅延（ＲＴＴ）が大きい場合、データ受信端末からデータ送信端末に対して再送要求を出しても、再送要求を発信して、再送パケットがデータ送信端末から再送され、データ受信端末において受信するまでに時間を要すると、その後デコーダに渡して復号を行なってリアルタイム再生に間に合わない場合が発生する。本発明のシステムでは、データ受信端末において、往復伝播遅延（ＲＴＴ）をあらかじめ把握し、往復伝播遅延（ＲＴＴ）に基づいて、ＮＡＣＫ−ＲＴＣＰパケットの送信判定処理を行なう。
【０１４３】
本発明のシステムにおいては、データ受信端末側が、任意タイミングで、往復伝播遅延（ＲＴＴ）の計測を実行することを可能な構成としている。具体的には、データ受信端末から、先に説明した図１２に示すＥＣＨＯ−ＲＴＣＰパケットを送信し、ＥＣＨＯ−ＲＥＰＬＹ−ＲＴＣＰパケットを受信して、ＲＴＴの算出を行なう。
【０１４４】
図１５を参照して、データ受信端末で実行するＥＣＨＯ−ＲＴＣＰパケットの送信、ＥＣＨＯ−ＲＥＰＬＹ−ＲＴＣＰパケットの受信、往復伝播遅延（ＲＴＴ）の算出処理について説明する。
【０１４５】
図１５（ａ）は、ＥＣＨＯ−ＲＴＣＰパケットの送信処理フローである。ＥＣＨＯ−ＲＴＣＰパケットの送信は、データ受信端末が任意タイミングで能動的に実行することが可能である。
【０１４６】
ステップＳ５０１における、ＲＴＣＰパケットの送信待機状態において、ＲＴＴの計測要請が発生した場合、ステップＳ５０２のＥＣＨＯ−ＲＴＣＰパケットの生成処理に移行する。ＲＴＴの計測は、データ受信が開始された後、例えば図１４の処理フローにおいて、ステップＳ４００の送信開始通知を受信した以降、定期的に実行する等の設定が可能であり、データ受信側端末に保有するタイマーで予め定めた計測間隔が経過したか否かを計測し、予め定めた計測間隔に対応する時間が経過した場合に、エラー訂正制御部２３０が、ＥＣＨＯ−ＲＴＣＰパケットの生成要求をＲＴＣＰパケット生成部２２７に出力し、ＲＴＣＰパケット生成部２２７がステップＳ５０２のＥＣＨＯ−ＲＴＣＰパケットの生成処理を実行するなどの設定が可能である。この他にも、パケットのロスト状況を解析し、ロスト状況に応じてＥＣＨＯ−ＲＴＣＰパケットの生成、送信を実行する構成としてもよく、いずれにしても、データ受信端末は、任意タイミングで、ＥＣＨＯ−ＲＴＣＰパケットの生成、送信が可能であり、常に最新の往復伝播遅延（ＲＴＴ）の算出が可能となる。
【０１４７】
ステップＳ５０２で生成するＥＣＨＯ−ＲＴＣＰパケットは、先に図１２（ａ）を参照して説明した構成を有する。パケットには、各パケット固有の識別子としてのＥＣＨＯ−ＩＤが設定される。ステップＳ５０３で、生成したＥＣＨＯ−ＲＴＣＰパケットが、ＲＴＣＰポート２２５を介して、データ送信端末２０１に対して送信される。ステップＳ５０４では、ＥＣＨＯ−ＲＴＣＰパケットを送信した送信時間、および、パケットに設定されたＥＣＨＯ−ＩＤがメモリに記録される。
【０１４８】
図１５（ｂ）は、ＥＣＨＯ−ＲＥＰＬＹ−ＲＴＣＰパケットの受信およびＲＴＴ算出処理フローである。ステップＳ６０１における、ＲＴＣＰパケットの送信待機状態において、ＥＣＨＯ−ＲＥＰＬＹ−ＲＴＣＰパケットが受信されたと判定（ステップＳ６０２でＹｅｓ）されると、ステップＳ６０３において、ＥＣＨＯ−ＲＥＰＬＹ−ＲＴＣＰパケットの受信時刻がメモリに記録される。受信するＥＣＨＯ−ＲＥＰＬＹ−ＲＴＣＰパケットは、先に図１２（ｂ）を参照して説明した構成を有する。パケットには、応答対象となった対応するＥＣＨＯ−ＲＴＣＰパケットと同一の識別子としてのＥＣＨＯ−ＩＤが設定され、さらに、データ送信端末において算出したサーバ処理時間が格納される。
【０１４９】
ステップＳ６０４では、受信したＥＣＨＯ−ＲＥＰＬＹ−ＲＴＣＰパケットからサーバ処理時間が抽出され、ステップＳ６０５において、受信したＥＣＨＯ−ＲＥＰＬＹ−ＲＴＣＰパケットに設定されたＥＣＨＯ−ＩＤから対応するＥＣＨＯ−ＲＴＣＰパケットの送信時間が検索される。
【０１５０】
ステップＳ６０６では、ステップＳ６０３において取得したＥＣＨＯ−ＲＥＰＬＹ−ＲＴＣＰパケットの受信時刻、ステップＳ６０４において取得したサーバ処理時間、ステップＳ６０３において取得したＥＣＨＯ−ＲＴＣＰパケットの送信時間に基づいて、往復伝播遅延（ＲＴＴ）の算出処理が実行される。往復伝播遅延（ＲＴＴ）の算出は、下式に基づいて実行される。
往復伝播遅延（ＲＴＴ）
＝(ECHO-REPLAY受信時刻)-(ECHO送信時刻)-(サーバ処理時間)
【０１５１】
なお、ＲＴＴの計測を実行する際に送受信するＥＣＨＯ，ＥＣＨＯ−ＲＥＰＬＹパケットも損失することが考えられる。またＲＴＴもネットワークの状況により常に変動するため、データ受信端末は一定間隔でＥＣＨＯ，ＥＣＨＯ−ＲＥＰＬＹパケットの送受信処理を実行してＲＴＴを計測する。
【０１５２】
図１４のフローに戻り、データ受信端末側の処理について説明を続ける。図１４のフローにおいて、ステップＳ４１５では、再送要求としてのＮＡＣＫ−ＲＴＣＰを出力した場合、リアルタイム再生処理に間に合うタイミングで再送要求パケットの受信が可能か否かを判定する。上述したＥＣＨＯ，ＥＣＨＯ−ＲＥＰＬＹパケットの送受信処理により計測されたＲＴＴ値と、各フレームの処理タイミングを計測しているタイマーの期限に基づいて、再送要求としてのＮＡＣＫ−ＲＴＣＰパケットを出しても間に合わないと判断した場合（Ｓ４１５でＮｏ）には、ＮＡＣＫ−ＲＴＣＰパケットの送信処理は実行しない。
【０１５３】
たとえば、パケット損失の存在する該当フレームの符号化データの処理開始までの時間Ｔａ＝１００ｍｍｓｅｃである場合、すなわち１００ｍｍｓｅｃ後にデコーダにデータを渡して復号処理が開始されることがタイマーの計測により明らかとなっている場合、計測された最新のＲＴＴ値が、該当フレームの符号化データの処理開始までの時間Ｔａより大きい値であった場合、すなわち、１００ｍｍｓｅｃ以上であった場合には、再送要求としてのＮＡＣＫ−ＲＴＣＰパケットを送信しても、再送パケットの受信が、デコード処理開始タイミングに間に合わないものと判断して、ＮＡＣＫ−ＲＴＣＰパケットの送信処理を実行しない。ただし、ＲＴＴ値が処理開始までの時間Ｔａ以上であっても、ＲＴＴ値と時間：Ｔａの非常に近い値を持つ場合には、ぎりぎり間に合う可能性もあるためＮＡＣＫを送出する構成としてもよい。このＮＡＣＫ送出判定の閾値は実装依存である。
【０１５４】
一方、計測された最新のＲＴＴ値が、パケット損失の存在する該当フレームの符号化データの処理開始までの時間Ｔａ以下であった場合には、再送要求としてのＮＡＣＫ−ＲＴＣＰパケットを送信して再送パケットを受信するまでの時間が、デコード処理開始タイミングまでの時間以下であるので、再送パケット受信が処理に間に合うものと判断して、ステップＳ４１７において、ＮＡＣＫ−ＲＴＣＰパケットの送信処理を実行する。
【０１５５】
図１４のフローのステップＳ４０２において、ＦＥＣによる冗長コードんが付与されていないパケットであると判定した場合は、ステップＳ４０３において、受信したパケットが、ｎフレーム目（ｎ=１，２...）の終端パケットであるか否かを判定する。また、ステップＳ４０４において、受信したパケットが、ｎ＋１フレーム目の先頭パケットであるか否かを判定する。受信したパケットが、ｎフレーム目（ｎ=１，２...）の終端パケットである場合、または、ｎ＋１フレーム目の先頭パケットである場合には、ステップＳ４１４に進む。
【０１５６】
ステップＳ４１４においては、ｎフレーム内に未受信のパケット、すなわちロストパケット、あるいはエラーパケットがあるか否かを判定する。
【０１５７】
ロストパケットまたはエラーパケットが検出されると、ステップＳ４１５以下の処理に進み、再送要求処理としてのＮＡＣＫ−ＲＴＣＰパケットの送信判定処理、および判定に基づくＮＡＣＫ−ＲＴＣＰパケットの送信処理が実行される。これらの判定処理の詳細は、前述した通りである。
【０１５８】
ＮＡＣＫ−ＲＴＣＰパケット送信の際にタイムスタンプ（TIMESTAMP）とシーケンス番号の組み合わせがはっきりしない場合には、先に図１０を参照して説明したオプションを指定して送信する。データ受信端末では、パケットの送受信情報を随時記録することで、パケットロス率の割り出しが可能となる。このロス率が一定値以上になった場合には、ＮＡＣＫ−ＲＴＣＰパケット自体の損失の可能性が考えられるため、おなじＮＡＣＫ−ＲＴＣＰパケットを複数回、重ねて送信する処理を行なうことで、再送成功率を高めることが可能となる。あるいは、ＮＡＣＫ−ＲＴＣＰパケットに重複指定回数を増分して設定する。
【０１５９】
データ送信端末は、ＮＡＣＫ−ＲＴＣＰパケットを受信すると、次のタイムスタンプを設定したフレームデータに併せて、再送パケットを送信する。
【０１６０】
ステップＳ４１４のロストパケットの検出処理は、ステップＳ４０３の各フレームの終端パケット受信、ステップＳ４０４の各フレームの先頭パケット受信時のみではなく、ステップＳ４０５の各フレームの最終再送時間の判定でＹｅｓの場合、およびステップＳ４０６のタイマーの最小計測時間τの経過判定でＹｅｓの場合に実行される。
【０１６１】
ステップＳ４０５の各フレームの最終再送時間の判定処理は、再送要求としてのＮＡＣＫ−ＲＴＣＰを出力した場合、リアルタイム再生処理に間に合う最終時間判定処理である。各フレームについて、各フレームの符号化データの処理開始までの時間Ｔａが計測されているＲＴＴ値と等しくなったとき、すなわち、Ｔａ＝ＲＴＴとなった場合に、ステップＳ４０５の判定がＹｅｓとなり、ステップＳ４０９の該当フレームに対するロストパケットの検出処理が実行される。これは、最後の再送要求可能タイミングにロストパケットを検出して、検出された場合に最後の再送要求を送信するための処理である。
【０１６２】
ステップＳ４０６のタイマーの最小計測時間τの経過判定処理は、データ受信端末の有するタイマーの計測最小時間：τ毎に、ステップＳ４０６の判定がＹｅｓとなり、ステップＳ４１４の該当フレームに対するロストパケットの検出処理が実行される。これは、各計測最小時間：τに対応する受信フレームについて、各フレームの先頭パケット、最終パケットの検出がなされない場合でもロストパケットを確実に検出して、再送要求を実行しようとするための処理である。
【０１６３】
このように、データ受信端末では、ステップＳ４０３の各フレームの終端パケット受信、ステップＳ４０４の各フレームの先頭パケット受信時、ステップＳ４０５の各フレームの最終再送時間の判定、およびステップＳ４０６のタイマーの最小計測時間τの経過判定の各タイミングにおいて、ステップＳ４１４のロストパケットの検出処理を実行する。なお、これらステップＳ４０３〜Ｓ４０６の４種類のタイミングのいずれかのみを実行する構成としてもよい。
【０１６４】
ステップＳ４１４の各フレームのロストパケット検出処理において、ロストパケットが検出されなかった場合は、各パケットに格納された符号化データのデコード（復号）処理がデコーダ２２４において実行される。ステップＳ４１８では、受信済みパケットについての受信確認パケットとしてのＡＣＫ−ＲＴＣＰパケットの生成、送信が行われる。ＡＣＫ−ＲＴＣＰパケットは、先に図１１を参照して説明した通り、受信済みシーケンス番号を格納したパケットである。このＡＣＫ−ＲＴＣＰパケットを受信したデータ送信端末は、ＡＣＫ−ＲＴＣＰパケットに記録された受信済みシーケンス番号に対応するパケットをバッファ２２３からクリアする。
【０１６５】
図１４に示すフローのステップＳ４０７では、各フレームのタイマー期限切れを確認する。このタイマー期限は、リアルタイム再生処理の開始期限を計測するタイマーによって設定される期限であり、各フレーム毎にそのタイミングが設定される。ｎフレームのタイマー期限切れであると判定された場合には、ロストパケットがあった場合であっても、ステップＳ４１６のデコード処理に移行することになる。
【０１６６】
ステップＳ４０８では、データ送信端末から、データストリームの終了を明示するＥＯＳ（End Of Stream）メッセージを持つＲＴＣＰパケットを受信したか否かを判定し、ＥＯＳ−ＲＴＣＰパケット受信でない場合は、ステップＳ４０１以下の処理を繰り返す。
【０１６７】
ＥＯＳ−ＲＴＣＰパケット受信である場合は、ステップＳ４０９において、各フレームのタイマー期限切れを確認する。このタイマー期限は、リアルタイム再生処理の開始期限を計測するタイマーによって設定される期限であり、各フレーム毎にそのタイミングが設定される。タイマー期限切れでない場合は、ステップＳ４１９に進み、再送要求されているロストパケットに関する再送パケットを受信待機状態であるか否かを判定して、待機状態である場合は、ステップＳ４２０に進み、再送パケットの受信待機状態として、ステップＳ４０１のパケット受信以下の処理を実行する。
【０１６８】
ステップＳ４０９における各フレームのタイマー期限切れの確認処理において、Ｙｅｓと判定された場合、および、ステップＳ４１９において、再送パケット受信待機状態でないと判定された場合は、デコード、再生処理へ移行すべき未受信のパケットデータは存在しないと判定され、受信処理を完了する。
【０１６９】
このように、本発明のシステムにおいては、リアルタイム配信に適するものの信頼性を保証しないＲＴＰ等のデータ通信プロトコルに従ったパケット伝送において、ＦＥＣ処理によるエラー訂正、または再送要求としてのＡＲＱを選択的に実行することで、エラー耐性のある信頼性の高いデータ伝送、リアルタイム再生が可能となる。なお、上述の実施例では、ＲＴＰパケットに符号化データを格納する構成例を中心として説明したが、ＲＴＰパケットフォーマットに限らず、ＵＤＰ等、他のデータ通信プロトコルフォーマットに従ったパケットを用いたデータ通信構成においても、上述の実施例と同様の各種のコントロールパケットを用いた再送要求処理を行なうことにより、上述の実施例と同様の構成を実現可能である。
【０１７０】
上述したように本発明の構成では、再送要求の処理タイミングとして、各フレームの先頭パケットの受信時、各フレームの最終パケットの受信時、最終処理期限、および一定間隔（τ）毎等の各種タイミングでロストパケットの検出処理を実行する構成としたので、確実なロストパケットの検出が可能となる。
【０１７１】
また、本発明のデータ通信システムにおける送信側端末の階層エラー訂正優先度制御部２１２は、および受信側端末２０２のエラー訂正制御部２３０は、それぞれのネットワーク監視部２１５、２２９によって監視されている現在のネットワーク状況を踏まえてエラー訂正を制御する。ネットワークの監視は、ＲＴＴやパケットロス率などＲＴＣＰやＩＣＭＰなどの汎用のプロトコルを利用して取得する。受信側がＲＴＴを検知するために、受信側は、前述したＥＣＨＯパケットを送信側に送り、その返事であるＥＣＨＯ−ＲＥＰＬＹパケットを受け取ることにとって、ＲＴＴを計測し、確実なパケット再送処理が実現される。
【０１７２】
先に説明したように、ＲＴＰではパケット毎にシーケンス番号をつけており、番号とフレームの先頭と終端を示すフラグをペイロードにいれておくことにより、あるフレームを構成するパケット数を簡単に受信側は計算することができ、必要なパケット数に対してある時間内にどれだけ正当なパケットが届いたかを監視していれば、ある程度のエラー率を求めることができる。ここで得られたエラー率またはＲＦＣ１８８９で規定されているＲＴＣＰのＲＲ（Ｒｅｃｉｅｖｅｒ Ｒｅｐｏｒｔ）でのパケットロス率により、送信側はエラー率を知りＦＥＣのエラー訂正強度をあげたり、またはＦＥＣを施さないなどの処理態様の制御を実行する。
【０１７３】
エラー訂正処理として実行されるパケット再送要求（ＡＲＱ）は、再送要求ＮＡＣＫを送信し再送パケットが届くまでにＲＴＴ時間を要することになり、また、ＦＥＣ訂正においても送受信端末でインターリーブする処理のために一定時間が必要となる。それぞれの端末におけるネットワーク監視部の監視により得られるネットワーク状況に基づいて、例えば、ＲＴＴが短いならば、ＡＲＱによる再送が可能となるためＡＲＱによるエラー訂正を選択して実行し、ＲＴＴが長く、再送する時間がないほど送信側から受信側に転送時間がかかるというネットワーク状況である場合には、ＡＲＱではなくＦＥＣによるエラー訂正を選択する、といった動的なエラー訂正制御が可能となる。
【０１７４】
受信側端末のエラー監視部２２２では、ＲＴＰではパケット毎のシーケンス番号に基づいて、必要なパケット数に対してある時間内にどれだけ正当なパケットが届いたかのエラー率を求めることができ、また、送信側端末では、再送要求処理の数をカウントすることでエラー率を概算することが可能となる。エラー率が高く、ＦＥＣによるエラー訂正で訂正できないほどの高いエラー率であると判定した場合には、送信側端末２０１の階層エラー訂正優先度制御部２１２は、ＦＥＣ処理部における冗長コードの付与を停止し、すべて受信側端末からの再送要求（ＡＲＱ）に応答するのみの処理を選択したり、あるいは、よりエラー訂正の強いアルゴリズムのＦＥＣを選択するといったエラーに対する処理態様を動的に変更することが可能となる。
【０１７５】
また、これらのエラー制御態様は、伝送するデータ階層に応じた優先度に対応して選択的に設定可能であり、様々なエラー訂正ポリシーが決められる。例えば受信側端末２０２のネットワーク状況監視部２２９は、パケットロス率、または伝送遅延時間に基づくネットワーク状況解析を実行し、階層選択制御部２３１が、解析結果に基づいて処理データの選択を実行することが可能である。
【０１７６】
さらに、このエラー訂正ポリシーは、ネットワーク状況や送信および受信端末側の意図により変更可能なため、一意に決まるものとすることは必要でない。ある送信環境とメディアによっては、基本となる階層は必ず完全再生したいので、強めのＦＥＣ＋ＡＲＱで優先度を上げておく、音声データはＦＥＣのみで、オーバーヘッドは極力避けたいのでＦＥＣなしでＡＲＱとして再送回数１回まで、といったように自由な態様でのエラー制御態様を設定することができる。
【０１７７】
また、本発明のシステムでは、データ受信端末は、再生処理時間、伝播遅延時間ＲＴＴを考慮したデータ再送要求処理を実行するので、無駄な再送要求パケットおよび再送パケットを出すことを防ぐ事ができ、ネットワークの帯域を再送によって狭めることがない。また、データ受信端末が、パケットの送受信情報を随時記録し、パケットロス率の割り出しにより、ロス率が一定値以上になった場合、おなじＮＡＣＫ−ＲＴＣＰパケットを複数回、重ねて送信することで、再送成功率を高めることが可能となる。
【０１７８】
［データ送受信端末装置構成例］
上述の実施例で述べた一連の処理は、ハードウェア、またはソフトウェア、あるいは両者の複合構成によって実行することが可能である。ソフトウェアによる処理を実行する場合は、処理シーケンスを記録したプログラムを、専用のハードウェアに組み込まれたデータ処理装置内のメモリにインストールして実行させるか、あるいは、各種処理が実行可能な汎用コンピュータにプログラムをインストールして実行させることが可能である。一連の処理をソフトウェアによって行う場合には、そのソフトウェアを構成するプログラムが、例えば汎用のコンピュータやマイクロコンピュータ等にインストールされる。
【０１７９】
図１６に、上述の実施例で述べた一連の処理を実行するデータ送信端末装置、データ受信端末装置のシステム構成例を示す。本発明のシステムで送受信されるデータは、符号化データであり、データ送信装置ではエンコード（符号化）処理が実行され、データ受信装置ではデコード（復号）処理が実行される。符号化されたデータはパケットとしてネットワークを介して送受信する。そのため、データ送信側では、パケット生成（パケタイズ処理）を実行し、データ受信側ではパケット展開（デパケタイズ処理）を実行する。
【０１８０】
図１６に示すデータ送受信装置（ｅｘ．ＰＣ）８５０は、エンコード（符号化）処理、デコード（復号）処理を実行するとともにパケット生成、展開処理を実行するコーデック８５１、通信ネットワークとのインタフェースとして機能するネットワークインタフェース８５２、マウス８３７、キーボード８３６等の入力機器との入出力インタフェース８５３、ビデオカメラ８３３、マイク８３４、スピーカ８３５等のＡＶデータ入出力機器からのデータ入出力を行なうＡＶインタフェース８５４、ディスプレイ８３２に対するデータ出力インタフェースとしてのディスプレイ・インタフェース８５５、各データ入出力インタフェース、コーデック８５１、ネットワークインタフェース８５２間のデータ転送制御、その他各種プログラム制御を実行するＣＰＵ８５６、ＣＰＵ８５６により制御実行される各種プログラムの格納、データの格納、ＣＰＵ８５６のワークエリアとして機能するＲＡＭ、ＲＯＭからなるメモリ８５７、データ格納、プログラム格納用の記憶媒体としてのＨＤＤ８５８を有し、それぞれＰＣＩバス８５９に接続され、相互のデータ送受信が可能な構成を持つ。
【０１８１】
コーデック８５１は、図１６に示すように、例えばビデオカメラ８３３からの画像データ、マイク８３４からの音声データを入力し、符号化処理、パケット生成処理（パケタイズ）を実行し、最終的に符号化データをペイロードとしたパケットを生成する。生成されたパケットは、ＰＣＩバス８５９上に出力され、ネットワークインタフェース８５２を介してネットワークに出力され、パケットのヘッダに設定された宛先アドレスに配信される。
【０１８２】
また、ＨＤＤ８５８またはメモリ８５７に格納されたソフトウェアエンコードプログラムに従ってＣＰＵ８５６の制御により、ビデオカメラ８３３からの画像データ、マイク８３４からの音声データを符号化してネットワークインタフェース８５２を介してネットワークに出力する処理も実行する構成としてもよい。
【０１８３】
一方、ネットワークを介して入力するＩＰパケット化されたデータは、ネットワークインタフェース８５２を介して、バス８５６上に出力されて、コーデック８５１に入力される。コーデック８５１では入力データのパケット展開処理（デパケタイズ）を実行し、ペイロードとして格納された符号化データを抽出後、復号処理を実行して、ディスプレイ８３２、スピーカ８３５において再生、出力する。
【０１８４】
上述の実施例における処理対象となる画像等のデータは、カメラ他の入力機器、例えばスキャナ等のデータ入力装置、あるいはフロッピーディスク、ＣＤ−ＲＯＭ(Compact Disc Read Only Memory)，ＭＯ(Magneto optical)ディスク，ＤＶＤ(Digital Versatile Disc)、磁気ディスク、半導体メモリなどのリムーバブル記録媒体から入力可能である。
【０１８５】
また、ＣＰＵ８５６は、ＲＯＭ格納プログラムに限らず、ハードディスクに格納されているプログラム、衛星若しくはネットワークから転送され、受信されてインストールされたプログラム等を、ＲＡＭ(Random Access Memory)等のメモリにロードして実行することも可能である。
【０１８６】
ここで、本明細書において、プログラムは、１つのコンピュータにより処理されるものであっても良いし、複数のコンピュータによって分散処理されるものであっても良い。さらに、プログラムは、遠方のコンピュータに転送されて実行されるものであっても良い。
【０１８７】
以上、特定の実施例を参照しながら、本発明について詳解してきた。しかしながら、本発明の要旨を逸脱しない範囲で当業者が該実施例の修正や代用を成し得ることは自明である。すなわち、例示という形態で本発明を開示してきたのであり、限定的に解釈されるべきではない。本発明の要旨を判断するためには、冒頭に記載した特許請求の範囲の欄を参酌すべきである。
【０１８８】
【発明の効果】
以上、説明してきたように、本発明の構成によれば、ネットワーク監視部によって監視されている現在のネットワーク状況を踏まえてエラー訂正を制御することが可能であり、ＦＥＣによるエラー制御あるいは再送要求処理（ＡＲＱ）に基づくエラー制御等の態様をネットワークにおけるパケット損失、エラー発生状況に応じて動的に変更してパケット転送を実行することが可能となる。監視データとして、パケットエラー率またはＲＦＣ１８８９で規定されているＲＴＣＰのＲＲ（Ｒｅｃｉｅｖｅｒ Ｒｅｐｏｒｔ）でのパケットロス率等を取得し、送信側においてＦＥＣのエラー訂正強度をあげたり、またはＦＥＣを施さずＡＲＱ処理のみの対応とするなどの処理態様の制御が可能となる。
【０１８９】
また、本発明の構成によれば、ネットワーク監視部の監視により得られるネットワーク状況に基づいて、例えば、ＲＴＴが短いならば、ＡＲＱによる再送が可能となるためＡＲＱによるエラー訂正を選択して実行し、ＲＴＴが長く、再送する時間がないほど送信側から受信側に転送時間がかかるというネットワーク状況である場合には、ＡＲＱではなくＦＥＣによるエラー訂正を選択する、といった動的なエラー訂正制御が可能となる。
【０１９０】
また、これらのエラー制御態様は、伝送するデータ階層に応じた優先度に対応して選択的に設定可能となり、符号化データの階層レベルに応じて異なるエラー訂正処理を実行する構成とすることが可能である。例えば基本階層を、強めのＦＥＣ＋ＡＲＱで優先度を上げた設定とし、音声データはＦＥＣのみの対応としたり、オーバーヘッドは極力避けたいのでＦＥＣなしでＡＲＱとして再送回数を例えば１回までといったように再送回数の制限数の設定等、自由な態様でのエラー制御態様を設定することができる。
【図面の簡単な説明】
【図１】本発明のデータ通信システムの構成を示す図である。
【図２】本発明のデータ通信システムの送信側端末、受信側端末の構成を示す図である。
【図３】データの階層化処理例としてのウェーブレット変換について説明する図である。
【図４】本発明のデータ通信システムの送信側端末で実行する優先度付け処理例について説明する図である。
【図５】本発明のデータ通信システムの送信側端末で実行する優先度付け処理に持ついるマップについて説明する図である。
【図６】本発明のデータ通信システムにおいて転送されるＲＴＰパケットフォーマットを示す図である。
【図７】本発明のデータ通信システムにおいて転送されるＩＰパケットヘッダフォーマットを示す図である。
【図８】本発明のデータ通信システムにおけるデータ送信端末の処理フローを示す図である。
【図９】本発明のデータ通信システムにおいて転送されるＮＡＣＫ−ＲＴＣＰパケットフォーマットを示す図である。
【図１０】本発明のデータ通信システムにおいて転送されるＮＡＣＫ−ＲＴＣＰパケットにおけるオプション値の機能について説明する図である。
【図１１】本発明のデータ通信システムにおいて転送されるＡＣＫ−ＲＴＣＰパケットフォーマットを示す図である。
【図１２】本発明のデータ通信システムにおいて転送されるＥＣＨＯ−ＲＴＣＰ、およびＥＣＨＯ−ＲＥＰＬＹ−ＲＴＣＰパケットフォーマットを示す図である。
【図１３】本発明のデータ通信システムにおいて転送されるＥＯＳ−ＲＴＣＰパケットフォーマットを示す図である。
【図１４】本発明のデータ通信システムにおけるデータ受信端末の処理フローを示す図である。
【図１５】本発明のデータ通信システムにおけるデータ受信端末のＥＣＨＯ−ＲＴＣＰ、およびＥＣＨＯ−ＲＥＰＬＹ−ＲＴＣＰパケットを適用したＲＴＴ計測処理フローを示す図である。
【図１６】データ送信端末装置およびデータ受信端末装置のシステム構成例を示す図である。
【符号の説明】
１０１，１１５，１２３ ＣＰＵ
１０２，１１６，１２４ ＲＯＭ
１０３，１１７，１２５ ＲＡＭ
１０４，１１８，１２６ 表示装置
１０５，１１１，１１９ 外部記憶装置
１０６，１１２，１２０ 通信Ｉ／Ｆ
１０７，１１３，１２１ 入力装置
１０８ インタフェース
１０９ カメラ
１１０ マイク
１１４，１２２ 再生装置
１３２，１３３，１３４ 伝送路
１３５ ＩＰネットワーク
２０１ 送信側端末
２０２ 受信側端末
２０３ ビデオカメラ
２０４ エンコーダ
２０５ 階層化部
２０６ 優先度付け処理部
２０７ バッファ
２０８ ＦＥＣ処理部
２０９ ＲＴＰパケット生成部
２１０ ＲＴＰポート
２１１ ビットレート制御部
２１２ 階層エラー訂正優先度制御部
２１３ ＡＲＱ処理部
２１４ ＲＴＣＰパケット生成部
２１５ ネットワーク監視部
２１６ ＲＴＣＰパケット解析部
２１７ ＲＴＣＰポート
２１８ ＴＣＰ，ＲＴＣＰポート
２１９ ＩＰネットワーク
２２０ ＲＴＰポート
２２１ ＲＴＰパケット解析部
２２２ エラー監視部
２２３ バッファ
２２４ デコーダ
２２５ ＲＴＣＰポート
２２６ ＲＴＣＰパケット解析部
２２７ ＲＴＣＰパケット生成部
２２８ ＴＣＰ，ＲＴＣＰポート
２２９ ネットワーク監視部
２３０ エラー訂正制御部
２３１ 階層選択制御部
８０９ ＰＣＩバス
８３２ ディスプレイ
８３３ ビデオカメラ
８３４ マイク
８３５ スピーカ
８３７ マウス
８３８ キーボード
８５０ データ送受信装置
８５１ コーデック
８５２ ネットワークインタフェース
８５３ 入出力インタフェース
８５４ ＡＶインタフェース
８５５ ディスプレイインタフェース
８５６ ＣＰＵ
８５７ メモリ
８５８ ＨＤＤ
Claims (8)
- データ送信装置およびデータ受信装置からなり、画像データのストリーム型データ転送を実行するデータ通信システムであり、
データ送信装置は、
送信画像データの階層符号化処理を実行する階層符号化部と、
前記送信画像データの元画像へのデータ損失による影響およびネットワークの損失率に基づき、前記階層符号化部において階層符号化された階層毎の優先度を設定する優先度付け処理部と、
前記階層符号化部により階層符号化された前記送信画像データを格納した送信画像データパケットを送信するパケット送信処理部と、
ネットワーク状況を監視するネットワーク状況監視部と、
前記優先度付け処理部により前記階層毎に設定された優先度に従って、前記ネットワーク状況監視部の監視するネットワーク状況に基づき、前記送信画像データパケットのエラー制御処理態様を制御するとともに、前記階層符号化部における前記送信画像データの符号化態様を設定してビットレートを制御するデータ送信側制御部と、
データ受信装置から受信する再送要求メッセージパケットに従って再送すべき送信画像データパケットの抽出処理を実行する再送制御部とを有し、
前記優先度付け処理部は、
前記ネットワーク状況監視部により検出されたネットワーク状況に応じて、前記階層毎の優先度を変更する構成であり、
データ受信装置は、
前記データ送信装置から受信する画像データパケットを受信するパケット受信処理部と、
ネットワーク状況を監視するネットワーク状況監視部と、
前記データ送信装置から受信する画像データパケットのエラーまたはパケットロスの検出を実行し、エラー対応処理を実行するエラー訂正制御部と、
前記データ送信装置から受信する画像データパケットのエラーまたはパケットロスの検出に基づいて、前記データ送信装置に対する画像データパケット再送要求としての再送要求メッセージパケットの送信可否を判定する再送要求処理制御部と、
前記ネットワーク状況監視部の監視結果に基づいて処理画像データの選択を実行する階層選択制御部とを有し、
前記階層選択制御部は、
前記ネットワーク状況監視部の解析結果に基づく処理画像データの選択を、前記階層符号化された画像データ毎に前記ネットワーク状況に応じて決定された前記優先度に従って実行する構成である、
ことを特徴とするデータ通信システム。 - 送信画像データのストリーム型データ送信を実行するデータ送信装置であり、
前記送信画像データの階層符号化処理を実行する階層符号化部と、
前記送信画像データの元画像へのデータ損失による影響およびネットワークの損失率に基づき、前記階層符号化部において階層符号化された階層毎の優先度を設定する優先度付け処理部と、
前記階層符号化部により階層符号化された前記送信画像データを格納した送信画像データパケットを送信するパケット送信処理部と、
ネットワーク状況を監視するネットワーク状況監視部と、
前記優先度付け処理部により前記階層毎に設定された優先度に従って、前記ネットワーク状況監視部の監視するネットワーク状況に基づき、前記送信画像データパケットのエラー制御処理態様を制御するとともに、前記階層符号化部における前記送信画像データの符号化態様を設定してビットレートを制御するデータ送信側制御部と、
データ受信装置から受信する再送要求メッセージパケットに従って再送すべき送信画像データパケットの抽出処理を実行する再送制御部とを有し、
前記優先度付け処理部は、
前記ネットワーク状況監視部により検出されたネットワーク状況に応じて、前記階層毎の優先度を変更する構成であることを特徴とするデータ送信装置。 - 前記データ送信側制御部は、前記ネットワーク状況監視部の監視するネットワーク状況に基づいて、エラー制御方式としてのＦＥＣ(Forward Error Correction)の処理態様変更、またはデータ再送要求処理としてのＡＲＱ（Auto Repeat reQuest）処理態様の変更処理を実行する構成であることを特徴とする請求項２に記載のデータ送信装置。
- 前記ネットワーク状況監視部は、パケットロス率、伝送遅延時間、または前記データ受信装置からの再送要求に基づいてネットワーク状況解析を実行し、該解析結果を前記データ送信側制御部に出力し、前記データ送信側制御部は、該解析結果に基づいて、伝送パケットのエラー制御処理態様を制御する構成であることを特徴とする請求項２に記載のデータ送信装置。
- 前記データ送信装置において、
前記データ送信側制御部は、前記ネットワーク状況監視部の監視するネットワーク状況に基づいて、エラー制御方式としてのＦＥＣ(Forward Error Correction)の処理態様変更、またはデータ再送要求処理としてのＡＲＱ（Auto Repeat reQuest）処理態様の変更処理を前記階層符号化部の設定した各階層の符号化送信画像データに対応して実行する構成であることを特徴とする請求項２に記載のデータ送信装置。 - 前記データ送信装置において、
前記データ送信側制御部は、前記ネットワーク状況監視部の監視するネットワーク状況に基づいて、エラー制御方式としてのＦＥＣ(Forward Error Correction)の処理態様変更、またはデータ再送要求処理としてのＡＲＱ（Auto Repeat reQuest）処理態様の変更処理を前記優先度付け処理部の設定した各優先度に対応して実行する構成であることを特徴とする請求項２に記載のデータ送信装置。 - 送信画像データのストリーム型データ送信を実行するデータ送信方法であって、
前記送信画像データの階層符号化処理を実行する階層符号化処理ステップと、
前記送信画像データの元画像へのデータ損失による影響およびネットワークの損失率に基づき、前記階層符号化処理ステップにおいて階層符号化された階層毎の優先度を設定する優先度付け処理ステップと、
前記階層符号化処理ステップにおいて階層符号化された前記送信画像データを格納した送信画像データパケットを送信するパケット送信処理ステップと、
ネットワーク状況を監視するネットワーク状況監視ステップと、
前記優先度付け処理ステップにおいて前記階層毎に設定された優先度に従って、前記ネットワーク状況監視ステップにおいて取得したネットワーク状況に基づき、前記送信画像データパケットのエラー制御処理態様を制御するとともに、前記階層符号化ステップにおける前記送信画像データの符号化態様を設定してビットレートを制御するデータ送信側制御ステップと、
データ受信装置から受信する再送要求メッセージパケットに従って再送すべき送信画像データパケットの抽出処理を実行する再送制御ステップとを有し、
前記優先度付け処理ステップは、
前記ネットワーク状況監視ステップにおいて検出されたネットワーク状況に応じて、前記階層毎の優先度の変更処理を行うことを特徴とするデータ送信方法。 - 送信画像データのストリーム型データ送信を実行するコンピュータ・プログラムであって、
前記送信画像データの階層符号化処理を実行する階層符号化処理ステップと、
前記送信画像データの元画像へのデータ損失による影響およびネットワークの損失率に基づき、前記階層符号化処理ステップにおいて階層符号化された階層毎の優先度を設定する優先度付け処理ステップと、
前記階層符号化処理ステップにおいて階層符号化された前記送信画像データを格納した送信画像データパケットを送信するパケット送信処理ステップと、
ネットワーク状況を監視するネットワーク状況監視ステップと、
前記優先度付け処理ステップにおいて前記階層毎に設定された優先度に従って、前記ネットワーク状況監視ステップにおいて取得したネットワーク状況に基づき、前記送信画像データパケットのエラー制御処理態様を制御するとともに、前記階層符号化ステップにおける前記送信画像データの符号化態様を設定してビットレートを制御するデータ送信側制御ステップと、
データ受信装置から受信する再送要求メッセージパケットに従って再送すべき送信画像データパケットの抽出処理を実行する再送制御ステップとを有し、
前記優先度付け処理ステップは、
前記ネットワーク状況監視ステップにおいて検出されたネットワーク状況に応じて、前記階層毎の優先度の変更処理を行うステップであることを特徴とするコンピュータ・プログラム。
Priority Applications (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2001378808A JP3757857B2 (ja) | 2001-12-12 | 2001-12-12 | データ通信システム、データ送信装置、データ受信装置、および方法、並びにコンピュータ・プログラム |
| US10/315,383 US7502818B2 (en) | 2001-12-12 | 2002-12-10 | Data communications system, data sender, data receiver, data communications method, and computer program |
| KR20020078418A KR100987421B1 (ko) | 2001-12-12 | 2002-12-10 | 데이터통신시스템, 데이터송신장치, 데이터수신장치, 데이터통신방법 및 컴퓨터가 판독가능한 기록 매체 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2001378808A JP3757857B2 (ja) | 2001-12-12 | 2001-12-12 | データ通信システム、データ送信装置、データ受信装置、および方法、並びにコンピュータ・プログラム |
Publications (3)
| Publication Number | Publication Date |
|---|---|
| JP2003179580A JP2003179580A (ja) | 2003-06-27 |
| JP2003179580A5 JP2003179580A5 (ja) | 2005-03-17 |
| JP3757857B2 true JP3757857B2 (ja) | 2006-03-22 |
Family
ID=19186424
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2001378808A Expired - Fee Related JP3757857B2 (ja) | 2001-12-12 | 2001-12-12 | データ通信システム、データ送信装置、データ受信装置、および方法、並びにコンピュータ・プログラム |
Country Status (3)
| Country | Link |
|---|---|
| US (1) | US7502818B2 (ja) |
| JP (1) | JP3757857B2 (ja) |
| KR (1) | KR100987421B1 (ja) |
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2008020547A1 (fr) | 2006-08-17 | 2008-02-21 | Sony Corporation | Dispositif de traitement des communications, procédé de commande des communications, et programme informatique |
| US9191696B2 (en) | 2012-06-15 | 2015-11-17 | Samsung Electronics Co., Ltd. | Reception device and program for reception device |
| US9485054B2 (en) | 2010-06-24 | 2016-11-01 | Sony Corporation | Transmission device, reception device and communication system |
Families Citing this family (174)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6263503B1 (en) | 1999-05-26 | 2001-07-17 | Neal Margulis | Method for effectively implementing a wireless television system |
| US8266657B2 (en) | 2001-03-15 | 2012-09-11 | Sling Media Inc. | Method for effectively implementing a multi-room television system |
| JP4150951B2 (ja) * | 2002-02-19 | 2008-09-17 | ソニー株式会社 | 動画配信システム、動画配信装置および方法、並びにプログラム |
| JP4000905B2 (ja) * | 2002-05-22 | 2007-10-31 | ソニー株式会社 | 情報処理システムおよび方法、情報処理装置および方法、記録媒体、並びにプログラム |
| KR100584170B1 (ko) * | 2002-07-11 | 2006-06-02 | 재단법인서울대학교산학협력재단 | 터보 부호화된 복합 재전송 방식 시스템 및 오류 검출 방법 |
| JP4406816B2 (ja) * | 2002-12-11 | 2010-02-03 | ソニー株式会社 | 受信装置および受信方法、記録媒体、並びにプログラム |
| US8009600B2 (en) * | 2003-01-30 | 2011-08-30 | Avaya Inc. | Dealing with lost acknowledgements when power-saving |
| AU2003227245A1 (en) | 2003-03-27 | 2004-10-25 | Matsushita Electric Industrial Co., Ltd. | Intermittent communication method and intermittent communication device |
| JP4244159B2 (ja) * | 2003-05-16 | 2009-03-25 | 株式会社エヌ・ティ・ティ・ドコモ | 受信装置、通信システムおよびプログラム |
| US7466666B2 (en) * | 2003-06-18 | 2008-12-16 | Telefonaktiebolaget Lm Ericsson (Publ) | Forward ACK/NACK channel for CDMA system |
| JP2005027208A (ja) * | 2003-07-01 | 2005-01-27 | Sony Corp | 送信装置および方法、記録媒体、並びにプログラム |
| KR100526183B1 (ko) | 2003-07-15 | 2005-11-03 | 삼성전자주식회사 | 모바일 애드 혹 네트워크 환경에서 효율적인 데이터송수신을 위한 네트워크 장치 및 데이터 전송 방법 |
| JP2005045409A (ja) * | 2003-07-24 | 2005-02-17 | Pioneer Electronic Corp | 情報処理装置、そのシステム、その方法、そのプログラム、および、そのプログラムを記録した記録媒体 |
| JP2005051714A (ja) * | 2003-07-31 | 2005-02-24 | Mitsubishi Electric Corp | パケット伝送方法および通信装置 |
| JP4250036B2 (ja) * | 2003-08-08 | 2009-04-08 | 富士通株式会社 | メディア伝送方法及びメディア伝送装置 |
| JP2005064568A (ja) * | 2003-08-11 | 2005-03-10 | Tsubasa System Co Ltd | ネットオークションシステム、ネットオークション方法、オークション中継サーバ、オークション参加者端末、オークション中継サーバプログラム、オークション参加者端末プログラム及び記録媒体 |
| WO2005022344A2 (en) | 2003-08-29 | 2005-03-10 | Opentv, Inc. | Targeted content broadcast and reception system |
| FI20031260A (fi) * | 2003-09-04 | 2005-03-05 | Nokia Corp | Median suoratoisto palvelimelta asiakaslaitteelle |
| JP4183586B2 (ja) * | 2003-09-12 | 2008-11-19 | 三洋電機株式会社 | 映像表示装置 |
| JP2005130428A (ja) * | 2003-09-29 | 2005-05-19 | Ntt Communications Kk | 双方向画像通信装置、その処理方法及びクライアント装置並びにプログラム |
| JP4328602B2 (ja) * | 2003-11-20 | 2009-09-09 | 富士通株式会社 | パケットエラー訂正装置及び方法 |
| US20070097987A1 (en) * | 2003-11-24 | 2007-05-03 | Rey Jose L | Feedback provision using general nack report blocks and loss rle report blocks |
| JP4349114B2 (ja) | 2003-12-10 | 2009-10-21 | ソニー株式会社 | 送信装置および方法、受信装置および方法、記録媒体、並びにプログラム |
| JP4452983B2 (ja) * | 2004-01-08 | 2010-04-21 | ソニー株式会社 | 受信装置および方法、プログラム、並びに記録媒体 |
| WO2005074291A1 (ja) * | 2004-01-28 | 2005-08-11 | Nec Corporation | コンテンツの符号化、配信及び受信方法と装置とシステムならびにプログラム |
| ES2708305T3 (es) | 2004-03-09 | 2019-04-09 | Optis Wireless Technology Llc | Procedimiento de acceso aleatorio y dispositivo terminal de radiocomunicación |
| KR101008636B1 (ko) * | 2004-05-04 | 2011-01-17 | 엘지전자 주식회사 | 소프터 핸드오버시에 적용되는 패킷 전송 성공 여부 전송방법 |
| US20050254508A1 (en) * | 2004-05-13 | 2005-11-17 | Nokia Corporation | Cooperation between packetized data bit-rate adaptation and data packet re-transmission |
| US8949395B2 (en) | 2004-06-01 | 2015-02-03 | Inmage Systems, Inc. | Systems and methods of event driven recovery management |
| US7769756B2 (en) | 2004-06-07 | 2010-08-03 | Sling Media, Inc. | Selection and presentation of context-relevant supplemental content and advertising |
| US7917932B2 (en) | 2005-06-07 | 2011-03-29 | Sling Media, Inc. | Personal video recorder functionality for placeshifting systems |
| US7975062B2 (en) | 2004-06-07 | 2011-07-05 | Sling Media, Inc. | Capturing and sharing media content |
| US9998802B2 (en) | 2004-06-07 | 2018-06-12 | Sling Media LLC | Systems and methods for creating variable length clips from a media stream |
| KR20070085203A (ko) | 2004-06-07 | 2007-08-27 | 슬링 미디어 인코퍼레이티드 | 퍼스널 미디어 브로드캐스팅 시스템 |
| KR100937060B1 (ko) * | 2004-06-14 | 2010-01-15 | 닛본 덴끼 가부시끼가이샤 | 쌍방향 통신 방법과 장치, 시스템 및 프로그램을 기억한 기억 매체 |
| US20070177491A1 (en) * | 2004-06-14 | 2007-08-02 | Matsushita Electric Industrial Co., Ltd. | Content use method and content recording device |
| JP4638200B2 (ja) * | 2004-10-07 | 2011-02-23 | ソフトバンクモバイル株式会社 | ストリーミングデータ受信再生端末 |
| JP2006126894A (ja) * | 2004-10-26 | 2006-05-18 | Sony Corp | コンテンツ配信方法、プログラムおよび情報処理装置 |
| CN100461859C (zh) * | 2004-11-12 | 2009-02-11 | 乐金电子（昆山）电脑有限公司 | 移动终端客户端及识别并还原解码器错误运行的方法 |
| WO2006103724A1 (ja) | 2005-03-25 | 2006-10-05 | Fujitsu Limited | パケットの配信帯域制御方法、配信装置及び映像配信システム |
| ITTO20050221A1 (it) * | 2005-04-04 | 2006-10-05 | St Microelectronics Srl | Procedimento e sistema per la correzione degli errori a raffica nelle reti di comunicazione, rete e prodotto informatico relativi |
| JP4645281B2 (ja) | 2005-04-19 | 2011-03-09 | ソニー株式会社 | 情報処理装置および方法、プログラム、並びに記録媒体 |
| JP2006339775A (ja) * | 2005-05-31 | 2006-12-14 | Kddi R & D Laboratories Inc | スケーラブル動画像伝送システム |
| US20060291452A1 (en) * | 2005-06-24 | 2006-12-28 | Motorola, Inc. | Method and apparatus for providing reliable communications over an unreliable communications channel |
| US7573820B2 (en) * | 2005-06-29 | 2009-08-11 | Intel Corporation | Techniques to control data transmission for a wireless system |
| AU2006346226B8 (en) | 2005-07-20 | 2010-03-25 | Vidyo, Inc. | System and method for a conference server architecture for low delay and distributed conferencing applications |
| WO2008082375A2 (en) * | 2005-09-07 | 2008-07-10 | Vidyo, Inc. | System and method for a conference server architecture for low delay and distributed conferencing applications |
| JP2007053745A (ja) * | 2005-07-22 | 2007-03-01 | Sanyo Electric Co Ltd | 受信機及びプログラム |
| US7747921B2 (en) * | 2005-08-05 | 2010-06-29 | Sony Corporation | Systems and methods for transmitting data over lossy networks |
| JP4513725B2 (ja) * | 2005-11-09 | 2010-07-28 | ソニー株式会社 | パケット送信装置、通信システム及びプログラム |
| US7743152B2 (en) * | 2005-10-31 | 2010-06-22 | Qualcomm Incorporated | Method and apparatus for detecting the presence of a terminal in a data session |
| JP4840365B2 (ja) * | 2005-11-28 | 2011-12-21 | 日本電気株式会社 | 通信装置、通信システム、通信方法、および、通信プログラム |
| JP4479650B2 (ja) * | 2005-11-29 | 2010-06-09 | ソニー株式会社 | コミュニケーションシステム、端末装置及びコンピュータプログラム |
| CN102036071B (zh) | 2005-12-08 | 2014-04-02 | 维德约股份有限公司 | 用于视频通信***中的差错弹性和随机接入的***和方法 |
| US20070220403A1 (en) * | 2006-02-27 | 2007-09-20 | Honeywell International Inc. | System and method for dynamic allocation of forward error encoding |
| US8693538B2 (en) * | 2006-03-03 | 2014-04-08 | Vidyo, Inc. | System and method for providing error resilience, random access and rate control in scalable video communications |
| JP2007324700A (ja) * | 2006-05-30 | 2007-12-13 | Mitsubishi Electric Corp | 伝送制御方法 |
| JP2008042288A (ja) * | 2006-08-02 | 2008-02-21 | Fujitsu Ltd | 信号処理装置及び信号処理方法 |
| EP2052484B1 (en) * | 2006-08-17 | 2012-11-21 | Dolby Laboratories Licensing Corporation | Transient analysis of packet queuing loss in a broadcast network |
| JP5016279B2 (ja) * | 2006-09-06 | 2012-09-05 | ソニー株式会社 | データ通信システム、データ送信装置およびデータ送信方法 |
| JP4809174B2 (ja) * | 2006-09-27 | 2011-11-09 | 京セラ株式会社 | 通信装置及びデータ送信方法 |
| KR100851918B1 (ko) * | 2006-10-20 | 2008-08-12 | 광주과학기술원 | 네트워크 적응형 데이터 전송 방법, 이를 위한 데이터 전송시스템, 데이터 송신 장치, 및 데이터 수신 장치 |
| US8488508B2 (en) * | 2006-11-13 | 2013-07-16 | Qualcomm Incorporated | Method and apparatus for providing reliable multicast in a wireless communication system |
| US7937640B2 (en) * | 2006-12-18 | 2011-05-03 | At&T Intellectual Property I, L.P. | Video over IP network transmission system |
| EP2102988A4 (en) * | 2007-01-09 | 2010-08-18 | Vidyo Inc | IMPROVED SYSTEMS AND METHODS OF TROUBLESHOOTING IN VIDEO COMMUNICATION SYSTEMS |
| US20080178243A1 (en) * | 2007-01-19 | 2008-07-24 | Suiwu Dong | Multimedia client/server system with audio synchronization and methods for use therewith |
| US8553757B2 (en) * | 2007-02-14 | 2013-10-08 | Microsoft Corporation | Forward error correction for media transmission |
| US8839325B2 (en) * | 2007-02-14 | 2014-09-16 | At&T Intellectual Property I, L.P. | System and method of managing video content quality |
| KR101177454B1 (ko) | 2007-03-02 | 2012-08-27 | 삼성전자주식회사 | 영상 데이터의 전송에 따른 에러 복원 결정을 위한 서버 및클라이언트와, 영상 데이터의 전송에 따른 에러 복원결정방법 |
| KR101399553B1 (ko) * | 2007-03-09 | 2014-05-27 | 삼성전자주식회사 | 멀티미디어 스트림 전송 장치 및 방법 |
| JP2008311795A (ja) * | 2007-06-12 | 2008-12-25 | Sony Corp | コンテンツ配信システム、配信サーバ、受信端末及びコンピュータプログラム |
| US20080311939A1 (en) * | 2007-06-18 | 2008-12-18 | Nokia Corporation | Acknowledgment aided space domain user scheduling for multi-user mimo |
| US20090034423A1 (en) * | 2007-07-30 | 2009-02-05 | Anthony Terrance Coon | Automated detection of TCP anomalies |
| JP4447028B2 (ja) * | 2007-08-10 | 2010-04-07 | 富士通株式会社 | 通信制御方法、送信装置、およびコンピュータプログラム |
| CN101796761B (zh) * | 2007-08-14 | 2014-07-16 | 诺基亚公司 | 实现部分受限重传的资源调度 |
| KR101420099B1 (ko) * | 2007-09-21 | 2014-07-16 | 삼성전자주식회사 | 방송 컨텐트 재생 방법 및 장치와 방송 컨텐트 제공 방법및 장치 |
| US8155013B2 (en) * | 2007-11-02 | 2012-04-10 | Ntt Docomo, Inc. | Synchronized multi-link transmission in an ARQ-enabled multi-hop wireless network |
| EP2073460A1 (en) * | 2007-12-17 | 2009-06-24 | Alcatel Lucent | Method for forwarding packets, a related packet forwarding system, a related classification device and a related popularity monitoring device |
| US9876599B2 (en) * | 2007-12-17 | 2018-01-23 | Avago Technologies General Ip (Singapore) Pte. Ltd. | System(s), method(s), and apparatus for accurate detection of the end of stream |
| WO2009081449A1 (ja) | 2007-12-20 | 2009-07-02 | Fujitsu Limited | 波長分割多重装置及び光信号の分散補償方法 |
| US8752102B2 (en) * | 2008-01-03 | 2014-06-10 | Microsoft Corporation | Intelligent retransmission of data stream segments |
| US8902996B2 (en) | 2008-02-26 | 2014-12-02 | Richwave Technology Corp. | Adaptive wireless video transmission systems and methods |
| US8265171B2 (en) * | 2008-02-26 | 2012-09-11 | Richwave Technology Corp. | Error resilient video transmission using instantaneous receiver feedback and channel quality adaptive packet retransmission |
| US8588071B2 (en) * | 2008-03-12 | 2013-11-19 | Telefonaktiebolaget L M Ericsson (Publ) | Device and method for adaptation of target rate of video signals |
| JP4670902B2 (ja) * | 2008-05-30 | 2011-04-13 | ソニー株式会社 | 送信装置、送信方法および受信装置 |
| JP5344541B2 (ja) * | 2008-06-03 | 2013-11-20 | キヤノン株式会社 | データ送信装置、送信方法及びプログラム |
| GB0905317D0 (en) * | 2008-07-14 | 2009-05-13 | Musion Ip Ltd | Video processing and telepresence system and method |
| JP2012513689A (ja) * | 2008-07-25 | 2012-06-14 | ノーテル ネットワークス リミテッド | マルチセグメント損失の保護 |
| JP2010056964A (ja) * | 2008-08-28 | 2010-03-11 | Canon Inc | 受信装置及びその制御方法、プログラム、記録媒体 |
| JP2010109530A (ja) * | 2008-10-29 | 2010-05-13 | Sony Corp | 無線通信装置および無線通信方法 |
| KR20100073168A (ko) * | 2008-12-22 | 2010-07-01 | 한국전자통신연구원 | 합성데이터 송/수신 장치 및 방법 |
| US8265022B2 (en) * | 2009-02-10 | 2012-09-11 | Apple Inc. | Apparatus and methods for transmission of emergency call data over wireless networks |
| US8169914B2 (en) | 2009-03-16 | 2012-05-01 | Sling Media Pvt. Ltd. | Method and node for transmitting data over a communication network using negative acknowledgment |
| JP2011009827A (ja) * | 2009-06-23 | 2011-01-13 | Nippon Telegr & Teleph Corp <Ntt> | 通信システム及び通信方法 |
| EP2302845B1 (en) | 2009-09-23 | 2012-06-20 | Google, Inc. | Method and device for determining a jitter buffer level |
| WO2011046056A1 (ja) * | 2009-10-14 | 2011-04-21 | 日本電気株式会社 | パケット通信の伝送制御方法及びパケット通信システム |
| US8923151B2 (en) * | 2009-11-24 | 2014-12-30 | Nec Corporation | Quality control apparatus, moving image transmission system, quality control method, and recording medium |
| JP5549681B2 (ja) * | 2010-01-14 | 2014-07-16 | 住友電気工業株式会社 | 動画像符号化データの表示方法、装置及び通信システム |
| EP2529502A1 (en) | 2010-01-28 | 2012-12-05 | Thomson Licensing | A method and apparatus for retransmission decision making |
| JP2010119133A (ja) * | 2010-01-28 | 2010-05-27 | Sony Corp | パケット送信装置、通信システム及びプログラム |
| US9525569B2 (en) * | 2010-03-03 | 2016-12-20 | Skype | Enhanced circuit-switched calls |
| US20110249729A1 (en) * | 2010-04-07 | 2011-10-13 | Apple Inc. | Error resilient hierarchical long term reference frames |
| US8630412B2 (en) | 2010-08-25 | 2014-01-14 | Motorola Mobility Llc | Transport of partially encrypted media |
| US8477050B1 (en) | 2010-09-16 | 2013-07-02 | Google Inc. | Apparatus and method for encoding using signal fragments for redundant transmission of data |
| KR101443061B1 (ko) * | 2010-11-12 | 2014-09-26 | 한국전자통신연구원 | 패킷 손실에 강인한 애드혹 멀티미디어 그룹통신 단말 및 그 동작방법 |
| WO2012072276A1 (en) * | 2010-11-30 | 2012-06-07 | Telefonaktiebolaget L M Ericsson (Publ) | Transport bit-rate adaptation in a multi-user multi-media conference system |
| JP5677070B2 (ja) * | 2010-12-14 | 2015-02-25 | キヤノン株式会社 | 受信装置及び、受信装置による処理方法 |
| US8751565B1 (en) | 2011-02-08 | 2014-06-10 | Google Inc. | Components for web-based configurable pipeline media processing |
| US9077761B2 (en) * | 2011-02-16 | 2015-07-07 | Dell Products L.P. | System and method for scalable, efficient, and robust system management communications via vendor defined extensions |
| CN106875416B (zh) * | 2011-07-06 | 2020-11-06 | Sk 普兰尼特有限公司 | 用户终端和用户终端的基于多播的内容接收方法 |
| US20130064286A1 (en) * | 2011-09-14 | 2013-03-14 | Mobitv, Inc. | Weighted encoder fragment scheduling |
| US9490850B1 (en) | 2011-11-28 | 2016-11-08 | Google Inc. | Method and apparatus for decoding packetized data |
| FR2984060A1 (fr) * | 2011-12-12 | 2013-06-14 | France Telecom | Procede et dispositif de restitution locale d'une video |
| FR2984059A1 (fr) * | 2011-12-12 | 2013-06-14 | France Telecom | Procede et dispositif de restitution locale d'une video |
| JP5838787B2 (ja) | 2011-12-21 | 2016-01-06 | 富士通株式会社 | 通信装置、および通信方法 |
| IL217307A (en) * | 2012-01-01 | 2015-09-24 | Video Flow Ltd | Continuous error correction (fec) system and method |
| US20130195262A1 (en) * | 2012-01-31 | 2013-08-01 | Cisco Technology, Inc. | Techniques for Handling High Delay Fax Transmissions |
| US9185429B1 (en) | 2012-04-30 | 2015-11-10 | Google Inc. | Video encoding and decoding using un-equal error protection |
| JP2013258657A (ja) * | 2012-06-14 | 2013-12-26 | Nippon Hoso Kyokai <Nhk> | Ｐ２ｐネットワークサービスに用いる端末装置及びプログラム |
| US20130339482A1 (en) * | 2012-06-15 | 2013-12-19 | Samsung Electronics Co., Ltd | Data transmitting system, and transmitting apparatus and receiving apparatus and program in data transmitting system |
| JP2014003359A (ja) * | 2012-06-15 | 2014-01-09 | Samsung Electronics Co Ltd | 映像データをストリーム型データ転送するために用いられるデータ転送システム及びデータ転送システムに用いられる送信装置、受信装置及びプログラム |
| JP5947631B2 (ja) * | 2012-06-15 | 2016-07-06 | 三星電子株式会社Ｓａｍｓｕｎｇ Ｅｌｅｃｔｒｏｎｉｃｓ Ｃｏ．，Ｌｔｄ． | 受信装置及び受信装置用プログラム |
| US10034023B1 (en) | 2012-07-30 | 2018-07-24 | Google Llc | Extended protection of digital video streams |
| US9247033B2 (en) | 2012-12-26 | 2016-01-26 | Google Inc. | Accessing payload portions of client requests from client memory storage hardware using remote direct memory access |
| CN105103500A (zh) * | 2013-03-20 | 2015-11-25 | 富士通株式会社 | 通信方法、通信装置以及通信程序 |
| CN103269260A (zh) * | 2013-06-03 | 2013-08-28 | 腾讯科技（深圳）有限公司 | 数据传输方法、数据接收端、数据发送端和数据传输*** |
| CN103354615B (zh) * | 2013-06-24 | 2015-04-15 | 西安交通大学 | 基于信号强度的直播视频数据传输差错控制方法 |
| KR102092090B1 (ko) * | 2013-08-28 | 2020-03-23 | 엘지전자 주식회사 | 네트워크 장치 및 동작방법 |
| CN104426636A (zh) * | 2013-09-11 | 2015-03-18 | 松下电器产业株式会社 | 通信控制装置及通信控制方法 |
| CN103533387B (zh) * | 2013-10-21 | 2016-08-17 | 腾讯科技（深圳）有限公司 | 一种视频直播控制方法、设备及*** |
| EP2882125B1 (en) * | 2013-12-06 | 2018-12-05 | Alcatel Lucent | Method and device for dynamically configuring either FEC or ARQ as impulse noise protection on a communication line |
| US9336071B2 (en) * | 2014-01-06 | 2016-05-10 | International Business Machines Corporation | Administering incomplete data communications messages in a parallel computer |
| KR102105656B1 (ko) | 2014-01-09 | 2020-04-28 | 한국전자통신연구원 | Mmt 서비스의 패킷 재전송 방법 및 장치, 재전송 요청 방법 및 장치 |
| US9209947B1 (en) * | 2014-01-21 | 2015-12-08 | Saratoga Data Systems, Inc. | Fault-tolerant data transmission system for networks subject to jamming conditions |
| US9871717B2 (en) * | 2014-04-25 | 2018-01-16 | Metaswitch Networks Ltd | Data processing |
| KR102198701B1 (ko) * | 2014-07-03 | 2021-01-05 | 삼성전자주식회사 | 멀티미디어 시스템에서 정보를 송수신하는 방법 및 장치 |
| CN104159166B (zh) * | 2014-08-07 | 2015-08-05 | 西安交通大学 | 基于移动网络丢包状态的直播视频数据传输差错控制方法 |
| JP2016063422A (ja) * | 2014-09-18 | 2016-04-25 | パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカＰａｎａｓｏｎｉｃ Ｉｎｔｅｌｌｅｃｔｕａｌ Ｐｒｏｐｅｒｔｙ Ｃｏｒｐｏｒａｔｉｏｎ ｏｆ Ａｍｅｒｉｃａ | デバイス、デバイス管理装置、中継装置、端末装置、および通信方法 |
| US9558078B2 (en) | 2014-10-28 | 2017-01-31 | Microsoft Technology Licensing, Llc | Point in time database restore from storage snapshots |
| JPWO2016088582A1 (ja) * | 2014-12-04 | 2017-09-21 | ソニー株式会社 | データ処理装置、データ処理方法、及び、プログラム |
| CN106034011A (zh) * | 2015-03-11 | 2016-10-19 | ***通信集团四川有限公司 | 一种组播传输质量保障的控制方法及*** |
| KR101792519B1 (ko) * | 2015-06-04 | 2017-11-02 | 엘지전자 주식회사 | 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법 |
| CN106301697B (zh) * | 2015-06-08 | 2019-12-06 | ***通信集团公司 | 一种数据传输的重传监听控制方法、装置及终端 |
| CN104915523B (zh) * | 2015-07-02 | 2019-03-08 | 国网福建省电力有限公司 | 一种基于时间序列的调控全业务统一建模方法 |
| US9781488B2 (en) * | 2015-07-30 | 2017-10-03 | Adi Rozenberg | Controlled adaptive rate switching system and method for media streaming over IP networks |
| EP3166246B1 (en) * | 2015-11-06 | 2018-06-20 | Fts Computertechnik Gmbh | Method to detect and to handle failures in the communication in a computer network |
| US9755789B2 (en) * | 2015-11-20 | 2017-09-05 | Ringcentral, Inc. | Systems and methods for dynamic packet duplication in a network |
| GB2545449B (en) * | 2015-12-16 | 2019-06-26 | Canon Kk | A method and system for controlling transmission of a data stream |
| CN106982108B (zh) | 2016-01-18 | 2019-05-28 | 华为技术有限公司 | 一种数据传输的方法以及相关设备 |
| EP3420699A1 (en) * | 2016-02-26 | 2019-01-02 | Net Insight Intellectual Property AB | Edge node control |
| CN107181968B (zh) * | 2016-03-11 | 2019-11-19 | 腾讯科技（深圳）有限公司 | 一种视频数据的冗余控制方法和装置 |
| WO2017195366A1 (ja) * | 2016-05-13 | 2017-11-16 | 富士通株式会社 | 通信装置、無線通信システム及び無線通信方法 |
| CN110855402A (zh) * | 2016-09-30 | 2020-02-28 | 瞬已网络科技（上海）有限公司 | 一种网络实时视频传输方法及装置 |
| CN106571893B (zh) * | 2016-11-10 | 2022-05-24 | 深圳市潮流网络技术有限公司 | 一种语音数据的编解码方法 |
| CN109906631B (zh) * | 2017-03-15 | 2021-02-12 | 华为技术有限公司 | 自适应传输方法和装置 |
| US10404632B2 (en) * | 2017-07-12 | 2019-09-03 | T-Mobile Usa, Inc. | Determining when to partition real time text content and display the partitioned content within separate conversation bubbles |
| KR102030460B1 (ko) * | 2017-11-02 | 2019-10-10 | 현대오트론 주식회사 | 실시간 제공 장치 및 그 방법 |
| EP3565186B1 (en) * | 2018-05-02 | 2021-06-30 | TTTech Computertechnik AG | Device and network to reliably communicate in a network |
| US11089341B2 (en) | 2018-05-11 | 2021-08-10 | Prowire Sport Llc | System and method for capturing and distributing a live audio stream of a live event in real-time |
| US11606407B2 (en) * | 2018-07-05 | 2023-03-14 | Prowire Sport Limited | System and method for capturing and distributing live audio streams of a live event |
| CN109195024B (zh) * | 2018-08-24 | 2019-07-26 | 深圳爱克莱特科技股份有限公司 | 一种基于流媒体技术的灯光控制***数据处理*** |
| WO2020179993A1 (en) | 2019-03-07 | 2020-09-10 | Samsung Electronics Co., Ltd. | Apparatus and method for transmitting and receiving data in wireless communication system |
| CN109862038A (zh) * | 2019-03-22 | 2019-06-07 | 江苏睿鸿网络技术有限公司 | 一种流媒体协议中数据延时及丢包的处理方法 |
| JP6754544B1 (ja) * | 2019-04-10 | 2020-09-16 | タック株式会社 | 管理サーバと集約サーバの連繋システム、管理サーバ |
| RU2710282C1 (ru) * | 2019-04-24 | 2019-12-25 | Федеральное государственное казенное военное образовательное учреждение высшего образования Академия Федеральной службы охраны Российской Федерации | Способ передачи данных |
| US11202314B2 (en) * | 2019-06-18 | 2021-12-14 | Sony Group Corporation | Immediate retransmission scheme for real time applications |
| US11464054B2 (en) | 2019-07-24 | 2022-10-04 | Sony Group Corporation | RTA contention collision avoidance |
| CN110730053A (zh) * | 2019-09-09 | 2020-01-24 | 晶晨半导体（深圳）有限公司 | 一种基于ts格式和udp传输方式的网络丢包重传方法 |
| CN111181698B (zh) * | 2019-10-31 | 2022-12-20 | 腾讯云计算（北京）有限责任公司 | 数据处理方法、装置、设备及介质 |
| JP2020123983A (ja) * | 2020-04-30 | 2020-08-13 | 富士通株式会社 | 通信装置、無線通信システム及び無線通信方法 |
| CN114095796A (zh) * | 2020-07-30 | 2022-02-25 | ***通信集团终端有限公司 | 无效重传包减少方法、装置、设备及计算机存储介质 |
| CN114125034B (zh) * | 2020-08-31 | 2023-12-08 | 华为技术有限公司 | 一种网络性能数据订阅方法及装置 |
| CN114499747B (zh) * | 2020-11-09 | 2023-06-20 | 成都鼎桥通信技术有限公司 | 音视频数据的处理方法、装置、电子设备及存储介质 |
| CN113660175A (zh) * | 2021-08-04 | 2021-11-16 | 国网青海省电力公司信息通信公司 | 通信数据的处理方法和装置，以及存储介质和处理器 |
Family Cites Families (17)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5844918A (en) | 1995-11-28 | 1998-12-01 | Sanyo Electric Co., Ltd. | Digital transmission/receiving method, digital communications method, and data receiving apparatus |
| JPH09214474A (ja) * | 1995-11-28 | 1997-08-15 | Sanyo Electric Co Ltd | デジタル通信方法及び受信装置 |
| KR100188681B1 (ko) * | 1996-09-13 | 1999-06-01 | 윤종용 | 데이터 통신 시 확인 신호 수신 불량을 개선한통신방법 |
| US6728775B1 (en) * | 1997-03-17 | 2004-04-27 | Microsoft Corporation | Multiple multicasting of multimedia streams |
| JP3317191B2 (ja) | 1997-06-12 | 2002-08-26 | トヨタ自動車株式会社 | データ伝送方法 |
| US6278716B1 (en) * | 1998-03-23 | 2001-08-21 | University Of Massachusetts | Multicast with proactive forward error correction |
| JP3450729B2 (ja) | 1998-12-21 | 2003-09-29 | 日本電信電話株式会社 | パケット通信装置 |
| US6594798B1 (en) * | 1999-05-21 | 2003-07-15 | Microsoft Corporation | Receiver-driven layered error correction multicast over heterogeneous packet networks |
| JP2001053794A (ja) | 1999-08-09 | 2001-02-23 | Nec Corp | Ｉｐ通信のリアルタイムバックアップ通信方法 |
| JP2001186193A (ja) | 1999-12-24 | 2001-07-06 | Fujitsu Ltd | Ｉｐ通信インタフェース装置、回線交換機及びｉｐ通信ネットワークシステム |
| DE60020672T2 (de) * | 2000-03-02 | 2005-11-10 | Matsushita Electric Industrial Co., Ltd., Kadoma | Verfahren und Vorrichtung zur Wiederholung der Videodatenrahmen mit Prioritätsstufen |
| US7035285B2 (en) * | 2000-04-07 | 2006-04-25 | Broadcom Corporation | Transceiver method and signal therefor embodied in a carrier wave for a frame-based communications network |
| CN1179512C (zh) * | 2000-05-22 | 2004-12-08 | 三星电子株式会社 | 用于混合自动重复请求数据通信***的数据发送设备和方法 |
| US6778553B1 (en) * | 2000-11-10 | 2004-08-17 | Microsoft Corp. | System and method for media streaming |
| US7292530B2 (en) * | 2000-12-29 | 2007-11-06 | Intel Corporation | Method and apparatus to manage packet fragmentation |
| US7454527B2 (en) * | 2001-05-02 | 2008-11-18 | Microsoft Corporation | Architecture and related methods for streaming media content through heterogeneous networks |
| US6745364B2 (en) * | 2001-06-28 | 2004-06-01 | Microsoft Corporation | Negotiated/dynamic error correction for streamed media |
-
2001
- 2001-12-12 JP JP2001378808A patent/JP3757857B2/ja not_active Expired - Fee Related
-
2002
- 2002-12-10 US US10/315,383 patent/US7502818B2/en not_active Expired - Fee Related
- 2002-12-10 KR KR20020078418A patent/KR100987421B1/ko not_active IP Right Cessation
Cited By (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2008020547A1 (fr) | 2006-08-17 | 2008-02-21 | Sony Corporation | Dispositif de traitement des communications, procédé de commande des communications, et programme informatique |
| US7886071B2 (en) | 2006-08-17 | 2011-02-08 | Sony Corporation | Communication processing device, communication control method, and computer program |
| US9485054B2 (en) | 2010-06-24 | 2016-11-01 | Sony Corporation | Transmission device, reception device and communication system |
| US9191696B2 (en) | 2012-06-15 | 2015-11-17 | Samsung Electronics Co., Ltd. | Reception device and program for reception device |
Also Published As
| Publication number | Publication date |
|---|---|
| KR20030051265A (ko) | 2003-06-25 |
| US20030126238A1 (en) | 2003-07-03 |
| KR100987421B1 (ko) | 2010-10-13 |
| JP2003179580A (ja) | 2003-06-27 |
| US7502818B2 (en) | 2009-03-10 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP3757857B2 (ja) | データ通信システム、データ送信装置、データ受信装置、および方法、並びにコンピュータ・プログラム | |
| US8005028B2 (en) | Data communication system, data transmitting device, data transmitting method, data receiving device, and data receiving method | |
| JP3912091B2 (ja) | データ通信システム、データ送信装置、データ受信装置、および方法、並びにコンピュータ・プログラム | |
| KR101242663B1 (ko) | 패킷 송신 장치, 통신 시스템 및 컴퓨터 판독가능한 기록매체 | |
| EP2529528B1 (en) | A method and apparatus for parsing a network abstraction-layer for reliable data communication | |
| EP1328096B1 (en) | Multimedia data packet communication with data type identifiers | |
| JP4116470B2 (ja) | メディア・ストリーミング配信システム | |
| KR101734835B1 (ko) | 재전송 결정을 위한 장치 및 방법 | |
| JP4742669B2 (ja) | 送受信システム、送信装置および送信方法、受信装置および受信方法、並びにプログラム | |
| EP1309122A2 (en) | Apparatus and method for data communication with retransmissions | |
| JP2003152544A (ja) | データ通信システム、データ送信装置、データ受信装置、および方法、並びにコンピュータ・プログラム | |
| JP2010119133A (ja) | パケット送信装置、通信システム及びプログラム | |
| JP2004153610A (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: 20050420 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20050422 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20050621 |
|
| A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20050810 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20051011 |
|
| A911 | Transfer to examiner for re-examination before appeal (zenchi) |
Free format text: JAPANESE INTERMEDIATE CODE: A911 Effective date: 20051024 |
|
| 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: 20051206 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20051219 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100113 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100113 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110113 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120113 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130113 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 |
|
| LAPS | Cancellation because of no payment of annual fees |