JP5635626B2 - メディア・ストリームの同期のための方法、システム及び装置 - Google Patents

Description

本発明はメディア・ストリームの同期に関し、特に、必ずしも必要ではないが、第１及び第２のメディア・ストリームを同期させるための方法及びシステム、このようなシステムにおいて使用するバッファ、同期サーバ及び端末、並びにこのような方法を使用するコンピュータ・プログラム製品に関するものである。

従来技術

ボイス・オーバーＩＰ（ＶｏＩＰ）及びインターネット・プロトコル・テレビジョン（ＩＰＴＶ）のような新規なマルチメディア技術は、全ての範囲の新規なマルチメディア・サービスを開拓する。これらサービスの１つのタイプでは、ユーザ・グループが、同一のテレビ・チャンネルを別個に閲覧し、テキスト、オーディオ及び／又はビデオを用いて相互に通信することを可能にする。これらサービス別のタイプでは、ブロードキャストされたテレビ・クイズといった双方向テレビ経験を提供する。ここでは、自宅にいる視聴者がブロードキャストされた質問に対する答えを入力することができ、その番組に参加することができる。この種のサービスでは、端末の出力信号が同時にグループ内の全ユーザに伝送されることが必要である。換言すれば、グループ内のディスプレイ出力又は再生デバイス、例えば、異なる宛先に対応する、テレビ、ＰＤＡ、モバイル・デバイス、ＰＣ又はこれらの組み合わせは、同期して然るべきである。

ＩＰＴＶシステムにおいては、テレビ・チャンネル信号は、通例、運用業者の高帯域幅ＩＰネットワークを通じた１又はそれ以上のパケット化されたストリームとして、ヘッド・エンド、エッジ・ルータ及びアクセス・ノードといったネットワーク・ノードを介して、このようなサービス加入者端末に伝送される。ストリーム伝送の間、パケットは、例えば伝送遅延、ネットワーク・ルートの相違、及びコーディング並びにデコーディングの相違といった、未知のネットワーク遅延にさらされる傾向にある。結果として、第１端末（第１の宛先）で受信されるオーディオ及びビデオ・ストリームのパケットと別の第２端末（第２の宛先）で受信されるそれらパケットとの時間的な関係が阻害される。

端末に対してＩＰＴＶコンテンツをストリームするために、通常は、リアル・タイム・トランスポート・プロトコル（ＲＴＰ;Real-time Transport Protocol）が用いられる。ＲＴＰは、シーケンス・ナンバリング及びタイム・スタンピングを提供する。ＲＴＰを用いて、同一のエンド端末で終端する付随したストリーム間（内部ストリーム同期）、又は異なる端末で終端する付随したストリーム間（グループ同期又は宛先間同期）における１つのストリーム内の時間的関係（ストリーム間同期）はリストアすることができる。本発明は、また、例えばＵＤＰにおけるＭＰＥＧトランスポート・ストリームを用いて、又は、トランスポート・プロトコルとしてＨＴＴＰを用い、他のメディア・トランスポート・プロトコルに適用することもできる。F.Boronatらによる比較研究の論文"Multimedia group and inter-stream synchronization techniques"（マルチメディア・グループ及びストリーム間の同期技術）（ＥｌｓｅｖｉｅｒＩｎｆｏｒｍａｔｉｏｎＳｙｓｔｅｍｓ３４（２００９年）ｐｐ．１０８―１３１）には、公知の宛先間同期技術についての包括的概要が提供される。

参照される宛先間同期技術は、３つの主要なカテゴリに再分割することができる。「同期マエスト方式」（ＳＭＳ;Synchronization Maestro Scheme）では、中心同期マスタが、グループ内の全ての端末からタイミング情報を収集し、制御パケットを端末に配布することにより出力タイミングを調整する。「マスタ−スレーブ受信機方式」（ＭＳＲＳ;Master-Slave Receiver Scheme）では、受信機（端末）は、マスタ受信機及びスレーブ受信機に分類される。マスタ受信機は、その出力タイミングをスレーブ受信機にマルチキャストし、それに応じてパケットについてそれらの出力タイミングを調整する。「分散制御方式」（ＤＣＳ;Distributed Control Scheme）では、各端末（受信機）は、グループ内の他の全ての端末に対して全タイミング情報をマルチキャストし、端末は、適切な出力タイミングを算出するように構成される。これらの方式は、同期がメディア・ストリームの供給元又は受信先のいずれかで行われることを共通して有する。

国際公開ＷＯ２００９／０５３０７２は、更なるネットワーク制御宛先間同期方式について記載しており、ネットワーク・ノード、例えばメディア経路内の境界ネットワーク・ノードは、それに接続するユーザ機器の宛先間同期を提供する。この方法は、特に、大規模な配備及びサービスに適しており、ストリームの宛先を運用業者ネットワークに接続するアクセス・ラインの違いから生じるストリームの伝播時間における、例えば標準的なジッタ・オーダーのわずかな差を許容する。同期化は、指定されたネットワーク・ノード内の同期エンティティ（例えば同期クライアント）を実装することによって実現される。そこでは、その同期エンティティは、パケットの到達時間に関する情報を測定し、同期ステータス情報においてこれら測定された時間を同期サーバにレポートし、同期設定指示を同期サーバから受信してその可変遅延バッファに指示するように構成される。

ネットワーク内に存在する同期化方式に関連した１つの課題は、同期ネットワーク・ノードと受信機間のストリームがコンテンツ準備及び／又はコンテンツ再生成の目的（例えば、高解像度（ＨＤ）から標準解像度（ＳＤ）、ＭＰＥＧ―３からＭＰＥＧ―２へ、及び／又は高いビット・レートから低いビット・レートへの変換のため）のトランスコーダによって修正されるという状況を取り扱うことへの困難性に対処することができないか、又は、少なくともその困難性を有するということである。これらの修正は、同期ネットワーク・ノードで補償され得ない実質的な遅延を導くこともある。更に、異なるコーディング遅延及びジッタ・バッファ設定の結果となるＵＥの違いによって、更なる遅延の原因となることもあり、この遅延は、遅延の増加や、特定のサービスを利用するときにもはや耐えることのできないＵＥ間の遅延差の原因となることもある。

別の課題は、ネットワーク内に存在する同期化方式がネットワーク・ノードを必要とするという事実に関し、メディア・ユニット到達時間を測定するように構成される。このような機能性は、ディープ・パケット・インスペクション(deep packet inspection)を必要とする。ここでは、異なるメディア・パケットのヘッダ情報、例えばＲＴＰヘッダ又はＭＰＥＧ ＴＳヘッダを、パケット到達時間についてレポート可能にするようにフィルタリングされなければならない。特定の状況下で同期ネットワーク・ノードが多くの異なるメディア・トランスポート・プロトコル（専用のトランスポート・プロトコルを含む）を処理することができるのが好ましいことを考えれば、主に機能を導出するのに構成される、ネットワーク・ノードのこのような機能性の実装は複雑であり、また高価なものになり得る。

要するに、すべての公知の宛先間同期方式のそれぞれは、限定されるものではないが、バッファリング・リソース（例えば、各エンド端末が大きい追加バッファを必要とするとき）の非効率的な使用、チャネル変更の間の遅延のザッピング（再同期化）、不正確な遅延測定といったそれら自身の不利な点を有する・
したがって、この技術分野においては、１又はそれ以上の端末のメディア再生について効果的なネットワーク制御可能同期を提供することができる、改良された方法、システム及びデバイスの必要がある。

発明の目的は、公知のサービス提供システムの欠点の少なくとも１つを減らすか又は除去することである。

第１の態様において、本発明は第１のメディア・ストリーム及び第２のメディア・ストリームを同期する方法に関し、第１メディア・ストリーム及び第２メディア・ストリームがネットワーク内の少なくとも１つのメディア供給元によって第１のメディア経路及び第２のメディア経路を通じて１又はそれ以上の端末に伝送される。本方法は、第１メディア経路及び第２メディア経路における第１の場所に位置する測定モジュールを用いて、第１メディア・ストリーム及び第２メディア・ストリーム内のメディア・パケットの到達時間に関連付けられるタイミング情報を測定するステップ、ネットワークにおいて、当該タイミング情報に基づいて少なくとも１つのバッファについてのバッファ指示を生成するステップであって、バッファが第１メディア経路及び第２メディア経路のうち少なくとも１つにおける第２の場所に位置するステップ、１又はそれ以上の端末におけるメディア・パケットの到達時間が実質的に同期されるように、メディア経路を通じて１又はそれ以上の端末に伝送される１又はそれ以上のメディア・パケットを遅延させるステップを含む。

一実施形態においては、第１メディア経路をメディア供給元と第１の端末との間に設け、第２メディア経路をメディア供給元と第２の端末との間に設けることができる。このような構成は、つまり、宛先間同期について方式(scheme)を提供する。

他の実施形態においては、測定モジュールが、１又はそれ以上の端末に位置するか、１若しくはそれ以上の端末をネットワークに接続する１若しくはそれ以上のアクセス・ラインに沿った位置に配置することができ、並びに／又はネットワーク内、好ましくは境界ネットワーク・ノード及び／若しくはアクセス・ネットワーク・ノードに位置することができる。

更なる実施形態において、バッファは、ホーム・ゲートウェイに、又はホーム・ロケーションにおける互換性がある機能において位置することができる。ホーム・ゲートウェイの後方に存在する端末が個々に追加のバッファリング能力を有する必要はないものの、それぞれが時間情報を測定するための測定モジュールをなおも備えることができる結果、個々の遅延をなおも決定することができるということが利点である。

このことは、例えば（トランスコーディング、ミクシング、スケーラブル・ビデオコーデック関連動作等といった）ホーム・ゲートウェイでのストリーム適合により、異なる遅延を経験している、ホーム・ゲートウェイの後方にある異なる端末が存在するかに特に関係する。

他の実施形態においては、測定モジュールは、ホーム・ゲートウェイに位置することができ、及びバッファはネットワーク内の更なるノードに位置することができる。このことは、バッファの後方の端末がもはや測定モジュールと共に構成する必要がないという利点がある。また、このホーム・ゲートウェイは追加のバッファリング容量を有する必要はない。何故なら、これは、ネットワークの更なるノードにより解決されるからである。最後に、ネットワーク・アドレスの変換問題のために、エンド端末は、元のマルチキャスト・ストリームを直接受信できなくてもよく、それ故、最も理想的な測定位置を提供することができない。

更なる別の実施形態では、測定モジュールは、ホーム・ゲートウェイに位置するが、バッファは端末に位置することができる。このことは、ホーム・ゲートウェイ及び御端末の適合性を必要とするだけであるが、ネットワークの更なるノードの適合性を必要としないために、有利である。

一実施形態において、ホーム・ゲートウェイは、本発明によるネットワーク・ノードとして振る舞うか、又は本発明による端末として振る舞う。
更なる実施形態において、バッファ指示は、同期サーバ、好ましくはメディア同期アプリケーション・サーバによって生成することができ、そして、測定モジュール及びバッファは、それぞれ同期測定クライアント及び同期バッファリング・クライアントとして構成することができる。本方法は、同期測定クライアントからタイミング情報を受信するステップ、及びバッファ指示を同期バッファリング・クライアントに伝送するステップを更に含むことができる。

更なる別の実施形態において、バッファ指示は、１若しくはそれ以上の同期設定指示レポート、好ましくはＲＴＣＰ同期設定指示レポートにより同期バッファリング・クライアントに送信することができ、及び／又はタイミング情報が１若しくはそれ以上の同期ステータス情報レポートにより同期サーバに送信することができる。

一実施形態において、同期ステータス情報レポートは、同期バッファリング・クライアントを介して同期サーバに送信することができる。
変形形態において、同期バッファリング・クライアントは、１つの端末から同期サーバに送信される同期ステータス情報レポートを修正するように構成することができ、及び／又は同期バッファリング・クライアントは、同期設定指示レポートを端末に転送するように構成することができる。

他の変形形態において、第１メディア経路は第１メディア供給元と１つの端末との間に設けることができ、第２メディア経路は第１メディア供給元又は更なる第２のメディア供給元とその端末との間に設けることができる。

更なる別の変形形態において、第１測定モジュールがネットワーク・ノード、好ましくは境界ネットワーク・ノード及び／又はアクセス・ネットワーク・ノードに位置することができ、バッファが１又はそれ以上の端末に位置するか、１又はそれ以上の端末をネットワークに接続する１又はそれ以上のアクセス・ラインに沿った位置に配置することができる。

更なる変形形態において、１又はそれ以上の端末のうち少なくとも１つが、メディア・ストリームにおけるメディア・パケットの到達時間の変動を測定し、この到達時間に基づいて変動がバッファリング・ポイントから生じた遅延に関係するかについて判定するように構成することができる。

更なる別の変形形態において、バッファが可変遅延バッファを含み、当該可変遅延バッファがネットワークから受信した遅延指示に基づいてメディア・ストリームを遅延させるように構成することができる。

一実施形態において、この遅延は０．５秒と１０秒との間、好ましくは１秒と５秒との間で選択されることができる。
別の実施形態において、このバッファ・ポイントが当該バッファに接続される２又はそれ以上の端末の間で共有することができる。

別の態様において、本発明は、第１のメディア・ストリーム及び第２のメディア・ストリームを同期するシステムに関することができ、当該システムは、第１メディア・ストリーム及び第２メディア・ストリームを第１のメディア経路及び第２のメディア経路を通じて１又はそれ以上の端末に伝送する少なくとも１つのメディア供給元、少なくとも１つの測定モジュールが受信する第１メディア・ストリーム及び第２メディア・ストリーム内のメディア・パケットに関連付けられるタイミング情報を測定する当該少なくとも１つの測定モジュールであって、第１メディア経路及び第２メディア経路における第１の場所に位置する測定モジュール、メディア経路を通じて１又はそれ以上の端末に伝送されるメディア・パケットを遅延指示に基づいて遅延させるように構成される少なくとも１つのバッファであって、当該バッファが第１メディア経路又は第２メディア経路のうち少なくとも１つにおける第２の場所に位置するバッファ、１又はそれ以上の端末におけるメディア・パケットの到達時間が実質的に同期されるように、タイミング情報に基づいて少なくとも１つのバッファについてのバッファ指示を生成する同期サーバを備える。

更なる態様において、本発明は、バッファ・モジュールに関することができ、好ましくは同期バッファリング・クライアントであり、メディア経路を通じて端末に伝送されるメディアを、バッファ指示に基づいて遅延させるように構成され、当該バッファ・モジュールが、可変遅延バッファ、バッファ指示を受信する受信機であって、当該バッファ指示が可変遅延にメディア・ストリームを遅延させる情報を所定の遅延期間にわたり提供する受信機、１又はそれ以上の遅延したメディア・ストリームを１又はそれ以上の端末に伝送する送信機、任意に、ポインタ情報を含むバッファ・リストであって、当該ポインタ情報がバッファ・モジュールに２又はそれ以上の端末間で可変遅延バッファにおけるメディア・パケットを共有させる、バッファ・リストを備える。

さらに他の態様において、本発明は同期サーバに関することができ、１又はそれ以上のメディア・ストリーム内のメディア・パケットの到達時間に関連付けられたタイミング情報を受信する受信機、バッファ指示を生成するように構成されるプロセッサであって、当該バッファ指示がタイミング情報に基づいて算出される遅延情報を含むプロセッサ、バッファ指示を少なくとも１つのバッファに伝送するための送信機を備える。

別の態様において、本発明はメディア再生のための端末に関することができ、端末が受信するメディア・パケットの到達時間に関連付けられたタイミング情報を測定するための測定モジュール、タイミング情報をネットワーク内の同期サーバに伝送するための送信機、任意に、メディア・ストリーム内のメディア・パケットの到達時間の変動を測定し、当該測定に基づいて、変動がバッファリング・ポイントから生じた遅延に関係するかについて判定するように構成される測定ユニットを備える。

本発明は、また、ソフトウェア・コード部を含むコンピュータ・プログラム製品に関することができ、コンピュータ上でランするときに、上述の方法のステップのいずれかにより本方法を実行するように構成される。

本発明は、更に、添付の図面を参照して説明される。図面は本発明による実施形態を模式的に示している。尚、本発明がこれら特定の実施形態にいかなる形でも限定されないことが理解されよう。

図１は、従来型のコンテンツ配信システムの一部を示す概略図を示す。 図２は、本発明の一実施形態によるコンテンツ配信システムの少なくとも一部の概略図を示す。 図３は、本発明の更なる別の実施形態によるコンテンツ配信システムの少なくとも一部の概略図を示す。 図４は、本発明の一実施形態によるシグナリング・フローを示す。 図５は、本発明の他の実施形態によるコンテンツ配信システムの少なくとも一部の概略図を示す。 図６は、本発明の他の実施形態によるシグナリング・フロー図を示す。 図７は、本発明の一実施形態による同期情報レポートを示す。 図８は、本発明の一実施形態によるバッファリング同期クライアントの概略図を示す。 図９は、本発明の一実施形態による同期方式を用いたチャネル変更の処理についての概略図を示す。 図１０は、本発明の更なる他の実施形態によるコンテンツ配信システムの少なくとも一部の概略図を示す。 図１１は、更なる変形形態によるコンテンツ配信システムの少なくとも一部の概略図を示す。 図１２は、更なる他の変形形態によるコンテンツ配信システムの少なくとも一部概略図を示す。

図１は、従来型のメディア配信システム１００について示しており、当該システムは、エッジ（アクセス）ノード１１２（例えば、ｘＤＳＬシステムのＤＳＬＡＭ又はＤＯＣＳＩＳ／ケーブルシステムのＣＭＴＳ）を介してメディア配信ネットワーク１１４に接続されるＵＥ１０２―１１０を備えている。メディア供給元１１１は、少なくとも一つのメディア・ストリーム１１３をこのエッジ・ノードに伝送する。エッジ・ノードと端末と間のルートが単純アクセス構成における単一のネットワークセグメント、即ちアクセス・リンクを備えるに過ぎないので、ホーム・ネットワーク内のユーザ位置においてエッジ・ノードと端末の間にそれほど多くの遅延は存在しない。したがって、エッジ・ノードと異なる端末との間に遅延が生じていたときは、その遅延は、程度の差はあるものの同一であり、その結果、エッジ・ノードに接続される異なるＵＥを仕様したメディア再生は、程度の差はあるものの同期されている。

しかしながら、異なるマルチメディア機器の使用は、その結果、エッジ・ノードとこれに接続される異なるＵＥとの間の異なる遅延が存在することがあるという状況になる場合がある。図１はエッジ・ノード及び３つの居住環境（住宅）１１６―１２０を示す。ここでは、そのエッジ・ノードは、メディア・ストリーム１２２、例えばＭＰＥＧ４メディア・ストリームを異なるＵＥに配信する。ＵＥ３のユーザは、配信されたメディア・ストリームを直接閲覧するために、ＵＥ１０２を使用することができ、それ故、更なる遅延は居住環境１１６には存在しない。ＵＥ１のユーザは配信されたメディア・ストリームを閲覧するためにそのデバイスを使用せず、第２のＵＥ２、例えばＭＰＥＧ―２メディア・プレーヤをＵＥ１に接続している。ＵＥ１はＵＥ２にメディア・ストリームを配信する。トランスポート・ストリームを転送する前に、ＵＥ１は、最初にＭＰＥＧ―４メディア・ストリームをＭＰＥＧ―２メディア・ストリーム１２４にコード変換する。同様に、ＵＥ４のユーザは、メディア・ストリームを閲覧するために、モバイル・デバイス１１０の形態の更なるＵＥ５を有する。モバイル・デバイスは、ワイヤレスでＵＥ５に接続され、ＵＥ５は、ＭＰＥＧ―４メディア・ストリームをモバイル・デバイスでの使用に適したメディア・フォーマットにコード変換する。したがって、アクセス・リンクのトランスコーダの使用は、以下を含む重要な遅延を導くこともある。即ち、ジッタ・バッファリングに関する、追加のパケット化及びデパケット化の処理に対する遅延、並びに追加のトランスポート及びトランスコード（コード変換）の遅延である。これらの追加の遅延（特に後者）は重要なものであり、これにより、様々なＵＥの再生について許容できない差を導出する。

これらの差は、公知のネットワーク・ベースの同期スキームを用いて補償することができない。ここでは、アクセス・ノードにおいて実装された同期クライアント（ＳＣ）１２６が同期サーバ１０１と同期情報を交換する。このような方式では、ＳＣ１２６は、メディア・パケット到達時間を測定し、同期ステータス情報を生成し、及びメディア・ストリームの再生を遅延させるための機能を有する。

同期サーバは、ＳＣ１２６から、及び他のアクセス／エッジ・ノードに含まれる他のＳＣから（図１には図示せず）、同期ステータス情報を収集し、遅延情報を算出して、同期設定情報１３４を送信することができる。同期設定情報１３４は、宛先間同期方式に関わる２又はそれ以上のアクセス／エッジ・ノードに接続されるＵＥにおけるメディア再生が実質的に同期されるように、可変遅延バッファを設定するための情報を使用する。大規模な配備及びネットワーク制御に適しているにもかかわらず、このような同期方式は、アクセス・ラインで生成する遅延を補償することができない。何故ならば、異なるエッジ・ノードに到達するメディア・ストリームの到達時間の差だけがこの方式で考慮されるからである。これらノードを超えて蓄積する遅延のいかなる相違も、メディア・ストリームがそれぞれのＵＥへの異なる経路上で継続するときには、もはや考慮されない。アクセス・ラインという用語は、ＳＣ、例えばエッジ・ノードを含むネットワーク・ノード及びＵＥの間の全ての接続及び要素を広義に意味する用語として用いる。これは、ホーム・ネットワーク部分、又はＵＥに到達する前に他のネットワークにリダイレクトされているメディア・ストリームの場合には他のネットワーク部分もまた含むこともできる。

したがって、この技術において、宛先間方式の改良を含む同期方式の改良の必要がある。この宛先間同期は、改良された同期パフォーマンスを提供して、そして、大規模アプリケーションでも計測可能な同期方式を提供する。

図２は、本発明の一実施形態によるコンテンツ配信システム２００について少なくとも一部分を示している。本システムは、コンテンツを、１以上のネットワーク・ノード２０４，２０６を介してユーザ機器（ＵＥ）２０８―２１２に配信するための少なくとも一つのメディア供給元２０２を含む。ＵＥは、アクセス・ノード、即ちネットワークのエッジにあるネットワーク・ノードに、アクセス・ライン２１４―２１８を介して接続される。通例、ネットワークはパケット交換ネットワークに関することができる。ここでは、コンテンツは、１以上のメディア・ストリーム２２０，２２２、例えばビデオ・オン・デマンド・ストリーム、又は（ライブでの）マルチキャスト・テレビジョン放送において、ＵＥに送信される。ネットワーク・ノードは、アクセス・ノード、（例えばデジタル加入者ライン・アクセス・マルチプレクサ（ＤＳＬＡＭ）、ケーブル・モデム終端システム（ＣＭＴＳ））光アクセス・ノード又はエッジ・ルータ若しくはヘッド・エンドに関することができる。更に、ＵＥ（端末とも呼ばれる）は、メディア・ストリームを処理する能力を有するいかなるデバイス、例えば、メディア再生デバイス、又は１つに接続されたデバイス（例えばセット・トップ・ボックス）に関することができる。このようなデバイスは、携帯電話、テレビジョン受像機、ＩＰ電話、ゲーム・コンソール、スマート・メータ・デバイス等を含むことができる。再生という用語は、ストリーム内のコンテンツ（の部分）をユーザ又は更なるデバイスに表示又は呈示するものとして理解することができる。

ＵＥとエッジ・ノードのアクセス・ラインは、中間要素（図示せず）、例えば１又はそれ以上のトランスコーダ及び／又はミキサを、図１にて図示したのと類似の方法で含むことができる。図１を参照して説明するように、これら中間要素は、ＵＥに接続された各アクセス・ラインにおける異なる遅延を生じさせることになり、その結果、同期した又は少なくとも実質的に同期したＵＥの再生は可能でない。したがって、このような望ましくない遅延の補償を可能にするために、ＵＥは測定ユニット、例えば同期測定クライアント（ＭＳＣ）２４６―２５０を備えることができ、メディア・パケット到達時間情報を判断するように構成される。このメディア・パケット到達時間情報は、ＭＳＣによって使用され、同期ステータス情報２２４―２２８を生成する。同期ステータス情報２２４―２２８は、ネットワーク内の同期サーバ２３０（以下、メディア同期アプリケーション・サーバ（ＭＳＡＳ）と称する。）に送信される。

したがって、このＭＳＣによって、メディア・パケットの到達時間情報を測定するための測定ポイントとしてＵＥにサービス提供させ、同期ステータス情報のこの情報をネットワークにレポートさせる。ＭＳＡＳは、ネットワーク内のバッファリング・ポイントについて遅延情報を算出するために、同期グループに所属している全てのＵＥの同期ステータス情報を使用する。このバッファリング・ポイントは、同期を必要とするメディア・ストリームのメディア経路に位置する。ＭＳＡＳは、ＵＥのメディア再生を実質的に同期するために、遅延情報をバッファリング・ポイントに提供することができる。

一実施形態において、このようなバッファリング・ポイントは、ネットワーク・ノード、例えばアクセス・ノード等のバッファリング同期クライアント（ＢＳＣ）として実装することができる。同期化を達成するために、このＢＳＣは可変遅延バッファ２３２、２３４に関連付けられる。可変遅延バッファは、ＭＳＡＳによってネットワーク・ノードに送信される同期設定情報２３６、２３８によって制御することができる。ＢＳＣに関連付けられるこのバッファは、以降においてＢＳＣバッファと称される。ＢＳＣバッファは、例えば概して０．５秒と５秒間の範囲の比較的大きい遅延を処理するように構成される。更には、ＢＳＣバッファは、それがＭＳＡＳからの同期設定情報を通じて遅延指示を受信し、これら指示に従ってその遅延設定を適合するという意味では、制御されるネットワークである。

ＵＥは、更に、通例は適応ジッタ・バッファの形態のジッタ・バッファ２４０、２４２、２４４を含むことができ、このジッタ・バッファは、通例２０ミリ秒と５０ミリ秒と間の範囲、最大１００ミリ秒と２００ミリ秒との間で、小さい遅延変動を補償することができる。通例は、補償される最大ジッタは、メディア・ストリームの再生を開始する前に導かれるバッファリング遅延（サイズ）に等しい。このような適応ジッタ・バッファは、メディア・ストリームの変動(fluctuation)（即ち、メディア・パケット到達時間の統計的な差）を測定するように構成され、バッファ長（サイズ）を動的に適応させることでこれら変動を補償する。このことは、ＢＳＣバッファに関連付けられたバッファと対照的であり、ＢＳＣバッファは、ＭＳＡＳからその遅延設定を受信する。

公知のネットワーク制御同期方式とは対照的に、本発明による同期方式は別個の測定ポイント（例えばＭＳＣ）、及び別個のバッファリング・ポイント（例えばＢＳＣ）を使用する。ここでは、測定ポイント及びバッファリング・ポイントはメディアの宛先（例えばＵＥ）とメディア供給元との間の媒体経路上の異なる位置に配置される。ＭＳＣは、アクセス・ラインのどこか、又はＵＥにさえ位置することができるため、同期方式はアクセス・ラインの遅延の補償を考慮に入れる。一実施形態において、ＭＳＣはＵＥに位置することができ、ＢＳＣはアクセス・ノードに位置することができる。更なる実施形態において、ＭＳＣは、ローカル・ネットワーク又はホーム・ネットワークに関連付けられるノードに位置することができる。別の更なる実施形態において、ＭＳＣはネットワーク内、例えばアクセス・ノードに位置することができ、ＢＳＣはアクセス・ラインに、又はＵＥにさえ位置することができる。

したがって、本発明は、同期化を提供するための機能が別々の測定ポイント及びバッファリング・ポイントによって提供されるという洞察に依存するものである。したがって、公知の宛先間同期方式とは対照的であり、公知の宛先間同期方式では同期化のために必要となる機能（即ち、測定及びバッファリング）は、単一の論理エンティティにおいて共に実装されてきた。これらの機能性を分離することは、満たされるべき多くの技術的課題を露呈する。上記実施形態の利点及びこれらに関連する利点について、以下に図２―１２を参照することよって、更に詳細に説明する。詳細を説明するに際し、これらを解決する解決策に対する明白な洞察と同様に、技術的な課題についても明記する。

同期化は、メディア・ストリーム、例えばＲＴＰ又はＭＰＥＧパケット等の基本メディア・ユニット内の、又はこれに関連付けられた時間情報に基づく。ＵＥのＭＳＣに到達する各パケットは、ＲＴＰタイムスタンプ及びＮＴＰタイムスタンプに関連付けることができる。ＲＴＰタイムスタンプは、ＲＴＰデータ・パケットにおける第１オクテットについてサンプリングする瞬間を反映する。このタイムスタンプの初期値は、ランダム値である。このＲＴＰタイムスタンプは、サンプリング期間を計数するので、第２のＲＴＰパケットが第１のＲＴＰパケットの後に１６０のサンプルを開始する場合には、第２のＲＴＰタイムスタンプは第１のものより１６０高くなる。

これに対し、ＮＴＰタイムスタンプは、絶対(absolute)「ウォール・クロック」時間である。ＮＴＰは、ＩＥＴＦ ＲＦＣ １３０５において規定されるように、１９００年１月１日から開示される６４ビット・カウンタである。このＮＴＰにより用いられる６４ビットのタイムスタンプは、３２ビットの秒(seconds)部分及び３２ビットの小数秒(fractional second)部品を備える。それは、ＲＴＰタイムスタンプによって特定される第１オクテットがＵＥで特定の時点を通過する絶対時間を表す。この特定時点は、例えば、ＵＥの再生時点とすることができ、ここでは、ＮＴＰタイムスタンプは、指定されたオクテットがユーザに再生される時を示す。あるいは、それは、ＭＳＣが指定されたオクテットを最初に受信した、進入（入力）の時点としてもよい。

本発明により測定及びバッファリング・ポジションを分離するときに応じられる１つの技術的な課題は、同期動作を有するネットワーク・ジッタの存在及び潜在的干渉に関する。ジッタのためにランダムなオフセットがＲＴＰパケット間に存在するにもかかわらず、ＵＥは呈示(presentation)の正確な時間を決定し、ＲＴＰタイムスタンプは、特定のビデオ・フレーム又は音声サンプルが、メディア・ストリームの他の部分と比較して、どの時間に再生されなければならないかを決定する。したがって、ネットワーク、例えばアクセス・ノードのＢＳＣがバッファリング・パケットによってメディア・ストリームを遅延させ、又はメディア・パケットを放棄することによってメディア・ストリームの速度を上げる（通例は一度これらのパッケをバッファリングすることだけが可能である）のであれば、ＵＥが通常の方法でＲＴＰタイムスタンプを使用する場合に課題が生じる。例えば、ＲＴＰタイムスタンプがパケットの再生をＵＥによって要求されている間に、ネットワーク内のＢＳＣがパケットを遅延させる場合に、ＵＥは課題に直面することになる。同様に、ＢＳＣがパケットを放棄して、その結果、ＲＴＰタイムスタンプの「ギャップ」になる。その一方で、ＵＥは、あたかもギャップが存在しないかのように再生を続けなければならない。

そのうえ、例えばＢＳＣを用いてネットワーク内のどこかにあるメディア・ストリームを遅延させることは、ＵＥでのメディア・ストリームの再生は、その同一の遅延によって実行されないということを自動的に意味するものではない。例えば、ＢＳＣによって導かれる遅延が、伝送されたメディアの周波数に対して比較的小さい場合（例えば１００ｍｓ）、ＵＥは、あたかも遅延がメディア・ストリームに全く導かれていないかのように、呈示を継続することが可能であろう。導かれた遅延が比較的小さい場合、ＵＥはこれをジッタとして認めることができて、遅延に補償するためにそのジッタ・バッファを使用することができる。より大きな遅延がＢＳＣによって導かれる場合（例えば１秒以上）、ＵＥはその実装に従って反応することができる。例えば、ＵＥは、それをメディア・ストリーム内の「ギャップ」と判断することができる。新しいパケットが到達しないために、ＵＥでの（ジッタ）バッファは、メディア・ストリームの呈示により空にされ、再生を継続することができない。次いで、遅延メディア・ストリームに関連づけられた新しいパケットがＵＥに到達する場合、ＵＥは、再びジッタ・バッファリングを開始し、メディア・ストリームの再生を継続することができる。一旦ジッタ・バッファがその時点を充たすと、再生を継続することができる。他のＵＥは、再びバッファリングを開始することができない。例えば、メディア・ストリームのギャップに応答して、ＵＥは、メディア・ストリームがもはや利用できないと判断し、再生を停止することができる。

この課題を解決するために、一実施形態において、ＵＥは、ネットワーク遅延メディア・ストリームを受信するように適合することができる。このことは、小さい遅延について、ＵＥがジッタと導かれた（小さい）遅延との間の差分を認識するようにプログラムすることができることを意味する。ジッタは伝送周波数の前後の（統計的な）変動を表すので、後にいくつかのパケットが予想されて到達する場合であっても、平均して、メディア・パケット到達時間は一定のままである。換言すれば、ジッタ・バッファのメディア・パケット量は、ある安定性のある平均時点の前後で変動することができる。これと対照的に、故意に導かれた遅延は、決定的な特徴を有し、全ての更なるメディア・パケットを後に到着させる。多くの（遅延した）メディア・パケットを測定することによって、統計上の遅延とネットワーク・バッファにより導かれる遅延との差分を決定することができる。ＵＥがネットワーク・バッファ遅延の発生を判断する場合、そのＵＥはこれらパケットを異なって扱うことができ、メディア呈示において同一の遅延を導くことができる。

特定のＵＥは、いわゆる適応ジッタ・バッファを含むことができる。適応ジッタ・バッファは、メディア・パケットの到達時の変更に適応することができる。例えば、多くのパケットが遅れて到達する場合、適応ジッタ・バッファはこの挙動を補償するためにサイズを増加することができる。このことは、ＵＥを、遅延しているメディア・ストリームについて呈示を遅延させることが可能なように調整するために、特定の種類の適応ジッタ・バッファを含むＵＥとみなすことができる。

より遅延を長くするために、ＵＥは、適当な方法で反応するようにプログラムすることができる。このことは、このような長い遅延が検出される場合にＵＥが再生を停止すべきではないことを意味する。その代わりに、それは、単により長く待たなければならない。このような遅延は、より長い時間期間、例えば１秒以上の間、どのメディア・パケットも到達しないときに検出することができる。このような「ギャップ」の後に新しいメディア・パケットが到着する場合、それらは以前のパケットとともに継続的に再生されることになる。更に、長い遅延が検出される場合には、この適応ジッタ・バッファは、バッファ設定を再設定することを要求することができる。長い遅延の後、適応ジッタ・バッファ設定は、あまりに高く設定することができる。したがって、この長い遅延の後に、このジッタ・バッファは遅延を導くことができる。この遅延は要求されたのより長い。

一旦遅延が導かれると、例えばメディア・パケットをスキップすることによって、ＢＳＣはまた、再度遅延を減少させることもできる。このような処理は、また課題を導く場合もある。パケットがＢＳＣによって欠落される場合、ＵＥはこれがパケット遅延又はパケット・ロスであると知覚することができる。ＵＥは、新しい遅延していないパケットで再生を継続する代わりに、パケットがまだ到着するかどうか見るために待つことができる。したがって、それらの実装に応じて、ＵＥは、失ったパケットとは異なって応答することができる。

このことは、ＵＥをプログラミングすることにより解決することができ、（平均して及び大きな遅延を検出するのと同一の方法で）予想よりも早く到達した新しいメディア・パケットに追従される失ったメディア・パケットを、ＵＥによって、遅延が削減され、及びメディア再生が新たに到達した遅延されていないパケットと共に直接継続するように解釈することができる（失ったパケットをパケット・ロスとして解釈するのではない）。

ＢＳＣバッファによって導かれる遅延を取り扱うことの他の解決策は、ＢＳＣメディアを認識させ、又は少なくともＲＴＰを認識されることである。ＢＳＣは、ＵＥにメディア・パケットを転送する前に入来するメディア・ストリームのＲＴＰタイムスタンプを変更するように構成することができる。しかしながら、全てのＲＴＰパケットが、必ずしも１つのメディア・パケットを含むわけではない。オーディオについて、ＲＴＰパケットは、多数オーディオ・サンプルを含むことができる。これとは対照的に、ビデオについて、（同一のＲＴＰタイムスタンプを有する）多数ＲＴＰパケットは、１つのビデオ・フレームを含むことができる。このことは、ＲＴＰパケットのサイズ及びメディア・パケット、即ちオーディオ又はビデオのサイズに依存する。したがって、ＲＴＰパケットにおいてＲＴＰタイムスタンプを変更するために、ＢＳＣは、メディアについて、ＲＴＰパケットが搬送していると認識して、それに応じてタイムスタンプを変更するように構成される。

タイムスタンプの変更は、比較的容易に実現することができる。全てのパケットが一定量の時間遅れることになる場合、新しいタイムスタンプが、バッファされたパケットについてその時間量を減算することによって、算出することができる。ＲＴＰタイムスタンプを、ＥＴＳＩ ＲＦＣ ３５５０において規定されるメディア・ストリームのクロック周波数に基づいて増やす。この点、時間量（ｍｓ）をＲＴＰタイムスタンプから減算することを可能にするために、そのクロック周波数が必要となる。多くのペイロード・タイプのために、クロック周波数は、公知であり、例えばＩＥＴＦ ＲＦＣ ３５５１において詳述される。時間どおりパケットを監視し、クロック周波数をペイロード・タイプに関連付けることによりクロック周波数を取得することによって、ＢＳＣは、メディア・ストリームで使用されるペイロード・タイプを取得することができる。あるいは、このペイロード・タイプは、同期設定メッセージにおいて、ＭＳＡＳからＢＳＣまで送信することができる。

ＢＳＣバッファによって導かれる遅延を取扱うことの更なる解決作としては、ＵＥ及びＢＳＣが同期設定指示を受信することができるということがある。これら同期設定指示は、メディア・ストリームの再生時間についての指示を含む。ＢＳＣが遅延を導いて、宛先間同期を達成する場合であっても、ＵＥは、その再生を調整する手段として、同期設定指示を使用することができる。同期設定指示からの情報を通じて、ＵＥは、メディア・ストリームからのパケットが遅く到達するという事実を認識している。何故ならばＢＳＣがそれらを遅延させたからである。ＵＥが同期設定指示を受信することを可能にする同期方式について、以下に図５及び図６を参照することによって更に詳細に説明する。

１又はそれ以上のアクセス・ラインが中間要素、例えばエンドユーザのＵＥにメディア・ストリームを転送する転送ＵＥを備える場合、この転送ＵＥは、エンドユーザのＵＥからネットワークまで生じている同期ステータス情報メッセージ（例えばＲＴＣＰメッセージのフォーマット）を転送することを可能とすべきである。このような処理は、ＩＥＴＦ ＲＦＣ ３５５０に説明される技術によって実現することができる。その技術については本願明細書に組み込まれるものとする。ＲＦＣ ３５５０は、メディア経路の２種類の中間要素を規定する。即ち、ミキサ及び変換器(translator)である。変換器は、ＲＴＰ及びＲＴＣＰのメッセージを変更することなく転送することができる。したがって、転送ＵＥが変換器のように機能する場合には、ＲＴＣＰメッセージを後方及び前方に転送することは課題を提起しない。しかしながら、ＵＥが（例えば他のコーデックにメディア・ストリームを変換する）トランスコーダとして機能する場合、ＵＥはＲＴＣＰメッセージを処理するように構成しなければならない。

トランスコーディングの間、ＵＥは、ＲＴＰメディア・パケット及びＲＴＰタイムスタンプを修正する。したがって、ＲＴＣＰメッセージをトランスコーディングの中間要素を介してネットワークに送信可能とするために、それは、一緒に属する入来し発出するタイムスタンプを追跡し続ける。換言すれば、トランスコーディングするＵＥは入力におけるメディア・パケットのタイムスタンプを出力におけるメディア・パケットのタイムスタンプに、またその逆に、相関させることができる。エンドユーザのＵＥが同期ステータス情報メッセージを送信する場合、この情報はトランスコードされたＲＴＰストリームのＲＴＰタイムスタンプを含むか又はこれに基づく。したがって、トランスコーディングＵＥは、入来タイムスタンプと発出タイムスタンプの間の相関情報を使用して、ＲＴＰタイムスタンプを入来するＲＴＰストリームの関連付けられた値に変更する必要がある。このように、ＭＳＡＳに送信されるＲＴＣＰメッセージは、正しいＲＴＰタイムスタンプに基づく同期ステータス情報を収容する。この処理については、ＲＦＣ ３５５０において更に詳細に説明する。

図３は、本発明の他の実施形態によるコンテンツ配信システムの少なくとも一部を示している。特に、この実施形態では、ＥＴＳＩ ＴＩＳＰＡＮ ＴＳ １８３０６３及びＴＳ １８２ ０２７に規定されるＩＭＳベースのＩＰＴＶ３００アーキテクチャに基づいて、コンテンツ配信システムの実施を示している。本システムは、コール／セッション制御機能（ＣＳＣＦ）のセットを含むＩＭＳコア３０７を備える。即ち、例えばプロキシＣＳＣＦ（Ｐ―ＣＳＣＦ）、問合せ(Interrogating)ＣＳＣＦ（Ｉ―ＣＳＣＦ）及び配給(Serving)ＣＳＣＦ（Ｓ―ＣＳＣＦ）である。このＩＭＳコアは、更に、ユーザ機器（ＵＥ）３０５、及びネットワークにおいてＩＰＴＶサービスを制御するＩＰＴＶサービス制御機能（ＳＣＦ）３０６に接続され、並びに、メディア制御機能（ＭＣＦ）２０２及びメディア配信機能（ＭＤＦ）３０３を含むメディア制御（ＭＦ）３０１に接続されて、トランスポート機能（ＴＦ）３０４を介したユーザ機器（ＵＥ）へのメディア・コンテンツ及び制御パケットの配信を制御する。

ＴＳ１８２０２７からのＩＰＴＶアーキテクチャは、メディア同期アプリケーション・サーバ（ＭＳＡＳ）３０８と共に拡張される。ＭＳＡＳ３０８は、宛先間同期機能を実行するように構成される。宛先間メディア同期は、特定のメディア、例えば、ビデオ・フラグメント及び／又はオーディオ・サンプルについて、異なった宛先で、同時に又は少なくともほとんど同一の時点で、呈示することを可能にする同期機構に関するものである。
同期が同期技術と関連づけるインター転送先のメディアは、（例えば同じことの異なる目的地の、又は、最も少なくほとんど同じ時のビデオ断片及び／又は音声サンプル）の提出を可能にする。ＩＭＳシステムは、メディア・バッファリングに適用してもよい。メディア・バッファリングは、例えば、１又はそれ以上の可変遅延バッファを用いたトランスポート機能で行うことができる。バッファは、同期ステータス情報レポートに付加されるＭＳＡＳからバッファ設定情報を受信することができる。例えば、ＲＴＣＰ受信機は、同期拡張と共にレポートし、そして、ＵＥがＲＴＰトランスポート制御のためにネットワークに送信する。

同期化は、例えば少なくとも１つの可変遅延バッファを用いたバッファリング、及びトランスポート機能における関連付けられたバッファリング同期クライアント（ＢＳＣ）３１０と連携して、ＵＥの位置における測定同期クライアント（ＭＳＣ）３０９によって決定される同期ステータス情報を用いることで実行することができる。ＭＳＡＳは、異なるＭＳＣから同期ステータス情報を収集することができ、また、同期設定指示を送信することによって、関連付けられるＢＳＣにおいてバッファリング処理を制御することができる。ＩＭＳコアは、同期設定指示をリソース・アドミッション及び制御サブシステム（ＲＡＣＳ）３１１を用いてトランスポート機能のＢＳＣに送信することができる。

図３のＩＰＴＶシステムは、セッション開始プロトコル（ＳＩＰ）を用いて、ユーザ端末間の、又はユーザ端末とＳＣＦ及びＭＦを備えるアプリケーション・サーバ間のセッションをセットアップ及び制御することができる。セッション記述プロトコル（ＳＤＰ）は、ＳＩＰ信号メッセージによって搬送され、セッション内のメディア・コンポーネントを記載及び交渉するために用いることができる。更に、リアル・タイム・ストリーミング・プロトコル（ＲＴＰ）は、例えば、ブロードキャスト・トリック・モード、コンテンツ・オン・デマンド（ＣｏＤ）、及びネットワーク・パーソナル・ビデオ・レコーダ（ＮＰＶＲ）を提供するメディア制御のために用いられ、また、リアル・タイム・トランスポート・プロトコル及びＲＴＰ制御プロトコル（ＲＴＣＰ）は、メディア・トランスポート及びその制御のためにそれぞれ用いられる。

図４は、本発明の一実施形態による、シグナリング・フロー４００をしめしており、ここでは、ＩＰマルチキャスト・チャネルへ加入した（ＵＥの）受信機が同期される。このシナリオは、例えば２人のユーザが、異なる位置の異なるＵＥに対して同期される方法により同一のライブ・コンテンツ（例えばマルチキャストされたサッカーの試合）を視聴することを望むときに、適用することができる。宛先間同期は、継続するチャット・セッション又はオープンしている電話ラインを介して、１ユーザが他のユーザの数秒前にゴールを見るというリスクをとることなく、試合を共に楽しみながら、ユーザ間の相互作用を可能にすることができる。

第１ステップ４０２において、ＵＥはＩＭＳコアにメディア・セッションのセットアップを要求する。このリクエスト・メッセージは、例えばＥＴＳＩ ＴＳ １８２ ０２７及びＥＴＳＩ ＴＳ １８３ ０６３で規定されたＳＩＰインバイト・メッセージとすることができる。このリクエストは、ＩＭＳコアによってＳＣＦに転送することができる（ステップ４０４）。ＳＣＦはベーシックＩＰＴＶメディア配信について高度なサービスを提供する。

このＳＣＦは、セットアップされるセッションについての更なる情報を含む応答メッセージ、例えばＳＩＰ２００ＯＫメッセージと共にこの要求に返答することができる。この更なる情報は、ＭＳＡＳのアドレス、例えばＵＲＬ又はＩＰアドレス、及び同期する端末のグループを特定するためのグループ同期識別子（ＳｙｎｃＧｒｏｕｐＩｄ）を含むことができる。このグループ同期識別子は、例えば応答メッセージのＳＤＰパラメータとして含むことができる。ＩＭＳコアは、引き続き、応答メッセージを要求元ＵＥへ戻し（ステップ４０６、４１２）、そして、要求されたメディア・セッションが同期を要求とすることをＲＡＣＳに通知する。

このＲＡＣＳは、ＥＴＳＩ ＴＳ １８３ ０１７によりＤｉａｍｅｔｅｒメッセージを使用して通知されることができる。Ｄｉａｍｅｔｅｒは、拡張可能なプロトコルであり、同期化の目的で、必要となる同期情報を収容する新規な属性値ペアを規定することによって、延長することができる。特に、Ｄｉａｍｅｔｅｒ同期設定要求４０８は、同期セッションを特定する情報、例えばＳｙｎｃＧｒｏｕｐＩｄ、同期されるメディア・ストリームを特定するための情報（例えば、ＳＩＰ応答メッセージ内の１又はそれ以上のセッション記述プロトコル（ＳＤＰ）パラメータ）、関係するＵＥを特定するための情報（例えば、メディア・ストリームをセットアップするＵＥのＩＰアドレス）、及びこの特定のメディア同期に対する同期サーバとして割り当てられたＭＳＡＳのアドレスを含むことができる。

例えばＤＨＣＰを使用して、ネットワークは、ＩＰアドレスをＵＥに割り当てることができる。ネットワークは、ＩＰアドレスの特定の範囲内で、ＩＰアドレスをＵＥに割り当てることができ、ＩＰアドレスはＢＳＣを収容するあるネットワーク・ノードに関連付けられてもよい。ＲＡＣＳは、ＩＰアドレス範囲のリスト及びＩＰアドレス範囲の各々に関連付けられるＢＳＣのアドレスを用いて提供又は構成することができる。同期設定要求メッセージ４０８におけるＵＥのＩＰアドレスを用いて、このＲＡＣＳは、リストに基づきＢＳＣを特定することができる。ＢＳＣは、メディア・セッションに関連付けられたバッファリング・メディア・ストリームに適している。ＢＳＣは、メディア供給元とＵＥの間の媒体経路内にあり、又は、それに関連付けられている場合、ＵＥと共に使用可能である。

ＲＡＣＳが同期化のためのバッファとして用いられるＢＳＣのＩＰアドレスを決定した後、それはこのアドレスを同期設定要求に挿入することができる。同期設定要求は、引き続き、例えばＤｉａｍｅｔｅｒメッセージ４１０を用いてＭＳＡＳに転送される。メッセージ４１０は、ＩＭＳコアからＲＡＣＳに送信される同期設定要求４０８と同一又は類似のフォーマットを有することができる。また、ＢＳＣ識別子、例えばＢＳＣ ＩＰアドレスを収容する属性値ペアを用いて拡張することができる。

ＢＳＣを割り当てる、又は位置を特定する機構は、上記の実施形態に限定されない。一実施形態において、ＳＣＦは、ＵＥ及びＢＳＣについてのリストを保持することができる。このリストを使用して、ＢＳＣをＵＥが要求したメディア・セッションに割り当てることができ、選択したＢＳＣを直接ＭＳＡＳに伝達することができる。他の実施形態において、ＲＡＣＳは、直接ＭＳＡＳに通知せず、それをＳＣＦによって割り当てられたＭＳＡＳへレポートするようにＢＳＣに指示する。さらに別の実施形態において、ＢＳＣアドレスを、ＵＥに伝達することができる。このＵＥは、その後に、ステータス情報レポートの一部としてＭＳＡＳにこのアドレスを伝達することができる。この変形形態において、ＢＳＣアドレスは、例えばＢＳＣ ＩＰアドレス及び、任意に、ポート番号を含むＲＴＣＰメッセージ内のフィールドと関連付けることができる。

したがって、ＳＣＦ及び／又は、ＲＡＣＳが適切なＢＳＣをＵＥに割り当てるように構成することができる。一実施形態において、このようなＢＳＣは、エッジ・ノード、例えばＤＳＬＡＭ又はＣＭＴＳ内に共に位置することができる。どのＵＥ（１又は複数）が特定のエッジ・ノードの後方にあるか（即ち、１又はそれ以上のＵＥのエッジ・ノードへの関連付け）を特定することの課題は、様々な方法で解決することができる。通例は、ＵＥに接続されたエッジ・ノードが、ＤＨＣＰを用いてＵＥにＩＰアドレス供給する。ＵＥに割り当てられるＩＰアドレスが一意なものである場合、それがどのエッジ・ノードに割り当てられているかについて、インジケータとして使用することができる。ネットワーク内のエッジ・ノードに対するＩＰアドレス範囲の割当ては、例えば、手動での構成によって予め決定することができ、ネットワークにアクセス可能であるデータベース内のどこかに格納されたリストに保持することができる。このリストは、コピーすることができるか又は、ＳＣＦ及び／又はＲＡＣＳによってアクセス可能とすることができる。

適切なＢＳＣを選択するための更なる変形例として、ネットワーク内で既に利用可能なネットワーク・トポロジ情報に基づいてもよい。例えば、多くの固定ネットワークは、ネットワーク管理(administration)システムを備える。このシステムはどの顧客がどのアクセス・ラインの後方にいるかについて追跡する。同様に、例えば呼設定及びハンドオーバに対処するために、モバイル・ネットワークは、継続して、どの基地局がどの端末によって使用されるかについて追跡する。したがって、このような状況下において、ネットワーク・トポロジ情報は、ネットワーク内で全て既に利用可能である。また、このネットワーク・トポロジ情報は、適切なＢＳＣを選択する目的で使用することができる。

他の変形形態において、ＢＳＣはネットワーク・ノードに位置することができる。このネットワーク・ノードは、ネットワーク階層の高いところにあり、即ち、ネットワーク・ノードは、全て又は大部分の少なくともメディア・ストリームが進行するネットワーク・ノードである。

更なるもう一つのオプションとして、メディア供給元とＵＥの間のルートを決定することができる。このことは、メディア供給元からＵＥへ又はその逆の経路探索メッセージを送信することによって、実現できる。経路探索メッセージは、大部分のオペレーティング・システムで利用可能であり、時折、「ｔｒａｃｅｐａｔｈ」又は「ｔｒａｃｅｒｔ」と呼ばれる。この経路探索メッセージは、ネットワーク内の２つのエンティティ間を伝わる全てのネットワーク・ノードのリストを戻すことができる。ＢＳＣ機能性を収容する全てのノードのリストが利用可能である場合、ＢＳＣ機能性を収容する１つネットワーク・ノードが、経路探索動作によって戻されるネットワーク・ノードのリストから選択することができる。

これから図４のフローに戻る。ステップ４１０において、ＭＳＡＳは、同期セッション・セットアップ情報を含む同期設定要求を受信する。同期セッション・セットアップ情報は、次のものを含む多くの情報項目を含むことができる。即ち、
−ＵＥに関連付けられる識別子、例えばＵＥにより現在用いられているＩＰアドレスに関連付けられる識別子、
−ＢＳＣに関連付けられる識別子、例えばＢＳＣのＩＰアドレス及びあるいはポート番号、
−同期グループに関連付けられる識別子、例えば同期グループＩＤ（ＳｙｎｃＧｒｏｕｐＩｄ）、そして
−コンテンツに関連付けられる識別子、例えばメディア・ストリームに関連付けられた１又はそれ以上のＳＤＰパラメータ、である。

１つのＳＤＰパラメータは、メディア・パケットを送信するためのポート番号に関することができる。ＵＥのＩＰアドレスと組み合わされるこのポート番号は、メディア・ストリームに対する識別子として使用することができる。メディア・コンテンツを特定するための他の変形例は、ＩＥＴＦ ＲＦＣ ３５５０に規定されたＳＳＲＣを使用してもよい。ＳＳＲＣは、メディア供給元によってメディア・ストリームに割り当てられ、メディア・ストリームのセットアップの間にＭＳＡＳに伝達することができる。ＭＳＡＳは、この情報をメモリ又はデータベースに格納することができる。更に、それは、この情報をＭＳＡＳにおける現在の同期情報に相関させることができる。例えば、一実施形態において、ＳｙｎｃＧｒｏｕｐＩｄに基づいて、ＭＳＡＳは、どの他のメディア宛先が同一の同期グループの一部であるかについて判断することができる。この情報は、遅延設定を算出するために、後の段階で、ＭＳＡＳによって使用することができる。

ＵＥによって受信される応答メッセージ４１２は、ＭＳＡＳ及びＳｙｎｃＧｒｏｕｐＩｄの位置を含んでいる、メディア・セットアップ及び同期について必要とされる全ての情報をＵＥに提供することができる。任意には、バッファリングが他のエンティティにおいて実行されるという指標を含むことができる。セッション・セットアップの承認（ステップ４１４，４１６）の後に、ＵＥは、例えば、選択したマルチキャスト・ストリームの配信を要求するためにＩＧＭＰを使用することができる。

同期化目的のために、ＵＥのＭＳＣは、次いで、同期ステータス情報をＭＳＡＳに送信することができる（ステップ４１８）。これに応じて、ＭＳＡＳは、同期設定指示を生成して、ＢＳＣにこれらの指示を転送することができる（ステップ４２０）。同期ステータス情報及び同期設定インストラクションの伝送は、例えば拡張されたＲＴＣＰ送信機及び受信機のレポートを用いて機構をレポートするＲＴＣＰを使用して実現することができる、そして、受信機がレポートする。当該レポートについて以下に更に詳細に説明する。

ＭＳＣから受信する同期ステータス情報は、メディア・ストリーム内の特定のサンプルを特定するためのＲＴＰタイムスタンプ及びＮＴＰタイムスタンプを含むことができる。例えば、ＲＴＣＰ受信機レポートが１２３４のＲＴＰタイムスタンプ及び２月３日、１０時１４分１５秒を示すＮＴＰタイムスタンプを収容するとき、それは、メディア・ストリーム内のサンプル１２３４が正確に２月３日１０時１４分１５秒に生じたことを意味する。

このように、ＮＴＰタイムスタンプは、ＵＥがレポートするサンプリング・イベントの実際の（絶対）時間を表わす。同期化目的のために、宛先間メディア同期に関わる全てのＵＥは、例えばＮＴＰ（ネットワーク・タイム・プロトコル）に基づいて公知技術を用いて同期されるクロックを使用することが想定される。ＲＴＰタイムスタンプは、ＲＴＰデータ・パケットの第１オクテットのサンプリングの瞬間を反映する。このサンプリングの瞬間は、同期及びジッタ算出を可能にするために、時点において単調に及び線形にインクリメントするクロックから導出されなければならない。ＲＴＰタイムスタンプは、このように、メディア・ストリーム内のサンプルの瞬間の時点に関する情報を提供する。

同期化は、さまざまなタイミング・イベントに基づくもの、例えばＵＥによってメディアを受信する時間又はメディアがユーザに呈示される時間に基づくものとすることができる。本例示では、同期ステータス情報のＲＴＰタイムスタンプが、示されたＮＴＰ時間で受信するメディア・パケットを反映することが想定される。

ＭＳＡＳは、１又はそれ以上の同期グループにおける異なるメディアの宛先（通例はＵＥ）のＭＳＣについての同期ステータス情報を受信及び管理する。収集した同期ステータス情報に基づいて、ＭＳＡＳは、引き続き、ＵＥに関連付けられたＢＳＣについての遅延設定指示を算出することができる。これらの遅延設定指示は、最も多くの遅延を有するメディアの宛先を特定して、次いでその特定した最も多く遅延したメディアの宛先の再生時間に一致させるために導くことが必要となる他のメディアの宛先の遅延量を計算することによって算出される。

遅延設定指示はＢＳＣについての指示に関し、ＲＴＰタイムスタンプ及びＮＴＰタイムスタンプの所与のタイムスタンプの組合せに（仮想的に）一致させるような方法で、ＢＳＣがメディア・パケットを処理することを可能にする。遅延設定指示の算出は、基準タイムスタンプ、例えばＮＴＰタイムスタンプの選択、また、全てのメディアの宛先についての関連付けられたＲＴＰタイムスタンプの算出を含むことができる。

第一の実施形態において、例えばＭＳＡＳは、特定のＲＴＰタイムスタンプを選択することができ、また、どのＮＴＰタイムスタンプでそれらが選択されたＲＴＰタイムスタンプと関連付けられたメディア・パケットを処理すべきかについて、メディアの宛先ごとに算出することができる。他の実施形態において、ＭＳＡＳは、ＮＴＰタイムスタンプを選択することができ、どのＲＴＰタイムスタンプが選択されたＮＴＰタイムスタンプと関連付けられるべきかについて、メディアの宛先ごとに算出することができる。ＭＳＡＳが現在のＮＴＰ又はＲＴＰタイムスタンプを選択する必要はないことに留意されたい。問題となるのは、ＮＴＰ及びＲＰＴの間の関係であり、現在のタイムスタンプ、又は、過去又は現在における（仮想的な）同期時点を反映しているタイムスタンプを使用することができる。

ＲＴＰタイムスタンプが、（ＩＥＴＦ ＲＦＣ ３５５０による）絶対時間ではなく周波数を示すので、サンプリング・レートを決定することが必要となる。このことは、（例えば公知のＩＥＴＦ ＲＦＣ ３５５１から）ペイロード・タイプ及びそれらの関連付けられた特定のサンプリング・レートを決定すること、又は２若しくはそれ以上のステータス情報レポートを用いることのいずれかによって、行うことができる。例えば、第１の状況レポートはＮＴＰタイムスタンプＮＴＰ＿ｘと共にＲＴＰタイムスタンプＲＴＰ＿ｘ、及びＮＴＰタイムスタンプＮＴＰ＿ｙと共に第２の状況レポートＲＴＰタイムスタンプＲＴＰ＿ｙを収容することができる。ここでは、ＮＴＰ＿ｙはＮＴＰ＿ｘより後の時点に関する。この情報に基づいて、周波数（又はクロック・レート）＝（ＲＴＰ＿ｙ ― ＲＴＰ＿ｘ）／（ＮＴＰ＿ｙ ― ＮＴＰ＿ｘ）を判断することができる。

レポートされたメディア・パケットの到達時間は、例えばネットワーク・ジッタのため、いくつか不正確性を含むこともある。これらの不正確性は、除去することができる、又は、２若しくはそれ以上のステータス情報レポートを使用することにより少なくても削減することができる。算出された値が、頻繁に用いられるある固定のクロック・レート（例えば８０００Ｈｚ、４４１００Ｈｚ及び９００００Ｈｚの）に近い場合、ＭＳＡＳはこれら公知の値の１つが使われると想定することができる。一旦ＭＳＡＳがクロック・レートを決定すると、ＢＳＣについての遅延設定指示は算出することができる。

ＵＥ１及びＵＥ２のそれぞれに関連付けられたステータス情報レポート値についての次の例を検討する。９００００Ｈｚのクロック・レートが以下に用いられる。即ち、
− ＵＥ１は、ＮＴＰ時間の０１時２３分４５．６７８秒（ＮＴＰ＿ＵＥ１）におけるＲＴＰタイムスタンプ２０７００００（ＲＴＰ＿ＵＥｌ＿Ｒｅｐｏｒｔｅｄ）をレポートする、及び
−ＵＥ２は、ＮＴＰ時間０１時２３分４６．６７８秒（ＮＴＰ＿ＵＥ２）におけるＲＴＰタイムスタンプ２２５００００（ＲＴＰ＿ＵＥ２＿Ｒｅｐｏｒｔｅｄ）をレポートする。

ＭＳＡＳは、まず、基準タイムスタンプの選択、及び当該基準タイムスタンプを基礎として使用する他のタイムスタンプの計算により、最も大きい遅延を決定する。例えば、ＭＳＡＳは、ＵＥ１のＮＴＰタイムスタンプを選択し、このＮＴＰ時間におけるＵＥ２のＲＴＰタイムスタンプを算出することができる。即ち、
ＲＴＰ＿ＵＥ２＿ｃａｌｃｕｌａｔｅｄ＝ＲＴＰ＿ＵＥ２＿ｒｅｐｏｒｔｅｄ＋９００００＊（ＮＴＰ＿ＵＥ１ ― ＮＴＰ＿ＵＥ２）
この算出の結果はＲＴＰ＿ＵＥ２＿ｃａｌｃｕｌａｔｅｄ＝２１６００００であり、ＵＥ１が最も遅延したＵＥであることを示す。換言すれば、ＮＴＰ＿ＵＥ１時間においてで、ＵＥ２のＲＴＰタイムスタンプ値は、ＵＥ１と関連付けられたものよりも大きい。したがって、宛先間同期を達成するために、ＵＥ２は再生を遅延させる必要がある。

遅延設定指示を算出した後に、ＭＳＡＳは、指示を適当なＢＳＣに送信することができる。これらの指示は、算出したＲＴＰ及びＮＴＰのタイムスタンプ、並びに遅延されるメディア・ストリームを識別するための手段（一例では、ＵＥのＩＰアドレス及びメディアを受信するポート番号、又はＲＴＰプロトコルで用いられるメディア・ストリームのＳＳＲＣ識別子）を例えば収容することができる。

ＭＳＣ及びＢＳＣがメディ経路における異なる位置に配置されるので、ＢＳＣは、ＵＥでＭＳＣによって送信された同期ステータス情報についてのナレッジ、及びどのメディア・ユニットをＵＥが現在呈示しているかについてのナレッジを有さない。したがって、それは、遅延を導くべきであるか又は取り除くべきかどうか決定することができない。この理由のために、一実施形態において、ＭＳＡＳは、ＵＥにおいてＭＳＣから遅延設定指示に対して発せられるステータス情報レポートを含むことができ、その結果、ＢＳＣは、ＭＳＡＳによって決定されるように、必要となる遅延をＲＴＰ及びＮＴＰのタイムスタンプに基づいて算出することができる。したがって、ＵＥ１及びＵＥ２についての遅延設定指示は、ＵＥ１のステータス情報レポートからの値及びＲＴＰ＿ＵＥ２＿ｃａｌｃｕｌａｔｅｄ値を含むことができ、ＵＥ１が遅延無を必要とすることを決定し、ＵＥ２が第２の遅延（２１６００００―２０７００００＝９００００、これは正確に１秒の所与のクロック・レートに等しい）を決定することを可能にする。

一旦ＢＳＣが指示を受信すると、それはストリーム識別手段に基づいて適切なストリームの配置し、その指示に基づいて導く又は取り除くための遅延量を算出することができる。その後に、このＢＳＣは、必要とされる遅延を導くことができる。遅延は、幾らかの時間にわたりメディア・パケットを送信するのを停止することにより、又は、ＲＴＰパケット及びＲＴＣＰパケットの両方のＲＴＰタイムスタンプを変更することにより、実現することができる。

遅延設定指示は、過去からのＮＴＰ又はＲＴＰのタイムスタンプを含むことができる。所与のＮＴＰ及びＲＴＰのタイムスタンプが一致するように、遅延設定指示の受信機、例えばＢＳＣは、メディア・ストリームの遅延を導くべきである。パケットが全て対処されることの準備ができているＲＴＰタイムスタンプをその指示が収容する場合であっても、その指示の受信機は、その指示を、現在対処されるタイムスタンプに変換(translate)しなければならない。ＮＴＰ及びＲＴＰのタイムスタンプは、また、受信機において決して到達しないメディア・パケットと関連付けることもできる。ある意味で、このようなタイムスタンプは、仮想的であるとみなすことができる。同期を命ずるのは、ＮＴＰ及びＲＴＰタイムスタンプの組合せである。ＭＳＡＳは、ＵＥに対し、ＵＥがあたかもＲＴＰタイムスタンプ、ＮＴＰタイムスタンプにあるべきである、又はあることができるように振る舞うことを通知する。ＭＳＣが決定及び送信した同期ステータス情報が異なるパケット処理時間（例えばパケット到達時間、パケット呈示時間又はパケット・デコード時間）に基づく又は関連付けることができるので、遅延設定指示は、原則として、同一のパケット処理時間に基づくべきである。例えば、同期ステータス情報が、パケット到達時間に基づく場合、遅延設定指示は、また、パケット到達時間に基づくとすべきでもある。異なる処理時点（到達、デコーディング、呈示）の間の時間差が一定で公知である場合には、このステータスレポートはパケット到達時間に基づいてもよく、その一方で、設定指示はパケット呈示時間に基づいてもよい。

ＮＴＰ及びＲＴＰのタイムスタンプの代わりに、他の実施形態において、ＢＳＣに送信される遅延設定指示は、をセットしているインストラクションは、他の実施形態では、ＢＳＣに対して第２のメディア・ストリームを１０００ミリ秒バッファする指示を含むことができる。あるいは、遅延設定指示は、ＢＳＣに対し、１０００ミリ秒の遅延が実現されるように、宛先間同期のバッファ・サイズ遅延を増加させるように指示することができる。これらの場合では、必要となる遅延を算出するのはＭＳＡＳである。

図５は、本発明の更なる別の実施形態による、コンテンツ配信システム５００の少なくとも一部を示している。特に、図５では、図２を参照して記載したものと類似のＩＭＳベースのＩＰＴＶアーキテクチャの一部を示している。本システムは、基本処理機能(Elementary Processing Function)及び基本転送機能 (Elementary Forwarding Functions)ＥＣＦ／ＥＦＦ５０４を備えるトランスポート機能５０２及びＢＳＣ５０６を備える。ＢＳＣ５０６はこのＥＣＦ／ＥＦＦ（又はその一部）と共に配置される。ＭＤＦ５０８は、宛先としてメディア・ストリーム５１０をＵＥ５１２に届ける。メディア・ストリームは、ＴＦ５０２を通じて、ＢＳＣ５０６を介してＵＥのＭＳＣ５１４まで移送される。

メディア・ストリーム５１０の受信に応答して、ＵＥのＭＳＣは、同期ステータス情報メッセージ５１６、即ち同期ステータス情報レポートを、ＭＳＡＳ５１８に対して生成する。図３及び図４を参照して説明したシステムとは対照的に、同期ステータス情報メッセージは、ＢＳＣ５０６を介してＭＳＡＳに送信される。受信した同期ステータス情報に基づいて、このＭＳＡＳは、引き続き、同期設定指示５１８を算出して、これらの指示をＵＥにＢＳＣを介して送信する。しかしながら、ＵＥにこれらのメッセージを転送する代わりに、ＢＳＣは、これら同期設定指示を遮断し、これらをＵＥに転送しない。この例では、ＵＥ、ＭＤＦ及びＭＳＡＳのいずれもが、ＢＳＣが呈示している任務を認識するというわけではない。このＢＳＣは、メディア・ストリーム及び全ての同期メッセージの両方の経路にあるので、それは、これらのメッセージ及びメディア・ストリームを遮断し、監視し及び／又は調整することができる。

図６は、図５を参照して説明したシステムに関連付けられるメッセージ・フロー６００を示している。特に、図６は、同期メッセージについてのメッセージ・フロー及びＭＤＦからＵＥまで届けられるメディア・ストリームを示している。第１ステップ６０２において、ＵＥは、同期ステータス情報レポートをＭＳＡＳに送信する。このレポートは、ステータス情報を収容するＲＴＣＰ拡張レポートブロックで拡張されるＲＴＣＰ受信機レポートの形態を有することができる。このレポートがＭＳＡＳに転送される前に、このメッセージはＥＣＦ／ＥＦＦによって遮断される。

このメッセージは、２つの理由により、ＥＣＦ／ＥＦＦによって遮断される。第１の理由は、ＥＣＦ／ＥＦＦのＢＳＣによっていかなるバッファリングも実行するために、ＢＳＣが同期ステータス情報レポートの情報、例えばＭＳＣの特定のメディア・ストリーム・パケットのパケット到達時間についてのタイミング情報を使用できるということである。ＢＳＣが、それによってどのくらいメディア・ストリームを遅延させるかを認識することを望む場合、ＢＳＣは、いくつかの方法でこの情報を受信及び／又は決定することができる。

第１の変形形態において、ＭＳＡＳは、例えば「ｙ秒の間メディア・ストリームｘを遅延させる」という形態で、絶対指示を送信することができる。ＢＳＣは、ＵＥから発している同期状況レポートから、いかなるナレッジなしにこれらの指示を実行することができる。他の変形形態において、ＭＳＡＳは、「これらのメディア・パケットが指定された時間に到達したときに、メディアを再生する」という形態で指示を送信することができる。その場合、（例えばＵＥから発している同期状況レポートに含まれているように）ＵＥにおいてパケット到達時間を認識しているときに、ＢＳＣはこれらの指示を実行することができる。ＵＥからＭＳＡＳまで送信される同期ステータス情報メッセージを遮断することによって、ＢＳＣは、到達時間情報を含むこれらメッセージの情報を認識する。ＢＳＣは、ＭＳＡＳからＵＥまで送信される同期設定インストラクションに収容される情報と結合して使用するために、一時的にこの情報を格納することができる。そのように、ステータス情報及び設定指示を使用して、ＢＳＣは、メディア・ストリームを遅延させるべきか、及びどれくらい遅延させるべきかを決定することができる。

この同期ステータス情報メッセージを遮断する第２の理由は、それにより、ＢＳＣがメッセージ内の情報を調整することを可能にするからである。ＭＳＣ及びＢＳＣがメディア経路上の異なる位置に配置されるため、この情報の調整が必要となる。ＭＳＣがＵＥに位置する状況において、ＢＳＣにより導かれるメディア・ストリームの遅延は、到達時間情報の遅延に結果としてなるであろう。ＭＳＣ及びＢＳＣが共に１つの同期クライアントに位置する場合には、このような状況は発生しない。一旦パケットが到着したならば、即ち、メディア・パケット到達時間を決定した後に、いかなる遅延もが導かれる。したがって、メディア・ストリームはＭＳＣに到達する前に遅延されるので、同期ステータス情報メッセージは、ＢＳＣ及びＭＳＣが１つの位置で結合される状況と比較した際に、異なるタイミング情報を収容するであろう。この効果を補正するために、ＢＳＣは、ＵＥからＭＳＡＳまで送信される同期ステータス情報メッセージを調整することができる。ＢＳＣは、どの時間量までメディア・ストリームを遅延させるかについて認識しているので、この値をステータス情報レポートにおいて報告される到達時間から減算することができる。ＢＳＣがこの動作を実行しない場合には、ＢＳＣがメディア・ストリームを遅延させない状況において、又は、ＢＳＣが時間内のある時点で行うことよりも少なくストリームを遅延させる状況において、ＵＥは、とても後にメディア・パケットを受信するようである。したがって、ＢＳＣが遅延を導くときに、ステータス情報メッセージがそれを反映するように調整することができる。

レポートでの情報の遮断及び調整の後に、ＢＳＣは同期ステータス情報をＭＳＡＳに送信することができ（ステップ６０４）、これに応答して同期設定指示をＵＥに戻すことができる（ステップ６０６）。再度、ＢＳＣはこれら同期設定指示を遮断し、ステータス情報及び設定指示から導かれる時間量によってメディア・ストリームを遅延させることができる。ＢＳＣは、ＵＥに同期メッセージを転送することもでき、又はそうしないこともできる。このことは、ステップ６０８の破線矢印によって示されている。ＢＳＣが設定指示を実行するので、ＵＥはそれらにメディア呈示を遅延させることを要求しない。それにもかかわらず、設定指示を実行するのに加えて、ＢＳＣは、また、ＵＥに指示を転送することもできる。このＵＥは、これら指示の情報を用いて、メディア・パケットを処理する、例えば適切な時間にそれらを呈示することができる。

図７は、ＲＴＰメディア・ストリームに関連付けられた宛先間メディア同期情報をレポートするための考えられるＲＴＣＰ ＸＲのブロック・タイプの一例を示したものである。この規定は、ＩＥＴＦ ＲＦＣ ３６１１に基づく。このＲＴＣＰ ＸＲは、ＲＴＰパケットの受信時間及び呈示時間に関する情報を、例えば、ＩＥＴＦ ＲＦＣ ３５５０に規定される送信機、ＩＥＴＦ ｄｒａｆｔ―ｉｅｔｆ―ａｖｔ―ｒｔｃｐｓｓｍ―１９において規定されるフィードバック・ターゲット、又はＩＥＴＦ ＲＦＣ ３５５０において規定される第三者モニタに対してレポートするのに用いられる。このＲＴＣＰ ＸＲは、また、例えば図３及び図６のメッセージ・フローにおいて示されるような同期メディア再生に関わる、同期ステータス情報、並びに様々な要素、特にＭＳＣ、ＢＳＣ及びＭＳＡＳの間の同期設定指示を交換するのに用いられる。

ＩＥＴＦ ＲＦＣ ３６１１において規定されるとおり、最初の６４ビットは、ＲＴＣＰ ＸＲのヘッダを形成する。宛先間同期ＲＴＣＰ ＸＲは、以下のフィールドの１又はそれ以上を含むことができる。即ち、
−パケット送信機のＳＳＲＣが特定のＲＴＣＰパケットの発信者を特定する。
−ブロック・タイプ（ＢＴ）は８ビットであり、ブロック・フォーマットを特定する。
−同期パケット送信機タイプ（ＳＰＳＴ）は４ビットであり、このフィールドは、この特性の拡張レポートについてのパケット送信機の役割を特定する。これは、以下の値を有することができる。即ち、
１．ＳＣ：パケット送信機は、同期ステータス情報をレポートするために、このＸＲを使用する。タイムスタンプは、ＳＣ入力に関する。ＭＳＡＳ：パケット送信機は、同期設定指示をレポートするために、このＸＲを使用する。タイムスタンプは仮想ＳＣの入力に関し、当該仮想ＳＣは、このＭＳＡＳに接続するＳＣが同期されるのを参照するものとして動作する。
−予約ビット（Ｒｅｓｒｖ）：３ビットである。
−パケット呈示ＮＴＰタイムスタンプ・フラグ（Ｐ）：１ビットであり、ビットは、パケット呈示ＮＴＰタイムスタンプが値を収容するときは１に、それが空である場合には０に設定する。このフラグがゼロに設定される場合には、パケット呈示ＮＴＰタイムスタンプは検査されない。
−ブロック長：１６ビットであり、このＲＴＣＰ Ｂｌｏｃｋ Ｔｙｐｅが固定長を有するので、これは７に設定される。
−ペイロード・タイプ（ＰＴ）：７ビットであり、このフィールドは、ＩＥＴＦ ＲＦＣ ３５５１にしたがってメディア・ペイロードのフォーマットを特定する。このメディア・ペイロードは、ＲＴＰタイムスタンプのクロック・レートに関連付けられる。このクロック・レートは、ＲＴＰタイムスタンプにタイム・ベースを提供する。
−予約のビット（Ｒｅｓｒｖ）：２５ビットである。
−メディア・ストリーム相関識別子：３２ビットであり、この識別子は、同期されたメディア・ストリームを相関させるのに用いる。値が０（全てのビットが「０」に設定される）は、このフィールドが空であることを示す。値が２＾３２―１（全てのビットが「１」に設定される）は、将来の使用のために予約されている。ＲＴＣＰパケット送信機がＳＣ又はＭＳＡＳ（ＳＰＳＴ＝１又はＳＰＳＴ＝２）であるときは、メディア・ストリーム相関識別子が同期グループＩＤ（ＳｙｎｃＧｒｏｕｐＩｄ）にマップする。
−ＳＳＲＣ：３２ビットであり、メディア供給元のＳＳＲＣは、ＸＲが関係するＲＴＰパケットにおけるＲＴＰヘッダで搬送されるＳＳＲＣ識別子の値にセットされる。
−パケット受信ＮＴＰタイムスタンプ：６４ビットであり、このＮＴＰタイムスタンプは、ＸＲが関係するＲＴＰパケットの第１オクテットの到達ウォール・クロック時間である。ＳＰＳＴ＝２に対し、それは、同期グループの他のＳＣが同期することができる仮想ＳＣに関する。
−パケット受信ＲＴＰタイムスタンプ：３２ビットであり、このタイムスタンプは、ＸＲが関係するＲＴＰパケットにおけるＲＴＰヘッダで搬送されるＲＴＰタイムスタンプの値を有する。
−パケット呈示ＮＴＰタイムスタンプ：３２ビットであり、このタイムスタンプは、関連付けられたＲＴＰパケットの第１オクテットに収容されるデータがユーザに呈示されるＮＴＰ時間を反映する。それは、最も重要でない１６ビットのＮＴＰ秒部分、及び最も重要な１６ビットのＮＴＰ少数部分を含む。このフィールドが空である場合には、それは０にセットされ、パケット呈示ＮＴＰタイムスタンプ・フラグ（Ｐ）は０にセットされる。

図８は、本発明の一実施形態によるＢＳＣ８００を示している。特に、それはバッファ８０２を含むＢＳＣ８００を示しており、第１ＵＥ１ ８０４及び第２のＵＥ２ ８０６によって共有される。ＵＥ１は、第１の同期メディア・ストリーム８０８を受信し、ＵＥ２は、第２の同期メディア・ストリーム８１０を受信する。この例において、メディア・ストリーム８０８及び８１０は、入来するメディア・ストリーム８１２から発しており、第１メディア・ストリームの特定パケットがＵＥ２よりＵＥ１に早く送信されるという例外を有する同一の内容に関係する、同一のメディア・ストリームである。このＢＳＣは、ＢＳＣの処理を制御するためのコントローラ８１４を備える。例えば、このコントローラは、ＭＳＡＳから同期設定情報８１６を受信し、同期グループ内の異なるＵＥに関連付けられた遅延を算出し、１又はそれ以上の遅延メディア・ストリームをＵＥに伝送することができる。

ＵＥ１及びＵＥ２が互いに同期された閲覧セッションにあり（即ち、これらは同じ同期グループに属する）、ＢＳＣとＵＥ１の間のメディア経路に関連するネットワーク遅延がＢＳＣとＵＥ２の間のメディア経路に関連するネットワーク遅延より大きいにために、ＢＳＣは遅延を導いて、ＵＥとＢＳＣを備えるアクセス・ノードとの間のアクセス・ラインの遅延を補償する。したがって、特定のメディア・パケット、例えばビデオ・フレーム又は音声サンプルは、ＵＥ１及びＵＥ２が実質的に同期される方法でメディア・ストリームを受信することを可能にするために、ＵＥ１により早く送信しなければならない。図８に、２つのＵＥ間で共有することを示す。同じＢＳＣを用いて同一のコンテンツを閲覧し、及び／又は１つの同期グループに所属するＵＥは、バッファを共有することができる。他の実施形態において、ＢＳＣは、異なる同期グループについての同一のコンテンツのバッファリングを実行することができる。いずれの場合においても、バッファ容量及びＢＳＣへ入来するネットワーク負荷の点で、単一のバッファを使用することがより効率的である。バッファは、Ｆｉｒｓｔ―ＩｎーＦｉｒｓｔーＯｕｔ（ＦＩＦＯ）方式により動作することができる。発しているメディア・ストリーム８１２から受信する新しいバッファは、バッファ８０２に追加され、バッファ内で最も長いパケットが最初に除去される。バッファは、ＵＥ識別子８２０及び関連付けられるポインタ８２２を含むバッファ・リスト８１８を保持することにより多数ＵＥで共有することができる。ここでは、ＩＤがＢＳＣを共有するＵＥを特定する。そして、ポインタがその対応するＵＥに送信される次のパケットをポイントする。例えば、バッファ・リスト８１８は、ＵＥ１に関連付けられる第１のポインタを含むことができ、バッファ内のパケット５及びＵＥ２と関連付けられた第２ポインタをポイントし、バッファのパケット８をポイントする。パケットが特定のＵＥに送信されるたびに、ＢＳＣはリスト、特にその中のポインタを維持及び更新する必要がある。ＢＳＣは、継続的に各メディア・ストリームをバッファする必要はない。例えば、このＢＳＣは、当該ＢＳＣが異なるＵＥに関連付けられた遅延を変更して取り扱うことを可能とするために、１５秒間メディア・ストリームをバッファするだけでよい。

図９Ａ及び図９Ｂは、宛先間同期の目的のバッファリング方式の概略図を示している。これらの図は、本発明と関係した更なる利点を示しており、特に、改良した時間を変更するチャネルの効果に関連した利点について示している。図９Ａは、ＵＥ９０２が測定機能９０４及びバッファリング機能９０６を備える同期クライアントを備えるシステムを示している。このような場合には、バッファ機能は、宛先間バッファ及びジッタ・バッファの両方として機能するように構成することができる。ＵＥは、ＵＥ９０２のユーザに表示されるビデオ・フレームを収容する第１のメディア・ストリーム９０８を受信する。ＵＥ９０２は、宛先間同期セッションの一部とすることができる。したがって、同期化を可能にするために、ＵＥ９０２は、バッファリング機能、で受信したメディアのバッファリングを実行することを必要とすることもある。この場合は、１０個のメディア・ユニット、例えばビデオ・フレームである。バッファ機能はまた、ジッタ・バッファとして機能するために、数を追加したフレーム、例えば５つのビデオ・フレームがバッファされ、これにより、バッファ機能において合計１５個のビデオ・フレームをバッファリングする。

ある時点で、ＵＥのユーザは、第１のメディア・ストリーム９０８から第２のメディア・ストリーム９１０へ切り替える必要があることもある。チャネル変更の間、このＵＥは、まず、第２ストリーム９１０からメディア・ユニットのバッファリングを開始する必要があり得る。宛先間同期なしで、短い期間だけが、ジッタを取り扱う目的でバッファリングされることを必要とする。しかしながら、ＵＥのバッファ機能がまた、宛先間同期の目的でバッファリングをも行うため、ビデオ・フレームの追加のバッファリングが、バッファされたビデオ・フレームのユーザへの表示を開始する前に、必要となる。

例えば、メディア・ユニットが毎秒２５個のフレームを有するビデオ・ストリームに関する場合には、フレームのみを、ジッタ・バッファリング目的のためにバッファすることが必要となる。これは、概ね２００ミリ秒の遅延を導く。このような遅延は、チャネルを変更するのになお使用可能な時間としてもよい。しかしながら、図９ＡのＢＳＣは、ジッタ及び宛先間同期の両方を取り扱うための１５個のフレームをバッファリングすることを必要とする。このようなバッファリングは、６００ミリ秒、即ちジッタのみを取扱う状況に対するものと比べて３倍の遅延を引き起こすことになる。チャネル変更時間のこのような増加は、ユーザ体験を劣化させ得るだろう。

図９Ｂは、ＭＳＣ及びＢＳＣがＵＥとメディア供給元との間のメディア経路上で異なる位置（すなわち複数の位置）に配置される方式に関する。この場合、ＵＥ９１２は、ＭＳＣ９１４及びジッタ・バッファ９１６を収容する。第１のＢＳＣ１（９１８）は、ネットワーク内のメディア供給元とＵＥとの間のメディア経路のどこかに位置する。ＢＳＣ１（９１８）は、現在の第１チャンネルについてバッファリングすることができる。即ち、第１チャンネルを含む第１ストリーム９２０が１０個のメディア・ユニット（例えばビデオ・フレーム）について、これらフレームがＵＥ９１２に転送される前にバッファされる。ネットワークは、更に、第２のチャネルを含む第２のメディア・ストリーム９２４をバッファする第２のＢＳＣ９２２を備える。

図９Ａの方式と比較すると、図９Ｂの方式はいくつかの利点を提供している。第１に、ジッタ・バッファのサイズ（この例では３個のメディア・ユニット）は、ＢＳＣとＵＥの間のより短いメディア経路のために、減少することができる。ジッタはネットワーク内で導出され、したがって、ネットワーク経路がより長く（より短く）なると、メディア・ストリーム内のパケットの遅延差がより大きく（より小さく）なる。図９Ｂの例では、第１のＢＳＣ１は、（実質的に如何なるジッタもない）規則的な間隔を有するメディア・ストリーム９２６内のメディア・ユニットを送出する。より短いメディア経路は、ジッタをより小さくし、したがってより小さいジッタ・バッファを必要とする。１秒当たり２５個のフレーム・レートを使用すると、図９Ａで示される方式において必要される５つのフレームのバッファリングに関連付けられた２００ミリ秒の遅延ではなく、１２０ミリ秒の遅延が導かれる。

第２に、チャネル変更時間は、ＵＥが宛先間同期の目的のためにバッファする必要がないことから、より短い。その代わりに、ＢＳＣ１を収容するネットワーク内のノードは、宛先間同期に必要とされる１０個のフレームについてバッファリングの後処理をする。第２のメディア・ストリームが第２ＢＳＣ２（９１２）によってすでにバッファされているので、メディア再生は直ちに開始することができる。毎秒２５個のフレーム・レートでは、チャネル変更の間の追加の４００ミリ秒の遅延を保存することができる。したがって、チャネル変更の遅延は１２０ミリ秒に減らすことができ、これにより、図９Ａの例示における６００ミリ秒の遅延と比較したときにチャネル変更時間の重大な削減をもたらす。

ザッピングに関する課題の１つは、宛先間同期の目的のために新しいチャンネルについてのバッファ・サイズを決定することである。最も単純な解決策は、例えば同一の時間量又は同一のビデオ・フレーム量の古いチャネルと同様に、新しいチャネルを遅延させることである。しかしながら、新しいチャンネルの遅延を決定するより正確な方法がまた可能である。

一実施形態において、ＢＳＣは、異なるメディア・ストリームに関連付けられる特定のステータス情報の履歴を格納することができ、また、この履歴を用いて正確な同期設定指示を決定することができる。例えば、メディア・ストリームＡに関連付けられたステータス情報レポートに基づいて、ＭＳＡＳは、設定指示をＢＳＣに送信することができ、ＵＥ及びこの同期グループに対してｘミリ秒の間ストリームを遅延させる。ＵＥがメディア・ストリームＢへ切り替えるときに、最初に、ＢＳＣは、メディア・ストリームＡに対して用いられたのと同一量のミリ秒についてメディア・ストリームＢを遅延させる。しかしながら、ＵＥからの新しいステータス情報レポートをＭＳＡＳが受信する場合には、ＵＥに対してストリームＢをｙミリ秒遅延させることを命じる新しい同期設定命令を算出し、ＢＳＣへ送信する。変更した唯一のものがメディア・ストリームであるので、ｙとｘの間の差は、これらメディア・ストリーム間で切り替わるために他の端末で使用することができる。十分なチャネル変更がＢＳＣを用いてＵＥについて発生する場合には、ＢＳＣは、様々なチャネルに対する想定遅延を含むチャネル切替リストを作成することができる。このリストは、１つのチャネルから別のチャネルへ切り替える任意のＵＥについて適切な遅延を選択するために用いることができる。

図１０は、本発明の別の実施例によるコンテンツ配信システム１０００の少なくとも一部分を示している。本実施形態において、このシステムは、多くのＵＥに１又はそれ以上のネットワーク・ノードを介してメディア・ストリームを届けるためにメディア供給元１００２を備える。ＵＥによってメディア・ストリームの同期化された再生を可能とするために、各ＵＥ１００４―１００８がＢＳＣ１０１０―１０１６を備え、ＭＳＣ１０１８、１０２０はネットワーク１０２２内においてメディア供給元と各ＵＥの間のメディア経路上のどこかに位置する同期方式が実装される。

ＭＳＣは、メディア供給元からのメディア・ストリーム１０２４を受信し、また、このストリームをメディア・ストリーム１０２６―１０３０としてＵＥに転送する。この例では、メディア・ストリーム１０２４はマルチキャスト・ストリームとして配信することができる。ここでは、このマルチキャストされたメディア・ストリームはマルチキャスト・ホップにおいて３つのメディア・ストリーム１０２６―１０３０に分割される。ＭＳＣ１０１８、１０２０は、マルチキャスト・ストリームを異なるＵＥに届けるのに分割する必要がある位置に配置される。このような位置は、ｘＤＳＬネットワークのＤＳＬＡＭ又はケーブル・ネットワークのＣＭＴＳといったネットワークのエッジ・ノードとすることができる。

ネットワーク内のＭＳＣ及びＵＥのＢＳＣの使用は、ＭＳＣの位置からその特定にＭＳＣを通じて伝送されるメディア・トラフィックを受信する異なるＵＥへのメディアのトランスポート間であまり大きな遅延差がない場合には、ほぼ正常に実行することになる。例えば図１に示したような、大きな差が存在する場合には、このようなシナリオは、宛先間同期の目的で最適には実行しないことになる。

ＭＳＣ１０１８、１０２０は、メディア・ユニット到達時間の測定を実行することができ、これら測定された到達時間情報を同期ステータス情報１０３２、１０３４として同期サーバ（ＭＳＡＳ）１０３６にレポートすることができる。このＭＳＡＳは、全てのＭＳＣから全ての同期ステータス情報を収集することができる。この同期ステータス情報は、宛先間同期に必要となるメディア・ストリーム及びＵＥに関する。次いで、適切な同期設定指示を算出して、これら指示１０３８―１０４２を、それぞれＢＳＣを備えた異なるＵＥに送信する。なお、これは、宛先間同期に関わる全てのＵＥがネットワーク内の単一のＭＳＣの後方にある場合には、あまり役立たないことに注意されたい。

図１０に示すような同期方式は、２つの明確な利点を有する。第１の利点は、この方式が宛先官同期の目的のためにネットワークを移動するのに必要なメッセージをより少なくするという事実に関する。ＵＥがＭＳＣ及びＢＳＣの両方を備える場合（例えば図９Ａを参照のこと）には、全てのＵＥはそれら自身の同期ステータス情報メッセージを同期サーバに送信する。図１０に示される実施形態において、ネットワーク内の１つのＭＳＣは、多数ＵＥに代わって１つのステータス情報メッセージを送信ことができ、これにより、メッセージの数を著しく減少させることができる。全てのＵＥは、なおもそれらの自身の同期設定指示を受信することになるが、通例は、ステータス情報メッセージの数がより大きくなるか、少なくとも設定指示メッセージの数に等しくなるであろう。

ＵＥはＭＳＡＳにステータス情報メッセージを定期的に送信することができる。その結果、初期の同期の後に発生し得る同期欠如の経過を追うことができる。しかしながら、一旦、宛先間同期がある時点において実現され、及び、ネットワーク遅延がむしろ変動しない結果、メディア配信が実質的に同期を維持されたときには、更なる設定指示は必要でなくなる。何故ならば遅延の変更をなくすのはＢＣＳにより行われる必要があるからである。したがって、ネットワーク内にＭＳＣを配置することによってステータス情報メッセージの数を減らすことは、宛先間同期に関わるメッセージについてのより大きな部分の減少を提供できる。

図１０の同期方式と関連した第２の利点は、それが同期サーバ（ＭＳＡＳ）によって実行される処理量を削減するということである。ＭＳＡＳは、関連のある遅延設定指示を算出できるようにするために、特定の宛先間同期グループについての全ての同期ステータス情報メッセージを処理する必要があろう。より少数のステータス情報メッセージにより、算出はより複雑でなくなり、及び更に必要な処理はより少なくなるだろう。

図１１は、本願を他の同期タイプについてコンテキストで示したものである。宛先間同期の目的のために同期クライアントをＢＳＣ及びＭＳＣに分割する代わりに、図１１では、ストリーム間同期（即ち、リップ・シンク）の適用を示している。図１１は、メディア・ストリームの配信に関するケースを例示する。当該メディア・ストリームは、他の供給元からの追加のメディア・ストリームによって強化される。このような追加のメディア・ストリームの例示では、異なるオーディオ・ストリーム、例えばスポーツの試合の放送における異なる解説者、としてもよい。この異なるオーディオ・ストリームは異なる供給元で発生し、次いで、オリジナルのゲームをブロードキャストすることができるので、ストリーム間同期は別個に調整されなければならない。

この特定の状況において、ストリーム間同期は宛先間同期と同様の課題が懸念される。例えば、このオーディオは、オリジナルの放送に応答して作成することができる。このことは、オリジナルの放送を閲覧している人が、代替のオーディオ・ストリームを受信する前に相当な秒数にわたりビデオ・ストリームをバッファする必要があることを、意味する。更には、その機器は、再生機器が短い時間期間のみにわたり（例えば、１００ミリ秒のオーダーで（ジッタ）バッファするように通常構成されるように、延長された時間期間にわたりバッファするように構成しなくてもよい。別の課題は、この場合にはまた、チャネルが変更する遅延を非常に長くできるということにも関する。チャネル変更の後に代替のオーディオ・ストリームがビデオのタイミングと一致して利用可能となる前に、ビデオが数秒間バッファされる必要があるという状況は、チャネル変更遅延を利用可能でないものにする。

そのような状況において、ネットワーク内のＭＳＣ／ＢＳＣの複合を備える同期クライアントの使用は、適切な同期機能を提供しないだろう。このことは、ＭＰＥＧのような現在のビデオ・エンコード方式が異なるタイプのフレーム（例えばＩ―フレーム、Ｂ―フレーム及びＰフレーム）を使用するので、通常は、ビデオがオーディオよりも長い時間期間にわたりバッファリングを必要とするという事実に起因する。このようなビデオ・エンコード方式が双方向のエンコード方法に適用される場合には、エンコードするのに特定のフレームが初期フレーム、いくらかは将来のフレーム及びいくらかはその両方に依存することもある。したがって、多くのフレームが特定フレームを出コードするために必要とされ、バッファする必要があるこれらのフレームは、それらのフレームをデコードしないうちに開始することができる。したがって、これらの問題を解決するために、同期化方式が必要となり、そこでは、ＢＳＣ及びＭＳＣは、１又はそれ以上のメディア供給元及びＵＥの間のメディア経路に沿った別々の場所に位置する。

図１１は、１又はそれ以上のメディア・ストリームに関連付けられたメディア・ユニット到達時間情報についてレポートするために、ＭＳＣ１１０６を有するＵＥ１１０４を備えるホーム環境１１０２を示す。このＵＥは、ディスプレイ１１０８及びオーディオ出力デバイス１１１０に接続することができる。このＵＥは、ビデオ・ストリーム１１１２及び別個の関連するオーディオ・ストリーム１１１４を受信する。ビデオ及びオーディオ・ストリームの双方は、ビデオ及びオーディオ・ストリームのメディア経路内のネットワークに位置しオーディオ及びビデオ・ストリームをバッファするための別個のＢＳＣバッファ１１１８、１１２０を備えるＢＳＣ１１１６を通過することができる。このＢＳＣは、ネットワーク内のどこかに位置する２つの別個のメディア供給元１１２２、１１２４から、ビデオ・ストリーム及びオーディオ・ストリームを受信することができる。ＭＳＡＳ１１２６は、ＭＳＣからステータス情報レポート１１２８を受信し、このステータス設定レポートに基づいて同期設定指示１１３０を算出することができる。同期設定指示１１３０は、その後ＢＳＣに送信される。

ＵＥは、それ故、共に属するオーディオ及びビデオ・ストリームの場合には（ネットワーク内の異なるメディア供給元から発生することができる又はできない）、２又はそれ以上の別個のメディア・ストリームを受信する。宛先間同期を実行するために、ＵＥはＩＥＴＦ ＲＦＣ ３５５０に規定されたＲＴＣＰ送信機レポートを受信することができる。これらＲＴＣＰ送信機レポートは、メディア供給元からＵＥまで送信され、メディア・パケットが送信された（より具体的には、サンプルされた）時間と対応するＲＴＰメディア・ストリームについてのＲＴＰタイムスタンプとの間の関係を含むことができる。宛先間同期は、それ故、異なるストリームの異なるメディア・パケットが送信された（より具体的には、サンプルされた）時間をマッチングすることによって、及び異なるメディア・ストリームの対応するＲＴＰタイムスタンプを実質的に探すことによって、達成することができる。

ＭＳＡＳが遅延設定指示を算出することを可能にするために、それは、異なるストリーム間での相関時間を必要とする。ストリームが共に同一の供給元から送信されるか、又は関連したメディア・パケットについて同一のサンプリング時間を使用して送信される場合には、通常のＲＴＣＰ手順をなお適用する。その場合には、このＭＳＡＳは、ＭＳＣによって送信された同期ステータス情報においてレポートされるタイムスタンプを相関させるために、ＲＴＣＰ送信機レポートに収容される情報を必要とする。

タイムスタンプを相関されるためのこの情報は、さまざまな方法で、例えばＭＳＡＳにＲＴＣＰ送信機レポートをルーティングすることにより、取得することができる。例えば、このＵＥはＭＳＡＳにこの送信機レポートを転送することができ、又は、このネットワークはこの送信機レポートのコピーをＭＳＡＳに送信することができる。この情報を得るための他の方法は、ＲＴＣＰメッセージのシグナリング経路内にネットワークのＭＳＡＳを配置することによるものである。このことは、例えば、ＢＳＣを有するＭＳＡＳを共に配置することによって達成できる。

異なるメディア・ストリームが同一の供給元から発生するか、又は関連したメディア・パケットについて同一のサンプリング時間を使用しない場合には、ＭＳＡＳはオーディオ・ストリーム及びビデオ・ストリームに関連付けられたステータス情報レポートのタイムスタンプ間の相関に関する情報をなおも必要とする。一実施形態において、相関情報は、例えば両方のストリームを呈示する何者か、及び遅延を手動で変えることができる何者かによって手動で供給し、同期を達成することができる。一旦同期が達成されると、手動で導かれた遅延をレポートし、ＭＳＡＳに送信することができる。別の実施例では、メディア・パケットの供給元は、同期ステータス情報のタイムスタンプ間の相関について供給することができる。例えば、第２のメディア・ストリームが別の第１のメディア・ストリームに応答して作成される場合には、その第２メディア・ストリームの供給元は、第２メディア・ストリームのサンプリング時間と（第２メディア・ストリームの供給元によって受信されるＲＴＣＰ送信機レポートに収容される）第１メディア・ストリームのそれとの間の相関についてレポートすることができる。

このコンテキストでは、他の課題もまた発生する。オーディオ及びビデオ・ストリームが別個のＵＥによって受信する場合には、これらのＵＥは、メディア・パケット到達時間が各ＵＥによってレポートされたことを認識していないので、ストリーム間同期を実行することができない。しかしながら、ＢＳＣがネットワーク内に位置する場合には、ＵＥは双方ともＭＳＣを備えることができ、到達時間についてＢＳＣにレポートすることができる。次いで、ＢＳＣは、異なるＵＥを代表してストリーム間同期を達成するために、必要なバッファリングを実行することができる。

図１２は、本発明の一実施例による分散同期システムを備えるメディア配信ネットワークを示している。このような分散アーキテクチャの導入により、いくらか利点を供することができる。例えば、遅延差は、メディア配信のネットワーク経路のさまざまな部分で生じることもある。したがって、遅延の差の発生源に依存して、異なる場所での遅延を補償することは有利なものとなる。更に、メディア経路の下り方向のあらゆるＵＥ又はネットワーク・ノードが同期機能性を提供することができるかについては、前もって知られていない。ネットワーク内の異なるノードにおいて同期化機能を導入ことにより、最善の同期化は、異なるネットワーク・ノードの所与の同期能力を達成することができる。更には、ＵＥ上の宛先間同期が最終的に達成できる場合であっても、チャネル変更時間は、メディア・ストリームがネットワーク内である程度同期される場合には、より低いものとなる。

図１２は、全てのＵＥ１２０２―１２０８がメディア・ストリーム１２１０を受信している概要を示している。これらＵＥは、あるネットワーク・ノード１２１２、１２１４、例えばネットワーク１２１６、１２１８のエッジ・ノードに接続される。これらＵＥの各々は、同期ステータス情報１２２０、１２２２をＭＳＡＳ１２２４、１２２６に送信する。これらＭＳＡＳは、遅延設定指示１２２８、１２３０を算出することができ、これらをネットワーク・ノード１２１２、１２１４に送信することができる。このことは、ＵＥが（ローカルに）同期されることを可能にする。

異なるネットワーク・ノード１２１２は、また、メディア・ストリーム１２１０を同期外(out of sync)で受信することもできる。ＭＳＣ及びＢＳＣ機能性を含む完全な宛先間同期がＵＥ上で実行される場合であっても、これらのネットワーク・ノードを少なくとも同期させることはまた有利となり得る。ネットワーク・ノード１２１２のうち１つが特定のメディア・ストリームについて他方のネットワーク・ノードに対して１秒の遅れていると仮定する。ネットワーク・ノードについての同期化がない場合、他の全てのネットワーク・ノードの後方にあるあらゆるＵＥもが、宛先間同期を達成するために、この１秒にわたりバッファしなければならないだろう。これらのネットワーク・ノード１２１２上の差をバッファリングすることで、これらのＵＥのチャネル変更時間はその１秒によって減らす。他の利点としては、ＵＥ１２０２、１２０４のいくつかが宛先間同期を実行することができない場合に、メディア・ストリーム１２１０をなおも受信するであろう。

ネットワーク・ノード１２１２は、同期ステータス情報１２３２を更なるＭＳＡＳ１２３４に送信することができる。更なるＭＳＡＳ１２３４は、更なる同期設定指示１２３６を算出し、ＢＳＣを収容するネットワーク・ノード１２３８に送信することができる。メディア経路でのネットワーク・ノードでのバッファリングの利点は、バッファ・メモリの総容量が削減されるということである。即ち、異なるネットワーク・ノード１２１２は、ネットワーク・ノード１２３８に収容されるバッファを共有することができる。加えて、メディア・ストリームのダウンストリーム経路上のあらゆるノード（ネットワーク・ノード又はＵＥ）が、宛先間メディア同期についてバッファリングを実行することができない場合には、このメディア・ストリームはなおもある程度同期することができる。

これら異なる宛先間同期は、異なるレベルで発生することができる。 ネットワーク１２１２において、ネットワーク・ノード１２１２は、ノード１２３８のネットワーク内で内部的に同期され、そして、ネットワーク１２１８において、ネットワーク・ノード１２１４はネットワーク階層においてより高い、更に別のネットワーク・ノード１２４０を用いることで同期される。より高いネットワーク階層では、ノードは、メディア・ストリームの経路ではより早いことを意味する。この例では、同期ステータス情報１２４２をＭＳＡＳ１２４４に送信することによって、コア・ネットワーク・ノード１２３８が同期される。このＭＳＡＳ１２４４は、同期設定指示１２４６を算出し、ＢＳＣを備えるネットワーク・ノード１２４０に送信することができる。このネットワーク・ノード１２４０は、例えば、メディア・ストリームを異なるネットワーク及びネットワーク運用業者に届けるための配信ポイントでもよい。しかし、ネットワーク１２１８からは、エッジ・ノード１２１４はまた、同期ステータス情報１２４８をＭＳＡＳ１２４４に送信し、これによって、ネットワーク・ノード１２４０内で同一のＢＳＣを使用する。

如何なる一つの実施形態に関して記載した如何なる特徴も、単独で、又は記載した他の特徴と組み合わせて使用することができ、また、如何なる他の実施形態の１又はそれ以上の特徴と組み合わせて使用することができ、又は、如何なる他の実施形態の如何なる組み合せで使用することができることを理解すべきである。本発明の一実施形態は、コンピュータ・システム用のプログラム製品として実施することができる。このプログラム製品におけるプログラムは、実施形態（本願明細書において説明した方法を含む）の機能を定義して、また、様々なコンピュータ可読記憶媒体上に収容することができる。コンピュータ可読記憶媒体の例示は、以下を含むが、これに限定されるものではない。即ち、（ｉ）情報が永続的に格納される非書込可能な記憶媒体（例えば、ＣＤ―ＲＯＭドライブ、フラッシュ・メモリ、ＲＯＭチップ又は如何なるタイプのソリッド・ステート不揮発性半導体メモリによって読み取り可能なＣＤ―ＲＯＭディスクのようなコンピュータ内のリードオンリー・メモリ・デバイス）、及び（ｉｉ）変更可能な情報が格納される書込可能な記憶媒体（例えば、ディスケット・ドライブ若しくはハードディスク・ドライブ内のフロッピー（登録商標）ディスク、又は如何なるタイプのソリッド・ステート・ランダム・アクセス半導体メモリ、である。

更に、本発明は、ＩＭＳに限定されず、ソフト・スイッチ設計に基づいて実施することもできる。これにより、基本ユーザ加入機能、ＩＰセッション管理及び特定のＶｏＩＰサービス機能が、完全に、又は部分的にネットワーク内の１又はそれ以上の信頼性のあるアプリケーション・サーバ内で統合される。更に、３ＧＰＰのＬｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ（ＬＴＥ）又は３ＧＰＰのＳｅｒｖｉｃｅ Ａｒｃｈｉｔｅｃｔｕｒｅ Ｅｖｏｌｕｔｉｏｎ（ＳＡＥ）のネットワークのような他のサービス提供ネットワークを用いて本発明の実施がまた予見される。更に、本発明は上記の実施形態に限定されなず、添付の特許請求の範囲の範囲内で変形することができる。

Claims (16)

1. 第１のメディア・ストリーム及び第２のメディア・ストリームを同期する方法であって、前記第１メディア・ストリーム及び前記第２メディア・ストリームがネットワーク内の少なくとも１つのメディア供給元によって第１のメディア経路及び第２のメディア経路を通じて１又はそれ以上の端末に伝送され、前記方法が、
   前記第１メディア経路及び前記第２メディア経路における第１の場所に位置する測定モジュールを用いて、前記第１メディア・ストリーム及び前記第２メディア・ストリーム内のメディア・パケットの到達時間に関連付けられるタイミング情報を測定するステップと、
   前記ネットワークにおいて、前記タイミング情報に基づいて少なくとも１つのバッファについてのバッファ指示を生成するステップであって、前記バッファが前記第１メディア経路及び前記第２メディア経路のうち少なくとも１つにおける第２の場所に位置するステップと、
   前記１又はそれ以上の端末におけるメディア・パケットの到達時間が実質的に同期されるように、前記メディア経路を通じて前記１又はそれ以上の端末に伝送される１又はそれ以上のメディア・パケットを遅延させるステップと、
   を含む、方法。
2. 請求項１に記載の方法において、前記第１メディア経路が前記メディア供給元及び第１の端末の間に設けられ、前記第２メディア経路が前記メディア供給元と第２の端末の間に設けられる、方法。
3. 請求項１又は２に記載の方法において、前記測定モジュールが、前記１又はそれ以上の端末に位置するか、前記１若しくはそれ以上の端末を前記ネットワークに接続する１若しくはそれ以上のアクセス・ラインに沿った位置に配置され、並びに／又は前記バッファが前記ネットワーク内、好ましくは境界ネットワーク・ノード及び／若しくはアクセス・ネットワーク・ノードに位置する、方法。
4. 請求項１から３のいずれかに記載の方法において、前記バッファ指示が、同期サーバ好ましくはメディア同期サーバによって生成され、前記測定モジュール及び前記バッファが、同期測定クライアント及び同期バッファリンング・クライアントとしてそれぞれ構成され、前記方法が、更に、
   タイミング情報を前記同期測定クライアントから受信するステップと、
   バッファ指示を前記同期バッファリング・クライアントに伝送するステップと、
   を含む、方法。
5. 請求項４に記載の方法において、前記バッファ指示が、１若しくはそれ以上の同期設定指示レポート、好ましくはＲＴＣＰ同期設定指示レポートにより前記同期バッファリング・クライアントに送信され、及び／又は前記タイミング情報が１若しくはそれ以上の同期ステータス情報レポートにより前記同期サーバに送信される、方法。
6. 請求項５に記載の方法において、前記同期ステータス情報レポートが前記同期バッファリング・クライアントを介して前記同期サーバに送信される、方法。
7. 請求項６に記載の方法において、前記同期バッファリング・クライアントは、１つの端末から前記同期サーバに送信される同期ステータス情報レポートを修正するように構成され、及び／又は前記同期バッファリング・クライアントは、同期設定指示レポートを端末に転送するように構成される、方法。
8. 請求項１に記載の方法において、前記第１メディア経路が第１メディア供給元及び１つの端末の間に設けられ、前記第２メディア経路が前記第１メディア供給元又は更なる第２のメディア供給元と前記端末との間に設けられる、方法。
9. 請求項１に記載の方法において、前記第１測定モジュールがネットワーク・ノード、好ましくは境界ネットワーク・ノード及び／又はアクセス・ネットワーク・ノードに位置し、前記バッファが前記１又はそれ以上の端末に位置するか、前記１又はそれ以上の端末を前記ネットワークに接続する前記１又はそれ以上のアクセス・ラインに沿った位置に配置される、方法。
10. 請求項１から９のいずれか一項に記載の方法において、前記１又はそれ以上の端末のうち少なくとも１つが、メディア・ストリームにおける前記メディア・パケットの到達時間の変動を測定し、前記到達時間に基づいて変動がバッファリング・ポイントから生じた遅延に関係するかについて判定するように構成される、方法。
11. 請求項１から９のいずれか一項に記載の方法において、前記バッファ・ポイントが可変遅延バッファを含み、当該可変遅延バッファが前記ネットワークから受信した遅延指示に基づいてメディア・ストリームを遅延させるように構成され、前記遅延が０．５秒と１０秒との間、好ましくは１秒と５秒との間で選択され、及び／又は前記バッファが該バッファに接続される２又はそれ以上の端末の間で共有される、方法。
12. 第１のメディア・ストリーム及び第２のメディア・ストリームを同期するシステムであって、
    第１のメディア・ストリーム及び第２のメディア・ストリームを第１のメディア経路及び第２のメディア経路を通じて１又はそれ以上の端末に伝送する少なくとも１つのメディア供給元と、
    少なくとも１つの測定モジュールが受信する前記第１メディア・ストリーム及び前記第２メディア・ストリーム内のメディア・パケットに関連付けられるタイミング情報を測定する当該少なくとも１つの測定モジュールであって、前記第１メディア経路及び前記第２メディア経路における第１の場所に位置する、測定モジュールと、
    メディア経路を通じて前記１又はそれ以上の端末に伝送されるメディア・パケットを、遅延指示に基づいて遅延させるように構成される少なくとも１つのバッファであって、前記バッファが前記第１メディア経路又は前記第２メディア経路のうち少なくとも１つにおける第２の場所に位置するバッファと、
    前記１又はそれ以上の端末におけるメディア・パケットの到達時間が実質的に同期されるように、前記タイミング情報に基づいて前記少なくとも１つのバッファについてのバッファ指示を生成する同期サーバと、
    を備える、システム。
13. 請求項１２に記載のシステムで使用するためのバッファ・モジュールであって、好ましくは同期バッファリング・クライアントであり、メディア経路を通じて端末に伝送されるメディアを、バッファ指示に基づいて遅延させるように構成され、前記バッファ・モジュールが、
    可変遅延バッファと、
    バッファ指示を受信する受信機であって、前記バッファ指示が前記可変遅延にメディア・ストリームを遅延させる情報を所定の遅延期間にわたり提供する受信機と、
    １又はそれ以上の遅延したメディア・ストリームを１又はそれ以上の端末に伝送する送信機と、
    任意に、ポインタ情報を含むバッファ・リストであって、該ポインタ情報が前記バッファ・モジュールに２又はそれ以上の端末間で前記可変遅延バッファにおける前記メディア・パケットを共有させる、バッファ・リストと、
    を備える、バッファ・モジュール。
14. 請求項１２に記載のシステムで使用するための同期サーバであって、
    １又はそれ以上のメディア・ストリーム内のメディア・パケットの到達時間に関連付けられたタイミング情報を受信する受信機と、
    バッファ指示を生成するように構成されるプロセッサであって、該バッファ指示が前記タイミング情報に基づいて算出される遅延情報を含む、プロセッサと、
    前記バッファ指示を少なくとも１つのバッファに伝送するための送信機と、
    を備える、同期サーバ。
15. メディア再生のための端末であって、請求項１２に記載のシステムにおいて使用されるように構成され、前記端末が、
    前記端末が受信するメディア・パケットの到達時間に関連付けられたタイミング情報を測定するための測定モジュールと、
    タイミング情報を前記ネットワーク内の同期サーバに伝送するための送信機と、
    任意に、メディア・ストリーム内のメディア・パケットの前記到達時間の変動を測定し、該測定に基づいて、変動がバッファリング・ポイントから生じた遅延に関係するかについて判定するように構成される測定ユニットと、
    を備える端末。
16. コンピュータ上でランするときに、請求項１から１１のいずれか一項に記載の方法を実行するように構成されるソフトウェア・コード部を含む、コンピュータ・プログラム。

Images