JP4357535B2 - 欠落部分の識別および再送信 - Google Patents

欠落部分の識別および再送信 Download PDF

Info

Publication number
JP4357535B2
JP4357535B2 JP2006551871A JP2006551871A JP4357535B2 JP 4357535 B2 JP4357535 B2 JP 4357535B2 JP 2006551871 A JP2006551871 A JP 2006551871A JP 2006551871 A JP2006551871 A JP 2006551871A JP 4357535 B2 JP4357535 B2 JP 4357535B2
Authority
JP
Japan
Prior art keywords
file
session
transmission
identifier
received
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
JP2006551871A
Other languages
English (en)
Other versions
JP2007520961A (ja
Inventor
ロッド ワルシュ
ハルシュ メータ
アイゴル クルシオ
トニ パイラ
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.)
Nokia Oyj
Original Assignee
Nokia Oyj
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 Nokia Oyj filed Critical Nokia Oyj
Publication of JP2007520961A publication Critical patent/JP2007520961A/ja
Application granted granted Critical
Publication of JP4357535B2 publication Critical patent/JP4357535B2/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
    • 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/1809Selective-repeat protocols
    • 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
    • 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/1607Details of the supervisory signal
    • 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
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/02Details
    • H04L12/16Arrangements for providing special services to substations
    • H04L12/18Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
    • H04L12/1863Arrangements for providing special services to substations for broadcast or conference, e.g. multicast comprising mechanisms for improved reliability, e.g. status reports
    • H04L12/1868Measures taken after transmission, e.g. acknowledgments
    • 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
    • H04L12/00Data switching networks
    • H04L12/02Details
    • H04L12/16Arrangements for providing special services to substations
    • H04L12/18Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
    • H04L12/189Arrangements for providing special services to substations for broadcast or conference, e.g. multicast in combination with wireless systems
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • H04L2001/0092Error control systems characterised by the topology of the transmission link
    • H04L2001/0093Point-to-multipoint
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/06Protocols specially adapted for file transfer, e.g. file transfer protocol [FTP]
    • 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/30Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/329Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Detection And Prevention Of Errors In Transmission (AREA)
  • Communication Control (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Information Transfer Between Computers (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Computer And Data Communications (AREA)

Description

本発明は、概ね、マルチキャストおよびブロードキャスト送信技術およびサービス、すなわち1つのデータソース(または送信機)および少なくとも1つの受信機を持つサービスに関する。
IPマルチキャスト、IPデータキャスティング(IPDC)およびマルチメディアブロードキャスト/マルチキャストサービス(MBMS)などのシステム上における一対多数(すなわち、ポイントツーマルチポイント)サービスにとって、ファイル配信(または個々のメディア配信またはファイルダウンロード)は重要なサービスである。ファイル転送プロトコル(FTP)およびハイパーテキスト転送プロトコル(HTTP)などのポイントツーポイントプロトコル上でのファイル配信に関する特徴の多くは、一対多数シナリオにとって問題のあるものである。特に、送信制御プロトコルTCPなどの類似する一対一(すなわちポイントツーポイント)肯定応答(ACK)プロトコルを使用する、信頼できるファイル配信―すなわち保証されたファイル配信―は、実行不可能である。
インターネットエンジニアリングタスクフォース(IETF)のリライアブルマルチキャストトランスポート(RMT)ワーキンググループは現在、2つのカテゴリのエラー回復マルチキャストトランスポートプロトコル標準化を進めている。第1のカテゴリにおいて、信頼性は(プロアクティブ型)前進型誤信号訂正(FEC)の使用によって、すなわち、受信機が誤ったデータを再構成するのを助けることができる一定量の冗長データを送信することによって達成される。第2のカテゴリでは、信頼できるマルチキャストトランスポートを実行するために、受信機のフィードバックが使用される。非同期階層符号化(ALC、RFC3450)は、第1のカテゴリに属するプロトコルインスタンス化であり、一方、NACK型リライアブルマルチキャスト(NORM)プロトコルは第2のカテゴリの例を示すものである。ALCおよびNORMプロトコルについての詳細は、IETFのワーキンググループによって作成された「Asynchronous Layered Coding(ALC)Protocol Instantiation(非同期階層符号化(ALC)プロトコルインスタンス化)」(RFC3450)および「NACK oriented Reliable Multicast Protocol(NACK型リライアブルマルチキャストプロトコル)」(インターネットドラフト)と題された出版物においてさらに詳しく論じられている。これらの出版物の内容は、参照することにより本明細書に完全に組み込まれる。
これらのプロトコルが使用されるアクセスインターネットは、ユニバーサル移動体通信システム(UMTS)システム、ワイヤレスローカルエリアネットワーク(WLAN)、デジタルビデオ放送‐地上波(DVB‐T)ネットワークおよびデジタルビデオ放送‐衛星(DVB‐S)ネットワークの無線アクセスネットワークなどのワイヤレス多重アクセスネットワークを含むがこれらに限定されない。
つまり、ALCプロトコルは、受信機が壊れたパケットまたは受信されていないパケットを再構成できるようにするプロアクティブ型FECベースのスキームである。ALCプロトコルは、多重チャネルにおいて、送信機が場合によっては異種受信機へ複数レート(チャネル)でデータを送信できるようにするFEC符号化を使用する。また、ALCプロトコルは、異なるチャネルにおいて異なるレートを維持するため、輻輳制御機構を使用する。
ALCプロトコルは、アップリンクシグナリングが必要ないため、ユーザ数に関して大規模に拡張可能である。したがって、どれだけ受信機を追加しても、必ずしもシステムの需要を増やすわけではない。しかしながらALCプロトコルは、受信が保証されていないため、100%信頼できるわけではなく、したがって一般的に強固なものとはされていない。
同様に、NORMは、受信機に到着すると予期されたどのデータのパケット(または「データブロック」と定義される)が受信機で受信されなかった(または誤って受信された)のかを知らせるために、否定応答(NACK)メッセージの使用法を特定する。言い換えると、受信機は、NACKを用いて送信されたパケットの損失または損傷を送信機に示す。したがって、データ送信から一部のデータブロックが「欠落した」受信機は、その欠落したデータブロックを再送信するよう送信機に要求するNACKメッセージを、送信機に対して送信することができる。NORMプロトコルは、プロアクティブ型の強固な送信のため、任意でパケットレベルFEC符号化の使用も可能にする。
File Delivery over Unidirectional Transport(一方向トランスポートでのファイル配信、FLUTE)は、FECおよびALCビルディングブロックを基礎とする一対多数トランスポートプロトコルである。これは、一方向システム上での送信機から受信機へのファイル配信用のものであり、ワイヤレスポイントツーマルチポイント(マルチキャスト)システムに適合させる特殊化を有する。FLUTEプロトコルについての詳細は、上述のIETFのワーキンググループによって作成された「FLUTE−File Delivery over Unidirectional Transport(一方向トランスポートでのファイル配信)」(インターネットドラフト)と題された出版物においてさらに詳しく論じられている。この出版物の内容は、参照することにより本明細書に完全に組み込まれる。
NACKメッセージは概してNORM固有ではなく、その他のプロトコルまたはシステムに関連して使用することもできる。FLUTEセッションに関連して(または特に一対多数送信を対象とするトランスポート層プロトコルを使用するセッションにおいて)NACKメッセージを使用する場合、欠落パケット(またはブロック)の識別は重要な問題である。TCPなどの一対一(またはポイントツーポイント)送信用のプロトコル、およびそれらの応答方法の使用は、ここで必ずしも実行可能とは限らない。例えば、一対多数システムにおけるTCP応答方法の使用により、多額の間接費が発生するであろう。したがって、正確な再送信が行えるよう、一対多数シナリオにおいて受信されなかったパケットを確実に識別することが必要である。
AsynchronousLayered Coding (ALC) Protocol Instantiation (RFC 3450), IETF Working Group. NACKoriented Reliable Multicast Protocol (Internet Draft), IETF Working Group. FLUTE-FileDelivery over Unidirectional Transport (Internet Draft), IETF Working Group.
マルチキャスト/ブロードキャストチャネル上で確実にデータを送信するためにNACKメッセージを使用する場合、欠落パケットの識別が重要な問題であると考えられている。これには、再送信が必要なブロックの識別に加え、送信の状況に関する情報の保守が必要である。応答時間に関して、NACK要求(受信機により送信され、送信機により受信される)は以下の2つのカテゴリに分けられるとされている。
a)初期送信後直ちに、または間もなく受信され、同一セッション内において満たすことのできるNACK要求(例えば、FLUTEセッションまたは類似のもの)。
b)セッション終了後に受信され、別のセッションによってデータが再送信されることを必要とするNACK要求。この場合、その他のセッションは、同一のポイントツーマルチポイントプロトコル(例えば、古いFLUTEセッションの終了後に確立された新しいFLUTEセッション)、または、ポイントツーポイントもしくはポイントツーマルチポイントプロトコル(例えば、FTP、HTTP等)であり得る別のプロトコルを使用するセッションのいずれであってもよい。
いずれの場合も、再送信されるべきブロックを正確に識別することが重要である。
本発明の第1の側面によると、一対多数送信が可能なシステム内におけるファイル配信のための方法であって、
送信機から少なくとも1つの受信機へ1つ以上のデータブロックを転送するステップと、
前記受信機において、受信すると予期されたがまったく受信されなかった、または誤って受信されたデータブロックを識別するステップと、
前記データブロックを再送信するための措置を講じるステップとを含み、
前記識別を、ブロック番号、符号化識別子、およびその他の識別情報に基づいて行うステップを含む方法が提供される。
ある実施形態によれば、その他の情報はセッションパラメータのセットおよび/または送信オブジェクト識別子を含む。
ある実施形態によれば、その他の情報は前記ファイルの情報および/またはブロッキング情報を含む。
本発明の第2の側面によると、一対多数送信が可能なシステム内におけるファイル配信のための受信装置であって、
送信機から1つ以上のデータブロックを受信する手段と、
受信すると予期されたがまったく受信されなかった、または誤って受信されたデータブロックを識別する手段と、
前記データブロックを再送信させるために措置を講じる手段とを備え、前記識別する手段は、ブロック番号、符号化識別子およびその他の識別情報に基づいて前記データブロックを識別するように構成される受信装置が提供される。
本発明の第3の側面によると、一対多数送信が可能なシステム内におけるファイル配信のための送信装置であって、
少なくとも1つの受信機へ1つ以上のデータブロックを送信する手段と、
前記受信機において、受信すると予期されたがまったく受信されなかった、または誤って受信されたデータブロックであって、ブロック番号、符号化識別子およびその他の識別情報に基づいて識別されたデータブロックを再送信する手段とを備える送信装置が提供される。
本発明の第4の側面によると、一対多数送信が可能なシステムであって、
送信機から少なくとも1つの受信機へ1つ以上のデータブロックを転送する手段と、
前記受信機において、受信すると予期されたがまったく受信されなかった、または誤って受信されたデータブロックを識別する手段と、
前記データブロックを再送信するための措置を講じる手段とを備える、
前記識別する手段は、ブロック番号、符号化識別子およびその他の識別情報に基づいて前記データブロックを識別するように構成されるシステムが提供される。
本発明の第5の側面によると、一対多数送信が可能なシステム内におけるファイル配信のための受信装置において実行可能なソフトウェアアプリケーションであって、
前記受信装置に送信機から1つ以上のデータブロックを受信させるためのプログラムコードと、
受信すると予期されたがまったく受信されなかった、または誤って受信されたデータブロックを識別するためのプログラムコードと、
前記受信装置に前記データブロックを再送信させるために措置を講じさせるためのプログラムコードとを備え、
前記識別するためのプログラムコードは、ブロック番号、符号化識別子およびその他の識別情報に基づいて前記データブロックを識別するように構成されるソフトウェアアプリケーションが提供される。
本発明の第6の側面によると、一対多数送信が可能なシステム内におけるファイル配信のための送信装置において実行可能なソフトウェアアプリケーションであって、
前記送信装置に、少なくとも1つの受信機へ1つ以上のデータブロックを送信させるためのプログラムコードと、
前記送信装置に、前記受信機において受信すると予期されたがまったく受信されなかった、または誤って受信されたデータブロックであって、ブロック番号、符号化識別子およびその他の識別情報に基づいて識別されたデータブロックを再送信する手段とを備えるソフトウェアアプリケーションが提供される。
ソフトウェアアプリケーションは、メモリなどの媒体に格納されたプログラムコードを含むコンピュータプログラム製品であってよい。
本発明のさらに別の側面によると、一対多数送信システム内におけるファイル配信のための方法であって、
送信機から少なくとも1つの受信機へ1つ以上のデータブロックを転送するステップと、
ブロック番号および/または符号化識別子領域を使用して、再送信されるべき欠落したデータブロックを識別するステップとを含む方法が提供される。
本発明のこの側面は、別個の側面として、または本発明のその他任意の側面に関連して実行されるべき側面として理解されることができる。
ブロック番号範囲および符号化識別子範囲は、連続的であっても非連続的であってもよい。
受信装置、送信装置、システム、およびソフトウェアアプリケーションは、個々に実装されてよい。
従属請求項は、本発明の実施形態に関する。本発明の特定の側面に関連する従属請求項に含まれる内容は、本発明のその他の側面にも適用できる。
詳細な説明
以下、添付図面を例として参照し、本発明の実施形態を説明する。
本特許出願の導入部に含まれる主題は、詳細な説明を支持するために使用することができる。以下のFile Delivery over Unidirectional Transport(一方向トランスポートでのファイル配信、FLUTE)プロトコルは、本発明がFLUTEのみに関与すると限定することを意図せず、例として使用される。一対多数マルチキャストファイル配信が可能なその他適合するプロトコルも、本発明の関係において適用できる。
図1は、本発明の実施形態に従って通信を行っている送信装置および受信装置を示す。送信装置10は、サーバ、IPベースの装置、DVB装置、GPRS(またはUMTS)装置、または、マルチキャストデータブロック(またはパケット)を受信装置20へ送信するためにALC機構などのプロアクティブ前進型誤信号訂正を任意で使用できる類似の装置である。受信装置20は、欠落ブロック(受信されなかった、または誤って受信されたブロック)に関する否定応答NACKメッセージ(または要求)を送信装置10に送信する。NACKメッセージを受けて、送信装置10は、FLUTEセッション(元の送信のために確立された元のFLUTEセッションと同一のFLUTEセッション、または次のFLUTEセッション)において欠落ブロックを受信装置20へ再送信する。あるいは、FLUTE以外のプロトコルを使用するセッションを使用してもよい。特定の文脈においては、再送信セッションは修復セッションと称される。
データはオブジェクトとして転送される。例えば、ファイル、JPEG画像、ファイルスライスはすべてオブジェクトである。ファイル(またはデータ)配信のため、送信装置10と受信装置20との間にセッションが確立される。単一のセッションは、単一のオブジェクトまたは複数のオブジェクトの送信を含むことができる。オブジェクトとセッションを識別するためには異なる識別子が使用される。各セッションは、送信機(ソース)のアドレス(例えば、IPアドレス)、受信機(宛先)のアドレスおよび送信セッション識別子(Transmission Session Identifier;TSI)または同類のものによって識別される。送信機または受信機のアドレスおよびTSIのみを使用することも可能である。さらに、特定のセッションに関連してパケットが転送されてくるオブジェクトを識別するために、送信オブジェクト識別子(Transmission Object Identifier; TOI)または同類のものが使用される。例えば、送信装置10は、第1のファイルを表す0、第2のファイル等を表す1といったTOIを使用して、同じセッション内のファイル数を送信するかもしれない。
各データブロックは、ソースブロック番号(Source Block Number;SBN)と称される番号または同類のものを有し、これによって各ブロックを識別する。ブロックは、符号化記号のセットによって表される。同様に、データパケット(またはブロック)のペイロードに運ばれる符号化記号がどのようにして上述のオブジェクト(例えば、ファイル)から生成されたかを、符号化記号識別子(Encoding Symbol Identifier;ESI)または同類のものが識別する。
図2Aは、本発明の実施形態に従って、簡略化したプロトコルアーキテクチャを図示している。この実施形態によると、送信装置10および受信装置20のために実装されるプロトコルスタックは、アプリケーション層、FLUTEプロトコル層、UDPおよびIP層、ならびに下位層を含む。FLUTEプロトコル層は、階層符号化トランスポート(LCT)ビルディングブロック(図示せず)のACLプロトコルインスタンス化の上部に構築される。また任意でFECビルディングブロックを使用してもよい。FLUTEプロトコル層は、NACKメッセージとともに、送信装置10から受信装置20へ信頼できるデータブロック送信を提供することを意図されたものである。このプロトコルアーキテクチャは、一対多数送信のために(一対多数送信だけでなく一対多数の「第1の送信」のためにも)使用できる。
あるいは、ある実施形態において、UDP層の代わりにTCP層を使用することができる(図2B参照)。これは、別個のポイントツーポイント修復セッション(ここではTCPセッション)が一対一(すなわち、ポイントツーポイント)再送信のために使用される場合に当てはまる。別の再送信方法の説明は、本明細書中で後に提示する。
以下、受信機が欠落パケット(またはブロック)のセットを識別するための別の事例を提示する。FLUTEソースブロックまたは符号化記号(結果として、1つまたは一連のデータパケット)を識別する2つの方法がある。
識別方法A
識別は、FLUTEセッションパラメータ(ソースアドレス、宛先アドレスおよびTSI)およびTOI(送信オブジェクト識別子)に加えて、SBNおよびESIに基づいて行われる。一般に、FLUTEパケット送信中にこの情報を生成するのは送信装置である。情報は、ALC/FLUTEパケットに含まれる。
識別方法B
識別は、ファイル(すなわち、配信ファイルのURI)、ファイルパラメータ(ファイル長および暗号化コード(MD5コード等)、使用するブロックアルゴリズムおよびブロックパラメータ(最大ソースブロック長、符号化記号長およびファイル長)に加えて、SBNおよびESIに基づいて行われる。情報は、これらのパラメータ/情報を含むFDT(ファイル記述テーブル)または同類のものから得られる。情報は、一般に別個のオブジェクトとしてFLUTEセッションにより運搬される。
以上のように、識別方法AおよびBの両方が、ブロック番号および符号化識別子、またさらに一定のその他の識別情報を利用する。識別方法Aは、セッション自体(ここでは、FLUTEセッション)から直接得られる詳細を使用し、一方で識別方法Bはその他の情報(すなわち、配信ファイルについての情報)も使用する。
識別方法とは別に、後続の再送信を行うためには以下2つが考えられる。
再送信方法A
再送信のために、FLUTEセッションが使用される(再送信は、同じ(進行中の)FLUTEセッション内で、または別個のFLUTEセッションにおいて成立し得る)。この方法は、ポイントツーポイントまたはポイントツーマルチポイント送信に基づいたものであってよい。
再送信方法B
FLUTE以外の方法、例えばHTTP、SMS、FTP、SAP、GPRS等で再送信するための別個のセッションを使用する。この方法は、ポイントツーポイントまたはポイントツーマルチポイント送信に基づいたものであってよい。
したがって、2つの異なる識別方法および再送信のためのFLUTEまたは別のプロトコルの使用により、パケットを識別し再送信するための4つの異なる組み合わせが発生する。
1.方法Aを使用した識別および方法Aを使用した再送信
2.方法Bを使用した識別および方法Bを使用した再送信
3.方法Aを使用した識別および方法Bを使用した再送信
4.方法Bを使用した識別および方法Aを使用した再送信
上記では、送信中、各符号化記号が唯一のパケット内に含まれていると想定している。しかしながら、複数の符号化記号が同じパケット内に含まれる場合、または単一の符号化記号が複数のパケットにわたっている場合、符号化記号(および符号化記号を含むパケットの部分または単一の符号化記号をそれぞれ含む一連のパケット)が適切に認識される必要がある。
第1の組み合わせ(A+A)は、同じチャネル上における、同じ送信機(またはサーバ)情報を使用した、同じFLUTEセッション内、短いタイムスパンでのパケット再送信が望ましい状況において有用であると考えられる。例えば、FLUTE送信機は、過去5分以内に送信されたすべてのSBNおよびESIをバッファリングする(または一時的に格納する)ことができる。再送信要求(NACK)がこの時間内に到着する場合、この方法が適用できる。
第2の組み合わせ(B+B)は、現在のセッションが終了した後、場合によってはずっと後に再送信が必要とされる状況において有用であると考えられる。セッション中の送信についての長期情報をすべてバッファリングすることは送信装置10にとって実行不可能かもしれないため、限定されない実施形態においては、「第三者サーバ」または修復サーバ(または単に別個のサーバ(図示せず))が送信情報をバッファリングするように構成される。このサーバは、例えば、BM‐SC(ブロードキャストマルチキャスト‐サービスセンター)とも称される元の送信機(例えば、MBMS(マルチメディアブロードキャスト/マルチキャストサービス))サーバと同一場所に配置されてよく、または、例えばUMTSオペレータネットワーク内の別個のサーバであってもよい。このサーバはその後、欠落パケットを再送信することができる。この例としては、GPRS(UMTS)アクセスが割安となる夜間に、GPRSまたはUMTS上で欠落パケットを再送信するサーバがある。再送信は、多くの受信装置20からの再送信要求(NACK)を送信装置10にオーバーロードするのを回避するため、再送信セッションが終了した直後、またはセッション終了後およびデータが受信装置20によって消費される前であれば、いつでも開始することができる。別個の修復サーバを有するという概念は、その他の実施形態にも当てはまる。
以下のステップは、前述の典型的な実施形態を説明するものである。
1.送信装置10がFLUTEセッションを使用して1つ以上のファイルを送信する。
2.セッションの終了時に、受信装置20が、受信しなかったすべてのパケットに関する1つ以上のNACKメッセージを送信する。このNACKメッセージが新しいセッションの開始を表す。
3.送信装置10が、新しいセッションにおいて、受信装置20により要求されたすべてのデータを再送信する。
4.新しく作成されたセッションが、送信装置10および受信装置20で閉鎖される。
上記のステップ2に関連する例として、HTTP上で特定のSBNおよびESIを使用するデータに関し、NACKを送信するには以下の方法を使用することができる。
Figure 0004357535
ここで、SBNおよびESIは、否定応答される(すなわち、NACKされる)ファイルの部分のソースブロック番号および符号化記号IDである。ここではファイル名をnumber1.mps、NACKされるSBNおよびESIをそれぞれ123および234とする。上記のHTTPクエリーにおいて、SBNおよびESIフィールドは、SBNおよびESI領域のためのNACKにも使用できる。例えば、
Figure 0004357535
である。
上記はファイルnumber1.mp3、SBN123、126および127、ならびにESI234乃至238についてNACKするものである。その他いくつかそのような組み合わせが可能であり、例えば次のようなものがある。
Figure 0004357535
NACKが1つ以上のパケットの再送信を求める要求を含むことが可能である。これがネットワークチャネル上で確実に送信される場合、単一のNACKにすべてのパケット要求を含むのがより効率的である。そうでない場合、いくつかのNACKにわたってすべてのパケットを要求できる。
以下は、あるFLUTEセッション中に欠落したパケットを再送信するための、本発明のさらに別の実施形態を説明するものである。この実施形態は、前述の4つの識別/再送信の組み合わせとは無関係である。
この実施形態において、FLUTEセッションコンテキスト(SBN、ESI、TSIおよびTOI)は後にFLUTE以外で使用するために格納される。このコンテキストは、その後FLUTE以外の方法を使用してデータを送信するために使用することができる。これを実行するためには、「セッションコンテキスト」を独自に識別する識別子、例えばマルチキャストIDを有することが有用であると考えられる。本明細書において「セッションコンテキスト」は例えばセッションのための独自の識別子を形成するために結合したセッションのすべての識別子であってよい。本明細書で使用される再送信方法は先に説明した組み合わせ方法4と同じであるが、セッション情報の格納に関して相違があることに留意すべきである。ある実施形態において、セッション情報は送信装置および受信装置の両方によって格納され、FLUTEセッション外において、送信装置と受信装置との間で通信を行う。
本発明のさらに別の実施形態によると、受信装置20は、再送信が必要なパケットを算出するよりもむしろ、再送信が必要な(送信装置10によって送信された元のオブジェクトの)バイト領域を算出する。また、この実施形態においては、SBNおよびESIを識別に使用することもできる。受信装置は、受信されなかったバイト領域を表すNACKメッセージを送信する。同じパケット内に複数のバイト領域が存在することが可能である。NACKメッセージを受けて、送信装置10は元のオブジェクトからバイト領域を再送信する。ワード領域に加えて、受信装置10は、バイト領域の代わりにビット領域を算出し、それらが再送信されるよう要求してもよい。
本発明の別の実施形態では、ソースブロックの、ソース記号よりも、欠落している冗長符号化記号が識別され、そのすべてまたは一部が再送信される。受信装置20から送信装置10(1つを超える送信装置があってもよい)に送信されたNACKは、したがって冗長記号に基づくものである。このスキームは特に、符号化された「冗長記号」だけが送信され、符号化されていない「ソース記号」は送信されず、また一般に、各ソースブロックにおける冗長符号化記号の一定の閾値数はソースブロックを完了する必要があり、したがってファイルを再構成する必要がある、体系的なFECスキームに適用できる。
例えば、各ソースブロックにつき送信装置によって送信される記号が1000あるような典型的なFECスキームにおいて、ファイルの配信を完了する(または正しく行う)ために受信装置によって受信されるよう要求される閾値数はちょうど500である。しかしながら、この典型的な事例において、受信装置が得る記号は、490だけである(単一のソースブロックから符号化記号のみが欠落していると想定する。いくつかのソースブロックから符号化記号が欠落していれば、以下の算出は欠落している記号を有する各ソースブロックについて行われる必要がある)。そのようなシナリオにおいて、各ファイルのソースブロックごとに当てはまるものとしては以下が考えられる。
1.受信装置が欠落記号を識別する;受信装置がブロックを完了するために十分な数を算定する;受信装置が欠落記号の一部(完了するために十分なもの)についてNACK
する;送信装置がこれらの記号を再送信する。
2.受信装置が欠落記号を識別する;受信装置がすべての欠落記号にNACKする;送信装置がこれらの記号をすべて再送信する。
3.受信装置が欠落記号を識別する;受信装置がすべての欠落記号にNACKする;送信装置がブロックを完了するのに十分な数を算定する;送信装置が欠落記号の一部(「十分な」数を数えて)を選択する;送信装置がこれらの記号を再送信する。
4.受信装置が受信した記号に肯定応答する(ACKする);送信装置が欠落記号を識別する;送信装置がこれらの記号をすべて再送信する。
5.受信装置が受信した記号にACKする;送信装置が欠落記号を識別する;送信装置がブロックを完了するのに十分な数を算定する;送信装置が欠落記号の一部(「十分な」数を数えて)を選択する;送信装置がこれらの記号を再送信する。
1つを超える記号、1つを超えるソースブロックおよび/または1つを超えるファイルが各NACKにおいて参照されるようにNACK(またはACK)を結合させるという選択は、アプリケーションごとの最適化に関する問題である。
「十分な」記号の定義は、特に他の何らかの手段(TCPトランスポート等)によって修復が確実に行われる場合、閾値数(上記の例では510のうち10)を完全にするために要求される数そのものであってよく、または、リンクによる損失を見越してそれより多くてもよい(例えば、上記の例では記号の51%が失われており、同じ通信チャネルを再度使用するならば同様のことが予測でき、したがっておそらく10×(100/51)=20の記号を再送信するのがより適切であろう。また、さらに安全マージンを追加してもよく(例えば、バーストエラーを処理するため)、これが3つの記号である場合は、「やり遂げる」のに必要なのが10だけであっても、23の記号を使用して修復することができるであろう。乗数(ここでは「100/51」)および定数(ここでは3)のいずれも、(これらの例のように)一定のパケット損失を想定するか、または元の送信の損失パターンに依存してよい。例えば、送信装置は損失記号の分布を分析することができ、それが不均一であった場合(例えば、3つの連続する記号が約20の記号ごとに頻繁に損失する)、いくつかの(例えば、20の記号につき3つ)追加の記号を加えてもよい(この例においては、ここでも23の記号という結果になる)。
さらにもう1つの例として、ファイルを完了するために必要なソースブロックにおける10の記号の前記閾値数を識別した後、受信装置は、これらの10の記号を再送信するよう要求するNACKを送信装置に送信することが考えられる。送信装置はこれらの記号を以前にキャッシュに格納されている通りに再送信してもよく、または代替の方法においては、送信装置は記号に対応するファイルまたはソースブロックにおいてFEC符号化の反復を行い、これらの記号を再送信する。この後者の方法によって、初期送信、分離される、および場合によっては異なるサーバ設備に配備される修復サーバ機能が可能になる。
さらに別の例として、受信装置が510の欠落記号のそれぞれに関するNACK(または、代替の実施形態において、490の記号を受信したという肯定応答)を送信することが考えられる。送信装置はその後、10の欠落記号のみを再送信するか、または510すべての欠落記号を再送信する。再送信するのは、以前にキャッシュに格納した記号か、新しくFEC符号化した記号であってよい。
記号識別に基づいて受信装置から送信装置へ送信された再送信(または修復)要求に加え、ファイルおよび/またはそれらのソースブロックにおいて要求は1つ以上のバイト領域を特定することができる。これは、受信した記号がブロックから欠落しているバイト領域を算定するのに十分である場合に適用できる。
欠落パケットを再送信するために、ポイントツーポイントまたはポイントツーマルチポイント送信が使用できることを説明してきた。明確にするための実施形態は、ポイントツーポイント再送信(または修復)を対象とする。この実施形態において、関係する各受信装置はポイントツーポイント接続(またはセッション)上で送信装置に否定応答(NACK)メッセージを送信する。受信装置において受信されたNACKの数および/または内容に応じて、受信装置は、
1)ポイントツーポイント接続を使用して欠落ブロックを各受信装置へ個別に送信するか否か、または、
2)ポイントツーマルチポイント接続(すなわち、マルチキャストまたは同類のもの)を使用して欠落ブロックを送信するか否か
の判断を下す。
多数の受信装置が同じ欠落パケットに関するNACK要求を送信した場合、2番目の選択肢がより望ましい。このように、単一の再送信で、複数の受信機の修復を行い、リソースを保存することが可能である。
図3は、本発明の実施形態に従って、システムおよび受信装置の詳細を示す。前記システムは、送信機10、例えばIPネットワークまたは別の固定ネットワークやワイヤレスネットワークまたは固定およびワイヤレス(セルラー)ネットワークの組み合わせ等の送信ネットワーク30、および受信装置20を備える。受信装置20は、携帯電話、衛星電話、携帯情報端末またはブルートゥース装置、WLAN装置、DVB装置、もしくはその他同類のワイヤレス装置であってよい。装置20は、内部メモリ21、プロセッサ22、オペレーティングシステム23、アプリケーションプログラム24、ネットワークインターフェイス25および識別&NACK機構26を含む。内部メモリ21は、プロセッサ22、オペレーティングシステム23およびアプリケーションプログラム24を収容する。識別&NACK機構26により、データパケットの識別を行い、データ送信における欠落または壊れたパケットに応じて、送信装置10へNACKおよびデータを送信することが可能になる。装置20は、ネットワークインターフェイス25およびネットワーク30を介して送信装置10およびその他の装置と通信を行うことができる。
図4は、本発明の実施形態に従って、送信装置10を示す。送信装置10は、例えば、ネットワークサーバまたはファイル(またはメディア)配信を対照とした任意の適合する装置であってよい。装置10は、内部メモリ11、プロセッサ12、オペレーティングシステム13、アプリケーションプログラム14、ネットワークインターフェイス15および送信&再送信機構16を含む。内部メモリ11は、プロセッサ12、オペレーティングシステム13およびアプリケーションプログラム14を収容する。送信&再送信機構16により、データパケットの送信、および受信装置20から受信したNACKに応じてデータパケットの再送信を行うことが可能になる。装置10は、ネットワークインターフェイス15およびネットワーク30を介して受信装置20およびその他の装置と通信を行うことができる。
欠落したデータパケットの識別およびその再送信に関する手順は、ソフトウェアにより実行できる。受信装置20に格納され、プロセッサ20において作動するプログラムコードを備えるコンピュータプログラム製品は、送信セッションの受信終了時に前記手順を実行するために使用することができ、一方、送信装置10に格納され、プロセッサ12において作動するプログラムコードを備えるコンピュータプログラム製品は、送信終了時に前記手順を実行するために使用することができる。
以下、本発明の実施形態の利点について論じる。本発明の実施形態は、欠落データを再送信するための新しいフレームワークを提供する。
以上に基づき明らかとなったように、このフレームワークにより、以下のシナリオにおける欠落データの再送信が可能になる。
・FLUTEのセッション内において、欠落パケットに関する情報が送信装置でまだ利用可能であり、短時間のうちに送信装置からNACKが受信された場合。
・欠落パケットがもともと送信された先の、元来のFLUTEセッション外に、それらのパケットを再送信するよう要求された場合。この再送信は、FLUTEまたは別の送信方法を使用して発生する場合がある。
本発明の実施形態が提供する利点の一部は、
・(連続的または非連続的な)欠落ブロック(またはパケット)を独自に識別する方法
・同じ(または多数の)セッション上で1つの(または複数の)ファイルの欠落ブロック(またはパケット)を識別する方法
・多数の送信プロトコル上で欠落ブロック(またはパケット)を識別し再送信する方法
・適時に欠落パケットを再送信する能力。ここで適時は、可能な基準(利用可能な帯域幅、割安な通信事業者等)を使用して選択される
・確実に(基礎となるトランスポートプロトコルが信頼できる)および単一の修復転送セッションで欠落パケットを再送信する能力
である。
したがって、本発明の実施形態は、一対多数マルチキャストセッションの内外いずれかにおいて欠落したブロックのために、否定応答(NACK)メッセージを識別し、送信するための方法を提示するものである。
本発明の特定の実行および実施形態について説明した。当業者には、本発明が上記に提示した実施形態の詳細に限定されるものでなく、本発明の特徴から逸脱することなく、同等の手段を使用してその他の実施形態で実行できることが明らかである。本発明の範囲は、添付の特許請求の範囲によってのみ限定される。
本発明の実施形態に従い通信を行っている送信装置および受信装置を示す。 図2Aは、本発明の実施形態に従う簡略化したプロトコルアーキテクチャを図示している。図2Bは、本発明の別の実施形態に従う簡略化したプロトコルアーキテクチャを図示している。 本発明の実施形態に従うシステムおよび受信装置の詳細を示す。 本発明の実施形態に従う送信装置を示す。

Claims (32)

  1. 一対多数送信が可能なシステム内において、ファイル配信のために受信機が実行する方法であって、
    送信機から送られてきたファイルの1つ以上のデータブロックを受信することと、
    受信すると予期されたがまったく受信されなかった、または誤って受信された、前記ファイルのデータブロックを識別することと、
    前記データブロックを再送信するため動作を実行することとを含み、
    前記データブロックを識別することは、ブロック番号、符号化識別子、および前記ファイルのファイル情報を含むその他の識別情報に基づいて行われ、前記ファイル情報は、前記ファイルの統一リソース識別子かファイルパラメータの少なくともいずれかを含む、方法。
  2. 前記その他の識別情報がセッションパラメータのセットを含む、請求項1に記載の方法。
  3. 前記その他の識別情報が送信オブジェクト識別子を含む、請求項1に記載の方法。
  4. 一方向トランスポートでのファイル配信を対象とし、一対多数送信シナリオが可能なセッションベースのプロトコルが使用される、請求項1に記載の方法。
  5. 前記プロトコルが、FLUTE(File Delivery over Uni−directional Transport)であり、前記ブロック番号がソースブロック番号であり、前記符号化識別子が符号化記号識別子であり、識別に使用されるセッションパラメータのセットがソースアドレス、宛先アドレスおよび送信セッション識別子から成るグループから選択され、前記識別において、FLUTEによって定義されるように送信オブジェクト識別子が使用される、請求項4に記載の方法。
  6. 前記その他の識別情報がブロック情報を含む、請求項1に記載の方法。
  7. 一方向トランスポートでのファイル配信を対象とし、一対多数送信シナリオが可能なセッションベースのプロトコルが使用される、請求項1に記載の方法。
  8. 前記プロトコルが、FLUTE(File Delivery over Uni−directional Transport,一方向トランスポートでのファイル配信)または類似のものであり、前記ブロック番号がソースブロック番号であり、前記符号化識別子が符号化記号識別子であり、前記ファイルパラメータは、前記ファイル長暗号化コードの少なくともいずれかを含み、
    前記識別において、使用されたブロックアルゴリズムと、最大ソースブロック長・符号化記号長・ファイル長などのブロックパラメータとから成るグループから選択されるブロック情報が使用される、請求項に記載の方法。
  9. 前記方法が、一対多数送信シナリオでの送信を対象としたプロトコルの使用におけるデータブロック送信のために、前記送信機と前記受信機との間にセッションを提供することを含む、請求項1に記載の方法。
  10. 前記データブロックを再送信するための措置を講じることが、前記受信機から前記送信機へ否定応答メッセージを送信することを含む、請求項1に記載の方法。
  11. ファイル配信が第1のセッションにおいて実行され、前記否定応答メッセージが同一の第1のセッション中に再送信を発生させる、請求項10に記載の方法。
  12. ファイル配信が第1のセッションにおいて実行され、前記否定応答メッセージが前記第1のセッション以外のセッション中に再送信を発生させる、請求項10に記載の方法。
  13. 前記その他のセッションが、前記第1のセッションが終了した後に確立されたセッションである、請求項12に記載の方法。
  14. 前記否定応答メッセージが、1つ以上のデータブロックまたはパケットの再送信要求を含む、請求項10に記載の方法。
  15. 前記否定応答メッセージが送信セッションの終了時に送信され、前記否定応答メッセージが、欠落したブロックの再送信を行うために新しいセッションの開始を示す、請求項14に記載の方法。
  16. セッションコンテキストが後の使用のために格納される、請求項1に記載の方法。
  17. 前記セッションコンテキストが、前記セッション内に、前記セッションコンテキスト自体を独自に識別する識別子に加えて、ソースブロック番号符号化記号識別子送信セッション識別子、および送信オブジェクト識別子などの識別子を含む、請求項16に記載の方法。
  18. データブロックの初期送信がFLUTEセッションにおいて行われ、再送信が同一もしくは異なるFLUTEセッション、または別のセッションにおいて行われる、請求項1に記載の方法。
  19. 否定応答メッセージがポイントツーポイントセッション上で受信機のセットから送信機へ送信され、再送信がポイントツーマルチポイントセッション上で行われる、請求項1に記載の方法。
  20. 前記受信機のセットが1つを超える受信機を含む、請求項19に記載の方法。
  21. 再送信がユニキャスト(ポイントツーポイント)送信によって行われる、請求項1に記載の方法。
  22. 一対多数送信が可能なシステム内におけるファイル配信のための受信装置であって、
    送信機から送られてきたファイルの1つ以上のデータブロックを受信する手段と、
    受信すると予期されたがまったく受信されなかった、または誤って受信された、前記ファイルのデータブロックを識別する手段と、
    前記データブロックを再送信させるための動作を実行する手段とを備え、
    前記識別する手段は、ブロック番号、符号化識別子および前記ファイルのファイル情報を含むその他の識別情報に基づいて前記データブロックを識別するように構成され、前記ファイル情報は、前記ファイルの統一リソース識別子かファイルパラメータの少なくともいずれかを含む、受信装置。
  23. 前記その他の識別情報がセッションパラメータのセットを含む、請求項22に記載の受信装置。
  24. 前記その他の識別情報が送信オブジェクト識別子を含む、請求項22に記載の受信装置。
  25. 前記その他の識別情報がブロック情報を含む、請求項22に記載の受信装置。
  26. 一対多数送信が可能なシステム内におけるファイル配信のための受信装置において実行可能なコンピュータ・プログラムであって、
    前記受信装置に送信機から送られてきたファイルの1つ以上のデータブロックを受信させるためのプログラムコードと、
    前記受信装置に、受信すると予期されたがまったく受信されなかった、または誤って受信された、前記ファイルのデータブロックを識別させるためのプログラムコードと、
    前記受信装置に前記データブロックを再送信させるためのプログラムコードとを備え、
    前記識別するためのプログラムコードは、ブロック番号、符号化識別子および前記ファイルのファイル情報を含むその他の識別情報に基づいて前記データブロックを識別するように構成され、ただし前記ファイル情報は、前記ファイルの統一リソース識別子かファイルパラメータの少なくともいずれかを含む
    コンピュータ・プログラム
  27. 一対多数送信が可能なシステム内におけるファイル配信のための送信装置であって、
    少なくとも1つの受信機へ、ファイルの1つ以上のデータブロックを送信する手段と、
    前記受信機において、受信すると予期されたがまったく受信されなかった、または誤って受信された、前記ファイルデータブロックを再送信する手段と、
    を備え、ただし前記再送信されるデータブロックは、ブロック番号、符号化識別子および前記ファイルのファイル情報を含むその他の識別情報に基づいて識別されたものであり、前記ファイル情報は、前記ファイルの統一リソース識別子かファイルパラメータの少なくともいずれかを含む、
    送信装置。
  28. 一対多数送信が可能なシステム内におけるファイル配信のための送信装置において実行可能なコンピュータ・プログラムであって、
    前記送信装置に、少なくとも1つの受信機へ、ファイルの1つ以上のデータブロックを送信させるためのプログラムコードと、
    前記送信装置に、前記受信機において受信すると予期されたがまったく受信されなかった、または誤って受信された、前記ファイルのデータブロックを再送信させるためのプログラムコードと、
    を含み、ただし前記再送信されるデータブロックは、ブロック番号、符号化識別子および前記ファイルのファイル情報を含むその他の識別情報に基づいて識別されたものであり、前記ファイル情報は、前記ファイルの統一リソース識別子かファイルパラメータの少なくともいずれかを含む、
    コンピュータ・プログラム
  29. 一対多数送信が可能なシステムであって、
    送信機から少なくとも1つの受信機へ、ファイルの1つ以上のデータブロックを転送する手段と、
    前記受信機において受信すると予期されたがまったく受信されなかった、または誤って受信された、前記ファイルのデータブロックを識別する手段と、
    前記データブロックを再送信するための動作を実行する手段とを備え、
    前記識別する手段は、ブロック番号、符号化識別子および前記ファイルのファイル情報を含むその他の識別情報に基づいて前記データブロックを識別するように構成され、前記ファイル情報は、前記ファイルの統一リソース識別子かファイルパラメータの少なくともいずれかを含む
    システム。
  30. 前記その他の識別情報が、セッションパラメータのセットおよび送信オブジェクト識別子を含む、請求項29に記載のシステム。
  31. 前記その他の識別情報が送信オブジェクト識別子を含む、請求項29に記載のシステム。
  32. 前記その他の識別情報がブロック情報を含む、請求項29に記載のシステム。
JP2006551871A 2004-02-13 2005-02-11 欠落部分の識別および再送信 Expired - Fee Related JP4357535B2 (ja)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US10/778,926 US7599294B2 (en) 2004-02-13 2004-02-13 Identification and re-transmission of missing parts
PCT/FI2005/050029 WO2005078982A1 (en) 2004-02-13 2005-02-11 Identification and re-transmission of missing parts

Publications (2)

Publication Number Publication Date
JP2007520961A JP2007520961A (ja) 2007-07-26
JP4357535B2 true JP4357535B2 (ja) 2009-11-04

Family

ID=34838272

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2006551871A Expired - Fee Related JP4357535B2 (ja) 2004-02-13 2005-02-11 欠落部分の識別および再送信

Country Status (14)

Country Link
US (1) US7599294B2 (ja)
EP (2) EP2728783A1 (ja)
JP (1) JP4357535B2 (ja)
KR (1) KR100855386B1 (ja)
CN (1) CN1918841B (ja)
AU (1) AU2005212895A1 (ja)
BR (1) BRPI0507557A (ja)
CA (3) CA2851953A1 (ja)
ES (1) ES2488846T3 (ja)
MY (1) MY143914A (ja)
SG (1) SG149868A1 (ja)
TW (1) TWI312622B (ja)
WO (1) WO2005078982A1 (ja)
ZA (1) ZA200607568B (ja)

Families Citing this family (56)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7068729B2 (en) 2001-12-21 2006-06-27 Digital Fountain, Inc. Multi-stage code generator and decoder for communication systems
US6307487B1 (en) 1998-09-23 2001-10-23 Digital Fountain, Inc. Information additive code generator and decoder for communication systems
US9240810B2 (en) 2002-06-11 2016-01-19 Digital Fountain, Inc. Systems and processes for decoding chain reaction codes through inactivation
EP2348640B1 (en) 2002-10-05 2020-07-15 QUALCOMM Incorporated Systematic encoding of chain reaction codes
WO2005036753A2 (en) 2003-10-06 2005-04-21 Digital Fountain, Inc. Error-correcting multi-stage code generator and decoder for communication systems having single transmitters or multiple transmitters
EP1716665B1 (en) * 2004-02-18 2009-05-27 Telefonaktiebolaget LM Ericsson (publ) Method and device for reliable broadcast
US20050223098A1 (en) * 2004-04-06 2005-10-06 Matsushita Electric Industrial Co., Ltd. Delivery mechanism for static media objects
WO2005112250A2 (en) 2004-05-07 2005-11-24 Digital Fountain, Inc. File download and streaming system
GB2419975A (en) * 2004-11-09 2006-05-10 Nokia Corp Auxiliary content handling
CN101088070B (zh) * 2004-12-31 2011-07-27 英特尔公司 远程记录机制的方法与系统
EP1859353A4 (en) * 2005-03-07 2012-02-22 Intel Corp SELF-ADAPTIVE MUTTON-DELAY FILE TRANSFER PROTOCOL
WO2007052143A2 (en) * 2005-11-04 2007-05-10 Nokia Corporation Method, wireless local area network (wlan), node and apparatus for multicast and/or broadcast ackowledgements
JP5550834B2 (ja) 2006-02-13 2014-07-16 デジタル ファウンテン, インコーポレイテッド 可変fecオーバヘッド及び保護期間を利用したストリーミング及びバッファリング
US9270414B2 (en) 2006-02-21 2016-02-23 Digital Fountain, Inc. Multiple-field based code generator and decoder for communications systems
US7664198B2 (en) * 2006-03-21 2010-02-16 Kyocera Corporation System and method for broadcasting data over a wireless network using rateless codes
WO2007115991A1 (en) * 2006-04-11 2007-10-18 Thomson Licensing Data reception method, repair method and corresponding terminal
WO2007134196A2 (en) 2006-05-10 2007-11-22 Digital Fountain, Inc. Code generator and decoder using hybrid codes
CN100454822C (zh) * 2006-05-13 2009-01-21 华为技术有限公司 一种用于多媒体广播和组播业务中的下载分发方法
US9386064B2 (en) 2006-06-09 2016-07-05 Qualcomm Incorporated Enhanced block-request streaming using URL templates and construction rules
US9209934B2 (en) 2006-06-09 2015-12-08 Qualcomm Incorporated Enhanced block-request streaming using cooperative parallel HTTP and forward error correction
US9419749B2 (en) 2009-08-19 2016-08-16 Qualcomm Incorporated Methods and apparatus employing FEC codes with permanent inactivation of symbols for encoding and decoding processes
US9380096B2 (en) 2006-06-09 2016-06-28 Qualcomm Incorporated Enhanced block-request streaming system for handling low-latency streaming
US9178535B2 (en) 2006-06-09 2015-11-03 Digital Fountain, Inc. Dynamic stream interleaving and sub-stream based delivery
US9432433B2 (en) 2006-06-09 2016-08-30 Qualcomm Incorporated Enhanced block-request streaming system using signaling or block creation
US20080101317A1 (en) * 2006-10-30 2008-05-01 Nokia Corporation System and method for providing advanced session control of a unicast session
CA2577030A1 (en) * 2007-01-31 2008-07-31 Unlimi-Tech Software Inc. Improved data transfer method, system and protocol
BRPI0816680A2 (pt) * 2007-09-12 2015-03-17 Qualcomm Inc Gerar e comunicar informações de identificação de origem pra habilitar comunicações confiáveis.
JP2009094863A (ja) * 2007-10-10 2009-04-30 Nippon Telegr & Teleph Corp <Ntt> 高信頼マルチキャストデータ配信システム,高信頼マルチキャストデータ配信方法および高信頼マルチキャストデータ配信プログラム
JP2009135772A (ja) * 2007-11-30 2009-06-18 Oki Semiconductor Co Ltd ルータ装置
EP2109293A1 (en) * 2008-04-11 2009-10-14 Thomson Licensing System and method for improving the file transmission reliability
TWI486040B (zh) * 2008-10-10 2015-05-21 Thomson Licensing 在接收器要求失落符號之方法及其接收器
CN101420317B (zh) * 2008-11-21 2011-10-26 华为终端有限公司 媒体文件录制错误的修复方法、录制终端、服务器和系统
US9281847B2 (en) 2009-02-27 2016-03-08 Qualcomm Incorporated Mobile reception of digital video broadcasting—terrestrial services
CA2757465C (en) * 2009-04-01 2015-11-10 Qualcomm Atheros, Inc. Managing transmissions among nodes communicating over a shared communication medium
US9015564B2 (en) * 2009-08-19 2015-04-21 Qualcomm Incorporated Content delivery system with allocation of source data and repair data among HTTP servers
US9288010B2 (en) 2009-08-19 2016-03-15 Qualcomm Incorporated Universal file delivery methods for providing unequal error protection and bundled file delivery services
US9917874B2 (en) 2009-09-22 2018-03-13 Qualcomm Incorporated Enhanced block-request streaming using block partitioning or request controls for improved client-side handling
US8397120B2 (en) * 2009-12-15 2013-03-12 Hong Kong Applied Science And Technology Research Institute Co. Ltd. Method of error correction for a multicast message
KR101412422B1 (ko) * 2009-12-17 2014-06-25 인텔 코오퍼레이션 감소된 네트워크 오버헤드로 일대다 데이터 송신들을 용이하게 하기 위한 방법 및 시스템
US9596447B2 (en) 2010-07-21 2017-03-14 Qualcomm Incorporated Providing frame packing type information for video coding
US9319448B2 (en) 2010-08-10 2016-04-19 Qualcomm Incorporated Trick modes for network streaming of coded multimedia data
US8619776B2 (en) * 2010-12-20 2013-12-31 Lockheed Martin Corporation Multiprotocol offload engine architecture
US8958375B2 (en) 2011-02-11 2015-02-17 Qualcomm Incorporated Framing for an improved radio link protocol including FEC
US9270299B2 (en) 2011-02-11 2016-02-23 Qualcomm Incorporated Encoding and decoding using elastic codes with flexible source block mapping
CN102790664A (zh) * 2011-05-19 2012-11-21 昆盈企业股份有限公司 一对多无线数据传输方法及装置
US9253233B2 (en) 2011-08-31 2016-02-02 Qualcomm Incorporated Switch signaling methods providing improved switching between representations for adaptive HTTP streaming
US9843844B2 (en) 2011-10-05 2017-12-12 Qualcomm Incorporated Network streaming of media data
CN104067594A (zh) * 2011-11-01 2014-09-24 高通股份有限公司 在http服务器之间分配源数据和修复数据的内容传送系统
CN103138871B (zh) * 2011-11-23 2015-09-30 毕书清 移动通讯系统中应用程序的服务器数据处理系统和方法
CN103209195A (zh) * 2012-01-11 2013-07-17 国家电网公司 数据获取方法、终端以及远端设备
US9213605B2 (en) * 2012-01-23 2015-12-15 Intel Corporation IP multimedia subsystem and method for MBMS file repair using HTTP servers
US9294226B2 (en) 2012-03-26 2016-03-22 Qualcomm Incorporated Universal object delivery and template-based file delivery
US8909605B1 (en) * 2013-02-28 2014-12-09 Emc Corporation Method and system for accelerating data movement using change information concerning difference between current and previous data movements
US9900166B2 (en) * 2013-04-12 2018-02-20 Qualcomm Incorporated Methods for delivery of flows of objects over broadcast/multicast enabled networks
WO2022006850A1 (en) * 2020-07-10 2022-01-13 Qualcomm Incorporated Transmitting encoding symbol identifier of raptor codes using control channel coding
CN114499993B (zh) * 2021-12-30 2022-11-29 郑州大学 一种基于单向光闸的高可靠性安全传输与控制系统及方法

Family Cites Families (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH05219056A (ja) 1992-02-04 1993-08-27 Nec Corp 同報通信方式
JP3614907B2 (ja) * 1994-12-28 2005-01-26 株式会社東芝 データ再送制御方法及びデータ再送制御システム
JPH09270790A (ja) 1996-04-01 1997-10-14 N T T Data Tsushin Kk ファイル配信方法及び通信制御装置
US6148005A (en) * 1997-10-09 2000-11-14 Lucent Technologies Inc Layered video multicast transmission system with retransmission-based error recovery
US6505253B1 (en) * 1998-06-30 2003-01-07 Sun Microsystems Multiple ACK windows providing congestion control in reliable multicast protocol
US6678855B1 (en) * 1999-12-02 2004-01-13 Microsoft Corporation Selecting K in a data transmission carousel using (N,K) forward error correction
JP2002124992A (ja) 2000-08-10 2002-04-26 Kddi Corp マルチキャストによるデータファイル配信方法
DE10129777A1 (de) 2001-06-20 2003-01-02 Siemens Ag Verfahren und Vorrichtung zur Datenübertragung gemäß einem ARQ-Verfahren
CN1225860C (zh) * 2001-11-28 2005-11-02 华为技术有限公司 一种混合自动重传方法
AU2003238968A1 (en) 2002-06-11 2003-12-22 Meshnetworks, Inc. System and method for multicast media access in ad-hoc communication networks
US7430617B2 (en) * 2003-12-19 2008-09-30 Nokia Corporation Method and system for header compression
US7296205B2 (en) * 2004-02-18 2007-11-13 Nokia Corporation Data repair
US7423986B2 (en) * 2004-03-26 2008-09-09 Cisco Technology, Inc. Providing a multicast service in a communication network

Also Published As

Publication number Publication date
CA2770432C (en) 2014-07-29
JP2007520961A (ja) 2007-07-26
MY143914A (en) 2011-07-29
TW200534630A (en) 2005-10-16
WO2005078982A1 (en) 2005-08-25
ES2488846T3 (es) 2014-08-29
CA2553069A1 (en) 2005-08-25
KR20060120248A (ko) 2006-11-24
EP1714415B1 (en) 2014-06-04
CA2851953A1 (en) 2005-08-25
CN1918841A (zh) 2007-02-21
AU2005212895A1 (en) 2005-08-25
EP1714415A1 (en) 2006-10-25
US20050182842A1 (en) 2005-08-18
ZA200607568B (en) 2009-04-29
CN1918841B (zh) 2010-12-22
US7599294B2 (en) 2009-10-06
KR100855386B1 (ko) 2008-09-04
SG149868A1 (en) 2009-02-27
TWI312622B (en) 2009-07-21
BRPI0507557A (pt) 2007-07-03
CA2553069C (en) 2012-04-03
EP2728783A1 (en) 2014-05-07
CA2770432A1 (en) 2005-08-25

Similar Documents

Publication Publication Date Title
JP4357535B2 (ja) 欠落部分の識別および再送信
KR100904072B1 (ko) 데이터 패킷들의 신뢰성 있는 멀티캐스트 전송을 위한 장치, 시스템, 방법 및 컴퓨터로 읽을 수 있는 매체
EP1771964B1 (en) Point-to-point repair request mechanism for point-to-multipoint transmission systems
KR100831654B1 (ko) 멀티캐스트 및 브로드캐스트 전송을 관리할 수 있는시스템에서 데이터 복구 방법
US7376150B2 (en) Point-to-point repair response mechanism for point-to-multipoint transmission systems
US20050216472A1 (en) Efficient multicast/broadcast distribution of formatted data
JP4536383B2 (ja) データ受信装置およびデータ受信方法
US20090204865A1 (en) Data repair enhancements for multicast/broadcast data distribution
KR100883576B1 (ko) 멀티캐스트/브로드캐스트 데이터 배포를 위한 데이터 복구강화
MXPA06008486A (es) Identificacion y retransmision de partes perdidas
KR100870236B1 (ko) 점-대-다중점 송신 시스템을 위한 점-대-점 보수 응답메커니즘

Legal Events

Date Code Title Description
A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20081225

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20090115

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20090302

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

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

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

Free format text: PAYMENT UNTIL: 20120814

Year of fee payment: 3

R150 Certificate of patent or registration of utility model

Free format text: JAPANESE INTERMEDIATE CODE: R150

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

Free format text: PAYMENT UNTIL: 20120814

Year of fee payment: 3

S111 Request for change of ownership or part of ownership

Free format text: JAPANESE INTERMEDIATE CODE: R313113

S533 Written request for registration of change of name

Free format text: JAPANESE INTERMEDIATE CODE: R313533

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

Free format text: PAYMENT UNTIL: 20120814

Year of fee payment: 3

R371 Transfer withdrawn

Free format text: JAPANESE INTERMEDIATE CODE: R371

S111 Request for change of ownership or part of ownership

Free format text: JAPANESE INTERMEDIATE CODE: R313113

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

Free format text: PAYMENT UNTIL: 20120814

Year of fee payment: 3

R350 Written notification of registration of transfer

Free format text: JAPANESE INTERMEDIATE CODE: R350

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

Free format text: PAYMENT UNTIL: 20120814

Year of fee payment: 3

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

Free format text: PAYMENT UNTIL: 20130814

Year of fee payment: 4

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

Free format text: PAYMENT UNTIL: 20130814

Year of fee payment: 4

S111 Request for change of ownership or part of ownership

Free format text: JAPANESE INTERMEDIATE CODE: R313113

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

Free format text: PAYMENT UNTIL: 20130814

Year of fee payment: 4

R350 Written notification of registration of transfer

Free format text: JAPANESE INTERMEDIATE CODE: R350

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

LAPS Cancellation because of no payment of annual fees