特許 7275292 ソースアクセスノード、ターゲットアクセスノード、および拡張ハンドオーバの方法

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2023-05-09

(45)【発行日】2023-05-17

(54)【発明の名称】ソースアクセスノード、ターゲットアクセスノード、および拡張ハンドオーバの方法

(51)【国際特許分類】

   H04W 36/18 20090101AFI20230510BHJP

   H04W 76/18 20180101ALI20230510BHJP

   H04W 92/20 20090101ALI20230510BHJP

【ＦＩ】

H04W36/18

H04W76/18

H04W92/20

【請求項の数】 23

(21)【出願番号】P 2021547534

(86)(22)【出願日】2020-02-13

(65)【公表番号】

(43)【公表日】2022-04-05

(86)【国際出願番号】 SE2020050156

(87)【国際公開番号】W WO2020167230

(87)【国際公開日】2020-08-20

【審査請求日】2021-11-01

(31)【優先権主張番号】62/805,466

(32)【優先日】2019-02-14

(33)【優先権主張国・地域又は機関】US

(73)【特許権者】

【識別番号】598036300

【氏名又は名称】テレフオンアクチーボラゲット エルエム エリクソン（パブル）

(74)【代理人】

【識別番号】100109726

【弁理士】

【氏名又は名称】園田 吉隆

(74)【代理人】

【識別番号】100161470

【弁理士】

【氏名又は名称】冨樫 義孝

(74)【代理人】

【識別番号】100194294

【弁理士】

【氏名又は名称】石岡 利康

(74)【代理人】

【識別番号】100194320

【弁理士】

【氏名又は名称】藤井 亮

(74)【代理人】

【識別番号】100150670

【弁理士】

【氏名又は名称】小梶 晴美

(72)【発明者】

【氏名】ミュラー， ジュリアン

(72)【発明者】

【氏名】ペーション， クラース－ヨーラン

(72)【発明者】

【氏名】ワレンティン， ポントス

【審査官】篠田 享佑

(56)【参考文献】

【文献】国際公開第２０１８／０３１１１０（ＷＯ，Ａ１）

【文献】Nokia, Nokia Shanghai Bell，Report from [104#61][LTE/feMOB] Solution directions for minimizing user data interruption for UL/DL (Nokia)[online]，3GPP TSG RAN WG2 #105 R2-1900619，Internet<URL:http://www.3gpp.org/ftp/tsg_ran/WG2_RL2/TSGR2_105/Docs/R2-1900619.zip>，2019年02月13日

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｈ０４Ｂ ７／２４－ ７／２６

Ｈ０４Ｗ ４／００－９９／００

３ＧＰＰ ＴＳＧ ＲＡＮ ＷＧ１－４

ＳＡ ＷＧ１－４

ＣＴ ＷＧ１、４

(57)【特許請求の範囲】

【請求項1】

ユーザ機器（ＵＥ）のハンドオーバに関連するソースアクセスノードによって実施される方法であって、
ターゲットアクセスノードに、前記ターゲットアクセスノードが拡張メイク・ビフォア・ブレークハンドオーバを要求する第１の明示的インジケータを含む、最初のハンドオーバ準備メッセージを伝送すること（５０１、５１１）と、
前記要求された拡張メイク・ビフォア・ブレークハンドオーバを許容または拒否する第２の明示的インジケータを含む、ハンドオーバ準備応答メッセージを前記ターゲットアクセスノードから受信すること（５０２、５１２）と、
前記ハンドオーバ準備応答メッセージから、前記拡張メイク・ビフォア・ブレークハンドオーバに関連する前記ターゲットアクセスノードの能力を学習すること（５０３）と、
拡張メイク・ビフォア・ブレークハンドオーバの拒否または非対応を示す前記ハンドオーバ準備応答メッセージを前記ターゲットアクセスノードから受信すると、可能なフォールバックメカニズムを選択すること（５０６、５１３）と、を含む、方法。

【請求項2】

前記要求された拡張メイク・ビフォア・ブレークハンドオーバの失敗または拒否の場合、前記ターゲットアクセスノードに所望のフォールバックを通知すること（５０４）を更に含む、請求項１に記載の方法。

【請求項3】

前記ターゲットアクセスノードの前記能力が、要求された拡張メイク・ビフォア・ブレークハンドオーバの成功応答または失敗応答に基づいて学習される、請求項１に記載の方法。

【請求項4】

前記可能なフォールバックメカニズムを選択すること（５０６）が、前記所望のフォールバックおよび／または前記ターゲットアクセスノードの学習した前記能力を考慮に入れる、請求項２または３に記載の方法。

【請求項5】

前記ソースアクセスノードが、前記ターゲットアクセスノードに前記所望のフォールバックを通知し、拡張メイク・ビフォア・ブレークハンドオーバに対する前記第１の明示的インジケータおよび前記所望のフォールバックメカニズムに対するインジケータが、前記最初のハンドオーバ準備メッセージの単一の情報要素で組み合わされる、請求項２から４のいずれか一項に記載の方法。

【請求項6】

前記第１の明示的インジケータが、ソースからターゲットに伝送される前記最初のハンドオーバ準備メッセージの追加情報として追加される、請求項１から５のいずれか一項に記載の方法。

【請求項7】

前記第１の明示的インジケータが、ソースからターゲットにシグナリングされる無線リソース制御（ＲＲＣ）コンテキストに含まれる、請求項１から６のいずれか一項に記載の方法。

【請求項8】

前記第１の明示的インジケータがハンドオーバ要求メッセージに追加される、請求項１から７のいずれか一項に記載の方法。

【請求項9】

前記可能なおよび／または所望のフォールバックが、レガシーハンドオーバへのフォールバック、リリース１４のメイク・ビフォア・ブレークハンドオーバへのフォールバック、およびハンドオーバ要求の拒否のうち１つもしくは複数を含む、請求項１から８のいずれか一項に記載の方法。

【請求項10】

前記拡張メイク・ビフォア・ブレークハンドオーバ要求の拒否の場合、前記ターゲットアクセスノードからの選択された可能なフォールバックメカニズムの通知を受信すること（５０５）を更に含む、請求項１から９のいずれか一項に記載の方法。

【請求項11】

前記可能なフォールバックメカニズムを選択すること（５０６）が前記通知を考慮に入れる、請求項１０に記載の方法。

【請求項12】

ソースアクセスノードからターゲットアクセスノードへのユーザ機器（ＵＥ）のハンドオーバに関連する前記ターゲットアクセスノードによって実施される方法であって、
拡張メイク・ビフォア・ブレークハンドオーバを要求する前記ソースアクセスノードからの第１の明示的インジケータを含む、最初のハンドオーバ準備メッセージを受信すること（６０１、６１１）と、
前記拡張メイク・ビフォア・ブレークハンドオーバ要求を許容または拒否する第２の明示的インジケータを含むハンドオーバ準備応答メッセージを用いて、前記ソースアクセスノードによって伝送された前記最初のハンドオーバ準備メッセージに応答すること（６０５、６１５）と、を含み、
前記ソースアクセスノードにおいて、前記ハンドオーバ準備応答メッセージから、前記拡張メイク・ビフォア・ブレークハンドオーバに関連する前記ターゲットアクセスノードの能力が学習され、
前記ソースアクセスノードにおいて、前記拡張メイク・ビフォア・ブレークハンドオーバの拒否または非対応を示す前記ハンドオーバ準備応答メッセージを前記ターゲットアクセスノードから受信すると、可能なフォールバックメカニズムが選択される、
方法。

【請求項13】

前記拡張メイク・ビフォア・ブレークハンドオーバの失敗または拒否の場合、可能なフォールバック方法を選択すること（６０３、６１４）と、
前記拡張メイク・ビフォア・ブレークハンドオーバ要求の失敗または拒否の場合、前記ソースアクセスノードに前記選択された可能なフォールバック方法を通知すること（６０４）と、を更に含む、請求項１２に記載の方法。

【請求項14】

前記拡張メイク・ビフォア・ブレークハンドオーバ要求を拒否する第２のインジケータと、選択された可能なフォールバック方法のインジケータとを含む、ハンドオーバ準備応答メッセージを用いて前記ソースアクセスノードに応答する、請求項１３に記載の方法。

【請求項15】

応答することが、明示的な拡張メイク・ビフォア・ブレークハンドオーバインジケータを、前記ソースアクセスノードに転送されるＲＲＣ ＨａｎｄｏｖｅｒＣｏｍｍａｎｄメッセージに挿入することを含む、請求項１２から１４のいずれか一項に記載の方法。

【請求項16】

前記要求された拡張メイク・ビフォア・ブレークハンドオーバの失敗または拒否の場合、前記ソースアクセスノードから所望のフォールバックの通知を受信すること（６０２）を更に含む、請求項１２から１５のいずれか一項に記載の方法。

【請求項17】

可能なフォールバックメカニズムを選択すること（６１３）が前記受信した通知を考慮に入れる、請求項１６に記載の方法。

【請求項18】

少なくとも１つのプロセッサで実行されると、前記少なくとも１つのプロセッサに、前記ソースアクセスノードまたは前記ターゲットアクセスノードそれぞれによって実施されるような、請求項１から１７のいずれか一項に記載の方法を実施させる命令を備える、コンピュータプログラム。

【請求項19】

少なくとも１つのプロセッサで実行されると、前記少なくとも１つのプロセッサに、前記ソースアクセスノードまたは前記ターゲットアクセスノードそれぞれによって実施されるような、請求項１から１７のいずれか一項に記載の方法を実施させる命令を備えるコンピュータプログラムが格納された、コンピュータ可読記憶媒体。

【請求項20】

ユーザ機器（ＵＥ）のハンドオーバを扱うソースアクセスノードであって、
ターゲットアクセスノードに、前記ターゲットアクセスノードが拡張メイク・ビフォア・ブレークハンドオーバを要求する第１の明示的インジケータを含む、最初のハンドオーバ準備メッセージを伝送し、
前記要求された拡張メイク・ビフォア・ブレークハンドオーバを許容または拒否する第２の明示的インジケータを含む、ハンドオーバ準備応答メッセージを前記ターゲットアクセスノードから受信し、
前記ハンドオーバ準備応答メッセージから、前記拡張メイク・ビフォア・ブレークハンドオーバに関連する前記ターゲットアクセスノードの能力を学習し、
拡張メイク・ビフォア・ブレークハンドオーバの拒否または非対応を示す前記ハンドオーバ準備応答メッセージを前記ターゲットアクセスノードから受信すると、可能なフォールバックメカニズムを選択するように設定された、ソースアクセスノード。

【請求項21】

前記ソースアクセスノードが、
請求項１から１１のいずれか一項に記載の方法を実施するように更に設定された、請求項２０に記載のソースアクセスノード。

【請求項22】

ソースアクセスノードからターゲットアクセスノードへのユーザ機器（ＵＥ）のハンドオーバを扱うターゲットアクセスノードであって、
拡張メイク・ビフォア・ブレークハンドオーバを要求する前記ソースアクセスノード（１０３）からの第１の明示的インジケータを含む、最初のハンドオーバ準備メッセージを受信し、
前記拡張メイク・ビフォア・ブレークハンドオーバ要求を許容または拒否する第２の明示的インジケータを含むハンドオーバ準備応答メッセージを用いて、前記ソースアクセスノードによって伝送された前記最初のハンドオーバ準備メッセージに応答するように設定され、
前記ソースアクセスノードにおいて、前記ハンドオーバ準備応答メッセージから、前記拡張メイク・ビフォア・ブレークハンドオーバに関連する前記ターゲットアクセスノードの能力が学習され、
前記ソースアクセスノードにおいて、前記拡張メイク・ビフォア・ブレークハンドオーバの拒否または非対応を示す前記ハンドオーバ準備応答メッセージを前記ターゲットアクセスノードから受信すると、可能なフォールバックメカニズムが選択される、ターゲットアクセスノード。

【請求項23】

前記ターゲットアクセスノードが、
請求項１２から１７のいずれか一項に記載の方法を実施するように更に設定された、請求項２２に記載のターゲットアクセスノード。

【発明の詳細な説明】

【技術分野】

【0001】

本明細書の実施形態は、ソースアクセスノード、ターゲットアクセスノード、およびそれらにおいて実施される無線通信の方法に関する。更に、コンピュータプログラム製品およびコンピュータ可読記憶媒体も本明細書において提供される。特に、本明細書の実施形態は、拡張ハンドオーバのためのネットワークシグナリングに関する。

【背景技術】

【0002】

ユニバーサル移動体通信システム（ＵＭＴＳ）は、第二世代（２Ｇ）の汎欧州移動体通信規格（ＧＳＭ）から進化した、第三世代（３Ｇ）の電気通信ネットワークである。第四世代（４Ｇ）ネットワークまたはロングタームエボリューション（ＬＴＥ）とも呼ばれる、進化型パケットシステム（ＥＰＳ）に関する規格は、第三世代パートナーシッププロジェクト（３ＧＰＰ）内で完成されたものであり、この研究は、例えば、第五世代（５Ｇ）新無線（ＮＲ）ネットワークを規定するため、来る３ＧＰＰリリースにおいて継続している。

【0003】

図１に示される無線通信システムについて考察する。無線通信システムは、１つまたは複数の無線アクセスネットワーク（ＲＡＮ）を備えてもよく、ネットワークノードと呼ばれることもある無線アクセスネットワーク１０は、無線接続１７～１８を使用して１つまたは複数のアクセスノード１３～１４と通信する、ユーザ機器（ＵＥ）１２とともに示されている。アクセスノード１３～１４はコアネットワーク（ＣＮ）ノード１６に接続される。アクセスノード１３～１４は無線アクセスネットワーク１０の一部である。

【0004】

３ＧＰＰ ＴＳ ３６．３００ ｖ．１５．０．０および関連する規格で規定されているものなど、３ＧＰＰ ＥＰＳまたはＬＴＥまたは４Ｇ標準規格に準拠した無線通信システムの場合、アクセスノード１３～１４は一般的に、エボルブドノードＢ（ｅＮＢ）に対応し、コアネットワークノード１６は一般的に、モビリティ管理エンティティ（ＭＭＥ）および／またはサービングゲートウェイ（ＳＧＷ）に対応する。ｅＮＢは、この場合は進化型ユニバーサル地上無線アクセスネットワーク（Ｅ－ＵＴＲＡＮ）である、無線アクセスネットワーク１０の一部であり、ＭＭＥおよびＳＧＷは両方とも進化型パケットコアネットワーク（ＥＰＣ）の一部である。

【0005】

３ＧＰＰ ＴＳ ３８．３００ ｖ．１５．０．０および関連する規格で規定されているものなど、５Ｇ ＮＲ標準規格とも呼ばれる３ＧＰＰ ５Ｇシステム（５ＧＳ）に準拠した無線通信システムの場合、他方では、アクセスノード１３～１４は一般的に、ｇＮＢと示される５ＧノードＢに対応し、コアネットワークノード１６は一般的に、アクセスおよびモビリティ管理機能（ＡＭＦ）ノードならびに／あるいはユーザプレーン機能（ＵＰＦ）ノードのどちらかに対応する。ｇＮＢは、この場合は次世代無線アクセスネットワーク（ＮＧ－ＲＡＮ）である、無線アクセスネットワーク１０の一部であり、ＡＭＦおよびＵＰＦは両方とも５Ｇコアネットワーク（５ＧＣ）の一部である。

【0006】

ＮＲとＬＴＥとの間の高速モビリティに対応し、コアネットワークの変化を回避するため、ｅＮＢとして示されるＬＴＥアクセスノードはまた、インターフェースＮＧ－Ｕおよび／またはＮＧ－Ｃを介して５Ｇ－ＣＮに接続され、Ｘｎインターフェースに対応してもよい。５ＧＣに接続されたｅＮＢは、次世代ｅＮＢ（ｎｇ－ｅＮＢ）と呼ばれ、ＮＧ－ＲＡＮの一部とみなされる。５ＧＣに接続されたＬＴＥは、本明細書ではこれ以上考察されないが、本明細書においてＬＴＥおよびＮＲに関して記載する解決策および特徴のほとんどは、５ＧＣに接続されたＬＴＥにも当てはまることに留意されたい。本明細書では、更なる規定なしにＬＴＥという用語が使用されるとき、ＬＴＥ－ＥＰＣを指す。

【0007】

ＬＴＥおよびＮＲでのＲＲＣ＿ＣＯＮＮＥＣＴＥＤにおけるモビリティ。
ＲＲＣ＿ＣＯＮＮＥＣＴＥＤ状態におけるモビリティは、ハンドオーバとしても知られている。ハンドオーバの目的は、ＵＥ １２を、例えばモビリティによって、ソース無線接続１７を使用するソースアクセスノード１３から、ターゲット無線接続１８を使用するターゲットアクセスノード１４へと移動させることである。ターゲット無線接続１８は、ターゲットアクセスノード１４によって制御されるターゲットセルと関連付けられる。そこで、換言すれば、ハンドオーバの間、ＵＥ １２はソースセルからターゲットセルへと移動する。

【0008】

いくつかの例では、ソースアクセスノード１３およびターゲットアクセスノード１４は、異なるｅＮＢまたはｇＮＢなど、異なるノードである。これらの例は、ノード間ハンドオーバ、ｅＮＢ間ハンドオーバ、またはｇＮＢ間ハンドオーバと呼ばれる。他の例では、ソースアクセスノード１３およびターゲットアクセスノード１４は、同じｅＮＢおよびｇＮＢなど、同じノードである。これらの例は、ノード内ハンドオーバ、ｅＮＢ内ハンドオーバ、またはｇＮＢ内ハンドオーバと呼ばれ、ソースおよびターゲットセルが同じ無線アクセスノードによって制御される事例をカバーする。更に他の例では、ハンドオーバは同じセル内で、したがってそのセルを制御する同じアクセスノード内で実施される。これらの例はセル内ハンドオーバと呼ばれる。

【0009】

したがって、ソースアクセスノード１３およびターゲットアクセスノード１４は、特定のＵＥのハンドオーバ中に所与のアクセスノードによってサーブされる役割を指すことが理解されるべきである。例えば、所与の無線アクセスノードは、あるＵＥのハンドオーバ中はソースアクセスノードとしてサーブし、また異なるＵＥのハンドオーバ中はターゲットアクセスノードとしてサーブしてもよい。また、所与のＵＥのノード内またはセル内ハンドオーバの場合、同じ無線アクセスノードがそのＵＥに対するソースアクセスノードおよびターゲットアクセスノードの両方としてサーブする。

【0010】

Ｅ－ＵＴＲＡＮまたはＮＧ－ＲＡＮにおけるＲＲＣ＿ＣＯＮＮＥＣＥＴＤ ＵＥは、サービングセルおよび近隣セルの測定を実施するように、ネットワークによって設定することができ、ＵＥによって伝送された測定報告に基づいて、近隣セルに対するＵＥのハンドオーバを実施することを決定してもよい。ネットワークは次に、ハンドオーバコマンドメッセージをＵＥに、例えば、ＬＴＥでは、ＲＲＣＣｏｎｎｅｃｔｉｏｎＲｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージをｍｏｂｉｌｉｔｙＣｏｎｔｒｏｌＩｎｆｏｒｍａｔｉｏｎと呼ばれるフィールドとともに、ＮＲでは、ＲＲＣＲｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージをｒｅｃｏｎｆｉｇｕｒａｔｉｏｎＷｉｔｈＳｙｎｃフィールドとともに伝送する。

【0011】

これらの再設定は、実際には、ＥＵＴＲＡ－ＥＰＣの場合はＸ２もしくはＳ１インターフェースを、またはＮＧ－ＲＡＮ－５ＧＣの場合はＸｎもしくはＮＧインターフェースを通じてソースアクセスノードから要求されると、ターゲットアクセスノードによって準備され、ノード間要求で提供されるソースアクセスノードとともにＵＥが有する既存の無線リソース制御（ＲＲＣ）設定を考慮に入れる。ターゲットアクセスノードによって提供される再設定パラメータは、例えば、ＵＥがターゲットアクセスノードにアクセスするのに必要な情報、例えば、ランダムアクセス設定、ターゲットアクセスノードによって割り当てられた新しいセル無線ネットワーク一時識別子（Ｃ－ＲＮＴＩ）、ならびにＵＥが、ターゲットアクセスノードにアクセスする際に新しいセキュリティキーに基づいて、暗号化され整合性が保護されたハンドオーバ完了メッセージをシグナリング無線ベアラ（ＳＲＢ１）で伝送できるように、ＵＥがターゲットアクセスノードに関連付けられた新しいセキュリティキーを計算できるようにするセキュリティパラメータを含む。

【0012】

図２は、例として５Ｇ／ＮＲを使用するハンドオーバ手順の間の、ＵＥと、ソースｇＮＢまたはソースセルとしても知られるソースアクセスノード１３と、ターゲットｇＮＢまたはターゲットセルとしても知られるターゲットアクセスノード１４との間の、シグナリングのフローを示している。

【0013】

図２のシグナリングフローは、５Ｇ／ＮＲのハンドオーバシナリオを示しているが、ＵＥがハンドオーバを実施する場合のいくつかの一般的な共通の原理、またはより一般的な用語では、ＬＴＥおよびＮＲでのＲＲＣ＿ＣＯＮＮＥＣＴＥＤにおけるモビリティがある。

【0014】

ネットワークは、負荷状況、異なるノードのリソース、利用可能周波数など、現在の状況に関する最良の情報を有するので、ＲＲＣ＿ＣＯＮＮＥＣＴＥＤにおけるモビリティはネットワーク制御型である。ネットワークはまた、ネットワークによってサーブされる他のＵＥからの、例えばリソース割当ての観点からの影響を考慮に入れることができる。

【0015】

ネットワークは、ＵＥがターゲットアクセスノード１４にアクセスする前に、そのアクセスノードによって制御されるターゲットセルを準備する。ソースアクセスノード１３は、ターゲットセルにおけるハンドオーバ（ＨＯ）完了メッセージを伝送するときにＵＥによって使用されるシグナリング無線ベアラ１（ＳＲＢ１）設定など、ターゲットセルで使用されるＲＲＣ設定をＵＥに提供する。

【0016】

ＵＥには、ターゲットアクセスノードによって新しいＣ－ＲＮＴＩが提供される。ＵＥ １２は、ＨＯ完了メッセージのメッセージ３（ＭＳＧ３）でＣ－ＲＮＴＩを伝達することによって、自身を識別する。したがって、不具合が起こらない限り、ターゲットアクセスノードとソースアクセスノードとの間にコンテキストの取込みはない。

【0017】

ハンドオーバを加速するため、ネットワークは、ターゲットアクセスノードにどのようにアクセスするかの情報、例えばランダムアクセスチャネル（ＲＡＣＨ）設定をＵＥ １２に提供するので、ＵＥ １２は、ハンドオーバの前にシステム情報（ＳＩ）を獲得する必要はない。

【0018】

ＵＥには、無競合ランダムアクセス（ＣＦＲＡ）リソースが提供されてもよく、即ちその場合、ターゲットアクセスノード１４はＭＳＧ１のプリアンブルからＵＥを識別する。原理は、ハンドオーバ手順をネットワークの事前割当てされたリソースによって常に最適化することができるというものである。

【0019】

セキュリティは、ＵＥがターゲットアクセスノードによって制御されるターゲットセルにアクセスする前に準備され、即ち、暗号化され整合性が保護されたＨＯ完了メッセージを、ＬＴＥの場合はＲＲＣ接続再設定完了メッセージを伝送する前に、ＵＥをターゲットアクセスノードによって検証できるように、キーをリフレッシュしなければならない。

【0020】

完全再設定およびデルタ再設定の両方に対応しているので、ＨＯコマンドを最小限にすることができる。

【0021】

メイク・ビフォア・ブレーク Ｒｅｌ－１４
ハンドオーバ中断時間は、一般的に、ＵＥがソースアクセスノード１３（ｅＮＢまたはｇＮＢ）との送受信を停止してから、ターゲットアクセスノード１４（ｅＮＢまたはｇＮＢ）がＵＥ １２との送受信を再開するまでの時間として定義される。

【0022】

ＬＴＥ プレＲｅｌ－１４では、３ＧＰＰ ＴＲ ３６．８８１ ｖ．１４．０．０にしたがって、ハンドオーバ中断時間は少なくとも４５ｍｓである。ＬＴＥおよびＮＲでは、それ以来、ハンドオーバ中断時間を減少させる異なる解決策が検討されてきた。例えば、低レイテンシに対する新しいサービス要件、例えば、短い中断時間が保証されるべき、空中、産業用自動化、産業用制御によって、改善策が推進される。

【0023】

かかる改善策の一例として、ハンドオーバ中断時間を短縮してできるだけ０ｍｓに近付ける目的で、メイク・ビフォア・ブレーク（ＭＢＢ）がＬＴＥ Ｒｅｌ－１４に導入された。図３は、ＬＴＥ Ｒｅｌ－１４におけるメイク・ビフォア・ブレークのシグナリングを示している。

【0024】

ＬＴＥ Ｒｅｌ－１４に導入されるようなＭＢＢハンドオーバ手順は、ＵＥが媒体アクセス制御（ＭＡＣ）をリセットし、ソースセルのＨＯコマンドメッセージである、ｍｏｂｉｌｉｔｙＣｏｎｔｒｏｌＩｎｆｏを有するＲＲＣＣｏｎｎｅｃｔｉｏｎＲｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージを受信する際に、パケットデータコンバージェンスプロトコル（ＰＤＣＰ）を再確立する、標準的なハンドオーバ手順とは異なり、ＵＥがソースセルから分断される前にターゲットセルに接続する、ハンドオーバメカニズムを指す。ＲＲＣＣｏｎｎｅｃｔｉｏｎＲｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージのｍｏｂｉｌｉｔｙＣｏｎｔｒｏｌＩｎｆｏは、ＵＥにソースセルへの接続を保持するように命令する情報要素（ＩＥ）ｍａｋｅＢｅｆｏｒｅＢｒｅａｋを含む。３ＧＰＰ ＴＳ ３６．３３１ ｖ．１５．０．０による。

【0025】

ｍａｋｅＢｅｆｏｒｅＢｒａｅｋ（ＭＢＢ）情報要素（ＩＥ）
この情報要素は、物理的ランダムアクセスチャネル（ＰＲＡＣＨ）を通してターゲットの周波数内プライマリセル（ＰＣｅｌｌ）への第１の送信を実施するか、またはｒａｃｈ－Ｓｋｉｐが設定された状態でターゲットの周波数内ＰＣｅｌｌへの最初の物理アップリンク共有チャネル（ＰＵＳＣＨ）送信を実施する前、ＵＥがソースセルとのアップリンク送信および／またはダウンリンク受信を継続すべきであることを示す。

【0026】

注記１ａ：これは、ｍａｋｅＢｅｆｏｒｅＢｒｅａｋが設定される場合、ＴＳ ３６．１３３ ｖ１６．０．０に規定されるように、ソースセルとのアップリンク送信および／またはダウンリンク受信を停止して、ターゲットセルに対する接続の再調整を開始するときの、ＵＥに依存した実現例である。

【0027】

ＭＢＢの解決策では、ｍａｋｅＢｅｆｏｒｅＢｒｅａｋ ＩＥがｍｏｂｉｌｉｔｙＣｏｎｔｒｏｌＩｎｆｏに存在する、ＲＲＣＣｏｎｎｅｃｔｉｏｎＲｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージの受信後、ＵＥがターゲットセルの最初のアップリンク送信を実行するまで、ソースセルへの接続が維持され、即ち、ＵＥがターゲットセルでランダムアクセスを実施するまで、ＭＡＣおよびＰＤＣＰリセットがＵＥにおいて遅延される。これは、ソースセルとのアップリンク送信／ダウンリンク受信を停止して、ターゲットセルに対する接続の再調整を開始するときの、ＵＥに依存した実現例である。

【0028】

ＬＴＥ Ｒｅｌ－１４ ｖ．１４．０．０（３ＧＰＰ ＴＳ ３６．３００およびＴＳ ３６．３３１）に規定されるようなＭＢＢは、いくつかの既知の制限を有する。ＭＢＢ、およびＲＡＣＨなしのハンドオーバなどの他の実現例が組み合わされる場合であっても、～０ｍｓのハンドオーバ中断時間に達することは依然として不可能である。Ｒｅｌ－１４のＭＢＢは、単一の送受信（Ｔｘ／Ｒｘ）チェーンを有するＵＥ向けに設計され、つまり、実際のＭＢＢは周波数内ハンドオーバにしか対応しないことを意味する。周波数内ハンドオーバのシナリオでは、単一ＲｘのＵＥは、ターゲットセルおよびソースセル両方からＤＬデータを受信することができるが、単一ＴｘのＵＥは両方のセルに同時に送信することができないであろう。このように、ＭＢＢ Ｒｅｌ－１４では、ＵＥは第１のＵＬ送信でソースセルへの接続を解除することになる。これは、ＵＥがＲＡＣＨプリアンブルを送信するとき、またはＲＡＣＨなしのＨＯが設定された場合、ＨＯ完了メッセージを送信するときに起こる。

【0029】

結果として、ＵＥは、ターゲットセルとの接続がパケット送信および／または受信の準備ができる前に、ソースセルとの接続を解除する。

【0030】

拡張メイク・ビフォア・ブレーク
ＬＴＥおよびＮＲにおけるモビリティ拡張のための２つの新しい作業項目が、３ＧＰＰのリリース１６で始まっている。作業項目の主な目的は、ハンドオーバにおける堅牢性を改善し、ハンドオーバの中断時間を更に減少させることである。

【0031】

ＬＴＥ Ｒｅｌ－１４のメイク・ビフォア・ブレークハンドオーバに対する改善策は、過去に提案されている。これらの改善策のいくつかは、二重Ｔｘ／Ｒｘ無線チェーンを有するＵＥを利用するものであり、かかるＵＥは、二重の無線送信機および受信機と、関連する二重のユーザプレーンプロトコルスタックとを有する。ＬＴＥ Ｒｅｌ－１６に関するかかる提案される改善策の一例が、図４に示されている。

【0032】

拡張ＭＢＢ手順を用いて０ｍｓのＨＯ中断時間に対応する重要なステップは、下記の通りである。

【0033】

ステップ４：ソースｅＮＢは、ハンドオーバコマンド、即ちｍｏｂｉｌｉｔｙＣｏｎｔｒｏｌＩｎｆｏを含むＲＣＣｏｎｎｅｃｔｉｏｎＲｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージを、インジケータを含む、例えば０ｍｓのＨＯ中断を実施する拡張ＭＢＢインジケータを含むインジケータを、ＵＥに伝送する。

【0034】

ステップ５：ソースｅＮＢは、ＤＬ ＰＤＣＰパケットのターゲットｅＮＢへの転送を開始し、ＵＥとの間でＰＤＣＰパケットの送受信を継続する（ステップ７）。ソースｅＮＢから転送されたＤＬ ＰＤＣＰパケットは、ターゲットｅＮＢでバッファリングされる。

【0035】

ステップ６：ＵＥは、ソースセルとの接続を保持しながら、ターゲットセルとの同期を開始する。

【0036】

ステップ７：パケットデータは依然としてソースセルを介して送受信される。

【0037】

ステップ８：ＵＥは、ターゲットセルでのランダムアクセスを実施し、ターゲットｅＮＢはアップリンクリソースをスケジューリングする。

【0038】

ステップ９：ＵＥは、ターゲットセル内のＲＲＣＣｏｎｎｅｃｔｉｏｎＲｅｃｏｎｆｉｇｕｒａｔｉｏｎＣｏｍｐｌｅｔｅメッセージを伝送する。ターゲットｅＮＢはここで、ＰＤＣＰパケットをＵＥに伝送し始めることができ、それと同時に、ソースｅＮＢはＰＤＣＰパケットのＵＥへの伝送を継続してもよい。この時点から、ＵＥはターゲットセルを介してＵＬデータのみを伝送する。ＰＤＣＰ二重検査を用いてターゲットｅＮＢを支援する目的で、ＵＥは、ＲＲＣＣｏｎｎｅｃｔｉｏｎＲｅｃｏｎｆｉｇｕｒａｔｉｏｎＣｏｍｐｌｅｔｅメッセージでＰＤＣＰ状態レポートを伝達してもよい。ＰＤＣＰ状態レポートの情報に基づいて、ターゲットｅＮＢは、ソースセルでＵＥによって受信されなかったＰＤＣＰパケットのみをＵＥに伝送する。

【0039】

ステップ１０：ＵＥは、ソースおよびターゲットセルから受信したＰＤＣＰパケットを区別する。

【0040】

ステップ１１：ソースｅＮＢは、ＵＥとの間の送受信が終わったとき、アップリンク／ダウンリンクＰＤＣＰ ＳＮ受信機／送信機状態を示す、通し番号（ＳＮ）状態転送メッセージをターゲットｅＮＢに伝送する。

【0041】

ステップ１２：ＵＥは、ターゲットセルに対する接続手順が完了すると、ソースセルから分離する。

【0042】

ステップ１３：ターゲットｅＮＢは、ＵＥコンテキストをリリースするようにソースｅＮＢに知らせる。

【0043】

例えば、ターゲットアクセスノードから必要とされる追加のアクションを含む、ＬＴＥの拡張メイク・ビフォア・ブレークに基づいて、ハンドオーバ中断時間を減少させるという３ＧＰＰの考察は、現在ＬＴＥおよびＮＲに関して進行している。

【0044】

モビリティのためのノード間メッセージ。
ＲＲＣノード間メッセージ。
ＮＲおよびＬＴＥにおける、ソースｇＮＢからターゲットｇＮＢ、またはソースｅＮＢからターゲットｅＮＢなど、ソースアクセスノードからターゲットアクセスノードへのハンドオーバなどモビリティの間、２つのノード間メッセージが一般的に使用される。ＨａｎｄｏｖｅｒｐｒｅｐａｒａｔｉｏｎＩｎｆｏｒｍａｔｉｏｎおよびＨａｎｄｏｖｅｒＣｏｍｍａｎｄ。ソースアクセスノードがＵＥをハンドオーバすることを決定すると、ソースアクセスノードは、ハンドオーバ実行時にターゲットセルにアクセスするときにＵＥによって使用される、ＨａｎｄｏｖｅｒＣｏｍｍａｎｄに提供される、ＲＲＣＲｅｃｏｎｆｉｇｕｒａｔｉｏｎをターゲットアクセスノードが準備できるようにする、ＨａｎｄｏｖｅｒｐｒｅｐａｒａｔｉｏｎＩｎｆｏｒｍａｔｉｏｎの何らかの情報をターゲットアクセスノードに提供する。ＴＳ ３８．３３１ ｖ．１５．０．０からの定義を下記に示す。

【0045】

ＨａｎｄｏｖｅｒＰｒｅｐａｒａｔｉｏｎＩｎｆｏｒｍａｔｉｏｎ。
このメッセージは、ＵＥ能力情報を含む、ハンドオーバ準備中にターゲットｇＮＢによって使用されるＮＲ ＲＲＣ情報を伝達するのに使用される。

【0046】

方向：ソースｇＮＢ／ソースＲＡＮからターゲットｇＮＢへ

【0047】

ＨａｎｄｏｖｅｒＣｏｍｍａｎｄ
このメッセージは、ターゲットｇＮＢによって生成されるようなハンドオーバコマンドを伝達するのに使用される。
方向：ターゲットｇＮＢからソースｇＮＢ／ソースＲＡＮへ

【0048】

ハンドオーバ／ＤＣセットアップのためのＸｎノード間メッセージ
ＴＳ ３８．４２０ ｖ．１５．２．０によれば、下記のように定義される「ハンドオーバ準備機能」と呼ばれる機能がある。

【0049】

ハンドオーバ準備機能
この機能は、ターゲットに対する特定のＵＥのハンドオーバを開始するため、ソースおよびターゲットＮＧ－ＲＡＮノード間での情報の交換を可能にする。

【0050】

関連する別の機能は、以下に定義するような「ハンドオーバ取消し」機能である。

【0051】

ハンドオーバ取消し機能
この機能は、準備されたハンドオーバが行われないことを、既に準備されたターゲットＮＧ－ＲＡＮノードに知らせることを可能にする。それにより、ハンドオーバ準備機能の間に割り当てられたリソースを解除することが可能になる。

【0052】

ＴＳ ３８．４２３ ｖ．１５．２．０で、これらの機能が更に詳細に記載されている。セクション８．２．１および８．２．３を参照のこと。

【0053】

既存の解決策、即ちリリース１４のメイク・ビフォア・ブレークでは、レガシーハンドオーバと比較して、ターゲットアクセスノードからの特別なアクションは示唆されていない。拡張メイク・ビフォア・ブレークでは、ターゲットアクセスノードは、決定を、即ち拒否または許容を行い、また、Ｒｅｌ－１４のメイク・ビフォア・ブレークなど、他のタイプのハンドオーバと比較して拡張されたメイク・ビフォア・ブレークでは異なる場合がある、要求されたアクションを開始するために、ソースアクセスノードが拡張メイク・ビフォア・ブレークハンドオーバを要求していることを理解する必要がある。かかるアクションの一例は、ソースアクセスノードからのＳＮ状態転送の送信である。また、異なるベンダーの場合または異なるソフトウェアバージョンの場合など、ソースアクセスノードが対応していても、ターゲットアクセスノードは拡張メイク・ビフォア・ブレークに対応していない場合がある。

【発明の概要】

【0054】

本明細書の実施形態を展開する一部として、以下が特定されている。ソースアクセスノードは、ターゲットアクセスノードが拡張メイク・ビフォア・ブレーク要求を拒否した場合、使用される所望のフォールバックメカニズムをシグナリングしない。これは、ＵＥが新しいノードにハンドオーバされるのに追加の遅延をもたらすことがあり、即ち、ソースノードは、同じまたは別のターゲットノードに向かって新しいハンドオーバ手順を開始するのが必要なことがある。

【0055】

ターゲットアクセスノードが拡張メイク・ビフォア・ブレーク要求を拒否した場合、例えばレガシーハンドオーバに対して、ＵＥが新しいノードにハンドオーバされる際の追加の遅延を回避することができる、ハンドオーバフォールバックメカニズムを選択できない。

【0056】

ターゲットアクセスノードが拡張メイク・ビフォア・ブレークに対応していない場合、ソースアクセスノードはそれを知らないことがあり、したがって既に分離されたＵＥにＤＬパケットを伝送し始めることがある。ソースアクセスノードが、ターゲットアクセスノードが拡張ＭＢＢに対応しているか否かを知るために、ソースアクセスノードは、ターゲットアクセスノードによって準備された透過コンテナに含まれる、例えばＨＡＮＤＯＶＥＲ ＲＥＱＵＥＳＴ ＡＣＫＮＯＷＬＥＤＧＥメッセージに含まれる、ＭｏｂｉｌｉｔｙＣｏｎｔｒｏｌＩｎｆｏの内容を読む必要がある。

【0057】

ターゲットアクセスノードが拡張メイク・ビフォア・ブレークを拒否したかまたはそれに対応していない場合、ソースアクセスノードは、ＵＥが新しいノードにハンドオーバされる際の追加の遅延をもたらす、新しいハンドオーバ準備を開始する必要がある。

【0058】

ターゲットアクセスノードが拡張メイク・ビフォア・ブレーク（ｅＭＢＢ）を拒否したかまたはそれに対応していない場合、ソースアクセスノードはそれら２つの、即ち非対応のｅＭＢＢまたは一時的に拒否されたｅＭＢＢの間で違わないことがあり、したがって、この特徴に対応していないノードに要求を伝送し続けることができる。この挙動を回避するために、ソースアクセスノードを、可能なターゲットアクセスノード能力をすべて有して設定する必要がある。

【0059】

したがって、本明細書の実施形態の目的は、ＵＥのハンドオーバを扱う改善された方法を提供することである。

【0060】

本明細書の実施形態によれば、目的は、ＵＥのハンドオーバに関連するソースアクセスノードによって実施される方法を提供することによって達成されてもよい。ソースアクセスノードはターゲットアクセスノードに、ターゲットアクセスノードが拡張メイク・ビフォア・ブレークハンドオーバを要求する第１の明示的インジケータを含む、最初のハンドオーバ準備メッセージを伝送する。ソースアクセスノードは、要求された拡張メイク・ビフォア・ブレークハンドオーバを許容または拒否する第２の明示的インジケータを含む、ハンドオーバ準備応答メッセージをターゲットアクセスノードから受信する。更に、ソースアクセスノードは、拡張メイク・ビフォア・ブレークハンドオーバの拒否または非対応を示すハンドオーバ準備応答メッセージをターゲットアクセスノードから受信すると、可能なフォールバックメカニズムを選択する。例えば、本明細書では、ＵＥに対する拡張メイク・ビフォア・ブレークハンドオーバを実施する決定を行い、ターゲットアクセスノードを準備し、ターゲットアクセスノードからの応答メッセージで作用する、ソースアクセスノードで実施される方法であって、ターゲットアクセスノードが拡張メイク・ビフォア・ブレークハンドオーバを要求する明示的インジケータを含む、最初のハンドオーバ準備メッセージを伝送することと、拡張メイク・ビフォア・ブレークハンドオーバ要求の失敗または拒否の場合に、ターゲットアクセスノードに所望のフォールバックを通知することと、拡張メイク・ビフォア・ブレークハンドオーバ要求を許容または拒否する明示的インジケータを含む、ハンドオーバ準備応答メッセージをターゲットアクセスノードから受信し処理することと、拡張メイク・ビフォア・ブレークハンドオーバ要求に対するターゲット応答メッセージから、ターゲット拡張メイク・ビフォア・ブレーク能力を学習することと、拡張メイク・ビフォア・ブレークハンドオーバを拒否するかまたはそれに対応していないターゲットアクセスノードを受信すると、可能なフォールバックメカニズム、即ちハンドオーバの代替を選択することと、を含む、方法が開示される。

【0061】

本明細書の実施形態によれば、目的は、ソースアクセスノードからターゲットアクセスノードへのＵＥのハンドオーバに関連する、ターゲットアクセスノードによって実施される方法を提供することによって達成されてもよい。ターゲットアクセスノードは、拡張メイク・ビフォア・ブレークハンドオーバを要求するソースアクセスノードからの第１の明示的インジケータを含む、最初のハンドオーバ準備メッセージを受信し、拡張メイク・ビフォア・ブレークハンドオーバ要求を許容または拒否する第２の明示的インジケータを含むハンドオーバ準備応答メッセージによって、ソースアクセスノードによって伝送された最初のハンドオーバ準備メッセージに応答する。例えば、ターゲットアクセスノードは、ＵＥに対する拡張メイク・ビフォア・ブレークハンドオーバ要求を許容または拒否する決定を行い、ソースアクセスノードを知らせる、方法を実施してもよい。方法は、拡張メイク・ビフォア・ブレークハンドオーバを要求するソースアクセスノードからの明示的インジケータを含む、最初のハンドオーバ準備メッセージを受信し処理することと、拡張メイク・ビフォア・ブレークハンドオーバ要求を許容または拒否する明示的インジケータを含む、ソースアクセスノードによって伝送された最初のハンドオーバ準備メッセージに応答することと、拡張メイク・ビフォア・ブレークハンドオーバの拒否の場合に、可能なフォールバックメカニズムを選択することと、拡張メイク・ビフォア・ブレークハンドオーバ要求の拒否の場合に、所望のフォールバックメカニズムのソースアクセスノードを通知することと、ＵＥに通知するために、明示的な拡張メイク・ビフォア・ブレークハンドオーバインジケータを、ソースに転送されるＲＲＣ ＨａｎｄｏｖｅｒＣｏｍｍａｎｄメッセージに挿入することと、を含んでもよい。

【0062】

本明細書では更に、少なくとも１つのプロセッサで実行されると、少なくとも１つのプロセッサに、ソースアクセスノードまたはターゲットアクセスノードそれぞれによって実施されるような、上述の方法を実施させる命令を備える、コンピュータプログラム製品が提供される。本明細書では更に、少なくとも１つのプロセッサで実行されると、少なくとも１つのプロセッサに、ソースアクセスノードまたはターゲットアクセスノードそれぞれによって実施されるような、上述の方法を実施させる命令を備えるコンピュータプログラム製品が格納された、コンピュータ可読記憶媒体が提供される。

【0063】

目的は、ＵＥのハンドオーバを扱うソースアクセスノードを提供することによって達成されてもよい。ソースアクセスノードはターゲットアクセスノードに、ターゲットアクセスノードが拡張メイク・ビフォア・ブレークハンドオーバを要求する第１の明示的インジケータを含む、最初のハンドオーバ準備メッセージを伝送するように設定される。ソースアクセスノードは更に、要求された拡張メイク・ビフォア・ブレークハンドオーバを許容または拒否する第２の明示的インジケータを含む、ハンドオーバ準備応答メッセージをターゲットアクセスノードから受信し、拡張メイク・ビフォア・ブレークハンドオーバの拒否または非対応を示すハンドオーバ準備応答メッセージをターゲットアクセスノードから受信すると、可能なフォールバックメカニズムを選択するように設定される。

【0064】

従来技術、即ち、背景技術に記載したようなレガシーハンドオーバ、またはリリース１４のメイク・ビフォア・ブレークハンドオーバの既存の手順と比較して、後述する実施形態による解決策の利点は、ソースアクセスノードが、
例えば、前もって能力を交換または設定することなく、ｅＭＢＢのターゲットアクセスノード能力を学習してもよく、
例えば、ｅＭＢＢに対応していないかまたはターゲットノードによって拒否されるはずである場合、使用する所望のフォールバックメカニズムをターゲットアクセスノードにシグナリングしてもよく、
例えば、ターゲットアクセスノードがｅＭＢＢに対応しておらず、したがってＤＬパケットを既に分離されたＵＥに伝送しないことを知らされてもよく、
例えば、ターゲットアクセスノードがｅＭＢＢに対応していない場合、レガシーハンドオーバがターゲットアクセスノードによって準備され、それによって新しいハンドオーバ手順の開始を回避することを知らされてもよいという点である。

【0065】

目的は、ソースアクセスノードからターゲットアクセスノードへのＵＥのハンドオーバを扱うターゲットアクセスノードを提供することによって達成されてもよい。ターゲットアクセスノードは、拡張メイク・ビフォア・ブレークハンドオーバを要求するソースアクセスノードからの第１の明示的インジケータを含む、最初のハンドオーバ準備メッセージを受信し、拡張メイク・ビフォア・ブレークハンドオーバ要求を許容または拒否する第２の明示的インジケータを含むハンドオーバ準備応答メッセージによって、ソースアクセスノードによって伝送された最初のハンドオーバ準備メッセージに応答するように設定される。

【0066】

従来技術、即ち、レガシーハンドオーバまたはリリース１４のメイク・ビフォア・ブレークの既存の手順と比較して、後述する実施形態による解決策の利点は、ターゲットアクセスノードが、
例えば、ｅＭＢＢ要求の許容または拒否に関して知らされた決定を行い、要求されたアクションを開始してもよく、
例えば、ｅＭＢＢ要求の許容をソースアクセスノードにシグナリングしてもよく、
例えば、ｅＭＢＢ要求の拒否を、例えば選ばれたフォールバックメカニズムとともに、ソースアクセスノードにシグナリングしてもよいという点である。

【0067】

上述したような本明細書の実施形態によるこれらのアクションは、ノード間の不要な能力設定を回避し、ハンドオーバ要求の不具合または拒否によって起こる追加のハンドオーバ遅延を回避し、ＵＥ、ソースおよびターゲットアクセスノード間の挙動における不一致を回避する、最適化されたｅＭＢＢ手順をもたらすであろう。したがって、本明細書の実施形態は、ＵＥのハンドオーバを扱う改善された方法を提供する。

【0068】

本明細書の実施形態の例について、添付図面を参照して更に詳細に記載する。

【図面の簡単な説明】

【0069】

【図1】従来技術による無線通信ネットワークを示す図である。

【図2】５Ｇ／ＮＲにおけるハンドオーバシグナリングを示す図である。

【図3】メイク・ビフォア・ブレークシグナリングＬＴＥを示す図である。

【図4】ＬＴＥ Ｒｅｌ－１６における０ｍｓのＨＯ中断時間に対応する、提案される拡張ＭＢＢ手順を示す図である。

【図5A】本明細書の実施形態が実現されてもよい無線通信ネットワークを示す図である。

【図5B】本明細書の一実施形態によるソースアクセスノードで実施される方法を示すフローチャートである。

【図5C】本明細書の一実施形態によるソースアクセスノードで実施される方法を示すフローチャートである。

【図6A】本明細書の別の実施形態によるターゲットアクセスノードで実施される方法を示すフローチャートである。

【図6B】本明細書の別の実施形態によるターゲットアクセスノードで実施される方法を示すフローチャートである。

【図7A】ソースアクセスノードの一実施形態を示す概略ブロック図である。

【図7B】ターゲットアクセスノードの一実施形態を示す概略ブロック図である。

【発明を実施するための形態】

【0070】

ＲＡＴ内（同じＲＡＴ内）、ＲＡＴ間（異なるＲＡＴの間）、ＮＧ－ＲＡＮ、Ｅ－ＵＴＲＡＮ、および更なる免責事項
本明細書の実施形態で定義されるネットワークおよびＵＥのアクションのほとんどは、ＮＧ－ＲＡＮまたはＥ－ＵＴＲＡＮで実施されるものとして記載される。これらすべての異なるフレーバーにおいて、拡張メイク・ビフォア・ブレーク（ｅＭＢＢ）が準備されてもよいソースアクセスノードおよびターゲットアクセスノードはそれぞれ、Ｅ－ＵＴＲＡＮノード、即ちｅＮｏｄｅＢ、ＮＧ－ＲＡＮノード、即ちＮＲに対応するｇＮｏｄｅＢ、またはＬＴＥに対応するｎｇ－ｅＮｏｄｅＢであってもよい。

【0071】

そのため、本明細書の実施形態に記載されるノード間手順は、２つのｅＮｏｄｅＢ、２つのｇＮｏｄｅＢ、２つのｎｇ－ｅＮｏｄｅＢ、または同じＲＡＴもしくは異なるＲＡＴからの任意の２つのＲＡＮノードの間であってもよい。したがって、５ＧＣに接続されたＮＧ－ＲＡＮノードの場合はＸｎＡＰプロトコル、またはＸ２ＡＰプロトコル、または両方で実現されてもよい。

【0072】

換言すれば、ノード間手順およびメッセージに関する考察は、次のいずれかであってもよい。
Ｘｎを通したｇＮｏｄｅＢなどの、ノード間ＲＡＴ内システム内、
Ｘｎを通したｎｇ－ｅＮｏｄｅＢなどの、ノード間ＲＡＴ内システム内、
Ｘ２を通したｅＮｏｄｅＢなどの、ノード間ＲＡＴ内システム内、
Ｘｎを通したｎｇ－ｅＮｏｄｅＢおよびｇＮｏｄｅＢなど、ノード間ＲＡＴ間システム内、
Ｅ－ＵＴＲＡＮおよびＮＧ－ＲＡＮ、即ち、ＮＧおよびＳ１を通したｇＮｏｄｅＢ／ｅｎ－ｅＮｏｄｅＢならびにｅＮｏｄｅＢなど、ノード間ＲＡＴ間システム間。

【0073】

それに加えて、手順はまた、ＮＧおよびＳ１インターフェースを通したＲＡＮノードとコアネットワークノードとの間、ならびに異なるシステムからのコアネットワークノード間、即ちＮ２６インターフェースを通したＥＰＣと５ＧＣとの間の、メッセージが関与する解決策を記載する。

【0074】

本明細書の実施形態による無線通信システムが、図５Ａに示されている。無線通信システムは、１つまたは複数の無線アクセスネットワーク（ＲＡＮ）を備えてもよく、無線アクセスネットワーク１００は、無線接続１０７～１０８を使用して１つまたは複数のアクセスノード１０３～１０４と通信する、ユーザ機器（ＵＥ）１０２とともに示されている。アクセスノード１０３～１０４はコアネットワーク（ＣＮ）ノード１０６に接続される。アクセスノード１０３～１０４は無線アクセスネットワーク１００の一部である。ソースアクセスノード１０３およびターゲットアクセスノード１０４。本明細書の実施形態は、ソースアクセスノード１０３からターゲットアクセスノード１０４への、ＵＥ １０２のｅＭＢＢハンドオーバに関する。

【0075】

以下、実施形態による通信ネットワーク１におけるＵＥ １０２のＨＯを扱う、ソースアクセスノード１０３によって実施される方法のアクションについて、図５Ｂに示されるフローチャートを参照して記載する。アクションは、後述する順序で行われなくてもよく、任意の好適な順序で行われてもよい。いくつかの実施形態で実施されるアクションは破線のボックスで示される。

【0076】

アクション５０１。ソースアクセスノード１０３はターゲットアクセスノード１０４に、ターゲットアクセスノード１０４がｅＭＢＢハンドオーバを要求する第１の明示的インジケータを含む、最初のハンドオーバ準備メッセージ、例えばハンドオーバ要求を伝送する。第１の明示的指示は、追加情報として、ソースアクセスノード１０３からターゲットアクセスノード１０４に伝送される最初のハンドオーバ準備メッセージに追加されてもよい。第１の明示的インジケータは、ソースアクセスノード１０３からターゲットアクセスノード１０４にシグナリングされる、無線リソース制御（ＲＲＣ）コンテキストに含まれてもよい。第１の明示的インジケータはハンドオーバ要求メッセージに追加されてもよい。

【0077】

アクション５０２。次に、ソースアクセスノード１０３は、要求されたｅＭＢＢハンドオーバを許容または拒否する第２の明示的インジケータを含む、ハンドオーバ準備応答メッセージをターゲットアクセスノード１０４から受信する。

【0078】

アクション５０３。ソースアクセスノード１０３は、ハンドオーバ準備応答メッセージから、拡張メイク・ビフォア・ブレークハンドオーバに関連するターゲットアクセスノード１０４の能力を学習してもよい。ターゲットアクセスノード１０４の能力は、要求された拡張メイク・ビフォア・ブレークハンドオーバの成功応答または失敗応答に基づいて学習されてもよい。

【0079】

アクション５０４。ソースアクセスノード１０３は更に、要求された拡張メイク・ビフォア・ブレークハンドオーバの失敗または拒否の場合、ターゲットアクセスノード１０４に所望のフォールバックを通知してもよい。拡張メイク・ビフォア・ブレークハンドオーバに対する第１の明示的インジケータおよび所望のフォールバックメカニズムに対するインジケータは、アクション５０１の最初のハンドオーバ準備メッセージにおける単一の情報要素で組み合わされてもよいことが注目されるべきである。

【0080】

アクション５０５。ソースアクセスノード１０３は、拡張メイク・ビフォア・ブレークハンドオーバ要求の拒否の場合、ターゲットアクセスノード１０４から、選択された可能なフォールバックメカニズムの通知を受信してもよい。

【0081】

アクション５０６。次に、ソースアクセスノード１０３は、ｅＭＢＢハンドオーバの拒否または非対応を示すハンドオーバ準備応答メッセージをターゲットアクセスノード１０４から受信すると、可能なフォールバックメカニズムを選択する。ソースアクセスノード１０３は、所望のフォールバックおよび／またはターゲットアクセスノード１０４の学習した能力を考慮に入れることによって、可能なフォールバックメカニズムを選択してもよい。例えば、ソースアクセスノード１０３は所望のフォールバックを考慮に入れてもよく、所望のフォールバックは、ターゲットアクセスノード１０４の学習した能力に基づいてもよい。可能なおよび／または所望のフォールバックは、レガシーハンドオーバへのフォールバック、リリース１４のＭＢＢハンドオーバへのフォールバック、およびハンドオーバ要求の拒否のうち１つもしくは複数を含んでもよい。ソースアクセスノード１０３は、ターゲットアクセスノード１０４からの選択された可能なフォールバックの通知を考慮に入れることによって、可能なフォールバックメカニズムを選択してもよい。このように、本明細書の実施形態は、ハンドオーバ準備応答メッセージの受信に応答して、ソースアクセスノード１０３がハンドオーバ準備応答メッセージに基づいて、ｅＭＢＢを拒否するターゲットアクセスノード１０４を受信した際に可能なフォールバック方法に関する決定を行ってもよいことを、開示してもよい。

【0082】

拡張ハンドオーバのための本明細書の実施形態による方法について、以下に詳細に記載する。

【0083】

Ｉ．最初のハンドオーバ準備メッセージにおけるソースアクセスノード１０３のシグナリング。
本明細書の例示の実施形態にしたがって、ソースアクセスノード１０３で実施される方法について、図５Ｃを参照して記載する。方法は、以下のアクションまたはステップを含み、それらのアクションは任意の好適な順序で実施されてもよい。

【0084】

アクション５１１。ソースアクセスノード１０３は、ターゲットアクセスノード１０４が拡張メイク・ビフォア・ブレークハンドオーバを要求する第１の明示的インジケータ、例えば拡張メイク・ビフォア・ブレークインジケータを含む、最初のハンドオーバ準備メッセージを伝送する。

【0085】

一実現例では、第１の明示的インジケータは、追加情報として、ソースからターゲットに伝送される最初のハンドオーバ準備メッセージに追加されてもよい。

【0086】

別の実現例では、第１の明示的インジケータは、ソースからターゲットにシグナリングされるＲＲＣコンテキストに含まれてもよい。

【0087】

ＸｎＡＰ（３ＧＰＰ ＴＳ ３８．４２３ ｖ１５．０．０）ＨＡＮＤＯＶＥＲＲＥＱＵＥＳＴメッセージをベースラインとして取る、上記第１の代替策の可能な実現例の一例が、下線を引いたテキストによって以下に示される。

【0088】

９．１．１．１ ＨＡＮＤＯＶＥＲ ＲＥＱＵＥＳＴ
このメッセージは、ハンドオーバのためにリソースの準備を要求するため、ソースＮＧ－ＲＡＮノードによってターゲットＮＧ－ＲＡＮノードに伝送される。
方向：ソースＮＧ－ＲＡＮノード→ターゲットＮＧ－ＲＡＮノード

【0089】

一実施形態では、ソースアクセスノード１０３は、ターゲットアクセスノード１０４が拡張メイク・ビフォア・ブレークハンドオーバ（ｅＭＢＢ）要求を拒否した場合、ターゲットアクセスノード１０４に所望のフォールバックを通知してもよい。

【0090】

一実施形態では、ソースアクセスノード１０３は、ターゲットアクセスノード１０４が拡張メイク・ビフォア・ブレーク要求を拒否した場合、所望のフォールバックメカニズムに関する決定を行ってもよい。この決定は、例えば、測定値、サービスの品質（ＱｏＳ）、ＵＥの能力、ネットワーク能力、加入などに基づいてもよい。可能なフォールバック方法の一例を以下に列挙する。
レガシーハンドオーバへのフォールバック、
リリース１４のＭＢＢハンドオーバへのフォールバック、
ハンドオーバ要求の拒否。

【0091】

別の実施形態では、ソースアクセスノード１０３は、例えば、最初のハンドオーバ準備メッセージの追加情報を介して、ターゲットアクセスノード１０４に所望のフォールバックメカニズムを知らせてもよい。

【0092】

別の実施形態では、拡張メイク・ビフォア・ブレークのインジケータ、即ち第１の明示的インジケータ、および所望のフォールバックメカニズムのインジケータは、最初のハンドオーバ準備メッセージにおける単一の情報要素に組み合わされてもよい。

【0093】

ＸｎＡＰ（３ＧＰＰ ＴＳ ３８．４２３ ｖ．１５．０．０）ハンドオーバ要求メッセージをベースラインとして取って、拡張メイク・ビフォア・ブレーク要求の許容とともに、「ＩＥ拡張メイク・ビフォア・ブレーク情報」の形で、ターゲットアクセスノード１０４に所望のフォールバックメカニズムを知らせるソースアクセスノード１０３の可能な実現例の一例が、下線を引いたテキストとして以下に示される。

【0094】

９．１．１．１ ＨＡＮＤＯＶＥＲ ＲＥＱＵＥＳＴ
このメッセージは、ハンドオーバのためにリソースの準備を要求するため、ソースＮＧ－ＲＡＮノードによってターゲットＮＧ－ＲＡＮノードに伝送される。
方向：ソースＮＧ－ＲＡＮノード→ターゲットＮＧ－ＲＡＮノード

【0095】

アクション５１２。ソースアクセスノード１０３は、拡張メイク・ビフォア・ブレークハンドオーバ要求を許容または拒否する第２の明示的インジケータを含む、ハンドオーバ準備応答メッセージをターゲットアクセスノード１０４から受信し処理する。

【0096】

アクション５１３。一実施形態では、最初のハンドオーバ準備メッセージに対するターゲットアクセスノードの応答を受信した後、ソースアクセスノード１０３は、アクション５０６で記載したような、可能なフォールバック方法に関する決定を行ってもよい。その場合、ソースアクセスノード１０３は次の間で選択を行ってもよい。

【0097】

ターゲットアクセスノード１０４によって提案されるフォールバック方法を許容する。
例えばＨＡＮＤＯＶＥＲ ＣＡＮＣＥＬメッセージを使用して、ハンドオーバ手順を取り消し、同じノードを用いて、例えばｅＭＢＢインジケータなしで、または異なるノードを用いて、新しいハンドオーバ手順を開始する。

【0098】

以下、本明細書の実施形態による、ソースアクセスノード１０３からターゲットアクセスノード１０４へのＵＥのハンドオーバを扱う、ターゲットアクセスノード１０４によって実施される方法のアクションについて、図６Ａに示されるフローチャートを参照して記載する。アクションは、後述する順序で行われなくてもよく、任意の好適な順序で行われてもよい。いくつかの実施形態で実施されるアクションは破線のボックスで示される。

【0099】

アクション６０１。ターゲットアクセスノード１０４は、拡張メイク・ビフォア・ブレークハンドオーバを要求するソースアクセスノード１０３からの第１の明示的インジケータを含む、最初のハンドオーバ準備メッセージを受信する。

【0100】

アクション６０２。ターゲットアクセスノード１０４は、要求された拡張メイク・ビフォア・ブレークハンドオーバの失敗または拒否の場合、ソースアクセスノード１０３から所望のフォールバックの通知を受信してもよい。

【0101】

アクション６０３。ターゲットアクセスノード１０４は更に、拡張メイク・ビフォア・ブレークハンドオーバの失敗または拒否の場合、可能なフォールバックメカニズムを選択してもよい。例えば、ターゲットアクセスノード１０４におけるフォールバックの解決策の選択は、ハンドオーバ準備メッセージに含まれる所望のフォールバックに基づいてもよい。

【0102】

アクション６０４。次に、ターゲットアクセスノード１０４は、拡張メイク・ビフォア・ブレークハンドオーバ要求の失敗または拒否の場合、ソースアクセスノード１０３に選択された可能なフォールバックメカニズムを通知してもよい。

【0103】

アクション６０５。ターゲットアクセスノード１０４は、拡張メイク・ビフォア・ブレークハンドオーバ要求を許容または拒否する第２の明示的インジケータを含むハンドオーバ準備応答メッセージを用いて、ソースアクセスノード１０３によって伝送された最初のハンドオーバ準備メッセージに応答する。ターゲットアクセスノード１０４は、拡張メイク・ビフォア・ブレークハンドオーバ要求を拒否する第２のインジケータと、選択された可能なフォールバック方法のインジケータとを含む、ハンドオーバ準備応答メッセージを用いてソースアクセスノード１０３に応答してもよい。ターゲットアクセスノード１０４は、明示的な拡張メイク・ビフォア・ブレークハンドオーバインジケータを、ソースアクセスノード１０３に転送されるＲＲＣ ＨａｎｄｏｖｅｒＣｏｍｍａｎｄメッセージに挿入することによって応答してもよい。ターゲットアクセスノード１０４は、所望のフォールバックのソースアクセスノード１０３から受信した通知を考慮に入れることによって、可能なフォールバックメカニズムを選択してもよい。

【0104】

ＩＩ．ターゲットアクセスノード１０４からのハンドオーバ準備応答。
本明細書の１つの例示の実施形態にしたがって、ターゲットアクセスノード１０４で実施される方法について、図６Ｂを参照して記載する。方法は、以下のアクションまたはステップを含み、それらのアクションは任意の好適な順序で実施されてもよい。

【0105】

アクション６１１。ターゲットアクセスノード１０４は、拡張メイク・ビフォア・ブレークハンドオーバを要求するソースアクセスノード１０３からの明示的インジケータ、即ち第１の明示的インジケータを含む、最初のハンドオーバ準備メッセージを受信し処理する。

【0106】

アクション６１２。次に、ターゲットアクセスノード１０４は、拡張メイク・ビフォア・ブレーク要求に関する決定、例えば許容、フォールバック、または拒否を行ってもよい。この決定は、例えば、ＱｏＳ、ネットワーク能力、利用可能なリソース、設定などに基づいてもよい。ターゲットアクセスノードの決定は次のようなものであってもよい。
拡張メイク・ビフォア・ブレークハンドオーバを許容、
レガシーハンドオーバへのフォールバック、
ｒｅｌ－１４メイク・ビフォア・ブレークハンドオーバへのフォールバック、
ハンドオーバを拒否。

【0107】

アクション６１３。ターゲットアクセスノード１０４がｅＭＢＢハンドオーバを許容した場合、拡張メイク・ビフォア・ブレークハンドオーバ要求を許容する第２の明示的インジケータを含む、ハンドオーバ準備応答メッセージをソースアクセスノード１０３に伝送する。

【0108】

ターゲットアクセスノード１０４は、例えば、ハンドオーバ準備応答メッセージの追加情報を介して、ソースアクセスノード１０３に、拡張メイク・ビフォア・ブレーク要求に関するその決定を知らせてもよい。

【0109】

成功または部分的な成功のため、例えばフォールバックメカニズムが使用される場合、可能な実現例の一例は、ＸｎＡＰ（３ＧＰＰ ＴＳ ３８．４２３ ｖ．１５．０．０）ＨＡＮＤＯＶＥＲＲＥＱＵＥＳＴ ＡＣＫＮＯＷＬＥＤＧＥメッセージをベースラインとして取り、下線を引いたテキストによって示されるようなＩＥ「拡張メイク・ビフォア・ブレークインジケータ」を追加する。

【0110】

９．１．１．２ ＨＡＮＤＯＶＥＲ ＲＥＱＵＥＳＴ ＡＣＫＮＯＷＬＥＤＧＥ
このメッセージは、ターゲットで準備されたリソースに関してソースＮＧ－ＲＡＮノードに知らせるため、ターゲットＮＧ－ＲＡＮノードによって伝送される。
方向：ターゲットＮＧ－ＲＡＮノード→ソースＮＧ－ＲＡＮノード

【0111】

アクション６１４。ターゲットアクセスノード１０４がｅＭＢＢハンドオーバを拒否した場合、ターゲットアクセスノード１０４は可能なフォールバック方法を選択してもよい。

【0112】

ハンドオーバ失敗の場合、例えばターゲットアクセスノード１０４がＨＯを拒否し、フォールバック方法が使用されなかった場合、可能な実現例の一例は、ＸｎＡＰ（３ＧＰＰ ＴＳ ３８．４２３ ｖ．１５．０．０）ＨＡＮＤＯＶＥＲ ＰＲＥＰＡＲＡＴＩＯＮ ＦＡＩＬＵＲＥメッセージをベースラインとして取り、下線を引いたテキストで示されるように拒否された新しい原因値ｅＭＢＢを使用してもよい。

【0113】

９．１．１．３ ＨＡＮＤＯＶＥＲ ＰＲＥＰＡＲＡＴＩＯＮ ＦＡＩＬＵＲＥ
このメッセージは、ハンドオーバ準備が失敗したことをソースＮＧ－ＲＡＮノードに知らせるため、ターゲットＮＧ－ＲＡＮノードによって伝送される。
方向：ターゲットＮＧ－ＲＡＮノード→ソースＮＧ－ＲＡＮノード

【0114】

９．２．３．２ 原因
原因ＩＥの目的は、ＸｎＡＰプロトコルに関する特定のイベントの理由を示すことである。

【0115】

異なる原因値の意味は以下の表で指定される。一般に、「非対応」の原因値は関連する能力が欠けていることを示す。他方で、「利用不能」の原因値は、関連する能力は存在しないが、要求されたアクションを実施するのに不十分なリソースは利用可能であったことを示す。

【0116】

アクション６１５。一実施形態では、ターゲットアクセスノード１０４は、拡張メイク・ビフォア・ブレークハンドオーバ要求を拒否する第２の明示的インジケータと、選択された可能なフォールバック方法のインジケータとを含む、ハンドオーバ準備応答メッセージをソースアクセスノード１０３に伝送する。

【0117】

一実施形態では、ｅＭＢＢに対応していないターゲットアクセスノード１０４は、既存の原因値、例えば抽象構文エラー（拒否）を含む、ハンドオーバ要求失敗を伝送してもよい。

【0118】

一実施形態では、ソースアクセスノード１０３は、拡張メイク・ビフォア・ブレークハンドオーバ要求を許容または拒否する第２の明示的インジケータを含む、上述のハンドオーバ準備応答メッセージをターゲットアクセスノード１０４から受信し、処理してもよい。

【0119】

ＩＩＩ．ソースアクセスノード１０３におけるターゲットアクセスノードのｅＭＢＢ能力の学習。
図５Ｂのアクション５０３を参照すると、上述の実施形態に従属する一実施形態では、ソースアクセスノード１０３は、ターゲットアクセスノード１０４からの応答にしたがって、ターゲットアクセスノードのｅＭＢＢ能力に関して学習してもよい。

【0120】

ソースアクセスノード１０３が、追加のｅＭＢＢ情報を含まない成功応答を受信した場合、ターゲットアクセスノード１０４はｅＭＢＢに対応していないと推論してもよい。

【0121】

ソースアクセスノード１０３が、追加のｅＭＢＢ情報、例えばｅＭＢＢ許容または所望のフォールバックを含む、成功応答を受信した場合、ターゲットアクセスノード１０４はｅＭＢＢに対応していると推論してもよい。

【0122】

ソースアクセスノード１０３が、追加のｅＭＢＢ情報、例えば原因値＝ｅＭＢＢ非許容を含む、失敗応答を受信した場合、ターゲットアクセスノード１０４はｅＭＢＢに対応していると推論してもよい。

【0123】

この情報は、同じまたは異なるＵＥの同じターゲットアクセスノード１０４への後続のハンドオーバに関する決定を行うために、ソースアクセスノード１０３に格納されてもよい。

【0124】

ＩＶ．ＲＲＣハンドオーバコマンドの拡張メイク・ビフォア・ブレークハンドオーバインジケータは、ソースアクセスノード１０３に転送されるコマンドメッセージである
一実施形態では、ターゲットアクセスノード１０４がソースアクセスノード１０３からの拡張メイク・ビフォア・ブレーク要求を許容した場合、ターゲットアクセスノード１０４は、拡張メイク・ビフォア・ブレークインジケータとして例示される第２のインジケータを、ＬＴＥの場合はＭｏｂｉｌｉｔｙＣｏｎｔｒｏｌＩｎｆｏ ＩＥを含むＲＲＣＣｏｎｎｅｃｔｉｏｎＲｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージ、ＮＲの場合はｒｅｃｏｎｆｉｇｕｒａｔｉｏｎＷｉｔｈＳｙｎｃ ＩＥを含むＲＲＣＲｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージに対応する、ＲＲＣ ＨａｎｄｏｖｅｒＣｏｍｍａｎｄメッセージに挿入して、拡張メイク・ビフォア・ブレークハンドオーバを実施すべきであることをＵＥにシグナリングしてもよい。

【0125】

拡張ＭａｋｅＢｅｆｏｒｅＢｒｅａｋ－ｒ１６ ＩＥ（下線）が、ＬＴＥに対するＲＲＣＣｏｎｎｅｃｔｉｏｎＲｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージに含まれるＭｏｂｉｌｉｔｙＣｏｎｔｒｏｌＩｎｆｏに追加される、ＬＴＥに関するＡＳＮ．１の例を以下に示す。

【0126】

拡張ＭａｋｅＢｅｆｏｒｅＢｒｅａｋ－ｒ１６ ＩＥ（下線）が、ＮＲにおけるＲＲＣＲｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージに含まれるｒｅｃｏｎｆｉｇｕｒａｔｉｏｎＷｉｔｈＳｙｎｃ ＩＥに追加される、ＮＲに関する一例を以下に示す。

【0127】

Ｖ．ターゲットアクセスノード１０４がｅＭＢＢに対応していない場合の、リリース１４ ＭＢＢへのフォールバック。
一実施形態では、ソースアクセスノード１０３は、リリース１４のメイク・ビフォア・ブレークに使用される、即ち、ＲＲＣ ＨａｎｄｏｖｅｒＰｒｅｐａｒａｔｉｏｎメッセージのｍａｋｅＢｅｆｏｒｅＢｒｅａｋ－ｒ１４インジケータと、アクション５０１で定義される新しいインジケータ、即ち第１の明示的インジケータとを加える、シグナリング方法を組み合わせてもよい。ターゲットアクセスノード１０４がｅＭＢＢに対応しており、ｅＭＢＢ要求を許容する場合、アクション６０５で定義されるように、ＲＲＣ ｅＭＢＢインジケータをＲＲＣ ＨａｎｄｏｖｅｒＣｏｍｍａｎｄメッセージに挿入する。ターゲットアクセスノード１０４がｅＭＢＢに対応しており、ｅＭＢＢ要求を拒否する場合、ＲＲＣリリース１４ ＭＢＢインジケータをＲＲＣ ＨａｎｄｏｖｅｒＣｏｍｍａｎｄメッセージに挿入する。ターゲットアクセスノード１０４が、ｅＭＢＢに対応していないがリリース１４ ＭＢＢには対応している場合、リリース１４ ＲＲＣ ＭＢＢインジケータをＲＲＣ ＨａｎｄｏｖｅｒＣｏｍｍａｎｄメッセージに挿入する。

【0128】

ＶＩ．拡張メイク・ビフォア・ブレーク準備のための可能なソースアクセスノード１０３およびターゲットアクセスノード１０４のアクション
本明細書の実施形態は、拡張メイク・ビフォア・ブレーク準備のための、ネットワークシグナリングに関する可能なソースおよびターゲットアクセスノードのアクションを定義している。これらのアクションは、異なる可能なシナリオにしたがって定義される。異なる可能なシナリオは、以下の基準／イベントの組み合わせである。

【0129】

ソースアクセスノード１０３からのｅＭＢＢ要求を受信する際の、ターゲットアクセスノードのｅＭＢＢ対応および決定。
Ｉ．ターゲットアクセスノード１０４はｅＭＢＢに対応しており、ｅＭＢＢ要求を許容する。
ＩＩ．ターゲットアクセスノード１０４はｅＭＢＢに対応しており、ｅＭＢＢ要求を拒否する。
ＩＩＩ．ターゲットアクセスノード１０４はｅＭＢＢに対応していない。

【0130】

ターゲットアクセスノード１０４がｅＭＢＢ要求を拒否する場合、どのノードが、即ちソースまたはターゲットが、使用されるフォールバック方法に対する最終決定を行うか。
Ａ．フォールバック方法はターゲットアクセスノード１０４によって決定される。ソースアクセスノード１０３は、フォールバック方法が適切でない場合、後でいつでも取り消すことができる。
Ｂ．フォールバック方法は、ハンドオーバ要求の前にソースアクセスノード１０３によって決定される。
Ｃ．フォールバック方法は、ハンドオーバ準備の失敗がターゲットアクセスノード１０４から受信された後に、ソースアクセスノード１０３によって決定される。

【0131】

フォールバック方法または他のソース／ターゲットアクセスノードの決定
１）レガシーハンドオーバへのフォールバック
２）リリース１４のメイク・ビフォア・ブレークへのフォールバック
３）ハンドオーバが拒否される
４）ハンドオーバが取り消される

【0132】

すべての可能な選択肢を組み合わせることによって、ソースおよびターゲットアクセスノードに関する以下の挙動が定義されてもよい。

【0133】

ターゲットアクセスノード１０４がｅＭＢＢに対応しており、ｅＭＢＢ要求を許容する。
Ｉ．ターゲットアクセスノード１０４は、第１の明示的インジケータ、例えばｅＭＢＢインジケータを、ＲＲＣ ＨａｎｄｏｖｅｒＣｏｍｍａｎｄメッセージ内に追加し、任意のＩＥの第２の明示的インジケータ、例えばｅＭＢＢ許容を、ハンドオーバ要求肯定応答に追加し、即ち、ターゲットアクセスノード１０４は、ｅＭＢＢが許容されていることを、明示的にシグナリングしてもよいので、ソースアクセスノード１０３は、ＲＲＣ ＨａｎｄｏｖｅｒＣｏｍｍａｎｄメッセージをチェックする必要なく分かっている。場合によっては、「ｅＭＢＢ許容」を「ｅＭＢＢ非対応」イベントと区別するのが必要なことがある。ソースアクセスノード１０３は、ターゲットアクセスノード１０４がｅＭＢＢに対応していると学習することができる。

【0134】

ターゲットアクセスノード１０４はｅＭＢＢに対応しており、ｅＭＢＢ要求を拒否する。

【0135】

ＩＩ．Ａ．１．ターゲットアクセスノード１０４は、ｅＭＢＢインジケータをＲＲＣ ＨａｎｄｏｖｅｒＣｏｍｍａｎｄメッセージ内に追加せず、任意のＩＥ、例えばレガシーＨＯへのフォールバックを、ハンドオーバ要求肯定応答に追加する。ソースアクセスノード１０３は、ターゲットアクセスノード１０４がｅＭＢＢに対応していると学習してもよい。

【0136】

ＩＩ．Ａ．２．ターゲットアクセスノード１０４は、ｒｅｌ－１４ ＭＢＢインジケータをＲＲＣ ＨａｎｄｏｖｅｒＣｏｍｍａｎｄメッセージ内に追加し、任意のＩＥ、例えばｒｅｌ－１４ ＭＢＢへのフォールバックを、ハンドオーバ要求肯定応答に追加する。ソースアクセスノード１０３は、ターゲットアクセスノード１０４がｅＭＢＢに対応していると学習することができる。ｅＭＢＢに対応しているソースアクセスノード１０３は、ｒｅｌ－１４ ＭＢＢにも対応していると仮定される。

【0137】

ＩＩ．Ａ．３．ターゲットアクセスノード１０４は、新しい原因値、例えばｅＭＢＢ拒否を含むハンドオーバ準備失敗メッセージをレガシーに伝送してもよい。次に、ソースアクセスノード１０３は、ターゲットアクセスノード１０４がｅＭＢＢに対応していると学習してもよい。ソースアクセスノード１０３は、別のハンドオーバ要求を、ｅＭＢＢインジケータを含まずに同じノードに対して試みてもよい。あるいは、ｅＭＢＢを含むかまたは含まずに、別のターゲットアクセスノードを試みる。

【0138】

ＩＩ．Ａ．４．該当なし。

【0139】

ＩＩ．Ｂ．１．ターゲットアクセスノード１０４は、ｅＭＢＢインジケータをＲＲＣ ＨａｎｄｏｖｅｒＣｏｍｍａｎｄメッセージ内に追加せず、任意のＩＥ、例えばレガシーＨＯへのフォールバックを、ハンドオーバ要求肯定応答に追加する。ソースアクセスノード１０３は、ターゲットアクセスノード１０４がｅＭＢＢに対応していると学習することができる。

【0140】

ＩＩ．Ｂ．２．ターゲットアクセスノード１０４は、ｒｅｌ－１４ ＭＢＢインジケータをＲＲＣ ＨａｎｄｏｖｅｒＣｏｍｍａｎｄメッセージ内に追加し、任意のＩＥ、例えばｒｅｌ－１４ ＭＢＢへのフォールバックを、ハンドオーバ要求肯定応答に追加する。ソースアクセスノード１０３は、ターゲットがｅＭＢＢに対応していると学習してもよい。

【0141】

ＩＩ．Ｂ．３．ターゲットアクセスノード１０４は、新しい原因値、例えばｅＭＢＢ拒否を含むハンドオーバ準備失敗メッセージを伝送する。ソースアクセスノード１０３は、ターゲットアクセスノード１０４がｅＭＢＢに対応していると学習してもよい。ソースアクセスノード１３は、ｅＭＢＢを含むかまたは含まずに、別のターゲットアクセスノードを試みることができる。

【0142】

ＩＩ．Ｂ．４．不要。その場合、ソースアクセスノード１０３はＩＩ．Ｂ．３．に記載したアクションを使用するべきである。

【0143】

ＩＩ．Ｃ．１．ターゲットアクセスノード１０４は、新しい原因値、例えばｅＭＢＢ拒否を含むハンドオーバ準備失敗メッセージを伝送する。ソースアクセスノード１０３は、ターゲットアクセスノード１０４がｅＭＢＢに対応していると学習してもよい。ソースアクセスノード１０３は、ｅＭＢＢインジケータを含まない新しいハンドオーバ要求を伝送する。

【0144】

ＩＩ．Ｃ．２．ターゲットアクセスノード１０４は、新しい原因値、例えばｅＭＢＢ拒否を含むハンドオーバ準備失敗メッセージを伝送する。ソースアクセスノード１０３は、ターゲットアクセスノード１０４がｅＭＢＢに対応していると学習してもよい。ソースアクセスノード１０３は、ｒｅｌ－１４ ＭＢＢインジケータを含まない新しいハンドオーバ要求を伝送する。ＭＢＢはターゲットアクセスノード１０４からのいずれの特定のアクションも必要としないので、ターゲットアクセスノード１０４は、ｒｅｌ－１４として許容することができるはずである。

【0145】

ＩＩ．Ｃ．３．ターゲットアクセスノード１０４は、新しい原因値、例えばｅＭＢＢ拒否を含むハンドオーバ準備失敗メッセージを伝送する。ソースアクセスノード１０３は、ターゲットアクセスノード１０４がｅＭＢＢに対応していると学習してもよい。ソースアクセスノード１０３は、ｅＭＢＢを含むかまたは含まずに、別のターゲットアクセスノードを試みてもよい。

【0146】

ＩＩ．Ｃ．４．該当なし。

【0147】

ターゲットアクセスノード１０４はｅＭＢＢに対応していない。

【0148】

ＩＩＩ．Ａ．１．ターゲットアクセスノード１０４は、ｅＭＢＢインジケータをＲＲＣ ＨａｎｄｏｖｅｒＣｏｍｍａｎｄメッセージ内に追加せず、任意のＩＥをハンドオーバ要求肯定応答メッセージに追加しない。ソースアクセスノード１０３は、ターゲットアクセスノード１０４がｅＭＢＢに対応していないと学習してもよい。

【0149】

ＩＩＩ．Ａ．２．ＲＲＣのｅＭＢＢインジケータがｒｅｌ－１４ ＭＢＢインジケータと同様でない限り、該当なし。その場合、ターゲットアクセスノード１０は、ｒｅｌ－１４ ＭＢＢインジケータをＨＯコマンド内に追加し、任意のＩＥをＨＯ要求肯定応答に追加しない。ソースアクセスノード１０３は、ターゲットがｅＭＢＢに対応していないと学習してもよい。この使用例を網羅する必要がある場合、ソースからのシグナリングは１および２を組み合わせて、ターゲットがｅＭＢＢに対応している事例を網羅する。

【0150】

ＩＩＩ．Ａ．３．該当なし。

【0151】

ＩＩＩ．Ａ．４．該当なし。

【0152】

ＩＩＩ．Ｂ．該当なし。

【0153】

ＩＩＩ．Ｃ．１． ＩＩＩ．Ａ．１と同様。これは、ｅＭＢＢに対応していないターゲットアクセスノード１０４からのデフォルトのアクションである。

【0154】

ＩＩＩ．Ｃ．２．ターゲットアクセスノード１０４は、ｅＭＢＢインジケータをＲＲＣ ＨａｎｄｏｖｅｒＣｏｍｍａｎｄメッセージ内に追加せず、任意のＩＥをハンドオーバ要求肯定応答メッセージに追加しない。ソースアクセスノード１０３は、ターゲットアクセスノード１０４がｅＭＢＢに対応していないと学習してもよい。ターゲットアクセスノード１０４は、ＨＯを取り消し、ｒｅｌ－１４ ＭＢＢインジケータを含む新しいハンドオーバ要求を伝送する。

【0155】

ＩＩＩ．Ｃ．３．該当なし。

【0156】

ＩＩＩ．Ｃ．４．ターゲットアクセスノード１０４は、ｅＭＢＢインジケータをＲＲＣハンドオーバコマンドメッセージのｅＭＢＢ内に追加しない。ソース／ターゲットアクセスノードは、ＨＯを取り消し、ｅＭＢＢを含むかまたは含まずに、別のターゲットアクセスノードを試みることができる。

【0157】

ｅＭＢＢに対応していないノードに関する上述のアクションに対する１つの代替案は、既存の原因値、例えば抽象構文エラー（拒否）を含む、ハンドオーバ要求失敗を伝送することである。

【0158】

ソースアクセスノード１０３において方法を実施するため、ソースアクセスノード１０３は、図７Ａに示されるようなモジュールを備えてもよい。ソースアクセスノード１０３は、受信モジュール７１０、送信モジュール７２０、判定モジュール７３０、処理モジュール７４０、メモリ７５０などを備えてもよい。受信モジュール７１０、送信モジュール７２０、判定モジュール７３０、および処理モジュール７４０は、プロセッサ７６０として示される、１つのモジュールとして組み合わされてもよい。

【0159】

本明細書の実施形態による方法は、ソースアクセスノード１０３内のプロセッサ７６０など、１つまたは複数のプロセッサによって、本明細書の実施形態の機能およびアクションを実施するコンピュータプログラムコードとともに、実現されてもよい。上述のプログラムコードはまた、例えば、ソースアクセスノード１０３にロードされると本明細書の実施形態を実施する、図７Ａに示されるような、コンピュータプログラムコード７７０を保持するデータキャリア７８０の形態の、コンピュータプログラム製品として提供されてもよい。かかる１つのキャリアは、ＣＤ ＲＯＭディスクの形態であってもよい。しかしながら、メモリスティックなど、他のデータキャリアで実現可能である。コンピュータプログラムコードは更に、サーバまたはクラウド上の純粋なプログラムコードとして提供され、ソースアクセスノード１０３にダウンロードされてもよい。

【0160】

ソースアクセスノード１０３内のメモリ７５０は、１つまたは複数のメモリユニットを備えてもよく、受信した情報、測定値、データ、設定、およびアプリケーションを格納して、ソースアクセスノード１０３で実行されたときに本明細書の方法を実施するのに使用されるように配置されてもよい。

【0161】

ソースアクセスノード１０３、プロセッサ７６０、または送信モジュール７２０は、ターゲットアクセスノード１０４に、ターゲットアクセスノード１０４が拡張メイク・ビフォア・ブレークハンドオーバを要求する第１の明示的インジケータを含む、最初のハンドオーバ準備メッセージを伝送するように設定される。

【0162】

ソースアクセスノード１０３、プロセッサ７６０、または受信モジュール７１０は、要求された拡張メイク・ビフォア・ブレークハンドオーバを許容または拒否する第２の明示的インジケータを含む、ハンドオーバ準備応答メッセージをターゲットアクセスノード１０４から受信するように設定される。

【0163】

ソースアクセスノード１０３、プロセッサ７６０、または判定モジュール７３０は、拡張メイク・ビフォア・ブレークハンドオーバの拒否または非対応を示すハンドオーバ準備応答メッセージをターゲットアクセスノード１０４から受信すると、可能なフォールバックメカニズムを選択するように設定される。

【0164】

ソースアクセスノード１０３、プロセッサ７６０、または処理モジュール７４０は、要求された拡張メイク・ビフォア・ブレークハンドオーバの失敗または拒否の場合、ターゲットアクセスノード１０４に所望のフォールバックを通知するように設定されてもよい。

【0165】

ソースアクセスノード１０３、プロセッサ７６０、または処理モジュール７４０は、ハンドオーバ準備応答メッセージから、拡張メイク・ビフォア・ブレークハンドオーバに関連するターゲットアクセスノード１０４の能力を学習するように設定されてもよい。ターゲットアクセスノード１０４の能力は、要求された拡張メイク・ビフォア・ブレークハンドオーバの成功応答または失敗応答に基づいて学習されてもよい。ソースアクセスノード１０３、プロセッサ７６０、または判定モジュール７３０は、所望のフォールバックを考慮に入れる可能なフォールバックメカニズム、ならびに／あるいはターゲットアクセスノード１０４の学習した能力を選択するように設定されてもよい。

【0166】

ソースアクセスノード１０３、プロセッサ７６０、または判定モジュール７３０は、ターゲットアクセスノード１０４に所望のフォールバックを通知するように設定されてもよく、その場合、拡張メイク・ビフォア・ブレークハンドオーバに対する第１の明示的インジケータおよび所望のフォールバックメカニズムに対するインジケータは、最初のハンドオーバ準備メッセージの単一の情報要素で組み合わされる。

【0167】

ソースアクセスノード１０３、プロセッサ７６０、または送信モジュール７２０は、追加情報としての第１の明示的指示を最初のハンドオーバ準備メッセージに追加するように設定されてもよい。

【0168】

第１の明示的指示は、ソースアクセスノードからターゲットアクセスノードにシグナリングされる、ＲＲＣコンテキストに含まれてもよい。第１の明示的指示はハンドオーバ要求メッセージに追加されてもよい。

【0169】

可能なおよび／または所望のフォールバックは、レガシーハンドオーバへのフォールバック、リリース１４のＭＢＢハンドオーバへのフォールバック、およびハンドオーバ要求の拒否のうち１つもしくは複数を含んでもよい。

【0170】

ソースアクセスノード１０３、プロセッサ７６０、または受信モジュール７１０は、拡張メイク・ビフォア・ブレークハンドオーバ要求の拒否の場合、ターゲットアクセスノード１０４から、選択された可能なフォールバックメカニズムの通知を受信するように設定されてもよい。

【0171】

ソースアクセスノード１０３、プロセッサ７６０、または判定モジュール７３０は、通知を考慮に入れることによって、可能なフォールバックメカニズムを選択するように設定されてもよい。

【0172】

ターゲットアクセスノード１０４において方法を実施するため、ターゲットアクセスノード１０４は、図７Ｂに示されるようなモジュールを備えてもよい。ターゲットアクセスノード１０４は、受信モジュール７１１、送信モジュール７２１、判定モジュール７３１、処理モジュール７４１、メモリ７５１などを備えてもよい。受信モジュール７１１、送信モジュール７２１、判定モジュール７３１、および処理モジュール７４１は、プロセッサ７６１として示される、１つのモジュールとして組み合わされてもよい。

【0173】

ターゲットアクセスノード１０４、プロセッサ７６１、および／または受信モジュール７１１は、拡張メイク・ビフォア・ブレークハンドオーバを要求するソースアクセスノード１０３からの第１の明示的インジケータを含む、最初のハンドオーバ準備メッセージを受信するように設定される。

【0174】

ターゲットアクセスノード１０４、プロセッサ７６１、および／または送信モジュール７２１は、拡張メイク・ビフォア・ブレークハンドオーバ要求を許容または拒否する第２の明示的インジケータを含むハンドオーバ準備応答メッセージを用いて、ソースアクセスノード１０３によって伝送された最初のハンドオーバ準備メッセージに応答するように設定される。

【0175】

ターゲットアクセスノード１０４、プロセッサ７６１、および／または判定モジュール７３１は、拡張メイク・ビフォア・ブレークハンドオーバの失敗または拒否の場合、可能なフォールバックメカニズムを選択するように設定されてもよい。

【0176】

ターゲットアクセスノード１０４、プロセッサ７６１、および／または送信モジュール７２１は、拡張メイク・ビフォア・ブレークハンドオーバ要求の失敗または拒否の場合、ソースアクセスノード１０３に選択された可能なフォールバックメカニズムを通知するように設定されてもよい。

【0177】

ターゲットアクセスノード１０４、プロセッサ７６１、および／または送信モジュール７２１は、拡張メイク・ビフォア・ブレークハンドオーバ要求を拒否する第２のインジケータと、選択された可能なフォールバック方法のインジケータとを含む、ハンドオーバ準備応答メッセージを用いてソースアクセスノード１０３に応答するように設定されてもよい。

【0178】

ターゲットアクセスノード１０４、プロセッサ７６１、および／または送信モジュール７２１は、明示的な拡張メイク・ビフォア・ブレークハンドオーバインジケータを、ソースアクセスノード１０３に転送されるＲＲＣ ＨａｎｄｏｖｅｒＣｏｍｍａｎｄメッセージに挿入することによって応答するように構成されてもよい。

【0179】

ターゲットアクセスノード１０４、プロセッサ７６１、および／または受信モジュール７１１は、要求された拡張メイク・ビフォア・ブレークハンドオーバの失敗または拒否の場合、ソースアクセスノード１０３から所望のフォールバックの通知を受信するように設定されてもよい。ターゲットアクセスノード１０４、プロセッサ７６１、および／または判定モジュール７３１は、受信した通知を考慮に入れる、可能なフォールバックメカニズムを選択するように設定されてもよい。

【0180】

本明細書の実施形態による方法は、ターゲットアクセスノード１０４内のプロセッサ７６１など、１つまたは複数のプロセッサによって、本明細書の実施形態の機能およびアクションを実施するコンピュータプログラムコードとともに、実現されてもよい。上述のプログラムコードはまた、例えば、ターゲットアクセスノード１０４にロードされると本明細書の実施形態を実施する、図７Ｂに示されるような、コンピュータプログラムコード７７１を保持するデータキャリア７８１の形態の、コンピュータプログラム製品として提供されてもよい。かかる１つのキャリアは、ＣＤ ＲＯＭディスクの形態であってもよい。しかしながら、メモリスティックなど、他のデータキャリアで実現可能である。コンピュータプログラムコードは更に、サーバまたはクラウド上の純粋なプログラムコードとして提供され、ターゲットアクセスノード１０４にダウンロードされてもよい。

【0181】

ターゲットアクセスノード１０４内のメモリ７５１は、１つまたは複数のメモリユニットを備えてもよく、受信した情報、測定値、データ、設定、およびアプリケーションを格納して、ターゲットアクセスノード１０４で実行されたときに本明細書の方法を実施するのに使用されるように配置されてもよい。

【0182】

以下、いくつかの実施形態について記載する。
実施形態１：ターゲットアクセスノードへのＵＥのハンドオーバを実施する、ソースアクセスノードにおける方法であって、
ターゲットアクセスノードが拡張メイク・ビフォア・ブレークハンドオーバを要求するインジケータを含む、最初のハンドオーバ準備メッセージを伝送することと、
拡張メイク・ビフォア・ブレークハンドオーバ要求の拒否の場合、ターゲットアクセスノードに所望のフォールバックを通知することと、
拡張メイク・ビフォア・ブレークハンドオーバ要求を許容または拒否するインジケータを含む、ハンドオーバ準備応答メッセージをターゲットアクセスノードから受信することと、
ハンドオーバ準備応答メッセージの受信に応答して、拡張メイク・ビフォア・ブレークハンドオーバを拒否するターゲットアクセスノードを受信すると、可能なフォールバック方法に関する決定を行うことと、を含む、方法。

【0183】

実施形態２：実施形態１にしたがって、ソースアクセスノードが、拡張メイク・ビフォア・ブレークハンドオーバ要求に対するターゲット応答メッセージから、ターゲットアクセスノード拡張メイク・ビフォア・ブレーク能力を学習する。

【0184】

グループＢ実施形態
実施形態３：ソースアクセスノードからのＵＥのハンドオーバを実施する、ターゲットアクセスノードにおける方法であって、
拡張メイク・ビフォア・ブレークハンドオーバを要求するソースアクセスノードからのインジケータを含む、最初のハンドオーバ準備メッセージを受信することと、
拡張メイク・ビフォア・ブレークハンドオーバ要求を許容または拒否するインジケータを含む、ソースアクセスノードによって伝送された最初のハンドオーバ準備メッセージに応答することと、
拡張メイク・ビフォア・ブレークハンドオーバの拒否の場合、可能なフォールバック方法を選択することと、
拡張メイク・ビフォア・ブレークハンドオーバ要求の拒否の場合、ソースアクセスノードに選択されたフォールバック方法を通知することと、
ＵＥに通知するために、明示的な拡張メイク・ビフォア・ブレークハンドオーバインジケータを、ソースアクセスノードに転送されるＲＲＣ ＨａｎｄｏｖｅｒＣｏｍｍａｎｄメッセージに挿入することと、を含む、方法。

【0185】

図２～４内の文字が小さすぎて不鮮明で読めない場合に備えて、以下に参照を示す。
図２：３ＧＰＰ ＴＳ ３８．３００ ｖ１５．２．０の図９．２．３．２．１－１による。
図３：３ＧＰＰ ＴＳ ３６．３００ ｖ１４．８．０の図１０．１．２．１．１－１による。
図４：Ｒ２－１８１７３９６，Ｅｎｈａｎｃｅｍｅｎｔｓ ｔｏ Ｍａｋｅ－Ｂｅｆｏｒｅ－Ｂｒｅａｋ，Ｅｒｉｃｓｓｏｎ，３ＧＰＰ ＴＳＧ－ＲＡＮ ＷＧ２＃１０４，Ｓｐｏｋａｎｅ，ＵＳＡ，２０１８年１１月１２～１６日による。

【0186】

以下の略語の少なくとも一部が本開示で使用されることがある。略語の間に不一致がある場合、上記でどのように使用されているかを優先するものとする。以下で複数回列挙されている場合、最初の列挙をその後の列挙よりも優先するものとする。

【0187】

略語の説明
５ＧＳ ５Ｇシステム
５ＧＣ ５Ｇコアネットワーク
ＡＭＦ アクセスおよびモビリティ管理機能
ＣＨＯ 条件付きハンドオーバ
Ｃ－ＲＮＴＩ セルＲＮＴＩ
ＤＬ ダウンリンク
ｅＮＢ エボルブドノードＢ
ｅＭＢＢ 拡張メイク・ビフォア・ブレーク
Ｅ－ＵＴＲＡＮ 進化型ユニバーサル地上無線アクセスネットワーク
ＥＰＣ 進化型パケットコアネットワーク
ｇＮＢ ５ＧノードＢ
ＨＯ ハンドオーバ
ＩＥ 情報要素
ＬＴＥ ロングタームエボリューション
ＭＢＢ メイク・ビフォア・ブレーク
ＮＣＣ ネクストホップチェイニングカウンタ
ＮＧ－ＲＡＮ 次世代無線アクセスネットワーク
ＮＲ 新無線
ＰＤＣＰ パケットデータコンバージェンスプロトコル
ＲＡ ランダムアクセス
ＲＡＲ ランダムアクセス応答
ＲＡＴ 無線アクセス技術
ＲＮＴＩ 無線ネットワーク一時識別子
ＲＲＣ 無線リソース制御
Ｒｘ 受信
ＳＤＵ サービスデータユニット
ＳＮ シーケンス番号
Ｔｘ 送信
ＵＥ ユーザ機器
ＵＬ アップリンク
ＵＰＦ ユーザプレーン機能

【図1】

【図2】

【図3】

【図4】

【図5A】

【図5B】

【図5C】

【図6A】

【図6B】

【図7A】

【図7B】