特表-16163544IP Force 特許公報掲載プロジェクト 2022.1.31 β版

知財求人 - 知財ポータルサイト「IP Force」

▶ 京セラ株式会社の特許一覧

再表2016-163544ハンドオーバ手順を制御するための方法及び基地局
(19)【発行国】日本国特許庁(JP)
【公報種別】再公表特許(A1)
(11)【国際公開番号】WO/0
(43)【国際公開日】2016年10月13日
【発行日】2017年12月28日
(54)【発明の名称】ハンドオーバ手順を制御するための方法及び基地局
(51)【国際特許分類】
   H04W 36/28 20090101AFI20171201BHJP
   H04W 16/32 20090101ALI20171201BHJP
   H04W 36/08 20090101ALI20171201BHJP
   H04W 72/04 20090101ALI20171201BHJP
【FI】
   H04W36/28
   H04W16/32
   H04W36/08
   H04W72/04 111
【審査請求】有
【予備審査請求】未請求
【全頁数】81
【出願番号】特願2017-511108(P2017-511108)
(21)【国際出願番号】PCT/0/0
(22)【国際出願日】2016年4月8日
(31)【優先権主張番号】62/145,755
(32)【優先日】2015年4月10日
(33)【優先権主張国】US
(31)【優先権主張番号】62/222,877
(32)【優先日】2015年9月24日
(33)【優先権主張国】US
(31)【優先権主張番号】62/251,890
(32)【優先日】2015年11月6日
(33)【優先権主張国】US
(31)【優先権主張番号】62/251,907
(32)【優先日】2015年11月6日
(33)【優先権主張国】US
(81)【指定国】 AP(BW,GH,GM,KE,LR,LS,MW,MZ,NA,RW,SD,SL,ST,SZ,TZ,UG,ZM,ZW),EA(AM,AZ,BY,KG,KZ,RU,TJ,TM),EP(AL,AT,BE,BG,CH,CY,CZ,DE,DK,EE,ES,FI,FR,GB,GR,HR,HU,IE,IS,IT,LT,LU,LV,MC,MK,MT,NL,NO,PL,PT,RO,RS,SE,SI,SK,SM,TR),OA(BF,BJ,CF,CG,CI,CM,GA,GN,GQ,GW,KM,ML,MR,NE,SN,TD,TG),AE,AG,AL,AM,AO,AT,AU,AZ,BA,BB,BG,BH,BN,BR,BW,BY,BZ,CA,CH,CL,CN,CO,CR,CU,CZ,DE,DK,DM,DO,DZ,EC,EE,EG,ES,FI,GB,GD,GE,GH,GM,GT,HN,HR,HU,ID,IL,IN,IR,IS,JP,KE,KG,KN,KP,KR,KZ,LA,LC,LK,LR,LS,LU,LY,MA,MD,ME,MG,MK,MN,MW,MX,MY,MZ,NA,NG,NI,NO,NZ,OM,PA,PE,PG,PH,PL,PT,QA,RO,RS,RU,RW,SA,SC,SD,SE,SG,SK,SL,SM,ST,SV,SY,TH,TJ,TM,TN,TR,TT,TZ,UA,UG,US
(71)【出願人】
【識別番号】000006633
【氏名又は名称】京セラ株式会社
(74)【代理人】
【識別番号】110001106
【氏名又は名称】キュリーズ特許業務法人
(72)【発明者】
【氏名】三井 勝裕
(72)【発明者】
【氏名】藤代 真人
(72)【発明者】
【氏名】長坂 優志
【テーマコード(参考)】
5K067
【Fターム(参考)】
5K067DD36
5K067DD57
5K067EE02
5K067EE10
5K067EE24
5K067EE56
5K067HH23
5K067JJ39
(57)【要約】
二重接続方式によってソースマスタ基地局及びセカンダリ基地局に接続しているユーザ端末の前記ソースマスタ基地局からターゲットマスタ基地局へのハンドオーバ手順を制御するための方法は、前記ソースマスタ基地局は、前記ターゲットマスタ基地局に対してハンドオーバ要求を送信し、前記ターゲットマスタ基地局から、前記セカンダリ基地局の変更の必要性に関する情報を受信することを含む。
【特許請求の範囲】
【請求項1】
二重接続方式によってソースマスタ基地局及びセカンダリ基地局に接続しているユーザ端末の前記ソースマスタ基地局からターゲットマスタ基地局へのハンドオーバ手順を制御するための方法であって、
前記ソースマスタ基地局は、
前記ターゲットマスタ基地局に対してハンドオーバ要求を送信し、
前記ターゲットマスタ基地局から、前記セカンダリ基地局の変更の必要性に関する情報を受信する方法。
【請求項2】
前記ターゲットマスタ基地局から送信される前記ハンドオーバ要求に対する返答に、前記セカンダリ基地局の変更の必要性に関する前記情報が含まれる請求項1に記載の方法。
【請求項3】
前記セカンダリ基地局の変更の必要性に関する前記情報は、前記ターゲットマスタ基地局が前記セカンダリ基地局を変更する必要があるか否かを判断した結果を含む請求項1に記載の方法。
【請求項4】
前記ソースマスタ基地局は、前記セカンダリ基地局の変更の必要性に関する前記情報に基づいて、以降のハンドオーバ手順を決定する請求項1に記載の方法。
【請求項5】
前記ソースマスタ基地局は、前記セカンダリ基地局の変更の必要性に関する前記情報に基づいて、前記セカンダリ基地局を変更する必要があると判断した場合には、以降のハンドオーバ手順を、前記セカンダリ基地局のデータフォワーディング処理を含むハンドオーバ手順に決定する請求項1に記載の方法。
【請求項6】
前記ターゲットマスタ基地局は、
前記セカンダリ基地局を変更する必要がないと判断した場合、前記セカンダリ基地局に対して、前記セカンダリ基地局を維持するためのメッセージを送信し、
前記メッセージに対する返答を前記セカンダリ基地局から受信した後、前記ソースマスタ基地局に対して前記情報を送信する請求項3に記載の方法。
【請求項7】
前記ターゲットマスタ基地局は、所定の情報に基づいて前記セカンダリ基地局を変更する必要があるか否かを判断し、
前記所定の情報は、複数の基地局が管理するセルからの信号の前記ユーザ端末による測定結果、前記ターゲットマスタ基地局がユーザ端末に接続するセカンダリ基地局として過去に設定した基地局に関する情報、セカンダリ基地局における無線リンク失敗情報、予め設定されたセカンダリ基地局として設定すべき基地局に関する情報、前記ターゲットマスタ基地局の負荷状況、前記セカンダリ基地局とサービングゲートウェイとの接続情報、前記ターゲットマスタ基地局と前記セカンダリ基地局との接続情報及び前記ユーザ端末の移動速度情報のうちの少なくとも一つを含む請求項3に記載の方法。
【請求項8】
二重接続方式によってソースマスタ基地局及びソースセカンダリ基地局に接続しているユーザ端末の前記ソースマスタ基地局からターゲットマスタ基地局へのハンドオーバ手順を制御するための方法であって、
前記ターゲットマスタ基地局は、
前記ソースマスタ基地局からハンドオーバ要求を受信すると、前記ソースセカンダリ基地局とは異なる、前記ユーザ端末に新たに接続するターゲットセカンダリ基地局を選択し、
当該選択したターゲットセカンダリ基地局に対して、セカンダリ基地局追加要求を送信する方法。
【請求項9】
前記ハンドオーバ要求は、前記ユーザ端末における複数の基地局からの信号の測定結果を含み、
前記ターゲットマスタ基地局は、前記測定結果に基づいて、前記複数の基地局から前記ターゲットセカンダリ基地局を選択する請求項8に記載の方法。
【請求項10】
前記複数の基地局は、前記ソースマスタ基地局との接続が確立されている基地局である請求項9に記載の方法。
【請求項11】
前記ターゲットマスタ基地局は、複数の基地局が管理するセルからの信号の前記ユーザ端末による測定結果、前記ターゲットマスタ基地局がユーザ端末に接続するセカンダリ基地局として過去に設定した基地局に関する情報、セカンダリ基地局における無線リンク失敗情報及び予め設定されたセカンダリ基地局として設定すべき基地局に関する情報、前記ターゲットマスタ基地局の負荷状況、前記セカンダリ基地局とサービングゲートウェイとの接続情報、前記ターゲットマスタ基地局と前記セカンダリ基地局との接続情報及び前記ユーザ端末の移動速度情報のうちの少なくとも一つに基づいて、前記ターゲットセカンダリ基地局を選択する請求項9に記載の方法。
【請求項12】
前記セカンダリ基地局追加要求は、前記ソースセカンダリ基地局の識別子を含み、
前記ターゲットセカンダリ基地局は、前記ソースセカンダリ基地局の識別子に基づいて、自局と前記ソースセカンダリ基地局との間で接続が確立されている場合には、前記セカンダリ基地局追加要求に対する返答に、X2−Uユーザプレーン用のデータを流すためのX2のトンネル識別子を含めて前記ターゲットマスタ基地局に対して送信する請求項8に記載の方法。
【請求項13】
前記ターゲットマスタ基地局は、前記ソースマスタ基地局に対して、前記ハンドオーバ要求に対する返答を、RRC再設定用の前記ターゲットセカンダリ基地局の設定情報と前記トンネル識別子とを含めて送信する請求項12に記載の方法。
【請求項14】
前記ソースマスタ基地局は、前記ハンドオーバ要求に対する返答に基づいて、前記ソースセカンダリ基地局から前記ターゲットセカンダリ基地局への直接的なデータ転送が可能であると判断すると、前記ソースセカンダリ基地局に対してセカンダリ基地局解放要求に前記トンネル識別子を含めて送信する請求項12に記載の方法。
【請求項15】
前記ソースセカンダリ基地局は、前記セカンダリ基地局解放要求に含まれる前記トンネル識別子に基づいて、前記ターゲットセカンダリ基地局に対して直接的なデータ転送を実行する請求項14に記載の方法。
【請求項16】
二重接続方式によってソースマスタ基地局及びセカンダリ基地局に接続しているユーザ端末の前記ソースマスタ基地局からターゲットマスタ基地局へのハンドオーバ手順を制御するための方法であって、
前記ターゲットマスタ基地局は、
前記ソースマスタ基地局からハンドオーバ要求を受信すると、前記ソースマスタ基地局に確立されているMCGベアラを、前記セカンダリ基地局で用いられるSCGベアラに変更するか否か判断し、
変更すると判断すると、前記セカンダリ基地局の設定を維持すると共に、前記セカンダリ基地局のX2トンネル識別子を前記ソースマスタ基地局へ送信する方法。
【請求項17】
前記セカンダリ基地局のX2トンネル識別子は、前記ソースマスタ基地局から前記セカンダリ基地局へのデータの直接的な転送のために用いられる請求項16に記載の方法。
【請求項18】
二重接続方式によってソースマスタ基地局及びセカンダリ基地局に接続しているユーザ端末の前記ソースマスタ基地局からターゲットマスタ基地局へのハンドオーバ手順を制御するための方法であって、
前記ターゲットマスタ基地局は、
前記ソースマスタ基地局からハンドオーバ要求を受信すると、前記セカンダリ基地局に確立されているSCGベアラを、前記ターゲットマスタ基地局で用いられるMCGベアラに変更するか否か判断し、
変更すると判断すると、前記セカンダリ基地局の設定を維持すると共に、前記ターゲットマスタ基地局のX2トンネル識別子を前記セカンダリ基地局へ送信する方法。
【請求項19】
前記ターゲットマスタ基地局のX2トンネル識別子は、前記セカンダリ基地局から前記ターゲットマスタ基地局へのデータの直接的な転送のために用いられる請求項18に記載の方法。
【請求項20】
二重接続方式によってマスタ基地局である自基地局及びセカンダリ基地局に接続しているユーザ端末の自基地局から他の基地局へのハンドオーバ手順を制御する基地局であって、
前記他の基地局へハンドオーバ要求を送信し、当該ハンドオーバ要求に対する応答を前記他の基地局から受信する通信部を備え、
前記ハンドオーバ要求に対する応答は、自基地局から前記セカンダリ基地局へのデータの直接転送である第1のダイレクトフォワーディング又は前記セカンダリ基地局から前記他の基地局へのデータの直接転送である第2のダイレクトフォワーディングを指示する情報を含む基地局。
【請求項21】
前記通信部は、前記ハンドオーバ要求に対する応答に前記第2のダイレクトフォワーディングの指示が含まれている場合には、前記セカンダリ基地局へ前記第2のダイレクトフォワーディングの指示を送信する請求項20に記載の基地局。
【請求項22】
二重接続方式によってマスタ基地局である他の基地局及びセカンダリ基地局に接続しているユーザ端末の前記他の基地局から自基地局へのハンドオーバ要求を前記他の基地局から受信する通信部と、
前記通信部は、前記ハンドオーバ要求に対する応答を前記他の基地局へ送信し、
前記ハンドオーバ要求に対する応答は、前記他の基地局から前記セカンダリ基地局へのデータの直接転送であるダイレクトフォワーディング又は前記セカンダリ基地局から自基地局へのデータの直接転送であるダイレクトフォワーディングを指示する情報を含む基地局。
【請求項23】
前記ダイレクトフォワーディングを指示する情報は、当該ダイレクトフォワーディングの対象となるベアラの識別子及び/又は前記データの転送先の識別子に対応付けられている請求項20に記載の基地局。
【請求項24】
二重接続方式をサポートする移動通信システムにおいて、ソース基地局からターゲット基地局に対してユーザ端末のハンドオーバを行う場合における前記ターゲット基地局であって、
前記ユーザ端末のベアラのデータを前記ソース基地局からセカンダリ基地局に直接的に転送するダイレクトフォワーディングに用いる第1のトンネリング識別子と、前記ターゲット基地局を介して前記データを前記セカンダリ基地局に間接的に転送するインダイレクトフォワーディングに用いる第2のトンネリング識別子と、前記ベアラを識別するベアラ識別子と、を含むメッセージを前記ソース基地局に送信する制御部を備え、
前記メッセージにおいて、前記第1のトンネリング識別子及び前記第2のトンネリング識別子は、同一の前記ベアラ識別子に対応付けられているターゲット基地局。
【請求項25】
前記メッセージは、前記ソース基地局から送信されたハンドオーバ要求に対するハンドオーバ要求応答である請求項24に記載のターゲット基地局。
【請求項26】
前記制御部は、前記ベアラのタイプを、前記ソース基地局を介して前記ベアラを確立する第1のタイプから、前記セカンダリ基地局を介して前記ベアラを確立する第2のタイプに変更すると決定する請求項24に記載のターゲット基地局。
【請求項27】
二重接続方式をサポートする移動通信システムにおいて、ソース基地局からターゲット基地局に対してユーザ端末のハンドオーバを行う場合における前記ソース基地局であって、
前記ユーザ端末のベアラのデータを前記ソース基地局からセカンダリ基地局に直接的に転送するダイレクトフォワーディングに用いる第1のトンネリング識別子と、前記ターゲット基地局を介して前記データを前記セカンダリ基地局に間接的に転送するインダイレクトフォワーディングに用いる第2のトンネリング識別子と、前記ベアラを識別するベアラ識別子と、を含むメッセージを前記ターゲット基地局から受信する制御部を備え、
前記メッセージにおいて、前記第1のトンネリング識別子及び前記第2のトンネリング識別子は、同一の前記ベアラ識別子に対応付けられているソース基地局。
【請求項28】
前記制御部は、
前記ダイレクトフォワーディング及び前記インダイレクトフォワーディングのうちの一のフォワーディング方式を決定し、
前記決定したフォワーディング方式に応じて、前記第1のトンネリング識別子及び前記第2のトンネリング識別子の何れかを用いて前記ベアラに対するフォワーディング制御を行う請求項27に記載のソース基地局。
【請求項29】
二重接続方式をサポートする移動通信システムにおいて、ソース基地局からターゲット基地局に対してユーザ端末のハンドオーバを行う場合における前記ターゲット基地局であって、
前記ユーザ端末のベアラのデータを前記ソース基地局からセカンダリ基地局に直接的に転送するダイレクトフォワーディング、及び前記ターゲット基地局を介して前記データを前記セカンダリ基地局に間接的に転送するインダイレクトフォワーディングのうちの一のフォワーディング方式を前記ソース基地局が決定可能であることを示す情報要素を前記ソース基地局に送信する制御部を備えるターゲット基地局。
【請求項30】
前記制御部は、前記ダイレクトフォワーディングに用いる第1のトンネリング識別子と、前記ベアラを識別する第1のベアラ識別子と、前記インダイレクトフォワーディングに用いる第2のトンネリング識別子と、前記ベアラを識別する第2のベアラ識別子と、前記情報要素と、を含むメッセージを前記ソース基地局に送信し、
前記メッセージにおいて、前記第1のトンネリング識別子が前記第1のベアラ識別子に対応付けられ、かつ、前記第2のトンネリング識別子が前記第2のベアラ識別子に対応付けられている請求項29に記載のターゲット基地局。
【請求項31】
前記メッセージは、前記ソース基地局から送信されたハンドオーバ要求に対するハンドオーバ要求応答である請求項30に記載のターゲット基地局。
【請求項32】
前記制御部は、前記ベアラのタイプを、前記ソース基地局を介して前記ベアラを確立する第1のタイプから、前記セカンダリ基地局を介して前記ベアラを確立する第2のタイプに変更すると決定する請求項30に記載のターゲット基地局。
【請求項33】
二重接続方式をサポートする移動通信システムにおいて、ソース基地局からターゲット基地局に対してユーザ端末のハンドオーバを行う場合における前記ソース基地局であって、
前記ユーザ端末のベアラのデータを前記ソース基地局からセカンダリ基地局に直接的に転送するダイレクトフォワーディング、及び前記ターゲット基地局を介して前記データを前記セカンダリ基地局に間接的に転送するインダイレクトフォワーディングのうちの一のフォワーディング方式を前記ソース基地局が決定可能であることを示す情報要素を前記ターゲット基地局から受信する制御部を備え、
前記制御部は、前記情報要素の受信に応じて、前記ダイレクトフォワーディング及び前記インダイレクトフォワーディングのうちの一のフォワーディング方式を決定するソース基地局。
【請求項34】
前記制御部は、
前記ダイレクトフォワーディングに用いる第1のトンネリング識別子と、前記ベアラを識別する第1のベアラ識別子と、前記インダイレクトフォワーディングに用いる第2のトンネリング識別子と、前記ベアラを識別する第2のベアラ識別子と、前記情報要素と、を含むメッセージを前記ターゲット基地局から受信し、
前記決定したフォワーディング方式に応じて、前記第1のトンネリング識別子及び前記第2のトンネリング識別子の何れかを用いて前記ベアラに対するフォワーディング制御を行う請求項33に記載のソース基地局。
【請求項35】
二重接続方式をサポートする移動通信システムにおいて、ソース基地局からターゲット基地局に対してユーザ端末のハンドオーバを行う場合における前記ソース基地局であって、
前記ユーザ端末のベアラのデータを前記ソース基地局からセカンダリ基地局に直接的に転送するダイレクトフォワーディングが可能であることを示す通知情報を前記ターゲット基地局に送信する制御部を備えるソース基地局。
【請求項36】
前記制御部は、前記ソース基地局から前記ターゲット基地局に送信するハンドオーバ要求に前記通知情報を含める請求項35に記載のソース基地局。
【請求項37】
前記通知情報は、前記ソース基地局が前記ダイレクトフォワーディングを提案することを示す情報、又は、前記ソース基地局と前記セカンダリ基地局との間のX2インターフェイスが利用可能であることを示す情報である請求項35に記載のソース基地局。
【請求項38】
二重接続方式をサポートする移動通信システムにおいて、ソース基地局からターゲット基地局に対してユーザ端末のハンドオーバを行う場合における前記ターゲット基地局であって、
前記ユーザ端末のベアラのデータを前記ソース基地局からセカンダリ基地局に直接的に転送するダイレクトフォワーディングが可能であることを示す通知情報を前記ソース基地局から受信する制御部を備え、
前記制御部は、前記通知情報の受信に応じて、前記ダイレクトフォワーディング、及び、前記ターゲット基地局を介して前記データを前記セカンダリ基地局に間接的に転送するインダイレクトフォワーディングのうちの一のフォワーディング方式を決定するターゲット基地局。
【請求項39】
二重接続方式をサポートする移動通信システムにおいて、ソース基地局からターゲット基地局に対してユーザ端末のハンドオーバを行う場合における前記ターゲット基地局であって、
前記ユーザ端末のベアラのデータを前記ソース基地局から前記ターゲット基地局を介してセカンダリ基地局に間接的に転送するインダイレクトフォワーディングに用いるトンネリング識別子を設定した後、前記トンネリング識別子を含むメッセージを前記ソース基地局に送信する制御部を備え、
前記制御部は、前記メッセージを前記ソース基地局に送信した際に、前記インダイレクトフォワーディングが開始されるまでの最大待ち時間を規定するタイマを開始させるターゲット基地局。
【請求項40】
前記制御部は、
前記タイマの時間内で前記インダイレクトフォワーディングが開始された場合、前記タイマを停止させ、
前記タイマが満了した場合、前記トンネリング識別子を解放する請求項39に記載のターゲット基地局。
【請求項41】
前記メッセージは、前記ソース基地局から送信されたハンドオーバ要求に対するハンドオーバ要求応答である請求項39に記載のターゲット基地局。
【請求項42】
二重接続方式をサポートする移動通信システムにおいて、ソース基地局からターゲット基地局に対してユーザ端末のハンドオーバを行う場合における前記ソース基地局であって、
前記ユーザ端末のベアラのデータを前記ソース基地局からセカンダリ基地局に直接的に転送するダイレクトフォワーディング、及び前記ターゲット基地局を介して前記データを前記セカンダリ基地局に間接的に転送するインダイレクトフォワーディングのうちの一のフォワーディング方式を決定する制御部を備え、
前記制御部は、前記ダイレクトフォワーディングを決定した場合、前記ダイレクトフォワーディングに関する通知情報を前記ターゲット基地局に送信するソース基地局。
【請求項43】
前記制御部は、前記ダイレクトフォワーディングが完了した場合、前記通知情報としてのエンドマーカを前記ターゲット基地局に送信する請求項42に記載のソース基地局。
【請求項44】
二重接続方式をサポートする移動通信システムにおいて、ソース基地局からターゲット基地局に対してユーザ端末のハンドオーバを行う場合における前記ターゲット基地局であって、
前記ユーザ端末のベアラのデータを前記ソース基地局から前記ターゲット基地局を介してセカンダリ基地局に間接的に転送するインダイレクトフォワーディングに用いるトンネリング識別子を設定した後、前記トンネリング識別子を含むメッセージを前記ソース基地局に送信する制御部を備え、
前記制御部は、前記データを前記ソース基地局から前記セカンダリ基地局に直接的に転送するダイレクトフォワーディングを前記ソース基地局が決定した場合、前記ダイレクトフォワーディングに関する通知情報を前記ソース基地局から受信するターゲット基地局。
【請求項45】
前記制御部は、前記通知情報の受信に応じて、前記トンネリング識別子を解放する請求項44に記載のターゲット基地局。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、ハンドオーバ手順を制御するための方法及び基地局に関する。
【背景技術】
【0002】
移動通信システムの標準化プロジェクトである3GPP(3rd Generation Partnership Project)では、一般基地局(例えば、マクロセル基地局)よりもカバレッジの狭い特定基地局(例えば、小セル基地局)を効率的に利用するための検討が進められている。
【0003】
また、3GPPでは、リリース12以降において二重接続方式(Dual connectivity)の導入が予定されている(非特許文献1参照)。二重接続方式では、ユーザ端末は、複数の基地局(一般基地局及び特定基地局)との接続を同時に確立する。ユーザ端末には、各基地局から無線リソースが割り当てられるため、スループットの向上が見込まれる。なお、二重接続方式は、基地局間キャリアアグリゲーション(inter−eNB CA)と称されることがある。
【0004】
二重接続方式では、ユーザ端末との接続を確立する複数の基地局のうち、1つの基地局(以下、「マスタ基地局」という)のみが当該ユーザ端末とのRRC接続を確立する。これに対し、当該複数の基地局のうち他の基地局(以下、「セカンダリ基地局」という)は、RRC接続をユーザ端末と確立せずに、追加的な無線リソースをユーザ端末に提供する。
【発明の概要】
【0005】
一の実施形態に係る方法は、二重接続方式によってソースマスタ基地局及びセカンダリ基地局に接続しているユーザ端末の前記ソースマスタ基地局からターゲットマスタ基地局へのハンドオーバ手順を制御するための方法である。方法は、前記ソースマスタ基地局は、前記ターゲットマスタ基地局に対してハンドオーバ要求を送信し、前記ターゲットマスタ基地局から、前記セカンダリ基地局の変更の必要性に関する情報を受信することを含む。
【0006】
一の実施形態に係る方法は、二重接続方式によってソースマスタ基地局及びセカンダリ基地局に接続しているユーザ端末の前記ソースマスタ基地局からターゲットマスタ基地局へのハンドオーバ手順を制御するための方法である。方法は、前記ターゲットマスタ基地局は、前記ソースマスタ基地局からハンドオーバ要求を受信すると、所定の情報に基づいて、前記セカンダリ基地局を変更する必要があるか否かを判断し、当該判断の結果に基づいて、前記セカンダリ基地局の変更の必要性に関する情報を前記ソースマスタ基地局に対して送信することを含む。
【0007】
一の実施形態に係る方法は、二重接続方式によってソースマスタ基地局及びソースセカンダリ基地局に接続しているユーザ端末の前記ソースマスタ基地局からターゲットマスタ基地局へのハンドオーバ手順を制御するための方法である。方法は、前記ターゲットマスタ基地局は、前記ソースマスタ基地局からハンドオーバ要求を受信すると、前記ソースセカンダリ基地局とは異なる、前記ユーザ端末に新たに接続するターゲットセカンダリ基地局を選択し、当該選択したターゲットセカンダリ基地局に対して、セカンダリ基地局追加要求を送信することを含む。
【0008】
一の実施形態に係るターゲット基地局は、二重接続方式をサポートする移動通信システムにおいて、ソース基地局からターゲット基地局に対してユーザ端末のハンドオーバを行う場合における前記ターゲット基地局である。前記ターゲット基地局は、前記ユーザ端末のベアラのデータを前記ソース基地局からセカンダリ基地局に直接的に転送するダイレクトフォワーディングに用いる第1のトンネリング識別子と、前記ターゲット基地局を介して前記データを前記セカンダリ基地局に間接的に転送するインダイレクトフォワーディングに用いる第2のトンネリング識別子と、前記ベアラを識別するベアラ識別子と、を含むメッセージを前記ソース基地局に送信する制御部を備える。前記メッセージにおいて、前記第1のトンネリング識別子及び前記第2のトンネリング識別子は、同一の前記ベアラ識別子に対応付けられている。
【0009】
一の実施形態に係るソース基地局は、二重接続方式をサポートする移動通信システムにおいて、ソース基地局からターゲット基地局に対してユーザ端末のハンドオーバを行う場合における前記ソース基地局である。前記ソース基地局は、前記ユーザ端末のベアラのデータを前記ソース基地局からセカンダリ基地局に直接的に転送するダイレクトフォワーディングに用いる第1のトンネリング識別子と、前記ターゲット基地局を介して前記データを前記セカンダリ基地局に間接的に転送するインダイレクトフォワーディングに用いる第2のトンネリング識別子と、前記ベアラを識別するベアラ識別子と、を含むメッセージを前記ターゲット基地局から受信する制御部を備える。前記メッセージにおいて、前記第1のトンネリング識別子及び前記第2のトンネリング識別子は、同一の前記ベアラ識別子に対応付けられている。
【0010】
一の実施形態に係るターゲット基地局は、二重接続方式をサポートする移動通信システムにおいて、ソース基地局からターゲット基地局に対してユーザ端末のハンドオーバを行う場合における前記ターゲット基地局である。前記ターゲット基地局は、前記ユーザ端末のベアラのデータを前記ソース基地局からセカンダリ基地局に直接的に転送するダイレクトフォワーディング、及び前記ターゲット基地局を介して前記データを前記セカンダリ基地局に間接的に転送するインダイレクトフォワーディングのうちの一のフォワーディング方式を前記ソース基地局が決定可能であることを示す情報要素を前記ソース基地局に送信する制御部を備える。
【0011】
一の実施形態に係るソース基地局は、二重接続方式をサポートする移動通信システムにおいて、ソース基地局からターゲット基地局に対してユーザ端末のハンドオーバを行う場合における前記ソース基地局である。前記ソース基地局は、前記ユーザ端末のベアラのデータを前記ソース基地局からセカンダリ基地局に直接的に転送するダイレクトフォワーディング、及び前記ターゲット基地局を介して前記データを前記セカンダリ基地局に間接的に転送するインダイレクトフォワーディングのうちの一のフォワーディング方式を前記ソース基地局が決定可能であることを示す情報要素を前記ターゲット基地局から受信する制御部を備える。前記制御部は、前記情報要素の受信に応じて、前記ダイレクトフォワーディング及び前記インダイレクトフォワーディングのうちの一のフォワーディング方式を決定する。
【0012】
一の実施形態に係るソース基地局は、二重接続方式をサポートする移動通信システムにおいて、ソース基地局からターゲット基地局に対してユーザ端末のハンドオーバを行う場合における前記ソース基地局である。前記ソース基地局は、前記ユーザ端末のベアラのデータを前記ソース基地局からセカンダリ基地局に直接的に転送するダイレクトフォワーディングが可能であることを示す通知情報を前記ターゲット基地局に送信する制御部を備える。
【0013】
一の実施形態に係るターゲット基地局は、二重接続方式をサポートする移動通信システムにおいて、ソース基地局からターゲット基地局に対してユーザ端末のハンドオーバを行う場合における前記ターゲット基地局である。前記ターゲット基地局は、前記ユーザ端末のベアラのデータを前記ソース基地局から前記セカンダリ基地局に直接的に転送するダイレクトフォワーディングが可能であることを示す通知情報を前記ソース基地局から受信する制御部を備える。前記制御部は、前記通知情報の受信に応じて、前記ダイレクトフォワーディング、及び、前記ターゲット基地局を介して前記データを前記セカンダリ基地局に間接的に転送するインダイレクトフォワーディングのうちの一のフォワーディング方式を決定する。
【0014】
一の実施形態に係るターゲット基地局は、二重接続方式をサポートする移動通信システムにおいて、ソース基地局からターゲット基地局に対してユーザ端末のハンドオーバを行う場合における前記ターゲット基地局である。前記ターゲット基地局は、前記ユーザ端末のベアラのデータを前記ソース基地局から前記ターゲット基地局を介してセカンダリ基地局に間接的に転送するインダイレクトフォワーディングに用いるトンネリング識別子を設定した後、前記トンネリング識別子を含むメッセージを前記ソース基地局に送信する制御部を備える。前記制御部は、前記メッセージを前記ソース基地局に送信した際に、前記インダイレクトフォワーディングが開始されるまでの最大待ち時間を規定するタイマを開始させる。
【0015】
一の実施形態に係るソース基地局は、二重接続方式をサポートする移動通信システムにおいて、ソース基地局からターゲット基地局に対してユーザ端末のハンドオーバを行う場合における前記ソース基地局である。前記ソース基地局は、前記ユーザ端末のベアラのデータを前記ソース基地局からセカンダリ基地局に直接的に転送するダイレクトフォワーディング、及び前記ターゲット基地局を介して前記データを前記セカンダリ基地局に間接的に転送するインダイレクトフォワーディングのうちの一のフォワーディング方式を決定する制御部を備える。前記制御部は、前記ダイレクトフォワーディングを決定した場合、前記ダイレクトフォワーディングに関する通知情報を前記ターゲット基地局に送信する。
【0016】
一の実施形態に係るターゲット基地局は、二重接続方式をサポートする移動通信システムにおいて、ソース基地局からターゲット基地局に対してユーザ端末のハンドオーバを行う場合における前記ターゲット基地局である、前記ターゲット基地局は、前記ユーザ端末のベアラのデータを前記ソース基地局から前記ターゲット基地局を介してセカンダリ基地局に間接的に転送するインダイレクトフォワーディングに用いるトンネリング識別子を設定した後、前記トンネリング識別子を含むメッセージを前記ソース基地局に送信する制御部を備える。前記制御部は、前記データを前記ソース基地局から前記セカンダリ基地局に直接的に転送するダイレクトフォワーディングを前記ソース基地局が決定した場合、前記ダイレクトフォワーディングに関する通知情報を前記ソース基地局から受信する。
【図面の簡単な説明】
【0017】
図1】実施形態に係るLTEシステムである。
図2】実施形態に係るUEのブロック図である。
図3】実施形態に係るeNBのブロック図である。
図4】実施形態に係る無線インターフェイスのプロトコルスタック図である。
図5】二重接続方式の概要を説明するための図である。
図6】第1のUPアーキテクチャ(UPアーキテクチャ「1A」)を示す図である。図6Aはデータパス構成を示し、図6Bはプロトコルスタック構成を示す。
図7】第2のUPアーキテクチャ(UPアーキテクチャ「3C」)を示す図である。図7Aはデータパス構成を示し、図7Bはプロトコルスタック構成を示す。
図8】第1実施形態に係る動作環境を示す図である。
図9】第1のハンドオーバ手順に係るシーケンス図である。
図10】第2のハンドオーバ手順に係るシーケンス図である。
図11】第3のハンドオーバ手順に係るシーケンス図である。
図12】第4のハンドオーバ手順に係るシーケンス図である。
図13】第5のハンドオーバ手順に係るシーケンス図である。
図14】第6のハンドオーバ手順に係るシーケンス図である。
図15】二重接続方式の概要を示す図である。
図16】二重接続方式におけるベアラ構成例1を示す図である。
図17】二重接続方式におけるベアラ構成例2を示す図である。
図18】第2実施形態乃至第6実施形態に係る想定シナリオを示す図である。
図19】第2実施形態乃至第6実施形態に係るフォワーディング方式を示す図である。
図20】第2実施形態に係る概略シーケンスを示す図である。
図21】第2実施形態に係る詳細シーケンスの一例を示す図である。
図22】第5実施形態に係るターゲットMeNB200M2の動作を示すフロー図である。
図23】第6実施形態に係る動作シーケンスの一例を示す図である。
図24】付記に係るベアラタイプの変更(SCGからMCGへ)を伴う直接データ転送を示す図である。
図25】付記に係るベアラタイプの変更(MCGからSCGへ)を伴う直接データ転送を示す図である。
図26】付記に係るハンドオーバ準備が成功する動作を示す図である。
図27】付記に係るMeNB始動のSeNB解放が成功する動作を示す図である。
【発明を実施するための形態】
【0018】
[第1実施形態]
以下において、本発明をLTEシステムに適用する場合の第1実施形態を説明する。
【0019】
(システム構成)
図1は、第1実施形態に係るLTEシステムの構成図である。
【0020】
図1に示すように、第1実施形態に係るLTEシステムは、UE(User Equipment)100、E−UTRAN(Evolved−UMTS Terrestrial Radio Access Network)10、及びEPC(Evolved Packet Core)20を備える。
【0021】
UE100は、ユーザ端末に相当する。UE100は、移動型の通信装置であり、セル(サービングセル)との無線通信を行う。UE100の構成については後述する。
【0022】
E−UTRAN10は、無線アクセスネットワークに相当する。E−UTRAN10は、eNB200(evolved Node−B)を含む。eNB200は、基地局に相当する。eNB200は、X2インターフェイスを介して相互に接続される。eNB200の構成については後述する。
【0023】
eNB200は、1又は複数のセルを管理しており、自セルとの接続を確立したUE100との無線通信を行う。eNB200は、無線リソース管理(RRM)機能、ユーザデータのルーティング機能、モビリティ制御・スケジューリングのための測定制御機能などを有する。「セル」は、無線通信エリアの最小単位を示す用語として使用される他に、UE100との無線通信を行う機能を示す用語としても使用される。
【0024】
EPC20は、コアネットワークに相当する。EPC20は、MME(Mobility Management Entity)/S−GW(Serving−Gateway)300を含む。MMEは、UE100に対する各種モビリティ制御などを行う。S−GWは、ユーザデータの転送制御を行う。MME/S−GW300は、S1インターフェイスを介してeNB200と接続される。
【0025】
図2は、UE100のブロック図である。図2に示すように、UE100は、複数のアンテナ101、無線送受信機110、ユーザインターフェイス120、GNSS(Global Navigation Satellite System)受信機130、バッテリ140、メモリ150、及びプロセッサ160を備える。メモリ150及びプロセッサ160は、制御部を構成する。UE100は、GNSS受信機130を有していなくてもよい。また、メモリ150をプロセッサ160と一体化し、このセット(すなわち、チップセット)をプロセッサ160’としてもよい。
【0026】
アンテナ101及び無線送受信機110は、無線信号の送受信に用いられる。無線送受信機110は、プロセッサ160が出力するベースバンド信号(送信信号)を無線信号に変換してアンテナ101から送信する。また、無線送受信機110は、アンテナ101が受信する無線信号をベースバンド信号(受信信号)に変換してプロセッサ160に出力する。
【0027】
ユーザインターフェイス120は、UE100を所持するユーザとのインターフェイスであり、例えば、ディスプレイ、マイク、スピーカ、及び各種ボタンなどを含む。ユーザインターフェイス120は、ユーザからの操作を受け付けて、該操作の内容を示す信号をプロセッサ160に出力する。GNSS受信機130は、UE100の地理的な位置を示す位置情報を得るために、GNSS信号を受信して、受信した信号をプロセッサ160に出力する。バッテリ140は、UE100の各ブロックに供給すべき電力を蓄える。
【0028】
メモリ150は、プロセッサ160により実行されるプログラム、及びプロセッサ160による処理に使用される情報を記憶する。プロセッサ160は、ベースバンド信号の変調・復調及び符号化・復号などを行うベースバンドプロセッサと、メモリ150に記憶されるプログラムを実行して各種の処理を行うCPU(Central Processing Unit)と、を含む。プロセッサ160は、さらに、音声・映像信号の符号化・復号を行うコーデックを含んでもよい。プロセッサ160は、後述する各種の処理及び各種の通信プロトコルを実行する。
【0029】
図3は、eNB200のブロック図である。図3に示すように、eNB200は、複数のアンテナ201、無線送受信機210、ネットワークインターフェイス220、メモリ230、及びプロセッサ240を備える。メモリ230及びプロセッサ240は、制御部を構成する。また、メモリ230をプロセッサ240と一体化し、このセット(すなわち、チップセット)をプロセッサとしてもよい。
【0030】
アンテナ201及び無線送受信機210は、無線信号の送受信に用いられる。無線送受信機210は、プロセッサ240が出力するベースバンド信号(送信信号)を無線信号に変換してアンテナ201から送信する。また、無線送受信機210は、アンテナ201が受信する無線信号をベースバンド信号(受信信号)に変換してプロセッサ240に出力する。
【0031】
ネットワークインターフェイス220は、X2インターフェイスを介して隣接eNB200と接続され、S1インターフェイスを介してMME/S−GW300と接続される。ネットワークインターフェイス220は、X2インターフェイス上で行う通信及びS1インターフェイス上で行う通信に用いられる。
【0032】
メモリ230は、プロセッサ240により実行されるプログラム、及びプロセッサ240による処理に使用される情報を記憶する。プロセッサ240は、ベースバンド信号の変調・復調及び符号化・復号などを行うベースバンドプロセッサと、メモリ230に記憶されるプログラムを実行して各種の処理を行うCPUと、を含む。プロセッサ240は、後述する各種の処理及び各種の通信プロトコルを実行する。
【0033】
図4は、LTEシステムにおける無線インターフェイスのプロトコルスタック図である。図4に示すように、無線インターフェイスプロトコルは、OSI参照モデルの第1層乃至第3層に区分されており、第1層は物理(PHY)層である。第2層は、MAC(Medium Access Control)層、RLC(Radio Link Control)層、及びPDCP(Packet Data Convergence Protocol)層を含む。第3層は、RRC(Radio Resource Control)層を含む。
【0034】
物理層は、符号化・復号、変調・復調、アンテナマッピング・デマッピング、及びリソースマッピング・デマッピングを行う。UE100の物理層とeNB200の物理層との間では、物理チャネルを介してユーザデータ及び制御信号が伝送される。
【0035】
MAC層は、データの優先制御、ハイブリッドARQ(HARQ)による再送処理、及びRRC接続確立時のランダムアクセス手順などを行う。UE100のMAC層とeNB200のMAC層との間では、トランスポートチャネルを介してユーザデータ及び制御信号が伝送される。eNB200のMAC層は、上下リンクのトランスポートフォーマット(トランスポートブロックサイズ、変調・符号化方式)及びUE100への割当リソースブロックを決定するスケジューラを含む。
【0036】
RLC層は、MAC層及び物理層の機能を利用してデータを受信側のRLC層に伝送する。UE100のRLC層とeNB200のRLC層との間では、論理チャネルを介してユーザデータ及び制御信号が伝送される。
【0037】
PDCP層は、ヘッダ圧縮・伸張、及び暗号化・復号化を行う。
【0038】
RRC層は、制御信号を取り扱う制御プレーンでのみ定義される。UE100のRRC層とeNB200のRRC層との間では、各種設定のための制御信号(RRCメッセージ)が伝送される。RRC層は、無線ベアラの確立、再確立及び解放に応じて、論理チャネル、トランスポートチャネル、及び物理チャネルを制御する。UE100のRRCとeNB200のRRCとの間に接続(RRC接続)がある場合、UE100はRRCコネクティッド状態であり、そうでない場合、UE100はRRCアイドル状態である。
【0039】
RRC層の上位に位置するNAS(Non−Access Stratum)層は、セッション管理及びモビリティ管理などを行う。
【0040】
(二重接続方式)
第1実施形態に係るLTEシステムは、二重接続方式をサポートする。二重接続方式は、リリース12以降において導入が予定されている。二重接続方式では、UE100は、複数のeNB200との接続を同時に確立する。UE100には、各eNB200から無線リソースが割り当てられるため、スループットの向上が見込まれる。なお、二重接続方式は、eNB200間キャリアアグリゲーション(inter−eNB CA)と称されることもある。
【0041】
図5は、二重接続方式の概要を説明するための図である。
【0042】
図5に示すように、二重接続方式では、UE100との接続を確立する複数のeNB200のうち、MeNB(MeNB)200Mのみが当該UE100とのRRC接続を確立する。これに対し、当該複数のeNB200のうちセカンダリeNB(SeNB)200Sは、RRC接続をUE100と確立せずに、追加的な無線リソースをUE100に提供する。言い換えると、MeNB200Mは、ユーザプレーン接続だけでなく制御プレーン接続をUE100と確立する。これに対し、SeNB200Sは、制御プレーン接続をUE100と確立せずに、ユーザプレーン接続をUE100と確立する。MeNB200MとSeNB200Sとの間にはXnインターフェイスが設定される。Xnインターフェイスは、X2インターフェイス又は新たなインターフェイスである。
【0043】
二重接続方式では、UE100は、MeNB200Mが管理するN個のセル及びSeNB200Sが管理するM個のセルを同時に利用したキャリアアグリゲーションが可能である。二重接続方式においてUE100のサービングセルの最大数、すなわち、(N+M)の最大数は、例えば5である。ここで、MeNB200Mが管理するN個のセルからなるグループは、マスタセルグループ(MCG)と称される。また、SeNB200Sが管理するM個のセルからなるグループは、セカンダリセルグループ(SCG)と称される。SCGには、UE100のPUCCHを設ける特別なセルが設定される。特別なセルは、キャリアアグリゲーションにおけるプライマリセル(PCell)の機能の一部を遂行する。
【0044】
図6及び図7は、二重接続方式におけるユーザデータの転送経路(データパス)の構成方式を説明するための図である。二重接続方式におけるユーザデータの転送経路(データパス)を構成するユーザプレーンアーキテクチャ(UPアーキテクチャ)は主に2通り存在する。
【0045】
図6は、第1のUPアーキテクチャ(UPアーキテクチャ「1A」とも称される)を示す。図6Aに示すように、第1のUPアーキテクチャでは、MeNB200MとS−GW300Uとの間のS1−Uインターフェイスと、SeNB200SとS−GW300Uとの間のS1−Uインターフェイスと、が利用される。UE100とP−GWとの間のEPSベアラ#1は、MeNB200MとS−GW300Uとの間のS1−Uインターフェイスを経由する。UE100とP−GWとの間のEPSベアラ#2は、SeNB200SとS−GW300Uとの間のS1−Uインターフェイスを経由する。このように、第1のUPアーキテクチャでは、SeNB200SとS−GW300Uとの間のデータパスはMeNB200Mを経由しない。図6Bに示すように、MeNB200M及びSeNB200Sのそれぞれは、PDCP、RLC、MACの各層の処理を行う。なお、図6Aに示すEPSベアラ#1は「MCGベアラ」と称され、EPSベアラ#2は「SCGベアラ」と称されてもよい。また、第1のUPアーキテクチャは、SCGベアラ・オプションと称されてもよい。
【0046】
図7は、第2のUPアーキテクチャ(UPアーキテクチャ「3C」とも称される)を示す。図7Aに示すように、第2のUPアーキテクチャでは、UE100とP−GWとの間のEPSベアラ#2は、MeNB200Mにおいて分割されており、分割された一方(split bearer)はSeNB200Sを経由してUE100で終端し、分割された他方(split bearer)はSeNB200Sを経由せずにUE100で終端する。このように、第2のUPアーキテクチャでは、SeNB200SとS−GW300Uとの間のデータパスはMeNB200Mを経由する。図7Bに示すように、EPSベアラ#2における分割された一方(split bearer)については、MeNB200MのPDCP、SeNB200SのRLC及びMAC、により各層の処理を行う。なお、split bearerについては、RLC(又はRLCの一部機能)までの処理をMeNB200Mが担当してもよい。なお、図7Aに示すEPSベアラ#1は「MCGベアラ」と称され、EPSベアラ#2は「スプリットベアラ」と称されてもよい。第2のUPアーキテクチャは、スプリットベアラ・オプションと称されてもよい。
【0047】
ところで、二重接続方式によってMeNB200M1とSeNB200S1と同時に接続しているUE100が、移動等によって信号の受信状況等の環境が変化すると、MeNB200M1(ソースMeNB、以下S−MeNB200M1と称する)から他のMeNB200M2(ターゲットMeNB又はターゲットeNB,以下、T−MeNB200M2又はT−eNB200M2と称する)へのハンドオーバを実行する。さらに、UE100が接続するSeNB200Sも変更する場合には、以下の2つのシナリオが想定される。
【0048】
第1のシナリオは、一旦、UE100と接続するSeNB200Sを変更せず(SeNB200SとUE100との接続を維持しつつ)、UE100のS−MeNB200M1からT−MeNB200M2へのハンドオーバ(Inter MeNB Handover without SeNB Change)を実行し、その後に、UE100と接続するSeNB200Sを変更する(SeNB changeを実行する)。
【0049】
なお、第1のシナリオにおけるハンドオーバは、SeNB200SとUE100との接続を維持するための手順を含む。なお、SeNB200SとUE100との接続を維持するとは、ハンドオーバ手順の中で、一旦SeNB200SとUE100との接続を解放し、再度接続する場合も含む。
【0050】
一方で、第2のシナリオは、SeNB200SとUE100との接続を維持せずに解放し、UE100のS−MeNB200MからT−MeNB200Mへのハンドオーバ(MeNB to eNB change)を実行し、その後に、T−MeNB200Mが他のSeNB200Sを追加する(SeNB Additionを実行する)。
【0051】
ここで、UE100の位置環境及び/又はT−MeNB200Mの設定状況に応じては、MeNB200Mのハンドオーバに併せてSeNB200Sを変更することが望ましい場合もある。
【0052】
そのような場合に、仮に、第1のシナリオに沿ってハンドオーバ(Inter MeNB Handover without SeNB Change)を実行すると、即座にUE100と接続するSeNB200Sを変更する(SeNB changeを実行する)こととなるため、SeNBとUE100との接続を維持するための手順が無駄となる可能性がある。
【0053】
そこで、第1実施形態は、UE100の環境及び/又はT−MeNB200M2の設定状況等を踏まえた最適なハンドオーバ手順の実行を実現する。
【0054】
図8は、S−MeNB200M1からT−MeNB200M2へのハンドオーバを実行する際のUE100の環境の一例を示す図である。
【0055】
UE100は、a地点において、S−MeNB200M1が管理するセルM1及びSeNB200S1が管理するセルS1の範囲内に位置し、二重接続方式によって、S−MeNB200M1及びSeNB200S1と接続している。
【0056】
次に、UE100は、矢印に沿って移動後、b地点において、S−MeNB200M1が管理するセルM1及びSeNB200S1が管理するセルS1の範囲内に位置すると共に、eNB200M2が管理するセルM2及びeNB200S2が管理するセルS2の範囲内に位置する。
【0057】
この場合、UE100は、各eNBが管理するセルからの参照信号の測定結果が所定の条件を満たすと、S−MeNB200M1に対して測定報告(Measurement Report)を行い、S−MeNB200M1が、S−MeNB200M1からeNB200M2(T−MeNB200M2)へUE100のハンドオーバを実行する。なお、UE100のハンドオーバとは、例えば、UE100の接続先をS−MeNB200M1(又はS−MeNB200M1が管理するセル)から他のT−MeNB200M2(又はT−MeNB200M2が管理するセル)へ切り替えることであってもよい。
【0058】
なお、S−MeNB200M1及びT−MeNB200M2は、マクロセルを管理するeNBであって、S−SeNB200S1及びeNB200S2は、マクロセルよりエリアの狭いセル(スモールセル)であって、例えばナノセル又はピコセルを管理するeNBであってもよい。また、マクロセルとスモールセルは、異なる周波数で運用されていてもよい。
【0059】
図8に示すような環境において、S−MeNB200M1からT−MeNB200M2へUE100のハンドオーバを実行する際の各ハンドオーバ手順(第1のハンドオーバ手順〜第6のハンドオーバ手順)を、図9図14を用いて以下に説明する。
【0060】
まず、第1のハンドオーバ手順について、図9を用いて以下に説明する。
【0061】
第1のハンドオーバ手順は、UE100と接続するSeNB200S1を変更せずに(接続を維持したままで)、S−MeNB200M1からT−MeNB200M2へUE100のハンドオーバを実行する手順である。
【0062】
なお、第1のハンドオーバ手順は、例えば、Inter MeNB Handover without SeNB Change procedureを一部改変したものであってもよい。
【0063】
ステップS101において、UE100は、eNB200(S−MeNB200M1及び/又はT−MeNB200M2を含む)からの信号の測定結果が一定の条件を満たすと、複数のeNB200(S−MeNB200M1、T−MeNB200M2、SeNB200S1及び/又はeNB200S2を含む)からの信号の測定結果を含む測定報告(Measurement Report)をS−MeNB200M1へ送信する。
【0064】
ステップS102において、S−MeNB200M1は、UE100から測定報告を受信すると、第1のハンドオーバ手順を開始する。なお、第1のハンドオーバ手順の開始は、UE100からの測定報告の受信以外を契機としてもよい。S−MeNB200M1は、第1のハンドオーバ手順を開始すると、ハンドオーバ要求(Handover Request)をT−MeNB200M2へ送信する。ハンドオーバ要求には、ステップS101においてUE100から受信した測定結果を含んでもよい。なお、S−MeNB200M1は、UE100から受信した複数のeNBが管理するセルからの信号の測定結果のうち、一部のeNBが管理するセルからの信号の測定結果のみをハンドオーバ要求に含めて送信してもよい。ハンドオーバ要求には、SeNB変更要否判断の指示を含んでもよい。
【0065】
ステップS103において、T−MeNB200M2は、所定の情報に基づいて、SeNB200S1を変更する必要があるか否か判断する。ここで、SeNB200S1を変更するとは、UE100が、SeNB200S1との接続を解放する及び/又はSeNB200S1とは異なるSeNB200(例えば、SeNB200S2)と新たに接続することを含んでもよい。所定の情報とは、複数のeNBが管理するセルからの信号のUE100による測定結果、過去にT−MeNB200M2がUE100との二重接続の際に設定したSeNB200に関する情報、当該SeNB200における無線リンク失敗(S−RLF:S-Radio Link Failure)、OAM(Operations、 Administration and Maintenance)によって予め設定されたSeNB200に関する情報、T−MeNB200M2の負荷状況(無線リソース消費状況、プロセッシング負荷状況等)、SeNB200S1とS−GW300Uとの接続情報、T−MeNB200M2とSeNB200S1とのX2接続情報、UE100の移動速度情報のうちの一つ若しくは複数の組合せであってもよい。
【0066】
ここで、T−MeNB200M2は、ステップS103において、SeNB200S1を変更する必要がないと判断する(ステップS103 NO)。一例として、T−MeNB200M2は、UE100から受信した測定結果において、SeNB200S1からの信号の品質(SINR及びRSRP等)が一定値以上及び/又はSeNB200S1からの信号の品質が他のeNB(例えば、eNB200S2)からの信号の品質より高い場合に、SeNB200S1を変更する必要が無いと判断してもよい。
【0067】
また、一例として、T−MeNB200M2は、過去にSeNB200S1をSeNBとして設定したことがある、SeNB200S1の無線リンク失敗が一定値未満及び/又はSeNB200S1がOAMによって予めSeNBとして設定されている場合に、SeNB200S1を変更する必要が無いと判断してもよい。
【0068】
ステップS104において、T−MeNB200M2は、SeNB200S1を変更する必要がないと判断する(ステップS103 NO)と、SeNB200S1へSeNB追加要求(SeNB Addition Request)を送信する。
【0069】
ステップS105において、SeNB200S1は、T−MeNB200M2へSeNB追加要求応答(SeNB Addition Request Acknowledgement)を送信する。
【0070】
ステップS106において、T−MeNB200M2は、ハンドオーバ要求応答(Handover Request Acknowledgement)をS−MeNB200M1へ送信する。このハンドオーバ要求応答には、SeNB200S1の変更の必要性に関する情報(SeNB200S1の変更が必要で有る旨)を含む。このSeNBの変更の必要性に関する情報は、T−MeNB200M2がSeNB200S1を変更する必要があるか否かを判断した結果及び/又はSeNB追加手順(SeNB Addition Requestの送信等)を実行した旨を示す情報を含んでもよい。この判断した結果は、S103における判断結果(ステップS103 NO)であって、SeNB200S1の変更不要である。また、SeNBの変更の必要性に関する情報は、UE100の測定結果に含まれる複数のeNBをSeNBとして選択すべき優先順位を含んでもよい。
【0071】
また、このハンドオーバ要求応答には、SeNB200S1の解放に用いられる設定情報(SeNB Release configuration)を含んでもよい。
【0072】
なお、T−MeNB200M2は、ハンドオーバ要求応答を送信することに代えて又はハンドオーバ要求応答を送信すると共に、SeNB変更要求(SeNB change Request)を送信してもよい。T−MeNB200M2は、ハンドオーバ要求応答を送信すると共にSeNB変更要求を送信する場合には、SeNBの変更の必要性に関する情報をハンドオーバ要求応答には含めずにSeNB変更要求に含めてもよい。
【0073】
ステップS107において、S−MeNB200M1は、T−MeNB200M2から受信したハンドオーバ要求応答に含まれる情報に基づいて、以降の手順を決定する。一例として、S−MeNB200M1は、ハンドオーバ要求応答にSeNB200S1の変更不要との判断結果が含まれる場合には、以降の手順(ハンドオーバ手順)を、SeNB200S1を変更しない(又は維持する)手順に決定する。SeNB200S1を変更しない(又は維持する)手順は、以下に説明するステップS108〜S121を含む手順であるが、少なくとも、ステップS112及び/又はステップS113を含むものであればよい。なお、以降の手順を、SeNB200S1を変更しない(又は維持する)手順に決定するとは、ステップS102から開始した、SeNB200S1を変更しないハンドオーバ手順を継続するとの決定であってもよい。
【0074】
ステップS108において、S−MeNB200M1は、SeNB200S1へSeNB解放要求(SeNB Release Request)を送信する。
【0075】
ステップS109において、S−MeNB200M1は、RRC接続再設定(RRC Connection Reconfiguration)をUE100へ送信する。
【0076】
ステップS110において、UE100は、ランダム接続手順(Random Access Procedure)をT−MeNB200M2に対して実行する。
【0077】
ステップS111において、UE100は、RRC接続再設定完了(RRC Connection Reconfiguration Complete)をT−MeNB200M2へ送信する。
【0078】
ステップS112において、UE100は、ランダム接続手順(Random Access Procedure)をSeNB200S1に対して実行する。
【0079】
ステップS113において、T−MeNB200M2は、SeNB200S1へSeNB再設定完了(SeNB Reconfiguration Complete)を送信する。
【0080】
ステップS114において、S−MeNB200M1は、SN Status TransferメッセージをT−MeNB200M2へ通知する。なお、SN Status Transferメッセージは、S−MeNB200M1からT−MeNB200M2への上り又は下りデータの転送状況に関する通知である。
【0081】
ステップS115において、S−MeNB200M1は、S−GW300UからS−MeNB200M1を介してT−MeNB200M2へUE100向けのデータを転送するデータフォワーディングを実行する。
【0082】
ステップS116において、T−MeNB200M2は、S−GW300UとS−MeNB200M1との間のデータパスをT−MeNB200M2へ切換えるために、パス切替要求(Path Switch Request)をMME300Cへ送信する。
【0083】
ステップS117及びステップS118において、S−GW300Uは、MME300Cとの間でベアラ修正(Bearer Modification)をし、新規のデータパスを、T−MeNB200M2との間に設定する(S118a)と共にSeNB200S1との間にSCGベアラで設定する(S118b)。なお、ステップS118bにおいて、SCGベアラを新たに設定してもよい。また、SCGベアラを新たに設定する代わりに、SeNB200S1がS−MeNB200M1によってSCGベアラが設定されている状態で、ハンドオーバ前後において、S−GW300Uが変更されないのであれば、当該SCGベアラを維持してもよい。
【0084】
ステップS119において、MME300Cは、パス切替要求応答(Path Switch Request Acknowledge)をT−MeNB200M2へ送信する。
【0085】
ステップS120において、T−MeNB200M2は、S−MeNB200M1へUEコンテキスト解放(UE Context Release)を送信する。
【0086】
ステップS121において、S−MeNB200M1は、UEコンテキスト解放(UE Context Release)をSeNB200S1へ送信する。
【0087】
なお、ステップS104において、T−MeNB200M2は、SeNB追加要求を送信することに代えて、SeNB修正要求(SeNB Modification Request)をSeNB200S1へ送信してもよい。その場合には、ステップS105において、SeNB200S1は、SeNB追加要求応答の送信に代えて、SeNB修正要求応答(SeNB Modification Request Acknowledgment)をT−MeNB200M2へ送信する。その場合には、S−MeNB200M1は、ステップS108及び/又はステップS121を省略してもよい。
【0088】
第1のハンドオーバ手順によって、T−MeNB200M2におけるSeNB200S1の変更の必要性に応じて、適切なハンドオーバ手順を実行することができる。つまり、T−MeNB200M2において、SeNB200S1の変更が不要(又は維持が必要)と判断された場合には、ハンドオーバ手順後においても、UE100とSeNB200S1との接続が解放されずに維持することができる。
【0089】
次に、第2のハンドオーバ手順について、図10を用いて以下に説明する。
【0090】
第2のハンドオーバ手順は、UE100とSeNB200S1との接続を維持せずに解放し、S−MeNB200M1からT−eNB200M2へUE100のハンドオーバを実行する手順である。
【0091】
なお、第2のハンドオーバ手順は、MeNB to eNB change procedureを一部改変したものであってもよい。
【0092】
UE100、S−MeNB200M1及びT−eNB200M2は、ステップS201〜ステップS203を実行する。なお、ステップS201〜ステップS203は、第1のハンドオーバ手順におけるステップS101〜ステップS103と同じ動作である。
【0093】
ステップS203において、T−eNB200M2は、SeNB200S1を変更する必要がある(又は維持する必要が無い)と判断する(ステップS203 YES)。一例として、T−eNB200M2は、UE100から受信した測定結果において、SeNB200S1が管理するセルからの信号の品質(SINR及びRSRP等)が一定値未満及び/又はSeNB200S1が管理するセルからの信号の品質が他のeNB200(例えば、SeNB200S2)が管理するセルからの信号の品質より低い場合に、SeNB200S1を変更する必要があると判断してもよい。
【0094】
また、一例として、T−eNB200M2は、過去にSeNB200S1をSeNBとして設定したことがない、SeNB200S1の無線リンク失敗が一定値以上及び/又はSeNB200S1がOAMによって予めSeNBとして設定されていない場合に、SeNB200S1を変更する必要が有ると判断してもよい。
【0095】
ステップS204において、T−eNB200M2は、T−SeNB200(例えば、eNB200S2)を選択できるか否かを判断する。ここで、T−eNB200M2は、所定の情報に基づいて、T−SeNB200として選択できるeNBを判断してもよい。一例として、T−eNB200M2は、S−MeNB200M1から受信したUE100における測定結果に含まれる複数のeNBのうち、所定の条件を満たすeNBの有無に応じて、T−SeNBとして選択できるeNBを判断してもよい。所定の条件を満たすeNBは、信号の品質(SINR及びRSRP等)が一定値以上、過去にT−eNB200M2がSeNBとして設定したことがある、無線リンク失敗が一定値未満及び/又はOAMによって予めSeNBとして設定されているeNBであってもよい。
【0096】
なお、T−eNB200M2は、ステップS204は省略してもよく、ステップS203において、SeNB200S1を変更する必要があると判断した場合(ステップS203 YES)に、ステップS205に移ってもよい。
【0097】
T−eNB200M2は、ステップS204を省略した場合若しくはステップS204において、所定の条件を満たすeNBが存在しなかったためT−SeNBを選択できなかった場合(ステップS204 NO)、ステップS205において、ハンドオーバ要求応答(Handover Request Acknowledgement)をS−MeNB200M1へ送信する。ここで、ハンドオーバ要求応答は、SeNBの変更の必要性に関する情報を含む。このSeNBの変更の必要性に関する情報は、T−eNB200M2がSeNB200S1を変更する必要があるか否かを判断した結果及び/又はSeNB追加手順(SeNB Addition Requestの送信等)を実行していない旨を示す情報を含んでもよい。この判断した結果は、S203における判断結果(ステップS203 NO)であって、SeNB200S1の変更が必要であることである。
【0098】
また、T−eNB200M2は、SeNB200S1を変更する必要があると判断すると、SeNB200S1に対して、SeNB追加要求を送信しない(又は送信を禁止する)。
【0099】
ステップS206において、S−MeNB200M1は、T−eNB200M2から受信したハンドオーバ要求応答に含まれる情報に基づいて、以降の手順(ハンドオーバ手順)を決定する。一例として、S−MeNB200M1は、ハンドオーバ要求応答にSeNB200S1を変更する必要があるとの判断結果及び/又はSeNB追加手順(SeNB Addition Requestの送信等)を実行していない旨を示す情報が含まれている場合、以降の手順を、SeNB200S1を維持しない(SeNB200S1との接続を解放する)手順に決定する。SeNBを維持しない手順は、以下に説明するステップS206〜218を含む手順であるが、少なくとも、第1のハンドオーバ手順におけるステップS112及び/又はステップS113を含まない(又はステップS112及び/又はステップS113に相当する動作の実行を禁止する)ものであればよい。つまり、SeNB200S1を維持しない手順は、SeNB200S1に対してUE100及び/又はT−eNB200M2が接続を確立しない手順であればよい。
【0100】
S−MeNB200M1は、ステップS207〜S210を実行するが、これは、第1のハンドオーバ手順におけるステップS108〜S111と同じ動作である。
【0101】
ステップS211及びステップS212において、S−MeNB200M1は、S−GW300UからSeNB200S1及びS−MeNB200M1を介して、T−eNB200M2へUE100向けのデータを転送するデータフォワーディングを実行する。
【0102】
ステップS213において、T−eNB200M2は、S−GW300UとS−MeNB200M1との間のデータパスをT−eNB200M2へ切換えるために、パス切替要求(Path Switch Request)をMME300Cへ送信する。
【0103】
ステップS214において、S−GW300Uは、MME300Cとの間でベアラ修正(Bearer Modification)を実行する。
【0104】
ステップS215において、S−GW300Uは、SeNB200S1及びS−MeNB200M1を介して、T−MeNB200M2へEnd Marker Packetを送信する。
【0105】
ステップS216において、S−GW300Uは、新規のデータパスをT−eNB200M2との間に設定する。
【0106】
ステップS217において、MME300Cは、パス切替要求応答(Path Switch Request Acknowledge)をT−eNB200M2へ送信する。
【0107】
ステップS218において、T−eNB200M2は、S−MeNB200M1へUEコンテキスト解放(UE Context Release)を送信する。
【0108】
ステップS219において、S−MeNB200M1は、UEコンテキスト解放(UE Context Release)をSeNB200S1へ送信する。
【0109】
第2のハンドオーバ手順によって、T−eNB200M2におけるSeNB200S1の変更の必要性に応じて、適切なハンドオーバ手順を実行することができる。つまり、T−MeNB200M2において、SeNB200S1の変更が必要(又は維持が不要)と判断された場合には、SeNB200S1を維持する処理(当該SeNBに対するランダム接続処理等)の実行を省くことができる。
【0110】
なお、第2のハンドオーバ手順が完了した後に、T−eNB200M2がUE100と接続するSeNB200S(例えば、SeNB200S2)を新たに設定する場合には、既存のSeNB追加手順(SeNBAddition)(3GPP TS36.300 v12.5.0)等を用いてもよい。
【0111】
次に、第3のハンドオーバ手順について、図11を用いて説明する。
【0112】
第3のハンドオーバ手順は、UE100とSeNB200S1(S−SeNB200S1)との接続を維持せずに解放すると共にT−SeNB200S2との接続を確立し、S−MeNB200M1からT−MeNB200M2へのUE100のハンドオーバを実行する手順である。
【0113】
UE100は、ステップS301を実行する。なお、ステップS301は、第1のハンドオーバ手順におけるステップS101及び第2のハンドオーバ手順におけるステップS201と同じ動作である。
【0114】
ステップS302において、S−MeNB200M1は、ハンドオーバ要求(Handover Request)をT−MeNB200M2へ送信する。一例として、S−MeNB200M1は、T−MeNB200M2へ送信するハンドオーバ要求に、ステップS301においてUE100から受信した測定結果を含めてもよく、特に、UE100から受信した複数のeNB200が管理するセルからの参照信号の測定結果のうち、一部のeNB200が管理するセルからの参照信号の測定結果のみを含めてもよい。一部のeNB200は、例えば、S−MeNB200M1とのX2接続が確立されているeNB200であってもよく、その場合、S−MeNB200M1は、ハンドオーバ要求に、X2接続が確立されているeNB200及びS−SeNB200S1の識別子(ID)を含めてもよい。
【0115】
T−MeNB200M2は、ステップS303及びS304を実行する。なお、ステップS303及びS304は、第2のハンドオーバ手順におけるステップS203及びS204と同じ動作である。なお、ステップS303は省略してもよく、T−MeNB200M2は、ステップS302においてハンドオーバ要求を受信すると、ステップS304においてT−SeNB200S2を選択してもよい。
【0116】
ステップS304において、T−MeNB200M2は、新たにUE100が接続するT−SeNB200S2を選択する(ステップS304 YES)。一例として、T−eNB200M2は、S−MeNB200M1から受信したUE100における測定結果に含まれる複数のeNB200のうち、所定の条件を満たすeNB200のうち最も条件の良いeNB200をT−SeNB200Sとして選択してもよい。所定の条件を満たすeNB200は、信号の品質(SINR及びRSRP等)が一定値以上、過去にT−eNB200M2がSeNBとして設定したことがある、無線リンク失敗が一定値未満及び/又はOAMによって予めSeNBとして設定されているeNBであってもよい。最も条件の良いeNB200は、複数の条件(信号の品質(SINR及びRSRP等)が一定値以上、過去にT−eNB200M2がSeNBとして設定したことがある、無線リンク失敗が一定値未満及びOAMによって予めSeNBとして設定されている)を最も多く満たすeNB200であってもよい。
【0117】
ステップS305において、T−MeNB200M2は、ステップS304において選択したT−SeNB200S2に対して、SeNB追加要求(SeNB Addition Request)を送信する。なお、SeNB追加要求には、ステップS302においてS−MeNB200M1から受信したS−SeNB200S1の識別子(ID)を含んでもよい。
【0118】
ステップS306において、T−SeNB200S2は、SeNB要求応答(SeNB Addition Request Acknowledg)を送信する。なお、T−SeNB200S2は、SeNB追加要求に含まれるS−SeNB200S1の識別子から、自局とS−SeNB200S1とのX2接続が確立されているか否かを判断する。ここで、T−SeNB200S2は、自局とS−SeNB200S1とのX2接続が確立されており、ダイレクトデータフォワーディングが可能であれば、自局のX2 TEID(Tunnel endpoint identifier)を含めて、SeNB要求応答(SeNB Addition Request Acknowledgement)をT−MeNB200M2へ送信する。なお、X2 TEIDは、X2−U ユーザプレーン用のデータを流すために用いられてもよい。ダイレクトデータフォワーディングは、一例として、S−SeNB200S1からT−SeNB200S2への直接的なUE100向けのデータの転送を意味する。一方で、T−SeNB200S2は、自局とS−SeNB200S1とのX2接続が確立されておらず、ダイレクトデータフォワーディングが不可能であれば、自局のX2 TEIDを含めずに、SeNB要求応答をT−MeNB200M2へ送信する。
【0119】
ステップS307において、T−MeNB200M2は、S−MeNB200M1に対してハンドオーバ要求応答(Handover Request Acknowledgement)を送信する。なお、ハンドオーバ要求応答は、SeNB200S1の変更の必要性に関する情報を含んでもよい。また、ハンドオーバ要求応答は、UE100のRRC接続再設定(RRC Connection Reconfiguration)用のT−SeNB200S2の設定情報(RRC Configuration information)を含んでもよい。このT−SeNB200S2の設定情報は、ステップS306において、T−SeNB200S2から送信されてもよい。また、T−MeNB200M2は、ステップS306においてT−SeNB200S2のX2 TEIDを受信した場合には、ハンドオーバ要求応答に、T−SeNB200S2のX2 TEIDを含めて送信してもよい。また、ハンドオーバ要求応答には、ステップS106において送信された情報と同様の情報を含んでもよい。
【0120】
ステップS308において、S−MeNB200M1は、ハンドオーバ要求応答に含まれるSeNB200S1の変更の必要性に関する情報、UE100のRRC再設定(RRC reconfiguration)用のT−SeNB200S2の設定情報(RRC Configuration information)及び/又はT−SeNB200S2のX2 TEIDに基づいて、以降の手順(ハンドオーバ手順)を決定する。一例として、S−MeNB200M1は、UE100のRRC再設定(RRC reconfiguration)用のT−SeNB200S2の設定情報(RRC Configuration information)及び/又はT−SeNB200S2のX2 TEIDが含まれる場合には、以降の手順を、S−T−SeNB200S2との接続を行う手順に決定してもよい。
【0121】
ステップS309において、S−MeNB200M1は、S−SeNB200S1に対して、SeNB解放要求(SeNB Release Request)を送信する。なお、S−MeNB200M1は、ステップS307においてT−SeNB200S2のX2 TEIDを受信した場合には、SeNB解放要求に、T−SeNB200S2のX2 TEIDを含めて送信してもよい。
【0122】
ステップS310において、S−MeNB200M1は、UE100に対して、T−SeNB200M2から受信したハンドオーバ要求応答に含まれるT−SeNB200S2の設定情報を含めて、RRC Connection Reconfigurationを送信する。
【0123】
UE100は、T−MeNB200M2に対してステップS311〜S312を実行する。なお、ステップS311〜S312は、第1のハンドオーバ手順におけるステップS110〜S111に対応する。
【0124】
ステップS313において、UE100は、T−SeNB200S2に対してランダム接続処理(Random Access Procedure)を実行する。なお、UE100は、ステップS309において受信したT−SeNB200S2の設定情報を用いてランダム接続処理(Random Access Procedure)を実行してもよい。なお、UE100は、ステップS311の途中からステップS313の処理を開始してもよい。
【0125】
ステップS314において、T−MeNB200M2は、T−SeNB200S2に対してSeNB再設定完了(SeNB Reconfiguration Complete)を通知する。
【0126】
ステップS315において、S−MeNB200M1は、T−MeNB200M2に対して、ハンドオーバに際して発生するデータフォワーディングのためにSN Status Transferメッセージを通知する。
【0127】
S−SeNB200S1は、ステップS309においてS−MeNB200M1から受信したソースeNB解放要求にT−SeNB200S2のX2 TEIDが含まれない場合には、ステップ316aにおいて、T−SeNB200S2に対して、S−MeNB200M1を介して、インダイレクトフォワーディング(インダイレクトデータフォワーディング)のためにSN Status Transferメッセージを送信する。その後に、S−SeNB200S1は、UE100向けのデータをS−MeNB200M1を介してT−SeNB200S2へ間接的に転送するインダイレクトフォワーディングを実行する。
【0128】
一方で、S−SeNB200S1は、ステップS309において受信したソースeNB解放要求にT−SeNB200S2のX2 TEIDが含まれる場合には、ステップ316bにおいて、T−SeNB200S2に対して、ダイレクトフォワーディング(ダイレクトデータフォワーディング)のために、SN Status Transferメッセージを送信する。その後に、S−SeNB200S1は、UE100向けのデータを直接的にT−SeNB200S2へ転送するダイレクトフォワーディングを実行する。
【0129】
つまり、S−SeNB200S1は、ステップS316a及びステップS316bのいずれか一方を実行する。
【0130】
また、ステップS317〜ステップS321は、第1のハンドオーバ手順におけるステップS116〜S121が対応し、ステップS118bにおけるS−GW300UとSeNB200S1との間の新たなパスの設定に代えて、S−GW300UとT−SeNB200S2との新たなパスの設定が実行される。
【0131】
第3のハンドオーバ手順によって、T−MeNB200M2におけるS−SeNB200S1の変更の必要性に応じて、適切なハンドオーバ手順を実行することができる。つまり、T−MeNB200M2において、S−SeNB200S1の変更が必要と判断された場合には、S−MeNB200M1からT−MeNB200M2へハンドオーバすると共に、S−SeNB200S1からT−SeNB200S2へ変更することができ、MeNB200Mのハンドオーバ後にSeNB200Sを変更する必要が無くなり、効率的にSeNB200Sの変更をすることができる。
【0132】
次に、第4のハンドオーバ手順を、図12を用いて以下に説明する。
【0133】
第4のハンドオーバ手順は、UE100と接続するSeNB200S1を変更せずに(SeNB200S1との接続を維持したままで)S−MeNB200M1からT−MeNB200M2へのUE100のハンドオーバを実行する手順であって、S−MeNB200M1で確立(又は設定)しているMCGベアラをSeNB200S1が用いる(又は管理する)SCGベアラに変更する手順を含むものである。
【0134】
UE100は、ステップS401を実行する。なお、ステップS401は、第1のハンドオーバ手順におけるステップS101と同じ動作である。
【0135】
ステップS402において、S−MeNB200M1は、T−MeNB200M2へハンドオーバ要求を送信する。一例として、ハンドオーバ要求は、ベアラタイプの変更を要求する旨(例えば、MCGベアラからSCGベアラへの変更を要求する旨)を含んでもよい。また、一例として、ハンドオーバ要求は、S−MeNB200M1が管理するMCGベアラの情報(例えば、ベアラID)及び/又はSCGベアラの情報を含んでもよい。または、ハンドオーバ要求は、UE合計最大ビットレート(UE Aggregate Maximum Bitrate)及び/又はSeNB200S1におけるUE合計最大ビットレート(SeNB UE Aggregate Maximum Bitrate)を含んでもよい。なお、ベアラIDは、E−RAB(E−UTRAN Access Bearer) IDであってもよい。また、ハンドオーバ要求には、ベアラの種類に関する情報(MCGベアラ、SCGベアラ又はスプリットベアラ)を含めてもよい。また、ハンドオーバ要求に含まれるベアラの種類に関する情報は、同じくハンドオーバ要求に含まれるS−MeNB200M1が管理するベアラのベアラIDに対応付けられてもよい。これによって、ハンドオーバ要求を受信したT−MeNB200M2は、S−MeNB200M1が管理するベアラIDに対応するベアラの種類(MCGベアラ、SCGベアラ又はスプリットベアラなのか)を特定することが可能となる。
【0136】
ステップS403において、T−MeNB200M2は、ベアラタイプを変更するか否かを判断する。つまり、T−MeNB200M2は、S−MeNB200M1で確立しているMCGベアラをSeNB200S1のSCGベアラに変更するか否かを判断する。一例として、T−MeNB200M2は、ハンドオーバ要求にベアラタイプの変更を要求する旨が含まれている場合に、ベアラタイプを変更すると判断してもよい。または、一例として、T−MeNB200M2は、自局のRRM(無線リソース管理)に基づいてベアラタイプを変更すると判断してもよい。具体的には、T−MeNB200M2は、SeNB200S1のリソース状況及びロード状況、UE100におけるT−MeNB200M2及び/若しくはSeNB200S1からの信号の測定結果、UE合計最大ビットレート(UE Aggregate Maximum Bit Rate)並びに/又はSeNB200S1におけるUE合計最大ビットレート(SeNB UE Aggregate Maximum Bit Rate)等に基づいて、S−MeNB200M1におけるUE100向けのデータをSeNB200S1から送信すべきと判断することにより、ベアラタイプを変更すると判断してもよい。
【0137】
T−MeNB200M2は、ステップS403において、ベアラタイプを変更すると判断すると(S403 YES)、変更するMCGベアラの識別子(ベアラ ID)を記憶する。一例として、T−MeNB200M2は、変更する対象のMCGベアラの情報をInter-node RRC information elementの1つであるHandover Preparation Informationにより取得してもよい。
【0138】
ステップS404において、T−MeNB200M2は、SeNB追加要求に、SeNB200S1に対して確立(又は設定)を要求するSCGベアラの情報を含めて送信する。一例として、T−MeNB200M2は、SeNB追加要求内のE−RAB To Be Added Item IE内のSCG Bearer IEに上記SCGベアラの情報を含める。ここで、SCGベアラの情報とは、E−RAB ID、E−RAB Level QoS Parameters、DL Forwarding及びS1 UL GTP Tunnel Endpoint等である。また、SeNB200S1は、受信したSeNB追加要求に、既に確立しているSCGベアラのベアラIDとは異なるベアラIDが含まれている場合には、当該異なるベアラIDに対応するSCGベアラの追加(当該ベアラIDに対応するMCGベアラからSCGベアラへの変更)が要求されていると判断してもよい。
【0139】
ステップS405において、SeNB200S1は、S−MeNB200M1からSeNB200S1へのデータフォワーディングのための自局のX2 TEIDを含めてSeNB追加要求応答(SeNB Addition Request Acknowledgement)をT−MeNB200M2へ送信する。
【0140】
ステップS406において、T−MeNB200M2は、ハンドオーバ要求応答(Handover Request Acknowledgement)に、SeNB200S1から受信したSeNB200S1のX2 TEID及びステップS403において記憶した、ベアラタイプをMCGベアラからSCGベアラへ変更するS−MeNB200M1が管理するMCGベアラの識別子(ベアラID)を含めて送信する。
【0141】
ステップS407〜S414を実行する。ステップS407〜S414は、第1のハンドオーバ手順におけるステップS108〜S115に対応する。
【0142】
ステップS415において、S−MeNB200M1は、SeNB200S1のX2 TEIDに対して、ステップS406において受信したMCGベアラの識別子で示されるMCGベアラにバッファ(記憶)又はMCGベアラに対応した記憶領域にバッファしているUE100向けのデータを、SeNB200S1へダイレクト(データ)フォワーディング(直接的に転送)する。なお、ダイレクト(データ)フォワーディングは、UE100向けのアップリンクデータ又はダウンリンクデータをS−MeNB200M1からSeNB200S1へ直接的に(他のeNB200を介さずに)転送することである。
【0143】
ステップS416〜S421を実行する。ステップS416〜S421は、第1のハンドオーバ手順におけるステップS116〜121に対応する。
【0144】
なお、S−MeNB200M1は、ステップS413の後であってステップS415の前に、ステップS415のダイレクトフォワーディングに用いるベアラ(ベアラタイプをMCGベアラからSCGベアラに変更するベアラ)に関するSN Status TransferメッセージをSeNB200S1へ通知してもよい(ステップS414a)。
【0145】
また、S−MeNB200M1は、SeNB200S1への上記SN Status Transferメッセージの通知に代えて、ステップS413においてT−MeNB200M2へ送信するSN Status Transferメッセージとして、(ベアラタイプを変更しない)MCGベアラのSN Status TransferとベアラタイプをMCGベアラからSCGベアラへ変更するベアラのSN Status Transferを送信してもよい。その後に、T−MeNB200M2は、S−MeNB200M1から受信したSN Status Transferのうち、ベアラのタイプをMCGベアラからSCGベアラへ変更するベアラのSN Status TransferのみをSeNB200S1へ転送してもよい(ステップS414b)。この際に、T−MeNB200M2は、ステップS403におけるベアラタイプの変更に基づいて、S−MeNB200M1から受信したSN Status Transferのうち、ベアラのタイプをMCGベアラからSCGベアラへ変更するベアラのSN Status Transferのみを抽出できることとしてもよい。
【0146】
また、T−MeNB200M2は、S−MeNB200M1からSeNB200S1へのダイレクトフォワーディングを指示する場合に、ステップS406において送信するハンドオーバ要求応答にダイレクトフォワーディングの指示(Direct Data Forwarding Indicator)を含めてもよい。これによって、S−MeNB200M1は、S―MeNB200M1からSeNB200S1へのダイレクトフォワーディングが要求されているのか否かを判断することができる。なお、ダイレクトフォワーディングの指示は、ハンドオーバ要求応答に含まれているベアラID及び/又はSeNB200S1のX2 TEIDに対応付けられてもよい。これによって、S−MeNB200M1は、ハンドオーバ要求応答に複数のベアラID及び又はX2 TEIDが含まれている場合に、どのベアラID及び/又はX2 TEIDがダイレクトフォワーディング用のベアラID及び/又はX2 TEIDであるかを判別することができる。
【0147】
第4のハンドオーバ手順によって、S−MeNB200M1からT−MeNB200M2へのハンドオーバの際に、ベアラタイプを変更し、S−MeNB200M1からSeNB200S1へのダイレクトフォワーディングが可能となる。
【0148】
次に、第5のハンドオーバ手順を、図13を用いて以下に説明する。
【0149】
第5のハンドオーバ手順は、UE100と接続するSeNB200S1を変更せずに(SeNB200S1との接続を維持したままで)S−MeNB200M1からT−MeNB200M2へUE100のハンドオーバを実行する手順であって、SeNB200S1で確立(設定)しているSCGベアラをT−MeNB200M2が用いる(又は管理する)MCGベアラに変更する手順を含むものである。
【0150】
UE100は、ステップS501を実行する。ステップS501は、第1のハンドオーバ手順におけるステップS101と同じ動作である。
【0151】
ステップS502において、S−MeNB200M1は、T−MeNB200M2へハンドオーバ要求を送信する。ハンドオーバ要求は、SeNB200S1で確立(設定)されているSCGベアラの識別子を含む。また、ハンドオーバ要求は、S−MeNB200M1で確立(設定)しているMCGベアラの識別子を含んでもよい。また、一例として、ハンドオーバ要求は、ベアラタイプの変更を要求する旨(例えば、SCGベアラからMCGベアラへの変更を要求する旨)を含んでもよい。
【0152】
ステップS503において、T−MeNB200M2は、ベアラタイプを変更するか否かを判断する。つまり、T−MeNB200M2は、SeNB200S1で確立(設定)されているSCGベアラをT−MeNB200M2で用いるMCGベアラに変更するか否かを判断する。
【0153】
T−MeNB200M2は、ステップS503において、RRM又はハンドオーバ要求にベアラタイプの変更を要求する旨の有無に基づいて、ベアラタイプを変更すると判断すると(S503 YES)、変更するSCGベアラの識別子及びT−MeNB200M2で新たに設定するMCGベアラの識別子を記憶する。
【0154】
ステップS504において、T−MeNB200M2は、SeNB追加要求(SeNB Addition Request)を送信する。ここで、T−MeNB200M2は、SeNB追加要求内のE−RAB To Be Added Item IEのSCG bearer IEにSeNB2001で設定されているSCGベアラの設定を含めてもよい。また、T−MeNB200M2は、SeNB追加要求に、自局のX2 TEIDを含めてもよい。この自局のX2 TEIDは、SeNB200S1からT−MeNB200M2へのダイレクトフォワーディングのためのものである。なお、ダイレクトデータフォワーディングは、UE100向けのアップリンクデータ又はダウンリンクデータをSeNB200S1からT−MeNB200M2へ直接的に(他のeNB200を介さずに)転送することである。
【0155】
SeNB200S1は、SeNB追加要求を受信すると、自局が確立しているSCGベアラをT−MeNB200M2で用いるためのMCGベアラに変更することを要求していると判断する。一例として、SeNB200S1は、SeNB追加要求に、自局が確立しているSCGベアラの設定若しくはT−MeNB200M2のX2 TEIDが含まれていることにより、ベアラの変更を要求していると判断してもよい。また、SeNB200S1は、受信したSeNB追加要求に、既に確立しているSCGベアラのID(又は既に確立している複数のSCGベアラのIDのうちの一部のSCGベアラのID)が含まれていない場合には、当該ベアラのIDに対応するSCGベアラの削除(又は当該ベアラのIDに対応するSCGベアラからMCGベアラへの変更)が要求されていると判断してもよい。
【0156】
ステップS505において、SeNB200S1は、SeNB追加要求応答(SeNB Addition Request Acknowledgement)を、T−MeNB200M2へ送信する。
【0157】
ステップS506において、T−MeNB200M2は、ハンドオーバ要求応答(Handover Request Acknowledgement)をS−MeNB200M1へ送信する。
【0158】
ステップS507〜S514を実行する。ステップS507〜S514は、第1のハンドオーバ手順におけるステップS108〜S115に対応する。
【0159】
ステップS515において、SeNB200S1は、ステップS504において受信したT−MeNB200M2のX2 TEIDに対して、自局で確立していたSCGベアラにバッファ(記憶)又はSCGベアラに対応した記憶領域にバッファしているUE100向けのデータ(アップリンクデータ若しくはダウンリンクデータ)をT−MeNB200M2へダイレクトフォワーディング(直接的に送信)する。なお、SCGベアラは、SeNB追加要求に、その設定に関する情報が含まれるものであってもよい。
【0160】
なお、T−MeNB200M2は、ステップS504においてSeNB200M1へ送信するSeNB追加要求に自局のX2 TEIDを含めることに代えて、ステップS506において送信するハンドオーバ要求応答に、自局のX2 TEIDを含めてもよい。自局のX2 TEIDは、ステップS515におけるダイレクトフォワーディング(SeNB200S1→T−MeNB200M2)に用いるX2 TEIDとMCGベアラ用のX2 TEIDを含む。また、ステップS507において、S−MeNB200M1は、ハンドオーバ要求応答に含まれているT−MeNB200M2のX2 TEIDのうちのダイレクトフォワーディングに用いるX2 TEIDのみを、SeNB解放要求に含めてSeNB200S1へ送信してもよい。その後、ステップS513において、S−MeNB200M1は、MCGベアラ(ハンドオーバ要求応答に含まれているMCGベアラ用のTEIDに対応するMCGベアラ)のみに関連するSN Status TransferメッセージをT−MeNB200M2へ送信してもよい。その後、SeNB200S1は、ベアラタイプを変更するベアラ(ダイレクトフォワーディングに用いるTEIDに対応するベアラ)のみに関連するSN Status TransferメッセージをT−MeNB200M2へ送信してもよい(S514a)。なお、ステップS513の前に、SeNB200S1は、ベアラタイプをSCGベアラからMCGベアラに変更するベアラに関する情報をS−MeNB200M1へ送信してもよい。この場合、S−MeNB200M1は、ステップS513において、SeNB200から受信した変更するベアラに関する情報をT−MeNB200M2へ送信するSN Status Transferメッセージに含めてもよい。
【0161】
また、T−MeNB200M2は、S−MeNB200M1へSeNB200S1からT−MeNB200M2へのダイレクトフォワーディングを指示する場合に、ステップS506において送信するハンドオーバ要求応答にダイレクトフォワーディングの指示(Direct Data Forwarding Indicator)を含めてもよい。これによって、S−MeNB200M1は、ダイレクトフォワーディング(SeNB200S1→T−MeNB200M2)が要求されているのか否かを判断することができる。なお、ダイレクトフォワーディングの指示は、ハンドオーバ要求応答に含まれているベアラ(複数のベアラのうちのいずれかのベアラ)のベアラID及び/又はX2 TEIDに対応付けられてもよい。これによって、S−MeNB200M1は、ハンドオーバ要求応答に含まれている複数のベアラID及び/又はX2 TEIDのうちのどのベアラID及び/又はX2 TEIDがダイレクトフォワーディング用のベアラID及び/又はX2 TEIDであるかを判別することができる。
【0162】
さらに、S−MeNB200M1は、受信したハンドオーバ要求応答にダイレクトフォワーディングの指示が含まれている場合には、ステップS507においてSeNB200S1へ送信するSeNB解放要求にダイレクトフォワーディングの指示を含めてもよい。これによって、SeNB200S1は、ダイレクトフォワーディング(SeNB200S1→T−MeNB200M2)が要求されているのか否かを判断することができる。これによって、SeNB200S1は、ダイレクトフォワーディングが要求されている場合には、SN Status TransferメッセージをT−MeNB200M2へ送信すればよいと判断できる。また、ダイレクトフォワーディングの指示は、SeNB解放要求に含まれているベアラID及び/又はX2 TEIDに対応付けられてもよい。これによって、SeNB200S1は、ダイレクトフォワーディングの指示に対応付けられているベアラID及び/又はX2 TEIDに対して、ダイレクトフォワーディングすることが要求されていると判断することができる。
【0163】
第5のハンドオーバ手順によって、S−MeNB200M1からT−MeNB200M2へのハンドオーバの際に、ベアラタイプを変更し、SeNB200S1からT−MeNB200M2へのダイレクトフォワーディングが可能となる。
【0164】
次に、第6のハンドオーバ手順を、図14を用いて以下に説明する。
【0165】
第6のハンドオーバ手順は、UE100と接続するSeNB200S1を変更せずに(SeNB200S1との接続を維持したままで)S−MeNB200M1からT−MeNB200M2へUE100のハンドオーバを実行する手順であって、SeNB200S1経由のスプリットベアラをT−MeNB200M2が用いるMCGベアラに変更する手順を含むものである。
【0166】
UE100は、ステップS601を実行する。なお、ステップS601は、第1のハンドオーバ手順におけるステップS101と同じ動作である。
【0167】
ステップS602において、S−MeNB200M1は、T−MeNB200M2へハンドオーバ要求を送信する。一例として、ハンドオーバ要求には、ベアラタイプの変更を要求する旨(例えば、スプリットベアラからMCGベアラへの変更を要求する旨)を含めてもよい。また、一例として、ハンドオーバ要求には、S−MeNB200M1が管理するスプリットベアラの情報を含んでもよい。
【0168】
ステップS603において、T−MeNB200M2は、ベアラタイプを変更するか否かを判断する。つまり、T−MeNB200M2は、SeNB200S1経由のスプリットベアラをT−MeNB200M2が用いるMCGベアラに変更するか否かを判断する。一例として、T−MeNB200M2は、ハンドオーバ要求にベアラタイプの変更を要求する旨が含まれている場合に、ベアラタイプを変更すると判断する。
【0169】
T−MeNB200M2は、SeNB200S1経由のスプリットベアラをMCGベアラに変更すると判断した場合(ステップS603 YES)、当該スプリットベアラのベアラ識別子(Bearer ID)を記憶する。
【0170】
ステップS604において、T−MeNB200M2は、ステップS604において、SeNB追加要求(SeNB Addition Request)をSeNB200S1へ送信する。ここで、T−MeNB200M2は、SeNB追加要求内のE−RAB To Be Added Item IEのSplit bearer IEに、SeNB200S1経由のスプリットベアラの設定を含めてもよい。
【0171】
SeNB200S1は、T−MeNB200M2からSeNB追加要求を受信すると、SeNB200S1経由のスプリットベアラをT−MeNB200M2で用いるためのMCGベアラに変更することを要求していると判断する。具体的には、SeNB200S1は、SeNB追加要求に、現在設定されているSeNB200S1経由のスプリットベアラの設定が含まれていることにより、ベアラタイプの変更を要求していると判断してもよい。
【0172】
ステップS605において、SeNB200S1は、SeNB追加要求応答(SeNB Addition Request Acknowledgement)をT−MeNB200M2へ送信する。
【0173】
ステップS607〜S614を実行する。ステップS607〜S614は、第1のハンドオーバ手順におけるステップS108〜S115に対応する。
【0174】
ステップS615において、T−MeNB200M2がベアラタイプの変更を要求していると判断したSeNB200S1は、スプリットベアラにバッファ(記憶)しているUE100向けのデータ(アップリンクデータ若しくはダウンリンクデータ)をS−MeNB200M1を介してT−MeNB200M2へインダイレクトフォワーディング(転送)する。なお、このスプリットベアラは、SeNB追加要求に設定が含まれているスプリットベアラであってもよい。
【0175】
ステップS616〜S621を実行する。ステップS616〜S621は、第1のハンドオーバ手順におけるステップS116〜121に対応する。
【0176】
第6のハンドオーバ手順によって、S−MeNB200M1からT−MeNB200M2へのハンドオーバの際にベアラタイプを変更し、SeNB200S1からT−MeNB200M2へのインダイレクトフォワーディングが可能となる。
【0177】
なお、ステップS404、S504及びS604において、T−MeNB200M2は、SeNB追加要求の送信に代えて、SeNB修正要求(SeNB Modification Request)をSeNB200S1へ送信してもよい。その場合には、ステップS405、S505及びS605において、SeNB200S1は、SeNB追加要求応答の送信に代えて、SeNB修正要求応答(SeNB Modification Request Acknowledgment)をT−MeNB200M2へ送信する。その場合には、S−MeNB200M1は、ステップS407、S507及びS607及び/又はステップS421、S521及びS621を省略してもよい。
【0178】
なお、第4〜6のハンドオーバ手順におけるステップS402、502及び602において、S−MeNB200M1から送信されるハンドオーバ要求には、MCGベアラの情報及び/又はSCGベアラの情報を含んでもよい。ここで、MCGベアラの情報及びSCGベアラの情報は、所定のベアラIDがMCGベアラ若しくはSCGベアラであるということを示す情報を含んでもよい。このMCGベアラ若しくはSCGベアラであるということを示す情報は、T−MeNB200M2が、変更の対象となるベアラ(MCGベアラ及び/又はSCGベアラ)を選択する時に用いられてもよい。
【0179】
なお、第4〜6のハンドオーバ手順は、例えば、Inter MeNB Handover without SeNB Changeを改良したものであってもよい。
【0180】
なお、第1〜6のハンドオーバ手順は、上述したものに限られず、例えば、上述のステップのうち一部のステップを除くものであってもよい。
【0181】
なお、第1〜6のハンドオーバ手順は、それぞれ異なる手順として説明したが、例えば、一のハンドオーバ手順における一部のステップを他のハンドオーバ手順において用いてもよい。
【0182】
上述した第1実施形態において、移動通信システムとしてLTEシステムを例示した。しかしながら、本発明はLTEシステムに限定されない。LTEシステム以外のシステムに本発明を適用してもよい。
【0183】
[第2実施形態乃至第6実施形態の概要]
第2実施形態に係るターゲット基地局は、二重接続方式をサポートする移動通信システムにおいて、ソース基地局からターゲット基地局に対してユーザ端末のハンドオーバを行う場合における前記ターゲット基地局である。前記ターゲット基地局は、前記ユーザ端末のベアラのデータを前記ソース基地局から前記セカンダリ基地局に直接的に転送するダイレクトフォワーディングに用いる第1のトンネリング識別子と、前記ターゲット基地局を介して前記データを前記セカンダリ基地局に間接的に転送するインダイレクトフォワーディングに用いる第2のトンネリング識別子と、前記ベアラを識別するベアラ識別子と、を含むメッセージを前記ソース基地局に送信する制御部を備える。前記メッセージにおいて、前記第1のトンネリング識別子及び前記第2のトンネリング識別子は、同一の前記ベアラ識別子に対応付けられている。
【0184】
第2実施形態に係るターゲット基地局において、前記メッセージは、前記ソース基地局から送信されたハンドオーバ要求に対するハンドオーバ要求応答であってもよい。
【0185】
第2実施形態に係るターゲット基地局において、前記制御部は、前記ベアラのタイプを、前記ソース基地局を介して前記ベアラを確立する第1のタイプから、前記セカンダリ基地局を介して前記ベアラを確立する第2のタイプに変更すると決定してもよい。
【0186】
第2実施形態に係るソース基地局は、二重接続方式によりソース基地局及びセカンダリ基地局に接続するユーザ端末の基地局間ハンドオーバを行う場合における前記ソース基地局である。前記ソース基地局は、前記ユーザ端末のベアラのデータを前記ソース基地局から前記セカンダリ基地局に直接的に転送するダイレクトフォワーディングに用いる第1のトンネリング識別子と、ターゲット基地局を介して前記データを前記セカンダリ基地局に間接的に転送するインダイレクトフォワーディングに用いる第2のトンネリング識別子と、前記ベアラを識別するベアラ識別子と、を含むメッセージを前記ターゲット基地局から受信する制御部を備える。前記メッセージにおいて、前記第1のトンネリング識別子及び前記第2のトンネリング識別子は、同一の前記ベアラ識別子に対応付けられている。
【0187】
第2実施形態に係るソース基地局において、前記制御部は、前記ダイレクトフォワーディング及び前記インダイレクトフォワーディングのうちの一のフォワーディング方式を決定し、前記決定したフォワーディング方式に応じて、前記第1のトンネリング識別子及び前記第2のトンネリング識別子の何れかを用いて前記ベアラに対するフォワーディング制御を行ってもよい。
【0188】
第3実施形態に係るターゲット基地局は、二重接続方式をサポートする移動通信システムにおいて、ソース基地局からターゲット基地局に対してユーザ端末のハンドオーバを行う場合における前記ターゲット基地局である。前記ターゲット基地局は、前記ユーザ端末のベアラのデータを前記ソース基地局から前記セカンダリ基地局に直接的に転送するダイレクトフォワーディング、及び前記ターゲット基地局を介して前記データを前記セカンダリ基地局に間接的に転送するインダイレクトフォワーディングのうちの一のフォワーディング方式を前記ソース基地局が決定可能であることを示す情報要素を前記ソース基地局に送信する制御部を備える。
【0189】
第3実施形態に係るターゲット基地局において、前記制御部は、前記ダイレクトフォワーディングに用いる第1のトンネリング識別子と、前記ベアラを識別する第1のベアラ識別子と、前記インダイレクトフォワーディングに用いる第2のトンネリング識別子と、前記ベアラを識別する第2のベアラ識別子と、前記情報要素と、を含むメッセージを前記ソース基地局に送信し、前記メッセージにおいて、前記第1のトンネリング識別子が前記第1のベアラ識別子に対応付けられ、かつ、前記第2のトンネリング識別子が前記第2のベアラ識別子に対応付けられていてもよい。
【0190】
第3実施形態に係るターゲット基地局において、前記メッセージは、前記ソース基地局から送信されたハンドオーバ要求に対するハンドオーバ要求応答であってもよい。
【0191】
第3実施形態に係るターゲット基地局において、前記制御部は、前記ベアラのタイプを、前記ソース基地局を介して前記ベアラを確立する第1のタイプから、前記セカンダリ基地局を介して前記ベアラを確立する第2のタイプに変更すると決定してもよい。
【0192】
第3実施形態に係るソース基地局は、二重接続方式をサポートする移動通信システムにおいて、ソース基地局からターゲット基地局に対してユーザ端末のハンドオーバを行う場合における前記ソース基地局である。前記ソース基地局は、前記ユーザ端末のベアラのデータを前記ソース基地局からセカンダリ基地局に直接的に転送するダイレクトフォワーディング、及び前記ターゲット基地局を介して前記データを前記セカンダリ基地局に間接的に転送するインダイレクトフォワーディングのうちの一のフォワーディング方式を前記ソース基地局が決定可能であることを示す情報要素を前記ターゲット基地局から受信する制御部を備える。前記制御部は、前記情報要素の受信に応じて、前記ダイレクトフォワーディング及び前記インダイレクトフォワーディングのうちの一のフォワーディング方式を決定する。
【0193】
第3実施形態に係るソース基地局において、前記制御部は、前記ダイレクトフォワーディングに用いる第1のトンネリング識別子と、前記ベアラを識別する第1のベアラ識別子と、前記インダイレクトフォワーディングに用いる第2のトンネリング識別子と、前記ベアラを識別する第2のベアラ識別子と、前記情報要素と、を含むメッセージを前記ターゲット基地局から受信し、前記決定したフォワーディング方式に応じて、前記第1のトンネリング識別子及び前記第2のトンネリング識別子の何れかを用いて前記ベアラに対するフォワーディング制御を行ってもよい。
【0194】
第4実施形態に係るソース基地局は、二重接続方式をサポートする移動通信システムにおいて、ソース基地局からターゲット基地局に対してユーザ端末のハンドオーバを行う場合における前記ソース基地局である。前記ソース基地局は、前記ユーザ端末のベアラのデータを前記ソース基地局からセカンダリ基地局に直接的に転送するダイレクトフォワーディングが可能であることを示す通知情報を前記ターゲット基地局に送信する制御部を備える。
【0195】
第4実施形態に係るソース基地局において、前記制御部は、前記ソース基地局から前記ターゲット基地局に送信するハンドオーバ要求に前記通知情報を含めてもよい。
【0196】
第4実施形態に係るソース基地局において、前記通知情報は、前記ソース基地局が前記ダイレクトフォワーディングを提案することを示す情報、又は、前記ソース基地局と前記セカンダリ基地局との間のX2インターフェイスが利用可能であることを示す情報であってもよい。
【0197】
第4実施形態に係るターゲット基地局は、二重接続方式をサポートする移動通信システムにおいて、ソース基地局からターゲット基地局に対してユーザ端末のハンドオーバを行う場合における前記ターゲット基地局である。前記ターゲット基地局は、前記ユーザ端末のベアラのデータを前記ソース基地局から前記セカンダリ基地局に直接的に転送するダイレクトフォワーディングが可能であることを示す通知情報を前記ソース基地局から受信する制御部を備える。前記制御部は、前記通知情報の受信に応じて、前記ダイレクトフォワーディング、及び、前記ターゲット基地局を介して前記データを前記セカンダリ基地局に間接的に転送するインダイレクトフォワーディングのうちの一のフォワーディング方式を決定する。
【0198】
第5実施形態に係るターゲット基地局は、二重接続方式をサポートする移動通信システムにおいて、ソース基地局からターゲット基地局に対してユーザ端末のハンドオーバを行う場合における前記ターゲット基地局である。前記ターゲット基地局は、前記ユーザ端末のベアラのデータを前記ソース基地局から前記ターゲット基地局を介してセカンダリ基地局に間接的に転送するインダイレクトフォワーディングに用いるトンネリング識別子を設定した後、前記トンネリング識別子を含むメッセージを前記ソース基地局に送信する制御部を備える。前記制御部は、前記メッセージを前記ソース基地局に送信した際に、前記インダイレクトフォワーディングが開始されるまでの最大待ち時間を規定するタイマを開始させる。
【0199】
第5実施形態に係るターゲット基地局において、前記制御部は、前記タイマの時間内で前記インダイレクトフォワーディングが開始された場合、前記タイマを停止させ、前記タイマが満了した場合、前記トンネリング識別子を解放してもよい。
【0200】
第5実施形態に係るターゲット基地局において、前記メッセージは、前記ソース基地局から送信されたハンドオーバ要求に対するハンドオーバ要求応答であってもよい。
【0201】
第6実施形態に係るソース基地局は、二重接続方式をサポートする移動通信システムにおいて、ソース基地局からターゲット基地局に対してユーザ端末のハンドオーバを行う場合における前記ソース基地局である。前記ソース基地局は、前記ユーザ端末のベアラのデータを前記ソース基地局からセカンダリ基地局に直接的に転送するダイレクトフォワーディング、及び前記ターゲット基地局を介して前記データを前記セカンダリ基地局に間接的に転送するインダイレクトフォワーディングのうちの一のフォワーディング方式を決定する制御部を備える。前記制御部は、前記ダイレクトフォワーディングを決定した場合、前記ダイレクトフォワーディングに関する通知情報を前記ターゲット基地局に送信する。
【0202】
第6実施形態に係るソース基地局において、前記制御部は、前記ダイレクトフォワーディングが完了した場合、前記通知情報としてのエンドマーカを前記ターゲット基地局に送信する。
【0203】
第6実施形態に係るターゲット基地局は、二重接続方式をサポートする移動通信システムにおいて、ソース基地局からターゲット基地局に対してユーザ端末のハンドオーバを行う場合における前記ターゲット基地局である、前記ターゲット基地局は、前記ユーザ端末のベアラのデータを前記ソース基地局から前記ターゲット基地局を介してセカンダリ基地局に間接的に転送するインダイレクトフォワーディングに用いるトンネリング識別子を設定した後、前記トンネリング識別子を含むメッセージを前記ソース基地局に送信する制御部を備える。前記制御部は、前記データを前記ソース基地局から前記セカンダリ基地局に直接的に転送するダイレクトフォワーディングを前記ソース基地局が決定した場合、前記ダイレクトフォワーディングに関する通知情報を前記ソース基地局から受信する。
【0204】
第6実施形態に係るターゲット基地局において、前記制御部は、前記通知情報の受信に応じて、前記第2のトンネリング識別子を解放する。
【0205】
[二重接続方式]
以下において、二重接続方式について説明する。実施形態に係るLTEシステムは、二重接続方式をサポートする。図15は、二重接続方式の概要を示す図である。図15に示すように、二重接続方式において、UE100は、MeNB200M(マスタ基地局)との接続及びSeNB200S(セカンダリ基地局)との接続を確立する。UE100には、各eNB200のスケジューラから無線リソースが割り当てられる。
【0206】
二重接続方式において、UE100との接続を確立する複数のeNB200のうち、MeNB200Mのみが当該UE100とのRRC接続を確立する。これに対し、SeNB200Sは、RRC接続をUE100と確立せずに、追加的な無線リソースをUE100に提供する。言い換えると、MeNB200Mは、ユーザプレーン接続だけでなく制御プレーン接続をUE100と確立する。これに対し、SeNB200Sは、制御プレーン接続をUE100と確立せずに、ユーザプレーン接続をUE100と確立する。MeNB200MとSeNB200Sとの間にはX2インターフェイスが設定されている。
【0207】
二重接続方式において、UE100は、MeNB200Mが管理するN個のサービングセル及びSeNB200Sが管理するM個のサービングセルを同時に利用したキャリアアグリゲーションが可能である。二重接続方式においてUE100のサービングセルの最大数、すなわち、(N+M)の最大数は、例えば5である。MeNB200Mが管理するN個のサービングセルからなるグループは、マスタセルグループ(MCG)と称される。SeNB200Sが管理するM個のサービングセルからなるグループは、セカンダリセルグループ(SCG)と称される。SCGは、UE100のPUCCHを設けるプライマリ・セカンダリセル(PSCell)を含む。
【0208】
図16及び図17は、二重接続方式におけるベアラ構成例を示す図である。ベアラは、ユーザデータの転送経路(データパス)に相当する。なお、UE100とP−GW(PDN Gateway)との間にEPS(Evolved Packet System)ベアラが確立される。EPSベアラは、UE100とS-GWとの間のE−RAB(E−UTRAN Radio Access Bearer)と、S-GWとP−GWとの間のS5/S8ベアラと、により構成される。E−RABは、UE100とeNB200との間の無線ベアラと、eNB200とS-GWとの間のS1ベアラと、により構成される。以下において「ベアラ」とは、主としてE−RAB又はEPSベアラを意味する。
【0209】
図16は、二重接続方式におけるベアラ構成例1を示す。図16Aに示すように、UE100は、MeNB200Mを介して確立するベアラ(EPS bearer#1)と、SeNB200Sを介して確立するベアラ(EPS bearer#2)と、を有する。但し、UE100は、3つ以上のベアラを有していてもよい。また、図16Aにおいて下りリンクのベアラを例示しているが、UE100は、上りリンクのベアラも有していてもよい。
【0210】
MeNB200Mを介して確立するベアラ(EPS bearer#1)は、対応する無線プロトコルがMeNB200Mにのみ存在するベアラである。このようなベアラのタイプは、「MCGベアラ」と称される。MCGベアラは、MeNB200Mを介してベアラを確立する第1のタイプに相当する。一方、SeNB200Sを介して確立するベアラ(EPS bearer#2)は、対応する無線プロトコルがSeNB200Sにのみ存在するベアラである。このようなベアラのタイプは、「SCGベアラ」と称される。SCGベアラは、SeNB200Sを介してベアラを確立する第2のタイプに相当する。
【0211】
図16Bに示すように、MeNB200Mは、MCGベアラ(EPS bearer#1)について、PDCP、RLC、MACの各層の処理を行う。SeNB200Sは、SCGベアラ(EPS bearer#2)について、PDCP、RLC、MACの各層の処理を行う。
【0212】
図17は、二重接続方式におけるベアラ構成例2を示す。図17Aに示すように、UE100は、MeNB200Mを介して確立するベアラ(EPS bearer#1)と、MeNB200M及びSeNB200Sの両方を介して確立するベアラ(EPS bearer#2)と、を有する。但し、UE100は、3つ以上のベアラを有していてもよい。また、図17Aにおいて下りリンクのベアラを例示しているが、UE100は、上りリンクのベアラも有していてもよい。
【0213】
MeNB200Mを介して確立するベアラ(EPS bearer#1)は、図16と同様なMCGベアラである。一方、MeNB200M及びSeNB200Sの両方を介して確立するベアラ(EPS bearer#2)は、対応する無線プロトコルがMeNB200M及びSeNB200Sの両方に存在するベアラである。このようなベアラのタイプは、「スプリットベアラ」と称される。
【0214】
図17Bに示すように、MeNB200Mは、MCGベアラ(EPS bearer#1)について、PDCP、RLC、MACの各層の処理を行う。また、MeNB200Mは、スプリットベアラ(EPS bearer#2)について、PDCP、RLC、MACの各層の処理を行う。MeNB200MのPDCP層は、スプリットベアラ(EPS bearer#2)の少なくとも一部のデータをSeNB200Sに割り振る。SeNB200Sは、スプリットベアラ(EPS bearer#2)について、RLC及びMACの各層の処理を行う。
【0215】
[想定シナリオ]
以下において、第2実施形態乃至第6実施形態に係る想定シナリオについて説明する。図18は、第2実施形態乃至第6実施形態に係る想定シナリオを示す図である。図18に示すように、二重接続方式によりMeNB200M1及びSeNB200Sに接続するUE100は、SeNB200Sを変更せず(SeNB200SとUE100との間の接続を維持しつつ)、MeNB200M1からMeNB200M2へのハンドオーバを行う。
【0216】
このようなハンドオーバは、SeNB200Sを変更しないMeNB間ハンドオーバ(inter MeNB Hanover without SeNB change)と称される。以下において、ハンドオーバ元であるeNB200M1をソースMeNB(ソースマスタ基地局)200M1と称し、ハンドオーバ先であるeNB200M2をターゲットMeNB(ターゲットマスタ基地局)200M2と称する。
【0217】
図18(A)に示すように、ソースMeNB200M1はマクロセルMC1を管理し、ターゲットMeNB200M2はマクロセルMC2を管理し、SeNB200Sは小セルSCを管理している。マクロセルMC1の一部とマクロセルMC2の一部とは重複しており、当該重複する領域に小セルSCが位置する。小セルSC内に位置するUE100は、二重接続方式によりソースMeNB200M1及びSeNB200Sに接続する。具体的には、UE100は、ソースMeNB200M1を介してMCGベアラを確立し、SeNB200Sを介してSCGベアラを確立する。UE100は、SCGベアラに代えてスプリットベアラを確立してもよいし、又はSCGベアラに加えてスプリットベアラを確立してもよい。
【0218】
このような状況下で、図18(B)に示すように、UE100がターゲットMeNB200M2の方向に向けて移動すると仮定する。この場合、UE100とソースMeNB200M1との間の無線状況が悪化するため、UE100のハンドオーバの必要性が生じる。UE100は、SeNB200Sを変更せずに、ソースMeNB200M1からターゲットMeNB200M2へのMeNB間ハンドオーバを行う。
【0219】
実施形態において、ソースMeNB200M1を介して確立された少なくとも1つのMCGベアラは、MeNB間ハンドオーバの際に、SCGベアラに変更され、SeNB200Sに引き継がれる。このようなベアラタイプの変更は、ターゲットMeNB200M2により決定される。MCGベアラをSCGベアラに変更する場合、MCGベアラのデータ(すなわち、ソースMeNB200M1のバッファに残存するデータ)をソースMeNB200M1からSeNB200Sに転送する必要がある。このようなデータ転送は、「フォワーディング」と称される。
【0220】
図19は、実施形態に係るフォワーディング方式を示す図である。フォワーディング方式には、ダイレクトフォワーディング及びインダイレクトフォワーディングの2つの方式がある。
【0221】
図19(A)に示すように、ダイレクトフォワーディングにおいて、ソースMeNB200M1は、X2インターフェイスを介して、UE100のベアラ(MCGベアラ)のデータをSeNB200Sに直接的に転送する。具体的には、ソースMeNB200M1とSeNB200Sとの間には、X2インターフェイス上にトンネリング接続が確立され、トンネリング接続によりソースMeNB200M1からSeNB200Sにデータが転送される。
【0222】
トンネリング接続は、フォワーディング対象のベアラごとに確立される。また、トンネリングには、GPRSトンネリングプロトコル(GTP)が適用される。ソースMeNB200M1は、ダイレクトフォワーディングを行うために、SeNB200Sに設定されたGTPトンネリング識別子(TE ID:Tunnel Endpoint Identifier)を把握している必要がある。SeNB200Sに設定されたGTP TE IDは、第1のトンネリング識別子に相当する。
【0223】
図19(B)に示すように、インダイレクトフォワーディングにおいて、ソースMeNB200M1は、ターゲットMeNB200M2を介して、UE100のベアラ(MCGベアラ)のデータをSeNB200Sに間接的に転送する。具体的には、ソースMeNB200M1とターゲットMeNB200M2との間には、X2インターフェイス上にトンネリング接続が設定され、かつ、ターゲットMeNB200M2とSeNB200Sとの間には、X2インターフェイス上にトンネリング接続が確立される。
【0224】
これらのトンネリング接続により、まずソースMeNB200M1からターゲットMeNB200M2にデータが転送され、次にターゲットMeNB200M2からSeNB200Sにデータが転送される。ソースMeNB200M1は、インダイレクトフォワーディングを行うために、ターゲットMeNB200M2に設定されたGTPトンネリング識別子(TE ID)を把握している必要がある。ターゲットMeNB200M2に設定されたGTP TE IDは、第2のトンネリング識別子に相当する。
【0225】
[第2実施形態]
以下において、第2実施形態について説明する。
【0226】
(1)第2実施形態に係る動作シーケンス
第2実施形態において、ソースMeNB200M1は、ダイレクトフォワーディングを行うか又はインダイレクトフォワーディングを行うかの決定を行う。このようなフォワーディング方式の決定をソースMeNB200M1が行う場合、ターゲットMeNB200M2は、ダイレクトフォワーディング用の第1のトンネリング識別子及びインダイレクトフォワーディング用の第2のトンネリング識別子を、フォワーディング対象のベアラと対応付けてソースMeNB200M1に通知する必要がある。
【0227】
図20は、第2実施形態に係る概略シーケンスを示す図である。
【0228】
図20に示すように、ステップS11において、ソースMeNB(S−MeNB)200M1は、ハンドオーバ要求(HANDOVER REQUEST)をターゲット(T−MeNB)MeNB200M2に送信する。ハンドオーバ要求は、UE100のベアラの情報を含む。
【0229】
ターゲットMeNB200M2は、ハンドオーバ要求を受信する。ターゲットMeNB200M2は、ソースMeNB200M1を介して確立された少なくとも1つのMCGベアラを、SCGベアラに変更して、SeNB200Sに引き継ぐことを決定する。言い換えると、ターゲットMeNB200M2は、ベアラのタイプを、ソースMeNB200M1を介してベアラを確立する第1のタイプから、SeNB200Sを介してベアラを確立する第2のタイプに変更すると決定する。以下において、MCGベアラからSCGベアラに変更されるベアラを「タイプ変更ベアラ」と称する。
【0230】
ステップS12において、ターゲットMeNB200M2は、SeNB追加要求(SENB ADDITION REQUEST)をSeNB200Sに送信する。SeNB追加要求は、タイプ変更ベアラのベアラ識別子を含む。
【0231】
SeNB200Sは、SeNB追加要求を受信する。SeNB200Sは、タイプ変更ベアラについて、ダイレクトフォワーディング用の第1のトンネリング識別子(GTP TE ID)を設定する。
【0232】
ステップS13において、SeNB200Sは、SeNB追加要求に対する肯定応答メッセージであるSeNB追加要求応答(SENB ADDITION REQUEST ACKNOWLEDGE)をターゲットMeNB200M2に送信する。SeNB追加要求応答は、タイプ変更ベアラのベアラ識別子と、ダイレクトフォワーディング用の第1のトンネリング識別子と、を含む。SeNB追加要求応答において、第1のトンネリング識別子は、タイプ変更ベアラのベアラ識別子と対応付けられている。
【0233】
ターゲットMeNB200M2は、SeNB追加要求応答を受信する。ターゲットMeNB200M2は、タイプ変更ベアラについて、インダイレクトフォワーディング用の第2のトンネリング識別子(GTP TE ID)を設定する。
【0234】
ステップS14において、ターゲットMeNB200M2は、ハンドオーバ要求に対する肯定応答メッセージであるハンドオーバ要求応答(HANDOVER REQUEST ACKNOWLEDGE)をソースMeNB200M1に送信する。ハンドオーバ要求応答は、ダイレクトフォワーディング用の第1のトンネリング識別子と、インダイレクトフォワーディング用の第2のトンネリング識別子と、タイプ変更ベアラのベアラ識別子と、を含む。
【0235】
ハンドオーバ要求応答において、第1のトンネリング識別子及び第2のトンネリング識別子は、同一のベアラ識別子に対応付けられている。ここで、第1のトンネリング識別子及び第2のトンネリング識別子は、同一のベアラ識別子に対応付けているのは、以下の理由による。
【0236】
第1のトンネリング識別子にタイプ変更ベアラのベアラ識別子(A)を対応付け、かつ、第2のトンネリング識別子にタイプ変更ベアラのベアラ識別子(B)を対応付ける場合、同一の値を有する複数のベアラ識別子がハンドオーバ要求応答に含まれることになる。つまり、第1のトンネリング識別子に対応付けられるベアラ識別子のフィールドと第2のトンネリング識別子に対応付けられるベアラ識別子のフィールドとが異なる場合、同一のベアラ(タイプ変更ベアラ)について複数のベアラ識別子が存在し、ベアラ識別子の重複が生じる。これは既存のLTE仕様において、エラー(Cause IE: Multiple E−RAB ID instances)とみなされてハンドオーバが失敗する又は特定のベアラに関してのみハンドオーバが失敗する虞がある。
【0237】
一方、ハンドオーバ要求応答において、第1のトンネリング識別子及び第2のトンネリング識別子は、同一のベアラ識別子に対応付けることにより、同一のベアラ(タイプ変更ベアラ)について複数のベアラ識別子が存在しなくなるため、上記のようなエラーを防止することができる。
【0238】
表1に、第2実施形態に係るハンドオーバ要求応答の構成例を示す。
【0239】
【表1】
【0240】
表1に示すように、ハンドオーバ要求応答は、ターゲットMeNB200M2がリソースを準備したベアラ(E−RAB)のリストである「E−RABs Admitted List」を含む。「E−RABs Admitted List」は、ベアラごとの項目(E−RABs Admitted Item)を含む。各項目は、「E−RAB ID」、「UL GTP Tunnel Endpoint」、「DL GTP Tunnel Endpoint」、「UL GTP Tunnel Endpoint for direct forwarding」、「DL GTP Tunnel Endpoint for direct forwarding」を含む。その他の情報要素(IE)については、3GPP技術仕様書「TS36.423」を参照されたい。
【0241】
ここで、「E−RAB ID」は、ベアラ識別子に相当する。「UL GTP Tunnel Endpoint」及び「DL GTP Tunnel Endpoint」は、インダイレクトフォワーディング用の第2のトンネリング識別子に相当する。「UL GTP Tunnel Endpoint for direct forwarding」及び「DL GTP Tunnel Endpoint for direct forwarding」は、ダイレクトフォワーディング用の第1のトンネリング識別子に相当する。このように、第1のトンネリング識別子及び第2のトンネリング識別子は、同一のベアラ識別子に対応付けられている。具体的には、1つの項目(E−RABs Admitted Item)内に、1つのベアラ識別子と、第1のトンネリング識別子及び第2のトンネリング識別子と、が含まれる。
【0242】
ソースMeNB200M1は、ハンドオーバ要求応答を受信する。
【0243】
ステップS15において、ソースMeNB200M1は、ハンドオーバ要求応答の受信に応じて、SeNB解放要求(SENB RELEASE REQUEST)をSeNB200Sに送信する。また、ソースMeNB200M1は、ダイレクトフォワーディング及びインダイレクトフォワーディングのうちの一のフォワーディング方式を決定する。
【0244】
なお、ソースMeNB200M1がダイレクトフォワーディング及びインダイレクトフォワーディングのうちの一のフォワーディング方式を決定する際の判断基準としては、次に示す情報を用いることができる。1)ユーザ(アプリケーション)が要求するQoSや課金情報。2)オペレータの好み。例えば、MeNBとSeNBが同一ベンダの製品であれば、ダイレクトを選択する。このような情報は、OAMによってeNBに事前設定(pre config)される。3)T−MeNBの負荷情報。既存仕様に従って事前に負荷情報が「Resource Status Reporting procedure」で交換されているため、T−MeNBの負荷が高い場合にはダイレクトフォワーディングを選択することにより、転送負荷をなくすことが可能である。
【0245】
ソースMeNB200M1は、決定したフォワーディング方式に応じて、第1のトンネリング識別子及び第2のトンネリング識別子の何れかを用いてタイプ変更ベアラに対するフォワーディング制御を行う。具体的には、ダイレクトフォワーディングを決定した場合、ソースMeNB200M1は、第1のトンネリング識別子を用いてタイプ変更ベアラに対するフォワーディング制御を行う(ステップS16b、ステップS17b)。一方、インダイレクトフォワーディングを決定した場合、ソースMeNB200M1は、第2のトンネリング識別子を用いてタイプ変更ベアラに対するフォワーディング制御を行う(ステップS16a、ステップS17a)。
【0246】
(2)詳細シーケンスの一例
図21は、第2実施形態に係る詳細シーケンスの一例を示す図である。上述したように、本シーケンスは、UE100と接続するSeNB200S1を変更せずにMeNB間ハンドオーバを行うシーケンスであって、ソースMeNB200M1で確立しているMCGベアラをSeNB200S1が管理するSCGベアラに変更するものである。
【0247】
図21に示すように、ステップS401において、UE100は、eNB200(ソースMeNB200M1及び/又はターゲットMeNB200M2を含む)からの信号の測定結果が一定の条件を満たすと、信号の測定結果を含む測定報告(Measurement Report)をソースMeNB200M1に送信する。ソースMeNB200M1は、UE100から測定報告を受信すると、ハンドオーバ手順を開始する。なお、ハンドオーバ手順の開始は、UE100からの測定報告の受信以外を契機としてもよい。
【0248】
ステップS402において、ソースMeNB200M1は、ターゲットMeNB200M2にハンドオーバ要求(Handover Request)を送信する。ハンドオーバ要求は、ベアラタイプの変更を要求する旨(例えば、MCGベアラからSCGベアラへの変更を要求する旨)を含んでもよい。また、ハンドオーバ要求は、ソースMeNB200M1が管理するMCGベアラの情報(例えば、ベアラ識別子)及び/又はSCGベアラの情報を含んでもよい。ハンドオーバ要求は、UE合計最大ビットレート(UE Aggregate Maximum Bitrate)及び/又はSeNB200S1におけるUE合計最大ビットレート(SeNB UE Aggregate Maximum Bitrate)を含んでもよい。なお、ベアラ識別子は、E−RAB IDであってもよい。また、ハンドオーバ要求は、ベアラの種類に関する情報(MCGベアラ、SCGベアラ又はスプリットベアラ)を含んでもよい。また、ベアラの種類に関する情報は、ベアラ識別子に対応付けられてもよい。これにより、ハンドオーバ要求を受信したターゲットMeNB200M2は、ソースMeNB200M1が管理するベアラ識別子に対応するベアラの種類(MCGベアラ、SCGベアラ又はスプリットベアラなのか)を特定することが可能となる。
【0249】
ステップS403において、ターゲットMeNB200M2は、ベアラタイプを変更するか否かを判断する。つまり、ターゲットMeNB200M2は、ソースMeNB200M1で確立しているMCGベアラをSeNB200S1のSCGベアラに変更するか否かを判断する。ターゲットMeNB200M2は、ハンドオーバ要求にベアラタイプの変更を要求する旨が含まれている場合に、ベアラタイプを変更すると判断してもよい。或いは、ターゲットMeNB200M2は、自局のRRM(無線リソース管理)に基づいてベアラタイプを変更すると判断してもよい。具体的には、ターゲットMeNB200M2は、SeNB200S1のリソース状況及び負荷状況、UE100におけるターゲットMeNB200M2及び/若しくはSeNB200S1からの信号の測定結果、UE合計最大ビットレート(UE Aggregate Maximum Bit Rate)並びに/又はSeNB200S1におけるUE合計最大ビットレート(SeNB UE Aggregate Maximum Bit Rate)等に基づいて、ソースMeNB200M1におけるUE100向けのデータをSeNB200S1から送信すべきと判断することにより、ベアラタイプを変更すると判断してもよい。
【0250】
ターゲットMeNB200M2は、ベアラタイプを変更すると判断すると(S403:YES)、変更するMCGベアラの識別子(ベアラ識別子)を記憶する。ターゲットMeNB200M2は、変更する対象のMCGベアラの情報を「Inter−node RRC information element」の1つである「Handover Preparation Information」により取得してもよい。
【0251】
ステップS404において、ターゲットMeNB200M2は、SeNB追加要求に、SeNB200S1に対して確立(又は設定)を要求するSCGベアラの情報を含めて送信する。ターゲットMeNB200M2は、SeNB追加要求内の「E−RAB To Be Added Item IE」内の「SCG Bearer IE」に上記SCGベアラの情報を含める。ここで、SCGベアラの情報とは、E−RAB ID、E−RAB Level QoS Parameters、DL Forwarding及びS1 UL GTP Tunnel Endpoint等である。SeNB200S1は、受信したSeNB追加要求に、既に確立しているSCGベアラのベアラ識別子とは異なるベアラ識別子が含まれている場合には、当該異なるベアラ識別子に対応するSCGベアラの追加(当該ベアラ識別子に対応するMCGベアラからSCGベアラへの変更)が要求されていると判断してもよい。
【0252】
ステップS405において、SeNB200S1は、ソースMeNB200M1からSeNB200S1へのダイレクトデータフォワーディングのための自局のGTP TE IDを含めてSeNB追加要求応答(SeNB Addition Request Acknowledgement)をターゲットMeNB200M2に送信する。
【0253】
ステップS406において、ターゲットMeNB200M2は、ハンドオーバ要求応答(Handover Request Acknowledgement)に、SeNB200S1から受信したSeNB200S1のGTP TE ID及びステップS403において記憶したタイプ変更ベアラの識別子(ベアラ識別子)を含めて送信する。
【0254】
ステップS407において、ソースMeNB200M1は、SeNB200S1へSeNB解放要求(SeNB Release Request)を送信する。
【0255】
ステップS408において、ソースMeNB200M1は、RRC接続再設定(RRC Connection Reconfiguration)をUE100に送信する。
【0256】
ステップS409において、UE100は、ランダム接続手順(Random Access Procedure)をターゲットMeNB200M2に対して実行する。
【0257】
ステップS410において、UE100は、RRC接続再設定完了(RRC Connection Reconfiguration Complete)をターゲットMeNB200M2に送信する。
【0258】
ステップS411において、UE100は、ランダム接続手順(Random Access Procedure)をSeNB200S1に対して実行する。
【0259】
ステップS412において、ターゲットMeNB200M2は、SeNB再設定完了(SeNB Reconfiguration Complete)をSeNB200S1に送信する。
【0260】
ステップS413において、ソースMeNB200M1は、「SN Status Transfer」メッセージをターゲットMeNB200M2に通知する。「SN Status Transfer」メッセージは、ソースMeNB200M1における上り又は下りデータの転送状況に関する通知である。
【0261】
ステップS414において、ソースMeNB200M1は、S−GW300UからソースMeNB200M1を介してUE100向けのデータをターゲットMeNB200M2に転送するデータフォワーディングを行う。
【0262】
ステップS415において、ソースMeNB200M1は、SeNB200S1の「GTP TE ID」に対して、タイプ変更ベアラについてバッファしているUE100向けのデータを、SeNB200S1に直接的に転送する(ダイレクトフォワーディング)。
【0263】
ステップS416において、ターゲットMeNB200M2は、S−GW300UとソースMeNB200M1との間のデータパスをターゲットMeNB200M2へ切換えるために、パス切替要求(Path Switch Request)をMME300Cに送信する。
【0264】
ステップS417及びステップS418において、S−GW300Uは、MME300Cとのベアラ修正(Bearer Modification)をし、新規のデータパスをターゲットMeNB200M2と設定する(S418a)とともに、SeNB200S1とのSCGベアラを設定する(S418b)。なお、ステップS418bにおいて、SCGベアラを新たに設定してもよい。また、SCGベアラを新たに設定する代わりに、SeNB200S1がソースMeNB200M1によってSCGベアラが設定されている状態で、ハンドオーバ前後において、S−GW300Uが変更されないのであれば、当該SCGベアラを維持してもよい。
【0265】
ステップS419において、MME300Cは、パス切替要求応答(Path Switch Request Acknowledge)をターゲットMeNB200M2に送信する。
【0266】
ステップS420において、ターゲットMeNB200M2は、ソースMeNB200M1へUEコンテキスト解放(UE Context Release)を送信する。
【0267】
ステップS421において、ソースMeNB200M1は、UEコンテキスト解放(UE Context Release)をSeNB200S1に送信する。
【0268】
なお、ソースMeNB200M1は、ステップS413の後であってステップS415の前に、ステップS415のダイレクトフォワーディングに用いるベアラ(ベアラタイプをMCGベアラからSCGベアラに変更するベアラ)に関する「SN Status Transfer」メッセージをSeNB200S1へ通知してもよい(ステップS414a)。
【0269】
[第3実施形態]
以下において、第3実施形態について説明する。第3実施形態は第2実施形態の一部を変更した実施形態であるため、第2実施形態との相違点について説明する。
【0270】
第3実施形態に係る動作シーケンスは、図20と同様である。但し、第3実施形態は、ハンドオーバ要求応答(図20のステップS14のメッセージ)の構成が第2実施形態とは異なる。
【0271】
第3実施形態に係るハンドオーバ要求応答において、第1のトンネリング識別子に対応付けられるベアラ識別子のフィールドと第2のトンネリング識別子に対応付けられるベアラ識別子のフィールドとが異なる。つまり、同一のベアラ(タイプ変更ベアラ)について複数のベアラ識別子が存在する。上述したように、このようなベアラ識別子の重複がある場合、エラー(Cause: Multiple E−RAB ID instances)とみなされる虞がある。
【0272】
そこで、第3実施形態に係るターゲットMeNB200M2は、ダイレクトフォワーディング及びインダイレクトフォワーディングのうちの一のフォワーディング方式をソースMeNB200M1が決定可能であることを示す情報要素をハンドオーバ要求応答に含める。このような情報要素をハンドオーバ要求応答に含める。言い換えると、ターゲットMeNB200M2は、ベアラ識別子の重複が意図的に行われており、エラーと判断するべきではないことを示すインジケータをハンドオーバ要求応答に含める。これにより、ソースMeNB200M1は、ハンドオーバ要求応答中に、同一の値を有する複数のベアラ識別子が存在する場合でも、エラーと判断しないようにすることができる。
【0273】
表2に、第3実施形態に係るハンドオーバ要求応答の構成例を示す。なお、説明の便宜上、既存のIEの一部を省略して示している。
【0274】
【表2】
【0275】
表2に示すように、第3実施形態に係るハンドオーバ要求応答において、「E−RABS ADMITTED LIST」とは別に、ダイレクトフォワーディング用の「Direct Data Forwarding E−RABs List」が設けられる。
【0276】
「Direct Data Forwarding E−RABs List」は、「Direct Data Forwarding E−RABs Item」を含む。「Direct Data Forwarding E−RABs Item」は、ダイレクトフォワーディングに用いる第1のトンネリング識別子(「UL Forwarding GTP Tunnel Endpoint」、「DL Forwarding GTP Tunnel Endpoint」)と、ベアラを識別する第1のベアラ識別子(E−RAB ID)と、を含む。このように、第1のトンネリング識別子が第1のベアラ識別子に対応付けられている。
【0277】
一方、「E−RABS ADMITTED LIST」は、「E−RABs Admitted Item」を含む。「E−RABs Admitted Item」は、インダイレクトフォワーディングに用いる第2のトンネリング識別子(「UL GTP Tunnel Endpoint」、「DL GTP Tunnel Endpoint」)と、ベアラを識別する第2のベアラ識別子(E−RAB ID)と、を含む。このように、第2のトンネリング識別子が第2のベアラ識別子に対応付けられている。
【0278】
さらに、第3実施形態に係るハンドオーバ要求応答は、フォワーディング方式をソースMeNB200M1が決定可能であることを示す情報要素(Forwarding Selectable)を含む。
【0279】
ソースMeNB200M1は、フォワーディング方式をソースMeNB200M1が決定可能であることを示す情報要素(Forwarding Selectable)を含むハンドオーバ要求応答を受信する。ソースMeNB200M1は、情報要素(Forwarding Selectable)の受信に応じて、エラーと判断することなく、ダイレクトフォワーディング及びインダイレクトフォワーディングのうちの一のフォワーディング方式を決定する。
【0280】
ソースMeNB200M1は、決定したフォワーディング方式に応じて、第1のトンネリング識別子及び第2のトンネリング識別子の何れかを用いてタイプ変更ベアラに対するフォワーディング制御を行う。具体的には、ダイレクトフォワーディングを決定した場合、ソースMeNB200M1は、第1のトンネリング識別子を用いてタイプ変更ベアラに対するフォワーディング制御を行う(図20のステップS16b、ステップS17b参照)。一方、インダイレクトフォワーディングを決定した場合、ソースMeNB200M1は、第2のトンネリング識別子を用いてタイプ変更ベアラに対するフォワーディング制御を行う(図20のステップS16a、ステップS17a参照)。
【0281】
[第4実施形態]
以下において、第4実施形態について説明する。第4実施形態に係る動作シーケンスは、図20と同様である。但し、第4実施形態は、ハンドオーバ要求(図20のステップS11のメッセージ)及びハンドオーバ要求応答(図20のステップS14のメッセージ)の構成が第2実施形態及び第3実施形態とは異なる。
【0282】
第4実施形態に係るソースMeNB200M1は、ダイレクトフォワーディングが可能であることを示す通知情報をターゲットMeNB200M2に送信する。具体的には、ソースMeNB200M1は、ソースMeNB200M1からターゲットMeNB200M2に送信するハンドオーバ要求に通知情報を含める。通知情報は、ソースMeNB200M1がダイレクトフォワーディングを提案することを示す情報、又は、ソースMeNB200M1とSeNB200Sとの間のX2インターフェイスが利用可能であることを示す情報である。なお、ソースMeNB200M1がダイレクトフォワーディングを提案するか否かを決定する際の判断基準としては、第2実施形態において例示した1)乃至3)に示す情報を用いることができる。
【0283】
ターゲットMeNB200M2は、通知情報の受信に応じて、ダイレクトフォワーディング及びインダイレクトフォワーディングのうちの一のフォワーディング方式を決定する。そして、ターゲットMeNB200M2は、決定したフォワーディング方式をソースMeNB200M1に通知(又は指示)する。具体的には、ターゲットMeNB200M2は、決定したフォワーディング方式を示す情報をハンドオーバ要求応答に含める。
【0284】
このように、第4実施形態においては、フォワーディング方式の決定権をターゲットMeNB200M2が持ち、ソースMeNB200M1は、そのような決定を補助するための通知を行う。フォワーディング方式の決定をターゲットMeNB200M2が行うことにより、ターゲットMeNB200M2は、ダイレクトフォワーディング用の第1のトンネリング識別子及びインダイレクトフォワーディング用の第2のトンネリング識別子のうち一方のみをソースMeNB200M1に通知すればよい。よって、上述したエラーの発生を防止することができる。
【0285】
ターゲットMeNB200M2は、ダイレクトフォワーディングを指示する場合に、ステップS406において送信するハンドオーバ要求応答にダイレクトフォワーディングの指示(Direct Data Forwarding Indicator)を含めてもよい。これにより、ソースMeNB200M1は、ソースMeNB200M1からSeNB200S1へのダイレクトフォワーディングが要求されているのか否かを判断することができる。なお、ダイレクトフォワーディングの指示は、ハンドオーバ要求応答に含まれているベアラ識別子及び/又はSeNB200S1のGTP TE IDに対応付けられてもよい。これにより、ソースMeNB200M1は、ハンドオーバ要求応答に複数のベアラ識別子及び又はGTP TE IDが含まれている場合に、どのベアラ識別子及び/又はGTP TE IDがダイレクトフォワーディング用のベアラ識別子及び/又はGTP TE IDであるかを判別することができる。
【0286】
(1)ハンドオーバ要求の構成例1
表3に、第4実施形態に係るハンドオーバ要求の構成例1を示す。なお、説明の便宜上、既存のIEの一部を省略して示している。
【0287】
【表3】
【0288】
表3に示すように、ハンドオーバ要求は、「DL Forwarding」を含む。「DL Forwarding」は、ハンドオーバすべきベアラ(E−RABs To Be Setup Item)ごとに設けられる。なお、「DL Forwarding」自体は、既存のIEである。その他のIEについては、3GPP技術仕様書「TS36.423」を参照されたい。
【0289】
第4実施形態に係るハンドオーバ要求の構成例1においては、ソースMeNB200M1がダイレクトフォワーディングを提案することを示す情報を「DL Forwarding」に含めることができるように、「DL Forwarding」の内容(ENUMERATED)を拡張する。
【0290】
表4に、第4実施形態に係る「DL Forwarding」の構成例を示す。
【0291】
【表4】
【0292】
表4に示すように、「DL Forwarding」は、ソースMeNB200M1がダイレクトフォワーディングを提案することを示す情報(direct forwarding proposed)を含めることが可能に構成される。
【0293】
ソースMeNB200M1は、ターゲットMeNB200M2にダイレクトフォワーディングを提案する場合、「direct forwarding proposed」を「DL Forwarding」に含める。一方、ターゲットMeNB200M2にダイレクトフォワーディングを提案しない場合、ソースMeNB200M1は、既存のIE(DL forwarding proposed)を「DL Forwarding」に含める。そして、ソースMeNB200M1は、「DL Forwarding」を含むハンドオーバ要求をターゲットMeNB200M2に送信する。
【0294】
ターゲットMeNB200M2は、「DL Forwarding」を含むハンドオーバ要求を受信する。ターゲットMeNB200M2は、「direct forwarding proposed」が「DL Forwarding」に含まれている場合、対応するベアラについて、ダイレクトフォワーディング及びインダイレクトフォワーディングの何れかのフォワーディング方式を決定する。一方、既存のIE(DL forwarding proposed)が「DL Forwarding」に含まれている場合、ターゲットMeNB200M2は、対応するベアラについて、ダイレクトフォワーディングを決定することはできず、インダイレクトフォワーディングを決定する。
【0295】
(2)ハンドオーバ要求の構成例2
表5に、第4実施形態に係るハンドオーバ要求の構成例2を示す。なお、説明の便宜上、既存のIEの一部を省略して示している。
【0296】
【表5】
【0297】
表5に示すように、ハンドオーバ要求の構成例2において、ハンドオーバ要求は、「E−RABs To Be Setup List」とは別のIEとして、ダイレクトフォワーディングを提案することを示す「Direct forwarding indicator」を含む。つまり、ダイレクトフォワーディングの提案をベアラごとに行うのではなく、「E−RABs To Be Setup List」中の全ベアラについてダイレクトフォワーディングの提案を纏めて行う。
【0298】
(3)ハンドオーバ要求の構成例3
ハンドオーバ要求の構成例3において、ソースMeNB200M1は、ソースMeNB200M1とSeNB200Sとの間のX2インターフェイスが利用可能である場合、ソースMeNB200M1とSeNB200Sとの間のX2インターフェイスが利用可能であることを示す情報(X2 available)をハンドオーバ要求に含める。
【0299】
ソースMeNB200M1は、ソースMeNB200M1とSeNB200Sとの間のX2インターフェイスが利用不能である場合、ソースMeNB200M1とSeNB200Sとの間のX2インターフェイスが利用不能であることを示す情報(X2 unavailable)をハンドオーバ要求に含めてもよい。
【0300】
ターゲットMeNB200M2は、情報(X2 available)がハンドオーバ要求に含まれている場合、ダイレクトフォワーディング及びインダイレクトフォワーディングの何れかのフォワーディング方式を決定する。一方、情報(X2 available)がハンドオーバ要求に含まれていない、又は、情報(X2 unavailable)がハンドオーバ要求に含まれている場合、ターゲットMeNB200M2は、ダイレクトフォワーディングを決定することはできず、インダイレクトフォワーディングを決定する。
【0301】
[第4実施形態の変更例]
上述した第4実施形態において、UE100と接続するSeNB200S1を変更せずにMeNB間ハンドオーバを行うシナリオである「inter MeNB Hanover without SeNB change」を想定していた。
【0302】
しかしながら、第4実施形態は、二重接続方式を適用していないUE100がハンドオーバに伴って二重接続方式を開始するシナリオである「inter eNB Hanover with SeNB Addition」に応用することができる。このシナリオにおいて、ソースeNBにおいて二重接続方式が適用されていない。このため、ターゲットeNBは、ダイレクトフォワーディングを利用可能か否か(すなわち、ソースeNBとSeNBとの間にX2インターフェイスが存在するか否か)を知ることができない。そこで、第4実施形態に係る通知情報をソースeNBからターゲットeNBに送信することにより、ターゲットeNBは、ダイレクトフォワーディングを利用可能か否か判断することができる。
【0303】
「inter eNB Hanover with SeNB Addition」のシナリオにおいて、まず、ソースeNBは、UE100に測定を設定し、UE100から測定報告を受信する。なお、ソースeNBがどのセルを対象として測定を設定するかは実装依存である。
【0304】
異なるeNBに属する複数のセルの測定結果が測定報告に含まれている場合、ソースeNBは、この情報をハンドオーバ要求(HO Req)に含めてターゲットeNB(target MeNB)に送信する。具体的には、ハンドオーバ要求内の「RRM Config IE in Handover Preparation information (RRC container)」に測定報告を含める。
【0305】
ここで、ソースeNBは、測定報告に含まれるセルが属するeNBすべてに対してX2インターフェイスがあれば、ダイレクトフォワーディング可と判断することができる。或いは、測定報告に含まれるセルが属するeNBのうち一部のeNBに対してのみX2インターフェイスがある場合、ソースeNBは、当該一部のeNBに対してのみダイレクトフォワーディング可と判断してもよい。この場合、ソースeNBは、当該一部のeNBをダイレクトフォワーディング可能なeNBとしてハンドオーバ要求(HO Req)中でターゲットeNBに通知してもよい。或いは、測定報告に対応する複数のeNB(複数のSeNB候補)のそれぞれについてダイレクトフォワーディング可能か否かをハンドオーバ要求(HO Req)中でターゲットeNBに通知してもよい。
【0306】
ターゲットeNB(target MeNB)は、転送された測定報告内の複数のセルの中から適したセルを選択し、対応するeNBに「SeNB Addition」を送信する。このようにしてSeNBが決定される。
【0307】
[第5実施形態]
以下において、第5実施形態について説明する。第5実施形態において、第2実施形態及び第3実施形態と同様に、ソースMeNB200M1は、ダイレクトフォワーディングを行うか又はインダイレクトフォワーディングを行うかの決定を行う。
【0308】
第2実施形態及び第3実施形態において説明したように、ターゲットMeNB200M2は、インダイレクトフォワーディングに用いる第2のトンネリング識別子を設定した後、第1のトンネリング識別子及び第2のトンネリング識別子を含むハンドオーバ要求応答をソースMeNB200M1に送信する(図20のステップS14参照)。
【0309】
ここで、ハンドオーバ要求応答を受信したソースMeNB200M1がダイレクトフォワーディングを決定した場合を想定する。この場合、ソースMeNB200M1は、SeNB200Sに対してダイレクトフォワーディングを行う(図19(A)参照)。具体的には、ソースMeNB200M1は、「SN STATUS TRANSFER」をSeNB200Sに送信し(図20のステップS16b参照)、その後、ダイレクトフォワーディングを行う(図20のステップS17b参照)。そして、ソースMeNB200M1は、自身宛のデータ転送が完了したことを示すエンドマーカをS−GWから受信すると、ダイレクトフォワーディングの完了を示すエンドマーカをSeNB200Sに送信する。
【0310】
このように、ソースMeNB200M1がダイレクトフォワーディングを決定した場合、ターゲットMeNB200M2は、その旨を知ることができず、インダイレクトフォワーディングに用いる第2のトンネリング識別子を保持しなければならない。よって、ターゲットMeNB200M2が第2のトンネリング識別子を保持する間において、X2インターフェイスのリソースが無駄になるという問題がある。
【0311】
図22は、第5実施形態に係るターゲットMeNB200M2の動作を示すフロー図である。
【0312】
図22に示すように、ターゲットMeNB200M2は、第1のトンネリング識別子及び第2のトンネリング識別子を含むハンドオーバ要求応答をソースMeNB200M1に送信した際に、インダイレクトフォワーディングが開始されるまでの最大待ち時間を規定するタイマを開始させる(ステップS41)。具体的には、タイマは、タイプ変更ベアラのベアラ識別子に対応する「SN STATUS TRANSFER」又は転送データの受信待ちを行うことが許容される時間を表す。
【0313】
ターゲットMeNB200M2は、タイマの時間内でインダイレクトフォワーディングが開始された場合(ステップS42:YES)には、タイマを停止させる(ステップS43)。具体的には、ターゲットMeNB200M2は、タイプ変更ベアラのベアラ識別子に対応する「SN STATUS TRANSFER」又は転送データの受信を検知した場合、すなわち、自身が設定した第2のトンネリング識別子宛てのメッセージ又はデータの受信を検知した場合、タイマを停止させる。
【0314】
一方、タイマが満了した場合、すなわち、タイマの時間内でインダイレクトフォワーディングが開始されなかった場合(ステップS44:YES)、ターゲットMeNB200M2は、第2のトンネリング識別子を解放する。具体的には、ターゲットMeNB200M2は、タイプ変更ベアラのベアラ識別子に対応する第2のトンネリング識別子(GTP TE ID)を解放する。ターゲットMeNB200M2は、第2のトンネリング識別子を解放するとともに、トランスポートレイヤアドレスを解放してもよい。
【0315】
よって、ソースMeNB200M1がダイレクトフォワーディングを決定した場合でも、ターゲットMeNB200M2が適切なタイミングで第2のトンネリング識別子を解放することができるため、X2インターフェイスのリソースが無駄になることを防止することができる。
【0316】
[第6実施形態]
以下において、第6実施形態について説明する。第6実施形態は、第5実施形態において説明した問題を解決しようとする実施形態であるが、解決方法が第5実施形態とは異なる。
【0317】
第6実施形態に係るソースMeNB200M1は、ダイレクトフォワーディング及びインダイレクトフォワーディングのうちの一のフォワーディング方式を決定する。ソースMeNB200M1は、ダイレクトフォワーディングを決定した場合、ダイレクトフォワーディングに関する通知情報をターゲットMeNB200M2に送信する。ソースMeNB200M1は、ダイレクトフォワーディングが完了した場合、エンドマーカをSeNB200Sに送信することに加えて、通知情報としてのエンドマーカをターゲットMeNB200M2に送信してもよい。この場合、ソースMeNB200M1は、転送データが存在しない場合でも、通知情報としてのエンドマーカをターゲットMeNB200M2に送信する。或いは、通知情報は、ダイレクトフォワーディングが決定されたことを示すシグナリング、又は第2のトンネリング識別子の解放を要求するシグナリングであってもよい。
【0318】
第6実施形態に係るターゲットMeNB200M2は、第1のトンネリング識別子及び第2のトンネリング識別子を含むハンドオーバ要求応答をソースMeNB200M1に送信する。ターゲットMeNB200M2は、ダイレクトフォワーディングをソースMeNB200M1が決定した場合、ダイレクトフォワーディングに関する通知情報をソースMeNB200M1から受信する。ターゲットMeNB200M2は、通知情報の受信に応じて、第2のトンネリング識別子を解放する。
【0319】
図23は、第6実施形態に係る動作シーケンスの一例を示す図である。
【0320】
図23に示すように、ステップS51乃至S55は、図20のステップS11乃至S15と同様である。
【0321】
ステップS56において、ソースMeNB200M1は、「SN STATUS TRANSFER」をSeNB200Sに送信する。
【0322】
ステップS57において、ソースMeNB200M1は、ダイレクトフォワーディングを行う。
【0323】
ステップS58において、ソースMeNB200M1は、エンドマーカをS−GWから受信すると、ダイレクトフォワーディングの完了を示すエンドマーカをSeNB200Sに送信する。
【0324】
ステップS59において、ソースMeNB200M1は、通知情報としてのエンドマーカをターゲットMeNB200M2に送信する。ターゲットMeNB200M2は、通知情報としてのエンドマーカの受信に応じて、第2のトンネリング識別子を解放する。ターゲットMeNB200M2は、第2のトンネリング識別子を解放するとともに、トランスポートレイヤアドレスを解放してもよい。
【0325】
[その他の実施形態]
第4実施形態の変更例において、「inter eNB Hanover with SeNB Addition」のシナリオについて説明した。しかしながら、第4実施形態以外の実施形態についても、「inter eNB Hanover with SeNB Addition」のシナリオに応用可能である。
【0326】
上述した各実施形態において、ターゲットMeNB200M2は、SeNB追加要求の送信に代えて、SeNB修正要求(SeNB Modification Request)をSeNB200Sに送信してもよい。その場合、SeNB200Sは、SeNB追加要求応答の送信に代えて、SeNB修正要求応答(SeNB Modification Request Acknowledgment)をターゲットMeNB200M2に送信する。その場合には、ソースMeNB200M1は、SeNB解放要求の送信を省略してもよい。
【0327】
上述した実施形態において、eNB200は、自身のタイマを停止させた後、当該タイマをリセット(クリア)する又は初期値にする。また、eNB200は、自身のタイマが満了した後、当該タイマをリセット(クリア)する又は初期値にする。
【0328】
上述した実施形態において、移動通信システムとしてLTEシステムを例示した。しかしながら、本発明はLTEシステムに限定されない。LTEシステム以外のシステムに本発明を適用してもよい。
【0329】
[付記1]
MeNB間ハンドオーバの承認されたシーケンスは、まだ検討事項(FFS)を有している。
【0330】
FFS1:SeNBにおけるUEコンテキストの参照は、SeNB UE X2AP ID又はC−RNTI。
【0331】
SeNBを変更しないMeNB間ハンドオーバ中にSeNBとUEとの間の関係を維持するために、SeNBは、該当するUEコンテキストを知るために、MeNBから識別子を通知される必要がある。SeNB UE X2AP ID及びC−RNTIの2つの候補がある。両方のIDがUEコンテキストを識別するために機能するが、次のような違いがある。
【0332】
−SeNB UE X2AP ID
このIDはSeNBのX2APでUEに一意に割り当てられる。よって、SeNB X2AP IDは、該当するUEのためのX2APセッションに関連している。UEコンテキストを参照するためにSeNB UE X2AP IDを使用することは素直な方法であると思われる。この場合、ソースMeNBからのハンドオーバ要求は、現在の二重接続(dual connectivity)に設定されているSeNB UE X2AP IDをターゲットMeNBに通知すべきである。
【0333】
−C−RNTI
C−RNTIは、該当するUEをASレイヤにおいて識別するためにMeNB及びSeNBの両方でMACによってセルグループごとにUEに割り当てられる。SeNBにおけるC−RNTIがUEコンテキストの参照のために使用されていると仮定すると、ターゲットMeNBは、SeNBコンテナIEに、MeNBにおけるIDをSeNBに通知する必要があり得る。また、ソースMeNBもハンドオーバ要求の前にSeNBで割り当てられたC−RNTIを知っている必要があり得る。これらは、RAN2の努力を引き起こす可能性がある。
【0334】
したがって、SeNB UE X2AP IDは、SeNBにおいてUEコンテキストを参照するために適している。
【0335】
提案1:SeNB UE X2AP IDは、SeNBでUEコンテキストを参照するために使用され、FFS1を削除すべきである。
【0336】
FFS2:SeNB修正要求(SeNB Modification Request)又は別のX2APメッセージは、SeNB追加要求(SeNB Addition Request)に代えてステップ3で使用することができる。
【0337】
FFS3:SeNBが保たれる場合、eNB1は、ステップ6のSeNB解放プロシージャ及びステップ15のUEコンテキスト解放をスキップすることができるか。
【0338】
それはSeNB修正準備(SeNB Modification Preparation)又はSeNB追加準備(SeNB Addition Preparation)のいずれかを使用することが考えられる。
【0339】
−SeNB修正準備
SeNB修正準備では、UEコンテキストが保持され、ハンドオーバ中に修正されるため、ソースMeNBからのSeNB解放プロシージャ及びUEコンテキスト解放プロシージャは必要ない。SeNBの観点から、SeNBにおいて該当するUEのUEコンテキストはハンドオーバ時に再利用され、ターゲットMeNBの新しい設定を適用するように修正される(例えば、SeNBセキュリティキー)。この挙動は、現在の仕様と整合される。
【0340】
ターゲットMeNBからのSENB MODIFICATION REQUEST messageに含まれるSeNB UE X2AP IDに関しては、ハンドオーバプロシージャの前に、既にSeNBによって割り当てられたものと同じでなければならない。したがって、SeNBは、SeNB UE X2AP IDがソースのMeNB UE X2AP IDに関連付けられていることに気づき、修正するべき該当するUEコンテキストを識別する必要がある。
【0341】
−SeNB追加準備
現在のTRは、SeNBを変更しないMeNB間ハンドオーバのためのSeNB追加準備を記述している。SeNBは、ターゲットMeNBによって開始されたSeNB追加要求の受信時に、該当するUEのための新たなUEコンテキストを作成することができる。SeNBはこの時点で古いUEコンテキストを解放していないので、SeNBで同じUEのためのUEコンテキストの複製(duplication)を引き起こす。よって、ソースMeNBからのUEコンテキスト解放プロシージャは、古いUEコンテキストを解放する必要があるべきである。
【0342】
現在のSeNB追加要求メッセージは、MeNB UE X2AP IDのみが含まれていることに留意すべきである。SeNB UE X2AP IDがメッセージに含まれているのであれば、SeNBは、SeNBを変更しないMeNB間ハンドオーバの発生を暗黙的に理解することができる。
【0343】
考察1:SeNB追加準備及びSeNB修正準備の両方を、SeNBを変更しないMeNB間ハンドオーバのために使用することができ、それぞれのプロシージャは長所と短所を持っている。
【0344】
−異常な状態(Abnormal condition)
SeNBを変更しないMeNB間ハンドオーバのプロシージャでは3つの異常な状態があることを考慮すべきである。これらの全ての条件は、以下の表6のように記述することができる。
【0345】
【表6】
【0346】
条件1:SeNB追加/修正要求拒絶を有するハンドオーバ要求肯定応答(HANDOVER REQUEST ACKNOWLEDGE with SENB ADDITION/MODIFICATION REQUEST REJECT)
SeNB修正準備では、拒絶により、二重接続用のX2セッションがソースMeNBとSeNBとの間にまだ保持されているので、ソースMeNBは、SeNBを解放すべきである。ソースMeNBは、最終のRRCメッセージを把握又は拒絶を通知されない限り、SeNB解放を開始すべきかどうかを決定する方法がない。
【0347】
一方、SeNB追加要求により、拒絶が発生したか否かにかかわらず、ソースMeNBは、SeNB解放プロシージャを開始する。この場合は、リリース12で定義された「MeNBからeNBに変更」と同じように考えることができる。
【0348】
条件2:SeNB追加/修正要求肯定応答を有するハンドオーバ準備失敗(HANDOVER PREPARATION FAILURE with SENB ADDITION/MODIFICATION REQUEST ACKNOWLEDGE)
SeNB修正準備では、ターゲットMeNBは、ソースMeNBへ二重接続のためのマスタの役割を返すためにSeNB修正準備を再始動する必要がある。また、ソースMeNBは役割が返されたか否かをSeNB又はターゲットMeNBのいずれかから通知される必要がある。SeNB追加準備では、ハンドオーバ拒絶に拘らず、二重接続のためのソースMeNBとSeNBとの間のX2セッションは保持されるので、ターゲットMeNBはSeNB解放を開始すべきである。
【0349】
条件3:SeNB追加/修正要求を有するハンドオーバ準備失敗(HANDOVER PREPARATION FAILURE with SENB ADDITION/MODIFICATION REQUEST REJECT)
SeNB追加/修正準備に拘らず、追加/修正要求が既に拒絶されたので、SeNB解放要求を開始する必要はない。よって、何も問題はない。
【0350】
異常な状態の両方のプロシージャに比べて、SeNB修正準備は、SeNB追加準備よりも複雑であるかもしれない。すなわち、SeNB解放要求を開始するか否かはケース・バイ・ケースである。したがって、SeNB追加準備をMeNB間ハンドオーバプロシージャのために使用することが若干好ましい。
【0351】
提案2:SeNB追加準備プロシージャは、SeNBを変更しないMeNB間ハンドオーバに適しており、FFS2を削除すべきである。
【0352】
提案3:SeNB解放プロシージャ及びUEコンテキスト解放プロシージャが必要であり、FFS3を削除すべきである。
【0353】
FFS4:データ転送(Data forwarding)はさらに一般的に考慮される必要があるか;省略するか又は直接データ転送であるか?
データ転送は、スプリットベアラ及びSCGベアラのオプションについて個別に分析すべきである。
【0354】
−スプリットベアラオプション
ULについては、UEがソースMeNBにより設定された、PDCPでUL PDCP PDUを暗号化(cipher)する限りは、SeNBは、X2−Uの上でソースMeNBにUL PDCP PDUを転送すべきである。MeNB間ハンドオーバ時には、ソースMeNBで復号(decipher)されたPDCP SDUは、ターゲットMeNBに転送すべきである。UEの再設定の後、SeNBは、X2−U上でターゲットMeNBにPDCP PDUの転送を開始し、それはターゲットMeNBのものと同じ暗号化キーで暗号化される。よって、SeNBは、UEに設定された暗号化キーに応じて、適切なMeNBにUL PDCP PDUを転送すべきである。そのため、SeNBからターゲットMeNBへの直接データ転送は、ULには適用されない。
【0355】
ULと同じように、DLは、PDCP PDUの暗号化キーを考慮すべきである。すなわち、ソース/ターゲットMeNBは、UEの再設定の前/後に、PDCP PDUを提供すべきである。よって、ソースMeNBは、MeNB間ハンドオーバ時にターゲットMeNBへのPDCP SDUを転送すべきである。そのため、SeNBからターゲットMeNBへの直接データ転送は、DLには適用されない。
【0356】
結論として、スプリットベアラは、直接データ転送及びデータ転送の省略を適用することができない。
【0357】
考察2:スプリットベアラは、直接データ転送及びデータ転送の省略のどちらも適用することができない。
【0358】
−SCGベアラオプション
スプリットベアラ場合とは異なり、X2−UはSCGベアラオプションで想定されていない。すなわち、PDCP PDU転送がないため、データ転送おける暗号化キーの問題はない。SCGベアラは、MeNB間ハンドオーバの間、SeNBとS−GWとの間のGTPトンネルを保持することができるので、DL PDCP SDUは、MeNBハンドオーバ後に適用することができ、UL PDCP SDUも同様にすることができる。したがって、MeNB間ハンドオーバに応じて、SCGベアラは、SeNBからソースMeNBへのデータ転送、及びターゲットMeNBからSeNBへのデータ転送を省略することができる。
【0359】
また、ベアラタイプの変更のサポートを想定すると、ベアラタイプ情報がeNB間で交換される限りは、直接データ転送が可能である。MCGベアラからSCGベアラへのケースでは、ソースMeNBは、SeNBにPDCP SDUの直接データ転送を行うことができる。MCGベアラからSCGベアラのケースでは、SeNBは、ターゲットMeNBに直接データ転送を実行することができる。
【0360】
結論として、SCGベアラはデータ転送を省略することができる。また、MCGベアラとSCGベアラとの間のベアラタイプ変更時に、対応するベアラ情報がeNB間で交換される限りは、直接データ転送を適用することが可能である。情報交換の詳細はWI段階に任される。
【0361】
考察3:ベアラタイプ変更が発生していない場合、SCGベアラは、データ転送を省略することができる。
【0362】
提案4:SCGベアラは、ベアラタイプ変更時に直接データ転送を行うことができる。詳細はWIフェーズに委ね、FFS4を削除すべきである。
【0363】
FFS5:ベアラタイプの変更
ベアラタイプの変更が、ベアラ関連のIEの取り扱いに影響を与えるかどうかを検討すべきであり、それらは、ハンドオーバ要求中のE−RABs To Be Setup List及びRRC Contextと、ハンドオーバ肯定応答中のE−RABs Admitted List、E−RABs Not Admitted List、及びTarget eNB To Source eNB Transparent Containerにマッピングされる。また、また、パス切り替え要求(Path Switch Request)も考慮されるべきである。一方、非ベアラ関連のIE、例えばUE−AMBRに影響があってはならない。
【0364】
−X2 AP中のRRCコンテナ
ハンドオーバ中のベアラタイプ変更を伴うRRC再設定については、RRCコンテキストに比べて、ターゲットeNBからソースeNBへの透過的なコンテナ(Target eNB to Source eNB Transparent Container)に、変更されたベアラ設定を含むことが必要である。最終的なRRCメッセージを作成するために、MeNBは、制限なしにこれらのIEを使用することができる。現在の仕様によれば、ハンドオーバ中にベアラのタイプを変更するのには制限はない。よって、問題はRRCコンテナにはない。
【0365】
−X2 APにおけるE−RAB関連リスト
ベアラタイプの変更にかかわらず、ハンドオーバ要求中のE−RABs To Be Setup Listは、ベアラタイプ(すなわち、SCG又はスプリット)を含む必要がある。ベアラタイプの変更がハンドオーバ準備プロシージャ中に発生した場合でも、MCGベアラに対応する少なくとも1つの非GBR E−RABがターゲットMeNBに認められる限りは、ハンドオーバ肯定応答が各ベアラタイプ変更をソースMeNBに通知する必要がないかもしれない。
【0366】
考察4:RRCコンテナ及びE−RAB関連リストを考慮すると、ベアラタイプの変更についてリリース12のハンドオーバ準備プロシージャには問題はない。
【0367】
−X2 APでのGTP TEIDの取り扱い
ベアラタイプの変更を想定した場合、データ転送アドレスの取り扱いが各シナリオについて考慮されるべきである。MeNB間ハンドオーバ中にSeNB追加準備を使用することをこの分析で想定する。なお、すでにリリース12においてハンドオーバ中にSCG/スプリットからMCGに全てのベアラのベアラタイプの変更が許可されている(すなわち、MeNBからeNBへの変更プロシージャ)。
【0368】
SCGベアラからMCGベアラへ
MeNB間ハンドオーバ中にSCGからMCGベアラへのベアラタイプ変更の一部を実行するには、ターゲットMeNBは、変更されるベアラをSeNB追加要求中に追加する必要はないかもしれない(すなわち、ターゲットMeNBは、保持するベアラをSeNB追加要求のE−RAB To Be Added IEに含めるだけである)。MCGベアラに変更されるSCGベアラはソースMeNBで自律的に解放されるかである。そして、ターゲットは、エンドポイントを所有するために、パス切り替え要求によって、SCGベアラのGTP−TEIDの変更をMMEに要求すべきである。
【0369】
スプリットベアラからMCGベアラへ
スプリットベアラからMCGベアラへのベアラタイプ変更の場合は、スプリットベアラを含むS1−Uのための全てのGTP−TEIDはMeNBで終端されている。よって、ターゲットMeNBは従来のX2ハンドオーバプロシージャに従う、すなわち、FFS4で説明したように直接データ転送の懸念がなく、MMEへのパス切り替え要求を行う。
【0370】
MCGベアラからSCGベアラ又はスプリットベアラへ
MCGベアラからSCG/スプリットベアラへのベアラタイプの変更に関しては、このSIで議論されているSeNB追加を伴うハンドオーバと同じプロシージャとして考えられる。
【0371】
データ転送(すなわち、直接データ転送)の最適化として、GTP TEIDの取り扱いを最適化する余地がある。例えば、SeNBからMCGベアラへのケースでは、SeNBからターゲットMeNBへのデータ転送は、SeNBが、直接データ転送のためにMeNBのGTP TEIDを知っている必要がある。もしあれば(例えば、SeNB追加要求又はSeNB解放要求が直接データ転送アドレスを含む)、WI段階でいくつかの最適化が必要となり得る。
【0372】
考察5:GTP TEIDの取り扱いの観点からは、直接データ転送のないベアラタイプの変更はSI段階で実現可能である。
【0373】
−S1 APでのパス切り替え要求
ベアラタイプの変更を想定した場合、パス切り替え要求プロシージャが考慮されるべきである。
【0374】
MCGベアラからSCGベアラへ
ベアラタイプの変更の場合には、パス切り替え要求メッセージは、SeNB及びターゲットMeNBの各トランスポート層アドレス(Transport Layer address)IEを含み得る。このような現象は、通常のハンドオーバで想定されておらず、リリース12では、パス切り替え要求メッセージは、ターゲットMeNBのみのトランスポート層アドレスを常に含むことを意味する。MMEは、このようなケースを想定していない可能性があるため、MMEは、このような現象を、メッセージ内の暗黙的又は明示的な指示によって、ベアラタイプの変更を有するMeNB間ハンドオーバを示すと理解する必要があり得る。しかし、それはWI段階で議論されるべきである。
【0375】
SCGベアラからMCGベアラへ
一方、SCGベアラからMCGベアラへのケースでは、パス切り替え要求メッセージは、ターゲットMeNBのみのトランスポート層アドレスIEが含まれる。これは、通常のハンドオーバの場合と同様である。よって、何も問題はありません。
【0376】
スプリット/MCGからMCG/スプリットベアラへ
この場合、スプリットベアラ又はMCGベアラに拘らず、S1−UベアラはMeNBで終端されているので、ターゲットMeNBは通常のハンドオーバのようなパス切り替え要求プロシージャを実行する。
【0377】
考察6:MCGベアラからSCGベアラへのケースについて不明確な点があるが、それはSI段階に任せて、ベアラタイプの変更はSI段階で実現可能である。
【0378】
なお、直接ベアラタイプ変更、すなわち、スプリット/SCGベアラからSCG/スプリットベアラへは、RAN2仕様でサポートされていない。
【0379】
ほとんど全てのリリース12のプロシージャ及び情報要素は、基本的にベアラタイプの変更で良好に機能するが、リリース13のためのいくつかのアップデートがWI段階で考慮されるべきである。さらに、ベアラタイプの変更は、例えばRRMに基づいて、ターゲットMeNBに二重接続設定のいくつかの柔軟性を可能にすることが期待される。したがって、RAN3は、MeNB間ハンドオーバ中のベアラタイプの変更が可能であると結論づけるである。
【0380】
提案5:考察4から6を考慮して、ベアラタイプの変更はMeNB間ハンドオーバ中に実現可能であり、FFS5を削除すべきである。
【0381】
[付記2]
(はじめに)
この付記では、SeNBを変更しないMeNB間ハンドオーバのための直接データ転送について説明する。
【0382】
(直接データ転送)
直接データ転送は2つのベアラタイプ変更時に考慮される。
【0383】
1.SCGからMCGへの変更(すなわち、SeNBからターゲットMeNBへの直接データ転送)
2.MCGからSCGへの変更(すなわち、ソースMeNBからSeNBへの直接データ転送)
以下では、両方のベアラタイプの変更のための直接データ転送を導入するための潜在的な仕様への影響を分析する。
【0384】
(SCGからMCGへの変更)
図24は、ベアラタイプの変更(SCGからMCGへ)を伴う直接データ転送を示す。
【0385】
SCGからMCGへのベアラタイプの変更については、ターゲットMeNBのデータ転送アドレス(すなわち、GTPトンネルエンドポイントIE)がSeNBに提供されるべきである。ターゲットMeNBは、対応するSCGベアラのデータ転送アドレスをHANDOVER REQUEST ACKNOWLEDGE(ステップ4)に含めるべきである。そして、ソースMeNBは、受信したアドレスをSeNB解放要求(ステップ5)に含めるべきである。仕様への影響の観点から、GTPトンネルエンドポイントIEが既にメッセージに含まれているので、これらのメッセージは、アドレスを転送するために適用されるであろう。
【0386】
図24において、ステップ1〜3はTRと同様である。
【0387】
ステップ4.ターゲットMeNBは、変更するSCGベアラのための自身のGTPトンネルエンドポイントをHANDOVER REQUEST ACKNOWLEDGEに含める。
【0388】
ステップ5.ソースMeNBは、ターゲットMeNBのGTPトンネルエンドポイントを含むSeNB解放要求を送信する。
【0389】
提案1:SeNBからターゲットMeNBへの直接データ転送については、ターゲットMeNBのGTPトンネルエンドポイントは、HANDOVER REQUEST ACKNOWLEDGE及びSENB RELEASE REQUESTで、ソースMeNBを介してSeNBに伝達されるべきである。
【0390】
SCGからMCGへのベアラタイプの変更の問題
−ソースMeNBの観点
ベアラタイプの変更及び直接データ転送が行われるかどうかはターゲットMeNBによって決定されるべきである。しかし、ソースMeNBは決定を知ることはできない。言い換えれば、ソースMeNBは、SeNB解放要求に自身のGTPトンネルエンドポイント又はターゲットMeNBのGTPトンネルエンドポイントを含めるべきかどうかを理解することはできない。それを理解するには、2つの可能な選択肢がある。
【0391】
ALT1.ソースMeNBはRRCコンテナを把握し、ベアラタイプ変更を行うかどうかを理解する。
【0392】
ALT2.HANDOVER REQUEST ACKNOWLEDGEは、直接データ転送が行われるかどうかを示すために明示的なIEを含む。
【0393】
ALT1は、RAN3仕様に与える影響が小さいが、レイヤの独立性を壊し、ソースMeNBの負担が大きい。したがって、HANDOVER REQUEST ACKNOWLEDGEに明示的インジケータを追加することが望ましい。
【0394】
提案2:HANDOVER REQUEST ACKNOWLEDGEは、直接データ転送が行われるかどうかを示すために追加のIEを含めるべきである。
【0395】
−SeNBの観点
現在の仕様によると、SNステータス転送(SN STATUS TRANSFER)及びデータ転送の方向を揃える必要がある。言い換えると、SeNBは、直接データ転送が適用されるかどうかを理解する必要がある。したがって、直接データ転送をSeNBに知らせるためには、SeNB解放要求に明示的なインジケータを追加することが望ましい。
【0396】
提案3:SeNB解放要求は、直接データ転送が行われるかどうかを示すために追加のIEを含むべきである。
【0397】
(MCGからSCGへの変更)
図25は、ベアラタイプの変更(MCGからSCGへ)を伴う直接データ転送を示す。
【0398】
MCGからSCGへのベアラタイプ変更の準備として、SeNBは、新しいSCGベアラの確立のための追加のE−RABが要求されるべきである。ターゲットMeNBは、SeNB追加要求(ステップ2)において追加のE−RABを要求すると想定することができる。したがって、SeNBは、SENB ADDITION REQUEST ACKNOWLEDGE(ステップ3)に自身のデータ転送アドレスを含める。
【0399】
MCGからSCGへの変更の場合における間接データ転送と直接データ転送との違いは、ソースMeNBが、SeNBのデータ転送アドレスを通知しなければならないということである。これはHANDOVER REQUEST ACKNOWLEDGE(ステップ4)にSeNBのGTPトンネルエンドポイントを含めることによって容易に達成される。
【0400】
図25において、ステップ1はTRと同様である。
【0401】
ステップ2.ターゲットMeNBは、SeNB追加要求(SENB ADDITION REQUEST)において追加SCGベアラを要求する。
【0402】
ステップ3.SeNBは、SeNB追加要求肯定応答(SENB ADDITION REQUEST ACKNOWLEDGE)に、追加ベアラのためのGTPトンネルエンドポイントを含める。
【0403】
ステップ4.ターゲットMeNBは、ハンドオーバ要求肯定応答(HANDOVER REQUEST ACKNOWLEDGE)に、SeNBのGTPトンネルエンドポイントを含める。
【0404】
提案4:ソースMeNBからSeNBへの直接データ転送については、SeNBのGTPトンネルエンドポイントは、HANDOVER REQUEST ACKNOWLEDGEで、ターゲットMeNBを介してソースMeNBに伝達されるべきである。
【0405】
[付記3]
成功する動作(Successful Operation)
図26は、ハンドオーバ準備が成功する動作を示す。
【0406】
ソースeNBは、ターゲットeNBにHANDOVER REQUESTメッセージを送信することによりプロシージャを開始する。ソースeNBは、HANDOVER REQUESTメッセージを送信すると、タイマTRELOCprepを開始しなければならない。
【0407】
E−RAB Level QoS Parameters IEに含まれるAllocation and Retention Priority IEの値に応じたリソースの割り当ては、TS36.413におけるE−RABのセットアッププロシージャに記載された原則に従わなければならない。
【0408】
ソースeNBはGUMMEI IEにソースMMEノードに対応する任意のGUMMEIを含めることができる。
【0409】
要求された非GBR E−RABの少なくとも1つが、ターゲットセルID IEで示されるセルに入ることを許可された場合、ターゲットeNBは、必要なリソースを確保し、ソースeNBにHANDOVER REQUEST ACKNOWLEDGEメッセージを送信しなければならない。ターゲットeNBは、E−RABs Admitted List IEに、ターゲットセルでリソースが準備されたE−RABを含めなければならない。ターゲットeNBは、E−RABs Not Admitted List IEに、承認しなかったE−RABを適切な原因値(cause value)と共に含めなければならない。
【0410】
ターゲットeNBは、HANDOVER REQUESTメッセージの受信時に:
−UEコンテキスト情報IE中のUE Security Capabilities IE及びAS Security Information IE中の情報を用いて、UEとターゲットeNBとの間のASセキュリティの関係の設定を準備する。
【0411】
ソースeNBは、下りリンクデータの転送を行うことを提案する各E−RABのために、ハンドオーバ要求メッセージのE−RABs To be Setup Item IE内に、DL Forwarding IEを含めなければならない。承認することを決定した各E−RABのために、ターゲットeNBは、下りリンクデータの提案された転送を受け入れることを示すために、ハンドオーバ要求肯定応答メッセージのE−RABs Admitted Item IE内に、DL GTP Tunnel Endpoint IEを含める。このGTPトンネルエンドポイントは、実装の選択に応じて、パス切り替え要求メッセージ(TS36.413を参照)のE−RAB To Be Switched in Downlink List IE中のGTP TEID IEと異なる場合がある。
【0412】
E−RABs Admitted List IE中の各ベアラについて、ターゲットeNBは、そのベアラのために実行される上りリンクパケットのデータ転送を要求することを示すために、UL GTPトンネルエンドポイントIEを含めることができる。
【0413】
ソースeNBは、ハンドオーバ要求肯定応答を受信すると、タイマTRELOCprepを停止し、タイマTX2RELOCoverallを開始し、ハンドオーバ準備プロシージャを終了しなければならない。ソースeNBは、そのX2のUEに関連するシグナリングのための準備されたハンドオーバを持つように定義される。
【0414】
ハンドオーバ制限リストIEがある場合、ハンドオーバ要求メッセージに含まれる場合、ターゲットeNBは、
−UEコンテキストにおけるハンドオーバ制限リストIEにおいて受信された情報を格納する。
【0415】
−二重接続動作中に適切なSCGを選択するためにこの情報を使用する。
【0416】
二重接続
MeNB間ハンドオーバ中に、ベアラオプションがSCGベアラに変更される各E−RABについて、ターゲットMeNBは、SENB ADDITION REQUEST ACKNOWLEDGEメッセージから受信したSeNBのDL Forwarding GTP Tunnel Endpoint / UL Forwarding GTP Tunnel Endpoint IEを、HANDOVER REQUEST ACKNOWLEDGEメッセージ中のUL GTP Tunnel Endpoint /DL GTP Tunnel Endpoint IEに設定し、Direct Data Forwarding Indicator IEを「direct data forwarding」に設定する。
【0417】
成功する動作(Successful Operation)
図27は、MeNB始動のSeNB解放が成功する動作を示す。
【0418】
MeNBは、SeNB解放要求(SENB RELEASE REQUEST)メッセージを送信することにより、プロシージャを開始する。SeNB解放要求メッセージを受信すると、SeNBは、UEにユーザデータの提供を停止しなければならない。SeNB UE X2AP ID IEがSeNBから取得された場合、それが含まれなければならない。MeNBは、原因(Cause)IE内で適切な情報を提供することができる。
【0419】
SeNBでベアラコンテキストがSCGベアラオプションで設定されていた場合、MeNBが上りリンク/下りリンクデータの転送を要求した各SCGベアラについて、MeNBは、そのSCGベアラのための上りリンク/下りリンクパケットのデータ転送をSeNBが実行する必要があることを示すために、SeNB解放要求メッセージのE−RABs To Be Released Item IE内に、UL Forwarding GTP Tunnel Endpoint/ DL Forwarding GTP Tunnel Endpoint IEを含める。
【0420】
SeNBでベアラコンテキストがスプリットベアラオプションで設定されていた場合、MeNBが下りリンクデータの転送を要求した各SCGベアラについて、MeNBは、そのスプリットベアラのための下りリンクパケットのデータ転送をSeNBが実行する必要があることを示すために、SeNB解放要求メッセージのE−RABs To Be Released Item IE内に、DL Forwarding GTP Tunnel Endpoint IEを含める。
【0421】
HANDOVER REQUEST ACKNOWLEDGEのE−RAB Admitted Item IE中のDirect Data Forwarding Indicator IEが「direct data forwarding」に設定された各E−RABについて、ソースMeNBは、SENB ADDITION REQUEST ACKNOWLEDGEメッセージから受信したMeNBのUL GTP Tunnel Endpoint/ DL GTP Tunnel Endpoint IEを、SENB RELEASE REQUESTメッセージのUL Forwarding GTP Tunnel Endpoint/ DL Forwarding GTP Tunnel Endpoint IEに設定し、E−RAB To Be Released Item IE中のDirect Data Forwarding Indicator IEを「direct data forwarding」に設定する。
【0422】
(ハンドオーバ要求肯定応答)
このメッセージは、ターゲットで準備されたリソースに関してソースeNBに通知するために、ターゲットeNBによって送信される。
【0423】
方向:ターゲットeNBからソースeNBへ。
【0424】
【表7】
【0425】
(SeNB解放要求)
このメッセージは、リソースの解放を要求するためにMeNBによってSeNBに送信される。
【0426】
方向:MeNBからSeNBへ。
【0427】
【表8】
【0428】
(直接データ転送インジケータ)
直接データ転送インジケータIEは、E−RABに対応する直接データ転送が要求されることを示す。
【0429】
【表9】
【0430】
[相互参照]
米国仮出願62/145755号(2015年4月10日出願)、米国仮出願62/222877号(2015年9月24日出願)、米国仮出願62/251890号(2015年11月6日出願)、及び米国仮出願62/251907号(2015年11月6日出願)の全内容が参照により本発明に組み込まれている。
図1
図2
図3
図4
図5
図6
図7
図8
図9
図10
図11
図12
図13
図14
図15
図16
図17
図18
図19
図20
図21
図22
図23
図24
図25
図26
図27

【手続補正書】
【提出日】2017年10月5日
【手続補正1】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項1】
二重接続方式によってソースマスタ基地局及びセカンダリ基地局に接続しているユーザ端末を、前記ソースマスタ基地局からターゲットマスタ基地局へハンドオーバするハンドオーバ手順を制御するための方法であって、
前記ソースマスタ基地局から前記ターゲットマスタ基地局に対してハンドオーバ要求を送信し、
前記ターゲットマスタ基地局から、前記セカンダリ基地局が維持されることを示す情報を含むハンドオーバ要求応答を前記ソースマスタ基地局が受信し、
前記ハンドオーバ要求応答の受信後、前記ユーザ端末のベアラを、前記ソースマスタ基地局を介して確立するMCGベアラから前記セカンダリ基地局を介して確立するSCGベアラに変更する場合に、前記ソースマスタ基地局から前記セカンダリ基地局に対してダイレクトデータフォワーディングを行う、
方法。
【請求項2】
前記セカンダリ基地局が維持されることを示す情報を含む前記ハンドオーバ要求応答を受信した場合でも、前記ソースマスタ基地局から前記セカンダリ基地局にセカンダリ基地局解放要求を送信する、
請求項1に記載の方法。
【請求項3】
二重接続方式によってソースマスタ基地局及びセカンダリ基地局に接続しているユーザ端末を、前記ソースマスタ基地局からターゲットマスタ基地局へハンドオーバするハンドオーバ手順において、前記ソースマスタ基地局として動作する基地局であって、
前記ターゲットマスタ基地局に対してハンドオーバ要求を送信する送信部と、
前記ターゲットマスタ基地局から、前記セカンダリ基地局が維持されることを示す情報を含むハンドオーバ要求応答を受信する受信部と、
前記ハンドオーバ要求応答の受信後、前記ユーザ端末のベアラを、前記ソースマスタ基地局を介して確立するMCGベアラから前記セカンダリ基地局を介して確立するSCGベアラに変更する場合に、前記ソースマスタ基地局から前記セカンダリ基地局に対してダイレクトデータフォワーディングを行う制御部とを備える、
基地局。
【国際調査報告】