JP5788473B2 - 端末の出力を同期させる方法およびシステム - Google Patents

Description

本発明は、端末の出力を同期させる方法およびシステムに関するものである。更に、本発明は、このようなシステムにおいて用いるための同期ユニットおよび端末に関するものである。

従来技術

ボイス・オーバーＩＰ（ＶｏＩＰ）やインターネット・プロトコル・テレビジョン（ＩＰＴＶ）のような新たなマルチメディア技法が、新たなマルチメディア・サービスの範囲を全体にまで押し広げた。このようなサービスの一種では、ユーザのグループが、直接通信のための別個のリアル・タイム通信チャネル（例えば、ＶｏＩＰ）を用いて互いにテキスト、オーディオおよび／またはビデオを通じて通信しつつ、同じＴＶチャネルを別個に見ることを可能にする。このようなサービスでは、端末の出力信号を、グループ内の全てのユーザに同時に送信して、各ユーザが同時に特定のＴＶの瞬間（例えば、生のサッカー試合）を体験できるようにすることが必要となる。言い換えると、グループにおける表示装置、例えば、テレビジョン、ＰＤＡ、ＰＣ、またはその組み合わせの出力との同期を取らなければならない。

ＩＰＴＶシステムでは、ＴＶチャネル信号は、通例、１つ以上のパケット化ストリームとして、運用業者の高帯域幅ＩＰネットワークを通じて、エッジ・ルータおよびアクセス・ノードを経由して、このようなサービスの加入者の端末に送信される。ストリームの送信中、パケットには、送信遅延、ネットワーク経路の相異、および符号化および復号化遅延の差というような、ネットワークにおける未知の遅延が生ずる。その結果、１つの端末において受信されるオーディオおよびビデオ・ストリームのパケットと、他の端末において受信したそれらのパケットとの間における時間的関係が乱されることになる。

ＩＰＴＶコンテンツを端末に向けてストリーミングする際、通常、リアル・タイム・トランスポート・プロトコル（ＲＴＰ）が用いられる。ＲＴＰは、シーケンス付番(sequence numbering)およびタイム・スタンプ付与(time stamping)を行う。ＲＴＰを用いると、１つのストリームにおける時間的関係（ストリーム内同期）および関連するストリーム間の関係（ストリーム内同期）を再現することができる。

グループ同期または宛先間同期を達成するためには（先に示したサービスに必要となる）、更に別の対策が必要となる。様々な技法が知られているが、これらは全て端末においてタイム・スタンプ付与および可変遅延バッファを用いる。可変遅延バッファは、ある時間量だけストリームを遅延させることができる。

"An Application-Level QoS Comparison of Inter-Destination Synchronization Schemes for Continuous Media Multicasting"（連続メディア・マルチキャスティングのための宛先間同期のアプリケーション・レベルにおけるＱｏＳ比較）と題するNunome et al.による論文（IEICE trans. Commun. vol. 87, 2004, pp. 3057-3067）において、２種類の宛先間同期方式が記載されている。第１の種類は、中央同期マスタを用い、この中央同期マスタが、グループの中にある全ての端末からタイミング情報を収集し、制御パケットをこれらの端末に配信することによって、出力タイミングを調節する。第２の種類は、分散制御方式に関し、各端末が全てのタイミング情報を、グループ内にある全ての他の端末にマルチキャストする。しかしながら、典型的なＩＰＴＶシステムにおいてこのような方式を実施すると、ある種の問題が発生する。これらの方式に関する１つの問題は、ストリームの宛先間同期に先だって全てのローカル・クロックを同期させる、絶対クロックまたは中央クロックが必要になることである。このようなローカル・クロックの同期は、実際には達成することが難しい場合もある。先行技術に関する更に別の問題に、スケーラビリティの点で限界がある。同期制御パケットは、専用マルチキャスト・チャネルを用いて配信されるが、リソースに限界があり、中央同期マスタはある一定数の端末しか処理できない場合がある。

ＩＰＴＶシステムにおいてグループ同期を達成する方法の１つは、運用業者のネットワークにおいて、ネットワーク・ノードの同期を取り、端末、例えば、セット・トップ・ボックスによって、これらの同期されたネットワーク・ノードに接続されている全ての視聴者が、ブロードキャストされた番組を同時に視聴することができるようにすることである。こうすると、端末は、個々のサービスがグループ同期を必要とするか否かには関係なく、常に同期状態にある。この解決策は、関連するヨーロッパ特許出願第０７０２０７３７．８号に記載されており、ネットワークにおけるネットワーク・ノードの適合を必要とする。

プロバイダの既存のネットワーク・インフラストラクチャを変更することなく、個々のサービスに対してグループ同期を取ることが望ましい。

本発明の目的は、先行技術において分かっている欠点の少なくとも１つを低減または解消すること、そして本発明の第１の態様において、少なくとも２つの端末の出力を同期させる方法を提供することである。この方法は、端末と同期ユニットとの間に１つ以上の低遅延通信チャネルを設けるステップと、同期ユニットが、１つ以上の低遅延通信チャネルを通じて端末から受信した同期情報に基づいて、遅延情報を計算するステップと、遅延情報を端末の少なくとも１つに送信し、端末の出力を実質的に同期させるように、当該少なくとも１つの端末がその出力を遅延させるステップとを備えている。

本発明は、ユーザのグループが同じＴＶ番組を見つつ、互いにテキスト、オーディオ、および／またはビデオを通じて通信することを可能にするサービスのある一定のグループが、しばしば、別個の高品質、低遅延通信チャネルを通信のために用いることがあるという知見に基づいている。つまり、低遅延通信チャネルは、ユーザのグループの端末と１つ以上の同期ユニットとの間において同期情報を交換するための、非常に効率的で比較的高速の接続を提供する。本発明による方法を用いることによって、このような低遅延接続は、メディア・ストリームの宛先間同期に先立つ、端末のローカル・クロックの同期のために絶対クロックを用いることを不要とする。更に、本方法は、ある種のＩＰＴＶサービスにおいてグループ同期に備えるための簡単で低コストの解決策を提供する。この解決策は、プロバイダ・ネットワークのインフラストラクチャの改変を必要としない。本方法は、実際にはグループ同期を必要とするような端末を同期させるだけでよい。

一実施形態では、本発明による方法によって定められるステップを同期ユニットによって実行する。

更に別の実施形態では、各端末は、マルチメディア信号を受信する入力と、マルチメディア信号を情報プレゼンテーション・ユニットに送信する出力とを備えており、各端末は、出力信号を遅延させる可変遅延ユニットを備えており、本方法は、更に、マルチメディア・ストリームを端末の入力に送信するステップであって、好ましくは、マルチメディア・ストリームがメディア・ユニットを含む、ステップと、受信した遅延情報にしたがって、出力信号を遅延させるステップとを備えている。

可変遅延ユニット（バッファ）を有する端末を用いると、各端末は出力を個々に(locally) 遅延させることができる。これには、運用業者のネットワーク全体において、全てのストリームの経路に可変遅延バッファを装備する必要はないという利点がある。

更に別の実施形態では、本方法は、更に、各端末が同期情報を、好ましくは、同期要求に応答して、同期ユニットへの低遅延通信チャネルを通じて送るステップを備えており、同期情報は、マルチメディア・ストリーム内におけるメディア・ユニットの位置を表すメディア・ユニット基準（ＭＵＲ）情報を備えている。

更に別の実施形態では、ＭＵＲ情報は、フレーム番号またはシーケンス番号を含む。

低遅延チャネルの使用のために、同期ユニットが同期情報を受信する時刻は、端末が同期情報を判定し送った時刻と実質的に同じとなる。したがって、先行技術の技法のように、ローカル・クロックはもはや同期情報と共に受信したメディア・ユニットの時間（タイム・スタンプ）情報を提供する必要はなく、端末のローカル・クロックを同期させる必要ももはやない。したがって、ストリームにおけるメディア・ユニットの相対的な位置に関する情報（ＭＵＲ情報によって表される）のみが、端末から要求されることになる。

更に別の実施形態では、本方法は、更に、端末から受信したＭＵＲ情報に、１つ以上のタイム・スタンプを付加するステップと、端末が受信したマルチメディア・ストリームのフレーム・レートに関する情報を提供するステップと、フレーム・レート情報およびタイム・スタンプが付加されたＭＵＲ情報に基づいて、端末毎に遅延情報を計算するステップと、遅延情報を端末の内少なくとも１つに送るステップとを備えている。

タイム・スタンプをＭＵＲ情報に追加することにより、そしてストリーム（群）のフレーム・レート（群）を供給されることによって、同期ユニットは、同期に関与する各端末について遅延情報（該当する遅延）を計算することができる。これらの遅延は最も遅いストリーム（端末）に対する相対的なものであるので、同期に関与する端末が２つだけの場合、一方の端末だけに遅延情報を提供すればよく、他方の端末を基準と見なす。

一実施形態では、本方法は、更に、同期ユニットが同期要求を、好ましくは同時に、１つ以上の低遅延通信チャネルを通じて端末に送るステップと、端末が受信したマルチメディア・ストリームのフレーム・レートに関する情報を提供するステップと、フレーム・レート情報およびＭＵＲ情報に基づいて、端末毎に遅延情報を計算するステップと、遅延情報を端末の内少なくとも１つに送るステップとを備えている。

同期プロセスは、端末が開始しても、同期ユニットが開始してもよい。後者の場合、同期ユニットは、関与する端末に、同期要求を送る。要求が関与する端末全てに同時に低遅延チャネルを通じて送られ、結果（ＭＵＲ情報）が直ちにこれらの端末から同期ユニットに低遅延チャネルを通じて返送された場合、全ての結果は実質的に同じ時刻に到達する。その結果、要求される同期レベルに応じて、タイム・スタンプを付加するステップを削除してもよく、遅延情報の計算においてはもはや不要となる。これには、クロックの使用およびタイム・スタンプを付与する手段がもはや同期ユニットには不要であり、プロセスや用いられる機器を一層簡素かつ一層効率的にすること利点を有する。

更に別の実施形態では、同期情報を同期ユニットに送信するために用いられる低遅延通信チャネルは、通信セッションまたはブロードキャスト・セッション、更に好ましくは、ＥＴＳＩ ＴＳ １８２ ０２７において定められているブロードキャスト・セッションの一部として確立される。

これには、本発明による方法を実行する際に、既存のネットワーク・リソースの使用効率を高めるという利点がある。

更に別の実施形態では、低遅延通信チャネルは、ボイス・オーバーＩＰ（ＶｏＩＰ）チャネルや、ＧＳＭ、ＵＭＴＳまたはＬＴＥネットワーク上におけるＵＳＳＤベース・チャネルや、ＩＭＳセッションにおけるＱｏＳ制御チャネルや、通信セッションまたはブロードキャスト・セッションにおける専用チャネルや、専用イーサネットＶＬＡＮチャネルや、専用ＭＰＬＳチャネルや、またはＩＰディフサーブ・ストリームによって用いられる専用チャネルである。

一実施形態では、同期情報は、低遅延通信チャネルと関連のあるＳＩＰセッション内におけるストリームによって搬送される。別の実施形態では、同期情報は、低遅延通信チャネルと関連のあるＲＴＰプロトコルによって搬送されるか、あるいはオーディオ、ビデオ、および／またはテキストのＲＴＰストリームと関連のあるＲＴＣＰプロトコルによって搬送されるか、あるいはオーディオ、ビデオ、および／またはテキストのコデック（群）によって搬送される。

本方法は、端末が接続されているグループの中にあるこれらの端末間において低遅延通信チャネル（またはセッション）を設定し維持するために用いられるプロトコルによって、同期情報を搬送することを可能にする。言い換えると、グループ同期に備える１つ以上のプロトコルを、低遅延通信チャネルを設定し維持するために用いられるプロトコルの上にピギーバック(piggyback)されているのである。

同期ユニットは、サーバ内、好ましくは、ＳＩＰベース・アプリケーション・サーバ内に配置することができ、あるいは、別の実施形態では、同期ユニットを第１端末および／または第２端末内に配置することもできる。

別の実施形態では、第１端末および第２端末は、それぞれ、第１同期ユニットおよび第２同期ユニットを備えており、各端末は、メディア・ユニット基準情報を他方の端末に伝達する手段を備えており、前述の方法は、更に、（ｉ）第１同期ユニットが、低遅延通信チャネルを通じて、第２同期ユニットが送信した第２メディア・ユニット基準情報を受信するステップと、（ｉｉ）第２同期ユニットが、低遅延通信チャネルを通じて、第１同期ユニットが送信した第１メディア・ユニット基準情報を受信するステップと、（ｉｉｉ）第１同期ユニットおよび第２同期ユニットが、第１メディア・ユニット基準情報および第２メディア・ユニット基準情報に基づいて、第１遅延および第２遅延をそれぞれ計算し、端末のグループの出力が実質的に同期するように、第１端末および第２端末の中にある可変遅延ユニットが送信を遅延することを可能にするステップとを備えている。

このように、各端末は同期ユニットを備えており、こうして、各端末はそれ自体によって遅延情報を決定することが可能となる。

別の態様において、本発明は、少なくとも２つの端末の出力を同期させるシステムに関するものである。このシステムは、１つ以上の低遅延通信チャネルを通じて少なくとも２つの端末に接続されている同期ユニットを備えており、同期ユニットは、端末から１つ以上の低遅延通信チャネルを通じて受信した同期情報に基づいて遅延情報を計算し、この延情報を端末の少なくとも１つに送信することにより、端末の出力を実質的に同期させるように、各端末にその出力を遅延させるように構成されている。

本システムの一実施形態では、各端末は、マルチメディア信号を受信する入力と、マルチメディア信号を情報プレゼンテーション・ユニットに送信する出力と、遅延情報にしたがって出力信号を遅延させる可変遅延ユニットを備えており、本システムは、更に、マルチメディア・ストリームを端末に送信する局(station)を備えており、マルチメディア・ストリームがメディア・ユニットを含む。

更に別の態様において、本発明は、前述のシステムにおいて用いるための同期ユニットに関するものである。このユニットは、端末から同期情報を１つ以上の低遅延通信チャネルを通じて受信する受信機と、受信した同期情報に基づいて、遅延情報を計算するように構成されているプロセッサと、遅延情報を端末の内少なくとも１つに送信する送信機とを備えている。

一実施形態では、この同期ユニットは、サーバ、好ましくは、ＳＩＰサーバ内、第１端末および／または第２端末内、あるいはコンフェレンス・ブリッジ(conference bridge)に配置されている。

更に別の実施形態では、本発明は、前述のシステムにおいて用いるための端末に関するものである。この端末は、同期ユニットから同期要求を受信するように構成されており、更にマルチメディア・ストリームを受信するように構成されている、受信機と、１つ以上の低遅延通信チャネルを通じて同期ユニットに送信するように構成されており、更にマルチメディア信号を情報プレゼンテーション・ユニットに送信するように構成されている、送信機と、マルチメディア信号の情報プレゼンテーション・ユニットへの送信を遅延させる可変遅延ユニットとを備えている。

有利な実施形態では、本発明による端末は、更に、同期情報に基づいて遅延情報を計算するように構成されている同期ユニットを備えている。これによって、中央管理同期ユニットの必要性を解消し、同期サービスが運用業者によって提供されていないネットワーク環境においても用いることができる。

実施形態例では、前述の端末は、セット・トップ・ボックス、家庭用コンピュータ、移動体デバイス、またはゲーム・コンソールである。

本発明は、更に、１つ以上の計算デバイス、好ましくは、１つ以上のネットワーク・サーバまたは端末のメモリにおいて実行させると、前述した発明の方法ステップを実行するように構成されているソフトウェア・コード部を備えている、コンピュータ・プログラム製品に関するものである。

添付図面を参照して、本発明について更に例示する。添付図面は、本発明による実施形態を模式的に示す。尚、本発明は、これら具体的な実施形態にはいかようにも限定されないことは言うまでもない。

図１は、中央同期システムの実施形態例を示す。 図２は、３つの端末と中央同期ユニットとを備えている、本発明によるシステムにおける情報のフローを示す。 図３は、分散システムの実施形態例を示す。 図４は、同期セッションの実施形態例を示す。 図５は、本発明を実現するように構成されたシステムのアーキテクチャ例を示す。 図６は、本発明を実現するように構成されたシステムのアーキテクチャ例における情報のフローを示す。

図１は、本発明の第１実施形態によるシステム１００を示す。このシステムは、ブロードキャスト局（ＢＳ）１０２、例えば、ＩＭＳ型アーキテクチャを有するＩＰＴＶシステムを備えることが好ましい。ＩＰＴＶシステムは、マルチメディア・コンテンツを運用業者のネットワーク１０６、例えば、高帯域ＩＰネットワークを通じて、多数のアクセス・ノードに送信する。アクセス・ノードの例には、ディジタル加入者線アクセス・マルチプレクサ（ＤＳＬＡＭ）、ケーブル・モデム終端システム（ＣＭＴＳ）、光アクセス・ノード、またエッジ・ルータが含まれる。

マルチメディア・コンテンツは、１つ以上のマルチメディア・ストリーム１０４によって、アクセス・ノードに送信することができる。通例、マルチメディア・ストリームは、多数のメディア単位、即ち、トランスポート・プロトコルによって用いられるデータの基本単位に分割され、コンテンツを１つ以上のパケット交換ネットワークを通じてノードに伝送する。一実施形態では、マルチメディア・ストリームは、パケット化された（ＭＰＥＧ）トランスポート・ストリームとすることができる。

ストリーム内にあるオーディオ、ビデオ、および／またはテキスト・コンテンツは、例えば、ＭＰＥＧ−２、ＭＰＥＧ−４、またはその他の適したマルチメディア・データ圧縮技法を用いて圧縮することもできる。更に、リアル・タイム・トランスポート・プロトコル（ＲＴＰ）およびリアル・タイム・トランスポート制御プロトコル（ＲＴＣＰ）のようなトランスポート・プロトコルも、ＩＰＴＶコンテンツをネットワークを通じてストリーミングするために用いることができる。ＲＴＣＰは、ＲＴＰフローに対して帯域外制御情報を提供する。ＲＴＰによって提供されるサービスは、シーケンス付番、タイム・スタンプ付与、および配信監視を含み、１つのストリームの中にある連続フレームが正しい時点でそして正しい時間間隔で再生されるように、１つのストリームの中にあるパケットの同期、および関連するストリーム・パケット間の同期を可能にする。

各アクセス・ノードは、１組の端末１０８ａ、１０８ｂに接続されている。各端末は、１つ以上の情報プレゼンテーション・ユニット１１６ａ、１１６に接続されている。一実施形態では、端末は、情報プレゼンテーション・ユニットに接続されている条件付きアクセス・ユニット、例えば、セット・トップ・ボックス等とすることができる。別の実施形態では、端末は、情報プレゼンテーション・ユニットの中に配置されたハードウェア・ユニットまたはハードウェア／ソフトウェアを組み合わせたユニットとすることもできる。これら１組の端末は、１つ以上のＩＰＴＶサービスを配信することができる端末グループを形成する。情報プレゼンテーション・ユニットは、テレビジョン、パーソナル・コンピュータ、パーソナル・ディジタル・アシスタント（ＰＤＡ）、またはマルチメディア・コンテンツをユーザに提示することができるのであれば他のいずれのデバイスでもよい。この端末は、インターネット・グループ管理プロトコル（ＩＧＭＰ）を用いて、アクセス・ノードに、マルチメディア・ストリームにおける１つのＴＶチャネルを端末に送信するように要求することができる。

本発明による方法の第１ステップでは、ユーザの端末間において通信セッションを確立する。この通信セッションは、１つ以上の低遅延通信チャネル１１０ａ、１１０ｂを備えており、特定のサービスによって設定される。特定のサービスは、サービスのユーザ間にリアル・タイムの通信を提供しつつ、同時に、全てのユーザは同じＴＶ番組を実質的に同期して視聴することができる。

サービス品質（ＱｏＳ）要件のために、このような通信セッションは、音声、ビデオ、および／またはテキスト・データを交換するために１つ以上の低遅延通信チャネルを用いる。固有の(intrinsic)低遅延通信チャネルは、運用業者が制御するネットワークによって得ることができ、このネットワークでは、ベスト・エフォートのＱｏＳを提供する代わりに、個々のトラフィック・フローに優先順位を付ける。例えば、このようなネットワークでは、ボイス・オーバーＩＰチャネルは、約１５０ｍｓのＱｏＳ劣化を伴わずに、最大の容認可能な（ワン・ウェイ）レイテンシを有することができる。低遅延通信チャネルの他の例には、ＱｏＳ制御ＩＭＳセッションがあり、専用のイーサネット仮想ＬＡＮ（ＶＬＡＮ）、専用の多重プロトコル・ラベル・スイッチング（ＭＰＬＳ：Multi Protocol Label Switching）経路、または専用のＩＰディフサーブ(Diffserv)ストリームを用いて確立することができる。あるいは、低遅延通信チャネルは、パケット化ストリームのチャネルとは完全に独立したトランスポート・インフラストラクチャを用いることもできる。例えば、移動体ＴＶの想定場面では、ＤＶＢ−Ｈを通じてストリームを受信し、低遅延通信チャネルが無構造化補足サービス・データ（ＵＳＳＤ：Unstructured Supplementary Service Data）またはその他の低遅延チャネルによってＧＳＭ／ＵＭＴＳネットワークを通じて提供される。このような低レイテンシ通信チャネルは、通例、ＴＶ信号、例えば、ネットワークの効率的な使用および画質について最適化されているマルチキャスト・ストリームに用いられる通信経路とは異なるルータ、バッファ、およびＱｏＳ設定値を用いる。通例、セッション開始プロトコル（ＳＩＰ）が、セッションを設定するために用いられる。更に、ＲＴＰおよびＲＴＣＰが、メディア・ストリームおよび付随する帯域外制御情報の伝送のために用いられる。

セッションにおける端末間の１つ以上の低遅延通信チャネルは、端末間で同期情報を交換するためにも用いることができる。これは、低遅延通信チャネルにおいて用いられる１つ以上のプロトコルの上に同期プロトコルをピギーバックさせることによって行うことができる。例えば、ＳＩＰセッションでは、ＲＴＰストリームによって同時情報を搬送することができる。

あるいは、同期プロトコルは、それ自体の専用低遅延通信チャネルをＳＩＰセッションの一部として用いることができ、あるいは、ＳＩＰシグナリングが低遅延通信チャネルを通じて送られる場合には、ＳＩＰ ＩＮＦＯメッセージのようなセッション内ＳＩＰシグナリングを用いることもできる。

一実施形態では、低遅延通信チャネル１１０ａ、１１０ｂは、第１端末４ａと同期ユニットを内蔵する（ＩＰＴＶ）サーバとの間における第１ブロードキャスト・セッション（例えば、ＥＴＳＩ ＴＩＳＰＡＮ ＴＳ １８２０２７、第８．３．１項）、および第２端末と（ＩＰＴＶ）サーバとの間における第２ブロードキャスト・セッションの一部として設定することもできる。したがって、同期情報は、ブロードキャスト・セッションの一部である低遅延通信チャネルによって搬送される。低遅延通信チャネルは、ブロードキャストされるＩＰＴＶストリームと同じ（ブロードキャスト）セッションの一部であるが、要求される低遅延特性を実現するために異なるＱｏＳ特性を有することもあり得る。

あるいは、同期情報パケットは、通信セッションと関連のある１つ以上のＲＴＰストリームにおいて伝送することもできる。この実施形態では、ＳＩＰはオーディオ、ビデオ、および／またはテキスト、ならびに同期情報パケット毎に別個のＲＴＰストリームを確立する。更に、同期情報を、１つ以上のＲＴＰストリームと関連のあるＲＴＣＰストリームにピギーバックすることもでき、あるいはオーディオ・ビデオ、および／またはテキスト・ストリームを符号化（復号）および／または圧縮（伸張）するための１つ以上のコデックにピギーバックすることもできる。

これらの実施形態は全て、ユーザとサービスの間においてリアル・タイム通信を提供し、同時に、サービスのユーザが視聴するＴＶ番組の同期を提供する個々のサービスの既存のインフラストラクチャを利用することもできる。

通信セッションの１つ以上の低遅延通信チャネルを、同時情報を交換するための低遅延通信チャネルとして用いることによって、様々な代替同期方式が可能となる。

図１を参照すると、端末群の出力のユーザ・グループに対する同期は、１つ以上の低遅延通信チャネルを通じてこれらの端末に接続されている同期ユニット１１２によって実現する。この同期ユニットは、サーバ、例えば、ネットワーク１０６におけるアプリケーション・サーバまたは専用同期サーバ内に、機能ユニットとして配置することができる。これによって、端末はネットワーク１０６におけるネットワーク遅延を補償することが可能になる（例えば、ネットワークにおける処理遅延、整列遅延、送信遅延、および伝搬遅延、ならびにネットワーク輻輳によって起こる遅延、これはリンクまたはノードが過剰な量のデータを搬送しているときに発生する）。このために、各端末は、プレゼンテーション・ユニットに送信するストリームの送信を遅延させることができる、可変遅延バッファ１１４ａ、１１４ｂのような、可変遅延ユニットを備えている。

一実施形態では、可変遅延ユニットおよび同期ユニットは、クライアント・サーバ型モデルにおいて実装することができ、この場合、可変遅延ユニットは同期クライアントとして機能し、同期ユニットは同期サーバとして機能する。同期クライアント（可変遅延ユニット）は、プロトコル・ソケットを有することができ、プロトコル・ソケットは、同期ステータス情報を、適したプロトコルを用いて同期サーバ（同期ユニット）に送ることを可能にし、更に、同期設定命令を同期サーバから受信することを可能にする。同期ステータス情報は、ストリーム受信に関するメディア・ユニット基準情報（即ち、どのメディア・ユニットが受信されたか）、および現在の遅延設定値を含むことができる。

メディア・ユニット基準情報(reference information)は、パケット化ストリームにおける特定点へのインディケータを備えている。このインディケータは、フレーム番号、タイムスタンプ、または連番を含むことができる。また、メディア・ユニット基準情報は、検知した受信メディア・ストリームのフレーム・レート（単位時間当たりのフレーム数）を含むこともできる。このように、同期ユニットは、検知したフレーム・レートが異なる端末が宛先間同期に関与する場合でも、遅延情報を計算することができるとよい。

同期設定命令は、可変遅延ユニットを設定する命令を含むことができる。

同期サーバ（同期ユニット）および同期クライアント（可変遅延ユニット）は、同期セッションを開始および終了するように構成されている。同期セッションは、同期クライアントが招待メッセージを同期サーバに送ったとき、またはその逆のときに開始することができる。同期セッションの間、同期サーバおよび同期クライアントは同期ステータス情報および同期設定命令を交換することができる。同期セッションは、同期クライアントが終了メッセージを同期サーバに送ったとき、またはその逆のときに終了することができる。同期サーバおよび同期クライアントは、同期セッションへの招待を受け入れるため、または同期セッションの終了を確認するために、リターン・メッセージを送ることができる。

概して言えば、本発明による同期方法に関係する、前述のタイプの情報は全て、同期情報と呼ぶこともできる。

図１は、同期方式を示し、同期ユニット１１２が、低遅延通信チャネル１１０ａ、１１０ｂを通じて端末からの同期情報を集中的に収集し、この情報に基づいて、各端末における可変遅延バッファについて、遅延情報を計算する。同期ユニットによって用いられるアルゴリズムの例では、フレーム・レート、即ち、ストリーミング・コンテンツ（例えば、ビデオ）の１秒当たりのフレーム数が分かっていると仮定する。

同期ユニットと端末との間における情報転送を、図２のフロー図に更に詳しく示す。第１ステップ２０２において、同期ユニットは、好ましくは低遅延通信チャネルを通じて、ストリームにおける特定のメディア・ユニット（フレーム）の基準情報を同期ユニットに返送するように、端末に要求する。続いて、端末はこの情報、通例、端末において受信されたフレーム番号を含むフレームのＲＴＰ情報を、同期ユニットに低遅延通信チャネルを通じて送る（ステップ２０４）。次に、同期ユニット１１２は、タイムスタンプをフレーム番号に加算することができ、フレーム番号の１つ、好ましくは、端末が報告したものの内一番小さいフレーム番号または一番大きいフレーム番号を、基準フレームとして選択することができ、既知のフレーム・レートを用いて、この基準フレームに関係する時刻を、端末毎に計算する。その後、同期ユニットは、最も「遅れている」端末を判別し、その他の１つまたは複数の端末について遅延を計算し（ステップ２０６）、続いてこれらの遅延を、好ましくは、低遅延通信線を通じて端末に送信する（ステップ２０８）。

図２を参照して、同期によって実行されるステップの一部を、以下のように更に詳しく示す。
同期ユニット１１２は、以下のメディア・ユニット基準情報を端末ＥＴ１、ＥＴ２、およびＥＴ３から受信する。

ＥＴ１は、フレーム６３８９を受信する。

ＥＴ２は、フレーム６３９５を受信する。

ＥＴ３は、フレーム６３７５を受信する。

基準情報を受信すると、同期ユニットはタイム・スタンプを付加する。

ＥＴ１は、フレーム６３８９を１４：４６：５９：２６４５（Ｔ１）において受信した。

ＥＴ２は、フレーム６３９５を１４：４７：０５：４１１２（Ｔ２）において受信した。

ＥＴ３は、フレーム６３７５を１４：４６：５９．７６００（Ｔ３）において受信した。

低遅延チャネルのために、同期ユニットのタイム・スタンプは、端末が実際にフレームを受信したそれぞれの時刻を正しく表す。好ましくは、一旦ストリームの最後に受信したメディア・ユニットの基準情報が判定されたなら、端末はメディア基準情報を同期ユニットに直ちに返送する。あるいは、端末は、追加の内部遅延情報（例えば、メディア・ユニットの基準情報を判定したときとメディア・ユニットの基準情報を送ったときの間の遅延）を同期ユニットに返送してもよい。

フレーム・レートの一例が毎秒２５フレームであるとすると、最小のフレーム番号、即ち、フレーム６３７５に対するクロック時刻を、同期ユニットによって次のように端末毎に計算することができる。

最初の端末は、フレーム６３７５をほぼＴ１−（６３８９−６３７５）／２５＝１４：４６：５８．７０４５（Ｔ１’）において受信し、二番目の端末は、フレーム６３７５をほぼＴ２−（６３９５−６３７５）／２５＝１４：４７：０４．６１１２（Ｔ２’）において受信し、三番目の端末は、フレーム６３７５をほぼＴ３＝１４：４６：５９．７６００（Ｔ３’＝Ｔ３）において受信した。

ＥＴ１は、フレーム６３７５を１４：４６：５８．７０４５（Ｔ１’）において受信した。

ＥＴ２は、フレーム６３７５を１４：４７：０４．６１１２（Ｔ２’）において受信した。

ＥＴ３は、フレーム６３７５を１４：４６：５９．７６００（Ｔ３’＝Ｔ３）において受信した。

最も「遅れた」端末、即ち、基準フレーム６３７５を最後に受信した端末は、端末ＥＴ２である。最後に、同期ユニットは、各端末についての遅延（Ｄ１、Ｄ２、Ｄ３）を以下のように決定する。

ＥＴ１についての遅延Ｄ１＝Ｔ２’−Ｔ１’＝５．９０６７
ＥＴ２についての遅延Ｄ２＝０
ＥＴ３についての遅延Ｄ３＝Ｔ２’−Ｔ３’＝４．８５１２
続いて、これらの遅延は、好ましくは低遅延通信チャネルを通じて、前述の端末群に送られ、プレゼンテーション・ユニットへのストリームの送信を遅延させるために、可変遅延バッファによって用いられる。このようにして、当初送信されたストリームの中にある特定のフレーム（メディア・ユニット）のコンテンツが、図１に模式的に示すように、同じ時点Ｔ_ｏｕｔにおいて、グループ内の全てのユーザに送信されることになる。

一実施形態では、同期ユニットは、同時に、低遅延チャネルを通じて、宛先間同期に関与する全ての端末に、フレーム番号を要求する。全ての端末は、要求を受信すると、ストリームにおいて最後に受信したメディア・ユニットの基準情報を直ちに判定し、低遅延チャネルを通じて、要求されたメディア・ユニットの基準情報を返す。ここで、同期ユニットは、フレーム・レートと受信したフレーム番号のみに基づいて遅延を判定することができる。何故なら、全てのメディア・ユニットの基準情報は、実質的に同時に判定されるからであり、したがってタイム・スタンプはもはや不要となるからである。これによって、同期ユニットにおけるクロックの使用を排除し、計算プロセスにおけるステップを排除する。

更に別の実施形態では、ネットワークを通じて分散された多数の同期ユニットを用いることができる。図３は、このような分散システム３００の一例を示す。このシステムでは、各端末３０２、３０４、３０６が同期ユニットＳＵ１、ＳＵ２、ＳＵ３を備えている。各同期ユニットは、メディア・ユニットの基準情報を他の全ての同期ユニットに、１つ以上の低遅延通信チャネル３０８、３１０を通じて送信することができる。各同期ユニットは、可変遅延ユニットに適した遅延時間を計算し、先に論じたのと同様に、可変遅延バッファ３１２を用いてその出力を遅延させることができる。

同期ユニットは、同期機能、例えば、ソフトウェア・プログラムをホストするネットワークにおけるサーバであってもよく、あるいは１つ以上の端末またはＳＩＰサーバのようなサーバにおける機能ユニット、あるいは、２つ以上の端末のメディア・ストリームを接続するコンフェレンス・ブリッジ(conference bridge)における機能ユニットであってもよい。

一実施形態では、計算した遅延情報の精度を更に高めるために、同期ユニットは、例えば、往復時間即ちＲＴＣＰ情報を周期的にポーリングすることによって、低遅延通信チャネル自体の遅延を測定または入手し、この低遅延通信チャネルによって生じた遅延の分だけ、計算したストリームの遅延情報を調節する。

図４は、本発明の一実施形態による、同期クライアント（ＳＣ）と同期サーバＳｙｎｃｈＳとの間における同期セッションのメッセージング・フローの一例を示す。ＳＣおよびＳｙｎｃｈＳは、ＩＭＳ型アーキテクチャで実現することができる。この場合、ＥＴＳＩ技術仕様書ＴＳ１８２０２７において定められているように、同期クライアントはユーザ機器（ＵＥ）の基礎機能とすることができ、同期サーバ（ＳｙｎｃｈＳ）はＩＰＴＶサービス制御機能（ＳＣＦ）の基礎機能とすることができる。

この実施形態では、同期情報の交換を開始、維持、および終了するための同期セッションは、ＥＴＳＩ ＴＩＳＰＡＮ ＴＳ １８２ ０２７、第８．３．１項に記載されているように、ブロードキャスト・セッションの一部として確立される。言い換えると、同期セッションを設定、維持、および終了するための基準点（インターフェースまたはプロトコル）は、ＳＣＦとのブロードキャスト・セッションを設定するためにＵＥによって用いられるＧｍ（ＴＳ １８２ ０２７、第６．３項）およびＩＳＣ（ＴＳ １８２ ０２７、第６．８項）基準点を通じて送信される。同期セッション内における同期情報の交換は、同期セッション開始の一部として設定される低遅延通信チャネルにおいて送信される。

ブロードキャスト・セッションおよび同期セッションを設定するプロセスは、以下のステップを備えることができる。

第１ステップ４００において、ＴＳ １８２ ０２７、第８．３．１項に記載されている手順にしたがって、ＵＥ（ＳＣを備えている）とＳＣＦ（ＳｙｎｃｈＳを備えている）との間に、ブロードキャスト・セッションを設定する。第２ステップ４０２において、ＳＣは同期開始要求をＳｙｎｃｈＳに送り、宛先間同期プロセスに参加したいことを示す。この要求は、同期対象ブロードキャスト・チャネルのＢＣＳｅｒｖｉｃｅＩｄを含む。このメッセージおよびこれに続く全てのメッセージは、第１ステップにおいて確立されたブロードキャスト・セッションにおいて送られる。第３ステップ４０４において、ＳｙｎｃｈＳは、ＳＣの宛先間同期プロセスへの参加を確認する。第４ステップ４０６において、ＳＣはその同期ステータス情報をＳｙｎｃｈＳに送る。第５ステップ４０８において、ＳｙｎｃｈＳは、多数のＳＣからの同期ステータス情報を集計し、各ＳＣに適した同期設定値を計算する。収集した同期ステータス情報から同期設定命令(synchronization setting instructions)を計算するアルゴリズムの例では、図２に関して先に説明したアルゴリズムを用いて計算することができる。第６ステップ４１０において、ＳｙｎｃｈＳは同期設定命令をＳＣに送る。ステップ４０６から４１０は、規則的な時間間隔で繰り返すことができる。セッションを終了する必要がある場合、ＳＣは、第７ステップ４１２において、同期終了要求を送り、ＳＣがもはや宛先間同期プロセスにおいてアクティブではないことを示す。第８ステップ４１４において、ＳｙｎｃｈＳは宛先間同期プロセスにおけるＳＣの参加終了を確認する。

任意に、ＳＣは、１回のブロードキャスト・セッション内において、連続的および／または同時にの双方で、多数の同期セッションを開始および終了することもできる。

更に別の実施形態では、同期セッションをどのように開始できるかについての別の例を更に詳しく示す。図５は、ＥＴＳＩ ＴＩＳＰＡＮによって定められた、ＩＭＳに基づくＩＰＴＶアーキテクチャ５００の一例を示す。このアーキテクチャは、例えば、ＩＭＳに基づくＩＰＴＶサービスの加入者２人が同じＴＶ番組（例えば、サッカーの試合）を同期させて視聴し、同時に（ビデオ）電話またはチャットで通信したいというような想定場面に用いることができる。容認可能なユーザ体験のためには、双方のＴＶにおけるＩＰＴＶストリームを実質的に同期させなければならない（例えば、ＴＶで実際のゴールを見る何秒も前に友人が「ゴール！」と叫ぶのを聞くことを避けるため）。

要求される実質的な同期レベルを達成するために、図６のフロー図６００ に示す以下のステップを実行する。

最初に、ユーザが、セッション変更（メディア配信機能ＭＤＦ５０２が送信局となり、ＩＰＴＶブロードキャスト・セッション５０４がパケット化ストリームとなる）を要求することによって、既存の非同期ＩＰＴＶブロードキャスト・セッションに対する同期を可能にしたい場合があり得る（ステップ６０４）。セッション変更には、ユーザ機器ＵＥ５０６（端末）がＳＩＰインバイト・メッセージをサービス制御機能ＳＣＦ５０８に送ること、またはその逆を伴い、このメッセージは、更新したセッション記述（セッション記述プロトコルＳＤＰを用いる）を含む。このセッション記述は、どのＩＰＴＶストリームを同期させるべきかについての情報（例えば、ＢＣＳｅｒｖｉｃｅＩｄによって示される）、および同期セッションに関与するＵＥについての情報を収容する。このＳＩＰ ＩＮＶＩＴＥメッセージは、コアＩＭＳ５１２内に配置されているプロキシ呼セッション制御機能（Ｐ−ＣＳＣＦ）５１０によって導出され（ステップ６０４、６０８）、これによって、Ｐ−ＣＳＣＦはセッション記述情報をリソース承認制御サブシステムＲＡＣＳ５１４に転送し、同期情報の交換のために低遅延トランスポート機能ＢＴＦ５１６を確保するために、基本トランスポート機能ＢＴＦ５１６におけるネットワーク・リソースを予約する（ステップ６０６）。

更に、ＳＣＦ５０８（または、ＳＣＦが要求を発した場合はＵＥ）は要求を受け入れることができ（ステップ６１０）、メディア同期アプリケーション・サーバＭＳＡＳ（同期ユニット）に、宛先間同期のために同期セッションを開始するように命令することができる。これは、ＭＳＡＳがＳＣＦ内に配置されている場合には内部プロトコルを用いて行うことができ、あるいは、例えば、ＭＳ ＡＳがＩＭＳアーキテクチャのメディア制御機能（ＭＣＦ）５１８に配置されている場合には、ＳＩＰプロトコルを用いることができる。ＭＣＦは、ＩＰＴＶメディア機能（ＭＦ）５２０の一部である。

最後に、宛先間同期（セッション）に参加しているＵＥは、その同期ステータス情報（同期対象ストリームのメディア・ユニット基準情報を含む）をＭＳＡＳに、変更したブロードキャスト・セッション（ここでは、ＲＡＣＳによって予約されている低遅延通信チャネルを含む）の一部として送る（ステップ６１２）。

次いで、ＭＳＡＳは、ＵＥ毎に可変遅延ユニットにおいて用いるための遅延情報を計算し、この遅延情報（同期設定命令）を、参加しているＵＥに送信する。

以上の実施形態例では、パケット化ストリーム（ＩＰＴＶブロードキャストのような）は、ＩＭＳに基づくＩＰＴＶアーキテクチャ（ＴＳ １８２ ０２７）から周知のメディア配信機能（ＭＤＦ）からマルチキャストされる、正規のブロードキャスト・チャネルを用いる。このブロードキャスト・チャネルは、パケット化ストリームが発信元と宛先との間で受ける可能性がある種々の走査によって、比較的遅い可能性がある。更に、これは通例単一方向である。ブロードキャスト・セッションは、例えば、ブロードキャスト・チャネルのために予約帯域幅に設定され、ポートを開き、課金(charging)を可能にする。本実施形態による同期セッションを含むブロードキャスト・セッションは、好ましくは、異なる通信経路を用いる同期情報を交換するために、低遅延通信チャネルを用いるＳＩＰシグナリング・セッションであることが好ましい。正規のブロードキャスト・チャネルとは対照的に、この異なる通信経路は、サービス制御機能（ＭＳＡＳを備えている）とＵＥ（ＳＣを備えている）との間における比較的高速の双方向低遅延通信チャネルである。

本発明は、前述の実施形態に限定されるのではなく、添付する請求項の範囲内において様々に変更することができる。

Claims (10)

1. 少なくとも２つの端末の出力を同期させる方法であって、
   −前記端末と同期ユニットとの間に１つ以上の低遅延通信チャネルを設けるステップであって、前記同期ユニットがサーバに備えられているステップと、
   −前記１つ以上の低遅延通信チャネルが、前記端末間における通信セッションの一部として確立されるステップであって、前記１つ以上の低遅延通信チャネルが１５０ｍｓ未満の遅延を有する、ステップと、
   −前記同期ユニットが、前記１つ以上の低遅延通信チャネルを通じて前記端末から受信した同期情報に基づいて、遅延情報を計算するステップであって、前記同期情報が、前記通信セッションをセットアップおよび維持するために用いるプロトコル、または前記低遅延通信チャネルで用いるプロトコルの一方にピギーバックされるステップと、
   −前記遅延情報を前記端末の少なくとも１つに送信し、前記端末の出力を実質的に同期させるように、当該少なくとも１つの端末にその出力を遅延させるステップと、
   を備えている、方法。
2. 請求項１記載の方法において、各端末は、マルチメディア信号を受信する入力と、該マルチメディア信号を情報プレゼンテーション・ユニットに送信する出力とを備えており、各端末は、前記出力信号を遅延させる可変遅延ユニットを備えており、前記方法は、更に、
   −マルチメディア・ストリームを前記端末の入力に送信するステップであって、好ましくは、前記マルチメディア・ストリームがメディア・ユニットを含む、ステップと、
   −前記受信した遅延情報にしたがって、前記出力信号を遅延させる、ステップと、
   を備えている、方法。
3. 請求項１または２記載の方法において、更に、
   各端末が同期情報を、好ましくは、同期要求に応答して、前記同期ユニットへの低遅延通信チャネルを通じて送るステップを備えており、前記同期情報は、マルチメディア・ストリーム内におけるメディア・ユニットの位置を表すメディア・ユニット基準（ＭＵＲ）情報を備えている、方法。
4. 請求項３記載の方法において、前記ＭＵＲ情報は、フレーム番号またはシーケンス番号を含む、方法。
5. 請求項３または４記載の方法において、更に、
   −前記端末から受信した前記ＭＵＲ情報に、１つ以上のタイム・スタンプを付加するステップと、
   −前記端末が受信した前記マルチメディア・ストリームのフレーム・レートに関する情報を提供するステップと、
   −前記フレーム・レート情報および前記タイム・スタンプが付加されたＭＵＲ情報に基づいて、端末毎に遅延情報を計算するステップと、
   −遅延情報を前記端末の内少なくとも１つに送るステップと、
   を備えている、方法。
6. 請求項３または４記載の方法において、更に、
   −前記同期ユニットが同期要求を、好ましくは同時に、１つ以上の低遅延通信チャネルを通じて前記端末に送るステップと、
   −前記端末が受信した前記マルチメディア・ストリームのフレーム・レートに関する情報を提供するステップと、
   −前記フレーム・レート情報および前記ＭＵＲ情報に基づいて、端末毎に遅延情報を計算するステップと、
   −遅延情報を前記端末の内少なくとも１つに送るステップと、
   を備えている、方法。
7. 請求項１から６までのいずれか１項に記載の方法において、前記同期情報を前記同期ユニットに低遅延通信チャネルを通じて送信し、該低遅延通信チャネルは、通信セッションまたはブロードキャスト・セッション、更に好ましくは、ＥＴＳＩ ＴＳ １８２ ０２７において定められているブロードキャスト・セッションの一部として確立される、方法。
8. 請求項１から６までのいずれか１項に記載の方法において、前記低遅延通信チャネルは、ボイス・オーバーＩＰ（ＶｏＩＰ）チャネル、ＧＳＭ、ＵＭＴＳまたはＬＴＥネットワーク上におけるＵＳＳＤベース・チャネル、ＩＭＳセッションにおけるＱｏＳ制御チャネル、通信セッションまたはブロードキャスト・セッションにおける専用チャネル、専用イーサネットＶＬＡＮチャネル、専用ＭＰＬＳチャネル、またはＩＰディフサーブ・ストリームによって用いられる専用チャネル
   である、方法。
9. １つ以上の計算デバイスにおいて実行させると、請求項１記載の前記方法ステップを実行するように構成されているソフトウェア・コード部を備えている、コンピュータ・プログラム。
10. 前記１つ以上の計算デバイスが１つ以上のネットワーク・サーバまたは端末が有するメモリである、請求項９記載のコンピュータ・プログラム。

Images