JP5363473B2 - 改善されたメディア・セッション管理の方法と装置 - Google Patents

Description

本発明は一般的には電気通信システムに関し、具体的にはそのようなシステムにおける改善されたユニキャスト・メディア・セッション管理に関する。

現行の移動ネットワークおよび移動通信システムにおいて、広範囲の新しいサービスを提案し、提供する傾向になってきた。現状では、マルチメディアまたはＴＶコンテンツに移動ネットワークを使用することに、非常に大きな関心が持たれている。これはしばしば、技術的には移動ＴＶといわれている。移動ＴＶ応用の目的は、各種のマルチメディアまたはＴＶチャネルの間で選択し、ユーザが容易に映すことができる、ＴＶ類似の環境を提案することである。

通常、ＴＶチャネルは多数のユーザにブロードキャストされ、典型的には、受信し、見るべきチャネルをユーザが選択することができる。移動ＴＶも同様に、一組の（ライブの）メディアまたはマルチメディア・ストリームを様々なエンド・ユーザに配信する必要がある。各マルチメディア・ストリームはＴＶチャネルに相当し、各ユーザは見るべきチャネルを選択することができるものである。現状では、移動ＴＶのブロードキャスト／マルチキャスト配信方法は開発中である。そのような標準化努力の例は、３ＧＰＰマルチメディア・ブロードキャスト／マルチキャスト・サービス（ＭＢＭＳ）および欧州電気通信標準化機構（ＥＴＳＩ）携帯機器向けデジタル・ビデオ・ブロードキャストである。そのブロードキャスト分配方法においては、これらは通常のＴＶと類似であろう。

ＩＰＴＶ（インターネット・プロトコルＴＶ）は、ＩＰネットワーク、典型的にはブロードキャスト・アクセス・ネットワークをでブロードキャストされたＴＶサービスを配信する場合に使用する用語である。さらに、ＩＰネットワーク、例えば、ビデオ・オン・デマンドまたは他のユーザ固有のサービスの持つ柔軟な性質のため、もっと個人的サービスが配信可能であり、これは次に、ユニキャストＩＰストリームでエンド・ユーザに配信される。ＩＰビデオ・システムは、プロバイダが住宅用および企業用顧客向けのサービス・プロバイダ・トリプル・プレイ提供物において、キーとなる特徴になりつつある。合理的な画質をもって受け入れ可能なチャネル切換を提供することは、顧客の採用にとって本質的なことである。本問題は、顧客の建物内およびネットワーク内の両方で低い遅延を保つことの中に、直接位置付ける。

ビデオ・ストリームから画像を復号して構成することを開始するため、ある頻度でのみ起こるストリームから多くの情報を集める必要がある。特に、新規のビデオ供給の画像を表示の開始するためには、デコーダはランダム・アクセス・ポイント（ＲＡＰ）を待ち、ビデオ・ストリーム、いわゆるイントラフレーム即ち旧ビデオ標準のＩフレーム、またはＨ．２６４では、いわゆるＩＤＲ（瞬時デコーダ・リフレッシュ、Ｉｎｓｔａｎｔｅｎｅｏｕｓ Ｄｅｃｏｄｅｒ Ｒｅｆｒｅｓｈ）に到達する必要がある。そのようなフレームはメディア・ストリームにおける唯一のフレームであり、完全な画像を再構成するために十分な情報をそれ自身に含む。それらは典型的にはコード化システムに依存し、０．５乃至５秒の周期で起こる。

従来の解決策では、プル・メカニズムを使用して、ビデオ・サーバまたは最近接アクセス・ノードからビデオ送信（ＨＴＴＰ ＧＥＴまたはその他）で送信された最後のイントラフレームを獲得するか、または各種のメカニズムを使用して、イントラフレームを受信するまでの時間距離が著しく削減されるよう、わずかに時間シフトしたビデオ・ストリームを配信する。これらの解決策は、次のイントラフレームが到達し、ビデオ復号化が継続できるまで、チャネル切換メカニズムは静止画像を示すことができるのみであるか、アクセス・ノード（ＤＳＬＡＭまたは同等のもの）で利用可能な時間シフト・ストリーム数とともに帯域幅消費が大きくなる、ということを意味する。もし時間シフトがアクセス・ノード自身で起こるなら、処理電力の要求条件およびアクセス・ノードを多重化する能力は大きく向上する。

ＭＢＭＳ（マルチメディア・ブロードキャスト／マルチキャスト・サービス[非特許文献１]）およびＤＶＢ−Ｈ（携帯機器向けデジタル・ビデオ・ブロードキャスト[非特許文献２]）の出現にともない、最初は完全にユニキャストであった移動ＴＶは、ユニキャストとブロードキャスト・チャネルの組合せから構成されるであろう。これにより、チャネル間でのみならず、同じチャネルの異なる送信ソース間でも切換できる必要があるので、新しいチャネル切換要求条件が加わる。

ユニキャスト・チャネル切換は長期間に亘って開発され、高速チャネル切換方法が利用可能である。ライブ・チャネルへ切り換える場合、メディア・デコーダは典型的には、ビデオ・ストリームの最初の完全な画像を表示するのに必要な全ての情報を直ちに得ることはない。それは、デコーダが全体の画像を表示できるイントラ画像、別名キーフレームまたはランダム・アクセス・ポイント（ＲＡＰ）をデコードする場合のみである。従って、高速で明確なチャネル切換を行う良い方法は、メディア・サーバがビットストリームをバッファし、ＲＡＰで始まる遅延ストリームをデコーダに送信することである。ＲＴＳＰ（リアルタイム・ストリーミング・プロトコル、[非特許文献３]）、ＰＳＳ（パケット切換 ストリーミング サービス、[非特許文献４]）の基本を使用する場合、完全に新しいＲＴＳＰセッションを設定する場合、および現行のＲＴＳＰセッション内にチャネルを切り換える場合の両方で、このバッファリングを使用することができる。

ＲＴＳＰセッション内でチャネルを切り換える場合、進行しているＲＴＰセッション内で、または新しいＲＴＰセッションを確立することにより、切換を行うが、本問題点および解決策は同じままである。

短期間に２個のストリームを同時に受信し、適当なポイントでソース間を切り換えることにより、ユニキャストとブロードキャスト間で継ぎ目のない移行を比較的簡単に達成することができる。もしストリームがパケット・レベルで全く同じであれば、任意のパケットでそれを行うことができる。もしそうでなければ、新しいストリームが開始してＲＡＰでデコードされるべきである。これが機能する前提条件は、チャネル間の到着時間差が小さいということである。

もしサーバがため個々のレベルでユニキャスト・チャネルをバッファしてＲＡＰの送信を開始するなら、遅延の最大値はＲＡＰ間の距離となる。

例えば、ブロードキャストからユニキャストへの切換で、同じチャネル内の切換の場合には、ＲＡＰで始まるチャネルのバッファ版への高速切換は望まれないが、その理由は、このことが、いわゆる継ぎ目のないアクセス移行を禁止する走行中のバッファの結果であり得るからである。即ち、ユーザが認知する意味で、継ぎ目がないということである。

それ故、ユニキャスト・セッションへ継ぎ目のない移行を可能とする方法と装置の必要性がある。

３ＧＰＰ ＴＳ ２６．３４６、" マルチメディア・ブロードキャスト／マルチキャスト・サービス（ＭＢＭＳ）；プロトコルとコーデック、Ｍｕｌｔｉｍｅｄｉａ Ｂｒｏａｄｃａｓｔ／Ｍｕｌｔｉｃａｓｔ Ｓｅｒｖｉｃｅ（ＭＢＭＳ）；Ｐｒｏｔｏｃｏｌ ａｎｄ Ｃｏｄｅｃｓ" ＥＴＳＩ ＥＮ ３０２ ３０４ Ｖ１．１．１、"デジタル・ビデオ・ブロードキャスト（ＤＶＢ）；携帯端末向け送信システム（ＤＶＢ−Ｈ）、Ｄｉｇｉｔａｌ Ｖｉｄｅｏ Ｂｒｏａｄｃａｓｔｉｎｇ（ＤＶＢ）；Ｔｒａｎｓｍｉｓｓｉｏｎ Ｓｙｓｔｅｍ ｆｏｒ Ｈａｎｄｈｅｌｄ Ｔｅｒｍｉｎａｌ（ＤＶＢ−Ｈ）" ＩＥＴＦ ＲＦＣ２３２６，"リアルタイム・ストリーミング・プロトコル（ＲＴＳＰ）、Ｒｅａｌ−Ｔｉｍｅ Ｓｔｒｅａｍｉｎｇ Ｐｒｏｔｏｃｏｌ（ＲＴＳＰ）" ３ＧＰＰ ＴＳ ２６．２３４、"トランスペアレント エンド−ツウ−エンド パケット切換 ストリーミング サービス（ＰＳＳ）；プロトコルとコーデック、Ｔｒａｎｓｐａｒｅｎｔ ｅｎｄ−ｔｏ−ｅｎｄ Ｐａｃｋｅｔ−ｓｗｉｔｃｈｅｄ Ｓｔｒｅａｍｉｎｇ Ｓｅｒｖｉｃｅ；Ｐｒｏｔｏｃｏｌ ａｎｄ Ｃｏｄｅｃｓ"

本発明の目的は、改善したメディア送信を可能とすることである。

本発明の更なる目的は、継ぎ目のないユーザ認知のチャネル切換を可能とすることである。

本発明のこれらおよび他の目的について、添付した一式の特許請求項で述べる。

基本的には、本発明によれば、ユニキャスト送信ソースからチャネル上のメディア・ストリームへの切換を検出Ｓ０、Ｓ００したユーザ端末は、送信のために所定の開始フレームを示すインジケーションを供給することによりメディア・ストリームの送信を要求Ｓ１し、メディア・サーバは、その要求のインジケーションに示されたメディア・フレームで始まる要求メディア・フレームを送信Ｓ２する。

特定の実施形態によれば、その要求をＲＴＳＰヘッダに備え、開始フレームを開始パラメータ、例えば、開始−位置−形式パラメータで示す。

本発明の利点には以下が含まれる。：
・ブロードキャストとユニキャスト・セッション間のユーザ認知の継ぎ目のない移行。
・ライブ・ユニキャスト・メディア・ストリームのどこで開始を希望するか、顧客がサーバに信号伝達を可能とすること。
・ＲＴＳＰサーバは、高速ユニキャスト・チャネル切換と、ユニキャスト移行または他のアクセス移行への継ぎ目のないブロードキャストとを合成することができること。各チャネルを一度だけ符号化し、バッファリングを使用して高速切換を実行するサーバ上でこれを行うことができる。
・現行のメッセージ内の新しいヘッダによって開始フレームのインジケーションを示す本発明の実施形態により、本発明を実装していないサーバは、ヘッダを簡単に無視するようにできる。それによって、本発明は、全てのバックワード互換性のない持たない解決策を提供する。

本発明は、その更なる目的および利点とともに、添付の図面と一緒にした以下の説明を参照することにより、最もよく理解できる可能性がある。

本発明を実装することができるシステムを示す。 メディア・ストリームのフレームを示す。 本発明による方法の一実施形態を示す。 本発明による方法の一実施形態の概略的信号伝達図を示す。 本発明による方法の更なる実施形態の概略的信号伝達図を示す。 本発明による方法の更なるもう一つの実施形態の概略的信号伝達図を示す。 本発明によるユーザ端末の一実施形態を示す。 本発明によるメディア・サーバの一実施形態を示す。

（略語）
・３ＧＰＰ 第3世代パートナーシップ・プロジェクト（Ｔｈｅ ３ｒｄ Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒｓｈｉｐ Ｐｒｏｊｅｃｔ）
・ＤＶＢ＿Ｈ 携帯機器向けデジタル・ビデオ・ブロードキャスト（Ｄｉｇｉｔａｌ Ｖｉｄｅｏ Ｂｒｏａｄｃａｓｔｉｎｇ−Ｈａｎｄｈｅｌｄ）
・ＦＥＣ 前方誤り訂正（Ｆｏｒｗａｒｄ Ｅｒｒｏｒ Ｃｏｒｒｅｃｔｉｏｎ）
・ＩＤＲ 瞬時デコーダ・リフレッシュ（Ｉｎｓｔａｎｔｅｎｅｏｕｓ Ｄｅｃｏｄｅｒ Ｒｅｆｒｅｓｈ）
・ＭＢＭＳ マルチメディア・ブロードキャスト／マルチキャスト・サービス（Ｍｕｌｔｉｍｅｄｉａ Ｂｒｏａｄｃａｓｔ／Ｍｕｌｔｉｃａｓｔ Ｓｅｒｖｉｃｅ）
・ＮＴＰ ネットワーク時間プロトコル（Ｎｅｔｗｏｒｋ Ｔｉｍｅ Ｐｒｏｔｏｃｏｌ）
・ＮＰＴ 通常再生時間（Ｎｏｒｍａｌ Ｐｌａｙ Ｔｉｍｅ）
・ＰＳＳ パケット切換 ストリーミング サービス（Ｐａｃｋｅｔ−ｓｗｉｔｃｈｅｄ Ｓｔｒｅａｍｉｎｇ Ｓｅｒｖｉｃｅ）
・ＲＡＰ ランダム・アクセス・ポイント（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｐｏｉｎｔ）
・ＲＹＣＰ ＲＴＰ制御プロトコル（ＲＴＰ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）
・ＲＴＰ リアルタイム送信プロトコル（Ｒｅａｌ−ｔｉｍｅ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ）
・ＲＴＳＰ リアルタイム・ストリーミング・プロトコル（Ｒｅａｌ−ｔｉｍｅ Ｓｔｒｅａｍｉｎｇ Ｐｒｏｔｏｃｏｌ）

移動ＴＶサービスをサポートできて、特にＲＴＳＰを使用するブロードキャスト／ユニキャスト通信システムとの関連で、本発明を述べる。しかしながら、明らかなことであるが、ブロードキャストからユニキャストへの送信へ、もっと一般的には、非バッファ送信からバッファ送信へ、ユーザ受信の移行が起こる可能性のある他のシステムに、本発明を適用できる。あるいは、全く新しいメディア・セッションを確立するか、ユニキャスト・プロバイダの一つのチャネルから同じユニキャスト・プロバイダのもう一つのチャネルに、例えば、同じセッション内でユーザ端末が切り換わるような状況において、本発明を適用できる。

本発明によるメディアまたはマルチメディア・データには、ユーザ端末でレンダリングを行い、表示できる全ての形態および形式のメディアを含む。これには、レンダリングの間はユーザが認識可能である画像、ビデオ、オーディオおよび他のメディア形式を含むが、限定はしない。本発明によるメディア・チャネルは、例えば、“ライブ”・メディアを運ぶことが可能な、または、一つ以上の切抜きから成る事前に記録したコンテンツから構成可能なチャネルである。

図１に、本発明を実装できる無線通信システム１を概略的に示す。無線通信システム１には、少なくとも一つの接続顧客またはユーザ端末１０にメディア・コンテンツを送信できる基地局またはネットワーク・ノード２０を備える。この基地局２０は、多数の利用可能なユニキャスト・ベースのメディア・チャネルを持つ本発明のメディア・サーバ２００を備えるか、それに接続される。さらに、本システムには、ユーザ端末１０（および同様に潜在的には他のユーザ端末）にメディア・コンテンツをブロードキャストできる第二の基地局またはネットワーク・ノード３０を備える。

図２で見るように、ＭＰＥＧ−２コーデックでは、メディア・ストリームには典型的には、各種形式のフレーム、Ｐフレーム、Ｂフレームおよびイントラフレーム即ちキーフレームを備え、イントラフレームを“Ｉフレーム”と印を付ける。Ｉフレームは、符号化の以前の、または将来のフレームに全く依存しない唯一のフレームであり、そのような自己完結した、即ちキーフレームの等価な例は、ランダム・アクセス・ポイント（ＲＡＰ）であり、ＲＡＰは全ての形式のメディアに対する一般的用語であり、Ｉフレームはビデオで使用する例である。符号化をＩフレーム自身の上でのみ行い、従ってイントラフレーム符号化のみを使用する。それ故、正しいフレームが再び復元するので、誤りがフレーム・シーケンスに入った場合には有効である。前にＰフレームまたはＩフレームの予測を使用して、Ｐフレームを符号化する。この予測は通常、動作補償と動作予測によって達成される。最終形式のフレームは、前方および後方予測によりＩフレームおよびＰフレームに符号化される、または、もっと適切に言えばそれらの中間値の推定値のフレームであるＢフレームである。この形式のフレームは伝搬誤りの影響を受け易いが、低ビット速度であるという利点を持つ。

現在のところ、顧客またはユーザ端末が、希望の開始フレームまたはメディア・ストリームの位置についてのいかなる既知のプロトコル、例えば、ＲＴＳＰによって、メディア・サーバまたは送信ソースに信号伝達、または通知できる方法は全く無い。これは、顧客がブロードキャストおよび／またはユニキャスト・メディア・サーバからメディア・ストリームを受信することができる、いわゆるハイブリッド・ユニキャスト／ブロードキャストの解決策では、特に問題である。それ故、ユニキャスト・チャネルの切換または確立は、同じチャネルの送信ソースにおける切換（例えば、ＭＢＭＳからＲＴＳＰへ）のためである、または、実際の場合なら、コンテンツにおいても切換のためであるということを、顧客がサーバに通知する、または、サーバが情報を得ることは不可能である。

上述の形式の切換は、顧客またはユーザ端末がメディア・ストリームのどこで合わせることを望むか、基本的に決定する。ブロードキャストから異なるユニキャスト・チャネルへ切り換える場合、イントラフレームまたはＲＡＰのようなキーフレームで始まる高速チャネル切換が望まれる。この高速切換は、もしサーバがメディア・パケットをバッファするなら達成可能であり、それ故、多かれ少なかれ継ぎ目の無い切換を可能とする遅延が提供される。同じチャネルであるが、異なる送信メカニズムまたはソースに切り換える場合、この形式のバッファリングは望ましくないが、それは、既に送信されたＲＡＰまたは他の一般的なメディア・フレームを送信するという結果になる可能性があるからである。それ故、ユーザまたは顧客端末に対して、継ぎ目のない送信を全て阻止することである。

基本的に、本発明によれば、顧客はユニキャスト送信ソースからメディアの送信を要求し、前記要求には、メディア・ストリームのどこで送信を開始すべきかという情報を含む。希望の開始フレームを示す特定のインジケーションを含めることにより、これを達成する。特定の実施形態によれば、いわゆるＲＴＳＰ ＰＬＡＹ要求または類似のものに、このインジケーションを含める。それによって、ユーザは、どの形式の切換を経験しているかに基づき、特定の開始フレームを要求できる。

図３を参照して、本発明の一般的実施形態について述べる。

本発明の最も一般的な実施形態では、顧客またはユーザ端末は、送信のためメディア・ストリームにおける開始位置を示すインジケーションを提供することにより、ユニキャスト・メディア・サーバまたはプロバイダから少なくとも一つのメディア・ストリームの送信を要求Ｓ１する。この要求とインジケーションに応じて、メディア・サーバは、インジケーションに示されたフレームで始まる要求メディアの送信をＳ２起動する。

ユーザ端末は、最後のキーフレーム、即ちＲＡＰ、瞬時の即ちライブ位置、次のキーフレームから、またはタイムライン例えばＮＴＰを使用して、時間の特定位置で、メディアを受信するよう要求することができる。

更なるステップにより、送信を要求することＳ１と、インジケーションに示された開始メディア・フレームから始まる要求フレームを実際に送信することＳ２とのステップを、先行することができる。

第一のステップＳ０では、切換の必要性を検出する。これは、受信条件の実際の測定により実行でき、ある品質のサービス測定、または顧客の無線条件に関係するある他の測定、または単に顧客またはユーザで引き起こる実際のチャネル切換の検出に基づいて、実行できる。

引き続いて、第二のステップＳ００では、検出された切換のために切換形式を決定する。次に、この形式は、ステップＳ１の実際の送信要求でどの開始フレームをインジケーションで示すべきか、決定する。

本発明の特定の実施形態によれば、チャネル切換という用語を広く解釈して、完全に新しいセッション、または同じ送信ソース（即ち、ユニキャスト）内のチャネル切換を対象とする。これらの二つ場合に対して、ステップＳ０およびＳ００は選択的と見なすことができるであろう。

上記の実施形態のユーザ端末とメディア・サーバとの間の信号伝達図の例を図４に示す。ユーザ端末でチャネル切換を検出する。かなり広い意味で切換という用語を使用するが、新しいチャネルへの実際の切換、およびブロードキャスト・サーバのチャネルからユニキャスト・サーバの同じチャネルへ切換の両方を含む。続いて、切換の形式を決定する。基本的には本切換は実際のチャネル切換であるか、ブロードキャストからユニキャスト・サーバへの単なる切換である。また、新しいセッションを設定する意味での切換のみならず、他の形式の”切換”を含む。決定した切換形式に基づき、ユーザ端末はメディア・サーバからメディア・ストリームの送信を要求する。本要求には、メディア・ストリームのどこで送信が始まるべきかを示すインジケーションを含む。メディア・サーバは本要求を処理し、続いて、開始フレームのインジケーションが示すフレームで始まるメディア・ストリームを送信する。最後に、ユーザ端末はメディアをレンダリングし、ユーザは継ぎ目のない視聴体験を持つ。

最後のキーフレーム即ちＲＡＰからメディアを要求する場合、サーバは、最新のＲＡＰで始まる遅延ストリームを送信することを直ちに開始すべきである。バッファしているので、これは瞬時に利用可能である。非バッファ・ストリームに対する遅延は、最後のＲＡＰへの距離に依存する。瞬時メディアの要求のため、ＲＡＰであってもよいし、そうでなくてもよい非バッファ・データという結果になるであろう。最終的には、次のＲＡＰからの要求のため、ＲＡＰである非バッファ・データとなるが、あり得る遅延の後である。次のＲＡＰ要求は、瞬時メディア要求に基本的に非常に類似している−相違は、ＲＡＰの一部でないパケットは全てサーバによってフィルタされている、ということである。最後に、タイムラインに基づく時間の特定のポイントのインジケーションは、全てのサーバ／ノード／ユーザ端末が同じクロックと同期している、ということを要求している。

ＲＡＰの概念は、殆んどビデオ・メディアのための成果であるが、また他のメディアにも関係してもよい。もしマルチメディアを使用する場合、コンテンツを可能な限り早く振る舞うことができるよう、サーバはＲＡＰを定めるべきである。

既知の方法によれば、ＲＴＳＰ ＰＬＡＹ要求を出す場合、顧客またはユーザ端末はＲＴＳＰヘッダ内の範囲を定める。この範囲は、ライブ・ストリームに対しては、典型的にはＲａｎｇｅ：０−またはＲａｎｇｅ：ｎｏｗ−である。格納コンテンツに対しては、替わりに特定のＮＰＴ（メディア時間）を使用できる。ライブおよび格納の両方の場合、サーバが時間に厳密あることを試みるべきかどうか、または最近のＲＡＰから送信を開始すべきかどうか、伝える可能性は全く無い。

本発明の特定の実施形態によれば、現行のＲＴＳＰ ＰＬＡＹ要求に新しいヘッダを追加する。このヘッダには、少なくとも開始位置の形式に関連する情報を含むか、または切換に先行する切換形式のインジケーションを潜在的に含む。

例として、開始−位置−形式と名付けた、次のフォーマットを有する新しいヘッダについて考える：
開始−位置−形式：“ｉｎｓｔａｎｔ”｜“ｌａｓｔＲＡＰ”｜“ｎｅｘｔＲＡＰ”
切換または送信形式“ｉｎｓｔａｎｔ”に対しては、余分の遅延無しに直ちに、そして第一の利用可能なライブ・メディア・フレームから開始して、メディアを送信すべきである。従って、非バッファ・メディア・フレームを送信すべきである。

形式“ｌａｓｔＲＡＰ”に対しては、顧客に直ちに、メディア・サーバにバッファした最新のＲＡＰで開始して、メディアを送信すべきである。余分の遅延無しでメディアを送信することに対する要求は全く無い。従って、最も最近にバッファしたキーフレームから開始して、バッファ・メディア・フレームを送信すべきである。

形式“ｎｅｘｔＲＡＰ”に対しては、次の非バッファ・キーフレームから開始して、メディアを送信すべきである。それ故、送信で遅延を避けることに対する要求は全く無い。実際、これは、第一のキーフレームを送信するまで、オーディオ送信のみで生じる可能性がある。

上記の実施形態によれば、所定の開始フレームに対する要求をＲＴＳＰ ＰＬＡＹ要求に含めるが、しかしながら、ＳＥＴ ＰＡＲＡＭＥＴＥＲまたは幾つかの将来の定まらないＲＴＳＰ要求のような幾つかの他のＲＴＳＰ要求に含めることも（または代わりにすることも）できる。

以下に、本発明の２〜３の実施形態例について、顧客またはユーザ端末およびサーバに整合する説明に適当に分割して述べる。

顧客／ユーザ端末の例
ブロードキャスト−＞ユニキャスト、同一チャネルへのチャネル切換
ブロードキャスト・ソースからのチャネルのメディア・ストリームから、同じメディア・ストリームおよびユニキャスト・ソースを経由して供給されるチャネルに切り換える決定の後、顧客はメディア・フレームの送信を要求し、メディア・ストリームのどこで本送信を開始すべきかを示すインジケーションを供給する。

この例によれば、顧客は、ＲＴＳＰ ＰＬＡＹ要求で開始−位置−形式パラメータを“ｎｅｘｔＲＡＰ”に設定し、供給する。この方法では、顧客は非バッファのユニキャスト・ストリームを要求している。次に、端末は、ブロードキャストおよびユニキャスト・ストリームを短期間同時に聞くことができる。一度、各ストリームのＮＴＰからＲＴＰへのタイムスタンプ・リンクを知ると、顧客はストリームを同期させ、第一のＲＡＰのユニキャストに切り換えることができる。

もしこのチャネル切換がブロードキャスト・サービス範囲の損失によるのであれば、またはもし顧客が、コンテンツを厳密に同じ方法で符号化していること知っていれば、キーフレームで切り換えることは常に利点のあることではない。これらの場合には、開始−位置−形式パラメータをｉｎｓｔａｎｔに設定し、即ち、余分の遅延を持ち込まずに、また、もし本フレームがキーフレームであっても、そうでなくてもにかかわらず、非バッファ・メディア・フレームの送信を要求することができる。

パケット間で１対１の対応があるよう、両方のストリームを厳密に同じ方法で符号化しているアクセス切換の場合、キーフレームまたはＲＡＰを待つ必要もない。新しいストリームのパケットを受信するごとに、ユーザ端末は簡単に切り換えることができる。この場合、開始−位置−形式値Ｉｎｓｔａｎｔを使用するであろう。

上記状況を概略的に示す信号伝達図を図５に示す。ユーザ端末はチャネル切換を検出し、切換形式を決定するが、この場合、チャネルは同じであるが、送信ソースはブロードキャストからユニキャストに変化する。それ故、ユーザ端末はメディア・サーバにＲＴＳＰ ＰＬＡＹ要求を送信する。本要求には、“ｎｅｘｔＲＡＰ”を示す値を有する開始−位置−形式パラメータを含み、それ故非バッファのユニキャスト・メディア・ストリームを要求する。メディア・サーバでは、本要求およびそのインジケーションを処理し、メディア・サーバは、次に続く非バッファのＲＡＰで始まるメディア・ストリームを送信する。最後に、メディア・コンテンツがユーザ端末でレンダリングされる。

（ユニキャスト、異なるチャネルへのチャネル切換）
ブロードキャストの一つのチャネルからユニキャストのもう一つのチャネルへ同時に切り換える場合、チャネルを見始めるためにキーフレームを受信する必要がある。このため、顧客端末は、最近バッファしたキーフィレームで始まる新しいチャネルの送信を要求する。それ故、開始−位置−形式パラメータを“ｌａｓｔＲＡＰ”に設定する。

上述の状況を示す信号伝達図を図６に示す。ユーザ端末はチャネル切換を検出し、切換形式を決定するが、この場合、チャネルは新規であり、送信ソースはブロードキャストからユニキャストに変化する。それ故、ユーザ端末はメディア・サーバにＲＴＳＰ ＰＬＡＹ要求を送信する。本要求には、“ｌａｓｔＲＡＰ”を示す値を有し、それ故、バッファしたユニキャスト・メディア・ストリームを要求する開始−位置−形式パラメータを含む。メディア・サーバで本要求とそのインジケーションを処理し、メディア・サーバは、最近バッファしたＲＡＰで始まるメディア・ストリームを送信する。最後に、メディア・コンテンツがユーザ端末でレンダリングされる。

使用例（サーバ）
本発明の方法が実際に希望の結果を提供するため、送信要求にある入力開始フレームのインジケーションを解釈し、応答できるよう、メディア・プロバイダまたはサーバを構成する必要がある。

サーバが“ｉｎｓｔａｎｔ”に設定した開始−位置−形式パラメータを受信する場合、サーバは直ちにそのライブ・メディア・ストリームを送信する。

サーバが “ｌａｓｔＲＡＰ”に設定した開始−位置−形式パラメータを受信する場合、サーバはキーフレームまたはＲＡＰと、全チャネルの後続パケットをバッファし、高速切換ができるようにする。そのようなコマンドを受信して、サーバは、最近バッファしたキーフレームで始まるデータの送信を開始する。また、サーバはメディアを同期させ、それらの全ての送信を開始しなければならない。

最後に、サーバが “ｎｅｘｔＲＡＰ”に設定した開始−位置−形式パラメータを受信する場合、サーバは次のキーフレームをひとたび受信すると、非バッファ・データの送信を単に開始する。

本発明による方法の一つの更なる実施形態は、希望の開始フレームを示す顧客端末の代わりである可能性があり；それは、希望のタイムスタンプを単に提示する可能性がある。ネットワーク遅延を多分考慮し、ＮＴＰ時間、タイムスタンプ、または他の時間を使用して、開始時間を特定する可能性がある。もしサーバが要求タイムスタンプに対応してバッファしたデータを持つなら、そのデータから送信を開始できるであろう。

全てのＦＥＣが誘起する送信遅延の変動を削減するため、潜在的に全チャネルを遅延させることができる。

本発明によるノード例えば、顧客またはユーザ端末について、図７を参照して説明する。

ユーザ端末１０は、必須のまたは選択的なチャネル切換を検出するため、選択的なユニット１１を潜在的に備える。さらに、端末１０には、ユニキャスト送信ソースまたはサーバからメディア・ストリームの送信を要求するため、ユニット１２を含む。特別な実施形態によれば、送信のための開始フレームを示す要求を提供するために、要求ユニット１２を構成する。ＲＳＴＰ ＰＬＡＹまたは同様な機能を有する幾つかの他のプロトコル特定要求のようなメッセージに、本要求を備えることができる。

加えて、本端末には、要求メディア・ストリームを受信し、見るために必要な全てのユニットを備える。

選択的にまたは追加して、送信条件をモニタし、検出ユニット１１への必要な切換に関する情報を提供する外部システム・モジュールとして、モニタ・ユニット１３を提供することができる。また、ユーザ端末からのフィードバック情報を受信するよう、このモニタ・モジュール１３を構成することができるであろう。

本発明によるメディア・送信サーバまたはソースについて、図８を参照して説明する。

メディア・サーバ２００には、顧客端末からのメディア・ストリームの送信の要求を受信するため、ユニット２１を備える。さらに、サーバ２００には、受信要求のインジケーションに基づき、所定の開始フレームを有するメディア・ストリームを送信するため、ユニット２２を備える。

本発明の利点には以下が含まれる。：
・ブロードキャストとユニキャスト間のユーザ認知の継ぎ目のない移行。
・ライブ・ユニキャスト・メディア・ストリームのどこで開始を希望するか、顧客がサーバに信号伝達を可能とすること。
・ＲＴＳＰサーバは、高速ユニキャスト・チャネル切換と、ユニキャスト移行または他のアクセス移行への継ぎ目のないブロードキャストとを合成することができること。各チャネルを一度だけ符号化し、バッファリングを使用して高速切換を実行するサーバ上で、これを行うことができる。
・現行のメッセージ内の新しいヘッダによって開始フレームのインジケーションを示す本発明の実施形態により、本発明を実装していないサーバは、ヘッダを簡単に無視するようにできること。それによって、本発明は、全てのバックワード互換性の問題を持たない解決策を提供する。

本発明について、ブロードキャストからユニキャスト・メディア送信ソース間のチャネル切換に関して主として議論したが、全く新しいユニキャスト・セッションを設定する状況にも等しく（小さな修正で）適用できる。同様に、チャネル切換がユニキャスト・セッション内で起こるような状況においても、本発明を適用できる。

当業者には理解されるであろうが、添付の特許請求の範囲が定める本発明の技術的範囲から逸脱すること無しに、本発明に対して各種の修正と変更を行ってもよい。

Claims (24)

1. 通信システムにおいてメディア・セッションを管理する方法であって、
   少なくとも一つのユーザ端末は、ブロードキャスト・メディア・ソースと別個に設けられたユニキャスト・メディア・ソースからの少なくとも一つのメディア・ストリームの送信を要求する能力を有し、
   前記ユーザ端末が、前記メディア・ストリームの受信の開始後にチャネル切換を検出して（Ｓ０）、当該検出した切換の切換形式を決定する工程（Ｓ００）と、
   前記ユーザ端末が、前記送信を行う所定の開始フレームを示すインジケーションを供給することにより、前記少なくとも一つのメディア・ストリームの送信を要求する工程（Ｓ１）と、
   前記ユニキャスト・メディア・ソースが、前記インジケーションに基づき前記少なくとも一つのメディア・ストリームを送信する工程（Ｓ２）と
   を有し、
   前記切換形式には、前記ブロードキャスト・メディア・ソースに関連するチャネルと前記ユニキャスト・メディア・ソースに関連するチャネルとの間のチャネル切換が含まれ、
   前記送信を要求する工程（Ｓ１）においては、所定のタイムスタンプを有するメディア・フレームで始まる前記メディア・ストリームを送信するよう要求する
   ことを特徴とする方法。
2. 前記送信を要求する工程（Ｓ１）においては、前記ユーザ端末が、前記ブロードキャスト・メディア・ソースと関連するチャネルから前記ユニキャスト・メディア・ソースのチャネルへ切り換えることに応じて、前記送信を要求することを特徴とする請求項１に記載の方法。
3. 前記送信を要求する工程（Ｓ１）においては、前記ユニキャスト・メディア・ソースを用いて新しいメディア・セッションを開始することに応じて、前記送信を要求することを特徴とする請求項１に記載の方法。
4. 各メディア・ストリームは１のチャネルに対応し、当該チャネルに対応するメディア・ストリームに対するメディア・ソースは、前記ブロードキャスト・メディア・ソースから前記ユニキャスト・メディア・ソースに切り替えられることを特徴とする請求項２に記載の方法。
5. 前記ブロードキャスト・メディア・ソースと関連するチャネルと、前記ユニキャスト・チャネルとが異なるチャネルであることを特徴とする請求項２に記載の方法。
6. 前記送信を要求する工程（Ｓ１）においては、最近バッファした自己完結メディア・フレームから始まる前記メディア・ストリームのユニキャスト・メディア・フレームを即時送信するよう要求することを特徴とする請求項５に記載の方法。
7. 前記送信を要求する工程（Ｓ１）においては、前記メディア・ストリームのユニキャスト・メディア・フレームを即時送信するよう要求することを特徴とする請求項４に記載の方法。
8. 前記送信を要求する工程（Ｓ１）においては、次の自己完結メディア・フレームで始まる前記メディア・ストリームのユニキャスト・メディア・フレームを送信するよう要求することを特徴とする請求項４に記載の方法。
9. 前記自己完結メディア・フレームは、イントラフレーム、キーフレームまたはランダム・アクセス・ポイント（ＲＡＰ）であることを特徴とする請求項６に記載の方法。
10. ＲＴＳＰ ＰＬＡＹ要求に前記要求を包含させる工程を有すること特徴とする請求項１に記載の方法。
11. 前記包含させる工程には、前記ＲＴＳＰ ＰＬＡＹ要求にヘッダを備えさせることが含まれることを特徴とする請求項１０に記載の方法。
12. 前記インジケーションは、前記ヘッダのパラメータ値を備えることを特徴とする請求項１１に記載の方法。
13. 通信システムにおけるユーザ端末（１０）であって、
    前記ユーザ端末は、ブロードキャスト・メディア・ソースと別個に設けられたユニキャスト・メディア・ソースから少なくとも一つのメディア・ストリームを送信することを要求する能力を有し、
    前記メディア・ストリームの受信の開始後にチャネル切換を検出し、切換形式を決定する手段（１１）と、
    前記送信を行う所定の開始フレームを示すインジケーションを供給することにより、前記少なくとも一つのメディア・ストリームの送信を要求する手段（１２）と
    を備え、
    前記切換形式には、前記ブロードキャスト・メディア・ソースに関連するチャネルと前記ユニキャスト・メディア・ソースに関連するチャネルとの間のチャネル切換が含まれ、
    前記要求する手段（１２）は、所定のタイムスタンプを有するメディア・フレームで始まる前記メディア・ストリームの送信を要求する
    ことを特徴とするユーザ端末。
14. 前記要求する手段（１２）は、前記ブロードキャスト・メディア・ソースに関連するチャネルから前記ユニキャスト・メディア・ソースのチャネルに前記ユーザ端末が切り換わることに応じて、前記送信を要求することを特徴とする請求項１３に記載のユーザ端末。
15. 前記要求する手段（１２）は、ユニキャスト・メディア・ソースを用いて新しいメディア・セッションを初期化することに応じて、前記送信を要求することを特徴とする請求項１３に記載のユーザ端末。
16. 各メディア・ストリームは１のチャネルに対応し、当該チャネルに対応するメディア・ストリームに対するメディア・ソースは、前記ブロードキャスト・メディア・ソースから前記ユニキャスト・メディア・ソースに切り替えられることを特徴とする請求項１４に記載のユーザ端末。
17. 前記ブロードキャスト・メディア・ソースに関連するチャネルと、前記ユニキャスト・チャネルとが異なるチャネルであることを特徴とする請求項１４に記載のユーザ端末。
18. 前記要求する手段（１２）は、最近バッファした自己完結メディア・フレームから始まる前記メディア・ストリームのユニキャスト・メディア・フレームの即時送信を要求することを特徴とする請求項１７に記載のユーザ端末。
19. 前記要求する手段（１２）は、前記メディア・ストリームのユニキャスト・メディア・フレームの即時送信を要求することを特徴とする請求項１６に記載のユーザ端末。
20. 前記要求する手段（１２）は、次の自己完結メディア・フレームで始まる前記メディア・ストリームのユニキャスト・メディア・フレームの送信を要求することを特徴とする請求項１６に記載のユーザ端末。
21. 通信システムにおけるユニキャスト・メディア・ソース（２００）であって、
    少なくとも一つの請求項１４に記載のユーザ端末は、ブロードキャスト・メディア・ソースと別個に設けられたユニキャスト・メディア・ソースからの少なくとも一つのメディア・ストリームの送信を要求する能力を有し、
    前記少なくとも一つのメディア・ストリームの送信の前記要求であって、送信を行う所定の開始フレームを示すインジケーションを有する要求を受信し、処理する手段（２１）と、
    前記処理したインジケーションに基づいて、前記メディア・ストリームのメディア・フレームで始まる前記少なくとも一つのメディア・ストリームを、前記少なくとも一つのユーザ端末に送信する手段（２２）と
    を備え、
    前記インジケーションは決定された切換形式に基づき、
    前記切換形式には、前記ブロードキャスト・メディア・ソースに関連するチャネルと前記ユニキャスト・メディア・ソースに関連するチャネルとの間のチャネル切換が含まれ、
    前記送信する手段（２２）は、所定のタイムスタンプを有するメディア・フレームで始まる前記メディア・ストリームを送信する
    ことを特徴とするユニキャスト・メディア・ソース。
22. 前記送信する手段（２２）は、前記ユーザ端末によるメディア・ストリームの受信の開始後に、前記ユニキャスト・メディア・ソースに最近バッファされた自己完結メディア・フレームから始まる前記メディア・ストリームのユニキャスト・メディア・フレームを即時に送信することを特徴とする請求項２１に記載のユニキャスト・メディア・ソース。
23. 前記送信する手段（２２）は、前記メディア・ストリームのユニキャスト・メディア・フレームを即時に送信することを特徴とする請求項２１に記載のユニキャスト・メディア・ソース。
24. 前記送信する手段（２２）は、次の自己完結メディア・フレームで始まる前記メディア・ストリームのユニキャスト・メディア・フレームを送信することを特徴とする請求項２１に記載のユニキャスト・メディア・ソース。

Images