JP2008530835A

JP2008530835A - パケット交換ネットワーク上のオンデマンドマルチチャネルストリーミングセッション

Info

Publication number: JP2008530835A
Application number: JP2007553477A
Authority: JP
Inventors: ウベホルン，; トルステンローマル，
Original assignee: テレフオンアクチーボラゲットエルエムエリクソン（パブル）
Priority date: 2005-02-08
Filing date: 2005-02-08
Publication date: 2008-08-07
Also published as: WO2006084503A1; US20080151885A1; CN101116306A; EP1847087A1

Abstract

本発明は、一つのオンデマンドマルチチャネルストリーミングセッションに属しているチャネル間の切り替えのための解決策を提供する。複数のチャネルに対応する複数のセッション記述パラメータを一つの単一セッション記述へと集めるための収集手続が提案される。また、各チャネルは、チャネル切り替え要求およびタイトル・バーまたはチャネル選択メニュー中の、人間が読み取れる表示用のオプションの識別子中で参照できる、必須の固有の識別子によって記述される。対応するクライアントアプリケーションは、チャネル束を記述するＳＤＰを処理し、見いだされた情報を用いて、ユーザが、ある識別子に関連づけられたチャネルへ切り替えることを許す。チャネル切り替え要求の送信は、好適にはＲＴＳＰＳＥＴＰＡＲＡＭＥＴＥＲメッセージを介して、あるいはその代わりとしてＨＴＴＰによる帯域外を介して行われる。マルチチャネルストリーミングサーバの一部であるチャネル切り替え制御ユニットは、多くのＲＴＰフローを受信し、クライアントに転送するためにフローから一つを選択する。切り替えポイントの決定は、チャネル切り替え制御ユニットの一部であり、要求されたチャネルへ切り替えるために次の可能な時点を決定する。クライアントアプリケーションはチャネル切り替え要求に応じて、切り替えポイントについての時間情報を受信する。

Description

本発明は、パケット交換通信システムにおけるマルチチャネルリアルタイムストリーミングサービスの性能向上のための解決策を提供する。

特に、本出願は無線パケット交換通信ネットワークにおけるテレビサービスに適用可能である。そうではあるが、同じ原理はどのような種類のマルチチャネルサービスにでも適用可能である（そのマルチチャネルサービスは、スクリーンの上で表示される１つのチャネルをエンドユーザが選ぶことができる多数のコンテンツチャネルを提供する）。モバイルテレビサービスは別として、現在スリーイタリー（Ｔｈｒｅｅ−Ｉｔａｌｙ）によって提供された「ＭｏｂｉｌｅＢｉｇＢｒｏｔｈｅｒ」サービスの中で提供されるように、これは、例えば異なるライブカメラの間で選ぶケースである。

ユニバーサルモバイルテレコミュニケーションシステムＵＭＴＳは、インターネットプロトコルを使って、ワイヤレスワイドバンドマルチメディアサービスを提供するために開発されている。第三世代の３Ｇのモバイル通信としてのＯＭＴＳはストリーミングを固有のサービスの範囲と結合する。イメージ、音声、オーディオ、およびビデオコンテンツはマルチメディアサービスの例である（それはユーザにメディアストリーミングおよびダウンロード技術によって提供される。すなわち、コンテンツがメディア・サーバの上に置かれたら、それがダウンロードまたはストリーミング経由で、要求に応じて提供され得ることを意味する）。コンテンツをダウンロードするために、ユーザはリンクをクリックし、コンテンツがダウンロードされ再生が始まるのを待つ。ストリーミングデータにアクセスするために、ユーザはリンクをクリックして再生を始める（それはほとんど即時である）。ユーザがコンテンツの選択に影響を及ぼすので、この種類のオンデマンドサービスはパーソナライズされたオンデマンドストリーミングと呼ばれる。ＵＭＴＳにおけるケースのように、特に、サービスがほとんどまたは全くサービス品質（ｑｕａｌｉｔｙｏｆｓｅｒｖｉｃｅ）のないネットワーク上で動作する場合、ストリーミングはデータの受信と同時に再生する準リアルタイムサービスであるという事実が、プロトコルおよびサービスの実装への要求を大きくする。さらに送信の最後の部分で使われる電波資源は効率的な方法で使われるべきである。

パケット交換網の中のストリーミングサービスは、いわゆるユニキャスト接続によって単一のユーザに、またポイントツーマルチポイントあるいはマルチポイントツーマルチポイント接続によってユーザのグループに提供されるかもしれない。ポイントツーマルチポイントのサービスは、ネットワークインフラストラクチャへの要求が高く、かなりの量の帯域幅を消費する可能性がある。そのようなサービスのいくつかの例は、テレビ会議、ホワイトボード、リアルタイムのマルチユーザゲーム、マルチメディアメッセージング、仮想世界、またはテレビ放送である。この種のポイントツーマルチポイントアプリケーションは送信のためにブロードキャストまたはマルチキャストモードを使う。ブロードキャストは、パケットを、ネットワークの上のすべてのユーザのようにすべての宛先に宛てる可能性がある。マルチキャストによって、コンテンツはマルチキャストグループに登録されているユーザのグループに提供される。しかし、現在のネットワークの発展では、ブロードキャスト転送技術における、ストリーミングサービスを利用するための能力はいまだに提供されていない。

つい最近、新しいタイプのオンデマンドストリーミングサービス（すなわち、パーソナライズされたオンデマンドストリーミングのために使用されているのと同じストリーミング技術に基づいて、ユーザが彼らの携帯電話の上のテレビを見ることを可能にする、いわゆるモバイルＴＶサービス）が、無線ワイヤレスパケット交換網中で開始されている。

しかし、オンデマンドストリーミングとテレビストリーミングはユーザビリティ面において異なっている。オンデマンドストリーミングサービスにおいて、あるコンテンツが見つかるまで、ユーザはコンテンツをブラウズする。その後、ストリーミングセッションは設立される。そのセッションの間には、メディア・サーバに蓄えられているコンテンツのストリームがユーザの端末に提供される。ストリームが終わった後に、ストリーミングセッションは終わり、ユーザは次のコンテンツをブラウズする。

モバイルテレビサービスにおいて、コンテンツは一般にメディア・サーバに予め蓄えられてははない。その代わりに、コンテンツはテレビチャネルによって提供されたシグナルからライブでエンコードされる。

最近では、モバイルテレビサービスは、既存のストリーミング技術に基づいて実装される。これは、各チャネルは別個のストリーミングセッション経由でアクセスされることを意味する。しかし、既存のストリーミング技術は、モバイルテレビの解決策において必要とされる、迅速なチャネルの切り換えをサポートしない。その代わりに、別のチャネルに切り替えるには、まず現在のチャネルを提供するセッションを終わらせる必要があり、それから新しいチャネルを選ぶためのＷＡＰまたはＷｅｂページに戻り、最後に新しいストリーミングセッションを設立する。セッションが設立された後、再生が始まる前に、クライアントは一定の期間（５秒のオーダー）の間にデータをバッファする。

新しいセッションのセットアップ前の現在のストリーミングセッションの切断と、新たなセッションの設立後の最初のバッファリング遅延とが一緒になって、チャネル間で切り替えを行うための約２０から３０秒の遅延を生じる。これは、ユーザが、家庭における彼らのテレビの経験から有する予想に比べて明らかに大きすぎる。従って、問題は基本的に、進行中のオンデマンドストリーミングセッションのチャネルの間で切り換えをユーザに行わせる柔軟なメカニズムがネットワークの中にないことである。現在、オンデマンドサービスのコンテンツを提供しているチャネル間の切り替えは、進行中のセッションが最初に閉じ、新しいチャネルのための新しいセッションがセットアップされることを必要としている。あるストリーミングセッションを閉じて、新しいものを設定することは数秒の遅延をまねく。新しいストリーミングセッションが設立された後に、再生が始まるまで、クライアントは一定の期間の間に着信パケットをバッファする。

本発明の目的は、通信ネットワークの中で時間的な効率の良いオンデマンドマルチチャネルストリーミングサービスを提供するための解決策を提供することにある。特に、進行中のオンデマンドストリーミングセッションの間のチャネル切り替えの遅延を縮小することを本発明の目的としている。

請求項１、１０、１５、１６、および１７において開示されている方法に本発明は具現化される。有効な実施形態は従属請求項において説明される。

本発明の基本的な考え方は、同じサービスに属している違うチャネルにアクセスするための別個のストリーミングセッションを避けることである。これは、選択されたチャネルに属しており、最初にそれらののＲＴＰパケットだけがエンドユーザに転送されるただ１つのストリーミングセッションを設立することによって達成される。

本発明は、サーバ側で記述される方法を記述している請求項１においてクレームされている。請求項１０には、ユーザノードで実行されるステップをクレームしている方法が記載されている。請求項１５にはユニットを持つサーバがクレームされ、請求項１６には、ユーザノードのユニットがクレームされている。

本発明において記述された方法は、最先端の解決策に比べて、パケット交換のストリーミング経由で提供されたチャネル間の切り替えの遅延を相当小さくできるという利点を持っている。さらに、本発明は、既存のネットワークノードの中で、セッション記述プロトコル（ＳＤＰ）のような既存のプロトコルと最小限度の影響で統合することができる。

チャネル切り替えがクライアントに対してトランスペアレントな方法でされるので、既存のストリーミングクライアントの実装への影響も最小限となる。

以下、本発明の詳細な説明を行う。

以下において、本発明の好適な例は、本発明についての一通りの完全な理解を当業者に提供するために詳細に説明されるが、これらの詳細な実施形態はただ発明の例として役立つもので、発明の制限を意図していない。以下の説明は添付された図面を参照している。

本発明の文脈の中の「ユーザ」、「サーバ」、「クライアント」、または一般に「ノード」という用語が、通信ネットワークの中で所定の機能を提供するためのハードウェアとソフトウェアのどのような適当な組み合わせをも指すことに注目すべきである。このように、前述の用語は一般に、ネットワークのいくつかの物理的なノードの上で展開することができる論理構成体を指すけれども、また１つの物理的なノードに置かれた物質的なエンティティを指すこともある。用語「クライアント」と「ユーザ」が同義語として使われることにも注意すべきである。

さらに、用語「パケット交換」「オンデマンドストリーミング」が、多数のコンテンツチャネルを提供するどのような種類のサービスも指すことは注目されるべきである。好適な実施形態はテレビのようなサービスである。

好ましくは、通信ネットワークはモバイル通信ネットワークであり、たとえば、ＧＰＲＳ（ＧｅｎｅｒａｌＰａｃｋｅｔＳｗｉｔｈｅｄＲａｄｉｏ）またはＵＭＴＳ（ＵｎｉｖｅｒｓａｌＭｏｂｉｌｅＴｅｌｅｐｏｎｅＳｙｓｔｅｍ）またはＧＳＭに従って動作するモバイル通信ネットワークである。しかし、本発明は、ストリーミングサービスを提供する能力を持ついかなる通信ネットワークの中ででもまた適用可能である。以下において、モバイル・ネットワークと関連している実施形態が開示される。しかし、それに限定されると考えられるべきでない。さらなる例はどのようなＩＰベースの通信ネットワークにもある。

以下において、サーバ側で実行されるステップは図１について示される。図１は、本発明の実施形態において、進行中のオンデマンドストリーミングセッションの間にチャネル切り替えをサーバ側で実行するためのフローチャートである。ステップＳ１１の中で、集められたチャネル束セッション記述はユーザに提供される。その集められたチャネル束セッション記述は前記束の一部であるチャネルの固有の識別子を含む。集められたチャネル束セッション記述は、多くのチャネルを有するオンデマンドストリーミングセッションをユーザに知らせるためにユーザに送られる。ユーザがセッションの受信に関心がある場合、ユーザノードとサーバの間のストリーミングセッションは、集められたチャネル束セッション記述をそのセッションの識別子として用いて設立される（ステップＳ１２）。そして、ユーザが利用可能なチャネルの間の切り替えを望む場合、対応するメッセージ、すなわちチャネル切り替え要求メッセージは、第１のチャネルから第２のチャネルへの切り替えを要求しているユーザノードから送られる（Ｓ１３）。その後、チャネル切り替え手続は実行される。切り替え手続の中で、チャネル切り替えを実行するための適切な切り替えポイントは決定される（Ｓ１４）。後述の説明においてより詳細に説明されるように、画質の不要な劣化を避けるために適切なスイッチポイントを選ぶことは重要である。ステップＳ１５によって、２番目のチャネルのメディアデータはユーザに提供され、供給の開始ポイントは、決定された切り替えポイントによって決定される（Ｓ１５）。

対応するステップは、ユーザ側でも実行されるべきである。これらのステップは図２について以下において説明される。ユーザノードは、設立されている単一のチャネル束セッション記述をサーバから受け取る（Ｓ２１）。単一のチャネル束セッション記述を受けとることで、ユーザノードは、前記セッション記述で記述されている利用可能なチャネルについての情報を持つ。ユーザノードが、これらのチャネルのひとつのコンテンツを受け取ることを望む場合、ユーザノードとサーバとの間のストリーミングセッションが設立される（Ｓ２２）。束の一部であるチャネル間で切り替えを行うために、チャネル切り替え要求メッセージが、第１のチャネルから第２のチャネルに切り換えるためにサーバに送られる（Ｓ２３）。このメッセージを受け取ると、前述したチャネル切り替えを行うために適した切り替えポイントを判断するためのチャネル切り替え手続きがサーバにおいて開始される。サーバのチャネル切り替え手続の実行の後に、ユーザは、決定された切り替えポイントで始まる第２のチャネルのコンテンツを受け取ることができる（Ｓ２４）。メディアパケットの形式で受信したコンテンツは、引き続いてデコードされ、それらを再生するユーザインターフェイスに提供される。

以下において、本発明の好適な実施形態は図３で説明される。図３中のボックスはストリーミング伝送技術の上でモバイルテレビの供給に関連しているノードを表している。ノードの間の矢印はノードの間で実行されている通信ステップを示す。

まず最初に、好適な実施形態の説明のために関連して使われた用語と機能を詳細に説明する。

ストリーミングデータはストリーミングプロトコルによって、特にリアルタイム転送プロトコル（ＲＴＰ）によって配布される。ＲＴＰは、マルチキャストまたはユニキャストのネットワークサービス上でオーディオとビデオなどのリアルタイムマルチメディアデータを送信しているアプリケーションに適したエンドツーエンドネットワーク転送機能を提供する。ＲＴＰによって提供された機能には、ペイロードタイプ識別、連続ナンバリング、タイムスタンプ、および配送監視を含む。ＲＴＰは、データ伝送を増やし、ＱｏＳを監視するためと進行中のセッションに参加者についての情報を伝えるために使われる、関連したＲＴＰ制御プロトコル（ＲＴＣＰ）を含んでいる。会議の中の各メディアストリームは別個のＲＴＣＰストリームによって別個のＲＴＰセッションとして送られる。リアルタイムストリーミングプロトコル（ＲＴＳＰ）は、ストリーミングセッションの間にセッション制御を提供し、ストリーミング接続の設立に責任がある。特に、ＲＴＳＰは、ビデオとオーディオなどの連続的なメディアの単一のまたはいくつかの、時間に同期したストリームを設立し、制御する。すなわちＲＴＳＰは、マルチメディアサーバのために「ネットワーク遠隔制御」として作動する。ＲＴＳＰはいかなる転送プロトコルとも結びつかない。そのことは、ＴＣＰと同様にＵＤＰを転送目的のために使用できることを意味している。さらに、ＲＴＳＰによって制御されたストリームはストリーミングデータの転送目的のためにＲＴＰを使うことができる。例えば、映画コンテンツを見ることなどの完全なＲＴＳＰセッションは、クライアントが、例えばＲＴＳＰＳＥＴＵＰメッセージによって転送手段をセットアップし、ＰＬＡＹによってストリーミングを開始させ、ＴＥＡＲＤＯＷＮによってセッションを閉じることで構成される。図３について、これらのステップはコネクション２４と２５によって説明される。ＲＴＳＰの詳細な説明は、ＲＦＣ２３２６「リアルタイムストリーミングプロトコル」（１９９８年４月、Ｈ．Ｓｃｈｕｌｚｒｉｎｎｅ、Ａ．Ｒａｏ、Ｒ．Ｌａｎｐｈｉｅｒ著）中に見いだせるだろう。

ＲＴＳＰによって制御されるストリームの集合は、たとえばＲＦＣ２３２７「ＳＤＰ：セッション記述プロトコル（Ｍ．Ｈａｎｄｌｅｙ、Ｖ．ジェイコブソン、１９９８年４月）」などに記載されたセッション記述プロトコル（ＳＤＰ）のようなプレゼンテーション説明書に記載されている。

セッション記述の受領者がセッションに参加することを可能にするために、ＳＤＰは、セッション告知（セッションアナウンスメント）またはセッション案内（セッションインビテーション）のためのマルチメディアセッションを記述する。実際、ＳＤＰは、単にセッション記述のためのフォーマットである。それは転送プロトコルを含んでおらず、従って、たとえばＲＴＳＰなどの異なる転送プロトコルを利用することを意図している。ＳＤＰセッション記述は、たとえば使用されたコーデックとビットレートとを記述する、＜ｔｙｐｅ＞＝＜ｖａｌｕｅ＞形式の多数のテキストから構成される完全なテキストである。以下において、ＳＤＰ記述のいくつかのラインが記載されていているが、ここでオプションのアイテムには「＊」がつけられている。
ｖ＝（プロトコルバージョン）
ｏ＝（オーナー／創造者とセッションの識別子）。
ｓ＝（セッション名）
ｉ＝＊（セッション情報）
ｕ＝＊（説明のＵＲＩ）
ｅ＝＊（電子メールアドレス）
ｐ＝＊（電話番号）
ｃ＝＊（接続情報）
ｂ＝＊（帯域幅情報）
ｚ＝＊（タイムゾーン調整）
ｋ＝＊（暗号化キー）
ａ＝＊（０本以上のセッション属性ライン）
ｔ＝（セッションがアクティブな時間）
ｒ＝＊（０倍以上の繰り返し回数）
ｍ＝（メディア名と輸送アドレス）
ｉ＝＊（メディアタイトル）
ｃ＝＊（接続情報）
ｂ＝＊（帯域幅情報）
ｋ＝＊（暗号化キー）
ａ＝＊（０本以上のメディア属性ライン）
好適な実装中で、チャネル束の記述は、ＳＤＰの中で「ｓ＝」ラインに続く、特別にフォーマットされた文字列に入れられる。それに代えて、それはまた別個の構成要素（たとえばＸＭＬ）に入れることもできよう。

図２に戻ると、ＳＤＰ収集部２０Ａは、マルチチャネルストリーミングクライアント（たとえばモバイルテレビアプリケーション）２ＯＢにより処理される、チャネル束記述ＳＤＰ２０Ａ’を提供する。図３の左上に、ライブエンコーダＬＥ＃１からＬＥ＃ｎを示す。各ライブエンコーダは、入力としてアナログビデオ／オーディオ信号を取得し、それはまずデジタル信号に変換されて、それからメディアエンコーダによって圧縮される。結果として生じるビットストリームはパケット化され、ＲＴＰパケットのストリーム（ＲＴＰフロー＃１…ＲＴＰフロー＃ｎ）として、エンドユーザやクライアントが接続できるストリーミングサーバやサーバへ配送される。ストリーミングサーバはチャネル切り替え制御装置２ＯＨを持っている。これについてはさらに詳細に説明する。チャネル切り替え制御装置の中に、チャネル切り替え制御部２０Ｄがあり、それはユーザ側２０Ｃ上の適切なチャネル切り替え制御部と通信する。また、サーバ側のＲＴＳＰ制御部２０１は、ユーザ側のＲＴＳＰ制御部２０Ｊと通信する。サーバからのストリーミングデータは、単一の「モバイルテレビ」ＲＴＰフロー３３から、メディアデコーディング部２０Ｌおよび再生機能部２０ｍを有し、データ３４をユーザデバイス２０Ｎに転送するユニットの一部であるＲＴＰ処理部３３へと転送される。

以下において、ノード間の処理ととそれらの機能は図３で説明される。

すでに説明したように、各ライブエンコーダＬＥ＃１…ＬＥ＃ｎは、入力としてアナログビデオ／オーディオ信号を取得し、圧縮する。結果として生じるビットストリームはパケット化され、ＲＴＰフローとしてサーバへ提供される。各ライブエンコーダはまたＳＤＰファイル（ＳＤＰ＃１…ＳＤＰ＃ｎ）を作り出す。それらは、ライブエンコーダによって生成されたストリームの記述を含んでいる。典型的なＳＤＰの例を以下に示す。
v=0
o=ライブエンコーダ16843009 1IN IP4 127.0.0.1
s=Channel One
C=IN IP4 192.168.16.254
t=0 0
b=AS: 128
a=control:*
a=range:npt=0-
m=video 6950 RTP/AVP 96
b=AS: 128
a=rtpmap:96 MP4V-ES/90000
a=control:trackID=1
a=range:npt=0-
a=fmtp：96profile-level-
id=8;config=000001B008000001B50900000100000001200084400668282078A21F
ここで、「ｓ＝」を含むラインはストリームを記述する文字列を含んでいて、この場合に、それは「ＣｈａｎｎｅｌＯｎｅ」である。ストリーミングクライアントは通常この情報をビデオウィンドウの上または下のタイトル・バーに入れる。

ＳＤＰ収集部２０Ａの目的は、ライブエンコーダＬＥ＃１…ＬＥ＃ｎの複数のＳＤＰ（ＳＤＰ＃１…ＳＤＰ＃ｎ）から単一のＳＤＰ２０Ａ’を生成することにある。このＳＤＰは、サービスを制御するためにクライアントとサーバで必要なすべての情報を含んでいる。様々なＳＤＰファイルの中で適切な属性ラインを比較することによって、ＳＤＰ収集部は、チャネル束の中で、全チャネルが同じコーデックと同じビットレートでエンコードされることを確認する。それからＳＤＰ収集部は、完全なチャネル束を記述する単一のＳＤＰを生成する。

好適な実施形態において、完全なチャネル束を記述する新しいＳＤＰ２０Ａ’は、標準的なＳＤＰのように見える。収集されたチャネルについての情報はすべて「ｓ＝」属性ラインの中に含まれている。

クライアントにおけるソフトウェア実行によって解釈できる、特別にフォーマットされた文字列を使うことがアイデアである。その文字列は、ライブエンコーダによって生成されたＳＤＰから取得された人間が読み取り可能なチャネル識別子とともに、チャネルを参照できるユニークな識別子をチャネルごとに含んでいる。例えば、２つのチャネル「ＣｈａｎｎｅｌＯｎｅ」と「ＣｈａｎｎｅｌＴｗｏ」があるとする。「ＣｈａｎｎｅｌＯｎｅ」は前述のＳＤＰ記述によって記述される。「ＣｈａｎｎｅｌＴｗｏ」は以下のＳＤＰによって記述される。
v=0
o=Live Encoder 16843009 1IN IP4 127.0.0.1
s=Channel Two
c=IN IP4 192.168.16.254
t=0 0
b=AS:128
a=control:*
a=range:npt=0-
m=video 6952 RTP/AVP 96
b=AS:128
a=rtpmap:96 MP4V-ES/90000
a=control:trackID=1
a=range:npt=0-
a=fmtp：96 profile-level-
id=8;config=000001B008000001B50900000100000001200084400668282078A21F
このため、ふたつのＳＤＰ記述の唯一の違いは、「ｓ＝」および「ｍ＝」ラインにある。「ｓ＝」は、チャネル識別子として「ＣｈａｎｎｅｌＯｎｅ」の代わりに「ＣｈａｎｎｅｌＴｗｏ」を含んでいて、「ｍ＝」ラインは、ＲＴＰパケットが配送されるＲＴＰポート番号として、６９５０の代わりに６９５２を含んでいる。それらの２つが同じポート番号を使わないようにライブエンコーダが設定される必要があることに注意が必要である。

すでに述べたように、ＳＤＰ収集部の仕事は、ふたつのＳＤＰを新しいひとつに併合することである。それは以下のようなものである。
v=0
o= Live Encoder 16843009 1 IN IP4 127.0.0.1
s=1：Channel One; 2:Channel Two
C=IN IP4 192.168.16.254
t=0 0
b=AS:128
a=control:rtsp://mobiletv.com/Bundle-1
a=range:npt=0-
m=video 0 RTP/AVP 96
b=AS:128
a=rtpmap:96 MP4V-ES/90000
a=control:rtsp://mobiletv.com/Bundle-1:trackID-1
a=range:npt=0-
a=fmtp：96 profile-level-
id=8;config=000001B008000001B50900000100000001200084400668282078A21F
ここで、「ｓ＝」ラインは文字列「１：ＲＡＩＵｎｏ；２：ＲＡＩＤｕｅ」を含んでいる。また、「ｍ＝」ラインは新しいポート番号として０を含んでいる。これは、ＲＴＳＰセッションが設立される時に、ポート番号が協議されることを示す。構成文字列は、この束が、それぞれユニークな識別子「１」と「２」によって参照される２つのチャネル「ＣｈａｎｎｅｌＯｎｅ」および「ＣｈａｎｎｅｌＴｗｏ」を含んでいることをクライアントに示す。さらに、完全に記述されたＲＴＳＰコントロールのＵＲＬを持つ「ａ＝」ラインが追加された。

図３に戻り、チャネル束を記述しているＳＤＰを様々な方法でクライアントに提供することができる。クライアントは例えばｈｔｔｐ：／／ｍｏｂｉｌｅｔｖ．ｃｏｍ／Ｂｕｎｄｌｅ−１ｓｄｐなどのＵＲＬｈｔｔｐアドレスを使っているＷｅｂサーバからＳＤＰをダウンロードすることができる。

それに代えて、クライアントはまず最初に、例えば上記の例におけるｒｔｓｐ：／／ｍｏｂｉｌｅｔｖ．ｃｏｍ／Ｂｕｎｄｌｅ−１などのＲＴＳＰＵＲＬを受け取り、それからＳＤＰはＲＴＳＰセッションのセットアップの間にクライアントに提供される。図３において、これは、記述文字列をモバイルテレビアプリケーション２０Ｂに転送することによって、コネクション２２’で行われる。モバイルテレビアプリケーションは文字列を構文解析し、それから利用可能なチャネルのリストを生成する。

利用可能なチャネルのリストは、チャネル選択メニューの中のユーザ要求の上に表示することができる。このリストの登録事項は、ビデオウィンドウの上または下のタイトル・バーの中でチャネル識別子を表示するためにまた使われる。

ユーザはまた、電話の特定のキーにこのリストの登録事項を対応づけることができる。

このように、携帯電話のキーボードはリモートコントロールのように使用され、プログラムされることができる。

ＲＴＳＰセッションの設立のために、クライアントは、ＳＤＰファイルからのＲＴＳＰＵＲＬ、またはストリーミングセッションをセットアップするためにＷｅｂページ上で見いだされるＲＴＳＰＵＲＬを用いる。これは、モバイルテレビ受信機２４、２５のスイッチを入れることに相当する。

デフォルトでは、サーバが、上述したＳＤＰ中で提供されたチャネル束記述文字列の中の最初の登録事項に対応するチャネルを配送し始めることが提案される。あるいは、サーバは、最後のセッションの間に最後のものとして提供されたチャネルをユーザに提供し始める。

ユーザが新しいチャネルへの切り替えを始動させるならば、モバイルテレビアプリケーションは、図３のステップ２６によって、チャネル切り替え制御部２ＯＣに対して、新しいチャネルを送信する。

チャネル切り替え要求２６が、「帯域内（ｉｎ−ｂａｎｄ）」でＲＴＳＰストリーミングセッション制御プロトコルを介して、または「帯域外（ｏｕｔ−ｂａｎｄ）」で、たとえばＨＴＴＰプロトコルを用いて、直接ストリーミングサーバに送信されることが提案される。後者の場合に、切り替え要求には、モバイルテレビアプリケーションで利用可能なチャネルアドレスだけでなく、影響されるストリーミングセッションの固有の識別子も含まねばならず、それによってストリーミングサーバは、どのセッションについてチャネル切り替えが実行されるか知ることができる。

好適な実施形態中で、以下の例において概説されるように、コネクション２６によって送られているＲＴＳＰＳＥＴ＿ＰＡＲＡＭＴＥＲメッセージは、帯域内送信方式のために使われる。
RTSP: SET_PARAMETER
rtsp://mobiletv.com/Bundle-1 RTSP/1.0
CSeq:10
コンテンツ長：14
コンテンツタイプ：テキスト/パラメータ
チャネル：2
この例において、クライアントは、メッセージ「チャネル：２」を含んでいるＲＴＳＰＳＥＴ＿ＰＡＲＡＭＥＴＥＲコマンド（チャネル「２」（我々の例では「ＣｈａｎｎｅｌＴｗｏ」）に切り換えるべきであると告げている。）をサーバに送る。チャネルを切り替えるユーザの要求２７は、ユーザ側のチャネル切り替え制御部２０Ｃから、ネットワーク側のチャネル切り替え制御部２０Ｄ、すなわちサーバへ転送される。

サーバのチャネル切り替え制御ユニットは切り替え要求を処理し、新しいチャネルに付属しているＲＴＰパケットが、クライアントに転送されるはずの時点を決定する。ひとつのチャネルから別のチャネルに切り換えることは或る同期点でのみ可能なので、これがまた、チャネル切り替え制御ユニットを持つことの理由である。同期点は、データフロー中においてチャネルのデコーディングを開始できる位置２０Ｆを、たとえそのチャネルの他のデータをそれ以前に受信していないとしても、記録する。例えば、ビデオストリームのデコードは、以前に送られたどのような写真を参照することもなくエンコードされた、いわゆるイントラフレームで始めることだけができる。

もしすべてのフレームがイントラフレームとしてエンコードされるならば、ビデオストリームのデコードはどのフレームでも始めることができるので、最も小さい切り換え遅延が達成される。しかし、イントラフレームは、以前に送信されたフレームを参照してエンコードされるフレームより相当多くのビットを必要としている。従って、ビデオストリームはあまりにも多くのイントラフレームを含むべきでない。しかしながら、チャネル切り替えの間の大幅な遅延を避けるために、少なくとも１つのイントラフレームが２から５秒ごとにあるべきである。高頻度のイントラフレームを持つ別の利点は、送信エラーが受信したビデオにエラーをもたらすとしても、このエラーが次のイントラフレーム後には消滅するだろうということである。イントラフレームの間隔がライブエンコーダで設定されることができることには注意するべきである。

クライアントにとって、新しいチャネルからのコンテンツがどの時点でディスプレイ上にあるかを「推察する」ことは不可能である。クライアントにとって、チャネル間の切り換えはトランスペアレントである。従って、クライアントは、どの時点で新しいチャネルに属しているコンテンツが受信されるかを示す指示を全く持っていない。ひとつの解決策は、チャネル切り替え信号を送信して新しいチャネルのコンテンツがクライアントのビデオウィンドウの中に出現するまでの間の遅延の見積りを用いることであろう。しかし、この遅延が多くのファクタ、例えば送信自体の遅延やサーバにおける処理遅延、新しいチャネルに属するパケットがクライアントに転送される次の同期ポイントまでの時間や、古いチャネルに属するクライアントでバッファされたデータの量などに依存するので、これでは正確な結果は得られない。従って、予測することは難しい。

ＲＴＰフロー（ＲＴＰフロー＃１…ＲＴＰフロー＃ｎ）を、それらの切り替えポイント２０Ｆでバッファするために、サーバはバッファを持っている。そのＲＴＰフローはまた、チャネル切り替え制御ユニット２ＯＤから要求を受け取るチャネル選択ユニット２０Ｅに提供される。チャネル選択ユニットの仕事は、考えられる切り換えポイントに切り替えコマンドの実行を同期させることである。従って、切り替え要求を受け取る際に、考えられる最も早い切り換え時間を識別するために、チャネル選択ユニットは、新しいチャネルに対応するフローについて最初にＲＴＰパケットの待ち行列を検査する。今回は、チャネル切り替えの実行を始動させたＲＴＳＰＳＥＴ＿ＰＡＲＡＭＥＴＲ要求への応答として、クライアントに応答２９，３０が送信される。そしてクライアントは、どの時点で、新しいチャネルのコンテンツがスクリーン上で表示されるか、そしてそれに応じてタイトル・バーを変更することができるかを知る。

好適な実装中で、時間は一般的にＲＴＳＰにおいて使われるＮＰＴ（正常な再生時間）フォーマットで送信される。

前のサブセクションにおいて示された切り替え要求への応答の例は以下の通りであり、それは通信３０経由で送信される。
Ｓ−＞Ｃ：ＲＴＳＰ／１．０２００ＯＫ
ＣＳｅｑ：１０
コンテンツ長：２０
コンテンツ形式：テキスト／パラメータ
チャネル：２
切り替えポイント：ｎｐｔ＝３２−
このメッセージによって、サーバは、チャネル２の切り替え要求を受け取ったこと、及び、チャネル２の表示がセッションの開始の後に３２秒後に始まることを確認する。

その後、識別された切り換えポイントに再生時間が達するまで、チャネル選択ユニットは、現在のチャネルに属しているパケットを転送し続ける。そのポイント以降、新しいチャネルに属しているＲＴＰパケットが転送される。

スイッチ制御装置２０Ｄはまた、出て行くＲＴＰパケット２０ＧのＲＴＰヘッダを書き直すようにする。異なるライブエンコーダによって生成されたＲＴＰパケットのヘッダ情報は同期しないので、これが必要である。異なるＲＴＰフローのＲＴＰヘッダは異なるＳＳＲＣ、異なる連続番号および異なるＲＴＰ再生時間を運ぶ。ひとつの単一のＲＴＰフローをエミュレートするために、サーバのスイッチ制御ユニットは、共通のタイムラインおよび連続番号空間に、異なるライブエンコーダのＲＴＰフローを同期させる。これは、ＲＴＰ中の関連したフィールドを書き直すことによって達成される。

これは以下の例において説明される。ライブエンコーダ１（ＬＥ１）が以下のヘッダを持つＲＴＰパケットをサーバに配送するとしよう。
1）＜SN=1001 TS=9000 SSRC=12345678＞＜ペイロード1.1＞
2）＜SN=1002 TS=18000 SSRC=12345678＞＜ペイロード1.2＞
3）＜SN=1003 TS=27000 SSRC=12345678＞＜ペイロード1.3＞
4）＜SN=1004 TS=36000 SSRC=12345678＞＜ペイロード1.4＞
5）＜SN=1005 TS=45000 SSRC=12345678＞＜ペイロード1.5＞
ここで、ライン
1）＜SN=1001 TS=9000 SSRC=12345678＞＜ペイロード1.1＞
は、パケット１が、そのＲＴＰヘッダ内で、連続番号ＳＮ＝１００１、タイムスタンプＴＳ＝９０００、および同期ソース識別子ＳＳＲＣ＝１２３４５６７８を運び、それがストリーム１の最初のパケットのメディアペイロードを参照するメディアペイロード１．１を配送することを意味している。

また、ライブエンコーダ２（ＬＥ２）が以下のＲＴＰパケットを配送するとしよう。
1）＜SN=2011 TS=15000 SSRC=87654321＞＜ペイロード2.1＞
2）＜SN=2012 TS=24000 SSRC=87654321＞＜ペイロード2.2＞
3）＜SN=2013 TS=33000 SSRC=87654321＞＜ペイロード2.3＞
4）＜SN=2014 TS=42000 SSRC=87654321＞＜ペイロード2.4＞
5）＜SN=2015 TS=51000 SSRC=87654321＞＜ペイロード2.5＞
さらに、クライアントがストリーム１からストリーム２への切り替えを要求し、ストリーム２への切り替えはパケット３において実行されることが決定されたものとする。サーバからクライアントに配送されたＲＴＰパケットのフローの例は以下の列である。
1）＜SN=10000 TS=90000 SSRC=7236237＜ペイロード1.1＞
2）＜SN=10001 TS=99000 SSRC=7236237＞＜ペイロード1.2＞
3）＜SN=10002 TS=108000 SSRC=7236237＞＜ペイロード2.3＞
4）＜SN=10003 TS=117000 SSRC=7236237＞＜ペイロード2.4＞
5）＜SN=10004 TS=126000 SSRC=7236237＞＜ペイロード2.5＞
結果として生じているＲＴＰストリームが、連続番号ＳＮにおいても、タイム・スタンプＴＳにおいても、いかなる「飛躍」も含んでいないように、オリジナルのＲＴＰパケットのＲＴＰヘッダ情報が書き直されたことを見て取れる。また、ＳＳＲＣ識別子もそれに応じて変更された。しかし、ペイロードは、最初の２つのパケットについてはストリーム１からコピーされ、それに続くすべてのパケットについては、パケット３より始めて、ストリーム２からコピーされる。

クライアントのチャネル切り替え制御ユニット２０Ｃは、現在表示されたフレームの再生時間３１をストリーミング再生機から受信するように構成されている。その時間は、サーバからの応答で送信されたチャネル切り替え時間と比較される。再生時間がチャネル切り替え時間より大きいならば、チャネル切り替え制御ユニットは、モバイルテレビアプリケーション３２のためにトリガを発生させ、そして、モバイルテレビアプリケーションはビデオウィンドウのタイトル・バーの中でチャネル識別子を変更する。

セッション解消（たとえばモバイルテレビ受信機のスイッチオフ）は、標準のＲＴＳＰストリーミングにおいてと同様に処理されるので、それについてこれ以上説明しない。

本発明は主として方法のステップについて説明されているが、本発明は方法の形態のみならず、データユニット転送ネットワークのノード上で実行するとその方法を遂行するよう構成されたコンピュータプログラムを含むコンピュータプログラム製品という形態でも具現化することができる。コンピュータプログラム製品は、例えば、コンピュータプログラム自身またはコンピュータプログラムを担持するコンピュータプログラム担体であってもよい。

さらに、本発明はまた図１中で言及されたサーバ及びユーザノードなどの適切なノードという形で具現化することができる。

図４は、コネクション４１４から４１７経由でユーザノードと通信するサーバ機器を表しているノード４０の概略図を示す。ノード４０は、チャネル４１１、４１２、４１３の束を集めるように構成された収集部４０１を備え、チャネル束の各チャネルはユニークなチャネル識別子によって記述される。収集部は、接続４１４経由でユーザノードに提供される単一のチャネル束セッション記述４０２を生成するよう配置される。さらに、サーバ４０は、ユーザノードとサーバの間でストリーミングセッション４１５を提供するように構成されたセッション設立制御ユニット４０３を有する。セッションの設立およびストリーミングセッションの供給はチャネル束セッション記述４０２によってされる。ユーザノードが、第１のチャネルからチャネル束セッション記述４０２の一部である第２のチャネルに切り換えると決定する場合に、対応するチャネル切り替え要求メッセージ４１６はユーザノードで生成されてサーバ４０に提供される。チャネル切り替え制御ユニット４０４は、ユーザノードからチャネル切り替え要求メッセージ４１６を受け取るように構成されている。さらに、チャネル切り替え制御ユニット４０４は、第１のチャネルから第２のチャネルへのチャネル切り替えを制御するように構成されている。チャネル切り替えの実行は、第１と第２のチャネルの間で切り替えを行うように構成されたチャネル選択ユニット４０５によって補助され、そのチャネル選択ユニットは、切り替えを実行するために適切な切り替えポイントを決定することと、また、決定された切り替えポイントに達するとユーザノードに第２のチャネル４１７のコンテンツを提供するように構成されている。

さらに、チャネル選択ユニット４０５に転送する前のコネクション４１１から４１３上の受信データユニットのキューイングのために、サーバ４０はできればまた、キューバッファ（図４０中で明示的に示されない）を備えている。

図５はユーザノードを表しているノード５０の略図であり、それはコネクション４１４から４１７経由でサーバ４０と通信する。ノード５０は、サーバからのコネクション４１４経由で単一のチャネル束セッション記述を受け取るように構成されたストリーミングアプリケーションユニット５０１を備えている。単一のチャネル束セッション記述はチャネルの記述を含み、それは単一のオンデマンドストリーミングセッションによってユーザノードに提供できる。ユーザノードは、チャネル束の間で選択をするように構成されている。チャネル束の各チャネルはユーザノード５０に提供されているユニークなチャネル識別子によって記述される。さらに、ユーザノード５０は、ユーザノードからサーバにひとつのストリーミングセッション４１５を設立するように構成されるセッション設立制御ユニット５０２をまた備えている。セッションの設立はチャネル束セッション記述によって実行される。ユーザが、第１のチャネルから第２のチャネルに切り換えると決定する場合、対応するメッセージが生成されて、チャネル切り替え制御ユニット５０３は、チャネル切り替え要求メッセージ４１６を、第１のチャネルから第２のチャネルにチャネル切り替えを実行するために配置されたサーバ４０に送信するように構成される。さらに、第２のチャネル４１７のコンテンツを受け取り、コンテンツをユーザインターフェイス５１８に提供するために、ユーザノード５０はコンテンツ供給ユニット５０４を備えている。

前述したノード４０および５０は、ハードウェアとソフトウェアのどのような適当な組み合わせによってでも提供できる。図６中で描かれているように、それらはまたシステム６０の一部である。図６は、チャネル４１１、４１２、４１３を受け取っているサーバ４０を持つシステムを示す。図１について上述したように、前記チャネルはノード４０中で準備される。図１で説明するように、ノード４０は方法のステップを実行する。図５について説明したように、図２に従って方法のステップを実行しているノード５０もある。ノード４０と５０は、図４と図５についてのメッセージ４１４から４１７の交換のための概略表現である通信リンク６０１経由で互いと通信するように構成されている。メッセージ交換は図１、図２、および図３までの説明においてまた明らかにされる。

本出願は、無線パケット交換通信ネットワーク中のテレビなどのサービスのために適用可能である。それにもかかわらず、同じ原理は、エンドユーザが選ぶことができる多数のコンテンツチャネルを提供するどのような種類のサービスにでも適用可能である。モバイルテレビサービスは別として、これは例えば、異なるライブカメラ信号の間で選ぶことによるケースである。

本発明の実施形態において、サーバ側の進行中のオンデマンドストリーミングセッションの間にチャネル切り替えを実行するためのフローチャートを示す。本発明の実施形態において、ユーザノード側の進行中のオンデマンドストリーミングセッションの間にチャネル切り替えを実行するためのフローチャートを示す。本発明の実施形態によるノードとインタフェースを持つシステムの概略図を示す。接続４１４から４１７経由でユーザノードと通信するサーバ機器を表しているノード４０の概略図を示す。ユーザノードを表しているノード５０の略図である。チャネル４１１、４１２、４１３を受け取っているサーバ４０を持つシステムを示す。

Claims

オンデマンドマルチチャネルストリーミングセッション、特にテレビのセッションをパケット交換通信ネットワークのユーザノードに提供する方法であって、前記オンデマンドマルチチャネルストリーミングセッションは、サーバにより提供されるとともに、コンテンツを提供し前記ユーザノードからアクセス可能な複数のチャネルから成り、前記方法は、前記サーバにより実行される、
チャネル束の各チャネルが固有のチャネル識別子により記述されたチャネル束の記述を含むユーザノードに、集められたチャネル束セッション記述を提供する工程（２ＯＡ、２０Ａ’、２２、２２’）と、
前記集められたチャネル束セッション記述を用いてユーザノードとサーバとの間の一つのストリーミングセッションを設立する工程（２０Ｉ、２５）と、
前記ユーザノードからチャネル切り替え要求メッセージを受け取り、前記固有のチャネル識別子により識別される第１のチャネルから第２のチャネルにチャネル切り替えを実行する工程（２０Ｄ，２０Ｆ）と、
切り替えを実行するために、適切な切り替えポイントの決定を含む、前記第１のチャネルと第２のチャネルとの間で切り替えを行うチャネル切り替え手続きを実行する工程（２０Ｈ、２０Ｆ、２０Ｄ、２０Ｅ、２０Ｇ、２８、２９）と、
前記決定された切り替えポイントにおいて開始される前記第２のチャネルのコンテンツの提供を行う工程（３３）と
を含むことを特徴とする方法。
前記決定された切り替えポイントもまた、前記チャネルのコンテンツとともにクライアントアプリケーションの中で表示されているチャネル識別子を同期させるために、ユーザに提供されることを特徴とする請求項１に記載の方法。
前記単一のチャネル束セッション記述は、前記ユーザノードで実行されるソフトウェアによって解釈可能な文字列を含むことを特徴とする請求項１に記載の方法。
前記集められたチャネル束セッション記述の提供は、前記チャネル束のチャネルが、同じビットレートで同じコーデックを用いてエンコードされたかどうかを確認することを含むことを特徴とする請求項１または３に記載の方法。
前記チャネル切り替え要求は、ストリーミング制御プロトコルを用いて「帯域内」で送信されるか、またはアプリケーションプロトコルを用いて「帯域外」で送信されることを特徴とする請求項１に記載の方法。
コンテンツのデータフロー中において、チャネルのデコードをいかなる品質の劣化もなしに開始できる同期ポイントマーク位置でチャネル切り替えが実行されることを特徴とする請求項１、２、または５に記載の方法。
前記同期ポイント間の距離は、チャネル切り替え遅延と圧縮効率との間のトレードオフが最適化されるように選択されることを特徴とする請求項６に記載の方法。
チャネル切り替え手続きにおいて、さらに、共通の再生と連続番号空間を提供する方法で、送出されるデータパケットのヘッダを修正することによって、ユーザノードに提供されているチャネルのデータパケットは、前記データパケットを同期させるためにサーバにおいて修正されることを特徴とする請求項１に記載の方法。
オンデマンドマルチチャネルストリーミングセッション、特にテレビのセッションをパケット交換通信ネットワークのユーザノードに提供する方法であって、前記オンデマンドマルチチャネルストリーミングセッションは、サーバにより提供されるとともに、コンテンツを提供し前記ユーザノードからアクセス可能な複数のチャネルから成り、前記方法は、前記ユーザノードにより実行される、
チャネル束の各チャネルが固有のチャネル識別子で記述された前記チャネル束の記述を含むサーバから、単一のチャネル束セッション記述を受信する工程（２０Ａ’、２２、２２Ｂ）と、
前記チャネル束セッション記述を用いて前記ユーザノードから前記サーバに対する一つのストリーミングセッションを設立する工程（２４、２０Ｊ、２５）と、
切り替えのための適当な切り替えポイントの決定を含む、固有のチャネル識別子で識別される第１と第２のチャネル間で切り替えを行うチャネル切り替え手続きを実行するために、チャネル切り替え要求メッセージを前記サーバに送信する工程（２６、２０Ｃ、２７）と、
決定された切り替えポイントに達すると前記第２のチャネルのコンテンツを受信し、前記コンテンツをユーザインターフェイスに提供する工程（３３、２０Ｋ、２０Ｌ、２０Ｍ、３４、２０Ｎ）と
を含むことを特徴とする方法。
単一のチャネル束セッション記述は、ユーザノード上で実行されるストリーミングアプリケーションによって解釈可能な文字列を含み、利用可能なチャネルのリストが生成されて、ユーザに示されることを特徴とする請求項９に記載の方法。
利用可能なチャネルのリストがチャネル選択メニューの中のユーザ要求の上で表示されて、さらに、チャネル識別子がビデオウィンドウの上または下のタイトル・バーの中で表示されることを特徴とする請求項９または１０に記載の方法。
前記リストは、携帯電話のキーボードを遠隔制御のように使うために、前記電話の特定のキーに対応づけられることを特徴とする請求項９、１０または１１に記載の方法。
チャネルコンテンツとともにクライアントアプリケーション中で表示されているチャネル識別子を同期させるために、前記決定された切り替えポイントもまたユーザに提供されることを特徴とする請求項９に記載の方法。
前記ユーザノードは、現在表示されたフレームと受信した切り替えポイントとを比較し、その結果に従って、ビデオウィンドウのタイトル・バーの中のチャネル識別子を変更するために、ストリーミングアプリケーションにトリガーが送られることを特徴とする請求項９または１３に記載の方法。
パケット交換無線通信ネットワークのユーザノードにオンデマンドマルチチャネルストリーミングセッション、特にテレビのセッションを提供するサーバ（４０）であって、前記オンデマンドストリーミングセッションは、前記サーバにより提供されるとともに、コンテンツを提供し前記ユーザノードからアクセス可能な複数のチャネルから成り、前記サーバは、
チャネル束の個々のチャネルが固有のチャネル識別子で記述されたチャネル（４１１、４１２、４１３）の束を単一のチャネル束セッション記述（４０２）に集め、前記単一のチャネル束セッション記述をユーザノード（４１４）に提供する収集部（４０１）と、
前記ユーザノードと前記サーバとの間で、チャネル束セッション記述により識別されているストリーミングセッション（４１５）を提供するセッション設立制御ユニット（４０３）と、
前記ユーザノードからチャネル切り替え要求メッセージ（４１６）を受信し、第１のチャネルから第２のチャネルへチャネル切り替えを実行するチャネル切り替え制御ユニット（４０４）と、
切り替えのための適当な切り替えポイントを決定し、前記決定された切り替えポイントに達すると、前記第２のチャネル（４１７）のコンテンツを前記ユーザノードへ提供する、前記第１のチャネルと第２のチャネルとの間で切り替えを行うチャネル選択ユニット（４０５）と
を備えることを特徴とするサーバ。
オンデマンドマルチチャネルストリーミングセッションを受信するパケット交換無線通信ネットワークのユーザノードであって、前記オンデマンドマルチチャネルストリーミングセッションはサーバにより提供されるとともに、コンテンツを提供し前記ユーザノードからアクセス可能な複数のチャネルから成り、前記ユーザノードは、
チャネル束の各チャネルが固有のチャネル識別子で記述された前記チャネル束の記述を含むサーバから、単一のチャネル束セッション記述（４１４）を受信するストリーミングアプリケーション（５０１）と、
前記チャネル束セッション記述を用いて前記ユーザノードから前記サーバに対する一つのストリーミングセッション（４１５）を設立するセッション設立制御ユニット（５０２）と、
固有のチャネル識別子で識別される第１と第２のチャネル間で切り替えを行うチャネル切り替え手続きを実行するために、チャネル切り替え要求メッセージ（４１６）を前記ユーザノードから前記サーバに送信するチャネル切り替え制御ユニット（５０３）と、
前記第２のチャネル（４１７）のコンテンツを受信し、該コンテンツをユーザインターフェイス（５１８）に提供するコンテンツ提供ユニット（５０４）と
を備えることを特徴とするユーザノード。
オンデマンドマルチチャネルストリーミングセッション、特にテレビのセッションをパケット交換通信ネットワークのユーザノードに提供するシステム（６０）であって、前記オンデマンドストリーミングセッションは、サーバにより提供されるとともに、コンテンツを提供し前記ユーザからアクセス可能な複数のチャネルから成り、
前記システムは、請求項１に記載された方法を実行する、請求項１５に記載されたサーバ（４０）と、
請求項９に記載された方法を実行する、請求項１６に記載されたユーザノード（５０）とを有し、
前記ユーザノード及びサーバは、互いに通信すること（６０）を特徴とするシステム。