(57)【要約】【課題】デュアルコネクティビティ中の移動端末装置がハンドオーバを行うことができる技術を提供する。【解決手段】通信システムは、通信端末（ＵＥ）と、通信端末と無線通信を行うための複数のセルを構成する少なくとも１つの基地局（Ｓ−ＭｅＮＢ、Ｔ−ＭｅＮＢ、ＳｅＮＢ）とを備える。複数のセルは、第１セル（ＳｅＮＢによるセル）と、第１セルと共に通信端末に第１デュアルコネクティビティを提供する第２セル（Ｓ−ＭｅＮＢによるセル）と、第１セルと共に通信端末に第２デュアルコネクティビティを提供する第３セル（Ｔ−ＭｅＮＢによるセル）とを含む。通信端末は、第１デュアルコネクティビティから第２デュアルコネクティビティへ移行するために第２セル（Ｓ−ＭｅＮＢによるセル）から第３セルへ（Ｔ−ＭｅＮＢによるセル）のハンドオーバを行う間、第１セル（ＳｅＮＢによるセル）との接続を維持する。【選択図】図１７
2020162180.tif 000002
【特許請求の範囲】
【請求項１】
通信端末と、
前記通信端末と無線通信を行うための複数のセルを構成する少なくとも１つの基地局と
を備える通信システムであって、
前記複数のセルは、
第１セルと、
前記第１セルと共に前記通信端末に第１デュアルコネクティビティを提供する第２セルと、
前記第１セルと共に前記通信端末に第２デュアルコネクティビティを提供する第３セルと
を含み、
前記通信端末は、前記第１デュアルコネクティビティから前記第２デュアルコネクティビティへ移行するために前記第２セルから前記第３セルへのハンドオーバを行う間、前記第１セルとの接続を維持することを特徴とする通信システム。
【請求項２】
前記通信端末が前記第２セルから前記第３セルへの前記ハンドオーバを行う間、前記第１セルを用いて構成されているベアラの構成を変更しないことを特徴とする請求項１に記載の通信システム。
【請求項３】
通信端末と、前記通信端末と無線通信を行うための複数のセルを構成する少なくとも１つの基地局とを備える通信システムで用いられる通信端末であって、
前記複数のセルは、
第１セルと、
前記第１セルと共に前記通信端末に第１デュアルコネクティビティを提供する第２セルと、
前記第１セルと共に前記通信端末に第２デュアルコネクティビティを提供する第３セルと
を含み、
前記通信端末は、前記第１デュアルコネクティビティから前記第２デュアルコネクティビティへ移行するために前記第２セルから前記第３セルへのハンドオーバを行う間、前記第１セルとの接続を維持することを特徴とする通信端末。
【請求項４】
通信端末と、前記通信端末と無線通信を行うための複数のセルを構成する少なくとも１つの基地局とを備える通信システムで用いられる基地局であって、
前記複数のセルは、
第１セルと、
前記第１セルと共に前記通信端末に第１デュアルコネクティビティを提供する第２セルと、
前記第１セルと共に前記通信端末に第２デュアルコネクティビティを提供する第３セルと
を含み、
前記第１セルおよび前記第２セルは前記基地局または他の基地局によって構成され、前記第３セルは前記基地局によって構成され、
前記基地局は、
前記通信端末が前記第１デュアルコネクティビティから前記第２デュアルコネクティビティへ移行するために前記第２セルから前記第３セルへのハンドオーバを行う場合に、前記第１セルを用いて構成されているベアラの構成を前記第２セルから引き継ぎ可能かを判断し、
前記ベアラの前記構成を前記第２セルから引き継ぎ可能と判断した場合、前記ハンドオーバの間、前記通信端末と前記第１セルとの間の接続を維持することを決定することを特徴とする基地局。
【発明の詳細な説明】
【技術分野】
【０００１】
本開示は、無線通信技術に関する。
【背景技術】
【０００２】
移動体通信システムの規格化団体である３ＧＰＰ（3rd Generation Partnership Project）において、無線区間についてはロングタームエボリューション（Long Term Evolution：ＬＴＥ）と称し、コアネットワークおよび無線アクセスネットワーク（以下、まとめて、ネットワークとも称する）を含めたシステム全体構成については、システムアーキテクチャエボリューション（System Architecture Evolution：ＳＡＥ）と称される新たな通信方式が検討されている（例えば、非特許文献１〜１０参照）。この通信方式は３．９Ｇ（3.9 Generation）システムとも呼ばれる。
【０００３】
ＬＴＥのアクセス方式としては、下り方向はＯＦＤＭ（Orthogonal Frequency Division Multiplexing）、上り方向はＳＣ−ＦＤＭＡ（Single Carrier Frequency Division Multiple Access）が用いられる。また、ＬＴＥは、Ｗ−ＣＤＭＡ（Wideband Code division Multiple Access）とは異なり、回線交換を含まず、パケット通信方式のみになる。
【０００４】
非特許文献１（５章）に記載される、３ＧＰＰでの、ＬＴＥシステムにおけるフレーム構成に関する決定事項について、図１を用いて説明する。図１は、ＬＴＥ方式の通信システムで使用される無線フレームの構成を示す説明図である。図１において、１つの無線フレーム（Radio frame）は１０ｍｓである。無線フレームは１０個の等しい大きさのサブフレーム（Subframe）に分割される。サブフレームは、２個の等しい大きさのスロット（slot）に分割される。無線フレーム毎に１番目および６番目のサブフレームに下り同期信号（Downlink Synchronization Signal：ＳＳ）が含まれる。同期信号には、第一同期信号（Primary Synchronization Signal：Ｐ−ＳＳ）と、第二同期信号（Secondary Synchronization Signal：Ｓ−ＳＳ）とがある。
【０００５】
３ＧＰＰでの、ＬＴＥシステムにおけるチャネル構成に関する決定事項が、非特許文献１（５章）に記載されている。ＣＳＧ（Closed Subscriber Group）セルにおいてもｎｏｎ−ＣＳＧセルと同じチャネル構成が用いられると想定されている。
【０００６】
物理報知チャネル（Physical Broadcast channel：ＰＢＣＨ）は、基地局から移動端末への下り送信用のチャネルである。ＢＣＨトランスポートブロック（transport block）は、４０ｍｓ間隔中の４個のサブフレームにマッピングされる。４０ｍｓタイミングの明白なシグナリングはない。
【０００７】
物理制御フォーマットインジケータチャネル（Physical Control Format Indicator Channel：ＰＣＦＩＣＨ）は、基地局から移動端末への下り送信用のチャネルである。ＰＣＦＩＣＨは、ＰＤＣＣＨｓのために用いるＯＦＤＭ（Orthogonal Frequency Division Multiplexing）シンボルの数を、基地局から移動端末へ通知する。ＰＣＦＩＣＨは、サブフレーム毎に送信される。
【０００８】
物理下り制御チャネル（Physical Downlink Control Channel：ＰＤＣＣＨ）は、基地局から移動端末への下り送信用のチャネルである。ＰＤＣＣＨは、後述のトランスポートチャネルの１つである下り共有チャネル（Downlink Shared Channel：ＤＬ−ＳＣＨ）のリソース割り当て（allocation）情報、後述のトランスポートチャネルの１つであるページングチャネル（Paging Channel：ＰＣＨ）のリソース割り当て（allocation）情報、ＤＬ−ＳＣＨに関するＨＡＲＱ（Hybrid Automatic Repeat reQuest）情報を通知する。ＰＤＣＣＨは、上りスケジューリンググラント（Uplink Scheduling Grant）を運ぶ。ＰＤＣＣＨは、上り送信に対する応答信号であるＡｃｋ（Acknowledgement）／Ｎａｃｋ（Negative Acknowledgement）を運ぶ。ＰＤＣＣＨは、Ｌ１／Ｌ２制御信号とも呼ばれる。
【０００９】
物理下り共有チャネル（Physical Downlink Shared Channel：ＰＤＳＣＨ）は、基地局から移動端末への下り送信用のチャネルである。ＰＤＳＣＨには、トランスポートチャネルである下り共有チャネル（ＤＬ−ＳＣＨ）、およびトランスポートチャネルであるＰＣＨがマッピングされている。
【００１０】
物理マルチキャストチャネル（Physical Multicast Channel：ＰＭＣＨ）は、基地局から移動端末への下り送信用のチャネルである。ＰＭＣＨには、トランスポートチャネルであるマルチキャストチャネル（Multicast Channel：ＭＣＨ）がマッピングされている。
【００１１】
物理上り制御チャネル（Physical Uplink Control Channel：ＰＵＣＣＨ）は、移動端末から基地局への上り送信用のチャネルである。ＰＵＣＣＨは、下り送信に対する応答信号（response signal）であるＡｃｋ／Ｎａｃｋを運ぶ。ＰＵＣＣＨは、ＣＱＩ（Channel Quality Indicator）レポートを運ぶ。ＣＱＩとは、受信したデータの品質、もしくは通信路品質を示す品質情報である。またＰＵＣＣＨは、スケジューリングリクエスト（Scheduling Request：ＳＲ）を運ぶ。
【００１２】
物理上り共有チャネル（Physical Uplink Shared Channel：ＰＵＳＣＨ）は、移動端末から基地局への上り送信用のチャネルである。ＰＵＳＣＨには、トランスポートチャネルの１つである上り共有チャネル（Uplink Shared Channel：ＵＬ−ＳＣＨ）がマッピングされている。
【００１３】
物理ＨＡＲＱインジケータチャネル（Physical Hybrid ARQ Indicator Channel：ＰＨＩＣＨ）は、基地局から移動端末への下り送信用のチャネルである。ＰＨＩＣＨは、上り送信に対する応答信号であるＡｃｋ／Ｎａｃｋを運ぶ。物理ランダムアクセスチャネル（Physical Random Access Channel：ＰＲＡＣＨ）は、移動端末から基地局への上り送信用のチャネルである。ＰＲＡＣＨは、ランダムアクセスプリアンブル（random access preamble）を運ぶ。
【００１４】
下り参照信号（リファレンスシグナル（Reference Signal）：ＲＳ）は、ＬＴＥ方式の通信システムとして既知のシンボルである。以下の５種類の下りリファレンスシグナルが定義されている。セル固有参照信号（Cell-specific Reference Signals：ＣＲＳｓ）、ＭＢＳＦＮ参照信号（MBSFN reference signals）、ＵＥ固有参照信号（UE-specific reference signals）であるデータ復調用参照信号（Demodulation Reference 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）などがある。
【０３０３】
ＲＲＣに関する情報は、ＭｅＮＢのためのＲＲＣに関する情報およびＳｅＮＢのためのＲＲＣに関する情報がある。各ＲＲＣに関する情報を識別可能とするとよい。例えば、ＭｅＮＢのためのＲＲＣコンテキストとＳｅＮＢのためのＲＲＣコンテキストとを別々に作成する。あるいは、１つのＲＲＣコンテキストの中に、ＭｅＮＢのための情報とＳｅＮＢのための情報とを別々に作成してもよい。
【０３０４】
このようにすることによって、ＳｅＮＢのためのＲＲＣに関する情報とＭｅＮＢのためのＲＲＣに関する情報とを個別に設定可能にし、Ｓ−ＭｅＮＢはＴ−ＭｅＮＢに対してＭｅＮＢとＳｅＮＢ、各々のＲＲＣに関する情報を通知することが可能となる。Ｔ−ＭｅＮＢは、Ｓ−ＭｅＮＢとＳｅＮＢ、各々のＲＲＣに関する情報を取得することが可能となり、Ｔ−ＭｅＮＢは、ＳｅＮＢのＲＲＣに関する設定の変更が必要か否か判断可能となる。
【０３０５】
Ｔ-ＭｅＮＢは、Ｓ−ＭｅＮＢからＨＯ要求メッセージで受信した情報を用いて、ステップＳＴ１１０１において、ＳｅＮＢを変更するか否か判断する。このステップＳＴ１１０１の処理は、図１７のステップＳＴ１１０１の処理と同様であるので、説明を省略する。
【０３０６】
ＳｅＮＢの変更を行うと判断した場合は、ステップＳＴ１１０２に移行する。ステップＳＴ１１０２の処理は、実施の形態２で開示した方法を適用すればよく、ここでは説明を省略する。
【０３０７】
ＳｅＮＢの変更をしないと判断した場合は、Ｔ-ＭｅＮＢは、ステップＳＴ１１０３において、ＳｅＮＢの使用を維持したままＨＯ処理を行うことを決定する。換言すれば、Ｔ-ＭｅＮＢは、ＭｅＮＢのみの変更を行うことを決定する。ＳｅＮＢの変更をしないと判断した場合は、ＳｅＮＢ使用のスプリットベアラ構成を維持する。ＳｅＮＢへのスプリットベアラ構成の変更処理は行わない。
【０３０８】
ステップＳＴ１２０２において、Ｔ−ＭｅＮＢは、ＨＯ要求に対するアドミッション制御を行う。このアドミッション制御は、前述のＳｅＮＢを変更するか否かの判断の前に行われてもよい。あるいは、その判断と併せて行われてもよい。
【０３０９】
ＳｅＮＢの変更を行わないので、ＭｅＮＢの変更によるアドミッション制御を行う。アドミッション制御において、Ｔ−ＭｅＮＢは、Ｔ−ＭｅＮＢのためのＲＲＣに関する設定を行う。ＲＲＣに関する設定として、無線リソースの構成を示すＡＳ構成（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）メッセージを通知する。該メジャメント制御メッセージに、周辺のＳｅＮＢのメジャメントを設定してもよい。あるいは、ＳｅＮＢ用の周波数のメジャメントを設定してもよい。また、メジャメントの設定として、ＭｅＮＢとは別に、ＳｅＮＢ用またはＳｅＮＢ用の周波数におけるイベント、もしくはイベントのクライテリアを設定してもよい。
【０４３８】
設定パラメータとしては、ＳｅＮＢの識別子、周波数、報告のためのイベント番号、受信品質の閾値、測定期間などがある。受信品質としては、ＲＳＲＰ（Reference Signal Received Power）、ＲＳＲＱ（Reference Signal Received Quality）などがある。
【０４３９】
ステップＳＴ２００２においてメジャメント制御メッセージを受信したＵＥは、周辺セル、すなわちＭｅＮＢおよびＳｅＮＢのメジャメントを行う。
【０４４０】
ステップＳＴ２００３において、ＵＥとＳ−ＭｅＮＢとの間で、パケットデータの通信が行われ、ステップＳＴ２００４において、Ｓ−ＭｅＮＢとＳ−ＧＷとの間で、パケットデータの通信が行われる。
【０４４１】
ＥＰＳベアラ＃２がベアラスプリットされる場合、ステップＳＴ２００５において、ＵＥとＳ−ＭｅＮＢとの間でパケットデータが直接通信され、ステップＳＴ２００６において、Ｓ−ＭｅＮＢとＳ−ＧＷとの間でパケットデータが直接通信される。
【０４４２】
また、ステップＳＴ２００７およびステップＳＴ２００８において、ＵＥとＳ−ＭｅＮＢとの間で、ＳｅＮＢを介して、パケットデータが通信される。具体的には、ステップＳＴ２００７において、ＵＥとＳｅＮＢとの間でパケットデータの通信が行われ、ステップＳＴ２００８において、ＳｅＮＢとＳ−ＭｅＮＢとの間でパケットデータの通信が行われる。
【０４４３】
ステップＳＴ２００９において、Ｓ−ＭｅＮＢは、ＵＥに、上りリンク割り当て（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）と称することがある。
【０５２６】
前述の各実施の形態およびその変形例は、例示に過ぎず、各実施の形態およびその変形例を自由に組合せることができる。また、各実施の形態およびその変形例の任意の構成要素を適宜、変更または省略することができる。
【０５２７】
本開示は詳細に説明されたが、上記した説明は、すべての局面において、例示であって、限定的なものではない。例示されていない無数の変形例が、想定され得るものと解される。
【符号の説明】
【０５２８】
５１  Ｓ−ＭｅＮＢ、５２  Ｓ−ＭｅＮＢのカバレッジ、５３  Ｔ−ＭｅＮＢ、５４  Ｔ−ＭｅＮＢのカバレッジ、５５，５８  ＳｅＮＢ、５６，５９  ＳｅＮＢのカバレッジ、５７  ＵＥ。
【図１】
2020162180.tif 000003
【図２】
2020162180.tif 000004
【図３】
2020162180.tif 000005
【図４】
2020162180.tif 000006
【図５】
2020162180.tif 000007
【図６】
2020162180.tif 000008
【図７】
2020162180.tif 000009
【図８】
2020162180.tif 000010
【図９】
2020162180.tif 000011
【図１０】
2020162180.tif 000012
【図１１】
2020162180.tif 000013
【図１２】
2020162180.tif 000014
【図１３】
2020162180.tif 000015
【図１４】
2020162180.tif 000016
【図１５】
2020162180.tif 000017
【図１６】
2020162180.tif 000018
【図１７】
2020162180.tif 000019
【図１８】
2020162180.tif 000020
【図１９】
2020162180.tif 000021
【図２０】
2020162180.tif 000022
【図２１】
2020162180.tif 000023
【図２２】
2020162180.tif 000024
【図２３】
2020162180.tif 000025
【図２４】
2020162180.tif 000026
【図２５】
2020162180.tif 000027
【図２６】
2020162180.tif 000028
【図２７】
2020162180.tif 000029
【図２８】
2020162180.tif 000030
【図２９】
2020162180.tif 000031
【図３０】
2020162180.tif 000032
【図３１】
2020162180.tif 000033
【図３２】
2020162180.tif 000034
【図３３】
2020162180.tif 000035
【図３４】
2020162180.tif 000036
【図３５】
2020162180.tif 000037