"移動通信システムの無線アクセス網を介してマルチキャストサービスまたはブロードキャストサービスを移動端末が受信するための方法であって、マルチキャストサービスまたはブロードキャストサービスは、マルチキャストサービスまたはブロードキャストサービスを提供するための複数のベアラに関連付けられ、前記移動端末が、マルチキャストサービスまたはブロードキャストサービスに関連付けられた複数のベアラを示すサービス記述情報を受信するステップと、前記サービス記述情報が、前記複数のベアラが予め決められた異なる品質において、RANまたはコアネットワーク内のネットワークエンティティにより選択的に提供されることを示し、前記移動端末が、マルチキャストサービスまたはブロードキャストサービスを要求することを示すためにマルチキャストサービスまたはブロードキャストサービスに関連付けられた前記複数のベアラを起動するステップと、前記移動端末が、前記起動した複数のベアラのうち前記ネットワークエンティティが選択したベアラについてサービス通知情報を受信するステップと、前記移動端末が、前記サービス記述情報に基づき受信した前記サービス通知情報が有効であると認識した場合には、前記サービス通知情報中に示されたベアラを介して、マルチキャストサービスまたはブロードキャストサービスのコンテンツデータを受信するステップと、を有する方法。前記マルチキャストサービスまたはブロードキャストサービスは、UMTSネットワークを介して提供されるMBMSユーザサービスである、請求項1に記載の方法。前記サービス通知情報は、少なくとも一つのベアラを移動端末で受信するために必要なパラメータをさらに示す、請求項1または請求項2に記載の方法。前記サービス記述情報の内容を記述するためにマークアップ言語が使用される、請求項1から請求項3のいずれかに記載の方法。前記複数のベアラを起動するステップは、マルチキャストサービスまたはブロードキャストサービスの配信ツリー中における論理状態を設定することである、請求項1から4のいずれかに記載の方法。マルチキャストサービスまたはブロードキャストサービスを受信する移動端末であって、マルチキャストサービスまたはブロードキャストサービスは移動通信システムの無線アクセス網を介して送信され、マルチキャストサービスまたはブロードキャストサービスは、マルチキャストサービスまたはブロードキャストサービスを提供するための複数のベアラに関連付けられ、前記移動端末は、マルチキャストサービスまたはブロードキャストサービスに関連付けられたサービス記述情報を受信する受信部と、前記サービス記述情報が、前記複数のベアラが予め決められた異なる品質において、RANまたはコアネットワーク内のネットワークエンティティにより選択的に提供されることを示し、前記移動端末が、マルチキャストサービスまたはブロードキャストサービスを要求することを示すためにマルチキャストサービスまたはブロードキャストサービスに関連付けられた前記複数のベアラを起動する送信部と、前記受信部が、前記起動した複数のベアラのうち前記ネットワークエンティティが選択したベアラについてサービス通知情報を受信するようになされ、前記サービス記述情報に基づき受信した前記サービス通知情報が有効であると認識した場合には、前記受信部が、前記サービス通知情報中に示されたベアラを介して、マルチキャストサービスまたはブロードキャストサービスのコンテンツデータを受信する、移動端末。前記マルチキャストサービスまたはブロードキャストサービスは、UMTSネットワークを介して提供されるMBMSユーザサービスである、請求項6に記載の移動端末。前記サービス通知情報は、少なくとも一つのベアラを移動端末で受信するために必要なパラメータをさらに示す、請求項6または請求項7に記載の移動端末。前記サービス記述情報の内容を記述するためにマークアップ言語が使用される、請求項6から請求項8のいずれかに記載の移動端末。前記複数のベアラを起動するステップは、マルチキャストサービスまたはブロードキャストサービスの配信ツリー中における論理状態を設定することである、請求項6から9のいずれかに記載の移動端末。添付の図と図面を参照して、以下に本発明をさらに詳細に説明する。各図中の同等または対応する細部の要素は、同一参照番号を付けて示される。以下のパラグラフでは、本発明の多様な実施形態を説明することにする。典型的な例を示すという目的でのみ、実施形態の大部分は、UMTS通信システムに関連して概説される。また、以下の節で使用される専門用語は、主にUMTSの用語に関係する。しかし、使用された用語とUMTSアーキテクチャに関連した実施形態の説明は、本発明の原理と概念を上記システムに限定するという意味合いはない。また、前述の背景技術の節で述べた詳細な説明は、以下に説明する主にUMTS向きの典型的な実施例をよりよく理解してもらうためのものにすぎず、移動通信網におけるプロセス及び機能のここで述べた特定の実装に本発明を限定するものと理解すべきではない。本発明は、帯域幅要件とQoS適応に関して主に説明されることにさらに留意する。しかし、QoS差別化及び適応は、例えば、損失率等のその他のQoSパラメータまたはパラメータの組み合わせに適用されてもよい。サービスの階層化した、補完的または代替的ストリームを転送する複数のベアラによるユーザサービスの提供を可能にするために、MBMSトランスポートサービス及びMBMSユーザサービスは拡張される。拡張されたマルチキャストサービス/ブロードキャストサービスアーキテクチャの設計についての重要な態様は、コンテンツ適応の広範囲な可能性を網羅することである。例えば、利用可能な適応的メディアコーデックがカバーされ得るし、将来の拡張のためのフレームワークも提供可能である。現行のMBMSアーキテクチャの限界を克服するための一つの可能なアプローチは、適応的メディアコーデックの使用であると言える。適応的メディアコーデックの例は、MPEG2またはMPEG4等の階層化コーデックである。これらのコーデックは、通常に、少なくとも2または3層でメディア情報を符号化し、この符号化によれば最下位層が最も重要な層である。後続のより高位の層は、その前のより低位の層に依存する。コンテンツは、例えば、異なる帯域幅要件または異なるエラー耐性をもつ代替的ストリームの提供を可能にするMPEG-1エンコーダを使用するなど、いくつかの独立した表現で符号化可能でもある。適応的メディアコーデックの別の例は、マルチプルディスクリプションコーデックMDCのファミリーである。この形式のコーディングでは、コンテンツはいくつかの補完的な層に符号化される。すなわち、基本層と前層への依存という概念がなくなる。特に、MDC符号化されたパケットはより多数受信すれば、より高い品質が得られる。さらに別の設計の考慮点は、RAN無線アクセス網リソースの可用性である。一般性を失わずに、RANは、通常、少ない無線リソースのためにトランスポートベアラの確立がボトルネックになる危機的なシステムとみなせる。したがって、拡張マルチキャスト/ブロードキャストサービスアーキテクチャは、RNCs無線ネットワークコントローラにおいてRANリソースの変化に対応する適応機能を考慮する必要がある。UEsのモビリティにより、配信ツリーは進行中のセッション中に変化することがあり得る。したがって、拡張マルチキャスト/ブロードキャストサービスアーキテクチャは、セッション開始時とセッション中、例えば、ハンドオーバ時の両方での適応を可能にし得る。拡張マルチキャスト/ブロードキャストサービスアーキテクチャの別の可能な設計態様は、ネットワーク及び無線構成要素の状態の変化への適応を提供することである。MBMSのデータは、多くのRNCsと多くのSGSNsを通過する可能性があるMBMS配信ツリーを通じて複数のユーザに配信され得る。したがって、ユーザの視点からは単一のMBMSサービスを含んでなる異なるメディア構成要素が、各構成要素についてのQoS差別化を可能にする、別個のGTPGPRSトンネリングプロトコルトンネルGGSN←→SGSN、SGSN←→RNC-図1を参照と無線ベアラRNC←→UEを通って提供され得る。拡張マルチキャスト/ブロードキャストサービスアーキテクチャは、したがって、無線アクセスとコアネットワークの両方でのQoSの課題に対処することができる。あるネットワークQoSを実現するために、明確に定義された特性と機能をもつベアラサービス例えば、UMTS/MBMSベアラをユーザサービス例えば、マルチキャストサービスまたはブロードキャストサービスの送信元から送信先へ確立することができる。ベアラサービスは、契約QoSの提供を可能にするすべての態様を含む。これらの態様は、とりわけ、制御シグナリング、ユーザプレーンのトランスポート及びQoS管理機能等である。UMTSベアラサービス階層化QoSアーキテクチャを図2に示す。特定の層の各ベアラサービスは、それより下位の層で提供されるサービスを使用して、その個別のサービスを提供する。特定のQoSをもつUMTSベアラサービスを指定し、確立し、修正し、維持するために必要なノードGGSN、SGSN、RNC等間の機能の特定の関係は、実装により固有であり得る。これは、DiffServ、IntServBradenほか、IntegratedServicesintheInternetArchitectureanOverview、RFC1633、1994を参照、RSVPまたはMPLS等のいくつかの技術が使用できることを意味する。UMTSの例を考えると、上記の機能のUMTSエンティティへの割当ては、これらのエンティティがUMTSベアラサービスに対してネゴシエートされたQoSコミットメントを実施し得ることを意味する。上記の機能の特定の実現は、実装に依存し、特定のQoS特性を維持しさえすればよい。すべてのUMTSエンティティのQoS管理機能は合同して、UMTSベアラサービスのアクセスポイント間でネゴシエートされたサービスの提供を保証できる。新しい拡張マルチキャスト/ブロードキャストサービスアーキテクチャの確立については、3GPPTS23107TechnicalSpecificationGroupServicesandSystemAspectsQualityofServiceconceptandarchitectureversion610March2004を参照の6211項に記載されている、サービスマネージャの機能が特に興味深いと言えよう。サービスマネージャは、それが担うサービスの確立、修正及び維持のために制御プレーンの機能例えば、MBMSベアラコンテクストを調整する図3を参照。さらに、サービスマネージャは、すべてのユーザプレーンのQoS管理機能に適切な属性例えば、保証ビットレート、最大ビットレート、最大パケットサイズ、損失率等を与える。サービスマネージャはさらに、ほかのインスタンス例えば、MBMSベアラコンテクスト管理機能にサービスを提供し、ピアのサービスマネージャと信号を交換し、ほかのインスタンスにより提供されたサービスを使用することができる。サービスマネージャはさらに、下位層のサービスを要求するために、属性変換例えば、アプリケーションパケット損失率をRLCSDU損失率に変換、SDU損失率をレイヤ1/レイヤ2ブロック誤り率に変換を行うことができる。さらに、サービスマネージャは、サービス提供に対する許可を受信するためにほかの制御機能に問い合わせを行うことができる。したがって、このような基盤インフラストラクチャが提供され、MBMSベアラとQoS管理機能間の相互動作が与えられると仮定できる。これは、ユーザが利用可能なリソースをどのように使用するかは不確実であるために本質的に変動するものであるネットワークCNとRANの両方の状態とその他の予測できない事象をMBMSユーザサービス用のコンテクスト管理機能で把握することを可能にする。例えば、後者の具体的な例は、特定のサーバとその関連ネットワークセグメントがユーザ要求により過負荷状態になる典型的なフラッシュクラウド突発的殺到現象である。別の例としては、サービス配信パス上のノードの障害またはどのくらい多くのユーザが3GPPMBMSのようなマルチキャストサービスに参加するのかが不確実な場合などがあげられる。さらに、拡張マルチキャスト/ブロードキャストサービスアーキテクチャを設計する際の別の態様は、マルチキャスト/ブロードキャストサービスのネットワーク主導の適応を可能にすることである。現在のMBMSアーキテクチャでは、MBMSユーザがサーバ例えば、BM-SCとセッション配信の詳細をネゴシエートする機会は、通常、ほとんどまたはまったくない。ここが、ネットワーク主導の適応が重要になるところである。QoSアーキテクチャは、ユーザサービスのストリーム/ベアラの差別化が、MBMSユーザサービスの配信ツリーに沿ったネットワークノードネットワークエンティティにおいて可能になるように拡張される。このようにして、変動するリソース、異種多様な端末、異なるネットワーク構成要素に対するネットワーク主導の適応が可能である。このアプローチによれば、MBMSユーザサービスコンテクストの形の追加の状態情報が導入される。MBMSユーザサービスコンテクストは、サービスに含まれたベアラへの参照を格納する。さらに、下りQoS制限等のダウンリンク性能に従って適応を行うノードがベアラの起動/停止を実行できるように、ベアラ間の関係を定義するベアラ関係情報を格納できる。典型的な例を示すという目的でのみ以下で考察するMBMSユーザサービスの時系列は、次のとおりである。データプレーンにおいて、要求されたマルチメディアブロードキャストまたはマルチキャストサービスのサービスコンテンツデータ通常は選択的/代替的/補完的ストリームの形のは、QoS要件制限が中間に介在するネットワークエンティティのいずれかによって満たされる限り、そのMBMSベアラによって下り方向へ転送される。例えば、中間に介在するノードがユーザサービスに属するすべてのベアラを転送できない場合、全セッションストリームを利用可能なQoSに適応させるために、ノードは使用可能なベアラサービスのサブセットを選択することによってベアラをフィルタにかける。中継されたコンテクスト情報例えば、MBMSベアラコンテクスト内の及び新たに定義したMBMSユーザサービスコンテクスト内のは、ネットワークノードでこのフィルタがけを行えるようにする。MBMSベアラコンテクスト及び新たに定義したMBMSユーザサービスコンテクストを設定するために必要な情報は、要求に応じて、配信ツリーの下流へ伝播することができる。コンテクスト情報はさらに、ノードがすべてのオプション、すなわち、サービス配信に利用できる可能なベアラの組み合わせを把握できるので、ネットワークが突然の容量変化上昇/下降に対応できるようにし得る。中継されたコンテクスト情報は、サービス設定、すなわち、サービスセマンティクスのオプションを記述し、例えば、MBMSユーザサービスコンテクストに格納可能である。サービスセマンティクスは、例えば、ユーザサービスに属する各ベアラとそれらの相互関係階層化、代替的、補完的、可能なストリームの組み合わせ-代替的ストリームの場合-等に関する情報を含むことができる。さらに別の設計可能性としては、切り離した、切り離さなかったストリームの状態に関する情報を下流へ転送することがあげられる。さらに、突然の容量変化への適応を可能にするために、ストリームのQoSプロファイルも考慮に入れてもよいことにさらに留意すべきである。確立された各ベアラについてのQoSプロファイルからなるこの情報は、適応を行うノードに存在するMBMSベアラコンテクストから容易に得ることができる。あるいは、サービスセマンティクス内のこの情報をシグナリングし、ユーザサービスコンテクストに格納することも考えられる。一般性を失わずに、無線アクセス網は3GPPアーキテクチャではボトルネックとみなせ、コアネットワークは過剰供給とみなせる。ここで説明する概念は、この仮定の下での適用可能性に限定されないことに留意すべきである。したがって、フィルタを行うエンティティすなわち、適応を行うノードの例としてRNCsがあげられるが、これはRNCsが自身の無線領域において利用可能なリソースに関する知識を得るからである。このため、RNCsはこの機能に十分適合する。一般に、RANまたはCN内のいずれかのネットワークエンティティは、フィルタリングを行うエンティティとして動作できる。例えば、要求したサービスを受信する移動端末に向けて下り方向のリンク上のリソースを把握しているエンティティをフィルタリングを行うエンティティとして選択することは実現可能であると言える。適応を行うネットワークエンティティでのフィルタの初期設定は、制御メッセージを使用してトリガすることができる。したがって、MBMSの手順を使用して、サービスセマンティクスを対応するRNCへ下り方向のシグナリングすることができる。サービスセマンティクスは、ユーザサービスを運ぶ各ストリーム、それらの相互関係、及びそれらのQoSプロファイルに関する情報を示すものと理解してよい。例えば、サービスセマンティクスを反映するこれらの個々の情報は、指定されたMBMSシグナリングメッセージのオプショナルなフィールド内に記述される。さらに、GGSNsやSGSNs等の介在するノードは、メッセージの拡張部分の意味について理解しないならば、それを解析し処理する必要はない。そのまま下流へ転送してよい。さらに、前述の適応的QoSの概念は、ある任意のコンテンツを符号化するための、例えば、階層化、代替的または補完的といった異なるパラダイムをサポートするサービスの提供を可能にする。これは、MBMSサービスを提供するための新規なアプローチであり、現在のアーキテクチャにはまだ反映されていないものである。現在、必要なMBMSコンテンツ情報のシグナリング及び管理のための代替物だけは定義されているが、異なる可能性をいかに実現するかは示されていない。サービスセマンティクスを格納するためのMBMSユーザサービスコンテクスト例えば、サービスに属する各ベアラ、それらの相互関係、それらのQoSプロファイル等の情報の使用は、したがって、現行のMBMSアーキテクチャに適合する。本発明は、MBMSユーザサービス等のマルチキャストサービスまたはブロードキャストサービスが、代替的、補完的または階層化であり得る複数のベアラからなることを前提にする。したがって、各ベアラは、各ベアラをUEへ配信するために満たされなければならない予め決められたQoS制限に関連付けられる。さらに、各ベアラに関連付けられたQoSパラメータは、ベアラをUEへ配信するために必要なビットレートのみでなく、その内容例えば、ベアラにより運ばれるストリームの保証ビットレート、最大ビットレート、最大パケットサイズ、損失率等も記述する。したがって、特定のQoSの関係が、例えば、代替的、補完的または階層化関係が、MBMSベアラ間またはベアラのグループ間に存在する。MBMSユーザサービスのQoSは、前述のように、3Gネットワークでは自律的に適応される。RANまたはCN内のQoS判断ポイント適応を行うノードは、適応を行うノードに実装されたサービスの品質管理機能から得たサービスの品質制限に基づいて、ダウンリンクの利用可能なリソースに従ってMBMSベアラの一部を選択する/切り離す。UEsはRAN及び/またはCN内でのこの選択/切り離し処理は気づかないので、MBMSユーザサービス記述に示されたとおり、MBMSユーザサービスのすべてのベアラを受信するものと想定する。従って、切り離されたベアラは、従来のUEではエラーケースとみなされた。UEsは、その結果、利用可能なQoSレベルの一つでサービスを実際に受信することに気づかない。したがって、UEsはMBMSユーザサービスを正しく受信できない。この問題のよりよい理解のために、次の例を示す。MBMSユーザサービスは、サービス代替物を表す二つのMBMSベアラを含むものとする。すなわち各ベアラは同一コンテンツを配信するが、異なる品質レベルに符号化されている例えば、二つの異なるビットレートに符号化された音声視覚ストリーム。さらに、各ベアラに設定された関連した配信後手順があってもよい例えば、コンテンツ受信報告。MBMSベアラはサービス代替物に相当するので、一つだけをUEへ配信するように決められる。UEは、両方のMBMSベアラの記述を含むMBMSユーザサービス記述を受信する。通常の挙動により、UEは両方のMBMSベアラを要求する。問題は、MBMSベアラが代替物であり、そのうちの一つに対してだけリソースの確保をすればよいことにUEが気づかないことである。したがって、UEは両方のベアラに対するリソース例えば、ストリームーミングバッファを確保することになり、UE中のリソース例えば、メモリ空間を無駄に消費することになる。さらに、UEは両方のベアラに対する配信後手順それがある場合を開始する。しかし、ネットワークは、実際にUEへ配信されたサービスベアラに対する配信後手順を受信することにしか関与しない。これは、ネットワークリソースの無駄な消費となる。本発明の実施形態の重要な態様は、新しいグルーピング記述を標準のMBMSユーザサービス記述の拡張として導入したことである。MBMSユーザサービス記述は、XMLに基づく。新しい要素は、MBMSユーザサービスに含まれた個々のMBMSベアラ間のグルーピング関係を記述する。この拡張記述により、UEsはMBMSベアラのグルーピングを把握し、ベアラのすべてのグループが受信されなくてもよいことを知る。したがって、UEsは、MBMSベアラのサブセットのみを受信するように準備される。したがって、あるMBMSベアラの非受信が直ちにエラーケースだとはみなされない。一方、UEsは完全なグループが受信されるか否かを判断でき、これによりMBMSユーザサービスが正しく受信されたかどうかをUEsは理解できる。以下の行は、従来のMBMSユーザサービス記述のXMLスキーマの典型的な例を示す。userServiceDescriptionユーザサービス記述は、すべてのMBMSユーザサービス記述情報を有する最上位要素である。最も重要なdeliveryMethod配信方法要素は、MBMSユーザサービスの特定のMBMSベアラに関するすべての情報を集める。MBMSベアラの詳細を記述するすべての情報は、ほかの専用のメタデータ記述メディア及びセッション記述とも言うに含まれる。これらはdeliveryMethod配信方法要素内のそれぞれの一意なURIによって参照される。さらに、deliveryMethod配信方法要素にそれぞれのURIs/メディアまたはセッション記述によってリストされたMBMSベアラの各々は、各ベアラに関連付けられたTMGIテンポラリーマルチキャストグループ識別子をもつ。トランスポート及びメディア符号化パラメータに関しては、これらの情報は、deliveryMethod配信方法要素のsessionDescriptionURIセッション記述URI属性に指定される、個別のSDP記述に含まれる。以下の行は、上記のXML仕様のdeliveryMethod配信方法要素内で重要とされる専用メタデータ記述の内容の典型的な例を示す。v0ouser12328908445262890842807INIP62201056D112E144A1E24sFiledeliverysessionexampleiMoreinformationt28733974962873404696ambmsmodebroadcast1234aFECdeclaration0encodingid128instanceid0asourcefilterinclINIP620012101224096FFFE258EC9aflutetsi3mapplication12345FLUTEUDP0cINIP6FF1E03AD7F2E172A1E241alangENaFEC0本発明の一実施形態に関連する行はambmsmodebroadcast1234であり、ここではMBMSユーザサービスがブロードキャストモードで提供され、TMGI、1234をもつベアラにより提供されることが規定される。MBMSユーザサービス記述により参照されたサービス記述中のこのTMGIに基づいて、UEは、MBMSユーザサービス記述中の各URIを、参照されたサービス記述中に記述された、コンテンツデータを提供するベアラのTMGIに関連付けることができる。したがって、UEで受信されるMBMS通知の対象となるベアラのTMGIsは、以下に述べるように、それぞれのTMGIsで識別されたベアラが有効なベアラ組み合わせをなすか否かをUEが判断できるようにする。マルチキャストモードでのMBMSサービスの場合、参照されたサービス記述が各ベアラのMTGIsを示さないこともあることに留意すべきである。以下の行は、本発明の例示的な実施形態によるMBMSベアラのグルーピングのサポートを可能にする、標準MBMSユーザサービス記述のXMLスキーマの拡張を示す太字の行は適用された拡張を示す。個々のMBMSベアラ間のグルーピング関係を記述するために、二つの新しい要素が導入されている。これらは、一つ以上のqosGroupItemQoSグループ項目要素を含む、qosGroupQoSグループ要素である。qosGroupQoSグループ要素は、deliveryMethod配信方法要素と同じレベルで定義される。qosGroupQoSグループ内のqosGroupItemQoSグループ項目要素は、MBMSベアラの一つのグループを定義する。deliveryMethod配信方法要素のsessionDescriptionURIセッション記述URI属性で使用されたのと同じURIが個々のMBMSベアラを一意に識別する。したがって、UEで受信された通知情報内に含まれたTMGIsは、MBMSユーザサービス記述中の定義によるベアラグループがネットワークによって提供されているか否かを判断するために使用できる。次に、本発明の別の実施形態による、標準のMBMSユーザサービス記述のXMLスキーマの拡張の別の典型的な例を以下に示す太字の行が適用された拡張を示す。この拡張は、MBMSベアラグループの関係の記述をサポートするために使用できる。各MBMSベアラグループとそれらの関係を記述するために、三つの新しい要素がある。deliveryMethod配信方法要素と同じレベルで定義されるQoSRelationQoS関係要素は、ベアラグループ間の大まかな関係を記述する。これらのグループは、個別の代替物に相当し得る。すなわち、これらのうちの一つが排他的選択される。あるいは互いに依存する。例えば、同じメディアの各層に相当する。これは、QoSRelationQoS関係要素の個別属性に表現される。QoSRelationQoS関係要素の子要素は、上記の例示的なXML定義に記述されたように、ある一つのグループに属する各MBMSベアラを指定するQoSGroupQoSグループ要素である。この実施形態で提示した拡張は、QoSGroupQoSグループ要素のQoSPrioQoS優先順位属性であり、これは定義されたベアラグループの順位を表わすために必要とされる。この順位の正確な意味は、QoSRelationQoS関係要素に依存する。QoS優先順位は、代替物の順位、例えば、最良から最悪までを指定するか、あるいは相互依存グループの順位、例えば、ベース層とエンハンスメント層を指定する。より一般的には、MBMSユーザサービス記述は、UEsへ配信されるサービスを記述するメタデータの集合として定義できる。サービスを受信するためのすべての必要なパラメータが、この記述に含まれる。サービスコンテンツを送信する各MBMSベアラは、個々のSDP記述によって記述される。これらは、MBMSユーザサービス記述中で、URIを介してdeliveryMethod配信方法要素において参照される。したがって、各deliveryMethod配信方法要素は、MBMSユーザサービスに含まれた個別のMBMSベアラを表現する。SDP記述を参照するURIは、このMBMSベアラを一意に識別する。QoSGroupQoSグループと呼ばれる、ユーザサービス記述中の新しい要素は、関連したMBMSベアラをグループにまとめる。このようなQoSGroupQoSグループ要素に含まれた各MBMSベアラは、ベアラの同一のグループに属する。これらは、QoSGroupQoSグループの子要素である新しいQoSGroupItemQoSグループ項目要素に指定される。各MBMSベアラのSDP記述のURIは、ベアラ識別子として使用される。以下のXML例は、上に示した二つの例示的な実施形態によるXMLスキーマの定義による拡張されたMBMSユーザサービス記述を示す。httpwwwexamplecomsession1sdphttpwwwexamplecomsession2sdphttpwwwexamplecomsession3sdphttpwwwexamplecomsession4sdpこの記述には、4個のdeliverMethod配信方法要素がある。これは、当該MBMSユーザサービスが4個のMBMSベアラからなることを意味する。さらに、2個のQoSGroupQoSグループ要素によって2個のグループが指定される。この例では、各グループがMBMSベアラのうちの2個を含み、これは、各ベアラのSDP記述のURIを含む2個のQoSGroupItemQoSグループ項目要素によって表現される。上記の例示的なXML定義で提示したような拡張MBMSユーザサービス記述を使用して、階層化、補完的層または代替的層で配信されるMBMSユーザサービスを受信するUEsは、個々のMBMSベアラ間のグルーピング関係を知り、自律的なQoS適応がネットワーク内で行われるものと認識する。したがって、UEsは、MBMSユーザサービス記述に含まれたすべてのMBMSベアラのサブセットのみを受信するように準備される。UEsはグループが完全に受信されるか否かを判断でき、それによりUEsはMBMSユーザサービスを正しく受信できる。上記の例示的なXMLスキームは、あるグループに属するMBMSベアラを識別する問題を解決するだけでなく、これらのグループがどのような相互関係を有するかを定義することもできる例えば、代替物または層を表わす。関連して、上に提示した第二のXMLスキーマは、グループの相互関係の記述を導入する。これは、新しいQoSRelationQoS関係要素とQoSGroupQoSグループ要素の拡張によって達成される。QoSRelationQoS関係要素は、大まかなグループの関係、すなわち、グループが別個のメディア代替物であるか、または同一メディアの異なる階層に属するかを指定する。そして、QoSGroupQoSグループ要素のQoSPrioQoS優先順位属性がグループのハイアラーキを指定する。これは、QoSRelationQoS関係要素に依存する、代替物の順位例えば、最良から最悪までの代替物または階層の順位例えば、ベース及びエンハンスメント層のいずれかである。以下の例は拡張を示す。httpwwwexamplecomsession1sdphttpwwwexamplecomsession2sdphttpwwwexamplecomsession3sdphttpwwwexamplecomsession4sdp上記の例におけるQoSRelationQoS関係要素は、記述されたグループが個別に扱われるべきもの、すなわち、サービスの代替物であることを示す。QoSPrioQoS優先順位属性は、最初に記述されたグループが好適なグループであることを示す。上記の例示的実施形態では、MBMSユーザサービス記述中で参照されたメタデータ記述に定義された各々のベアラのコンテンツデータを提供するためにRNCによって選択された各ベアラについてのMBMS通知メッセージをUEは受信する。例えば、ページングチャネルを介してMBMS通知メッセージにて受信された、サービスを提供しているベアラのTMGIsをUEは把握する。この通知により受信したTMGIsとMBMSユーザサービス記述の各々のQoSGroupQoSグループ要素のQoSGroupItemQoSグループ項目要素で参照された各記述で定義されたTMGIsを比較して、UEは予め決められたベアラ設定においてサービスを受信するために必要なすべてのベアラが受信されたか否かを認識する。MBMS通知が、MBMSユーザサービス記述に定義されたベアラの組み合わせを告知する場合、UEは当該ベアラ上で提供されたコンテンツデータを受信でき、受信したビデオデータを表示したり、受信した音声信号を再生するなどして、UEのユーザにコンテンツを提供できる。MBMS通知が、MBMSユーザサービス記述に定義されたベアラ組み合わせを告知しない場合、UEはこの状況に対処するために異なる方策をとることができる。例えば、UEはユーザにサービスが提供できないことを知らせてもよい。すなわち、エラーメッセージを発動してもよい。あるいは、MBMSユーザサービスの指示されたMBMSベアラのセットを、指示されたベアラがMBMSユーザサービス記述に示されたベアラ組み合わせに対応するように、おそらく満たす後続の通知の受信をUEは待ってもよい。所定の時間期間内に有効なベアラ組み合わせがUEに示されることを確実にするために、例えば、タイマーを使用してもよい。タイマーの期限が切れた時点で、UEはエラーメッセージの発動を決定してもよい。以下のパラグラフでは、本発明の例示的な実施形態によるMBMSマルチキャストサービスの典型的な動作を図5を参照して概説する。以下に簡単に概説する、加入、参加及び退去手順を実行することを要求されないことを除いて、MBMSブロードキャストサービスの提供も同様である。最初のステップでは、関連したMBMSマルチキャストサービスをユーザが受信することを可能にするサービスプロバイダとユーザの関係が確立される。いわゆるサービス加入は、サービスプロバイダにより提供されるサービスを受信することへのユーザの合意である。サービスプロバイダは、ネットワーク運用者のネットワーク中の適当なデータベースに加入情報を記録するUMTSでは、サービスプロバイダは第三者であり得るが、MBMSはネットワーク運用者によって制御される。次のステップは、MBMSユーザサービス告知/検出メカニズム401である。このメカニズムは、ユーザが要求を出すことまたは利用可能なMBMSユーザサービスの範囲について通知を受けることを可能にする。利用可能なサービスは、例えば、運用者固有のMBMSユーザサービスやPLMNの外部のコンテンツプロバイダからのサービスがあり得る。サービス告知は、サービスとサービス起動に必要なパラメータ例えば、IPマルチキャストアドレス、場合によりその他のサービスに関連したパラメータ例えば、サービス開始時についてのユーザ情報を配布するために使用される。一般に、この情報は、前述の本発明の実施形態による拡張MBMSユーザサービス記述により提供される502。本発明のある実施形態によれば、SMS等の標準的メカニズム、または個々のUEの性能に応じてユーザの問い合わせを促進するアプリケーションを含むいくつかのサービス検出メカニズムが使用可能である。ユーザに利用可能なMBMSユーザサービスを通知するために選択される方法は、ユーザの位置に対応する。例えば、CBSセルブロードキャストサービス、MBMSマルチキャストユーザサービス及びブロードキャストユーザサービスを通知するためのMBMSブロードキャストモード、MBMSマルチキャストユーザサービスを通知するためのMBMSマルチキャストモード、WAP、SMS-PPまたはMMS等のPUSHメカニズム、URL例えば、HTTP、FTPを介したなどが、MBMSユーザサービス告知メカニズムとして使用可能である。次に、ユーザによるMBMS起動503が行われる。このプロセスにより、加入者は、マルチキャストグループに参加する、すなわち、ユーザは、彼/彼女が特定のMBMSベアラサービスのマルチキャストモードのデータを受信する意思があることをネットワークに示す403。MBMSマルチキャストサービス起動手順は、特定のマルチキャストMBMSベアラサービスからのデータ受信を可能にするために、ネットワークにユーザを登録する。起動は、UEとネットワーク間のシグナリング手順である。手順は、起動された各マルチキャストMBMSベアラサービスに対して、UE、SGSNとGGSN及びRNCにMBMSUEコンテクストを設定することができる。サービス起動手順において、UEは、例えば、受信を希望するMBMSユーザサービスのMBMSベアラベアラサービスのIPマルチキャストアドレスをBM-SCに通知することができる。その後のBM-SCとUE間のシグナリングにおいて、UEは通知したMBMSベアラのTMGIsを提供される。したがって、マルチキャストサービスの場合、メディアまたはセッション記述MBMSユーザサービス記述により参照される中のベアラサービスのIPマルチキャストアドレスが、ベアラの相互関係とグルーピング間の、ベアラのTMGIsに対するマッピングを設定するために使用できる。MBMS起動手順503のこのシグナリングにおいて、さらにMBMS登録手順が実行される。MBMS登録は、下流のノードが上流のノードに特定のMBMSベアラサービスのセッション属性とデータを、それをさらに下流へ配信するために受信したい旨を通知する手順である。この手順は、BM-SCからサービスに関与したUEsまでのMBMSセッション属性とデータの転送のための配信ツリーを構築し、配信ツリー中の各ネットワークノードにMBMSベアラコンテクストを設定する。MBMSユーザサービスの各ベアラMBMSベアラサービスに対して、MBMSベアラコンテクストが各ネットワークノードに設定される504。MBMSベアラコンテクストは、とりわけ、各MBMSベアラサービスに要求されたQoSとUEがサポートしなければならない最小のベアラ能力等を具備する。しかし、ネットワークノードは、単一のMBMSユーザサービスに属する各ベアラまたはそれらの関係については認識しない。MBMS登録手順は、MBMSベアラサービスの相互関係に関する情報をネットワークノードに提供する、以下に説明するMBMSユーザサービスコンテクストを配送ツリー上のネットワークノードに設定する504ように適合されてもよい。MBMSサービスの要求元のUEをサーブするRNCでも設定される、MBMSユーザサービスコンテクストは、セッションセマンティクスを反映する。すなわち、ベアラの関係に関する情報を提供し、追加のベアラ特性を記述する。下表は、本発明の例示的な実施形態によるこのコンテクストの内容を示す。各ベアラの情報要素は、ベアラの相互関係に応じて異なるフィールドを含み得る。例示タイプ階層化、代替的、及び補完的ごとの情報要素を以下に述べる。上記のMBMSユーザサービスコンテクストを維持するとき、RNCは、MBMSユーザサービスを提供可能な異なるベアラの組み合わせとそれらの要求QoSを認識するMBMSベアラコンテクスト。次のステップ505では、BM-SCはデータ送信とセッション開始の準備が整う。セッション開始は、ユーザによるサービスの起動とは関わりなく発生可能である。セッション開始手順は、ネットワーク内でMBMSデータを転送するためのベアラリソースを確保する契機を与える。したがって、BM-SCはサービスコンテンツの下流への送信509を始める。セッション開始手順を通じて、QoSや、もし得られていれば、推定セッション継続時間などのMBMSセッション属性が、該当MBMSベアラサービスのためにすでに登録されたGGSNsとSGSNs及び登録されたSGSNに接続されるすべてのRNCsへ提供される。本発明の一つの実施形態によれば、MBMSユーザサービスの要求元のUEをサーブするRNCは、UE側へのそのインタフェース上の利用可能なリソースをそのサービスの品質管理機能から要求することができる506。この機能は、RNCにUEへの下流側のサービス提供のためのQoS制限を提供する。サービスの品質管理機能から得た情報とベアラの関係性の知識MBMSユーザサービスコンテクストとそれぞれのQoS要件MBMSベアラコンテクストに基づいて、RNCは、サービスの品質管理機能から得たQoS制限内で要求されたMBMSユーザサービスをUEに提供できるMBMSベアラ組み合わせを選択することができる507。このようにして、RNCは、そこを通じてUEsが以前にサービスを要求したすべてのインタフェース上のQoS制限を得て、各インタフェースセルについて各々のQoS制限を満たすベアラ組み合わせを選択することができる。各セルに対して適切なベアラ組み合わせを選択した後、それぞれ選択したMBMSベアラの来るべき進行中の可能性もある送信をサービス要求元のUEsに通知するために、RNCは選択したMBMSベアラについてのMBMS通知をブロードキャストすることができる508。まだ送信されていなければ、RNCは、MBMSユーザサービスの選択したMBMSベアラ上でコンテンツデータのマルチキャストを開始することができる。MBMSサービスへの関与を告知したUEは、そのセル内の選択されたベアラについてのMBMS通知を受信し、選択されたベアラからのコンテンツデータ受信を開始する510。MBMSユーザサービス記述によってベアラの相互関係の情報を知らされているので、上述したように、UEは有効なベアラ組み合わせが提供されるか否かを認識できる。MBMSユーザサービス提供時に実行される手順のシーケンスを完了するため、セッション停止手順を次に説明する。BM-SCブロードキャスト/マルチキャストサービスセンターは、MBMSセッションを終了すべきと判断したとき、MBMSセッション停止手順を開始する。ネットワーク内のベアラプレーンリソースの解放を正当化するのに十分長い期間にわたり、さらなるMBMSデータの送信が期待されないときに、セッションは通常終了される。手順は、該当MBMSベアラサービスのために登録されたすべてのSGSNsとGGSNs及びSGSNとのluベアラプレーンを確立したRNCcへ伝播される。退去手順によって、UEはMBMSマルチキャストサービスの受信を終了することができる。ユーザによるこのMBMSマルチキャスト停止は、加入者がマルチキャストグループから退去するそのメンバーであることをやめるプロセスであり、すなわち、特定のMBMSベアラサービスのマルチキャストモードのデータの受信をユーザはもはや望まない。本発明の別の実施形態は、ハードウェア及びソフトウェアを使用した、上記の多様な実施形態の実現に関係する。多様な前述の方法、並びに前述の様々な論理ブロック、モジュール、回路は、例えば、汎用プロセッサ、デジタルシグナルプロセッサDSP、特定用途向け集積回路ASIC、フィールドプログラマブルゲートアレイFPGAまたはその他のプログラム可能論理素子など、コンピューティングデバイスを使用して実現可能または実施可能であることが認識される。本発明の多様な実施形態は、上記のデバイスの組合せによっても実施または実現可能である。さらに、本発明の多様な実施形態は、プロセッサにより実行されるソフトウェアモジュールを用いても実現可能であり、またはハードウェアにより直接実現することもできる。また、ソフトウェアモジュールとハードウェア実現の組合せも可能である。ソフトウェアモジュールは、例えば、RAM,EPROM,EEPROM,フラッシュメモリ、レジスタ、ハードディスク、CD-ROM,DVD等、コンピュータで読取り可能などんな種類の記憶媒体に記憶されてもよい。"