JP2009530928A - ドメイン間グループ通信 - Google Patents

Abstract

本発明は、グループ通信サービス、即ち、二人以上のユーザ（またはサービス参加者）を伴う通信サービスに関わる。本発明は、異なるドメインにマルチキャストサービスのマルチキャストデータを配信する方法と、ドメインにおけるサービス参加者にマルチキャストデータを配信する方法と、を提供する。本発明は、更に、それぞれの方法を実行する制御ノードとシステムに関わる。サービス参加者にマルチキャストサービス、とりわけ、ＰｏＣサービスを提供する際のリソース利用を向上するために、本発明は、異なるドメインのサービス参加者へのマルチキャストサービスの配信ツリーにおけるマルチキャストデータの不要な増大を回避するための機構を提供する。このために、どのドメインにマルチキャストデータを提供すべきか決定された要求の際にマルチキャストサービスを開始する制御ノードはドメイン毎にマルチキャストデータを送る。本発明の別の態様では、個々のドメイン内でマルチキャストデータが不必要に複製されることが回避される。

Description

本発明は、グループ通信サービス、即ち、二人以上のユーザ（またはサービス参加者）を伴う通信サービスに関する。本発明は、異なるドメインにマルチキャストサービスのマルチキャストデータを配信する方法、および、ドメイン内のサービス参加者にマルチキャストデータを配信する方法に関する。本発明は、更に、それぞれの方法を実行する制御ノードおよびシステムに関する。

ＩＰマルチメディアサブシステム（ＩＭＳ）
ＩＭＳは、３ＧＰＰによって新しいサブシステム、つまり、ＩＰベースのインフラストラクチャ上でデータ、音声、および、モバイルネットワーク技術を集合させる新しいモバイルネットワークのインフラストラクチャと定義されている。

ＩＭＳは、帯域幅を増加させるだけでは得られない、既存の従来の電気通信技術と、インターネット技術との間のギャップを埋めるために設計された。これにより、操作者は株主やエンドユーザが期待する新しく革新的なサービスを提供することができる。

ＩＭＳは、具体的には、リッチな音声サービス、ビデオ電話、メッセージング、会議、およびプッシュサービス等のリアルタイムなマルチメディアモバイルサービスを可能にし且つ改善するために設計されている。ＩＭＳは、セッション交渉や管理、品質サービス（ＱｏＳ）、および、移動性管理を含む幾つかの主要な機構を介してユーザ対ユーザ通信サービスを可能にするよう設計されている。しかしながら、ＩＭＳは、リアルタイムなユーザ対ユーザサービス以上のことを可能にする。

モバイル産業は、従来の音声および短メッセージサービス中心のビジネスから幅広い新しく刺激的なマルチメディアサービスおよびアプリケーションへの移行段階にある。電話やメッセージは、次世代の人対人のアプリケーションによって補足され得、それにより双方向無線セッション（プッシュトゥトーク）のより簡単な共有、ビューの共有、ファイル、共有ホワイトボード、および、マルチプレーヤゲーム経験の共有を可能にする。更に、プッシュトゥトークセッション中にマルチプレーヤゲームを追加する等の際に、既存のサービスを刺激的な方法で組み合わす能力を提供する。

ＩＰマルチメディアサブシステム（ＩＭＳ）は、セルラ／無線ネットワーク（ｈｔｔｐ：／／ｗｗｗ．３ｇｐｐ．ｏｒｇより入手可能な非特許文献１参照）における発展を含むだけでなく、移動装置と固体装置との間で新しいサービスを可能にする。このようなサービスの例として、移動端末とＰＣ間のコンテンツ共有やメッセージングサービスが挙げられる。

プッシュトゥトークオーバーセルラ（ＰｏＣ）
ＩＭＳインフラストラクチャを利用するサービスの一つは、オープンモバイルアライアンス（ＯＭＡ）によって開発され標準化されたプッシュトゥトークオーバーセルラ等のプッシュトゥトークアプリケーションである。

プッシュトゥトークオーバーセルラは、セルネットワーク上で直接一対一および一対多数の音声通信サービスを提供する。考え方は簡単である。ＰｏＣの「常時接続」により、ユーザはボタンを押すだけで個人またはグループに電話をかけることができる。他のユーザの利用可能性は、存在する機能により電話をかける前に確認することができる。電話は、略一瞬で接続され、受信側は応答する必要がない。プッシュトゥトークサービスのユーザは、電話以外のアクティビティを行っている場合もあり、忙しい間はグループトラフィックを聞くことで通じていることもできる。ユーザは、名前で接触されてもよく、または、グループに対して発言したいと思うこともしばしばある。ＰｏＣは、ＩＰ対応ネットワークを用いる半二重ボイスオーバＩＰ（ＶｏＩＰ）技術に基づき、つまり、一人の参加者は他の参加者が音声データを受信している間話すことができる。

プッシュトゥトークは、どの既存のセルラサービスの代用品でもない。操作者が、既存のサービスを変更することなくそれぞれの音声ポートフォリオを展開し区別することができるようにする補完的なサービスである。

ＯＭＡのＰｏＣ標準ネットワークアーキテクチャは、図１０に例示的に示すように、ＩＰマルチメディアサブシステム（ＩＭＳ）に接続されたＰｏＣアプリケーションサーバ（ＰｏＣ ＡＳ）に基づく。ＩＭＳは、セッション初期化プロトコル（ＳＩＰ）に基づくユーザ認証、呼び出しルーティング、および、一般的なチャージング等の共通の機能を取り扱う。

以下では、ＯＭＡウェブサイトｈｔｔｐ：／／ｗｗｗ．ｏｐｅｎｍｏｂｉｌｅａｌｌｉａｎｃｅ．ｏｒｇを参照し、特に、非特許文献２および非特許文献３（ｈｔｔｐ：／／ｗｗｗ．ｏｐｅｎｍｏｂｉｌｅａｌｌｉａｎｃｅ．ｏｒｇより入手可能）を参照する。

ＰｏＣアプリケーションサーバは、フロア制御（個別に一人の話手に対するトークの予約）等のアプリケーション特有のタスクを扱う。操作者のプロビジョニングおよびネットワーク管理システムにインターフェースを提供し、アプリケーション特有のチャージングディテールレコード（ＣＤＲ）を作成する。プッシュトゥトークのユーザのデータベースは、提供されたユーザおよびそのサービスプロファイルを含む。ユーザおよびトークグループは、ビジネスアプリケーションで必要な安全および管理能力をサポートするために組織特有の閉ユーザグループにおけるデータベースに配置され得る。プッシュトゥトークソリューションは、幾つかのネットワーク化されたＰｏＣアプリケーションサーバで数百万ユーザネットワークに拡大され得る。

図１０に示すように、様々なセルラアクセスネットワークがＰｏＣユーザにＰｏＣメディアデータを配信するために使用される。セルラアクセスネットワークは、ＰｏＣエネーブラと呼ばれる。ＰｏＣエネーブラの例として３ＧＰＰネットワーク、ＧＳＭネットワーク、または、３ＧＰＰネットワークが挙げられる。ＰｏＣエネーブラとして３ＧＰＰネットワークに対するアーキテクチャ上の要件は、３ＧＰＰＴＲ２３．９７９（ｈｔｔｐ：／／ｗｗｗ．３ｇｐｐ．ｏｒｇより入手可能な非特許文献４）から明らかであろう。

プッシュトゥトークは、マルチユニキャスティングに基づく。各送信側クライアントは、専用のプッシュトゥトークサーバにパケットデータトラフィックを送信し、グループ呼び出しの場合には、サーバは全ての受信側にトラフィックを複製する。アクセスまたコアネットワークではマルチキャスティングは実施されず、移動性管理は、無線ネットワークによって行われる。そのため、プッシュトゥトークソリューションはセルラおよび固定ネットワーク上でユーザに気付かれることなく動作する。ＰｏＣ呼び出し制御および他のシグナリングは、ＩＥＴＦ定義されたＳＩＰに基づき、音声トラフィックは、ＲＴＰ／ＲＴＣＰベースのストリーミングベアラを介して行われる。移動性は、ＧＳＭ／ＷＣＤＭＡ上のサポート広範囲ローミングを利用して（Ｅ）ＧＰＲＳを介して扱われる。

ＰｏＣソリューションプロトコルスタックは図１１に示される。アプリケーションレベルでは、ＰｏＣアプリケーションが提供される。セッション関連のシグナリングについて、セッションを確立、変更、または、破壊するようＳＩＰが典型的には使用される。メディアには伝送ＲＴＰ／ＲＴＣＰが一般的に使用される。シグナリングおよび伝送関連のプロトコルＳＩＰおよびＲＴＰ／ＲＴＣＰは、ＵＤＰ（ＴＣＰも可能）およびＩＰプロトコルによって伝送される。ＩＰパケットは、最終的には、３ＧＰＰモバイルチャネル等のアクセスネットワーク特有チャネルを用いて異なるアクセスネットワークにおけるサービス参加者に提供される。

潜在的な問題
ＰｏＣサービスは、ＰｏＣアプリケーションサーバ（ＰｏＣ ＡＳ）と呼ばれる会議中心、つまり、通信を制御する中心的なエレメントに基づく。全ての参加者は、該ノードに接続され、結果としてＰｏＣサービスの基礎となるスター型トポロジーが得られる。主な機能の一つとしては、ＰｏＣ ＡＳはフロア制御を実行する、つまり、話す許可を制御する。フロアを取った参加者は、音声データをＰｏＣ ＡＳに送信し、ＰｏＣ ＡＳは全ての他の参加者に配信する。

一般的に、ＰｏＣ ＡＳは、ＩＰマルチメディアサブシステム（ＩＭＳ）のアプリケーションサーバとして実行される。ＰｏＣサービスの参加者は、ＩＭＳネットワークにアクセスを提供するどのＩＰ接続アクセスネットワーク（ＩＰ−ＣＡＮ）を介してＰｏＣ ＡＳに接続されてもよい。第３世代の移動通信システムの標準化プロジェクト（３ＧＰＰ）によって特定されるＧＥＲＡＮおよび／またはＵＴＲＡＮ無線アクセスを含むＧＰＲＳアクセスも含まれる。

会議中心としてＰｏＣアプリケーションサーバを使用することにより、サービスが簡単に（中央型）制御される。グループ通信は、多数のポイントトゥポイント接続を用いて実現される。しかしながら、グループの大きさを増大させるには、このポイントトゥポイント接続性質は、サービスデータの非効率的な配信を生じさせる。同じデータが各参加者に対して個別にコピーされ送信されなくてはならない。これは、サービスにアクセスするために少ない無線リソースを利用する無線参加者に特に関連している。

上述の通り、特に、グループの大きさが大きく無線リソースが少ない場合のグループ通信の効率的な配信が必要である。多数のポイントトゥポイント送信の非効率性を回避するためには、ポイントトゥマルチポイント伝送またはマルチキャスティングを可能ならいつでも利用することが明らかであろう。

ＩＭＳネットワークへのＧＰＲＳベースのＩＰ−ＣＡＮに関して、この機能性はマルチメディアブロードキャスト／マルチキャストサービス（ＭＢＭＳ）によって提供される。ＧＰＲＳコアネットワークにおいてマルチキャスト配信ツリーを確立し、ユーザの大グループにデータ効率的に送信する無線ブロードキャストを利用する。ＭＢＭＳは、ＵＴＲＡＮ並びにＧＥＲＡＮ無線アクセスネットワークにおいてサポートされる。

ＩＭＳサービス、特に、ＰｏＣにＭＢＭＳを利用することは、３ＧＰＰ標準化グループにおいて最近議論されている。この事項は３ＧＰＰ作業項目において取り組まれ、それぞれのサービス要件が３ＧＰＰ ＴＳ２２．２２８（ｈｔｔｐ：／／ｗｗｗ．３ｇｐｐ．ｏｒｇから入手可能な非特許文献５参照）において定義されている。更なる技術的提案が、ＩＭＳサービスにおいてどのようにしてＭＢＭＳ利用を実現するかについてなされている。しかしながら、最近の議論は、ローカルドメイン、例えば、限定されたサービスシナリオだけを表す、単一の操作者のネットワーク内でのＭＢＭＳの使用に焦点を当てている。

本発明や従来技術との差をより良く理解するためには、完全なサービスシナリオを理解する必要がある。一般的には、ＩＭＳサービスは、例えば、異なるオペレータネットワークを伴う異なるドメインにわたることが可能である。これは、ＰｏＣサービスでも本来可能である。このドメイン間シナリオをサポートするためには、ＰｏＣ ＡＳはＰｏＣ呼び出しにおいて様々な論理的且つ機能的役割を担う。ＰｏＣ ＡＳは、制御ＰｏＣ機能または参加ＰｏＣ機能を実行するか、同時にそれぞれの機能を実行する。制御ＰｏＣ ＡＳは、呼び出し制御を実行する会議中心として機能し、参加ＰｏＣ ＡＳはローカルドメインのＰｏＣユーザと別のドメインの制御ＰｏＣ ＡＳの間でシグナリングやデータを送るプロキシとして機能する。必ず一つの単一の制御ＰｏＣ ＡＳが存在するが、異なるオペレータドメイン等に多数の参加ＰｏＣ ＡＳがＰｏＣ呼び出しにおいて存在する。通常、ＰｏＣ呼び出しを開始するユーザとしてのＰｏＣ ＡＳは、制御ＰｏＣ ＡＳの役割を担う。

本分野における現在の標準化活動は進行中でまだ完成していないが、ＰｏＣサービスにＭＢＭＳ伝送機能が利用可能となることが予想される。ＭＢＭＳの制御エレメントは、ブロードキャストマルチキャストサービスセンター（ＢＭ−ＳＣ）である。ＰｏＣサービスにおけるＭＢＭＳの利用は、様々な方法で実現される。ＰｏＣ ＡＳとＢＭ−ＳＣとの間で新しいインターフェースを確立して、両（別個の）エレメント間の対話を可能にしてもよい。別の方法としては、両機能モジュールを単一のエレメントに一体化することである。しかしながら、機能の面からすると、それぞれのオプションは同じである。

前述の通り、ＭＢＭＳ機能は、ＧＰＲＳベースのＩＰ−ＣＡＮ内で利用可能である。一般的には、特定のネットワークオペレータの制御下にある。上記したドメイン間シナリオに関しては、ＰｏＣ呼び出しが多数のオペレータドメインにわたるため、ＭＢＭＳ伝送機能性に対するサポートが特定のＰｏＣ ＡＳのローカル特性といった結果を生ずる。したがって、ＭＢＭＳが呼び出しに関わる全てのＰｏＣ ＡＳで利用可能でない場合も考慮しなくてならない。

ネットワークにおけるＭＢＭＳサポートは、ＰｏＣサービスにおいて利用する上で考慮しなくてはならない一つの点である。別の点は、ＭＢＭＳ受信が端末の能力に依存する点である。幾つかの端末は、ＰｏＣのようにＩＭＳサービスと平行してＭＢＭＳを受信することができない場合もある。他の端末は、ＭＢＭＳを全く受信できない場合もある。したがって、ＭＢＭＳが全てのＰｏＣユーザによってサポートされ得ないことも仮定しなくてならない。

上記した完全なサービスシナリオにおいて生ずる主な問題は、ＰｏＣ呼び出しに伴う各ＰｏＣ ＡＳの異なる機能的役割によるものである。ＭＢＭＳ伝送のサポートがＰｏＣ ＡＳのローカル特性であるため、制御ＰｏＣ ＡＳは参加ＰｏＣ ＡＳがＭＢＭＳ伝送機能性を利用するか否かを知らず、ポイントトゥポイント接続されたユーザと推測する。

したがって（既に記載した通り）、制御ＰｏＣ ＡＳは参加ＰｏＣ ＡＳに対して各参加者に個々の接続を確立し、到来する音声データの個々のコピーを配信する。ＭＢＭＳ伝送機能性がローカルドメインで利用されている場合、参加ＰｏＣ ＡＳは全ての接続で受信した全ての音声データをＢＭ−ＳＣに送る。したがって、同じ音声データの全ての個々のコピーがＭＢＭＳベアラ上で送信される。ローカルドメイン内の全ての参加者が該ＭＢＭＳベアラを受信するため、各参加者は一回だけでなく、同じ音声データの全てのコピーを受信することになる。

一方で、当然のことながらこの音声データのコピーの不必要な送信は、特に、無線インターフェース上でリソースの無駄である。他方で、端末での多数の音声データの複製の受信は、ＰｏＣユーザに顕著には行われず、アプリケーションを受信する上で幾つかの問題が生ずる。

シナリオとその潜在的な問題を図１２に例示的に示す。

結果として、音声データのコピーの不必要な送信が
（１）制御と参加ＰｏＣ ＡＳとの間、
（２）ＰｏＣ呼び出しのダウンリンクＭＢＭＳベアラ
において生ずる。

完全なサービスシナリオにおいて生ずる別の問題は、ＰｏＣ呼び出しにＭＢＭＳ伝送機能性を利用するか否かの判断に関連する。ＰｏＣサービスはグループ通信を可能にし、ＭＢＭＳはユーザのグループにデータを効率的に配信するが、利用可能なＭＢＭＳ伝送機能性を全てのケースで使用することが賢明でないこともある。その特性、特に、無線インターフェース上での特性により、効率的なデータ送信とＭＢＭＳのリソース消費量とに関してトレードオフが存在する。

したがって、ユーザの大きいまたは密度の高いグループにＭＢＭＳ伝送を利用することは意味がある。これに関して、ＰｏＣ ＡＳにおけるＭＢＭＳ判断の基として、正確なグループ情報が利用可能であることが重要である。これは、開始ＰｏＣユーザからの要求において完全なグループ情報を受信する制御ＰｏＣ ＡＳの場合である。しかしながら、参加ＰｏＣ ＡＳでは見られない。ここでは、グループ情報は別個のシグナリングメッセージから導出されなくてはならないため、ＰｏＣ呼び出しにおけるＭＢＭＳ利用の判断を複雑化させ得る。
3GPP TR 23.228 "IP Multimedia Subsystem (IMS); Stage 2", V. 7.2.0 OMA draft "Push to talk over Cellular (PoC) - Architecture", Candidate Version 1.0, 27 Jan. 2006 OMA draft "Push to talk over Cellular (PoC) - Architecture", Draft Version 2.0, 14 Mar. 2006 3GPP TR 23.979 "3GPP enablers for Open Mobile Alliance (OMA); Push-to-talk over Cellular (PoC) services; Stage 2", V. 6.2.0 3GPP TS 22.228, "Service requirements for the Internet Protocol (IP) multimedia core network subsystem (IMS); Stage 1", V. 7.3.0 RFC 3261, "SIP: Session Initiation Protocol" by the IETF (Internet Engineering Task Force) from June 2002 RFC 3320, "Signaling Compression (SigComp)" of the IETF from January 2003

本発明は、サービスの参加者に、マルチキャストサービス、とりわけＰｏＣサービスを提供する際に改善されたリソース利用を提供することを目的とする。

この目的は、独立請求項の技術的内容によって解決される。本発明の有利な実施形態は、従属請求項の技術的内容である。

本発明の一つの主な態様は、異なるドメインのサービス参加者へのマルチキャストサービスの配信ツリーにおけるマルチキャストデータを不必要に増大することを回避する。このために、どのドメインにマルチキャストデータを提供すべきか決定された要求の際にマルチキャストサービスを開始する制御ノードはドメイン毎にマルチキャストデータを送る。

本発明の別の態様では、個々のドメイン内でマルチキャストデータが不必要に複製されることを回避する。本態様によると、ドメインの制御ノードは、そのドメイン内でサービスを受信するサービス参加者に関する情報を取得し、制御ノードは、ドメイン内のサービス参加者にマルチキャストデータを提供するために、ドメイン内または無線アクセスサブシステムそれぞれでポイントトゥポイントリンクまたはポイントトゥマルチポイントリンクを利用するかをドメイン毎にまたは無線アクセスサブシステム毎に判断する。この動作は、ドメイン内での最適化されたリソース利用を可能にするため有利である。

本発明の一実施形態によると、異なるドメインにマルチキャストサービスのマルチキャストデータを配信する方法が提供される。異なるドメインの第１のドメインの制御ノードは、マルチキャストサービスに参加するサービス参加者を識別するサービス開始要求を受信する。サービス参加者の識別に基づき、サービス参加者が属し、且つ、第１のドメインの制御ノードによって制御されないドメインを識別し、ドメイン毎に識別されたドメインの制御ノードにマルチキャストデータを配信する。

本発明の別の実施形態では、制御ノードは、識別された制御ノードにサービス開始要求を送信する。制御ノードに送信されるサービス開始要求は制御ノードによって制御されるそれぞれのドメインに属するサービス参加者を含む。それぞれのドメインにおけるサービス参加者について識別されたドメインの制御ノードに通知することは、それぞれのドメインのサービス参加者にマルチキャストデータを提供するためにドメインにおいて使用されるべき最も適した伝送の判断を情報が容易にし得るため有利である。

別の実施形態によると、第１のドメインの制御ノードは、マルチキャストデータがそれぞれの制御ノードに送られるべき識別されたドメインそれぞれの制御ノードにポイントトゥポイントリンクを確立する。

本発明の別の実施形態によると、識別されたドメインそれぞれの制御ノードにマルチキャストデータを配信する際、マルチキャストデータそれぞれの単一のコピーがそれぞれのドメインの制御ノードにポイントトゥポイントリンクを介して配信され、それぞれのドメインのサービス参加者に更に配信される。上記の通り、マルチキャストデータをドメイン毎に配信することは、異なるドメインの制御ノード間のインターフェース上でのマルチキャストデータの不要な複製を回避するために有利である。それぞれのマルチキャストデータの単一のコピーは、それぞれのドメインに複数のサービス参加者がいる場合でもそれぞれのドメインの制御ノードに配信される。

本発明の更なる実施形態によると、（第１のドメインの）制御ノードは、識別されたドメインのうちの一つの制御ノードからのサービス開始要求に応答して否定応答を受信する。否定応答に応答して、否定応答に応じて制御ノードによって制御されるドメインにおけるサービス参加者それぞれに個々のサービス開始要求を送信する。この動作は、本願記載のように改良されていない標準的な制御ノードとの互換性が得られる点で有利である。

本発明の別の実施形態は、ドメイン内のサービス参加者にマルチキャストサービスのマルチキャストデータを配信する方法に関わる。ドメインの制御ノードは、最初に、別のドメインの制御ノードからサービス開始要求を受信する。サービス開始要求は、制御ノードによって制御されるドメインに位置するマルチキャストサービスに参加するサービス参加者に関する情報を含む。サービス参加者に関する情報に基づいて、ドメインの制御ノードは、ドメイン内でマルチキャストデータを配信するためにポイントトゥポイントリンクを利用するかポイントトゥマルチポイントリンクを利用するかを判断する。この判断に依存して、制御ノードは、ドメインにおけるサービス参加者それぞれにポイントトゥポイントまたはドメインにおけるサービス参加者にポイントトゥマルチポイントを、マルチキャストデータの伝送媒体として確立し、確立された伝送媒体を介してドメインにおけるサービス参加者にマルチキャストデータを配信する。

ドメイン内に複数の無線ネットワークサブシステムが存在する場合には、リソース利用を更に最適化するためにドメイン毎の代わりに無線ネットワークサブシステム毎にどの伝送媒体を使用するかを判断することが有利である。したがって、本発明の別の実施形態では、制御ノードは、サービス参加者にサービングする少なくとも一つの無線ネットワークサブシステムを決定する。ポイントトゥポイントリンクまたはポイントトゥマルチポイントリンクの利用に関する判断は、決定された無線ネットワークサブシステム毎に行われ、サービス参加者毎のポイントトゥポイントリンクまたはポイントトゥマルチポイントは各決定された無線ネットワークサブシステムそれぞれに確立される。

別の有利な実施形態は、例えば、ユーザ移動性により新しいユーザがサービスに参加するまたはサービスから出る等、ドメインにおけるまたは無線ネットワークサブシステムにおけるサービス参加者数の変化を説明する。典型的な実施形態によると、ドメイン内のマルチキャストサービスに現在参加しているサービス参加者の数に依存して、伝送媒体はポイントトゥポイントリンクからポイントトゥマルチポイントリンク、または、その逆に切り換えられる。代替的には、ポイントトゥポイントリンクからポイントトゥマルチポイントリンクへの切換は、無線ネットワークサブシステム毎に行われてもよい。

マルチキャストデータを配信するためにポイントトゥマルチポイントリンクを使用する場合、本発明の別の実施形態は、ドメインにおいてマルチキャストデータを配信するために利用される、ＭＢＭＳ等のドメイン幅のマルチキャストサービスの使用を予測する。典型的には、マルチキャストサービスは、マルチキャストサービスセンターと呼ばれるドメイン内の機能的エンティティによって提供される。本実施形態によると、ドメインの制御ノードは、ドメイン内のマルチキャストサービスセンターにマルチキャストデータを送り、ドメインレベルまたは無線ネットワークサブシステムレベルでドメインにおいて利用可能なマルチキャストサービスを利用する。

本発明の別の実施形態では、ドメインの制御ノードは、サービス開始要求を承認して、即ち、承認またはエラーメッセージの形態で肯定または否定フィードバックを提供する。

肯定フィードバックの返信は、他のドメインの制御ノードとポイントトゥポイントリンクを確立する。更に、マルチキャストサービス識別子はポイントトゥポイントリンク上でマルチキャストサービスのデータの識別を可能にするよう、マルチキャストサービス識別子がリンクに割り当てられる。

本実施形態の変形例では、マルチキャストサービス識別子を、ドメイン内のマルチキャストサービスセンターによって使用されるマルチキャストサービス識別子と関連付けられ、ドメインにおけるサービス参加者に配信される際にマルチキャストサービスデータを識別する。この動作は、ドメイン間およびドメイン内で配信される際に、異なる識別子がマルチキャストデータに使用される場合に有利である。

本発明の別の実施形態によると、ドメインの制御ノードは、他のドメインの制御ノードから受信されるサービス開始要求で識別されるサービス参加者それぞれに対してサービス開始要求を生成し、ドメインのサービス参加者に少なくとも一つの生成されたサービス開始要求を送信する。制御ノードの本動作により、とりわけ、最初のサービス開始要求を受信する制御ノードではなく、個々のドメイン内でマルチキャストサービスのサービス開始要求を生成することが可能であり、制御ノード間のドメイン間シグナリングの負荷を減少させる。

本実施形態の典型的な変形例では、サービス参加者それぞれのサービス開始要求は、マルチキャストサービスデータを識別するためにドメイン内のマルチキャストサービスセンターによって使用されるべきマルチキャストサービス識別子を備える。これは、マルチキャストデータがドメイン内の特別なマルチキャストサービス伝達機構（たとえば、独自のサービス識別子を利用するＭＢＭＳ（例えば、ＭＢＭの場合には、特定のマルチキャストアドレス））を用いるポイントトゥマルチポイントリンクを介してサービス参加者にマルチキャストデータが送信されるべき場合に特に有利である。

本発明の別の実施形態は、ドメイン内でのマルチキャストデータの提供にマルチキャストサービスを効率的に利用することに関する。サービス参加者にマルチキャストデータを提供するマルチキャストサービスの高速サービスアクティベーションをサポートするために、ドメインの制御ノードが、ドメイン内のマルチキャストサービスセンターにドメインのサービス参加者を申し込むことが有利である。例えば、サービス参加者にマルチキャストデータを提供するためにＭＢＭＳを利用する場合、制御ノードは、ドメインのＢＭ−ＳＣで参加者を申し込む。

本発明の更なる実施形態は、異なるドメインにマルチキャストサービスのマルチキャストデータを配信する第１のドメインの制御ノードを提供する。この制御ノードは、マルチキャストサービスに参加するサービス参加者を識別するサービス開始要求を受信する受信器と、サービス参加者の識別に基づき、サービス参加者が属し、且つ、第１のドメインの制御ノードによって制御されないドメインを識別するプロセッサと、を備える。更に、制御ノードは、ドメイン毎に識別されたドメインの制御ノードにマルチキャストデータを配信する送信器を備える。

本発明の別の実施形態は、ドメインにおけるサービス参加者にマルチキャストサービスのマルチキャストデータを配信する制御ノードに関する。この制御ノードは、制御ノードによって制御されるドメインに位置するマルチキャストサービスに参加するサービス参加者に関する情報を含む別のドメインの制御ノードからのサービス開始要求を受信する受信器と、ドメイン内でマルチキャストデータを配信するためにポイントトゥポイントリンクを利用するかポイントトゥマルチポイントリンクを利用するかを、サービス参加者に関する情報に基づいて判断し、判断に依存して、ドメインにおけるサービス参加者それぞれにポイントトゥポイントまたはドメインにおけるサービス参加者にポイントトゥマルチポイントを、マルチキャストデータの伝送媒体として確立するプロセッサと、を備える。更に、制御ノードは、確立された伝送媒体を介してドメインにおけるサービス参加者にマルチキャストデータを配信する送信器を備える。

別の実施形態では、上記制御ノードは、上述の実施形態のいずれかにしたがって、異なるドメインにマルチキャストサービスのマルチキャストデータを配信する方法、または、ドメイン内のサービス参加者にマルチキャストサービスのマルチキャストデータを配信する方法のステップを実行するよう適合される手段を更に備える。

本発明の別の実施形態は、本発明の一つの典型的な実施形態による制御ノードを少なくとも一つ備える、システムを提供する。

更に、別の実施形態による本発明は、異なるドメインの第１のドメインの制御ノードのプロセッサによって実行されると、制御ノードに、マルチキャストサービスのマルチキャストデータを異なるドメインに配信させる命令を記憶するコンピュータ読取可能媒体を提供する。制御ノードは、マルチキャストサービスに参加するサービス参加者を識別するサービス開始要求を受信し、サービス参加者の識別に基づき、サービス参加者が属し、且つ、第１のドメインの制御ノードによって制御されないドメインを識別し、ドメイン毎に識別されたドメインの制御ノードにマルチキャストデータを配信することで、マルチキャストデータを配信する。

本発明の更なる実施形態によると、ドメインの制御ノードによって実行されると、制御ノードに、ドメインにおけるサービス参加者にマルチキャストサービスのマルチキャストデータを配信させる命令を記憶するコンピュータ読取可能媒体を提供する。制御ノードは、制御ノードによって制御されるドメインに位置するマルチキャストサービスに参加するサービス参加者に関する情報を含む別のドメインの制御ノードからのサービス開始要求を受信し、ドメイン内でマルチキャストデータを配信するためにポイントトゥポイントリンクを利用するかポイントトゥマルチポイントリンクを利用するかを、サービス参加者に関する情報に基づいて判断し、判断に依存して、ドメインにおけるサービス参加者それぞれにポイントトゥポイントまたはドメインにおけるサービス参加者にポイントトゥマルチポイントを、マルチキャストデータの伝送媒体として確立し、確立された伝送媒体を介してドメインにおけるサービス参加者にマルチキャストデータを配信することで、サービス参加者にマルチキャストサービスのマルチキャストデータを配信する。

別の実施形態は、第１のドメインの制御ノードによって実行されると、上述の実施形態のいずれかにしたがって、異なるドメインにマルチキャストサービスのマルチキャストデータを配信する方法、または、ドメイン内のサービス参加者にマルチキャストサービスのマルチキャストデータを配信する方法のステップを制御ノードに実行させる命令を更に記憶するコンピュータ読取可能媒体に関する。

以下に、本発明を添付の図面を参照してより詳細に説明する。図中、同様のまたは対応する詳細には同じ符号が付与される。

以下に、ＭＢＭＳ対応３ＧＰＰ無線ネットワークを介してＩＭＳネットワークインフラストラクチャ内のＰｏＣマルチキャストサービスに部分的に関連する、本発明の様々な実施形態を説明する。典型的且つ具体的な実施形態は、本発明の基礎となる思想をこれら具体的な実施形態に限定することを意図しないことは理解されるべきである。背景技術におけるより詳細な情報は、本発明の原則が適用される可能なネットワークアーキテクチャおよびシナリオを例示することを目的とする。

本発明の思想は、中央エレメントがサービス通信を制御する中央型アプローチを使用するマルチキャストサービスに特に適用可能である。本発明の主な思想の一つは、中央型アプローチの代わりに分散型アプローチ、特に、マルチキャストサービス制御並びにマルチサービスデータの分散の機能を使用することである。中央制御エレメントによって典型的には実施されるある機能はドメインレベルで分散され、つまり、ドメインレベルでより効率的に扱われる機能はマルチキャストサービスを受信するサービス参加者が位置するドメインそれぞれの制御ノードに分散される。該思想の別の態様は、制御ノードが新しい機能を実行するに必要な情報の交換に関わる。

以下に説明する典型的な実施形態からより明らかになるように、ドメインレベルに機能性を分散することにより、シグナリングオーバーヘッドを減少し、ドメインの制御ノード間並びにドメイン内でリソースの利用を最適化することができる。

本願記載の本発明の様々な実施形態による解決策が、例えば、サービス参加者が異なる管理ドメインに属するＰｏＣ等のＩＭＳサービスに有利に使用されることが理解されるであろう。本願の意味の範囲でのドメインは、共通の規則および手順でユニットとして管理されるネットワーク上のコンピュータや装置のグループである。通常は、該ネットワーク上の全ての装置は、特定のネットワークオペレータによって所有され、維持される。

従来のＰｏＣサービスの二つの主な欠点は、本願で特定されている。第１に、制御ＰｏＣ ＡＳは、ＰｏＣサービスデータが分散されるべき他のドメイン内で利用可能な伝送能力について知識が全くない点である。これは、シグナリング負荷の増加や制御ＰｏＣ ＡＳと参加ＰｏＣ ＡＳとの間のインターフェースのサービスデータ負荷につながる。

第２に、参加ＰｏＣ ＡＳは、自身のドメインにおけるサービス参加者について知識が全くないため（あるいは、よくても、信頼性は高くないが送られてきたＳＩＰシグナリングから該情報を導出する）、参加ＰｏＣ ＡＳがドメインにおいてＰｏＣサービスデータを分散するためにそれぞれのドメイン内で最適な伝送機構を選択することが（不可能ではないにしても）困難な点である。ドメインにおけるサービス参加者を認識していないため、参加ＰｏＣ ＡＳ制御されたドメインにおいてサービスデータを分散するために「高価な」リソースを消費するポイントトゥポイントリンクが使用されるか、同一のサービスデータの幾つかのコピーがサービス参加者にマルチキャストサービスを介して提供される。

これらの欠点は、上述のＰｏＣサービスと同様の中央型アプローチを使用するマルチキャストサービスに一般化される。

第１の欠点に取り組むために、本発明の一実施形態は、第１のドメインにおいてサービス開始要求を受信する制御ノードが、サービス参加者が位置するドメインを決定し、サービスのマルチキャストデータをドメイン毎に（参加者毎ではなく）他の決定されたドメインの制御ノードに配信することを提案する。

この考え方は、以下で図１および図４を参照してより詳細に説明する。図１は、本発明の実施形態による、サービス参加者にドメイン間マルチキャストサービスのデータを提供する典型的なオーバーレイネットワークを示す図である。図４は、本発明の典型的な実施形態による、異なるドメインの制御ノード間でのシグナリングおよびデータ転送を示す図である。

例示目的として、マルチキャストサービスの設定がクライアント１００によって要求されたと仮定する。クライアント１００は、その制御ノード、つまり、本例ではドメイン＃１の制御ノード１１０にサービス開始要求を送信する。サービス開始要求は、サービスに参加する潜在的なサービス参加者を識別する。

サービス参加者の識別は、個々のサービス参加者を識別する固有のＩＤによって実現される。代替的には、グループまたはリストに属するユーザの適当な識別を含むグループまたはリストが予め構成されてもよい。それぞれのグループまたはリストは、潜在的なサービス参加者を識別するためにクライアント１００によって使用され得るＩＤが個別に割り当てられてもよい。

例えば、サービス設定にＳＩＰをシグナリングプロトコルとして使用する場合、該サービス開始要求は、とりわけ、マルチキャストサービスに参加するサービス参加者を識別するＳＩＰ ＩＮＶＩＴＥメッセージでもよい。典型的には、ＳＩＰ ＵＲＩが参加者を識別するために使用され得る。ＳＩＰプロトコルおよびメッセージフォーマットに関する詳細は、本願で参照として組み込むｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇから入手可能な非特許文献６に記載されている。更に、ＳＩＰメッセージのサイズを減少するために、本願で参照として組み込む非特許文献７に記載のシグナリング圧縮が使用されてもよい。

制御ノード１１０は、サービス開始要求を受信し（ステップ４０１）、要求に示される様々なサービス参加者が属するドメインを決定する（ステップ４０２）。一般的に、クライアント１００からの要求が一人以上のサービス参加者を示す、つまり、サービスに少なくとも二人のユーザが参加することで十分であることに注意する。

図１に示す例では、サービス開始要求がクライアント（サービス参加者）１０１から１０６を識別すると仮定する。したがって、制御ノード１１０は、参加者１０１は自身のドメイン＃１に属し、参加者１０２および１０３、並びに、参加者１０４、１０５、および、１０６はそれぞれドメイン＃２およびドメイン＃３に属すると決定する（４０２）。

例えば、サービス参加者の識別子としてＳＩＲ ＵＲＩを使用する場合、省略されていないドメイン名または数字のＩＰｖ４またはＩＰｖ６アドレスのいずれかを含むＳＩＰ ＵＲＩのホスト部から異なるドメインが決定される。ＳＩＰ ＵＲＩ「ｊｏｅ＠ｅｘａｍｐｌｅ．ｃｏｍ」のドメインは、「ｅｘａｍｐｌｅ．ｃｏｍ」に決定される。

次に、制御ノード１１０は、本例ではドメイン＃２およびドメイン＃３である識別されたドメインにサーブする制御ノード（ここでは、制御ノード１１１および１１２）を識別する（４０３）。

異なるドメインの制御ノードの識別は、様々な方法で実現される。例えば、制御ノード１１０は、他のドメインにおける制御ノードの予め構成されたリストを使用してもよい。あるいは、制御ノード１１０は、該情報を、他のドメインとの先の（シグナリング）通信から導出してもよい。別のオプションとしては、「ＣｏｎｆｅｒｅｎｃｅＦａｃｔｏｒｙ＠ｅｘａｍｐｌｅ．ｃｏｍ」等、サービスを開始するためにサービス参加者によって使用され得る幾らかの周知の名前を制御ノードに使用することである。

ドメイン＃２と＃３の制御ノード１１１と１１２を識別した後、制御ノード１１０は、各制御ノード１１１および１１２にサービス開始要求メッセージを任意に送ってもよい。制御ノード１１１および１１２に送られる各サービス開始要求メッセージそれぞれは、それぞれの制御ノードによって制御されているドメインにおけるサービス参加者を識別する、つまり、制御ノード１１２に送信される要求メッセージにおいてサービス参加者１０２および１０３、制御ノード１１１に送信される要求メッセージにおいてサービス参加者１０４、１０５、および、１０６を識別する。以下により詳細に説明するように、制御ノードのサービス開始要求メッセージは、マルチキャストサービスを確立するよう個々のサービス開始要求をドメイン内の個々の示されるサービス参加者に送られてもよい。

原則として、制御ノード１１０は、ドメイン毎のレベルでマルチキャストデータを配信するよう潜在的なサービス参加者が位置する異なるドメインを識別するだけでよい。サービス参加者（例えば、クライアント１００）に配信されるべきマルチキャストデータを受信すると（４０６）、制御ノード１１０は、データの個々のコピーを生成してサービス参加者に提供するために他のドメインの制御ノードに参加者毎に提供する代わりに、「識別された」ドメインの制御ノード１１１および１１２にサービスデータを配信してもよい（４０７、４０８）。

結果として、マルチキャストデータの一つのコピーだけが識別されたドメインそれぞれに送られるため、マルチキャストデータが提供されるべき異なるドメインを識別することにより、マルチキャストデータ配信による（シグナリングによる）負荷が減少される。

前述し、図５を参照して説明するように、あるドメイン内のサービス参加者の識別をそれぞれのドメインの制御ノードに提供することも有利である（図４のステップ４０４、４０５）。厳密に言えば、参加者がセッションに招待されなくてもよい、および／または、サービスのシステムリソースを通知される必要がないドメインでは、識別は不要である。それにも関わらず、本発明の各種実施形態では、サービス参加者の識別はサービス開始要求に含まれる（ステップ４０４、４０５）。

図５は、本発明の典型的な実施形態によるドメイン間マルチキャストサービスを可能にするドメイン内の制御ノードの典型的な動作を示す図である。例示目的として、図５の制御ノードは、図４の制御ノードおよび図１の制御ノード１１１に対応すると仮定する。

サービス開始要求を受信すると（４０４）、制御ノードは、制御ノード１１１によって先に受信されたサービス開始要求に示される各サービス参加者に対して個々のサービス開始要求を生成してもよい。生成された少なくとも一つのサービス開始メッセージは、ドメイン＃２のサービス参加者１０４、１０５、および、１０６に送信される（５０１）。

例えば、サービスを設定する際にシグナリングプロトコルとしてＳＩＰを使用する場合、開始要求メッセージはＳＩＰ ＩＮＶＩＴＥメッセージでもよい。参加者は、サービス開始メッセージに応答して、承認メッセージで返答する。制御ノード１１１と個々の参加者との間でドメイン＃２内で局所的にサービスが確立されている場合、制御ノード１１１は、そのサービス開始要求に対する応答を取り扱う。さもなければ、サービスセッションがドメイン＃１の制御ノード１１０とドメイン＃２内のサービス参加者との間で確立されている場合、制御ノード１１１は、そのドメインにおけるサービス参加者１０４、１０５、および、１０６からの応答をドメイン＃１の制御ノード１１０に送る。

更に、ドメイン＃２の制御ノード１１１は、サービス参加者１０４、１０５、および、１０６にマルチキャストサービスデータを配信するためにドメイン内で使用される配信方法を決定する（５０２）。サービス開始要求はドメインにおけるサービス参加者に関する情報を含むため、制御ノード１１１は該情報からドメインにおけるサービス参加者の数を導出してもよい。

一般的に、制御ノード１１１は、サービス参加者１０４、１０５、および、１０６にサービスデータを提供するためにポイントトゥポイントリンク（例えば、個別の伝送チャネルまたは接続）が使用されているかを判断する。あるいは、該目的に対してポイントトゥマルチポイントリンク（例えば、共有または共通の伝送チャネル）が使用されてもよい。これら二つの伝送方法のいずれを選択するかは、ドメイン内の有線および／またはエアインターフェースの電流負荷、ドメインまたは無線ネットワークサブシステムにおいてマルチキャストサービスを受信するサービス参加者の数等に依存する。適当な判断基準を得るためには、無線リソース情報が制御ノード１１１に（あるいは、マルチキャストサービスセンター３０１にドメイン特有のマルチキャストサービス伝送機構を使用する場合）利用可能であってもよい。例えば、サービスユーザ数が所与のあるいは定められた閾値を超える場合、制御ノード１１１は、ポイントトゥマルチポイントリンクを使用すると判断し、さもなければ個々のポイントトゥポイントリンクを使用する。

サービス提供中にサービス参加者数が変動する場合、配信方法はイベントをトリガーとして（例えば、参加者の参加／退散、他の無線ネットワークサブシステムまたはネットワークへの参加者のハンドオーバ等の際）または定期的に再評価される。この評価により別の伝送機構を使用する方がより効率的であると示されると、制御ノード１１１は必要であればポイントトゥポイントリンクからポイントトゥマルチポイントリンクに、あるいはその逆に、伝送機構を切り換える。

いずれの伝送機構を使用するか判断した後、ドメイン＃２において適当なリソースが確立される。例えば、ポイントトゥポイントリンクが使用される場合、制御ノード１１１は個々のサービス参加者１０４、１０５、および、１０６への個別のチャネルまたは接続の確立を開始し得る。ポイントトゥマルチポイントリンクが使用される場合、参加者１０４、１０５、および、１０６にサービス提供するために共通のまたは共有のチャネルが確立され得る。

ポイントトゥマルチポイントリンクを確立する別の方法は、ドメインにおいて既に設けられているマルチキャストサービス伝送機構を利用する方法である。このために、マルチキャストサービスセンター３０１が設けられてもよい。マルチキャストサービスセンター３０１は、ポイントトゥマルチポイントリンク接続を利用するドメイン内のユーザにマルチキャストサービスを提供する機能を担うドメインにおける機能的または物理的エンティティである。マルチキャストサービスセンターが機能的エンティティである場合、制御ノード１１１と同じネットワークエレメント内に位置してもよい。マルチキャストサービス機構の例は、３ＧＰＰネットワークのＭＢＭＳであり、この場合、マルチキャストサービスセンター３０１はＢＭ−ＳＣに対応する。

マルチキャストサービス伝送機構を提供するドメインの典型的な構造上の概観を図３に示す。図３は、ドメイン＃２以外では図１に対応し、マルチキャストサービスセンター３０１が含まれる。

制御ノード１１１においてサービスのマルチキャストデータを受信すると（４０７）、制御ノード１１１はドメイン内のサービス参加者１０４、１０５、および、１０６にマルチキャストデータを配信する（５０４）。ここで、ポイントトゥポイントリンクが使用される場合のみ、制御ノード１１１が配信用にマルチキャストデータのコピーを生成する必要があることに注意する。

図１および図３に戻ると、ドメイン＃３の制御ノード１１２の動作は、ドメイン＃２の制御ノード１１１の動作と同様である。更に、ドメイン＃２および＃３における制御ノード１１１および１１２が、クライアントから最初のサービス開始要求を受信した場合にはドメイン＃１の制御ノード１１０の動作を実行することができることに注意する。同様にして、ドメイン＃１の制御ノード１１０は後者の場合にドメイン＃２の制御ノード１１１の機能を実行してもよい。

図５に概要を説明した本発明の一実施形態では、どの伝送機構を利用するかは、ドメイン＃２全体に対して制御ノード１１１によって判断されている。しかしながら、以下に説明するように、この判断や伝送機構間の切り換えは、以下のように無線ネットワークサブシステム毎に行われてもよい。

図２は、本発明の実施形態による図１の異なるドメインの一つのネットワークアーキテクチャの典型的な概観図である。図２では、ドメイン＃２が３ＧＰＰネットワーク、例えば、ＧＧＳＮ２０１によりなるコアネットワークと少なくとも一つのＳＧＳＮ２０２（ＧＧＳＮ＝ゲートウェイＧＰＲＳサポートノード；ＳＧＳＮ＝サービングＧＰＲＳサポートノード）を備えるＵＭＴＳであると仮定される。無線アクセスネットワークは、ＳＧＳＮ２０２と無線アクセスネットワークのそれぞれのＲＮＣ２１０、２１１（無線ネットワークコントローラ）との間のインターフェースを介してコアネットワークに接続される。各ＲＮＣは、移動端末１０４、１０５、１０６とデータを送受信する一つ以上のノードＢ２１５、２１６、および、２１７と典型的には接続される。

現在のＵＭＴＳシステムでは、ＲＮＣ２１０、２１１は、無線リソース制御を終了するため、エアインターフェースリソースの確立や制御の機能も担う。これに関して、ＲＮＣ２１０、２１１はサービス参加者１０４、１０５、および、１０６にポイントトゥポイントリンクおよび／またはポイントトゥマルチポイントリンクも確立する。ＵＭＴＳネットワークにおいてＭＢＭＳサービスが利用可能である場合（アーキテクチャにおいてＢＭ−ＳＣ２００によって示される）、ＲＮＣはそれぞれのノードＢによって制御されている各無線セルに対して端末にポイントトゥマルチポイントリンクを確立する。

従って、本アーキテクチャでは、各無線セルに対して、マルチキャストサービスデータの配信用に利用する伝送機構を判断することが有利である。本発明の本実施形態では、無線ネットワークサブシステムは、ノードＢによって制御される無線セルに対応する。したがって、マルチキャストデータの配信用のシステムリソースは、個々のセル内でマルチキャストサービスを現在受信しているユーザ数によって切り換えられてもよい。

本発明の代替的な実施形態では、伝送機構に対する判断は、無線ネットワークサブシステム毎に行われてもよく、このとき、無線ネットワークサブシステムはＲＮＣおよびその制御下にあるノードＢ（例えば、ＲＮＣ２１０とノードＢ２１５および２１６）として定義される。同様にして、サービス提供中の利用する伝送機構の切り替えは、無線ネットワークサブシステムレベルで行われてもよい。

図６は、本発明の典型的な実施形態によるドメイン間マルチキャストサービスを可能にするドメイン＃２内の制御ノード１１１の更なる典型的な動作を示す。図６に典型的には例示される実施形態では、ドメイン＃２内のマルチキャストサービスデータの配信にどの伝送機構を利用するかは無線ネットワークサブシステム毎に判断される。

図５に示すように、制御ノード１１１は最初に、ドメイン＃２に位置するサービス参加者を示すサービス開始要求を受信し（４０４）、サービス参加者１０４、１０５、および、１０６に送信する（５０１）ために個々のサービス開始要求を生成し得る。

サービス参加者の識別に基づき、ドメイン＃２の制御ノード１１１は示された参加者がどの無線ネットワークサブシステムに属するかを判断する（６０１）。

例えば、無線ネットワークサブシステムは、無線セルレベルで定義されてもよく、この場合、制御ノード１１１は、サービス参加者１０４がノードＢ２１６によってサービングされ、サービス参加者１０５および１０６がノードＢ２１５によってサービスされていると判断する。

この結果に基づき、制御ノード１１１は、決定された無線ネットワークサブシステムそれぞれにどの伝送機構を利用するかを判断する（６０２）。例えば、この判断は、上記した通り、決定された無線ネットワークサブシステムそれぞれにおけるサービス参加者の数に基づく。該判断により、制御ノード１１１はドメインにおいて適当なリソースを更に確立する（６０３）。

例えば、参加者１０５および１０６が、ポイントトゥポイントリンクを介してサービングされるべきと判断された場合、制御ノード１１１は、このためにノードＢ２１５によって制御される無線セルに共有のまたは共通のチャネルを確立してもよい。ドメイン特有のマルチキャストサービス伝送機構を利用する場合、制御ノード１１１は、マルチキャストサービスセンター３０１を介してダウンリンクマルチキャストサービス提供を開始し、ポイントトゥマルチポイントリンクを介して参加者１０５および１０６に配信するためにマルチキャストサービスセンター３０１にマルチキャストデータを転送してもよい。

マルチキャストサービス伝送機構としてＭＢＭＳサービス機能を使用する場合、本例ではＩＭＳアプリケーションサーバまたはＰｏＣアプリケーションサーバに該当する制御ノード１１１は、参加者１０５および１０６に対してＭＢＭＳを開始する。この手順では、制御ノード１１１は、参加者１０５および１０６をＢＭ−ＳＣ２００に登録し、ＢＭ−ＳＣ２００によって確立されたＭＢＭＳサービスのマルチキャスト識別子（例えば、ＩＰマルチキャストアドレス）を取得する。マルチキャスト識別子は、参加者１０５および１０６に送信されるサービス開始要求に含まれてもよく、マルチキャストデータを参加者に提供するリソースが識別される。

参加者１０４に対しては、制御ノード１１１はマルチキャストサービスにポイントトゥポイントリンクを使用すると判断する。したがって、参加者１０４に個別チャネルが確立される。

制御ノード１１１はマルチキャストデータを受信すると（４０７）、確立されたリンクを利用してドメインにおける参加者にマルチキャストサービスを送る。

制御ノード１１１とマルチキャストサービスセンター３０１を備えるネットワークの動作方法（伝送機構の判断方法やその条件付切換を含む）の更なる詳細は、本発明の出願人による、同時係属出願中のEP06001019.6 "EFFICIENT MULTICAST SERVICE DATA PROVISION IN A MOBILE COMMUNICATION SYSTEM"（本願で参照として組み込む）およびEP06004868.3 "EFFICIENT PROVISION OF A MULTICAST SERVICE BY SWITCHING BETWEEN MULTICAST SERVICES IN A MOBILE COMMUNICATION SYSTEM"（本願で参照として組み込む）に記載される。これらの文献では、制御ノードはＩＭＳアプリケーションサーバ／ＰｏＣ ＡＳに対応し、マルチキャストサービスセンターはＢＭ−ＳＣに対応する。

以下では、本発明のより詳細な実施形態を、マルチキャストサービスの例示的な実施例としてＰｏＣサービスを用いて概略的に説明する。図８は、本発明の典型的な実施形態によるＭＢＭＳ対応移動通信システムにおけるドメイン間ＰｏＣサービスの実現への本発明の原理の典型的な適用を示す。

上述の通り、本発明の一態様は、異なるドメインのノード間で機能性を配信することである。この考えが適用されるＰｏＣ呼び出しでは、呼の設定やセッションの確立等の制御ＰｏＣによって典型的には実行されるある機能性が、ＰｏＣ呼び出しに伴われる異なるドメインにおけるＰｏＣ ＡＳに配信されることを意味する。

機能性の配信を容易化するためには、制御ＰｏＣ ＡＳは、要求される対象ドメインにおける全ての参加ＰｏＣ ＡＳとシグナリングダイアログを確立してもよい。このダイアログ内では、制御ＰｏＣ ＡＳは、参加ＰｏＣ ＡＳにそれぞれのユーザグループ情報を配信し、異なるドメインにおけるエレメント間で単一の個別接続を確立する（ＩＮＶＩＴＥ ＰｏＣ−Ｂ ［ｕｓｅｒ ｌｉｓｔ＠Ｄｏｍａｉｎ Ｂ］）。

各参加ＰｏＣ ＡＳは、ＭＢＭＳ伝送機能性の利用を含みＰｏＣ呼び出しデータの送信戦略（例えば、図８に示すＢＭ−ＳＣによるＭＢＭＳサービスを介したトークバーストの転送か否か）を局所的に判断し、呼の設定要求（ＩＮＶＩＴＥ ＵＥ−Ｂ１， …， ＩＮＶＩＴＥ ＵＥ−Ｂｎ）を処理する機能を担う。

その後、制御ＰｏＣ ＡＳは、各対象ドメイン（ＰｏＣ−Ａ乃至ＰｏＣ−Ｂから送信されるトークバースト）に単一の個別接続を介して一度だけ到来する音声データを送信してもよい。ローカル参加ＰｏＣ ＡＳは、それぞれの参加者にデータを配信する機能を担う。ＭＢＭＳ伝送機能性が利用されう場合、参加ＰｏＣ ＡＳは、音声データ（トークバースト）の単一のコピーをＢＭ−ＳＣに送る。

それにより、多数の音声データのコピーの不要な送信が回避される。更なる利点は、参加ＰｏＣ ＡＳにおいて即時に信頼性の高いユーザグループ情報が利用可能であるため、ＰｏＣ呼び出しに対するＭＢＭＳ利用の判断が向上し得る点である。

図８に関連して説明した方法の変形例では、開始するＰｏＣユーザ（ＵＥ−Ａ）は、そのＳＩＰ ＩＮＶＩＴＥ要求において呼に対する所望の参加者を特定する。該メッセージを受信すると、制御ＰｏＣ ＡＳは、リストを検討して、各ドメインに対してサブリストにグループ化する等、ドメインに応じて要求されるユーザをグループ化する。各ユーザそれぞれにシグナリングする代わりに、制御ＰｏＣ ＡＳは、生成されたサブリストを含む単一のＳＩＰ ＩＮＶＩＴＥ要求をそれぞれのドメインにおけるＰｏＣ ＡＳに発信する。制御ＰｏＣ ＡＳは、対象ドメインにおけるＰｏＣ ＡＳを直接的にアドレス指定するために周知のアイデンティティあるいは先に取得した情報を使用してもよい。

対象ドメインにおける参加ＰｏＣ ＡＳにおいて該メッセージを受信すると、参加ＰｏＣ ＡＳは、要求が別のドメインにおける別のＰｏＣ ＡＳから受信されたため、標準的な参加ＰｏＣ機能の代わりに制御ＰｏＣ機能を実行しなくてはならないと判断する。参加ＰｏＣ ＡＳは、取得したグループ情報を使用して要求されるＰｏＣユーザにシグナリングし、適当なＳＩＰ ＩＮＶＩＴＥメッセージを生成する。更に、参加ＰｏＣ ＡＳは、要求されたＰｏＣ呼び出しに対してＭＢＭＳ伝送機能性を利用するか否かの判断においてグループ情報を使用してもよい。

参加ＰｏＣ ＡＳは、他のドメインにおける制御ＰｏＣ ＡＳに適当なＳＩＰ応答を送り返す。これは、制御ＰｏＣ ＡＳに対するそれぞれのＳＩＰ ＩＮＶＩＴＥ要求を受信した直後、または、ローカルドメインにおけるシグナリングされたＰｏＣユーザから全ての応答を受信した後に行われる。この挙動は、参加ＰｏＣ ＡＳの特定の実行による場合もある。いずれの場合でも、制御ＰｏＣ ＡＳとのＳＩＰダイアログの完了が成功すると、異なるドメインにおけるＰｏＣ ＡＳ間のメディア送信用に単一の個別接続が結果として確立される。

この手順は、制御ＰｏＣ ＡＳにおいて受信された開始要求のユーザグループ情報にあるどの対象ドメインに対しても実行される。その結果、制御ＰｏＣ ＡＳと異なるドメインにおける参加ＰｏＣ ＡＳとの間で幾つかの個別接続が存在する場合もある。制御ＰｏＣ ＡＳがＰｏＣユーザから音声データを受信すると、制御ＰｏＣ ＡＳは関連する参加ＰｏＣ ＡＳに丁度一度だけデータを配信するために個別接続を利用する。対象ドメインにおけるＭＢＭＳの利用を考えると、参加ＰｏＣ ＡＳは、音声データの一つのコピーをＢＭ−ＳＣに送り、ＢＭ−ＳＣはそれをローカルドメインにおけるＰｏＣユーザにＭＢＭＳベアラを介して送信する。従って、全てのＰｏＣユーザが一度だけ音声データを受信し、同じデータの多数のコピーの不要な送信が回避される。

図７は、本発明の典型的な実施形態によるＭＢＭＳ対応移動通信システムにおけるＰｏＣサービスを確立する信号図を示す。例示目的として、二つのドメインにわたるサービスが仮定される（本原理は幾つかのドメインにわたるサービスに適用可能である）。第１のドメインＡでは、ＰｏＣユーザ（ＵＥ−Ａ）がドメインＢ（ＵＥ−Ｂ）における少なくとも一つの参加者にサービスを開始する。

シグナリングの流れ、対象ドメインにおける単一のＰｏＣユーザ（ＵＥ−Ｂ）を典型的には示す。しかしながら、一般的なケースでは、任意の数の要求される参加者をホストする多数の異なる対象ドメインが存在してもよい。更に、シグナリングの流れについて、ＰｏＣユーザがそれぞれのローカルＩＭＳネットワークにアクセスするためにＧＰＲＳベースのＩＰ−ＣＡＮを利用し、対象ドメインはＭＢＭＳ伝送機能性をサポートする。ＩＭＳネットワークへのアクセスに関して、開始するユーザはＧＰＲＳを使用する必要はなく、それぞれのＩＭＳネットワークへのアクセスを提供する限り任意のＩＰ−ＣＡＮが使用され得る。

ユーザ（ＵＥ−Ａ）にまだどのＩＰアドレスも割り当てられていない場合、ＩＭＳ関連のシグナリングに好適なＰＤＰコンテキスト、更に必要な場合には、同じＡＰＮ（アクセス点名）およびＩＰアドレスの追加的な汎用ＰＤＰコンテキストが、ＩＭＳ関連のシグナリングのＰＤＰコンテキストとして確立されることが確実になる。

端末（ＵＥ−Ａ）は、最初のＩＭＳネットワークに自身を登録する（ステップ１）。この登録は、全てのＩＭＳサービスにアクセス可能になるための必須条件である。ユーザ（ＵＥ−Ａ）がＰｏＣ呼び出しを開始することを好む場合、ユーザ（ＵＥ−Ａ）は、本例ではＵＥ−Ｂを宛先アドレスとして（代替的には、宛先アドレスはＰｏＣグループセッションに対してＰｏＣサーバによってホストされるＰＳＩ（公共サービスアイデンティティ）でもよい）ドメインＡ（ＰｏＣ−Ａ）の制御ＰｏＣ ＡＳに送られる、ＩＭＳコア（Ａ）にＩＮＶＩＴＥ要求を送る（ステップ２）ことで、ＰｏＣ通信に対してＳＩＰセッションを作成する。

ＩＮＶＩＴＥ要求は、ＰｏＣサービス表示を含み、そのＳＤＰメディアパラメータはＰＤＰコンテキストを確立した際に得られるＩＰアドレスやＵＥ−Ａがメディアを送受信する準備ができたことを示す（本例では、ＩＭＳ登録時のトークバースト制御およびメディアに対してＵＥ−ＡがノンリアルタイムＰＤＰコンテキストを確立すると仮定する）。アドホックグループに対して、ＩＮＶＩＴＥ要求は、更に呼び出しに対する要求されるユーザのリストを含む。ＩＭＳネットワーク（Ａ）を介してＰｏＣ ＡＳ（ＰｏＣ−Ａ）にルーティングされる（ステップ３および４）。

ＳＩＰ ＩＮＶＩＴＥメッセージを受信すると、ＰｏＣ ＡＳは、制御ＰｏＣ機能を実行し、本発明の本実施形態によると、受信したユーザリストを対象ドメイン毎にグループ化する（ステップ５）。

次のステップでは、制御ＰｏＣ ＡＳ（ＰｏＣ−Ａ）は、対応するドメインの要求されるユーザのリストを含む、対象ドメイン（ＰｏＣ−Ｂ）におけるＰｏＣ ＡＳ向けのＳＩＰ ＩＮＶＩＴＥメッセージを生成する。このメッセージは、ローカルＩＭＳネットワークに送られ、その後、対象ドメインにおけるＩＭＳネットワークを介して所望のＰｏＣ ＡＳにルーティングされる（ステップ６乃至８）。従来のシステムでは、ＩＮＶＩＴＥメッセージを受信したＰｏＣ ＡＳは、参加ＰｏＣ機能を実行する。しかしながら、別のドメインにおける別のＰｏＣ ＡＳからＩＮＶＩＴＥメッセージが送られたことが該メッセージから認識されるため、ドメインＢのＰｏＣ ＡＳは呼の設定やセッションの確立に関して制御ＰｏＣ機能を実行すべきと認識する。

従って、参加ＰｏＣ ＡＳ（ＰｏＣ−Ｂ）は、制御ＰｏＣ ＡＳ（ＰｏＣ−Ａ）からの受信したメッセージに列挙される各ユーザに対してＳＩＰ ＩＮＶＩＴＥメッセージを生成する。該ドメインがＭＢＭＳ伝送機能性をサポートするため、参加ＰｏＣ ＡＳは信頼性の高いグループ情報を用いてＰｏＣ呼び出しに利用するか否かを判断する（ステップ９）。

図示するシグナリングの流れについて、例示目的として、参加ＰｏＣ ＡＳ（ＰｏＣ−Ｂ）が既存のＭＢＭＳ伝送機能性を利用する。したがって、生成されたＳＩＰ ＩＮＶＩＴＥメッセージは、ＭＢＭＳユーザサービス記述等に含まれるＭＢＭＳベアラの構成パラメータを含む。参加ＰｏＣ ＡＳ（ＰｏＣ−Ｂ）からメッセージを受信するドメインＢにおけるＰｏＣユーザは、適当な応答を返し、ＧＰＲＳネットワークにおいて対応するＭＢＭＳベアラをアクティブにする。端末がＭＢＭＳベアラの受信をサポートすることができない場合、参加ＰｏＣ ＡＳ（ＰｏＣ−Ｂ）にエラーメッセージを送り、ＰｏＣ ＡＳ（ＰｏＣ−Ｂ）は該ＰｏＣユーザに対してポイントトゥポイントリンクを設定する。この手順（ステップ１０乃至１４）は、参加ＰｏＣ ＡＳ（ＰｏＣ−Ｂ）のローカルドメインにおける要求される参加者それぞれに対して行われる。

参加ＰｏＣ ＡＳ（ＰｏＣ−Ｂ）は、制御ＰｏＣ ＡＳ（ＰｏＣ−Ａ）から受信したＳＩＰ ＩＮＶＩＴＥ要求に対して適当な応答を返す（ステップ１５乃至１７）。参加ＰｏＣ ＡＳ（ＰｏＣ−Ｂ）の実行によっては、ＰｏＣユーザから全ての応答が受信された後、または、最初の応答に対して既に行われてもよい。いずれの場合でも、参加ＰｏＣ ＡＳ（ＰｏＣ−Ｂ）から制御ＰｏＣ ＡＳ（ＰｏＣ−Ａ）の肯定応答により、二つのエレメント間で単一の個別接続が確立される。この接続は、音声データの単一のコピーを交換するためや、異なるドメインにおけるＰｏＣ ＡＳ間のインバンドシグナリングにその後使用される（ステップ２４および３４）。最後に、参加ＰｏＣ ＡＳ（ＰｏＣ−Ｂ）は、制御ＰｏＣ ＡＳから受信した音声データを関連するＢＭ−ＳＣに送り、ＢＭ−ＳＣはローカルドメインにおけるＰｏＣユーザに確立されたＭＢＭＳベアラを介して送る（ステップ３５および３６）。

上述の本発明の様々な実施形態による方法およびシステムは、マルチキャストセッションに伴われる異なるドメインにおける制御ノードが、本願に記載するように、改良された適用法やアイデアや機能の向上をサポートすると仮定している。

既に述べたとおり、マルチキャストサービスは異なるオペレータの制御下にある様々なドメインにわたってもよい。したがって、全てのオペレータがそれぞれのローカルドメインで本願記載の改良型の機能性を実行したと仮定される。

例えば、単一のオペレータがそのＰｏＣ ＡＳにおいて配信された制御ＰｏＣ機能性をサポートしない場合もある。更に、様々な理由により、ＭＢＭＳ伝送機能性が全てのドメインで利用可能であることは仮定できない。ＰｏＣ ＡＳにどのＢＭ−ＳＣも配置されないまたは関連付けられないこともあり、既存のＢＭ−ＳＣがＰｏＣ呼び足しに対して要求されるリソースを提供しないこともある。

従って、従来の制御ノードをサポートすることや、特定のマルチキャストサービス伝送機能性を有することなくドメインをサポートすることが望ましい。

図９は、本発明の典型的な実施形態により動作していない制御ノードへの後方互換性を維持しながら、本発明の典型的な実施形態によりドメイン間ＰｏＣサービスを設定する際の典型的なシグナリング手順を示している。ドメインＢにおける参加ＰｏＣ ＡＳ（ＰｏＣ−Ｂ）は、最先端のＰｏＣ ＡＳであると仮定する。さらに、例示目的として、どのＭＢＭ伝送機能性もドメインＢにおいて利用可能でないと仮定する。以下の手順は、ＭＢＭＳ伝送機能性がドメインＢにおいて利用可能な場合でも変更されないことに注意する。

制御ＰｏＣ ＡＳは、上述の通り、それぞれのドメインにおけるユーザグループ情報を含む対象ドメインにおけるＰｏＣ ＡＳに向けられる単一のＳＩＰ ＩＮＶＩＴＥメッセージを送る。

改良型呼び出し制御機能性をサポートしない既存のＰｏＣ ＡＳが対象ドメインＢに配置される場合、ＰｏＣ ＡＳ（ＰｏＣ−Ｂ）は適当なエラーメッセージで受信したＳＩＰ ＩＮＶＩＴＥ要求を拒絶する。本発明の本実施形態によると、制御ＰｏＣ ＡＳは、対象ドメインのＰｏＣ ＡＳからエラーメッセージを受信した場合には、標準的なＰｏＣ挙動に応じて各要求されるＰｏＣユーザに向けられる別々のＳＩＰ ＩＮＶＩＴＥメッセージ（ＩＮＶＩＴＥ Ｂ１， …， ＩＮＶＩＴＥ Ｂｎ）を送る。

ＭＢＭＳ伝送機能性のサポートがない改良型ＰｏＣ ＡＳが対象ドメインに配置される場合、要求を取り扱う方法が様々存在する。ＰｏＣ ＡＳは、制御ＰｏＣ機能を実行し、その後に、制御ＰｏＣ ＡＳに通知することなくドメインにおけるＰｏＣユーザに個々のポイントトゥポイントリンクを介して受信した音声データを配信してもよい。ＰｏＣ ＡＳは、そのローカル能力について制御ＰｏＣ ＡＳに通知し、制御ＰｏＣ ＡＳは参加ＰｏＣ ＡＳに個々の接続を確立するか個別接続を確立するか判断し得る。別の選択肢としては、ＰｏＣ ＡＳは上述のように受信した要求を拒絶する。

いずれの場合でも、対象ドメインが改良型呼び出し制御機能性またはＭＢＭＳ伝送機能性をサポートする場合には、最初に要求されるＰｏＣ呼び出しが確立される。

本願の異なる実施形態で記載されるように、配信された制御ノード機能性は、革新的なスキームを用いる、つまり、最初に制御ノードが対象ドメインに単一のサービス開始要求メッセージを送ることで改良型呼び出し制御機能性の利用を試みる。しかしながら、対象ドメインでサポートされない場合に追加的なシグナリングが生ずる。

別の可能性は、反応スキームを使用することである。本発明の他の実施形態による本変形例では、第１のドメインの制御ノードは別のドメインにおける各要求されるサービス参加者に向けられる別個のサービス開始要求を送る。これにより、ドメインの制御ノード間で別個の接続が確立される。サービス参加者が位置する対象ドメインにおける制御ノードが特定のマルチキャスト伝送機能性（例えば、ＭＢＭＳ伝送機能性）の利用をサポートする場合、受信したサービス開始要求メッセージに対して送られる応答メッセージにおいて、特定のマルチキャスト伝送機能性をサポートすることを、要求するソースドメインの制御ノードに通知してもよい。

この情報に基づき、ソースドメインにおける制御ノードは対象ドメインにおけるユーザの集合のリストを生成することができる。サービス参加者から音声データを受信する場合、対象ドメインにおけるサービス参加者への更なる配信に対して対象ドメインの制御ノードに単一のコピーだけを配信する。送信に関して、ソースドメインの制御ノードは前述の確立された接続の一つを選択してもよい。対象ドメインの制御ノードは、ローカルサービス参加者にポイントトゥマルチポイントベアラを介して送信するために対象ドメインのマルチキャストサービスセンターに受信した音声データを転送する。

本発明の実施形態による典型的な動作がＰｏＣサービスに使用されてもよい。ドメインに関する予備知識を有することなく、対象ドメインでサポートされた場合に配信された制御ＰｏＣ機能性だけが利用される。

しかしながら、開始するソースドメインにおける制御ＰｏＣ ＡＳと対象ドメインにおける参加ＰｏＣ ＡＳとの間で個々の（未使用）接続を確立することは本発明の実施形態では欠点として考えられる。更に、参加ＰｏＣ ＡＳは遅延された信頼性の低いユーザグループ情報だけを得ることになる。これにより、参加ＰｏＣ ＡＳにおけるＰｏＣ呼び出しに対するＭＢＭＳ利用の判断が複雑になる。

本発明の別の実施形態は、ハードウェアおよびソフトウェアを用いて上記した様々な実施形態を実行することに関わる。本発明の様々な実施形態がコンピュータ装置（プロセッサ）を用いて実行または実施されることが認識される。演算装置またはプロセッサは、汎用プロセッサ、デジタル信号プロセッサ（ＤＳＰ）、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルアレイ（ＦＰＧＡ）または他のプログラマブル論理装置等である。本発明の様々な実施形態は、これら装置の組み合わせによって実行または具現化されてもよい。

更に、本発明の各種実施形態は、プロセッサによってあるいはハードウェアで直接的に実行されるソフトウェアモジュールを用いて実行されてもよい。ソフトウェアモジュールとハードウェア実行の組み合わせも可能である。ソフトウェアモジュールはＲＡＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリ、レジスタ、ハードディスク、ＣＤ−ＲＯＭ、ＤＶＤ等の全ての種類のコンピュータ読取可能記憶媒体に記憶され得る。

本発明の実施形態による、サービス参加者にドメイン間マルチキャストサービスのデータを提供する典型的なオーバーレイネットワークを示す図 本発明の実施形態による、図１の異なるドメインのうちの一つのドメインにおけるネットワークアーキテクチャの典型的な概略図 本発明の別の実施形態による、サービス参加者にドメイン間マルチキャストサービスのデータを提供する別の典型的なオーバーレイネットワークを示す図 本発明の典型的な実施形態による、異なるドメインの制御ノード間でのシグナリングおよびデータ転送を示す図 本発明の典型的な実施形態によるドメイン間マルチキャストサービスを可能にするドメイン内の制御ノードの典型的な動作を示す図 本発明の典型的な実施形態によるドメイン間マルチキャストサービスを可能にするドメイン内の制御ノードの典型的な動作を示す図 本発明の典型的な実施形態によるＭＢＭＳ対応移動通信システムにおいてＰｏＣサービスを確立する信号図 本発明の典型的な実施形態によるＭＢＭＳ対応移動通信システムにおけるドメイン間ＰｏＣサービスの実現への本発明の原理の典型的な適用を示す図 本発明の典型的な実施形態により動作していない制御ノードへの後方互換性を維持しながら、本発明の典型的な実施形態によりドメイン間ＰｏＣサービスを設定する際の、典型的なシグナリング手順を示す図 ＩＭＳサービスを可能にする典型的なネットワークアーキテクチャを示す図 ＰｏＣ ＩＭＳサービスを可能にする典型的なプロトコルスタックを示す図 ドメイン間ＰｏＣサービスを可能にする典型的なシグナリング手順を示す図

Claims (25)

1. 異なるドメインにマルチキャストサービスのマルチキャストデータを配信する方法であって、前記異なるドメインの第１のドメインの制御ノード（１１０）によって実行される以下のステップ：
   前記マルチキャストサービスに参加するサービス参加者を識別するサービス開始要求を受信するステップ（４０１）と、
   前記サービス参加者の識別に基づき、前記サービス参加者が属し、且つ、前記第１のドメインの前記制御ノードによって制御されないドメインを識別するステップ（４０２）と、
   ドメイン毎に前記識別されたドメインの制御ノードにマルチキャストデータを配信するステップ（４０７，４０８）と、
   を含む方法。
2. 前記識別された前記制御ノードにサービス開始要求を送信するステップ（４０４，４０５）を更に含み、
   制御ノードに送信されるサービス開始要求は前記制御ノードによって制御されるそれぞれのドメインに属するサービス参加者（１０２−１０３、１０４−１０６）を含む、請求項１記載の方法。
3. 前記マルチキャストデータがそれぞれの制御ノードに送られるべき前記識別されたドメインそれぞれの制御ノード（１１１，１１２）にポイントトゥポイントリンクを確立するステップを更に含む、請求項１または請求項２記載の方法。
4. 前記識別されたドメインの前記制御ノード（４１１，４１２）に前記マルチキャストデータを配信する（４０７，４０８）する際、前記マルチキャストデータそれぞれの単一のコピーがそれぞれのドメインの制御ノードにポイントトゥポイントリンクを介して配信され、前記それぞれのドメインの前記サービス参加者に更に配信される、請求項１から請求項３のいずれかに記載の方法。
5. 前記それぞれのマルチキャストデータの単一のコピーは、前記それぞれのドメインに複数のサービス参加者がいる場合でもそれぞれのドメインの制御ノードに配信される、請求項４記載の方法。
6. 前記識別されたドメインのうちの一つの制御ノードからのサービス開始要求に応答して否定応答を受信するステップと、
   前記否定応答に応答して、前記否定応答に応じて前記制御ノードによって制御されるドメインにおけるサービス参加者それぞれに個々のサービス開始要求を送信するステップと、を含む、請求項１から請求項５のいずれかに記載の方法。
7. ドメインにおけるサービス参加者にマルチキャストサービスのマルチキャストデータを配信する方法であって、前記ドメインの制御ノード（１１１，１１２）によって実行される以下のステップ：
   前記制御ノードによって制御されるドメインに位置するマルチキャストサービスに参加する前記サービス参加者に関する情報を含む別のドメインの制御ノードからのサービス開始要求を受信するステップ（４０４）と、
   前記ドメイン内で前記マルチキャストデータを配信するためにポイントトゥポイントリンクを利用するかポイントトゥマルチポイントリンクを利用するかを、前記サービス参加者に関する前記情報に基づいて判断するステップ（５０２）と、
   前記判断に依存して、前記ドメインにおける前記サービス参加者それぞれにポイントトゥポイントまたは前記ドメインにおける前記サービス参加者にポイントトゥマルチポイントを、前記マルチキャストデータの伝送媒体として確立するステップ（５０３）と、
   前記確立された伝送媒体を介して前記ドメインにおける前記サービス参加者に前記マルチキャストデータを配信するステップ（５０４）と、
   を含む方法。
8. 前記サービス参加者にサービングする少なくとも一つの無線ネットワークサブシステムを決定するステップ（６０２）を更に含み、
   前記ポイントトゥポイントリンクまたは前記ポイントトゥマルチポイントリンクの利用に関する判断（６０３）は決定された無線ネットワークサブシステム毎に行われ、
   前記サービス参加者毎のポイントトゥポイントリンクまたはポイントトゥマルチポイントリンクは各決定された無線ネットワークサブシステムそれぞれに確立される、請求項７記載の方法。
9. マルチキャストサービスを提供する間、前記ドメイン内の前記マルチキャストサービスに現在参加しているサービス参加者の数に依存して、前記伝送媒体は前記ポイントトゥポイントリンクから前記ポイントトゥマルチポイントリンク、または、その逆に切り換えられる、請求項７または請求項８記載の方法。
10. 前記ポイントトゥポイントリンクから前記ポイントトゥマルチポイントリンクへの切換は、前記無線ネットワークサブシステム毎に行われる、請求項９記載の方法。
11. 前記マルチキャストデータを配信するために前記ポイントトゥマルチポイントリンクを使用する場合、前記ドメイン内のマルチキャストサービスセンターに前記マルチキャストデータを送るステップを更に含む、請求項７から請求項１０のいずれかに記載の方法。
12. 前記サービス開始要求を承認して、他のドメインの制御ノードとポイントトゥポイントリンクを確立するステップを更に含み、
    マルチキャストサービス識別子は前記ポイントトゥポイントリンク上で前記マルチキャストサービスのデータを識別するために使用される、請求項７から請求項１１のいずれかに記載の方法。
13. 前記マルチキャストサービス識別子を、前記ドメイン内のマルチキャストサービスセンターによって使用されるマルチキャストサービス識別子と関連付けして、前記ドメインにおける前記サービス参加者に配信される際に前記マルチキャストサービスデータを識別するステップを更に含む、請求項１２記載の方法。
14. 前記他のドメインの前記制御ノードから受信される前記サービス開始要求で識別されるサービス参加者それぞれに対してサービス開始要求を生成するステップと、
    前記ドメインの前記サービス参加者に少なくとも一つの生成されたサービス開始要求を送信するステップ（６０１）と、
    更に含む、請求項７から請求項１３のいずれかに記載の方法。
15. 前記サービス参加者それぞれに対する前記サービス開始要求は、前記マルチキャストサービスデータを識別するために前記ドメイン内の前記マルチキャストサービスセンターによって使用されるべきマルチキャストサービス識別子を含む、請求項１４記載の方法。
16. 前記ドメインの前記制御ノード（１１１）は、前記ドメイン内のマルチキャストサービスセンターに前記ドメインの前記サービス参加者を申し込む、請求項７から請求項１５のいずれかに記載の方法。
17. 異なるドメインにマルチキャストサービスのマルチキャストデータを配信する第１のドメインの制御ノードであって、
    前記マルチキャストサービスに参加するサービス参加者を識別するサービス開始要求を受信する受信器と、
    前記サービス参加者の識別に基づき、前記サービス参加者が属し、且つ、前記第１のドメインの前記制御ノードによって制御されないドメインを識別するプロセッサと、
    ドメイン毎に前記識別されたドメインの制御ノードにマルチキャストデータを配信する送信器と、を備える制御ノード。
18. 請求項２から請求項６のいずれかに記載の方法のステップを実行するよう適合される手段を更に備える、請求項１７記載の制御ノード。
19. ドメインにおけるサービス参加者にマルチキャストサービスのマルチキャストデータを配信する制御ノードであって、
    前記制御ノードによって制御されるドメインに位置するマルチキャストサービスに参加する前記サービス参加者に関する情報を含む別のドメインの制御ノードからのサービス開始要求を受信する受信器と、
    前記ドメイン内で前記マルチキャストデータを配信するためにポイントトゥポイントリンクを利用するかポイントトゥマルチポイントリンクを利用するかを、前記サービス参加者に関する前記情報に基づいて判断し、前記判断に依存して、前記ドメインにおける前記サービス参加者それぞれにポイントトゥポイントまたは前記ドメインにおける前記サービス参加者にポイントトゥマルチポイントを、前記マルチキャストデータの伝送媒体として確立するプロセッサと、
    前記確立された伝送媒体を介して前記ドメインにおける前記サービス参加者に前記マルチキャストデータを配信する送信器と、
    を備える制御ノード。
20. 請求項１から請求項１６のいずれかに記載の方法のステップを実行するよう適合される手段を更に備える、請求項１９記載の制御ノード。
21. 請求項１７または請求項１８、あるいは、請求項１９または請求項２０記載の制御ノードを少なくとも一つ備える、システム。
22. 異なるドメインの第１のドメインの制御ノードのプロセッサによって実行されると、前記制御ノードに、
    前記マルチキャストサービスに参加するサービス参加者を識別するサービス開始要求を受信する処理と、
    前記サービス参加者の識別に基づき、前記サービス参加者が属し、且つ、前記第１のドメインの前記制御ノードによって制御されないドメインを識別する処理と、
    ドメイン毎に前記識別されたドメインの制御ノードにマルチキャストデータを配信する処理と、
    を実行させて、マルチキャストサービスのマルチキャストデータを異なるドメインに配信させる命令を記憶するコンピュータ読取可能媒体。
23. 前記第１のドメインの前記制御ノードによって実行されると、前記制御ノードに請求項２から請求項１６のいずれかに記載の方法のステップを実行させる、請求項２２記載のコンピュータ読取可能媒体。
24. ドメインの制御ノードによって実行されると、前記制御ノードに、
    前記制御ノードによって制御されるドメインに位置するマルチキャストサービスに参加する前記サービス参加者に関する情報を含む別のドメインの制御ノードからのサービス開始要求を受信する処理と、
    前記ドメイン内で前記マルチキャストデータを配信するためにポイントトゥポイントリンクを利用するかポイントトゥマルチポイントリンクを利用するかを、前記サービス参加者に関する前記情報に基づいて判断する処理と、
    前記判断に依存して、前記ドメインにおける前記サービス参加者それぞれにポイントトゥポイントまたは前記ドメインにおける前記サービス参加者にポイントトゥマルチポイントを、前記マルチキャストデータの伝送媒体として確立する処理と、
    前記確立された伝送媒体を介して前記ドメインにおける前記サービス参加者に前記マルチキャストデータを配信する処理と、
    を実行させて、ドメインにおけるサービス参加者にマルチキャストサービスのマルチキャストデータを配信させる命令を記憶するコンピュータ読取可能媒体。
25. 前記第１のドメインの前記制御ノードによって実行されると、前記制御ノードに請求項１から請求項１６のいずれかに記載の方法のステップを実行させる、請求項２４記載のコンピュータ読取可能媒体。
    

Images