JP4951070B2 - １トンネル手法を用いた効率的ｍｂｍｓバックボーン分配 - Google Patents

Description

本発明は、マルチメディアブロードキャスト／マルチキャストサービス（Ｍｕｌｔｉｍｅｄｉａ Ｂｒｏａｄｃａｓｔ／Ｍｕｌｔｉｃａｓｔ Ｓｅｒｖｉｃｅ：ＭＢＭＳ）の分野に関し、特に、ＧＰＲＳコアネットワークにおいてＭＢＭＳペイロードを分配する拡張機能に関する。

マルチキャスティングとは、データを複数の受信先へ分配されるようにするアドレスへ、ソースが同一のデータの単一のコピーを送信することを可能とするサービスである。マルチキャスティングのもとでは、メッセージのコピー１つだけが、ネットワークにおけるいずれかのリンクを通り、パスが分化するところでのみ、メッセージのコピーが複数作られるであろう。ネットワークの視点からは、マルチキャストは、エンドシステムでというよりもむしろ適当な点でネットワークにおいてデータが複製されるため、全体的な帯域幅消費を劇的に削減する。

マルチキャストは、インターネットプロトコルＩＰネットワークにおいて使用される場合、ＩＰマルチキャストと呼ばれる。インターネットプロトコルＩＰで、マルチキャスト受信者は、送信者からトラフィックを受信するのに、送信者が誰でどこにいるかを知る必要はなく、送信者は受信者が誰であるかを知る必要は絶対にない。ネットワークが分配を最適化するので、送信者も受信者もネットワークトポロジーを気にする必要はない。受信者が送信者を認知する代替手法も存在し、ＲＦＣ４６０７「ＩＰのためのソース固有マルチキャスト（Ｓｏｕｒｃｅ‐Ｓｐｅｃｉｆｉｃ Ｍｕｌｔｉｃａｓｔ ｆｏｒ ＩＰ）」において説明されている。ＩＰマルチキャストを介した情報の分配は、例えばツリーのようなホストの階層的接続に基づいて行われる。マルチキャスト分配ツリーを構成するいくつかのアルゴリズムが提案されており、例えばスパニングツリーや共有ツリー、ソースベースのツリーやコアベースのツリーのようなものがある。対応するアルゴリズムの説明は、「ＩＰテレフォニー：パケットベースのマルチメディア通信システム（ＩＰ ｔｅｌｅｐｈｏｎｙ：Ｐａｃｋｅｔ‐ｂａｓｅｄ ｍｕｌｔｉｍｅｄｉａ ｃｏｍｍｕｎｉｃａｔｉｏｎｓ ｓｙｓｔｅｍｓ）」Ｏ．・エルサン、Ｄ．・ギュルラ、Ｄ．・プティ（Ｏ． Ｈｅｒｓｅｎｔ，Ｄ． Ｇｕｒｌｅ，Ｄ． Ｐｅｔｉｔ）、アディソン‐ウェズリー（Ａｄｄｉｓｏｎ‐Ｗｅｓｌｅｙ）、ハーロー（Ｈａｒｌｏｗ）、２０００において発見できる。分配ツリーの確立後、ＩＰマルチキャストルーティングプロトコルは情報の分配を行う。対応するＩＰマルチキャストルーティングプロトコルの詳細な説明も上述の文書において発見可能である。

マルチキャストとは受信者ベースのコンセプトであり、つまり対応するマルチキャストルータに通知することによって受信者が特定のマルチキャストセッショングループに入会し、ネットワークインフラストラクチャによってそのグループの全メンバーへトラフィックが分配される。したがって、ＩＰマルチキャスト内ではマルチキャストセッショングループのメンバーシップが動的であり、つまりホストはいつでもグループに入会し、退会することが可能である。ネットワーク上のホストが特定のマルチキャストグループに入会したいかまたは退会したいかを示すのを可能とするために、インターネットグループメッセージプロトコルＩＧＭＰ（Ｉｎｔｅｒｎｅｔ Ｇｒｏｕｐ Ｍｅｓｓａｇｅ Ｐｒｏｔｏｃｏｌ）というプロトコルがある。このプロトコルは、どのホストがどのマルチキャストグループに目下属しているかをシステムに認知させる。この情報は、どのマルチキャストのデータグラムがどのインターフェース上へ転送されようとしているかを認知する必要のあるマルチキャストルータによって要求される。

ＩＧＭＰはＩＰレイヤの一部であり、ＩＧＭＰメッセージはＩＰデータパケットで送信される。ＲＦＣ１１１２「ＩＰマルチキャスティングのためのホスト拡張（Ｈｏｓｔ ｅｘｔｅｎｓｉｏｎｓ ｆｏｒ ＩＰ ｍｕｌｔｉｃａｓｔｉｎｇ）」、Ｓ．・Ｅ．・ディーリング（Ｓ． Ｅ． Ｄｅｅｒｉｎｇ）、１９８９年８月１日においてＩＧＭＰのバージョン１が説明されており、ＲＦＣ２２３６「インターネットグループ管理プロトコル、バージョン２（Ｉｎｔｅｒｎｅｔ Ｇｒｏｕｐ Ｍａｎａｇｅｍｅｎｔ Ｐｒｏｔｏｃｏｌ，Ｖｅｒｓｉｏｎ ２）」Ｗ．・フェナー（Ｗ． Ｆｅｎｎｅｒ）、１９９７年１１月がバージョン２を説明する。ＩＧＭＰは、ＩＰバージョン４のために開発されてきた。インターネットプロトコルＩＰバージョン６において、マルチキャストリスナーディスカバリＭＬＤ（Ｍｕｌｔｉｃａｓｔ Ｌｉｓｔｅｎｅｒ Ｄｉｓｃｏｖｅｒｙ）という同様のプロトコルがあり、ＩＧＭＰと同一の目的で使用される。ＭＬＤの第１のバージョンの説明は、ＲＧＣ２７１０「ＩＰｖ６のためのマルチキャストリスナーディスカバリ（Ｍｕｌｉｃａｓｔ Ｌｉｓｔｅｎｅｒ Ｄｉｓｃｏｖｅｒｙ（ＭＬＤ）ｆｏｒ ＩＰｖ６）」、Ｓ．・デアリング、Ｗ．・フェナー、Ｂ．・ハーバーマン、１９９９年１０月において発見可能である。しかしながら、ＭＬＤにおいて使用されるメッセージはＩＧＭＰメッセージに対応する。以下では、ＩＧＭＰを例として使用することにする。発明の機能はＩＧＭＰに限定されるべきではなく、ＭＬＤの使用によっても与えられるものである。

原則として、ＩＧＭＰは２つの基本メッセージを使用してそのタスク、メンバーシップ報告およびメンバーシップクエリメッセージを果たし、以下のルールが適用される。ＩＧＭＰの色々なバージョンが追加のメッセージを含む。

マルチキャストルータが定期的にメンバーシップクエリを送信し、いずれかのホストが未だいずれかのグループに属しているかどうかをみる。ルータは各インターフェースから１つのクエリを送信しなければならない。各ホスト上に１または２以上のメンバーを含むグループごとに、ホストから１つの応答をルータが期待するため、クエリにおけるグループアドレスは０である。全グループに対するよりむしろ１つの特定のグループに対するメンバーシップクエリを送信することも可能である。未だ少なくとも１つのユーザを含むグループごとに１つのＩＧＭＰ報告を送信することによって、ホストがＩＧＭＰクエリに応答する。メンバーシップ報告を送信することによって、ホストがグループに入会する。報告とクエリーメッセージを適用することによって受信される情報を使用して、少なくとも１つのホストをマルチキャストグループに有するそのインターフェースを有するテーブルが確立される。マルチキャストデータの受信の後、ルータは各インターフェースからデータを転送するのであり、各インターフェースは少なくとも１のメンバーを有する。

汎用パケット無線システムＧＰＲＳ（Ｇｅｎｅｒａｌ Ｐａｃｋｅｔ Ｒａｄｉｏ Ｓｙｓｔｅｍ）またはユニバーサル移動通信システムＵＭＴＳ（Ｕｎｅｖｅｒｓａｌ Ｍｏｂｉｌｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｓｙｓｔｅｍ）のような公用地移動ネットワークＰＬＭＮ（Ｐｕｂｌｉｃ Ｌａｎｄ Ｍｏｂｉｌｅ Ｎｅｔｗｏｒｋ）におけるマルチキャスティングが、例えばユーザのモビリティやエアーインターフェースの特性に関して、さらなる開発を必要とする。さらに、例えばＵＭＴＳのような移動通信ネットワークにおける通信はユニキャスト通信である。ユニキャスト通信はポイントツーポイント通信ともいう。ポイントツーポイント通信とは、単一の送信者から単一の受信者へメッセージを送信することを意味する。このような種類のネットワークにおいて、特にコアネットワークにおいて、マルチキャスト通信を行うことは予想されない。グループ通信は、グループの各メンバーへパケットを別々に送信する送信者を有するポイントツーポイント通信によって実施される。ｎのメンバーを有するグループについて、送信者と受信者との間ではずっと、マルチキャストが使用される際の１個のパケットではなく、ｎ個のパケットが必要とされる。

以下に、汎用パケット無線システムＧＰＲＳネットワークのアーキテクチャの概観を与える。

ＧＰＲＳとは、移動通信用グローバルシステムＧＳＭ（Ｇｌｏｂａｌ Ｓｙｓｔｅｍ ｆｏｒ Ｍｏｂｉｌｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎ）のパケット交換拡張であり、回路交換ネットワークである。ユニバーサル移動電気通信システムＵＭＴＳをカバーするようにＧＰＲＳも拡張された。ＧＰＲＳパケット交換拡張で、ユーザが恒久的にオンラインで接続可能であるが実データ転送に対してのみ代金を支払わなければならない、ということを意味する。新しい要求を果たすために、ＧＳＭへいくつかの変化が導入され、他の新しい論理ノードの中でも、サービングＧＰＲＳサポートノード（ＳＧＳＮ：Ｓｅｒｖｉｎｇ ＧＰＲＳ Ｓｕｐｐｏｒｔ Ｎｏｄｅ）およびゲートウェイＧＰＲＳサポートノード（ＧＧＳＮ：Ｇａｔｅｗａｙ ＧＰＲＳ Ｓｕｐｐｏｒｔ Ｎｏｄｅ）が導入される。ＧＧＳＮの主要機能は、例えばインターネットサービスプロバイダＩＳＰ（Ｉｎｔｅｒｎｅｔ Ｓｅｒｖｉｃｅ Ｐｒｏｖｉｄｅｒ）への接続を提供する外部ＩＰパケットネットワークとの相互作用に関する。外部ＩＰネットワークの視点からは、ＧＧＳＮは、ＧＰＲＳネットワークがサービスする全加入者のＩＰアドレスに対するルータとしてふるまう。ＧＧＳＮは外部ネットワークとルーティング情報も交換する。各ＧＧＳＮは多くのＳＧＳＮにサービスし、ＧＧＳＮをツリーの根としたツリーとして配列可能である。ＳＧＳＮは、地理的ＳＧＳＮサービスエリア内に物理的に位置する全ＧＰＲＳ加入者にサービスする。それは、移動局へまたは移動局からアドレス指定された入来および退去ＩＰパケットを転送する。

ＧＳＭおよびＵＭＴＳにおけるこれらのノードの機能を区別するために、拡張名がしばしば使用される、２Ｇ‐ＳＧＳＮ、３Ｇ‐ＳＧＳＮおよび２Ｇ‐ＧＧＳＮ、３Ｇ‐ＧＧＳＮ。以下の説明では、ＧＰＲＳノードとＵＭＴＳノードとは区別しないことにする。

３ＧＰＰ ＴＳ２３．０６０ｖ７．２．０（２００６‐０９）第３世代パートナーシッププロジェクト；技術仕様書グループサービスおよびシステムアスペクト、汎用パケット無線サービス（ＧＰＲＳ）、サービスデスクリプション、ステージ２（リリース）（３．．ｒｄ Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒｓｈｉｐ Ｐｒｏｊｅｃｔ；Ｔｅｃｈｎｉｃａｌ Ｓｐｅｃｉｆｉｃａｔｉｏｎ Ｇｒｏｕｐ Ｓｅｒｖｉｃｅ ａｎｄ Ｓｙｓｔｅｍ Ａｓｐｅｃｔｓ，Ｇｅｎｅｒａｌ Ｐａｃｋｅｔ Ｒａｄｉｏ Ｓｅｒｖｉｃｅ（ＧＰＲＳ），Ｓｅｒｖｉｃｅ Ｄｅｓｃｒｉｐｔｉｏｎ，Ｓｔａｇｅ ２（Ｒｅｌｅａｓｅ））に、アーキテクチャの詳細な説明が発見されることになる。

ストリーミングの導入および対話型マルチメディアサービスの導入で、多くの新しいポイントツーマルチポイントサービスが発達するであろう。このようなサービスのいくつかの例が、モバイルＴＶ、テレビ会議、ホワイトボーディング、リアルタイムマルチユーザゲーム、マルチメディアメッセージング、仮想世界である。特に、ネットワークオペレータは、モバイルネットワーク内で数多くの色々なマルチキャストアプリケーションを提供するであろう。

ＭＢＭＳサービスは、ＧＰＲＳパケット交換ネットワークにおけるユーザのグループへのマルチキャストおよびブロードキャストサービスの効率的な分配のために設計される。セルにおける無線インターフェース上のマルチキャストおよびブロードキャストを通して、複数のユーザが、効率的なやり方で、例えば同一の無線チャネル上のＴＶストリーミングサービスのペイロード同時に受信可能であり、無線資源を節約する。サービスはコアネットワーク制御ノード、ＢＭ‐ＳＣから提供される。サービスはネットワークにおける制御信号送信を通してセットアップされる。ＭＢＭＳブロードキャストサービスについて、地理的分配ツリーが、サービスエリアに属する多くのセルへの「ブラインド（ｂｌｉｎｄ）」ブロードキャストに基づいて構成され、一方でＭＢＭＳマルチキャストサービスは、サービスに参加するユーザによって動的に構成され、分配ツリーは、ノードと、参加ユーザがいるセルとからなるであろう。図１を参照。コアネットワークにおける分配プロトコルはＧＴＰプロトコルである。信号送信およびペイロードは、ＧＴＰ‐ＣおよびＧＴＰ‐Ｕによってそれぞれ処理される。

図１は、周知の解決手段による状況を説明する。通信ネットワーク１は、マルチメディアサービスをブロードキャストすることに使用されるＢＭ‐ＳＣ２（ＢＭ‐ＳＣは次々にメディアコンテンツをコンテンツサーバ（図示せず）から得るであろう）と、通信チェーンのさらに下へデータを分配することに使用される少なくとも１つのＧＧＳＮ３、７と、少なくとも１つのＳＧＳＮ４と、少なくとも１つのＲＮＣ５とを備える。移動ユニット（図示せず）がノードＢ（図示せず）を介してＲＮＣと通信する。ＧＴＰトンネル６が、ＧＧＳＮから各関連ＳＧＳＮへの、およびＳＧＳＮから各関連ＲＮＣへのポイントツーポイントをセットアップする。

ＧＧＳＮとＳＧＳＮとの間のＧＴＰポイントツーポイントトンネルを使用するＭＢＭＳ分配ツリーは効率的ではない。ＧＧＳＮが多くのＳＧＳＮ（ＯＴＳについてはＲＮＣ）へペイロードを複製しなければいけなくなる分配方法には問題がある。ＧＧＳＮへ入来する各ＭＢＭＳペイロードパケットは、複製され、１０〜２０またはいかなる数のダウンストリームＳＧＳＮへ分配されなければならない場合がある。ＧＧＳＮにおけるこのパケット複製は、資源を非常に必要とすることになり、ＧＧＳＮを相当遅くし得る。この複製パケットの多くも同一の退出インターフェースおよび接続上で送信されることになり、ネットワーク資源を非常に効率悪く使用する。ＧＧＳＮにおけるより効率的なパケット処理が必要とされる。同様に、ＳＧＳＮへ入来する各ＭＢＭＳペイロードパケットは、複製され、１０〜２０またはいかなる数のダウンストリームＲＮＣへ分配されなければならない場合がある。ＳＧＳＮにおけるこのパケット分配は、資源を非常に必要とすることになり、ＳＧＳＮを相当遅くし得る。この分配パケットの多くも同一の退出インターフェースおよび接続上で送信されることとなり、ネットワーク資源を非常に効率悪く使用する。ＳＧＳＮにおけるより効率の良いパケット処理が必要とされる。

ＧＰＲＳコアネットワークにおけるＭＢＭＳペイロードの分配のためのＩＰマルチキャストを使用する第１の解決手段は、米国特許出願公開第２００５０００７９６９号明細書、第２００４０２４６９８４号明細書、第２００６００３４２７８号明細書（ここで参照して含める）において提案された。この解決手段の問題は、ＧＴＰ‐Ｕ実施が再利用されないので、既存のＧＧＳＮ、ＳＧＳＮおよびＲＮＣノードに大きなインパクトを有することである。別の問題は、提案された方法がＭＢＭＳブロードキャストサービスに適用可能ではないということである。ＩＰマルチキャスト分配からレガシーポイントツーポイント分配までのフォールバック機構が説明されていないので、提案された方法は既存のネットワークに導入する困難も与える。ＴＲ２３．８０９において報告された進行中の３ＧＰＰ研究、「１トンネル研究（Ｏｎｅ Ｔｕｎｎｅｌ ｓｔｕｄｙ）」において、ＧＴＰ‐ＵトンネルでＳＧＳＮをバイパスする可能性が調査される。これをＭＢＭＳについてどのように行
うことができるかは未だ説明されていないのだが、本発明には含まれている。

ユーザレイヤ上のマルチキャストアプリケーションの導入は、特にマルチキャストデータ配信に関するノード間の、トランスポートレイヤ上の調整を必要とする。複数のＧＧＳＮを有するＰＬＭＮにおいて、目下、ＧＧＳＮ間のマルチキャストグループに対する調整および同期機構はない。同様に、ＧＴＰ‐ＵおよびＩＰマルチキャストを使用するＭＢＭＳ分配に使用される複数のＧＧＳＮによって割り当てられるＴＥＩＤに対して説明される調整または同期機構もない。

このように、ＰＬＭＮにおける複数のＧＧＳＮが同一のマルチキャストグループを対処する、ということが起こる場合があり、複数のマルチキャストグループおよびマルチキャスト接続となる。さらに、マルチキャストグループ情報がＰＬＭＮに分配される場合、ＰＬＭＮオペレータには、いずれかの分析をグループメンバーシップに基づかせる手段がない。つまり、オペレータは追加メンバーを制限できない、またはいずれかのチャージ決定をＰＬＭＮにおけるグループメンバーシップ全体に基づかせることができないということである。

本発明の目的は、上述の問題のうち少なくともいくつかを解決する解決手段を提供することである。これは多くの観点を提供し、第１の観点、電気通信ネットワークにおいてマルチメディアブロードキャストマルチキャストサービス、すなわちＭＢＭＳ、の分配を容易にする電気通信ゲートウェイ装置が提供され、
ブロードキャスト／マルチキャストサービスセンターからのＭＢＳＭセッション開始メッセージを受信する命令セットと、
制御ネットワーク上で制御トラフィックを送信する命令セットと、
サービングノードへの制御トラフィックとしてＭＢＭＳセッション開始要求メッセージを送信し、ＭＢＭＳセッション開始要求メッセージに共通トンネルエンドポイント識別子、すなわちｃＴＥＩＤ、を含める命令セットと、
ＩＰマルチキャストの使用の受け入れを示すサービングノードからの情報を受信する命令セットと、
ｃＴＥＩＤを使用してマルチキャストグループに参加したホストへＩＰマルチキャストバックボーン上でメディアコンテンツを送信する命令セットと
で構成される。

この装置は、ｃＴＥＩＤの一意性を確証するために、ｃＴＥＩＤを他のインフラストラクチャ装置と同期する命令セットをさらに備えてもよい。

この装置は、別のインフラストラクチャ装置から一意のｃＴＥＩＤを受信する命令セットをさらに備えたとしてもよい。

なおこの装置は、フォールバックの目的でサービングノードと制御ノードとのうちの少なくとも１つへ少なくとも１つのネットワーク通信トンネルを作成する命令セットをさらに備えてもよい。

本発明の第２の観点、電気通信ネットワークにおいてマルチメディアブロードキャストマルチキャストサービス、すなわちＭＢＭＳ、の分配を容易にする電気通信サービング装置が提供され、
共通トンネルエンドポイント識別子、すなわちｃＴＥＩＤ、を含む電気通信ゲートウェイ装置からのＭＢＳＭセッション開始メッセージを受信する命令セットと、
ＭＢＭＳセッション開始要求メッセージを制御装置へ送信し、ＭＢＭＳセッション開始要求メッセージに共通トンネルエンドポイント識別子、すなわちｃＴＥＩＤ、を含める命令セットと、
インターネットプロトコル（ＩＰ）マルチキャスト分配の使用の受け入れを示す制御装置からの情報を受信する命令セットと
で構成される。

このサービング装置は、インターネットプロトコルマルチキャストバックボーンへインターネットグループ管理プロトコル、すなわちＩＧＭＰ、参加メッセージまたはメンバーシップ報告メッセージ（ＩＧＭＰｖ２およびＩＧＭＰｖ３）を送信する命令セットをさらに備えてもよい。

このサービング装置は、制御装置がＩＰマルチキャスト分配の使用の非受け入れを示す場合にペイロードデータの分配のためにトンネルを作成する命令セットをさらに備えてもよい。

なお、本発明の別の観点、電気通信ネットワークマルチメディアブロードキャストマルチキャストサービス、すなわちＭＢＭＳ、の分配を容易にする電気通信制御装置が提供され、
共通トンネルエンドポイント識別子、すなわちｃＴＥＩＤ、を含むＭＢＭＳセッション開始メッセージを電気通信サービング装置から受信する命令セットと、
電気通信制御装置がインターネットプロトコルマルチキャスト分配を受け入れるという表示を有するＭＢＭＳセッション開始応答メッセージをサービング装置へ送信する命令セットと、
インターネットプロトコルマルチキャストバックボーンへインターネットグループ管理プロトコル、すなわちＩＧＭＰ、参加メッセージまたはメンバーシップ報告メッセージ（ＩＧＭＰｖ２およびＩＧＭＰｖ３）を送信する命令セットと
で構成される。

この制御装置は、（ＭＢＭＳセッション終了メッセージが受信された場合）インターネットプロトコルマルチキャストバックボーンへインターネットグループ管理プロトコル、すなわちＩＧＭＰ、リーブメッセージまたはメンバーシップ報告メッセージ（ＩＧＭＰｖ２およびＩＧＭＰｖ３）を送信して、マルチキャスト受信をキャンセルするステップをさらに含んでもよい。

なお、本発明の別の観点、マルチメディアブロードキャストマルチキャストサービス、すなわちＭＢＭＳ、の分配を容易にする電気通信インフラストラクチャネットワークが提供され、
ブロードキャスト／マルチキャストサービスノード、すなわちＢＭ‐ＳＣと、
ゲートウェイノードと、
少なくとも１つのサービングノードと、
少なくとも１つの制御ノードと
を備え、
ＢＭ‐ＳＣはゲートウェイノードに接続され、次にゲートウェイノードは２つのインターフェース、制御インターフェースおよびバックボーンインターフェースを介してサービングノードに接続され、次に制御ノードはサービングノードおよび／またはゲートウェイノードに接続され、ゲートウェイノードは、
ブロードキャスト／マルチキャストサービスセンターからＭＢＳＭセッション開始メッセージを受信する命令セットと、
ＭＢＭＳセッション開始要求メッセージをサービスノードへ制御トラフィックとして送信し、ＭＢＭＳセッション開始要求メッセージに共通トンネルエンドポイント識別子、すなわちｃＴＥＩＤ、を含める命令セットと、
ｃＴＥＩＤを使用してマルチキャストグループに参加したホストへＩＰマルチキャストバックボーン上でメディアコンテンツを送信する命令セットと
で構成される。

本発明は、電気通信ネットワークにおいてマルチメディアブロードキャストマルチキャストサービス、すなわちＭＢＭＳ、の分配を容易にする方法としても提供され、
ブロードキャスト／マルチキャストサービスセンター、すなわちＢＭ‐ＳＣ、からのＭＢＭＳセッション開始メッセージをゲートウェイノードにおいて受信するステップと、
制御ネットワーク上で制御トラフィックを送信するステップと、
ＭＢＭＳセッション開始要求メッセージをゲートウェイノードからへサービングノード（２４）の制御トラフィックとして送信し、ＭＢＭＳセッション開始要求メッセージに共通トンネルエンドポイント識別子、すなわち共通ＴＥＩＤ、を含めるステップと、
ＩＰマルチキャストの使用の受け入れを示すサービングノードからの情報を受信するステップと、
共通ＴＥＩＤを使用してマルチキャストグループに参加したホスト（２５、２６、３１）へＩＰマルチキャストバックボーン上でメディアコンテンツを送信するステップと
を含む。

共通ＴＥＩＤはＭＢＭＳセッションごとに一意であってもよい。

この方法は、共通ＴＥＩＤを、同一のＢＭ‐ＳＣに接続される他のゲートウェイノードと同期するステップを、さらに含んでもよい。

ホストはサービングノードと制御ノードとのうちの１つであってもよい。

サービングノードはサービングＧＰＲＳサポートノード、すなわちＳＧＳＮ、であってもよく、制御ノードは基地局コントローラ、すなわちＢＳＣ、と無線ネットワークコントローラ、すなわちＲＮＣ、とのうちの１つである。

共通ＴＥＩＤは、アクティブ状態を示す少なくとも１つのビットのＴＥＩＤ構造を設定することによって識別されてもよい。

この方法は、ゲートウェイノードとサービングノードとの間、およびサービングノードと制御ノードとの間にＧＴＰトンネルをセットアップすることを含むフォールバック手続を使用するステップを、さらに含んでもよい。

この方法は、ＩＰマルチキャストバックボーンへの制御装置の参加のステップをさらに含んでもよく、参加ステップは、インターネットプロトコルマルチキャストバックボーンへインターネットグループ管理プロトコル、すなわちＩＧＭＰ、参加メッセージまたはメンバーシップ報告メッセージ（ＩＧＭＰｖ２およびＩＧＭＰｖ３）を送信すること、またはマルチキャストリスナーディスカバリ、すなわちＭＬＤ、メッセージを使用することを含んでもよい。

本発明の別の観点、電気通信ネットワークにおいてマルチメディアブロードキャストマルチキャストサービス、すなわちＭＢＭＳ、を搬送する信号が提供され、インターネットプロトコルマルチキャストアドレスと、ＧＰＲＳトンネルプロトコルトンネルエンドポイント識別子と、ＭＢＭＳマルチキャストアドレスと、メディアコンテンツデータとを含む。

本発明によって、ＧＧＳＮとＳＧＳＮとの間の効率的なバックボーン分配がＭＢＭＳサービスに活用可能である。この方法がなくては、ＧＧＳＮは、ＭＢＭＳパケットをＧｎインターフェースへコピーすることから重くダウンロードされる場合がある。

以下では、添付図面に示す例示的実施形態を参照しながら、本発明を非限定的でより詳細に説明することにする。

周知技術によるネットワークトポロジーを概略的に示す。 本発明によるネットワークトポロジーを概略的に示す。 本発明によるプロトコルスタックモデルを概略的に示す。 より詳細に図２のネットワークトポロジーを概略的に示す。 本発明によるインフラストラクチャ装置をブロック図で概略的に示す。 本発明によるデータパケットを概略的に示す。 本発明によるセッション開始手続を概略的に示す。 本発明によるＭＢＭＳセッション終了手続を概略的に示す。 本発明によるＭＢＭＳ登録抹消手続を概略的に示す。 本発明によるＢＭ‐ＳＣ開始ＭＢＭＳ登録抹消手続を概略的に示す。

図２において、参照番号２０は、ブロードキャスト／マルチキャストサービスを可能にするものされる電気通信インフラストラクチャネットワークを一般的に示す。ブロードキャスト／マルチキャストサービスセンター（ＢＭ‐ＳＣ：ｂｒｏａｄｃａｓｔ／ｍｕｌｔｉｃａｓｔ ｓｅｒｖｉｃｅ ｃｅｎｔｅｒ）２が、メディアコンテンツサーバ（図示せず）から供給されるメディアコンテンツのブロードキャスティングおよび／またはマルチキャスティングを処理するものとされる。ＢＭ‐ＳＣは、少なくとも１つのＧＧＳＮ２３（ゲートウェイＧＰＲＳサービスノード）に接続され、ＧＧＳＮ２３は次にＩＰマルチキャストバックボーン２１に接続される。ＩＰマルチキャストバックボーンにおいて、多くのルータ３２、３３および３４が、メディアコンテンツの配信の対象としてセットアップされたＲＮＣ２５、２６（Ｒａｄｉｏ Ｎｅｔｗｏｒｋ Ｃｏｎｔｒｏｌｌｅｒ：無線ネットワークコントローラ）へメディアコンテンツ（すなわちいわゆるペイロード）をルーティングする。いくつかの場合では、ＲＮＣは本発明によるやり方で直接ペイロードを受信することができない。それゆえペイロードトラフィックはまずＳＧＳＮ３１（サービングＧＰＲＳサービスノード）へ送信され、ＳＧＳＮ３１がペイロードトラフィックをＲＮＣへ中継する。ＲＮＣがペイロードトラフィックを直接受信可能である場合には、ＳＧＳＮ２４はペイロード分配には使用されない。本発明によると、ＩＰマルチキャストバックボーン２９は、ＩＰマルチキャストバックボーン上の少なくとも１つのルータ３２を介したＧＧＳＮ２３とマルチキャストネットワークの各ＲＮＣ部分との間で使用される。しかしながら、ＲＮＣが、本発明を用いるマルチキャストネットワークの一部でない場合、ＧＧＳＮ２３は、バックボーン上のルータを介してＳＧＳＮ３１へＩＰマルチキャストネットワーク上でデータを送信する、すなわち、ＳＧＳＮ３１がＩＰマルチキャストネットワークにおいてホストとしてふるまい、ＳＧＳＮ３１はＳＧＳＮ３１とＲＮＣ３０との間にトンネル２８をセットアップするであろう。ＳＧＳＮが本発明をサポートしない場合、ＧＧＳＮは標準ＧＴＰトンネル２７をＳＧＳＮ３１へセットアップしなければならないであろう。

ＧＧＳＮ２３にＭＢＭＳペイロードを複製して、ポイントツーポイントトンネル送信を用いて多くのＳＧＳＮ２４へ送信させる代わりに、バックボーン上のＧＧＳＮ２３からＩＰマルチキャストを行うことが好ましいであろう。ＧＧＳＮ２３とＳＧＳＮ２５、２６との間に（またはＩＰマルチキャストをサポートするＲＮＣへ直接）ＩＰマルチキャスト分配をセットアップすることが必要である。それからＧＧＳＮはＭＢＭＳペイロードパケットのただ１つのコピーをＧＰＲＳバックボーンへ送信する必要があり、ＩＰマルチキャストバックボーン上のルータは、複製とＳＧＳＮへのパケット分配とを処理するであろう、図２参照。

上の図２における最左端のＲＮＣ３０は、ＩＰマルチキャスト分配をサポートせず、したがって通常ＭＢＭＳユニキャストを介してＳＧＳＮ３１からＭＢＭＳペイロードを得る。最右端のＳＧＳＮの下の全ＲＮＣ２５がＩＰマルチキャスト分配をサポートし、したがって、ＳＧＳＮ２４は、（ユーザプレーン）分配ツリーの一部である必要が全くないが、ただ通信セットアップの制御プレーンの一部である。

図４は、図２で説明したものと同様のネットワークを示すが、メディアコンテンツサーバ４１６と移動局４０６、４０７および４０８ともまた示される点が異なっている。図４において、参照番号４００はインフラストラクチャネットワーク構成を示す。メディアコンテンツサーバ４１６は、マルチキャストサービスに制御されているＢＭ‐ＳＣ４１０へ接続４１５を介してマルチキャストコンテンツを送信する。ＢＭ‐ＳＣは、ＧＧＳＮ４０２へ接続４１４を介してマルチキャスト制御とユーザプレーン情報とを送信し、ＧＧＳＮ４０２は次に制御プレーン接続４１２を介してネットワークにおけるＳＧＳＮ４０４へ制御プレーントラフィックを送信する。接続がセットアップされると、実施される本発明を有する各ＲＮＣ４０５へ直接４１７、またはＳＧＳＮ４０４を介して非直接４１８、４１１、バックボーン上の少なくとも１つのルータ４０３を介してＩＰマルチキャストバックボーン４１５を介してユーザプレーン情報が送信される４１３。ＲＮＣは、さらに移動局４０６、４０７、４０８へユーザプレーントラフィックを転送する責任がある。移動局はいずれかの適当な通信装置、または通信能力を有する計算装置であってもよく、例えば、携帯電話、携帯情報端末（ＰＤＡ）、ラップトップ、ＭＰ３プレーヤまたはポータブルＤＶＤプレーヤ（または同様のメディアコンテンツ装置）、デジタルカメラ、またはＰＣのような固定装置でさえあるが、これらに限定はされない。ＰＣが、ブロードキャスト／マルチキャストされたメディアの終端局として移動局を介して接続される場合もある。

バックボーンマルチキャストサービスは効率的分配のみに使用され、ユーザマルチキャストサービスとは混同されないであろう。

ここで本発明をより詳細に説明することにする。

基本着想のプロトコル関連図が図３に反映されている。図３は、３ＧＰＰに標準化されるようなネットワークのアーキテクチャを示す。しかしながら、これは本発明に対する限定として見られるべきではない。図３は、移動局ＭＳがＵｕインターフェースを通してアクセスネットワークＵＴＲＡＮと通信する状況を示す。Ｉｕ‐ＰＳインターフェースがＵＴＲＡＮを３Ｇ‐ＳＧＳＮと接続し、３Ｇ‐ＳＧＳＮはＧｎインターフェースを通して３Ｇ‐ＧＧＳＮと通信する。図３は、ＵＭＴＳで使用される色々なノードにおける色々なプロトコルスタックの概観を提供する。単に、ＩＰ、ＰＰおよびＵＤＰ／ＩＰと表すパケット交換ドメイン２つのＩＰレイヤとＧＴＰ‐Ｕレイヤとに、以下の説明は集中する。図３にでは、補足的な理由で他のプロトコルにも言及する。

ＳＧＳＮまたはＧＧＳＮのような導入パケット交換指向ノードの機能および通信方式に対する上述の要求および制限は、そのインパクトを開発プロトコルスタックへ有する。ルータとして、または外部ネットワークへのインターフェースとしてのＧＧＳＮの機能の結果として、アプリケーションレイヤの下のＩＰレイヤが導入された。さらに、ＧＧＳＮとＳＧＳＮとの間にＩＰネットワークを有する制限のため、ＩＰ論理接続は、搬送手段として、ＧＴＰ‐Ｕレイヤの下に導入される。

したがって、図３に関して２つのＩＰレイヤがあり、以下でアプリケーションＩＰおよびトランスポートＩＰレイヤとして説明する。アプリケーションＩＰレイヤは、アプリケーションプロトコル、アプリケーション、直下のプロトコルスタックに位置し、移動局と３Ｇ‐ＧＧＳＮとを接続する。このＩＰレイヤは、パケット交換ネットワークに対して透過的であり、これを図３において、ＭＳから３Ｇ‐ＧＧＳＮまでの直線で示す。第２のＩＰレイヤは、ＳＧＳＮとＧＧＳＮとＵＴＲＡＮとの間の送信に使用されるトランスポートＩＰレイヤである。トンネリング用トランスポートレイヤプロトコルの一例であるアプリケーション固有トンネリングプロトコル、ＧＰＲＳトンネリングプロトコルＧＴＰに封入されるＧｎを越えて、ペイロードトラフィックが搬送される。ＧＴＰパケットは、トランスポートプロトコルとしてＵＤＰを使用する。しかしながら、トンネルを構成する責任のあるトンネリングプロトコルは色々ある。ＧＴＰは単に一例であり、本発明を限定するものであるべきではない。

マークされたＵＤＰ／ＩＰレイヤが、ここで提案する変更を有するＩＰマルチキャストサービスを使用するであろう。マークされたＵＤＰ／ＩＰレイヤ、すなわちトランスポートレイヤにおいてＩＰマルチキャストアドレス指定を使用する本発明は、目下標準化された３ＧＰＰプロトコルスタックを変えない、ということがわかる。このように、ＩＰマルチキャスト分配を実施すると、ノードへのインパクトは最小化される。ＭＢＭＳサポートノードにおけるパケット転送機能は、ＩＰマルチキャスト分配が導入される際に基本的には影響を受けない。

＜ＭＢＭＳに対するＩＰマルチキャスト分配のための信号送信＞
１．ＭＢＭＳに対するパラメータを含むセッション開始をＧＧＳＮへ送信することによって、ＢＭ‐ＳＣがＭＢＭＳサービスを開始する。
２．ＧＧＳＮが、その「ダウンストリームノードのリスト（Ｌｉｓｔ ｏｆ ｄｏｗｎｓｔｒｅａｍ ｎｏｄｅｓ）」にある全ＳＧＳＮへＭＢＭＳ＿Ｓｅｓｓｉｏｎ＿Ｓｔａｒｔ‐ｒｅｑｕｅｓｔを送信する（あるいはＢＭ‐ＳＣが、ＧＧＳＮへのセッション開始メッセージにおける「ダウンストリームノードのリスト」パラメータでＲＮＣのリストを提供する場合もある。次にＧＧＳＮ（または対応するサービスノード）は、新しいＩｕインターフェースを用いてＲＮＣに直接信号送信するであろう。これは、目下の３ＧＰＰ ＣＮアーキテクチャには存在しないが、将来の３ＧＰＰアーキテクチャ、例えば３ＧＰＰ ＳＡＥ研究の発展パケットコアには存在し得る）、提案「バックボーン分配のためのＩＰマルチキャストアドレス（ＩＰ Ｍｕｌｔｉｃａｓｔ ａｄｄｒｅｓｓ ｆｏｒ ｂａｃｋｂｏｎｅ ｄｉｓｔｒｉｂｕｔｉｏｎ）」（新しいＧＴＰ ＩＥ）と、また提案共通ＴＥＩＤ‐Ｕ（新しいＧＴＰ ＩＥ）を含む。ソース固有マルチキャストが使用される場合、「マルチキャストサービスへのアドレス（Ａｄｄｒｅｓｓ ｔｏ ｍｕｌｔｉｃａｓｔ Ｓｏｕｒｃｅ）」（例えばＧＧＳＮ）も新しいＧＴＰ ＩＥに含まれる。ＧＧＳＮは、各ＭＢＭＳに一意となるこの提案一般ＴＥＩＤ‐Ｕを選択して、ＭＢＭＳサービスごとに一意のＴＥＩＤを受信ノード（ＲＮＣおよび２Ｇ‐ＳＧＳＮ）が受信するということを確証するであろう。
３．ＳＧＳＮがセッション開始を受け入れ、ＩＰマルチキャスト分配が受け入れられたという表示を含むＭＢＭＳ＿Ｓｅｓｓｉｏｎ＿Ｓｔａｒｔ‐ｒｅｓｐｏｎｓｅをＧＧＳＮへ送信し、ユーザプレーンＩＥに対するＳＧＳＮアドレスを、ＧＧＳＮから受信された「バックボーン分配に対するＩＰマルチキャストアドレス（ＩＰ Ｍｕｌｔｉｃａｓｔ ａｄｄｒｅｓｓ ｆｏｒ ｂａｃｋｂｏｎｅ ｄｉｓｔｒｉｂｕｔｉｏｎ）」に設定する。
・バックボーン分配に対する提案ＩＰマルチキャストアドレス（または提案ＴＥＩＤ‐Ｕ）をＳＧＳＮが受け入れない場合、それはこれを、ユーザトラフィックおよびＴＥＩＤ‐Ｕに対する普通ユニキャストＳＧＳＮアドレスをＭＢＭＳ＿Ｓｅｓｓｉｏｎ＿Ｓｔａｒｔ‐ｒｅｓｐｏｎｓｅに含むことによって示すであろう。
接続される各ＲＮＣ（またはＢＳＣ）接続ダウンストリームへ、ＳＧＳＮはＭＢＭＳセッション開始要求メッセージを送信し、ＩＰマルチキャストが受け入れられるという表示を有するＭＢＭＳセッション開始応答を受信する。
・バックボーン分配に対する提案ＩＰマルチキャストアドレス（または提案ＴＥＩＤ‐Ｕ）をＲＮＣが受け入れる場合、ＳＧＳＮはこれを、ユーザトラフィックおよびＴＥＩＤ‐Ｕに対する普通ユニキャストＲＮＣ ＩＰアドレスをＭＢＭＳ＿Ｓｅｓｓｉｏｎ＿Ｓｔａｒｔ‐ｒｅｓｐｏｎｓｅに含むことによって示すであろう。
４．ＳＧＳＮがＩＧＭＰメッセージ（ＩＰｖ４）またはＭＬＤ‐メッセージ（ＩＰｖ６）をＩＰマルチキャストバックボーンへ送信して、分配マルチキャストに参加する。これは、例えばＳＳＭが使用される場合、ＩＧＭＰｖ３またはＭＬＤｖ２メッセージである場合がある（ＲＦＣ４６０４）。
５．ＧＧＳＮがＭＢＭＳユーザペイロードの１つのコピーをバックボーンへ送信可能であり、そこでパケットの複製が行われ、アドレス「バックボーン分配に対するＩＰマルチキャストアドレス」とともにＳＧＳＮへ分配される。
６．アドレス「バックボーン分配に対するＩＰマルチキャストアドレス」上のペイロードをＳＧＳＮが受信すると、ＳＧＳＮはＴＥＩＤ‐Ｕをチェックし、関連ＭＢＭＳ＿Ｂｅａｒｅｒ＿Ｃｏｎｔｅｘｔを発見し、ＲＮＣへ、通例のＭＢＭＳ方法を用いてパケットを送信する。

ＧＧＳＮは、各ＭＢＭＳサービス／セッションに一意となる提案共通ＴＥＩＤ‐Ｕを効果的に選択し、受信ノード（ＲＮＣおよび２Ｇ‐ＳＧＳＮ）がＭＢＭＳサービスごとに一意のＴＥＩＤを受信するということを確証することが可能である。ＭＢＭＳ＿Ｓｅｓｓｉｏｎ＿Ｓｔａｒｔ‐ｒｅｑｕｅｓｔメッセージを使用することによって、システムはブロードキャストおよびマルチキャスト構成の両方を対処可能であるということが確証される。

ＭＢＭＳサービスを提供するＧＧＳＮが複数ある場合、これらのＧＧＳは、異なる共通ＴＥＩＤ‐Ｕを使用するであろう。使用されるこの共通ＴＥＩＤ‐ＵとＩＰマルチキャストアドレスとは、
ａ）ＧＧＳＮにおける構成および／または
ｂ）ＧＧＳＮ間の信号送信および／または
ｃ）別々のネットワーク装置、例えばＢＭ‐ＳＣ、におけるＴＥＩＤ割当て機能、および別々のネットワーク装置からＧＧＳＮへの信号送信
によって同期される。

ＳＧＳＮまたはＲＮＣにおいてすでに使用された共通ＴＥＩＤ‐Ｕを有するセッション開始要求をＳＧＳＮまたはＲＮＣが受信する場合、新しいＴＥＩＤ‐Ｕを割り当てて、それを、提案共通ＴＥＩＤ‐Ｕではなく、セッション開始応答で返すことによって、ノードはＲｅｌ‐６ＭＢＭＳユーザプレーンへフォールバックするであろう。

対立するＴＥＩＤ‐Ｕおよび後続のＲｅｌ‐６ＭＢＭＳユーザプレーンへのフォールバックを完全に回避するために、ＴＥＩＤ‐Ｕスペースの次元が使用可能である。これは、例えば、ＴＥＩＤ‐Ｕにおける３２個のビットのうちの１つを指示ＭＢＭＳに割り当てることによる場合がある。そのビットは、したがって、ＧＧＳＮが割り当てた共通ＴＥＩＤ‐Ｕに常に設定され、ＳＧＳＮまたはＲＮＣの内部に割り当てられたＴＥＩＤ‐Ｕには設定されないであろう。

ＳＧＳＮが、ＲＮＣが提案ＩＰマルチキャストアドレスと提案共通ＴＥＩＤ‐Ｕとを受け入れたかどうかについてＧＧＳＮに通知し、「バックボーン分配に対するＩＰマルチキャストアドレス」と、特定のＭＢＭＳサービス（ＲＡＮＡＰにおけるインパクト／新しいＩＥ）に対するＭＢＭＳペイロード受信に使用するための共通ＴＥＩＤ‐ＵとについてＲＮＣに通知するという追加とともに、この方法はＯＴＳ（ＴＲ２３．８７３において説明されるような、ユーザプレーン通信（すなわちペイロード）がＧＧＳＮとＲＮＣとの間で直接通信される、Ｏｎｅ Ｔｕｎｎｅｌ Ｓｏｌｕｔｉｏｎ：１トンネル解決手段）に対して等しく有効である、ということが留意されるべきである。次に、ＧＧＳＮからペイロードを受信するために、ＲＮＣは、バックボーンへＩＧＭＰメッセージ（ＩＰｖ４）またはＭＬＤメッセージ（ＩＰｖ６）を送信しなければならない。また、この場合、ＳＧＳＮは、ＲＮＣ ＩＰアドレスおよびＩＰマルチキャストを受け入れない全ＲＮＣに対するＲＮＣ ＴＥＩＤのリストをＧＧＳＮに提供しなければならない。

ＭＢＭＳマルチキャストモードとＭＢＭＳブロードキャストモードとの間の違いだけが、分配ツリーおよび特にＧＧＳＮの「ダウンストリームノードのリスト」がどのように構成されるかにある、ということがさらに留意されるべきである。ＭＢＭＳブロードキャストモードでは、リストはＢＭ‐ＳＣから受信される。ＭＢＭＳマルチキャストモードでは、それは、ＳＧＳＮから受信されるＭＢＭＳ＿Ｒｅｇｉｓｔｒａｔｉｏｎ‐ｒｅｑｕｅｓｔによって構成され、モバイル（ＭＳ）はマルチキャストセッション参加を待機している。

ホームＧＧＳＮが訪問ＧＧＳＮ（ｘＧＧＳＮすなわちＧＧＳＮプロキシ）をＳＧＳＮ（ＧＧＳＮプロキシ方法を用いるＯＴＳについて）として扱うため、この解決手段はローミングＯＴＳにもはたらくであろう、ということも留意されるべきである。ｘＧＧＳＮが、それ自身のバックボーンにおいてＩＰマルチキャストを開始するのである。つまり、ＧＧＳＮプロキシは、外部ネットワークを通したマルチキャスト搬送を使用しないことを選択可能であり（すなわちＧＲＸ）、したがってＧＧＳＮプロキシはそれ自身のＩＰアドレスおよびＴＥＩＤを返し、従来のＭＢＭＳ ＧＴＰ‐Ｕユニキャストトンネルを通してＭＢＭＳペイロードを得る。セキュリティ、技術的およびチャージの問題のため、異なるオペレータのネットワークドメイン間のマルチキャストは回避されるべきである。訪問アンカがＧＧＳＮプロキシの役割を担う、次の世代の３ＧＰＰ移動コアネットワーク仕様ａ．ｋ．ａ．ＳＡＥに対して、上述のローミング方法はこのようにはたらくことが可能である。ローミングのためにはたらくことが可能な別の方法は、ホームＰＬＭＮからユニキャストを受信して、訪問ＰＬＭＮ内でマルチキャストを送信するようにふるまうＰＬＭＮがＧＲＸネットワークへの境界にエッジルータを有する場合。第３の方法は、ＳＳＭ、ソースルートマルチキャストプロトコル（Ｓｏｕｒｃｅ ｒｏｕｔｅｄ ｍｕｌｔｉｃａｓｔ ｐｒｏｔｏｃｏｌ）を用いることで、ＰＬＭＮ間でさえＩＰマルチキャスト搬送を使用することが容認可能である、ということである場合がある。

＜ＭＢＭＳベアラコンテキスト＞
ＧＧＳＮはは、ＭＢＭＳサービスに対するＭＢＭＳ＿Ｂｅａｒｅｒ＿Ｃｏｎｔｅｘｔを維持する。提案方法で、ＧＧＳＮは、１つのサービスに対する全ダウンストリームノードについて１つの共通ＭＢＭＳ＿Ｂｅａｒｅｒ＿Ｃｏｎｔｅｘｔを維持するであろう。

一例として、ＳＧＳＮ２、３および４がＩＰマルチキャスト分配ツリーに属することを受け入れられた、サービス００１に対するＭＢＭＳ＿Ｂｅａｒｅｒ＿Ｃｏｎｔｅｘｔが、以下のようであってもよい（ＳＧＳＮ１はＩＰマルチキャスト分配に属することを拒否しており、ＧＧＳＮはＳＧＳＮ１に対して個々にパケットをコピーしなければならない、ということに留意されたい）。
MBMS_Bearer_Context_001
APN=MBMS_APN_01
…
List_of_Downstream_Nodes{
SGSN1
IP-address 192.168.100.10 TEID-U 10
SGSN2，SGSN3，SGSN4
Multicast-address 239.192.200.21 TEID-U 11
}

ＧＧＳＮは、ＳＧＳＮおよびＭＢＭＳ＿Ｂｅａｒｅｒ＿Ｃｏｎｔｅｘｔごとに１つのＴＥＩＤ‐Ｃを有するであろう（ＯＴＳについてはＳＧＳＮおよびＭＢＭＳ＿Ｂｅａｒｅｒ＿Ｃｏｎｔｅｘｔごとに１つのＴＥＩＤ‐Ｃ）。ＧＧＳＮは、（ＧＧＳＮが提案する）ＩＰマルチキャストを受け入れる全ダウンストリームノードに対してＭＢＭＳ＿Ｂｅａｒｅｒ＿Ｃｏｎｔｅｘｔごとの１つの共通ＴＥＩＤ‐Ｕを有する。ＧＧＳＮは、ユニキャストＳＧＳＮ／ＲＮＣおよびＭＢＭＳ＿Ｂｅａｒｅｒ＿Ｃｏｎｔｅｘｔごとに１つのＴＥＩＤ‐Ｕを有する。

ＲＦＣ４６０７およびＲＦＣ４６０４によるソース固有マルチキャスト（ＳＳＭ：Ｓｏｕｒｃｅ Ｓｐｅｃｉｆｉｃ Ｍｕｌｔｉｃａｓｔ）がＩＰマルチキャスト分配に使用され、ＧＧＳＮからＲＮＣへの直接トンネリング（１トンネル）が使用される場合の別の例は、ＭＢＭＳ＿Ｂｅａｒｅｒ＿Ｃｏｎｔｅｘｔは以下のようであってもよい。
MBMS_Bearer_Context_001
APN=MBMS_APN_01
…
List_of_Downstream_Nodes{
SGSN1
IP-address 192.168.100.10 TEID-U 10
SGSN2，SGSN4，RNC31，RNC32，RNC33
Multicast-address 232.192.200.21 TEID-U 11
Address-to-multicast-Source 192.168.111.21
}

＜エラー処理＞
ＳＧＳＮまたはＲＮＣが再開あるいは故障すると、故障ノードがアクティブＧＴＰ‐Ｕトンネルを有さないダウンリンクペイロードパケットを受信するときに、ＧＧＳＮはエラー表示を受信する。ＩＰマルチキャストが使用される場合、ＧＧＳＮは、エラー表示の分野からは、どのＳＧＳＮ（またはＲＮＣ）からメッセージが発せられたかわからないであろう。

しかしながら、ほとんどの場合で、ＳＧＳＮ（またはＲＮＣ）がＭＢＭＳペイロードを受信することを拒否する場合、これは再開または主要な不具合のためであろう、なぜ故障ＰＤＰコンテキストが故障ノードを識別するのであろうか。

ＳＧＳＮ（またはＯＴＳについてはＲＮＣ）が、すでにＩＧＭＰメッセージ（ＩＰｖ４）またはＭＬＤメッセージ（ＩＰｖ６）をＩＰマルチキャストバックボーンへ送信したにもかかわらず、普通ＰＤＰコンテキストペイロードを受け入れるが、何らかの理由でＩＰマルチキャストを介して受信されたＭＢＭＳペイロードを受け入れない場合にのみ、一意の問題が発生するであろう。この場合は、以下の２つの改善法が十分な解決手段を形成するためには、十分にまれであろう。

ブロードキャストの場合の改善法：未識別エラー表示を受信すると、ＧＧＳＮは、ダウンストリームノードのそのリストにおける全ＳＧＳＮ／ＲＮＣへＭＢＭＳ＿Ｓｅｓｓｉｏｎ＿Ｓｔａｒｔ‐ｒｅｑｕｅｓｔを再送する。アクティブＳＧＳＮは肯定応答を単純に返し、さらなる行動なく、メッセージを受け入れるであろう。故障ＳＧＳＮは応答せず、ＭＢＭＳ＿Ｂｅａｒｅｒ＿Ｃｏｎｔｅｘｔに対するＧＧＳＮの「ダウンストリームノードのリスト（Ｌｉｓｔ ｏｆ Ｄｏｗｎｓｔｒｅａｍ Ｎｏｄｅｓ）」から除外されるであろう。

マルチキャストの場合の改善法：ＭＢＭＳ＿Ｓｅｓｓｉｏｎ＿Ｓｔａｒｔ‐ｒｅｑｕｅｓｔの再送は許可されない。故障ＳＧＳＮに関する全ＭＢＭＳ＿ＵＥ＿ＣｏｎｔｅｘｔおよびこのＭＢＭＳ＿Ｂｅａｒｅｒ＿Ｃｏｎｔｅｘｔは削除されるであろう。しかしながら、これは可能ではないであろう、ＭＢＭＳ＿Ｂｅａｒｅｒ＿Ｃｏｎｔｅｘｔが非アクティブ化するまでなぜこれらのＭＢＭＳ＿ＵＥ＿Ｃｏｎｔｅｘｔはハンギングしたままであろうか。

上の改善法が何らかの理由で容認されないならば、ＧＧＳＮは、エラー表示を含むＩＰデータグラムのヘッダを調査しなければならないであろう。このヘッダは、エラー表示を送信したＳＧＳＮのユニキャストＩＰアドレスを含む。

故障ＳＧＳＮ／ＲＮＣがバックボーンマルチキャストネットワークへＩＧＭＰリーブを送信するであろう、ということが留意されるべきである。故障ノードがＩＧＭＰリーブを送信する場合、または何か他のやり方で、故障ノードはマルチキャストダウンリンクメッセージの受信を望まないとＩＰマルチキャストバックボーンに信号送信する場合、たとえ故障ノードがＧＧＳＮ「ダウンストリームノードのリスト」から除外されても、ＧＧＳＮは反復エラー表示を受信しないであろう。

マルチキャストセッションのリスナーがまだいるかどうかをチェックするためのＩＧＭＰ周期的「クエリ要求／クエリ応答」機構が、ＩＰバックボーンにおけるＭＢＭＳマルチキャスト搬送のペイロードの配信を結果的にスイッチオフするであろう。

オペレータがＭＢＭＳにＧＧＳＮを使用する場合、各ＧＧＳＮはそれ自身の分配ツリーを形成する。これは、今日すでに機能するものとは異なる。違いは、分配ツリーの全体または部分が今や搬送にＩＰマルチキャストを使用するであろうということである。

ＭＢＭＳに使用されるＧＧＳＮ間でＩＰマルチキャストアドレスが同期される、ということが効果的である。また、共通ＴＥＩＤ‐Ｕが効果的に同期される。この同期には色々な代替解決手段が使用可能である。
・構成（色々なＧＧＳＮにおける色々な範囲を構成する）
・ＧＧＳＮ間の信号送信（対立するアドレスおよびＴＥＩＤ‐Ｕを回避するための）
・ＢＭ‐ＳＣにおける同期機能、および同期のためのＧＧＳＮとＢＭ‐ＳＣ間への信号送信

上述のＭＢＭＳ解決手段は、ソフトウェアにおける命令組として多くのインフラストラクチャノードに実装される。図５は、概略ブロック図で、（例えばサポートノードのような）本発明によるインフラストラクチャノード（ＧＧＳＮ、ＳＧＳＮ、またはＲＮＣ）を説明し、処理ユニット５０１が通信データと通信制御情報とを処理する。インフラストラクチャノード５００は、揮発性（例えばＲＡＭ）５０２および／または不揮発性メモリ（例えばハードディスクまたはフラッシュディスク）５０３と、インターフェースユニット５０４とをさらに備える。インフラストラクチャノード５００は、ダウンストリーム通信ユニット５０５と、アップストリーム通信ユニット５０６とをさらに含んでもよく、各々はそれぞれの接続インターフェースを有する。インフラストラクチャノードにおける全ユニットは、処理ユニット５０１を通して直接または非直接に互いに通信可能である。ネットワークに添付される移動ユニットへおよびから通信を処理するソフトウェアは、少なくとも部分的にこのノードで実行され、このノードに格納されること場合もある。しかしながらソフトウェアは、ノードの開始の際に、または後の段階、例えばサービスインターバルで、動的にロードされる場合もある。ソフトウェアは、コンピュータプログラムプロダクトとして実施可能であり、例えば例えばディスケット、ＣＤ（コンパクトディスク）、ＤＶＤ（デジタルビデオディスク）、フラッシュまたは同様のリムーバブルメモリ媒体（例えばコンパクトフラッシュ、ＳＤセキュアデジタル、メモリスティック、ミニＳＤ、ＭＭＣマルチメディアカード、スマートメディア、トランスフラッシュ、ＸＤ）、ＨＤ‐ＤＶＤ（高解像度ＤＶＤ）、またはブルーレイＤＶＤ、ＵＳＢ（ユニバーサルシリアルバス）ベースのリムーバブルメモリ媒体、磁気テープ媒体、光格納媒体、光磁気媒体、バブルメモリのようなリムーバブルコンピュータ読出し可能媒体に分配および／または格納可能であり、またはネットワーク（例えばイーサネット、ＡＴＭ、ＩＳＤＮ、ＰＳＴＮ、Ｘ．２５、インターネット、ローカルエリアネットワーク（ＬＡＮ）、またはＧＧＳＮへデータパケット搬送可能な同様のネットワーク）を介して伝搬信号として分配可能である。

図６は、本発明によるデータパケット６００を概略的に示す。データパケット６００は、ＩＰマルチキャストアドレスを有するヘッダ６０１と、ＧＴＰＴＥＩＤ６０２とを備える。この中には、ＭＢＭＳマルチキャストアドレス６０３が位置し、最後にメディアコンテンツデータを有するペイロード６０４がある。

この発明の効果は、ＧＧＳＮとＳＧＳＮとの間の効率的なバックボーン分配がＭＢＭＳサービスに使用可能である、ということである。この方法なくては、ＧＧＳＮは、Ｇｎインターフェースへ、ＭＢＭＳパケットをコピーすることから、重くダウンロードされる場合がある。

さらに、この発明にカバーされる解決手段は、ＧＳＭまたはＵＭＴＳネットワークにおけるパケット交換ドメインに焦点を当てる。しかしながらこの解決手段は、トンネリングが適用される場合のように、２つのＩＰレイヤ、１つのアプリケーションＩＰレベルおよび１つの送信ＩＰレベルを有するネットワークへ一般的に適用可能である。一般に、この考えは、例えばＧＴＰ、Ｌ２ＴＰ、ＩＰＳｅｃ、および移動ＩＰにおいて、トンネリングが使用されるときならいつでも適用可能である。また、例えばＡＴＭのような、マルチキャスト送信を支援する別の技術にトランスポートレイヤが基づく場合に、この機構は適用可能である。

さらに、同一の機構が適用して、例えばポイントツーマルチポイントストリーミング（ＲＴＳＰ）または対話型マルチメディアサービス（ＳＩＰ）のようなアプリケーション用マルチキャストトランスポートグループを作成することが可能である、ということが理解されるべきである。

３ＧＰＰ内のＭＢＭＳの基準における変化：ＴＳ２３．２４６（参照することにより、ここに組み入れるものとする）に関連して、本発明をさらに詳細に議論することにする。

ＵＴＲＡＮ／ＧＥＲＡＮは、指定ＭＢＭＳサービスエリアへＭＢＭＳデータを効果的に配信する責任を担う。マルチキャストモードでのＭＢＭＳデータの効果的配信には、例えばＭＢＭＳ送信の前および間におけるセル内のユーザの数を使用して適当な無線ベアラを選択可能であるということなど、ＵＴＲＡＮ／ＧＥＲＡＮにおける機構が必要な場合がある。ＭＢＭＳ送信は断続的に開始および終了可能である。ＵＴＲＡＮ／ＧＥＲＡＮは、コアネットワークによってＭＢＭＳ送信の開始および終了をサポートするであろう。さらに、ＵＴＲＡＮ／ＧＥＲＡＮは、多くのＵＥが共有するＩｕベアラを通してコアネットワークからＭＢＭＳデータを受信可能であろう。ＵＴＲＡＮは、ＩＰマルチキャストを通したコアネットワークからのＭＢＭＳデータの受信をサポートする場合もある。ＵＴＲＡＮ／ＧＥＲＡＮは、ＭＢＭＳ受信機のイントラＲＮＣ／ＢＳＣおよびインターＲＮＣ／ＢＳＣモビリティの両方をサポートするであろう。モビリティは、制約されたデータロスを引き起こすと予測される。したがって、ＭＢＭＳユーザサービスは、ＵＥモビリティが引き起こす潜在的データロスを対処可能であるべきである。ＵＴＲＡＮ／ＧＥＲＡＮは、ＭＢＭＳユーザサービスアナウンス、ページング情報（非ＭＢＭＳ固有）を送信可能であり、ＭＢＭＳと並行して他のサービスをサポート可能であろう（例えば、端末能力に依存して、ＭＢＭＳビデオコンテンツを受信する間に、ユーザはコールを発信または受信可能であり、またはメッセージを送信および受信可能である）。

＜ＳＧＳＮ＞
ＭＢＭＳアーキテクチャ内のＳＧＳＮの役割は、ＭＢＭＳベアラサービス制御機能を行うことと、ＵＴＲＡＮ／ＧＥＲＡＮへＭＢＭＳ送信を提供することである。ＭＢＭＳマルチキャストの場合、ＭＢＭＳベアラサービス制御機能が個々のＵＥごとに行われる。ＭＢＭＳブロードキャストモードの場合、制御機能はＵＥに独立に行われる。ＩＰマルチキャストがＭＢＭＳ送信に使用されると、３Ｇ、すなわちＧＧＳＮからＲＮＣへ送信されるＭＢＭＳデータの場合において、ＳＧＳＮはバイパスされる場合がある。ＳＧＳＮは、イントラ」ＳＧＳＮおよびインターＳＧＳＮモビリティ手続に対するサポートを提供するであろう。特にこれには、ＳＧＳＮがアクティブ化マルチキャストＭＢＭＳベアラサービスごとにユーザ固有ＭＢＭＳ ＵＥコンテンツを格納し、このコンテンツをインターＳＧＳＮモビリティ手続の間に新しいＳＧＮＳへ渡すことが必要である。ＳＧＳＮは、そのＭＢＭＳサポートをＵＥへ示すことが可能であり、ＵＥと同期も可能であろう。ＵＥのＭＢＭＳ ＵＥコンテンツはなおもアクティブである。ＳＧＳＮはユーザごとにチャージングデータを生成可能であろう。ＳＧＳＮは、ＭＢＭＳベアラサービスまたはＭＢＭＳユーザサービスに対するオンラインチャージングを行わない（これはＢＭ‐ＳＣにおいて処理される）。ＳＧＳＮは、ＧＧＳＮからセッション開始を受信すると、多くのユーザが共有するＩｕおよびＧｎベアラを確立可能であろう。同様に、ＳＧＳＮは、ＧＧＳＮからの命令のうえでこのベアラを破棄（ｔｅａｒ ｄｏｗｎ）可能である

＜ＧＧＳＮ＞
ＭＢＭＳアーキテクチャ内のＧＧＳＮ役割は、ＭＢＭＳデータとしてのＩＰマルチキャストに対するエントリーポイントとしてはたらくことである。ＢＭ‐ＳＣからの通知のうえで、ＧＧＳＮは、マルチキャストＭＢＭＳ送信に対するベアラプレーンの確立を要求可能であろう。さらにＢＭ‐ＳＣ通知のうえで、ＧＧＳＮは確立ベアラプレーンを破棄可能であろう。マルチキャストサービスに対するベアラプレーン確立が、特定のマルチキャストＭＢＭＳベアラサービスに対する送信を受信するように要求されたＳＧＳＮおよび／またはＲＮＣに向けて実行される。ブロードキャストサービスについては、アップストリームノードから、特にＧＧＳＮにおいてはＢＭ‐ＳＣから受信される「ダウンストリームノードのリスト」に含まれるＳＧＳＮおよび／またはＲＮＣに向けて、ベアラプレーン確立は実行される。最適化ベアラプレーンについては、ＩＰマルチキャスト搬送がコアネットワーク内で使用可能である。すると、ＧＧＳＮとＳＧＳＮとの間に、および／または直接ＧＧＳＮとＲＮＣとの間に、ベアラプレーンが確立される。ＧＧＳＮはＭＢＭＳ固有ＩＰマルチキャストトラフィックを受信し、このデータを、ＭＢＭＳベアラサービスの一部としてセットアップされた適当なＧＴＰトンネルにルーティング可能であろう。ＭＢＭＳに限定されない、ＭＢＭＳベアラサービスをサポートする特徴を提供することも、ＧＧＳＮは可能である。例としては、
‐メッセージスクリーニング（ＭＢＭＳソースがＰＬＭＮの内部にある場合には必要なし）
‐チャージングデータ収集
‐フローベースのチャージング

＜ＭＢＭＳベアラコンテキスト＞
ＭＢＭＳベアラコンテキストは、ＲＡＮにおいてＭＢＭＳサービスコンテキストと呼ばれるものであるが、特定のＭＢＭＳベアラサービスを説明する全情報を含み、ＭＢＭＳデータの配信に関する各ノードにおいて作成される。ＭＢＭＳマルチキャストモードについては、第１のＭＢＭＳ ＵＥコンテキストがノードにおいて作成されると、またはダウンストリームノードがそれを要求すると、ＭＢＭＳベアラコンテキストがＳＧＳＮおよびＧＧＳＮにおいて作成される。ＭＢＭＳブロードキャストモードについては、ＭＢＭＳセッション開始メッセージがアップストリームノードから受信されると、ＭＢＭＳベアラコンテキストがＳＧＳＮおよびＧＧＳＮにおいて作成される。ＭＢＭＳベアラコンテキストがＢＭ‐ＳＣプロキシ搬送機能において静的に構成される。これがどのように行われるかは、本明細書の範囲外である。第１のＭＢＭＳ ＵＥコンテキストがＢＳＣ／ＳＲＮＣにおいて作成されると、ＭＢＭＳベアラコンテキストはＩｕモードＢＳＣにおいて、およびＳＲＮＣにおいて作成される。ＭＢＭＳセッション開始手続は、ＭＢＭＳベアラコンテキストを未だ有さないＢＳＣ／ＲＮＣにおいてＭＢＭＳベアラコンテキストを作成可能である。

ＭＢＭＳベアラコンテキストは、ひとたび作成されると、対応するＭＢＭＳベアラサービスのベアラプレーン資源ステータスを反映する２つの状態のうち１つとなり得る。
‐「アクティブ（ａｃｔｉｖｅ）」は、ＭＢＭＳデータの転送のためにベアラプレーン資源がネットワークにおいて必要とされるＭＢＭＳベアラコンテキストの状態を反映する。この状態は、対応するＭＢＭＳセッションが進行中である限り維持される。
‐「スタンバイ（ｓｔａｎｂｙ）」は、ＭＢＭＳデータの転送のためにベアラプレーン資源がネットワークにおいて必要とされないＭＢＭＳベアラコンテキストの状態を反映する。この状態は、対応するＭＢＭＳセッションが進行中でない限り維持される。

＜サービス品質＞
ネットワークにとって、マルチキャストおよびブロードキャストＭＢＭＳベアラサービスのセッションに対するサービス品質パラメータを制御するということが可能であろう。ＴＳ２３．１０７に説明されるＵＭＴＳベアラサービスに関する全ＱｏＳ属性がＭＢＭＳベアラサービスに適用可能である。ポイントツーポイントベアラサービスと比較すると、以下の限定が存在する。
‐トラフィッククラスについて、バックグラウンドおよびストリーミングクラスのみがサポートされるであろう。
‐ＳＤＵエラー率について、より高い値のみがサポートされる、すなわちより高い数の損失または崩壊ＳＤＵを説明する値（バックグラウンドおよびストリーミングクラスに対する実際の値は１０−２および１０−１である。）。
‐最大ビットレートについては、ＴＳ２２．２４６に記載の値を参照。
‐ストリーミングトラフィッククラスの保証ビットレートについて：他のサービスによる無線資源使用に依存して、ＭＢＭＳサービスエリアのいくつかのセルは、ＭＢＭＳセッションに使用可能な十分な資源を有さない場合がある。ＲＡＮは、必要な資源が使用不可能であるセルにおいてＲＢを確立しないと決める場合がある。１または２以上のセルが無線ベアラを確立するに十分な資源を有さずとも、ＲＡＮはＭＢＭＳセッション開始要求メッセージを拒否しない。

バックグラウンドクラスのＭＢＭＳベアラサービスは、メッセージングまたはダウンロードのようなＭＢＭＳユーザサービスの搬送に最も適している。バッファリング、スキーム成形およびパケットドロッピングは、使用可能な資源に適応するトラフィックフローに適用可能であり、ネットワーク条件を変化させる。通常、コンテンツは全体で受信され、ユーザがアクセス可能となる前にＵＥに格納されているはずであるため、全転送時間はバックグラウンドクラスベアラサービスにとっては重大なものではない。

ストリーミングクラスのＭＢＭＳベアラサービスは、ストリーミングのようなＭＢＭＳユーザサービスに搬送に最も適している。ポイントツーポイントベアラサービスについて、ネットワークは、可能な限りストリーミングクラスベアラサービスのパケット転送遅延（および遅延ジッタ）を最小化するであろう。パケットドロッピングは、使用可能な資源に適応されるトラフィックフローに適用される好ましいトラフィック調節行動であろう。

ＭＢＭＳに対するバックグラウンドおよびストリーミングクラス間の原則差異は、ストリーミングの場合の保証ビットレートのサポートである。ＲＡＮが必要なＱｏＳを提供できない場合、ＵＥへ表示が提供されない。結果として、いくつかのＵＥは、ＭＢＭＳセッションまたはその部分を受信しない場合がある。バックグラウンドクラスについて、ＲＡＮは、輻輳状況だが潜在的に高いパケットロスレートではデータを分配することを続行しない場合があり、したがってＭＢＭＳユーザサービスは、高パケットロスを対処するために、データ内に十分な冗長を提供しなければならないであろう。しかしながら、通常はバックグラウンドクラスのＭＢＭＳベアラサービスを使用するであろうＭＢＭＳユーザサービスは、ＭＢＭＳユーザサービスが高パケットロスを対処できない場合には、ストリーミングクラスＭＢＭＳベアラサービスを使用することを決定可能である。

ＭＢＭＳベアラサービスの割当ておよび保持優先順位は、ＭＢＭＳベアラサービス間の、およびＭＢＭＳベアラサービスと非ＭＢＭＳベアラサービスとの間の優先順位付けを可能とする。

ＭＢＭＳベアラサービスは、並行して多くのＵＥへデータを転送し、無線レベル上のフィードバックチャネルの欠如のため、低ＳＤＵエラー率は達成が困難である。得られるパケットエラー率がＭＢＭＳユーザサービスに適当でない場合、またはデータロスの防止が必要とされる場合、ＭＢＭＳユーザサービスは、ポイントツーポイントＰＤＰコンテキストを通してＭＢＭＳデータの再送信を実行可能である。

＜ＭＢＭＳ ＱｏＳ分配ツリー＞
ＭＢＭＳデータは、多くのＢＳＣ／ＲＮＣと多くのＳＧＳＮと１または２以上のＧＧＳＮとを通過するＭＢＭＳ分配ツリーを通して複数のユーザへ分配されるであろう。さらに、いくつかのベアラ資源が、資源を節約するために、同一のＭＢＭＳベアラサービスにアクセスする多くのユーザ間で共有可能である。結果として、ＭＢＭＳ分配ツリーの各枝は、効果的には同一のＱｏＳで確立される。ＭＢＭＳ分配ツリーは、効果的にはその全ての枝に同一のＱｏＳを有する。ＭＢＭＳ分配ツリーの枝が作成された場合、別の枝にとって、（例えば、枝の削除および新しい枝の追加で、新しいＵＥの到着またはＵＥの位置の変化のため）すでに確立された枝のＱｏＳに衝突することは適当ではない。

ネットワークエレメント間（例えばＲＮＣとＳＧＳＮとの間）にＱｏＳ（再）ネゴシエーションはない。これは、接続されたネットワークノードがＱｏＳ要求を受け入れられない場合にはいくつかの枝が確立されない場合がある、ということを示す。

＜一時的モバイルグループアイデンティティ＞
一時的モバイルグループアイデンティティ（ＴＭＧＩ：Ｔｅｍｐｏｒａｒｙ Ｍｏｂｉｌｅ Ｇｒｏｕｐ Ｉｄｅｎｔｉｔｙ）がＭＢＭＳ通知目的で使用される。ＢＭＳＣは、ＭＢＭＳベアラサービスごとに、グローバルに一意のＴＭＧＩを割り当てる。ＴＭＧＩの構造は、ＴＳ２３．００３（参照することにより、ここに組み入れるものとする）において定められる。マルチキャストＭＢＭＳベアラサービスについては、ＴＭＧＩはＭＢＭＳマルチキャストサービスアクティブ化手続を介してＵＥへ送信される。ブロードキャストサービスについては、ＴＭＧＩはサービスアナウンスを介して得ることができる。ＴＭＧＩは無線資源効率的ＭＢＭＳベアラサービス識別であり、ＩＰマルチキャストアドレスとＡＰＮとからなるＭＢＭＳベアラサービス識別と均等のものである。

＜ＩＰマルチキャスト分配＞
ＧＧＳＮにおいて、それは、構成により、バックボーンネットワークにおいてＩＰマルチキャストを用いることで、ＭＢＭＳペイロードのあり得る可能な分布であろう。ＩＰマルチキャスト分配が、ＧＧＳＮからダウンストリームノードへ（ＧＧＳＮからＳＧＳＮへ、またはＧＧＳＮから直接ＲＮＣへ）行われる。ソース固有マルチキャスト（ＳＳＭ：Ｓｏｕｒｃｅ Ｓｐｅｃｉｆｉｃ Ｍｕｌｔｉｃａｓｔ）サービスモデルが、ＲＦＣ４６０７およびＲＦＣ４６０４に指定されるように、ノードおよびルータによって使用されるであろう。レガシーポイントツーポイント分配へのフォールバックが、ＩＰマルチキャスト分配をサポートしないノードに対して行われる。

ＧＧＳＮは、共通ＴＥＩＤ‐Ｕとして、分配ためのＩＰマルチキャストアドレスと、ソースアドレスとを選択する。分配のための提案ＩＰマルチキャストおよびソースアドレスと共通ＴＥＩＤ‐Ｕは、セッション開始におけるダウンストリームＳＧＳＮへＧＧＳＮによって示される。ＳＧＳＮは、提案ＩＰマルチキャスト分配を受け入れるかまたは拒否することが可能であり、これをＭＢＭＳセッション開始応答で示すことが可能である。受け入れられると、ベアラサービスマルチキャスト分配に参加するため、ＳＧＳＮはチャネル（ＩＰマルチキャストおよびソースアドレス）をバックボーンへ報告し、ＧＧＳＮはＩＰマルチキャスト分配を用いてベアラサービスユーザデータグラムをバックボーン上に送るであろう。ＳＧＳＮがＩＰマルチキャスト分配を受け入れない場合、ＧＧＳＮは、当のＳＧＳＮへのユニキャスト分配へフォールバックするであろう。

分配のための提案ＩＰマルチキャストおよびソースアドレスと共通ＴＥＩＤ‐Ｕは、さらに、セッション開始におけるダウンストリームＲＮＣ（およびＩｕモードのＢＳＣ）へＳＧＳＮによって示される。ＲＮＣは、ＳＧＳＮへのＭＢＭＳセッション開始応答で提案ＩＰマルチキャスト分配を受け入れる、または拒否することが可能である。受け入れられると、ＲＮＣは、ベアラサービスマルチキャスト分配に参加するため、チャネル（ＩＰマルチキャストおよびソースアドレス）をバックボーンに報告するであろう。全ダウンストリームＲＡＮノードがＩＰマルチキャスト分配を受け入れ、ＧｂモードのＢＳＣがダウンストリーム分配ツリーに存在しない場合、ＳＧＳＮは、バックボーンへチャネルを報告する必要がない。

ダウンストリームノードは、セッション開始応答で、ＩＰマルチキャスト分配が受け入れられるかどうかを示すであろう。この表示が欠損する場合、アップストリームノードは、ダウンストリームノードを、ＩＰマルチキャスト分配を受け入れていないものとして扱い、ユニキャスト分配を使用するであろう。ＧＧＳＮは、ＲＦＣ４６０７によるＭＢＭＳ分配に使用されるＩＰマルチキャストアドレスを割り当てるであろう。いくつかのＧＧＳＮがＭＢＭＳペイロード分配に使用されると、使用されるＩＰマルチキャストアドレスおよび共通ＴＥＩＤは構成によって調整されるであろう。ＧＧＳＮが割り当てる共通ＴＥＩＤとＳＧＳＮおよびＲＮＣが割り当てるＴＥＩＤとの間のクラッシュを回避するＧＴＰ‐Ｕにおける機構があろう。

＜ＭＢＭＳセッション開始手続＞
ＢＭ‐ＳＣは、データ送信準備ができると、ＭＢＭＳセッション開始手続を開始する。これは、ＭＢＭＳデータの転送のために、ネットワークにおける全部の必要なベアラ資源をアクティブ化し、送信の緊急開始の関与ＵＥを通知する要求である。この手続を通して、ＱｏＳ、ＭＢＭＳサービスエリア、推定セッション期間、ＭＢＭＳデータ転送時間のようなＭＢＭＳセッション属性が、対応するＭＢＭＳベアラサービスに対して事前に登録されたＧＧＳＮおよびＳＧＳＮへ、および登録ＳＧＳＮに接続される全ＢＳＣ／ＲＮＣへ提供される。加えて、手続は、全登録ＧＧＳＮおよび全登録ＳＧＳＮに、およびセッション開始要求メッセージに応答するＢＳＣ／ＲＮＣにベアラプレーンを割り当てる。セッション開始要求メッセージを送信した後、ＭＢＭＳデータを送信する前に、ＢＭ‐ＳＣは構成可能遅延（ＭＢＭＳデータ転送時間）を待機する。この遅延は、ＢＭ‐ＳＣ以外のエンティティにおいてＭＢＭＳデータのバッファリングを回避するに十分長くあるべきである。すなわちこの遅延は、ＢＭ‐ＳＣがＭＢＭＳデータを送信する前にＭＢＭＳデータ転送を可能とするに必要な全手続をネットワークが行うことを可能とするものであるべきである。例えば、ＵＥの通知と無線ベアラ確立は、ＭＢＭＳデータがＲＡＮに到着する前に行われるべきである。遅延は数秒または数十秒の領域にあってもよい。ＢＭ‐ＳＣにとって、２Ｇおよび３ＧのＭＢＭＳベアラサービスにそれぞれ異なる遅延を構成可能であることが有用である場合がある。

マルチキャストＭＢＭＳベアラサービスについては、ＳＧＳＮおよびＧＧＳＮの登録は、ＭＢＭＳマルチキャストサービスアクティブ化手続、インターＳＧＳＮルーティングエリア更新手続、インターＳＧＳＮサービングＲＮＳ再配置手続によって開始され、ＭＢＭＳ登録手続によって行われる。ハンドオーバのためにも、インター無線アクセス技術（ＩＲＡＴ：Ｉｎｔｅｒ Ｒａｄｉｏ Ａｃｃｅｓｓ Ｔｅｃｈｎｏｌｏｇｙ）ＰＳハンドオーバについて、登録に関連して言及すべきである。ブロードキャストＭＢＭＳベアラサービスについては、ＢＭ‐ＳＣおよびＧＧＳＮのダウンストリームノードのリストは以下のように達成される。
‐ＧＧＳＮに対するダウンストリームノードのリストは、セッション開始要求でＢＭ‐ＳＣからＧＧＳＮへ送信されるであろう。
通常、ＢＭ‐ＳＣに対する「ダウンストリームノードのリスト」に含まれるＧＧＳＮは、デフォルトＧＧＳＮ（耐性（ｒｅｓｉｌｉｅｎｃｅ）のためには２つ）である。

ステップ番号を示しつつ、全体的セッション開始手続を図７に提示する。

７０１．ＢＭ‐ＳＣセッションおよび送信機能はセッション開始要求メッセージを送信し、差し迫った送信開始を示し、セッション属性（ＴＭＧＩ、ＱｏＳ、ＭＢＭＳサービスエリア、セッション識別子、推定セッション期間、ブロードキャスト／マルチキャスト、ＧＧＳＮに対するダウンストリームノードのリスト（ブロードキャストのみ）、ＭＢＭＳデータ転送時間、……）と２Ｇ／３Ｇインジケータとを提供する。メッセージがＢＭ‐ＳＣプロキシおよび搬送機能へ送信され、次にＢＭ‐ＳＣプロキシおよび搬送機能は、対応するＭＢＭＳベアラコンテキストの「ダウンストリームノードのリスト」パラメータに載っているＧＧＳＮへメッセージを転送する。ＢＭ‐ＳＣプロキシおよび搬送機能は、そのＭＢＭＳベアラコンテキストの状態属性を「アクティブ」に設定する。ブロードキャストＭＢＭＳベアラサービスについて、ＧＧＳＮがＭＢＭＳベアラコンテキストを作成する。ＧＧＳＮは、セッション属性とダウンストリームノードのリストとをＭＢＭＳベアラコンテキストに格納し、そのＭＢＭＳベアラコンテキストの状態属性を「アクティブ」に設定し、ＭＢ‐ＳＣへセッション開始応答メッセージを送信する。それをＢＭ‐ＳＣセッションおよび搬送機能へ転送するプロキシおよび搬送機能。ＢＭ‐ＳＣプロキシおよび搬送機能は、チャージングの目的で、ＢＭ‐ＳＣメンバーシップ機能へセッション開始要求をコピーする。

７０２．ＧＧＳＮは、セッション属性（ＴＭＧＩ、ＱｏＳ、ＭＢＭＳサービスエリア、セッション識別子、推定セッション期間、ブロードキャスト／マルチキャスト、ＭＢＭＳデータ転送時間、バックボーン分配のためのＩＰマルチキャストおよびソースアドレス、共通ＴＥＩＤ‐Ｕ、……）と２Ｇ／３Ｇインジケータとを含むＭＢＭＳセッション開始要求メッセージを、対応するＭＢＭＳベアラコンテキストの「ダウンストリームノードのリスト」パラメータに載っているＳＧＳＮへ送信する。ブロードキャストＭＢＭＳベアラサービスについて、ＳＧＳＮがＭＢＭＳベアラコンテキストを作成する。ＳＧＳＮは、セッション属性と２Ｇ／３ＧインジケータとをＭＢＭＳベアラコンテキストに格納し、そのＭＢＭＳベアラコンテキストの状態属性を「アクティブ」に設定する。ＳＧＳＮがセッション開始とバックボーン分配のための提案ＩＰマルチキャストおよびソースアドレス（と提案共通ＴＥＩＤ‐Ｕ）とを受け入れる場合、ＳＧＳＮは、ＩＰマルチキャスト分配が受け入れられるという表示を含めて、ＭＢＭＳセッション開始応答メッセージをＧＧＳＮへ送信し、「バックボーン分配のためのＩＰマルチキャストおよびソースアドレス」のマルチキャストアドレス部にユーザプレーンＩＥのためのＳＧＳＮアドレスを設定し、ＧＧＳＮがＭＢＭＳデータ転送に使用するであろうベアラプレーンのためのＴＥＩＤを、ＧＧＳＮから受信される「共通ＴＥＩＤ‐Ｕ」に設定する。ＳＧＳＮがバックボーン分配のための提案ＩＰマルチキャストおよびソースアドレス（または提案共通ＴＥＩＤ‐Ｕ）を受け入れない場合、ＳＧＳＮは、これを、ＩＰマルチキャスト分配が受け入れられないという表示を含む（または表示を除外する）ことで示し、ユーザトラフィックに対する普通ユニキャストＳＧＳＮアドレスと、ＳＧＳＮが選択するＴＥＩＤ‐Ｕとを、ＭＢＭＳセッション開始応答メッセージに含むであろう。ＭＢＭＳベアラサービスについては、複数のＭＢＭＳセッション開始要求メッセージを受信するＳＧＳＮが、例えば第１のＭＢＭＳセッション開始要求メッセージに対して、１つのＧＧＳＮを有するただ１つのベアラプレーンを確立する。

７０３．ＳＧＳＮは、セッション属性（ＴＭＧＩ、ＱｏＳ、ＭＢＭＳサービスエリア、セッション識別子、推定セッション期間、ブロードキャスト／マルチキャスト、ＭＢＭＳデータ転送時間、ＲＡのリスト、……）を含むＭＢＭＳセッション開始要求メッセージを、このＳＧＳＮに接続される各ＢＳＣおよび／または各ＲＮＣへ送信する。メッセージがＩｕモードのＲＮＣ／ＢＳＣへ送信されると、ＧＧＳＮから受信される場合にはバックボーン分配のためのＩＰマルチキャストアドレスと共通ＴＥＩＤ‐Ｕとがまた含まれるであろう。２Ｇ／３Ｇインジケータは、ＭＢＭＳセッション開始要求メッセージがＢＳＣのみへ、またはＲＮＣのみへ、またはＲＮＣとＢＳＣとの両方へ送信されるかどうかを定めるために、ＳＧＳＮによって使用されるであろう。ブロードキャストＭＢＭＳベアラサービスについて、ＢＳＣ／ＲＮＣがＭＢＭＳサービスコンテキストを作成する。（Ｉｕモードの）ＢＳＣおよび／またはＲＮＣは、ＭＢＭＳサービスコンテキストにセッション属性を格納し、そのＭＢＭＳサービスコンテキスト状態属性を「アクティブ」に設定し、ＭＢＭＳセッション開始応答メッセージで応答する。ＲＮＣ／ＩｕモードＢＳＣは、ＳＧＳＮがＭＢＭＳデータの転送に使用するであろうＩｕベアラプレーンのためのＭＢＭＳセッション開始応答メッセージにＴＥＩＤを含む。ＲＮＣがセッション開始と、バックボーン分配のための提案ＩＰマルチキャストアドレス（と提案共通ＴＥＩＤ‐Ｕ）とを受け入れる場合、ＲＮＣは、ＩＰマルチキャスト分配が受け入れられるという表示を含めて、ＭＢＭＳセッション開始応答メッセージをＳＧＳＮへ送信する。ＲＮＣがバックボーン分配ための提案ＩＰマルチキャストアドレス（または提案共通ＴＥＩＤ‐Ｕ）を受け入れない場合、ＲＮＣは、これを、ＩＰマルチキャスト分配が受け入れられないという表示を含める（または表示を除外する）ことで示し、ＩｕベアラプレーンのためのＴＥＩＤ‐ＵをＭＢＭＳセッション開始応答メッセージに含めるであろう、ＭＢＭＳサービスエリアにサービスしないＧｂモードのＢＳＣはセッション属性を格納する必要がない。複数のＭＢＭＳセッション開始要求メッセージを受信するＢＳＣ／ＲＮＣが、１つのＳＧＮＳを有するただ１つのベアラプレーンを確立する。

７０３ａ．ＲＮＣがＩＰマルチキャスト分配を受け入れる場合、ＲＮＣはバックボーンにおけるマルチキャストグロープに参加する。それは、ＲＦＣ３３７６、ＲＦＣ３８１０およびＲＦＣ４６０４でセットアップされる手続で参加するであろう。

７０３ｂ．少なくとも１つのＲＮＣがＩＰマルチキャスト分配を受け入れない場合、またはＧｂモードのＢＳＣがある場合、ＳＧＳＮはＩＰバックボーンにおけるマルチキャストグループに参加する。それは、ＲＦＣ３３７６、ＲＦＣ３８１０およびＲＦＣ４６０４でセットアップされる手続きで参加するであろう。

７０４．ＢＳＣ／ＲＮＣは、関与ＵＥへのＭＢＭＳデータの転送に必要な無線資源を確立する。ＲＡＮ資源セットアップは、ＭＢＭＳデータ転送時間パラメータにしたがって、スケジューリング可能である。

アップストリームノードは、通常、ＭＢＭＳセッションに１度、ＭＢＭＳセッション開始要求メッセージをダウンストリームノードへ提供するということが留意されるべきである。しかしながら、「複数コアネットワークノードへのＲＡＮノードのイントラドメイン接続」のため、ＢＳＣ／ＲＮＣがいくつかのＳＧＳＮからＭＢＭＳセッション開始要求メッセージを受信する場合がある。

＜ＭＢＭＳセッションストップ手続＞
ＢＭ‐ＳＣセッションおよび送信機能は、ＭＢＭＳセッションが終了すべきと見なすと、ＭＢＭＳセッション終了手続を開始する。ネットワークにおけるベアラプレーン資源の解放を正当化するに十分長い時間、送信されることを期待されるＭＢＭＳデータがもうない場合、セッションは典型的に終了される。手続は、対応するＭＢＭＳベアラサービスに登録される全ＳＧＳＮおよびＧＧＳＮへ、およびＳＧＳＮを有する確立Ｉｕベアラプレーンを有するＢＳＣ／ＲＮＣへ伝搬される。

全体的ＭＢＭＳセッション終了手続を図８に提示する。

８０１．ＢＭ‐ＳＣセッションおよび送信機能は、ＢＭ‐ＳＣプロキシおよび搬送機能へセッション終了要求メッセージを送信し、ＢＭ‐ＳＣプロキシおよび搬送機能は、それを、影響を受けるＭＢＭＳベアラコンテキストの「ダウンストリームノードのリスト」パラメータに載っている全ＧＧＳＮへ転送し、ＭＢＭＳセッションが終了してベアラプレーン資源が解放可能であるということを示す。ＢＭ‐ＳＣプロキシおよび搬送機能は、そのＭＢＭＳベアラコンテキストの状態属性を「スタンバイ」に設定する。ＧＧＳＮは、ＢＭ‐ＳＣプロキシおよび搬送機能へセッション終了応答メッセージを送信し、ＢＭ‐ＳＣプロキシおよび搬送機能は、それをＢＭ‐ＳＣセッションおよび送信機能へ転送する。ＢＭ‐ＳＣプロキシおよび搬送機能は、チャージングの目的で、ＢＭ‐ＳＣメンバーシップ機能へセッション終了要求をコピーする。

８０２．ＧＧＳＮは、ＧＧＳＮで確立されるベアラプレーンを有する全ＳＧＳＮへＭＢＭＳセッション終了要求メッセージを送信し、これらのＳＧＳＮに向かう対応のベアラプレーン資源を解放し、そのＭＢＭＳベアラコンテキストの状態属性を「スタンバイ」に設定する。ブロードキャストＭＢＭＳベアラサービスの場合、ＧＧＳＮはＭＢＭＳベアラコンテキストを解放する。

８０２ａ．ＳＧＳＮがＩＰマルチキャスト分配を使用している場合、それは特定のＭＢＭＳベアラサービスのＩＰバックボーンからの受信を不可能にする。それは、ＲＦＣ３３７６、ＲＦＣ３８１０およびＲＦＣ４６０４でセットアップされる手続を使用するであろう。

８０３．ＳＧＳＮは、影響を受けるＭＢＭＳベアラサービスに対してＧＧＳＮからＭＢＭＳデータを受信していたＴＥＩＤおよびベアラプレーン資源を解放し、ＳＧＳＮで確立されるベアラプレーンを有する全ＢＳＣ／ＲＮＣへＭＢＭＳセッション終了要求メッセージを送信する。ブロードキャストＭＢＭＳベアラサービスの場合、ＳＧＳＮはＭＢＭＳベアラコンテキストを解放する。

８０３ａ．ＲＮＣ／ＢＳＣがＩＰマルチキャスト分配を使用している場合、それは特定のＭＢＭＳベアラサービスのＩＰバックボーンからの受信を不可能とする。それは、ＲＦＣ３３７６、ＲＦＣ３８１０およびＲＦＣ４６０４でセットアップされる手続を使用するであろう。

８０４．ＲＮＣは、影響を受ける無線およびＩｕ資源を解放し、ＢＳＣは、影響を受ける無線資源を解放する。ブロードキャストＭＢＭＳベアラサービスの場合、ＢＳＣ／ＲＮＣはＭＢＭＳサービスコンテキストを解放する。アクティブなＭＢＭＳコンテキストがＢＳＣにないとしても、ＧｂモードのＢＳＣがＳＧＳＮへ肯定応答を送信するであろう。

＜ＭＢＭＳ登録抹消手続＞
＜共通ＭＢＭＳ登録抹消手続＞
ＭＢＭＳ登録抹消とは、ダウンストリームノードが特定のＭＢＭＳベアラサービスに対する信号送信、セッション属性およびデータをもはや受信する必要がなく、したがって対応する分配ツリーからの削除を望むということをアップストリームノードに通知する手続である。ＭＢＭＳ登録抹消手続は、
‐特定のＭＢＭＳベアラサービスに対する最後のＭＢＭＳ ＵＥコンテキストがノードから消去され、対応するＭＢＭＳベアラコンテキストにおける「ダウンストリームノードのリスト」パラメータが空である場合に、ＳＧＳＮまたはＧＧＳＮによって
‐「ダウンストリームノードのリスト」に登録される最後のノードが、対応するＭＢＭＳ ＵＥコンテキストがないＭＢＭＳベアラサービスから登録抹消する場合に、ＳＧＳＮまたはＧＧＳＮによって、または、
‐ＳＧＳＮにおいて登録するＤＲＮＣ（登録抹消ＲＮＣ：Ｄｅ‐ｒｅｇｉｓｔｅｒｉｎｇ ＲＮＣ）によって、それが関連ＭＢＭＳサービスコンテキストを消去する場合に、
開始される。

登録抹消手続を図９に示す。

Ａ．ＳＧＳＮにおいて登録されるＤＲＮＣが、そのＭＢＭＳベアラサービスに関与するいずれのＵＥももはやホストしない場合、ＤＲＮＣは、その親ＳＧＳＮにＭＢＭＳベアラサービスからの登録抹消を要求する。実施オプションとして、例えばすぐ後にＲＮＣが同一のＭＢＭＳベアラサービスを再度必要とする場合に不必要な信号送信を回避するため、ＤＲＮＣは、これらの条件が満たされてすぐにＭＢＭＳベアラサービスから登録抹消はしないと決定してもよい。また、ＳＧＳＮおよび／またはＧＧＳＮは、不必要な信号送信を回避するためにすぐには登録抹消しないと決定してもよく、すなわち、ＤＲＮＣを登録抹消する前に、ある時間待機してもよい。
ＳＧＳＮは、影響を受けるＭＢＭＳベアラコンテキストの「ダウンストリームノードのリスト」パラメータからＲＮＣの識別子を削除し、ＭＢＭＳ登録抹消応答メッセージをＲＮＣへ送信することによってオペレーションを確認する。ＩｕベアラプレーンがこのＭＢＭＳベアラサービスのためにＤＲＮＣとＳＧＳＮとの間に確立されなかった場合、Ｉｕベアラプレーンは解放される。ＲＮＣがＩＰマルチキャスト分配を使用している場合、それは特定のＭＢＭＳベアラサービスのＩＰバックボーンからの受信を不可能とするであろう。それは、ＲＦＣ３３７６、ＲＦＣ３８１０およびＲＦＣ４６０４に記載の手続を使用するであろう。

Ｂ．ＳＧＳＮにおける特定のＭＢＭＳベアラコンテキストの「ダウンストリームノードのリスト」が空になり、そのＭＢＭＳベアラコンテキストにリンクされるＭＢＭＳ ＵＥコンテキストをＳＧＳＮが有しない場合、ＳＧＳＮは、ＭＢＭＳベアラコンテキストに関連するそのアップストリームＧＧＳＮへＭＢＭＳ登録抹消要求（ＩＰマルチキャストアドレス、ＡＰＮ）メッセージを送信する。
ＧＧＳＮは、影響を受けるＭＢＭＳベアラコンテキストの「ダウンストリームのリスト」パラメータからＳＧＳＮの識別子を削除し、ＳＧＳＮへＭＢＭＳ登録抹消応答メッセージを送信することによってオペレーションを確認する。ベアラプレーンがこのＭＢＭＳベアラサービスのためにＳＧＳＮとＧＧＳＮとの間に確立された場合、ベアラプレーンは解放される。ＳＧＳＮがＩＰマルチキャスト分配を使用している場合、それは特定のＭＢＭＳベアラサービスのＩＰバックボーンからの受信を不可能にするであろう。それは、ＲＦＣ３３７６、ＲＦＣ３８１０およびＲＦＣ４６０４に記載の手続を使用するであろう。

Ｃ．ＧＧＳＮにおける特定のＭＢＭＳベアラコンテキストの「ダウンストリームのリスト」が空になり、そのＭＢＭＳベアラコンテキストにリンクするＭＢＭＳ ＵＥコンテキストをＧＧＳＮが有さない場合、ＧＧＳＮは、ＢＭ‐ＳＣへ登録抹消要求（ＩＰマルチキャストアドレス、ＡＰＮ）メッセージを送信する。プロキシおよび搬送機能、ベアラプレーンがこのＭＢＭＳベアラサービスに対するＧｉを通して確立された場合、ベアラプレーンは解放される。
ＢＭ‐ＳＣは、影響を受けるＭＢＭＳベアラコンテキストの「ダウンストリームノードのリスト」パラメータからＧＧＳＮの識別子を削除し、ＧＧＳＮへ登録抹消応答メッセージを送信することによってオペレーションを確認する。

＜ＢＭ‐ＳＣ開始ＭＢＭＳ登録抹消手続＞
このＭＢＭＳ登録抹消手続は、特定のＭＢＭＳベアラサービスが終了すると、ＢＭ‐ＳＣによって開始される。この手続は、セッション属性とＭＢＭＳデータとの配信のための分配ツリーを破棄する。この手続は、この手続によって、分配ツリーに沿ったノードにおける全ＭＢＭＳベアラコンテキストと関連ＭＢＭＳ ＵＥコンテキストを解放することになる。この手続を図１０に示す。

１００１．ＢＭ‐ＳＣは、対応するＭＢＭＳベアラコンテキストの「ダウンストリームノードのリスト」パラメータに含まれる全ＧＧＳＮへ登録抹消要求メッセージを送信して、セッションが終了し、関連するいずれのＭＢＭＳベアラも解放されることになるということを示す。

ＧＧＳＮはＢＭ‐ＳＣへ登録抹消応答メッセージを返信する。ＢＭ‐ＳＣは全ＭＢＭＳ ＵＥコンテキストと対応のＭＢＭＳベアラコンテキストとを解放する。

１００２．ＧＧＳＮは、対応するＭＢＭＳベアラコンテキストの「ダウンストリームのリスト」パラメータに含まれる全ＳＧＳＮへＭＢＭＳ登録抹消要求メッセージを送信する。ＭＢＭＳベアラコンテキストの状態属性が「アクティブ」である場合には、ＳＧＳＮはＧＧＳＮへＭＢＭＳ登録抹消応答メッセージを返信し、全ベアラ資源を解放する。ＳＧＳＮがＩＰマルチキャスト分配を使用している場合、それは特定のＭＢＭＳベアラサービスのＩＰバックボーンからの受信を不可能にするであろう。それは、ＲＦＣ３３７６、ＲＦＣ３８１０およびＲＦＣ４６０４に記載の手続を使用するであろう。ＧＧＳＮは全ＭＢＭＳ ＵＥコンテキストと、影響を受けるＭＢＭＳベアラコンテキストとを解放する。このＭＢＭＳベアラサービスに対するＧｉを通してベアラプレーンが確立された場合、ベアラプレーンは解放される。

１００３．ＳＧＳＮは、このＳＧＳＮと接続される全ＲＮＣへＭＢＭＳ登録抹消要求メッセージを送信する。ＭＢＭＳサービスコンテキストの状態属性が「アクティブ」である場合、ＲＮＣはＳＧＳＮへＭＢＭＳ登録抹消応答メッセージを返信し、全ベアラ資源を解放する。ＲＮＣがＩＰマルチキャスト分配を使用している場合、それは特定のＭＢＭＳベアラサービスのＩＰバックボーンからの受信を不可能にするであろう。それは、ＲＦＣ３３７６、ＲＦＣ３８１０およびＲＦＣ４６０４に記載の手続を使用するであろう。ＳＧＳＮは、全ＭＢＭＳ ＵＥコンテキストと、影響を受けるＭＢＭＳベアラコンテキストとを解放する。このＭＢＭＳベアラサービスのためにＳＧＳＮとＧＧＳＮとの間にベアラプレーンが確立された場合、ベアラプレーンが解放される。

１００４．ＲＮＣは、影響を受ける無線資源と、全ＭＢＭＳ ＵＥコンテキストと、ＭＢＭＳサービスコンテキストとを解放する。詳細な手続はＴＳ２５．３４６とＴＳ４３．２４６とに指定される。ＲＡＮは、ＭＢＭＳベアラサービスが終了されたということをＵＥに通知し、そのためＵＥは、そのＭＢＭＳ ＵＥコンテキスト局所的に非アクティブ化することができる。詳細な手続はＴＳ２５．３４６とＴＳ４３．２４６とに指定される。

本発明は、２．５および３Ｇネットワーク解決手段（例えばＧＰＲＳおよびＵＭＴＳ）に関連して説明したが、例えばワイヤレス通信の将来の解決手段のように、同様の方式で動作する他のネットワークにも、このような場合においてアーキテクチャが如何にセットアップされるかに依存して、適用可能である。制御プレーンを使用するが、ユーザプレーンバックボーンネットワーク上で実際のペイロードデータを送信するトンネルを設定することによって、この解決手段は制御プレーンとユーザプレーンとの間の分離を利用する。本発明による解決手段は、２Ｇ解決手段にも適用性を発見できるが、ＳＧＳＮはＲＮＣではなくホストとしてふるまうことになり、ＳＧＳＮはペイロード情報をＢＳＣへ送信することになり、さらに各移動局（ＭＳ）へ搬送されていくという違いがある、ということが留意されるべきである。ＲＮＣと同様に、ＢＳＣがホストとしてもふるまうように、ＢＳＣにいくつかの補正が可能である。

「含む／備える（ｃｏｍｐｒｉｓｉｎｇ）」という言葉はリストしたもの以外の他のエレメントまたはステップの存在を排除するものではなく、エレメントに先行する「ａ」または「ａｎ」という言葉は複数のそのようなエレメントの存在を排除するものではない、ということが留意されるべきである。本発明は、ソフトウェアまたはハードウェアのどちらかに少なくとも部分的に実装可能である。いずれの参照記号も特許請求の範囲を限定するものではなく、いくつかの「手段（ｍｅａｎｓ）」、「装置（ｄｅｖｉｃｅｓ）」および「ユニット（ｕｎｉｔｓ）」は同一のハードウェアのアイテムで表すことが可能である、ということもさらに留意されるべきである。

上で言及し説明した実施形態は例として与えたものであり、本発明を限定するべきものではない。以下に記載の特許請求の範囲において請求するような本発明の範囲内の他の解決手段、使用法、目的および機能は当業者にとって明らかであろう。

＜略語＞
ＢＭ‐ＳＣ ブロードキャスト／マルチキャストサービスセンター（Ｂｒｏａｄｃａｓｔ／Ｍｕｌｔｉｃａｓｔ Ｓｅｒｖｉｃｅ Ｃｅｎｔｅｒ）
ＧＧＳＮ ゲートウェイＧＰＲＳサービスノード（Ｇａｔｅｗａｙ ＧＰＲＳ Ｓｅｒｖｉｃｅ Ｎｏｄｅ）
ＧＰＲＳ 汎用パケット無線サービス（Ｇｅｎｅｒａｌ Ｐａｃｋｅｔ Ｒａｄｉｏ Ｓｅｒｖｉｃｅ）
ＧＴＰ ＧＰＲＳトンネリングプロトコル（ＧＰＲＳ Ｔｕｎｎｅｌｉｎｇ Ｐｒｏｔｏｃｏｌ）
ＧＲＸ ＧＰＲＳローミング交換（ＧＰＲＳ Ｒｏａｍｉｎｇ ｅＸｃｈａｎｇｅ）
ＩＥ 情報エレメント（Ｉｎｆｏｒｍａｔｉｏｎ Ｅｌｅｍｅｎｔ）
ＩＧＭＰ インターネットグループ管理プロトコル（Ｉｎｔｅｒｎｅｔ Ｇｒｏｕｐ Ｍａｎａｇｅｍｅｎｔ Ｐｒｏｔｏｃｏｌ）
ＩＰ インターネットプロトコル（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）
ＩＳＲＡＵ インターＳＧＳＮ ＲＡＵ（Ｉｎｔｅｒ ＳＧＳＮ ＲＡＵ）
ＭＢＭＳ マルチメディアブロードキャスト／マルチキャストサービス（Ｍｕｌｔｉｍｅｄｉａ Ｂｒｏａｄｃａｓｔ／Ｍｕｌｔｉｃａｓｔ Ｓｅｒｖｉｃｅ）
ＭＬＤ マルチキャストリスナーディスカバリ（Ｍｕｌｔｉｃａｓｔ Ｌｉｓｔｅｎｅｒ Ｄｉｓｃｏｖｅｒｙ）
ＭＳ 移動局（Ｍｏｂｉｌｅ Ｓｔａｔｉｏｎ）（ＧＰＲＳネットワークにおける携帯電話）
ＯＴＳ １トンネル解決手段（Ｏｎｅ Ｔｕｎｎｅｌ Ｓｏｌｕｔｉｏｎ）
ＰＤＮ パケットデータネットワーク（Ｐａｃｋｅｔ Ｄａｔａ Ｎｅｔｗｏｒｋ）
ＰＤＰ パケットデータプロトコル（Ｐａｃｋｅｔ Ｄａｔａ Ｐｒｏｔｏｃｏｌ）
ＰＬＭＮ 公用地移動ネットワーク（Ｐｕｂｌｉｃ Ｌａｎｄ Ｍｏｂｉｌｅ Ｎｅｔｗｏｒｋ）
ＲＡＵ ルーティングエリア更新（Ｒｏｕｔｉｎｇ Ａｒｅａ Ｕｐｄａｔｅ）
ＲＮＣ 無線ネットワークコントローラ（Ｒａｄｉｏ Ｎｅｔｗｏｒｋ Ｃｏｎｔｒｏｌｌｅｒ）
ＳＧＳＮ サービングＧＰＲＳサービスノード（Ｓｅｒｖｉｎｇ ＧＰＲＳ Ｓｅｒｖｉｃｅ Ｎｏｄｅ）
ＴＥＩＤ トンネルエンドポイント識別子（Ｔｕｎｎｅｌ Ｅｎｄｐｏｉｎｔ Ｉｄｅｎｔｉｆｉｅｒ）
ＴＥＩＤ‐Ｃ 制御プレーントンネルを識別するＴＥＩＤ（ＴＥＩＤ ｉｄｅｎｔｉｆｙｉｎｇ ａ Ｃｏｎｔｒｏｌ ｐｌａｎｅ ｔｕｎｎｅｌ）
ＴＥＩＤ‐Ｕ ユーザプレーントンネルを識別するＴＥＩＤ（ＴＥＩＤ ｉｄｅｎｔｉｆｙｉｎｇ ａ Ｕｓｅｒ ｐｌａｎｅ ｔｕｎｎｅｌ）
ＵＥ ユーザイクイップメント（Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔ）（＝ＭＳ）
ＵＭＴＳ ユニバーサル移動電気通信システム（Ｕｎｉｖｅｒｓａｌ Ｍｏｂｉｌｅ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ｓｙｓｔｅｍ）
ＵＴＲＡＮ／ＧＥＲＡＮ ユニバーサル地上波無線アクセスネットワーク／ＧＳＭ‐ＥＤＧＥ無線アクセスネットワーク（Ｕｎｉｖｅｒｓａｌ Ｔｅｒｒｅｓｔｒｉａｌ Ｒａｄｉｏ Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ／ＧＳＭ‐ＥＤＧＥ Ｒａｄｉｏ Ａｃｃｅｓｓ）

Claims (14)

1. 電気通信ネットワークにおいてマルチメディアブロードキャストマルチキャストサービス、すなわちＭＢＭＳ、の分配を容易にする電気通信ゲートウェイ装置であって、
   ブロードキャスト／マルチキャストサービスセンターからのＭＢＭＳセッション開始要求メッセージを受信する命令セットと、
   制御ネットワーク上で制御トラフィックを送信する命令セットと、
   サービングノードへの制御トラフィックとしてＭＢＭＳセッション開始要求メッセージを送信し、前記ＭＢＭＳセッション開始要求メッセージに共通トンネルエンドポイント識別子、すなわちｃＴＥＩＤ、を含める命令セットと、
   ＩＰマルチキャストの使用の受け入れを示す前記サービングノードからの情報を受信する命令セットと、
   前記ｃＴＥＩＤを使用してマルチキャストグループに参加したホストへＩＰマルチキャストバックボーン上でメディアコンテンツを送信する命令セットと
   で構成される、電気通信ゲートウェイ装置。
2. 前記ｃＴＥＩＤの一意性を確証するために、前記ｃＴＥＩＤを他のインフラストラクチャ装置と同期する命令セットをさらに備える、請求項１に記載の装置。
3. 別のインフラストラクチャ装置から一意のｃＴＥＩＤを受信する命令セットをさらに備える、請求項１に記載の装置。
4. フォールバックの目的でサービングノードと制御ノードとのうちの少なくとも１つへ少なくとも１つのネットワーク通信トンネルを作成する命令セットをさらに備える、請求項１に記載の装置。
5. 電気通信ネットワークにおいてマルチメディアブロードキャストマルチキャストサービス、すなわちＭＢＭＳ、の分配を容易にする電気通信サービング装置であって、
   共通トンネルエンドポイント識別子、すなわちｃＴＥＩＤ、を含む電気通信ゲートウェイ装置からのＭＢＭＳセッション開始要求メッセージを受信する命令セットと、
   ＭＢＭＳセッション開始要求メッセージを制御ノードへ送信し、前記ＭＢＭＳセッション開始要求メッセージに前記共通トンネルエンドポイント識別子、すなわちｃＴＥＩＤ、を含める命令セットと、
   インターネットプロトコル（ＩＰ）マルチキャスト分配の使用の受け入れを示す前記制御ノードからの情報を受信する命令セットと
   で構成される、電気通信サービング装置。
6. インターネットプロトコルマルチキャストバックボーンへインターネットグループ管理プロトコル、すなわちＩＧＭＰ、参加メッセージまたはメンバーシップ報告メッセージ（ＩＧＭＰｖ２およびＩＧＭＰｖ３）を送信する命令セットをさらに備える、請求項５に記載の装置。
7. 電気通信ネットワークにおいてマルチメディアブロードキャストマルチキャストサービス、すなわちＭＢＭＳ、の分配を容易にする電気通信制御装置であって、
   共通トンネルエンドポイント識別子、すなわちｃＴＥＩＤ、を含むＭＢＭＳセッション開始要求メッセージを電気通信サービング装置から受信する命令セットと、
   前記電気通信制御装置がインターネットプロトコルマルチキャスト分配を受け入れるという表示を有するＭＢＭＳセッション開始応答メッセージを前記電気通信サービング装置へ送信する命令セットと、
   インターネットプロトコルマルチキャストバックボーンへインターネットグループ管理プロトコル、すなわちＩＧＭＰ、参加メッセージまたはメンバーシップ報告メッセージ（ＩＧＭＰｖ２およびＩＧＭＰｖ３）を送信する命令セットと
   で構成される、電気通信制御装置。
8. マルチメディアブロードキャストマルチキャストサービス、すなわちＭＢＭＳ、の分配を容易にする電気通信インフラストラクチャネットワーク（２０）であって、
   ブロードキャスト／マルチキャストサービスノード（２）、すなわちＢＭ‐ＳＣと、
   ゲートウェイノード（２３）と、
   少なくとも１つのサービングノード（２４）と、
   少なくとも１つの制御ノード（２５、２６）と
   を備え、
   前記ＢＭ‐ＳＣは前記ゲートウェイノードに接続され、前記ゲートウェイノードは２つのインターフェース、制御インターフェースおよびバックボーンインターフェースを介して前記サービングノードに接続され、前記制御ノードは前記サービングノードおよび／または前記ゲートウェイノードに接続され、前記ゲートウェイノードは、
   ブロードキャスト／マルチキャストサービスセンターからＭＢＭＳセッション開始要求メッセージを受信する命令セットと、
   前記制御インターフェース上で制御トラフィックを送信する命令セットと、
   ＭＢＭＳセッション開始要求メッセージを前記サービングノードへ制御トラフィックとして送信し、前記ＭＢＭＳセッション開始要求メッセージに共通トンネルエンドポイント識別子、すなわちｃＴＥＩＤ、を含める命令セットと、
   ＩＰマルチキャストの使用の受け入れを示す前記サービングノードからの情報を受信する命令セットと、
   前記ｃＴＥＩＤを使用してマルチキャストグループに参加したホストへＩＰマルチキャストバックボーン上でメディアコンテンツを送信する命令セットと
   で構成される、電気通信インフラストラクチャネットワーク（２０）。
9. 電気通信ネットワークにおいてマルチメディアブロードキャストマルチキャストサービス、すなわちＭＢＭＳ、の分配を容易にする方法であって、
   ブロードキャスト／マルチキャストサービスセンター（２）、すなわちＢＭ‐ＳＣ、からのＭＢＭＳセッション開始要求メッセージをゲートウェイノード（２３）において受信するステップと、
   制御ネットワーク上で制御トラフィックを送信するステップと、
   ＭＢＭＳセッション開始要求メッセージを前記ゲートウェイノードからサービングノード（２４）へ制御トラフィックとして送信し、前記ＭＢＭＳセッション開始要求メッセージに共通トンネルエンドポイント識別子、すなわち共通ＴＥＩＤ、を含めるステップと、
   ＩＰマルチキャストの使用の受け入れを示す前記サービングノードからの情報を受信するステップと、
   前記共通ＴＥＩＤを使用してマルチキャストグループに参加したホスト（２５、２６、３１）へＩＰマルチキャストバックボーン上でメディアコンテンツを送信するステップと
   を含む方法。
10. 前記共通ＴＥＩＤはＭＢＭＳセッションごとに一意である、請求項９に記載の方法。
11. 前記ホストはサービングノードと制御ノードとのうちの少なくとも１つである、請求項９に記載の方法。
12. 前記共通ＴＥＩＤは、ＴＥＩＤ構造の少なくとも１つのビットをアクティブ状態を示すように設定することによって識別される、請求項９に記載の方法。
13. 前記ゲートウェイノードと前記サービングノードとの間、および前記サービングノードと制御ノードとの間にＧＴＰトンネルをセットアップすることを含むフォールバック手続を使用するステップをさらに含む、請求項９に記載の方法。
14. 前記ＩＰマルチキャストバックボーンに参加する関心を示すメッセージを送信することにより、前記ＩＰマルチキャストバックボーンへ制御ノードが参加するステップをさらに含む、請求項９に記載の方法。

Images