(57)【要約】【課題】マクロセルに加えて多数のスモールセルを設置して運用する場合の通信端末装置の通信性能を向上させる。【解決手段】通信システムは、通信端末装置（ＵＥ）と、通信端末装置と無線通信可能に構成された複数の基地局とを備える。複数の基地局は、通信端末装置に対して緊急サービス用の緊急ベアラを提供する第１基地局（ＭｅＮＢ）を含む。緊急ベアラを提供している状態の第１基地局が、複数の基地局のうちの第２基地局（ＳｅＮＢ）に対して、第１基地局と共に通信端末装置に対してデュアルコネクティビティ（ＤＣ）を実行することの要求を送信する場合、第１基地局は、ＤＣが緊急ベアラに対するものであることを示す情報を第２基地局に送信する（ステップＳＴ２２１５）。【選択図】図２１
2020198647.tif 000002
【特許請求の範囲】
【請求項１】
通信端末装置と、
前記通信端末装置と無線通信可能に構成された複数の基地局と
を備える通信システムであって、
前記複数の基地局は、前記通信端末装置に対して緊急サービス用の緊急ベアラを提供する第１基地局を含み、
前記緊急ベアラを提供している状態の前記第１基地局が、前記複数の基地局のうちの第２基地局に対して、前記第１基地局と共に前記通信端末装置に対してデュアルコネクティビティ（ＤＣ）を実行することの要求を送信する場合、前記第１基地局は、前記ＤＣが前記緊急ベアラに対するものであることを示す情報を前記第２基地局に送信する、
ことを特徴とする通信システム。
【請求項２】
前記第２基地局は、前記ＤＣが前記緊急ベアラに対するものであることを示す前記情報を受信した場合、所定の状況下では前記緊急ベアラに対する前記ＤＣを実行せず、
前記所定の状況は、前記第２基地局が前記緊急ベアラの設立を許可していないという状況を含む、
ことを特徴とする請求項１に記載の通信システム。
【請求項３】
前記所定の状況は、前記通信システムの状況と前記通信端末装置の消費電力とのうちの少なくとも１つが、前記緊急ベアラに対する前記ＤＣを実行するための条件を満足していないという状況を、さらに含むことを特徴とする請求項２に記載の通信システム。
【請求項４】
通信端末装置と無線通信可能に構成された基地局であって、
前記基地局は、前記通信端末装置に対して緊急サービス用の緊急ベアラを提供可能に構成され、
前記緊急ベアラを提供している状態の前記基地局が、他の基地局に対して、前記基地局と共に前記通信端末装置に対してデュアルコネクティビティ（ＤＣ）を実行することの要求を送信する場合、前記基地局は、前記ＤＣが前記緊急ベアラに対するものであることを示す情報を前記他の基地局に送信する、
ことを特徴とする基地局。
【請求項５】
通信端末装置と無線通信可能に構成された基地局であって、
前記基地局は、前記通信端末装置に対してデュアルコネクティビティ（ＤＣ）を提供可能に構成され、
前記基地局は、前記通信端末装置に対して緊急サービス用の緊急ベアラを提供している状態の前記他の基地局から、前記他の基地局と共に前記ＤＣを実行することの要求と、前記ＤＣが前記緊急ベアラに対するものであることを示す情報とを受信した場合、前記基地局は、所定の状況下では前記緊急ベアラに対する前記ＤＣを実行せず、
前記所定の状況は、前記基地局は前記緊急ベアラの設立が許可されていないという状況を含む、
ことを特徴とする基地局。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、無線通信技術に関する。
【背景技術】
【０００２】
移動体通信システムの規格化団体である３ＧＰＰ（3rd Generation Partnership Project）において、無線区間についてはロングタームエボリューション（Long Term Evolution：ＬＴＥ）と称し、コアネットワークおよび無線アクセスネットワーク（以下、まとめて、ネットワークとも称する）を含めたシステム全体構成については、システムアーキテクチャエボリューション（System Architecture Evolution：ＳＡＥ）と称される新たな通信方式が検討されている（例えば、非特許文献１〜１４参照）。この通信方式は３．９Ｇ（3.9 Generation）システムとも呼ばれる。
【０００３】
ＬＴＥのアクセス方式としては、下り方向はＯＦＤＭ（Orthogonal Frequency Division Multiplexing）、上り方向はＳＣ−ＦＤＭＡ（Single Carrier Frequency Division Multiple Access）が用いられる。また、ＬＴＥは、Ｗ−ＣＤＭＡ（Wideband Code division Multiple Access）とは異なり、回線交換を含まず、パケット通信方式のみになる。
【０００４】
非特許文献１（５章）に記載される、３ＧＰＰでの、ＬＴＥシステムにおけるフレーム構成に関する決定事項について、図１を用いて説明する。図１は、ＬＴＥ方式の通信システムで使用される無線フレームの構成を示す説明図である。図１において、１つの無線フレーム（Radio frame）は１０ｍｓである。無線フレームは１０個の等しい大きさのサブフレーム（Subframe）に分割される。サブフレームは、２個の等しい大きさのスロット（slot）に分割される。無線フレーム毎に１番目および６番目のサブフレームに下り同期信号（Downlink Synchronization Signal：ＳＳ）が含まれる。同期信号には、第一同期信号（Primary Synchronization Signal：Ｐ−ＳＳ）と、第二同期信号（Secondary Synchronization Signal：Ｓ−ＳＳ）とがある。
【０００５】
３ＧＰＰでの、ＬＴＥシステムにおけるチャネル構成に関する決定事項が、非特許文献１（５章）に記載されている。ＣＳＧ（Closed Subscriber Group）セルにおいてもｎｏｎ−ＣＳＧセルと同じチャネル構成が用いられると想定されている。
【０００６】
物理報知チャネル（Physical Broadcast channel：ＰＢＣＨ）は、基地局から移動端末への下り送信用のチャネルである。ＢＣＨトランスポートブロック（transport block）は、４０ｍｓ間隔中の４個のサブフレームにマッピングされる。４０ｍｓタイミングの明白なシグナリングはない。
【０００７】
物理制御フォーマットインジケータチャネル（Physical Control Format Indicator Channel：ＰＣＦＩＣＨ）は、基地局から移動端末への下り送信用のチャネルである。ＰＣＦＩＣＨは、ＰＤＣＣＨｓのために用いるＯＦＤＭ（Orthogonal Frequency Division Multiplexing）シンボルの数について基地局から移動端末へ通知する。ＰＣＦＩＣＨは、サブフレーム毎に送信される。
【０００８】
物理下り制御チャネル（Physical Downlink Control Channel：ＰＤＣＣＨ）は、基地局から移動端末への下り送信用のチャネルである。ＰＤＣＣＨは、後述のトランスポートチャネルの１つである下り共有チャネル（Downlink Shared Channel：ＤＬ−ＳＣＨ）のリソース割り当て（allocation）情報、後述のトランスポートチャネルの１つであるページングチャネル（Paging Channel：ＰＣＨ）のリソース割り当て（allocation）情報、ＤＬ−ＳＣＨに関するＨＡＲＱ（Hybrid Automatic Repeat reQuest）情報を通知する。ＰＤＣＣＨは、上りスケジューリンググラント（Uplink Scheduling Grant）を運ぶ。ＰＤＣＣＨは、上り送信に対する応答信号であるＡｃｋ（Acknowledgement）／Ｎａｃｋ（Negative Acknowledgement）を運ぶ。ＰＤＣＣＨは、Ｌ１／Ｌ２制御信号とも呼ばれる。
【０００９】
物理下り共有チャネル（Physical Downlink Shared Channel：ＰＤＳＣＨ）は、基地局から移動端末への下り送信用のチャネルである。ＰＤＳＣＨには、トランスポートチャネルである下り共有チャネル（ＤＬ−ＳＣＨ）、およびトランスポートチャネルであるＰＣＨがマッピングされている。
【００１０】
物理マルチキャストチャネル（Physical Multicast Channel：ＰＭＣＨ）は、基地局から移動端末への下り送信用のチャネルである。ＰＭＣＨには、トランスポートチャネルであるマルチキャストチャネル（Multicast Channel：ＭＣＨ）がマッピングされている。
【００１１】
物理上り制御チャネル（Physical Uplink Control Channel：ＰＵＣＣＨ）は、移動端末から基地局への上り送信用のチャネルである。ＰＵＣＣＨは、下り送信に対する応答信号（response signal）であるＡｃｋ／Ｎａｃｋを運ぶ。ＰＵＣＣＨは、ＣＱＩ（Channel Quality Indicator）レポートを運ぶ。ＣＱＩとは、受信したデータの品質、もしくは通信路品質を示す品質情報である。またＰＵＣＣＨは、スケジューリングリクエスト（Scheduling Request：ＳＲ）を運ぶ。
【００１２】
物理上り共有チャネル（Physical Uplink Shared Channel：ＰＵＳＣＨ）は、移動端末から基地局への上り送信用のチャネルである。ＰＵＳＣＨには、トランスポートチャネルの１つである上り共有チャネル（Uplink Shared Channel：ＵＬ−ＳＣＨ）がマッピングされている。
【００１３】
物理ＨＡＲＱインジケータチャネル（Physical Hybrid ARQ Indicator Channel：ＰＨＩＣＨ）は、基地局から移動端末への下り送信用のチャネルである。ＰＨＩＣＨは、上り送信に対する応答信号であるＡｃｋ／Ｎａｃｋを運ぶ。物理ランダムアクセスチャネル（Physical Random Access Channel：ＰＲＡＣＨ）は、移動端末から基地局への上り送信用のチャネルである。ＰＲＡＣＨは、ランダムアクセスプリアンブル（random access preamble）を運ぶ。
【００１４】
下り参照信号（リファレンスシグナル（Reference Signal）：ＲＳ）は、ＬＴＥ方式の通信システムとして既知のシンボルである。以下の５種類の下りリファレンスシグナルが定義されている。セル固有参照信号（Cell-specific Reference Signals：ＣＲＳ）、ＭＢＳＦＮ参照信号（MBSFN reference signals）、ＵＥ固有参照信号（UE-specific reference signals）であるデータ復調用参照信号（Demodulation Reference Signal：ＤＭ−ＲＳ）、位置決定参照信号（Positioning Reference Signals：ＰＲＳ）、チャネル情報参照信号（Channel-State Information Reference Signals：ＣＳＩ−ＲＳ）。移動端末の物理レイヤの測定として、リファレンスシグナルの受信電力（Reference Signal Received Power：ＲＳＲＰ）測定がある。
【００１５】
非特許文献１（５章）に記載されるトランスポートチャネル（Transport channel）について、説明する。下りトランスポートチャネルのうち、報知チャネル（Broadcast Channel：ＢＣＨ）は、その基地局（セル）のカバレッジ全体に報知される。ＢＣＨは、物理報知チャネル（ＰＢＣＨ）にマッピングされる。
【００１６】
下り共有チャネル（Downlink Shared Channel：ＤＬ−ＳＣＨ）には、ＨＡＲＱ（Hybrid ARQ）による再送制御が適用される。ＤＬ−ＳＣＨは、基地局（セル）のカバレッジ全体への報知が可能である。ＤＬ−ＳＣＨは、ダイナミックあるいは準静的（Semi-static）なリソース割り当てをサポートする。準静的なリソース割り当ては、パーシステントスケジューリング（Persistent Scheduling）ともいわれる。ＤＬ−ＳＣＨは、移動端末の低消費電力化のために移動端末の間欠受信（Discontinuous reception：ＤＲＸ）をサポートする。ＤＬ−ＳＣＨは、物理下り共有チャネル（ＰＤＳＣＨ）へマッピングされる。
【００１７】
ページングチャネル（Paging Channel：ＰＣＨ）は、移動端末の低消費電力を可能とするために移動端末のＤＲＸをサポートする。ＰＣＨは、基地局（セル）のカバレッジ全体への報知が要求される。ＰＣＨは、動的にトラフィックに利用できる物理下り共有チャネル（ＰＤＳＣＨ）のような物理リソースへマッピングされる。
【００１８】
マルチキャストチャネル（Multicast Channel：ＭＣＨ）は、基地局（セル）のカバレッジ全体への報知に使用される。ＭＣＨは、マルチセル送信におけるＭＢＭＳ（Multimedia Broadcast Multicast Service）サービス（ＭＴＣＨとＭＣＣＨ）のＳＦＮ合成をサポートする。ＭＣＨは、準静的なリソース割り当てをサポートする。ＭＣＨは、ＰＭＣＨへマッピングされる。
【００１９】
上りトランスポートチャネルのうち、上り共有チャネル（Uplink Shared Channel：ＵＬ−ＳＣＨ）には、ＨＡＲＱ（Hybrid ARQ）による再送制御が適用される。ＵＬ−ＳＣＨは、ダイナミックあるいは準静的（Semi-static）なリソース割り当てをサポートする。ＵＬ−ＳＣＨは、物理上り共有チャネル（ＰＵＳＣＨ）へマッピングされる。
【００２０】
ランダムアクセスチャネル（Random Access Channel：ＲＡＣＨ）は、制御情報に限られている。ＲＡＣＨは、衝突のリスクがある。ＲＡＣＨは、物理ランダムアクセスチャネル（ＰＲＡＣＨ）へマッピングされる。
【００２１】
ＨＡＲＱについて説明する。ＨＡＲＱとは、自動再送要求（Automatic Repeat reQuest：ＡＲＱ）と誤り訂正（Forward Error Correction）との組合せにより、伝送路の通信品質を向上させる技術である。ＨＡＲＱには、通信品質が変化する伝送路に対しても、再送により誤り訂正が有効に機能するという利点がある。特に、再送にあたって初送の受信結果と再送の受信結果との合成をすることで、更なる品質向上を得ることも可能である。
【００２２】
再送の方法の一例を説明する。受信側にて、受信データが正しくデコードできなかった場合、換言すればＣＲＣ（Cyclic Redundancy Check）エラーが発生した場合（ＣＲＣ＝ＮＧ）、受信側から送信側へ「Ｎａｃｋ」を送信する。「Ｎａｃｋ」を受信した送信側は、データを再送する。受信側にて、受信データが正しくデコードできた場合、換言すればＣＲＣエラーが発生しない場合（ＣＲＣ＝ＯＫ）、受信側から送信側へ「Ａｃｋ」を送信する。「Ａｃｋ」を受信した送信側は次のデータを送信する。
【００２３】
非特許文献１（６章）に記載される論理チャネル（ロジカルチャネル：Logical channel）について、説明する。報知制御チャネル（Broadcast Control Channel：ＢＣＣＨ）は、報知システム制御情報のための下りチャネルである。論理チャネルであるＢＣＣＨは、トランスポートチャネルである報知チャネル（ＢＣＨ）、あるいは下り共有チャネル（ＤＬ−ＳＣＨ）へマッピングされる。
【００２４】
ページング制御チャネル（Paging Control Channel：ＰＣＣＨ）は、ページング情報（Paging Information）およびシステム情報（System Information）の変更を送信するための下りチャネルである。ＰＣＣＨは、移動端末のセルロケーションをネットワークが知らない場合に用いられる。論理チャネルであるＰＣＣＨは、トランスポートチャネルであるページングチャネル（ＰＣＨ）へマッピングされる。
【００２５】
共有制御チャネル（Common Control Channel：ＣＣＣＨ）は、移動端末と基地局との間の送信制御情報のためのチャネルである。ＣＣＣＨは、移動端末がネットワークとの間でＲＲＣ接続（connection）を有していない場合に用いられる。下り方向では、ＣＣＣＨは、トランスポートチャネルである下り共有チャネル（ＤＬ−ＳＣＨ）へマッピングされる。上り方向では、ＣＣＣＨは、トランスポートチャネルである上り共有チャネル（ＵＬ−ＳＣＨ）へマッピングされる。
【００２６】
マルチキャスト制御チャネル（Multicast Control Channel：ＭＣＣＨ）は、１対多の送信のための下りチャネルである。ＭＣＣＨは、ネットワークから移動端末への１つあるいはいくつかのＭＴＣＨ用のＭＢＭＳ制御情報の送信のために用いられる。ＭＣＣＨは、ＭＢＭＳ受信中の移動端末のみに用いられる。ＭＣＣＨは、トランスポートチャネルであるマルチキャストチャネル（ＭＣＨ）へマッピングされる。
【００２７】
個別制御チャネル（Dedicated Control Channel：ＤＣＣＨ）は、１対１にて、移動端末とネットワークとの間の個別制御情報を送信するチャネルである。ＤＣＣＨは、移動端末がＲＲＣ接続（connection）である場合に用いられる。ＤＣＣＨは、上りでは上り共有チャネル（ＵＬ−ＳＣＨ）へマッピングされ、下りでは下り共有チャネル（ＤＬ−ＳＣＨ）にマッピングされる。
【００２８】
個別トラフィックチャネル（Dedicated Traffic Channel：ＤＴＣＨ）は、ユーザ情報の送信のための個別移動端末への１対１通信のチャネルである。ＤＴＣＨは、上りおよび下りともに存在する。ＤＴＣＨは、上りでは上り共有チャネル（ＵＬ−ＳＣＨ）へマッピングされ、下りでは下り共有チャネル（ＤＬ−ＳＣＨ）へマッピングされる。
【００２９】
マルチキャストトラフィックチャネル（Multicast Traffic channel：ＭＴＣＨ）は、ネットワークから移動端末へのトラフィックデータ送信のための下りチャネルである。ＭＴＣＨは、ＭＢＭＳ受信中の移動端末のみに用いられるチャネルである。ＭＴＣＨは、マルチキャストチャネル（ＭＣＨ）へマッピングされる。
【００３０】
ＣＧＩとは、セルグローバル識別子（Cell Global Identifier）のことである。ＥＣＧＩとは、Ｅ−ＵＴＲＡＮセルグローバル識別子（E-UTRAN Cell Global Identifier）のことである。ＬＴＥ、後述のＬＴＥ−Ａ（Long Term Evolution Advanced）およびＵＭＴＳ（Universal Mobile Telecommunication System）において、ＣＳＧ（Closed Subscriber Group）セルが導入される。
【００３１】
ＣＳＧ（Closed Subscriber Group）セルとは、利用可能な加入者をオペレータが特定しているセル（以下「特定加入者用セル」という場合がある）である。特定された加入者は、ＰＬＭＮ（Public Land Mobile Network）の１つ以上のセルにアクセスすることが許可される。特定された加入者がアクセスを許可されている１つ以上のセルを「ＣＳＧセル（ＣＳＧ  ｃｅｌｌ（ｓ））」と呼ぶ。ただし、ＰＬＭＮにはアクセス制限がある。
【００３２】
ＣＳＧセルは、固有のＣＳＧアイデンティティ（CSG identity：ＣＳＧ  ＩＤ；ＣＳＧ−ＩＤ）を報知し、ＣＳＧインジケーション（CSG Indication）にて「ＴＲＵＥ」を報知するＰＬＭＮの一部である。予め利用登録し、許可された加入者グループのメンバーは、アクセス許可情報であるところのＣＳＧ−ＩＤを用いてＣＳＧセルにアクセスする。
【００３３】
ＣＳＧ−ＩＤは、ＣＳＧセルまたはセルによって報知される。ＬＴＥ方式の通信システムにＣＳＧ−ＩＤは複数存在する。そして、ＣＳＧ−ＩＤは、ＣＳＧ関連のメンバーのアクセスを容易にするために、移動端末（ＵＥ）によって使用される。
【００３４】
移動端末の位置追跡は、１つ以上のセルからなる区域を単位に行われる。位置追跡は、待受け状態であっても移動端末の位置を追跡し、移動端末を呼び出す、換言すれば移動端末が着呼することを可能にするために行われる。この移動端末の位置追跡のための区域をトラッキングエリアと呼ぶ。
【００３５】
３ＧＰＰにおいて、Ｈｏｍｅ−ＮｏｄｅＢ（Ｈｏｍｅ−ＮＢ；ＨＮＢ）、Ｈｏｍｅ−ｅＮｏｄｅＢ（Ｈｏｍｅ−ｅＮＢ；ＨｅＮＢ）と称される基地局が検討されている。ＵＴＲＡＮにおけるＨＮＢ、およびＥ−ＵＴＲＡＮにおけるＨｅＮＢは、例えば家庭、法人、商業用のアクセスサービス向けの基地局である。非特許文献３には、ＨｅＮＢおよびＨＮＢへのアクセスの３つの異なるモードが開示されている。具体的には、オープンアクセスモード（Open access mode）と、クローズドアクセスモード（Closed access mode）と、ハイブリッドアクセスモード（Hybrid access mode）とが開示されている。
【００３６】
各々のモードは、以下のような特徴を有する。オープンアクセスモードでは、ＨｅＮＢおよびＨＮＢは、通常のオペレータのノーマルセルとして操作される。クローズドアクセスモードでは、ＨｅＮＢおよびＨＮＢは、ＣＳＧセルとして操作される。このＣＳＧセルは、ＣＳＧメンバーのみアクセス可能なＣＳＧセルである。ハイブリッドアクセスモードでは、ＨｅＮＢおよびＨＮＢは、非ＣＳＧメンバーも同時にアクセス許可されているＣＳＧセルとして操作される。言い換えれば、ハイブリッドアクセスモードのセル（ハイブリッドセルとも称する）は、オープンアクセスモードとクローズドアクセスモードとの両方をサポートするセルである。
【００３７】
３ＧＰＰでは、全ての物理セル識別子（Physical Cell Identity：ＰＣＩ）のうち、ＣＳＧセルで使用するためにネットワークによって予約されたＰＣＩ範囲がある（非特許文献１  １０．５．１．１章参照）。ＰＣＩ範囲を分割することをＰＣＩスプリットと称することがある。ＰＣＩスプリットに関する情報（ＰＣＩスプリット情報とも称する）は、システム情報によって基地局から傘下の移動端末に対して報知される。基地局の傘下とは、該基地局をサービングセルとすることを意味する。
【００３８】
非特許文献４は、ＰＣＩスプリットを用いた移動端末の基本動作を開示する。ＰＣＩスプリット情報を有していない移動端末は、全ＰＣＩを用いて、例えば５０４コード全てを用いて、セルサーチを行う必要がある。これに対して、ＰＣＩスプリット情報を有する移動端末は、当該ＰＣＩスプリット情報を用いてセルサーチを行うことが可能である。
【００３９】
また３ＧＰＰでは、リリース１０として、ロングタームエボリューションアドヴァンスド（Long Term Evolution Advanced：ＬＴＥ−Ａ）の規格策定が進められている（非特許文献５、非特許文献６参照）。ＬＴＥ−Ａは、ＬＴＥの無線区間通信方式を基本とし、それにいくつかの新技術を加えて構成される。
【００４０】
ＬＴＥ−Ａシステムでは、１００ＭＨｚまでのより広い周波数帯域幅（transmission bandwidths）をサポートするために、二つ以上のコンポーネントキャリア（Component Carrier：ＣＣ）を集約する（「アグリゲーション（aggregation）する」とも称する）、キャリアアグリゲーション（Carrier Aggregation：ＣＡ）が検討されている。
【００４１】
ＣＡが構成される場合、ＵＥはネットワーク（Network：ＮＷ）と唯一つのＲＲＣ接続（RRC connection）を有する。ＲＲＣ接続において、一つのサービングセルがＮＡＳモビリティ情報とセキュリティ入力を与える。このセルをプライマリセル（Primary Cell：ＰＣｅｌｌ）と呼ぶ。下りリンクで、ＰＣｅｌｌに対応するキャリアは、下りプライマリコンポーネントキャリア（Downlink Primary Component Carrier：ＤＬ  ＰＣＣ）である。上りリンクで、ＰＣｅｌｌに対応するキャリアは、上りプライマリコンポーネントキャリア（Uplink Primary Component Carrier：ＵＬ  ＰＣＣ）である。
【００４２】
ＵＥの能力（ケーパビリティ（capability））に応じて、セカンダリセル（Secondary Cell：ＳＣｅｌｌ）が、ＰＣｅｌｌとサービングセルとの組を形成するために構成される。下りリンクで、ＳＣｅｌｌに対応するキャリアは、下りセカンダリコンポーネントキャリア（Downlink Secondary Component Carrier：ＤＬ  ＳＣＣ）である。上りリンクで、ＳＣｅｌｌに対応するキャリアは、上りセカンダリコンポーネントキャリア（Uplink Secondary Component Carrier：ＵＬ  ＳＣＣ）である。
【００４３】
一つのＵＥに対して、一つのＰＣｅｌｌと、一つ以上のＳＣｅｌｌからなるサービングセルとの組が構成される。
【００４４】
また、ＬＴＥ−Ａでの新技術としては、より広い帯域をサポートする技術（Wider bandwidth extension）、および多地点協調送受信（Coordinated Multiple Point transmission and reception：ＣｏＭＰ）技術などがある。３ＧＰＰでＬＴＥ−Ａのために検討されているＣｏＭＰについては、非特許文献７に記載されている。
【００４５】
また、３ＧＰＰにおいて、リリース１２版の規格書の策定が進められている。この中で、将来の膨大なトラフィックに対応するために、スモールセルを構成するスモールｅＮＢを用いることが検討されている。例えば、多数のスモールｅＮＢを設置して、多数のスモールセルを構成することによって、周波数利用効率を高めて、通信容量の増大を図る技術などが検討されている。
【００４６】
モバイルネットワークのトラフィック量は、増加傾向にあり、通信速度も高速化が進んでいる。ＬＴＥおよびＬＴＥ−Ａが本格的に運用を開始されると、更に通信速度が高速化され、トラフィック量が増加することが見込まれる。
【先行技術文献】
【非特許文献】
【００４７】
【非特許文献１】３ＧＰＰ  ＴＳ３６．３００  Ｖ１２．１．０
【非特許文献２】３ＧＰＰ  ＴＳ３６．３０４  Ｖ１２．０．０
【非特許文献３】３ＧＰＰ  Ｓ１−０８３４６１
【非特許文献４】３ＧＰＰ  Ｒ２−０８２８９９
【非特許文献５】３ＧＰＰ  ＴＲ  ３６．８１４  Ｖ９．０．０
【非特許文献６】３ＧＰＰ  ＴＲ  ３６．９１２  Ｖ１０．０．０
【非特許文献７】３ＧＰＰ  ＴＲ  ３６．８１９  Ｖ１１．２．０
【非特許文献８】３ＧＰＰ  ＴＳ  ３６．１４１  Ｖ１２．４．０
【非特許文献９】３ＧＰＰ  ＴＲ３６．８４２  Ｖ１２．０．０
【非特許文献１０】３ＧＰＰ  ＴＳ２３．０４１  Ｖ１２．５．０
【非特許文献１１】３ＧＰＰ  Ｒ２-１４２４７１
【非特許文献１２】３ＧＰＰ  Ｒ２-１４２０２７
【非特許文献１３】３ＧＰＰ  ＴＳ２３．４０１  Ｖ１２．４．０
【非特許文献１４】３ＧＰＰ  ＴＳ３６．２１１  Ｖ１２．１．０
【発明の概要】
【発明が解決しようとする課題】
【００４８】
マクロセルに加えて多数のスモールセルを設置して運用する場合、モビリティ性能の劣化、干渉の増大という問題が生じる。これらの問題を解決するために、３ＧＰＰでは、デュアルコネクティビティ（Dual connectivity；略称：ＤＣ）技術の検討が進められている。ＤＣでは、ＵＥが、マクロセルとスモールセルとを用いて通信を行うことが検討されている。具体的には、マクロセルによってＵＥのモビリティ性能を確保するとともに、データ通信を行うときに、マクロセルのリソースとスモールセルのリソースとを併せて用いることによって、スループットの増大を図ることが検討されている。
【００４９】
しかし、従来の技術に対してＤＣを何の工夫も無く適用すると、実現不可能な技術が生じてしまうという問題がある。例えば、警報（warning）情報の通知サービスであるＰＷＳ（Public Warning System）、緊急サービス（emergency service）、およびＵＥ要求ベアラ修正などである。ＰＷＳでは、ＤＣ中のＵＥに対して、スモールセル向けの警報情報を通知することは不可能である。緊急サービスでは、ＤＣを実行するときに、セカンダリｅＮＢが自ｅＮＢの状況でＤＣの実行を拒否してしまう場合が生じる。ＵＥ要求ベアラ修正では、ＤＣされたベアラの修正は行うことができない。このような問題を解決する方法が要求される。
【００５０】
また、ＤＣにおいて、マクロセルに加えて多数のスモールセルを設置して運用することを考慮した場合、さらにモビリティ性能の向上が望まれる。例えば、ＵＥがマクロセル内で移動し、スモールセルの変更を行うような場合、従来技術におけるＵＥの位置および移動状態の導出方法では、最適なスモールセルの変更を行うことができず、モビリティ性能が劣化してしまうという問題が生じる。
【００５１】
また、３ＧＰＰでは、ＣｏＭＰおよびＭＩＭＯ（Multiple Input and Multiple Output）などのように、ＵＥに対して複数のセル（ポイント）あるいは複数のアンテナを用いて通信を行う技術が検討されている。この技術では、複数のセルあるいは複数のアンテナを協調して用いることによって、干渉の影響を低減し、スループットの増大を図る。
【００５２】
しかし、ＣｏＭＰおよびＭＩＭＯなどの技術において、マクロセルに加えて多数のスモールセルを設置して運用することを考慮した場合、さらにモビリティ性能の改善および干渉の低減を図る技術、あるいは、ＵＥの移動先のセルで最適なスケジューリングを可能としてスループットの増大を図る技術が要求される。
【００５３】
本発明の目的は、マクロセルに加えて多数のスモールセルを設置して運用する場合の通信端末装置の通信性能を向上させることである。
【課題を解決するための手段】
【００５４】
本発明の通信システムは、通信端末装置と、前記通信端末装置と無線通信可能に構成された複数の基地局とを備える通信システムであって、前記複数の基地局は、前記通信端末装置に対して緊急サービス用の緊急ベアラを提供する第１基地局を含み、前記緊急ベアラを提供している状態の前記第１基地局が、前記複数の基地局のうちの第２基地局に対して、前記第１基地局と共に前記通信端末装置に対してデュアルコネクティビティ（ＤＣ）を実行することの要求を送信する場合、前記第１基地局は、前記ＤＣが前記緊急ベアラに対するものであることを示す情報を前記第２基地局に送信する、ことを特徴とする。
本発明の基地局は、通信端末装置と無線通信可能に構成された基地局であって、前記基地局は、前記通信端末装置に対して緊急サービス用の緊急ベアラを提供可能に構成され、前記緊急ベアラを提供している状態の前記基地局が、他の基地局に対して、前記基地局と共に前記通信端末装置に対してデュアルコネクティビティ（ＤＣ）を実行することの要求を送信する場合、前記基地局は、前記ＤＣが前記緊急ベアラに対するものであることを示す情報を前記他の基地局に送信する、ことを特徴とする。
本発明の基地局は、通信端末装置と無線通信可能に構成された基地局であって、前記基地局は、前記通信端末装置に対してデュアルコネクティビティ（ＤＣ）を提供可能に構成され、前記基地局は、前記通信端末装置に対して緊急サービス用の緊急ベアラを提供している状態の前記他の基地局から、前記他の基地局と共に前記ＤＣを実行することの要求と、前記ＤＣが前記緊急ベアラに対するものであることを示す情報とを受信した場合、前記基地局は、所定の状況下では前記緊急ベアラに対する前記ＤＣを実行せず、前記所定の状況は、前記基地局は前記緊急ベアラの設立が許可されていないという状況を含む、ことを特徴とする。
【発明の効果】
【００５５】
本発明によれば、マクロセルに加えて多数のスモールセルを設置して運用する場合の通信端末装置の通信性能を向上させることができる。
【００５６】
本発明の目的、特徴、局面、および利点は、以下の詳細な説明と添付図面とによって、より明白となる。
【図面の簡単な説明】
【００５７】
【図１】ＬＴＥ方式の通信システムで使用される無線フレームの構成を示す説明図である。
【図２】３ＧＰＰにおいて議論されているＬＴＥ方式の通信システム７００の全体的な構成を示すブロック図である。
【図３】本発明に係る移動端末である図２に示す移動端末７１の構成を示すブロック図である。
【図４】本発明に係る基地局である図２に示す基地局７２の構成を示すブロック図である。
【図５】本発明に係るＭＭＥの構成を示すブロック図である。
【図６】ＬＴＥ方式の通信システムにおいて移動端末（ＵＥ）が行うセルサーチから待ち受け動作までの概略を示すフローチャートである。
【図７】マクロｅＮＢとスモールｅＮＢとが混在する場合のセルの構成の概念を示す図である。
【図８】マクロセルとスモールセルとがオーバレイされる場合のセルの構成の一例を示す図である。
【図９】実施の形態１の通信システムにおけるＰＷＳメッセージの流れの一例を示す図である。
【図１０】実施の形態１の通信システムにおけるＰＷＳメッセージ通知処理のシーケンスの一例を示す図である。
【図１１】実施の形態１の通信システムにおけるＰＷＳメッセージ通知処理のシーケンスの他の例を示す図である。
【図１２】実施の形態１の変形例１の通信システムにおけるＰＷＳメッセージの流れの一例を示す図である。
【図１３】実施の形態１の変形例１の通信システムにおけるＰＷＳメッセージ通知処理のシーケンスの一例を示す図である。
【図１４】実施の形態１の変形例１の通信システムにおけるＰＷＳメッセージ通知処理のシーケンスの他の例を示す図である。
【図１５】実施の形態１の変形例２の通信システムにおけるＰＷＳメッセージの流れの一例を示す図である。
【図１６】実施の形態１の変形例２の通信システムにおけるＰＷＳメッセージ通知処理のシーケンスの一例を示す図である。
【図１７】実施の形態１の変形例２の通信システムにおけるＰＷＳメッセージ通知処理のシーケンスの他の例を示す図である。
【図１８】実施の形態１の変形例３の通信システムにおけるＰＷＳメッセージ通知処理のシーケンスの一例を示す図である。
【図１９】実施の形態１の変形例３の通信システムにおけるＰＷＳメッセージ通知処理のシーケンスの他の例を示す図である。
【図２０】実施の形態１の変形例４の通信システムにおけるＰＷＳメッセージの流れの一例を示す図である。
【図２１】実施の形態２の通信システムにおける緊急ベアラに対するＤＣ実行処理のシーケンスの一例を示す図である。
【図２２】実施の形態３の通信システムにおけるＵＥ起動のＤＣ用ベアラ修正処理のシーケンスの一例を示す図である。
【図２３】実施の形態３の通信システムにおけるＵＥ起動のＤＣ用ベアラ修正処理のシーケンスの他の例を示す図である。
【図２４】実施の形態４の変形例１の通信システムにおけるＳＣＧセルのメジャメント処理のシーケンスの一例を示す図である。
【図２５】３ＧＰＰで検討されているＵＬ  ＣｏＭＰの概念を示す図である。
【図２６】実施の形態５の変形例１の通信システムにおけるＤＣの動作の一例を示す図である。
【図２７】実施の形態５の変形例１の通信システムにおけるＤＣの動作の一例を示す図である。
【図２８】実施の形態６で解決する課題の概念を示す図である。
【図２９】実施の形態６の通信システムにおけるＳＲＳ受信処理のシーケンスの一例を示す図である。
【図３０】実施の形態６の通信システムにおけるＳＲＳ受信処理のシーケンスの他の例を示す図である。
【図３１】測定報告値に対するＳＲＳ受信開始閾値とＨＯ開始閾値との違いを示すための図である。
【図３２】実施の形態７の通信システムにおけるアンテナ制御の一例を示す図である。
【発明を実施するための形態】
【００５８】
実施の形態１．
図２は、３ＧＰＰにおいて議論されているＬＴＥ方式の通信システム７００の全体的な構成を示すブロック図である。図２について説明する。無線アクセスネットワークは、Ｅ−ＵＴＲＡＮ（Evolved Universal Terrestrial Radio Access Network）７０と称される。通信端末装置である移動端末装置（以下「移動端末（User Equipment：ＵＥ）」という）７１は、基地局装置（以下「基地局（E-UTRAN NodeB：ｅＮＢ）」という）７２と無線通信可能であり、無線通信で信号の送受信を行う。
【００５９】
移動端末７１に対する制御プロトコル、例えばＲＲＣ（Radio Resource Control）と、ユーザプレイン、例えばＰＤＣＰ（Packet Data Convergence Protocol）、ＲＬＣ（Radio Link Control）、ＭＡＣ（Medium Access Control）、ＰＨＹ（Physical layer）とが基地局７２で終端するならば、Ｅ−ＵＴＲＡＮは１つあるいは複数の基地局７２によって構成される。
【００６０】
移動端末７１と基地局７２との間の制御プロトコルＲＲＣ（Radio Resource Control）は、報知（Broadcast）、ページング（paging）、ＲＲＣ接続マネージメント（RRC connection management）などを行う。ＲＲＣにおける基地局７２と移動端末７１との状態として、ＲＲＣ＿ＩＤＬＥと、ＲＲＣ＿ＣＯＮＮＥＣＴＥＤとがある。
【００６１】
ＲＲＣ＿ＩＤＬＥでは、ＰＬＭＮ（Public Land Mobile Network）選択、システム情報（System Information：ＳＩ）の報知、ページング（paging）、セル再選択（cell re-selection）、モビリティなどが行われる。ＲＲＣ＿ＣＯＮＮＥＣＴＥＤでは、移動端末はＲＲＣ接続（connection）を有し、ネットワークとのデータの送受信を行うことができる。またＲＲＣ＿ＣＯＮＮＥＣＴＥＤでは、ハンドオーバ（Handover：ＨＯ）、隣接セル（Neighbour cell）の測定（メジャメント（measurement））などが行われる。
【００６２】
基地局７２は、ｅＮＢ７６と、Ｈｏｍｅ−ｅＮＢ７５とに分類される。通信システム７００は、複数のｅＮＢ７６を含むｅＮＢ群７２−１と、複数のＨｏｍｅ−ｅＮＢ７５を含むＨｏｍｅ−ｅＮＢ群７２−２とを備える。またコアネットワークであるＥＰＣ（Evolved Packet Core）と、無線アクセスネットワークであるＥ−ＵＴＲＡＮ７０とで構成されるシステムは、ＥＰＳ（Evolved Packet System）と称される。コアネットワークであるＥＰＣと、無線アクセスネットワークであるＥ−ＵＴＲＡＮ７０とを合わせて、「ネットワーク」という場合がある。
【００６３】
ｅＮＢ７６は、移動管理エンティティ（Mobility Management Entity：ＭＭＥ）、あるいはＳ−ＧＷ（Serving Gateway）、あるいはＭＭＥおよびＳ−ＧＷを含むＭＭＥ／Ｓ−ＧＷ部（以下「ＭＭＥ部」という場合がある）７３とＳ１インタフェースにより接続され、ｅＮＢ７６とＭＭＥ部７３との間で制御情報が通信される。一つのｅＮＢ７６に対して、複数のＭＭＥ部７３が接続されてもよい。ｅＮＢ７６間は、Ｘ２インタフェースにより接続され、ｅＮＢ７６間で制御情報が通信される。
【００６４】
Ｈｏｍｅ−ｅＮＢ７５は、ＭＭＥ部７３とＳ１インタフェースにより接続され、Ｈｏｍｅ−ｅＮＢ７５とＭＭＥ部７３との間で制御情報が通信される。一つのＭＭＥ部７３に対して、複数のＨｏｍｅ−ｅＮＢ７５が接続される。あるいは、Ｈｏｍｅ−ｅＮＢ７５は、ＨｅＮＢＧＷ（Home-eNB GateWay）７４を介してＭＭＥ部７３と接続される。Ｈｏｍｅ−ｅＮＢ７５とＨｅＮＢＧＷ７４とは、Ｓ１インタフェースにより接続され、ＨｅＮＢＧＷ７４とＭＭＥ部７３とはＳ１インタフェースを介して接続される。
【００６５】
一つまたは複数のＨｏｍｅ−ｅＮＢ７５が一つのＨｅＮＢＧＷ７４と接続され、Ｓ１インタフェースを通して情報が通信される。ＨｅＮＢＧＷ７４は、一つまたは複数のＭＭＥ部７３と接続され、Ｓ１インタフェースを通して情報が通信される。
【００６６】
ＭＭＥ部７３およびＨｅＮＢＧＷ７４は、上位装置、具体的には上位ノードであり、基地局であるｅＮＢ７６およびＨｏｍｅ−ｅＮＢ７５と、移動端末（ＵＥ）７１との接続を制御する。ＭＭＥ部７３は、コアネットワークであるＥＰＣを構成する。基地局７２およびＨｅＮＢＧＷ７４は、Ｅ−ＵＴＲＡＮ７０を構成する。
【００６７】
さらに３ＧＰＰでは、以下のような構成が検討されている。Ｈｏｍｅ−ｅＮＢ７５間のＸ２インタフェースはサポートされる。すなわち、Ｈｏｍｅ−ｅＮＢ７５間は、Ｘ２インタフェースにより接続され、Ｈｏｍｅ−ｅＮＢ７５間で制御情報が通信される。ＭＭＥ部７３からは、ＨｅＮＢＧＷ７４はＨｏｍｅ−ｅＮＢ７５として見える。Ｈｏｍｅ−ｅＮＢ７５からは、ＨｅＮＢＧＷ７４はＭＭＥ部７３として見える。
【００６８】
Ｈｏｍｅ−ｅＮＢ７５が、ＨｅＮＢＧＷ７４を介してＭＭＥ部７３に接続される場合および直接ＭＭＥ部７３に接続される場合のいずれの場合も、Ｈｏｍｅ−ｅＮＢ７５とＭＭＥ部７３との間のインタフェースは、Ｓ１インタフェースで同じである。
【００６９】
基地局装置７２は、１つのセルを構成してもよいし、複数のセルを構成してもよい。各セルは、通信端末装置と通信可能な範囲であるカバレッジとして予め定める範囲を有し、カバレッジ内で通信端末装置と無線通信を行う。１つの基地局装置が複数のセルを構成する場合、１つ１つのセルが、移動端末と通信可能に構成される。
【００７０】
図３は、本発明に係る移動端末である図２に示す移動端末７１の構成を示すブロック図である。図３に示す移動端末７１の送信処理を説明する。まず、プロトコル処理部８０１からの制御データ、およびアプリケーション部８０２からのユーザデータが、送信データバッファ部８０３へ保存される。送信データバッファ部８０３に保存されたデータは、エンコーダー部８０４へ渡され、誤り訂正などのエンコード処理が施される。エンコード処理を施さずに、送信データバッファ部８０３から変調部８０５へ直接出力されるデータが存在してもよい。エンコーダー部８０４でエンコード処理されたデータは、変調部８０５にて変調処理が行われる。変調されたデータは、ベースバンド信号に変換された後、周波数変換部８０６へ出力され、無線送信周波数に変換される。その後、アンテナ８０７から基地局７２に送信信号が送信される。
【００７１】
また、移動端末７１の受信処理は、以下のように実行される。基地局７２からの無線信号がアンテナ８０７により受信される。受信信号は、周波数変換部８０６にて無線受信周波数からベースバンド信号に変換され、復調部８０８において復調処理が行われる。復調後のデータは、デコーダー部８０９へ渡され、誤り訂正などのデコード処理が行われる。デコードされたデータのうち、制御データはプロトコル処理部８０１へ渡され、ユーザデータはアプリケーション部８０２へ渡される。移動端末７１の一連の処理は、制御部８１０によって制御される。よって制御部８１０は、図３では省略しているが、各部８０１〜８０９と接続している。
【００７２】
図４は、本発明に係る基地局である図２に示す基地局７２の構成を示すブロック図である。図４に示す基地局７２の送信処理を説明する。ＥＰＣ通信部９０１は、基地局７２とＥＰＣ（ＭＭＥ部７３など）、ＨｅＮＢＧＷ７４などとの間のデータの送受信を行う。他基地局通信部９０２は、他の基地局との間のデータの送受信を行う。ＥＰＣ通信部９０１および他基地局通信部９０２は、それぞれプロトコル処理部９０３と情報の受け渡しを行う。プロトコル処理部９０３からの制御データ、ならびにＥＰＣ通信部９０１および他基地局通信部９０２からのユーザデータおよび制御データは、送信データバッファ部９０４へ保存される。
【００７３】
送信データバッファ部９０４に保存されたデータは、エンコーダー部９０５へ渡され、誤り訂正などのエンコード処理が施される。エンコード処理を施さずに、送信データバッファ部９０４から変調部９０６へ直接出力されるデータが存在してもよい。エンコードされたデータは、変調部９０６にて変調処理が行われる。変調されたデータは、ベースバンド信号に変換された後、周波数変換部９０７へ出力され、無線送信周波数に変換される。その後、アンテナ９０８より一つもしくは複数の移動端末７１に対して送信信号が送信される。
【００７４】
また、基地局７２の受信処理は以下のように実行される。一つもしくは複数の移動端末７１からの無線信号が、アンテナ９０８により受信される。受信信号は、周波数変換部９０７にて無線受信周波数からベースバンド信号に変換され、復調部９０９で復調処理が行われる。復調されたデータは、デコーダー部９１０へ渡され、誤り訂正などのデコード処理が行われる。デコードされたデータのうち、制御データはプロトコル処理部９０３あるいはＥＰＣ通信部９０１、他基地局通信部９０２へ渡され、ユーザデータはＥＰＣ通信部９０１および他基地局通信部９０２へ渡される。基地局７２の一連の処理は、制御部９１１によって制御される。よって制御部９１１は、図４では省略しているが、各部９０１〜９１０と接続している。
【００７５】
図５は、本発明に係るＭＭＥの構成を示すブロック図である。図５では、前述の図２に示すＭＭＥ部７３に含まれるＭＭＥ７３ａの構成を示す。ＰＤＮ  ＧＷ通信部１００１は、ＭＭＥ７３ａとＰＤＮ  ＧＷとの間のデータの送受信を行う。基地局通信部１００２は、ＭＭＥ７３ａと基地局７２との間のＳ１インタフェースによるデータの送受信を行う。ＰＤＮ  ＧＷから受信したデータがユーザデータであった場合、ユーザデータは、ＰＤＮ  ＧＷ通信部１００１から、ユーザプレイン通信部１００３経由で基地局通信部１００２に渡され、１つあるいは複数の基地局７２へ送信される。基地局７２から受信したデータがユーザデータであった場合、ユーザデータは、基地局通信部１００２から、ユーザプレイン通信部１００３経由でＰＤＮ  ＧＷ通信部１００１に渡され、ＰＤＮ  ＧＷへ送信される。
【００７６】
ＰＤＮ  ＧＷから受信したデータが制御データであった場合、制御データは、ＰＤＮ  ＧＷ通信部１００１から制御プレイン制御部１００５へ渡される。基地局７２から受信したデータが制御データであった場合、制御データは、基地局通信部１００２から制御プレイン制御部１００５へ渡される。
【００７７】
ＨｅＮＢＧＷ通信部１００４は、ＨｅＮＢＧＷ７４が存在する場合に設けられ、情報種別によって、ＭＭＥ７３ａとＨｅＮＢＧＷ７４との間のインタフェース（ＩＦ）によるデータの送受信を行う。ＨｅＮＢＧＷ通信部１００４から受信した制御データは、ＨｅＮＢＧＷ通信部１００４から制御プレイン制御部１００５へ渡される。制御プレイン制御部１００５での処理の結果は、ＰＤＮ  ＧＷ通信部１００１経由でＰＤＮ  ＧＷへ送信される。また、制御プレイン制御部１００５で処理された結果は、基地局通信部１００２経由でＳ１インタフェースにより１つあるいは複数の基地局７２へ送信され、またＨｅＮＢＧＷ通信部１００４経由で１つあるいは複数のＨｅＮＢＧＷ７４へ送信される。
【００７８】
制御プレイン制御部１００５には、ＮＡＳセキュリティ部１００５−１、ＳＡＥベアラコントロール部１００５−２、アイドルステート（Idle State）モビリティ管理部１００５−３などが含まれ、制御プレインに対する処理全般を行う。ＮＡＳセキュリティ部１００５−１は、ＮＡＳ（Non-Access Stratum）メッセージのセキュリティなどを行う。ＳＡＥベアラコントロール部１００５−２は、ＳＡＥ（System Architecture Evolution）のベアラの管理などを行う。アイドルステートモビリティ管理部１００５−３は、待受け状態（アイドルステート（Idle State）；ＬＴＥ−ＩＤＬＥ状態、または、単にアイドルとも称される）のモビリティ管理、待受け状態時のページング信号の生成および制御、傘下の１つあるいは複数の移動端末７１のトラッキングエリアの追加、削除、更新、検索、トラッキングエリアリスト管理などを行う。
【００７９】
ＭＭＥ７３ａは、１つまたは複数の基地局７２に対して、ページング信号の分配を行う。また、ＭＭＥ７３ａは、待受け状態（Idle State）のモビリティ制御（Mobility control）を行う。ＭＭＥ７３ａは、移動端末が待ち受け状態のとき、および、アクティブ状態（Active State）のときに、トラッキングエリア（Tracking Area）リストの管理を行う。ＭＭＥ７３ａは、ＵＥが登録されている（registered）追跡領域（トラッキングエリア：Tracking Area）に属するセルへ、ページングメッセージを送信することで、ページングプロトコルに着手する。ＭＭＥ７３ａに接続されるＨｏｍｅ−ｅＮＢ７５のＣＳＧの管理やＣＳＧ−ＩＤの管理、そしてホワイトリストの管理は、アイドルステートモビリティ管理部１００５−３で行ってもよい。
【００８０】
次に通信システムにおけるセルサーチ方法の一例を示す。図６は、ＬＴＥ方式の通信システムにおいて移動端末（ＵＥ）が行うセルサーチから待ち受け動作までの概略を示すフローチャートである。移動端末は、セルサーチを開始すると、ステップＳＴ１で、周辺の基地局から送信される第一同期信号（Ｐ−ＳＳ）、および第二同期信号（Ｓ−ＳＳ）を用いて、スロットタイミング、フレームタイミングの同期をとる。
【００８１】
Ｐ−ＳＳとＳ−ＳＳとを合わせて、同期信号（ＳＳ）という。同期信号（ＳＳ）には、セル毎に割り当てられたＰＣＩに１対１に対応するシンクロナイゼーションコードが割り当てられている。ＰＣＩの数は５０４通りが検討されている。この５０４通りのＰＣＩを用いて同期をとるとともに、同期がとれたセルのＰＣＩを検出（特定）する。
【００８２】
次に同期がとれたセルに対して、ステップＳＴ２で、基地局からセル毎に送信される参照信号（リファレンスシグナル：ＲＳ）であるセル固有参照信号（Cell-specific Reference Signal：ＣＲＳ）を検出し、ＲＳの受信電力（Reference Signal Received Power：ＲＳＲＰ）の測定を行う。参照信号（ＲＳ）には、ＰＣＩと１対１に対応したコードが用いられている。そのコードで相関をとることによって他セルと分離できる。ステップＳＴ１で特定したＰＣＩから、該セルのＲＳ用のコードを導出することによって、ＲＳを検出し、ＲＳの受信電力を測定することが可能となる。
【００８３】
次にステップＳＴ３で、ステップＳＴ２までで検出された一つ以上のセルの中から、ＲＳの受信品質が最もよいセル、例えば、ＲＳの受信電力が最も高いセル、つまりベストセルを選択する。
【００８４】
次にステップＳＴ４で、ベストセルのＰＢＣＨを受信して、報知情報であるＢＣＣＨを得る。ＰＢＣＨ上のＢＣＣＨには、セル構成情報が含まれるＭＩＢ（Master Information Block）がマッピングされる。したがってＰＢＣＨを受信してＢＣＣＨを得ることで、ＭＩＢが得られる。ＭＩＢの情報としては、例えば、ＤＬ（ダウンリンク）システム帯域幅（送信帯域幅設定（transmission bandwidth configuration：dl-bandwidth）とも呼ばれる）、送信アンテナ数、ＳＦＮ（System Frame Number）などがある。
【００８５】
次にステップＳＴ５で、ＭＩＢのセル構成情報をもとに該セルのＤＬ−ＳＣＨを受信して、報知情報ＢＣＣＨの中のＳＩＢ（System Information Block）１を得る。ＳＩＢ１には、該セルへのアクセスに関する情報や、セルセレクションに関する情報、他のＳＩＢ（ＳＩＢｋ；ｋ≧２の整数）のスケジューリング情報が含まれる。また、ＳＩＢ１には、トラッキングエリアコード（Tracking Area Code：ＴＡＣ）が含まれる。
【００８６】
次にステップＳＴ６で、移動端末は、ステップＳＴ５で受信したＳＩＢ１のＴＡＣと、移動端末が既に保有しているトラッキングエリアリスト内のトラッキングエリア識別子（Tracking Area Identity：ＴＡＩ）のＴＡＣ部分とを比較する。トラッキングエリアリストは、ＴＡＩリスト（TAI list）とも称される。ＴＡＩはトラッキングエリアを識別するための識別情報であり、ＭＣＣ（Mobile Country Code）と、ＭＮＣ（Mobile Network Code）と、ＴＡＣ（Tracking Area Code）とによって構成される。ＭＣＣは国コードである。ＭＮＣはネットワークコードである。ＴＡＣはトラッキングエリアのコード番号である。
【００８７】
移動端末は、ステップＳＴ６で比較した結果、ステップＳＴ５で受信したＴＡＣがトラッキングエリアリスト内に含まれるＴＡＣと同じならば、該セルで待ち受け動作に入る。比較して、ステップＳＴ５で受信したＴＡＣがトラッキングエリアリスト内に含まれなければ、移動端末は、該セルを通して、ＭＭＥなどが含まれるコアネットワーク（Core Network，ＥＰＣ）へ、ＴＡＵ（Tracking Area Update）を行うためにトラッキングエリアの変更を要求する。
【００８８】
コアネットワークを構成する装置（以下「コアネットワーク側装置」という場合がある）は、ＴＡＵ要求信号とともに移動端末から送られてくる該移動端末の識別番号（ＵＥ−ＩＤなど）をもとに、トラッキングエリアリストの更新を行う。コアネットワーク側装置は、移動端末に更新後のトラッキングエリアリストを送信する。移動端末は、受信したトラッキングエリアリストに基づいて、移動端末が保有するＴＡＣリストを書き換える（更新する）。その後、移動端末は、該セルで待ち受け動作に入る。
【００８９】
スマートフォンおよびタブレット端末の普及によって、セルラー系無線通信によるトラフィックが爆発的に増大しており、世界中で無線リソースの不足が懸念されている。これに対応して周波数利用効率を高めるために、小セル化し、空間分離を進めることが検討されている。
【００９０】
従来のセルの構成では、ｅＮＢによって構成されるセルは、比較的広い範囲のカバレッジを有する。従来は、複数のｅＮＢによって構成される複数のセルの比較的広い範囲のカバレッジによって、あるエリアを覆うように、セルが構成されている。
【００９１】
小セル化された場合、ｅＮＢによって構成されるセルは、従来のｅＮＢによって構成されるセルのカバレッジに比べて範囲が狭いカバレッジを有する。したがって、従来と同様に、あるエリアを覆うためには、従来のｅＮＢに比べて、多数の小セル化されたｅＮＢが必要となる。
【００９２】
以下の説明では、従来のｅＮＢによって構成されるセルのように、比較的広い範囲のカバレッジを構成するセル、すなわちカバレッジエリアが比較的広いセルを「マクロセル」といい、マクロセルを構成するｅＮＢを「マクロｅＮＢ」という。また、小セル化されたセルのように、比較的狭い範囲のカバレッジを構成するセル、すなわちカバレッジエリアが比較的狭いセルを「スモールセル」といい、スモールセルを構成するｅＮＢを「スモールｅＮＢ」という。
【００９３】
マクロｅＮＢは、例えば、非特許文献８に記載される「ワイドエリア基地局（Wide Area Base Station）」であってもよい。
【００９４】
スモールｅＮＢは、例えば、ローパワーノード、ローカルエリアノード、ホットスポットなどであってもよい。また、スモールｅＮＢは、ピコセルを構成するピコｅＮＢ、フェムトセルを構成するフェムトｅＮＢ、ＨｅＮＢ、ＲＲＨ（Remote Radio Head）、ＲＲＵ（Remote Radio Unit）、ＲＲＥ（Remote Radio Equipment）またはＲＮ（Relay Node）であってもよい。また、スモールｅＮＢは、非特許文献８に記載される「ローカルエリア基地局（Local Area Base Station）」または「ホーム基地局（Home Base Station）」であってもよい。
【００９５】
図７は、マクロｅＮＢとスモールｅＮＢとが混在する場合のセルの構成の概念を示す図である。マクロｅＮＢによって構成されるマクロセルは、比較的広い範囲のカバレッジ１３０１を有する。スモールｅＮＢによって構成されるスモールセルは、マクロｅＮＢ（マクロセル）のカバレッジ１３０１に比べて範囲が狭いカバレッジ１３０２を有する。
【００９６】
複数のｅＮＢが混在する場合、あるｅＮＢによって構成されるセルのカバレッジが、他のｅＮＢによって構成されるセルのカバレッジ内に含まれる場合がある。図７に示すセルの構成では、参照符号「１３０４」または「１３０５」で示されるように、スモールｅＮＢによって構成されるスモールセルのカバレッジ１３０２が、マクロｅＮＢによって構成されるマクロセルのカバレッジ１３０１内に含まれる場合がある。
【００９７】
また、参照符号「１３０５」で示されるように、複数、例えば２つのスモールセルのカバレッジ１３０２が、１つのマクロセルのカバレッジ１３０１内に含まれる場合もある。移動端末（ＵＥ）１３０３は、例えばスモールセルのカバレッジ１３０２内に含まれ、スモールセルを介して通信を行う。
【００９８】
また図７に示すセルの構成では、参照符号「１３０６」で示されるように、マクロｅＮＢによって構成されるマクロセルのカバレッジ１３０１と、スモールｅＮＢによって構成されるスモールセルのカバレッジ１３０２とが複雑に重複する場合が生じる。
【００９９】
また、参照符号「１３０７」で示されるように、マクロｅＮＢによって構成されるマクロセルのカバレッジ１３０１と、スモールｅＮＢによって構成されるスモールセルのカバレッジ１３０２とが重複しない場合も生じる。
【０１００】
さらには、参照符号「１３０８」で示されるように、多数のスモールｅＮＢによって構成される多数のスモールセルのカバレッジ１３０２が、一つのマクロｅＮＢによって構成される１つのマクロセルのカバレッジ１３０１内に構成される場合も生じる。
【０１０１】
スモールセルの運用において、マクロセルのカバレッジ内でトラフィックの多いエリアにスモールセルを構成する、すなわちマクロセルにスモールセルを重ねて配置（オーバレイ）することによって、スループットを向上させることが検討されている。
【０１０２】
図８は、マクロセルとスモールセルとがオーバレイされる場合のセルの構成の一例を示す図である。図８では、図７と同様に、マクロセルのカバレッジを参照符号「１３０１」で示し、スモールセルのカバレッジを参照符号「１３０２」で示す。
【０１０３】
３ＧＰＰでは、図８に示すようなセルの構成において、ＵＥがマクロセルとスモールセルとの両方に接続する、デュアルコネクティビティ（Dual connectivity；略称：ＤＣ）の議論が行われている（非特許文献９参照）。ＤＣを行うＵＥに対する制御プレイン（C-plane）では、ＳｅＮＢ（Secondary eNB）は、ＭｅＮＢ（Master eNB）を介してＭＭＥに接続される。
【０１０４】
ＤＣを行うＵＥに対して、ユーザプレイン（U-plane）では、主に二つのアーキテクチャが検討されている。一つは、ＳｅＮＢが直接Ｓ−ＧＷに接続されるアーキテクチャ（以下「アーキテクチャ１Ａ」という場合がある）である。他の一つは、ＳｅＮＢがＭｅＮＢを介してＳ−ＧＷに接続されるアーキテクチャ（以下「アーキテクチャ３Ｃ」という場合がある）である。
【０１０５】
ここで、ＭｅＮＢは、ＤＣにおけるマクロセルを構成するｅＮＢである。ＳｅＮＢは、ＤＣにおけるスモールセルを構成するｅＮＢである。また、ＭｅＮＢが構成するセルグル―プを「ＭＣＧ」と称し、ＳｅＮＢが構成するセルグループを「ＳＣＧ」と称する。ＭＣＧ内のセルを「ＭＣＧセル」と称し、ＳＣＧ内のセルを「ＳＣＧセル」と称する。ＭＣＧ内でＰＵＣＣＨを送信するセルを「ＰＣｅｌｌ」と称する。ＳＣＧ内でＰＵＣＣＨを送信する特別なセルを「ＳＰＣｅｌｌ」と称する。ＳＰＣｅｌｌは、ＰＣｅｌｌの一部の機能を有する。
【０１０６】
実施の形態１で解決する課題、およびその解決策について、以下に示す。ＰＷＳ（Public Warning System）は、特定のエリアに存在するＵＥに対して警報（Warning）メッセージを通知するシステムである（非特許文献１０参照）。ＰＷＳとしては、ＥＴＷＳ（Earthquake and Tsunami Warning System），ＣＭＡＳ（Commercial Mobile Alert System），ＥＵ−ＡＬＥＲＴ（European Public Warning System），ＫＰＡＳ（Korean Public Alert System）などがある。
【０１０７】
ＰＷＳでは、通知するメッセージの重要性から、ＲＲＣ＿ＩＤＬＥのＵＥだけでなく、ＲＲＣ＿ＣＯＮＮＥＣＴＥＤのＵＥに対してもサポートされている。また、ＰＷＳにおけるメッセージ（以下「ＰＷＳメッセージ」という場合がある）は、ＭＭＥからｅＮＢに対して、制御プレイン（C-Plane）のインタフェースであるＳ１−ＭＭＥを介して通知される。ＰＷＳメッセージは、上位装置からスモールセルに向けたスモールセル向け情報に相当する。上位装置は、例えば、後述するＣＢＥ（Cell Broadcast Entity）、ＣＢＣ（Cell Broadcast Centre）およびＭＭＥである。
【０１０８】
３ＧＰＰで検討されているＤＣでは、ＤＣ中のＵＥの制御プレイン（C-Plane）において、ＳｅＮＢは、ＭＭＥと直接は接続されない。したがって、前述のＰＷＳをＤＣに適用した場合、ＳｅＮＢを用いてＤＣを行っているＵＥは、該ＳｅＮＢ向けのＰＷＳメッセージの通知対象にならず、該ＵＥは、ＳｅＮＢ向けのＰＷＳメッセージを受信することはできない。
【０１０９】
３ＧＰＰにおいては、ＤＣにおけるＰＷＳの取扱いについては、ＤＣ中のＵＥは、ＭｅＮＢ向けのＰＷＳメッセージを受信することのみが検討されており、ＳｅＮＢ向けのＰＷＳメッセージの受信方法については、何ら議論されていない（非特許文献１１，１２参照）。
【０１１０】
ＰＷＳは、特定のエリアを対象とするので、たとえＳｅＮＢとＭｅＮＢとがオーバレイして構成されていたとしても、ＳｅＮＢ向けのＰＷＳメッセージとＭｅＮＢ向けのＰＷＳメッセージとは異なる場合がある。したがって、ＳｅＮＢのカバレッジ内に存在するＵＥが、該ＳｅＮＢ向けのＰＷＳメッセージを受信することができるようにすることは、該ＵＥにとって有効である。
【０１１１】
実施の形態１では、ＳｅＮＢを用いてＤＣを行っているＵＥが、該ＳｅＮＢ向けのＰＷＳメッセージを受信することを可能とする方法を開示する。
【０１１２】
実施の形態１における解決策を以下に示す。ＳｅＮＢは、ＤＣ中のＵＥに対して、自ＳｅＮＢ向けのＰＷＳメッセージを送信する。ＳｅＮＢを用いてＤＣを行っているＵＥは、該ＳｅＮＢ向けのＰＷＳメッセージを受信する。
【０１１３】
ＰＷＳメッセージが、特定の一つまたは複数のＳＣＧセルに通知される場合は、ＤＣに用いられているＳｅＮＢは、自ＳＣＧセルを用いてＤＣを行っているＵＥに対して、自ＳＣＧセル向けのＰＷＳメッセージを送信する。ＳＣＧセルを用いてＤＣを行っているＵＥは、該ＳＣＧセル向けのＰＷＳメッセージを受信する。
【０１１４】
ＰＷＳメッセージの通知方法について説明する。図９は、実施の形態１の通信システムにおけるＰＷＳメッセージの流れの一例を示す図である。図９では、ＰＷＳメッセージの流れを、太線の矢符１０６，１０７，１０８で示している。
【０１１５】
ＰＷＳメッセージは、不図示のＣＢＥ（Cell Broadcast Entity）からＣＢＣ（Cell Broadcast Centre）１０１に通知される。ＣＢＣ１０１は、ＣＢＥから通知されたＰＷＳメッセージを、矢符１０６で示すように、ＭＭＥ１０２に通知する。
【０１１６】
ＭＭＥ１０２は、ＣＢＣ１０１から通知されたＰＷＳメッセージを、ｅＮＢに通知する。具体的には、ＭＭＥ１０２は、ＰＷＳメッセージを、矢符１０７で示すように、ＳｅＮＢ１０４に通知する。またＭＭＥ１０２は、ＰＷＳメッセージをＭｅＮＢ１０３に通知する。ｅＮＢは、自セルがＤＣに用いられている場合、すなわち、ＳｅＮＢ１０４である場合、ＭＭＥ１０２から通知されたＰＷＳメッセージを、矢符１０８で示すように、自セルを用いてＤＣを行っているＵＥ１０５に通知する。
【０１１７】
ＭＭＥ１０２とＭｅＮＢ１０３とは、インタフェース１１１によって接続される。ＭＭＥ１０２とＭｅＮＢ１０３との間のインタフェース１１１には、Ｓ１インタフェースが用いられる。ここでは、ＤＣ中のＵＥ１０５に対するインタフェースを示している。
【０１１８】
ＭｅＮＢ１０３とＳｅＮＢ１０４とは、インタフェース１１２によって接続される。ＭｅＮＢ１０３とＳｅＮＢ１０４との間のインタフェース１１２には、Ｘ２またはＸｎインタフェースが用いられる。ここでは、ＤＣ中のＵＥ１０５に対するインタフェースを示している。
【０１１９】
ＳｅＮＢ１０４が、自セルを用いてＤＣを行っているＵＥ１０５にＰＷＳメッセージを通知するために、ＳＣＧセルは、ＰＷＳメッセージをＳＩＢに含めて報知するとよい。
【０１２０】
ＰＷＳメッセージを含めるＳＩＢ（以下「ＰＷＳメッセージ用ＳＩＢ」という場合がある）としては、新たなＳＩＢを設けてもよいし、既存のＳＩＢを用いてもよい。既存のＰＷＳメッセージを含むＳＩＢとしては、例えば、ＥＴＷＳ用として、ＳＩＢ１０、ＳＩＢ１１があり、ＣＭＡＳ用として、ＳＩＢ１２がある。
【０１２１】
ＳＣＧセルが、ＰＷＳメッセージを、ＤＣ中のＵＥに通知する方法は、ＳＣＧセルが傘下のＵＥにＰＷＳメッセージを報知する方法を適用することができる。ＳＣＧセルは、傘下のＵＥに対して、ＰＷＳメッセージを通知しなくてはならない。該通知は報知によって行われる。
【０１２２】
したがって、ＳＣＧセルが、傘下のＵＥにＰＷＳメッセージを報知する方法を用いて、自セルを用いてＤＣを行っているＵＥに対してもＰＷＳメッセージを通知することによって、新たな処理を加えなくて済む。これによって、ＳｅＮＢの機能が複雑になることを防ぎ、誤動作を低減させることができる。
【０１２３】
ＳＣＧセルを用いてＤＣを行っているＵＥは、ＳＣＧセルから報知されるＰＷＳメッセージ用ＳＩＢを受信する。ＰＷＳメッセージはＰＷＳメッセージ用ＳＩＢに含めて報知されるので、ＵＥは、ＰＷＳメッセージ用ＳＩＢを受信することによって、ＰＷＳメッセージ用ＳＩＢ中のＰＷＳメッセージを受信する。
【０１２４】
ＰＷＳメッセージが報知されたことを、ＤＣ中のＵＥに示すために、ＰＷＳインジケーション（PWS indication）を設けるとよい。ＰＷＳインジケーションは、スモールセル向け情報が報知されたことを示す報知指示情報に相当する。ＰＷＳインジケーションは、ＰＷＳメッセージに先立って、ＤＣ中のＵＥに通知される。ＤＣ中のＵＥは、ＰＷＳインジケーションを受信すると、ＳＣＧセルのＰＷＳメッセージが含まれるＳＩＢを受信する。図９では、ＰＷＳインジケーションの流れを、矢符１０９，１１０で示している。
【０１２５】
ＳｅＮＢ１０４は、ＭＭＥ１０２から、自ＳｅＮＢ向けのＰＷＳメッセージを受信した場合、ＵＥ１０５に対してＰＷＳインジケーションを通知する。ＰＷＳインジケーションの通知方法の具体例として、以下の（１），（２）の２つを開示する。
【０１２６】
（１）ＳｅＮＢ１０４から、矢符１１０で示すように直接、ＤＣ中のＵＥ１０５に通知する。
【０１２７】
（２）ＳｅＮＢ１０４から、矢符１０９で示すように、ＭｅＮＢ１０３を介して、ＤＣ中のＵＥ１０５に通知する。
【０１２８】
ＰＷＳインジケーションの通知方法として、前記（１）の通知方法を適用する場合について説明する。ＭＭＥ１０２からＰＷＳメッセージを受信したＳｅＮＢ１０４は、ＰＷＳメッセージを送信するＳＣＧセルを特定する。ＳＣＧセルは、ＰＷＳインジケーションをページング（Paging）メッセージに含めて、傘下のＵＥに通知する。ＳＣＧセルは、ＤＣ中のＵＥに対しても、ＰＷＳインジケーションをページングメッセージに含めて通知する。また、ＳＣＧセルは、ＰＷＳメッセージを報知する。
【０１２９】
ＳＣＧセルを用いてＤＣを行っているＵＥは、ＳＣＧセルからのページングメッセージを受信し、ページングメッセージ内のＰＷＳインジケーションを受信する。
【０１３０】
ＰＷＳインジケーションとしては、新たなインジケーションを設けてもよいし、既存のインジケーションを用いてもよい。既存のインジケーションとしては、例えば、ＥＴＷＳ用として、ＥＴＷＳインジケーション（ETWS indication）があり、ＣＭＡＳ用として、ＣＭＡＳインジケーション（CMAS indication）がある。
【０１３１】
ＳＣＧセルを用いてＤＣを行っているＵＥは、ページングメッセージ内のＰＷＳインジケーションを受信すると、ＳＣＧセルのＰＷＳメッセージが含まれるＳＩＢを受信する。
【０１３２】
ＰＷＳメッセージが含まれるＳＩＢは、予め静的に決められておくとよい。また、ＰＷＳメッセージが含まれるＳＩＢは、規格で決められておいてもよい。
【０１３３】
ＳＣＧセルを用いてＤＣを行っているＵＥは、ＰＷＳメッセージが含まれるＳＩＢを受信するために、スケジューリング情報が含まれるＳＩＢ（ＳＩＢ１）を受信する。ＳＣＧセルのＳＩＢ１を受信したＤＣ中のＵＥは、スケジューリング情報を用いて、ＰＷＳメッセージが含まれるＳＩＢを受信する。
【０１３４】
図１０は、実施の形態１の通信システムにおけるＰＷＳメッセージ通知処理のシーケンスの一例を示す図である。図１０では、ＰＷＳインジケーションの通知方法として、前述の（１）の通知方法を適用した場合の例を示している。
【０１３５】
ステップＳＴ１００１において、ＵＥ、ＭｅＮＢおよびＭＭＥは、登録処理（Registration Procedure）を行う。登録処理では、具体的には、ＵＥが、ＭｅＮＢを介して、ＭＭＥに対して登録（registration）を行う。登録処理完了後、ＵＥは、ＭｅＮＢとＲＲＣ＿ＣＯＮＮＥＣＴＥＤ状態に移行する。
【０１３６】
ステップＳＴ１００２において、ＭｅＮＢは、ＵＥに対して、ＤＣを実行するために、ＳｅＮＢの追加処理（以下「ＳｅＮＢ追加処理」という場合がある）を起動する。これによって、ＭｅＮＢ、ＵＥ、およびＳｅＮＢの間で、ＳｅＮＢ追加処理（SeNB Addition Procedure）が行われる。ＳｅＮＢ追加処理の具体的な内容については、例えば、非特許文献９に開示される。ＳｅＮＢ追加処理において、ＵＥは、追加するＳＣＧセルと同期をとる。
【０１３７】
ＳｅＮＢ追加処理を行い、追加するＳＣＧセルと同期をとったＵＥは、ステップＳＴ１００３において、ＳＣＧセルのページングメッセージがマッピングされるＰＣＨを受信する。本実施の形態では、ＵＥは、ＳＣＧセルのページングメッセージがマッピングされるＰＣＨを間欠受信する。
【０１３８】
ＵＥは、ＳＣＧセルのＰＣＨ送信タイミングに関する情報を、ＳｅＮＢから、ＭｅＮＢを介して受信しておくとよい。ＳｅＮＢは、ＭｅＮＢに対して、ＳＣＧセルのＰＣＨ送信タイミングに関する情報を通知する。ＭｅＮＢは、ＵＥに対して、ＳＣＧセルのＰＣＨ送信タイミングに関する情報を通知する。これらの通知は、ステップＳＴ１００２のＳｅＮＢ追加処理において行われるとよい。ＰＣＨ送信タイミングに関する情報としては、ＤＲＸ周期などがある。
【０１３９】
また、ＳｅＮＢは、予めＵＥの識別子を認識しておく。ＭｅＮＢは、ＤＣを実行するＵＥの識別子をＳｅＮＢに対して通知するとよい。この通知は、ステップＳＴ１００２のＳｅＮＢ追加処理において行われるとよい。
【０１４０】
ＵＥの識別子としては、ＩＭＳＩ（International Mobile Subscriber Identity）を用いるとよい。ＤＣを実行するＵＥのＩＭＳＩを、ＳｅＮＢが受信することによって、従来の傘下のＵＥに対するＰＣＨ送信タイミング導出方法と同様にして、ＵＥへのＰＣＨ送信タイミングを導出することが可能となる。また、ＤＣ中のＵＥも、自ＩＭＳＩに基づいて、従来の導出方法から、ＳＣＧセルからのＰＣＨ送信タイミングを導出することが可能となる。
【０１４１】
ステップＳＴ１００４において、ＣＢＣ（Cell Broadcast Centre）は、不図示のＣＢＥ（Cell Broadcast Entity）からＰＷＳメッセージを受信する。具体的には、ＣＢＣは、ＰＷＳメッセージとして、緊急報知要求（Emergency Broadcast Request）メッセージを受信する。
【０１４２】
ＣＢＥからＰＷＳメッセージを受信したＣＢＣは、ステップＳＴ１００５において、ＭＭＥに対して、ＳＢｃインタフェースによって、ＰＷＳメッセージを通知する。
【０１４３】
ステップＳＴ１００５において、ＣＢＣは、ＰＷＳメッセージとともに、トラッキングエリアＩＤリスト（tracking area ID list）、警報エリア（warning area）情報、グローバルｅＮＢ  ＩＤ（Global eNB ID）をＭＭＥに通知する。また、ＰＷＳメッセージ固有の識別子を通知してもよい。警報エリア（warning area）情報は、セル識別子のリスト、またはトラッキングエリア識別子のリスト、または緊急エリア（Emergency Area）識別子からなる。
【０１４４】
ＰＷＳメッセージ、トラッキングエリアＩＤリスト、警報エリア情報、およびグローバルｅＮＢ  ＩＤの通知用のメッセージとしては、「Write-Replace Warning Request」メッセージが用いられる。すなわち、ＣＢＣは、ステップＳＴ１００５において、「Write-Replace Warning Request」メッセージをＭＭＥに通知することによって、ＰＷＳメッセージ、トラッキングエリアＩＤリスト、警報エリア情報、およびグローバルｅＮＢ  ＩＤをＭＭＥに通知する。
【０１４５】
ＰＷＳメッセージを受信したＭＭＥは、トラッキングエリアＩＤリスト（tracking area ID list）から、ＰＷＳメッセージを通知するｅＮＢを特定する。ここでは、ＳｅＮＢがトラッキングエリアＩＤリストに含まれている場合について示している。
【０１４６】
また、ＰＷＳメッセージを受信したＭＭＥは、ステップＳＴ１００６において、ＣＢＣに対して、ＰＷＳメッセージ受信確認メッセージを通知する。ＰＷＳメッセージ受信確認メッセージの通知用のメッセージとしては、「Write-Replace Warning Confirm」メッセージを用いる。
【０１４７】
ＰＷＳメッセージ受信確認メッセージを受信したＣＢＣは、ステップＳＴ１００７において、ＣＢＥに対して、ＰＷＳメッセージ受信応答メッセージを通知する。具体的には、ＣＢＣは、ＰＷＳメッセージ受信応答メッセージとして、緊急報知応答（Emergency Broadcast Response）メッセージを通知する。
【０１４８】
ＭＭＥは、ステップＳＴ１００６におけるＰＷＳメッセージ受信確認メッセージの通知を、後述のステップＳＴ１００８において「Write-Replace Warning Request」メッセージを送信した後で行ってもよいし、ステップＳＴ１０１２において「Write-Replace Warning Response」メッセージを受信した後で行ってもよい。ｅＮＢにＰＷＳメッセージを通知してから、あるいはｅＮＢからＰＷＳメッセージ通知に対する応答を受信してから行うようにしてもよい。
【０１４９】
ステップＳＴ１００８において、ＭＭＥは、ＳｅＮＢに対して、Ｓ１−ＭＭＥインタフェースによって、ＰＷＳメッセージを通知する。ステップＳＴ１００８において、ＭＭＥは、ＰＷＳメッセージとともに、警報エリア（warning area）情報をＳｅＮＢに通知する。また、ＰＷＳメッセージ固有の識別子を通知してもよい。ＰＷＳメッセージおよび警報エリア情報の通知用のメッセージとしては、「Write-Replace Warning Request」メッセージが用いられる。
【０１５０】
ＰＷＳメッセージを受信したＳｅＮＢは、警報エリア（warning area）情報を用いて、自ＳｅＮＢ向けのＰＷＳメッセージか否かを確認する。また、ＳｅＮＢは、自ＳｅＮＢ向けのＰＷＳメッセージである場合、警報エリア（warning area）情報を用いて、ＰＷＳメッセージを送信するＳＣＧセルを特定する。
【０１５１】
ステップＳＴ１００９において、ＳｅＮＢは、特定されたＳＣＧセルから、ＰＷＳインジケーション（PWS indication）を含めたページングメッセージを、傘下のＵＥに通知する。またＳｅＮＢは、ＤＣ中のＵＥに対しても、ＰＷＳインジケーション（PWS indication）を含めたページングメッセージを通知する。ＤＣ中のＵＥへのページングメッセージの送信タイミングは、ステップＳＴ１００２のＳｅＮＢ追加処理で取得したＵＥのＩＭＳＩを用いて決定する。
【０１５２】
ステップＳＴ１００３でＰＣＨを受信しているＵＥは、ステップＳＴ１００９において、ＳＣＧセルからＰＣＨにマッピングされたページングメッセージを受信し、ＰＷＳインジケーションを受信する。
【０１５３】
ＰＷＳインジケーションを受信したＵＥは、ステップＳＴ１０１０において、ＳＣＧセルから報知されるＳＩＢ１を受信して、ＰＷＳメッセージが含まれるＳＩＢのスケジューリング情報を受信する。そして、ＵＥは、スケジューリング情報に従って、ステップＳＴ１０１１において、ＰＷＳメッセージが含まれるＳＩＢを受信し、ＰＷＳメッセージを受信する。
【０１５４】
緊急性を要するＰＷＳメッセージ、例えばＥＴＷＳなどの場合は、ＵＥは、ＰＷＳインジケーションを受信した後、直ちにＰＷＳメッセージを受信するようにしてもよい。
【０１５５】
ステップＳＴ１０１２において、ＳｅＮＢは、ＭＭＥに対して、「Write-Replace Warning Response」メッセージを通知し、ＰＷＳメッセージ通知処理の処理手順を終了する。
【０１５６】
以上の図１０に示すようなＰＷＳメッセージ通知処理を行うことによって、ＳｅＮＢを用いてＤＣを行っているＵＥが、ＳｅＮＢ向けのＰＷＳメッセージを受信することが可能となる。
【０１５７】
また、ＰＷＳインジケーションの通知方法を、前述の（１）の通知方法とすることによって、従来のＰＷＳインジケーションを通知する方法と同様にしてＰＷＳインジケーションを通知することが可能となるので、ＳｅＮＢにおける処理が複雑になることを抑制することができる。
【０１５８】
ＤＣに用いられるＳＣＧセルが複数存在する場合、ＤＣ中のＵＥは、複数のＳＣＧセルのＰＣＨを受信する必要が生じる。この場合、ＤＣ中のＵＥは、ＰＣＨの受信処理が増大し、消費電力が増大してしまう。これを避けるために、ＰＷＳインジケーションが通知されるのは、ＳＰＣｅｌｌのみに限定してもよい。また、ＰＷＳメッセージが通知されるのも、ＳＰＣｅｌｌのみに限定してもよい。このようにすることによって、ＤＣ中のＵＥの消費電力の増大を防ぐことが可能となる。
【０１５９】
また、ＳｅＮＢが、ＭＭＥからＰＷＳメッセージを受信した場合、ＳｅＮＢを用いてＤＣを行っているＵＥがＳＰＣｅｌｌとしているＳＣＧセルが、該ＵＥに対してＰＷＳインジケーションを送信するようにしてもよい。ＳＰＣｅｌｌは、該ＵＥに対して、ＰＷＳインジケーションとともに、どのＳＣＧセル向けＰＷＳメッセージが発生したかを示す情報を送信するとよい。これによって、ＳｅＮＢを用いてＤＣを行っているＵＥは、少なくともＳＰＣｅｌｌのＰＣＨのみを受信すればよくなる。また、ＰＷＳメッセージを、ＳｅＮＢを用いてＤＣを行っているＵＥがＳＰＣｅｌｌとしているＳＣＧセルが送信するようにしてもよい。これによって、ＳｅＮＢを用いてＤＣを行っているＵＥは、ＳＰＣｅｌｌのみからＰＷＳメッセージを受信すればよくなる。したがって、ＤＣ中のＵＥの消費電力の増大を防ぐことが可能となる。
【０１６０】
ＰＷＳインジケーションの通知方法として、前記（２）の通知方法を適用する場合について、前述の図９を用いて説明する。ＭＭＥ１０２からＰＷＳメッセージを受信したＳｅＮＢ１０４は、自ＳＣＧセルを用いてＤＣを行っているＵＥ１０５に対して、ＭｅＮＢ１０３を介して、ＰＷＳインジケーションを通知する。
【０１６１】
さらに具体的に述べると、ＳｅＮＢ１０４は、ＰＷＳメッセージを送信するＳＣＧセルを特定し、該ＳＣＧセルを用いてＤＣを行っているＵＥ１０５に対して、矢符１０９で示すように、ＭｅＮＢ１０３を介して、ＰＷＳインジケーションを通知する。
【０１６２】
ＳＣＧセルを用いてＤＣを行っているＵＥ１０５は、ＭｅＮＢ１０３から送信されるＰＷＳインジケーションを受信すると、ＳＣＧセルのＰＷＳメッセージが含まれるＳＩＢを受信する。
【０１６３】
図１１は、実施の形態１の通信システムにおけるＰＷＳメッセージ通知処理のシーケンスの他の例を示す図である。図１１では、ＰＷＳインジケーションの通知方法として、前述の（２）の通知方法を適用した場合の例を示している。図１１に示すシーケンスは、図１０に示すシーケンスと類似しているので、同一のステップについては同一のステップ番号を付して、共通する説明を省略する。
【０１６４】
まず、前述の図１０に示す場合と同様にして、ステップＳＴ１００１〜ステップＳＴ１００２、ステップＳＴ１００４〜ステップＳＴ１００８の処理が行われる。ステップＳＴ１００８においてＰＷＳメッセージを受信したＳｅＮＢは、警報エリア（warning area）情報を用いて、自ＳｅＮＢ向けのＰＷＳメッセージか否かを確認する。ＳｅＮＢは、自ＳｅＮＢ向けのＰＷＳメッセージである場合、警報エリア（warning area）情報を用いて、ＰＷＳメッセージを送信するＳＣＧセルを特定する。
【０１６５】
ステップＳＴ１１０１において、ＳｅＮＢは、特定されたＳＣＧセルを用いてＤＣを行っているＭｅＮＢに対して、ＰＷＳインジケーション（PWS indication）を通知する。ＰＷＳインジケーションは、Ｘ２インタフェースを用いて通知する。あるいは、ＤＣのためにＭｅＮＢとＳｅＮＢとの間に、新たにＸｎインタフェースが設けられる場合、Ｘｎインタフェースを用いて通知してもよい。Ｘ２メッセージとして新たなメッセージを設けてそれに含めて通知してもよい。あるいは、ＳＣＧセルの設定変更のためのメッセージに含めて通知してもよい。また、Ｘ２メッセージ中あるいはＸｎメッセージ中に、ＲＲＣメッセージのコンテナを設け、該コンテナ内に含めて通知してもよい。これらのメッセージは、個別シグナリングで通知されるとよい。
【０１６６】
ステップＳＴ１１０１において、ＳｅＮＢは、ＰＷＳインジケーションとともに、ＳｅＮＢの識別子、または、特定したＳＣＧセルの識別子をＭｅＮＢに通知しておく。または、特定したＳＣＧセルとＤＣ中のＵＥ識別子を認識している場合は、ＳｅＮＢは、該ＤＣ中のＵＥの識別子を通知してもよい。ＳｅＮＢが、ＳＣＧセルとＤＣ中のＵＥ識別子を認識する方法として、ステップＳＴ１００２のＳｅＮＢ追加処理において、ＭｅＮＢからＳｅＮＢに対して、ＳＣＧセルとＤＣ中のＵＥ識別子を通知しておくとよい。
【０１６７】
ステップＳＴ１１０１において、ＳｅＮＢから、ＤＣ中のＵＥに対するＰＷＳインジケーションを受信したＭｅＮＢは、ステップＳＴ１１０２において、ＳｅＮＢを用いてＤＣを行っているＵＥに対して、ＰＷＳインジケーション（PWS indication）を通知する。ＰＷＳインジケーションの通知には、ＲＲＣメッセージを用いるとよい。ＲＲＣメッセージは、個別シグナリングで通知するとよい。
【０１６８】
ステップＳＴ１１０２において、ＭｅＮＢは、ＳｅＮＢを用いてＤＣを行っているＵＥに対して、ＰＷＳインジケーションとともに、ＰＷＳメッセージを送信するＳＣＧセルの識別子を通知してもよい。
【０１６９】
ＭｅＮＢが、ＳｅＮＢからＲＲＣメッセージのコンテナでＰＷＳインジケーションを通知された場合は、ＲＲＣメッセージに乗せ換え、該コンテナをＤＣ中のＵＥに個別に通知するとよい。
【０１７０】
ステップＳＴ１１０１において、ＳｅＮＢから、ＤＣ中のＵＥに対するＰＷＳインジケーションを受信したＭｅＮＢは、特定したＳＣＧセルの識別子または特定したＳＣＧセルとＤＣ中のＵＥ識別子を用いて、特定したＳＣＧセルとＤＣ中のＵＥに対してのみＰＷＳインジケーションを通知するようしてもよい。ＰＷＳインジケーションとともに、特定したＳＣＧセルの識別子の通知が不要となる。また、ＰＷＳメッセージを送信しないＳＣＧセルとＤＣを行っているＵＥに対して、ＰＷＳインジケーションを通知する必要がなくなる。これによって、シグナリング負荷の削減および制御の簡易化を図ることができる。
【０１７１】
ステップＳＴ１１０１において、ＳｅＮＢが特定されたＳＣＧセルを用いてＤＣを行っているＭｅＮＢに対してＰＷＳインジケーションを通知することを開示したが、ＳｅＮＢは、自セルを用いてＤＣを行うことが可能なｅＮＢ、あるいは、周辺のｅＮＢに対して、ＰＷＳインジケーションを通知してもよい。この場合、ＳｅＮＢは、ＰＷＳインジケーションとともに自ＳｅＮＢの識別子または特定したＳＣＧセルの識別子を通知する。ＰＷＳインジケーションを通知されたｅＮＢは、ＳｅＮＢの識別子または特定したＳＣＧセルの識別子を用いて、自ｅＮＢが該ＳｅＮＢあるいはＳＣＧセルを用いてＤＣを行っているか否かを判断する。該ＳｅＮＢあるいはＳＣＧセルを用いてＤＣを行っている場合は、該ＤＣ中のＵＥに対してＰＷＳインジケーションを通知するとよい。
【０１７２】
ＰＷＳインジケーションのＵＥへの他の通知方法としては、ＭｅＮＢが、ＰＣＨにマッピングするページングメッセージに、ＰＷＳインジケーションを含めて通知してもよい。ＰＣＨ上に、ＤＣ中のＳｅＮＢ向けのＰＷＳメッセージのＰＷＳインジケーションを設けるとよい。ＰＷＳインジケーションとともに、ＰＷＳメッセージを送信するＳＣＧセルの識別子を含めてもよい。これによって、ＰＷＳメッセージを送信するＳＣＧセルを、ＵＥに特定させることができる。
【０１７３】
ＭｅＮＢは、ＵＥがＰＣＨを受信可能なＭＣＧセルのＰＣＨにマッピングするとよい。
【０１７４】
また、ＭｅＮＢは、ＰＣｅｌｌのＰＣＨにマッピングするようにしてもよい。この方法は、ＵＥがＭｅＮＢのＰＣｅｌｌのみについてＰＣＨを受信している場合に適用することができる。
【０１７５】
ステップＳＴ１１０２において、ＭｅＮＢからＰＷＳインジケーションを受信したＵＥは、ともに通知されたＳＣＧセルの識別子を受信し、どのＳＣＧセル向けにＰＷＳメッセージが送信されたかを認識する。
【０１７６】
ＰＷＳインジケーションを受信したＵＥは、ステップＳＴ１０１０において、ＳＣＧセルから報知されるＳＩＢ１を受信して、ＰＷＳメッセージが含まれるＳＩＢのスケジューリング情報を受信する。そして、ＵＥは、スケジューリング情報に従って、ステップＳＴ１０１１において、ＰＷＳメッセージが含まれるＳＩＢを受信し、ＰＷＳメッセージを受信する。
【０１７７】
緊急性を要するＰＷＳメッセージ、例えばＥＴＷＳなどの場合は、ＵＥは、ＰＷＳインジケーションを受信した後、直ちにＰＷＳメッセージを受信するようにしてもよい。
【０１７８】
ステップＳＴ１０１２において、ＳｅＮＢは、前述の図１０に示す場合と同様に、ＭＭＥに対して、「Write-Replace Warning Response」メッセージを通知し、ＰＷＳメッセージ通知処理の処理手順を終了する。
【０１７９】
ＰＷＳインジケーションの通知方法（１）で開示した、ＤＣに用いられるＳＣＧセルが複数存在する場合の方法、または、ＳｅＮＢがＭＭＥからＰＷＳメッセージを受信した場合にＳＰＣｅｌｌからＰＷＳインジケーションまたはＰＷＳメッセージを通知する方法を、ＰＷＳインジケーションの通知方法（２）に適用してもよい。これによって、ＵＥにおけるＰＷＳインジケーション受信処理あるいはＰＷＳメッセージ受信処理を簡易にすることができ、ＵＥの低消費電力化を図ることが可能となる。
【０１８０】
以上の図１１に示すようなＰＷＳメッセージ通知処理を行うことによって、ＳｅＮＢを用いてＤＣを行っているＵＥが、ＳｅＮＢ向けのＰＷＳメッセージを受信することが可能となる。
【０１８１】
また、ＰＷＳインジケーションの通知方法を、前述の（２）の通知方法とすることによって、ＤＣ中のＵＥは、前述の（１）の通知方法で必要であったＳＣＧセルのＰＣＨを受信する必要が無くなる。したがって、ＵＥの低消費電力化を図ることが可能となる。
【０１８２】
実施の形態１  変形例１．
本変形例では、ＳｅＮＢが、ＤＣ中のＵＥに対して、自ＳｅＮＢ向けのＰＷＳメッセージを送信する方法の他の方法を開示する。
【０１８３】
ＳｅＮＢは、ＤＣ中のＵＥに対して、ＭｅＮＢを介して、自ＳｅＮＢ向けのＰＷＳメッセージを送信する。ＤＣ中のＵＥは、ＭｅＮＢからＳｅＮＢ向けのＰＷＳメッセージを受信する。
【０１８４】
ＰＷＳメッセージが、特定の一つまたは複数のＳＣＧセルに通知される場合は、ＤＣに用いられているＳｅＮＢは、自ＳＣＧセルを用いてＤＣを行っているＵＥに対して、ＭｅＮＢを介して、自ＳＣＧセル向けＰＷＳメッセージを送信する。ＳＣＧセルを用いてＤＣを行っているＵＥは、ＭｅＮＢから、ＳＣＧセル向けのＰＷＳメッセージを受信する。
【０１８５】
ＰＷＳメッセージの通知方法について説明する。図１２は、実施の形態１の変形例１の通信システムにおけるＰＷＳメッセージの流れの一例を示す図である。図１２に示す構成は、図９に示す構成と類似しているので、同一の部分には同一の参照符号を付して、共通する説明を省略する。図１２では、ＰＷＳメッセージの流れを、太線の矢符１０６，１０７，１２２で示している。
【０１８６】
ＰＷＳメッセージは、不図示のＣＢＥからＣＢＣ１０１に通知される。ＣＢＣ１０１は、ＰＷＳメッセージを、矢符１０６で示すように、ＭＭＥ１０２に通知する。
【０１８７】
ＭＭＥ１０２は、ＰＷＳメッセージをｅＮＢに通知する。具体的には、ＭＭＥ１０２は、ＰＷＳメッセージを、矢符１０７で示すように、ＳｅＮＢ１０４に通知する。またＭＭＥ１０２は、ＰＷＳメッセージをＭｅＮＢ１０３に通知する。ｅＮＢは、自セルがＤＣに用いられている場合、すなわち、ＳｅＮＢ１０４である場合、矢符１２１および矢符１２２で示すように、自セルを用いてＤＣを行っているＵＥ１０５に、ＭｅＮＢ１０３を介して、ＰＷＳメッセージを通知する。
【０１８８】
ＭＭＥ１０２からＰＷＳメッセージを受信したＳｅＮＢ１０４は、自ＳｅＮＢを用いてＤＣを行っているＭｅＮＢ１０３に対して、ＰＷＳメッセージを通知する。ＳｅＮＢ１０４は、ＰＷＳメッセージを送信するＳＣＧセルを特定し、該ＳＣＧセルを用いてＤＣを行っているＭｅＮＢ１０３に対して、ＰＷＳメッセージを通知する。
【０１８９】
ＰＷＳメッセージの通知には、Ｘ２インタフェース１１２を用いる。あるいは、ＤＣのためにＭｅＮＢ１０３とＳｅＮＢ１０４との間に、新たにＸｎインタフェースが設けられる場合は、Ｘｎインタフェースを用いてＰＷＳメッセージを通知してもよい。Ｘ２メッセージとして新たなメッセージを設けて、それに含めて通知してもよい。あるいは、ＳＣＧセルの設定変更のためのメッセージに含めて通知してもよい。Ｘ２メッセージ中あるいはＸｎメッセージ中に、ＲＲＣメッセージのコンテナを設け、該コンテナ内に含めて通知してもよい。これらのメッセージは、個別シグナリングで通知されるとよい。
【０１９０】
ＰＷＳメッセージとともに、ＳｅＮＢの識別子、または、特定したＳＣＧセルの識別子を通知しておく。または、特定したＳＣＧセルとＤＣ中のＵＥ識別子を認識している場合は、該ＤＣ中のＵＥの識別子を通知してもよい。また、ＰＷＳメッセージ固有の識別子を通知してもよい。
【０１９１】
ＳｅＮＢからＰＷＳメッセージを受信したＭｅＮＢは、該ＳｅＮＢを用いてＤＣを行っているＵＥに対して、ＰＷＳメッセージを通知する。また、ＰＷＳメッセージとともにＰＷＳメッセージ固有の識別子を通知してもよい。ＳｅＮＢを用いてＤＣを行っているＵＥは、ＭｅＮＢから通知される、該ＳｅＮＢ向けのＰＷＳメッセージを受信する。また、ＰＷＳメッセージとともにＰＷＳメッセージ固有の識別子を受信してもよい。このようにすることによって、ＳｅＮＢを用いてＤＣを行っているＵＥが、ＳｅＮＢ向けのＰＷＳメッセージを得ることが可能となる。
【０１９２】
実施の形態１と同様に、ＰＷＳインジケーションが設けられ、ＰＷＳメッセージに先立って、ＤＣ中のＵＥに通知されるようにしてもよい。この場合、ＤＣ中のＵＥは、ＰＷＳインジケーションを受信すると、ＭｅＮＢから通知されるＳｅＮＢ向けのＰＷＳメッセージを受信する。
【０１９３】
図１２では、ＰＷＳインジケーションの流れを、矢符１０９，１１０，１２３で示している。
【０１９４】
ＳｅＮＢ１０４は、ＭＭＥ１０２から、自ＳｅＮＢ向けのＰＷＳメッセージを受信した場合、矢符１１０で示すように、ＵＥ１０５に対してＰＷＳインジケーションを通知する。あるいは、ＭｅＮＢ１０３がＳｅＮＢ１０４からＰＷＳメッセージを受信した場合、矢符１２３で示すように、ＭｅＮＢ１０３がＤＣ中のＵＥ１０５にＰＷＳインジケーションを通知してもよい。
【０１９５】
ＰＷＳインジケーションの通知方法の具体例として、以下の（１）〜（３）の３つを開示する。
（１）ＳｅＮＢ１０４から、矢符１１０で示すように直接、ＤＣ中のＵＥ１０５に通知する。
（２）ＳｅＮＢ１０４から、矢符１０９で示すように、ＭｅＮＢ１０３を介して、ＤＣ中のＵＥ１０５に通知する。
（３）ＭｅＮＢ１０３が、矢符１２３で示すように、ＤＣ中のＵＥ１０５に通知する。
【０１９６】
前述の（１），（２）の通知方法については、実施の形態１で述べた方法を適用することができる。ＰＷＳインジケーションの通知方法として、前述の（３）の通知方法について説明する。ＳｅＮＢ１０４からＰＷＳメッセージを受信したＭｅＮＢ１０３は、ＤＣ中のＵＥ１０５に対して、ＰＷＳインジケーションを通知する。さらに具体的に述べると、ＭｅＮＢ１０３は、ＰＷＳメッセージとともに受信した、どのＳＣＧセル向けかの情報、例えばＳＣＧセル識別子を用いて、該ＳＣＧセルを用いてＤＣを行っているＵＥ１０５に対して、ＰＷＳインジケーションを通知する。ＳＣＧセルを用いてＤＣを行っているＵＥ１０５は、ＭｅＮＢ１０３から送信されるＰＷＳインジケーションを受信すると、該ＳＣＧセルのＰＷＳメッセージをＭｅＮＢ１０３から受信する。
【０１９７】
図１３は、実施の形態１の変形例１の通信システムにおけるＰＷＳメッセージ通知処理のシーケンスの一例を示す図である。図１３では、ＰＷＳインジケーションの通知方法として、前述の（３）の通知方法を適用した場合の例を示している。図１３に示すシーケンスは、前述の図１０および図１１に示すシーケンスと類似しているので、同一のステップについては同一のステップ番号を付して、共通する説明を省略する。
【０１９８】
まず、前述の図１０および図１１に示す場合と同様にして、ステップＳＴ１００１〜ステップＳＴ１００２、ステップＳＴ１００４〜ステップＳＴ１００８の処理が行われる。ステップＳＴ１００８において、ＰＷＳメッセージを受信したＳｅＮＢは、警報エリア（warning area）情報を用いて、自ＳｅＮＢ向けのＰＷＳメッセージか否かを確認する。ＳｅＮＢは、自ＳｅＮＢ向けのＰＷＳメッセージの場合、警報エリア（warning area）情報を用いて、ＰＷＳメッセージを送信するＳＣＧセルを特定する。
【０１９９】
ステップＳＴ１３０１において、ＳｅＮＢは、特定されたＳＣＧセルを用いてＤＣを行っているＭｅＮＢに対して、ＰＷＳメッセージを通知する。また、ＰＷＳメッセージ固有の識別子を通知してもよい。
【０２００】
ＳｅＮＢからＰＷＳメッセージを受信したＭｅＮＢは、ステップＳＴ１３０２において、該ＳｅＮＢを用いてＤＣを行っているＵＥに対して、ＰＷＳインジケーション（PWS indication）を通知する。該通知には、ＲＲＣメッセージを用いるとよい。ＲＲＣメッセージは、個別シグナリングで通知するとよい。
【０２０１】
ステップＳＴ１３０１において、ＳｅＮＢが、特定されたＳＣＧセルを用いてＤＣを行っているＭｅＮＢに対してＰＷＳメッセージを通知することを開示したが、ＳｅＮＢは、自セルを用いてＤＣを行うことが可能なｅＮＢ、あるいは、周辺のｅＮＢに対して、ＰＷＳメッセージを通知してもよい。この場合、ＳｅＮＢは、ＰＷＳメッセージとともに自ＳｅＮＢの識別子または特定したＳＣＧセルの識別子を通知する。ＰＷＳメッセージを通知されたｅＮＢは、ＳｅＮＢの識別子または特定したＳＣＧセルの識別子を用いて、自ｅＮＢが該ＳｅＮＢあるいはＳＣＧセルを用いてＤＣを行っているか否かを判断する。該ＳｅＮＢあるいはＳＣＧセルを用いてＤＣを行っている場合は、該ＤＣ中のＵＥに対してＰＷＳインジケーションを通知するとよい。
【０２０２】
ステップＳＴ１３０２において、ＭｅＮＢは、ＳｅＮＢを用いてＤＣ中のＵＥに対して、該ＰＷＳインジケーションとともに、ＰＷＳメッセージを送信するＳＣＧセルの識別子を通知してもよい。
【０２０３】
ＰＷＳインジケーションのＵＥへの他の通知方法として、ＭｅＮＢは、ＰＣＨにマッピングするページングメッセージにＰＷＳインジケーションを含めて通知してもよい。ＰＣＨ上に、ＤＣ中のＳｅＮＢ向けのＰＷＳメッセージのＰＷＳインジケーションを設けるとよい。ＰＷＳインジケーションとともに、ＰＷＳメッセージを送信するＳＣＧセルの識別子を含めてもよい。これによって、ＰＷＳメッセージを送信するＳＣＧセルをＵＥに特定させることができる。
【０２０４】
ＭｅＮＢは、ＵＥがＰＣＨを受信可能なＭＣＧセルのＰＣＨにマッピングするとよい。また、ＭｅＮＢは、ＰＣｅｌｌのＰＣＨにマッピングするようにしてもよい。この方法は、ＵＥがＭｅＮＢのＰＣｅｌｌのＰＣＨのみを受信している場合に適用することができる。この場合、ＵＥは、ＰＣｅｌｌのＰＣＨのみを受信すればよく、他のＭＣＧセルから送信されるＰＣＨを受信する必要はない。したがって、ＵＥの低消費電力化を図ることができる。
【０２０５】
ＳｅＮＢからＰＷＳメッセージを受信したＭｅＮＢは、ステップＳＴ１３０４において、ＰＷＳメッセージを報知する。ＭｅＮＢは、ＰＷＳメッセージをＳＩＢに含めて報知する。ＰＷＳメッセージを含めるＳＩＢとして、新たなＳＩＢを設けてもよいし、ＳｅＮＢ向けＰＷＳメッセージ用ＳＩＢを設けてもよい。既存のＳＩＢを用いてもよい。既存のＰＷＳメッセージを含むＳＩＢとしては、例えば、ＥＴＷＳ用としてＳＩＢ１０、ＳＩＢ１１があり、ＣＭＡＳ用としてＳＩＢ１２がある。ＭｅＮＢがＰＷＳメッセージをＤＣ中のＵＥに通知する方法としては、ＭｅＮＢが傘下のＵＥにＰＷＳメッセージを報知する方法を適用することができる。
【０２０６】
ＭｅＮＢは、ＤＣ中のＵＥに対して、ＳｅＮＢ向けのＰＷＳメッセージを、ＰＣｅｌｌから報知してもよい。ＰＣｅｌｌのＳＩＢに含めて報知するようにしてもよい。
【０２０７】
ＤＣ中のＵＥは、ＰＣｅｌｌから送信されるＳｅＮＢ向けのＰＷＳメッセージを受信すればよい。
【０２０８】
ＵＥは、ＰＣｅｌｌのＳＩＢのみを受信すればよく、他のＭＣＧセルから送信されるＳＩＢを受信する必要はない。したがって、ＵＥの低消費電力化を図ることができる。
【０２０９】
ステップＳＴ１３０２においてＭｅＮＢからＰＷＳインジケーションを受信したＵＥは、ステップＳＴ１３０３において、ＭｅＮＢから報知されるＳＩＢ１を受信して、ＰＷＳメッセージが含まれるＳＩＢのスケジューリング情報を受信する。そして、ＵＥは、スケジューリング情報に従って、ステップＳＴ１３０４において、ＰＷＳメッセージが含まれるＳＩＢを受信し、ＰＷＳメッセージを受信する。
【０２１０】
緊急性を要するＰＷＳメッセージ、例えばＥＴＷＳなどの場合は、ＵＥは、ＰＷＳインジケーションを受信した後、直ちにＰＷＳメッセージを受信するようにしてもよい。
【０２１１】
ＭｅＮＢは、ＤＣ中のＵＥに対して、ＰＣｅｌｌからＰＷＳインジケーションまたはＰＷＳメッセージを通知することによって、ＳｅＮＢからＰＷＳインジケーションまたはＰＷＳメッセージを受信する必要が無くなるので、ＵＥの低消費電力化を図ることが可能となる。
【０２１２】
ステップＳＴ１０１２において、ＳｅＮＢは、前述の図１０および図１１に示す場合と同様に、ＭＭＥに対して、「Write-Replace Warning Response」メッセージを通知し、ＰＷＳメッセージ通知処理の処理手順を終了する。
【０２１３】
前述の方法では、ＭｅＮＢは、ＤＣ中のＵＥに対して、ＰＷＳメッセージをＳＩＢに含めて通知する。他の方法として、ＭｅＮＢは、ＤＣ中のＵＥに対して、ＰＷＳメッセージをＲＲＣメッセージに含めて通知してもよい。この場合、ＲＲＣメッセージは、個別シグナリングで通知するとよい。
【０２１４】
ＭｅＮＢが、ＰＷＳメッセージをＳｅＮＢからＲＲＣメッセージのコンテナで通知された場合は、ＲＲＣメッセージに乗せ換え、該コンテナをＤＣ中のＵＥに個別に通知するとよい。
【０２１５】
ＭｅＮＢは、ＳｅＮＢを用いてＤＣを行っているＵＥに対して、該ＰＷＳメッセージとともに、ＰＷＳメッセージを送信するＳＣＧセルの識別子を通知してもよい。
【０２１６】
ＭｅＮＢは、ＰＷＳインジケーションを含めたＲＲＣメッセージを送信した後に、ＰＷＳメッセージを含めたＲＲＣメッセージを送信する。
【０２１７】
また、ＭｅＮＢは、ＤＣ中のＵＥに対して、ＰＷＳインジケーションとＰＷＳメッセージとを一つのＲＲＣメッセージに含めて通知してもよい。この場合、メッセージを一つにすることが可能となるので、ＭｅＮＢとＵＥとの間のシグナリング量の削減を図ることが可能となる。
【０２１８】
以上の図１３に示すようなＰＷＳメッセージ通知処理を行うことによって、ＳｅＮＢを用いてＤＣを行っているＵＥが、該ＳｅＮＢ向けのＰＷＳメッセージを受信することが可能となる。
【０２１９】
また、ＰＷＳメッセージを、ＭｅＮＢから、ＤＣ中のＵＥに通知することによって、ＵＥがＳｅＮＢから送信されるＰＷＳメッセージを受信する必要が無くなる。これによって、ＰＷＳメッセージの受信処理が複雑になることを防ぐことが可能となる。
【０２２０】
また、ＳｅＮＢの報知情報を受信する必要が無くなるので、ＵＥの低消費電力化を図ることができる。
【０２２１】
また、前述のＰＷＳインジケーションの通知方法（２）、（３）では、ＰＷＳインジケーションをＭｅＮＢからＤＣ中のＵＥに通知する。したがって、ＵＥがＳｅＮＢから送信されるＰＷＳインジケーションを受信する必要が無くなる。これによって、ＰＷＳメッセージの受信処理が複雑になることを防ぐことが可能となる。また、ＵＥがＳｅＮＢのＰＣＨを受信する必要が無くなるので、ＵＥの低消費電力化を図ることができる。
【０２２２】
図１３に示す例では、ＤＣ中のＵＥに、ＰＷＳメッセージに先だってＰＷＳインジケーションが通知される方法を開示したが、以下では他の方法を開示する。
【０２２３】
他の方法では、ＤＣ中のＵＥに対するＰＷＳインジケーションを無くす。言い換えると、ＤＣ中のＵＥに対しては、ＰＷＳメッセージのみを通知するようにする。
【０２２４】
図１４は、実施の形態１の変形例１の通信システムにおけるＰＷＳメッセージ通知処理のシーケンスの他の例を示す図である。図１４では、ＤＣ中のＵＥに対しては、ＰＷＳメッセージのみを通知する場合の例を示している。図１４に示すシーケンスは、前述の図１０、図１１および図１３に示すシーケンスと類似しているので、同一のステップについては同一のステップ番号を付して、共通する説明を省略する。
【０２２５】
まず、前述の図１０および図１１に示す場合と同様にして、ステップＳＴ１００１〜ステップＳＴ１００２、ステップＳＴ１００４〜ステップＳＴ１００８の処理が行われる。ステップＳＴ１３０１において、ＳｅＮＢからＰＷＳメッセージを受信したＭｅＮＢは、ステップＳＴ１４０１において、該ＳｅＮＢを用いてＤＣを行っているＵＥに対して、ＰＷＳメッセージを通知する。具体的には、ＭｅＮＢは、ＰＷＳメッセージをＲＲＣメッセージに含めて通知する。ＲＲＣメッセージは、ＵＥ個別シグナリングで通知するとよい。
【０２２６】
ＭｅＮＢが、ＰＷＳメッセージをＳｅＮＢからＲＲＣメッセージのコンテナで通知された場合は、ＲＲＣメッセージに乗せ換え、該コンテナをＤＣ中のＵＥに個別に通知するとよい。
【０２２７】
ＭｅＮＢは、ＳｅＮＢを用いてＤＣ中のＵＥに対して、該ＰＷＳメッセージとともに、ＰＷＳメッセージを送信するＳＣＧセルの識別子を通知してもよい。
【０２２８】
ステップＳＴ１４０１において、ＤＣ中のＵＥは、自ＵＥ宛ての該ＲＲＣメッセージを受信し、ＳｅＮＢ向けのＰＷＳメッセージを受信する。
【０２２９】
このように、ＭｅＮＢは、ＤＣ中のＵＥに対して、ＳｅＮＢ向けのＰＷＳメッセージをＵＥ個別のＲＲＣメッセージに含めて通知する。これによって、ＳｅＮＢ向けのＰＷＳメッセージを特定のＵＥに通知することができる。したがって、ＰＷＳインジケーションをＵＥに通知しなくても、ＰＷＳメッセージをＵＥに通知することが可能となる。
【０２３０】
こうすることによって、ＰＷＳインジケーションの送受信の処理が不要となるので、システムとして処理が複雑になることを防ぐことが可能となる。また、ＰＷＳインジケーション用のシグナリングも不要となるので、シグナリング負荷を低減することも可能となる。
【０２３１】
実施の形態１  変形例２．
本変形例では、ＭｅＮＢが、ＤＣ中のＵＥに対して、ＳｅＮＢ向けのＰＷＳメッセージを送信する方法を開示する。
【０２３２】
本変形例では、ＭＭＥが、ＳｅＮＢ向けのＰＷＳメッセージをＭｅＮＢにも通知する場合について開示する。ＭＭＥがＳｅＮＢ向けのＰＷＳメッセージをＭｅＮＢにも通知する場合として、例えば、ＭｅＮＢとＳｅＮＢとが同一のＴＡＩに存在する場合がある。
【０２３３】
従来、ＭＭＥからＰＷＳメッセージを受信したＭｅＮＢは、該ＰＷＳメッセージが、ＭｅＮＢ向けのＰＷＳメッセージの場合しか傘下のＵＥには通知しない。したがって、仮に、ＭＭＥから通知されたＰＷＳメッセージがＭｅＮＢ向けでなかった場合、ＭｅＮＢの傘下のＵＥには、ＰＷＳメッセージは通知されない。
【０２３４】
たとえ、ＭＭＥがＳｅＮＢ向けのＰＷＳメッセージをＭｅＮＢにも通知したとしても、ＭｅＮＢは、該ＰＷＳメッセージを傘下のＵＥに通知しない。すなわち、ＭｅＮＢは、ＳｅＮＢ向けのＰＷＳメッセージを、傘下の、該ＳｅＮＢを用いてＤＣ中のＵＥに対して通知しない。
【０２３５】
したがって、該ＵＥは、ＳｅＮＢ向けのＰＷＳメッセージを受信することが不可能となるという課題が生じる。本変形例では、このような課題を解決する方法を開示する。
【０２３６】
ＭｅＮＢは、ＤＣ中のＵＥに対して、ＳｅＮＢ向けのＰＷＳメッセージを送信する。
【０２３７】
ＭＭＥからＳｅＮＢ向けのＰＷＳメッセージを受信したＭｅＮＢが、ＳｅＮＢを用いてＤＣ中のＵＥに対して、該ＳｅＮＢ向けのＰＷＳメッセージを通知する。
【０２３８】
ＰＷＳメッセージの通知方法について説明する。図１５は、実施の形態１の変形例２の通信システムにおけるＰＷＳメッセージの流れの一例を示す図である。図１５に示す構成は、図９および図１２に示す構成と類似しているので、同一の部分には同一の参照符号を付して、共通する説明を省略する。図１５では、ＰＷＳメッセージの流れを、太線の矢符１０６，１５１，１５２で示している。
【０２３９】
ＣＢＣ１０１からＰＷＳメッセージを受信したＭＭＥ１０２は、矢符１５１で示すように、ＳｅＮＢ１０４だけでなく、ＭｅＮＢ１０３に対してもＰＷＳメッセージを通知する。
【０２４０】
ＭｅＮＢ１０３は、ＭＭＥ１０２から受信したＰＷＳメッセージが、ＤＣに使用しているＳｅＮＢ１０４向けか否かを判断する。ＭｅＮＢ１０３は、ＤＣに使用しているＳｅＮＢ１０４向けのＰＷＳメッセージを受信した場合、矢符１５２で示すように、該ＳｅＮＢ１０４を用いてＤＣを行っているＵＥ１０５に、ＰＷＳメッセージを通知する。
【０２４１】
ＳｅＮＢ１０４を用いてＤＣを行っているＵＥ１０５は、矢符１５２で示すように、ＭｅＮＢ１０３から該ＳｅＮＢ１０４向けのＰＷＳメッセージを受信する。
【０２４２】
このようにすることによって、矢符１５２に示すように、ＳｅＮＢ１０４を用いてＤＣを行っているＵＥ１０５が、ＳｅＮＢ向けのＰＷＳメッセージを得ることが可能となる。
【０２４３】
本変形例においても、実施の形態１の変形例１と同様に、ＰＷＳインジケーションが設けられ、ＰＷＳメッセージに先立ってＤＣ中のＵＥに通知されるようにしてもよい。ＤＣ中のＵＥは、ＰＷＳインジケーションを受信すると、ＭｅＮＢから通知されるＳｅＮＢ向けのＰＷＳメッセージを受信する。
【０２４４】
図１５には、ＰＷＳインジケーションの流れを併せて示す。図１５では、ＰＷＳインジケーションの流れを細線の矢符１２３で示す。
【０２４５】
矢符１５１で示すように、ＭｅＮＢ１０３が、ＭＭＥ１０２から、ＤＣに使用しているＳｅＮＢ１００４向けのＰＷＳメッセージを受信した場合、ＭｅＮＢ１０３は、矢符１２３で示すように、該ＳｅＮＢ１０４を用いてＤＣを行っているUE１０５に、ＰＷＳインジケーションを通知してもよい。
【０２４６】
ＰＷＳインジケーションの通知方法としては、実施の形態１の変形例１で開示したＰＷＳインジケーションの通知方法（３）を適用することができる。
【０２４７】
図１６は、実施の形態１の変形例２の通信システムにおけるＰＷＳメッセージ通知処理のシーケンスの一例を示す図である。図１６では、ＰＷＳインジケーションの通知方法として、前述の実施の形態１の変形例１で開示したＰＷＳインジケーションの通知方法（３）を適用した場合の例を示している。図１６に示すシーケンスは、前述の図１０、図１１および図１３に示すシーケンスと類似しているので、同一のステップについては同一のステップ番号を付して、共通する説明を省略する。
【０２４８】
まず、前述の図１０および図１１に示す場合と同様にして、ステップＳＴ１００１、ステップＳＴ１００２、ステップＳＴ１００４およびステップＳＴ１００５の処理が行われる。ステップＳＴ１００５において、ＣＢＣからＰＷＳメッセージを受信したＭＭＥは、ＰＷＳメッセージとともに通知されたトラッキングエリアＩＤリスト（tracking area ID list）から、ＰＷＳメッセージを通知するｅＮＢを特定する。ここでは、ＭｅＮＢとＳｅＮＢとがトラッキングエリアＩＤリストに含まれている場合について示している。
【０２４９】
ステップＳＴ１００８において、ＭＭＥは、ＳｅＮＢに対して、Ｓ１−ＭＭＥインタフェースを用いて、ＰＷＳメッセージを通知する。また、ステップＳＴ１６０１において、ＭＭＥは、ＭｅＮＢに対しても、Ｓ１−ＭＭＥインタフェースを用いて、ＰＷＳメッセージを通知する。具体的には、ＭＭＥは、ＰＷＳメッセージとともに、警報エリア（warning area）情報を通知する。ＰＷＳメッセージおよび警報エリア情報の通知用のメッセージとしては、「Write-Replace Warning Request」メッセージが用いられる。
【０２５０】
ステップＳＴ１６０１においてＰＷＳメッセージを受信したＭｅＮＢは、ステップＳＴ１６０２において、警報エリア（warning area）情報を用いて、ＤＣに使用しているＳｅＮＢ向けのＰＷＳメッセージであるか否かを判断する。
【０２５１】
ＤＣに使用しているＳｅＮＢ向けのＰＷＳメッセージで無い場合、ＭｅＮＢは、該ＳｅＮＢを用いてＤＣを行っているＵＥへのＰＷＳメッセージの送信処理を行わずに、通常の処理に戻る。ＤＣに使用しているＳｅＮＢ向けのＰＷＳメッセージの場合、ＭｅＮＢは、警報エリア（warning area）情報を用いて、ＰＷＳメッセージを送信するＳＣＧセルを特定する。
【０２５２】
ステップＳＴ１３０２において、ＭｅＮＢは、ＰＷＳインジケーションを、該ＳｅＮＢを用いてＤＣを行っているＵＥに通知する。
【０２５３】
ＰＷＳインジケーションを受信したＤＣ中のＵＥは、ステップＳＴ１３０３およびステップＳＴ１３０４の処理によって、ＭｅＮＢから通知されるＰＷＳメッセージを受信する。ステップＳＴ１３０３およびステップＳＴ１３０４の処理の方法としては、実施の形態１の変形例１の方法を適用することができるので、ここでは説明を省略する。
【０２５４】
ステップＳＴ１６０３において、ＭｅＮＢは、ＭＭＥに対して、「Write-Replace Warning Response」メッセージを通知し、ＰＷＳメッセージ通知処理の処理手順を終了する。
【０２５５】
以上の図１６に示すようなＰＷＳメッセージ通知処理を行うことによって、ＳｅＮＢを用いてＤＣを行っているＵＥが、ＳｅＮＢ向けのＰＷＳメッセージを受信することが可能となる。
【０２５６】
また、ＭｅＮＢがＳｅＮＢからＰＷＳメッセージを受信する必要が無くなるので、ＳｅＮＢとＭｅＮＢとの間で生じるＰＷＳメッセージの送受信処理を削減することが可能となる。したがって、ＳｅＮＢおよびＭｅＮＢにおける処理を簡略化することができ、また、ＳｅＮＢとＭｅＮＢとの間のシグナリング負荷を低減することが可能となる。
【０２５７】
本変形例では、ＤＣ中のＵＥに、ＰＷＳメッセージに先だってＰＷＳインジケーションが通知される方法を開示したが、以下では他の方法を開示する。
【０２５８】
ＤＣ中のＵＥに対するＰＷＳインジケーションを無くす。言い換えると、ＤＣ中のＵＥに対しては、ＰＷＳメッセージのみを通知するようにする。
【０２５９】
図１７は、実施の形態１の変形例２の通信システムにおけるＰＷＳメッセージ通知処理のシーケンスの他の例を示す図である。図１７では、ＤＣ中のＵＥに対しては、ＰＷＳメッセージのみの通知とする場合を示している。図１７に示すシーケンスは、前述の図１０、図１１、図１３、図１５および図１６に示すシーケンスと類似しているので、同一のステップについては同一のステップ番号を付して、共通する説明を省略する。
【０２６０】
まず、前述の図１６に示す場合と同様にして、ステップＳＴ１００１、ステップＳＴ１００２、ステップＳＴ１００４〜ステップＳＴ１００８、およびステップＳＴ１６０１の処理が行われる。ステップＳＴ１６０１において、ＭＭＥからＰＷＳメッセージを受信したＭｅＮＢは、ステップＳＴ１６０２において、警報エリア（warning area）情報を用いて、ＤＣに使用しているＳｅＮＢ向けのＰＷＳメッセージであるか否かを判断する。
【０２６１】
ＤＣに使用しているＳｅＮＢ向けのＰＷＳメッセージで無い場合、ＭｅＮＢは、該ＳｅＮＢを用いてＤＣを行っているＵＥへのＰＷＳメッセージ送信処理を行わず、通常の処理に戻る。ＤＣに使用しているＳｅＮＢ向けのＰＷＳメッセージの場合、ＭｅＮＢは、警報エリア（warning area）情報を用いて、ＰＷＳメッセージを送信するＳＣＧセルを特定する。
【０２６２】
ステップＳＴ１４０１において、ＭｅＮＢは、ＳｅＮＢを用いてＤＣを行っているＵＥに対して、ＰＷＳメッセージを通知する。具体的には、ＭｅＮＢは、ＰＷＳメッセージをＲＲＣメッセージに含めて通知する。ＲＲＣメッセージは、ＵＥ個別シグナリングで通知するとよい。
【０２６３】
ＭｅＮＢは、ＳｅＮＢを用いてＤＣを行っているＵＥに対して、ＰＷＳメッセージとともに、ＰＷＳメッセージを送信するＳＣＧセルの識別子を通知してもよい。
【０２６４】
ステップＳＴ１４０１において、ＤＣ中のＵＥは、自ＵＥ宛ての該ＲＲＣメッセージを受信し、ＳｅＮＢ向けのＰＷＳメッセージを受信する。
【０２６５】
このように、ＭｅＮＢは、ＤＣ中のＵＥに対して、ＳｅＮＢ向けのＰＷＳメッセージを、ＵＥ個別のＲＲＣメッセージに含めて通知することによって、ＳｅＮＢ向けのＰＷＳメッセージを特定のＵＥに通知することができる。したがって、ＰＷＳインジケーションをＵＥに通知しなくても、ＰＷＳメッセージをＵＥに通知することが可能となる。
【０２６６】
こうすることによって、ＰＷＳインジケーションの送受信の処理が不要となるので、システムとして処理が複雑になることを防ぐことが可能となる。また、ＰＷＳインジケーション用のシグナリングも不要となるので、シグナリング負荷を低減することも可能となる。
【０２６７】
実施の形態１  変形例３．
本変形例では、ＭｅＮＢが、ＤＣ中のＵＥに対して、ＳｅＮＢ向けのＰＷＳメッセージを送信する方法の他の方法を開示する。
【０２６８】
実施の形態１の変形例２では、ＭＭＥが、ＳｅＮＢ向けのＰＷＳメッセージをＭｅＮＢにも通知する場合について開示した。しかし、ＭＭＥが、ＳｅＮＢ向けのＰＷＳメッセージをＭｅＮＢに通知しない場合も存在する。例えば、ＭｅＮＢとＳｅＮＢとが異なるＴＡＩに存在する場合などである。このような場合は、実施の形態１の変形例２で開示した方法は適用できない。
【０２６９】
本変形例では、このような課題を解決する方法を開示する。
【０２７０】
ＭｅＮＢは、ＭＭＥに、ＤＣに使用しているＳｅＮＢの情報を通知する。ＭｅＮＢは、この通知を、ＤＣに使用しているＳｅＮＢあるいはＳＣＧセルの変更の際に行うようにするとよい。これによって、ＭＭＥが有するＳｅＮＢの情報が適宜更新されることになる。ＤＣに使用しているＳｅＮＢの情報の通知は、ＳｅＮＢの追加処理において行われてもよい。あるいは、ＳｅＮＢの変更処理あるいはＳｅＮＢの修正処理において行われてもよい。また、ＳｅＮＢの解放（リリース）処理においては、ＭｅＮＢは、ＤＣに使用しているＳｅＮＢが無いことを示す情報をＭＭＥに通知してもよい。
【０２７１】
このようにすることによって、ＭＭＥは、ＰＷＳメッセージを送信するＳｅＮＢと、該ＳｅＮＢをＤＣに用いているＭｅＮＢとを関連付けることが可能となる。したがって、ＭＭＥは、ＳｅＮＢ向けのＰＷＳメッセージを、該ＳｅＮＢをＤＣに使用しているＭｅＮＢに対して通知することが可能となる。
【０２７２】
ＭＭＥは、ＰＷＳメッセージを受信した場合、ＤＣに使用しているＳｅＮＢ向けか否かを判断する。ＭＭＥは、ＤＣに使用しているＳｅＮＢ向けのＰＷＳメッセージを受信した場合、ＭｅＮＢに対して、該ＰＷＳメッセージを通知する。
【０２７３】
ＭｅＮＢは、ＭＭＥから受信したＰＷＳメッセージが、ＤＣに使用しているＳｅＮＢ向けか否かを判断する。ＭｅＮＢは、ＤＣに使用しているＳｅＮＢ向けのＰＷＳメッセージを受信した場合、該ＳｅＮＢを用いてＤＣを行っているＵＥに、ＰＷＳメッセージを通知する。
【０２７４】
該ＳｅＮＢセルを用いてＤＣを行っているＵＥは、ＭｅＮＢから該ＳｅＮＢセル向けのＰＷＳメッセージを受信する。
【０２７５】
ＰＷＳメッセージの通知方法について示す。本変形例におけるＰＷＳメッセージの流れは、前述の図１５に示す実施の形態１の変形例２の場合と同様である。
【０２７６】
実施の形態１の変形例２と同様に、ＰＷＳインジケーションが設けられ、ＰＷＳメッセージに先立って、ＤＣ中のＵＥに通知されるようにしてもよい。ＤＣ中のＵＥは、ＰＷＳインジケーションを受信すると、ＭｅＮＢから通知されるＳｅＮＢ向けのＰＷＳメッセージを受信する。
【０２７７】
本変形例におけるＰＷＳインジケーションの流れも、前述の図１５に示す実施の形態１の変形例２の場合と同様である。
【０２７８】
ＭｅＮＢが、ＭＭＥから、ＤＣに使用しているＳｅＮＢ向けのＰＷＳメッセージを受信した場合、ＭｅＮＢは、該ＳｅＮＢを用いてＤＣを行っているＵＥに、ＰＷＳインジケーションを通知してもよい。ＰＷＳインジケーションの通知方法としては、実施の形態１の変形例1で開示したＰＷＳインジケーションの通知方法（３）を適用することができる。
【０２７９】
図１８は、実施の形態１の変形例３の通信システムにおけるＰＷＳメッセージ通知処理のシーケンスの一例を示す図である。図１８に示すシーケンスは、前述の図１６に示すシーケンスと類似しているので、同一のステップについては同一のステップ番号を付して、共通する説明を省略する。
【０２８０】
まず、前述の図１６に示す場合と同様にして、ステップＳＴ１００１の処理が行われる。ステップＳＴ１００２において、ＭｅＮＢは、該ＵＥに対して、ＤＣを実行するために、ＳｅＮＢ追加処理を起動する。これによって、ＭｅＮＢ、ＵＥおよびＳｅＮＢの間で、ＳｅＮＢ追加処理が行われる。このＳｅＮＢ追加処理において、ＳｅＮＢは、自セルのセルＩＤ（Cell ID）、あるいはＴＡＩ，あるいは緊急エリアＩＤ（Emergency Area ID）を、ＭｅＮＢに通知する。
【０２８１】
ステップＳＴ１８０１において、ＭｅＮＢは、追加したＳｅＮＢに関する情報をＭＭＥに通知する。また、ＭｅＮＢは、ＳＣＧセルに関する情報を通知してもよい。ＳｅＮＢに関する情報として、警報エリア（Warning Area）情報を特定できる情報、具体的には、ＳｅＮＢのセルＩＤ（Cell ID）、ＴＡＩ、緊急エリアＩＤ（Emergency Area ID）とするとよい。また、ＳｅＮＢに関する情報として、自ＳｅＮＢを用いてＤＣを行っているＭｅＮＢの識別子を通知してもよい。これによって、ＳｅＮＢに関する情報が、どのＭｅＮＢがＤＣに使用しているＳｅＮＢに関する情報なのかを認識できるようになる。
【０２８２】
ＳｅＮＢを用いたＤＣが、ＤＣアーキテクチャ１Ａの場合、ステップＳＴ１００２におけるＤＣ実行のためのＳｅＮＢ追加処理において、ＭｅＮＢは、ＭＭＥに、Ｓ−ＧＷにおけるユーザプレイン（U-plane）のパス変更通知を行う。ＭｅＮＢは、追加したＳｅＮＢに関する情報をＭＭＥに通知するために、この変更通知を利用してもよい。例えば、パス変更通知メッセージに、ＳｅＮＢに関する情報を含めて通知するようにしてもよい。あるいは、ＳｅＮＢ追加処理において、ＭｅＮＢは、ＭＭＥに、別のメッセージで、ＳｅＮＢに関する情報を含めて通知してもよい。
【０２８３】
ステップＳＴ１００５において、ＣＢＣからＰＷＳメッセージを受信したＭＭＥは、ＰＷＳメッセージとともに受信したトラッキングエリアＩＤリスト（tracking area ID list）から、ＰＷＳメッセージを通知するｅＮＢを特定する。
【０２８４】
ステップＳＴ１８０２において、ＭＭＥは、特定したｅＮＢと、ステップＳＴ１８０１でＭｅＮＢから受信した、追加したＳｅＮＢに関する情報を用いて、ＤＣ中のＳｅＮＢであるか否かを判断する。特定したｅＮＢがＤＣ中のＳｅＮＢであった場合、該ＰＷＳメッセージが、ＤＣ中のＳｅＮＢ向けであると判断する。特定したｅＮＢがＤＣ中のＳｅＮＢでなかった場合、該ＰＷＳメッセージが、ＤＣ中のＳｅＮＢ向けでは無いと判断する。
【０２８５】
該ＰＷＳメッセージがＤＣ中のＳｅＮＢ向けでは無い場合、該ＳｅＮＢを用いてＤＣを実行しているＭｅＮＢへはＰＷＳメッセージ送信処理を行わず、通常の処理に戻る。
【０２８６】
該ＰＷＳメッセージがＤＣ中のＳｅＮＢ向けの場合、ＭＭＥは、ステップＳＴ１８０１でＭｅＮＢから受信した、追加したＳｅＮＢに関する情報を用いて、ＰＷＳメッセージを送信するｅＮＢを特定する。ここではＭｅＮＢになる。また、ＭＭＥは、ステップＳＴ１８０１で受信した、追加したＳｅＮＢに関する情報と、該情報を通知してきたＭｅＮＢとを関連付けておき、該ＳｅＮＢと関連付けられたＭｅＮＢ情報を用いて、ＰＷＳメッセージを送信するｅＮＢを特定してもよい。
【０２８７】
ＰＷＳメッセージを送信するｅＮＢを特定したＭＭＥは、該ｅＮＢに対してＰＷＳメッセージを通知する。該ｅＮＢは、ここではＭｅＮＢとなる。ステップＳＴ１６０１において、ＭＭＥは、ＭｅＮＢに対しても、Ｓ１−ＭＭＥインタフェースを用いて、ＳｅＮＢ向けのＰＷＳメッセージを通知する。
【０２８８】
ＭＭＥは、ＰＷＳメッセージとともに、トラッキングエリアＩＤリスト（tracking area ID list）、警報エリア（warning area）情報、グローバルｅＮＢ  ＩＤ（Global eNB ID）を通知する。該通知用のメッセージとして、「Write-Replace Warning Request」メッセージを用いる。また、ＰＷＳメッセージ固有の識別子を通知してもよい。
【０２８９】
ステップＳＴ１６０１において、ＰＷＳメッセージを受信したＭｅＮＢは、ステップＳＴ１６０２において、警報エリア（warning area）情報を用いて、ＤＣに使用しているＳｅＮＢ向けのＰＷＳメッセージか否かを判断する。
【０２９０】
ＤＣに使用しているＳｅＮＢ向けのＰＷＳメッセージで無い場合、ＭｅＮＢは、該ＳｅＮＢを用いてＤＣを行っているＵＥへのＰＷＳメッセージ送信処理を行わず、通常の処理に戻る。ＤＣに使用しているＳｅＮＢ向けのＰＷＳメッセージの場合、警報エリア（warning area）情報を用いて、ＰＷＳメッセージを送信するＳＣＧセルを特定する。
【０２９１】
ステップＳＴ１３０２において、ＭｅＮＢは、ＰＷＳインジケーションを、該ＳｅＮＢを用いてＤＣを行っているＵＥに通知する。ＰＷＳインジケーションを受信したＤＣ中のＵＥは、ステップＳＴ１３０３およびステップＳＴ１３０４において、ＭｅＮＢから通知されるＰＷＳメッセージを受信する。ステップＳＴ１３０３およびステップＳＴ１３０４の方法としては、実施の形態１の変形例１の方法を適用することができるので、ここでは説明を省略する。
【０２９２】
ＭＭＥは、ステップＳＴ１８０２において、ＰＷＳメッセージがＤＣ中のＳｅＮＢ向けと判断した場合、ＭｅＮＢに対して、ＰＷＳメッセージとともに、ＤＣ中のＳｅＮＢ向けであることを示す情報を通知してもよい。これによって、ＭｅＮＢは、受信したＰＷＳメッセージが、ＤＣに使用しているＳｅＮＢ向けであることを明示的に認識することが可能となる。ＭｅＮＢは、ステップＳＴ１６０２における判断に該情報を用いるとよい。これによって、誤動作を低減させることが可能となる。
【０２９３】
以上の図１８に示すようなＰＷＳメッセージ通知処理を行うことによって、ＳｅＮＢを用いてＤＣを行っているＵＥが、該ＳｅＮＢ向けのＰＷＳメッセージを受信することが可能となる。
【０２９４】
ＭＭＥが、ＳｅＮＢ向けのＰＷＳメッセージをＭｅＮＢに通知しない場合、例えば、ＭｅＮＢとＳｅＮＢとが異なるＴＡＩに存在する場合なども、ＭｅＮＢは、ＳｅＮＢ向けのＰＷＳメッセージを、ＤＣ中のＵＥに通知することが可能となる。
【０２９５】
ＤＣ中のＵＥは、ＳｅＮＢ向けのＰＷＳメッセージをＭｅＮＢから受信することが可能となる。
【０２９６】
本変形例では、ＤＣ中のＵＥに、ＰＷＳメッセージに先だって、ＰＷＳインジケーションが通知される方法を開示したが、以下では他の方法を開示する。
【０２９７】
ＤＣ中のＵＥに対するＰＷＳインジケーションを無くす。言い換えると、ＤＣ中のＵＥに対しては、ＰＷＳメッセージのみを通知するようにする。
【０２９８】
図１９は、実施の形態１の変形例３の通信システムにおけるＰＷＳメッセージ通知処理のシーケンスの他の例を示す図である。図１９では、ＤＣ中のＵＥに対しては、ＰＷＳメッセージのみの通知とする場合を示している。図１９に示すシーケンスは、前述の図１７および図１８と類似しているので、同一のステップについては同一のステップ番号を付して、共通する説明を省略する。
【０２９９】
図１９に示す例では、まず、前述の図１８に示す場合と同様にして、ステップＳＴ１００１，ＳＴ１００２，ＳＴ１８０１，ＳＴ１００４〜ＳＴ１００８，ＳＴ１８０２，ＳＴ１６０１，ＳＴ１６０２の処理が実行される。その後、前述の図１７に示す場合と同様にして、ステップＳＴ１４０１，ＳＴ１０１２，ＳＴ１６１３の処理が実行される。
【０３００】
このようにすることによって、本変形例においても、ＰＷＳインジケーションの送受信の処理を不要とすることができる。したがって、システムとして処理が複雑になることを防ぐことが可能となる。また、ＰＷＳインジケーション用のシグナリングも不要となるので、シグナリング負荷を低減することも可能となる。
【０３０１】
実施の形態１  変形例４．
本変形例では、ＳｅＮＢが、ＤＣ中のＵＥに対して、自ＳｅＮＢ向けのＰＷＳメッセージを送信する方法の他の方法を開示する。
【０３０２】
本変形例では、ＭｅＮＢに接続されるＭＭＥと、ＳｅＮＢに接続されるＭＭＥとが異なる場合について示す。
【０３０３】
この場合、ＭＭＥからＰＷＳメッセージを受信したＳｅＮＢが、ＤＣ中のＵＥに対して、自ＳｅＮＢ向けのＰＷＳメッセージを送信すればよい。ＳｅＮＢは直接、ＤＣ中のＵＥに対して、自ＳｅＮＢ向けのＰＷＳメッセージを送信する。あるいは、ＳｅＮＢは、ＭｅＮＢを介して、ＤＣ中のＵＥに対して、自ＳｅＮＢ向けのＰＷＳメッセージを送信してもよい。
【０３０４】
ＤＣ中のＵＥは、ＳｅＮＢから、あるいは、ＭｅＮＢから、ＳｅＮＢ向けのＰＷＳメッセージを受信する。この方法としては、実施の形態１、実施の形態１の変形例１で開示した方法を適用すればよい。ＰＷＳメッセージが特定の一つまたは複数のＳＣＧセルに通知される場合も同様である。
【０３０５】
ＰＷＳメッセージの通知方法について説明する。図２０は、実施の形態１の変形例４の通信システムにおけるＰＷＳメッセージの流れの一例を示す図である。図２０に示す構成は、図９および図１２に示す構成と類似しているので、同一の部分には同一の参照符号を付して、共通する説明を省略する。図２０では、ＰＷＳメッセージの流れを、太線の矢符２０２，２０３，１２１，１２２，１０８で示している。
【０３０６】
図２０では、ＳｅＮＢ１０４に接続されるＭＭＥ（以下「ＳｅＮＢ用ＭＭＥ」という場合がある）２０１と、ＭｅＮＢ１０３に接続されるＭＭＥ１０２（以下「ＭｅＮＢ用ＭＭＥ」という場合がある）とが異なる場合を示している。
【０３０７】
ＣＢＣ１０１は、ＳｅＮＢ用ＭＭＥ２０１に接続される。図２０では、ＣＢＣ１０１からＳｅＮＢ１０４までのＰＷＳメッセージの流れを、太線の矢符２０２，２０３でを示す。
【０３０８】
ＰＷＳメッセージは、不図示のＣＢＥからＣＢＣ１０１へ通知され、ＣＢＣ１０１からＳｅＮＢ用ＭＭＥ２０１に通知され、ＳｅＮＢ用ＭＭＥ２０１からＳｅＮＢ１０４へ通知される。
【０３０９】
ｅＮＢは、自セルがＤＣに用いられている場合、すなわち、ＳｅＮＢ１０４である場合、矢符１０８で示すように、自セルを用いてＤＣを行っているＵＥ１０５に、ＰＷＳメッセージを通知する。また、この場合、ＰＷＳインジケーションは、矢符１０９，１１０で示すように、ＳｅＮＢ１０４からＭｅＮＢ１０３およびＵＥ１０５に通知される。
【０３１０】
ＳｅＮＢ１０４は、自セルを用いてＤＣを行っているＵＥ１０５に、矢符１２１，１２２で示すように、ＭｅＮＢ１０３を介してＰＷＳメッセージを通知してもよい。この場合、ＰＷＳインジケーションは、矢符１１０，１０９，１２３で示すように、ＳｅＮＢ１０４からＭｅＮＢ１０３およびＵＥ１０５に通知される。
【０３１１】
ＳｅＮＢがＤＣ中のＵＥにＰＷＳメッセージを通知する場合の、ＰＷＳメッセージおよびＰＷＳインジケーションの通知方法には、前述の実施の形態１で開示した方法を適用すればよい。これによって、ＳｅＮＢを用いてＤＣを行っているＵＥは、ＳｅＮＢからＰＷＳメッセージを受信可能となる。
【０３１２】
ＳｅＮＢが、ＭｅＮＢを介してＤＣ中のＵＥにＳｅＮＢ向けのＰＷＳメッセージを通知する場合の、ＰＷＳメッセージおよびＰＷＳインジケーションの通知方法には、前述の実施の形態１の変形例１で開示した方法を適用すればよい。これによって、ＳｅＮＢを用いてＤＣを行っているＵＥは、ＭｅＮＢからＳｅＮＢ向けのＰＷＳメッセージを受信可能となる。
【０３１３】
このようにすることによって、ＭｅＮＢに接続されるＭＭＥと、ＳｅＮＢに接続されるＭＭＥとが異なる場合についても、ＳｅＮＢを用いてＤＣを行っているＵＥは、ＳｅＮＢ向けのＰＷＳメッセージを受信可能となる。
【０３１４】
ＭｅＮＢに接続されるＭＭＥとＳｅＮＢに接続されるＭＭＥとは異なるが、ＭｅＮＢに接続されるＭＭＥにも、ＳｅＮＢに接続されるＭＭＥにも、ＣＢＣが接続されている場合には、前述の実施の形態１の変形例３で開示した方法を適用することができる。
【０３１５】
この場合、ＣＢＣは、ＭｅＮＢが接続されるＭＭＥにＰＷＳメッセージを通知する。ＰＷＳメッセージを通知されたＭＭＥとＤＣ中のＵＥとの間におけるＳｅＮＢ向けのＰＷＳメッセージの通知方法には、前述の実施の形態１の変形例３で開示した方法を適用すればよい。
【０３１６】
このようにすることによって、ＳｅＮＢを用いてＤＣを行っているＵＥは、ＳｅＮＢ向けのＰＷＳメッセージを受信可能となる。
【０３１７】
ＭｅＮＢに接続されるＭＭＥと、ＳｅＮＢに接続されるＭＭＥとは異なるが、ＭｅＮＢに接続されるＭＭＥにも、ＳｅＮＢに接続されるＭＭＥにも、ＣＢＣが接続されており、ＭｅＮＢとＳｅＮＢとが同じトラッキングエリア（ＴＡ）内にあるような場合には、前述の実施の形態１の変形例２で開示した方法を適用することができる。
【０３１８】
これによって、ＳｅＮＢを用いてＤＣを行っているＵＥは、ＳｅＮＢ向けのＰＷＳメッセージを受信可能となる。ＭＣＧセルとＳＣＧセルとが同じＴＡ内にあるような場合も同様である。
【０３１９】
同一のＰＷＳメッセージをＭｅＮＢとＳｅＮＢとの両方が傘下のＵＥに通知する場合がある。換言すると、ＭｅＮＢ向けＰＷＳメッセージとＳｅＮＢ向けＰＷＳメッセージとが同じ場合がある。このような場合、本実施の形態および変形例で開示した方法を用いると、ＵＥは、ＭｅＮＢ向けＰＷＳメッセージとＳｅＮＢ向けＰＷＳメッセージとを受信することになる。すなわち、同一のＰＷＳメッセージを重複して受信することになる。
【０３２０】
ＵＥは、同じＰＷＳメッセージを重複して受信可能とすることによって、たとえ、どちらか一つのＰＷＳメッセージを受信できなかったとしても、他のＰＷＳメッセージを受信することができるようになる。したがって、ＵＥがＰＷＳメッセージを受信できなくなる確率を低減することができる。これによって、ＰＷＳとして堅固なシステムを構築することができる。
【０３２１】
しかし、ＵＥが同一のＰＷＳメッセージを重複して受信することは、消費電力の増大につながるという問題がある。この問題を解決するための方法として、以下の（１）〜（３）の３つを開示する。
【０３２２】
（１）ＵＥがＭｅＮＢとＳｅＮＢとの両方からＰＷＳメッセージを通知される場合、ＵＥは、ＭｅＮＢから通知されたＰＷＳメッセージと、ＳｅＮＢから通知されたＰＷＳメッセージとが同一のＰＷＳメッセージか否かを判断する。この判断に、ＰＷＳメッセージとともに通知される、メッセージ固有の識別子を用いるとよい。メッセージ固有の識別子として、例えば、メッセージＩＤ（message ID）がある。ＵＥは、最初に通知されたＰＷＳメッセージを受信する。その際に、該ＰＷＳメッセージのメッセージＩＤを記録する。後に通知されたＰＷＳメッセージのメッセージＩＤを、以前に受信したＰＷＳメッセージのメッセージＩＤと比較する。
【０３２３】
メッセージＩＤが同じ場合は、そのＰＷＳメッセージを受信しない。またはＰＷＳメッセージを復調しないとしてもよい。メッセージＩＤが異なる場合は、ＰＷＳメッセージを受信する。また、該メッセージＩＤを記録する。これを繰り返すことによって、ＵＥは、同一のＰＷＳメッセージを重複して受信することを防ぐことができる。したがって、ＵＥの消費電力の増大を防ぐことができる。以上の（１）の方法は、実施の形態１で開示した方法を用いる場合に適用するとよい。
【０３２４】
（２）ＭｅＮＢがＳｅＮＢからＰＷＳメッセージを受信する場合、ＭｅＮＢは、自ＭｅＮＢ向けＰＷＳメッセージと、ＳｅＮＢ向けＰＷＳメッセージとが同じかどうかを判断するとよい。ＰＷＳインジケーションの通知方法は、前述の（２）あるいは（３）の方法とするとよい。
【０３２５】
ＭｅＮＢが判断する方法を開示する。ＭｅＮＢは、自ＭｅＮＢ向けＰＷＳメッセージのメッセージＩＤを記録し、記録した自ＭｅＮＢ向けＰＷＳメッセージのメッセージＩＤと、ＳｅＮＢから受信したＰＷＳメッセージとともに通知されたメッセージＩＤとを比較する。メッセージＩＤが同じ場合は、該ＳｅＮＢから受信したＰＷＳメッセージを、該ＳｅＮＢを用いてＤＣを行っているＵＥに対して送信しない。この場合、ＰＷＳインジケーションも該ＵＥに対して通知しないようにするとよい。メッセージＩＤが異なる場合は、ＭｅＮＢは、該ＳｅＮＢから受信したＰＷＳメッセージを、該ＳｅＮＢを用いてＤＣを行っているＵＥに対して送信する。
【０３２６】
このようにすることによって、ＵＥが同一のＰＷＳメッセージを重複して受信することを防ぐことができる。したがって、ＵＥの消費電力の増大を防ぐことができる。
【０３２７】
以上の（２）の方法は、実施の形態１の変形例１で開示した方法を用いる場合に適用するとよい。
【０３２８】
（３）ＭｅＮＢが、ＭＭＥからＳｅＮＢ向けＰＷＳメッセージを受信する場合、ＭｅＮＢが、自ＭｅＮＢ向けＰＷＳメッセージと、ＳｅＮＢ向けＰＷＳメッセージとが同じかどうかを判断するとよい。
【０３２９】
ＭｅＮＢが判断する方法を開示する。ＭｅＮＢは、ＭＭＥから受信したＰＷＳメッセージが、ＳｅＮＢ向けであるとともに、自ＭｅＮＢ向けであるか否かを判断する。この場合、ＭＭＥからＰＷＳメッセージとともに通知された警報エリア（Warning Area）情報を用いて判断すればよい。具体的には、警報エリア情報に、ＰＷＳメッセージを送信するｅＮＢあるいはセルの情報として、自ＭｅＮＢと、自ＭｅＮＢとＤＣを行っているＳｅＮＢとの両方が存在するか否かを判断する。
【０３３０】
両方が存在する場合は、ＭｅＮＢは、自ＭｅＮＢ向けＰＷＳメッセージと、ＳｅＮＢ向けＰＷＳメッセージとが同じと判断し、該ＳｅＮＢを用いてＤＣを行っているＵＥに対しては、該ＰＷＳメッセージを一度のみ送信する。この場合、ＰＷＳインジケーションも該ＵＥに対して一度のみ通知するようにしてもよい。ＳｅＮＢ向けＰＷＳメッセージの通知方法を実行しないとしてもよい。両方が存在しない場合は、各ＰＷＳメッセージの通知方法でＵＥに対してＰＷＳメッセージを通知する。
【０３３１】
このようにすることによって、ＵＥが同一のＰＷＳメッセージを重複して受信することを防ぐことができる。したがって、ＵＥの消費電力の増大を防ぐことができる。
【０３３２】
以上の（３）の方法は、実施の形態１の変形例２で開示した方法を用いる場合、実施の形態１の変形例３で開示した方法を用いる場合に適用するとよい。
【０３３３】
実施の形態１の変形例４で開示した方法を用いる場合は、ＰＷＳメッセージの通知経路に応じて、上で開示した方法を適宜適用すればよい。これによって、同様の効果を得ることができる。
【０３３４】
実施の形態２．
実施の形態２で解決する課題、およびその解決策について、以下に示す。
【０３３５】
緊急呼（emergency call）などの緊急サービス（emergency service）において、将来、地図情報などの大容量のデータ通信の要求が生じることが考えられる。したがって、緊急サービス用の緊急セッション（emergency session）または緊急サービス用の緊急ベアラ（emergency bearer）に対しても、ＤＣを実行可能とする要求が生じると考えられる。
【０３３６】
３ＧＰＰでは、緊急サービスについての規格が決められてきたが（非特許文献１３  ４．３.１２参照）、緊急サービスへのＤＣの導入に関する議論は何らなされていない。
【０３３７】
したがって、緊急ベアラに対して、３ＧＰＰで議論されているＳｅＮＢ追加処理（SeNB addition procedure）あるいはＳｅＮＢ修正処理（SeNB modification procedure）（非特許文献９参照）などのＤＣを実行するための処理を単に適用しただけでは、緊急ベアラに対して、ＳｅＮＢを用いたＤＣを行えない場合が生じてしまう。
【０３３８】
例えば、ＭｅＮＢが、あるベアラに対してＤＣを実行する場合、ＳｅＮＢに対してＳｅＮＢ追加（SeNB addition）要求を通知するときに、該ベアラが緊急ベアラか否かを通知していない。したがって、ＳｅＮＢは、ＭｅＮＢからのＳｅＮＢ追加（SeNB addition）要求が緊急ベアラ用か否かを認識できない。
【０３３９】
また、ＳｅＮＢは、自ＳｅＮＢあるいはＳＣＧセルのリソースの状況に応じて、ＭｅＮＢから受信したＳｅＮＢ追加（SeNB addition）要求を拒否する場合がある。例えば、ＳｅＮＢがオーバロード（overload）の場合、あるいは、ＳｅＮＢがＭＭＥからオーバロード開始処理（overload start procedure）を通知されている場合、あるいは、ＳｅＮＢがＤＣ対象のＵＥに対してアクセス制限している場合、例えば「not suitable」の場合などである。このような場合、ＳｅＮＢは、ＭｅＮＢからのＳｅＮＢ追加要求を拒否してしまう。
【０３４０】
このように、緊急ベアラに対するＳｅＮＢ追加処理であることを認識しないＳｅＮＢは、自ＳｅＮＢの状況に応じて、ＳｅＮＢ追加処理を拒否してしまう場合が発生する。拒否されたＭｅＮＢは、緊急ベアラに対してＤＣを実行することが不可能となる。言い換えると、緊急サービスを提供するＵＥに対して、ＤＣの実行が不可能となってしまう。
【０３４１】
本実施の形態では、緊急ベアラに対してＤＣを実行可能とする方法を開示する。実施の形態２における解決策を以下に示す。
【０３４２】
ＳｅＮＢは、ＭｅＮＢからのＤＣを実行するための処理要求において、該要求が緊急ベアラに対する要求の場合、拒否しない。ＤＣを実行するための処理要求として、例えば、ＳｅＮＢ追加要求およびＳｅＮＢ修正要求などがある。ＭｅＮＢは、緊急ベアラに対してＤＣを行う場合、ＳｅＮＢ追加要求あるいはＳｅＮＢ修正要求に、これらの要求が緊急ベアラであることを示す情報を含める。
【０３４３】
図２１は、実施の形態２の通信システムにおける緊急ベアラに対するＤＣ実行処理のシーケンスの一例を示す図である。
【０３４４】
ＭｅＮＢ、ＳｅＮＢは、ＤＣを実行した場合に用いられるが、ここでは説明を簡略化するために、後にＤＣに用いられるｅＮＢをＭｅＮＢ、ＳｅＮＢと示すこととする。
【０３４５】
まず、緊急サービスのための緊急ベアラが設立される際の緊急ベアラ関連情報の流れを説明する。
【０３４６】
緊急サービスを行うＵＥは、ステップＳＴ２２０１において、ＮＡＳメッセージとして、アタッチ要求（Attach request）あるいはＰＤＮ接続要求（PDN connectivity request）に、その理由が緊急であることを示す情報（以下「緊急情報」という場合がある）を含めて、ＭＭＥに通知する。本実施の形態では、ＵＥは、ＰＤＮ接続要求（PDN connectivity request）に緊急情報を含めて、ＭＭＥに通知する。
【０３４７】
その際に、ＵＥは、緊急サービスに関するＲＲＣ接続要求メッセージに、緊急情報を含めて、ＭｅＮＢに通知する。例えば、ＲＲＣ接続要求メッセージとして、ＲＲＣ接続設立要求（RRC connection establishment request）メッセージに緊急情報を含めて、ＭｅＮＢに通知する。
【０３４８】
ＭｅＮＢは、緊急情報を用いて、該要求が緊急サービス用か否かを判断する。該要求が緊急サービス用である場合、ＭｅＮＢは、通常のベアラで行うアクセス制限を行わずに、該要求を受理する。
【０３４９】
ＭｅＮＢは、Ｓ１メッセージとして、初期ＮＡＳメッセージ（initial NAS message）に、緊急情報を含めて、ＭＭＥに通知する。ＭＭＥは、初期ＮＡＳメッセージの緊急情報、またはアタッチ要求（Attach request）あるいはＰＤＮ接続要求（PDN connectivity request）に含まれる緊急情報を用いて、これらの要求が緊急サービス用か否かを判断する。
【０３５０】
緊急サービス用である場合、ＭＭＥは、緊急サービス用のＰ−ＧＷ（緊急用Ｐ−ＧＷ）を選択する。そして、ＭＭＥは、緊急用Ｐ−ＧＷのアドレスを導出する。
【０３５１】
ＭＭＥは、ステップＳＴ２２０２において、Ｓ１１メッセージとして、セッション作成要求（create session request）メッセージに緊急用Ｐ−ＧＷのアドレスを含めて、Ｓ−ＧＷに通知する。Ｓ−ＧＷは、ステップＳＴ２２０３において、緊急用Ｐ−ＧＷのアドレスを用いて、緊急用Ｐ−ＧＷに対して、Ｓ５メッセージとして、セッション作成要求（create session request）を通知する。
【０３５２】
緊急用Ｐ−ＧＷは、ステップＳＴ２２０４において、ＰＣＲＦ（Policy and charging rules function）から、緊急サービス用ＡＲＰ（Allocation and Retention Priority）値を得る。
【０３５３】
緊急サービス用ＡＲＰ値を得た緊急用Ｐ−ＧＷは、該ＡＲＰ値を用いて、ＥＰＳベアラ用ＱｏＳ関連情報を導出する。ＥＰＳベアラ用ＱｏＳ関連情報としては、ＱＣＩ、ＡＲＰ、ＧＢＲ、ＭＢＲがある。
【０３５４】
緊急用Ｐ−ＧＷは、ステップＳＴ２２０５において、セッション作成応答（create session response）メッセージにＥＰＳベアラ用ＱｏＳ関連情報を含めて、Ｓ−ＧＷに通知する。Ｓ−ＧＷは、ステップＳＴ２２０６において、セッション作成応答（create session response）メッセージにＥＰＳベアラ用ＱｏＳ関連情報を含めて、ＭＭＥに通知する。ＭＭＥは、受信した、ＥＰＳベアラ用ＱｏＳ関連情報から、Ｅ−ＲＡＢ（E-UTRAN Radio Access Bearer）レベルＱｏＳ情報を導出する。
【０３５５】
ステップＳＴ２２０７において、ＭＭＥは、Ｅ−ＲＡＢセットアップ要求（E-RAB setup request）メッセージに、Ｅ−ＲＡＢレベルＱｏＳ情報と該ＡＲＰ値とを含めて、ＭｅＮＢに通知する。通知には、Ｓ１メッセージが用いられる。ＭｅＮＢは、受信したＥ−ＲＡＢレベルＱｏＳ情報をもとに、ＭｅＮＢを介して、Ｓ−ＧＷとＵＥとの間に設けられるＥ−ＲＡＢのための設定を行う。
【０３５６】
ステップＳＴ２２０８において、ＭｅＮＢは、受信したＥ−ＲＡＢレベルＱｏＳ情報をもとに、ＲＲＣ接続再設定（RRC connection reconfiguration）メッセージにＥ−ＲＡＢ用のリソース設定を含めて、ＵＥに通知する。
【０３５７】
また、ＭＭＥは、アタッチ応答（attach response）メッセージあるいはＰＤＮ接続アクセプト（PDN connectivity accept）メッセージに、ＡＲＰを除くＥＰＳベアラ用ＱｏＳ関連情報を含めて、ＵＥに通知する。アタッチ応答メッセージあるいはＰＤＮ接続アクセプトメッセージは、個別ＥＰＳベアラコンテキスト要求アクティブ化（ACtivate Dedicated EPS Bearer Context Request）メッセージであってもよい。
【０３５８】
ＲＲＣ接続再設定（RRC connection reconfiguration）メッセージでＥ−ＲＡＢ用のリソース設定を受信したＵＥは、Ｅ−ＲＡＢのためのリソース設定を行い、ステップＳＴ２２０９において、ＭｅＮＢに対して、ＲＲＣ接続再設定完了（RRC connection reconfiguration complete）メッセージを通知する。
【０３５９】
Ｅ−ＲＡＢのための設定を行ったＭｅＮＢは、ステップＳＴ２２１０において、ベアラセットアップ応答（Bearer Setup Response）メッセージをＭＭＥに通知する。
【０３６０】
また、ＮＡＳメッセージであるアタッチ応答（Attach Response）メッセージあるいはＰＤＮ接続アクセプト（PDN Connectivity Accept）メッセージを受信したＵＥは、ステップＳＴ２２１１のダイレクト転送（Direct Transfer）メッセージおよびステップＳＴ２２１２のＰＤＮ接続完了（PDN Connectivity Complete）メッセージで、ＭＭＥに対してＰＤＮ接続（PDN connectivity）の完了を通知する。
【０３６１】
ステップＳＴ２２１３において、パス設定処理が行われる。これによって、緊急ベアラ（Emergency Bearer）の設定が行われ、ステップＳＴ２２１４で示すように、緊急ベアラに対するＵＬ／ＤＬデータの通信が可能となる。
【０３６２】
緊急ベアラにおいて、ＤＣを実行する方法について開示する前に、従来のＤＣを実行する方法について説明する。
【０３６３】
ＵＥに対してＤＣを行うことを決定したＭｅＮＢは、該ＵＥに対してＭｅＮＢで提供されるリソースとＳｅＮＢで提供されるリソースの合計が、ＭＭＥから要求されたＥ−ＲＡＢレベルのＱｏＳが保証されるように、あるいはそれ以上となるように、ＳｅＮＢに対してリソースの要求を行う。
【０３６４】
したがって、ＭｅＮＢは、ＭＭＥから要求されたＥ−ＲＡＢレベルのＱｏＳ情報と異なる値をＳｅＮＢに設定する場合が生じる。ＭｅＮＢは、ＳｅＮＢに対するＤＣ実行要求メッセージ、例えば、ＳｅＮＢ追加要求メッセージに、ＳｅＮＢに要求するＥ−ＲＡＢレベルのＱｏＳ情報を含めて、ＳｅＮＢに通知する（非特許文献９参照）。
【０３６５】
現在３ＧＰＰで議論されているＤＣを実行する場合のＳｅＮＢ追加要求は、以上のとおりである。
【０３６６】
しかし、この方法では、ＳｅＮＢは、ＭｅＮＢからＤＣ実行を要求されたベアラが、緊急サービス用か否かを認識することができない。これは、ＳｅＮＢに対するリソース要求をＭｅＮＢが設定するので、ＭｅＮＢがＤＣ実行要求メッセージにＡＲＰ値を含めるかどうかが明確でないためである。また、たとえ、ＤＣ実行要求メッセージに、ＡＲＰ値を含めて要求したとしても、該ＡＲＰが緊急サービス用のＡＲＰ値ではない場合も生じるためである。
【０３６７】
このように、緊急ベアラに対するＳｅＮＢ追加処理であることを認識しないＳｅＮＢは、自ＳｅＮＢの状況によって拒否してしまい、緊急サービスを提供するＵＥに対して、ＤＣの実行が不可能となってしまう。
【０３６８】
このような課題を解決するための方法を開示する。
【０３６９】
ＭｅＮＢは、ＳｅＮＢに対するＤＣ実行要求メッセージに、該要求が緊急ベアラに対するＤＣ実行要求であることを示す情報を含める。緊急ベアラに対するＤＣ実行要求を受信したＳｅＮＢは、ＤＣ実行要求を拒否しない。すなわち、ＤＣの実行を許可する。
【０３７０】
緊急ベアラに対してＤＣを実行する方法の一例を、図２１を用いて説明する。
【０３７１】
前述のように、ステップＳＴ２２１４において、緊急ベアラに対するＵＬ／ＤＬデータの通信が行われている。ステップＳＴ２２１５において、ＭｅＮＢは、ＳｅＮＢに対するＤＣ実行要求メッセージ、例えば、ＳｅＮＢ追加要求メッセージをＳｅＮＢに通知する。
【０３７２】
このとき、該ＳｅＮＢに対するＤＣ実行要求メッセージ、例えば、ＳｅＮＢ追加要求メッセージに、該要求が緊急ベアラに対してであることを示す情報を含めて通知する。ＳｅＮＢに要求するＥ−ＲＡＢレベルのＱｏＳ情報とともに、該要求が緊急ベアラに対してであることを示す情報を含めて通知してもよい。または、ＤＣ実行要求が緊急ベアラに対するものであることを示す情報を通知するための新たなメッセージを設けてもよい。
【０３７３】
ＭｅＮＢは、ＳｅＮＢに対して、緊急ベアラに対するＤＣ実行要求を行う際に、該新たなメッセージも通知するとよい。該情報の通知には、Ｘ２インタフェースあるいはＸｎインタフェースを用いるとよい。また、該情報を、インジケーション（indication）としてもよいし、理由（cause）情報としてもよい。
【０３７４】
このようにすることによって、ＳｅＮＢは、該要求が緊急ベアラに対するＤＣ実行要求メッセージであることを認識することができる。ステップＳＴ２２１５において、緊急ベアラに対するものであることを示す情報を受信したＳｅＮＢは、該情報を用いて、該要求が緊急ベアラに対するＤＣ実行要求か否かを判断する。
【０３７５】
該要求が緊急ベアラに対するＤＣ実行要求でない場合、ＳｅＮＢは、自ＳｅＮＢあるいはＳＣＧセルの状況に応じて、該要求を拒否するか受理するかを決定する。該要求が緊急ベアラに対するＤＣ実行要求の場合、ＳｅＮＢは、該要求に対して拒否を行わない。すなわち、該要求を受理する。
【０３７６】
図２１では、要求が緊急ベアラに対するＤＣ実行要求である場合を示しているので、ＳｅＮＢは、ＤＣ実行要求に対して拒否を行わず、受理する。
【０３７７】
ＳｅＮＢは、ステップＳＴ２２１６において、ＤＣ実行要求応答、例えば、ＳｅＮＢ追加要求応答を、ＭｅＮＢに通知する。ＭｅＮＢは、ステップＳＴ２２１７において、ＵＥに対して、ＲＲＣ接続再設定（RRC Connection Reconfiguration）メッセージによって、ＤＣを実行させるための無線リソースの設定を行う。
【０３７８】
ＳｅＮＢを使用したＤＣのための無線リソースの設定を行ったＵＥは、ステップＳＴ２２１８において、ＭｅＮＢに対して、ＲＲＣ接続再設定完了（RRC Connection Reconfiguration Complete）メッセージによって、該設定の完了を通知する。
【０３７９】
ＭｅＮＢは、ステップＳＴ２２１９において、ＳｅＮＢに対して、ＳｅＮＢ再設定完了（SeNB Reconfiguration Complete）メッセージによって、ＳｅＮＢを使用したＤＣのための無線リソースの設定が完了したことを通知する。以上のようにすることによって、ステップＳＴ２２０２において、ＭｅＮＢ、ＳｅＮＢ、ＵＥ間で、緊急ベアラに対するＤＣ実行処理が行われる。
【０３８０】
また、ステップＳＴ２２１５において、ＭｅＮＢは、ＳｅＮＢに、緊急ベアラのＤＣ実行要求メッセージ、例えば、ＳｅＮＢ追加（SeNB addition）要求あるいはＳｅＮＢ修正（SeNB modification）要求の際に、緊急ベアラ用のベアラ設定を通知してもよい。つまり、ＭｅＮＢ自体が設定されたのと同じベアラ設定をＳｅＮＢに要求してもよい。
【０３８１】
言い換えると、ＭｅＮＢは、緊急ベアラのためのＳｅＮＢへのリソース要求のために、ＭＭＥから要求されたＥ−ＲＡＢレベルのＱｏＳ情報と異なる値をＳｅＮＢに設定しない。すなわち、同じ値をＳｅＮＢに設定する。
【０３８２】
例えば、ＭｅＮＢは、ＭＭＥから通知された緊急ベアラ用のＥ−ＲＡＢレベルのＱｏＳ情報をＳｅＮＢに設定して、ＤＣ実行要求を行う。緊急ベアラ用のＥ−ＲＡＢレベルのＱｏＳ情報としてＡＲＰ値を含めてもよい。
【０３８３】
このようにすることによって、ＳｅＮＢは、緊急ベアラに対するＤＣ実行要求であることを認識することが可能となるので、緊急ベアラに対しては拒否を行わないようにすることによって、自ＳｅＮＢあるいはＳＣＧセルの状況によって拒否してしまう場合を無くすことができる。したがって、緊急サービスを提供するＵＥに対してＤＣを実行可能とすることができる。
【０３８４】
また、ステップＳＴ２２１５において、ＭｅＮＢは、ＳｅＮＢに、緊急ベアラのＤＣ実行要求メッセージ、例えば、ＳｅＮＢ追加（SeNB addition）要求あるいはＳｅＮＢ修正（SeNB modification）要求の際に、緊急ベアラ用であることを示すＡＲＰ値を通知してもよい。ＳｅＮＢは、緊急ベアラのためのＡＲＰ値を、予め認識しておくとよい。例えば、規格で予め静的に決められていてもよい。あるいは、オペレータによって設定しておいてもよい。
【０３８５】
他の方法として、Ｐ−ＧＷは、ＰＣＲＦから緊急ベアラ用のＡＲＰ値を取得し、ＭＭＥを介してＳｅＮＢに通知してもよい。また、他の方法として、ＭＭＥは、Ｐ−ＧＷから緊急ベアラ用のＡＲＰ値を取得し、ＭＭＥからＳｅＮＢに通知しておいてもよい。該ＡＲＰ値を緊急ベアラ専用としてもよい。
【０３８６】
このようにすることによって、要求が緊急ベアラに対するものであることを示す情報を用いずに、ＳｅＮＢは、ＡＲＰ値で判断することが可能となる。したがって、該情報をＭｅＮＢからＳｅＮＢに通知する必要がなくなるので、Ｘ２あるいはＸｎ間の情報量を削減することができる。
【０３８７】
実施の形態２  変形例１．
ＳｅＮＢが緊急ベアラの設立を許可していない場合がある。例えば、地域毎の規則（local regulation）、およびオペレータの意向（operator's policy）による場合などである。このような場合、例えばＭｅＮＢがＳｅＮＢに対して緊急ベアラに対するＤＣ実行要求であることを示したとしても、ＳｅＮＢは受理することはできない。
【０３８８】
実施の形態２で開示した方法では、このような場合もＳｅＮＢは拒否することはできなくなってしまう、という問題が生じる。
【０３８９】
本変形例では、このような課題を解決する方法を開示する。
【０３９０】
ＳｅＮＢが緊急ベアラの設立を許可していない場合、ＳｅＮＢは、ＭｅＮＢからのＤＣ実行要求、例えば、ＳｅＮＢ追加（SeNB addition）要求あるいはＳｅＮＢ修正（SeNB modification）要求において、該要求が緊急ベアラに対する要求の場合、拒否する。ＳｅＮＢは、ＭｅＮＢに対して、拒否（Reject）メッセージを通知するとよい。該メッセージに、拒否の理由情報を含めるとよい。拒否の理由情報として、緊急ベアラの設立を許可していなことを示す情報を設けておくとよい。ＳｅＮＢが緊急ベアラの設立を許可していない場合に、ＳｅＮＢは、ＭｅＮＢからの緊急ベアラに対するＤＣ実行要求に対して、拒否する場合、拒否メッセージに、緊急ベアラの設立を許可していなことを示す情報を含めて、ＭｅＮＢに通知するとよい。緊急ベアラの設立を許可していなことを示す情報を受信したＭｅＮＢは、ＵＥに対して、該ＳｅＮＢを用いてＤＣを行わない。
【０３９１】
拒否メッセージを受信したＭｅＮＢは、他のＳｅＮＢを用いてＤＣを実行することを判断可能となる。拒否メッセージを受信したＭｅＮＢが、他のＳｅＮＢを用いてＤＣを実行させるようにするために、拒否メッセージを受信したＭｅＮＢは、拒否メッセージを通知したＳｅＮＢに対して、所定の期間ＤＣ実行要求を行うことを禁止してもよい。これにより、無駄なＤＣ実行要求メッセージを通知しなくて済むので、シグナリング量の削減を図ることができる。
【０３９２】
所定の期間は、予め静的に決められていてもよい。例えば、規格で決めておいてもよい。予め決めておくことで、処理を簡易にすることが可能となる。あるいは、ＳｅＮＢが拒否メッセージに含めてＭｅＮＢに通知してもよい。この場合、ＳｅＮＢがその時の状況に応じて柔軟に所定の期間を設定できる。通信システムの柔軟な運用を可能にする。なお、前述の方法は、緊急ベアラの設立を許可していなことによる拒否メッセージに限らず適用できる。
【０３９３】
本変形例で示した課題を解決する他の方法を開示する。
【０３９４】
ＳｅＮＢが緊急ベアラの設立を許可していない場合も、一旦、ＳｅＮＢは、ＭｅＮＢに、ＤＣ実行要求応答メッセージを通知する。該ＤＣ実行要求応答メッセージに、緊急ベアラの設立を許可していなことを示す情報を含めておく。ＭｅＮＢは、ＳｅＮＢから緊急ベアラの設立を許可していないことを示す情報を受信した場合、ＳｅＮＢに対して、ＤＣ実行リリースメッセージ、例えば、ＳｅＮＢリリース（SeNB Release）メッセージを通知する。また、ＭｅＮＢは、ＵＥに対して、ＲＲＣ接続再設定メッセージを通知しない。これにより、ＭｅＮＢは、該ＳｅＮＢを緊急ベアラ用のＤＣに用いない。この方法は、実施の形態２で開示した方法に限らず、従来の、ＳｅＮＢは、ＭｅＮＢからＤＣ実行を要求されたベアラが、緊急サービス用か否かを認識することができない場合にも適用することができる。
【０３９５】
本変形例で示した課題を解決する他の方法を開示する。
【０３９６】
ＳｅＮＢは、予め、自セルが緊急ベアラの設立を許可していないことを示す情報を周辺のｅＮＢに通知してもよい。周辺のｅＮＢとしては、ＤＣする可能性のあるｅＮＢとしてもよい。ＭＭＥを介して周辺のｅＮＢに通知してもよい。ＭｅＮＢは、該情報を用いて、該ＳｅＮＢに対して緊急ベアラのＤＣを行うかどうかを判断する。ＳｅＮＢが緊急ベアラの設立を許可していない場合、該ＳｅＮＢを用いて緊急ベアラに対するＤＣを行わないようにする。この方法も、実施の形態２で開示した方法に限らず、従来の、ＳｅＮＢは、ＭｅＮＢからＤＣ実行を要求されたベアラが、緊急サービス用か否かを認識することができない場合にも適用できる。
【０３９７】
ＭＭＥが、ＳｅＮＢが緊急ベアラの設立を許可していないことを認識している場合、予め、ＭＭＥがＳｅＮＢとＤＣを行う可能性のあるＭｅＮＢに対して、該ＳｅＮＢの識別子と、該ＳｅＮＢが緊急ベアラの設定を許可していなことを示す情報とを通知してもよい。これによって、ＭｅＮＢは、該情報を用いて、該ＳｅＮＢに対して緊急ベアラのＤＣを行うかどうかを判断する。ＳｅＮＢが緊急ベアラの設立を許可していない場合、該ＳｅＮＢを用いて緊急ベアラに対するＤＣを行わないようにする。
【０３９８】
これらの方法によって、ＳｅＮＢが緊急ベアラの設立を許可していない場合に、ＳｅＭＢが緊急ベアラのためのリソースを割当てないようにすることが可能となる。地域毎の規則（local regulation）、およびオペレータの意向（operator's policy）を反映したシステムを構築することができる。
【０３９９】
実施の形態２  変形例２．
緊急ベアラに対して、ＤＣをサポートさせようとすると、実施の形態２および実施の形態２の変形例１で示したような付加的な処理が必要となるので、システムとして処理の複雑さが増す。処理が複雑になると、システムの安定性が劣化してしまう。
【０４００】
本変形例では、安定なシステムを構築するための方法を開示する。
【０４０１】
緊急ベアラに対しては、ＤＣを行わない。ｅＮＢは、ＤＣの実行を判断する際に、ＤＣの実行を行うべきベアラが、緊急ベアラか否かを判断する。緊急ベアラの場合、ＤＣを行わない。すなわち、ｅＮＢは、ＤＣ実行処理を起動しない。緊急ベアラでない場合、ＤＣを行う。すなわち、ｅＮＢは、ＤＣ実行処理を可能とする。
【０４０２】
このように、緊急ベアラに対してはＤＣを行わないとすることによって、安定なシステムを構築することが可能となる。
【０４０３】
緊急ベアラに対しては、ＤＣをサポートするか否かを通信システムの状況に応じて適宜使い分けられるようにしてもよい。
【０４０４】
例えば、高スループットの要求が低い場所（混雑していない場所）などでは、緊急ベアラに対してＤＣサポートするよりも安定なシステムを構築した方がよい場合がある。したがって、高スループットの要求が高い場所では、緊急ベアラに対してＤＣを実行可能とし、高スループットの要求が低い場所では、緊急ベアラに対してＤＣの実行を行わないとする。スループットの要求に閾値を設けておき、ｅＮＢは該閾値に基づいて判断してもよい。該閾値は、予め規格などで静的に決められていてもよいし、ＭＭＥがｅＮＢに通知するようにしてもよい。
【０４０５】
このようにすることによって、緊急ベアラに対するＤＣの実行を通信システムの状況に応じて変えることが可能となるので、通信システムの状況に応じた柔軟な運用が可能となる。
【０４０６】
また、緊急ベアラに対しては、ＤＣをサポートするか否かをＵＥの消費電力に応じて適宜使い分けられるようにしてもよい。
【０４０７】
例えばアーキテクチャ３ＣによるＤＣが実行されると、ＵＥは、ＭｅＮＢおよびＳｅＮＢの両方と通信を行う必要があるので、ＵＥの消費電力が増大する。ＵＥの電池切れにより緊急サービスが中断することは避けたい。状況に応じてできる限りＵＥの消費電力を抑える必要がある。したがって、ＵＥの電池残量が高い場合は、緊急ベアラに対してＤＣを実行可能とし、ＵＥの電池残量が低い場合は、緊急ベアラに対してＤＣの実行を行わないとする。
【０４０８】
ＵＥは、ｅＮＢに対して電池残量情報を送信する。ｅＮＢは、ＵＥの電池残量情報を受信し、該電池残量情報を用いて、緊急ベアラに対してＤＣさせるか否かを判断するとよい。
【０４０９】
ｅＮＢは、ＵＥから電池残量情報を得るために、ＵＥに対して、電池残量情報要求メッセージを通知してもよい。ＲＲＣメッセージで通知してもよい。ＵＥ個別のメッセージで通知してもよい。例えば、ｅＮＢは、ＵＥ情報要求（UE Information Request）メッセージに、電池残量情報の要求情報を含めて、ＵＥに対して通知してもよい。ＵＥ情報要求（UE Information Request）メッセージを受信したＵＥは、ＵＥ情報要求メッセージの中に電池残量情報の要求情報が含まれる場合、ｅＮＢに対して、電池残量情報をＵＥ情報応答（UE Information Response）メッセージに含めて通知する。
【０４１０】
このようにすることによって、ｅＮＢは、ＵＥから電池残量情報を受信することが可能となり、ｅＮＢは、緊急ベアラに対してはＤＣをサポートするか否かをＵＥの消費電力に応じて判断することが可能となる。緊急ベアラに対しては、ＤＣをサポートするか否かをＵＥの消費電力に応じて適宜使い分けられるようになる。
【０４１１】
スモールセルを低消費電力化するために、あるいは、多数のスモールセルが運用された場合の干渉を低減するために、スモールセルをオンあるいはオフすることが検討されている。緊急ベアラに用いるためにスモールセルをオンする処理においては、スモールセルは、自セルをオンする処理を拒否しないようにしておくとよい。また、緊急ベアラにスモールセルが用いられている場合、該スモールセルは、自セルをオフする処理を拒否するようにしておくとよい。この方法として、本実施の形態および変形例で開示した方法を適宜適用するとよい。例えば、スモールセルのオンを要求するメッセージに、緊急ベアラ用であることを示す情報を含める、などである。
【０４１２】
実施の形態３．
実施の形態３で解決する課題、およびその解決策について、以下に示す。
【０４１３】
現在の規格では、設定されたベアラに対して、ＵＥがベアラリソースの修正（allocation or release of resources）の要求を行うことが許可されている（非特許文献１３  ５．４．５参照）。ＵＥは、ＭＭＥを介してＰ−ＧＷに、ベアラに対する修正要求を行う。Ｐ−ＧＷは、ＥＰＳベアラＱｏＳ関連情報を設定することが可能であるので、ＵＥからベアラに対する修正要求を受信したＰ−ＧＷは、ＥＰＳベアラＱｏＳ関連情報、例えば、ＱＣＩまたはＧＢＲまたはＭＢＲまたはＡＲＰの修正を行う。
【０４１４】
ＭＭＥは、Ｐ−ＧＷからＳ−ＧＷを介して通知されたＥＰＳベアラＱｏＳ関連情報に基づいて、ｅＮＢにベアラ設定、すなわち、Ｅ−ＲＡＢセットアップ要求（E-RAB Setup Request）を行う。Ｅ−ＲＡＢレベルのＱｏＳパラメータの設定を行う。したがって、ＭＭＥは、Ｐ−ＧＷがベアラ設定を修正した場合、ｅＮＢに対するベアラ設定を修正する。
【０４１５】
このように、あるベアラに対してＤＣが実行されない場合は、ベアラは一つのｅＮＢを用いて設立されていたため、従来の規格におけるＵＥからのベアラリソースの修正要求により該ベアラの設定修正が可能であった。
【０４１６】
しかし、あるベアラに対してＤＣが実行される場合は、従来の規格におけるＵＥからのベアラリソースの修正要求による該ベアラの設定修正は不可能となる。ＭｅＮＢあるいはＳｅＮＢにおけるＥ−ＲＡＢ設定の修正は不可能である。
【０４１７】
３ＧＰＰにおけるＤＣに関する議論では、ＤＣ実行処理において、ＭｅＮＢは、ＭＭＥから要求されたベアラ設定から、ＳｅＮＢに対して要求するベアラ設定を導出することが議論されている。ＤＣ実行処理において、ＭｅＮＢは、ＭｅＮＢで提供されるリソースとＳｅＮＢで提供されるリソースの合計が、ＭＭＥから要求されたＥ−ＲＡＢレベルのＱｏＳが保証されるように、あるいはそれ以上となるように、ＳｅＮＢに対してリソースの要求を行う。
【０４１８】
したがって、ＭｅＮＢは、ＭＭＥから要求されたＥ−ＲＡＢレベルのＱｏＳ情報と異なる値をＳｅＮＢに設定する場合が生じる。ＭｅＮＢは、ＳｅＮＢに対するＤＣ実行要求メッセージ、例えば、ＳｅＮＢ追加要求メッセージに、ＳｅＮＢに要求するＥ−ＲＡＢレベルのＱｏＳ情報を含めて、ＳｅＮＢに通知する。このように、ＭｅＮＢが、ＳｅＮＢに対して、ＳｅＮＢのベアラ設定を行う。
【０４１９】
従来の規格におけるＵＥからＰ−ＧＷに対するベアラリソースの修正要求では、ＤＣにおいてＭｅＮＢが行うＳｅＮＢのベアラ設定に対してＵＥが修正を要求する仕組みは設けられていない。ＳｅＮＢのベアラ設定、あるいは、ＭｅＮＢとＳｅＮＢのベアラ振り分け設定の修正要求はできないことになる。
【０４２０】
本実施の形態では、このような課題を解決するための方法を開示する。
【０４２１】
ＵＥ起動によるＭｅＮＢおよびＳｅＮＢの少なくともいずれか一方のベアラ（以下「ＤＣ用ベアラ」という場合がある）の修正を可能とする。ＵＥ起動のＤＣ用ベアラ修正処理を設けるとよい。ＵＥ起動のＤＣ用ベアラ修正要求のためのメッセージを設けるとよい。
【０４２２】
ＵＥ起動のＤＣ用ベアラ修正処理について開示する。ＵＥは、ＭｅＮＢに対してＤＣ用ベアラ修正要求を行う。ＵＥは、ＭｅＮＢに対してＤＣ用ベアラ修正要求メッセージを通知する。
【０４２３】
ＤＣ用ベアラ修正要求メッセージに含む情報の例として、以下の（１）〜（１１）の１１個を開示する。
（１）ＤＣ用ベアラ修正要求であることを示す情報。
（２）ベアラを特定するための識別子。例えば、ＥＰＳベアラ識別子。ＥＰＳベアラＩＤ。Ｅ−ＲＡＢ識別子。Ｅ−ＲＡＢ  ＩＤ。
（３）所定のＱｏＳが保てないことを示す情報。
（４）要求するＥ−ＲＡＢレベルＱｏＳ情報。例えば、ＱＣＩ、ＧＢＲ。
（５）ＳｅＮＢのＱｏＳの改善要求を示す情報。例えば、Ｅ−ＲＡＢレベルのＱｏＳの改善要求を示す情報。
（６）ＭｅＮＢのＱｏＳの改善要求を示す情報。例えば、Ｅ−ＲＡＢレベルのＱｏＳの改善要求を示す情報。
（７）ＭｅＮＢとＳｅＮＢのパケットフロー比率修正要求を示す情報。例えば、ＭｅＮＢの比率増大要求を示す情報、ＳｅＮＢの比率増大要求を示す情報。
（８）ＳｅＮＢ識別子。または、ＳＣＧセルの識別子としてもよい。
（９）ＵＥの識別子。
（１０）ＵＥ  ＡＭＢＲ（Aggregate Maximum Bit Rate）。
（１１）前記（１）〜（１０）の組合せ。
【０４２４】
ＵＥからＤＣ用ベアラ修正要求メッセージを受信したＭｅＮＢは、該メッセージに含まれる情報を用いて、ＳｅＮＢのベアラ設定、あるいは、ＭｅＮＢとＳｅＮＢのベアラ振り分け設定の修正を行う。この際、ＭｅＮＢは、ＭｅＮＢで提供されるリソースとＳｅＮＢで提供されるリソースの合計が、ＭＭＥから要求されたＥ−ＲＡＢレベルのＱｏＳが保証されるように、あるいはそれ以上となるようにするとよい。
【０４２５】
ＭｅＮＢは、ＳｅＮＢに対して修正したベアラ設定を実行するために、ＳｅＮＢ修正（SeNB modification）処理を起動する。ＭｅＮＢは、ＳｅＮＢに要求するＥ−ＲＡＢレベルのＱｏＳ情報を含めて、ＳｅＮＢに通知するとよい。
【０４２６】
また、ＭｅＮＢは、ＳｅＮＢに対するベアラ設定を行わないと判断してもよい。言い換えると、ＭｅＮＢは、ＳｅＮＢに対するベアラ設定をリリースすると判断してもよい。これにより、修正の選択肢が増える。ＭｅＮＢは、ＳｅＮＢリリース（SeNB Release）処理を起動するとよい。
【０４２７】
また、ＭｅＮＢは、ＤＣ用ベアラの修正を行わず、ＭｅＮＢとＳｅＮＢのパケットフロー比率の修正を行うようにしてもよい。これにより、修正の選択肢が増えることになる。例えば、ＵＥからＭｅＮＢとＳｅＮＢのパケットフロー比率修正要求を示す情報を受信した場合に適用するとよい。ＭｅＮＢおよびＳｅＮＢの少なくともいずれか一方のベアラ設定を修正する処理を行う必要が無く、簡易な処理で済ませることが可能となる。
【０４２８】
図２２は、実施の形態３の通信システムにおけるＵＥ起動のＤＣ用ベアラ修正処理のシーケンスの一例を示す図である。
【０４２９】
ステップＳＴ２３０１において、ＵＥ、ＭｅＮＢ、ＳｅＮＢ間で、ＳｅＮＢ追加処理が行われ、ＵＥに対して、ＭｅＮＢとＳｅＮＢを用いたＤＣが実行される（非特許文献９参照）。ＤＣアーキテクチャ１Ａの場合は、ＵＥ、ＭｅＮＢ、ＳｅＮＢ、ＭＭＥ、Ｓ−ＧＷ間で、ＳｅＮＢ追加処理が行われ、ＵＥに対して、ＭｅＮＢとＳｅＮＢを用いたＤＣが実行される。
【０４３０】
この際、前述のように、ＭｅＮＢは、ＳｅＮＢのベアラ設定、あるいは、ＭｅＮＢとＳｅＮＢのベアラ振り分け設定を行う。
【０４３１】
ステップＳＴ２３０２において、ＵＥは、ベアラの修正を要求するか否かを判断する。該ベアラに対して所望のＱｏＳが得られているか否かを判断してもよい。あるいは、ＭｅＮＢのベアラに対するＱｏＳ、または、ＳｅＮＢのベアラに対するＱｏＳが得られているか否かを判断してもよい。
【０４３２】
ベアラ修正の要求が必要無いと判断したＵＥは、現在実行されているＤＣを引き続き行う。
【０４３３】
ベアラの修正を要求すると判断したＵＥは、ステップＳＴ２３０３において、ＤＣ用ベアラ修正要求をＭｅＮＢに対して通知する。ＤＣ用ベアラ修正要求のためのメッセージを設けて通知するとよい。該要求は、ＲＲＣメッセージを用いて通知するとよい。ＵＥ個別のシグナリングとするとよい。ＵＥは、ＤＣ用ベアラ修正要求メッセージに、前述した情報を含ませてもよい。
【０４３４】
ステップＳＴ２３０３において、ＤＣ用ベアラ修正要求のためのメッセージを受信したＭｅＮＢは、ステップＳＴ２３０４において、該メッセージに含まれる情報を用いて、ＳｅＮＢのリソース設定の修正を行う。ＳｅＮＢのリソース設定の修正として、ベアラ設定、あるいは、ＭｅＮＢとＳｅＮＢのベアラ振り分け設定の修正を行う。ベアラ設定として、Ｅ−ＲＡＢレベルのＱｏＳ情報を設定してもよい。また、この際、ＭｅＮＢは、ＭｅＮＢで提供されるリソースとＳｅＮＢで提供されるリソースの合計が、ＭＭＥから要求されたＥ−ＲＡＢレベルのＱｏＳが保証されるように、あるいはそれ以上となるようにする。
【０４３５】
ステップＳＴ２３０５において、ＭｅＮＢは、ＳｅＮＢに対して修正したベアラ設定を実行するために、ＳｅＮＢ修正処理を起動する。ＭｅＮＢは、ＳｅＮＢに要求するＥ−ＲＡＢレベルのＱｏＳ情報を含めて、ＳｅＮＢに通知するとよい。これにより、ＵＥ、ＭｅＮＢ、ＳｅＮＢ間で、ＳｅＮＢ修正処理が行われる。ＤＣアーキテクチャ１Ａの場合は、ＵＥ、ＭｅＮＢ、ＳｅＮＢ、ＭＭＥ、Ｓ−ＧＷ間で、ＳｅＮＢ修正処理が行われる。このＳｅＮＢ修正処理により、ＳｅＮＢのリソース設定の修正が行われる。
【０４３６】
このようにすることによって、ＵＥがＤＣ用ベアラリソースの修正要求を行うことが可能となる。
【０４３７】
ＤＣ用ベアラ修正が行われない場合、ＭｅＮＢは、ＵＥに対して、拒否メッセージを通知する。
【０４３８】
ＤＣ用ベアラ修正が行われない場合として、例えば、ＭｅＮＢが判断する場合がある。例えば、ＭｅＮＢが、ＵＥからＤＣ用ベアラ修正要求メッセージを受信したときに、該メッセージに含まれる情報から示されるＵＥからの要求を、ＳｅＮＢのリソース設定の修正では満たせないと判断したような場合である。
【０４３９】
このような場合は、ＭｅＮＢは、ＵＥに対して、ＤＣ用ベアラ修正要求に対する拒否メッセージを通知してもよい。
【０４４０】
また、ＭｅＮＢは、ＭｅＮＢ起動のＳｅＮＢ修正処理において、ＳｅＮＢから修正拒絶メッセージを受信した場合、ＵＥからのＤＣ用ベアラ修正要求を満たせないと判断して、ＵＥに対して、ＤＣ用ベアラ修正要求に対する拒否メッセージを通知してもよい。
【０４４１】
このように、ＵＥに対して拒否メッセージを通知することによって、ＵＥは、ＤＣ用ベアラ修正が行われないことを認識できる。ＵＥは、他のベアラ修正の手段、例えば、従来のＵＥ起動のＥＰＳベアラ修正要求などを実行するための判断に用いることができる。
【０４４２】
拒否メッセージに理由情報を含ませてもよい。理由情報の例として、以下の（１）〜（９）の９つを開示する。
（１）ＵＥ起動のＤＣ用ベアラ修正をサポートしていない。
（２）ＭｅＮＢとＳｅＮＢの合計のリソース不足。
（３）ＭｅＮＢのリソース不足。
（４）ＳｅＮＢのリソース不足。
（５）要求されたＥＰＳレベルのＱｏＳが受理されない。
（６）無効なＥＰＳベアラ識別子。
（７）無効なＥ−ＲＡＢ識別子。
（８）サポートしていないＱＣＩ値。
（９）ＳｅＮＢ修正要求に対する拒否。この場合、拒否の理由情報を含めてもよい。
【０４４３】
拒否メッセージを受信したＵＥは、所定の期間ＤＣ用ベアラ修正要求を行うことを禁止してもよい。
【０４４４】
これにより、無駄なＤＣ用ベアラ修正要求メッセージを通知しなくて済むため、シグナリング量の削減を図ることができる。
【０４４５】
所定の期間は、予め静的に決められていてもよい。例えば、規格で決めておいてもよい。予め決めておくことで、処理を簡易にすることが可能となる。
【０４４６】
あるいは、ＭｅＮＢが拒否メッセージに含めてＵＥに通知してもよい。この場合、ＭｅＮＢがそのときの状況に応じて、柔軟に所定の期間を設定できる。通信システムの柔軟な運用を可能にする。
【０４４７】
ＭｅＮＢは、ＳｅＮＢからＳｅＮＢ修正拒絶メッセージを受信した場合、ＵＥからのＤＣ用ベアラ修正要求を満たせないと判断して、ＵＥに対して、ＤＣ用ベアラ修正要求に対する拒否メッセージを通知してもよいことを開示した。
【０４４８】
他の方法として、ＭｅＮＢは、ＳｅＮＢからＳｅＮＢ修正拒絶メッセージを受信した場合、ＵＥからのＤＣ用ベアラ修正要求を満たせないと判断して、ＤＣに用いるＳｅＮＢの変更を起動してもよい。ＵＥに対してＤＣ可能な他のＳｅＮＢがある場合、該ＳｅＮＢへの変更処理を起動してもよい。これにより、ＵＥからのＤＣ用ベアラ修正要求を満たすことが可能となる。
【０４４９】
実施の形態３  変形例１．
本変形例では、実施の形態３の課題を解決するための他の方法を開示する。
【０４５０】
ＵＥは、ＭＭＥを介して、ＭｅＮＢに対してＤＣ用ベアラ修正要求を行う。ＵＥは、ＭＭＥに対してＤＣ用ベアラ修正要求メッセージを通知する。
【０４５１】
該ＤＣ用ベアラ修正要求メッセージに含む情報として、実施の形態３で開示した情報を適用できる。その他の該情報の例を以下に開示する。
【０４５２】
（１）ＤＣを実行しているＭｅＮＢの識別子。または、ＰＣｅｌｌの識別子としてもよい。この情報は、実施の形態３で開示した情報と組合せて適用してもよい。
【０４５３】
例えばＤＣアーキテクチャ３Ｃでは、ＭＭＥは、ＤＣが実行されていることを認識しなくてもよい。したがって、そのような場合、ＭＭＥは、ＵＥからＤＣ用ベアラ修正要求メッセージを受信したとしても、それに応じた処理を行うことが不可能となる。
【０４５４】
ＵＥからＤＣ用ベアラ修正要求メッセージを受信したＭＭＥが、上記に開示した（１）の情報を用いることで、該ＤＣを実行しているＭｅＮＢを認識することが可能となる。
【０４５５】
ＵＥからＤＣ用ベアラ修正要求メッセージを受信したＭＭＥは、ＤＣを実行しているＭｅＮＢに対して、ＤＣ用ベアラ修正要求メッセージを通知する。該ＤＣ用ベアラ修正要求メッセージに含む情報として、実施の形態３で開示した情報を適用できる。
【０４５６】
ＤＣ用ベアラ修正要求メッセージをＭＭＥから受信したＭｅＮＢは、該メッセージに含まれる情報を用いて、ＳｅＮＢのベアラ設定、あるいは、ＭｅＮＢとＳｅＮＢのベアラ振り分け設定の修正等を行う。これらの処理は実施の形態３で開示した方法を適用するとよい。
【０４５７】
図２３は、実施の形態３の通信システムにおけるＵＥ起動のＤＣ用ベアラ修正処理のシーケンスの他の例を示す図である。図２２と同一のステップには同一の番号を付して共通の説明を省略する。
【０４５８】
ステップＳＴ２３０２において、ベアラの修正を要求すると判断したＵＥは、ステップＳＴ２４０１において、ＤＣ用ベアラ修正要求をＭＭＥに対して通知する。ＤＣ用ベアラ修正要求のためのメッセージを設けて通知するとよい。該要求はＮＡＳメッセージとしてもよい。また、該要求は、ＭｅＮＢを介してＭＭＥに通知してもよい。ＵＥからはＭｅＮＢ間はＲＲＣメッセージを用いて、ＭｅＮＢからＭＭＥ間はＳ１メッセージを用いて通知してもよい。
【０４５９】
ＵＥ個別のシグナリングとするとよい。ＵＥは、ＤＣ用ベアラ修正要求メッセージに、前述した情報を含ませるとよい。
【０４６０】
ステップＳＴ２４０１において、ＤＣ用ベアラ修正要求のためのメッセージを受信したＭＭＥは、該メッセージに含まれる情報を用いて、ＤＣ用ベアラ修正要求であること、該ＤＣを実行するＭｅＮＢなどを認識する。
【０４６１】
ステップＳＴ２４０２において、ＭＭＥは、ＤＣを実行するＭｅＮＢに対して、ＤＣ用ベアラ修正要求メッセージを通知する。該要求はＳ１メッセージとしてもよい。ＵＥ個別のシグナリングとするとよい。ＭＭＥは、該ＤＣ用ベアラ修正要求メッセージに、実施の形態３で開示した情報を含ませるとよい。
【０４６２】
これによって、ＭｅＮＢは、ＵＥからのＤＣ用ベアラ修正要求メッセージを受信する。
【０４６３】
ステップＳＴ２４０２において、ＭｅＮＢがＤＣ用ベアラ修正要求メッセージを受信した後の処理は、実施の形態３と同様なので説明を省略する。
【０４６４】
これによって、実施の形態３と同様に、ＵＥがＤＣ用ベアラリソースの修正要求を行うことが可能となる。
【０４６５】
ＵＥからＭＭＥへ通知するＤＣ用ベアラ修正要求のためのメッセージに、従来の規格においてＵＥからＭＭＥに通知するＵＥ起動ベアラリソース修正要求（request bearer resource modification）メッセージを用いてもよい。
【０４６６】
この場合、従来の内容と区別するため、該メッセージに、ＤＣ用ベアラ修正要求であることを示す情報、該ＤＣを実行しているＭｅＮＢの識別子情報を含めるとよい。また、実施の形態３および前述に開示した情報を含めてもよい。
【０４６７】
ＭＭＥは、これらの情報を用いて、従来の規格の処理であるＰ−ＧＷにベアラリソース修正要求を行うか、ＭｅＮＢに対してＤＣ用ベアラ修正要求を行うかを判断するとよい。例えば、ＤＣ用ベアラ修正要求の場合は、ＭｅＮＢに対してＤＣ用ベアラ修正要求を行い、そうでない場合は、Ｐ−ＧＷにベアラリソース修正要求を行うとよい。
【０４６８】
こうすることによって、新たなＵＥからＭＭＥへのメッセージを設けなくて済み、メッセージ処理が複雑になることを防ぐことが可能となる。
【０４６９】
ＭｅＮＢがＵＥに対して拒否メッセージを通知する場合は、ＭＭＥを介して通知してもよい。この場合、拒否メッセージに、実施の形態３で開示した情報に加えて、ＤＣ用ベアラ修正要求に対する拒否であることを示す情報、ＤＣ用ベアラ修正要求を行ったＵＥの識別子を含めるとよい。ＭＭＥは、該ＵＥに対して、拒否メッセージを通知することが可能となる。
【０４７０】
実施の形態２で、緊急ベアラに対してＤＣを適用可能とする方法を開示したが、緊急ベアラの場合は、ＤＣ用ベアラ変更は実行されない、としてもよい。
【０４７１】
例えば、緊急ベアラに対しては、ＵＥはＤＣ用ベアラ修正要求を行わない、とするとよい。
【０４７２】
他の例として、ＭｅＮＢは、ＵＥから、緊急ベアラに対するＤＣ用ベアラ変更の要求を受信したとしても、拒否するとしてもよい。理由情報として、緊急ベアラのためであることを示す情報を設けて、拒否メッセージに含めてもよい。
【０４７３】
実施の形態４．
実施の形態４で解決する課題、およびその解決策について、以下に示す。
【０４７４】
現在の３ＧＰＰの規格では、ＵＥのロケーション情報に関する機能が存在する。例えば、ＭＤＴ（Minimization of Drive Test）における即時型ＭＤＴ（Immediate MDT）の機能である（３ＧＰＰ  ＴＳ３７．３２０  Ｖ１２．０．０（以下「非特許文献１５」という場合がある）参照）。即時型ＭＤＴは、ＲＲＣ＿ＣｏｎｎｅｃｔｅｄのＵＥに適用される。即時型ＭＤＴは、ＲＲＣのメジャメント処理を用いて行われる。ＵＥは、メジャメント設定（Measurement Configuration）で、メジャメントリポートにロケーション情報（location information）を含めるかどうか設定される。設定された場合、ＵＥはメジャメントリポートにロケーション情報を含めてｅＮＢに通知する。
【０４７５】
また、ＵＥは、ｅＮＢから、所定の情報（obtain Location）を含む、他の設定用メッセージ（OtherConfig）が通知されると、メジャメントリポート送信時、ロケーション情報に、ＧＮＳＳ（Global Navigation Satellite System）を用いた詳細のロケーション情報（detailed location information）を含めて通知する。
【０４７６】
ＵＥは、非常に精度の高いＧＮＳＳを用いて詳細のロケーション情報の測定を行う。しかし、ＧＮＳＳを用いるので、屋内（indoor）環境、例えば、地下街および地下駐車場などでは、測定が不可能となってしまう。したがって、このような場合、他の精度の高いロケーション情報が必要となる。
【０４７７】
本実施の形態では、このような課題を解決する方法を開示する。
【０４７８】
ＤＣ実行中のＵＥは、メジャメント設定で、メジャメントリポートにロケーション情報を含めるように設定された場合、メジャメントリポートに、ロケーション情報としてＳｅＮＢの識別子を含めて、ＭｅＮＢに通知する。ＳｅＮＢの識別子として、グローバルなｅＮＢ識別子（Global eNB ID）を設定してもよい。あるいは、ロケーション情報としてＳＣＧセルの識別子を含めてＭｅＮＢに通知してもよい。セルの識別子としてＣＧＩあるいはＰＣＩを設定してもよい。
【０４７９】
ＳＣＧセルの具体例として、以下の（１）〜（５）の５つを開示する。
（１）ＤＣ用に設定された全ＳＣＧセル。
（２）ＳＰＣｅｌｌ。
（３）最も受信品質（受信電力であってもよい）の良好なＳＣＧセル。
（４）最もパスロスの小さいＳＣＧセル。
（５）最もセルサイズの小さいセル。
【０４８０】
このようにすることによって、ＭｅＮＢはＵＥの位置を、ＳＣＧセルのカバレッジサイズに応じた精度で認識することが可能となる。先に、ＳＣＧセルのカバレッジサイズは比較的小さいことを記した。また、屋内（indoor）環境では、特に小さいカバレッジサイズのＳＣＧセルの運用も想定される。したがって、精度の高いロケーション情報が得られることになる。
【０４８１】
なお、ＭｅＮＢに通知するようにしたが、ＤＣにおいて、ＲＲＣ機能を有するｅＮＢに通知すればよい。
【０４８２】
他の方法を開示する。
【０４８３】
新たに、ＳｅＮＢあるいはＳＣＧセルの識別子の報告を示す情報を設ける。ｅＮＢは、ＵＥに対して、ＲＲＣメッセージで該情報を通知するとよい。他の設定用メッセージ（OtherConfig）に該情報を含めて通知するようにしてもよい。ＤＣ実行中のＵＥは、他の設定用メッセージで、ＳｅＮＢあるいはＳＣＧセルの識別子の報告を示す情報が通知された場合、メジャメントリポートにＳｅＮＢあるいはＳＣＧセルの識別子を含めてＭｅＮＢに通知してもよい。新たに該情報を設けることで、ｅＮＢは明示的に、ＳｅＮＢあるいはＳＣＧセルの識別子の報告要求を行うことが可能となる。この方法を用いることで、ｅＮＢは、適宜、柔軟にＵＥのロケーション情報を得ることが可能となる。
【０４８４】
あるいは、既存の情報を利用してもよい。ＤＣ実行中のＵＥは、他の設定用メッセージで所定の情報（obtain Location）が通知された場合、メジャメントリポートにＳｅＮＢあるいはＳＣＧセルの識別子を含めてＭｅＮＢに通知してもよい。
【０４８５】
また、既存の情報を利用する場合、ＵＥにおいてＧＮＳＳの利用が不可能な場合に、メジャメントリポートにＳｅＮＢあるいはＳＣＧセルの識別子を含めてＭｅＮＢに通知する、としてもよい。
【０４８６】
既存の情報を利用することによって、新たな情報を設ける必要が無くなり、システムとして処理が複雑になることを防ぐことが可能となる。
【０４８７】
また、ＳｅＮＢあるいはＳＣＧセルの識別子を含めてＭｅＮＢに通知するために、メジャメントリポートではなく、他のＲＲＣメッセージを用いてもよい。また、該情報を通知するためのＲＲＣメッセージを新設してもよい。メジャメントリポートとは別のメッセージが用いられることによって、ｅＮＢは、より柔軟にＵＥのロケーション情報を得ることが可能となる。
【０４８８】
本実施の形態で開示した方法を用いることで、ｅＮＢは、ＵＥの詳細なロケーション情報を得ることが可能となる。ｅＮＢは、ＵＥが、どのＳｅＮＢあるいはどのＳＣＧセルのカバレッジ内に位置するかを認識することが可能となる。
【０４８９】
本実施の形態で開示した方法を、無線リンク失敗（Radio Link Failure：ＲＬＦ）またはハンドオーバ失敗（HandOver Failure：ＨＯＦ）が生じた場合に適用してもよい。
【０４９０】
ＤＣ実行中のＵＥがＲＬＦまたはＨＯＦになった場合、該ＵＥは、ＲＬＦ報告（RLF Report）メッセージに、ロケーション情報としてＳｅＮＢあるいはＳＣＧセルの識別子を含めるとよい。
【０４９１】
ＵＥは、ｅＮＢからＲＬＦ報告（RLF Report）要求を含むメッセージを受信した場合、該ロケーション情報を含むＲＬＦ報告（RLF Report）メッセージを、ｅＮＢに通知するとよい。
【０４９２】
例えば、ＲＬＦ報告（RLF Report）要求を含むメッセージとして、ＵＥ情報要求（UE Information Request）メッセージを用いてもよい。ｅＮＢは、ＵＥ情報要求（UE Information Request）メッセージに、ＲＬＦ報告（RLF Report）要求情報を設定して、ＵＥに通知する。該ＲＬＦ報告要求情報を受信したＵＥは、ＵＥ情報応答（UE Information Response）メッセージに、ＳｅＮＢあるいはＳＣＧセルの識別子を含むロケーション情報を含めて、ｅＮＢに通知する。
【０４９３】
このようにすることによって、ｅＮＢは、ＲＬＦまたはＨＯＦが発生したＵＥの詳細なロケーション情報を得ることが可能となる。
【０４９４】
現在の３ＧＰＰの規格では、他にもＵＥのロケーション情報に関する機能が存在する。例えば、ＵＥ  ｐｏｓｉｔｉｏｎｉｎｇ（３ＧＰＰ  ＴＳ３６．３０５参照）、ＬＰＰ（LTE Positioning Protocol）（３ＧＰＰ  ＴＳ３６．３５５参照）、ＬＣＳ（Location Service）（３ＧＰＰ  ＴＳ２３．２７１参照）などである。これらの機能において、ＵＥのロケーション情報として、ＳｅＮＢあるいはＳＣＧセルの識別子を用いるようにしてもよい。ＵＥのロケーションとして、ＤＣ中のＵＥが接続するＳｅＮＢあるいはＳＣＧセルの識別子を用いて導出する。
【０４９５】
ＳｅＮＢを用いてＤＣを行っているＵＥは、該ＳｅＮＢのカバレッジ内に存在する。さらに、ＳＣＧセルまで特定すると、ＳＣＧセルを用いてＤＣを行っているＵＥは、該ＳＣＧセルのカバレッジ内に存在する。したがって、ＤＣ中のＵＥが接続するＳｅＮＢあるいはＳＣＧセルの識別子を用いることによって、該ＵＥのロケーションを導出することができる。前述したように、ＳＣＧセルのカバレッジサイズは比較的小さい。したがって、精度の高いＵＥのロケーション情報が得られることになる。
【０４９６】
例えば、これらの機能で用いられるＥ−ＣＩＤ（Enhanced Cell ID）メカニズムがある。これは、ＵＥの位置を得るために、該ＵＥのサービングｅＮＢあるいはセルの情報を用いる。したがって、ＤＣ中のＵＥにおいては、従来は、ＭｅＮＢあるいはＰＣｅｌｌの情報を用いることとなる。
【０４９７】
新たな方法として、ＤＣ中のＵＥにおいては、ＵＥの位置を得るために、ＤＣ中のＵＥが接続するＳｅＮＢあるいはＳＣＧセルの情報を用いる。ＳｅＮＢあるいはＳＣＧセルの情報として、ｅＮＢの識別子、あるいはセル識別子を用いるとよい。また、ＳｅＮＢあるいはＳＣＧセルとＵＥとの間の送信または受信の時間情報を用いてもよい。例えば、ＵＥの送信と受信との時間差（UE Tx-Rx time difference）を用いてもよい。このようにすることによって、従来のＭｅＮＢを用いたＥ-ＣＩＤ方法よりも精度の高いＵＥのロケーション情報が得られる。
【０４９８】
実施の形態４  変形例１．
実施の形態４の変形例１で解決する課題、およびその解決策について、以下に示す。
【０４９９】
現在の３ＧＰＰの規格では、ＵＥの移動状態に関する機能が存在する。例えば、メジャメント関連パラメータの移動速度依存スケーリング機能（Speed dependent scaling of measurement related parameters）である（３ＧＰＰ  ＴＳ３６．３３１  Ｖ１２．１．０（以下「非特許文献１６」という場合がある）参照）。
【０５００】
ｅＮＢは、ＵＥに対して、メジャメント設定（Measurement Configuration）で、ＵＥの移動速度を表す移動状態（mobility state）のパラメータを設定する。該パラメータとしては、測定期間、ＨＯ回数の閾値、スケーリングファクタがある。該メジャメント設定を受信したＵＥは、測定期間内のＨＯ回数を検出する。ＵＥは、検出したＨＯ回数とＨＯ回数の閾値とを用いて、自ＵＥの移動状態を導出する。移動状態としては、「high」、「medium」、それ以外（以下「normal」とする）がある。自ＵＥの移動状態を導出したＵＥは、移動状態に応じたスケーリングファクタを導出し、メジャメント関連パラメータの値に該スケーリングファクタを乗算して設定する。メジャメント関連パラメータとしては、ＴＴＴ（Time To Trigger）がある。
【０５０１】
このように、従来の規格では、ＵＥは、ＨＯ回数を検出して自ＵＥの移動状態を導出している。
【０５０２】
ＤＣ実行中のＵＥでは、ＭｅＮＢの変更はＨＯで行われるが、ＳｅＮＢの変更はＨＯで行われない。したがって、ＤＣ実行中のＵＥの移動状態はＭｅＮＢを用いて判断される。例えば、ＤＣ実行中のＵＥがＭｅＮＢ内で移動するような場合には、移動状態が「normal」に設定されてしまう。
【０５０３】
しかし、スモールセルは比較的カバレッジが小さい。したがって、ＵＥがＳｅＮＢ間あるいはＳＣＧセル間を移動する場合は、短期間で移動することになる。このような場合、ＵＥの移動状態は、実質的に「normal」とは言えなくなる。
【０５０４】
ＳＣＧセルのメジャメントは、ＭｅＮＢが、ＤＣに用いるＳｅＮＢあるいはＳＣＧセルの設定を判断するために用いられる。ＳＣＧセルのメジャメント関連パラメータの設定に、ＭｅＮＢのＨＯ回数で判断したＵＥの移動状態を用いたのでは不十分となる。ＳＣＧセルのメジャメントには、より精度の高い、言い換えると、スモールセルのカバレッジに適したメジャメント関連パラメータの設定が必要となり、それには、より精度の高いＵＥの移動状態の取得が必要となる。
【０５０５】
本変形例では、より精度の高いＵＥの移動状態を得る方法を開示する。
【０５０６】
ＤＣ実行中のＵＥの移動状態の導出に、ＳｅＮＢの変更回数を用いる。ＤＣ実行中のＵＥは、ＳｅＮＢの変更回数を検出する。ＵＥは、検出したＳｅＮＢの変更回数を記録してもよい。
【０５０７】
ＭｅＮＢは、ＵＥに、ＤＣに用いるＳｅＮＢの追加処理を行う際に、ＳｅＮＢの変更回数のカウントを指示する。ＲＲＣシグナリングで通知するとよい。個別シグナリングを用いてもよい。
【０５０８】
また、ＳｅＮＢの変更回数の検出を指示する情報を、ＲＲＣメッセージに含めて通知してもよい。例えば、ＭｅＮＢは、該情報をＲＲＣ接続再設定（RRC Connection Reconfiguration）メッセージに含めてＵＥに通知してもよい。該情報を「Radio Resource Configuration Dedicated」メッセージに含めて通知してもよい。他の例として、ＭｅＮＢは、該情報を、メジャメント設定に含めてＵＥに通知してもよい。該情報をメジャメントリポート設定に含めて通知してもよい。メジャメント設定として、ＤＣに用いるＳｅＮＢあるいはＳＣＧセルのメジャメント設定としてもよい。
【０５０９】
他の例として、ＭｅＮＢは、ＳｅＮＢに関するＲＲＣ接続再設定（RRC Connection Reconfiguration）を行う際にＵＥに通知してもよい。例えば、ＭｅＮＢは、該情報をＳｅＮＢ追加処理の際にＵＥに通知してもよい。他の例として、ＭｅＮＢは、該情報をＳｅＮＢ変更処理あるいは修正処理の際にＵＥに通知してもよい。他の例として、ＭｅＮＢは、ＳＰＣｅｌｌを変更する際にＵＥに通知してもよい。
【０５１０】
これらの通知方法は組合せて用いてもよい。システムとして柔軟な運用が可能となる。
【０５１１】
ＳｅＮＢの変更回数検出の指示を受信したＵＥは、ＳｅＮＢの変更回数の検出を行い、該検出結果を用いて、自ＵＥの移動状態を導出する。
【０５１２】
ＵＥの移動状態の導出方法の具体例を開示する。ＭｅＮＢは、ＳｅＮＢの変更回数の検出の指示とともに、ＵＥの移動速度を表す移動状態のパラメータを設定する。該パラメータは、ＳｅＮＢに関するパラメータとする。該バラメータとして、測定期間、ＳｅＮＢ変更回数の閾値、スケーリングファクタがある。
【０５１３】
該パラメータ設定を受信したＵＥは、測定期間内のＳｅＮＢの変更回数を検出する。ＵＥは、検出したＳｅＮＢの変更回数とＳｅＮＢ変更回数の閾値とを用いて、自ＵＥの移動状態を導出する。移動状態としては、「high」、「medium」、それ以外（以下「normal」とする）とする。
【０５１４】
このようにすることによって、ＵＥは、自ＵＥの移動状態を導出することができる。
【０５１５】
自ＵＥの移動状態を導出したＵＥは、移動状態に応じたスケーリングファクタを導出し、メジャメント関連パラメータに該スケーリングファクタを乗算する。メジャメント関連パラメータとしては、例えば、ＴＴＴがある。
【０５１６】
ＵＥが検出したＳｅＮＢ変更回数を用いて導出されたスケーリングファクタが乗算されたメジャメント関連パラメータは、ＳｅＮＢあるいはＳＣＧセルのメジャメントに用いられる。
【０５１７】
このようにすることによって、ＵＥは、ＳｅＮＢの変更回数を検出することが可能となり、該検出結果を用いることによって、より精度の高い自ＵＥの移動状態を導出することができる。
【０５１８】
ＳＣＧセルのメジャメントに該移動状態を用いることによって、ＵＥは、より精度の高い、言い換えると、スモールセルのカバレッジに適したメジャメント関連パラメータの設定が可能となる。
【０５１９】
本変形例で開示した方法を用いることによって、ＵＥは、より精度の高い、言い換えると、スモールセルのカバレッジに適したメジャメント関連パラメータの設定が可能となる。ＭｅＮＢは、ＵＥから、より精度の高いＳＣＧセルのメジャメント結果を得られることになる。したがって、ＭｅＮＢは、ＤＣに用いるＳｅＮＢあるいはＳＣＧセルの設定を、ＵＥの移動状態に応じて、より正確に判断することが可能となる。
【０５２０】
これによって、ＵＥのスループットの向上を図ることが可能となり、システムとしての通信容量の向上を図ることも可能となる。
【０５２１】
前述の方法では、ＭｅＮＢは、ＳｅＮＢの変更回数の検出を指示する情報を、ＲＲＣメッセージに含めてＵＥに通知することによって、ＵＥが、ＳｅＮＢの変更回数の検出を行い、ＳＣＧセルのメジャメントに該検出結果を用いるようにした。
【０５２２】
他の方法として、ＭｅＮＢは、ＵＥに、ＳｅＮＢに関するＵＥの移動速度を表す移動状態のパラメータの設定を通知することを、ＳｅＮＢの変更回数の検出の指示としてもよい。ＵＥは、ＳｅＮＢに関するＵＥの移動速度を表す移動状態のパラメータの設定を受信した場合、ＳｅＮＢの変更回数の検出を行い、ＳＣＧセルのメジャメントに該検出結果を用いる。
【０５２３】
このようにすることによって、ＳｅＮＢの変更回数の検出を指示する情報およびそのためのシグナリングを削減することが可能となる。
【０５２４】
ＤＣ実行中のＵＥの移動状態の導出に、ＳｅＮＢの変更回数を用いることを開示したが、ＳＰＣｅｌｌの変更回数を用いてもよい。ＤＣ実行中のＵＥは、ＳＰＣｅｌｌの変更回数であってもよい。ＵＥは、検出したＳＰＣｅｌｌの変更回数を記録してもよい。これによって、ＳｅＮＢ内でのＳＰｃｅｌｌの変更を考慮することが可能となり、さらに詳細なＵＥの移動状態を導出することができる。
【０５２５】
また、ＳＣＧセルの変更回数を用いてもよい。ＤＣ実行中のＵＥは、ＳＣＧセルの変更回数であってもよい。ＵＥは、検出したＳＣＧセルの変更回数を記録してもよい。ＳｅＮＢがＲＲＨなどを用いてＣＡしているような場合も、ＳＣＧセルの変更回数を記録することによって、さらに詳細なＵＥの移動状態を導出することが可能となる。
【０５２６】
ＳｅＮＢの変更回数を用いるか、ＳＰＣｅｌｌの変更回数を用いるか、ＳＣＧセルの変更回数を用いるか、適宜選択可能としてもよい。ＭｅＮＢが、ＵＥに対して、どの変更回数を用いるかを指示するとよい。ＭｅＮＢは、どの変更回数を用いるかの情報を変更回数の検出を指示する情報とともに、ＵＥに対して通知してもよい。
【０５２７】
図２４は、実施の形態４の変形例１の通信システムにおけるＳＣＧセルのメジャメント処理のシーケンスの一例を示す図である。
【０５２８】
ステップＳＴ２５０１において、ＭｅＮＢは、ＵＥに対してＤＣを実行するために、ＳｅＮＢ（ここではＳ−ＳｅＮＢ）に対して、ＳｅＮＢ追加要求メッセージを通知する。
【０５２９】
ステップＳＴ２５０１のＳｅＮＢ追加要求メッセージを受信し、自ＳｅＮＢのリソースをＤＣに使用可能と判断したＳｅＮＢは、ステップＳＴ２５０２において、ＳｅＮＢ追加要求受理メッセージを通知する。
【０５３０】
ＳｅＮＢ追加要求受理メッセージを受信したＭｅＮＢは、ステップＳＴ２５０３において、ＵＥに対してＤＣを実行させるための設定を通知する。この通知には、ＲＲＣ接続再設定（RRC Connection Reconfiguration）メッセージを用いる。ＭｅＮＢは、ＵＥに対してＳｅＮＢ変更回数を検出させるために、該メッセージに、ＳｅＮＢに関するＵＥの移動速度を表す移動状態のパラメータの設定を含める。
【０５３１】
ステップＳＴ２５０３において該メッセージを受信したＵＥは、ＤＣ実行のためのリソース設定を行う。
【０５３２】
ステップＳＴ２５０４において、ＵＥは、ＭｅＮＢに対して、ＭｅＮＢにＲＲＣ接続再設定完了メッセージを通知する。
【０５３３】
ステップＳＴ２５０５において、ＭｅＮＢは、ＳｅＮＢに対して、ＳｅＮＢ再設定（SeNB Reconfiguration）メッセージを通知する。
【０５３４】
これに従い、ステップＳＴ２５０６において、ＵＥ、ＭｅＮＢ、ＳｅＮＢ間でＤＣ実行処理が行われる。
【０５３５】
ステップＳＴ２５０３において、ＲＲＣ接続再設定メッセージを受信し、該メッセージ中にＳｅＮＢに関するＵＥの移動速度を表す移動状態のパラメータの設定が含まれることを認識したＵＥは、ＳｅＮＢ変更回数検出指示とみなし、ステップＳＴ２５１３において、該パラメータを用いてＳＣＧセルのメジャメント処理を行う。
【０５３６】
具体的には、ステップＳＴ２５０７において、ＵＥは、測定期間内のＳｅＮＢの変更回数を検出する。
【０５３７】
ステップＳＴ２５０８において、ＵＥは、検出したＳｅＮＢの変更回数とＳｅＮＢ変更回数の閾値とを用いて、自ＵＥの移動状態を導出する。移動状態は、「high」、「medium」、それ以外（以下「normal」とする）とする。
【０５３８】
また、ステップＳＴ２５０８において、ＵＥは、導出した自ＵＥの移動状態に応じたスケーリングファクタ（ＳＦ）を導出する。
【０５３９】
ステップＳＴ２５０９において、ＵＥは、メジャメント関連パラメータ、例えばＴＴＴに、導出したスケーリングファクタを乗算する。この値を、ＳＣＧセルのメジャメント用のＴＴＴに設定し、ＳＣＧセルのメジャメントを行う。
【０５４０】
ステップＳＴ２５１０において、ＵＥは、メジャメント結果をＭｅＮＢに通知する。該メジャメント結果には、ＳＣＧセルのメジャメント結果も含む。
【０５４１】
ステップＳＴ２５１０において、ＵＥからＳＣＧセルを含めたメジャメント結果を受信したＭｅＮＢは、ステップＳＴ２５１１において、該メジャメント結果を用いて、ＳｅＮＢの変更を決定する。ＳｅＮＢの変更を決定したＭｅＮＢは、ＳｅＮＢ変更処理を起動し、それに従って、ＵＥ、ＭｅＮＢ、Ｓ−ＳｅＮＢ、Ｔ−ＳｅＮＢ間でＳｅＮＢ変更処理が行われる。Ｓ−ＳｅＮＢは、変更前ＳｅＮＢでソースＳｅＮＢ（Source SeNB）である。Ｔ−ＳｅＮＢは、変更後ＳｅＮＢでターゲットＳｅＮＢ（Target SeNB）である。
【０５４２】
引き続き、ＵＥは、ステップＳＴ２５１３において、ＳｅＮＢに関するＵＥの移動速度を表す移動状態のパラメータを用いてＳＣＧセルのメジャメント処理を行う。
【０５４３】
ステップＳＴ２５１１においてＳｅＮＢの変更が行われたので、測定期間内のＳｅＮＢの変更回数を一つインクリメントする。ＵＥは、検出したＳｅＮＢの変更回数とＳｅＮＢ変更回数の閾値とを用いて、新たな自ＵＥの移動状態を導出する。新たに導出した自ＵＥの移動状態からメジャメント関連パラメータを導出し、ＳＣＧセルのメジャメントを行う。
【０５４４】
ステップＳＴ２５１２において、ＵＥは、メジャメント結果をＭｅＮＢに通知する。該メジャメント結果には、ＳＣＧセルのメジャメント結果も含む。
【０５４５】
このように、ＵＥがＳｅＮＢ変更回数を検出することによって、より精度の高い自ＵＥの移動状態を導出することができる。
【０５４６】
また、ＳＣＧセルのメジャメントに該移動状態を用いることによって、ＵＥは、より精度の高い、言い換えると、スモールセルのカバレッジに適したメジャメント関連パラメータの設定が可能となる。
【０５４７】
したがって、ＭｅＮＢは、ＵＥから、より精度の高いＳＣＧセルのメジャメント結果を得られることになり、ＭｅＮＢは、ＤＣに用いるＳｅＮＢあるいはＳＣＧセルの設定を、ＵＥの移動状態に応じて、より正確に判断することが可能となる。
【０５４８】
本変形例で開示した方法は、従来のｅＮＢ用の移動状態導出処理とは個別に行ってもよい。従来のｅＮＢ用、すなわち、ＨＯ回数の検出結果から移動状態を導出する処理と、本変形例で開示した方法、すなわち、ＳｅＮＢ変更回数の検出結果から移動状態を導出する処理とを個別に行ってもよい。並行して行ってもよい。
【０５４９】
本変形例で開示した移動状態導出方法およびメジャメント方法は、ＳＣＧセルのメジャメント専用に用いるようにしてもよい。セルのカバレッジ範囲に応じた適正なメジャメントが可能となる。
【０５５０】
なお、ＭｅＮＢのメジャメントには、従来の移動状態導出方法およびメジャメント方法を用いるとよい。
【０５５１】
本変形例で開示した移動状態導出方法およびメジャメント方法は、ＳＣＧセルの周波数レイヤのメジャメントに用いるようにしてもよい。また、スモールセルが運用される周波数レイヤのメジャメントに用いるようにしてもよい。
【０５５２】
ＳＣＧセルに限らず、スモールセルのカバレッジ範囲に応じた適正なメジャメントが可能となる。
【０５５３】
ソースＭｅＮＢは、ターゲットＭｅＮＢ（ｅＮＢ）に、ＳｅＮＢに関するＵＥの移動速度を表す移動状態のパラメータの設定を通知してもよい。例えば、ＭｅＮＢの変更、あるいは、ｅＮＢのＨＯの場合、これによって、ターゲットＭｅＮＢ（ｅＮＢ）は、ＨＯ対象のＵＥのソースＭｅＮＢで設定されていたＳｅＮＢに関するＵＥの移動速度を表す移動状態のパラメータ設定を認識することが可能となり、自ＭｅＮＢ（ｅＮＢ）におけるＳｅＮＢに関するＵＥの移動速度を表す移動状態のパラメータ設定に資することができる。
【０５５４】
また、ターゲットＭｅＮＢ（ｅＮＢ）においても、新たなＵＥの移動速度を表す移動状態のパラメータ設定が行われるまでは、引き続きソースＭｅＮＢと同じＵＥの移動速度を表す移動状態のパラメータ設定が有効となるようにしてもよい。ＵＥは、ターゲットＭｅＮＢ（ｅＮＢ）から、新たなＵＥの移動速度を表す移動状態のパラメータ設定が通知されるまで、引き続きソースＭｅＮＢと同じＵＥの移動速度を表す移動状態のパラメータ設定を用いて、ＳｅＮＢ変更回数の検出および記録を行う。このようにすることによって、長期的なＵＥの移動状態の検出が可能となる。
【０５５５】
逆に、ＵＥは、ＭｅＮＢ（ｅＮＢ）のＨＯで、ＳｅＮＢ変更回数の検出および記録をリセットしてもよい。ＳｅＮＢ変更回数の検出および記録のリセットに従い、ＳｅＮＢ変更回数を用いたＳＣＧセルのメジャメントもリセットされるようにしてもよい。ＵＥは、変更先ＭｅＮＢ（ｅＮＢ）から通知されるメジャメント設定の受信に従って、再度実行するとよい。これによって、メジャメント設定をソースＭｅＮＢからターゲットＭｅＮＢに通知する必要が無くなる。したがって、ＨＯ時のシグナリング量の増大を防ぐことができる。
【０５５６】
ＭｅＮＢ（ｅＮＢ）のＨＯについて記載したが、ＭｅＮＢの変更、あるいはＰＣｅｌｌの変更など、ＵＥにメジャメント設定を通知するサービングセルが変更される場合にも適用できる。
【０５５７】
ＳｅＮＢ変更回数の検出および記録は、ＳｅＮＢリリース処理が行われた場合にリセットされるようにしてもよい。ＵＥは、ＳｅＮＢリリース処理を通知された場合に、ＳｅＮＢ変更回数の検出および記録をリセットしてもよい。ＵＥは、ＤＣの実行が終了した場合に、ＳｅＮＢ変更回数の検出および記録をリセットしてもよい。
【０５５８】
ＳｅＮＢ変更回数の検出および記録のリセットに従い、ＳｅＮＢ変更回数を用いたＳＣＧセルのメジャメントもリセットされるようにしてもよい。
【０５５９】
本変形例で開示した方法は、ＴＴＴへの適用だけでなく他のメジャメント関連パラメータに用いてもよい。より精度の高い移動状態を必要とする場合に使用可能である。
【０５６０】
実施の形態４  変形例２．
実施の形態４の変形例２で解決する課題、およびその解決策について、以下に示す。
【０５６１】
現在の３ＧＰＰの規格では、ＵＥの移動状態に関する機能が存在する。例えば、移動履歴情報（Mobility History Information）である（非特許文献１６参照）。
【０５６２】
移動履歴情報（Mobility History Information）は、ＲＲＣ＿ＩｄｌｅとＲＲＣ＿ＣｏｎｎｅｃｔｅｄのＵＥに適用される。ＵＥは、ＲＲＣ＿Ｉｄｌｅ時のサービングセルの変更、あるいは、ＲＲＣ＿Ｃｏｎｎｅｃｔｅｄ時のＰＣｅｌｌの変更に従って、該セル（変更前のセル）のセル識別子と、そのセルでの滞留時間とを記録する。サービス外から、あるいは、他のＲＡＴから最初にＥ−ＵＴＲＡセルに入るときは、Ｅ−ＵＴＲＡ外の滞留時間のみ記録する。
【０５６３】
ＵＥは、ｅＮＢからのＵＥ情報要求（UE Information Request）に応じて、記録したＰＣｅｌｌあるいはサービングセルのセル識別子と滞留時間とをＵＥ情報応答（UE Information Response）メッセージに含めて、ｅＮＢに通知する。これによって、ｅＮＢは、ＵＥの移動状態を取得することができる。
【０５６４】
このように、従来の規格では、ＲＲＣ＿Ｃｏｎｎｅｃｔｅｄ時の対象とするセルをＰＣｅｌｌとしている。
【０５６５】
ＤＣに用いられるＳＣＧセルは、ＰＣｅｌｌではないので、移動履歴情報（Mobility History Information）の対象とならない。ＤＣ実行中のＵＥの移動状態は、ＭｅＮＢのＰＣｅｌｌの変更によって決定される。
【０５６６】
したがって、実施の形態４の変形例１で示したのと同様に、従来の規格では、ｅＮＢは、精度の高い、スモールセルのカバレッジに適したＵＥの移動状態を取得できないことになる。
【０５６７】
本変形例では、ｅＮＢが、より精度の高いＵＥの移動状態を得る方法を開示する。
【０５６８】
ＵＥは、ＤＣ実行中のＳＰＣｅｌｌのセル識別子と該セルでの滞留時間とを記録する。ＤＣ実行中のＵＥは、ＳＰＣｅｌｌの変更に従って、該セル（変更前のセル）のセル識別子と、該セルでの滞留時間とを記録する。また、該セルのキャリア周波数を記録してもよい。セル識別子としては、ＣＧＩあるいはＰＣＩとするとよい。
【０５６９】
ＵＥは、従来のＰＣｅｌｌの情報を記録したリストと、ＳＰＣｅｌｌの情報を記録したリストとを個別に設けてもよい。ＵＥは、ＰＣｅｌｌの情報とＳＰＣｅｌｌの情報とを各々のリストに記録する。
【０５７０】
ｅＮＢが、ＵＥが記録したリストを取得する方法を開示する。
【０５７１】
ＭｅＮＢは、ＤＣ実行中のＵＥに、ＳＰＣｅｌｌの情報を記録したリストを要求する。新たに該要求のためのＲＲＣメッセージを設けて通知してもよい。あるいは既存のＲＲＣメッセージにＳＰＣｅｌｌの情報を記録したリストの要求であることを示す情報を含めて通知してもよい。個別シグナリングで通知してもよい。
【０５７２】
例えば、ＭｅＮＢは、該情報をＲＲＣ接続再設定（RRC Connection Reconfiguration）メッセージに含めてＵＥに通知してもよい。該情報を「Radio Resource Configuration Dedicated」メッセージに含めて通知してもよい。
【０５７３】
あるいは、ＭｅＮＢは、ＳｅＮＢに関するＲＲＣ接続再設定（RRC Connection Reconfiguration）を行う際にＵＥに通知してもよい。例えば、ＭｅＮＢは、該情報をＳｅＮＢ追加処理の際にＵＥに通知してもよい。他の例として、ＭｅＮＢは、該情報をＳｅＮＢ変更処理あるいは修正処理の際にＵＥに通知してもよい。他の例として、ＭｅＮＢは、ＳＰＣｅｌｌを変更する際にＵＥに通知してもよい。
【０５７４】
これらの通知方法は組み合わせて用いてもよい。システムとして柔軟な運用が可能となる。他の例として、従来と同じメッセージであるＵＥ情報要求（UE Information Request）メッセージに該情報を含めてもよい。ＰＣｅｌｌの情報を記録したリストとＳＰＣｅｌｌの情報を記録したリストとのどちらを要求するかを示す情報を該メッセージに含めてもよい。
【０５７５】
ＵＥは、ＭｅＮＢから、ＳＰＣｅｌｌの情報を記録したリストの要求を受信した場合、ＳＰＣｅｌｌの情報を記録したリストを、ＭｅＮＢに対して通知する。新たに該要求のためのＲＲＣメッセージを設けて通知してもよい。あるいは既存のＲＲＣメッセージにＳＰＣｅｌｌの情報を記録したリストの要求であることを示す情報を含めて通知してもよい。個別シグナリングで通知してもよい。
【０５７６】
例えば、ＳＰＣｅｌｌの情報を記録したリストの要求に、従来と同じメッセージであるＵＥ情報要求（UE Information Request）メッセージを用いる場合は、ＵＥ情報応答（UE Information Response）メッセージを用いて通知するとよい。ＵＥは、ＭｅＮＢに、ＳＰＣｅｌｌの情報を記録したリストをＵＥ情報応答（UE Information Response）メッセージに含めて通知する。
【０５７７】
ＭｅＮＢは、ＵＥに対して、ＰＣｅｌｌの情報を記録したリスト要求と、ＳＰＣｅｌｌの情報を記録したリスト要求とを個別に行ってもよい。例えば、どちらもＵＥ情報要求（UE Information Request）メッセージを用いてもよい。該メッセージに、前述の、ＰＣｅｌｌの情報を記録したリストとＳＰＣｅｌｌの情報を記録したリストとのどちらを要求するかを示す情報を含めておくことによって、ＵＥは、どちらの情報をＭｅＮＢに対して通知するかを認識することが可能となる。ＵＥは、該情報に従い、対応するリストをＭｅＮＢに対して報告するとよい。
【０５７８】
ＭｅＮＢが一つのメッセージで、ＳＰＣｅｌｌの情報を記録したリストとＰＣｅｌｌの情報を記録したリストとの両方を要求してもよい。ＭｅＮＢは、両方を要求することを示す情報をＵＥに対して通知するとよい。該メッセージを受信したＵＥは、ＳＰＣｅｌｌの情報を記録したリストと、ＰＣｅｌｌの情報を記録したリストとの両方を、ＭｅＮＢに対して通知する。一つのメッセージを用いて通知してもよい。
【０５７９】
また、一つのメッセージが、常に、両方を要求することを示すメッセージとしてもよい。予め規格などで静的に決めておいてもよい。ＭｅＮＢが、該メッセージをＵＥに通知した場合、ＵＥは、ＳＰＣｅｌｌの情報を記録したリストと、ＰＣｅｌｌの情報を記録したリストとの両方を、ＭｅＮＢに対して通知する。一つのメッセージを用いて通知してもよい。
【０５８０】
ＳＰＣｅｌｌの情報を記録したリストの作成方法を開示する。
【０５８１】
ＵＥは、ＤＣ実行中のＳＰＣｅｌｌの変更に従って、該セル（変更前のセル）のセルＩＤなどと、該セルでの滞留時間とを記録する。併せて、該セルのキャリア周波数を記録してもよい。また、該セルのセルサイズを併せて記録してもよい。
【０５８２】
リストに記録する最大のセル数を決めておいてもよい。例えば、最大ｎセルとし、ＵＥは、それを超えた場合、古いものから破棄する。ＵＥの記録容量が膨大になることを防ぐことができる。最大のセル数ｎは、予め規格などで静的に決めておいてもよい。あるいは、ＭｅＮＢから通知してもよい。
【０５８３】
ＵＥは、ＳｅＮＢリリース処理が実行された場合に、ＳＰｃｅｌｌの情報を記録したリストを廃棄するようにしてもよい。ＵＥは、ＳｅＮＢ追加処理が実行された場合に、ＳＰｃｅｌｌの情報を記録したリストを新たに作成するようにしてもよい。ＳｅＮＢリリース処理が実行された場合として、ＵＥが、ＳｅＮＢ用のリソースをリリースあるいはリセットした場合としてもよい。
【０５８４】
ＵＥは、ＳｅＮＢリリース処理が実行された場合、ＳＰＣｅｌｌの情報を記録したリストを、所定の期間保持するようにしてもよい。ＵＥは、ＳｅＮＢリリース処理実行後、所定の期間満了前に新たにＳｅＮＢ追加処理が実行された場合は、既に作成されていたリストに記録する。ＵＥは、ＳｅＮＢリリース処理実行後、新たにＳｅＮＢ追加処理が実行されずに所定の期間満了した場合、リストを破棄する。
【０５８５】
このようにすることによって、ＳｅＮＢのカバレッジが連続していないような状況で、ＤＣが断続的に実行されるような場合も、ＳＰＣｅｌｌ情報を記録したリストを無駄に破棄することはなくなる。所定の期間は、予め規格などで静的に決められてもよい。あるいは、所定の期間は、ＭｅＮＢからＵＥに通知してもよい。通知方法として、ＲＲＣメッセージを用いて通知してもよい。個別シグナリングを用いて通知してもよい。あるいは、ＭｅＮＢは傘下のＵＥに報知してもよい。ＳＩＢに該所定の期間を含めて通知してもよい。
【０５８６】
また、ＵＥは、ＲＲＣ＿ＣＯＮＮＥＣＴＥＤ中の、ＤＣが実行されていない時間を記録しておいてもよい。例えば、ＲＲＣ＿ＣＯＮＮＥＣＴＥＤに移行してからＳｅＮＢ追加処理が実行されるまでの時間、ＳｅＮＢリリース処理が実行されてからＳｅＮＢ追加処理が実行されるまでの時間、ＳｅＮＢリリース処理が実行されてから、ＲＲＣ＿ＣＯＮＮＥＣＴＥＤ状態を終了するまでの時間を記録しておいてもよい。各々、別々に記録するとよい。ＤＣが実行されていない時間の発生に従い記録するとよい。ＤＣが実行されていない時間については、ＳＰＣｅｌｌのセル識別子とキャリア周波数情報を記録せず、滞留時間として、記録しておくとよい。
【０５８７】
このようにすることによって、ＵＥは、ＲＲＣ＿ＣＯＮＮＥＣＴＥＤ状態におけるＳＰＣｅｌｌ変更の状況を、ＳＰＣｅｌｌの使用が無い場合も含めて記録することができる。ＭｅＮＢは、ＵＥから該情報を取得することができ、より詳細なＵＥの移動状態を認識することが可能となる。
【０５８８】
また、ＵＥは、ＭｅＮＢのＨＯを行った場合に、ＳＰＣｅｌｌの情報を記録したリストを廃棄するようにしてもよい。
【０５８９】
ＵＥは、ＭｅＮＢのＨＯを行った場合、ＳＰＣｅｌｌの情報を記録したリストを、所定の期間保持するようにしてもよい。ＵＥは、ＨＯ処理実行後、所定の期間満了前に新たにＳｅＮＢ追加処理あるいはＳＰＣｅｌｌ変更処理が実行された場合は、既に作成されていたリストに記録する。ＵＥは、ＨＯ処理実行後、新たにＳｅＮＢ追加処理あるいはＳＰＣｅｌｌ変更処理が実行されずに所定の期間満了した場合、リストを破棄する。
【０５９０】
また、ＵＥは、ＭｅＮＢのＨＯを行った場合、ＨＯ先ＭｅＮＢ（ｅＮＢ）に、ＳＰＣｅｌｌの情報を記録したリストを通知した後、該リストを廃棄するようにしてもよい。
【０５９１】
ＵＥは、ＨＯ処理実行後、ＨＯ先ＭｅＮＢ（ｅＮＢ）からの要求に応じて、ＳＰＣｅｌｌの情報を記録したリストを通知してもよい。
【０５９２】
ＭｅＮＢのＨＯの場合、ＨＯ元ＭｅＮＢは、ＨＯ先ＭｅＮＢ（ｅＮＢ）に、ＵＥから取得したＳＰＣｅｌｌの情報を記録したリストを通知してもよい。また、該リストにセルサイズが含まれていない場合、ＭｅＮＢが該リストにセルサイズを加えて通知してもよい。ＭｅＮＢがＳＰＣｅｌｌのセルサイズを認識している場合に有効である。Ｘ２シグナリングで通知してもよい。あるいは、ＭＭＥを介して、Ｓ１シグナリングで通知してもよい。
【０５９３】
この方法を行うことで、ＨＯ先ＭｅＮＢ（ｅＮＢ）は該情報を引き続き利用可能となる。
【０５９４】
また、ＨＯ元ＭｅＮＢは、ＨＯ先ＭｅＮＢ（ｅＮＢ）に、ＵＥから取得したＳＰＣｅｌｌの情報を記録したリストを通知してもよい。ＵＥから取得したＳＰＣｅｌｌの情報を記録したリストとともに通知してもよい。同じメッセージ含めて通知してもよい。
【０５９５】
前述した方法では、ＵＥは、ＰＣｅｌｌの情報とＳＰＣｅｌｌの情報を各々のリストに記録した。他の方法として、一つのリストに、ＰＣｅｌｌの情報とＳＰＣｅｌｌの情報とを記録してもよい。あるいは、従来のＰＣｅｌｌの情報のリストにＳＰｃｅｌｌの情報を含めてもよい。
【０５９６】
この場合、ＳＰＣｅｌｌであることを示すパラメータを設け、ＳＰＣｅｌｌに対応付けて記録してリストを作成するとよい。
【０５９７】
該リストに既にセルサイズが含まれている場合は、該ＳＰＣｅｌｌであることを示すパラメータは記録しなくてもよい。
【０５９８】
このようにすることによって、ＵＥは、リストを一つとすることが可能となり、記憶容量の削減、リスト作成処理の簡易化を図ることができる。また、ＭｅＮＢとＵＥとの間のリストの要求と通知メッセージに含む情報あるいはメッセージを削減することが可能となる。これによって、シグナリング負荷の削減が可能となる。
【０５９９】
前述の方法では、ＵＥは、ＳＰＣｅｌｌの情報を記録しリストを作成した。他の方法として、ＳｅＮＢの情報を記録してリストを作成してもよい。ＤＣ実行中のＵＥは、ＳｅＮＢの変更に従って、該ＳｅＮＢ（変更前のＳｅＮＢ）のｅＮＢ識別子と、該ｅＮＢでの滞留時間を記録する。また、該ｅＮＢで使用されるキャリア周波数を記録してもよい。ＳＰＣｅｌｌの情報に比べて粗い情報となるが、記録容量の削減、シグナリング負荷の削減を図ることができる。
【０６００】
また、ＵＥは、ＳＣＧセルの情報を記録してリストを作成してもよい。ＤＣ実行中のＵＥは、ＳＣＧセルの変更に従って、該ＳＣＧセル（変更前のＳＣＧセル）のセル識別子と、該セルでの滞留時間を記録する。また、該セルのキャリア周波数を記録してもよい。また、該セルのセルサイズを併せて記録してもよい。ＭｅＮＢは、ＳＣＧセルの情報を記録したリストを取得することによって、さらに詳細なＵＥの移動状態を導出することが可能となる。
【０６０１】
ＳＰＣｅｌｌの情報を記録したリストとするか、ＳｅＮＢの情報を記録したリストとするか、ＳＣＧセルの情報を記録したリストとするか、選択可能としてもよい。予め規格などで静的に決められてもよい。あるいは、ＭｅＮＢが、ＵＥに対して、どのリストを作成するか指示してもよい。ＭｅＮＢは、どのリストを作成するかの情報をＵＥに通知するとよい。例えば、ＵＥがＲＲＣ＿Ｃｏｎｎｅｃｔｅｄ状態に移行する際に通知するとよい。ＭｅＮＢは、ＲＲＣメッセージで通知するとよい。個別シグナリングとするとよい。
【０６０２】
実施の形態４  変形例３．
実施の形態４の変形例３で解決する課題、およびその解決策について、以下に示す。
【０６０３】
現在の３ＧＰＰの規格では、ＵＥの移動状態に関する機能が存在する。例えば、ＵＥ履歴情報（UE History Information）である（非特許文献１参照）。
【０６０４】
ＵＥ履歴情報（UE History Information）は、ＵＥをサーブするｅＮＢが、アクティブ状態のＵＥの「Last Visited Cell List」を作成する。
【０６０５】
ＵＥがＨＯを実行する際、ＨＯ元ｅＮＢは、該ＵＥの「Last Visited Cell List」にＰＣｅｌｌを追加して、該リストをＨＯ先ｅＮＢにＳ１あるいはＸ２で通知する。ＨＯ先ｅＮＢは、次のＨＯ先ｅＮＢに対して同様の処理を行い、該リストを通知する。ネットワーク側が、ＵＥのＨＯ履歴情報を作成して維持する。「Last Visited Cell List」に記録する情報としては、セル識別子、例えばＣＧＩ、セルサイズ、セルの滞留時間、ＨＯ理由がある。
【０６０６】
このように、従来の規格では、ｅＮＢは、ＨＯの履歴情報をリストに記録する。
【０６０７】
ＤＣに用いられるＳｅＮＢの変更はＨＯで行われない。したがって、ＤＣ実行中のＵＥがいくらＳｅＮＢの変更を繰り返しても、該リストには記録されない。
【０６０８】
したがって、従来の規格では、実施の形態４の変形例２で示したのと同様に、ｅＮＢは、精度の高い、スモールセルのカバレッジに適したＵＥの移動状態を取得できないことになる。
【０６０９】
本変形例では、ｅＮＢが、より精度の高いＵＥの移動状態を得る他の方法を開示する。
【０６１０】
ＭｅＮＢは、ＤＣ実行中のＵＥが接続したＳＰＣｅｌｌのリストを作成する。以下の説明では、ＤＣ実行中のＵＥが接続したＳＰＣｅｌｌのリストを、「ＳＰＣｅｌｌ変更履歴リスト」という場合がある。
【０６１１】
ＵＥに対して、ＤＣに用いるＳＰＣｅｌｌが変更された際、ＭｅＮＢは、変更前ＳＰＣｅｌｌをＳＰＣｅｌｌ変更履歴リストに追加する。あるいは、ＳｅＮＢリリース処理が実行された際、ＭｅＮＢは、リリース前にＵＥに接続していたＳＰＣｅｌｌを該ＵＥのＳＰＣｅｌｌ変更履歴リストに追加する。
【０６１２】
ＳＰＣｅｌｌ変更履歴リストに記録する情報として、セル識別子、例えばＣＧＩ、セルサイズ、セルの滞留時間、ＳＰＣｅｌｌ変更理由あるいはＳｅＮＢリリース理由がある。
【０６１３】
このようにすることによって、ＭｅＮＢは、ＤＣ実行中のＵＥのＳＰＣｅｌｌの履歴情報をリストに記録することができる。したがって、ＭｅＮＢは、スモールセルのカバレッジに適したＵＥの移動状態を取得できる。
【０６１４】
ＭｅＮＢは、従来のＨＯ履歴情報を記録するリストと、ＳＰＣｅｌｌ変更履歴情報を記録するリストとを個別に設けてもよい。ＭｅＮＢは、ＨＯ履歴情報とＳＰＣｅｌｌ変更履歴情報とを各々のリストに記録する。
【０６１５】
ＤＣ実行中のＵＥに対してＳｅＮＢリリース処理が実行された場合に、ＭｅＮＢは、該ＵＥのＳＰｃｅｌｌ変更履歴情報を記録したリストを廃棄するようにしてもよい。ＵＥに対するＳｅＮＢ追加処理が実行された場合に、ＭｅＮＢは、該ＵＥのＳＰｃｅｌｌの情報を記録したリストを新たに作成するようにしてもよい。ＳｅＮＢリリース処理が実行された場合として、ＭｅＮＢがＵＥに対して、ＳｅＮＢのリソースリリースを指示した場合としてもよい。
【０６１６】
ＤＣ実行中のＵＥに対してＳｅＮＢリリース処理が実行された場合、ＭｅＮＢは、該ＵＥのＳＰＣｅｌｌの情報を記録したリストを、所定の期間保持するようにしてもよい。ＤＣ実行中のＵＥに対するＳｅＮＢリリース処理実行後、所定の期間満了前に新たにＳｅＮＢ追加処理が実行された場合は、ＭｅＮＢは、既に作成されていたリストに記録する。ＤＣ実行中のＵＥに対するＳｅＮＢリリース処理実行後、新たにＳｅＮＢ追加処理が実行されずに所定の期間満了した場合、ＭｅＮＢはリストを破棄する。
【０６１７】
このようにすることによって、ＳｅＮＢのカバレッジが連続していないような状況で、ＤＣが断続的に実行されるような場合も、ＳＰＣｅｌｌへ高履歴情報を記録したリストを無駄に破棄することはなくなる。所定の期間は、予め規格などで静的に決められてもよい。準静的、あるいは動的に決められてもよい。ＭＭＥあるいはＯ＆Ｍ（Operation and Maintenance）が決定し、ＭｅＮＢに対して通知してもよい。
【０６１８】
また、ＭｅＮＢは、ＲＲＣ＿Ｃｏｎｎｅｃｔｅｄ中のＵＥに対して、ＤＣを実行していない時間をリストに記録しておいてもよい。例えば、ＵＥとＭｅＮＢとの間でＲＲＣ接続設立処理が完了してからＳｅＮＢ追加処理が実行されるまでの時間、ＳｅＮＢリリース処理が実行されてからＳｅＮＢ追加処理が実行されるまでの時間、ＳｅＮＢリリース処理が実行されてから、ＲＲＣ＿ＣＯＮＮＥＣＴＥＤ状態を終了するまでの時間を記録しておいてもよい。各々、別々に記録するとよい。ＤＣが実行されていない時間の発生に従い記録するとよい。ＤＣが実行されていない時間については、ＳＰＣｅｌｌのセル識別子とキャリア周波数情報とを記録せず、滞留時間のみを記録しておくとよい。
【０６１９】
このようにすることによって、ＭｅＮＢは、ＲＲＣ＿ＣＯＮＮＥＣＴＥＤ状態におけるＳＰＣｅｌｌ変更の状況を、ＳＰＣｅｌｌの使用が無い場合も含めて記録できる。ＭｅＮＢは、より詳細なＵＥの移動状態を認識することが可能となる。
【０６２０】
また、ＭｅＮＢは、ＨＯを行った場合に、該ＨＯ対象ＵＥのＳＰＣｅｌｌ変更履歴情報を記録したリストを廃棄するようにしてもよい。
【０６２１】
ＭｅＮＢは、ＨＯを行った場合、該ＨＯ対象ＵＥのＳＰＣｅｌｌ変更履歴情報を記録したリストを、所定の期間保持するようにしてもよい。該ＨＯ対象ＵＥがＨＯ元ＭｅＮＢに切り戻った場合などに、該リストを利用できる。
【０６２２】
ＭｅＮＢのＨＯの場合、ＨＯ元ＭｅＮＢは、ＨＯ先ＭｅＮＢ（ｅＮＢ）に、ＳＰＣｅｌｌ変更履歴情報を記録したリストを通知してもよい。Ｘ２シグナリングで通知してもよい。あるいは、ＭＭＥを介して、Ｓ１シグナリングで通知してもよい。この方法を行うことで、ＨＯ先ＭｅＮＢ（ｅＮＢ）は該情報を引き続き利用可能となる。
【０６２３】
また、ＨＯ元ＭｅＮＢは、ＨＯ先ＭｅＮＢ（ｅＮＢ）に、ＰＣｅｌｌのＨＯ履歴情報を記録したリストを通知してもよい。ＳＰＣｅｌｌ変更履歴情報を記録したリストとともに通知してもよい。同じメッセージに含めて通知してもよい。
【０６２４】
ＨＯ先ＭｅＮＢ（ｅＮＢ）は、ＨＯ元ＭｅＮＢ（ｅＮＢ）から、該ＨＯ対象ＵＥのＳＰＣｅｌｌ変更履歴情報を記録したリストを受信した場合は、該ＨＯ対象ＵＥのＳＰＣｅｌｌ変更履歴情報を記録したリストを、所定の期間保持するようにしてもよい。
【０６２５】
ＨＯ処理実行後、所定の期間満了前に、ＨＯ先ＭｅＮＢ（ｅＮＢ）が新たにＳｅＮＢ追加処理あるいはＳＰＣｅｌｌ変更処理を実行された場合は、既に作成されていたリストに記録する。ＨＯ先ＭｅＮＢ（ｅＮＢ）は、新たにＳｅＮＢ追加処理あるいはＳＰＣｅｌｌ変更処理が実行されずに所定の期間満了した場合、リストを破棄する。
【０６２６】
前述の方法では、ＭｅＮＢは、ＰＣｅｌｌのＨＯ履歴情報とＳＰＣｅｌｌ変更履歴情報を各々のリストに記録した。他の方法として、一つのリストに、ＰＣｅｌｌのＨＯ履歴情報とＳＰＣｅｌｌ変更履歴情報とを記録してもよい。あるいは、従来のＰＣｅｌｌのＨＯ履歴情報のリストにＳＰｃｅｌｌ変更履歴情報を含めてもよい。
【０６２７】
この場合、ＳＰＣｅｌｌであることを示すパラメータを設け、ＳＰＣｅｌｌに対応付けて記録してリストを作成するとよい。
【０６２８】
該リストに既にセルサイズが含まれている場合は、該ＳＰＣｅｌｌであることを示すパラメータは記録しなくてもよい。
【０６２９】
このようにすることによって、ＭｅＮＢは、リストを一つとすることが可能となり、記憶容量の削減、リスト作成処理の簡易化を図ることができる。
【０６３０】
前述の方法では、ＭｅＮＢは、ＳＰＣｅｌｌの変更履歴情報を記録してリストを作成した。他の方法として、ＳｅＮＢの変更履歴情報を記録してリストを作成してもよい。ＭｅＮＢは、ＤＣ実行中のＵＥに対して、ＳｅＮＢの変更に従って、該ＳｅＮＢ（変更前のＳｅＮＢ）のｅＮＢ識別子と、該ｅＮＢでの滞留時間を記録する。また、該ｅＮＢで使用されるキャリア周波数を記録してもよい。また、変更理由を記録してもよい。ＳＰＣｅｌｌの情報に比べて粗い情報となるが、記録容量の削減を図ることができる。
【０６３１】
また、ＭｅＮＢは、ＳＣＧセルの変更履歴情報を記録してリストを作成してもよい。ＭｅＮＢは、ＤＣ実行中のＵＥに対して、ＳＣＧセルの変更に従って、該ＳＣＧセル（変更前のＳＣＧセル）のセル識別子と、該セルでの滞留時間を記録する。また、該セルのキャリア周波数を記録してもよい。また、該セルのセルサイズを併せて記録してもよい。また、変更理由を記録してもよい。ＭｅＮＢは、ＳＣＧセルの変更履歴情報を記録したリストを取得することによって、さらに詳細なＵＥの移動状態を導出することが可能となる。
【０６３２】
ＳＰＣｅｌｌの変更履歴情報を記録したリストとするか、ＳｅＮＢの変更履歴情報を記録したリストとするか、ＳＣＧセルの変更履歴情報を記録したリストとするか、選択可能としてもよい。予め規格などで静的に決められてもよい。準静的、あるいは動的に決められてもよい。ＭＭＥあるいはＯ＆Ｍが決定し、ＭｅＮＢに対して通知してもよい。
【０６３３】
実施の形態５．
本実施の形態では、非特許文献７に記載される多地点協調送受信（Coordinated Multipoint transmission and reception：ＣｏＭＰ）の開始時、ＣｏＭＰ対象であるＵＥが送信するサウンディング参照信号（Sounding Reference Signal：ＳＲＳ）を用いて、リソース（周波数、時間、送信電力）の無駄および不足が少ない通信ができる方法について開示する。
【０６３４】
ここで、「サウンディング参照信号」とは、例えば非特許文献１４に記載されるような、送信データがないときにも常時、あるいは、間欠的に送信される既知系列の信号のことを指す。
【０６３５】
まず、上りについて説明する。図２５は、３ＧＰＰで検討されているＵＬ  ＣｏＭＰの概念を示す図である。図２５では、ｅＮＢ＃１を参照符号「５１０１」で示し、ｅＮＢ＃２を参照符号「５１０３」で示し、ｅＮＢ＃１の通信エリア、すなわちカバレッジを参照符号「５１０２」で示し、ｅＮＢ＃２の通信エリア、すなわちカバレッジを参照符号「５１０４」で示す。また、セントラルエンティティ（Central Entity）あるいは移動管理エンティティ（Mobile Management Entity：ＭＭＥ）を参照符号「５１０６」で示す。
【０６３６】
ｅＮＢ＃１  ５１０１およびｅＮＢ＃２  ５１０３は、ＵＬ  ＣｏＭＰ、すなわち上り多地点間協調受信を行う場合、セントラルエンティティ（Central Entity）あるいは移動管理エンティティ（Mobile Management Entity：ＭＭＥ）５１０６経由でｅＮＢ間の協調動作を行う。例えば、多地点間協調スケジューリングを行う協調スケジューリング（Coordinated Scheduling：ＣＳ）が検討されており、各ｅＮＢの通信状況に合わせて、セルエッジのＵＥ５１０５との通信データ５１０７，５１１０、送信電力などをスケジュールすることによって、スループットの向上、システムスループットの増大を図ることができる。セントラルエンティティは、多地点間協調を行う機能部であり、ＭＭＥ経由の場合はｅＮＢ間の多地点間協調を行う信号のやり取りを行い、実際の協調制御はｅＮＢ同士で行う。
【０６３７】
ＣＳ時のＵＬ  ＣｏＭＰでは、ｅＮＢ＃１  ５１０１の傘下にいる移動端末（ＵＥ）５１０５は、ｅＮＢ＃１  ５１０１に送信したいデータ５１０７が発生すると、ｅＮＢ＃１  ５１０１に、スケジューリング要求（Scheduling Request：ＳＲ）を送信する。ｅＮＢ＃１  ５１０１は，他のＵＥの通信状況などのリソースの空き状況を確認して、送信可能であれば、許可範囲を表すグラント（Ｇｒａｎｔ）信号を送信する。
【０６３８】
ＵＥ５１０５は、Ｇｒａｎｔ信号を受信すると、Ｇｒａｎｔ信号で許可された範囲内の送信したいデータ５１０７を送信する。
【０６３９】
ｅＮＢ＃１  ５１０１は、ＵＥ５１０５がセルの境界、あるいは、他セルの近傍にいることを検出すると、ＲＲＣ（Radio Resource Control）を用いて、ＵＥ５１０５にＳＲＳ送信指示を通知する。
【０６４０】
ＵＥ５１０５がメジャメント報告（Measurement Report）メッセージで報告してきた自セルの報告値、具体的にはＲＳＲＰ（Reference Signal Received Power）、あるいは、ＲＳＲＱ（Reference Signal Received Quality）、あるいは、両者が特定の閾値以下かどうかで、セルの境界にいることを判定してもよい。
【０６４１】
また、ＵＥ５１０５がメジャメント報告（Measurement Report）メッセージで報告してきた他セルの報告値、具体的にはＲＳＲＰ、あるいはＲＳＲＱ、あるいは両者が特定の閾値以上かどうかで、他セルの近傍にいることを判定してもよい。
【０６４２】
非特許文献１４（５．５．１．５参照）では、ＳＲＳ信号を規定する擬似乱数を発生させるためのパラメータｎＲＳＩＤはＮｃｅｌｌＩＤとなっており、セル毎の値（セルＩＤ）になっているが、本発明では、ＳＲＳ送信指示は、少なくとも１つのＵＥ個別のパラメータを指定する。すなわち、ＵＥ５１０５は、セル独自のＳＲＳ信号ではなく、ＵＥ独自のＳＲＳ信号を送信する。
【０６４３】
ＳＲＳ信号は、常時、ＵＥ独自の信号としてもよいし、セルの境界、あるいは、他セルの近傍にいることを検出したときに、セル個別のＳＲＳ信号からＵＥ独自の信号に切り替えてもよい。
【０６４４】
ＵＥがデータを送信する方法としては、以下の２通りの方法がある。１つは、ＵＥがｅＮＢ＃１に送信するときと、ｅＮＢ＃２に送信するときとで、同じ構成（同じＰＵＳＣＨ  ｃｏｎｆｉｇ、ＰＵＣＣＨ  ｃｏｎｆｉｇ）とする方法である。もう１つは、ＵＥがｅＮＢ＃１に送信するときと、ｅＮＢ＃２に送信するときとで、異なる構成とする方法である。
【０６４５】
例えば図２５に示す例において、ＵＥ５１０５が、送信するｅＮＢ５１０１，５１０３毎に異なる構成で送信する場合、ｅＮＢ＃２  ５１０３は、ｅＮＢ＃１  ５１０１に、ｅＮＢ＃２  ５１０３で使用する「ＰＵＣＣＨ  ｃｏｎｆｉｇ」、「ＰＵＳＣＨ  ｃｏｎｆｉｇ」などのＣｏＭＰ設定用パラメータをＸ２インタフェース５１１５経由で通知する。セントラルエンティティあるいはＭＭＥ５１０６経由でもよい。ｅＮＢ＃１  ５１０１は、ＵＥ５１０５に、これらのｃｏｎｆｉｇ情報を通知する。
【０６４６】
これによって、ＵＥ５１０１は、ｅＮＢ＃２  ５１０３に送信するときには、ｅＮＢ＃２  ５１０３が受信できる構成でデータを送信することができる。この方法は、ｅＮＢのバックホールで大きな遅延時間が発生するなど、ｅＮＢ間で同期が取れていないときに有効である。
【０６４７】
一方、ＵＥ５１０５が、送信するｅＮＢ５１０１，５１０３によらずに共通の構成で送信する場合、ｅＮＢ＃１  ５１０１は、ｅＮＢ＃２  ５１０３に、「ＰＵＣＣＨ  ｃｏｎｆｉｇ」、「ＰＵＳＣＨ  ｃｏｎｆｉｇ」などのＣｏＭＰ設定用パラメータをＸ２インタフェース５１１５経由で通知する。セントラルエンティティあるいはＭＭＥ５１０６経由でもよい。
【０６４８】
これによって、ｅＮＢ＃２  ５０１３も、ＵＥ５１０５が送信するデータを受信することができる。この方法は、ＵＥがどちらのｅＮＢに送信するかを意識することなく、同一のデータを送信することができるので、制御手順が簡易になる。
【０６４９】
また、ｅＮＢ＃１  ５１０１は、ＵＬ  ＣｏＭＰを行う可能性のあるｅＮＢ＃１  ５１０１に隣接したｅＮＢ＃２  ５１０３に、Ｘ２インタフェース５１１５経由で直接、ＳＲＳ  ｃｏｎｆｉｇ５１１６を通知する。ｅＮＢ＃２  ５１０３では、ＳＲＳ  ｃｏｎｆｉｇ５１１６に従って、ＵＥ５１０５のＳＲＳの受信を開始する。
【０６５０】
この際、ｅＮＢ＃１  ５１０１とｅＮＢ＃２  ５１０３とで、事前に同期をとっておくとよい。あるいは、特定の時間範囲内に同期させておくとよい。ＯＦＤＭシンボルの同期だけではなく、複数のＯＦＤＭシンボル長に相当する時間を示すサブフレーム番号、スロット番号、システムフレーム番号（ＴＳ３６．２１１に規定されているもの相当）の同期をとることも有効である。
【０６５１】
あるいは、ｅＮＢは、指定されたＳＲＳ送信時間に対してサイクリックプリフィックス（Cyclic Prefix：ＣＰ）長以上の所定の時間範囲内の信号の受信を行えるようにする。あるいは、ＳＲＳのＯＦＤＭシンボルのみＣＰ長を他のデータより長くするもの有効である。あるいは、ＳＲＳ送信を開始するときに、データ部分も含めてＣＰ長が長いスロットフォーマットにすることも有効である。あるいは、ＵＥがｅＮＢ毎に送信する基準タイミング、例えばサブフレーム番号、スロット番号またはシステムフレーム番号の先頭のタイミングを変更することも有効である。
【０６５２】
以上のようにすることによって、ＵＬ  ＣｏＭＰを開始する前に、ＵＬ  ＣｏＭＰ対象のｅＮＢ＃２  ５１０３は、ＵＥ５１０５のＳＲＳの受信によって、上りの通信品質が分かる。ｅＮＢ＃１  ５１０１、ｅＮＢ＃２  ５１０３が、ともに上り受信品質５１０９，５１１２をセントラルエンティティ５１０６に報告することによって、セントラルエンティティ５１０６では、２つのｅＮＢに最適なリソース割り当てを行うことができる。
【０６５３】
ＵＬ  ＣｏＭＰ開始までの遅延時間（開始指示後、上りの品質測定を行う時間）が不要となり、直ちにＵＬ  ＣｏＭＰを開始でき、遅延時間で発生する最適化できていない周波数、時間、送信電力の割り当てをなくすことができる。
【０６５４】
前述のＳＲＳ  ｃｏｎｆｉｇの通知方法では、Ｘ２インタフェース５１１５経由としたが、セントラルエンティティあるいはＭＭＥ５１０６経由でもよい。
【０６５５】
この際には、セントラルエンティティは、選択したｅＮＢに、ｅＮＢ＃１  ５１０１のｅＮＢ識別子を通知する。ｅＮＢは、複数選択されてもよい。
【０６５６】
また、ＵＥ５１０５に、選択したｅＮＢのｅＮＢ識別子を通知してもよい。
【０６５７】
前述のＣｏＭＰ開始前の手順では、ＣｏＭＰ対象ＵＥに、ＳＲＳ送信指示を行った後に、隣接するｅＮＢ＃２  ５１０３に、ＳＲＳ  ｃｏｎｆｉｇ５１１６を通知したが、隣接するｅＮＢ＃２  ５１０３で割り当てたいＳＲＳ用リソース、例えば、周波数、時間（サブフレーム番号）、リソースブロック番号が既に使われている場合を考えて、ＵＥへの通知前に、隣接するｅＮＢに、ＳＲＳ  ｃｏｎｆｉｇを通知してもよい。
【０６５８】
あるいは、ＳＲＳ  ｃｏｎｆｉｇのＳＲＳ用リソースと、ｅＮＢ＃２  ５１０３の使用中のＳＲＳ用リソースとが同じにならないように、ｅＮＢ＃２  ５１０３において、ｅＮＢ＃２のＳＲＳ使用開始時に使用状況を、隣接するｅＮＢ（ｅＮＢ＃１  ５１０１）に通知しておいてもよい。ｅＮＢ＃２  ５１０３の傘下の他のＵＥからのＳＲＳと重ならないようにすることによって、ｅＮＢ＃２  ５１０３におけるＵＥからのＳＲＳの受信品質をさらに向上させることができる。
【０６５９】
前述のＳＲＳ送信開始判断の例では、セルの境界にいることを検出したタイミングで、ｅＮＢ＃１  ５１０１が、ＵＥ５１０５にＳＲＳ送信開始指示を通知することによって、使われないときのＳＲＳ送信を最小限にすることができるが、ｅＮＢ＃１  ５１０１のセル半径が小さいときなど、ＳＲＳ送信開始指示を行う処理時間を省くために、ＵＥ５１０５がｅＮＢ＃１  ５１０１と通信を開始したときに予めＳＲＳ送信開始  ｃｏｎｆｉｇを設定してもよい。
【０６６０】
前記ＳＲＳ送信指示では、リソース位置を指定する情報に加えて、セル個別パラメータではなく、少なくとも１つのＵＥ個別のパラメータを送信したが、例えばＳ−ＴＭＳＩ（SAE(System Architecture  Evolution) Temporary Mobile Station Identifier）、ＩＭＳＩ（International Mobile Station Identifier）などのＵＥを特定するＩＤを通知するようにしてもよい（例：ｎＲＳＩＤ＝Ｓ−ＴＭＳＩ、ｎＲＳＩＤ＝ＩＭＳＩ）。
【０６６１】
前記ＳＲＳ送信指示では、セル個別パラメータではなく、少なくとも１つのＵＥ個別のパラメータを送信したが、特定の区域内、例えばトラッキングエリア内、またはＣｏＭＰセット（CoMP set）内、もしくは隣接セル群をクラスタ化して管理したときのクラスタ内で、共通に使用するＳＲＳのプールを用意してもよい。地下街に設置されているｅＮＢと、野外に設置されているｅＮＢのように、隣接セル群は、互いに電波が届かない場所に設置されていても、地理的に近いセルを１つのグループとしてＳＲＳ用ＩＤを共有する方式も有効である。セントラルエンティティあるいはＭＭＥ５１０６でＩＤの管理を行い、その払い出したＩＤをサービングセル経由でＵＥにＳＲＳ指示で通知するようにしてもよい（例：ｎＲＳＩＤ＝エリア内ＩＤ）。
【０６６２】
これによって、特定の区域内で共通のＳＲＳとなるので、該区域内ｅＮＢが予めＳＲＳ受信可能となる。
【０６６３】
前記ＳＲＳ送信指示では、セル個別パラメータではなく、少なくとも１つの、時間多重、あるいは、周波数多重、あるいは、符号多重、あるいは、これらの組合せを行うことで、複数のセル個別パラメータを同時に通知してもよい。この際には、ｅＮＢ＃２  ５１０３からｅＮＢ＃１  ５１０１に、セルＩＤ等のセル個別パラメータを少なくとも１つ含むＳＲＳ  ｃｏｎｆｉｇを送信する。ｅＮＢ＃１  ５１０１は、この情報をＵＥ５１０５に通知する。これによって、ＵＥ５１０５が、ｅＮＢ＃１  ５１０１個別のＳＲＳと同時に、ｅＮＢ＃２  ５１０３個別のＳＲＳを送信することができる。
【０６６４】
また、ｅＮＢ＃１  ５１０１からｅＮＢ＃２  ５１０３に通知されるＳＲＳ  ｃｏｎｆｉｇ５１１６とともに、ｅＮＢ＃２  ５１０３で使用しているリソースを多重していることを同定できる情報も通知してもよい。これによって、ｅＮＢ＃２  ５１０３で、ＵＥ５１０５のＳＲＳが受信可能となる。
【０６６５】
また、ＳＲＳ送信方式を変更することによって送信ビット数が減少し、ＳＲＳの送信電力が不足する場合は、それに応じた送信電力オフセットを加算してもよい。
【０６６６】
また、ｅＮＢ＃１  ５１０１からの通知先であるｅＮＢ＃２  ５１０３は、以上の説明では、ＵＬ  ＣｏＭＰを行う可能性のある隣接ｅＮＢとしているが、具体的には、ＵＬ  ＣｏＭＰ対象となるｅＮＢでもよい。または、ＵＬ  ＣｏＭＰセット内の全てのセルでもよい。
【０６６７】
ＵＥへのＳＲＳ送信指示は、ＲＲＣを用いた例を記載しているが、ＭＡＣシグナリング、Ｌ１／Ｌ２制御信号（例えばＰＤＣＣＨ／ＥＰＤＣＣＨ）で指示してもよい。
【０６６８】
次に、下りについて説明する。
【０６６９】
上り同様に、ＤＬ  ＣｏＭＰが検討されている。例えば、両方のセルから送信を行う結合処理（Joint Processing：ＪＰ）、ならびに、多地点間協調スケジューリングを行うＣＳが検討されている。ＪＰは、結合送信（Joint Transmission：ＪＴ）とＤＰＳ（Dynamic Point Selection）とに分類される。また、ＪＴとＣＳとの組合せ方式も検討されている。これらの方法を用いて、セルエッジでのスループットの向上、システムスループットの増大を図ることができる。
【０６７０】
特に、ＣｏＭＰを行う信号が時分割複信（Time Division Duplex：ＴＤＤ）の場合は、上りおよび下りが同一周波数であることから、上りＳＲＳから伝送路推定を行うことによって、下りの伝送路を推定することができるので、ＤＬ  ＣｏＭＰに使用することができる。
【０６７１】
ＴＤＤ時の、下りＣＳの例で説明する。ＤＬ  ＣｏＭＰでは、ｅＮＢ＃１  ５１０１は、ＵＥ５１０５に送信したいデータが発生すると、ＵＥ５１０５にデータを送信する。
【０６７２】
ｅＮＢ＃１  ５１０１は、ＵＥ５１０５がセルの境界にいることを検出すると、ＲＲＣを用いて、ＵＥ５１０５にＳＲＳ送信指示を通知する。非特許文献１４（５．５．１．５参照）では、ＳＲＳ信号を規定する擬似乱数を発生させるためのパラメータｎＲＳＩＤはＮｃｅｌｌＩＤとなっており、セル毎の値（セルＩＤ）になっているが、本発明では、ＳＲＳ送信指示は、少なくとも１つのＵＥ個別のパラメータを指定する。すなわち、ＵＥ５１０５はセル独自のＳＲＳ信号ではなく、ＵＥ独自のＳＲＳ信号を送信する。
【０６７３】
また、ｅＮＢ＃１  ５１０１は、ＤＬ  ＣｏＭＰを行う可能性のあるｅＮＢ＃１に隣接したｅＮＢ＃２  ５１０３に、Ｘ２経由で直接、ＳＲＳ  ｃｏｎｆｉｇを通知する。ｅＮＢ＃２では、ＳＲＳ  ｃｏｎｆｉｇに従って、ＵＥ５１０５のＳＲＳを受信開始する。
【０６７４】
以上により、ＴＤＤの場合は、ＤＬ  ＣｏＭＰを開始する前にＤＬ  ＣｏＭＰ対象のｅＮＢ＃２がＵＥのＳＲＳ受信によって、下りの通信品質が分かる。ｅＮＢ＃１、ｅＮＢ＃２は、ともに上り受信品質をセントラルエンティティ５１０６に報告することによって、セントラルエンティティ５１０６では、２つのｅＮＢに最適なリソース割り当てを行うことができる。
【０６７５】
ＤＬ  ＣｏＭＰ開始までの遅延時間、すなわち、開始指示後、ＵＥにおいて下りの品質測定を行う時間が不要となり、直ちにＤＬ  ＣｏＭＰを開始することができ、遅延時間で発生する最適化できていない周波数、時間、送信電力の割り当てをなくすことができる。
【０６７６】
下りも上りと同様の変形例がある。
【０６７７】
ＳＲＳ  ｃｏｎｆｉｇの通知方法では、Ｓ１経由（ＭＭＥ経由）でもよい。あるいは、ｉｎｔｅｒ−ｅＮＢ  ＣｏＭＰのリソース割り当てを司るセントラルエンティティの機能部経由であってもよい。
【０６７８】
この際には、セントラルエンティティは、選択したｅＮＢに、ｅＮＢ＃１  ５１０１のｅＮＢ識別子を通知する。ｅＮＢは、複数選択されてもよい。
【０６７９】
また、ＵＥ５１０５に、選択したｅＮＢのｅＮＢ識別子を通知してもよい。
【０６８０】
ＣｏＭＰ開始前の手順では、ＵＥへの通知前に、隣接ｅＮＢにＳＲＳ  ｃｏｎｆｉｇを通知するのもよい。
【０６８１】
あるいは、ｅＮＢ＃２  ５１０３において、ｅＮＢ＃２のＳＲＳ使用開始時に使用状況を隣接ｅＮＢ（ｅＮＢ＃１）に通知しておくのもよい。
【０６８２】
ＳＲＳ送信開始判断の例では、ＵＥ５１０５がｅＮＢ＃１と通信を開始したときに予めＳＲＳ送信開始  ｃｏｎｆｉｇを設定してもよい。
【０６８３】
ＳＲＳ送信指示に含む、少なくとも１つのＵＥ個別のパラメータは、例えばＳ−ＴＭＳＩ、ＩＭＳＩなどのＵＥを特定するＩＤを通知することでもよい（例：ｎＲＳＩＤ＝Ｓ−ＴＭＳＩ、ｎＲＳＩＤ＝ＩＭＳＩ）。
【０６８４】
ＳＲＳ送信指示では、特定の区域内、例えばトラッキングエリア内、またはＣｏＭＰセット内、もしくは隣接セル群をクラスタ化して管理したときのクラスタ内で、共通に使用するＳＲＳのプールを用意してもよい。セントラルエンティティあるいはＭＭＥ５１０６でＩＤの管理を行い、その払い出したＩＤをサービングセル経由でＵＥにＳＲＳ指示で通知するようにしてもよい（例：ｎＲＳＩＤ＝ＳＲＳ用プールＩＤ）。
【０６８５】
これによって、特定の区域内で共通のＳＲＳとなるので、該区域内ｅＮＢが予めＳＲＳ受信可能となる。
【０６８６】
ＳＲＳ送信指示では、セル個別パラメータではなく、少なくとも１つのＵＥ個別のパラメータを送信したが、時間多重、あるいは、周波数多重、あるいは、符号多重、あるいは、これらの組み合わせを行うことで、複数のセル個別パラメータを同時に通知してもよい。この際には、ｅＮＢ＃１  ５１０１からｅＮＢ＃２  ５１０３へのＳＲＳ  ｃｏｎｆｉｇ５１１６に、ｅＮＢ＃２  ５１０３で使用しているリソースを多重していることを同定できる情報も通知する。
【０６８７】
また、ｅＮＢ＃１  ５１０１からの通知先であるｅＮＢ＃２  ５１０３は、上記では、ＤＬ  ＣｏＭＰを行う可能性のある隣接ｅＮＢとしているが、具体的には、ＤＬ  ＣｏＭＰ対象となるｅＮＢでもよい。または、ＤＬ  ＣｏＭＰセット内の全てのセルでもよい。あるいは、ＩＤ管理に対応したトラッキングエリア内の該当するｅＮＢ、および隣接セル群をクラスタ化して管理したとき、そのクラスタ内のｅＮＢでもよい。前記トラッキングエリア内の該当するｅＮＢおよび前記クラスタ内のｅＮＢは、複数でもよい。
【０６８８】
ＵＥへのＳＲＳ送信指示は、ＲＲＣを用いた例を記載しているが、ＭＡＣシグナリング、Ｌ１／Ｌ２制御信号（例えばＰＤＣＣＨ／ＥＰＤＣＣＨ）で指示してもよい。
【０６８９】
ｅＮＢ＃１  ５１０１は、ＵＥ５１０５がセルの境界、あるいは、他セルの近傍から離れていることを検出すると、Ｘ２インタフェース５１１５経由あるいは、ＭＭＥあるいはセントラルエンティティ５１０６経由で、ｅＮＢ＃２５１０５にＳＲＳ受信停止を通知する。
【０６９０】
ＵＥがメジャメント報告（Measurement Report）メッセージで報告してきた自セル（ｅＮＢ＃１）の報告値、具体的にはＲＳＲＰ、あるいはＲＳＲＱ、あるいは両者が特定の閾値以上かどうかで、セルの境界ではないことを判定してもよい。
【０６９１】
また、ＵＥがメジャメント報告（Measurement Report）メッセージで報告してきた他セル（ｅＮＢ＃２）の報告値、具体的にはＲＳＲＰ、あるいはＲＳＲＱ、あるいは両者が特定の閾値以下かどうかで、他セルの近傍から離れていると判定してもよい。
【０６９２】
また、あるいは、ＣｏＭＰ終了時に、ｅＮＢ＃２にＳＲＳ受信停止を通知してもよい。
【０６９３】
また、ＳＲＳ用パラメータをセル個別パラメータに指定したときに、ｅＮＢ＃２にＳＲＳ受信停止を通知してもよい。
【０６９４】
また、上り制御と下り制御とを同時に行ってもよい。
【０６９５】
実施の形態５  変形例１．
実施の形態５では、ＣｏＭＰの例を説明したが、同様に、ＤＣでのＳＲＳを隣接ｅＮＢで受信することによって、ＤＣ開始およびＤＣ構成変更後の遅延時間、すなわち開始指示後、ＵＥにおいて下りの品質測定を行う時間が不要となり、直ちにＤＣを開始することができ、遅延時間で発生する最適化できていない周波数、時間、送信電力の割り当てをなくすことができる。
【０６９６】
ＤＣは、非特許文献９（８章参照）に記載があるように、いくつかの形態が検討されているが、アーキテクチャ１Ａとアーキテクチャ３Ｃの検討が進められている。以下、アーキテクチャ３Ｃの例を、後述する図２７を用いて説明する。
【０６９７】
Ｓ−ＧＷ５２１７は、１ユーザあたりに２つのベアラを割り当てる。ベアラ１は、Ｓ１−Ｕ経由でＭｅＮＢ５２１８からＵＥ５２２０に送信するベアラである。ベアラ２は、Ｓ１−Ｕ経由でＭｅＮＢ５２１８に到達した信号が、ＰＤＣＰ処理部において、２つに分離される。１つは、ＭｅＮＢ５２１８において、ＲＬＣ（Radio Link Control）、ＭＡＣ処理され、ＵＥ５２２０に送信される。もう１つは、ＳｅＮＢ５２１９において処理され、ＵＥ５２２０に送信される。
【０６９８】
例えば、ベアラ１として、モビリティを管理するための制御信号を適用し、ベアラ２として、動画などのユーザパケットデータを適用する。これによって、セルの半径が大きいＭｅＮＢにおいて、高速移動でも通信を継続可能とすることができる。また、ＳｅＮＢは、セルの半径が小さいので、少ないユーザで周波数帯域を使用することができ、大容量通信が可能となる。
【０６９９】
図２６および図２７は、実施の形態５の変形例１の通信システムにおけるＤＣの動作の一例を示す図である。図２６および図２７を用いて、本変形例におけるＤＣ開始時の動作について説明する。
【０７００】
ＭｅＮＢ５２０１の通信領域５２０２にいるＵＥ５２０５は、モビリティ管理用の制御信号も、ユーザパケットデータも、Ｓ−ＧＷ５２０６とＭｅＮＢ５２０１とを経由して通信している。ＵＥ５２０５が、ＳｅＮＢ５２０３の通信領域５２０４に入り、ＵＥ５２０５、ＭｅＮＢ５２０１、ＳｅＮＢ５２０３がＤＣ可能であるとき、ＤＣに再構成（SeNB addition）され、２つのベアラが異なるパスに設定される。
【０７０１】
例えば、ベアラ１は、Ｓ−ＧＷ（５２０６）、Ｓ１（５２１４）、ＭｅＮＢ（５２０１）、無線伝搬路（５２０７）およびＵＥ（５２０５）のパスに設定される。ベアラ２は、Ｓ−ＧＷ（５２０６）、Ｓ１（５２１４）およびＭｅＮＢ（５２０１）で分離される。そのうち、１つは、ＭｅＮＢ（５２０１）、無線伝搬路（５２０７）およびＵＥ（５２０５）のパスに設定される。もう１つは、ＭｅＮＢ（５２０１）、Ｘ２（５２１５）、ＳｅＮＢ（５２０３）、無線伝搬路（５２１０）およびＵＥ５２０５のパスに設定される。
【０７０２】
ここで、ＵＥ５２０５は、ＳｅＮＢと同期を確立し、通信品質の測定を行わないと、実際にデータの通信が開始できないという問題がある。また、ベアラ２を分離するとき、無線伝搬路５２１０の通信品質が分からないという問題がある。
【０７０３】
そこで、実施の形態５に記載した方法と同じ方法で、ｅＮＢ＃１からＭｅＮＢ、ｅＮＢ＃２からＳｅＮＢとすることによって、通信しているＭｅＮＢだけではなく、隣接セルであるＳｅＮＢでも、予めＳＲＳが受信できるようになる。これによって、ＳｅＮＢ５２０３は、ＤＣ開始時に、無線伝搬路の品質確認待ちをせずに、即座にデータの送信が可能となる。
【０７０４】
また、ＭｅＮＢ５２０１は、無線伝搬路の品質確認待ちを行うことなく、自ら受信するＳＲＳ５２０８の受信結果だけでなく、Ｘ２（５２１５）経由でＳｅＮＢ５２０３が受信するＳＲＳ５２１２の受信品質などの受信結果５２１３を考慮して、ベアラ２の分割の割合を決定後、ＤＣ開始が可能となる。
【０７０５】
また、ＳｅＮＢ５２０３でも、ＳＲＳ５２１２を受信することによって、ＭｅＮＢ５２０１とＳｅＮＢ５２０３のタイミング差異を精度良く検出することが可能となる。ＳｅＮＢ５２０３のＳＲＳ受信タイミング情報を通知することによって、ＭｅＮＢ５２０１における上りＰＤＣＰでの到達パケットの順番組立（リオーダリング）待ち受けタイマの値を、ＤＣ開始時にバックホール遅延を考慮して設定することができる。ＳＲＳ受信タイミング情報は、ＳＲＳ受信結果５２１３と一緒に通知してもよい。
【０７０６】
以上の説明では、ＤＣ開始トリガについて、ＵＥ５２０５、ＭｅＮＢ５２０１、ＳｅＮＢ５２０３がＤＣ可能であるときと記載したが、具体的には、以下の（１）〜（４）の４つの条件のうち、少なくとも１つは必要となる。
【０７０７】
（１）ＵＥ５２０５のケーパビリティ（capability）がＤＣに対応しているとき。
（２）ＭｅＮＢ５２０１、ＳｅＮＢ５２０３がいずれもＤＣ設定可能であるとき。
（３）使用可能なＸ２  ５２１５などのバックホールの伝送遅延がＤＣ実施上許容範囲内であるとき。
（４）ＵＥ５２０５がＭｅＮＢ５２０１、ＳｅＮＢ５２０３の両方のカバレッジエリア内、あるいは、その近傍にいることを検出したとき。
【０７０８】
以上の説明では、アーキテクチャ３Ｃの例で説明したが、アーキテクチャ１Ａも同様に、ＳＲＳ  ｃｏｎｆｉｇ５２１６をＸ２経由、あるいは、Ｓ１（ＭＥＥ）経由、あるいは、セントラルエンティティ経由でＳｅＮＢに通知することによって、ＳｅＮＢはＤＣ開始時に、無線伝搬路の品質確認待ちをせずに、即座にデータの送信が可能となる。
【０７０９】
以上の説明では、ＳｅＮＢ追加について説明したが、ＳｅＮＢ変更についても同様である。同時に受信可能なＳＲＳを設定するためのＳＲＳ  ｃｏｎｆｉｇを、ＭｅＮＢから事前にターゲットのＳｅＮＢ（Ｔ−ＳｅＮＢ）に通知することによって、ＳｅＮＢ変更時に、無線伝搬路の品質確認待ちをせずに、即座にデータの送信が可能となる。
【０７１０】
以上の説明では、ＳＲＳ  ｃｏｎｆｉｇをＭｅＮＢからＴ−ＳｅＮＢに通知したが、ソースのＳ−ＳｅＮＢからＴ−ＳｅＮＢに通知してもよい。
【０７１１】
実施の形態６．
実施の形態６で解決する課題を図２８に基づいて説明する。図２８は、実施の形態６で解決する課題の概念を示す図である。
【０７１２】
図２８では、通信端末装置である移動端末装置（以下「移動端末（User Equipment：ＵＥ）」という）のうち、参照符号「５３０５」で示されるＵＥが、ハンドオーバ（ＨＯ）元の無線基地局装置であるｅ−ＮＢ＃１（以下「Ｓ−ｅＮＢ」という。）５３０１の電波の送受信可能なセル５３０２内に在圏している状態を示している。ＵＥ５３０５は、ＨＯ５３０７を行い、ＨＯ先の無線基地局装置（以下「Ｔ−ｅＮＢ」という。）５３０３のセル５３０４内に在圏する状態となる。この状態のＵＥが、参照符号「５３０６」で示されるＵＥ５３０６である。
【０７１３】
実施の形態５に記載のように、現在の３ＧＰＰでは、ＳＲＳがセル固有の信号となっている（非特許文献１４  ５．５．１．５参照）。したがって、Ｔ−ｅＮＢ５３０３は、ハンドオーバが完了するまで、対象のＵＥのＳＲＳを受信することができず、受信品質をもとに各ＵＥに対して周波数およびタイミング等のリソース割り当てを行う処理（スケジューリング）を開始するのが遅くなるという問題がある。
【０７１４】
Ｓ−ｅＮＢ５３０１は、ＨＯ元のＵＥ５３０５が在圏しているセル５３０２内で受信通信品質を測定し、同一セル内のスケジューリングを行うものである。一方、Ｔ−ｅＮＢ５３０３は、ＵＥ５３０５からのＳＲＳ５３０９は無く、スケジューリングは行っていない。
【０７１５】
Ｔ−ｅＮＢ５３０３では、ＨＯ後のＵＥ５３０６の状態でしかＳＲＳを受信できないので、周波数特性を考慮した精度が良いスケジューリングを、ＨＯしてきたＵＥ５３０６に対して早期に開始することができなかった。
【０７１６】
特に、スモールセルが多数運用される場合において、セルの半径も小さく、ＵＥの移動時にはスモールセルの変更が短時間に繰り返されることになる。Ｔ−ｅＮＢで、ＵＥ５３０６でスケジューリングを実行する際には、既に、他のセルの傘下へ移動している可能性があった。
【０７１７】
これらの課題を解決する方法として、実施の形態５と同様に、ＳＲＳをセル固有ではなく、ＵＥ固有にすることで、Ｔ−ｅＮＢ５３０３でのスケジューリングを早期に開始することを可能にした通信システムを提案する。
【０７１８】
図２９は、実施の形態６の通信システムにおけるＳＲＳ受信処理のシーケンスの一例を示す図である。
【０７１９】
ステップＳＴ５４０２およびステップＳＴ５４０３において、ＵＥは、Ｓ−ｅＮＢ経由でＳ−ＧＷとパケットデータのやり取りをしている。
【０７２０】
ステップＳＴ５４０１において、Ｓ−ｅＮＢは、ＵＥに対し、受信品質を知るために、メジャメント制御（Measurement Control：ＭＣ）メッセージを送信する。ＵＥは、上記ＭＣメッセージの情報に基づいて、自セルならびに周辺セルの受信品質を測定し、ステップＳＴ５４０４において、メジャメント報告（Measurement Report：ＭＲ）メッセージをＳ−ｅＮＢへ送信する。
【０７２１】
これまでのシーケンスでは、ステップＳＴ５４０４でＭＲメッセージを受信したＳ−ｅＮＢは、ステップＳＴ５４０８において、ＨＯを実行するか否かの判定処理のＨＯ開始判定を行っていたが、本実施の形態では、ステップＳＴ５４０８のＨＯ開始判定よりも前に、ステップＳＴ５４０５において、ＳＲＳ開始判定を行うようにしている。
【０７２２】
ステップＳＴ５４０４のＭＲメッセージによって報告されたＣＲＳの受信品質（ＲＳＲＰ、あるいは、ＲＳＲＱ、あるいは両者）あるいはその他のＲＳの受信品質が、閾値Ｔｈ１より小さい場合は、隣接セルへＨＯする可能性は低いものと判断し、再度ステップＳＴ５４０４のＭＲメッセージ待ちとする。
【０７２３】
ステップＳＴ５４０５のＳＲＳ開始判定において、ステップＳＴ５４０４のＭＲメッセージによって報告された周辺セルの受信品質が、閾値ＴＨ１より大きいか否かを判定する。閾値ＴＨ１より大きい場合（Ｙｅｓの場合）は、当該セルへＨＯする可能性があるものと判断し、ステップＳＴ５４０６において、Ｓ−ｅＮＢから、Ｔ−ｅＮＢへ、ＳＲＳ  Ｃｏｎｆｉｇを含むＳＲＳ受信開始指示メッセージを送信する。Ｔ−ｅＮＢは、ステップＳＴ５４０６のＳＲＳ受信開始指示メッセージを受けて、ステップＳＴ５４０７において、ＳＲＳ受信を開始する。
【０７２４】
Ｘ２シグナリングでＳ−ｅＮＢからＴ−ｅＮＢに直接通知する例として記載したが、Ｓ１シグナリングでＭＭＥ経由で通知してもよい。
【０７２５】
Ｓ−ｅＮＢは、ステップＳＴ５４０６においてＳＲＳ受信開始指示を行った後、ステップＳＴ５４０８のＨＯ開始判定において、ＨＯをするかどうかの判定を行う。
【０７２６】
以降のＨＯのシーケンスは、現在のシーケンスと同じである。
【０７２７】
本実施の形態では、ステップＳＴ５４０８のＨＯ開始判定とは別に、ステップＳＴ５４０５のＳＲＳ開始判定を設けることによって、ＨＯするよりも前に、ステップＳＴ５４０７においてＳＲＳ受信が開始できる。
【０７２８】
上記ステップＳＴ５４０５のＳＲＳ開始判定は、一度「Ｙｅｓ」と判定した後、ステップＳＴ５４０８のＨＯ開始判定において、ＨＯ未実行となった場合、再度ステップＳＴ５４０４のＭＲメッセージを受信したときは、再度、ステップＳＴ５４０５のＳＲＳ開始判定を実行し、ステップＳＴ５４０６でＳＲＳ受信開始指示を通知してもよいが、しなくてもよい。余分な開始指示を行わないことで、ＣＰＵ（Central Processing Unit）などの処理負荷を軽減することが可能となる。ステップＳＴ５４０５のＳＲＳ開始判定において「Ｎｏ」と判定した場合、Ｓ−ｅＮＢは、ステップＳＴ５４０５のＭＲメッセージ待ち状態になる。
【０７２９】
図３１は、測定報告値に対するＳＲＳ受信開始閾値とＨＯ開始閾値との違いを示すための図である。
【０７３０】
ＨＯを開始するための閾値Ｔｈ２とは別に、本発明の実施形態となるＳＲＳ開始のための閾値Ｔｈ１を設ける。
【０７３１】
Ｓ−ｅＮＢは、閾値Ｔｈ１を閾値Ｔｈ２より低い値に設定してもよい。これによって、ＨＯより先に、Ｔ−ｅＮＢにてＳＲＳの受信が可能になり、Ｔ−ｅＮＢにて、早期に周波数スケジューリングが可能となる。
【０７３２】
上記では、閾値Ｔｈ１を閾値Ｔｈ２より低い値としたが、閾値Ｔｈ１と閾値Ｔｈ２とが同じ値（Ｔｈ１＝Ｔｈ２）としてもよい。このときは、ＳＲＳ開始判定でＳＲＳ受信開始指示（ＳＲＳ  ｃｏｎｆｉｇを含む）を通知するとともに、ＨＯ要求（HO Request）を通知する。ＳＲＳ受信開始指示とＨＯ要求とが１つのメッセージでもよい。
【０７３３】
閾値Ｔｈ１と閾値Ｔｈ２とを同じ値（Ｔｈ１＝Ｔｈ２）とした場合、閾値Ｔｈ１を閾値Ｔｈ２よりも低い値とした場合に比べて、Ｔ−ｅＮＢは、ＳＲＳ受信開始が遅くなるが、ステップＳＴ５４１４においてＨＯが完了（RRC Connection Reconfiguration Complete）するよりも早く、ＳＲＳの受信を開始することができる。また、閾値Ｔｈ１を閾値Ｔｈ２よりも低い値とした場合に比べて、Ｓ−ｅＮＢでの判定処理を軽減することができる。
【０７３４】
セルの大きさに対して、ＵＥ５３０５が非常に速く移動する際は、移動先であるＴ−ｅＮＢでＳＲＳが受信できても、有効にスケジューリングができない場合がある。そのような場合は、ＳＲＳ受信処理を行わないために、Ｓ−ｅＮＢ５３０１からＴ−ｅＮＢ５３０３へ送信するＳＲＳ受信開始指示メッセージ、あるいは、ＨＯ要求メッセージなどに、ＵＥ５３０５の速度情報、例えばＵＥの移動状態（high、medium、normal）、ハンドオーバまたはセルチェンジしてきた回数（特定時間あたりのハンドオーバまたはセルチェンジ回数も有効）、ＧＰＳによる位置の変動（特定時間あたりの位置の移動も有効）、セル毎の滞在時間も含ませるとよい。Ｔ−ｅＮＢ５３０３の配下においても同様に、高速移動時にＳＲＳ５３０９を抑制することが可能になる。
【０７３５】
先に述べたＳＲＳ受信開始指示を実行するトリガは、ＵＥからの報告された受信品質に基づいて、Ｓ−ｅＮＢ５３０１が判定を行うものであったが、ＵＥ５３０５が判定を行って、判定結果をＳ−ｅＮＢ５３０１に送信し、ＳＲＳ受信開始指示を行ってもよい。
【０７３６】
例えば、ＵＥ５３０５は、セル毎の受信品質が所定の閾値以上であるかどうかを示す情報をＭＲに含めて通知することとしてもよい。
【０７３７】
あるいは、ＵＥ５３０５は、周辺セルの受信品質が所定の閾値以上であるとき、セル毎にＳＲＳ受信した方がよいことを示すＳＲＳ受信要求もＭＲに含めて通知してもよい。
【０７３８】
あるいは、ＵＥ５３０５は、ＭＲとは別に、受信品質が所定の閾値を超えたことを、超えたときに、対象のセルを同定するＩＤとともに通知してもよい。
【０７３９】
以上のようにすることによって、Ｓ−ｅＮＢにおいて、ＭＲで受信品質判定負荷を軽減することができる。
【０７４０】
上記では、ＵＥは、既にＵＥ個別パラメータによるＳＲＳを送信している前提で、他セルに対するＳＲＳ受信開始について説明した。次に、ＵＥがＳＲＳ送信を開始する判定処理について説明する。
【０７４１】
ＵＥがＳＲＳを送信するには、送信電力を消費するので、ＨＯする前後等にのみＳＲＳを送信する、あるいは、ＨＯする前後等にのみＳＲＳの送信間隔をより長くするのが有効である。
【０７４２】
ステップＳＴ５４０５のＳＲＳ開始判定では、前述の処理に加えて、ステップＳＴ５４０４のＭＲメッセージによって報告された自セル（Ｓ−ｅＮＢ）のＣＲＳの受信品質（ＲＳＲＰ、あるいは、ＲＳＲＱ、あるいは両者）あるいはその他のＲＳの受信品質が、所定の閾値より小さい（例えば、閾値Ｔｈ２より小さい）かどうか、または、他セルの受信品質が閾値Ｔｈ１より大きいかどうかを判定する。判定結果が、どちらか一方、あるいは、両方を満たす場合は、隣接セルへＨＯする可能性が高いものと判断し、ＵＥへのＳＲＳ  ｃｏｎｆｉｇを含む送信指示を通知する。
【０７４３】
Ｓ−ｅＮＢは、例えば、ステップＳＴ５４１７のＲＲＣ接続再設定（RRC Connection Reconfiguration）メッセージに、ＳＲＳ  ｃｏｎｆｉｇを含ませて送信するとよい。これによって、ＵＥは、ＳＲＳ送信を開始、あるいは、ＳＲＳ送信頻度を増加させる。
【０７４４】
ＳＲＳの受信開始のタイミングとして、Ｔ−ｅＮＢ５３０３が、ＵＥ５３０５のＳＲＳ  ｃｏｎｆｉｇ５３１１を受信後、直ちに該ＳＲＳ５３０９を受信し、スケジューリングを実施するとしているが、Ｔ−ｅＮＢ５３０３、ＵＥ５３０５からのＳＲＳ５３０９を、スケジューリングする前に少なくとも１回は受信するとしてもよい。
【０７４５】
あるいは、Ｔ−ｅＮＢ５３０３がＵＥ５３０５からのＳＲＳを、ＨＯ  ａｃｋを送信する前に少なくとも１回は受信するとしてもよい。
【０７４６】
また、Ｓ−ｅＮＢによるＵＥへのＳＲＳ送信指示は、ＲＲＣを用いた例を記載しているが、ＭＡＣシグナリング、Ｌ１／Ｌ２制御信号（例えばＰＤＣＣＨ／ＥＰＤＣＣＨ）で指示してもよい。
【０７４７】
また、Ｓ−ｅＮＢによるＵＥへのＳＲＳ送信指示は、ＳＲＳ送信停止指示が送られるまで有効としてもよい。また、所定の期間周期的に送信する指示としてもよい。
【０７４８】
また、ＵＥは、ＭＣＩ（Mobility Control Information）を受信後、Ｔ−ｅＮＢと同期確立を行った場合は、該ＳＲＳを送信停止してもよい。
【０７４９】
図２９に示すＳ−ｅＮＢからＴ−ｅＮＢへのＨＯのシーケンスは以下となる。
【０７５０】
ステップＳＴ５４０９において、Ｓ−ｅＮＢより、Ｔ−ｅＮＢへＨＯ要求が送信される。ステップＳＴ５４１０において、Ｔ−ｅＮＢによってアドミッション制御（Admission Control）が実行された後、ステップＳＴ５４１１において、Ｔ−ｅＮＢからＳ−ｅＮＢへ「HO Request Ack」が返信される。
【０７５１】
前記Ａｃｋを受信したＳ−ｅＮＢは、ステップＳＴ５４１２において、ＵＥへＲＲＣ接続再設定（RRC Connection Reconfiguration）を送信した後、ステップＳＴ５４１３において、Ｔ−ｅＮＢへ「SN Status Transfer」を送信する。ステップＳＴ５４１２において、ＵＥは、ＲＲＣ接続再設定（RRC Connection Reconfiguration）を受信し、ＲＲＣ接続の再設定を行い、結果のＲＲＣ接続再設定完了（RRC Connection Reconfiguration Complete）を、ステップＳＴ５４１４において、Ｔ−ｅＮＢへ送信する。これによって、ステップＳＴ５４１５およびステップＳＴ５４１６において、ＵＥは、Ｔ−ｅＮＢ経由でＳ−ＧＷとパケットデータのやり取りができる。
【０７５２】
Ｔ−ｅＮＢにおけるＳＲＳ受信の停止は、例えば、ステップＳＴ５４１４において、Ｔ−ｅＮＢがＲＲＣ接続再設定完了（RRC Connection Reconfiguration Complete）を受信後、停止を行うとすればよい。ＨＯ失敗であっても同様に受信を停止する。
【０７５３】
あるいは、ステップＳＴ５４１３において、「SN Status Transfer」をＳ−ｅＮＢから受信したタイミングでもよい。更には、ステップＳＴ５４１１において、Ｔ−ｅＮＢが「HO Request Ack」をＳ−ｅＮＢへ送信したタイミングであってよい。
【０７５４】
以上に述べたシーケンスでは、ＨＯ終了後ＳＲＳの受信の停止を前提としているが、切り戻しを考慮してＨＯ失敗後もＳＲＳ受信を継続してもよい。
【０７５５】
その場合の停止方法として、タイマを設けて所定時間確保した後、ＳＲＳを停止する。タイマの満了後、再度閾値を確認して判定してもよい。あるいは、ＵＥからＳＲＳ受信停止指示がＲＲＣで送信されるまで実行するとしてもよい。あるいは、ＵＥからの周辺セルサーチ情報に基づいて、サービングセルがＸ２経由でＳＲＳ受信停止を指示するまで実行するとしてもよい。
【０７５６】
他に、メジャメント結果の判定閾値を更に１つ追加して、ＳＲＳ停止指示の判定に用いる。他セルへのＨＯ開始より早く閾値を越える値を設定してもよい。この場合のシーケンスを図３０に示す。図３０は、実施の形態６の通信システムにおけるＳＲＳ受信処理のシーケンスの他の例を示す図である。
【０７５７】
ステップＳＴ５５０１において、Ｔ−ｅＮＢは、ＵＥへＭＣメッセージを送信する。ステップＳＴ５５０２において、ＵＥは、ＭＲメッセージを送信する。Ｔ−ｅＮＢは、ステップＳＴ５５０２のＭＲメッセージを受けて、ステップＳＴ５５０３において、ＳＲＳの要否判定、すなわちＳＲＳを停止するか否かの判断を行う。具体的には、ステップＳＴ５５０２のＭＲメッセージで報告された自セル（Ｔ−ｅＮＢ）の受信品質値が、閾値Ｔｈ３よりも小さいか否か、あるいは、Ｓ−ｅＮＢの受信品質値が、所定の閾値よりも小さいか否かを判断する。所定の閾値は、例えば、閾値Ｔｈ１である。所定の閾値は、閾値Ｔｈ１よりも小さい閾値Ｔｈ４でもよい。
【０７５８】
ステップＳＴ５５０２のＭＲメッセージで報告された自セル（Ｔ−ｅＮＢ）の受信品質値が、閾値Ｔｈ３よりも小さい、あるいは、Ｓ−ｅＮＢの受信品質値が、所定の閾値を下回った場合、ＳＲＳの受信を継続すると判断してステップＳＴ５５０２に戻り、ステップＳＴ５５０２のＭＲメッセージの待ち状態とする。ステップＳＴ５５０２のＭＲメッセージで報告された自セル（Ｔ−ｅＮＢ）の受信品質値が閾値Ｔｈ３以上である、あるいは、Ｓ−ｅＮＢの受信品質値が所定の閾値以上である場合は、ステップＳＴ５５０４において、ＳＲＳの受信を停止する。
【０７５９】
Ｔ−ｅＮＢは、対象ＵＥのＳＲＳ受信結果に基づいて、ＨＯ受け入れ可否（Handover Request Ack）を判断してもよい。その場合、受け入れＮＧの要因として「ＳＲＳ受信結果ＮＧ」を通知するとよい。
【０７６０】
Ｔ−ｅＮＢは、対象ＵＥのＳＲＳ受信結果に基づいて、スケジューリングを行う。
【０７６１】
上り送信電力値をＳＲＳ受信値により調整する（初期ＭＣＳも含める）。セルサイズが異なるｅＮＢが重なるように存在する場合に有効である。
【０７６２】
実施の形態６によって、以下の効果を得ることができる。対象となるＵＥに対するチャネル評価が早期に可能となることで、早期にスケジューリングを行うことができ、周波数効率が改善する。
【０７６３】
実施の形態７．
図３２は、実施の形態７の通信システムにおけるアンテナ制御の一例を示す図である。本実施の形態では、図３２に示すように、ハンドオーバ先ｅＮＢ＃２  ５７０４が、複数のアンテナによる送受信（ＭＩＭＯ）が可能なとき、ハンドオーバ確立前にＳＲＳを受信可能とすることで、ハンドオーバ時すぐにビーム形成等のアンテナ制御を行うことができ、ｅＮＢとＵＥの送信電力を低減可能とする例を説明する。
【０７６４】
ｅＮＢ＃１  ５７０３の通信エリア５７０１で通信しているＵＥ５７０５，５７０６がｅＮＢ＃１  ５７０３のエリア境界にあり、ｅＮＢ＃２  ５７０４の通信エリア５７０２に移動している。
【０７６５】
ｅＮＢ＃２  ５７０４は、複数のアンテナを有し、各アンテナの入力信号の位相、振幅を制御することで、指向性を絞ったビーム５７１１を形成することができる。しかしながら、実施の形態５に記載のように、現在の３ＧＰＰでは、ＳＲＳがセル固有の信号となっており（非特許文献１４  ５．５．１．５参照）、ハンドオーバが完了するまで対象のＵＥのＳＲＳを受信することができず、指向性を絞ったビーム形成ができないという問題がある。
【０７６６】
そこで、実施の形態５と同様に、ｅＮＢ＃１  ５７０３のエリア境界にいることを検出したとき、ｅＮＢ＃１  ５７０３は、ＲＲＣで、ＵＥ５７０５に、複数のｅＮＢで受信可能なＳＲＳ５７０９，５７１０の送信指示をするとともに、ｅＮＢ＃２  ５７０４にＸ２  ５７０７経由でＳＲＳ  ｃｏｎｆｉｇ５７０８を送信することで、ｅＮＢ＃２  ５７０４がＵＥ  ５７０５，５７０６のＳＲＳ信号を受信可能とする。
【０７６７】
上記の具体的な方法としては、実施の形態５、あるいは、実施の形態６を適用してもよい。
【０７６８】
これによって、ｅＮＢ＃２  ５７０４は、複数のアンテナを有し、各アンテナの入力信号の位相、振幅を制御することで、指向性を絞ったビーム５７１１を形成することができる。
【０７６９】
補足すると、例えば、既知系列であるＳＲＳの受信電力が最大になる上りまたは下りの各アンテナ入力信号の位相、振幅値（＝重み付け係数）を調整することで、ビームの指向性を絞る。この重み付けを行ったアンテナで、既知系列以外のデータ部分の受信を行う、あるいは、下り送信を行うことで、指向性を絞ったビームによる通信ができる。これによって、ｅＮＢ＃２  ５７０４、ＵＥ５７０６は、他のｅＮＢおよびＵＥの干渉電力が低減し、良好に受信することができるので、送信電力を低減することができる。
【０７７０】
ＨＯする前のＵＥ５７０５がＳＲＳを送信する場合、指向性アンテナが順次方向を変えて送信を行う場合、例えばθ（ｔ）で送信する方向を時間的に変更する場合、ＨＯ先のＴ−ｅＮＢ５７０４が指向性アンテナを特定できるように、ＨＯする前のＵＥ５７０５は、指向性アンテナ毎に異なるシーケンスパターンを含めるようにしてもよい。
【０７７１】
または、ＨＯする前のＵＥ５７０５がＳＲＳを送信する場合、複数のセクタアンテナのような指向性アンテナでＳＲＳを送信する場合に、指向性アンテナを特定できるように、ＨＯする前のＵＥ５７０５は、指向性アンテナ毎に異なるシーケンスパターンを含めるようにしてもよい。
【０７７２】
また、前述の重み付け係数を決定する方法の例として、ｅＮＢ＃２  ５７０４の通信エリア５７０２を分割し、分割毎でＳＲＳ受信電力値が最大になるものを特定する。ＳＲＳ受信電力が最大になる分割部を更に分割し、ＳＲＳ受信電力値が最大になるものを特定する。以上を繰り返すことで、重み付け係数を決定する方法でもよい。
【０７７３】
また、下り送信においては、ＴＤＤの場合は、上りおよび下りが同一周波数になるため有効である。周波数分割複信（Frequency Division Multiplex：ＦＤＤ）の場合は、上りと下りで周波数が異なるので、周波数に依存した伝搬特性の差が小さい場合に有効である。
【０７７４】
また、前述の実施の形態では、ビームの指向性を絞る制御を説明したが、マルチユーザＭＩＭＯによる全ユーザ一括復調の処理を、ハンドオーバ後、速やかに実行することもできる。全ＵＥの既知系列であるＳＲＳ（ＳＳＲＳ）、伝送路のインパルス応答（Ｈ）、雑音（Ｎ）、受信信号Ｙの関係は、以下に示す式になる。
Ｙ＝Ｈ×ＳＳＲＳ＋Ｎ
【０７７５】
例えば、ＺＦ（Zero Forcing）のアルゴリズムのように、雑音（Ｎ）を無視すれば、Ｈの逆行列を求めることで、ＵＥの送信データを復元できる。ＴＤＤの場合、上り下りの伝搬特性が同じであるので、Ｈの逆行列を送信データに乗じる（プリコーディングする）ことで、ＵＥは、干渉の影響を低減した信号を受信することができる。
【０７７６】
ｅＮＢは、上り受信において、通信エリア（ｅＮＢ＃２  ５７０４の通信エリア５７０２に相当）の全てを覆う指向性のアンテナ・アンテナ群、例えば、指向性なしの等方向受信アンテナを有し、下り送信においては、指向性を有するビームフォーミングを有してもよい。
【０７７７】
また、ｅＮＢにおける受信アンテナは、等方向の指向性を有してもよい。
【０７７８】
または、サービングセルではない隣接したｅＮＢでＳＲＳの受信をすることによって、ＡｏＡ（Angle of Arrival）を導出することができる。また、ｅＮＢの位置を把握している複数ｅＮＢでＡｏＡを測定することによって、３点測量を行い、ＵＥの位置をＧＰＳ（Global Positioning System）を使わずに把握することもできる。
【０７７９】
また、上述の例では、Ｘ２インタフェース５７０７による例を説明したが、実施の形態５と同様に、Ｓ１インタフェース（ＭＭＥ経由）でもよいし、セントラルエンティティ経由でもよい。
【０７８０】
また、ハンドオーバ先をｅＮＢで説明したが、リレーノード（Relay Node：ＲＮ）、ＲＲＨ（Remote Radio Head）が複数のアンテナになっている場合も同様である。
【０７８１】
ＵＥ５７０５，５７０６が、電車などに搭載され、複数のユーザを束ねて移動するＵＥの場合（動くリレーノード）、多くのアンテナを備えてビーム形成を行うことが有効である。
【０７８２】
複数のアンテナを備えているＵＥでは、以下のＳＲＳの送信方法が有効である。ＳＲＳは、ビーム形成を行わず、等方向に送信する。これによって、ｅＮＢ＃１、ｅＮＢ＃２は、オムニアンテナのみ備えているＵＥと同様の処理を行うことで、ハンドオーバ前にＳＲＳ受信を行い、上りおよび下りのビーム形成を速やかに行うことができる。
【０７８３】
また、ＵＥ５７０５が受信できるｅＮＢの同期信号を使って、ＵＥ５７０５の指向性を絞ったビーム形成を行うことも有効である。ＳＲＳも該ビームを使って送信する。これにより、ＵＥ５７０５が送信するＳＲＳの送信電力を低減することができる。
【０７８４】
また、ＵＥ５７０５が同期信号を受信できない可能性があるので、ｅＮＢの存在位置情報を使って、ｅＮＢの同期信号が見えなくてもｅＮＢがある方向に送信する方法でもよい。
【０７８５】
また、ＵＥ５７０５が複数周波数を送受信しているときは、周波数毎に等方ビームと指向性を絞ったビームの両方でＳＲＳを送信してもよい。これによって、ｅＮＢは、上りおよび下りのビーム形成を速やかに行うことができる。
【０７８６】
また、周波数が一つでもＴＤＤの場合、サブフレーム毎に、等方ビームと指向性有りの両方を送信させることが可能となる。
【０７８７】
また、周波数が一つでもＦＤＤの場合、ＴＤＤと同様に、サブフレーム毎に、等方ビームと指向性有りの両方を送信させることが可能となる。
【０７８８】
また、ｅＮＢがスモールセルである場合は、等方ビームとするのも有効である。セルの半径が小さいので、到来角度の変化に対しても安定したＳＲＳ受信が可能となる。
【０７８９】
また、街中を走るバスのようにＵＥ５７０５の移動速度が速いときには、等方ビームでもよい。
【０７９０】
また、新幹線のように多くのＵＥ５７０５が大容量で通信するものについては、移動速度が速くても指向性を絞ったビームでよい。
【０７９１】
ＨＯ先のＴ−ｅＮＢ５７０４がＦＤＤの場合、ＨＯ前のＵＥ５７０５から送信されるＳＲＳ５７１０を受信後、取得した端末情報をダウンリンク（Down Link）チャネルでＵＥ５７０５にフィードバックすることで、ＵＥ５７０５は、上りの個別チャネル情報を、ＨＯ先のＴ−ｅＮＢ５７０４に対して、ビームフォーミング送信が可能となる。
【０７９２】
ＨＯ先のＴ−ｅＮＢ５７０４は、ＨＯ前のＵＥ５７０５から送信されるＳＲＳ５７１０を受信後、周波数補正の要否を判断する必要がある。周波数補正が不要と判断できれば、Ｘ２インタフェース５７０７経由で受信したＳＲＳ  Ｃｏｎｆｉｇ情報をダウンリンクチャネルのビームフォーミングに使用することができる。
【０７９３】
ＨＯ先のＴ−ｅＮＢ５７０４がアレイアンテナのような複数の等方的なアンテナである場合、ＨＯ前のＳ−ｅＮＢ５７０３から通信路５７０７経由で受信したＳＲＳ  Ｃｏｎｆｉｇ５７０８を用いて、ＨＯするＵＥ５７０５のＳＲＳ５７１０を受信し、伝搬特性Ｈを算出することができる。
【０７９４】
また、ＨＯ先のＴ−ｅＮＢ５７０４が複数のセクタアンテナのような指向性アンテナ（同等の指向性をアレイアンテナで形成する場合も含む）でＳＲＳ５７１０の受信電力が大きいところに指向性を向けたプリコーディングを実行し、ビームフォーミング５７１１の送信が可能となる。
【０７９５】
また、ＨＯ先のＴ−ｅＮＢ５７０４の指向性アンテナが、ＵＥ５７０５，５７０６がＳＲＳを送信するタイミングに合せて、順次方向を変える送信を行う場合、ＵＥ５７０５から送信されるＳＲＳ５７１０の受信電力が最大になる時間のときに、ＨＯ先のＴ−ｅＮＢ５７０４が送信していた方向を算出し、その方向に指向性を向けたビームフォーミング５７１１送信が可能となる。
【０７９６】
あるいは、ＨＯ先のＴ−ｅＮＢ５７０４の指向性アンテナが、ＵＥ５７０５，５７０６がＳＲＳを送信するタイミングの倍数のタイミングに合せて、順次方向を変える送信としてもよい。
【０７９７】
あるいは、ＨＯ先のＴ−ｅＮＢ５７０４の指向性アンテナが送信していた方向に対して、ある受信期間にＵＥ５７０５から送信されるＳＲＳ５７１０を少なくとも１回受信したときに、ＨＯ先のＴ−ｅＮＢ５７０４が送信していた方向に対して、指向性を向けえたビームフォーミング５７１１送信が可能となる。
【０７９８】
ＨＯ先のＴ−ｅＮＢ５７０４は、ランダムアクセスプロシージャ（Random Access Procedure）で端末情報を取得し、ビームフォーミング５７１１送信を実行してもよい。ＨＯしようするＵＥ５７０５は、ＨＯ先であるＴ−ｅＮＢ５７０４にＰＲＡＣＨを送信する。ＨＯ先であるＴ−ｅＮＢ５７０５は、ＵＥ５７０５に対して、ランダムアクセス応答（Random Access Response）を送信する。
【０７９９】
ＨＯするＵＥ５７０５は、ランダムアクセスプロシージャにおいて、自ＵＥの位置情報をＴ−ｅＮＢ５７０４に対して通知する。これによって、ＨＯ先であるＴ−ｅＮＢ５７０４は、ランダムアクセスプロシージャにおいて、ＨＯするＵＥ５７０５の位置情報を特定し、その方向に対して、指向性を向けたビームフォーミング５７１１の送信が可能となる。
【０８００】
また、ハンドオーバ時にＨＯ先であるＴ−ｅＮＢ５７０４がＰＲＡＣＨを受信することで、ＡｏＡ（Angle of Arrival）を算出することができ、その方向に対して、指向性を向けたビームフォーミング５７１１送信が可能となる。
【０８０１】
また、ハンドオーバ時にＳＲＳの受信により同期確立を行うことも可能であるので、ＲＡＣＨのシーケンスなしとしてもよい。
【０８０２】
ＨＯする前のＵＥ５７０５が、その他のＵＥと纏まって移動する場合、もしくは、多数のアンテナを有する端末である場合、もしくは、リピータ（Repeater）機能を担っている場合、ＨＯする前のＵＥ５７０５からＨＯ元のＳ−ｅＮＢ５７０３が検出したＨＯ前のＵＥ５７０５の位置情報を、通信路５７０７経由でＳＲＳ  Ｃｏｎｆｉｇ（設定パラメータ値）５７０８をＨＯ先のＴ−ｅＮＢ５７０４に通知する。
【０８０３】
これによって、ＨＯ先のＴ−ｅＮＢ５７０４は、ＨＯ前のＵＥ５７０５から送信されるＳＲＳ５７１０を受信して、プリコーディングマトリックスの導出、すなわちビームフォーミングを行うためのアンテナの重み係数の導出のために用いて、ＨＯ先のＴ−ｅＮＢ５７０４で、ビームフォーミング５７１１の送信が可能となる。
【０８０４】
本実施の形態によって、ＭＩＭＯ時も含め、ＨＯ元の端末からのＳＲＳを受信することで、ビームの指向性、端末の初期送信電力を決めることができ、ＨＯ開始時から適切な通信が可能となる。
【０８０５】
また、ＨＯ時ＵＥにおける受信品質を向上させることができるので、ハンドオーバ失敗（Hand Over Failure：ＨＯＦ）、無線リンク失敗（Radio Link Failure：ＲＬＦ）を低減させることが可能となる。
【０８０６】
本実施の形態で開示した方法は、マルチストリームのビーム形成にも適用することが可能である。
【０８０７】
前述の各実施の形態およびその変形例は、本発明の例示に過ぎず、本発明の範囲内において、各実施の形態およびその変形例を自由に組合せることができる。また各実施の形態およびその変形例の任意の構成要素を適宜変更または省略することができる。これによって、マクロセルに加えて多数のスモールセルを設置して運用する場合にも、ＵＥの通信性能を向上させることができる。
【０８０８】
本発明は詳細に説明されたが、上記した説明は、すべての局面において、例示であって、本発明がそれに限定されるものではない。例示されていない無数の変形例が、本発明の範囲から外れることなく想定され得るものと解される。
【符号の説明】
【０８０９】
１０１  ＣＢＣ、１０２  ＭＭＥ、１０３  ＭｅＮＢ、１０４  ＳｅＮＢ、１０５  ＵＥ、１３０１  マクロｅＮＢ（マクロセル）のカバレッジ、１３０２  スモールｅＮＢ（スモールセル）のカバレッジ。
【図１】
2020198647.tif 000003
【図２】
2020198647.tif 000004
【図３】
2020198647.tif 000005
【図４】
2020198647.tif 000006
【図５】
2020198647.tif 000007
【図６】
2020198647.tif 000008
【図７】
2020198647.tif 000009
【図８】
2020198647.tif 000010
【図９】
2020198647.tif 000011
【図１０】
2020198647.tif 000012
【図１１】
2020198647.tif 000013
【図１２】
2020198647.tif 000014
【図１３】
2020198647.tif 000015
【図１４】
2020198647.tif 000016
【図１５】
2020198647.tif 000017
【図１６】
2020198647.tif 000018
【図１７】
2020198647.tif 000019
【図１８】
2020198647.tif 000020
【図１９】
2020198647.tif 000021
【図２０】
2020198647.tif 000022
【図２１】
2020198647.tif 000023
【図２２】
2020198647.tif 000024
【図２３】
2020198647.tif 000025
【図２４】
2020198647.tif 000026
【図２５】
2020198647.tif 000027
【図２６】
2020198647.tif 000028
【図２７】
2020198647.tif 000029
【図２８】
2020198647.tif 000030
【図２９】
2020198647.tif 000031
【図３０】
2020198647.tif 000032
【図３１】
2020198647.tif 000033
【図３２】
2020198647.tif 000034