JP2005175837A - 送信装置および方法、受信装置および方法、記録媒体、並びにプログラム - Google Patents

送信装置および方法、受信装置および方法、記録媒体、並びにプログラム Download PDF

Info

Publication number
JP2005175837A
JP2005175837A JP2003412459A JP2003412459A JP2005175837A JP 2005175837 A JP2005175837 A JP 2005175837A JP 2003412459 A JP2003412459 A JP 2003412459A JP 2003412459 A JP2003412459 A JP 2003412459A JP 2005175837 A JP2005175837 A JP 2005175837A
Authority
JP
Japan
Prior art keywords
packet
fec
error correction
packets
transmission
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
JP2003412459A
Other languages
English (en)
Other versions
JP4349114B2 (ja
Inventor
Kenji Yamane
健治 山根
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Sony Corp
Original Assignee
Sony Corp
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 Sony Corp filed Critical Sony Corp
Priority to JP2003412459A priority Critical patent/JP4349114B2/ja
Priority to US10/999,980 priority patent/US7539925B2/en
Priority to KR1020040103604A priority patent/KR20050056886A/ko
Priority to CNB2004101002744A priority patent/CN100377516C/zh
Publication of JP2005175837A publication Critical patent/JP2005175837A/ja
Application granted granted Critical
Publication of JP4349114B2 publication Critical patent/JP4349114B2/ja
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

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
    • H03—ELECTRONIC CIRCUITRY
    • H03M—CODING; DECODING; CODE CONVERSION IN GENERAL
    • H03M13/00—Coding, decoding or code conversion, for error detection or error correction; Coding theory basic assumptions; Coding bounds; Error probability evaluation methods; Channel models; Simulation or testing of codes
    • H03M13/27—Coding, decoding or code conversion, for error detection or error correction; Coding theory basic assumptions; Coding bounds; Error probability evaluation methods; Channel models; Simulation or testing of codes using interleaving techniques
    • H03M13/2703—Coding, decoding or code conversion, for error detection or error correction; Coding theory basic assumptions; Coding bounds; Error probability evaluation methods; Channel models; Simulation or testing of codes using interleaving techniques the interleaver involving at least two directions
    • H03M13/2707—Simple row-column interleaver, i.e. pure block interleaving
    • H—ELECTRICITY
    • H03—ELECTRONIC CIRCUITRY
    • H03M—CODING; DECODING; CODE CONVERSION IN GENERAL
    • H03M13/00—Coding, decoding or code conversion, for error detection or error correction; Coding theory basic assumptions; Coding bounds; Error probability evaluation methods; Channel models; Simulation or testing of codes
    • H03M13/29—Coding, decoding or code conversion, for error detection or error correction; Coding theory basic assumptions; Coding bounds; Error probability evaluation methods; Channel models; Simulation or testing of codes combining two or more codes or code structures, e.g. product codes, generalised product codes, concatenated codes, inner and outer codes
    • H03M13/2906—Coding, decoding or code conversion, for error detection or error correction; Coding theory basic assumptions; Coding bounds; Error probability evaluation methods; Channel models; Simulation or testing of codes combining two or more codes or code structures, e.g. product codes, generalised product codes, concatenated codes, inner and outer codes using block codes
    • H03M13/2909—Product codes
    • H03M13/2915—Product codes with an error detection code in one dimension
    • H—ELECTRICITY
    • H03—ELECTRONIC CIRCUITRY
    • H03M—CODING; DECODING; CODE CONVERSION IN GENERAL
    • H03M13/00—Coding, decoding or code conversion, for error detection or error correction; Coding theory basic assumptions; Coding bounds; Error probability evaluation methods; Channel models; Simulation or testing of codes
    • H03M13/35—Unequal or adaptive error protection, e.g. by providing a different level of protection according to significance of source information or by adapting the coding according to the change of transmission channel characteristics
    • H03M13/353—Adaptation to the channel
    • H—ELECTRICITY
    • H03—ELECTRONIC CIRCUITRY
    • H03M—CODING; DECODING; CODE CONVERSION IN GENERAL
    • H03M13/00—Coding, decoding or code conversion, for error detection or error correction; Coding theory basic assumptions; Coding bounds; Error probability evaluation methods; Channel models; Simulation or testing of codes
    • H03M13/63—Joint error correction and other techniques
    • H03M13/6306—Error control coding in combination with Automatic Repeat reQuest [ARQ] and diversity transmission, e.g. coding schemes for the multiple transmission of the same information or the transmission of incremental redundancy
    • 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
    • H04L1/0041—Arrangements at the transmitter end
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H—ELECTRICITY
    • H03—ELECTRONIC CIRCUITRY
    • H03M—CODING; DECODING; CODE CONVERSION IN GENERAL
    • H03M13/00—Coding, decoding or code conversion, for error detection or error correction; Coding theory basic assumptions; Coding bounds; Error probability evaluation methods; Channel models; Simulation or testing of codes
    • H03M13/03—Error detection or forward error correction by redundancy in data representation, i.e. code words containing more digits than the source words
    • H03M13/05—Error detection or forward error correction by redundancy in data representation, i.e. code words containing more digits than the source words using block codes, i.e. a predetermined number of check bits joined to a predetermined number of information bits
    • H03M13/09—Error detection only, e.g. using cyclic redundancy check [CRC] codes or single parity bit
    • H03M13/098—Error detection only, e.g. using cyclic redundancy check [CRC] codes or single parity bit using single parity bit
    • H—ELECTRICITY
    • H03—ELECTRONIC CIRCUITRY
    • H03M—CODING; DECODING; CODE CONVERSION IN GENERAL
    • H03M13/00—Coding, decoding or code conversion, for error detection or error correction; Coding theory basic assumptions; Coding bounds; Error probability evaluation methods; Channel models; Simulation or testing of codes
    • H03M13/03—Error detection or forward error correction by redundancy in data representation, i.e. code words containing more digits than the source words
    • H03M13/05—Error detection or forward error correction by redundancy in data representation, i.e. code words containing more digits than the source words using block codes, i.e. a predetermined number of check bits joined to a predetermined number of information bits
    • H03M13/13—Linear codes
    • H03M13/15—Cyclic codes, i.e. cyclic shifts of codewords produce other codewords, e.g. codes defined by a generator polynomial, Bose-Chaudhuri-Hocquenghem [BCH] codes
    • H03M13/151—Cyclic codes, i.e. cyclic shifts of codewords produce other codewords, e.g. codes defined by a generator polynomial, Bose-Chaudhuri-Hocquenghem [BCH] codes using error location or error correction polynomials
    • H03M13/1515—Reed-Solomon codes
    • H—ELECTRICITY
    • H03—ELECTRONIC CIRCUITRY
    • H03M—CODING; DECODING; CODE CONVERSION IN GENERAL
    • H03M13/00—Coding, decoding or code conversion, for error detection or error correction; Coding theory basic assumptions; Coding bounds; Error probability evaluation methods; Channel models; Simulation or testing of codes
    • H03M13/03—Error detection or forward error correction by redundancy in data representation, i.e. code words containing more digits than the source words
    • H03M13/05—Error detection or forward error correction by redundancy in data representation, i.e. code words containing more digits than the source words using block codes, i.e. a predetermined number of check bits joined to a predetermined number of information bits
    • H03M13/13—Linear codes
    • H03M13/15—Cyclic codes, i.e. cyclic shifts of codewords produce other codewords, e.g. codes defined by a generator polynomial, Bose-Chaudhuri-Hocquenghem [BCH] codes
    • H03M13/151—Cyclic codes, i.e. cyclic shifts of codewords produce other codewords, e.g. codes defined by a generator polynomial, Bose-Chaudhuri-Hocquenghem [BCH] codes using error location or error correction polynomials
    • H03M13/152—Bose-Chaudhuri-Hocquenghem [BCH] codes
    • H—ELECTRICITY
    • H03—ELECTRONIC CIRCUITRY
    • H03M—CODING; DECODING; CODE CONVERSION IN GENERAL
    • H03M13/00—Coding, decoding or code conversion, for error detection or error correction; Coding theory basic assumptions; Coding bounds; Error probability evaluation methods; Channel models; Simulation or testing of codes
    • H03M13/03—Error detection or forward error correction by redundancy in data representation, i.e. code words containing more digits than the source words
    • H03M13/05—Error detection or forward error correction by redundancy in data representation, i.e. code words containing more digits than the source words using block codes, i.e. a predetermined number of check bits joined to a predetermined number of information bits
    • H03M13/13—Linear codes
    • H03M13/19—Single error correction without using particular properties of the cyclic codes, e.g. Hamming codes, extended or generalised Hamming codes

Abstract

【課題】 通信網の状態に応じて、冗長データを含むデータの送信をより効率的に行う。
【解決手段】 輻輳／非輻輳判定部１０５は、通信網が輻輳状態であるか否かを判定する。FECパケット生成部８４は、送信パケットに格納されているストリーミングデータの誤りを訂正するための誤り訂正データが格納されている誤り訂正パケットを生成する。FEC送信制御部８６は、輻輳状態でない旨の判定結果から輻輳状態である旨の判定結果に変化した場合、誤り訂正パケットの数を変更するように、誤り訂正パケットの生成を制御する。本発明は、遠隔テレビ会議システムに適用できる。
【選択図】 図６

Description

本発明は送信装置および方法、受信装置および方法、記録媒体、並びにプログラムに関し、特に、通信網の状態に応じて、冗長データを含むデータの送信をより効率的に行うことができるようにした送信装置および方法、受信装置および方法、記録媒体、並びにプログラムに関する。
昨今、インターネットなど、種々の通信媒体を介して、画像データまたは音声データを伝送して提供するサービスが一般に行われている。特に、近年、ダウンロード型の伝送方式のサービスに加えて、ストリーム型の伝送方式のサービスがより多く提供されるようになってきた。
ストリーム型の伝送方式のサービスにおいては、送信装置が、データを順次送信し、受信装置が、送信装置から送信されてくるデータを受信するとともに、これに並行して、受信されたデータを基に画像または音声を再生する。ストリーム型の伝送方式は、インターネット電話、遠隔テレビ会議、またはビデオオンデマンドなどのインターネットサービスに利用されている。
ストリーム型の伝送方式において、送信装置から送信されてくるデータを、一般に、ストリーミングデータと称する。
しかしながら、インターネットなどのデータの到達が保証されない伝送路を介して、動画像または音声のストリーミングデータを伝送すると、伝送負荷の増大により、パケットロスが生じる場合がある。
パケットロスが生じると、受信側において、再生される動画像が乱れたり、音声が途切れたりしてしまう。
この問題を解決するために、ストリーミングデータと共に冗長データを送信し、受信側でロスしたパケットのエラーを訂正する方法が用いられている。その一例として、FEC（Forward Error Correction）方式がある。FEC方式においては、複数のパケットからなる集合に対して、冗長パケットを複数生成して、集合と共に冗長パケットが送信される。受信側においては、集合に属するパケットにパケットロスが生じた場合、冗長パケットを用いて、ロスしたパケットのエラーが訂正される。
例えば、図１で示されるように、送信側は、データパケット１−１乃至データパケット１−５の５つのパケットからなる集合に、FECパケット２−１およびFECパケット２−２の２つの冗長パケットを付加して、受信側に送信する。FECパケット２−１およびFECパケット２−２は、データパケット１−１乃至データパケット１−５の所定の組み合わせに対して排他的論理和（exclusive-OR）の演算を適用することにより生成される。
例えば、伝送路において、データパケット１−２がロスされた場合、受信側において、データパケット１−１とFECパケット２−１とに排他的論理和の演算が適用されることにより、データパケット１−２が復元される。
図１で示される例において、FECパケット２−１およびFECパケット２−２の数と同じ数のロスしたパケットのエラーを訂正することができる。すなわち、データパケット１−１乃至データパケット１−５のうち、１つまたは２つがロスされても、そのパケットを回復することができる。
FEC方式によって、１フレームの集合に対して、冗長データを生成することが考えられるが、冗長データの生成をソフトウェアで行うと、非常に負荷の高い処理になってしまうという問題がある。
図２は、データパケット１−１乃至データパケット１−５からなる集合、およびFECパケット２−１およびFECパケット２−２の冗長パケットの送信の順序を説明する図である。図２の横方向は、時間を示す。
データパケット１−１乃至データパケット１−５の集合、およびFECパケット２−１およびFECパケット２−２の冗長パケットの送信において、最初に、データパケット１−１乃至データパケット１−５が順に送信され、その後、FECパケット２−１およびFECパケット２−２が順に送信される。
図３は、従来のFECパケットを付加した送信の処理を説明するフローチャートである。ステップＳ１１において、送信装置は、内蔵しているタイマを初期化する。
ステップＳ１２において、送信装置は、タイマの値を基に、タイマが終了したか否かを判定し、タイマが終了していない場合、ステップＳ１２に戻り、タイマが終了するまで、判定の処理を繰り返す。
ステップＳ１２において、タイマが終了したと判定された場合、１つのフレームに対応する期間が経過したので、ステップＳ１３に進み、送信装置は、供給された画像データをキャプチャする。ステップＳ１４において、送信装置は、キャプチャされた画像データを、エンコード（符号化）する。
ステップＳ１５において、送信装置は、符号化された画像データを格納するデータパケットであるRTP（Real-time Transport Protocol）パケットを生成する。ステップＳ１６において、送信装置は、RTPパケットを相手に送信する。
ステップＳ１７において、送信装置は、RTPパケットを基に、FECパケットを生成する。
ステップＳ１８において、送信装置は、FECパケットを相手に送信する。
ステップＳ１９において、送信装置は、RTPパケットに付加するタイムスタンプを更新する。ステップＳ２０において、送信装置は、内蔵しているタイマをセットして、ステップＳ１２に戻り、上述した処理を繰り返す。
また、送信側では、各パケットの情報ブロックを、先行パケットおよび後続パケットの情報ブロックとの共通部分を持つように構成し、誤り訂正符号にて符号化して送信し、共通部分の大きさは伝送路状態に応じて変化させ、一方、受信側では、その情報ブロックを復号および誤り訂正符号の機能によって誤り訂正し、復号に失敗した場合には、情報ブロックの共通部分を先行パケットのものと置換して、この共通部分が置換された情報ブロックを、再度、復号および誤り訂正するようにしているものもある（特許文献１参照）。
さらに、パケット伝送において、ネットワーク監視部によって監視されるネットワーク状況に基づいてエラー訂正制御を行うシステムもある（特許文献２参照）。このシステムにおいては、FECによるエラー制御、再送要求処理（ARQ）に基づくエラー制御等の態様をネットワークにおけるパケット損失、エラー発生状況に応じて動的に変更してパケット転送を実行し、RTT（Round-Trip Time）が短いならば、ARQによるエラー訂正選択、RTTが長い状況である場合には、ARQではなくFECによるエラー訂正を選択するといった動的なエラー訂正制御が可能となる。
特開２０００−２２４２２６号公報
特開２００３−１７９５８０号公報
しかしながら、常にストリーミングデータと共に冗長パケットを送信すると、無駄なデータを送信してしまうことになる。
また、通信網において、パケットロスがどの程度発生しているかが分からないので、冗長パケットをいくつ送信してよいか分からないという問題があった。
本発明の送信装置は、通信網が輻輳状態であるか否かを判定する判定手段と、送信パケットに格納されているストリーミングデータの誤りを訂正するための誤り訂正データが格納されている誤り訂正パケットを生成する生成手段と、輻輳状態でない旨の判定結果から輻輳状態である旨の判定結果に変化した場合、誤り訂正パケットの数を変更するように、生成手段における誤り訂正パケットの生成を制御する制御手段とを備えることを特徴とする。
制御手段は、輻輳状態であると判定された場合、生成手段に所定の数の誤り訂正パケットを生成させ、輻輳状態でないと判定された場合、生成手段の誤り訂正パケットの生成を抑制するように、生成手段における誤り訂正パケットの生成を制御するようにすることができる。
制御手段は、輻輳状態でない旨の判定結果から輻輳状態である旨の判定結果に変化した場合、直前の輻輳状態における送信パケットの受信の状態を基に、誤り訂正パケットの数を変更するように、生成手段における誤り訂正パケットの生成を制御するようにすることができる。
制御手段は、所定の期間における１または複数の送信パケットからなる誤り訂正の単位であって、所定の期間における１または複数の誤り訂正の単位の受信状態を基に、所定の期間における１または複数の誤り訂正の単位のいずれかにおいて、誤り訂正パケットの数が不足している場合、誤り訂正パケットの数を増加させるように、生成手段における誤り訂正パケットの生成を制御するようにすることができる。
判定手段は、第１の時刻から現在時刻までの期間における送信パケットの相手への伝送に要する遅延時間に依存する短期依存遅延時間と、第１の時刻より過去の第２の時刻から現在時刻までの期間における遅延時間に依存する長期依存遅延時間とを基に、輻輳状態であるか否かを判定するようにすることができる。
本発明の送信方法は、通信網が輻輳状態であるか否かを判定する判定ステップと、送信パケットに格納されているストリーミングデータの誤りを訂正するための誤り訂正データが格納されている誤り訂正パケットを生成する生成ステップと、輻輳状態でない旨の判定結果から輻輳状態である旨の判定結果に変化した場合、誤り訂正パケットの数を変更するように、生成ステップにおける誤り訂正パケットの生成を制御する制御ステップとを含むことを特徴とする。
本発明の記録媒体のプログラムは、通信網が輻輳状態であるか否かを判定する判定ステップと、送信パケットに格納されているストリーミングデータの誤りを訂正するための誤り訂正データが格納されている誤り訂正パケットを生成する生成ステップと、輻輳状態でない旨の判定結果から輻輳状態である旨の判定結果に変化した場合、誤り訂正パケットの数を変更するように、生成ステップにおける誤り訂正パケットの生成を制御する制御ステップとを含むことを特徴とする。
本発明のプログラムは、通信網が輻輳状態であるか否かを判定する判定ステップと、送信パケットに格納されているストリーミングデータの誤りを訂正するための誤り訂正データが格納されている誤り訂正パケットを生成する生成ステップと、輻輳状態でない旨の判定結果から輻輳状態である旨の判定結果に変化した場合、誤り訂正パケットの数を変更するように、生成ステップにおける誤り訂正パケットの生成を制御する制御ステップとをコンピュータに実行させることを特徴とする。
送信装置は、独立した装置であってもよいし、通信装置の送信処理を行うブロックであってもよい。
本発明の受信装置は、送信パケットに格納されているストリーミングデータの誤りを訂正するための誤り訂正データが格納されている誤り訂正パケットを受信する受信制御手段と、受信された誤り訂正パケットの数が、ストリーミングデータの誤りを訂正するのに適正であるか否かを判定する判定手段とを備えることを特徴とする。
判定手段は、受信された誤り訂正パケットの数が、ストリーミングデータの誤りを訂正するのに不足であるか、適正であるか、および過多であるかの何れであるかを判定するようにすることができる。
判定手段は、１または複数の送信パケットからなる誤り訂正の単位ごとに、受信された誤り訂正パケットの数が、ストリーミングデータの誤りを訂正するのに不足であるか、適正であるか、および過多であるかの何れであるかを判定し、所定の期間における１または複数の誤り訂正の単位に対する判定結果を基に、所定の期間における１または複数の誤り訂正の単位のいずれかにおいて、誤り訂正パケットの数が不足していると判定された場合、相手への通知に誤り訂正パケットの数が不足している旨を設定する設定手段をさらに設けることができる。
受信装置は、判定結果に基づく通知を格納するフィードバックパケットを生成する生成手段と、生成手段によって、生成されたフィードバックパケットの相手への送信を制御する送信制御手段とをさらに設けることができる。
本発明の受信方法は、送信パケットに格納されているストリーミングデータの誤りを訂正するための誤り訂正データが格納されている誤り訂正パケットを受信する受信制御ステップと、受信制御ステップにおいて受信された誤り訂正パケットの数が、ストリーミングデータの誤りを訂正するのに適正であるか否かを判定する判定ステップとを含むことを特徴とする。
本発明の記録媒体のプログラムは、送信パケットに格納されているストリーミングデータの誤りを訂正するための誤り訂正データが格納されている誤り訂正パケットを受信する受信制御ステップと、受信制御ステップにおいて受信された誤り訂正パケットの数が、ストリーミングデータの誤りを訂正するのに適正であるか否かを判定する判定ステップとを含むことを特徴とする。
本発明のプログラムは、送信パケットに格納されているストリーミングデータの誤りを訂正するための誤り訂正データが格納されている誤り訂正パケットを受信する受信制御ステップと、受信制御ステップにおいて受信された誤り訂正パケットの数が、ストリーミングデータの誤りを訂正するのに適正であるか否かを判定する判定ステップとをコンピュータに実行させることを特徴とする。
受信装置は、独立した装置であってもよいし、通信装置の受信処理を行うブロックであってもよい。
本発明の送信装置および方法、記録媒体、並びにプログラムにおいては、通信網が輻輳状態であるか否かが判定され、送信パケットに格納されているストリーミングデータの誤りを訂正するための誤り訂正データが格納されている誤り訂正パケットが生成され、輻輳状態でない旨の判定結果から輻輳状態である旨の判定結果に変化した場合、誤り訂正パケットの数を変更するように、誤り訂正パケットの生成が制御される。
本発明の受信装置および方法、記録媒体、並びにプログラムにおいては、送信パケットに格納されているストリーミングデータの誤りを訂正するための誤り訂正データが格納されている誤り訂正パケットが受信され、受信された誤り訂正パケットの数が、ストリーミングデータの誤りを訂正するのに適正であるか否かが判定される。
第１の本発明によれば、誤り訂正のための冗長データを送信することができる。また、第１の本発明によれば、通信網の状態に応じて、冗長データを含むデータの送信をより効率的に行うことができる。
第２の本発明によれば、受信したデータの誤りを訂正することができる。また、第２の本発明によれば、送信側において、通信網の状態に応じて、冗長データを含むデータの送信をより効率的に行うことができる。
以下に本発明の実施の形態を説明するが、本明細書に記載の発明と、発明の実施の形態との対応関係を例示すると、次のようになる。この記載は、本明細書に記載されている発明をサポートする実施の形態が本明細書に記載されていることを確認するためのものである。従って、発明の実施の形態中には記載されているが、発明に対応するものとして、ここには記載されていない実施の形態があったとしても、そのことは、その実施の形態が、その発明に対応するものではないことを意味するものではない。逆に、実施の形態が発明に対応するものとしてここに記載されていたとしても、そのことは、その実施の形態が、その発明以外の発明には対応しないものであることを意味するものでもない。
さらに、この記載は、本明細書に記載されている発明の全てを意味するものではない。換言すれば、この記載は、本明細書に記載されている発明であって、この出願では請求されていない発明の存在、すなわち、将来、分割出願されたり、補正により出現、追加される発明の存在を否定するものではない。
本発明によれば、送信装置が提供される。この送信装置（例えば、図４のサーバ１２）は、通信網が輻輳状態であるか否かを判定する判定手段（例えば、図６の輻輳／非輻輳判定部１０５）と、送信パケット（例えば、図８のRTPパケット集合１８１−１）に格納されているストリーミングデータの誤りを訂正するための誤り訂正データが格納されている誤り訂正パケット（例えば、図８のFECパケット集合１８２−１）を生成する生成手段（例えば、図６のFECパケット生成部８４）と、輻輳状態でない旨の判定結果から輻輳状態である旨の判定結果に変化した場合、誤り訂正パケットの数を変更するように、生成手段における誤り訂正パケットの生成を制御する制御手段（例えば、図６のFEC送信制御部８６）とを備える。
この送信装置は、制御手段（例えば、図６のFEC送信制御部８６）が、輻輳状態であると判定された場合、生成手段（例えば、図６のFECパケット生成部８４）に所定の数の誤り訂正パケット（例えば、図８のFECパケット集合１８２−１）を生成させ、輻輳状態でないと判定された場合、生成手段の誤り訂正パケットの生成を抑制するように、生成手段における誤り訂正パケットの生成を制御するようにすることができる。
この送信装置は、制御手段（例えば、図６のFEC送信制御部８６）が、輻輳状態でない旨の判定結果から輻輳状態である旨の判定結果に変化した場合、直前の輻輳状態における送信パケットの受信の状態を基に、誤り訂正パケットの数を変更するように、生成手段（例えば、図６のFECパケット生成部８４）における誤り訂正パケットの生成を制御するようにすることができる。
この送信装置は、制御手段（例えば、図６のFEC送信制御部８６）が、所定の期間における１または複数の送信パケットからなる誤り訂正の単位（例えば、図８のFECブロック１７１−１）であって、所定の期間における１または複数の誤り訂正の単位の受信状態を基に、所定の期間における１または複数の誤り訂正の単位のいずれかにおいて、誤り訂正パケットの数が不足している場合、誤り訂正パケットの数を増加させるように、生成手段（例えば、図６のFECパケット生成部８４）における誤り訂正パケットの生成を制御するようにすることができる。
この送信装置は、判定手段（例えば、図６の輻輳／非輻輳判定部１０５）が、第１の時刻から現在時刻までの期間における送信パケットの相手への伝送に要する遅延時間に依存する短期依存遅延時間と、第１の時刻より過去の第２の時刻から現在時刻までの期間における遅延時間に依存する長期依存遅延時間とを基に、輻輳状態であるか否かを判定するようにすることができる。
また、本発明によれば、送信方法が提供される。この送信方法は、通信網が輻輳状態であるか否かを判定する判定ステップ（例えば、図１２のステップＳ８７の処理）と、送信パケットに格納されているストリーミングデータの誤りを訂正するための誤り訂正データが格納されている誤り訂正パケットを生成する生成ステップ（例えば、図１０のステップＳ５９の処理）と、輻輳状態でない旨の判定結果から輻輳状態である旨の判定結果に変化した場合、誤り訂正パケットの数を変更するように、生成ステップにおける誤り訂正パケットの生成を制御する制御ステップ（例えば、図１２のステップＳ９１の処理）とを含む。
また、本発明によれば、プログラムが提供される。このプログラムは、通信網が輻輳状態であるか否かを判定する判定ステップ（例えば、図１２のステップＳ８７の処理）と、送信パケットに格納されているストリーミングデータの誤りを訂正するための誤り訂正データが格納されている誤り訂正パケットを生成する生成ステップ（例えば、図１０のステップＳ５９の処理）と、輻輳状態でない旨の判定結果から輻輳状態である旨の判定結果に変化した場合、誤り訂正パケットの数を変更するように、生成ステップにおける誤り訂正パケットの生成を制御する制御ステップ（例えば、図１２のステップＳ９１の処理）とをコンピュータに実行させる。
このプログラムは、記録媒体（例えば、図５の磁気ディスク５１）に記録することができる。
本発明によれば、受信装置が提供される。この受信装置（例えば、図４のクライアント１４）は、送信パケット（例えば、図８のRTPパケット集合１８１−１）に格納されているストリーミングデータの誤りを訂正するための誤り訂正データが格納されている誤り訂正パケット（例えば、図８のFECパケット集合１８２−１）を受信する受信制御手段（例えば、図７の受信部１５２）と、受信された誤り訂正パケットの数が、ストリーミングデータの誤りを訂正するのに適正であるか否かを判定する判定手段（例えば、図７のFEC処理部１３５）とを備える。
この受信装置は、判定手段（例えば、図７のFEC処理部１３５）が、受信された誤り訂正パケットの数が、ストリーミングデータの誤りを訂正するのに不足であるか、適正であるか、および過多であるかの何れであるかを判定するようにすることができる。
この受信装置は、判定手段（例えば、図７のFEC処理部１３５）が、１または複数の送信パケットからなる誤り訂正の単位（例えば、図８のFECブロック１７１−１）ごとに、受信された誤り訂正パケット（例えば、図８のFECパケット集合１８２−１）の数が、ストリーミングデータの誤りを訂正するのに不足であるか、適正であるか、および過多であるかの何れであるかを判定し、所定の期間における１または複数の誤り訂正の単位に対する判定結果を基に、所定の期間における１または複数の誤り訂正の単位のいずれかにおいて、誤り訂正パケットの数が不足していると判定された場合、相手への通知に誤り訂正パケットの数が不足している旨を設定する設定手段（例えば、図７の通知FEC状態保持部１３７）を設けることができる。
この受信装置は、判定結果に基づく通知を格納するフィードバックパケットを生成する生成手段（例えば、図７のFECフィードバックパケット生成部１５３）と、生成手段によって、生成されたフィードバックパケットの相手への送信を制御する送信制御手段（例えば、図７の送信部１５１）とをさらに設けることができる。
また、本発明によれば、受信方法が提供される。この受信方法は、送信パケットに格納されているストリーミングデータの誤りを訂正するための誤り訂正データが格納されている誤り訂正パケットを受信する受信制御ステップ（例えば、図１８のステップＳ１７２の処理）と、受信制御ステップにおいて受信された誤り訂正パケットの数が、ストリーミングデータの誤りを訂正するのに適正であるか否かを判定する判定ステップ（例えば、図２２のステップＳ２２１の処理）とを含む。
また、本発明によれば、プログラムが提供される。このプログラムは、送信パケットに格納されているストリーミングデータの誤りを訂正するための誤り訂正データが格納されている誤り訂正パケットを受信する受信制御ステップ（例えば、図１８のステップＳ１７２の処理）と、受信制御ステップにおいて受信された誤り訂正パケットの数が、ストリーミングデータの誤りを訂正するのに適正であるか否かを判定する判定ステップ（例えば、図２２のステップＳ２２１の処理）とをコンピュータに実行させる。
このプログラムは、記録媒体（例えば、図５の磁気ディスク５１）に記録することができる。
本発明は、例えば、インターネット電話、遠隔テレビ会議システム、ライブ映像ストリーミング配信システム、またはテレビ電話などのリアルタイムにストリーミングデータを伝送する通信システムに適用できる。
図４は、本発明に係る通信システムの一実施の形態を示す図である。カメラ１１は、画像を撮像して、撮像した画像に対応する画像データをサーバ１２に供給する。例えば、カメラ１１は、動画像を撮像して、動画像に対応する画像データをサーバ１２に供給する。
画像データは、ストリーミングデータの一例である。ストリーミングデータは、音声のデータ、またはリアルタイム制御データなど、時間の経過に対応して順次送信または受信が要求されるデータであればよい。
サーバ１２は、カメラ１１から供給された画像データをパケットに格納して、パケットを通信網１３を介して、クライアント１４に送信する。サーバ１２は、画像を格納したパケットを訂正するための冗長データを生成して、冗長データを格納したパケットを通信網１３を介して、クライアント１４に送信する。
通信網１３は、有線または無線の、通信回線、ネットワーク、またはインターネットなどからなる伝送路であり、サーバ１２から送信されたパケットをクライアント１４まで伝送する。
クライアント１４は、通信網１３を介してサーバ１２から送信されてきた各種のパケットを受信する。
クライアント１４は、ストリーミングデータが格納されているパケットを正常に受信できなかった場合、冗長データを格納したパケットを基に、正常に受信できなかった画像データを格納するパケットのエラーを訂正する。
クライアント１４は、サーバ１２から通信網１３を介して送信されてきたパケットの受信状態をサーバ１２に通知する。サーバ１２は、通信網１３の伝送状態を取得する。例えば、サーバ１２は、往復遅延時間（RTT）を基に、通信網１３の輻輳状態を取得する。サーバ１２は、クライアント１４からの通知および通信網１３の伝送状態に基づいて、クライアント１４に送信する冗長データを格納したパケット数を変更する。
図５は、サーバ１２の構成の例を示すブロック図である。CPU（Central Processing Unit）３１は、ROM（Read Only Memory）３２、または記録部３８に記録されているプログラムに従って各種の処理を実行する。RAM（Random Access Memory）３３には、CPU３１が実行するプログラムやデータなどが適宜記憶される。これらのCPU３１、ROM３２、およびRAM３３は、バス３４により相互に接続されている。
CPU３１にはまた、バス３４を介して入出力インタフェース３５が接続されている。入出力インタフェース３５には、キーボード、マウス、スイッチなどよりなる入力部３６、ディスプレイ、スピーカ、ランプなどよりなる出力部３７が接続されている。CPU３１は、入力部３６から入力される指令に対応して各種の処理を実行する。
入出力インタフェース３５に接続されている記録部３８は、例えばハードディスクなどで構成され、CPU３１が実行するプログラムや各種のデータを記録する。通信部３９は、インターネット、その他のネットワークなどの通信網１３を介して、クライアント１４などの外部の装置と通信する。
また、通信部３９を介してプログラムを取得し、記録部３８に記録してもよい。
入出力インタフェース３５に接続されているドライブ４０は、磁気ディスク５１、光ディスク５２、光磁気ディスク５３、或いは半導体メモリ５４などが装着されたとき、それらを駆動し、そこに記録されているプログラムやデータなどを取得する。取得されたプログラムやデータは、必要に応じて記録部３８に転送され、記録される。
なお、クライアント１４は、サーバ１２と同様に構成されるので、その説明は省略する。
図６は、本発明に係るサーバ１２の一実施の形態の構成を示すブロック図である。
サーバ１２は、通信部３９、エンコーダ８１、バッファ８２、RTPパケット生成部８３、FECパケット生成部８４、RTT計測部８５、FEC送信制御部８６、FECパケット数増減状態保持部８７、FEC送信モード記憶部８８、およびFECパケット数保持部８９を含むように構成される。
エンコーダ８１は、カメラ１１から供給されたストリーミングデータの一例である画像データをエンコード（符号化）し、エンコードされた画像データをバッファ８２に供給する。
バッファ８２は、エンコーダ８１から供給された画像データを一時的に記憶する。
RTPパケット生成部８３は、バッファ８２からエンコードされた画像データを取得する。RTPパケット生成部８３は、取得した画像データをRTP方式のパケットに格納することにより、RTPパケットを生成し、生成したRTPパケットを通信部３９に供給する。
RTPパケットは、IETF RFC（Internet Engineering Task Force Request For Comments）１８８９で規定されているプロトコルであるRTPに基づく方式のパケットである。
また、RTPパケット生成部８３は、生成されたRTPパケットに格納されているRTPパケットのデータをFECパケット生成部８４に供給する。
FECパケット生成部８４は、FEC送信モード記憶部８８に記憶されているFEC送信モードフラグを参照し、FEC送信モードである場合、RTPパケット生成部８３から供給されたRTPパケットのデータを基に、所定の誤り訂正方式により、FECパケット数保持部８９から供給されたFECパケット数で示される数のFECパケットを生成する。FECパケット生成部８４は、生成したFECパケットを通信部３９に供給する。
FECパケット生成部８４は、FEC送信モードでない場合、FECパケットを生成しない。
通信部３９は、各種のパケットを送信する送信部１０１をよび各種のパケットを受信する受信部１０２を備えており、通信網１３を介してパケットの送受信を行う。
通信部３９の送信部１０１は、RTPパケット生成部８３から供給されたRTPパケットおよびFECパケット生成部８４から供給されたFECパケットを、通信網１３を介して、クライアント１４に送信する。
より詳細には、通信部３９の送信部１０１は、RTPパケット生成部８３から供給されたRTPパケットおよびFECパケット生成部８４から供給されたFECパケットを一時的に保持し、同一のFECブロックＩＤを含むRTPパケットおよびFECパケットを１つのFECブロックとして、例えば、バースト転送方式などの所定の方式により通信網１３を介して、クライアント１４に送信する。FECブロックを特定するFECブロックＩＤの詳細は後述する。
また、通信部３９の送信部１０１は、RTT計測部８５から供給されたRTT計測パケットを、通信網１３を介して、クライアント１４あてに送信する。
通信部３９の受信部１０２は、通信網１３を介して、クライアント１４から送信されてきたRTT計測パケットをRTT計測部８５に供給する。また、通信部３９の受信部１０２は、通信網１３を介して、クライアント１４から送信されてきたFECフィードバックパケットをFEC送信制御部８６に供給する。
RTT計測部８５は、RTT計測パケットを生成し、生成したRTT計測パケットを通信部３９に供給する。RTT計測部８５は、通信部３９に受信され、通信部３９から供給されたRTT計測パケットを基に、遅延時間（RTT）を計算する。
RTT計測部８５は、長期依存RTTを計算する長期依存RTT演算部１０３および短期依存RTTを計算する短期依存RTT演算部１０４を備えている。RTT計測部８５の長期依存RTT演算部１０３は、RTT計測部８５によって計算された遅延時間を基に、長期依存RTTを計算する。RTT計測部８５の短期依存RTT演算部１０４は、RTT計測部８５によって計算された遅延時間を基に、短期依存RTTを計算する。長期依存RTTおよび短期依存RTTの詳細は、後述する。
さらに、RTT計測部８５は、長期依存RTT演算部１０３によって計算された長期依存RTTおよび短期依存RTT演算部１０４によって計算された短期依存RTTをFEC送信制御部８６に供給する。
FEC送信制御部８６は、FECパケット生成部８４のFECパケットの生成を制御する。FEC送信制御部８６は、通信網１３が、輻輳状態であるか否かを判定する輻輳／非輻輳判定部１０５を備えている。
FEC送信制御部８６の輻輳／非輻輳判定部１０５は、RTT計測部８５から供給された長期依存RTTおよび短期依存RTTを基に、通信網１３が輻輳状態であるか否かを判定し、輻輳状態であるか否かの判定結果を記憶する。FEC送信制御部８６は、判定結果が、輻輳状態である旨の判定結果であった場合、FEC送信モード記憶部８８のFEC送信モードフラグをセットし（例えば、“１”を設定する）、輻輳状態でない旨の判定結果であった場合、すなわち非輻輳状態である旨の判定結果であった場合、FEC送信モード記憶部８８のFEC送信モードフラグをリセットする（例えば、“０”を設定する）。
また、FEC送信制御部８６は、通信部３９が受信し、通信部３９から供給されたFECフィードバックパケットを基に、FECパケット数増減状態保持部８７に保持されているFECパケット数増減状態を更新する。ここで、FECパケット数増減状態は、FECパケットの数を増加させるか、減少させるか、または維持するかを示す状態である。FECパケット数増減状態の変更の処理の詳細は、後述する。
さらに、FEC送信制御部８６は、FECパケット数増減状態保持部８７に保持されているFECパケット数増減状態を読み込み、FECパケット数保持部８９に保持されているFECパケット数を変更する。FECパケット数の変更の処理の詳細は、後述する。
FECパケット数増減状態保持部８７は、FEC送信制御部８６から供給されたFECパケット数増減状態を保持（記憶）する。
FEC送信モード記憶部８８は、FEC送信モードであるか否かを示すFEC送信モードフラグを記憶する。セットされている（例えば、“１”が設定されている）FEC送信モードフラグは、FEC送信モードであることを示し、リセットされている（例えば、“０”が設定されている）FEC送信モードフラグは、FEC送信モードでないことを示す。FEC送信モードである場合、FECパケット生成部８４は、FECパケットを生成し、FEC送信モードでない場合、FECパケット生成部８４は、FECパケットを生成しない。
FEC送信モード記憶部８８に記憶されているFEC送信モードフラグは、通信網１３が輻輳状態である場合、FEC送信制御部８６によって、セットされる。また、通信網１３が非輻輳状態である場合、FEC送信モード記憶部８８に記憶されているFEC送信モードフラグは、FEC送信制御部８６によって、リセットされる。
すなわち、通信網１３が輻輳状態である場合、FEC送信モードになるので、FECパケットが生成されて、FECパケットが送信され、通信網１３が輻輳状態でない場合、FEC送信モードではないので、FECパケットは生成されず、FECパケットは送信されない。
FECパケット数保持部８９は、FEC送信制御部８６から供給されたFECパケット数を保持する。FECパケット数保持部８９は、FEC送信制御部８６からFECパケット数を供給されると、供給されたFECパケット数をFECパケット生成部８４に供給する。
なお、FECパケット数増減状態保持部８７、FEC送信モード記憶部８８、およびFECパケット数保持部８９が、FECパケット生成部８４に含まれる構成とすることも可能である。
図７は、本発明に係るクライアント１４の一実施の形態の構成を示すブロック図である。
クライアント１４は、通信部１３１、RTP処理部１３２、バッファ１３３、デコーダ１３４、FEC処理部１３５、FECブロック情報保持部１３６、通知FEC状態保持部１３７、およびRTT計測部１３８を含むように構成される。
通信部１３１は、クライアント１４の通信部３９に対応し、パケットの受信を制御する受信部１５１およびパケットの送信を制御する送信部１５２を備えている。通信部１３１の受信部１５１は、通信網１３を介して送信されてきた各種のパケットを受信し、受信したパケットをRTP処理部１３２またはRTT計測部１３８に供給する。通信部１３１の送信部１５２は、通信網１３を介して、各種のパケットを送信する。
RTP処理部１３２は、通信部１３１に受信され、通信部１３１から供給されたRTPパケットおよびFECパケットを検査する。RTP処理部１３２は、正常なFECパケットが受信された場合、受信されたFECパケットをFEC処理部１３５に供給するとともに、FECヘッダ情報をFECブロック情報保持部１３６に供給する。RTP処理部１３２は、正常ではないFECパケットが受信された場合、受信されたFECパケットを破棄する。
また、RTP処理部１３２は、正常なRTPパケットが受信された場合、受信されたRTPパケットを一時的に保持すると共に、RTPヘッダ情報をFECブロック情報保持部１３６に供給する。RTP処理部１３２は、正常ではないRTPパケットが受信された場合、受信したRTPパケットに含まれるFECブロックＩＤと同一のFECブロックＩＤを含むFECパケットを受信したとき、正常ではないRTPパケットの復元を指示する信号をFEC処理部１３５に供給する。
RTP処理部１３２は、正常ではないRTPパケットが受信された場合、受信したRTPパケットに含まれるFECブロックＩＤと同一のFECブロックＩＤを含むFECパケットを受信していないとき、RTPパケットを破棄する。
RTP処理部１３２は、RTPパケットの復元を指示する信号をFEC処理部１３５に供給しなかった場合、パケットの受信が完了すると、一時的に保持しているRTPパケットをバッファ１３３に供給する。
また、RTP処理部１３２は、RTPパケットの復元を指示する信号をFEC処理部１３５に供給した場合、パケットの受信が完了し、FEC処理部１３５から復元されたRTPパケットが供給されてから、保持しているRTPパケットおよび復元されたRTPパケットをバッファ１３３に供給する。
さらに、RTP処理部１３２は、RTPパケットまたはFECパケットが正常に受信された場合、FECブロック情報保持部１３６に保持されているFECブロック情報であるFECブロック情報テーブルの受信パケット数をインクリメントする。RTP処理部１３６は、受信されたRTPパケットまたはFECパケットに含まれるFECブロックＩＤが変化した場合、FECブロック情報保持部１３６に保持されているFECブロック情報を更新する。FECブロック情報テーブルの詳細およびFECブロック情報更新の処理の詳細は後述する。
バッファ１３３は、RTP処理部１３２から供給されたRTPパケットを一時的に記憶する。
デコーダ１３４は、バッファ１３３に記憶されているRTPパケットを順に取得して、取得したRTPパケットから画像データを抽出する。そして、デコーダ１３４は、エンコーダ８１に対応する復号方式で、抽出された画像データをデコード（復号）して、デコードされた画像データを出力する。
FEC処理部１３５は、FECフィードバックパケットを生成するFECフィードバックパケット生成部１５３を備えている。
FEC処理部１３５は、RTP処理部１３２から供給されたFECパケットを一時的に保持する。FEC処理部１３５は、正常ではないRTPパケットの復元を指示する信号がRTP処理部１３２から供給された場合、FECパケットを基に、RTPパケットを復元し、復元したRTPパケットをRTP処理部１３２に供給する。
より具体的には、例えば、FEC処理部１３５は、RTP処理部１３２に一時的に記憶されている正常に受信されたRTPパケットであって復元の処理に要するRTPパケットをRTP処理部１３２から取得して、取得したRTPパケットおよびFECパケットを基に、正常に受信されなかったRTPパケットを復元する。
また、FEC処理部１３５は、正常ではないRTPパケットの復元を指示する信号がRTP処理部１３２から供給されなかった場合、パケットの受信が完了すると、保持しているFECパケットを破棄する。
なお、RTP処理部１３２がRTPパケットの復元を行うような構成としてもよい。
FEC処理部１３５は、FECブロック情報保持部１３６に保持されているFECブロック情報テーブルに記録されているFECブロックＩＤが変化した場合、FECブロック情報を基に、FECブロック情報保持部１３６に保持（記録）されている、FECパケットの数が適正であるか否かを示すFECブロック状態を更新する。FEC処理部１３５は、FECブロック情報保持部１３６に保持されているFECブロック情報を読み込み、通知FEC状態保持部１３７に保持されている通知FEC状態を更新する。FECブロック状態更新の処理および通知FEC状態更新の処理の詳細は後述する。
また、FEC処理部１３５のFECフィードバックパケット生成部１５３は、通知FEC状態保持部１３７に保持されている通知FEC状態を基に、FECフィードバックパケットを生成し、FEC処理部１３５は、生成されたFECフィードバックパケットを通信部１３１に供給する。FECフィードバックパケットの詳細は後述する。
FECブロック情報保持部１３６は、RTP処理部１３２およびFEC処理部１３５によって更新されるFECブロック情報を保持（記録）している。
通知FEC状態保持部１３７は、FEC処理部１３５によって更新される通知FEC状態を保持している。
RTT計測部１３８は、通信部１３１に受信され、通信部１３１から供給されたRTT計測パケットを取得する。RTT計測部１３８は、取得したRTT計測パケットのデータ部と同じデータ部を含むRTT計測パケットを生成し、生成したRTT計測パケットを通信部１３１に供給する。
なお、図６または図７で示されるサーバ１２またはクライアント１４の機能は、ハードウェアにより実現するようにしてもよく、ソフトウェア（プログラム）により実現するようにしてもよい。
次に、図８のタイムチャートを参照して、サーバ１２によるFECブロック送信の処理を説明する。
図８における横方向は、時間を示す。図８において、時刻ｔ１から時刻ｔ２までの期間D１および時刻ｔ３から時刻ｔ４までの期間D３は、通信網１３が輻輳状態である期間を示す。また、時刻ｔ２から時刻ｔ３までの期間D２は、通信網１３が非輻輳状態である期間を示す。
サーバ１２は、通信網１３が輻輳状態である場合、FECパケット集合を含むFECブロックを送信し、通信網１３が非輻輳状態である場合には、FECパケット集合を含まないFECブロックを送信する。さらに、サーバ１２は、通信網１３を介して、クライアント１４から受信したFECフィードバックパケットを基に、FECパケット集合に含まれるFECパケットの数を変更する。すなわち、時刻ｔ１１において、通信網１３が輻輳状態であるため、サーバ１２は、同一のFECブロックＩＤを含むRTPパケットおよびFECパケットを１つのFECブロックとしてクライアント１４あてに送信する。
より詳細に説明すれば、サーバ１２は、例えば、図８において、１つのフレームを再生するための画像データであるストリーミングデータをFECブロック１７１−１の４つのRTPパケットに格納する。また、サーバ１２は、そのフレームを再生するためのストリーミングデータの冗長データをFECブロック１７１−１の２つのFECパケットに格納する。そして、サーバ１２は、そのフレームを再生するためのストリーミングデータが格納された、４つのRTPパケットからなるRTPパケット集合１８１−１および２つのFECパケットからなるFECパケット集合１８２−１をFECブロック１７１−１として通信網１３を介してクライアント１４あてに送信する。
クライアント１４は、通信網１３を介して、サーバ１２から送信されてきたFECブロック１７１−１を時刻ｔ２１に受信する。
同様に、サーバ１２は、次の１つのフレームを再生するための画像データであるストリーミングデータをFECブロック１７１−２の４つのRTPパケットに格納する。また、サーバ１２は、そのフレームを再生するためのストリーミングデータの冗長データをFECブロック１７１−２の２つのFECパケットに格納する。そして、サーバ１２は、そのフレームを再生するためのストリーミングデータが格納された、４つのRTPパケットからなるRTPパケット集合１８１−２および２つのFECパケットからなるFECパケット集合１８２−２をFECブロック１７１−２として通信網１３を介してクライアント１４あてに送信する。
サーバ１２は、さらに次の１つのフレームを再生するための画像データであるストリーミングデータをFECブロック１７１−３の４つのRTPパケットに格納する。また、サーバ１２は、そのフレームを再生するためのストリーミングデータの冗長データをFECブロック１７１−３の２つのFECパケットに格納する。そして、サーバ１２は、そのフレームを再生するためのストリーミングデータが格納された、４つのRTPパケットからなるRTPパケット集合１８１−３および２つのFECパケットからなるFECパケット集合１８２−３をFECブロック１７１−３として通信網１３を介してクライアント１４あてに送信する。
時刻ｔ２において、通信網１３が輻輳状態から非輻輳状態に変化したので、時刻ｔ２以降において、サーバ１２は、通信網１３を介して、クライアント１４あてにFECパケットを含まないFECブロックを送信する。
サーバ１２は、FECブロック１７１−３のフレームの次の１つのフレームを再生するための画像データであるストリーミングデータをFECブロック１７１−４の４つのRTPパケットに格納し、４つのRTPパケットからなるRTPパケット集合１８１−４をFECブロック１７１−４として通信網１３を介してクライアント１４あてに送信する。サーバ１２は、さらに次の１つのフレームを再生するための画像データであるストリーミングデータをFECブロック１７１−５の４つのRTPパケットに格納し、４つのRTPパケットからなるRTPパケット集合１８１−５をFECブロック１７１−５として、通信網１３を介してクライアント１４あてに送信する。サーバ１２は、さらに次の１つのフレームを再生するための画像データであるストリーミングデータをFECブロック１７１−６の４つのRTPパケットに格納し、４つのRTPパケットからなるRTPパケット集合１８１−６をFECブロック１７１−６として、通信網１３を介してクライアント１４あてに送信する。
時刻ｔ３において、通信網１３が非輻輳状態から輻輳状態に変化したので、時刻ｔ３以降において、サーバ１２は、通信網１３を介して、ストリーミングデータとともに冗長データをクライアント１４あてに送信する。
すなわち、サーバ１２は、FECブロック１７１−６のフレームの次の１つのフレームを再生するための画像データであるストリーミングデータをFECブロック１７１−７の４つのRTPパケットに格納する。また、サーバ１２は、そのフレームを再生するためのストリーミングデータの冗長データをFECブロック１７１−７の２つのFECパケットに格納する。そして、サーバ１２は、そのフレームを再生するためのストリーミングデータが格納された、４つのRTPパケットからなるRTPパケット集合１８１−７および２つのFECパケットからなるFECパケット集合１８２−４をFECブロック１７１−７として通信網１３を介してクライアント１４あてに送信する。
時刻ｔ２１から時刻ｔ２３までの期間Ｔ１、時刻ｔ２３から時刻ｔ２４までの期間Ｔ２、時刻ｔ２４から時刻ｔ２５までの期間Ｔ３、および時刻ｔ２５から時刻ｔ２６までの期間Ｔ４のそれぞれは、クライアント１４におけるFECフィードバックパケット送信処理を実行する時間間隔であり、タイマで定まる。すなわち、クライアント１４は、タイマが終了する時刻である時刻ｔ２３、時刻ｔ２４、時刻ｔ２５、および時刻ｔ２６のそれぞれの時刻にFECフィードバックパケットを生成し、生成したFECフィードバックパケットを、通信網１３を介して、サーバ１２あてに送信する。
以下、FECブロック１７１−１乃至FECブロック１７１−７を個々に区別する必要がないとき、単にFECブロック１７１と称する。同様に、以下、RTPパケット集合１８１−１乃至RTPパケット集合１８１−７を個々に区別する必要がないとき、単にRTPパケット集合１８１と称し、FECパケット集合１８２−１乃至FECパケット集合１８２−４を個々に区別する必要がないとき、単にFECパケット集合１８２と称する。
クライアント１４は、通信網１３を介して、サーバ１２から送信されてきたFECブロック１７１を受信すると、FECブロック情報を記録する。FECブロック情報は、例えば、図９で示すFECブロック情報テーブルに記録される。
クライアント１４は、FECブロック１７１を受信すると、FECブロック１７１に固有の識別番号であるFECブロックＩＤ、FECブロック１７１に含まれるRTPパケットの数を示すオリジナルデータパケット数、FECブロック１７１に含まれるRTPパケット数およびFECパケット数の合計である総パケット数、正常に受信されたパケット数を示す受信パケット数、並びに受信されたFECパケットの数がロスパケットを復元する場合に、不足であるか、適正であるか、あるいは過多であるかを表すFECブロック状態をそれぞれFECブロック情報テーブルに記録する。
図９は、FECブロック情報テーブルの例を示す図である。
ここで、例えば、図９において、FECブロックＩＤ１のFECブロック１７１は、総パケット数が６であるのに対して、受信パケット数が４であり、２つのパケットをロスしている。また、FECブロックＩＤ１のFECブロック１７１の総パケット数が６であるのに対して、オリジナルパケット数は４であるから、FECブロックＩＤ１のFECブロック１７１には、２つのFECパケットが含まれることが分かる。
FECパケット１つにつきRTPパケット１つを復元できるので、FECブロックＩＤ１のFECブロック１７１に含まれる２つのFECパケットを用いることにより、２つのロスパケットを回復することができる。したがって、FECブロックＩＤ１に含まれるFECパケットの数は、過多でもなく、不足でもないので、FECブロック状態は、適正状態に設定される。
同様に、FECブロックＩＤ２のFECブロック１７１においては、FECブロック１７１に含まれるFECパケットが２つであるのに対して、ロスパケットは３つであるから、３つのロスパケットのうち、１つのロスパケットは回復することができない。すなわち、FECパケットが１つ不足しているので、FECブロック状態は、不足状態に設定される。
また、FECブロックＩＤ３のFECブロック１７１においては、FECブロック１７１に含まれるFECパケットが、２つであるのに対して、ロスパケットは０であるから、２つのFECパケットが用いられずに破棄されることになる。したがって、FECパケットが２つ過多であるので、FECブロック状態は、過多状態に設定される。
図８のタイムチャートの説明に戻り、例えば、時刻ｔ２２において、クライアント１４は、FECブロック１７１−２において３つのパケットのパケットロスを検知する。そして、クライアント１４は、FECブロック１７１−２のFECブロック状態を不足状態に設定する。時刻ｔ２３に期間Ｔ１が経過したので（タイマが終了したので）、クライアント１４は、時刻ｔ２１から時刻ｔ２３までに受信されたFECブロック１７１のそれぞれのFECブロック状態を基に、例えば、FECパケットが不足している旨のFECフィードバックパケットを生成し、生成されたFECフィードバックパケットを、通信網１３を介して、サーバ１２あてに送信する。FECフィードバックパケットの詳細は、後述する。
また、クライアント１４は、期間Ｔ２および期間Ｔ３のそれぞれの終了時刻ｔ２４および時刻ｔ２５のそれぞれにおいて、通信網１３を介して、サーバ１２あてにFECフィードバックパケットを送信する。
時刻ｔ３において、通信網１３が非輻輳状態から輻輳状態に変化したので、サーバ１２は、時刻ｔ１から時刻ｔ３までに、通信網１３を介して、クライアント１４から受信されたフィードバックパケットを基に、FECブロック１７１に含まれるFECパケットの数を変更し、例えば、時刻ｔ１２に３つのFECパケットが含まれるFECブロック１７１−７を、通信網１３を介して、クライアント１４あてに送信する。
このように、サーバ１２は、通信網１３における輻輳状態およびクライアント１４から送信されてきたFECフィードバックパケットを基に、FECブロック１７１に含まれるFECパケットの数を変更し、FECブロック１７１を送信する。
次に、図１０のフローチャートを参照して、サーバプログラムを実行するサーバ１２によるデータ送信の処理を説明する。
ステップＳ５１において、サーバ１２は、送信の処理に必要なデータを初期化する。例えば、ステップＳ５１において、エンコーダ８１は、内蔵しているタイマの値を0msにセットし、RTPパケット生成部８３は、タイムスタンプおよびシーケンス番号を初期化し、FECブロックＩＤの値を１に設定する。
ステップＳ５２において、エンコーダ８１は、内蔵しているタイマの値を基に、タイマが終了したか否かを判定し、タイマが終了していない場合、ステップＳ５２に戻り、タイマが終了したと判定されるまで、判定の処理を繰り返す。
ステップＳ５２において、タイマが終了したと判定された場合、処理はステップＳ５３に進む。
例えば、画像データのフレームの数が１秒当たり３０である場合、タイマが時間の経過に対応して値を増加させるとき、ステップＳ５２において、エンコーダ８１は、33msなどの所定の値とタイマの値を比較することによりタイマが終了したか否かを判定する。
例えば、ステップＳ５１において、タイマの値を33msにセットし、タイマの値が時間の経過に対応して値を減少させるとき、エンコーダ８１は、タイマの値と、0msとを比較することによりタイマが終了したか否かを判定する。
この場合における、タイマの値と比較される0msまたは33msは、フレームの数が１秒当たり３０である場合の例であり、本発明を限定するものではない。
以下に説明するタイマに関する処理において、同様である。
ステップＳ５３において、エンコーダ８１は、カメラ１１から供給された画像データを１フレーム分キャプチャする。例えば、ステップＳ５３において、エンコーダ８１は、カメラ１１から供給された画像データを順次取得して、取得した画像データのうち、１フレーム分をキャプチャする。
ステップＳ５４において、エンコーダ８１は、キャプチャされた画像データをエンコードする。例えば、ステップＳ５４において、エンコーダ８１は、キャプチャされた画像データをMPEG（Moving Picture Experts Group）１、２、４、７、もしくは２１、JPEG（Joint Photographic Experts Group）、JPEG２０００、またはモーションJPEGなどの方式によりエンコードする。
ステップＳ５５において、エンコーダ８１は、エンコードされた画像データをバッファ８２に供給して、バッファ８２にエンコードされた画像データを格納（記憶）させる。
ステップＳ５６において、RTPパケット生成部８３は、デコードされた画像データをバッファ８２から取得し、取得した画像データを格納するRTPパケットを生成する。
図１１は、RTPパケットを説明する図である。RTPパケットの先頭には、図１１において“Ｖ”で表される、２ビットのバージョン情報が配置される。バージョン情報は、RTPパケットのバージョンを示す。
バージョン情報の次に図１１中の“Ｐ”で表される１ビットのパディングが配置され、パディングに続いて、１ビットの拡張情報がRTPパケットに配置される。拡張情報は、図１１において、“Ｘ”で表される。拡張情報は、RTPパケットに拡張ヘッダを配置する場合に、所定の値に設定される。
拡張情報に続いて、CSRC（Contributing Source）カウントがRTPパケットに配置される。CSRCカウントは、図１１中において、“ＣＣ”で表される。CSRCカウントは、CSRC識別子の数を表す。
CSRCカウントに続いて配置される、１ビットのメーカー情報は、プロファイルによって定義される。メーカー情報は、図１１中において“ｍ”で表される。
メーカー情報に続いて配置される、７ビットのペイロードタイプは、RTPパケットのフォーマットを定義するための情報である。ペイロードタイプは、図１１中において、“ＰＴ”で表される。RTPパケットにおいて、ペイロードタイプは、３３とされる。
シーケンス番号は、ペイロードタイプの次に配置される、１６ビットの情報である。シーケンス番号は、RTPパケットの再生の順番を示す番号であり、送信の度に、１ずつ増える。
シーケンス番号の次に配置される、３２ビットのタイムスタンプは、そのRTPパケットに格納されているストリーミングデータの最初のオクテットがサンプルされた時刻を示す情報である。また、タイムスタンプにより、受信側においてRTPパケットの展開時に処理時間の制御が実行され、リアルタイム画像、または音声の再生制御を行うことが可能となる。タイムスタンプは、１つの画像フレームに属する複数のRTPパケットに共通のタイムスタンプが設定される。
SSRC（Synchronization Source）識別子は、タイムスタンプの次に配置される３２ビットの情報であって、RTPパケットに格納されるストリーミングデータのソースを示す。
RTPパケットにおいて、SSRC識別子の次には、FECブロックＩＤが配置される。FECブロックＩＤは、サーバ１２が通信網１３を介して、クライアント１４あてに送信するRTPパケットおよびFECパケットの集合であるFECブロック１７１を識別する番号である。例えば、図８において、RTPパケット集合１８１に属するRTPパケットには、同一のFECブロックＩＤが付与される。なお、１つのFECブロック１７１のFECパケット集合１８２に属するFECパケットには、そのFECブロック１７１のRTPパケット集合１８１に属するRTPパケットのFECブロックＩＤと同一のFECブロックＩＤが格納される。
FECブロックＩＤに続いて、総パケット数がRTPパケットに配置される。総パケット数は、図１１において“Ｎ”で表され、１つのFECブロック１７１に含まれるRTPパケット数およびFECパケット数の合計である。
RTPパケットにおいて、総パケット数の次には、オリジナルデータパケット数が配置される。オリジナルデータパケット数は、図１１において、“Ｋ”で表され、１つのFECブロック１７１に含まれるRTPパケットの数である。
オリジナルデータパケット数の次に、図１１中の“Ｒ”で表される冗長パケット数が配置される。冗長パケット数は、１つのFECブロックに含まれるFECパケットの数を表す。
冗長パケット数に続いて、データ量を調整するための、図１１中の“Ｐ”で表されるパディングが配置される。パディングに続いてストリーミングデータが格納される。図１１において、“Original Data”は、ストリーミングデータを示す。
なお、FECパケットは、RTPパケットと同様に構成することができる。この場合、FECパケットのペイロードタイプは、例えば、３４とされる。
図１０に戻り、ステップＳ５７において、RTPパケット生成部８３は、生成されたRTPパケットを通信部３９に供給し、通信部３９は、供給されたRTPパケットを、通信網１３を介してクライアント１４あてに送信する。
ステップＳ５８において、FECパケット生成部８４は、FEC送信モードであるか否かを判定する。例えば、ステップＳ５８において、FECパケット生成部８４は、FEC送信モード記憶部８８のFEC送信モードフラグのセットまたはリセットの設定を基に、FEC送信モードであるか否かを判定する。
ステップＳ５８において、FEC送信モードであると判定された場合、通信網１３は輻輳状態であるため、パケットロスが発生する可能性が高い。そこで、FECパケットをクライアント１４あてに送信するため、処理は、ステップＳ５９に進む。
ステップＳ５９において、FECパケット生成部８４は、RTPパケット生成部８３から供給されたRTPパケットのデータを基に、FECパケット数保持部８９から供給されたFECパケット数で示される数のFECパケットを生成する。
例えば、ステップＳ５９において、FECパケット生成部８４は、RTPパケット生成部８３から供給されたRTPパケットに格納されるデータに排他的論理和の演算を適用することにより、FECパケットのデータを生成し、生成したデータに所定のヘッダを付加することにより、FECパケットを生成する。
ここで、FECパケットに付加されるヘッダは、例えば、図１１で示されるRTPパケットのヘッダと同じフォーマットのヘッダが付加される。RTPパケットおよびFECパケットの識別は、FECパケットのヘッダにおいて、例えば、図１１中の“Ｘ”で表される拡張情報を１にすることで、RTPパケットおよびFECパケットが識別される。また、例えば、FECパケットにおいて、ペイロードタイプは、３４とされ、FECパケットにおいて、図１１中の“Original Data”で表される領域には、誤り訂正のための冗長データが格納される。
なお、FECパケット生成部８４によって生成されるFECパケットの誤り訂正方式（冗長データの方式）は、排他的論理和の演算によるものに限らず、例えば、ハミング符号などの線形符号、巡回符号、BCH（Bose‐Chaudhuri‐Hocquenghem）符号もしくはリードソロモン（Reed Solomon）符号などの代数的符号、または多数決論理符号などいずれの方式であってもよい。
ステップＳ６０において、FECパケット生成部８４は、生成されたFECパケットを通信部３９に供給し、通信部３９は、通信網１３を介して、供給されたFECパケットをクライアント１４あてに送信し、手続は、ステップＳ６１に進む。
より詳細には、通信部３９は、ステップＳ５７において、RTPパケット生成部８３から供給されたRTPパケットを一時的に保持する。そして、ステップＳ６０において、通信部３９は、保持しているRTPパケットに含まれるFECブロックＩＤと同一のFECブロックＩＤを含むFECパケットがFECパケット生成部８４から供給されると、保持しているRTPパケットおよびFECパケット生成部８４から供給されたFECパケットを１つのFECブロック１７１として、通信網１３を介して、クライアント１４あてに送信する。
例えば、図８の時刻ｔ１から時刻ｔ２において、サーバ１２は、通信網１３が輻輳状態（FECパケット送信モード）であるので、RTPパケットとともにFECパケットを、通信網１３を介して、クライアント１４あてに送信する。
一方、ステップＳ５８において、FEC送信モードでないと判定された場合、通信網１３は、非輻輳状態であるため、パケットロスが発生する可能性は低い。そこで、FECパケットのクライアント１４への送信を抑制するため、ステップＳ５９およびステップＳ６０の処理はスキップされ、手続は、ステップＳ６１に進む。
なお、ステップＳ５８において、FEC送信モードでないと判定された場合、FECパケットの送信は、抑制されるので、通信部３９は、ステップＳ５７において、RTPパケット生成部８３から供給されたRTPパケットを１つのFECブロック１７１として、通信網１３を介して、クライアント１４あてに送信する。
例えば、図８の時刻ｔ２から時刻ｔ３において、サーバ１２は、通信網１３が非輻輳状態であるので、RTPパケット集合１８１を１つのFECブロック１７１として、通信網１３を介して、クライアント１４あてに送信する。換言すれば、サーバ１２は、FECパケット送信モードでないので、FECパケットのクライアント１４への送信を抑制する。
ステップＳ６１において、RTPパケット生成部８３は、FECブロックＩＤを更新する。例えば、ステップＳ６１において、RTPパケット生成部８３は、パケットに格納されるFECブロックＩＤをインクリメントする。
ステップＳ６２において、RTPパケット生成部８３は、タイムスタンプを更新する。
なお、FECパケット生成部８４は、RTPパケット生成部８３から供給されるRTPヘッダ情報に含まれるFECブロックＩＤおよびタイムスタンプを基に、FECパケットを生成するようにしてもよく、自分自身が、RTPタイムスタンプおよびFECブロックＩＤを保持し、更新するようにしてもよい。
ステップＳ６３において、エンコーダ８１は、内蔵しているタイマをセットして、ステップＳ５２に戻り、データ送信の処理を繰り返す。
例えば、ステップＳ６３において、エンコーダ８１は、タイマの値を0msにセットする。
このようにして、サーバ１２は、FECブロック１７１ごとにFECブロックＩＤを付加し、通信網１３が輻輳状態の場合、通信網１３を介して、RTPパケットおよびFECパケットをクライアント１４あてに送信し、通信網１３が非輻輳状態の場合、通信網１３を介して、RTPパケットをクライアント１４あてに送信し、FECパケットの送信は抑制する。
図１２のフローチャートを参照して、サーバプログラムを実行するサーバ１２によるFECパケットの送信の制御の処理を説明する。
ステップＳ８１において、サーバ１２は、FECパケットの送信の制御の処理に必要なデータを初期化する。例えば、ステップＳ８１において、RTT計測部８５は、内蔵しているタイマの値を0msにセットする。
ステップＳ８２において、FEC送信制御部８６は、FECフィードバックパケットを受信したか否かを判定し、FECフィードバックパケットを受信したと判定された場合、ステップＳ８３に進み、FEC送信制御部８６は、FECパケット数増減状態の更新の処理を行い、FECパケット数増減状態保持部８７に保持されているFECパケット数増減状態を更新する。FECパケット数増減状態の更新の処理が終了すると、ステップＳ８２に戻り、FECパケットの送信の制御の処理を繰り返す。
なお、FECパケット数増減状態の更新の処理の詳細は後述する。
一方、ステップＳ８２において、FECフィードバックパケットが受信されなかったと判定された場合、ステップＳ８４に進み、RTT計測部８５は、RTT計測パケットを受信したか否かを判定する。
ステップＳ８４において、RTT計測パケットが受信されたと判定された場合、ステップＳ８５に進み、RTT計測部８５は、受信されたRTT計測パケットを基に、遅延時間（RTT）を計算する。そして、計算された遅延時間を基に、RTT計測部８５の長期依存RTT演算部１０３は、長期依存RTTを計算し、RTT計測部８５の短期依存RTT演算部１０４は、短期依存RTTを計算する。RTT計測部８５は、計算された長期依存RTTおよび短期依存RTTをFEC送信制御部８６の輻輳／非輻輳判定部１０５に供給する。
例えば、ステップＳ８５において、RTT計測部８５は、式（１）により遅延時間を計算する。
遅延時間＝
（RTT計測パケットの受信時刻）−（RTT計測パケットの送信時刻） ・・・（１）
ここで、RTT計測パケットの受信時刻は、RTT計測部８５がRTT計測パケットを受信したときに、内蔵しているRTC（Real Time Clock）から取得した時刻である。また、RTT計測パケットの送信時刻は、受信されたRTT計測パケットに格納されているRTT計測パケットの送信時刻である。
また、例えば、ステップＳ８５において、RTT計測部８５の長期依存RTT演算部１０３は、式（２）により長期依存RTTを計算する。
長期依存RTT＝
０．９×（前回計算された長期依存RTT）＋０．１×（遅延時間） ・・・（２）
ここで、前回計算された長期依存RTTは、前回のステップＳ８５の処理により計算された長期依存RTTである。また、遅延時間は、RTT計測部８５により計算された遅延時間である。
また、例えば、ステップＳ８５において、RTT計測部８５の短期依存RTT演算部１０４は、式（３）により短期依存RTTを計算する。
短期依存RTT＝
０．５×（前回計算された短期依存RTT）＋０．５×（遅延時間） ・・・（３）
ここで、前回計算された短期依存RTTは、前回のステップＳ８５の処理により計算された短期依存RTTである。また、遅延時間は、RTT計測部８５により計算された遅延時間である。
例えば、RTT計測部８５の長期依存RTT演算部１０３および短期依存RTT演算部１０４は、それぞれステップＳ８５の処理において、計算された長期依存RTTおよび短期依存RTTを記憶し、次回のステップＳ８５の処理において、記憶されている長期依存RTTおよび短期依存RTTを利用することにより、次の長期依存RTTおよび短期依存RTTを計算する。
なお、長期依存RTTは、例えば、５秒間の平均遅延時間としてもよい。また、短期依存RTTは、例えば、１秒間の平均遅延時間としてもよい。
ステップＳ８６において、FEC送信制御部８６の輻輳／非輻輳判定部１０５は、RTT計測部８５から供給された長期依存RTTと短期依存RTTとを比較する。
例えば、ステップＳ８６において、輻輳／非輻輳判定部１０５は、RTT計測部８５から供給された長期依存RTTおよび短期依存RTTを基に、式（４）で示す計算をすることによって、長期依存RTTと短期依存RTTとを比較する。
（短期依存RTT）／（長期依存RTT）＞１ ・・・（４）
ステップＳ８７において、輻輳／非輻輳判定部１０５は、ステップＳ８６において計算された式（４）の計算結果を基に、通信網１３が輻輳状態であるか否かを判定する。
例えば、ステップＳ８７において、輻輳／非輻輳判定部１０５は、RTT計測部８５から供給された長期依存RTTおよび短期依存RTTが式（４）を満たす場合、通信網１３が輻輳状態であると判定し、RTT計測部８５から供給された長期依存RTTおよび短期依存RTTが式（４）を満たさない場合、通信網１３が輻輳状態でないと判定する。
ここで、輻輳状態とは、通信網１３のトラフィックが増加して、パケットの伝送に支障が生ずる状態をいう。例えば、輻輳状態においては、正常にパケットの伝送ができなくなる場合がある。輻輳状態であるか否かの通信網１３の状態は、例えば、通信網１３のノードにおけるバッファのキュー長によって示すことができる。例えば、ノードにおけるバッファのキュー長が長い場合、伝送されずに伝送を待機しているパケットが多いので、通信網１３は込みあっているといえる。逆に、ノードにおけるキュー長が短い場合、伝送を待機するパケットが少ないので、通信網１３は込んでいないと言える。
例えば、バッファのキュー長に対して、所定の閾値を設け、バッファにおけるキュー長が閾値よりも大きい場合、輻輳状態であると判定し、バッファにおけるキュー長が閾値よりも小さい場合、非輻輳状態であると判定することができる。
通信網１３におけるノードのキュー長は、例えば、SNMP（Simple Network Management Protocol）などを用いて観測することができる。
本出願人が、ノードにおけるキュー長、長期依存RTT、および短期依存RTTの測定を行った結果、ノードにおけるキュー長、長期依存RTT、および短期依存RTTの間には、一定の関係が満たされることが認められた。
図１３は、ノードにおけるキュー長、長期依存RTT、および短期依存RTTの関係を説明する図である。
図１３において、横方向は、時間を示す。図１３において、実線は、長期依存RTTを表し、点線は、短期依存RTTを表し、一点鎖線は、ノードにおけるキュー長を表す。
図１３で示すように、短期依存RTTが長期依存RTTより大きい状態から、長期依存RTTが短期依存RTTより大きい状態に変化したとき、ノードにおけるキュー長が、急激に小さくなっていることが分かる。例えば、図１３の時刻ｔ５２において、短期依存RTTが長期依存RTTより大きい状態から、長期依存RTTが短期依存RTTより大きい状態に変化し、ノードにおけるキュー長が急激に小さくなっていることが分かる。
逆に短期依存RTTが長期依存RTTより小さい状態から、短期依存RTTが長期依存RTTより大きい状態に変化したとき、ノードにおけるキュー長が大きくなっていることが分かる。例えば、図１３の時刻ｔ５３において、短期依存RTTが長期依存RTTより小さい状態から、短期依存RTTが長期依存RTTより大きい状態に変化したとき、ノードにおけるキュー長が大きくなっていることが分かる。
したがって、短期依存RTTが長期依存RTTより大きいか否かで、通信網１３が輻輳状態であるか否かを判定することができる。換言すれば、長期依存RTTおよび短期依存RTTによって式（４）が満たされる場合、通信網１３は輻輳状態であると判定し、式（４）が満たされない場合、通信網１３は、非輻輳状態であると判定することができる。
例えば、図１３において、時刻ｔ５１から時刻ｔ５２までの期間は、通信網１３が輻輳状態であると判定し、時刻ｔ５２から時刻ｔ５３までの期間は、通信網１３が非輻輳状態であると判定することができる。
図１２のフローチャートに戻り、ステップＳ８７において、通信網１３が輻輳状態であると判定された場合、ステップＳ８８に進み、輻輳／非輻輳判定部１０５は、通信網１３が輻輳状態である旨を輻輳／非輻輳状態として記憶し、FEC送信制御部８６に通信網１３が輻輳状態である旨の信号を供給する。
なお、ステップＳ８７における判定の処理は、長期依存RTTおよび短期依存RTTに基づくものに限らず、例えば、通信網１３のトラフィック状態を観測するSNMP、ジッタ、あるいはパケットのロス率などを用いて、輻輳状態であるか否かを判定するようにしてもよい。
ステップＳ８９において、FEC送信制御部８６は、輻輳／非輻輳判定部１０５から通信網１３が輻輳状態である旨の信号を取得すると、FEC送信モード記憶部８８に記憶されているFEC送信モードフラグをセットする。
ここで、FEC送信モードとは、FECパケットを送信するモードである。すなわち、FEC送信制御部８６は、ステップＳ８７において、通信網１３が輻輳状態であると判定された場合、FEC送信モード記憶部８８に記憶されているFEC送信モードフラグをセットすることにより、FEC送信モードとされ、FECブロック１７１の送信において、FECパケットが送信される。
ステップＳ９０において、FEC送信制御部８６は、通信網１３が非輻輳状態から輻輳状態に変化したか否かを判定する。
例えば、ステップＳ９０において、FEC送信制御部８６は、輻輳／非輻輳判定部１０５に記憶されている輻輳／非輻輳状態を参照することにより、通信網１３が非輻輳状態から輻輳状態に変化したか否かを判定する。
また、例えば、ステップＳ９０において、FEC送信制御部８６は、FEC送信モード記憶部８８に記憶されているFEC送信モードフラグを基に、通信網１３が非輻輳状態から輻輳状態に変化したか否かを判定するようにしてもよい。
ステップＳ９０において、非輻輳状態から輻輳状態に変化したと判定された場合、ステップＳ９１に進み、FEC送信制御部８６は、ステップＳ８３の処理によって更新され、FECパケット数増減状態保持部８７に保持されているFECパケット数増減状態を読み出す。
例えば、FECパケット数増減状態保持部８７には、FECパケット数増減状態としての増加状態、維持状態、および削減状態の３つの状態のうち、いずれかの状態が保持されている。すなわち、増加状態は、サーバ１２が、通信網１３を介して、クライアント１４あてに送信するFECブロック１７１に含まれるFECパケットの数を増加させることを表し、維持状態は、サーバ１２が、通信網１３を介して、クライアント１４あてに送信するFECブロック１７１に含まれるFECパケットの数を維持させる（変化させない）ことを表し、削減状態は、サーバ１２が、通信網１３を介して、クライアント１４あてに送信するFECブロック１７１に含まれるFECパケットの数を削減させることを表す。
なお、FECパケット数増減状態保持部８７に保持されているFECパケット数増減状態は、通信網１３を介して、クライアント１４からFECフィードバックパケットを受信する度に更新される。
ステップＳ９２において、FEC送信制御部８６は、読み出したFECパケット数増減状態を基に、FECパケット数変更の処理を行う。FECパケット数変更の処理の詳細は後述する。
ここで、FECパケット数とは、サーバ１２が、通信網１３を介して、クライアント１４あてに送信する１つのFECブロック１７１に含まれるFECパケットの数である。例えば、図８において、時刻ｔ１から時刻ｔ２までの期間におけるサーバ１２のFECパケット数は、２である。
ステップＳ９３において、FEC送信制御部８６は、FECパケット数増減状態保持部８７に保持されているFECパケット数状態を初期化し、処理は、ステップＳ８２に戻り、FECパケットの送信の制御の処理を繰り返す。
例えば、ステップＳ９３において、FEC送信制御部８６は、FECパケット数増減状態保持部８７に保持されているFECパケット数増減状態に維持状態を設定することによりFECパケット数状態を初期化する。
一方、ステップＳ９０において、非輻輳状態から輻輳状態に変化したと判定されなかった場合、ステップＳ９１乃至ステップＳ９３の処理はスキップされ、処理はステップＳ８２に戻り、FECパケットの送信の制御の処理を繰り返す。
また、ステップＳ８７において、通信網１３が輻輳状態でないと判定された場合、ステップＳ９４に進み、輻輳／非輻輳判定部１０５は、通信網１３が非輻輳状態である旨を輻輳／非輻輳状態として記憶し、FEC送信制御部８６に通信網１３が非輻輳状態である旨の信号を供給する。
ステップＳ９５において、FEC送信制御部８６は、輻輳／非輻輳判定部１０５から通信網１３が非輻輳状態である旨の信号を取得すると、FEC送信モード記憶部８８に記憶されているFEC送信モードフラグをリセットする。FEC送信モード記憶部８８のFEC送信モードフラグがリセットされることにより、FEC送信モードではなくなり、FECブロック１７１の送信において、FECパケットは送信されなくなる。
FEC送信制御部８６がFEC送信モードフラグをリセットすると、処理は、ステップＳ８２に戻り、FECパケットの送信の制御の処理を繰り返す。
ステップＳ８４において、RTT計測部８５がRTT計測パケットを受信しなかったと判定された場合、ステップＳ９６に進み、RTT計測部８５は、内蔵しているタイマが終了したか否かを判定する。
例えば、ステップＳ９６において、RTT計測部８５は、タイマの値と10sなどの所定の値とを比較することによって、タイマが終了したか否かを判定する。
ステップＳ９６において、タイマが終了していないと判定された場合、ステップＳ８２に戻り、FECパケットの送信の制御の処理を繰り返す。
一方、ステップＳ９６において、タイマが終了したと判定された場合、ステップＳ９７に進み、RTT計測部８５は、RTT計測パケットを生成し、生成したRTT計測パケットを、通信網１３を介して、クライアント１４あてに送信する。
例えば、ステップＳ９７において、RTT計測部８５は、内蔵しているRTCから現在時刻を取得し、図１４で示されるRTT計測パケットを生成する。
図１４は、RTT計測パケットを説明する図である。バージョン情報、パディング、およびSSRCは、図で示されるRTPパケットの場合と同様であるので、その説明は、省略する。
RTT計測パケットにおいて、パディングに続いて５ビットのサブタイプが配置される。
RTT計測パケットにおいて、ペイロードタイプは２０５とされる。ペイロードタイプの次に配置される、１６ビットのメッセージ長は、RTT計測パケットの長さ（サイズ）を示す情報である。
３２ビットのSSRCに続いて、３２ビットの名前が配置される。名前は、例えば、RTT計測パケットを取り扱うアプリケーションプログラムの名前である。
RTT計測パケットにいおいて、名前の次に配置される送信時刻は、サーバ１２がクライアント１４に、そのRTT計測パケットを送信した時刻を示す。例えば、送信時刻には、ステップＳ９７において、RTT計測部８５が内蔵しているRTCから取得した時刻が格納される。
図１２のフローチャートに戻り、ステップＳ９８において、RTT計測部８５は、内蔵しているタイマをセットして、処理は、ステップＳ８２に戻り、上述した処理を繰り返す。
例えば、ステップＳ９８において、RTT計測部８５は、内蔵しているタイマの値を0sにセットする。
このようにして、サーバ１２は、FECパケットの送信の制御の処理を行う。
次に、図１５のフローチャートを参照して、図１２のステップＳ８３の処理に対応するFECパケット数増減状態の更新の処理について説明する。
ステップＳ１１１において、FEC送信制御部８６は、FECパケット数増減状態保持部８７に保持されているFECパケット数増減状態が増加状態であるか否かを判定する。
ステップＳ１１１において、FECパケット数増減状態が増加状態であると判定された場合、FEC送信制御部８６は、FECパケット数増減状態保持部８７に保持されているFECパケット数増減状態の設定を更新せずに、FECパケット数増減状態の更新の処理は、終了する。
一方、ステップＳ１１１において、増加状態でないと判定された場合、ステップＳ１１２に進み、FEC送信制御部８６は、FECパケットの不足状態を示すFECフィードバックパケットを受信したか否かを判定する。
ここで、FECフィードバックパケットは、通信網１３を介して、クライアント１４から送信されてくるパケットである。例えば、図８において、クライアント１４は、時刻ｔ２３、時刻ｔ２４、時刻ｔ２５、および時刻ｔ２６のそれぞれにおいて、通信網１３を介して、サーバ１２あてにFECフィードバックパケットを送信する。
また、FECフィードバックパケットには、クライアント１４において、受信されたFECパケットが、ロスパケットを復元するのに不足状態であるか、適正状態であるか、および過多状態であるかのいずれであるかを示す通知FEC状態が格納されている。
ステップＳ１１２において、FECパケットの不足状態を示すFECフィードバックパケットを受信したと判定された場合、ステップＳ１１３に進み、クライアント１４において、FECパケットが不足しているので、FEC送信制御部８７は、FECパケット数増減状態保持部８７に保持されているFECパケット数増減状態に増加状態を設定し、処理は、終了する。
ステップＳ１１２において、FECパケットの不足状態を示すFECフィードバックパケットを受信していないと判定された場合、ステップＳ１１４に進み、FEC送信制御部８６は、FECパケットの過多状態を示すFECフィードバックパケットを受信したか否かを判定する。
ステップＳ１１４において、FECパケットの過多状態を示すFECフィードバックパケットを受信したと判定された場合、ステップＳ１１５において、FEC送信制御部８６は、クライアント１４において、受信されたFECパケットが過多であるので、FECパケット数増減状態に削減状態を設定し、処理は終了する。
また、ステップＳ１１４において、FECパケットの過多状態を示すFECフィードバックパケットを受信していないと判定された場合、FEC送信制御部８６は、FECパケット数増減状態の更新を行わず、処理は終了する。
すなわち、FEC送信制御部８６は、図１２のステップＳ９３の処理において、FECパケット数増減状態の初期化を行ってから、RTT計測パケットが受信されるまでの期間において、１度でもFECの不足状態を示すFECフィードバックパケットを受信した場合、FECパケット数状態を増加状態に設定し、FECの適正状態を示すFECフィードバックパケットだけを受信した場合、FECパケット数状態を維持状態に設定し、FECの適正状態を示すFECフィードバックパケットおよびFECの過多状態を示すFECフィードバックパケットを受信した場合、FECパケット数状態を削減状態に設定する。
このようにして、FEC送信制御部８６は、クライアント１４からFECフィードバックパケットを受信するごとに、FECパケット数増減状態の更新を行う。
次に、図１６のフローチャートを参照して、図１２のステップＳ９２の処理に対応するFECパケット数変更の処理について説明する。
ステップＳ１３１において、FEC送信制御部８６は、FECパケット数増減状態保持部８７に記憶されているFECパケット数増減状態が維持状態であるか否かを判定し、維持状態であると判定された場合、FEC送信制御部８６は、FECパケット数の変更をせず、処理は終了する。
一方、ステップＳ１３１において、FECパケット数増減状態保持部８７に記憶されているFECパケット数増減状態が維持状態でないと判定された場合、ステップＳ１３２に進み、FEC送信制御部８６は、FECパケット数増減状態保持部８７に記憶されているFECパケット数増減状態が増加状態であるか否かを判定する。
ステップＳ１３２において、増加状態であると判定された場合、ステップＳ１３３に進み、FEC送信制御部８６は、FECパケット数保持部８９に保持されているFECパケット数が上限値であるか否かを判定する。
ステップＳ１３３において、FECパケット数が、上限値でないと判定された場合、ステップＳ１３４に進み、FEC送信制御部８６は、FECパケット数をインクリメントする。
また、ステップＳ１３３において、FECパケット数保持部８９に保持されているFECパケット数が上限値であると判定された場合、FECパケット数をこれ以上増加させることができないので、FEC送信制御部８６は、FECパケット数の変更をせず、処理は終了する。
ステップＳ１３２において、FECパケット数増減状態保持部８７に記憶されているFECパケット数増減状態が増加状態でないと判定された場合、ステップＳ１３５に進み、FEC送信制御部８６は、FECパケット数増減状態保持部８７に記憶されているFECパケット数増減状態が削減状態であるか否かを判定する。
ステップＳ１３５において、削減状態であると判定された場合、ステップＳ１３６に進み、FEC送信制御部８６は、FECパケット数保持部８９に保持されているFECパケット数が０であるか否かを判定する。
ステップＳ１３６において、FECパケット数が０でないと判定された場合、ステップＳ１３７に進み、FEC送信制御部８６は、FECパケット数をデクリメントし、処理は終了する。
一方、ステップＳ１３６において、FECパケット数が０であると判定された場合、FEC送信制御部８６は、これ以上FECパケット数を削減することができないので、FECパケット数を変更せず、処理は終了する。
また、ステップＳ１３５において、FECパケット数増減状態保持部８７に記憶されているFECパケット数増減状態が削減状態でないと判定された場合、FEC送信制御部８６は、FECパケット数の変更をせず、処理は終了する。
このようにして、FEC送信制御部８６は、FECパケット数保持部８９に保持されているFECパケット数を変更する。
図１７のフローチャートを参照して、クライアントプログラムを実行するクライアント１４によるデコードの処理について説明する。
ステップＳ１５１において、デコーダ１３４は、デコードの処理に必要なデータを初期化する。例えば、ステップＳ１５１において、デコーダ１３４は、500msの期間、待ち状態となって待機して、バッファ１３３が、所定の量の画像データを記憶するまで待つ。
また、例えば、画像データのフレームの数が１秒当たり３０である場合、ステップＳ１５１において、デコーダ１３４は、内蔵しているタイマの値を0msにセットし、33msなどの所定の値と比較することによりタイマが終了したか否かを判定する。
ステップＳ１５２において、デコーダ１３４は、タイマの値を基に、タイマが終了したか否かを判定し、タイマが終了したと判定された場合、ステップＳ１５３に進み、デコーダ１３４は、バッファ１３３から１フレーム分のデータを取得する。ステップＳ１５４において、デコーダ１３４は、ステップＳ１５３の処理で取得したデータをデコードして、デコードにより得られた画像データを出力する。
ステップＳ１５５において、デコーダ１３４は、内蔵しているタイマをセットして、ステップＳ１５１に戻り、デコードの処理を繰り返す。例えば、ステップＳ１５５において、デコーダ１３４は、タイマの値を0msにセットする。
一方、ステップＳ１５２において、タイマが終了していないと判定された場合、ステップＳ１５６に進み、RTP処理部１３２は、RTPパケットを受信したか否かを判定する。
ステップＳ１５６において、RTPパケットを受信したと判定されなかった場合、ステップＳ１５２に戻り、デコードの処理を繰り返す。
ステップＳ１５６において、RTPパケットを受信したと判定された場合、ステップＳ１５７に進み、RTP処理部１３２は、受信されたRTPパケットを検査することにより、パケットロスが発生したか否かを判定する。
ステップＳ１５７において、パケットロスが発生したと判定された場合、ステップＳ１５８に進み、FEC処理部１３５は、ロスパケットを復元する。
例えば、ステップＳ１５８において、FEC処理部１３５は、ロスしたパケットのFECブロックＩＤと同じFECブロックＩＤを含むFECパケットをRTP処理部１３２から供給された場合、供給されたFECパケットを基に、ロスパケットを復元し、復元されたRTPパケットをRTP処理部１３２に供給する。
また、ステップＳ１５８において、FECパケットが供給されなかった場合および供給されたFECパケットの数がロスパケットの数に対して、不足している場合は、ロスパケットを復元することができないので、FECパケットが不足している分のロスパケットの復元は行わない。
ステップＳ１５７において、パケットロスが発生していないと判定された場合、RTPパケットを復元する必要がないので、ステップＳ１５８の処理をスキップし、ステップＳ１５９に進む。
ステップＳ１５９において、RTP処理部１３２は、受信されたRTPパケットおよび復元されたRTPパケットをバッファ１３３に供給して、ステップＳ１５２に戻り、上述した処理を繰り返す。
このようにして、デコーダ１３４は、デコードの処理を行う。
次に、図１８のフローチャートを参照して、クライアントプログラムを実行するクライアント１４によるFECフィードバックパケット送信の処理を説明する。
ステップＳ１７１において、クライアント１４は、FECフィードバックパケット送信の処理に必要なデータの初期化を行う。例えば、ステップＳ１７１において、FEC処理部１３５は、後述するFECブロック情報を初期化し、内蔵しているタイマの値を0msに設定する。
ステップＳ１７２において、RTP処理部１３２は、パケットを受信したか否かを判定する。
ステップＳ１７２において、パケットが受信されたと判定された場合、ステップＳ１７３に進み、RTP処理部１３２は、受信したパケットのFECブロックＩＤが変化したか否かを判定する。ステップＳ１７３において、受信したパケットのFECブロックＩＤが変化したと判定された場合、ステップＳ１７４に進み、FEC処理部１３５は、受信が完了したFECブロック１７１に対するFECブロック状態の更新の処理を行う。
ここで、受信が完了したFECブロック１７１とは、ステップＳ１７４において、変化したと判定されたFECブロックＩＤの１つ前のFECブロックＩＤを含むFECブロック１７１である。FECブロック状態更新の処理は、通信網１３を介してサーバ１２から送信されてきた１つのFECブロック１７１に含まれるパケットの数と正常に受信されたパケットの数とを基に、処理が行われるため、FECブロック１７１に含まれる全てのパケットの受信が完了したとき、処理が実行できる。
従って、例えば、ステップＳ１７３において、受信したパケットのFECブロックＩＤが変化したか否かを基に、FECブロック１７１に含まれる全てのパケットの受信が、完了したか否かを判定する。
なお、ステップＳ１７４におけるFECブロック状態更新の処理の詳細は、後述する。
ステップＳ１７５において、RTP処理部１３２は、受信されたパケットに含まれるFECブロックＩＤ、オリジナルデータパケット数、および総パケット数をFECブロック情報として、FECブロック情報保持部１３６に記録する。
ここで、例えば、オリジナルデータパケット数は、図１１で示されるRTPパケットの“Ｋ”に対応し、総パケット数は、図１１で示されるRTPパケットの“Ｎ”に対応する。また、FECブロック情報は、例えば、図９で示すFECブロック情報テーブルに記録される。
図１１において、“Ｋ”で示されるRTPパケットのオリジナルデータパケット数が、FECブロックＩＤと対応して、図９で示されるFECブロック情報のオリジナルデータパケット数として格納される。図１１で示されるRTPパケットのFECブロックＩＤが図９のFECブロック情報のFECブロックＩＤとして格納される。また、図１１において、“Ｎ”で示される総パケット数が、FECブロックＩＤと対応して、図９で示されるFECブロック情報の総パケット数として格納される。
ステップＳ１７５の処理において、処理の対象となる受信されたパケットは、ステップＳ１７３の処理において、FECブロックＩＤが変化したと判定されたパケットである。すなわち、ステップＳ１７４の処理の対象となるFECブロックＩＤと、ステップＳ１７５の処理の対象となるFECブロックのFECブロックＩＤとは異なる。
ステップＳ１７６において、RTP処理部１３２は、FECブロック情報保持部１３６に記録されているFECブロック情報テーブルの受信パケット数に０を設定する。
また、ステップＳ１７３において、FECブロックＩＤが変化していないと判定された場合、ステップＳ１７４乃至ステップＳ１７６の処理はスキップされ、ステップＳ１７７に進む。
ステップＳ１７７において、RTP処理部１３２は、FECブロック情報保持部１３６に記録されているFECブロック情報テーブルの受信パケット数をインクリメントし、ステップＳ１７２に戻り、FECフィードバックパケット送信の処理を繰り返す。
また、ステップＳ１７２において、パケットが受信されていないと判定された場合、ステップＳ１７８に進み、FEC処理部１３５は、内蔵しているタイマが終了したか否かを判定する。
例えば、ステップＳ１７８において、FEC処理部１３５は、内蔵しているタイマの値と100msなどの所定の値とを比較することによって、タイマが終了したか否かを判定する。
ステップＳ１７８において、タイマが終了していないと判定された場合、ステップＳ１７２に戻り、FECフィードバックパケット送信の処理を繰り返す。
ステップＳ１７８において、タイマが終了したと判定された場合、ステップＳ１７９に進み、FEC処理部１３５は、サーバ１２に通知するFEC状態である通知FEC状態設定の処理を行う。
例えば、ステップＳ１７９において、FEC処理部１３５は、FECブロック情報保持部１３６に保持されているFECブロック情報テーブルに記録されている全てのFECブロック状態を基に、通知FEC状態設定の処理を行う。通知FEC状態設定の処理の詳細は、後述する。
ステップＳ１８０において、FEC処理部１３５のFECフィードバックパケット生成部１５３は、ステップＳ１７９において、設定されている通知FEC状態を基に、FECフィードバックパケットを生成する。
図１９は、FECフィードバックパケットを説明する図である。バージョン情報、パディング、サブタイプ、メッセージ長、SSRC、および名前は、図１４で示されるRTT計測パケットの場合と同様であるので、その説明は、省略する。
FECフィードバックパケットにおいて、ペイロードタイプは、２０４とされる。
FECフィードバックパケットにおいて、名前の次に配置される通知FEC状態は、相手に通知する通知FEC状態である。通知FEC状態には、例えば、図１８のステップＳ１７９の処理において、適正状態、過多状態、および不足状態のいずれかの設定された通知FEC状態が格納される。
図１８の説明に戻り、ステップＳ１８１において、FECフィードバックパケット生成部１５３は、生成されたFECフィードバックパケットを通信部１３１に供給し、通信部１３１は、FECフィードバックパケット生成部１５３から供給されたFECフィードバックパケットを、通信網１３を介して、サーバ１２あてに送信する。
ステップＳ１８２において、FEC処理部１３５は、内蔵しているタイマを更新し、ステップＳ１７２に戻り、上述した処理を繰り返す。
例えば、ステップＳ１８２において、FEC処理部１３５は、内蔵しているタイマを0msにセットする。
このようにして、FEC処理部１３５は、所定の期間ごとに通信網１３を介して、サーバ１２あてにFECフィードバックパケットを送信する。なお、ステップＳ１７８において、タイマの値と比較される100msは、図８におけるＴ１、Ｔ２、Ｔ３、およびＴ４に対応する期間の一例であり、本発明を限定するものではない。
次に、図２０のフローチャートを参照して、図１８のステップＳ１７４の処理に対応する受信完了FECブロック１７１に対するFECブロック状態更新の処理について説明する。
ステップＳ２０１において、RTP処理部１３２は、FECブロック情報保持部１３６に保持されているFECブロック情報テーブルに、受信が完了したFECブロック１７１の受信パケット数を格納（記録）する。
ステップＳ２０２において、FEC処理部１３５は、FECブロック情報保持部１３６に保持されているFECブロック情報テーブルを基に、受信が完了したFECブロック１７１の受信パケット数が、オリジナルデータパケット数と等しいか否かを判定する。
ステップＳ２０２において、受信パケット数が、オリジナルデータパケット数と等しいと判定された場合、RTPパケットを復元するFECパケットの数は、不足でもなく、過多でもないので、ステップＳ２０３に進み、FEC処理部１３５は、FECブロック情報保持部１３６に保持されているFECブロック情報テーブルのFECブロック状態に適正状態を設定し、処理は終了する。
ステップＳ２０２において、受信パケット数がオリジナルデータパケット数と等しくないと判定された場合、ステップＳ２０４に進み、FEC処理部１３５は、受信パケット数がオリジナルパケット数より多いか否かを判定する。
ステップＳ２０４において、受信パケット数がオリジナルデータパケット数より多いと判定された場合、RTPパケットを復元するFECパケットの数が過多であるので、ステップＳ２０５に進み、FEC処理部１３５は、FECブロック情報保持部１３６に保持されているFECブロック情報テーブルのFECブロック状態に過多状態を設定し、処理は終了する。
ステップＳ２０４において、受信パケット数がオリジナルデータパケット数より多いと判定されなかった場合、ステップＳ２０６に進み、FEC処理部１３５は、受信パケット数がオリジナルパケット数より少ないか否かを判定する。
ステップＳ２０６において、受信パケット数がオリジナルデータパケット数より少ないと判定された場合、RTPパケットを復元するFECパケットの数が不足しているので、ステップＳ２０７に進み、FEC処理部１３５は、FECブロック情報保持部１３６に保持されているFECブロック情報テーブルのFECブロック状態に不足状態を設定し、処理は終了する。
一方、ステップＳ２０６において、受信パケット数がオリジナルデータパケット数より少ないと判定されなかった場合、ステップＳ２０８に進み、FEC処理部１３５は、FECブロック情報保持部１３６に保持されているFECブロック情報テーブルのFECブロック状態に適正状態を設定し、処理は終了する。
このようにして、FEC処理部１３５は、FECブロック１７１の受信が完了するごとにFECブロック情報保持部１３６に保持されているFECブロック状態を更新する。
なお、ステップＳ２０６の判定の処理を省略して、FECブロック状態を不足状態と設定するようにしてもよい。
次に、図２１のフローチャートを参照して、図１８のステップＳ１７９の処理に対応する通知FECブロック状態設定の処理について説明する。
ステップＳ２２１において、FEC処理部１３５は、FECブロック情報保持部１３６に保持されているFECブロック情報テーブルに記録されているFECブロックＩＤごとのFEC状態のなかに、不足状態であるFECブロック１７１があるか否かを判定する。
ステップＳ２２１において、不足状態であるFECブロック１７１があると判定された場合、ステップＳ２２２に進み、FEC処理部１３５は、通知FEC状態保持部１３７に保持されている通知FEC状態に不足状態を設定する。ステップＳ２２３において、FECブロック情報を初期化し、処理は終了する。
例えば、ステップＳ２２３において、FEC処理部１３５は、FEC情報テーブルに記録されているFECブロック情報の全てをクリアすることにより初期化を行う。
また、ステップＳ２２１において、FECブロック情報保持部１３６に保持されているFECブロック情報テーブルに記録されているFECブロックＩＤごとのFEC状態のなかに、不足状態であるFECブロック１７１がないと判定された場合、ステップＳ２２４に進み、FEC処理部１３５は、FECブロックＩＤごとのFEC状態のなかに、過多状態であるFECブロック１７１があるか否かを判定する。
ステップＳ２２４において、過多状態であるFECブロック１７１があると判定された場合、ステップＳ２２５に進み、FEC処理部１３５は、通知FEC状態保持部１３７に保持されている通知FEC状態に過多状態を設定し、ステップＳ２２３に進む。
ステップＳ２２４において、過多状態であるFECブロック１７１がないと判定された場合、ステップＳ２２６に進み、FEC処理部１３５は、通知FEC状態保持部１３７に保持されている通知FEC状態に適正状態を設定し、ステップＳ２２３に進む。
すなわち、FEC処理部１３５は、FECブロック情報保持部１３６に保持されているFECブロック情報テーブルに記録されているFECブロック状態の中に、１つでも不足状態であるFECブロック１７１がある場合、通知FEC状態を不足状態に設定し、全てのFECブロック１７１が、適正状態である場合、通知FEC状態を適正状態に設定し、不足状態であるFECブロック１７１がなく、過多状態であるFECブロック１７１がある場合、通知FEC状態を過多状態に設定する。
このようにして、FEC処理部１３５は、所定の期間ごとに、FECブロック情報保持部１３６に保持されているFECブロックＩＤごとのFECブロック状態を基に、サーバ１２に通知する通知FEC状態を設定する。
図２２のフローチャートを参照して、RTT計測パケットの返信の処理を説明する。ステップＳ２４１において、RTT計測部１３８は、通信部１３１がパケットを受信した場合に、通信部１３１から供給されたパケットを基に、RTT計測パケットを受信したか否かを判定し、RTT計測パケットを受信していないと判定された場合、ステップＳ２４１に戻り、RTT計測パケットが受信されるまで、判定の処理を繰り返す。
ステップＳ２４１において、RTT計測パケットを受信したと判定された場合、ステップＳ２４２に進み、RTT計測部１３８は、直ちに、受信したRTT計測パケットのデータ部と同様のデータ部のRTT計測パケットを生成して、生成したRTT計測パケットを通信部１３１に供給する。そして、RTT計測部１３８は、通信部１３１に、通信網１３を介して、RTT計測パケットをサーバ１２あてに直ちに送信させて、ステップＳ２４１に戻り、上述した処理を繰り返す。
このように、クライアント１４は、RTT計測パケットを受信すると、直ちに、サーバ１２にRTT計測パケットを返送する。
以上のように、サーバ１２は、クライアント１４から送信されてきたFECフィードバックパケットを基に、クライアント１４に送信するFECパケットの数を変更し、さらに、通信網１３が輻輳状態である場合、FECパケットをクライアント１４に送信し、通信網１３が輻輳状態でない場合、FECパケットのクライアント１４への送信を抑制することで、より効率的にデータの送信を行うことができる。
第１の本発明によれば、誤り訂正パケットを生成するようにしたので、誤り訂正のための冗長データを送信することができる。また、第１の本発明によれば、通信網が輻輳状態であるか否かを判定し、誤り訂正パケットを生成し、輻輳状態でない旨の判定結果から輻輳状態である旨の判定結果に変化した場合、誤り訂正パケットの数を変更するように、生成を制御するようにしたので、通信網の状態に応じて、冗長データを含むデータの送信をより効率的に行うことができる。
第２の本発明によれば、誤り訂正パケットを受信するようにしたので、受信したデータの誤りを訂正することができる。また、第２の本発明によれば、誤り訂正パケットを受信し、受信した誤り訂正パケットの数が、ストリーミングデータの誤りを訂正するのに適正であるか否かを判定するようにしたので、送信側において、通信網の状態に応じて、冗長データを含むデータの送信をより効率的に行うことができる。
上述した一連の処理は、ハードウェアにより実行させることもできるが、ソフトウェアにより実行させることもできる。一連の処理をソフトウェアにより実行させる場合には、そのソフトウェアを構成するプログラムが、専用のハードウェアに組み込まれているコンピュータ、または、各種のプログラムをインストールすることで、各種の機能を実行することが可能な、例えば汎用のパーソナルコンピュータなどに、記録媒体からインストールされる。
この記録媒体は、図５に示すように、コンピュータとは別に、ユーザにプログラムを提供するために配布される、プログラムが記録されている磁気ディスク５１（フレキシブルディスクを含む）、光ディスク５２（CD-ROM(Compact Disc-Read Only Memory)、ＤＶＤ(Digital Versatile Disc)を含む）、光磁気ディスク５３（ＭＤ(Mini-Disc)（商標）を含む）、若しくは半導体メモリ５４などよりなるパッケージメディアにより構成されるだけでなく、コンピュータに予め組み込まれた状態でユーザに提供される、プログラムが記録されているROM３２や、記録部３８に含まれるハードディスクなどで構成される。
なお、上述した一連の処理を実行させるプログラムは、必要に応じてルータ、モデムなどのインタフェースを介して、ローカルエリアネットワーク、インターネット、デジタル衛星放送といった、有線または無線の通信媒体を介してコンピュータにインストールされるようにしてもよい。
また、本明細書において、記録媒体に格納されるプログラムを記述するステップは、記載された順序に沿って時系列的に行われる処理はもちろん、必ずしも時系列的に処理されなくとも、並列的あるいは個別に実行される処理をも含むものである。
なお、本明細書において、システムとは、複数の装置により構成される装置全体を表すものである。
従来のFECパケットの送信を説明する図である。 従来のFECパケットの送信の順序を説明する図である。 従来のFECパケットを付加した送信の処理を説明するフローチャートである。 本発明に係る通信システムの一実施の形態を示す図である。 サーバの構成の例を示すブロック図である。 サーバの機能の構成を示すブロック図である。 クライアントの機能の構成を示すブロック図である。 FECパケットの送信を説明するタイムチャートである。 FECブロック情報を説明する図である。 データ送信の処理を説明するフローチャートである。 RTPパケットを説明する図である。 FECパケットの送信の制御の処理を説明するフローチャートである。 輻輳状態、長期依存RTTおよび短期依存RTTの関係を説明する図である。 RTT計測パケットを説明する図である。 FECパケット数増減状態の更新の処理を説明するフローチャートである。 FECパケット数変更の処理を説明するフローチャートである。 デコードの処理を説明するフローチャートである。 FECフィードバックパケット送信の処理を説明するフローチャートである。 FECフィードバックパケットを説明する図である。 受信完了ブロックに対するFECブロック状態更新の処理を説明するフローチャートである。 通知FEC状態設定の処理を説明するフローチャートである。 RTT計測パケットの返信の処理を説明するフローチャートである。
符号の説明
３１ ＣＰＵ， ３２ ＲＯＭ， ３３ ＲＡＭ， ３８ 記録部， ５１ 磁気ディスク， ５２ 光ディスク， ５３ 光磁気ディスク， ５４ 半導体メモリ， ８３ RTTパケット生成部， ８４ FECパケット生成部， ８５ RTT計測部， ８６ FEC送信制御部， ８７ FECパケット数増減状態保持部， ８８ FEC送信モード記憶部， ８９ FECパケット数保持部， １３２ RTP処理部， １３５ FEC処理部， １３６ FECブロック情報保持部， １３７ 通知FEC状態保持部

Claims (15)

  1. 通信網を介して、ストリーミングデータが格納されている送信パケットを送信する送信装置において、
    前記通信網が輻輳状態であるか否かを判定する判定手段と、
    前記送信パケットに格納されている前記ストリーミングデータの誤りを訂正するための誤り訂正データが格納されている誤り訂正パケットを生成する生成手段と、
    輻輳状態でない旨の判定結果から輻輳状態である旨の判定結果に変化した場合、前記誤り訂正パケットの数を変更するように、前記生成手段における前記誤り訂正パケットの生成を制御する制御手段と
    を備えることを特徴とする送信装置。
  2. 前記制御手段は、輻輳状態であると判定された場合、前記生成手段に所定の数の前記誤り訂正パケットを生成させ、輻輳状態でないと判定された場合、前記生成手段の前記誤り訂正パケットの生成を抑制するように、前記生成手段における前記誤り訂正パケットの生成を制御する
    ことを特徴とする請求項１に記載の送信装置。
  3. 前記制御手段は、輻輳状態でない旨の判定結果から輻輳状態である旨の判定結果に変化した場合、直前の輻輳状態における前記送信パケットの受信の状態を基に、前記誤り訂正パケットの数を変更するように、前記生成手段における前記誤り訂正パケットの生成を制御する
    ことを特徴とする請求項１に記載の送信装置。
  4. 前記制御手段は、所定の期間における１または複数の前記送信パケットからなる誤り訂正の単位であって、所定の期間における１または複数の誤り訂正の単位の受信状態を基に、前記期間における１または複数の前記誤り訂正の単位のいずれかにおいて、前記誤り訂正パケットの数が不足している場合、前記誤り訂正パケットの数を増加させるように、前記生成手段における前記誤り訂正パケットの生成を制御する
    ことを特徴とする請求項１の記載の送信装置。
  5. 前記判定手段は、第１の時刻から現在時刻までの期間における前記送信パケットの相手への伝送に要する遅延時間に依存する短期依存遅延時間と、前記第１の時刻より過去の第２の時刻から現在時刻までの期間における前記遅延時間に依存する長期依存遅延時間とを基に、輻輳状態であるか否かを判定する
    ことを特徴とする請求項１に記載の送信装置。
  6. 通信網を介して、ストリーミングデータが格納されている送信パケットを送信する送信方法において、
    前記通信網が輻輳状態であるか否かを判定する判定ステップと、
    前記送信パケットに格納されている前記ストリーミングデータの誤りを訂正するための誤り訂正データが格納されている誤り訂正パケットを生成する生成ステップと、
    輻輳状態でない旨の判定結果から輻輳状態である旨の判定結果に変化した場合、前記誤り訂正パケットの数を変更するように、前記生成ステップにおける前記誤り訂正パケットの生成を制御する制御ステップと
    を含むことを特徴とする送信方法。
  7. 通信網を介して、ストリーミングデータが格納されている送信パケットを送信する送信処理用のプログラムであって、
    前記通信網が輻輳状態であるか否かを判定する判定ステップと、
    前記送信パケットに格納されている前記ストリーミングデータの誤りを訂正するための誤り訂正データが格納されている誤り訂正パケットを生成する生成ステップと、
    輻輳状態でない旨の判定結果から輻輳状態である旨の判定結果に変化した場合、前記誤り訂正パケットの数を変更するように、前記生成ステップにおける前記誤り訂正パケットの生成を制御する制御ステップと
    を含むことを特徴とするコンピュータが読み取り可能なプログラムが記録されている記録媒体。
  8. 通信網を介して、ストリーミングデータが格納されている送信パケットを送信する送信処理をコンピュータに行わせるプログラムにおいて、
    前記通信網が輻輳状態であるか否かを判定する判定ステップと、
    前記送信パケットに格納されている前記ストリーミングデータの誤りを訂正するための誤り訂正データが格納されている誤り訂正パケットを生成する生成ステップと、
    輻輳状態でない旨の判定結果から輻輳状態である旨の判定結果に変化した場合、前記誤り訂正パケットの数を変更するように、前記生成ステップにおける前記誤り訂正パケットの生成を制御する制御ステップと
    を含むことを特徴とするプログラム。
  9. 通信網を介して、ストリーミングデータが格納されている送信パケットを受信する受信装置において、
    前記送信パケットに格納されている前記ストリーミングデータの誤りを訂正するための誤り訂正データが格納されている誤り訂正パケットを受信する受信制御手段と、
    受信された誤り訂正パケットの数が、前記ストリーミングデータの誤りを訂正するのに適正であるか否かを判定する判定手段と
    を備えることを特徴とする受信装置。
  10. 前記判定手段は、受信された誤り訂正パケットの数が、前記ストリーミングデータの誤りを訂正するのに不足であるか、適正であるか、および過多であるかの何れであるかを判定する
    ことを特徴とする請求項９に記載の受信装置。
  11. 前記判定手段は、１または複数の前記送信パケットからなる誤り訂正の単位ごとに、受信された前記誤り訂正パケットの数が、前記ストリーミングデータの誤りを訂正するのに不足であるか、適正であるか、および過多であるかの何れであるかを判定し、
    所定の期間における１または複数の前記誤り訂正の単位に対する前記判定結果を基に、前記期間における１または複数の前記誤り訂正の単位のいずれかにおいて、前記誤り訂正パケットの数が不足していると判定された場合、相手への通知に前記誤り訂正パケットの数が不足している旨を設定する設定手段をさらに備える
    ことを特徴とする請求項９に記載の受信装置。
  12. 前記判定結果に基づく通知を格納するフィードバックパケットを生成する生成手段と、
    前記生成手段によって、生成された前記フィードバックパケットの相手への送信を制御する送信制御手段とをさらに備える
    ことを特徴とする請求項９に記載の受信装置。
  13. 通信網を介して、ストリーミングデータが格納されている送信パケットを受信する受信方法において、
    前記送信パケットに格納されている前記ストリーミングデータの誤りを訂正するための誤り訂正データが格納されている誤り訂正パケットを受信する受信制御ステップと、
    前記受信制御ステップにおいて受信された誤り訂正パケットの数が、前記ストリーミングデータの誤りを訂正するのに適正であるか否かを判定する判定ステップと
    を含むことを特徴とする受信方法。
  14. 通信網を介して、ストリーミングデータが格納されている送信パケットを受信する受信処理用のプログラムであって、
    前記送信パケットに格納されている前記ストリーミングデータの誤りを訂正するための誤り訂正データが格納されている誤り訂正パケットを受信する受信制御ステップと、
    前記受信制御ステップにおいて受信された誤り訂正パケットの数が、前記ストリーミングデータの誤りを訂正するのに適正であるか否かを判定する判定ステップと
    を含むことを特徴とするコンピュータが読み取り可能なプログラムが記録されている記録媒体。
  15. 通信網を介して、ストリーミングデータが格納されている送信パケットを受信する受信処理をコンピュータに行わせるプログラムにおいて、
    前記送信パケットに格納されている前記ストリーミングデータの誤りを訂正するための誤り訂正データが格納されている誤り訂正パケットを受信する受信制御ステップと、
    前記受信制御ステップにおいて受信された誤り訂正パケットの数が、前記ストリーミングデータの誤りを訂正するのに適正であるか否かを判定する判定ステップと
    を含むことを特徴とするプログラム。
JP2003412459A 2003-12-10 2003-12-10 送信装置および方法、受信装置および方法、記録媒体、並びにプログラム Expired - Fee Related JP4349114B2 (ja)

Priority Applications (4)

Application Number Priority Date Filing Date Title
JP2003412459A JP4349114B2 (ja) 2003-12-10 2003-12-10 送信装置および方法、受信装置および方法、記録媒体、並びにプログラム
US10/999,980 US7539925B2 (en) 2003-12-10 2004-12-01 Transmission apparatus and method, reception apparatus and method, storage medium, and program
KR1020040103604A KR20050056886A (ko) 2003-12-10 2004-12-09 송신 장치 및 방법, 수신 장치 및 방법, 기록 매체, 및프로그램
CNB2004101002744A CN100377516C (zh) 2003-12-10 2004-12-10 发送设备和方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2003412459A JP4349114B2 (ja) 2003-12-10 2003-12-10 送信装置および方法、受信装置および方法、記録媒体、並びにプログラム

Publications (2)

Publication Number Publication Date
JP2005175837A true JP2005175837A (ja) 2005-06-30
JP4349114B2 JP4349114B2 (ja) 2009-10-21

Family

ID=34732895

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2003412459A Expired - Fee Related JP4349114B2 (ja) 2003-12-10 2003-12-10 送信装置および方法、受信装置および方法、記録媒体、並びにプログラム

Country Status (4)

Country Link
US (1) US7539925B2 (ja)
JP (1) JP4349114B2 (ja)
KR (1) KR20050056886A (ja)
CN (1) CN100377516C (ja)

Cited By (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2009027720A (ja) * 2007-07-23 2009-02-05 Polycom Inc 輻輳回避と共に損失パケット回復を行うシステム及び方法
JP2010016484A (ja) * 2008-07-01 2010-01-21 Fujitsu Ltd データ転送装置、データ転送方法及びデータ転送プログラム
JP2010050809A (ja) * 2008-08-22 2010-03-04 Toshiba Corp データ受信装置、データ受信方法、及びデータ受信プログラム
JP2010514348A (ja) * 2006-12-21 2010-04-30 トムソン ライセンシング インターネットプロトコルネットワークでのリアルタイムのオーディオ及びビデオデータの前方誤り訂正をサポートする方法
JP2010119133A (ja) * 2010-01-28 2010-05-27 Sony Corp パケット送信装置、通信システム及びプログラム
US8023533B2 (en) 2006-12-25 2011-09-20 Sony Corporation Data communication system, data transmitting apparatus, data transmitting method, and method for determining packet size and redundancy
US8234548B2 (en) 2005-11-09 2012-07-31 Sony Corporation Packet transmission apparatus, communication system and program
JP2013085293A (ja) * 2013-01-11 2013-05-09 Thomson Licensing インターネットプロトコルネットワークでのリアルタイムのオーディオ及びビデオデータの前方誤り訂正をサポートする方法
US8923151B2 (en) 2009-11-24 2014-12-30 Nec Corporation Quality control apparatus, moving image transmission system, quality control method, and recording medium
JP2015508979A (ja) * 2012-02-27 2015-03-23 サムスン エレクトロニクス カンパニー リミテッド 順方向エラー訂正スキームを使用するパケット送受信装置及び方法
JP2019501566A (ja) * 2016-03-11 2019-01-17 ▲騰▼▲訊▼科技（深▲セン▼）有限公司 ビデオデータ冗長制御方法および装置
JP2020145523A (ja) * 2019-03-04 2020-09-10 日本電信電話株式会社 無線通信システムおよび無線通信方法

Families Citing this family (35)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2007531078A (ja) * 2003-07-16 2007-11-01 ハンヤン ハク ウォン カンパニー，リミテッド ３次元メッシュ情報の符号化及び復号化方法並びにその装置
US7904781B2 (en) * 2004-12-09 2011-03-08 Mitsubishi Electric Corporation Data transmitting device, data receiving device, and data distribution system
US7730385B2 (en) * 2005-11-30 2010-06-01 Motorola, Inc. Method for decoding a received control channel message with a priori information
JP2007201756A (ja) * 2006-01-26 2007-08-09 Sony Corp 情報処理装置および方法、並びにプログラム
US7787377B2 (en) * 2006-02-03 2010-08-31 Telefonaktiebolaget Lm Ericsson (Publ) Selective redundancy for Voice over Internet transmissions
US7577898B2 (en) * 2006-04-10 2009-08-18 At&T Intellectual Property I, L.P. System and method of correcting video data errors
JP4724613B2 (ja) * 2006-07-04 2011-07-13 富士通株式会社 通信装置、通信制御プログラム及び通信制御方法
WO2008013528A1 (en) 2006-07-25 2008-01-31 Thomson Licensing Recovery from burst packet loss in internet protocol based wireless networks using staggercasting and cross-packet forward error correction
US8300563B2 (en) * 2006-09-29 2012-10-30 Intel Corporation Aggregated transmission in WLAN systems with FEC MPDUs
CN1937631B (zh) * 2006-10-24 2010-12-08 杭州华三通信技术有限公司 用户数据报协议报文的处理方法及装置
JP4250654B2 (ja) * 2006-11-17 2009-04-08 株式会社東芝 通信装置、通信方法および通信プログラム
KR101177454B1 (ko) * 2007-03-02 2012-08-27 삼성전자주식회사 영상 데이터의 전송에 따른 에러 복원 결정을 위한 서버 및클라이언트와, 영상 데이터의 전송에 따른 에러 복원결정방법
JP4434242B2 (ja) * 2007-07-11 2010-03-17 ソニー株式会社 送信装置、受信装置、誤り訂正システム、送信方法及び誤り訂正方法
JP5075536B2 (ja) * 2007-09-03 2012-11-21 株式会社東芝 Ｆｅｃ送信処理装置、ならびにｆｅｃ送信処理のための方法およびプログラム
CN101478442B (zh) * 2008-01-02 2011-11-30 中兴通讯股份有限公司 组网模拟测试的工具、系统和方法
US8839339B2 (en) * 2008-04-15 2014-09-16 International Business Machines Corporation Blade center KVM distribution
JP5094593B2 (ja) * 2008-06-27 2012-12-12 キヤノン株式会社 送信装置、受信装置、及び方法、プログラム
JP5191826B2 (ja) * 2008-07-04 2013-05-08 パナソニック株式会社 ストリーム通信装置、ストリーム通信方法及びストリーム通信システム
US8489954B2 (en) * 2008-08-29 2013-07-16 Ntt Docomo, Inc. Method and apparatus for reliable media transport
US8397140B2 (en) * 2010-06-04 2013-03-12 Apple Inc. Error correction coding for recovering multiple packets in a group view of limited bandwidth
GB2492830B (en) 2011-07-14 2018-06-27 Skype Correction data
US10498359B2 (en) 2011-07-14 2019-12-03 Microsoft Technology Licensing, Llc Correction data
CN103686055B (zh) * 2012-09-24 2017-05-10 中兴通讯股份有限公司 电视会议系统中丢包补偿的处理方法及装置
EP2827522A1 (en) * 2013-07-15 2015-01-21 Alcatel Lucent Method for a first network node for transmitting or retransmitting data to a second network node and first network node thereof and method for a second network node for receiving data transmitted or retransmitted from a first network node and second network node thereof
WO2016203870A1 (ja) * 2015-06-17 2016-12-22 ソニー株式会社 送信装置、送信方法、及び通信システム
GB2535819B (en) 2015-07-31 2017-05-17 Imagination Tech Ltd Monitoring network conditions
CN107769887B (zh) * 2016-08-17 2021-02-12 华为技术有限公司 一种数据传输、数据处理方法及装置
US10784986B2 (en) * 2017-02-28 2020-09-22 Intel Corporation Forward error correction mechanism for peripheral component interconnect-express (PCI-e)
CN107241166A (zh) * 2017-06-12 2017-10-10 京信通信系统（中国）有限公司 一种长期演进上的语音Volte数据保障方法和设备
US10771189B2 (en) 2018-12-18 2020-09-08 Intel Corporation Forward error correction mechanism for data transmission across multi-lane links
US11637657B2 (en) 2019-02-15 2023-04-25 Intel Corporation Low-latency forward error correction for high-speed serial links
US11249837B2 (en) 2019-03-01 2022-02-15 Intel Corporation Flit-based parallel-forward error correction and parity
US10997111B2 (en) 2019-03-01 2021-05-04 Intel Corporation Flit-based packetization
US11296994B2 (en) 2019-05-13 2022-04-05 Intel Corporation Ordered sets for high-speed interconnects
US11740958B2 (en) 2019-11-27 2023-08-29 Intel Corporation Multi-protocol support on common physical layer

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH11239159A (ja) * 1994-07-21 1999-08-31 Fujitsu Ltd Ａｔｍ交換機
JP2003179580A (ja) * 2001-12-12 2003-06-27 Sony Corp データ通信システム、データ送信装置、データ受信装置、および方法、並びにコンピュータ・プログラム
JP2003529289A (ja) * 2000-03-29 2003-09-30 サムスン エレクトロニクス カンパニー リミテッド マルチメディアデータ送受信装置及び方法
WO2005046125A1 (en) * 2003-10-28 2005-05-19 Docomo Communications Laboratories Usa, Inc. Method for supporting scalable and reliable multicast in tdma/tdd systems using feedback suppression techniques
JP2005515697A (ja) * 2001-12-28 2005-05-26 コーニンクレッカ　フィリップス　エレクトロニクス　エヌ　ヴィ リード・ソロモン符号に基づいた前方誤り訂正を用いた不均一誤り保護

Family Cites Families (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5313454A (en) * 1992-04-01 1994-05-17 Stratacom, Inc. Congestion control for cell networks
WO1995003657A1 (fr) * 1993-07-21 1995-02-02 Fujitsu Limited Central mta
US5426635A (en) * 1993-09-08 1995-06-20 At&T Corp. Method for adaptive control of windows and rates in networks
JP2576776B2 (ja) * 1993-11-10 1997-01-29 日本電気株式会社 パケット伝送方法・パケット伝送装置
US5600663A (en) 1994-11-16 1997-02-04 Lucent Technologies Inc. Adaptive forward error correction system
JP3614907B2 (ja) * 1994-12-28 2005-01-26 株式会社東芝 データ再送制御方法及びデータ再送制御システム
US5699364A (en) * 1995-03-16 1997-12-16 Kabushiki Kaisha Toshiba Data communication system, apparatus and method which optimize the set value of parameters
JP2768297B2 (ja) 1995-03-23 1998-06-25 日本電気株式会社 データ転送方法とその装置
JP3307792B2 (ja) * 1995-04-13 2002-07-24 株式会社日立製作所 Ａｔｍスイッチおよびａｔｍ−ｌａｎにおける輻輳制御方式
US5732078A (en) * 1996-01-16 1998-03-24 Bell Communications Research, Inc. On-demand guaranteed bandwidth service for internet access points using supplemental user-allocatable bandwidth network
US5699365A (en) * 1996-03-27 1997-12-16 Motorola, Inc. Apparatus and method for adaptive forward error correction in data communications
US6310857B1 (en) * 1997-06-16 2001-10-30 At&T Corp. Method and apparatus for smoothing and multiplexing video data flows
US6424624B1 (en) * 1997-10-16 2002-07-23 Cisco Technology, Inc. Method and system for implementing congestion detection and flow control in high speed digital network
US6882624B1 (en) * 1998-04-09 2005-04-19 Nokia Networks Oy Congestion and overload control in a packet switched network
JP3556495B2 (ja) * 1998-12-15 2004-08-18 株式会社東芝 パケットスイッチ及びパケット交換方法
US6996097B1 (en) * 1999-05-21 2006-02-07 Microsoft Corporation Receiver-driven layered error correction multicast over heterogeneous packet networks
US7095729B2 (en) * 2000-12-22 2006-08-22 Intel Corporation Method for multimedia communication over packet channels
US7099273B2 (en) * 2001-04-12 2006-08-29 Bytemobile, Inc. Data transport acceleration and management within a network communication system
US7035220B1 (en) * 2001-10-22 2006-04-25 Intel Corporation Technique for providing end-to-end congestion control with no feedback from a lossless network
KR100408525B1 (ko) * 2001-10-31 2003-12-06 삼성전자주식회사 네트워크에 적응적인 실시간 멀티미디어 스트리밍 시스템및 방법

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH11239159A (ja) * 1994-07-21 1999-08-31 Fujitsu Ltd Ａｔｍ交換機
JP2003529289A (ja) * 2000-03-29 2003-09-30 サムスン エレクトロニクス カンパニー リミテッド マルチメディアデータ送受信装置及び方法
JP2003179580A (ja) * 2001-12-12 2003-06-27 Sony Corp データ通信システム、データ送信装置、データ受信装置、および方法、並びにコンピュータ・プログラム
JP2005515697A (ja) * 2001-12-28 2005-05-26 コーニンクレッカ　フィリップス　エレクトロニクス　エヌ　ヴィ リード・ソロモン符号に基づいた前方誤り訂正を用いた不均一誤り保護
WO2005046125A1 (en) * 2003-10-28 2005-05-19 Docomo Communications Laboratories Usa, Inc. Method for supporting scalable and reliable multicast in tdma/tdd systems using feedback suppression techniques
JP2007510363A (ja) * 2003-10-28 2007-04-19 株式会社エヌ・ティ・ティ・ドコモ フィードバック抑制技術を使用してｔｄｍａ／ｔｄｄシステムにおおけるスケーラブル且つリライアブルなマルチキャストをサポートする方法

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
吉村健、大矢智之、河原敏朗、栄藤稔: "モバイルストリーミングにおけるRTPモニタリングエージェントを用いたMPEGビデオ品質制御方式", 電子情報通信学会論文誌, vol. 85, no. 8, JPN6009014695, 25 July 2002 (2002-07-25), JP, pages 1243 - 1253, ISSN: 0001286903 *
高山修一、堀良影、上原聡、尾家祐二: "実時間情報伝送のためのFECシステム", 電子情報通信学会技術研究報告 IN95-5, vol. 95, no. 28, JPN6008053289, 12 May 1995 (1995-05-12), JP, pages 27 - 32, ISSN: 0001162855 *

Cited By (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8234548B2 (en) 2005-11-09 2012-07-31 Sony Corporation Packet transmission apparatus, communication system and program
US8516346B2 (en) 2005-11-09 2013-08-20 Sony Corporation Packet transmission apparatus, communication system and program
US8990663B2 (en) 2006-12-21 2015-03-24 Thomson Licensing Method to support forward error correction for real-time audio and video data over internet protocol networks
JP2010514348A (ja) * 2006-12-21 2010-04-30 トムソン ライセンシング インターネットプロトコルネットワークでのリアルタイムのオーディオ及びビデオデータの前方誤り訂正をサポートする方法
US8023533B2 (en) 2006-12-25 2011-09-20 Sony Corporation Data communication system, data transmitting apparatus, data transmitting method, and method for determining packet size and redundancy
US8711884B2 (en) 2006-12-25 2014-04-29 Sony Corporation Data communication system, data transmitting apparatus, data transmitting method, and method for determining packet size and redundancy
JP2009027720A (ja) * 2007-07-23 2009-02-05 Polycom Inc 輻輳回避と共に損失パケット回復を行うシステム及び方法
JP2010016484A (ja) * 2008-07-01 2010-01-21 Fujitsu Ltd データ転送装置、データ転送方法及びデータ転送プログラム
JP2010050809A (ja) * 2008-08-22 2010-03-04 Toshiba Corp データ受信装置、データ受信方法、及びデータ受信プログラム
US8923151B2 (en) 2009-11-24 2014-12-30 Nec Corporation Quality control apparatus, moving image transmission system, quality control method, and recording medium
JP2010119133A (ja) * 2010-01-28 2010-05-27 Sony Corp パケット送信装置、通信システム及びプログラム
US10177784B2 (en) 2012-02-27 2019-01-08 Samsung Electronics Co., Ltd. Packet transmission/reception apparatus and method using forward error correction scheme
JP2015508979A (ja) * 2012-02-27 2015-03-23 サムスン エレクトロニクス カンパニー リミテッド 順方向エラー訂正スキームを使用するパケット送受信装置及び方法
JP2013085293A (ja) * 2013-01-11 2013-05-09 Thomson Licensing インターネットプロトコルネットワークでのリアルタイムのオーディオ及びビデオデータの前方誤り訂正をサポートする方法
JP2019501566A (ja) * 2016-03-11 2019-01-17 ▲騰▼▲訊▼科技（深▲セン▼）有限公司 ビデオデータ冗長制御方法および装置
US10735029B2 (en) 2016-03-11 2020-08-04 Tencent Technology (Shenzhen) Company Limited Method and apparatus for encoding packets using video data redundancy control information
JP2020145523A (ja) * 2019-03-04 2020-09-10 日本電信電話株式会社 無線通信システムおよび無線通信方法
JP7338172B2 (ja) 2019-03-04 2023-09-05 日本電信電話株式会社 無線通信システムおよび無線通信方法
US11962408B2 (en) 2019-03-04 2024-04-16 Nippon Telegraph And Telephone Corporation Wireless communication system, and wireless communication method

Also Published As

Publication number Publication date
JP4349114B2 (ja) 2009-10-21
US7539925B2 (en) 2009-05-26
CN100377516C (zh) 2008-03-26
CN1638321A (zh) 2005-07-13
US20050160346A1 (en) 2005-07-21
KR20050056886A (ko) 2005-06-16

Similar Documents

Publication Publication Date Title
JP4349114B2 (ja) 送信装置および方法、受信装置および方法、記録媒体、並びにプログラム
JP2005136546A (ja) 送信装置および方法、記録媒体、並びにプログラム
KR100680671B1 (ko) 에러 정정용 데이터의 생성 방법 및 생성 장치와 생성 프로그램을 저장한 컴퓨터 판독가능한 기록 매체
JP5442816B2 (ja) 可変ｆｅｃオーバヘッド及び保護期間を利用したストリーミング及びバッファリング
JP5141197B2 (ja) 符号化装置
WO2017157303A1 (zh) 实时通信中的抗丢包方法、装置和系统
CN107257270B (zh) 基于混合自动重传请求的数据传输方法及系统
US7584404B2 (en) Method and apparatus for multimedia communication over packet channels
JP5094546B2 (ja) 通信装置、及び通信方法、プログラム
JP2004032719A (ja) Ｆｅｃ符号化方式に基づいた可変長パケット送信方法及び受信方法
US9781488B2 (en) Controlled adaptive rate switching system and method for media streaming over IP networks
JP2004517534A (ja) パケット・チャネルを介するマルチメディア通信のための方法
JP2020502832A (ja) データストリーミングの前方誤り訂正
JP5344541B2 (ja) データ送信装置、送信方法及びプログラム
US10334322B1 (en) System and method for media delivery on broadcast video networks
JP4362761B2 (ja) 送信装置および方法、記録媒体、並びにプログラム
US8472310B2 (en) Packet distribution band controlling method, distributing apparatus, and video distributing system
CN115550459A (zh) 语音数据的发送和接收方法以及相关设备
JP2005065100A (ja) データ配信方法、中継装置及びコンピュータプログラム
JP3730977B2 (ja) データ伝送方法およびデータ処理方法
JP4367287B2 (ja) 受信装置および方法、記録媒体、プログラム、並びに通信システム
WO2016203870A1 (ja) 送信装置、送信方法、及び通信システム
JP2005136547A (ja) 通信システム、受信装置および方法、送信装置および方法、記録媒体、並びにプログラム
JP2006304351A (ja) 無線通信方法および無線通信装置
JP2006314120A (ja) 無線通信方法

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20060927

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20081015

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20081021

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20081216

A02 Decision of refusal

Free format text: JAPANESE INTERMEDIATE CODE: A02

Effective date: 20090331

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20090528

A911 Transfer to examiner for re-examination before appeal (zenchi)

Free format text: JAPANESE INTERMEDIATE CODE: A911

Effective date: 20090612

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: 20090630

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20090713

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20120731

Year of fee payment: 3

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20120731

Year of fee payment: 3

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20130731

Year of fee payment: 4

LAPS Cancellation because of no payment of annual fees