Nothing Special   »   [go: up one dir, main page]

JP2014533045A - Ｈｔｔｐサーバの間でのソースデータおよび修復データの割り当てを伴うコンテンツ配送システム - Google Patents

Ｈｔｔｐサーバの間でのソースデータおよび修復データの割り当てを伴うコンテンツ配送システム Download PDF

Info

Publication number
JP2014533045A
JP2014533045A JP2014540098A JP2014540098A JP2014533045A JP 2014533045 A JP2014533045 A JP 2014533045A JP 2014540098 A JP2014540098 A JP 2014540098A JP 2014540098 A JP2014540098 A JP 2014540098A JP 2014533045 A JP2014533045 A JP 2014533045A
Authority
JP
Japan
Prior art keywords
symbols
source
file
request
symbol
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
JP2014540098A
Other languages
English (en)
Other versions
JP5795446B2 (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.)
Qualcomm Inc
Original Assignee
Qualcomm Inc
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
Priority claimed from US13/563,590 external-priority patent/US9015564B2/en
Application filed by Qualcomm Inc filed Critical Qualcomm Inc
Publication of JP2014533045A publication Critical patent/JP2014533045A/ja
Application granted granted Critical
Publication of JP5795446B2 publication Critical patent/JP5795446B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H03—ELECTRONIC CIRCUITRY
    • H03M—CODING; DECODING; CODE CONVERSION IN GENERAL
    • H03M13/00—Coding, decoding or code conversion, for error detection or error correction; Coding theory basic assumptions; Coding bounds; Error probability evaluation methods; Channel models; Simulation or testing of codes
    • H03M13/03—Error detection or forward error correction by redundancy in data representation, i.e. code words containing more digits than the source words
    • H03M13/05—Error detection or forward error correction by redundancy in data representation, i.e. code words containing more digits than the source words using block codes, i.e. a predetermined number of check bits joined to a predetermined number of information bits
    • H03M13/11—Error detection or forward error correction by redundancy in data representation, i.e. code words containing more digits than the source words using block codes, i.e. a predetermined number of check bits joined to a predetermined number of information bits using multiple parity bits
    • H03M13/1102—Codes on graphs and decoding on graphs, e.g. low-density parity check [LDPC] codes
    • H—ELECTRICITY
    • H03—ELECTRONIC CIRCUITRY
    • H03M—CODING; DECODING; CODE CONVERSION IN GENERAL
    • H03M13/00—Coding, decoding or code conversion, for error detection or error correction; Coding theory basic assumptions; Coding bounds; Error probability evaluation methods; Channel models; Simulation or testing of codes
    • H03M13/35—Unequal or adaptive error protection, e.g. by providing a different level of protection according to significance of source information or by adapting the coding according to the change of transmission channel characteristics
    • H03M13/356—Unequal error protection [UEP]
    • H—ELECTRICITY
    • H03—ELECTRONIC CIRCUITRY
    • H03M—CODING; DECODING; CODE CONVERSION IN GENERAL
    • H03M13/00—Coding, decoding or code conversion, for error detection or error correction; Coding theory basic assumptions; Coding bounds; Error probability evaluation methods; Channel models; Simulation or testing of codes
    • H03M13/37—Decoding methods or techniques, not specific to the particular type of coding provided for in groups H03M13/03 - H03M13/35
    • H03M13/3761—Decoding 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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/40—Support for services or applications
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]

Landscapes

  • Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Probability & Statistics with Applications (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Detection And Prevention Of Errors In Transmission (AREA)
  • Error Detection And Correction (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)

Abstract

データオブジェクトが、パケット交換ネットワークを介して配送され、受信機は、どのソースシンボルまたはサブシンボルが必要とされており、または失われているかに基づいて、必要に応じて追加のシンボルを求める要求を形成するのに十分な情報とともに、ブロードキャストまたはマルチキャストされた、修復シンボルなどの符号化シンボルを受信する。要求は、ユニキャストまたは要求方法で行うことができる。要求およびブロードキャストは、異なるエンティティによって行うことができる。ブロードキャストサーバは、修復シンボルを生成し、記憶することができ、一方、ソースサーバは、ソース形式でコンテンツを記憶することができる。要求は、ＵＲＬ、開始位置、および長さなどの、ユニキャストＨＴＴＰバイト範囲要求とすることができる。要求は、ファイルの開始位置と合わせることができる。受信機は、ファイル内のシンボルまたはサブシンボルの開始バイト位置および終了バイト位置を計算することができ、ファイル修復のために従来のＨＴＴＰサーバが使用可能である旨の表示を取得することができる。修復サーバは、複数の受信機からのバイト範囲要求が重複する場合、修復データのブロードキャストを要求することができる。

Description

関連出願の相互参照
本出願は、２０１１年１１月１日に出願された、「Ｕｎｉｃａｓｔ Ｒｅｐａｉｒ Ｓｅｒｖｉｃｅ ａｎｄ Ｓｅｒｖｅｒ Ａｕｇｍｅｎｔｉｎｇ Ｂｒｏａｄｃａｓｔ Ｆｉｌｅ Ｄｅｌｉｖｅｒｙ Ｓｙｓｔｅｍ」と題する、米国仮特許出願第６１／５５４４３４号（整理番号１２１５１９Ｐ１）、２０１２年１月２３日に出願された、「Ｕｎｉｃａｓｔ Ｒｅｐａｉｒ Ｓｅｒｖｉｃｅ ａｎｄ Ｓｅｒｖｅｒ Ａｕｇｍｅｎｔｉｎｇ Ｂｒｏａｄｃａｓｔ Ｆｉｌｅ Ｄｅｌｉｖｅｒｙ Ｓｙｓｔｅｍ」と題する、仮特許出願第６１／５８９８５５号（整理番号１２１５１９Ｐ２）、２０１２年３月２２日に出願された、「Ｕｎｉｃａｓｔ Ｒｅｐａｉｒ Ｓｅｒｖｉｃｅ ａｎｄ Ｓｅｒｖｅｒ Ａｕｇｍｅｎｔｉｎｇ Ｂｒｏａｄｃａｓｔ Ｆｉｌｅ Ｄｅｌｉｖｅｒｙ Ｓｙｓｔｅｍ」と題する、仮特許出願第６１／６１４４０８号（整理番号１２１５１９Ｐ３）、２０１２年５月１０日に出願された、「Ｃｏｎｔｅｎｔ Ｄｅｌｉｖｅｒｙ Ｓｙｓｔｅｍ ｗｉｔｈ Ａｌｌｏｃａｔｉｏｎ ｏｆ Ｓｏｕｒｃｅ Ｄａｔａ ａｎｄ Ｒｅｐａｉｒ Ｄａｔａ Ａｍｏｎｇ ＨＴＴＰ Ｓｅｒｖｅｒｓ」と題する、米国仮特許出願第６１／６４５５６２号（整理番号１２１５１９Ｐ４）、および２０１２年５月１５日に出願された、「Ｃｏｎｔｅｎｔ Ｄｅｌｉｖｅｒｙ Ｓｙｓｔｅｍ ｗｉｔｈ Ａｌｌｏｃａｔｉｏｎ ｏｆ Ｓｏｕｒｃｅ Ｄａｔａ ａｎｄ Ｒｅｐａｉｒ Ｄａｔａ Ａｍｏｎｇ ＨＴＴＰ Ｓｅｒｖｅｒｓ」と題する、米国仮特許出願第６１／６４７４１４号（整理番号１２１５１９Ｐ５）の優先権を主張する、それらの非仮出願であり、それらの開示全体が、あらゆる目的で、参照により本明細書に組み込まれる。
本開示は、本出願の譲受人に譲渡された次の特許または出願に関連することがあり、それらの各々は、あらゆる目的で、その全体が参照により本明細書に組み込まれる。
１）Ｍｉｃｈａｅｌ Ｇ．Ｌｕｂｙに対して発行された、「Ｉｎｆｏｒｍａｔｉｏｎ Ａｄｄｉｔｉｖｅ Ｃｏｄｅ Ｇｅｎｅｒａｔｏｒ ａｎｄ Ｄｅｃｏｄｅｒ ｆｏｒ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｓｙｓｔｅｍｓ」と題する、米国特許第６３０７４８７号（以降本明細書では「Ｌｕｂｙ Ｉ」）。
２）Ｍｉｃｈａｅｌ Ｇ．Ｌｕｂｙに対して発行された、「Ｉｎｆｏｒｍａｔｉｏｎ Ａｄｄｉｔｉｖｅ Ｇｒｏｕｐ Ｃｏｄｅ Ｇｅｎｅｒａｔｏｒ ａｎｄ Ｄｅｃｏｄｅｒ ｆｏｒ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｓｙｓｔｅｍｓ」と題する、米国特許第６３２０５２０号（以降本明細書では「Ｌｕｂｙ ＩＩ」）。
３）Ｍ．Ａｍｉｎ Ｓｈｏｋｒｏｌｌａｈｉに対して発行された、「Ｓｙｓｔｅｍｓ ａｎｄ Ｐｒｏｃｅｓｓｅｓ ｆｏｒ Ｄｅｃｏｄｉｎｇ ａ Ｃｈａｉｎ Ｒｅａｃｔｉｏｎ Ｃｏｄｅ Ｔｈｒｏｕｇｈ Ｉｎａｃｔｉｖａｔｉｏｎ」と題する、米国特許第６８５６２６３号（以降本明細書では「Ｓｈｏｋｒｏｌｌａｈｉ Ｉ」）。
４）Ｍ．Ａｍｉｎ Ｓｈｏｋｒｏｌｌａｈｉに対して発行された、「Ｓｙｓｔｅｍａｔｉｃ Ｅｎｃｏｄｉｎｇ ａｎｄ Ｄｅｃｏｄｉｎｇ ｏｆ Ｃｈａｉｎ Ｒｅａｃｔｉｏｎ Ｃｏｄｅｓ」と題する、米国特許第６９０９３８３号（以降本明細書では「Ｓｈｏｋｒｏｌｌａｈｉ ＩＩ」）、
５）Ｍ．Ａｍｉｎ Ｓｈｏｋｒｏｌｌａｈｉに対して発行された、「Ｍｕｌｔｉ Ｓｔａｇｅ Ｃｏｄｅ Ｇｅｎｅｒａｔｏｒ ａｎｄ Ｄｅｃｏｄｅｒ ｆｏｒ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｓｙｓｔｅｍｓ」と題する、米国特許第７０６８７２９号（以降本明細書では「Ｓｈｏｋｒｏｌｌａｈｉ ＩＩＩ」）。
６）Ｍｉｃｈａｅｌ Ｇ．Ｌｕｂｙ、Ｍ．Ａｍｉｎ Ｓｈｏｋｒｏｌｌａｈｉ、Ｍａｒｋ Ｗａｔｓｏｎに対して発行された、「Ｆｉｌｅ Ｄｏｗｎｌｏａｄ ａｎｄ Ｓｔｒｅａｍｉｎｇ Ｓｙｓｔｅｍ」と題する、米国特許第７４１８６５１号（以降本明細書では「Ｌｕｂｙ ＩＩＩ」）。
７）Ｍｉｃｈａｅｌ Ｇ．Ｌｕｂｙ、Ｍ．Ａｍｉｎ Ｓｈｏｋｒｏｌｌａｈｉの名による、「Ｉｎ Ｐｌａｃｅ Ｔｒａｎｓｆｏｒｍａｔｉｏｎｓ ｗｉｔｈ Ａｐｐｌｉｃａｔｉｏｎｓ ｔｏ Ｅｎｃｏｄｉｎｇ ａｎｄ Ｄｅｃｏｄｉｎｇ Ｖａｒｉｏｕｓ Ｃｌａｓｓｅｓ ｏｆ Ｃｏｄｅｓ」と題する、米国特許公開第２００６／０２８０２５４号（以降本明細書では「Ｌｕｂｙ ＩＶ」）。
８）Ｍ．Ａｍｉｎ Ｓｈｏｋｒｏｌｌａｈｉの名による、「Ｍｕｌｔｉｐｌｅ Ｆｉｅｌｄ Ｂａｓｅｄ Ｃｏｄｅ Ｇｅｎｅｒａｔｏｒ ａｎｄ Ｄｅｃｏｄｅｒ ｆｏｒ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ｓｙｓｔｅｍｓ」と題する、米国特許公開第２００７／０１９５８９４号（以降本明細書では「Ｓｈｏｋｒｏｌｌａｈｉ ＩＶ」）。
９）２００９年１０月２３日に出願された、Ｍ．Ａｍｉｎ Ｓｈｏｋｒｏｌｌａｈｉ他の名による、「Ｍｅｔｈｏｄ ａｎｄ Ａｐｐａｒａｔｕｓ Ｅｍｐｌｏｙｉｎｇ ＦＥＣ Ｃｏｄｅｓ ｗｉｔｈ Ｐｅｒｍａｎｅｎｔ Ｉｎａｃｔｉｖａｔｉｏｎ ｏｆ Ｓｙｍｂｏｌｓ ｆｏｒ Ｅｎｃｏｄｉｎｇ ａｎｄ Ｄｅｃｏｄｉｎｇ Ｐｒｏｃｅｓｓｅｓ」と題する、米国特許出願第１２／６０４７７３号（以降本明細書では「Ｓｈｏｋｒｏｌｌａｈｉ Ｖ」）。
１０）２００９年８月１９日に出願された、Ｍｉｃｈａｅｌ Ｇ．Ｌｕｂｙの名による、「Ｍｅｔｈｏｄｓ ａｎｄ Ａｐｐａｒａｔｕｓ Ｅｍｐｌｏｙｉｎｇ ＦＥＣ Ｃｏｄｅｓ ｗｉｔｈ Ｐｅｒｍａｎｅｎｔ Ｉｎａｃｔｉｖａｔｉｏｎ ｏｆ Ｓｙｍｂｏｌｓ ｆｏｒ Ｅｎｃｏｄｉｎｇ ａｎｄ Ｄｅｃｏｄｉｎｇ Ｐｒｏｃｅｓｓｅｓ」と題する、米国仮出願第６１／２３５２８５号（以降本明細書では「Ｌｕｂｙ Ｖ」）。
１１）２０１０年８月１８日に出願された、Ｍｉｃｈａｅｌ Ｇ．Ｌｕｂｙ、Ｍ．Ａｍｉｎ Ｓｈｏｋｒｏｌｌａｈｉの名による、「Ｍｅｔｈｏｄｓ ａｎｄ Ａｐｐａｒａｔｕｓ Ｅｍｐｌｏｙｉｎｇ ＦＥＣ Ｃｏｄｅｓ ｗｉｔｈ Ｐｅｒｍａｎｅｎｔ Ｉｎａｃｔｉｖａｔｉｏｎ ｏｆ Ｓｙｍｂｏｌｓ ｆｏｒ Ｅｎｃｏｄｉｎｇ ａｎｄ Ｄｅｃｏｄｉｎｇ Ｐｒｏｃｅｓｓｅｓ」と題する、米国特許出願第１２／８５９１６１号（以降本明細書では「Ｓｈｏｋｒｏｌｌａｈｉ ＶＩ」）。
１２）２０１１年８月９日に出願された、Ｍｉｃｈａｅｌ Ｇ．Ｌｕｂｙ、Ｔｈａｄｉ Ｍ．Ｎａｇａｒａｊの名による、「Ｂｒｏａｄｃａｓｔ Ｍｕｌｔｉｍｅｄｉａ Ｓｔｏｒａｇｅ ａｎｄ Ａｃｃｅｓｓ Ｕｓｉｎｇ Ｐａｇｅ Ｍａｐｓ ｗｈｅｎ Ａｓｙｍｍｅｔｒｉｃ Ｍｅｍｏｒｙ ｉｓ Ｕｓｅｄ」と題する、米国特許出願第１３／２０６４１８号（以降本明細書では「Ｌｕｂｙ ＶＩ」）。
１３）２０１２年５月１０日に出願された、Ｍｉｃｈａｅｌ Ｇ．Ｌｕｂｙ、Ｎｉｋｏｌａｉ Ｌｅｕｎｇ、Ｒａｌｐｈ Ｇｈｏｌｍｉｅｈ、Ｔｈｏｍａｓ Ｓｔｏｃｋｈａｍｍｅｒの名による、「Ｃｏｎｔｅｎｔ Ｄｅｌｉｖｅｒｙ Ｓｙｓｔｅｍ ｗｉｔｈ Ａｌｌｏｃａｔｉｏｎ ｏｆ Ｓｏｕｒｃｅ Ｄａｔａ ａｎｄ Ｒｅｐａｉｒ Ｄａｔａ Ａｍｏｎｇ ＨＴＴＰ Ｓｅｒｖｅｒｓ」と題する、米国特許出願第６１／６４５５６２号（以降本明細書では「Ｌｕｂｙ ＶＩＩ」）。
参考文献
以下の参考文献の各々は、あらゆる目的で、その全体が参照により本明細書に組み込まれる。
［Ａｌｂａｎｅｓｅ９６］または［ＰＥＴ］、「Ｐｒｉｏｒｉｔｙ Ｅｎｃｏｄｉｎｇ Ｔｒａｎｓｍｉｓｓｉｏｎ」、Ａｎｄｒｅｓ Ａｌｂａｎｅｓｅ、Ｊｏｈａｎｎｅｓ Ｂｌｏｍｅｒ、Ｊｅｆｆ Ｅｄｍｏｎｄｓ、Ｍｉｃｈａｅｌ Ｌｕｂｙ、Ｍａｄｈｕ Ｓｕｄａｎ、ＩＥＥＥ Ｔｒａｎｓａｃｔｉｏｎｓ ｏｎ Ｉｎｆｏｒｍａｔｉｏｎ Ｔｈｅｏｒｙ、ｖｏｌ．４２、ｎｏ．６（１９９６年１１月）。
［Ａｌｂａｎｅｓｅ９７］または［ＰＥＴ特許］、Ａ．Ａｌｂａｎｅｓｅ、Ｍ．Ｌｕｂｙ、Ｊ．Ｂｌｏｍｅｒ、Ｊ．Ｅｄｍｏｎｄｓに対する、「Ｓｙｓｔｅｍ ｆｏｒ Ｐａｃｋｅｔｉｚｉｎｇ Ｄａｔａ Ｅｎｃｏｄｅｄ Ｃｏｒｒｅｓｐｏｎｄｉｎｇ ｔｏ Ｐｒｉｏｒｉｔｙ Ｌｅｖｅｌｓ Ｗｈｅｒｅ Ｒｅｃｏｎｓｔｒｕｃｔｅｄ Ｄａｔａ Ｃｏｒｒｅｓｐｏｎｄｓ ｔｏ Ｆｒａｃｔｉｏｎａｌｉｚｅｄ Ｐｒｉｏｒｉｔｙ Ｌｅｖｅｌ ａｎｄ Ｒｅｃｅｉｖｅｄ Ｆｒａｃｔｉｏｎａｌｉｚｅｄ Ｐａｃｋｅｔｓ」と題する、米国特許第５６１７５４１号（１９９７年４月１日発行）。
［ＡＬＣ］、Ｌｕｂｙ，Ｍ．、Ｗａｔｓｏｎ，Ｍ．、Ｖｉｃｉｓａｎｏ，Ｌ．、「Ａｓｙｎｃｈｒｏｎｏｕｓ Ｌａｙｅｒｅｄ Ｃｏｄｉｎｇ （ＡＬＣ） Ｐｒｏｔｏｃｏｌ Ｉｎｓｔａｎｔｉａｔｉｏｎ」、ＩＥＴＦ ＲＦＣ ５７７５（Ａｐｒｉｌ ２０１０年４月）。
［ＦＥＣ ＢＢ］、Ｗａｔｓｏｎ，Ｍ．、Ｌｕｂｙ，Ｍ．、Ｌ．Ｖｉｃｉｓａｎｏ、「Ｆｏｒｗａｒｄ Ｅｒｒｏｒ Ｃｏｒｒｅｃｔｉｏｎ （ＦＥＣ） Ｂｕｉｌｄｉｎｇ Ｂｌｏｃｋ」、ＩＥＴＦ ＲＦＣ ５０５２（２００７年８月）。
［ＦＬＵＴＥ］、Ｐａｉｌａ，Ｔ．、Ｌｕｂｙ，Ｍ．、Ｌｅｈｔｏｎｅｎ，Ｒ、Ｒｏｃａ，Ｖ．、Ｗａｌｓｈ，Ｒ．、「ＦＬＵＴＥ−Ｆｉｌｅ Ｄｅｌｉｖｅｒｙ ｏｖｅｒ Ｕｎｉｄｉｒｅｃｔｉｏｎａｌ Ｔｒａｎｓｐｏｒｔ」、ＩＥＴＦ ＲＦＣ ３９２６（２００４年１０月）。
［ＬＣＴ］、Ｌｕｂｙ，Ｍ．、Ｗａｔｓｏｎ，Ｍ．、Ｖｉｃｉｓａｎｏ，Ｌ．、「Ｌａｙｅｒｅｄ Ｃｏｄｉｎｇ Ｔｒａｎｓｐｏｒｔ （ＬＣＴ） Ｂｕｉｌｄｉｎｇ Ｂｌｏｃｋ」、ＩＥＴＦ ＲＦＣ ５６５１（２００９年１０月）。
［Ｌｕｂｙ２００７］または［Ｒａｐｔｏｒ ＲＦＣ ５０５３］、Ｍ．Ｌｕｂｙ、Ａ．Ｓｈｏｋｒｏｌｌａｈｉ、Ｍ．Ｗａｔｓｏｎ、Ｔ．Ｓｔｏｃｋｈａｍｍｅｒ、「Ｒａｐｔｏｒ Ｆｏｒｗａｒｄ Ｅｒｒｏｒ Ｃｏｒｒｅｃｔｉｏｎ Ｓｃｈｅｍｅ ｆｏｒ Ｏｂｊｅｃｔ Ｄｅｌｉｖｅｒｙ」、ＩＥＴＦ ＲＦＣ ５０５３（２００７年９月）。
［Ｌｕｂｙ２００２］、Ｌｕｂｙ，Ｍ．、Ｖｉｃｉｓａｎｏ，Ｌ．、Ｇｅｍｍｅｌｌ，Ｊ．、Ｒｉｚｚｏ，Ｌ．、Ｈａｎｄｌｅｙ，Ｍ．、Ｊ．Ｃｒｏｗｃｒｏｆｔ、「Ｔｈｅ Ｕｓｅ ｏｆ Ｆｏｒｗａｒｄ Ｅｒｒｏｒ Ｃｏｒｒｅｃｔｉｏｎ （ＦＥＣ） ｉｎ Ｒｅｌｉａｂｌｅ Ｍｕｌｔｉｃａｓｔ」、ＩＥＴＦ ＲＦＣ ３４５３（２００２年１２月）。
［Ｍａｔｓｕｏｋａ］または［ＬＤＰＣ拡張］、「Ｌｏｗ Ｄｅｎｓｉｔｙ Ｐａｒｉｔｙ Ｃｈｅｃｋ Ｃｏｄｅ Ｅｘｔｅｎｓｉｏｎｓ Ａｐｐｌｉｅｄ ｆｏｒ Ｂｒｏａｄｃａｓｔ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｉｎｔｅｇｒａｔｅｄ Ｃｏｎｔｅｎｔ Ｄｅｌｉｖｅｒｙ」、Ｈｏｓｅｉ Ｍａｔｓｕｏｋａ、Ａｋｉｒａ Ｙａｍａｄａ、Ｔｏｍｏｙｕｋｉ Ｏｈｙａ、Ｒｅｓｅａｒｃｈ Ｌａｂｏｒａｔｏｒｉｅｓ、ＮＴＴ ＤＯＣＯＭＯ，Ｉｎｃ．、３−６，Ｈｉｋａｒｉ Ｎｏ Ｏｋａ，Ｙｏｋｏｓｕｋａ，Ｋａｎａｇａｗａ，２３９−８５３６，Ｊａｐａｎ。
［ＲａｐｔｏｒＱ−ＲＦＣ−６３３０］、Ｍ．Ｌｕｂｙ、Ａ．Ｓｈｏｋｒｏｌｌａｈｉ、Ｍ．Ｗａｔｓｏｎ、Ｔ．Ｓｔｏｃｋｈａｍｍｅｒ、Ｌ．Ｍｉｎｄｅｒ、「ＲａｐｔｏｒＱ Ｆｏｒｗａｒｄ Ｅｒｒｏｒ Ｃｏｒｒｅｃｔｉｏｎ Ｓｃｈｅｍｅ ｆｏｒ Ｏｂｊｅｃｔ Ｄｅｌｉｖｅｒｙ」、ＩＥＴＦ ＲＦＣ ６３３０、Ｒｅｌｉａｂｌｅ Ｍｕｌｔｉｃａｓｔ Ｔｒａｎｓｐｏｒｔ（２０１１年８月）。
［Ｒｏｃａ］または［ＬＤＰＣ ＲＦＣ ５１７０］、Ｖ．Ｒｏｃａ、Ｃ．Ｎｅｕｍａｎｎ、Ｄ．Ｆｕｒｏｄｅｔ、「Ｌｏｗ Ｄｅｎｓｉｔｙ Ｐａｒｉｔｙ Ｃｈｅｃｋ （ＬＤＰＣ） Ｓｔａｉｒｃａｓｅ ａｎｄ Ｔｒｉａｎｇｌｅ Ｆｏｒｗａｒｄ Ｅｒｒｏｒ Ｃｏｒｒｅｃｔｉｏｎ （ＦＥＣ） Ｓｃｈｅｍｅｓ」、ＩＥＴＦ ＲＦＣ ５１７０（２００８年７月）。
本発明は、通信システムにおけるデータの符号化および復号に関し、より詳細には、効率的な方法で伝達データ内のエラーおよびギャップを考慮してデータを符号化および復号する、ならびに異なるファイル配送方法を扱う、通信システムに関する。
通信チャネルを介して送信機と受信機との間でファイルを送信するための技法は、多くの文献の主題である。好ましくは、受信機は、あるレベルの確実性で、送信機によってチャネルを介して送信されたデータの正確なコピーを受信することを望む。チャネルが完全な忠実性を有さない場合（これはほとんどすべての物理的に実現可能なシステムに当てはまる）、１つの関心事は、送信中に失われた、または誤伝送されたデータにどのように対処すべきかである。受信機は、破損データが受信された場合、それが誤っていると常に見分けられるとは限らないので、破損データ（誤り）よりも、紛失データ（消失）のほうが、対処が容易なことが多い。多くの誤り訂正符号が、消失および／または誤りを訂正するために開発されてきた。
一般に、使用される特定の符号は、データが送信されているチャネルの非忠実性、および送信されているデータの性質についての何らかの情報に基づいて選択される。たとえば、チャネルが長期間の非忠実性を有することが知られている場合、バースト誤り符号が、そのアプリケーションに最もよく適していることがある。短い低頻度の誤りのみが予想される場合、単純なパリティ符号が最良のことがある。
本明細書で使用される場合、「ソースデータ」とは、１つもしくは複数の送信機において入手可能であり、誤りおよび／または消失などを伴うまたは伴わない送信シーケンスから回復によって獲得するために受信機が使用される、データのことを指す。本明細書で使用される場合、「符号化データ」とは、伝達され、ソースデータを回復または獲得するために使用できる、データのことを指す。単純なケースでは、符号化データは、ソースデータのコピーであるが、受信された符号化データが、（誤りおよび／または消失が原因で）送信された符号化データと異なる場合、この単純なケースでは、ソースデータについての追加データがないので、ソースデータは、完全には回復可能にならないことがある。送信は、空間または時間を経ることができる。より複雑なケースでは、符号化データは、変換においてソースデータに基づいて生成され、１つまたは複数の送信機から受信機に送信される。ソースデータが符号化データの一部であることがわかる場合、符号化は、「システマティック」であると言われる。システマティックな符号化の単純な例では、符号化データを形成するために、ソースデータについての冗長な情報が、ソースデータの末尾に追加される。
また本明細書で使用される場合、「入力データ」とは、ＦＥＣ（前方誤り訂正）符号化器装置、またはＦＥＣ符号化器モジュール、コンポーネント、ステップなど（「ＦＥＣ符号化器」）の入力において存在する、データのことを指し、「出力データ」とは、ＦＥＣ符号化器の出力において存在する、データのことを指す。対応して、出力データは、ＦＥＣ復号器の入力において存在することが予想され、ＦＥＣ復号器は、それが処理する出力データに基づいて、入力データまたはそれの対応物を出力することが予想される。場合によっては、入力データは、ソースデータであり、またはソースデータを含み、場合によっては、出力データは、符号化データであり、または符号化データを含む。たとえば、ＦＥＣ符号化器の入力の前に処理が存在しない場合、入力データは、ソースデータである。しかし、場合によっては、ソースデータの代わりにＦＥＣ符号化器に提示される中間データを生成するために、ソースデータは、異なる形式に処理される（たとえば、静的符号化器、逆符号化器、または別のプロセス）。
場合によっては、送信機デバイスまたは送信機プログラムコードは、２つ以上のＦＥＣ符号化器を備えることができ、すなわち、ソースデータは、一連の複数のＦＥＣ符号化器で符号化データに変換される。同様に、受信機において、受信された符号化データからソースデータを生成するために適用される、２つ以上のＦＥＣ復号器が存在することがある。
データは、シンボルに分割されるものと考えることができる。符号化器は、ソースシンボルまたは入力シンボルの系列から符号化シンボルまたは出力シンボルを生成する、コンピュータシステム、デバイス、または電子回路などであり、復号器は、受信または回復された符号化シンボルまたは出力シンボルからソースシンボルまたは入力シンボルの系列を回復する、対応するコンピュータシステム、デバイス、または電子回路などである。符号化器および復号器は、チャネルによって時間的および／または空間的に隔てられ、受信されたいずれの符号化シンボルも、対応する送信された符号化シンボルと正確には同じでないことがあり、それらが送信されたのと正確に同じ系列で受信されないことがある。シンボルの「サイズ」は、シンボルが実際にビットストリームに分解されるかどうかにかかわらず、ビット単位で測定することができ、２M個のシンボルからなるアルファベットからシンボルが選択される場合、シンボルは、Ｍビットのサイズを有する。本明細書の例の多くでは、シンボルは、オクテット単位で測定され、符号は、２５６通りの可能性があるフィールドにわたって存在することができる（各オクテット内では２５６通りの可能な８ビットパターンが存在する）が、データ測定の異なる単位が使用できること、および様々な方法でデータを測定することがよく知られていることを理解されたい。一般的な文献では、８ビット値を示すために、「バイト」という用語が、「オクテット」という用語と交換可能に使用されることがあるが、文脈によっては、「バイト」は、Ｘビット値を示し、Ｘは、８に等しくなく、たとえば、Ｘ＝７である。本明細書では、「オクテット」という用語と「バイト」という用語は、交換可能に使用される。別段の指摘がない限り、本明細書の例は、シンボル当たりのビットの数について、特定の整数または非整数に限定されない。
Ｌｕｂｙ Ｉは、計算効率的、メモリ効率的、および帯域幅効率的な方法で誤り訂正に対処するための、チェーンリアクション符号などの符号の使用について説明している。チェーンリアクション符号化器によって生成される符号化シンボルの１つの特性は、十分な符号化シンボルが受信されたら直ちに、受信機が元のファイルを回復できることである。具体的には、元のＫ個のソースシンボルを高い確率で回復するために、受信機は、約Ｋ＋Ａ個の符号化シンボルを必要とする。
与えられた状況についての「絶対受信オーバヘッド」は、値Ａによって表されるが、「相対受信オーバヘッド」は、比Ａ／Ｋとして計算することができる。絶対受信オーバヘッドは、データの情報理論的な最少量を超えて、余分なデータをどれだけ受信する必要があるかについての尺度であり、復号器の信頼性に依存し得、ソースシンボルの数Ｋの関数として変化し得る。同様に、相対受信オーバヘッドＡ／Ｋは、データの情報理論的な最少量を超えて、余分なデータをどれだけ受信する必要があるかを、回復されるソースデータのサイズ当たりで示す尺度であり、やはり復号器の信頼性に依存し得、ソースシンボルの数Ｋの関数として変化し得る。
チェーンリアクション符号は、パケットベースのネットワークを介する通信に極めて有益である。しかし、チェーンリアクション符号は、かなり計算集約的になることがあり得る。チェーンリアクション符号または別のレートレス符号（ｒａｔｅｌｅｓｓ ｃｏｄｅ）を使用して符号化を行う動的符号化器の前に、ソースシンボルが静的符号化器を使用して符号化される場合、復号器は、より頻繁またはより容易に復号できることがある。そのような復号器は、たとえば、Ｓｈｏｋｒｏｌｌａｈｉ Ｉに示されている。そこで示される例では、ソースシンボルは、静的符号化器への入力シンボルであり、静的符号化器は、動的符号化器への入力シンボルである出力シンボルを生成し、動的符号化器は、符号化シンボルである出力シンボルを生成し、動的符号化器は、入力シンボルの数に対する固定レートではない量の多数の出力シンボルを生成できる、レートレス符号化器である。静的符号化器は、２つ以上の固定レート符号化器を含むことができる。たとえば、静的符号化器は、ハミング符号化器、低密度パリティチェック（「ＬＤＰＣ」）符号化器、および／または高密度パリティチェック（「ＨＤＰＣ」）符号化器を含むことができる。
チェーンリアクション符号は、いくつかのシンボルが復号器において受信シンボルから回復されると、追加のシンボルを回復するために、それらのシンボルを使用できることがあり、今度は、さらに多くのシンボルを回復するために、追加のシンボルが使用されることがあるという特性を有する。好ましくは、復号器におけるシンボル解決のチェーンリアクションは、受信シンボルのプールが使い尽くされる前に、所望のシンボルのすべてが回復されるように続けることができる。好ましくは、チェーンリアクション符号化および復号プロセスを実行する計算量は低い。所望のシンボルは、元のソースシンボルのすべてを完全に回復するのに必要とされる、または元のソースシンボルのすべてよりも低い何らかの所望のレベルの完全性に必要とされるシンボルのすべてとすることができる。
復号器における回復プロセスは、どのシンボルが受信されたかを決定することと、元の入力シンボルを受信されたそれらの符号化シンボルにマッピングする行列を生成することと、その後、行列を逆行列化し、逆行列と受信された符号化シンボルのベクトルとの行列乗算を実行することとを含むことができる。典型的なシステムでは、これの強引な実施は、過剰な計算労力およびメモリ要件を消費し得る。もちろん、特定の１組の受信された符号化シンボルでは、元の入力シンボルのすべてを回復することが不可能なことがあるが、可能な場合であっても、結果を計算することは、計算的に非常にコストがかかることがある。
前方誤り訂正（「ＦＥＣ」）オブジェクト送信情報（Ｏｂｊｅｃｔ Ｔｒａｎｓｍｉｓｓｉｏｎ Ｉｎｆｏｒｍａｔｉｏｎ）（「ＯＴＩ」）、または「ＦＥＣ ＯＴＩ」
受信機が受信した（または推測できる）ＦＥＣ ＯＴＩに基づいて、受信機は、ファイル転送のソースブロックおよびサブブロック構造を決定することができる。［Ｒａｐｔｏｒ ＲＦＣ ５０５３］および［ＲａｐｔｏｒＱ−ＲＦＣ−６３３０］では、ＦＥＣペイロードＩＤは、（ＳＢＮ，ＥＳＩ）であり、本明細書の図１に示されるように、［Ｒａｐｔｏｒ ＲＦＣ ５０５３］では、ソースブロック番号（ＳＢＮ）は、１６ビットであり、符号化シンボルＩＤ（ＥＳＩ）は、１６ビットであり、一方、［ＲａｐｔｏｒＱ−ＲＦＣ−６３３０］では、ＳＢＮは、８ビットであり、ＥＳＩは、２４ビットである。このＦＥＣペイロードＩＤ形式の１つの難点は、ＳＢＮおよびＥＳＩを割り当てるために、ＦＥＣペイロードＩＤのビットの数を事前決定しなければならず、すべてのファイル配送パラメータに妥当する適切なミックスを決定することが時には困難なことである。
たとえば、［Ｒａｐｔｏｒ ＲＦＣ ５０５３］を使用する場合、２16＝６５５３６個のＥＳＩしか利用可能でないと、状況によっては制限が課されることがあるが、それは、場合によっては、８１９２個のソースシンボルを有するソースブロックが存在することがあり、したがって、符号化シンボルの数は、８倍しか大きくなく、この場合、使用され得る可能な符号レートを１／８より低下させないように制限するためである。この例では、利用可能な２16＝６５５３６個のソースブロックは、使用される数をはるかに上回り得る可能性があり、たとえば、各々が１０２４オクテットからなるソースシンボルを８１９２個有する場合、サポートされ得るファイルのサイズは、５２４ＧＢであり、これは、多くのアプリケーションでは、必要とされるよりも２桁大きい。
別の例として、［ＲａｐｔｏｒＱ−ＲＦＣ−６３３０］を使用する場合、２8＝２５６個のＳＢＮしか利用可能でないと、状況によっては制限が課されることがあるが、それは、ファイルが４ＧＢであるときに、各ソースブロックが８ＭＢに制限された場合（最大サブブロックサイズが２５６ＫＢであり、最小サブシンボルサイズが３２オクテットであり、シンボルサイズが１０２４オクテットである場合がこれに該当し得る）、ソースブロックの数を２５６個に制限すると、今度は、ファイルサイズが２ＧＢに制限されるためである。この例では、可能な符号化シンボルが２24＝１６７７７２１６個も利用可能であることは、使用される数をはるかに上回っている可能性があり、たとえば、ソースシンボルを８１９２個有する場合、可能な符号化シンボルの数は、２０４８倍も大きく、アプリケーションによっては、それほどの数は必要とされないことがある。
別の望ましい特性は、ファイルの異なる部分の間の、不均一誤り保護（「ＵＥＰ」）とも呼ばれることがある、優先度付けされた符号化送信のための機能を提供することである。たとえば、ファイルの最初の１０％を残りの９０％よりも強力にパケットロスから保護することが望ましいことがある。たとえば、［ＬＤＰＣ拡張］は、ＵＥＰのサポートを提供するために、［ＬＤＰＣ ＲＦＣ ５１７０］がどのように拡張され得るかについて説明している。この場合、ファイルの異なる部分において異なるレベルのパリティ保護を提供するために、実際のＦＥＣ符号自体が変更される。しかし、この手法には難点が存在する。たとえば、ＵＥＰを提供するためにＦＥＣ符号自体を変更しなければならないことは、それがＦＥＣ符号自体の実施およびテストを複雑化するので、望ましくない。さらに、［ＬＤＰＣ拡張］の図６に示される結果として、ファイルの異なる部分に対して提供されるパケットロスに対する回復力に関する、そのような手法の結果として得られる性能は、最適からはほど遠い。
［ＰＥＴ］および［ＰＥＴ特許］において説明されているようなＵＥＰファイル配送機能を提供するための１つの方法は、ファイルの異なる部分に、それらの優先度およびサイズに従って、各パケットの異なる部分を割り当てることである。しかし、課題は、ファイルの各異なる部分がファイルの他の部分とは独立にソースブロックおよびサブブロックに分割され得るように、そのようなＵＥＰ方法を具体化するにはどうするか、たとえば、ファイルの各部分の少量メモリ復号をサポートし、また同時に、ファイルの各部分のためのどのシンボルが各パケットに含まれるかを受信機が決定することを可能にするＦＥＣペイロードＩＤを各パケット内で提供するにはどうするかである。ファイルの各部分について、ファイルの第１の部分のためのパケット内のシンボルのための対応するＳＢＮおよびＥＳＩは、ファイルの第２の部分のためのパケット内のシンボルのためのＳＢＮおよびＥＳＩと異なることがあるので、（ＳＢＮ，ＥＳＩ）形式のＦＥＣペイロードＩＤを使用して、これをサポートすることは非常に困難である。
場合によっては、専用のサーバが必要とされるが、コンテンツ配送をサポートするためのより一般的な従来のハードウェアシステムを使用して、それを実施し、サポートし、維持するには、より大きいコストがかかり得る。したがって、実施の複雑さがより低い、コンテンツ配送およびシンボル修復のための方法があることが望まれる。
ファイル配送方法および装置の実施形態では、コンテンツを表すソースブロックおよびシンボルはユニキャスト方式で利用可能であり、修復ブロックおよびシンボルはブロードキャストまたはマルチキャスト方式で提供されるように、コンテンツがファイル配送システムに提供される。他の手段および冗長性も提供することができる。ソースブロックおよびシンボルのユニキャスト提供は、１つのエンティティによって行うことができ、ブロードキャストまたはマルチキャスト部分は、第１のエンティティによって行われる特定の処理を行って、または行わずに、別のエンティティによって提供される。
特定の実施形態では、１組のコンテンツ（データ、画像、オーディオ、ビデオなど）は、一般に、任意のユーザがコンテンツの要求を非同期に行った直後に、そのユーザへの提示を開始し、好ましくは、（ユーザがコンテンツを終了しない限り）コンテンツの終わりまで提示を継続するコンテンツの提示を多数のユーザに対して行うために、それらのユーザによって操作される、またはそれらのユーザのために操作される、多数のエンドユーザデバイス（「ＵＥ」）から利用可能にされる。その実施形態では、コンテンツは、１つまたは複数のユニキャストサーバにおいてソース形式で記憶され、コンテンツのための修復シンボルは、ブロードキャストサーバにおいて生成および記憶され、そこから複数のＵＥにブロードキャストまたはマルチキャストされる。代替として、記憶は行われず、修復シンボルが生成されると直ちに、コンテンツがブロードキャストされる。ＵＥは、その後、ブロードキャストサーバから何らかの数の修復シンボルを受信し、修復シンボルがプロセス中に失われたかどうかを判定し、追加シンボルと受信された修復シンボルからコンテンツを完全に回復するために必要とされる追加シンボルの数を（少なくとも近似的に）決定し、その後、その数のシンボルをユニキャストサーバに要求する。別の代替として、少なくともいくつかのソースシンボルが、ブロードキャストサーバからブロードキャストまたはマルチキャストされ、ＵＥが再生しようとするコンテンツの部分を完全に回復するために必要とされる追加シンボルの数を（少なくとも近似的に）決定し、その後、修復サブシンボルまたは修復シンボルとすることができる、その数のシンボルまたはサブシンボルをユニキャストサーバに要求する。
場合によっては、ユニキャストサーバへの要求は、ＨＴＴＰバイト範囲要求の形式を取る。ＨＴＴＰバイト範囲要求が、ファイルのＵＲＬ、ファイル内の開始位置、および（要求されたシンボルの数）、もしくは要求されたサブシンボルの数、または連続する１組のサブシンボルもしくはシンボルに対応するバイト範囲要求などの）要求の長さを指定する場合、要求は、要求のすべてまたは多くがファイルの初期位置を開始位置として使用するようなものとすることができる。ダウンストリームキャッシュが特定のファイルに関する最大の要求をキャッシュした後は、すべてのより小さい要求はそのキャッシュされたバイト範囲のサブセットであり、提供する必要があるすべてのデータを有するので、これは、ダウンストリームキャッシュがより頻繁に要求を満たすことを可能にする。
特定の実施形態では、ユニキャストサーバは、バイト範囲要求を処理することが可能な、単純な従来のＨＴＴＰウェブサーバである。そのため、それらのユニキャストサーバは、実行されているどの特定のブロードキャストについても知らないように設計することができる。
以下の詳細な説明は、添付の図面と一緒に、本発明の特徴および利点についてのより良い理解を提供する。
図１は、従来のＦＥＣペイロードＩＤを示す図であり、図１Ａは、Ｒａｐｔｏｒ−ＲＦＣ ５０５３のためのＦＥＣペイロードＩＤを示す図。 図１は、従来のＦＥＣペイロードＩＤを示す図であり、図１Ｂは、ＲａｐｔｏｒＱ−ＲＦＣ−６３３０のためのＦＥＣペイロードＩＤを示す図。 基本的な汎用ファイル配送（「ＵＦＤ」）方法のためのＦＥＣペイロードＩＤを示すブロック図。 送信機側の基本的ＵＦＤ方法を説明するフローチャート。 受信機側の基本的ＵＦＤ方法を説明するフローチャート。 ファイルのシンボルの（ＳＢＮ，ＥＳＩ）識別情報、およびファイルのシンボルの対応する汎用ファイルシンボル識別子（「ＵＦＳＩ」）との間のマッピングを示す例の図。 ファイルのシンボルの（ＳＢＮ，ＥＳＩ）識別情報、およびファイルのシンボルの対応する汎用ファイルシンボル識別子（「ＵＦＳＩ」）との間のマッピングを示す例の図。 送信機側の汎用ファイル配送、不均一誤り保護（「ＵＦＤ ＵＥＰ」）方法を説明するフローチャート。 受信機側のＵＦＤ ＵＥＰ方法を説明するフローチャート。 各々が異なる優先度を有する２つの部分を備えるファイルの（ＳＢＮ，ＥＳＩ）識別情報の一例を示す図。 各々が異なる優先度を有する２つの部分を備えるファイルの（ＳＢＮ，ＥＳＩ）識別情報の一例を示す図。 図８Ａおよび図８Ｂに対応する、ファイルの２つの部分からの符号化シンボルの（ＳＢＮ，ＥＳＩ）識別子と、各パケット内に含まれるＵＦＳＩと一緒に部分のための符号化シンボルを含むパケットとの間のマッピングの一例の図。 ［ＲａｐｔｏｒＱ−ＲＦＣ−６３３０］を使用するシンプルＵＥＰファイル配送方法の性能を示す図。 ともに［ＲａｐｔｏｒＱ−ＲＦＣ−６３３０］を使用する、シンプルＵＥＰファイル配送方法とＵＦＤ ＵＥＰファイル配送方法との間の例示的な性能比較を示す図。 すべてが［ＲａｐｔｏｒＱ−ＲＦＣ−６３３０］を使用する、１ファイルのファイル配送と、複数ファイルのファイル配送と、ＵＦＤバンドル化ファイル配送方法との間の例示的な性能比較を示す図。 ファイル配送の一環として、Ｒａｐｔｏｒ、ＲａｐｔｏｒＱ、または他のパケットを生成し、送信し、受信するために使用できる、通信システムのブロック図。 １つの受信機が複数の通常は独立した送信機から出力シンボルを受信するファイル配送を行うことができる通信システムの図。 １つの受信機および／または１つの送信機しか使用されない場合よりも少ない時間で入力ファイルを受信するために、複数のおそらくは独立した受信機が複数の通常は独立した送信機から出力シンボルを受信するファイル配送を行うことができる通信システムの図。 ＨＴＴＰストリーミングサーバを使用するファイル配送を提供するために使用できるブロック要求ストリーミングシステムの要素を示す図。 ファイル配送のために使用できるような、コンテンツ取込みシステムによって処理されたデータを受信するためにブロックサービングインフラストラクチャ（「ＢＳＩ」）に連結されたクライアントシステムの要素をより詳細に示す、図１６のブロック要求ストリーミングシステムの要素を示す図。 ファイル配送のためのファイルを準備するために使用できる取込みシステムのハードウェア／ソフトウェア実施の図。 クライアントシステムに配送されたファイルを受信するために使用できるクライアントシステムのハードウェア／ソフトウェア実施の図。 共通ＦＥＣ ＯＴＩ要素形式の一例を示す図。 方式固有のＦＥＣ ＯＴＩ要素形式の一例を示す図。 基本的ＦＬＵＴＥファイル配送を示す図。 基本的ＦＬＵＴＥパケット形式を示す図。 サブブロックを使用する送信機において行われるサブブロック符号化を示す図。 サブブロックを使用する受信機において行われるサブブロック復号を示す図。 サブブロックを使用するファイル配送を示す図。 複数のソースブロックの処理を示す図。 ＦＥＣおよびＦＬＵＴＥを使用するワークフローを示す図。 ブロードキャスト／修復、ユニキャスト／ソース構成を示す図。 ＭＢＭＳベアラ上でシステムがどのように修復シンボルのみをブロードキャストするかを示す図。 ＨＴＴＰバイト範囲要求を介するユニキャスト修復の使用を示す図。 第１のソースブロックのためのサブブロック範囲要求計算の一例を示す図。 第２のソースブロックのためのサブブロック範囲要求計算の一例を示す図。 オリジナル順ＨＴＴＰファイル形式および分割構造の一例を示す図。 ＵＯＳＩ順のソースシンボルの一例を示す図。 ＵＯＳＩ順の修復シンボルの一例を示す図。 拡張オリジナル順ＨＴＴＰファイル形式の一例を示す図。 拡張オリジナル順ＨＴＴＰファイル形式の別の例を示す図。 サブブロックを用いないオリジナル順ＨＴＴＰファイル形式のためのバイト範囲計算の一例を示す図。 サブブロックを用いない拡張オリジナル順ＨＴＴＰファイル形式のためのバイト範囲計算の一例を示す図。 サブブロックを用いる拡張オリジナル順ＨＴＴＰファイル形式のためのバイト範囲計算の一例を示す図。
本明細書の実施形態では、ファイル配送は、ファイルを送信する符号化器／送信機システム、およびファイルを受信する受信機／復号器システムによって実行される。送信の形式は、符号化器が符号化したものを復号器が理解するように調整される。以下の様々な例に示されるように、ファイル配送は、一般的なオブジェクト配送の一例であり、別段の指摘がない限り、オブジェクトはファイルとして扱うことができ、その逆も可能であることが、これらの例から明らかである。
パケット配送システムでは、データは、パケットに組織され、パケットとして送信される。各パケットは、パケット内に何が存在し、それがどのようにレイアウトされているのかを、受信機が決定することを可能にする要素を有する。本明細書で説明される技法を使用することで、前方誤り訂正（「ＦＥＣ」）が使用されるパケット送信に柔軟性が提供される。
これらの技法を使用することで、ファイルのバンドル化配送ばかりでなく、不均一ＦＥＣ保護も提供することができる。多くのファイルが別々のファイルとして配送される場合、パケットロスに対する配送の回復力は、すべてのファイルが一緒により大きいファイルとして連結され、配送においてより大きいファイルが保護される場合よりも、はるかに低くなり得ることがよく知られている。しかし、より小さいファイルの組合せとしてのより大きいファイルの構造の伝達が必要とされ、受信機は、より小さいファイルのサブセットを回復することにしか関心がないとしても、大きいファイル内のより小さいファイルのいずれかを回復するために、完全な大きいファイルを回復することを一般には必要とする。
したがって、好ましいファイル配送システムまたは方法は、ファイルのためのファイル配送構造として使用される、ソースブロックの数およびソースブロック当たりの符号化シンボルの数の任意の柔軟な組合せを可能にすべきである。典型的な実施では、ソースブロックが、修復シンボルの生成などのＦＥＣ操作の範囲である。たとえば、修復シンボルは、１つのソースブロックにすべてが属する１つまたは複数のソースシンボルの関数として生成することができる。そのような場合、各ソースブロックは、独立に復号可能とすることができる。このようにすると、データのすべてが受信される前に、配送されているいくつかのデータを復号器が復号および処理する必要がある場合に、復号器において有益である。本開示から明らかなように、ソースブロックが非常に小さい場合、受信された修復シンボルは、より少数のソースシンボルの回復のために使用可能であるが、ソースブロックが非常に大きい場合、より大きいソースブロックを復号するには、より長い時間を要するので、受信機がソースブロック内のソースシンボルのいずれかを復号および／または処理および／または使用するには、より多くの時間を要することがある。
ファイル配送方法は、パケットロスに対する効率的な保護を提供すべきであり、ファイルの異なる部分が異なる優先度で保護されるファイルの配送をサポートすべきであり、ファイルの各部分は、ファイルの他の部分とは異なるソースブロック構造およびサブブロック構造を有することができる。やはり、ファイルは、場合によっては、オブジェクトの特定の例と考えられるが、本明細書では、ファイルの転送および処理について説明するために本明細書で使用される例は、データベースからのデータの大きいかたまり、ビデオシーケンスの一部など、おそらくはファイルとは呼ばれないデータオブジェクトに対しても使用できることを理解されたい。
ファイル／オブジェクト配送システムまたは方法は、大きいファイル／オブジェクトの保護効率を有する多くのより小さいファイル／オブジェクトの配送、より小さいファイル／オブジェクト構造の単純な伝達、および受信機が、より小さいファイル／オブジェクトのすべてを回復せずに、より小さいファイル／オブジェクトのサブセットのみを独立に回復するための機能を提供すべきである。
ファイル配送システムは、ブロードキャスト部分と、ユニキャスト部分とを備えることができる。読みやすくするため、「ブロードキャスト」は、「共通のデータを複数のユーザに提供するためのブロードキャスト、マルチキャスト、および／または他のメカニズム」の意味で読むことができる。「ユニキャスト」は、１つの送信元から１つの送信先へのデータの移動のことを指すが、１つの論理送信元は、複数の構成要素を備えることができ、１つの論理送信先は、複数の構成要素を備えることができる。ユニキャスト構成では、一般に、送信元サーバと送信先サーバが存在し、送信元サーバは、クライアントからの要求を待ち、特に要求されたデータを（別途許可されている場合は）要求クライアントに送信することによって、受信された要求に応答する。当技術分野においてよく知られているように、多数の送信先へのユニキャスト配送は、それらの同じ多数の送信先へのブロードキャスト配送よりも多くのスケーラビリティ上の課題をもたらし得る。一般に、ＨＴＴＰ配送の場合、切断（ｓｅｖｅｒ）配送スケーラビリティを高めるために、多くのキャッシングサーバが、ネットワーク全域に配備される。しかし、そのような手法は、必ずしもネットワーク容量を増やすとは限らず、それは、モバイルデバイスへのコンテンツの配送に関する一般的なボトルネックである。
これらの望ましい特質を有するシステムの例が今から説明される。
基本的な汎用ファイル配送（ｕｎｉｖｅｒｓａｌ ｆｉｌｅ ｄｅｌｉｖｅｒｙ）（「ＵＦＤ」）方法およびシステム
基本的な汎用ファイル配送（「ＵＦＤ」）方法および対応するシステム（複数可）が今から説明され、ＵＦＤは、既存のファイル配送方法にまさる著しい利点を含む。基本的ＵＦＤ方法のための前方誤り訂正（「ＦＥＣ」）ペイロードＩＤは、たとえば、３２ビットフィールドとすることができる、汎用ファイルシンボル識別子（ｕｎｉｖｅｒｓａｌ ｆｉｌｅ ｓｙｍｂｏｌ ｉｄｅｎｔｉｆｉｅｒ）（「ＵＦＳＩ」）フィールドを備える。今度は、基本的ＵＦＤ方法のための送信機方法および受信機方法が今から説明される。やはり、ファイルがオブジェクトと呼ばれる場合、「ＵＦＳＩ」は、代わりに、「ＵＯＳＩ」（汎用オブジェクトシンボル識別子（ｕｎｉｖｅｒｓａｌ ｏｂｊｅｃｔ ｓｙｍｂｏｌ ｉｄｅｎｔｉｆｉｅｒ））と呼ばれることがある。
図１は、従来のＦＥＣペイロードＩＤを示す図であり、図１Ａは、Ｒａｐｔｏｒ−ＲＦＣ ５０５３のためのＦＥＣペイロードＩＤを図示し、一方、図１Ｂは、ＲａｐｔｏｒＱ−ＲＦＣ−６３３０のためのＦＥＣペイロードＩＤを図示する。
図２は、基本的な汎用ファイル配送（「ＵＦＤ」）方法のためのＦＥＣペイロードＩＤを示す図である。後者の手法は、より柔軟とすることができる。
図３は、送信機側の基本的ＵＦＤ方法を示している。送信機は、たとえば、［Ｒａｐｔｏｒ ＲＦＣ ５０５３］または［ＲａｐｔｏｒＱ−ＲＦＣ−６３３０］で説明されているように、ＦＥＣオブジェクト送信情報（「ＯＴＩ」）を生成するために、既存の方法を使用することができ（たとえば、［ＲａｐｔｏｒＱ−ＲＦＣ−６３３０］のセクション４．３を参照）、ファイルを送信するために使用されるソースブロックおよびサブブロック構造を決定するために、また（ＳＢＮ，ＥＳＩ）ペアとファイルの符号化シンボルとの間の関係を決定するために、ＦＥＣ ＯＴＩを使用することができる（たとえば、［ＲａｐｔｏｒＱ−ＲＦＣ−６３３０］のセクション４．４を参照）。
たとえば、［ＲａｐｔｏｒＱ−ＲＦＣ−６３３０］で説明されているように、生成されたＦＥＣ ＯＴＩは、（Ｆ，Ａｌ，Ｔ，Ｚ，Ｎ）とすることができ、ここで、Ｆは、送信されるファイルのサイズであり、Ａｌは、サブシンボルがＡｌの倍数であるメモリ境界上に整列していることを確認するために使用されるアライメントファクタであり、Ｔは、生成され、送信中に送信されるシンボルのサイズであり、Ｚは、送信のためにファイルが分割されるソースブロックの数であり、Ｎは、送信のために各ソースブロックが分割されるサブブロックの数である。これは、図３のステップ３００に示される通りである。
送信機は、パケットで送信される符号化シンボルを形成し、たとえば、［ＲａｐｔｏｒＱ−ＲＦＣ−６３３０］で説明されているように、これらの符号化シンボルのためのＳＢＮおよびＥＳＩを、ソースブロックに基づいて、またサブブロックが使用される場合は、サブブロック構造にも基づいて、既存の方法を使用して生成することができる。符号化シンボルを送信しようとするたびに、送信機は、図３のステップ３１０に示されるように、生成される符号化シンボルのために、ＳＢＮ ＡおよびＥＳＩ Ｂを決定することができ、次いで、送信機は、図３のステップ３２０に示されるように、たとえば、［ＲａｐｔｏｒＱ−ＲＦＣ−６３３０］で説明されている既存の技法を使用して、（ＳＢＮ，ＥＳＩ）＝（Ａ，Ｂ）に基づいて、符号化シンボルの値を生成することができる。次いで、図３のステップ３３０に示されるように、その符号化シンボルのためのＵＦＳＩ Ｃが、Ｃ＝Ｂ×Ｚ＋Ａと計算される。
送信機は、図３のステップ３４０に示されるように、パケットで符号化シンボルを送信することができ、パケットのＦＥＣペイロードＩＤは、符号化シンボルのＵＦＳＩ Ｃになるように設定される。送信機は、次いで、図３のステップ３５０に示されるように、ほかにも送信すべき符号化シンボルがあるかどうかを判定することができ、ある場合、送信機は、「はい」分岐によって示されるように、図３のステップ３１０に戻って、送信する追加の符号化シンボルを生成することができ、ない場合、送信機は、「いいえ」分岐によって示されるように、図３のステップ３６０に進んで、終了することができる。
送信機側の基本的ＵＦＤ方法には、多くの変形が存在する。たとえば、送信機は、パケットの少なくともいくつかで、２つ以上の符号化シンボルを送信することができ、その場合、ＦＥＣペイロードＩＤは、パケット内に含まれる第１の符号化シンボルのＵＦＳＩになるように設定することができ、パケット内に含まれる追加のシンボルは、それらの対応するＵＦＳＩが連続するように選択することができる。たとえば、パケットで搬送する符号化シンボルが３つ存在し、第１のそのようなシンボルがＵＦＳＩ＝４２３４を有する場合、他の２つの符号化シンボルは、ＵＦＳＩがそれぞれ４２３５および４２３６であるような符号化シンボルとすることができる。他の代替の例として、送信機は、符号化シンボルのいずれかを生成する前に、符号化シンボルをいくつ生成すべきかを事前決定し、生成されるすべての符号化シンボルのための（ＳＢＮ，ＥＳＩ）値を決定することができる。別の例として、ＵＦＳＩ値は、（ＳＢＮ，ＥＳＩ）値を生成する中間ステップを踏まずに、直接的に生成することができる。
変形の別の例として、他の形式のＦＥＣ ＯＴＩ情報を生成することができる。たとえば、ファイルのためのＦＥＣ ＯＴＩ内に、ベースＵＦＳＩ（ｂａｓｅ ＵＦＳＩ）ＢＵを含むことができ、これは、次のように使用することができ、すなわち、パケット内に含まれる符号化シンボルのためにＦＥＣ送信機および受信機によって使用されるＵＦＳＩは、Ｕ＋ＢＵとされ、ここで、Ｕは、符号化シンボルを搬送するパケット内で搬送されるＵＦＳＩである。したがって、たとえば、パケットが、Ｕ＝１０４５を搬送し、ＦＥＣ ＯＴＩ内のベースＵＦＳＩが、ＢＵ＝２００００００である場合、符号化シンボルのＵＦＳＩは、２００１０４５である。ベースＵＦＳＩの使用には、いくつかの利点がある。１つは、［ＦＬＵＴＥ］、［ＡＬＣ］、［ＬＣＴ］、［ＦＥＣ ＢＢ］で説明されているプロトコルスイートが、ＴＯＩとも呼ばれる送信オブジェクト識別子（ｔｒａｎｓｍｉｓｓｉｏｎ ｏｂｊｅｃｔ ｉｄｅｎｔｉｆｉｅｒ）を、転送されるファイルまたはオブジェクトのＦＥＣ ＯＴＩに関連付ける。同じファイルのための符号化シンボルを、異なる時間に、または異なるセッションで送信することが、および異なるＴＯＩに関連付けることが可能である。また、各異なるＴＯＩに関連付けられたパケットごとに、ＵＦＳＩ＝０で開始する符号化パケットを送信できることも有利である。ＦＥＣ ＯＴＩの一部としてベースＵＦＳＩを指定する能力を有することによって、異なるベースＵＦＳＩを各ＴＯＩに関連付けることができ、異なるＴＯＩにおいて重複する符号化シンボルを送信することなく、ファイルのための符号化シンボルが送信される。たとえば、同じファイルのための符号化シンボルは、ＴＯＩ＝１に関連付けられたパケットと、ＴＯＩ＝２に関連付けられたパケットとで送信することができ、ＴＯＩ＝１に関連付けられたベースＵＦＳＩは、０に設定され、ＴＯＩ＝２に関連付けられたベースＵＦＳＩは、１００００００に設定される。その場合、ＴＯＩ＝１およびＴＯＩ＝２に関する符号化パケットはともに、０、１、２などのＵＦＳＩの系列を含むことができ、ＴＯＩ＝１を有するファイルについて、１００００００個未満の符号化シンボルが送信される限り、２つのＴＯＩに関連付けられて送信される符号化シンボルの間で、重複する符号化シンボルが送信されることはない。
受信機側の基本的ＵＦＤ方法が図４を参照して説明される。受信機は、図４のステップ４００に示されるように、送信機に関して上で説明されたのと同じ形式で、ＦＥＣ ＯＴＩ（Ｆ，Ａｌ，Ｔ，Ｚ，Ｎ）を決定するために、既存の技法を使用することができる。たとえば、ＦＥＣ ＯＴＩは、ＦＬＵＴＥセッション記述内に埋め込むことができ、またはＦＥＣ ＯＴＩは、ＵＲＬ内に符号化することができ、またはＦＥＣ ＯＴＩは、ＳＤＰメッセージを介して獲得することができる。ステップ４１０において、受信機は、ほかにも符号化シンボルが受信されたかどうかを調べ、別の符号化シンボルを受信するまで、またはさらなる符号化シンボルは受信されないと決定するまで、このステップに留まることができ、別の符号化シンボルを受信した場合、受信機は、ステップ４３０に進み、あるいはさらなる符号化シンボルは受信されないと決定した場合、受信機は、ステップ４２０に進み、他の手段を使用して、たとえば、ファイル修復サーバへのＨＴＴＰ要求を使用して、ファイルを回復しようと試み、または受信機は、後の時間にさらなる符号化シンボルを受信するために別のセッションを待つことができ、もしくは受信機は、ファイルを受信できないと決定することができる。
別の符号化シンボルが利用可能な場合、ステップ４３０において、受信機は、符号化シンボルのＵＦＳＩ Ｃを決定し、符号化シンボルの値を受け取る。ステップ４４０において、受信機は、ソースブロックの数ＺおよびＵＦＳＩ Ｃに基づいて、Ａ＝Ｃ ｍｏｄｕｌｏ Ｚ、Ｂ＝ｆｌｏｏｒ（Ｃ／Ｚ）を計算し、ステップ４５０において、受信機は、符号化シンボルのための（ＳＢＮ，ＥＳＩ）を（Ａ，Ｂ）になるように設定し、ステップ４６０において、受信機は、ファイル回復のために使用される、符号化シンボルの値および（Ａ，Ｂ）を記憶し、ステップ４７０において、受信機は、ファイルを回復するのに十分な符号化シンボルが受信されたかどうかを判定し、十分な符号化シンボルが受信された場合、ステップ４８０に進んで、ファイルを回復し、受信されていない場合、ステップ４１０に進んで、さらなる符号化シンボルを受信する。
受信機側の基本的ＵＦＤ方法には、多くの変形が存在する。たとえば、受信機は、パケットの少なくともいくつかで、２つ以上の符号化シンボルを受信することができ、その場合、ＦＥＣペイロードＩＤは、パケット内に含まれる第１の符号化シンボルのＵＦＳＩになるように設定することができ、パケット内の追加のシンボルは、連続的な対応するＵＦＳＩ値を有することができる。たとえば、パケットで搬送される符号化シンボルが３つ存在し、第１のそのようなシンボルがＵＦＳＩ＝４２３４を有する場合、他の２つの符号化シンボルは、ＵＦＳＩがそれぞれ４２３５および４２３６であるような符号化シンボルとすることができ、パケットで搬送されるＵＦＳＩは、第１の符号化シンボルのＵＦＳＩ＝４２３４とすることができる。他の代替の例として、受信機は、回復を試みる前に、符号化シンボルをいくつ受信すべきかを事前決定することができる。別の例として、受信機は、ファイルを回復するのに十分な符号化シンボルが受信されたかどうかを判定するために使用される、ＦＥＣ符号に固有の何らかの処理を行うことができる。別の例として、ＵＦＳＩ値は、回復プロセスにおいて（ＳＢＮ，ＥＳＩ）値を生成する中間ステップを踏まずに、直接的に使用することができる。別の例として、ファイルの回復は、符号化シンボルの受信と同時に行うことができる。別の例として、他の形式のＦＥＣ ＯＴＩ情報を使用することができる。
基本的ＵＦＤ方法を、ソースブロックおよびサブブロック構造を決定するための［ＲａｐｔｏｒＱ−ＲＦＣ−６３３０］で説明されている技法と組み合わせることで、多くの利点が提供される。たとえば、ファイルを送信する目的でＳＢＮとＥＳＩの組合せによって識別される、先の方法でソースシンボルと呼ばれたものは、基本的ＵＦＤ方法を使用する場合、ＵＦＳＩによって識別されるファイルシンボルと見なすことができる。Ｆは、送信されるファイルのオクテット単位のサイズとされ、Ｔは、ファイルを送信するときにＦＥＣ符号化／復号目的で使用されるシンボルサイズとされ、したがって、ＫＴ＝ｃｅｉｌ（Ｆ／Ｔ）は、ファイル内のシンボルの総数であり、ここで、ｃｅｉｌ（ｘ）は、ｘ以上の整数のうちで最小の整数である。
ソースブロック構造およびサブブロック構造が、たとえば、［ＲａｐｔｏｒＱ−ＲＦＣ−６３３０］で説明されているように決定され、シンボルの識別情報を（ＳＢＮ，ＥＳＩ）形式からＵＦＳＩ形式に、またＵＦＳＩ形式から（ＳＢＮ，ＥＳＩ）形式に変換するために、上で説明された基本的ＵＦＤ方法が使用される場合、ファイルシンボルのためのＵＦＳＩの範囲は、０、１、２、．．．、ＫＴ−１であり、ファイルから生成される修復シンボルはいずれも、ＫＴ、ＫＴ＋１、ＫＴ＋２などの範囲内のＵＦＳＩを有する。この特性は、シンボルが元のファイルの一部であるか、それともファイルから生成された修復シンボルであるかの判定を、単にそのＵＦＳＩをＫＴの値と比較することによって可能にする。これは、たとえば、ＦＥＣ復号をサポートしない受信機が、どのシンボルが元のファイルの一部であるか（およびファイル内のそれらの位置）を決定することを可能にするために、またパケット内で搬送されるＵＦＳＩ値、およびファイルのためのＫＴの値に基づいて、どれを修復シンボルとして無視できるかを決定することを可能にするために有益であり得る。
図５Ａおよび図５Ｂは、一例を図示し、この場合、ファイルサイズは、Ｆ＝２８６６９オクテットであり、シンボルサイズは、Ｔ＝１０２４オクテットであり、したがって、ＫＴ＝ｃｅｉｌ（Ｆ／Ｔ）＝２８である。これら２つの図では、ソースブロックの数は、Ｚ＝５である。図５Ａおよび図５Ｂでは、ファイルのシンボルの（ＳＢＮ，ＥＳＩ）ラベリングが、上および／または横に示されており、各行は、ソースブロックに対応し、各列は、同じＥＳＩ値を有するシンボルに対応する。シンボルの対応するＵＦＳＩラベリングは、下側に示されている。この場合、ＵＦＳＩ＝２７を有するシンボル、すなわち、ＵＦＳＩラベリングに関して第２８のシンボルは、末尾の（ＫＴ×Ｔ）−Ｆ＝３オクテットが、ＦＥＣ符号化および復号の目的で、ゼロでパディングされるが、このシンボルのこれら末尾のパディングされた３オクテットは、送信されないことがある。この例では、ＵＦＳＩが２８以上の符号化シンボルは、いずれも修復シンボルであり、ＵＦＳＩが２８の符号化シンボルは、ＳＢＮ＝３のソースブロックから生成され、ＵＦＳＩが２９の符号化シンボルは、ＳＢＮ＝４のソースブロックから生成され、ＵＦＳＩが３０の符号化シンボルは、ＳＢＮ＝０のソースブロックから生成され、以降も同様である。当業者が理解するように、この特性には、他の多くの利点が存在する。
基本的ＵＦＤ方法の別の利点は、符号化シンボルが、それらのＵＦＳＩによって定められる順序で、すなわち、ＵＦＳＩ順の０、１、２、３、４、．．．で送信される場合、Ｚ個のソースブロックのための符号化シンボルは、インターリーブされた順序で送信され、すなわち、最初に、Ｚ個のソースブロックの各々に属するＥＳＩが０のＺ個の符号化シンボルが送信され、続いて、Ｚ個のソースブロックの各々に属するＥＳＩが１のＺ個の符号化シンボルが送信され、以降も同様なことである。ほとんどの送信において、この単純な送信順序は、十分であり、好ましい。しかし、ソースブロックの数Ｚと同期することがある何らかの周期で、パケットロスが経験される場合、より良い可能性のある送信順序は、Ｚ個のＵＦＳＩが連続する符号化シンボルからなる各組を、それらを送信する前に、ランダムに置換したものであり、すなわち、ＵＦＳＩが０、．．．、Ｚ−１である最初のＺ個の符号化シンボルが、ランダムに置換された順序で送信され、次いで、ＵＦＳＩがＺ、．．．、２×Ｚ−１である次のＺ個の符号化シンボルが、ランダムに置換された順序で送信され、以降も同様である。この説明を通して、別段の指摘がない限り、「ランダム」は疑似ランダムを含むことができることを理解されたい。
基本的ＵＦＤ方法を使用すると、これまで知られていた方法にまさる多くの追加的な利点が提供される。たとえば、所定のサイズのＳＢＮおよびＥＳＩフィールドを備えるＦＥＣペイロードＩＤを使用する場合、可能なソースブロックについて、またはソースブロック当たり可能な符号化シンボルについて、別々の所定の数が存在する。たとえば、３２ビットのＦＥＣペイロードＩＤをもたらす８ビットのＳＢＮおよび２４ビットのＥＳＩは、可能なソースブロックの数を２５６に、またソースブロック当たりの可能な符号化シンボルの数を１６７７７２１６に制限する。代わりに、ＵＦＳＩフィールドを備えるＦＥＣペイロードＩＤは、ファイルのソースブロック構造とは無関係に、ファイル当たりの可能な符号化シンボルの総数を制限するだけである。たとえば、３２ビットのＦＥＣペイロードＩＤをもたらす３２ビットのＵＦＳＩを使用する場合、ファイルがいくつのソースブロックに分割されるかには無関係に、またサブブロックが使用される場合はファイルのサブブロック構造とは無関係に、ファイルのために生成され得る符号化シンボルの総数は、４２９４９６７２９６である。したがって、シンボルが１０２４オクテットのサイズである場合、この例では、ファイルサイズは最大４ＧＢとすることができるが、ファイルが１個のソースブロックに分割されるか、１６３８４個のソースブロックに分割されるか、それとも４１９４３０４個のソースブロックに分割されるかには無関係に、符号化シンボルの数は、ファイルサイズの１０２４倍とすることができる。別の例として、ファイルサイズを２ＴＢとすることができ、符号化シンボルの数は、ファイルサイズの２倍とすることができる。すべての場合で、ファイルのために生成され得る符号化シンボルの数は、サブブロック構造が使用される場合、ファイルのサブブロック構造とは無関係である。
不均一誤り保護ファイル配送サービスのための汎用ファイル配送方法
これまでのほとんどのファイル配送方法は、不均一誤り保護（「ＵＥＰ」）ファイル配送をサポートしない。たとえば、ファイルの異なる部分を符号化するために使用される実際のＦＥＣ符号を変更することによってＵＥＰをサポートする、［ＬＤＰＣ拡張］で説明されている方法を使用する、ＩＳＤＢ Ｔｍｍ（地上モバイルマルチメディア）規格で現在仕様化されている方法など、いくつかの方法がこれまでも存在した。ＵＥＰを使用するときに実際のＦＥＣ符号を変更しなければならない不都合に加えて、さらなる不都合は、これらの方法によって提供される保護が理想からほど遠いことである。
一例として、結果が［ＬＤＰＣ拡張］の図６に示されている方法について考察する。その例では、パケットで送信される、サイズが１０００ＫＢのファイルに対して、２つの部分が存在し、各パケットは、１ＫＢのシンボルを含み、ファイルの第１の部分は、サイズが３０ＫＢであり、１００個のパリティパケットまたは修復パケットによって保護され、ファイルの第２の部分は、９７０ＫＢであり、ファイルのために、全体で１０００個のソースパケットおよび１０００個のパリティパケットが送信される。提供される保護は、２つの問題のせいで、理想からほど遠い。１つの問題は、［ＬＤＰＣ ＲＦＣ ５１７０］に基づいて使用されるＦＥＣ符号は、ソースブロックを回復するために、しばしば著しい受信オーバヘッドを必要とし、すなわち、ファイルを回復するために、ファイル内に存在するソースパケットよりも多くのパケットが受信される必要があることである。第２の問題は、方法が、基本的に、ファイルの第２の部分を送信および保護するために使用されるのとは別個の１組のパケットを使用して、ファイルの第１の部分を送信および保護することである。第２の問題について、ファイルの第１の部分はそのような少量のパケットを介して送信されるので、受信する３０個のパケットとファイルの第１の部分のために送信される１３０個のパケットとの差は大きい。
本明細書で「シンプルＵＥＰ」ファイル配送方法と呼ばれる拡張によって、［ＬＤＰＣ拡張］で説明されているＵＥＰファイル配送方法を改良することができる。シンプルＵＥＰファイル配送方法は、ファイル配送のための既存の技法を使用して、またファイルの各部分の優先度に基づいたファイルの各部分に対する異なる程度の保護を使用して、ファイルの部分を別個のファイル配送として配送し、配送されたファイルが同じファイルの部分であることが受信機にわかるように、ファイルの部分間の論理的な結び付きを伝達することができる。たとえば、シンプルＵＥＰファイル配送方法は、上の例では、第１の部分から生成されたサイズが１０２４オクテットの符号化シンボルを各々が含む、全部で１３０個のパケットを送信することによって、ファイルの第１の３０ＫＢの部分を配送するために、［ＲａｐｔｏｒＱ−ＲＦＣ−６３３０］を使用することができ、次いで、第２の部分から生成されたサイズが１０２４オクテットの符号化シンボルを各々が含む、全部で１８７０個のパケットを送信することによって、ファイルの第２の９７０ＫＢの部分を別個のファイルとして配送することができる。したがって、別個のファイルとして送信されるファイルの２つの部分のために、全部で２０００個のパケットが送信される。シンプルＵＥＰファイル配送方法は、ＦＥＣ符号自体は変更されないので、また本明細書の図１０に示されるように、ファイルの２つの部分の配送の性能は、異なるパケットロス条件下で、［ＬＤＰＣ拡張］の図６に示される性能よりも優れているので、［ＬＤＰＣ拡張］で説明されている方法に対する改良である。
相違の１つの可能な原因は、［ＲａｐｔｏｒＱ−ＲＦＣ−６３３０］で仕様化されたＦＥＣ符号は、［ＬＤＰＣ ＲＦＣ ５１７０］で仕様化されたＦＥＣ符号よりも優れた回復特性を有することにある。しかし、シンプルＵＥＰファイル配送方法は、依然として上で説明された第２の問題を抱えている。
［ＰＥＴ］および［ＰＥＴ特許］は、ＵＥＰファイル配送サービスを提供するための潜在的に改良された方法を提供し、各パケットは、ファイルの各部分の優先度に基づいた、ファイルの各部分からの指定された量の符号化データを含む。［ＰＥＴ］の簡単な具体化は、ファイルの各部分のための適切なサイズの符号化シンボルを各パケット内に含むことであり、次いで、ファイルの各部分のための（ＳＢＮ，ＥＳＩ）ペアを備える別個のＦＥＣペイロードＩＤを含むことである。しかし、この方法は、少なくはあるがいくつかの理由で有利ではない。
たとえば、各部分に対して所定のサイズのＳＢＮおよびＥＳＩフィールドを備えるＦＥＣペイロードＩＤを使用する場合、ファイルの各部分ごとに、可能なソースブロックについて、またはソースブロック当たり可能な符号化シンボルについて、別々の所定の数が存在する。たとえば、ｄ個の部分の各々に対する８ビットのＳＢＮおよび２４ビットのＥＳＩは、部分当たりの可能なソースブロックの数を２５６に、またソースブロック当たりの可能な符号化シンボルの数を１６７７７２１６に制限する、（３２×ｄ）ビットのＦＥＣペイロードＩＤをもたらす。さらに、ｄ個の部分の各々に対するＦＥＣペイロードＩＤサイズが３２ビットである場合、これは、各パケット内のすべての部分のためのＦＥＣペイロードＩＤが合計で３２×ｄビットであることを意味し、たとえば、ｄ＝１０である場合、これは、各パケット内のＦＥＣペイロードＩＤヘッダのみに対して、３２０ビット、または等価的に４０オクテットである。
ファイル配送のための基本ＵＦＤ方法は、これまでのＵＥＰファイル配送方法に著しい利点を提供する、以下で詳細に説明されるような、不均一誤り保護（ＵＥＰ）ファイル配送サービスを提供するために、拡張することができる。本明細書では、これらの拡張された方法は、「ＵＦＤ ＵＥＰ」ファイル配送方法と呼ばれる。これらのＵＦＤ ＵＥＰファイル配送方法は、［ＰＥＴ］および［ＰＥＴ特許］で説明されている方法のいくつかを使用することができる。
例示的なＵＦＤ ＵＥＰファイル配送方法が、今からより詳細に説明される。そのような方法では、送信機は、サイズがＦのファイルを、サイズがＦ0、Ｆ1、．．．、Ｆd-1のｄ個（ｄ＞１）の部分に分割し、したがって、Ｆは、ｉの全範囲にわたるＦiの和に等しい。送信機は、サイズＴのパケットを、サイズがＴ0、Ｔ1、．．．、Ｔd-1のｄ個の部分に分割し、したがって、Ｔは、ｉの全範囲にわたるＴiの和に等しい。Ｔのこの分割は、Ｆ0、Ｆ1、．．．、Ｆd-1と、対応するファイル部分の優先度に基づいている。比Ｆi／Ｔiは、ファイルの部分ｉを１つのソースブロックとして保護するために、理想的なＦＥＣ符号が使用されると仮定して、ファイルの部分ｉを回復するために、いくつのパケットが受信される必要があるかを決定し、したがって、比Ｆi／Ｔiが小さいほど、ファイルの部分ｉの優先度は高い。実際には、たとえば、ＦＥＣ符号は完璧ではなく、いくらかの受信オーバヘッドを示すので、またはファイルのその部分が複数のソースブロックに分割され、いくつかのソースブロックのための符号化シンボルは他のソースブロックのための符号化シンボルよりも高いレートで失われるので、またはＦi／Ｔiが整数でないので、Ｆi／Ｔiよりもわずかに多くのパケットが、ファイルの部分ｉを回復するために必要とされることがある。ＵＥＰの一例として、Ｆ＝１ＭＢ、Ｔ＝１０２４オクテット、ｄ＝２、Ｆ0＝３２ＫＢ、Ｆ1＝Ｆ−Ｆ0＝９９２ＫＢ、およびＴ0＝６４オクテット、Ｔ1＝Ｔ−Ｔ0＝９６０オクテットと仮定する。この例では、Ｆ0／Ｔ0＝５１２であり、したがって、理想的には、５１２個のパケットの受信が、ファイルの部分０の回復を可能にし、一方、Ｆ1／Ｔ1＝１０５８．１３であり、したがって、理想的には、１０５９個のパケットの受信が、ファイルの部分１の回復を可能にする。したがって、この例では、ファイルの部分０は、ファイルの部分１を回復するのに必要とされる数のほぼ半分のパケットから回復することができる。
この例では、ＵＥＰが使用されない、すなわち、ｄ＝１であり、したがって、Ｆ0＝Ｆ＝１ＭＢ、Ｔ0＝Ｔ＝１０２４オクテットである場合、Ｆ0／Ｔ0＝１０２４個のパケットが、ファイルを回復するために必要とされることに留意されたい。したがって、先の段落において説明されたＵＥＰ例では、ファイルの部分１の回復は、ファイルの部分０のより高い優先度が原因で、ＵＥＰが使用されない場合よりもわずかに多くのパケットを必要とする。この基本的なトレードオフについての分析的研究は、［ＰＥＴ］において見出すことができる。
送信機側のＵＦＤ ＵＥＰ方法が、Ｆ0、Ｆ1、．．．、Ｆd-1と、異なるファイル部分の優先度に基づいて、Ｔの分割Ｔ0、Ｔ1、．．．、Ｔd-1を生成する様々な方法が存在する。Ｆi／Ｔi≒Ｆ／Ｔであるように、Ｔiが選択される場合、ファイルの部分ｉは、平均的な優先度を有すると見なされ、部分ｉの優先度は、Ｆi／Ｔi＜Ｆ／Ｔか、それともＦi／Ｔi＞Ｆ／Ｔかに応じて、それぞれ、相対的により高く、またはより低くなることに留意されたい。
ＦＥＣ ＯＴＩの生成のための送信機側のＵＦＤ ＵＥＰ方法が、図６を参照して、今から説明される。ｄ、Ｆ0、Ｆ1、．．．、Ｆd-1、Ｔ0、Ｔ1、．．．、Ｔd-1、Ａｌ、ＷＳの値を与えると、ファイルのｄ個の部分の各々に独立して適用されるＦＥＣ ＯＴＩは、既存の方法を使用して、たとえば、［ＲａｐｔｏｒＱ−ＲＦＣ−６３３０］のセクション４．３で説明されている方法を使用して、通常通り計算することができ、すなわち、各ｉ＝０、．．．、ｄ−１について、送信機は、たとえば、［ＲａｐｔｏｒＱ−ＲＦＣ−６３３０］のセクション４．３で説明されている方法を使用して、Ｆiをファイルサイズとし、Ｔiを各パケット内の部分ｉのための情報を搬送するために使用されるシンボルサイズとして、ファイル部分をどのようにソースブロックおよびサブブロックに分割すべきかを決定する、ファイル部分ｉのためのＦＥＣ ＯＴＩを生成することができる。送信機は、したがって、ファイルの他の部分とは無関係に、ファイルの部分ｉのためのＦＥＣ ＯＴＩを生成する。このプロセスは、本明細書の図６のステップ６００に示されている。
送信機は、既存の方法を使用して、たとえば、［ＲａｐｔｏｒＱ−ＲＦＣ−６３３０］のセクション４．４およびセクション５で説明されている方法を使用して、ファイルの部分ｉのソースブロックおよびサブブロックへの分割、ならびにファイルの部分ｉのための符号化シンボルの（ＳＢＮ，ＥＳＩ）とファイルの部分ｉから符号化シンボルが生成される方法との間のマッピングも生成することができる。これらのＵＦＤ ＵＥＰ方法は、ファイルの他の部分とは無関係に、ファイルの部分ｉに適用され、したがって、ファイルの異なる部分は、異なるソースブロックおよびサブブロック構造を有することができ、特に、方法がファイルの各部分に独立して適用されるので、ソースブロック当たり異なる数のソースシンボルが、またファイルの異なる部分では異なる数のソースブロックが存在することができる。
アライメントファクタＡｌは、好ましくは、ファイルの部分のすべてについて同じであり、特に、各部分ｉについて、Ｔiの値がＡｌの倍数であれば好ましい。さらに、たとえば、ＦＥＣ ＯＴＩを導出するために、［ＲａｐｔｏｒＱ−ＲＦＣ−６３３０］のセクション４．５で説明されている方法が使用される場合、ファイルの部分の各々のためのソースブロックおよびサブブロック構造を導出するときに、同じＡｌの値およびＷＳの値が使用されるのならば好ましい。Ａｌについて同じ値を使用することで、受信機においてＡｌの倍数オクテットにアライメントされたメモリ上で復号を行うことができることが保証され、ＷＳについて同じ値を使用することで、受信機のランダムアクセスメモリ（ＲＡＭ）内で復号される必要がある最大ブロックサイズがファイルのすべての部分について同じであることが保証される。しかし、これは、本明細書で説明される方法の要件ではなく、すなわち、方法は、以下でさらに説明されるように、異なるファイルに対して異なるＡｌ値が使用される場合にも変更を施さずに適用される。たとえば、ファイルの優先度がより高い部分を回復するために、よりわずかなメモリを使用することが望ましい場合など、ファイルの異なる部分に対して異なる値のＷＳを使用することがＦＥＣ ＯＴＩを導出するのに好ましい、いくつかの応用が存在する。
異なる部分に対して異なるアライメントファクタを使用することが有利な応用が存在し得る。たとえば、優先度が高い部分は、４オクテットでアライメントされたメモリを有するローエンド受信機と８オクテットでアライメントされたメモリを有するハイエンド受信機の両方によって復号されることがあり、一方、優先度が低い部分は、ハイエンド受信機のみによって復号されることがある。この例では、優先度が高い部分については、ローエンド受信機がこれらの部分を効率的に復号できるように、Ａｌ＝４を使用するのが有利であり得、優先度が低い部分については、Ａｌ＝４を用いるよりもＡｌ＝８を用いるほうが、ハイエンド受信機がこれらの部分をより効率的に復号できるので、Ａｌ＝８を使用するのが有利であり得る。
ファイル部分ｉに固有の、送信機側のＵＦＤ ＵＥＰ方法によって生成される、対応するＦＥＣ ＯＴＩは、Ｆi、Ｔi、Ｚi、Ｎiを備え、Ｚiは、ファイルの部分ｉが分割されるソースブロックの数であり、Ｎiは、ファイルの部分ｉの各ソースブロックが分割されるサブブロックの数である。したがって、送信機側のＵＦＤ ＵＥＰ方法がファイルのために生成するＦＥＣ ＯＴＩ全体は、（ｄ、Ａｌ、Ｆ0、Ｔ0、Ｚ0、Ｎ0、Ｆ1、Ｔ1、Ｚ1、Ｎ1、．．．、Ｆd-1、Ｔd-1、Ｚd-1、Ｎd-1）を備えることができる。たとえば、ｄが固定され、したがって、ＦＥＣ ＯＴＩ内に明示的に載せる必要がない場合、またはソースブロック構造を、また使用される場合はサブブロック構造を示すために、他の方法が使用される場合、ＦＥＣ ＯＴＩの他のバージョンも利用可能である。
ＵＦＤ ＵＥＰ方法を使用する送信機は、パケットで送信されるファイルの各部分に対して１つの符号化シンボルを組み立て、パケットのためのＦＥＣペイロードＩＤは、ＵＦＳＩ値Ｃを備える。パケットが送信されるとき、送信機は、図６のステップ６１０に示されるように、パケットのためのＦＥＣペイロードＩＤとして使用されるＵＦＳＩ値Ｃを決定する。使用されるＵＦＳＩ値は、たとえば、連続的とすること、たとえば、ＵＦＳＩ値０、１、２、３、．．．などとすることができる。与えられたＵＦＳＩ値Ｃについて、ファイルの部分ｉのための、パケット内のパケットの第ｉの部分内に配置される、サイズがＴiの符号化シンボルは、図６のステップ６２０に示されるように、Ａi＝Ｃ ｍｏｄｕｌｏ Ｚi、Ｂi＝ｆｌｏｏｒ（Ｃ／Ｚi）として計算される、ＳＢＮ ＡiおよびＥＳＩ Ｂiを有する。図６のステップ６３０、６４０、６５０に示されるように、ｉ＝０、．．．、ｄ−１について、これらｄ個の符号化シンボルは、パケットのｄ個の部分の各々に対して生成され、次いで、ＵＦＳＩ Ｃと、合計サイズがＴのこれらｄ個の符号化シンボルが、パケットで一緒に送信される。送信機側のＵＦＤ ＵＥＰ方法は、図６のステップ６６０において行われる判断に示されるように、符号化パケットを生成および送信し続ける。
受信機側のＵＦＤ ＵＥＰ方法が、図７を参照して説明される。受信機は、図７のステップ７００において示されるように、送信機に関して上で説明されたのと同じ形式のＦＥＣ ＯＴＩ（ｄ、Ａｌ、Ｆ0、Ｔ0、Ｚ0、Ｎ0、Ｆ1、Ｔ1、Ｚ1、Ｎ1、．．．、Ｆd-1、Ｔd-1、Ｚd-1、Ｎd-1）を決定するために、既存の技法を使用することができる。たとえば、ＦＥＣ ＯＴＩは、ＦＬＵＴＥセッション記述内に埋め込むことができ、またはＦＥＣ ＯＴＩは、ＵＲＬ内に符号化することができ、またはＦＥＣ ＯＴＩは、ＳＤＰメッセージを介して獲得することができる。ステップ７１０において、受信機は、ほかにもパケットが受信されたかどうかを調べ、別のパケットを受信するまで、またはさらなるパケットは受信されないと決定するまで、このステップに留まることができ、別のパケットを受信した場合、受信機は、ステップ７３０に進み、あるいはさらなるパケットは受信されないと決定した場合、受信機は、ステップ７２０に進み、ファイルの十分な部分が回復されたと決定して停止し、もしくは他の手段を使用して、たとえば、ファイル修復サーバへのＨＴＴＰ要求を使用して、追加の部分を回復しようと試み、または受信機は、後の時間にさらなるパケットを受信するために別のセッションを待つことができる。
別のパケットが利用可能である場合、ステップ７３０において、受信機は、受信されたパケットのＵＦＳＩ Ｃを決定し、各ｉ＝０、．．．、ｄ−１について、パケットからサイズがＴiの符号化シンボルを抽出する。ステップ７４０において、各ｉ＝０、．．．、ｄ−１について、受信機は、ソースブロックの数ＺiおよびＵＦＳＩ Ｃに基づいて、Ａi＝Ｃ ｍｏｄｕｌｏ Ｚi、Ｂi＝ｆｌｏｏｒ（Ｃ／Ｚi）を計算し、ステップ７５０において、受信機は、部分ｉの符号化シンボルのための（ＳＢＮ，ＥＳＩ）を（Ａi，Ｂi）になるように設定し、ステップ７６０において、受信機は、ファイルの部分ｉを回復するために使用される、部分ｉの符号化シンボルの値および（Ａi，Ｂi）を記憶する。ステップ７７０において、受信機は、各ｉ＝０、．．．、ｄ−１について、ファイルの部分ｉを回復するのに十分な符号化シンボルが受信されたかどうかを判定し、受信された場合、ステップ７８０に進んで、ファイルの部分ｉを回復し、受信されていない場合、ステップ７１０に進んで、さらなるパケットを受信する。
受信機側のＵＦＤ ＵＥＰ方法には、多くの変形が存在する。たとえば、送信機は、パケットの少なくともいくつかで、ファイルの各部分について、２つ以上の符号化シンボルを送信することができ、したがって、受信機は、２つ以上の符号化シンボルを受信することができ、その場合、ＦＥＣペイロードＩＤは、パケット内に含まれる各部分のための第１の符号化シンボルに対応するＵＦＳＩになるように設定することができ、パケット内の各部分のための追加のシンボルは、連続的な対応するＵＦＳＩ値を有することができる。たとえば、パケットで搬送されるファイルの各部分のための符号化シンボルが３つ存在し、各部分のための第１のシンボルがＵＦＳＩ＝４２３４に対応する場合、各部分のための他の２つの符号化シンボルは、ＵＦＳＩがそれぞれ４２３５および４２３６に対応することができ、パケットで搬送されるＵＦＳＩは、ＵＦＳＩ＝４２３４とすることができる。
他の代替の例として、受信機は、回復を試みる前に、符号化シンボルをいくつ受信すべきかを事前決定することができ、またはセッション中のパケットロス統計を計算し、これに基づいて、ファイルのどの部分の回復を試みるべきかを決定することができる。別の例として、受信機は、ファイルの各部分を回復するのに十分な符号化シンボルが受信されたかどうかを判定するために使用される、ＦＥＣ符号に固有の何らかの処理を行うことができる。別の例として、ＵＦＳＩ値は、各ファイル部分のための回復プロセスにおいて（ＳＢＮ，ＥＳＩ）値を生成する中間ステップを踏まずに、直接的に使用することができる。別の例として、ファイルの部分の回復は、符号化シンボルの受信と同時に行うことができる。
別の例として、他の形式のＦＥＣ ＯＴＩ情報が使用され得る。たとえば、部分ｉのためのＦＥＣ ＯＴＩ内で、ベースＵＦＳＩ ＢＵiを他の部分とは無関係に指定することができ、これは、次のように使用することができ、すなわち、パケット内に含まれる部分ｉのための符号化シンボルのためにＦＥＣ送信機および受信機によって使用されるＵＦＳＩは、Ｕ＋ＢＵIとされ、ここで、Ｕは、符号化シンボルを搬送するパケット内で搬送されるＵＦＳＩである。したがって、たとえば、パケットが、Ｕ＝１０４５を搬送し、部分ｉのためのＦＥＣ ＯＴＩ内のベースＵＦＳＩが、ＢＵi＝２００００００である場合、符号化シンボルのＵＦＳＩは、２００１０４５である。
ベースＵＦＳＩの使用には、いくつかの利点がある。たとえば、（後で説明される理由で）異なる部分のための修復シンボルのみが送信される場合、ＢＵi＝ＫＴiと設定することが有利であり得、ここで、ＫＴiは、部分ｉ内のファイルシンボルの数である。この場合、送信パケットシーケンスにおけるＵＦＳＩのシーケンスは、０、１、２、３などとすることができ、それにもかかわらず、各部分について、その部分から生成された修復シンボルのみがパケットで送信される。
この段落では、ベースＵＦＳＩを使用する別の例示的な利点について説明する。［ＦＬＵＴＥ］、［ＡＬＣ］、［ＬＣＴ］、［ＦＥＣ ＢＢ］で説明されているプロトコルスイートは、ＴＯＩとも呼ばれる送信オブジェクト識別子を、転送されるファイルまたはオブジェクトのＦＥＣ ＯＴＩに関連付ける同じ部分のための符号化シンボルを、異なる時間に、または異なるセッションで送信することが、および異なるＴＯＩに関連付けることが可能である。また、各異なるＴＯＩに関連付けられたパケットごとに、ＵＦＳＩ＝０で開始する符号化パケットを送信できることも有利である。各部分ごとに独立して、ＦＥＣ ＯＴＩの一部としてベースＵＦＳＩを指定する能力を有することによって、各部分のための異なるベースＵＦＳＩを各ＴＯＩに関連付けることができ、異なるＴＯＩにおいて重複する符号化シンボルを送信することなく、ファイルのための符号化シンボルが送信される。たとえば、同じ部分のための符号化シンボルは、ＴＯＩ＝１に関連付けられたパケットと、ＴＯＩ＝２に関連付けられたパケットとで送信することができ、ＴＯＩ＝１に関連付けられた部分のためのベースＵＦＳＩは、０に設定され、ＴＯＩ＝２に関連付けられた同じ部分のためのベースＵＦＳＩは、１００００００に設定される。その場合、ＴＯＩ＝１およびＴＯＩ＝２に関する符号化パケットはともに、０、１、２などのＵＦＳＩの系列を含むことができ、ＴＯＩ＝１を有する部分について、１００００００個未満の符号化シンボルが送信される限り、２つのＴＯＩに関連付けられて送信される符号化シンボルの間で、部分のための重複する符号化シンボルが送信されることはない。各部分ごとに異なるベースＵＦＳＩを指定する代わりに、ＦＥＣ ＯＴＩ内に部分のすべてによって使用されるベースＵＦＳＩを有することが有利なこともあり、それは、これがＦＥＣ ＯＴＩを伝達するのに必要とされるオクテットの数を減らすことができながら、特に、この方法と併せて使用されるＦＥＣ符号が、たとえば、Ｌｕｂｙ Ｉにおいて説明されているような情報付加ＦＥＣ符号である場合は、すべての部分のためのＵＦＳＩの有効範囲を非常に大きくできるので、同時に、ＦＥＣ ＯＴＩ内で各部分のために別個のベースＵＦＳＩを指定する利点の多くを共有するからである。
ＵＦＤ ＵＥＰ方法を、ソースブロックおよびサブブロック構造を決定するための［ＲａｐｔｏｒＱ−ＲＦＣ−６３３０］で説明されている技法と組み合わせることで、多くの利点が提供される。特に、基本的ＵＦＤ方法の利点のすべては、ＵＦＤ ＵＥＰ方法でも保たれる。たとえば、ファイルのＵＥＰ部分の１つを送信する目的で、ＳＢＮとＥＳＩの組合せによって識別された、これまでの方法がソースブロックと呼んだものは、ＵＦＤ ＵＥＰ方法を使用する場合は、ＵＦＳＩによって識別されるその部分のためのファイルシンボルと見なすことができる。ＫＴi＝ｃｅｉｌ（Ｆi／Ｔi）は、ファイルの部分ｉ内のファイルシンボルの総数であることに留意されたい。たとえば、ソースブロック構造およびサブブロック構造が、［ＲａｐｔｏｒＱ−ＲＦＣ−６３３０］で説明されているように、ファイルの各部分のために決定され、ファイルの部分のためのシンボルの識別情報を（ＳＢＮ，ＥＳＩ）形式からＵＦＳＩ形式に、またＵＦＳＩ形式から（ＳＢＮ，ＥＳＩ）形式に変換するために、上で説明されたＵＦＤ ＵＥＰ方法が使用される場合、ファイルシンボルのためのＵＦＳＩの範囲は、０、１、２、．．．、ＫＴi−１であり、ファイルから生成される修復シンボルはいずれも、ＫＴi、ＫＴi＋１、ＫＴi＋２などの範囲内のＵＦＳＩを有する。この特性は、シンボルがファイルの元の部分ｉの一部であるか、それともファイルの部分ｉから生成された修復シンボルであるかの判定を、単にそのＵＦＳＩをＫＴiの値と比較することによって可能にする。これは、たとえば、ＦＥＣ復号をサポートしない受信機が、パケットのどの部分が元のファイルの部分を含むか（およびファイル内のそれらの位置）を決定することを可能にするために、またパケット内で搬送されるＵＦＳＩ値、ならびにファイルの各部分ｉのためのＴiおよびＫＴiの値に基づいて、パケットのどの部分が無視できる修復シンボルを含むかを決定することを可能にするために有益であり得る。
図８Ａおよび図８Ｂは、一例を示しており、このケースでは、ファイルは、２つの部分を備える。第１の部分は、５つのソースブロックに分割され、これらのソースブロックの最初の３つは、各々が６つのソースシンボルを有し、残りの２つのソースブロックは、各々が５つのソースシンボルを有し、これらのシンボルの各々は、たとえば、サイズが４８オクテットであり、したがって、第１の部分は、サイズが２８×４８＝１３４４オクテットである。第２の部分は、４つのソースブロックに分割され、これらのソースブロックの最初の３つは、各々が４つのソースシンボルを有し、残りの１つのソースブロックは、各々が３つのソースシンボルを有し、これらのシンボルの各々は、たとえば、サイズが２５６オクテットであり、したがって、第２の部分は、サイズが１５×２５６＝３８４０オクテットである。
図９は、図８Ａおよび図８Ｂに示されたファイル構造に対する可能なパケット化を示している。この例では、各パケットは、ＵＦＳＩ Ｃを備え、サイズがＴ1＝４８オクテットの第１の符号化シンボルは、図６を参照して先に説明されたように、Ｃに基づいて、図８Ａおよび図８Ｂに示されたファイル構造の第１の部分から生成され、サイズがＴ2＝２５６オクテットの第２の符号化シンボルは、図６を参照して先に説明されたように、Ｃに基づいて、図８Ａおよび図８Ｂに示されたファイル構造の第２の部分から生成される。パケットの影なし部分は、ファイルの対応する部分のソースシンボルを搬送し、影つき部分は、ファイルの対応する部分から生成される修復シンボルを搬送する。この例では、ファイルの第１の部分を回復するのに必要なパケットの最小数は、２８であり、一方、ファイルの第２の部分を回復するのに必要なパケットの最小数は、１５である。
図９は、ＵＦＳＩが０、．．．、２７の２８個のパケットを示しており、したがって、これらのパケット内で搬送されるファイルの第１の部分のための符号化シンボルのすべてが、ソースシンボルである。２８以上のＵＦＳＩ値を用いて生成される追加のパケットはいずれも、ファイルの第１の部分のための修復シンボルを搬送する。
ＵＦＤ ＵＥＰ方法の別の利点は、符号化シンボルが、それらのＵＦＳＩによって定められる順序で、すなわち、ＵＦＳＩ順の０、１、２、３、４、．．．で送信される場合、ファイルの部分ｉのＺi個のソースブロックのための符号化シンボルは、インターリーブされた順序で送信され、すなわち、最初に、Ｚi個のソースブロックの各々からのＥＳＩが０のＺi個の符号化シンボルが送信され、続いて、Ｚi個のソースブロックの各々からのＥＳＩが１のＺi個の符号化シンボルが送信され、以降も同様なことである。この特性は、各部分が独立のソースブロック構造を有する場合であっても、ファイルのすべての部分に当てはまる。ほとんどの送信において、この単純な送信順序は、十分であり、好ましい。しかし、ソースブロックの数Ｚiと同期することがある何らかの周期で、パケットロスが経験される場合、より良い可能性のある送信順序は、Ｚ個のＵＦＳＩが連続する符号化シンボルからなる各組を、それらを送信する前に、ランダムに置換したものであり、ここで、Ｚは、すべてのｉ＝０、．．．、ｄ−１に対するＺiの最大値であり、すなわち、ＵＦＳＩが０、．．．、Ｚ−１である最初のＺ個の符号化シンボルが、ランダムに置換された順序で送信され、次いで、ＵＦＳＩがＺ、．．．、２×Ｚ−１である次のＺ個の符号化シンボルが、ランダムに置換された順序で送信され、以降も同様である。別の可能な送信順序は、送信される符号化シンボルのすべてを、それらを送信する前に、ランダムに置換したものである。
ＵＦＤ ＵＥＰ方法を使用すると、これまでの方法またはこれまでの方法の単純な拡張にまさる多くの追加的な利点が提供される。たとえば、ＵＦＳＩフィールドを備えるＦＥＣペイロードＩＤフィールドを使用するＵＦＤ ＵＥＰ方法では、ファイルの各部分のための可能な符号化シンボルの総数は、ＵＦＳＩフィールドのサイズによって制限されるだけであり、ファイルの各部分のソースブロック構造とは無関係である。さらに、ＵＦＳＩフィールドの使用は、ファイルの各部分のためのまったく異なるソースブロック構造から生成されるシンボルの同時識別を可能にする、汎用的で簡潔なＦＥＣペイロードＩＤを提供する。たとえば、３２ビットのＦＥＣペイロードＩＤをもたらす３２ビットのＵＦＳＩを使用する場合、ファイルの各部分について、ファイルがいくつのソースブロックに分割されるかには無関係に、またサブブロックが使用される場合はファイルのサブブロック構造とは無関係に、ファイルのために生成され得る符号化シンボルの総数は、４２９４９６７２９６である。したがって、ファイルの第１の部分のためのシンボルが２５６オクテットのサイズであり、ファイルの第２の部分のためのシンボルが１０２４オクテットのサイズであるとすると、その場合、この例では、ファイルの第１の部分はサイズが１ＧＢになり、ファイルの第２の部分はサイズが４ＧＢになるが、ファイルが１個のソースブロックに分割されるか、１６３８４個のソースブロックに分割されるか、それとも４１９４３０４個のソースブロックに分割されるかには無関係に、符号化シンボルの数は、各ファイル部分のためのソースシンボルの数の１０２４倍とすることができる。
図１０は、［ＲａｐｔｏｒＱ−ＲＦＣ−６３３０］を使用するシンプルＵＥＰファイル配送方法の性能を図示する。この例では、ＵＥＰファイル配送は、１００個の修復シンボルを用いて保護された３０個のソースパケットと、９００個の修復シンボルを用いて保護された９７０個のソースパケットに対するものである。
図１１は、ＵＦＤ ＵＥＰファイル配送方法が提供する、図１０のシンプルＵＥＰファイル配送方法に対する改善の一例を図示する。この例では、１ＭＢのファイルが、３２ＫＢの第１の部分と、９９２ＫＢの第２の部分とに分割される。どちらの方法でも、［ＲａｐｔｏｒＱ−ＲＦＣ−６３３０］において仕様化されているＦＥＣ符号が使用され、符号化シンボルを搬送するための各パケット内のサイズは、１０２４オクテットであり、合計で２０４８個のパケットが送信される。
図１１に示されるシンプルＵＥＰファイル配送方法の例では、ファイルの第１の部分とファイルの第２の部分は、独立に処理および配送され、どちらの場合も、サイズが１０２４オクテットの正確に１つの符号化シンボルが、各パケットで搬送される。ファイルの第１の部分のためのソースは、３２個のパケットで搬送され、符号化シンボルを含む合計で１２８個のパケットが送信される。ファイルの第２の部分のためのソースは、９９２個のパケットで搬送され、符号化シンボルを含む合計で１９２０個のパケットが送信される。
図１１に示されるＵＦＤ ＵＥＰファイル配送方法の例では、ファイルの第１の部分とファイルの第２の部分は、組合された方法で処理および配送され、すなわち、送信される各パケットは、２つの部分の各々のための符号化シンボルを含み、第１の部分については、符号化シンボルのサイズは６４オクテットであり、第２の部分については、符号化シンボルのサイズは９６０オクテットである。ファイルの第１の部分のためのソースは、５１２個のパケットで搬送され、全部で２０４８個のパケットが、第１の部分のための符号化シンボルを含む。ファイルの第２の部分のためのソースは、１０５９個のパケットで搬送され（ソースの最後のパケット内の符号化シンボルは、９９２オクテットの完全なシンボルサイズになるまでゼロでパディングされた第２の部分のための符号化シンボルである）、全部で２０４８個のパケットが、第２の部分のための符号化シンボルを含む。
図１１に見られるように、パケットロス率の関数である、シンプルＵＥＰファイル配送方法とＵＦＤ ＵＥＰファイル配送方法の回復性能は、ファイルの第２の部分については実際には同じであり、すなわち、どちらの場合も、ファイルの第２の部分は、パケットロス率が４８％に接近するまでは、かなり一貫して回復される。他方、ファイルの第１の部分については、ＵＦＤ ＵＥＰファイル配送方法の回復性能は、シンプルＵＥＰファイル配送方法の回復性能よりも著しく良好であり、シンプルＵＥＰファイル配送方法は、６５％未満のパケットロス率については、ファイルの第１の部分を一貫して回復することができるが、ＵＦＤ ＵＥＰファイル配送方法は、７５％に近いパケットロス率まで、ファイルの第１の部分を一貫して回復することができる。
バンドル化ファイル配送サービスのための汎用ファイル配送方法およびシステム
これまでのほとんどのファイル配送方法は、バンドル化ファイル配送、すなわち、単一のバンドル化ファイルとしての複数のファイルの配送をサポートしない。複数のファイルを配送する単純な方法は、各ファイルを独立に配送することである。しかし、この単純な方法は、いくつかの難点を有する。たとえば、ファイルが小さい場合、提供される保護は理想からほど遠いが、それは、各ファイルのための符号化シンボルを含むパケットの数が小さい場合、パケットロス統計に大きな分散が存在し得るからである。
図１２は、この問題を図示する。図１２では、３２ＫＢのファイル配送の信頼性が、ネットワークにおける配送中のパケットロスのパーセントの関数として示されている。このファイル配送の例では、シンボルのサイズは１０２４であり、ファイルの３２個のソースシンボルが、［ＲａｐｔｏｒＱ−ＲＦＣ−６３３０］において仕様化されているＦＥＣ符号を使用して、６４個の符号化シンボルに符号化され、各符号化シンボルは、別個のパケットで送信される。図１２に見られるように、ファイルの信頼できる配送が達成され得るロスのパーセントは、この分散のせいで、５０％よりもはるかに小さい。
さらに、多くの小さいファイルが独立に符号化および送信される場合、すべてのファイルが高い信頼性で受信されるパケットロスのパーセントは、一段と小さくなる。図１２は、各々が３２ＫＢのサイズである３２個のファイルについて、この挙動を示しており、各ファイルの符号化および送信は、先の段落で説明されたのと同じパラメータを使用して、他のファイルとは無関係に実行される。見られるように、３２個のファイルすべての配送が高い信頼性で達成され得るのは、パケットロスが２５％を下回る場合であり、これは、５０％よりもはるかに小さい。
ＵＦＤ ＵＥＰファイル配送方法は、ＵＦＤバンドル化ファイル配送方法を提供するために、次のように拡張することができる。ＵＦＤバンドル化ファイル配送方法は、ＵＦＤ ＵＥＰファイル配送方法と同じ方法を使用することができるが、同じファイルのｄ個の部分の配送を伝達する代わりに、各部分が別個のファイルであり、ｄ個のファイルがバンドルとして配送されることを代わりに伝達することができる。サイズがそれぞれＦ0、Ｆ1、．．．、Ｆd-1であるファイルのバンドル化配送を提供することを送信機が望んでいると仮定する。送信機側のＵＦＤバンドル化方法は、サイズＴのパケットを、サイズがＴ0、Ｔ1、．．．、Ｔd-1であるｄ個の部分に分割し、したがって、Ｔは、ｉの全範囲にわたるＴiの和に等しい。Ｔのこの分割は、Ｆ0、Ｆ1、．．．、Ｆd-1と、対応するファイルの優先度に基づいている。
比Ｆi／Ｔiは、ファイルの部分ｉを１つのソースブロックとして保護するために、理想的なＦＥＣ符号が使用されると仮定して、ファイルｉを回復するために、いくつのパケットが受信される必要があるかを決定し、したがって、比Ｆi／Ｔiが小さいほど、ファイルの部分ｉの優先度は高くなる。実際には、たとえば、ＦＥＣ符号は完璧ではなく、いくらかの受信オーバヘッドを示すので、またはファイルのその部分が複数のソースブロックに分割され、いくつかのソースブロックのための符号化シンボルは他のソースブロックのための符号化シンボルよりも高いレートで失われるので、またはＦi／Ｔiが整数でないので、Ｆi／Ｔiよりもわずかに多くのパケットが、ファイルの部分ｉを回復するために必要とされることがある。配送されるすべてのファイルの優先度が同じであることが望まれる場合、Ｔiは、Ｆi／Ｔi≒Ｆ／Ｔとなるように設定される。送信機側と受信機側の両方における、ＵＦＤバンドル化ファイル配送方法についての多くの詳細は、ＵＦＤ ＵＥＰファイル配送方法とほぼ同じであり、したがって、省略される。
ＵＦＤバンドル化ファイル配送方法は、バンドル化ファイル配送とＵＥＰファイル配送の両方を同時に提供するように拡張することができ、すなわち、バンドル内の各ファイルの優先度は、異なるように設定することができる。さらに、ＵＦＤバンドル化ファイル配送方法は、適切な伝達を用いて、複数のファイルの優先度付けされた配送とファイルの部分の優先度付けされた配送の両方の配送をサポートすることができる。たとえば、ＵＦＤバンドル化ファイル配送方法を使用して、３つのオブジェクトが符号化され、送信される場合、最初の２つのオブジェクトは、異なる優先度を有する、同じファイルの異なる部分とすることができ、第３のオブジェクトは、また異なる優先度を有する、異なるファイルとすることができる。受信機は、バンドル化ファイルおよび／またはファイル部分のどれを回復することに関心があるかを、多くの要因に基づいて決定することができ、他のファイルまたはファイルの部分とは独立に、それらのファイルまたはファイルの部分のみを回復することができる。当業者が理解するように、本開示を読めば、ＵＦＤバンドル化ファイル配送方法の多くの可能な代替バージョンが存在する。
ＵＦＤバンドル化ファイル配送の単純な一例として、３２個のファイルからなるバンドルが配送され、各ファイルはサイズが３２ＫＢであり、各ファイルが同じ優先度を有すると仮定する。Ｔ＝１０２４オクテットであると仮定する。この場合、各ｉ＝０、．．．、３１に対して、Ｔiの値は、Ｔi＝３２オクテットである。各パケットは、３２個のファイルの各々のための３２オクテットの符号化シンボルと、パケット内の３２個の符号化シンボルを識別するＵＦＳＩとを含む。この例では、３２個の等しいサイズのファイルの各々からのソースシンボルを含む１０２４個のパケットが存在し、これらは、０〜１０２３の範囲のＵＦＳＩを有するパケットである。この例では、１０２４個の追加の修復シンボルが、各ファイルのために生成され、１０２４〜２０４７の範囲内のＵＦＳＩを有する追加の１０２４個のパケットで送信されると仮定する。
図１２は、このＵＦＤバンドル化ファイル配送の例の回復特性を、パケットロスの関数として示している。この例では、ＵＦＤバンドル化ファイル配送方法を使用する場合、５０％に近いパケットロス率に対して、３２個のファイルすべてを高い信頼性で回復することができ、これは、各ファイル別々の符号化および送信を使用する場合に、３２個のファイルすべてについて高い信頼性の配送を可能にする、約２５％のパケットロス率を大きく上回る改善である。
ＵＦＤおよびＵＥＰファイル配送方法は、他の多くの応用を有することができる。たとえば、ＤＡＳＨ形式のコンテンツのセグメントは、３ＧＰＰ ｅＭＢＭＳ規格に従った、マルチキャストまたはブロードキャストネットワークを介して配送することができる。その場合、ＤＡＳＨ形式のコンテンツは、後で再生するために、エンドユーザのモバイルデバイスに配送することができ、ＤＡＳＨ形式のコンテンツの各セグメントは、１Ｍｂｐｓで符号化されたビデオコンテンツの８秒分を備えることができ、すなわち、各セグメントは、サイズが１ＭＢである。
ＤＡＳＨ形式のコンテンツが、最終的にモバイルデバイス上でエンドユーザによって再生される場合、完全な忠実度の、すなわち、ビデオアーチファクトもしくはスキップまたはバッファリングのない、再生が望ましく、エンドユーザは、配送されたコンテンツの部分のみを再生することを望むことができる。たとえば、コンテンツをＤＡＳＨ形式にひとたびフォーマットすれば、再フォーマットを行わずに、様々な転送を介してそれを配送することができる、転送および再生における効率性および柔軟性のため、各セグメントが別個のファイルとして配送されることが望ましい。
ネットワーク効率性のため、各ＤＡＳＨセグメントは、ＦＥＣ保護され、他のセグメントと完全にインターリーブされることが望ましく、好ましくは、パケット内でＵＦＤおよびＵＥＰ配送方法によって提供されるインターリーブを利用することができる。たとえば、配送される１５０個のセグメントが存在し、したがって、配送されるＤＡＳＨコンテンツの全体的なサイズが、１２００秒または等価的に２０分の再生提示時間を備える、１５０ＭＢであると仮定する。コンテンツは、各々が１２００バイトのペイロードを有するパケットで配送されると仮定する。その場合、本明細書で説明されるＵＦＤおよびＵＥＰ配送方法を使用すると、各パケットの８バイトが、１５０個のセグメントの各々に割り当てられ得、すなわち、各パケットは、１５０個のＤＡＳＨセグメントの各々のための８バイトシンボルを搬送する。その場合、パケットロスパターンとは無関係に、各ＤＡＳＨセグメントは、モバイル受信デバイスに約１３１０７２パケットが到着したときに、すなわち、１５０個のセグメントの各々のための１ＭＢのデータが到着したときに、回復することができる。この例では、１５０個のＤＡＳＨセグメントの各々は、他のＤＡＳＨセグメントを復号する必要なしに、受信モバイルデバイスにおいて復号し、任意選択で再生することができる。
本明細書で説明されるＵＦＤおよびＵＥＰファイル配送方法の別の例として、３ＧＰＰ ｅＭＢＭＳ規格に従ったネットワークなど、マルチキャストまたはブロードキャストネットワークを介して配送されるＤＡＳＨ形式コンテンツの配送について考察するが、ＤＡＳＨコンテンツは、ビデオセグメントおよびオーディオセグメントの系列を備え、各ビデオセグメントは、１Ｍｂｐｓで符号化された８秒のビデオコンテンツを備え、すなわち、各ビデオセグメントは、サイズが１ＭＢであり、各オーディオセグメントは、３２Ｋｂｐｓで符号化された８秒の対応するオーディオコンテンツを備え、すなわち、各オーディオセグメントは、サイズが３２ＫＢであり、ビデオセグメントおよび対応するオーディオセグメントは、８秒の提示時間という概して同じ間隔のコンテンツを含む。
この例では、ＤＡＳＨコンテンツは、ストリーミングされ、すなわち、各ビデオセグメントおよび対応するオーディオセグメントは、それらの提示時間の順序で順番に配送される。コンテンツは、各々が１２００バイトのペイロードを有するパケットで配送されると仮定する。その場合、本明細書で説明されるＵＦＤおよびＵＥＰ配送方法を使用すると、各パケットの１１６０バイトをビデオセグメントに割り当てることができ、各パケットの残りの４０バイトを対応するオーディオセグメントに割り当てることができ、すなわち、各パケットは、ビデオセグメントのための１１６０バイトシンボルと、対応するオーディオセグメントのための４０バイトシンボルを搬送する。その場合、パケットロスパターンとは無関係に、ビデオセグメントは、そのセグメントのためのシンボルを含む約９０５パケットの受信から回復することができ、対応するオーディオセグメントは、そのセグメントのためのシンボルを含む約８２０パケットの受信から回復することができる。
したがって、全体では、対応するビデオセグメントおよびオーディオセグメントが存在する８秒の間隔の提示時間に対応するいずれか８２０パケットの受信が、モバイル受信デバイスがオーディオセグメントを回復することを可能にし、追加の８５パケットの受信または合計で９０５パケットの受信が、対応するビデオセグメントの回復も可能にする。この例では、オーディオが、ビデオよりも強固に保護されるが、多くの場合、そのほうが好ましく、それは、たとえば、ビデオ再生のタイミングは、オーディオ再生のタイミングによって指示されるからであり、オーディオとビデオの両方を再生するのに十分なデータが受信されない場合、少なくともオーディオを再生するほうが多くの場合は好ましいからである。
ユニキャスト修復要求のネイティブＨＴＴＰサポートのための方法
ファイルまたはファイル部分は、ファイルまたはファイル部分を記憶するために、および受信機によるファイルまたはファイル部分へのアクセスを可能にするために、標準的なＨＴＴＰウェブキャッシュサーバによって使用され得る、関連するＵＲＬを有する、「ＨＴＴＰファイル」に組織すること、および「ＨＴＴＰファイル」として利用可能にすることができる。ＨＴＴＰファイルとして利用可能にされる、その元の順序のファイルまたはファイル部分は、本明細書では「オリジナル順ＨＴＴＰファイル（Ｏｒｉｇｉｎａｌ−ｏｒｄｅｒ ＨＴＴＰ ｆｉｌｅ）」と呼ばれる。一般に、ユニキャスト修復要求のネイティブＨＴＴＰサポートのための方法は、ＨＴＴＰファイルのソースブロックのシンボルおよびサブシンボルのための修復要求を、ＳＢＮおよびＥＳＩに基づいて、ＨＴＴＰファイル内の標準的なＨＴＴＰ（たとえば、ネイティブＨＴＴＰ／１．１）オクテット範囲要求（指定されたバイト範囲を有するＨＴＴＰ部分ＧＥＴ要求としばしば呼ばれる）に変換する。これは、ＨＴＴＰファイルがどのようにソースブロックおよびソースブロック内のソースシンボルに分割されるかを理解している専門のＨＴＴＰウェブキャッシュサーバを大量に配備する必要がないように、標準的なＨＴＴＰウェブキャッシュサーバが、これらの修復要求にサービスできるようにすることを可能にする。
そのようなシナリオでは、システマティックなＦＥＣ符号が使用される場合、セッションのいくつか、たとえば、ブロードキャスト／マルチキャストセッションにおいて、修復シンボルだけを送信することがしばしば有利であるが、それは、こうすることで、受信機がユニキャスト修復要求でソースシンボルだけを要求することが可能になるからである。これは、ＨＴＴＰファイル、または以下でより詳細に説明されるようなＨＴＴＰファイルの単純な並べ替え変換が、標準的なＨＴＴＰウェブキャッシュサーバとすることができるユニキャスト修復サーバに提供されることのみを要求し、ＨＴＴＰファイルの定義およびＨＴＴＰファイルの分配のロジスティクス（ｌｏｇｉｓｔｉｃｓ）を、これらのロジスティクスはＦＥＣ符号化には無関係であるので、より簡単にするという利点を有する。別の利点は、セッションにおいてソースシンボルが送信されない場合、ソースシンボルのすべては「失われて」いるので、受信機がユニキャスト修復要求でソースシンボルの任意の系列を要求できることであり、これは、ソースシンボルの連続的な系列のための修復要求を可能にするので好ましい。たとえば、完璧な回復特性を有するＦＥＣ符号が使用され、部分のソースブロックが１０００個のソースシンボルを備え、（修復シンボルのいくつかは送信中に失われることがあり、したがって、受信された修復シンボルのＥＳＩのパターンは連続からほど遠いことがある場合でも）７００個の修復シンボルがソースブロックのために受信されると仮定する。その場合、受信機は、ユニキャスト修復要求で、ソースブロックのための最初の３００個の連続的なソースシンボルを要求し、これらのソースシンボルを、ソースブロックを回復するために、７００個の修復シンボルと組み合わせることができる。ソースシンボルがＨＴＴＰファイル内で連続的である場合、３００個すべての連続的なソースシンボルを要求して受信するために、単一のＨＴＴＰオクテット範囲要求を使用することができる。
受信機は、必ずしもプレフィックス要求（すなわち、第１バイトから開始する、ファイルの定められた数のバイトを求める要求）を行う必要はないが、多くの受信デバイスが存在し、ブロードキャストまたはマルチキャストセッションからパケットを受信するときに、異なる受信デバイスによって経験される任意に異なるロスパターンが存在する場合であっても、すべてのＵＥがプレフィックス要求を行うことを必要とすることで、結果として行われるＵＥからの要求が大きくオーバーラップするので、ＨＴＴＰサーバにおけるキャッシング効率を著しく改善する。
説明されたそれらの利益のいくつかに基づいて、上で説明された技法は、ネットワークまたはネットワークデバイスが、修復シンボルのみがブロードキャストされていることを受信機に伝えるのに有利であり得る。この表示が伝達された場合、受信機は、どのソースシンボルを受信しているのかを追跡する必要はなく、受信したシンボルの数を追跡しさえすればよい。たとえば、受信されたシンボルの合計に基づいて、受信機は、次いで、さらにいくつのソースシンボルを修復サーバに要求すべきかを決定することができる。キャッシング効率を改善するために、受信機は、修復シンボルのみがブロードキャストされる旨の表示の知識に基づいて、ソースシンボルの失われた数のプレフィックス要求を行うように構成することができる。
代替として、プレフィックス要求を行うために、別個のシグナリング表示を受信機に与えることができる。別の実施形態では、受信機が失われたソースブロックの異なるサブセットの間で選択を行う柔軟性を有する場合はいつでも、受信機は、最低のシンボルインデックス値を有する失われたソースシンボル（すなわち、ソースブロックまたはサブブロックの先頭に最も近い失われたソースシンボル）を常に選択するように構成することができる。これは、ソースシンボルと修復シンボルの両方がブロードキャストチャネルを介して送信される場合とすることができる。
別の実施形態では、受信デバイスは、受信されたシンボル識別子、ＥＳＩを絶えず監視し、たとえば、ＦＥＣ ＯＴＩに基づいて、または受信パケットで搬送されたＦＥＣペイロードＩＤに基づいて、修復シンボルのみに対応するＥＳＩを受信しているかどうかを判定する。修復シンボルのみに対応するＥＳＩを受信している場合、そのような受信機は、プレフィックス要求を行うことができる。この実施形態では、明示的なシグナリングを使用することなく、受信機は、修復シンボルのみを受信している場合、修復要求でソースブロックおよびサブブロックのプレフィックスを求める要求を送信する。受信デバイスがブロードキャストチャネルから修復シンボルを受信する場合であっても、受信されたシンボルのパターン、および単純な要求を行うことと、ブロードキャストチャネルを介してすでに受信された冗長なデータを受信する可能性との間のトレードオフに応じて、修復要求は、依然として、大部分または全部がプレフィックス要求であることができる。
修復シンボルのみがブロードキャストされることを伝達し、受信機がプレフィックス要求を行うことを伝達する場合に、ＨＴＴＰバイト範囲ファイル修復要求、またはシンボルベースのファイル修復要求が使用されるとき、いくつかの利点が生じる。したがって、これらの方法は、どちらかまたは両方の要求形式をサポートする、受信機およびネットワークに適用することができる。
修復シンボルのみがブロードキャストされることを示す伝達は、（ユニキャストを介して）帯域外で、または（ブロードキャストを介して）帯域内で送信することができる。表示は、所望の粒度レベルに応じて、サービスレベル、セッションレベル、メディアレベルで、またはファイルレベルでさえ適用可能とすることができる。たとえば、伝達は、ユーザサービス記述（「ＵＳＤ」）内に追加することができる。ＵＳＤは、識別されたサービスすべての配送について、修復シンボルのみがブロードキャストされることを示すことができる。伝達は、メディア提示記述（「ＭＰＤ」）内に追加することもでき、ＭＰＤは、どのメディアが修復シンボルのみを使用してブロードキャストされるかを示すことができる。伝達は、それがセッション全体の配送に適用されるのか、それともセッション内のメディア成分の配送に適用されるのかを示すために、セッション記述プロトコル（「ＳＤＰ」）内に追加することができる。伝達は、修復シンボルのブロードキャストがファイルレベルでのみ適用されることを示すために、ファイル記述テーブル（「ＦＤＴ」）内に追加することもできる。
修復データを求めるプレフィックス要求を行うように受信機に要求する伝達は、帯域内転送または帯域外転送を介して配送することもできる。この表示も、所望の粒度レベルに応じて、サービスレベル、セッションレベル、メディアレベルで、またはファイルレベルでさえ適用される行うことができる。
したがって、そのような表示を提供するための様々な方法および装置が存在し、受信機は、そのような通知が受信される場合と、そのような通知が受信されない場合とで、異なる応答を行うようにプログラムおよび／または構成することができる。
要求は、特定の数のバイトまたはシンボルを求めるものとすることができる。場合によっては、受信機は、受信された修復シンボルの数、および受信されるファイルまたはオブジェクト内に含まれることが予想されるソースシンボルの数に基づいて、要求するソースシンボルの数を決定する。他の場合では、受信機は、スケジューリング動作を実行することができ、受信機は、すでに受信された修復シンボルのみを使用して、どのように復号を行うかを決定し、したがって、必要とされるソースシンボルのより具体的な数を述べることができる。たとえば、修復シンボルのいくつかは、他の修復シンボルと重複していることがあり、その場合は、より多くのソースシンボルが必要とされることがある。他の場合には、よりわずかなソースシンボルしか必要とされないことがわかることがある。
受信機は、ＦＥＣ ＯＴＩに基づいて、特定の（ＳＢＮ，ＥＳＩ）ペアに対応するオリジナル順ＨＴＴＰファイルのソースシンボルを求める要求を、ＨＴＴＰオクテット範囲要求に変換することができる。たとえば、ファイルのためのＦＥＣ ＯＴＩが（Ｆ，Ａｌ，Ｔ，Ｚ，Ｎ）であり、要求されるソースシンボルのためのＳＢＮがＡであり、ソースシンボルのためのＥＳＩがＢであると仮定し、簡潔にするために、Ｎ＝１、すなわち、ファイル構造のこの例では、ソースブロックはさらにサブブロックに分割されないと仮定する。その場合、受信機は、（ＫＬ，ＫＳ，ＺＬ，ＺＳ）を決定するために、たとえば、［ＲａｐｔｏｒＱ−ＲＦＣ−６３３０］のセクション４．４で説明されている方法を適用することができ、ここで、最初のＺＬ個のソースブロックは、ＫＬ個のソースシンボルを有し、残りのＺＳ個のソースブロックは、ＫＳ個のソースシンボルを有する。その場合、Ａ、Ｂ、およびシンボルサイズＴに基づいて、受信機は、ファイル内のソースシンボルの開始オクテットインデックスが、式１に示されるようになると決定することができ、ファイル内のソースシンボルの終了オクテットインデックスは、ＥＩ＝ＳＩ＋Ｔ−１である。次いで、受信機は、ソースシンボルを求める標準的なＨＴＴＰオクテット範囲要求を使用して、オクテットＳＩ〜ＥＩを要求することができる。
Figure 2014533045
当業者が理解するように、これらの方法には、多くの拡張および改良が存在する。たとえば、単一のＨＴＴＰオクテット範囲要求は、サブブロックが使用されない場合に、オリジナル順ＨＴＴＰファイルに複数の連続するソースシンボルが要求される場合、行うことができる。別の例として、オリジナル順ＨＴＴＰファイルに加えて、または代わって、ＨＴＴＰウェブキャッシュサーバが、修復シンボルを含むファイルを有することができ、またはオリジナル順ＨＴＴＰファイルは、修復シンボルを含むように、すでに拡張されていることがあり、受信機は、修復シンボルを求めるＨＴＴＰオクテット範囲要求を行うために、本明細書で説明される方法と類似した方法を使用することができる。機能強化の別の例として、これらの方法は、当業者によって理解されるような類似の方法を使用して、サブブロックが使用される場合に対処するように拡張することができる。たとえば、受信機は、（ＴＬ，ＴＳ，ＮＬ，ＮＳ）を決定するために、［ＲａｐｔｏｒＱ−ＲＦＣ−６３３０］のセクション４．４で説明されている方法を使用することができ、ここで、ソースブロックの最初のＮＬ個のサブブロックは、サイズがＴＬ×Ａｌであり、ソースブロックの残りのＮＳ個のサブブロックは、サイズがＴＳ×Ａｌである。その場合、Ａ、Ｂ、およびシンボルサイズＴに基づいて、受信機は、ソースシンボルに対応するファイル内のＮ個のサブシンボルの開始および終了オクテットインデックスを決定し、標準的なＨＴＴＰオクテット範囲要求を使用して、これらのオクテットを求める要求を行うことができる。
別の例として、受信機は、ＦＥＣ ＯＴＩに基づいて、特定のＵＦＳＩに対応するファイルまたはファイル部分のソースシンボルを求める要求を、ＨＴＴＰオクテット範囲要求に変換することができる。
次の方法は、要求されたオクテット範囲要求を受信機に配送するために標準的なＨＴＴＰウェブキャッシングサーバを同時に使用しながら、ＨＴＴＰファイルのシンボルを回復するために受信機によって標準的なＨＴＴＰバイト範囲要求を使用する効率を大きく高めることができる。
説明されるようなＨＴＴＰオクテット範囲要求をサポートするための単純な方法は、オリジナル順ＨＴＴＰファイルを使用することである。この方法は、ＨＴＴＰウェブキャッシュサーバのためのオリジナル順ＨＴＴＰファイルを生成するために、元のファイルまたはファイル部分の変換が必要とされない利点を有するが、各ソースブロックのために連続的なソースシンボルのみが要求される場合であっても、ソースシンボルを要求するために、多くの異なるＨＴＴＰオクテット範囲要求が必要とされることがある。これには少なくとも２つの理由が存在し、すなわち、（１）複数のソースブロックが存在し、各ソースブロックからソースシンボルが失われることがあり、その場合、各ソースブロックのために別個のオクテット範囲要求が必要とされることがあり、（２）ソースブロック当たり複数のサブブロックが存在することがあり、したがって、１つのソースブロックに属する単一のソースシンボルを要求するためであっても、ソースシンボルのためのサブシンボルはオリジナル順ＨＴＴＰファイル内で連続していないことがあるので、ソースシンボルを構成する複数のサブシンボルを求める複数のＨＴＴＰオクテット範囲要求を必要とすることがある。
上で説明されたＨＴＴＰオクテット範囲要求をサポートするための有利な方法は、最初に、元のファイルまたはファイル部分のためのＦＥＣ ＯＴＩに基づいて、本明細書で「ＵＦＳＩ順ＨＴＴＰファイル（ＵＦＳＩ−ｏｒｄｅｒ ＨＴＴＰ ｆｉｌｅ）」と呼ばれる新しい形式に、ファイルまたはファイル部分を再組織する。この方法は、複数のソースブロックおよび／またはソースブロック当たり複数のサブブロックが存在する場合に有益である。ＵＦＳＩ順ＨＴＴＰファイル内のデータの順序は、ＵＦＳＩが０のファイルシンボル、ＵＦＳＩが１のファイルシンボル、ＵＦＳＩが２のファイルシンボル、以下同様といった順序であり、すなわち、ＵＦＳＩ順ＨＴＴＰファイル内のデータの順序は、ＦＥＣ ＯＴＩによって決定されるような、昇順の連続的なＵＦＳＩに従ってファイルシンボルを並べて組織される。ＵＲＬをＵＦＳＩ順ＨＴＴＰファイルに関連付けることができ、そのＵＲＬは、ＨＴＴＰウェブキャッシングサーバに提供することができる。受信機は、その場合、必要に応じて、ＵＦＳＩ順ＨＴＴＰファイルの一部を要求するために、ＨＴＴＰオクテット範囲要求を使用することができる。ＵＦＳＩ順ＨＴＴＰファイルの１つの利点は、受信機がソースブロックの各々からほぼ同じ数の修復シンボルを受け取る場合、元のファイルまたはファイル部分を回復するのに十分なソースシンボルを獲得するために必要とされるＨＴＴＰオクテット範囲要求の数が、最小になり得ることであり、たとえば、各ソースブロックのために正確に同じ数の修復シンボルが受け取られる場合、１つのＨＴＴＰオクテット範囲要求で十分なことがある。たとえば、元のファイルまたはファイル部分のＺ個のソースブロックの各々からサイズがＴの最初のＬ個のソースシンボルを受け取るためには、ＵＦＳＩ順ＨＴＴＰファイルの最初のＬ×Ｔ×Ｚ個の連続するオクテットを求める要求で十分である。Ｚ個のソースシンボルの各々のために１つまたは複数のセッションにおいてＫ−Ｌ個の修復シンボルが受信される場合、またＦＥＣ符号が理想的な回復特性を有する場合、ＨＴＴＰファイルをＦＥＣ復号するためには、ＨＴＴＰオクテット範囲要求から受け取ったＬ×Ｔ×Ｚ個のオクテットで十分であり、この例では、Ｋは、Ｚ個のソースブロックの各々におけるソースシンボルの数であると仮定される。
上で説明されたＨＴＴＰオクテット範囲要求をサポートするための別の有利な方法は、最初に、元のファイルまたはファイル部分のためのＦＥＣ ＯＴＩに基づいて、本明細書で「ＳＳ順ＨＴＴＰファイル（ＳＳ−ｏｒｄｅｒ ＨＴＴＰ ｆｉｌｅ）」と呼ばれる異なる新しい形式に、ファイルまたはファイル部分を再組織する。この方法は、ソースブロック当たり複数のサブブロックが存在する場合に有益であり、それは、この場合は、各ソースシンボルが、元のファイルまたはファイル部分の連続的な部分ではないことがあり、すなわち、ソースシンボルのサブシンボルは、元のファイルの順序ではソースブロック全体に散らばることができるからである。ＳＳ順ＨＴＴＰファイル内のデータの順序は、第１のソースブロックのすべてのソースシンボル、次に第２のソースブロックのすべてのソースシンボル、次に第３のソースブロックのすべてのソースシンボル、以下同様といった順序であり、すなわち、ＳＳ順ＨＴＴＰファイル内のデータの順序は、ＦＥＣ ＯＴＩによって決定されるような、昇順の連続的なＥＳＩ順に従ってソースブロック内でソースシンボルを並べ、昇順の連続的なＳＢＮ順に従ってソースブロックを連結して組織される。ＵＲＬをＳＳ順ＨＴＴＰファイルに関連付けることができ、そのＵＲＬは、ＨＴＴＰウェブキャッシングサーバに提供することができる。受信機は、その場合、必要に応じて、ＳＳ順ＨＴＴＰファイルの一部を要求するために、ＨＴＴＰオクテット範囲要求を使用することができる。ＳＳ順ＨＴＴＰファイルは、受信機がソースブロックの各々から異なる数の修復シンボルを受け取る場合、特に有利である。たとえば、２つのソースブロックが存在し、各々が１０００個のソースシンボルからなる場合、また受信機が、１つまたは複数のセッションから、第１のソースブロックのための９００個の修復シンボルと、第２のソースブロックのための１００個の修復シンボルとを受け取る場合、受信機は、ＳＳ順ＨＴＴＰファイルの最初のＴ×１００個のオクテットを求める１つの要求を行い、第１のソースブロックのための１００個のソースシンボルを受信することができ、受信機は、ＳＳ順ＨＴＴＰファイルのＴ×１０００〜Ｔ×１９００−１のオクテットを求める別の要求を行い、第２のソースブロックのための９００個のソースシンボルを受信することができ、この例では、Ｔは、両方のソースブロックのためのオクテット単位のシンボルサイズである。
今説明された両方の方法の組合せを使用することもでき、すなわち、ＵＦＳＩ順ＨＴＴＰファイルとＳＳ順ＨＴＴＰファイルの両方は、異なるＵＲＬを通して受信機から利用可能にすることができ、その場合、受信機は、２つの異なる形式のＨＴＴＰファイルへのＨＴＴＰオクテット要求の組合せを使用することができる。たとえば、１０個のソースブロックが存在し、各々が１０００個のソースシンボルを有する場合、また１つまたは複数のセッションにおいて、最初の８個のソースブロックの各々のための８００個の修復シンボルが受信され、第９のソースブロックのための８２０個の修復シンボルが受信され、第１０のソースブロックのための５００個の修復シンボルが受信される場合、受信機は、１０個のソースブロックの各々のための２００個のソースシンボルを受信するために、ＵＦＳＩ順ＨＴＴＰファイルへのＨＴＴＰオクテット範囲要求を行うことができ、第１０のソースブロックのための追加の３００個のソースシンボルを受信するために、ＳＳ順ＨＴＴＰファイルへの追加のＨＴＴＰオクテット範囲要求を行うことができる。この例では、受信機は、（理想的な回復特性を有するＦＥＣ符号を仮定した場合）第９のソースブロックのための不必要な２０個のソースシンボルを受信することがあるが、場合によっては、よりわずかな数のＨＴＴＰオクテット範囲要求を使用する、いくつかのソースブロックのための最低限必要とされるよりも多くのオクテットの要求を行うほうが、はるかに多くの数の異なるＨＴＴＰオクテット範囲要求を必要とすることがある、各ソースブロックのための正確に必要とされる数のソースシンボルの要求を行うよりも効率的なことがある。
ファイルを修復するために、このＨＴＴＰバイト範囲要求が受信機によって使用できる場合、そのことを伝えることは有利であり得る。これは、ファイル修復のために現在は他の要求メッセージを使用している配備されたネットワークに、この特徴を徐々に導入していくことを可能にする。従来のＨＴＴＰベースのファイル修復サーバにネットワーク動作を移行することを計画しているシステム運営者は、自らのネットワーク全体またはローミングパートナネットワークにおいて特徴が十分にサポートされる前に、ＨＴＴＰバイト範囲要求を行うことが可能な受信機の配備から開始することができる。次いで、配備されたＨＴＴＰ対応の受信機の数が増加するにつれて、運営者は、これらの端末からの推定される要求負荷に見合ったＨＴＴＰサーバの配備を開始することができる。特定のネットワークにおいて、受信機がそのネットワーク内でＨＴＴＰバイト範囲要求を使用できることを受信機に示すために、伝達を使用することができる。
ＨＴＴＰバイト範囲要求のネットワークサポートを伝えるための別の手法は、サーバがＨＴＴＰバイト範囲要求のみをサポートすることを示す（たとえば、サーバＵＲＩに「ｂｙｔｅＲａｎｇｅＳｅｒｖｉｃｅＵＲＩ」タイプオブジェクトというタグを付ける）、ディスクリプタを修復サーバＵＲＬとともに提供することである。この方法は、一般に「ｓｅｒｖｉｃｅＵＲＩ」ディスクリプタによって識別される、シンボルベースの要求のみを受け入れるすでに配備された修復サーバを有する、ネットワークにおいて有益である。新しい「ｂｙｔｅＲａｎｇｅＳｅｒｖｉｃｅＵＲＩ」の定義は、このディスクリプタを認識しないレガシ受信機が、これらのＨＴＴＰサーバに誤ってシンボルベースの要求を行うことを防止しながら、新しい受信機が、これらのサーバとともにバイト範囲要求を使用することを可能にする。
ＨＴＴＰバイト範囲要求のネットワークサポートを伝えるための別の実施形態は、サーバがＨＴＴＰバイト範囲要求のみをサポートするのか、それともＨＴＴＰバイト範囲要求とシンボルベースの要求などの他の要求形式とをサポートするのかを示す、ディスクリプタを修復サーバＵＲＬとともに提供することである。別の実施形態では、ディスクリプタは、３つの可能性、すなわち、（１）修復サーバはＨＴＴＰバイト範囲要求のみをサポートするのかどうか、（２）修復サーバは別のタイプの要求形式（たとえば、シンボルベース）のみをサポートするのかどうか、それとも（３）修復サーバはＨＴＴＰバイト範囲要求と他の要求形式をサポートするのかどうかのうちの１つを示す。ディスクリプタは、受信機によってサポートされる場合、要求形式のどれが好ましいか、または要求形式のどれを使用する必要があるかも示すことができる。サーバによってサポートされる要求形式のディスクリプタは、修復サーバＵＲＩのリストとともに送信することができる。
たとえば、インターネット上のロケーションなど、ファイルが保存されているコンテンツサーバから直接的にファイルの部分またはファイルのすべてを取り出すために、受信機がＨＴＴＰバイト範囲要求を使用できることを示す、別のディスクリプタ（たとえば、「ｕｓｅＦｉｌｅＵＲＩ」要素）も、受信機に送信することができる。これは、（モバイルネットワーク運営者など）ネットワーク運営者が、修復手順のためのソースデータを提供するために、専用ファイル修復サーバを配備する必要がなく、代わりに、ファイルのコンテンツサーバに依存できる、アーキテクチャを可能にする。ファイルがブロードキャストチャネルを介してダウンロードされる場合、ファイルは、ファイルのＵＲＩ、たとえば、ｗｗｗ．＜ｎｅｗｓ ｐｒｏｖｉｄｅｒｓｉｔｅ＞．ｃｏｍ／ｌａｔｅｓｔ＿ｎｅｗｓ．３ｇｐを含む、ファイルディスクリプタテーブルを用いて送信することができる。「ｕｓｅＦｉｌｅＵＲＩ」要素の存在は、ｗｗｗ．＜ｎｅｗｓ ｐｒｏｖｉｄｅｒｓｉｔｅ＞．ｃｏｍ／ｌａｔｅｓｔ＿ｎｅｗｓ．３ｇｐからソースデータを取り出すために、端末がＨＴＴＰバイト範囲要求を使用できることを端末に示す。したがって、受信機をｗｗｗ．＜ｍｏｂｉｌｅ−ｏｐｅｒ−ｃａｃｈｅｄ−ｆｉｌｅ−ｓｅｒｖｅｒ−ｏｆ−ｎｅｗｓ＞．ｃｏｍ／ｎｅｗｓｆｉｌｅ＿００３．３ｇｐに向かわせる代わりに、受信機は、一般に従来のＨＴＴＰプロトコルを使用してコンテンツにアクセスするブラウザからコンテンツがすでに利用可能であるサイトに直接的に向かう。たとえば、オリジナル順、またはＵＦＳＩ順、またはＳＳ順、または拡張オリジナル順ＨＴＴＰファイル形式などの、ファイル形式を伝える別の要素が存在することができる。
専用の修復手順とは独立に、コンテンツ配送システムは、ブロードキャストされるコンテンツに加えて、ファイルのコンテンツの一部またはすべてがユニキャストによって利用可能であることを受信機に伝えるためのメカニズムを含むことができる。この伝達は、ブロードキャストの一部として提供されるデータとすることができ、データは、ユニキャストロケーションを指し示す。たとえば、ブロードキャストデータは、ファイルの利用可能性およびファイルのためのＵＲＬの表示を含むことができる。異なる実施形態は、これらの利用可能なファイルを異なるように使用することができる。たとえば、ブロードキャストされたＵＲＬによって示されるファイルは、修復処理のために使用されるファイル、ダウンロードをスピードアップするために、および／またはより高速な初期プレイアウトをサポートするために使用されるファイルとすることができる。
いくつかの実施形態では、ファイルは、２つ以上のネットワークまたは物理ロケーションに存在する。そのため、ブロードキャストチャネル上の伝達は、ファイルが入手可能な複数のロケーションを示すＵＲＬのリストを含むことができる。いくつかの実施形態では、実際には同じ物理ロケーションを指し示す、したがって、同じファイルまたはオブジェクトを指し示す、複数のＵＲＬが存在する。
ＵＲＬ（複数可）によって示されるリソース（複数可）は、たとえば、限られた時間の間だけ利用可能であることによって、制限され得る。（ブロードキャスト配信において識別子を介して指定される）オブジェクトを場合によっては複数のＵＲＬにマッピングできるようにすることが有益であり得る。ＵＲＬの各々について、ファイルが、ＨＴＴＰプロトコルを使用して１つのロケーションにおいて物理的にアクセス可能であり、他のプロトコルを使用して他のロケーションまたは同じロケーションにおいて利用可能であることを示す表示など、追加情報を提供することができる。そのような追加情報の他の例は、リソースが特定のＵＲＬにおいてアクセス可能な時間、および／またはリソースにアクセスするための複数のＵＲＬの中からＵＲＬを選択する優先順位に関するルール、たとえば、優先順位リスト、もしくは利用可能なアクセスネットワークに依存する優先順位リストなどを含む。
修復データを要求するときに、受信機がどのサーバまたはドメインを最初に試みるべきかについての優先度付けを提供するために、別のディスクリプタも、サーバＵＲＬリストとともに送信することができる。好ましい一実施形態では、「ｐｒｉｏｒｉｔｙＵＲＩ」要素を何らかのＵＲＩに関連付けて、サーバを選択する際に、それらが受信機によって優先されるべきであることを示すことができる。これは、２つのレベルの優先度付けを可能にし、それによって、受信機は、「ｐｒｉｏｒｉｔｙＵＲＩ」を有するサーバを最初に試み、優先されたサーバが応答しない場合に限って、他のサーバに要求を送信する。別の実施形態では、サーバＵＲＩのグループを、優先度の降順に列挙されたグループを有する「ｐｒｉｏｒｔｙＧｒｏｕｐｓ」に構成することができる。これは、優先度が最も高いグループから最初に選択すべきことを受信機に通知する。これらのサーバのすべてへの要求が失敗した場合、受信機は、サーバの次のグループからサーバを選択することに着手し、以下同様であり、それによって、複数のレベルの優先度付けを可能にする。
ディスクリプタおよびサーバＵＲＩのリストを受信機に伝達できる、２つの一般的な方法が今から説明される。一方では、伝達は、すべての受信機に対するブロードキャストチャネルを介するものであり（帯域内）、他方では、伝達は、各受信機へのユニキャストチャネルを介するものである（帯域外）。情報は、関連手順記述（構成ファイル）、ユーザサービス記述（「ＵＳＤ」）、メディア提示記述（「ＭＰＤ」、セッション記述プロトコル（「ＳＤＰ」）、またはファイル記述テーブル（「ＦＤＴ」）など、ファイル修復機能において使用される様々な既存のメッセージタイプに追加することができる。
そのような情報を分配するためにＦＤＴおよびＵＳＤを伝達するようにサーバが構成され、それらのＦＤＴおよびＵＳＤを読み、理解するように受信機が構成される場合、これは、様々な有益な情報を送信するための機構を提供する。
たとえば、情報は、ＦＬＵＴＥでは、同じファイルのための複数の代替ＵＲＬを含むことができる、「代替コンテンツロケーション（Ａｌｔｅｒｎａｔｉｖｅ−Ｃｏｎｔｅｎｔ−Ｌｏｃａｔｉｏｎ）」要素をファイル要素内に含むことができる。この要素は、（リソース利用可能性のインジケータ、リソースが利用可能である形式、リソースが利用可能である時間、優先度位など）他のパラメータも追加するように拡張することができる。
別の例として、ＦＤＴ内のファイルの各々がベースＵＲＬ要素のいずれかに対して解決され得ることを受信機に通知するために、「ベースＵＲＬ（ＢａｓｅＵＲＬ）」をＦＤＴ要素内に含むことができる（したがって、ファイル要素内では必要とされない）。上記のようなフラグおよびタイミングが、同じく存在することができる。これは、選択可能な多くの配備をカバーすることができる。変形では、ベースＵＲＬは、ＦＬＵＴＥの代わりに、ＵＳＤレベルにおいて提示される。したがって、ＵＳＤは、ＦＬＵＴＥと互換性をもちながら、ＭＢＭＳのためのベースＵＲＬ解決を行うための方法として提供することができる。
別の実施形態では、「代替コンテンツロケーション−１」要素および「代替コンテンツロケーション−２」要素などの、いくつかの任意選択的な要素を、ファイル配送テーブル（ＦＤＴ）のファイル要素に導入することができる。これらの要素の各々は、コンテンツサーバまたは共通の専用サーバにおけるファイルのＵＲＬを提供するために使用することができる。一実施形態では、これらの要素のどちらかが存在する場合、これらのＵＲＬは、シンボルベースのファイル修復サーバに要求を行う前に、端末によって優先度付けされる。両方の要素が存在する場合、「代替コンテンツロケーション−２」要素の前に、「代替コンテンツロケーション−１」要素が選択されることを必要とすることも可能である。ＵＲＬは、絶対ＵＲＬ、またはＲＦＣ３９８６で説明されているような相対参照とすることができる。
別の実施形態では、わかっている場合は、利用可能時間を示すために、任意選択的な「利用可能時間」要素が、上述の「代替コンテンツロケーション−ｘ」属性の各々に関連付けられる。
別の実施形態では、任意選択的な要素「ベースＵＲＬ−１」および「ベースＵＲＬ−２」が、ファイル配送テーブル内で使用され得る。存在する場合、「ベースＵＲＬ−１」は、ＦＤＴファイル要素の任意の「代替コンテンツロケーション−１」要素内に含まれる相対参照を解決するためのベースＵＲＬを提供する。存在する場合、「ベースＵＲＬ−２」は、ＦＤＴファイル要素の任意の「代替コンテンツロケーション−２」要素内に含まれる相対参照を解決するためのベースＵＲＬを提供する。
他のオプションを考えることができ、同様に上述のオプションの組合せも考えることができる。たとえば、利用可能なファイル形式に従ってグループ化された他のＵＲＬに、ファイル形式タイプを埋め込む。
通信事業者のネットワーク内の端末がチャーン（ｃｈｕｒｎ）され、より多くの受信機がＨＴＴＰバイト範囲要求に対応可能になるにつれて、通信事業者は、ファイル修復容量のより多くを従来のＨＴＴＰサーバに移行し、この伝達方法を介して、それらの能力を通知することができる。
ある修復サーバがＨＴＴＰバイト範囲要求をサポートする旨の通知を受信すると、ＨＴＴＰバイト範囲要求をサポートする端末は、サポートサーバの１つにデータを要求するために、バイト範囲要求を使用することができる。
どの要求形式を使用するのが好ましいか、または必要かをディスクリプタが示す、別の実施形態では、受信機は、示された選好または要件に従う。
別の手法は、どの特定のサーバがこの機能を有するかを識別することなく、ＨＴＴＰバイト範囲要求が修復サーバによってサポートされることを受信機に伝えることである。伝達は、すべての修復サーバが、ＨＴＴＰバイト範囲要求のみに対応可能であること、またはすべてが、ＨＴＴＰバイト範囲要求と、たとえば、シンボルベースの要求など、他の要求メッセージ形式とに対応可能であることを示す。
別の実施形態では、信号は、上で列挙された３つの可能性のうちの１つ、すなわち、（１）すべての修復サーバがＨＴＴＰバイト範囲要求のみをサポートするかどうか、（２）修復サーバが別のタイプの要求形式（たとえば、シンボルベース）のみをサポートするかどうか、または（３）修復サーバがＨＴＴＰバイト範囲要求と他の要求形式とをサポートするかどうかを示す。この簡略化された伝達が使用される場合、通信事業者は、これを受信機に伝達する前に、通知された要求形式（複数可）をサポートするように、ファイル修復サーバのすべてをアップグレードすることができる。たとえば、オリジナル順、ＵＦＳＩ順、ＳＳ順、拡張オリジナル順、または他のタイプのＨＴＴＰファイル形式など、ファイル形式タイプも伝達することができる。ファイル形式タイプが明示的に伝達されない場合の、デフォルトファイル形式タイプが存在することができ、たとえば、ファイル形式タイプが伝達されない場合、オリジナル順ＨＴＴＰファイル形式をデフォルトとすることができる。
ディスクリプタおよびサーバＵＲＩ情報と同様に、この伝達も、２つの一般的な方法を使用して、受信機に伝達することができる。一方では、伝達は、すべての受信機に対するブロードキャストチャネルを介するものであり（帯域内）、他方では、伝達は、各受信機へのユニキャストチャネルを介するものである（帯域外）。表示は、関連手順記述（構成ファイル）、ユーザサービス記述（「ＵＳＤ」）、メディア提示記述（「ＭＰＤ」）、セッション記述プロトコル（「ＳＤＰ」）、またはファイル記述テーブル（「ＦＤＴ」）など、ファイル修復機能において使用される様々な既存のメッセージタイプに追加することができる。
ディスクリプタおよびサーバＵＲＩのリストを受信機に伝達できる、２つの一般的な方法が今から説明される。
当業者が理解するように、これらの方法には多くの変形が存在する。たとえば、オリジナル順ＨＴＴＰファイル、ＵＦＳＩ順ＨＴＴＰファイル、およびＳＳ順ＨＴＴＰファイルはすべて、要求に対して利用可能にすることができる。別の例として、ＳＳ順ＨＴＴＰファイルは、分割して、複数のＨＴＴＰファイルとして利用可能にすることができ、各ソースブロックに対して、１つのそのようなＨＴＴＰファイルが存在する。変形の他の例として、ＨＴＴＰに基づいたもの以外の方法およびプロトコルを使用することができ、ＲＴＰ／ＵＤＰまたはＵＤＰ上に構築された独自仕様のプロトコルに基づいた方法などを使用することができる。
ハードウェアシステムおよび例
上で説明された方法およびシステムは、ハードウェア、ソフトウェア、および／またはプログラムコードもしくは他の命令を含む適切に組織されたコンピュータ可読媒体で実施することができる。プログラムコードは、適切なハードウェアプラットフォーム上で実行するために、非一時的な媒体上で提供すること、またはダウンロードとして送信することなどができる。上述の教示を使用できるシステムのいくつかの例が、本明細書で提供される。
図１３は、本明細書で説明されるファイル配送システムの一部としての、パケットを送信するために使用できるようなマルチステージ符号化を使用する通信システム１３００のブロック図である。もちろん、他の符号および／またはハードウェアを代わりに使用することができる。
通信システム１３００では、入力ファイル１３０１または入力ストリーム１３０５が入力シンボル生成器１３１０に提供される。入力シンボル生成器１３１０は、入力ファイルまたはストリームから、１つまたは複数の入力シンボルの系列（ＩＳ（０）、ＩＳ（１）、ＩＳ（２）、．．．）を生成し、各入力シンボルは、値および（図１３において括弧付きの整数として示される）位置を有する。上で説明されたように、入力シンボルのための可能な値、すなわち、そのアルファベットは、各入力シンボルが入力ファイルのＭビットに対する符号となるように、一般に２M個のシンボルからなるアルファベットである。Ｍの値は、一般に、通信システム１３００の使用によって決定されるが、汎用的なシステムは、使用ごとにＭが変化し得るように、入力シンボル生成器１３１０のためのシンボルサイズ入力を含むことができる。入力シンボル生成器１３１０の出力は、符号化器１３１５に提供される。
静的鍵生成器１３３０は、静的鍵のストリームＳ0、Ｓ1、．．．を生成する。生成される静的鍵の数は、一般に制限され、符号化器１３１５の特定の実施形態に依存する。静的鍵の生成は、後でより詳細に説明される。動的鍵生成器１３２０は、符号化器１３１５によって生成された各出力シンボルのための動的鍵を生成する。各動的鍵は、同じ入力ファイルのための動的鍵の大部分が一意的であるように生成される。乱数発生器１３３５が、生成器１３２０および／または生成器１３３０に入力を提供することができる。たとえば、Ｌｕｂｙ Ｉは、使用できる鍵生成の実施形態について説明している。動的鍵生成器１３２０および静的鍵生成器１３３０の出力は、符号化器１３１５に提供される。
動的鍵生成器１３２０によって提供される各鍵Ｉと、入力シンボル生成器によって提供される入力シンボルとから、符号化器１３１５は、値がＢ（Ｉ）の出力シンボルを生成する。符号化器１３１５の動作は、以下でより詳細に説明される。各出力シンボルの値は、その鍵に基づいて、また入力シンボルの１つまたは複数と、場合によっては、入力シンボルから計算された１つまたは複数の冗長シンボルとの何らかの関数に基づいて生成される。特定の出力シンボルを生じさせる入力シンボルと冗長シンボルの集まりは、本明細書では、出力シンボルの「同伴シンボル（ａｓｓｏｃｉａｔｅｄ ｓｙｍｂｏｌ）」または単に「同伴（ａｓｓｏｃｉａｔｅ）」と呼ばれる。関数（「値関数」）および同伴の選択は、以下でより詳細に説明されるプロセスに従って行われる。常にではないが、一般に、Ｍは、入力シンボルと出力シンボルに対して同じであり、すなわち、それらはともに、同数のビットに対する符号である。
いくつかの実施形態では、同伴を選択するために、入力シンボルの数Ｋが、符号化器１３１５によって使用される。入力がストリーミングファイルである場合など、Ｋが事前にわからない場合、Ｋは、単なる推定値とすることができる。値Ｋは、入力シンボルおよび符号化器１３１５によって生成される任意の中間シンボルのための記憶域を割り当てるために、符号化器１３１５によって使用することもできる。
符号化器１３１５は、出力シンボルを送信モジュール１３４０に提供する。送信モジュール１３４０は、動的鍵生成器１３２０から、そのような各出力シンボルの鍵も提供される。送信モジュール１３４０は、出力シンボルを送信し、使用される鍵方法に応じて、送信モジュール１３４０は、送信される出力シンボルの鍵についての何らかのデータも、チャネル１３４５を介して、受信モジュール１３５０に送信することができる。チャネル１３４５は、消失チャネルであることが仮定されるが、それは、通信システム１３００の適切な動作のための要件ではない。
モジュール１３４０、１３４５、１３５０は、送信モジュール１３４０が、出力シンボルと、それらの鍵についての任意の必要なデータとをチャネル１３４５に送信するように適合されており、受信モジュール１３５０が、シンボルと、潜在的にそれらの鍵についての何らかのデータとをチャネル１３４５から受信するように適合されている限り、任意の適切なハードウェア構成要素、ソフトウェア構成要素、物理媒体、またはそれらの任意の組合せとすることができる。Ｋの値は、同伴を決定するために使用される場合は、チャネル１３４５を介して送信することができ、または符号化器１３１５と復号器１３５５の取り決めによって事前に設定しておくことができる。図１３（および本明細書の他の場所）に示される他の要素も、モジュール、ステップ、プロセスなどのいずれとして説明されているかにかかわらず、ハードウェア、ソフトウェア、および／または電子的に可読な媒体上に記憶されたプログラムコードを使用して実施することができる。
上で説明されたように、チャネル１３４５は、インターネットを介する経路、もしくはテレビ送信機からテレビ受信者までの放送リンク、もしくは１つの地点から別の地点までの電話接続などの、リアルタイムチャネルとすることができ、またはチャネル１３４５は、ＣＤ ＲＯＭ、ディスクドライブ、もしくはウェブサイトなどの、記憶チャネルとすることができる。チャネル１３４５は、ある人がパーソナルコンピュータから電話回線を介してインターネットサービスプロバイダ（ＩＳＰ）に入力ファイルを送信し、入力ファイルがウェブサーバ上に記憶され、その後、インターネットを介して受信者に送信される場合に形成されるチャネルなど、リアルタイムチャネルと記憶チャネルの組合せとすることさえできる。
チャネル１３４５は消失チャネルであると仮定されるので、通信システム１３００は、受信モジュール１３５０から出る出力シンボルと送信モジュール１３４０に入る出力シンボルとの間の１対１対応を仮定しない。事実、チャネル１３４５がパケットネットワークを備える場合、通信システム１３００は、任意の２つ以上のパケットの相対順序が、チャネル１３４５を通過する際に維持されることを仮定できないことさえある。したがって、出力シンボルの鍵は、上で説明された鍵方式の１つまたは複数を使用して決定され、出力シンボルが受信モジュール１３５０から出る順序によって必ずしも決定されない。
受信モジュール１３５０は、出力シンボルを復号器１３５５に提供し、これらの出力シンボルの鍵についての受信モジュール１３５０が受信する任意のデータは、動的鍵再生成器１３６０に提供される。動的鍵再生成器１３６０は、受信された出力シンボルのための動的鍵を再生成し、これらの動的鍵を復号器１３５５に提供する。静的鍵生成器１３６３は、静的鍵Ｓ0、Ｓ1、．．．を再生成し、それらを復号器１３５５に提供する。静的鍵生成器は、符号化プロセス中と復号プロセス中の両方で使用される乱数発生器１３３５にアクセスする。これは、乱数が同じ物理デバイス上で生成される場合は、そのようなデバイスへのアクセスの形態を取ることができ、または同じ挙動を達成するために、乱数生成のための同じアルゴリズムへのアクセスの形態を取ることができる。復号器１３５５は、入力シンボル（やはり、ＩＳ（０）、ＩＳ（１）、ＩＳ（２）、．．．）を回復するために、動的鍵再生成器１３６０および静的鍵生成器１３６３によって提供される鍵を、対応する出力シンボルと一緒に使用する。復号器１３５５は、回復された入力シンボルを入力ファイル再組立て器１３６５に提供し、入力ファイル再組立て器１３６５は、入力ファイル１３０１または入力ストリーム１３０５のコピー１３７０を生成する。
ファイル配送は、複数の受信機および／または複数の送信機を用いて行うことができる。これらの概念は、図１４〜図１５に図示される。
図１４は、１つの受信機２４０２が、３つのチャネル２４０６を介して、（それぞれ「Ａ」、「Ｂ」、「Ｃ」で示される）３つの送信機２４０４からデータを受信する構成を図示する。この構成は、受信機が利用可能な帯域幅を３倍にするために、またはいずれか１つの送信機からファイル全体を獲得できるほど十分長くは利用できない送信機に対処するために使用することができる。示されるように、各送信機２４０４は、値のストリームＳ（）を送信する。各Ｓ（）値は、その使用が上で説明された、出力シンボルＢ（Ｉ）および鍵Ｉを表す。たとえば、値Ｓ（Ａ、ｎA）は、送信機２４０２（Ａ）において生成された出力シンボルの系列における、第「ｎA」の出力シンボルおよび第「ｎA」の鍵である。１つの送信機からの鍵の系列は、送信機が重複した労力を払わないように、好ましくは、他の送信機からの鍵の系列と異なる。これは、図１４において、系列Ｓ（）が送信機の関数であるという事実によって示されている。
送信機２４０２は、重複した労力を払わないようにするために、同期または協調させる必要はない。事実、協調せずに、各送信機は、その系列の異なる場所にいる（すなわち、ｎA≠ｎB≠ｎCである）可能性が高い。
図１５では、１つの入力ファイル２５０２のコピーが、複数の送信機２５０４（そのうちの２つが図に示されている）に提供される。送信機２５０４は、個々に、入力ファイル２５０２のコンテンツから生成された出力シンボルを、チャネル２５０６を介して、受信機２５０８に送信する。示された２つのうちの各送信機は、（Ｋ＋Ａ）／２個の出力シンボルのみを送信しさえすればよく、その後、受信機の復号器は、入力ファイル全体を回復することができる。
２つの受信機と２つの送信機を使用すると、受信機ユニット２５１０によって受信される情報の総量は、１つのチャネル２５０６を介して利用可能な情報の４倍になり得る。情報の量は、たとえば、送信機が両方の受信機に同じデータをブロードキャストする場合、単一チャネルの情報の４倍よりも少なくなることがある。その場合、受信機ユニット２５１０における情報の量は、少なくとも２倍になり、データがいずれかのチャネルで失われる場合は、しばしばそれよりも多くなる。送信機がただ１つの信号をブロードキャストする場合でも、受信機が異なる時間に視野内にあるならば、各送信機をリスンしている２つ以上の受信機を有する利点が存在することに留意されたい。図１５では、受信機ユニット２５１０は、図１３に示された受信モジュール１３５０、復号器１３５５、動的鍵再生成器１３６０、および入力ファイル再組立て器１３６５の機能に類似した機能を実行する。
いくつかの実施形態では、コンピューティングデバイスが、一方の送信機に１つの出力を提供でき、他方の送信機に別の出力を提供できるように、入力ファイル２５０２は、２つの符号化器を有する１つのコンピューティングデバイスにおいて符号化される。これらの例の他の変形は、本開示を検討することで明らかになる。
本明細書で説明される符号化装置および方法は、他の通信状況においても使用することができ、インターネットなどの通信ネットワークに限定されないことを理解されたい。たとえば、コンパクトディスク技術も、傷付きディスク問題に対処するために、消失および誤り訂正符号を使用し、情報をディスクに記憶する際にチェーンリアクション符号を使用することから利益を得る。別の例として、衛星システムは、送信のための電力要件を犠牲にして、電力低下によるより多くの誤りを意図的に許容するために、消失符号を使用することができ、チェーンリアクション符号は、その応用において有益である。また、消失符号は、情報記憶の信頼性を高めるためのＲＡＩＤ（独立ディスクの冗長アレイ）システムを開発するために使用された。本発明は、したがって、潜在的なデータ紛失またはデータ誤りの問題に対処するために符号が使用される他の応用において有益であることがわかる。
いくつかの好ましい実施形態では、上で説明された通信プロセスを実行するための命令の組（またはソフトウェア）が、おそらくは損失のある通信媒体を介して通信する２つ以上の多目的コンピューティング機械に提供される。機械の数は、１つの送信機および１つの受信機から、任意の数の送信および／または受信機械にわたることができる。機械を接続する通信媒体は、有線、光、またはワイヤレスなどとすることができる。上で説明された通信システムは、この説明から明らかな、多くの用途を有する。
ＨＴＴＰストリーミングサーバを使用するブロック要求ストリーミングシステムは、上で説明されたように、ファイルを配送することができる。以下では、そのようなシステムの例示的な実施が説明される。ＨＴＴＰストリーミングを用い、送信元は、標準的なウェブサーバ、およびコンテンツ配送ネットワーク（ＣＤＮ）とすることができ、標準的なＨＴＴＰを使用することができる。
クライアント側では、クライアントによってシームレスに継ぎ合わされる個々のセグメントを求める要求が、ＨＴＴＰを使用して行われ得る。ＨＴＴＰストリーミングの利点は、標準化された既存のインフラストラクチャの使用を含む。
図１６は、ファイルを配送できる、ブロック要求ストリーミングシステムの簡略図を示している。図１６には、ブロックストリーミングシステム１６００が図示されており、それは、ブロックサービングインフラストラクチャ（「ＢＳＩ」）１６０１を備え、今度は、ブロックサービングインフラストラクチャ１６０１が、取込みシステム１６０３を備え、取込みシステム１６０３は、コンテンツ１６０２を取込み、そのコンテンツを準備し、そして、取込みシステム１６０３とＨＴＴＰストリーミングサーバ１６０４の両方からアクセス可能なコンテンツストア１６１０にコンテンツを記憶することによって、ＨＴＴＰストリーミングサーバ１６０４によるサービスのためにそのコンテンツをパッケージ化するためのものである。示されるように、システム１６００は、ＨＴＴＰキャッシュ１６０６も含むことができる。動作面では、ＨＴＴＰストリーミングクライアントなどクライアント１６０８は、ＨＴＴＰストリーミングサーバ１６０４に要求１６１２を送信し、ＨＴＴＰストリーミングサーバ１６０４またはＨＴＴＰキャッシュ１６０６から応答１６１４を受信する。どの場合も、図１６に示される要素は、少なくとも部分的には、プロセッサまたは他の電子機器上で実行されるプログラムコードを備えるソフトウェアで実施することができる。
図１７に示されるように、メディアブロックは、たとえば、ＨＴＴＰサーバ、コンテンツ配送ネットワークデバイス、ＨＴＴＰプロキシ、ＦＴＰプロキシもしくはサーバ、または他の何らかのメディアサーバもしくはシステムとすることができる、ブロックサービングインフラストラクチャ１６０１（１）内に記憶することができる。ブロックサービングインフラストラクチャ１６０１（１）は、たとえば、インターネットなどのインターネットプロトコル（「ＩＰ」）ネットワークとすることができる、ネットワーク１７２２に接続される。６つの機能構成要素を有する、ブロック要求ストリーミングシステムクライアントが示されており、その６つとは、上で説明されたメタデータを提供され、メタデータによって指示される複数の利用可能なブロックの中から要求されるブロックまたは部分ブロックを選択する機能を実行する、ブロック選択器１７２３、ブロック選択器１７２３から要求命令を受け取り、指定されたブロック、ブロックの部分、または複数のブロックを求める要求をネットワーク１７２２を介してブロックサービングインフラストラクチャ１６０１（１）に送信し、応答としてブロックを備えるデータを受信するために必要な動作を実行する、ブロック要求器１７２４、ならびにブロックバッファ１７２５、バッファモニタ１７２６、メディア復号器１７２７、およびメディア消費を円滑にする１つまたは複数のメディア変換機１７２８である。
ブロック要求器１７２４によって受信されたブロックデータは、メディアデータを記憶するブロックバッファ１７２５に、一時記憶のために渡される。代替として、受信されたブロックデータは、ブロックバッファ１７２５に直接的に記憶することができる。メディア復号器１７２７は、ブロックバッファ１７２５によってメディアデータを提供され、このデータに対して、メディア変換機１７２８に適切な入力を提供するのに必要となるような変換を実行し、メディア変換機１７２８は、ユーザまたは他の消費のために適した形式で、メディアを表現する。メディア変換機の例は、モバイルフォン、コンピュータシステム、またはテレビにおいて見出されるような視覚的表示デバイスを含み、スピーカまたはヘッドフォンなどのオーディオ表現デバイスも含むことができる。
バッファモニタ１７２６は、ブロックバッファ１７２５のコンテンツに関する情報を受け取り、この情報および場合によっては他の情報に基づいて、ブロック選択器１７２３に入力を提供し、ブロック選択器１７２３は、本明細書で説明されるように、要求するブロックの選択を決定するために使用される。
ブロック要求ストリーミングシステム（ＢＲＳＳ）は、１つまたは複数のコンテンツサーバ（たとえば、ＨＴＴＰサーバ、ＦＴＰサーバなど）に要求を行う、１つまたは複数のクライアントを備える。取込みシステムは、１つまたは複数の取込みプロセッサを備え、取込みプロセッサは、コンテンツを（リアルタイムまたは非リアルタイムで）取込み、ＢＲＳＳによる使用のためにコンテンツを処理し、それを、取込みプロセッサによって生成されたメタデータと場合によっては一緒に、コンテンツサーバがアクセス可能なストレージに記憶する。
ＢＲＳＳは、コンテンツサーバと協調するコンテンツキャッシュも含むことができる。コンテンツサーバおよびコンテンツキャッシュは、ＵＲＬを含み、ＵＲＬによって示されるファイルまたはセグメントの全体よりも小さい部分を要求するために、オクテット範囲も含むことができる、ＨＴＴＰ要求の形式のファイルまたはセグメントを求める要求を受信する、従来のＨＴＴＰサーバおよびＨＴＴＰキャッシュとすることができる。クライアントは、ＨＴＴＰサーバに要求を行い、それらの要求に対する応答を処理する、従来のＨＴＴＰクライアントを含むことができ、ＨＴＴＰクライアントは、新規なクライアントシステムによって駆動され、新規なクライアントシステムは、要求を定式化し、それらをＨＴＴＰクライアントに渡し、ＨＴＴＰクライアントから応答を取得し、それらを提示プレーヤに提供して、クライアントデバイスによってプレイアウトするために、それらを処理する（または記憶、変換などを行う）。一般に、（どのメディアが必要かは、ユーザ入力、ユーザ入力の変更などに依存し得るので）クライアントシステムは、どのメディアが必要かを事前に知らず、そのため、受信されると直ちに、または受信後まもなく、メディアが「消費」される点で、「ストリーミング」システムであると言われる。結果として、応答遅延および帯域幅制約は、消費中の提示内におけるユーザの場所にストリームが追い付くときに、提示中に中断を生じさせるなど、提示の遅延の原因となり得る。
良好な品質であると感知される提示を提供するために、ＢＲＳＳでは、数々の細目を、クライアント側、取込み側、または両方で実施することができる。場合によっては、実施される細目は、ネットワークにおけるクライアントサーバインターフェースを考慮して、およびそれに対処するために行われる。いくつかの実施形態では、クライアントシステムと取込みシステムの両方が、機能強化について知っているが、他の実施形態では、一方の側しか、機能強化について知っていない。そのような場合、一方の側しか機能強化について知らなくても、システム全体が機能強化から利益を得るが、他の場合は、両方の側が機能強化について知っている場合のみ、利益が得られ、しかし、一方の側が知らない場合でも、それは依然として問題なく動作する。
図１８に示されるように、取込みシステムは、様々な実施形態に従って、ハードウェア構成要素とソフトウェア構成要素の組合せとして実施することができる。取込みシステムは、本明細書で説明される方法のいずれか１つまたは複数をシステムに実行させるために実行することができる、１組の命令を備えることができる。システムは、コンピュータの形態を取る特定の機械として実現することができる。システムは、サーバコンピュータ、パーソナルコンピュータ（ＰＣ）、またはそのシステムによって取られるアクションを指定する（順次的または他の）１組の命令を実行することが可能な任意のシステムとすることができる。さらに、単一のシステムのみが示されているが、「システム」という用語は、本明細書で説明される方法のいずれか１つまたは複数を実行するために、個々にまたは共同して、１組（または複数組）の命令を実行する、システムの任意の集まりも含むと解釈される。
取込みシステムは、取込みプロセッサ１８０２（たとえば、中央処理装置（ＣＰＵ））と、実行中にプログラムコードを記憶できるメモリ１８０４と、ディスクストレージ１８０６とを含むことができ、それらはすべて、バス１８００を介して互いに通信する。システムは、ビデオディスプレイユニット１８０８（たとえば、液晶ディスプレイ（ＬＣＤ）またはブラウン管（ＣＲＴ））をさらに含むことができる。システムは、英数字入力デバイス１８１０（たとえば、キーボード）と、コンテンツソースを受け取り、コンテンツストアを配送するためのネットワークインターフェースデバイス１８１２も含むことができる。
ディスクストレージユニット１８０６は、本明細書で説明される方法または機能のいずれか１つまたは複数を具体化する１組または複数組の命令（たとえば、ソフトウェア）を記憶できる、機械可読媒体を含むことができる。命令は、システムによる命令の実行中は、メモリ１８０４内および／または取込みプロセッサ１８０２内にも、全体的または少なくとも部分的に存在することができ、メモリ１８０４および取込みプロセッサ１８０２も、機械可読媒体を構成する。
図１９に示されるように、クライアントシステムは、様々な実施形態に従って、ハードウェア構成要素とソフトウェア構成要素の組合せとして実施することができる。クライアントシステムは、本明細書で説明される方法のいずれか１つまたは複数をシステムに実行させるために実行することができる、１組の命令を備えることができる。システムは、コンピュータの形態を取る特定の機械として実現することができる。システムは、サーバコンピュータ、パーソナルコンピュータ（ＰＣ）、またはそのシステムによって取られるアクションを指定する（順次的または他の）１組の命令を実行することが可能な任意のシステムとすることができる。さらに、単一のシステムのみが示されているが、「システム」という用語は、本明細書で説明される方法のいずれか１つまたは複数を実行するために、個々にまたは共同して、１組（または複数組）の命令を実行する、システムの任意の集まりも含むと解釈される。
クライアントシステムは、クライアントプロセッサ１９０２（たとえば、中央処理装置（ＣＰＵ））と、実行中にプログラムコードを記憶できるメモリ１９０４と、ディスクストレージ１９０６とを含むことができ、それらはすべて、バス１９００を介して互いに通信する。システムは、ビデオディスプレイユニット１９０８（たとえば、液晶ディスプレイ（ＬＣＤ）またはブラウン管（ＣＲＴ））をさらに含むことができる。システムは、英数字入力デバイス１９１０（たとえば、キーボード）と、要求を送信し、応答を受信するためのネットワークインターフェースデバイス１９１２も含むことができる。
ディスクストレージユニット１９０６は、本明細書で説明される方法または機能のいずれか１つまたは複数を具体化する１組または複数組の命令（たとえば、ソフトウェア）を記憶できる、機械可読媒体を含むことができる。命令は、システムによる命令の実行中は、メモリ１９０４内および／またはクライアントプロセッサ１９０２内にも、全体的または少なくとも部分的に存在することができ、メモリ１９０４およびクライアントプロセッサ１９０２も、機械可読媒体を構成する。
特定の一実施形態の例
［ＲａｐｔｏｒＱ−ＲＦＣ−６３３０］で仕様化されたＲａｐｔｏｒＱ ＦＥＣ方式を使用する汎用オブジェクト配送のための完全に仕様化されたＦＥＣ方式の特定の実施形態が、このセクションにおいて説明される。簡略化および機能強化されたオブジェクト配送機能を提供するために、［ＲａｐｔｏｒＱ−ＲＦＣ−６３３０］のＲａｐｔｏｒＱ ＦＥＣ方式と一緒に、ＵＯＳＩ ＦＥＣペイロードＩＤを使用することができる。特に、基本的オブジェクト配送のための、より柔軟かつ簡単なサポートが提供され、不均一誤り保護（ＵＥＰ）オブジェクト配送、バンドル化オブジェクト配送、およびＵＥＰとバンドル化オブジェクト配送の組合せのための、サポートも提供される。通信デバイス間で「ＵＯＤ ＲａｐｔｏｒＱ ＦＥＣ方式」をサポートするために、適切なハードウェアおよび／またはソフトウェアを使用できることを理解されたい。
ＦＥＣペイロードＩＤ形式は、図２に示されるような４オクテットフィールドであり、この特定の実施では、３２ビットの符号なし整数である汎用ファイルシンボル識別子（ＵＦＳＩ）は、やはり３２ビットの符号なし整数である汎用オブジェクトシンボル識別子（ＵＯＳＩ）によって一般化される。ＵＯＳＩは、そのペイロードＩＤを搬送するパケット内に含まれる符号化シンボルを識別するために、ＦＥＣ ＯＴＩと併せて使用される、非負の整数である。
単一のオブジェクト、もしくは複数のオブジェクト、もしくは優先度が異なる部分に分割される単一のオブジェクト、またはこれらの任意の組合せの配送の場合、ＦＥＣ ＯＴＩは、以下で説明されるようになる。配送される各オブジェクトについて、ＦＥＣ ＯＴＩは、ＲａｐｔｏｒＱ ＦＥＣ方式によって仕様化されたものと同じとすることができることに留意されたい。配送は、ｄ個のオブジェクトを備え、ｄは、何らかの正の整数である。各オブジェクトは、同じファイルの異なる部分、もしくは異なるファイル、またはそれらの組合せを備えることができる。送信におけるオブジェクトｉの優先度を決定するために、オブジェクトｉのサイズＦiとオブジェクトｉのために使用される符号化シンボルのサイズＴiとの間の関係を使用することができる。
図２０は、共通ＦＥＣ ＯＴＩフィールドの一例を図示する。その例で使用される場合、配送されるオブジェクトの数についての８ビットの符号なし整数が存在し、示される例では、ｄ＝２である。デフォルト値は、ｄ＝１とすることができる。含まれる他のサブフィールドは、ｄ個のオブジェクトの各々についての（すなわち、ｉ＝１、．．．、ｄについての）ものであり、オブジェクトｉに固有の共通ＦＥＣ ＯＴＩ要素は、オブジェクトｉのためのシンボルのサイズをオクテット単位で示す、２16未満の正の整数である、シンボルサイズＴiのための１６ビットの符号なし整数、オブジェクトｉの転送長をオクテット単位で示す、最大２40の非負の整数である、オブジェクトｉの転送長Ｆiのための４０ビットの符号なし整数を含む。適切なパディングが提供される。
共通ＦＥＣ ＯＴＩフィールドとは対照的に、図２１に示されるような、方式固有のＦＥＣ ＯＴＩ要素が存在し得る。その例に示されるように、方式固有のＦＥＣ ＯＴＩ要素は、シンボルアライメントパラメータ（Ａｌ）（８ビットの符号なし整数）、各オブジェクトについての方式固有のＦＥＣ ＯＴＩ要素を含み、各オブジェクトについての方式固有のＦＥＣ ＯＴＩ要素は、オブジェクトｉのためのソースブロックの数Ｚi（１２ビットの符号なし整数）と、オブジェクトｉのためのサブブロックの数Ｎiとを備える。符号化された方式固有のオブジェクト送信情報は、（１＋３×ｄ）オクテットのフィールドである。図２１の例では、ｄ＝２である。符号化ＦＥＣ ＯＴＩは、その場合、符号化された共通ＦＥＣ ＯＴＩと符号化された方式固有のＦＥＣ ＯＴＩ要素との連結を備える、（２＋１０×ｄ）オクテットのフィールドである。
符号化されたＦＥＣ ＯＴＩを使用するコンテンツ配送は、ＵＯＤ ＲａｐｔｏｒＱ ＦＥＣ方式と、オブジェクト配送のためにＵＯＤ ＲａｐｔｏｒＱ ＦＥＣ方式を使用するコンテンツ配送プロトコル（「ＣＤＰ」）とを使用する、デバイス、コンピュータ、システムのプログラムの間の情報交換を伴うことができる。ＣＤＰは、符号化器デバイスおよび復号器デバイスに、ｄ、Ａｌ、オブジェクトごとのＦi、Ｔi（Ａｌの倍数）、Ｚi、およびＮiを提供すべきである。符号化器には、ｉによってインデックス付けされた各オブジェクトが提供される。ＵＯＤ ＲａｐｔｏｒＱ符号化器方式を使用する符号化器デバイスは、送信される各パケットのためのＣＤＰ、パケットのＵＯＳＩ、ｄ個のオブジェクト（複数可）のための符号化シンボル（複数可）を供給する。
パラメータ選択の例
一例では、［ＲａｐｔｏｒＱ−ＲＦＣ−６３３０］のセクション４．３で説明されている例示的なパラメータ導出を使用し、ｄ個のオブジェクトの各々に個別に適用することができる。一例では、Ａｌ＝４オクテットであり、ＳＳ＝８であり（これは、各サブシンボルが少なくともＳＳ×Ａｌ＝３２オクテットであることを暗示する）、オブジェクトｉのためのＴiは、好ましくは、少なくともＳＳ×Ａｌオクテットであり、Ｔiは、Ａｌの倍数であるが、各符号化パケットのペイロードサイズは、好ましくは、少なくともＴのサイズであり、Ｔは、ｉ＝１、．．．、ｄにわたるＴiの合計である。
ソースブロック構成について、［ＲａｐｔｏｒＱ−ＲＦＣ−６３３０］のセクション４．４．１内の手順を、ｄ個のオブジェクトの各々に個別に適用することができる。
符号化パケット構成について、各符号化パケットは、ＵＯＳＩと、ｄ個のオブジェクト（複数可）のための符号化シンボル（複数可）とを含む。［ＲａｐｔｏｒＱ−ＲＦＣ−６３３０］のＲａｐｔｏｒＱ ＦＥＣ方式によって使用されるＦＥＣペイロードＩＤの（ＳＢＮ，ＥＳＩ）形式と、ＵＯＤ ＲａｐｔｏｒＱ ＦＥＣ方式によって使用されるＵＯＳＩ形式との間の互換性について、特定の形式が存在することができる。たとえば、各オブジェクトについて、ＵＯＳＩ値Ｃからオブジェクトｉのための対応する（ＳＢＮ，ＥＳＩ）値（Ａ，Ｂ）へのマッピングが存在することができ、ここで、Ｂ＝ｆｌｏｏｒ（Ｃ／Ｚi）、Ａ＝Ｃ−Ｂ×Ｚiである。同様に、各オブジェクトについて、オブジェクトｉのための（ＳＢＮ，ＥＳＩ）値（Ａ，Ｂ）から対応するＵＯＳＩ値Ｃへのマッピングは、Ｃ＝Ａ＋Ｂ×Ｚiである。
各オブジェクトｉ＝１、．．．、ｄについて、０〜ＫＴi−１のＵＯＳＩ値は、ソースブロックインターリーブ順で、オブジェクトｉのソースシンボルを識別し、ここで、ＫＴi＝ｃｅｉｌ（Ｆi／Ｔi）である。ＫＴiから先のＵＯＳＩ値は、ＲａｐｔｏｒＱ符号化器を使用して、オブジェクトｉのソースシンボルから生成された、修復シンボルを識別する。
符号化パケットは、ソースシンボル、修復シンボル、またはソースシンボルと修復シンボルの組合せを含むことができる。パケットは、オブジェクトｉの同じソースブロックから任意の数のシンボルを含むことができる。オブジェクトｉのためのソースパケット内の最後のソースシンボルが、ＦＥＣ符号化目的で追加されたパディングオクテットを含む場合、全体的なシンボルのみが各パケット内に含まれるように、これらのオクテットは、パケット内に含まれるべきである。
各符号化パケット内で搬送される汎用オブジェクトシンボル識別子Ｃは、そのパケット内で搬送される各オブジェクトについての最初の符号化シンボルのＵＯＳＩである。各オブジェクトについてのパケット内の後続の符号化シンボルは、順番にＣ＋１〜Ｃ＋Ｇ＋１の番号が付けられたＵＯＳＩを有し、ここで、Ｇは、パケット内の各オブジェクトについての符号化シンボルの数である。他の実施形態では、各オブジェクトｉについてのＦＥＣ ＯＴＩ情報の一部として指定される、ベースＵＯＳＩ Ｕiが存在することができ、その場合、オブジェクトｉについてのパケット内の最初のシンボルのためのＵＯＳＩは、Ｃ＋Ｕiである。
好ましい一実施では、各符号化パケット内のｄ個のオブジェクトの各々について１つの符号化シンボルが存在する。好ましい一実施では、符号化パケットは、次の手順に従って生成され、送信される。各ＵＯＳＩ値Ｃ＝１、２、３、．．．について、符号化器は、符号化パケットのＦＥＣペイロードＩＤの値がＵＯＳＩ値Ｃになるように設定された符号化パケットを、次のように生成および送信し、すなわち、各オブジェクトｉ、ｉ＝１、．．．、ｄについて、符号化器は、ＵＯＳＩ値Ｃに対応する（ＳＢＮ，ＥＳＩ）値（Ａi，Ｂi）を決定し、ＲａｐｔｏｒＱ ＦＥＣ方式［ＲａｐｔｏｒＱ−ＲＦＣ−６３３０］の手順に従って、オブジェクトｉから（ＳＢＮ，ＥＳＩ）値（Ａi，Ｂi）に対応するサイズがＴiの符号化シンボルＥiを生成し、符号化パケットのペイロードに符号化シンボルＥiを追加し、符号化パケットを送信する。受信機が符号化パケットの総数を知る必要はないことに留意されたい。
ユニキャストソースサーバおよびブロードキャスト修復サーバ
このセクションで説明されるほとんどの実施形態では、修復シンボルは、ブロードキャスト方法で送信され、ソースシンボルは、何組かのソースシンボルを求めるＵＥ要求に応答して、ユニキャスト方法で送信される。少なくともいくつかのソースシンボルがブロードキャスト方法で送信される、いくつかはこのセクションで説明され、いくつかは本明細書の他の箇所で説明される、他の実施形態が存在し、少なくともいくつかの修復シンボルが、ＵＥ要求に応答して、ユニキャスト方法で送信される、実施形態も存在する。
例示的なブロードキャストファイル配送システムは、ｅＭＢＭＳファイル配送システムである。例示的なユニキャストファイル配送システムは、ＨＴＴＰバイト範囲要求に対応可能なシステムである。しかし、ファイル全体しか要求できす、提供できないユニキャストシステムも、場合によっては使用することができるが、多くの利益が失われる。本明細書の先のセクションは、いくつかの例示的なシステムを示している。
このセクションの例では、修復データは、ブロードキャストセッションで送信され、ソースデータのみが、ユニキャスト修復セッションで送信される。ユニキャスト修復要求は、元のファイルの部分を求める標準的なＨＴＴＰ１．１バイト範囲要求である。ブロードキャストセッションは、修復シンボルのみを有するので、２つのセッションの間で重複するデータは存在しない。いくつかの実施では、先に説明されたシステムとこのセクションのシステムの両方が共存すること、および／またはそれらを組み合わせることができることに留意されたい。
上で説明されたように、ＵＥ（たとえば、モバイルユーザデバイスなどのエンドユーザデバイス）は、ＵＥがどのソースシンボルを失っているかを決定し、失っているソースシンボルのソースブロック番号、符号化シンボルｉｄから、標準的なＨＴＴＰ１．１バイト範囲要求への変換を行い、それらの要求を行うように構成することができる。
ブロードキャストセッションで修復シンボルを送信することによって、ユニキャスト修復サーバは、ファイルの元のコピーのみを必要とし、要求は、個々のシンボルを求める要求、または多くの小さなバイト範囲を求める要求ではなく、連続的な範囲のソースシンボルを求める、または連続的な大きい範囲の連続的なバイトを求める単純な要求である。ＵＥは、いくつ受信し、いくつ必要かを単純にカウントすることに基づいて、あるいはたとえば、ソースブロックの復号を可能にするソースシンボルのプレフィックス数、またはソースサブブロックの復号を可能にするソースサブシンボルのプレフィックス数、またはサブブロックもしくはソースブロックの復号を可能にするプレフィックスバイト範囲サイズを決定するために、復号スケジュールを実行することに基づいて、いくつのシンボルを要求すべきかを決定することができる。この文脈および本明細書の他の文脈では、「プレフィックス」によって、「サブブロックに対応するファイルの部分のプレフィックス」、または「ソースブロックに対応するファイルの部分のプレフィックス」を指すことが意図されており、すなわち、「プレフィックス」によって、ファイル全体のプレフィックスではなく、代わりに、ファイルの関連部分のプレフィックスを指すことができ、関連部分は、「プレフィックス」が使用される文脈から推測することができることに留意されたい。
サブブロックが使用されない場合、ソースブロックの連続的なソースシンボルを求める要求は、連続的なバイトの系列を求める要求に変換することができる。サブブロックが使用される場合、サブブロックの連続的な多数のソースサブシンボルを求める要求は、ファイルの連続的なバイトの系列を求める要求に変換することができる。
本明細書で説明されるように、ＵＥは、サブブロックの連続的な多数のソースサブシンボルを求める要求から、ファイルにおけるバイト範囲要求を導出することができる。
いくつかの実施では、異なるブロードキャストサーバは、おそらく異なる地理に基づいた、異なる数組の修復シンボルを有する。これは、ブロードキャスト送信中に１つの地理から別の地理にＵＥが移動する場合、同じデバイスにおいて重複受信が起こらないことを保証するために有益である。
ＵＥは、ブロードキャストセッションでどの修復サブシンボル（サブブロックが使用されない場合はシンボル。この補足説明は以下同様に適用される）を受信したかにはほとんど無関係に、ブロードキャストセッションでいくつの修復シンボルを受信したかにのみ応じて、ＨＴＴＰ要求でソースブロック（またはサブブロックが使用されない場合はブロック）のバイト範囲プレフィックスを要求する。ＩＥＴＦ ＲＦＣ ５５１０において仕様化されているリード−ソロモン符号など、いくつかの符号の場合、要求されるバイト範囲プレフィックスは、ブロードキャストセッションでどの修復シンボルが受信されたかには完全に無関係とすることができる。ＩＥＴＦ ＲＦＣ ６３３０において仕様化されているＲａｐｔｏｒＱ符号など、他の符号の場合、バイト範囲プレフィックスのサイズは、ブロードキャストセッションでどの修復シンボルが受信されたかにわずかに依存し得る。たとえば、ソースサブブロック内にＫ個のソースサブシンボルが存在し、そのサブブロックのためにＫ−Ｌ個の修復ソースシンボルが受信される場合、最初のＬ個のソースサブシンボルに対応するバイト範囲プレフィックスの要求は、少なくとも９９％の確率で復号を可能にし、Ｌ＋１個のサブシンボルの要求は、少なくとも９９．９９％の確率で復号を可能にし、Ｌ＋２個のサブシンボルの要求は、少なくとも９９．９９９９％の確率で復号を可能にする。復号が可能かどうかは、復号のために使用されるサブシンボルのパターンに依存し、受信機デバイスは、要求を行う前に、受信されたサブシンボルの特定の系列が復号を可能にするかどうかを決定し、したがって、復号を保証するために、どの要求を行うべきかを決定する。したがって、修復のために要求されるプレフィックスのサイズは、ブロードキャストセッションで受信されたサブシンボルのパターンにわずかに依存し得る。
しかし、簡潔にするために、受信機デバイスは、単にＬ＋２個のサブシンボルを求める要求を行うことができ、その場合、要求サイズは、潜在的に２つの冗長なサブシンボルを受信するオーバヘッドが生じる代償、すなわち、Ｋ個のソースサブシンボルを回復するために、ブロードキャストセッションからのＫ−Ｌ個のサブシンボルと、修復要求からのＬ＋２個のサブシンボルの、合計でＫ＋２個のサブシンボルを受信する代償、および非常に小さい確率ながら復号に失敗する可能性がある代償を払うことで、ブロードキャストセッションでどのサブシンボルが受信されたかには無関係である。要求のサイズおよびパターンを、どのデータが受信されたかには無関係にし、ブロードキャストセッションでどれだけのデータが受信されたかにのみ依存させる、いくつかの理由は、次のものを含む。
（ａ）ＵＥ要求を単純にすることができ、常に、ソースサブブロック（ブロック）の先頭から、ソースサブブロック（ブロック）当たり高々１つのバイト範囲要求を行うことができる（場合によっては、ブロードキャストセッションで十分な修復サブシンボル（シンボル）が受信された場合、追加のＨＴＴＰ要求は必要とされない）。
（ｂ）ＵＥは、修復サーバからＨＴＴＰを介してダウンロードを行いながら、サブブロック（ブロック）のコンテンツのプレイアウトを開始することができ、次いで、十分なものをダウンロードしたら、ＵＥは、サブブロックの残りの部分を回復するために、ブロードキャストを介してすでに受信された修復サブシンボルを使用することができる（残りのサブブロック（ブロック）のサイズは、基本的には、ブロードキャストセッションで受信されたサブブロック（ブロック）のための修復サブシンボル（シンボル）のサイズである）。
受信機は、ブロードキャストを介して修復データを受信するのと並行して、同時にコンテンツを再生しようと試み、ブロードキャストを介して受信されたものと組合された場合に、サブブロックの残りの部分を復号および回復するのに十分になるまで、ＨＴＴＰを介して各サブブロックのために十分なものをダウンロードする場合さえもあり得る。この場合、ブロードキャストが継続しており、ＵＥがブロードキャストを介して受信する、すべてのサブブロック（ブロック）のための修復サブシンボル（シンボル）は、次第に多くなっていくので、各サブブロック（ブロック）のために必要とされるＨＴＴＰダウンロードされる量は、次第に少なくなる。
（ｃ）ＵＥはソースサブブロックのプレフィックスを要求するので、ファイルの部分を求めるＵＥ要求間の重複は、可能な限り高くなり、たとえば、ソースサブブロック（ブロック）のための修復サブシンボル（シンボル）を同量受信する２つのＵＥは、各々が受信する修復シンボルのパターンが独立で、完全に異なることができる場合であっても、そのソースサブブロック（ソースブロック）を求める正確に同じバイト範囲要求を行う。
異なるＵＥが、ブロードキャストセッションからサブブロックのための異なる数の修復サブシンボルを受信する場合、最も少量の修復サブシンボルを受信するＵＥが、一般に、ソースサブブロックを求める最大のプレフィックスバイト範囲要求を行い、他のＵＥからのすべての要求は、この要求のサブセットである。したがって、ＨＴＴＰサーバが、１つのＵＥのために、サブブロック（ブロック）を求めるバイト範囲要求をすでにフェッチし、サービスしている場合、ＨＴＴＰサーバは、この応答をキャッシュし、同じサブブロック（ブロック）を求める修復要求を行う次のＵＥのために、それを利用可能にすることができる。ＨＴＴＰキャッシングサーバは、ＵＥによって要求されるよりも大きいバイト範囲を、先を見越して上流サーバに要求することができ、したがって、現在の要求を超えるデータの部分を求めるさらなる要求が同じまたは異なるＵＥから行われた場合、要求のサイズを超えるデータが利用可能であるまで時間を短縮する。したがって、１つのＵＥが、ファイルの関連部分からのデータのプレフィックスを求める要求を行った場合、後続のＵＥが、ファイルの同じ関連部分からのデータのより大きいプレフィックスを求める要求を行うとき、ＨＴＴＰキャッシングサーバは、キャッシュされたそれをすでに有していることがあり、データの対応するプレフィックスを用いて、その要求に直ちに応答できることがある。
ＨＴＴＰ修復サーバが、重複するバイト範囲を求める、たとえば、何らかの閾値を超える、複数の要求を受信した場合、サーバは、これらの受信機へのユニキャストチャネルに冗長に負荷をかけることを回避するために、要求をＢＭＳＣに転送して、このバイト範囲のデータのブロードキャストを要求することに決定するように構成することもできる。修復サーバは、ＢＭＳＣによってブロードキャストされないソースデータを、各受信機にユニキャストしさえすればよい。ＢＭＳＣは、バイト範囲要求を、要求された必要なソースシンボルに変換することができ、次いで、これらのソースシンボルをブロードキャストすること、またはより好ましくは、これらの多くの新しい修復シンボルをブロードキャストすることができる。これは、端末が、ユニキャストチャネルにあまり負荷をかけずに、ファイルを修復するために、十分な非冗長シンボルを受信することを可能にする。
場合によっては、ＵＥが、ソースブロック（サブブロック）に関連するコンテンツを再生する、すなわち、要求を行うために「ストリーミングモード」を使用する準備を整えている場合、ＵＥが、そのソースブロック（サブブロック）のためのソースシンボル（サブシンボル）を求めるユニキャスト要求のみを行うことが有利である。１つの理由は、実際に再生するコンテンツのための修復データのみをＵＥが要求し、何らかの理由で、コンテンツの一部を決して再生しない場合、ＵＥがそのブロック（サブブロック）のためのデータを要求して、ユニキャストネットワークリソースを浪費することが決してないことである。
たとえば、ＵＥは、コンテンツ（ファイル）の再生を中間から開始し、コンテンツの４分の１だけ再生することができる。この例では、再生が差し迫っているときにのみ要求を行うことで、再生前にコンテンツファイル全体を回復するためにユニキャスト修復要求が行われた場合に必要とされる量の約４分の１まで、ユニキャストネットワークリソースが減少する。もちろん、ソースブロック（サブブロック）のための十分なシンボル（サブシンボル）が受信された後は、ＵＥがソースブロック（サブブロック）のための追加データをユニキャスト修復サーバに要求する必要はまったくない。
システム運営者は、これらの手法から利益を得ることができる。たとえば、ユニキャスト修復サーバの配備は、簡略化することができ、コストをはるかにわずかにすることができる。専門の修復サーバを購入し、配備し、運用する必要もなくなり、代わりに、配備および管理がはるかに安価かつ容易なＨＴＴＰウェブサーバに依存する。別の例として、運営者は、インターネットコンテンツファイルが透過的に獲得され、それらのためのＦＥＣ修復データがＵＥにブロードキャストされる、サービスを展開することができ、その場合、ＵＥは、それらのブロードキャストされた受信されたＦＥＣ修復データを使用し、ブロードキャストを介して受信されたＦＥＣ修復データと組み合わせて、ＵＥが再生しようとするファイルの部分を回復することを可能にするには、どのようなＨＴＴＰ１．１バイト範囲要求を行うべきかを決定し、（運営者が必ずしも運用しているとは限らず、運営者が必ずしもコンテンツの出所とは限らない）既存のＣＤＮにすでにキャッシュされていることがあるインターネット利用可能なコンテンツファイルの部分を求める適切なＨＴＴＰ１．１バイト範囲要求を、インターネットを介して行うための方法を含む。
そうすることによって、運営者は、（ファイルははるかに高い信頼性で、はるかに迅速に利用可能であるので）より良好なユーザエクスペリエンスを提供する価値あるサービスを提供することができ、同時に、（ブロードキャストデータは、すべてのＵＥに有益であり、多くの個別のユニキャスト接続を介して各個別ＵＥにデータを送信するよりもわずかなネットワークリソースしか送信に費やさないので）ファイルを配送するのに必要とされる、ネットワーク上の全体的なネットワークトラフィックの量を低減させ、同時に、コンテンツは他者によって提供される標準的なＨＴＴＰウェブサーバにおいてすでに利用可能であり、これがユニキャスト修復をサポートするために使用されるものであるので、運営者は、サービスをサポートするためにユニキャスト修復サーバを配備するコストを回避することができる。
システム運営者は、既存のＨＴＴＰウェブサーバを目的付けし直し、ＨＴＴＰウェブサーバを介して他のコンテンツプロバイダからＵＥに配送されるファイルのための修復シンボルを傍受し、ブロードキャストするなどの、新しいサービス機会を生み出すこともできる。
加えて、この手法は、運営者のネットワークの帯域幅容量を節約することができる。コストは、ネットワークを介して送信されるブロードキャストデータの量であり、一方、利益は、そのＵＥによって受信されたブロードキャストデータの量のコンテンツを再生する、すべてのＵＥにわたる総和である。これは、コンテンツのより迅速で、より信頼性の高い配送ばかりでなく、運営者ネットワークにおけるより良好なユーザエクスペリエンスを提供することもできる。
セッション記述、およびＭＢＭＳダウンロード配送プロトコル、ＦＬＵＴＥは、各ファイルのソースブロックおよび符号化シンボル構造を決定するための十分な情報を、クライアント（すなわち、ＵＥ）に提供する。これから、クライアントは、ファイルを回復するために、どのソースシンボルを要求し、使用できるかを決定することができる。したがって、ＭＢＭＳクライアントは、（ファイルの）ソースブロックの再構成を完了するのに必要とされるソースシンボルの数を識別することができる。
３ＧＰＰ ＴＳ ２６．３４６において仕様化されているＭＢＭＳ ＦＥＣ方式が使用される場合、ＭＢＭＳクライアントは、必要とされるさらなるソースシンボルを決定するときに、すでに受信された修復シンボルを考慮することができる。この場合、クライアントは、（ファイルの）各ソースブロックについて、数ｒを識別し、ＭＢＭＳ ＦＥＣ復号器がファイルを回復することを可能にする、ソースブロックの最初のｒ個のソースシンボルを求める要求を行うべきである。
失われたファイルデータが識別されると、ＭＢＭＳクライアントは、失われたファイルデータの回復を可能にするデータの送信を要求する１つまたは複数のメッセージを、ファイル修復サーバに送信する。特定のＭＢＭＳ送信についてのすべてのファイル修復要求および修復応答は、ＨＴＴＰプロトコルを使用して、単一のＴＣＰセッションにおいて行うことができる。代替として、バイト範囲要求は、異なる潜在的に重複するＨＴＴＰ／ＴＣＰ接続、またはＦＴＰ接続、またはＲＴＰ接続などを介する複数の要求に分割することができる。修復要求に対する応答は、ネットワーク利用可能性、ならびに受信デバイスがどれだけビジーであるか、および受信デバイスの能力に応じて、非常に遅いまたは高いビットレートで配送することができる。修復要求は、選択された「ｓｅｒｖｉｃｅＵＲＩ」から解決される、ファイル修復サーバＩＰアドレスに転送することができる。特定のＭＢＭＳクライアントの、サーバとのＴＣＰ接続のオープン、および最初の修復要求は、すべてのＵＥが同時にユニキャスト要求を行わないように、時間窓にわたってランダム化することができる。
ＭＢＭＳ ＵＥが、修復要求で要求されるシンボルを識別した場合、応答は、そのように識別された対応するシンボルであり、要求内で識別された関連ソースブロックからのすべてのシンボルを含むべきである。ＭＢＭＳ ＵＥは、サブブロックが使用される場合は、代わりに、ソースサブブロックのサブシンボルを求める要求を行うことができる。代替として、本明細書で説明されるように、シンボルまたはサブシンボルを要求するために、バイト範囲要求を行うことができる。
ＭＢＭＳ ＵＥは、これを他の方法と組み合わせることができる。たとえば、ＭＢＭＳ ＵＥは、Ｌｕｂｙ ＶＩで説明されているように、ブロードキャストセッションでデータを受信し、インターリーブ解除または復号を行って元のソースファイルに戻さずに、それを長期ストレージ内に記憶することができる。ＭＢＭＳ ＵＥは、元のソースファイルの部分のインターリーブ解除および復号を、たとえば、ソースファイルがビデオファイルである場合は、ソースファイルのそれらの部分を再生するためにエンドユーザが行う要求に応答して、トリガすることができる。ＭＢＭＳ ＵＥが、再生のために要求されている元のソースファイルの部分を回復するのに十分なデータを、ブロードキャストセッションから受信していない場合、ＭＢＭＳ ＵＥは、エンドユーザが再生を要求しているソースファイルの関連部分を求める本明細書で説明されるような修復要求を行うことができる。したがって、ＭＢＭＳ ＵＥは、あるサブブロックまたはソースブロックのための追加データを受信するための要求だけを、それらを回復するのに十分なデータがブロードキャストセッションで受信されていない場合に限って、行うことができ、要求は、それらのサブブロックまたはソースブロックと交わるソースファイルの部分の再生をエンドユーザが望むときに、または望むときの近くでもっぱら行われる。この実施形態は、エンドユーザがソースファイルの部分の再生を要求するときに、それらの部分のための修復データのみが要求され、したがって、ファイルの部分が再生されない場合は、それらの部分のための修復要求は行われないので、ネットワークリソースを最低限に抑える。さらに、この実施形態は、サブブロックまたはソースブロックを回復するために、長期ストレージからデータを読み込み、インターリーブ解除および復号を行うのに必要とされるデバイスリソースを、これらの動作は、エンドユーザがソースファイルのこれらの部分の再生を要求した場合に限って実行されるので、最低限に抑える。
代替として、ＭＢＭＳ ＵＥは、修復要求を行うための適切なネットワーク接続およびアイドル容量を有するときに、回復に十分なデータがブロードキャストセッションから受信されていないサブブロックまたはソースブロックのための修復要求を行い、次いで、これらのサブブロックまたはソースブロックのためのブロードキャストセッションから受信されたデータに加えて、応答データを、サブブロックまたはソースブロックを後で回復するために、長期ストレージ内に記憶することができる。ユーザが、元のファイルの部分の再生を要求する場合、ＭＢＭＳ ＵＥは、ユーザによって要求されるファイルの部分と交わる、ブロードキャストセッションから受信されたインターリーブおよび符号化されたデータと、サブブロックまたはソースブロックのための修復要求から受信されたインターリーブおよび符号化されたデータの組合せを、長期ストレージから読み出し、それらのサブブロックまたはソースブロックを回復し、再生のためにそれらを直接的にビデオプレーヤに提供することができる。この代替は、ＭＢＭＳ ＵＥが、修復要求を行い、応答を受信するのに適したネットワークに接続されているときに、修復データを要求することができ、ユーザが再生を要求したときには、ＭＢＭＳ ＵＥが適切なネットワークに接続されていなくてもよいという利点を有する。さらに、再生のために必要とされるすべてのデータが、ユーザ要求時には、ネットワークを介する配送を必要とする代わりに、デバイス上にローカルに記憶されているので、再生を求めるユーザ要求に対する再生応答時間をより短くすることができる。
別の代替として、ＭＢＭＳ ＵＥは、回復のために追加データが必要とされるサブブロックまたはソースブロックのすべてのための修復データを要求し、ファイルのすべてを回復し、それを、後で再生および使用するために長期ストレージ内に記憶することができる。ＭＢＭＳ ＵＥは、任意の時点に任意の順序で、これらの動作を実行することができ、すなわち、場合によっては、たとえば、ファイルのサブブロックもしくはソースブロックを完全に回復するのに十分なデータがブロードキャストセッションを介して送信されないことがわかっている場合、またはたとえば、ブロードキャストセッションが終了する前に（潜在的にはブロードキャストセッションが開始する前に）エンドユーザがコンテンツ再生の開始を望む場合、ブロードキャストセッションからデータを受信する前に、修復データを要求することができる。
いくつかの実施形態では、ＦＥＣを実行しない（したがって、すべてのソースシンボルを望み、修復シンボルを望まない）ＵＥが存在する。そのような場合、ＵＥは、「ノーコードＦＥＣ（Ｎｏ−ｃｏｄｅ ＦＥＣ）」を使用し、ブロードキャストセッションおよびいずれかの修復要求応答でソースシンボルを受信するが、これは、多くの異なるＵＥが異なるロスパターンを経験し、そのため、異なるソースシンボル修復要求を行うほど、スケーラブルではないことがある。
いくつかの実施形態では、修復ブロードキャストセッションは、ＵＥにおいて、Ｌｕｂｙ ＶＩで説明されているような、ブロードキャストデータの部分的な並べ替えを使用する。その場合、上で説明されたようなＨＴＴＰを使用するユニキャスト修復サービスの組合せを、Ｌｕｂｙ ＶＩで説明されている方法と組み合わせることができる。ブロードキャスト送信で受信されたシンボル／サブシンボルは、Ｌｕｂｙ ＶＩで説明されているように、フラッシュまたは他のメモリに記憶することができる。場合によっては、ブロードキャストセッションで、修復シンボルのみを送信するのが好ましいが、他の場合は、ブロードキャストセッションで、すべてではないとしても、少なくともいくつかのソースシンボルを送信するのが好ましい。シンボルまたはサブシンボルが、修復サービスにおいて、バイト範囲要求または他のＭＢＭＳ方法を用い、ＨＴＴＰを介して要求される場合、２つの異なる可能性が生じる（両方を同時に使用することができる）。
（１）Ｌｕｂｙ ＶＩで説明されている方法は、ブロードキャストセッションから受信されたシンボルまたはサブシンボルをフラッシュメモリに書き込むために使用することができ、ソースブロックまたはサブブロックが回復される場合、Ｌｕｂｙ ＶＩで説明されている方法は、ブロードキャストセッションからのフラッシュメモリ内に記憶されたソースブロックまたはサブブロックのためのシンボルまたはサブシンボルをＲＡＭに読み込むために使用することができる。これらは、次いで、ＨＴＴＰを介して受信され、ＲＡＭに直接的に記憶された、シンボルまたはサブシンボルと組み合わせることができ、ソースブロックまたはサブブロックは、これらのシンボルまたはサブシンボルの組合せを使用して、ＲＡＭ内で復号され、次いで、回復されたソースブロックまたはサブブロックは、再生のために直接的に提供することができる。
（２）Ｌｕｂｙ ＶＩで説明されているいくつかの方法は、ブロードキャストセッションを介して受信されたシンボルまたはサブシンボルと同様に、ＨＴＴＰを介して受信されたシンボルまたはサブシンボルをフラッシュメモリに書き込むために使用することができ、次いで、任意の時点で、ソースブロックまたはサブブロックは、ＨＴＴＰ要求と、ブロードキャストセッションからのフラッシュメモリ内に記憶されたソースブロックまたはサブブロックのためのシンボルまたはサブシンボルとに基づいて、フラッシュメモリ内に記憶されたソースブロックまたはサブブロックのためのシンボルまたはサブシンボルの組合せをフラッシュメモリからＲＡＭに読み込むことによって、オンザフライ（ｏｎ ｔｈｅ ｆｌｙ）で回復することができる。
上述の実施形態では、好ましくは、ブロードキャストセッションを介して受信されたシンボルまたはサブシンボルと、修復セッションにおいて受信されたシンボルまたはサブシンボルとは、シンボルまたはサブシンボルからなる大きく異なる組である。
図２２は、基本的ＦＬＵＴＥファイル配送を図示する。ＦＥＣペイロードＩＤは、代わりに、本明細書で説明されるＵＯＳＩまたはＵＯＦＩを備えることができることに留意されたい。
図２３は、基本的ＦＬＵＴＥパケット形式のいくつかの部分を図示する。
図２４は、サブブロックを使用する送信機において行われるサブブロック符号化を図示する。図２４に示されるように、ファイルは、１つまたは複数（この例では１つ）のソースブロックとして組織し、サブブロックに分割することができ、サブブロックは、サブシンボルからシンボルを形成するように配置される。
図２５は、サブブロックを使用する受信機において行われるサブブロック復号を図示する。場合によっては、受信機における記憶の前に、部分的な並べ替えが存在する。これは、たとえば、記憶要素において読み込みと書き込みとの間に非対称性が存在する場合に、有益なことがある。
図２６は、サブブロックを使用するファイル配送を図示する。典型的な場合、受信機は、各サブブロック内で同じロスパターンを見る。転送の観点からは、ファイルは、１つのソースブロックとすることができ、各パケットは、１つのシンボルを含むことができる。復号の観点からは、復号動作のスケジュールは、すべてのサブブロックについて同じとすることができ、各サブブロックについて、サブシンボルのロスパターンまたは受信パターンは同じであり、受信機は、すべてのサブブロックのためのスケジュールを一度に計算する。復号動作のスケジュールが、次いで、各サブブロックに別々に適用され、サブシンボルに作用し、同じスケジュールをすべてのサブブロックに適用する。復号器のＣＰＵは、大きなソースブロックの操作でさえも少量のスクラッチＲＡＭメモリのみを使用して良好に実行することができ、メディアのサブブロックのアクセスおよび復号をそれらが再生されるときに可能にする。
図２７は、複数のソースブロックの処理の一例を図示する。場合によっては、良好なネットワーク効率のために、シンボルは、各ラウンドで各ソースブロックから１つのシンボルが送信される、ラウンドロビン方法で送信される。他の場合、より容易なクライアント回復またはエンドツーエンド待ち時間の理由で、シンボルは、順次的方法で送信され、すなわち、各ソースブロックごとに、すべてのシンボルが、他のソースブロックからのシンボルを間に点在させることなく、連続的なシーケンスで送信される。すべての場合で、サブブロックを使用することができる。
図２８は、ＦＥＣおよびＦＬＵＴＥを使用するワークフローを図示する。ステップ１において、ＦＬＵＴＥセッションで搬送されるファイルが定義される。ステップ２において、ファイルはブロックに分割することができる。分割が必要かどうかは、ＦＥＣ方式が処理できる最大サイズによって決定される。
ステップ３において、ＦＥＣがブロックに適用され、各ブロックは、Ｋ個の等しいサイズのシステマティックシンボルに分割され、Ｒ1＋Ｒ2個の修復ＦＥＣシンボルが生成される。ステップ４において、Ｋ＋Ｒ1個のシンボルが、ブロードキャスト送信上でＦＬＵＴＥを介して、または代替として、ＵＤＰを使用するユニキャストを介して、もしくはＨＴＴＰを使用するユニキャストを介して送信される。各ＩＰ／ＵＤＰ／ＬＣＴパケットが、シンボルサイズに応じて、１つまたは複数のシンボルを搬送する。ステップ５において、受信機は、ＦＥＣ復号のためにＫ＋δ個のシンボルが利用可能になるように、十分なパケットを収集する。いくつかの実施形態では、ＲａｐｔｏｒＱを使用し、δ＝２である。しかし、たとえば、δ＝０またはδ＝０．０１×Ｋなど、他の値も可能である。ステップ３において生成される追加のＲ2個のシンボルは、ステップ４における送信からＫ＋δ個のシンボルを受信しない受信機にＨＴＴＰベースの修復サービスを提供するために、ＨＴＴＰサーバに提供することができる。
図２９は、上で説明されたブロードキャスト／修復、ユニキャスト／ソース構成を図示する。多数の修復シンボルを生成することができる。ＵＥは、ＦＥＣ復号に成功するために、それらのシンボルのうちのＫ＋δ個を必要とする。示される実施形態では、各ブロードキャストＢＭ−ＳＣは、ファイルのＮ個の異なるＲａｐｔｏｒ修復シンボルを送信し、各ＢＭ−ＳＣは、修復シンボルのみを、すなわち、範囲｛Ｋ，Ｋ＋１，．．．｝内のＥＳＩを有するシンボルのみを送信する。
上述の実施形態の１つの利点は、ＵＥが異なるＢＭ−ＳＣのカバレージエリア間でローミングする場合、ＵＥが、シンボルの重複受信を心配することなく、異なるＢＭ−ＳＣからのシンボルを使用でき、より効率的なＦＥＣ復号を可能にすることである。ＵＥは、ソースシンボルのための単純な修復要求を行うことができるが（しかし、これは専門の修復要求サーバを必要とすることがある）、本明細書の別の箇所でより詳細に説明されたように、元のソースファイルのみを有する従来のＨＴＴＰウェブサーバを使用する、ＨＴＴＰバイト範囲要求も行うことができる。これは、よりコスト効率の良い、集中的なインターネット／ＭＢＭＳソリューションを可能にする。
図３０は、ＭＢＭＳベアラ上でシステムがどのように修復シンボルのみをブロードキャストするか、またＵＥがどのように連続する１組のソースシンボルのみを要求するかを図示する。ＵＥは、ソースブロックの復号に成功するために、一般にＫ＋δ個のシンボルを必要とするが、ＭＢＭＳベアラ上で受信される修復シンボルは、Ｋ＋δ−Ｒ個だけである。ソースブロックを回復するために、ＵＥは、ソースブロックの最初のＲ個（またはＲ＞Ｋの場合はＫ個）のソースシンボルを要求する。ＵＥは、他の何らかのＲ個のソースシンボルを要求することができるが、すべてのＵＥが重複する数組のソースシンボルを要求する場合、下流のキャッシュが、要求されたソースシンボルをローカルキャッシュからほとんどの受信機に配送できる可能性がより高くなる。
これは、修復サーバにおける単純で効率的なキャッシングを可能にする。修復シンボルのみがブロードキャストチャネルを介して送信されるので、ソースブロックのソースシンボルはすべて、ＵＥにおいてすでに受信されたシンボルとは異なる。したがって、修復サーバは、ソースブロックのソースシンボルを記憶しさえすればよく、新しい修復シンボルを記憶する、または生成する必要はない。これは、ＦＥＣ方式を実施する、または新しい修復シンボルを記憶する必要がない、より単純な修復サーバを可能にする。
受信されたシンボルのシンプルなＵＥ処理が可能である。ＵＥは、受信した修復シンボルの数を数えているだけでよく、次いで、必要とするソースシンボルの数を計算する（ＲがＫ以下の場合はＲ、ＲがＫよりも大きい場合はＫ）。ＵＥは、どの特定のソースシンボルが失われたかを追跡し、次いで、失われたソースシンボルのみを求める要求を生成する必要はない。
加えて、ＵＥは、初期ＥＳＩ＋（Ｒの値）を使用して、連続する１組のソースシンボルを修復サーバに要求することができる。これは、要求を非常に単純かつ短く保つ。分離した数組のソースシンボルをサーバが取り出し、追加する必要がないので、これは、応答のサーバ構成も簡略化することができる。サーバは連続的なソースシンボル要求を処理しさえすればよいので、これは、「ノーコード」ＦＥＣ方式を使用しない配備において特に有利であり得る。
図３１は、サブブロックが使用される場合の、ＨＴＴＰバイト範囲要求を介するユニキャスト修復の使用を図示する。
ＨＴＴＰバイト範囲修復要求を用いて、ＵＥは、同じソースブロックの各サブブロックごとに同じ数のバイトを要求することができる。各サブブロックのバイト範囲を求める１つの要求は、ブロードキャストセッションでソースシンボルが送信されないほとんどの環境において使用することができる。
ＨＴＴＰ要求は、「必要に応じて」行うことができる。ＵＥは、そのサブブロック内のコンテンツを再生する時間になったときに、各サブブロックを求める要求を行うことができる。ＵＥは、サブブロックを復号および回復するのに、ブロードキャストセッションなどの他の転送を介して受信されたサブシンボルと組み合わせて、十分なサブシンボルが得られるまで、ＨＴＴＰを介してサブブロックを求める要求を行い、サブブロックのコンテンツを再生することができる。十分なサブシンボルが受信され、復号されると、ＵＥは、ローカルで回復されたサブブロックからシームレスに再生を継続することができる。ＵＥは、再生されないサブブロックを求めるＨＴＴＰ要求を行う必要はない。
バイト範囲計算の例
受信機は、どのバイト範囲を要求すべきかを決定するために、このセクションで説明される計算を実行することができる。計算は、ＦＥＣ構造に依存することができる。受信機は、次いで、バイト範囲要求に基づいて、受信機が必要とするシンボルを獲得するために、サーバに要求を送信することができる。
好ましい一実施形態では、受信機は、どのシンボルを受信機が受信していないかを認識するために、ＦＥＣオブジェクト送信情報（「ＦＥＣ ＯＴＩ」）を使用する。ＦＥＣ ＯＴＩは、ファイルのソースブロック、サブブロック、シンボル、およびサブシンボル構造を決定し、オブジェクト転送サイズＦ、アライメントファクタＡｌ、シンボルサイズＴ、ソースブロックの数Ｚ、およびソースブロック当たりのサブブロックの数Ｎを備える。受信機は、正確にいくつの、どのシンボルを受信機が必要としているかを決定するために、この情報のすべてをＦＥＣ符号自体の特性と一緒に使用し、各シンボルまたはサブシンボルは、ＳＢＮ、ＥＳＩ、およびＳｕＢＮ（それぞれ、ソースブロック番号、符号化シンボル識別子、サブブロック番号）によって識別される。この実施形態では、ソースシンボルまたはソースサブシンボルが要求される。受信機は、次に説明されるように、これらのシンボルまたはサブシンボルに対応するファイル内のバイト範囲を計算するために、ＦＥＣ ＯＴＩ情報を使用する。
サブブロックが使用されない場合（すなわち、Ｎ＝１である場合）、与えられたＳＢＮおよびＥＳＩに対して、受信機は、（ＳＢＮ，ＥＳＩ）ペアによって識別される対応するソースシンボルの、ファイル内の開始バイト番号および終了バイト番号を計算することができる。
計算プロセスが今から説明される。これは、受信機内のプログラム、または受信機内のロジックによって行うことができる。ＫＴ＝ｃｅｉｌ（Ｆ／Ｔ）をファイル内のソースシンボルの数とする（最も近い整数に切り上げられ、その場合、最後のソースシンボルは、完全なソースシンボルになるまでゼロでパディングされたものと考えることができる）。
ＫＬ＝ｃｅｉｌ（ＫＴ／Ｚ）、ＫＳ＝ｆｌｏｏｒ（ＫＴ／Ｚ）、ＺＬ＝ＫＴ−ＫＳ×Ｚ、ＺＳ＝Ｚ−ＺＬとし、ここで、ＫＬは、最初のＺＬ個のソースブロック内のソースシンボルの数であり、ＫＳは、残りのＺＳ個のソースブロック内のソースシンボルの数である。
各ｉ＝０、．．．、Ｚ−１について、Ｋiをソースブロックｉ内のソースシンボルの数とし、すなわち、ｉ＝０、．．．、ＺＬ−１については、Ｋi＝ＫＬであり、ｉ＝ＺＬ、．．．、Ｚ−１については、Ｋi＝ＫＳである。
次いで、ＳＢＮおよびＥＳＩによって識別されるシンボルに関連する開始バイトを、式２として計算することができる。このサブシンボルの終了バイト位置は、開始バイト位置にＴ−１を加算することによって計算することができる。
Figure 2014533045
サブブロックが使用される場合（すなわち、Ｎ＞１である場合）、与えられたＳＢＮ、ＳｕＢＮ、およびＥＳＩに対して、受信機は、３つ組（ＳＢＮ，ＳｕＢＮ，ＥＳＩ）によって識別される対応するソースサブシンボルの、ファイル内の開始バイト番号および終了バイト番号を計算することができる。ＫＴ、ＫＬ、ＫＳ、ＺＬ、ＺＳ、およびｉ＝０、．．．、Ｚ−１についてのＫiについての計算は、サブブロックが使用されない場合（Ｎ＝１）の計算と同じとすることができる。
サブブロックバイト位置を識別するための追加計算は、以下のように実行することができる。
ＴＬ＝ｃｅｉｌ（Ｔ／（Ｎ×Ａｌ）、ＴＳ＝ｆｌｏｏｒ（Ｔ／（Ｎ×Ａｌ））、ＮＬ＝Ｔ／Ａｌ−ＴＳ×Ｎ、ＮＳ＝Ｎ−ＮＬとし、ここで、ＴＬ×Ａｌは、最初のＮＬ個のサブブロック内のサブシンボルのサイズであり、ＴＳ×Ａｌは、残りのＮＳ個のサブブロック内のサブシンボルのサイズである。
各ｊ＝０、．．．、Ｎ−１について、Ｔjをサブブロックｊのサブシンボルのサイズとし、すなわち、ｊ＝０、．．．、ＮＬ−１については、Ｔj＝ＴＬ×Ａｌであり、ｊ＝ＮＬ、．．．、Ｎ−１については、Ｔj＝ＴＳ×Ａｌである。
次いで、ＳＢＮ、ＥＳＩおよび、ＳｕＢＮによって識別されるシンボルに関連する開始バイトを、式３として計算することができる。このサブシンボルの終了バイト位置は、開始バイト位置にＴSuBN−１を加算することによって計算することができる。
Figure 2014533045
要求されたシンボルまたはサブシンボルの開始バイト位置および終了バイト位置についてのこれらの計算に基づいて、受信機は、サーバに送信する必要があるバイト範囲要求を決定することができる。連続的に失われたシンボルまたはサブシンボルが存在する場合、受信機は、最初の失われたシンボルまたはサブシンボルの開始バイト位置からバイト範囲要求を開始し、最後の失われたシンボルまたはサブシンボルの終了バイト位置で範囲を終了することができる。
サブブロックが使用される場合に、上述の計算がどのように行われるかを説明するために、受信機が、ブロードキャストダウンロードセッションを有し、オブジェクトサイズＦ＝２０００００００バイト、アライメントファクタＡｌ＝４バイト、シンボルサイズＴ＝１３２０バイト、ソースブロックの数Ｚ＝２、およびソースブロック当たりのサブブロックの数Ｎ＝１２であるＦＥＣ ＯＴＩを用いて配送される、ＵＲＩがｗｗｗ．＜ｍｏｂｉｌｅ−ｏｐｅｒａｔｏｒ＞．ｃｏｍ／ｎｅｗｓ／ｗｅａｔｈｅｒ．３ｇｐの３ｇｐファイルを獲得しようと試みていると仮定する。この例では、ファイル内のソースシンボルの総数は、ＫＴ＝１５１５２であり、第１のソースブロックは、ＳＢＮ＝０であり、第２のソースブロックは、ＳＢＮ＝１であり、各々が、７５７６個のソースシンボルを有する。この場合、各ソースブロックは、各々、さらに１２個のサブブロックに分割され、その各々は、７５７６個のサブシンボルを有し、最初の６個のサブブロックは、サイズが１１２バイトのサブシンボルを有し、残りの６個のサブブロックは、サイズが１０８バイトのサブシンボルを有する。ブロードキャストダウンロードセッションの後、受信機が、ＳＢＮ＝０である第１のソースブロックからのＥＳＩが１２〜２９の連続する１８個のソースシンボルと、ＳＢＮ＝１である第２のソースブロックからのＥＳＩが１２〜２９の連続する１８個のソースシンボルとを受信しておらず、これらのソースブロックを復号するために、これらのソースブロックの各々から、少なくともこれだけの数のさらなるシンボルが必要であることを認識したと仮定する。
ＳＢＮ＝０である第１のソースブロックの場合、ＥＳＩ＝１２のソースシンボル（１８個の失われたソースシンボルのうちの最初のもの）を構成する１２個のサブシンボルの開始バイト位置は、図３２に示されるように計算することができる。図３２は、ＥＳＩ＝２９のソースシンボル（１８個の失われたソースシンボルのうちの最後のもの）を構成する１２個のサブシンボルの終了バイト位置をどのように計算できるかも示している。
同様に、図３３は、ＳＢＮ＝１である第２のソースブロックの場合、ＥＳＩ＝１２のシンボルを構成する１２個のサブシンボルの開始バイト位置をどのように計算できるかを示している。図３３は、ＥＳＩ＝２９のソースシンボルを構成する１２個のサブシンボルの終了バイト位置をどのように計算すべきかも示している。
選択された修復サーバＵＲＩがｈｔｔｐ：／／ｍｂｍｓｒｅｐａｉｒ２．＜ｍｏｂｉｌｅ−ｏｐｅｒａｔｏｒ＞．ｃｏｍである場合、ＨＴＴＰ ＧＥＴ要求は、次のようになり得る。
Figure 2014533045
ヘッダ：統計収集
いくつかの実施形態では、コンテンツを求めて行われる様々な要求に統計が関連するので、統計が収集される。これらの統計は、たとえば、コンテンツのブロードキャストからいくつのファイルが完全には調達されていないかをシステム運営者が見分け得るために有益なことがある。これは、ユニキャスト方法で修復データを提供する修復サーバのためのＨＴＴＰログを単に見ることによって行うことができる。しかし、修復サーバが、（ブロードキャストシンボルの受信を試みず、または修復サーバをコンテンツのための１次ＨＴＴＰソースと単に見ているデバイスからの要求などに対する）コンテンツのための直接的なソースとしての役割も果たしている場合、統計は、要求を過大にカウントする。システム運営者は、デバイス自体に、ブロードキャスト／ユニキャスト統計を報告させること（およびユニキャスト限定の要求を報告させないこと）ができるが、これはデバイスに依存し、それは煩雑であり得る。１つのソリューションでは、ＨＴＴＰ修復サーバは、統計を収集し、ブロードキャスト紛失が原因で修復データを求める要求と、コンテンツを求める直接的なユニキャスト要求である要求とを区別することができる。
１つの特定の手法では、修復サーバは、要求のタイプ（修復要求か、直接要求か）、およびどの端末が要求を行っているかを決定する。第１の部分は、ブロードキャストチャネルを介して受信されたファイルを修復するためのものである、それが受信しているＨＴＴＰ要求と、端末がユニキャストを介して受信したファイルを単に要求または修復する、端末からの要求とを区別する。端末識別は、サーバが、同じ端末からの要求を対応付け、各端末に詳細な受信統計を提供することも可能にする。これは、２重カウントを減らすために、および修復パターンをよりよく対応付けるためにも有益なことがある。
タイプおよび端末を決定するためのサーバのこの能力を実施するために、これを行ういくつかの方法が存在する。
サーバＵＲＬまたはファイルのＵＲＬは、直接的なユニキャストタイプの要求から区別するために、修復タイプ要求に固有とすることができる。たとえば、これらのＵＲＬは、ブロードキャストサービスの関連配送手順、またはブロードキャストされるファイルのファイル配送テーブルでのみ提供することができる。これらのＵＲＬは、ブロードキャストされなかったファイルを直接的にダウンロードするために、端末に提供されることはない。サーバは、特定のＵＲＬへの要求がブロードキャストされたファイルを修復するためのものであると決定し、これらの要求に基づいて修復統計を収集することができる。同じ端末からの要求を識別するために、サーバは、ＨＴＴＰ ＧＥＴ要求のソースＩＰアドレスを使用することができる。
サーバは、どの端末が要求を行っているかを識別するために、端末のＩＰアドレスを使用することができる。どのＩＰアドレスがブロードキャスト端末に属するかをＨＴＴＰサーバが知っている場合、サーバは、要求がブロードキャスト端末から来ているかどうかを判定するために、ＩＰアドレスを使用することもできる。ブロードキャストを介して受信しなかったファイルのためのデータを要求することを端末が許可されている場合、この手法は、ブロードキャスト統計を収集するためには、それほど信頼性が高くないことに留意されたい。そのため、これらのサーバに直接的にファイルを要求するブロードキャスト端末に、いくつかの制約が課されることがあり得る。
別の手法では、ＨＴＴＰサーバにデータを要求するために端末によって使用されるＨＴＴＰ ＧＥＴ要求に拡張を付加することができる。拡張は、要求がブロードキャストされたファイルを修復するためのものであることを識別する。拡張は、モバイルディレクトリ番号、または国際移動体加入者識別番号（ＩＭＳＩ）などの、端末の一意的ＩＤを識別することもできる。拡張ヘッダの別の例は、３ＧＰＰ ＴＳ ２４．１０９において定義されるような、「Ｘ−３ＧＰＰ向け識別情報拡張ヘッダ（Ｘ−３ＧＰＰ−Ｉｎｔｅｎｄｅｄ−Ｉｄｅｎｔｉｔｙ ｅｘｔｅｎｓｉｏｎ−ｈｅａｄｅｒ）」を使用することである。プライバシまたはセキュリティ目的で、運営者がこれらを暗号化せずに送信することを望まない場合、これらのＩＤにハッシュまたは暗号を適用することができる。
上述の手法のすべては、修復サーバのカスタマイズを必要とし、したがって、標準的なＨＴＴＰサーバの使用を困難にすることがあり得る。上述の手順のサーバサポートは、任意選択の機能とすることができる。そのように、ＵＥ（すなわち、端末）からの受信報告に依存することをいとわないシステム運営者は、依然として標準的なＨＴＴＰサーバを使用することができる。
ソースシンボルおよび修復シンボルの一般化された割り当て
上で説明された例では、コンテンツ配送システムは、ＵＥなどのクライアントと、ＭＢＭＳブロードキャストサーバおよび／またはＨＴＴＰサーバなどのサーバ、好ましくは、ＵＲＬファイル要求に加えて、バイト範囲要求もサポートするサーバとを備えることができる。その手法では、修復シンボルのみがブロードキャストされ、ソースシンボルのみがＨＴＴＰサーバへの要求を介して入手可能であることができる。しかし、より一般化された場合では、修復シンボルおよび／またはソースシンボルをブロードキャストすることができ、修復シンボルおよび／またはソースシンボルをＨＴＴＰサーバから入手可能とすることができる。
一例では、ＨＴＴＰサーバから入手可能なものの種類は、ＵＯＳＩ値（代替としてＵＯＦＩ値と呼ばれる）の範囲として表現され、および／または伝達される。ＵＯＳＩ値の範囲が、元のファイルに対応するＵＯＳＩ値と同じである場合、すなわち、Ｆをオクテット単位のファイルサイズ、Ｔをオクテット単位のシンボルサイズとし、ＵＯＳＩ値が０〜ｃｅｉｌ（Ｆ／Ｔ）−１である場合、ＨＴＴＰ修復サーバから入手可能であるのは、元の形式の、すなわち、オリジナル順ＨＴＴＰファイル形式の元のファイルである。ＵＯＳＩ値の範囲が、修復シンボルのＵＯＳＩ値、または修復シンボルとソースシンボルのＵＯＳＩ値にわたる場合、それらのシンボルは、「拡張オリジナル順ＨＴＴＰファイル形式」と呼ばれる、以下本明細書でさらに説明される、オリジナル順ＨＴＴＰファイル形式の自然な拡張である形式で、同じく入手可能である。これは、１つのタイプの要求が、様々なタイプのシンボルを処理し、それをシームレスに行うことを可能にする。たとえば、ＨＴＴＰサーバは、ＵＯＳＩ範囲の伝達または他の何らかの伝達だけによって、修復シンボルのみを有する修復ファイル、または修復シンボルとソースシンボルを有する修復ファイル（混合形式）と同じに、ソースシンボルのみを有する修復ファイルを扱うことができる。この方式は、サブブロックが使用される場合であっても、またブロックサイズがファイルの異なるソースブロックの間で可変である場合であっても機能することに留意されたい。
ＵＯＳＩ順のシンボルでは、ソースシンボルのみを含む修復ファイルは、０〜ＫＴ−１のＵＯＳＩ範囲を有し、ここで、ＫＴは、元のファイル内のソースシンボルの総数である。これは、伝達され得る範囲である。たとえば、ファイルが２０００００００バイトであり、シンボルサイズが１０００バイトである場合、ＫＴ＝２００００であり、したがって、［０，１９９９９］のＵＯＳＩ範囲の伝達は、（元のファイルのソースブロックの数とは無関係に）修復ファイルが元のソースファイルであり、すなわち、この場合の拡張オリジナル順ＨＴＴＰファイルは、オリジナル順ＨＴＴＰファイルと同じであることを示す。
代わりに、コンテンツ配送システムが、修復ファイルが修復シンボルのみを保有することを伝達することを望んだと仮定する。コンテンツ配送システムは、その場合、［２００００，Ｘ］のＵＯＳＩ範囲を使用することができ、ここで、Ｘは、２００００以上である。さらに、ＦＥＣオブジェクト送信情報（「ＯＴＩ」）で伝達されるように、このソースファイルがＺ＝１９個のソースブロックに分割され、したがって、最初の１２個のソースブロックは１０５３個のソースシンボルを有し、残りの７個のソースブロックは１０５２個のソースシンボルを有すると仮定する。次いで、修復ファイルが修復シンボルのみを保有すること、また各ソースブロックのための修復シンボルの数が、そのソースブロック内のソースシンボルの数よりも少なくとも３つ多いことを伝達するために、その場合は、ＵＯＳＩ範囲を［２００００，４００６３］と伝達することができ、すなわち、１９個のソースブロックの各々について修復ファイル内には１０５６個の修復シンボルが存在することを伝達する。
さらに、サブブロックが使用される場合、各サブブロックのサブシンボルは、各ソースブロック内で順番に並んでおり、すなわち、ソースブロックのための修復データ内では、第１のサブブロックのために１０５６個のサブシンボルが存在し、それに続いて、第２のサブブロックのために１０５６個のサブシンボルが存在し、以降も同様であり、すなわち、修復シンボルがソースブロックのための修復データ内で連続しており、したがって、元のソースファイル内のソースデータの組織と同じ組織を有することができるという必要はなく、すなわち、拡張オリジナル順ＨＴＴＰファイル形式は、オリジナル順ＨＴＴＰファイル形式の自然な拡張である。たとえば、１９個のソースブロックの各々が、Ｎ＝３個のサブブロックに分割され、サブブロックのためのサブシンボルサイズが、それぞれ、３３６、３３２、３３２オクテットであると仮定する。（Ｊ，Ｌ）をファイル内のサブブロックのための識別子とし、ここで、Ｊは、ソースブロック番号であり、Ｌは、ソースブロック内でのサブブロック番号である。その場合、ファイルは、サブブロック（０，０）のための、各サブシンボルのサイズが３３６バイトである、１０５６個のサブシンボルと、それに続く、サブブロック（０，１）のための、各サブシンボルのサイズが３３２バイトである、１０５６個のサブシンボルと、それに続く、サブブロック（０，２）のための、各サブシンボルのサイズが３３２バイトである、１０５６個のサブシンボルと、それに続く、サブブロック（１，０）のための、各サブシンボルのサイズが３３６バイトである、１０５６個のサブシンボルと、それに続く、サブブロック（１，１）のための、各サブシンボルのサイズが３３２バイトである、１０５６個のサブシンボルと、それに続く、サブブロック（１，２）のための、各サブシンボルのサイズが３３２バイトである、１０５６個のサブシンボルとを備え、以降も同様である。この例では、ソースブロックＪ＝０、．．．１１内のサブブロックは、１０５３のＥＳＩで開始し、２１０８のＥＳＩで終了し、ソースブロックＪ＝１２、．．．１８内のサブブロックは、１０５２のＥＳＩで開始し、２１０７のＥＳＩで終了する。
別の例として、ファイルを回復するために必要とされるデータのたかだか２０％を受信機が失っている場合に、ＨＴＴＰ修復サーバに修復データを求めるために戻ってくる受信をサポートするだけのサービスが意図されると仮定する。その場合、修復データを含む修復ファイルは、たとえば、［２００００，２４０２７］のＵＯＳＩ範囲に対応して、はるかに小さくすることができ、すなわち、修復ファイル内には、１９個のソースブロックの各々のために利用可能な２１２個の修復シンボルが存在する。この例では、最初の１１個のソースブロック内のサブブロックのためのサブシンボルのＥＳＩ範囲は、１０５３〜１２６４であり、残りの８個のソースブロック内のサブブロックのためのサブシンボルのＥＳＩ範囲は、１０５２〜１２６３である。
一般に、元のソースファイル形式は順次的であり、たとえば、データは、コンテンツの再生のためにファイルのバイトが先頭から末尾へと消費される順番で並んでおり、すなわち、それは、オリジナル順ＨＴＴＰファイル形式である。これは、ＨＴＴＰウェブサーバ上でのホスティング、配送、ファイルシステムへの記憶などのための自然な形式を含む、多くの理由で便利な形式である。これは、ｅＭＢＭＳによる配送か、それともユニキャストによる配送かにかかわらず、ソースファイルのための形式とすることができる。修復シンボルのみがｅＭＢＭＳチャネルを介して送信される場合、順次的形式のソースファイルの部分は送信されず、そのため、ＨＴＴＰウェブサーバへの要求は重複せず、有益な方法で、ｅＭＢＭＳを介して受信されたものと組み合わせて、ファイルを回復するために、ソースブロック（またはサブブロック）の連続的な初期部分を求める要求を行うことができる。
ｅＭＢＭＳチャネルを介してソースシンボルと修復シンボルの両方を受信機に送信することが望ましい場合、ＨＴＴＰウェブサーバ上に利用可能な元のソースファイルのみを有すると、同じように良好に機能しないことがあるが、それは、ソースファイルのいくつかの部分は、ｅＭＢＭＳを介してすでに受信されていることがあり、したがって、ソースファイルの部分を要求するためのＨＴＴＰウェブサーバへの要求パターンは、（ｅＭＢＭＳを介して受信された部分をスキップして）ソースファイルの多くの小さい部分を要求することになるからであり、したがって、潜在的に、ＨＴＴＰバイト範囲要求のボリュームに関してかなりの非効率性を生じさせ、ＨＴＴＰウェブサーバ内の非連続的なデータ部分にアクセスし、ｅＭＢＭＳチャネルから異なるパケットロスパターンを経験する異なる受信機から異なるデータを要求することによってキャッシング効率を低下させる。
本明細書で説明されるように、これは、自然な方法で、修復シンボルを含むように、または場合によっては、修復シンボルのみから成るように、元のソースファイルの形式を拡張する、拡張オリジナル順ＨＴＴＰファイル形式を使用することによって、解決することができる。この新しいファイル形式を使用することで、ファイルは、従来のＨＴＴＰウェブサーバ上で利用可能にすることができ、集中サービスを提供するために使用することができ、修復要求は、キャッシング効率が高くなり、ＨＴＴＰバイト範囲要求が、最低限に抑えられ、ｅＭＢＭＳセッションにおいて異なる受信機によって経験されるロスパターンとは無関係にファイル内の同じポイントから開始するデータの連続的な部分を求める要求となるように、ｅＭＢＭＳを介したソースシンボルと修復シンボルの両方の配送と組合されたバイト範囲要求を使用して、従来のＨＴＴＰウェブサーバに対して行うことができる
技法的に、ファイルＸは、関連するＦＥＣ ＯＴＩパラメータ（Ｆ，Ａｌ，Ｔ，Ｚ，Ｎ）を有することができる。拡張オリジナル順ＨＴＴＰファイル形式では、ファイル内のデータの範囲は、代替的にＵＯＦＩと呼ばれる、汎用オブジェクトシンボル識別子（「ＵＯＳＩ」）によって表すことができる。シンボルのＵＯＳＩは、シンボルのソースブロック番号（「ＳＢＮ」）と符号化シンボル識別子（「ＥＳＩ」）に対応し、すなわち、ＳＢＮがＡ、ＥＳＩがＢであるシンボルの場合、ＵＯＳＩは、Ｃ＝Ａ＋Ｂ×Ｚである。逆の対応付けは、ＵＯＳＩ値がＣのシンボルの場合、ＥＳＩ値は、Ｂ＝ｆｌｏｏｒ（Ｃ／Ｚ）であり、ＳＢＮは、Ａ＝Ｃ−Ｂ×Ｚである。ＵＯＳＩ範囲を伝達する際、範囲は、［ＳＵ，ＥＵ］の形式で表すことができ、ここで、ＳＵは、ファイルの開始ＵＯＳＩ値であり、ＥＵは、ファイルの終了ＵＯＳＩ値である。ＳＵはＥＵ以下であることに留意されたい。その場合、ファイル内に含まれるシンボルの範囲は、ＳＵからＥＵまでの範囲のＵＯＳＩを有するそれらのシンボルであり、したがって、ファイル内のシンボルの総数は、ＥＵ−ＳＵ＋１である。この新しいファイル形式の特殊な場合は、ＳＵ＝０、ＥＵ＝ｃｅｉｌ（Ｆ／Ｔ）−１となる場合であり、その場合、ファイルは、元のファイルと正確に同じであり、すなわち、この場合、拡張オリジナル順ＨＴＴＰファイル形式は、オリジナル順ＨＴＴＰファイル形式と一致する（ファイルサイズＦがシンボルサイズＴの倍数でない場合、法として、おそらくはゼロパディングを用いて最終シンボルをパディングする）。
そのようなファイルは、ＦＥＣ ＯＴＩパラメータを含むＵＲＬによって、ならびにファイル内のシンボルの開始ＵＯＳＩおよび終了ＵＯＳＩによって識別することができる。新しい拡張オリジナル順ＨＴＴＰファイル形式では、ファイル内のデータは、ＳＢＮ＝０のソースブロックのＥＳＩに関連するシンボルのすべてと、それに続く、ＳＢＮ＝１のソースブロックのＥＳＩに関連するすべてのシンボルから、以降も同様に、ＳＢＮ＝Ｚ−１のソースブロックのＥＳＩに関連するすべてのシンボルまでである。ソースブロック内は、サブブロック順に組織され、すなわち、ソースブロックの第１のサブブロックに関連するすべてのサブシンボルは、ＥＳＩの昇順に並び、次いで、ソースブロックの第２のサブブロックに関連するすべてのサブシンボルから、以降も同様に、ソースブロックの最後の第（Ｎ−１）のサブブロックに関連するすべてのサブシンボルまでが続く。
ＳＵ〜ＥＵのＵＯＳＩ範囲内にある、ＳＢＮ＝Ｊのソースブロック内のソースシンボルのＥＳＩは、次のように計算することができる。ＳＥＳＩ（Ｊ）を、ＵＯＳＩ範囲（ＳＵ，．．．，ＥＵ）内にあるシンボルの中でのソースブロックＪのための開始ＥＳＩとし、ＥＥＳＩ（Ｊ）を、ＵＯＳＩ範囲（ＳＵ，．．．，ＥＵ）内にあるシンボルの中でのソースブロックＪのための終了ＥＳＩとする。その場合、ＳＥＳＩ（Ｊ）は、次のように計算することができる。
Figure 2014533045
同様に、ＥＥＳＩ（Ｊ）は、次のように計算することができる。
Figure 2014533045
その場合、ＵＯＳＩ範囲（ＳＵ，．．．，ＥＵ）内にあるソースブロックＪに属するシンボルの総数は、ＮＫ（Ｊ）＝ＥＥＳＩ（Ｊ）−ＳＥＳＩ（Ｊ）＋１である。ファイルの異なるソースブロックについてのシンボルの数は、値の範囲（ＳＵ，ＥＵ）とは無関係に、互いの１つの中のすべて（ａｌｌ ｗｉｔｈｉｎ ｏｎｅ ｏｆ ｏｎｅ ａｎｏｔｈｅｒ）であることに留意されたい。
サブブロックＬ内のサブシンボルのサイズＴＳ（Ｌ）は、本明細書に示されるように計算することができる。以下の式において、ＴＳ（Ｌ’）は、サブブロックＬ’内のサブシンボルのサイズである。
ファイル内の、（Ｊ，Ｌ，Ｉ）、ＳＥＳＩ（Ｊ）≦Ｉ≦ＥＥＳＩ（Ｊ）である３つ組（ＳＢＮ，ＳｕＢＮ，ＥＳＩ）によってインデックス付けされるサブシンボルの開始バイト位置は、次のように計算することができる。
Figure 2014533045
ファイル内の、（Ｊ，Ｌ，Ｉ）によってインデックス付けされるサブシンボルの終了バイト位置は、開始バイト位置＋ＴＳ（Ｌ）−１である。
一例として、ファイルは、ＳＵ＝ｃｅｉｌ（Ｆ／Ｔ）、ＥＵ＝ＳＵ＋Ｚ×Ｍ−１と設定することによって形成されると仮定し、ここで、Ｍは、任意の受信クライアントによって予想されるソースブロック当たりのシンボルの最大ロスであり、したがって、この場合、Ｚ個のソースブロックの各々について、ファイル内には正確にＭ個のシンボルが存在し、ファイルは、修復シンボルのみから成り、ファイル内の最小ＥＳＩ値を有する修復シンボルは、修復シンボルの中で可能な最小のＥＳＩ値を有する。元のｅＭＢＭＳブロードキャストにおいて、ソースシンボルのみが送信された場合、修復シンボルのみから成るこのファイルを、ＨＴＴＰウェブサーバ上にアップロードし、ｅＭＢＭＳのための修復サービスを提供するために、バイト範囲要求を発行するクライアントによって使用することができる。もう少し一般的には、ｅＭＢＭＳセッションで送信される最大のＵＯＳＩがＸである場合、修復のために使用されるファイルは、ＵＯＳＩ範囲（Ｘ’，Ｙ’）によって指定することができ、ここで、Ｘ’＞Ｘであり、（Ｙ’−Ｘ’）／Ｚは、ソースブロックまたはソースサブブロックを回復するために任意のクライアントが要求する必要があるシンボルまたはサブシンボルの数の上限である。
図３４は、元の順序のファイルを図示し、この例では、ファイルは、Ｚ＝３個のソースブロックに分割され、各ソースブロックは、さらにＮ＝２個のサブブロックに分割され、最初の２つのソースブロックの各々には、４個のソースシンボルが存在し、第３のソースブロックには、３個のソースシンボルが存在する。図３４では、各ソースサブシンボルは、３つ組（Ｊ，Ｌ，Ｉ）を用いてラベル付けされ、ここで、Ｊは、ＳＢＮであり、Ｌは、ＳｕＢＮであり、Ｉは、サブシンボルのＥＳＩである。
図３５は、図３４に対応するファイルについてのソースシンボルを示しており、ここでは、ソースシンボルは、ＵＯＳＩ順で列挙されている。したがって、ＵＯＳＩ＝０を有するソースシンボルは、（０，０，０）および（０，１，０）でラベル付けされた２つのサブシンボルを備え、ＵＯＳＩ＝５を有するソースシンボルは、（２，０，１）および（２，１，１）でラベル付けされた２つのサブシンボルを備える。
図３６は、図３４に示されたファイルのための１１〜１９の範囲のＵＯＳＩを有する修復シンボルを示している。これらの修復シンボルは、元のファイルから、すなわち、図３５に示されるソースシンボルから生成することができる。各修復シンボルは、同じＥＳＩを使用する与えられたソースブロックの２つのサブブロックの各々から生成された２つのサブシンボルを備え、たとえば、ＵＯＳＩ＝１６を有する修復シンボルは、（１，０，５）および（１，１，５）でラベル付けされた２つのサブシンボルを備える。
図３７は、図３４に示されたファイルのためのＵＯＳＩ範囲１１〜１９に対応する拡張オリジナル順ＨＴＴＰファイル形式を示している。この順序付けでは、指定されたＵＯＳＩ範囲内のシンボルを構成するサブシンボルは、最初にＳＢＮによって順序付けられ、その中でＳｕＢＮによって順序付けられ、その中でＥＳＩによって順序付けられる。したがって、与えられたサブブロックについてのすべてのサブシンボルは、拡張オリジナル順ＨＴＴＰファイル形式内では連続的である。この例では、ＳＢＮ＝０およびＳＢＮ＝１を有するソースブロックを構成するサブブロックのサブシンボルについては、ＥＳＩ範囲は４〜６であるが、ＳＢＮ＝２を有するソースブロックを構成するサブブロックのサブシンボルについては、ＥＳＩ範囲は３〜５であることに留意されたい。拡張オリジナル順ＨＴＴＰファイル形式は、そのサブブロックのファイル内におけるサブシンボルの数を最大とする、単一のサブブロックに属する任意の数のサブシンボルを要求するために、単一のバイト範囲の使用をサポートすることに留意されたい。
拡張オリジナル順ＨＴＴＰファイル形式は、ソースシンボルと修復シンボルの混合を備えるファイルを生成するためにも使用することができる。たとえば、図３８は、図３４に示されたファイルのための、ＵＯＳＩ範囲８〜１２についての、拡張オリジナル順ＨＴＴＰファイル形式を示している。この例では、８、９、１０のＵＯＳＩは、ソースシンボルに対応し、１１、１２のＵＯＳＩは、修復シンボルに対応することに留意されたい。この例では、ソースブロックのいくつかについては異なる数のシンボルが存在し、たとえば、ＳＢＮ＝０およびＳＢＮ＝２を有するソースブロックの場合、２個のシンボルが存在し、ＳＢＮ＝１を有するソースブロックの場合、２個のシンボルが存在することにも留意されたい。
場合によっては、与えられたソースファイルに対して、２つ以上の拡張オリジナル順ＨＴＴＰファイルを提供することが望ましいことがある。たとえば、異なるファイルを異なるＣＤＮから、または異なる地域において利用可能とすることができる。たとえば、元のソースファイルに対応する、ＵＯＳＩ範囲が［０，１９９９９］である１つのファイルが存在することができ、ＵＯＳＩ範囲がそれぞれ［２００００，２２０００］、［２２００１，２６３５４］、および［４５６５１，６４３５６］である３つの他のファイルが存在することができる。代替として、元のソースファイルに対応する複数のファイル、たとえば、２００００個のソースシンボルを有するソースファイルに対して、ＵＯＳＩ範囲がそれぞれ［０，７０００］、［７００１，１４０００］、［１４０００，１９９９９］である３つのファイルが存在することができる。別の例として、利用可能な重複するＵＯＳＩ範囲を有する、たとえば、ＵＯＳＩ範囲がそれぞれ［０，１５０００］および［１００００，３００００］である、２つのファイルが存在することができる。場合によっては、拡張オリジナル順ＨＴＴＰファイル内のシンボルは、ソースシンボルと修復シンボルの混合とすることができ、たとえば、ＵＯＳＩ範囲は、［１００００，３００００］であり、ソースファイル内のソースシンボルの数は、２００００である。
オリジナル順ＨＴＴＰファイルのためのＨＴＴＰバイト範囲要求の例
ＭＢＭＳ ＵＥは、参照されるリソースのソースシンボルまたはサブシンボルのすべてまたはサブセットを要求するために、それぞれ、ＲＦＣ ２６１６で定義されているような従来のＨＴＴＰ／１．１ ＧＥＴまたは部分ＧＥＴ要求を使用することができる。これらのメッセージ形式は、ＭＢＭＳ ＵＥが、バイト範囲要求をサポートする、すなわち、そのＵＲＩが「ｂｙｔｅＲａｎｇｅＳｅｒｖｉｃｅＵＲＩ」もしくは「ｐｒｉｏｒｉｔｙＢｙｔｅＲａｎｇｅＳｅｒｖｉｃｅＵＲＩ」として挙げられている、ファイル修復サーバにシンボルを要求する場合に、またはＦＬＵＴＥ ＦＤＴインスタンス内の「Ｃｏｎｔｅｎｔ−Ｌｏｃａｔｉｏｎ」属性のサーバＵＲＩ部分に直接的にソースデータを要求する場合に、使用される。
オリジナル順ＨＴＴＰファイルの場合、ＭＢＭＳ ＵＥは、送信されるリソースのすべてのソースシンボルを必要とするときに、ＨＴＴＰ ＧＥＴ要求を使用する。ＭＢＭＳ ＵＥが、ソースシンボルまたはサブシンボルのサブセットのみの送信を要求する場合、ＵＥは、ＲＦＣ ２６２６の１４．３５．２で定義されているような、範囲要求ヘッダを有するＨＴＴＰ部分ＧＥＴ要求を使用することができる。ＭＢＭＳ ＵＥは、ＲＦＣ ２６１６の１４．３５．１で定義されているようなバイト範囲仕様として、特定のソースシンボルまたはサブシンボルを示す。
メッセージング効率のため、ＨＴＴＰ ＧＥＴ方法は、ＵＥが、単一の部分ＧＥＴ要求内に複数のバイト範囲要求を含めることを可能にする。ＵＥが、単一の要求内に複数のバイト範囲を含める場合、ＨＴＴＰ ＧＥＴ要求は、ＨＴＴＰサーバによる切り捨てを回避するために、２０４８バイトの長さを超えるべきではない。
ＭＢＭＳ ＵＥが、ソースシンボルまたはサブシンボルの複数のサブセットの中から選択できると決定した場合、ＭＢＭＳ ＵＥは、利用可能な最低のＥＳＩ値を有するサブセットを要求すべきであり、すなわち、ソースブロックまたはソースサブブロックの先頭から、それぞれ、失われたソースシンボルまたはサブシンボルを選択すべきである。これは、ＨＴＴＰファイル修復サーバのキャッシング効率を改善する。たとえば、ＭＢＭＳ ＵＥが、利用可能な最高のＥＳＩ値を有するサブセットを要求するなど、他の戦略も可能である。
２つ以上のファイルが、特定のＭＢＭＳダウンロードセッションにおいてダウンロードされた場合、またＭＢＭＳクライアントが、そのセッションにおいて受信された２つ以上のファイルのための修復データを必要とする場合、ＭＢＭＳクライアントは、各ファイルのための別々のＨＴＴＰ ＧＥＴ要求を送信することができる。
たとえば、ＭＢＭＳダウンロードセッションにおいて、ＦＬＵＴＥ ＦＤＴインスタンス内の「Ｃｏｎｔｅｎｔ−Ｌｏｃａｔｉｏｎ」属性がｗｗｗ．ｅｘａｍｐｌｅ．ｃｏｍ／ｎｅｗｓ／ｓｐｏｒｔｓ．３ｇｐになるように設定された３ｇｐファイルが、オブジェクトサイズがＦ＝２０００００００バイト、アライメントファクタがＡｌ＝４バイト、シンボルサイズがＴ＝１３２０バイト、ソースブロックの数がＺ＝２０、およびソースブロック当たりのサブブロックの数がＮ＝１であるＦＥＣ ＯＴＩとともに配送されると仮定する。その例では、ファイル内のソースシンボルの総数は、ＫＴ＝１５１５２であり、ＳＢＮが０〜１１の最初の１２個のソースブロックは、各々、７５８個のソースシンボルを有し、ＳＢＮが１２〜１９の残りの８個のソースブロックは、各々、７５７個のソースシンボルを有する。
ＭＢＭＳダウンロードセッションの後、ＭＢＭＳクライアントが、ＳＢＮ＝５のソースブロックに属するＥＳＩが１２〜２９の１８個の連続するソースシンボルと、ＳＢＮ＝１９の最後のソースブロックに属するＥＳＩが２７〜３６の１０個の連続するソースシンボルとを受信しなかったこと、またこれらのソースブロックを復号するために、これらのソースブロックの各々から少なくともこれだけの数のシンボルをさらに必要とすることを認識したと仮定する。ＳＢＮ＝５のソースブロックの場合、ＥＳＩ＝１２の最初の失われたソースシンボルの開始バイト位置は、図３９に示されるように計算することができる。ＥＳＩ＝２９の最後の失われたシンボルの終了バイト位置についての計算も、図３９に示されている。ＳＢＮ＝１９のソースブロックの失われたシンボルの開始バイト位置および終了バイト位置についての計算も、図３９の表の最終行に示されている。
選択された修復サーバが、バイト範囲要求を受け入れ（たとえば、サーバＵＲＩは、関連する配送手順メタデータフラグメント内の「ｂｙｔｅＲａｎｇｅＳｅｒｖｉｃｅＵＲＩ」要素を用いて識別される）、そのサーバＵＲＩが、ｈｔｔｐ：／／ｈｔｔｐｒｅｐａｉｒ１．ｅｘａｍｐｌｅ．ｃｏｍである場合、修復サーバへのＨＴＴＰ ＧＥＴ要求は、次のようになる。
Figure 2014533045
拡張オリジナル順ＨＴＴＰファイル形式内のファイルのＵＯＳＩ範囲は、数々の異なる手法または実施形態を介して、ＵＥに伝達することができる。一実施形態では、これは、たとえば、新しい属性「Ｓｔａｒｔ−ＵＯＳＩ」および「Ｅｎｄ−ＵＯＳＩ」を追加することによって、ファイルに関連するＦＬＵＴＥインスタンス内のファイル記述テーブルの一部として、送信することができる。別の実施形態では、ＵＯＳＩ範囲は、たとえば、「ｓｔａｒｔ＿ｕｏｓｉ＝ｘｘｘ」および「ｅｎｄ＿ｕｏｓｉ＝ｙｙｙ」属性をＵＲＬ内に挿入／追加することによって、ファイルのＵＲＬ内に直接的に符号化することができる。代替として、ファイルのＵＯＳＩ範囲は、ファイルのための配送セッションに関連する、セッション記述プロトコル（ＳＤＰ）、メディア提示記述（ＭＰＤ）、またはユーザサービス記述（ＵＳＤ）を介して伝達することが、たとえば、「Ｓｔａｒｔ−ＵＯＳＩ」および「Ｅｎｄ−ＵＯＳＩ」のための新しい属性をこれらの記述の１つに追加することによって伝達することができる。
ＵＥがファイル形式を適切に復号するために必要とされる補助ファイル形式パラメータを、ＵＯＳＩ範囲に加えて、伝達することができる。そのような追加のパラメータの例は、何らかのＦＥＣオブジェクト送信情報を含む。これらの補助ファイル形式パラメータも、これらのパラメータのための属性を定義することによって、ＦＬＵＴＥインスタンスのファイル記述テーブル（ＦＤＴ）で送信することができる。別の実施形態では、補助ファイル形式パラメータは、ファイルのＵＲＬ内に直接的に符号化することができる。代替として、補助ファイル形式パラメータは、ファイルのための配送セッションに関連する、セッション記述プロトコル（ＳＤＰ）、メディア提示記述（ＭＰＤ）、またはユーザサービス記述（ＵＳＤ）を介して伝達することが、たとえば、パラメータのための新しい属性をこれらの記述の１つに追加することによって伝達することができる。
一実施形態では、ＦＥＣ ＯＴＩ情報、ＵＯＳＩ範囲、または任意の一般的な補助ファイル形式パラメータは、ＭＩＭＥタイプとして伝達することができる。たとえば、ＦＥＣ ＯＴＩパラメータは、ＦＬＵＴＥシンボルが特定のＦＥＣ ＯＴＩ値とともにＭＰ４ファイル内に含まれていることを示す、ＲＦＣ ６３８１に従った文字列「ａｐｐｌｉｃａｔｉｏｎ／ｍｐ４ ｐｒｏｆｉｌｅｓ＝‘ｆｌｕｔ’ ｆｅｃ−ｏｔｉ＝‘ＸＹＺ’」を使用して、伝達することができる。別の実施形態では、新しいファイル形式が、定義され、パラメータを「ｆｅｃ−ｏｔｉ」としてＭＩＭＥタイプ登録に追加する。この伝達の一例は、文字列「ａｐｐｌｉｃａｔｉｏｎ／ｆｌｕｔ−ｆｅｃ−ｏｔｉ＝‘ＸＹＺ’」である。
いくつかの実施形態では、必要ではないが、ＨＴＴＰサーバ上に記憶されたファイルのための補助ファイル形式パラメータは、ブロードキャストを介して送信されたファイルのための補助ファイル形式パラメータと同じである。一代替実施形態では、補助ファイル形式パラメータのいくつかは、ブロードキャストされたファイルの場合と、修復を可能にするためにＨＴＴＰサーバ上に記憶されたファイルの場合とで異なることができる。
たとえば、ＨＴＴＰサーバ上に記憶されたファイル形式のためのＦＥＣ ＯＴＩは、ブロードキャストを形式化するために使用されたＦＥＣ ＯＴＩと異なることができる。実際の例として、異なるエリアにおいて異なるＦＥＣ ＯＴＩパラメータを使用してブロードキャストデータが符号化される場合、異なるカバレージエリアの間を移動するデバイスは、デバイスの現在位置に応じて、異なる符号化が施されたファイルにサービスする異なるサーバに転送されるユニキャスト修復要求を有することがある。これらの異なる数組のパラメータ値を区別するために、パラメータ値は、上で説明されたように、修復サーバ上に記憶されるファイル名またはＵＲＩに直接的に符号化することができる。代替として、それらの属性は、ＦＤＴ、ＳＤＰ、ＭＰＤ、またはＵＳＤの一部として端末に伝達される場合、たとえば、「ＦＥＣ＿ＯＴＩ＿ｂｃａｓｔ」および「ＦＥＣ＿ＯＴＩ＿ｆｉｌｅ」など、異なる名前を用いて定義することができる。端末（たとえば、ＵＥ端末）は、次いで、ブロードキャストまたはＨＴＴＰサーバから取り出されたファイルを復号するための適切な手順を決定することができる。一実施形態では、端末は、異なるファイル形式構成を使用して複数のファイルが提示される場合、ＨＴＴＰサーバ上のどのファイルからデータを取り出すべきかを決定するために、補助ファイルパラメータを使用することができる。また他の実施形態では、ファイルを求めるＨＴＴＰ要求は、必要とされるＯＴＩパラメータを示すプログラム命令を含むことができ、ＨＴＴＰサーバは、その場合、正しく符号化されたファイルを求める要求にサービスするために、またはそのような符号化されたファイルが利用可能でない場合は、要求を拒否するために、埋め込まれた命令を使用する。
別の実施形態では、たとえば、ソースファイルがインターネットＵＲＬを有するサーバ上に配置され、端末が、補助ファイル形式パラメータを伝達するために変更または形式化できないＵＲＬに修復データを要求することが必要なことがある。別の手法は、ＵＲＬで任意選択のパラメータを伝達でき、それらがＵＲＬで明示的に伝達されない場合は、デフォルトパラメータ値を仮定できる能力を有することである。たとえば、伝達される潜在的なパラメータが、形式タイプ（たとえば、ＳＳ順ＨＴＴＰファイル形式、または拡張オリジナル順ＨＴＴＰファイル形式）、ＦＥＣ ＯＴＩパラメータ、およびＵＯＳＩ範囲であると仮定する。
ＵＲＬがｗｗｗ．ｅｘａｍｐｌｅ．ｃｏｍであるユニキャストファイルが存在し、すなわち、これらのパラメータはどれも、ＵＲＬで伝達されないと仮定する。その例では、クライアントによって仮定されるデフォルトパラメータは、拡張オリジナル順ＨＴＴＰファイル形式、ＵＯＳＩ範囲＝０、．．．、Ｆ／Ｔ、ＦＥＣ ＯＴＩ＝ブロードキャストＦＥＣ ＯＴＩとすることができ、すなわち、それは、まさに、元の順序の元のソースファイルである。
代わりに、ＵＯＳＩ範囲が伝達される場合、たとえば、クライアントに提供されるＵＲＬが、ｗｗｗ．ｅｘａｍｐｌｅ．ＵＯＳＩ＝Ｘ＿ｔｏ＿Ｙ．ｃｏｍである場合、クライアントは、ＵＯＳＩ範囲がＸ〜Ｙであることを理解し、これを使用し、ＦＥＣ ＯＴＩは伝達されないので、それは、デフォルトによって、このファイルのブロードキャストバージョンのＦＥＣ ＯＴＩと同じであり、拡張オリジナル順ＨＴＴＰファイル形式が仮定される。
第３の例では、ＵＯＳＩ範囲とＦＥＣ ＯＴＩの両方がＵＲＬで伝達される場合、たとえば、ｗｗｗ．ｅｘａｍｐｌｅ．ＦＥＣ＿ＯＴＩ＝（Ｆ，Ａｌ，Ｔ，Ｚ，Ｎ）．ＵＯＳＩ＝Ｘ＿ｔｏ＿Ｙ．ｃｏｍである場合、与えられたＦＥＣ ＯＴＩおよびＵＯＳＩ範囲とともに、デフォルトの拡張オリジナル順ＨＴＴＰファイル形式が仮定される。
第４の例では、形式がＵＲＬで伝達される場合、すなわち、ｗｗｗ．ｅｘａｍｐｌｅ．Ｆｏｒｍａｔ＝ＳＳ．ＦＥＣ＿ＯＴＩ＝（Ｆ，Ａｌ，Ｔ，Ｚ，Ｎ）．ｃｏｍである場合、これは、形式がＳＳ順ＨＴＴＰファイル形式であることをクライアントに伝達し、ＦＥＣ ＯＴＩを提供する（ＦＥＣ ＯＴＩが提供されない場合、この例では、ブロードキャストＦＥＣ ＯＴＩと同じであることが仮定される）。
したがって、ＵＲＬで伝達できるこれらの任意選択のパラメータを有することによって、次のことを、すなわち、（伝達されないパラメータについてのデフォルト値がファイルの形式に一致することを確認しながら）関連するＵＲＬをすでに有するファイルのために無変更のＵＲＬを可能にすること、またはパラメータの一部もしくは全部を伝達するＵＲＬを可能にすることを達成することができる。主な利点は、この場合の伝達されないパラメータは、デフォルトではファイルが元のソースファイルであることを示すので、インターネットまたはオーバーザトップ（Ｏｖｅｒ−Ｔｈｅ−Ｔｏｐ）を介して利用可能な既存のファイルのために無変更のＵＲＬを使用できることである。その場合、パラメータを伝達するＵＲＬを有するファイルについては、これらのファイルは、（たとえば、ファイルの一部である修復データを生成する、またはファイルの形式を再組織化するなど）特別に形成しなければならない可能性が高い。これらのファイルは元のソースファイルではないので、ＵＲＬで追加のパラメータを伝達すべきことが好ましいが、それは、ファイルが特別に形成されるときには、これらのファイルのためにＵＲＬを生成する必要があるからである。
拡張オリジナル順ＨＴＴＰファイルの場合、ＭＢＭＳ ＵＥは、送信されるリソースのすべてのソースシンボルを必要とするときに、ＨＴＴＰ ＧＥＴ要求を使用する。ＭＢＭＳ ＵＥが、シンボルまたはサブシンボルのサブセットのみの送信を要求する場合、ＵＥは、ＲＦＣ ２６２６の１４．３５．２で定義されているような、範囲要求ヘッダを有するＨＴＴＰ部分ＧＥＴ要求を使用することができる。ＭＢＭＳ ＵＥは、ＲＦＣ ２６１６の１４．３５．１で定義されているようなバイト範囲仕様として、特定のソースシンボルまたはサブシンボルを示す。
たとえば、ＭＢＭＳダウンロードセッションにおいて、ＦＬＵＴＥ ＦＤＴインスタンス内の「Ｃｏｎｔｅｎｔ−Ｌｏｃａｔｉｏｎ」属性がｗｗｗ．ｅｘａｍｐｌｅ．ｃｏｍ／ｎｅｗｓ／ｓｐｏｒｔｓ．３ｇｐになるように設定された３ｇｐファイルが、オブジェクトサイズがＦ＝２０００００００バイト、アライメントファクタがＡｌ＝４バイト、シンボルサイズがＴ＝１３２０バイト、ソースブロックの数がＺ＝２０、およびソースブロック当たりのサブブロックの数がＮ＝１であるＦＥＣ ＯＴＩとともに配送されると仮定する。その例では、ファイル内のソースシンボルの総数は、ＫＴ＝１５１５２であり、ＳＢＮが０〜１１の最初の１２個のソースブロックは、各々、７５８個のソースシンボルを有し、ＳＢＮが１２〜１９の残りの８個のソースブロックは、各々、７５７個のソースシンボルを有する。この例では、ソースシンボルがＭＢＭＳダウンロードセッションで送信され、ＨＴＴＰを介して利用可能な修復ファイルに関連するＵＯＳＩ範囲は、［１５１５２，１７１５１］であり、すなわち、拡張オリジナル順ＨＴＴＰファイル形式では、修復ファイルは、２０個のソースブロックの各々について、最初の１００個の修復シンボルを備えると仮定する。
ＭＢＭＳダウンロードセッションの後、ＭＢＭＳクライアントが、ＳＢＮ＝５のソースブロックのための追加の１８個のシンボルと、ＳＢＮ＝１９の最後のソースブロックのための１０個の追加のシンボルとを、これらのソースブロックを復号するために必要とすることを認識したと仮定する。ＳＢＮ＝５のソースブロックの場合、ＥＳＩ＝７５８であるファイル内の最初のシンボルの開始バイト位置は、図４０に示されるように計算することができる。ＥＳＩ＝７７５である最後のシンボルの終了バイト位置についての計算も、図４０に示されている。ＳＢＮ＝１９であるソースブロックのシンボルの開始バイト位置および終了バイト位置についての計算も、図４０の表の最終行に示されている。
選択された修復サーバが、バイト範囲要求を受け入れ（たとえば、サーバＵＲＩは、関連する配送手順メタデータフラグメント内の「ｂｙｔｅＲａｎｇｅＳｅｒｖｉｃｅＵＲＩ」要素を用いて識別される）、そのサーバＵＲＩが、ｈｔｔｐ：／／ｈｔｔｐｒｅｐａｉｒ１．ｅｘａｍｐｌｅ．ｃｏｍである場合、修復サーバへのＨＴＴＰ ＧＥＴ要求は、次のようになる。
Figure 2014533045
サブブロックが使用される別の例では、ＭＢＭＳダウンロードセッションにおいて、ＦＬＵＴＥ ＦＤＴインスタンス内の「Ｃｏｎｔｅｎｔ−Ｌｏｃａｔｉｏｎ」属性がｗｗｗ．ｅｘａｍｐｌｅ．ｃｏｍ／ｎｅｗｓ／ｉｎｔｅｒｎａｔｉｏｎａｌ．３ｇｐになるように設定された３ｇｐファイルが、オブジェクトサイズがＦ＝２０００００００バイト、アライメントファクタがＡｌ＝４バイト、シンボルサイズがＴ＝１３２０バイト、ソースブロックの数がＺ＝２、およびソースブロック当たりのサブブロックの数がＮ＝１２であるＦＥＣ ＯＴＩとともに配送されると仮定する。その例では、ファイル内のソースシンボルの総数は、ＫＴ＝１５１５２であり、ＳＢＮ＝０の第１のソースブロックおよびＳＢＮ＝１の第２のソースブロックは、各々、７５７６個のソースシンボルを有する。その例では、各ソースブロックは、各々、１２個のサブブロックにさらに分割され、その各々は、７５７６個のソースサブシンボルを有し、最初の６個のサブブロックは、サイズが１１２バイトのサブシンボルを有し、残りの６個のサブブロックは、サイズが１０８バイトのサブシンボルを有する。この例では、ソースシンボルがＭＢＭＳダウンロードセッションで送信され、ＨＴＴＰを介して利用可能な修復ファイルに関連するＵＯＳＩ範囲は、［１５１５２，１７１５１］であり、すなわち、拡張オリジナル順ＨＴＴＰファイル形式では、修復ファイルは、２個のソースブロックの各々について、最初の１０００個の修復シンボルを備えると仮定する。
ＭＢＭＳダウンロードセッションの後、ＭＢＭＳクライアントが、ＳＢＮ＝０の第１のソースブロックのための１８個の追加のシンボルと、ＳＢＮ＝１の第２のソースブロックのための１８個の追加のシンボルとを、これらのソースブロックを復号するために必要とすることを認識したと仮定する。
ＳＢＮ＝０の第１のソースブロックの場合、ＥＳＩ＝７５７６であるシンボル（修復ファイル内で利用可能な最初のシンボル）を構成する１２個のサブシンボルの開始バイト位置は、図４１に示されるように計算することができる。図４１は、ＥＳＩ＝７５９３であるシンボル（１８個のシンボルのうちの最後のもの）を構成する１２個のサブシンボルの終了バイト位置がどのように計算され得るかも示している。図４１の表において、「ＳｕＢＮ」は、サブブロック番号のことである。
多くの他の実施形態および上で説明された実施形態の変形が存在する。本明細書で説明されたすべての形式に対する変形の一例として、ソースブロックのシンボルおよびサブシンボルがＥＳＩの逆順で並べられること以外は同じ形式を使用することができる。たとえば、ファイルが２つのソースブロックに分割され、各々が２つのサブブロックを有し、その各々が３つのサブシンボルを有する場合、このファイルの拡張オリジナル順ＨＴＴＰ形式は、（０，０，０）、（０，０，１）、（０，０，２）、（０，１，０）、（０，１，１）、（０，１，２）、（１，０，０）、（１，０，１）、（１，０，２）、（１，１，０）、（１，１，１）、（１，１，２）と表すことができ、各３つ組は、各サブシンボルのＳＢＮ、ＳｕＢＮ、およびＥＳＩを示す。逆順のこのファイルは、（０，０，２）、（０，０，１）、（０，０，０）、（０，１，２）、（０，１，１）、（０，１，０）、（１，０，２）、（１，０，１）、（１，０，０）、（１，１，２）、（１，１，１）、（１，１，０）と表すことができる。同様の逆変形は、本明細書で説明された他のすべての形式にも適用される。ファイルの逆変形は、たとえば、クライアントが、２つの異なるサーバから、コンテンツを再構成するために使用できるデータをダウンロードしており、第１のサーバからは、１つのファイル形式で記憶された、コンテンツを再構成するために使用できるデータをダウンロードまたは受信しており、第２のサーバからは、逆形式で記憶された、コンテンツを再構成するために使用できるファイルをダウンロードまたは受信している場合に有益とすることができる。２つのサーバからのデータの配送速度が異なる、または予測不可能である場合、クライアントは、２つのサーバから到着したデータの組合せがコンテンツを再構成するのに十分になるまで、単純に待つことができ、次いで、クライアントは、接続を終了すること、または単に、２つのサーバから追加のデータを受信することを止めることができる。一方の形式は、他方の逆であるので、クライアントは、概して、クライアントが各サーバからどれだけのデータを受信したかには無関係に、クライアントがコンテンツを再構成することを可能にする、重複のないデータを受信する。
拡張オリジナル順ＨＴＴＰ形式ファイルの形式を指定する多くの他の変形、または本明細書で説明される多くの他の形式が存在する。たとえば、拡張オリジナル順ＨＴＴＰ形式ファイルのデータを指定するために、ＵＯＳＩ範囲の代わりに、バイト範囲を使用することができる。たとえば、ＵＯＳＩ範囲が（Ｘ，Ｙ）であり、シンボルサイズがＴである場合、同じ形式を指定するバイト範囲は、バイトＸ×Ｔで開始し、バイト（Ｙ＋１）×Ｔ−１で終了する、バイト範囲とすることができる。形式を指定する他の変形は、ファイルの各ソースブロックについてのＥＳＩ範囲の明示的なリストを指定することを含む。たとえば、ファイルが５個のソースシンボルを有する場合、ファイルの形式の指定は、ＳＢＮ＝０、ＥＳＩ＝２０〜５０、ＳＢＮ＝１、ＥＳＩ＝３０〜４０、ＳＢＮ＝２、ＥＳＩ＝１０〜１９、ＳＢＮ＝３、ＥＳＩ＝０〜５０、ＳＢＮ＝４、ＥＳＩ＝１７〜３７とすることができる。この例では、異なる範囲のＥＳＩを有する同じソースブロックを複数回挙げることができ、たとえば、ＳＢＮ＝４、ＥＳＩ＝５５〜６５を上記のリストに追加することができ、その場合、形式化されたファイル内には、ＳＢＮ＝４のソースブロックに対して、ＥＳＩの２つの範囲が存在する。代替として、ＥＳＩ範囲は、バイト範囲で置き換えることができ、この場合、各バイト範囲は、ソースブロックに関連する。たとえば、上記において、シンボルサイズが１０００バイトである場合、バイト範囲３００００〜４０９９９は、ＥＳＩ範囲３０〜４０と等価である。形式の指定についてのこれらの変形は、先に本明細書で説明されたすべての形式と組み合わせることができる。
今説明したように、いくつかの特定の例が存在する。本開示を読んだ後には、当業者は、さらなる実施形態を思いつくことができる。他の実施形態では、上で開示された本発明のコンビネーションまたはサブコンビネーションを有利に作成することができる。構成要素の例示的な構成は、説明を目的として示されたものであり、本発明の代替実施形態では、組合せ、追加、および再構成などが企図されることを理解されたい。したがって、本発明は例示的な実施形態に関して説明されたが、数多くの変更が可能であることを当業者は理解されよう。
たとえば、本明細書で説明されたプロセスは、ハードウェア構成要素、ソフトウェア構成要素、および／またはそれらの任意の組合せを使用して実施することができる。本明細書および図面は、したがって、限定的な意味ではなく、説明的な意味に解釈されるべきである。しかし、特許請求の範囲で説明される本発明のより広範な主旨および範囲から逸脱することなく、様々な修正および変更をそれらに施し得ること、また本発明が以下の特許請求の範囲内にすべての修正および均等物を包含することが意図されていることは明らかである。

Claims (53)

  1. パケット交換ネットワークに連結された電子デバイスまたはシステムを使用して、１つまたは複数のデータオブジェクトを受信する方法であって、前記１つまたは複数のデータオブジェクトのソースデータがパケット内において符号化シンボルによって表され、前記ソースデータが前記符号化シンボルから少なくとも近似的に回復可能である、前記方法が、
    ａ）ブロードキャストチャネルを介して符号化シンボルを受信することであって、符号化シンボルの値が、少なくとも部分的に、ソースシンボルの値から導出される、受信することと、
    ｂ）所望のレベルの完全性でコンテンツを回復するために必要とされる追加シンボルの数を決定することと、
    ｃ）１つまたは複数のファイルの１つまたは複数のバイト範囲の対応するセットを決定することであって、前記対応するセットが、前記コンテンツを回復するために必要とされる前記追加シンボルに対応する、決定することと、
    ｄ）前記対応するセットの１つまたは複数のバイト範囲を指定する、サーバに送られる要求を使用する、少なくとも前記追加シンボルの数を求める要求を生成することと、
    ｅ）前記要求を送信することと、
    ｆ）前記要求された追加シンボルの少なくともいくつかを受信することと、
    ｇ）前記コンテンツを回復する際に、前記ブロードキャストチャネルを介して受信された前記符号化シンボルと組み合わせて、前記受信された追加シンボルを使用することと、
    を備える方法。
  2. 前記所望のレベルの完全性は、前記コンテンツの完全な回復である、請求項１に記載の方法。
  3. 前記要求は、ＨＴＴＰバイト範囲要求であり、複数の要求のうちの少なくとも１つの要求は、非連続バイト範囲を求めるＨＴＴＰバイト範囲要求である、請求項１に記載の方法。
  4. 前記要求は、追加シンボルの連続的なセットを求めるものである、請求項１に記載の方法。
  5. 前記追加シンボルの連続的なセットは、コンテンツをリモートで受信する複数のデバイスの各々について、同じ開始シンボルであるソースシンボルで開始する、請求項４に記載の方法。
  6. 前記要求は、ユニキャストＨＴＴＰバイト範囲要求である、請求項１に記載の方法。
  7. 前記追加シンボルは、ソースシンボルである、請求項１に記載の方法。
  8. 前記追加シンボルは、ソースシンボルおよび修復シンボルである、請求項１に記載の方法。
  9. 前記符号化シンボルは、すべて修復シンボルであり、前記追加シンボルは、すべてソースシンボルである、請求項１に記載の方法。
  10. 前記ソースデータは、ソースシンボルのソースブロックの組織化されたセットを備え、ソースサブブロックおよびソースサブシンボルのセットにさらに組織化される、請求項１に記載の方法。
  11. 前記要求は、サブシンボルのバイト範囲を求めるものである、請求項１０に記載の方法。
  12. 前記要求は、追加サブシンボルの連続的なセットを求めるものである、請求項１０に記載の方法。
  13. 前記連続的なセットは、コンテンツをリモートで受信する複数のデバイスの各々について、同じ開始サブシンボルであるソースサブシンボルで開始する、請求項１２に記載の方法。
  14. 前記要求は、ソースサブシンボルを求めるものである、請求項１０に記載の方法。
  15. 前記要求は、ソースサブシンボルおよび修復サブシンボルを求めるものである、請求項１０に記載の方法。
  16. リモートで受信されたコンテンツを提示するデバイスであって、
    ブロードキャストチャネルからデータを受信するための電子的なインターフェースと、
    前記ブロードキャストチャネルを介して符号化シンボルを受信するためのロジックであって、符号化シンボルの値が、少なくとも部分的に、リモートで受信された前記コンテンツに対応するソースシンボルの値から導出される、ロジックと、
    所望のレベルの完全性でコンテンツを回復するために必要とされる追加シンボルの数を決定するためのロジックと、
    １つまたは複数のファイルの１つまたは複数のバイト範囲の対応するセットを決定するためのロジックであって、前記対応するセットが、前記コンテンツを回復するために必要とされる前記追加シンボルに対応する、ロジックと、
    前記対応するセットの１つまたは複数のバイト範囲を指定する、サーバに送られる要求を使用する、少なくとも前記追加シンボルの数を求める要求を生成するためのロジックと、
    前記要求を送信するためのインターフェースと、
    前記要求された追加シンボルの少なくともいくつかを受信するためのロジックと、
    前記コンテンツを回復する際に、前記ブロードキャストチャネルを介して受信された前記符号化シンボルと組み合わせて、前記受信された追加シンボルを使用する復号器と
    を備えるデバイス。
  17. 前記所望のレベルの完全性は、前記コンテンツの完全な回復である、請求項１６に記載のデバイス。
  18. 前記要求は、ＨＴＴＰバイト範囲要求であり、複数の要求のうちの少なくとも１つの要求は、非連続バイト範囲を求めるＨＴＴＰバイト範囲要求である、請求項１６に記載のデバイス。
  19. 前記要求は、追加シンボルの連続的なセットを求めるものである、請求項１６に記載のデバイス。
  20. 前記追加シンボルの連続的なセットは、コンテンツをリモートで受信する複数のデバイスの各々について、同じ開始シンボルであるソースシンボルで開始する、請求項１９に記載のデバイス。
  21. 前記追加シンボルは、ソースシンボルである、請求項１６に記載のデバイス。
  22. 前記追加シンボルは、ソースシンボルおよび修復シンボルである、請求項１６に記載のデバイス。
  23. 前記符号化シンボルは、すべて修復シンボルであり、前記追加シンボルは、すべてソースシンボルである、請求項１６に記載のデバイス。
  24. 前記ソースデータは、ソースシンボルのソースブロックの組織化されたセットを備え、ソースサブブロックおよびソースサブシンボルのセットにさらに組織化される、請求項１６に記載のデバイス。
  25. 前記要求は、サブシンボルのバイト範囲を求めるものである、請求項１６に記載のデバイス。
  26. 前記要求は、追加サブシンボルの連続的なセットを求めるものである、請求項１６に記載のデバイス。
  27. 前記連続的なセットは、コンテンツをリモートで受信する複数のデバイスの各々について、同じ開始サブシンボルであるソースサブシンボルで開始する、請求項２６に記載のデバイス。
  28. 前記要求は、ソースサブシンボルを求めるものである、請求項１６に記載のデバイス。
  29. 前記要求は、ソースサブシンボルおよび修復サブシンボルを求めるものである、請求項１６に記載のデバイス。
  30. ＨＴＴＰバイト範囲要求がファイルサーバによってサポートされるかどうかの表示をネットワークから受信するためのロジックをさらに備える、請求項１６に記載のデバイス。
  31. どのサーバがどの形式をサポートするかの表示を前記ネットワークから受信するためのロジックをさらに備える、請求項１６に記載のデバイス。
  32. 前記デバイスがどのサーバに要求を行うように試みるべきかについての優先度の表示を前記ネットワークから受信するためのロジック
    をさらに備える、請求項３１に記載のデバイス。
  33. 前記デバイスによって２つ以上がサポートされる場合に、どの要求形式を使用すべきかを示す選好または要件を受信するためのロジックをさらに備える、請求項１６に記載のデバイス。
  34. 修復シンボルのみが前記デバイスにブロードキャストされる旨の表示を受信するためのロジックをさらに備える、請求項１６に記載のデバイス。
  35. 前記デバイスが前記表示を受信した場合、追加データを求めるプレフィックス要求を常に使用するように制約される、請求項３４に記載のデバイス。
  36. 前記デバイスが追加データを求めるプレフィックス要求を使用することを要求する表示を受信するためのロジックをさらに備える、請求項１６に記載のデバイス。
  37. シンボルまたはサブシンボルのファイル内における開始バイト位置と、前記シンボルまたはサブシンボルの前記ファイル内における終了バイト位置とを計算するためのロジックをさらに備える、請求項１６に記載のデバイス。
  38. パケット交換ネットワークを介して電子デバイスまたはシステムから１つまたは複数のデータオブジェクトを配送する方法であって、前記１つまたは複数のデータオブジェクトのソースデータがパケット内において符号化シンボルによって表され、前記ソースデータが前記符号化シンボルから少なくとも近似的に回復可能である、前記方法が、
    ａ）前記ソースデータが、ソースシンボルのソースブロックにまだ組織化されていない場合、前記ソースデータをソースシンボルのソースブロックの組織化されたセットに組織化することと、
    ｂ）符号化シンボルを生成することであって、符号化シンボルの値が、少なくとも部分的に、ソースシンボルの値から導出され、修復シンボルである符号化シンボルが、ソースブロックに対応する、生成のために使用される範囲を有する、生成することと、
    ｃ）修復シンボルおよび／またはソースシンボルを符号化シンボルとして宛先デバイスにブロードキャスト方法で提供することであって、ブロードキャストが、ブロードキャストされたデータのシンボルおよびブロック構造を宛先デバイスが決定するのに十分な情報を提供する、提供することと
    を備え、
    前記十分な情報は、バイト範囲要求を用いるファイル要求をサポートするサーバからバイト範囲要求することのために、使用可能なバイト範囲にソースシンボルのソースブロックの前記組織化されたセットにおいてソースシンボルを、マッピングする情報を少なくとも備える、
    方法。
  39. ｄ）前記宛先デバイスにおいて、どのソースシンボルが受信されたブロードキャストシンボルから復号可能でないかを決定することと、
    ｅ）前記宛先デバイスにおいて、バイト範囲限定子を有するファイル要求を使用して要求可能である、ファイルの１つまたは複数のバイト範囲のセットを決定することと、
    ｆ）前記バイト範囲限定子を有する前記ファイル要求を行うことと
    をさらに備える、請求項３８に記載の方法。
  40. 前記ファイル要求は、ＵＲＬおよびバイト範囲を備えるＨＴＴＰクライアント要求である、請求項３８に記載の方法。
  41. 前記バイト範囲は、要求される前記ファイルの先頭から開始する、請求項４０に記載の方法。
  42. ｄ）受信された要求から、前記受信された要求が、ブロードキャストプロセスから導出された失われた修復シンボルを回復するための修復プロセスに応答したものかどうかを決定することと、
    ｅ）前記受信された要求から、前記受信された要求が、ブロードキャストプロセスに無関係の、クライアントからの直接的な要求に応答したものかどうかを決定することと、
    ｆ）決定結果を記録することと
    をさらに備える、請求項３８に記載の方法。
  43. 決定が、前記受信された要求において使用されるＵＲＬの全部または一部を読むことによって実行される、請求項４２に記載の方法。
  44. ソースシンボルのソースブロックの前記組織化されたセットは、ソースサブブロックおよびソースサブシンボルのセットにさらに組織化される、請求項３８に記載の方法。
  45. パケット交換ネットワークに連結された電子デバイスまたはシステムを使用して、１つまたは複数のデータオブジェクトを受信するための非一時的なコンピュータプログラム製品であって、前記１つまたは複数のデータオブジェクトのソースデータがパケット内において符号化シンボルによって表され、前記ソースデータが前記符号化シンボルから少なくとも近似的に回復可能である、前記製品が、
    ａ）ブロードキャストチャネルを介して符号化シンボルを受信するためのプログラムコードであって、符号化シンボルの値が、少なくとも部分的に、ソースシンボルの値から導出される、プログラムコードと、
    ｂ）所望のレベルの完全性でコンテンツを回復するために必要とされる追加シンボルの数を決定するためのプログラムコードと、
    ｃ）１つまたは複数のファイルの１つまたは複数のバイト範囲の対応するセットを決定するためのプログラムコードであって、前記対応するセットが、前記コンテンツを回復するために必要とされる前記追加シンボルに対応する、プログラムコードと、
    ｄ）前記対応するセットの１つまたは複数のバイト範囲を指定する、サーバに送られる要求を使用する、少なくとも前記追加シンボルの数を求める要求を生成するためのプログラムコードと、
    ｅ）前記要求をサーバに送信するためのプログラムコードと、
    ｆ）前記要求された追加シンボルの少なくともいくつかを受信するためのプログラムコードと、
    ｇ）前記ブロードキャストチャネルを介して受信された前記符号化シンボルと組み合わされる、前記受信された追加シンボルを使用して、前記コンテンツを回復するためのプログラムコードと
    を備える製品。
  46. 前記所望のレベルの完全性は、前記コンテンツの完全な回復である、請求項４５に記載の製品。
  47. 前記要求は、ＨＴＴＰバイト範囲要求であり、複数の要求のうちの少なくとも１つの要求は、非連続バイト範囲を求めるＨＴＴＰバイト範囲要求である、請求項４５に記載の製品。
  48. 前記要求は、追加シンボルの連続的なセットを求めるものである、請求項４５に記載の製品。
  49. 前記追加シンボルの連続的なセットが、コンテンツをリモートで受信する複数のデバイスの各々について、同じ開始シンボルであるソースシンボルで開始する、請求項４８に記載の製品。
  50. 前記符号化シンボルは、すべて修復シンボルであり、前記追加シンボルは、すべてソースシンボルである、請求項４５に記載の製品。
  51. 前記ソースデータは、ソースシンボルのソースブロックの組織化されたセットを備え、ソースサブブロックおよびソースサブシンボルのセットにさらに組織化される、請求項４５に記載の製品。
  52. 前記要求は、追加サブシンボルの連続的なセットを求めるものである、請求項５１に記載の製品。
  53. 前記連続的なセットは、コンテンツをリモートで受信する複数のデバイスの各々について、同じ開始サブシンボルであるソースサブシンボルで開始する、請求項５２に記載の製品。
JP2014540098A 2011-11-01 2012-11-01 Ｈｔｔｐサーバの間でのソースデータおよび修復データの割り当てを伴うコンテンツ配送システム Expired - Fee Related JP5795446B2 (ja)

Applications Claiming Priority (13)

Application Number Priority Date Filing Date Title
US201161554434P 2011-11-01 2011-11-01
US61/554,434 2011-11-01
US201261589855P 2012-01-23 2012-01-23
US61/589,855 2012-01-23
US201261614408P 2012-03-22 2012-03-22
US61/614,408 2012-03-22
US201261645562P 2012-05-10 2012-05-10
US61/645,562 2012-05-10
US201261647414P 2012-05-15 2012-05-15
US61/647,414 2012-05-15
US13/563,590 2012-07-31
US13/563,590 US9015564B2 (en) 2009-08-19 2012-07-31 Content delivery system with allocation of source data and repair data among HTTP servers
PCT/US2012/063115 WO2013067219A2 (en) 2011-11-01 2012-11-01 Content delivery system with allocation of source data and repair data among http servers

Publications (2)

Publication Number Publication Date
JP2014533045A true JP2014533045A (ja) 2014-12-08
JP5795446B2 JP5795446B2 (ja) 2015-10-14

Family

ID=51266046

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2014540098A Expired - Fee Related JP5795446B2 (ja) 2011-11-01 2012-11-01 Ｈｔｔｐサーバの間でのソースデータおよび修復データの割り当てを伴うコンテンツ配送システム

Country Status (6)

Country Link
EP (1) EP2774347A2 (ja)
JP (1) JP5795446B2 (ja)
KR (1) KR101591238B1 (ja)
CN (1) CN104067594A (ja)
IN (1) IN2014CN02992A (ja)
WO (1) WO2013067219A2 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20170124950A (ko) * 2015-03-04 2017-11-13 소니 주식회사 수신 장치, 수신 방법, 송신 장치, 및 송신 방법

Families Citing this family (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20150081761A1 (en) * 2013-09-17 2015-03-19 Nvidia Corporation Determining format compatibility across a data processing device and another data processing device prior to transfer of a multimedia file therebetween
US9350484B2 (en) * 2014-03-18 2016-05-24 Qualcomm Incorporated Transport accelerator implementing selective utilization of redundant encoded content data functionality
US9596323B2 (en) 2014-03-18 2017-03-14 Qualcomm Incorporated Transport accelerator implementing client side transmission functionality
US20150271225A1 (en) 2014-03-18 2015-09-24 Qualcomm Incorporated Transport accelerator implementing extended transmission control functionality
US9596281B2 (en) 2014-03-18 2017-03-14 Qualcomm Incorporated Transport accelerator implementing request manager and connection manager functionality
US20170171606A1 (en) * 2014-04-30 2017-06-15 Lg Electronics Inc. Broadcast signal transmitting device, broadcast signal receiving device, broadcast signal transmitting method, and broadcast signal receiving method
US10164738B2 (en) * 2015-12-16 2018-12-25 Qualcomm Incorporated Interlacing method for high throughput forward error correction
US10599634B2 (en) * 2016-06-19 2020-03-24 Qualcomm Incorporated Signaling which version information to use on byte-range file repair
WO2018209658A1 (zh) * 2017-05-18 2018-11-22 深圳市大疆创新科技有限公司 数据传输方法、设备、机器可读存储介质以及系统
US10833710B2 (en) 2017-06-29 2020-11-10 Cisco Technology, Inc. Bandwidth efficient FEC scheme supporting uneven levels of protection
US11582125B2 (en) * 2019-10-01 2023-02-14 Qualcomm Incorporated Repair mechanism for adaptive bit rate multicast
CN111093110B (zh) 2019-12-03 2021-02-12 华为技术有限公司 一种http请求传输方法及设备
CN113393547B (zh) * 2021-05-25 2023-03-24 上海联影医疗科技股份有限公司 Pet符合数据量控制方法、装置、设备和存储介质

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2007520961A (ja) * 2004-02-13 2007-07-26 ノキア コーポレイション 欠落部分の識別および再送信
JP2008508761A (ja) * 2004-07-30 2008-03-21 ノキア コーポレイション ポイント・ツー・マルチポイント送信システム用のポイント・ツー・ポイントリペア要求メカニズム
JP2010114844A (ja) * 2008-11-10 2010-05-20 Ntt Docomo Inc データ受信装置、及び、データ受信方法

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5617541A (en) 1994-12-21 1997-04-01 International Computer Science Institute System for packetizing data encoded corresponding to priority levels where reconstructed data corresponds to fractionalized priority level and received fractionalized packets
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
CN1225860C (zh) * 2001-11-28 2005-11-02 华为技术有限公司 一种混合自动重传方法
US20030227934A1 (en) * 2002-06-11 2003-12-11 White Eric D. System and method for multicast media access using broadcast transmissions with multiple acknowledgements in an Ad-Hoc communications network
ES2443823T3 (es) 2002-06-11 2014-02-20 Digital Fountain, Inc. Descodificación de códigos de reacción en cadena por inactivación
JP4546246B2 (ja) 2002-10-05 2010-09-15 デジタル ファウンテン， インコーポレイテッド 連鎖的暗号化反応の系統的記号化および復号化
KR101161193B1 (ko) 2004-05-07 2012-07-02 디지털 파운튼, 인크. 파일 다운로드 및 스트리밍 시스템
US7644335B2 (en) 2005-06-10 2010-01-05 Qualcomm Incorporated In-place transformations with applications to encoding and decoding various classes of codes
US9270414B2 (en) 2006-02-21 2016-02-23 Digital Fountain, Inc. Multiple-field based code generator and decoder for communications systems
WO2010049585A1 (en) 2008-10-30 2010-05-06 Nokia Corporation Method and apparatus for interleaving a data block

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2007520961A (ja) * 2004-02-13 2007-07-26 ノキア コーポレイション 欠落部分の識別および再送信
JP2008508761A (ja) * 2004-07-30 2008-03-21 ノキア コーポレイション ポイント・ツー・マルチポイント送信システム用のポイント・ツー・ポイントリペア要求メカニズム
JP2010114844A (ja) * 2008-11-10 2010-05-20 Ntt Docomo Inc データ受信装置、及び、データ受信方法

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
JPN6015009529; Ｄａｖｉｄ　Ｇｏｍｅｚ-Ｂａｒｑｕｅｒｏ　ｅｔ　ａｌ．: 'Ｍｕｌｔｉｃａｓｔ　Ｄｅｌｉｖｅｒｙ　ｏｆ　Ｆｉｌｅ　Ｄｏｗｎｌｏａｄ　Ｓｅｒｖｉｃｅｓ　ｉｎ　Ｅｖｏｌｖｅｄ　３Ｇ　Ｍｏｂｉｌｅ　Ｎｅｔｗｏｒｋｓ　Ｗｉｔｈ　ＨＳＤＰＡ　ａｎｄ　ＭＢＭＳ' ＩＥＥＥ　Ｔｒａｎｓａｃｔｉｏｎｓ　ｏｎ　Ｂｒｏａｄｃａｓｔｉｎｇ Ｖｏｌ．５５，　Ｎｏ．４, 200912, ｐｐ．７４２-７５１ *
JPN6015009531; Ｑｕａｌｃｏｍｍ　Ｉｎｃｏｒｐｏｒａｔｅｄ　ｅｔ　ａｌ．: 'ＭＢＭＳ　Ｆｉｌｅ　Ｒｅｐａｉｒ　ｖｉａ　Ｃｏｎｖｅｎｔｉｏｎａｌ　ＨＴＴＰ　Ｗｅｂ　Ｓｅｒｖｅｒｓ' ３ＧＰＰ　Ｓ４-１２００４６　［ｏｎｌｉｎｅ］ , 20120125 *

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20170124950A (ko) * 2015-03-04 2017-11-13 소니 주식회사 수신 장치, 수신 방법, 송신 장치, 및 송신 방법
US11490138B2 (en) 2015-03-04 2022-11-01 Saturn Licensing Llc Reception apparatus, reception method, transmission apparatus, and transmission method for indicating presence or absence of signaling information in a payload of a packet
KR102515018B1 (ko) * 2015-03-04 2023-03-29 소니그룹주식회사 수신 장치, 수신 방법, 송신 장치, 및 송신 방법

Also Published As

Publication number Publication date
WO2013067219A3 (en) 2013-07-11
IN2014CN02992A (ja) 2015-07-03
WO2013067219A2 (en) 2013-05-10
KR20140089405A (ko) 2014-07-14
EP2774347A2 (en) 2014-09-10
KR101591238B1 (ko) 2016-02-18
CN104067594A (zh) 2014-09-24
JP5795446B2 (ja) 2015-10-14

Similar Documents

Publication Publication Date Title
JP5795446B2 (ja) Ｈｔｔｐサーバの間でのソースデータおよび修復データの割り当てを伴うコンテンツ配送システム
US9350488B2 (en) Content delivery system with allocation of source data and repair data among HTTP servers
JP5788988B2 (ja) 不均一誤り保護および一括ファイル配信サービスを提供するための汎用ファイル配信の方法
US9294226B2 (en) Universal object delivery and template-based file delivery
JP5542872B2 (ja) メディアコンテナファイルの管理
AU2005268492B2 (en) Point-to-point repair request mechanism for point-to-multipoint transmission systems
US7853856B2 (en) Forming of error correction data
JP6604640B2 (ja) 放送システムにおけるマルチメディアデータの転送装置及び方法
CN104737518B (zh) 用于数据表示和传输的系统和方法
US9294227B2 (en) LT staircase FEC code
US8484540B2 (en) Data transmitting device, control method therefor, and program
JPWO2012011473A1 (ja) 送信装置、送信方法、受信装置、受信方法、通信システム、データ構造、プログラム、及び、記憶媒体
Nazir et al. Application layer systematic network coding for sliced H. 264/AVC video streaming
Gasiba et al. Reliable and efficient download delivery with Raptor codes
JP2010130472A (ja) 一方向伝送路に用いる送信端末、受信端末及び伝送システム
JP2023549779A (ja) カスタマイズされたオーディオ及び／又はビデオコンテンツ配信のための方法及びシステム

Legal Events

Date Code Title Description
A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20150220

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20150310

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20150610

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

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20150812

R150 Certificate of patent or registration of utility model

Ref document number: 5795446

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

LAPS Cancellation because of no payment of annual fees