WO2015141607A1

WO2015141607A1 - 通信システム

Info

Publication number: WO2015141607A1
Application number: PCT/JP2015/057611
Authority: WO
Inventors: 卓也大原; 大成末満; 望月　満; 邦之鈴木; 正幸中澤; 大輔平松
Original assignee: 三菱電機株式会社
Priority date: 2014-03-20
Filing date: 2015-03-16
Publication date: 2015-09-24
Also published as: JP7074806B2; US20240267813A1; JP2020162180A; JP6731844B2; US10743227B2; US20200314715A1; JP2022106987A; JP2024105495A; EP3122119A4; US20180176839A1; EP3474600A1; EP4266795A3; EP3122119A1; CN106134253B; JPWO2015141607A1; EP3737156A1; CN106134253A; US20220353770A1; EP4266795A2; US11997557B2

Abstract

　移動端末装置（ＵＥ）（５７）がマクロセル（Ｓ－ＭｅＮＢ）（５１）とスモールセル（ＳｅＮＢ）（５５）とに接続されるとき、ＵＥ（５７）の移動に伴って、ＵＥ（５７）が接続されるマクロセルを、移動元のマクロセル（Ｓ－ＭｅＮＢ）（５１）から、移動先のマクロセル（Ｔ－ＭｅＮＢ）（５３）に切替えるハンドオーバ処理の前に、ＳｅＮＢ（５５）との接続を解消するハンドオーバ前処理を行い、ハンドオーバ処理の後に、ＳｅＮＢ（５５）との接続を再度確立するハンドオーバ後処理を行う。

Description

通信システム

　本発明は、通信端末装置と基地局装置との間で無線通信を行う通信システムに関する。

　移動体通信システムの規格化団体である３ＧＰＰ（3rd Generation Partnership Project）において、無線区間についてはロングタームエボリューション（Long Term Evolution：ＬＴＥ）と称し、コアネットワークおよび無線アクセスネットワーク（以下、まとめて、ネットワークとも称する）を含めたシステム全体構成については、システムアーキテクチャエボリューション（System Architecture Evolution：ＳＡＥ）と称される新たな通信方式が検討されている（例えば、非特許文献１～１０参照）。この通信方式は３．９Ｇ（3.9 Generation）システムとも呼ばれる。

　ＬＴＥのアクセス方式としては、下り方向はＯＦＤＭ（Orthogonal Frequency Division Multiplexing）、上り方向はＳＣ－ＦＤＭＡ（Single Carrier Frequency Division Multiple Access）が用いられる。また、ＬＴＥは、Ｗ－ＣＤＭＡ（Wideband Code division Multiple Access）とは異なり、回線交換を含まず、パケット通信方式のみになる。

　非特許文献１（５章）に記載される、３ＧＰＰでの、ＬＴＥシステムにおけるフレーム構成に関する決定事項について、図１を用いて説明する。図１は、ＬＴＥ方式の通信システムで使用される無線フレームの構成を示す説明図である。図１において、１つの無線フレーム（Radio frame）は１０ｍｓである。無線フレームは１０個の等しい大きさのサブフレーム（Subframe）に分割される。サブフレームは、２個の等しい大きさのスロット（slot）に分割される。無線フレーム毎に１番目および６番目のサブフレームに下り同期信号（Downlink Synchronization Signal：ＳＳ）が含まれる。同期信号には、第一同期信号（Primary Synchronization Signal：Ｐ－ＳＳ）と、第二同期信号（Secondary Synchronization Signal：Ｓ－ＳＳ）とがある。

　３ＧＰＰでの、ＬＴＥシステムにおけるチャネル構成に関する決定事項が、非特許文献１（５章）に記載されている。ＣＳＧ（Closed Subscriber Group）セルにおいてもｎｏｎ－ＣＳＧセルと同じチャネル構成が用いられると想定されている。

　物理報知チャネル（Physical Broadcast channel：ＰＢＣＨ）は、基地局から移動端末への下り送信用のチャネルである。ＢＣＨトランスポートブロック（transport block）は、４０ｍｓ間隔中の４個のサブフレームにマッピングされる。４０ｍｓタイミングの明白なシグナリングはない。

　物理制御フォーマットインジケータチャネル（Physical Control Format Indicator Channel：ＰＣＦＩＣＨ）は、基地局から移動端末への下り送信用のチャネルである。ＰＣＦＩＣＨは、ＰＤＣＣＨｓのために用いるＯＦＤＭ（Orthogonal Frequency Division Multiplexing）シンボルの数を、基地局から移動端末へ通知する。ＰＣＦＩＣＨは、サブフレーム毎に送信される。

　物理下り制御チャネル（Physical Downlink Control Channel：ＰＤＣＣＨ）は、基地局から移動端末への下り送信用のチャネルである。ＰＤＣＣＨは、後述のトランスポートチャネルの１つである下り共有チャネル（Downlink Shared Channel：ＤＬ－ＳＣＨ）のリソース割り当て（allocation）情報、後述のトランスポートチャネルの１つであるページングチャネル（Paging Channel：ＰＣＨ）のリソース割り当て（allocation）情報、ＤＬ－ＳＣＨに関するＨＡＲＱ（Hybrid Automatic Repeat reQuest）情報を通知する。ＰＤＣＣＨは、上りスケジューリンググラント（Uplink Scheduling Grant）を運ぶ。ＰＤＣＣＨは、上り送信に対する応答信号であるＡｃｋ（Acknowledgement）／Ｎａｃｋ（Negative Acknowledgement）を運ぶ。ＰＤＣＣＨは、Ｌ１／Ｌ２制御信号とも呼ばれる。

　物理下り共有チャネル（Physical Downlink Shared Channel：ＰＤＳＣＨ）は、基地局から移動端末への下り送信用のチャネルである。ＰＤＳＣＨには、トランスポートチャネルである下り共有チャネル（ＤＬ－ＳＣＨ）、およびトランスポートチャネルであるＰＣＨがマッピングされている。

　物理マルチキャストチャネル（Physical Multicast Channel：ＰＭＣＨ）は、基地局から移動端末への下り送信用のチャネルである。ＰＭＣＨには、トランスポートチャネルであるマルチキャストチャネル（Multicast Channel：ＭＣＨ）がマッピングされている。

　物理上り制御チャネル（Physical Uplink Control Channel：ＰＵＣＣＨ）は、移動端末から基地局への上り送信用のチャネルである。ＰＵＣＣＨは、下り送信に対する応答信号（response signal）であるＡｃｋ／Ｎａｃｋを運ぶ。ＰＵＣＣＨは、ＣＱＩ（Channel Quality Indicator）レポートを運ぶ。ＣＱＩとは、受信したデータの品質、もしくは通信路品質を示す品質情報である。またＰＵＣＣＨは、スケジューリングリクエスト（Scheduling Request：ＳＲ）を運ぶ。

　物理上り共有チャネル（Physical Uplink Shared Channel：ＰＵＳＣＨ）は、移動端末から基地局への上り送信用のチャネルである。ＰＵＳＣＨには、トランスポートチャネルの１つである上り共有チャネル（Uplink Shared Channel：ＵＬ－ＳＣＨ）がマッピングされている。

　物理ＨＡＲＱインジケータチャネル（Physical Hybrid ARQ Indicator Channel：ＰＨＩＣＨ）は、基地局から移動端末への下り送信用のチャネルである。ＰＨＩＣＨは、上り送信に対する応答信号であるＡｃｋ／Ｎａｃｋを運ぶ。物理ランダムアクセスチャネル（Physical Random Access Channel：ＰＲＡＣＨ）は、移動端末から基地局への上り送信用のチャネルである。ＰＲＡＣＨは、ランダムアクセスプリアンブル（random access preamble）を運ぶ。

　下り参照信号（リファレンスシグナル（Reference Signal）：ＲＳ）は、ＬＴＥ方式の通信システムとして既知のシンボルである。以下の５種類の下りリファレンスシグナルが定義されている。セル固有参照信号（Cell-specific Reference Signals：ＣＲＳｓ）、ＭＢＳＦＮ参照信号（MBSFN reference signals）、ＵＥ固有参照信号（UE-specific reference signals）であるデータ復調用参照信号（Demodulation Reference Signals：ＤＭ－ＲＳｓ）、位置決定参照信号（Positioning Reference Signals：ＰＲＳｓ）、チャネル情報参照信号（Channel-State Information Reference Signals：ＣＳＩ－ＲＳｓ）。移動端末の物理レイヤの測定として、リファレンスシグナルの受信電力（Reference Signal Received Power：ＲＳＲＰ）測定がある。

　非特許文献１（５章）に記載されるトランスポートチャネル（Transport channel）について、説明する。下りトランスポートチャネルのうち、報知チャネル（Broadcast Channel：ＢＣＨ）は、その基地局（セル）のカバレッジ全体に報知される。ＢＣＨは、物理報知チャネル（ＰＢＣＨ）にマッピングされる。

　下り共有チャネル（Downlink Shared Channel：ＤＬ－ＳＣＨ）には、ＨＡＲＱ（Hybrid ARQ）による再送制御が適用される。ＤＬ－ＳＣＨは、基地局（セル）のカバレッジ全体への報知が可能である。ＤＬ－ＳＣＨは、ダイナミックあるいは準静的（Semi-static）なリソース割り当てをサポートする。準静的なリソース割り当ては、パーシステントスケジューリング（Persistent Scheduling）ともいわれる。ＤＬ－ＳＣＨは、移動端末の低消費電力化のために移動端末の間欠受信（Discontinuous reception：ＤＲＸ）をサポートする。ＤＬ－ＳＣＨは、物理下り共有チャネル（ＰＤＳＣＨ）へマッピングされる。

　ページングチャネル（Paging Channel：ＰＣＨ）は、移動端末の低消費電力を可能とするために移動端末のＤＲＸをサポートする。ＰＣＨは、基地局（セル）のカバレッジ全体への報知が要求される。ＰＣＨは、動的にトラフィックに利用できる物理下り共有チャネル（ＰＤＳＣＨ）のような物理リソースへマッピングされる。

　マルチキャストチャネル（Multicast Channel：ＭＣＨ）は、基地局（セル）のカバレッジ全体への報知に使用される。ＭＣＨは、マルチセル送信におけるＭＢＭＳ（Multimedia Broadcast Multicast Service）サービス（ＭＴＣＨとＭＣＣＨ）のＳＦＮ合成をサポートする。ＭＣＨは、準静的なリソース割り当てをサポートする。ＭＣＨは、ＰＭＣＨへマッピングされる。

　上りトランスポートチャネルのうち、上り共有チャネル（Uplink Shared Channel：ＵＬ－ＳＣＨ）には、ＨＡＲＱ（Hybrid ARQ）による再送制御が適用される。ＵＬ－ＳＣＨは、ダイナミックあるいは準静的（Semi-static）なリソース割り当てをサポートする。ＵＬ－ＳＣＨは、物理上り共有チャネル（ＰＵＳＣＨ）へマッピングされる。

　ランダムアクセスチャネル（Random Access Channel：ＲＡＣＨ）は、制御情報に限られている。ＲＡＣＨは、衝突のリスクがある。ＲＡＣＨは、物理ランダムアクセスチャネル（ＰＲＡＣＨ）へマッピングされる。

　ＨＡＲＱについて説明する。ＨＡＲＱとは、自動再送要求（Automatic Repeat reQuest：ＡＲＱ）と誤り訂正（Forward Error Correction）との組合せによって、伝送路の通信品質を向上させる技術である。ＨＡＲＱには、通信品質が変化する伝送路に対しても、再送によって誤り訂正が有効に機能するという利点がある。特に、再送にあたって初送の受信結果と再送の受信結果との合成をすることで、更なる品質向上を得ることも可能である。

　再送の方法の一例を説明する。受信側にて、受信データが正しくデコードできなかった場合、換言すればＣＲＣ（Cyclic Redundancy Check）エラーが発生した場合（ＣＲＣ＝ＮＧ）、受信側から送信側へ「Ｎａｃｋ」を送信する。「Ｎａｃｋ」を受信した送信側は、データを再送する。受信側にて、受信データが正しくデコードできた場合、換言すればＣＲＣエラーが発生しない場合（ＣＲＣ＝ＯＫ）、受信側から送信側へ「Ａｃｋ」を送信する。「Ａｃｋ」を受信した送信側は次のデータを送信する。

　非特許文献１（６章）に記載される論理チャネル（ロジカルチャネル：Logical channel）について、説明する。報知制御チャネル（Broadcast Control Channel：ＢＣＣＨ）は、報知システム制御情報のための下りチャネルである。論理チャネルであるＢＣＣＨは、トランスポートチャネルである報知チャネル（ＢＣＨ）、あるいは下り共有チャネル（ＤＬ－ＳＣＨ）へマッピングされる。

　ページング制御チャネル（Paging Control Channel：ＰＣＣＨ）は、ページング情報（Paging Information）およびシステム情報（System Information）の変更を送信するための下りチャネルである。ＰＣＣＨは、移動端末のセルロケーションをネットワークが知らない場合に用いられる。論理チャネルであるＰＣＣＨは、トランスポートチャネルであるページングチャネル（ＰＣＨ）へマッピングされる。

　共有制御チャネル（Common Control Channel：ＣＣＣＨ）は、移動端末と基地局との間の送信制御情報のためのチャネルである。ＣＣＣＨは、移動端末がネットワークとの間でＲＲＣ接続（connection）を有していない場合に用いられる。下り方向では、ＣＣＣＨは、トランスポートチャネルである下り共有チャネル（ＤＬ－ＳＣＨ）へマッピングされる。上り方向では、ＣＣＣＨは、トランスポートチャネルである上り共有チャネル（ＵＬ－ＳＣＨ）へマッピングされる。

　マルチキャスト制御チャネル（Multicast Control Channel：ＭＣＣＨ）は、１対多の送信のための下りチャネルである。ＭＣＣＨは、ネットワークから移動端末への１つあるいはいくつかのＭＴＣＨ用のＭＢＭＳ制御情報の送信のために用いられる。ＭＣＣＨは、ＭＢＭＳ受信中の移動端末のみに用いられる。ＭＣＣＨは、トランスポートチャネルであるマルチキャストチャネル（ＭＣＨ）へマッピングされる。

　個別制御チャネル（Dedicated Control Channel：ＤＣＣＨ）は、１対１にて、移動端末とネットワークとの間の個別制御情報を送信するチャネルである。ＤＣＣＨは、移動端末がＲＲＣ接続（connection）である場合に用いられる。ＤＣＣＨは、上りでは上り共有チャネル（ＵＬ－ＳＣＨ）へマッピングされ、下りでは下り共有チャネル（ＤＬ－ＳＣＨ）にマッピングされる。

　個別トラフィックチャネル（Dedicated Traffic Channel：ＤＴＣＨ）は、ユーザ情報の送信のための個別移動端末への１対１通信のチャネルである。ＤＴＣＨは、上りおよび下りともに存在する。ＤＴＣＨは、上りでは上り共有チャネル（ＵＬ－ＳＣＨ）へマッピングされ、下りでは下り共有チャネル（ＤＬ－ＳＣＨ）へマッピングされる。

　マルチキャストトラフィックチャネル（Multicast Traffic channel：ＭＴＣＨ）は、ネットワークから移動端末へのトラフィックデータ送信のための下りチャネルである。ＭＴＣＨは、ＭＢＭＳ受信中の移動端末のみに用いられるチャネルである。ＭＴＣＨは、マルチキャストチャネル（ＭＣＨ）へマッピングされる。

　ＣＧＩとは、セルグローバル識別子（Cell Global Identifier）のことである。ＥＣＧＩとは、Ｅ－ＵＴＲＡＮセルグローバル識別子（E-UTRAN Cell Global Identifier）のことである。ＬＴＥ、後述のＬＴＥ－Ａ（Long Term Evolution Advanced）およびＵＭＴＳ（Universal Mobile Telecommunication System）において、ＣＳＧ（Closed Subscriber Group）セルが導入される。

　ＣＳＧ（Closed Subscriber Group）セルとは、利用可能な加入者をオペレータが特定しているセル（以下「特定加入者用セル」という場合がある）である。特定された加入者は、ＰＬＭＮ（Public Land Mobile Network）の１つ以上のセルにアクセスすることが許可される。特定された加入者がアクセスを許可されている１つ以上のセルを「ＣＳＧセル（ＣＳＧ　ｃｅｌｌ（ｓ））」と呼ぶ。ただし、ＰＬＭＮにはアクセス制限がある。

　ＣＳＧセルは、固有のＣＳＧアイデンティティ（CSG identity：ＣＳＧ　ＩＤ；ＣＳＧ－ＩＤ）を報知し、ＣＳＧインジケーション（CSG Indication）にて「ＴＲＵＥ」を報知するＰＬＭＮの一部である。予め利用登録し、許可された加入者グループのメンバーは、アクセス許可情報であるところのＣＳＧ－ＩＤを用いてＣＳＧセルにアクセスする。

　ＣＳＧ－ＩＤは、ＣＳＧセルまたはセルによって報知される。ＬＴＥ方式の通信システムにＣＳＧ－ＩＤは複数存在する。そして、ＣＳＧ－ＩＤは、ＣＳＧ関連のメンバーのアクセスを容易にするために、移動端末（ＵＥ）によって使用される。

　移動端末の位置追跡は、１つ以上のセルからなる区域を単位に行われる。位置追跡は、待受け状態であっても移動端末の位置を追跡し、移動端末を呼び出す、換言すれば移動端末が着呼することを可能にするために行われる。この移動端末の位置追跡のための区域をトラッキングエリアと呼ぶ。

　３ＧＰＰにおいて、Ｈｏｍｅ－ＮｏｄｅＢ（Ｈｏｍｅ－ＮＢ；ＨＮＢ）、Ｈｏｍｅ－ｅＮｏｄｅＢ（Ｈｏｍｅ－ｅＮＢ；ＨｅＮＢ）と称される基地局が検討されている。ＵＴＲＡＮにおけるＨＮＢ、およびＥ－ＵＴＲＡＮにおけるＨｅＮＢは、例えば家庭、法人、商業用のアクセスサービス向けの基地局である。非特許文献３には、ＨｅＮＢおよびＨＮＢへのアクセスの３つの異なるモードが開示されている。具体的には、オープンアクセスモード（Open access mode）と、クローズドアクセスモード（Closed access mode）と、ハイブリッドアクセスモード（Hybrid access mode）とが開示されている。

　各々のモードは、以下のような特徴を有する。オープンアクセスモードでは、ＨｅＮＢおよびＨＮＢは、通常のオペレータのノーマルセルとして操作される。クローズドアクセスモードでは、ＨｅＮＢおよびＨＮＢは、ＣＳＧセルとして操作される。このＣＳＧセルは、ＣＳＧメンバーのみアクセス可能なＣＳＧセルである。ハイブリッドアクセスモードでは、ＨｅＮＢおよびＨＮＢは、非ＣＳＧメンバーも同時にアクセス許可されているＣＳＧセルとして操作される。言い換えれば、ハイブリッドアクセスモードのセル（ハイブリッドセルとも称する）は、オープンアクセスモードとクローズドアクセスモードとの両方をサポートするセルである。

　３ＧＰＰでは、全ての物理セル識別子（Physical Cell Identity：ＰＣＩ）のうち、ＣＳＧセルで使用するためにネットワークによって予約されたＰＣＩ範囲がある（非特許文献１　１０．５．１．１章参照）。ＰＣＩ範囲を分割することをＰＣＩスプリットと称することがある。ＰＣＩスプリットに関する情報（ＰＣＩスプリット情報とも称する）は、システム情報によって基地局から傘下の移動端末に対して報知される。基地局の傘下とは、該基地局をサービングセルとすることを意味する。

　非特許文献４は、ＰＣＩスプリットを用いた移動端末の基本動作を開示する。ＰＣＩスプリット情報を有していない移動端末は、全ＰＣＩを用いて、例えば５０４コード全てを用いて、セルサーチを行う必要がある。これに対して、ＰＣＩスプリット情報を有する移動端末は、当該ＰＣＩスプリット情報を用いてセルサーチを行うことが可能である。

　また３ＧＰＰでは、リリース１０として、ロングタームエボリューションアドヴァンスド（Long Term Evolution Advanced：ＬＴＥ－Ａ）の規格策定が進められている（非特許文献５、非特許文献６参照）。ＬＴＥ－Ａは、ＬＴＥの無線区間通信方式を基本とし、それにいくつかの新技術を加えて構成される。

　ＬＴＥ－Ａシステムでは、１００ＭＨｚまでのより広い周波数帯域幅（transmission bandwidths）をサポートするために、二つ以上のコンポーネントキャリア（Component Carrier：ＣＣ）を集約する（「アグリゲーション（aggregation）する」とも称する）、キャリアアグリゲーション（Carrier Aggregation：ＣＡ）が検討されている。

　ＣＡが構成される場合、ＵＥはネットワーク（Network：ＮＷ）と唯一つのＲＲＣ接続（RRC connection）を有する。ＲＲＣ接続において、一つのサービングセルがＮＡＳモビリティ情報とセキュリティ入力を与える。このセルをプライマリセル（Primary Cell：ＰＣｅｌｌ）と呼ぶ。下りリンクで、ＰＣｅｌｌに対応するキャリアは、下りプライマリコンポーネントキャリア（Downlink Primary Component Carrier：ＤＬ　ＰＣＣ）である。上りリンクで、ＰＣｅｌｌに対応するキャリアは、上りプライマリコンポーネントキャリア（Uplink Primary Component Carrier：ＵＬ　ＰＣＣ）である。

　ＵＥの能力（ケーパビリティ（capability））に応じて、セカンダリセル（Secondary Cell：ＳＣｅｌｌ）が、ＰＣｅｌｌとサービングセルとの組を形成するために構成される。下りリンクで、ＳＣｅｌｌに対応するキャリアは、下りセカンダリコンポーネントキャリア（Downlink Secondary Component Carrier：ＤＬ　ＳＣＣ）である。上りリンクで、ＳＣｅｌｌに対応するキャリアは、上りセカンダリコンポーネントキャリア（Uplink Secondary Component Carrier：ＵＬ　ＳＣＣ）である。

　一つのＵＥに対して、一つのＰＣｅｌｌと、一つ以上のＳＣｅｌｌからなるサービングセルとの組が構成される。

　また、ＬＴＥ－Ａでの新技術としては、より広い帯域をサポートする技術（Wider bandwidth extension）、および多地点協調送受信（Coordinated Multiple Point transmission and reception：ＣｏＭＰ）技術などがある。３ＧＰＰでＬＴＥ－Ａのために検討されているＣｏＭＰについては、非特許文献７に記載されている。

　モバイルネットワークのトラフィック量は、増加傾向にあり、通信速度も高速化が進んでいる。ＬＴＥおよびＬＴＥ－Ａが本格的に運用を開始されると、更に通信速度が高速化され、トラフィック量が増加することが見込まれる。

　また、スマートフォンおよびタブレット端末の普及によって、セルラー系無線通信によるトラフィック量が爆発的に増加しており、世界中で無線リソースの不足が懸念されている。

　トラフィック量の増加の問題に対して、３ＧＰＰにおいて、リリース１２版の規格書の策定が進められている。リリース１２版の規格書では、将来の膨大なトラフィック量に対応するために、スモールｅＮＢを用いることが検討されている。例えば、多数のスモールｅＮＢを設置して、多数のスモールセルを構成することによって、周波数利用効率を高めて、通信容量の増大を図る技術などが検討されている。

　その中で、マクロセルとスモールセルとがオーバラップしている場合に、移動端末がマクロセルとスモールセルとの両方に接続する技術として、デュアルコネクティビティ（dual connectivity）が議論されている（非特許文献１１参照）。

３ＧＰＰ　ＴＳ３６．３００　Ｖ１１．７．０３ＧＰＰ　ＴＳ３６．３０４　Ｖ１１．２．０３ＧＰＰ　Ｓ１－０８３４６１３ＧＰＰ　Ｒ２－０８２８９９３ＧＰＰ　ＴＲ　３６．８１４　Ｖ９．０．０３ＧＰＰ　ＴＲ　３６．９１２　Ｖ１０．０．０３ＧＰＰ　ＴＲ　３６．８１９　Ｖ１１．１．０３ＧＰＰ　ＴＳ　３６．１４１　Ｖ１１．１．０３ＧＰＰ　Ｒ１－１３４４９６３ＧＰＰ　Ｒ１－１３２２３６３ＧＰＰ　ＴＲ３６．８４２　Ｖ０．２．０

　前述のように、非特許文献１１には、マクロセルとスモールセルとがオーバラップしている場合に、移動端末がマクロセルとスモールセルとの両方に接続する技術として、デュアルコネクティビティ（dual connectivity）が開示されている。

　しかし、デュアルコネクティビティ中の移動端末がハンドオーバを行うときの取り扱いについては、非特許文献１１には何ら開示されていない。従来のハンドオーバ方法では、移動端末は、１つのセルとのみ接続しており、デュアルコネクティビティにおけるマクロセルとスモールセルとの両方との接続については考慮されていない。

　したがって、従来のハンドオーバ方法を何の工夫もなく、デュアルコネクティビティ中の移動端末に適用することは不可能である。

　本発明の目的は、マクロセルとスモールセルとの両方に接続中の移動端末装置がマクロセル間のハンドオーバを行うことができる通信システムを提供することである。

　本発明の通信システムは、移動端末装置と、前記移動端末装置と無線通信可能なセルを構成する基地局装置とを備える通信システムであって、前記セルとして、前記移動端末装置と通信可能な範囲であるカバレッジが比較的大きい複数のマクロセルと、前記カバレッジが比較的小さいスモールセルとを備え、前記移動端末装置は、前記複数のマクロセルのうちの１つと前記スモールセルとに接続されるとき、前記移動端末装置の移動に伴って、前記移動端末装置が接続されるマクロセルを移動元のマクロセルから移動先のマクロセルに切替えるハンドオーバ処理の前に、前記スモールセルとの接続を解消するハンドオーバ前処理を行い、前記ハンドオーバ処理の後に、前記スモールセルとの接続を再度確立するハンドオーバ後処理を行うことを特徴とする。

　また本発明の通信システムは、移動端末装置と、前記移動端末装置と無線通信可能なセルを構成する基地局装置とを備える通信システムであって、前記セルとして、前記移動端末装置と通信可能な範囲であるカバレッジが比較的大きい複数のマクロセルと、前記カバレッジが比較的小さいスモールセルとを備え、前記移動端末装置が前記複数のマクロセルのうちの１つと前記スモールセルとに接続されるとき、前記移動端末装置の移動に伴って、前記移動端末装置が接続されるマクロセルを移動元のマクロセルから移動先のマクロセルに切替えるハンドオーバ処理が起動されると、前記スモールセルに、前記スモールセルを制御する前記マクロセルが変更されることが通知されることを特徴とする。

　本発明の通信システムによれば、マクロセルとスモールセルとの両方に接続中の移動端末装置が、マクロセル間のハンドオーバを行うことができる。

　本発明の目的、特徴、局面、および利点は、以下の詳細な説明と添付図面とによって、より明白となる。

ＬＴＥ方式の通信システムで使用される無線フレームの構成を示す説明図である。３ＧＰＰにおいて議論されているＬＴＥ方式の通信システム７００の全体的な構成を示すブロック図である。本発明に係る移動端末である図２に示す移動端末７１の構成を示すブロック図である。本発明に係る基地局である図２に示す基地局７２の構成を示すブロック図である。本発明に係るＭＭＥの構成を示すブロック図である。ＬＴＥ方式の通信システムにおいて移動端末（ＵＥ）が行うセルサーチから待ち受け動作までの概略を示すフローチャートである。マクロｅＮＢとスモールｅＮＢとが混在する場合のセルの構成の概念を示す図である。本発明の実施の形態１の通信システムにおけるｅＮＢのカバレッジの一例を示す図である。本発明の実施の形態１の通信システムにおけるｅＮＢのカバレッジの一例を示す図である。本発明の実施の形態１の通信システムにおけるハンドオーバ関連処理のシーケンスの一例を示す図である。図１０のステップＳＴ９０８のＨＯ前処理のシーケンスの一例を示す図である。図１０のステップＳＴ９２８のＨＯ処理のシーケンスの一例を示す図である。図１０のステップＳＴ９４９のＨＯ後処理のシーケンスの一例を示す図である。本発明の実施の形態１の変形例１の通信システムにおけるハンドオーバ関連処理のシーケンスの一例を示す図である。図１４のステップＳＴ１００９のＨＯ前処理のシーケンスの一例を示す図である。図１４のステップＳＴ１０１０のＨＯ後処理のシーケンスの一例を示す図である。本発明の実施の形態２の通信システムにおけるハンドオーバ関連処理のシーケンスの一例を示す図である。本発明の実施の形態２の通信システムにおけるハンドオーバ関連処理のシーケンスの一例を示す図である。本発明の実施の形態２の通信システムにおけるハンドオーバ関連処理のシーケンスの一例を示す図である。本発明の実施の形態３の通信システムにおけるハンドオーバ関連処理のシーケンスの一例を示す図である。本発明の実施の形態３の通信システムにおけるハンドオーバ関連処理のシーケンスの一例を示す図である。本発明の実施の形態３の通信システムにおけるハンドオーバ関連処理のシーケンスの一例を示す図である。本発明の実施の形態４の通信システムにおけるハンドオーバ関連処理のシーケンスの一例を示す図である。本発明の実施の形態４の通信システムにおけるハンドオーバ関連処理のシーケンスの一例を示す図である。本発明の実施の形態４の通信システムにおけるハンドオーバ関連処理のシーケンスの一例を示す図である。本発明の実施の形態５の通信システムにおけるハンドオーバ関連処理のシーケンスの一例を示す図である。本発明の実施の形態５の通信システムにおけるハンドオーバ関連処理のシーケンスの一例を示す図である。本発明の実施の形態５の通信システムにおけるハンドオーバ関連処理のシーケンスの一例を示す図である。図２８のステップＳＴ２０２５のＥＰＳベアラ＃１用ＭｅＮＢ　ＨＯ処理のシーケンスの一例を示す図である。図２８のステップＳＴ２０２５のＥＰＳベアラ＃１用ＭｅＮＢ　ＨＯ処理のシーケンスの一例を示す図である。ＵＥとの間のデータの送受信の状況の一例を示す図である。本発明の実施の形態６の通信システムにおけるＥＰＳベアラ＃１用ＭｅＮＢ　ＨＯ処理のシーケンスの一例を示す図である。本発明の実施の形態６の通信システムにおけるＥＰＳベアラ＃１用ＭｅＮＢ　ＨＯ処理のシーケンスの一例を示す図である。本発明の実施の形態７の通信システムにおけるＥＰＳベアラ＃１用ＭｅＮＢ　ＨＯ処理のシーケンスの一例を示す図である。本発明の実施の形態７の通信システムにおけるＥＰＳベアラ＃１用ＭｅＮＢ　ＨＯ処理のシーケンスの一例を示す図である。

　実施の形態１．
　図２は、３ＧＰＰにおいて議論されているＬＴＥ方式の通信システム７００の全体的な構成を示すブロック図である。図２について説明する。無線アクセスネットワークは、Ｅ－ＵＴＲＡＮ（Evolved Universal Terrestrial Radio Access Network）７０と称される。通信端末装置である移動端末装置（以下「移動端末（User Equipment：ＵＥ）」という）７１は、基地局装置（以下「基地局（E-UTRAN NodeB：ｅＮＢ）」という）７２と無線通信可能であり、無線通信で信号の送受信を行う。

　移動端末７１に対する制御プロトコル、例えばＲＲＣ（Radio Resource Control）と、ユーザプレイン、例えばＰＤＣＰ（Packet Data Convergence Protocol）、ＲＬＣ（Radio Link Control）、ＭＡＣ（Medium Access Control）、ＰＨＹ（Physical layer）とが基地局７２で終端するならば、Ｅ－ＵＴＲＡＮは１つあるいは複数の基地局７２によって構成される。

　移動端末７１と基地局７２との間の制御プロトコルＲＲＣ（Radio Resource Control）は、報知（Broadcast）、ページング（paging）、ＲＲＣ接続マネージメント（RRC connection management）などを行う。ＲＲＣにおける基地局７２と移動端末７１との状態として、ＲＲＣ＿ＩＤＬＥと、ＲＲＣ＿ＣＯＮＮＥＣＴＥＤとがある。

　ＲＲＣ＿ＩＤＬＥでは、ＰＬＭＮ（Public Land Mobile Network）選択、システム情報（System Information：ＳＩ）の報知、ページング（paging）、セル再選択（cell re-selection）、モビリティなどが行われる。ＲＲＣ＿ＣＯＮＮＥＣＴＥＤでは、移動端末はＲＲＣ接続（connection）を有し、ネットワークとのデータの送受信を行うことができる。またＲＲＣ＿ＣＯＮＮＥＣＴＥＤでは、ハンドオーバ（Handover：ＨＯ）、隣接セル（Neighbour cell）の測定（メジャメント（measurement））などが行われる。

　基地局７２は、ｅＮＢ７６と、Ｈｏｍｅ－ｅＮＢ７５とに分類される。通信システム７００は、複数のｅＮＢ７６を含むｅＮＢ群７２－１と、複数のＨｏｍｅ－ｅＮＢ７５を含むＨｏｍｅ－ｅＮＢ群７２－２とを備える。またコアネットワークであるＥＰＣ（Evolved Packet Core）と、無線アクセスネットワークであるＥ－ＵＴＲＡＮ７０とで構成されるシステムは、ＥＰＳ（Evolved Packet System）と称される。コアネットワークであるＥＰＣと、無線アクセスネットワークであるＥ－ＵＴＲＡＮ７０とを合わせて、「ネットワーク」という場合がある。

　ｅＮＢ７６は、移動管理エンティティ（Mobility Management Entity：ＭＭＥ）、あるいはＳ－ＧＷ（Serving Gateway）、あるいはＭＭＥおよびＳ－ＧＷを含むＭＭＥ／Ｓ－ＧＷ部（以下「ＭＭＥ部」という場合がある）７３とＳ１インタフェースにより接続され、ｅＮＢ７６とＭＭＥ部７３との間で制御情報が通信される。一つのｅＮＢ７６に対して、複数のＭＭＥ部７３が接続されてもよい。ｅＮＢ７６間は、Ｘ２インタフェースにより接続され、ｅＮＢ７６間で制御情報が通信される。

　Ｈｏｍｅ－ｅＮＢ７５は、ＭＭＥ部７３とＳ１インタフェースにより接続され、Ｈｏｍｅ－ｅＮＢ７５とＭＭＥ部７３との間で制御情報が通信される。一つのＭＭＥ部７３に対して、複数のＨｏｍｅ－ｅＮＢ７５が接続される。あるいは、Ｈｏｍｅ－ｅＮＢ７５は、ＨｅＮＢＧＷ（Home-eNB GateWay）７４を介してＭＭＥ部７３と接続される。Ｈｏｍｅ－ｅＮＢ７５とＨｅＮＢＧＷ７４とは、Ｓ１インタフェースにより接続され、ＨｅＮＢＧＷ７４とＭＭＥ部７３とはＳ１インタフェースを介して接続される。

　一つまたは複数のＨｏｍｅ－ｅＮＢ７５が一つのＨｅＮＢＧＷ７４と接続され、Ｓ１インタフェースを通して情報が通信される。ＨｅＮＢＧＷ７４は、一つまたは複数のＭＭＥ部７３と接続され、Ｓ１インタフェースを通して情報が通信される。

　ＭＭＥ部７３およびＨｅＮＢＧＷ７４は、上位装置、具体的には上位ノードであり、基地局であるｅＮＢ７６およびＨｏｍｅ－ｅＮＢ７５と、移動端末（ＵＥ）７１との接続を制御する。ＭＭＥ部７３は、コアネットワークであるＥＰＣを構成する。基地局７２およびＨｅＮＢＧＷ７４は、Ｅ－ＵＴＲＡＮ７０を構成する。

　さらに３ＧＰＰでは、以下のような構成が検討されている。Ｈｏｍｅ－ｅＮＢ７５間のＸ２インタフェースはサポートされる。すなわち、Ｈｏｍｅ－ｅＮＢ７５間は、Ｘ２インタフェースにより接続され、Ｈｏｍｅ－ｅＮＢ７５間で制御情報が通信される。ＭＭＥ部７３からは、ＨｅＮＢＧＷ７４はＨｏｍｅ－ｅＮＢ７５として見える。Ｈｏｍｅ－ｅＮＢ７５からは、ＨｅＮＢＧＷ７４はＭＭＥ部７３として見える。

　Ｈｏｍｅ－ｅＮＢ７５が、ＨｅＮＢＧＷ７４を介してＭＭＥ部７３に接続される場合および直接ＭＭＥ部７３に接続される場合のいずれの場合も、Ｈｏｍｅ－ｅＮＢ７５とＭＭＥ部７３との間のインタフェースは、Ｓ１インタフェースで同じである。

　基地局装置７２は、１つのセルを構成してもよいし、複数のセルを構成してもよい。各セルは、移動端末７１と通信可能な範囲であるカバレッジとして予め定める範囲を有し、カバレッジ内で移動端末７１と無線通信を行う。１つの基地局装置７２が複数のセルを構成する場合、１つ１つのセルが、移動端末７１と通信可能に構成される。

　図３は、本発明に係る移動端末である図２に示す移動端末７１の構成を示すブロック図である。図３に示す移動端末７１の送信処理を説明する。まず、プロトコル処理部８０１からの制御データ、およびアプリケーション部８０２からのユーザデータが、送信データバッファ部８０３へ保存される。送信データバッファ部８０３に保存されたデータは、エンコーダー部８０４へ渡され、誤り訂正などのエンコード処理が施される。エンコード処理を施さずに、送信データバッファ部８０３から変調部８０５へ直接出力されるデータが存在してもよい。エンコーダー部８０４でエンコード処理されたデータは、変調部８０５にて変調処理が行われる。変調されたデータは、ベースバンド信号に変換された後、周波数変換部８０６へ出力され、無線送信周波数に変換される。その後、アンテナ８０７から基地局７２に送信信号が送信される。

　また、移動端末７１の受信処理は、以下のように実行される。基地局７２からの無線信号がアンテナ８０７により受信される。受信信号は、周波数変換部８０６にて無線受信周波数からベースバンド信号に変換され、復調部８０８において復調処理が行われる。復調後のデータは、デコーダー部８０９へ渡され、誤り訂正などのデコード処理が行われる。デコードされたデータのうち、制御データはプロトコル処理部８０１へ渡され、ユーザデータはアプリケーション部８０２へ渡される。移動端末７１の一連の処理は、制御部８１０によって制御される。よって制御部８１０は、図３では省略しているが、各部８０１～８０９と接続している。

　図４は、本発明に係る基地局である図２に示す基地局７２の構成を示すブロック図である。図４に示す基地局７２の送信処理を説明する。ＥＰＣ通信部９０１は、基地局７２とＥＰＣ（ＭＭＥ部７３など）、ＨｅＮＢＧＷ７４などとの間のデータの送受信を行う。他基地局通信部９０２は、他の基地局との間のデータの送受信を行う。ＥＰＣ通信部９０１および他基地局通信部９０２は、それぞれプロトコル処理部９０３と情報の受け渡しを行う。プロトコル処理部９０３からの制御データ、ならびにＥＰＣ通信部９０１および他基地局通信部９０２からのユーザデータおよび制御データは、送信データバッファ部９０４へ保存される。

　送信データバッファ部９０４に保存されたデータは、エンコーダー部９０５へ渡され、誤り訂正などのエンコード処理が施される。エンコード処理を施さずに、送信データバッファ部９０４から変調部９０６へ直接出力されるデータが存在してもよい。エンコードされたデータは、変調部９０６にて変調処理が行われる。変調されたデータは、ベースバンド信号に変換された後、周波数変換部９０７へ出力され、無線送信周波数に変換される。その後、アンテナ９０８より一つもしくは複数の移動端末７１に対して送信信号が送信される。

　また、基地局７２の受信処理は以下のように実行される。一つもしくは複数の移動端末７１からの無線信号が、アンテナ９０８により受信される。受信信号は、周波数変換部９０７にて無線受信周波数からベースバンド信号に変換され、復調部９０９で復調処理が行われる。復調されたデータは、デコーダー部９１０へ渡され、誤り訂正などのデコード処理が行われる。デコードされたデータのうち、制御データはプロトコル処理部９０３あるいはＥＰＣ通信部９０１、他基地局通信部９０２へ渡され、ユーザデータはＥＰＣ通信部９０１および他基地局通信部９０２へ渡される。基地局７２の一連の処理は、制御部９１１によって制御される。よって制御部９１１は、図４では省略しているが、各部９０１～９１０と接続している。

　図５は、本発明に係るＭＭＥの構成を示すブロック図である。図５では、前述の図２に示すＭＭＥ部７３に含まれるＭＭＥ７３ａの構成を示す。ＰＤＮ　ＧＷ通信部１００１は、ＭＭＥ７３ａとＰＤＮ　ＧＷとの間のデータの送受信を行う。基地局通信部１００２は、ＭＭＥ７３ａと基地局７２との間のＳ１インタフェースによるデータの送受信を行う。ＰＤＮ　ＧＷから受信したデータがユーザデータであった場合、ユーザデータは、ＰＤＮ　ＧＷ通信部１００１から、ユーザプレイン通信部１００３経由で基地局通信部１００２に渡され、１つあるいは複数の基地局７２へ送信される。基地局７２から受信したデータがユーザデータであった場合、ユーザデータは、基地局通信部１００２から、ユーザプレイン通信部１００３経由でＰＤＮ　ＧＷ通信部１００１に渡され、ＰＤＮ　ＧＷへ送信される。

　ＰＤＮ　ＧＷから受信したデータが制御データであった場合、制御データは、ＰＤＮ　ＧＷ通信部１００１から制御プレイン制御部１００５へ渡される。基地局７２から受信したデータが制御データであった場合、制御データは、基地局通信部１００２から制御プレイン制御部１００５へ渡される。

　ＨｅＮＢＧＷ通信部１００４は、ＨｅＮＢＧＷ７４が存在する場合に設けられ、情報種別によって、ＭＭＥ７３ａとＨｅＮＢＧＷ７４との間のインタフェース（ＩＦ）によるデータの送受信を行う。ＨｅＮＢＧＷ通信部１００４から受信した制御データは、ＨｅＮＢＧＷ通信部１００４から制御プレイン制御部１００５へ渡される。制御プレイン制御部１００５での処理の結果は、ＰＤＮ　ＧＷ通信部１００１経由でＰＤＮ　ＧＷへ送信される。また、制御プレイン制御部１００５で処理された結果は、基地局通信部１００２経由でＳ１インタフェースにより１つあるいは複数の基地局７２へ送信され、またＨｅＮＢＧＷ通信部１００４経由で１つあるいは複数のＨｅＮＢＧＷ７４へ送信される。

　制御プレイン制御部１００５には、ＮＡＳセキュリティ部１００５－１、ＳＡＥベアラコントロール部１００５－２、アイドルステート（Idle State）モビリティ管理部１００５－３などが含まれ、制御プレインに対する処理全般を行う。ＮＡＳセキュリティ部１００５－１は、ＮＡＳ（Non-Access Stratum）メッセージのセキュリティなどを行う。ＳＡＥベアラコントロール部１００５－２は、ＳＡＥ（System Architecture Evolution）のベアラの管理などを行う。アイドルステートモビリティ管理部１００５－３は、待受け状態（アイドルステート（Idle State）；ＬＴＥ－ＩＤＬＥ状態、または、単にアイドルとも称される）のモビリティ管理、待受け状態時のページング信号の生成および制御、傘下の１つあるいは複数の移動端末７１のトラッキングエリアの追加、削除、更新、検索、トラッキングエリアリスト管理などを行う。

　ＭＭＥ７３ａは、１つまたは複数の基地局７２に対して、ページング信号の分配を行う。また、ＭＭＥ７３ａは、待受け状態（Idle State）のモビリティ制御（Mobility control）を行う。ＭＭＥ７３ａは、移動端末が待ち受け状態のとき、および、アクティブ状態（Active State）のときに、トラッキングエリア（Tracking Area）リストの管理を行う。ＭＭＥ７３ａは、ＵＥが登録されている（registered）追跡領域（トラッキングエリア：Tracking Area）に属するセルへ、ページングメッセージを送信することで、ページングプロトコルに着手する。ＭＭＥ７３ａに接続されるＨｏｍｅ－ｅＮＢ７５のＣＳＧの管理およびＣＳＧ－ＩＤの管理、そしてホワイトリスト管理は、アイドルステートモビリティ管理部１００５－３で行われてもよい。

　次に通信システムにおけるセルサーチ方法の一例を示す。図６は、ＬＴＥ方式の通信システムにおいて移動端末（ＵＥ）が行うセルサーチから待ち受け動作までの概略を示すフローチャートである。移動端末は、セルサーチを開始すると、ステップＳＴ１で、周辺の基地局から送信される第一同期信号（Ｐ－ＳＳ）、および第二同期信号（Ｓ－ＳＳ）を用いて、スロットタイミング、フレームタイミングの同期をとる。

　Ｐ－ＳＳとＳ－ＳＳとを合わせて、同期信号（ＳＳ）という。同期信号（ＳＳ）には、セル毎に割り当てられたＰＣＩに１対１に対応するシンクロナイゼーションコードが割り当てられている。ＰＣＩの数は５０４通りが検討されている。この５０４通りのＰＣＩを用いて同期をとるとともに、同期がとれたセルのＰＣＩを検出（特定）する。

　次に同期がとれたセルに対して、ステップＳＴ２で、基地局からセル毎に送信される参照信号（リファレンスシグナル：ＲＳ）であるセル固有参照信号（Cell-specific Reference Signal：ＣＲＳ）を検出し、ＲＳの受信電力（Reference Signal Received Power：ＲＳＲＰ）の測定を行う。参照信号（ＲＳ）には、ＰＣＩと１対１に対応したコードが用いられている。そのコードで相関をとることによって他セルと分離できる。ステップＳＴ１で特定したＰＣＩから、該セルのＲＳ用のコードを導出することによって、ＲＳを検出し、ＲＳの受信電力を測定することが可能となる。

　次にステップＳＴ３で、ステップＳＴ２までで検出された一つ以上のセルの中から、ＲＳの受信品質が最もよいセル、例えば、ＲＳの受信電力が最も高いセル、つまりベストセルを選択する。

　次にステップＳＴ４で、ベストセルのＰＢＣＨを受信して、報知情報であるＢＣＣＨを得る。ＰＢＣＨ上のＢＣＣＨには、セル構成情報が含まれるＭＩＢ（Master Information Block）がマッピングされる。したがってＰＢＣＨを受信してＢＣＣＨを得ることで、ＭＩＢが得られる。ＭＩＢの情報としては、例えば、ＤＬ（ダウンリンク）システム帯域幅（送信帯域幅設定（transmission bandwidth configuration：dl-bandwidth）とも呼ばれる）、送信アンテナ数、ＳＦＮ（System Frame Number）などがある。

　次にステップＳＴ５で、ＭＩＢのセル構成情報をもとに該セルのＤＬ－ＳＣＨを受信して、報知情報ＢＣＣＨの中のＳＩＢ（System Information Block）１を得る。ＳＩＢ１には、該セルへのアクセスに関する情報、セルセレクションに関する情報、他のＳＩＢ（ＳＩＢｋ；ｋ≧２の整数）のスケジューリング情報が含まれる。また、ＳＩＢ１には、トラッキングエリアコード（Tracking Area Code：ＴＡＣ）が含まれる。

　次にステップＳＴ６で、移動端末は、ステップＳＴ５で受信したＳＩＢ１のＴＡＣと、移動端末が既に保有しているトラッキングエリアリスト内のトラッキングエリア識別子（Tracking Area Identity：ＴＡＩ）のＴＡＣ部分とを比較する。トラッキングエリアリストは、ＴＡＩリスト（TAI list）とも称される。ＴＡＩはトラッキングエリアを識別するための識別情報であり、ＭＣＣ（Mobile Country Code）と、ＭＮＣ（Mobile Network Code）と、ＴＡＣ（Tracking Area Code）とによって構成される。ＭＣＣは国コードである。ＭＮＣはネットワークコードである。ＴＡＣはトラッキングエリアのコード番号である。

　移動端末は、ステップＳＴ６で比較した結果、ステップＳＴ５で受信したＴＡＣがトラッキングエリアリスト内に含まれるＴＡＣと同じならば、該セルで待ち受け動作に入る。比較して、ステップＳＴ５で受信したＴＡＣがトラッキングエリアリスト内に含まれなければ、移動端末は、該セルを通して、ＭＭＥなどが含まれるコアネットワーク（Core Network，ＥＰＣ）へ、ＴＡＵ（Tracking Area Update）を行うためにトラッキングエリアの変更を要求する。

　コアネットワークを構成する装置（以下「コアネットワーク側装置」という場合がある）は、ＴＡＵ要求信号とともに移動端末から送られてくる該移動端末の識別番号（ＵＥ－ＩＤなど）をもとに、トラッキングエリアリストの更新を行う。コアネットワーク側装置は、移動端末に更新後のトラッキングエリアリストを送信する。移動端末は、受信したトラッキングエリアリストに基づいて、移動端末が保有するＴＡＣリストを書き換える（更新する）。その後、移動端末は、該セルで待ち受け動作に入る。

　スマートフォンおよびタブレット端末の普及によって、セルラー系無線通信によるトラフィックが爆発的に増大しており、世界中で無線リソースの不足が懸念されている。これに対応して周波数利用効率を高めるために、小セル化し、空間分離を進めることが検討されている。

　従来のセルの構成では、ｅＮＢによって構成されるセルは、比較的広い範囲のカバレッジを有する。従来は、複数のｅＮＢによって構成される複数のセルの比較的広い範囲のカバレッジによって、あるエリアを覆うように、セルが構成されている。

　小セル化された場合、ｅＮＢによって構成されるセルは、従来のｅＮＢによって構成されるセルのカバレッジに比べて範囲が狭いカバレッジを有する。したがって、従来と同様に、あるエリアを覆うためには、従来のｅＮＢに比べて、多数の小セル化されたｅＮＢが必要となる。

　以下の説明では、従来のｅＮＢによって構成されるセルのように、カバレッジが比較的大きいセルを「マクロセル」といい、マクロセルを構成するｅＮＢを「マクロｅＮＢ」という。また、小セル化されたセルのように、カバレッジが比較的小さいセルを「スモールセル」といい、スモールセルを構成するｅＮＢを「スモールｅＮＢ」という。

　マクロｅＮＢは、例えば、非特許文献８に記載される「ワイドエリア基地局（Wide Area Base Station）」であってもよい。

　スモールｅＮＢは、例えば、ローパワーノード、ローカルエリアノード、ホットスポットなどであってもよい。また、スモールｅＮＢは、ピコセルを構成するピコｅＮＢ、フェムトセルを構成するフェムトｅＮＢ、ＨｅＮＢ、ＲＲＨ（Remote Radio Head）、ＲＲＵ（Remote Radio Unit）、ＲＲＥ（Remote Radio Equipment）またはＲＮ（Relay Node）であってもよい。また、スモールｅＮＢは、非特許文献８に記載される「ローカルエリア基地局（Local Area Base Station）」または「ホーム基地局（Home Base Station）」であってもよい。

　図７は、マクロｅＮＢとスモールｅＮＢとが混在する場合のセルの構成の概念を示す図である。マクロｅＮＢによって構成されるマクロセルは、比較的広い範囲のカバレッジ１３０１を有する。スモールｅＮＢによって構成されるスモールセルは、マクロｅＮＢによって構成されるマクロセルのカバレッジ１３０１に比べて範囲が小さいカバレッジ１３０２を有する。

　複数のｅＮＢが混在する場合、あるｅＮＢによって構成されるセルのカバレッジが、他のｅＮＢによって構成されるセルのカバレッジ内に含まれる場合がある。図７に示すセルの構成では、参照符号「１３０４」または「１３０５」で示されるように、スモールｅＮＢによって構成されるスモールセルのカバレッジ１３０２が、マクロｅＮＢによって構成されるマクロセルのカバレッジ１３０１内に含まれる場合がある。

　また、参照符号「１３０５」で示されるように、複数、例えば２つのスモールセルのカバレッジ１３０２が、１つのマクロセルのカバレッジ１３０１内に含まれる場合もある。移動端末（ＵＥ）１３０３は、例えばスモールセルのカバレッジ１３０２内に含まれ、スモールセルを介して通信を行う。

　また図７に示すセルの構成では、参照符号「１３０６」で示されるように、マクロｅＮＢによって構成されるマクロセルのカバレッジ１３０１と、スモールｅＮＢによって構成されるスモールセルのカバレッジ１３０２とが複雑に重複する場合が生じる。

　また、参照符号「１３０７」で示されるように、マクロｅＮＢによって構成されるマクロセルのカバレッジ１３０１と、スモールｅＮＢによって構成されるスモールセルのカバレッジ１３０２とが重複しない場合も生じる。

　さらには、参照符号「１３０８」で示されるように、多数のスモールｅＮＢによって構成される多数のスモールセルのカバレッジ１３０２が、１つのマクロｅＮＢによって構成される１つのマクロセルのカバレッジ１３０１内に構成される場合も生じる。

　図８および図９は、本発明の実施の形態１の通信システムにおけるｅＮＢのカバレッジの一例を示す図である。図８および図９では、デュアルコネクティビティ中のＵＥ５７がマクロセル５１，５３間でＨＯを行う場合を示す。

　以下の説明では、デュアルコネクティビティを行うマクロセルを「マスターセル」といい、マスターセルを構成するｅＮＢを「マスターｅＮＢ（略称：ＭｅＮＢ）」という場合がある。また、ＨＯ元のＭｅＮＢを「ソースＭｅＮＢ（略称：Ｓ－ＭｅＮＢ）」といい、ＨＯ先のＭｅＮＢを「ターゲットＭｅＮＢ（略称：Ｔ－ＭｅＮＢ）」という場合がある。

　また、デュアルコネクティビティを行うスモールセルを「セカンダリセル」といい、セカンダリセルを構成するｅＮＢを「セカンダリｅＮＢ（略称：ＳｅＮＢ）」という場合がある。

　図８および図９では、Ｓ－ＭｅＮＢを参照符号「５１」で示し、Ｓ－ＭｅＮＢ５１のカバレッジを参照符号「５２」で示す。また、Ｔ－ＭｅＮＢを参照符号「５３」で示し、Ｔ－ＭｅＮＢ５３のカバレッジを参照符号「５４」で示す。また、ＳｅＮＢを参照符号「５５」で示し、ＳｅＮＢ５５のカバレッジを参照符号「５６」で示す。

　図９では、図８に示すＳｅＮＢ５５に加えて、もう１つのＳｅＮＢ５８が存在する場合を示す。図９では、図８に示すＳｅＮＢ５５を、移動元のＳｅＮＢ（以下「移動元ＳｅＮＢ」という場合がある）５５とし、もう１つのＳｅＮＢを、移動先のＳｅＮＢ（以下「移動先ＳｅＮＢ」という場合がある）５８とする。また、図９において、参照符号「５６」は移動元ＳｅＮＢ５５のカバレッジを示し、参照符号「５９」は移動先ＳｅＮＢ５８のカバレッジを示す。

　本実施の形態では、図８および図９に示すＵＥ５７の移動によって、ＵＥ５７の周辺セルのメジャメントにおいてＳ－ＭｅＮＢ５１の受信品質が劣化し、Ｔ－ＭｅＮＢ５３の受信品質が改善しているというメジャメント報告が行われる場合について説明する。

　図１０は、本発明の実施の形態１の通信システムにおけるハンドオーバ関連処理のシーケンスの一例を示す図である。図１１は、図１０のステップＳＴ９０８のＨＯ前処理のシーケンスの一例を示す図である。図１２は、図１０のステップＳＴ９２８のＨＯ処理のシーケンスの一例を示す図である。図１３は、図１０のステップＳＴ９４９のＨＯ後処理のシーケンスの一例を示す図である。ここで、ハンドオーバ関連処理とは、ハンドオーバ（ＨＯ）に関連する処理をいい、ＨＯ前処理、ＨＯ処理およびＨＯ後処理を含む。

　本実施の形態では、非特許文献１１に記載されるデュアルコネクティビティのユーザプレインアーキテクチャの選択肢１Ａ（Alternative 1A）の場合（非特許文献１１　８．１．１．１参照）において、デュアルコネクティビティ中のＵＥがマクロセル間のＨＯを行う方法について開示する。

　ユーザプレインアーキテクチャの選択肢１Ａでは、Ｓ－ＧＷからＭｅＮＢを介して通信を行うパス（以下「ＭｅＮＢ経由パス」という場合がある）と、Ｓ－ＧＷからスモールセルであるＳｅＮＢを介して通信を行うパス（以下「ＳｅＮＢ経由パス」という場合がある）とにおいて、通信が行われる。ＭｅＮＢ経由パスは、ベアラ１を用いるパスであり、例えばステップＳＴ９０２およびステップＳＴ９０３において、パケットデータの通信に用いられる。ＳｅＮＢ経由パスは、ベアラ２を用いるパスであり、例えばステップＳＴ９０４およびステップＳＴ９０５において、パケットデータの通信に用いられる。

　ＭｅＮＢが、デュアルコネクティビティ中のＵＥに対して、メジャメント制御メッセージを通知する方法を以下に開示する。

　図１０に示す例では、ステップＳＴ９０１において、Ｓ－ＭｅＮＢは、ＵＥにメジャメント制御（Measurement Control）メッセージを通知する。該メジャメント制御メッセージに、周辺のＳｅＮＢのメジャメントを設定してもよい。あるいは、ＳｅＮＢ用の周波数のメジャメントを設定してもよい。また、メジャメントの設定として、ＭｅＮＢとは別に、ＳｅＮＢ用またはＳｅＮＢ用の周波数におけるイベント、もしくはイベントのクライテリアを設定してもよい。

　設定パラメータとしては、ＳｅＮＢの識別子、周波数、報告のためのイベント番号、受信品質の閾値、測定期間などがある。受信品質としては、ＲＳＲＰ（Reference Signal Received Power）、ＲＳＲＱ（Reference Signal Received Quality）などがある。

　ステップＳＴ９０１においてメジャメント制御メッセージを受信したＵＥは、周辺セル（ＭｅＮＢおよびＳｅＮＢ）のメジャメントを行う。

　ステップＳＴ９０６において、ＵＥは、Ｓ－ＭｅＮＢにメジャメント報告（Measurement Report）メッセージを通知する。ステップＳＴ９０６においてメジャメント報告メッセージを受信したＳ－ＭｅＮＢは、ステップＳＴ９０７において、メジャメント報告の結果を用いて、ＵＥをＴ－ＭｅＮＢにハンドオーバ（ＨＯ）させるか否かを決定する。図１０に示す例では、Ｓ－ＭｅＮＢは、ステップＳＴ９０７において、ＵＥをＴ－ＭｅＮＢにＨＯさせることを決定する。

　Ｓ－ＭｅＮＢがステップＳＴ９０７においてＵＥをＴ－ＭｅＮＢにＨＯさせることを決定すると、ステップＳＴ９０８に移行し、ステップＳＴ９０８において、図１１に示すＨＯ前処理であるＳｅＮＢリリース処理が実行される。

　Ｓ－ＭｅＮＢは、具体的には、図１０のステップＳＴ９０７において、ＵＥをＴ－ＭｅＮＢにＨＯさせることを決定すると、図１１のステップＳＴ９０９に移行する。

　ステップＳＴ９０９において、Ｓ－ＭｅＮＢは、ＳｅＮＢにＳｅＮＢリリース要求（SeNB Release Request）メッセージを通知する。ステップＳＴ９０９においてＳｅＮＢリリース要求メッセージを受信したＳｅＮＢは、ステップＳＴ９１０において、ＳｅＮＢリリース応答（SeNB Release Response）メッセージをＳ－ＭｅＮＢに通知する。

　ステップＳＴ９１１において、Ｓ－ＭｅＮＢは、ＵＥに、ＲＲＣに関する情報としてＲＲＣ接続再構成（RRC Connection Reconfiguration）メッセージを通知する。

　ステップＳＴ９１２において、ＳｅＮＢは、Ｓ－ＭｅＮＢに、ＰＤＣＰのシーケンス番号（Sequence Number；略称：ＳＮ）の状況を伝達するＳＮ状況伝達（SN Status Transfer）を行う。具体的には、ＳｅＮＢは、Ｓ－ＭｅＮＢに、ＰＤＣＰのＳＮ情報を通知する。また、ステップＳＴ９１３において、ＳｅＮＢは、Ｓ－ＭｅＮＢに、送信が完了していないデータを転送するデータ転送（Data Forwarding）を行って、ロスのない通信を確立してもよい。

　また、ベアラの種別、サービス品質（Quality of Service；略称：ＱｏＳ）、接続先のセルのバックホールで発生する遅延時間、転送回数（転送したデータの再転送）に応じて、転送の有無、ＳＮのリオーダリング（reordering）の有無を判断してもよい。例えば、ＶｏＩＰ（Voice over Internet Protocol）などの音声データのようにデータロスが発生しても問題がないサービスについては、転送を行わない、あるいは、リオーダリングを行わない。また、例えば、ハンドオーバ中のハンドオーバで転送データの再転送になるときには転送を行わない。また、例えば、リアルタイム性を要するサービスの場合には、接続先のセルのバックホールで発生する遅延時間が大きいときには転送を行わない。以上のようにすることによって、リソースリリースを速やかに行うことができ、安定した動作を提供することができる。

　ステップＳＴ９１４において、Ｓ－ＭｅＮＢは、ＳｅＮＢから転送されたデータをバッファに記憶する。

　ステップＳＴ９１５において、ＵＥは、Ｓ－ＭｅＮＢにＲＲＣ接続再構成完了（RRC Connection Reconfiguration Complete）メッセージを通知する。これによって、Ｓ－ＭｅＮＢとＵＥとの間でＲＲＣの設定および無線同期が完了すると、ステップＳＴ９１６において、ＵＥとＳ－ＭｅＮＢとの間で通信が開始されるとともに、ステップＳＴ９１７において、ＵＥとＳ－ＧＷとの間で通信が開始される。

　ステップＳＴ９１８において、Ｓ－ＭｅＮＢは、ＭＭＥに、パスの切替えを要求するパススイッチ要求（Path Switch Request）メッセージを通知する。パススイッチ要求メッセージを通知されたＭＭＥは、ステップＳＴ９１９において、Ｓ－ＧＷに、ベアラの変更を要求するベアラ変更要求（Modify Bearer Request）メッセージを通知する。

　ステップＳＴ９１８、あるいは、ステップＳＴ９１９では、ＳｅＮＢの変更の有無を示す情報が付与されていてもよい。または、ＵＥのＨＯによるパススイッチ要求あるいはベアラ変更要求でないことを示す情報が付与されていてもよい。または、ＨＯ対象のＵＥを識別する情報が付与されないことによって、ＵＥのＨＯによるパススイッチ要求あるいはベアラ変更要求でないことを示すようにしてもよい。

　これによって、ＭＭＥ、あるいは、Ｓ－ＧＷ、あるいは、別途設けている位置登録管理機能部において、通常のＨＯ処理と異なり、ＵＥの位置情報の更新処理、位置情報の更新に伴う無線リソースの管理処理を省くことができる。

　ベアラ変更要求メッセージを通知されたＳ－ＧＷは、ステップＳＴ９２０において、通信に使用していたベアラ２の送信先を、ＳｅＮＢから、Ｓ－ＭｅＮＢに変更する。また、このとき、Ｓ－ＭｅＮＢのユーザの収容状況を考慮して、Ｓ－ＭｅＮＢ経由パス用にベアラを変更してもよい。

　ステップＳＴ９２４において、Ｓ－ＧＷは、ＭＭＥに、ベアラの変更要求に応じたことを表すベアラ変更応答（Modify Bearer Response）メッセージを通知する。ベアラ変更応答メッセージを通知されたＭＭＥは、ステップＳＴ９２５において、Ｓ－ＭｅＮＢに、パスの切替え要求を受諾したことを表すパススイッチ要求受諾応答（Path Switch Request Ack）メッセージを通知する。

　このように、Ｓ－ＭｅＮＢは、図１０のステップＳＴ９０２、ステップＳＴ９０３、図１１のステップＳＴ９１６およびステップＳＴ９２２において、同一のＵＥに対して、ベアラ１およびベアラ２という２つのベアラを送受信する。

　このとき、Ｓ－ＧＷは、ステップＳＴ９２１において、ＳｅＮＢに送信するＰＤＣＰにエンドマーカ（End Marker）を付与して転送処理の終了を伝えてもよい。これによって、ＳｅＮＢは、転送データの終わりを認識することができるので、転送バッファを無駄のないタイミングでリリースすることが可能となる。

　また、ＳｅＮＢは、ステップＳＴ９２３において、エンドマーカを付与してＳ－ＭｅＮＢに転送してもよい。これによって、Ｓ－ＭｅＮＢが転送受け付けバッファを無駄のないタイミングでリリースすることが可能となる。

　ステップＳＴ９２６において、Ｓ－ＭｅＮＢは、ＳｅＮＢに、ＵＥコンテキストを解放（リリース）するように指示するＵＥコンテキスト解放（ＵＥ context release）メッセージを通知する。Ｓ－ＭｅＮＢは、ステップＳＴ９２３でエンドマーカを通知された場合は、ステップＳＴ９２６において、ＳｅＮＢにＵＥコンテキスト解放メッセージを通知することに加えて、ＳｅＮＢに、エンドマーカを受けたことを通知する。このようにＳｅＮＢにＵＥコンテキスト解放メッセージ、またはエンドマーカを受けたことを通知することによって、ＳｅＮＢは、ステップＳＴ９２７において、ＵＥの管理情報をリリースすることができる。

　エンドマーカは、ベアラの種別、またはＱｏＳに応じて、エンドマーカの付与の有無を判断されてもよい。ＶｏＩＰなどの音声データのようにデータロスが発生しても問題がないサービスについては、エンドマーカを付与しなくても、リソースを解放することによって、リソースの管理を速やかに行うことができ、安定した動作を提供することができるという効果を得ることができる。

　図８に示すように、ＵＥ５７が移動して、Ｓ－ＭｅＮＢ５１のカバレッジ５２の境界に近づくと、前述の図１０のステップＳＴ９０７において、Ｓ－ＭｅＮＢ５１が、ＵＥ５７のメジャメント報告に基づいて、Ｔ－ＭｅＮＢ５３にＨＯすると決定する。このとき、通信中のＳｅＮＢ５５のメジャメント値も良好になる。

　Ｓ－ＭｅＮＢ５１は、ＳｅＮＢ５５のメジャメント値が良好なときは、ＨＯ後もＳｅＮＢ５５のカバレッジ５６内にＵＥ５７が存在すると判断する。そして、図１１のステップＳＴ９０９において、ＳｅＮＢ５５に通知するリリース要求メッセージに、リソース保留指示情報、あるいは、リソースを保留できるＩＤを付与して通知してもよい。

　これによって、ＳｅＮＢ５５は、設定していたＲＲＣに関する設定または情報、無線同期に関する設定または情報をリリースせず、Ｔ－ＭｅＮＢ５３にＨＯした後、Ｔ－ＭｅＮＢ５３からＳｅＮＢ５５にデュアルコネクティビティの再設定をするときのリソース確保処理、再同期処理を削減することができる。

　ステップＳＴ９２７のＳｅＮＢによるＵＥの管理情報のリリース後は、図１０のステップＳＴ９２８において、Ｓ－ＭｅＮＢからＴ－ＭｅＮＢへのハンドオーバ処理が行われる。これによって、２つのベアラはともに、Ｓ－ＭｅＮＢからＴ－ＭｅＮＢに切り替えられる。

　ステップＳＴ９２８のハンドオーバ処理は、具体的には、図１２に示すようにして実行される。ステップＳＴ９２９において、Ｓ－ＭｅＮＢは、ハンドオーバ要求（Handover Request）メッセージを、ＨＯ先であるＴ－ＭｅＮＢに通知する。ＨＯ要求メッセージには、ＨＯを行うＥ－ＲＡＢ（E-UTRAN Radio Access Bearer）情報が含まれる。

　ステップＳＴ９３０において、Ｔ－ＭｅＮＢは、収容キャパシティを確認するアドミッション制御を行う。Ｔ－ＭｅＮＢは、アドミッション制御の結果に基づいて、ＨＯを受付可能であると判断すると、ステップＳＴ９３１において、Ｓ－ＭｅＮＢにＨＯ要求受諾応答（Handover Request Ack）メッセージを通知する。

　ステップＳＴ９３１のＨＯ要求応答可メッセージを受けて、Ｓ－ＭｅＮＢは、ステップＳＴ９３２において、ＵＥに、モビリティ制御情報を含むＲＲＣ接続再構成（RRC Connection Reconfiguration）メッセージを通知する。

　ステップＳＴ９３３において、Ｓ－ＭｅＮＢは、Ｔ－ＭｅＮＢに対して、ＳＮ状況伝達（SN Status Transfer）を行う。具体的には、Ｓ－ＭｅＮＢは、Ｔ－ＭｅＮＢにＰＤＣＰのＳＮ情報を通知する。

　ステップＳＴ９３４において、Ｓ－ＭｅＮＢは、Ｔ－ＭｅＮＢに、送信が完了していないデータを転送するデータ転送（Data Forwarding）を行ってもよい。ステップＳＴ９３５において、Ｔ－ＭｅＮＢは、Ｓ－ＭｅＮＢから転送されたデータをバッファに記憶する。

　ステップＳＴ９３６において、ＵＥは、無線設定を完了し、Ｔ－ＭｅＮＢに、ＲＲＣ接続再構成完了（RRC Connection Reconfiguration Complete）メッセージを通知する。このようにして無線設定が完了すると、ステップＳＴ９３７において、ＵＥとＴ－ＭｅＮＢとの間で通信が開始されるとともに、ステップＳＴ９３８において、ＵＥとＳ－ＧＷとの間で通信が開始される。

　ステップＳＴ９３９において、Ｔ－ＭｅＮＢは、ＭＭＥに、パススイッチ要求（Path Switch Request）メッセージを通知する。パススイッチ要求メッセージを通知されたＭＭＥは、ステップＳＴ９４０において、Ｓ－ＧＷに、ベアラ変更要求（Modify Bearer Request）メッセージを通知する。

　ステップＳＴ９３９、あるいは、ステップＳＴ９４０では、ＳｅＮＢの変更の有無を示す情報が付与されていてもよい。または、ＵＥのＨＯによるパススイッチ要求あるいはベアラ変更要求であることを示す情報が付与されていてもよい。または、ＨＯ対象のＵＥを識別する情報が付与されることによって、ＵＥのＨＯによるパススイッチ要求あるいはベアラ変更要求であることを示すようにしてもよい。または、従来のパススイッチ要求あるいはベアラ変更要求とすることによって、従来のＵＥのＨＯであることを示すようにしてもよい。

　これによって、ＭＭＥ、あるいは、Ｓ－ＧＷ、あるいは、別途設けている位置登録管理機能部において、通常のＨＯ処理として、ＵＥの位置情報の更新処理、位置情報の更新に伴う無線リソース管理処理を行うことができる。

　ベアラ変更要求メッセージを通知されたＳ－ＧＷは、ステップＳＴ９４１において、通信に使用していたベアラ２の送信先を、Ｔ－ＭｅＮＢに変更する。また、このとき、Ｔ－ＭｅＮＢのユーザの収容状況を考慮して、Ｔ－ＭｅＮＢ経由パス用にベアラを変更してもよい。

　以上によって、ベアラ１とベアラ２とがＴ－ＭｅＮＢ経由に設定され、ステップＳＴ９３７において、ＵＥとＴ－ＭｅＮＢとの間で通信が行われるとともに、ステップＳＴ９４３において、Ｓ－ＧＷとＴ－ＭｅＮＢとの間で通信が行われる。

　ステップＳＴ９４５において、Ｓ－ＧＷは、ＭＭＥに、ベアラ変更応答（Modify Bearer Response）メッセージを通知する。ベアラ変更応答メッセージを通知されたＭＭＥは、ステップＳＴ９４６において、Ｔ－ＭｅＮＢに、パススイッチ要求受諾応答（Path Switch Request Ack）メッセージを通知する。

　Ｓ－ＧＷは、ロスのない伝送をするために、ステップＳＴ９４２において、Ｓ－ＭｅＮＢへの最終データにエンドマーカを付与してもよい。これによって、Ｓ－ＭｅＮＢは、転送バッファを無駄のないタイミングでリリースできるようになる。

　ステップＳＴ９４４において、Ｓ－ＭｅＮＢは、最終転送データにエンドマーカを付与してもよい。これによって、Ｔ－ＭｅＮＢが、転送受け付けバッファを無駄のないタイミングでリリースすることが可能となる。

　ステップＳＴ９４７において、Ｔ－ＭｅＮＢは、Ｓ－ＭｅＮＢに、ＵＥコンテキスト解放（ＵＥ context release）メッセージを通知する。Ｓ－ＭｅＮＢは、ステップＳＴ９４４でエンドマーカを通知された場合は、ステップＳＴ９４７において、Ｓ－ＭｅＮＢにＵＥコンテキスト解放メッセージを通知することに加えて、Ｓ－ＭｅＮＢに、エンドマーカを受けたことを通知する。このようにＳ－ＭｅＮＢにＵＥコンテキスト解放メッセージ、またはエンドマーカを受けたことを通知することによって、Ｓ－ＭｅＮＢは、ステップＳＴ９４８において、ＵＥの管理情報をリリースすることができる。

　ステップＳＴ９４８のＳ－ＭｅＮＢによるＵＥの管理情報のリリース後は、図１０のステップＳＴ９４９において、ＨＯ後処理であるＳｅＮＢ追加処理が行われる。ステップＳＴ９４９のＳｅＮＢ追加処理は、具体的には、図１３に示すようにして実行される。

　図１０のステップＳＴ９２８のＨＯ処理によるＴ－ＭｅＮＢへの切替え後、Ｔ－ＭｅＮＢは、図１３のステップＳＴ９５０において、ＳｅＮＢに、ＳｅＮＢ追加要求（SeNB Addition Request）メッセージを通知する。

　ステップＳＴ９５１において、ＳｅＮＢは、Ｔ－ＭｅＮＢに、ＳｅＮＢ追加応答（SeNB Addition Response）メッセージを通知する。

　ステップＳＴ９５２において、Ｔ－ＭｅＮＢは、ＵＥに、ＲＲＣに関する情報として、ＲＲＣ接続再構成（RRC Connection Reconfiguration）メッセージを通知する。

　また、ステップＳＴ９５１でＳｅＮＢがＳｅＮＢ追加要求メッセージへの返信として、ＳｅＮＢ追加要求を受け付けたことを表すＳｅＮＢ追加応答メッセージを通知したことを受けて、Ｔ－ＭｅＮＢは、ステップＳＴ９５３において、ＳＮ状況伝達（SN Status Transfer）として、ＳｅＮＢにＰＤＣＰのＳＮ情報を通知する。

　Ｔ－ＭｅＮＢは、ステップＳＴ９５４において、ＳｅＮＢに、送信が完了していないデータを転送するデータ転送（Data Forwarding）を行って、ロスのない通信を確立してもよい。

　Ｔ－ＭｅＮＢは、ベアラの種別、あるいは、ＱｏＳに応じて、データ転送の有無、あるいは、ＳＮのリオーダリングの有無を判断してもよい。ＶｏＩＰなどの音声データのようにデータロスが発生しても問題がないベアラについては、データ転送、またはＳＮのリオーダリングを省くことによって、リソースリリースを速やかに行い、安定した動作を提供することができるという効果を得ることができる。

　ステップＳＴ９５５において、ＳｅＮＢは、Ｔ－ＭｅＮＢから転送されたデータをバッファに記憶する。

　ステップＳＴ９５６において、ＵＥは、無線同期を完了し、Ｔ－ＭｅＮＢに、ＳｅＮＢとＵＥとの間のＲＲＣ接続の再構成が完了したことを表すＲＲＣ接続再構成完了（RRC Connection Reconfiguration Complete）メッセージを通知する。このようにして無線同期が完了すると、ステップＳＴ９５７において、ＵＥとＳｅＮＢとの間で通信が開始されるとともに、ステップＳＴ９５８において、ＵＥとＳ－ＧＷとの間で通信が開始される。

　さらに、ステップＳＴ９５９において、ＳｅＮＢは、無線設定の完了、具体的にはＳｅＮＢの追加が完了したことを表すＳｅＮＢ追加完了メッセージを、Ｔ－ＭｅＮＢに通知する。ＳｅＮＢ追加完了メッセージを通知されたＴ－ＭｅＮＢは、ステップＳＴ９６０において、ＭＭＥに、パススイッチ要求（Path Switch Request）メッセージを通知する。パススイッチ要求メッセージを通知されたＭＭＥは、ステップＳＴ９６１において、Ｓ－ＧＷに、ベアラ変更要求（Modify Bearer Request）メッセージを通知する。

　ステップＳＴ９６０、あるいは、ステップＳＴ９６１では、ＳｅＮＢの変更（追加）の有無を示す情報が付与されていてもよい。または、ＵＥのＨＯによるパススイッチ要求あるいはベアラ変更要求でないことを示す情報が付与されていてもよい。または、ＨＯ対象のＵＥを識別する情報が付与されないことによって、ＵＥのＨＯによるパススイッチ要求あるいはベアラ変更要求でないことを示すようにしてもよい。

　ベアラ変更要求メッセージを通知されたＳ－ＧＷは、ステップＳＴ９６２において、通信に使用していたベアラ２の送信先を、Ｓ－ＭｅＮＢに変更する。また、このとき、ＳｅＮＢのユーザの収容状況を考慮して、ＳｅＮＢ経由パス用にベアラを変更してもよい。

　ステップＳＴ９６６において、Ｓ－ＧＷは、ＭＭＥに、ベアラ変更応答（Modify Bearer Response）メッセージを通知する。ベアラ変更応答メッセージを通知されたＭＭＥは、ステップＳＴ９６７において、Ｔ－ＭｅＮＢに、パスの切替完了を表すパススイッチ要求受諾応答（Path Switch Request Ack）メッセージを通知する。以上によって、ベアラ２がＳｅＮＢ経由に設定され、ステップＳＴ９５７において、ＵＥとＳｅＮＢとの間で通信が行われるとともに、ステップＳＴ９６４において、Ｓ－ＧＷとＳｅＮＢとの間で通信が行われる。ステップＳＴ９６８において、Ｔ－ＭｅＮＢは、ＵＥのベアラ２に対する管理情報をリリースしてもよい。

　このとき、Ｓ－ＧＷは、ステップＳＴ９６３において、Ｔ－ＭｅＮＢに送信するＰＤＣＰにエンドマーカを付与して転送処理の終了を伝えてもよい。これによって、Ｔ－ＭｅＮＢは、転送データの終わりを認識することができるので、転送バッファを無駄のないタイミングでリリースすることが可能となる。

　また、Ｔ－ＭｅＮＢは、ステップＳＴ９６５において、エンドマーカを付与してＳｅＮＢに転送してもよい。これによって、ＳｅＮＢが転送バッファを無駄のないタイミングでリリースすることが可能となる。

　前述の図９に示すように、ＵＥ５７が移動して、Ｓ－ＭｅＮＢ５１のカバレッジ５２の境界に近づき、移動元ＳｅＮＢ５５をリリースし、Ｓ－ＭｅＮＢ５１からＴ－ＭｅＮＢ５３へのＨＯを実行した後、ＳｅＮＢ５８を追加する。このとき、Ｔ－ＭｅＮＢ５３は、図１０のステップＳＴ９０６において通知されるメジャメント報告に加えて、ＵＥ５７の移動方向情報、あるいは、ＵＥ５７の移動速度情報、あるいは、周辺ＳｅＮＢの位置情報（各ＳｅＮＢのＧＰＳ情報、あるいは、各ＳｅＮＢがどのＭｅＮＢに近いかを表す情報）、あるいは、移動先のＳｅＮＢのセルサイズ（セルサイズに相当するＳｅＮＢの最大送信電力値でもよい）、あるいは、当該ＵＥがＳｅＮＢのＣＳＧ（Closed Subscriber Group）に含まれるかどうかの情報、あるいは、これらの組合せによって、追加するＳｅＮＢ５８を決定してもよい。ＵＥと記載したが、複数のＵＥをまとめているモバイルルータであってもよい。これらの判断結果として、ＨＯ後に追加するＳｅＮＢを指定するＳｅＮＢ指定情報を、図１２のステップＳＴ９２９において通知されるＨＯ要求メッセージに追加してもよい。

　例えば、ＵＥが電車に乗っている場合、当該ＵＥのメジャメント情報において、通信中のＳｅＮＢに対するメジャメント値が、移動先ＳｅＮＢより良好であっても、移動先ＳｅＮＢが通信可能な品質で、位置情報から移動先ＳｅＮＢがＴ－ＭｅＮＢのカバレッジ内であることが分かると、移動先ＳｅＮＢを追加することによって、デュアルコネクティビティ処理を軽減することができる。すなわち、移動元ＳｅＮＢを追加後、当該ＵＥが高速で移動することによって、即座に移動元ＳｅＮＢをリリースして、移動先ＳｅＮＢを追加することによる処理の増加を防ぐことができる。

　また、例えば、移動元ＳｅＮＢにおいて、ＣＳＧで通信しているときに、人体などのシャドーイングで誤って移動先ＳｅＮＢが一時的に良好であっても、ＣＳＧで通信していること、あるいは、移動速度が遅いことによって、移動元ＳｅＮＢを追加する。これによって、継続して安定した通信を行うことできる。

　以上のように本実施の形態では、ＵＥが１つのマクロセルと１つのスモールセルとに接続されて、デュアルコネクティビティを行うとき、ＵＥの移動に伴って、ＵＥが接続されるマクロセルを、移動元のマクロセルであるＳ－ＭｅＮＢから、移動先のマクロセルであるＴ－ＭｅＮＢに切替えるＨＯ処理の前に、ＨＯ前処理が行われ、ＨＯ処理の後に、ＨＯ後処理が行われる。ＨＯ前処理では、スモールセルであるＳｅＮＢがリリースされて、ＳｅＮＢとの接続が解消される。ＨＯ後処理では、ＳｅＮＢが追加されて、ＳｅＮＢとの接続が再度確立される。

　これによって、非特許文献１１に記載されるデュアルコネクティビティのユーザプレインアーキテクチャの選択肢１Ａの場合において、デュアルコネクティビティ中のＵＥがマクロセル間のＨＯを実現することができる。

　実施の形態１　変形例１．
　図１４は、本発明の実施の形態１の変形例１の通信システムにおけるハンドオーバ関連処理のシーケンスの一例を示す図である。図１５は、図１４のステップＳＴ１００９のＨＯ前処理のシーケンスの一例を示す図である。図１６は、図１４のステップＳＴ１０１０のＨＯ後処理のシーケンスの一例を示す図である。本変形例のハンドオーバ関連処理は、前述の図１０～図１３に示す実施の形態１のハンドオーバ関連処理と類似するので、同一のステップについては同一のステップ番号を付して、説明を省略する。

　本実施の形態では、非特許文献１１に記載されるデュアルコネクティビティのユーザプレインアーキテクチャの選択肢３Ｃ（Alternative 3C）の場合（非特許文献１１　８．１．１．８参照）において、デュアルコネクティビティ中のＵＥがマクロセル間のＨＯを行う方法について開示する。

　ユーザプレインアーキテクチャの選択肢３Ｃでは、ＭｅＮＢによって、ＭｅＮＢとＵＥとの間で、直接通信を行うパス（ベアラ１）と、スモールセルを介して通信を行うパスとでベアラ（ベアラ２）が分割されるベアラスプリットが行われる。

　ベアラスプリットの場合、１つのＥＰＳベアラに対応するＥ－ＲＡＢが、Ｓ－ＭｅＮＢで、２つのパスに分離され、Ｓ－ＧＷとＵＥとの間でデータが通信される。一つはステップＳＴ１００１において、Ｓ－ＭｅＮＢとＵＥとの間でデータが直接通信される。もう一つは、ステップＳＴ１００３およびステップＳＴ１００４において、Ｓ－ＭｅＮＢとＵＥとの間でデータがＳｅＮＢを介して通信される。

　Ｓ－ＭｅＮＢとＳ－ＧＷとの間は、ステップＳＴ１００２において、１つのパスでデータが通信される。ＳｅＮＢとＭｅＮＢとの間の通信は、異なるｅＮＢ間で行われる。異なるｅＮＢ間の通信路の通信品質が悪い場合は、データの欠落などが生じる場合がある。このような問題を解決するために、ＳｅＮＢとＭｅＮＢとの間の通信において、送達確認処理を導入するとよい。例えば、再送処理を導入するとよい。このようにすることによって、ＳｅＮＢとＭｅＮＢとの間の通信におけるデータの欠落を低減することが可能となる。

　ベアラスプリットによって、デュアルコネクティビティ中のＵＥがＭｅＮＢ間ＨＯを行う場合について説明する。

　ＵＥの移動によって、メジャメントによるＳ－ＭｅＮＢの受信品質が劣化し、Ｔ－ＭｅＮＢの受信品質が改善し、イベントクライテリアに従ってメジャメント報告を行う場合について説明する。

　本実施の形態では、以下のようにしてＳｅＮＢリリース処理が行われる。図１４のステップＳＴ９０６でＵＥからメジャメント報告を受信したＳ－ＭｅＮＢは、図１５のステップＳＴ９０７において、メジャメント報告の結果を用いて、ＵＥをＴ－ＭｅＮＢへＨＯさせることを決定する。

　Ｓ－ＭｅＮＢは、ＵＥをＴ－ＭｅＮＢへＨＯさせることを決定すると、ステップＳＴ９０９において、ＳｅＮＢに、ＳｅＮＢのリリースを要求するＳｅＮＢリリース要求（SeNB Release Request）メッセージを送信する。また、Ｓ－ＭｅＮＢは、ステップＳＴ９１１において、ＵＥに、ＲＲＣに関する情報として、ＲＲＣ接続再設立要求メッセージを送信する。これによって、Ｓ－ＭｅＮＢは、ベアラ２のベアラスプリットをやめて、ステップＳＴ９１６およびステップＳＴ９１７において、直接ＵＥに対してベアラ２を送受信する。

　ＳｅＮＢのリリース後は、図１４のステップＳＴ９２８において、Ｓ－ＭｅＮＢからＴ－ＭｅＮＢへのハンドオーバ（ＨＯ）処理を行う。ステップＳＴ９２８のＨＯ処理は、前述の図１２に示すＨＯ処理と同様にして実行される。このＨＯ処理によって、２つのベアラはともに、Ｓ－ＭｅＮＢからＴ－ＭｅＮＢに切り替えられる。

　Ｔ－ＭｅＮＢへの切替え後、図１４のステップＳＴ１０１０のＨＯ後処理が実行される。具体的には、図１６のステップＳＴ９５０において、Ｔ－ＭｅＮＢは、ＳｅＮＢに追加要求メッセージを通知し、ステップＳＴ９５２において、ＵＥに、通信を行うためのＲＲＣに関する情報を通知する。以上によって、ベアラ２をベアラスプリットする。

　ベアラスプリットされたベアラ２のうちの一つのベアラは、ステップＳＴ１００５において、Ｔ－ＭｅＮＢとＵＥとの間でデータが直接通信されるときに用いられ、もう一つのベアラは、ステップＳＴ１００７およびステップＳＴ１００８において、Ｔ－ＭｅＮＢとＵＥとの間でデータがＳｅＮＢを介して通信されるときに用いられる。Ｔ－ＭｅＮＢとＳ－ＧＷとの間は、ステップＳＴ１００６において、１つのパスでデータが通信される。このように、ベアラスプリットは、ＭＭＥおよびＳ－ＧＷに、パススイッチ要求を送らずに処理することが可能である。

　以上のように本変形例によれば、非特許文献１１に記載されるデュアルコネクティビティのユーザプレインアーキテクチャの選択肢３Ｃの場合、すなわちマクロセルとＵＥとの間、およびスモールセルとＵＥとの間で、ベアラスプリットされたベアラを用いて通信が行われる場合においても、デュアルコネクティビティ中のＵＥがマクロセル間のＨＯを実現することができる。

　実施の形態２．
　図１７～図１９は、本発明の実施の形態２の通信システムにおけるハンドオーバ関連処理のシーケンスの一例を示す図である。図１７と図１８とは、境界線ＢＬ１で接続されている。図１８と図１９とは、境界線ＢＬ２で接続されている。本実施の形態のハンドオーバ関連処理は、前述の図１０～図１３に示す実施の形態１のハンドオーバ関連処理と類似するので、同一のステップについては同一のステップ番号を付して、説明を省略する。

　本実施の形態では、非特許文献１１に記載されるデュアルコネクティビティのユーザプレインアーキテクチャの選択肢１Ａ（Alternative 1A）の場合（非特許文献１１　８．１．１．１参照）において、ＳｅＮＢをリリースしないでＨＯを行う方法について開示する。

　ユーザプレインアーキテクチャの選択肢１Ａでは、ステップＳＴ９０２およびステップＳＴ９０３において、ベアラ１を用いて、Ｓ－ＧＷからＭｅＮＢを介して通信を行うパスと、ステップＳＴ９０４およびステップＳＴ９０５において、ベアラ２を用いて、Ｓ－ＧＷからスモールセルを介して通信を行うパスとの２つのパスで通信が行われる。

　本実施の形態では、デュアルコネクティビティ中のＵＥがＭｅＮＢ間ＨＯを行う場合、ＳｅＮＢとの接続はリリースされない。すなわち、ＵＥのデュアルコネクティビティを保ったまま、ＭｅＮＢ間のＨＯが行われる。

　ＭｅＮＢが、デュアルコネクティビティ中のＵＥに対してメジャメント制御メッセージを通知する方法を以下に開示する。

　図１７～図１９に示す例では、ステップＳＴ９０１において、Ｓ－ＭｅＮＢは、ＵＥにメジャメント制御メッセージを通知する。該メジャメント制御メッセージに、周辺のＳｅＮＢのメジャメントを設定してもよい。あるいは、ＳｅＮＢ用の周波数のメジャメントを設定してもよい。また、メジャメントの設定として、ＭｅＮＢとは別に、ＳｅＮＢ用あるいはＳｅＮＢ用の周波数におけるイベントあるいはイベントのクライテリアを設定してもよい。

　設定パラメータとして、ＳｅＮＢの識別子、周波数、報告のためのイベント番号、受信品質の閾値、測定期間などがある。受信品質として、ＲＳＲＰ、ＲＳＲＱなどがある。

　ステップＳＴ９０１でメジャメント制御メッセージを受信したＵＥは、ＭｅＮＢおよびＳｅＮＢのメジャメントを行う。

　ここでは、ＵＥの移動によって、メジャメントによるＳ－ＭｅＮＢの受信品質が劣化し、Ｔ－ＭｅＮＢの受信品質が改善し、イベントクライテリアに従ってメジャメント報告を行う場合について説明する。

　ステップＳＴ９０６において、ＵＥは、Ｓ－ＭｅＮＢに対してメジャメント報告を行う。ＵＥからのメジャメント報告に、デュアルコネクティビティに用いているＳｅＮＢの識別子と受信品質を含めてもよい。

　ステップＳＴ９０６でＵＥからメジャメント報告を受信したＳ－ＭｅＮＢは、ステップＳＴ９０７において、メジャメント報告の結果を用いて、ＵＥをＴ－ＭｅＮＢへＨＯさせることを決定する。

　ステップＳＴ１１００において、Ｓ－ＭｅＮＢは、Ｔ－ＭｅＮＢに、ＨＯ要求メッセージを通知する。このＨＯ要求メッセージに、ＳｅＮＢに関する情報（以下「ＳｅＮＢ情報」という場合がある）を含めて通知するとよい。ＳｅＮＢ情報として、例えば、ＳｅＮＢの識別子、ＵＥにおけるＳｅＮＢの受信品質などがある。

　また、ＳｅＮＢのベアラに関する情報（以下「ベアラ情報」という場合がある）として、Ｅ－ＲＡＢ識別子などがある。ＭｅＮＢは、ＳｅＮＢにベアラが複数設定されている場合は、各ベアラに対する識別子を設けてもよい。各ベアラの識別子とベアラ構成に関する情報を関連させて通知するとよい。また、該ＳｅＮＢの識別子と該ベアラの識別子とを関連させて通知してもよい。ベアラ毎に設定されるベアラ構成に関する情報として、例えば、ＱｏＳパラメータ、具体的には、サービス品質クラス識別子（QoS Class Identifier；略称：ＱＣＩ）、割当ておよび保持優先度（Allocation and Retention Priority；略称：ＡＲＰ）、帯域保証サービス品質情報（Guaranteed Bit Rate QoS Information）などがある。

　このようにすることによって、ベアラ毎の設定が可能になり、Ｓ－ＭｅＮＢは、Ｔ－ＭｅＮＢに対して、ＳｅＮＢの使用しているベアラ設定を通知することが可能となる。Ｔ－ＭｅＮＢは、ＳｅＮＢのベアラ毎のベアラ設定を取得することが可能となり、ベアラ毎の変更が必要か否かの判断が可能となる。ベアラ設定は、ＳｅＮＢのベアラ情報に関する情報を関連させて通知するとよい。

　ＲＲＣに関する設定情報として、例えば、ＲＲＣコンテキスト（RRC context）がある。ＲＲＣコンテキストには、例えば、無線リソースの構成を示すＡＳ（Access Stratum）構成（AS configuration）、無線リソース管理（Radio Resource Management；略称：ＲＲＭ）情報を示すＲＲＭ構成（RRM configuration）などがある。

　ＲＲＣに関する情報は、ＭｅＮＢのためのＲＲＣに関する情報およびＳｅＮＢのためのＲＲＣに関する情報がある。各ＲＲＣに関する情報を識別可能とするとよい。例えば、ＭｅＮＢのためのＲＲＣコンテキストとＳｅＮＢのためのＲＲＣコンテキストとを別々に作成する。あるいは、１つのＲＲＣコンテキストの中に、ＭｅＮＢのための情報とＳｅＮＢのための情報とを別々に作成してもよい。

　このようにすることによって、ＳｅＮＢのためのＲＲＣに関する情報とＭｅＮＢのためのＲＲＣに関する情報とを個別に設定可能にし、Ｓ－ＭｅＮＢはＴ－ＭｅＮＢに対してＭｅＮＢとＳｅＮＢ、各々のＲＲＣに関する情報を通知することが可能となる。Ｔ－ＭｅＮＢは、Ｓ－ＭｅＮＢとＳｅＮＢ、各々のＲＲＣに関する情報を取得することが可能となり、Ｔ－ＭｅＮＢは、ＳｅＮＢのＲＲＣに関する設定の変更が必要か否かの判断が可能となる。

　ステップＳＴ１１０１において、Ｔ-ＭｅＮＢは、Ｓ－ＭｅＮＢからＨＯ要求メッセージで受信した情報を用いて、ＳｅＮＢを変更するか否か判断する。この処理は、Ｔ－ｅＮＢがＳｅＮＢのベアラをＳ－ｅＮＢで設定していた状態で引継ぎが可能かを判断する。例えば、Ｔ－ｅＮＢで収容可能なＳ－ｅＮＢ数に制限があり、その制限によって受け入れが不可能な場合がある。また、デュアルコネクティビティにおけるユーザプレインアーキテクチャの選択肢３Ｃの場合では、Ｓ－ＭｅＮＢでベアラスプリットされたベアラを収容できるか否かも判断の情報となる。

　ＳｅＮＢの変更を行うと判断された場合は、ステップＳＴ１１０２に移行する。また、ＳｅＮＢの変更を行うと判断した場合に限らず、ＨＯ処理において、Ｔ－ＭｅＮＢがＳｅＮＢのリリースを決定した場合に、ステップＳＴ１１０２に移行してもよい。

　ステップＳＴ１１０２において、Ｔ－ＭｅＮＢは、前述の図１０に示すステップＳＴ９０８のＳｅＮＢリリース処理を実行してＳｅＮＢをリリースした後、ステップＳＴ９０８のＨＯ処理を実行する。具体的には、Ｔ－ＭｅＮＢは、Ｓ－ＭｅＮＢに、ＳｅＮＢリリース処理の実行要求を示す情報（以下「ＳｅＮＢリリース処理実行要求情報」という場合がある）を通知する。Ｔ－ＭｅＮＢからＳｅＮＢリリース処理実行要求情報を通知されたＳ－ＭｅＮＢは、実施の形態１で開示した方法を適用すればよく、ここでは説明を省略する。

　なお、この場合、ステップＳＴ１１００のＳ－ＭｅＮＢからＴ－ＭｅＮＢへのＨＯ要求は省略してもよい。Ｔ－ＭｅＮＢは、Ｓ－ＭｅＮＢにＳｅＮＢリリース処理実行要求情報を通知した後、ステップＳＴ９３０のアドミッション制御を行うとよい。

　Ｔ－ＭｅＮＢからＳ－ＭｅＮＢへのＳｅＮＢリリース処理実行要求情報の通知を、ＨＯ要求受諾応答メッセージを用いて行ってもよい。例えば、アドミッション制御の後のステップＳＴ１１０４におけるＨＯ要求受諾応答メッセージを用いて行ってもよい。ＨＯ処理においてＳｅＮＢをリリースすると決定したＴ－ＭｅＮＢは、ＭｅＮＢ間のみのＨＯを行うと判断し、それに応じてアドミッション制御を行い、ＳｅＮＢリリース処理実行要求情報を含めたＳ－ＭｅＮＢに対して、ＨＯ要求受諾応答メッセージを通知する。ＭｅＮＢのＨＯの際はＳｅＮＢをリリースするとシステムとして規定している場合は、ＨＯ要求受諾応答メッセージがＳｅＮＢリリース処理の実行要求を示すとしてもよい。Ｔ－ＭｅＮＢからＨＯ要求受諾応答メッセージを受信したデュアルコネクティビティを行っているＳ－ＭｅＮＢは、ＳｅＮＢのリリース処理を実行する。

　Ｔ－ＭｅＮＢからＵＥへのＳｅＮＢリリース処理実行要求情報の通知を、ＭＣＩ（Mobility Control Information）を含むＲＲＣ接続再構成（RRC Connection Reconfiguration）メッセージを用いて通知してもよい。例えば、ステップＳＴ１１０６のＭＣＩを含むＲＲＣ接続再構成メッセージを用いてもよい。ＭｅＮＢのＨＯの際はＳｅＮＢをリリースするとシステムとして規定している場合は、ＭＣＩを含むＲＲＣ接続再構成メッセージがＳｅＮＢリリース処理の実行要求を示すとしてもよい。Ｓ－ＭｅＮＢからＭＣＩを含むＲＲＣ接続再構成メッセージを受信したＳｅＮＢを構成しているＵＥは、ＳｅＮＢのリリース処理を実行する。

　Ｔ－ＭｅＮＢは、ＳｅＮＢを変更しないと判断した場合は、ステップＳＴ１１０３において、ＳｅＮＢの使用を維持したままＨＯ処理を行うことを決定する。換言すれば、ＭｅＮＢのみの変更を行う。ＳｅＮＢの変更をしないと判断した場合は、ＳｅＮＢ使用のベアラ２の変更処理は行わない。

　ステップＳＴ９３０において、Ｔ－ＭｅＮＢは、ＨＯ要求に対するアドミッション制御を行う。このアドミッション制御は、前述した、ＳｅＮＢを変更するか否かの判断の前に行われてもよい。あるいは、その判断と併せて行われてもよい。

　ＳｅＮＢの変更を行わないので、ＭｅＮＢの変更によるアドミッション制御を行う。アドミッション制御において、Ｔ－ＭｅＮＢは、Ｔ－ＭｅＮＢのためのＲＲＣに関する設定を行う。ＲＲＣに関する設定として、無線リソースの構成を示すＡＳ構成（AS configuration）、ＲＲＭ情報を示すＲＲＭ構成（RRM configuration）などがある。また、ＲＲＣ接続再構成メッセージに含まれる情報の設定も行ってもよい。

　Ｔ－ＭｅＮＢで用いるＵＥ個別ＲＡＣＨプリアンブル構成は、ＳｅＮＢで用いるＵＥ個別のＲＡＣＨプリアンブル構成と別々に設けて設定してもよい。また、Ｔ－ＭｅＮＢで用いるＣ－ＲＮＴＩ（Cell-Radio Network Temporary Identifier）は、ＳｅＮＢで用いるＣ－ＲＮＴＩと別々に設けて設定してもよい。ＳｅＮＢがＴ－ＭｅＮＢ傘下にない他のＵＥをサポートするような場合に、各ＵＥに個別に設定することができるので、柔軟な制御を可能とする。

　あるいは、Ｔ－ＭｅＮＢで用いるＵＥ個別のＲＡＣＨプリアンブル構成をＳｅＮＢで用いるＵＥ個別のＲＡＣＨプリアンブル構成と同じに設定してもよい。また、Ｔ－ＭｅＮＢで用いるＣ－ＲＮＴＩをＳｅＮＢで用いるＣ－ＲＮＴＩと同じに設定してもよい。ＳｅＮＢがＴ－ＭｅＮＢ傘下にない他のＵＥをサポートしない場合などに、各ＵＥ個別に設定する必要が無く、１つの値で制御することができるので、制御が簡易になる。

　Ｔ－ＭｅＮＢのためのＲＲＣに関する設定は、ＵＥがＴ－ＭｅＮＢとＲＲＣ接続再構成を可能とする情報が必要となる。

　Ｔ－ＭｅＮＢは、ＨＯ要求受入を決定した場合、ステップＳＴ１１０４において、Ｓ－ＭｅＮＢに、ＨＯ指示メッセージを含むＨＯ要求受諾応答メッセージを通知する。このＨＯ指示メッセージに、前述のＴ－ＭｅＮＢのためのＲＲＣに関する設定情報を含めるとよい。

　また、ＳｅＮＢを用いたベアラ２を維持する場合、Ｔ－ＭｅＮＢは、Ｓ－ＭｅＮＢに、ＳｅＮＢを用いたベアラ２の構成を維持したままＨＯが可能であることを通知してもよい。また、ＳｅＮＢを用いたベアラ２の構成を維持する場合、Ｔ－ＭｅＮＢは、Ｓ－ＭｅＮＢに、ＳｅＮＢのためのＲＲＣに関する設定を維持したままＨＯが可能であることを通知してもよい。これらの通知は、ＨＯ要求受諾応答メッセージを用いて行うとよい。ＳｅＮＢを用いないベアラに対するＨＯ要求受諾応答メッセージと一緒に通知してもよい。ＳｅＮＢを用いないベアラに対するＨＯ要求受諾応答メッセージと別に通知してもよい。

　ＨＯ要求受諾応答メッセージ、または、ＨＯ指示メッセージに、ＳｅＮＢのＲＲＣに関する設定の変更があるか否かの情報を含めてもよい。Ｓ－ＭｅＮＢは、該情報を取得し、変更があると認識した場合に、さらに、ＳｅＮＢのＲＲＣに関する設定を取得するようにしてもよい。これによって、変更がない場合の処理を簡略化することが可能となる。

　ＳｅＮＢのＲＲＣに関する設定に変更がない場合、該設定情報をＨＯ指示メッセージに含めなくてもよい。これによって、シグナリングする情報量を削減することが可能となる。

　あるいは、ＳｅＮＢのためのＲＲＣに関する設定情報を、ＨＯ指示メッセージに含めてもよい。Ｓ－ＭｅＮＢが、Ｔ－ＭｅＮＢから取得したＳｅＮＢのためのＲＲＣに関する設定情報と、自セルが有しているＳｅＮＢのためのＲＲＣに関する設定情報とを比較することが可能となり、確実に変更が無いことを検証することが可能となる。

　ステップＳＴ１１０４でＨＯ要求受諾応答メッセージを受信したＳ－ＭｅＮＢは、Ｔ－ＭｅＮＢへ、デュアルコネクティビティ中のＵＥに対するＳｅＮＢを維持したままのＨＯであることを認識することができる。

　ＳｅＮＢを維持したままのＨＯを行うことを認識したＳ－ＭｅＮＢは、ＳｅＮＢに対して、ベアラ２構成の変更の要求を行わない。ＳｅＮＢのためのＲＲＣに関する設定変更の要求を行わない。

　ステップＳＴ１１０５において、Ｔ－ＭｅＮＢ、Ｓ－ＭｅＮＢおよびＳｅＮＢ間で、ＳｅＮＢへＨＯが起動されることを示す情報を通知する処理が行われる。たとえば、Ｔ-ＭｅＮＢは、ＳｅＮＢへＨＯが起動されることを示す情報を通知する。この通知は、Ｔ－ＭｅＮＢがＳ-ＭｅＮＢへＨＯ要求受諾応答メッセージを送信したときに行うとよい。あるいは、Ｔ-ＭｅＮＢからＨＯ要求受諾応答メッセージを受信したＳ-ＭｅＮＢが、ＳｅＮＢへＨＯを起動することを示す情報を通知してもよい。

　図１８のステップＳＴ１１０８において、Ｓ－ＭｅＮＢは、ＰＤＣＰのＳＮ情報、および、送信が完了していないデータをＴ－ＭｅＮＢに転送し、ロスのない通信を確立する。

　デュアルコネクティビティ中のＵＥがＭｅＮＢ間ＨＯ中に、ＳｅＮＢ起動によるベアラ２構成の変更は行わないようにしてもよい。ＨＯ中にＳｅＮＢ起動によるベアラ構成の変更があると、Ｓ－ＭｅＮＢからＴ－ＭｅＮＢへのＭｅＮＢ変更時に該処理を行うこととなるので、制御が複雑になり、誤動作の可能性が高くなる。ＨＯ時のＳｅＮＢ起動によるベアラ２の構成の変更は行わないとすることによって、誤動作を低減することが可能となる。

　ＨＯ中に、ＳｅＮＢ起動によるベアラ２の構成の変更が行われないようにする方法を以下に開示する。

　Ｔ-ＭｅＮＢは、ＳｅＮＢへＨＯが起動されることを示す情報を通知する。この通知は、Ｔ－ＭｅＮＢがＳ-ＭｅＮＢへＨＯ要求受諾応答メッセージを送信したときに行うとよい。あるいは、Ｔ-ＭｅＮＢからＨＯ要求受諾応答メッセージを受信したＳ-ＭｅＮＢが、ＳｅＮＢへＨＯを起動することを示す情報を通知してもよい。

　ＨＯが起動されたことを示す情報を受信したＳｅＮＢは、ベアラ２の構成の変更要求を起動しない。該ＨＯが完了するまで起動しないとするとよい。

　他の方法として、該ＨＯ中は、Ｓ－ＭｅＮＢあるいはＴ－ＭｅＮＢは、ＳｅＮＢからのベアラ２構成変更要求に対してＮａｃｋ（あるいは拒否）をＳｅＮＢに通知してもよい。理由情報を含めてもよく、理由として、ＨＯ中によることを示す情報を設けて設定するとよい。

　ＳｅＮＢがＨＯ完了を認識する方法を以下に開示する。Ｔ-ＭｅＮＢは、ＳｅＮＢへＨＯ完了したことを示す情報を通知するとよい。この通知は、ＨＯ処理において、Ｔ－ＭｅＮＢがＭＭＥからパススイッチ要求受諾応答メッセージを受信したときに行うとよい。あるいは、後述するＭｅＮＢの変更処理完了をＨＯ完了としてもよい。

　このようにすることによって、デュアルコネクティビティ中のＵＥのＨＯ処理中に、ＳｅＮＢ起動の該ＵＥに対するベアラ２構成の変更を行わないようにすることができる。したがって、システムとして誤動作を低減することが可能となる。

　他の方法について開示する。前述のＳｅＮＢを維持したままのＨＯを行う場合、Ｓ－ＭｅＮＢは、ＳｅＮＢに対して、ベアラ２の構成の変更の要求、およびＳｅＮＢのためのＲＲＣに関する設定変更の要求を行わないことを開示したが、他の方法として、ＳｅＮＢを維持したままのＨＯを行う場合、Ｓ－ＭｅＮＢは、ＳｅＮＢに対して、ＳｅＮＢを維持したままのＨＯであることを通知してもよい。あるいは、ベアラ２構成の変更の要求、ＳｅＮＢのためのＲＲＣに関する設定変更の要求を行わないことを通知してもよい。前述のＨＯが起動されることを示す情報とともに通知してもよい。

　これによって、ＳｅＮＢは、ＨＯ中に、該ＨＯがＳｅＮＢを維持したままのＨＯを行う場合か否かなどを認識することが可能となる。ＳｅＮＢを維持したままのＨＯの場合は、ＳｅＮＢは、該ＨＯ中はＳｅＮＢ起動の該ＵＥに対するベアラ２の構成の変更を行わないようにすることができる。前述と同様の効果を得ることが可能となる。

　ＨＯ要求受諾応答メッセージを受信したＳ-ＭｅＮＢは、ステップＳＴ１１０６において、ＵＥへ、Ｔ－ＭｅＮＢへＨＯをさせるために、モビリティ制御情報（Mobility Control Information；略称：ＭＣＩ）を含むＲＲＣ接続再構成（RRC Connection Reconfiguration）メッセージを通知する。また、ＨＯ要求受諾応答メッセージを受信したＳ-ＭｅＮＢはＵＥへ、ＳｅＮＢを用いたベアラの変更が無いことを通知してもよい。

　Ｓ－ＭｅＮＢはＵＥへ、該ＨＯ時、ベアラ２を行うＥ－ＲＡＢ用のＳｅＮＢの変更が無いことを通知する。また、ＳｅＮＢのためのＲＲＣに関する設定変更が無いことを通知してもよい。該ＭＣＩを含むＲＲＣ接続再構成メッセージに一緒に含めて通知するとよい。

　必要に応じて、Ｓ－ＭｅＮＢは、ＳｅＮＢのためのＲＲＣに関する設定情報を認識している場合は、該設定情報をＵＥに通知してもよい。ＵＥは、自ＵＥが接続しているＳｅＮＢに対するＲＲＣに関する設定情報と、受信した該設定情報とを比較することが可能となり、確実に変更が無いことを検証することが可能となる。

　ステップＳＴ１１０６において、ＭＣＩを含むＲＲＣ接続再構成メッセージを受信したＵＥは、ＳｅＮＢとの同期および接続を維持したまま、Ｓ－ＭｅＮＢからＴ－ＭｅＮＢへのＨＯを行う。ＵＥは、ＳｅＮＢとの無線リソースを維持したままＨＯを行う。この状態においてＵＥは、ＳｅＮＢとの通信が可能である。

　ＵＥからＳｅＮＢへの上りデータの取扱い方法について、以下に開示する。ＵＥは、ＳｅＮＢと接続を維持したままＨＯを行う場合、ベアラ２の上りデータの送信を維持することができる。または、Ｓ―ＭｅＮＢからＴ－ＭｅＮＢへのＨＯが完了するまで、ＵＥは、ＨＯ中は上りデータの送信を停止し、バッファに記憶することもできる。このようにすることによって、制御プレインの確立を待つことができ、制御プレインパスの未確立時のＳｅＮＢとＳ―ＭｅＮＢ、または、ＳｅＮＢとＴ－ＭｅＮＢの制御情報のバッファリング処理などを削減することができ、ＳｅＮＢの処理を簡易化することが可能となる。

　ステップＳＴ１１０６において、Ｓ－ＭｅＮＢから、Ｔ－ＭｅＮＢへのＨＯを指示するＭＣＩを受信したＵＥは、ステップＳＴ１１０７において、ベアラ１の上りデータの送信を停止し、バッファに記憶する。

　ステップＳＴ１１０９において、ＵＥは、ＭＣＩに従い、Ｓ－ＭｅＮＢからＴ－ＭｅＮＢへ接続変更処理を行う。ＵＥは、ＭＣＩを受信した後、Ｓ－ＭｅＮＢとの接続を切断してＴ－ＭｅＮＢとの接続を行う。ＵＥは、ステップＳＴ１１０６のＲＲＣ接続再構成メッセージで受信した内容を用いて、Ｔ－ＭｅＮＢのためのＲＲＣ接続の再構成を行い、Ｔ－ＭｅＮＢと接続を行う。

　ＵＥは、ステップＳＴ１１１０において、Ｔ－ＭｅＮＢとＲＡ処理を行い、ステップＳＴ１１１１において、Ｔ－ＭｅＮＢに対してＲＲＣ接続再構成完了メッセージを通知する。

　ＵＥは、Ｔ－ＭｅＮＢにＲＲＣ接続再構成完了メッセージ通知後、Ｔ－ＭｅＮＢとの間で、直接データ通信を行うことが可能となる。

　ＵＥは、Ｔ－ＭｅＮＢとのＲＲＣ接続再構成完了メッセージを通知後、ベアラ１の上りデータを送信する。

　ＳｅＮＢからＵＥへ通知する下りデータの取扱い方法について、以下に開示する。ＳｅＮＢは、ＵＥと接続を維持したままＨＯを行う場合、ベアラ２の下りデータの送信を維持することができる。

　または、Ｓ―ＭｅＮＢからＴ－ＭｅＮＢへのＨＯが完了するまで、ＳｅＮＢは、ＨＯ中は下りデータの送信を停止し、バッファに記憶することもできる。このようにすることによって、制御プレインの確立を待つことができ、制御プレインパスの未確立時のＳｅＮＢとＳ―ＭｅＮＢ、または、ＳｅＮＢとＴ－ＭｅＮＢの制御情報のバッファリング処理などを削減することができ、ＳｅＮＢの処理を簡易化することが可能となる。

　ＳｅＮＢは、ＭｅＮＢによって、ＵＥに対するデュアルコネクティビティのためのベアラの構成を通知される。また、ＳｅＮＢの該ＵＥに対するＲＲＣに関する設定情報は、該ＭｅＮＢによって通知される。

　したがって、ＳｅＮＢは、どのＭｅＮＢから該ベアラの構成が通知されたか、どのＭｅＮＢに、ＳｅＮＢが設定したＲＲＣに関する設定情報を通知すればよいか、などを認識する必要がある。すなわち、該ＭｅＮＢを認識する必要がある。

　また、ＳｅＮＢは、ＭｅＮＢ間でデュアルコネクティビティを行うＵＥのためのデータ通信を行う。ＳｅＮＢは、どのＭｅＮＢからのデータをＵＥに送信すればよいか、ＵＥからのデータをどのＭｅＮＢへ送信すればよいかを認識する必要がある。すなわち、該ＭｅＮＢを認識する必要がある。

　前者のＭｅＮＢと後者のＭｅＮＢとを別に設定してもよいが、ここでは、同一である場合について説明する。以下の説明では、該ＭｅＮＢを、ＳｅＮＢの制御ＭｅＮＢと称する。

　デュアルコネクティビティ中のＵＥのＨＯ処理において、ＳｅＮＢの変更は行われず、ＭｅＮＢがＳ－ＭｅＮＢからＴ－ＭｅＮＢに変更される場合について、該ＳｅＮＢの制御ＭｅＮＢが、どのＭｅＮＢに変更されたかを認識する方法を開示する。

　ＳｅＮＢの制御ＭｅＮＢが、どのＭｅＮＢに変更されたかを認識する方法の具体例として、以下の（１），（２）の２つを開示する。
　（１）Ｓ－ＭｅＮＢがＳｅＮＢに制御ＭｅＮＢの変更を通知する。
　（２）Ｔ－ＭｅＮＢがＳｅＮＢに制御ＭｅＮＢの変更を通知する。

　前記具体例（１）について、具体例を以下に開示する。Ｔ－ＭｅＮＢは、ＵＥからＲＲＣ接続再構成完了メッセージを受信すると、Ｓ－ＭｅＮＢに対して、ＳｅＮＢへ制御ＭｅＮＢの変更を要求するように、ＳｅＮＢの制御ＭｅＮＢ変更要求メッセージの通知を行う。該通知はＸ２シグナリングを用いて行うとよい。該通知に、制御ＭｅＮＢの変更を行うＳｅＮＢの識別子を含めて通知してもよい。また、変更の理由情報を含めて通知してもよい。ＨＯによるＭｅＮＢの変更であることを示す情報を設けて通知してもよい。

　該通知を受信したＳ－ＭｅＮＢは、制御ＭｅＮＢの変更を行うＳｅＮＢへ、制御ＭｅＮＢの変更を要求する制御ＭｅＮＢ変更要求メッセージを通知する。該通知は、Ｘ２シグナリングを用いて行ってもよい。あるいはＭｅＮＢとＳｅＮＢとの間に設けられるインタフフェース上のシグナリングを用いて行ってもよい。

　該シグナリングに含める情報の具体例として、以下の（１）～（５）の５つを開示する。
　（１）制御ＭｅＮＢの変更を示す情報。
　（２）変更後の制御ＭｅＮＢの識別子。ここでは、Ｔ－ＭｅＮＢの識別子。
　（３）ＳｅＮＢを用いたパスのベアラ識別子。ここでは、Ｅ－ＲＡＢ識別子（E-RAB IDなどであってもよい）、あるいは、ＥＰＳベアラ識別子。
　（４）ベアラを用いてデュアルコネクティビティを行うＵＥの識別子。
　（５）前記（１）～（４）の組合せ。

　制御ＭｅＮＢ変更要求メッセージを受信したＳｅＮＢは、該制御ＭｅＮＢ変更要求メッセージに含まれる情報から、ＭｅＮＢの変更を行うベアラを特定する。ＳＭｅＮＢは、該ベアラの制御ＭｅＮＢを変更後のＭｅＮＢに変更する。ＳｅＮＢにおけるベアラの管理は、制御ＭｅＮＢの識別子と関連付けて行うとよい。すなわち、ベアラの識別子と制御ＭｅＮＢの識別子とを関連付けておくとよい。このようにすることによって、ＳｅＮＢは、デュアルコネクティビティを行うＵＥのためのベアラの制御ＭｅＮＢの変更が可能となる。

　ＳｅＮＢは、制御ＭｅＮＢの変更後、該ベアラの修正、リリースの要求は、変更後の制御ＭｅＮＢからのみ受入れることとする。また、ＳｅＮＢは、変更後のＭｅＮＢとデータの通信を行うこととする。

　このようにすることによって、ＳｅＮＢは、制御ＭｅＮＢが、どのＭｅＮＢに変更されたかを認識することができ、変更後の制御ＭｅＮＢとの間で、該ＵＥに対する該ベアラの修正、リリースの要求などの制御のための通信、およびデータ通信を行うことが可能となる。

　制御ＭｅＮＢの変更を行ったＳｅＮＢは、Ｓ－ＭｅＮＢに対して、制御ＭｅＮＢ変更応答メッセージを通知してもよい。該メッセージに、制御ＭｅＮＢの変更を行ったことを示す情報を含めてもよい。

　ＳｅＮＢから制御ＭｅＮＢ変更応答メッセージを受信したＳ－ＭｅＮＢは、変更後の制御ＭｅＮＢ、ここではＴ－ＭｅＮＢに、ＳｅＮＢの制御ＭｅＮＢ変更が完了したことを示すメッセージを通知してもよい。

　このようにすることによって、変更後のＭｅＮＢ、ここではＴ－ＭｅＮＢは、ＳｅＮＢの制御ＭｅＮＢが変更されたことを認識することができ、該ＳｅＮＢに対して、該ＵＥに対する該ベアラの修正、リリースの要求などの制御のための通信、およびデータ通信を開始することが可能となる。

　変更後ＭｅＮＢは、ＳｅＮＢに対して、該ＵＥに対する該ベアラの制御ＭｅＮＢが変更になったことを確認するメッセージを通知してもよい。また、ＳｅＮＢは該メッセージに対して応答してもよい。

　前記具体例（２）について、以下に具体例を開示する。Ｔ－ＭｅＮＢは、ＵＥからＲＲＣ接続再構成完了メッセージを受信すると、ＳｅＮＢに、制御ＭｅＮＢ変更要求メッセージの通知を行う。該ＳｅＮＢの識別子は、Ｓ－ＭｅＮＢから受信したＨＯ要求メッセージ含まれるＳｅＮＢ情報を用いるとよい。該通知はＸ２シグナリングを用いて行うとよい。あるいはＭｅＮＢとＳｅＮＢ間に設けられるインタフフェース上のシグナリングを用いて行ってもよい。該シグナリングに含める情報は、前記具体例（１）の方法で開示したものを適用することができる。

　Ｔ－ＭｅＮＢから、制御ＭｅＮＢ変更要求メッセージを受信したＳｅＮＢにおける処理は、前記具体例（１）と同様であるので、説明を省略する。

　このようにすることによって、ＳｅＮＢは制御ＭｅＮＢがどのＭｅＮＢに変更されたかを認識することができ、変更後の制御ＭｅＮＢとの間で該ＵＥに対する該ベアラの修正、リリースの要求などの制御のための通信、およびデータ通信を行うことが可能となる。

　制御ＭｅＮＢの変更を行ったＳｅＮＢは、Ｔ－ＭｅＮＢに対して、制御ＭｅＮＢ変更応答メッセージを通知してもよい。該メッセージに、制御ＭｅＮＢの変更を行ったことを示す情報を含めてもよい。

　ＳｅＮＢから制御ＭｅＮＢ変更応答メッセージを受信したＴ－ＭｅＮＢは、変更前の制御ＭｅＮＢ、ここではＳ－ＭｅＮＢに、ＳｅＮＢの制御ＭｅＮＢ変更が完了したことを示すメッセージを通知してもよい。

　このようにすることによって、変更前のＭｅＮＢ、ここではＳ－ＭｅＮＢは、ＳｅＮＢの制御ＭｅＮＢが変更されたことを認識することができ、該ＳｅＮＢに対して、該ＵＥに対する該ベアラの修正、リリースの要求などの制御のための通信、およびデータ通信を終了することが可能となる。

　また、ＳｅＮＢを用いてデュアルコネクティビティ中のＵＥのＨＯが行われた場合、ＳｅＮＢは、変更後のＭｅＮＢ（Ｔ－ＭｅＮＢ）とベアラ構成に関する制御のための通信、およびデータ通信を行うことが可能となる。

　したがって、ＵＥとＴ－ＭｅＮＢとの間でＳｅＮＢを介してデータ通信を行うことが可能となる。

　ＳｅＮＢのＭｅＮＢ変更処理について具体例を説明する。ステップＳＴ１１１１でＵＥからＲＲＣ接続再構成完了メッセージを受信したＴ－ＭｅＮＢは、ステップＳＴ１１１２において、Ｓ－ＭｅＮＢに対して、ＳｅＮＢの制御ＭｅＮＢの変更を要求する制御ＭｅＮＢ変更要求メッセージを通知する。該ＳｅＮＢの制御ＭｅＮＢ変更要求メッセージに、制御ＭｅＮＢの変更を行うＳｅＮＢの識別子を含める。

　該メッセージを受信したＳ－ＭｅＮＢは、ステップＳＴ１１１３において、制御ＭｅＮＢの変更を行うＳｅＮＢに対して、制御ＭｅＮＢ変更要求メッセージを通知する。該制御ＭｅＮＢ変更要求メッセージに、制御ＭｅＮＢの変更を示す情報、Ｔ－ＭｅＮＢの識別子、ＳｅＮＢを用いたパスのベアラ識別子、ＳｅＮＢにおける制御ＭｅＮＢを変更するベアラの識別子、Ｓ－ＭｅＮＢの識別子、ＳｅＮＢを用いてデュアルコネクティビティを行うＨＯ対象のＵＥの識別子を含める。このようにすることによって、ＳｅＮＢは、どのＭｅＮＢが設定したどのベアラについて制御ＭｅＮＢの変更を行えばよいかを認識することができる。

　該制御ＭｅＮＢ変更要求メッセージを受信したＳｅＮＢは、ステップＳＴ１１１４において、受信した情報を用いて、制御ＭｅＮＢの変更を行う。これによって、ＳｅＮＢは、以降、変更後の制御ＭｅＮＢであるＴ－ＭｅＮＢと、ベアラに関する制御のための通信およびデータ通信を行う。制御ＭｅＮＢを変更したＳｅＮＢは、変更前の制御ＭｅＮＢとの制御のための通信およびデータ通信を終了する。

　ステップＳＴ１１１４で制御ＭｅＮＢの変更を行ったＳｅＮＢは、ステップＳＴ１１１５において、Ｓ－ＭｅＮＢに対して、制御ＭｅＮＢを変更したことを通知するために、制御ＭｅＮＢ変更応答メッセージを通知する。該制御ＭｅＮＢ変更応答メッセージを受信したＳ－ＭｅＮＢは、ステップＳＴ１１１６において、Ｔ－ＭｅＮＢに対してＳｅＮＢの制御ＭｅＮＢの変更が終了したことを通知するために、ＳｅＮＢの制御ＭｅＮＢ変更応答メッセージを通知する。これによって、Ｔ－ＭｅＮＢは、ＳｅＮＢの制御ＭｅＮＢがＴ－ＭｅＮＢに変更されたことを認識することができる。したがって、Ｔ－ＭｅＮＢは、ＳｅＮＢと、ベアラに関する制御のための通信およびデータ通信を行うことが可能となる。

　以上のように、本実施の形態では、ＳｅＮＢへの制御ＭｅＮＢ変更要求メッセージの通知を、Ｓ－ＭｅＮＢを介して実行しているが、Ｓ－ＭｅＮＢを介さずに、直接、Ｔ－ＭｅＮＢとＳｅＮＢとの間で、制御ＭｅＮＢ変更要求メッセージ、および制御ＭｅＮＢ変更応答メッセージを送受信してもよい。その場合、制御ＭｅＮＢ変更要求メッセージにＳ－ＭｅＮＢの情報を含めて、ＳｅＮＢの制御ＭｅＮＢ変更処理において、不正な制御ＭｅＮＢ変更要求でないことの判断に用いてもよい。

　図１８に示すステップＳＴ１１１２からステップＳＴ１１１６を、ステップＳＴ１１１７とする。ステップＳＴ１１１７は、Ｔ－ＭｅＮＢ、Ｓ－ＭｅＮＢおよびＳｅＮＢの間で行われるＳｅＮＢの制御ＭｅＮＢ変更処理を示す。

　その後の、ＭｅＮＢ変更のためのＳ－ＧＷにおけるパス切替処理は、前述の図１２と同様であるので、説明を省略する。パス切替処理によって、Ｓ－ＧＷと、ＨＯ対象であったＵＥとの間において、Ｔ－ＭｅＮＢを介したデータ通信を行うことが可能となる。

　Ｓ－ＧＷとＵＥとの間におけるデータ通信は、一つはＳ－ＭｅＮＢとＵＥとの間でデータが直接通信され、もう一つはＳｅＮＢとＵＥとの間でデータが直接通信される。本実施の形態で開示した方法とすることによって、ベアラによるデュアルコネクティビティ中のＵＥがＭｅＮＢ間ＨＯを行うことが可能となる。

　ＳｅＮＢの制御ＭｅＮＢ変更処理について、他の方法を開示する。前述に開示した方法では、ＳｅＮＢの制御ＭｅＮＢ変更処理は、Ｔ－ＭｅＮＢがＵＥからＲＲＣ接続再構成完了メッセージを受信した後に行われる。

　他の方法として、Ｔ－ＭｅＮＢがＳ－ＭｅＮＢに対してＨＯ要求受諾応答メッセージを通知した後、あるいは、Ｓ－ＭｅＮＢがＴ－ＭｅＮＢからＨＯ要求受諾応答メッセージを受信した後、あるいは、Ｓ－ＭｅＮＢがＵＥにＭＣＩを含むＲＲＣ接続再構成メッセージを送信した後に、ＳｅＮＢの制御ＭｅＮＢ変更処理を行うようにしてもよい。ＳｅＮＢの制御ＭｅＮＢ変更処理は、前述の方法を適用するとよい。

　このようにすることによって、早期に、ＳｅＮＢにおいて制御ＭｅＮＢをＴ－ＭｅＮＢに変更することが可能となるので、早期に、ＳｅＮＢとＴ-ＭｅＮＢとの間で制御データ通信を行うことが可能となる。

　ＳｅＮＢの制御ＭｅＮＢ変更処理について、他の方法を開示する。Ｔ－ＭｅＮＢが、ＭＭＥおよびＳ－ＧＷに対して行うパススイッチ処理を完了した後に、ＳｅＮＢの制御ＭｅＮＢ変更処理を行うようにしてもよい。Ｔ-ＭｅＮＢは、ＭＭＥからパススイッチ要求受諾応答メッセージを受信すると、ＳｅＮＢへＭｅＮＢの変更通知を行う。

　あるいは、Ｓ－ＭｅＮＢは、Ｔ－ＭｅＮＢからＵＥコンテキストリリース（UE context release）メッセージを受信すると、ＳｅＮＢへＭｅＮＢの変更通知を行う、としてもよい。ＳｅＮＢの制御ＭｅＮＢ変更処理は、前述の方法を適用するとよい。

　このようにすることによって、ＭＭＥおよびＳ－ＧＷのＴ－ＭｅＮＢへのパス切替えも含めてＨＯ処理が終了した後に、ＳｅＮＢを用いたベアラによるデータ通信を行うことが可能となる。確実にＨＯ処理が終了した後に行うことによって、データ通信の制御の複雑化を避けることが可能となる。

　以上のように本実施の形態によれば、ＨＯ処理が起動されると、スモールセルであるＳｅＮＢに、スモールセルを制御するマクロセルが変更されることが通知される。これによって、Ｓ－ＧＷからスモールセルを介して通信を行うパスは保持したまま、ＨＯ処理を実行することができるので、ＨＯ処理中であっても、ユーザプレインデータ通信を継続することが可能となる。

　また、実施の形態１のようにＳｅＮＢをリリースした後、ＨＯを実行する場合と比較して、制御シーケンスが簡易になるので、デュアルコネクティビティ中からのＨＯシーケンスにおけるシグナリングする情報量を削減することが可能となる。

　実施の形態３．
　図２０～図２２は、本発明の実施の形態３の通信システムにおけるハンドオーバ関連処理のシーケンスの一例を示す図である。図２０と図２１とは、境界線ＢＬ３で接続されている。図２１と図２２とは、境界線ＢＬ４で接続されている。本実施の形態のハンドオーバ関連処理は、前述の図１０～図１３に示す実施の形態１および図１７～図１９に示す実施の形態２のハンドオーバ関連処理と類似するので、同一のステップについては同一のステップ番号を付して、説明を省略する。

　本実施の形態では、非特許文献１１に記載されるデュアルコネクティビティのユーザプレインアーキテクチャの選択肢３Ｃ（Alternative 3C）の場合（非特許文献１１　８．１．１．８参照）において、ＳｅＮＢをリリースしないでＨＯを行う方法について開示する。

　ユーザプレインアーキテクチャの選択肢３Ｃでは、ＭｅＮＢによって、ＭｅＮＢとＵＥとの間で、直接通信を行うパスと、スモールセルを介して通信を行うパスとでベアラが分割されるベアラスプリットが行われる。

　ベアラスプリットによるデュアルコネクティビティ中のＵＥがＭｅＮＢ間ＨＯを行う場合、ＳｅＮＢとの接続はリリースされない。すなわち、ＵＥのデュアルコネクティビティを保ったまま、ＭｅＮＢ間のＨＯが行われる。

　ベアラスプリットの場合、実施の形態１の変形例１でも説明したが、１つのＥＰＳベアラに対応するＥ－ＲＡＢが、Ｓ－ＭｅＮＢで、２つのパスに分離され、Ｓ－ＧＷとＵＥとの間でデータが通信される。一つはステップＳＴ１００１において、Ｓ－ＭｅＮＢとＵＥ間でデータが直接通信される。もう一つは、ステップＳＴ１００３およびステップＳＴ１００４において、Ｓ－ＭｅＮＢとＵＥ間でデータがＳｅＮＢを介して通信される。ステップＳＴ１００２において、Ｓ－ＭｅＮＢとＳ－ＧＷとの間は、一つのパスでデータが通信される。

　ＭｅＮＢが、ベアラスプリットによるデュアルコネクティビティ中のＵＥに対してメジャメント制御メッセージを通知する方法は、実施の形態１で開示した方法を適用することができる。ここでは説明を省略する。

　ここでは、メジャメントによるＳ－ＭｅＮＢの受信品質が劣化し、Ｔ－ＭｅＮＢの受信品質が改善し、イベントクライテリアに従ってメジャメント報告を行う場合について説明する。

　該ＵＥからメジャメント報告を受信したＳ－ＭｅＮＢは、該報告の結果を用いて該ＵＥをＴ－ＭｅＮＢへＨＯさせることを決定する。

　ステップＳＴ１２０１において、Ｓ－ＭｅＮＢは、Ｔ－ＭｅＮＢに対してＨＯ要求メッセージを通知する。このメッセージに、ＳｅＮＢ情報を含めて通知するとよい。また、ＳｅＮＢを用いてベアラスプリットを行っているベアラに関するベアラ情報を通知してもよい。また、ベアラスプリットに関する情報を通知してもよい。また、ベアラスプリットにおけるＲＲＣに関する情報を通知してもよい。

　ＳｅＮＢ情報として、例えば、ＳｅＮＢの識別子、ＵＥにおけるＳｅＮＢの受信品質などがある。

　ベアラスプリットを行っているベアラに関するベアラ情報として、Ｅ－ＲＡＢ識別子などがある。

　ベアラスプリットに関する情報として、ＭｅＮＢとＵＥとの間の直接のパスと、ＳｅＮＢを介したＭｅＮＢとＵＥとの間のパスとにスプリットされたベアラ（以下「スプリットベアラ」という場合がある）の構成（以下「スプリットベアラ構成」という場合がある）に関する情報がある。ＭｅＮＢは、スプリットされたパス毎にスプリットベアラの設定を行うとよい。各パスに対する識別子を設けてもよい。各パスの識別子と、パス毎に設定したスプリットベアラ構成に関する情報とを関連させて通知するとよい。また、ＳｅＮＢを用いるパスの場合は、該ＳｅＮＢの識別子と該パスの識別子とを関連させて通知してもよい。パス毎に設定されるスプリットベアラ構成に関する情報として、例えば、ＱｏＳパラメータ、具体的には、ＱＣＩ、ＡＲＰ、帯域保証サービス品質情報などがある。

　このようにすることによって、パス毎のスプリットベアラ設定を可能にし、Ｓ－ＭｅＮＢはＴ－ＭｅＮＢに対してパス毎のスプリットベアラ設定を通知することが可能となる。Ｔ－ＭｅＮＢは、パス毎のスプリットベアラ設定を取得することが可能となり、パス毎のスプリットベアラの設定の変更が必要か否か判断可能となる。

　ベアラスプリットを行っているベアラに関するベアラ情報と、スプリットベアラ構成に関する情報とを関連させて通知するとよい。ベアラスプリットを行っているベアラと、行っていないベアラとを識別可能となる。

　ベアラスプリットにおけるＲＲＣに関する設定情報として、例えば、ＲＲＣコンテキスト（RRC context）がある。ＲＲＣコンテキストには、例えば、無線リソースの構成を示すＡＳ構成（AS configuration）、ＲＲＭ情報を示すＲＲＭ構成（RRM configuration）などがある。

　このようにすることによって、ＳｅＮＢのためのＲＲＣに関する情報とＭｅＮＢのためのＲＲＣに関する情報とを個別に設定可能にし、Ｓ－ＭｅＮＢはＴ－ＭｅＮＢに対してＭｅＮＢとＳｅＮＢ、各々のＲＲＣに関する情報を通知することが可能となる。Ｔ－ＭｅＮＢは、Ｓ－ＭｅＮＢとＳｅＮＢ、各々のＲＲＣに関する情報を取得することが可能となり、Ｔ－ＭｅＮＢは、ＳｅＮＢのＲＲＣに関する設定の変更が必要か否か判断可能となる。

　Ｔ-ＭｅＮＢは、Ｓ－ＭｅＮＢからＨＯ要求メッセージで受信した情報を用いて、ステップＳＴ１１０１において、ＳｅＮＢを変更するか否か判断する。このステップＳＴ１１０１の処理は、図１７のステップＳＴ１１０１の処理と同様であるので、説明を省略する。

　ＳｅＮＢの変更を行うと判断した場合は、ステップＳＴ１１０２に移行する。ステップＳＴ１１０２の処理は、実施の形態２で開示した方法を適用すればよく、ここでは説明を省略する。

　ＳｅＮＢの変更をしないと判断した場合は、Ｔ-ＭｅＮＢは、ステップＳＴ１１０３において、ＳｅＮＢの使用を維持したままＨＯ処理を行うことを決定する。換言すれば、Ｔ-ＭｅＮＢは、ＭｅＮＢのみの変更を行うことを決定する。ＳｅＮＢの変更をしないと判断した場合は、ＳｅＮＢ使用のスプリットベアラ構成を維持する。ＳｅＮＢへのスプリットベアラ構成の変更処理は行わない。

　ステップＳＴ１２０２において、Ｔ－ＭｅＮＢは、ＨＯ要求に対するアドミッション制御を行う。このアドミッション制御は、前述のＳｅＮＢを変更するか否かの判断の前に行われてもよい。あるいは、その判断と併せて行われてもよい。

　Ｔ－ＭｅＮＢで用いるＵＥ個別ＲＡＣＨプリアンブル構成は、ＳｅＮＢで用いるＵＥ個別のＲＡＣＨプリアンブル構成と別々に設けて設定してもよい。また、Ｔ－ＭｅＮＢで用いるＣ－ＲＮＴＩはＳｅＮＢで用いるＣ－ＲＮＴＩと別々に設けて設定してもよい。ＳｅＮＢがＴ－ＭｅＮＢ傘下にない他のＵＥをサポートするような場合に、各ＵＥに個別に設定することができるので、柔軟な制御を可能とする。

　Ｔ－ＭｅＮＢがＨＯ要求受入を決定した場合、ステップＳＴ１２０３において、Ｔ－ＭｅＮＢは、Ｓ－ＭｅＮＢに対して、ＨＯ要求受諾応答メッセージにＨＯ指示メッセージを含めて通知する。このＨＯ指示メッセージに前述のＴ－ＭｅＮＢのためのＲＲＣに関する設定情報を含めるとよい。

　また、ＳｅＮＢを用いたスプリットベアラの構成を維持する場合、Ｔ－ＭｅＮＢは、Ｓ－ＭｅＮＢに、該ＳｅＮＢの識別子、Ｅ－ＲＡＢ識別子、ベアラスプリットに関する情報、ベアラスプリットにおけるＲＲＣに関する情報などを通知する。あるいは、Ｔ－ＭｅＮＢは、Ｓ－ＭｅＮＢに、ＳｅＮＢを用いたスプリットベアラの構成を維持したままＨＯが可能であることを通知してもよい。また、ＳｅＮＢを用いたスプリットベアラの構成を維持する場合、Ｔ－ＭｅＮＢは、Ｓ－ＭｅＮＢに、ＳｅＮＢのためのＲＲＣに関する設定を維持したままＨＯが可能であることを通知してもよい。

　このようにすることによって、通知する情報量を削減することが可能となる。これらの通知は、ＨＯ要求受諾応答メッセージを用いて行うとよい。ＳｅＮＢを用いないベアラに対するＨＯ要求受諾応答メッセージと一緒に通知してもよい。ＳｅＮＢを用いないベアラに対するＨＯ要求受諾応答メッセージと別に通知してもよい。

　ＳｅＮＢのＲＲＣに関する設定に変更がない場合、該設定情報をＨＯ指示メッセージに含めなくてもよい。シグナリングする情報量を削減可能となる。

　ステップＳＴ１２０３でＨＯ要求受諾応答メッセージを受信したＳ－ＭｅＮＢは、Ｔ－ＭｅＮＢへ、デュアルコネクティビティ中のＵＥに対するＳｅＮＢを維持したままのＨＯであることを認識することができる。

　ＳｅＮＢを維持したままのＨＯを行うことを認識したＳ－ＭｅＮＢは、ＳｅＮＢに対して、スプリットベアラ構成の変更の要求を行わない。ＳｅＮＢのためのＲＲＣに関する設定変更の要求を行わない。

　デュアルコネクティビティ中のＵＥがＭｅＮＢ間ＨＯ中に、ＳｅＮＢ起動によるベアラスプリット構成の変更は行わないようにしてもよい。ＨＯ中にＳｅＮＢ起動によるベアラスプリット構成の変更があると、Ｓ－ＭｅＮＢからＴ－ＭｅＮＢへのＭｅＮＢ変更時に該処理を行うこととなるため、制御が複雑になり、誤動作の可能性が高くなる。ＨＯ時のＳｅＮＢ起動によるベアラスプリット構成の変更は行わないようにすることによって、誤動作を低減することが可能となる。

　ＨＯ中に、ＳｅＮＢ起動によるベアラスプリット構成の変更が行われないようにする方法を以下に開示する。

　ＨＯが起動されたことを示す情報を受信したＳｅＮＢは、ベアラスプリット構成の変更要求を起動しない。該ＨＯが完了するまで起動しないとするとよい。

　他の方法として、該ＨＯ中は、Ｓ－ＭｅＮＢあるいはＴ－ＭｅＮＢは、ＳｅＮＢからのベアラスプリット構成変更要求に対してＮａｃｋ（あるいは拒否）をＳｅＮＢに通知してもよい。理由情報を含めてもよく、理由として、ＨＯ中によることを示す情報を設けて設定するとよい。

　図２０～図２２の処理においては、ステップＳＴ１２０４において、Ｔ－ＭｅＮＢ、Ｓ－ＭｅＮＢおよびＳｅＮＢ間でこれらの処理が行われる。

　このようにすることによって、デュアルコネクティビティ中のＵＥのＨＯ処理中に、ＳｅＮＢ起動の該ＵＥに対するベアラスプリット構成の変更を行わないようにすることができる。したがって、システムとして誤動作を低減することが可能となる。

　他の方法について開示する。前述のＳｅＮＢを維持したままのＨＯを行う場合、Ｓ－ＭｅＮＢは、ＳｅＮＢに対して、スプリットベアラ構成の変更の要求、また、ＳｅＮＢのためのＲＲＣに関する設定変更の要求を行わないことを開示したが、他の方法として、ＳｅＮＢを維持したままのＨＯを行う場合、Ｓ－ＭｅＮＢは、ＳｅＮＢに対して、ＳｅＮＢを維持したままのＨＯであることを通知してもよい。あるいは、スプリットベアラ構成の変更の要求、ＳｅＮＢのためのＲＲＣに関する設定変更の要求を行わないことを通知してもよい。前述のＨＯが起動されることを示す情報とともに通知してもよい。

　これによって、ＳｅＮＢは、ＨＯ中に、該ＨＯがＳｅＮＢを維持したままのＨＯを行う場合か否かなどを認識することが可能となる。ＳｅＮＢを維持したままのＨＯの場合は、ＳｅＮＢは、該ＨＯ中はＳｅＮＢ起動の該ＵＥに対するベアラスプリット構成の変更を行わないようにすることができる。前述と同様の効果を得ることが可能となる。

　ＨＯ要求受諾応答メッセージを受信したＳ-ＭｅＮＢは、ステップＳＴ１２０５において、Ｔ－ＭｅＮＢにＨＯをさせるために、ＭＣＩ（Mobility Control Information）を含むＲＲＣ接続再構成（RRC Connection Reconfiguration）メッセージをＵＥに通知する。また、ＨＯ要求受諾応答メッセージを受信したＳ-ＭｅＮＢは、ＵＥに、ＳｅＮＢを用いたベアラスプリットの変更が無いことを通知してもよい。

　Ｓ－ＭｅＮＢはＵＥへ、該ＨＯ時、スプリットベアラを行うＥ－ＲＡＢ用のＳｅＮＢの変更が無いことを通知する。また、ＳｅＮＢのためのＲＲＣに関する設定変更が無いことを通知してもよい。該ＭＣＩを含むＲＲＣ接続再構成メッセージに一緒に含めて通知するとよい。

　ステップＳＴ１２０５でＭＣＩを含むＲＲＣ接続再構成メッセージを受信したＵＥは、ＳｅＮＢとの同期および接続を維持したまま、Ｓ－ＭｅＮＢからＴ－ＭｅＮＢへのＨＯを行う。ＵＥは、ＳｅＮＢとの無線リソースを維持したままＨＯを行う。例えば、ＵＥは、ＳｅＮＢに対するＭＡＣ設定をリセットしない。あるいは、ＳｅＮＢに対するＲＬＣ設定を再構成しない。この状態においてＵＥは、ＳｅＮＢとの通信が可能である。

　ＭｅＮＢに対する設定は、該ＭＣＩを含むＲＲＣ接続再構成メッセージのＭｅＮＢに対するＲＲＣに関する設定情報に従う。ＰＤＣＰは、ＭｅＮＢに位置するので、ＰＤＣＰの設定は、ＭｅＮＢに対する設定に従うとよい。例えば、Ｓ－ＭｅＮＢに対する設定からＴ－ＭｅＮＢに対する設定に再設定される。ＭＣＩを含むＲＲＣ接続再構成メッセージにおいて、ＭｅＮＢに対するＲＲＣに関する設定情報と、ＳｅＮＢに対するＲＲＣに関する設定情報とを個別に設けて、個別に設定可能とするとよい。これによって、ＵＥは、ＳｅＮＢに対する設定とＭｅＮＢに対する設定とを個別に、再構成あるいは維持あるいはデフォルト設定への移行が可能となる。この例では、ＵＥは、ＳｅＮＢに対する設定を維持したままＭｅＮＢに対する設定を再構成することが可能となるので、ＳｅＮＢの接続を維持したままＳ－ＭｅＮＢからＴ－ＭｅＮＢへの変更が可能となる。

　ＵＥからＳｅＮＢへの上りデータの取扱い方法について以下に開示する。ＵＥは、ＳｅＮＢと接続を維持したままＨＯを行う場合でも、ＳｅＮＢがＳ－ＭｅＮＢと接続しているかＴ－ＭｅＮＢと接続しているか認識しない。ＨＯ処理中、もし、ＳｅＮＢがまだＴ－ＭｅＮＢと接続していないときに、ＵＥがＳｅＮＢに上りデータを送信した場合、ＳｅＮＢはＴ－ＭｅＮＢ上りデータを送信することができず、該上りデータのロスを引き起こすことになる。ここでは、そのような問題を解決する方法を開示する。

　ＵＥは、Ｓ－ＭｅＮＢからＭＣＩ受信後、上りデータの送信を停止し、バッファに記憶する。また、ＵＥは、Ｔ－ＭｅＮＢとのＲＲＣ接続再構成が完了するまで上りデータの送信を停止し、バッファに記憶する。ＵＥは、Ｔ－ＭｅＮＢとのＲＲＣ接続再構成完了メッセージを通知後上りデータを送信する。ＵＥは、Ｓ－ＭｅＮＢからＭＣＩ受信後の新たな上りデータの送信を停止し、バッファに記憶するとよい。該上りデータとして、ＵＥから送信する上りデータ全てとするとよい。ＵＥは、Ｔ－ＭｅＮＢへの直接のパスで送信する上りデータと、ＳｅＮＢを介したＴ－ＭｅＮＢへのパスで送信する上りデータとを振り分ける前に停止し、バッファに記憶するとよい。あるいは、たとえ、Ｔ－ＭｅＮＢへの直接のパスで送信する上りデータと、ＳｅＮＢを介したＴ－ＭｅＮＢへのパスで送信する上りデータとがＵＥ内で振り分けられたとしても、両方を停止し、バッファに記憶するとよい。ＵＥにおける上りデータの処理として、ＰＤＣＰ　ＳＮのナンバリングは行ってもよい。このようにすることによって、上りデータのロスが生じる問題を解決することが可能となる。

　ステップＳＴ１２０５において、Ｓ－ＭｅＮＢから、Ｔ－ＭｅＮＢへのＨＯを指示するＭＣＩを受信したＵＥは、ステップＳＴ１２０６において、上りデータの送信を停止し、バッファに記憶する。ステップＳＴ１２０７において、ＵＥはＭＣＩに従い、Ｓ－ＭｅＮＢからＴ－ＭｅＮＢに接続変更処理を行う。

　ステップＳＴ１２０７において、ＵＥは、ＭＣＩを受信した後、Ｓ－ＭｅＮＢとの接続を切断してＴ－ＭｅＮＢと接続を行う。ＵＥは、ステップＳＴ１２０５のＲＲＣ接続再構成メッセージで受信した内容を用いて、Ｔ－ＭｅＮＢのためのＲＲＣ接続の再構成を行い、Ｔ－ＭｅＮＢと接続を行う。

　ＵＥは、ステップＳＴ１２１２でＴ－ＭｅＮＢとＲＡ処理を行い、ステップＳＴ１２１３でＴ－ＭｅＮＢ対してＲＲＣ接続再構成完了メッセージを通知する。

　ＵＥは、Ｔ－ＭｅＮＢにＲＲＣ接続再構成完了メッセージ通知後、Ｔ－ＭｅＮＢとの間で直接データ通信を行うことが可能となる。

　ＵＥは、Ｔ－ＭｅＮＢとのＲＲＣ接続再構成完了メッセージを通知後、上りデータを送信する。上りデータは、ＵＥにおいて、Ｔ－ＭｅＮＢへ直接送信するパスとＳｅＮＢを介してＴ－ＭｅＮＢへ送信するパスとに分割され、ＵＥは、Ｔ－ＭｅＮＢ、ＳｅＮＢ各々に対して、上りデータを送信する。

　ステップＳＴ１２１９において、ＵＥは、Ｔ－ＭｅＮＢへ直接送信するパスで上りデータを送信する。ステップＳＴ１２２０において、ＵＥは、ＳｅＮＢに上りデータを送信する。上りデータの送信はＰＤＣＰ　ＳＮに従って送信してもよい。

　ＵＥあるいはＳｅＮＢは、ＵＥがＳ－ＭｅＮＢからＴ－ＭｅＮＢにＨＯ中、ＵＥとＳｅＮＢ間の同期処理を必要に応じて行っておくとよい。あるいは、ＵＥがＳｅＮＢに対して上りデータ送信開始前に行ってもよい。ＲＡ処理を用いてもよい。

　ＵＥは、ＭＣＩの受信前、すなわち上りデータの送信が停止される前にＳｅＮＢとの間で送受信していたＳ－ＭｅＮＢへの上りデータについては送信処理を続けてもよい。Ｓ－ＭｅＮＢとの間で直接行っていた上りデータについても送信不達となるまで送信処理を続けてもよい。これらは、Ｓ－ＭｅＮＢによって通知されたオーバヘッド圧縮設定などを用いて行う。

　ＵＥは、ＭＣＩの受信前、すなわち上りデータの送信が停止される前にＳ－ＭｅＮＢと直接またはＳｅＮＢを介してＳ－ＭｅＮＢとの間で送受信していた上りデータのうち、送信を失敗したデータから、Ｔ－ＭｅＮＢへの送信を開始してもよい。ＵＥは、送信を失敗したデータのうち、ＰＤＣＰ　ＳＮの最も小さいデータからＴ－ＭｅＮＢへ送信を開始してもよい。該データから、ＵＥは、Ｔ－ＭｅＮＢ直接あるいはＳｅＮＢを介してＴ－ＭｅＮＢに送信するとよい。

　このようにすることによって、データのロスを最小にすることが可能となる。また、この方法は、ＳｅＮＢでの上りデータのバッファが少なくて済むので、ＳｅＮＢのバッファ容量の低減および構成の簡易化を可能とする。ＳｅＮＢを安価にすることが可能となる。

　Ｔ－ＭｅＮＢへの送信は、Ｔ－ＭｅＮＢへ直接およびＳｅＮＢを介してＴ－ＭｅＮＢへ送信する両方の場合において、Ｔ－ＭｅＮＢによって設定されたヘッダ圧縮設定を用いるとよい。

　ＳｅＮＢを介して上りデータをＴ－ＭｅＮＢに送信するパスにおいて、ＳｅＮＢがまだＴ－ＭｅＮＢと接続していない場合がある。このような場合、ＳｅＮＢは、Ｔ－ＭｅＮＢとのＭｅＮＢ設定の変更が完了するまで、ＵＥからの上りデータをバッファに記憶するとよい。ＳｅＮＢは、Ｔ-ＭｅＮＢとのＭｅＮＢ設定変更完了後、ＵＥからの上りデータをＴ-ＭｅＮＢに送信する。ＳｅＮＢは、データのＰＤＣＰ　ＳＮを用いてリオーダリングして送信してもよい。

　これによって、ＳｅＮＢとＴ－ＭｅＮＢとの間でＭｅＮＢ設定変更が何らからの理由で遅延し、ＵＥからＳｅＮＢへの上りデータ送信が行われてしまったような場合でも、ＳｅＮＢにおけるデータのロスが発生する問題を解決することができる。

　上りデータのロスが発生する問題を解決する他の方法を開示する。ＵＥはＴ-ＭｅＮＢとの接続完了を待たずに上りデータをＳｅＮＢに送信する。ＳｅＮＢは、Ｔ－ＭｅＮＢとのＭｅＮＢ設定の変更が完了するまで、ＵＥからの上りデータをバッファに記憶する。ＳｅＮＢは、Ｔ-ＭｅＮＢとのＭｅＮＢ設定変更完了後、ＵＥからの上りデータをＴ-ＭｅＮＢに送信する。ＳｅＮＢは、データのＰＤＣＰ　ＳＮを用いてリオーダリングして送信してもよい。これによって、ＳｅＮＢにおけるデータのロスが発生する問題を解決することができる。

　この場合、前述の方法に比べて、ＳｅＮＢに必要となるバッファ量は大きくなるが、ＳｅＮＢとＴ－ＭｅＮＢとの間でＭｅＮＢの設定変更が行われると、直ちにＳｅＮＢからＴ－ＭｅＮＢへバッファしていた上りデータを送信することが可能となるので、ＵＥからの上りデータが早期にＴ－ＭｅＮＢに送達することが可能となる。

　ＵＥがＴ-ＭｅＮＢに接続完了を通知する前に上りデータをＳｅＮＢに送信する具体例を説明する。

　ＵＥがＳ－ＭｅＮＢからＭＣＩを受信後、新たな上りデータを、ＳｅＮＢを介してＴ－ＭｅＮＢに送信する。Ｔ－ＭｅＮＢは、Ｓ－ＭｅＮＢを介してＵＥに、ヘッダ圧縮設定を通知し、ＵＥは、ＳｅＮＢを介したＴ－ＭｅＮＢとの新たな上り通信に該ヘッダ圧縮設定を用いる。

　この場合、ＵＥは、ＭＣＩ受信前にＳｅＮＢとの間で行っていたＳ－ＭｅＮＢへの上りデータの送信を停止するとよい。Ｓ-ＭｅＮＢへの上りデータ送信失敗したデータも、Ｔ-ＭｅＮＢによるヘッダ圧縮設定でＳｅＮＢへ送信してもよい。ＵＥは、データ送信を失敗したデータのうち、ＰＤＣＰ　ＳＮの最も小さいデータからＳｅＮＢを介してＴ－ＭｅＮＢへ送信開始してもよい。

　あるいは、ＵＥは、ＳｅＮＢとの間において、Ｓ-ＭｅＮＢ向とＴ-ＭｅＮＢ向との両方の上りデータを送信してもよい。ＳｅＮＢはこれらを、どちらのヘッダ圧縮が用いられているかを識別することでどちらに向けての上りデータかを判断してもよい。あるいは、他の方法として、ＵＥからＳｅＮＢへの上りデータに、どちら向けの上りデータかを示す情報を含めてあるいは付加して送信するとよい。例えば該情報を１ビットとして含める。１ビットの設定方法として、例えば、ＳｅＮＢがユーザプレインデータのみしか送受信しない場合、ＰＤＣＰフォーマットのＤ／Ｃビットを該情報用のビットとして設定するようにしてもよい。

　ＳｅＮＢは、Ｔ－ＭｅＮＢとのＭｅＮＢ設定の変更が完了するまで、ＵＥからの上りデータをバッファし、Ｔ-ＭｅＮＢとのＭｅＮＢ設定変更が完了した後、ＵＥからの上りデータをＴ-ＭｅＮＢに送信する。ＳｅＮＢは、データのＰＤＣＰ　ＳＮを用いてリオーダリングして送信してもよい。

　Ｓ－ＭｅＮＢがＵＥから受信した上りデータについて説明する。Ｓ－ＭｅＮＢが受信したＵＥからの上りデータは、ＵＥから直接受信した上りデータもＳｅＮＢを介して受信した上りデータもあわせて、ＰＤＣＰ　ＳＮによって管理するとよい。Ｓ－ＭｅＮＢは、ＰＤＣＰ　ＳＮに従ってリオーダリングしてＳ－ＧＷに送信する。

　Ｓ－ＭｅＮＢがＵＥにＭＣＩを送信した場合、ＭＣＩを送信するときに直接ＵＥとの間で通信中の上りデータは、Ｓ－ＭｅＮＢにデータ送達成功後、Ｓ－ＭｅＮＢからＳ－ＧＷへ送信してもよい。また、同様に、ＭＣＩを送信するときにＳｅＮＢを介してＵＥとの間で通信中の上りデータは、Ｓ－ＭｅＮＢにデータ送達成功後、Ｓ－ＧＷへ送信してもよい。Ｓ－ＧＷで、Ｓ－ＭｅＮＢから受信したデータとＴ－ＭｅＮＢから受信したデータとの順序管理を行うとよい。

　ＵＥがＭＣＩを受信した時点で送信完了と判断していたデータが、何らかの原因でＳ－ＭｅＮＢへまだ送達成功していない場合、ＵＥがＴ－ＭｅＮＢに対して該データを送信しないことによって発生するデータの損失を防ぐことができる。また、Ｓ－ＭｅＮＢからＳ－ＧＷへ送信する代わりに、Ｔ－ＭｅＮＢへ転送（フォワーディング（forwarding））してもよい。Ｔ－ＭｅＮＢにおいて、ＰＤＣＰ　ＳＮに従ってリオーダリングしてＳ－ＧＷに送信するとよい。これによって、Ｓ－ＧＷに送信する方法と同様の効果が得られる。

　また、Ｓ－ＭｅＮＢが該データをＳ－ＧＷへ送信するのか、Ｔ－ＭｅＮＢへ転送するのかを設定可能としてもよい。設定する主体としては、ＲＡＮ側あるいはコアネットワーク側のノードとするとよい。該設定情報は、予めＳ－ＭｅＮＢに通知されるとよい。例えば、ＭＭＥ、あるいはＳ－ＧＷは、Ｓ－ＭｅＮＢに対して該設定情報を予め通知する。

　また、Ｓ－ＭｅＮＢがＵＥにＭＣＩを送信した場合、直前に送達失敗したデータ後に送達成功したデータを、Ｓ－ＧＷへ送信、あるいはＴ－ＭｅＮＢへ転送（フォワーディング（forwarding））してもよい。ＵＥでは送達失敗したデータからＴ－ＭｅＮＢで上り送信が行われる。ＵＥがＨＯ完了後Ｔ－ＭｅＮＢとの間で該データ以降のデータの送達が失敗したような場合、該転送されたデータを利用できる。

　ＭｅＮＢからＳｅＮＢを介してＵＥへ通知する下りデータの取扱い方法について、以下に開示する。

　ステップＳＴ１２０３でＨＯ要求受諾応答メッセージ受信したＳ－ＭｅＮＢは、新たな下りデータの送信を停止し、バッファに記憶する。該下りデータとして、ＨＯをさせるＵＥへ送信する下りデータ全てとするとよい。Ｓ－ＭｅＮＢは、ＵＥへの直接のパスで送信する下りデータと、ＳｅＮＢを介したＵＥへのパスで送信する下りデータを振り分ける前に停止し、バッファに記憶するとよい。あるいは、たとえ、ＵＥへの直接のパスで送信する下りデータと、ＳｅＮＢを介したＵＥへのパスで送信する下りデータとがＳ－ＭｅＮＢ内で振り分けられたとしても、両方のデータの送信を停止し、バッファに記憶するとよい。Ｓ－ＭｅＮＢにおける下りデータの処理として、ＰＤＣＰ　ＳＮのナンバリングは行ってもよい。

　Ｓ－ＭｅＮＢは、ＨＯ要求受諾応答メッセージの受信前、すなわちデータの送信が停止される前にＵＥとの間で送受信していた下りデータのうち、送信不達となった下りデータ以降の下りデータを、Ｔ－ＭｅＮＢに対して転送（フォワーディング（forwarding））する。

　送信不達となった下りデータのうち、ＰＤＣＰ　ＳＮの最も小さいデータからＴ－ＭｅＮＢへ転送（フォワーディング（forwarding））するとよい。Ｓ－ＭｅＮＢからＵＥへの直接のパスによって送信した下りデータおよびＳｅＮＢを介したパスによって送信した下りデータをあわせて最もＰＤＣＰ　ＳＮが小さいデータからＴ－ＭｅＮＢへ転送（フォワーディング（forwarding））するとよい。

　ステップＳＴ１２０８において、Ｓ－ＭｅＮＢは、Ｔ－ＭｅＮＢへの転送（フォワーディング（forwarding））を開始し、ステップＳＴ１２０９において、ＳＮ状況伝達（SN Status Transfer）を行い、ステップＳＴ１２１０でデータ転送（Data Forwarding）を行う。転送は、ＰＤＣＰ　ＳＮで管理され、ステップＳＴ９４２およびステップＳＴ９４４において通知されるＳ-ＧＷからのエンドマーカまでが転送される。

　ステップＳＴ１２１１において、Ｔ－ＭｅＮＢは、Ｓ－ＭｅＮＢから転送（フォワーディング（forwarding））されたデータをバッファに記憶する。

　このようにすることによって、たとえ、ＵＥがＳｅＮＢを用いてデュアルコネクティビティを行っていたとしても、ＨＯ処理時に下りデータのロスが生じるのを防ぐことが可能となる。

　Ｔ－ＭｅＮＢは、ＵＥとの直接のＲＲＣ接続再構成が完了するまで、および、ＳｅＮＢにおけるＭｅＮＢ変更処理が完了するまで、下りデータをバッファに記憶する。Ｔ－ＭｅＮＢは、ベアラスプリットによって、ＵＥとの直接のパスによる下りデータと、ＳｅＮＢを介したパスによる下りデータとを、分離する前にバッファしてもよいし、分離した後にバッファしてもよい。いずれも、ナンバリングされたＰＤＣＰ　ＳＮで管理することが可能である。ＵＥにおいてもＰＤＣＰ　ＳＮでリオーダリングすることが可能となる。

　分離する前にバッファに記憶する方法の場合、ＳｅＮＢを用いたベアラスプリット構成を変更する場合に、両方のパスともに新たなベアラスプリット構成が設定された後に、該ベアラスプリット構成に適した、データの分離のためのスケジューリングを可能とする。したがって、デュアルコネクティビティのＵＥにとって効率がよいスケジューリングを行うことができる。

　他方、分離した後にバッファに記憶する方法の場合、両方のパスが利用可能となった場合に即時に該両方のパスを用いて下りデータをＵＥに送信することが可能となる。すなわち、遅延量の増大を防ぐことができる。

　Ｔ－ＭｅＮＢは、ＵＥとの直接の接続が完了したとき、および、ＳｅＮＢにおけるＭｅＮＢ変更処理が完了したとき、各パスに下りデータを分離スケジューリングして、各パスを用いてＵＥに対して下りデータを送信する。

　他の方法を開示する。Ｔ－ＭｅＮＢは、ＵＥとの直接の接続の完了、およびＳｅＮＢとのＭｅＮＢ変更通知完了のいずれか早い方で、ＵＥへの下りデータ送信を開始する。

　Ｔ－ＭｅＮＢがデータを分離する前にバッファに記憶する場合は、両方のパスが設立するまで、早い方のパスで下りデータ送信を行う。その後、両方のパスが設立したときに、ベアラスプリットを開始するとよい。

　Ｔ－ＭｅＮＢがデータを分離した後にバッファに記憶する場合は、各パスの設立に応じて下りデータ送信を行うとよい。

　このようにすることによって、可能な限り早期に下りデータをＵＥに送信することができる。

　ＳｅＮＢは、ＭｅＮＢによって、ＵＥに対するデュアルコネクティビティのためのベアラスプリットの構成を通知される。また、ＳｅＮＢの該ＵＥに対するＲＲＣに関する設定情報は該ＭｅＮＢによって通知される。

　したがって、ＳｅＮＢはどのＭｅＮＢから該ベアラスプリットの構成が通知されたか、どのＭｅＮＢにＳｅＮＢが設定したＲＲＣに関する設定情報を通知すればよいか、などを認識する必要がある。すなわち、該ＭｅＮＢを認識する必要がある。

　前者のＭｅＮＢと後者のＭｅＮＢとを別に設定してもよいが、ここでは、同一である場合について説明する。該ＭｅＮＢを、ＳｅＮＢの制御ＭｅＮＢと称する。

　デュアルコネクティビティ中のＵＥのＨＯ処理において、ＳｅＮＢの変更は行わず、ＭｅＮＢがＳ－ＭｅＮＢからＴ－ＭｅＮＢに変更される場合について、該ＳｅＮＢの制御ＭｅＮＢがどのＭｅＮＢに変更されたかを認識する方法を以下に開示する。具体例として、以下の（１），（２）の２つを開示する。
　（１）Ｓ－ＭｅＮＢがＳｅＮＢに制御ＭｅＮＢの変更を通知する。
　（２）Ｔ－ＭｅＮＢがＳｅＮＢに制御ＭｅＮＢの変更を通知する。

　前記具体例（１）について具体例を開示する。Ｔ－ＭｅＮＢは、ＵＥからＲＲＣ接続再構成完了メッセージを受信すると、Ｓ－ＭｅＮＢに対して、ＳｅＮＢの制御ＭｅＮＢ変更要求メッセージの通知を行う。該通知はＸ２シグナリングを用いて行うとよい。該通知に、制御ＭｅＮＢの変更を行うＳｅＮＢの識別子を含めて通知してもよい。また、変更の理由情報を含めて通知してもよい。ＨＯによるＭｅＮＢの変更であることを示す情報を設けて通知してもよい。

　該通知を受信したＳ－ＭｅＮＢは、制御ＭｅＮＢの変更を行うＳｅＮＢへ、制御ＭｅＮＢの変更を通知する。該通知はＸ２シグナリングを用いて行ってもよい。あるいはＭｅＮＢとＳｅＮＢ間に設けられるインタフフェース上のシグナリングを用いて行ってもよい。

　該シグナリングに含める情報の具体例として、以下の（１）～（７）の７つを開示する。
　（１）制御ＭｅＮＢの変更を示す情報。
　（２）変更後の制御ＭｅＮＢの識別子。ここでは、Ｔ－ＭｅＮＢの識別子。
　（３）ＳｅＮＢを用いたパスのベアラ識別子。ここでは、Ｅ－ＲＡＢ識別子（E-RAB IDなどであってもよい）、あるいは、ＥＰＳベアラ識別子。
　（４）ＳｅＮＢにおける制御ＭｅＮＢを変更するスプリットベアラの識別子。
　（５）ベアラスプリット構成の設定要求したＭｅＮＢの識別子。ここでは、Ｓ－ＭｅＮＢの識別子。
　（６）ベアラスプリットを用いてデュアルコネクティビティを行うＵＥの識別子。
　（７）前記（１）～（６）の組合せ。

　制御ＭｅＮＢ変更通知メッセージを受信したＳｅＮＢは、該変更通知メッセージに含まれる情報から、ＭｅＮＢの変更を行うスプリットベアラを特定する。ＳＭｅＮＢは、該スプリットベアラの制御ＭｅＮＢを変更後のＭｅＮＢに変更する。ＳｅＮＢにおけるスプリットベアラの管理は制御ＭｅＮＢの識別子と関連付けて行うとよい。すなわち、スプリットベアラの識別子と制御ＭｅＮＢの識別子とを関連付けておくとよい。このようにすることによって、ＳｅＮＢは、デュアルコネクティビティを行うＵＥのためのスプリットベアラの制御ＭｅＮＢの変更が可能となる。

　ＳｅＮＢは、制御ＭｅＮＢの変更後、該スプリットベアラの修正、リリースの要求は、変更後の制御ＭｅＮＢからのみ受入れることとする。また、ＳｅＮＢは、変更後のＭｅＮＢとデータの通信を行うこととする。

　このようにすることによって、ＳｅＮＢは制御ＭｅＮＢがどのＭｅＮＢに変更されたかを認識することができ、変更後の制御ＭｅＮＢとの間で該ＵＥに対する該スプリットベアラの修正、リリースの要求などの制御のための通信、およびデータ通信を行うことが可能となる。

　このようにすることによって、変更後のＭｅＮＢ、ここではＴ－ＭｅＮＢは、ＳｅＮＢの制御ＭｅＮＢが変更されたことを認識することができ、該ＳｅＮＢに対して、該ＵＥに対する該スプリットベアラの修正、リリースの要求などの制御のための通信、およびデータ通信を開始することが可能となる。

　変更後ＭｅＮＢは、ＳｅＮＢに対して、該ＵＥに対する該スプリットベアラの制御ＭｅＮＢが変更になったことを確認するメッセージを通知してもよい。また、ＳｅＮＢは該メッセージに対して応答してもよい。

　前記具体例（２）について具体例を開示する。Ｔ－ＭｅＮＢは、ＵＥからＲＲＣ接続再構成完了メッセージを受信すると、ＳｅＮＢに、制御ＭｅＮＢ変更要求メッセージの通知を行う。該ＳｅＮＢの識別子は、Ｓ－ＭｅＮＢから受信したＨＯ要求メッセージ含まれるＳｅＮＢ情報を用いるとよい。該通知はＸ２シグナリングを用いて行うとよい。あるいはＭｅＮＢとＳｅＮＢ間に設けられるインタフフェース上のシグナリングを用いて行ってもよい。該シグナリングに含める情報は、前記具体例（１）の方法で開示したものを適用することができる。

　このようにすることによって、ＳｅＮＢは、制御ＭｅＮＢが、どのＭｅＮＢに変更されたかを認識することができ、変更後の制御ＭｅＮＢとの間で該ＵＥに対する該スプリットベアラの修正、リリースの要求などの制御のための通信、およびデータ通信を行うことが可能となる。

　このようにすることによって、変更前のＭｅＮＢ、ここではＳ－ＭｅＮＢは、ＳｅＮＢの制御ＭｅＮＢが変更されたことを認識することができ、該ＳｅＮＢに対して、該ＵＥに対する該スプリットベアラの修正、リリースの要求などの制御のための通信、およびデータ通信を終了することが可能となる。

　また、ＳｅＮＢを用いてデュアルコネクティビティ中のＵＥのＨＯが行われた場合、ＳｅＮＢは、変更後のＭｅＮＢ（Ｔ－ＭｅＮＢ）とスプリットベアラ構成に関する制御のための通信、およびデータ通信を行うことが可能となる。

　ＳｅＮＢのＭｅＮＢ変更処理について、具体例を説明する。図２１のステップＳＴ１２１３でＵＥからＲＲＣ接続再構成完了メッセージを受信したＴ－ＭｅＮＢは、ステップＳＴ１２１４において、Ｓ－ＭｅＮＢに対してＳｅＮＢの制御ＭｅＮＢの変更要求メッセージを通知する。該メッセージに、制御ＭｅＮＢの変更を行うＳｅＮＢの識別子を含める。

　該メッセージを受信したＳ－ＭｅＮＢは、ステップＳＴ１２１５において、制御ＭｅＮＢの変更を行うＳｅＮＢに対して、制御ＭｅＮＢの変更を要求するメッセージを通知する。該メッセージに、制御ＭｅＮＢの変更を示す情報、Ｔ－ＭｅＮＢの識別子、ＳｅＮＢを用いたパスのベアラ識別子、ＳｅＮＢにおける制御ＭｅＮＢを変更するスプリットベアラの識別子、Ｓ－ＭｅＮＢの識別子、ＳｅＮＢを用いてデュアルコネクティビティを行うＨＯ対象のＵＥの識別子を含める。このようにすることによって、ＳｅＮＢは、どのＭｅＮＢが設定したどのスプリットベアラについて制御ＭｅＮＢの変更を行えばよいかを認識することができる。

　該メッセージを受信したＳｅＮＢは、ステップＳＴ１２１６において、ステップＳＴ１２１５で受信した情報を用いて、制御ＭｅＮＢの変更を行う。これによって、ＳｅＮＢは、以降、変更後のＭｅＮＢであるＴ－ＭｅＮＢとスプリットベアラに関する制御のための通信およびデータ通信を行う。制御ＭｅＮＢを変更したＳｅＮＢは、変更前の制御ＭｅＮＢとの制御のための通信およびデータ通信を終了する。

　制御ＭｅＮＢの変更を行ったＳｅＮＢは、ステップＳＴ１２１７でＳ－ＭｅＮＢに対して、制御ＭｅＮＢを変更したことを通知するために、制御ＭｅＮＢ変更応答メッセージを通知する。該応答メッセージを受信したＳ－ＭｅＮＢは、ステップＳＴ１２１８でＴ－ＭｅＮＢに対してＳｅＮＢの制御ＭｅＮＢ変更が終了したことを通知するためＳｅＮＢの制御ＭｅＮＢ変更応答メッセージを通知する。これによって、Ｔ－ＭｅＮＢは、ＳｅＮＢのＭｅＮＢがＴ－ＭｅＮＢに変更されたことを認識することができる。したがって、Ｔ－ＭｅＮＢは、ＳｅＮＢと、スプリットベアラに関する制御のための通信およびデータ通信を行うことが可能となる。

　これによって、ステップＳＴ１２２０、ステップＳＴ１２２１において、Ｔ－ＭｅＮＢからＵＥへの下りデータも、ＵＥからＴ－ＭｅＮＢへの上りデータも、ＳｅＮＢを介して通信を行うことが可能となる。

　図１２に示すステップＳＴ１２１４からステップＳＴ１２１８を、ステップＳＴ１２２２とする。ステップＳＴ１２２２は、Ｔ－ＭｅＮＢ、Ｓ－ＭｅＮＢ、ＳｅＮＢで行われるＳｅＮＢのＭｅＮＢ変更処理を示す。

　その後のステップＳＴ９３９からステップＳＴ９４７の、ＭｅＮＢ変更のためのＳ－ＧＷにおけるパス切り替え処理は、図１２と同様であるので、説明を省略する。

　これによって、Ｓ－ＧＷと、ＨＯ対象であったＵＥとの間において、Ｔ－ＭｅＮＢ、あるいは、Ｔ－ＭｅＮＢとＳｅＮＢを介したデータ通信を行うことが可能となる。

　Ｓ－ＧＷとＵＥとの間でのデータ通信は、一つは、ステップＳＴ１００５において、Ｓ－ＭｅＮＢとＵＥ間でデータが直接通信され、もう一つは、ステップＳＴ１００７とステップＳＴ１００８において、Ｓ－ＭｅＮＢとＵＥとの間でデータがＳｅＮＢを介して通信される。ステップＳＴ１００６において、Ｓ－ＭｅＮＢとＳ－ＧＷとの間は１つのパスでデータが通信される。

　本実施の形態で開示した方法とすることによって、ベアラスプリットによるデュアルコネクティビティ中のＵＥがＭｅＮＢ間ＨＯを行うことが可能となる。

　ＳｅＮＢへのＭｅＮＢ変更処理ステップＳＴ１２２２について、他の方法を開示する。前述に開示した方法では、ＳｅＮＢへのＭｅＮＢ変更処理は、Ｔ－ＭｅＮＢがＵＥからＲＲＣ接続再構成完了メッセージを受信した後に行った。

　他の方法として、Ｔ－ＭｅＮＢがＳ－ＭｅＮＢに対してＨＯ要求受諾応答メッセージを通知した後、あるいは、Ｓ－ＭｅＮＢがＴ－ＭｅＮＢからＨＯ要求受諾応答メッセージを受信した後、あるいは、Ｓ－ＭｅＮＢがＵＥにＭＣＩを含むＲＲＣ接続再構成メッセージを送信した後に、ＳｅＮＢへのＭｅＮＢ変更処理を行うようにしてもよい。ＳｅＮＢへのＭｅＮＢ変更処理は、前述の方法を適用するとよい。

　このようにすることによって、早期に、ＳｅＮＢにおいて制御ＭｅＮＢをＴ－ＭｅＮＢに変更することが可能となるので、早期に、ＳｅＮＢとＴ-ＭｅＮＢとの間でデータ通信を行うことが可能となる。

　したがって、ＵＥは上りデータを、Ｔ－ＭｅＮＢとＲＲＣ接続再構成完了するまで送信停止し、バッファしなくてよい。あるいは、ＳｅＮＢにおいて送信停止しバッファしなくてよい。ＵＥは、ＳｅＮＢを用いたスプリットベアラによって、ＳｅＮＢを介してＴ－ＭｅＮＢに対して早期に上りデータを通信することが可能となる。

　また、Ｔ－ＭｅＮＢは下りデータを、ＵＥからＲＲＣ接続再構成完了を受信するまで送信停止し、バッファしなくてよい。Ｔ－ＭｅＮＢは、ＳｅＮＢを用いたスプリットベアラによって、ＳｅＮＢを介してＵＥに対して早期に上りデータを通信することが可能となる。

　これは、ＵＥとＴ－ＭｅＮＢ間の直接のパスによるデータ通信がまだ行なわれない間も、ＵＥとＴ－ＭｅＮＢとの間でＳｅＮＢを介したパスを用いて通信が可能になる。これによって、ＨＯ時のデータ通信処理を低遅延で行うことが可能となり、ＨＯ時のデータロスを低減させることが可能となる。

　ＳｅＮＢへのＭｅＮＢ変更処理ステップＳＴ１２２２について、他の方法を開示する。Ｔ－ＭｅＮＢが、ＭＭＥおよびＳ－ＧＷに対して行うパススイッチ処理を完了した後に、ＳｅＮＢへのＭｅＮＢ変更処理を行うようにしてもよい。Ｔ-ＭｅＮＢは、ＭＭＥからパススイッチ要求受諾応答メッセージを受信したときに、ＳｅＮＢへＭｅＮＢの変更通知を行う。

　あるいは、Ｓ－ＭｅＮＢは、Ｔ－ＭｅＮＢからＵＥコンテキストリリース（UE context release）メッセージを受信したときに、ＳｅＮＢへＭｅＮＢの変更通知を行う、としてもよい。ＳｅＮＢへのＭｅＮＢ変更処理は、前述の方法を適用するとよい。

　このようにすることによって、ＭＭＥおよびＳ－ＧＷのＴ－ＭｅＮＢへのパス切替えも含めてＨＯ処理が終了した後に、ＳｅＮＢを用いたスプリットベアラによるデータ通信を行うことが可能となる。確実にＨＯ処理が終了した後に行うことによって、データ通信の制御の複雑化を避けることが可能となる。

　実施の形態４．
　図２３～図２５は、本発明の実施の形態４の通信システムにおけるハンドオーバ関連処理のシーケンスの一例を示す図である。図２３と図２４とは、境界線ＢＬ５で接続されている。図２４と図２５とは、境界線ＢＬ６で接続されている。本実施の形態のハンドオーバ関連処理は、前述の図１０～図１３に示す実施の形態１、図１７～図１９に示す実施の形態２、および図２０～図２２に示す実施の形態３のハンドオーバ関連処理と類似するので、同一のステップについては同一のステップ番号を付して、説明を省略する。

　本実施の形態では、前述の実施の形態３と下りデータの取扱い方法が異なる。本実施の形態において、ＭｅＮＢからＳｅＮＢを介してＵＥへ通知する下りデータの取扱い方法について以下に開示する。

　本実施の形態では、ステップＳＴ１２０３でＨＯ要求受諾応答メッセージ受信したＳ－ＭｅＮＢは、新たな下りデータの送信を停止し、バッファに記憶する。下りデータとして、ＨＯをさせるＵＥへ送信する下りデータ全てとするとよい。Ｓ－ＭｅＮＢは、ＵＥへの直接のパスで送信する下りデータと、ＳｅＮＢを介したＵＥへのパスで送信する下りデータを振り分けた後にストップし、バッファに記憶して、ＳｅＮＢを介したＵＥへのパスで送信する下りデータはストップせずに、送信を継続するとよい。Ｓ－ＭｅＮＢにおける下りデータの処理として、ＰＤＣＰ　ＳＮのナンバリングは行ってもよい。

　Ｓ－ＭｅＮＢは、ＨＯ要求受諾応答メッセージの受信前、すなわちデータの送信が停止される前にＵＥとの間で送受信していた下りデータのうち、送信不達となった下りデータ以降の下りデータを、Ｔ－ＭｅＮＢに対して転送（フォワーディング（forwarding））する。送信不達となった下りデータのうち、ＰＤＣＰ　ＳＮの最も小さいデータからＴ－ＭｅＮＢへ転送（フォワーディング（forwarding））するとよい。Ｓ－ＭｅＮＢからＵＥへの直接のパスによって送信した下りデータのうち最もＰＤＣＰ　ＳＮが小さいデータからＴ－ＭｅＮＢへ転送（フォワーディング（forwarding））するとよい。

　ステップＳＴ１３０１において、Ｓ－ＭｅＮＢは、Ｔ－ＭｅＮＢへの転送（フォワーディング（forwarding））を開始し、ステップＳＴ１２０９において、ＳＮ状況伝達（SN Status Transfer）を行い、ステップＳＴ１２１０において、データ転送（Data Forwarding）を行う。転送は、ＰＤＣＰ　ＳＮで管理され、ステップＳＴ９４２およびステップＳＴ９４４において通知されるＳ-ＧＷからのエンドマーカまでが転送される。

　以降のステップは、実施の形態３と同様に実行される。具体的には、ステップＳＴ１２１１において、Ｔ－ＭｅＮＢは、Ｓ－ＭｅＮＢから転送（フォワーディング（forwarding））されたデータをバッファに記憶する。

　本実施の形態では、Ｔ－ＭｅＮＢは、ＵＥとの直接のＲＲＣ接続再構成が完了するまで、および、ＳｅＮＢにおけるＭｅＮＢ変更処理が完了するまで、下りデータをバッファに記憶する。Ｔ－ＭｅＮＢは、ベアラスプリットによって、ＵＥとの直接のパスによる下りデータと、ＳｅＮＢを介したパスによる下りデータとを、分離した後にバッファに記憶するとよい。ナンバリングされたＰＤＣＰ　ＳＮで管理することが可能である。ＵＥにおいてもＰＤＣＰ　ＳＮでリオーダリングすることが可能となる。

　他方、分離した後にバッファに記憶する方法の場合、両方のパスが利用可能となった場合に即時に該両方のパスを用いて下りデータをＵＥに送信可能となる。すなわち、遅延量の増大を防ぐことができる。

　以降のステップは、実施の形態３と同様に実行される。Ｔ－ＭｅＮＢは、ＵＥとの直接の接続が完了したとき、および、ＳｅＮＢにおけるＭｅＮＢ変更処理が完了したとき、各パスに下りデータを分離スケジューリングして、各パスを用いてＵＥに対して下りデータを送信する。

　このようにすることによって、可能な限り早期に、下りデータをＵＥに送信することができる。

　実施の形態５．
　図２６～図２８は、本発明の実施の形態５の通信システムにおけるハンドオーバ関連処理のシーケンスの一例を示す図である。図２６と図２７とは、境界線ＢＬ７で接続されている。図２７と図２８とは、境界線ＢＬ８で接続されている。

　本実施の形態では、Ｓ－ＭｅＮＢからＴ－ＭｅＮＢへのハンドオーバが行われる前は、ＥＰＳに対応するベアラ（以下「ＥＰＳベアラ」という場合がある）として、ベアラ２（以下「ＥＰＳベアラ＃２」と記載する場合がある）を用いて、ＳｅＮＢとＳ－ＭｅＮＢとの両方が、ＵＥとの間でデータの送受信を行う。ハンドオーバの処理中は、ＳｅＮＢのみが、ＵＥとの間でデータの送受信を行う。ハンドオーバの処理後は、ＳｅＮＢとＴ－ＭｅＮＢとの両方が、ＵＥとの間でデータの送受信を行う。

　一例として、ＥＰＳベアラ＃２を用いて、ＳｅＮＢおよびＳ－ＭｅＮＢの両方との間で、データを送受信するＵＥについて説明する。このＵＥが、Ｓ－ＭｅＮＢから、Ｔ－ＭｅＮＢにハンドオーバを行う際、ハンドオーバ直前に、ＥＰＳベアラ＃２は、Ｓ－ＭｅＮＢのＲＬＣ／ＭＡＣを経由せずに、ＳｅＮＢのＲＬＣ／ＭＡＣ／ＰＨＹのみを経由するように、全て移行される。あるいは、ＥＰＳベアラ＃２は、ＧＴＰｕ／ＰＤＣＰも含めて、Ｓ－ＧＷよりも下位は全てＳ－ＭｅＮＢを経由せずに、ＳｅＮＢのＲＬＣ／ＭＡＣ／ＰＨＹのみを経由するように、全て移行される。あるいは、ＥＰＳベアラ＃２は、ＳｅＮＢのＲＬＣ／ＭＡＣ／ＰＨＹのみを経由するように全て移行されることに代えて、ＳｅＮＢのＧＴＰｕ／ＰＤＣＰ／ＲＬＣ／ＭＡＣ／ＰＨＹの全てを経由するように、全て移行される。以下の説明では、このように、ベアラを、ＳｅＮＢを経由するように全て移行することを、「ＳｅＮＢへ全移行する」という場合がある。

　図２６のステップＳＴ２００１において、Ｓ－ＭｅＮＢ、Ｔ－ＭｅＮＢ、ＭＭＥおよびＳ－ＧＷは、エリア制限を付与する（Area Restriction Provided）。

　ステップＳＴ２００２からステップＳＴ２０１１のＨＯ決定までは、前述の実施の形態４と同様に行われる。具体的には、ステップＳＴ２００２において、Ｓ－ＭｅＮＢは、ＵＥにメジャメント制御（Measurement Control）メッセージを通知する。該メジャメント制御メッセージに、周辺のＳｅＮＢのメジャメントを設定してもよい。あるいは、ＳｅＮＢ用の周波数のメジャメントを設定してもよい。また、メジャメントの設定として、ＭｅＮＢとは別に、ＳｅＮＢ用またはＳｅＮＢ用の周波数におけるイベント、もしくはイベントのクライテリアを設定してもよい。

　ステップＳＴ２００２においてメジャメント制御メッセージを受信したＵＥは、周辺セル、すなわちＭｅＮＢおよびＳｅＮＢのメジャメントを行う。

　ステップＳＴ２００３において、ＵＥとＳ－ＭｅＮＢとの間で、パケットデータの通信が行われ、ステップＳＴ２００４において、Ｓ－ＭｅＮＢとＳ－ＧＷとの間で、パケットデータの通信が行われる。

　ＥＰＳベアラ＃２がベアラスプリットされる場合、ステップＳＴ２００５において、ＵＥとＳ－ＭｅＮＢとの間でパケットデータが直接通信され、ステップＳＴ２００６において、Ｓ－ＭｅＮＢとＳ－ＧＷとの間でパケットデータが直接通信される。

　また、ステップＳＴ２００７およびステップＳＴ２００８において、ＵＥとＳ－ＭｅＮＢとの間で、ＳｅＮＢを介して、パケットデータが通信される。具体的には、ステップＳＴ２００７において、ＵＥとＳｅＮＢとの間でパケットデータの通信が行われ、ステップＳＴ２００８において、ＳｅＮＢとＳ－ＭｅＮＢとの間でパケットデータの通信が行われる。

　ステップＳＴ２００９において、Ｓ－ＭｅＮＢは、ＵＥに、上りリンク割り当て（UL allocation）情報を通知する。ステップＳＴ２０１０において、ＵＥは、Ｓ－ＭｅＮＢにメジャメント報告（Measurement Report）メッセージを通知する。

　ステップＳＴ２０１０でメジャメント報告メッセージを受信したＳ－ＭｅＮＢは、ステップＳＴ２０１１において、メジャメント報告の結果を用いて、ＵＥをＴ－ＭｅＮＢにハンドオーバ（ＨＯ）させるか否かを決定する。図２６に示す例では、Ｓ－ＭｅＮＢは、ステップＳＴ２０１１において、ＵＥをＴ－ＭｅＮＢにＨＯさせることを決定する。

　Ｓ－ＭｅＮＢは、ステップＳＴ２０１１でＵＥをＴ－ＭｅＮＢにＨＯさせることを決定すると、ステップＳＴ２０１２に移行する。ステップＳＴ２０１２において、Ｓ－ＭｅＮＢは、ＥＰＳベアラ＃２をＳｅＮＢへ全移行するための修正（以下「ＥＰＳベアラ＃２のＳｅＮＢへの全移行のための修正」という場合がある）を行うか否かを決定する。図２６に示す例では、Ｓ－ＭｅＮＢは、ＥＰＳベアラ＃２のＳｅＮＢへの全移行のための修正を行うことを決定する。

　ステップＳＴ２０１３において、Ｓ－ＭｅＮＢは、ＳｅＮＢに対するＥＰＳベアラ＃２全移行可否確認処理を行う。ここで、ＳｅＮＢに対するＥＰＳベアラ＃２全移行可否確認処理とは、ＥＰＳベアラ＃２をＳｅＮＢへ全移行することが可能か否か、すなわちＥＰＳベアラ＃２のＳｅＮＢへの全移行の可否をＳｅＮＢに確認する処理をいう。具体的には、Ｓ－ＭｅＮＢは、ＳｅＮＢに対するＥＰＳベアラ＃２全移行可否確認処理として、ＳｅＮＢに対して、ＥＰＳベアラ＃２のＳｅＮＢへの全移行が可能か否かを確認する全移行可否確認信号を通知する。全移行可否確認信号を受信したＳｅＮＢは、Ｓ－ＭｅＮＢに対して、ＥＰＳベアラ＃２のＳｅＮＢへの全移行の可否を通知する。

　ステップＳＴ２０１４において、Ｓ－ＭｅＮＢは、ＳｅＮＢから通知された全移行の可否に基づいて、ＳｅＮＢへの全移行が可能であるか否かを判断する。ＳｅＮＢへの全移行が可能であると判断された場合は、ステップＳＴ２０１５に移行し、ＳｅＮＢへの全移行が可能でないと判断された場合は、ステップＳＴ２０１６に移行する。

　ステップＳＴ２０１５において、ＵＥ、ＳｅＮＢおよびＳ－ＭｅＮＢは、Ｓ－ＭｅＮＢに対するＥＰＳベアラ＃２全移行修正処理を行う。具体的には、ステップＳＴ２０１５において、ＥＰＳベアラ＃２をＳｅＮＢへ全移行する処理が行われる。

　ステップＳＴ２０１６において、Ｓ－ＭｅＮＢは、図１７のステップＳＴ１１０２と同様にして、ＳｅＮＢをリリースした後、ＨＯ処理を実行する。本発明の他の実施の形態では、ＳｅＮＢへの全移行が可能でないと判断されてステップＳＴ２０１６に移行した場合、ＳｅＮＢをリリースせずに、ＨＯ処理を実行してもよい。

　ステップＳＴ２０１７において、Ｓ－ＭｅＮＢとＳ－ＧＷとの間でパケットデータの通信が行われる。ステップＳＴ２０１８において、ＵＥとＳｅＮＢとの間でパケットデータの通信が行われる。ステップＳＴ２０１９において、ＳｅＮＢとＳ－ＭｅＮＢとの間でパケットデータの通信が行われる。

　ステップＳＴ２０２０において、Ｓ－ＭｅＮＢは、ハンドオーバ要求（Handover Request）メッセージを、ＨＯ先であるＴ－ＭｅＮＢに通知する。ＨＯ要求メッセージには、ＳｅＮＢ情報および、ＥＰＳベアラ＃２に関する情報（以下「ＥＰＳベアラ＃２情報」という場合がある）が含まれる。ＳｅＮＢ情報およびＥＰＳベアラ＃２情報は、ＨＯ要求メッセージとは別のメッセージを用いて通知されてもよい。

　ステップＳＴ２０２１において、Ｔ－ＭｅＮＢは、ＳｅＮＢの変更が必要か否かを判断する。ＳｅＮＢの変更が必要であると判断された場合は、ステップＳＴ２０２２に移行し、ＳｅＮＢの変更が必要でないと判断された場合は、ステップＳＴ２０２３に移行する。

　ステップＳＴ２０２２において、Ｔ－ＭｅＮＢは、図１７のステップＳＴ１１０２と同様にして、ＳｅＮＢをリリースした後、ハンドオーバ（ＨＯ）処理を実行する。

　ステップＳＴ２０２３において、Ｔ－ＭｅＮＢは、ベアラ構成の変更が必要か否かを判断する。ベアラ構成の変更が必要であると判断された場合は、図２８のステップＳＴ２０２５に移行し、ベアラ構成の変更が必要でないと判断された場合は、ステップＳＴ２０２４に移行する。

　ステップＳＴ２０２４において、ＳｅＮＢおよびＴ－ＭｅＮＢによって、ＳｅＮＢに対するＭｅＮＢ変更確認処理が行われる。ここで、ＭｅＮＢ変更確認処理とは、Ｓ－ＭｅＮＢからＴ－ＭｅＮＢへのＭｅＮＢの変更を行うか否かを確認する処理をいう。具体的には、ＭｅＮＢ変更確認処理として、Ｔ－ＭｅＮＢが、ＳｅＮＢに対して、Ｓ－ＭｅＮＢからＴ－ＭｅＮＢへのＭｅＮＢの変更を行うか否かを確認するＭｅＮＢ変更確認信号を通知する。ＭｅＮＢ変更確認信号を受信したＳｅＮＢは、Ｔ－ＭｅＮＢに対して、ＭｅＮＢの変更を行うか否かを通知する。ステップＳＴ２０２４の処理には、Ｓ－ＭｅＮＢは関与しない。

　図２８のステップＳＴ２０２５において、ＵＥ、ＳｅＮＢ、Ｓ－ＭｅＮＢ、Ｔ－ＭｅＮＢ、ＭＭＥおよびＳ－ＧＷによって、ＥＰＳベアラ＃１用ＭｅＮＢ　ＨＯ処理が行われる。ＳｅＮＢを介したＮＡＳシグナリングがある場合も、ステップＳＴ２０２５のＥＰＳベアラ＃１用ＭｅＮＢ　ＨＯ処理に従う。ＥＰＳベアラ＃１用ＭｅＮＢ　ＨＯ処理の詳細については後述する。

　ステップＳＴ２０２６において、ＳｅＮＢ、Ｓ－ＭｅＮＢおよびＴ－ＭｅＮＢによって、ＳｅＮＢに対するＭｅＮＢ変更処理が行われる。これは、ＭｅＮＢのハンドオーバ完了後、ＳｅＮＢの制御プレイン（C-plane）、たとえばシグナリングを行うマクロｅＮＢ（ＭｅＮＢ）が変更されたことを通知する処理である。この処理は、ＥＰＳベアラ＃２のＭｅＮＢをＴ－ＭｅＮＢに変更したことを通知し、Ｔ－ＭｅＮＢとＳｅＮＢとの間でデータ送受信を可能にするために必要な処理である。具体的には、ステップＳＴ２０２６において、Ｓ－ＭｅＮＢが、ＳｅＮＢに対して、ＭｅＮＢがＴ－ＭｅＮＢに変更されたことを表す信号を通知する。

　ステップＳＴ２０２７において、ＵＥとＳｅＮＢとの間でパケットデータの通信が行われる。ステップＳＴ２０２８において、ＳｅＮＢとＴ－ＭｅＮＢとの間でパケットデータの通信が行われてもよい。

　ステップＳＴ２０２９において、Ｔ－ＭｅＮＢは、ＥＰＳベアラ＃２のＳｅＮＢへの全移行のために、ＥＰＳベアラ＃２の修正を行うか否かを判断する。図２８に示す例では、Ｔ－ＭｅＮＢは、ＥＰＳベアラ＃２のＳｅＮＢへの全移行のために、ＥＰＳベアラ＃２の修正を行うことを決定する。

　これによって、ＥＰＳベアラ＃２は、ＭｅＮＢのハンドオーバ処理中に、ハンドオーバしないＳｅＮＢのみから送受信されるように変更されるので、ハンドオーバの影響を受けなくなる。したがって、ハンドオーバ処理を簡素化することができるので、ハンドオーバの失敗を軽減することができる。また、データの欠落を軽減することができる。

　ステップＳＴ２０３０において、ＵＥ、ＳｅＮＢおよびＴ－ＭｅＮＢは、ＳｅＮＢに対するＥＰＳベアラ＃２全移行可否確認処理、およびＥＰＳベアラ＃２のＳｅＮＢへの全移行のための修正処理を行う。ステップＳＴ２０３０の処理には、Ｓ－ＭｅＮＢは関与しない。

　ステップＳＴ２０３１において、ＵＥとＴ－ＭｅＮＢとの間でパケットデータの通信が行われる。ステップＳＴ２０３２において、Ｔ－ＭｅＮＢとＳ－ＧＷとの間でパケットデータの通信が行われる。

　ステップＳＴ２０３３において、ＵＥとＳｅＮＢとの間でパケットデータの通信が行われる。ステップＳＴ２０３４において、ＳｅＮＢとＴ－ＭｅＮＢとの間でパケットデータの通信が行われる。

　図２９および図３０は、図２８のステップＳＴ２０２５のＥＰＳベアラ＃１用ＭｅＮＢ　ＨＯ処理のシーケンスの一例を示す図である。

　ステップＳＴ２０４１において、Ｔ－ＭｅＮＢは、前述の図１２に示すステップＳＴ９３０と同様にして、収容キャパシティを確認するアドミッション制御を行う。Ｔ－ＭｅＮＢは、アドミッション制御の結果に基づいて、ＨＯを受付可能であると判断すると、ステップＳＴ２０４２において、ステップＳＴ９３１と同様にして、Ｓ－ＭｅＮＢに、ＨＯ要求受諾応答（Handover Request Ack）メッセージを通知する。

　ステップＳＴ２０４２のＨＯ要求受諾応答メッセージを受けて、ステップＳＴ２０４３において、ＳｅＮＢ、Ｓ－ＭｅＮＢおよびＴ－ＭｅＮＢは、ＳｅＮＢに対するＭｅＮＢ変更処理を行う。ここで、ＭｅＮＢ変更処理とは、Ｔ－ＭｅＮＢからＳ－ＭｅＮＢへ、さらにＳ－ＭｅＮＢからＳｅＮＢへのデータの流れ、または、Ｔ－ＭｅＮＢからＳ－ＭｅＮＢおよびＴ－ＭｅＮＢからＳｅＮＢへのデータの流れにおいて、ＳｅＮＢの制御プレイン（C-plane）、たとえばシグナリングを行うマクロｅＮＢ（ＭｅＮＢ）が変更されたことを通知する処理である。具体的には、ＳｅＮＢに対して、Ｓ－ＭｅＮＢが、Ｔ－ＭｅＮＢにＭｅＮＢが変更されたことを表す信号を通知する。ＭｅＮＢが変更されたことは、ステップＳＴ２０４２のＨＯ要求受諾応答（Handover Request Ack）メッセージを用いて通知されてもよい。

　ステップＳＴ２０４４において、ＵＥとＳ－ＭｅＮＢとの間でパケットデータの通信が行われる。ステップＳＴ２０４５において、Ｓ－ＭｅＮＢとＴ－ＭｅＮＢとの間でパケットデータの通信が行われる。

　ステップＳＴ２０４６において、Ｓ－ＭｅＮＢは、ＵＥに、下りリンク割り当て（DL allocation）情報を通知する。ステップＳＴ２０４７において、Ｓ－ＭｅＮＢは、ＵＥに、モビリティ制御情報を含むＲＲＣ接続再構成（RRC Connection Reconfiguration）メッセージを通知する。ステップＳＴ２０４７では、ＳｅＮＢおよびＥＰＳベアラ＃２に変更がないことを通知してもよい。

　ステップＳＴ２０４８からステップＳＴ２０５５までの処理は、３ＧＰＰ　ＴＳ３６．３００と同じである。具体的には、ステップＳＴ２０４８において、ＵＥは、旧セルであるＳ－ＭｅＮＢからデタッチするとともに、新セルであるＴ－ＭｅＮＢへの同期を開始する。

　ステップＳＴ２０４９において、Ｓ－ＭｅＮＢは、バッファに記憶中のパケット、および送信中のパケットを、ターゲットｅＮＢであるＴ－ＭｅＮＢに伝達する。

　ステップＳＴ２０５０において、Ｓ－ＭｅＮＢは、Ｔ－ＭｅＮＢに、図１１のステップＳＴ９１２と同様にして、ＰＤＣＰのシーケンス番号（ＳＮ）の状況を伝達するＳＮ状況伝達（SN Status Transfer）を行う。また、ステップＳＴ２０５１において、Ｓ－ＭｅＮＢは、Ｔ－ＭｅＮＢに、送信が完了していないデータを転送するデータ転送（Data Forwarding）を行ってもよい。

　ステップＳＴ２０５２において、Ｔ－ＭｅＮＢは、Ｓ－ＭｅＮＢから伝達されたパケットをバッファに記憶する。

　ステップＳＴ２０５３において、ＵＥは、Ｔ－ＭｅＮＢに同期（Synchronization）する。ステップＳＴ２０５４において、Ｔ－ＭｅＮＢは、ＵＥに、上りリンク割り当て（UL allocation）情報およびＵＥ用トラッキングエリア（ＴＡ）を通知する。ステップＳＴ２０５５において、ＵＥは、Ｔ－ＭｅＮＢに、ＲＲＣ接続再構成完了（RRC Connection Reconfiguration Complete）メッセージを通知する。

　図３０のステップＳＴ２０５６において、ＳｅＮＢ、Ｓ－ＭｅＮＢおよびＴ－ＭｅＮＢによって、図２８のステップＳＴ２０２６と同様にして、ＳｅＮＢに対するＭｅＮＢの変更処理が行われる。これは、ＳｅＮＢの制御プレイン（C-plane）、たとえばシグナリングを行うマクロｅＮＢ（ＭｅＮＢ）が変更したことを通知する処理である。

　ステップＳＴ２０５７において、ＵＥとＴ－ＭｅＮＢとの間でパケットデータの通信が行われてもよい。ステップＳＴ２０５８において、ＵＥとＳｅＮＢとの間でパケットデータの通信が行われる。ステップＳＴ２０５９において、ＳｅＮＢとＴ－ＭｅＮＢとの間でパケットデータの通信が行われてもよい。ステップＳＴ２０６０において、Ｔ－ＭｅＮＢは、Ｓ－ＧＷにパケットデータを伝達してもよい。

　ステップＳＴ２６７１において、Ｔ－ＭｅＮＢ、ＭＭＥおよびＳ－ＧＷは、ＥＰＳベアラ＃１およびＥＰＳベアラ＃２のパスをいずれも、Ｓ－ＭｅＮＢからＴ－ＭｅＮＢに変更することを要求するパススイッチ要求を行う。

　具体的には、ステップＳＴ２０６１において、Ｔ－ＭｅＮＢは、ＭＭＥに、パススイッチ要求（Path Switch Request）メッセージを通知する。パススイッチ要求メッセージを通知されたＭＭＥは、ステップＳＴ２０６２において、Ｓ－ＧＷに、ベアラ変更要求（Modify Bearer Request）メッセージを通知する。

　ベアラ変更要求メッセージを通知されたＳ－ＧＷは、ステップＳＴ２０６３において、下りパスを変更する。ステップＳＴ２０６４において、Ｓ－ＧＷは、Ｓ－ＭｅＮＢに送信するＰＤＣＰにエンドマーカを付与して転送処理の終了を伝えてもよい。Ｓ－ＭｅＮＢは、ステップＳＴ２０６６において、エンドマーカを付与してＴ－ＭｅＮＢに転送してもよい。ステップＳＴＳＴ２０６５において、Ｔ－ＭｅＮＢとＳ－ＧＷとの間で、パケットデータの通信が行われてもよい。

　ステップＳＴ２０６７において、Ｓ－ＧＷは、ＭＭＥに、ベアラ変更応答（Modify Bearer Response）メッセージを通知する。ベアラ変更応答メッセージを通知されたＭＭＥは、ステップＳＴ２０６８において、Ｔ－ＭｅＮＢに、パスの切替完了を表すパススイッチ要求受諾応答（Path Switch Request Ack）メッセージを通知する。このようにして、ステップＳＴ２６７１の処理が終了する。

　ステップＳＴ２０６９において、Ｔ－ＭｅＮＢは、Ｓ－ＭｅＮＢに、ＵＥコンテキスト解放（ＵＥ context release）メッセージを通知する。ＵＥコンテキスト解放メッセージを通知されたＳ－ＭｅＮＢは、ステップＳＴ２６７０において、ＵＥに割り当てていたリソースを解放（リリース）する。ステップＳＴ２６７０のリソースのリリース処理の後、前述の図２８のステップＳＴ２０２６のＳｅＮＢに対するＭｅＮＢの変更処理が行われる。

　前述のように、図２８のステップＳＴ２０２９の処理によって、ハンドオーバ時に、ＳｅＮＢのみが、ＵＥとの間で、ＥＰＳベアラ＃２を用いたデータの送受信を行うように設定される。このステップＳＴ２０２９の処理をどのようにして行うかについて、図３１を用いて説明する。

　図３１は、ＵＥとの間のデータの送受信の状況の一例を示す図である。Ｓ－ＧＷ６０１は、ＰＤＣＰ処理ｅＮＢ切替部６０２を備える。Ｓ－ＭｅＮＢ６０３は、第１ＰＤＣＰ処理部６０４、ＲＬＣ処理部６０５、ＭＡＣ処理部６０６、ＰＨＹ処理部６０７および第２ＰＤＣＰ処理部６０８を備える。ＳｅＮＢ６０９は、ＰＤＣＰ処理部６１０、ＰＤＣＰパス切替部６１１、ＲＬＣ処理部６１２、ＭＡＣ処理部６１３およびＰＨＹ処理部６１４を備える。

　ハンドオーバ切替前は、ＵＥ６１５は、Ｓ－ＭｅＮＢ６０３およびＳｅＮＢ６０９の両方と、ＥＰＳベアラ＃２を用いたデータの送受信を行っている。たとえば、下りリンクの場合、Ｓ－ＧＷ６０１から、データが、Ｓ－ＭｅＮＢ６０３の第１ＰＤＣＰ処理部６０４および第２ＰＤＣＰ処理部６０８に与えられる。第１および第２ＰＤＣＰ処理部（以下、まとめて「ＰＤＣＰ処理部」という場合がある）６０４，６０８は、ＬＴＥまたはＬＴＥ－ＡにおけるＰＤＣＰの処理を行う。

　第２ＰＤＣＰ処理部６０８に与えられたデータは、ＳｅＮＢ６０９のＰＤＣＰパス切替部６１１に与えられる。ＰＤＣＰパス切替部６１１は、ＰＤＣＰのパスの切替を行う。ＰＤＣＰパス切替部６１１は、ハンドオーバ中ではないので、第２ＰＤＣＰ処理部６０８からのＰＤＣＰをＲＬＣ処理部６１２に与えると判断し、第２ＰＤＣＰ処理部６０８からのデータをＲＬＣ処理部６１２に与える。ＲＬＣ処理部６１２は、ＬＴＥまたはＬＴＥ－ＡにおけるＲＬＣの処理を行う。

　ＲＬＣ処理部６１２に与えられたデータは、その後、ＭＡＣ処理部６１３、ＰＨＹ処理部６１４に順に与えられ、無線伝送によって、ＵＥ６１５に与えられる。ＭＡＣ処理部６１３は、ＬＴＥまたはＬＴＥ－ＡにおけるＭＡＣの処理を行う。ＰＨＹ処理部６１４は、ＬＴＥまたはＬＴＥ－ＡにおけるＰＨＹの処理を行う。

　本実施の形態のように、ＳｅＮＢ６０９におけるデータの送受信は変わらず、ＭｅＮＢのハンドオーバのみが行われる場合、ハンドオーバ中は、ＵＥ６１５と、Ｓ－ＭｅＮＢ６０３との間で、ＥＰＳベアラ＃２を用いたデータの送受信は行われない。

　ＰＤＣＰを含めてＳｅＮＢ６０９へ全移行する場合、Ｓ－ＧＷ６０１は、ＰＤＣＰ処理ｅＮＢ切替部６０２によって、ＰＤＣＰの処理を行うｅＮＢを切替える。ＰＤＣＰ処理ｅＮＢ切替部６０２は、Ｓ－ＭｅＮＢ６０３の第２ＰＤＣＰ処理部６０８ではなく、ＳｅＮＢ６０９のＰＤＣＰ処理部６１０に対して、ＥＰＳベアラ＃２を用いてデータを送信する。ＰＤＣＰ処理部６１０は、ＬＴＥまたはＬＴＥ－ＡにおけるＰＤＣＰの処理を行う。

　Ｓ－ＧＷ６０１からデータを受信したＳｅＮＢ６０９は、受信したデータに対して、ＰＤＣＰ処理部６１０によってＰＤＣＰの処理を行い、処理後のデータをＰＤＣＰパス切替部６１１に与える。ＳｅＮＢ６０９は、ＰＤＣＰパス切替部６１１によって、Ｓ－ＭｅＮＢ６０３の第２ＰＤＣＰ処理部６０８からのＰＤＣＰデータではなく、自装置のＰＤＣＰ処理部６１０からのＰＤＣＰデータを選択し、ＲＬＣ処理部６１２に与える。

　ＲＬＣ処理部６１２に与えられたＰＤＣＰデータは、その後、ＭＡＣ処理部６１３、ＰＨＹ処理部６１４の順に与えられて処理され、最後に、無線伝送によって、ＵＥ６１５に送信される。

　ＰＤＣＰ処理ｅＮＢ切替部６０２およびＰＤＣＰパス切替部６１１を設けることによって、ＭｅＮＢのハンドオーバ中は、データの導通を、ハンドオーバしないＳｅＮＢのみで行う処理を実現することができる。

　上りリンクの場合でも、下りリンクの場合と同様の処理の流れとなる。上りリンクの場合も、下りリンクの場合と同様に、ＰＤＣＰ処理ｅＮＢ切替部６０２およびＰＤＣＰパス切替部６１１を設けることによって、ＭｅＮＢのハンドオーバ中は、データの導通を、ハンドオーバしないＳｅＮＢのみで行う処理を実現することができる。

　また、前述の図２８のステップＳＴ２０２５のハンドオーバ処理の後に、ＳｅＮＢとＴ－ＭｅＮＢとの両方で、ＥＰＳベアラ＃２を用いたデータの送受信が行われる場合の処理は、以下のようにして実行される。ハンドオーバ時は、ＳｅＮＢにおいて、Ｓ－ＭｅＮＢからＴ－ＭｅＮＢに接続を変更する。その後、Ｔ－ＭｅＮＢが、ＳｅＮＢのみのデータの送受信経路を、ＳｅＮＢとＴ－ＭｅＮＢとのデータの送受信経路に変更する。あるいは、ハンドオーバ時は、一度に、ＳｅＮＢおよびＴ－ＭｅＮＢの両方のデータの送受信経路を用いて接続する、といった方法も考えられる。

　その際、無線リソースの構成（Configuration）の変更については、（Ａ）Ｔ－ＭｅＮＢからのスプリットベアラ構成の設定で行う場合と、（Ｂ）データの送受信経路の切替の変更で行う場合との二通りが考えられる。

　前記（Ａ）のＴ－ＭｅＮＢからのスプリットベアラ構成の設定で行う場合の具体例として、以下の（Ａ－１）～（Ａ－４）の４つを開示する。

　（Ａ－１）Ｓ－ＭｅＮＢからＴ－ＭｅＮＢに通知が必要な情報は、ＳｅＮＢの識別情報、具体的にはＳｅＮＢの行先番地（アドレス）に関する情報である。ＰＤＣＰ処理されたデータをＳｅＮＢに送信することになるが、その際にＳｅＮＢの識別情報が必要となるためである。ＳｅＮＢの識別情報がないと、Ｔ－ＭｅＮＢは、どのＳｅＮＢにデータを送信したらよいのか、どのＳｅＮＢからデータを受信したらよいのかが分からない。また、Ｔ－ＭｅＮＢは、ＳｅＮＢが、どのＲＲＣコネクションパラメータで動作しているかのパラメータ情報を知る必要があるので、その情報も通知される。

　（Ａ－２）Ｔ－ＭｅＮＢからＳ－ＭｅＮＢに通知が必要な情報は、ＭｅＮＢのハンドオーバに成功したか失敗したかの情報である。また、Ｓ－ＭｅＮＢのバッファにデータが滞留している場合は、データ転送（Data Forwarding）を行う指示を表す情報も、Ｔ－ＭｅＮＢからＳ－ＭｅＮＢに通知が必要な情報である。

　（Ａ－３）ＵＥに通知が必要な情報は、Ｓ－ＭｅＮＢからＴ－ＭｅＮＢへ、ハンドオーバによってＭｅＮＢが切り替わったことを表す通知である。この場合、ＵＥは、Ｓ－ＭｅＮＢではなく、Ｔ－ＭｅＮＢとの間でデータの送受信を行うことになる。

　（Ａ－４）ＳｅＮＢは、スプリットベアラ構成の場合は、Ｓ－ＭｅＮＢおよびＴ－ＭｅＮＢのどちらかのＰＤＣＰ処理部を経由してＳ－ＧＷとデータの送受信を行うことになる。したがって、ＳｅＮＢに通知が必要な情報は、ＳｅＮＢが、Ｓ－ＭｅＮＢおよびＴ－ＭｅＮＢのどちらのＭｅＮＢのＰＤＣＰ処理部を経由するかの情報である。

　前記（Ｂ）のデータの送受信経路の切替の変更で対応する場合の具体例として、以下の（Ｂ－１）～（Ｂ－４）の４つを開示する。

　（Ｂ－１）Ｓ－ＭｅＮＢからＴ－ＭｅＮＢに通知が必要な情報は、ＳｅＮＢの識別情報である。Ｓ－ＭｅＮＢが、ハンドオーバ前は、どのＳｅＮＢと同時通信していたのかを知らないと、ハンドオーバ後に、どのＳｅＮＢと同時通信してよいのかが分からないためである。また、Ｔ－ＭｅＮＢは、ＳｅＮＢが、どのＲＲＣコネクションパラメータで動作しているかのパラメータ情報を知る必要があるので、その情報も通知される。本具体例（Ｂ－１）では、ＳｅＮＢは、データの送受信のみで、制御情報（シグナリング）は、Ｔ－ＭｅＮＢが受け持つようになる場合を想定している。

　（Ｂ－２）Ｔ－ＭｅＮＢからＳ－ＭｅＮＢに通知が必要な情報は、前記具体例（Ａ－２）と同様、ＭｅＮＢのハンドオーバに成功したか失敗したかの情報、およびＳ－ＭｅＮＢのバッファにデータが滞留している場合の、データ転送（Data Forwarding）を行うように指示する通知である。

　（Ｂ－３）ＵＥに通知が必要な情報は、前記具体例（Ａ－３）と同様、Ｓ－ＭｅＮＢからＴ－ＭｅＮＢへ、ハンドオーバによってＭｅＮＢが切り替わったことを表す通知である。この場合、ＵＥは、Ｓ－ＭｅＮＢではなく、Ｔ－ＭｅＮＢとの間でデータの送受信を行うことになる。

　（Ｂ－４）ＳｅＮＢに通知が必要な情報は、ハンドオーバの完了（成功）によって、Ｓ－ＭｅＮＢからＴ－ＭｅＮＢにＭｅＮＢが切り替わったことを表す情報である。ＳｅＮＢは、ＭｅＮＢに従属した存在であるので、従属先であるＭｅＮＢのうち、どのＭｅＮＢが、自装置に対する制御信号たとえばシグナリングを送受信しているのかを知り、そのＭｅＮＢからの制御に従う必要があるためである。

　前述の図２６～図３０に示すシーケンスにおいて、無線リソースの構成（Configuration）の変更は、（１）ステップＳＴ２０２６、（２）ステップＳＴ２０５６、および（３）ステップＳＴ２０４３の３つのタイミングで行われる。前記（１）～（３）の各タイミングについて、以下に具体的に説明する。

　（１）ステップＳＴ２０２６におけるＳｅＮＢに対するＭｅＮＢ変更処理のタイミングでは、ステップＳＴ２０６３の下りパス変更のタイミングの後に、無線リソースの構成（Configuration）の変更が行われることになる。したがって、ＭｅＮＢがＴ－ＭｅＮＢに切り替わり、しかも、Ｓ－ＭｅＮＢのリソースが解放された後であるので、誤って、ハンドオーバ前のリソースで処理されてしまうことを防ぐことができる。また、簡潔な処理で実現することができ、また規模が比較的小さい回路で処理を実現することができる。

　（２）ステップＳＴ２０５６におけるＳｅＮＢに対するＭｅＮＢ変更処理のタイミングでは、ステップＳＴ２０６３の下りパス変更のタイミングの前に、無線リソースの構成（Configuration）の変更が行われることになる。したがって、ハンドオーバによって上位装置がＳ－ＭｅＮＢからＴ－ＭｅＮＢに切り替わる前に、ＵＥとの間の無線通信が、ハンドオーバ後に行われるべき動作となっているという矛盾が発生する。

　これによって、前記（１）のタイミングで行われる場合よりも処理が複雑になるが、切り替わりタイミングが早いので、その分、ＳｅＮＢのみでデータの送受信が行われることによるリスク、たとえばＳｅＮＢに複数のＵＥからアクセスが集中して輻輳状態となることを回避し、安定した動作を実現することができる。

　（３）ステップＳＴ２０４３におけるＳｅＮＢに対するＭｅＮＢ変更処理のタイミングは、ステップＳＴ２０４２でＴ－ＭｅＮＢが、ハンドオーバ要求に対するＡｃｋ応答を通知した直後である。本タイミングでは、前記（２）のタイミングよりも、さらに早いタイミングで、無線リソースの構成（Configuration）の変更が行われる。

　これによって、前記（２）のタイミングで行われる場合よりも、ハンドオーバに失敗した場合の処理などがさらに複雑になるが、前述のリスクを、より確実に回避することができるので、より安定した動作を実現することができる。

　前記（２）および（３）のタイミングにおいて、無線リソースの構成（Configuration）によってデータの送受信ができるのは、上りデータの送受信のみである。下りデータの送受信については、Ｔ－ＭｅＮＢがＳ－ＧＷからデータを受信した後になる。

　実施の形態６．
　図３２および図３３は、本発明の実施の形態６の通信システムにおけるＥＰＳベアラ＃１用ＭｅＮＢ　ＨＯ処理のシーケンスの一例を示す図である。図３２と図３３とは、境界線ＢＬ１０で接続されている。

　前述の実施の形態５では、Ｓ－ＭｅＮＢが再構成（reconfiguration）を行うが、本実施の形態では、Ｔ－ＭｅＮＢが再構成（reconfiguration）を行う。具体的には、本実施の形態では、前述の図２６～図３０に示す実施の形態５のシーケンスにおいて、図２９および図３０に示すステップＳＴ２０２５に代えて、図３２および図３３に示すステップＳＴ２６８０のＥＰＳベアラ＃１用ＭｅＮＢ　ＨＯ処理を行うこと以外は、実施の形態５と同様の処理を行う。

　図３２および図３３に示すステップＳＴ２６８０の処理は、図２９および図３０に示すステップＳＴ２０２５のＥＰＳベアラ＃１用ＭｅＮＢ　ＨＯ処理と類似するので、同一のステップについては、同一のステップ番号を付して、共通する説明を省略する。

　ステップＳＴ２６８０の処理は、図２９および図３０に示す実施の形態５のステップＳＴ２０２５において、図２９のステップＳＴ２０４６およびステップＳＴ２０４７に代えて、ステップＳＴ２６８１およびステップＳＴ２６８２の処理を行うこと以外は、実施の形態５のステップＳＴ２０２５の処理と同様である。

　本実施の形態では、ステップＳＴ２６８１において、Ｔ－ＭｅＮＢが、ＵＥに、下りリンク割り当て（DL allocation）情報を通知する。またステップＳＴ２６８２において、Ｔ－ＭｅＮＢが、ＵＥに、ＲＲＣ接続再構成（RRC Connection Reconfiguration）メッセージを通知する。本実施の形態では、ＲＲＣ接続再構成メッセージは、モビリティ制御情報を含まない。

　このように、前述の実施の形態５では、Ｓ－ＭｅＮＢがＵＥにＲＲＣ接続再構成（RRC Connection Reconfiguration）メッセージを通知するが、本実施の形態では、Ｔ－ＭｅＮＢがＵＥにＲＲＣ接続再構成（RRC Connection Reconfiguration）メッセージを通知する。

　これによって、ハンドオーバ元であるＳ－ＭｅＮＢではなく、これから通信接続を行うハンドオーバ先であるＴ－ＭｅＮＢによって、最適なＲＲＣ接続設定が行われることになるので、ＵＥとＭｅＮＢとの通信を安定させることができる。

　実施の形態７．
　図３４および図３５は、本発明の実施の形態７の通信システムにおけるＥＰＳベアラ＃１用ＭｅＮＢ　ＨＯ処理のシーケンスの一例を示す図である。図３４と図３５とは、境界線ＢＬ１１で接続されている。

　本実施の形態では、前述の図２６～図３０に示す実施の形態５のシーケンスにおいて、図２９および図３０に示すステップＳＴ２０２５に代えて、図３４および図３５に示すステップＳＴ２６９０のＥＰＳベアラ＃１用ＭｅＮＢ　ＨＯ処理を行うこと以外は、実施の形態５と同様の処理を行う。

　図３４および図３５に示すステップＳＴ２６９０の処理は、図２９および図３０に示すステップＳＴ２０２５のＥＰＳベアラ＃１用ＭｅＮＢ　ＨＯ処理と類似するので、同一のステップについては、同一のステップ番号を付して、共通する説明を省略する。

　ステップＳＴ２６９０の処理は、図２９および図３０に示す実施の形態５のステップＳＴ２０２５に加えて、ステップＳＴ２６９１の処理を行うこと以外は、実施の形態５のステップＳＴ２０２５の処理と同様である。

　本実施の形態では、ステップＳＴ２６４６およびステップＳＴ２６４７の前に、ステップＳＴ２６９１において、Ｔ－ＭｅＮＢが、Ｓ－ＭｅＮＢに、ＲＲＣ接続再構成（RRC Connection Reconfiguration）メッセージおよび下りリンク割り当て（DL allocation）情報を通知する。

　このように本実施の形態では、Ｔ－ＭｅＮＢからＳ－ＭｅＮＢに対して通知してから、その内容をＳ－ＭｅＮＢからＵＥに通知する。これによって、前述の実施の形態６と同様に、Ｓ－ＭｅＮＢからＵＥに再構成メッセージを通知するのではなく、Ｔ－ＭｅＮＢから通知された再構成メッセージの内容をＳ－ＭｅＮＢ経由でＵＥに通知することになる。

　したがって、実施の形態６と同様に、ハンドオーバ元であるＳ－ＭｅＮＢではなく、これから通信接続を行うハンドオーバ先であるＴ－ＭｅＮＢによって、最適なＲＲＣ接続設定が行われることになるので、ＵＥとＭｅＮＢとの通信を安定させることができる。

　前述の各実施の形態およびその変形例は、ＳｅＮＢが複数のサービングセルを構成する場合にも適用することができる。また、同様に、ＭｅＮＢが複数のサービングセルを構成する場合にも適用することができる。ＳｅＮＢが構成するサービングセルの集合をＳＣＧ（secondary cell group）と称し、ＭｅＮＢが構成するサービングセルの集合をＭＣＧ（master cell group）と称することがある。

　前述の各実施の形態およびその変形例は、本発明の例示に過ぎず、本発明の範囲内において、各実施の形態およびその変形例を自由に組合せることができる。また、各実施の形態およびその変形例の任意の構成要素を適宜、変更または省略することができる。

　本発明は詳細に説明されたが、上記した説明は、すべての局面において、例示であって、本発明がそれに限定されるものではない。例示されていない無数の変形例が、本発明の範囲から外れることなく想定され得るものと解される。

　５１　Ｓ－ＭｅＮＢ、５２　Ｓ－ＭｅＮＢのカバレッジ、５３　Ｔ－ＭｅＮＢ、５４　Ｔ－ＭｅＮＢのカバレッジ、５５，５８　ＳｅＮＢ、５６，５９　ＳｅＮＢのカバレッジ、５７　ＵＥ。

Claims

　移動端末装置と、前記移動端末装置と無線通信可能なセルを構成する基地局装置とを備える通信システムであって、
　前記セルとして、前記移動端末装置と通信可能な範囲であるカバレッジが比較的大きい複数のマクロセルと、前記カバレッジが比較的小さいスモールセルとを備え、
　前記移動端末装置は、
　前記複数のマクロセルのうちの１つと前記スモールセルとに接続されるとき、
　前記移動端末装置の移動に伴って、前記移動端末装置が接続されるマクロセルを移動元のマクロセルから移動先のマクロセルに切替えるハンドオーバ処理の前に、前記スモールセルとの接続を解消するハンドオーバ前処理を行い、
　前記ハンドオーバ処理の後に、前記スモールセルとの接続を再度確立するハンドオーバ後処理を行うことを特徴とする通信システム。
　移動端末装置と、前記移動端末装置と無線通信可能なセルを構成する基地局装置とを備える通信システムであって、
　前記セルとして、前記移動端末装置と通信可能な範囲であるカバレッジが比較的大きい複数のマクロセルと、前記カバレッジが比較的小さいスモールセルとを備え、
　前記移動端末装置が前記複数のマクロセルのうちの１つと前記スモールセルとに接続されるとき、
　前記移動端末装置の移動に伴って、前記移動端末装置が接続されるマクロセルを移動元のマクロセルから移動先のマクロセルに切替えるハンドオーバ処理が起動されると、前記スモールセルに、前記スモールセルを制御する前記マクロセルが変更されることが通知されることを特徴とする通信システム。
　前記マクロセルと前記移動端末装置との間、および前記スモールセルと前記移動端末装置との間では、ベアラスプリットされたベアラを用いて通信が行われることを特徴とする請求項１または２に記載の通信システム。