JP2007508750A - Fecベース信頼度制御プロトコル - Google Patents

Fecベース信頼度制御プロトコル Download PDF

Info

Publication number
JP2007508750A
JP2007508750A JP2006534401A JP2006534401A JP2007508750A JP 2007508750 A JP2007508750 A JP 2007508750A JP 2006534401 A JP2006534401 A JP 2006534401A JP 2006534401 A JP2006534401 A JP 2006534401A JP 2007508750 A JP2007508750 A JP 2007508750A
Authority
JP
Japan
Prior art keywords
control protocol
block
transmitter
data
reliability control
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
JP2006534401A
Other languages
English (en)
Other versions
JP2007508750A5 (ja
JP4685787B2 (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 デジタル ファウンテン, インコーポレイテッド
Publication of JP2007508750A publication Critical patent/JP2007508750A/ja
Publication of JP2007508750A5 publication Critical patent/JP2007508750A5/ja
Application granted granted Critical
Publication of JP4685787B2 publication Critical patent/JP4685787B2/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
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • 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 systems
    • H04L1/1812Hybrid protocols; Hybrid automatic repeat request [HARQ]
    • H04L1/1819Hybrid protocols; Hybrid automatic repeat request [HARQ] with retransmission of additional or different redundancy
    • HELECTRICITY
    • H03ELECTRONIC CIRCUITRY
    • H03MCODING; DECODING; CODE CONVERSION IN GENERAL
    • H03M13/00Coding, 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/65Purpose and implementation aspects
    • H03M13/6522Intended application, e.g. transmission or communication standard
    • H03M13/6547TCP, UDP, IP and associated protocols, e.g. RTP
    • HELECTRICITY
    • H03ELECTRONIC CIRCUITRY
    • H03MCODING; DECODING; CODE CONVERSION IN GENERAL
    • H03M7/00Conversion of a code where information is represented by a given sequence or number of digits to a code where the same, similar or subset of information is represented by a different sequence or number of digits
    • 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 systems
    • H04L1/1867Arrangements specially adapted for the transmitter end
    • H04L1/1887Scheduling and prioritising arrangements
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/28Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/163In-band adaptation of TCP data exchange; In-band control procedures
    • HELECTRICITY
    • H03ELECTRONIC CIRCUITRY
    • H03MCODING; DECODING; CODE CONVERSION IN GENERAL
    • H03M13/00Coding, 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/37Decoding methods or techniques, not specific to the particular type of coding provided for in groups H03M13/03 - H03M13/35
    • H03M13/3761Decoding methods or techniques, not specific to the particular type of coding provided for in groups H03M13/03 - H03M13/35 using code combining, i.e. using combining of codeword portions which may have been transmitted separately, e.g. Digital Fountain codes, Raptor codes or Luby Transform [LT] codes

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Probability & Statistics with Applications (AREA)
  • Communication Control (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Detection And Prevention Of Errors In Transmission (AREA)

Abstract

転送するデータを各々が複数の符号化ユニットを含むデータブロックに編成しデータを送信機から受信機まで確実に転送する転送システムにおいて、送信機から受信機に第1データブロックの符号化ユニットを送信し、送信機において受信機による符号化ユニット受信の肯定応答を検出する。送信機において、受信機が第1データブロックを回復するための第1データブロックの充分な符号化ユニットを受信したという確率を検出し、その確率が予め定められたテストを満たすかどうか判定するため閾値確率に対してテストする。テストのステップに続いて、予め定められたテストが満たされるとき、送信機が受信機で第1データブロックの回復の受信確認に先立って、送信機から第2データブロックの符号化ユニットを送信する。送信機において第1データブロックの回復失敗の指示が受信された場合、送信機から受信機へ第1データブロックの更なる符号化ユニットを送信する。いくつかの実施形態では、予め定められたテストは閾値確率に対する確率の比較であり、確率が閾値確率より大きいときに予め定められたテストは満たされる。

Description

本発明は、通信システムのデータの符号化および復号化に関する。より具体的には、本発明は、通信データの誤りおよびギャップを考慮しデータを符号化および復号化する通信システムに関する。実施例において、データは、ブロードキャストおよび/またはマルチキャスト無線ネットワークを介して受信機に転送される。
本発明は、データ通信ネットワークを介したエンドシステム間での高速なデータ伝送の問題に関連する。
多くのデータ通信方式および高水準データ通信プロトコルは、高信頼のデータ転送の便利な通信抽象化を提供し、また、速度制御を提供する。すなわち、ネットワークの状態に基づいて自動的にそれらのパケット伝送速度を調整する。以下の状況のうちの少なくとも1つが生じる際、例えば、遍在するTransport Control Protocol (TCP)のような下位レベルパケット化データ転送に関する従来の実施態様は影響を受ける。(a)送信機および受信機の接続が大きなラウンドトリップ時間(RTT)を有する。(b)データ量が大きく、ネットワークにバースト的・一時的なロスが発生している。
今日最も広く使われている高信頼の転送プロトコルのうちの1つは、Transport Control Protocol (TCP)である。TCPは、肯定応答メカニズムを有する汎用のポイントツーポイントパケット制御方式である。TCPは、送信機および受信機の間にほとんどロスがなく、送信機および受信機の間のRTTが小さい1対1の高信頼通信のために適切に動作する。しかしながら、少しでもロスがあるか、あるいは、送信機および受信機が遠く離れている場合には、TCPのスループットは大幅に減少する。
TCPを使用して、送信機は順序付けたパケットを送信し、受信機は各々のパケットの受信を肯定応答する。パケットが消失する場合肯定応答は送信機に送信されず、送信機はパケットを再送する。TCPなどのプロトコル使用すると、肯定応答パラダイムにより、肯定応答の欠落に応答して、または受信者からの明示的要求に応答して損失パケットが単に再送され得るので、パケット送信は完全には失敗しない。
TCPは信頼度管理および速度制御を提供する。すなわち、オリジナルデータの全てが受信機に配信されることを確保し、輻輳およびパケット損失などのネットワークの状態に基づいて自動的にパケット伝送速度を調整する。TCPでは、信頼性制御プロトコルおよび速度制御プロトコルは関連しあっており分離可能でない。RTTの増加およびパケット損失の関数としてのTCPのスループットパフォーマンスは決して最適ではない。
多くの研究者による研究は、TCPを使用するときデータ転送のスループットは、エンドツーエンド接続においてRTTおよび損失率の逆二乗根の積に反比例することを示した。たとえば、米国およびヨーロッパの間の典型的エンドツーエンド型地上接続は、200ミリ秒のRTTおよび2%の平均パケット損失を有する。これらの条件下では、TCP接続のスループットは、エンドツーエンドでどれだけ多くの帯域幅があったとしても1秒につき多くても約300−400キロバイト(kbps)である。大きなRTT、および、大気によるさまざまな影響のために情報が消失する衛星リンクにおいて状況はより厳しい。この種の状況下においてTCPのパフォーマンスが低下する主要な理由は、TCPによって使用される速度制御プロトコルがこれらの状況で適切に動作しないことにある。TCPでは信頼性制御プロトコルおよび速度制御プロトコルが分離できないため、これはTCPプロトコル全体がこれらの状況下で適切に動作しないことを意味する。さらにまた、転送のアプリケーションが異なると必要条件は変化するが、TCPが全てのネットワーク状態の種々のアプリケーションに対し普遍的に使用されている。そのため、結果として多くの状況においてパフォーマンスが低下することになる。
転送プロトコル全体において、使用する信頼度管理および速度制御プロトコルが独立していることが望ましく、そうすることにより、アプリケーションの要求条件およびアプリケーションの動作するネットワークの状態に基づいて、実際に速度制御プロトコルを選択し、同じ信頼性制御プロトコルを種々の異なる速度制御プロトコルと共に使用することが可能となる。
Micah Adler, Yair Bartal, John Byers, Michael Luby, Danny Razによる、1997年6月のFifth Israeli Symposium on Theory of Computing and Systemsのプロシーディングの論文”A Modular Analysis of Network Transmission Protocols”(以降”アドラー”と呼び本願明細書において引用したものとする)において、モジュール化による転送プロトコルの構築方法を紹介し、高信頼転送プロトコルを独立した信頼度管理と速度制御に分離することを主唱する。
いかなる信頼性制御プロトコルにおいても、そのパフォーマンスの2つの主要な指標は、バッファの必要量およびその”グッドプット”である。バッファリングは、送信機および受信機の信頼性制御プロトコルにおいて導入される。たとえば、送信機のバッファリングは、データが最初に送信されたあと受信機で受信された肯定応答を送信機が受信するまでデータはバッファするときに生じる。受信機のバッファリングは、類似した理由のために生じる。バッファリングは、2つの理由のために重要である。(1)送信機および受信機の信頼性制御プロトコルがどれくらいのメモリーを使用するかに直接影響を与える。(2)送信機および受信機の信頼性制御プロトコルがどれくらいの時間遅延をもたらすかに直接影響を与える。グッドプットは、転送中に受信エンドシステムで受信される送信データの量に分割された転送データのサイズとして定義される。たとえば、オリジナルデータを転送するためパケットとして送信されたデータ量がオリジナルデータのサイズである場合グッドプット=1.0であり、グッドプット=1.0は冗長データが全く転送されないときに達成される。
アドラーは使用する速度制御プロトコルから大きく独立している信頼性制御プロトコルを概説し、以降”非コード信頼度制御プロトコル”と呼ぶ。非コード信頼度制御プロトコルは、オリジナルデータがブロックに仕切られ各々のブロックがパケットペイロードにより送信されるという意味で、TCPに埋め込まれた信頼度制御プロトコルにいくらか類似しており、高信頼の転送を確保するために各々のブロックの正確なコピーが受信されることを要する。非コード信頼度制御プロトコルの問題は、グッドプットは最適(基本的に1に等しい)であるが、パケット損失があるときに非コード信頼度制御プロトコルは相当のバッファを必要とすることである。アドラーは、送信機および受信機で必要とされるバッファの量を最小化する観点から最適なグッドプットおよび確かさから最適となる定数因子となるように、非コード信頼度制御プロトコルがデータ転送に符号化を用いない信頼度管理プロトコルの中で最適となる定数因子であるということを証明している。
信頼性制御プロトコルに使用される1つのソリューションは、リード−ソロモン符号またはトルネード符号のような前方誤り訂正(FEC)符号、または、情報付加符号である連鎖反応符号である。FEC符号を使用するときには、パケットのペイロードより大きいオリジナルデータはブロックに区切られ、符号化ユニットはこれらのブロックから生成され、パケットとして符号化ユニットは送信される。符号化を使用しない信頼性制御プロトコルに対するこのアプローチの基本的な利点は、応答がよりシンプルとなりより少ない頻度でありえるということである。すなわち、受信機は、各々のブロックについて、送信機に、正確にどの符号化ユニットが受信されたかを示すリストの代わりに受信された符号化ユニットの量を指示すればよいだけである。さらにまた、全体としてオリジナルデータブロックの長さより多くの符号化ユニットを生成し送信する能力は、信頼性制御プロトコルの設計の強力なツールとなる。
リード−ソロモン符号またはトルネード符号のような消去修正符号は、固定長ブロックの符号化ユニットを固定数だけ生成する。たとえば、B個の入力ユニットを含むブロックに対し、N個の符号化ユニットが生成される。これらN個の符号化ユニットは、B個のオリジナル入力ユニットおよびN−B個の冗長ユニットを含み得る。記憶装置が許す場合、送信機は一度だけ各々のブロックの符号化ユニット群を計算しカルーセルプロトコルを用い符号化ユニットを送信することができる。
いくつかのFEC符号に関する1つの問題は、過大な演算能力または動作メモリを必要とするということである。他の問題は、必要とされる符号化ユニットの数が符号化処理に先立って決定されなければならないということである。これは、パケット損失率が過大評価される場合結果として非効率性を生じ、パケット損失率が過小評価される場合結果として失敗を生じる。
従来のFEC符号では、生成可能な符号化ユニットの数は、ブロックに区切られる入力ユニットの数と同程度である。排他的にでないが、一般的に、これらの符号化ユニットのほとんどまたは全ては、送信ステップ前の前処理ステップで生成される。これらの符号化ユニットは、オリジナルブロックと等しいかわずかに長さの符号化ユニットのいかなるサブセットからも全入力ユニットが再生できるという特性を有する。
米国特許第6,307,487号(以降、”ルビーI”と呼び本願明細書において引用したものとする)に記載されている連鎖反応復号化は、上記の問題に対処する前方誤り訂正の形式を提供できる。連鎖反応符号において、生成可能な符号化ユニットのプールは、入力ユニットに比較し数桁大きい程度あり、プールからランダムまたは疑似ランダムに選択された符号化ユニットは、非常にすばやく生成されうる。連鎖反応符号では、符号化ユニットは、送信ステップと同時に”必要に応じて”を原則に即座に生成される。連鎖反応符号では、オリジナルコンテンツよりわずかに長いランダムまたは疑似ランダムに生成された符号化ユニット群のサブセットからコンテンツの全入力ユニットを再生可能である。
米国特許第6,320,520号,第6,373,406号,第6,614,366号,第6,411,223号,第6,486,803号および米国特許公開番号20030058958(以降、”ショクロラヒI”と呼び本願明細書において引用したものとする)のような他の文書はさまざまな連鎖反応符号体系を述べており、本願明細書に引用したものとする。
連鎖反応符号を使用している送信機は、送信される各々のブロックの符号化ユニットを連続的に生成できる。符号化ユニットは、User Datagram Protocol(UDP)のユニキャストまたは適用可能であればUDPマルチキャストを介して、受信機に送信される。各々の受信機は復号化装置を備えていると仮定され、オリジナルブロックを得るため、パケットとして受信される符号化ユニットを適切な数だけ復号化する。
デジタルファウンテン(Digital Fountain)から入手可能なトランスポーターファウンテン(Transporter Fountain)ネットワーク装置において利用可能な転送装置の1つは、シンプルなFECベースの信頼度制御プロトコルを使用する高信頼転送プロトコルであり、種々の速度制御プロトコルと合わせて利用可能である。シンプルなFECベースの信頼性制御プロトコルを以降では”TF信頼度制御プロトコル”と呼ぶ。TF信頼度制御プロトコルは、ブロックを回復するための十分な符号化ユニットが受信されたことを示す受信機からの肯定応答を受信するまで、所与のデータブロックの符号化ユニットを送信し、肯定応答を受信すると次ブロックへ移動する。
RTTを送信機がパケットを送信してから送信機がパケットが到着した受信機から肯定応答を受信するまでの秒数、Rをパケット/秒を単位とした送信機における現在の送信速度、Bをパケットを単位としたブロックサイズとする。TF信頼度制御プロトコルを使用すると、ブロックを回復するために必要な最後のパケットの後に送信されるブロックの符号化ユニットを含む役立たないパケットの数は、N=R*RTTである。そのため、送信されたパケットの割合f=N/(B+N)は無駄となり、グッドプットは大きくとも1−fである。たとえば、R=1,000パケット/秒、RTT=1秒、そして、B=3,000パケットのとき、F=0.25である。すなわち、受信されたパケットの25%が無駄となる。そのため、この例でグッドプットは最大グッドプット1.0に比較し低い0.75となる。
また、この速度RとブロックサイズBによる例では、シンプルなFECベースの信頼度制御プロトコルにより生じる時間遅延は少なくとも4秒であり(各々のブロックは計4秒で送信される)、少なくとも1個のブロック(すなわち、データの3,000パケット)をバッファリングすることを必要とすることを意味する点に注意する。さらにまた、グッドプットを増加させると必要バッファも増加する、逆にいえば、バッファを減少させるためにはグッドプットを減少させることは必要である。
上述にかんがみ信頼度管理の改善が望ましく、グッドプットおよびバッファサイズの間により良好なトレードオフを有する信頼度管理プロトコルを提供する。
本発明の実施例に従う転送システムにおいて、転送されるデータを各々が複数の符号化ユニットを含むデータブロックに編成し、第1データブロックの符号化ユニットを前記送信機から前記受信機へ送信し、前記送信機において、前記受信機による符号化ユニット受信の肯定応答を検出することによりデータを送信機から受信機へ高信頼に転送する。送信機において、前記第1データブロックを回復するため前記受信機で該第1データブロックの十分な符号化ユニットを受信した確率が検出され、所定のテストを満足するどうか決定するため前記確率は閾値確率に対してテストされる。前記テストのステップの後かつ前記送信機が前記受信機での前記第1データブロックの回復の確認を受信する前において、前記所定のテストを満足するとき前記送信機から第2データブロックの符号化ユニットを送信する。前記送信機が前記第1データブロックの回復の失敗の指示を受信したとき、送信機から受信機へ前記第1データブロックの更なる符号化ユニットを送信する。いくつかの実施例では、所定のテストは閾値確率に対する確率の比較であり、確率が閾値確率より大きいときに所定のテストは満たされる。
グッドプットおよびバッファサイズの間の非常により良好なトレードオフを有する信頼度管理プロトコルを提供することができる。
(関連出願の相互参照)
本出願は、2003年10月8日に出願された”FEC-BASED RELIABILITY CONTROL PROTOCOLS”の名称の米国特許出願番号60/509,976号に基づく優先権を主張し、全ての目的のために、この文書に記載される全てを本願明細書に引用する。
本発明の実施例において、TCP、TF信頼度制御プロトコルおよび非コード信頼度制御プロトコルを改善するためインタリーブ信頼度制御プロトコルを利用する。信頼度制御プロトコルについては、データのブロックは送信機から受信機へ一連の符号化ユニットとして送信され、受信機は符号化ユニットあるいはブロックの回復を肯定応答する。このため、送信機は受信機がデータを受信したかどうかを判定可能となり、受信されない場合は、データを再送信するは、あるいは、受信データを回復可能に有用な他のデータを送信する。いくつかのインタリーブ信頼度制御プロトコルの特性の1つは、異なるブロックの符号化ユニットがインターリーブされて送信されるということである。インタリーブ信頼度制御プロトコルは、実質的に速度制御プロトコルを組み合わされる場合、エンドシステムでバッファリング(および、それに伴う時間遅延)を最小化する効率的な高信頼データ転送を提供し、転送のグッドプットを最大にする。
インタリーブ信頼度制御プロトコルは、高い損失および/または大きいRTTがあるときでも、高スループットを維持し高信頼のデータ転送を確保するため適当な速度制御プロトコルと共に利用することが出来る。例えば、速度制御プロトコルは固定速度(レート)で送信するだけの単純なものでも良く、インターリーブ信頼性制御プロトコルは、転送時にバッファリングおよび時間遅延が最小化されている間は、固定速度と到着パケットの割合との積で示される速度でデータが転送されることを保証する。
ここで紹介するインタリーブ信頼度制御プロトコルにより提供される定量的な改善例では、速度制御プロトコルは1秒につきRパケットの固定レートでパケットを送信し、送信機および受信機の間の往復時間はRTT秒であり、従って、N=R*RTTは転送中の肯定応答のされていないパケット数であることを仮定する。非コード信頼度制御プロトコルにおいて、送信機の総バッファサイズは少なくともN*ln(N)であり、グッドプットはおよそ1.0である。そして、バッファ必要量およびグッドプットの間には他のトレードオフ位置がない。ここで、ln(x)は、xの自然対数として定義される。TF信頼度制御プロトコルにおいて、送信機の総バッファサイズは少なくともBであり、グッドプットはおよそB/(B+N)である。ここで、Bはパケットを単位として選択されたブロックサイズであって、グッドプットに対するバッファ必要量のトレードオフを選択可能である。対照的に、インタリーブ信頼度制御プロトコルにおいて、送信機の総バッファサイズは最大でもBであり、グッドプットはおよそN/(N+X)である。ここで、Xはグッドプットに対するバッファ必要量のトレードオフにより選択される自然数のパラメータであり、B=N*(1+ln((N/X)+1))はパケットを単位とするバッファサイズである。
例えば、速度Rが1000パケット/秒でありRTTが1秒である場合、N=1000パケットである。そして、非コード信頼度制御プロトコルでは、送信機のバッファサイズは少なくとも7,000パケットである。TF信頼度制御プロトコルでは、Bが4,000パケットとして選択される場合、グッドプットはおよそ0.80となる。Xが50と選択され、B=4000パケット(TF信頼度制御プロトコルの場合と同じ値)であるインタリーブ信頼度制御プロトコルでは、グッドプットは0.95を上回る。すなわち、無駄になる受信パケットは多くても5%である。そのため、この例においては、インタリーブ信頼度制御プロトコルは、ほぼ同じ最適グッドプットの非コード信頼度制御プロトコルに対しはるかにバッファを必要とせず、同一バッファ量のTF信頼度制御プロトコルのグッドプットをはるかに上回る。すなわち、インターリーブ信頼性制御プロトコルでは多くても5%が無駄になるだけなのに対しTF信頼性制御プロトコルでは25%となる。
実質的に全ての速度制御プロトコルは、高信頼の転送プロトコルを提供するため、インターリーブ信頼性制御プロトコルによって利用可能である。例えば、固定速度で送信するか、TCPに類似したウインドウベースの輻輳制御を使用するか、均衡化ベースの輻輳制御プロトコル(例えばTCPフレンドリ速度制御(TFRC))を使用するか、その他のほぼ任意の速度制御プロトコルを使用可能である。
<3.高信頼転送プロトコル>
本明細書において、高信頼転送プロトコルは、送信されたパケットのいくつかは受信されない可能性があるときでも全てのデータが転送されるというような方法で、パケットベースのネットワークを介して送信エンドシステムから受信エンドシステムまで確実にデータを転送するプロトコルである。図1は、高信頼転送プロトコルが動作しうる、ネットワーク130、および、送信エンドシステム100(1),...,100(J)と受信エンドシステム160(1),...,160(K)の一群を例示する図である。一般的に、この種のプロトコルもパケット送信速度を調整するためのいくつかのメカニズムを含んでいる。この送信速度は、プロトコルが構築されるアプリケーションを含む種々の要因、ユーザー入力パラメータ、および、送信および受信エンドシステム間のネットワークの状態に依存し得る。
高信頼転送プロトコル(例えばTCP)は、一般的にいくつかのステップを含む。これらのステップは、エンドシステムにおいて、データが利用可能であることを通知し、他のエンドシステムにデータ転送を始め、どのデータを転送するかを通信し、高信頼のデータ転送を実行する方法を含む。エンドシステムにおいて、利用可能性の通知、転送の開始、および、転送されるものの通信のための種々の標準的な方法があり、例えば、セッション通知プロトコル(session announcement protocols)、セション開始プロトコル(session initiation protocols)などがある。これらのステップは周知であるため、ここでは詳細には記載しない。
高信頼のパケットデータの転送は、転送の各々の時点でパケットのどのデータを送信しどのレートでパケットを送信するかの決定を含む。各時点でなされる決定は、受信エンドシステムから送信される応答あるいは他の要素に依存し得る。一般的に、データは、送信エンドシステムにおいてデータのストリームとして提供され、高信頼転送プロトコルはこのストリームが送信された順序で受信エンドシステムに確実に配信する。しばしば、転送が開始される前にストリームの全長が未知の場合がある。
<4.高信頼転送プロトコルのモジュール化アーキテクチャ>
アドラーは、信頼度制御プロトコルおよび速度制御プロトコルを組合せることにより、高信頼転送プロトコルがどのように案出可能かについて記述している。信頼度制御プロトコルは、転送プロトコル全体のうち、転送中に各々のパケットにどのデータを配置するかを決定する部分である。速度制御プロトコルは、各々のデータパケットをいつ送信するかについて決定する。多くの転送プロトコルにおいて、信頼度管理および速度制御プロトコルは動作中には不可分に関連しあっている。すなわち、TCPはこの場合に当てはまる。しかしながら、この種の関連しあうプロトコルであっても概念的には信頼度制御プロトコルおよび速度制御プロトコルに区分可能である場合もある。
アドラーは、信頼度制御プロトコルおよび速度制御プロトコルをそれぞれ独立に設計する高信頼転送プロトコルの設計を提唱する。この種の方法を採用することにより同一の信頼度制御プロトコルが種々の速度制御プロトコルと共に使用可能となり、そのため同一の信頼度制御プロトコルを、アプリケーションおよび全体の高信頼転送プロトコルが使用されるネットワークの状態に応じた適切な速度制御プロトコルと共に使用可能となる。異なるアプリケーションおよびネットワーク環境において同一の信頼度制御プロトコルを多様な速度制御プロトコル群と共に使用可能であため、設計におけるこのモジュール化による方法は非常に有利であり、そのため、各々のアプリケーションおよびネットワーク環境に対し高信頼転送プロトコル全体の完全な再設計を回避することが出来る。たとえば、TCPは異なるネットワーク環境で種々のアプリケーションにより使用されているが、いくつかのアプリケーションおよびネットワーク環境においては、速度制御プロトコルによって決定される低いスループットにより十分な性能を発揮しない。残念なことに、TCPアーキテクチャにおいては、信頼度制御プロトコルおよび速度制御プロトコルが非常に絡み合っているので、十分な性能を発揮しない状況でのスループットパフォーマンスを高めるためにTCPの中で異なる速度制御プロトコルを使用することは出来ない。
図2は、アドラーにより提唱されるモジュール化された高信頼転送プロトコルの構造の具体例である。送信転送プロトコル210は、送信信頼度制御プロトコル220および送信速度制御プロトコル230に区分される。送信信頼度制御プロトコル220は各々のデータパケットにおいて何が送信するかを決定し、送信速度制御プロトコル230は各々のデータパケットをいつ送信するかを決定する。送信信頼度制御プロトコル220は、受信転送プロトコル290の受信信頼度制御プロトコル280により使用可能な付加的な信頼度制御情報を各々のデータパケットに入れることができる。送信信頼度制御プロトコル220は、また、受信転送プロトコル290の対応する受信信頼度制御プロトコル280から、各々のデータパケットにおいて何が送信されたかを決定するのに役立つ信頼度制御情報250を受信できる。同様に、送信速度制御プロトコル230は、受信転送プロトコル290の受信速度制御プロトコル270により使用可能な速度制御情報を各々のデータパケットに入れることができる。送信速度制御プロトコル230は、また、受信転送プロトコル290の対応する受信速度プロトコル270から、各々のデータパケットがいつ送信されたかを決定するのに役立つ速度制御情報250を受信できる。
送信信頼度プロトコル220および受信信頼度プロトコル280の間で転送される信頼度制御情報は、パケット損失のような種々の要因に依存し、後述するいくつかの各種詳細情報を含むことができる。同様に、送信速度制御プロトコル230および受信速度制御プロトコル270の間で転送される速度制御情報は、パケット損失および測定された往復時間(RTT)などの種々の要因に依存する。さらにまた、データパケット240または応答パケット250において送信される情報が信頼度制御および速度制御のために使用されるように、信頼度制御情報および速度制御情報をオーバーラップさせることができる。通常、送信転送プロトコル210から受信転送プロトコル290まで送信される信頼度管理および速度制御情報は、データパケット240のデータ、分離された制御パケット240、あるいは、その両方によって送信される。これらのプロトコルは、送信機から受信機、あるいは、受信機から送信機に送信が必要な制御情報量を最小化するように設計されていなければならない。
多くのアプリケーションでは、データはストリームとして転送される。すなわち、データは送信エンドシステムに到着すると、送信エンドシステムに到着するのと同じ順序で可及的速やかに受信エンドシステムに高信頼に転送される。例えば、ストリーミングアプリケーションや小さなバーストデータが可及的速やかに2つのエンドシステム間で双方向に送信される対話型アプリケーションなどのアプリケーションによっては、転送プロトコル全体により生じる時間遅延は最小化されなければならない。
送信信頼度制御プロトコル220および受信信頼度制御プロトコル280は、一般的に両方ともデータを一時的に格納するバッファを必要とする。通常、送信信頼度制御プロトコル220でバッファされるデータは、少なくとも、送信信頼度制御プロトコル220が受信信頼度制御プロトコル280から回復の肯定応答をまだ受信していないストリームの最も初期のデータから送信信頼度制御プロトコル220がデータパケットを送信開始したストリームの最新のデータまでを含む。受信信頼度制御プロトコル280でのバッファサイズは、一般に少なくとも、受信されたデータパケットのうちがまだ回復されない最も初期のデータから最新のデータまでストリームのデータ量である。
送信信頼度制御プロトコル220のバッファ必要条件は、送信信頼度制御プロトコル220によりどれだけの一時記憶領域が必要とされるか、また、送信信頼度制御プロトコル220が信頼性のあるデータ転送全体にどれだけの時間遅延を与えるかに直接影響する。受信信頼度制御プロトコル280のバッファ必要条件も類似した影響を与える。このように、送信信頼度制御プロトコル220および受信信頼度制御プロトコル280のバッファ必要条件を最小化することは重要である。
信頼度制御プロトコルは、各々のデータパケットにおいて何が送信されるかを決定する。効率的にエンドシステム間の接続を利用するため、受信信頼性制御プロトコル280で受信されるどんなデータパケットでもオリジナルデータストリームの一部分を回復することに役立つが、送信信頼度制御プロトコル220がパケットの冗長データを可能な限り少なくすることは重要である。信頼度制御プロトコルのグッドプットは、データのオリジナルストリームの回復の間受信信頼度制御プロトコル280により受信されるデータのオリジナルストリームの長さをデータパケット全長で除することにより定義される。グッドプットの目標は、信頼度制御プロトコルにおいてグッドプット1.0あるいはその程度の結果となることである。そのとき、データのオリジナルストリームを回復するために受信されるデータ量は最小となる。いくつかの信頼度制御プロトコルにおいてグッドプットは1.0未満であり、そのとき、いくつかの送信データパケットは無駄となっている。このように、グッドプットを可能な限り1.0に近づけるように信頼度制御プロトコルを設計することは、送信エンドシステムから受信エンドシステムまで転送されるデータパケットにより消費される帯域幅を効率的に使用するため重要である。
<5.FECベースの信頼度制御プロトコル>
信頼度制御プロトコルとして用いられている1つの解は、例えばリード−ソロモン符号、トルネード符号、あるいは、情報付加コードである連鎖反応コードのような前方誤り訂正(FEC)符号である。パケットのペイロードより大きいオリジナルデータはブロックに区切られ、符号化ユニットはこれらのブロックから生成され、パケットとして符号化ユニットを送信する。リード−ソロモン符号やトルネード符号のような消去修正符号は、固定長ブロックの固定数の符号化ユニットを生成する。たとえば、入力ユニットを含んでいるブロックでは、N個の符号化ユニットが生成される得る。これらのN個の符号化ユニットは、B個のオリジナルの入力ユニットおよびN−B個の冗長ユニットを含み得る。
FECベースの信頼度制御プロトコルは、FEC符号を使用する信頼度制御プロトコルである。図3は送信FECベース信頼度制御プロトコル220の例示図であり、図4は受信FECベース信頼度制御プロトコル280の例示図である。送信信頼度制御ロジック310は、データのオリジナルストリームをデータブロック330に区切って、FEC符号器320に各々のブロックに対し符号化ユニットを生成するよう指示する。送信信頼度制御ロジック310は、符号化ユニットおよび信頼度制御情報340を送信速度制御プロトコル230を処理しているデバイスにどのように通知するかを決定し、また、図4に示されるFECベース信頼度制御ロジック410により送信される信頼度制御情報350を処理する。
送信信頼度制御ロジック310は、各々のブロックの回復を確保するため、図4に示される受信FECベース信頼度制御プロトコル280により十分な符号化ユニットが受信されることを確保する。全てのブロックは基本的に同じ長さであってもよいし、ブロック長は転送中に種々のパラメータ(送信機で利用可能なデータのストリームの速度、データパケットの送信速度、ネットワークの状態、アプリケーションによる要求およびユーザーの要求)の関数として動的に変化させてもよい。
予め指定されるデータブロックをB個の符号化ユニットの長さであると仮定する。あるFECコードではオリジナルデータブロックを回復するのに必要な符号化ユニットの数は正確にB個であるが、他のFECコードではオリジナルデータブロックを回復するのに必要な符号化ユニットの数はB個よりわずかに大きい。FECベース信頼度制御プロトコルの説明を単純化するために、データブロックを回復するのにB個の符号化ユニットで充分であると仮定する。ここで、FECコードはブロックを復号するためB個より多くの符号化ユニットを必要とするためグッドプットはわずかに減少し、また、わずかに多くのバッファを要求することが理解されよう。
図4の受信信頼度制御ロジック410はデータブロックを復号化するためB個の符号化ユニットの受信を確保する役割を果たし、FEC復号器420はデータブロック430を回復するために用いられる。受信信頼度制御ロジック410は符号化ユニットおよび送信FECベース信頼度制御プロトコル220から送られる信頼度制御情報340を受信する役割を果たし、偶発的に送信され送信信頼度制御ロジック310によって処理される信頼度制御情報350を生成し送信する。
<6.TF信頼度制御プロトコル>
TF信頼度制御プロトコルは、データのストリームを一般に等しいサイズのブロックに区切る。全体アーキテクチャは、いかなる時点においてもアクティブなデータブロックは1つであり、送信機はブロックの復元に十分な符号化ユニットを受信したという指示のメッセージを受信し次のブロックへ移動するまでデータブロックの符号化ユニットを生成し送信する。このように、所与のブロックの全ての符号化ユニットが生成され送信されて、次のブロックのいかなる符号化ユニットが生成され送信される前にブロックは回復される。
図5は、TF信頼度制御プロトコルによって使用可能なフォーマットの1セットである。送信データフォーマットは、送信TF信頼度制御プロトコルが符号化ユニットおよび対応する信頼度制御情報を受信TF信頼度制御プロトコルに送信するフォーマットを示している。これは、符号化ユニットがどのブロックから生成されたを指示するブロック番号510、符号化ユニットがどのようにブロックから生成されたかを指示する符号化ユニットID520、および、ブロックを回復するために受信TF信頼性制御プロトコルのFEC復号器によって使用可能な符号化ユニット530を含む。受信応答フォーマットは、受信TF信頼度制御プロトコルが信頼度制御情報を送信TF信頼度制御プロトコルに送信するフォーマットを示している。これは、ブロックを回復するために受信TF信頼度制御プロトコルが受信している符号化ユニットの現在のブロックのブロック番号であるブロック番号540、および、受信TF信頼度制御プロトコルがブロックを回復するのに必要とされるさらなる符号化ユニットの数である必要符号化ユニット550を含む。
図6は、送信TF信頼度制御プロトコルを実装するための処理を例示する図である。処理は送信データを送信する時間であるかどうかを絶えずチェックする(ステップ610)。送信する時間である場合、符号化ユニットからアクティブブロックを生成し、送信データを送信する(620)。送信データのフォーマットの例は、図5に示されるフォーマットである。処理は、また、受信応答があったどうかを絶えずチェックする(630)。受信応答データのフォーマットの例は、図5に示されるフォーマットである。受信応答がある場合、受信機がアクティブブロックを回復するために何個の更なる符号化ユニットを必要とするかという情報を更新する。そして、必要とされる符号化ユニットの数がゼロであるかどうかをチェックし(640)、ゼロの場合データのストリームの次のブロックが利用可能になる(650)。利用可能でない場合、それが利用可能となるまで次のブロックを準備し(660)、現在のアクティブブロックを停止させ、次のブロックをアクティブ化する(670)。通常は、現在のアクティブブロックが送信される間に次ブロックは準備され得る。
本願明細書において記載されている各々のプロトコルは、デバイス、または、適切なプロセッサによって実行されるソフトウェアまたはファームウェアにより実現され得ることが理解される。たとえば、ルーターおよびホストコンピュータのようなネットワーク装置を使用して実現することも出来るし、同様に、ワイヤレス送信機、再送信機およびその他の無線デバイスにより実現することも出来る。記載されているプロトコルは、この種のプロトコルを実装するように構成される方法および/または装置を有するソフトウェアとして実現することも出来る。
図7は、受信TF信頼度制御プロトコルを実装するための処理を例示する図である。受信TF信頼度制御プロトコルは、図5に示される送信データフォーマットを用いて送信データを受信したかを絶えずチェックする(710)。受信した場合、送信データ内の符号化ユニットがアクティブブロックのものかどうかがチェックされる(720)。符号化ユニットがアクティブブロックのものでない場合破棄され(760)、そのためいかなるブロックも回復するのに役立たないためこれは無駄な送信データである。符号化ユニットがアクティブブロックのものである場合、アクティブブロックのためにすでに受信された符号化ユニットの一群に追加し、ブロックの符号化ユニットの必要数を1だけデクリメントする(730)。そして、符号化ユニットの必要数がゼロであるかどうかチェックし(740)、ゼロである場合FEC復号器を用いアクティブブロックを回復して、次のアクティブブロック750の符号化ユニットの受信に備える(750)。受信TF信頼度制御プロトコルも、対応する受信速度制御プロトコルで決定される受信応答を送信する時間であるかどうか絶えずチェックする(770)。送信する時間である場合、図5に示される受信応答フォーマットの受信応答を準備し送信する(780)。
これはTF信頼度制御プロトコル全体の一部の説明である点に注意する。たとえば、受信応答が受信TF信頼度制御プロトコルによって送信される状況に限定されない。受信された送信データの受信、時折発するタイマー、これらのイベントのいかなる組合せまたは受信速度制御プロトコルによって決定される他のいかなるイベントが送信のトリガとなり得る。通常、受信応答は、受信TF信頼度制御プロトコルが送信TF信頼度制御プロトコルに定期的に符号化ユニットの受信の進捗を知らせるように十分な頻度で送信され、送信TF信頼度制御プロトコルから受信TF信頼度制御プロトコルまで送信される符号化ユニットを含んでいる送信データとほぼ同程度の帯域幅を消費することのない頻度で送信する。
TF信頼度制御プロトコルが以下の意味において”無駄”とみなされ得る点に注意する。Bを符号化ユニットを単位にする各々のデータブロックのサイズ、Rを速度制御プロトコルによってパケットが送信される速度、RTTを送信および受信エンドシステム間の往復時間、そして、N=R*RTTとする。そして、パケット損失が送信機および受信機の間にないと仮定する。その場合、送信TF信頼度制御プロトコルがアクティブブロックのB個の符号化ユニット(ブロックの回復に十分である)を送信した後、受信TF信頼度制御プロトコルからブロックを回復するのに十分な符号化ユニットを受信したことを指示する受信応答を受信するまでN個の付加的な符号化ユニットを送信し続けるため、N個の符号化ユニットの全てが無駄となる。長さBのブロックを回復するにはB+N個の符号化ユニットを送信することが必要であるため、グッドプットはB/(B+N)である。BがNと比較して比較的小さい場合グッドプットは望ましい値から程遠くなり、送信機および受信機間の多くの使用帯域幅は無駄になる。一方、BがNと比較して大きい場合送信および受信TF信頼度制御プロトコルのバッファサイズが大きくなり得るため、受信機におけるデータストリーム配信の時間遅延が大きくなる。例えば、符号化ユニットのサイズを1キロバイト、速度Rを1秒につき1,000個の符号化ユニット(=1メガバイト/秒=8メガビット/秒)そして、RTTが1秒であると仮定する。そのとき、N=R*RTT=1メガバイトである。ブロックのサイズをB=3メガバイトに設定する場合、グッドプットはおよそ(B/(B+N))=0.75しかない。すなわち、送信された符号化ユニットの約25%は無駄になる。たとえば、送信される符号化ユニットの無駄が約2%になるようにグッドプットを0.98に増やすためには、B=49メガバイトとなる非常に大きなバッファサイズが必要となる。このサイズバッファは、結果として信頼度制御プロトコルによる少なくとも50秒の時間遅延をもたらす。
上述したTF信頼度制御プロトコルには多くの変形がある。たとえば、送信TF信頼度制御プロトコルはブロックからのB個の符号化ユニットを送信した後符号化ユニットの送信を止め、ブロックを回復するための十分な符号化ユニットが受信されたかどうかを指示する受信応答の受信待機をすることができる。損失がない場合、この変形は無駄になるいかなる符号化ユニットも送信しない。しかし、この場合においてもRTT時間のギャップが各々のブロック間にあるため、帯域幅が他のために使われていない場合このプロトコルはまだ結果としてR*RTTの帯域幅の無駄を生じる。さらにまた、総配送時間は理想的な場合に比較しB/(B+N)倍遅くなる。損失がある場合、結局、ブロックを回復するために消失した符号化ユニットの代わりの付加的な符号化ユニットを送信しなければならないため、この変形は配信の更なる時間遅延および低速化を生じる。
<7.インタリーブ信頼度制御プロトコル>
受信応答なしに同一のブロックから生成されるその後受信されたいかなる符号化ユニットからいかなる消失する符号化ユニットも補うことができるため、TF信頼度制御プロトコルは非コード信頼度制御プロトコルに比較し有利である。TF信頼度制御プロトコルが無駄となる主要な理由は、次のブロックの転送が始まる前に各々のブロックの転送が完了するのと同様、プロトコルの経時的な性質による。本願明細書に記載されている改良された信頼度制御プロトコルは、インテリジェントな方法によるブロック処理をインタリーブするのに利用することができる。
インタリーブの実施例の図を図8に示す。この例では、第1のアクティブブロックAB1(810)および第2のアクティブブロックAB2(820)の2つのアクティブブロックがある。図8の下部に、時間に対応するデータパケットの送信パターンの実施例を示す。ここで、各々のパケットには、対応するパケットがAB1かAB2の符号化ユニットを含むかどうかに依存してAB1かAB2の表示を付している。この例では、AB1の符号化ユニットを含んでいる4つのパケット((830(1)、830(2)、830(3)および830(4))が最初に送信され、そしてAB2の符号化ユニットを含んでいる2つのパケット(830(5)および830(6))、AB1の符号化ユニットを含んでいる1つのパケット(830(7))、AB2の符号化ユニットを含んでいる1つのパケット(830(8))、そして、AB1の符号化ユニットを含んでいる1つのパケット(830(9))が引き続いて送信される。一般に、異なるブロックに対する符号化ユニット間のインターリーブは、グッドプットが最大化されるよう、総バッファの必要条件(および、それに伴う時間遅延)が最小化されるよう設計される。
図9は、インタリーブ信頼度制御プロトコルによって使用可能なフォーマットの一群である。送信データフォーマットは、送信インタリーブ信頼度制御プロトコルが符号化ユニットおよび対応する信頼度制御情報を受信インタリーブ信頼度制御プロトコルに送信するフォーマットを示す。この例では、符号化ユニットが生成されたブロックを指示するブロック番号910、ブロックから何個の符号化ユニットが送信されたかを指示するシーケンス番号920、ブロックから符号化ユニットが生成された方法を指示する符号化ユニットID930、および、ブロックを回復するために受信インタリーブ信頼度制御プロトコルの中のFEC復号器によって使用され得る符号化ユニット940を含む。受信応答フォーマットは、受信インタリーブ信頼度制御プロトコルが信頼度制御情報を送信インタリーブ信頼度制御プロトコルに送信するフォーマットを示す。各々のアクティブブロックについて、ブロック番号(950(1)、950(2))、ブロックを回復するために必要な符号化ユニットの数(960(1)、960(2))、および、そのブロックにおいて現在までに受信された最も高いシーケンス番号(970(1)、970(2))を含む。
図10は、基本送信インターリーブ信頼度制御プロトコルの論理を例示する図である。このバージョンのプロトコルにおいて、基本送信インターリーブ信頼度制御プロトコルは、対応する送信速度制御プロトコルで決定される送信データ1005を送信する時であるかどうかを絶えずチェックする。送信データを送信する時間になったら、基本送信インターリーブ信頼度制御プロトコルは、どのアクティブブロックから符号化ユニットを生成し送信するべきかについて決定するため以下の一群のルールを使用する。
基本送信インターリーブ信頼度制御プロトコルは、各々のアクティブブロックi(1010)の以下の変数の情報を取得し続ける。B_iはブロックを回復するために必要な符号化ユニットの数、R_iは受信された受信応答に基づき基本送信インターリーブ信頼度制御プロトコルが知っている基本受信インターリーブ信頼度制御プロトコルがブロックから受信した符号化ユニットの数、L_i=B_i−R_iは基本送信インターリーブ信頼度制御プロトコルが知っているブロックを回復するために基本受信インターリーブ信頼度制御プロトコルが必要とする未確認の符号化ユニットの残りの数、U_iはブロックのために送信されたが基本送信インターリーブ信頼度制御プロトコルにより肯定応答がまだ受信されていない符号化ユニットの数、X_iは基本送信インターリーブ信頼度制御プロトコルがどれくらいアグレッシブにブロックのための符号化ユニットを送信するかを決定するパラメータである。
これらの変数は以下のように決定することができる。B_iの値はブロックのサイズおよび各々の符号化ユニットのサイズにより決定される。通常、各々の符号化ユニットは同一サイズであり、サイズはデータパケットのペイロードに適合するよう選択される。例えば、符号化ユニットの長さは1024バイトである。通常、各々のブロックのサイズは同一であるが可変でもよく、送信機でのデータストリームの到着速度に依存してもよいし、データパケットの送信速度に依存してもよいし、これらおよび他の要素の組合せに依存してもよい。R_iの値はステップ1030において受信される受信応答に基づいて決定される。U_iの値はブロックの符号化ユニットを含む最後の送信データのシーケンス番号とブロックの受信応答により受信される最大シーケンス番号との差である。
X_iの値は信頼度制御プロトコル全体の関数であり、後で説明されているようにX_iの選択にはトレードオフがある。X_iの値はブロックの全ての符号化ユニットについて送信の間一定のままでもよいし、種々の異なる方法による可変値でもよい。その幾つかは後述する。基本的に、各時点でのX_iは、基本受信インターリーブ信頼度プロトコルからのいかなる付加的な受信応答無しに、ブロックを復元するたに最低限必要となるものを超え基本送信インターリーブ信頼度制御プロトコルが送信しようとしている符号化ユニットの数の基準である。L_iはすでに肯定応答された受信符号化ユニットを超えブロックiを回復するために必要な符号化ユニットの数であり、U_iはブロックiの転送中でまだ肯定応答のされていない符号化ユニットの数であるため、L_i+X_i−U_iは基本送信インターリーブ信頼度制御プロトコルがこの時点で送信しようとしているブロックiの付加的な符号化ユニットの数である。X_iの値のトレードオフは以下の通りである。アクティブブロックiを回復するのに最小限必要となるものを超える最大X_i個の符号化ユニットが基本受信インターリーブ信頼度制御プロトコルにより受信され得るため、X_iが増加するとグッドプットは減少する。一方では、X_iが増加するとアクティブブロックiの高信頼の受信を完了するためのパケットタイムスロットの数は減少するため、X_iが増加するとアクティブブロックの総サイズは減少する。これはブロックiのX_i個の符号化ユニットが消失し得、付加的な符号化ユニットの送信のトリガとなる受信応答を待つことなく基本受信機はブロックを回復することが可能となる理由である。総バッファサイズおよびグッドプットの間のトレードオフがX_iの関数として表され、例えばTF信頼度制御プロトコルまたは非コード信頼度制御プロトコルのような他の信頼度制御プロトコルの対応するトレードオフに比較し非常に有利であることがわかる。
ステップ1015において、不等式L_i+X_i−U_i>0を満たすアクティブブロックiがあるかどうか判定するためにテストが実行される。L_iの値は、受信応答の肯定応答がなされた符号化ユニットに基づいたブロックを回復するのに受信機が必要とする符号化ユニットの何個である。U_iは、ブロックの転送中の肯定応答のされていない符号化ユニットの数であり、L_i−U_iは、転送中の全ての符号化ユニットが消失しない場合送信されなければならない付加的な符号化ユニットの数である。そのため、この数がゼロ以下の場合、転送中のブロックの全ての符号化ユニットが受信されると受信機はブロックを回復することが可能である。一方、いくつかの符号化ユニットが消失するかもしれず、X_iは、次の受信応答によりトリガされるブロックの付加的な符号化ユニットを送信しなければならなくなることを回避し消失から保護するため、送信機が前もって送信しようとしている付加的な符号化ユニットの数である。そのため、L_i+X_i−U_i>0の場合、送信機はブロックiのより多くの符号化ユニットを送信しようとし、それがゼロであるか負の場合、送信機はブロックiのより多くの符号化ユニットを送信しようとしない。このように、ステップ1015において、L_i+X_i−U_i>0を満たすアクティブブロックiがある場合、ステップ1020において最早のこの種のアクティブブロックから符号化ユニットを生成し対応する送信データを送信する。この種のアクティブブロックがない場合、ステップ1025において全てのアクティブブロックの中で最初期のアクティブブロックから符号化ユニットを生成し対応する送信データを送信する。そして、望ましくは、ステップ1025の実行を強制するステップ1015の状態をどのブロックも満たさないことを可能な限り回避するような方法でパラメータがセットされる。なぜなら、本質的にステップ1025は、基本送信インターリーブ信頼度制御プロトコルのバッファをクリアする最後の手段として実行されなければならないからである。
プロトコルの1つの変形は、以下の通りである。アクティブ化されたブロックの数は1から始まる、すなわち、データストリームの第1のブロックをアクティブ化する。ステップ1015の状態を満足するアクティブブロックがない場合にだけ、データストリームの新規のブロックをアクティブ化するということである。このシンプルな方法を使用して、ブロックは必要なときにアクティブブロックになるだけであり、アクティブブロックの数およびバッファサイズを、ブロックiのグッドプットBi/(Bi+X_i)を保証するために必要な数に自動調節する。
プロトコルの他の変形は、以下の通りである。この変形において、グッドプットは変化するが総バッファサイズは常に同一サイズ(全てのブロックが同一サイズである場合、常に一定数のアクティブブロックが存在することを意味する)である。ステップ1015の状態を満たすアクティブブロックがない場合は、ステップ1015の状態を満たすアクティブブロックが存在するまでアクティブブロックのX_iの値は増加する。ステップ1015の状態を満たすアクティブブロックが常に存在するという制約条件によって、適切な場合はいつでもブロックiのX_iの値は減少する。X_iの値を増加あるいは減少させる多くの方法がある。例えば、全ての値を等しく増加、全ての値を正比例して増加、最後のアクティブブロックの値より最初のアクティブブロックの値をより増加、最初のアクティブブロックの値より最後のアクティブブロックの値をより増加などがある。類似の方法がX_iの値を減少させるために用いることができる。当業者は、同様に多くの他のバリエーションについて考えることができる。
記載するにはあまりに多いが、これらの変形プロトコルの多くの他の組合せおよび拡張があり、当業者にとって明らかである。
ステップ1030において、受信応答が受信されたかどうかについてチェックされる。受信されていた場合、全てのパラメータはステップ1035において、これに基づいて更新される。すなわち、全てのアクティブブロックiのパラメータRi、U_iおよびX_iである。ステップ1040において、最も初期のアクティブブロックが完全に回復され肯定応答されたかがチェックされる。そして、肯定応答されていた場合、ステップ1045および1050で次のブロックが準備され、ステップ1055において最も初期のアクティブブロックは非アクティブ化され次のブロックがアクティブ化される。一般に、現在のアクティブブロックが送信されアクティブ化の準備がされまたは最も初期のアクティブブロックが非アクティブ化される前の場合、次のブロックまたはいくつかの次のブロックは準備中でもよい。
図11は、基本受信インターリーブ信頼度制御プロトコルの論理の例示する図である。プロトコルのこのバージョンにおいて、基本受信インターリーブ信頼度制御プロトコルは、たとえば、図9に示される送信データフォーマットにおいて送信データが受信されたかどうかを絶えずチェックする(1105)。受信された場合、ステップ1110で全てのアクティブブロックに関する情報を更新し、受信された符号化ユニットがアクティブブロックの送信データのものかをチェックする(1115)。符号化ユニットが、すでに回復されたブロックまたは現在のアクティブブロックからデータストリームのずっと先の遠いブロックである場合、ステップ1135において廃棄される。つまり、これはいかなるブロックの回復にも役立たない無駄な送信データである。そうでない場合、符号化ユニットは生成されたアクティブブロックの符号化ユニットのプールに追加され、ステップ1120において、アクティブブロックを回復するために必要な符号化ユニットの数を更新する。
ブロックiの必要な符号化ユニットの数は、B_iから受信された符号化ユニットの数を減算することにより算出される。例えば、基本受信インターリーブ信頼度制御プロトコルに対するB_iの値を通信する種々の方法がある。例えば、B_iの値を各々の送信データの中に含むようにしてもよいし、B_iの値を別の制御メッセージで送信してもよいし、B_iの値は全てのブロックで同一にしセッション開始などの間に通信してもよい。
ステップ1125では、最も初期のアクティブブロックの符号化ユニットの必要数がゼロであるかどうかについてチェックされる。ゼロである場合、FEC復号器を用いアクティブブロックを回復し、ステップ1130で新規な次のアクティブブロックの符号化ユニットの受信に備える。基本受信インターリーブ信頼度制御プロトコルは、対応する受信速度制御プロトコルで決定される受信応答送信する時であるかどうかを絶えずチェックする(1140)。送信するときである場合、ステップ1145において、たとえば、図9に示される送信データフォーマットにおいて受信応答は準備され送信される。
上記は、基本インターリーブ信頼度制御プロトコル全体の一部分の説明である点に注意する。たとえば、受信応答が基本受信インターリーブ信頼度制御プロトコルによって送信される状況に限定しない。受信された送信データの受信、時折発するタイマー、これらのイベントのいかなる組合せまたは受信速度制御プロトコルによって決定される他のいかなるイベントが送信のトリガとなり得る。通常、受信応答は、基本受信インターリーブ信頼度制御プロトコルが基本送信インターリーブ信頼度制御プロトコルに定期的に符号化ユニットの受信の進捗を知らせるように十分な頻度で送信され、基本送信インターリーブ信頼度制御プロトコルから基本受信インターリーブ信頼度制御プロトコルまで送信される符号化ユニットを含んでいる送信データとほぼ同程度の帯域幅を消費することのない頻度で送信する。
TF信頼度制御プロトコルまたは非コード信頼度制御プロトコルに比較し、基本インターリーブ信頼度制御プロトコルは、グッドプットおよびバッファサイズの間の非常により良好なトレードオフを有することができる。たとえば、基本インターリーブ信頼度制御プロトコルの多くても2つのアクティブブロックがあると仮定する。Bを符号化ユニットを単位にする各々のデータブロックのサイズ、Rを速度制御プロトコルによってパケットが送信される速度、RTTを送信および受信エンドシステム間の往復時間、そして、N=R*RTTとする。そして、Xを全てのアクティブブロックで等しい定数とする。一般には、これらのパラメータは、データ転送の間動的に変化することができるが、この例では、全てが固定であり、B≧Nであるとみなす。
パケット損失が送信機および受信機の間にないと仮定する。その場合、基本送信インターリーブ信頼度制御プロトコルが最も初期のアクティブブロックのB+X個の符号化ユニットを送信した後、基本受信インターリーブ信頼度制御プロトコルから最も初期のブロックを回復完了したことを指示する受信応答を受信するまで次のブロックの符号化ユニットを送信する。この時点で、基本送信インターリーブ信頼度制御プロトコルは最も初期のアクティブブロックを非アクティブ化する。そして、いくつかの符号化ユニットがすでに送られた次のアクティブブロックが最も初期のアクティブブロックになり、次のブロックがアクティブ化される。そのため、B+X個の符号化ユニットが長さBのブロックの回復に使用され、送信されたX個の符号化ブロックは無駄となる。一方、B≧Nの場合、図9のステップ1015に示される不等式を満たすアクティブブロックが常に存在することになる。そのため、グッドプットはB/(B+X)であるのに、2つのアクティブブロックがある場合、バッファの総サイズは2*Bである。例えば、符号化ユニットのサイズが1キロバイト、レートRが1秒につき1,000個の符号化ユニット(=1メガバイトの/秒=8メガビット/秒)そして、RTTが1秒であると仮定する。そのとき、N=R*RTT=1メガバイトである。ブロックのサイズをB=1メガバイトXを10に設定する場合、グッドプットはおよそ(B/(B+X))=0.99。すなわち、多くとも送信された符号化ユニットの1%が無駄になるだけであり、このときの総バッファサイズは2MBに過ぎない。これは、この例において基本送信インターリーブ信頼度制御プロトコルにより2秒の時間遅延を生じることを意味する。このバッファサイズが同じ状況の送信TF信頼度制御プロトコルに比較し25倍小さい点に注意する。
パケット損失がない上述の実施例においては、Xの値をゼロにセットされることもでき、グッドプットを1.0まで増加可能である。しかしながら、なんらかのパケット損失があるときには、X>0と設定することにより重要な利点がある。たとえば、上記例において、1,000個の符号化ユニットのうち多くても10個が損失する場合、分析によりX=10により同じグッドプットおよびバッファサイズが達成されるが、X=0の場合は必ずしもそうならないことが分かる。パケット損失がより可変的で未知であるとき、特にB個のパケットにつき消失するパケットの数がX個を超えることがありえるとき、基本インターリーブ信頼度制御プロトコルにより達成されるグッドプットおよびバッファサイズが、TF信頼度制御プロトコルまたは非コード信頼度プロトコルを使用して達成されることができるそれらに比較し定量的に非常に良好であることがわかる。
別の例として、送信レートを1秒当たりのR個のパケット、往復時間RTTは定数およびN=R*RTTを仮定する。各々のパケットが確率pで損失するように、パケット損失がランダムであると仮定する。さらに、各々のブロックiのサイズB_iはパケットを単位として同一のCであり、それぞれのX_iが同一の値Yであるとする。さらに、上述のプロトコルの変形において、必要なときに新規なブロックをアクティブ化する起動させるだけであるとする。最初のアクティブ化の時間から回復の肯定応答が受信機から受信されることにより非アクティブ化される時間までのブロックを考慮する。ブロックのC−N個のパケットが肯定応答される時間tに、F=N+Y個のパケットが転送中で応答されていない。そして、送信機は受信機がブロックを完了するためにN=F−Y個のパケットを必要とすることを知っている。時間t+RTTで、時間tでブロックのために転送中であったF個のパケットの中で、(1−p)*F個のパケットが受信機により受信され、送信機は肯定応答を受信する。このように、時間t+RTTで送信機は、受信機が必要とする残りのパケットの数が現在N−(1−p)*F=p*F−Y個であり、転送中のパケットはp*F個であるということを知っている。続いて、時間t+i*RTTで送信機は、受信機が必要とする残りのパケットの数がp^i*F−Yであり、転送中のパケットの数がp^i*F個であることを知っている。送信機が知っている受信機が必要とするということをパケットの数がゼロより小さくなるとブロックは完了する。そして、時間t+i*RTTで真となり、このときiがp^i*F−Y<=0を満たす。この不等式が真であるiの最小値は、iがおよそln((N/Y)+1)/ln(1/p)である時である。各RTTにおいて、(1−p)*N個のパケットが受信機により受信されるので、考慮するブロックを超えたデータストリームで送信プロトコルが有することができる最遠のもので、受信され肯定応答されるブロックは最高でも(ln((N/Y)+1)/ln(1/p))*(1−p)*Nパケットであることを意味する。pの全ての値に対して(1−p)/ln(1/p)<=1であることを考慮すると、バッファサイズが最高でもC+ln((N/Y)+1)*Nパケットの長さであることを意味する。もちろん、これは全て確率過程がその期待される挙動として正確にふるまうと仮定している、しかし、Yがあまり小さく無い場合これはプロトコルのふるまいについての大まかな考えを与える。この場合、グッドプットは、C/(C+Y)である。たとえば、RTT=1,R=1,000,C=1,000,Y=50である場合、バッファサイズは多くても約4,000であり、グッドプットは0.95である。
上述した基本インターリーブ信頼度制御プロトコルの多くの変形は、本明細書を読んだ後に明らかでなければならない。例えば、上述したように、送信信頼度制御プロトコルが一度に2個以上のアクティブブロックを使用することもできる。そして、より複雑でより多くのアクティブブロックを扱う代価として、送信および受信信頼度制御プロトコルで使用するバッファサイズの全体量を低減可能とする可能性を持っている。
変形の他の実施例として、符号化ユニットがどのアクティブブロックから送信されることになっているかについて決定するために確率過程を使用することが有益でありえる。これは、パケット損失パターンが必ずしもランダムであるというわけではなくシステマチックでもよく、いくつかのブロックが決して回復されないが受信機にパケットを配送し続けているパケット損失パターンなどで、次に送信する符号化ユニットを選択するためいかなる決定論的な手順も使用される。たとえば、決定論的な手順が特定のアクティブブロックから符号化ユニットを送信するときは常にその符号化ユニットが失われ、他のいかなるアクティブブロックの符号化ユニットを送信するときは常に受信機に到達するような損失パターンを考慮する。そのため、この例では、受信機がまだ符号化ユニットを受信する場合であっても、受信機はアクティブブロックを決して回復しない。この種のシステマチックな損失を克服するために、どのアクティブブロックから次の符号化ユニットを送信するかをランダム化する送信信頼度制御プロトコルは有利である。これを達成する1つのシンプルな方法は、送信信頼度制御プロトコルのために送信されるQ個の符号化ユニットの束を一緒にバッファリングして、ランダムな順に各々の束のQ個の符号化ユニットを送信する。また、より高度な方法も使用され、例えば、送信される各々の符号化ユニットについて、次の時点で送信される符号化ユニットに、例えば、回数が多いほど選択されなくなるような動的に変化している確率を割り当てる。他の変形は基本送信インターリーブ信頼度制御プロトコルの図10に示すステップ1020への変更であり、送信される符号化ユニットがステップ1015の状態を満たすアクティブブロックの中からランダムに生成される(以前のアクティブブロックに適切であり、時間とともに動的に変化できる適切に選ばれた確率分布を使用する)。
いつアクティブブロックiのための符号化ユニットを送信するかについて決定するためにパラメータX_iを用いる場合、転送の間、X_iを調整する多くの変形方法がある。1つの実施例は、X_iを固定値にして、転送全体にわたってその値を維持することである。たとえば、X_iは、ゼロまたは10のようないくつかの他の固定値にセットしてもよい。他の実施例は、アクティブブロックiの符号化ユニットの転送の開始時はX_iを固定値として、符号化ユニットが送信されるたびにX_iを増加させ、アクティブブロックiから符号化ユニットを送信する条件は満たされない。X_iが増加させる多くの変形方法がある。例えば、X_iは、最初のN回はゼロ増加するが、次ではN/Bだけ増加する。いくつかのステップで、X_iの増加を負とすることもまた可能である。
他の変形として、基本インターリーブ信頼度制御プロトコルにて説明したように、各々のアクティブブロックiのパラメータX_iを使用するだけでなく、1つは符号化ユニットが特定のアクティブブロックから送られなければならないか否か、決定する他の方法を使用することである。たとえば、パケット損失率の平均は維持される場合、アクティブブロックから送られることが可能である符号化ユニットの数は最近のパケット損失率が現在のパケット損失率のための良好な予測手段であるという仮定に基づいて決定することが出来る。たとえば、平均損失率が現在pである場合、状態がL_i+X_i/(1−p)−U_i*(1−p)>0であるために、1つの方法は基本送信インターリーブ信頼度制御プロトコルの図10に示すステップ1015を変更を加えることである。この特定の選択の正当性はアクティブブロックiのU_i符号化ユニットが転送中の場合、割合1−pだけが基本受信インターリーブ信頼度制御プロトコルに到着するということにある。そして、X_i/(1−p)個の付加的なパケットが送信される場合、X_i個が基本受信インターリーブ信頼度制御プロトコルに到着する。このように、全体平均として、基本受信インターリーブ信頼度制御プロトコルはアクティブブロックiのB_i+X_i個の符号化ユニットを受信する。そして、X_i付加的な符号化ユニットの値は、ブロックを回復するために符号化ユニットの充分な数の伝送のための受信応答に従い回避するパケット損失率の変わりやすさを考慮して十分な値がセットされる。
インターリーブ信頼度制御プロトコルの他の変形は、受信機においてパケットが送信された順番を同じ順番で到着していない可能性を考慮する。そのため、ブロックから受信される最も高いシーケンス番号が同一であっても、受信機からの次の受信応答は前の受信応答より所与のアクティブブロックのための符号化ユニットの数より大きい数として報告されてしまう。このように、基本インターリーブ信頼度制御プロトコルの論理は、追加注文されたパケットを考慮するため、送信機および受信機において、変更を加えられることが可能である。
前述のように、図10で示す基本送信インターリーブ信頼度制御プロトコルのステップ1025は、通常、各時点で少なくとも一つのアクティブブロックが状態1015を満たすように適切にパラメータをセットすることにより回避される。ステップ1025の変形はどのアクティブブロックが符号化ユニットを生成して送信するように選択されるかにより変化する。たとえば、アクティブブロックはステップ1025において、ランダムに選択することが出来、または、アクティブブロックの一群で循環して選択することが出来る。
図10のステップ1045は、最も初期のアクティブブロックが非アクティブ化されるとすぐに次のブロックがアクティブ化されることを示している。最新の現在のアクティブブロックを超えてあるブロックから符号化ユニットを送る時であるときに、総バッファサイズおよびそれに伴う時間遅延を低減できる変形は次のブロックをアクティブ化させるだけである。
上記の通り、基本インターリーブ信頼度制御プロトコルは、暗にいかなる時もアクティブブロックの数は固定されている仮定する。変形はアクティブブロックの数がデータが、送信時に利用可能な速度、どのくらいパケットロスが発生しているか、パケット送信レートの変化しやすさなどを含む種々の要因に従い変化できることである、そして、例えば、パケット損失が少なく送信レートが低いとき、アクティブブロックの数は少ない状態に保持される。しかし、パケット損失が増加するか送信レートが増加するとき、アクティブブロックの数は一時的に多くなりうる。そのため、バッファおよび時間遅延は、プロトコルが動作している状況に従い動的に変化する。
アクティブブロックの数が固定であっても、アクティブブロックの集約した大きさは可変でありうる。この場合、各々の次のアクティブブロックのサイズは前のブロックと異なる。たとえば、データ有効レートが増大するとき次のアクティブブロックのサイズは増加する。そして、送信速度が増加するとき、次のアクティブブロックのサイズは増加する。各々のアクティブブロックの長さは時間の関数であってもよい。例えば、新規なブロックが形成される前に多くの時間が経過可能となるよう、長さの関数であってもよい。すなわち、すなわち、各々のブロックが非常に長くてもよいし、これらおよび他の要素の組合せであってもよい。
1つのブロックの終了および次のブロックの始まりはインターリーブ信頼度制御プロトコルによって、自動的に決定することができ、それは、アプリケーションまたはこれらおよび他の要素のいくつかの組合せにより決定することができる。たとえば、データストリームのブロックはMPEGストリームにおける、ピクチャ群(GOP)ブロックまたはIフレームなどのアプリケーションの論理的意味を有してもよい。そして、このように、インターリーブ信頼度制御プロトコルがデータのストリームをブロックに区切る方法は論理的アプリケーションブロックの境界を反映してもよい。また、アプリケーションがインターリーブ信頼度制御プロトコルにブロック境界を指示してもよい。インターリーブ信頼度制御プロトコルは可能な限りのこれらの境界を反映しようとするが、アプリケーションにより指示されるそれら位置以外でブロック境界を作ることも可能である。
インターリーブ信頼度制御プロトコルの他の変形は、全てのブロックを確実に順番に受信機に対して配信するのではなく、その代わりに他の制約条件を前提としてこの目的を達成するために同じく可能な限りトライすることを許すプロトコルである。たとえば、ストリーミングアプリケーションにおいて、データのストリームをできる限り確実に配信することが重要であるが、例えばデータストリーム上のタイミング制約条件などの他の制約条件がある。たとえば、それは、特定の時間以後データの一定部分がもはや関係ない条件であり、あるいは、インターリーブ信頼度制御プロトコルにより生じる時間遅延をどの程度許容できるかという強い限度がある。例えば、インタラクティブな映像会議アプリケーションがそうである。これらの場合、送信インターリーブ信頼度制御プロトコルと受信インターリーブ信頼度制御プロトコルはそれらが完全に回復される前にいくつかのブロックがスキップされうるよう変更を加えられうる。たとえば、送信インターリーブ信頼度プロトコルは、アクティブブロックが所与の時間だけアクティブ化可能なよう制限されうる。または、それがもはやブロックの符号化ユニットを送ることは許されないアプリケーションにより出力される各々のブロックのための時間制約条件を有することができる。または、それは各々のブロックの符号化ユニットの提供された最大数だけ送信可能である。または、これらの制約条件のいかなる組合せもありうる。類似した制約条件を、受信インターリーブ信頼度制御プロトコルに適用してもよい。これらのアプリケーションのために、インタリーブされた信頼度制御プロトコルは、これらの制約条件を反映するために変更を加えられることが可能である。
インタリーブ信頼度制御プロトコルのいくつかの変形において、1台の送信機および1つの受信機がある。1台の送信機および多数の受信機、1つの受信機および多数の送信機、多数の送信機および多数の受信機などの他の変形を含むが、これに限定されるものではない。送信チャネルがブロードキャストまたはマルチキャストチャネルである1つの送信機/多数の受信機の変形において、送信機が各々のアクティブブロックiの計算のために、たとえばRiを図10のステップ1010の任意の受信機から受信された肯定応答された符号化ユニットの最小数とするよう送信信頼度制御プロトコルに変更を加えることができる。1つの送信機/多数の受信機の他の実施例として、送信機が別々のパケットストリームを各々の受信機に送信する場合、以下のように送信信頼度制御プロトコルに変更を加えることが出来る。送信機が各々のアクティブブロックi各々の受信機jに対応するR_ijの値をアクティブブロックiの受信機jから受信された肯定応答された符号化ユニットの数とし、図10のステップ1010でLjj=Bi−Rijを計算し、U_ijを受信機jに送信したアクティブブロックiのうちまだ応答されていない符号化ユニットの数とし、ステップ1015の状態を、L_ij+X_i−U_ij>0を満たすいくつかの受信機jについてアクティブブロックiがあるかどうかを決定することに変更する。別の例として、多数の送信機/1つの受信機の変形があり、受信機が、多数の送信機から並行して同一あるいは異なるアクティブブロックの符号化ユニットを受信し、ブロードキャストかマルチキャストチャネルによって全ての送信機に受信応答を送信し、あるいは、各々の送信機に対する潜在的に別々の受信応答を別々のパケットストリームを使用して送信するよう、受信信頼度制御プロトコルは変更を加えられる。別の例として、多数の送信機/多数の受信機の変形があり、変更を加えられたステップは、上述した1つの送信機/多数の受信機の場合と多数の送信機/1つの受信機を混合したものである。
他の変形は、送信機が並行して複数の送信データストリームを送信する場合であり、各々が別々の送信インターリーブ信頼度制御プロトコル、あるいは、異なるデータストリームを考慮可能なバージョンの送信インターリーブ信頼度制御プロトコルを使用している。例えば、全てのストリームの全てのパケットの合計の送信速度は制限されうるため、送信機は他に対していくつかのデータストリームにたいし優先させる。同様に、受信機は、複数のデータストリームを並行して受信していることができ、各々は別々の受信インターリーブ信頼度制御プロトコル、あるいは、異なるデータストリームを考慮可能なバージョンの受信インターリーブ信頼度制御プロトコルを使用している。すなわち、全てのストリームの全てのパケットの合計の受信速度は制限されうるため、送信者は他に対していくつかのデータストリームの受信パケットおよび処理で送信する受信応答の受信を優先させる。
上記の変形のいずれかは、お互いに結合することができる。たとえば、タイミングおよび/または帯域幅制限のためいくつかのブロックを受信機に確実に配信されることができないプロトコルは、多数の送信機/多数の受信機の変形と組み合わせて使用することが出来る。
本発明の教示を使用する送信エンドシステムおよび受信エンドシステムのネットワークの実施例のブロック図である。 モジュラ高信頼転送プロトコルアーキテクチャおよびこの種のプロトコルを使用して動作する関連システムの図である。 送信FECベース信頼度制御プロトコルアーキテクチャおよびこの種のプロトコルを使用して動作する関連システムの例示図である。 受信FECベース信頼度制御プロトコルアーキテクチャおよびこの種のプロトコルを使用して動作する関連システムの例示図である。 TF信頼度制御プロトコルを実装しているシステムによって使用可能なフォーマットセットの1つである。 送信TF信頼度制御プロトコルを実装しているシステムの論理ブロック図である。 受信TF信頼度制御プロトコルを実装しているシステムの論理ブロック図である。 アクティブブロックの図である。 インターリーブ信頼度制御プロトコルによって使用可能なフォーマットセットの図である。 基本送信インターリーブ信頼度制御プロトコルを実装しているシステムの論理実施例の例示図である。 基本受信インターリーブ信頼度制御プロトコルを実装しているシステムの論理実施例の例示図である。

Claims (9)

  1. 送信機から受信機へ高信頼にデータを転送する方法であって、
    送信されるデータを各々が複数の符号化ユニットを含むデータブロックに編成するステップと、
    第1データブロックの符号化ユニットを前記送信機から前記受信機へ送信するステップと、
    前記送信機において、前記受信機で前記第1データブロックを回復するため該受信機で該第1データブロックの十分な符号化ユニットを受信した確率を決定するステップと、
    所定のテストを満足するどうか決定するため前記確率を閾値確率に対してテストするステップと、
    前記テストのステップの後かつ前記送信機が前記受信機での前記第1データブロックの回復の確認を受信する前において、前記所定のテストを満足するとき前記送信機から第2データブロックの符号化ユニットを送信するステップと、
    前記送信機が前記第1データブロックの回復の失敗の指示を受信したとき、送信機から受信機へ前記第1データブロックの更なる符号化ユニットを送信するステップと、
    を含む方法。
  2. 各々の前記符号化ユニットは、IPパケットである請求項1に記載の方法。
  3. 前記失敗指示は、前記受信機により送信され前記送信機により受信される明示的な失敗通知である請求項1に記載の方法。
  4. 前記失敗指示は、前記受信機からの前記第1データブロックの回復成功の肯定応答の前記送信機で決定される期間内での受信失敗に対応して前記送信機のために生成される請求項1に記載の方法。
  5. 前記第1データブロックの前記更なる符号化ユニットは、テストのステップの前に送信される前記符号化ユニット以外の付加的な符号化ユニットである請求項1に記載の方法。
  6. 前記第1データブロックの前記更なる符号化ユニットは、テストのステップの前に送信される前記符号化ユニットの再送コピーである請求項1に記載の方法。
  7. 前記符号化ユニットは、連鎖反応符号化処理を使用して符号化されることを特徴とする請求項1に記載の方法。
  8. 前記符号化ユニットは、トルネード符号化処理を使用して符号化されることを特徴とする請求項1に記載の方法。
  9. 前記符号化ユニットは、予め指定された符号化率を有する前方誤り訂正符号化処理を使用して符号化されることを特徴とする請求項1に記載の方法。
JP2006534401A 2003-10-08 2004-10-08 Fecベース信頼度制御プロトコル Expired - Fee Related JP4685787B2 (ja)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US50997603P 2003-10-08 2003-10-08
PCT/US2004/033307 WO2005036361A2 (en) 2003-10-08 2004-10-08 Fec-based reliability control protocols

Publications (3)

Publication Number Publication Date
JP2007508750A true JP2007508750A (ja) 2007-04-05
JP2007508750A5 JP2007508750A5 (ja) 2007-11-22
JP4685787B2 JP4685787B2 (ja) 2011-05-18

Family

ID=34435044

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2006534401A Expired - Fee Related JP4685787B2 (ja) 2003-10-08 2004-10-08 Fecベース信頼度制御プロトコル

Country Status (6)

Country Link
US (2) US7447235B2 (ja)
EP (1) EP1671424B1 (ja)
JP (1) JP4685787B2 (ja)
KR (1) KR101035219B1 (ja)
CN (2) CN101656731B (ja)
WO (1) WO2005036361A2 (ja)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2016504005A (ja) * 2013-01-17 2016-02-08 クアルコム,インコーポレイテッド マルチパスストリーミングのためのfecベースの信頼性のある転送制御プロトコル
JP2017153163A (ja) * 2009-10-28 2017-08-31 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカPanasonic Intellectual Property Corporation of America パリティパケットを用いた通信方法、通信装置及び中継器

Families Citing this family (56)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4126059B2 (ja) 2003-06-18 2008-07-30 日本電信電話株式会社 無線パケット通信方法および無線パケット通信装置
WO2005036361A2 (en) * 2003-10-08 2005-04-21 Digital Fountain, Inc. Fec-based reliability control protocols
US8077743B2 (en) * 2003-11-18 2011-12-13 Qualcomm Incorporated Method and apparatus for offset interleaving of vocoder frames
US20050187979A1 (en) * 2004-02-09 2005-08-25 Microsoft Corporation System and method for message-level connection management
US8184657B2 (en) * 2004-09-23 2012-05-22 Sony Corporation Reliable audio-video transmission system using multi-media diversity
US8374087B2 (en) * 2004-09-23 2013-02-12 Sony Corporation Reliable audio-video transmission system using multi-media diversity
US8140699B2 (en) * 2005-02-23 2012-03-20 Cisco Technology, Inc. Switching a client from unicasting to multicasting by simultaneously providing unicast and multicast streams to the client
US7904581B2 (en) * 2005-02-23 2011-03-08 Cisco Technology, Inc. Fast channel change with conditional return to multicasting
US7657816B2 (en) * 2005-07-13 2010-02-02 Leanics Corporation Low-complexity hybrid LDPC code encoder
US7596673B2 (en) * 2005-12-08 2009-09-29 Sony Corporation Failure tolerant data storage
JP4722693B2 (ja) * 2005-12-16 2011-07-13 Kddi株式会社 通信システム
US8713195B2 (en) 2006-02-10 2014-04-29 Cisco Technology, Inc. Method and system for streaming digital video content to a client in a digital video network
JP4808054B2 (ja) * 2006-03-17 2011-11-02 富士通株式会社 データ転送方法及び,これを適用する通信システム及びプログラム
JP5184527B2 (ja) * 2006-07-25 2013-04-17 トムソン ライセンシング スタガーキャスティング及びクロスパケット前方誤り訂正を用いたインターネットプロトコル型無線ネットワークでのバーストパケット損失からの回復
US7895347B2 (en) * 2007-07-27 2011-02-22 Red Hat, Inc. Compact encoding of arbitrary length binary objects
US8442070B1 (en) * 2008-02-01 2013-05-14 Hobnob, Inc. Fractional threshold encoding and aggregation
FR2935862B1 (fr) * 2008-09-08 2014-09-05 Canon Kk Procede de prediction du taux d'erreurs de transmission dans un reseau de communication et serveur mettant en oeuvre un tel procede
US20100142522A1 (en) * 2008-12-04 2010-06-10 James Gardner Methods and apparatus for adaptive error correction in networks
WO2010093289A1 (en) * 2009-02-10 2010-08-19 Telefonaktiebolaget L M Ericsson (Publ) A network element and a method of operating a network element in a telecommunications network
JP2010213150A (ja) * 2009-03-12 2010-09-24 Nec Corp 送信装置、大容量ファイル配信システム、同システムにおけるファィル再送制御方法、再送制御プログラム
EP2302845B1 (en) 2009-09-23 2012-06-20 Google, Inc. Method and device for determining a jitter buffer level
TWI421871B (zh) * 2009-11-27 2014-01-01 Macronix Int Co Ltd 定址一記憶積體電路之方法與裝置
US8477050B1 (en) 2010-09-16 2013-07-02 Google Inc. Apparatus and method for encoding using signal fragments for redundant transmission of data
JP5664229B2 (ja) * 2010-12-28 2015-02-04 ソニー株式会社 送信装置、送信方法、及びプログラム
JP5529177B2 (ja) 2011-01-19 2014-06-25 ネイバー ビジネス プラットフォーム コーポレーション P2p基盤のストリーミングサービスでバッファリングを行うシステムおよび方法、並びにクライアントでバッファリングを処理するアプリケーションを配布するシステム
US8539319B2 (en) * 2011-01-28 2013-09-17 Cisco Technology, Inc. Providing capacity optimized streaming data with forward error correction
US8838680B1 (en) 2011-02-08 2014-09-16 Google Inc. Buffer objects for web-based configurable pipeline media processing
US8681866B1 (en) 2011-04-28 2014-03-25 Google Inc. Method and apparatus for encoding video by downsampling frame resolution
US8661323B2 (en) 2011-05-09 2014-02-25 Google Inc. Method and apparatus for generating packet mask
US9106787B1 (en) 2011-05-09 2015-08-11 Google Inc. Apparatus and method for media transmission bandwidth control using bandwidth estimation
US9490850B1 (en) 2011-11-28 2016-11-08 Google Inc. Method and apparatus for decoding packetized data
US9185429B1 (en) 2012-04-30 2015-11-10 Google Inc. Video encoding and decoding using un-equal error protection
US10034023B1 (en) 2012-07-30 2018-07-24 Google Llc Extended protection of digital video streams
US9172740B1 (en) 2013-01-15 2015-10-27 Google Inc. Adjustable buffer remote access
US9311692B1 (en) 2013-01-25 2016-04-12 Google Inc. Scalable buffer remote access
US9225979B1 (en) 2013-01-30 2015-12-29 Google Inc. Remote access encoding
US20140269359A1 (en) * 2013-03-14 2014-09-18 Google Inc. Reduction of retransmission latency by combining pacing and forward error correction
CN104426636A (zh) * 2013-09-11 2015-03-18 松下电器产业株式会社 通信控制装置及通信控制方法
KR20150049052A (ko) * 2013-10-29 2015-05-08 삼성에스디에스 주식회사 데이터 전송 장치 및 방법
US9582904B2 (en) 2013-11-11 2017-02-28 Amazon Technologies, Inc. Image composition based on remote object data
US9641592B2 (en) 2013-11-11 2017-05-02 Amazon Technologies, Inc. Location of actor resources
US9578074B2 (en) 2013-11-11 2017-02-21 Amazon Technologies, Inc. Adaptive content transmission
US9596280B2 (en) 2013-11-11 2017-03-14 Amazon Technologies, Inc. Multiple stream content presentation
US9805479B2 (en) 2013-11-11 2017-10-31 Amazon Technologies, Inc. Session idle optimization for streaming server
US9604139B2 (en) 2013-11-11 2017-03-28 Amazon Technologies, Inc. Service for generating graphics object data
US9634942B2 (en) 2013-11-11 2017-04-25 Amazon Technologies, Inc. Adaptive scene complexity based on service quality
US9350484B2 (en) 2014-03-18 2016-05-24 Qualcomm Incorporated Transport accelerator implementing selective utilization of redundant encoded content data functionality
US9596281B2 (en) 2014-03-18 2017-03-14 Qualcomm Incorporated Transport accelerator implementing request manager and connection manager functionality
US9596323B2 (en) 2014-03-18 2017-03-14 Qualcomm Incorporated Transport accelerator implementing client side transmission functionality
US9794311B2 (en) 2014-03-18 2017-10-17 Qualcomm Incorporated Transport accelerator implementing extended transmission control functionality
US10536382B2 (en) * 2017-05-04 2020-01-14 Global Eagle Entertainment Inc. Data flow control for dual ended transmission control protocol performance enhancement proxies
US10638366B2 (en) * 2018-06-18 2020-04-28 Verizon Patent And Licensing Inc. Flow level pacing by controlling socket send buffer size
US11088968B2 (en) * 2019-09-10 2021-08-10 Verizon Patent Licensing Inc. Controlling socket receive buffer for traffic optimization
CN110855400B (zh) * 2019-11-29 2022-02-25 江苏方天电力技术有限公司 基于纠错码的自适应丢包恢复方法、计算设备及存储介质
CN113676736B (zh) * 2020-05-13 2024-05-07 华为技术有限公司 数据帧的传输方法和通信装置
US11863317B2 (en) * 2021-08-25 2024-01-02 BitRipple, Inc. Methods for reliable low latency data delivery using erasure codes and feedback

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH05292150A (ja) * 1992-04-10 1993-11-05 Canon Inc 通信処理装置
JPH06350575A (ja) * 1993-06-11 1994-12-22 Fujitsu Ltd 移動通信用のデータ通信プロトコル
JP2002510902A (ja) * 1998-03-30 2002-04-09 テレフオンアクチーボラゲット エル エム エリクソン(パブル) パケット交換システムにおけるブロックのインタリーブ方式
JP2003008553A (ja) * 2001-06-22 2003-01-10 Mitsubishi Electric Corp 送信機、受信機、送受信機および通信システム
JP2003087225A (ja) * 2001-09-12 2003-03-20 Nippon Telegr & Teleph Corp <Ntt> データ転送方法、データ転送システム、端末装置、データ転送プログラム、および記録媒体

Family Cites Families (21)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH11505685A (ja) 1995-04-27 1999-05-21 トラスティーズ・オブ・ザ・スティーブンス・インスティテュート・オブ・テクノロジー 時間限界マルチメディアネットワークアプリケーションのための高保全性伝送
ZA965340B (en) * 1995-06-30 1997-01-27 Interdigital Tech Corp Code division multiple access (cdma) communication system
JP3391251B2 (ja) * 1998-03-25 2003-03-31 三菱電機株式会社 適応確率推定方法及び適応符号化方法並びに適応復号方法
US6307487B1 (en) 1998-09-23 2001-10-23 Digital Fountain, Inc. Information additive code generator and decoder for communication systems
US7068729B2 (en) 2001-12-21 2006-06-27 Digital Fountain, Inc. Multi-stage code generator and decoder for communication systems
US6320520B1 (en) 1998-09-23 2001-11-20 Digital Fountain Information additive group code generator and decoder for communications systems
CN1218527C (zh) * 1998-10-23 2005-09-07 艾利森电话股份有限公司 复合的混合自动重发请求方案
US6621796B1 (en) * 1999-03-22 2003-09-16 Telefonaktiebolaget Lm Ericsson (Publ) Discard mechanism for selective repeat automatic repeat request
US6757654B1 (en) * 2000-05-11 2004-06-29 Telefonaktiebolaget Lm Ericsson Forward error correction in speech coding
US6486803B1 (en) 2000-09-22 2002-11-26 Digital Fountain, Inc. On demand encoding with a window
US6411223B1 (en) 2000-10-18 2002-06-25 Digital Fountain, Inc. Generating high weight encoding symbols using a basis
US7095729B2 (en) * 2000-12-22 2006-08-22 Intel Corporation Method for multimedia communication over packet channels
US7068726B1 (en) * 2001-08-30 2006-06-27 3Com Corporation Near end cross-talk and echo avoider for bi-directional digital communications
US20030103459A1 (en) * 2001-11-16 2003-06-05 Connors Dennis P. Method and implementation for a flow specific modified selective-repeat ARQ communication system
US7254140B1 (en) * 2002-01-14 2007-08-07 Xilinx, Inc. Method and apparatus for transceiving data in a micro-area network
US6677864B2 (en) * 2002-04-18 2004-01-13 Telefonaktiebolaget L.M. Ericsson Method for multicast over wireless networks
US7483408B2 (en) * 2002-06-26 2009-01-27 Nortel Networks Limited Soft handoff method for uplink wireless communications
US7168022B2 (en) * 2002-12-27 2007-01-23 Ntt Docomo, Inc. Transmission control method and system
US6954617B2 (en) * 2003-03-31 2005-10-11 Sony Corporation Apparatus and method to improve goodput in unreliable networks
US7385954B2 (en) * 2003-07-16 2008-06-10 Lucent Technologies Inc. Method of transmitting or retransmitting packets in a communication system
WO2005036361A2 (en) * 2003-10-08 2005-04-21 Digital Fountain, Inc. Fec-based reliability control protocols

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH05292150A (ja) * 1992-04-10 1993-11-05 Canon Inc 通信処理装置
JPH06350575A (ja) * 1993-06-11 1994-12-22 Fujitsu Ltd 移動通信用のデータ通信プロトコル
JP2002510902A (ja) * 1998-03-30 2002-04-09 テレフオンアクチーボラゲット エル エム エリクソン(パブル) パケット交換システムにおけるブロックのインタリーブ方式
JP2003008553A (ja) * 2001-06-22 2003-01-10 Mitsubishi Electric Corp 送信機、受信機、送受信機および通信システム
JP2003087225A (ja) * 2001-09-12 2003-03-20 Nippon Telegr & Teleph Corp <Ntt> データ転送方法、データ転送システム、端末装置、データ転送プログラム、および記録媒体

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2017153163A (ja) * 2009-10-28 2017-08-31 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカPanasonic Intellectual Property Corporation of America パリティパケットを用いた通信方法、通信装置及び中継器
US10560224B2 (en) 2009-10-28 2020-02-11 Panasonic Intellectual Property Corporation Of America Transmission method using parity packets, transmitter and repeater
US11121817B2 (en) 2009-10-28 2021-09-14 Panasonic Intellectual Property Corporation Of America Transmission method using parity packets, transmitter and repeater
US11671201B2 (en) 2009-10-28 2023-06-06 Panasonic Intellectual Property Corporation Of America Transmission method using parity packets, transmitter and repeater
JP2016504005A (ja) * 2013-01-17 2016-02-08 クアルコム,インコーポレイテッド マルチパスストリーミングのためのfecベースの信頼性のある転送制御プロトコル

Also Published As

Publication number Publication date
EP1671424B1 (en) 2012-06-06
US8458567B2 (en) 2013-06-04
EP1671424A2 (en) 2006-06-21
CN1864335A (zh) 2006-11-15
US20090144601A1 (en) 2009-06-04
CN100550652C (zh) 2009-10-14
US20050226272A1 (en) 2005-10-13
WO2005036361A3 (en) 2006-03-30
EP1671424A4 (en) 2010-12-22
CN101656731B (zh) 2015-04-15
US7447235B2 (en) 2008-11-04
KR20070004517A (ko) 2007-01-09
CN101656731A (zh) 2010-02-24
KR101035219B1 (ko) 2011-05-18
JP4685787B2 (ja) 2011-05-18
WO2005036361A2 (en) 2005-04-21

Similar Documents

Publication Publication Date Title
JP4685787B2 (ja) Fecベース信頼度制御プロトコル
JP6284549B2 (ja) マルチパスストリーミングのためのfecベースの信頼性のある転送制御プロトコル
EP1346578B1 (en) Method for multimedia communication over packet channels
AU769881B2 (en) Method and apparatus for discarding packets in a data network having automatic repeat request
JP4454320B2 (ja) 伝送装置、伝送制御プログラム、及び伝送方法
US7584404B2 (en) Method and apparatus for multimedia communication over packet channels
CN115396078A (zh) 一种数据传输方法及装置
CN101061659A (zh) 自适应前向纠错
KR20160141871A (ko) 네트워크에서 신뢰성 있는 실시간 데이터 스트리밍을 위한 효율적인 애플리케이션 계층의 자동 반복 요청 재송신 방법
WO2001084731A1 (en) Methods and systems for forward error correction based loss recovery for interactive video transmission
WO2001037480A2 (en) Multicast transmission method and system
US20120320732A1 (en) Multicast bulk transfer system
US7756992B1 (en) Reliable delivery of updates for antivirus programs
US20090262646A1 (en) Transport protocol for efficient aggregation of heterogeneous losssy paths
Huang et al. A hybrid FEC-ARQ protocol for low-delay lossless sequential data streaming
Yoon et al. Adaptive reliable multicast
CN114285528A (zh) 传输报文的方法及通信装置
US7013418B1 (en) Method and apparatus for reliable delivery of status information for multiple sets of data units in a single packet
Wei et al. QoS tradeoffs using an application-oriented transport protocol (AOTP) for multimedia applications over IP
Mehrotra et al. Minimizing delay in lossless sequential data streaming
Paul et al. Forward Error Correction-based Reliable Multicast Protocols
Delgrossi et al. Reliability and Congestion Control
Protocol RMT Working Group B. Adamson/NRL INTERNET-DRAFT C. Bormann/Tellique

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20071001

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20071001

RD03 Notification of appointment of power of attorney

Free format text: JAPANESE INTERMEDIATE CODE: A7423

Effective date: 20090713

RD04 Notification of resignation of power of attorney

Free format text: JAPANESE INTERMEDIATE CODE: A7424

Effective date: 20090727

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20091222

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20100105

A601 Written request for extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A601

Effective date: 20100405

A602 Written permission of extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A602

Effective date: 20100412

A601 Written request for extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A601

Effective date: 20100506

A602 Written permission of extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A602

Effective date: 20100513

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20100602

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

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

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

Free format text: PAYMENT UNTIL: 20140218

Year of fee payment: 3

R150 Certificate of patent or registration of utility model

Ref document number: 4685787

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

Free format text: JAPANESE INTERMEDIATE CODE: R150

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

S111 Request for change of ownership or part of ownership

Free format text: JAPANESE INTERMEDIATE CODE: R313113

R350 Written notification of registration of transfer

Free format text: JAPANESE INTERMEDIATE CODE: R350

LAPS Cancellation because of no payment of annual fees