(57)【要約】      （修正有）【課題】移動通信システムの無線アクセス網を介してマルチキャストサービスまたはブロードキャストサービスを移動端末に提供する。【解決手段】無線アクセス網のネットワーク・エンティティによって実行され、コア・ネットワークからのセッション開始メッセージを受信し、セッション開始メッセージは、複数のベアラの中で予め決められたベアラグループを示すユーザサービス記述と関連付けられ、予め決められたベアラグループの各々はサービスパラメータの予め決められた品質でマルチキャストサービスまたはブロードキャストサービスを提供し、ベアラグループは、下り通信に利用可能なサービスの品質と予め決められたベアラグループの各々のサービスパラメータの予め決められた品質とに基づいて選択され、その旨を示すサービス通知情報を移動端末へ送信し、選択したベアラグループの内の少なくとも一つのベアラを介して移動端末へコンテンツ・データを送信する。【選択図】図５
2010081625.tif 000002
【特許請求の範囲】
【請求項１】
移動通信システムの無線アクセス網を介してマルチキャストサービスまたはブロードキャストサービスを移動端末に提供する方法であって、前記マルチキャストサービスまたはブロードキャストサービスは、前記マルチキャストサービスまたはブロードキャストサービスを提供するための複数のベアラに関連付けられ、
前記方法は、前記無線アクセス網の無線インタフェース上の無線リソースを制御する無線アクセス網のネットワーク・エンティティによって実行される以下のステップ、すなわち、
前記移動通信網のコア・ネットワークのネットワーク・エンティティから前記マルチキャストサービスまたはブロードキャストサービスのセッション開始メッセージを受信するステップと、
前記セッション開始メッセージは、複数のベアラの中で予め決められたベアラグループを示すユーザサービス記述と関連付けられ、予め決められたベアラグループの各々は前記複数のベアラのうち少なくとも１つを含み、予め決められたベアラグループの各々はサービスパラメータの予め決められた品質で前記マルチキャストサービスまたはブロードキャストサービスを提供し、
移動端末のサービス要求が受信された前記ネットワーク・エンティティのインタフェースを介した下り送信に利用可能なサービスの品質の範囲内で提供可能な予め決められた前記ベアラグループから１つのベアラグループを選択するステップと、
前記ベアラグループは、下り通信に利用可能なサービスの品質と予め決められたベアラグループの各々についてのサービスパラメータの予め決められた品質とに基づいて選択され、
前記選択したベアラグループを示すサービス通知情報を前記移動端末へ送信するステップと、
前記選択したベアラグループのうちの前記少なくとも一つのベアラを介して前記移動端末へ前記マルチキャストサービスまたはブロードキャストサービスのコンテンツ・データを送信するステップと、を有する方法。
【請求項２】
前記マルチキャストサービスまたはブロードキャストサービスは、ＵＭＴＳネットワークを介して提供されるＭＢＭＳユーザ・サービスである、請求項１に記載の方法。
【請求項３】
前記サービス通知情報は、少なくとも一つのベアラを移動端末で受信するために必要なパラメータをさらに示す、請求項１または請求項２に記載の方法。
【請求項４】
前記サービス記述情報の内容を記述するためにマークアップ言語が使用される、請求項１から請求項３のいずれかに記載の方法。
【請求項５】
前記サービス記述情報が、前記予め決められたベアラグループを定義するタグを有する、請求項４に記載の方法。
【請求項６】
無線アクセス網において使用するためのネットワーク・エンティティであって、移動通信システムの無線アクセス網を介して移動端末にマルチキャストサービスまたはブロードキャストサービスを提供するためのネットワーク・エンティティであり、前記マルチキャストサービスまたはブロードキャストサービスは、前記マルチキャストサービスまたはブロードキャストサービスを提供するための複数のベアラに関連付けられ、
前記ネットワーク・エンティティは、
前記無線アクセス網の無線インタフェース上の無線リソースを制御する手段と、
前記移動通信網のコア・ネットワークのネットワーク・エンティティから前記マルチキャストサービスまたはブロードキャストサービスのセッション開始メッセージを受信するための受信器と、
前記セッション開始メッセージは、複数のベアラの中で予め決められたベアラグループを示すユーザサービス記述と関連付けられ、予め決められたベアラグループの各々は前記複数のベアラのうち少なくとも１つを含み、予め決められたベアラグループの各々はサービスパラメータの予め決められた品質で前記マルチキャストサービスまたはブロードキャストサービスを提供し、
移動端末のサービス要求が受信された前記ネットワーク・エンティティのインタフェースを介した下り送信に利用可能なサービスの品質を示すサービスの品質の範囲内で提供可能な予め決められた前記ベアラグループから１つのベアラグループを選択する選択手段と、
前記選択手段は、下り通信に利用可能なサービスの品質と予め決められたベアラグループの各々についてのサービスパラメータの予め決められた品質とに基づいてベアラグループを選択するように適合され、
前記選択したベアラグループを示すサービス通知情報を前記移動端末へ送信するための送信器であって、かつ前記選択したベアラグループのうちの前記少なくとも一つのベアラを介して前記移動端末へ前記マルチキャストサービスまたはブロードキャストサービスのコンテンツ・データを送信するための送信器と、を具備するネットワーク・エンティティ。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、移動通信システムの無線アクセス網を介して移動端末（のユーザ）にマルチキャストサービスまたはブロードキャストサービスを提供するための方法に関係する。マルチキャストサービスまたはブロードキャストサービスは、マルチキャストサービスまたはブロードキャストサービスを提供するための複数のベアラに関連付けられる。さらに、本発明は、マルチキャスサービストまたはブロードキャストサービスをユーザに提供するための移動端末、並びに移動通信システムの無線アクセス網を介して移動端末にマルチキャストサービスまたはブロードキャストサービスを提供するためのネットワーク・エンティティに関係する。
【背景技術】
【０００２】
コーディング技術の最近の進歩は、例えば、代替的な（サイマル放送）または選択的な（階層化マルチキャスト）等の複数のストリームでブロードキャスト／マルチキャストサービスのデータ伝送を可能にする。このような手法は、マルチキャスト通信において大まかな品質適応を可能にする点でインタネット・コミュニティの注目を集め、これに関するいくつかの研究作業が構築されてきた。例えば、非特許文献１（ＩＥＴＦによるすべてのＲＦＣｓ及びインターネット・ドラフトはhttp://www.ietf.orgで得られる）、非特許文献２、または非特許文献３がある。しかし、例えば、３ＧＰＰネットワークのような３Ｇ通信ネットワークのアーキテクチャはインターネットのアーキテクチャとは異なるため、異なるかまたは追加のソリューションが必要とされる。
【０００３】
異種ユーザ群への帯域幅集約型マルチメディア・アプリケーションのますます進みつつある普及に伴い、インターネットにおけるマルチキャスト速度及び輻輳制御の分野で集中的な研究がなされてきた。McCanneほかのパイオニア的研究（非特許文献４を参照）以来、複数の速度のマルチキャストが、ストリーミング・シナリオにおける速度適応に向けた非常に有望なアプローチとして考察されてきた。累積的階層化データ編成（階層的に符号化した）に基づく、またはストリーム複製（独立ストリーム及び代替ストリーム）に基づく、異なる品質レベルに対応付けた複数のマルチキャスト・グループを使用して同一コンテンツを送信するための技術が提案された。さらに、両方のアプローチの組み合わせも可能である。例えば、単一の音声ストリームといくつかの代替のビデオ・ストリームのセッションを、異なるデータ速度で、または異なる損失率のロバスト性にて標準的コーディング方式により符号化することが考えられ得る。
【０００４】
一般に、インターネット・マルチキャスト・モデルは、マルチキャスト配信ツリーのサブセットに異なったＱｏＳパラメータをもつデータを配信するための基本的メカニズムを提供する。インターネット・グループ管理プロトコル（ＩＧＭＰ−http://www.ietf.orgにて得られる非特許文献５を参照）を使用してマルチキャスト・ルータと通信するホストは、マルチキャスト・グループへの参加／退去により、原則的に、サブツリー内でＱｏＳに動的に適応が可能である。
【０００５】
しかし、例えば、移動通信ネットワークがそうであるように、通信ネットワークのすべてがエンド・ツー・エンド・パラダイムに従うわけではない。この点で、エンド・ツー・エンドの原則の順守は、例えば、パケット欠落や遅延変動といった暗示的なネットワーク・シグナリングだけを頼りにエンド・ホストがネットワーク状況へ適応する責任を負うことである。
【０００６】
一方、移動通信ネットワークは、通常、ＱｏＳ提供のためのネットワーク中心型のアプローチに従うので、異なるブロードキャスト／マルチキャスト ・サービス・モデルが生成される。加入したユーザは、個別ネットワーク・ノードへのＩＧＭＰまたは同等のシグナリングによって、マルチキャスト・セッションへの関与を表出することができる。一方、それに沿ってデータが提供されるデータ配信ツリーは、ネットワークによって自律的に作成され、必要な場合、例えば、ハンドオーバに対応して修正される。このアプローチは、無線ネットワーク・コントローラが使用可能なリソースの知識を得て（例えば、リソース制御機能を備えることにより）、エンド・ユーザが事実上シームレスなサービスの提供を受けられるようにする点で特に有利である。
【０００７】
インターネット上で異種通信サービスを提供するためのネットワーク中心型のアプローチも提案されている。ネットワーク内の拡張された機能を実現するための既知の方法は、非特許文献６、または非特許文献７にそれぞれ提示されたように、トランスポート・レベルまたはアプリケーション・レベルのゲートウェイの確立、またはアクティブ・ネットワーク・ノードの導入である。
【０００８】
前者のアプローチは、トランスコーディング・オペレーションによるかなり多いオーバヘッドを負わせ、後者のアプローチは、ネットワーク特有の機能及びメカニズムを提供するためにそれぞれの場合に適応させる必要があるフレームワークを提供する。
【０００９】
ＭＢＭＳアーキテクチャにおける異種ＱｏＳ向けの最初のコンセプトは、3GPP TR 23.846のオプションＧ: http://www.3gpp.orgにて得られる非特許文献８（ＭＢＭＳのアーキテクチャ及び機能説明の概要については、非特許文献９を参照) として提案された。TR 23.846に示されたアーキテクチャは、それぞれ単一のＲＴＰインスタンスに対応する複数のストリーム（選択的または代替的）を含むことができるＭＢＭＳベアラ・サービスを定義する。各ストリームは、ＭＢＭＳサービスの継続中にわたり維持される、ＧＧＳＮ（ゲートウェイＧＰＲＳサポート・ノード）とＲＮＣ（無線ネットワーク・コントローラ）間の一意的なトンネルを介して転送される。
【００１０】
したがって、原則的に、ＲＮＣはセッション開始時にあるＭＢＭＳサービスのストリームを選択し、かつセッション継続中にストリームを変更／追加することができる。しかし、この機能を可能にするためには、 無線アクセス網（ＲＡＮ）において適切なメカニズムが実装されなければならない。必要な前提条件は、セルまたは下流のノードの現在の状態に応じた適切なストリーム（のセット）をＲＡＮノードが選択できるようにする、ストリーム状態及び関連事項の通信と管理である。
【００１１】
３ＧＰＰのマルチメディア・ブロードキャスト／マルチキャストサービス（ＭＢＭＳ）アーキテクチャは、現在、非常に単純なＱｏＳモデルしかサポートしていない。このアーキテクチャは、ＭＢＭＳ配信ツリーの全分岐が同一ＱｏＳをもつように確立されるか、またはサービス全体が取り消されるかのどちらである、拡張性がなくかつ適応性がないサービスを基本的に提供する。ネットワーク・ノード間でＱｏＳ値のネゴシエーションはない。これは、分岐の一部はそれに対応するネットワーク・ノードによってＱｏＳ要件が満たせなければ、確立できないことを意味する。これは、セッションの開始時や、またはセッション中の、例えば、各ハンドオーバ時、すなわち配信ツリーの新たな分岐の創出／取外しを行わなければならないときに該当する。
【００１２】
一方、移動端末は、各端末に提供された機能、すなわち処理能力、表示サイズ等に関してかなり異種多様的である。現行のＭＢＭＳアーキテクチャは、この異種多様性に対応できないか、もしくはすべての端末（優れた性能のものも、劣った性能のものも）を、すべてが最低の品質に適応する、最悪のケースのシナリオに当てはめることで対応できる。
【００１３】
ＭＢＭＳアーキテクチャは、一方、課金及びサービス提供の面から見て最適でない。例えば、複数の代替的ストリーム（例えば、異なるビットレートの三つの異なる音声ストリーム）または補完的ストリーム（例えば、異なるビットレートの三つのビデオ・ストリームと異なるビットレートの二つの音声ストリーム）からなる単一のユーザ・サービスが３ＧＰＰ ＭＢＭＳアーキテクチャを使用して提供される場合、各代替的ストリームは、各サービスが代替的ストリームの一つを有する三つの別々のＭＢＭＳサービスとして提供される必要がある。
【００１４】
同様に、補完的ストリームの提供を考えると、ストリームの六つの異なる組み合わせが可能である。この場合も、ＭＢＭＳアーキテクチャは、ストリームの各可能な組み合わせが別個のＭＢＭＳユーザ・サービスとしてユーザに提供されることを要求する。また、階層化ストリームが転送される場合、階層の組み合わせごとの各ＭＢＭＳユーザ・サービスで同ストリームが提供される。すなわち、例えば、サービス・メディアが３層（ベース、エンハンスメント１、エンハンスメント２）で提供されるとき、三つの異なるＭＢＭＳサービス（ベース、ベース＆エンハンスメント１、ベース＆エンハンスメント１＆エンハンスメント２）が確立されなければならない。
【００１５】
上記のように、ＭＢＭＳには十分なＱｏＳモデルがないこと並びにＭＢＭＳアーキテクチャから予測される結果によれば、サービスの配信ツリーの個々の分岐ではＱｏＳ差別化を行えない。さらに、実際には「単一の」サービスの代替的または補完的ストリームを提供するために要求されるいくつもの並列のＭＢＭＳサービスの必要性は、ネットワーク内のシグナリング・オーバヘッドの増加につながり、ＵＭＴＳネットワークにおけるリソースを無駄に消費する。
【００１６】
図４を参照して、従来のＭＢＭＳアーキテクチャを使用した従来のＭＢＭＳサービスの確立を以下に説明することにする。ＵＥは、サービス検出または告知手順４０１でＭＢＭＳユーザ・サービス記述を受信する（４０２）。このＭＢＭＳユーザ・サービス記述は、当該ＭＢＭＳユーザ・サービスに含まれるすべてのＭＢＭＳベアラを記述する。個々のベアラは、ＢＭ−ＳＣ（ブロードキャスト／マルチキャスト・サービス・センター）において動的に割り当てられる、各々のＴＭＧＩ（テンポラリー・モバイル・グループ識別子）によって識別される。
【００１７】
ＭＢＭＳユーザ・サービス記述の典型的な例を以下に示す。
<?xml version="1.0" encoding="UTF-8"?>
<userServiceDescription
xmlns="www.example.com/3gppUserServiceDescription"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
serviceId="urn:3gpp:1234567890coolcat">
<deliveryMethod sessionDescriptionURI=
"http://www.example.com/3gpp/mbms/session1.sdp"/>
<deliveryMethod sessionDescriptionURI=
"http://www.example.com/3gpp/mbms/session2.sdp"/>
</userServiceDescription>
この例によれば、ＭＢＭＳユーザ・サービス記述は、ユーザにより要求されたＭＢＭＳサービスに属するベアラをどちらも定義する二つのセッション記述であるsession1.sdp とsession2.sdpを示す。
【００１８】
次に、ＵＥは、ＭＢＭＳユーザ・サービス記述に含まれたすべてのＭＢＭＳベアラを起動する（４０３）。ベアラの起動は、各ＵＥがサービスを要求することを示すためにＭＢＭＳサービスの配信ツリー中で論理状態を設定することであると理解すべきことに留意すべきである。ベアラの起動は、ネットワーク中のリソースの確保を意味するものではない。
【００１９】
ＢＭ−ＳＣはユーザ・サービスを開始する準備が整うとすぐに、ユーザ・サービスの各ベアラに対するＭＢＭＳセッション開始要求をネットワークに送信する(４０４)。セッション開始手続に応答して、ＲＮＣｓは、データ送信がもうすぐ始まることをＵＥｓに知らせるために、ＭＢＭＳ通知を無線で送信する（４０５）。ベアラの受信のために必要な無線ベアラ情報は、この通知の中に含まれる。ＴＭＧＩが、各ＭＢＭＳベアラを識別するために使用される。通知を送信すると、ＲＮＣはサービス提供に必要な無線リソースを割り当てる。通知で受信した情報に基づいて、ＵＥｓはＢＭ−ＳＣからＣＮ／ＲＡＮを介して提供される（４０６、４０７）データを受信するためにチューニング・インできる。
【００２０】
３ＧＰＰ ＭＢＭＳアーキテクチャでは、ＵＥｓは（サービスの一つ以上の個々のストリームを運ぶ）すべてのベアラを起動し、各ベアラに対する通知が受信され、ＭＢＭＳユーザ・サービスに属する各ベアラ上でデータが提供されることを予期する。拡張ＭＢＭＳアーキテクチャにおいては単一のＭＢＭＳサービスが、単一ユーザ・サービス内で階層化した、代替的または補完的ストリームを転送する複数のベアラの提供を可能にすると想定すると、ＭＢＭＳユーザ・サービス記述にリストされたベアラのすべてを同時にＵＥｓに提供する必要はないことは明らかである。
【００２１】
しかし、もしＵＥｓが３ＧＰＰ ＭＢＭＳユーザ・サービス記述にリストされたベアラを全ては受信していないとすれば、ＵＥｓはこれをサービス配信上のエラーとみなし、しかるべき対処をすることになる。
【先行技術文献】
【非特許文献】
【００２２】
【非特許文献１】DiffServ（Differentiated Services− Blake et. Al., "An Architecture for Differentiated Services"、RFC 2475、1998を参照）
【非特許文献２】RSVP （Braden et. Al., "Resource ReSerVation Protocol (RSVP) - Version 1 Message Processing Rules"、RFC 2209、1997を参照）
【非特許文献３】NSIS（Hancock、"Next Steps in Signaling: Framework"、Internet Draft (draft-ietf-nsis-fw-05.txt)、2003を参照）
【非特許文献４】McCanne et al. "Receiver-driven Layered Multicast",Proceedings of ACM SIGCOMM '96,p. 117〜130,1996
【非特許文献５】Fenner,"Internet Group Management Protocol, Version 2",RFC 2236
【非特許文献６】Amir et al. "An application level video gateway", Proceeding of ACM Multimedia ’95、SanFrancisco、CA, USA、November 1995
【非特許文献７】Metzler et al. "AMnet: Heterogeneous Multicast Services based on Active Networking",Proceedings of the 2nd Workshop on Open Architectures and Network Programming (OPENARCH99), New York、NY、USA、March 1999
【非特許文献８】Option G in the 3GPP TR 23.846: "Multimedia Broadcast/Multicast (MBMS); Architecture and functional description (Release 6)", V6.1.0, December 2002
【非特許文献９】3GPP TS 23.246: "Multimedia Broadcast/Multicast (MBMS); Architecture and functional description (Release 6)"、V6.2.0、March 2004
【発明の概要】
【００２３】
したがって、本発明の目的は前述した問題点を克服することである。
【００２４】
この目的は独立請求項の主題によって解決される。有利な実施形態は従属請求項の主題である。
【００２５】
本発明の一つの重要な態様は、サービス受信がうまく行くことを手助けするために、個々の（階層化／代替的／補完的）ベアラの関係に関する情報をマルチキャストサービスまたはブロードキャストサービスを受信する各移動端末に提供することである。ベアラの関係は、マルチキャストサービスまたは ブロードキャストサービスのためのサービス記述情報の中で提供可能であり、そのサービス記述情報はマルチキャストサービスまたはブロードキャストサービスに関連付けられた各ベアラと複数のベアラ間で予め決められたベアラの組み合わせを示す。
【００２６】
予め決められたベアラの各組み合わせは、前記複数のベアラの少なくとも一つを含んでなり、予め決められたベアラの各組み合わせは、サービス・パラメータの予め決められた品質でマルチキャストサービスまたはブロードキャストサービスを提供する。サービス記述情報に基づいて、移動端末は、ネットワークから受信した少なくとも一つの通知中に示された少なくとも一つのベアラが予め決められたベアラの組み合わせの一つに対応するか否かを判断でき、この判断結果により適切に動作できる。
【００２７】
さらに、マルチキャストサービスまたはブロードキャストサービスの各ベアラは、サービスの 一つのパケット・ストリーム（例えば、音声またはビデオ）を含んでなる。しかし、二つ以上のパケット・ストリーム（例えば、音声またはビデオ）が単一のベアラ・サービスを使用して提供されることも可能である。
【００２８】
上記の考察によれば、本発明のある実施形態は、移動通信システムの無線アクセス網を介してマルチキャストサービスまたはブロードキャストサービスを移動端末のユーザに提供するための方法に関係する。この実施形態では、マルチキャストサービスまたはブロードキャストサービスは、マルチキャストサービスまたはブロードキャストサービスを提供するための複数のベアラに関連付けられる。
【００２９】
移動端末は、マルチキャストサービスまたはブロードキャストサービスについてのサービス記述情報を受信することができ、当該サービス記述情報はマルチキャストサービスまたはブロードキャストサービスに関連付けられた複数のベアラを示す。さらに、当該サービス記述情報は複数のベアラ間で予め決められたベアラの組み合わせを示し、予め決められたベアラの各組み合わせは、当該複数のベアラの少なくとも一つを含んでなり、予め決められたベアラの各組み合わせは、サービス・パラメータの予め決められた品質でマルチキャストサービスまたはブロードキャストサービスを提供する。
【００３０】
次に、移動端末は、マルチキャストサービスまたはブロードキャストサービスに関連付けられた複数のベアラを起動することができる。ベアラの起動は、起動した各ベアラへの移動端末の関与を示すだけであること、すなわち、マルチキャストサービスまたはブロードキャストサービスへの移動端末の関与を示すだけであることに留意すべきである。複数のベアラの起動に応答して、移動端末は、無線アクセス網の無線インタフェースを介してマルチキャストサービスまたはブロードキャストされる複数のベアラのうち少なくとも一つのベアラを示すサービス通知情報を受信できる。
【００３１】
端末ですでに受信されたサービス記述情報に基づいて、移動端末は、受信したサービス通知情報に示された当該少なくとも一つのベアラが、予め決められたベアラの組み合わせの一つに対応するか否かを判断できる。これがそうある場合、移動端末は、サービス通知情報に示された当該少なくとも一つのベアラを介して、マルチキャストサービスまたはブロードキャストサービスのコンテンツ・データを受信でき、そのコンテンツ・データを移動端末のユーザに提供する。
【００３２】
本発明の例示的な実施形態では、マルチキャストサービスまたはブロードキャストサービスは、ＵＭＴＳネットワークを介して提供されるＭＢＭＳユーザ・サービスである。
【００３３】
マルチキャストサービスまたはブロードキャストサービスを提供する「許容された」ベアラの組み合わせを認識しているので、移動端末は、「許容された」ベアラの組み合わせを示していない通知情報を理由にエラーが検出される事態も検出できる。これに関して、受信したサービス通知情報に示された少なくとも一つのベアラが、予め決められたベアラ組み合わせの一つに対応しない場合、移動端末は、移動端末のユーザにエラー・メッセージを提供できる。
【００３４】
あるいは、受信したサービス通知情報に示された少なくとも一つのベアラが、予め決められたベアラ組み合わせの一つに対応しない場合、移動端末は、マルチキャストサービスまたはブロードキャストサービスのコンテンツ・データを移動端末のユーザに提供する前にさらなるサービス通知情報の受信を待ってもよく、さらなるサービス通知情報が予め決められた時間期間内に受信されない場合、エラー・メッセージを移動端末のユーザに提供するようにしてもよい。
【００３５】
このように、 移動端末は、サービス・レベルの提供された品質に対しては不十分な数のベアラがネットワークから提供されるケースを処理するルーチンを実装してもよい。
【００３６】
本発明のさらに別の実施形態では、サービス通知情報は、少なくとも一つのベアラを受信端末により受信するために必要なパラメータをさらに示す。したがって、マルチキャストサービスまたはブロードキャストサービスのコンテンツ・データが提供される各ベアラの識別に加えて、端末は、指示されたベアラのそれぞれ一つへ端末がチューニングできるようにするパラメータをさらに通知され得る。
【００３７】
本発明の別の実施形態は、サービス記述情報のコンテンツを、例えば、ＸＭＬ等のマークアップ言語で記述することを見込む。この実施形態の変形では、サービス記述情報は、予め決められたベアラの組み合わせを定義するタグを含んでなる。別の変形では、サービス記述情報は、予め決められたベアラの組み合わせ間の関係を示すタグを（さらに）含むことができる。
【００３８】
さらに、サービス記述情報は、予め決められたベアラの組み合わせの各々についての優先順位をさらに定義してもよい。組み合わせの優先順位の定義は、代替的なベアラ組み合わせについてのサービスの品質要件に関する所望のベアラ組み合わせの順位を示してもよい。階層化ベアラ組み合わせの場合には、優先順位は層の順位を示してもよい。これは、移動端末がユーザ・サービス・セマンティクスを十分に把握できるようにする。
【００３９】
さらに別の実施形態では、サービス通知情報は少なくとも一つの通知メッセージで提供されることが見込まれる。サービス通知情報を無線アクセス網内で効率的に配布するには、通知情報はブロードキャスト無線チャネルを介して提供されることがさらに見込まれてもよい。
【００４０】
本発明の別の実施形態は、無線アクセス網の無線インタフェース上の無線リソースを制御する、無線アクセス網のネットワーク・エンティティの動作に関係する。ＵＭＴＳネットワークでは、このネットワーク・エンティティは、一般に、ＲＮＣ（無線ネットワーク・コントローラ）と呼ばれる。しかし、当該ネットワーク要素は、無線リソースを制御する、無線アクセス網のその他のネットワーク要素であってもよいことに留意すべきである。例えば、拡張ＲＡＮアーキテクチャでは、このネットワーク・エンティティは、無線リソース制御（ＲＲＣ）の役目を担うノードＢに相当し得る。
【００４１】
当該実施形態は、移動通信システムの無線アクセス網を介してマルチキャストサービスまたはブロードキャストサービスを移動端末に提供するための方法に関係する。この場合もまた、マルチキャストサービスまたはブロードキャストサービスは、マルチキャストサービスまたはブロードキャストサービスを提供するための複数のベアラに関連付けられる。当該ネットワーク・エンティティは、移動通信網のコア・ネットワークのネットワーク・エンティティからマルチキャストサービスまたはブロードキャストサービスのサービス・コンテクスト情報を先ず受信することができる。このサービス・コンテクスト情報は、マルチキャストサービスまたはブロードキャストサービスに関連付けられた複数のベアラを示す。さらに、サービス・コンテクスト情報は、複数のベアラ間で予め決められたベアラの組み合わせを示し、予め決められたベアラの各組み合わせは、当該複数のベアラの少なくとも一つを含んでなり、サービス・パラメータの予め決められた品質でマルチキャストサービスまたはブロードキャストサービスを提供する。
【００４２】
序部で概説したように、ネットワーク・エンティティは、サービスの品質管理機能を含んでもよく、（とりわけ）そこから、移動端末のサービス要求が受信されたネットワーク・エンティティのインタフェースを介した下り送信に利用可能なサービスの品質を示すサービスの品質制限を得ることができる。
【００４３】
予め決められたベアラの組み合わせの各々についてのサービス・パラメータの予め決められた品質の知識を得て（サービス・コンテクスト情報によって提供された）、ネットワーク・エンティティは、今、サービスの品質管理機能から得たサービスの品質制限内で提供可能な予め決められたベアラの組み合わせからあるベアラ組み合わせを選択することができる。
【００４４】
次に、ネットワークは、選択した複数ベアラ上でのマルチキャストサービスまたはブロードキャストサービスの送信を告知することができる。したがって、ネットワーク・エンティティは、選択したベアラ組み合わせを示す、例えば、サービス通知情報を移動端末へ送信できる。さらに、ネットワーク・エンティティは、選択したベアラ組み合わせのうちの少なくとも一つのベアラを介して、移動端末へのマルチキャストサービスまたはブロードキャストサービスのコンテンツ・データ送信を続けることができる。
【００４５】
本発明のさらに別の実施形態では、ネットワーク・エンティティは、選択したベアラ組み合わせのうちのベアラを介してコンテンツ・データを送信するための無線リソースをさらに割り当てることができる。
【００４６】
上記の実施形態の変形では、ネットワーク・エンティティがマルチキャストサービスまたはブロードキャストサービスの開始に関する指示を、例えば、セッション開始メッセージで受け取った後、通知情報の送信と共にリソース確保が行われてもよい。
【００４７】
本発明の別の実施形態では、ネットワーク・エンティティは、マルチキャストサービスまたはブロードキャストサービスについてのサービス記述情報を移動端末へさらに中継することができ、当該サービス記述情報は、マルチキャストサービスまたはブロードキャストサービスに関連付けられた複数のベアラを示す。このサービス記述情報は、複数のベアラ間で予め決められたベアラの組み合わせをさらに示してもよい。予め決められたベアラの各組み合わせは、当該複数のベアラの少なくとも一つを含むことができ、予め決められたベアラの各組み合わせは、サービス・パラメータの予め決められた品質でマルチキャストサービスまたはブロードキャストサービスを提供することができる。
【００４８】
さらに、本発明のある実施形態は、ネットワーク・エンティティが、ネットワーク・エンティティのサービスの品質管理機能を利用して、移動端末のサービス要求を受信したネットワーク・エンティティのインタフェースでの下り送信に利用可能なサービスの品質を示すサービスの品質制限をモニタし、モニタされたサービスの品質制限が選択したベアラ組み合わせの移動端末への提供をまだ許すか否か判断することを見込む。
【００４９】
これがそうでない場合、ネットワーク・エンティティは、サービス・コンテクスト情報に含まれた予め決められたベアラ組み合わせの各々についてのサービス・パラメータの予め決められた品質に基づいて、サービスの品質管理機能から得たサービスの品質制限内で提供可能な予め決められたベアラの組み合わせからほかのベアラの組み合わせを選択できる。ネットワーク・エンティティは、選択したほかのベアラ組み合わせを示すサービス通知情報を移動端末へ送信でき、さらに、選択したほかのベアラ組み合わせのうちの少なくとも一つのベアラを介して、移動端末へマルチキャストサービスまたはブロードキャストサービスのコンテンツ・データを送信できる。
【００５０】
この実施形態のある変形では、ネットワーク・エンティティはまた、選択したほかのベアラ組み合わせのうちの各ベアラを介してコンテンツ・データを送信するための無線リソースを割り当てることができ、マルチキャストサービスまたはブロードキャストサービスのコンテンツ・データの送信に先に割り当てた無線リソースを解放することができる。
【００５１】
本発明のさらに別の実施形態では、サービス記述情報は、移動端末に別々に提供される複数のベアラの各ベアラについてのユーザ・サービス記述及びサービス記述に含まれる。
【００５２】
ある変形では、ユーザ・サービス記述は、複数のベアラに関連付けられたサービス記述の各々のＵＲＩを示し、ＵＲＩｓに基づいて予め決められたベアラの組み合わせを定義し、複数のベアラの各一つに対する各サービス記述はその各ベアラのテンポラリー識別子を含んでなる。さらに、別の変形では、サービス通知情報は選択したベアラ組み合わせに含まれた各ベアラのテンポラリー識別子を含んでなる。
【００５３】
本発明の別の実施形態は、マルチキャストサービスまたはブロードキャストサービスをユーザに提供するための移動端末に関係する。マルチキャストサービスまたはブロードキャストサービスは、移動通信システムの無線アクセス網を介して送信され、マルチキャストサービスまたはブロードキャストサービスを提供するための複数のベアラに関連付けられる。
【００５４】
この実施形態によれば、移動端末は、マルチキャストサービスまたはブロードキャストサービスについてのサービス記述情報を受信するための受信器を含む構成とすることができる。サービス記述情報は、マルチキャストサービスまたはブロードキャストサービスに関連付けられた複数のベアラを示す。さらに、サービス記述情報は、複数のベアラ間で予め決められたベアラの組み合わせを示す。予め決められたベアラの各組み合わせは、当該複数のベアラの少なくとも一つを含むことができる。さらに、予め決められたベアラの各組み合わせは、サービス・パラメータの予め決められた品質でマルチキャストサービスまたはブロードキャストサービスを提供できる。
【００５５】
移動端末の受信器は、複数のベアラの起動に応答してサービス通知情報を受信するようにさらに適合され得る。サービス通知情報は、無線アクセス網の無線インタフェースを介してマルチキャストサービスまたはブロードキャストされる複数のベアラのうちの少なくとも一つを示す。
【００５６】
さらに、移動端末は、マルチキャストサービスまたはブロードキャストサービスに関連付けられた複数のベアラを起動するための送信器と、受信したサービス通知情報中に示された少なくとも一つのベアラが予め決められたベアラの組み合わせの一つに対応するか否かを判断するための処理手段を含む構成とすることができる。
【００５７】
移動端末の受信器は、受信したサービス通知情報中に示された少なくとも一つのベアラが予め決められたベアラの組み合わせの一つに対応すると処理手段が判断した場合、サービス通知情報中に示された少なくとも一つのベアラを介してマルチキャストサービスまたはブロードキャストサービスのコンテンツ・データを受信するように適合され得る。
【００５８】
さらに、構成された移動端末は、移動端末のユーザにコンテンツ・データを提供するように適合される。
【００５９】
さらに別の実施形態では、移動端末は、当該方法の上記の様々な実施形態及び変形の一つによる、移動端末のユーザにマルチキャストサービスまたはブロードキャストサービスを提供するための方法の各ステップを実行するように適合された手段をさらに含む構成とする。
【００６０】
本発明の別の実施形態は、移動通信システムの無線アクセス網を介して移動端末にマルチキャストサービスまたはブロードキャストサービスを提供するためのネットワーク・エンティティに関係する。上記の実施形態と同様、マルチキャストサービスまたはブロードキャストサービスは、マルチキャストサービスまたはブロードキャストサービスを提供するための複数のベアラに関連付けられる。ネットワーク・エンティティは、無線アクセス網内に置かれ、無線アクセス網の無線インタフェース上の無線リソースを制御するように適合され得る。
【００６１】
ネットワーク・エンティティは、移動通信網のコア・ネットワークのネットワーク・エンティティからマルチキャストサービスまたはブロードキャストサービスのサービス・コンテクスト情報を受信するための受信器を含む構成とすることができる。このサービス・コンテクスト情報は、マルチキャストサービスまたはブロードキャストサービスに関連付けられた複数ベアラと複数のベアラ間で予め決められたベアラの組み合わせを示す。予め決められたベアラの各組み合わせは、当該複数のベアラの少なくとも一つを含んでなり、サービス・パラメータの予め決められた品質でマルチキャストサービスまたはブロードキャストサービスを提供することができる。
【００６２】
さらに、ネットワーク・エンティティは、ネットワーク・エンティティのサービスの品質管理機能から、移動端末のサービス要求が受信されたネットワーク・エンティティのインタフェースを介した下り送信に利用可能なサービスの品質を示すサービスの品質制限を得るための処理手段を含む構成とすることができる。処理手段は、サービス・コンテクスト情報に含まれた予め決められたベアラ組み合わせの各々についてのサービス・パラメータの予め決められた品質に基づいて、サービスの品質管理機能から得たサービスの品質制限内で提供可能な予め決められたベアラの組み合わせからベアラ組み合わせを選択するように適合され得る。
【００６３】
さらに、ネットワーク・エンティティは、選択したベアラ組み合わせを示すサービス通知情報を移動端末へ送信するための、さらに選択したベアラ組み合わせのうちの少なくとも一つのベアラを介して移動端末へマルチキャストサービスまたはブロードキャストサービスのコンテンツ・データを送信するための送信器を含む。
【００６４】
さらに別の実施形態では、ネットワーク・エンティティは、当該方法の上記の様々な実施形態及び変形の一つによる、移動端末にマルチキャストサービスまたはブロードキャストサービスを提供するための方法の各ステップを実行するように適合された手段をさらに含む構成とする。
【００６５】
本発明の別の実施形態は、移動端末のプロセッサにより実行時、移動通信システムの無線アクセス網を介して移動端末のユーザにマルチキャストサービスまたはブロードキャストサービスを提供することを実施させる命令を記憶するコンピュータにより読出し可能な媒体に関係する。マルチキャストサービスまたはブロードキャストサービスは、マルチキャストサービスまたはブロードキャストサービスを提供するための複数のベアラに関連付けることができる。
【００６６】
移動端末は、マルチキャストサービスまたはブロードキャストサービスについてのサービス記述情報を受信することにより、マルチキャストサービスまたはブロードキャストサービスを受信するように動作し得る、ここでサービス記述情報はマルチキャストサービスまたはブロードキャストサービスに関連付けられた複数のベアラを示し、ここでサービス記述情報は複数のベアラ間で予め決められたベアラの組み合わせをさらに示し、予め決められたベアラの各組み合わせは当該複数のベアラの少なくとも一つを含んでなり、予め決められたベアラの各組み合わせはサービス・パラメータの予め決められた品質でマルチキャストサービスまたはブロードキャストサービスを提供する。
【００６７】
命令はさらに、マルチキャストサービスまたはブロードキャストサービスに関連付けられた複数のベアラを起動し、複数のベアラの起動に応答してサービス通知情報を受信し、受信したサービス通知情報中に示された少なくとも一つのベアラが予め決められたベアラの組み合わせの一つに対応するか否かを判断することにより、マルチキャストサービスまたはブロードキャストサービスを受信するように移動端末を動作させることができる。ここでサービス通知情報は、 無線アクセス網の無線インタフェースを介してマルチキャストサービスまたはブロードキャストされる複数のベアラの少なくとも一つを示す。対応すると判断された場合、命令は、サービス通知情報の中に示された少なくとも一つのベアラを介して、マルチキャストサービスまたはブロードキャストサービスのコンテンツ・データを受信し、移動端末のユーザに対してコンテンツ・データを提供するように移動端末を動作させることができる。
【００６８】
さらに別の実施形態では、コンピュータにより読出し可能な媒体は、移動端末のプロセッサにより実行する時、当該方法の上記の様々な実施形態及び変形の一つによる、移動端末のユーザにマルチキャストサービスまたはブロードキャストサービスを提供するための方法の各ステップを移動端末に実行させる命令を記憶する。
【００６９】
本発明の別の実施形態は、ネットワーク・エンティティのプロセッサにより実行する時、移動通信システムの無線アクセス網を介して移動端末にマルチキャストサービスまたはブロードキャストサービスを提供するようにネットワーク・エンティティを動作させる命令を記憶するコンピュータにより読出し可能な媒体に提供する。マルチキャストサービスまたはブロードキャストサービスは、マルチキャストサービスまたはブロードキャストサービスを提供するための複数のベアラに関連付けることができる。さらに、ネットワーク・エンティティは無線アクセス網内に置くことができ、 無線アクセス網の無線インタフェース上の無線リソースを制御する。命令は、プロセッサにより実行する時、移動通信網のコア・ネットワークのネットワーク・エンティティからマルチキャストサービスまたはブロードキャストサービスのサービス・コンテクスト情報を受信するようにネットワーク・エンティティを動作させることができる。ここでサービス・コンテクスト情報はマルチキャストサービスまたはブロードキャストサービスに関連付けられた複数ベアラを示し、サービス・コンテクスト情報は複数のベアラ間で予め決められたベアラの組み合わせをさらに示す。予め決められたベアラの各組み合わせは当該複数のベアラの少なくとも一つを含んでなることができ、予め決められたベアラの各組み合わせはサービス・パラメータの予め決められた品質でマルチキャストサービスまたはブロードキャストサービスを提供できる。
【００７０】
さらに、命令は、ネットワーク・エンティティのサービスの品質管理機能から、移動端末のサービス要求が受信されたネットワーク・エンティティのインタフェースを介した下り送信に利用可能なサービスの品質を示すサービスの品質制限を得て、サービス・コンテクスト情報に含まれた予め決められたベアラ組み合わせの各々についてのサービス・パラメータの予め決められた品質に基づいて、サービスの品質管理機能から得たサービスの品質制限内で提供可能な予め決められたベアラの組み合わせからベアラ組み合わせを選択するようにネットワーク・エンティティを動作させることができる。
【００７１】
さらに、命令は、選択したベアラ組み合わせを示すサービス通知情報を移動端末へ送信し、選択したベアラ組み合わせのうちの少なくとも一つのベアラを介して、マルチキャストサービスまたはブロードキャストサービスのコンテンツ・データを移動端末へ送信するようにネットワーク・エンティティを動作させることができる。
【００７２】
さらに別の実施形態では、コンピュータにより読出し可能な媒体は、ネットワーク・エンティティのプロセッサにより実行する時、当該方法の上記の様々な実施形態及び変形の一つによる、移動端末にマルチキャストサービスまたはブロードキャストサービスを提供するための方法の各ステップをネットワーク・エンティティに実行させる命令を記憶する。
【図面の簡単な説明】
【００７３】
【図１】３ＧＰＰ ＭＢＭＳアーキテクチャのユーザ・プレーンのプロトコル・スタックをそれぞれ示す。
【図２】ＵＭＴＳのＱｏＳアーキテクチャの概要を示す。
【図３】制御プレーンにおけるＵＭＴＳベアラ・サービスのＱｏＳ管理機能を示す。
【図４】従来の３ＧＰＰ ＭＢＭＳユーザ・サービスの動作を示す。
【図５】本発明の実施形態によるＭＢＭＳユーザ・サービスの動作を示す。
【発明を実施するための形態】
【００７４】
添付の図と図面を参照して、以下に本発明をさらに詳細に説明する。各図中の同等または対応する細部の要素は、同一参照番号を付けて示される。
【００７５】
以下のパラグラフでは、本発明の多様な実施形態を説明することにする。典型的な例を示すという目的でのみ、実施形態の大部分は、ＵＭＴＳ通信システムに関連して概説される。また、以下の節で使用される専門用語は、主にＵＭＴＳの用語に関係する。しかし、使用された用語とＵＭＴＳアーキテクチャに関連した実施形態の説明は、本発明の原理と概念を上記システムに限定するという意味合いはない。
【００７６】
また、前述の背景技術の節で述べた詳細な説明は、以下に説明する主にＵＭＴＳ向きの典型的な実施例をよりよく理解してもらうためのものにすぎず、移動通信網におけるプロセス及び機能のここで述べた特定の実装に本発明を限定するものと理解すべきではない。
【００７７】
本発明は、帯域幅要件とＱｏＳ適応に関して主に説明されることにさらに留意する。しかし、ＱｏＳ差別化及び適応は、例えば、損失率等のその他のＱｏＳパラメータまたはパラメータの組み合わせに適用されてもよい。
【００７８】
サービスの階層化した、補完的または代替的ストリームを転送する複数のベアラによるユーザ・サービスの提供を可能にするために、ＭＢＭＳトランスポート・サービス及びＭＢＭＳユーザ・サービスは拡張される。拡張されたマルチキャストサービス／ブロードキャストサービス・アーキテクチャの設計についての重要な態様は、コンテンツ適応の広範囲な可能性を網羅することである。例えば、利用可能な適応的メディア・コーデックがカバーされ得るし、将来の拡張のためのフレームワークも提供可能である。
【００７９】
現行のＭＢＭＳアーキテクチャの限界を克服するための一つの可能なアプローチは、適応的メディア・コーデックの使用であると言える。適応的メディア・コーデックの例は、ＭＰＥＧ２またはＭＰＥＧ４等の階層化コーデックである。これらのコーデックは、通常に、（少なくとも）２または３層でメディア情報を符号化し、この符号化によれば最下位層が最も重要な層である。後続の（より高位の）層は、その前の（より低位の）層に依存する。
【００８０】
コンテンツは、例えば、異なる帯域幅要件または異なるエラー耐性をもつ代替的ストリームの提供を可能にするＭＰＥＧ−１エンコーダを使用するなど、いくつかの独立した表現で符号化可能でもある。
【００８１】
適応的メディア・コーデックの別の例は、マルチプル・ディスクリプション・コーデック（ＭＤＣ）のファミリーである。この形式のコーディングでは、コンテンツはいくつかの補完的な層に符号化される。すなわち、基本層と前層への依存という概念がなくなる。特に、ＭＤＣ符号化されたパケットはより多数受信すれば、より高い品質が得られる。
【００８２】
さらに別の設計の考慮点は、ＲＡＮ（無線アクセス網）リソースの可用性である。一般性を失わずに、ＲＡＮは、通常、少ない無線リソースのためにトランスポート・ベアラの確立がボトルネックになる危機的なシステムとみなせる。したがって、拡張マルチキャスト／ブロードキャストサービス・アーキテクチャは、ＲＮＣｓ（無線ネットワーク・コントローラ）においてＲＡＮリソースの変化に対応する適応機能を考慮する必要がある。
【００８３】
ＵＥｓのモビリティにより、配信ツリーは進行中のセッション中に変化することがあり得る。したがって、拡張マルチキャスト／ブロードキャストサービス・アーキテクチャは、セッション開始時とセッション中、例えば、ハンドオーバ時の両方での適応を可能にし得る。
【００８４】
拡張マルチキャスト／ブロードキャストサービス・アーキテクチャの別の可能な設計態様は、ネットワーク及び無線構成要素の状態の変化への適応を提供することである。ＭＢＭＳのデータは、多くのＲＮＣｓと多くのＳＧＳＮｓを通過する可能性があるＭＢＭＳ配信ツリーを通じて複数のユーザに配信され得る。
【００８５】
したがって、ユーザの視点からは単一のＭＢＭＳサービスを含んでなる異なるメディア構成要素が、各構成要素についてのＱｏＳ差別化を可能にする、別個のＧＴＰ（ＧＰＲＳトンネリング・プロトコル）トンネル（ＧＧＳＮ←→ＳＧＳＮ、ＳＧＳＮ←→ＲＮＣ−図１を参照）と無線ベアラ（ＲＮＣ←→ＵＥ）を通って提供され得る。拡張マルチキャスト／ブロードキャストサービス・アーキテクチャは、したがって、無線アクセスとコア・ネットワークの両方でのＱｏＳの課題に対処することができる。
【００８６】
あるネットワークＱｏＳを実現するために、明確に定義された特性と機能をもつベアラ・サービス（例えば、ＵＭＴＳ／ＭＢＭＳベアラ）をユーザ・サービス（例えば、マルチキャストサービスまたはブロードキャストサービス）の送信元から送信先へ確立することができる。ベアラ・サービスは、契約ＱｏＳの提供を可能にするすべての態様を含む。これらの態様は、とりわけ、制御シグナリング、ユーザ・プレーンのトランスポート及びＱｏＳ 管理機能等である。ＵＭＴＳベアラ・サービス階層化ＱｏＳアーキテクチャを図２に示す。特定の層の各ベアラ・サービスは、それより下位の層で提供されるサービスを使用して、その個別のサービスを提供する。
【００８７】
特定のＱｏＳをもつＵＭＴＳベアラ・サービスを指定し、確立し、修正し、維持するために必要なノード（ＧＧＳＮ、ＳＧＳＮ、ＲＮＣ等）間の機能の特定の関係は、実装により固有であり得る。これは、DiffServ、IntServ（Bradenほか、"Integrated Services in the Internet Architecture: an Overview"、RFC1633、1994を参照）、ＲＳＶＰまたはＭＰＬＳ等のいくつかの技術が使用できることを意味する。
【００８８】
ＵＭＴＳの例を考えると、上記の機能のＵＭＴＳエンティティへの割当ては、これらのエンティティがＵＭＴＳベアラ・サービスに対してネゴシエートされたＱｏＳコミットメントを実施し得ることを意味する。上記の機能の特定の実現は、実装に依存し、特定のＱｏＳ特性を維持しさえすればよい。すべてのＵＭＴＳエンティティのＱｏＳ管理機能は合同して、ＵＭＴＳベアラ・サービスのアクセス・ポイント間でネゴシエートされたサービスの提供を保証できる。
【００８９】
新しい拡張マルチキャスト／ブロードキャストサービス・アーキテクチャの確立については、3GPP TS 23.107: "Technical Specification Group Services and System Aspects; Quality of Service (QoS) concept and architecture (Release 6)" （version 6.1.0, March 2004を参照）の6.2.1.1項に記載されている、サービス・マネージャの機能が特に興味深いと言えよう。サービス・マネージャは、それが担うサービスの確立、修正及び維持のために制御プレーンの機能（例えば、ＭＢＭＳベアラ・コンテクスト）を調整する（図３を参照）。さらに、サービス・マネージャは、すべてのユーザ・プレーンのＱｏＳ管理機能に適切な属性（例えば、保証ビットレート、最大ビットレート、最大パケット・サイズ、損失率等）を与える。
【００９０】
サービス・マネージャはさらに、ほかのインスタンス（例えば、ＭＢＭＳベアラ・コンテクスト管理機能）にサービスを提供し、ピアのサービス・マネージャと信号を交換し、ほかのインスタンスにより提供されたサービスを使用することができる。サービス・マネージャはさらに、下位層のサービスを要求するために、属性変換（例えば、アプリケーション・パケット損失率をＲＬＣ ＳＤＵ損失率に変換、ＳＤＵ損失率をレイヤ１／レイヤ２ブロック誤り率に変換）を行うことができる。さらに、サービス・マネージャは、サービス提供に対する許可を受信するためにほかの制御機能に問い合わせを行うことができる。
【００９１】
したがって、このような基盤インフラストラクチャが提供され、ＭＢＭＳベアラとＱｏＳ管理機能間の相互動作が与えられると仮定できる。これは、ユーザが利用可能なリソースをどのように使用するかは不確実であるために本質的に変動するものであるネットワーク（ＣＮ）とＲＡＮの両方の状態とその他の予測できない事象をＭＢＭＳユーザ・サービス用のコンテクスト管理機能で把握することを可能にする。
【００９２】
例えば、後者の具体的な例は、特定のサーバとその関連ネットワーク・セグメントがユーザ要求により過負荷状態になる典型的なフラッシュ・クラウド（突発的殺到）現象である。別の例としては、サービス配信パス上のノードの障害またはどのくらい多くのユーザが３ＧＰＰ ＭＢＭＳのようなマルチキャストサービスに参加するのかが不確実な場合などがあげられる。
【００９３】
さらに、拡張マルチキャスト／ブロードキャストサービス・アーキテクチャを設計する際の別の態様は、マルチキャスト／ブロードキャストサービスのネットワーク主導の適応を可能にすることである。現在のＭＢＭＳアーキテクチャでは、 ＭＢＭＳユーザがサーバ（例えば、ＢＭ−ＳＣ）とセッション配信の詳細をネゴシエートする機会は、通常、ほとんどまたはまったくない。ここが、ネットワーク主導の適応が重要になるところである。
【００９４】
ＱｏＳアーキテクチャは、ユーザ・サービスのストリーム／ベアラの差別化が、ＭＢＭＳユーザ・サービスの配信ツリーに沿ったネットワーク・ノード（ネットワーク・エンティティ）において可能になるように拡張される。このようにして、変動するリソース、異種多様な端末、異なるネットワーク構成要素に対するネットワーク主導の適応が可能である。
【００９５】
このアプローチによれば、ＭＢＭＳユーザ・サービス・コンテクストの形の追加の状態情報が導入される。ＭＢＭＳユーザ・サービス・コンテクストは、サービスに含まれたベアラへの参照を格納する。さらに、下りＱｏＳ制限等のダウンリンク性能に従って 適応を行うノードがベアラの起動／停止を実行できるように、ベアラ間の関係を定義するベアラ関係情報を格納できる。
【００９６】
典型的な例を示すという目的でのみ以下で考察するＭＢＭＳユーザ・サービスの時系列は、次のとおりである。データ・プレーンにおいて、要求されたマルチメディア・ブロードキャストまたはマルチキャスト・サービスのサービス・コンテンツ・データ（通常は選択的／代替的／補完的ストリームの形の）は、ＱｏＳ要件（制限）が中間に介在するネットワーク・エンティティのいずれかによって満たされる限り、そのＭＢＭＳベアラによって下り方向へ転送される。例えば、中間に介在するノードがユーザ・サービスに属するすべてのベアラを転送できない場合、全セッション・ストリームを利用可能なＱｏＳに適応させるために、ノードは使用可能なベアラ・サービスのサブセットを選択することによってベアラをフィルタにかける。中継されたコンテクスト情報（例えば、ＭＢＭＳベアラ・コンテクスト内の及び新たに定義したＭＢＭＳユーザ・サービス・コンテクスト内の）は、ネットワーク・ノードでこのフィルタがけを行えるようにする。ＭＢＭＳベアラ・コンテクスト及び新たに定義したＭＢＭＳユーザ・サービス・コンテクストを設定するために必要な情報は、要求に応じて、配信ツリーの下流へ伝播することができる。
【００９７】
コンテクスト情報はさらに、ノードがすべてのオプション、すなわち、サービス配信に利用できる可能なベアラの組み合わせを把握できるので、ネットワークが突然の容量変化（上昇／下降）に対応できるようにし得る。中継されたコンテクスト情報は、サービス設定、すなわち、サービス・セマンティクスのオプションを記述し、例えば、ＭＢＭＳユーザ・サービス・コンテクストに格納可能である。サービス・セマンティクスは、例えば、ユーザ・サービスに属する各ベアラとそれらの相互関係（階層化、代替的、補完的）、可能なストリームの組み合わせ−代替的ストリームの場合−等に関する情報を含むことができる。さらに別の設計可能性としては、切り離した、切り離さなかったストリームの状態に関する情報を下流へ転送することがあげられる。
【００９８】
さらに、突然の容量変化への適応を可能にするために、ストリームのＱｏＳプロファイルも考慮に入れてもよいことにさらに留意すべきである。確立された各ベアラについてのＱｏＳプロファイルからなるこの情報は、適応を行うノードに存在するＭＢＭＳベアラ・コンテクストから容易に得ることができる。あるいは、サービス・セマンティクス内のこの情報をシグナリングし、ユーザ・サービス・コンテクストに格納することも考えられる。
【００９９】
一般性を失わずに、無線アクセス網は３ＧＰＰアーキテクチャではボトルネックとみなせ、コア・ネットワークは過剰供給とみなせる。ここで説明する概念は、この仮定の下での適用可能性に限定されないことに留意すべきである。したがって、フィルタを行うエンティティ（すなわち、「適応を行うノード」）の例としてＲＮＣｓがあげられるが、これはＲＮＣｓが自身の無線領域において利用可能なリソースに関する知識を得るからである。このため、ＲＮＣｓはこの機能に十分適合する。
【０１００】
一般に、ＲＡＮまたはＣＮ内のいずれかのネットワーク・エンティティは、フィルタリングを行うエンティティとして動作できる。例えば、要求したサービスを受信する移動端末に向けて下り方向のリンク上のリソースを把握しているエンティティをフィルタリングを行うエンティティとして選択することは実現可能であると言える。
【０１０１】
適応を行うネットワーク・エンティティでのフィルタの初期設定は、制御メッセージを使用してトリガすることができる。したがって、ＭＢＭＳの手順を使用して、サービス・セマンティクスを対応するＲＮＣへ下り方向のシグナリングすることができる。サービス・セマンティクスは、ユーザ・サービスを運ぶ各ストリーム、それらの相互関係、及びそれらのＱｏＳプロファイルに関する情報を示すものと理解してよい。
【０１０２】
例えば、サービス・セマンティクスを反映するこれらの個々の情報は、指定されたＭＢＭＳシグナリング・メッセージのオプショナルなフィールド内に記述される。さらに、ＧＧＳＮｓやＳＧＳＮｓ等の介在するノードは、メッセージの拡張部分の意味について理解しないならば、それを解析し処理する必要はない。そのまま下流へ転送してよい。
【０１０３】
さらに、前述の適応的ＱｏＳの概念は、ある任意のコンテンツを符号化するための、例えば、階層化、代替的または補完的といった異なるパラダイムをサポートするサービスの提供を可能にする。これは、ＭＢＭＳサービスを提供するための新規なアプローチであり、現在のアーキテクチャにはまだ反映されていないものである。現在、必要なＭＢＭＳコンテンツ情報のシグナリング及び管理のための代替物だけは定義されているが、異なる可能性をいかに実現するかは示されていない。サービス・セマンティクスを格納するためのＭＢＭＳユーザ・サービス・コンテクスト（例えば、サービスに属する各ベアラ、それらの相互関係、それらのＱｏＳプロファイル等の情報）の使用は、したがって、現行のＭＢＭＳアーキテクチャに適合する。
【０１０４】
本発明は、ＭＢＭＳユーザ・サービス等のマルチキャストサービスまたは ブロードキャストサービスが、代替的、補完的または階層化であり得る複数のベアラからなることを前提にする。したがって、各ベアラは、各ベアラをＵＥへ配信するために満たされなければならない予め決められたＱｏＳ制限に関連付けられる。さらに、各ベアラに関連付けられたＱｏＳパラメータは、ベアラをＵＥへ配信するために必要なビットレートのみでなく、その内容（例えば、ベアラにより運ばれるストリームの保証ビットレート、最大ビットレート、最大パケット・サイズ、損失率等）も記述する。
【０１０５】
したがって、特定のＱｏＳの関係が、例えば、代替的、補完的または階層化関係が、ＭＢＭＳベアラ間（またはベアラのグループ間）に存在する。ＭＢＭＳユーザ・サービスのＱｏＳは、前述のように、３Ｇネットワークでは自律的に適応される。ＲＡＮまたはＣＮ内のＱｏＳ判断ポイント（「適応を行うノード」）は、適応を行うノードに実装されたサービスの品質管理機能から得たサービスの品質制限に基づいて、ダウンリンクの利用可能なリソースに従ってＭＢＭＳベアラの一部を選択する／切り離す。
【０１０６】
ＵＥｓはＲＡＮ及び／またはＣＮ内でのこの選択／切り離し処理は気づかないので、ＭＢＭＳユーザ・サービス記述に示されたとおり、ＭＢＭＳユーザ・サービスのすべてのベアラを受信するものと想定する。従って、切り離されたベアラは、従来のＵＥではエラー・ケースとみなされた。ＵＥｓは、その結果、利用可能なＱｏＳレベルの一つでサービスを実際に受信することに気づかない。したがって、ＵＥｓはＭＢＭＳユーザ・サービスを正しく受信できない。
【０１０７】
この問題のよりよい理解のために、次の例を示す。ＭＢＭＳユーザ・サービスは、サービス代替物を表す二つのＭＢＭＳベアラを含むものとする。すなわち各ベアラは同一コンテンツを配信するが、異なる品質レベルに符号化されている（例えば、二つの異なるビットレートに符号化された音声視覚ストリーム）。さらに、各ベアラに設定された関連した配信後手順があってもよい（例えば、コンテンツ受信報告）。ＭＢＭＳベアラはサービス代替物に相当するので、一つだけをＵＥへ配信するように決められる。
【０１０８】
ＵＥは、両方のＭＢＭＳベアラの記述を含むＭＢＭＳユーザ・サービス記述を受信する。通常の挙動により、ＵＥは両方のＭＢＭＳベアラを要求する。問題は、ＭＢＭＳベアラが代替物であり、そのうちの一つに対してだけリソースの確保をすればよいことにＵＥが気づかないことである。したがって、ＵＥは両方のベアラに対するリソース（例えば、ストリームーミング・バッファ）を確保することになり、ＵＥ中のリソース（例えば、メモリ空間）を無駄に消費することになる。さらに、ＵＥは両方のベアラに対する配信後手順（それがある場合）を開始する。しかし、ネットワークは、実際にＵＥへ配信されたサービス（ベアラ）に対する配信後手順を受信することにしか関与しない。これは、ネットワーク・リソースの無駄な消費となる。
【０１０９】
本発明の実施形態の重要な態様は、新しいグルーピング記述を標準のＭＢＭＳユーザ・サービス記述の拡張として導入したことである。ＭＢＭＳユーザ・サービス記述は、ＸＭＬに基づく。新しい要素は、ＭＢＭＳユーザ・サービスに含まれた個々のＭＢＭＳベアラ間のグルーピング関係を記述する。
【０１１０】
この拡張記述により、ＵＥｓはＭＢＭＳベアラのグルーピングを把握し、ベアラのすべてのグループが受信されなくてもよいことを知る。したがって、ＵＥｓは、ＭＢＭＳベアラのサブセットのみを受信するように準備される。したがって、あるＭＢＭＳベアラの非受信が直ちにエラー・ケースだとはみなされない。一方、ＵＥｓは完全なグループが受信されるか否かを判断でき、これによりＭＢＭＳユーザ・サービスが正しく受信されたかどうかをＵＥｓは理解できる。
【０１１１】
以下の行は、従来のＭＢＭＳユーザ・サービス記述のＸＭＬスキーマの典型的な例を示す。
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema elementFormDefault="qualified”
targetNamespace="urn:3gpp:metadata:2004:userservicedescription" 
xmlns="urn:3gpp:metadata:2004:userservicedescription" 
xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:element name="userServiceDescription”
type="userServiceDescriptionType"/>
<xs:complexType name="userServiceDescriptionType">
<xs:sequence>
<xs:element name="name" type="nameType"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="serviceLanguage" type="xs:language"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="deliveryMethod”
type="deliveryMethodType"
maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="serviceId" type="xs:anyURI”
use="required"/>
</xs:complexType>
<xs:complexType name="deliveryMethodType">
<xs:attribute name="associatedProcedureDescriptionURI"
type="xs:anyURI" use="optional"/>
<xs:attribute name="protectionDescriptionURI"
type="xs:anyURI" use="optional"/>
<xs:attribute name="sessionDescriptionURI"
type="xs:anyURI" use="required"/>
</xs:complexType>
<xs:complexType name="nameType">
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute name="lang" type="xs:language”
use="optional"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:schema>
userServiceDescription（ユーザ・サービス記述）は、すべてのＭＢＭＳユーザ・サービス記述情報を有する最上位要素である。最も重要なdeliveryMethod（配信方法）要素は、ＭＢＭＳユーザ・サービスの特定のＭＢＭＳベアラに関するすべての情報を集める。ＭＢＭＳベアラの詳細を記述するすべての情報は、ほかの専用のメタデータ記述（メディア及びセッション記述とも言う）に含まれる。これらは deliveryMethod（配信方法）要素内のそれぞれの一意なＵＲＩによって参照される。さらに、deliveryMethod（配信方法）要素に（それぞれのＵＲＩｓ／メディアまたはセッション記述によって）リストされたＭＢＭＳベアラの各々は、各ベアラに関連付けられたＴＭＧＩ（テンポラリー・マルチキャスト・グループ識別子）をもつ。トランスポート及びメディア符号化パラメータに関しては、これらの情報は、deliveryMethod（配信方法）要素のsessionDescriptionURI（セッション記述ＵＲＩ）属性に指定される、個別のＳＤＰ記述に含まれる。
【０１１２】
以下の行は、上記のＸＭＬ仕様のdeliveryMethod（配信方法）要素内で重要とされる専用メタデータ記述の内容の典型的な例を示す。
v=0
o=user123 2890844526 2890842807 IN IP6
2201:056D::112E:144A:1E24
s=File delivery session example
i=More information
t=2873397496 2873404696
a=mbms-mode:broadcast 1234                
a=FEC-declaration:0 encoding-id=128; instance-id=0
a=source-filter: incl IN IP6 *
2001:210:1:2:240:96FF:FE25:8EC9
a=flute-tsi:3
m=application 12345 FLUTE/UDP 0
c=IN IP6 FF1E:03AD::7F2E:172A:1E24/1
a=lang:EN
a=FEC:0
本発明の一実施形態に関連する行は
a=mbms-mode:broadcast 1234
であり、ここではＭＢＭＳユーザ・サービスがブロードキャスト・モードで提供され、ＴＭＧＩ、1234をもつベアラにより提供されることが規定される。ＭＢＭＳユーザ・サービス記述により参照されたサービス記述中のこのＴＭＧＩに基づいて、ＵＥは、ＭＢＭＳユーザ・サービス記述中の各ＵＲＩを、参照されたサービス記述中に記述された、コンテンツ・データを提供するベアラのＴＭＧＩに関連付けることができる。したがって、ＵＥで受信されるＭＢＭＳ通知の対象となるベアラのＴＭＧＩｓは、以下に述べるように、それぞれのＴＭＧＩｓで識別されたベアラが「有効な」ベアラ組み合わせをなすか否かをＵＥが判断できるようにする。マルチキャスト・モードでのＭＢＭＳサービスの場合、参照されたサービス記述が各ベアラのＭＴＧＩｓを示さないこともあることに留意すべきである。
【０１１３】
以下の行は、本発明の例示的な実施形態によるＭＢＭＳベアラのグルーピングのサポートを可能にする、標準ＭＢＭＳユーザ・サービス記述のＸＭＬスキーマの拡張を示す（太字の行は適用された拡張を示す）。
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema elementFormDefault="qualified" 
targetNamespace="urn:3gpp:metadata:2004:userservicedescription" 
xmlns="urn:3gpp:metadata:2004:userservicedescription" 
xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:element name="userServiceDescription" 
type="userServiceDescriptionType"/>
<xs:complexType name="userServiceDescriptionType">
<xs:sequence>
<xs:element name="name" type="nameType"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="serviceLanguage" type="xs:language"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="deliveryMethod" 
type="deliveryMethodType"
maxOccurs="unbounded"/>
<xs:element name="qosGroup" type=" qosGroupType"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="serviceId" type="xs:anyURI" 
use="required"/>
</xs:complexType>
<xs:complexType name="deliveryMethodType">
<xs:attribute name="associatedProcedureDescriptionURI"
type="xs:anyURI" use="optional"/>
<xs:attribute name="protectionDescriptionURI"
type="xs:anyURI" use="optional"/>
<xs:attribute name="sessionDescriptionURI"
type="xs:anyURI" use="required"/>
</xs:complexType>
<xs:complexType name="nameType">
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute name="lang" type="xs:language" 
use="optional"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:complexType name="qosGroupType">
<xs:sequence> <!-- re-uses sessionDescriptionURI 
attribute from deliveryMethod element -->
<xs:element name="qosGroupItem" type="xs:anyURI"
maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="qosItem" type="xs:anyURI"
use="optional"/>
</xs:complexType>
</xs:schema>
個々のＭＢＭＳベアラ間のグルーピング関係を記述するために、二つの新しい要素が導入されている。これらは、 一つ以上のqosGroupItem（ＱｏＳグループ項目）要素を含む、qosGroup（ＱｏＳグループ）要素である。qosGroup（ＱｏＳグループ）要素は、deliveryMethod（配信方法）要素と同じレベルで定義される。 qosGroup（ＱｏＳグループ）内のqosGroupItem（ＱｏＳグループ項目）要素は、ＭＢＭＳベアラの一つのグループを定義する。deliveryMethod（配信方法）要素のsessionDescriptionURI（セッション記述ＵＲＩ）属性で使用されたのと同じＵＲＩが個々のＭＢＭＳベアラを一意に識別する。
【０１１４】
したがって、ＵＥで受信された通知情報内に含まれたＴＭＧＩｓは、ＭＢＭＳユーザ・サービス記述中の定義によるベアラ・グループがネットワークによって提供されているか否かを判断するために使用できる。
【０１１５】
次に、本発明の別の実施形態による、標準のＭＢＭＳユーザ・サービス記述のＸＭＬスキーマの拡張の別の典型的な例を以下に示す（太字の行が適用された拡張を示す）。 
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema elementFormDefault="qualified" 
targetNamespace="urn:3gpp:metadata:2004:userservicedescription" 
xmlns="urn:3gpp:metadata:2004:userservicedescription" 
xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:element name="userServiceDescription"
type="userServiceDescriptionType"/>
<xs:complexType name="userServiceDescriptionType">
<xs:sequence>
<xs:element name="name" type="nameType"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="serviceLanguage" type="xs:language"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="deliveryMethod" 
type="deliveryMethodType"
maxOccurs="unbounded"/>
<xs:element name="qosRelation" type="qosRelationType"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="serviceId" type="xs:anyURI" 
use="required"/>
</xs:complexType>
<xs:complexType name="deliveryMethodType">
<xs:attribute name="associatedProcedureDescriptionURI"
type="xs:anyURI" use="optional"/>
<xs:attribute name="protectionDescriptionURI"
type="xs:anyURI" use="optional"/>
<xs:attribute name="sessionDescriptionURI"
type="xs:anyURI" use="required"/>
</xs:complexType>
<xs:complexType name="nameType">
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute name="lang" type="xs:language" 
use="optional"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:complexType name="qosRelationType">
<xs:sequence>
<xs:element name="qosGroup" type="qosGroupType"
maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="discrete" type="xs:boolean" 
use="optional"/>
</xs:complexType>
<xs:complexType name="qosGroupType">
<xs:sequence> <!-- re-uses sessionDescriptionURI 
attribute from deliveryMethod element -->
<xs:element name="qosGroupItem" type="xs:anyURI"
maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="qosPrio" type="xs:positiveInteger" 
use="optional"/>
<xs:attribute name="qosItem" type="xs:anyURI"
use="optional"/>
</xs:complexType>
</xs:schema>
この拡張は、ＭＢＭＳベアラ・グループの関係の記述をサポートするために使用できる。
【０１１６】
各ＭＢＭＳベアラ・グループとそれらの関係を記述するために、三つの新しい要素がある。deliveryMethod（配信方法）要素と同じレベルで定義されるＱｏＳRelation（ＱｏＳ関係）要素は、ベアラ・グループ間の大まかな関係を記述する。これらのグループは、個別の代替物に相当し得る。すなわち、これらのうちの一つが排他的選択される。あるいは互いに依存する。例えば、同じメディアの各層に相当する。これは、ＱｏＳRelation（ＱｏＳ関係）要素の個別属性に表現される。ＱｏＳRelation（ＱｏＳ関係）要素の子要素は、上記の例示的なＸＭＬ定義に記述されたように、ある一つのグループに属する各ＭＢＭＳベアラを指定するＱｏＳGroup（ＱｏＳグループ）要素である。
【０１１７】
この実施形態で提示した拡張は、ＱｏＳGroup（ＱｏＳグループ）要素のＱｏＳPrio（ＱｏＳ優先順位）属性であり、これは定義されたベアラ・グループの順位を表わすために必要とされる。この順位の正確な意味は、ＱｏＳRelation（ＱｏＳ関係）要素に依存する。ＱｏＳ優先順位は、代替物の順位、例えば、最良から最悪までを指定するか、あるいは相互依存グループの順位、例えば、ベース層とエンハンスメント層を指定する。
【０１１８】
より一般的には、ＭＢＭＳユーザ・サービス記述は、ＵＥｓへ配信されるサービスを記述するメタデータの集合として定義できる。サービスを受信するためのすべての必要なパラメータが、この記述に含まれる。サービス・コンテンツを送信する各ＭＢＭＳベアラは、個々のＳＤＰ記述によって記述される。これらは、ＭＢＭＳユーザ・サービス記述中で、ＵＲＩを介してdeliveryMethod（配信方法）要素において参照される。したがって、各deliveryMethod（配信方法）要素は、ＭＢＭＳユーザ・サービスに含まれた個別のＭＢＭＳベアラを表現する。ＳＤＰ記述を参照するＵＲＩは、このＭＢＭＳベアラを一意に識別する。
【０１１９】
ＱｏＳGroup（ＱｏＳグループ）と呼ばれる、ユーザ・サービス記述中の新しい要素は、関連したＭＢＭＳベアラをグループにまとめる。このようなＱｏＳGroup（ＱｏＳグループ）要素に含まれた各ＭＢＭＳベアラは、ベアラの同一のグループに属する。これらは、ＱｏＳGroup（ＱｏＳグループ）の子要素である新しいＱｏＳGroupItem（ＱｏＳグループ項目）要素に指定される。各ＭＢＭＳベアラのＳＤＰ記述のＵＲＩは、ベアラ識別子として使用される。
【０１２０】
以下のＸＭＬ例は、上に示した二つの例示的な実施形態によるＸＭＬスキーマの定義による拡張されたＭＢＭＳユーザ・サービス記述を示す。
<?xml version="1.0" encoding="UTF-8"?>
<userServiceDescription
xmlns="www.example.com/3gppUserServiceDescription"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
serviceId="urn:3gpp:1234567890coolcat">
<deliveryMethod sessionDescriptionURI=
"http://www.example.com/3gpp/mbms/session1.sdp"/>
<deliveryMethod sessionDescriptionURI=
"http://www.example.com/3gpp/mbms/session2.sdp"/>
<deliveryMethod sessionDescriptionURI=
"http://www.example.com/3gpp/mbms/session3.sdp"/>
<deliveryMethod sessionDescriptionURI=
"http://www.example.com/3gpp/mbms/session4.sdp"/>
<qosGroup>
<qosGroupItem>
http://www.example.com/session1.sdp
</qosGroupItem>
<qosGroupItem>
http://www.example.com/session2.sdp
</qosGroupItem>
</qosGroup>
<qosGroup>
<qosGroupItem>
http://www.example.com/session3.sdp
</qosGroupItem>
<qosGroupItem>
http://www.example.com/session4.sdp
</qosGroupItem>
</qosGroup>
</userServiceDescription>
この記述には、４個のdeliverMethod（配信方法）要素がある。これは、当該ＭＢＭＳユーザ・サービスが４個のＭＢＭＳベアラからなることを意味する。さらに、２個のＱｏＳGroup（ＱｏＳグループ）要素によって２個のグループが指定される。この例では、各グループがＭＢＭＳベアラのうちの２個を含み、これは、各ベアラのＳＤＰ記述のＵＲＩを含む２個のＱｏＳGroupItem（ＱｏＳグループ項目）要素によって表現される。
【０１２１】
上記の例示的なＸＭＬ定義で提示したような拡張ＭＢＭＳユーザ・サービス記述を使用して、階層化、補完的層または代替的層で配信されるＭＢＭＳユーザ・サービスを受信するＵＥｓは、個々のＭＢＭＳベアラ間のグルーピング関係を知り、自律的なＱｏＳ適応がネットワーク内で行われるものと認識する。したがって、ＵＥｓは、ＭＢＭＳユーザ・サービス記述に含まれたすべてのＭＢＭＳベアラのサブセットのみを受信するように準備される。ＵＥｓはグループが完全に受信されるか否かを判断でき、それによりＵＥｓはＭＢＭＳユーザ・サービスを正しく受信できる。
【０１２２】
上記の例示的なＸＭＬスキームは、あるグループに属するＭＢＭＳベアラを識別する問題を解決するだけでなく、これらのグループがどのような相互関係を有するかを定義することもできる（例えば、代替物または層を表わす）。
【０１２３】
関連して、上に提示した第二のＸＭＬスキーマは、グループの相互関係の記述を導入する。これは、新しいＱｏＳRelation（ＱｏＳ関係）要素とＱｏＳGroup（ＱｏＳグループ）要素の拡張によって達成される。ＱｏＳRelation（ＱｏＳ関係）要素は、大まかなグループの関係、すなわち、グループが別個のメディア代替物であるか、または同一メディアの異なる階層に属するかを指定する。そして、ＱｏＳGroup（ＱｏＳグループ）要素のＱｏＳPrio（ＱｏＳ優先順位）属性がグループのハイアラーキを指定する。これは、ＱｏＳRelation（ＱｏＳ関係）要素に依存する、代替物の順位（例えば、最良から最悪までの代替物）または階層の順位（例えば、ベース及びエンハンスメント層）のいずれかである。
【０１２４】
以下の例は拡張を示す。
<qosRelation discrete="true">
<qosGroup qosPrio="1">
<qosGroupItem>
http://www.example.com/session1.sdp
</qosGroupItem>
<qosGroupItem>
http://www.example.com/session2.sdp</qosGroupItem>
</qosGroup>
<qosGroup qosPrio="2">
<qosGroupItem>
http://www.example.com/session3.sdp
</qosGroupItem>
<qosGroupItem>
http://www.example.com/session4.sdp
</qosGroupItem>
</qosGroup>
</qosRelation>
上記の例におけるＱｏＳRelation（ＱｏＳ関係）要素は、記述されたグループが個別に扱われるべきもの、すなわち、サービスの代替物であることを示す。ＱｏＳPrio（ＱｏＳ優先順位）属性は、最初に記述されたグループが好適なグループであることを示す。上記の例示的実施形態では、ＭＢＭＳユーザ・サービス記述中で参照されたメタデータ記述に定義された各々のベアラのコンテンツ・データを提供するためにＲＮＣによって選択された各ベアラについてのＭＢＭＳ通知メッセージをＵＥは受信する。例えば、ページング・チャネルを介してＭＢＭＳ通知メッセージにて受信された、サービスを提供しているベアラのＴＭＧＩｓをＵＥは把握する。この通知により受信したＴＭＧＩｓとＭＢＭＳユーザ・サービス記述の各々のＱｏＳGroup（ＱｏＳグループ）要素のＱｏＳGroupItem（ＱｏＳグループ項目）要素で参照された各記述で定義されたＴＭＧＩｓを比較して、ＵＥは予め決められた（ベアラ）設定においてサービスを受信するために必要なすべてのベアラが受信されたか否かを認識する。
【０１２５】
ＭＢＭＳ通知が、ＭＢＭＳユーザ・サービス記述に定義されたベアラの組み合わせを告知する場合、ＵＥは当該ベアラ上で提供されたコンテンツ・データを受信でき、受信したビデオ・データを表示したり、受信した音声信号を再生するなどして、ＵＥのユーザにコンテンツを提供できる。
【０１２６】
ＭＢＭＳ通知が、ＭＢＭＳユーザ・サービス記述に定義されたベアラ組み合わせを告知しない場合、ＵＥはこの状況に対処するために異なる方策をとることができる。例えば、ＵＥはユーザにサービスが提供できないことを知らせてもよい。すなわち、エラー・メッセージを発動してもよい。あるいは、ＭＢＭＳユーザ・サービスの指示されたＭＢＭＳベアラのセットを、指示されたベアラがＭＢＭＳユーザ・サービス記述に示されたベアラ組み合わせに対応するように、おそらく「満たす」後続の通知の受信をＵＥは待ってもよい。所定の時間期間内に「有効な」ベアラ組み合わせがＵＥに示されることを確実にするために、例えば、タイマーを使用してもよい。タイマーの期限が切れた時点で、ＵＥはエラー・メッセージの発動を決定してもよい。
【０１２７】
以下のパラグラフでは、本発明の例示的な実施形態によるＭＢＭＳマルチキャスト・サービスの典型的な動作を図５を参照して概説する。以下に簡単に概説する、加入、参加及び退去手順を実行することを要求されないことを除いて、ＭＢＭＳブロードキャストサービスの提供も同様である。
【０１２８】
最初のステップでは、関連したＭＢＭＳマルチキャスト・サービスをユーザが受信することを可能にするサービス・プロバイダとユーザの関係が確立される。いわゆるサービス加入は、サービス・プロバイダにより提供されるサービスを受信することへのユーザの合意である。サービス・プロバイダは、ネットワーク運用者のネットワーク中の適当なデータベースに加入情報を記録する（ＵＭＴＳでは、サービス・プロバイダは第三者であり得るが、ＭＢＭＳはネットワーク運用者によって制御される）。
【０１２９】
次のステップは、ＭＢＭＳユーザ・サービス告知／検出メカニズム（４０１）である。このメカニズムは、ユーザが要求を出すことまたは利用可能なＭＢＭＳユーザ・サービスの範囲について通知を受けることを可能にする。利用可能なサービスは、例えば、運用者固有のＭＢＭＳユーザ・サービスやＰＬＭＮの外部のコンテンツ・プロバイダからのサービスがあり得る。
【０１３０】
サービス告知は、サービスとサービス起動に必要なパラメータ（例えば、ＩＰマルチキャスト・アドレス）、場合によりその他のサービスに関連したパラメータ（例えば、サービス開始時）についてのユーザ情報を配布するために使用される。一般に、この情報は、前述の本発明の実施形態による拡張ＭＢＭＳユーザ・サービス記述により提供される（５０２）。
【０１３１】
本発明のある実施形態によれば、ＳＭＳ等の標準的メカニズム、または個々のＵＥの性能に応じてユーザの問い合わせを促進するアプリケーションを含むいくつかのサービス検出メカニズムが使用可能である。ユーザに利用可能なＭＢＭＳユーザ・サービスを通知するために選択される方法は、ユーザの位置に対応する。例えば、ＣＢＳ（セル・ブロードキャストサービス）、ＭＢＭＳマルチキャスト・ユーザ・サービス及びブロードキャスト・ユーザ・サービスを通知するためのＭＢＭＳブロードキャスト・モード、ＭＢＭＳマルチキャスト・ユーザ・サービスを通知するためのＭＢＭＳマルチキャスト・モード、ＷＡＰ、ＳＭＳ−ＰＰまたはＭＭＳ等のＰＵＳＨメカニズム、ＵＲＬ（例えば、ＨＴＴＰ、ＦＴＰを介した）などが、ＭＢＭＳユーザ・サービス告知メカニズムとして使用可能である。
【０１３２】
次に、ユーザによるＭＢＭＳ起動（５０３）が行われる。このプロセスにより、加入者は、マルチキャスト・グループに参加する、すなわち、ユーザは、彼／彼女が特定のＭＢＭＳベアラ・サービスのマルチキャスト・モードのデータを受信する意思があることをネットワークに示す（４０３）。
【０１３３】
ＭＢＭＳマルチキャスト・サービス起動手順は、特定のマルチキャストＭＢＭＳベアラ・サービスからのデータ受信を可能にするために、ネットワークにユーザを登録する。起動は、ＵＥとネットワーク間のシグナリング手順である。手順は、起動された各マルチキャストＭＢＭＳベアラ・サービスに対して、ＵＥ、ＳＧＳＮとＧＧＳＮ及びＲＮＣにＭＢＭＳ ＵＥコンテクストを設定することができる。
【０１３４】
サービス起動手順において、ＵＥは、例えば、受信を希望するＭＢＭＳユーザ・サービスのＭＢＭＳベアラ（ベアラ・サービス）のＩＰマルチキャスト・アドレスをＢＭ−ＳＣに通知することができる。その後のＢＭ−ＳＣとＵＥ間のシグナリングにおいて、ＵＥは通知したＭＢＭＳベアラのＴＭＧＩｓを提供される。したがって、マルチキャスト・サービスの場合、 メディアまたはセッション記述（ＭＢＭＳユーザ・サービス記述により参照される）中のベアラ・サービスのＩＰマルチキャスト・アドレスが、ベアラの相互関係とグルーピング間の、ベアラのＴＭＧＩｓに対するマッピングを設定するために使用できる。
【０１３５】
ＭＢＭＳ起動手順（５０３）のこのシグナリングにおいて、さらにＭＢＭＳ登録手順が実行される。ＭＢＭＳ登録は、下流のノードが上流のノードに特定のＭＢＭＳベアラ・サービスのセッション属性とデータを、それをさらに下流へ配信するために受信したい旨を通知する手順である。この手順は、ＢＭ−ＳＣからサービスに関与したＵＥｓまでのＭＢＭＳセッション属性とデータの転送のための配信ツリーを構築し、配信ツリー中の各ネットワーク・ノードにＭＢＭＳベアラ・コンテクストを設定する。ＭＢＭＳユーザ・サービスの各ベアラ（ＭＢＭＳベアラ・サービス）に対して、ＭＢＭＳベアラ・コンテクストが各ネットワーク・ノードに設定される（５０４）。ＭＢＭＳベアラ・コンテクストは、とりわけ、各ＭＢＭＳベアラ・サービスに要求されたＱｏＳとＵＥがサポートしなければならない最小のベアラ能力等を具備する。
【０１３６】
しかし、ネットワーク・ノードは、単一のＭＢＭＳユーザ・サービスに属する各ベアラまたはそれらの関係については認識しない。ＭＢＭＳ登録手順は、ＭＢＭＳベアラ・サービスの相互関係に関する情報をネットワーク・ノードに提供する、以下に説明するＭＢＭＳユーザ・サービス・コンテクストを配送ツリー上のネットワーク・ノードに設定する（５０４）ように適合されてもよい。ＭＢＭＳサービスの要求元のＵＥをサーブするＲＮＣでも設定される、ＭＢＭＳユーザ・サービス・コンテクストは、セッション・セマンティクスを反映する。すなわち、ベアラの関係に関する情報を提供し、追加のベアラ特性を記述する。下表は、本発明の例示的な実施形態によるこのコンテクストの内容を示す。
【０１３７】
【表１】
2010081625.tif 000003
【０１３８】
各ベアラの情報要素は、ベアラの相互関係に応じて異なるフィールドを含み得る。例示タイプ（階層化、代替的、及び補完的）ごとの情報要素を以下に述べる。
【０１３９】
【表２】
2010081625.tif 000004
【０１４０】
【表３】
2010081625.tif 000005
【０１４１】
【表４】
2010081625.tif 000006
【０１４２】
【表５】
2010081625.tif 000007
【０１４３】
【表６】
2010081625.tif 000008
【０１４４】
【表７】
2010081625.tif 000009
【０１４５】
上記のＭＢＭＳユーザ・サービス・コンテクストを維持するとき、ＲＮＣは、ＭＢＭＳユーザ・サービスを提供可能な異なるベアラの組み合わせとそれらの要求ＱｏＳを認識する（ＭＢＭＳベアラ・コンテクスト）。
【０１４６】
次のステップ５０５では、ＢＭ−ＳＣはデータ送信とセッション開始の準備が整う。セッション開始は、ユーザによるサービスの起動とは関わりなく発生可能である。セッション開始手順は、ネットワーク内でＭＢＭＳデータを転送するためのベアラ・リソースを確保する契機を与える。したがって、ＢＭ−ＳＣはサービス・コンテンツの下流への送信（５０９）を始める。
【０１４７】
セッション開始手順を通じて、ＱｏＳや、もし得られていれば、推定セッション継続時間などのＭＢＭＳセッション属性が、該当ＭＢＭＳベアラ・サービスのためにすでに登録されたＧＧＳＮ（ｓ）とＳＧＳＮ（ｓ）及び登録されたＳＧＳＮに接続されるすべてのＲＮＣｓへ提供される。
【０１４８】
本発明の一つの実施形態によれば、ＭＢＭＳユーザ・サービスの要求元のＵＥをサーブするＲＮＣは、ＵＥ側へのそのインタフェース上の利用可能なリソースをそのサービスの品質管理機能から要求することができる（５０６）。この機能は、ＲＮＣにＵＥへの下流側のサービス提供のためのＱｏＳ制限を提供する。サービスの品質管理機能から得た情報とベアラの関係性の知識（ＭＢＭＳユーザ・サービス・コンテクスト）とそれぞれのＱｏＳ要件（ＭＢＭＳベアラ・コンテクスト）に基づいて、ＲＮＣは、サービスの品質管理機能から得たＱｏＳ制限内で要求されたＭＢＭＳユーザ・サービスをＵＥに提供できるＭＢＭＳベアラ組み合わせを選択することができる（５０７）。このようにして、ＲＮＣは、そこを通じてＵＥｓが以前にサービスを要求したすべてのインタフェース上のＱｏＳ制限を得て、各インタフェース（セル）について各々のＱｏＳ制限を満たすベアラ組み合わせを選択することができる。
【０１４９】
各セルに対して適切なベアラ組み合わせを選択した後、それぞれ選択したＭＢＭＳベアラの来るべき（進行中の可能性もある）送信をサービス要求元のＵＥｓに通知するために、ＲＮＣは選択したＭＢＭＳベアラについてのＭＢＭＳ通知をブロードキャストすることができる（５０８）。まだ送信されていなければ、ＲＮＣは、ＭＢＭＳユーザ・サービスの選択したＭＢＭＳベアラ上でコンテンツ・データのマルチキャストを開始することができる。
【０１５０】
ＭＢＭＳサービスへの関与を告知したＵＥは、そのセル内の選択されたベアラについてのＭＢＭＳ通知を受信し、選択されたベアラからのコンテンツ・データ受信を開始する（５１０）。ＭＢＭＳユーザ・サービス記述によってベアラの相互関係の情報を知らされているので、上述したように、ＵＥは「有効な」ベアラ組み合わせが提供されるか否かを認識できる。
【０１５１】
ＭＢＭＳユーザ・サービス提供時に実行される手順のシーケンスを完了するため、セッション停止手順を次に説明する。ＢＭ−ＳＣ（ブロードキャスト／マルチキャスト・サービス・センター）は、ＭＢＭＳセッションを終了すべきと判断したとき、ＭＢＭＳセッション停止手順を開始する。ネットワーク内のベアラ・プレーン・リソースの解放を正当化するのに十分長い期間にわたり、さらなるＭＢＭＳデータの送信が期待されないときに、セッションは通常終了される。手順は、該当ＭＢＭＳベアラ・サービスのために登録されたすべてのＳＧＳＮｓとＧＧＳＮｓ及びＳＧＳＮとのｌｕベアラ・プレーンを確立したＲＮＣｃへ伝播される。
【０１５２】
退去手順によって、ＵＥはＭＢＭＳマルチキャスト・サービスの受信を終了することができる。ユーザによるこのＭＢＭＳマルチキャスト停止は、加入者がマルチキャスト・グループから退去する（そのメンバーであることをやめる）プロセスであり、すなわち、特定のＭＢＭＳベアラ・サービスのマルチキャスト・モードのデータの受信をユーザはもはや望まない。
【０１５３】
本発明の別の実施形態は、ハードウェア及びソフトウェアを使用した、上記の多様な実施形態の実現に関係する。多様な前述の方法、並びに前述の様々な論理ブロック、モジュール、回路は、例えば、汎用プロセッサ、デジタル・シグナル・プロセッサ（ＤＳＰ）、特定用途向け集積回路（ＡＳＩＣ）、フィールド・プログラマブル・ゲート・アレイ（ＦＰＧＡ）またはその他のプログラム可能論理素子など、コンピューティング・デバイスを使用して実現可能または実施可能であることが認識される。本発明の多様な実施形態は、上記のデバイスの組合せによっても実施または実現可能である。
【０１５４】
さらに、本発明の多様な実施形態は、プロセッサにより実行されるソフトウェア・モジュールを用いても実現可能であり、またはハードウェアにより直接実現することもできる。また、ソフトウェア・モジュールとハードウェア実現の組合せも可能である。ソフトウェア・モジュールは、例えば、ＲＡＭ，ＥＰＲＯＭ，ＥＥＰＲＯＭ，フラッシュ・メモリ、レジスタ、ハード・ディスク、ＣＤ−ＲＯＭ，ＤＶＤ等、コンピュータで読取り可能などんな種類の記憶媒体に記憶されてもよい。
【図１】
2010081625.tif 000010
【図２】
2010081625.tif 000011
【図３】
2010081625.tif 000012
【図４】
2010081625.tif 000013
【図５】
2010081625.tif 000014