JP6445527B2 - ブロードキャスト／マルチキャスト対応ネットワークを通じたオブジェクトのフローの配信のための方法 - Google Patents

ブロードキャスト／マルチキャスト対応ネットワークを通じたオブジェクトのフローの配信のための方法 Download PDF

Info

Publication number
JP6445527B2
JP6445527B2 JP2016507689A JP2016507689A JP6445527B2 JP 6445527 B2 JP6445527 B2 JP 6445527B2 JP 2016507689 A JP2016507689 A JP 2016507689A JP 2016507689 A JP2016507689 A JP 2016507689A JP 6445527 B2 JP6445527 B2 JP 6445527B2
Authority
JP
Japan
Prior art keywords
source
flow
fec
repair
objects
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.)
Active
Application number
JP2016507689A
Other languages
English (en)
Other versions
JP2016521494A5 (ja
JP2016521494A (ja
Inventor
マイケル・ジョージ・ルビー
トーマス・シュトックハンマー
Original Assignee
クアルコム，インコーポレイテッド
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by クアルコム，インコーポレイテッド filed Critical クアルコム，インコーポレイテッド
Publication of JP2016521494A publication Critical patent/JP2016521494A/ja
Publication of JP2016521494A5 publication Critical patent/JP2016521494A5/ja
Application granted granted Critical
Publication of JP6445527B2 publication Critical patent/JP6445527B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/16—Arrangements for providing special services to substations
    • H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/06—Selective distribution of broadcast services, e.g. multimedia broadcast multicast service [MBMS]; Services to user groups; One-way selective calling services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/16—Arrangements for providing special services to substations
    • H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
    • H04L12/1863—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast comprising mechanisms for improved reliability, e.g. status reports
    • H04L12/1868—Measures taken after transmission, e.g. acknowledgments
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/16—Arrangements for providing special services to substations
    • H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
    • H04L12/1886—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast with traffic restrictions for efficiency improvement, e.g. involving subnets or subdomains
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/16—Arrangements for providing special services to substations
    • H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
    • H04L12/189—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast in combination with wireless systems
    • 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
    • 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/60—Network streaming of media packets
    • H04L65/65—Network streaming protocols, e.g. real-time transport protocol [RTP] or real-time control protocol [RTCP]
    • 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/06—Protocols specially adapted for file transfer, e.g. file transfer protocol [FTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/22—Parsing or analysis of headers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/83—Generation or processing of protective or descriptive data associated with content; Content structuring
    • H04N21/845—Structuring of content, e.g. decomposing content into time segments
    • H04N21/8456—Structuring of content, e.g. decomposing content into time segments by decomposing the content in the time domain, e.g. in time segments
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/85—Assembly of content; Generation of multimedia applications
    • H04N21/854—Content authoring
    • H04N21/85406—Content authoring involving a specific file format, e.g. MP4 format

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Multimedia (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Information Transfer Between Computers (AREA)
  • Computer Security & Cryptography (AREA)
  • Telephonic Communication Services (AREA)

Description

関連出願
本出願は、2013年4月12日に出願された「Methods for Delivery of Flows of Objects over Broadcast/Multicast Enabled Networks」という表題の米国仮出願第61/811,693号、2013年5月2日に出願された「Methods for Delivery of Flows of Objects over Broadcast/Multicast Enabled Networks」という表題の米国仮出願第61/818,912号、2013年9月16日に出願された「Methods for Delivery of Flows of Objects over Broadcast/Multicast Enabled Networks」という表題の米国仮出願第61/878,368号、および2013年12月5日に出願された「Methods for Delivery of Flows of Objects over Broadcast/Multicast Enabled Networks」という表題の米国仮出願第61/912,145号の各々の優先権の利益を主張し、これらの仮出願のすべての内容全体が参照によって本明細書に組み込まれる。
ワイヤレス通信技術は、過去数年にわたって爆発的な発展をとげてきた。ワイヤレスサービスプロバイダは現在、多数のサービスを顧客に提供し、情報、リソースおよび通信への、前例のないレベルのアクセスをユーザに提供している。ワイヤレス通信サービスに対する最近の追加は、テレビおよび他のコンテンツを受信機デバイスにブロードキャストするための能力であった。マルチメディアforward link only (FLO)ブロードキャストサービスは、ユーザが、テレビ番組のようなマルチメディア番組を見ること、さらには、ニュース、娯楽、スポーツ、ビジネス、インターネットデータ、データファイル、および他のコンテンツのモバイル版を、モバイルブロードキャスト送信を受信するように構成されたモバイル受信機デバイスを使用して受信することを、可能にする。マルチメディアブロードキャストサービスは、種々のサービスを受信機デバイスに配信するために使用され得る大量の帯域幅を代表するものである。
ブロードキャストサービスを配信するための1つのプロトコルは、File Delivery over Unidirectional Transport (FLUTE)であり、これは、Internet Engineering Task Force (IETF) Request for Comments (RFC) 3926およびRFC 6726において定義される。FLUTEは、数秒以上の配信セッションを使用した、多くのホストへの大きなファイルおよび小さなファイルの配信のために使用され得る。たとえば、FLUTEは、大きなソフトウェア更新を多くのホストに同時に配信するために使用され得る。FLUTEはまた、セッションの豊かさをネットワークの混雑状態へと合わせるために、Asynchronous Layered Coding (ALC、IETF RFC 3450およびIETF RFC 5775において規定されるような)およびLayered Coding Transport (LCT、IETF RFC 3451およびIETF RFC 5651において規定されるような)からのレイヤリング継承物を場合によっては利用した、字幕のための時間順に並べられたテキストのような、連続的であるがセグメント化されたデータのために使用され得る。FLUTEはまた、メタデータ、たとえば、ユーザのアプリケーションがマルチメディアセッションにアクセスすることを可能にするセッション記述プロトコル(SDP)ファイルの基本的なトランスポートに適している。FLUTEは、マルチキャスト配信とユニキャスト配信の両方で使用され得るが、その主要な適用は、単方向のマルチキャストファイル配信に対するものである。
ストリーム、たとえばビデオストリームおよび/またはオーディオストリームを、ファイルのシーケンスとして単方向ユニキャストシステムを通じて配信するという、最近の傾向がある。たとえば、3GPP MBMSシステムにおける主要なストリーミング配信機構は、ストリームのRTP配信から、DASH(ISO/IEC 23009-1で規定されるようなMPEG Dynamic Adaptive Streaming over HTTPおよびTS26.247で規定されるDASHの3GPPバージョン)フォーマットされたストリーミングコンテンツのFLUTEを使用した配信へと、過去数年にわたって進化してきており、DASHフォーマットされたストリーミングコンテンツのFLUTEを使用した配信では、通常は等しい時間長のストリーミングコンテンツはDASHセグメントファイルとしてフォーマットされ、次いで、各DASHセグメントファイルがFLUTEプロトコルを使用してオブジェクトとして配信される。しかしながら、FLUTEはそのようなストリーミング用途のために特別に設計されたものではないので、この状況ではある程度の制約がある。
様々な態様は、関連するソースオブジェクトの集合体をソースフローと関連付けて、ソースオブジェクトが互いに対する関係に基づいて受信機デバイスによって受信され復元され得るように、ブロードキャストネットワークを通じてソースフローと関連付けられる関連するソースオブジェクトの集合体の中のソースオブジェクトを送信することによって、ブロードキャストネットワークを介して情報を送信する方法を含む。ある態様では、方法は、ソースフローのソースフロー識別子を決定するステップと、ソースフローと関連付けられる関連するソースオブジェクトの集合体の中の少なくとも1つのソースオブジェクトのデータを含み得るパケットに、ソースフロー識別子を含めるステップとを含み得る。
さらなる態様では、方法は、パケット中のバイト範囲を使用してパケット中のデータを特定するステップを含み得る。さらなる態様では、方法は、パケット中のソースオブジェクトのデータを特定するバイト範囲をパケットに含めるステップを含み得る。さらなる態様では、方法は、ソースフロー識別子としてパケットの送信セッション識別子(TSI)フィールドを使用するステップを含み得る。さらなる態様では、パケットにソースフロー識別子を含めるステップは、パケットのTSIフィールドにソースフロー識別子を含めるステップを伴い得る。さらなる態様では、方法は、パケットのインターネットプロトコル(IP)宛先アドレスフィールドとユーザデータグラムプロトコル(UDP)ポート番号フィールドとの組合せを、ソースフロー識別子として使用するステップを含み得る。さらなる態様では、パケットにソースフロー識別子を含めるステップは、インターネットプロトコル(IP)宛先アドレスフィールドとUDPポート番号フィールドとの組合せにソースフロー識別子を含めるステップを含み得る。
さらなる態様では、方法は、ソースフロー識別子としてパケットのコードポイント(CP)フィールドを使用するステップを含み得る。さらなる態様では、パケットにソースフロー識別子を含めるステップは、データパケットのコードポイント(CP)フィールドにソースフロー識別子を含めるステップを含み得る。さらなる態様では、関連するソースオブジェクトの集合体を送信するステップは、関連するソースオブジェクトの複数の集合体を送信するステップを含んでよく、各集合体は複数の異なるソースフローの1つと関連付けられ、複数の異なるソースフローの各々は固有のソースフロー識別子を含む。この態様では、ソースフローと関連付けられる関連するソースオブジェクトの集合体の中の少なくとも1つのソースオブジェクトのデータを含み得るパケットにソースフロー識別子を含めるステップは、そのソースオブジェクトのデータを含み得るパケットにソースフローの固有のソースフロー識別子を含めるステップを含み得る。
さらなる態様では、関連するソースオブジェクトの集合体を送信するステップは、FEC修復データ、修復フロー識別子、および修復オブジェクト識別子を含み得る少なくとも1つのパケットを送信するステップを含んでよく、方法はさらに、修復フローを複数の異なるソースフローの1つまたは複数と関連付けるステップと、修復フローの修復フロー識別子を決定するステップと、修復フローに対する修復オブジェクト識別子の集合体を決定するステップと、パケットの修復フロー識別子と修復オブジェクト識別子の集合体に少なくとも一部基づいて、関連付けられる複数のソースフローからのいずれのソースオブジェクトから、パケットに含まれるFEC修復データが生成されるかを決定するステップとを含む。
さらなる態様では、修復フロー識別子はTSIフィールドに含まれる。さらなる態様では、修復フロー識別子はインターネットプロトコル(IP)宛先アドレスフィールドとUDPポート番号フィールドとの組合せに含まれる。さらなる態様では、修復フロー識別子はコードポイント(CP)フィールドに含まれる。さらなる態様では、修復オブジェクト識別子は送信オブジェクト識別子(TOI)である。
さらなる態様では、修復オブジェクト識別子はオブジェクトシーケンス番号(OSN)である。さらなる態様では、FEC修復データを含み得る少なくとも1つのパケットを送信するステップは、FEC修復データを含み得る少なくとも1つのパケットを、対応するソースオブジェクトのためのデータを含み得るパケットと同じ時間間隔において送信するステップを含み得る。さらなる態様では、方法は、異なるソースフロー中の2つのソースオブジェクトからの、同じ修復フロー識別子および同じ修復オブジェクト識別子を有するパケットから、かつ、2つのソースオブジェクトの統合サイズ以上である2つのソースオブジェクトのいずれかに対するデータを含むパケットから、組合せで受信されるデータの量が、2つのソースオブジェクトを復号するのに十分であるように、同じ修復フロー識別子および同じ修復オブジェクト識別子を有するパケットに対するFEC修復データを生成するステップを含み得る。さらなる態様では、修復フロー識別子の部分は、FEC修復データを含み得るパケットの異なるデータフィールドに含まれる。
さらなる態様では、方法は、修復フロー宣言が、FEC修復データを含み得るパケット中の修復オブジェクト識別子と、パケット中のFEC修復データの生成元であるソースフローと関連付けられる関連するソースオブジェクトの集合体からのソースオブジェクトとの間の関係を、シグナリングするのに適した情報を含み得るように、修復フローのための修復フロー宣言を決定するステップを含み得る。さらなる態様では、方法は、テンプレートを使用して修復フロー宣言を介して関係をシグナリングするステップを含み得る。さらなる態様では、修復フロー宣言の部分は、修復フローと関連付けられるソースフローと関連付けられる少なくとも1つのソースオブジェクトより前に受信機デバイスに送信される。
さらなる態様では、方法は、関連するソースオブジェクトの集合体の中の各ソースオブジェクトのソースオブジェクト識別子を決定するステップと、ソースオブジェクトのためのデータを含む1つまたは複数のパケットにソースオブジェクト識別子を含めるステップとを含み得る。さらなる態様では、方法は、ソースフロー識別子とソースオブジェクト識別子の組合せを使用して、関連するソースオブジェクトの集合体の中の対応するソースオブジェクトを特定するステップを含み得る。さらなる態様では、データを含み得るパケットにソースオブジェクト識別子を含めるステップは、ソースフロー識別子とソースオブジェクト識別子との組合せが、関連するデータをパケットが搬送する対応するソースオブジェクトを特定するように、パケットにソースオブジェクト識別子を含めるステップを含み得る。さらなる態様では、方法は、ソースオブジェクト識別子としてTOIを使用するステップを含み得る。
さらなる態様では、方法は、ソースオブジェクト識別子としてOSNを使用するステップを含み得る。さらなる態様では、方法は、ソースオブジェクトが互いに対する関係に基づいて受信機デバイスによって受信され復元され得るように、ブロードキャストネットワークを通じて、ソースフローと関連付けられる関連するソースオブジェクトの集合体に対するFEC修復データを送信するステップを含んでよく、ソースフローと関連付けられる関連するソースオブジェクトの1つまたは複数に対するFEC修復データを含み得る各パケットは、関連するFEC修復データをパケットが含み得るソースフローを特定するソースフロー識別子を含んでよく、ソースフローと関連付けられる関連するソースオブジェクトの1つまたは複数に対するFEC修復データを含み得る各パケットは、パケット中で搬送されるFEC修復データの生成元である1つまたは複数のソースオブジェクトの1つまたは複数のソースオブジェクト識別子を搬送し、ソースフロー識別子と1つまたは複数のソースオブジェクト識別子との組合せは、パケット中で搬送されるFEC修復データの生成元であるソースフローと関連付けられる関連するソースオブジェクトの集合体からの1つまたは複数のソースオブジェクトを特定する。
さらなる態様では、方法は、1つまたは複数のソースオブジェクトから生成されたFEC修復データを搬送するパケットを、1つまたは複数のソースオブジェクトのためのデータを搬送するパケットと同じ時間の間隔において送信するステップを含み得る。さらなる態様では、ブロードキャストネットワークを通じてソースフローと関連付けられる関連するソースオブジェクトの集合体の中のソースオブジェクトを送信するステップは、ソースオブジェクトを対応する修復オブジェクトとは独立に送信するステップを含み得る。さらなる態様では、方法は、セッション記述プロトコル(SDP)情報を使用して、ソースオブジェクトを対応する修復オブジェクトと区別するステップを含み得る。
さらなる態様では、関連するソースオブジェクトの集合体の中の少なくとも1つのソースオブジェクトは、ファイルのバイト範囲を含み得る。さらなる態様では、ユニフォームリソースロケータ(URL)がそのファイルと関連付けられ、方法はさらに、URLおよびバイト範囲を介して少なくとも1つのソースオブジェクトを特定するステップを含む。さらなる態様では、関連するソースオブジェクトの集合体の中の少なくとも1つのソースオブジェクトはファイルである。さらなる態様では、URLがそのファイルと関連付けられ、方法はさらに、URLを介して少なくとも1つのソースオブジェクトを特定するステップを含む。さらなる態様では、関連するソースオブジェクトの集合体の中の少なくとも1つのソースオブジェクトは、ハイパーテキスト転送プロトコル(HTTP)ヘッダとファイルのバイト範囲とを含み得る。さらなる態様では、ソースオブジェクトの少なくともいくつかは、HTTPヘッダ、関連付けられたファイル、およびHTTPトレーラを含み得る。
さらなる態様では、方法は、ソースフロー宣言が、位置、名前、利用可能時間、または、ソースフローと関連付けられるソースオブジェクトの集合体のための他のメタデータの間の関係をシグナリングするのに適した情報を含み得るように、ソースフローと関連付けられるソースオブジェクトの集合体のためのソースフロー宣言を決定するステップを含み得る。さらなる態様では、関連するソースオブジェクトの集合体を送信するステップは、マルチメディアブロードキャストマルチキャストサービス(MBMS)を介して関連するソースオブジェクトの集合体を送信するステップを含み得る。さらなる態様では、関連するソースオブジェクトの集合体を送信するステップは、file delivery over unidirectional transport (FLUTE)を介して関連するソースオブジェクトの集合体を送信するステップを含み得る。さらなる態様では、関連するソースオブジェクトの集合体を送信するステップは、前方誤り訂正(FEC)シグナリング情報を送信することなくソースオブジェクトを送信するステップを含み得る。さらなる態様では、ソースオブジェクトの少なくともいくつかは、HTTPヘッダとファイルのバイト範囲とを含む。
様々な態様はまた、ファイル全体の部分を受信するステップと、ファイル全体を受信する前にソースオブジェクトを受信された部分に基づいて生成するステップと、ファイル全体を受信する前に受信機デバイスへ生成されたソースオブジェクトを送信するステップとを含む、ブロードキャストネットワークを通じて1つまたは複数のソースオブジェクトを送信する方法を含む。ある態様では、ファイル全体を受信する前に受信機デバイスへ生成されたソースオブジェクトを送信するステップは、ファイル全体のデータ順序とは異なる順序で、生成されたソースオブジェクトのためのデータを送信するステップを含み得る。さらなる態様では、ファイル全体の部分を受信するステップは、ファイルの最初にファイルサイズを含み得るファイルの部分を受信するステップを含んでよく、ファイルサイズの後のファイルの少なくともいくつかのデータがファイルサイズよりも前に送信されるような順序で、ソースオブジェクトのデータが送信される。
さらなる態様では、ソースオブジェクトは、HTTPヘッダおよび関連付けられたファイルを含み得る。さらなる態様では、ソースオブジェクトは、HTTPヘッダ、関連付けられたファイル、およびHTTPトレーラを含み得る。さらなる態様では、方法は、ソースフローと関連付けられるソースオブジェクトの集合体のためのソースフロー宣言を決定するステップを含んでよく、ソースフロー宣言は、位置、名前、利用可能時間、または、ソースフローと関連付けられるソースオブジェクトの集合体のための他のメタデータの間の関係をシグナリングする。さらなる態様では、方法は、テンプレートを使用してソースフロー宣言中で関係性情報をシグナリングするステップを含み得る。
さらなる態様では、方法は、ソースフローと関連付けられる少なくとも1つの関連するソースオブジェクトより前に、ソースフローのためのソースフロー宣言の部分を受信機デバイスに送信するステップを含み得る。さらなる態様では、ソースフローと関連付けられる少なくとも1つの関連するソースオブジェクトより前に、ソースフローのためのソースフロー宣言の部分を受信機デバイスに送信するステップは、タイミング情報、ユニフォームリソース識別子(URI)、およびソースオブジェクトのための解読鍵を特定する情報の少なくとも1つを含み得る部分を送信するステップを含み得る。さらなる態様では、ソースフローと関連付けられる少なくとも1つの関連するソースオブジェクトより前に、ソースフローのためのソースフロー宣言の部分を受信機デバイスに送信するステップは、ソースフローと関連付けられる少なくとも1つのソースオブジェクトを送信する前にソースフロー宣言の部分を帯域外で受信機デバイスに送信するステップと、ソースフロー宣言の別の部分をソースオブジェクトとともに帯域内で送信するステップとを含み得る。
さらなる態様では、ソースフロー宣言の別の部分をソースオブジェクトとともに帯域内で送信するステップは、ソースオブジェクトのためのデータの最後の部分の指示を送信するステップを含み得る。さらなる態様では、ソースフロー宣言の部分を受信機デバイスに提供するステップは、ファイル配信テーブルを送信することなく、単方向トランスポートプロトコルを介してソースフロー宣言の部分を送信するステップを含み得る。さらなる態様では、ファイル全体を受信する前に受信機デバイスへ生成されたソースオブジェクトを送信するステップは、マルチメディアブロードキャストマルチキャストサービス(MBMS)を介して関連するソースオブジェクトの集合体を送信するステップを含み得る。さらなる態様では、ファイル全体を受信する前に受信機デバイスへ生成されたソースオブジェクトを送信するステップは、file delivery over unidirectional transport (FLUTE)を介して関連するソースオブジェクトの集合体を送信するステップを含み得る。
さらなる態様では、関連するソースオブジェクトの集合体を送信するステップは、ソースオブジェクトを対応する修復オブジェクトとは独立に送信するステップを含み得る。さらなる態様では、方法は、セッション記述プロトコル(SDP)情報を使用して、ソースオブジェクトを対応する修復オブジェクトと区別するステップを含み得る。さらなる態様では、ファイル全体を受信する前に受信機デバイスへ生成されたソースオブジェクトを送信するステップは、FECシグナリング情報を送信することなくソースオブジェクトを送信するステップを含み得る。
さらなる態様では、方法は、FEC動作を実行して個々のソースオブジェクトの部分を保護するステップを含み得る。さらなる態様では、方法は、複数のFEC符号化を伴って個々のソースオブジェクトを送信するステップを含み得る。さらなる態様では、方法は、ソースオブジェクトの保護される部分のためのTOIまたはOSNを修復パケットヘッダに追加するステップと、保護される部分のバイト範囲をトランスポートソースブロックの最後に追加するステップとを含み得る。さらなる態様では、方法は、保護されるべきソースオブジェクトの部分の最初にソースシンボルを追加するステップと、保護される部分のバイト範囲を修復パケットヘッダに追加するステップとを含み得る。
さらなる態様では、方法は、ソースオブジェクトの保護される部分のバイト範囲の開始位置およびバイト範囲によって包含されるシンボルの数を修復パケットヘッダに追加するステップと、保護される部分のバイト単位またはオクテット単位のサイズをトランスポートソースブロックの最後に追加するステップとを含み得る。さらなる態様では、ファイル全体を受信する前に受信機デバイスへ生成されたソースオブジェクトを送信するステップは、ソースオブジェクトが定期的に配信されるHTTPリソースとして受信機デバイスにおいて使用するのに適するように、HTTPエンティティヘッダとHTTPエンティティボディの組合せとして、単方向プロトコルを介してソースオブジェクトを受信機デバイスに配信するステップを含み得る。
さらなる態様は、上で論じられた方法に対応する様々な動作を実行するように、プロセッサ実行可能命令によって構成された送信機およびコンピューティングデバイスを含む通信システムを含み得る。
さらなる態様は、上で論じられた方法動作に対応する機能を実行するための様々な手段を有する通信システムを含み得る。
さらなる態様は、上で論じられた方法動作に対応する様々な動作を通信システム中のコンピューティングデバイスに実行させるように構成される、プロセッサ実行可能命令を記憶した非一時的コンピュータ可読記憶媒体を含み得る。
本明細書に組み込まれ本明細書の一部を構成する添付の図面は、上で与えられた全般的な説明および以下で与えられる詳細な説明とともに、本発明の例示的な実施形態を示し、本発明の特徴を説明する役割を果たす。
様々な実施形態において使用するのに適したモバイルマルチメディア通信システムを示すブロック図である。 様々な実施形態によって使用され得る様々なハードウェアおよびソフトウェアのプロトコル層とモジュールとを通じた情報の流れを示すスタック図である。 様々な実施形態による、各オブジェクトがフローと関連付けられるように、マルチメディアコンテンツをモバイル受信機デバイスに配信するのに適した例示的なブロードキャスト通信システムの様々な論理的および機能的コンポーネントを示すブロック図である。 ある実施形態による、複数のソースパケットへとパッケージングされるソースオブジェクトを示すブロック図である。 現在のFLUTEオブジェクトと実施形態のFLUTEオブジェクトとの差を示すブロック図である。 HTTPヘッダフィールドおよび利用可能時間フィールドを含むある実施形態のFLUTEオブジェクトを示す図である。 ソースオブジェクトフィールド、パディングフィールド、およびサイズ/長さ(F)フィールドを含む実施形態のトランスポートオブジェクトを示す図である。 ソースオブジェクトフィールド、パディングフィールド、およびバイト範囲フィールドを含む実施形態のトランスポートオブジェクトを示す図である。 現在のFLUTE修復前方誤り訂正(FEC)ペイロードIDと様々な実施形態の修復FECペイロードIDとの差を示すブロック図である。 現在のFLUTE修復前方誤り訂正(FEC)ペイロードIDと様々な実施形態の修復FECペイロードIDとの差を示すブロック図である。 ある実施形態による、同期されたソースフローのための前方誤り訂正(FEC)を実行する際に使用するのに適した通信パケット中のデータフィールドを示すブロック図である。 ある実施形態による、同期されたソースフローのための前方誤り訂正(FEC)を実行する際に使用するのに適した通信パケット中のデータフィールドを示すブロック図である。 ある実施形態による、2つの同期されたソースフローのための前方誤り訂正(FEC)動作を実行する際に使用するのに適した通信パケットのデータフィールドを示すブロック図である。 ある実施形態による、2つの同期されていないソースフローのための前方誤り訂正(FEC)動作を実行する際に使用するのに適した通信パケットのデータフィールドを示すブロック図である。 ある実施形態による、3つの同期されていない短いソースフローのための前方誤り訂正(FEC)を実行する際に使用するのに適した通信パケットのデータフィールドを示すブロック図である。 ブロードキャストネットワークまたはマルチキャストネットワークを通じてオブジェクトのフローで情報を通信するある実施形態のサーバの方法を示すプロセスフロー図である。 ブロードキャストネットワークまたはマルチキャストネットワークを通じてオブジェクトのフローで情報を受信し、ソースオブジェクト全体が受信されたかどうか、またはオブジェクトの部分が受信されたソースパケットから欠けているかどうかを決定する、ある実施形態の受信機デバイスの方法を示すプロセスフロー図である。 様々な実施形態による、コンテンツを通信するのに適したブロードキャスト通信システムの様々な論理的および機能的コンポーネントを示すブロック図である。 様々な実施形態による、コンテンツを通信するのに適したブロードキャスト通信システムの様々な論理的および機能的コンポーネントを示すブロック図である。 2つのソースオブジェクトに基づいて前方誤り訂正(FEC)修復パケットを生成するように構成される、ある実施形態のFECフレームワーク中の、様々な構造、データフィールド、通信パケット、変換、および情報の流れを示すブロック図である。 実施形態のいずれかとともに使用するのに適した受信機デバイスのシステムブロック図である。 実施形態のいずれかとともに使用するのに適したサーバコンピュータのシステムブロックである。
様々な実施形態が添付の図面を参照しながら詳細に説明される。可能な場合には常に、同じ参照番号が、同じ部分または同様の部分を指すために、図面全体を通じて使用される。特定の例および実装形態へと行われる言及は、説明を目的とし、本発明の範囲または特許請求の範囲を限定するものではない。
概略的に、様々な実施形態は、コンテンツ(たとえば、マルチメディアストリーム、オーディオ-ビデオストリーム、ビデオファイル、テキストなど)を、ブロードキャストチャンネルを通じて、かつ/またはブロードキャストネットワークを介して、受信機デバイスへ効率的に配信するための、システム、デバイス、方法、およびソフトウェアを記憶する非一時的コンピュータ可読記憶媒体を提供することができる。様々な実施形態は、既存のブロードキャストの解決法を上回る、いくつかの機能、増強、改善、および利益をもたらすことができる。
たとえば、実施形態は、ブロードキャストネットワークを通じて通信される情報の量を減らし、通信によって消費されるネットワーク帯域幅の量を減らし、通信される個々のオブジェクトに対する厳密なタイミング要件を満たし、各受信機デバイスがその受信機デバイスの過剰な量のバッテリーまたは処理リソースを消費することなくコンテンツを受信し、復号し、レンダリングすることを可能にする方式で、コンテンツを受信機デバイスに通信するように構成されるコンポーネント(たとえば、サーバ、受信機デバイス、ソフトウェアアプリケーション、モジュール、プロセスなど)を含み得る。
実施形態はまた、関連するオブジェクトのフロー(または関連するオブジェクトの集合体もしくはグループ)が互いに対する関係に基づいて受信機デバイスによって受信され、復号され、処理され得るように、単一のフロー、ストリーム、または通信チャンネルにおいて、FLUTEを介して、かつ/またはブロードキャストネットワークを通じて、関連するオブジェクトのフローを送信するように構成されるコンポーネントを含み得る。
実施形態は、ネットワークを通じて通信される情報の量と、コンテンツをレンダリングするときに受信機デバイスによって受信され、復号され、誤り訂正される情報の量とを減らすために、コンテンツがブロードキャストシステムを通じてどのように配信されるべきかを調整するための、シグナリング情報(たとえば、チャンネル設定、セキュリティ、コンテンツ配信などに関する情報)を送信するように構成されるコンポーネントを含み得る。
実施形態は、ソースオブジェクトが受信機デバイスに送信されるときより前に、かつ/または、ソースオブジェクトが受信機デバイスによって受信されるときより前に、オブジェクト情報を受信機デバイス(たとえば、FLUTE受信機)に送信するように構成されるコンポーネントを含み得る。
実施形態は、情報が入手可能になるとサンプルまたはオブジェクトをブロードキャストし、既存のFLUTEベースの解決法およびシステムに適合しながら各サンプル/オブジェクトに対する非常に正確なタイミングを達成し、これによって、既存のパケットベースのストリーミングシステムによって提供される機能と既存のブロードキャストオブジェクトベースのストリーミングシステムによって提供される機能のハイブリッド/組合せを達成するように構成されるコンポーネントを含み得る。
実施形態は、ファイル配信テーブル(FDT)を使用することなく、FLUTEベースの通信を遂行するように構成されるコンポーネントを含み得る。ある実施形態では、コンポーネントは、FDTオブジェクトをブロードキャストすることなく、かつ、受信機デバイスが要求またはレンダリングされるそれぞれの実際のオブジェクト(たとえば、ソースオブジェクト)に対して2つのオブジェクトを受信することを必要とすることなく、FLUTEを介して、かつ/またはブロードキャストネットワークを通じて、オブジェクトを通信するように構成され得る。
実施形態は、オブジェクト配信が既存のDASHシステムの機能、動作、または要件と良好に揃うように、FLUTEを介して、かつ/またはブロードキャストネットワークを通じて、オブジェクトを配信するように構成されるコンポーネントを含み得る。ある実施形態では、コンポーネントは、ソースオブジェクトがDASH表現のDASHセグメントに適合するように、またはソースオブジェクトがDASH表現のDASHセグメントとして解釈され得るように、ソースオブジェクトをブロードキャストすることによって、ブロードキャスト配信ネットワークを通じてフローオブジェクト配信機構を介してDASHコンテンツを配信するように構成され得る。ある実施形態では、コンポーネントは、FLUTEベースのオブジェクトがDASHセグメントであることをシグナリングし、FLUTEベースのオブジェクトがDASHセグメントであるかのように受信機デバイスがFLUTEベースのオブジェクトを受信し処理できるようにFLUTEベースのオブジェクトをパッケージングするように構成され得る。
実施形態は、既存のFLUTEベースのオブジェクトおよびDASHベースのセグメントによって提供される機能/特性の組合せを含むオブジェクトまたはフォーマットで、シグナリング情報を生成し、ブロードキャストし、または受信するように構成されるコンポーネントを含み得る。
実施形態は、チャンク配信動作および/またはチャンク受信動作を実行するように構成されるコンポーネントを含み得る。
実施形態は、サイズが送信機によって任意に決定される、可変サイズのソースパケットを通信するように構成されるコンポーネントを含み得る。
実施形態は、前方誤り訂正(FEC)オブジェクトのバンドリング動作を実行するように構成されるコンポーネントを含み得る。
実施形態は、対応する修復オブジェクト(たとえば、FECオブジェクト)とは独立にソースオブジェクトを配信するように構成されるコンポーネントを含み得る。コンポーネントは、データパケットの中で帯域内で搬送される情報を介して、かつ/またはセッション記述プロトコル(SDP)情報を介して、ソースフローを修復フローと区別することができる。
実施形態は、FECセマンティクス(たとえば、FEC符号化ID、「非符号FEC」セマンティックなど)を含まないソースコンテンツを通信し、FECセマンティクスを伴わずにソースコンテンツを配信し、かつ/またはFECをシグナリングする(すなわち、FECシグナリング情報を送信する)ことなくソースコンテンツを配信するように構成されるコンポーネントを含み得る。これは、FEC能力を備えない受信機デバイスが、FLUTEを介して、かつ/またはブロードキャストネットワークを通じて、ソースオブジェクトを受信し、復号し、復元することを可能にする。
実施形態は、個々のソースオブジェクトまたはDASHセグメントの部分を保護するためのFEC動作を実行して、複数のFEC符号化を伴ってソースオブジェクトが配信されることを可能にし、オブジェクト全体が受信機デバイスにおいて受信される前にオブジェクトがレンダリングされることを可能にするように構成されるコンポーネントを含み得る。
実施形態は、オブジェクトの部分が異なるラベルと関連付けられ得るように、ソースオブジェクトのためのシグナリング情報およびオブジェクト情報をパッケージングして通信するように構成されるコンポーネントを含み得る。コンポーネントは、Layered Coding Transport (LCT)コードポイントフィールドを使用して、そのパケット(すなわち、元のソースオブジェクトを含むパケット)で搬送されるコンテンツの「タイプ」を特定するように構成され得る。
実施形態は、バイト範囲を使用して、FEC保護されるソースオブジェクトの部分をシグナリングまたは特定するように構成されるコンポーネントを含み得る。
実施形態は、完全なソースファイル/オブジェクト、ユニフォームリソースロケータ(URL)、またはユニフォームリソース識別子(URI)のサブセットに基づいてソースオブジェクトを配信し保護するように構成されるコンポーネントを含み得る。
実施形態は、ソースオブジェクトの保護される部分に対する送信オブジェクト識別子(TOI)/オブジェクトシーケンス番号(OSN)の値を修復パケットヘッダに(たとえば、ヘッダ拡張部に)、かつ、ソースブロックの保護される部分のバイト範囲をトランスポートソースブロックの最後に追加するように構成されるコンポーネントを含み得る。コンポーネントはまた、(ソースオブジェクトの最初ではなく)保護されるべきソースオブジェクトの部分の最初にソースシンボルを追加または開始し、ファイル、配信、またはソースオブジェクトの保護される部分の実際のバイト範囲を修復パケットヘッダの中で直接提供するように構成され得る。コンポーネントはまた、バイト範囲の開始位置とバイト範囲によって包含されるシンボルの数とを修復パケットヘッダの中に直接追加し、保護されるソースオブジェクトの部分のバイト単位(または、本開示においては等価的にオクテット単位)のサイズをトランスポートソースブロックの最後(たとえば、FEC符号化オブジェクト)に追加するように構成され得る。コンポーネントはまた、ソースオブジェクトの送信オブジェクト識別子(TOI)またはオブジェクトシーケンス番号(OSN)、ソースオブジェクト内での開始バイト位置、およびソースオブジェクト内での終了バイト位置を含む、ソースオブジェクトの各々の保護される部分に対する修復パケットヘッダを有する修復パケットを生成するように構成され得る。
実施形態は、ソースオブジェクトが完全なHTTP応答を含むことを可能にするためにオブジェクト配信動作を実行するように構成されるコンポーネントを含み得る。コンポーネントはまた、オブジェクト(またはオブジェクトのバイト範囲)と関連付けられるデータが動的に配信されることを可能にするために、HTTPエンティティのボディおよびヘッダを(たとえば、配信オブジェクトとして)送信するように構成され得る。
実施形態は、ファイルまたはオブジェクトの全体がサーバまたは送信デバイスにおいて受信または生成される前に、早めにデータの送信を開始するように構成されるコンポーネントを含み得る。
実施形態は、すべての部分が受信または生成される前に、かつ/またはFEC方式とは独立に、ファイル/オブジェクトの部分を順序通りではなく送信するように構成されるコンポーネントを含み得る。ある実施形態では、これは、LCTの拡張能力を利用することによって、LCT機構を介して遂行され得る。
実施形態は、テンプレートまたはテンプレーティング技法を使用して、位置、名前、利用可能時間、および配信されるべきオブジェクトの集合体またはシーケンスと関連付けられる他のメタデータの間の関係をシグナリングするように構成されるコンポーネントを含み得る。ある実施形態では、コンポーネントは、ソースフロー宣言を使用して、オブジェクトのURIを特定し、オブジェクトがブロードキャスト/マルチキャストチャンネルを通じていつ送信および/または受信されるかを決定するように構成され得る。ある実施形態では、コンポーネントは、ワンタイムの静的ファイル配信記述子を受信機デバイスに送信し、動的配信プロトコル中のヘッダフィールドを使用して、有効なユニフォームリソース識別子(URI)を特定する情報のような動的な情報を作成するように構成され得る。
実施形態は、現在のFLUTE規格の要件に準拠しながら、かつ/または、現在のFLUTE規格を実装する他のコンポーネントとの後方互換性を維持しながら、上述の動作のいずれかまたはすべてを実行するように構成されるコンポーネントを含み得る。
「例示的な」という言葉は、例、事例、または例示として機能することを意味するように本明細書で使用される。本明細書で「例示的」として説明されるいかなる実装形態も、必ずしも他の実装形態よりも好ましいか、または有利であると解釈されるべきではない。
「受信機デバイス」という用語は、本明細書では、携帯電話、スマートフォン、マルチメディアプレーヤー、携帯情報端末(PDA)、コンピューティングデバイス、サーバコンピュータ、パーソナルコンピュータ、ラップトップコンピュータ、スマートブック、ウルトラブック、タブレットコンピュータ、パームトップコンピュータ、ワイヤレス電子メール受信機、マルチメディアインターネット対応携帯電話、ワイヤレスゲームコントローラ、ならびに、情報を送信し受信するための通信回路、メモリ、およびプログラム可能プロセッサを含む同様の電子デバイスの、いずれか1つまたはすべてを指すために使用される。
「ブロードキャスト」という用語は、本明細書では、データが多数の受信デバイスによって同時に受信され得るようなデータ(マルチメディアストリーム、ファイル、情報パケットなど)の送信を意味するために使用され、ユニキャスト、マルチキャスト、および、単一の送信で1つまたは多数の受信機デバイスに情報を送信するのに適した他の送信技法を包含する。ブロードキャストネットワークは送信することだけが可能であり直接の返信リンクを有さないので、そのようなネットワークはまた、携帯電話システムまたはワイヤレスワイドエリアネットワーク(たとえば、WiFi、WiMAXなど)のような双方向のワイヤレス通信ネットワークとそのような通信ネットワークを区別するために、「forward link ony」(FLO)ブロードキャストネットワークとも呼ばれる。
「配信オブジェクト」および「ソースオブジェクト」という用語は、本明細書では、メタデータまたはデータを含み、もしくはそれらとして表され、かつ、ワイヤレス通信技術またはブロードキャスト通信技術を使用して通信され得る、任意の独立したユニットを表すために交換可能に使用され得る。ソースオブジェクトの例は、ファイル、HTTPエンティティ、バイト範囲、エンティティヘッダおよびエンティティヘッダによって示される完全なファイルを含むエンティティボディ、ファイルのバイト範囲を示すエンティティヘッダ、エンティティヘッダによって示されるファイルの部分を含むエンティティボディなどを含む。
本出願で使用される場合、「コンポーネント」、「モジュール」、「システム」、「サービス」、「エンコーダ」、「送信機」、「受信機」などの用語は、限定はされないが、特定の動作または機能を実行するように構成された、ハードウェア、ファームウェア、ハードウェアとソフトウェアの組合せ、ソフトウェア、または実行中のソフトウェアのような、コンピュータ関連のエンティティを含むものとする。たとえば、コンポーネントは、限定はされないが、プロセッサ上で動作しているプロセス、プロセッサ、オブジェクト、実行ファイル、実行スレッド、プログラム、および/またはコンピュータであり得る。実例として、コンピューティングデバイス上で動作しているアプリケーションとコンピューティングデバイスの両方が、コンポーネントと呼ばれ得る。1つまたは複数のコンポーネントは、プロセスおよび/または実行スレッド内に存在することがあり、1つのコンポーネントは、1つのプロセッサに局在していることがあり、または2つ以上のコンピュータ間に分散していることがある。加えて、これらのコンポーネントは、様々な命令および/またはデータ構造を記憶している様々な非一時的コンピュータ可読媒体から実行することができる。コンポーネントは、ローカルプロセスおよび/またはリモートプロセス、関数呼出しまたはプロシージャ呼出し、電子信号、通信メッセージ、データパケット、メモリ読出し/書込み、ならびに他の知られているネットワーク、コンピュータ、プロセッサ、および/またはプロセス関連の通信方法によって通信することができる。
いくつかの異なるブロードキャストのサービス、規格、および技術が利用可能であり、または将来考えられ、それらのすべてが様々な実施形態を実装し、様々な実施形態から利益を受けることができる。そのようなサービス、規格、および技術は、たとえば、マルチメディアブロードキャスト/マルチキャストサービス(MBMS)、エンハンストマルチメディアブロードキャスト/マルチキャストサービス(eMBMS)、エンハンストマルチブロードキャストサービス(EMBS)、グローバルブロードキャストサービス(GBS)、open mobile alliance mobile broadcast services enabler suite (OMA BCAST)、MediaFLO(登録商標)、digital video broadcast Internet protocol datacasting (DVB-IPDC)、digital video broadcasting-handheld (DVB-H)、digital video broadcasting-satellite services to handhelds (DVB-SH)、digital video broadcasting-handheld 2 (DVB-H2)、advanced television systems committee-mobile/handheld (ATSC-M/H)、China multimedia mobile broadcasting (CMMB)、advanced television systems committee terrestrial (ATSC-T)、およびMPEG Media Transport (MMT)を含む。これらのブロードキャストの規格、サービス、および技術の各々は、たとえば、データ、シグナリング、および/またはコンテンツメッセージを通信するのに適した、ブロードキャスト通信チャンネルを含む。
上で言及されたブロードキャストサービスに加えて、マルチメディアサービスおよび他のサービスは、そのいずれかまたはすべてが様々な実施形態を実装でき様々な実装形態から利益を受けることができる、様々なセルラーおよびワイヤレスの通信サービスと規格を介して個々のモバイル受信機デバイスに直接配信され得る。そのようなサービスおよび規格は、たとえば、第3世代パートナーシッププロジェクト(3GPP)、long term evolution(LTE)システム、第3世代ワイヤレスモバイル通信技術(3G)、第4世代ワイヤレスモバイル通信技術(4G)、global system for mobile communications (GSM（登録商標）)、universal mobile telecommunications system (UMTS)、3GSM（登録商標）、general packet radio service (GPRS)、符号分割多元接続(CDMA)システム(たとえば、cdmaOne、CDMA1020TM)、enhanced data rates for GSM（登録商標） evolution (EDGE)、advanced mobile phone system (AMPS)、digital AMPS (IS-136/TDMA)、evolution-data optimized (EV-DO)、digital enhanced cordless telecommunications (DECT)、Worldwide Interoperability for Microwave Access (WiMAX)、wireless local area network (WLAN)、Wi-Fi Protected Access I & II (WPA、WPA2)、および、integrated digital enhanced network (iden)を含む。これらの技術の各々は、たとえば、音声、データ、シグナリング、および/またはコンテンツメッセージの送信および受信を伴う。
個々の規格または技術に関する用語および/または技術的詳細に対するいかなる参照も例示だけが目的であり、請求項の文言に具体的に記載されない限り、特許請求の範囲を特定の通信システムまたは通信技術に限定するものではないことを理解されたい。
一般に、受信機デバイス上でコンテンツを受信し、復号し、表示する動作は、受信機デバイスの大量の利用可能なリソース(CPU動作、バッテリー電力、メモリなど)を消費する。これは、部分的には、受信機デバイスによって受信され、復号され、誤り訂正されなければならないデジタル情報が大量であることによる。様々な実施形態は、コンテンツを受信またはレンダリングするときに受信機デバイスによって受信され、復号され、誤り訂正されなければならない情報の量を減らすことができる。
現在、マルチメディアコンテンツを配信するときにネットワークを通じて通信されなければならない情報の量を減らす、いくつかの容易に利用可能な圧縮技法(たとえば、moving picture experts group 「MPEG」圧縮)がある。しかしながら、そのような技法によって使用される圧縮方法の効率性とは無関係に、ユーザに満足のいくユーザ体験を提供するために、大量の情報がネットワークを通じて通信されなければならない。したがって、既存の圧縮技法は単独では、ネットワークを通じて通信される情報の量を適切に減らさず、または、受信機デバイスの性能もしくは電力消費特性を大きく改善しない。
配信ネットワークの状態を経時的に変化させる、ネットワークの変動(たとえば、リソースの利用可能性の変化)が存在することがある。これらの変動により、受信機デバイスは、パケットをドロップし、バッファアンダーランを引き起こし、または別様にユーザ体験に悪影響を与えるようになり得る。受信機デバイスのクライアントアプリケーション(たとえば、メディアプレーヤーなど)が、受信機デバイスに送信される、または受信機デバイスによって受信されるストリーミングのビットレートまたは品質を調整することによって、ネットワーク条件のそのような変化に応答することを、DASHのような様々な技術が可能にする。これらの技術は通常、生成側のインターネットプロトコル(IP)ネットワークを通じた配信のために、生のビデオファイルを読み込み、ファイルの複数のバージョン(「表現」と呼ばれる)を生成する、コンテンツ生成サーバを含む。
DASHは、クライアントアプリケーション(たとえば、メディアプレーヤーなど)が、ネットワークの変動、リソースの利用可能性、および/または他の適切な要因に基づいて、メディアプレゼンテーションのどの部分を受信するかを動的に選ぶことを可能にする、マルチレート符号化マルチメディアを記述するためのウェブ互換の国際規格である。DASHは、受信機デバイスに配信されるべきデータを符号化するセグメントへと各表現を区分することをサポートする。DASHは通常、セグメントと、セグメントが利用可能である時間と、セグメントを含むメディアの再生レートの指示とを告知するセグメント利用可能性タイムラインである、Media Presentation Description (MPD)を利用する。現在のシステムでは、MPDは、Over-the-Air(OTA)配信技術を介して受信機デバイスに提供される。
FLUTEは、ブロードキャスト/マルチキャスト配信ネットワークとともに使用するのに特によく適しているファイルの単方向配信のための、トランスポート層の技術/プロトコルである。FLUTEの解決法またはシステムは、Internet Engineering Task Force (IETF) Request for Comments (RFC) 3926およびRFC 6726で定義される通信機構を実装する、サーバおよび受信機デバイスを含み得る。
既存のFLUTE解決法は、ソースオブジェクト(たとえば、ファイル、セグメントなど)を互いに独立に配信し、一般に、同じフローに含まれる関連するソースオブジェクトの間の関係を確立することをサポートしない。結果として、既存の解決法を使用すると、ブロードキャストネットワーク中のサーバは、各オブジェクトのパラメータ、オブジェクトが記憶されるべき位置、オブジェクトがいつ配信される予定であるか、および他の同様の情報を、ソースオブジェクトの配信の前に、またはその間に、受信機デバイスへ独立にシグナリングする(すなわち、シグナリング情報または制御情報を含む通信メッセージを送信)することが必要である。FLUTE規格(RFC 3926およびRFC 6726)によれば、サーバは、その受信機デバイスに配信されるべき各ソースオブジェクトのために、そのようなシグナリング情報を送信しなければならない。それでも、各オブジェクトのためにそのようなシグナリング情報を通信することは、過剰な量のネットワークの利用可能な帯域幅を消費し、追加の処理、同期、またはメモリアクセス動作を受信機デバイスが実行することを必要とし、これらのいずれもが、受信機デバイスの性能および/または電力消費性能を下げ、もしくはユーザ体験を劣化させ得る。加えて、シグナリング情報のいずれかが失われる場合、オブジェクトは一般に回復され得ない。
様々な実施形態は、コンテンツまたはソースオブジェクトのフローを配信するときに通信される情報の量を減らすために、ブロードキャストネットワークにおける通信を管理するための、方法、デバイス、および方法を実施するように構成されるシステムを含み得る。
様々な実施形態は、関連するオブジェクトのフロー(またはオブジェクトの関連するグループの集合体)が互いに対する関係に基づいて受信され、復号され、処理され得るように、単一のフロー、ストリーム、または通信チャンネルにおいて、FLUTEを介して、かつ/またはブロードキャストネットワークを通じて、関連するオブジェクトのフローを送信するのに適した、配信フレームワークを提供することができる。これは、フロー中のFLUTEオブジェクトの間の関係を特定せず、関連しないオブジェクトを同じフローへとパッケージングし、受信デバイスが各FLUTEオブジェクトを復号するために独立のシグナリング情報およびデータを受信することを必要とする、既存のFLUTEベースの解決法とは対照的である。
様々な実施形態はまた、ネットワークを通じて通信される情報の量を減らす方式でコンテンツがブロードキャストシステムを通じてどのように配信されるべきかを調整するために、シグナリング情報(たとえば、チャンネル設定、セキュリティ、コンテンツ配信などに関する情報)を送信するように構成される、ネットワークブロードキャストサーバを含み得る。
ブロードキャストシステムを介してオブジェクト配信を遂行するための既存の解決法は、一般に、ブロードキャストネットワーク中のサーバが、ブロードキャストネットワークを通じて通信されるべき各オブジェクトに対して独立にシグナリング情報を送信することを必要とする。これは、部分的には、既存の解決法が、ブロードキャストネットワークを通じて、かつ/またはフローもしくは通信チャンネル内で通信される2つ以上のオブジェクトの間の関係を適切に確立または特定できないからである。これらの理由および他の理由で、既存の解決法は通常、コンテンツ情報を含むファイル/オブジェクトとは別のファイル/オブジェクトでシグナリング情報を送信する。FLUTEベースのシステムでは、そのようなシグナリング情報は通常ファイル配信テーブル(FDT)に含まれ、FDTは、ファイル配信セッション内で配信されるべきファイルと関連付けられる様々な特性を記述する。
既存のFLUTE解決法は、ファイル配信テーブル(FDT)を、FDTが記述するコンテンツを含むオブジェクトとは別のオブジェクトで受信機デバイスに送信する。したがって、既存のFLUTE解決法を使用すると、受信機デバイスは、要求またはレンダリングされるそれぞれのソースオブジェクト(たとえば、ビデオのセグメント)に対して2つのオブジェクト(たとえば、ビデオのセグメントおよびビデオのセグメントを記述するFDT)を受信することが必要とされる。さらに、FDTを含むパケット/オブジェクトが失われた場合、または脱落した場合、受信機デバイスは、ソースオブジェクト(たとえば、ビデオのセグメント)に含まれる情報を復元または復号することができないので、既存のFLUTE解決法は通常、受信の確率を上げるために各FDTオブジェクトを複数回ブロードキャストする。そのようなFDTオブジェクトの冗長なブロードキャストは、過剰な量のネットワークの利用可能な帯域幅を消費し得るブロードキャストリソースの非効率的な使用であり、サービスに合わせるときのより長い始動遅延のような、他の欠点を有する。
様々な実施形態は、FDTオブジェクトをブロードキャストすることなく、かつ、受信機デバイスが要求またはレンダリングされるそれぞれの実際のオブジェクト(すなわち、ソースオブジェクト)に対して2つのオブジェクトを受信することを必要とすることなく、FLUTEを介して、かつ/またはブロードキャストネットワークを通じて、オブジェクト(たとえば、ビデオのセグメントなど)を通信するように構成されるコンポーネントを含み得る。ある実施形態では、シグナリング情報とオブジェクト情報の少なくともある部分が、帯域内で一緒に、かつ/または単一のストリームもしくはチャンネルで通信され得る。そのような情報を帯域内で通信することは、ネットワークを通じて通信される情報の量を減らすことができ、ネットワークリソースのより効率的な使用である。
様々な実施形態は、ソースオブジェクトが受信機デバイスに送信されるときより前に、かつ/または、ソースオブジェクトが受信機デバイスによって受信されるときより前に、オブジェクト情報を受信機デバイス(たとえば、FLUTE受信機)に送信するように構成されるネットワークサーバを含み得る。そのようなオブジェクト情報は、タイミング情報、ファイルの名前および位置(たとえば、ファイルがどこでアプリケーションによって参照またはアクセスされることになるか)を規定するURI、オブジェクトが配信されて暗号化される場合にオブジェクトを解読するためにどの鍵を使用するか、および、配信されるべきソースオブジェクトに関する他の識別情報を含み得る。オブジェクトの関連するシーケンス(またはオブジェクトの集合体)のためのそのようなオブジェクト情報は、圧縮された形式で提供され得る。ある実施形態では、オブジェクト情報の部分はソースオブジェクトよりも前に受信機デバイスに帯域外で送信されてよく、オブジェクト情報の部分はFDTをブロードキャストすることなくソースオブジェクトとともに帯域内で送信されてよい。この方式で、様々な実施形態は、FLUTEベースの通信においてFDTを使用する必要を完全になくすことができる。
様々な実施形態は、受信機デバイスがよりインテリジェントな決定を行いソースオブジェクトの受信をより良好に計画することを可能にするために、ソースオブジェクトのためのシグナリング情報およびオブジェクト情報をパッケージングして通信するように構成される、ネットワークサーバを含み得る。これは、受信機デバイスに送信される予定であるオブジェクトに関する情報を、それらのオブジェクトが送信される前に、かつ/またはそれらのオブジェクトが受信機デバイスにおいて受信される前に、サーバが受信機デバイスに送信することによって遂行され得る。そのような情報を事前に入手できることは、受信機デバイスによるより良い決定および計画を支援する。
様々な実施形態は、受信機デバイスの1つまたは複数のクライアントアプリケーションへFLUTEを介してブロードキャストネットワークを通じて配信されているオブジェクトをリンクするように構成されるコンポーネントを含み得る。
様々な実施形態は、オブジェクト配信が既存のDASHシステムの機能、動作、または要件と良好に揃うように、FLUTEを介して、かつ/またはブロードキャストネットワークを通じて、オブジェクトを配信するように構成されるコンポーネントを含み得る。
様々な実施形態は、ブロードキャスト配信ネットワークを通じてフローオブジェクト配信機構を介してDASHコンテンツを配信するように構成されるコンポーネント(たとえば、ブロードキャストネットワーク中のサーバなど)を含み得る。ある実施形態では、これは、ソースオブジェクトがDASH表現のDASHセグメントに適合するように、またはDASH表現のDASHセグメントとして解釈され得るように、ソースオブジェクトをブロードキャストすることによって遂行され得る。
様々な実施形態は、FLUTEベースのオブジェクトがDASHセグメントであることをシグナリングし、FLUTEベースのオブジェクトがDASHセグメントであるかのように受信機デバイスがFLUTEベースのオブジェクトを受信し処理できるようにFLUTEベースのオブジェクトをパッケージングするように構成されるネットワークサーバを含み得る。
様々な実施形態は、既存のFLUTEベースのオブジェクトおよびDASHベースのセグメントによって提供される機能/特性の組合せを含むオブジェクトまたはフォーマットで、シグナリング情報を生成し、ブロードキャストし、または受信するように構成されるコンポーネントを含み得る。
様々な実施形態は、チャンク配信動作および/またはチャンク受信動作を実行するように構成されるコンポーネントを含み得る。そのようなチャンク配信動作は、ブロードキャストネットワーク中のサーバが、オブジェクトを、ソースエンコーダおよび/またはカプセル化ユニットもしくはモジュールによって完全に生成されるよりも前に送信するのを開始することを可能にし得る。たとえば、ブロードキャストネットワーク中のサーバは、コンテンツが利用可能になるのを完全に10秒待つことなく、10秒のビデオを含むことになるオブジェクトを送信することができる。すなわち、コンテンツが利用可能になるのを完全に10秒待つのではなく、サーバは、チャンク配信動作を実行して、サーバによって他の部分が受信される前にビデオの第1の部分を送信するのを開始することができる。ある実施形態では、サーバは、送信遅延を最小化するために、アクセスユニットまたはネットワーク抽象化層ユニットまたはサンプルのカプセル化されたバージョンを、別個のソースパケットとして送信することができる。同様に、受信機デバイスは、チャンク受信動作を実行して、ソースオブジェクト全体が受信機デバイスにおいて受信される前に、オブジェクトの受信、復号、および使用を開始することができる。たとえば、受信機デバイスは、チャンク受信動作を実行して、ビデオを含むオブジェクト全体が受信機デバイスにおいて受信される前に、ビデオコンテンツの部分を再生するのを開始するように構成され得る。
様々な実施形態は、可変サイズのソースパケットをサポートするように構成されるコンポーネントを含み得る。すなわち、既存のFLUTEの規格および解決法は、各ソースパッケージおよび各修復パッケージが同じサイズである(または少なくとも所定のシンボルサイズの倍数である)ことを必要とする。既存のFLUTEの規格および解決法とは対照的に、様々な実施形態は、可変サイズのソースパケットを生成し、送信し、受信し、復号し、または使用するように構成されるコンポーネントを含み得る。そのような可変サイズのパケットで搬送されるコンテンツの境界は、完全に任意に設定されることがあり、かつ/または、背後のコンテンツの構造、たとえば、ビデオコンテンツのアクセスユニット/モジュール構造またはネットワーク抽象化層ユニット/モジュール構造と揃っていることがある。そのような可変サイズのパケットの使用は、ソースパケットの境界がシンボル構造と揃っている可能性があるとき(たとえば、FECを使用するときなど)に特に有利である。また、そのようなパケットの喪失は、複数のユニット/モジュールではなく単一のアクセスユニット/モジュールにしか影響を与えないことがあり、適切に構成された受信機デバイスは、受信されたコンテンツをレンダリングして体良く下げられた品質を提供するために受信機デバイス(または受信機デバイスのソフトウェアアプリケーション)によって処理され得る、部分的に受信されたオブジェクトを生成することができる。
様々な実施形態は、FECセマンティクスを含まないソースコンテンツを通信するのに適した動作を実行するように構成されるコンポーネントを含み得る。すなわち、既存のFLUTEの規格および解決法は一般に、ソース配信動作が復元動作のために使用されるFEC符号およびFEC方式と密接に結び付けられるように、ソース配信動作がシグナリングされ実行されることを必要とする。これは、限定はされないが、一定のサイズのソースシンボルの使用を含み、最後のパケット以外のすべてのソースパケットがソースシンボルサイズの倍数であること、FECを適用するための基本ユニットとしてソースシンボルを使用することなどを必要とする。これらの理由および他の理由で、既存の解決法は、非FEC符号がサポートされない、必要とされない、または使用されない状況であっても、「非符号FEC」セマンティックの使用を必要とする。しかしながら、FEC能力を備えない受信機デバイスは、FECセマンティクスを含むオブジェクトを受信し、復号し、または復元できないことがある。
様々な実施形態は、FEC能力を備えない受信機デバイスがソースオブジェクトを受信し、復号し、復元することができるように、FECセマンティクスを伴わずに(かつ/またはFECをシグナリングすることなく)ソースコンテンツを配信するように構成されるサーバを含み得る。ある実施形態では、サーバは、コンテンツ情報を第1のオブジェクトで、FECシグナリング情報を第2のオブジェクトで配信するように構成され得る。ある実施形態では、第1のオブジェクトおよび第2のオブジェクトは一緒に帯域内で配信され得る。
様々な実施形態は、前方誤り訂正(FEC)オブジェクトのバンドリング動作を実行するように構成されるコンポーネントを含み得る。様々な実施形態は、複数のオブジェクトにわたるFEC保護を提供するように構成されるコンポーネントを含み得る。ある実施形態では、これは、FECオブジェクトのバンドリング動作と、FECセマンティクスの配信をソースコンテンツから分離する動作との組合せを介して、遂行され得る(または可能にされ得る)。
様々な実施形態は、前方誤り訂正(FEC)動作を実行して個々のソースオブジェクトまたはDASHセグメントの部分を保護し、複数のFEC符号化を伴ってソースオブジェクトが配信されることを可能にし、より大きな柔軟性をもたらし、オブジェクト全体が受信される前にオブジェクトがレンダリングされることまたは「演じられること」を可能にするように構成されるコンポーネントを含み得る。そのような実施形態では、FEC保護は、部分的なオブジェクトにわたって、独立したソースオブジェクトのバイト範囲にわたって、かつ/または、異なるストリーム中の異なるソースオブジェクトからのバイト範囲の組合せにわたって、提供され得る。たとえば、コンポーネントは、ソースオブジェクトの最初の3個のフレームにわたって独立したFEC保護を提供し、ソースオブジェクトの次の5個のフレームにわたって独立したFEC保護を提供し、ソースオブジェクトの次の6個のフレームにわたって別の独立したFEC保護を提供し、ソースオブジェクトの最後の10個のフレームにわたってさらに別の独立したFEC保護を提供するように構成され得る。この方式のFEC保護は、システムが可変サイズのソースパケットまたはオブジェクトの送信をより良好にサポートするのを可能にし、オブジェクト全体が受信される前に受信機デバイスがオブジェクトの復号を漸次的に開始することを可能にし、より大きなオブジェクトの送信を可能にし、オブジェクト/ストリームに含まれる独立したリフレッシュフレームの数または頻度を減らし、ストリーミングコンテンツ(特に大きなオブジェクトからなるコンテンツ)と関連付けられるレイテンシを改善し、ストリームによって消費される帯域幅の量を減らし、システムがFEC保護を提供することが可能である粒度に対するより大きな柔軟性と制御を提供することができる。
様々な実施形態は、オブジェクトの部分が異なるラベルと関連付けられ得るように、ソースオブジェクトのためのシグナリング情報およびオブジェクト情報をパッケージングして通信するように構成されるコンポーネントを含み得る。たとえば、オブジェクトの最初の部分は「タイプA」と標識されることがあり、「タイプB」と標識される部分がそれに続き、「タイプA」と標識される別の部分がそれに続く。これは、ビデオ層コンポーネント(たとえば、ビデオ層デコーダなど)が、同じタイプである、関連のある、独立に再生可能である、などの、オブジェクトの様々な断片または部分を、識別し、類別し、または分類することを可能にし得る。オブジェクト標識はまた、ビデオ層コンポーネントに有用であり得る情報の他の適用を可能にし得る。ある実施形態では、ソースオブジェクトの様々な断片/部分のための標識情報は、様々な特質を定義し、含み、または規定するコードポイントを介して、受信機デバイスに通信またはシグナリングされ得る。
様々な実施形態は、バイト範囲を使用して、FEC保護されるソースオブジェクトの部分をシグナリングまたは特定するように構成されるコンポーネントを含み得る。これらのコンポーネントはまた、FEC保護される部分のバイト範囲をタイプ識別子またはデータフィールドとともに含むパケットを標識するように構成され得る。ソースオブジェクトの部分のタイプ識別情報(これは通常、ソースオブジェクトが受信機において復元されると、ソースオブジェクトを消費するより高いレベルのアプリケーションに対しては価値がある)が、異なるタイプのソースオブジェクトの部分のFEC保護を提供することを可能にするために、様々なバイト範囲にわたってFEC保護を提供するためにシステムとともに使用され得る。これは、ソースオブジェクト内のデータのタイプに対応するソースオブジェクトの各部分が、FECを使用して独立に復元されることを可能にし、このことは、あるタイプに対応するソースオブジェクトの異なる部分が消費するアプリケーションに対して有用であるときは、ソースオブジェクトの他の部分が受信機にまだ到達していないことによりまだ利用不可能であるときであっても、または、不十分なFEC保護により決して利用可能にならないときであっても、そのアプリケーションに対して価値があり得る。しかしながら、ソースオブジェクトの部分のFEC保護、およびソースオブジェクトの異なる部分を異なるタイプであるとして識別することは、互いに独立に使用され得る。たとえば、FEC保護は、異なるタイプのソースオブジェクトの2つの連続する部分にわたって提供されてよく、または、FEC保護は、異なるタイプの異なる部分と揃えられないソースオブジェクトの部分にわたって提供されてよく、または、FEC保護は、タイプに分類されないソースオブジェクトの異なる部分にわたって提供されてよい。
様々な実施形態において、ソースオブジェクトの配信および保護は、完全なソースファイルのサブセットに基づき得る。たとえば、ある実施形態では、コンポーネントは、別個の配信オブジェクト(またはソースオブジェクト)としてあるバイト範囲を扱うように構成され得る。このバイト範囲と関連付けられるシグナリング情報は、ダイナミックメタデータ(DMD)のようなメタデータを介して、通信され、送信され、またはシグナリングされ得る。たとえば、ダイナミックメタデータ中のオブジェクトは、システムが、オブジェクトを、メタデータのContent-Locationフィールドで定義されるURLのContent-Rangeと関連付けることを可能にする、Content-Rangeヘッダを割り当てられ得る。この場合、FLUTEに対する拡張として、送信オブジェクト識別子(TOI)とURLとの間の1対1のマッピングはないことがあるが、TOはURLとバイト範囲の組合せにマッピングされ得る。ある実施形態では、ソースオブジェクトは、複数の保護オブジェクトまたはFEC保護される部分に分割され得る。
様々な実施形態は、ソースオブジェクトの保護される部分に対する送信オブジェクト識別子(TOI)/オブジェクトシーケンス番号(OSN)の値を修復パケットヘッダに(たとえば、ヘッダ拡張部に)、かつ、ソースブロックの保護される部分のバイト範囲をトランスポートソースブロックの最後に追加するように構成されるコンポーネントを含み得る。他の実施形態は、(ソースオブジェクトの最初ではなく)保護されるべきソースオブジェクトの部分の最初にソースシンボルを追加または開始し、ファイル、配信、またはソースオブジェクトの保護される部分の実際のバイト範囲を修復パケットヘッダの中で直接提供するように構成されるコンポーネントを含み得る。さらなる実施形態では、コンポーネントは、バイト範囲の開始位置とバイト範囲によって包含されるシンボルの数とを修復パケットヘッダの中に直接追加し、保護されるソースオブジェクトの部分のバイト単位(またはオクテット単位)のサイズをトランスポートソースブロックの最後(たとえば、FEC符号化オブジェクト)に追加するように構成され得る。この好ましい実施形態は、上で論じられた実施形態よりも少数の修復パケットヘッダのバイトしか必要とせず、修復シンボルを無駄にせず、トランスポートソースブロックの最初のシンボルにパディングバイトを有さない。
様々な実施形態は、ソースオブジェクトのTOI(またはOSN)、ソースオブジェクト内での開始バイト位置、およびソースオブジェクト内での終了バイト位置を含む、ソースオブジェクトの各々の保護される部分に対する修復パケットヘッダを有する修復パケットを生成するように構成されるコンポーネントを含み得る。ある実施形態では、修復パケットヘッダは、ソースオブジェクトの各々の保護される部分に対して10バイト(たとえば、TOIに対して2バイト、開始バイト位置に対して4バイト、および終了バイト位置に対して4バイト)であってよい。ある実施形態では、これらおよび他のマッピングは、別個のファイルまたはオブジェクトにおいて受信機デバイスに配信されるメタデータファイルに含まれ得る。好ましい実施形態では、コンポーネントは、開始バイト位置およびシンボル単位のオブジェクトのサイズをシグナリングするように構成され得る。ある実施形態では、TOIはメタデータを介してマッピングされ得る。ある実施形態では、バイト単位の保護されるオブジェクトのサイズは、受信機によって知られている、またはシグナリングされる位置にある、ソースブロック(たとえば、FEC符号化オブジェクト)に含まれ得る。ある実施形態では、コンポーネントは、ソースオブジェクトの開始バイト位置から始めて、ソースオブジェクトのある部分にFEC保護を適用するように構成され得る。様々な実施形態は、シンボル単位のサイズ、配信/ソースオブジェクトの開始アドレス(たとえば、16ビット、32ビット)、およびシンボル単位のサイズなどのような、様々なタイプのサイズをシステムがシグナリングすることを可能にする、複数の拡張ヘッダを定義することができる。
様々な実施形態は、Layered Coding Transport (LCT)コードポイントフィールドを使用して、そのパケット(すなわち、元のソースオブジェクトを含むパケット)で搬送されるコンテンツの「タイプ」を特定するように構成されるコンポーネントを含み得る。ある実施形態では、この情報はコードポイントに含まれ得る。ある実施形態では、コンポーネントは、FEC保護されトランスポートソースオブジェクトの部分の「タイプ」である、トランスポートソースオブジェクトの複数のバイト範囲の間の関係を特定するように構成され得る。たとえば、トランスポートソースオブジェクトのバイト範囲は、いくつかのタイプ(たとえば、総称的にタイプX、タイプY、タイプZ)の1つによって標識されてよく、各ソースパケットは1つのタイプのデータのみを含むように生成されてよい。さらなる例として、タイプXのバイト範囲12000から19999は、7個のソースパケット(各々がコードポイントフィールドにおいてタイプXとして標識される)に含まれてよく、最初の6個のソースパケットは1200バイトを含んでよく、7番目のソースパケットは800バイトを含んでよい。すべてのそのような情報が、関連付けられるパケットのコードポイントフィールドに含まれ得る。コードポイントフィールド(またはコードポイント)は、それが特定のタイプの始まりである場合、特定の値を割り当てられ得る。さらに、FEC保護は、同じタイプのソースオブジェクト内で連続しているソースオブジェクトの部分にわたって提供され得る。たとえば、コードポイントで示されるようなソースオブジェクト内のタイプXのデータに対応するソースオブジェクトのバイト範囲12000から19999を保護する、FEC修復オブジェクトがあり得る。
様々な実施形態は、既存のFEC方式のソースFECペイロードIDを(すなわち、ソースプロトコルで提案されるようなバイト範囲の代わりに)使用するように構成されるコンポーネントを含み得る。この実施形態は、たとえば、ソース配信レベルで、既存のFEC方式との後方互換性をサポートすることを可能にし得る。この実施形態はまた、オブジェクトのバンドリングをサポートし得る。ソースFECペイロードIDは、FECフレームワークを適用する前にバイト範囲に変換され得る。この実施形態は、進化したFECフレームワークをソースプロトコルにおける任意のFEC方式とともに適用することを可能にし得る。
ある実施形態では、ソースオブジェクトは、完全な既存のファイルではなく、既存のファイルのバイト範囲(たとえば、ISO/IEC 23009-1、Annex Eでたとえば定義されるようにバイト範囲を特定するURLを伴う)であってよく、またはそれを含んでよい。
一般に、ウェブキャッシュは、帯域幅の使用、サーバの負荷、およびネットワークのレイテンシを減らすための、ウェブドキュメント(たとえば、HTMLページ、画像など)の一時記憶のための機構である。通常、ウェブキャッシュは、後続のウェブベースの要求がウェブキャッシュから直接満たされ得るように、ウェブキャッシュを通過するドキュメントのコピーを記憶する。HTTPキャッシュは、HTTP規格において規定される基本的なフレッシュネスの要件、妥当性確認の要件、および無効化の要件を実装する、ウェブキャッシュである。
様々な実施形態は、ソースオブジェクトが完全なHTTP応答を含むことを可能にするためにオブジェクト配信動作を実行するように構成されるコンポーネントを含み得る。このことは、別のコンピューティングデバイスがHTTP要求を出した場合、または、同じデバイスで動作するアプリケーションがHTTP要求を出した場合に、HTTP要求の全体がHTTPを通じて配信されたかのように受信機デバイスがHTTP要求を完全なHTTP応答とともに提供できるように、受信機デバイスがHTTPキャッシュとして動作することを可能にし得る。
様々な実施形態は、現在のFLUTE規格の要件に準拠しながら、かつ/または、現在のFLUTE規格を実装する他のコンポーネントとの後方互換性を維持しながら、上述の動作のいずれかまたはすべてを実行するように構成されるコンポーネントを含み得る。
様々な実施形態は、その例が図1に示されている、種々の通信システム、ネットワーク、および/またはモバイルマルチメディアブロードキャストシステム内で実装され得る。具体的には、図1は通信システムを示し、この通信システムでは、モバイル受信機デバイス102が、マルチメディアブロードキャストネットワーク104から、ユニキャストネットワーク106から、またはインターネット108を介して受信することができる。典型的なマルチメディアブロードキャストネットワーク104は、モバイルブロードキャストネットワークコントロールセンター/ブロードキャストオペレーションセンター(BOC)114によって制御される複数のブロードキャスト送信機112を含む。マルチメディアブロードキャストネットワーク104は、モバイル受信機デバイス102による受信のために、ブロードキャスト送信機112からのコンテンツをモバイルブロードキャスト送信113としてブロードキャストする。BOC 114内には、コンテンツのブロードキャストを管理するための、インターネット108への接続を提供する1つまたは複数のサーバ110があり得る。
マルチメディアブロードキャストネットワーク104に加えて、モバイル受信機デバイス102は、携帯電話ネットワーク、WiFiネットワーク(図示されず)、WiMAXなどのようなユニキャストネットワーク106を介して通信することができる。通常の携帯電話ネットワークは、ネットワークオペレーションセンター118に結合された複数のセルラー基地局116を含む。ネットワークオペレーションセンター118は、電話陸上通信線(たとえば、図示されていないPOTSネットワーク)およびインターネット108を介するなどして、モバイル受信機デバイス102と他のネットワーク宛先との間の音声呼およびデータ呼を接続するように動作する。
モバイル受信機デバイス102とユニキャストネットワーク106との間の通信は、LTE、4G、3G、CDMA、TDMA、および他の携帯電話通信技術のような双方向ワイヤレス通信リンク115を介して遂行され得る。そのような双方向ワイヤレス通信リンク115は、ユーザがマルチメディアコンテンツを受信機デバイス(たとえば、モバイルデバイス)へストリーミングすることを可能にし得る。
インターネットデータ通信(たとえば、ビデオフィードのストリーミング)を容易にするために、ユニキャストネットワーク106は通常、インターネット108への接続を提供するネットワークオペレーションセンター118に結合される、またはその内部にある、1つまたは複数のサーバ120を含む。モバイル受信機デバイス102は、有線接続が利用可能なときにはそれを介してインターネット108に接続することができ、その場合、インターネット108はユニキャストネットワークとして働き得る。モバイル受信機デバイス102はまた、よく知られている従来のウェブベースのアクセスプロトコルを使用して、インターネット108を通じて非ブロードキャストコンテンツを受信することができる。
一般に、受信機デバイス(たとえば、上で論じられたモバイル受信機デバイス102)によってコンテンツを受信しレンダリングするための動作は、別々の独立した動作のグループまたはカテゴリーに分けられてよく、動作の各グループまたはカテゴリーは、層(たとえば、物理層、データリンク層など)を割り当てられ得る。これらの層の各々では、様々なハードウェアコンポーネントおよび/またはソフトウェアコンポーネントが、その層に割り当てられる役割にふさわしい機能を実装することができる。たとえば、メディアストリーム(たとえば、ブロードキャスト、ポイントツーポイントなど)は通常物理層で受信され、物理層は、無線受信機と、バッファと、復調、高周波(RF)信号内のシンボルの認識、および受信されたRF信号から生のデータを抽出するための他の動作の実行という動作を実行する処理コンポーネントとを含み得る。
図2は、ある実施形態による、コンテンツを受信し表示するのに適したモバイル受信機デバイスの例示的なプロトコルスタック200を示す。図2の示される例では、プロトコルスタック200は、物理層202モジュール、データリンク層204モジュール、ネットワーク層206モジュール、トランスポート層208モジュール、およびアプリケーション層210モジュールを含み、これらの各々が、ハードウェア、ソフトウェア、またはハードウェアとソフトウェアの組合せで実装され得る。さらに、モジュール202〜210の各々はサブレイヤを含んでよく、これらもまた、ハードウェア、ソフトウェア、またはハードウェアとソフトウェアの組合せで実装され得る。
物理層202モジュールは、基本的な通信信号を受信し、通信信号からデータを抽出し、データをメディアトランスポートストリーム(たとえば、MPEG-2 Transport Stream)またはデータリンク層204モジュール中のメディアアクセス制御モジュールに提供するように構成される、無線コンポーネントを含み得る。データリンク層204モジュールは、モバイル受信機デバイスの様々なコンポーネントがデータの異なるストリームを受信することを可能にする、アドレス指定およびチャンネルアクセス制御機構を提供することができる。データリンク層204モジュールはまた、例示されるマルチプロトコルカプセル化前方誤り訂正(MPE-FEC)モジュール/レイヤならびにプログラムおよびシステム情報(SI/PSI)モジュール/レイヤのような、Moving Picture Experts Group (MPEG)トランスポートストリーム(TS)の頂部に、パケットプロトコル(たとえば、インターネットプロトコル)を搬送するための様々なサブモジュールまたはサブレイヤを含み得る。
コンテンツおよび情報の流れを搬送するためのストリーム/信号の部分は、データリンク層204モジュールによってネットワーク層206モジュールに渡されてよく、ネットワーク層206モジュールは、ストリーム、データグラムおよび/またはパケットをトランスポート層208モジュールに通信/中継するための、IPモジュール/インターフェースを含み得る。トランスポート層208モジュールで受信されるストリームおよびデータは、トランスポートのためにデータを処理しパッケージングする、適切なトランスポート層サブモジュールまたはサブレイヤに配信され得る。そのようなトランスポート層サブモジュール/サブレイヤは、ユーザデータグラムプロトコル(UDP)モジュール/レイヤ、asynchronous layered coding/layered coding transport (ALC/LCT)モジュール/レイヤ、リアルタイムトランスポートプロトコル(RTP)モジュール/レイヤ、およびfile delivery over unidirectional transport (FLUTE)モジュール/レイヤを含み得る。ある実施形態では、RTPモジュール/レイヤは、DASHフォーマットと同様に、アプリケーション層210に含まれてよく、またはその一部であってよい。
アプリケーション層210モジュールは、ホストツーホスト、エンドツーエンドの接続を確立してプロセス対プロセスの通信を行うために必要とされる、プロトコルおよび方法を含み得る。アプリケーション層210モジュールはまた、モバイル受信機デバイス上での受信されたコンテンツの処理、レンダリング、および/または表示のための、エンドユーザのアプリケーション(たとえば、メディアプレーヤーなど)を含み得る。アプリケーション層はまた、DASHフォーマット、符号化されたメディアストリーム、および他のメディア関連のメタデータのような、メディアフォーマットを含み得る。図2に示される例では、アプリケーション層210モジュールは、DASHモジュール、RTPモジュール、およびメディアプレーヤーモジュールを含む。
図3Aは、マルチメディアコンテンツをモバイル受信機デバイスに配信するのに適した、ある実施形態のブロードキャスト通信システム300の様々な論理的および機能的コンポーネントを示す。図3Aに示される例では、ブロードキャスト通信システム300は、進化したオブジェクト前方誤り訂正コンポーネント302、進化したオブジェクトシグナリングコンポーネント304、および進化したオブジェクト配信コンポーネント306を含む。マルチメディアコンテンツは、3つの異なるオブジェクトフロー(オブジェクトフロー1、2、および3)を介してブロードキャストされる、可変サイズのオブジェクト(Obj)において符号化される。各オブジェクトフロー(オブジェクトフロー1、2、および3)は、進化したオブジェクト配信コンポーネント306を含み、またはそれと関連付けられる。可変サイズのオブジェクト(Obj)の各々は、完全なオブジェクトまたはオブジェクトの部分(たとえば、バイト範囲など)であってよい。
様々な実施形態において、進化したオブジェクト前方誤り訂正コンポーネント302、進化したオブジェクトシグナリングコンポーネント304、および進化したオブジェクト配信コンポーネント306のいずれかまたはすべてが、ハードウェア、ソフトウェア、またはハードウェアとソフトウェアの組合せで実装され得る。
進化したオブジェクト配信コンポーネント306は、配信レベルでオブジェクト(Obj)間のフロー関連付けを確立または特定すること、パケットレベルでオブジェクトまたはデータにタイムスタンプを追加すること、チャンク配信動作を実行すること、オブジェクト(Obj)をソースパケットへとパケット化または断片化すること、および様々な他の同様の動作を実行することを含む、様々なオブジェクト配信動作を実行するように構成され得る。
進化したオブジェクトシグナリングコンポーネント304は、オブジェクトフロー(オブジェクトフロー1、2、および3)においてシグナリング情報をパッケージングして送信すること、HTTPサーバ/プロキシ/キャッシュの複製を遂行すること、および、HTTPオブジェクトのための「利用可能タイミング」情報を配信することのような、様々なシグナリング動作を実行するように構成され得る。たとえば、進化したオブジェクトシグナリングコンポーネント304は、対応するオブジェクトが配信されるときに、HTTPオブジェクトの利用可能タイミング情報をシグナリングするように構成され得る。このことは、ブロードキャスト通信システム300が、ブロードキャストを通じてオブジェクトを配信するときにタイムアウト動作を実行することを可能にする。そのような利用可能タイミング情報の配信はまた、ブロードキャスト通信システム300が、キャッシュに記憶されたアイテムが限られた時間長の間だけコンピューティングシステムに対して利用可能にされる、かつ/または、ある時間長もしくは期間の後に期限切れになる、キャッシュタイムアウトポリシーと同様の機能を実装することを可能にし得る。このようにして、ブロードキャスト通信システム300は、データ、オブジェクト(Obj)、および/またはソースパケットが常に最新であること、または最新の情報を含むことを確実にし得る。
進化したオブジェクトシグナリングコンポーネント304はまた、受信機デバイスにシグナリング情報を提供するように構成されてよく、シグナリング情報は、1つまたは複数のオブジェクト(Obj)が受信機デバイスにいつどのように配信されるかを特定する様々な情報フィールドを含み得る。様々な実施形態では、そのような情報は、対応するオブジェクトまたはパケットが受信機デバイスによって受信される前に、またはサーバによって送信される前に、ブロードキャストセッションを通じて受信機デバイスに配信され得る。
進化したオブジェクト前方誤り訂正コンポーネント302は、オブジェクトのソースフローのためのFEC保護を提供すること、オブジェクトのバンドルのためのFEC保護を提供すること、個々のオブジェクトの部分のためのFEC保護を提供すること、および、FECのセマンティクス、コード、論理、サポート、または動作とは無関係にソースオブジェクトの配信を可能にすることのための動作を含む、様々な前方誤り訂正動作を実行するように構成され得る。ある実施形態では、進化したオブジェクト前方誤り訂正コンポーネント302は、ソースオブジェクトのバンドルのためのFEC保護を提供しながら、同時に、FECセマンティクスとは独立にバンドルの個々のソースオブジェクトを配信するように構成され得る。
ある実施形態では、進化したオブジェクト前方誤り訂正コンポーネント302は、トランスポートソースオブジェクトのバイト範囲(およびバイト範囲の組合せ)のためのFEC保護を提供して、同じまたは異なるフローもしくはストリームの中のオブジェクトの部分を保護するように構成され得る。このことは、受信機デバイスが、FEC復号動作を実行して、オブジェクトが受信されるにつれてオブジェクトを漸次的にレンダリングすることを可能にする。これは、FEC符号化がオブジェクト全体にわたって実行され、そのオブジェクトをレンダリングするためのFEC復号動作を実行するのをオブジェクト全体が受信されるまで受信機デバイスが待つことを一般に必要とする、既存の解決法とは対照的である。
ある実施形態では、進化したオブジェクト前方誤り訂正コンポーネント302は、ソースオブジェクトのフローのためのFEC保護を提供するように構成され得る。進化したオブジェクト前方誤り訂正コンポーネント302は、FLUTEベースの配信システムを含む任意のオブジェクトベースの配信システムにおいて、ソースオブジェクトのフローにわたるFEC保護を提供することができる。加えて、進化したオブジェクト前方誤り訂正コンポーネント302、進化したオブジェクトシグナリングコンポーネント304、および/または進化したオブジェクト配信コンポーネント306は、既存のFLUTEの規格および解決法を実装することができ、またはそのサブセットであってよい。さらに、これらのコンポーネント302、304、306のいずれかまたはすべては、オブジェクトのストリームまたはフローが、FLUTEの状況においてより効率的に、かつ既存のFLUTE規格に適合して配信されることを可能にするように、FLUTEの機能(たとえば、図2を参照して上で論じられたFLUTEサブレイヤによって提供される機能など)を拡張することができる。
現在のFLUTEの解決法によって提供される(セグメントのDASHシーケンスの配信のために3GPP MBMSにおいて規定される)もののような、既存のブロードキャストオブジェクトベースのストリーミング配信の解決法は、パケットベースのストリーミングの解決法によって提供される特徴と機能の多くを欠いている。したがって、多くの既存のストリーミングの解決法は、オブジェクトベースではなく、代わりに、RTP/IP、MPEG 2トランスポートストリーム(TS)、または他の同様の技術を介してパケットストリームを配信する、パケットベースの解決法である。FECがそのようなパケットベースのストリーミングの解決法において使用されるとき、パケットは通常ソースブロックに区分され、FEC修復保護がこれらのソースブロックの各々に対して個々に提供される。この理由および他の理由で、既存のパケットベースのストリーミングの解決法は、ストリームの部分を名付けて識別する能力(たとえば、ユニフォームリソース識別子(URI)によって)を欠いており、一般に、DASHのようなオブジェクトベースのストリーミングの解決法によって提供される有利な特徴の多くを欠いている。
ある実施形態では、ブロードキャスト通信システム300は、既存のパケットベースのストリーミングシステムによって提供される機能と既存のブロードキャストオブジェクトベースのストリーミングシステムによって提供される機能の組合せである機能を提供するように構成され得る。すなわち、既存のストリーミングの解決法とは対照的に、ブロードキャスト通信システム300は、既存のパケットベースのストリーミングの解決法とブロードキャストオブジェクトベースのストリーミングの解決法の特徴を組み合わせる(かつ、追加のさらなる特徴を提供する)機能を実現することができ、一方で、既存のFLUTEベースの解決法およびシステムに適合したままであり、かつブロードキャストを介してそのような通信を遂行する。
一般に、パケットベースのストリーミングシステムは、個々のパケットが搬送し、パッケージングし、または符号化するソースコンテンツの特性と一致するように、個々のパケットを生成することができる。たとえば、ソースコンテンツがビデオストリームであるとき、パケットベースのストリーミングシステムは、ビデオデータの1つのフレームまたはスライスまたはネットワーク抽象化層ユニットを含むように、各ソースパケットを生成することができる。このことは、パケットベースのストリーミングシステムが、各ビデオフレームまたは各スライスまたはアクセスユニットまたはネットワーク抽象化層ユニットがシステムに対して利用可能になると、それを送信することを可能にし、このことは、いくつかの環境またはネットワークではネットワークのレイテンシを減らし得る。加えて、パケットベースのストリーミングシステムは通常、各サンプルに対して非常に正確なタイミングを達成し、これもいくつかの環境またはネットワークでは有益である。
既存のブロードキャストオブジェクトベースのストリーミングシステムは、大きなサンプルまたはオブジェクトを配信するには、パケットベースのストリーミングシステムよりも適しているが、セグメントまたはオブジェクトに含まれるべき情報のすべてが、セグメント/オブジェクトが送信される前にIPネットワークを通じた通信のために利用可能にされることを必要とする。すなわち、既存のブロードキャストオブジェクトベースのストリーミングシステムは、サーバが、ソースオブジェクトのコンテンツを、それがそのサーバに対して利用可能になるにつれて送信するのを開始することを可能にしない。むしろ、既存のブロードキャストオブジェクトベースのストリーミングシステムは、サーバが、DASHセグメントまたは一般にはソースオブジェクトのための情報のすべてが受信されるまで、またはサーバに対して利用可能になるまで、そのDASHセグメント(またはソースオブジェクト)のためのパケットの受信機デバイスへの送信を開始できるようになるのを待つことを必要とする。加えて、既存のブロードキャストオブジェクトベースのストリーミングシステムは、個々のサンプル/セグメント/オブジェクトに対する厳密なタイミング要件を満たすにはよく適していないので、いくつかの環境またはネットワークでは、ネットワークのレイテンシおよびジッタの影響を受けやすい。
様々な実施形態は、情報がブロードキャスト通信サーバに対して入手可能になるにつれてサンプルまたはオブジェクトを効率的にブロードキャストし、既存のFLUTEベースの解決法およびシステムに適合しながら各サンプル/オブジェクトに対する非常に正確なタイミングを達成し、これによって、既存のパケットベースのストリーミングシステムによって提供される機能と既存のブロードキャストオブジェクトベースのストリーミングシステムによって提供される機能のハイブリッド/組合せを達成するように構成されるブロードキャスト通信サーバを含み得る。たとえば、ブロードキャスト通信サーバは、データを、そのようなデータがサーバに対して利用可能になるにつれてファイルに含め、データがサーバに対して利用可能になるにつれて(すなわち、ファイルに含まれるべきすべてのデータをサーバが受信する前に)データがネットワークに対して利用可能にされるように、ファイルを直ちにブロードキャストすることを開始するように構成され得る。加えて、ブロードキャスト通信サーバは、FLUTEレベルでタイミング情報を各ファイル/パケットに追加することができる。そのようなタイミング情報は、ネットワーク中のジッタを測定し、他の同様の動作を実行するために使用され得る。ジッタの測定およびジッタの補償が、バッファの寸法を決定し、低レイテンシの動作を確実にするために使用され得る。
既存のFLUTEシステムは、ファイル配信テーブル(FDT)を使用してシグナリング情報を通信する。FDTは、前方誤り訂正オブジェクト送信情報(FEC OTI)、ユニフォームリソース識別子(URI)、パケットに含まれるオブジェクト情報を特定する送信オブジェクト識別子(TOI)、およびオブジェクトのための送信セッション/ストリーム識別子(TSI)を含み得る。
前方誤り訂正オブジェクト送信情報(FEC OTI)は、特定のFECコーディング方法を識別する「FEC符号化ID」を含み得る。加えて、FEC OTIは、バイト範囲またはオブジェクト/ファイルサイズ(F)、バイトオフセットを特定する整列係数(Al)、シンボルサイズ(T)、オブジェクト中のソースブロックの数(Z)、およびそのオブジェクトのために各ソースブロックが区分されるサブブロックの数(N)のような、様々なパラメータを含み得る。
様々な実施形態では、各オブジェクトは、異なる前方誤り訂正オブジェクト送信情報(FEC OTI)および/または異なるuniform resource identifiers (URI)を含み得る。ファイル配信テーブル(FDT)は、送信オブジェクト識別子(TOI)を、URI、FEC OTI、および他のオブジェクト送信パラメータのような、FDTに含まれる他の情報とリンクすることができる。送信セッション/ストリーム識別子(TSI)はTOIをスコープする(すなわち、TOIを識別しTOIのコンテキストを提供する)ことができ、これは、複数のオブジェクトが同じセッションで、かつ異なるTOIを伴って配信されることを可能にする。TSIとTOIの組合せは一意にオブジェクトを識別することができる。オブジェクトシーケンス番号(OSN)はTOIにマッピングされてよく、逆も同様である。TSIはFLIDにマッピングされてよい。
ファイル配信テーブル(FDT)は、静的な情報と動的な情報の両方を含み得る。たとえば、送信オブジェクト識別子(TOI)、URI、コンテンツのタイプ、およびバイト範囲またはオブジェクト/ファイルサイズ(F)の値は、オブジェクトごとに変動する動的な情報を含み得る。FEC符号化ID、送信セッション/ストリーム識別子(TSI)、整列係数(Al)、シンボルサイズ(T)、ソースブロックの数(Z)、およびサブブロックの数(N)の値はすべて、複数のオブジェクトにわたって、またはオブジェクトのシーケンスにわたって一定である、静的な情報を含み得る。そのような値は、たとえば、値Z=1、N=1、およびすべてのオブジェクトに対して一定のAlとFEC符号化IDの値を使用することによって、関連するオブジェクト(またはオブジェクトの集合体)のシーケンス全体に対して1回提供され得る。しかしながら、既存の解決法を使用すると、シグナリング情報は、ストリーム中の複数のオブジェクトにわたって共有される静的なフィールドの数とは関係なく、ブロードキャストされるべき各オブジェクトに対して(FDTをブロードキャストすることを介して)送信されなければならない。
オブジェクトのストリームを配信するとき、TOIおよびURIの値は、関連するオブジェクトのストリームにわたって予測され得るが、オブジェクト/ファイルサイズ(F)は通常は予測可能ではない。URI情報は、TOIとテンプレートとを使用してURIを生成することによって、テンプレーティングを介して伝えられ得る。
上で論じられた値フィールドに加えて、既存のFLUTEベースの解決法では、各パケットはFECペイロードIDを含む。FECペイロードIDは、パケットペイロードについての情報を提供し、ソースブロック番号(SBN)および符号化シンボル識別子(ESI)を含み得る。FECペイロードIDは、パケットがソースデータを含むか修復データを含むかに関係なく、特定のFEC方法またはシステムに特有の情報を含み得る。この理由で、FEC符号化IDは、FLUTEを介してオブジェクトのためのソースデータを配信するときに、既存のシステムによって必要とされる。
様々な実施形態は、FEC符号化IDデータフィールドまたは値のようなFECセマンティクスを含むことなく、FLUTEを介してオブジェクトのためのソースデータを配信するように構成されるブロードキャストサーバを含み得る。様々な実施形態はまた、FECセマンティクスを含まないオブジェクトを受信し、復号し、使用するように構成される受信機デバイスを含み得る。
既存のFLUTEの解決法は、単一のオブジェクトフローまたは通信チャンネルに含まれる複数のオブジェクト間の関係を確立することをサポートしない。既存の解決法を使用すると、オブジェクトのためのFDTに含まれ得る静的な情報と動的な情報のすべてが、各オブジェクトに対して個々に受信機デバイスに配信されなければならない。加えて、オブジェクトのためにFDT内で配信される情報の一部は通常、オブジェクト自体が配信されるときにだけ利用可能であるので、少なくとも1つのFDTは一般に、ストリーム中の各オブジェクトに対して配信されなければならない。この情報は、情報に対する実際の変化または潜在的な変化があるかどうかに関係なく、また、複数のオブジェクトに対して、もしくはストリーム中のすべてのオブジェクトにわたって同じ情報が使用され得るかどうかに関係なく、各オブジェクトに対してFDT内で配信されなければならない。加えて、FECセマンティックでありオブジェクトとともに配信される各パケットのコンテンツについての情報を提供するFECペイロードIDは、通常はFEC固有であり、すべての例で必要とはされない。既存のシステムで行われているように、同じ情報、受信機デバイスによって必要とされない、もしくは使用されない情報、または複数のオブジェクトにわたって共有され得る情報を繰り返しブロードキャストすることは、ネットワークリソースの非効率的な使用である。
様々な実施形態は、シグナリング情報(たとえば、FDTパラメータ)がフロー中の複数のオブジェクトにわたって共有され得るように、単一のフロー、ストリーム、または通信チャンネルで関連するオブジェクトをブロードキャストするように構成される、ブロードキャスト通信サーバを含み得る。このことは、ネットワークを通じて通信される情報の量を減らし、ネットワークリソース(たとえば、帯域幅など)のより効率的な使用であり、情報を受信機デバイスに配信するための既存の解決法よりも信頼性がある。
様々な実施形態はまた、関連するオブジェクトのシーケンスをブロードキャストするように構成されるブロードキャスト通信サーバを含み得る。ある実施形態では、オブジェクト間の関係はTOIフィールドを介して特定されてよく、これは、関連するオブジェクトのフローを特定するフローID(FLID)サブフィールドと、関連するソースオブジェクトのフロー内の各ソースオブジェクトを特定するオブジェクトシーケンス番号(OSN)サブフィールドという、2つのサブフィールドへとTOIフィールドを分割することによって達成され得る。ある実施形態では、OSNはTOIフィールドにマッピングされ得る。FLUTE規格はTOIフィールドのための厳密な構造を定義しないので、TOIはこの方式で分割されることが可能であり、したがって、TOIフィールドに含まれる各数字は、異なるオブジェクトまたはフィールドのために使用され得る。さらに、既存のTOIフィールドは通常4バイトの情報を記憶するので、TOIフィールドは、既存のシステムとの後方互換性に影響を与えることなく、1バイトのFLIDパラメータサブフィールドと、3バイトのOSNパラメータサブフィールドへと分割され得る。
ある実施形態では、FLIDは1バイトのパラメータであってよく、これはシステムが各セッションに対して256個の異なるFLIDをサポートすることを可能にする。ある実施形態では、一部のシステムではFDTオブジェクト配信のために確保されていることがある、0というTOI値による混乱を避けるために、0という値は、FLIDサブフィールドに対して許容される値またはサポートされる値としては除外され得る。
ある実施形態では、TOIは4バイトの値であってよく、ある値の範囲(たとえば、128〜255など)が、既存のFLUTEの解決法を使用した、かつ同じセッション内でのオブジェクトの配信を可能にするために、TOIのFLIDサブフィールドでの使用のために確保され得る。たとえば、TOIをサブフィールドへと分割せずFDTを使用する解決法は、使用されるTOIの値を0から128*256*256*256-1=2147483647に制限することができる(第1の使用事例)。一方、4バイトのTOIを1バイトのFLIDおよび3バイトのOSNへと分割する解決法は、使用されるFLIDの値を、3バイトのOSN値の範囲に対するさらなる制約を伴わずに、範囲128から255に制限することができる(第2の仕様事例)。連結されると、1バイトのFLIDと3バイトのOSNは、128*256*256*256から256*256*256*256-1にわたる4バイトのTOI整数値を形成する(または等価的にTOI整数値は2147483648から4294967295にわたる)。このことは、上で論じられた2つの使用事例で使用される4バイトのTOI値の範囲全体が連続していないことを確実にする。このことは、FLUTEブロードキャスト配信システムが、TOIを分割せずFDTを使用するオブジェクト(上で説明された第1の使用事例、既存のFLUTEの解決法)およびTOIを分割しFDTを使用しないオブジェクト(上で説明された第2の使用事例)を同じセッションで配信することを可能にする。説明されたように、これは、全体のTOI値の範囲を2つの異なる使用事例に対して重複しない範囲へと区分することによって達成されることが可能であり、このことは、同じセッションにおける2つの使用事例に対するTOIの競合の可能性をなくす。
ある実施形態では、送信セッション/ストリーム識別子(TSI)がフローID(FLID)として使用され得る。
様々な実施形態のFLIDサブフィールドによって特定されるもののような、関連するオブジェクトのフローは、DASH表現におけるビデオセグメントのストリームに対応し得る。たとえば、そのような表現において配信される各オブジェクトは同じFLIDを有し(たとえば、FLID=1)、したがって、同じFLIDを有するパケットは、オブジェクトの同じフローに属すオブジェクトとして、様々な実施形態のサーバおよび受信機デバイスによって扱われ得る。別のフローは、たとえば、DASH Media Presentationのオーディオデータであり得る。
オブジェクトの同じフローに属し、したがって同じFLID値を有するオブジェクトは、OSNサブフィールドを介して特定され得る。OSNサブフィールドは、第1のオブジェクトに対して0の値で開始し、フロー中の各々の後続のソースオブジェクトに対して1だけインクリメントされる、単純な整数を格納することができる。ある実施形態では、OSNは3バイトのパラメータであってよく、これは、毎秒1オブジェクトというオブジェクト配信レートにおいて、約200日間の別個のOSN値を可能にする。
TSIはFLIDサブフィールドをスコープすることができ、FLIDサブフィールドはOSNサブフィールドをスコープすることができる。すなわち、TSI値は、同じFLID値を有する2つのオブジェクトを区別するための十分なコンテキストを提供することができ、FLID値は、同じOSN値を有する2つのオブジェクトを区別するための十分なコンテキストを提供することができる。
ある実施形態では、システムはFLID値としてTSIを使用するように構成され得る。様々な実施形態において、TSIフィールドはDASH表現にマッピングされてよく、逆も同様である。
様々な実施形態に従ってTOIフィールドを2つのサブフィールド(すなわち、FLIDおよびOSN)に分割することによって、ブロードキャストネットワークは、ソースフローのためのFDTをブロードキャストする必要がなくなる。代わりに、ブロードキャストネットワークは、各受信機および各フローに対して(すなわち、フロー中の各オブジェクトに対してではなく)、単一のソースフロー宣言(FLUTEメタデータに含まれ得る)をブロードキャストすることができる。
ソースフロー宣言は、オブジェクトフローおよび/またはオブジェクトフローに含まれるパケットのオブジェクトに関する様々な情報フィールドおよび値の簡潔な表現であり得る。ソースフロー宣言は、オブジェクトシーケンス番号とオブジェクトとの間の関係を特定することができる。ソースフロー宣言は、メタデータレベルでフローを宣言することができる。これは、様々な情報フィールドおよび値をFLUTEメタデータに含めることによって達成され得る。ソースフロー宣言は、フロー中のソースパケットを特定する固有のフロー識別子(FLID)と、そのフローのための他の静的な情報とを含み得る。ソースフロー宣言はまた、フローのタイプ(たとえば、ビデオオブジェクトフロー、オーディオオブジェクトフローなど)に関する情報を含み得る。ソースフロー宣言は、フロー中のオブジェクトの多目的インターネットメール拡張(MIME)のタイプを特定し、他の同様の情報を含み得る。ある実施形態では、ソースフロー宣言は、フロー中のオブジェクトを(それらが暗号化されていれば)解読する際に使用するのに適した解読鍵および/または解読鍵のシーケンスの指示を含み得る。
FLUTEを使用したMBMS配信の場合、ソースフロー宣言はuser service description (USD)で搬送され得る。ソースフロー宣言は、FLUTE受信機または受信機デバイスに最も関連のあるシグナリング情報を通信することができる。ソースフロー宣言は、オブジェクト配信のフローに関連のある帯域外の事前の情報を受信機デバイスに提供することができる。
ある実施形態では、ソースフロー宣言は、次のようにサーバまたは受信機デバイスにおいて宣言または表現され得る。
flow_declaration{
flow_type = source
FLID = 5
source_type = video
}
フロー宣言の上の例では、フローのタイプは、この場合は「source」であるflow_typeデータフィールドの値によって示され、このフローのフロー識別子は、この場合は「5」であるFLIDデータフィールドの値によって示され、フローのオブジェクトで搬送されるコンテンツのタイプは、この場合は「video」であるsource_typeデータフィールドの値によって示される。一般に、flow_typeおよびFLIDは、flow_declaration内で宣言される必要があるが、他の情報はflow_declarationに含まれてよく、または含まれなくてよい。
代替として、既存のフィールドがフロー識別子(FLID)をシグナリングしてFLIDの使用をサポートするために使用されてよく、この場合、シグナリングまたはプロトコルに対する他の修正を伴うことなく、別個に定義されたOSNの代わりに、トランスポートオブジェクト識別子(TOI)のシグナリングおよび使用が、トランスポートオブジェクトを特定するために使用され得る。たとえば、LCTヘッダ中の既存のコードポイントフィールドが、(コードポイントフィールドの他の使用に加えて)FLIDをシグナリングするために使用されてよく、既存のTOIフィールドが、新たに定義されたOSNを使用する代わりに、トランスポートオブジェクト識別子をシグナリングするために修正されずに残され得る。
様々な実施形態は、ソースパケットが、FECまたはFECセマンティクスに対する依存性を含まず、チャンク配信を可能にし、送信オブジェクトが完全に利用可能になる前に送信オブジェクトの送信を可能にし、可変サイズのパケットへとソースオブジェクトをパッケージングすること(たとえば、背後にあるメディアの各アクセスユニットの配信)をサポートするように、ソースオブジェクトをソースパケットへとパッケージングするように構成されるブロードキャストサーバを含み得る。
ある実施形態では、source_typeデータフィールドまたは値は、対応するオブジェクトフローのMIMEタイプによって置き換えられ得る。
ある実施形態では、ソースパケットは、パケットで搬送される第1のソースオブジェクトバイトのバイトオフセットを含むソースペイロードIDデータフィールドおよび値を含むように生成され得る。ソースパケットはまた、ソースオブジェクトのバイトがパケット内で順次的に記憶されるように、かつ、終了バイト位置がパケットペイロードのサイズによって推測され得るように、生成され得る。ある実施形態では、ソースペイロードIDは、4バイトのパラメータであり得る。ある実施形態では、FEC復元の効率を改善するために、ブロードキャストシステムは、各ソースパケット中のバイトの数をFECシンボルのサイズと揃えることができる。ある実施形態では、ソースパケットはコードポイントも含むように生成されてよく、コードポイントは、ソースオブジェクトのバイト範囲または部分のための標識情報および/またはFECコーディング情報を含み得る。
この方式でソースオブジェクトをソースパケットへとパッケージングすることによって、様々な実施形態は、FEC動作またはFECセマンティクスとは無関係なソースオブジェクトの配信を可能にし得る。さらに、ソースオブジェクトがFEC動作とは無関係であるようにソースオブジェクトをパッケージングすることによって、送信機は、異なるFEC方法を必要なときに同じソースオブジェクトに適用することができる。
加えて、ソースオブジェクトがFEC動作と無関係であるようにソースオブジェクトをパッケージングすることによって、様々な実施形態は、送信機(すなわち、サーバ)が、FEC保護の方法を適用して、FEC保護の第1のバージョンを引き起こすためにソースフローまたはフローの組合せを保護する修復フローを生成することであって、各FEC符号化が、受信条件の悪い受信機への配信、または、ブロードキャストセッションのみを記録するので可能な最高の復元の忠実度を望む受信機のための配信に適した、フローの複数のオブジェクトまたはフローの組合せにわたって適用される、生成することと、FEC保護の第2のバージョンを引き起こすために同じフローまたはフローの組合せを保護する別の修復フローを生成することであって、各FEC符号化が、第1のバージョンよりも少数のフローのオブジェクトまたはフローの組合せにわたって適用される、生成することとを可能にでき、このことは、すべての他の受信機への配信に適したより短いエンドツーエンドのレイテンシを提供することができ、かつ/または、セッションに参加するときにメディアストリームへのより高速なアクセスを可能にする。たとえば、FEC保護の第1のバージョンは、各FEC符号化がソースフローからの連続するソースオブジェクトのペアに適用される第1の修復フローであってよく、FEC保護の第2のバージョンは、各FEC符号化が同じソースフローからの単一のソースオブジェクトに適用される第2の修復フローであってよい。
様々な実施形態のブロードキャストシステムは、ソースオブジェクトのシグナリングのいくつかの改善を提供するように構成され得る。既存のシステムは、FECセマンティクスを使用して、ソースオブジェクトのすべてのパケットが受信されたかどうか/いつ受信されたか、および/または、ソースオブジェクトの長さ/サイズを決定する。様々な実施形態は、受信機デバイスが、ソースオブジェクトのすべてのパケットが受信されたかどうか、またはいつ受信されたかと、ソースオブジェクトの長さ/サイズと、ソースオブジェクトが不完全なオブジェクトである(たとえば、すべてのパケットが受信されてはいない)かどうかを、すべて、パケットを使用することなく、またはパケットがFECセマンティクスを含むことを必要とすることなく、決定することを可能にし得る。ある実施形態では、これは、「close object flag」(たとえば、B-flag)をソースオブジェクトの最後のソースパケットにおいて設定することによって、ソースオブジェクトの終わりを示すようにシグナリングすることによって達成されることが可能であり、B-flagは既存のFLUTE規格に存在するフィールドである。
たとえば、B-flagフィールドの値は最後のソースパケットを除きすべて0に設定されてよく、最後のソースパケットにおいてB-flagは1に設定され得る。これは、FLUTE規格がB-flagフィールドの使用に対する決定的な要件または正確な要件を設定せず、いずれの場合でも、ソースオブジェクトの最後のソースパケットのみにおいてB-flagフィールドが1に設定されるべきであることを規定しないので、可能である。
ソースオブジェクトの最後のソースパケット(P)は、ソースオブジェクトの最後の部分を含む。したがって、B-flagを最後のソースパケットのみにおいて設定する(すなわち、PのB-flag=1と設定する)ことによって、様々な実施形態は、受信機デバイスがソースオブジェクトの最後の部分が受信されたかどうかを決定することを可能にし得る。さらに、受信機デバイスは、長さ/サイズの値を、最後のソースパケット(P)のソースペイロードID中のバイトオフセットと最後のソースパケット(P)のペイロードサイズとを足したものと等しくなるように設定することによって、ソースオブジェクトのサイズ/長さを決定することができる。さらに、受信機デバイスは、オブジェクトの任意の他の部分がオブジェクトのために受信された他のソースパケットのバイトオフセットおよびペイロードサイズを使用して受信されていないかどうかを決定することができ、すなわち、受信機は、ソースパケット内で受信されていないオブジェクトのバイトのシーケンスがあるかどうかを決定することができる。この方式で、ブロードキャストシステムは、ソースオブジェクトのすべてのパケットが受信されたかどうか、またはいつ受信されたか、ソースオブジェクトの長さ/サイズ、および/または、ソースオブジェクトが不完全なオブジェクトかどうかを、すべて、FDTまたは他のシグナリング情報が各オブジェクトに対して送信されることを必要とすることなく、かつ、ソースパケットまたはオブジェクトにFECセマンティクスを含めることなく、決定することができる。
図4は、ブロードキャストシステムが、ソースオブジェクトのすべてのパケットが受信されたかどうか、またはいつ受信されたかを、FDTセマンティクスまたはFECセマンティクスを伴わずに決定できるように、ある実施形態のソースオブジェクト402が複数のソースパケット404〜410へとパッケージングされることを示す。各ソースパケット404〜410は、B-flagフィールド、ソースペイロードIDフィールド、およびソースペイロードフィールドを含む。図4に示される例では、ソースオブジェクト402はサイズ/長さが5000バイトであり、最初の3つのソースパケット404〜408の各々は、サイズ/長さが1280バイトであるソースペイロードデータフィールドを含む。ソースオブジェクトのサイズ(すなわち、5000バイト)は1280の倍数ではないので、最後のパケット410のソースペイロードデータフィールドは1160バイトしか含まない。最初の3つのソースパケット404〜408の各々のB-flagフィールドは0に設定されるが、最後のパケット410の各々のB-flagフィールドは1に設定される。
概略的に、受信機デバイスまたは受信機は、ソースオブジェクト全体が受信されたかどうか、または、オブジェクトの少なくとも一部が欠けているかどうかを、受信されたソースパケットから決定することができる。たとえば、B-flagフィールドが1に設定されたオブジェクトの最後のパケットを受信機が受信しない場合、受信機は、オブジェクトの少なくともいくつかのサフィックスがまだ受信されていないと決定することができる。一方、B-flagフィールドが1に設定されたソースパケットがオブジェクトに対して受信されている場合、受信機は、オブジェクトのサフィックスを受信したと決定することができ、B-flagが1に設定されたパケット中のバイトオフセットとそのパケットのパケットペイロードサイズとの合計を計算することによって、オブジェクトのサイズを決定することができる。加えて、B-flagフィールドが1に設定されたソースパケットがオブジェクトに対して受信されたとき、受信機は、欠けているソースオブジェクトの内部の部分があるかどうかを、受信されたソースパケットのバイトオフセットおよびパケットペイロードサイズから決定することができる。
図4に示される例に関して、受信機デバイスは、ソースパケット404、408、および410を受信し(ソースパケット406は受信せず)、B-flagが1に設定されたソースパケット410の受信から、オブジェクトのサフィックスが受信されており、オブジェクトのサイズが3840(バイトオフセット)+1160(ペイロードサイズ)=5000バイトのサイズであることを決定することができる。受信機デバイスはまた、受信されたソースパケット、バイトオフセット、およびそれらのパケットのペイロードサイズから、オブジェクトのバイト1280〜2559(受信されなかったソースパケット406で搬送されるバイト)が欠けていると決定することができる。ソースパケット406の代わりに、受信機がソースパケット410を受信しなかった場合、受信機は、このオブジェクトに対してはB-flagフィールドが1に設定されたソースパケットをまだ受信していないこと、したがってオブジェクトのサフィックスがまだ受信されていないことを決定することができる。ある実施形態では、受信機デバイスは、ソースオブジェクトに対してまだ受信されていないさらなるパケットが送信されなかった、または送信されないであろう、または受信されないであろう高い確率があると決定する前に、ある期間待機し、必要に応じて復元動作を実行するように構成され得る。受信機がこの決定を行うために待機し得る時間の長さは、もしあればソース宣言中の配信時間情報に少なくとも部分的に基づき得る。
ある実施形態では、ブロードキャストシステムは、タイミング情報を含むようにソースパケット404〜410を生成するように構成され得る。このタイミング情報は、ソースパケットの送信のタイミングであり得る。したがって、ソースパケットのタイミングは、パケット自体の中に配置され得る。ソースパケットにタイミング情報を含めることで、システムは、RTP動作を複製し、ネットワークジッタを測定し、配信のタイミングを関連付け、メディアの時間関係を関連付け、NTPタイムスタンプを覆うマスクを規定することなどが可能になる。たとえば、システムは、64ビットのNTPタイムスタンプを生成し、タイミングの精度を決定するためにパケットに含めるべき64ビットのNTPタイムスタンプの4バイトのマスクを使用することができる。タイムスタンプは、パケットが送信される時間(または何らかの他の基準)を表すことができ、提示時間(RTPと同様であるがメディア同期のためには使用されない)と関連付けられてよい。マスクは、シグナリング情報において規定されてよく、ビット1と64との間の任意の範囲を有し得る。マスクサイズは、バイトベースのタイムスタンプを可能にするために、8ビットの倍数であり得る。マスクサイズはまた、タイミング情報の不在を示すために、0としてシグナリングされ得る。
ある実施形態では、システムは、FLUTE/LCTヘッダ中の混雑制御情報を使用してタイミング情報を搬送するように構成され得る。あるいは、FLUTE/LCTヘッダ中の混雑制御情報は、フローシーケンス番号を搬送して、受信機デバイスによるフローごとのパケットロスの測定を可能にするために使用され得る。
図5は、従来技術のFLUTEオブジェクトパケットヘッダ502と実施形態のFLUTEオブジェクトパケットヘッダ504との差の一部を示す。具体的には、図5は、実施形態のFLUTEオブジェクトパケットヘッダ504が、タイムスタンプ506フィールド、FLID 508フィールド、OSN 510フィールド、およびバイトオフセット512を含み得ることを示す。
様々な実施形態は、データ配信のエンドツーエンドのレイテンシが最小限であるように、ソースフローのチャンク配信および受信を遂行するように構成されるコンポーネントを含み得る。ブロードキャスト側では、実施形態のブロードキャストサーバが、チャンク中のソースオブジェクトが利用可能になるにつれてそれを送信することができ、それは、各ソースパケットが送信されるときに各ソースパケットにバイトオフセットを追加するだけでよいからである。ブロードキャストサーバはまた、ソースオブジェクトサイズがソースパケットを送信するために必要とされないように、ソースオブジェクトの最後のソースパケットにおいて「close object flag」(B-flag)を設定することができる。同様に、サーバは、ソースオブジェクト中の各部分または異なるタイプの部分の最後のパケットを特定するために、「close type」フラグ、フィールド、または値を設定することができる。たとえば、ソースオブジェクトが4つの異なる部分に区分され、第1の部分および第3の部分が「タイプA」として標識され、第2の部分および第4の部分が「タイプB」として標識される場合、システムは、その部分の最後のパケット、および/またはそのタイプの最後のパケットとしてそのパケットを特定するために、これらの4つの部分の各々の最後のパケットに、「close type」フラグ/フィールドを含め、または設定することができる。
受信機側では、受信機デバイスは、ソースオブジェクトがチャンクで到達するにつれてソースオブジェクトを復元するように構成され得る。受信機デバイスは、ソースパケットバイトオフセットを使用して、ソースオブジェクト内のデータの位置を決定し、順次的に受信されたソースパケットデータをアプリケーションまたはクライアント(たとえば、メディアプレーヤー)に直ちに送信することができる。受信機デバイスは、ソースペイロードIDバイトオフセットおよび「close object flag」(B-flag)フィールド値を介して、ソースオブジェクト内の欠けているデータを検出することができる。受信機デバイスは、受信されたソースパケットペイロードのバイトオフセット値およびサイズを介して、欠けているデータの穴があるかどうかを決定することができる。受信機デバイスは、B-flagが1に設定されたソースパケットをまだ受信していないと決定することによって、データの欠けているサフィックスを検出することができる。
図6は、HTTPヘッダ604フィールドおよび利用可能時間606フィールドを含む(またはそれらとバンドリングされる)ある実施形態のFLUTEオブジェクト602の図である。HTTPヘッダ604フィールドは、キャッシュ動作を複製するためのHTTPプロキシによる使用に適した情報を含む、HTTP応答ヘッダを含み得る。
利用可能時間606フィールドは、受信デバイスにおけるFLUTEオブジェクト602の利用可能タイミングに関するシグナリング情報または制御情報を含んでよく、これは、FLUTEオブジェクト602がアクティブ化されているかどうか、有効であるかどうか、または期限切れであるかどうかを、システムが決定することを可能にし得る。ある実施形態では、利用可能時間606フィールドは、消費するアプリケーションによる使用のために、オブジェクトの開始および/または終了利用可能時間に対するネットワークタイムプロトコル(NTP)タイムスタンプを含み得る。FLUTEオブジェクト602にそのようなタイミング情報を含めることは、ブロードキャストシステムが、キャッシュに記憶されたアイテムが限られた時間長の間だけ利用可能にされる、かつ/または、ある期間の後に期限切れになる、キャッシュタイムアウトポリシーと同様の機能を実装することを可能にし得る。この方式で、ブロードキャストシステムは、FLUTEオブジェクト602が現在のまたは最新の情報を含むことを確実にし得る。
既存のFLUTEの解決法では、ソースオブジェクトの配信のためのメタデータ情報を搬送するFDTオブジェクトは、対応するソースオブジェクトのタイミング情報またはタイムスタンプを含まない。FDTオブジェクトは、HTTP応答ヘッダに通常含まれる1つまたは2つのフィールドを含み得るが、既存のFDTオブジェクトは、様々な実施形態で遂行されるような完全なHTTPヘッダの含有を可能にしない。さらに、FDTオブジェクトをブロードキャストすることは追加の帯域幅を消費するので、かつ、各FDTは通常はフロー中の各ソースオブジェクトに対して繰り返しブロードキャストされるので、個々のFDTオブジェクトのサイズを最小化することが有利である。様々な実施形態は、FDTオブジェクトを伴わないオブジェクト配信を遂行し、ソースオブジェクトとともにHTTP応答ヘッダおよびタイムスタンプ情報を配信することができ、これは、各オブジェクトフローによって消費される帯域幅の量を減らす、ネットワークリソースのより効率的な使用である。
様々な実施形態は、テンプレート情報を含むソースフロー宣言情報を通信するように構成されるコンポーネントを含み得る。上で論じられたように、ソースフロー宣言は、オブジェクトフローに関する情報フィールド(たとえば、FLID、フロータイプ、MIMEタイプ、解読鍵情報など)の簡潔な表現であってよく、オブジェクトのフローの中のオブジェクト間の関係を特定するために使用されてよい。テンプレートおよびテンプレーティング技法を使用することによって、様々な実施形態は、ソースフロー宣言を使用して、オブジェクトのURIと、ブロードキャスト/マルチキャストチャンネルを通じてオブジェクトがいつ送信および/または受信される予定であるかとを特定することができる。たとえば、テンプレート情報を含むソースフロー宣言は、次のようにサーバまたは受信機デバイスにおいて表現され得る。
flow_declararation{
flow_type = source
FLID = 5
source_type = video
URI = http://localhost.seq1/object%OSN%
Timescale = 10
START_TRANSMISSION = %OSN*20%
END_TRANSMISSION = %OSN*20 + 20%
}
前述の例では、ソースフロー宣言のURIフィールドは文字列「%OSN%」を含む。テンプレーティング技法を使用すると、この文字列は、オブジェクトのURIとシーケンス番号との間の暗黙的なマッピングを与えるように、オブジェクトのフローの中の各オブジェクトに対して異なる値へと変換され得る。たとえば、このフロー内のOSN=25であるオブジェクトは、URI http://localhost.seq1/object25と関連付けられる。同様の技法が、送信情報のために、たとえば、「START_TRANSMISSION」フィールドおよび「END_TRANSMISSION」フィールドのために使用され得る。ある実施形態では、「START_TRANSMISSION」フィールドおよび「END_TRANSMISSION」フィールドは、配信のタイミングを示すための「Timescale」フィールドの値に基づいて計算され得る。たとえば、Timescale=10は、時間測定が毎秒10ティックの単位であることを示すので、このフロー内のOSN=25であるオブジェクトは、50秒という送信開始時間および52秒という送信終了時間を有する。
したがって、テンプレートおよびテンプレーティング技法は、オブジェクトのURI、オブジェクトの配信時間、FLID、OSN、およびURIの間の関係などを導出するための機構を提供するために使用され得る。したがって、テンプレートは、位置、名前、利用可能時間、および配信されるべきオブジェクトのシーケンスと関連付けられる他のメタデータとの間の関係をシグナリングする小型で簡潔な手段として、様々な実施形態において使用され得る。
様々な実施形態は、テンプレート情報およびアプリケーションへのリンクを含むソースフロー宣言情報を通信するように構成されるコンポーネントを含み得る。そのようなソースフロー宣言は、次のようにサーバまたは受信機デバイスにおいて表現され得る。
flow_declararation{
flow_type = source
FLID = 5
source_type = video
MPD_URL = http://news.video_content/sept25.2012.mpd
MPD_REP_ID = http://newsfeed.example.com/video500
URI = http://localhost.seq1/object%OSN%
Timescale = 10
START_TRANSMISSION = %OSN*20%
END_TRANSMISSION = %OSN*20 + 20%
}
前述の例では、ソースフロー宣言は、MPD_URLフィールドおよびMPD_REP_IDフィールドを含む。ある実施形態では、これらのフィールドは、オブジェクトとMPDにおいて記述される表現のDASHセグメントとの対応付けのために、実施形態のサーバまたは受信機デバイスによって使用され得る。
様々な実施形態は、ソースオブジェクトが、FECセマンティクスまたはFEC情報とは独立に無関係に、FDTの使用を伴わずに配信されることを可能にしながら、パケットヘッダのオーバーヘッドを最小化し、オブジェクトのチャンク配信をサポートし、可変サイズのソースパケットの使用を可能にする、進化したFEC能力をブロードキャスト通信システムに提供するように構成されるコンポーネントを含み得る。
様々な実施形態は、フロー宣言をシグナリングするために静的なファイル配信情報を使用するように構成されるコンポーネントを含み得る。
様々な実施形態は、オブジェクトコンテキストにおいてフローのバンドリングされたFEC保護に対するサポートを提供するように構成されるコンポーネントを含み得る。
様々な実施形態は、ソースオブジェクトを通信し、必要な場合にのみ、ソースフロー宣言またはソースオブジェクト以外でFEC情報を提供しながら、FEC能力を有さない受信機デバイスがFEC修復フローを無視することを可能にし得る。
FECはシンボルベースであってよく、修復フローごとに一定のシンボルサイズを伴う。
FEC修復フローは、1つまたは複数のソースフローにおいて(たとえば、バンドリングを介して)オブジェクトの保護を提供することができる。
様々な実施形態は、FEC修復フロー宣言、FEC修復パケット、およびFECトランスポートオブジェクト(ソースブロックまたはソースオブジェクトのバンドルを含み得る)のような、様々なFEC固有のコンポーネント、要素、通信メッセージ、およびデータ構造を含み得る。FEC修復フロー宣言は、FECシグナリング情報および他のFEC固有情報を含み得る。FECトランスポートオブジェクトは、ソースオブジェクトおよび関連する情報を含み得る。様々な実施形態は、1つのFECトランスポートオブジェクトまたは複数のトランスポートオブジェクトの連結物にFEC符号化を適用するように構成され得る。
ある実施形態では、受信機デバイスは、利用可能なFEC情報に基づいて、修復パケットからバンドリングされたオブジェクトを復元するように構成され得る。
様々な実施形態は、他のソースFLIDおよび修復FLIDとは異なる、各修復フローのための別個の固有のFLIDを含み得る。このFLIDは、TSIによってスコープされてよく、FLIDに含まれる情報をスコープすることができる。
様々な実施形態は、同期されたソースフローのためのFEC修復を提供することができ、このことはソースフローに対する保護を提供することができる。保護されたソースフローは、修復フロー宣言において列挙され得る。様々な実施形態は、保護されたソースフロー中のオブジェクトを時間的に揃え、異なるソースフローからの同じOSNを伴うソースオブジェクトを保護することができる。様々な実施形態は、修復のためのOSNが保護されたソースフローのためのソースオブジェクトのOSNと一致するように、各修復フローパケット中に1つのOSNを含めることができる。
様々な実施形態はまた、同期されていないソースフローに対してFEC修復を提供し、完全には時間的に揃えられていないオブジェクトを含むソースフローのための保護を提供することができる。様々な実施形態は、異なるフローからの異なるOSNを伴うソースオブジェクトを保護し、単一のソースフローの2つ以上のソースオブジェクトを保護することができ、これは、保護されるべきソースオブジェクトの何倍もこれらのソースフローを列挙することによって遂行され得る。
様々な実施形態は、修復フローパケット中のOSNの数を、保護されるオブジェクトの数に等しく設定することができる。OSNは、修復フロー宣言の中のソースフローリストと一致する順序で列挙され得る。
様々な実施形態は、FEC符号化動作のために使用され得る、ソースオブジェクトのためのFECトランスポートオブジェクトを含み得る。FECトランスポートオブジェクトは、ソースオブジェクト、パディングバイト、およびサイズ/長さ(F)フィールドを含んでよく、Fはソースオブジェクトのバイト単位のサイズである。ある実施形態では、サイズ/長さ(F)フィールドは4バイトのフィールドであり得る。
様々な実施形態は、FEC符号化動作のために使用され得る、ソースオブジェクトの一部分のためのFECトランスポートオブジェクトを含み得る。FECトランスポートオブジェクトは、ソースオブジェクトのバイト範囲およびパディングバイトを含み得る。ある実施形態では、FECトランスポートオブジェクトはまた、サイズ/長さ(F)フィールドを含み得る。様々な実施形態では、サイズ/長さ(F)フィールドは、ソースオブジェクトのバイト範囲、または、ソースオブジェクトのその部分のバイト範囲の最後とバイト範囲の最初の間のバイト単位の差を提供することができる。
FECトランスポートオブジェクトのサイズは、シンボルサイズTの倍数であり得る。サイズ/長さ(F)フィールドの値は、FECトランスポートオブジェクトの最後の4バイトで搬送され得る。この場合、FECトランスポートオブジェクト中のシンボルの数は、ceil((F+4)/T)として計算されてよく、ceil(x)は、少なくともx以上である最小の整数を返す関数である。たとえば、T=1280でありF=5000である場合、FECトランスポートオブジェクト中のシンボルの数は、ceil(5004/1280)=4として計算される。FECトランスポートオブジェクトは、最小限の数のパディングバイトを含むように生成され得る。パディングバイトおよびFは、ソースオブジェクトのソースパケット内で送信されてよく、FEC復号が復元するFECトランスポートオブジェクトの一部であってよい。
様々な実施形態は、FEC保護をソースフローに提供するためのFEC修復フローを含んでよく、これは、ソースフローのソースオブジェクトの一部分を保護するため、ソースフローの個々のオブジェクトを保護するため、1つまたは複数のソースフローから複数のオブジェクトを保護するため、または、1つまたは複数のソースフローからオブジェクトの複数の部分を保護するために使用され得る。ソースフロー中の個々のオブジェクトを保護するために使用されるとき、各FEC符号化は、ソースオブジェクトのためのFECトランスポートオブジェクトから生成され得る。1つまたは複数のソースフローから複数のオブジェクトを保護するために使用されるとき、各FEC符号化は、ソースオブジェクトのためのFECトランスポートオブジェクトの連結物から生成され得る。この連結物は、修復パケットにおいて受信される修復フロー宣言およびOSNによって示されるソースフローの順序であり得る。
様々な実施形態では、FECトランスポートオブジェクトの長さは、修復パケットで搬送されるTOLから受信機において決定されてよく、TOLは、修復パケットで搬送されるOSNおよび修復フロー宣言で宣言されるFLIDに対応するFECトランスポートオブジェクト中のシンボルの数を示す。TOLは、FEC保護されるソースオブジェクトの各FECトランスポートオブジェクトのための修復FECペイロードIDに含まれる2バイトの値であり得る。
一般に、FECデコーダは、それが復元すべきオブジェクトの部分に対するシンボルを知るだけでよい。したがって、様々な実施形態は、FEC保護されるオブジェクトの部分によって包含されるシンボル範囲に基づいて、FECトランスポートオブジェクトの長さを設定することができる。すなわち、FECトランスポートオブジェクトの長さは、ソースオブジェクトの一部分が包含するソースシンボルの範囲に基づいて設定され得る。たとえば、シンボルの長さが1000バイトであり(すなわち、新たなシンボルが1000バイトごとに開始し、シンボル0がソースオブジェクトのバイト0〜999を包含する)、FEC保護されるべきソースオブジェクトの部分がバイト1500で開始しバイト4500で終了する場合、システムは、バイト範囲1500〜4500を包含するようにシンボル範囲1〜4を示すように、FECトランスポートオブジェクトの長さを設定することができる。システムは次いで、FECトランスポートオブジェクト中の範囲1000〜1499および4501〜4999を0でパディングすることができる。ある実施形態では、受信機デバイスは自動的に、オブジェクトを復号するときにこのzeroのパディングを追加することができ、受信機は、オブジェクトを符号化するときにこれらのシンボルを追加することができる。このことは、パディング情報を送信する必要をなくす。このことはまた、FEC保護された部分からパディングバイトを除去することによって、FEC符号化に包含されるバイトの数を減らす。
部分的なシンボルの性能への影響を減らすために、ある実施形態では、FECトランスポートオブジェクトに含まれるパディングが小さいように、または重大ではないように、システムは、十分小さいシンボルサイズを選択するように構成され得る。ある実施形態では、システムは、シンボル境界と揃うようにパケット構造を生成するように構成され得る。
図7Aは、ソースオブジェクトのためのある実施形態のトランスポートオブジェクト700の図示である。示されるトランスポートオブジェクト700は、ソースオブジェクト702フィールド、パディング704フィールド、およびバイト範囲またはサイズ/長さ(F)706フィールドを含む。トランスポートオブジェクト700は、シンボルサイズTに基づいて決定され得る複数のシンボル境界708と関連付けられ得る。FECトランスポートオブジェクトがそれらへと区分され得るシンボルの数は、ソースオブジェクト702のサイズ/長さと、バイト範囲またはサイズ/長さ(F)706フィールドのサイズとの合計をシンボルサイズ(T)で割ったものの天井として計算され得る。トランスポートオブジェクト700は、サイズ/長さ(F)706フィールドおよびソースオブジェクト702フィールドを埋めることによって作成され得る。パディング704フィールドは、ソースオブジェクト702フィールドとサイズ/長さ(F)706フィールドとの間の任意の間隙を満たすように埋められ得る。
図7Aに示される例では、FECトランスポートオブジェクト700は3つのシンボルに区分され、ソースオブジェクト702はシンボル境界708で終了しない。送信オブジェクト長さ(TOL)はこの例では3であり、FECトランスポートオブジェクトが3シンボルのサイズであることを示す。
修復FECペイロードIDは、各々の保護されるオブジェクトに対して、符号化シンボル識別子(ESI)フィールドと送信オブジェクト長さ(TOI)フィールドおよびシンボルとを含み得る。ある実施形態では、ESIフィールドおよびTOLフィールドは各々、2バイトのサイズであり得る。
図7Bは、ソースオブジェクトの一部分のためのある実施形態のトランスポートオブジェクト750の図示である。示されるトランスポートオブジェクト750は、ソースオブジェクト702フィールド、パディング704フィールド、およびバイト範囲752フィールドを含む。トランスポートオブジェクト750は、シンボルサイズT(たとえば、1000)またはソースオブジェクトに基づいて決定され得る、複数のシンボル境界754と関連付けられ得る。FEC保護される部分によって包含されるバイト範囲752は、1500〜4500に等しくてよいので、保護部分のシンボル範囲は、シンボルサイズが上の例で説明されたように1000バイトに設定される場合、(すなわち、バイト範囲1500〜4500を包含するように)シンボル1〜4に等しくてよい。
修復FECペイロードIDは、ESIフィールドと、FEC保護される部分の開始側の境界と終了側の境界754を包含するシンボル範囲フィールドとを含み得る。ある実施形態では、ESIフィールドおよびシンボル範囲フィールドは各々、2バイトのサイズであり得る。
ある実施形態では、FECペイロードIDは、ソースシンボル開始位置とソースシンボル終了位置とを含み得る。さらなる実施形態では、FECペイロードIDは、オブジェクト識別子の保護されたフローからのソースのTOIを含み得る。TOIは2バイトのサイズであり得る。
好ましい実施形態では、FECペイロードIDは、保護されるべき部分のソースオブジェクト内のバイト開始位置とともに、保護されるべきソースオブジェクトの部分を含むFEC符号化オブジェクトのシンボル中でのサイズ(最も近いシンボル境界に切り上げられた)を含み、ソースオブジェクトの保護される部分のバイト(またはオクテット)単位のサイズは、このトランスポートソースブロックの最後で搬送される。この好ましい実施形態は、修復ヘッダのオーバーヘッドに関しては比較的効率的であり、トランスポートソースオブジェクト内のパディングバイトの無駄にされる保護を最小限にし、受信機が、FEC復号を行ってFEC符号化オブジェクトを復元し、修復ヘッダ内およびFEC符号化オブジェクト内の情報からソースオブジェクトの部分を抽出することを可能にする。
図8Aは、現在のFLUTE修復FECペイロードID 802と様々な実施形態の修復FECペイロードID 804、806、808との差を示す。現在のFLUTE修復FECペイロードID 802は、SBNフィールドとESIフィールドとを含む。実施形態の修復FECペイロードID 804、806、808の各々は、FEC符号化によって保護される各オブジェクトに対して、ESIフィールドと1つの送信オブジェクト長さフィールド(TOL1、TOL2、TOL3など)を含む。したがって、実施形態の修復FECペイロードID 804、806、808のフォーマットは、保護されるオブジェクトの数に依存する。
現在のFLUTE修復FECペイロードID 802は、ソースオブジェクトまたは対応するFECトランスポートオブジェクト(FEC符号化オブジェクト)の中のシンボルの数を特定する情報を含まず、ソースオブジェクトまたは対応するFECトランスポートオブジェクトの長さを特定する情報も含まない。代わりに、現在のFLUTEの解決法では、ソースオブジェクトおよび/または対応するトランスポートオブジェクトについての情報は、ソースオブジェクトと関連付けられる別個のFDTで搬送される。現在のFLUTE修復FECペイロードID 802のSBN(ソースブロック番号)フィールドは、修復パケットで搬送されるシンボルの生成元のソースブロックを特定し、これは、オブジェクトが複数のソースブロックに区分されるときに有用である。
ある実施形態では、実施形態の修復FECペイロードID 804、806、808のESIフィールドは、汎用オブジェクトシンボル識別子(UOSI)フィールドにより置き換えられてよく、UOSIフィールドは、修復パケットペイロードで搬送される修復シンボルがオブジェクトからどのように生成されるかを一意に特定する。FEC符号化オブジェクトの中のソースブロックの数が1であるとき、UOSIおよびESIは等価である。しかしながら、FEC符号化オブジェクトのソースブロックZの数が1より大きいとき、SBN値がCであるソースブロックからの、ESI値がBであるシンボルに対するUOSI値Aは、A=B*Z+Cとして計算される。ESIの代わりにUOSIを使用することは、オブジェクトが少なくとも場合によっては複数のソースブロックとして区分されFEC符号化される場合に、特に有用である。
図8Bは、現在のFLUTE修復FECペイロードID 802と様々な追加の実施形態の修復FECペイロードID 852aおよび852bとの差を示す。単一の(場合によっては部分的な)ソースオブジェクトに対するFECペイロードID 852aは、ソースオブジェクト開始バイト位置(SBP)、送信オブジェクトのシンボル単位のサイズである送信オブジェクト長さ(TOL)、およびESIフィールドを含む。FECペイロードID 852bはまたTOIフィールドを含む。同様に、FECペイロードID 858は、保護されるべきソースオブジェクトの一部分に対応する各TOIフィールドに対するSBPおよびTOLと、それらに続いてESIフィールドとを含み得る。
他の実施形態では、FECペイロードIDは、修復フローによって保護される各々の(場合によっては部分的な)ソースオブジェクトに対するソースオブジェクト開始バイト位置(SBP)および終了バイト位置(EBP)と、ESIフィールドとを含む。FECペイロードIDはまた、修復フローによって保護される各々の(場合によっては部分的な)ソースオブジェクトに対するTOIを搬送することができる。
FEC符号化オブジェクト中のソースブロックZの数が1より大きいとき、または、ソースブロックNごとのサブブロックの数が1より大きいとき、システムが、様々な特質、特性、または目標を、維持または達成することが重要であることが多い。たとえば、(本出願で説明されるように)ソースオブジェクトがFEC保護とは無関係に送信され得ることをシステムが確実にすることが重要であり得る。また、異なるソースオブジェクトからの異なる量のソースパケットの喪失があるときに保護されるオブジェクトを復元するとき、FEC保護動作が(たとえば、復元のオーバーヘッドに関して)効果的であり効率的であることをシステムが確実にすることが重要であり得る。加えて、FECトランスポートオブジェクトが、可能な限り少量のデータの並べ替えで、かつ可能な限り少量のメモリを使用して、効率的に復元されるように、FEC復号動作が受信機デバイスにおいて実行され得ることを確実にすることも、システムにとって重要であり得る。それでも、FEC符号化オブジェクトを形成するための従来の単純な方法は、システムがこれらの特質、特性、または目標を維持または達成することを可能にしないので、非効率的または不適切であることが多い。
様々な実施形態は、ソースブロックZの数が1より大きいとき、および/またはソースブロックごとのサブブロックの数Nが1より大きいときに、上で論じられた特質、特性、または目標をシステムが維持または達成することを可能にするために、FEC符号化オブジェクトを形成する方法と、その方法を実施するように構成されるコンポーネントとを含み得る。たとえば、コンポーネントは、ソースブロックに均等に(または可能な限り均等に)FECトランスポートオブジェクトの部分をマッピングするように構成され得る。次いで、ソースブロック内で、コンポーネントは、そのソースブロックのサブブロックにFECトランスポートオブジェクトの部分をマッピングすることができる。各々のそのようなFECトランスポートオブジェクトに対して、コンポーネントは、各FECトランスポートオブジェクトが各サブブロック内のサブシンボルの連続するセットを満たすように、各サブブロックの同じ数のサブシンボルを満たすことができる。
例として、FECトランスポートオブジェクトの数がOであり、FECトランスポートオブジェクト中のシンボルの数がKiであると仮定する。KtをKiのi=0からO-1までの合計とし、すなわち、KtはすべてのFECトランスポートオブジェクト中のシンボルの総数である。j=0からZ-1の各々に対して、Njをソースブロックjに割り当てられたソースシンボルの数とする。この例では、コンポーネントは、ソースブロックごとのシンボルの数およびサブブロックごとのサブシンボルサイズを、標準的な方法(たとえば、IETF RFC 6330で説明される方法)を使用して計算することができる。次いで、各オブジェクトi=0からO-1に対して、コンポーネントは、Ki,jがソースブロックjに割り当てられるべきFECトランスポートオブジェクトiのシンボルの数となるように、Z個のソースブロックの間でKiの値を区分することができる。これは、ソースブロックをラウンドロビン方式で網羅し、第1のオブジェクトのすべてのシンボルが割り当てられるまでにソースブロックの各々に第1のオブジェクトの1つのシンボルを割り当て、次いで、その時点からラウンドロビンを続け、第2のソースオブジェクトのすべてのシンボルが割り当てられるまでソースブロックの各々に第2のオブジェクトの1つのシンボルを割り当てることなどによって、遂行され得る。これらの動作(すなわち、ソースブロックをラウンドロビン方式で網羅すること)は、オブジェクトのシンボルのすべてのKtがソースブロックに割り当てられるまで、繰り返し実行され得る。コンポーネントは次いで、FECトランスポートオブジェクトの部分をFEC符号化オブジェクトのソースブロックの各々に割り当てることができる。これは、各FECトランスポートオブジェクトの最初から開始することによって遂行されてよく、ここでTはシンボルサイズであり、i=0からO-1およびj=0からZ-1に対して、オブジェクトiの次のKi,j*Tバイトがソースブロックjに割り当てられる。コンポーネントは次いで、各ソースブロックに割り当てられたFECトランスポートオブジェクトの部分をソースブロックのサブブロックに割り当てることができる。k=0からN-1に対して、SSkをサブブロックkに対するバイト単位のサブシンボルサイズとする。次いで、ソースブロックjのサブブロックkに割り当てられ得るFECトランスポートオブジェクトiの部分は、SSk*Ki,jバイトである。この方式でFEC、符号化オブジェクトを形成することによって、コンポーネントは、システムが上で論じられたすべての望ましい特質、特性、または目標を達成または維持することを可能にし得る。
様々な実施形態は、修復フロー宣言を生成または使用するように構成されるコンポーネントを含み得る。修復フロー宣言は、保護タイプ(同期されているか同期されていないか)を決定し、ソースフローのためのシグナリング動作をどのように実行するかを決定し、ソースフロー中の保護すべきソースオブジェクトを決定し、修復フローによって保護されるべきソースフローを決定するのに適した情報を含み得る。保護のタイプは、パケットのヘッダフォーマットを決定するのに有用であり得る。修復フロー宣言はまた、修復フローによって保護されるソースフローがFLIDによって特定され得るように、それらのソースフローを列挙することができる。修復フロー宣言はまた、列挙の順序がFECトランスポートオブジェクトの連結物の順序に対応するように、ソースフローを列挙することができる。ある実施形態では、修復フロー宣言はFEC OTIフィールドまたはFEC OTI値を含み得る。
単一の同期されたソースフローを保護する修復フロー宣言は、次のようにサーバまたは受信機デバイスにおいて表現され得る。
flow_declaration{
flow_type = repair
FLID = 20
repair_type = synchronized, source_FLIDs = 5
FEC Encoding ID = 6, Al = 8, T = 1280, Z = 1, N = 1
}
フロー宣言の上の例では、フローのタイプは、この場合は「repair」であるflow_type値によって示され、このフローのフロー識別子は、この場合は「20」であるFLID値によって示され、修復タイプは、この場合は「synchronized」であるrepair_type値によって示され、この修復フローによって保護されるソースフローは、この場合はFLID「5」を伴うソースフローであるsource_FLID値によって示される。
ある実施形態では、FEC OTIは、IETF RFC 6330で規定されるRaptorQコードに対応するFEC符号化ID=6と、8バイトの整列が使用されることを示すAl=8と、シンボルのサイズが1280バイトであることを示すT=1280と、FECトランスポートオブジェクトが1つのソースブロックとソースブロックごとに1つのサブブロックを含む(すなわち、サブブロック化が使用されない)ことを示すZ=1、N=1とを含み得る。修復フロー宣言に対して、repair_type値およびsource_FLID値が、FEC OTIとともに与えられ得る。
図9Aおよび図9Bは、上で論じられた例示的な修復フロー宣言に対応するFEC符号化オブジェクトおよび修復パケットを示す。
図9Aの上部分は、上で論じられた例示的な修復フロー宣言に対応するFECを実行する際に使用するのに適した修復パケットに含まれ得る、様々なデータフィールドを示す。具体的には、図9Aは、修復FLUTEヘッダ902がFLIDフィールドおよびOSNフィールドを含み得ることと、修復FECペイロードID 904がTOLフィールドおよびESIフィールドを含み得ることと、FEC符号化オブジェクト906がFECトランスポートオブジェクトを含み得ることとを示す。
902および904に示される修復パケットヘッダならびに上で示される対応するフロー宣言は、修復パケットがFEC符号化オブジェクト906から生成された修復シンボルを搬送することを示す。この例では、1つのソースオブジェクトが各FEC符号化によってFEC保護されるので、FEC符号化オブジェクト906は、ソースブロックの数ZおよびFEC符号化オブジェクト906のサブブロックの数Nがともに1であるとき、そのソースブロックに対応するFECトランスポートオブジェクトと一致する。FEC符号化オブジェクト906の長さが35シンボルであり、これは、修復FECペイロードID 904のTOLフィールドの値に対応する。この例では、この修復パケットで搬送される修復シンボルはESI=37を有する。
2つの同期されたソースフローを保護する例示的な修復フロー宣言は、次のようにサーバまたは受信機デバイスにおいて表現され得る。
flow_declararation{
flow_type = repair
FLID = 21
repair_type = synchronized, source_FLIDs = 6, 7
FEC Encoding ID = 6, Al = 8, T = 1280, Z = 1, N = 1
}
フロー宣言の上の例では、フローのタイプは、この場合は「repair」であるflow_type値によって示され、このフローのフロー識別子は、この場合は「21」であるFLID値によって示され、修復タイプは、この場合は「synchronized」であるrepair_type値によって示され、この修復フローによって保護されるソースフローは、この場合はFLID「6」および「7」を伴うソースフローであるsource_FLID値によって示される。FEC OTIは前の例と同じである。
様々な実施形態において、FEC修復によってソースオブジェクトの部分を保護するために、テンプレート化されたTOI範囲が、FEC修復フロー宣言の部分として提供され得る。たとえば、このTOI範囲は、修復TOI 10から19がソースフローからのソースオブジェクト1を保護し、修復TOI 20から29がソースオブジェクト2を保護することなどを特定し得る。以下は、そのようなFEC修復フロー宣言の例である。
flow_declararation{
flow_type = repair
FLID = 21
repair_type = synchronized, source_FLIDs = 6, 7
number_of_repair_TOIs_per_source_TOI = 10
FEC Encoding ID = 6, Al = 8, T = 1280, Z = 1, N = 1
}
上の例では、ソースTOIごとに宣言される10個の修復TOIがある。修復TOI 1〜10は、FLID=6およびFLID=7である、ソースフローからのTOI=1であるソースオブジェクトの部分を保護するために確保される。修復TOI 11〜20は、FLID=6およびFLID=7である、ソースフローからのTOI=2であるソースオブジェクトの部分を保護するために確保される。したがって、この例では、最大で10個の修復TOIが、FLID 6および7を伴う2つのソースフローからのソースオブジェクトの各ペアを保護するために使用され得る。2つのソースフローからのソースオブジェクトの異なるペアに対して、最大で最大限の割り振り(この場合は10個)までの、異なる数の使用される修復TOIがあり得ることに留意されたい。すなわち、ソースTOI=3を伴うソースオブジェクトのペアに対して、1個の修復TOI、たとえば修復TOI 30しか使用されないことがある。一方、ソースTOI=4を伴うソースオブジェクトのペアに対して、10個の修復TOI、たとえば修復TOI 40、41、...、49が使用されることがある。ソースTOI=5を伴うソースオブジェクトのペアに対して、0個の修復TOIが使用されることがある。
したがって、ソースオブジェクトの異なるペアに対して、ソースオブジェクトの部分の異なる数のFEC保護が提供され得る。さらに、ソースオブジェクトの同じペアに対して提供される2つの異なるFEC保護は、ソースオブジェクトの重複しない部分、またはソースオブジェクトの重複する部分を保護することができる。
たとえば、修復TOI 40と関連付けられるFEC保護は、TOI=4かつFLID=6であるソースオブジェクトの第1の半分、および、TOI=4かつFLID=7であるソースオブジェクトの第1の半分のバンドリングされた保護を提供することができる。修復TOI 41と関連付けられるFEC保護は、TOI=4かつFLID=6であるソースオブジェクトの第2の半分、および、TOI=4かつFLID=7であるソースオブジェクトの第2の半分のバンドリングされた保護を提供することができる。修復TOI 42と関連付けられるFEC保護は、TOI=4かつFLID=6であるソースオブジェクトの中間の半分、および、TOI=4かつFLID=7であるソースオブジェクトの中間の半分のバンドリングされた保護を提供することができる。
上の例では、各ソースオブジェクトに対するTOIは、修復フローの各修復パケットの修復FECペイロードID 952では搬送されない(または搬送されることが必要とされない)。これは、ソースオブジェクトTOIが、FEC修復フロー宣言で搬送されるテンプレート化されたTOI範囲、および各修復パケットの修復FECペイロードID 952で搬送される修復フローTOIに基づいて決定され得る。
図9Bの上部分は、ソースオブジェクトの部分にわたってFECを実行する際に使用するのに適した修復パケットに含まれ得る、様々なデータフィールドを示す。具体的には、図9Bは、修復FLUTEヘッダ902がFLIDフィールドおよびOSNフィールドを含み得ることを示す。修復FECペイロードID 952は、開始バイト位置(SBP)フィールド、送信オブジェクト長さ(TOL)フィールド、およびESIフィールドを含み得る。TOLは、ソースシンボルの送信オブジェクトの(シンボル単位の)サイズであり得る。
図9Bはまた、FEC符号化オブジェクト954が、保護されるべきソースオブジェクトの部分と、保護されるべきソースオブジェクトの部分のバイト単位のサイズ(場合によってはソースオブジェクトの部分とサイズとの間にいくつかのパディングバイトを伴う)とを含み得ることを示す。示される例では、SBP=1500およびTOL=4は、保護されるべき部分的なソースオブジェクトがソースオブジェクト内でバイト位置1500において開始することを示す。シンボルサイズが1000バイトである場合、TOL=4であるので、ソースオブジェクトのFEC保護される部分は、サイズが3001バイトと3996バイトの間である。この例では、部分的なソースオブジェクトのサイズは最大で3996バイトであり、それは、FEC保護されるべき部分的なソースオブジェクトのサイズを搬送するためのFEC符号化オブジェクトの最後に4バイトのフィールドがあり、したがって部分的なソースオブジェクトのサイズは、TOL=4でありシンボルサイズが1000バイトであるときには最大でも1000*4-4=3996バイトのサイズであり得るからである。したがって、終了バイト位置(この実施形態では明示的にシグナリングされない)は、4500(1500+3001-1)と5495(1500+3996-1)の間である。FEC符号化オブジェクト954の保護される部分の(バイト単位の)サイズはFEC符号化オブジェクト954の最後で搬送されるので、実際の終了バイト位置は、FEC符号化オブジェクト954のFEC符号化の後に決定され得る。示される例では、FEC、符号化オブジェクト954のバイト単位のサイズが3500として示され、終了バイト位置はソースオブジェクト内で4999(1500+3500-1)である。
別の実施形態では、修復FECペイロードID 952は、保護される各々の完全なソースオブジェクトまたは部分的なソースオブジェクトに対する開始バイト位置(SBP)フィールドおよび終了バイト位置(EBP)フィールドと、ESIフィールドとを含み得る。保護されるべき各ソースオブジェクトに対して、FEC符号化オブジェクト954は、保護されるべきソースオブジェクトの部分を含み得る。
図10の上部分は、2つの同期されたソースフローのためにFECを実行する際に使用するのに適した修復パケットに含まれ得る、様々なデータフィールドを示す。図10に示される例は、上で論じられた例示的な修復フロー宣言に対応する。
図10に示される例では、修復FLUTEヘッダ902のOSNフィールドは、2つの保護されたソースフローのためのものであり、FEC符号化オブジェクト906は、OSN 4を有するオブジェクトに対して、FLID=6を有するFECトランスポートオブジェクトとFLID=7を有するFECトランスポートオブジェクトの連結物を含む。保護されるFECトランスポートオブジェクトの長さは、オブジェクトが宣言において列挙される順序のような適切な順序(すなわち、18、10)で、修復FECペイロードID 904の中で2つのFECトランスポートオブジェクトのTOLを列挙することによって特定され得る。
2つの同期されていないソースフローを保護する例示的な修復フロー宣言は、次のようにサーバまたは受信機デバイスにおいて表現され得る。
flow_declararation{
flow_type = repair
FLID = 22
repair_type = unsynchronized, source_FLIDs = 8, 9
FEC Encoding ID = 6, Al = 8, T = 1280, Z = 1, N = 1
}
フロー宣言の上の例では、フローのタイプが、この場合は「repair」であるflow_type値によって示される。このフローに対するフロー識別子は、この場合は「22」であるFLID値によって示される。修復タイプは、この場合は「unsynchronized」であるrepair_type値によって示される。この修復フローによって保護されるソースフローは、この場合はFLID「8」および「9」を伴うソースフローであるsource_FLID値によって示される。FEC OTIは前の例と同じである。
修復パケットがソースオブジェクトの部分にわたってFECを実行する際に使用するのに適したものとなるように、様々なデータフィールドが修復パケットに含まれ得る。たとえば、修復FECペイロードID 904は、オブジェクトの保護される部分に対するシンボルまたはバイト範囲を特定する際に使用するのに適した、各々の保護される部分に対する開始位置(Start Pos)フィールドおよび終了位置(End Pos)フィールドを含み得る。
図11の上部分は、2つの同期されていないソースフローのためのFECを実行する際に使用するのに適しており、上で論じられた2つの同期されていないソースフローを保護する例示的な修復フロー宣言に対応する、修復パケットに含まれ得る様々なデータフィールドを示す。図11に示される例では、修復FLUTEヘッダ902は、オブジェクトの各々に対するOSNフィールド(OSN1、OSN2)、すなわち、「source_FLID」フィールドを介して修復フロー宣言において特定されるオブジェクト(すなわち、8および9というFLIDを有するオブジェクト)を含む。
様々な実施形態は、ソースフローと修復フローのいずれかに対して、オブジェクトシーケンス番号インジケータ(OSNI)フィールドまたは値においてオブジェクトシーケンス番号(OSN)を表すことができる。OSNIは、同期されたまたは同期されない修復フロー保護のためにOSNをシグナリングするための短い形式であり得る。OSNIはまた、保護されるオブジェクトの現在のバンドルにおいてオブジェクトがFEC保護されるべきかどうかを示すために使用され得る。すなわち、0のOSNI値は保護されるべきソースオブジェクトがないことを示し得るが、0ではないOSNI値はバンドル内であるソースオブジェクトが保護されるべきであることを示し得る。
様々な実施形態は、保護すべきソースオブジェクトがあるとき、OSNI値を((OSN modulo 255) + 1)に設定することができる。OSNI値からOSNへのマッピングは、OSNI値と、保護されるソースフローのためのソースフロー宣言中の開始送信時間情報および終了送信時間情報との組合せに基づいて、行われ得る。
例として、ソースフローの各ソースオブジェクトのための送信の期間が2秒であり、ソースオブジェクトのための送信が時間的に連続していると仮定する。送信の全体の時間長は、OSNI=191であるソースパケットが受信されるときである1401秒であるとさらに仮定する。この場合は、OSNI=191にマッピングされる可能なOSN値は、OSN=190、445、700、955、1210などを含む。さらに、OSN=190であるソースオブジェクトは時間380〜382秒の間隔において送信され、OSN=445であるソースオブジェクトは時間890〜892秒の間隔において送信され、OSN=700であるソースオブジェクトは時間1400〜1402秒の間隔において送信され、OSN=955であるソースオブジェクトは時間1910〜1912秒の間隔において送信され、OSN=1210であるソースオブジェクトは時間2420〜2422秒の間隔において送信される。したがって、実施形態の受信機デバイスは、高い信頼度で、送信の中の1401秒において受信されるOSNI=191であるソースパケットがOSN=700に対応すると決定することができる。
上の例では、受信機デバイスは、OSNI=191にマッピングされる他のOSN値を伴うパケットが時間1401秒において受信されるとき、その仮定/決定に誤りがあり得ることに留意されたい。しかしながら、これは通常、ソースフロー宣言中の送信時間情報において告知される時間よりも500秒早く、または遅く、パケットが送信または受信されるときにのみ起きる。たとえば、890〜892秒の間に送信されることが意図される、OSN=445であるソースオブジェクトからのパケットが1401秒において受信されるとき、実施形態の受信機デバイスは、予定された送信時間よりも500秒以上遅れてパケットが到達したと決定し、それに応じて応答することができる。
ある実施形態では、OSNIは長さが1バイトであり得る。これは、ソースフローと修復フローのいずれかに対してOSNを使用するときに必要とされ得る3バイトとは対照的に、システムがフローごとに1バイトのFLUTEヘッダしか使用しなくてよいことを意味し得る。修復フローに対して、OSNIはまた、システムが、保護されるべき「オブジェクトがない」ことをシグナリングすることを可能にでき、これは、OSNIの値を0に設定することによって遂行され得る。この方式で、システムは、変化する数の保護されるソースオブジェクトをサポートすることができる。すなわち、保護されるソースオブジェクトの数は可変であり得る。
OSN(短い形式)の代わりにOSNIを使用して3つの同期されていないソースフローを保護する例示的な修復フロー宣言は、次のようにサーバまたは受信機デバイスにおいて表現され得る。
flow_declararation{
flow_type = repair
FLID = 23
repair_type = unsynchronized short, source_FLIDs = 8, 8, 9
FEC Encoding ID = 6, Al = 8, T = 1280, Z = 1, N = 1
}
フロー宣言の上の例では、フローのタイプが、この場合は「repair」であるflow_type値によって示される。このフローに対するフロー識別子は、この場合は「23」であるFLID値によって示される。修復タイプは、この例では「unsynchronized short」であるrepair_type値によって示され、これは、(修復パケットヘッダ中のより長いOSNフィールドの代わりに)短いOSNIフィールドを使用した同期されない保護を示す。この修復フローによって保護されるソースフローは、この場合はFLID「8」、「8」および「9」を伴うソースフローであるsource_FLID値によって示される。FEC OTIは前の例と同じである。
図12の上部分は、3つの同期されていないソースフローのためのFECを実行する際に使用するのに適しており、すぐ上で論じられた例示的な修復フロー宣言に対応する、修復パケットに含まれ得る様々なデータフィールドを示す。図12に示される例では、修復FLUTEヘッダ902は、オブジェクトの各々のためのOSNIフィールド(OSNI 1〜3)を含む。OSNIフィールド(OSNI 1〜3)の値は、対応する3つのFECトランスポートオブジェクトの((OSN modulo 255) + 1)に等しくてよい。FEC符号化オブジェクト906は、FLID=8である2つのFECトランスポートオブジェクトと、FLID=9である1つのFECトランスポートオブジェクトとを保護する。
この例では、FLID=8であるソースフローに対して、各々の後続のソースオブジェクトのためのソースパケットが重複しない2秒の間送信されることと、FLID=9であるソースフローに対して、各々の後続のソースオブジェクトのためのソースパケットが重複しない4秒の間送信されることと、FLID=23である修復フローのための修復パケットが、修復パケットが保護するソースオブジェクトのためのソースパケットが送信されるのと同様の時間の間隔にわたって送信されることとを仮定する。さらに、図12の上部分で示されるヘッダを伴う修復パケットが、1401秒において受信されることを仮定する。この場合、実施形態のコンポーネントは、高い信頼度で、OSNI=191に対応するFLID=8であるソースフローのソースオブジェクトがOSN=700であるソースオブジェクトであることと、OSNI=192に対応するFLID=8であるソースフローのソースオブジェクトがOSN=701であるソースオブジェクトであることと、OSNI=96に対応するFLID=9であるソースフローのソースオブジェクトがOSN=350であるソースオブジェクトであることとを決定することができる。
様々な実施形態は、ソースオブジェクトのFEC復元および/またはソースオブジェクトの部分を実行するように構成されるコンポーネントを含み得る。受信機デバイスは、受信された修復パケットによって保護されるソースオブジェクトまたは部分を、その修復パケットのための修復フロー宣言において列挙されるソースフローのFLID(たとえば、TSIフィールド値)、修復パケットの修復パケットヘッダ中のOSN、および/または保護されるソースオブジェクトからのソースシンボルの範囲から決定するように構成され得る。
受信機デバイスは、修復パケットの修復FECペイロードID 904中の開始位置値フィールドおよび終了位置値フィールドから、保護されるオブジェクトの部分に対するシンボルの範囲を決定するように構成され得る。受信機デバイスは、修復パケットの修復FECペイロードID 904の中のTOLから、保護されるソースオブジェクトの各々に対する(シンボル単位の)FECトランスポートオブジェクトのサイズを決定することができる。ある実施形態では、受信機デバイスは、FECトランスポートオブジェクトのサイズを足すことによってFEC符号化オブジェクト906のサイズを決定するように構成され得る。受信機デバイスは、修復パケットの修復ペイロードID 904で搬送されるESIを使用して、シンボル(または複数のシンボルまたは複数のシンボルの部分)がFEC符号化オブジェクト906からどのように生成されるかを決定することができる。
受信機デバイスは、保護されるソースオブジェクトの1つのための受信されたソースパケットから、ソースデータの識別情報およびFEC符号化オブジェクト906へのソースデータの配置を決定するように構成され得る。たとえば、保護されるソースオブジェクトの1つのための受信されたソースパケットからの、ソースデータの識別情報およびFEC符号化オブジェクト906へのソースデータの配置は、ソースパケットヘッダにおいて受信されるFLIDおよびOSNから、FECトランスポートオブジェクトのTOLから、シンボル範囲から、かつソースパケットのソースペイロードIDの中のバイトオフセットから決定され得る。受信機デバイスのFECデコーダは、ソースパケット、バイト範囲情報、またはシンボル範囲情報からのFEC符号化オブジェクトおよび906(またはオブジェクトの部分)の十分なソースデータと、修復パケットからのFEC符号化オブジェクト906のための修復シンボルと、適切に配置されたソースパケットデータとを組み合わせて受信することに基づいて、FEC符号化オブジェクト906のすべてまたは部分を復元することができる。
受信機デバイスは、FEC符号化オブジェクト906からFECトランスポートオブジェクト(またはその部分)を抽出するように構成され得る。受信機デバイスは、各FECトランスポートオブジェクトの最後にあるソースオブジェクトサイズに基づいて、かつ/またはバイト範囲情報から、FECトランスポートオブジェクトからソースオブジェクト(またはその部分)を抽出することができる。
代替的な実施形態では、バイト範囲を使用することとは対照的に、コンポーネントは、既存のFEC方式のソースFECペイロードIDを使用するように構成され得る。この実施形態は、少なくともソース配信レベルで、既存のFEC方式との後方互換性をより良好にサポートすることができる。この実施形態はまた、オブジェクトのバンドリングをサポートし得る。たとえば、ソースFECペイロードIDは、FEC動作を実行する前に、または本出願で論じられる進化したFECフレームワークを適用する前に、バイト範囲へと変換され得る。この実施形態はさらに、進化したFECフレームワークをソースプロトコルコンポーネントにおける任意のFEC方式とともに適用することを可能にでき、これは以下でさらに詳細に論じられる。
別の代替例として、コンポーネントは、修復パケットヘッダ内での帯域内シグナリングを避けるために、修復フローによって保護されるトランスポートソースオブジェクトをシグナリングするように構成され得る。具体的には、OSN(またはOSNI)のリストを修復パケットヘッダにおいて明示的に搬送する代わりに、修復フローによって保護されるべきソースオブジェクトTOIは、修復フロー宣言内でテンプレーティングを使用してシグナリングされ得る。
様々な実施形態は、修復フローを伴うチャンク配信/受信を実行するように構成されるコンポーネントを含み得る。ブロードキャスト側では、サーバが、ソースオブジェクトが利用可能になるにつれてソースオブジェクトをチャンクで送信し、保護されるソースオブジェクトのためのソースパケットの後に送信される保護されるソースオブジェクトを修復し、エンドツーエンドの遅延に対する影響を最小限にすることができる。受信機側では、受信機デバイスは、ソースオブジェクトがチャンクで到達するにつれてソースオブジェクトを復元することができる。ソースオブジェクトデータは、受信されるにつれてクライアントアプリケーションに対して利用可能にされ得る。受信機デバイスは、FEC復号が必要ではない場合であっても、修復がオブジェクトのために受信されるときにだけ、最初のソースオブジェクトの再生を再生することができる。これは、FEC復号が後続のソースオブジェクトのために必要とされる未来における、ストールを防止する。あるいは、FEC符号化はソースオブジェクトの部分に適用されてよく、ソースオブジェクトが受信機デバイスに到達するにつれてソースオブジェクトの部分のFEC復号を可能にし、したがって、受信機デバイスにおけるより即刻の再生を可能にする。
ある実施形態では、受信機デバイスは、ソースオブジェクトが受信された後で直ちに、最初のソースオブジェクトの再生/レンダリングを開始するように構成され得る。FEC復号を必要とする後続のパケットロスは、FEC修復の到達を待つ間にストールを引き起こし得る。進化したメディア再生システムは、メディアの再生レートを調整することによって、たとえば、名目よりも低いビデオフレームレートで再生することによって、または、オーディオ処理を使用して再生時間を延ばすことによって、そのようなFEC技術を組み合わせることができる。
さらなる実施形態では、オブジェクトへと情報をパッケージングする方法が、FLUTE/3GPP MBMSを増強する、上で説明されたものと同様の能力および利益および機能を提供するようにMPEG Media Transport (MMT)を増強するために、MMT内での包括的なファイルおよび資産のトランスポートを提供するように拡張され得る。この実施形態は、通常はブロードキャストモードまたはマルチキャストモードでネットワークを通じて配信されるべき、関連するファイルのシーケンス(たとえば、ファイルのシーケンスへと区分されるビデオストリームまたはオーディオストリーム)を配信するという問題を解決する。動機を与える例はDASHセグメントを配信することであり、この場合、各セグメントは、オーディオもしくはビデオのファイル、または、オーディオ/ビデオのDASH表現である。
MBMSを介してDASHセグメントを配信するための既存の解決法があるが、これらの既存の解決法は、ファイルのシーケンスが論理的に関連していることを示す、もしくはシグナリングするための能力を欠いており、かつ/または、セグメント、ファイル、オブジェクト、エンティティ、ストリームなどの間の関係を規定するための能力を欠いている。上で説明されたように、本明細書では、これらの能力およびシグナリングによってMBMSを増強する方法を説明する。本明細書で説明される実施形態はまた、プロトコルのFLUTE/3GPP MBMSスイートについて上で説明されたのと同一の全体的なシステムアーキテクチャおよび方法に向かってプロトコルのMPEG MMTスイートを増強し、また、上で説明された全体的な方法およびシグナリング方法を増強する、新たなシグナリング、プロトコル、手順、および方法を提供することができる。
概略的に、この実施形態は、MMTプロトコルを通じた包括的な資産の配信のための解決法を提供する。包括的な資産は、DASH表現のセグメント、MPUのシーケンスなどのような、論理的にグループ化されアプリケーションに対していくつかの共通性を共有する1つまたは複数のファイルであり得る。コンポーネントは、General File Delivery Session (GFDS)を使用して、General File Delivery (GFD)プロトコルを介して包括的な資産を配信するように構成され得る。
包括的な資産またはオブジェクトに対する新たなデータタイプは、トランスポートされるべき包括的なオブジェクトを含むペイロードのために定義され得る。包括的なオブジェクトを搬送するパケットは、包括的なペイロードヘッダを有し得る。GFDセッション内で配信される各ファイルは、トランスポート配信情報と関連付けられ得る。これは、限定はされないが、転送の長さおよび転送コーディングのような情報を含み得る。転送コーディングについては、帯域内のメタ情報を伴わないファイル、帯域内のメタ情報を伴うファイルの配信を可能にし、帯域内のメタ情報を伴うファイルのプログレッシブな配信を可能にする、様々なタイプが定義され得る。
一般に、MMTプロトコルは、プロトコルパケットを解釈するために、受信機におけるセッション情報の存在と利用可能性に依存する。セッション情報は、フローと、フローを介して配信されるオブジェクトがどのように受信機デバイスによって解釈および/またはアクセスされるべきかとを記述し得る。ある実施形態では、そのようなセッション情報は、1つまたは複数のコードポイントにおいて定義され、含まれ、かつ/または配信され得る。たとえば、コードポイントは、関連するオブジェクトのパケットまたはシーケンスが、コードポイントにおいて定義される特定の制約のセットに適合することを、シグナリングするために使用され得る。これらの実施形態では、packet_id属性および値がフローID(FLID)に関して上で論じられた動作を遂行するために使用され得る。したがって、MMT内で包括的なファイルおよび資産をトランスポートする状況では、packet_idは、上で論じられたFLID属性と同じであってよく、またはそれに対応してよい。
実施形態は、HTTPを介してコンテンツを配信するときにだけ通常は利用可能である情報を、オブジェクトまたは関連するオブジェクトのシーケンスに割り当てるように構成されるコンポーネントを含み得る。実施形態は、オブジェクトまたはオブジェクトのシーケンスにこの情報を割り当て、そのような情報を効率的な方式で配信し使用するように構成されるコンポーネントを含み得る。これは、静的であり複数のオブジェクトに対して同一である情報を、セッション情報を定義するコードポイントに追加することによって、遂行され得る。
簡単には、コードポイントは、ファイル配信モードおよびこのコードポイントシグナリングによって配信される任意のオブジェクトの最大の転送の長さのような、様々な特質を定義し、含み、または規定し得る。加えて、コードポイントは、以下の情報、すなわち、オブジェクトの実際の転送の長さ、エンティティヘッダに存在し得る任意の情報、TOIおよびpacket_idパラメータ(もしあれば)を使用したContent-Location-Template、およびコンテンツについての特定の情報(たとえば、コンテンツがどのようにパッケージングされるかなど)のいずれかを含み得る。
単一のセッションにおいて、複数の階級の特質があり得る。ある実施形態では、各コードポイントは、ある階級の特質を定義するために生成されてよく、複数のコードポイントは、セッションのための複数の階級の特質を通信するために使用されてよい。
ある実施形態では、各コードポイントは、関連するオブジェクトのシーケンス中の特定のオブジェクトに対して、または関連するオブジェクトの特定のシーケンスに対して固有となるように、生成され得る。すなわち、オブジェクトのシーケンス中の各オブジェクトは、1つのコードポイントを参照し得る。ある実施形態では、コードポイントは、テンプレートファイルまたは同様のデータ構造において定義され得る。
実施形態は、1つのセッション内で複数のコードポイントをシグナリングするように構成されるコンポーネントを含み得る。コンポーネントは、HTTP RFC 2616において利用可能なすべての情報および特質と、追加のまたは補助的な情報とを含むエンティティヘッダを、コードポイントを介して生成することができる。コンポーネントは、(たとえば、TOIなどを使用して)解決され得るパラメータを含むテンプレートのような、非静的な情報を含むコードポイントを生成することができる。
実施形態は、アプリケーションに提供される必要があり得るGFDセッションにおけるファイル(たとえば、Composition Information document、Media Presentation Descriptionなど)を配信するように構成されるコンポーネントを含み得る。ファイルは、Content-Locationから提供または導出されるURIを通じて参照されてよく、Content-Locationは帯域内で、またはセッション記述の一部として提供され得る。すなわち、ファイルを参照するアプリケーションが存在することがあり、そのような情報をセッション記述に含めることは、MMT内で包括的なファイルおよび資産をトランスポートするのに適した接続の確立を可能にする。
ある実施形態では、コードポイントは、ファイルまたはオブジェクトを配信するための様々な方法を定義し得る。たとえば、オブジェクトは、追加の情報を含まない通常のファイルであり得る(すなわち、通常ファイルモード)。オブジェクトは、エンティティヘッダおよびファイルを含むエンティティであってよい(すなわち、通常エンティティモード)。オブジェクトは、エンティティヘッダ、ファイル、およびトレーラとして導出されてよい(すなわち、プログレッシブエンティティモード)。
図13Aは、ブロードキャストネットワークまたはマルチキャストネットワークを通じてオブジェクトのフローで情報を通信するある実施形態のサーバの方法1300を示す。ブロック1302において、ブロードキャストネットワーク中のサーバのサーバプロセッサは、情報をオブジェクトへとパッケージングすることができる。ある実施形態では、ブロック1302で情報をオブジェクトへとパッケージングすることの一部として、サーバプロセッサは、任意選択のブロック1304において、情報を可変サイズのソースパケットへとパッケージングすることができる。ある実施形態では、サーバプロセッサは、ブロック1302の一部として、オブジェクトが任意選択のブロック1306において、前方誤り訂正セマンティクスを含まないように、情報をパッケージングすることができる。ある実施形態では、ブロック1302の一部として、サーバプロセッサは、任意選択のブロック1308において、情報をFLUTEオブジェクトへとパッケージングすることができる。
ブロック1310において、サーバプロセッサは、ファイル配信テーブル(FDT)において各オブジェクトのための付随するメタデータを送信することなく、ブロードキャストネットワークを通じてオブジェクトのフローの中でオブジェクトを送信することができる。ある実施形態では、ブロック1310の一部として、サーバプロセッサは、任意選択のブロック1312において、関連するオブジェクトのシーケンスとしてオブジェクトを送信することができる。ある実施形態では、ブロック1310の一部として、サーバプロセッサは、任意選択のブロック1314において、情報のすべてが利用可能になる前にオブジェクトの送信を開始することができる。ある実施形態では、ブロック1310の一部として、サーバプロセッサは、任意選択のブロック1316において、ブロードキャストを通じてFLUTEを介してオブジェクトを送信することができる。
図13Bは、ブロードキャストネットワークまたはマルチキャストネットワークを通じてオブジェクトのフローで情報を受信し、ソースオブジェクト全体が受信されたかどうか、またはオブジェクトの少なくともある部分が受信されたソースパケットから欠けているかどうかを決定する、ある実施形態の受信機デバイスの方法1350を示す。ブロック1352において、受信機デバイスのデバイスプロセッサは、ブロードキャストまたはマルチキャストネットワークから送信されるソースパケットを受信することができる。決定ブロック1354において、デバイスプロセッサは、受信されたソースパケットのいずれかが「1」という値を有するB-flagデータフィールドを含むかどうかを決定することができる。
受信されたソースパケットが「1」という値を有するB-flagデータフィールドを含むとデバイスプロセッサが決定するとき(すなわち、決定ブロック1354=「Yes」)、ブロック1356において、デバイスプロセッサは、オブジェクトのサフィックスを受信したと決定することができる。ブロック1358において、デバイスプロセッサは、B-flagが「1」に設定されたパケット中のバイトオフセットとそのパケットのパケットペイロードサイズとを足すことによって、オブジェクトのサイズを計算することができる。ブロック1360および1362において、デバイスプロセッサは、バイトオフセットから欠けているソースオブジェクトの内部の部分があるかどうかと、受信されたソースパケットのパケットペイロードサイズとを決定することができる。受信されたソースパケットから欠けている内部の部分がないと決定されるとき(すなわち、決定ブロック1362=「No」)、ブロック1364において、デバイスプロセッサは、受信されたソースパケットに含まれるコンテンツおよび/または情報をレンダリングすることができる。受信されたソースパケットから欠けている内部の部分があると決定されるとき(すなわち、決定ブロック1362=「Yes」)、任意選択のブロック1366において、デバイスプロセッサは、追加の情報を受信するために待機すること、情報が再送信されるように要求すること、受信された修復パケットを使用してソースオブジェクトの欠けている部分をFEC復号すること、または、下げられた品質でコンテンツを提示するために受信されたパケットを処理することのような、復元動作を実行することができる。
受信されたソースパケットが「1」という値を有するB-flagデータフィールドを含まないとデバイスプロセッサが決定するとき(すなわち、決定ブロック1354=「No」)、ブロック1368において、デバイスプロセッサは、オブジェクトのいくつかのサフィックスがまだ受信されていないと決定することができる。任意選択のブロック1370において、デバイスプロセッサは、タイマーが満了したかどうか、またはオブジェクトのサフィックスが受信されない確率が高いことを示すための別の試験条件が満たされたかどうかを、決定することができる。タイマーが満了していないこと、または他の試験条件が満たされていないことをデバイスプロセッサが決定する場合(任意選択の決定ブロック1370=「No」)、ブロック1352において、デバイスプロセッサは、追加のソースパケットを受信するために待機することができる。
タイマーが満了したこと、または別の試験条件が満たされたことをデバイスプロセッサが決定する場合(任意選択の決定ブロック1370=「Yes」)、任意選択のブロック1366において、デバイスプロセッサは、受信された修復パケットを使用してソースオブジェクトの欠けている部分をFEC復号すること、または情報が再送信されるように要求すること、または下げられた品質でコンテンツを提示するために受信されたパケットを処理することのような、いくつかの復元動作のいずれかを実行することができる。
様々な実施形態において、サーバおよび受信機コンポーネントは、上で言及された動作、方法、および解決法のいずれかまたはすべてが、既存の技術および/または構造の拡張として実行され、遂行され、または実施され得るように、構成され得る。
図14A〜図14Bは、様々な実施形態による、コンテンツを通信するのに適したブロードキャスト通信システム1400、1420中の論理的および機能的コンポーネントを示す。これらのブロードキャスト通信システム1400、1420の各々において、情報を受信し、パッケージングし、FEC保護し、シグナリングし、通信するための動作は、別々の独立した動作のグループまたはカテゴリーへと分割され、動作の各グループまたはカテゴリーは、1つまたは複数のハードウェアおよび/またはソフトウェアコンポーネント(たとえば、サーバコンピューティングデバイスなど)によって実行され得る。そのようなグループ化/編成は、ブロードキャスト通信システム1400、1420の各々が、種々の異なる保護方式ならびに配信技術、プロトコル、および規格をより良好にサポートすることをより可能にし得る。
図14Aは、ブロードキャスト通信システム1400が、ソース配信プロトコル1402および前方誤り訂正(FEC)フレームワーク1404という2つの大きなグループへと分割または編成され得ることを示す。この方式でシステム1400を分割/編成することは、2つのasynchronous layered coding (ALC)インスタンス化が多重送信されること、または別様に組み合わされることを可能にする。このことは、既存のFLUTEフレームワークを含む、種々の既存の技術および/または構造を介してコンテンツが配信されることを可能にする。この編成/グループ化はまた、ブロードキャスト通信システム1400が、本明細書で論じられる特徴を含む、既存のブロードキャストの解決法を上回るいくつかの他の改善および利益を提供することを可能にする。
図14Aに示される例では、ソース配信プロトコル1402は、ソースALCコンポーネント1406を含む。ソースALCコンポーネント1406は、ソースLCTを含み、FECの使用を必要としない(FECなし)ように構成され得る。前方誤り訂正(FEC)フレームワーク1404は、オブジェクトバンドリングコンポーネント1414および修復ALCコンポーネント1408を含み得る。修復ALCコンポーネント1408は、修復LCTおよびFEC方式を含み得る。
ソース配信プロトコル1402は、ファイルの2つの集合体1410および1412の中のマルチメディアコンテンツを符号化する。各集合体1410、1412は、関連するファイルのグループを含み得る。例として、第1の集合体1410はビデオデータファイルを含んでよく、第2の集合体1412はオーディオデータファイルを含んでよい。各集合体1410、1412はフローであることもないこともある。各集合体1410、1412は、静的メタデータ(静的メタデータ1、静的メタデータ2)を割り当てられ得る。図14Aに示される例では、第2の集合体中の各ファイルは動的メタデータ(DMD)と関連付けられる。
システム1400は、システム中の各ファイルを個々のオブジェクトとして扱うように構成されてよく、各ファイル/オブジェクトはALCインスタンス化を通じて配信され得る。
ソースALCコンポーネント1406は、ファイル、オブジェクト、フロー、バンドル、または集合体を配信するように構成され得る。修復ALCコンポーネント1408は、FECのために、ファイル、オブジェクト、フロー、バンドル、または集合体を柔軟に保護するように構成され得る。
システム1400は、プロトコルを特定するLCT/UDPのための新たなプロトコルハンドラを定義することができる。ある実施形態では、システム1400は、コードポイントを使用して、オブジェクトの異なる集合体を特定しパラメータを割り当てることができる。
システム1400は、クライアントアプリケーション(たとえば、受信機デバイス中の)が、場合によっては最大のインターリーブ深さを伴って、オブジェクトおよび/または送信を事前に知らされ得るように、順序通りではないオブジェクトのバイト範囲の送信と、セッション定義中でのオブジェクトの送信のためのシグナリングとをサポートするように構成され得る。これは、システム1400が、オブジェクトのサイズがファイルの最初に追加される必要があるフォーマットをサポートすることを可能にする。これはまた、同じオブジェクトのより早く送信されるデータより小さいバイト範囲の数字を示すことによって、オブジェクトのコンテンツデータがまず送信され、ヘッダデータが利用可能になるとサイズフィールド/ヘッダが後で送信されることを可能にする。これは、受信機デバイスが、規定されたバイト範囲においてヘッダが追加された状態で、オブジェクトを再構築することを可能にする。
ある実施形態では、システム1400は、制約されたリストをシグナリングするために使用され得る、開始TOI、終了TOI、または両方を提供するように構成され得る。さらなる実施形態では、コードポイントは使用中の静的FDIを参照することができ、LCT時刻ヘッダは、サーバ時刻とクライアントを同期し、さらにエンドツーエンドのレイテンシまたはジッタを測定するために使用され得る。修復フローは、セッション記述1416およびコードポイントに対する参照を含んでよく、これらは、詳細な保護特性を取得するために使用され得る。
ある実施形態では、FECフレームワークコンポーネント1404は、修復パケットのみを送信するように構成され得る。ある実施形態では、システム1400は、個々のオブジェクトのサイズの送信を可能にするために、LCT拡張ヘッダを定義するように構成され得る。ある実施形態では、システム1400は、FEC保護されるスーパーオブジェクトを定義するように構成され得る。
図14Bは、様々な実施形態に従って、2つの集合体(すなわち、オブジェクトの2つの関連するグループ)に基づいてFEC修復パケットを生成し、FEC修復パケットとは独立にオブジェクトを受信機デバイスに配信するように構成される、例示的なブロードキャスト通信システム1420中の様々なコンポーネントおよび情報の流れを示す。図14Bに示される例では、ブロードキャスト通信システム1420は、ソースプロトコルコンポーネント1424および修復プロトコルハンドラコンポーネント1426へと編成される。修復プロトコルコンポーネント1406は、ソースオブジェクト作成コンポーネント1434、修復ALCコンポーネント1436、LCTコンポーネント1438、およびFEC方式コンポーネント1440を含む。ソースプロトコルコンポーネント1424は、ソースパケット作成コンポーネント1428およびLCTコンポーネント1430を含み、これらの組合せは、オブジェクト(たとえば、ソース/配信オブジェクト)またはオブジェクトのフロー/集合体を配信するように構成され得る。ある実施形態では、ソースパケット作成コンポーネント1428および/またはLCTコンポーネント1430は、Asynchronous Layered Coding (ALC)インスタンス化であり得る。
ソースプロトコルコンポーネント1424は、ソースデータ1442を受信し、使用し、パッケージングし、通信するように構成され得る。ソースプロトコルコンポーネント1424は、配信オブジェクトまたはオブジェクトのフロー/集合体を介してソースデータ1442を通信することができる。各配信オブジェクトは、場合によっては静的メタデータからの情報、送信セッションのLCTヘッダデータ/ストリーム識別子(TSI)および送信オブジェクト識別子(TOI)と組み合わされた、アプリケーションに対して自己完結しているオブジェクトであり得る。
ソースプロトコルコンポーネント1424は、各々が異なる特性または特質を有し得る、情報ユニット/エンティティの多様なセットを含むソースデータ1422を受信し使用するように構成され得る。たとえば、ソースプロトコルコンポーネント1424は、非リアルタイムのデータとリアルタイムのデータの組合せ、全体としてのみアクセス可能であり変化するサイズの(たとえば、数キロバイトからギガバイトまでの)サブユニット(たとえば、ファイル)を含む単一のデータファイル(たとえば、gzip化されたファイルなど)、および/または、個々にアクセス可能であるが一緒にされたときのみ有用であるデータファイルの集合体(たとえば、ウェブページのオブジェクトなど)を含む、ソースデータ1402を受信し使用することができる。さらなる例として、ソースデータ1402は、ブロードキャストマルチキャストサービスセンター(BMSC)上で全体として利用可能でありリアルタイムの制約を伴わずに配信される大きなマルチメディアファイル、任意のURL名によって参照される時限のメディアセグメントの集合体(たとえば、HLS配信における1つの表現)、共通のURLパターンによって参照される時限のメディアセグメントの集合体(たとえば、DASHにおけるMedia Presentation中の表現)、メディアプレゼンテーションの一部であるメディアセグメント、一緒に配信され一緒に再生される複数のメディアコンポーネント、または、サーバにおいて徐々に生成されサーバがファイル全体を生成するよりも前に送信されるメディアファイルを含み得る。別の例として、ソースデータ1402は、メディアファイルの一部分(たとえば、断片化されたMP4ファイル、DASH On-Demandフォーマットの表現など)だけを受信した後で受信機デバイスがレンダリング、再生、または消費を開始できるメディアファイルを含み得るが、このメディアファイルはサーバに対しては全体としてのみ利用可能にされる。
ソースプロトコルコンポーネント1424は、ソースデータ1422を使用して、関連するオブジェクトの集合体(すなわち、集合体1および集合体2)を生成するように構成され得る。図14Bに示される例では、ソースプロトコルコンポーネント1424は、3つの配信オブジェクト(すなわち、配信オブジェクト1〜3)と静的メタデータ(すなわち、静的メタデータ1)とを含む、第1の集合体(集合体1)を生成する。第2の集合体(集合体2)は、静的メタデータ(すなわち、静的メタデータ2)と、動的メタデータ(DMD)と関連付けられる3つの配信オブジェクト(すなわち、配信オブジェクト1'〜3')とを含む。
ある実施形態では、ソースプロトコルコンポーネント1424は、ダウンロード配信セッションとしてセッション情報を配信するように構成され得る。ダウンロード配信セッションは、セッション記述プロトコル(SDP)ユニットに含まれてよく、またはそれによって記述されてよい。
ある実施形態では、ソースプロトコルコンポーネント1424は、セッション情報またはソースプロトコルの使用法を記述するFEC方式をシグナリングするように構成され得る。ある実施形態では、ソースプロトコルコンポーネント1424は、セッション記述プロトコル(SDP)ユニットを介してFEC方式をシグナリングするように構成され得る。
様々な実施形態において、ソースプロトコルコンポーネント1424は、静的および/または動的ファイル配信記述子(FDD)を生成し、使用し、または通信するように構成され得る。ソースプロトコルコンポーネント1424は、各ダウンロード配信セッションのための1つまたは複数の静的FDDフラグメントを生成し、使用し、または通信することができる。ソースプロトコルコンポーネント1424は、1つまたは複数の静的FDDフラグメントを単一のダウンロード配信セッションと関連付けることができる。各FDDは、セッション記述プロトコル(SDP)ユニットのダウンロード配信セッションに含まれる@tsiデータフィールドの値を介して特定され得る。ある実施形態では、ソースプロトコルコンポーネント1424は、ファイル配信テーブル(FDT)のすべての機能を複製するように、FDDを生成し、使用し、または通信することができる。ある実施形態では、ソースプロトコルコンポーネント1424は、FDDがFDTの等価物を生成するために使用され得るように、たとえばTOIおよびテンプレートを使用することによって、FDDを生成し、使用し、または通信するように構成され得る。
様々な実施形態において、ソースプロトコルコンポーネント1424は、ソースフロー宣言を生成し、使用し、かつ/または通信するように構成され得る。ソースフロー宣言は、ユーザサービス記述(USD)に含まれてよく、それを介して通信されてよい。ある実施形態では、USDはメタデータフラグメントを含むように生成され得る。各メタデータフラグメントは、静的ファイル配信記述子(FDD)を規定するStaticFDDデータフィールドを含み得る。各StaticFDDデータフィールドはまた、@tsiデータフィールド、@objectDeliveryModeデータフィールド、@oufOfOrderSendingデータフィールド、@expiresデータフィールド、@completeデータフィールド、@contentTypeデータフィールド、@contentEncodingデータフィールド、CodePointデータフィールド、Fileデータフィールド、およびFileTemplateデータフィールドのような、様々な他のデータフィールドを含み得る。これらのデータフィールドの各々は、ソースデータ、配信オブジェクトまたは通信の様々な特性を特定または決定するために様々な実施形態のコンポーネントによって使用され得る情報を含み得る。
たとえば、@oufOfOrderSendingデータフィールドは、ソースデータ1422が順序通りではなく送信されるかどうかを決定するために使用され得る情報を含み得る。@objectDeliveryModeデータフィールドは、オブジェクト配信モードを特定するために使用され得る情報を含み得る。@tsiデータフィールドは、送信セッション/ストリーム識別子(TSI)、または、静的ファイル配信記述子(FDD)が割り当てられるトランスポートセッションを特定するために使用され得る情報を、LCTヘッダに含めることができる。たとえば、@tsiデータフィールドは、配信オブジェクトまたは配信オブジェクトの集合体を解釈するために使用される静的FDDインスタンスを特定するTSIを含み得る。加えて、@tsiデータフィールドはさらに、配信オブジェクトまたは配信オブジェクトの集合体のための(セッションの範囲内の)固有の識別子を含み得る。
StaticFDDデータフィールドのCodePointデータフィールドは、パケットヘッダにおいて使用されるコードポイントを特定し、かつ/または特定の値へのマッピングを特定する、情報を含み得る。CodePointデータフィールドは、@assignmentデータフィールド、@schemeIDURIデータフィールド、および@valueデータフィールドのような、様々な他のデータフィールドを含み得る。@assginmentデータフィールドは、コードポイントに割り当てられるCPフィールド(コードポイントフィールド)の値を特定する情報を含み得る。@schemeIDURIデータフィールドは、コードポイントを定義する方式を特定する情報を含み得る。@valueデータフィールドは、コードポイントを定義する方式の値を特定する情報を含み得る。
StaticFDDデータフィールドのFileデータフィールドは、既存のFLUTEの解決法を使用するときに「File要素」に通常は含まれるものと同じまたは同様の情報を含み得る。しかしながら、既存の解決法で使用される「File要素」とは異なり、FileデータフィールドはFECパラメータを含むことを要求されない。加えて、Fileデータフィールドは、@byteRangeデータフィールドのような、様々な他のデータフィールドを含み得る。@byteRangeデータフィールドは、配信オブジェクトを構成するファイルのバイト範囲を特定する情報を含み得る。このバイト範囲は、バイト範囲固有の表現として、またはバイトの連続的な範囲を特定する表現として、表現またはフォーマットされ得る。実施形態のコンポーネント(たとえば、受信機デバイス)は、この情報を使用して、配信オブジェクトがファイル全体を含むかファイルの部分を含むかを決定することができる。たとえば、コンポーネントは、@byteRangeデータフィールドがヌルである、空である、または値を含まないと決定したことに応答して、ファイル全体が配信オブジェクトであると決定することができる。
StaticFDDデータフィールドのFileTemplateデータフィールドは、配信オブジェクトまたはHTTPエンティティのボディに含まれ得る、ファイルテンプレートを特定するために実施形態のコンポーネントによって使用され得る情報を含み得る。FileTemplateデータフィールドは、@startTOIデータフィールドおよび@endTOIデータフィールドのような、様々な他のデータフィールドを含み得る。@startTOIデータフィールドは、配信される最初のTOIを特定するために使用され得る情報を含み得る。@endTOIデータフィールドは、配信される最後のTOIを特定する情報を含み得る。
様々な実施形態において、ソースプロトコルコンポーネント1424は、セッションにおいて配信されるすべてのファイルを記述するように構成され得る。ソースプロトコルコンポーネント1424は、個々に、またはリストを介してファイルを記述し得る。ソースプロトコルコンポーネント1424はまた、ワンタイムの静的記述子(たとえば、ファイル配信記述子)に静的ファイル情報を含め、ヘッダフィールドを使用してURL/URI情報のような動的情報を作成することができる。ソースプロトコルコンポーネント1424は、この技法を使用して、オブジェクト、オブジェクトのセット、または集合体を記述することができる。実施形態のコンポーネントは、本明細書で説明される様々な技法のいずれかを使用して、オブジェクトの集合体またはグループを特定することができる。たとえば、TSI値はオブジェクトの集合体またはグループをスコープすることができ、この場合、TOIおよび/またはバイト範囲がオブジェクトのグループを特定するために使用され得る。
様々な実施形態では、ソースプロトコルコンポーネント1424は、テンプレートまたはテンプレーティング技法を使用して、位置、名前、利用可能時間、および配信されるべきオブジェクトまたは集合体と関連付けられる他のメタデータの間の関係をシグナリングするように構成され得る。そのようなテンプレートおよびテンプレーティング技法は、オブジェクトのURI、オブジェクトの配信時間、FLID、OSN、およびURIの間の関係などを導出するための機構を提供するために使用され得る。
ある実施形態では、ソースプロトコルコンポーネント1424は、静的ファイル配信記述子にFileTemplate要素またはデータフィールドを含めるように構成され得る。FileTemplateデータフィールドは、配信オブジェクトまたはファイルの全体が受信機デバイスにおいて受信された後などに、置換パラメータによって置き換えられ得る識別子を含み得る。たとえば、FileTemplateデータフィールドは、対応するLCTパケットのTSIにより置換され得る$TSI$識別子と、対応するLCTパケットのTOIにより置換され得る$TOI$識別子とを含み得る。
ある実施形態では、ソースプロトコルコンポーネント1424は、エンティティヘッダフィールドの形式のメタ情報とエンティティボディの形式のコンテンツ(たとえば、ファイル、オブジェクトなど)を含む、オブジェクトまたはエンティティを配信するように構成され得る。ソースプロトコルコンポーネント1424は、たとえば帯域内配信技法を介して、かつ/または動的な方式で、ファイル自体と同じ配信オブジェクトにファイル属性を含めることができる。たとえば、ソースプロトコルコンポーネント1424は、Content-Location、Content-Size、Content-Rangeなどのような属性を、対応するファイルを含む同じ配信オブジェクトを介して関連付けて配信することができる。
様々な実施形態において、ソースプロトコルコンポーネント1424は、拡張ファイル配信テーブル(FDT)モードを含む、様々なFDT通信モードで動作するように構成され得る。拡張FDTモードで動作するとき、ソースプロトコルコンポーネント1424は、FDTおよびFDT拡張を使用して、通常はエンティティヘッダに含まれる情報を提供または通信することができる。FDT拡張の使用は、ソースプロトコルコンポーネント1424が、HTTP拡張ヘッダおよび他のHTTP能力をFLUTEを介してシグナリングすることを可能にし得る。
ソースプロトコルコンポーネント1424は、ファイルモード、通常エンティティモード、プログレッシブエンティティモード、冗長FDTモード、相補FDTモード、および動的FDTモードのような、様々なファイル配信モードで動作するように構成され得る。ある実施形態では、ソースプロトコルコンポーネント1424は、静的ファイル配信記述子ユニットを介してファイル配信モードを特定するように構成され得る。
ファイルモードで動作するとき、ソースプロトコルコンポーネント1424は、通常のファイルまたはファイルのバイト範囲としてオブジェクトを配信することができる。すなわち、通常のファイルモードで動作するとき、各配信オブジェクトは、ファイルまたはファイルのバイト範囲(すなわち、@byteRangeが存在する)を表し得る。ソースプロトコルコンポーネント1424は、配信オブジェクトと関連付けられるすべての情報をFDDに含めることができ、ファイルのすべての属性またはバイト範囲は、静的FDDまたは静的FDTを介して配信され得る。
ソースプロトコルコンポーネント1424はまた、通常エンティティモードでも動作することができる。このモードでは、LCTを介したオブジェクトの配信は、HTTPエンティティを介してコンテンツを配信する既存のHTTP配信技法と密接に、または完全に揃えられ得る。上で言及されるように、HTTPエンティティはエンティティヘッダとエンティティボディとを含む。したがって、通常エンティティモードで動作するとき、ソースプロトコルコンポーネント1424は、エンティティヘッダとエンティティボディとを含むエンティティ(すなわち、ファイル)としてオブジェクトを配信することができる。配信オブジェクトは、エンティティヘッダで開始するように、生成または通信され得る。配信オブジェクトは、メッセージボディがURLとコンテンツ範囲とを含むように生成または通信されてよく、URLおよびコンテンツ範囲は、配信オブジェクトが完全なオブジェクト/ファイルとは対照的なオブジェクト/ファイルのバイト範囲であることを、シグナリングし、通信し、または決定するために使用され得る。
通常エンティティモードで動作するとき、ソースプロトコルコンポーネント1424は、配信されるファイルに適用可能な静的ファイル配信記述子(FDD)または静的ファイル配信テーブル(FDT)において、ファイルのすべての属性を配信する。加えて、ファイルまたはバイト範囲とともに(たとえば、帯域内で)送信されるエンティティヘッダは、そのファイル/バイト範囲に対する追加の情報を含み得る。いくつかの属性がFDDとエンティティヘッダの両方に存在するとき、エンティティヘッダ中の値は、静的FDDの中の対応する値を上書きし得る。ヘッダがエンティティヘッダにContent-Rangeを含むとき、配信オブジェクトは、完全なオブジェクト/ファイルとは対照的に、オブジェクト/ファイルのバイト範囲を含むと決定され得る。
ソースプロトコルコンポーネント1424はまた、HTTP/1.1においてチャンク転送モードを介して遂行され得るものと同様の、ファイルのプログレッシブ配信を遂行するために、プログレッシブエンティティモードで動作することができる。プログレッシブエンティティモードで動作するとき、ソースプロトコルコンポーネント1424は、エンティティヘッダ、ファイル、およびトレーラを含むエンティティとしてオブジェクトを配信することができる。追加のヘッダファイルを含み得るトレーラは、ソースプロトコルコンポーネント1424が、オブジェクト/ファイルをプログレッシブな方式で配信することを可能にする追加のヘッダフィールドを含んでよく、すなわち、オブジェクト/ファイルはファイル全体が生成される前に配信され得る。
様々な実施形態では、ソースプロトコルコンポーネント1424は、コードポイントまたはエンティティヘッダにトレーラを含めるように構成され得る。静的ファイル配信テーブル(FDT)中のすべての属性が、配信されるオブジェクト/ファイルに適用され得る。加えて、ソースプロトコルコンポーネント1424は、ファイルのための追加の情報を含むようにエンティティヘッダを生成することができる。いくつかの属性が両方の位置(すなわち、FDDとエンティティヘッダ)に存在するとき、エンティティヘッダ中の値は、静的FDDの中の対応する値を上書きし得る。
冗長FDTモードで動作するとき、ソースプロトコルコンポーネント1424は、FDTに含まれる情報がFDDに含まれる情報に対して冗長となるように、オブジェクトとともにFDTを生成し送信することができる。相補FDTモードで動作するとき、ソースプロトコルコンポーネント1424は、受信機デバイスに対して有用であり得る追加の情報をFDTが含むように、オブジェクトとともにFDTを生成し送信することができる。動的FDTモードで動作するとき、ソースプロトコルコンポーネント1424は、受信機デバイスによって使用され得る不可欠な追加の情報をFDTが含むように、オブジェクトとともにFDTを生成し送信することができる。
ソースプロトコルコンポーネント1424は、FLUTEを介したオブジェクト配信を遂行し、本出願で論じられる様々な特徴および機能をサポートするために、LCT通信の技術および方法を特定の方法で使用するように構成され得る。たとえば、ソースプロトコルコンポーネント1424は、混雑制御ヘッダ(LCT/ACTで定義される)の値を0に設定すること、LCTヘッダ中のTSIをパケットによって適用される配信オブジェクトの集合体に従って(たとえば、@tsiデータフィールドを介して)設定すること、LCTヘッダ中のコードポイントを@codepointデータフィールドの値に基づいて設定すること、PSIの最初のビットを0に設定してソースパケットを示すことなどが可能である。ソースプロトコルコンポーネント1424はまた、配信オブジェクトの開始アドレス(たとえば、オクテット単位の、バイト単位のなど)を規定するソースFECペイロードIDを使用することができる。そのような情報は、直接のアドレス指定(たとえば、32または64ビットを使用した)を介して、または、SBN、ESI、およびシンボルサイズ(T)の値を使用することによって、通信され得る。
ソースプロトコルコンポーネント1424は、LCTヘッダEXT_TIME拡張を使用して、様々な時間の値およびイベントを通信またはシグナリングするように構成され得る。たとえば、ソースプロトコルコンポーネント1424は、EXT_TIME拡張を、送信機の現在時刻をシグナリングするための「送信機現在時刻」フィールドとして使用することができる。この情報は、送信機および受信機デバイスの中の時計と同期するために使用され得る。さらなる例として、ソースプロトコルコンポーネント1424は、EXT_TIME拡張を、現在のオブジェクトに対する予想される残存時間をシグナリングするための「予想残存時間」フィールドとして使用することができる。ソースプロトコルコンポーネント1424はまた、EXT_TIME拡張を、セグメントの追加または除去をシグナリングするためのSLCフラグ(セッション最終変更フラグ)として使用することができる。
ソースプロトコルコンポーネント1424は、ファイル/オブジェクトのすべてが送信機デバイスにおいて受信または生成される前に、ファイル/オブジェクトのバイト範囲または部分を順序通りではなく送信するように構成され得る。したがって、オブジェクト/ファイルのバイト範囲は順次的に送信されないことがある。むしろ、より後のバイト範囲がより前のバイト範囲よりも前に送信されることがある。そのような場合、ソースプロトコルコンポーネント1424は、@outOfOrderSendingデータフィールドを使用して、送信機デバイスがそのような技術を適用すること、および/またはバイト範囲が順序通りではなく送信され得ることを、受信機デバイスに通信することができる。
ファイル/オブジェクトのバイト範囲または部分を順序通りではなく送信することは、メディアが生成された後でヘッダデータが生成されることを要求するデータフォーマット、たとえばヘッダにファイルのサイズ情報を含むフォーマットでは特に有用である。そのようなフォーマットでは、ソースプロトコルコンポーネント1424は、受信機デバイスがデータユニットのサイズを決定するためにそのようなヘッダ情報を受信し使用できるように、データを送信した後でヘッダを受信機デバイスに送信することができる。ヘッダフィールドのサイズは通常は事前に知られているので、これは、オブジェクトが受信されたときに受信機デバイスがヘッダ部分を飛ばすことによって、または、本出願で論じられる他の技法のいずれかを使用することによって、遂行され得る。ヘッダフィールドのサイズが可変であるフォーマットをサポートするために、ソースプロトコルコンポーネント1424はデータまたは通信をパディングすることができる。ソースプロトコルコンポーネント1424はまた、時間(たとえば、ミリ秒)単位のインターリーブ深さ、最大のデータ範囲などを通信するためのフラグを設定または使用することができる。
様々な実施形態において、システム1140は、ソースと修復フローとを、それらの異なるUDPフロー(すなわち、異なるIP/UDPポートの組合せで搬送される)によって、かつ/またはそれらのセッション記述プロトコル(SDP)ファイルを介して、区別するように構成され得る。LCTパケットが同じUDPフローで送信されるとき、システム1140は、パケットのLCTヘッダフィールド中の送信セッション/ストリーム識別子(TSI)に基づいて、ソースと修復フローを区別することができる。LCTパケットが同じUDPフローで送信され同じTSI値を有するとき、システム1140は、パケットのヘッダ中のプログラムおよびシステム情報(PSI)ビットに基づいて、ソースフロー/パケットと修復フロー/パケットを区別することができる。これは、システム1420が後方互換性モードで動作するとき、または後方互換性をサポートすることが要求されるときに、特に有用であり得る。
修復プロトコルコンポーネント1426は、FECのために、配信オブジェクトの断片、配信オブジェクトのバンドル、および/または配信オブジェクトの断片のバンドルを保護するように構成され得る。加えて、修復プロトコルコンポーネント1426は、配信オブジェクトまたはその断片(すなわち、保護パケットとは対照的に)の配信を遂行するように構成され得る。
修復プロトコルコンポーネント1426は、FEC符号化方式、FEC復号方式、ならびに/またはパケットペイロードデータ(すなわち、FEC方式の状況において)を特定するための様々な他のプロトコルフィールドおよび手順を定義するように構成される、FEC方式コンポーネント1434を含み得る。様々な実施形態では、FEC方式コンポーネント1434は、トランスポート層の上の機能層(たとえば、UDP/IPマルチキャスト)のコンポーネント1428として実装されてよく、またはそれとして動作するように構成されてよい。
修復プロトコルコンポーネント1426はまた、配信オブジェクト1430またはオブジェクトの集合体(たとえば、集合体1、集合体2)を柔軟に保護するように構成される、Repair Asynchronous Layered Coding (ALC)コンポーネント1438を含み得る。さらに、修復プロトコルコンポーネント1426およびソースプロトコルコンポーネント1424の各々は、Layered Coding Transport (LCT)コンポーネント1436を含み得る。パケットはLCTパケットであり得る。
修復プロトコルコンポーネント1426は、1つまたは複数のFECオブジェクトを生成するように構成され得る。各FECオブジェクトは、完全な配信オブジェクトまたは配信オブジェクトの連続的なバイト範囲であり得る。様々な実施形態において、修復プロトコルコンポーネント1426は、FEC保護が単一のFECオブジェクトまたはFECオブジェクトの集合体に適用され得るように、構成され得る。修復プロトコルコンポーネント1426は、TSIがFECオブジェクトの集合体をスコープするために使用され得るように、構成され得る。修復プロトコルコンポーネント1426は、FEC構造とは独立に、かつ/または本出願で論じられる技法のいずれかを使用して、TOI/TSIをインスタンス化するように構成され得る。
様々な実施形態において、修復プロトコルコンポーネント1426は、FEC関連の情報が、そのような情報が必要とされる、要求される、かつ/または有用であると修復プロトコルコンポーネント1426が決定したときにのみ通信されるように、構成され得る。修復プロトコルコンポーネント1426はまた、FEC動作を実行することができない受信機デバイスがFEC関連の情報を無視し、それでも対応するコンテンツをレンダリングできるように、FEC関連の情報を通信するように構成され得る。修復プロトコルコンポーネント1426は、各々の保護される修復フローに対して一定のシンボルサイズで、シンボルベースのFEC動作を実行するように構成され得る。修復プロトコルコンポーネント1426はまた、各修復フローが1つまたは複数のソースフローからの配信オブジェクトに対する保護を提供するように、FEC動作を実行するように構成され得る。
修復プロトコルコンポーネント1426は、すべてのFEC固有の情報を含むFEC修復フロー宣言、ソースオブジェクトの保護される連続的なオクテット範囲またはソースオブジェクト自体であるFECオブジェクト、FECオブジェクトの連結物であるFECトランスポートオブジェクト、1つまたは複数のFECトランスポートオブジェクト、FECプロトコル、およびパケット構造の連結物であるFECスーパーオブジェクトを含む、またはそれを通信するように構成される、FECフレームワークであり得る。FECトランスポートオブジェクトは、データのシンボル整列されたチャンクを形成するために使用され得る、パディングオクテットおよびサイズの情報を含み得る。FECスーパーオブジェクトは、FEC保護のためにFECトランスポートオブジェクトをバンドリングするために使用され得る。
図15は、2つのソースオブジェクト1504、1506に基づいてFEC修復パケット1502を生成するように構成される、ある実施形態のFECフレームワーク1500中の、様々な構造、データフィールド、通信パケット、変換、および情報の流れを示す。FECフレームワーク1500は、図14Bを参照して上で論じられた修復プロトコルコンポーネント1426に含まれてよく、またはその一部として実装されてよい。ある実施形態では、ソースオブジェクト1504、1506は、図14Bに関して上で論じられた配信オブジェクトと同じであり得る。
図15に示される例では、FECフレームワーク1500は、第1のソースオブジェクト1504のための第1のFECオブジェクト1508と、第2のソースオブジェクト1506のための第2のFECオブジェクト1510とを生成する。FECオブジェクト1508、1510の各々は、完全なソースオブジェクトまたはソースオブジェクトの連続的なオクテット範囲であり得る。FECフレームワーク1500は、対応するソースオブジェクト1504、1506および/またはソースオブジェクト1504、1506のオクテット範囲のTSIおよびTOI、すなわち、ソースオブジェクト1504、1506内の開始オクテットおよび保護されるべきFECオブジェクト1508、1510を構成するソースオブジェクト1504、1506のオクテットの数を使用して、FECオブジェクト1508、1510を生成するように構成され得る。
各FECオブジェクト1508、1510に対して、FECフレームワーク1500は、FECオブジェクト1508、1510と、パディングオクテット(P)1516、1520と、FECオブジェクトサイズ(F)1518、1522との連結物を含む、FECトランスポートオブジェクト1512、1514を生成することができる。パディングオクテット(P)1516、1520は、ソースオブジェクト1504、1506とFECオブジェクトサイズ(F)1518、1522との間でFECトランスポートオブジェクト1512、1514の最後の方に向かって含まれる、パディングデータであり得る。FECオブジェクトサイズ(F)1518、1522の値は、オクテット単位で表現され、かつ/または4オクテットのフィールドを介して通信され得る。すなわち、FECオブジェクトサイズ(F)1518、1522は、FECトランスポートオブジェクト1512、1514の最後の4オクテットで搬送され得る。
様々な実施形態において、FECフレームワーク1500は、セッション情報および/または修復パケットヘッダに基づいて、FECトランスポートオブジェクト1512、1514の各々に対するFECトランスポートオブジェクトサイズ(S)を計算するように構成され得る。FECフレームワーク1500は、シンボルの単位で、かつ/またはシンボルサイズ(T)の整数倍として、FECトランスポートオブジェクトサイズ(S)を計算することができる。たとえば、FECオブジェクトサイズ(F)1518、1522がオクテット単位で表されるFECオブジェクト1508、1510のサイズであり、Fがソースオブジェクト1504、1506のデータのFオクテットであり、パラメータ「f」がネットワークにおいてオクテットの順序(高次のオクテットが先)でFの値を搬送するデータの4オクテットを示し、FECトランスポートオブジェクトサイズ(S)がFECトランスポートオブジェクトのサイズでありS=ceil((F+4)/T)であり、パディングオクテット(P)1516、1520がデータのS*T-4-F個の0のオクテットであり、OがF、P、およびfの連結物である場合、OはサイズS*TオクテットのFECトランスポートオブジェクトを構成する。
パディングオクテット(P)1516、1520およびFECオブジェクトサイズ(F)1518、1522は、ソースオブジェクト1504、1506のソースパケットで送信されることを要求されないことを理解されたい。むしろ、それらは、FECオブジェクト1508、1510を抽出するためにFEC復号が復元するFECトランスポートオブジェクト1512、1514に含まれ得るので、ソースオブジェクト1504、1506またはソースオブジェクト1504、1506の部分は、FECオブジェクト1508、1510を構成する。
FECフレームワーク1500は、FECトランスポートオブジェクト1512、1514についての全般的な情報を受信機デバイスに通信するように構成され得る。FECフレームワーク1500は、FEC対応受信機デバイスに伝えられるFECトランスポートオブジェクト1512、1514についての全般的な情報が、ソースTSI、ソースTOI、および関連付けられるFECオブジェクト1508、1510のソースオブジェクト1504、1506内の関連付けられるオクテット範囲であるように、構成され得る。FECオブジェクト1508、1510のオクテット単位のサイズはFECトランスポートオブジェクト1512、1514内の付加されたフィールドで提供され得るので、残りの情報は、FECトランスポートオブジェクト1512、1514と関連付けられるFECオブジェクト1508、1510の生成元であるソースオブジェクト1504、1506のTSIおよびTOI、関連付けられるFECオブジェクト1508、1510のためのソースオブジェクト1504、1506内の開始オクテット、ならびにFECトランスポートオブジェクト1512、1514のシンボル単位のサイズとして伝えられ得る。
FECフレームワーク1500は、FECトランスポートオブジェクト1512、1514および/またはFEC修復フロー宣言に基づいて、FECスーパーオブジェクト1540を生成するように構成され得る。たとえば、FECフレームワーク1500は、FECトランスポートオブジェクト1512とFECトランスポートオブジェクト1514の連結物を含むように、FECスーパーオブジェクト1540を生成することができる。FECフレームワーク1500はまた、上で説明されたFECトランスポートオブジェクト1512、1514についてのすべての全般的な情報、さらには、FECスーパーオブジェクト1540内のFECトランスポートオブジェクト1512、1514の順序を特定する情報を含めるように、FECスーパーオブジェクト1540を生成することができる。
ある実施形態では、FECフレームワーク1500は、FECスーパーオブジェクト1540中のソースシンボルの数を決定するように構成され得る。たとえば、NがFECスーパーオブジェクト構築のためのFECトランスポートオブジェクトの総数であり、S[i]がi=0, ..., N-1に対するFECトランスポートオブジェクトiのシンボル単位のサイズであり、BがFECトランスポートオブジェクト1512、1514の順序通りの連結物を含むFECスーパーオブジェクト1540である場合、FECスーパーオブジェクト1540は、K = sum (i=0) (N-1) S[i]個のソースシンボルを含むと決定され得る。
FECフレームワーク1500は、FECトランスポートオブジェクト1512、1514で搬送される全般的な情報を超える追加の全般的な情報を含むように、FECスーパーオブジェクト1540を生成するように構成され得る。そのような情報は、FECトランスポートオブジェクトの総数Nを含み得る。この情報はまた、FECトランスポートオブジェクト1512、1514と関連付けられるFECオブジェクト1508、1510の生成元であるソースオブジェクト1504、1506のTSIおよびTOI、関連付けられるFECオブジェクト1508、1510のためのソースオブジェクト1504、1506内の開始オクテット、ならびにFECトランスポートオブジェクト1512、1514のシンボル単位のサイズのような、各FECトランスポートオブジェクト1512、1514に対する値を含み得る。
ある実施形態では、FECフレームワーク1500は、FECスーパーオブジェクト1540に基づいてFEC修復パケット1502を生成するように構成され得る。FEC修復パケット1502は、Asynchronous Layered Coding (ALC)、LCT Layered Coding Transport (LCT) Building Blockに基づいて、かつ/または、本出願で論じられた技術、特徴、および修正のいずれかを含むように、生成され得る。たとえば、LCTヘッダ中のTSIは、FEC修復パケット1502が適用される修復フローに従って設定されてよく、これは、RepairFlow.SDPParameter@tsi属性を介して定義され得る。SPI(ソースパケットインジケータ)の最初のビットは、それが修復パケットであることを示すために0に設定され得る。FEC構成情報は、LCT拡張ヘッダで搬送され得る。
さらなる例として、FECフレームワーク1500は、FEC構築ブロックを使用して修復パケットのみを配信するように構成され得る。修復フローの範囲内の各修復パケット(LCTヘッダ中のTSIフィールドによって示されるような)は、適切な修復TOIを含む/搬送するように生成されてよく、適切な修復TOIは、TSIの範囲内で作成される各FECスーパーオブジェクトに固有であり得る。セッション記述情報は、上で論じられたSDPParameterなどを介して、SDPパラメータを通じて通信され得る。
FECフレームワーク1500は、概略FEC情報を受信機デバイスに通信するように構成され得る。様々な実施形態において、FECフレームワーク1500は、RepairFlow宣言において静的に、LCT拡張ヘッダにおいて動的に、またはこれらの組合せで、概略FEC情報を通信するように構成され得る。FECフレームワーク1500は、(修復フロー内の固有のTOIによって特定され、LCTヘッダ中のTSIによって修復フローと関連付けられる)各スーパーオブジェクトに対する、そのような情報を通信することができる。そのような情報は、FEC構成情報、FEC符号化ID、FEC OTI、および追加のFEC情報を含み得る。この情報はまた、FECスーパーオブジェクト1540に含まれるFECオブジェクトの総数、さらには、FECトランスポートオブジェクト1512、1514と関連付けられるFECオブジェクト1508、1510の生成元であるソースオブジェクト1504、1506のTSIおよびTOI、関連付けられるFECオブジェクト1508、1510のためのソースオブジェクト1504、1506内の開始オクテット、ならびにFECトランスポートオブジェクト1512、1514のシンボル単位のサイズを含み得る。
FECフレームワーク1500は、FECシグナリング情報を含むFEC修復フロー宣言を生成し、使用し、かつ/または通信するように構成され得る。たとえば、MBMSユーザサービスでは、修復フロー宣言は、バンドル記述またはユーザサービス記述のフラグメントとして含まれ得る。この修復フロー宣言の一部として、FECフレームワーク1500は、@tsi属性において修復フローの修復フロー識別子を提供することができ、すべての修復フローはタイプRepairFlowであると宣言される。IPアドレス、ポート、および修復フロー識別子の組合せは、ユーザサービス内のすべてのフローに固有の識別子を提供することができる。IP/ポートの組合せは、異なるFEC修復データ、さらにはソースデータを搬送し得ることに留意されたい。この場合、データは、LCTヘッダ中の異なるTSI値によって区別され得る。
ある実施形態では、FECフレームワーク1500は、修復フローによって保護されるべきソースフローからのソースオブジェクトのパターン(またはソースオブジェクトのオクテット範囲)を特定する情報を含むように、修復フロー宣言を生成するように構成され得る。さらなる実施形態では、FECフレームワーク1500は、セッション中で修復フローを定義するRepairFlowデータフィールドを含むメタデータフラグメントを含むように、修復フロー宣言を生成することができる。各々のRepairFlowデータフィールドはまた、@tsiデータフィールド、@sessionDescriptionデータフィールド、およびFECParametersデータフィールドのような、様々な他のデータフィールドを含み得る。@tsiデータフィールドは、セッション中のLCTヘッダにおいて修復フローが割り当てられるTSIを特定するために使用され得る情報を含み得る。@sessionDescriptionデータフィールドは、修復フローを含むセッション記述を参照するために使用され得る情報を含み得る。
FECParametersデータフィールドは、@fecEncodingIdデータフィールド、@maximumDelayデータフィールド、FECOTIデータフィールド、およびProtectedObjectデータフィールドのような、様々な他のデータフィールドを含み得る。@fecEncodingIdデータフィールドは、適用されるFEC方式を特定するために使用され得る情報を含み得る。@maximumDelayデータフィールドは、ソースフロー中の任意のソースパケットと修復フロー中の任意のソースパケットとの間の最大の配信遅延を特定するために使用され得る情報を含み得る。FECOTIデータフィールドは、オブジェクトと関連付けられるFEC関連情報、さらにはこの宣言に含まれるべきオブジェクトの符号化シンボルと関連付けられるFEC情報に対応し、修復フローを伴うすべての修復パケットに当てはまる、FECオブジェクト送信情報(FEC OTI)を含み得る。
ProtectedObjectデータフィールドは、修復フローによって保護されるソースフローと、保護がどのように行われるかについての詳細とを特定するために使用され得る情報を含み得る。実施形態のコンポーネントは、そのような情報を使用して、ソースフローが修復フローと同じセッションに含まれるかどうか、ソースフローが修復フローと同じTSIとともにシグナリングされるかどうか、ソースTOIが修復TOIと同じかどうかなどを決定することができる。実施形態のコンポーネントは、ソースTOIが修復TOIと同じであると決定したことに応答して、パケットがLCTヘッダ中のPSIフラグを介して区別され得ると決定することができる。実施形態のコンポーネントはまた、ProtectedObjectデータフィールド中の情報を使用して、各FECトランスポートオブジェクトのサイズがEXT_TOLヘッダを使用して修復パケットから取得され得るかどうかを決定することができる。
ProtectedObjectデータフィールドは、修復フローに含まれるオブジェクトの集合体の中のソースオブジェクトを特定するために使用され得る情報を含み得る。ProtectedObjectデータフィールドはまた、@sessionDescriptionデータフィールド、@tsiデータフィールド、@sourceTOIデータフィールド、@fecTransportObjectSizeデータフィールド、および@startOctetデータフィールドのような、様々な他のデータフィールドを含み得る。
@sessionDescriptionデータフィールドは、ソースフローを含むセッション記述を特定するために使用され得る情報を含み得る。実施形態のコンポーネントは、@sessionDescriptionデータフィールドが空であると決定したことに応答して、ソースフローが修復フローと同じセッションに含まれると決定するように構成され得る。
@tsiデータフィールドは、保護されるべきソースフローのためのトランスポートセッション識別子を特定するために使用され得る情報を含み得る。実施形態のコンポーネントは、@tsiデータフィールドが空であると決定したことに応答して、ソースフローが修復フローと同じtsi/TSIとともにシグナリングされることを決定するように構成されてよく、この場合、パケットは、ALC IETF RFC 5775で定義されるような、LCTヘッダ中のSPIフラグ(ソースパケットインジケータフラグ)を介して区別され得る。
@sourceTOIデータフィールドは、ソースオブジェクトのTOIと修復フローに含まれるTOIのマッピングとを特定するために使用され得る情報を含み得る。実施形態のコンポーネントは、@sourceTOIデータフィールドが空であると決定したことに応答して、ソースTOIが修復TOIと同じであると決定するように構成され得る。
@fecTransportObjectSizeデータフィールドは、シンボルの単位などで、各FECトランスポートオブジェクトのデフォルトサイズを特定するために使用され得る情報を含み得る。実施形態のコンポーネントは、@fecTransportObjectSizeデータフィールドが空であると決定したことに応答して、デフォルトサイズの値がEXT_TOLヘッダを使用して修復パケットにおいて提供され得ると決定するように構成され得る。
@startOctetデータフィールドは、関連付けられるソースオブジェクト中の開始オクテットを特定するために使用され得る情報を含み得る。実施形態のコンポーネントは、@startOctetデータフィールドが空であると決定したことに応答して、開始オクテット情報がEXT_TOLヘッダを使用して修復パケットに含まれ得ると決定するように構成され得る。実施形態のコンポーネントはまた、@startOctetデータフィールドが値を含む、または空ではないと決定したことに応答して、EXL_TOLヘッダが存在しないと決定するように構成され得る。
ある実施形態では、コンポーネント(たとえば、受信機デバイス)は、修復フロー宣言がProtectedObjectデータフィールド値を含むと決定したことに応答して、修復パケットが保護するソースオブジェクトのソースTOIに対する修復パケットに含まれる修復TOI値のマッピングを@sourceTOI属性が規定すると決定するように構成され得る。マッピングは、Cフォーマットである式を通じて記述されてよく、このとき修復フローのTOIフィールドは可変のTOIとして規定される。コンポーネントは、この式を適用した結果を使用してソースTOIを決定することができる。属性の値は、多くとも1つの可変のTOIを伴い、「,」記号の追加を伴わない、適切なCの式であり得る。コンポーネントはさらに、ProtectedObjectデータフィールドに含まれる@sourceTOIデータフィールドがないと決定したことに応答して、デフォルトの式(たとえば、sourceTOI=「TOI」)を適用するように構成され得る。
TSI値が1であるソースフローからのTOI値が20であるソースオブジェクトを保護する、TSI値が10でありTOI値が20である修復パケットのための例示的な修復フロー宣言が、次のようにサーバまたは受信機デバイスにおいて表現され得る。
<RepairFlow xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="urn:3gpp:mbms:schema:repairflow:2013"
xsi:schemaLocation="urn:3gpp:mbms:schema:repairflow:2013 repairflow.xsd"
tsi="10"
sessionDescription="http://mbmsrocks.com/example-session1.sdp">
<FECParameters fecEncodingID="6" maximumDelay="5000">
<FECOTI>XXXYYYYZZZZ</FECOTI>
<ProtectedObject
tsi="1"
sessionDescription="http://mbmsrocks.com/example-session1.sdp"
sourceTOI="TOI"
fecTransportObjectSize="892"/>
</FECParameters>
</RepairFlow>
@sourceTOI値を含まない例示的な修復フロー宣言は次の通りである。
<RepairFlow xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="urn:3gpp:mbms:schema:repairflow:2013"
xsi:schemaLocation="urn:3gpp:mbms:schema:repairflow:2013 repairflow.xsd"
tsi="11"
sessionDescription="http://mbmsrocks.com/example-session1.sdp">
<FECParameters fecEncodingID="6" maximumDelay="5000">
<FECOTI>XXXYYYYZZZZ</FECOTI>
<ProtectedObject tsi="2" fecTransportObjectSize="892"/>
<ProtectedObject tsi="3" fecTransportObjectSize="1340"/>
</FECParameters>
</RepairFlow>
上の例では、@sourceTOI属性がProtectedObjectにおいて提供されないので、デフォルトの式sourceTOI="TOI"が、TOIからソースTOIを導出するために使用される。したがって、TSIが11でありTOIが20である修復パケットによって保護されるスーパーオブジェクトは、TSIが2でありTOIが20であるソースオブジェクトに対するFECトランスポートオブジェクトと、TSIが3でありTOIが20であるソースオブジェクトに対するFECトランスポートオブジェクトの連結物である。両方の場合におけるFECトランスポートオブジェクトサイズが定義され、FECスーパーオブジェクトは全体で2232シンボルというサイズを有する。
TSIが12でありTOIが20である修復パケットによって保護されるFECスーパーオブジェクトのための例示的な修復フロー宣言は、TSIが4でありTOIが40であるソースオブジェクトに対するFECトランスポートオブジェクトと、TSIが5でありTOIが20であるソースオブジェクトに対するFECトランスポートオブジェクトと、TSIが4でありTOIが41であるソースオブジェクトに対するFECトランスポートオブジェクトとの連結物であり、次のようにサーバまたは受信機デバイスにおいて表現され得る。
<RepairFlow xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="urn:3gpp:mbms:schema:repairflow:2013"
xsi:schemaLocation="urn:3gpp:mbms:schema:repairflow:2013 repairflow.xsd"
tsi="12"
sessionDescription="http://mbmsrocks.com/example-session1.sdp">
<FECParameters fecEncodingID="6" maximumDelay="5000">
<FECOTI>XXXYYYYZZZZ</FECOTI>
<ProtectedObject tsi="4" sourceTOI="2*TOI"/>
<ProtectedObject tsi="5"/>
<ProtectedObject tsi="4" sourceTOI="2*TOI+1"/>
</FECParameters>
</RepairFlow>
上の例では、ソースオブジェクトのFECトランスポートオブジェクトサイズは、修復フロー宣言に含まれない。加えて、RepairFlow宣言内でのProtectedObject宣言のシーケンスが、スーパーオブジェクト中のソースオブジェクトに対するFECトランスポートオブジェクトの順序を決定するために使用され得る。
TSIが6でありTOIが21であるソースオブジェクトを保護する、TSIが13でありTOIが20である修復パケットのための例示的な修復フロー宣言が、次のようにサーバまたは受信機デバイスにおいて表現され得る。
<RepairFlow xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="urn:3gpp:mbms:schema:repairflow:2013"
xsi:schemaLocation="urn:3gpp:mbms:schema:repairflow:2013 repairflow.xsd"
tsi="13"
sessionDescription="http://mbmsrocks.com/example-session1.sdp">
<FECParameters fecEncodingID="6" maximumDelay="5000">
<FECOTI>XXXYYYYZZZZ</FECOTI>
<ProtectedObject tsi="6" sourceTOI="TOI+1"/>
</FECParameters>
</RepairFlow>
TSIが14でありTOIが10である修復パケットのための例示的な修復フロー宣言は、2つのソースオブジェクト、すなわち、TSIが7でありTOIが20であるソースオブジェクトおよびTSIが7でありTOIが21であるソースオブジェクトに対する、FECトランスポートオブジェクトの連結物を保護し、次のようにサーバまたは受信機デバイスにおいて表現され得る。
<RepairFlow xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="urn:3gpp:mbms:schema:repairflow:2013"
xsi:schemaLocation="urn:3gpp:mbms:schema:repairflow:2013 repairflow.xsd"
tsi="14"
sessionDescription="http://mbmsrocks.com/example-session1.sdp">
<FECParameters fecEncodingID="6" maximumDelay="5000">
<FECOTI>XXXYYYYZZZZ</FECOTI>
<ProtectedObject tsi="7" repairTOI="2*TOI"/>
<ProtectedObject tsi="7" repairTOI="2*TOI+1"/>
</FECParameters>
</RepairFlow>
上の例では、TSIが14である修復フロー宣言は静的FDDを提供する。加えて、FECスーパーオブジェクト中のFECトランスポートオブジェクトの順序は、ProtectedObject宣言がRepairflow宣言において行われる順序と同じである。したがって、TSIが14でありTOIが10である修復パケットに対応するFECスーパーオブジェクトは、TSIが7でありTOIが20であるソースオブジェクトに対するFECトランスポートオブジェクトと、TSIが7でありTOIが21であるソースオブジェクトに対するFECトランスポートオブジェクトの連結物である。
概略的に、前述の実施形態は、関連するソースオブジェクトの集合体をソースフローと関連付けるステップと、ソースオブジェクトが互いに対する関係に基づいて受信機デバイスによって受信され復元され得るように、ソースフローと関連付けられるブロードキャストネットワークを通じて、関連するソースオブジェクトの集合体を送信するステップとを含む、ブロードキャストネットワークを介して情報を通信するための、ブロードキャスト機および受信機デバイスにおいて実施され得る方法を含む。ある実施形態では、ソースフローを特定するソースフロー識別子(たとえば、FLID)が決定されてよく、ソースフローと関連付けられる関連するソースオブジェクトのうちのソースオブジェクトの1つまたは複数のためのデータを搬送する各パケットは、ソースフロー識別子を搬送することができる。ある実施形態では、パケットで搬送されるソースオブジェクトのデータは、パケットで搬送されるバイト範囲によって特定され得る。ある実施形態では、ソースフロー識別子は、送信セッション識別子(TSI)フィールドで搬送され得る。ある実施形態では、ソースフロー識別子は、IP宛先アドレスフィールドとUDPポート番号フィールドとの組合せで搬送され得る。ある実施形態では、ソースフロー識別子は、コードポイント(CP)フィールドで搬送され得る。
ある実施形態では、ソースオブジェクト識別子の集合体が決定されてよく、ソースフローの関連するソースオブジェクトの1つのためのデータを搬送する各パケットは、ソースオブジェクト識別子を搬送することができ、ソースフロー識別子とソースオブジェクト識別子の組合せは、関連するデータをパケットが搬送するソースフローと関連付けられる関連するソースオブジェクトの集合体からソースオブジェクトを特定することができる。ある実施形態では、ソースオブジェクト識別子は、送信オブジェクト識別子(TOI)であり得る。ある実施形態では、ソースオブジェクト識別子は、オブジェクトシーケンス番号(OSN)であり得る。
ある実施形態では、関連するソースオブジェクトの2つ以上の集合体はブロードキャストネットワークを通じて送信されてよく、関連するソースオブジェクトの各集合体は異なるソースフローと関連付けられてよく、ソースフローの各々を特定するソースフロー識別子は固有であってよく、データを搬送する各パケットのソースフローはパケットで搬送されるソースフロー識別子と関連付けられてよく、またはそれによって特定されてよい。
ある実施形態では、ソースフロー識別子の部分は、パケット内の異なるフィールド内で搬送され得る。ある実施形態では、ソースオブジェクトの少なくともいくつかはファイルのバイト範囲を含んでよく、ソースオブジェクトの少なくともいくつかはHTTPヘッダとファイルのバイト範囲とを含んでよい。ある実施形態では、URLはファイルと関連付けられてよく、ソースオブジェクトはファイルのURLおよび対応するバイト範囲によって参照されてよい。ある実施形態では、ソースオブジェクトの少なくともいくつかはファイルを含んでよく、URLは、ソースオブジェクトがファイルのURLによって参照され得るようにファイルと関連付けられてよい。
ある実施形態では、ソースオブジェクトの少なくともいくつかは、HTTPヘッダおよび関連付けられたファイルを含み得る。ある実施形態では、ソースオブジェクトの少なくともいくつかは、HTTPヘッダ、関連付けられたファイル、およびHTTPトレーラを含み得る。
さらなる実施形態は、ファイル全体の部分を受信するステップと、ファイル全体を受信する前にソースオブジェクトを受信された部分に基づいて生成するステップと、ファイル全体を受信する前に受信機デバイスへ生成されたソースオブジェクトを送信するステップとを含む、ブロードキャストネットワークを介して情報を送信するための、ブロードキャスト機および受信機デバイスにおいて実施され得る方法を含む。ある実施形態では、ファイル全体を受信する前に受信機デバイスへ生成されたソースオブジェクトを送信するステップは、ファイルのデータ順序とは異なる順序で、ソースオブジェクトのためのデータを送信するステップを含み得る。ある実施形態では、ファイルはファイルの最初にファイルサイズを含んでよく、ファイルサイズの後のファイルの少なくともいくつかのデータがファイルサイズよりも前に送信され得るような順序で、ソースオブジェクトのためのデータが送信され得る。ある実施形態では、ソースオブジェクトは、HTTPヘッダおよび関連付けられたファイルを含み得る。ある実施形態では、ソースオブジェクトは、HTTPヘッダ、関連付けられたファイル、およびHTTPトレーラを含み得る。
ある実施形態では、方法はさらに、ソースフローと関連付けられるソースオブジェクトの集合体のためのソースフローメタデータを決定するステップを含んでよく、ソースフローメタデータは、位置、名前、利用可能時間、または、ソースフローと関連付けられるソースオブジェクトの集合体のための他のメタデータの間の関係をシグナリングする。ある実施形態では、テンプレートは、ソースフローメタデータ中の関係性情報の少なくともいくつかをシグナリングするために使用され得る。ある実施形態では、ソースフローのためのソースフローメタデータの部分は、ソースフローと関連付けられる関連するソースオブジェクトの少なくともいくつかが送信されるときよりも前に、受信機デバイスに提供され得る。ある実施形態では、受信機デバイスに提供されるソースフローメタデータの部分は、タイミング情報、ユニフォームリソース識別子(URI)、およびソースオブジェクトのための解読鍵を特定する情報を含み得る。ある実施形態では、ソースフローメタデータの部分を受信機デバイスに提供するステップは、ソースフローと関連付けられるソースオブジェクトの少なくともいくつかを送信する前にフローメタデータの部分を帯域外で受信機デバイスに送信するステップと、ソースフローメタデータの他の部分をソースオブジェクトとともに帯域内で送信するステップとを含み得る。ある実施形態では、各ソースオブジェクトとともに帯域内で送信されるソースフローメタデータの部分は、ソースオブジェクトのデータの最後の部分の指示を含み得る。ある実施形態では、ソースフローメタデータの部分を受信機デバイスに提供するステップは、ファイル配信テーブルを送信することなく、単方向トランスポートプロトコルを介してソースフローメタデータの部分を送信するステップを含み得る。ある実施形態では、関連するソースオブジェクトの集合体を送信するステップは、マルチメディアブロードキャストマルチキャストサービス(MBMS)を介して関連するソースオブジェクトの集合体を送信するステップを含み得る。
ある実施形態では、関連するソースオブジェクトの集合体を送信するステップは、file delivery over unidirectional transport (FLUTE)を介して関連するソースオブジェクトの集合体を送信するステップを含み得る。ある実施形態では、関連するソースオブジェクトの集合体を送信するステップは、ソースオブジェクトを対応する修復オブジェクトとは独立に送信するステップを含み得る。ある実施形態では、方法はさらに、セッション記述プロトコル(SDP)情報を使用して、ソースオブジェクトを対応する修復オブジェクトと区別するステップを含み得る。ある実施形態では、関連するソースオブジェクトの集合体を送信するステップは、前方誤り訂正(FEC)シグナリング情報を送信することなくソースオブジェクトを送信するステップを含み得る。
ある実施形態では、方法はさらに、ソースオブジェクトが互いに対する関係に基づいて受信機デバイスによって受信され復号され得るように、ブロードキャストネットワークを通じて、ソースフローと関連付けられる関連するソースオブジェクトの集合体に対するFEC修復データを送信するステップを含んでよく、ソースフローと関連付けられる関連するソースオブジェクトの1つまたは複数に対するFEC修復データを搬送する各パケットは、関連するFEC修復データをパケットが搬送するソースフローを特定するソースフロー識別子を搬送することができ、ソースフローと関連付けられる関連するソースオブジェクトの1つまたは複数に対するFEC修復データを搬送する各パケットは、パケット中で搬送されるFEC修復データの生成元であり得る1つまたは複数のソースオブジェクトの1つまたは複数のソースオブジェクト識別子を搬送することができ、ソースフロー識別子と1つまたは複数のソースオブジェクトとの組合せは、パケット中で搬送されるFEC修復データの生成元であり得るソースフローと関連付けられる関連するソースオブジェクトの集合体からの1つまたは複数のソースオブジェクトを特定することができる。
ある実施形態では、方法はさらに、1つまたは複数のソースオブジェクトから生成されたFEC修復データを搬送するパケットを、1つまたは複数のソースオブジェクトのためのデータを搬送するパケットが送信されるのと同じ時間の間隔内に大半を送信するステップを含み得る。
ある実施形態では、方法はさらに、修復フローを1つまたは複数のソースフローと関連付けるステップと、修復フローの修復フロー識別子を決定するステップと、修復フローと関連付けられるFEC修復データを搬送する各パケットで修復フロー識別子を搬送するステップと、修復フローに対する修復オブジェクト識別子の集合体を決定するステップと、修復フローと関連付けられるFEC修復データを搬送する各パケットで、修復オブジェクト識別子の集合体からの修復オブジェクト識別子を搬送するステップとを含んでよく、修復フローと関連付けられる1つまたは複数のソースフローの関連するソースオブジェクトの集合体からのいずれのソースオブジェクトから、パケットで搬送されるFEC修復データが生成されるかが、パケットで搬送される修復フロー識別子と修復オブジェクト識別子の組合せによって少なくとも一部決定され得る。ある実施形態では、修復フロー識別子は、送信セッション識別子(TSI)フィールドで搬送され得る。ある実施形態では、修復フロー識別子は、IP宛先アドレスフィールドとUDPポート番号フィールドとの組合せで搬送され得る。ある実施形態では、修復フロー識別子は、コードポイント(CP)フィールドで搬送され得る。ある実施形態では、修復オブジェクト識別子は、送信オブジェクト識別子(TOI)である。ある実施形態では、修復オブジェクト識別子は、オブジェクトシーケンス番号(OSN)である。
ある実施形態では、方法はさらに、修復フローのための修復フローメタデータを決定するステップを含んでよく、修復フローメタデータは、FEC修復データを搬送するパケットで搬送される修復オブジェクト識別子と、パケット中のFEC修復データの生成元であるソースフローと関連付けられる関連するソースオブジェクトの1つまたは複数の集合体からのソースオブジェクトとの間の関係をシグナリングする。ある実施形態では、テンプレートが、修復フローメタデータ中の関係性情報の少なくともいくつかをシグナリングするために使用され得る。ある実施形態では、修復フローのための修復フローメタデータの部分は、修復フローと関連付けられるソースフローと関連付けられる関連するソースオブジェクトの少なくともいくつかが送信されるときよりも前に、受信機デバイスに提供され得る。
ある実施形態では、方法は、1つまたは複数のソースオブジェクトから生成されたFEC修復データを搬送するパケットを、1つまたは複数のソースオブジェクトのためのデータを搬送するパケットが送信されるのと同じ時間の間隔内に大半を送信するステップを含み得る。ある実施形態では、同じ修復フロー識別子および同じ修復オブジェクト識別子を伴うパケットで搬送されるFEC修復データは、異なるソースフロー中にある2つのソースオブジェクトから生成されてよく、同じ修復フロー識別子および同じ修復オブジェクト識別子を伴うパケットから、かつ、2つのソースオブジェクトを復号するのに十分な、それらのパケット中のFEC修復データの生成元の2つのソースオブジェクトから組合せで受信されるデータの量は、2つのソースオブジェクトの合計サイズと等しくてよく、またはそれよりわずかに大きくてよい。ある実施形態では、修復フロー識別子の部分は、パケット内の異なるフィールド内で搬送され得る。
図16は、実施形態のいずれかとともに受信機デバイスとして使用するのに適したモバイルコンピューティングデバイスのシステムブロック図である。典型的なモバイルコンピューティングデバイス1600は、内部メモリ1602と、ディスプレイ1603と、スピーカー1604とに結合された、プロセッサ1601を含み得る。加えて、モバイルコンピューティングデバイス1600は、プロセッサ1601に結合されたワイヤレスデータリンクおよび/または携帯電話送受信機1608と、プロセッサ1601に結合されたモバイルマルチメディアブロードキャスト受信機1610とに接続され得る、電磁放射を送信および受信するためのアンテナ1606を含む。モバイルコンピューティングデバイス1600は通常、ユーザ入力を受け取るためのメニュー選択ボタン1612またはロッカースイッチも含む。
モバイルコンピューティングデバイス1600はまた、マイクロフォンから受信された音をワイヤレス送信に適したデータパケットにデジタル化し、受信された音のデータパケットを復号し、スピーカー1604に供給されて音を発生させるアナログ信号を生成する、音の符号化/復号(CODEC)回路1614を含み得る。また、プロセッサ1601、ワイヤレス送受信機1608およびコーデック回路1614の1つまたは複数は、デジタル信号プロセッサ(DSP)回路(個別に示されず)を含み得る。
ブロードキャスト側の様々な実施形態は、図17に示されたサーバ1700のような、種々の市販のサーバデバイスのいずれでも実装され得る。そのようなサーバ1700は通常、揮発性メモリ1702と、ディスクドライブ1703のような大容量の不揮発性メモリとに結合されたプロセッサ1701を含む。サーバ1700はまた、プロセッサ1704に結合されたフロッピー（登録商標）ディスクドライブ、コンパクトディスク(CD)またはDVDディスクドライブ1701を含み得る。サーバ1700はまた、他のブロードキャストシステムコンピュータおよびサーバに結合されたローカルエリアネットワークのような、ネットワーク1706とのデータ接続を確立するための、プロセッサ1701に結合されたネットワークアクセスポート1705を含み得る。
プロセッサ1701は、上で説明された様々な実施形態の機能を含む、様々な機能を実行するためのソフトウェア命令(アプリケーション)によって構成され得る、任意のプログラマブルマイクロプロセッサ、マイクロコンピュータ、または1つもしくは複数の多重プロセッサチップであり得る。いくつかのモバイル受信機デバイスでは、1つのプロセッサをワイヤレス通信機能専用とし、1つのプロセッサを他のアプリケーションの実行専用とするなど、複数のプロセッサが設けられ得る。通常、ソフトウェアアプリケーションは、それらがアクセスされ、プロセッサ1601、1602にロードされる前に、内部メモリ1702に記憶され得る。プロセッサ1601、1602は、アプリケーションソフトウェア命令を記憶するのに十分な内部メモリを含み得る。
様々な実施形態は、ブロードキャストネットワークを通じて情報を通信する方法を含んでよく、この方法は、既存の技術、プロトコル、および/または構造を使用してファイル/オブジェクトを配信するステップと、パケットでファイル/オブジェクトを配信するステップであって、各パケットがファイルの連続的なバイト範囲を含むステップと、パケットでファイル/オブジェクトを配信するステップであって、バイト範囲に対するより大きな開始アドレスを伴う少なくとも1つのパケットがバイト範囲に対するより小さなアドレスを伴うパケットよりも前に送信される、ステップと、ファイル/オブジェクトの配信に適した通信プロトコルを特定するLCT/UDPのための新たなプロトコルハンドラを定義するステップと、コードポイントを使用してオブジェクトの異なる集合体を特定しパラメータを割り当てるステップと、セッション定義またはセッション記述メッセージまたはコンポーネントを使用してファイル/オブジェクトの配信および配信のシグナリングをサポートするステップと、サイズフィールド/ヘッダを送信する前にファイル/オブジェクトのデータを送信するステップと、開始送信オブジェクト識別子(TOI)または終了TOIまたは両方を使用して制約されたリストをシグナリングするステップと、コードポイントを使用して使用中の静的ファイル配信情報(FDI)を一意に特定するステップと、サーバとクライアントを同期するためにLCT時間拡張ヘッダを使用するステップと、ジッタまたはレイテンシの測定のためにLCT時間拡張ヘッダを使用するステップと、セッション記述およびコードポイントへの参照として修復フローを定義して詳細な保護特性を提供するステップと、FEC保護されるようにスーパーオブジェクトを定義するステップと、FECフレームワークをALCインスタンス化として使用して修復パケットのみを送信するステップと、個々のFECトランスポートオブジェクトのサイズの送信を可能にするLCT拡張ヘッダを定義するステップと、フロー識別子(FLID)をシグナリングするために、またはFLIDの使用をサポートするために既存のフィールドを使用するステップと、シグナリングまたはプロトコルに対する他の修正を伴わずにトランスポートオブジェクトを特定するためにTOIを使用するステップと、静的FDIを使用してフロー宣言をシグナリングするステップと、修復パケットヘッダ内での帯域内シグナリングを避けるために修復フローによって保護されるトランスポートソースオブジェクトをシグナリングするステップと、修復フロー宣言内でテンプレーティングを使用して修復フローによって保護されるべきソースオブジェクトTOIをシグナリングするステップとを含み得る。
様々な実施形態は、既存のブロードキャストの解決法を上回る、いくつかの増強および利益をもたらすことができる。実施形態は、関連するオブジェクトのシーケンスの増強されたFile Delivery Over Unidirectional Transport (FLUTE)ベースの配信を提供する。実施形態は、フローオブジェクト配信を遂行するための能力、Dynamic Adaptive Streaming over HTTP (DASH)および他の同様のアプリケーション、規格、またはプロトコルに対するサポート、および、コンテンツがオブジェクトから復元され得る前に受信されることが必要とされるオブジェクトの数を減らすための能力とを提供する。実施形態は、ストリーミング/送信される各オブジェクトのためのファイル配信テーブル(FDT)を配信する必要をなくす。実施形態は、事前にFLUTE受信機へ情報を供給することをサポートし、これは、オブジェクトがFLUTE受信機に送信される前またはFLUTE受信機によって受信される前に遂行され得る。実施形態は、タイミング情報、uniform resource identifiers (URIs)、およびオブジェクトの他の識別情報の、フロー中での配信を改善する。実施形態は、受信機デバイスにおける改善された意思決定と計画作成をサポートする。実施形態は、クライアントアプリケーションにリンクを供給することをサポートする。実施形態は、オブジェクトと、Media Presentation Description (MPD)において表される表現のDASHセグメントとの間の関係を確立し特定することをサポートする。実施形態は、コンテンツのチャンク配信/受信をサポートする。実施形態は、前方誤り訂正(FEC)動作の使用または受信機デバイスの能力とは無関係に、送信機のエンドツーエンドのレイテンシの低減を可能にする。実施形態は、FECが使用されないとき、または必要とされないとき、受信機のエンドツーエンドのレイテンシの低減を可能にする。実施形態は、FECの使用が許容可能であると見なされるまで動作を待機または休止するための能力を提供する。実施形態は、可変サイズのソースパケットを生成し、送信し、受信することをサポートする。実施形態は、アクセスユニット、ネットワーク抽象化層ユニット、サンプル、ファイルフォーマットのボックスまたは同様の構造のような、背後のメディア構造の境界とソースパケットの境界を揃えることをサポートする。実施形態は、FECセマンティクスを伴わないソースコンテンツの配信をサポートし、FEC能力を有さない受信機デバイスがソースコンテンツを受信することを可能にする。いくつかの実施形態は、FECオブジェクトのバンドリングをサポートし、複数のオブジェクトにわたるFEC保護を提供し、他の実施形態は、個々のソースオブジェクトの部分に対するFEC保護を提供し、さらに他の実施形態は、個々のソースオブジェクトの部分のバンドルのFEC保護を提供する。実施形態は、RFC 2616で定義されるもののような、完全なHTTP GET応答としてオブジェクトを配信することを可能にする。実施形態は、現在のブロードキャストおよびFLUTE規格との互換性、およびそれらの再使用に対するサポートを提供する。実施形態は、FDTを使用することのない本明細書で説明される関連するオブジェクトのシーケンスの配信を伴う、同じセッション中でのFDTを使用した標準的なFLUTEオブジェクトの配信をサポートする。様々な実施形態はまた、下で論じられるいくつかの追加の利益および増強を含み得る。
様々な実施形態によって提供される、既存のブロードキャストの解決法を上回る追加の増強および利点はまた、MPEG Media Transport (MMT)内での汎用的なファイルおよび資産のトランスポート、コードポイントの使用、オブジェクトの一部としてのHypertext Transfer Protocol (HTTP)ヘッダの使用、テンプレーティング、ファイルのコンテンツ固有の様相を配信するためのコードポイントの使用およびコードポイント中でのシグナリング、コードポイントを介したシグナリングに適した機能を含むMMTプロトコルの修正、コードポイントのトレーラまたはエンティティヘッダを介したオブジェクト転送サイズのシグナリング、オブジェクトが定期的に配信されるHTTPリソースとしての使用に適するようにHTTPエンティティヘッダとHTTPエンティティボディの組合せとして単方向プロトコルを通じてオブジェクトを配信すること、チャンク配信または順次的な配信を介してオブジェクトを配信すること、サイズ値または他の情報をトレーラ中のオブジェクト配信の一部として追加することによって、オブジェクトのサイズまたは配信の開始の時点で知られていないオブジェクトに関する他の情報を示すこと、ペイロードに関連するオブジェクトがMPEG Media Transport (MMT)プロトコルヘッダ中のpacket_id属性(オブジェクトが属するフローを特定する)およびGeneral File Delivery (GFD)プロトコルヘッダで搬送される送信オブジェクト識別子(TOI)属性(オブジェクトのフロー内の特定のオブジェクトを特定する)とによって特定されるように、MMTプロトコルを介してオブジェクトを配信することを含み得る。
上記の方法の説明およびプロセスフロー図は、単に説明のための例として提供され、様々な態様のステップを提示された順序で実行しなければならないことを要求または暗示するものではない。当業者によって諒解されるように、上記の態様におけるステップの順序は、いかなる順序でも実行され得る。「その後」、「次いで」、「次」などの言葉は、ステップの順番を限定するものではなく、これらの言葉は単に、読者に本方法の説明を案内するために使用される。さらに、たとえば、冠詞「a」、「an」または「the」の使用による単数形での請求要素へのいかなる言及も、その要素を単数に限定するものとして解釈されるべきではない。
本明細書で開示される態様に関して説明される、様々な例示的な論理ブロック、モジュール、回路、およびアルゴリズムステップは、電子ハードウェア、コンピュータソフトウェア、または両方の組合せとして実装され得る。ハードウェアおよびソフトウェアのこの互換性を明確に示すために、様々な例示的なコンポーネント、ブロック、モジュール、回路、およびステップが、上では全般にそれらの機能に関して説明された。そのような機能がハードウェアとして実現されるか、またはソフトウェアとして実現されるかは、具体的な適用例および全体的なシステムに課される設計制約によって決まる。当業者は、説明された機能を具体的な適用例ごとに様々な方法で実現することができるが、そのような実現の決定は、本発明の範囲からの逸脱を生じるものと解釈されるべきではない。
本明細書で開示される態様に関して説明される様々な例示的な論理、論理ブロック、モジュール、および回路を実装するために使用されるハードウェアは、汎用プロセッサ、デジタル信号プロセッサ(DSP)、特定用途向け集積回路(ASIC)、フィールドプログラマブルゲートアレイ(FPGA)もしくは他のプログラマブル論理デバイス、個別ゲートもしくはトランジスタ論理、個別のハードウェアコンポーネント、または、本明細書で説明する機能を実行するように設計されたそれらの任意の組合せで、実装または実行され得る。汎用プロセッサはマルチプロセッサであり得るが、代替として、プロセッサは任意の従来のプロセッサ、コントローラ、マイクロコントローラ、または状態機械であり得る。プロセッサは、コンピューティングデバイスの組合せ、たとえば、DSPとマルチプロセッサとの組合せ、複数のマルチプロセッサ、DSPコアと連携する1つもしくは複数のマルチプロセッサ、または任意の他のそのような構成としても実装され得る。代替として、いくつかのステップまたは方法は、所与の機能に特有の回路によって実行され得る。
1つまたは複数の例示的な態様では、説明された機能は、ハードウェア、ソフトウェア、ファームウェア、またはそれらの任意の組合せで実装され得る。機能は、ソフトウェアで実装される場合、1つまたは複数の命令またはコードとして、非一時的コンピュータ可読記憶媒体、非一時的コンピュータ可読媒体または非一時的プロセッサ可読媒体に記憶され得る。本明細書で開示される方法またはアルゴリズムのステップは、非一時的コンピュータ可読記憶媒体またはプロセッサ可読記憶媒体上に存在し得るプロセッサ実行可能ソフトウェアモジュール内で具現化され得る。非一時的コンピュータ可読記憶媒体またはプロセッサ可読記憶媒体は、コンピュータまたはプロセッサによってアクセスされ得る、任意の記憶媒体であり得る。限定ではなく例として、そのような非一時的コンピュータ可読媒体またはプロセッサ可読媒体は、RAM、ROM、EEPROM、FLASHメモリ、CD-ROMもしくは他の光ディスク記憶装置、磁気ディスク記憶装置もしくは他の磁気記憶デバイス、または、命令またはデータ構造の形式で所望のプログラムコードを記憶するために使用され得るとともに、コンピュータによってアクセスされ得る任意の他の媒体を含み得る。本明細書で使用される場合、ディスク(disk)およびディスク(disc)は、コンパクトディスク(CD)、レーザーディスク（登録商標）、光ディスク、デジタル多用途ディスク(DVD)、フロッピー（登録商標）ディスク、およびブルーレイディスクを含み、ディスク(disk)は、通常、磁気的にデータを再生するが、ディスク(disc)は、レーザーで光学的にデータを再生する。
上記の組合せも、非一時的コンピュータ可読媒体およびプロセッサ可読媒体の範囲内に含まれる。加えて、方法またはアルゴリズムの動作は、コンピュータプログラム製品に組み込まれ得る、非一時的プロセッサ可読媒体および/またはコンピュータ可読媒体上のコードおよび/または命令の1つまたは任意の組合せまたはセットとして存在し得る。
開示された実施形態の上記の説明は、任意の当業者が本発明を作成または使用することを可能にするために提供される。これらの実施形態への様々な修正が当業者には容易に明らかになり、本明細書で定義された一般原理は、本発明の趣旨および範囲を逸脱することなく他の実施形態に適用され得る。したがって、本発明は、本明細書で示される実施形態に限定されることは意図されず、以下の特許請求の範囲ならびに本明細書で開示される原理および新規の特徴に一致する最大の範囲を与えられるべきである。
102 モバイル受信機デバイス
104 マルチメディアブロードキャストネットワーク
106 ユニキャストネットワーク
108 インターネット
110 サーバ
112 ブロードキャスト送信機
113 モバイルブロードキャスト送信
114 ブロードキャストオペレーションセンター
115 双方向ワイヤレス通信リンク
116 セルラー基地局
118 ネットワークオペレーションセンター
120 サーバ
200 プロトコルスタック
202 物理層
204 データリンク層
206 ネットワーク層
208 トランスポート層
210 アプリケーション層
300 ブロードキャスト通信システム
302 進化したオブジェクト前方誤り訂正コンポーネント
304 進化したオブジェクトシグナリングコンポーネント
306 進化したオブジェクト配信コンポーネント
402 ソースオブジェクト
404 ソースパケット
406 ソースパケット
408 ソースパケット
410 ソースパケット
502 従来技術のFLUTEオブジェクトパケットヘッダ
504 実施形態のFLUTEオブジェクトパケットヘッダ
506 タイムスタンプフィールド
508 FLIDフィールド
510 OSNフィールド
512 バイトオフセット
602 FLUTEオブジェクト
604 HTTPヘッダフィールド
606 利用可能時間フィールド
700 トランスポートオブジェクト
702 ソースオブジェクトフィールド
704 パディングフィールド
706 バイト範囲またはサイズ/長さフィールド
708 シンボル境界
752 バイト範囲フィールド
754 境界
802 現在のFLUTE修復FECペイロードID
804 実施形態の修復FECペイロードID
806 実施形態の修復FECペイロードID
808 実施形態の修復FECペイロードID
852a 追加の実施形態の修復FECペイロードID
852b 追加の実施形態の修復FECペイロードID
858 FECペイロードID
902 修復FLUTEヘッダ
904 修復FECペイロードID
906 FEC符号化オブジェクト
952 修復FECペイロードID
954 FEC符号化オブジェクト
1300 方法
1400 ブロードキャスト通信システム
1402 ソース配信プロトコル
1404 前方誤り訂正(FEC)フレームワーク
1406 ソースALCコンポーネント
1408 修復ALCコンポーネント
1410 集合体
1412 集合体
1414 オブジェクトバンドリングコンポーネント
1416 セッション記述
1420 ブロードキャスト通信システム
1422 ソースデータ
1424 ソースプロトコルコンポーネント
1426 修復プロトコルコンポーネント
1428 ソースパケット作成コンポーネント
1430 LCTコンポーネント
1434 ソースオブジェクト作成コンポーネント
1436 修復ALCコンポーネント
1438 LCTコンポーネント
1440 FEC方式コンポーネント
1500 FECフレームワーク
1502 FEC修復パケット
1504 ソースオブジェクト
1506 ソースオブジェクト
1508 第1のFECオブジェクト
1510 第2のFECオブジェクト
1512 FECトランスポートオブジェクト
1514 FECトランスポートオブジェクト
1516 パディングオクテット
1518 FECオブジェクトサイズ
1520 パディングオクテット
1522 FECオブジェクトサイズ
1540 FECスーパーオブジェクト
1600 モバイルコンピューティングデバイス
1601 プロセッサ
1602 内部メモリ
1603 ディスプレイ
1604 スピーカー
1606 アンテナ
1608 携帯電話送受信機
1610 モバイルマルチメディアブロードキャスト受信機
1612 メニュー選択ボタン
1614 符号化/復号回路
1700 サーバ
1701 CDまたはDVDディスクドライブ
1702 揮発性メモリ
1703 ディスクドライブ
1704 プロセッサ
1705 ネットワークアクセスポート
1706 ネットワーク

Claims (13)

  1. ブロードキャストネットワークを介して情報を通信する方法であって、
    関連するソースオブジェクトの集合体を単一のフローと関連付けるステップと、
    前記フローのフロー識別子を決定するステップであって、前記フロー識別子は、前記単一のフローに関連付けられた関連するソースオブジェクトの前記集合体の中の全てのソースオブジェクトに対して同一である、ステップと、
    前記関連するソースオブジェクトの前記集合体の中のソースオブジェクトごとに、ソースオブジェクトシーケンス番号OSNを決定するステップと、
    前記フローと関連付けられる関連するソースオブジェクトの前記集合体の中の少なくとも1つのソースオブジェクトのデータを含むパケットの送信オブジェクト識別子TOIフィールドに前記フロー識別子と前記OSNを含めるステップと、
    前記フローと関連付けられる関連するソースオブジェクトの前記集合体の中のソースオブジェクトを単一の通信チャンネルを通じて送信するステップと、
    を含む、方法。
  2. 前記パケット中のバイト範囲を使用して前記パケット中のデータを特定するステップをさらに含む、請求項1に記載の方法。
  3. 前記パケット中のソースオブジェクトのデータを特定する前記パケットにバイト範囲を含めるステップをさらに含む、請求項1に記載の方法。
  4. 関連するソースオブジェクトの前記集合体を送信するステップが、関連するソースオブジェクトの複数の集合体を送信するステップを含み、各集合体が複数の異なるフローの1つと関連付けられ、前記複数の異なるフローの各々が固有のフロー識別子を含み、
    前記フローと関連付けられる関連するソースオブジェクトの前記集合体の中の少なくとも1つのソースオブジェクトのデータを含む前記パケットに前記フロー識別子を含めるステップが、前記ソースオブジェクトのデータを含む前記パケットに前記フローの前記固有のフロー識別子を含めるステップを含む、請求項1に記載の方法。
  5. 関連するソースオブジェクトの前記集合体を送信するステップが、前方誤り訂正(FEC)修復データと、修復フロー識別子と、修復オブジェクト識別子とを含む少なくとも1つのパケットを送信するステップを含み、
    修復フローを、前記複数の異なるフローの1つまたは複数と関連付けるステップと、
    前記修復フローの前記修復フロー識別子を決定するステップと、
    前記修復フローに対する修復オブジェクト識別子の集合体を決定するステップと、
    パケットの前記修復フロー識別子と前記修復オブジェクト識別子の組合せに少なくとも一部基づいて、前記関連付けられる複数のフローからの前記ソースオブジェクトのいずれから、前記パケットに含まれる前記FEC修復データが生成されるかを決定するステップと
    をさらに含む、請求項4に記載の方法。
  6. FEC修復データを含む少なくとも1つのパケットを送信するステップが、
    対応するソースオブジェクトのためのデータを含む前記パケットと同じ時間間隔において、FEC修復データを含む少なくとも1つのパケットを送信するステップを含む、請求項5に記載の方法。
  7. 異なるフロー中の2つのソースオブジェクトからの、同じ修復フロー識別子および同じ修復オブジェクト識別子を有するパケットから、かつ、前記2つのソースオブジェクトの統合サイズ以上である前記2つのソースオブジェクトのいずれかに対するデータを含むパケットから、組合せで受信されるデータの量が、前記2つのソースオブジェクトを復号するのに十分であるように、前記同じ修復フロー識別子および前記同じ修復オブジェクト識別子を有する前記パケットに対するFEC修復データを生成するステップをさらに含む、請求項5に記載の方法。
  8. 前記修復フロー識別子の部分が、FEC修復データを含む前記パケットの異なるデータフィールドに含まれる、請求項5に記載の方法。
  9. 修復フロー宣言が、FEC修復データを含む前記パケット中の前記修復オブジェクト識別子と、前記パケット中の前記FEC修復データの生成元であるフローと関連付けられる関連するソースオブジェクトの前記集合体からのソースオブジェクトとの間の関係を、シグナリングするのに適した情報を含むように、前記修復フローのための前記修復フロー宣言を決定するステップをさらに含む、請求項5に記載の方法。
  10. テンプレートを使用して、前記修復フロー宣言を介して前記関係をシグナリングするステップをさらに含む、請求項9に記載の方法。
  11. 前記修復フロー宣言のある部分が、前記修復フローと関連付けられる前記フローと関連付けられる少なくとも1つのソースオブジェクトより前に受信機デバイスに送信される、請求項9に記載の方法。
  12. 関連するソースオブジェクトの集合体を単一のフローと関連付けるための手段と、
    前記フローのフロー識別子を決定するための手段であって、前記フロー識別子は、前記単一のフローに関連付けられた関連するソースオブジェクトの前記集合体の中の全てのソースオブジェクトに対して同一である、手段と、
    前記関連するソースオブジェクトの前記集合体の中のソースオブジェクトごとに、ソースオブジェクトシーケンス番号OSNを決定するための手段と、
    前記フローと関連付けられる関連するソースオブジェクトの前記集合体の中の少なくとも1つのソースオブジェクトのデータを含むパケットの送信オブジェクト識別子TOIフィールドに前記フロー識別子と前記OSNを含めるための手段と、
    前記フローと関連付けられる関連するソースオブジェクトの前記集合体の中のソースオブジェクトを単一の通信チャンネルを通じて送信するための手段と、
    を備える、通信システム。
  13. 通信システム内のコンピューティングデバイスに、ブロードキャストネットワークを介して情報を通信するための動作を実行させるように構成されるプロセッサ実行可能ソフトウェア命令を記憶した非一時的コンピュータ可読記憶媒体であって、前記動作が、
    関連するソースオブジェクトの集合体を単一のフローと関連付けるステップと、
    前記フローのフロー識別子を決定するステップであって、前記フロー識別子は、前記単一のフローに関連付けられた関連するソースオブジェクトの前記集合体の中の全てのソースオブジェクトに対して同一である、ステップと、
    前記関連するソースオブジェクトの前記集合体の中のソースオブジェクトごとに、ソースオブジェクトシーケンス番号OSNを決定するステップと、
    前記フローと関連付けられる関連するソースオブジェクトの前記集合体の中の少なくとも1つのソースオブジェクトのデータを含むパケットの送信オブジェクト識別子TOIフィールドに前記フロー識別子と前記OSNを含めるステップと、
    前記フローと関連付けられる関連するソースオブジェクトの前記集合体の中のソースオブジェクトを単一の通信チャンネルを通じて送信するステップと、
    を含む、非一時的コンピュータ可読記憶媒体。
JP2016507689A 2013-04-12 2014-04-11 ブロードキャスト／マルチキャスト対応ネットワークを通じたオブジェクトのフローの配信のための方法 Active JP6445527B2 (ja)

Applications Claiming Priority (11)

Application Number Priority Date Filing Date Title
US201361811693P 2013-04-12 2013-04-12
US61/811,693 2013-04-12
US201361818912P 2013-05-02 2013-05-02
US61/818,912 2013-05-02
US201361878368P 2013-09-16 2013-09-16
US61/878,368 2013-09-16
US201361912145P 2013-12-05 2013-12-05
US61/912,145 2013-12-05
US14/249,499 US9900166B2 (en) 2013-04-12 2014-04-10 Methods for delivery of flows of objects over broadcast/multicast enabled networks
US14/249,499 2014-04-10
PCT/US2014/033838 WO2014169233A2 (en) 2013-04-12 2014-04-11 Methods for delivery of flows of objects over broadcast/multicast enabled networks

Publications (3)

Publication Number Publication Date
JP2016521494A JP2016521494A (ja) 2016-07-21
JP2016521494A5 JP2016521494A5 (ja) 2017-05-18
JP6445527B2 true JP6445527B2 (ja) 2018-12-26

Family

ID=51686774

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2016507689A Active JP6445527B2 (ja) 2013-04-12 2014-04-11 ブロードキャスト／マルチキャスト対応ネットワークを通じたオブジェクトのフローの配信のための方法

Country Status (7)

Country Link
US (2) US9900166B2 (ja)
EP (1) EP2984809A2 (ja)
JP (1) JP6445527B2 (ja)
KR (1) KR20150140783A (ja)
CN (1) CN105122767B (ja)
BR (1) BR112015025908A2 (ja)
WO (1) WO2014169233A2 (ja)

Families Citing this family (53)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20130058648A (ko) * 2011-11-25 2013-06-04 (주)휴맥스 Mmt 미디어와 dash 미디어와의 연동 방법
US9060252B2 (en) 2012-07-31 2015-06-16 International Business Machines Corporation Rate adaptive transmission of wireless broadcast packets
US9386062B2 (en) * 2012-12-28 2016-07-05 Qualcomm Incorporated Elastic response time to hypertext transfer protocol (HTTP) requests
KR102127685B1 (ko) * 2013-04-17 2020-06-29 삼성전자주식회사 순방향 오류 정정 패킷 송수신 장치 및 방법
KR102148158B1 (ko) * 2013-04-23 2020-08-28 삼성전자주식회사 통신 시스템에서 패킷 송수신 방법 및 장치
US9059847B2 (en) * 2013-04-26 2015-06-16 International Business Machines Corporation Reliable multicast broadcast in wireless networks
US20160212042A1 (en) * 2013-08-19 2016-07-21 Lg Electronics Inc. Broadcast transmitting device, broadcast receiving device, operating method of the broadcast transmitting device, and operating method of the broadcast receiving device
JP2015043484A (ja) * 2013-08-26 2015-03-05 ソニー株式会社 コンテンツ供給装置、コンテンツ供給方法、プログラム、端末装置、およびコンテンツ供給システム
JP2015061307A (ja) * 2013-09-20 2015-03-30 ソニー株式会社 コンテンツ供給装置、コンテンツ供給方法、プログラム、端末装置、およびコンテンツ供給システム
US9729903B2 (en) * 2013-12-31 2017-08-08 Samsung Electronics Co., Ltd. Data transmitting device and method
KR102273757B1 (ko) * 2014-01-03 2021-07-06 엘지전자 주식회사 방송 신호를 송신하는 장치, 방송 신호를 수신하는 장치, 방송 신호를 송신하는 방법 및 방송 신호를 수신하는 방법
JP6466951B2 (ja) * 2014-01-13 2019-02-06 エルジー エレクトロニクス インコーポレイティド 一つ以上のネットワークを介して放送コンテンツを送受信する装置及び方法
KR101737849B1 (ko) * 2014-02-24 2017-05-19 엘지전자 주식회사 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법
KR102208814B1 (ko) 2014-03-28 2021-01-28 삼성전자주식회사 통신 시스템에서 패킷 송수신 방법 및 장치
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
EP3175624A4 (en) 2014-07-31 2018-02-28 LG Electronics Inc. Apparatus and method for transmitting/receiving processes of a broadcast signal
WO2016033056A1 (en) 2014-08-26 2016-03-03 Ctera Networks, Ltd. A method and computing device for allowing synchronized access to cloud
US9635407B2 (en) * 2014-10-16 2017-04-25 Samsung Electronics Co., Ltd. Method and apparatus for bottleneck coordination to achieve QoE multiplexing gains
WO2016093537A1 (ko) 2014-12-10 2016-06-16 엘지전자 주식회사 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법
WO2016105100A1 (ko) 2014-12-22 2016-06-30 엘지전자 주식회사 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법
KR102379530B1 (ko) 2015-01-07 2022-03-29 삼성전자주식회사 통신 시스템에서 미디어 정보를 송수신하는 방법 및 장치
US10129308B2 (en) * 2015-01-08 2018-11-13 Qualcomm Incorporated Session description information for over-the-air broadcast media data
WO2016117939A1 (ko) 2015-01-21 2016-07-28 엘지전자 주식회사 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법
US9819760B2 (en) * 2015-02-03 2017-11-14 Microsoft Technology Licensing, Llc Method and system for accelerated on-premise content delivery
WO2016144142A1 (ko) * 2015-03-12 2016-09-15 엘지전자 주식회사 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법
US10165025B2 (en) 2015-04-03 2018-12-25 Qualcomm Incorporated Techniques for HTTP live streaming over eMBMS
EP3086497B1 (en) * 2015-04-24 2019-03-06 Alcatel Lucent An apparatus and a method for a regenerative network node between a first and a second link portion
US20160323063A1 (en) * 2015-05-01 2016-11-03 Qualcomm Incorporated Bundled Forward Error Correction (FEC) for Multiple Sequenced Flows
CN106330845A (zh) * 2015-07-02 2017-01-11 中兴通讯股份有限公司 一种传输流媒体数据的方法和装置
US10149122B2 (en) 2015-09-14 2018-12-04 Qualcomm Incorporated Techniques for in-band signaling of service description updates in RTP
US11102536B2 (en) 2015-09-18 2021-08-24 Saturn Licensing Llc Transmission apparatus, reception apparatus, and data processing method
US10805273B2 (en) 2016-04-01 2020-10-13 Egnyte, Inc. Systems for improving performance and security in a cloud computing system
US10860821B1 (en) * 2016-04-26 2020-12-08 A9.Com, Inc. Barcode disambiguation
US10623635B2 (en) * 2016-09-23 2020-04-14 Mediatek Inc. System and method for specifying, signaling and using coding-independent code points in processing media contents from multiple media sources
US10397079B2 (en) * 2016-09-27 2019-08-27 Netscout Systems, Inc. Video delivery performance analysis for EMBMS
KR102656013B1 (ko) * 2016-10-28 2024-04-11 삼성전자주식회사 컨텐츠 출력 장치 및 그 제어 방법
EP3545648B1 (en) * 2016-11-23 2024-08-14 Nokia Technologies Oy Delivery of sub-service flows using broadcast, multicast
JP6359074B2 (ja) * 2016-12-01 2018-07-18 株式会社インフォシティ コンテンツ配信システム
WO2018210411A1 (en) 2017-05-16 2018-11-22 Telefonaktiebolaget Lm Ericsson (Publ) Low latency media ingestion system, devices and methods
US10594661B1 (en) * 2017-06-13 2020-03-17 Parallels International Gmbh System and method for recovery of data packets transmitted over an unreliable network
CN109600403B (zh) * 2017-09-30 2021-11-02 北京国双科技有限公司 一种发送信息的方法及装置
KR102464803B1 (ko) * 2017-10-13 2022-11-09 삼성전자주식회사 응용 계층 순방향 오류 정정 방식을 사용하는 멀티미디어 서비스 제공 방법 및 장치
CN109788014A (zh) * 2017-11-14 2019-05-21 阿里巴巴集团控股有限公司 一种消息处理、物联网系统的消息处理方法和装置
US10721287B2 (en) * 2018-03-23 2020-07-21 Verizon Patent And Licensing, Inc. Real-time file repair
JP6490284B2 (ja) * 2018-06-01 2019-03-27 株式会社インフォシティ コンテンツ配信システム
CN108923541A (zh) * 2018-08-31 2018-11-30 国电南瑞科技股份有限公司 基于广域服务总线的主配一体化安全遥控方法
GB201817780D0 (en) * 2018-10-31 2018-12-19 V Nova Int Ltd Methods,apparatuses, computer programs and computer-readable media for processing configuration data
WO2020101639A1 (en) 2018-11-12 2020-05-22 Nokia Technologies Oy Method and apparatus for efficient delivery of source and forward error correction streams in systems supporting mixed unicast multicast transmission
US10949089B2 (en) * 2019-06-17 2021-03-16 Vmware, Inc. Reconfiguring data objects using batch processing of concatenated components
US11196664B2 (en) * 2019-09-16 2021-12-07 Envistacom, Llc Multi-path message distribution and message reassembly for large data flow using forward error correction with high-performance computing (HPC)
US11582125B2 (en) * 2019-10-01 2023-02-14 Qualcomm Incorporated Repair mechanism for adaptive bit rate multicast
TWI747417B (zh) * 2020-08-05 2021-11-21 國立陽明交通大學 經由影音平台的網址而產生音訊字幕檔的方法
US11943125B2 (en) * 2022-01-26 2024-03-26 Dish Network Technologies India Private Limited Discontinuity detection in transport streams

Family Cites Families (27)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050160345A1 (en) * 2003-12-24 2005-07-21 Rod Walsh Apparatus, system, method and computer program product for reliable multicast transport of data packets
US7599294B2 (en) * 2004-02-13 2009-10-06 Nokia Corporation Identification and re-transmission of missing parts
US8296436B2 (en) * 2004-03-22 2012-10-23 Nokia Corporation Conveying parameters for broadcast/multicast sessions via a communication protocol
US8112531B2 (en) 2004-07-14 2012-02-07 Nokia Corporation Grouping of session objects
US7590922B2 (en) * 2004-07-30 2009-09-15 Nokia Corporation Point-to-point repair request mechanism for point-to-multipoint transmission systems
WO2006058544A1 (en) 2004-11-30 2006-06-08 Telefonaktiebolaget Lm Ericsson (Publ) Method for delivering multimedia files
BRPI0608470A2 (pt) 2005-03-24 2010-01-05 Nokia Corp método para notificar o dispositivo receptor sobre uma sessão de transmissão futura, dispositivo de transmissão que suporta uma notificação do dispositivo receptor sobre uma sessão de transmissão futura, rede de comunicação, sistema de comunicação, produto de programa, e, aparelho de recepção
US8351363B2 (en) * 2005-04-08 2013-01-08 Qualcomm Incorporated Method and apparatus for enhanced file distribution in multicast or broadcast
EP1929737B1 (en) 2005-09-27 2020-11-04 BlackBerry Limited Progressive delivery of multimedia objects
JP5550834B2 (ja) * 2006-02-13 2014-07-16 デジタル ファウンテン， インコーポレイテッド 可変ｆｅｃオーバヘッド及び保護期間を利用したストリーミング及びバッファリング
JP4653011B2 (ja) * 2006-05-01 2011-03-16 パナソニック株式会社 中継装置及び中継方法
US9432433B2 (en) * 2006-06-09 2016-08-30 Qualcomm Incorporated Enhanced block-request streaming system using signaling or block creation
US20080031243A1 (en) * 2006-08-01 2008-02-07 Gidon Gershinsky Migration of Message Topics over Multicast Streams and Groups
WO2008084441A1 (en) * 2007-01-10 2008-07-17 Nokia Corporation System and method for implementing mbms handover during download delivery
CA2696721C (en) * 2007-08-24 2012-07-24 Lg Electronics Inc. Digital broadcasting system and method of processing data in digital broadcasting system
US7764533B2 (en) * 2007-09-18 2010-07-27 International Business Machines Corporation Multi-level memory cell utilizing measurement time delay as the characteristic parameter for level definition
WO2009038442A2 (en) * 2007-09-21 2009-03-26 Lg Electronics Inc. Digital broadcasting receiver and method for controlling the same
KR101572875B1 (ko) * 2007-09-21 2015-11-30 엘지전자 주식회사 디지털 방송 시스템 및 데이터 처리 방법
US7813310B2 (en) * 2007-09-21 2010-10-12 Lg Electronics, Inc. Digital broadcasting receiver and method for controlling the same
JP5086980B2 (ja) * 2008-11-28 2012-11-28 日本放送協会 一方向伝送路に用いる送信端末、受信端末及び伝送システム
JP4939520B2 (ja) * 2008-12-10 2012-05-30 日本放送協会 一方向伝送路に用いる送信端末、受信端末及び伝送システム
JP5541488B2 (ja) * 2009-02-09 2014-07-09 ソニー株式会社 コンテンツ受信装置および方法
US8914471B2 (en) * 2010-05-28 2014-12-16 Qualcomm Incorporated File delivery over a broadcast network using file system abstraction, broadcast schedule messages and selective reception
US9485108B2 (en) * 2011-03-14 2016-11-01 Qualcomm Incorporated System and apparatus for using multichannel file delivery over unidirectional transport (“FLUTE”) protocol for delivering different classes of files in a broadcast network
WO2013107502A1 (en) * 2012-01-17 2013-07-25 Telefonaktiebolaget L M Ericsson (Publ) Method for sending respectively receiving a media stream
US9264481B2 (en) 2012-03-30 2016-02-16 Qualcomm Incorporated Responding to hypertext transfer protocol (HTTP) requests
KR101961736B1 (ko) * 2012-04-23 2019-03-25 삼성전자 주식회사 통신 시스템에서 패킷 송수신 장치 및 방법

Also Published As

Publication number Publication date
US20140307734A1 (en) 2014-10-16
KR20150140783A (ko) 2015-12-16
WO2014169233A3 (en) 2015-01-22
US9900166B2 (en) 2018-02-20
EP2984809A2 (en) 2016-02-17
CN105122767A (zh) 2015-12-02
US20180123810A1 (en) 2018-05-03
JP2016521494A (ja) 2016-07-21
WO2014169233A2 (en) 2014-10-16
BR112015025908A2 (pt) 2017-07-25
CN105122767B (zh) 2019-01-29

Similar Documents

Publication Publication Date Title
JP6445527B2 (ja) ブロードキャスト／マルチキャスト対応ネットワークを通じたオブジェクトのフローの配信のための方法
US11805286B2 (en) Apparatus and method for transmitting/receiving processes of a broadcast signal
KR102127733B1 (ko) 멀티미디어 시스템에서 미디어 컨텐츠 전송 방법 및 장치
US9294226B2 (en) Universal object delivery and template-based file delivery
KR102340240B1 (ko) 지상파 방송망과 인터넷 프로토콜망 연동 기반의 하이브리드 방송 시스템에서 방송 서비스의 송수신 방법 및 장치
EP3257216B1 (en) Method of handling packet losses in transmissions based on dash standard and flute protocol
KR102381335B1 (ko) 모바일 사용자 장치들에 컨텐츠를 전송하는 방법
US20190191190A1 (en) Reception apparatus, reception method, transmission apparatus, and transmission method
TW202215853A (zh) 用於適應性位元率多播的修復機制
Alliance File and Stream Distribution for Mobile Broadcast Services

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20170327

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20170327

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20180308

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20180319

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20180618

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20180723

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20181022

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

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20181129

R150 Certificate of patent or registration of utility model

Ref document number: 6445527

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250