実施の形態1.
図2は、3GPPにおいて議論されているLTE方式の通信システム700の全体的な構成を示すブロック図である。図2について説明する。無線アクセスネットワークは、E-UTRAN(Evolved Universal Terrestrial Radio Access Network)70と称される。通信端末装置である移動端末装置(以下「移動端末(User Equipment:UE)」という)71は、基地局装置(以下「基地局(E-UTRAN NodeB:eNB)」という)72と無線通信可能であり、無線通信で信号の送受信を行う。
移動端末71に対する制御プロトコル、例えばRRC(Radio Resource Control)と、ユーザプレイン、例えばPDCP(Packet Data Convergence Protocol)、RLC(Radio Link Control)、MAC(Medium Access Control)、PHY(Physical layer)とが基地局72で終端するならば、E-UTRANは1つあるいは複数の基地局72によって構成される。
移動端末71と基地局72との間の制御プロトコルRRC(Radio Resource Control)は、報知(Broadcast)、ページング(paging)、RRC接続マネージメント(RRC connection management)などを行う。RRCにおける基地局72と移動端末71との状態として、RRC_IDLEと、RRC_CONNECTEDとがある。
RRC_IDLEでは、PLMN(Public Land Mobile Network)選択、システム情報(System Information:SI)の報知、ページング(paging)、セル再選択(cell re-selection)、モビリティなどが行われる。RRC_CONNECTEDでは、移動端末はRRC接続(connection)を有し、ネットワークとのデータの送受信を行うことができる。またRRC_CONNECTEDでは、ハンドオーバ(Handover:HO)、隣接セル(Neighbour cell)の測定(メジャメント(measurement))などが行われる。
基地局72は、eNB76と、Home-eNB75とに分類される。通信システム700は、複数のeNB76を含むeNB群72-1と、複数のHome-eNB75を含むHome-eNB群72-2とを備える。またコアネットワークであるEPC(Evolved Packet Core)と、無線アクセスネットワークであるE-UTRAN70とで構成されるシステムは、EPS(Evolved Packet System)と称される。コアネットワークであるEPCと、無線アクセスネットワークであるE-UTRAN70とを合わせて、「ネットワーク」という場合がある。
eNB76は、移動管理エンティティ(Mobility Management Entity:MME)、あるいはS-GW(Serving Gateway)、あるいはMMEおよびS-GWを含むMME/S-GW部(以下「MME部」という場合がある)73とS1インタフェースにより接続され、eNB76とMME部73との間で制御情報が通信される。一つのeNB76に対して、複数のMME部73が接続されてもよい。eNB76間は、X2インタフェースにより接続され、eNB76間で制御情報が通信される。
Home-eNB75は、MME部73とS1インタフェースにより接続され、Home-eNB75とMME部73との間で制御情報が通信される。一つのMME部73に対して、複数のHome-eNB75が接続される。あるいは、Home-eNB75は、HeNBGW(Home-eNB GateWay)74を介してMME部73と接続される。Home-eNB75とHeNBGW74とは、S1インタフェースにより接続され、HeNBGW74とMME部73とはS1インタフェースを介して接続される。
一つまたは複数のHome-eNB75が一つのHeNBGW74と接続され、S1インタフェースを通して情報が通信される。HeNBGW74は、一つまたは複数のMME部73と接続され、S1インタフェースを通して情報が通信される。
MME部73およびHeNBGW74は、上位装置、具体的には上位ノードであり、基地局であるeNB76およびHome-eNB75と、移動端末(UE)71との接続を制御する。MME部73は、コアネットワークであるEPCを構成する。基地局72およびHeNBGW74は、E-UTRAN70を構成する。
さらに3GPPでは、以下のような構成が検討されている。Home-eNB75間のX2インタフェースはサポートされる。すなわち、Home-eNB75間は、X2インタフェースにより接続され、Home-eNB75間で制御情報が通信される。MME部73からは、HeNBGW74はHome-eNB75として見える。Home-eNB75からは、HeNBGW74はMME部73として見える。
Home-eNB75が、HeNBGW74を介してMME部73に接続される場合および直接MME部73に接続される場合のいずれの場合も、Home-eNB75とMME部73との間のインタフェースは、S1インタフェースで同じである。
基地局装置72は、1つのセルを構成してもよいし、複数のセルを構成してもよい。各セルは、通信端末装置と通信可能な範囲であるカバレッジとして予め定める範囲を有し、カバレッジ内で通信端末装置と無線通信を行う。1つの基地局装置が複数のセルを構成する場合、1つ1つのセルが、移動端末と通信可能に構成される。
図3は、本発明に係る移動端末である図2に示す移動端末71の構成を示すブロック図である。図3に示す移動端末71の送信処理を説明する。まず、プロトコル処理部801からの制御データ、およびアプリケーション部802からのユーザデータが、送信データバッファ部803へ保存される。送信データバッファ部803に保存されたデータは、エンコーダー部804へ渡され、誤り訂正などのエンコード処理が施される。エンコード処理を施さずに、送信データバッファ部803から変調部805へ直接出力されるデータが存在してもよい。エンコーダー部804でエンコード処理されたデータは、変調部805にて変調処理が行われる。変調されたデータは、ベースバンド信号に変換された後、周波数変換部806へ出力され、無線送信周波数に変換される。その後、アンテナ807から基地局72に送信信号が送信される。
また、移動端末71の受信処理は、以下のように実行される。基地局72からの無線信号がアンテナ807により受信される。受信信号は、周波数変換部806にて無線受信周波数からベースバンド信号に変換され、復調部808において復調処理が行われる。復調後のデータは、デコーダー部809へ渡され、誤り訂正などのデコード処理が行われる。デコードされたデータのうち、制御データはプロトコル処理部801へ渡され、ユーザデータはアプリケーション部802へ渡される。移動端末71の一連の処理は、制御部810によって制御される。よって制御部810は、図3では省略しているが、各部801~809と接続している。
図4は、本発明に係る基地局である図2に示す基地局72の構成を示すブロック図である。図4に示す基地局72の送信処理を説明する。EPC通信部901は、基地局72とEPC(MME部73など)、HeNBGW74などとの間のデータの送受信を行う。他基地局通信部902は、他の基地局との間のデータの送受信を行う。EPC通信部901および他基地局通信部902は、それぞれプロトコル処理部903と情報の受け渡しを行う。プロトコル処理部903からの制御データ、ならびにEPC通信部901および他基地局通信部902からのユーザデータおよび制御データは、送信データバッファ部904へ保存される。
送信データバッファ部904に保存されたデータは、エンコーダー部905へ渡され、誤り訂正などのエンコード処理が施される。エンコード処理を施さずに、送信データバッファ部904から変調部906へ直接出力されるデータが存在してもよい。エンコードされたデータは、変調部906にて変調処理が行われる。変調されたデータは、ベースバンド信号に変換された後、周波数変換部907へ出力され、無線送信周波数に変換される。その後、アンテナ908より一つもしくは複数の移動端末71に対して送信信号が送信される。
また、基地局72の受信処理は以下のように実行される。一つもしくは複数の移動端末71からの無線信号が、アンテナ908により受信される。受信信号は、周波数変換部907にて無線受信周波数からベースバンド信号に変換され、復調部909で復調処理が行われる。復調されたデータは、デコーダー部910へ渡され、誤り訂正などのデコード処理が行われる。デコードされたデータのうち、制御データはプロトコル処理部903あるいはEPC通信部901、他基地局通信部902へ渡され、ユーザデータはEPC通信部901および他基地局通信部902へ渡される。基地局72の一連の処理は、制御部911によって制御される。よって制御部911は、図4では省略しているが、各部901~910と接続している。
図5は、本発明に係るMMEの構成を示すブロック図である。図5では、前述の図2に示すMME部73に含まれるMME73aの構成を示す。PDN GW通信部1001は、MME73aとPDN GWとの間のデータの送受信を行う。基地局通信部1002は、MME73aと基地局72との間のS1インタフェースによるデータの送受信を行う。PDN GWから受信したデータがユーザデータであった場合、ユーザデータは、PDN GW通信部1001から、ユーザプレイン通信部1003経由で基地局通信部1002に渡され、1つあるいは複数の基地局72へ送信される。基地局72から受信したデータがユーザデータであった場合、ユーザデータは、基地局通信部1002から、ユーザプレイン通信部1003経由でPDN GW通信部1001に渡され、PDN GWへ送信される。
PDN GWから受信したデータが制御データであった場合、制御データは、PDN GW通信部1001から制御プレイン制御部1005へ渡される。基地局72から受信したデータが制御データであった場合、制御データは、基地局通信部1002から制御プレイン制御部1005へ渡される。
HeNBGW通信部1004は、HeNBGW74が存在する場合に設けられ、情報種別によって、MME73aとHeNBGW74との間のインタフェース(IF)によるデータの送受信を行う。HeNBGW通信部1004から受信した制御データは、HeNBGW通信部1004から制御プレイン制御部1005へ渡される。制御プレイン制御部1005での処理の結果は、PDN GW通信部1001経由でPDN GWへ送信される。また、制御プレイン制御部1005で処理された結果は、基地局通信部1002経由でS1インタフェースにより1つあるいは複数の基地局72へ送信され、またHeNBGW通信部1004経由で1つあるいは複数のHeNBGW74へ送信される。
制御プレイン制御部1005には、NASセキュリティ部1005-1、SAEベアラコントロール部1005-2、アイドルステート(Idle State)モビリティ管理部1005-3などが含まれ、制御プレインに対する処理全般を行う。NASセキュリティ部1005-1は、NAS(Non-Access Stratum)メッセージのセキュリティなどを行う。SAEベアラコントロール部1005-2は、SAE(System Architecture Evolution)のベアラの管理などを行う。アイドルステートモビリティ管理部1005-3は、待受け状態(アイドルステート(Idle State);LTE-IDLE状態、または、単にアイドルとも称される)のモビリティ管理、待受け状態時のページング信号の生成および制御、傘下の1つあるいは複数の移動端末71のトラッキングエリアの追加、削除、更新、検索、トラッキングエリアリスト管理などを行う。
MME73aは、1つまたは複数の基地局72に対して、ページング信号の分配を行う。また、MME73aは、待受け状態(Idle State)のモビリティ制御(Mobility control)を行う。MME73aは、移動端末が待ち受け状態のとき、および、アクティブ状態(Active State)のときに、トラッキングエリア(Tracking Area)リストの管理を行う。MME73aは、UEが登録されている(registered)追跡領域(トラッキングエリア:Tracking Area)に属するセルへ、ページングメッセージを送信することで、ページングプロトコルに着手する。MME73aに接続されるHome-eNB75のCSGの管理やCSG-IDの管理、そしてホワイトリストの管理は、アイドルステートモビリティ管理部1005-3で行ってもよい。
次に通信システムにおけるセルサーチ方法の一例を示す。図6は、LTE方式の通信システムにおいて移動端末(UE)が行うセルサーチから待ち受け動作までの概略を示すフローチャートである。移動端末は、セルサーチを開始すると、ステップST1で、周辺の基地局から送信される第一同期信号(P-SS)、および第二同期信号(S-SS)を用いて、スロットタイミング、フレームタイミングの同期をとる。
P-SSとS-SSとを合わせて、同期信号(SS)という。同期信号(SS)には、セル毎に割り当てられたPCIに1対1に対応するシンクロナイゼーションコードが割り当てられている。PCIの数は504通りが検討されている。この504通りのPCIを用いて同期をとるとともに、同期がとれたセルのPCIを検出(特定)する。
次に同期がとれたセルに対して、ステップST2で、基地局からセル毎に送信される参照信号(リファレンスシグナル:RS)であるセル固有参照信号(Cell-specific Reference Signal:CRS)を検出し、RSの受信電力(Reference Signal Received Power:RSRP)の測定を行う。参照信号(RS)には、PCIと1対1に対応したコードが用いられている。そのコードで相関をとることによって他セルと分離できる。ステップST1で特定したPCIから、該セルのRS用のコードを導出することによって、RSを検出し、RSの受信電力を測定することが可能となる。
次にステップST3で、ステップST2までで検出された一つ以上のセルの中から、RSの受信品質が最もよいセル、例えば、RSの受信電力が最も高いセル、つまりベストセルを選択する。
次にステップST4で、ベストセルのPBCHを受信して、報知情報であるBCCHを得る。PBCH上のBCCHには、セル構成情報が含まれるMIB(Master Information Block)がマッピングされる。したがってPBCHを受信してBCCHを得ることで、MIBが得られる。MIBの情報としては、例えば、DL(ダウンリンク)システム帯域幅(送信帯域幅設定(transmission bandwidth configuration:dl-bandwidth)とも呼ばれる)、送信アンテナ数、SFN(System Frame Number)などがある。
次にステップST5で、MIBのセル構成情報をもとに該セルのDL-SCHを受信して、報知情報BCCHの中のSIB(System Information Block)1を得る。SIB1には、該セルへのアクセスに関する情報や、セルセレクションに関する情報、他のSIB(SIBk;k≧2の整数)のスケジューリング情報が含まれる。また、SIB1には、トラッキングエリアコード(Tracking Area Code:TAC)が含まれる。
次にステップST6で、移動端末は、ステップST5で受信したSIB1のTACと、移動端末が既に保有しているトラッキングエリアリスト内のトラッキングエリア識別子(Tracking Area Identity:TAI)のTAC部分とを比較する。トラッキングエリアリストは、TAIリスト(TAI list)とも称される。TAIはトラッキングエリアを識別するための識別情報であり、MCC(Mobile Country Code)と、MNC(Mobile Network Code)と、TAC(Tracking Area Code)とによって構成される。MCCは国コードである。MNCはネットワークコードである。TACはトラッキングエリアのコード番号である。
移動端末は、ステップST6で比較した結果、ステップST5で受信したTACがトラッキングエリアリスト内に含まれるTACと同じならば、該セルで待ち受け動作に入る。比較して、ステップST5で受信したTACがトラッキングエリアリスト内に含まれなければ、移動端末は、該セルを通して、MMEなどが含まれるコアネットワーク(Core Network,EPC)へ、TAU(Tracking Area Update)を行うためにトラッキングエリアの変更を要求する。
コアネットワークを構成する装置(以下「コアネットワーク側装置」という場合がある)は、TAU要求信号とともに移動端末から送られてくる該移動端末の識別番号(UE-IDなど)をもとに、トラッキングエリアリストの更新を行う。コアネットワーク側装置は、移動端末に更新後のトラッキングエリアリストを送信する。移動端末は、受信したトラッキングエリアリストに基づいて、移動端末が保有するTACリストを書き換える(更新する)。その後、移動端末は、該セルで待ち受け動作に入る。
スマートフォンおよびタブレット端末の普及によって、セルラー系無線通信によるトラフィックが爆発的に増大しており、世界中で無線リソースの不足が懸念されている。これに対応して周波数利用効率を高めるために、小セル化し、空間分離を進めることが検討されている。
従来のセルの構成では、eNBによって構成されるセルは、比較的広い範囲のカバレッジを有する。従来は、複数のeNBによって構成される複数のセルの比較的広い範囲のカバレッジによって、あるエリアを覆うように、セルが構成されている。
小セル化された場合、eNBによって構成されるセルは、従来のeNBによって構成されるセルのカバレッジに比べて範囲が狭いカバレッジを有する。したがって、従来と同様に、あるエリアを覆うためには、従来のeNBに比べて、多数の小セル化されたeNBが必要となる。
以下の説明では、従来のeNBによって構成されるセルのように、比較的広い範囲のカバレッジを構成するセル、すなわちカバレッジエリアが比較的広いセルを「マクロセル」といい、マクロセルを構成するeNBを「マクロeNB」という。また、小セル化されたセルのように、比較的狭い範囲のカバレッジを構成するセル、すなわちカバレッジエリアが比較的狭いセルを「スモールセル」といい、スモールセルを構成するeNBを「スモールeNB」という。
マクロeNBは、例えば、非特許文献8に記載される「ワイドエリア基地局(Wide Area Base Station)」であってもよい。
スモールeNBは、例えば、ローパワーノード、ローカルエリアノード、ホットスポットなどであってもよい。また、スモールeNBは、ピコセルを構成するピコeNB、フェムトセルを構成するフェムトeNB、HeNB、RRH(Remote Radio Head)、RRU(Remote Radio Unit)、RRE(Remote Radio Equipment)またはRN(Relay Node)であってもよい。また、スモールeNBは、非特許文献8に記載される「ローカルエリア基地局(Local Area Base Station)」または「ホーム基地局(Home Base Station)」であってもよい。
図7は、マクロeNBとスモールeNBとが混在する場合のセルの構成の概念を示す図である。マクロeNBによって構成されるマクロセルは、比較的広い範囲のカバレッジ1301を有する。スモールeNBによって構成されるスモールセルは、マクロeNB(マクロセル)のカバレッジ1301に比べて範囲が狭いカバレッジ1302を有する。
複数のeNBが混在する場合、あるeNBによって構成されるセルのカバレッジが、他のeNBによって構成されるセルのカバレッジ内に含まれる場合がある。図7に示すセルの構成では、参照符号「1304」または「1305」で示されるように、スモールeNBによって構成されるスモールセルのカバレッジ1302が、マクロeNBによって構成されるマクロセルのカバレッジ1301内に含まれる場合がある。
また、参照符号「1305」で示されるように、複数、例えば2つのスモールセルのカバレッジ1302が、1つのマクロセルのカバレッジ1301内に含まれる場合もある。移動端末(UE)1303は、例えばスモールセルのカバレッジ1302内に含まれ、スモールセルを介して通信を行う。
また図7に示すセルの構成では、参照符号「1306」で示されるように、マクロeNBによって構成されるマクロセルのカバレッジ1301と、スモールeNBによって構成されるスモールセルのカバレッジ1302とが複雑に重複する場合が生じる。
また、参照符号「1307」で示されるように、マクロeNBによって構成されるマクロセルのカバレッジ1301と、スモールeNBによって構成されるスモールセルのカバレッジ1302とが重複しない場合も生じる。
さらには、参照符号「1308」で示されるように、多数のスモールeNBによって構成される多数のスモールセルのカバレッジ1302が、一つのマクロeNBによって構成される1つのマクロセルのカバレッジ1301内に構成される場合も生じる。
スモールセルの運用において、マクロセルのカバレッジ内でトラフィックの多いエリアにスモールセルを構成する、すなわちマクロセルにスモールセルを重ねて配置(オーバレイ)することによって、スループットを向上させることが検討されている。
図8は、マクロセルとスモールセルとがオーバレイされる場合のセルの構成の一例を示す図である。図8では、図7と同様に、マクロセルのカバレッジを参照符号「1301」で示し、スモールセルのカバレッジを参照符号「1302」で示す。
3GPPでは、図8に示すようなセルの構成において、UEがマクロセルとスモールセルとの両方に接続する、デュアルコネクティビティ(Dual connectivity;略称:DC)の議論が行われている(非特許文献9参照)。DCを行うUEに対する制御プレイン(C-plane)では、SeNB(Secondary eNB)は、MeNB(Master eNB)を介してMMEに接続される。
DCを行うUEに対して、ユーザプレイン(U-plane)では、主に二つのアーキテクチャが検討されている。一つは、SeNBが直接S-GWに接続されるアーキテクチャ(以下「アーキテクチャ1A」という場合がある)である。他の一つは、SeNBがMeNBを介してS-GWに接続されるアーキテクチャ(以下「アーキテクチャ3C」という場合がある)である。
ここで、MeNBは、DCにおけるマクロセルを構成するeNBである。SeNBは、DCにおけるスモールセルを構成するeNBである。また、MeNBが構成するセルグル―プを「MCG」と称し、SeNBが構成するセルグループを「SCG」と称する。MCG内のセルを「MCGセル」と称し、SCG内のセルを「SCGセル」と称する。MCG内でPUCCHを送信するセルを「PCell」と称する。SCG内でPUCCHを送信する特別なセルを「SPCell」と称する。SPCellは、PCellの一部の機能を有する。
実施の形態1で解決する課題、およびその解決策について、以下に示す。PWS(Public Warning System)は、特定のエリアに存在するUEに対して警報(Warning)メッセージを通知するシステムである(非特許文献10参照)。PWSとしては、ETWS(Earthquake and Tsunami Warning System),CMAS(Commercial Mobile Alert System),EU-ALERT(European Public Warning System),KPAS(Korean Public Alert System)などがある。
PWSでは、通知するメッセージの重要性から、RRC_IDLEのUEだけでなく、RRC_CONNECTEDのUEに対してもサポートされている。また、PWSにおけるメッセージ(以下「PWSメッセージ」という場合がある)は、MMEからeNBに対して、制御プレイン(C-Plane)のインタフェースであるS1-MMEを介して通知される。PWSメッセージは、上位装置からスモールセルに向けたスモールセル向け情報に相当する。上位装置は、例えば、後述するCBE(Cell Broadcast Entity)、CBC(Cell Broadcast Centre)およびMMEである。
3GPPで検討されているDCでは、DC中のUEの制御プレイン(C-Plane)において、SeNBは、MMEと直接は接続されない。したがって、前述のPWSをDCに適用した場合、SeNBを用いてDCを行っているUEは、該SeNB向けのPWSメッセージの通知対象にならず、該UEは、SeNB向けのPWSメッセージを受信することはできない。
3GPPにおいては、DCにおけるPWSの取扱いについては、DC中のUEは、MeNB向けのPWSメッセージを受信することのみが検討されており、SeNB向けのPWSメッセージの受信方法については、何ら議論されていない(非特許文献11,12参照)。
PWSは、特定のエリアを対象とするので、たとえSeNBとMeNBとがオーバレイして構成されていたとしても、SeNB向けのPWSメッセージとMeNB向けのPWSメッセージとは異なる場合がある。したがって、SeNBのカバレッジ内に存在するUEが、該SeNB向けのPWSメッセージを受信することができるようにすることは、該UEにとって有効である。
実施の形態1では、SeNBを用いてDCを行っているUEが、該SeNB向けのPWSメッセージを受信することを可能とする方法を開示する。
実施の形態1における解決策を以下に示す。SeNBは、DC中のUEに対して、自SeNB向けのPWSメッセージを送信する。SeNBを用いてDCを行っているUEは、該SeNB向けのPWSメッセージを受信する。
PWSメッセージが、特定の一つまたは複数のSCGセルに通知される場合は、DCに用いられているSeNBは、自SCGセルを用いてDCを行っているUEに対して、自SCGセル向けのPWSメッセージを送信する。SCGセルを用いてDCを行っているUEは、該SCGセル向けのPWSメッセージを受信する。
PWSメッセージの通知方法について説明する。図9は、実施の形態1の通信システムにおけるPWSメッセージの流れの一例を示す図である。図9では、PWSメッセージの流れを、太線の矢符106,107,108で示している。
PWSメッセージは、不図示のCBE(Cell Broadcast Entity)からCBC(Cell Broadcast Centre)101に通知される。CBC101は、CBEから通知されたPWSメッセージを、矢符106で示すように、MME102に通知する。
MME102は、CBC101から通知されたPWSメッセージを、eNBに通知する。具体的には、MME102は、PWSメッセージを、矢符107で示すように、SeNB104に通知する。またMME102は、PWSメッセージをMeNB103に通知する。eNBは、自セルがDCに用いられている場合、すなわち、SeNB104である場合、MME102から通知されたPWSメッセージを、矢符108で示すように、自セルを用いてDCを行っているUE105に通知する。
MME102とMeNB103とは、インタフェース111によって接続される。MME102とMeNB103との間のインタフェース111には、S1インタフェースが用いられる。ここでは、DC中のUE105に対するインタフェースを示している。
MeNB103とSeNB104とは、インタフェース112によって接続される。MeNB103とSeNB104との間のインタフェース112には、X2またはXnインタフェースが用いられる。ここでは、DC中のUE105に対するインタフェースを示している。
SeNB104が、自セルを用いてDCを行っているUE105にPWSメッセージを通知するために、SCGセルは、PWSメッセージをSIBに含めて報知するとよい。
PWSメッセージを含めるSIB(以下「PWSメッセージ用SIB」という場合がある)としては、新たなSIBを設けてもよいし、既存のSIBを用いてもよい。既存のPWSメッセージを含むSIBとしては、例えば、ETWS用として、SIB10、SIB11があり、CMAS用として、SIB12がある。
SCGセルが、PWSメッセージを、DC中のUEに通知する方法は、SCGセルが傘下のUEにPWSメッセージを報知する方法を適用することができる。SCGセルは、傘下のUEに対して、PWSメッセージを通知しなくてはならない。該通知は報知によって行われる。
したがって、SCGセルが、傘下のUEにPWSメッセージを報知する方法を用いて、自セルを用いてDCを行っているUEに対してもPWSメッセージを通知することによって、新たな処理を加えなくて済む。これによって、SeNBの機能が複雑になることを防ぎ、誤動作を低減させることができる。
SCGセルを用いてDCを行っているUEは、SCGセルから報知されるPWSメッセージ用SIBを受信する。PWSメッセージはPWSメッセージ用SIBに含めて報知されるので、UEは、PWSメッセージ用SIBを受信することによって、PWSメッセージ用SIB中のPWSメッセージを受信する。
PWSメッセージが報知されたことを、DC中のUEに示すために、PWSインジケーション(PWS indication)を設けるとよい。PWSインジケーションは、スモールセル向け情報が報知されたことを示す報知指示情報に相当する。PWSインジケーションは、PWSメッセージに先立って、DC中のUEに通知される。DC中のUEは、PWSインジケーションを受信すると、SCGセルのPWSメッセージが含まれるSIBを受信する。図9では、PWSインジケーションの流れを、矢符109,110で示している。
SeNB104は、MME102から、自SeNB向けのPWSメッセージを受信した場合、UE105に対してPWSインジケーションを通知する。PWSインジケーションの通知方法の具体例として、以下の(1),(2)の2つを開示する。
(1)SeNB104から、矢符110で示すように直接、DC中のUE105に通知する。
(2)SeNB104から、矢符109で示すように、MeNB103を介して、DC中のUE105に通知する。
PWSインジケーションの通知方法として、前記(1)の通知方法を適用する場合について説明する。MME102からPWSメッセージを受信したSeNB104は、PWSメッセージを送信するSCGセルを特定する。SCGセルは、PWSインジケーションをページング(Paging)メッセージに含めて、傘下のUEに通知する。SCGセルは、DC中のUEに対しても、PWSインジケーションをページングメッセージに含めて通知する。また、SCGセルは、PWSメッセージを報知する。
SCGセルを用いてDCを行っているUEは、SCGセルからのページングメッセージを受信し、ページングメッセージ内のPWSインジケーションを受信する。
PWSインジケーションとしては、新たなインジケーションを設けてもよいし、既存のインジケーションを用いてもよい。既存のインジケーションとしては、例えば、ETWS用として、ETWSインジケーション(ETWS indication)があり、CMAS用として、CMASインジケーション(CMAS indication)がある。
SCGセルを用いてDCを行っているUEは、ページングメッセージ内のPWSインジケーションを受信すると、SCGセルのPWSメッセージが含まれるSIBを受信する。
PWSメッセージが含まれるSIBは、予め静的に決められておくとよい。また、PWSメッセージが含まれるSIBは、規格で決められておいてもよい。
SCGセルを用いてDCを行っているUEは、PWSメッセージが含まれるSIBを受信するために、スケジューリング情報が含まれるSIB(SIB1)を受信する。SCGセルのSIB1を受信したDC中のUEは、スケジューリング情報を用いて、PWSメッセージが含まれるSIBを受信する。
図10は、実施の形態1の通信システムにおけるPWSメッセージ通知処理のシーケンスの一例を示す図である。図10では、PWSインジケーションの通知方法として、前述の(1)の通知方法を適用した場合の例を示している。
ステップST1001において、UE、MeNBおよびMMEは、登録処理(Registration Procedure)を行う。登録処理では、具体的には、UEが、MeNBを介して、MMEに対して登録(registration)を行う。登録処理完了後、UEは、MeNBとRRC_CONNECTED状態に移行する。
ステップST1002において、MeNBは、UEに対して、DCを実行するために、SeNBの追加処理(以下「SeNB追加処理」という場合がある)を起動する。これによって、MeNB、UE、およびSeNBの間で、SeNB追加処理(SeNB Addition Procedure)が行われる。SeNB追加処理の具体的な内容については、例えば、非特許文献9に開示される。SeNB追加処理において、UEは、追加するSCGセルと同期をとる。
SeNB追加処理を行い、追加するSCGセルと同期をとったUEは、ステップST1003において、SCGセルのページングメッセージがマッピングされるPCHを受信する。本実施の形態では、UEは、SCGセルのページングメッセージがマッピングされるPCHを間欠受信する。
UEは、SCGセルのPCH送信タイミングに関する情報を、SeNBから、MeNBを介して受信しておくとよい。SeNBは、MeNBに対して、SCGセルのPCH送信タイミングに関する情報を通知する。MeNBは、UEに対して、SCGセルのPCH送信タイミングに関する情報を通知する。これらの通知は、ステップST1002のSeNB追加処理において行われるとよい。PCH送信タイミングに関する情報としては、DRX周期などがある。
また、SeNBは、予めUEの識別子を認識しておく。MeNBは、DCを実行するUEの識別子をSeNBに対して通知するとよい。この通知は、ステップST1002のSeNB追加処理において行われるとよい。
UEの識別子としては、IMSI(International Mobile Subscriber Identity)を用いるとよい。DCを実行するUEのIMSIを、SeNBが受信することによって、従来の傘下のUEに対するPCH送信タイミング導出方法と同様にして、UEへのPCH送信タイミングを導出することが可能となる。また、DC中のUEも、自IMSIに基づいて、従来の導出方法から、SCGセルからのPCH送信タイミングを導出することが可能となる。
ステップST1004において、CBC(Cell Broadcast Centre)は、不図示のCBE(Cell Broadcast Entity)からPWSメッセージを受信する。具体的には、CBCは、PWSメッセージとして、緊急報知要求(Emergency Broadcast Request)メッセージを受信する。
CBEからPWSメッセージを受信したCBCは、ステップST1005において、MMEに対して、SBcインタフェースによって、PWSメッセージを通知する。
ステップST1005において、CBCは、PWSメッセージとともに、トラッキングエリアIDリスト(tracking area ID list)、警報エリア(warning area)情報、グローバルeNB ID(Global eNB ID)をMMEに通知する。また、PWSメッセージ固有の識別子を通知してもよい。警報エリア(warning area)情報は、セル識別子のリスト、またはトラッキングエリア識別子のリスト、または緊急エリア(Emergency Area)識別子からなる。
PWSメッセージ、トラッキングエリアIDリスト、警報エリア情報、およびグローバルeNB IDの通知用のメッセージとしては、「Write-Replace Warning Request」メッセージが用いられる。すなわち、CBCは、ステップST1005において、「Write-Replace Warning Request」メッセージをMMEに通知することによって、PWSメッセージ、トラッキングエリアIDリスト、警報エリア情報、およびグローバルeNB IDをMMEに通知する。
PWSメッセージを受信したMMEは、トラッキングエリアIDリスト(tracking area ID list)から、PWSメッセージを通知するeNBを特定する。ここでは、SeNBがトラッキングエリアIDリストに含まれている場合について示している。
また、PWSメッセージを受信したMMEは、ステップST1006において、CBCに対して、PWSメッセージ受信確認メッセージを通知する。PWSメッセージ受信確認メッセージの通知用のメッセージとしては、「Write-Replace Warning Confirm」メッセージを用いる。
PWSメッセージ受信確認メッセージを受信したCBCは、ステップST1007において、CBEに対して、PWSメッセージ受信応答メッセージを通知する。具体的には、CBCは、PWSメッセージ受信応答メッセージとして、緊急報知応答(Emergency Broadcast Response)メッセージを通知する。
MMEは、ステップST1006におけるPWSメッセージ受信確認メッセージの通知を、後述のステップST1008において「Write-Replace Warning Request」メッセージを送信した後で行ってもよいし、ステップST1012において「Write-Replace Warning Response」メッセージを受信した後で行ってもよい。eNBにPWSメッセージを通知してから、あるいはeNBからPWSメッセージ通知に対する応答を受信してから行うようにしてもよい。
ステップST1008において、MMEは、SeNBに対して、S1-MMEインタフェースによって、PWSメッセージを通知する。ステップST1008において、MMEは、PWSメッセージとともに、警報エリア(warning area)情報をSeNBに通知する。また、PWSメッセージ固有の識別子を通知してもよい。PWSメッセージおよび警報エリア情報の通知用のメッセージとしては、「Write-Replace Warning Request」メッセージが用いられる。
PWSメッセージを受信したSeNBは、警報エリア(warning area)情報を用いて、自SeNB向けのPWSメッセージか否かを確認する。また、SeNBは、自SeNB向けのPWSメッセージである場合、警報エリア(warning area)情報を用いて、PWSメッセージを送信するSCGセルを特定する。
ステップST1009において、SeNBは、特定されたSCGセルから、PWSインジケーション(PWS indication)を含めたページングメッセージを、傘下のUEに通知する。またSeNBは、DC中のUEに対しても、PWSインジケーション(PWS indication)を含めたページングメッセージを通知する。DC中のUEへのページングメッセージの送信タイミングは、ステップST1002のSeNB追加処理で取得したUEのIMSIを用いて決定する。
ステップST1003でPCHを受信しているUEは、ステップST1009において、SCGセルからPCHにマッピングされたページングメッセージを受信し、PWSインジケーションを受信する。
PWSインジケーションを受信したUEは、ステップST1010において、SCGセルから報知されるSIB1を受信して、PWSメッセージが含まれるSIBのスケジューリング情報を受信する。そして、UEは、スケジューリング情報に従って、ステップST1011において、PWSメッセージが含まれるSIBを受信し、PWSメッセージを受信する。
緊急性を要するPWSメッセージ、例えばETWSなどの場合は、UEは、PWSインジケーションを受信した後、直ちにPWSメッセージを受信するようにしてもよい。
ステップST1012において、SeNBは、MMEに対して、「Write-Replace Warning Response」メッセージを通知し、PWSメッセージ通知処理の処理手順を終了する。
以上の図10に示すようなPWSメッセージ通知処理を行うことによって、SeNBを用いてDCを行っているUEが、SeNB向けのPWSメッセージを受信することが可能となる。
また、PWSインジケーションの通知方法を、前述の(1)の通知方法とすることによって、従来のPWSインジケーションを通知する方法と同様にしてPWSインジケーションを通知することが可能となるので、SeNBにおける処理が複雑になることを抑制することができる。
DCに用いられるSCGセルが複数存在する場合、DC中のUEは、複数のSCGセルのPCHを受信する必要が生じる。この場合、DC中のUEは、PCHの受信処理が増大し、消費電力が増大してしまう。これを避けるために、PWSインジケーションが通知されるのは、SPCellのみに限定してもよい。また、PWSメッセージが通知されるのも、SPCellのみに限定してもよい。このようにすることによって、DC中のUEの消費電力の増大を防ぐことが可能となる。
また、SeNBが、MMEからPWSメッセージを受信した場合、SeNBを用いてDCを行っているUEがSPCellとしているSCGセルが、該UEに対してPWSインジケーションを送信するようにしてもよい。SPCellは、該UEに対して、PWSインジケーションとともに、どのSCGセル向けPWSメッセージが発生したかを示す情報を送信するとよい。これによって、SeNBを用いてDCを行っているUEは、少なくともSPCellのPCHのみを受信すればよくなる。また、PWSメッセージを、SeNBを用いてDCを行っているUEがSPCellとしているSCGセルが送信するようにしてもよい。これによって、SeNBを用いてDCを行っているUEは、SPCellのみからPWSメッセージを受信すればよくなる。したがって、DC中のUEの消費電力の増大を防ぐことが可能となる。
PWSインジケーションの通知方法として、前記(2)の通知方法を適用する場合について、前述の図9を用いて説明する。MME102からPWSメッセージを受信したSeNB104は、自SCGセルを用いてDCを行っているUE105に対して、MeNB103を介して、PWSインジケーションを通知する。
さらに具体的に述べると、SeNB104は、PWSメッセージを送信するSCGセルを特定し、該SCGセルを用いてDCを行っているUE105に対して、矢符109で示すように、MeNB103を介して、PWSインジケーションを通知する。
SCGセルを用いてDCを行っているUE105は、MeNB103から送信されるPWSインジケーションを受信すると、SCGセルのPWSメッセージが含まれるSIBを受信する。
図11は、実施の形態1の通信システムにおけるPWSメッセージ通知処理のシーケンスの他の例を示す図である。図11では、PWSインジケーションの通知方法として、前述の(2)の通知方法を適用した場合の例を示している。図11に示すシーケンスは、図10に示すシーケンスと類似しているので、同一のステップについては同一のステップ番号を付して、共通する説明を省略する。
まず、前述の図10に示す場合と同様にして、ステップST1001~ステップST1002、ステップST1004~ステップST1008の処理が行われる。ステップST1008においてPWSメッセージを受信したSeNBは、警報エリア(warning area)情報を用いて、自SeNB向けのPWSメッセージか否かを確認する。SeNBは、自SeNB向けのPWSメッセージである場合、警報エリア(warning area)情報を用いて、PWSメッセージを送信するSCGセルを特定する。
ステップST1101において、SeNBは、特定されたSCGセルを用いてDCを行っているMeNBに対して、PWSインジケーション(PWS indication)を通知する。PWSインジケーションは、X2インタフェースを用いて通知する。あるいは、DCのためにMeNBとSeNBとの間に、新たにXnインタフェースが設けられる場合、Xnインタフェースを用いて通知してもよい。X2メッセージとして新たなメッセージを設けてそれに含めて通知してもよい。あるいは、SCGセルの設定変更のためのメッセージに含めて通知してもよい。また、X2メッセージ中あるいはXnメッセージ中に、RRCメッセージのコンテナを設け、該コンテナ内に含めて通知してもよい。これらのメッセージは、個別シグナリングで通知されるとよい。
ステップST1101において、SeNBは、PWSインジケーションとともに、SeNBの識別子、または、特定したSCGセルの識別子をMeNBに通知しておく。または、特定したSCGセルとDC中のUE識別子を認識している場合は、SeNBは、該DC中のUEの識別子を通知してもよい。SeNBが、SCGセルとDC中のUE識別子を認識する方法として、ステップST1002のSeNB追加処理において、MeNBからSeNBに対して、SCGセルとDC中のUE識別子を通知しておくとよい。
ステップST1101において、SeNBから、DC中のUEに対するPWSインジケーションを受信したMeNBは、ステップST1102において、SeNBを用いてDCを行っているUEに対して、PWSインジケーション(PWS indication)を通知する。PWSインジケーションの通知には、RRCメッセージを用いるとよい。RRCメッセージは、個別シグナリングで通知するとよい。
ステップST1102において、MeNBは、SeNBを用いてDCを行っているUEに対して、PWSインジケーションとともに、PWSメッセージを送信するSCGセルの識別子を通知してもよい。
MeNBが、SeNBからRRCメッセージのコンテナでPWSインジケーションを通知された場合は、RRCメッセージに乗せ換え、該コンテナをDC中のUEに個別に通知するとよい。
ステップST1101において、SeNBから、DC中のUEに対するPWSインジケーションを受信したMeNBは、特定したSCGセルの識別子または特定したSCGセルとDC中のUE識別子を用いて、特定したSCGセルとDC中のUEに対してのみPWSインジケーションを通知するようしてもよい。PWSインジケーションとともに、特定したSCGセルの識別子の通知が不要となる。また、PWSメッセージを送信しないSCGセルとDCを行っているUEに対して、PWSインジケーションを通知する必要がなくなる。これによって、シグナリング負荷の削減および制御の簡易化を図ることができる。
ステップST1101において、SeNBが特定されたSCGセルを用いてDCを行っているMeNBに対してPWSインジケーションを通知することを開示したが、SeNBは、自セルを用いてDCを行うことが可能なeNB、あるいは、周辺のeNBに対して、PWSインジケーションを通知してもよい。この場合、SeNBは、PWSインジケーションとともに自SeNBの識別子または特定したSCGセルの識別子を通知する。PWSインジケーションを通知されたeNBは、SeNBの識別子または特定したSCGセルの識別子を用いて、自eNBが該SeNBあるいはSCGセルを用いてDCを行っているか否かを判断する。該SeNBあるいはSCGセルを用いてDCを行っている場合は、該DC中のUEに対してPWSインジケーションを通知するとよい。
PWSインジケーションのUEへの他の通知方法としては、MeNBが、PCHにマッピングするページングメッセージに、PWSインジケーションを含めて通知してもよい。PCH上に、DC中のSeNB向けのPWSメッセージのPWSインジケーションを設けるとよい。PWSインジケーションとともに、PWSメッセージを送信するSCGセルの識別子を含めてもよい。これによって、PWSメッセージを送信するSCGセルを、UEに特定させることができる。
MeNBは、UEがPCHを受信可能なMCGセルのPCHにマッピングするとよい。
また、MeNBは、PCellのPCHにマッピングするようにしてもよい。この方法は、UEがMeNBのPCellのみについてPCHを受信している場合に適用することができる。
ステップST1102において、MeNBからPWSインジケーションを受信したUEは、ともに通知されたSCGセルの識別子を受信し、どのSCGセル向けにPWSメッセージが送信されたかを認識する。
PWSインジケーションを受信したUEは、ステップST1010において、SCGセルから報知されるSIB1を受信して、PWSメッセージが含まれるSIBのスケジューリング情報を受信する。そして、UEは、スケジューリング情報に従って、ステップST1011において、PWSメッセージが含まれるSIBを受信し、PWSメッセージを受信する。
緊急性を要するPWSメッセージ、例えばETWSなどの場合は、UEは、PWSインジケーションを受信した後、直ちにPWSメッセージを受信するようにしてもよい。
ステップST1012において、SeNBは、前述の図10に示す場合と同様に、MMEに対して、「Write-Replace Warning Response」メッセージを通知し、PWSメッセージ通知処理の処理手順を終了する。
PWSインジケーションの通知方法(1)で開示した、DCに用いられるSCGセルが複数存在する場合の方法、または、SeNBがMMEからPWSメッセージを受信した場合にSPCellからPWSインジケーションまたはPWSメッセージを通知する方法を、PWSインジケーションの通知方法(2)に適用してもよい。これによって、UEにおけるPWSインジケーション受信処理あるいはPWSメッセージ受信処理を簡易にすることができ、UEの低消費電力化を図ることが可能となる。
以上の図11に示すようなPWSメッセージ通知処理を行うことによって、SeNBを用いてDCを行っているUEが、SeNB向けのPWSメッセージを受信することが可能となる。
また、PWSインジケーションの通知方法を、前述の(2)の通知方法とすることによって、DC中のUEは、前述の(1)の通知方法で必要であったSCGセルのPCHを受信する必要が無くなる。したがって、UEの低消費電力化を図ることが可能となる。
実施の形態1 変形例1.
本変形例では、SeNBが、DC中のUEに対して、自SeNB向けのPWSメッセージを送信する方法の他の方法を開示する。
SeNBは、DC中のUEに対して、MeNBを介して、自SeNB向けのPWSメッセージを送信する。DC中のUEは、MeNBからSeNB向けのPWSメッセージを受信する。
PWSメッセージが、特定の一つまたは複数のSCGセルに通知される場合は、DCに用いられているSeNBは、自SCGセルを用いてDCを行っているUEに対して、MeNBを介して、自SCGセル向けPWSメッセージを送信する。SCGセルを用いてDCを行っているUEは、MeNBから、SCGセル向けのPWSメッセージを受信する。
PWSメッセージの通知方法について説明する。図12は、実施の形態1の変形例1の通信システムにおけるPWSメッセージの流れの一例を示す図である。図12に示す構成は、図9に示す構成と類似しているので、同一の部分には同一の参照符号を付して、共通する説明を省略する。図12では、PWSメッセージの流れを、太線の矢符106,107,122で示している。
PWSメッセージは、不図示のCBEからCBC101に通知される。CBC101は、PWSメッセージを、矢符106で示すように、MME102に通知する。
MME102は、PWSメッセージをeNBに通知する。具体的には、MME102は、PWSメッセージを、矢符107で示すように、SeNB104に通知する。またMME102は、PWSメッセージをMeNB103に通知する。eNBは、自セルがDCに用いられている場合、すなわち、SeNB104である場合、矢符121および矢符122で示すように、自セルを用いてDCを行っているUE105に、MeNB103を介して、PWSメッセージを通知する。
MME102からPWSメッセージを受信したSeNB104は、自SeNBを用いてDCを行っているMeNB103に対して、PWSメッセージを通知する。SeNB104は、PWSメッセージを送信するSCGセルを特定し、該SCGセルを用いてDCを行っているMeNB103に対して、PWSメッセージを通知する。
PWSメッセージの通知には、X2インタフェース112を用いる。あるいは、DCのためにMeNB103とSeNB104との間に、新たにXnインタフェースが設けられる場合は、Xnインタフェースを用いてPWSメッセージを通知してもよい。X2メッセージとして新たなメッセージを設けて、それに含めて通知してもよい。あるいは、SCGセルの設定変更のためのメッセージに含めて通知してもよい。X2メッセージ中あるいはXnメッセージ中に、RRCメッセージのコンテナを設け、該コンテナ内に含めて通知してもよい。これらのメッセージは、個別シグナリングで通知されるとよい。
PWSメッセージとともに、SeNBの識別子、または、特定したSCGセルの識別子を通知しておく。または、特定したSCGセルとDC中のUE識別子を認識している場合は、該DC中のUEの識別子を通知してもよい。また、PWSメッセージ固有の識別子を通知してもよい。
SeNBからPWSメッセージを受信したMeNBは、該SeNBを用いてDCを行っているUEに対して、PWSメッセージを通知する。また、PWSメッセージとともにPWSメッセージ固有の識別子を通知してもよい。SeNBを用いてDCを行っているUEは、MeNBから通知される、該SeNB向けのPWSメッセージを受信する。また、PWSメッセージとともにPWSメッセージ固有の識別子を受信してもよい。このようにすることによって、SeNBを用いてDCを行っているUEが、SeNB向けのPWSメッセージを得ることが可能となる。
実施の形態1と同様に、PWSインジケーションが設けられ、PWSメッセージに先立って、DC中のUEに通知されるようにしてもよい。この場合、DC中のUEは、PWSインジケーションを受信すると、MeNBから通知されるSeNB向けのPWSメッセージを受信する。
図12では、PWSインジケーションの流れを、矢符109,110,123で示している。
SeNB104は、MME102から、自SeNB向けのPWSメッセージを受信した場合、矢符110で示すように、UE105に対してPWSインジケーションを通知する。あるいは、MeNB103がSeNB104からPWSメッセージを受信した場合、矢符123で示すように、MeNB103がDC中のUE105にPWSインジケーションを通知してもよい。
PWSインジケーションの通知方法の具体例として、以下の(1)~(3)の3つを開示する。
(1)SeNB104から、矢符110で示すように直接、DC中のUE105に通知する。
(2)SeNB104から、矢符109で示すように、MeNB103を介して、DC中のUE105に通知する。
(3)MeNB103が、矢符123で示すように、DC中のUE105に通知する。
前述の(1),(2)の通知方法については、実施の形態1で述べた方法を適用することができる。PWSインジケーションの通知方法として、前述の(3)の通知方法について説明する。SeNB104からPWSメッセージを受信したMeNB103は、DC中のUE105に対して、PWSインジケーションを通知する。さらに具体的に述べると、MeNB103は、PWSメッセージとともに受信した、どのSCGセル向けかの情報、例えばSCGセル識別子を用いて、該SCGセルを用いてDCを行っているUE105に対して、PWSインジケーションを通知する。SCGセルを用いてDCを行っているUE105は、MeNB103から送信されるPWSインジケーションを受信すると、該SCGセルのPWSメッセージをMeNB103から受信する。
図13は、実施の形態1の変形例1の通信システムにおけるPWSメッセージ通知処理のシーケンスの一例を示す図である。図13では、PWSインジケーションの通知方法として、前述の(3)の通知方法を適用した場合の例を示している。図13に示すシーケンスは、前述の図10および図11に示すシーケンスと類似しているので、同一のステップについては同一のステップ番号を付して、共通する説明を省略する。
まず、前述の図10および図11に示す場合と同様にして、ステップST1001~ステップST1002、ステップST1004~ステップST1008の処理が行われる。ステップST1008において、PWSメッセージを受信したSeNBは、警報エリア(warning area)情報を用いて、自SeNB向けのPWSメッセージか否かを確認する。SeNBは、自SeNB向けのPWSメッセージの場合、警報エリア(warning area)情報を用いて、PWSメッセージを送信するSCGセルを特定する。
ステップST1301において、SeNBは、特定されたSCGセルを用いてDCを行っているMeNBに対して、PWSメッセージを通知する。また、PWSメッセージ固有の識別子を通知してもよい。
SeNBからPWSメッセージを受信したMeNBは、ステップST1302において、該SeNBを用いてDCを行っているUEに対して、PWSインジケーション(PWS indication)を通知する。該通知には、RRCメッセージを用いるとよい。RRCメッセージは、個別シグナリングで通知するとよい。
ステップST1301において、SeNBが、特定されたSCGセルを用いてDCを行っているMeNBに対してPWSメッセージを通知することを開示したが、SeNBは、自セルを用いてDCを行うことが可能なeNB、あるいは、周辺のeNBに対して、PWSメッセージを通知してもよい。この場合、SeNBは、PWSメッセージとともに自SeNBの識別子または特定したSCGセルの識別子を通知する。PWSメッセージを通知されたeNBは、SeNBの識別子または特定したSCGセルの識別子を用いて、自eNBが該SeNBあるいはSCGセルを用いてDCを行っているか否かを判断する。該SeNBあるいはSCGセルを用いてDCを行っている場合は、該DC中のUEに対してPWSインジケーションを通知するとよい。
ステップST1302において、MeNBは、SeNBを用いてDC中のUEに対して、該PWSインジケーションとともに、PWSメッセージを送信するSCGセルの識別子を通知してもよい。
PWSインジケーションのUEへの他の通知方法として、MeNBは、PCHにマッピングするページングメッセージにPWSインジケーションを含めて通知してもよい。PCH上に、DC中のSeNB向けのPWSメッセージのPWSインジケーションを設けるとよい。PWSインジケーションとともに、PWSメッセージを送信するSCGセルの識別子を含めてもよい。これによって、PWSメッセージを送信するSCGセルをUEに特定させることができる。
MeNBは、UEがPCHを受信可能なMCGセルのPCHにマッピングするとよい。また、MeNBは、PCellのPCHにマッピングするようにしてもよい。この方法は、UEがMeNBのPCellのPCHのみを受信している場合に適用することができる。この場合、UEは、PCellのPCHのみを受信すればよく、他のMCGセルから送信されるPCHを受信する必要はない。したがって、UEの低消費電力化を図ることができる。
SeNBからPWSメッセージを受信したMeNBは、ステップST1304において、PWSメッセージを報知する。MeNBは、PWSメッセージをSIBに含めて報知する。PWSメッセージを含めるSIBとして、新たなSIBを設けてもよいし、SeNB向けPWSメッセージ用SIBを設けてもよい。既存のSIBを用いてもよい。既存のPWSメッセージを含むSIBとしては、例えば、ETWS用としてSIB10、SIB11があり、CMAS用としてSIB12がある。MeNBがPWSメッセージをDC中のUEに通知する方法としては、MeNBが傘下のUEにPWSメッセージを報知する方法を適用することができる。
MeNBは、DC中のUEに対して、SeNB向けのPWSメッセージを、PCellから報知してもよい。PCellのSIBに含めて報知するようにしてもよい。
DC中のUEは、PCellから送信されるSeNB向けのPWSメッセージを受信すればよい。
UEは、PCellのSIBのみを受信すればよく、他のMCGセルから送信されるSIBを受信する必要はない。したがって、UEの低消費電力化を図ることができる。
ステップST1302においてMeNBからPWSインジケーションを受信したUEは、ステップST1303において、MeNBから報知されるSIB1を受信して、PWSメッセージが含まれるSIBのスケジューリング情報を受信する。そして、UEは、スケジューリング情報に従って、ステップST1304において、PWSメッセージが含まれるSIBを受信し、PWSメッセージを受信する。
緊急性を要するPWSメッセージ、例えばETWSなどの場合は、UEは、PWSインジケーションを受信した後、直ちにPWSメッセージを受信するようにしてもよい。
MeNBは、DC中のUEに対して、PCellからPWSインジケーションまたはPWSメッセージを通知することによって、SeNBからPWSインジケーションまたはPWSメッセージを受信する必要が無くなるので、UEの低消費電力化を図ることが可能となる。
ステップST1012において、SeNBは、前述の図10および図11に示す場合と同様に、MMEに対して、「Write-Replace Warning Response」メッセージを通知し、PWSメッセージ通知処理の処理手順を終了する。
前述の方法では、MeNBは、DC中のUEに対して、PWSメッセージをSIBに含めて通知する。他の方法として、MeNBは、DC中のUEに対して、PWSメッセージをRRCメッセージに含めて通知してもよい。この場合、RRCメッセージは、個別シグナリングで通知するとよい。
MeNBが、PWSメッセージをSeNBからRRCメッセージのコンテナで通知された場合は、RRCメッセージに乗せ換え、該コンテナをDC中のUEに個別に通知するとよい。
MeNBは、SeNBを用いてDCを行っているUEに対して、該PWSメッセージとともに、PWSメッセージを送信するSCGセルの識別子を通知してもよい。
MeNBは、PWSインジケーションを含めたRRCメッセージを送信した後に、PWSメッセージを含めたRRCメッセージを送信する。
また、MeNBは、DC中のUEに対して、PWSインジケーションとPWSメッセージとを一つのRRCメッセージに含めて通知してもよい。この場合、メッセージを一つにすることが可能となるので、MeNBとUEとの間のシグナリング量の削減を図ることが可能となる。
以上の図13に示すようなPWSメッセージ通知処理を行うことによって、SeNBを用いてDCを行っているUEが、該SeNB向けのPWSメッセージを受信することが可能となる。
また、PWSメッセージを、MeNBから、DC中のUEに通知することによって、UEがSeNBから送信されるPWSメッセージを受信する必要が無くなる。これによって、PWSメッセージの受信処理が複雑になることを防ぐことが可能となる。
また、SeNBの報知情報を受信する必要が無くなるので、UEの低消費電力化を図ることができる。
また、前述のPWSインジケーションの通知方法(2)、(3)では、PWSインジケーションをMeNBからDC中のUEに通知する。したがって、UEがSeNBから送信されるPWSインジケーションを受信する必要が無くなる。これによって、PWSメッセージの受信処理が複雑になることを防ぐことが可能となる。また、UEがSeNBのPCHを受信する必要が無くなるので、UEの低消費電力化を図ることができる。
図13に示す例では、DC中のUEに、PWSメッセージに先だってPWSインジケーションが通知される方法を開示したが、以下では他の方法を開示する。
他の方法では、DC中のUEに対するPWSインジケーションを無くす。言い換えると、DC中のUEに対しては、PWSメッセージのみを通知するようにする。
図14は、実施の形態1の変形例1の通信システムにおけるPWSメッセージ通知処理のシーケンスの他の例を示す図である。図14では、DC中のUEに対しては、PWSメッセージのみを通知する場合の例を示している。図14に示すシーケンスは、前述の図10、図11および図13に示すシーケンスと類似しているので、同一のステップについては同一のステップ番号を付して、共通する説明を省略する。
まず、前述の図10および図11に示す場合と同様にして、ステップST1001~ステップST1002、ステップST1004~ステップST1008の処理が行われる。ステップST1301において、SeNBからPWSメッセージを受信したMeNBは、ステップST1401において、該SeNBを用いてDCを行っているUEに対して、PWSメッセージを通知する。具体的には、MeNBは、PWSメッセージをRRCメッセージに含めて通知する。RRCメッセージは、UE個別シグナリングで通知するとよい。
MeNBが、PWSメッセージをSeNBからRRCメッセージのコンテナで通知された場合は、RRCメッセージに乗せ換え、該コンテナをDC中のUEに個別に通知するとよい。
MeNBは、SeNBを用いてDC中のUEに対して、該PWSメッセージとともに、PWSメッセージを送信するSCGセルの識別子を通知してもよい。
ステップST1401において、DC中のUEは、自UE宛ての該RRCメッセージを受信し、SeNB向けのPWSメッセージを受信する。
このように、MeNBは、DC中のUEに対して、SeNB向けのPWSメッセージをUE個別のRRCメッセージに含めて通知する。これによって、SeNB向けのPWSメッセージを特定のUEに通知することができる。したがって、PWSインジケーションをUEに通知しなくても、PWSメッセージをUEに通知することが可能となる。
こうすることによって、PWSインジケーションの送受信の処理が不要となるので、システムとして処理が複雑になることを防ぐことが可能となる。また、PWSインジケーション用のシグナリングも不要となるので、シグナリング負荷を低減することも可能となる。
実施の形態1 変形例2.
本変形例では、MeNBが、DC中のUEに対して、SeNB向けのPWSメッセージを送信する方法を開示する。
本変形例では、MMEが、SeNB向けのPWSメッセージをMeNBにも通知する場合について開示する。MMEがSeNB向けのPWSメッセージをMeNBにも通知する場合として、例えば、MeNBとSeNBとが同一のTAIに存在する場合がある。
従来、MMEからPWSメッセージを受信したMeNBは、該PWSメッセージが、MeNB向けのPWSメッセージの場合しか傘下のUEには通知しない。したがって、仮に、MMEから通知されたPWSメッセージがMeNB向けでなかった場合、MeNBの傘下のUEには、PWSメッセージは通知されない。
たとえ、MMEがSeNB向けのPWSメッセージをMeNBにも通知したとしても、MeNBは、該PWSメッセージを傘下のUEに通知しない。すなわち、MeNBは、SeNB向けのPWSメッセージを、傘下の、該SeNBを用いてDC中のUEに対して通知しない。
したがって、該UEは、SeNB向けのPWSメッセージを受信することが不可能となるという課題が生じる。本変形例では、このような課題を解決する方法を開示する。
MeNBは、DC中のUEに対して、SeNB向けのPWSメッセージを送信する。
MMEからSeNB向けのPWSメッセージを受信したMeNBが、SeNBを用いてDC中のUEに対して、該SeNB向けのPWSメッセージを通知する。
PWSメッセージの通知方法について説明する。図15は、実施の形態1の変形例2の通信システムにおけるPWSメッセージの流れの一例を示す図である。図15に示す構成は、図9および図12に示す構成と類似しているので、同一の部分には同一の参照符号を付して、共通する説明を省略する。図15では、PWSメッセージの流れを、太線の矢符106,151,152で示している。
CBC101からPWSメッセージを受信したMME102は、矢符151で示すように、SeNB104だけでなく、MeNB103に対してもPWSメッセージを通知する。
MeNB103は、MME102から受信したPWSメッセージが、DCに使用しているSeNB104向けか否かを判断する。MeNB103は、DCに使用しているSeNB104向けのPWSメッセージを受信した場合、矢符152で示すように、該SeNB104を用いてDCを行っているUE105に、PWSメッセージを通知する。
SeNB104を用いてDCを行っているUE105は、矢符152で示すように、MeNB103から該SeNB104向けのPWSメッセージを受信する。
このようにすることによって、矢符152に示すように、SeNB104を用いてDCを行っているUE105が、SeNB向けのPWSメッセージを得ることが可能となる。
本変形例においても、実施の形態1の変形例1と同様に、PWSインジケーションが設けられ、PWSメッセージに先立ってDC中のUEに通知されるようにしてもよい。DC中のUEは、PWSインジケーションを受信すると、MeNBから通知されるSeNB向けのPWSメッセージを受信する。
図15には、PWSインジケーションの流れを併せて示す。図15では、PWSインジケーションの流れを細線の矢符123で示す。
矢符151で示すように、MeNB103が、MME102から、DCに使用しているSeNB1004向けのPWSメッセージを受信した場合、MeNB103は、矢符123で示すように、該SeNB104を用いてDCを行っているUE105に、PWSインジケーションを通知してもよい。
PWSインジケーションの通知方法としては、実施の形態1の変形例1で開示したPWSインジケーションの通知方法(3)を適用することができる。
図16は、実施の形態1の変形例2の通信システムにおけるPWSメッセージ通知処理のシーケンスの一例を示す図である。図16では、PWSインジケーションの通知方法として、前述の実施の形態1の変形例1で開示したPWSインジケーションの通知方法(3)を適用した場合の例を示している。図16に示すシーケンスは、前述の図10、図11および図13に示すシーケンスと類似しているので、同一のステップについては同一のステップ番号を付して、共通する説明を省略する。
まず、前述の図10および図11に示す場合と同様にして、ステップST1001、ステップST1002、ステップST1004およびステップST1005の処理が行われる。ステップST1005において、CBCからPWSメッセージを受信したMMEは、PWSメッセージとともに通知されたトラッキングエリアIDリスト(tracking area ID list)から、PWSメッセージを通知するeNBを特定する。ここでは、MeNBとSeNBとがトラッキングエリアIDリストに含まれている場合について示している。
ステップST1008において、MMEは、SeNBに対して、S1-MMEインタフェースを用いて、PWSメッセージを通知する。また、ステップST1601において、MMEは、MeNBに対しても、S1-MMEインタフェースを用いて、PWSメッセージを通知する。具体的には、MMEは、PWSメッセージとともに、警報エリア(warning area)情報を通知する。PWSメッセージおよび警報エリア情報の通知用のメッセージとしては、「Write-Replace Warning Request」メッセージが用いられる。
ステップST1601においてPWSメッセージを受信したMeNBは、ステップST1602において、警報エリア(warning area)情報を用いて、DCに使用しているSeNB向けのPWSメッセージであるか否かを判断する。
DCに使用しているSeNB向けのPWSメッセージで無い場合、MeNBは、該SeNBを用いてDCを行っているUEへのPWSメッセージの送信処理を行わずに、通常の処理に戻る。DCに使用しているSeNB向けのPWSメッセージの場合、MeNBは、警報エリア(warning area)情報を用いて、PWSメッセージを送信するSCGセルを特定する。
ステップST1302において、MeNBは、PWSインジケーションを、該SeNBを用いてDCを行っているUEに通知する。
PWSインジケーションを受信したDC中のUEは、ステップST1303およびステップST1304の処理によって、MeNBから通知されるPWSメッセージを受信する。ステップST1303およびステップST1304の処理の方法としては、実施の形態1の変形例1の方法を適用することができるので、ここでは説明を省略する。
ステップST1603において、MeNBは、MMEに対して、「Write-Replace Warning Response」メッセージを通知し、PWSメッセージ通知処理の処理手順を終了する。
以上の図16に示すようなPWSメッセージ通知処理を行うことによって、SeNBを用いてDCを行っているUEが、SeNB向けのPWSメッセージを受信することが可能となる。
また、MeNBがSeNBからPWSメッセージを受信する必要が無くなるので、SeNBとMeNBとの間で生じるPWSメッセージの送受信処理を削減することが可能となる。したがって、SeNBおよびMeNBにおける処理を簡略化することができ、また、SeNBとMeNBとの間のシグナリング負荷を低減することが可能となる。
本変形例では、DC中のUEに、PWSメッセージに先だってPWSインジケーションが通知される方法を開示したが、以下では他の方法を開示する。
DC中のUEに対するPWSインジケーションを無くす。言い換えると、DC中のUEに対しては、PWSメッセージのみを通知するようにする。
図17は、実施の形態1の変形例2の通信システムにおけるPWSメッセージ通知処理のシーケンスの他の例を示す図である。図17では、DC中のUEに対しては、PWSメッセージのみの通知とする場合を示している。図17に示すシーケンスは、前述の図10、図11、図13、図15および図16に示すシーケンスと類似しているので、同一のステップについては同一のステップ番号を付して、共通する説明を省略する。
まず、前述の図16に示す場合と同様にして、ステップST1001、ステップST1002、ステップST1004~ステップST1008、およびステップST1601の処理が行われる。ステップST1601において、MMEからPWSメッセージを受信したMeNBは、ステップST1602において、警報エリア(warning area)情報を用いて、DCに使用しているSeNB向けのPWSメッセージであるか否かを判断する。
DCに使用しているSeNB向けのPWSメッセージで無い場合、MeNBは、該SeNBを用いてDCを行っているUEへのPWSメッセージ送信処理を行わず、通常の処理に戻る。DCに使用しているSeNB向けのPWSメッセージの場合、MeNBは、警報エリア(warning area)情報を用いて、PWSメッセージを送信するSCGセルを特定する。
ステップST1401において、MeNBは、SeNBを用いてDCを行っているUEに対して、PWSメッセージを通知する。具体的には、MeNBは、PWSメッセージをRRCメッセージに含めて通知する。RRCメッセージは、UE個別シグナリングで通知するとよい。
MeNBは、SeNBを用いてDCを行っているUEに対して、PWSメッセージとともに、PWSメッセージを送信するSCGセルの識別子を通知してもよい。
ステップST1401において、DC中のUEは、自UE宛ての該RRCメッセージを受信し、SeNB向けのPWSメッセージを受信する。
このように、MeNBは、DC中のUEに対して、SeNB向けのPWSメッセージを、UE個別のRRCメッセージに含めて通知することによって、SeNB向けのPWSメッセージを特定のUEに通知することができる。したがって、PWSインジケーションをUEに通知しなくても、PWSメッセージをUEに通知することが可能となる。
こうすることによって、PWSインジケーションの送受信の処理が不要となるので、システムとして処理が複雑になることを防ぐことが可能となる。また、PWSインジケーション用のシグナリングも不要となるので、シグナリング負荷を低減することも可能となる。
実施の形態1 変形例3.
本変形例では、MeNBが、DC中のUEに対して、SeNB向けのPWSメッセージを送信する方法の他の方法を開示する。
実施の形態1の変形例2では、MMEが、SeNB向けのPWSメッセージをMeNBにも通知する場合について開示した。しかし、MMEが、SeNB向けのPWSメッセージをMeNBに通知しない場合も存在する。例えば、MeNBとSeNBとが異なるTAIに存在する場合などである。このような場合は、実施の形態1の変形例2で開示した方法は適用できない。
本変形例では、このような課題を解決する方法を開示する。
MeNBは、MMEに、DCに使用しているSeNBの情報を通知する。MeNBは、この通知を、DCに使用しているSeNBあるいはSCGセルの変更の際に行うようにするとよい。これによって、MMEが有するSeNBの情報が適宜更新されることになる。DCに使用しているSeNBの情報の通知は、SeNBの追加処理において行われてもよい。あるいは、SeNBの変更処理あるいはSeNBの修正処理において行われてもよい。また、SeNBの解放(リリース)処理においては、MeNBは、DCに使用しているSeNBが無いことを示す情報をMMEに通知してもよい。
このようにすることによって、MMEは、PWSメッセージを送信するSeNBと、該SeNBをDCに用いているMeNBとを関連付けることが可能となる。したがって、MMEは、SeNB向けのPWSメッセージを、該SeNBをDCに使用しているMeNBに対して通知することが可能となる。
MMEは、PWSメッセージを受信した場合、DCに使用しているSeNB向けか否かを判断する。MMEは、DCに使用しているSeNB向けのPWSメッセージを受信した場合、MeNBに対して、該PWSメッセージを通知する。
MeNBは、MMEから受信したPWSメッセージが、DCに使用しているSeNB向けか否かを判断する。MeNBは、DCに使用しているSeNB向けのPWSメッセージを受信した場合、該SeNBを用いてDCを行っているUEに、PWSメッセージを通知する。
該SeNBセルを用いてDCを行っているUEは、MeNBから該SeNBセル向けのPWSメッセージを受信する。
PWSメッセージの通知方法について示す。本変形例におけるPWSメッセージの流れは、前述の図15に示す実施の形態1の変形例2の場合と同様である。
実施の形態1の変形例2と同様に、PWSインジケーションが設けられ、PWSメッセージに先立って、DC中のUEに通知されるようにしてもよい。DC中のUEは、PWSインジケーションを受信すると、MeNBから通知されるSeNB向けのPWSメッセージを受信する。
本変形例におけるPWSインジケーションの流れも、前述の図15に示す実施の形態1の変形例2の場合と同様である。
MeNBが、MMEから、DCに使用しているSeNB向けのPWSメッセージを受信した場合、MeNBは、該SeNBを用いてDCを行っているUEに、PWSインジケーションを通知してもよい。PWSインジケーションの通知方法としては、実施の形態1の変形例1で開示したPWSインジケーションの通知方法(3)を適用することができる。
図18は、実施の形態1の変形例3の通信システムにおけるPWSメッセージ通知処理のシーケンスの一例を示す図である。図18に示すシーケンスは、前述の図16に示すシーケンスと類似しているので、同一のステップについては同一のステップ番号を付して、共通する説明を省略する。
まず、前述の図16に示す場合と同様にして、ステップST1001の処理が行われる。ステップST1002において、MeNBは、該UEに対して、DCを実行するために、SeNB追加処理を起動する。これによって、MeNB、UEおよびSeNBの間で、SeNB追加処理が行われる。このSeNB追加処理において、SeNBは、自セルのセルID(Cell ID)、あるいはTAI,あるいは緊急エリアID(Emergency Area ID)を、MeNBに通知する。
ステップST1801において、MeNBは、追加したSeNBに関する情報をMMEに通知する。また、MeNBは、SCGセルに関する情報を通知してもよい。SeNBに関する情報として、警報エリア(Warning Area)情報を特定できる情報、具体的には、SeNBのセルID(Cell ID)、TAI、緊急エリアID(Emergency Area ID)とするとよい。また、SeNBに関する情報として、自SeNBを用いてDCを行っているMeNBの識別子を通知してもよい。これによって、SeNBに関する情報が、どのMeNBがDCに使用しているSeNBに関する情報なのかを認識できるようになる。
SeNBを用いたDCが、DCアーキテクチャ1Aの場合、ステップST1002におけるDC実行のためのSeNB追加処理において、MeNBは、MMEに、S-GWにおけるユーザプレイン(U-plane)のパス変更通知を行う。MeNBは、追加したSeNBに関する情報をMMEに通知するために、この変更通知を利用してもよい。例えば、パス変更通知メッセージに、SeNBに関する情報を含めて通知するようにしてもよい。あるいは、SeNB追加処理において、MeNBは、MMEに、別のメッセージで、SeNBに関する情報を含めて通知してもよい。
ステップST1005において、CBCからPWSメッセージを受信したMMEは、PWSメッセージとともに受信したトラッキングエリアIDリスト(tracking area ID list)から、PWSメッセージを通知するeNBを特定する。
ステップST1802において、MMEは、特定したeNBと、ステップST1801でMeNBから受信した、追加したSeNBに関する情報を用いて、DC中のSeNBであるか否かを判断する。特定したeNBがDC中のSeNBであった場合、該PWSメッセージが、DC中のSeNB向けであると判断する。特定したeNBがDC中のSeNBでなかった場合、該PWSメッセージが、DC中のSeNB向けでは無いと判断する。
該PWSメッセージがDC中のSeNB向けでは無い場合、該SeNBを用いてDCを実行しているMeNBへはPWSメッセージ送信処理を行わず、通常の処理に戻る。
該PWSメッセージがDC中のSeNB向けの場合、MMEは、ステップST1801でMeNBから受信した、追加したSeNBに関する情報を用いて、PWSメッセージを送信するeNBを特定する。ここではMeNBになる。また、MMEは、ステップST1801で受信した、追加したSeNBに関する情報と、該情報を通知してきたMeNBとを関連付けておき、該SeNBと関連付けられたMeNB情報を用いて、PWSメッセージを送信するeNBを特定してもよい。
PWSメッセージを送信するeNBを特定したMMEは、該eNBに対してPWSメッセージを通知する。該eNBは、ここではMeNBとなる。ステップST1601において、MMEは、MeNBに対しても、S1-MMEインタフェースを用いて、SeNB向けのPWSメッセージを通知する。
MMEは、PWSメッセージとともに、トラッキングエリアIDリスト(tracking area ID list)、警報エリア(warning area)情報、グローバルeNB ID(Global eNB ID)を通知する。該通知用のメッセージとして、「Write-Replace Warning Request」メッセージを用いる。また、PWSメッセージ固有の識別子を通知してもよい。
ステップST1601において、PWSメッセージを受信したMeNBは、ステップST1602において、警報エリア(warning area)情報を用いて、DCに使用しているSeNB向けのPWSメッセージか否かを判断する。
DCに使用しているSeNB向けのPWSメッセージで無い場合、MeNBは、該SeNBを用いてDCを行っているUEへのPWSメッセージ送信処理を行わず、通常の処理に戻る。DCに使用しているSeNB向けのPWSメッセージの場合、警報エリア(warning area)情報を用いて、PWSメッセージを送信するSCGセルを特定する。
ステップST1302において、MeNBは、PWSインジケーションを、該SeNBを用いてDCを行っているUEに通知する。PWSインジケーションを受信したDC中のUEは、ステップST1303およびステップST1304において、MeNBから通知されるPWSメッセージを受信する。ステップST1303およびステップST1304の方法としては、実施の形態1の変形例1の方法を適用することができるので、ここでは説明を省略する。
MMEは、ステップST1802において、PWSメッセージがDC中のSeNB向けと判断した場合、MeNBに対して、PWSメッセージとともに、DC中のSeNB向けであることを示す情報を通知してもよい。これによって、MeNBは、受信したPWSメッセージが、DCに使用しているSeNB向けであることを明示的に認識することが可能となる。MeNBは、ステップST1602における判断に該情報を用いるとよい。これによって、誤動作を低減させることが可能となる。
以上の図18に示すようなPWSメッセージ通知処理を行うことによって、SeNBを用いてDCを行っているUEが、該SeNB向けのPWSメッセージを受信することが可能となる。
MMEが、SeNB向けのPWSメッセージをMeNBに通知しない場合、例えば、MeNBとSeNBとが異なるTAIに存在する場合なども、MeNBは、SeNB向けのPWSメッセージを、DC中のUEに通知することが可能となる。
DC中のUEは、SeNB向けのPWSメッセージをMeNBから受信することが可能となる。
本変形例では、DC中のUEに、PWSメッセージに先だって、PWSインジケーションが通知される方法を開示したが、以下では他の方法を開示する。
DC中のUEに対するPWSインジケーションを無くす。言い換えると、DC中のUEに対しては、PWSメッセージのみを通知するようにする。
図19は、実施の形態1の変形例3の通信システムにおけるPWSメッセージ通知処理のシーケンスの他の例を示す図である。図19では、DC中のUEに対しては、PWSメッセージのみの通知とする場合を示している。図19に示すシーケンスは、前述の図17および図18と類似しているので、同一のステップについては同一のステップ番号を付して、共通する説明を省略する。
図19に示す例では、まず、前述の図18に示す場合と同様にして、ステップST1001,ST1002,ST1801,ST1004~ST1008,ST1802,ST1601,ST1602の処理が実行される。その後、前述の図17に示す場合と同様にして、ステップST1401,ST1012,ST1613の処理が実行される。
このようにすることによって、本変形例においても、PWSインジケーションの送受信の処理を不要とすることができる。したがって、システムとして処理が複雑になることを防ぐことが可能となる。また、PWSインジケーション用のシグナリングも不要となるので、シグナリング負荷を低減することも可能となる。
実施の形態1 変形例4.
本変形例では、SeNBが、DC中のUEに対して、自SeNB向けのPWSメッセージを送信する方法の他の方法を開示する。
本変形例では、MeNBに接続されるMMEと、SeNBに接続されるMMEとが異なる場合について示す。
この場合、MMEからPWSメッセージを受信したSeNBが、DC中のUEに対して、自SeNB向けのPWSメッセージを送信すればよい。SeNBは直接、DC中のUEに対して、自SeNB向けのPWSメッセージを送信する。あるいは、SeNBは、MeNBを介して、DC中のUEに対して、自SeNB向けのPWSメッセージを送信してもよい。
DC中のUEは、SeNBから、あるいは、MeNBから、SeNB向けのPWSメッセージを受信する。この方法としては、実施の形態1、実施の形態1の変形例1で開示した方法を適用すればよい。PWSメッセージが特定の一つまたは複数のSCGセルに通知される場合も同様である。
PWSメッセージの通知方法について説明する。図20は、実施の形態1の変形例4の通信システムにおけるPWSメッセージの流れの一例を示す図である。図20に示す構成は、図9および図12に示す構成と類似しているので、同一の部分には同一の参照符号を付して、共通する説明を省略する。図20では、PWSメッセージの流れを、太線の矢符202,203,121,122,108で示している。
図20では、SeNB104に接続されるMME(以下「SeNB用MME」という場合がある)201と、MeNB103に接続されるMME102(以下「MeNB用MME」という場合がある)とが異なる場合を示している。
CBC101は、SeNB用MME201に接続される。図20では、CBC101からSeNB104までのPWSメッセージの流れを、太線の矢符202,203でを示す。
PWSメッセージは、不図示のCBEからCBC101へ通知され、CBC101からSeNB用MME201に通知され、SeNB用MME201からSeNB104へ通知される。
eNBは、自セルがDCに用いられている場合、すなわち、SeNB104である場合、矢符108で示すように、自セルを用いてDCを行っているUE105に、PWSメッセージを通知する。また、この場合、PWSインジケーションは、矢符109,110で示すように、SeNB104からMeNB103およびUE105に通知される。
SeNB104は、自セルを用いてDCを行っているUE105に、矢符121,122で示すように、MeNB103を介してPWSメッセージを通知してもよい。この場合、PWSインジケーションは、矢符110,109,123で示すように、SeNB104からMeNB103およびUE105に通知される。
SeNBがDC中のUEにPWSメッセージを通知する場合の、PWSメッセージおよびPWSインジケーションの通知方法には、前述の実施の形態1で開示した方法を適用すればよい。これによって、SeNBを用いてDCを行っているUEは、SeNBからPWSメッセージを受信可能となる。
SeNBが、MeNBを介してDC中のUEにSeNB向けのPWSメッセージを通知する場合の、PWSメッセージおよびPWSインジケーションの通知方法には、前述の実施の形態1の変形例1で開示した方法を適用すればよい。これによって、SeNBを用いてDCを行っているUEは、MeNBからSeNB向けのPWSメッセージを受信可能となる。
このようにすることによって、MeNBに接続されるMMEと、SeNBに接続されるMMEとが異なる場合についても、SeNBを用いてDCを行っているUEは、SeNB向けのPWSメッセージを受信可能となる。
MeNBに接続されるMMEとSeNBに接続されるMMEとは異なるが、MeNBに接続されるMMEにも、SeNBに接続されるMMEにも、CBCが接続されている場合には、前述の実施の形態1の変形例3で開示した方法を適用することができる。
この場合、CBCは、MeNBが接続されるMMEにPWSメッセージを通知する。PWSメッセージを通知されたMMEとDC中のUEとの間におけるSeNB向けのPWSメッセージの通知方法には、前述の実施の形態1の変形例3で開示した方法を適用すればよい。
このようにすることによって、SeNBを用いてDCを行っているUEは、SeNB向けのPWSメッセージを受信可能となる。
MeNBに接続されるMMEと、SeNBに接続されるMMEとは異なるが、MeNBに接続されるMMEにも、SeNBに接続されるMMEにも、CBCが接続されており、MeNBとSeNBとが同じトラッキングエリア(TA)内にあるような場合には、前述の実施の形態1の変形例2で開示した方法を適用することができる。
これによって、SeNBを用いてDCを行っているUEは、SeNB向けのPWSメッセージを受信可能となる。MCGセルとSCGセルとが同じTA内にあるような場合も同様である。
同一のPWSメッセージをMeNBとSeNBとの両方が傘下のUEに通知する場合がある。換言すると、MeNB向けPWSメッセージとSeNB向けPWSメッセージとが同じ場合がある。このような場合、本実施の形態および変形例で開示した方法を用いると、UEは、MeNB向けPWSメッセージとSeNB向けPWSメッセージとを受信することになる。すなわち、同一のPWSメッセージを重複して受信することになる。
UEは、同じPWSメッセージを重複して受信可能とすることによって、たとえ、どちらか一つのPWSメッセージを受信できなかったとしても、他のPWSメッセージを受信することができるようになる。したがって、UEがPWSメッセージを受信できなくなる確率を低減することができる。これによって、PWSとして堅固なシステムを構築することができる。
しかし、UEが同一のPWSメッセージを重複して受信することは、消費電力の増大につながるという問題がある。この問題を解決するための方法として、以下の(1)~(3)の3つを開示する。
(1)UEがMeNBとSeNBとの両方からPWSメッセージを通知される場合、UEは、MeNBから通知されたPWSメッセージと、SeNBから通知されたPWSメッセージとが同一のPWSメッセージか否かを判断する。この判断に、PWSメッセージとともに通知される、メッセージ固有の識別子を用いるとよい。メッセージ固有の識別子として、例えば、メッセージID(message ID)がある。UEは、最初に通知されたPWSメッセージを受信する。その際に、該PWSメッセージのメッセージIDを記録する。後に通知されたPWSメッセージのメッセージIDを、以前に受信したPWSメッセージのメッセージIDと比較する。
メッセージIDが同じ場合は、そのPWSメッセージを受信しない。またはPWSメッセージを復調しないとしてもよい。メッセージIDが異なる場合は、PWSメッセージを受信する。また、該メッセージIDを記録する。これを繰り返すことによって、UEは、同一のPWSメッセージを重複して受信することを防ぐことができる。したがって、UEの消費電力の増大を防ぐことができる。以上の(1)の方法は、実施の形態1で開示した方法を用いる場合に適用するとよい。
(2)MeNBがSeNBからPWSメッセージを受信する場合、MeNBは、自MeNB向けPWSメッセージと、SeNB向けPWSメッセージとが同じかどうかを判断するとよい。PWSインジケーションの通知方法は、前述の(2)あるいは(3)の方法とするとよい。
MeNBが判断する方法を開示する。MeNBは、自MeNB向けPWSメッセージのメッセージIDを記録し、記録した自MeNB向けPWSメッセージのメッセージIDと、SeNBから受信したPWSメッセージとともに通知されたメッセージIDとを比較する。メッセージIDが同じ場合は、該SeNBから受信したPWSメッセージを、該SeNBを用いてDCを行っているUEに対して送信しない。この場合、PWSインジケーションも該UEに対して通知しないようにするとよい。メッセージIDが異なる場合は、MeNBは、該SeNBから受信したPWSメッセージを、該SeNBを用いてDCを行っているUEに対して送信する。
このようにすることによって、UEが同一のPWSメッセージを重複して受信することを防ぐことができる。したがって、UEの消費電力の増大を防ぐことができる。
以上の(2)の方法は、実施の形態1の変形例1で開示した方法を用いる場合に適用するとよい。
(3)MeNBが、MMEからSeNB向けPWSメッセージを受信する場合、MeNBが、自MeNB向けPWSメッセージと、SeNB向けPWSメッセージとが同じかどうかを判断するとよい。
MeNBが判断する方法を開示する。MeNBは、MMEから受信したPWSメッセージが、SeNB向けであるとともに、自MeNB向けであるか否かを判断する。この場合、MMEからPWSメッセージとともに通知された警報エリア(Warning Area)情報を用いて判断すればよい。具体的には、警報エリア情報に、PWSメッセージを送信するeNBあるいはセルの情報として、自MeNBと、自MeNBとDCを行っているSeNBとの両方が存在するか否かを判断する。
両方が存在する場合は、MeNBは、自MeNB向けPWSメッセージと、SeNB向けPWSメッセージとが同じと判断し、該SeNBを用いてDCを行っているUEに対しては、該PWSメッセージを一度のみ送信する。この場合、PWSインジケーションも該UEに対して一度のみ通知するようにしてもよい。SeNB向けPWSメッセージの通知方法を実行しないとしてもよい。両方が存在しない場合は、各PWSメッセージの通知方法でUEに対してPWSメッセージを通知する。
このようにすることによって、UEが同一のPWSメッセージを重複して受信することを防ぐことができる。したがって、UEの消費電力の増大を防ぐことができる。
以上の(3)の方法は、実施の形態1の変形例2で開示した方法を用いる場合、実施の形態1の変形例3で開示した方法を用いる場合に適用するとよい。
実施の形態1の変形例4で開示した方法を用いる場合は、PWSメッセージの通知経路に応じて、上で開示した方法を適宜適用すればよい。これによって、同様の効果を得ることができる。
実施の形態2.
実施の形態2で解決する課題、およびその解決策について、以下に示す。
緊急呼(emergency call)などの緊急サービス(emergency service)において、将来、地図情報などの大容量のデータ通信の要求が生じることが考えられる。したがって、緊急サービス用の緊急セッション(emergency session)または緊急サービス用の緊急ベアラ(emergency bearer)に対しても、DCを実行可能とする要求が生じると考えられる。
3GPPでは、緊急サービスについての規格が決められてきたが(非特許文献13 4.3.12参照)、緊急サービスへのDCの導入に関する議論は何らなされていない。
したがって、緊急ベアラに対して、3GPPで議論されているSeNB追加処理(SeNB addition procedure)あるいはSeNB修正処理(SeNB modification procedure)(非特許文献9参照)などのDCを実行するための処理を単に適用しただけでは、緊急ベアラに対して、SeNBを用いたDCを行えない場合が生じてしまう。
例えば、MeNBが、あるベアラに対してDCを実行する場合、SeNBに対してSeNB追加(SeNB addition)要求を通知するときに、該ベアラが緊急ベアラか否かを通知していない。したがって、SeNBは、MeNBからのSeNB追加(SeNB addition)要求が緊急ベアラ用か否かを認識できない。
また、SeNBは、自SeNBあるいはSCGセルのリソースの状況に応じて、MeNBから受信したSeNB追加(SeNB addition)要求を拒否する場合がある。例えば、SeNBがオーバロード(overload)の場合、あるいは、SeNBがMMEからオーバロード開始処理(overload start procedure)を通知されている場合、あるいは、SeNBがDC対象のUEに対してアクセス制限している場合、例えば「not suitable」の場合などである。このような場合、SeNBは、MeNBからのSeNB追加要求を拒否してしまう。
このように、緊急ベアラに対するSeNB追加処理であることを認識しないSeNBは、自SeNBの状況に応じて、SeNB追加処理を拒否してしまう場合が発生する。拒否されたMeNBは、緊急ベアラに対してDCを実行することが不可能となる。言い換えると、緊急サービスを提供するUEに対して、DCの実行が不可能となってしまう。
本実施の形態では、緊急ベアラに対してDCを実行可能とする方法を開示する。実施の形態2における解決策を以下に示す。
SeNBは、MeNBからのDCを実行するための処理要求において、該要求が緊急ベアラに対する要求の場合、拒否しない。DCを実行するための処理要求として、例えば、SeNB追加要求およびSeNB修正要求などがある。MeNBは、緊急ベアラに対してDCを行う場合、SeNB追加要求あるいはSeNB修正要求に、これらの要求が緊急ベアラであることを示す情報を含める。
図21は、実施の形態2の通信システムにおける緊急ベアラに対するDC実行処理のシーケンスの一例を示す図である。
MeNB、SeNBは、DCを実行した場合に用いられるが、ここでは説明を簡略化するために、後にDCに用いられるeNBをMeNB、SeNBと示すこととする。
まず、緊急サービスのための緊急ベアラが設立される際の緊急ベアラ関連情報の流れを説明する。
緊急サービスを行うUEは、ステップST2201において、NASメッセージとして、アタッチ要求(Attach request)あるいはPDN接続要求(PDN connectivity request)に、その理由が緊急であることを示す情報(以下「緊急情報」という場合がある)を含めて、MMEに通知する。本実施の形態では、UEは、PDN接続要求(PDN connectivity request)に緊急情報を含めて、MMEに通知する。
その際に、UEは、緊急サービスに関するRRC接続要求メッセージに、緊急情報を含めて、MeNBに通知する。例えば、RRC接続要求メッセージとして、RRC接続設立要求(RRC connection establishment request)メッセージに緊急情報を含めて、MeNBに通知する。
MeNBは、緊急情報を用いて、該要求が緊急サービス用か否かを判断する。該要求が緊急サービス用である場合、MeNBは、通常のベアラで行うアクセス制限を行わずに、該要求を受理する。
MeNBは、S1メッセージとして、初期NASメッセージ(initial NAS message)に、緊急情報を含めて、MMEに通知する。MMEは、初期NASメッセージの緊急情報、またはアタッチ要求(Attach request)あるいはPDN接続要求(PDN connectivity request)に含まれる緊急情報を用いて、これらの要求が緊急サービス用か否かを判断する。
緊急サービス用である場合、MMEは、緊急サービス用のP-GW(緊急用P-GW)を選択する。そして、MMEは、緊急用P-GWのアドレスを導出する。
MMEは、ステップST2202において、S11メッセージとして、セッション作成要求(create session request)メッセージに緊急用P-GWのアドレスを含めて、S-GWに通知する。S-GWは、ステップST2203において、緊急用P-GWのアドレスを用いて、緊急用P-GWに対して、S5メッセージとして、セッション作成要求(create session request)を通知する。
緊急用P-GWは、ステップST2204において、PCRF(Policy and charging rules function)から、緊急サービス用ARP(Allocation and Retention Priority)値を得る。
緊急サービス用ARP値を得た緊急用P-GWは、該ARP値を用いて、EPSベアラ用QoS関連情報を導出する。EPSベアラ用QoS関連情報としては、QCI、ARP、GBR、MBRがある。
緊急用P-GWは、ステップST2205において、セッション作成応答(create session response)メッセージにEPSベアラ用QoS関連情報を含めて、S-GWに通知する。S-GWは、ステップST2206において、セッション作成応答(create session response)メッセージにEPSベアラ用QoS関連情報を含めて、MMEに通知する。MMEは、受信した、EPSベアラ用QoS関連情報から、E-RAB(E-UTRAN Radio Access Bearer)レベルQoS情報を導出する。
ステップST2207において、MMEは、E-RABセットアップ要求(E-RAB setup request)メッセージに、E-RABレベルQoS情報と該ARP値とを含めて、MeNBに通知する。通知には、S1メッセージが用いられる。MeNBは、受信したE-RABレベルQoS情報をもとに、MeNBを介して、S-GWとUEとの間に設けられるE-RABのための設定を行う。
ステップST2208において、MeNBは、受信したE-RABレベルQoS情報をもとに、RRC接続再設定(RRC connection reconfiguration)メッセージにE-RAB用のリソース設定を含めて、UEに通知する。
また、MMEは、アタッチ応答(attach response)メッセージあるいはPDN接続アクセプト(PDN connectivity accept)メッセージに、ARPを除くEPSベアラ用QoS関連情報を含めて、UEに通知する。アタッチ応答メッセージあるいはPDN接続アクセプトメッセージは、個別EPSベアラコンテキスト要求アクティブ化(ACtivate Dedicated EPS Bearer Context Request)メッセージであってもよい。
RRC接続再設定(RRC connection reconfiguration)メッセージでE-RAB用のリソース設定を受信したUEは、E-RABのためのリソース設定を行い、ステップST2209において、MeNBに対して、RRC接続再設定完了(RRC connection reconfiguration complete)メッセージを通知する。
E-RABのための設定を行ったMeNBは、ステップST2210において、ベアラセットアップ応答(Bearer Setup Response)メッセージをMMEに通知する。
また、NASメッセージであるアタッチ応答(Attach Response)メッセージあるいはPDN接続アクセプト(PDN Connectivity Accept)メッセージを受信したUEは、ステップST2211のダイレクト転送(Direct Transfer)メッセージおよびステップST2212のPDN接続完了(PDN Connectivity Complete)メッセージで、MMEに対してPDN接続(PDN connectivity)の完了を通知する。
ステップST2213において、パス設定処理が行われる。これによって、緊急ベアラ(Emergency Bearer)の設定が行われ、ステップST2214で示すように、緊急ベアラに対するUL/DLデータの通信が可能となる。
緊急ベアラにおいて、DCを実行する方法について開示する前に、従来のDCを実行する方法について説明する。
UEに対してDCを行うことを決定したMeNBは、該UEに対してMeNBで提供されるリソースとSeNBで提供されるリソースの合計が、MMEから要求されたE-RABレベルのQoSが保証されるように、あるいはそれ以上となるように、SeNBに対してリソースの要求を行う。
したがって、MeNBは、MMEから要求されたE-RABレベルのQoS情報と異なる値をSeNBに設定する場合が生じる。MeNBは、SeNBに対するDC実行要求メッセージ、例えば、SeNB追加要求メッセージに、SeNBに要求するE-RABレベルのQoS情報を含めて、SeNBに通知する(非特許文献9参照)。
現在3GPPで議論されているDCを実行する場合のSeNB追加要求は、以上のとおりである。
しかし、この方法では、SeNBは、MeNBからDC実行を要求されたベアラが、緊急サービス用か否かを認識することができない。これは、SeNBに対するリソース要求をMeNBが設定するので、MeNBがDC実行要求メッセージにARP値を含めるかどうかが明確でないためである。また、たとえ、DC実行要求メッセージに、ARP値を含めて要求したとしても、該ARPが緊急サービス用のARP値ではない場合も生じるためである。
このように、緊急ベアラに対するSeNB追加処理であることを認識しないSeNBは、自SeNBの状況によって拒否してしまい、緊急サービスを提供するUEに対して、DCの実行が不可能となってしまう。
このような課題を解決するための方法を開示する。
MeNBは、SeNBに対するDC実行要求メッセージに、該要求が緊急ベアラに対するDC実行要求であることを示す情報を含める。緊急ベアラに対するDC実行要求を受信したSeNBは、DC実行要求を拒否しない。すなわち、DCの実行を許可する。
緊急ベアラに対してDCを実行する方法の一例を、図21を用いて説明する。
前述のように、ステップST2214において、緊急ベアラに対するUL/DLデータの通信が行われている。ステップST2215において、MeNBは、SeNBに対するDC実行要求メッセージ、例えば、SeNB追加要求メッセージをSeNBに通知する。
このとき、該SeNBに対するDC実行要求メッセージ、例えば、SeNB追加要求メッセージに、該要求が緊急ベアラに対してであることを示す情報を含めて通知する。SeNBに要求するE-RABレベルのQoS情報とともに、該要求が緊急ベアラに対してであることを示す情報を含めて通知してもよい。または、DC実行要求が緊急ベアラに対するものであることを示す情報を通知するための新たなメッセージを設けてもよい。
MeNBは、SeNBに対して、緊急ベアラに対するDC実行要求を行う際に、該新たなメッセージも通知するとよい。該情報の通知には、X2インタフェースあるいはXnインタフェースを用いるとよい。また、該情報を、インジケーション(indication)としてもよいし、理由(cause)情報としてもよい。
このようにすることによって、SeNBは、該要求が緊急ベアラに対するDC実行要求メッセージであることを認識することができる。ステップST2215において、緊急ベアラに対するものであることを示す情報を受信したSeNBは、該情報を用いて、該要求が緊急ベアラに対するDC実行要求か否かを判断する。
該要求が緊急ベアラに対するDC実行要求でない場合、SeNBは、自SeNBあるいはSCGセルの状況に応じて、該要求を拒否するか受理するかを決定する。該要求が緊急ベアラに対するDC実行要求の場合、SeNBは、該要求に対して拒否を行わない。すなわち、該要求を受理する。
図21では、要求が緊急ベアラに対するDC実行要求である場合を示しているので、SeNBは、DC実行要求に対して拒否を行わず、受理する。
SeNBは、ステップST2216において、DC実行要求応答、例えば、SeNB追加要求応答を、MeNBに通知する。MeNBは、ステップST2217において、UEに対して、RRC接続再設定(RRC Connection Reconfiguration)メッセージによって、DCを実行させるための無線リソースの設定を行う。
SeNBを使用したDCのための無線リソースの設定を行ったUEは、ステップST2218において、MeNBに対して、RRC接続再設定完了(RRC Connection Reconfiguration Complete)メッセージによって、該設定の完了を通知する。
MeNBは、ステップST2219において、SeNBに対して、SeNB再設定完了(SeNB Reconfiguration Complete)メッセージによって、SeNBを使用したDCのための無線リソースの設定が完了したことを通知する。以上のようにすることによって、ステップST2202において、MeNB、SeNB、UE間で、緊急ベアラに対するDC実行処理が行われる。
また、ステップST2215において、MeNBは、SeNBに、緊急ベアラのDC実行要求メッセージ、例えば、SeNB追加(SeNB addition)要求あるいはSeNB修正(SeNB modification)要求の際に、緊急ベアラ用のベアラ設定を通知してもよい。つまり、MeNB自体が設定されたのと同じベアラ設定をSeNBに要求してもよい。
言い換えると、MeNBは、緊急ベアラのためのSeNBへのリソース要求のために、MMEから要求されたE-RABレベルのQoS情報と異なる値をSeNBに設定しない。すなわち、同じ値をSeNBに設定する。
例えば、MeNBは、MMEから通知された緊急ベアラ用のE-RABレベルのQoS情報をSeNBに設定して、DC実行要求を行う。緊急ベアラ用のE-RABレベルのQoS情報としてARP値を含めてもよい。
このようにすることによって、SeNBは、緊急ベアラに対するDC実行要求であることを認識することが可能となるので、緊急ベアラに対しては拒否を行わないようにすることによって、自SeNBあるいはSCGセルの状況によって拒否してしまう場合を無くすことができる。したがって、緊急サービスを提供するUEに対してDCを実行可能とすることができる。
また、ステップST2215において、MeNBは、SeNBに、緊急ベアラのDC実行要求メッセージ、例えば、SeNB追加(SeNB addition)要求あるいはSeNB修正(SeNB modification)要求の際に、緊急ベアラ用であることを示すARP値を通知してもよい。SeNBは、緊急ベアラのためのARP値を、予め認識しておくとよい。例えば、規格で予め静的に決められていてもよい。あるいは、オペレータによって設定しておいてもよい。
他の方法として、P-GWは、PCRFから緊急ベアラ用のARP値を取得し、MMEを介してSeNBに通知してもよい。また、他の方法として、MMEは、P-GWから緊急ベアラ用のARP値を取得し、MMEからSeNBに通知しておいてもよい。該ARP値を緊急ベアラ専用としてもよい。
このようにすることによって、要求が緊急ベアラに対するものであることを示す情報を用いずに、SeNBは、ARP値で判断することが可能となる。したがって、該情報をMeNBからSeNBに通知する必要がなくなるので、X2あるいはXn間の情報量を削減することができる。
実施の形態2 変形例1.
SeNBが緊急ベアラの設立を許可していない場合がある。例えば、地域毎の規則(local regulation)、およびオペレータの意向(operator's policy)による場合などである。このような場合、例えばMeNBがSeNBに対して緊急ベアラに対するDC実行要求であることを示したとしても、SeNBは受理することはできない。
実施の形態2で開示した方法では、このような場合もSeNBは拒否することはできなくなってしまう、という問題が生じる。
本変形例では、このような課題を解決する方法を開示する。
SeNBが緊急ベアラの設立を許可していない場合、SeNBは、MeNBからのDC実行要求、例えば、SeNB追加(SeNB addition)要求あるいはSeNB修正(SeNB modification)要求において、該要求が緊急ベアラに対する要求の場合、拒否する。SeNBは、MeNBに対して、拒否(Reject)メッセージを通知するとよい。該メッセージに、拒否の理由情報を含めるとよい。拒否の理由情報として、緊急ベアラの設立を許可していなことを示す情報を設けておくとよい。SeNBが緊急ベアラの設立を許可していない場合に、SeNBは、MeNBからの緊急ベアラに対するDC実行要求に対して、拒否する場合、拒否メッセージに、緊急ベアラの設立を許可していなことを示す情報を含めて、MeNBに通知するとよい。緊急ベアラの設立を許可していなことを示す情報を受信したMeNBは、UEに対して、該SeNBを用いてDCを行わない。
拒否メッセージを受信したMeNBは、他のSeNBを用いてDCを実行することを判断可能となる。拒否メッセージを受信したMeNBが、他のSeNBを用いてDCを実行させるようにするために、拒否メッセージを受信したMeNBは、拒否メッセージを通知したSeNBに対して、所定の期間DC実行要求を行うことを禁止してもよい。これにより、無駄なDC実行要求メッセージを通知しなくて済むので、シグナリング量の削減を図ることができる。
所定の期間は、予め静的に決められていてもよい。例えば、規格で決めておいてもよい。予め決めておくことで、処理を簡易にすることが可能となる。あるいは、SeNBが拒否メッセージに含めてMeNBに通知してもよい。この場合、SeNBがその時の状況に応じて柔軟に所定の期間を設定できる。通信システムの柔軟な運用を可能にする。なお、前述の方法は、緊急ベアラの設立を許可していなことによる拒否メッセージに限らず適用できる。
本変形例で示した課題を解決する他の方法を開示する。
SeNBが緊急ベアラの設立を許可していない場合も、一旦、SeNBは、MeNBに、DC実行要求応答メッセージを通知する。該DC実行要求応答メッセージに、緊急ベアラの設立を許可していなことを示す情報を含めておく。MeNBは、SeNBから緊急ベアラの設立を許可していないことを示す情報を受信した場合、SeNBに対して、DC実行リリースメッセージ、例えば、SeNBリリース(SeNB Release)メッセージを通知する。また、MeNBは、UEに対して、RRC接続再設定メッセージを通知しない。これにより、MeNBは、該SeNBを緊急ベアラ用のDCに用いない。この方法は、実施の形態2で開示した方法に限らず、従来の、SeNBは、MeNBからDC実行を要求されたベアラが、緊急サービス用か否かを認識することができない場合にも適用することができる。
本変形例で示した課題を解決する他の方法を開示する。
SeNBは、予め、自セルが緊急ベアラの設立を許可していないことを示す情報を周辺のeNBに通知してもよい。周辺のeNBとしては、DCする可能性のあるeNBとしてもよい。MMEを介して周辺のeNBに通知してもよい。MeNBは、該情報を用いて、該SeNBに対して緊急ベアラのDCを行うかどうかを判断する。SeNBが緊急ベアラの設立を許可していない場合、該SeNBを用いて緊急ベアラに対するDCを行わないようにする。この方法も、実施の形態2で開示した方法に限らず、従来の、SeNBは、MeNBからDC実行を要求されたベアラが、緊急サービス用か否かを認識することができない場合にも適用できる。
MMEが、SeNBが緊急ベアラの設立を許可していないことを認識している場合、予め、MMEがSeNBとDCを行う可能性のあるMeNBに対して、該SeNBの識別子と、該SeNBが緊急ベアラの設定を許可していなことを示す情報とを通知してもよい。これによって、MeNBは、該情報を用いて、該SeNBに対して緊急ベアラのDCを行うかどうかを判断する。SeNBが緊急ベアラの設立を許可していない場合、該SeNBを用いて緊急ベアラに対するDCを行わないようにする。
これらの方法によって、SeNBが緊急ベアラの設立を許可していない場合に、SeMBが緊急ベアラのためのリソースを割当てないようにすることが可能となる。地域毎の規則(local regulation)、およびオペレータの意向(operator's policy)を反映したシステムを構築することができる。
実施の形態2 変形例2.
緊急ベアラに対して、DCをサポートさせようとすると、実施の形態2および実施の形態2の変形例1で示したような付加的な処理が必要となるので、システムとして処理の複雑さが増す。処理が複雑になると、システムの安定性が劣化してしまう。
本変形例では、安定なシステムを構築するための方法を開示する。
緊急ベアラに対しては、DCを行わない。eNBは、DCの実行を判断する際に、DCの実行を行うべきベアラが、緊急ベアラか否かを判断する。緊急ベアラの場合、DCを行わない。すなわち、eNBは、DC実行処理を起動しない。緊急ベアラでない場合、DCを行う。すなわち、eNBは、DC実行処理を可能とする。
このように、緊急ベアラに対してはDCを行わないとすることによって、安定なシステムを構築することが可能となる。
緊急ベアラに対しては、DCをサポートするか否かを通信システムの状況に応じて適宜使い分けられるようにしてもよい。
例えば、高スループットの要求が低い場所(混雑していない場所)などでは、緊急ベアラに対してDCサポートするよりも安定なシステムを構築した方がよい場合がある。したがって、高スループットの要求が高い場所では、緊急ベアラに対してDCを実行可能とし、高スループットの要求が低い場所では、緊急ベアラに対してDCの実行を行わないとする。スループットの要求に閾値を設けておき、eNBは該閾値に基づいて判断してもよい。該閾値は、予め規格などで静的に決められていてもよいし、MMEがeNBに通知するようにしてもよい。
このようにすることによって、緊急ベアラに対するDCの実行を通信システムの状況に応じて変えることが可能となるので、通信システムの状況に応じた柔軟な運用が可能となる。
また、緊急ベアラに対しては、DCをサポートするか否かをUEの消費電力に応じて適宜使い分けられるようにしてもよい。
例えばアーキテクチャ3CによるDCが実行されると、UEは、MeNBおよびSeNBの両方と通信を行う必要があるので、UEの消費電力が増大する。UEの電池切れにより緊急サービスが中断することは避けたい。状況に応じてできる限りUEの消費電力を抑える必要がある。したがって、UEの電池残量が高い場合は、緊急ベアラに対してDCを実行可能とし、UEの電池残量が低い場合は、緊急ベアラに対してDCの実行を行わないとする。
UEは、eNBに対して電池残量情報を送信する。eNBは、UEの電池残量情報を受信し、該電池残量情報を用いて、緊急ベアラに対してDCさせるか否かを判断するとよい。
eNBは、UEから電池残量情報を得るために、UEに対して、電池残量情報要求メッセージを通知してもよい。RRCメッセージで通知してもよい。UE個別のメッセージで通知してもよい。例えば、eNBは、UE情報要求(UE Information Request)メッセージに、電池残量情報の要求情報を含めて、UEに対して通知してもよい。UE情報要求(UE Information Request)メッセージを受信したUEは、UE情報要求メッセージの中に電池残量情報の要求情報が含まれる場合、eNBに対して、電池残量情報をUE情報応答(UE Information Response)メッセージに含めて通知する。
このようにすることによって、eNBは、UEから電池残量情報を受信することが可能となり、eNBは、緊急ベアラに対してはDCをサポートするか否かをUEの消費電力に応じて判断することが可能となる。緊急ベアラに対しては、DCをサポートするか否かをUEの消費電力に応じて適宜使い分けられるようになる。
スモールセルを低消費電力化するために、あるいは、多数のスモールセルが運用された場合の干渉を低減するために、スモールセルをオンあるいはオフすることが検討されている。緊急ベアラに用いるためにスモールセルをオンする処理においては、スモールセルは、自セルをオンする処理を拒否しないようにしておくとよい。また、緊急ベアラにスモールセルが用いられている場合、該スモールセルは、自セルをオフする処理を拒否するようにしておくとよい。この方法として、本実施の形態および変形例で開示した方法を適宜適用するとよい。例えば、スモールセルのオンを要求するメッセージに、緊急ベアラ用であることを示す情報を含める、などである。
実施の形態3.
実施の形態3で解決する課題、およびその解決策について、以下に示す。
現在の規格では、設定されたベアラに対して、UEがベアラリソースの修正(allocation or release of resources)の要求を行うことが許可されている(非特許文献13 5.4.5参照)。UEは、MMEを介してP-GWに、ベアラに対する修正要求を行う。P-GWは、EPSベアラQoS関連情報を設定することが可能であるので、UEからベアラに対する修正要求を受信したP-GWは、EPSベアラQoS関連情報、例えば、QCIまたはGBRまたはMBRまたはARPの修正を行う。
MMEは、P-GWからS-GWを介して通知されたEPSベアラQoS関連情報に基づいて、eNBにベアラ設定、すなわち、E-RABセットアップ要求(E-RAB Setup Request)を行う。E-RABレベルのQoSパラメータの設定を行う。したがって、MMEは、P-GWがベアラ設定を修正した場合、eNBに対するベアラ設定を修正する。
このように、あるベアラに対してDCが実行されない場合は、ベアラは一つのeNBを用いて設立されていたため、従来の規格におけるUEからのベアラリソースの修正要求により該ベアラの設定修正が可能であった。
しかし、あるベアラに対してDCが実行される場合は、従来の規格におけるUEからのベアラリソースの修正要求による該ベアラの設定修正は不可能となる。MeNBあるいはSeNBにおけるE-RAB設定の修正は不可能である。
3GPPにおけるDCに関する議論では、DC実行処理において、MeNBは、MMEから要求されたベアラ設定から、SeNBに対して要求するベアラ設定を導出することが議論されている。DC実行処理において、MeNBは、MeNBで提供されるリソースとSeNBで提供されるリソースの合計が、MMEから要求されたE-RABレベルのQoSが保証されるように、あるいはそれ以上となるように、SeNBに対してリソースの要求を行う。
したがって、MeNBは、MMEから要求されたE-RABレベルのQoS情報と異なる値をSeNBに設定する場合が生じる。MeNBは、SeNBに対するDC実行要求メッセージ、例えば、SeNB追加要求メッセージに、SeNBに要求するE-RABレベルのQoS情報を含めて、SeNBに通知する。このように、MeNBが、SeNBに対して、SeNBのベアラ設定を行う。
従来の規格におけるUEからP-GWに対するベアラリソースの修正要求では、DCにおいてMeNBが行うSeNBのベアラ設定に対してUEが修正を要求する仕組みは設けられていない。SeNBのベアラ設定、あるいは、MeNBとSeNBのベアラ振り分け設定の修正要求はできないことになる。
本実施の形態では、このような課題を解決するための方法を開示する。
UE起動によるMeNBおよびSeNBの少なくともいずれか一方のベアラ(以下「DC用ベアラ」という場合がある)の修正を可能とする。UE起動のDC用ベアラ修正処理を設けるとよい。UE起動のDC用ベアラ修正要求のためのメッセージを設けるとよい。
UE起動のDC用ベアラ修正処理について開示する。UEは、MeNBに対してDC用ベアラ修正要求を行う。UEは、MeNBに対してDC用ベアラ修正要求メッセージを通知する。
DC用ベアラ修正要求メッセージに含む情報の例として、以下の(1)~(11)の11個を開示する。
(1)DC用ベアラ修正要求であることを示す情報。
(2)ベアラを特定するための識別子。例えば、EPSベアラ識別子。EPSベアラID。E-RAB識別子。E-RAB ID。
(3)所定のQoSが保てないことを示す情報。
(4)要求するE-RABレベルQoS情報。例えば、QCI、GBR。
(5)SeNBのQoSの改善要求を示す情報。例えば、E-RABレベルのQoSの改善要求を示す情報。
(6)MeNBのQoSの改善要求を示す情報。例えば、E-RABレベルのQoSの改善要求を示す情報。
(7)MeNBとSeNBのパケットフロー比率修正要求を示す情報。例えば、MeNBの比率増大要求を示す情報、SeNBの比率増大要求を示す情報。
(8)SeNB識別子。または、SCGセルの識別子としてもよい。
(9)UEの識別子。
(10)UE AMBR(Aggregate Maximum Bit Rate)。
(11)前記(1)~(10)の組合せ。
UEからDC用ベアラ修正要求メッセージを受信したMeNBは、該メッセージに含まれる情報を用いて、SeNBのベアラ設定、あるいは、MeNBとSeNBのベアラ振り分け設定の修正を行う。この際、MeNBは、MeNBで提供されるリソースとSeNBで提供されるリソースの合計が、MMEから要求されたE-RABレベルのQoSが保証されるように、あるいはそれ以上となるようにするとよい。
MeNBは、SeNBに対して修正したベアラ設定を実行するために、SeNB修正(SeNB modification)処理を起動する。MeNBは、SeNBに要求するE-RABレベルのQoS情報を含めて、SeNBに通知するとよい。
また、MeNBは、SeNBに対するベアラ設定を行わないと判断してもよい。言い換えると、MeNBは、SeNBに対するベアラ設定をリリースすると判断してもよい。これにより、修正の選択肢が増える。MeNBは、SeNBリリース(SeNB Release)処理を起動するとよい。
また、MeNBは、DC用ベアラの修正を行わず、MeNBとSeNBのパケットフロー比率の修正を行うようにしてもよい。これにより、修正の選択肢が増えることになる。例えば、UEからMeNBとSeNBのパケットフロー比率修正要求を示す情報を受信した場合に適用するとよい。MeNBおよびSeNBの少なくともいずれか一方のベアラ設定を修正する処理を行う必要が無く、簡易な処理で済ませることが可能となる。
図22は、実施の形態3の通信システムにおけるUE起動のDC用ベアラ修正処理のシーケンスの一例を示す図である。
ステップST2301において、UE、MeNB、SeNB間で、SeNB追加処理が行われ、UEに対して、MeNBとSeNBを用いたDCが実行される(非特許文献9参照)。DCアーキテクチャ1Aの場合は、UE、MeNB、SeNB、MME、S-GW間で、SeNB追加処理が行われ、UEに対して、MeNBとSeNBを用いたDCが実行される。
この際、前述のように、MeNBは、SeNBのベアラ設定、あるいは、MeNBとSeNBのベアラ振り分け設定を行う。
ステップST2302において、UEは、ベアラの修正を要求するか否かを判断する。該ベアラに対して所望のQoSが得られているか否かを判断してもよい。あるいは、MeNBのベアラに対するQoS、または、SeNBのベアラに対するQoSが得られているか否かを判断してもよい。
ベアラ修正の要求が必要無いと判断したUEは、現在実行されているDCを引き続き行う。
ベアラの修正を要求すると判断したUEは、ステップST2303において、DC用ベアラ修正要求をMeNBに対して通知する。DC用ベアラ修正要求のためのメッセージを設けて通知するとよい。該要求は、RRCメッセージを用いて通知するとよい。UE個別のシグナリングとするとよい。UEは、DC用ベアラ修正要求メッセージに、前述した情報を含ませてもよい。
ステップST2303において、DC用ベアラ修正要求のためのメッセージを受信したMeNBは、ステップST2304において、該メッセージに含まれる情報を用いて、SeNBのリソース設定の修正を行う。SeNBのリソース設定の修正として、ベアラ設定、あるいは、MeNBとSeNBのベアラ振り分け設定の修正を行う。ベアラ設定として、E-RABレベルのQoS情報を設定してもよい。また、この際、MeNBは、MeNBで提供されるリソースとSeNBで提供されるリソースの合計が、MMEから要求されたE-RABレベルのQoSが保証されるように、あるいはそれ以上となるようにする。
ステップST2305において、MeNBは、SeNBに対して修正したベアラ設定を実行するために、SeNB修正処理を起動する。MeNBは、SeNBに要求するE-RABレベルのQoS情報を含めて、SeNBに通知するとよい。これにより、UE、MeNB、SeNB間で、SeNB修正処理が行われる。DCアーキテクチャ1Aの場合は、UE、MeNB、SeNB、MME、S-GW間で、SeNB修正処理が行われる。このSeNB修正処理により、SeNBのリソース設定の修正が行われる。
このようにすることによって、UEがDC用ベアラリソースの修正要求を行うことが可能となる。
DC用ベアラ修正が行われない場合、MeNBは、UEに対して、拒否メッセージを通知する。
DC用ベアラ修正が行われない場合として、例えば、MeNBが判断する場合がある。例えば、MeNBが、UEからDC用ベアラ修正要求メッセージを受信したときに、該メッセージに含まれる情報から示されるUEからの要求を、SeNBのリソース設定の修正では満たせないと判断したような場合である。
このような場合は、MeNBは、UEに対して、DC用ベアラ修正要求に対する拒否メッセージを通知してもよい。
また、MeNBは、MeNB起動のSeNB修正処理において、SeNBから修正拒絶メッセージを受信した場合、UEからのDC用ベアラ修正要求を満たせないと判断して、UEに対して、DC用ベアラ修正要求に対する拒否メッセージを通知してもよい。
このように、UEに対して拒否メッセージを通知することによって、UEは、DC用ベアラ修正が行われないことを認識できる。UEは、他のベアラ修正の手段、例えば、従来のUE起動のEPSベアラ修正要求などを実行するための判断に用いることができる。
拒否メッセージに理由情報を含ませてもよい。理由情報の例として、以下の(1)~(9)の9つを開示する。
(1)UE起動のDC用ベアラ修正をサポートしていない。
(2)MeNBとSeNBの合計のリソース不足。
(3)MeNBのリソース不足。
(4)SeNBのリソース不足。
(5)要求されたEPSレベルのQoSが受理されない。
(6)無効なEPSベアラ識別子。
(7)無効なE-RAB識別子。
(8)サポートしていないQCI値。
(9)SeNB修正要求に対する拒否。この場合、拒否の理由情報を含めてもよい。
拒否メッセージを受信したUEは、所定の期間DC用ベアラ修正要求を行うことを禁止してもよい。
これにより、無駄なDC用ベアラ修正要求メッセージを通知しなくて済むため、シグナリング量の削減を図ることができる。
所定の期間は、予め静的に決められていてもよい。例えば、規格で決めておいてもよい。予め決めておくことで、処理を簡易にすることが可能となる。
あるいは、MeNBが拒否メッセージに含めてUEに通知してもよい。この場合、MeNBがそのときの状況に応じて、柔軟に所定の期間を設定できる。通信システムの柔軟な運用を可能にする。
MeNBは、SeNBからSeNB修正拒絶メッセージを受信した場合、UEからのDC用ベアラ修正要求を満たせないと判断して、UEに対して、DC用ベアラ修正要求に対する拒否メッセージを通知してもよいことを開示した。
他の方法として、MeNBは、SeNBからSeNB修正拒絶メッセージを受信した場合、UEからのDC用ベアラ修正要求を満たせないと判断して、DCに用いるSeNBの変更を起動してもよい。UEに対してDC可能な他のSeNBがある場合、該SeNBへの変更処理を起動してもよい。これにより、UEからのDC用ベアラ修正要求を満たすことが可能となる。
実施の形態3 変形例1.
本変形例では、実施の形態3の課題を解決するための他の方法を開示する。
UEは、MMEを介して、MeNBに対してDC用ベアラ修正要求を行う。UEは、MMEに対してDC用ベアラ修正要求メッセージを通知する。
該DC用ベアラ修正要求メッセージに含む情報として、実施の形態3で開示した情報を適用できる。その他の該情報の例を以下に開示する。
(1)DCを実行しているMeNBの識別子。または、PCellの識別子としてもよい。この情報は、実施の形態3で開示した情報と組合せて適用してもよい。
例えばDCアーキテクチャ3Cでは、MMEは、DCが実行されていることを認識しなくてもよい。したがって、そのような場合、MMEは、UEからDC用ベアラ修正要求メッセージを受信したとしても、それに応じた処理を行うことが不可能となる。
UEからDC用ベアラ修正要求メッセージを受信したMMEが、上記に開示した(1)の情報を用いることで、該DCを実行しているMeNBを認識することが可能となる。
UEからDC用ベアラ修正要求メッセージを受信したMMEは、DCを実行しているMeNBに対して、DC用ベアラ修正要求メッセージを通知する。該DC用ベアラ修正要求メッセージに含む情報として、実施の形態3で開示した情報を適用できる。
DC用ベアラ修正要求メッセージをMMEから受信したMeNBは、該メッセージに含まれる情報を用いて、SeNBのベアラ設定、あるいは、MeNBとSeNBのベアラ振り分け設定の修正等を行う。これらの処理は実施の形態3で開示した方法を適用するとよい。
図23は、実施の形態3の通信システムにおけるUE起動のDC用ベアラ修正処理のシーケンスの他の例を示す図である。図22と同一のステップには同一の番号を付して共通の説明を省略する。
ステップST2302において、ベアラの修正を要求すると判断したUEは、ステップST2401において、DC用ベアラ修正要求をMMEに対して通知する。DC用ベアラ修正要求のためのメッセージを設けて通知するとよい。該要求はNASメッセージとしてもよい。また、該要求は、MeNBを介してMMEに通知してもよい。UEからはMeNB間はRRCメッセージを用いて、MeNBからMME間はS1メッセージを用いて通知してもよい。
UE個別のシグナリングとするとよい。UEは、DC用ベアラ修正要求メッセージに、前述した情報を含ませるとよい。
ステップST2401において、DC用ベアラ修正要求のためのメッセージを受信したMMEは、該メッセージに含まれる情報を用いて、DC用ベアラ修正要求であること、該DCを実行するMeNBなどを認識する。
ステップST2402において、MMEは、DCを実行するMeNBに対して、DC用ベアラ修正要求メッセージを通知する。該要求はS1メッセージとしてもよい。UE個別のシグナリングとするとよい。MMEは、該DC用ベアラ修正要求メッセージに、実施の形態3で開示した情報を含ませるとよい。
これによって、MeNBは、UEからのDC用ベアラ修正要求メッセージを受信する。
ステップST2402において、MeNBがDC用ベアラ修正要求メッセージを受信した後の処理は、実施の形態3と同様なので説明を省略する。
これによって、実施の形態3と同様に、UEがDC用ベアラリソースの修正要求を行うことが可能となる。
UEからMMEへ通知するDC用ベアラ修正要求のためのメッセージに、従来の規格においてUEからMMEに通知するUE起動ベアラリソース修正要求(request bearer resource modification)メッセージを用いてもよい。
この場合、従来の内容と区別するため、該メッセージに、DC用ベアラ修正要求であることを示す情報、該DCを実行しているMeNBの識別子情報を含めるとよい。また、実施の形態3および前述に開示した情報を含めてもよい。
MMEは、これらの情報を用いて、従来の規格の処理であるP-GWにベアラリソース修正要求を行うか、MeNBに対してDC用ベアラ修正要求を行うかを判断するとよい。例えば、DC用ベアラ修正要求の場合は、MeNBに対してDC用ベアラ修正要求を行い、そうでない場合は、P-GWにベアラリソース修正要求を行うとよい。
こうすることによって、新たなUEからMMEへのメッセージを設けなくて済み、メッセージ処理が複雑になることを防ぐことが可能となる。
MeNBがUEに対して拒否メッセージを通知する場合は、MMEを介して通知してもよい。この場合、拒否メッセージに、実施の形態3で開示した情報に加えて、DC用ベアラ修正要求に対する拒否であることを示す情報、DC用ベアラ修正要求を行ったUEの識別子を含めるとよい。MMEは、該UEに対して、拒否メッセージを通知することが可能となる。
実施の形態2で、緊急ベアラに対してDCを適用可能とする方法を開示したが、緊急ベアラの場合は、DC用ベアラ変更は実行されない、としてもよい。
例えば、緊急ベアラに対しては、UEはDC用ベアラ修正要求を行わない、とするとよい。
他の例として、MeNBは、UEから、緊急ベアラに対するDC用ベアラ変更の要求を受信したとしても、拒否するとしてもよい。理由情報として、緊急ベアラのためであることを示す情報を設けて、拒否メッセージに含めてもよい。
実施の形態4.
実施の形態4で解決する課題、およびその解決策について、以下に示す。
現在の3GPPの規格では、UEのロケーション情報に関する機能が存在する。例えば、MDT(Minimization of Drive Test)における即時型MDT(Immediate MDT)の機能である(3GPP TS37.320 V12.0.0(以下「非特許文献15」という場合がある)参照)。即時型MDTは、RRC_ConnectedのUEに適用される。即時型MDTは、RRCのメジャメント処理を用いて行われる。UEは、メジャメント設定(Measurement Configuration)で、メジャメントリポートにロケーション情報(location information)を含めるかどうか設定される。設定された場合、UEはメジャメントリポートにロケーション情報を含めてeNBに通知する。
また、UEは、eNBから、所定の情報(obtain Location)を含む、他の設定用メッセージ(OtherConfig)が通知されると、メジャメントリポート送信時、ロケーション情報に、GNSS(Global Navigation Satellite System)を用いた詳細のロケーション情報(detailed location information)を含めて通知する。
UEは、非常に精度の高いGNSSを用いて詳細のロケーション情報の測定を行う。しかし、GNSSを用いるので、屋内(indoor)環境、例えば、地下街および地下駐車場などでは、測定が不可能となってしまう。したがって、このような場合、他の精度の高いロケーション情報が必要となる。
本実施の形態では、このような課題を解決する方法を開示する。
DC実行中のUEは、メジャメント設定で、メジャメントリポートにロケーション情報を含めるように設定された場合、メジャメントリポートに、ロケーション情報としてSeNBの識別子を含めて、MeNBに通知する。SeNBの識別子として、グローバルなeNB識別子(Global eNB ID)を設定してもよい。あるいは、ロケーション情報としてSCGセルの識別子を含めてMeNBに通知してもよい。セルの識別子としてCGIあるいはPCIを設定してもよい。
SCGセルの具体例として、以下の(1)~(5)の5つを開示する。
(1)DC用に設定された全SCGセル。
(2)SPCell。
(3)最も受信品質(受信電力であってもよい)の良好なSCGセル。
(4)最もパスロスの小さいSCGセル。
(5)最もセルサイズの小さいセル。
このようにすることによって、MeNBはUEの位置を、SCGセルのカバレッジサイズに応じた精度で認識することが可能となる。先に、SCGセルのカバレッジサイズは比較的小さいことを記した。また、屋内(indoor)環境では、特に小さいカバレッジサイズのSCGセルの運用も想定される。したがって、精度の高いロケーション情報が得られることになる。
なお、MeNBに通知するようにしたが、DCにおいて、RRC機能を有するeNBに通知すればよい。
他の方法を開示する。
新たに、SeNBあるいはSCGセルの識別子の報告を示す情報を設ける。eNBは、UEに対して、RRCメッセージで該情報を通知するとよい。他の設定用メッセージ(OtherConfig)に該情報を含めて通知するようにしてもよい。DC実行中のUEは、他の設定用メッセージで、SeNBあるいはSCGセルの識別子の報告を示す情報が通知された場合、メジャメントリポートにSeNBあるいはSCGセルの識別子を含めてMeNBに通知してもよい。新たに該情報を設けることで、eNBは明示的に、SeNBあるいはSCGセルの識別子の報告要求を行うことが可能となる。この方法を用いることで、eNBは、適宜、柔軟にUEのロケーション情報を得ることが可能となる。
あるいは、既存の情報を利用してもよい。DC実行中のUEは、他の設定用メッセージで所定の情報(obtain Location)が通知された場合、メジャメントリポートにSeNBあるいはSCGセルの識別子を含めてMeNBに通知してもよい。
また、既存の情報を利用する場合、UEにおいてGNSSの利用が不可能な場合に、メジャメントリポートにSeNBあるいはSCGセルの識別子を含めてMeNBに通知する、としてもよい。
既存の情報を利用することによって、新たな情報を設ける必要が無くなり、システムとして処理が複雑になることを防ぐことが可能となる。
また、SeNBあるいはSCGセルの識別子を含めてMeNBに通知するために、メジャメントリポートではなく、他のRRCメッセージを用いてもよい。また、該情報を通知するためのRRCメッセージを新設してもよい。メジャメントリポートとは別のメッセージが用いられることによって、eNBは、より柔軟にUEのロケーション情報を得ることが可能となる。
本実施の形態で開示した方法を用いることで、eNBは、UEの詳細なロケーション情報を得ることが可能となる。eNBは、UEが、どのSeNBあるいはどのSCGセルのカバレッジ内に位置するかを認識することが可能となる。
本実施の形態で開示した方法を、無線リンク失敗(Radio Link Failure:RLF)またはハンドオーバ失敗(HandOver Failure:HOF)が生じた場合に適用してもよい。
DC実行中のUEがRLFまたはHOFになった場合、該UEは、RLF報告(RLF Report)メッセージに、ロケーション情報としてSeNBあるいはSCGセルの識別子を含めるとよい。
UEは、eNBからRLF報告(RLF Report)要求を含むメッセージを受信した場合、該ロケーション情報を含むRLF報告(RLF Report)メッセージを、eNBに通知するとよい。
例えば、RLF報告(RLF Report)要求を含むメッセージとして、UE情報要求(UE Information Request)メッセージを用いてもよい。eNBは、UE情報要求(UE Information Request)メッセージに、RLF報告(RLF Report)要求情報を設定して、UEに通知する。該RLF報告要求情報を受信したUEは、UE情報応答(UE Information Response)メッセージに、SeNBあるいはSCGセルの識別子を含むロケーション情報を含めて、eNBに通知する。
このようにすることによって、eNBは、RLFまたはHOFが発生したUEの詳細なロケーション情報を得ることが可能となる。
現在の3GPPの規格では、他にもUEのロケーション情報に関する機能が存在する。例えば、UE positioning(3GPP TS36.305参照)、LPP(LTE Positioning Protocol)(3GPP TS36.355参照)、LCS(Location Service)(3GPP TS23.271参照)などである。これらの機能において、UEのロケーション情報として、SeNBあるいはSCGセルの識別子を用いるようにしてもよい。UEのロケーションとして、DC中のUEが接続するSeNBあるいはSCGセルの識別子を用いて導出する。
SeNBを用いてDCを行っているUEは、該SeNBのカバレッジ内に存在する。さらに、SCGセルまで特定すると、SCGセルを用いてDCを行っているUEは、該SCGセルのカバレッジ内に存在する。したがって、DC中のUEが接続するSeNBあるいはSCGセルの識別子を用いることによって、該UEのロケーションを導出することができる。前述したように、SCGセルのカバレッジサイズは比較的小さい。したがって、精度の高いUEのロケーション情報が得られることになる。
例えば、これらの機能で用いられるE-CID(Enhanced Cell ID)メカニズムがある。これは、UEの位置を得るために、該UEのサービングeNBあるいはセルの情報を用いる。したがって、DC中のUEにおいては、従来は、MeNBあるいはPCellの情報を用いることとなる。
新たな方法として、DC中のUEにおいては、UEの位置を得るために、DC中のUEが接続するSeNBあるいはSCGセルの情報を用いる。SeNBあるいはSCGセルの情報として、eNBの識別子、あるいはセル識別子を用いるとよい。また、SeNBあるいはSCGセルとUEとの間の送信または受信の時間情報を用いてもよい。例えば、UEの送信と受信との時間差(UE Tx-Rx time difference)を用いてもよい。このようにすることによって、従来のMeNBを用いたE-CID方法よりも精度の高いUEのロケーション情報が得られる。
実施の形態4 変形例1.
実施の形態4の変形例1で解決する課題、およびその解決策について、以下に示す。
現在の3GPPの規格では、UEの移動状態に関する機能が存在する。例えば、メジャメント関連パラメータの移動速度依存スケーリング機能(Speed dependent scaling of measurement related parameters)である(3GPP TS36.331 V12.1.0(以下「非特許文献16」という場合がある)参照)。
eNBは、UEに対して、メジャメント設定(Measurement Configuration)で、UEの移動速度を表す移動状態(mobility state)のパラメータを設定する。該パラメータとしては、測定期間、HO回数の閾値、スケーリングファクタがある。該メジャメント設定を受信したUEは、測定期間内のHO回数を検出する。UEは、検出したHO回数とHO回数の閾値とを用いて、自UEの移動状態を導出する。移動状態としては、「high」、「medium」、それ以外(以下「normal」とする)がある。自UEの移動状態を導出したUEは、移動状態に応じたスケーリングファクタを導出し、メジャメント関連パラメータの値に該スケーリングファクタを乗算して設定する。メジャメント関連パラメータとしては、TTT(Time To Trigger)がある。
このように、従来の規格では、UEは、HO回数を検出して自UEの移動状態を導出している。
DC実行中のUEでは、MeNBの変更はHOで行われるが、SeNBの変更はHOで行われない。したがって、DC実行中のUEの移動状態はMeNBを用いて判断される。例えば、DC実行中のUEがMeNB内で移動するような場合には、移動状態が「normal」に設定されてしまう。
しかし、スモールセルは比較的カバレッジが小さい。したがって、UEがSeNB間あるいはSCGセル間を移動する場合は、短期間で移動することになる。このような場合、UEの移動状態は、実質的に「normal」とは言えなくなる。
SCGセルのメジャメントは、MeNBが、DCに用いるSeNBあるいはSCGセルの設定を判断するために用いられる。SCGセルのメジャメント関連パラメータの設定に、MeNBのHO回数で判断したUEの移動状態を用いたのでは不十分となる。SCGセルのメジャメントには、より精度の高い、言い換えると、スモールセルのカバレッジに適したメジャメント関連パラメータの設定が必要となり、それには、より精度の高いUEの移動状態の取得が必要となる。
本変形例では、より精度の高いUEの移動状態を得る方法を開示する。
DC実行中のUEの移動状態の導出に、SeNBの変更回数を用いる。DC実行中のUEは、SeNBの変更回数を検出する。UEは、検出したSeNBの変更回数を記録してもよい。
MeNBは、UEに、DCに用いるSeNBの追加処理を行う際に、SeNBの変更回数のカウントを指示する。RRCシグナリングで通知するとよい。個別シグナリングを用いてもよい。
また、SeNBの変更回数の検出を指示する情報を、RRCメッセージに含めて通知してもよい。例えば、MeNBは、該情報をRRC接続再設定(RRC Connection Reconfiguration)メッセージに含めてUEに通知してもよい。該情報を「Radio Resource Configuration Dedicated」メッセージに含めて通知してもよい。他の例として、MeNBは、該情報を、メジャメント設定に含めてUEに通知してもよい。該情報をメジャメントリポート設定に含めて通知してもよい。メジャメント設定として、DCに用いるSeNBあるいはSCGセルのメジャメント設定としてもよい。
他の例として、MeNBは、SeNBに関するRRC接続再設定(RRC Connection Reconfiguration)を行う際にUEに通知してもよい。例えば、MeNBは、該情報をSeNB追加処理の際にUEに通知してもよい。他の例として、MeNBは、該情報をSeNB変更処理あるいは修正処理の際にUEに通知してもよい。他の例として、MeNBは、SPCellを変更する際にUEに通知してもよい。
これらの通知方法は組合せて用いてもよい。システムとして柔軟な運用が可能となる。
SeNBの変更回数検出の指示を受信したUEは、SeNBの変更回数の検出を行い、該検出結果を用いて、自UEの移動状態を導出する。
UEの移動状態の導出方法の具体例を開示する。MeNBは、SeNBの変更回数の検出の指示とともに、UEの移動速度を表す移動状態のパラメータを設定する。該パラメータは、SeNBに関するパラメータとする。該バラメータとして、測定期間、SeNB変更回数の閾値、スケーリングファクタがある。
該パラメータ設定を受信したUEは、測定期間内のSeNBの変更回数を検出する。UEは、検出したSeNBの変更回数とSeNB変更回数の閾値とを用いて、自UEの移動状態を導出する。移動状態としては、「high」、「medium」、それ以外(以下「normal」とする)とする。
このようにすることによって、UEは、自UEの移動状態を導出することができる。
自UEの移動状態を導出したUEは、移動状態に応じたスケーリングファクタを導出し、メジャメント関連パラメータに該スケーリングファクタを乗算する。メジャメント関連パラメータとしては、例えば、TTTがある。
UEが検出したSeNB変更回数を用いて導出されたスケーリングファクタが乗算されたメジャメント関連パラメータは、SeNBあるいはSCGセルのメジャメントに用いられる。
このようにすることによって、UEは、SeNBの変更回数を検出することが可能となり、該検出結果を用いることによって、より精度の高い自UEの移動状態を導出することができる。
SCGセルのメジャメントに該移動状態を用いることによって、UEは、より精度の高い、言い換えると、スモールセルのカバレッジに適したメジャメント関連パラメータの設定が可能となる。
本変形例で開示した方法を用いることによって、UEは、より精度の高い、言い換えると、スモールセルのカバレッジに適したメジャメント関連パラメータの設定が可能となる。MeNBは、UEから、より精度の高いSCGセルのメジャメント結果を得られることになる。したがって、MeNBは、DCに用いるSeNBあるいはSCGセルの設定を、UEの移動状態に応じて、より正確に判断することが可能となる。
これによって、UEのスループットの向上を図ることが可能となり、システムとしての通信容量の向上を図ることも可能となる。
前述の方法では、MeNBは、SeNBの変更回数の検出を指示する情報を、RRCメッセージに含めてUEに通知することによって、UEが、SeNBの変更回数の検出を行い、SCGセルのメジャメントに該検出結果を用いるようにした。
他の方法として、MeNBは、UEに、SeNBに関するUEの移動速度を表す移動状態のパラメータの設定を通知することを、SeNBの変更回数の検出の指示としてもよい。UEは、SeNBに関するUEの移動速度を表す移動状態のパラメータの設定を受信した場合、SeNBの変更回数の検出を行い、SCGセルのメジャメントに該検出結果を用いる。
このようにすることによって、SeNBの変更回数の検出を指示する情報およびそのためのシグナリングを削減することが可能となる。
DC実行中のUEの移動状態の導出に、SeNBの変更回数を用いることを開示したが、SPCellの変更回数を用いてもよい。DC実行中のUEは、SPCellの変更回数であってもよい。UEは、検出したSPCellの変更回数を記録してもよい。これによって、SeNB内でのSPcellの変更を考慮することが可能となり、さらに詳細なUEの移動状態を導出することができる。
また、SCGセルの変更回数を用いてもよい。DC実行中のUEは、SCGセルの変更回数であってもよい。UEは、検出したSCGセルの変更回数を記録してもよい。SeNBがRRHなどを用いてCAしているような場合も、SCGセルの変更回数を記録することによって、さらに詳細なUEの移動状態を導出することが可能となる。
SeNBの変更回数を用いるか、SPCellの変更回数を用いるか、SCGセルの変更回数を用いるか、適宜選択可能としてもよい。MeNBが、UEに対して、どの変更回数を用いるかを指示するとよい。MeNBは、どの変更回数を用いるかの情報を変更回数の検出を指示する情報とともに、UEに対して通知してもよい。
図24は、実施の形態4の変形例1の通信システムにおけるSCGセルのメジャメント処理のシーケンスの一例を示す図である。
ステップST2501において、MeNBは、UEに対してDCを実行するために、SeNB(ここではS-SeNB)に対して、SeNB追加要求メッセージを通知する。
ステップST2501のSeNB追加要求メッセージを受信し、自SeNBのリソースをDCに使用可能と判断したSeNBは、ステップST2502において、SeNB追加要求受理メッセージを通知する。
SeNB追加要求受理メッセージを受信したMeNBは、ステップST2503において、UEに対してDCを実行させるための設定を通知する。この通知には、RRC接続再設定(RRC Connection Reconfiguration)メッセージを用いる。MeNBは、UEに対してSeNB変更回数を検出させるために、該メッセージに、SeNBに関するUEの移動速度を表す移動状態のパラメータの設定を含める。
ステップST2503において該メッセージを受信したUEは、DC実行のためのリソース設定を行う。
ステップST2504において、UEは、MeNBに対して、MeNBにRRC接続再設定完了メッセージを通知する。
ステップST2505において、MeNBは、SeNBに対して、SeNB再設定(SeNB Reconfiguration)メッセージを通知する。
これに従い、ステップST2506において、UE、MeNB、SeNB間でDC実行処理が行われる。
ステップST2503において、RRC接続再設定メッセージを受信し、該メッセージ中にSeNBに関するUEの移動速度を表す移動状態のパラメータの設定が含まれることを認識したUEは、SeNB変更回数検出指示とみなし、ステップST2513において、該パラメータを用いてSCGセルのメジャメント処理を行う。
具体的には、ステップST2507において、UEは、測定期間内のSeNBの変更回数を検出する。
ステップST2508において、UEは、検出したSeNBの変更回数とSeNB変更回数の閾値とを用いて、自UEの移動状態を導出する。移動状態は、「high」、「medium」、それ以外(以下「normal」とする)とする。
また、ステップST2508において、UEは、導出した自UEの移動状態に応じたスケーリングファクタ(SF)を導出する。
ステップST2509において、UEは、メジャメント関連パラメータ、例えばTTTに、導出したスケーリングファクタを乗算する。この値を、SCGセルのメジャメント用のTTTに設定し、SCGセルのメジャメントを行う。
ステップST2510において、UEは、メジャメント結果をMeNBに通知する。該メジャメント結果には、SCGセルのメジャメント結果も含む。
ステップST2510において、UEからSCGセルを含めたメジャメント結果を受信したMeNBは、ステップST2511において、該メジャメント結果を用いて、SeNBの変更を決定する。SeNBの変更を決定したMeNBは、SeNB変更処理を起動し、それに従って、UE、MeNB、S-SeNB、T-SeNB間でSeNB変更処理が行われる。S-SeNBは、変更前SeNBでソースSeNB(Source SeNB)である。T-SeNBは、変更後SeNBでターゲットSeNB(Target SeNB)である。
引き続き、UEは、ステップST2513において、SeNBに関するUEの移動速度を表す移動状態のパラメータを用いてSCGセルのメジャメント処理を行う。
ステップST2511においてSeNBの変更が行われたので、測定期間内のSeNBの変更回数を一つインクリメントする。UEは、検出したSeNBの変更回数とSeNB変更回数の閾値とを用いて、新たな自UEの移動状態を導出する。新たに導出した自UEの移動状態からメジャメント関連パラメータを導出し、SCGセルのメジャメントを行う。
ステップST2512において、UEは、メジャメント結果をMeNBに通知する。該メジャメント結果には、SCGセルのメジャメント結果も含む。
このように、UEがSeNB変更回数を検出することによって、より精度の高い自UEの移動状態を導出することができる。
また、SCGセルのメジャメントに該移動状態を用いることによって、UEは、より精度の高い、言い換えると、スモールセルのカバレッジに適したメジャメント関連パラメータの設定が可能となる。
したがって、MeNBは、UEから、より精度の高いSCGセルのメジャメント結果を得られることになり、MeNBは、DCに用いるSeNBあるいはSCGセルの設定を、UEの移動状態に応じて、より正確に判断することが可能となる。
本変形例で開示した方法は、従来のeNB用の移動状態導出処理とは個別に行ってもよい。従来のeNB用、すなわち、HO回数の検出結果から移動状態を導出する処理と、本変形例で開示した方法、すなわち、SeNB変更回数の検出結果から移動状態を導出する処理とを個別に行ってもよい。並行して行ってもよい。
本変形例で開示した移動状態導出方法およびメジャメント方法は、SCGセルのメジャメント専用に用いるようにしてもよい。セルのカバレッジ範囲に応じた適正なメジャメントが可能となる。
なお、MeNBのメジャメントには、従来の移動状態導出方法およびメジャメント方法を用いるとよい。
本変形例で開示した移動状態導出方法およびメジャメント方法は、SCGセルの周波数レイヤのメジャメントに用いるようにしてもよい。また、スモールセルが運用される周波数レイヤのメジャメントに用いるようにしてもよい。
SCGセルに限らず、スモールセルのカバレッジ範囲に応じた適正なメジャメントが可能となる。
ソースMeNBは、ターゲットMeNB(eNB)に、SeNBに関するUEの移動速度を表す移動状態のパラメータの設定を通知してもよい。例えば、MeNBの変更、あるいは、eNBのHOの場合、これによって、ターゲットMeNB(eNB)は、HO対象のUEのソースMeNBで設定されていたSeNBに関するUEの移動速度を表す移動状態のパラメータ設定を認識することが可能となり、自MeNB(eNB)におけるSeNBに関するUEの移動速度を表す移動状態のパラメータ設定に資することができる。
また、ターゲットMeNB(eNB)においても、新たなUEの移動速度を表す移動状態のパラメータ設定が行われるまでは、引き続きソースMeNBと同じUEの移動速度を表す移動状態のパラメータ設定が有効となるようにしてもよい。UEは、ターゲットMeNB(eNB)から、新たなUEの移動速度を表す移動状態のパラメータ設定が通知されるまで、引き続きソースMeNBと同じUEの移動速度を表す移動状態のパラメータ設定を用いて、SeNB変更回数の検出および記録を行う。このようにすることによって、長期的なUEの移動状態の検出が可能となる。
逆に、UEは、MeNB(eNB)のHOで、SeNB変更回数の検出および記録をリセットしてもよい。SeNB変更回数の検出および記録のリセットに従い、SeNB変更回数を用いたSCGセルのメジャメントもリセットされるようにしてもよい。UEは、変更先MeNB(eNB)から通知されるメジャメント設定の受信に従って、再度実行するとよい。これによって、メジャメント設定をソースMeNBからターゲットMeNBに通知する必要が無くなる。したがって、HO時のシグナリング量の増大を防ぐことができる。
MeNB(eNB)のHOについて記載したが、MeNBの変更、あるいはPCellの変更など、UEにメジャメント設定を通知するサービングセルが変更される場合にも適用できる。
SeNB変更回数の検出および記録は、SeNBリリース処理が行われた場合にリセットされるようにしてもよい。UEは、SeNBリリース処理を通知された場合に、SeNB変更回数の検出および記録をリセットしてもよい。UEは、DCの実行が終了した場合に、SeNB変更回数の検出および記録をリセットしてもよい。
SeNB変更回数の検出および記録のリセットに従い、SeNB変更回数を用いたSCGセルのメジャメントもリセットされるようにしてもよい。
本変形例で開示した方法は、TTTへの適用だけでなく他のメジャメント関連パラメータに用いてもよい。より精度の高い移動状態を必要とする場合に使用可能である。
実施の形態4 変形例2.
実施の形態4の変形例2で解決する課題、およびその解決策について、以下に示す。
現在の3GPPの規格では、UEの移動状態に関する機能が存在する。例えば、移動履歴情報(Mobility History Information)である(非特許文献16参照)。
移動履歴情報(Mobility History Information)は、RRC_IdleとRRC_ConnectedのUEに適用される。UEは、RRC_Idle時のサービングセルの変更、あるいは、RRC_Connected時のPCellの変更に従って、該セル(変更前のセル)のセル識別子と、そのセルでの滞留時間とを記録する。サービス外から、あるいは、他のRATから最初にE-UTRAセルに入るときは、E-UTRA外の滞留時間のみ記録する。
UEは、eNBからのUE情報要求(UE Information Request)に応じて、記録したPCellあるいはサービングセルのセル識別子と滞留時間とをUE情報応答(UE Information Response)メッセージに含めて、eNBに通知する。これによって、eNBは、UEの移動状態を取得することができる。
このように、従来の規格では、RRC_Connected時の対象とするセルをPCellとしている。
DCに用いられるSCGセルは、PCellではないので、移動履歴情報(Mobility History Information)の対象とならない。DC実行中のUEの移動状態は、MeNBのPCellの変更によって決定される。
したがって、実施の形態4の変形例1で示したのと同様に、従来の規格では、eNBは、精度の高い、スモールセルのカバレッジに適したUEの移動状態を取得できないことになる。
本変形例では、eNBが、より精度の高いUEの移動状態を得る方法を開示する。
UEは、DC実行中のSPCellのセル識別子と該セルでの滞留時間とを記録する。DC実行中のUEは、SPCellの変更に従って、該セル(変更前のセル)のセル識別子と、該セルでの滞留時間とを記録する。また、該セルのキャリア周波数を記録してもよい。セル識別子としては、CGIあるいはPCIとするとよい。
UEは、従来のPCellの情報を記録したリストと、SPCellの情報を記録したリストとを個別に設けてもよい。UEは、PCellの情報とSPCellの情報とを各々のリストに記録する。
eNBが、UEが記録したリストを取得する方法を開示する。
MeNBは、DC実行中のUEに、SPCellの情報を記録したリストを要求する。新たに該要求のためのRRCメッセージを設けて通知してもよい。あるいは既存のRRCメッセージにSPCellの情報を記録したリストの要求であることを示す情報を含めて通知してもよい。個別シグナリングで通知してもよい。
例えば、MeNBは、該情報をRRC接続再設定(RRC Connection Reconfiguration)メッセージに含めてUEに通知してもよい。該情報を「Radio Resource Configuration Dedicated」メッセージに含めて通知してもよい。
あるいは、MeNBは、SeNBに関するRRC接続再設定(RRC Connection Reconfiguration)を行う際にUEに通知してもよい。例えば、MeNBは、該情報をSeNB追加処理の際にUEに通知してもよい。他の例として、MeNBは、該情報をSeNB変更処理あるいは修正処理の際にUEに通知してもよい。他の例として、MeNBは、SPCellを変更する際にUEに通知してもよい。
これらの通知方法は組み合わせて用いてもよい。システムとして柔軟な運用が可能となる。他の例として、従来と同じメッセージであるUE情報要求(UE Information Request)メッセージに該情報を含めてもよい。PCellの情報を記録したリストとSPCellの情報を記録したリストとのどちらを要求するかを示す情報を該メッセージに含めてもよい。
UEは、MeNBから、SPCellの情報を記録したリストの要求を受信した場合、SPCellの情報を記録したリストを、MeNBに対して通知する。新たに該要求のためのRRCメッセージを設けて通知してもよい。あるいは既存のRRCメッセージにSPCellの情報を記録したリストの要求であることを示す情報を含めて通知してもよい。個別シグナリングで通知してもよい。
例えば、SPCellの情報を記録したリストの要求に、従来と同じメッセージであるUE情報要求(UE Information Request)メッセージを用いる場合は、UE情報応答(UE Information Response)メッセージを用いて通知するとよい。UEは、MeNBに、SPCellの情報を記録したリストをUE情報応答(UE Information Response)メッセージに含めて通知する。
MeNBは、UEに対して、PCellの情報を記録したリスト要求と、SPCellの情報を記録したリスト要求とを個別に行ってもよい。例えば、どちらもUE情報要求(UE Information Request)メッセージを用いてもよい。該メッセージに、前述の、PCellの情報を記録したリストとSPCellの情報を記録したリストとのどちらを要求するかを示す情報を含めておくことによって、UEは、どちらの情報をMeNBに対して通知するかを認識することが可能となる。UEは、該情報に従い、対応するリストをMeNBに対して報告するとよい。
MeNBが一つのメッセージで、SPCellの情報を記録したリストとPCellの情報を記録したリストとの両方を要求してもよい。MeNBは、両方を要求することを示す情報をUEに対して通知するとよい。該メッセージを受信したUEは、SPCellの情報を記録したリストと、PCellの情報を記録したリストとの両方を、MeNBに対して通知する。一つのメッセージを用いて通知してもよい。
また、一つのメッセージが、常に、両方を要求することを示すメッセージとしてもよい。予め規格などで静的に決めておいてもよい。MeNBが、該メッセージをUEに通知した場合、UEは、SPCellの情報を記録したリストと、PCellの情報を記録したリストとの両方を、MeNBに対して通知する。一つのメッセージを用いて通知してもよい。
SPCellの情報を記録したリストの作成方法を開示する。
UEは、DC実行中のSPCellの変更に従って、該セル(変更前のセル)のセルIDなどと、該セルでの滞留時間とを記録する。併せて、該セルのキャリア周波数を記録してもよい。また、該セルのセルサイズを併せて記録してもよい。
リストに記録する最大のセル数を決めておいてもよい。例えば、最大nセルとし、UEは、それを超えた場合、古いものから破棄する。UEの記録容量が膨大になることを防ぐことができる。最大のセル数nは、予め規格などで静的に決めておいてもよい。あるいは、MeNBから通知してもよい。
UEは、SeNBリリース処理が実行された場合に、SPcellの情報を記録したリストを廃棄するようにしてもよい。UEは、SeNB追加処理が実行された場合に、SPcellの情報を記録したリストを新たに作成するようにしてもよい。SeNBリリース処理が実行された場合として、UEが、SeNB用のリソースをリリースあるいはリセットした場合としてもよい。
UEは、SeNBリリース処理が実行された場合、SPCellの情報を記録したリストを、所定の期間保持するようにしてもよい。UEは、SeNBリリース処理実行後、所定の期間満了前に新たにSeNB追加処理が実行された場合は、既に作成されていたリストに記録する。UEは、SeNBリリース処理実行後、新たにSeNB追加処理が実行されずに所定の期間満了した場合、リストを破棄する。
このようにすることによって、SeNBのカバレッジが連続していないような状況で、DCが断続的に実行されるような場合も、SPCell情報を記録したリストを無駄に破棄することはなくなる。所定の期間は、予め規格などで静的に決められてもよい。あるいは、所定の期間は、MeNBからUEに通知してもよい。通知方法として、RRCメッセージを用いて通知してもよい。個別シグナリングを用いて通知してもよい。あるいは、MeNBは傘下のUEに報知してもよい。SIBに該所定の期間を含めて通知してもよい。
また、UEは、RRC_CONNECTED中の、DCが実行されていない時間を記録しておいてもよい。例えば、RRC_CONNECTEDに移行してからSeNB追加処理が実行されるまでの時間、SeNBリリース処理が実行されてからSeNB追加処理が実行されるまでの時間、SeNBリリース処理が実行されてから、RRC_CONNECTED状態を終了するまでの時間を記録しておいてもよい。各々、別々に記録するとよい。DCが実行されていない時間の発生に従い記録するとよい。DCが実行されていない時間については、SPCellのセル識別子とキャリア周波数情報を記録せず、滞留時間として、記録しておくとよい。
このようにすることによって、UEは、RRC_CONNECTED状態におけるSPCell変更の状況を、SPCellの使用が無い場合も含めて記録することができる。MeNBは、UEから該情報を取得することができ、より詳細なUEの移動状態を認識することが可能となる。
また、UEは、MeNBのHOを行った場合に、SPCellの情報を記録したリストを廃棄するようにしてもよい。
UEは、MeNBのHOを行った場合、SPCellの情報を記録したリストを、所定の期間保持するようにしてもよい。UEは、HO処理実行後、所定の期間満了前に新たにSeNB追加処理あるいはSPCell変更処理が実行された場合は、既に作成されていたリストに記録する。UEは、HO処理実行後、新たにSeNB追加処理あるいはSPCell変更処理が実行されずに所定の期間満了した場合、リストを破棄する。
また、UEは、MeNBのHOを行った場合、HO先MeNB(eNB)に、SPCellの情報を記録したリストを通知した後、該リストを廃棄するようにしてもよい。
UEは、HO処理実行後、HO先MeNB(eNB)からの要求に応じて、SPCellの情報を記録したリストを通知してもよい。
MeNBのHOの場合、HO元MeNBは、HO先MeNB(eNB)に、UEから取得したSPCellの情報を記録したリストを通知してもよい。また、該リストにセルサイズが含まれていない場合、MeNBが該リストにセルサイズを加えて通知してもよい。MeNBがSPCellのセルサイズを認識している場合に有効である。X2シグナリングで通知してもよい。あるいは、MMEを介して、S1シグナリングで通知してもよい。
この方法を行うことで、HO先MeNB(eNB)は該情報を引き続き利用可能となる。
また、HO元MeNBは、HO先MeNB(eNB)に、UEから取得したSPCellの情報を記録したリストを通知してもよい。UEから取得したSPCellの情報を記録したリストとともに通知してもよい。同じメッセージ含めて通知してもよい。
前述した方法では、UEは、PCellの情報とSPCellの情報を各々のリストに記録した。他の方法として、一つのリストに、PCellの情報とSPCellの情報とを記録してもよい。あるいは、従来のPCellの情報のリストにSPcellの情報を含めてもよい。
この場合、SPCellであることを示すパラメータを設け、SPCellに対応付けて記録してリストを作成するとよい。
該リストに既にセルサイズが含まれている場合は、該SPCellであることを示すパラメータは記録しなくてもよい。
このようにすることによって、UEは、リストを一つとすることが可能となり、記憶容量の削減、リスト作成処理の簡易化を図ることができる。また、MeNBとUEとの間のリストの要求と通知メッセージに含む情報あるいはメッセージを削減することが可能となる。これによって、シグナリング負荷の削減が可能となる。
前述の方法では、UEは、SPCellの情報を記録しリストを作成した。他の方法として、SeNBの情報を記録してリストを作成してもよい。DC実行中のUEは、SeNBの変更に従って、該SeNB(変更前のSeNB)のeNB識別子と、該eNBでの滞留時間を記録する。また、該eNBで使用されるキャリア周波数を記録してもよい。SPCellの情報に比べて粗い情報となるが、記録容量の削減、シグナリング負荷の削減を図ることができる。
また、UEは、SCGセルの情報を記録してリストを作成してもよい。DC実行中のUEは、SCGセルの変更に従って、該SCGセル(変更前のSCGセル)のセル識別子と、該セルでの滞留時間を記録する。また、該セルのキャリア周波数を記録してもよい。また、該セルのセルサイズを併せて記録してもよい。MeNBは、SCGセルの情報を記録したリストを取得することによって、さらに詳細なUEの移動状態を導出することが可能となる。
SPCellの情報を記録したリストとするか、SeNBの情報を記録したリストとするか、SCGセルの情報を記録したリストとするか、選択可能としてもよい。予め規格などで静的に決められてもよい。あるいは、MeNBが、UEに対して、どのリストを作成するか指示してもよい。MeNBは、どのリストを作成するかの情報をUEに通知するとよい。例えば、UEがRRC_Connected状態に移行する際に通知するとよい。MeNBは、RRCメッセージで通知するとよい。個別シグナリングとするとよい。
実施の形態4 変形例3.
実施の形態4の変形例3で解決する課題、およびその解決策について、以下に示す。
現在の3GPPの規格では、UEの移動状態に関する機能が存在する。例えば、UE履歴情報(UE History Information)である(非特許文献1参照)。
UE履歴情報(UE History Information)は、UEをサーブするeNBが、アクティブ状態のUEの「Last Visited Cell List」を作成する。
UEがHOを実行する際、HO元eNBは、該UEの「Last Visited Cell List」にPCellを追加して、該リストをHO先eNBにS1あるいはX2で通知する。HO先eNBは、次のHO先eNBに対して同様の処理を行い、該リストを通知する。ネットワーク側が、UEのHO履歴情報を作成して維持する。「Last Visited Cell List」に記録する情報としては、セル識別子、例えばCGI、セルサイズ、セルの滞留時間、HO理由がある。
このように、従来の規格では、eNBは、HOの履歴情報をリストに記録する。
DCに用いられるSeNBの変更はHOで行われない。したがって、DC実行中のUEがいくらSeNBの変更を繰り返しても、該リストには記録されない。
したがって、従来の規格では、実施の形態4の変形例2で示したのと同様に、eNBは、精度の高い、スモールセルのカバレッジに適したUEの移動状態を取得できないことになる。
本変形例では、eNBが、より精度の高いUEの移動状態を得る他の方法を開示する。
MeNBは、DC実行中のUEが接続したSPCellのリストを作成する。以下の説明では、DC実行中のUEが接続したSPCellのリストを、「SPCell変更履歴リスト」という場合がある。
UEに対して、DCに用いるSPCellが変更された際、MeNBは、変更前SPCellをSPCell変更履歴リストに追加する。あるいは、SeNBリリース処理が実行された際、MeNBは、リリース前にUEに接続していたSPCellを該UEのSPCell変更履歴リストに追加する。
SPCell変更履歴リストに記録する情報として、セル識別子、例えばCGI、セルサイズ、セルの滞留時間、SPCell変更理由あるいはSeNBリリース理由がある。
このようにすることによって、MeNBは、DC実行中のUEのSPCellの履歴情報をリストに記録することができる。したがって、MeNBは、スモールセルのカバレッジに適したUEの移動状態を取得できる。
MeNBは、従来のHO履歴情報を記録するリストと、SPCell変更履歴情報を記録するリストとを個別に設けてもよい。MeNBは、HO履歴情報とSPCell変更履歴情報とを各々のリストに記録する。
DC実行中のUEに対してSeNBリリース処理が実行された場合に、MeNBは、該UEのSPcell変更履歴情報を記録したリストを廃棄するようにしてもよい。UEに対するSeNB追加処理が実行された場合に、MeNBは、該UEのSPcellの情報を記録したリストを新たに作成するようにしてもよい。SeNBリリース処理が実行された場合として、MeNBがUEに対して、SeNBのリソースリリースを指示した場合としてもよい。
DC実行中のUEに対してSeNBリリース処理が実行された場合、MeNBは、該UEのSPCellの情報を記録したリストを、所定の期間保持するようにしてもよい。DC実行中のUEに対するSeNBリリース処理実行後、所定の期間満了前に新たにSeNB追加処理が実行された場合は、MeNBは、既に作成されていたリストに記録する。DC実行中のUEに対するSeNBリリース処理実行後、新たにSeNB追加処理が実行されずに所定の期間満了した場合、MeNBはリストを破棄する。
このようにすることによって、SeNBのカバレッジが連続していないような状況で、DCが断続的に実行されるような場合も、SPCellへ高履歴情報を記録したリストを無駄に破棄することはなくなる。所定の期間は、予め規格などで静的に決められてもよい。準静的、あるいは動的に決められてもよい。MMEあるいはO&M(Operation and Maintenance)が決定し、MeNBに対して通知してもよい。
また、MeNBは、RRC_Connected中のUEに対して、DCを実行していない時間をリストに記録しておいてもよい。例えば、UEとMeNBとの間でRRC接続設立処理が完了してからSeNB追加処理が実行されるまでの時間、SeNBリリース処理が実行されてからSeNB追加処理が実行されるまでの時間、SeNBリリース処理が実行されてから、RRC_CONNECTED状態を終了するまでの時間を記録しておいてもよい。各々、別々に記録するとよい。DCが実行されていない時間の発生に従い記録するとよい。DCが実行されていない時間については、SPCellのセル識別子とキャリア周波数情報とを記録せず、滞留時間のみを記録しておくとよい。
このようにすることによって、MeNBは、RRC_CONNECTED状態におけるSPCell変更の状況を、SPCellの使用が無い場合も含めて記録できる。MeNBは、より詳細なUEの移動状態を認識することが可能となる。
また、MeNBは、HOを行った場合に、該HO対象UEのSPCell変更履歴情報を記録したリストを廃棄するようにしてもよい。
MeNBは、HOを行った場合、該HO対象UEのSPCell変更履歴情報を記録したリストを、所定の期間保持するようにしてもよい。該HO対象UEがHO元MeNBに切り戻った場合などに、該リストを利用できる。
MeNBのHOの場合、HO元MeNBは、HO先MeNB(eNB)に、SPCell変更履歴情報を記録したリストを通知してもよい。X2シグナリングで通知してもよい。あるいは、MMEを介して、S1シグナリングで通知してもよい。この方法を行うことで、HO先MeNB(eNB)は該情報を引き続き利用可能となる。
また、HO元MeNBは、HO先MeNB(eNB)に、PCellのHO履歴情報を記録したリストを通知してもよい。SPCell変更履歴情報を記録したリストとともに通知してもよい。同じメッセージに含めて通知してもよい。
HO先MeNB(eNB)は、HO元MeNB(eNB)から、該HO対象UEのSPCell変更履歴情報を記録したリストを受信した場合は、該HO対象UEのSPCell変更履歴情報を記録したリストを、所定の期間保持するようにしてもよい。
HO処理実行後、所定の期間満了前に、HO先MeNB(eNB)が新たにSeNB追加処理あるいはSPCell変更処理を実行された場合は、既に作成されていたリストに記録する。HO先MeNB(eNB)は、新たにSeNB追加処理あるいはSPCell変更処理が実行されずに所定の期間満了した場合、リストを破棄する。
前述の方法では、MeNBは、PCellのHO履歴情報とSPCell変更履歴情報を各々のリストに記録した。他の方法として、一つのリストに、PCellのHO履歴情報とSPCell変更履歴情報とを記録してもよい。あるいは、従来のPCellのHO履歴情報のリストにSPcell変更履歴情報を含めてもよい。
この場合、SPCellであることを示すパラメータを設け、SPCellに対応付けて記録してリストを作成するとよい。
該リストに既にセルサイズが含まれている場合は、該SPCellであることを示すパラメータは記録しなくてもよい。
このようにすることによって、MeNBは、リストを一つとすることが可能となり、記憶容量の削減、リスト作成処理の簡易化を図ることができる。
前述の方法では、MeNBは、SPCellの変更履歴情報を記録してリストを作成した。他の方法として、SeNBの変更履歴情報を記録してリストを作成してもよい。MeNBは、DC実行中のUEに対して、SeNBの変更に従って、該SeNB(変更前のSeNB)のeNB識別子と、該eNBでの滞留時間を記録する。また、該eNBで使用されるキャリア周波数を記録してもよい。また、変更理由を記録してもよい。SPCellの情報に比べて粗い情報となるが、記録容量の削減を図ることができる。
また、MeNBは、SCGセルの変更履歴情報を記録してリストを作成してもよい。MeNBは、DC実行中のUEに対して、SCGセルの変更に従って、該SCGセル(変更前のSCGセル)のセル識別子と、該セルでの滞留時間を記録する。また、該セルのキャリア周波数を記録してもよい。また、該セルのセルサイズを併せて記録してもよい。また、変更理由を記録してもよい。MeNBは、SCGセルの変更履歴情報を記録したリストを取得することによって、さらに詳細なUEの移動状態を導出することが可能となる。
SPCellの変更履歴情報を記録したリストとするか、SeNBの変更履歴情報を記録したリストとするか、SCGセルの変更履歴情報を記録したリストとするか、選択可能としてもよい。予め規格などで静的に決められてもよい。準静的、あるいは動的に決められてもよい。MMEあるいはO&Mが決定し、MeNBに対して通知してもよい。
実施の形態5.
本実施の形態では、非特許文献7に記載される多地点協調送受信(Coordinated Multipoint transmission and reception:CoMP)の開始時、CoMP対象であるUEが送信するサウンディング参照信号(Sounding Reference Signal:SRS)を用いて、リソース(周波数、時間、送信電力)の無駄および不足が少ない通信ができる方法について開示する。
ここで、「サウンディング参照信号」とは、例えば非特許文献14に記載されるような、送信データがないときにも常時、あるいは、間欠的に送信される既知系列の信号のことを指す。
まず、上りについて説明する。図25は、3GPPで検討されているUL CoMPの概念を示す図である。図25では、eNB#1を参照符号「5101」で示し、eNB#2を参照符号「5103」で示し、eNB#1の通信エリア、すなわちカバレッジを参照符号「5102」で示し、eNB#2の通信エリア、すなわちカバレッジを参照符号「5104」で示す。また、セントラルエンティティ(Central Entity)あるいは移動管理エンティティ(Mobile Management Entity:MME)を参照符号「5106」で示す。
eNB#1 5101およびeNB#2 5103は、UL CoMP、すなわち上り多地点間協調受信を行う場合、セントラルエンティティ(Central Entity)あるいは移動管理エンティティ(Mobile Management Entity:MME)5106経由でeNB間の協調動作を行う。例えば、多地点間協調スケジューリングを行う協調スケジューリング(Coordinated Scheduling:CS)が検討されており、各eNBの通信状況に合わせて、セルエッジのUE5105との通信データ5107,5110、送信電力などをスケジュールすることによって、スループットの向上、システムスループットの増大を図ることができる。セントラルエンティティは、多地点間協調を行う機能部であり、MME経由の場合はeNB間の多地点間協調を行う信号のやり取りを行い、実際の協調制御はeNB同士で行う。
CS時のUL CoMPでは、eNB#1 5101の傘下にいる移動端末(UE)5105は、eNB#1 5101に送信したいデータ5107が発生すると、eNB#1 5101に、スケジューリング要求(Scheduling Request:SR)を送信する。eNB#1 5101は,他のUEの通信状況などのリソースの空き状況を確認して、送信可能であれば、許可範囲を表すグラント(Grant)信号を送信する。
UE5105は、Grant信号を受信すると、Grant信号で許可された範囲内の送信したいデータ5107を送信する。
eNB#1 5101は、UE5105がセルの境界、あるいは、他セルの近傍にいることを検出すると、RRC(Radio Resource Control)を用いて、UE5105にSRS送信指示を通知する。
UE5105がメジャメント報告(Measurement Report)メッセージで報告してきた自セルの報告値、具体的にはRSRP(Reference Signal Received Power)、あるいは、RSRQ(Reference Signal Received Quality)、あるいは、両者が特定の閾値以下かどうかで、セルの境界にいることを判定してもよい。
また、UE5105がメジャメント報告(Measurement Report)メッセージで報告してきた他セルの報告値、具体的にはRSRP、あるいはRSRQ、あるいは両者が特定の閾値以上かどうかで、他セルの近傍にいることを判定してもよい。
非特許文献14(5.5.1.5参照)では、SRS信号を規定する擬似乱数を発生させるためのパラメータnRS
IDはNcell
IDとなっており、セル毎の値(セルID)になっているが、本発明では、SRS送信指示は、少なくとも1つのUE個別のパラメータを指定する。すなわち、UE5105は、セル独自のSRS信号ではなく、UE独自のSRS信号を送信する。
SRS信号は、常時、UE独自の信号としてもよいし、セルの境界、あるいは、他セルの近傍にいることを検出したときに、セル個別のSRS信号からUE独自の信号に切り替えてもよい。
UEがデータを送信する方法としては、以下の2通りの方法がある。1つは、UEがeNB#1に送信するときと、eNB#2に送信するときとで、同じ構成(同じPUSCH config、PUCCH config)とする方法である。もう1つは、UEがeNB#1に送信するときと、eNB#2に送信するときとで、異なる構成とする方法である。
例えば図25に示す例において、UE5105が、送信するeNB5101,5103毎に異なる構成で送信する場合、eNB#2 5103は、eNB#1 5101に、eNB#2 5103で使用する「PUCCH config」、「PUSCH config」などのCoMP設定用パラメータをX2インタフェース5115経由で通知する。セントラルエンティティあるいはMME5106経由でもよい。eNB#1 5101は、UE5105に、これらのconfig情報を通知する。
これによって、UE5101は、eNB#2 5103に送信するときには、eNB#2 5103が受信できる構成でデータを送信することができる。この方法は、eNBのバックホールで大きな遅延時間が発生するなど、eNB間で同期が取れていないときに有効である。
一方、UE5105が、送信するeNB5101,5103によらずに共通の構成で送信する場合、eNB#1 5101は、eNB#2 5103に、「PUCCH config」、「PUSCH config」などのCoMP設定用パラメータをX2インタフェース5115経由で通知する。セントラルエンティティあるいはMME5106経由でもよい。
これによって、eNB#2 5013も、UE5105が送信するデータを受信することができる。この方法は、UEがどちらのeNBに送信するかを意識することなく、同一のデータを送信することができるので、制御手順が簡易になる。
また、eNB#1 5101は、UL CoMPを行う可能性のあるeNB#1 5101に隣接したeNB#2 5103に、X2インタフェース5115経由で直接、SRS config5116を通知する。eNB#2 5103では、SRS config5116に従って、UE5105のSRSの受信を開始する。
この際、eNB#1 5101とeNB#2 5103とで、事前に同期をとっておくとよい。あるいは、特定の時間範囲内に同期させておくとよい。OFDMシンボルの同期だけではなく、複数のOFDMシンボル長に相当する時間を示すサブフレーム番号、スロット番号、システムフレーム番号(TS36.211に規定されているもの相当)の同期をとることも有効である。
あるいは、eNBは、指定されたSRS送信時間に対してサイクリックプリフィックス(Cyclic Prefix:CP)長以上の所定の時間範囲内の信号の受信を行えるようにする。あるいは、SRSのOFDMシンボルのみCP長を他のデータより長くするもの有効である。あるいは、SRS送信を開始するときに、データ部分も含めてCP長が長いスロットフォーマットにすることも有効である。あるいは、UEがeNB毎に送信する基準タイミング、例えばサブフレーム番号、スロット番号またはシステムフレーム番号の先頭のタイミングを変更することも有効である。
以上のようにすることによって、UL CoMPを開始する前に、UL CoMP対象のeNB#2 5103は、UE5105のSRSの受信によって、上りの通信品質が分かる。eNB#1 5101、eNB#2 5103が、ともに上り受信品質5109,5112をセントラルエンティティ5106に報告することによって、セントラルエンティティ5106では、2つのeNBに最適なリソース割り当てを行うことができる。
UL CoMP開始までの遅延時間(開始指示後、上りの品質測定を行う時間)が不要となり、直ちにUL CoMPを開始でき、遅延時間で発生する最適化できていない周波数、時間、送信電力の割り当てをなくすことができる。
前述のSRS configの通知方法では、X2インタフェース5115経由としたが、セントラルエンティティあるいはMME5106経由でもよい。
この際には、セントラルエンティティは、選択したeNBに、eNB#1 5101のeNB識別子を通知する。eNBは、複数選択されてもよい。
また、UE5105に、選択したeNBのeNB識別子を通知してもよい。
前述のCoMP開始前の手順では、CoMP対象UEに、SRS送信指示を行った後に、隣接するeNB#2 5103に、SRS config5116を通知したが、隣接するeNB#2 5103で割り当てたいSRS用リソース、例えば、周波数、時間(サブフレーム番号)、リソースブロック番号が既に使われている場合を考えて、UEへの通知前に、隣接するeNBに、SRS configを通知してもよい。
あるいは、SRS configのSRS用リソースと、eNB#2 5103の使用中のSRS用リソースとが同じにならないように、eNB#2 5103において、eNB#2のSRS使用開始時に使用状況を、隣接するeNB(eNB#1 5101)に通知しておいてもよい。eNB#2 5103の傘下の他のUEからのSRSと重ならないようにすることによって、eNB#2 5103におけるUEからのSRSの受信品質をさらに向上させることができる。
前述のSRS送信開始判断の例では、セルの境界にいることを検出したタイミングで、eNB#1 5101が、UE5105にSRS送信開始指示を通知することによって、使われないときのSRS送信を最小限にすることができるが、eNB#1 5101のセル半径が小さいときなど、SRS送信開始指示を行う処理時間を省くために、UE5105がeNB#1 5101と通信を開始したときに予めSRS送信開始 configを設定してもよい。
前記SRS送信指示では、リソース位置を指定する情報に加えて、セル個別パラメータではなく、少なくとも1つのUE個別のパラメータを送信したが、例えばS-TMSI(SAE(System Architecture Evolution) Temporary Mobile Station Identifier)、IMSI(International Mobile Station Identifier)などのUEを特定するIDを通知するようにしてもよい(例:nRS
ID=S-TMSI、nRS
ID=IMSI)。
前記SRS送信指示では、セル個別パラメータではなく、少なくとも1つのUE個別のパラメータを送信したが、特定の区域内、例えばトラッキングエリア内、またはCoMPセット(CoMP set)内、もしくは隣接セル群をクラスタ化して管理したときのクラスタ内で、共通に使用するSRSのプールを用意してもよい。地下街に設置されているeNBと、野外に設置されているeNBのように、隣接セル群は、互いに電波が届かない場所に設置されていても、地理的に近いセルを1つのグループとしてSRS用IDを共有する方式も有効である。セントラルエンティティあるいはMME5106でIDの管理を行い、その払い出したIDをサービングセル経由でUEにSRS指示で通知するようにしてもよい(例:nRS
ID=エリア内ID)。
これによって、特定の区域内で共通のSRSとなるので、該区域内eNBが予めSRS受信可能となる。
前記SRS送信指示では、セル個別パラメータではなく、少なくとも1つの、時間多重、あるいは、周波数多重、あるいは、符号多重、あるいは、これらの組合せを行うことで、複数のセル個別パラメータを同時に通知してもよい。この際には、eNB#2 5103からeNB#1 5101に、セルID等のセル個別パラメータを少なくとも1つ含むSRS configを送信する。eNB#1 5101は、この情報をUE5105に通知する。これによって、UE5105が、eNB#1 5101個別のSRSと同時に、eNB#2 5103個別のSRSを送信することができる。
また、eNB#1 5101からeNB#2 5103に通知されるSRS config5116とともに、eNB#2 5103で使用しているリソースを多重していることを同定できる情報も通知してもよい。これによって、eNB#2 5103で、UE5105のSRSが受信可能となる。
また、SRS送信方式を変更することによって送信ビット数が減少し、SRSの送信電力が不足する場合は、それに応じた送信電力オフセットを加算してもよい。
また、eNB#1 5101からの通知先であるeNB#2 5103は、以上の説明では、UL CoMPを行う可能性のある隣接eNBとしているが、具体的には、UL CoMP対象となるeNBでもよい。または、UL CoMPセット内の全てのセルでもよい。
UEへのSRS送信指示は、RRCを用いた例を記載しているが、MACシグナリング、L1/L2制御信号(例えばPDCCH/EPDCCH)で指示してもよい。
次に、下りについて説明する。
上り同様に、DL CoMPが検討されている。例えば、両方のセルから送信を行う結合処理(Joint Processing:JP)、ならびに、多地点間協調スケジューリングを行うCSが検討されている。JPは、結合送信(Joint Transmission:JT)とDPS(Dynamic Point Selection)とに分類される。また、JTとCSとの組合せ方式も検討されている。これらの方法を用いて、セルエッジでのスループットの向上、システムスループットの増大を図ることができる。
特に、CoMPを行う信号が時分割複信(Time Division Duplex:TDD)の場合は、上りおよび下りが同一周波数であることから、上りSRSから伝送路推定を行うことによって、下りの伝送路を推定することができるので、DL CoMPに使用することができる。
TDD時の、下りCSの例で説明する。DL CoMPでは、eNB#1 5101は、UE5105に送信したいデータが発生すると、UE5105にデータを送信する。
eNB#1 5101は、UE5105がセルの境界にいることを検出すると、RRCを用いて、UE5105にSRS送信指示を通知する。非特許文献14(5.5.1.5参照)では、SRS信号を規定する擬似乱数を発生させるためのパラメータnRS
IDはNcell
IDとなっており、セル毎の値(セルID)になっているが、本発明では、SRS送信指示は、少なくとも1つのUE個別のパラメータを指定する。すなわち、UE5105はセル独自のSRS信号ではなく、UE独自のSRS信号を送信する。
また、eNB#1 5101は、DL CoMPを行う可能性のあるeNB#1に隣接したeNB#2 5103に、X2経由で直接、SRS configを通知する。eNB#2では、SRS configに従って、UE5105のSRSを受信開始する。
以上により、TDDの場合は、DL CoMPを開始する前にDL CoMP対象のeNB#2がUEのSRS受信によって、下りの通信品質が分かる。eNB#1、eNB#2は、ともに上り受信品質をセントラルエンティティ5106に報告することによって、セントラルエンティティ5106では、2つのeNBに最適なリソース割り当てを行うことができる。
DL CoMP開始までの遅延時間、すなわち、開始指示後、UEにおいて下りの品質測定を行う時間が不要となり、直ちにDL CoMPを開始することができ、遅延時間で発生する最適化できていない周波数、時間、送信電力の割り当てをなくすことができる。
下りも上りと同様の変形例がある。
SRS configの通知方法では、S1経由(MME経由)でもよい。あるいは、inter-eNB CoMPのリソース割り当てを司るセントラルエンティティの機能部経由であってもよい。
この際には、セントラルエンティティは、選択したeNBに、eNB#1 5101のeNB識別子を通知する。eNBは、複数選択されてもよい。
また、UE5105に、選択したeNBのeNB識別子を通知してもよい。
CoMP開始前の手順では、UEへの通知前に、隣接eNBにSRS configを通知するのもよい。
あるいは、eNB#2 5103において、eNB#2のSRS使用開始時に使用状況を隣接eNB(eNB#1)に通知しておくのもよい。
SRS送信開始判断の例では、UE5105がeNB#1と通信を開始したときに予めSRS送信開始 configを設定してもよい。
SRS送信指示に含む、少なくとも1つのUE個別のパラメータは、例えばS-TMSI、IMSIなどのUEを特定するIDを通知することでもよい(例:nRS
ID=S-TMSI、nRS
ID=IMSI)。
SRS送信指示では、特定の区域内、例えばトラッキングエリア内、またはCoMPセット内、もしくは隣接セル群をクラスタ化して管理したときのクラスタ内で、共通に使用するSRSのプールを用意してもよい。セントラルエンティティあるいはMME5106でIDの管理を行い、その払い出したIDをサービングセル経由でUEにSRS指示で通知するようにしてもよい(例:nRS
ID=SRS用プールID)。
これによって、特定の区域内で共通のSRSとなるので、該区域内eNBが予めSRS受信可能となる。
SRS送信指示では、セル個別パラメータではなく、少なくとも1つのUE個別のパラメータを送信したが、時間多重、あるいは、周波数多重、あるいは、符号多重、あるいは、これらの組み合わせを行うことで、複数のセル個別パラメータを同時に通知してもよい。この際には、eNB#1 5101からeNB#2 5103へのSRS config5116に、eNB#2 5103で使用しているリソースを多重していることを同定できる情報も通知する。
また、eNB#1 5101からの通知先であるeNB#2 5103は、上記では、DL CoMPを行う可能性のある隣接eNBとしているが、具体的には、DL CoMP対象となるeNBでもよい。または、DL CoMPセット内の全てのセルでもよい。あるいは、ID管理に対応したトラッキングエリア内の該当するeNB、および隣接セル群をクラスタ化して管理したとき、そのクラスタ内のeNBでもよい。前記トラッキングエリア内の該当するeNBおよび前記クラスタ内のeNBは、複数でもよい。
UEへのSRS送信指示は、RRCを用いた例を記載しているが、MACシグナリング、L1/L2制御信号(例えばPDCCH/EPDCCH)で指示してもよい。
eNB#1 5101は、UE5105がセルの境界、あるいは、他セルの近傍から離れていることを検出すると、X2インタフェース5115経由あるいは、MMEあるいはセントラルエンティティ5106経由で、eNB#25105にSRS受信停止を通知する。
UEがメジャメント報告(Measurement Report)メッセージで報告してきた自セル(eNB#1)の報告値、具体的にはRSRP、あるいはRSRQ、あるいは両者が特定の閾値以上かどうかで、セルの境界ではないことを判定してもよい。
また、UEがメジャメント報告(Measurement Report)メッセージで報告してきた他セル(eNB#2)の報告値、具体的にはRSRP、あるいはRSRQ、あるいは両者が特定の閾値以下かどうかで、他セルの近傍から離れていると判定してもよい。
また、あるいは、CoMP終了時に、eNB#2にSRS受信停止を通知してもよい。
また、SRS用パラメータをセル個別パラメータに指定したときに、eNB#2にSRS受信停止を通知してもよい。
また、上り制御と下り制御とを同時に行ってもよい。
実施の形態5 変形例1.
実施の形態5では、CoMPの例を説明したが、同様に、DCでのSRSを隣接eNBで受信することによって、DC開始およびDC構成変更後の遅延時間、すなわち開始指示後、UEにおいて下りの品質測定を行う時間が不要となり、直ちにDCを開始することができ、遅延時間で発生する最適化できていない周波数、時間、送信電力の割り当てをなくすことができる。
DCは、非特許文献9(8章参照)に記載があるように、いくつかの形態が検討されているが、アーキテクチャ1Aとアーキテクチャ3Cの検討が進められている。以下、アーキテクチャ3Cの例を、後述する図27を用いて説明する。
S-GW5217は、1ユーザあたりに2つのベアラを割り当てる。ベアラ1は、S1-U経由でMeNB5218からUE5220に送信するベアラである。ベアラ2は、S1-U経由でMeNB5218に到達した信号が、PDCP処理部において、2つに分離される。1つは、MeNB5218において、RLC(Radio Link Control)、MAC処理され、UE5220に送信される。もう1つは、SeNB5219において処理され、UE5220に送信される。
例えば、ベアラ1として、モビリティを管理するための制御信号を適用し、ベアラ2として、動画などのユーザパケットデータを適用する。これによって、セルの半径が大きいMeNBにおいて、高速移動でも通信を継続可能とすることができる。また、SeNBは、セルの半径が小さいので、少ないユーザで周波数帯域を使用することができ、大容量通信が可能となる。
図26および図27は、実施の形態5の変形例1の通信システムにおけるDCの動作の一例を示す図である。図26および図27を用いて、本変形例におけるDC開始時の動作について説明する。
MeNB5201の通信領域5202にいるUE5205は、モビリティ管理用の制御信号も、ユーザパケットデータも、S-GW5206とMeNB5201とを経由して通信している。UE5205が、SeNB5203の通信領域5204に入り、UE5205、MeNB5201、SeNB5203がDC可能であるとき、DCに再構成(SeNB addition)され、2つのベアラが異なるパスに設定される。
例えば、ベアラ1は、S-GW(5206)、S1(5214)、MeNB(5201)、無線伝搬路(5207)およびUE(5205)のパスに設定される。ベアラ2は、S-GW(5206)、S1(5214)およびMeNB(5201)で分離される。そのうち、1つは、MeNB(5201)、無線伝搬路(5207)およびUE(5205)のパスに設定される。もう1つは、MeNB(5201)、X2(5215)、SeNB(5203)、無線伝搬路(5210)およびUE5205のパスに設定される。
ここで、UE5205は、SeNBと同期を確立し、通信品質の測定を行わないと、実際にデータの通信が開始できないという問題がある。また、ベアラ2を分離するとき、無線伝搬路5210の通信品質が分からないという問題がある。
そこで、実施の形態5に記載した方法と同じ方法で、eNB#1からMeNB、eNB#2からSeNBとすることによって、通信しているMeNBだけではなく、隣接セルであるSeNBでも、予めSRSが受信できるようになる。これによって、SeNB5203は、DC開始時に、無線伝搬路の品質確認待ちをせずに、即座にデータの送信が可能となる。
また、MeNB5201は、無線伝搬路の品質確認待ちを行うことなく、自ら受信するSRS5208の受信結果だけでなく、X2(5215)経由でSeNB5203が受信するSRS5212の受信品質などの受信結果5213を考慮して、ベアラ2の分割の割合を決定後、DC開始が可能となる。
また、SeNB5203でも、SRS5212を受信することによって、MeNB5201とSeNB5203のタイミング差異を精度良く検出することが可能となる。SeNB5203のSRS受信タイミング情報を通知することによって、MeNB5201における上りPDCPでの到達パケットの順番組立(リオーダリング)待ち受けタイマの値を、DC開始時にバックホール遅延を考慮して設定することができる。SRS受信タイミング情報は、SRS受信結果5213と一緒に通知してもよい。
以上の説明では、DC開始トリガについて、UE5205、MeNB5201、SeNB5203がDC可能であるときと記載したが、具体的には、以下の(1)~(4)の4つの条件のうち、少なくとも1つは必要となる。
(1)UE5205のケーパビリティ(capability)がDCに対応しているとき。
(2)MeNB5201、SeNB5203がいずれもDC設定可能であるとき。
(3)使用可能なX2 5215などのバックホールの伝送遅延がDC実施上許容範囲内であるとき。
(4)UE5205がMeNB5201、SeNB5203の両方のカバレッジエリア内、あるいは、その近傍にいることを検出したとき。
以上の説明では、アーキテクチャ3Cの例で説明したが、アーキテクチャ1Aも同様に、SRS config5216をX2経由、あるいは、S1(MEE)経由、あるいは、セントラルエンティティ経由でSeNBに通知することによって、SeNBはDC開始時に、無線伝搬路の品質確認待ちをせずに、即座にデータの送信が可能となる。
以上の説明では、SeNB追加について説明したが、SeNB変更についても同様である。同時に受信可能なSRSを設定するためのSRS configを、MeNBから事前にターゲットのSeNB(T-SeNB)に通知することによって、SeNB変更時に、無線伝搬路の品質確認待ちをせずに、即座にデータの送信が可能となる。
以上の説明では、SRS configをMeNBからT-SeNBに通知したが、ソースのS-SeNBからT-SeNBに通知してもよい。
実施の形態6.
実施の形態6で解決する課題を図28に基づいて説明する。図28は、実施の形態6で解決する課題の概念を示す図である。
図28では、通信端末装置である移動端末装置(以下「移動端末(User Equipment:UE)」という)のうち、参照符号「5305」で示されるUEが、ハンドオーバ(HO)元の無線基地局装置であるe-NB#1(以下「S-eNB」という。)5301の電波の送受信可能なセル5302内に在圏している状態を示している。UE5305は、HO5307を行い、HO先の無線基地局装置(以下「T-eNB」という。)5303のセル5304内に在圏する状態となる。この状態のUEが、参照符号「5306」で示されるUE5306である。
実施の形態5に記載のように、現在の3GPPでは、SRSがセル固有の信号となっている(非特許文献14 5.5.1.5参照)。したがって、T-eNB5303は、ハンドオーバが完了するまで、対象のUEのSRSを受信することができず、受信品質をもとに各UEに対して周波数およびタイミング等のリソース割り当てを行う処理(スケジューリング)を開始するのが遅くなるという問題がある。
S-eNB5301は、HO元のUE5305が在圏しているセル5302内で受信通信品質を測定し、同一セル内のスケジューリングを行うものである。一方、T-eNB5303は、UE5305からのSRS5309は無く、スケジューリングは行っていない。
T-eNB5303では、HO後のUE5306の状態でしかSRSを受信できないので、周波数特性を考慮した精度が良いスケジューリングを、HOしてきたUE5306に対して早期に開始することができなかった。
特に、スモールセルが多数運用される場合において、セルの半径も小さく、UEの移動時にはスモールセルの変更が短時間に繰り返されることになる。T-eNBで、UE5306でスケジューリングを実行する際には、既に、他のセルの傘下へ移動している可能性があった。
これらの課題を解決する方法として、実施の形態5と同様に、SRSをセル固有ではなく、UE固有にすることで、T-eNB5303でのスケジューリングを早期に開始することを可能にした通信システムを提案する。
図29は、実施の形態6の通信システムにおけるSRS受信処理のシーケンスの一例を示す図である。
ステップST5402およびステップST5403において、UEは、S-eNB経由でS-GWとパケットデータのやり取りをしている。
ステップST5401において、S-eNBは、UEに対し、受信品質を知るために、メジャメント制御(Measurement Control:MC)メッセージを送信する。UEは、上記MCメッセージの情報に基づいて、自セルならびに周辺セルの受信品質を測定し、ステップST5404において、メジャメント報告(Measurement Report:MR)メッセージをS-eNBへ送信する。
これまでのシーケンスでは、ステップST5404でMRメッセージを受信したS-eNBは、ステップST5408において、HOを実行するか否かの判定処理のHO開始判定を行っていたが、本実施の形態では、ステップST5408のHO開始判定よりも前に、ステップST5405において、SRS開始判定を行うようにしている。
ステップST5404のMRメッセージによって報告されたCRSの受信品質(RSRP、あるいは、RSRQ、あるいは両者)あるいはその他のRSの受信品質が、閾値Th1より小さい場合は、隣接セルへHOする可能性は低いものと判断し、再度ステップST5404のMRメッセージ待ちとする。
ステップST5405のSRS開始判定において、ステップST5404のMRメッセージによって報告された周辺セルの受信品質が、閾値TH1より大きいか否かを判定する。閾値TH1より大きい場合(Yesの場合)は、当該セルへHOする可能性があるものと判断し、ステップST5406において、S-eNBから、T-eNBへ、SRS Configを含むSRS受信開始指示メッセージを送信する。T-eNBは、ステップST5406のSRS受信開始指示メッセージを受けて、ステップST5407において、SRS受信を開始する。
X2シグナリングでS-eNBからT-eNBに直接通知する例として記載したが、S1シグナリングでMME経由で通知してもよい。
S-eNBは、ステップST5406においてSRS受信開始指示を行った後、ステップST5408のHO開始判定において、HOをするかどうかの判定を行う。
以降のHOのシーケンスは、現在のシーケンスと同じである。
本実施の形態では、ステップST5408のHO開始判定とは別に、ステップST5405のSRS開始判定を設けることによって、HOするよりも前に、ステップST5407においてSRS受信が開始できる。
上記ステップST5405のSRS開始判定は、一度「Yes」と判定した後、ステップST5408のHO開始判定において、HO未実行となった場合、再度ステップST5404のMRメッセージを受信したときは、再度、ステップST5405のSRS開始判定を実行し、ステップST5406でSRS受信開始指示を通知してもよいが、しなくてもよい。余分な開始指示を行わないことで、CPU(Central Processing Unit)などの処理負荷を軽減することが可能となる。ステップST5405のSRS開始判定において「No」と判定した場合、S-eNBは、ステップST5405のMRメッセージ待ち状態になる。
図31は、測定報告値に対するSRS受信開始閾値とHO開始閾値との違いを示すための図である。
HOを開始するための閾値Th2とは別に、本発明の実施形態となるSRS開始のための閾値Th1を設ける。
S-eNBは、閾値Th1を閾値Th2より低い値に設定してもよい。これによって、HOより先に、T-eNBにてSRSの受信が可能になり、T-eNBにて、早期に周波数スケジューリングが可能となる。
上記では、閾値Th1を閾値Th2より低い値としたが、閾値Th1と閾値Th2とが同じ値(Th1=Th2)としてもよい。このときは、SRS開始判定でSRS受信開始指示(SRS configを含む)を通知するとともに、HO要求(HO Request)を通知する。SRS受信開始指示とHO要求とが1つのメッセージでもよい。
閾値Th1と閾値Th2とを同じ値(Th1=Th2)とした場合、閾値Th1を閾値Th2よりも低い値とした場合に比べて、T-eNBは、SRS受信開始が遅くなるが、ステップST5414においてHOが完了(RRC Connection Reconfiguration Complete)するよりも早く、SRSの受信を開始することができる。また、閾値Th1を閾値Th2よりも低い値とした場合に比べて、S-eNBでの判定処理を軽減することができる。
セルの大きさに対して、UE5305が非常に速く移動する際は、移動先であるT-eNBでSRSが受信できても、有効にスケジューリングができない場合がある。そのような場合は、SRS受信処理を行わないために、S-eNB5301からT-eNB5303へ送信するSRS受信開始指示メッセージ、あるいは、HO要求メッセージなどに、UE5305の速度情報、例えばUEの移動状態(high、medium、normal)、ハンドオーバまたはセルチェンジしてきた回数(特定時間あたりのハンドオーバまたはセルチェンジ回数も有効)、GPSによる位置の変動(特定時間あたりの位置の移動も有効)、セル毎の滞在時間も含ませるとよい。T-eNB5303の配下においても同様に、高速移動時にSRS5309を抑制することが可能になる。
先に述べたSRS受信開始指示を実行するトリガは、UEからの報告された受信品質に基づいて、S-eNB5301が判定を行うものであったが、UE5305が判定を行って、判定結果をS-eNB5301に送信し、SRS受信開始指示を行ってもよい。
例えば、UE5305は、セル毎の受信品質が所定の閾値以上であるかどうかを示す情報をMRに含めて通知することとしてもよい。
あるいは、UE5305は、周辺セルの受信品質が所定の閾値以上であるとき、セル毎にSRS受信した方がよいことを示すSRS受信要求もMRに含めて通知してもよい。
あるいは、UE5305は、MRとは別に、受信品質が所定の閾値を超えたことを、超えたときに、対象のセルを同定するIDとともに通知してもよい。
以上のようにすることによって、S-eNBにおいて、MRで受信品質判定負荷を軽減することができる。
上記では、UEは、既にUE個別パラメータによるSRSを送信している前提で、他セルに対するSRS受信開始について説明した。次に、UEがSRS送信を開始する判定処理について説明する。
UEがSRSを送信するには、送信電力を消費するので、HOする前後等にのみSRSを送信する、あるいは、HOする前後等にのみSRSの送信間隔をより長くするのが有効である。
ステップST5405のSRS開始判定では、前述の処理に加えて、ステップST5404のMRメッセージによって報告された自セル(S-eNB)のCRSの受信品質(RSRP、あるいは、RSRQ、あるいは両者)あるいはその他のRSの受信品質が、所定の閾値より小さい(例えば、閾値Th2より小さい)かどうか、または、他セルの受信品質が閾値Th1より大きいかどうかを判定する。判定結果が、どちらか一方、あるいは、両方を満たす場合は、隣接セルへHOする可能性が高いものと判断し、UEへのSRS configを含む送信指示を通知する。
S-eNBは、例えば、ステップST5417のRRC接続再設定(RRC Connection Reconfiguration)メッセージに、SRS configを含ませて送信するとよい。これによって、UEは、SRS送信を開始、あるいは、SRS送信頻度を増加させる。
SRSの受信開始のタイミングとして、T-eNB5303が、UE5305のSRS config5311を受信後、直ちに該SRS5309を受信し、スケジューリングを実施するとしているが、T-eNB5303、UE5305からのSRS5309を、スケジューリングする前に少なくとも1回は受信するとしてもよい。
あるいは、T-eNB5303がUE5305からのSRSを、HO ackを送信する前に少なくとも1回は受信するとしてもよい。
また、S-eNBによるUEへのSRS送信指示は、RRCを用いた例を記載しているが、MACシグナリング、L1/L2制御信号(例えばPDCCH/EPDCCH)で指示してもよい。
また、S-eNBによるUEへのSRS送信指示は、SRS送信停止指示が送られるまで有効としてもよい。また、所定の期間周期的に送信する指示としてもよい。
また、UEは、MCI(Mobility Control Information)を受信後、T-eNBと同期確立を行った場合は、該SRSを送信停止してもよい。
図29に示すS-eNBからT-eNBへのHOのシーケンスは以下となる。
ステップST5409において、S-eNBより、T-eNBへHO要求が送信される。ステップST5410において、T-eNBによってアドミッション制御(Admission Control)が実行された後、ステップST5411において、T-eNBからS-eNBへ「HO Request Ack」が返信される。
前記Ackを受信したS-eNBは、ステップST5412において、UEへRRC接続再設定(RRC Connection Reconfiguration)を送信した後、ステップST5413において、T-eNBへ「SN Status Transfer」を送信する。ステップST5412において、UEは、RRC接続再設定(RRC Connection Reconfiguration)を受信し、RRC接続の再設定を行い、結果のRRC接続再設定完了(RRC Connection Reconfiguration Complete)を、ステップST5414において、T-eNBへ送信する。これによって、ステップST5415およびステップST5416において、UEは、T-eNB経由でS-GWとパケットデータのやり取りができる。
T-eNBにおけるSRS受信の停止は、例えば、ステップST5414において、T-eNBがRRC接続再設定完了(RRC Connection Reconfiguration Complete)を受信後、停止を行うとすればよい。HO失敗であっても同様に受信を停止する。
あるいは、ステップST5413において、「SN Status Transfer」をS-eNBから受信したタイミングでもよい。更には、ステップST5411において、T-eNBが「HO Request Ack」をS-eNBへ送信したタイミングであってよい。
以上に述べたシーケンスでは、HO終了後SRSの受信の停止を前提としているが、切り戻しを考慮してHO失敗後もSRS受信を継続してもよい。
その場合の停止方法として、タイマを設けて所定時間確保した後、SRSを停止する。タイマの満了後、再度閾値を確認して判定してもよい。あるいは、UEからSRS受信停止指示がRRCで送信されるまで実行するとしてもよい。あるいは、UEからの周辺セルサーチ情報に基づいて、サービングセルがX2経由でSRS受信停止を指示するまで実行するとしてもよい。
他に、メジャメント結果の判定閾値を更に1つ追加して、SRS停止指示の判定に用いる。他セルへのHO開始より早く閾値を越える値を設定してもよい。この場合のシーケンスを図30に示す。図30は、実施の形態6の通信システムにおけるSRS受信処理のシーケンスの他の例を示す図である。
ステップST5501において、T-eNBは、UEへMCメッセージを送信する。ステップST5502において、UEは、MRメッセージを送信する。T-eNBは、ステップST5502のMRメッセージを受けて、ステップST5503において、SRSの要否判定、すなわちSRSを停止するか否かの判断を行う。具体的には、ステップST5502のMRメッセージで報告された自セル(T-eNB)の受信品質値が、閾値Th3よりも小さいか否か、あるいは、S-eNBの受信品質値が、所定の閾値よりも小さいか否かを判断する。所定の閾値は、例えば、閾値Th1である。所定の閾値は、閾値Th1よりも小さい閾値Th4でもよい。
ステップST5502のMRメッセージで報告された自セル(T-eNB)の受信品質値が、閾値Th3よりも小さい、あるいは、S-eNBの受信品質値が、所定の閾値を下回った場合、SRSの受信を継続すると判断してステップST5502に戻り、ステップST5502のMRメッセージの待ち状態とする。ステップST5502のMRメッセージで報告された自セル(T-eNB)の受信品質値が閾値Th3以上である、あるいは、S-eNBの受信品質値が所定の閾値以上である場合は、ステップST5504において、SRSの受信を停止する。
T-eNBは、対象UEのSRS受信結果に基づいて、HO受け入れ可否(Handover Request Ack)を判断してもよい。その場合、受け入れNGの要因として「SRS受信結果NG」を通知するとよい。
T-eNBは、対象UEのSRS受信結果に基づいて、スケジューリングを行う。
上り送信電力値をSRS受信値により調整する(初期MCSも含める)。セルサイズが異なるeNBが重なるように存在する場合に有効である。
実施の形態6によって、以下の効果を得ることができる。対象となるUEに対するチャネル評価が早期に可能となることで、早期にスケジューリングを行うことができ、周波数効率が改善する。
実施の形態7.
図32は、実施の形態7の通信システムにおけるアンテナ制御の一例を示す図である。本実施の形態では、図32に示すように、ハンドオーバ先eNB#2 5704が、複数のアンテナによる送受信(MIMO)が可能なとき、ハンドオーバ確立前にSRSを受信可能とすることで、ハンドオーバ時すぐにビーム形成等のアンテナ制御を行うことができ、eNBとUEの送信電力を低減可能とする例を説明する。
eNB#1 5703の通信エリア5701で通信しているUE5705,5706がeNB#1 5703のエリア境界にあり、eNB#2 5704の通信エリア5702に移動している。
eNB#2 5704は、複数のアンテナを有し、各アンテナの入力信号の位相、振幅を制御することで、指向性を絞ったビーム5711を形成することができる。しかしながら、実施の形態5に記載のように、現在の3GPPでは、SRSがセル固有の信号となっており(非特許文献14 5.5.1.5参照)、ハンドオーバが完了するまで対象のUEのSRSを受信することができず、指向性を絞ったビーム形成ができないという問題がある。
そこで、実施の形態5と同様に、eNB#1 5703のエリア境界にいることを検出したとき、eNB#1 5703は、RRCで、UE5705に、複数のeNBで受信可能なSRS5709,5710の送信指示をするとともに、eNB#2 5704にX2 5707経由でSRS config5708を送信することで、eNB#2 5704がUE 5705,5706のSRS信号を受信可能とする。
上記の具体的な方法としては、実施の形態5、あるいは、実施の形態6を適用してもよい。
これによって、eNB#2 5704は、複数のアンテナを有し、各アンテナの入力信号の位相、振幅を制御することで、指向性を絞ったビーム5711を形成することができる。
補足すると、例えば、既知系列であるSRSの受信電力が最大になる上りまたは下りの各アンテナ入力信号の位相、振幅値(=重み付け係数)を調整することで、ビームの指向性を絞る。この重み付けを行ったアンテナで、既知系列以外のデータ部分の受信を行う、あるいは、下り送信を行うことで、指向性を絞ったビームによる通信ができる。これによって、eNB#2 5704、UE5706は、他のeNBおよびUEの干渉電力が低減し、良好に受信することができるので、送信電力を低減することができる。
HOする前のUE5705がSRSを送信する場合、指向性アンテナが順次方向を変えて送信を行う場合、例えばθ(t)で送信する方向を時間的に変更する場合、HO先のT-eNB5704が指向性アンテナを特定できるように、HOする前のUE5705は、指向性アンテナ毎に異なるシーケンスパターンを含めるようにしてもよい。
または、HOする前のUE5705がSRSを送信する場合、複数のセクタアンテナのような指向性アンテナでSRSを送信する場合に、指向性アンテナを特定できるように、HOする前のUE5705は、指向性アンテナ毎に異なるシーケンスパターンを含めるようにしてもよい。
また、前述の重み付け係数を決定する方法の例として、eNB#2 5704の通信エリア5702を分割し、分割毎でSRS受信電力値が最大になるものを特定する。SRS受信電力が最大になる分割部を更に分割し、SRS受信電力値が最大になるものを特定する。以上を繰り返すことで、重み付け係数を決定する方法でもよい。
また、下り送信においては、TDDの場合は、上りおよび下りが同一周波数になるため有効である。周波数分割複信(Frequency Division Multiplex:FDD)の場合は、上りと下りで周波数が異なるので、周波数に依存した伝搬特性の差が小さい場合に有効である。
また、前述の実施の形態では、ビームの指向性を絞る制御を説明したが、マルチユーザMIMOによる全ユーザ一括復調の処理を、ハンドオーバ後、速やかに実行することもできる。全UEの既知系列であるSRS(SSRS)、伝送路のインパルス応答(H)、雑音(N)、受信信号Yの関係は、以下に示す式になる。
Y=H×SSRS+N
例えば、ZF(Zero Forcing)のアルゴリズムのように、雑音(N)を無視すれば、Hの逆行列を求めることで、UEの送信データを復元できる。TDDの場合、上り下りの伝搬特性が同じであるので、Hの逆行列を送信データに乗じる(プリコーディングする)ことで、UEは、干渉の影響を低減した信号を受信することができる。
eNBは、上り受信において、通信エリア(eNB#2 5704の通信エリア5702に相当)の全てを覆う指向性のアンテナ・アンテナ群、例えば、指向性なしの等方向受信アンテナを有し、下り送信においては、指向性を有するビームフォーミングを有してもよい。
また、eNBにおける受信アンテナは、等方向の指向性を有してもよい。
または、サービングセルではない隣接したeNBでSRSの受信をすることによって、AoA(Angle of Arrival)を導出することができる。また、eNBの位置を把握している複数eNBでAoAを測定することによって、3点測量を行い、UEの位置をGPS(Global Positioning System)を使わずに把握することもできる。
また、上述の例では、X2インタフェース5707による例を説明したが、実施の形態5と同様に、S1インタフェース(MME経由)でもよいし、セントラルエンティティ経由でもよい。
また、ハンドオーバ先をeNBで説明したが、リレーノード(Relay Node:RN)、RRH(Remote Radio Head)が複数のアンテナになっている場合も同様である。
UE5705,5706が、電車などに搭載され、複数のユーザを束ねて移動するUEの場合(動くリレーノード)、多くのアンテナを備えてビーム形成を行うことが有効である。
複数のアンテナを備えているUEでは、以下のSRSの送信方法が有効である。SRSは、ビーム形成を行わず、等方向に送信する。これによって、eNB#1、eNB#2は、オムニアンテナのみ備えているUEと同様の処理を行うことで、ハンドオーバ前にSRS受信を行い、上りおよび下りのビーム形成を速やかに行うことができる。
また、UE5705が受信できるeNBの同期信号を使って、UE5705の指向性を絞ったビーム形成を行うことも有効である。SRSも該ビームを使って送信する。これにより、UE5705が送信するSRSの送信電力を低減することができる。
また、UE5705が同期信号を受信できない可能性があるので、eNBの存在位置情報を使って、eNBの同期信号が見えなくてもeNBがある方向に送信する方法でもよい。
また、UE5705が複数周波数を送受信しているときは、周波数毎に等方ビームと指向性を絞ったビームの両方でSRSを送信してもよい。これによって、eNBは、上りおよび下りのビーム形成を速やかに行うことができる。
また、周波数が一つでもTDDの場合、サブフレーム毎に、等方ビームと指向性有りの両方を送信させることが可能となる。
また、周波数が一つでもFDDの場合、TDDと同様に、サブフレーム毎に、等方ビームと指向性有りの両方を送信させることが可能となる。
また、eNBがスモールセルである場合は、等方ビームとするのも有効である。セルの半径が小さいので、到来角度の変化に対しても安定したSRS受信が可能となる。
また、街中を走るバスのようにUE5705の移動速度が速いときには、等方ビームでもよい。
また、新幹線のように多くのUE5705が大容量で通信するものについては、移動速度が速くても指向性を絞ったビームでよい。
HO先のT-eNB5704がFDDの場合、HO前のUE5705から送信されるSRS5710を受信後、取得した端末情報をダウンリンク(Down Link)チャネルでUE5705にフィードバックすることで、UE5705は、上りの個別チャネル情報を、HO先のT-eNB5704に対して、ビームフォーミング送信が可能となる。
HO先のT-eNB5704は、HO前のUE5705から送信されるSRS5710を受信後、周波数補正の要否を判断する必要がある。周波数補正が不要と判断できれば、X2インタフェース5707経由で受信したSRS Config情報をダウンリンクチャネルのビームフォーミングに使用することができる。
HO先のT-eNB5704がアレイアンテナのような複数の等方的なアンテナである場合、HO前のS-eNB5703から通信路5707経由で受信したSRS Config5708を用いて、HOするUE5705のSRS5710を受信し、伝搬特性Hを算出することができる。
また、HO先のT-eNB5704が複数のセクタアンテナのような指向性アンテナ(同等の指向性をアレイアンテナで形成する場合も含む)でSRS5710の受信電力が大きいところに指向性を向けたプリコーディングを実行し、ビームフォーミング5711の送信が可能となる。
また、HO先のT-eNB5704の指向性アンテナが、UE5705,5706がSRSを送信するタイミングに合せて、順次方向を変える送信を行う場合、UE5705から送信されるSRS5710の受信電力が最大になる時間のときに、HO先のT-eNB5704が送信していた方向を算出し、その方向に指向性を向けたビームフォーミング5711送信が可能となる。
あるいは、HO先のT-eNB5704の指向性アンテナが、UE5705,5706がSRSを送信するタイミングの倍数のタイミングに合せて、順次方向を変える送信としてもよい。
あるいは、HO先のT-eNB5704の指向性アンテナが送信していた方向に対して、ある受信期間にUE5705から送信されるSRS5710を少なくとも1回受信したときに、HO先のT-eNB5704が送信していた方向に対して、指向性を向けえたビームフォーミング5711送信が可能となる。
HO先のT-eNB5704は、ランダムアクセスプロシージャ(Random Access Procedure)で端末情報を取得し、ビームフォーミング5711送信を実行してもよい。HOしようするUE5705は、HO先であるT-eNB5704にPRACHを送信する。HO先であるT-eNB5705は、UE5705に対して、ランダムアクセス応答(Random Access Response)を送信する。
HOするUE5705は、ランダムアクセスプロシージャにおいて、自UEの位置情報をT-eNB5704に対して通知する。これによって、HO先であるT-eNB5704は、ランダムアクセスプロシージャにおいて、HOするUE5705の位置情報を特定し、その方向に対して、指向性を向けたビームフォーミング5711の送信が可能となる。
また、ハンドオーバ時にHO先であるT-eNB5704がPRACHを受信することで、AoA(Angle of Arrival)を算出することができ、その方向に対して、指向性を向けたビームフォーミング5711送信が可能となる。
また、ハンドオーバ時にSRSの受信により同期確立を行うことも可能であるので、RACHのシーケンスなしとしてもよい。
HOする前のUE5705が、その他のUEと纏まって移動する場合、もしくは、多数のアンテナを有する端末である場合、もしくは、リピータ(Repeater)機能を担っている場合、HOする前のUE5705からHO元のS-eNB5703が検出したHO前のUE5705の位置情報を、通信路5707経由でSRS Config(設定パラメータ値)5708をHO先のT-eNB5704に通知する。
これによって、HO先のT-eNB5704は、HO前のUE5705から送信されるSRS5710を受信して、プリコーディングマトリックスの導出、すなわちビームフォーミングを行うためのアンテナの重み係数の導出のために用いて、HO先のT-eNB5704で、ビームフォーミング5711の送信が可能となる。
本実施の形態によって、MIMO時も含め、HO元の端末からのSRSを受信することで、ビームの指向性、端末の初期送信電力を決めることができ、HO開始時から適切な通信が可能となる。
また、HO時UEにおける受信品質を向上させることができるので、ハンドオーバ失敗(Hand Over Failure:HOF)、無線リンク失敗(Radio Link Failure:RLF)を低減させることが可能となる。
本実施の形態で開示した方法は、マルチストリームのビーム形成にも適用することが可能である。
前述の各実施の形態およびその変形例は、本発明の例示に過ぎず、本発明の範囲内において、各実施の形態およびその変形例を自由に組合せることができる。また各実施の形態およびその変形例の任意の構成要素を適宜変更または省略することができる。これによって、マクロセルに加えて多数のスモールセルを設置して運用する場合にも、UEの通信性能を向上させることができる。
本発明は詳細に説明されたが、上記した説明は、すべての局面において、例示であって、本発明がそれに限定されるものではない。例示されていない無数の変形例が、本発明の範囲から外れることなく想定され得るものと解される。