"サービス品質管理機能を提供するサービスマネージャを有するネットワークエンティティの少なくとも1つを介して、サービスセンターから移動端末に、それぞれが単一ベアラサービスを介して伝送される複数のパケットストリームの形式でマルチキャストサービスまたはブロードキャストサービスを提供する方法であって、前記マルチキャストサービスまたはブロードキャストサービスに属するベアラサービスと、前記ベアラサービスにより伝送されるパケットストリームまたはそのパケットストリームの組合せにより必要とされるサービス品質属性とを示す情報を受信して、受信した前記情報を含むサービスコンテキストを設定するステップと、前記サービス品質管理機能から、前記ネットワークエンティティの下流側のインターフェース毎における下流側データ伝送のために利用可能なサービス品質を示すサービス品質制約を取得するステップと、前記サービスコンテキスト内に格納される前記サービス品質属性に基づいて、前記マルチキャストサービスまたはブロードキャストサービスに属する前記ベアラサービスから、取得した前記サービス品質制約内でそのストリームを伝送可能なベアラサービスを選択するステップと、選択した前記ベアラサービスを登録するための登録要求を、上流側ネットワークエンティティまたは前記サービスセンターに送信するステップと、前記上流側ネットワークエンティティまたは前記サービスセンターから、登録が成功したベアラサービスを示す登録応答メッセージを受信するステップと、登録が成功したベアラサービス毎に、前記ネットワークエンティティと前記上流側ネットワークエンティティとの間のリンクを設定するステップと、設定した各リンクを介して、それぞれ登録済みのベアラサービスのパケットストリームを受信するステップと、設定した各ベアラサービスのパケットストリームを、前記下流側のインターフェースを介して前記移動端末へ転送するステップと、前記下流側のネットワークインタフェースのネットワーク状態を監視するステップと、前記下流側のネットワークインタフェースのネットワーク状態の変化に適応して、ベアラサービスを動的に追加またはドロップするための登録要求を、前記上流側ネットワークエンティティまたは前記サービスセンターに送信するステップと、を実行する方法。下流側インターフェース毎に、前記マルチキャストサービスまたはブロードキャストサービスに属する前記ベアラサービスのそれぞれの転送状態を、前記サービスコンテキスト内に格納するステップをさらに含む、請求項1記載の方法。下流側ネットワークエンティティからベアラサービスの登録要求を受信するステップと、前記サービスコンテキストに基づいて、要求される前記ベアラサービスのパケットストリームが前記ネットワークエンティティにより受信されたか否かを判定するステップと、受信されたと判定する場合、要求元である前記下流側のネットワークエンティティに、要求される前記ベアラサービスの登録が成功したことを示す登録応答メッセージを送信するステップとをさらに含む、請求項1乃至請求項2のいずれかに記載の方法。前記登録応答メッセージが登録の成功を示す場合、前記ネットワークエンティティと要求元である前記下流側ネットワークエンティティとの間に、要求される前記ベアラサービスのパケットストリームを転送するためのリンクを設定するステップをさらに含む、請求項3記載の方法。要求される前記ベアラサービスのパケットストリームが前記ネットワークエンティティにより受信されていないと判定した場合、前記要求される少なくとも1つのベアラサービスの登録要求を、上流側ネットワークエンティティまたは前記サービスセンターへ送信するステップと、前記上流側ネットワークエンティティまたは前記サービスセンターから、前記要求される少なくとも1つのベアラサービスの登録が成功したか否かを示す登録応答メッセージを受信するステップとをさらに含む、請求項3または請求項4記載の方法。前記登録応答メッセージが登録の成功を示す場合、前記ネットワークエンティティと前記上流側ネットワークまたは前記サービスセンターとの間に、要求される前記ベアラサービスのパケットストリームを転送するためのリンクを設定するステップと、要求元である前記下流側ネットワークエンティティに、要求される前記ベアラサービスの登録が成功したことを示す登録応答メッセージを送信するステップとをさらに含む、請求項5記載の方法。前記上流側ネットワークエンティティまたは前記サービスセンターにベアラサービスの登録要求を送信するステップと、前記上流側ネットワークエンティティまたは前記サービスセンターから、要求される前記ベアラサービスの登録が成功したか否かを示す登録応答メッセージを受信するステップとをさらに含む、請求項1乃至請求項6のいずれかに記載の方法。前記登録応答メッセージが登録の成功を示す場合、前記ネットワークエンティティと、要求元である前記上流側ネットワークエンティティまたは前記サービスセンターとの間に、要求される前記ベアラサービスのパケットストリームを転送するためのリンクを設定するステップをさらに含む、請求項7記載の方法。前記ネットワークエンティティで保持されるサービスコンテキストを、受信した前記登録応答メッセージに基づいて更新するステップをさらに含む、請求項5乃至請求項8のいずれかに記載の方法。下流側ネットワークエンティティからベアラサービスの登録解除要求を受信するステップと、要求元である前記下流側ネットワークエンティティと前記ネットワークエンティティとの間に前記ベアラサービスのために設定される前記リンクを解除するステップと、前記ベアラサービスのストリームが要求元である前記下流側ネットワークエンティティへもはや転送されないことを示すために、前記サービスコンテキストを更新するステップとをさらに含む、請求項1乃至請求項8のいずれかに記載の方法。要求元である前記下流側ネットワークエンティティ以外の別の下流側ネットワークエンティティが前記ネットワークエンティティへのベアラサービスのためのリンクを保持するか否かを判定するステップと、保持しないと判定する場合、前記上流側ネットワークエンティティまたは前記サービスセンターに前記ベアラサービスの登録解除要求を送信するステップとをさらに含む、請求項10記載の方法。前記上流側ネットワークエンティティまたは前記サービスセンターにベアラサービスの登録解除要求を送信するステップと、前記ベアラサービスのストリームが下流側ネットワークエンティティまたは移動端末への下流側にもはや転送されないことを示すために、前記サービスコンテキストを更新するステップとをさらに含む、請求項1乃至請求項11のいずれかに記載の方法。前記サービス品質属性を示す受信情報は、前記複数のパケットストリーム毎のサービス品質属性と、前記パケットストリームの組合せのサービス品質属性とを示す、請求項1乃至請求項12のいずれかに記載の方法。前記ネットワークエンティティは、サービス品質管理機能を有する無線アクセスネットワークのエンティティ、またはサービス品質管理機能を有するコアネットワークのエンティティである、請求項1乃至請求項13のいずれかに記載の方法。選択される少なくとも1つのストリームを、前記サービス品質管理機能から取得される前記サービス品質制約内で伝送可能なストリームに変換するステップをさらに含む、請求項1乃至請求項14のいずれかに記載の方法。前記変換は、前記ストリームのビットレートを変換すること、コーデックタイプを変換すること、空間的分解能または時間的分解能を変換すること、複数層ストリームから単一層ストリームに変換すること、一定ビットレートストリームから可変ビットレートストリームに変換すること、および可変ビットレートストリームから一定ビットレートストリームに変換することのうち少なくとも1つを含む、請求項15記載の方法。前記ネットワークエンティティは、サービス品質管理機能を有する無線アクセスネットワークのエンティティ、またはサービス品質管理機能を有するコアネットワークのエンティティである、請求項1乃至請求項16のいずれかに記載の方法。それぞれが単一ベアラサービスを介して伝送される複数のパケットストリームの形式でのマルチキャストサービスまたはブロードキャストサービスが、サービスセンターから移動端末へ提供されるネットワークエンティティであって、サービス品質管理機能を提供するサービスマネージャと、前記マルチキャストサービスまたはブロードキャストサービスに属するベアラサービスと、前記ベアラサービスにより伝送されるパケットストリームまたはそのパケットストリームの組合せにより必要とされるサービス品質属性とを示す情報を受信する手段と、受信した前記情報を含むサービスコンテキストを設定する手段と、前記サービス品質管理機能から、前記ネットワークエンティティの下流側のインターフェース毎における下流側データ伝送のために利用可能なサービス品質を示すサービス品質制約を取得する手段と、前記サービスコンテキスト内に格納される前記サービス品質属性に基づいて、前記マルチキャストサービスまたはブロードキャストサービスに属する前記ベアラサービスから、取得した前記サービス品質制約内でそのストリームを伝送可能なベアラサービスを選択する手段と、選択した前記ベアラサービスを登録するための登録要求を、上流側ネットワークエンティティまたは前記サービスセンターに送信する手段と、前記上流側ネットワークエンティティまたは前記サービスセンターから、登録が成功したベアラサービスを示す登録応答メッセージを受信する手段と、登録が成功したベアラサービス毎に、前記ネットワークエンティティと前記上流側ネットワークエンティティとの間のリンクを設定する手段と、設定した各リンクを介して、それぞれ登録済みのベアラサービスのパケットストリームを受信する手段と、設定した各ベアラサービスのパケットストリームを、前記下流側のインターフェースを介して前記移動端末へ転送する送信手段と、前記下流側のネットワークインタフェースのネットワーク状態を監視する手段と、前記下流側のネットワークインタフェースのネットワーク状態の変化に適応して、ベアラサービスを動的に追加またはドロップするための登録要求を、前記上流側ネットワークエンティティまたは前記サービスセンターに送信する手段と、を含む、ネットワークエンティティ。請求項2乃至請求項17のいずれかに記載の方法のステップを実行するように適合される手段をさらに含む、請求項18記載のネットワークエンティティ。サービスセンターと、マルチキャストサービスまたはブロードキャストサービスを受信する少なくとも1つの移動端末と、請求項18または請求項19記載の少なくとも1つのネットワークエンティティとを含む移動通信システム。以下の段落では、本発明の様々な実施形態が説明される。例示的な目的のみのため、大部分の実施形態はUMTS通信システムに関連して概説され、以降の節で使用される用語は主にUMTS用語に関連する。但し、使用される用語と、UMTSアーキテクチャに関する実施形態の説明は、本発明の原理と概念をこれらのシステムに限定するように意図するものではない。また、上述の背景技術に記載の詳細説明は、以下に説明される主としてUMTS特有の例示的な実施形態をよりよく理解することのみを意図しており、本発明を、説明する移動通信ネットワークにおける処理と機能の特定の実施形態に限定するものとして理解すべきではない。本発明は、主に帯域幅要件とそれぞれのQoS適応に関して説明されることにさらに留意されたい。しかし、QoSの識別および適応もまた、他の任意のQoSパラメータ、例えば損失率やパラメータの組合せに適用することができる。拡張マルチキャスト/ブロードキャストサービスアーキテクチャの設計面本発明の上記目的を解決するマルチキャスト/ブロードキャストサービスアーキテクチャを設計する際、次の側面を考慮することができる。httpwww3gpporgで入手可能な非特許文献10および非特許文献11に規定されるMBMSアーキテクチャは実用化が近い。速やかにかつ広範囲に配置することを考えると、拡張マルチキャスト/ブロードキャストサービスアーキテクチャは、そのアーキテクチャ仕様に従って、合理的な範囲に限りこの仕様と異なるとよい。したがって、ネットワークノード間のQoSのネゴシエーションは回避され、シグナリングとフィルタリングに関して生成されるオーバーヘッドはできるだけ小さく保たれる。さらに、拡張マルチキャスト/ブロードキャストサービスアーキテクチャを設計する際の別の態様は、コンテンツの適応化に対する広範な可能性を網羅することである。例えば、入手可能な適応型メディアコーデックを取り扱ってもよく、将来の拡張のためのフレームワークを設けてもよい。現在のMBMSアーキテクチャの限界を克服するためにとり得る手法の一つは、適応型メディアコーデックを使用することであろう。適応型メディアコーデックの例は、MPEG2またはMPEG4のような階層型コーデックである。これらのコーデックは、通常、最下位層が最も重要な層となる少なくとも2つ以上の層におけるメディア情報を符号化する。続く上位層は前の下位層に依存する。コンテンツはまた、例えば、様々な帯域幅要件または様々なエラー強度を有する代替ストリームを提供することができるMPEG-1符号器を使用することにより、複数の独立した表現で符号化することができる。適応型メディアコーデックの別の例は、複数記述コーデックMDCの類である。このタイプの符号化では、コンテンツはいくつかの捕捉的な層において符号化される。すなわち、基本層および前の層への依存の概念は消える。特に、受信されるMDC符号化パケットの数が多いほど、得られる品質は高くなる。別の設計留意点はRAN無線アクセスネットワーク資源の有用性であろう。先に概説したように、一般性を失わずに、RANは通常、トランスポートベアラの設定が乏しい無線リソースによるボトルネックを意味し得る基幹システムcriticalsystemと見なすことができる。したがって、拡張マルチキャスト/ブロードキャストサービスアーキテクチャは、無線ネットワーク制御装置において適応機能を考慮することができる。エンドノードの移動性のために、分散ツリーはセッション継続中に変化し得る。最終的に、拡張マルチキャスト/ブロードキャストサービスアーキテクチャは、セッション開始時と、例えばハンドオーバでのセッション中との双方における適応を可能にする。拡張マルチキャスト/ブロードキャストサービスアーキテクチャの別の可能な設計態様は、ネットワークおよび無線構成要素において変化する状況に対する適応性を提供することである。MBMSデータは、多くのRNCと多くのSGSNを通過することができるMBMS分散ツリーを介して、複数のユーザに配布することができる。これにより、ユーザの観点からは、単一のMBMSサービスを含む様々なメディア構成要素が、構成要素毎のQoS識別を可能にする別々のGTPGPRSトンネリングプロトコルトンネルGGSN<->SGSN,SGSN<->RNC、図2参照および無線ベアラRNC<->UEを通じて提供することができる。したがって、拡張マルチキャスト/ブロードキャストサービスアーキテクチャは、無線アクセスネットワークとコアネットワークの双方においてQoS問題に取り組むことができる。特定のネットワークのQoSを実現するために、明確に定義された特性と機能を有するベアラサービス例えば、UMTS/MBMSベアラを、ソースからユーザサービス例えば、マルチキャストサービスまたはブロードキャストサービスの宛先まで設定することができる。ベアラサービスは、縮められたQoSの提供を可能にするすべての態様を含む。これらの態様は、制御シグナリング、ユーザプレーントランスポート、およびQoS管理機能である。図1に、UMTSベアラサービス階層化QoSアーキテクチャを示す。特定層の各ベアラサービスは、下位層により提供されるサービスを利用して、個々のサービスを提供する。特定のQoSを有するUMTSベアラサービスを特定し、設定し、変更し、保持するために必要なノードGGSN、SGSN、RNC等間における機能の特定の関係は、実施形態に固有であってよい。このことは、DiffServ、IntServ非特許文献12を参照、RSVP、またはMPLS等のいくつかの技術を使用できるということを意味する。UMTSの例を考えると、これらの機能のUMTSエンティティへの割り当ては、これらのエンティティが、UMTSベアラサービスに対してネゴシエーションされたQoSコミットメントを実施できることを意味する。これらの機能の具体的な実現は実施形態に依存するが、特定されたQoS特性を維持さえできればよい。すべてのUMTSエンティティのQoS管理機能は、連携して、UMTSベアラサービスのアクセスポイント間でネゴシエーションされたサービスの提供を保証することができる。新しい拡張マルチキャスト/ブロードキャストサービスアーキテクチャを設定することについては、非特許文献13に記載されるサービスマネージャの機能は特に興味深い。サービスマネージャは、責任を負うサービスを設定し、変更し、保持するための制御プレーン例えば、MBMSベアラコンテキストの機能を調整する図9を参照。サービスマネージャはさらに、関連する属性例えば、保証ビットレート、最大ビットレート、最大パケットサイズ、損失率等をすべてのユーザプレーンQoS管理機能に提供する。サービスマネージャはさらに、他のインスタンス例えば、MBMSベアラコンテキスト管理機能にサービスを提供し、ピアサービスマネージャによりシグナリングし、他のインスタンスによって提供されるサービスを利用することができる。サービスマネージャはさらに、より下位の層のサービスを要求するために、属性変換例えば、アプリケーションパケット損失率からRLCSDU損失率へ、SDU損失率から層1/層2ブロック誤り率へを実行することができる。さらに、サービス提供の許可を受信するために他の制御機能に問い合わせることができる。したがって、このようなインフラが提供されることと、MBMSベアラとQoS管理機能との間の相互作用が付与されることを仮定してよい。これにより、どのようにしてユーザが利用可能な資源を利用するか、および他の予知できない事象に関する不確実性のために本質的に異なり得るネットワークCN状態と無線アクセスネットワーク状態の双方を、MBMSサービスのコンテキスト管理機能に知らせることが可能となる。例えば、後者の具体例は典型的なフラッシュクラウド現象であり、ここでは特定のサーバおよび関連するネットワークセグメントがユーザ要求により混み過ぎてしまうoverloaded。別の例は、経路上の一部ノードの故障、あるいはどれだけのユーザが3GPPPSSのようなユニキャストサービスに加わるかに関する不確実性であろう。さらに、拡張マルチキャスト/ブロードキャストサービスアーキテクチャを設計する際の別の態様は、マルチキャスト/ブロードキャストサービスのネットワーク駆動型適応network-drivenadaptationを可能にすることである。現在のMBMSアーキテクチャでは、MBMSユーザは通常、セッション配送の詳細をサーバ例えば、BM-SCとネゴシエーションする機会はほとんどないか全くないであろう。ここが、ネットワーク駆動型適応が重要になる点である。拡張マルチキャスト/ブロードキャストサービスアーキテクチャ本発明の一実施形態によれば、MBMS伝送サービスとMBMSユーザサービスの概念が拡張される。マルチキャストサービスまたはブロードキャストサービス例えば、MBMSサービスを提供するためのマルチベアラサービス例えば、MBMSベアラを利用する手法を検討する。QoSアーキテクチャは、ユーザサービスのストリーム/ベアラの識別がネットワークノードネットワークエンティティにおいて可能になるように拡張される。このようにして、変化する資源、異種の端末、および様々なネットワーク構成要素へのネットワーク駆動型適応は、この情報を用いることにより可能となる。この手法によれば、MBMSユーザサービスコンテキスト形式の追加の状態情報が導入される。MBMSユーザサービスコンテキストは、サービスを含むベアラに対する参照子を格納する。さらに、適応ノードがダウンリンク能力、例えば下流側のQoS制約に従ってベアラの活性化/不活性化を実行できるように、ベアラ間の関係を規定するベアラ関連情報を格納することができる。例示的な目的のためだけに以下で検討するMBMSサービスの時系列timelineは、次のようになるであろう。データプレーンにおいては、要求されたマルチメディアブロードキャストまたはマルチキャストサービスのための選択的/代替的/補捉的ストリームは、QoS要件制約が中間ネットワークエンティティのいずれか1つにより満たされる限り、下流側に転送される各ストリームは単一ベアラサービスを介して伝送される。中間ノードがユーザサービスに属するすべてのパケットストリームを転送できない場合、中間ノードは、全体のセッションストリームを利用可能なQoSに適応させるために、利用可能なベアラサービスのサブセットを選択することによりストリームをフィルタで除去する。中継されるコンテキスト情報例えば、MBMSベアラコンテキストとMBMSユーザサービスコンテキスト内により、ネットワークノードはこのフィルタリングを実行できるようになる。このノードは利用可能であろう残りの選択肢を知っているので、コンテキスト情報によってさらに、ネットワークは突然の能力変化アップグレード/ダウングレードに応答できるようになる。中継されたコンテキスト情報は、サービス構成すなわち、サービスセマンティクスservicesemanticsの選択肢を記述しており、そしてこのコンテキスト情報は、例えば、MBMSユーザサービスコンテキスト内に格納することができる。サービスセマンティクスは、例えば、ユーザサービスに属するベアラ、それらの相互関係階層的、代替的、捕捉的、代替ストリームの場合のストリームの可能な組合せについての情報等を含むことができる。別の設計可能性は、下流にドロップされたストリームとドロップされなかったストリームの状態に関する情報を転送することであろう。その詳細を以下の段落に示す。さらに、突然の能力変化への適応を可能にするために、ストリームのQoSプロファイルを考慮できることに留意されたい。この情報は、設定されたベアラ毎のQoSプロファイルを含む適応ノードに存在するMBMSベアラコンテキストから容易に入手できる。代替的には、サービスセマンティクス内のこの情報をシグナリングし、ユーザサービスコンテキスト内にそれらを格納することも考えられる。一般性を失うことなく、無線アクセスネットワークは3GPPアーキテクチャのボトルネックと考えられ、コアネットワークは過剰供給over-provisionedされていると考えられる。本発明はこの仮定の元でのみ適用可能であると限定すべきでないことに留意されたい。したがって、RNCは自身の無線ドメインにおける利用可能な資源についての知識を持つので、フィルタエンティティすなわち、適応ノードをRNC内に例示することができる。これにより、フィルタエンティティをこの機能に適切なものにする。このようにして、RNCは適応ノードとして動作する。一般的には、RANまたはCNにおけるあらゆるネットワークエンティティは、フィルタエンティティとして動作することができる。しかし、これらのエンティティを、要求されたサービスを受信する移動端末に向かう下流側リンク上の資源を知るフィルタリングエンティティとして選択することは可能である。適応するネットワークエンティティにおけるフィルタの初期化は、制御メッセージを使用することによりトリガすることができる。したがって、以下に説明するMBMS手順を用いることにより、サービスセマンティクスを、対応するRNCに向けて下流側にシグナリングすることができる。サービスセマンティクスは、ユーザサービスと、それらの相互関係と、それらのQoSプロファイルとを伝送するストリームに関する情報を参照するためのものと理解することができる。本発明の一実施形態によれば、サービスセマンティクスを反映するこれらの情報要素は、特定されたMBMSシグナリングメッセージの選択的な領域内に与えられる。さらに、GGSNおよびSGSNのような中間ノードは、メッセージ拡張の値を理解しない場合、それらを解析および処理する必要はなく、それらを下流側に転送するだけでよい。本発明の別の実施形態によれば、上に概説した適応型QoSの概念はさらに、与えられたコンテンツ、例えば階層的コンテンツ、代替的コンテンツ、および捕捉的コンテンツを符号化するための様々なパラダイムをサポートするサービスを可能にすることを目的とする。これは、MBMSサービスを提供するための新規な手法であるので、現在のアーキテクチャにはまだ反映されていない。現在、必要なMBMSコンテキスト情報のシグナリングおよび管理用のプレースホルダplaceholderのみが定義されるが、様々な可能性をどのように実現するかについては定義されていない。したがって、サービスセマンティクス例えば、サービス、それらの相互関係、それらのQoSプロファイル等に属するベアラに関する情報を格納するMBMSユーザサービスコンテキストの使用は、現在のMBMSアーキテクチャと互換性がある。MBMSユーザサービスコンテキスト以下では、適応ノードに保持される、本発明の一実施形態による新規なMBMSユーザサービスコンテキストについて説明する。このコンテキストはセッション動作sessionsemanticsを反映する。すなわち、このコンテキストは、ベアラに関する情報を提供し、適応ノードにおいて転送の判断を行なうために必要な追加のベアラ特性について説明する。MBMSベアラコンテキストは不変のままで現在の3GPP仕様に準拠することができる。各ベアラ情報要素は、ストリームの相互関係に依存した異なる領域を含むことができる。例示された各タイプ階層的、代替的、捕捉的について、その情報要素を以下に説明する。マルチベアラ手法本発明の実施形態によるマルチベアラ手法は、ユーザサービスが複数のトランスポートチャネルすなわちMBMSベアラを利用することができるというアーキテクチャの可能性を活用する。この手法の機能的要素は、表を参照して上に説明したMBMSユーザサービスコンテキストの新しい定義と、ベアラをネットワーク状態とユーザの環境設定に適応させるために適切なサービスのベアラを活性化および非活性化するいわゆる適応ノードの導入である。適応ノードの動作のために必要な追加情報を、上記サービスコンテキストに格納することができる。さらに、サービスの分散ツリー内には2つ以上の適応ノードが存在してもよいことに留意されたい。この実施態様によると、マルチキャストサービスまたはブロードキャストサービスは、複数の代替的ストリーム、階層的ストリーム、または選択的ストリームを含む。適応ノードにより転送されたストリーム毎に、個別のベアラサービスが設定される。この目的のために、図8に示すように、唯一のサービスIPアドレスをストリーム毎に割り当てることができる。本発明の一実施形態によると、適応ノードは、MBMSユーザサービスを含むベアラについての情報を備える。その情報の保管のために、MBMSユーザサービスコンテキスト上の表1、2.1、2.2、3.1、3.2、4.2を参照を使用することができる。このコンテキストは、MBMSユーザサービス識別子と、ベアラの関係を規定するベアラIEを含む。他のベアラ依存性を規定するために、追加のベアラIEを定義してもよい。ベアラIEは、関連するMBMSベアラの識別子、およびこれらについての情報、例えばMBMSベアラID、優先順位、転送状態のリストを含む。また、各ベアラには、対応するMBMSベアラコンテキストに格納される唯一のIPマルチキャストアドレスを割り当てることができるので、このIPアドレスは、適切なMBMSベアラIDとして機能することが好ましい。代替的ベアラタイプについては、デフォルトの選択肢と、重要なベアラ組合せの明示的なリストとが含まれなければならない。適応ノードにおいてMBMSユーザサービスコンテキストを設定するために、MBMS手順、例えばMBMS登録手順で既に規定されたメッセージを、MBMSユーザサービスコンテキストを設定するために必要な情報を伝送するための拡張された形式で再利用することができる。これらの手順の1つは、MBMSサービスに関与するネットワークノードの登録をトリガすることができる。すなわち、MBMSベアラコンテキストとMBMSユーザサービスコンテキストが例示される。QoS属性はMBMSユーザサービスコンテキスト内に規定しなくてよいので、MBMS登録手順図10を参照は、上記MBMSユーザサービスコンテキストを設定するのに十分と考えられる。サービスに属する個々のベアラサービスのQoS属性は、対応するMBMSベアラコンテキストの一部として既に存在していてもよい。この目的のために、適応ノードは、MBMSユーザサービスコンテキスト情報を持つことへの関心を示さなければならない。代替的には、サービスセンターが、登録手順においてデフォルトで交換されるメッセージ内に関連情報を含むということであろう。この目的のために、図5に示すMBMS登録要求のプライベート拡張IEを使用することができる。代替的には、このメッセージ内の必須の領域を規定してもよい。さらには、MBMSユーザサービスコンテキストを設定するための新しいMBMS手順とメッセージを規定してもよい。登録手順によるMBMSユーザサービスコンテキストの設定に続いて、MBMSセッション開始手順を使用して、MBMSベアラコンテキストのQoSプロファイルに規定される実際のベアラプレーンQoS属性を伝送し、予約することができる詳細については、非特許文献14を参照。このように、適応を実行するノードのみが、これらMBMSメッセージで伝送される情報を使用できるようになる。互換性のない他のノードはそれらを無視し、次の下流側ノードへそれらを転送してもよい。上記実施例は、コアネットワークCNメッセージGGSN<->SGSNに限定された。CNにおいて、図5に示すMBMS登録要求メッセージは、GTP-Cプロトコルの一部である図3の制御プレーンプロトコルスタックも参照。このことは、一般的には、あらゆるMBMS制御メッセージに対してあてはまる。しかし、CNとRANとの間で、RANAP無線アクセスネットワークアプリケーション部プロトコルを使用することによりシグナリングを実現することができる。RANAPプロトコルは現在、MBMS専用メッセージフォーマットを明示的に規定していない。そこで、CNメッセージに対して規定される属性が、RANAPプロトコルによってUTRANにおいて交換されるメッセージにおいて、選択的なIEまたは新たに規定される必須のIE内に等価なマッピングを見出すことを提案する。当業者は通常、メッセージの機能およびコンテンツと手順に対する、拡張、変更または置換のいずれかにより、上記機能を同じように実現できることを理解するであろう。適応ノードがMBMSユーザサービスコンテキストを一旦設定すると、適応ノードは、MBMSベアラコンテキストが存在する登録済みベアラ毎にMBMSセッション開始要求を受信できる状態になる。それぞれのMBMSセッション開始要求が独立して処理される標準のメカニズムとは対照的に、これらのベアラは相互に関連するので、適応ノードは、すべてのMBMSセッション開始要求メッセージを同時に考慮することができる。上に説明したように、ベアラの相互関係は、MBMSユーザサービスコンテキストに保持される情報の一部である。本発明の一実施形態によると、登録されたベアラのいずれかのMBMSセッション開始メッセージを受信すると、適応ノードは、MBMSベアラコンテキストを更新するとともに、関連する他のすべてのベアラのセッション開始要求メッセージを待つことができる。適応ノードは、MBMSユーザサービスコンテキストからのベアラの関係およびベアラ優先順位または、重要なベアラ代替と、そのMBMSベアラコンテキストによる各ベアラのQoS要件とを解決する。それにより、そのMBMSサービスについて予約された資源によりマッチするベアラの組を決定することができる。上に説明したように、適応ノードの下流側のインターフェース上でそれぞれ入手可能な利用可能資源は、例えば、サービスマネージャ、すなわちそのQoS管理機能から得ることができる。代替的には、登録されたベアラのいずれかのMBMSセッション開始メッセージを受信すると、適応ノードは、これらがそうすることを許容していれば、サービスを提供し始めることができる。この場合、それぞれのMBMSベアラコンテキストは、登録されたベアラ毎に、セッション開始メッセージが受信されたか否か、すなわちベアラ状態がアクティブなのかスタンバイなのかを示すことができる。したがって、適応ノードの下流側インターフェースにおける下流側QoS制約に最も良くマッチするベアラを、MBMSユーザサービスコンテキストからのベアラ関係およびベアラ優先順位または重要なベアラ代替と、そのMBMSベアラコンテキストによる各ベアラのQoS要件およびステータス情報とに基づいて選択することができる。登録されたすべてのベアラのMBMSセッション開始メッセージを適応ノードが待つ例示的な実施形態に戻る。すべてのセッション開始要求が一旦受信され、あるいはタイマが終了すると、適応ノードは、提供されたベアラまたはベアラの組合せのQoSレベルのQoS要件を検査することができる。現在のネットワーク状態下でサポートすることができる最良のQoSレベルのために、肯定的なMBMSセッション開始応答は、対応するベアラまたはベアラ群に対して送信され、一方、その他すべてに対しては、否定的な応答が送信される。例えば、下流側インターフェース上で利用可能なビットレートに適応するベアラの組合せに属するベアラは、応答メッセージで肯定確認応答され得る。なお、下流側ノードによりサポートされていないストリームは、適応ノードに到達しない。なぜなら、これらのベアラは、MBMSセッション開始手順中またはサービス中のいずれかにおいて、例えば、適応ノードが、利用可能資源無しを示すことによりMBMSセッション開始応答で拒否されるからである。これにより、資源の効率的な利用に寄与することができる。MBMSユーザサービスの動的適応上記実施形態から明らかとなるように、適応ノードにおいてMBMSユーザサービスコンテキストを設定することにより、マルチキャストサービスまたはブロードキャストサービスの動的適応のための基本が確立された。すなわち、下流側ノードのいずれかをQoSに関してアップグレードまたはダウングレードする場合に、適応ノードはこれを管理することができる。MBMSユーザサービスコンテキストを利用することにより、適応ノードは、どのベアラが特定のノードに対して活性化/非活性化されるかを判定し、対応する手順を開始することができる。ここでは、ベアラサービスは、そのストリームがサービスセンターにより提供される限り設定され続けるということに留意されたい。本発明の実施形態によると、マルチキャストサービスまたはブロードキャストサービスの各ベアラサービスの分散ツリーは、ネットワーク状態に依存してネットワークノード間にリンクを追加/解除することにより、ネットワーク状態に動的に適応される。例えば、ある適応ノードが上流側の適応ノードにおいてサービスのアップグレード、例えばサービスベアラの追加を要求した場合、要求側適応ノードに対して、分散ツリー内の上流側のインターフェース上のネットワーク資源がそれを許容すれば、要求されたベアラの分散ツリーにおける新たなブランチが設定される。この処理については、以下の図6と図7を参照してさらに詳細に説明する。MBMSユーザサービスの適応は、MBMSユーザサービスコンテキストのパラメータをアップグレード、ダウングレード、あるいは多少なりとも変更する処理として規定することができる。適応は、例えば、UEがRNCがホストする1つのセルから異なるRNCがホストする別のRNCへ移動する場合、UEが継続MBMSサービスの途中でサービスを受信することを要求した場合、または適応ノードが良かれ悪しかれ利用可能資源が変化したということを理解した場合などのいくつかの場合に実行可能である。2つのタイプの適応を規定することができる。上述のように、動的適応はサービス中に実行され、静的適応はサービスの初めに実行され得る。更に、通常、適応は、ネットワーク内に1つまたは複数の適応ノードが存在する場合に実行することができる。本発明の例示的な実施形態によると、動的適応は、2つ以上の適応ノードが存在する。例えばRNCとSGSNが利用可能なシステムにおいて実行することができる。例えば、MBMSユーザサービスの適応を実行するために、適応ノードは、各適応ノードで提供されるQoS管理機能、すなわち上述のようなサービスマネージャとインターフェースすることができる。QoS管理機能は、無線アクセスネットワークまたはコアネットワークの一部であるネットワークにおいて利用可能な資源を制御し、割り当て、監視する責任を負う。非特許文献15には、このようなフレームワークの動作に関する詳細が記載されている。各適応ノードがQoS管理機能にアクセスすると仮定すると、各適応ノードは、そのネットワークインターフェースの能力または有用性の変化を知ることができる。これらの変化の例は、MBMSサービスを提供する下流側ノードまたは上流側ノードに設定されるトンネルの数または能力の増加または減少であろう。なお、上記では、MBMSセッション開始手順中の適応を取り扱った。以下、本発明の例示的な実施形態では、追加ベアラが要求された場合について図6と図7を参照して説明する。ベアラサービスをドロップするための動作は類似していることに留意されたい。下流側ノードが追加ベアラを必要としていることを適応ノードが知っており、適応ノードが下流側ノードへのインターフェース上に十分な能力を有する場合、適応ノードは次の上流側の適応ノードに、追加ベアラのためのMBMS登録要求図6要求ID4参照を発行することができる。MBMSユーザサービスコンテキストを適応ノードにおいて利用可能にすることにより、適応ノードは、ユーザサービスに属するベアラを識別することができる。RNC1のMBMSユーザサービスコンテキストからわかるように、ベアラID1のストリームのみがBS2に提供されるので、ベアラID1の転送状態は転送のみに設定される。これらのベアラサービスのそれぞれのQoSプロファイルは、MBMSベアラコンテキスト内に容易に存在させることができる。なお、ベアラのデータは現在RNC1により受信されていないので、要求されたID4を有するベアラはスタンバイモードにある。したがって、各適応ノードにおいて利用可能なコンテキスト情報内の情報を使用することにより、適応ノードは、現在のネットワーク資源に基づいて、サービスを提供するための適切なベアラ組合せを選択することができる。追加のベアラサービスを要求する際のこの新しいMBMS登録要求の機能は、利用可能な資源に対する上流側の適応ノードのポーリングに限定してよい。ポーリングされるノードが次のいずれかの利用可能な十分な資源を有する場合、以下のようになる。1.ポーリングされるノードもまた、利用可能な要求ベアラを有する。図6では、それはRNC2へ転送されるので、SGSN1は利用可能なベアラID4を有するベアラコンテキスト内のベアラID4:QoS4、アクティブ参照。この場合、これらは、インターフェース毎に、このベアラの転送状態を、RNC1へのインターフェース毎のサービスコンテキスト内でドロップから転送に設定することにより要求ベアラを転送し、さらに肯定的なMBMS登録応答を下流に伝播することができる。適応ノードは、転送されるベアラとMBMS登録応答に加えて、新たなMBMSセッション開始要求を下流側に発行することができる。しかし、QoSプロファイルは下流側ノードにおいて既に設定されているかもしれないので、これは厳密には必要ではない。さらに、要求元である下流側ノードは、それに従ってそのコンテキストを更新することができる図7を参照。RNC1のベアラコンテキストでは、RNC1は今やこのベアラサービスを介してデータを受信するので、ベアラID4の状態はアクティブに設定される。さらに、ユーザサービスコンテキストにおいて、RNC1は要求されたベアラのデータをBS2へ伝播するので、RNC1はBS2へのインターフェースについての転送状態を転送に設定する。2.ポーリングされるノードはベアラを有しないが、それを下流側に提供する能力を有する。これは、それぞれのコンテキストに次のように反映されるであろう図6と図7を参照。RNC1のユーザサービスコンテキストは、すべてのインターフェースに対しエントリベアラID4→ドロップを、そしてベアラコンテキスト内にエントリベアラID4:QoS4、スタンバイを有することになる。この場合、適応ノードは、要求されたベアラまたはBM-SCの登録に成功した適応ノードに到達するまで、MBMS登録要求を上流側に伝播することができる。双方の場合において、上記項目1で説明した手順を実行することができる。3.第3の可能性は、どの適応ノードもベアラの登録に成功せず、あるいはベアラを下流に提供する能力が利用できる場合である。この場合、適応ノードは否定的なMBMS登録要求応答を送信することができる。肯定的なMBMS登録要求が要求元への下流側への経路における適応ノードに到達すると、対応するMBMSベアラコンテキストはアクティブに設定され、データは下流側ノードへ転送することができる。この処理は、影響を受けるそれぞれのインターフェース毎に、すべてのMBMSベアラコンテキストとMBMSユーザサービスコンテキストがそれに応じて転送状態の領域を転送に更新するまで繰り返すことができる。どの適応ノードもベアラの登録に成功しなかった場合、あるいはベアラを下流側に提供する能力が得られない場合は、上流側ノードを連続的にポーリングすることができ、故障ネットワークの動作をもたらすかもしれない。これを回避するために、本発明の別の実施形態は、上流側ノードが最初のMBMS登録要求に肯定的に応答するまで、後のポーリングを禁止することを提案する。これは、このようなアップグレードを拒否した上流側ノードもまた、その後のアップグレードが可能かどうかを監視するということを意味する。したがって、上流ノードが今やこのような要求に対処するであろうことが理解される。ベアラが、分散ツリーの枝路におけるネットワークノード間に設定されたリンクをドロップダウングレードする場合、それぞれのベアラは、可能な限り遠い上流側までのリンクを解除することができる。本発明の一実施形態によると、適応ノードが選択されたベアラをドロップした後、すなわちベアラのストリームを下流側に伝播するために設定されたリンクを解除した後に、適応ノードはMBMS登録要求を上流側に送ることができる。肯定的なMBMS登録応答を応答として受信することができる。このことは上流側の他のすべての適応ノードがベアラをドロップすることを選択したことを意味する。したがって、発信元以外は他のどの適応ノードも実際にはベアラに関するストリームを必要としないので、帯域幅を節約することができる。否定的な応答は、別のノードがローカルにドロップされたベアラを実際に必要としているということを示すことができる。上記様々な実施形態において概説されたマルチベアラ手法は、適応ノードがトランスポートベアラを活性化/不活性化することによりストリームをフィルタリングするので、簡単な決定論理を使用することにより実施することができる。したがって、RANおよびCNノードにおける実施は、単純な決定論理により容易に実現することができる。さらに、ユーザの環境設定および能力への適応は、ユーザによりすなわち、ネットワーク内において適切な一組のベアラを選択することにより可能となる。また、利用されるベアラの資源のみが予約される、すなわちネットワークノード間の必要なリンクが必要なときにのみ設定されるので、この手法は資源的に効率的である。進化したUTRANにおけるスケーラブルで適応型QoSアーキテクチャ将来のUTRANアーキテクチャは、さらに多くのインテリジェンス拡張制御および管理機能の提供がネットワークの端まで、例えばノードB基地局までさらに押し進められることを想定する。これを行う1つの理由は、RNCが現在影響を及ぼしている単一点singlepoint障害を取り除くことである。この将来のUTRANアーキテクチャは、上記様々な実施形態による適応型QoSアーキテクチャを完全に取り込むことができるということに留意すべきである。上に概説した原理を利用するために、MBMSベアラコンテキストは、新しいノード、および適応ノード、例えば新しいUTRANアーキテクチャのノードBとして動作するノード内のMBMSユーザサービスコンテキストにおいて、それに応じて複製することができる。提案するMBMS手順は、それに応じて拡張することができる。他の機能と要件は、上の章において概説したものと同様である。ストリーム変換本発明の別の実施形態では、適応ノードが、例えば、サービスの1つまたは複数のストリームを下流側QoS制約に整合させるためにパケットストリームの変換を可能にする手段をさらに具備することを提案する。これは、例えば、ノードの下流側インターフェース毎のQoS検査が、関連するベアラを介してサービスにより提供されるストリームのそれぞれについて失敗した状況において適用可能である。可能なストリームまたは、ストリームの組合せ変換の概要は、非特許文献16に提案されている。コード変換技術は、例えば、以下のように様々な要求に対応することができる。●様々なコーデック間を切り替えるためのコーデック変換●時間分解能またはフレーム率の低減●空間分解能の低減●一定ビットレートから可変ビットレートへの変換●複数階層ストリームから単一層ストリームへの変換コーデック変換の適用は、相異なるアーキテクチャ同士または専用ネットワーク同士がインターフェースする場合、例えばMPEGファイルからウインドウズ専用WMAコーデックへの変換に適切であろう。フレーム率低減は、符号化された画像の品質を保持し、処理ニーズを低減しつつ、ビットレートを低減するために有用であろう。フレーム率低減の典型的な使用例は、画像分解能を保持する低減率が記憶装置能力の点から許容される妥協点である監視アプリケーションである。空間分解能の低減は、移動端末のような小型装置に媒体を適応させる場合に有用であろう。典型的な変換は、MPEG2画像5.3Mbps、30fps、720x480からMPEG4単一プロファイルレベル2128Kbps、10fps、352x240への変換である。一定ビットレートストリームから可変ビットレートストリームへの変換は、非特許文献17に例示される。その目的は、可変ビットレートサービスネットワークにおいて一定ビットレートストリームに対処することである。さらに、複数階層ストリーム、例えばMPEG-4FGSの単一層ストリームへの変換は、適応ノードが実行できる変換の別の例である。これは、非特許文献18に例示される。ハードウェアおよびソフトウェアの実現本発明の別の実施形態は、ハードウェアとソフトウェアを使用することにより上述の様々な実施形態を実施することに関する。上記様々な方法および上記様々な論理ブロック、モジュール、回路は、例えば、汎用プロセッサ、デジタル信号プロセッサDSP、特定用途向けICASIC、フィールドプログラマブルゲートアレイFPGA、または他のプログラマブルロジックデバイス等の演算装置を使用することにより、実施または実行することができるということが理解される。本発明の様々な実施形態はまた、これら装置の組み合わせにより実行または具現化することができる。さらに、本発明の様々な実施形態は、また、プロセッサにより、またはハードウェアで直接実行されるソフトウェアモジュールによって実施することができる。また、ソフトウェアモジュールとハードウェア実装とを組み合わせることが可能である。上記ソフトウェアモジュールは、例えば、RAM、EPROM、EEPROM、フラッシュメモリ、レジスタ、ハードディスク、CD-ROM、DVD等の任意のタイプのコンピュータ読取り可能な記憶媒体に格納することができる。"