JP2011526098A - 帯域幅を予約するための方法及びユーザ機器 - Google Patents

Abstract

ユーザ機器において、条件付き帯域幅再ネゴシエーションの方法が、ユーザ機器（３００）がＩＰＴＶネットワーク（１０２）から提供されるＩＰＴＶセッションに関与していて、かつチャネル切替が要求されている場合の帯域幅再ネゴシエーションを管理する方法が提供される。リクエストされるチャネル切替が現在選択されているチャネルよりも狭い帯域幅を要求すると判定される場合、条件付き帯域幅再ネゴシエーション処理が開始される。リクエストされたチャネルへ切り替えられると、タイマーが開始される。継続中のタイマーのタイムアウトが、別のチャネル切替のリクエストの前に認識される場合、帯域幅再ネゴシエーション手順が開始される。一方、継続中のタイマーのタイムアウトの前に別のチャネル切替のリクエストが認識される場合、帯域幅再ネゴシエーションは実行されない。
【選択図】 なし

Description

本発明は、一般的には、ＩＰＴＶセッションに関与するユーザ機器に対するチャネル切替に関連する帯域幅予約のための方法、かつその方法を実行するユーザ機器に関するものである。

テレビ（ＴＶ）が、一方向の配信サービスから、エンドユーザとの双方向インタラクティブサービスを提供することに移行し、かつ、固定された位置だけに配信されるという制限から、事実上は任意の位置に配信可能で、かつ様々な形式で、かつ様々な画面のサイズで視聴することができるサービスへと移行するにつれて、我々は、ＴＶ番組製作、広告活動、インタラクティブゲーム、及び様々なタイプのインタラクティブサービスに対して、完全に新規の大衆市場の誕生を経験しようとしている。

インターネットプロトコルテレビ（ＩＰＴＶ）は、音声トラフィックの収益の減少の埋め合わせのために、それぞれのネットワークに新規の顧客を引き付けるようにする際に、通信サービスプロバイダに対して新たな収益の機会を提案する。ＩＰＴＶの取り組みは、いくつかの異なるコンテキストで進行中であり、これには、例えば、ＩＰＴＶフォーラムによって現在進行中の整備が含まれている。このＩＰＴＶフォーラムでは、インターネットを介して、ＩＰＴＶを実現可能なユーザ機器（ＵＥ）群で提供されるエンドユーザに、マルチメディア及びＩＰＴＶサービスを供給するためばかりでなく、かつサービス品質（ＱｏＳ）パフォーマンスを制御しているネットワークを管理するための、エンドツーエンドプラットホームを規定している。機能上のＩＰＴＶアーキテクチャのバージョン１．１の仕様は、ｗｗｗ．ｏｐｅｎｉｐｔｖｆｏｒｕｍ．ｏｒｇで利用可能であり、ここで、上述のアーキテクチャは、第３世代パートナーシッププロジェクト（３ＧＰＰ）によって特定されるＩＰマルチメディアサブシステム（ＩＭＳ）に基づいている。ＵＥは、多くの様々な方法によってＩＭＳを通して提供されるサービスへアクセスすることができる。この方法には、有線アクセス、無線アクセス、あるいはその両方、あるいはＩＥＥＥ８０２．１１あるいはＩＥＥＥ８０２．１６規格を使用するものがある。有線アクセスには、例えば、イーサネット、ケーブルモデムあるいはデジタル加入者線がある。無線アクセスには、例えば、３ＧＰＰで規定されるセルラー無線がある。

ＩＭＳは、３ＧＰＰ技術仕様書（ＴＳ）２３．２２８ Ｖ８．４．０、ＩＰマルチメディアサブシステム（ＩＭＳ）ステージ２（リリース８）と、２００８年３月、前バージョンのＴＳ２３．２２８で規定されている。また、ＩＭＳベースのＩＰＴＶへの様々なアプローチが、エム．セデルバル等による、「オープンＩＰＴＶフォーラム−オープンＩＰＴＶ標準へ向かう」と、エリクソンレビュー、Ｎｏ．３、ページ７４−７８（２００７）と、及びティー．ケイジェニス等による、「ＴＶ体験の進化：いつでもどこでもどの装置でも」、エリクソンレビュー、Ｎｏ．３、ページ１０７−１１１（２００６）で記載されている。

ＵＥについて、ＵＥは、サービス呼セッション制御機能（Ｓ−ＣＳＣＦ）に登録する。ここで、ＵＥは、セットトップボックス（ＳＴＢ）あるいは統合ＳＴＢ機能を有するエンティティであり得る。これには、例えば、コンピュータ、ＴＶ、ＰＤＡ、移動電話、あるいは移動デバイスにＩＭＳを介してＩＰＴＶサービス群にアクセスすることができる、任意の他のＩＰＴＶ機能付き移動デバイスがある。また、サービス呼セッション制御機能は、ＩＭＳコアノードであり、本質的には、ＳＩＰサーバとして動作する。典型的なＩＭＳは、いくつかの更なるノードを含んでいて、これには、プロキシＣＳＣＦ（Ｐ−ＣＳＣＦ）、メディアゲートウェイ制御機能（ＭＧＣＦ）、及び１つ以上の境界ゲートウェイ（ＢＧ）群が含まれる。この境界ゲートウェイは、コアノード群へのＵＥ群のアクセスを仲介し、また、コアノード群を介して、１つ以上のメディアサーバに常駐するメディアコンテンツへアクセスする。

従来のＩＭＳベースのＩＰＴＶネットワークにおいては、セッションの変更を実行することが可能である。これには、要求されるサービス群がエンドユーザ群に提供されることを保証するために、ユーザ機器からセットアップされているセッション群に対する帯域幅予約が含まれる。この状況では、セッションは、ユニキャストセッション、あるいはブロードキャストセッションであり得る。ユニキャストセッションには、例えば、ユニキャストストリームを介して配信されるビデオオンデマンドセッションがある。また、マルチキャストセッションは、マルチキャストストリームを介して、エンドユーザ群に合わせて配信されるものである。

帯域幅予約手順は、選択されたサービスの切断のリスクを最小限にしながら、適切なユーザ体験を保証することを可能にするために、ＩＰＴＶオペレータに対し、ネットワーク基盤のラストマイル（last mile）あるいは集約ネットワークにおいて、ネットワークリソースが十分に存在することを保証する。

例えば、２つのセッションが共に、ラストマイルを介してＩＰオペレータに利用可能な帯域幅量を越える場合、これらの２つのセッションに関連付けられているパケット群は、利用可能なネットワークリソース群に対して競合することになる。つまり、両方のストリームに対するパケット群の多くが破棄される可能性があり、これによって、２つのセッションの少なくとも１つに対する品質が低下することになる。帯域幅が１つ以上のセッションに対して一旦予約されると、既存のセッションに悪影響を与え得る新規なセッションが許容されないことは重要なことである。

図１は、従来技術に従うシグナリングスキームであり、ここでは、典型的なＩＰＴＶサービスセットアップがＵＥ１００とＩＰＴＶネットワーク１０２との間でどのようにして実行されているかを示している。この手順により、図中、コアネットワーク１０１によって表されるＩＭＳネットワークを介して、１つ以上のＩＰＴＶサービスをＵＥ１００へ提供する。

ＩＰＴＶネットワーク１０２と、ＩＭＳコアネットワーク１０１によって表されるＩＭＳネットワークの両方は、典型的には、複数のネットワークノードを備えているが、図１では、これらのネットワークのそれぞれが図１に示されるそれぞれのノードによって表されていることが理解されるべきである。

２つの開始ステップ１：１と１：２において、ＵＥ１００は、ＩＭＳコアネットワーク１０１に登録し、ＩＭＳコアネットワーク１０１は、通常は、２００ＯＫメッセージで応答する。続くステップ１：３−１：６で、ＵＥ１００は、ＳＩＰ加入を介して、ＩＰＴＶネットワーク１０２から提供されるＩＰＴＶサービスをリクエストする。ステップ１：６で示されるように、ＵＥ１００がＩＭＳコアネットワーク１０１から２００ＯＫメッセージを受信して、この手順が一旦完了すると、ＵＥ１００には、通常、ＩＰＴＶサービスディスカバリデータと呼ばれるＩＰＴＶサービスデータが提供される。このデータには、ＩＰＴＶネットワーク１０２の各ＩＰＴＶサービスプロバイダから提供されるチャネル群のすべてを示すチャネルリストが含まれている。典型的なＩＰＴＶサービスディスカバリシグナリング手順は、図１のステップ１：７−１：１０で示される。利用可能なチャネルについての情報が一旦提供されると、ＵＥ１００は、要求されるサービスを選択することを選ぶことができる。本例では、これは、ステップ１：１１において、ＨＴＴＰ ＧＥＴメッセージが、ＩＭＳコアネットワーク１０１を介して、ＵＥ１００からＩＰＴＶネットワーク１０２へ送信されることが示されている。

次のステップ１：１２において、ＩＰＴＶネットワーク１０２は、ＵＥ１００に、通常、リニアＴＶチャネルリストと呼ばれるリストを提供することによって応答する。このリストで、特に、他のＩＰＴＶチャネル関連情報は、ＩＰＴＶネットワーク１０２から利用可能なＩＰＴＶチャネルに関連付けられている帯域幅要件情報を含んでいる。この情報は、通常、ブロードキャストディスカバリレコードのブロードキャスト提供（broadcast offering）と呼ばれるＴＩＳＰＡＮサービスパケットとしてＵＥ１００へ提供される。

ブロードキャスト提供は、通常は、いくつかの要素あるいは属性を備え、それぞれが、利用可能なＩＰＴＶチャネルについての様々な種類の情報を搬送する。各チャネルに対して、ブロードキャスト提供は、様々な情報を含み得る。これには、例えば、ＵＥにおいてＩＰＴＶチャネル識別を可能にするＤＶＢトリプレット、各ＩＰＴＶチャネル名を表すテキストのアイデンティティ、各チャネルを検出することについての命令であるサービスロケーション、各サービスについて要求される最大ビットレートの表示である最大ビットレートがある。

次のステップ１：１３において、ブロードキャスト提供から提供される情報が、ＵＥ１００のメモリに記憶される。この段階で、ＵＥ１００のエンドユーザは、通常は、リモード制御を起動（アクティベート）することによって、あるいはＵＥに関連付けられている別のユーザインタフェースを介して、ブロードキャスト提供で利用可能なチャネルから好みのＩＰＴＶチャネルを選択することを選ぶことができる。ステップ１：１４において、エンドユーザは、そのような選択を行い、チャネル選択に応じて、ＵＥ１００は、選択したチャネルに対して適切な帯域幅を予約するための帯域幅予約手順を開始する。図では、これは、通常、ＳＩＰ招待と呼ばれる招待で示され、この招待は、ステップ１：１５で示されるように、ＩＭＳコアネットワーック１０１へ転送される。

要求される帯域幅が利用可能でない場合、あるいは何らかの理由で要求される帯域幅がＵＥ１００へ割り当てることができない場合、ステップ１：１６ａで示されるように、このことがＵＥ１００へ通知される。このような状況では、エンドユーザは、同一のチャネルに対して再試行を行うことを選択し、あるいは別のチャネルを選択することを試行することができる。

一方、帯域幅リクエストがＩＭＳネットワークによって承認される場合、ステップ１：１６ｂで示されるように、帯域幅がＵＥ１００に対して予約される。次に、帯域幅予約手順は、ステップ１：１７及び続くステップ１：１８で示されるように、ＩＰＴＶネットワーク１０２に割り当てられた帯域幅を通知し、ＩＰＴＶネットワーク１０２がそのことを確認することによって完了し、そして、ステップ１：１９及びステップ１：２０で示されるように、ＵＥ１００に向けての確認も実行される。

要求される帯域幅がＵＥ１００について予約されると、要求されたＩＰＴＶサービスを開始することができる。本例では、ステップ１：２１で示されるように、本手順は、ＵＥ１００が、ＩＧＭＰ参加をＩＰＴＶネットワーク１０２に送信することによって実行される。図で示されるように、ＩＰＴＶネットワーク１０２は、最後のステップ１：２２で示されるように、マルチキャストストリームを介して、選択されたＩＰＴＶチャネルをＵＥ１００へ配信することによって、そのようなサービスリクエストに応答する。

帯域幅予約に関する一般的な問題は、選択されたブロードキャストセッションをネゴシエートするために実際にどの程度の帯域幅が必要となるかについての情報をどのようにして適切に取得するかである。上述のように、通常は、ブロードキャスト提供によって配信される、ＩＰＴＶオペレータから利用可能なＩＰＴＶセッションをセットアップするために必要なブロードキャストチャネル情報は、各ＩＰＴＶチャネルに対する最大ビットレートの表示を含んでいる場合がある。このような情報は、一旦リソースが割り当てられ、かつＩＰＴＶチャネルが選択されると、適切な帯域幅がＩＭＳコアネットワーク１０１から利用可能であることを保証するための目的を持っている。

しかしながら、上述の手順に従う、最大ビットレート属性に基づく帯域幅再ネゴシエーション手順に伴う問題は、要求されるシグナリングが、様々なチャネルに切り換えるユーザに対するユーザ経験を減らしてしまう可能性がある処理遅延を生じさせることになる。エンドユーザが選択したチャネルを見ることができる前に、帯域幅再ネゴシエーションを伴うセッション変更は行わなければならず、その結果、そのような帯域幅再ネゴシエーションからの結果として、エンドユーザは、チャネルを実際に見ることができる迄の遅延をユーザは経験することになる。

上述で扱う問題は、より不変な基準で利用可能なチャネルの１つを見ることを決定する前に、様々な最大ビットレートが指定されている様々なチャネルにエンドユーザが換える場合に、特に、わずらわしいものとなる。遅延が繰り返されると、エンドユーザをかなり悩ませることになると同時に、オペレータの観点からも、エンドユーザによって開始されるチャネルの切替に応じて、直ちに帯域幅再ネゴシエーションを開始することによる進めるべき処理もわずかしかない可能性がある。

加えて、帯域幅再ネゴシエーションを実行するための現在知られているソリューションも、利用可能な帯域幅の使用によるいかなる制御も、ＩＰＴＶオペレータに与えるものではない。

本発明の目的は、ＩＰＴＶセッションに関与しているユーザ機器に対する帯域幅再ネゴシエーションの数を削減するための方法を提供することである。より詳しくは、本明細書は、遅延させるべきＩＰＴＶセッションに関与しているユーザ機器に対するチャネル切替に関連している帯域幅予約を実行するか否かの決定をある環境下で可能にするメカニズムを言及している。より高い帯域幅要件を有するチャネルから切替が要求されているチャネルへのチャネル切替に対するこのような決定を遅延することは、ユーザ経験あるいはネットワークパフォーマンスに悪影響を与えることなく、実際に実行される帯域幅際ネゴシエーションの数を削減することができる。

第１の構成に従えば、ＩＰＴＶネットワークから提供されるＩＰＴＶセッションに関与するユーザ機器におけるチャネル切替に関連する帯域幅再ネゴシエーションを管理する方法が提供される。

リクエストされているチャネル切替に関連付けられている条件付き帯域幅再ネゴシエーション処理が、リクエストされたチャネルが、現在選択されているチャネルよりも狭い帯域幅を要求すると判定される場合に適用されるものである。このような条件付き帯域幅再ネゴシエーション処理は、タイマーによって開始することに続いて、リクエストされたチャネルへの切替で開始するいくつかのステップの実行を含んでいる。このタイマーは、帯域幅再ネゴシエーションが実行されるべきかどうかの決定を遅延するためのものである。タイムアウトが認識される場合、典型的には従来の手続のステップ群に従って、帯域幅再ネゴシエーションが開始されて実行される。

タイマーのタイムアウトの前に、別のチャネル切替のリクエストが認識される場合、先のチャネル切替に対して帯域幅再ネゴシエーションは実行されず、そして、継続中のタイマーが終了すると、別の評価処理が、最新のチャネル切替のリクエストに応じて、条件付き帯域幅再ネゴシエーション処理が適用されるかを判定するために開始される。

提案される方法に従えば、条件付き帯域幅再ネゴシエーション手順に依存する帯域幅要件が、リクエストされたチャネルに対して要求されている帯域幅に対応し、かつそのリクエストされたチャネルに関連付けられているビットレート属性の値と、現在のチャネルに割り当てられている帯域幅に対応し、かつユーザ機器で現在利用可能な最大ビットレートを示す値と比較することによって評価される。

典型的な実施形態では、ビットレート属性は、チャネル切替の前に、ＩＰＴＶネットワークからユーザ機器へ提供されている。これは、ビットレート属性を、典型的には、他のビットレート属性とともに、ブロードキャスト提供で転送することによって達成されてもよい。ユーザ機器に提供されるビットレート属性は、チャネル単位で、あるいはチャネルのグループ単位で、予め定義されていても良い。チャネルのグループ単位で予め定義されている場合には、そのグルーピングは、１つ以上の異なる基準に基づいていても良い。

また、条件付き帯域幅再ネゴシエーション手順に対して使用されるタイマー値は、典型的には、ＩＰＴＶネットワークからユーザ機器へ提供されても良い。このようなタイマー値は、ＩＰＴＶネットワークから提供されるすべてのチャネルに対して有効となるように指定されている値であっても良いし、あるいは、特定のチャネルに対して予め定義されているチャネル専用のタイマー値であっても良い。また、タイマー値は、ブロードキャスト提供でユーザ機器に提供されても良い。

別の構成に従えば、請求項で定義される発明は、また、上述の方法を実行するように構成されているユーザ機器も言及している。

提案される方法は、ユーザ機器で実現することが容易である帯域幅再ネゴシエーションの数を制限するためのメカニズムを提供する。

提案される方法は、また、オペレータに、少なくとも制限された範囲で、次回の帯域幅再ネゴシエーション中に、どのようにして利用可能なリソースが割り当てられることになるかに関与することを可能にする。また、提案される方法とそれに関連するユーザ機器の詳細と特徴、及び効果は、詳細な説明で更に詳細に説明する。

従来技術に従うユーザ機器とＩＰＴＶネットワーク間で、どのようにしてＩＰＴＶセッションをセットアップすることができるかを示すシグナリング図である。 一実施形態に従って、帯域幅再ネゴシエーション手順が実行されるべきか否かについての決定を遅延する方法を示すフローチャートである。 一連の例示の状況に従って、図２を参照して説明される方法を、ユーザ機器がどのようにして適用するかを示すシグナリング図である。 一実施形態に従って、図２を参照して説明される方法を実行することができることに基づく情報を例示するテーブルである。 別の実施形態に従って、図２を参照して説明される方法を実行することができることに基づく情報を例示する別のテーブルである。 一実施形態に従って、図２を参照して説明される方法を実行することができるユーザ機器がどのようにして設定構成されるかを示すブロック図である。

上述のように、一定量の帯域幅の要件は、ＩＰＴＶネットワークでセットアップすべきＩＰＴＶセッションを要求するＵＥに対する帯域幅予約をＩＭＳコアネットワークに対して実行することを可能にするために、利用可能なＩＰＴＶチャネルに対して定義することを必要とする。

今日、この目的に対して利用可能な情報は、ブロードキャスト提供でＩＰＴＶネットワークからＵＥへ提供されているメタデータがあり、また、この情報は、各セッションに対して利用可能となるべきビットレート、即ち、各セッションをセットアップする前に、各ＩＰＴＶチャネルに対して保証されるべきビットレートが何であるかの表示を与えるものである。

上述のことからも明らかなことは、エンドユーザの観点からは、チャネル毎の帯域幅の再ネゴシエートすることは、最大範囲で避けるべきことである。これは、選択されたチャネルに対して要求される帯域幅が、各ＵＥに対して許可されている後になってのみチャネルを見ることができるからである。

それゆえ、必要とされることは、実行される再ネゴシエーションの数を制限する方法である。１つのアプローチは、実行対象の帯域幅再ネゴシエーションの内、不要なものとして見なせるものを取り除くことを試行することである。これによって、条件付きの再ネゴシエーションに適用し、かつ再ネゴシエーション手順の完了によって発生する遅延の数を減らす、帯域幅再ネゴシエーションの方法が提案される。

また、少なくともある程度の範囲で、ＩＰＴＶネットワークを介して、ＩＰＴＶチャネルの形式でＩＰＴＶサービスを提供しているＩＰＴＶオペレータが、利用可能なリソース、あるいはより具体的には、利用可能な帯域幅をどのようにして、ＩＰＴＶサービス配信に対して使用されるかについてより影響を与えることができるかが要求される。

提案される条件付きの帯域幅再ネゴシエーション方法に従えば、帯域幅は、１つのチャネルではなくチャネルのグループに対してネゴシエートされることで、エンドユーザが様々なＩＰＴＶチャネルでザッピング（zapping）する際に、帯域幅再ネゴシエーションが実際に実行することが必要であるかをどうかについての決定は、いくつかの場合には、後回しにすることができる。この決定を後回しすることによって、あるいくつかの場合での帯域幅再ネゴシエーションは必要でないことを判定することができることになる。つまり、実行される帯域幅再ネゴシエーション手順によって生じる遅延の量を削減することができる。

提案される方法に従う帯域幅再ネゴシエーションによってより良い制御を行うために、ＵＥ群にタイマーを導入する。このタイマー値は、ＩＰＴＶオペレータからＵＥへ提供されることが好ましい。そのため、以下では、例えば、再ネゴシエーション時間（TimeToRenegotiation（ＴＴＲ））と呼ばれる、１つ以上のタイマー値を表す新規の要素あるいは属性を導入する。

この状況では、ＴＴＲは、チャネル切替の前に、典型的には、ブロードキャスト提供を介して、ＵＥへ提供される属性である。エンドユーザのＵＥによって開始されるチャネル切替に応じて、帯域幅再ネゴシエーション手順を無条件で実行する代わりに、帯域幅再ネゴシエーション手順をＵＥで実行すべきであるかどうかについての決定を遅延させるために、このＴＴＲを使用することができる。

現在見ているチャネルよりも帯域幅がより少なくて済むチャネルへエンドユーザが切り替えているという事実によって必要とされる帯域幅再ネゴシエーション手順は、時間に厳しくない。これは、再ネゴシエーションを実行しなくても、ＵＥに対して既に予約されている帯域幅を使用することによって、要求されている新規のチャネルをエンドユーザに提供することができるからである。

このような状況では、帯域幅再ネゴシエーションの決定は、ユーザ経験を損なうことなく、例えば、ＴＴＲによって特定される、特定のタイマー値に基づいて遅延させることができ、これによって、タイマー値が満了する前に、後続の更なるチャネル切替が発生するかどうかに依存して、再ネゴシエーション手順が実際に必要とされるかについての再検討を後回しにすることを可能にする。

より詳しくは、提案される方法は、別のチャネルへの切替がタイマーのタイムアウト前に選択される場合には、タイマーがリセットされ、かつ直近の切替に対して再度タイマーが開始されるように構成される。これは、対応する状況が、最新のチャネル選択に対して現れる場合、即ち、最新の選択されたチャネルが、直近に選択されたチャネルよりも帯域幅が少なくとも済む場合である。

一方、最近選択されたチャネルから現在見ているチャネルによってより多くの帯域幅が要求される場合、従来からの帯域幅再ネゴシエーション手順が即座に開始され、かつ実行される。

その結果、このような従来のからの再ネゴシエーション手順を導入することによって、見ているチャネルに対するタイマーがタイムアウトする前に後続のチャネル切替が認識されない場合には、より狭い帯域幅を要求するチャネルへの切替に関与する再ネゴシエーション手順だけが実行されることになる。

上述のように、適用されるタイマー値は、ＩＰＴＶオペレータによって適切な値に選択され、かつ相対的に低い値で開始する範囲から、例えば、５秒までの値から、分の範囲の値まで、例えば、５分の継続時間を有するタイマー値の範囲で選択することができる。

どのようにタイマー値が選択されるかは、１つ以上の基準に依存させることができる。この基準とは、例えば、ユーザ行動、利用可能チャネル数、及び利用可能帯域幅の少なくとも１つである。

ＩＰＴＶオペレータによって提供されるすべてのチャネルに対して有効となる１つの値としてタイマー属性を定義する代替方法としては、タイマー値を、異なるチャネルに対してあるいはチャネルのグループに対して、異なるタイマー値が指定されているベクトルとして定義することができる。タイマー属性が異なるチャネルに対して異なる場合、それは、基準、例えば、各チャネルがどれくらい人気があるか、チャネルのタイプ、あるいは、各チャネルの予測されるユーザ行動に依存して選択することができる。

再ネゴシエーション処理をよりもっと最適化するために、タイマー値は、例えば、より人気のあるチャネルに対して特定される値にはより低くすることができ、より高いタイマー値には、あまり人気のないチャネルに対して選択される。

提案されるタイマーに基づく条件付きの帯域幅再ネゴシエーションメカニズムを導入することによって、帯域幅再ネゴシエーションの数を削減することができ、また、エンドユーザが、特定の時間の継続時間、即ち、関連するタイマー値の継続時間に対して合わせられている選択された各チャネルを維持していると判定される場合の時に限り、帯域幅再ネゴシエーションが実際に開始する。

一実施形態に従って、ＵＥにおいて、このようなメカニズムを実現する方法の一つを、図２のフローチャートを参照して詳細に説明する。

記載されるフローチャートは、仮にそうであるとしても、帯域幅再ネゴシエーション手順をいつ開始するかを判定することができる方法の１つを単に記載しているに過ぎず、また、上述の一般的な原理に基づくメカニズムが、他の代替の方法の実装によっても適用できることが理解されるべきである。

前提条件としては、エンドユーザが、ＩＰＴＶのチャネルに合わせていて、かつ条件付き帯域幅再ネゴシエーション機能をＵＥで開始していると想定する。ここで、ＵＥは、典型的には、例えば、任意のコンピュータ、ＰＤＡ、セットトップボックス、あるいはセットトップボックス機能を備えるＴＶ、あるいは移動電話、１つ以上のＩＰＴＶサービス／ＩＰＴＶチャネルをリクエストし、かつ表示するように構成されている任意の他のタイプの移動デバイスであり得る。このような条件付きの機能の開始は、まず、ステップ２００で示される。

次のステップ２０１において、チャネル切替がエンドユーザによってリクエストされているかが判定される。リクエストされたチャネル切替がＵＥによって一旦認識されると、選択されたチャネルに要求される帯域幅が現在見ているチャネルで要求される帯域幅、即ち、ＵＥに既に割り当てられている帯域幅と等しいかが判定される。つまり、新規のチャネルへの切替が任意の帯域幅再ネゴシエーションを要求することなく実行できるかが判定される。ステップ２０２において、この条件が評価され、要求される帯域幅が変更されないままであると検出される場合、次のステップ２０３で示されるように、チャネル切替が実行される。チャネル切替が実行された後、ステップ２０１で、待機している別のチャネル切替を開始する上述のループが繰り返される。

一方、帯域幅要件が異なるチャネルに対して異なる場合、ステップ２０４で示されるように、別の評価ステップを開始する。この第２の評価ステップでは、選択されたチャネルで要求される帯域幅が、現在のチャネルで要求される帯域幅よりも狭いかが判定される。そうでない場合、即ち、選択されたサービス／チャネルをエンドユーザへ提供できるようにするために更なる帯域幅が要求される場合、ステップ２０５で示されるように、典型的には従来の手順に従う無条件の再ネゴシエーション手順が実行され、その後、ステップＳ２０３で示されるように、リクエストされたチャネルの変更が実行され、更に、その後、ステップ２０１を開始するために、上述のループが再度開始される。

一方、選択されているチャネルで要求される帯域幅よりもより広い帯域幅が現在割り当てられていると判定される場合、ステップ２０６で示されるように、リクエストされているチャネル切替を実行することによって、提案される方法を継続し、そのチャネル切替に関連して、続くステップ２０７で示されるように、その選択されたチャネルに対して指定されているあるいは各チャネルに属するチャネルのグループに対して指定されている所定のタイマー値の継続時間をタイマーにセットする。

ステップ２０８のループで示されるように、エンドユーザによって新規のチャネル切替が開始されない限りタイマーが動作し、「ｎｏ」の分岐（２０８ｂ）となると、次のステップ２１０を継続する。上述のループで示されるように、タイマーがタイムアウトする前に新規のチャネル切替が発生する場合、即ち、ステップ２１０の「Ｙｅｓ」分岐（２１０ａ）に従う場合、従前のチャネル切替に対してはこれ以上帯域幅再ネゴシエーションが要求されないと見なすことによって、現在動作中のタイマーに依存する帯域幅再ネゴシエーションを遅延することの決定がなされ、ステップ２１１に示されるように、このような決定に続く次の動作として、従前のチャネル切替に関する係属中のタイマーがリセットされ、その後、最新のリクエストされたチャネル切替に対する状態を検証するために、ステップ２０２に戻る。

一方、ステップ２０８の「ｙｅｓ」分岐（２０８ａ）で示されるように、エンドユーザによって任意の新規のチャネル切替が起動される前にタイマーのタイムアウトが発生する場合、ステップ２０９で示されるように、典型的には、従来よりの帯域幅再ネゴシエーション手順に従って、最近リクエストされたチャネル切替を開始するために、帯域幅再ネゴシエーションが設定される。

一実施形態に従えば、ステップ２０２及び２０４で実行される帯域幅要件の評価手順は、選択されたチャネル及び現在のチャネルそれぞれに対して特定されていて、かつ、例えば、ブロードキャスト提供を介して、ＵＥに提供されている最大ビットレート属性の関連値を比較することによって実行することができる。

図２を参照して説明されるような、ＵＥがどのようにして条件付きの帯域幅再ネゴシエーション手順を実行することができるかを説明する例示の状況を、図３のシグナリング図を参照して説明する。

図３は、異なるチャネル切替の状況での違いに焦点を合わせている、簡略化された概要シグナリングスキームであり、このチャネル切替の状況では、上述の原理に従う条件付き帯域幅再ネゴシエーション手順が適用される。図では、提案される条件付き帯域幅再ネゴシエーション手順が起動される様々な状況が、符号「Ｓ」で示されている。

簡略化のために、条件付き再ネゴシエーション手順の開始の後には、様々な異なる状況に応じて実行される提案される条件付き帯域幅再ネゴシエーション手順に対しての基本原理を完全に理解するために重要なステップ群のみを図で示し、上述の状況のすべてに対して適用可能な完全な手順は図２のフローチャートとその説明によって特定することができる。

前提条件として、この図に対しても、条件付き帯域幅再ネゴシエーション手順を適用するように構成されているＵＥ３００は、ＩＭＳコアネットワーク１０１によって表されるＩＭＳネットワークを介してＩＰＴＶネットワーク１０１に接続され、かつＩＰＴＶセッションに関与していると想定する。即ち、ＩＰＴＶチャネルがＵＥ３００で現在提示されていると想定する。

最初のステップ３：１で、エンドユーザは、典型的には、従来の方法でリモート制御を起動することによってチャネルを切り替え、その結果、条件付き帯域幅再ネゴシエーション手順が開始される。この特定の場合では、リクエストされたチャネルは、現在選択されているチャネルに対して割り当てられている帯域幅よりも広い帯域幅を要求すると想定する。つまり、帯域幅再ネゴシエーションの決定を遅延する代わりに、典型的には、図１を参照して説明されるステップ１：１５−１：２０の実行を含む帯域幅再ネゴシエーションを開始する。図３では、これらのステップは、対応するステップ３：２−３：７によって表される。

再帯域幅再ネゴシエーション手順が首尾よく一旦完了すると、選択された番組が、各ＩＰＴＶチャネルを介してユーザに提示される。即ち、図１のステップ１：２１−１：２２に対応するステップ群が実行される。本例では、これらのステップは、図３のステップ３：８によって表される。

別のチャネルを選択することをユーザが一旦選ぶと、ステップ３：９で示されるように、新規の条件付き帯域幅再ネゴシエーション手順が開始される。但し、この場合、現在の帯域幅が選択されたチャネルに対して要求される帯域幅を越えている、つまり、任意の帯域幅再ネゴシエーション手順を直ちに実行するかどうかを決定することなく、チャネル切替が実行される可能性があると想定する。これに応じて、チャネル切替が実行され、ステップ３：１０で示されるように、リクエストされたＩＰＴＶサービスがＵＥ３００に提供される。但し、チャネルが一旦選択されると、ステップ３：１１に示されるように、タイマーによる、帯域幅再ネゴシエーションの決定を遅延するための手順が開始される。

ある程度の時間が経過した後、エンドユーザが別のチャネル切替を行うと想定すると、図２のステップ２１０に対応するステップ３：１２で示されるように、更に別の条件付き帯域幅再ネゴシエーション手順が開始する。

新規のチャネル選択が、ステップ３：９で示される従前のチャネル切替によってトリガーされたタイマーのタイムアウト前に発生すると想定すると、ステップ３：９で選択されたチャネルに対する帯域幅再ネゴシエーションを実行することは必要ないと判定される。その結果、ステップ３：１３で示されるように、係属中のタイマーが終了され、その後、帯域幅再ネゴシエーションを遅延することが実行されるべきか、あるいは、直ちに、無条件の帯域幅再ネゴシエーションが開始されるべきかが再度判定される。

今回でも、現在の帯域幅が、リクエストされたチャネルで要求される帯域幅を越えている、つまり、図２のステップ２０６に対応するステップ３：１４で示されるように、リクエストされたチャネルがユーザに提供できると想定すると、その後、ステップ３：１５（図２のステップ２０７に対応する）で示されるように、別のタイマーと別の帯域幅再ネゴシエーション手順を遅延することが開始される。

最新の状況は、任意の番組を見続けることを選ぶことを決定することなく、ユーザが、利用可能な番組に合わせるために様々なチャネルへ切り替えているイベントで表現することができる。このような状況では、帯域幅再ネゴシエーションは、不必要な遅延、特に、割り当てられた帯域幅の効率的な使用を実現することを努力することの観点から、オペレータによってわずかに行われると考慮する場合の不必要な遅延が発生することになる。

しかしながら、この時点で、ステップ３：１５で示されるタイマーのタイムアウト前に、新規のチャネルが選択されると想定する。これは、ステップ３：１６のタイマーのタイムアウトで示される。タイムアウトの結果として、帯域幅再ネゴシエーション手順が開始されることになる。これは、ユーザが現在のチャネルに接続したままであろう、つまり、ＵＥ３００が、そのチャネルに割り当てられたより狭い帯域幅を使用して、選択されたＩＰＴＶチャネルを受信し続けることができることになるであろうからである。図３のステップ３：１７で示される、このような開始のステップは、図１のステップ１：１５と、図２のステップ２０８の「Ｙｅｓ」分岐に対応する。このステップに続いて、図１のステップ１：１６ａあるいは１：１６ｂから１：２０に対応する、帯域幅再ネゴシエーション手順が開始することになる（不図示）。

上述したように、本明細書で提案される、条件付きの帯域幅再ネゴシエーション手順は、特定の帯域幅要件に基づいている。また、更に上述したように、このような情報は、典型的には、ブロードキャスト提供を介して、１つ以上のＩＰＴＶサービスを提供するＩＰＴＶネットワークからＵＥへ提供することができる。

図４ａは、例示のテーブル４００ａであり、これは、条件付き帯域幅再ネゴシエーション手順に対する入力データを生成するために、ＵＥへ提供されるべき情報が、典型的には、オペレータによってどのようにして構成設定することができるかを示すものである。テーブル４００ａは、「チャネル」欄４０１と、その「チャネル」欄４０１でリストされる各ＩＰＴＶチャネルに対して指定されている最大ビットレートがリストされる「最大ビットレート」欄４０２を備えている。また、テーブル４００ａは、各チャネルに対して指定されているタイマー値がリストされる「ＴＴＲ」欄４０３を備える。

上述のように、最大ビットレート属性は、例えば、周知のオープンＩＰＴＶフォーラム規格に従うブロードキャスト提供で、ＵＥへ通常提供される。この情報に加えて、１つ以上の関連タイマー値は、例えば、ブロードキャスト提供の新規のＴＴＲ属性で、ＵＥに提供することができる。

選択的には、特定のチャネルのグループに対する最大ビットレートの表示である別の変数、ここでは、予約済最大ビットレートとして呼ばれ、「予約済最大ビットレート」欄４０４で示される変数を定義して、また、上述の目的のために使用することができる。テーブル４００ｂは、取り得る構成設定の例示であり、ここでは、それぞれが関連する最大ビットレートが指定されている複数のチャネルが、１つ以上のグループにグループ化されている。

典型的な実施形態では、個々のビットレートが考慮される場合には最大ビットレート属性４０２が、グループに対する最大ビットレートが考慮される場合には予約済最大ビットレート属性が、ＴＴＲ属性とともにＵＥに提供される。そして、条件付き帯域幅再ネゴシエーション手順は、受信したビットレート属性とＴＴＲ属性で提供される値に依存することになる。

予約済最大ビットレートを導入する主な目的は、チャネルに対して指定されている帯域幅要件に基づいて、異なるカテゴリのチャネルをグルーピングすることを可能にすることである。

図４ｂでは、これは、グループ化されている２つのチャネルＳＶＴ−１とＳＶＴ−２によって例示されている。ここでは、共通の予約済最大ビットレート値をこのグループに与えている一方で、ｃａｎａｌ＋、ＴＶ−４及びＴＶ−３がグループ化され、これらには、別のより高い予約済最大ビットレート値が指定されている。

図２のステップ２０２及び２０４で示される評価ステップが、例えば、エンドユーザの行動パターンに基づいている所定の方法に従って指定される予約済最大ビットレート値に基づいている場合、開始される帯域幅再ネゴシエーション手順の数は、ビットレート要件がチャネル毎に指定されている、即ち、個々のチャネルに指定されている最大ビットレート属性に従って指定されている場合でさえも削減することができる。これは、選択されているチャネルが現在のチャネルとして同一のグループに属している限り、新規の帯域幅再ネゴシエーションが要求されないからである。

各最大ビットレート値及び予約済最大ビットレート値の少なくとも一方は、１つ以上の所定の基準に従ってオペレータによって指定されかつ選択することができる。これによって、オペレータに、ＩＰＴＶチャネルに配信のためにどのように帯域幅が使用されるかについて、少なくともある程度の制御を可能にする。

提案されるタイマーに基づく条件付きの帯域幅再ネゴシエーションメカニズムの実装は、ＩＰＴＶネットワーク側で行うための大幅な変更は要求されず、以下で明らかなように、このようなメカニズムを適用するように構成されるＵＥに対して軽微な変更が必要とされるだけである。

実施形態に従う上述のメカニズムを適用するように構成されているＵＥを、図５を参照して説明する。

図５のＵＥ３００は、プロセッサ５０１を備える。このプロセッサ５０１は、１つ以上のサブプロセッサを含むことができる。また、プロセッサ５０１は、上述の処理、手順、それに加えて、任意の従来からの処理をＵＥに対して実行できるようにするために、１つ以上のソフトウェアモジュール及びアプリケーションの少なくとも一方を管理するように構成されている。この従来からの処理とは、典型的には、提案されるタイプの通信エンティティで動作するものである。

ＵＥ３００は、ＩＭＳコアネットワーク１０１で示される１つ以上のネットワークエンティティと情報を交換するように構成されていて、かつ図のＩＰＴＶネットワークで示されるＩＰＴＶオペレータと通信するための、トランシーバ５０２を含んでいる。

ユーザ入力は、ユーザインタフェース（ＵＩ）５０３を介してＵＥ３００に提供される。このユーザインタフェース（ＵＩ）５０３は、ＵＥに統合されていても良いし、あるいは、別のエンティティの一部ととして構成されていても良い。この別のエンティティには、例えば、リモートコントロール装置がある。ＵＥ３００は、更に、ＩＰＴＶセットアップに関連する情報と、それに加えて、ＩＰＴＶメディアコンテンツをエンドユーザに提示するためのディスプレイ５０４を備えている。選択的には、ＵＥ３００がタッチスクリーン機能を有している場合には、ディスプレイ５０４は、ユーザインタフェース５０３に統合されているディスプレイとして構成されていても良い。

ＵＥ３００のソフトウェアアプリケーションは、典型的には、アプリケーションメモリ５０５に記憶され、情報、例えば、ブロードキャスト提供は、別のメモリ５０６にダンロードされるあるいはキャッシュされることの少なくとも一方がなされ、その後、その別のメモリ５０６から取得される。

そして、ＵＥ３００は、タイマー５０７を備える。これは、所定のタイマー値に基づいて動作するように構成されていて、このタイマー値は、例えば、ブロードキャスト提供で転送されるＴＴＲ属性を介して、ＩＰＴＶネットワークからＵＥ３００へ提供されても良い。

複数のチャネルあるいはチャネルのグループに対して帯域幅を再ネゴシエーションすることによって、オペレータに対して、オペレータによって提供されるＩＰＴＶサービスに対して利用可能なリソースの予約の最適化をもたらすことができる。この最適化は、チャネル別に、あるいはチャネルのグループ別に、帯域幅をネゴシエーションすることによって適用することができる。例えば、帯域幅がチャネルのグループに対して標準解像度（ＳＤ）でネゴシエートし、次に、ユーザは、高解像度（ＨＤ）チャネルを選択する場合、帯域幅再ネゴシエーションを含むセッション変更が、そのチャネルのグループに対して実行されることになる。これは、ユーザが、異なるチャネルのグループに属するチャネルの中からチャネル切替をすることを選択している場合である。そして、セッションが、各グループに対して指定されている最大帯域幅／ビットレートでセットアップされることになり、その後、ユーザが異なるグループのチャネルを選択する場合には、新規の最大帯域幅／ビットレートが指定されることになる。

提案されるタイマーベースのメカニズムは、様々なタイプのステーショナリー及び移動機器の両方に容易に実装することができる、とても単純でかつ直接的なソリューションに基づいている。

２つの新規の属性を導入して、所定のビットレート値及び１つ以上の遅延値をブロードキャスト提供でＵＥに提供することによって、１つのチャネルに対して、あるいはチャネルのグループに対して、帯域幅予約を実行するために必要な情報を管理すること容易になる。これは、この入力データが容易に取得可能であるからである。

すべてのチャネルに対して最大帯域幅要件を解析する必要はなくなり、帯域幅再ネゴシエーションの決定を後回しにするべきかどうかを判定する場合に、単に、ＵＥに記憶されている情報を、ブロードキャスト提供で各フィールドをルックアップすれば済むことになる。

ＩＰＴＶオペレータは、帯域幅特性がわずかに異なるだけであるチャネルを切り替える場合に、余計なシグナリングを要求することなく、帯域幅予約をアクセス回線でどのように処理するかについての制御を少なくともある程度獲得することになる。

ＨＤチャネルのサポートは、永続的な基準で、チャネルに対する予約を要求することなく提供され得る。再度、条件付きのタイマーベースの再ネゴシエーション方法を用いる際には、オペレータは、ＨＤチャネルに対する帯域幅予約を制御する明確な手段を処分しなければならない。

また、提案されるメカニズムは、ピクチャ＆ピクチャ（picture & picture）のサポートを提供する。これは、典型的には、小帯域幅に加えて、複数のストリームが１つのディスプレイ上に提示される、モザイクタイプビュー（mosaic type views）を要求する。提案される方法を通して、多くのマルチキャストストリームをセットアップすることができ、また、明確な帯域幅要件を使用することができる。典型的には、このようなストリームは、ＳＤストリームとしても、ある状況では不正であるとされるＨＤストリームとしてもみなされる。この状況とは、実質的で、かつ潜在的には、１５程の小ストリームがサポートできる場合に、アクセス機器、例えば、ＤＳＬＡＭが、３つのストリームが限界を示していると想定できる場合である。このような問題は、提案される方法によって処理することができ、これは、結果として、帯域幅再ネゴシエーションの数を削減することになるからである。

加えて、本発明は、特定の実施形態を参照して説明しているが、この記載は、一般的には、本発明の概念を示すためだけに意図されるものであり、添付の請求項によって定義される本発明の範囲を制限するものとして採られるべきでない。

略語
ＢＧ 境界ゲートウェイ
ＤＳＬＡＭ デジタル加入者線アクセスマルチプレクサ
ＩＭＳ ＩＰマルチメディアサブシステム
ＩＰＴＶ インターネットプロトコルテレビ
ＨＤ 高解像度
ＭＧＣＦ メディアゲートウェイ制御機能
Ｐ−ＣＳＣＦ プロキシ−呼セッション制御機能
Ｓ−ＣＳＣＦ サービング−呼セッション制御機能
ＳＤ 標準解像度
ＳＴＢ セットトップボックス
ＵＥ ユーザ機器

Claims (19)

1. ユーザ機器（３００）がＩＰＴＶネットワーク（１０２）から提供されるＩＰＴＶセッションに関与している場合に、チャネル切替と関連する帯域幅再ネゴシエーションを前記ユーザ機器において管理する方法であって、
   前記方法では、
   リクエストされたチャネル切替（２０１、２１０）に関連付けられている条件付き帯域幅再ネゴシエーション処理が、リクエストされたチャネルが、現在選択されているチャネルよりも狭い帯域幅を要求すると判定される（２０４）場合に適用されるものであり、
   前記条件付き帯域幅再ネゴシエーション処理は、
   前記リクエストされたチャネルへ切り替えるステップ（２０６）と、
   帯域幅再ネゴシエーションが実行されるべきかどうかの決定を遅延する目的のためのタイマーを開始するステップ（２０７）と、
   係属中の前記タイマーのタイムアウトを認識する（２０８ａ）ことに応じて、帯域幅再ネゴシエーションを開始する（２０９）ステップと
   の実行を含んでいる
   ことを特徴とする方法。
2. 前記タイマーのタイムアウトの前に別のチャネル切替のリクエストを認識する（２１０ａ）ことに応じて、前記タイマーを終了するステップ（２１１）を更に備える
   ことを特徴とする請求項１に記載の方法。
3. 係属中のタイマーを終了することに続いて、最新のチャネル切替のリクエストに応じて、条件付き帯域幅再ネゴシエーション処理が適用されるべきであるかが判定される（２０２、２０４）
   ことを特徴とする請求項１に記載の方法。
4. 前記帯域幅の要件が、前記リクエストされたチャネルに対して要求されている帯域幅に対応し、かつそのリクエストされたチャネルに関連付けられているビットレート属性の値と、現在のチャネルに割り当てられている帯域幅に対応し、かつ前記ユーザ機器（３００）で現在利用可能な最大ビットレートとを比較することによって評価される
   ことを特徴とする請求項１または２に記載の方法。
5. 前記ビットレート属性は、前記ＩＰＴＶネットワーク（１０２）から前記ユーザ機器（３００）へ提供される
   ことを特徴とする請求項３に記載の方法。
6. 前記ビットレート属性は、ブロードキャスト提供で前記ユーザ機器（３００）へ提供される
   ことを特徴とする請求項４に記載の方法。
7. 前記ビットレート属性は、チャネル毎に予め定義されているビットレート値を備えている
   ことを特徴とする請求項３または４に記載の方法。
8. 前記ビットレート属性は、最大ビットレート属性である
   ことを特徴とする請求項６に記載の方法。
9. 前記ビットレート属性は、チャネルのグループ毎に予め定義されている値を備える新規の属性である
   ことを特徴とする請求項３乃至５のいずれか１項に記載の方法。
10. 前記タイマーは、前記ＩＰＴＶネットワーク（１０２）から前記ユーザ機器（３００）へ提供されるタイマー値（ＴＴＲ）に従ってセットされる
    ことを特徴とする請求項１乃至９のいずれか１項に記載の方法。
11. 前記タイマー値（ＴＴＲ）は、前記ＩＰＴＶネットワーク（１０２）から提供されるすべてのチャネルに対して予め定義されている共通のタイマー値である
    ことを特徴とする請求項９に記載の方法。
12. 前記タイマー値（ＴＴＲ）は、特定のチャネルに対して予め定義されているチャネル専用のタイマー値である
    ことを特徴とする請求項９に記載の方法。
13. 前記タイマー値（ＴＴＲ）は、特定のチャネルのグループに対して予め定義されているグループ専用のタイマー値である
    ことを特徴とする請求項９に記載の方法。
14. 前記タイマー値（ＴＴＲ）は、ブロードキャスト提供で前記ユーザ機器（３００）へ提供される新規の属性である
    ことを特徴とする請求項９に記載の方法。
15. ユーザ機器（３００）がＩＰＴＶネットワーク（１０２）でＩＰＴＶセッションに関与している場合に、リクエストされたチャネル切替の実行に関連する帯域幅再ネゴシエーションを管理するためのユーザ機器（３００）であって、
    少なくとも２つのＩＰＴＶチャネルに関連付けられている帯域幅要件情報を記憶するように構成されているメモリー（５０６）と、
    前記リクエストされたチャネルによって要求される帯域幅が、現在選択されているチャネルによって要求される帯域幅よりも狭い場合に、リクエストされたチャネル切替に応じて、条件付き帯域幅再ネゴシエーション処理を開始するように構成されているプロセッサ（５０１）と、
    前記プロセッサ（５０１）によって制御可能なタイマー（５０７）であって、条件付き帯域幅再ネゴシエーション中に、帯域幅再ネゴシエーションが開始されるべきかどうかの決定を遅延するように設定されるタイマー（５０７）とを備え、
    前記プロセッサ（５０１）は、更に、前記リクエストされたチャネルへ切り替えることによって条件付き帯域幅再ネゴシエーション手順を開始し、かつ１つ以上の所定のタイマー値（ＴＴＲ）の１つによって定義されるタイムアウトを認識することに応じて、帯域幅再ネゴシエーションを開始するように構成されている
    ことを特徴とするユーザ機器（３００）。
16. 前記メモリーは、更に、少なくとも２つのＩＰＴＶチャネルに関連付けられていて、かつ前記タイマーによって使用されるべき、少なくとも１つの所定のタイマー値（ＴＴＲ）を記憶するように構成されている
    ことを特徴とする請求項１５に記載のユーザ機器（３００）。
17. 係属中のタイマーが終了することに続いて、前記プロセッサ（５０１）は、最新のチャネル切替のリクエストに応じて、条件付き帯域幅再ネゴシエーション処理が適用されるべきであるかを判定するように構成されている
    ことを特徴とする請求項１５に記載のユーザ機器（３００）。
18. 前記プロセッサ（５０１）は、更に、前記リクエストされたチャネルに対して要求されている帯域幅に対応し、かつそのリクエストされたチャネルに関連付けられているビットレート属性のビットレート値と、現在のチャネルに割り当てられている帯域幅に対応し、かつ前記ユーザ機器（３００）で現在利用可能な最大ビットレートとを比較することによって、前記帯域幅要件を評価するように構成されている
    ことを特徴とする請求項１４または１５に記載のユーザ機器（３００）。
19. 前記ユーザ機器（３００）は、セットトップボックス、ＰＤＡ、コンピュータ、あるいは移動電話の内の１つである
    ことを特徴とする請求項１５乃至１７のいずれか１項に記載のユーザ機器（３００）。

Images