(57)【要約】【課題】本発明は、通信方法を向上させるためのものである。【解決手段】本発明は、ネットワークでＵＲＡ＿ＰＣＨ状態のユーザー端末のためにマルチキャストサービスの受信を支援するか否かを判断するステップと、前記ネットワークがマルチキャストサービスの受信を支援すると、ユーザー端末が存在する登録領域内にマルチキャストサービスが有効であるか否かを示すサービスの有効性情報を無線網制御器同士で送信するステップと、登録領域内の全てのセルに対して前記マルチキャストサービスのための一貫したサービスの有効性情報を提供するステップとを含むことを特徴とする。【選択図】図３
2010279048.tif 000002
【特許請求の範囲】
【請求項１】
移動通信ネットワークにおけるマルチキャストサービス関連情報を送信する方法において、
ネットワークでＵＲＡ＿ＰＣＨ状態のユーザー端末のためにマルチキャストサービスの受信を支援するか否かを判断するステップと、
前記ネットワークがマルチキャストサービスの受信を支援すると、前記ユーザー端末が存在する登録領域内にマルチキャストサービスが有効であるか否かを示すサービスの有効性情報を無線網制御器同士で送信するステップと、
前記登録領域内の全てのセルに対して前記マルチキャストサービスのための一貫したサービスの有効性情報を提供するステップと、を含むことを特徴とするマルチキャストサービス関連情報の送信方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信システムにおけるブロードキャスト若しくはマルチキャストサービスに係り、さらに詳しくは、ＵＭＴＳ（Universal Mobile Telecommunications Service）無線アクセスネットワークなどの無線アクセスネットワーク（Radio Access Network：ＲＡＮ）においてマルチキャストブロードキャストサービスを実現することに関する。ＵＭＴＳは、ＷＣＤＭＡ（Wideband Code Division Multiple Access）技術を用いる第３世代の無線ネットワークに相当する。
【背景技術】
【０００２】
ＵＭＴＳの場合、図１に示すように、セルラー通信システムは、移動ユーザー端末（User Equipment：ＵＥ）１と、ＵＭＴＳ地上無線アクセスネットワーク（ＵＭＴＳ Terrestrial Radio Access Network：ＵＴＲＡＮ）３と、コアネットワーク（Core Network：ＣＮ）５と、を備える。第３世代のセルラー通信システムの構造の詳細は、３ＧＰＰ標準「ＵＴＲＡＮの全体の説明」３ＧＰＰ ＴＳ２５．４０１及び関連標準に記述されている。端末１とＵＴＲＡＮ３との通信はＵｕインタフェースを介して行われ、ＵＴＲＡＮ３とコアネットワーク５との通信は、Ｉｕインタフェースを介して行われる。
【０００３】
無線アクセスネットワークは、基地局と、無線網制御器（Radio Network Controllers：ＲＮＣ）あるいは基地局制御器（Base Station Controllers：ＢＳＣ）と、を備える。基地局は、セルと呼ばれる地理的な特定の領域をカバーし、無線インタフェース上の実際の通信を処理する。無線網制御器は、接続されている基地局を制御し、さらに、例えば、無線資源の割り当てや局部的な移動性の制御などの機能も行う。ＲＮＣは、１以上のコアネットワークにＩｕインタフェースを介して接続され、複数の基地局（ＵＴＲＡＮの場合、ノードＢと称する。）にＩｕｂインタフェースを介して接続され、さらに、場合によって、１以上の他のＲＮＣにＩｕｒインタフェースを介して接続される。コアネットワークは、サービングＧＰＲＳ（General Packet Radio Service）支援ノード（Serving ＧＰＲＳ support Node：ＳＧＳＮ）と、ブロードキャスト／マルチキャスト−サービスセンター（Broadcast/multicast-service centre：ＢＮ−ＳＣ）と、を備える。ＢＭ−ＳＣは、ＭＢＭＳサービスに関するデータの分配を司る。
【０００４】
ＵＭＴＳネットワークなどの第３世代（３Ｇ）の通信ネットワークにおいては、マルチメディアブロードキャストマルチキャストサービス（Multimedia Broadcast Multicast Services：ＭＢＭＳ）を提供する。ＭＢＭＳは、単一のソース固体から多数の受信者に単方向のベアラーサービスを用いてオーディオ、イメージ若しくはビデオデータなどのマルチメディアデータを伝送する点対多のサービスである。ＭＢＭＳベアラーサービスは、ブロードキャストモードとマルチキャストモードの両方を提供する。ブロードキャストモードの場合、データは、全てのユーザーにブロードキャストされる。これとは逆に、マルチキャストサービスを受信するために、ユーザーは、サービスプロバイダーを持つ特定のＭＢＭＳサービス若しくはＭＢＭＳサービスのグループに加入する必要がある。これにより、運営者は、ユーザーにＭＢＭＳサービスが有効である旨を知らせるために、上記サービスを公知するか、あるいは、サービスディスカバリーメカニズムを用いることができる。ユーザーが特定のＭＢＭＳサービスを受信したい場合、ユーザーは、上記サービスに参加する。すなわち、ユーザーは、ＭＢＭＳマルチキャストサービスを活性化する。この場合、ユーザーは、特定のマルチキャストグループの一員となり、ネットワークに上記特定のＭＢＭＳサービスに関するＭＢＭＳデータの受信を希望するという旨を知らせる。
【０００５】
特定のマルチキャストＭＢＭＳベアラーサービスが有効となる領域は、ＭＢＭＳサービス領域若しくはＭＢＭＳマルチキャスト（ＭＣ）サービス領域と称する。ＭＢＭＳベアラーサービス別に、すなわち、ＭＢＭＳサービス領域別にＭＢＭＳサービスが特定される。このようなＭＢＭＳサービス領域は、複数のセルを含む。ＭＢＭＳ ＭＣサービス領域は、ＵＴＲＡＮ登録領域（ＵＲＡ）、ルーティング領域（Routing Areas：ＲＡｓ）あるいは位置領域（Location Areas：ＬＡｓ）など、ネットワークの他の領域といかなる関連性も持たない場合がある。このため、ＭＢＭＳ ＭＣサービス領域は、上記ＵＲＡ、ＲＡあるいはＬＡの全てのセルを含まず、ＵＲＡ、ＲＡあるいはＬＡの一部のセルを含むことができる。
【０００６】
ＵＴＲＡＮにおけるＭＢＭＳの実現に関するさらなる情報は、相当するステージ−２文書「無線アクセスネットワーク（ＲＡＮ）におけるマルチメディアブロードキャストマルチキャストサービス（ＭＢＭＳ）の紹介」、ＴＳ２５．３４６．ｖ２．６．０に記述されている。
【０００７】
多数の受信者に同じデータを伝送するためには、ネットワーク資源を共有する必要がある。このため、ＭＢＭＳ構造は、無線ネットワーク及びコアネットワーク資源を効率よく使用可能に設計される。
【０００８】
ＭＢＭＳセッションを初期化するために、ＣＮは、セッション開始指令をＲＮＣに送信する。上記セッション開始指令は、コアネットワークが特定のＭＢＭＳサービスに関するデータを伝送する準備ができていることを示す。上記セッション開始指令は、ＭＢＭＳデータの伝送のためのベアラー資源の設定を引き起こす。上記セッション開始により、ユーザーは、上記サービスを独立して活性化させる。これは、ユーザーがセッション開始前、若しくはセッション開始後に特定のサービスを活性化させることが可能であることを意味する。
【０００９】
セッション開始指令を受信した後、ＲＮＣは、ＭＢＭＳマルチキャストデータの伝送が迫っている旨、あるいは、既にＭＢＭＳマルチキャストデータの伝送が進行中である旨を端末に知らせるために、端末にＭＢＭＳの通知を伝送する。ＲＮＣは無線資源の使用を管理し、ＭＢＭＳデータを無線インタフェース上において点対多の伝送モードで伝送するか、あるいは、点対点の伝送モードで伝送するかを決める。セル内に存在する端末の数が適正数であれば、ほとんどの場合、点対多の伝送モードが高効的である。これに対し、セル内に存在する端末の数が少数であれば、ほとんどの場合、点対点の伝送モードが効率的である。伝送モードを決めるために、ＲＮＣは、カウント動作を行うことができる。次いで、特定のＭＢＭＳサービスに関するマルチメディアデータは、データ伝送中にＣＮからＲＮＣを介して端末に伝送される。
【００１０】
ＢＭ−ＳＣがそれ以上伝送するデータがないと決めると、ＣＮは、セッション終了指令をＲＮＣに伝送してベアラー資源を解放する。
【００１１】
ユーザーが特定のＭＢＭＳサービスをそれ以上受信したくない場合、ユーザーは、上記サービスを非活性化させる。これにより、ユーザーが特定のＭＢＭＳベアラーサービスのマルチキャストモードデータをそれ以上受信したくない場合、ユーザーは、マルチキャストグループから脱会する。
【００１２】
加入、参加及び脱会の段階は、ユーザーごとに個別に行われることに留意しなければならない。通知、データ伝送などの他の段階は、全てのユーザーが受信したい特定のサービスに対して行われる。
【００１３】
３ＧＰＰ ＲＡＮ２の４１次会議（２００４．２．１６−２１）において、ＭＢＭＳがＵｕインタフェースにおいてどのように処理されるかに関する状況がなお一層明確に論議される。ＲＡＮ２におけるＭＢＭＳの実現は、３ＧＰＰ標準ＴＳ２５．４０１に開示されているのが現状である。
【００１４】
ＭＢＭＳの受信と関連して、ＵＲＡ＿ＰＣＨ／ＣＥＬＬ＿ＰＣＨの状態にある端末をどのように処理するかに関する種々の寄稿案がＲＡＮ２に下記の例示文献に既に提出されている。
文献Ｒ２−０４００６８:「MBBMS Common Paging versus MBMS Dedicated Paging Samsung」, http://www.3gpp.org/ftp/tsg_ran/WG2_RL2/TSGR2_40/Docs; 
文献Ｒ２−０４００８７: 「Requirements for responding to MBMS Notification for UEs in URA_PCH Vodafone Group」, 
http://www.3gpp.org/ftp/tsg_ran/WG2_RL2/TSGR2_40/Docs;
文献Ｒ２−０４０５０５: 「Handling of Ues in CELL_PCH and URA_PCH Ericsson」, http://www.3gpp.org/ftp/tsg_ran/WG2_RL2/TSGR2_41/Docs
文献Ｒ２−０４０５３２: 「Tracking and MBMS bearer establishment for UEs in URA_PCH Vodafone Group」, 
http://www.3gpp.org/ftp/tsg_ran/WG2_RL2/TSGR2_41/Docs.
【発明の開示】
【発明が解決しようとする課題】
【００１５】
本発明は、上記した方法及びシステムを向上させるためのものである。
ＲＲＣ接続を持っている端末はＲＲＣ接続端末と呼ぶのに対し、ＲＲＣ接続を持っていない端末は遊休モードの端末と呼ぶ。ＲＲＣ接続モードの端末は、端末が、現在、当該チャンネルを受信可能であるかどうかによって、ＣＥＬＬ＿ＰＣＨ（Cell-Paging Channel）、ＵＲＡ＿ＰＣＨ、ＣＥＬＬ＿ＦＡＣＨ（Cell-Forward Access Channel）及びＣＥＬＬ＿ＤＣＨ（Cell-Dedicated Channel）の状態に分類できる。
【００１６】
ＣＥＬＬ＿ＤＣＨの状態にある端末の場合、ＤＣＨに関する専用論理チャンネルと伝送チャンネルが設定されており、ＤＣＨを介してデータを常に受信する。ＣＥＬＬ＿ＦＡＣＨの状態にある端末の場合、ＦＡＣＨに関する専用論理チャンネルと伝送チャンネルが設定されており、ＦＡＣＨデータを常に受信可能であるが、ＤＣＨ及びＤＳＣＨ（Downlink Shared Channel）は受信することができない。ＣＥＬＬ＿ＰＣＨ若しくはＵＲＡ＿ＰＣＨの状態にある端末の場合、専用論理チャンネルを設定していないが、ページング・メッセージをＰＣＨを介して受信することができるか、あるいは、セル・ブロードキャスト・サービス（Cell Broadcast Service：ＣＢＳ）メッセージをＦＡＣＨを介して受信することができる。
【課題を解決するための手段】
【００１７】
本発明の一実施の形態は、移動通信ネットワークにおけるマルチキャストサービス関連情報を送信する方法において、１以上の端末が参加した上記マルチキャストサービスに関する情報を、上記端末が上記１以上のマルチキャストサービスに参加している間に無線網制御器に保存することを特徴とする。
【００１８】
他の見地によれば、ＭＢＭＳと関連してＵＲＡ＿ＰＣＨの状態にある端末に対する処理を開示する。
【００１９】
この出願においては、ＵＲＡ＿ＰＣＨの状態において、点対多（ＰＴＭ）のＭＢＭＳ無線ベアラー(Radio Bearer:ＲＢ）の受信を支援可能にする方案を開示する。
【００２０】
ところが、ＵＴＲＡＮは、ＵＲＡ＿ＰＣＨの状態においては、ＵＲＡに位置している端末の移動が不知である。このため、このような方案は、ネットワークにおいて、ＵＲＡの全てのセル内に一貫したサービスの有効性情報を提供する必要があることを意味する。この観点から、この方案は、上述の実施の形態とは異なる。
【００２１】
参照文献Ｒ２−０４００８７及びＲ２−０４０５３２においては、２番目の実施の形態が論議されている。しかしながら、これらの文献は、両方共に、全体のＵＲＡ内にサービスの有効性情報を正確に指示する必要があるといった課題を開示していない。
【００２２】
参照文献Ｒ２−０４０５０５は、ＣＥＬＬ＿ＰＣＨ及びＵＲＡ＿ＰＣＨを同様に処理することを提案している。しかしながら、同文献においては、全体のＵＲＡ内にサービスの有効性情報を提供する必要があるといった課題は論議されていない。
【００２３】
本発明の他の実施の形態は、移動通信ネットワークにおけるマルチキャストサービス関連情報を送信する方法において、上記マルチキャストサービスのマルチキャストサービス領域の一部である登録領域内にセルが存在するかどうかに関する情報を無線網制御器同士で送信することを特徴とする。
【００２４】
本発明のさらに他の実施の形態は、移動通信ネットワークにおけるマルチキャストサービスを提供する方法ににおいて、１以上のマルチキャストサービスを受信しようとする、登録領域内において特定の状態にある端末に関する情報を第１の無線網制御器に保存することを特徴とする。
【００２５】
この実施の形態においては、３ＧＰＰ標準ＴＳ ２５．４２３ ｖ６．４．０（セクション８．２．２．２参照）に示すＵＲＡ＿ＰＣＨの状態において、点対多（ＰＴＭ）のＭＢＭＳ ＲＢの受信を支援可能にする方案を開示している。しかしながら、上記の標準は、ＭＢＭＳサービスをＰＴＰモードで提供するか、若しくはＰＴＭモードで提供するかを区別するために、カウントの手順をどのように行うかについては全く開示されていない。
【００２６】
以上によれば、ＲＲＣ遊休の状態にある端末のために用いられるカウント若しくは再カウントの手順は、カウントの要求に応答して、ＲＲＣ遊休の状態から外れる端末の特定の割合を示す確率因子を用いて行われる。応答端末の数が決められると、ＭＢＭＳサービスをＰＴＰモードで提供するか、若しくはＰＴＭモードで提供するかが決められる。
【００２７】
参照文献Ｒ２−０４０５３２においては、ＲＲＣ遊休の状態にある端末のために用いられる確率因子と同じ確率因子をＵＲＡ＿ＰＣＨの状態にある端末のために用いることを開示している。
【００２８】
ＲＲＣ遊休の状態にある端末をカウントする必要がある場合、カウントの要求に応答させるためには、端末をＲＲＣ遊休の状態からＲＲＣ接続の状態に遷移させることが必要である。これに対し、ＵＲＡ＿ＰＣＨの状態にある端末をカウントする必要がある場合、セルの更新手順を行わなければならない。
【００２９】
しかしながら、通常、セルの更新手順を用いて端末をＵＲＡ＿ＰＣＨの状態から他のＲＲＣ接続の状態に遷移させることは、ＲＲＣ遊休の状態にある端末をＲＲＣ接続の設定手順によりＲＲＣ接続の状態に遷移させることに比べて、簡単で且つ迅速に行われることが分かる。これより、Ｒ２−０４０５３２に示す方案は、極めて非効率的な解決方案であることが分かる。
【００３０】
本発明のさらに他の実施の形態は、移動通信ネットワークにおけるマルチキャストサービスを提供する方法において、互いに異なる第１及び第２の確率因子を用いて、特定のマルチキャストサービスを受信しようとする、ＲＲＣ遊休状態及び／またはＵＲＡ＿ＰＣＨ状態にある端末をカウントすることを特徴とする。
【００３１】
本発明のさらに他の実施の形態は、移動通信ネットワークにおけるマルチキャストサービスを提供する方法において、確率因子及び付加的なパラメータを用いて特定のマルチキャストサービスを受信しようとする端末をカウントすることを特徴とする。
【発明の効果】
【００３２】
方案１に比較して、方案２の利点は、Ｕｕインタフェースを通じての付加的なシグナリングを低減できるという点にある。これは、方案１は、２つの確率因子をシグナリングしなければならないためである。これに対し、方案２は、単に付加的な１ビットのフラグ若しくはその類似物を端末に対してシグナリングする。これによっても、カウント手順は、従来の技術による方案に比べて大幅に改善される。
【００３３】
このため、全てのＵＲＡ−ＰＣＨの状態にある端末がカウントされた場合、ＲＲＣ遊休の状態にある端末がＲＲＣ接続の状態に遷移することが求められるとしたとき、方案２は、方案１において提供する機能のほとんどを提供する。方案２は、シグナリングの観点から、動作時の効率性及び融通性が高い。
方案１の利点は、カウント手順において、一層高い融通性を与えるところにある。
【図面の簡単な説明】
【００３４】
【図１】本発明が適用可能な移動通信ネットワークの概略構造図である。
【図２】本発明が適用可能な移動通信ネットワークの概略構造図である。
【図３】ＭＢＭＳセッションのメッセージングの経時的なフローを示す図である。
【図４】本発明の一実施の形態によるシグナリングの流れを示す図である。
【図５】５Ａ及び５Ｂは、本発明の２つの実施の形態による確率因子シグナリングを示す図である。
【発明を実施するための形態】
【００３５】
図２は、無線アクセスネットワークの構造図である。ＲＡＮ６は、ＵＴＲＡＮにおいてノードＢと呼ばれる基地局２と、基地局制御器（ＢＳＣ）と呼ばれる無線網制御器（ＲＮＣ）４と、を備える。基地局２は、セルという地理的な特定の領域をカバーし、無線インタフェース上の実際の通信を司る。ＲＮＣ４は、接続されている基地局２を制御し、さらに、例えば、無線資源の割り当てや局部的な移動性の制御などの機能も行う。ＲＮＣ４は、１以上のコアネットワーク８にＩｕインタフェース１２を介して接続され、複数の基地局２にＩｕｂインタフェース１０を介して接続され、且つ、場合によって、１以上の他のＲＮＣ４にＩｕｒインタフェース１４を介して接続される。
【００３６】
ＵＭＴＳネットワークにおいては、端末とＵＴＲＡＮとの間の無線インタフェース上において無線資源制御（Radio Resource Control：ＲＲＣ）プロトコルを用いる。かかるプロトコルの終端は、１以上の情報要素を含むメッセージを伝送してプロトコルパラメータを抽出することにより互いに連動する。
【００３７】
ＭＢＭＳセッションを設定するために、ＲＮＣは、ＣＮから個別の要請を受信する。かかるＭＢＭＳセッションの開始の要請は、ＭＢＭＳサービス識別子を含み、ＭＢＭＳベアラーサービスの種別とＭＢＭＳサービス地域情報あるいはサービス品質パラメータなどのＭＢＭＳセッションの属性を明示する。ＲＮＣは、ＭＢＭＳセッションの開始の要請を受け付けた後、上記特定のＭＢＭＳサービスを受信しようとする端末にこれを通知して、上記特定のＭＢＭＳサービスを活性化させる。
【００３８】
ＭＢＭＳセッションの開始の要請は、ＭＢＭＳ無線アクセスベアラー（Radio Access Bearer：ＲＡＢ）の設定に必要となるあらゆる情報を含む。セッション開始メッセージを受信すると、ＲＮＣは、Ｉｕインタフェースを介してＭＢＭＳデータベアラーの設定を行い、次いで、ＭＢＭＳセッション開始応答メッセージ上に上記設定の結果を載せて当該ＣＮに通知する。
【００３９】
特定のＭＢＭＳサービスの場合、データは、無線アクセスネットワークと端末との間のＭＢＭＳ ＲＡＢを介して受け渡される。
【００４０】
ＲＮＣと端末との接続を設定するに当たり、ＰＴＰ ＭＢＭＳの伝送の場合には、Ｉｕｂインタフェースを通じての順方向のアクセスチャンネル（ＦＡＣＨ）の既存の伝送チャンネルメカニズムが用いられる。ＰＴＭ接続は、セル内においてカウントされた複数のＭＢＭＳユーザーが運営者により定義された特定の臨界値を超える場合に設定される。これに対し、ＰＴＰ接続は、他の専用サービスのために定義されたＤＴＣＨ（Dedicated Transport Channel）を介して設定される。
【００４１】
同様に、ＣＮがＲＮＣにＭＢＭＳセッションの終了指令を伝送すると、ＲＮＣは、ＭＢＭＳサービスを受信したい活性化された端末に上記ＭＢＭＳサービスの終了を通知する。ＲＮＣは、上記ＭＢＭＳセッションの終了指令を受信すると、関連付けられたＭＢＭＳ ＲＡＢ資源を解放する。
【００４２】
図３には、ＭＢＭＳセッション中に起こる一連の主なイベントが示してある。より具体的には、３ＧＰＰ標準ＴＳ２５．３４６に記述されている。上記セッションは、ＳＥＳＳＩＯＮ ＳＴＡＲＴメッセージ１０１がＩｕインタフェースを介してＵＴＲＡＮに受信されることにより開始され、ＳＥＳＳＩＯＮ ＳＴＯＰメッセージ１１７がＩｕインタフェースを介して受信されることにより終了する。
【００４３】
ＳＥＳＳＩＯＮ ＳＴＡＲＴメッセージ１０１後に、ＵＴＲＡＮは、ＲＲＣ＿Ｉｄｌｅ、ＣＥＬＬ＿ＰＣＨ、ＵＲＡ＿ＰＣＨ及びＣＥＬＬ＿ＦＡＣＨの状態にある端末をウェークアップするために、ＭＢＭＳ通知指示子（notification indicators：ＮＩ´ｓ）１０３を伝送する。ＭＢＭＳ通知指示子１０３は、ＭＢＭＳ通知指示子チャンネル（ＭＢＭＳ notification Indicator channel：ＭＩＣＨ）を介して伝送される。端末は、正常なページングの場合、すなわち、典型的な（Ｒ９９）ページングに用いられる正常な端末不連続受信（ＵＥ Ｄiscontinuous Receive：ＵＥＤＲＸ）サイクルにおけるページングが発生した場合にウェークアップされてＭＢＭＳ ＮＩ１０３を探索する。結果的に、ネットワークは、１以上の端末ＤＲＸサイクル中にＭＢＭＳ通知指示子１０３を連続して繰り返し送信する。
【００４４】
端末が受信したいＭＢＭＳサービスに対してＭＢＭＳ ＮＩ１０３が設定されることを感知すると、端末は、ＭＢＭＳ点対多の制御チャンネル（ＭＢＭＳ point-to-multipoint Control Channel：ＭＣＣＨ）を受信する。たとえ、３ＧＰＰ標準２５．３４６に明示されてはいないが、ＭＣＣＨを通じての伝送がスケジュールされる必要があるという点では同意している。このため、特定の周期中にＭＢＭＳ ＮＩ１０３を受信した全ての端末は、特定の時点においてＭＣＣＨをいずれも受信するが、これは、ＭＣＣＨ通知と称する。上記特定の周期は、一般に、最大端末ＤＲＸサイクルとなる。ＭＣＣＨ通知の発生の構成は、ＢＣＣＨあるいはＭＣＣＨ上においてブロードキャストされることを想定する。
【００４５】
ＭＣＣＨの通知が発生したとき、各ＤＲＸサイクルにおいて伝送されるメッセージは、ＭＢＭＳ ＮＯＴＩＦＩＣＡＴＩＯＮメッセージ１０５ａ／ｂ／ｃ／ｄである。通常、上記メッセージ１０５は、上記開始されるセッションを受信したい端末の所定の割合（以下、「カウント確率」と称する。）がＲＲＣ接続を設定することにより応答することを指示することにより、セッションの開始時に先ずカウントの手順をトリガーする。ここで留意すべき点は、ＭＢＭＳ通知メッセージは、３ＧＰＰ標準２５．３４６にまだ登載されていないということである。
【００４６】
ＭＢＭＳ通知メッセージ１０５を受信した後、端末は、カウントの手順を許容させるために、コアネットワークにＲＲＣ接続の設定への要請１１３を伝送する。上記要請１１３は、端末が受信したいＭＢＭＳサービスを示すサービス識別子（ＩＤ）を含む。これに対する応答として、ＣＮは、端末が受信したいＭＢＭＳサービスを識別し、Ｉｕインタフェースを介してＭＢＭＳリンキング要請メッセージ１１５を伝送する。
【００４７】
「受信したい」ＭＢＭＳ ＮＩ１０３を受信するや否や、端末は、ＭＣＣＨ通知の発生時にＭＣＣＨを受信する。この点で、「受信したい」ＭＢＭＳ ＮＩとは、当該ＮＩが端末の参加しているＭＢＭＳサービスと関連付けられていることを意味する。第１のＭＢＭＳ通知メッセージ１０５ａが伝送された後、１以上の後続するＭＢＭＳ通知メッセージ１０５ｂ／ｃ／ｄは、互いに異なるカウント確率を含むことができる。この場合、ＵＴＲＡＮは、ＭＢＭＳサービスを点対点（ＰＴＰ）で提供するか、あるいは点対多（ＰＴＭ）で提供するかを決める。後続するカウントサイクルにおいて一層高いカウント確率を用いることにより、ＵＴＲＡＮは、セル内においてどれだけの端末が特定のＭＢＭＳサービスを受信しようとするかを次第に捉えることができ、これにより、上記ＭＢＭＳサービスをＰＴＰで提供するか、あるいは、ＰＴＭで提供するかを決めることが可能になる。
【００４８】
ＵＴＲＡＮによりＰＴＰ／ＰＴＭの決定が完了すると、カウントの手順は終了する。ＰＴＰが選択された場合、ＭＢＭＳサービスを受信しようとする端末は、ＲＡＤＩＯ ＢＥＡＲＥＲ ＳＥＴＵＰメッセージを受信する。図３は、サービスがＰＴＭで提供される場合を示している。この場合、ＵＴＲＡＮは、ＭＢＭＳ点対多のトラフィックチャンネル（ＭＢＭＳ point-to-multipoint Traffic Channel：ＭＴＣＨ）を構成し、ＭＢＭＳ ＳＥＲＶＩＣＥ ＩＮＦＯＲＭＡＴＩＯＮメッセージ１０７ａ／ｂ／ｃとＭＢＭＳ ＲＡＤＩＯ ＢＥＡＲＥＲ ＩＮＦＯＲＭＡＴＩＯＮメッセージ１０９ａ／ｂ／ｃを伝送することにより、ＭＣＣＨを更新する。これらの２つのメッセージ１０７、１０９は、ＭＢＭＳサービスに対するサービス識別子と無線ベアラー情報を含む。
【００４９】
端末は、上記ＭＢＭＳ ＳＥＲＶＩＣＥ ＩＮＦＯＲＭＡＴＩＯＮメッセージ１０７ａ／ｂ／ｃ及びＭＢＭＳ ＲＡＤＩＯ ＢＥＡＲＥＲ ＩＮＦＯＲＭＡＴＩＯＮメッセージ１０９ａを受信した後、該当するＭＴＣＨ上においてＭＢＭＳデータ伝送１１１を読み取ることができる。
【００５０】
ＭＢＭＳセッションの伝送が終了して、ＳＥＳＳＩＯＮ ＳＴＯＰメッセージ１１７がＩｕインタフェースを介して受信されると、端末は、ＰＴＰの場合にはＲＡＤＩＯ ＢＥＡＲＥＲ ＲＥＬＥＡＳＥメッセージにより、ＰＴＭの場合にはＳＥＳＳＩＯＮ ＳＴＯＰ通知メッセージ１２１によりセッション終了を通知される。全ての端末による上記ＳＥＳＳＩＯＮ ＳＴＯＰ通知の検出を可能にするために、ＵＴＲＡＮは、ＭＢＭＳサービスを受信しようとする端末がＭＣＣＨを受信するようにＭＢＭＳＮＩ１１９を再送する。
【００５１】
ＣＥＬＬ＿ＰＣＨ状態の端末の管理
ＭＢＭＳの受信を希望するＣＥＬＬ＿ＰＣＨ状態の端末をいかに管理するかについて説明する。
シグナリング、特に、サービング無線網制御器（Serving Radio Network Controller：ＳＲＮＣ）とドリフト無線網制御器（Drift Radio Network Controller：ＤＲＮＣ）との間のシグナリングを低減するために、下記の２通りの方案を提案する。
【００５２】
方案１
ＭＢＭＳサービスを提供する上で必要となるシグナリングは、ＤＲＮＣが特定のＭＢＭＳサービスに参加している端末に関する情報を保存する場合に適宜に低減可能である。この場合、ある端末がＤＲＮＣ内においてあるセルから他のセルに移動すると、ＳＲＮＣは上記情報をＤＲＮＣに提供しない。
【００５３】
例えば、ＤＲＮＣによりサービスされるある端末がＤＲＮＣ内においてあるセルから他のセルに移動すると、ＤＲＮＣは、上記保存されている情報を用いることにより、特定のサービスを受信したいＣＥＬＬ＿ＰＣＨの状態にある端末の数を正確にカウントすることができる。
【００５４】
例えば、相異なる２種類のＭＢＭＳサービス、すなわち、ＭＢＭＳサービス５及びＭＢＭＳサービス１０を受信したいＣＥＬＬ＿ＰＣＨの状態にある端末がＤＲＮＣ下位のセル１からセル２に移動すると、ＤＲＮＣは、セル１において、サービス５、１０を受信したい端末の数を１だけデクリメントし、セル２において、ＭＢＭＳサービス５、１０を受信したい端末の数を１だけインクリメントする。この場合、ＳＲＮＣがあるセルから他のセルへのあらゆる変動事項をＤＲＮＣに通知しない場合であっても、ＤＲＮＣは、相異なるＭＢＭＳサービスを受信したいＣＥＬＬ＿ＰＣＨの状態にある端末の数を常に知っている。
【００５５】
ＭＢＭＳの受信と関連して、ＣＥＬＬ＿ＰＣＨ端末の管理のために、ＣＥＬＬ＿ＰＣＨの状態にある端末に関するＭＢＭＳ情報を保存するための新規な種別のコンテキスト（すなわち、「ＭＢＭＳコンテキスト」）が用いられる。
【００５６】
このため、上記の解決方案は、このようなＭＢＭＳコンテキストにより実現可能である。これは、相異なるＭＢＭＳサービスを受信したいＣＥＬＬ＿ＰＣＨの状態にある端末の数に関する情報がＭＢＭＳコンテキスト内に保存されることを意味する。
【００５７】
方案２
ＣＥＬＬ＿ＰＣＨの状態にある端末に関する情報をＤＲＮＣに保存するための上述の解決方案を実現するための他の実施の形態として、ＭＢＭＳコンテキストではなく、端末コンテキストが用いられる場合がある。
【００５８】
特に、ＣＥＬＬ＿ＤＣＨあるいはＣＥＬＬ＿ＦＡＣＨの状態にある端末のための端末コンテキストについて述べる。ＤＲＮＣ下位の端末がＣＥＬＬ＿ＤＣＨあるいはＣＥＬＬ＿ＦＡＣＨの状態にあるとき、ＤＲＮＣは、Ｕｕチャンネルの構成あるいは無線ネットワーク臨時識別子（Radio Network Temporary Identities：ＲＮＴＩｓ）などのあらゆる端末特定の情報を保存するための端末特定のコンテキストを持つ。
【００５９】
ＣＥＬＬ＿ＰＣＨの状態にある端末のための端末コンテキストが必ずしもＤＲＮＣに設けられるとは限らないが、それにも拘わらず、Ｒ９９によれば、ＳＲＮＣは、ＤＲＮＣにＣＥＬＬ＿ＰＣＨの状態にある端末のための端末コンテキストを設けることを要請することができる。
【００６０】
ＣＥＬＬ＿ＰＣＨ端末のための端末コンテキストをＤＲＮＣに設ける場合、ＤＲＮＣは、端末が参加しているＭＢＭＳサービスに関する情報を保存することが可能であり、ＳＲＮＣは、各セルを変更する度に上記情報をＤＲＮＣに通知することが不要になる。
【００６１】
端末が１以上のＭＢＭＳサービスに参加しており、且つ、上記１以上のサービスのセッションが進行中である場合、ＳＲＮＣは、ＤＲＮＣに対して、ＣＥＬＬ＿ＰＣＨの状態にある端末についての端末コンテキストを保存するように要請することができる。
【００６２】
一方、上記端末が１以上のＭＢＭＳサービスに参加している間に、上記サービスのセッションがいずれも進行中ではない場合であっても、ＳＲＮＣは、ＤＲＮＣに対して、ＣＥＬＬ＿ＰＣＨの状態にある端末についての端末コンテキストを保持することを要請することができる。
【００６３】
方案１と比較して、方案２の利点は、既に存在している端末コンテキストを用いることにより、ＤＲＮＣにＣＥＬＬ＿ＰＣＨの状態にある端末のために付加的なコンテキストを生成させないことである。すなわち、既に存在している端末コンテキストを用いることにより、既存のＲ９９シグナリングを再利用することができる。例えば、もし、端末が第１のＲＮＣから第２のＲＮＣに移動する場合、ＤＲＮＣにこのような変動を知らせるために、既に存在しているＣＯＭＭＯＮ ＴＲＡＮＳＰＯＲＴ ＣＨＡＮＮＥＬ ＲＥＳＯＵＲＣＥ ＲＥＬＥＡＳＥ要請を用いることができる。これにより、ＤＲＮＣは、特定のサービスを受信しようとする端末の数を適宜に調整することができる。
【００６４】
ＵＲＡ＿ＰＣＨの状態におけるＰＴＭ ＭＢＭＳ ＲＢの受信への支援
現在、端末がセルレベルに位置している状態だけではなく、ＲＲＣ遊休の状態にある場合であっても、端末は、ＰＴＭ ＭＢＭＳ ＲＢを受信することが可能であることに留意すべきである。端末にＵＲＡ＿ＰＣＨの状態におけるＰＴＭ ＭＢＭＳ ＲＢの受信を可能にするために示唆されるべきことも論議される必要がある。
【００６５】
ＲＲＣ遊休の状態にある端末があるＲＡ内において移動した場合、ＲＡの更新（ＲＡ updates：ＲＡＵｓ）は行われない。結果的に、このような端末が特定のＲＡに入った場合、ネットワークは、上記ＲＡの一部である全てのセルにおいてＭＢＭＳサービスが有効であるかどうか、すなわち、各セルがマルチキャストサービス領域の一部であるかどうかに関する一貫した情報を送る必要がある。
【００６６】
ＲＲＣ遊休の状態にある端末に対して、ＲＡの全てのセルに亘って一貫した情報を保持することは、ＣＮとＵＴＲＡＮに共通して行われなければならない。
【００６７】
ＣＮは、ＲＡの一部である全てのＲＮＣにＳＥＳＳＩＯＮ ＳＴＡＲＴを伝送し、ＵＴＲＡＮは、上記ＲＡの一部であり、且つ、マルチキャスト領域の一部である全てのセルに対してＭＢＭＳービスの有効性情報を更新する。
【００６８】
ＵＲＡ内において移動してＵＲＡの更新を行わないＵＲＡ＿ＰＣＨの状態にある端末に対しても、ＲＲＣ遊休状態における動作とほとんど同じ動作が適用される。このため、ネットワークにおいては、ＵＲＡの一部である全てのセルに対してＭＢＭＳサービスが有効であるかどうかに関する一貫した情報を伝送する必要があるということは明らかである。
【００６９】
ＣＮはＵＲＡについて不知であるため、ＵＲＡの全てのセルに亘って一貫した情報を保持することはＵＴＲＡＮにおいて行う必要があるが、これは、下記の如き方法により行われる。
【００７０】
端末がＵＲＡに入ると、サービングＲＮＣ（ＳＲＮＣ）は、上記ＵＲＡの一部であるセルを司る全てのドリフトＲＮＣ（ＤＲＮＣｓ）にメッセージを伝送する。上記メッセージを通じて、ＳＲＮＣは、ＤＲＮＣに、１以上のサービスに対して、上記ＵＲＡの全てのセルにおいて正確なービスの有効性情報を提供することを要請する。上記メッセージは、以下では、「ＵＲＡ−ＡＴＴＡＣＨ」メッセージと称する。
【００７１】
ＤＲＮＣは、当該セルのための少なくとも１つのＵＲＡ−ＡＴＴＡＣＨメッセージを受信した場合、当該ＭＢＭＳサービスのためのＳＥＳＳＩＯＮ ＳＴＡＲＴメッセージを受信することを認知し、ＭＣＣＨを介して上記セッション間に正確なＭＢＭＳサービスの有効性情報を提供する。
【００７２】
端末が上記ＵＲＡから外れたり、あるいは、ＵＲＡ＿ＰＣＨの状態から外れた場合、ＳＲＮＣは、他のメッセージを用いることにより上記ＵＲＡの一部であるセルを司る全てのＤＲＮＣに上記要請が中断されることを知らせることができる。上記他のメッセージは、以下では、「ＵＲＡ−ＤＥＴＡＣＨ」メッセージと称する。
【００７３】
ＳＲＮＣは、ＳＲＮＣの観点からは、特定のＭＢＭＳサービスに参加している第１の端末がＵＲＡ＿ＰＣＨ状態においてＵＲＡに入る度に、あるいは、ＳＲＮＣの観点からは、特定のＭＢＭＳサービスに参加している最後の端末がＵＲＡ＿ＰＣＨ状態においてＵＲＡから外れる度に、ＤＲＮＣに伝送する要請を更新する。
【００７４】
ＵＲＡへの進入及びＵＲＡからの離脱は、状態の遷移、すなわち、あるＵＲＡに属するセルに既に存在しているＣＥＬＬ＿ＤＣＨの状態にある端末がＵＲＡ＿ＰＣＨの状態に遷移する場合だけではなく、移動性、すなわち、ＵＲＡ＿ＰＣＨの状態にある端末が新たなＵＲＡに移動する場合にも行われることがある。
【００７５】
ＤＲＮＣは、相異なるＳＲＮＣ（ＤＲＮＣそのものを含む）からの要請を累積し、少なくとも１つのＳＲＮＣがあるＵＲＡに関するＭＢＭＳサービスの有効性情報を希望すると、Ｕｕインタフェースを介して上記情報を提供する。
【００７６】
図４は、本発明の実施の形態によるシグナリングのシーケンスを示している。
ここでは、端末が２種類の相異なるＭＢＭＳサービス、すなわち、ＭＢＭＳサービス４と１７２を受信したい場合を示している。端末は、第１のＵＲＡＵＲＡ−３７からＤＲＮＣＤＲＮＣ１の制御する他のＵＲＡＵＲＡ−５へと移動している。ＤＲＮＣ１とＤＲＮＣ２は、両方共にＵＲＡ−５に属するセルを持つ。
【００７７】
ステップＳ２０１において、端末がＵＲＡ ＵＰＤＡＴＥメッセージをＤＲＮＣ１に伝送すると、ＤＲＮＣ１は、ＲＲＣ ＵＲＡ ＵＰＤＡＴＥメッセージとＵＲＡ情報、特に、ＵＥが移動したいＤＲＮＣ２の制御下でのＵＲＡ−５に関するＵＲＡ情報を含む上りリンク（uplink：ＵＬ）シグナリング伝送メッセージ（ＵＬ signaling transfer message）をＳＲＮＣに伝送する（ステップＳ２０３）。すると、ＳＲＮＣは、ＤＲＮＣに対して、ＲＲＣ ＵＲＡ ＵＰＤＡＴＥを確かめる下りリンク（downlink：ＤＬ）シグナリング伝送メッセージ（ＤＬ signaling transfer message）をもって応答をする（ステップＳ２０５）。ステップＳ２０７において、ＤＲＮＣ１は、ＵＲＡ ＵＰＤＡＴＥ確認メッセージを端末に伝送する。
【００７８】
上述のように、ＵＲＡの更新手順を処理することが求められる正常なシグナリング手順に加えて、ＳＲＮＣはまた、ＤＲＮＣにＵＲＡ−ＡＴＴＡＣＨメッセージを伝送することにより、現在のＭＢＭＳサービス４、１７２に関するサービスの有効性情報がＵＲＡ−５において正確にシグナリングされるべきことをＤＲＮＣ１に通知する（ステップＳ２０９）。さらに、ＭＢＭＳサービス４、１７２に関する有効性情報のシグナリングは、ＵＲＡ−３７においてはそれ以上行われる必要がないため、ＳＲＮＣは、このような情報を含むＵＲＡ−ＤＥＴＡＣＨメッセージをＤＲＮＣ１に伝送する（ステップＳ２１１）。
【００７９】
ＵＲＡ−５が２つのＲＮＣに渡っているため、ＤＲＮＣ２はまた、ＵＲＡ−ＡＴＴＡＣＨメッセージを通じてＭＢＭＳサービス４、１７２に関するサービスの有効性情報がＵＲＡ−５において保持されるべきことを通知される（ステップＳ２１３）。
【００８０】
効率を高めるために、図示の幾つかのフローは単一のメッセージに結合可能である。
上記の如き新機能の追加は、一見して多くのシグナリングを必要とするかのように見える。しかしながら、下記のことを考慮したとき、付加的なシグナリングは制限的に発生する。
【００８１】
すなわち、ＵＲＡ−ＡＴＴＡＣＨ情報の更新は、ＳＲＮＣに属する第１の端末がＤＲＮＣのＵＲＡに入ったとき、あるいは、ＳＲＮＣに属する最後の端末が当該ＵＲＡから外れたときに行われる必要がある。このため、ＵＲＡ−ＡＴＴＡＣＨメッセージが各端末がＵＲＡに入る度に更新する必要があるとは限らない。
さらに、上記の例における幾つかの情報のフローは単一のメッセージに結合可能である。
【００８２】
ＵＲＡが単一のＲＮＣに限られていると共に、端末がＳＲＮＣ内において移動するような典型的な場合、ＵＲＡに亘ってサービスの有効性情報のシグナリングを一致させることは、シグナリングの負荷を大幅に増やさない。
【００８３】
このような方式によりＩｕｒインタフェースを介して付加的なシグナリングを提供する場合、ネットワークは、あるＵＲＡの全てのセルにおいてＭＢＭＳサービスの有効性情報を一致させることができ、その結果、ＵＲＡ＿ＰＣＨ状態においてＰＴＭ ＭＢＭＳ ＲＢの受信を可能にすることができる。
【００８４】
上述の実施の形態において、共通するシグナリング（すなわち、端末特定のシグナリングではない）はＩｕｒインタフェースを介して用いられる。この場合、Ｉｕｒインタフェースを通じてのシグナリング負荷は、専用シグナリング（すなわち、端末特定のシグナリング）を用いる方案と比較して低減する。
【００８５】
ＰＴＭ ＭＢＭＳ ＲＢを受信する間に、端末をＵＲＡ＿ＰＣＨ状態に留めるためのＲ９９−Ｒ５ＲＲＭの手順に及ぼす影響は限定的であり、他のＲＲＣ接続状態に求められる端末のさらなる電力消防を排除する。
【００８６】
ＵＲＡ＿ＰＣＨの状態にある端末のためのカウント手順
以下、ＵＲＡ＿ＰＣＨの状態にある端末のためのカウント手順を高めるための２通りの方案を説明する。
【００８７】
方案１
ＵＲＡ＿ＰＣＨの状態にある端末のために、別途の確率因子を用いることが可能である。ここで、確率は、ＲＲＣ遊休の状態にある端末のための確率因子とは異なる。この場合、ＵＲＡ＿ＰＣＨの状態にある端末のための確率因子は、例えば、ＲＲＣ遊休の状態にある端末のための確率因子よりも大きく選定される。
この場合、方案１は、相異なる状態（ＲＲＣ遊休あるいはＵＲＡ＿ＰＣＨ）にある端末の割合をカウントするか、あるいは、再カウントするかを決める上での融通性を与える。
【００８８】
図５Ａは、２つの相異なる確率因子の使用を示している。シグナリングメッセージ部３０１、３０２は、ＵＲＡ＿ＰＣＨ及びＲＲＣ遊休の状態にある端末のための確率因子をそれぞれ含む。ＵＲＡ＿ＰＣＨの状態にある端末のためのカウント手順が行われると、ＵＲＡ＿ＰＣＨの状態にある端末のうち確率因子３０１により決められたシグナリング済みの割合に見合う分の端末がＵＴＲＡＮからの要請に応答するように、ＵＴＲＡＮは、端末に対して確率因子ｐ＿ＵＲＡ＿ＰＣＨをシグナリングする。これに対し、ＲＲＣ遊休の状態にある端末のためのカウント手順が行われると、ＲＲＣ遊休の状態にある端末のうち確率因子３０２により決められたシグナリング済みの割合がＵＴＲＡＮからの要請に応答するように、ＵＴＲＡＮは、端末に対して確率因子ｐ＿ＲＲＣ＿Ｉｄｌｅをシグナリングする。
【００８９】
方案２
他の方案として、どれほどの端末がカウントされるべきかを決める単一の確率因子が用いられる。上記確率因子は、ＲＲＣ遊休の状態及びＵＲＡ＿ＰＣＨの状態にある端末の両方に適用される。ＲＲＣ遊休の状態にある端末は、ＵＲＡ＿ＰＣＨの状態にある端末をカウントするあらゆる場合にカウントされるわけではない。ところが、ＵＲＡ＿ＰＣＨの状態にある端末がカウントされるあらゆる場合には、ＲＲＣ遊休の状態にある端末もカウントされることがある。
【００９０】
この方案は、ＲＲＣ遊休の状態にある端末をＲＲＣ接続の状態に遷移させるよりも、ＵＲＡ＿ＰＣＨ端末を他のＲＲＣ接続の状態に遷移させた方が一層簡単であるということに基づいている。
【００９１】
この方案は、例えば、端末に対してＵｕインタフェースを介してシグナリングされる確率因子に１ビットのフラグを追加することにより実現可能である。上記フラグは、カウント手順が行われる状態を示し、後述する「ＵＲＡ−ＰＣＨ」及び「ＲＲＣ遊休」などの２通りを行い分ける。
【００９２】
上記フラグが「ＵＲＡ−ＰＣＨ」を指示する場合、カウント手順は、専らＵＲＡ＿ＰＣＨの状態にある端末に対してのみ行われる。すなわち、このような端末に対して上記シグナリング済みの確率因子が適用される。ＲＲＣ遊休の状態にある端末は、カウントと関連してＲＲＣ接続を設定する必要がない。すなわち、この場合、確率因子は、現在ＲＲＣ遊休の状態にある端末に適用されない。
【００９３】
上記フラグが「ＲＲＣ遊休」を指示する場合、ＭＢＭＳサービスに参加していると共に、ＵＲＡ＿ＰＣＨの状態にある全ての端末は、カウントの要求に応答するためにＲＲＣ接続を設定する必要がある。これらの端末にはまた、ＲＲＣ接続の状態に遷移することが求められる。
【００９４】
図５Ｂは、共通する確率因子３１１とフラグ３１２を含んでＵＴＲＡＮから端末へと伝送されるメッセージを示している。
【００９５】
以上の実施の形態は、単なる好適な実施の形態として理解されなければならず、特許請求の範囲に記載の本発明の範囲から逸脱しない範囲内であれば、種々な特徴の省略、変形や置換が可能であることは言うまでもない。
【符号の説明】
【００９６】
２  基地局
４  無線網制御器（ＲＮＣ）
６  ＲＡＮ
８  コアネットワーク
１０  Ｉｕｂインタフェース
１２  Ｉｕインタフェース
１４  Ｉｕｒインタフェース
【図１】
2010279048.tif 000003
【図２】
2010279048.tif 000004
【図３】
2010279048.tif 000005
【図４】
2010279048.tif 000006
【図５】
2010279048.tif 000007