JP3757857B2 - データ通信システム、データ送信装置、データ受信装置、および方法、並びにコンピュータ・プログラム - Google Patents

データ通信システム、データ送信装置、データ受信装置、および方法、並びにコンピュータ・プログラム Download PDF

Info

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
transmission
processing
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
Application number
JP2001378808A
Other languages
English (en)
Other versions
JP2003179580A5 (ja
JP2003179580A (ja
Inventor
英三郎 板倉
道成 河野
Original Assignee
ソニー株式会社
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by ソニー株式会社 filed Critical ソニー株式会社
Priority to JP2001378808A priority Critical patent/JP3757857B2/ja
Publication of JP2003179580A publication Critical patent/JP2003179580A/ja
Publication of JP2003179580A5 publication Critical patent/JP2003179580A5/ja
Application granted granted Critical
Publication of JP3757857B2 publication Critical patent/JP3757857B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements or protocols for real-time communications
    • H04L65/60Media handling, encoding, streaming or conversion
    • H04L65/608Streaming protocols, e.g. RTP or RTCP
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • H04L1/0001Systems modifying transmission characteristics according to link quality, e.g. power backoff
    • H04L1/0009Systems modifying transmission characteristics according to link quality, e.g. power backoff by adapting the channel coding
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Application independent communication protocol aspects or techniques in packet data networks
    • H04L69/16Transmission control protocol/internet protocol [TCP/IP] or user datagram protocol [UDP]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Application independent communication protocol aspects or techniques in packet data networks
    • H04L69/16Transmission control protocol/internet protocol [TCP/IP] or user datagram protocol [UDP]
    • H04L69/161Implementation details of TCP/IP or UDP/IP stack architecture; Specification of modified or new header fields
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/234Processing of video elementary streams, e.g. splicing of video streams, manipulating MPEG-4 scene graphs
    • H04N21/2343Processing of video elementary streams, e.g. splicing of video streams, manipulating MPEG-4 scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements
    • H04N21/234327Processing of video elementary streams, e.g. splicing of video streams, manipulating MPEG-4 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
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43Processing 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/442Monitoring 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/44209Monitoring of downstream path of the transmission network originating from a server, e.g. bandwidth variations of a wireless network
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/45Management 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/462Content 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/4621Controlling 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
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60Network 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/63Control 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/643Communication protocols
    • H04N21/6437Real-time Transport Protocol [RTP]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • H04L1/004Arrangements for detecting or preventing errors in the information received by using forward error control
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • H04L1/12Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16Arrangements 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/18Automatic repetition systems, e.g. van Duuren system ; ARQ protocols

Description

【0001】
【発明の属する技術分野】
本発明は、データ通信システム、データ送信装置、データ受信装置、および方法、並びにコンピュータ・プログラムに関する。さらに詳細には、ストリーミングデータ転送におけるエラー耐性を高めたパケット送信構成を持つデータ通信システム、データ送信装置、データ受信装置、および方法、並びにコンピュータ・プログラムに関する。
【0002】
【従来の技術】
昨今、インターネット通信など、様々な通信媒体を介した画像、音声データ等のデータ転送が盛んに行われている。特に、近年においては、インターネット上のデータ転送において、従来から利用されているダウンロード型伝送方式に加えて、ストリーム型伝送方式によるサービスが増加してきている。ダウンロード型伝送方式においては、映像ファイルや音声ファイルといったマルチメディアデータを伝送する場合、配信サーバからデータファイルを一旦受信側端末の記憶媒体にダウンロードして、その後、記憶媒体から再生することになる。よって、この方式ではファイルを完全に転送が終わるまでは再生できず、長時間再生やリアルタイム再生などには不向きである。
【0003】
一方、後者のストリーム型伝送方式では、送信側から受信端末にデータ転送が行われている間に、並列して受信データの再生処理を実行するものであり、インターネット電話・遠隔テレビ会議・ビデオオンデマンドといったインターネットサービスに利用されている。
【0004】
ストリーム型伝送方式は、例えば画像データのMPEG圧縮処理により生成されるMPEGストリームをIP(Internet Protocol)パケットに格納してインターネット上を転送させて、PCやPDA、携帯電話等の各通信端末において受信するシステム等において使用され、開発が進んでいる。このような技術は、ビデオオンデマンドやライブ映像のストリーミング配信、あるいはビデオ会議、テレビ電話などのリアルタイム通信において有効となる。
【0005】
このようなストリーム型伝送方式に適したインターネット技術に、IETF RFC1889で規定されているプロトコル:RTP(Realtime Transport Protocol)がある。RTPに従ったデータ転送では、時間情報としてパケットにタイムスタンプを付加し、タイムスタンプの参照により送信側と受信側の時間的関係の把握を行ない、データ受信側において、パケット転送の遅延ゆらぎ(ジッター)などの影響を受けずに同期をとった再生を可能としている。
【0006】
ただし、RTPは実時間のデータ転送を保証しているものではない。パケット配送の優先度や設定、管理などはRTPが提供するトランスポートサービスの範疇ではないため、RTPパケットは、他のパケットと同様、ネットワーク上での配送遅延やパケット損失がおきる可能性がある。しかし、このような事態が起こっても、受信側は期待する時間内に到着したパケットだけを利用してデータを再生することが可能である。これは、映像や音声データが多少のデータ欠損があったとしても、データ品質を落とした再生、あるいはデータ補正処理による再生が可能となるからである。
【0007】
なお、再生に間に合わず遅延配送されたパケットやエラーの発生したパケットは、受信側でそのまま破棄される。つまり、パケット損失やエラーが発生した場合は、高品質なデータ配信処理を行なっている場合でも、受信側で品質を保持した再生が実行されないという問題点がある。特に、有線区間で10-5、無線区間で10-3以上のエラーがあるといわれている中では、配信するメディアの品質保持を考慮すると、RTPをそのまま利用したデータ転送には問題がある。
【0008】
このようなRTPに従ったデータ転送における問題点を解決する1つの案としては、データ転送に信頼性が高いデータ転送プロトコルであるTCPに従ってパケットの再送要求および再送パケット送信を行わせる方法が考えられる。しかし、TCPはエラーには強いが、スループットが低く、遅延が大きいため、再送しても再生時間に間に合わない可能性があり、リアルタイム通信の実現を困難とするという問題がある。
【0009】
さらに、パケットエラー等に対応するエラー訂正手法として、例えばFEC(Forward Error Correction)という手段が考えられている。これは誤り訂正を行うためのFECデータを冗長データとして送信して、エラーが発生した場合には、データ受信側において、このFECデータをもとにエラーの修復を実行しようとするものである。ランダム誤り訂正符号として、BCH符号と畳み込み符号が用いられる。また、バースト誤り訂正符号では、リードソロモン符号(RS符号)が一般的によく利用されている。前述のARQに比べると再送にかかる遅延がない分、遅延時間を低く抑えられるが、冗長データを付加するためにパケット損失が非常に少ない伝送路においてはスループットは低下する。
【0010】
FECは、端末側での誤り検出と符号処理が複雑なため受信端末側の処理能力に依存してしまう。このように、ネットワーク状況と受信端末に合わせた最適な付加FECデータを一意に決定して送信するのは難しく、処理時間のオーバーヘッドが常につきまとうなど問題が存在する。
【0011】
【発明が解決しようとする課題】
本発明は、上述の問題点に鑑みてなされたものであり、ビデオオンデマンドや、遠隔テレビ会議のような、リアルタイム再生が望まれるデータ転送処理を効率的に実行可能とかるとともに、パケット損失等のエラー発生時にも品質の低下を抑えて高品質なデータ再生を実現するデータ通信システム、データ送信装置、データ受信装置、および方法、並びにコンピュータ・プログラムを提供することを目的とする。
【0012】
【課題を解決するための手段】
本発明の第1の側面は、
データ送信装置およびデータ受信装置からなり、画像データのストリーム型データ転送を実行するデータ通信システムであり、
データ送信装置は、
送信画像データの階層符号化処理を実行する階層符号化部と、
前記送信画像データの元画像へのデータ損失による影響およびネットワークの損失率に基づき、前記階層符号化部において階層符号化された階層毎の優先度を設定する優先度付け処理部と、
前記階層符号化部により階層符号化された前記送信画像データを格納した送信画像データパケットを送信するパケット送信処理部と、
ネットワーク状況を監視するネットワーク状況監視部と、
前記優先度付け処理部により前記階層毎に設定された優先度に従って、前記ネットワーク状況監視部の監視するネットワーク状況に基づき、前記送信画像データパケットのエラー制御処理態様を制御するとともに、前記階層符号化部における前記送信画像データの符号化態様を設定してビットレートを制御するデータ送信側制御部と、
データ受信装置から受信する再送要求メッセージパケットに従って再送すべき送信画像データパケットの抽出処理を実行する再送制御部とを有し、
前記優先度付け処理部は、
前記ネットワーク状況監視部により検出されたネットワーク状況に応じて、前記階層毎の優先度を変更する構成であり、
データ受信装置は、
前記データ送信装置から受信する画像データパケットを受信するパケット受信処理部と、
ネットワーク状況を監視するネットワーク状況監視部と、
前記データ送信装置から受信する画像データパケットのエラーまたはパケットロスの検出を実行し、エラー対応処理を実行するエラー訂正制御部と、
前記データ送信装置から受信する画像データパケットのエラーまたはパケットロスの検出に基づいて、前記データ送信装置に対する画像データパケット再送要求としての再送要求メッセージパケットの送信可否を判定する再送要求処理制御部と、
前記ネットワーク状況監視部の監視結果に基づいて処理画像データの選択を実行する階層選択制御部とを有し、
前記階層選択制御部は、
前記ネットワーク状況監視部の解析結果に基づく処理画像データの選択を、前記階層符号化された画像データ毎に前記ネットワーク状況に応じて決定された前記優先度に従って実行する構成である、
ことを特徴とするデータ通信システムにある。
【0022】
本発明の第2の側面は、
送信画像データのストリーム型データ送信を実行するデータ送信装置であり、
前記送信画像データの階層符号化処理を実行する階層符号化部と、
前記送信画像データの元画像へのデータ損失による影響およびネットワークの損失率に基づき、前記階層符号化部において階層符号化された階層毎の優先度を設定する優先度付け処理部と、
前記階層符号化部により階層符号化された前記送信画像データを格納した送信画像データパケットを送信するパケット送信処理部と、
ネットワーク状況を監視するネットワーク状況監視部と、
前記優先度付け処理部により前記階層毎に設定された優先度に従って、前記ネットワーク状況監視部の監視するネットワーク状況に基づき、前記送信画像データパケットのエラー制御処理態様を制御するとともに、前記階層符号化部における前記送信画像データの符号化態様を設定してビットレートを制御するデータ送信側制御部と、
データ受信装置から受信する再送要求メッセージパケットに従って再送すべき送信画像データパケットの抽出処理を実行する再送制御部とを有し、
前記優先度付け処理部は、
前記ネットワーク状況監視部により検出されたネットワーク状況に応じて、前記階層毎の優先度を変更する構成であることを特徴とするデータ送信装置にある。
【0023】
さらに、本発明のデータ送信装置の一実施態様において、前記データ送信側制御部は、前記ネットワーク状況監視部の監視するネットワーク状況に基づいて、エラー制御方式としてのFEC(Forward Error Correction)の処理態様変更、またはデータ再送要求処理としてのARQ(Auto Repeat reQuest)処理態様の変更処理を実行する構成であることを特徴とする。
【0024】
さらに、本発明のデータ送信装置の一実施態様において、前記ネットワーク状況監視部は、パケットロス率、伝送遅延時間、または前記データ受信装置からの再送要求に基づいてネットワーク状況解析を実行し、該解析結果を前記データ送信側制御部に出力し、前記データ送信側制御部は、該解析結果に基づいて、伝送パケットのエラー制御処理態様を制御する構成であることを特徴とする。
【0026】
さらに、本発明のデータ送信装置の一実施態様において、前記データ送信装置において、前記データ送信側制御部は、前記ネットワーク状況監視部の監視するネットワーク状況に基づいて、エラー制御方式としてのFEC(Forward Error Correction)の処理態様変更、またはデータ再送要求処理としてのARQ(Auto Repeat reQuest)処理態様の変更処理を前記階層符号化部の設定した各階層の符号化送信画像データに対応して実行する構成であることを特徴とする。
【0027】
さらに、本発明のデータ送信装置の一実施態様において、前記データ送信装置において、前記データ送信側制御部は、前記ネットワーク状況監視部の監視するネットワーク状況に基づいて、エラー制御方式としてのFEC(Forward Error Correction)の処理態様変更、またはデータ再送要求処理としてのARQ(Auto Repeat reQuest)処理態様の変更処理を前記優先度付け処理部の設定した各優先度に対応して実行する構成であることを特徴とする。
【0032】
本発明の第の側面は、
送信画像データのストリーム型データ送信を実行するデータ送信方法であって、
前記送信画像データの階層符号化処理を実行する階層符号化処理ステップと、
前記送信画像データの元画像へのデータ損失による影響およびネットワークの損失率に基づき、前記階層符号化処理ステップにおいて階層符号化された階層毎の優先度を設定する優先度付け処理ステップと、
前記階層符号化処理ステップにおいて階層符号化された前記送信画像データを格納した送信画像データパケットを送信するパケット送信処理ステップと、
ネットワーク状況を監視するネットワーク状況監視ステップと、
前記優先度付け処理ステップにおいて前記階層毎に設定された優先度に従って、前記ネットワーク状況監視ステップにおいて取得したネットワーク状況に基づき、前記送信画像データパケットのエラー制御処理態様を制御するとともに、前記階層符号化ステップにおける前記送信画像データの符号化態様を設定してビットレートを制御するデータ送信側制御ステップと、
データ受信装置から受信する再送要求メッセージパケットに従って再送すべき送信画像データパケットの抽出処理を実行する再送制御ステップとを有し、
前記優先度付け処理ステップは、
前記ネットワーク状況監視ステップにおいて検出されたネットワーク状況に応じて、前記階層毎の優先度の変更処理を行うことを特徴とするデータ送信方法にある。
【0042】
本発明の第の側面は、
送信画像データのストリーム型データ送信を実行するコンピュータ・プログラムであって、
前記送信画像データの階層符号化処理を実行する階層符号化処理ステップと、
前記送信画像データの元画像へのデータ損失による影響およびネットワークの損失率に基づき、前記階層符号化処理ステップにおいて階層符号化された階層毎の優先度を設定する優先度付け処理ステップと、
前記階層符号化処理ステップにおいて階層符号化された前記送信画像データを格納した送信画像データパケットを送信するパケット送信処理ステップと、
ネットワーク状況を監視するネットワーク状況監視ステップと、
前記優先度付け処理ステップにおいて前記階層毎に設定された優先度に従って、前記ネットワーク状況監視ステップにおいて取得したネットワーク状況に基づき、前記送信画像データパケットのエラー制御処理態様を制御するとともに、前記階層符号化ステップにおける前記送信画像データの符号化態様を設定してビットレートを制御するデータ送信側制御ステップと、
データ受信装置から受信する再送要求メッセージパケットに従って再送すべき送信画像データパケットの抽出処理を実行する再送制御ステップとを有し、
前記優先度付け処理ステップは、
前記ネットワーク状況監視ステップにおいて検出されたネットワーク状況に応じて、前記階層毎の優先度の変更処理を行うステップであることを特徴とするコンピュータ・プログラムにある。
【0044】
なお、本発明のコンピュータ・プログラムは、例えば、様々なプログラム・コードを実行可能な汎用コンピュータ・システムに対して、コンピュータ可読な形式で提供する記憶媒体、通信媒体、例えば、CDやFD、MOなどの記録媒体、あるいは、ネットワークなどの通信媒体によって提供可能なコンピュータ・プログラムである。このようなプログラムをコンピュータ可読な形式で提供することにより、コンピュータ・システム上でプログラムに応じた処理が実現される。
【0045】
本発明のさらに他の目的、特徴や利点は、後述する本発明の実施例や添付する図面に基づくより詳細な説明によって明らかになるであろう。なお、本明細書においてシステムとは、複数の装置の論理的集合構成であり、各構成の装置が同一筐体内にあるものには限らない。
【0046】
【発明の実施の形態】
[システム及びデータ送受信概要]
本発明のデータ通信システムのシステム構成例を図1に示す。本発明のデータ通信システムは、ビデオオンデマンドや、遠隔テレビ会議のような、リアルタイム再生が望まれるデータ転送処理をデータ送信処理を実行する送信側端末100と、データ受信処理を実行する受信側端末130,131との間でIPネットワーク135を介して実行するシステムである。
【0047】
図1には、1つの送信側端末100と2つの受信側端末130,131が示してあるが、この他にも任意数の端末がIPネットワーク135を介してデータ送受信が実行される。また、データ送信側端末、受信側端末は、データの送信のみ、受信のみを実行するばかりでなく、データ送受信が可能な端末として構成可能である。
【0048】
データ送信側端末100は、カメラ109やマイク110より、画像、音声等のメディアデータをインターフェース(I/F)108などを通して記憶装置105、RAM103に取り込む。撮り込まれたデータは、通信インターフェース106を介して、IPネットワーク135に伝送される。IPネットワーク135を介して設定される伝送路132,133,134は、有線路でも無線路でも構わない。これらの伝送路132,133,134を介して受信側端末130は、通信インターフェース112を通してデータを受信しRAM117にバッファリングする。
【0049】
受信側端末130では、CPU115による処理を経て、受信データを表示装置118において画像表示し、また再生装置114において音声の再生を実行する。受信端末131も受信端末130と同様に送信側端末100からのデータを同時に受信し、同様の画像再生、音声再生を実行する。
【0050】
図1の構成において、送信側端末100、受信側端末130,131のそれぞれは例えば通信処理機能を持つPC、あるいは携帯端末等によって構成される。各端末の詳細構成については、後段で説明するが、図1に示す送信側端末100および受信側端末130,131の各処理部の機能の概略をまとめて説明する。
【0051】
CPU(Central processing Unit)101,115,123は、各種実行プログラム、OS(Operating System)を実行するプロセッサであり、後段で説明する。送受信データの再送制御、エラー訂正処理等のプログラムを実行する。ROM(Read-Only-Memory)102,116,124は、CPUが実行するプログラム、あるいは演算パラメータとしての固定データを格納する。RAM(Random Access Memory)102,117,125は、CPUの処理において実行されるプログラム、およびプログラム処理において適宜変化するパラメータの格納エリア、ワーク領域として使用される。
【0052】
表示装置104,118,126は、例えばCRT、液晶ディスプレイ等であり、各種情報をテキストまたはイメージ等により表示する。外部記憶装置105,111,119はハードディスク、DVD等の記憶媒体を持つ記憶装置であり、各種データ、プログラムを格納する。
【0053】
通信I/F106,112,120は送信側端末と受信側端末間の通信処理を実行し、CPUの制御の下に、各記憶部から供給されたデータ、あるいはCPUによって処理されたデータを送信したり、他端末からのデータを受信する処理を実行する。
【0054】
入力装置107,113,121は、例えばキーボード、ポインティングデバイスを含む入力部であり、キーボードやマウス等を介してユーザによるデータまたはコマンドの入力が可能である。受信側端末130,131に示す再生装置114,122は前述したように音声再生を実行する例えばスピーカ等の装置である。
【0055】
次に、図2以下を参照して、本発明のデータ通信システムにおけるデータ送受信処理の詳細を説明する。
【0056】
図2のデータ通信システムにおいて、送信側端末201は受信側端末202に対して画像、音声等のデータをパケット化して送信する。転送データは、例えばビデオカメラ203によって取得された画像、音声データである。なお、転送データは、CD,DVD等の記憶媒体から入力されるデータ、あるいは外部ネットワーク、衛星等から受信するデータ等であってもよい。なお、以下の説明では、1つの例として送信側端末201から受信側端末202へビデオカメラ203によって取得された動画像データを転送する構成を中心として説明する。
【0057】
ビデオカメラ203によって取得された動画像データは、送信側端末201の符号化装置(エンコーダ)204により符号化、例えばMPEG圧縮処理等による符号化がなされ、階層化部205、優先度付け処理部206において、送信するデータ、および端末側の再生能力などに応じてデータを階層化し、優先度付け処理を実行する。
【0058】
階層化部205は、符号化がなされたデータの階層化処理を実行する。基本階層(ベースレイヤー)は画像の基本となる階層であり、受信側端末202は、基本階層のみ受信した場合であっても最低限の品質を確保できる。さらに、上位階層のデータを受信することでより高品質なデータ例えば画像再生が可能となる。階層化部205は、このように符号化データに応じた階層区分処理を行なう。
【0059】
ビデオオンデマンドやライブ映像のストリーミング配信、あるいはビデオ会議、テレビ電話などのリアルタイム通信においては、異なる能力を持つ端末を受信端末として、データ送受信が行われることを想定する必要がある。例えば、1つの情報送信ソースからの送信データは、携帯電話などのような解像度の低いディスプレイと処理能力の低いCPUを有する受信端末によって受信されディスプレイに表示する処理が実行され、かつ、デスクトップパソコンのように高解像度のモニターと高い処理能力のCPUを有する受信端末によって受信されて表示処理が実行される。このように、処理能力の異なる様々な受信端末を相手としたデータ送信が行なわれる。このように様々な受信端末において処理能力等に応じた受信処理、表示処理を実行させる手法として、送受信するデータの符号化を階層化させて実行するものであり、階層化部205は、このように符号化データに応じた階層化処理を行なう。
【0060】
階層符号化によるデータ配信により、例えば、高解像度のディスプレイを有する受信端末においてのみ処理する符号化データと、高解像度のディスプレイを有する受信端末および低解像度のディスプレイを有する受信端末の双方において共通に処理する符号化データとを、それぞれ区別可能な態様でパケット化して配信可能となり、受信側において、データを選別して処理できる。
【0061】
階層符号化が可能な圧縮・伸張方式としては、例えばMPEG4とJPEG2000によるビデオストリームをあげることができる。MPEG4ではFineGranuality Scalability技術を規格に取り込みプロファイル化する予定であり、この階層符号化技術によりスケーラブルに低いビットレートから高いビットレートまで配信することが可能と言われている。また、ウェーブレット(Wavelet)変換をベースとするJPEG2000は、ウェーブレット(Wavelet)変換の特徴を生かし、空間解像度をベースにパケット化することや、あるいは画質をベースに階層的にパケット化することが可能である。またJPEG2000は静止画だけでなく動画を扱えるMotion JPEG2000(Part 3)規格により、階層化したデータをファイルフォーマットで保存することが可能である。上述の階層符号化処理の適用により、1つのファイルデータから異なる能力の端末へ同時にデータ配信を実行することが可能となる。
【0062】
また、階層符号化の例としてDCT(Discrete Cosine Transform)ベースの技術を用いた構成も可能である。これは配信情報となる例えば画像データをDCT処理し、DCT処理により高域と低域とを区別した階層化を実現し、高域と低域との階層で区分したパケットを生成してデータ配信を実行する方法である。エンコーダ204では、上述のDCT処理、あるいは、ウェーブレット変換のような階層化の可能な符号化方式を実行する。
【0063】
エンコーダ204は上述の階層符号化をあらかじめ設定されたプログレッシブ順序でのプログレッシブ符号化処理を実行する。すなわち上記したフェーブレット変換等に対応する空間解像度によるプログレッシブ、あるいはSNR(Signal to Noise Ratio)、すなわち画質毎に設定した階層に対応するプログレッシブ、あるいはカラー成分(RGBやYCbCr)毎の階層に対応するプログレッシブ等、様々なデータ階層に応じたプログレッシブ符号化処理を実行する。
【0064】
プログレッシプ符号化とは、インターネットの画像配信等において多用される符号化処理であり、データ受信端末側で粗い画像データを先に出力し、順次、細かい画像を出力して表示することを可能とするものである。例えば、空間解像度によるプログレッシブ符号化の場合は、粗い画像に対応する低周波画像データの符号化データから精細な画像に対応する高周波画像データの符号化データを生成する。データの復号、表示を実行する端末では、低周波画像データの符号化データの復号、表示処理をまず実行することで、短時間でディスプレイに粗い概略画像を表示することが可能となり、その後、高周波領域の符号化データを復号し、表示することで、徐々に精細な画像を表示することが可能となる。SNR(Signal to Noise Ratio)、すなわち画質によるプログレッシブの場合は、低SNR(低画質)の符号化データから高SNR(高画質)を区別して符号化する。カラー成分(RGBやYCbCr)によるプログレッシブの場合は、カラー成分(RGBやYCbCr)毎の符号化を実行する。
【0065】
一例としてウェーブレット変換による符号化データの階層化処理について説明する。ウェーブレット変換は、入力画像信号を、ローパスフィルタ、ハイパスフィルタによって帯域分割処理を複数段に渡って実行し、低域成分を階層的に帯域分割した帯域成分を順次生成する処理として実行される。図3は、レベル3まで2次元画像を帯域分割した結果得られる帯域成分を図示したものである。この図3に示す例では、先ずレベル1の帯域分割(水平・垂直方向)により4つの成分LL、LH、HL、HHに分かれる。ここでLLは水平・垂直成分が共にLであること、LHは水平成分がHで垂直成分がLであることを意味している。次に、LL成分は再度帯域分割されて、LLLL、LLHL、LLLH、LLHHが生成される。さらに、LLLL成分は再度帯域分割されて、LLLLLL、LLLLHL、LLLLLH、LLLLHHが生成される。
【0066】
図2に示すエンコーダ204は、例えば上述したウェーブレット変換処理等の階層符号化を実行し、階層化部205において、各階層毎に分類され、さらに、優先度付け処理部206において各階層毎の優先度付け処理が行なわれる。なお、エンコーダ204は、ビットレート制御部211からの情報に基づいて符号化態様の変更、例えば符号化階層数等の変更を行なう。ビットレート制御部211は、ネットワーク監視部215が監視するネットワーク状況を受信する階層エラー訂正優先度制御部212の設定した情報に基づいて、エンコーダ204の符号化態様の設定を行なう。例えばネットワークの混雑等によるパケットの遅延状況等をネットワーク監視部215が検出し、検出情報に基づいてエンコーダ204は、符号化階層数等の変更等、符号化態様を動的に変更する。
【0067】
優先度付け処理部206においては、階層符号化データの階層毎の重要度に応じた優先度を付与する。上述したウェーブレット変換データの空間解像度による階層レベル分けを実行した場合において、もっとも重要度の高い階層レベルは、ディスプレイに粗い概略画像を表示するために必要となるデータであり、これは、図3に示す低域(3LL)データを含む符号化領域、すなわち1/8のサイズのLLLLLL、LLLLHL、LLLLLH、LLLLHHデータ領域301に相当する。次の重要度の階層レベルは、次の低域の1/4のサイズのデータ領域となり、LLLL、LLHL、LLLH、LLHHデータ領域302で構成され、次の重要度の階層レベルは、次の低域の1/2のサイズのデータ領域となり、LL、LH、HL、HHデータ領域303で構成される。
【0068】
優先度付け処理部206も、ネットワーク監視部215が監視するネットワーク状況を受信する階層エラー訂正優先度制御部212の設定した情報に基づいて、設定する優先度を動的に変更可能な構成を持つ。例えばネットワークの混雑等によるパケットの遅延状況等をネットワーク監視部215が検出し、この検出情報に基づいて優先度付け処理部206は、各符号化データに対して設定する優先度を動的に変更する。
【0069】
優先度の設定は、例えば図4に示すような設定として実行される。エンコーダ204によって階層符号化されたデータを、例えば5階層とした場合、階層0〜階層4までの階層別の符号化データに区分し、これらをそれぞれパケット65〜69の5つのパケットにペイロードとして格納する例を示している。
【0070】
階層0の符号化データが最も重要度の高いデータであり、この階層0の符号化データをペイロードとするIPパケット65のRTPヘッダ(RTPH)には優先度[0]を設定し、また、IPヘッダ(IPH)には、優先度[0]を設定する。階層1の符号化データは、次に重要度の高いデータであり、この階層1の符号化データをペイロードとするIPパケット66のRTPヘッダ(RTPH)には優先度[1]を設定し、また、IPヘッダ(IPH)には、優先度[1]を設定する。以下、階層2の符号化データをペイロードとするIPパケット67のRTPヘッダには優先度[2]、IPヘッダには優先度[1]、階層3の符号化データをペイロードとするIPパケット68のRTPヘッダには優先度[3]、IPヘッダには優先度[2]、階層4の符号化データをペイロードとするIPパケット69のRTPヘッダには優先度[4]、IPヘッダには優先度[2]を設定する。
【0071】
このIPヘッダ、RTPヘッダに対する優先度設定処理は、優先度付け処理部206内の記憶手段に記憶した優先度設定マップに従って実行される。図5に優先度設定マップの構成例を示す。優先度設定マップは、エンコーダ204において符号化された階層毎にRTPヘッダ、IPヘッダに設定する優先度を対応付けたマップである。
【0072】
図5に示す優先度設定マップの例は、ウェーブレット変換において設定された階層のレベル:0〜4をRTPパケットの拡張ヘッダ(RTP共通ヘッダに続くRTPペイロードヘッダ)に設定する優先度:0〜4としてそのまま適用している。また、IPヘッダに設定する優先度は、0〜2の3種類としIPネットワークから見た場合の優先度は3レベルとなる。このように階層レベルからRTPのレベルへの優先度の対応付けとRTPレベルからIPレベルへの優先度のマッピングを行うことにより、例えば次のような制御が可能となる。
【0073】
RTPレベルにおいてはパケットのシーケンス番号を管理しており、インターネットでロスがあった場合にロスしたパケットを検出可能である。パケットロスを検出することにより、受信側は例えばデコーダにパケットロス位置を通知することによって、エラー制御方法を変更することができる。エラー制御方式としては、例えばFEC(Forward Error Correction)を使用する。FECの手法としては、ATMのAAL1におけるパケットロスに対してFECを行う手法、ITU-T Recommendation I.363.1, B-ISDN ATM Adaptation Layer (AAL), types 1 and 2 specificationに記載のマトリックスを作って損失パケットのリードソロモン復号する手法に準じた方法等が適用可能である。
【0074】
このような処理はすべての階層レベルのパケットに対して同等に処理する必要はなく、例えばネットワークの帯域に応じてFEC(フォワードエラーコレクション)の冗長度を変化させたり、再送回数を優先度に応じて重み付けする。
【0075】
なお、図5に示す優先度設定マップは、ネットワーク状況に応じて動的に変更する構成を持つ。ネットワーク監視部21が取得する帯域監視情報、RTCPによる送信パケットの損失率情報等を用いて、送信可能な帯域、保証可能な品質を考慮してマッピング方法を変える。階層レベルをRTPパケットの優先度レベルあるいはIPパケットの優先度レベルへマッピングする優先度設定マップを生成する場合、元画像へのロスによる影響をネットワークのロス率を考慮して優先度を決めることが可能である。
【0076】
このように、本発明のデータ通信システムにおいては、RTPヘッダのRTPペイロードヘッダ内に、符号化データの階層レベルに応じた優先度を設定した構成としたので、RTPパケットレベルで上層のアプリケーションに依存した優先度の把握が可能となる。この優先度の把握により、パケットロスに対する処理を変えることが可能である。
【0077】
このような階層レベル毎の処理はアプリケーションに依存し、RTPパケットレベルでは優先度に応じてどう処理するかは、RTPパケットレベルだけで決定してよい。同様に、IPパケットレベルで優先度をつけて処理方法を変えることも可能である。この場合、IPパケットレベルではDiffServのようにネットワークが提供する機能であるからネットワークがサポートする、あるいはネットワークが規定した優先度をつけるためにRTPパケットレベルの優先度からIPパケットレベルの優先度へマッピングする。
【0078】
図5に示す優先度設定マップにおいてはRTPパケットレベルで5段階の優先度を設定し、IPパケットレベルで3段階の優先度を設定した例である。RTPパケットレベル1がIPパケットレベル1に、RTPパケットレベル2,3がIPパケットレベル2に、RTPパケットレベル4,5がIPパケットレベル3に対応している。DiffServで扱える優先度の数は現状のIPv4フォーマットでは少ないが、本例のようなマッピングを適用して、3段階の優先度に対応する処理は可能である。
【0079】
例えば、解像度に基づくプログレッシブ順序に従った符号化データについてのパケット化の場合、低解像度データの符号化データを格納したパケットの優先度が高く、高解像度の符号化データを格納したパケットの優先度が低く設定され、受信端末では、各パケットのIPヘッダまたはRTPヘッダに付与された優先度を参照して、低域のパケットを優先して処理することが可能となり、例えばネットワークの輻輳があっても該当するパケットの廃棄される率が下がることにより画質が改善される。
【0080】
なお、優先度設定マップは、この他にも、様々な態様の構成が可能である。このように、階層符号化されたデータの重要度に応じて、アプリケーションに依存した優先度をRTPペイロードヘッダに設定し、さらに、IPヘッダに優先度を設定することが可能であり、これらの複数の優先度情報を使ってレイヤー毎にエラー制御方法を変えたり、レート制御を実行するなどの処理が可能となる。
【0081】
RTPペイロードヘッダに設定する優先度はアプリケーションやユーザの要求、受信側端末から受信する受信側端末情報に応じて動的に変更設定可能であり、IPヘッダに設定する優先度は、ネットワーク状況、例えばネットワークの輻輳度合いに応じて動的に変更設定する。なお、送信側端末201のネットワーク監視部は、受信側端末202から受信側端末のデータ受信状況に関する情報を受信し、階層エラー訂正優先度制御部212は、この情報に基づいて、上述したように、エンコーダ204における符号化態様、階層化部205における階層設定処理態様、優先度付け処理部206における優先度設定処理態様を動的に変更するための制御情報を各処理部に出力する。
【0082】
このように、優先度付け処理部206において、優先度付け処理が行なわれデータはバッファ207ヘ出力され保存される。バッファ207に保存された符号化データは、FEC(Forward Error Correction)処理部208において、エラー訂正のための冗長コードが必要に応じて付与される。FECの手法としては、ATMのAAL1におけるパケットロスに対してFECを行う手法、ITU-T Recommendation I.363.1, B-ISDN ATM Adaptation Layer (AAL), types 1 and 2 specificationに記載のマトリックスを作って損失パケットのリードソロモン復号する手法に準じた方法等が適用可能である。なお、FEC(Forward Error Correction)処理部208における、エラー訂正のための冗長コード付与処理は、個々のデータに基づく冗長コード付与ではなく、エラー耐性を高めるために複数のデータに渡るテータに基づいて冗長コードを付与する処理、すなわちインターリーブ処理を併せて実行する構成としてもよい。
【0083】
このFEC(Forward Error Correction)処理部208における、エラー訂正のための冗長コード付与処理はすべての階層レベルのパケットに対して同等に処理する必要はなく、FEC(Forward Error Correction)処理部208は、例えばネットワークの混雑等によるパケットの遅延状況、ネットワークの帯域等をネットワーク監視部215が検出し、この検出情報に基づいてFEC(フォワード・エラー・コレクション)の冗長度を変化させる等、処理を動的に変更する。
【0084】
上述のように、送信側端末201は、ネットワーク監視部215の情報、すなわち、受信側端末202からの受信側端末のデータ受信状況に関する情報、ネットワーク状況に関する情報に基づいて、エンコーダ204における符号化態様、階層化部205における階層設定処理態様、優先度付け処理部206における優先度設定処理態様、FEC(Forward Error Correction)処理部208における処理を動的に変更可能である。
【0085】
上述した送信側端末の処理構成に基づいて、例えば符号化階層(レイヤー)毎に実行すべきエラー処理態様として、FEC処理対象階層データとしたり、あるいは再生要求処理(ARQ:Auto Repeat reQuest)対象階層データとしての割り当てが可能となり、各階層において最適なエラー訂正とスループットを得ることが可能となる。つまり、伝送路状況がエラー率が高かったり遅延が大きいなどパケット再生処理(ARQ:Auto Repeat reQuest)に不利な状況ではFECでエラー訂正を実行する設定としたり、あるいは伝送遅延が小さいが冗長データを送りたくない場合には、FECではなくARQを利用したエラー対応とするなど、送信側で任意のエラー対応設定としたデータパケットの送信が可能となる。
【0086】
また、受信側端末においても同様のネットワーク監視部229を有しており、ネットワークの混雑等によるパケットの遅延状況、ネットワークの帯域等の情報に基づいて、ネットワーク状況が良い場合には、階層を上げてより高品質なデータを再生する等の動的な対応が可能となる。
【0087】
図2の送信側端末201の構成について説明を続ける。FEC処理部208において、必要に応じてエラー訂正用の冗長コードが付与されたデータは、リアルタイム・トランスポート・プロトコル:RTP(Real-time Transport Protocol)に従ったデータ・パケット(以下パケットと称する)を生成するRTPパケット生成部209に出力され、符号化データを格納したRTPパケットのパケット生成処理が実行される。RTPパケット生成部209において生成された符号化データを格納したRTPパケットは、RTPプロトコルを通じてRTPポート210からIPネットワーク219に送出される。送信側端末201のRTPパケット生成部209およびRTPポートによってパケット送信処理部が構成される。
【0088】
RTPパケット生成部209は、符号化データをペイロードとしたパケットを生成する処理を実行する。ペイロードデータに対して、RTPヘッダを付加しパケット化する。RTPパケット構成を図6に示す。RTPヘッダには、バージョン番号(v)、パディング(P)、拡張ヘッダ(X)の有無、送信元数(Counter)、マーカ情報(marker bit)、ペイロードタイプ(Payload type)、シーケンス番号、タイムスタンプ、同期ソース(送信元)識別子(SSRC)および貢献ソース(送信元)識別子(CSRC)の各フィールドが設けられている。データ受信側において、RTPヘッダに付与されたタイムスタンプによりRTPパケットの展開時に処理時間の制御が実行され、リアルタイム画像、または音声の再生制御が可能となる。なお、例えば動画像データの符号化データを格納したRTPパケットにおいては、1つの画像フレームに属する複数のRTPパケットに共通のタイムスタンプが設定され、各フレームを構成する終端パケットには、終端であることを示す識別フラグがRTPヘッダに格納される。
【0089】
RTPヘッダを付加されたパケットはさらにIPヘッダが付与される。図7にIPパケットの構成中のIPヘッダの詳細を示す。IPv4、IPv6等のバージョンを示すバージョン、ヘッダ長、さらに、優先度情報を格納したTOS(Type of Service)フィールド、パケットの長さ、パケットの識別子、IP層でのデータ分割(フラグメント)に関する制御情報としてのフラグ、分割(フラグメント)されたデータの場所を示す断片オフセット、データの破棄までの時間情報を示すTTL(Time to Live)、上位層で利用されるプロトコル(4:IP,TCP:7,UDP:17…)ヘッダのチェックサム、送信元IPアドレス、宛て先IPアドレスを有する。
【0090】
図2に戻り、データ受信処理について説明する。受信側端末202のRTPポート220は、IPネットワーク219を介して送信側端末201からのRTPパケットを受信する。受信したRTPパケットは、RTPパケット解析部221においてパケットの解析が実行される。受信側端末202のRTPポート220および、RTPパケット解析部221によってパケット受信処理部が構成される。RTPパケット解析部221は、具体的にはパケット内のヘッダ部、データ部についての解析を実行する。パケットから取り出されたペイロードとしてのデータは、エラー監視部222において受信パケットのエラーについての検証が実行される。
【0091】
エラー監視部222にてパケット損失が発見されず、正常にデータ受信がなされている場合には、受信パケットはバッファ223に蓄積され、ヘッダ情報に基づく時間制御の下にデコーダ224に渡され、デコーダ224によって復号処理が実行される。例えば動画像を構成する各画像フレームは、複数のパケットに格納されたデータによって構成され、1つの画像フレームを構成するデータを格納した複数のRTPパケットのヘッダには、同一のタイムスタンプが格納されるので、ヘッダ情報のタイムスタンプを参照して同一タイムスタンプを持つパケットを1つの画像フレームを構成する符号化データの集合として、デコーダ224に渡すことが可能となり、デコーダ224は、フレーム毎に復号処理を実行することができる。デコーダ224において復号されたデータは、再生装置としてのディスプレイ、またはスピーカへ渡され、出力再生される。
【0092】
送信側端末201から受信側端末202へ転送されるパケットが全て滞りなく、また、エラーのない状態で送信されれば、受信側端末202におけるリアルタイムデータ再生は問題なく実行される。しかし、実際は、ネットワーク上でのパケット損失の発生、遅延、転送パケットのデータエラー等、様々な要因に基づく再生エラーあるいは再生データの品質低下が発生し得る。
【0093】
本発明のデータ通信システムでは、エラー監視部222にてパケット損失が発見された場合、エラー訂正制御部230は、FECにより復元可能かを判断する。FECにより訂正可能ならば、エラー訂正制御部230は、FECに基づくエラー訂正を実行する。FECエラー訂正によるデータ復元が実行された場合は、送信側端末201に対するデータ再送要求としてのARQ(Auto Repeat reQuest)処理は実行しない。訂正不可能であると判定した場合には、エラー訂正制御部230は、再送要求としてARQ(Auto Repeat reQuest)処理を実行する。図2においては、再送要求としてRTCPパケット生成部227において、RTCPパケットを作成し、RTCPポート225より再送要求を送信側端末に送信する構成を持つ。なお、再送要求伝送処理のプロトコルはRTCPに限らず、TCPに従った再送要求をTCPポート228を介して出力してもよい。
【0094】
エラー訂正制御部230において、再送要求を実行するとの判定がなされた場合、受信側端末202は、再送要求パケットを識別するデータを格納した再送要求NACK(Negative ACKnowledge)−RTCP(Real-time Transport Control Protocol)パケットをRTCPパケット生成部227にて作成し、RTCPパケットポート225を介して、送信側端末201に対して出力する。
【0095】
送信側端末201のRTCPパケットポート217が、受信側端末202からの再送要求を示すNACK−RTCPパケットを受信すると、受信したNACK−RTCPパケットをRTCPパケット解析部216に渡す、RTCPパケット解析部216はパケットの解析を実行し、解析結果をARQ制御部213、およびネットワーク監視部215へ渡す。ネットワーク監視部215は、入力情報に基づいて、ARQの頻度の検出が可能となり、伝送状態を判定することが可能であり、これらの情報を階層エラー訂正優先度制御部212に出力し、階層エラー訂正優先度制御部212は入力情報に基づいて、符号化、階層化、優先度付け、FEC処理の各処理態様の動的変更制御を行なうことが可能となる。
【0096】
また、RTCPパケット解析部216において解析した解析結果を受信したARQ制御部213では、再送要求に応じたパケットの再送を実行するため、NACK−RTCPパケットにおいて指定されたパケットをバッファ207から抽出し、抽出したパケットを、RTPポート210を介して再送する制御処理を実行する。ARQ制御部213は、データ受信端末装置から受信する再送要求メッセージパケットに従って再送すべきデータパケットの抽出処理を実行する再送制御部として機能する。
【0097】
送信側端末201において送信すべきストリームデータの終了を検知した場合には、送信側端末201のRTCPパケット生成部214の生成したストリームの終了を示すEOS(End Of Stream)メッセージを持つRTCPパケットを受信側端末202へ送り、データストリームの終了を明示する。
【0098】
本発明のデータ通信システムにおいては、リアルタイム再生を考慮して、ロストパケットに関する再送要求の実行/非実行の処理を決定する。データ転送における自動再送要求方式であるARQ(Automatic Repeat reQuest)は非常に有効な誤り訂正機能として知られている。ARQの具体的方式としては、例えばSAW(Stop And Wait)方式、GBN(Go Back N)方式、SR(Selective Repeat)方式など種々の方法が提案され実現されている。
【0099】
本発明のシステムにおいては、上述のようにFECとARQを組み合わせて、よりエラー耐性の強いデータ伝送が実現される。受信側端末202では、ネットワーク状況とバッファ状況、再生状況によって階層を落とさなくても、FEC処理およびARQ処理にてその階層の品質が得られるならば、エラー訂正によって処理し、処理対象データの階層を落とすことによるデータ品質低下はできるだけ行わないよう制御する。
【0100】
また、受信側端末の階層選択制御部231は、ネットワーク状況を監視するネットワーク状況監視部229のネットワーク状況情報に基づく処理データの選択を実行し、送信側端末の設定した階層または優先度に従って処理データを選択して実行する。例えばネットワーク状況が悪くパケットロス、遅延が大きい場合には、基本階層のみあるいは、優先度の高いデータのみを選択して処理を実行したり、ネットワーク状況がよくパケットロス、遅延が少ない場合には、より高階層のデータあるいは、優先度の低いデータも選択して処理を実行するなど、ネットワーク状況に応じたデータ選択処理を実行する。
【0101】
図2のデータ通信システムにおける受信側端末202のエラー訂正制御部223の処理について、さらに説明する。エラー訂正制御部223は、ネットワーク監視部229によって監視されている現在のネットワーク状況を踏まえてエラー訂正を制御する。ネットワークの監視は、往復伝播遅延(RTT)やパケットロス率などRTCPやICMPなどの汎用のプロトコルを利用して取得する。ARQにおいてデータ再生におけるリアルタイム性を保持するためには、常に送信と受信における往復伝播遅延(RTT)を計測しておく必要がある。本発明のシステムでは、データ受信側端末は、能動的にRTTを計測し、ネットワーク状況等において変化する送信と受信における往復伝播遅延(RTT)の更新を実行し、最新のRTTに基づいて再送要求としてのNACK−RTCPの送信の実行可否を判定する。
【0102】
送信と受信における往復伝播遅延(RTT)をデータ受信端末において、あらかじめ把握することにより、データ受信端末において、再送要求を行なってから再送パケットを受信するまでの時間の把握が可能となり、データ受信端末においてリアルタイム再生を行なうために必要な最終再送要求時間を割り出すことが可能なる。本発明のシステムでは、受信端末のARQ判定部において、往復伝播遅延(RTT)に基づく最終再送要求時間を判定し、判定に基づいて、再送要求としてのNACK−RTCPの送信を実行する。これらの処理については、次の各端末の処理フローの説明において詳細に説明する。
【0103】
[データ送信端末における処理]
以下、図面を参照しながら、データ送信端末における処理の詳細について説明する。
【0104】
データ送信端末の処理手順を図8に示すフローチャートを参照して説明する。図8に示す処理は、図2の送信側端末201において実行される処理を説明したフローである。送信側端末は、例えばビデオカメラ、あるいはDVD、CD、ハードディスク等の記憶媒体から撮り込んだデータをエンコーダにおいてMPEG圧縮等の符号化処理を実行し、その後、符号化データをペイロードとしたパケットを生成する。図8に示すフローは、このパケット生成処理以降の処理を示している。
【0105】
データ送信端末は、ステップS301において、送信データをペイロードとしたRTPパケット生成処理を実行する。RTPパケットは、先に図6を参照して説明した構成を有しタイムスタンプをヘッダ中に持つ。例えば動画像データを送信する場合は、同一画像フレームに属する符号化データを格納したパケットには同一のタイムスタンプが設定され、後続フレームに進むに従って、増分されたタイムスタンプが設定される。
【0106】
ステップS301で生成したRTPパケットは、ステップS302、ステップS303において、必要に応じてFEC(Forward Error Correction)処理部208が、エラー訂正のための冗長コード付与処理を実行する。先に説明したように、FEC処理部208における処理は動的に変更され、例えばネットワークの混雑等によるパケットの遅延状況、ネットワークの帯域等をネットワーク監視部215が検出し、この検出情報に基づいてFEC(フォワード・エラー・コレクション)の冗長度を変化させたり、あるいは冗長コードの付与対象の階層を変更して処理を実行する。FEC処理部における処理を実行しないデータに対しては、ステップS303を飛ばしてステップS304に進む。
【0107】
FEC処理部208は、ネットワーク監視部215が検出したネットワーク状況情報に基づいて階層エラー訂正優先度制御部212が生成した制御情報を入力して、入力する制御情報に基づいて処理態様が決定される。なお、前述したように、FEC処理部208におけるエラー訂正のための冗長コード付与処理は、個々のデータに基づく冗長コード付与ではなく、エラー耐性を高めるために複数のデータに渡るテータに基づいて冗長コードを付与する処理、すなわちインターリーブ処理が併せて実行される。
【0108】
次に、ステップS304において、RTPポートを介して受信端末に向けてIPネットワークに出力される。なお、RTPパケットはさらに、先に図7を用いて説明したIPヘッダが付与され、IPヘッダに設定されたアドレスに向けて配信されることになる。パケット生成、パケット送信処理は、ストリーミング配信されるデータが終了したことを明示的に示すEOS(End Of Stream)を配信し、予め設定した時間をタイマーで計測して、タイマーでの計測時間が設定時間を超えた場合に、処理を終了する。
【0109】
図8に示すステップS305のパケット再送要求としてのNACK−RTCPパケットの受信判定処理、ステップS306のパケット受信確認応答としてのACK−RTCPパケットの受信判定処理、ステップS307のRTT時間計測用のECHO−RTCPパケットの受信判定処理は、RTPパケットによる実データ送信中の割込み処理としてRTPパケットによる実データ送信に並行して逐次実行される処理である。
【0110】
ステップS305の処理は、データ受信端末からのパケット再送要求であるNACK−RTCPパケットの受信判定処理である。データ受信端末からのパケット再送要求であるNACK−RTCPパケットを受信した場合は、ステップS313〜S317の処理を実行する。このステップS313〜S317の処理は、図2に示すエラー訂正制御部230における処理として実行される。
【0111】
ステップS313においては、データ送信装置は、NACK−RTCPパケットを受信する。図9にデータ受信端末において生成し、データ送信端末の受信するパケット再送要求であるNACK−RTCPパケットの構成を示す。
【0112】
NACK−RTCPパケットは、図9に示すようにヘッダ(HEAD)、フォーマット(FORMAT)、パケットタイプ、パケット長、送信同期ソース識別子(RTCP)、タイムスタンプの情報に加えて、再送要求対象となるパケットの識別子としての再送指定シーケンス番号、さらに、各再送指定シーケンス番号に対応するデータとして、「再送回数」、「オプション」、「重複指定回数」が設定可能である。
【0113】
前述したように、本発明の提案するARQを適用したシステムでは、RTCPに従ったコントロール・パケットとして再送要求としてのNACK、受信確認としてのACK、ストリーミング配信されるデータが終了したことを明示的に示すEOS、送信と受信における往復伝播遅延(RTT)を計測する際に使用されるECHO、およびECHO−REPLYのパケットが利用される。これらの各RTCPパケットそれぞれのフォーマットタイプを一制御メッセージとして、すなわちRTCPヘッダのPT(Payload Type)として区別をするのは汎用的ではない。よって、制御メッセージとしては、フィードバックメッセージ(FM:Feedback Message)として定義しPT(Payload Type)に指定する。かつ、RTCPヘッダ内の[フォーマット]フィールドであるFMT (Feedback Message Format)にそのパケットフォーマットの指定をすることで、どのようなフィードバックメッセージかを決定できる構成とする。
【0114】
図9に示すように、1つのNACKパケットには1つ以上の再送要求対象となるパケットの識別子としてのシーケンス番号を付与することができる構成を持つ。つまり一度のNACKパケットの送信処理で複数のパケットについての再送要求が可能になる。また、再送要求パケットのシーケンス番号各々に対して付加される「再送回数」は、何回目の再送要求かを明記するフィールドであり、「重複指定回数」は、再送する場合の多重回数の指定を明記するフィールドであり、「オプション」はその他の任意の情報を格納するフィールドとして使用される。
【0115】
例えば、「重複指定回数」に[3]をいれておけば、NACKを受信したデータ送信側は、同じデータを格納した再送パケットを[3]つ連続で送る処理を実行する。重要データを格納したパケットについては、重複再送を要求することで、再送パケットの受信の確実性を高めることが可能となる。また、繰り返し、同一パケットについての再送要求としてのNACKを送信しているにもかかわらず、受信に成功しない場合や、リアルタイム再生に間に合うための再送可能最終時間に出されるNACKにおいて、「重複指定回数」の設定数を増加させてデータ送信側に送信することにより、再送パケットの受信の確実性を高めることが可能となり、データ再生品質を向上させることが可能となる。データ受信側は、このようなNACK−RTCPパケットを送信して、データ送信側は、受信したNACK−RTCPパケットに基づくパケット再送処理を実行する。
【0116】
なお、RTPパケットフォーマットやペイロードフォーマット、または受信端末の利用者が意図的に指定した場合など、パケットに優先度が与えられている場合、優先度が高いパケットやデータに関しての再送は多重再送処理を行なうことで、再送パケットの受信確率を高めるようコントロール可能である。また、「再送回数」フィールドにおいて何回目の再送要求かを明記することで、NACK自身が損失したことを送信側が検知できる。
【0117】
「オプション」フィールドには、フィールド設定値に従って、例えば図10に示す処理指定を行なうことが可能となる。すなわち、
オプション設定値=0
指定シーケンス番号を持つパケットのみの再送要求(デフォルト)
オプション設定値=1
フレーム先頭パケットから指定シーケンス番号を持つパケットまでの一括再送要求
オプション設定値=2
指定シーケンス番号からフレーム最後尾までのパケットの一括再送要求
オプション設定値=3
指定タイムスタンプの付与されたパケットの一括再送要求
オプション設定値=4
タイムスタンプを無視してシーケンス番号のみで検索して検索結果のパケットの再送を要求
【0118】
画像データ等の符号化データは、先に図6を参照して説明したように、タイムスタンプとシーケンス番号をセットとしたヘッダを持つ1つのRTPパケットに格納した構成を有するが、データ転送処理において、タイムスタンプの変わり目を含んた連続的なエラーとしてのバーストエラーが起こった場合、あるいは、バーストエラーの発生により、フレーム単位でパケットの損失が発生した場合などにおいては、受信端末側では、パケット損失の発生したパケットに対応するタイムスタンプとシーケンス番号のセットを特定できない場合が発生する。このような場合において、特定可能なタイムスタンプ、あるいはシーケンス番号のいずれか一方のみを指定して、上記のオプション設定値を設定することにより、フレキシブルな態様で再送の必要な1以上のパケット指定が可能となる。
【0119】
このように、データ受信端末では、様々な態様での再送要求パケットの指定が可能であり、NACK−RTCPパケットを受信したデータ送信端末のARQ制御部213は、オプションフィールドの設定値に従って、バッファ207に格納済みのパケットから指定パケットを抽出して、再送処理を実行する。
【0120】
図8に戻り、データ送信端末の処理について説明する。ステップS314では、ステップS312で受信したNACK−RTCPパケットに指定された再送要求パケットに対応するシーケンス番号を抽出し、ステップS315では、オプション指定の抽出を実行する。上述したように再送要求パケットの指定態様は、シーケンス番号の直接指定のみならず、タイムスタンプ等による指定等、様々であり、データ送信端末装置のARQ制御部213では、受信したNACK−RTCPパケットに指定されたオプション指定、およびタイムスタンプ、シーケンス番号を参照して、再送要求パケットを特定する処理を実行する。
【0121】
ステップS316では、特定された再送要求パケットをバッファ207から抽出する。バッファ207には、再送要求に備えて所定時間、送信済みのパケットが保持格納されており、これらの格納パケットから再送指定のあったパケットを抽出する処理を実行する。ステップS317で、RTPポートから抽出パケットが送信される。
【0122】
ステップS305において、NACK−RTCPパケットを受信しない場合は、ステップS306でパケット受信応答としてのACK−RTCPパケットの受信確認を行ない、ACK−RTCPパケットの受信に基づいて、ステップS311で、受信の確認されたパケットをバッファ207からクリア(削除)する。このACKにより、再送要求に対応してパケットを保持する送信側のバッファを能動的に早めにクリアすることが可能となり、バッファ溢れの恐れを低下させることが可能となる。
【0123】
図11にデータ受信端末において生成し、データ送信端末の受信するパケット受信確認応答であるACK−RTCPパケットの構成を示す。
【0124】
ACK−RTCPパケットは、図11に示すようにヘッダ(HEAD)、フォーマット(FORMAT)、パケットタイプ、パケット長、送信同期ソース識別子(RTCP)、タイムスタンプの情報に加えて、受信パケットの識別子としての受信済みシーケンス番号が格納される。
【0125】
なお、シーケンス番号を指定せず、タイムスタンプ(TIMESTAMP)のみ指定する構成とすることも可能であり、この場合には、そのタイムスタンプ(TIMESTAMP)の設定されたパケットすべてを受け取った事を示す。よってこのような場合にはシーケンス番号をすべて指定する必要はないため、ACK−RTCPパケットサイズを小さくすることが可能となり、ネットワークトラフィックの増大を低減できる。
【0126】
図8に戻り、データ送信端末の処理の説明を続ける。データ送信端末は、ステップS307において、ECHO−RTCPパケットの受信確認を行ない、データ受信端末からECHO−RTCPパケットを受信した場合は、ステップS311において、ECHO−REPLY−RTCPパケットをECHO−RTCPパケットを送信してきたデータ受信端末に対して送信する処理を実行する。
【0127】
ECHO−RTCPパケットと、ECHO−REPLY−RTCPパケットは、送信端末と受信端末における往復伝播遅延(RTT)をデータ受信端末において把握するために用いるRTCPパケットである。このパケットの送受信によって、データ受信端末において、再送要求を行なってから再送パケットを受信するまでの時間の把握が可能となり、データ受信端末においてリアルタイム再生を行なうために必要な最終再送要求時間を割り出すことが可能なる。
【0128】
本発明のシステムでは、受信端末のエラー訂正制御部230において、往復伝播遅延(RTT)に基づく最終再送要求時間を判定し、判定に基づいて、再送要求としてのNACK−RTCPの送信の実行可否を決定する。この判定処理に必要な送信端末と受信端末における往復伝播遅延(RTT)の最新情報を取得するため、データ受信端末側は、任意タイミングで、能動的にECHO−RTCPパケットをデータ送信端末に送信し、データ送信端末は、ECHO−RTCPパケットの受信に応答してECHO−REPLY−RTCPパケットをECHO−RTCPパケットを送信してきたデータ受信端末に対して送信する。
【0129】
データ受信端末では、データ送信端末からの応答として受信するECHO−REPLY−RTCPパケットを解析することによって、送信端末と受信端末における往復伝播遅延(RTT)を算出する。このRTT算出処理については、後段のデータ受信端末の処理の項目で説明する。
【0130】
図12にデータ受信端末において生成し、データ送信端末の受信するECHO−RTCPパケットの構成、および、データ送信端末において生成し、データ受信端末に対して送信するECHO−REPLY−RTCPパケットの構成を示す。
【0131】
ECHO−RTCPパケットは、図12(a)に示すようにヘッダ(HEAD)、フォーマット(FORMAT)、パケットタイプ、パケット長、送信同期ソース識別子(RTCP)、およびECHOパケットの識別データとしてのECHO−IDが格納される。ECHO−REPLY−RTCPパケットは、図12(b)に示すようにヘッダ(HEAD)、フォーマット(FORMAT)、パケットタイプ、パケット長、送信同期ソース識別子(RTCP)、およびECHO−RTCPパケットに対応するECHO−ID、および、サーバ処理時間が格納される。
【0132】
ECHO−IDをECHO−RTCPパケットとECHO−REPLY−RTCPパケットに入れることにより、データ受信端末側がECHO−REPLYを受け取った際に、いつ送信したECHO−RTCPパケットに対応する返事(ECHO−REPLY)かを識別することが可能となる。ECHO−REPLY−RTCPパケットに格納されるサーバ処理時間は、データ送信端末がデータ受信端末からの再送要求(NACK−RTCP)を受信してからパケットをデータ送信端末から出力するまでに要する処理時間に相当する時間である。このサーバ処理時間は、ECHO−RTCPパケットを受信した時間からECHO−REPLY−RTCPパケットを送信するまでの時間として設定するか、あるいは、予めデータ送信端末において過去の履歴データとして、実際に、データ送信端末がデータ受信端末からの再送要求(NACK−RTCP)を受信してからパケットをデータ送信端末から出力するまでに要した時間をメモリに格納し、この格納データを適用してもよいし、あるいは、ECHO−RTCPパケットを受信した時点におけるサーバ(データ送信端末)における処理負荷を算出して、処理負荷に基づいて算出される予測処理時間をサーバ処理時間として設定する構成としてもよい。
【0133】
データ受信端末は、ECHO−REPLY−RTCPパケットに格納されたサーバ処理時間と、ECHO−RTCPパケット送信からECHO−REPLY−RTCPの受信までの時間とに基づいて、送信端末と受信端末における往復伝播遅延(RTT)を算出する。このRTT算出処理については、後段のデータ受信端末の処理の項目で説明する。
【0134】
図8に戻り、データ送信端末の処理の説明を続ける。データ送信端末は、ステップS306において、送信対象となるストリーミングデータのパケット送信がすべて終了したかを判定し、終了と判定した場合は、ステップS310において、データストリームの終了を明示するEOS(End Of Stream)メッセージを持つRTCPパケットを受信側端末へ送信する処理を実行する。
【0135】
図13にデータ送信端末において生成し、データ受信端末の受信するEOS−RTCPパケットの構成を示す。
【0136】
EOS−RTCPパケットは、図13に示すようにヘッダ(HEAD)、フォーマット(FORMAT)、パケットタイプ、パケット長、送信同期ソース識別子(RTCP)、およびタイムスタンプ(TIMESTAMP)が格納される。データ受信端末は、EOS−RTCPパケットをデータ送信端末から受信することにより、ストリーミング配信されるデータの終了を認識する。受信端末はこの認識処理により、次フレームが到着しないことによる誤ったNACK送出動作を防ぐことができる。
【0137】
図8に戻り、データ送信端末の処理の説明を続ける。データ送信端末は、ステップS309において、予め設定した時間を計測するタイマーでの計測時間が設定時間を超えたか否かを判定して、タイマーが設定時間を超えていない場合は、ステップS305以下の処理、すなわち、ステップS305のパケット再送要求としてのNACK−RTCPパケットの受信判定処理以下の処理を継続して実行する。これは、全パケット送出後においても、一定時間は、データ受信側からのパケット再送要求としてのNACK−RTCPパケット、または、受信確認応答としてのACK−RTCPパケット、または、ECHO−RTCPパケットを受信する可能性があり、これらのパケット受信に対する処理を実行するためである。タイマーにおいて、予め設定した時間が経過した時点で、データ送信を終了する。
【0138】
[データ受信端末における処理]
次に、データ受信端末の処理手順を図14に示すフローチャートを参照して説明する。図14に示す処理は、図2の受信側端末202において実行される処理を説明したフローである。
【0139】
データ受信端末は、ステップS400において、データ送信端末からの送信開始通知を受信後、ステップS401において、データ送信端末からの送信パケット、すなわち符号化データをペイロードとして格納したRTPパケットを順次、受信する。RTPパケットは、先に、図6を参照して説明したように、タイムスタンプがヘッダ情報中に格納されている。データ受信端末は、タイムスタンプに基づいて受信するパケットに含まれるフレームを判別することができる。先に説明したように、動画像データをRTPパケットに符号化データとして格納して送信する場合、同一の画像フレームに属する複数のRTPパケットには同一のタイムスタンプが設定され、データ受信側端末は、タイムスタンプを参照して、フレームの判別が可能となる。
【0140】
データ受信端末は、ステップS402において、受信パケットがエラー訂正のための冗長コードが付与されているか否かを判定する。冗長コードが付与されている場合は、ステップS411に進み、エラー訂正制御部230において、データ送信側で実行したインターリーブ対応するインターリーブ処理を実行して、ステップS412において、損失パケットの有無を判定する。損失パケットが無い場合は、ステップS416のデコード処理に進む。損失パケットがある場合は、ステップS413で、FECによるエラー訂正、すなわち冗長コードに基づくエラー訂正処理を実行し、エラー訂正により再生可能か否かを判定する。再生可能であると判定した場合は、ステップS416のデコード処理に進む。
【0141】
ステップS413においてFECによる処理のみでは、再生可能でないと判定した場合は、ステップS415に進む。ステップS415の再送要求処理としてのNACK−RTCPパケットの送信判定処理について説明する。リアルタイム再生処理を実現するためには、再生タイミングに間に合うように、再送要求パケットが受信端末に届くことが必要となる。ステップS415の再送要求処理としてのNACK−RTCPパケットの送信判定処理は、NACK−RTCPパケットを送信した場合、リアルタイム再生処理に間に合うタイミングで、再送パケットが受信可能か否かを判定するものである。
【0142】
この判定のためには、前述したように、送信端末と受信端末間における往復伝播遅延(RTT)が重要なパラメータとなる。往復伝播遅延(RTT)が大きい場合、データ受信端末からデータ送信端末に対して再送要求を出しても、再送要求を発信して、再送パケットがデータ送信端末から再送され、データ受信端末において受信するまでに時間を要すると、その後デコーダに渡して復号を行なってリアルタイム再生に間に合わない場合が発生する。本発明のシステムでは、データ受信端末において、往復伝播遅延(RTT)をあらかじめ把握し、往復伝播遅延(RTT)に基づいて、NACK−RTCPパケットの送信判定処理を行なう。
【0143】
本発明のシステムにおいては、データ受信端末側が、任意タイミングで、往復伝播遅延(RTT)の計測を実行することを可能な構成としている。具体的には、データ受信端末から、先に説明した図12に示すECHO−RTCPパケットを送信し、ECHO−REPLY−RTCPパケットを受信して、RTTの算出を行なう。
【0144】
図15を参照して、データ受信端末で実行するECHO−RTCPパケットの送信、ECHO−REPLY−RTCPパケットの受信、往復伝播遅延(RTT)の算出処理について説明する。
【0145】
図15(a)は、ECHO−RTCPパケットの送信処理フローである。ECHO−RTCPパケットの送信は、データ受信端末が任意タイミングで能動的に実行することが可能である。
【0146】
ステップS501における、RTCPパケットの送信待機状態において、RTTの計測要請が発生した場合、ステップS502のECHO−RTCPパケットの生成処理に移行する。RTTの計測は、データ受信が開始された後、例えば図14の処理フローにおいて、ステップS400の送信開始通知を受信した以降、定期的に実行する等の設定が可能であり、データ受信側端末に保有するタイマーで予め定めた計測間隔が経過したか否かを計測し、予め定めた計測間隔に対応する時間が経過した場合に、エラー訂正制御部230が、ECHO−RTCPパケットの生成要求をRTCPパケット生成部227に出力し、RTCPパケット生成部227がステップS502のECHO−RTCPパケットの生成処理を実行するなどの設定が可能である。この他にも、パケットのロスト状況を解析し、ロスト状況に応じてECHO−RTCPパケットの生成、送信を実行する構成としてもよく、いずれにしても、データ受信端末は、任意タイミングで、ECHO−RTCPパケットの生成、送信が可能であり、常に最新の往復伝播遅延(RTT)の算出が可能となる。
【0147】
ステップS502で生成するECHO−RTCPパケットは、先に図12(a)を参照して説明した構成を有する。パケットには、各パケット固有の識別子としてのECHO−IDが設定される。ステップS503で、生成したECHO−RTCPパケットが、RTCPポート225を介して、データ送信端末201に対して送信される。ステップS504では、ECHO−RTCPパケットを送信した送信時間、および、パケットに設定されたECHO−IDがメモリに記録される。
【0148】
図15(b)は、ECHO−REPLY−RTCPパケットの受信およびRTT算出処理フローである。ステップS601における、RTCPパケットの送信待機状態において、ECHO−REPLY−RTCPパケットが受信されたと判定(ステップS602でYes)されると、ステップS603において、ECHO−REPLY−RTCPパケットの受信時刻がメモリに記録される。受信するECHO−REPLY−RTCPパケットは、先に図12(b)を参照して説明した構成を有する。パケットには、応答対象となった対応するECHO−RTCPパケットと同一の識別子としてのECHO−IDが設定され、さらに、データ送信端末において算出したサーバ処理時間が格納される。
【0149】
ステップS604では、受信したECHO−REPLY−RTCPパケットからサーバ処理時間が抽出され、ステップS605において、受信したECHO−REPLY−RTCPパケットに設定されたECHO−IDから対応するECHO−RTCPパケットの送信時間が検索される。
【0150】
ステップS606では、ステップS603において取得したECHO−REPLY−RTCPパケットの受信時刻、ステップS604において取得したサーバ処理時間、ステップS603において取得したECHO−RTCPパケットの送信時間に基づいて、往復伝播遅延(RTT)の算出処理が実行される。往復伝播遅延(RTT)の算出は、下式に基づいて実行される。
往復伝播遅延(RTT)
=(ECHO-REPLAY受信時刻)-(ECHO送信時刻)-(サーバ処理時間)
【0151】
なお、RTTの計測を実行する際に送受信するECHO,ECHO−REPLYパケットも損失することが考えられる。またRTTもネットワークの状況により常に変動するため、データ受信端末は一定間隔でECHO,ECHO−REPLYパケットの送受信処理を実行してRTTを計測する。
【0152】
図14のフローに戻り、データ受信端末側の処理について説明を続ける。図14のフローにおいて、ステップS415では、再送要求としてのNACK−RTCPを出力した場合、リアルタイム再生処理に間に合うタイミングで再送要求パケットの受信が可能か否かを判定する。上述したECHO,ECHO−REPLYパケットの送受信処理により計測されたRTT値と、各フレームの処理タイミングを計測しているタイマーの期限に基づいて、再送要求としてのNACK−RTCPパケットを出しても間に合わないと判断した場合(S415でNo)には、NACK−RTCPパケットの送信処理は実行しない。
【0153】
たとえば、パケット損失の存在する該当フレームの符号化データの処理開始までの時間Ta=100mmsecである場合、すなわち100mmsec後にデコーダにデータを渡して復号処理が開始されることがタイマーの計測により明らかとなっている場合、計測された最新のRTT値が、該当フレームの符号化データの処理開始までの時間Taより大きい値であった場合、すなわち、100mmsec以上であった場合には、再送要求としてのNACK−RTCPパケットを送信しても、再送パケットの受信が、デコード処理開始タイミングに間に合わないものと判断して、NACK−RTCPパケットの送信処理を実行しない。ただし、RTT値が処理開始までの時間Ta以上であっても、RTT値と時間:Taの非常に近い値を持つ場合には、ぎりぎり間に合う可能性もあるためNACKを送出する構成としてもよい。このNACK送出判定の閾値は実装依存である。
【0154】
一方、計測された最新のRTT値が、パケット損失の存在する該当フレームの符号化データの処理開始までの時間Ta以下であった場合には、再送要求としてのNACK−RTCPパケットを送信して再送パケットを受信するまでの時間が、デコード処理開始タイミングまでの時間以下であるので、再送パケット受信が処理に間に合うものと判断して、ステップS417において、NACK−RTCPパケットの送信処理を実行する。
【0155】
図14のフローのステップS402において、FECによる冗長コードんが付与されていないパケットであると判定した場合は、ステップS403において、受信したパケットが、nフレーム目(n=1,2...)の終端パケットであるか否かを判定する。また、ステップS404において、受信したパケットが、n+1フレーム目の先頭パケットであるか否かを判定する。受信したパケットが、nフレーム目(n=1,2...)の終端パケットである場合、または、n+1フレーム目の先頭パケットである場合には、ステップS414に進む。
【0156】
ステップS414においては、nフレーム内に未受信のパケット、すなわちロストパケット、あるいはエラーパケットがあるか否かを判定する。
【0157】
ロストパケットまたはエラーパケットが検出されると、ステップS415以下の処理に進み、再送要求処理としてのNACK−RTCPパケットの送信判定処理、および判定に基づくNACK−RTCPパケットの送信処理が実行される。これらの判定処理の詳細は、前述した通りである。
【0158】
NACK−RTCPパケット送信の際にタイムスタンプ(TIMESTAMP)とシーケンス番号の組み合わせがはっきりしない場合には、先に図10を参照して説明したオプションを指定して送信する。データ受信端末では、パケットの送受信情報を随時記録することで、パケットロス率の割り出しが可能となる。このロス率が一定値以上になった場合には、NACK−RTCPパケット自体の損失の可能性が考えられるため、おなじNACK−RTCPパケットを複数回、重ねて送信する処理を行なうことで、再送成功率を高めることが可能となる。あるいは、NACK−RTCPパケットに重複指定回数を増分して設定する。
【0159】
データ送信端末は、NACK−RTCPパケットを受信すると、次のタイムスタンプを設定したフレームデータに併せて、再送パケットを送信する。
【0160】
ステップS414のロストパケットの検出処理は、ステップS403の各フレームの終端パケット受信、ステップS404の各フレームの先頭パケット受信時のみではなく、ステップS405の各フレームの最終再送時間の判定でYesの場合、およびステップS406のタイマーの最小計測時間τの経過判定でYesの場合に実行される。
【0161】
ステップS405の各フレームの最終再送時間の判定処理は、再送要求としてのNACK−RTCPを出力した場合、リアルタイム再生処理に間に合う最終時間判定処理である。各フレームについて、各フレームの符号化データの処理開始までの時間Taが計測されているRTT値と等しくなったとき、すなわち、Ta=RTTとなった場合に、ステップS405の判定がYesとなり、ステップS409の該当フレームに対するロストパケットの検出処理が実行される。これは、最後の再送要求可能タイミングにロストパケットを検出して、検出された場合に最後の再送要求を送信するための処理である。
【0162】
ステップS406のタイマーの最小計測時間τの経過判定処理は、データ受信端末の有するタイマーの計測最小時間:τ毎に、ステップS406の判定がYesとなり、ステップS414の該当フレームに対するロストパケットの検出処理が実行される。これは、各計測最小時間:τに対応する受信フレームについて、各フレームの先頭パケット、最終パケットの検出がなされない場合でもロストパケットを確実に検出して、再送要求を実行しようとするための処理である。
【0163】
このように、データ受信端末では、ステップS403の各フレームの終端パケット受信、ステップS404の各フレームの先頭パケット受信時、ステップS405の各フレームの最終再送時間の判定、およびステップS406のタイマーの最小計測時間τの経過判定の各タイミングにおいて、ステップS414のロストパケットの検出処理を実行する。なお、これらステップS403〜S406の4種類のタイミングのいずれかのみを実行する構成としてもよい。
【0164】
ステップS414の各フレームのロストパケット検出処理において、ロストパケットが検出されなかった場合は、各パケットに格納された符号化データのデコード(復号)処理がデコーダ224において実行される。ステップS418では、受信済みパケットについての受信確認パケットとしてのACK−RTCPパケットの生成、送信が行われる。ACK−RTCPパケットは、先に図11を参照して説明した通り、受信済みシーケンス番号を格納したパケットである。このACK−RTCPパケットを受信したデータ送信端末は、ACK−RTCPパケットに記録された受信済みシーケンス番号に対応するパケットをバッファ223からクリアする。
【0165】
図14に示すフローのステップS407では、各フレームのタイマー期限切れを確認する。このタイマー期限は、リアルタイム再生処理の開始期限を計測するタイマーによって設定される期限であり、各フレーム毎にそのタイミングが設定される。nフレームのタイマー期限切れであると判定された場合には、ロストパケットがあった場合であっても、ステップS416のデコード処理に移行することになる。
【0166】
ステップS408では、データ送信端末から、データストリームの終了を明示するEOS(End Of Stream)メッセージを持つRTCPパケットを受信したか否かを判定し、EOS−RTCPパケット受信でない場合は、ステップS401以下の処理を繰り返す。
【0167】
EOS−RTCPパケット受信である場合は、ステップS409において、各フレームのタイマー期限切れを確認する。このタイマー期限は、リアルタイム再生処理の開始期限を計測するタイマーによって設定される期限であり、各フレーム毎にそのタイミングが設定される。タイマー期限切れでない場合は、ステップS419に進み、再送要求されているロストパケットに関する再送パケットを受信待機状態であるか否かを判定して、待機状態である場合は、ステップS420に進み、再送パケットの受信待機状態として、ステップS401のパケット受信以下の処理を実行する。
【0168】
ステップS409における各フレームのタイマー期限切れの確認処理において、Yesと判定された場合、および、ステップS419において、再送パケット受信待機状態でないと判定された場合は、デコード、再生処理へ移行すべき未受信のパケットデータは存在しないと判定され、受信処理を完了する。
【0169】
このように、本発明のシステムにおいては、リアルタイム配信に適するものの信頼性を保証しないRTP等のデータ通信プロトコルに従ったパケット伝送において、FEC処理によるエラー訂正、または再送要求としてのARQを選択的に実行することで、エラー耐性のある信頼性の高いデータ伝送、リアルタイム再生が可能となる。なお、上述の実施例では、RTPパケットに符号化データを格納する構成例を中心として説明したが、RTPパケットフォーマットに限らず、UDP等、他のデータ通信プロトコルフォーマットに従ったパケットを用いたデータ通信構成においても、上述の実施例と同様の各種のコントロールパケットを用いた再送要求処理を行なうことにより、上述の実施例と同様の構成を実現可能である。
【0170】
上述したように本発明の構成では、再送要求の処理タイミングとして、各フレームの先頭パケットの受信時、各フレームの最終パケットの受信時、最終処理期限、および一定間隔(τ)毎等の各種タイミングでロストパケットの検出処理を実行する構成としたので、確実なロストパケットの検出が可能となる。
【0171】
また、本発明のデータ通信システムにおける送信側端末の階層エラー訂正優先度制御部212は、および受信側端末202のエラー訂正制御部230は、それぞれのネットワーク監視部215、229によって監視されている現在のネットワーク状況を踏まえてエラー訂正を制御する。ネットワークの監視は、RTTやパケットロス率などRTCPやICMPなどの汎用のプロトコルを利用して取得する。受信側がRTTを検知するために、受信側は、前述したECHOパケットを送信側に送り、その返事であるECHO−REPLYパケットを受け取ることにとって、RTTを計測し、確実なパケット再送処理が実現される。
【0172】
先に説明したように、RTPではパケット毎にシーケンス番号をつけており、番号とフレームの先頭と終端を示すフラグをペイロードにいれておくことにより、あるフレームを構成するパケット数を簡単に受信側は計算することができ、必要なパケット数に対してある時間内にどれだけ正当なパケットが届いたかを監視していれば、ある程度のエラー率を求めることができる。ここで得られたエラー率またはRFC1889で規定されているRTCPのRR(Reciever Report)でのパケットロス率により、送信側はエラー率を知りFECのエラー訂正強度をあげたり、またはFECを施さないなどの処理態様の制御を実行する。
【0173】
エラー訂正処理として実行されるパケット再送要求(ARQ)は、再送要求NACKを送信し再送パケットが届くまでにRTT時間を要することになり、また、FEC訂正においても送受信端末でインターリーブする処理のために一定時間が必要となる。それぞれの端末におけるネットワーク監視部の監視により得られるネットワーク状況に基づいて、例えば、RTTが短いならば、ARQによる再送が可能となるためARQによるエラー訂正を選択して実行し、RTTが長く、再送する時間がないほど送信側から受信側に転送時間がかかるというネットワーク状況である場合には、ARQではなくFECによるエラー訂正を選択する、といった動的なエラー訂正制御が可能となる。
【0174】
受信側端末のエラー監視部222では、RTPではパケット毎のシーケンス番号に基づいて、必要なパケット数に対してある時間内にどれだけ正当なパケットが届いたかのエラー率を求めることができ、また、送信側端末では、再送要求処理の数をカウントすることでエラー率を概算することが可能となる。エラー率が高く、FECによるエラー訂正で訂正できないほどの高いエラー率であると判定した場合には、送信側端末201の階層エラー訂正優先度制御部212は、FEC処理部における冗長コードの付与を停止し、すべて受信側端末からの再送要求(ARQ)に応答するのみの処理を選択したり、あるいは、よりエラー訂正の強いアルゴリズムのFECを選択するといったエラーに対する処理態様を動的に変更することが可能となる。
【0175】
また、これらのエラー制御態様は、伝送するデータ階層に応じた優先度に対応して選択的に設定可能であり、様々なエラー訂正ポリシーが決められる。例えば受信側端末202のネットワーク状況監視部229は、パケットロス率、または伝送遅延時間に基づくネットワーク状況解析を実行し、階層選択制御部231が、解析結果に基づいて処理データの選択を実行することが可能である。
【0176】
さらに、このエラー訂正ポリシーは、ネットワーク状況や送信および受信端末側の意図により変更可能なため、一意に決まるものとすることは必要でない。ある送信環境とメディアによっては、基本となる階層は必ず完全再生したいので、強めのFEC+ARQで優先度を上げておく、音声データはFECのみで、オーバーヘッドは極力避けたいのでFECなしでARQとして再送回数1回まで、といったように自由な態様でのエラー制御態様を設定することができる。
【0177】
また、本発明のシステムでは、データ受信端末は、再生処理時間、伝播遅延時間RTTを考慮したデータ再送要求処理を実行するので、無駄な再送要求パケットおよび再送パケットを出すことを防ぐ事ができ、ネットワークの帯域を再送によって狭めることがない。また、データ受信端末が、パケットの送受信情報を随時記録し、パケットロス率の割り出しにより、ロス率が一定値以上になった場合、おなじNACK−RTCPパケットを複数回、重ねて送信することで、再送成功率を高めることが可能となる。
【0178】
[データ送受信端末装置構成例]
上述の実施例で述べた一連の処理は、ハードウェア、またはソフトウェア、あるいは両者の複合構成によって実行することが可能である。ソフトウェアによる処理を実行する場合は、処理シーケンスを記録したプログラムを、専用のハードウェアに組み込まれたデータ処理装置内のメモリにインストールして実行させるか、あるいは、各種処理が実行可能な汎用コンピュータにプログラムをインストールして実行させることが可能である。一連の処理をソフトウェアによって行う場合には、そのソフトウェアを構成するプログラムが、例えば汎用のコンピュータやマイクロコンピュータ等にインストールされる。
【0179】
図16に、上述の実施例で述べた一連の処理を実行するデータ送信端末装置、データ受信端末装置のシステム構成例を示す。本発明のシステムで送受信されるデータは、符号化データであり、データ送信装置ではエンコード(符号化)処理が実行され、データ受信装置ではデコード(復号)処理が実行される。符号化されたデータはパケットとしてネットワークを介して送受信する。そのため、データ送信側では、パケット生成(パケタイズ処理)を実行し、データ受信側ではパケット展開(デパケタイズ処理)を実行する。
【0180】
図16に示すデータ送受信装置(ex.PC)850は、エンコード(符号化)処理、デコード(復号)処理を実行するとともにパケット生成、展開処理を実行するコーデック851、通信ネットワークとのインタフェースとして機能するネットワークインタフェース852、マウス837、キーボード836等の入力機器との入出力インタフェース853、ビデオカメラ833、マイク834、スピーカ835等のAVデータ入出力機器からのデータ入出力を行なうAVインタフェース854、ディスプレイ832に対するデータ出力インタフェースとしてのディスプレイ・インタフェース855、各データ入出力インタフェース、コーデック851、ネットワークインタフェース852間のデータ転送制御、その他各種プログラム制御を実行するCPU856、CPU856により制御実行される各種プログラムの格納、データの格納、CPU856のワークエリアとして機能するRAM、ROMからなるメモリ857、データ格納、プログラム格納用の記憶媒体としてのHDD858を有し、それぞれPCIバス859に接続され、相互のデータ送受信が可能な構成を持つ。
【0181】
コーデック851は、図16に示すように、例えばビデオカメラ833からの画像データ、マイク834からの音声データを入力し、符号化処理、パケット生成処理(パケタイズ)を実行し、最終的に符号化データをペイロードとしたパケットを生成する。生成されたパケットは、PCIバス859上に出力され、ネットワークインタフェース852を介してネットワークに出力され、パケットのヘッダに設定された宛先アドレスに配信される。
【0182】
また、HDD858またはメモリ857に格納されたソフトウェアエンコードプログラムに従ってCPU856の制御により、ビデオカメラ833からの画像データ、マイク834からの音声データを符号化してネットワークインタフェース852を介してネットワークに出力する処理も実行する構成としてもよい。
【0183】
一方、ネットワークを介して入力するIPパケット化されたデータは、ネットワークインタフェース852を介して、バス856上に出力されて、コーデック851に入力される。コーデック851では入力データのパケット展開処理(デパケタイズ)を実行し、ペイロードとして格納された符号化データを抽出後、復号処理を実行して、ディスプレイ832、スピーカ835において再生、出力する。
【0184】
上述の実施例における処理対象となる画像等のデータは、カメラ他の入力機器、例えばスキャナ等のデータ入力装置、あるいはフロッピーディスク、CD−ROM(Compact Disc Read Only Memory),MO(Magneto optical)ディスク,DVD(Digital Versatile Disc)、磁気ディスク、半導体メモリなどのリムーバブル記録媒体から入力可能である。
【0185】
また、CPU856は、ROM格納プログラムに限らず、ハードディスクに格納されているプログラム、衛星若しくはネットワークから転送され、受信されてインストールされたプログラム等を、RAM(Random Access Memory)等のメモリにロードして実行することも可能である。
【0186】
ここで、本明細書において、プログラムは、1つのコンピュータにより処理されるものであっても良いし、複数のコンピュータによって分散処理されるものであっても良い。さらに、プログラムは、遠方のコンピュータに転送されて実行されるものであっても良い。
【0187】
以上、特定の実施例を参照しながら、本発明について詳解してきた。しかしながら、本発明の要旨を逸脱しない範囲で当業者が該実施例の修正や代用を成し得ることは自明である。すなわち、例示という形態で本発明を開示してきたのであり、限定的に解釈されるべきではない。本発明の要旨を判断するためには、冒頭に記載した特許請求の範囲の欄を参酌すべきである。
【0188】
【発明の効果】
以上、説明してきたように、本発明の構成によれば、ネットワーク監視部によって監視されている現在のネットワーク状況を踏まえてエラー訂正を制御することが可能であり、FECによるエラー制御あるいは再送要求処理(ARQ)に基づくエラー制御等の態様をネットワークにおけるパケット損失、エラー発生状況に応じて動的に変更してパケット転送を実行することが可能となる。監視データとして、パケットエラー率またはRFC1889で規定されているRTCPのRR(Reciever Report)でのパケットロス率等を取得し、送信側においてFECのエラー訂正強度をあげたり、またはFECを施さずARQ処理のみの対応とするなどの処理態様の制御が可能となる。
【0189】
また、本発明の構成によれば、ネットワーク監視部の監視により得られるネットワーク状況に基づいて、例えば、RTTが短いならば、ARQによる再送が可能となるためARQによるエラー訂正を選択して実行し、RTTが長く、再送する時間がないほど送信側から受信側に転送時間がかかるというネットワーク状況である場合には、ARQではなくFECによるエラー訂正を選択する、といった動的なエラー訂正制御が可能となる。
【0190】
また、これらのエラー制御態様は、伝送するデータ階層に応じた優先度に対応して選択的に設定可能となり、符号化データの階層レベルに応じて異なるエラー訂正処理を実行する構成とすることが可能である。例えば基本階層を、強めのFEC+ARQで優先度を上げた設定とし、音声データはFECのみの対応としたり、オーバーヘッドは極力避けたいのでFECなしでARQとして再送回数を例えば1回までといったように再送回数の制限数の設定等、自由な態様でのエラー制御態様を設定することができる。
【図面の簡単な説明】
【図1】本発明のデータ通信システムの構成を示す図である。
【図2】本発明のデータ通信システムの送信側端末、受信側端末の構成を示す図である。
【図3】データの階層化処理例としてのウェーブレット変換について説明する図である。
【図4】本発明のデータ通信システムの送信側端末で実行する優先度付け処理例について説明する図である。
【図5】本発明のデータ通信システムの送信側端末で実行する優先度付け処理に持ついるマップについて説明する図である。
【図6】本発明のデータ通信システムにおいて転送されるRTPパケットフォーマットを示す図である。
【図7】本発明のデータ通信システムにおいて転送されるIPパケットヘッダフォーマットを示す図である。
【図8】本発明のデータ通信システムにおけるデータ送信端末の処理フローを示す図である。
【図9】本発明のデータ通信システムにおいて転送されるNACK−RTCPパケットフォーマットを示す図である。
【図10】本発明のデータ通信システムにおいて転送されるNACK−RTCPパケットにおけるオプション値の機能について説明する図である。
【図11】本発明のデータ通信システムにおいて転送されるACK−RTCPパケットフォーマットを示す図である。
【図12】本発明のデータ通信システムにおいて転送されるECHO−RTCP、およびECHO−REPLY−RTCPパケットフォーマットを示す図である。
【図13】本発明のデータ通信システムにおいて転送されるEOS−RTCPパケットフォーマットを示す図である。
【図14】本発明のデータ通信システムにおけるデータ受信端末の処理フローを示す図である。
【図15】本発明のデータ通信システムにおけるデータ受信端末のECHO−RTCP、およびECHO−REPLY−RTCPパケットを適用したRTT計測処理フローを示す図である。
【図16】データ送信端末装置およびデータ受信端末装置のシステム構成例を示す図である。
【符号の説明】
101,115,123 CPU
102,116,124 ROM
103,117,125 RAM
104,118,126 表示装置
105,111,119 外部記憶装置
106,112,120 通信I/F
107,113,121 入力装置
108 インタフェース
109 カメラ
110 マイク
114,122 再生装置
132,133,134 伝送路
135 IPネットワーク
201 送信側端末
202 受信側端末
203 ビデオカメラ
204 エンコーダ
205 階層化部
206 優先度付け処理部
207 バッファ
208 FEC処理部
209 RTPパケット生成部
210 RTPポート
211 ビットレート制御部
212 階層エラー訂正優先度制御部
213 ARQ処理部
214 RTCPパケット生成部
215 ネットワーク監視部
216 RTCPパケット解析部
217 RTCPポート
218 TCP,RTCPポート
219 IPネットワーク
220 RTPポート
221 RTPパケット解析部
222 エラー監視部
223 バッファ
224 デコーダ
225 RTCPポート
226 RTCPパケット解析部
227 RTCPパケット生成部
228 TCP,RTCPポート
229 ネットワーク監視部
230 エラー訂正制御部
231 階層選択制御部
809 PCIバス
832 ディスプレイ
833 ビデオカメラ
834 マイク
835 スピーカ
837 マウス
838 キーボード
850 データ送受信装置
851 コーデック
852 ネットワークインタフェース
853 入出力インタフェース
854 AVインタフェース
855 ディスプレイインタフェース
856 CPU
857 メモリ
858 HDD

Claims (8)

  1. データ送信装置およびデータ受信装置からなり、画像データのストリーム型データ転送を実行するデータ通信システムであり、
    データ送信装置は、
    送信画像データの階層符号化処理を実行する階層符号化部と、
    前記送信画像データの元画像へのデータ損失による影響およびネットワークの損失率に基づき、前記階層符号化部において階層符号化された階層毎の優先度を設定する優先度付け処理部と、
    前記階層符号化部により階層符号化された前記送信画像データを格納した送信画像データパケットを送信するパケット送信処理部と、
    ネットワーク状況を監視するネットワーク状況監視部と、
    前記優先度付け処理部により前記階層毎に設定された優先度に従って、前記ネットワーク状況監視部の監視するネットワーク状況に基づき、前記送信画像データパケットのエラー制御処理態様を制御するとともに、前記階層符号化部における前記送信画像データの符号化態様を設定してビットレートを制御するデータ送信側制御部と、
    データ受信装置から受信する再送要求メッセージパケットに従って再送すべき送信画像データパケットの抽出処理を実行する再送制御部とを有し、
    前記優先度付け処理部は、
    前記ネットワーク状況監視部により検出されたネットワーク状況に応じて、前記階層毎の優先度を変更する構成であり、
    データ受信装置は、
    前記データ送信装置から受信する画像データパケットを受信するパケット受信処理部と、
    ネットワーク状況を監視するネットワーク状況監視部と、
    前記データ送信装置から受信する画像データパケットのエラーまたはパケットロスの検出を実行し、エラー対応処理を実行するエラー訂正制御部と、
    前記データ送信装置から受信する画像データパケットのエラーまたはパケットロスの検出に基づいて、前記データ送信装置に対する画像データパケット再送要求としての再送要求メッセージパケットの送信可否を判定する再送要求処理制御部と、
    前記ネットワーク状況監視部の監視結果に基づいて処理画像データの選択を実行する階層選択制御部とを有し、
    前記階層選択制御部は、
    前記ネットワーク状況監視部の解析結果に基づく処理画像データの選択を、前記階層符号化された画像データ毎に前記ネットワーク状況に応じて決定された前記優先度に従って実行する構成である、
    ことを特徴とするデータ通信システム。
  2. 送信画像データのストリーム型データ送信を実行するデータ送信装置であり、
    前記送信画像データの階層符号化処理を実行する階層符号化部と、
    前記送信画像データの元画像へのデータ損失による影響およびネットワークの損失率に基づき、前記階層符号化部において階層符号化された階層毎の優先度を設定する優先度付け処理部と、
    前記階層符号化部により階層符号化された前記送信画像データを格納した送信画像データパケットを送信するパケット送信処理部と、
    ネットワーク状況を監視するネットワーク状況監視部と、
    前記優先度付け処理部により前記階層毎に設定された優先度に従って、前記ネットワーク状況監視部の監視するネットワーク状況に基づき、前記送信画像データパケットのエラー制御処理態様を制御するとともに、前記階層符号化部における前記送信画像データの符号化態様を設定してビットレートを制御するデータ送信側制御部と、
    データ受信装置から受信する再送要求メッセージパケットに従って再送すべき送信画像データパケットの抽出処理を実行する再送制御部とを有し、
    前記優先度付け処理部は、
    前記ネットワーク状況監視部により検出されたネットワーク状況に応じて、前記階層毎の優先度を変更する構成であることを特徴とするデータ送信装置。
  3. 前記データ送信側制御部は、前記ネットワーク状況監視部の監視するネットワーク状況に基づいて、エラー制御方式としてのFEC(Forward Error Correction)の処理態様変更、またはデータ再送要求処理としてのARQ(Auto Repeat reQuest)処理態様の変更処理を実行する構成であることを特徴とする請求項2に記載のデータ送信装置。
  4. 前記ネットワーク状況監視部は、パケットロス率、伝送遅延時間、または前記データ受信装置からの再送要求に基づいてネットワーク状況解析を実行し、該解析結果を前記データ送信側制御部に出力し、前記データ送信側制御部は、該解析結果に基づいて、伝送パケットのエラー制御処理態様を制御する構成であることを特徴とする請求項2に記載のデータ送信装置。
  5. 前記データ送信装置において、
    前記データ送信側制御部は、前記ネットワーク状況監視部の監視するネットワーク状況に基づいて、エラー制御方式としてのFEC(Forward Error Correction)の処理態様変更、またはデータ再送要求処理としてのARQ(Auto Repeat reQuest)処理態様の変更処理を前記階層符号化部の設定した各階層の符号化送信画像データに対応して実行する構成であることを特徴とする請求項2に記載のデータ送信装置。
  6. 前記データ送信装置において、
    前記データ送信側制御部は、前記ネットワーク状況監視部の監視するネットワーク状況に基づいて、エラー制御方式としてのFEC(Forward Error Correction)の処理態様変更、またはデータ再送要求処理としてのARQ(Auto Repeat reQuest)処理態様の変更処理を前記優先度付け処理部の設定した各優先度に対応して実行する構成であることを特徴とする請求項2に記載のデータ送信装置。
  7. 送信画像データのストリーム型データ送信を実行するデータ送信方法であって、
    前記送信画像データの階層符号化処理を実行する階層符号化処理ステップと、
    前記送信画像データの元画像へのデータ損失による影響およびネットワークの損失率に基づき、前記階層符号化処理ステップにおいて階層符号化された階層毎の優先度を設定する優先度付け処理ステップと、
    前記階層符号化処理ステップにおいて階層符号化された前記送信画像データを格納した送信画像データパケットを送信するパケット送信処理ステップと、
    ネットワーク状況を監視するネットワーク状況監視ステップと、
    前記優先度付け処理ステップにおいて前記階層毎に設定された優先度に従って、前記ネットワーク状況監視ステップにおいて取得したネットワーク状況に基づき、前記送信画像データパケットのエラー制御処理態様を制御するとともに、前記階層符号化ステップにおける前記送信画像データの符号化態様を設定してビットレートを制御するデータ送信側制御ステップと、
    データ受信装置から受信する再送要求メッセージパケットに従って再送すべき送信画像データパケットの抽出処理を実行する再送制御ステップとを有し、
    前記優先度付け処理ステップは、
    前記ネットワーク状況監視ステップにおいて検出されたネットワーク状況に応じて、前記階層毎の優先度の変更処理を行うことを特徴とするデータ送信方法。
  8. 送信画像データのストリーム型データ送信を実行するコンピュータ・プログラムであって、
    前記送信画像データの階層符号化処理を実行する階層符号化処理ステップと、
    前記送信画像データの元画像へのデータ損失による影響およびネットワークの損失率に基づき、前記階層符号化処理ステップにおいて階層符号化された階層毎の優先度を設定する優先度付け処理ステップと、
    前記階層符号化処理ステップにおいて階層符号化された前記送信画像データを格納した送信画像データパケットを送信するパケット送信処理ステップと、
    ネットワーク状況を監視するネットワーク状況監視ステップと、
    前記優先度付け処理ステップにおいて前記階層毎に設定された優先度に従って、前記ネットワーク状況監視ステップにおいて取得したネットワーク状況に基づき、前記送信画像データパケットのエラー制御処理態様を制御するとともに、前記階層符号化ステップにおける前記送信画像データの符号化態様を設定してビットレートを制御するデータ送信側制御ステップと、
    データ受信装置から受信する再送要求メッセージパケットに従って再送すべき送信画像データパケットの抽出処理を実行する再送制御ステップとを有し、
    前記優先度付け処理ステップは、
    前記ネットワーク状況監視ステップにおいて検出されたネットワーク状況に応じて、前記階層毎の優先度の変更処理を行うステップであることを特徴とするコンピュータ・プログラム。
JP2001378808A 2001-12-12 2001-12-12 データ通信システム、データ送信装置、データ受信装置、および方法、並びにコンピュータ・プログラム Expired - Fee Related JP3757857B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2001378808A JP3757857B2 (ja) 2001-12-12 2001-12-12 データ通信システム、データ送信装置、データ受信装置、および方法、並びにコンピュータ・プログラム

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
JP2001378808A JP3757857B2 (ja) 2001-12-12 2001-12-12 データ通信システム、データ送信装置、データ受信装置、および方法、並びにコンピュータ・プログラム
KR20020078418A KR100987421B1 (ko) 2001-12-12 2002-12-10 데이터통신시스템, 데이터송신장치, 데이터수신장치, 데이터통신방법 및 컴퓨터가 판독가능한 기록 매체
US10/315,383 US7502818B2 (en) 2001-12-12 2002-12-10 Data communications system, data sender, data receiver, data communications method, and computer program

Publications (3)

Publication Number Publication Date
JP2003179580A JP2003179580A (ja) 2003-06-27
JP2003179580A5 JP2003179580A5 (ja) 2003-06-27
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)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2008020547A1 (en) 2006-08-17 2008-02-21 Sony Corporation Communication processing device, communication control method, and computer program
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 (146)

* Cited by examiner, † Cited by third party
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
US7916674B2 (en) * 2003-03-27 2011-03-29 Panasonic Corporation Method and apparatus for intermittent communication
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
KR100526183B1 (ko) 2003-07-15 2005-11-03 삼성전자주식회사 모바일 애드 혹 네트워크 환경에서 효율적인 데이터송수신을 위한 네트워크 장치 및 데이터 전송 방법
JP2005045409A (ja) * 2003-07-24 2005-02-17 Pioneer Electronic Corp 情報処理装置、そのシステム、その方法、そのプログラム、および、そのプログラムを記録した記録媒体
ES2532202T3 (es) * 2003-08-29 2015-03-25 Opentv, Inc. Sistema de difusión y recepción de contenido dirigido
FI20031260A (fi) * 2003-09-04 2005-03-05 Nokia Corp Median suoratoisto palvelimelta asiakaslaitteelle
JP4183586B2 (ja) * 2003-09-12 2008-11-19 三洋電機株式会社 映像表示装置
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 ソニー株式会社 受信装置および方法、プログラム、並びに記録媒体
JP4475235B2 (ja) * 2004-01-28 2010-06-09 日本電気株式会社 コンテンツの符号化、配信及び受信方法と装置とシステムならびにプログラム
JP4734233B2 (ja) * 2004-03-09 2011-07-27 パナソニック株式会社 送信方法及び送信装置
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
KR100916274B1 (ko) 2004-06-07 2009-09-10 슬링 미디어 인코퍼레이티드 퍼스널 미디어 브로드캐스팅 시스템
US9998802B2 (en) 2004-06-07 2018-06-12 Sling Media LLC Systems and methods for creating variable length clips from a media stream
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
JPWO2005122577A1 (ja) * 2004-06-14 2008-04-10 松下電器産業株式会社 コンテンツ利用方法およびコンテンツ記録装置
EP1775870A4 (en) * 2004-06-14 2012-11-07 Nec Corp Two-way communication method and device, system and program
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 乐金电子(昆山)电脑有限公司 移动终端客户端及识别并还原解码器错误运行的方法
JP4445012B2 (ja) 2005-03-25 2010-04-07 富士通株式会社 Packet distribution bandwidth control method, distribution apparatus, and video distribution system
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
US7747921B2 (en) * 2005-08-05 2010-06-29 Sony Corporation Systems and methods for transmitting data over lossy networks
EP1966917B1 (en) * 2005-09-07 2016-05-04 Vidyo, Inc. System and method for a conference server architecture for low delay and distributed conferencing applications
WO2007075196A1 (en) * 2005-09-07 2007-07-05 Vidyo, Inc. System and method for a high reliability base layer trunk
US7743152B2 (en) * 2005-10-31 2010-06-22 Qualcomm Incorporated Method and apparatus for detecting the presence of a terminal in a data session
JP4513725B2 (ja) * 2005-11-09 2010-07-28 ソニー株式会社 パケット送信装置、通信システム及びプログラム
WO2007061087A1 (ja) * 2005-11-28 2007-05-31 Nec Corporation 通信装置、通信システム、通信方法、および、通信プログラム
CN101371312B (zh) * 2005-12-08 2015-12-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 信号処理装置及び信号処理方法
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
CA2674710C (en) * 2007-01-09 2016-02-23 Vidyo, Inc. Improved systems and methods for error resilience 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
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
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
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
BRPI0822489B1 (pt) * 2008-03-12 2020-10-06 Telefonaktiebolaget Lm Ericsson (Publ) METHOD FOR ADAPTING A CURRENT TARGET RATE FROM A VIDEO SIGNAL TRANSMITTED FROM A VIDEO PROVIDER TO A VIDEO RECEIVER, DEVICE FOR CALCULATING A NEW TARGET RATE FROM A VIDEO SIGNAL TRANSMITTED FROM A VIDEO PROVIDER, AND THEREFORE COMPUTER
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
KR20110036754A (ko) * 2008-07-25 2011-04-08 노오텔 네트웍스 리미티드 멀티세그먼트 손실 방지
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 住友電気工業株式会社 動画像符号化データの表示方法、装置及び通信システム
JP6067378B2 (ja) * 2010-01-28 2017-01-25 トムソン ライセンシングThomson Licensing 再送決定する方法及び装置
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
WO2013005917A1 (ko) * 2011-07-06 2013-01-10 에스케이플래닛 주식회사 멀티캐스트 기반 컨텐츠 전송 시스템과 방법, 및 고속 움직임 추정을 위한 장치와 방법
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
FR2984059A1 (fr) * 2011-12-12 2013-06-14 France Telecom Procede et dispositif de restitution locale d'une video
FR2984060A1 (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 Adaptive forward 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> P2pネットワークサービスに用いる端末装置及びプログラム
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
JP5947631B2 (ja) * 2012-06-15 2016-07-06 三星電子株式会社Samsung Electronics Co.,Ltd. 受信装置及び受信装置用プログラム
JP2014003359A (ja) * 2012-06-15 2014-01-09 Samsung Electronics Co Ltd 映像データをストリーム型データ転送するために用いられるデータ転送システム及びデータ転送システムに用いられる送信装置、受信装置及びプログラム
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 腾讯科技(深圳)有限公司 一种视频直播控制方法、设备及系统
EP3493443B1 (en) 2013-12-06 2020-08-12 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
KR20160004628A (ko) * 2014-07-03 2016-01-13 삼성전자주식회사 멀티미디어 시스템에서 정보를 송수신하는 방법 및 장치
CN104159166B (zh) * 2014-08-07 2015-08-05 西安交通大学 基于移动网络丢包状态的直播视频数据传输差错控制方法
JP2016063422A (ja) * 2014-09-18 2016-04-25 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカPanasonic Intellectual Property Corporation of America デバイス、デバイス管理装置、中継装置、端末装置、および通信方法
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 中国移动通信集团四川有限公司 一种组播传输质量保障的控制方法及系统
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 华为技术有限公司 一种数据传输的方法以及相关设备
WO2017144645A1 (en) * 2016-02-26 2017-08-31 Net Insight Intellectual Property Ab Edge node control
CN107181968B (zh) 2016-03-11 2019-11-19 腾讯科技(深圳)有限公司 一种视频数据的冗余控制方法和装置
CN107888342B (zh) * 2016-09-30 2019-10-25 瞬已网络科技(上海)有限公司 一种网络实时视频传输方法及装置
KR102030460B1 (ko) * 2017-11-02 2019-10-10 현대오트론 주식회사 실시간 제공 장치 및 그 방법
CN109195024B (zh) * 2018-08-24 2019-07-26 深圳爱克莱特科技股份有限公司 一种基于流媒体技术的灯光控制系统数据处理系统
RU2710282C1 (ru) * 2019-04-24 2019-12-25 Федеральное государственное казенное военное образовательное учреждение высшего образования Академия Федеральной службы охраны Российской Федерации Способ передачи данных

Family Cites Families (16)

* Cited by examiner, † Cited by third party
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
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
JP3535767B2 (ja) * 1998-06-04 2004-06-07 積水化成品工業株式会社 難燃性の熱可塑性ポリエステル系樹脂発泡体、及びその製造方法
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 Ip通信のリアルタイムバックアップ通信方法
JP2001186193A (ja) * 1999-12-24 2001-07-06 Fujitsu I-Network Systems Ltd Ip通信インタフェース装置、回線交換機及びip通信ネットワークシステム
DE60020672T2 (de) * 2000-03-02 2005-11-10 Matsushita Electric Industrial Co., Ltd., Kadoma Verfahren und Vorrichtung zur Wiederholung der Videodatenrahmen mit Prioritätsstufen
US6888844B2 (en) * 2000-04-07 2005-05-03 Broadcom Corporation Method for selecting an operating mode for a frame-based communications network
CA2380008C (en) * 2000-05-22 2006-05-09 Min-Goo Kim Data transmission apparatus and method for an harq data communication system
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

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2008020547A1 (en) 2006-08-17 2008-02-21 Sony Corporation Communication processing device, communication control method, and computer program
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
JP2003179580A (ja) 2003-06-27
US20030126238A1 (en) 2003-07-03
KR20030051265A (ko) 2003-06-25
KR100987421B1 (ko) 2010-10-13
US7502818B2 (en) 2009-03-10

Similar Documents

Publication Publication Date Title
US10547656B2 (en) Multipath data streaming over multiple wireless networks
US10419502B2 (en) Systems and methods for using client-side video buffer occupancy for enhanced quality of experience in a communication network
US9917878B2 (en) Congestion induced video scaling
US10084831B2 (en) Method and apparatus for improving quality of multimedia streaming service
US8472520B2 (en) Systems and methods for transmitting and receiving data streams with feedback information over a lossy network
US9191664B2 (en) Adaptive bitrate management for streaming media over packet networks
US8306058B2 (en) Communication system and techniques for transmission from source to destination
US8769141B2 (en) Adaptive bitrate management for streaming media over packet networks
US7376880B2 (en) Transmission apparatus, transmission control program, and transmission method
US8935736B2 (en) Channel switching method, channel switching device, and channel switching system
EP1535419B1 (en) Method and devices for controlling retransmissions in data streaming
JP3590949B2 (ja) データ伝送装置およびデータ伝送方法
US8711884B2 (en) Data communication system, data transmitting apparatus, data transmitting method, and method for determining packet size and redundancy
US6789123B2 (en) System and method for delivery of dynamically scalable audio/video content over a network
US8018850B2 (en) Wireless video transmission system
JP3735067B2 (ja) Method and data transmission protocol for making data transmission more efficient
EP2532170B1 (en) Data flow control method and apparatus
US7505447B2 (en) Systems and methods for improved data throughput in communications networks
US7583666B2 (en) Protocol information processing system and method information processing device and method recording medium and program
CN1248456C (zh) 传输控制参数产生方法及根据分组特性选择性重发的方法
US6792470B2 (en) Method and apparatus for communicating with data frames having priority levels
EP1919117B1 (en) Packet retransmission control using priority information
DE60017356T2 (de) Datenübertragung über ein unzuverlässiges Netz
USRE46167E1 (en) Systems and methods for transmitting data over lossy networks
DE602004007329T2 (de) Zuverlässiges Multimedia Streaming mit wiederholten Übertragungen

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20040423

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

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 Written amendment

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 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20051011

A911 Transfer of reconsideration by examiner 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