JP7168048B2 - ターゲットｒａｎノード、５ｇコアネットワーク装置、及びこれらの方法 - Google Patents

Description

本開示は、無線通信システムに関し、特に異なるRadio Access Technologies（RATs）の間での無線端末のハンドオーバに関する。

3rd Generation Partnership Project（3GPP）は、2020年移行の導入に向けた第5世代移動通信システム（5G）の標準化作業を3GPP Release 14として2016年に開始している（非特許文献１を参照）。5Gは、LTE及びLTE-Advancedの継続的な改良・発展（enhancement/evolution）と新たな5Gエア・インタフェース（新たなRadio Access Technology（RAT））の導入による革新的な改良・発展の組合せで実現されると想定されている。新たなRATは、例えば、LTE/LTE-Advancedの継続的発展が対象とする周波数帯（e.g., 6 GHz以下）よりも高い周波数帯、例えば10 GHz以上のセンチメートル波帯及び30 GHz以上のミリ波帯をサポートする。

本明細書では、第5世代移動通信システムは、Next Generation (NextGen) System（NG System）とも呼ばれる。NG Systemのための新たなRATは、New Radio（NR）、5G RAT、又はNG RATと呼ばれる。NG Systemのための新たな無線アクセスネットワーク（Radio Access Network（RAN））及びコアネットワークは、それぞれNextGen RAN（NG RAN）及びNextGen Core（NG Core）と呼ばれる。NG Systemに接続する無線端末（User Equipment（UE））は、NextGen UE（NG UE）と呼ばれる。NG SystemのためのRAT、UE、無線アクセスネットワーク、コアネットワーク、ネットワーク・エンティティ（ノード）、及びプロトコルレイヤ等の正式な名称は、標準化作業が進む過程で将来的に決定されるであろう。

また、本明細書で使用される“LTE”との用語は、特に断らない限り、NG Systemとのインターワーキングを可能とするためのLTE及びLTE-Advancedの改良・発展を含む。NG System とのインターワークのためのLTE及びLTE-Advancedの改良・発展は、LTE-Advanced Pro、LTE+、又はenhanced LTE（eLTE）とも呼ばれる。さらに、本明細書で使用される“Evolved Packet Core (EPC)”、“Mobility Management Entity (MME)”、“Serving Gateway (S-GW)”、及び“Packet Data Network (PDN) Gateway (P-GW)”等のLTEのネットワーク又は論理的エンティティに関する用語は、特に断らない限り、NG Systemとのインターワーキングを可能とするためのこれらの改良・発展を含む。改良されたEPC、MME、S-GW、及びP-GWは、例えば、enhanced EPC（eEPC）、enhanced MME（eMME）、enhanced S-GW（eS-GW）、及びenhanced P-GW（eP-GW）とも呼ばれる。

LTE及びLTE-Advancedでは、Quality of Service（QoS）及びパケットルーティングのために、QoSクラス毎且つPDNコネクション毎のベアラがRAN（i.e., Evolved Universal Terrestrial RAN）及びコアネットワーク（i.e., Evolved Packet core（EPC））の両方で使用される。すなわち、Bearer-based QoS（or per-bearer QoS）コンセプトでは、UEとEPC内のP-GWとの間に１又は複数のEvolved Packet System (EPS) bearersが設定され、同じQoSクラスを持つ複数のサービスデータフロー（Service Data Flows（SDFs））はこれらのQoSを満足する１つのEPS bearerを通して転送される。SDFは、Policy and Charging Control (PCC) ルールに基づくSDFテンプレート（i.e., packet filters）にマッチする１又は複数のパケットフローである。また、パケットルーティングのために、EPS bearerを通って送られる各パケットは、このパケットがどのベアラ（i.e., General Packet Radio Service (GPRS) Tunneling Protocol（GTP）トンネル）に関連付けられているかを見分ける（identify）ための情報を包含する。

これに対して、NG Systemでは、無線ベアラがNG RAN において使用されるかもしれないが、NG Core及びNG CoreとNG RANの間のインタフェースにおいてベアラは使用されないことが検討されている（非特許文献１を参照）。具体的には、EPS bearerの代わりにPDU flowsが定義され、１又は複数のSDFsは、１又は複数のPDU flowsにマップされる。NG UEとNG Core内のユーザプレーン終端エンティティ（i.e., EPC内のP-GWに相当するエンティティ）との間のPDU flowは、EPS Bearer-based QoSコンセプトにおけるEPSベアラに相当する。すなわち、NG Systemは、Bearer-based QoSコンセプトの代わりにFlow-based QoS（or per-flow QoS）コンセプトを採用する。Flow-based QoS コンセプトでは、QoSはPDU flow単位で取り扱われる（handled）。なお、UEとデータネットワークとの間の関連付け（association）は、PDUセッション（PDU session）と呼ばれる。PDUセッションは、LTE及びLTE-AdvancedのPDNコネクション（PDN connection）に相当する用語である。複数のPDU flowsが１つのPDUセッション内に設定されることができる。

本明細書では、LTE及びLTE-Advancedシステムのように、UEとコアネットワーク内のエッジノード（e.g., P-GW）との間にend-to-endベアラ（e.g., EPS bearer）を設定し、Bearer-based QoSコンセプトを採用するシステムを、“bearer-based system”又は“bearer-based network”と呼ぶ。一方、NG Systemのように、コアネットワーク及びコアネットワークとRANのインタフェースにおいてベアラを使用せず、Flow-based QoSコンセプトを採用するシステムを“bearer-less system”又は“bearer-less network”と呼ぶ。上述したNG Systemのように、bearer-less networkのRANでは無線ベアラが使用されてもよい。“bearer-less”との用語は、例えば、GTP-less, (PDN) connection-less, tunnel-less, (IP) flow-based, SDF-based, stream-based, 又は(PDU) session-basedと言い換えることもできる。

さらに、NG Systemがnetwork slicingをサポートすることも検討されている（非特許文献１を参照）。Network slicingは、Network Function Virtualization（NFV）技術及びsoftware-defined networking（SDN）技術を使用し、複数の仮想化された論理的なネットワークを物理的なネットワークの上に作り出すことを可能にする。各々の仮想化された論理的なネットワークは、ネットワークスライス（network slice）又はネットワークスライス・インスタンス（network slice instance）と呼ばれ、論理的なノード（nodes）及び機能（functions）を含み、特定のトラフィック及びシグナリングのために使用される。NG RAN若しくはNG Core又はこれら両方は、Slice Selection Function（SSF）を有する。SSFは、NG UE及びNG Coreの少なくとも一方によって提供される情報に基づいて、当該NG UEのために適した１又は複数のネットワークスライスを選択する。

なお、特許文献１は、bearer-less network（e.g., 5G）からbearer-based network（e.g., LTE）へのハンドオーバ、及びbearer-based network（e.g., LTE）からbearer-less network（e.g., 5G）へのハンドオーバに関する開示を含む。特許文献１に示された5GからLTEへのハンドオーバでは、5Gコア（NG Core）のsource制御ノード（i.e., Access Control Server (ACS)/eMME）は、bearer-less network（5G）のservice flowsのQoS parametersをbearer-based network （LTE）のEPS-bearer-level QoSにマップする。5Gのservice flowsのQoS parameters は、例えば、DiffServ code point (DSCP) valuesである。LTEのEPS-bearer-level QoSは、例えば、QoS class identifier（QCI）及びallocation and retention priority（ARP）である。DSCP valuesのEPS bearersへのマッピングは、一対一またはｎ対一で行われてもよい。Source ACS/eMMEは、EPS-bearer-level QoS の情報を含むAPN information をtarget MMEに送る。Target MMEは、受信したAPN informationに従って、UEのためのGTP tunnelsをセットアップする。

また、特許文献１に示されたLTEから5Gへのハンドオーバでは、LTEコア（i.e., EPC）のsource MMEは、必要な bearer context informationを包含するforward relocation requestを5Gコア（NG Core）のtarget ACS/eMMEに送る。target ACS/eMMEは、LTE（i.e., source MME）から取得したQCI valuesを5G QoS parameters （i.e., DSCP values）にマップし、これを5Gコア（NG Core）の転送ノード（i.e., Mobility Gateway Access Router (M-GW/AR) 又は Mobility Gateway Edge Router (M-GW/ER)）に供給する。これにより、Target ACS/eMMEは、UEのservice flows（i.e., IP packets）を送るための少なくとも１つのGeneric Routing Encapsulation (GRE) tunnelをセットアップする。

国際公開第２０１５／１６０３２９号

3GPP TR 23.799 V0.6.0 (2016-07) "3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Study on Architecture for Next Generation System (Release 14)", July 2016

本件発明者等は、bearer-based network（e.g., LTE）とbearer-less network（e.g., 5G）との間のハンドオーバに関して検討を行い、いくつかの課題を見出した。例えば、特許文献１は、bearer-based network（e.g., LTE）からbearer-less network（e.g., 5G）へのハンドオーバにおいて、5Gコア（NG Core）内のtarget ACS/eMMEが、LTE（i.e., source MME）から取得したQCI valuesを5G QoS parameters （i.e., DSCP values）にマップし、これを5Gコア（NG Core）の転送ノード（i.e., Mobility Gateway Access Router (M-GW/AR) 又は Mobility Gateway Edge Router (M-GW/ER)）に供給することを開示している。しかしながら、特許文献１は、LTEから5Gへのハンドオーバ手順の間に、UE、E-UTRAN内のsource eNodeB（eNB）、及び5G RAN（NG RAN）内のtarget 5G Access Point（AP）によって行われる処理（特に、Access Stratum（AS）レイヤの処理）の詳細について記載していない。

したがって、本明細書に開示される実施形態が達成しようとする目的の１つは、bearer-based network（e.g., LTE）とbearer-less network（e.g., 5G）との間のハンドオーバにおいてtarget RATのASレイヤ設定を適切に行うことに寄与する装置、方法、及びプログラムを提供することである。なお、この目的は、本明細書に開示される複数の実施形態が達成しようとする複数の目的の１つに過ぎないことに留意されるべきである。その他の目的又は課題と新規な特徴は、本明細書の記述又は添付図面から明らかにされる。

一態様では、ベアラレス・ネットワークに関連付けられたターゲット無線アクセスネットワーク（RAN）ノードは、少なくとも１つのメモリと、前記少なくとも１つのメモリに結合された少なくとも１つのプロセッサとを含む。前記少なくとも１つのプロセッサは、ベアラベースド・ネットワークから前記ベアラレス・ネットワークへの無線端末のハンドオーバを要求するhandover requestメッセージをコアネットワークから受信するよう構成されている。前記handover requestメッセージは、前記無線端末の少なくとも１つのパケットフローを転送するために前記ベアラレス・ネットワーク内で確立される少なくとも１つのセッションに関するフロー情報を含む。前記少なくとも１つのプロセッサは、さらに、前記handover requestメッセージに応答して、Target to Source Transparent Containerを包含するhandover request acknowledgeメッセージを前記コアネットワークに送信するよう構成されている。前記Target to Source Transparent Containerは、前記フロー情報から導かれる無線リソース設定情報を包含し、且つ前記コアネットワークを介して前記ベアラベースド・ネットワークに関連付けられたソースRANノードにフォワードされる。

一態様では、ベアラベースド・ネットワークに関連付けられたソース無線アクセスネットワーク（RAN）ノードは、少なくとも１つのメモリと、前記少なくとも１つのメモリに結合された少なくとも１つのプロセッサとを含む。前記少なくとも１つのプロセッサは、前記ベアラベースド・ネットワークからベアラレス・ネットワークへの無線端末のハンドオーバを開始するためのhandover requiredメッセージをコアネットワークに送信し、Target to Source Transparent Containerを包含するhandover commandメッセージを前記コアネットワークから受信するよう構成されている。前記Target to Source Transparent Containerは、前記ベアラレス・ネットワークに関連付けられたターゲットRANノードによって生成され、前記無線端末の少なくとも１つのパケットフローを転送するために前記ベアラレス・ネットワーク内で確立される少なくとも１つのセッションに関連付けられた無線コネクションを確立するために前記無線端末にとって必要となる無線リソース設定情報を包含する。前記少なくとも１つのプロセッサは、さらに、前記無線リソース設定情報を包含し且つ前記ベアラレス・ネットワークへのハンドオーバを示すmobility commandメッセージを前記無線端末に送信するよう構成されている。

一態様では、無線端末は、少なくとも１つのメモリと、前記少なくとも１つのメモリに結合された少なくとも１つのプロセッサとを含む。前記少なくとも１つのプロセッサは、ベアラベースド・ネットワークからベアラレス・ネットワークへのハンドオーバを示すmobility commandメッセージを前記ベアラベースド・ネットワークに関連付けられた無線アクセスネットワーク（RAN）ノードから受信するよう構成されている。前記mobility commandメッセージは、前記ベアラレス・ネットワークに関連付けられたターゲットRANノードによって生成され、前記無線端末の少なくとも１つのパケットフローを転送するために前記ベアラレス・ネットワーク内で確立される少なくとも１つのセッションに関連付けられた無線コネクションを確立するために前記無線端末にとって必要となる無線リソース設定情報を包含する。前記少なくとも１つのプロセッサは、さらに、前記無線リソース設定情報を用いて、前記ベアラレス・ネットワークに関連付けられた前記ターゲットRANノードとの前記無線コネクションを確立するよう構成されている。

一態様では、ベアラレス・ネットワークに関連付けられたターゲット無線アクセスネットワーク（RAN）ノードにおける方法は、
ベアラベースド・ネットワークから前記ベアラレス・ネットワークへの無線端末のハンドオーバを要求するhandover requestメッセージをコアネットワークから受信すること、ここで、前記handover requestメッセージは、前記無線端末の少なくとも１つのパケットフローを転送するために前記ベアラレス・ネットワーク内で確立される少なくとも１つのセッションに関するフロー情報を含み；及び
前記handover requestメッセージに応答して、Target to Source Transparent Containerを包含するhandover request acknowledgeメッセージを前記コアネットワークに送信すること、ここで、前記Target to Source Transparent Containerは、前記フロー情報から導かれる無線リソース設定情報を包含し、且つ前記コアネットワークを介して前記ベアラベースド・ネットワークに関連付けられたソースRANノードにフォワードされる；
を含む。

一態様では、ベアラベースド・ネットワークに関連付けられたソース無線アクセスネットワーク（RAN）ノードにおける方法は、
前記ベアラベースド・ネットワークからベアラレス・ネットワークへの無線端末のハンドオーバを開始するためのhandover requiredメッセージをコアネットワークに送信すること；
Target to Source Transparent Containerを包含するhandover commandメッセージを前記コアネットワークから受信すること、ここで、前記Target to Source Transparent Containerは、前記ベアラレス・ネットワークに関連付けられたターゲットRANノードによって生成され、前記無線端末の少なくとも１つのパケットフローを転送するために前記ベアラレス・ネットワーク内で確立される少なくとも１つのセッションに関連付けられた無線コネクションを確立するために前記無線端末にとって必要となる無線リソース設定情報を包含し；及び
前記無線リソース設定情報を包含し且つ前記ベアラレス・ネットワークへのハンドオーバを示すmobility commandメッセージを前記無線端末に送信すること；
を含む。

一態様では、無線端末における方法は、
ベアラベースド・ネットワークからベアラレス・ネットワークへのハンドオーバを示すmobility commandメッセージを前記ベアラベースド・ネットワークに関連付けられた無線アクセスネットワーク（RAN）ノードから受信すること、ここで、前記mobility commandメッセージは、前記ベアラレス・ネットワークに関連付けられたターゲットRANノードによって生成され、前記無線端末の少なくとも１つのパケットフローを転送するために前記ベアラレス・ネットワーク内で確立される少なくとも１つのセッションに関連付けられた無線コネクションを確立するために前記無線端末にとって必要となる無線リソース設定情報を包含し；及び
前記無線リソース設定情報を用いて、前記ベアラレス・ネットワークに関連付けられた前記ターゲットRANノードとの前記無線コネクションを確立すること；
を含む。

一態様では、プログラムは、コンピュータに読み込まれた場合に、上述の態様に係る方法をコンピュータに行わせるための命令群（ソフトウェアコード）を含む。

上述の態様によれば、bearer-based network（e.g., LTE）とbearer-less network（e.g., 5G）との間のハンドオーバにおいてtarget RATのASレイヤ設定を適切に行うことに寄与する装置、方法、及びプログラムを提供できる。

いくつかの実施形態に係る無線通信ネットワークの構成例を示す図である。 いくつかの実施形態に係る無線通信ネットワークの構成例を示す図である。 第１の実施形態に係る、LTE SystemからNG Systemへのinter-RATハンドオーバ手順の一例を示すシーケンス図である。 第１の実施形態に係る、LTE SystemからNG Systemへのinter-RATハンドオーバ手順の一例を示すシーケンス図である。 第１の実施形態に係る、LTE SystemからNG Systemへのinter-RATハンドオーバ手順の他の例を示すシーケンス図である。 第１の実施形態に係る、LTE SystemからNG Systemへのinter-RATハンドオーバ手順の他の例を示すシーケンス図である。 第１の実施形態に係るコアネットワークにより行われる方法の一例を示すフローチャートである。 第１の実施形態に係るターゲットNR NodeB（NR NB）により行われる方法の一例を示すフローチャートである。 第１の実施形態に係るソースLTE eNBにより行われる方法の一例を示すフローチャートである。 第１の実施形態に係る無線端末により行われる方法の一例を示すフローチャートである。 第２の実施形態に係る、NG SystemからLTE Systemへのinter-RATハンドオーバ手順の一例を示すシーケンス図である。 第２の実施形態に係る、NG SystemからLTE Systemへのinter-RATハンドオーバ手順の一例を示すシーケンス図である。 第２の実施形態に係る、NG SystemからLTE Systemへのinter-RATハンドオーバ手順の他の例を示すシーケンス図である。 第２の実施形態に係る、NG SystemからLTE Systemへのinter-RATハンドオーバ手順の他の例を示すシーケンス図である。 幾つかの実施形態に係る無線端末の構成例を示すブロック図である。 幾つかの実施形態に係る基地局の構成例を示すブロック図である。 幾つかの実施形態に係る基地局の構成例を示すブロック図である。 幾つかの実施形態に係るコアネットワークノードの構成例を示すブロック図である。 Mobility from EUTRA commandメッセージのフォーマットの一例を示す図である。 Mobility from EUTRA commandメッセージのフォーマットの一例を示す図である。 Handover Requiredメッセージのフォーマットの一例を示す図である。 Source NR NB to Target NR NB Transparent Containerのフォーマットの一例を示す図である。 Source NR NB to Target NR NB Transparent Containerのフォーマットの一例を示す図である。 Source NR NB to Target NR NB Transparent Containerのフォーマットの一例を示す図である。 Source NR NB to Target NR NB Transparent Containerのフォーマットの一例を示す図である。 (NR) Handover Requestメッセージのフォーマットの一例を示す図である。 (NR) Handover Requestメッセージのフォーマットの一例を示す図である。 (NR) Handover Requestメッセージのフォーマットの一例を示す図である。 Slice Informationのフォーマットの一例を示す図である。 Session Endpoint IDのフォーマットの一例を示す図である。 (NR) Handover Request Acknowledgeメッセージのフォーマットの一例を示す図である。 Target to Source Transparent Containerのフォーマットの一例を示す図である。 (NR) Handover Request Acknowledgeのフォーマットの一例を示す図である。 (NR) Handover Request Acknowledgeのフォーマットの一例を示す図である。 Forwarding Addressのフォーマットの一例を示す図である。 S1AP Handover Commandメッセージのフォーマットの一例を示す図である。 NG2AP Handover Commandメッセージのフォーマットの一例を示す図である。

以下では、具体的な実施形態について、図面を参照しながら詳細に説明する。各図面において、同一又は対応する要素には同一の符号が付されており、説明の明確化のため、必要に応じてこれらに関する重複説明は省略される。

以下に説明される複数の実施形態は、独立に実施されることもできるし、適宜組み合わせて実施されることもできる。これら複数の実施形態は、互いに異なる新規な特徴を有している。したがって、これら複数の実施形態は、互いに異なる目的又は課題を解決することに寄与し、互いに異なる効果を奏することに寄与する。

＜第１の実施形態＞
図１は、本実施形態を含む幾つかの実施形態に係る無線通信ネットワークの構成例を示している。図１の例では、無線通信ネットワークは、無線端末（UE）１、LTE基地局（i.e., eNB）２、New Radio (NR) 基地局（i.e., NR NodeB (NR NB)）３、EPC４、及びNextGen (NG) Core５を含む。UE１は、LTE eNB２及びEPC４を含むLTEシステムに接続する能力を有し、且つNR NB３及びNG Core５を含むNextGen（NG）システムに接続する能力を有する。

図１の例では、EPC４はNG Core５に接続されている。具体的には、EPC４内の１又は複数のノードは、コントロールプレーン・インタフェースを介してNG Core５内の１又は複数のノードに接続される。幾つかの実装において、EPC４内のMMEは、コントロールプレーン・インタフェースを介してNG Core５内のMMEの機能の少なくとも一部を有する制御ノード（i.e., Control Plane Function (CPF)ノード）に接続されてもよい。さらに、EPC４内の１又は複数のノードは、ユーザプレーン・インタフェースを介してNG Core５内の１又は複数のデータノード（i.e., User Plane Function (UPF)ノード）に接続されてもよい。ここで、該データノード（UPFノード）は、S-GWの機能の少なくとも一部を有するノードでもよい。すなわち、EPC４は、NG Core５を含むNG Systemとのインターワーキングを行うよう改良（enhanced）されていて、eEPCと呼ばれてもよい。

同様に、NR NB３は、コントロールプレーン・インタフェース（e.g., NG2インタフェース）を介してNG Core５内の１又は複数のCPFノードに接続されてもよい。また、NR NB３は、ユーザプレーン・インタフェース（e.g., NG3インタフェース）を介してNG Core５内の１又は複数のUPFノードに接続されてもよい。さらに、UE１は、コントロールプレーン・インタフェース（e.g., NG1インタフェース）を介してNG Core５内の１又は複数のCPFノードに接続されてもよい。ここで、NG1インタフェースは、NASレイヤの情報を転送するための論理インタフェースとして定義され、当該NASレイヤの情報の送信は、NG2インタフェース、及びNR NB３とUE１の間の無線インタフェース（NG Uu）を介して行われてもよい。

図２は、本実施形態を含む幾つかの実施形態に係る無線通信ネットワークの他の構成例を示している。図２の例では、LTE eNB２は、NG Core５に接続されている。すなわち、LTE eNB２は、コントロールプレーン・インタフェース（e.g., NG2インタフェース）を介してNG Core５内のMME又はMMEの機能の少なくとも一部を有する制御ノード（i.e., CPFノード）に接続され、ユーザプレーン・インタフェース（e.g., NG3インタフェース）を介してNG Core５内のServing Gateway（S-GW）又はS-GWの機能の少なくとも一部を有するデータノード（i.e., UPFノード）に接続される。このようにLTE eNB２は、NG Core５と接続されるよう改良（enhanced）されていて、eLTE eNBと呼ばれてもよい。幾つかの実装において、NG Core５は、論理的なEPCノード（nodes）及びEPC機能（functions）を提供する仮想化されたネットワークスライスをセットアップしてもよい。幾つかの実装において、LTE eNB２を含むE-UTRAN及びNR NB３を含むNG RANは、同じネットワークスライスに接続されもよい。これに代えて、LTE eNB２を含むE-UTRAN及びNR NB３を含むNG RANは、互いに異なるネットワークスライスに接続されてもよい。

図１及び図２の例において、LTE eNB２は、ダイレクト基地局間インタフェース（e.g., X3インタフェース）によってNR NB３と接続されてもよい。ダイレクト基地局間インタフェースは、LTE eNB２とNR NB３との間のシグナリング若しくはユーザパケット転送又はこれら両方に使用されてもよい。しかしながら、LTE eNB２とNR NB３との間のダイレクト基地局間インタフェースは存在しなくてもよい。

NG Systemは、上述のNG1, NG2, NG3インタフェースに加え、さらに他のインタフェースを含んでもよい。インタフェースは、参照点（reference point）とも呼ばれる。NG RAN間（異なるNR NB間）は、NX2インタフェースを介して接続されてもよい。モビリティ管理機能（Mobility Management Function: MMF）及びセッション管理機能（Session Management Function: SMF）のいずれか又は両方を有するCPFノードは、UPFノードにコントロールプレーン・インタフェース（e.g., NG4インタフェース）を介して接続されてもよい。異なるUPFノード間は、ユーザプレーン・インタフェース（e.g., NG9インタフェース）を介して接続されてもよい。異なる機能を有するCPFノード間はコントロールプレーン・インタフェースを介して接続されてもよい。例えば、MMF及びSMFを有するCPFノードは、ポリシー制御機能（Policy Control Function: PCF）を有するCPFノードと、コントロールプレーン・インタフェース（e.g., NG7インタフェース）を介して接続されてもよい。MMF及びSMFを有するCPFノードは、加入者データ管理機能（Subscriber Data Management: SDM）を有するノードと、コントロールプレーン・インタフェース（e.g., NG8インタフェース）を介して接続されてもよい。CPFノードは、アプリケーション機能（Application Function: AF）を有するノードとコントロールプレーン・インタフェース（e.g., NG5インタフェース）を介して接続されてもよい。UPFノードは、外部またはローカルのデータネットワーク（Data Network: DN）とユーザプレーン・インタフェース（e.g., NG6インタフェース）を介して接続されてもよい。なお、SMFは、ユーザまたは端末の認証（Authentication）、サービスまたはネットワークスライシングの承認（Authorization）の機能を含んでもよい。なお、上述のネットワークノードのそれぞれを指して、又はそれらを総称してネットワーク機能（Network Function(s): NF(s)）とも呼ぶ。

NR NB３及びNG Core５を含むNG Systemは、上述したFlow-based QoS（or per-flow QoS）コンセプトに基づくデータ転送をサポートする。NR NB３及びNG Core５を含むNG Systemは、さらに、QoSクラス毎且つPDUセッション毎のベアラを用いるベアラベースド転送をサポートするよう構成されてもよい。NG Systemのベアラは、ネットワーク機能（Network Functions（NFs））のペアの間、例えば、NR NB３とNG Core５内のユーザプレーン機能の間、又はNG Core５内の２つのユーザプレーン機能の間に設定されてもよい。これに代えて、NG Systemのベアラは、UE１とNG Core５内のユーザプレーン機能の間にNR NB3を介して設定されてもよい。NG SystemのベアラはNG-EPS-bearerと呼ばれてもよく、NG Systemの無線アクセスベアラはNG-RABと呼ばれてもよい。NG Systemのベアラは、複数のパケットフロー（PDU flows）の転送に利用されることができる。

NG-RABは、UE１（NG UE）とNR NB３との間に設定される無線ベアラと、NR NB３とNG Core５内のユーザプレーン機能（e.g., Edge Gateway（Edge GW））との間に設定されるベアラ（e.g., NG3ベアラ）とから構成されてもよい。NG-EPS-bearerは、NG-RABと、NG Core５内のユーザプレーン機能の間（e.g., Edge GWとData Network Gateway（DN GW）との間）に設定されるコアネットワークベアラ（e.g., NG9ベアラ）とから構成されてもよい。Edge GWは、無線アクセスネットワークとのゲートウェイであり、LTEのS-GWのユーザプレーン機能に相当する。ただし、LTEのS-GWとは異なり、NG SystemではUE１が複数のEdge GWと接続されてもよい。DN GWは、外部ネットワーク（i.e., Data Network）とのゲートウェイであり、LTEのP-GWのユーザプレーン機能に相当する。なお、LTEのP-GWと同様に、NG SystemではUE１が複数のDN GWと接続されてもよい。

より具体的に述べると、NG-EPS-bearerは、UE１（NG UE）とNG Core５内のスライス固有ユーザプレーン機能（Slice specific User plane NF (SUNF)）との間に設定されてもよい。NG-RABは、UE１（NG UE）とNG Core５内の共通ユーザプレーン機能（Common User plane NF (CUNF)）との間に設定されてもよい。この場合、CUNFはEdge GWの機能を提供し、SUNFはDN GWの機能を提供する。CUNFは、NG-RABとコアネットワークベアラ（e.g., NG9ベアラ）との間を関連付けてもよい。すなわち、NG-EPS-bearerは、UE１（NG UE）とCUNFとの間のNG-RABと、CUNFとSUNFとの間のコアネットワークベアラ（e.g., NG9ベアラ）とから構成されてもよい。

ベアラベースド転送をサポートするNG Systemは、さらに、データフロー（PDU flow）毎のQoSハンドリング(e.g., パケット破棄)のためにベアラ内のデータフロー（PDU flow）を特定するよう構成されてもよい。例えば、NR NB３は、NR NB３とNG Core５内のユーザプレーン機能の間に設定されたベアラ（e.g., NG3ベアラ）を無線ベアラに関連付け、当該ベアラ（e.g., NG3ベアラ）と当該無線ベアラの間のパケットフォワーディングを行い、さらにベアラ内のデータフロー（PDU flow）毎のQoSハンドリング(e.g., パケット破棄)を行ってもよい。

なお、(e)LTE eNB２がNG Core５にNG2インタフェースで接続される場合、LTEのEPS Radio Access Bearer（E-RAB）に相当する無線アクセスベアラは、NG EPS Radio Access Bearer（NE-RAB）として定義され、LTEのEPS bearerに相当するベアラはNG EPS bearer（NEPS bearer）として定義されてもよい。NE-RABは、UE１とLTE eNB２との間に設定される無線ベアラと、LTE eNB２とNG Core５内のユーザプレーン機能（e.g., Edge GW又はCUNF）との間に設定されるベアラ（e.g., NG3ベアラ）とから構成されてもよい。NEPS bearerは、NE-RABと、NG Core５内のユーザプレーン機能の間（e.g., Edge GWとDN GWとの間、又はCUNFとSUNFとの間）に設定されるコアネットワークベアラ（e.g., NG9ベアラ）とから構成されてもよい。

NG Systemに接続されるLTE eNB２は、データフロー（PDU flow）毎のQoSハンドリング(e.g., パケット破棄)のためにNE-RAB内のデータフロー（PDU flow）を特定するよう構成されてもよい。例えば、LTE eNB２は、LTE eNB２とNG Core５内のユーザプレーン機能の間に設定されたベアラ（e.g., NG3ベアラ）を無線ベアラに関連付け、当該ベアラ（e.g., NG3ベアラ）と当該無線ベアラの間のパケットフォワーディングを行い、さらにベアラ内のデータフロー（PDU flow）毎のQoSハンドリング(e.g., パケット破棄)を行ってもよい。

本実施形態は、LTE System（i.e., bearer-based network）からNG System（i.e., bearer-less network）へのUE１のハンドオーバ方法を提供する。図３Ａ及び図３Ｂは、図１に示された無線通信ネットワークの構成例におけるLTE SystemからNG SystemへのUE１のハンドオーバ手順の一例を示している。図３Ａは、ハンドオーバの準備（preparation）フェーズを示し、図３Ｂは、ハンドオーバの実施（execution）フェーズを示している。

図３Ａ及び図３Ｂに示された手順では、ソース基地局（i.e., LTE eNB２）は、ソース基地局（i.e., LTE eNB２）とコアネットワーク（i.e., EPC４）との間のインタフェース（又は参照点（reference point））上でHandover Requiredメッセージを送ることによって、ハンドオーバを開始する。したがって、図３Ａ及び図３Ｂに示された手順は、LTEの“E-UTRAN to UTRAN Iu mode Inter RAT handover”の改良・発展であってもよい。あるいは、図３Ａ及び図３Ｂに示された手順は、LTEのMME relocationを伴う“S1-based handover”の改良・発展であってもよい。

ステップ３０１では、UE１は、LTE eNB２に接続され、コネクテッド状態（i.e., RRC_Connected）である。UE１は、測定設定（Measurement Configuration）をLTE eNB２から受信し、当該測定設定に従ってE-UTRAN (LTE) cells及びNG-RAN cellsを含む隣接セル測定（neighbor cell measurements）及び異種無線アクセス技術（Radio Access Technology）測定（inter-RAT measurements）を実行し、測定報告（measurement report）をLTE eNB２に送る。測定設定は、例えばE-UTRANからUEへ送信されるRRC Connection Reconfigurationメッセージに含まれる。

ステップ３０２では、LTE eNB２は、NR NB３のセルへのinter-RATハンドオーバを決定し、Handover RequiredメッセージをEPC４内のソース制御ノード（i.e., ソースMME）に送る。当該Handover Requiredメッセージは、ターゲットNR NB３の識別子を包含する。さらに、当該Handover Requiredメッセージは、LTEからNRへのハンドオーバであることを示すハンドオーバ種別 情報要素（Handover Type Information Element (IE)）を包含してもよい。Handover Type IEは、例えば、“LTEtoNR”がセットされる。さらに又はこれに代えて、当該Handover Requiredメッセージは、ターゲットNR-NB識別子 情報要素（Target NR-NB Identifier IE）を包含してもよい。当該Handover Requiredメッセージは、Source to Target Transparent Container IEを包含してもよい。Source to Target Transparent Container IEは、RRCレイヤの情報（RRC container）を含んでもよく、さらにベアラ（e.g., E-RAB）情報を含んでもよい。RRCレイヤの情報（RRC container）は、例えば、NR NB３の無線リソースの設定に必要となる、LTE eNB２が管理するUE１のサービングセルにおける無線リソース設定（Radio Resource Configuration）の少なくとも一部を含む。

ステップ３０３では、EPC４内のソースMMEは、受信したHandover Requiredメッセージ内のHandover Type IE又はTarget NR-NB Identifier IEから、当該ハンドオーバの種別がNR（又はNG System）へのInter-RATハンドオーバであることを判定する。EPC４内のソースMMEは、NG Core５内のターゲット制御ノードを選択する。ターゲット制御ノードは、EPC４内のMMEの機能の少なくとも一部を有するノードである。EPC４内のソースMMEは、Forward Relocation Requestメッセージをターゲット制御ノードに送ることによって、ハンドオーバリソース割り当て手順（Handover resource allocation procedure）を開始する。当該Forward Relocation Requestメッセージは、Mobility Management (MM) Context、及びUE１のためにソースシステム（i.e., LTEシステム）においてアクティブである全てのPDNコネクションを包含する。各PDNコネクションは、associated APN及びEPS Bearer Contextsのリストを含む。MM Contextは、EPS bearer context(s)についての情報、及びセキュリティ関連情報（security related information）を含む。さらに、当該Forward Relocation Requestメッセージは、各EPS bearer contextに関連付けられた１又は複数のサービスデータフローを特定するための情報（e.g., SDF templates、又はTraffic Flow Templates（TFTs））を含む。

ステップ３０４では、NG Core５内のターゲット制御ノードは、ベアラレス・セッションの生成（creation）手順を行う。具体的には、ターゲット制御ノードは、UE１のためのパケット転送ノード（ゲートウェイ）が再配置（relocated）される必要があることを判定し、NG Core５内のターゲット転送ノード（ゲートウェイ）を選択する。ターゲット転送ノード（ゲートウェイ）は、EPC４内のS-GWの機能の少なくとも一部を有するノードである。ターゲット制御ノードは、ターゲット転送ノード（ゲートウェイ）にCreate Session Requestメッセージを送る。当該Create Session Requestメッセージは、各EPS bearer contextに関連付けられた１又は複数のサービスデータフローを特定するための情報（e.g., SDF templates、又はTraffic Flow Templates（TFTs））を含む。当該１又は複数のサービスデータフローを特定するための情報は、EPC４内のソースMMEからNG Core５内のターゲット制御ノードに送られるForward Relocation Requestメッセージから導かれる。ターゲット転送ノード（ゲートウェイ）は、そのローカルリソースを割り当て、Create Session Responseメッセージをターゲット制御ノードに返信する。

さらに、ステップ３０４では、NG Core５内のターゲット制御ノード（e.g., CPF）は、ハンドオーバ後のUE１に接続させるネットワークスライスを決定（選択）してもよい。一例において、NG Core５内のターゲット制御ノード（CPF）は、UE１のEPS bearer(s)又はSDF(s)のために必要なQoSに基づいてUE１のためのネットワークスライスを選択してもよい。さらに又はこれに代えて、EPC４内のソースMMEによって送られるForward Relocation Requestメッセージ（ステップ３０３）は、ネットワークスライス支援情報（network slice assistance information）をさらに包含してもよい。ネットワークスライス支援情報は、ターゲット制御ノードによるネットワークスライスの選択、設定、又は承認をアシストする。EPC４内のソースMMEは、ネットワークスライス支援情報の少なくとも一部をUE１から受信し、これをNG Core５内のターゲット制御ノードに送ってもよい。NG Core５内のターゲット制御ノードは、選択されたネットワークスライス・インスタンスの生成（creation）を実行してもよい。

ネットワークスライス支援情報は、例えば、UE１の種別（e.g., Device Type, UE Category）、UE１のアクセス用途（e.g., UE Usage Type）、UE１が希望するサービス種別（e.g., Requested/Preferred Service Type, MDD、Multi-Dimensional Descriptor (MDD)）、UE１が選択したスライス情報（e.g., Selected Slice Type、Selected Slice Identity (ID), Selected Network Function (NF) ID）、UE１が予め承認されたスライス情報（e.g., Authorized Slice Type, Authorized Slice ID, Authorized NF ID）、及びUE１の許容レイテンシ（e.g., Allowed Latency, Tolerable Latency）のいずれか又は任意の組合せを示してもよい。Service Typeは、例えば、Use Caseの種別（e.g., 広帯域通信（enhanced Mobile Broad Band: eMBB）、高信頼・低遅延通信（Ultra Reliable and Low Latency Communication: URLLC）、又は多接続M2M通信（massive Machine Type Communication: mMTC）又はこれらに準ずるもの）を示してもよい。Slice IDは、例えば、スライス・インスタンス情報（Network Slice Instance (NSI) ID）、個別ネットワーク情報（Dedicated Core Network (DCN) ID ）、及びネットワーク・ドメイン・ネーム情報（Domain Network Name (DNN) ID）のいずれか又は任意の組み合わせを示してもよい。NF IDは、例えば、共通ネットワーク機能（Common NF (CNF)）、共通コントロールプレーン機能（Common Control plane NF (CCNF)）、共通ユーザプレーン機能（Common User plane NF (CUNF)）、及びデータ・ゲートウェイ（Data Network Gateway (DN GW)）のいずれか又は任意の組み合わせの識別情報（ID）を示してもよい。

ステップ３０５では、NG Core５内のターゲット制御ノードは、ターゲットNR NB３にNR Handover Requestメッセージを送る。当該NR Handover Requestメッセージは、フロー情報（Flow Information）を包含する。フロー情報は、UE１の少なくとも１つのパケットフロー（i.e., PDU flow(s)）を転送するためにbearer-less network（i.e., NG system）内で確立される少なくとも１つのセッション（i.e., PDU session(s)）に関する。UE１の各パケットフロー（i.e., PDU flow）に関して、フロー情報は、フロー識別子（e.g., PDU flow ID）、NG Core５内の転送ノードのアドレス（Transport Layer Address）及びアップリンク（UL）のセッション・エンドポイント識別子（Session Endpoint Identifier（SEID））、並びにフローQoSパラメータを含む。セッション・エンドポイント識別子（SEID）は、例えばTunnel Endpoint Identifier (TEID)、又はネットワーク機能（ノード）識別子（NF ID）でもよい。TEIDは、例えば、GTP-TEID又はGRE-TEIDであってもよい。

当該フロー情報は、さらに、UE１のためのEPS bearersとPDU flowsとのマッピングを示してもよい。例えば、当該フロー情報は、UE１の各EPS bearerにマッピングされる１又は複数のSDFsと、これら１又は複数のSDFsの各々に割り当てられたフロー識別子（e.g., PDU flow ID）を示してもよい。さらに、フロー情報は、優先度情報（priority indicator）、フロータイプ情報（flow type indicator）、又は、フロー・クラス（Flow Class）を含んでもよい。優先度情報は、例えば複数フロー間の相対的な優先順位を示してもよいし、各フローの絶対的な優先順位を示してもよい。フロータイプ情報は、例えば、どのUse Case又はサービスに対応するフローかを示してもよい。また、フロー・クラスは、例えば、予め規定されたフロータイプ（e.g., loss-less, delay tolerant, delay sensitive, mission critical）のうち１つを示してもよい。

さらに、ステップ３０５のNR Handover Requestメッセージは、スライス情報（Slice Information）を包含してもよい。スライス情報は、ハンドオーバ後のUE１に接続する（接続される）NG Core５のネットワークスライスに関する情報、UE１に接続が許可されるNG Core５のネットワークスライスに関する情報、及びUE１が接続可能なNG Core５のネットワークスライスに関する情報のうち少なくとも１つを含む。

具体的には、スライス情報は、決定（選択）されたスライス（Network Slice: NS）の識別情報、ネットワークノード（NF）の識別情報、若しくはスライスの種別情報又はこれらの任意の組み合わせを含んでもよい。スライスの識別情報は、例えば、Slice ID, NSI ID, MDD, DCN ID,及びDNNのいずれか又は任意の組み合わせでもよい。ネットワークノードの識別情報は、例えば、NF ID, CNF ID, CCNF ID, SCNF ID, CUNF ID, SUNF ID, UPF ID, 及びDN GW IDのいずれか又は任意の組み合わせを含んでもよい。スライスの種別情報は、例えば、Service Type, Service Category, 及びUse Caseのいずれか又は任意の組み合わせを示すSlice Typeを含んでもよい。さらに又はこれに代えて、スライスの種別情報は、Use Case又は契約形態（Subscription Group, e.g. home UE or roaming UE）を示すTenant IDを含んでもよい。スライスの種別情報は、Slice Type及びTenant IDを要素に含むMDDを含んでもよい。なお、上述のスライス情報のコンテンツはネットワークスライス毎に指定されてもよい。従って、UE１が同時に複数のネットワークスライスに接続される場合、当該スライス情報は、UE１が接続されるネットワークスライスの数に相当する複数セットの情報を含んでもよい。

スライス情報は、さらにモビリティ・クラス（Mobility Class）若しくはセッション・クラス（Session Class）又は両方を含んでもよい。Mobility Classは、予め規定されたモビリティ・レベル（e.g., high mobility, low mobility, no mobility）のうち１つを示してもよい。例えば、high mobilityは、ネットワークスライスがUE１のためにモビリティをサポートする（UE１にモビリティを許可する）地理的範囲（geographical area）がlow mobilityのそれよりも広く、ハンドオーバ時のサービス（PDU session）の継続性（continuity）の要求度が高いことを意味する。No mobilityは、ネットワークスライスがUE１のためにごく限られた地理的範囲内でのみモビリティをサポートする（UE１にモビリティを許可する）ことを意味する。Mobility Classは、UE毎に指定されてもよいし、ネットワークスライス毎に指定されてもよい。Session Classは、予め規定されたセッション・タイプ（e.g., Session pre-setup, Session post-setup, No PDU session）のうち１つを示してもよい。例えば、Session pre-setupは、既存のハンドオーバのようにモビリティに応じてサービス（PDU Session）を維持するために、UEがターゲット（セル、ビーム、その他エリア）に移動完了するより先にPDU sessionを確立することが要求されることを示してもよい。これに対し、Session post-setupは、UEがターゲットに移動した後にPDU sessionが確立されればよいことを示してもよい。Session ClassはPDU session毎に指定されてもよい。Mobility Class及びSession Classは、Slice Type に包含されてもよい。言い換えると、Slice Typeは、Mobility Class及びSession Classを含む複数の属性を包含してもよい。なお、上述のフロー情報が、Mobility Class、Session Class、又は両方を含んでもよい。

スライス情報は、ネットワークスライス支援情報の少なくとも一部を含んでもよい。すなわち、ステップ３０５において、NG Core５内のターゲット制御ノードは、EPC４内のソースMMEから受信したネットワークスライス支援情報の少なくとも一部を、NR Handover Requestメッセージ内のスライス情報に含めてターゲットNR NB３に転送（Forwarding）してもよい。

ステップ３０６では、ターゲットNR NB３は、フロー情報を包含するNR Handover Requestメッセージの受信に応答して、パケットフロー（i.e., PDU flow(s)）についての情報及びセキュリティ・コンテキストを含むUEコンテキストを生成（create）し、リソースを割り当てる。さらに、ターゲットNR NB３は、bearer-less network（i.e., NG System）に関連付けられた無線コネクション（e.g., RRCコネクション、無線ベアラ）を確立するためにUE１にとって必要となる無線リソース設定情報（e.g., 無線パラメータ）を、フロー情報に基づいて生成する（又は、フロー情報から導出する）。無線リソース設定情報は、フロー情報に含まれる少なくとも１つのパラメータを含んでもよい。無線リソース設定情報は、ターゲットNR NB3のセル（又は、モビリティ・エリア、ビームカバーエリア）におけるシステム情報（System Information Block: SIB）、UE間共通の無線リソース設定（Common Resource Configuration）、又は、UE個別の無線リソース設定（Dedicated Resource Configuration）を含んでもよい。さらに、無線リソース設定情報は、ソースLTE eNB２のセルにおけるベアラ（e.g., EPS bearer, Data Radio Bearer (DRB)）とターゲットNR NB３のセルにおいて確立されるフロー（e.g., PDU flow）とのマッピングを示す情報を含んでもよい。

そして、ターゲットNR NB３は、Target to Source Transparent Containerを包含するNR Handover Request Acknowledgeメッセージをターゲット制御ノードに送る。当該Target to Source Transparent Containerは、ターゲットNR NB３によって生成された無線リソース設定情報を包含する。後述するように、Target to Source Transparent Containerは、コアネットワーク（i.e., EPC４及びNG Core５）を介してソースLTE eNB２にフォワードされる。

さらに、ステップ３０６では、ターゲットNR NB３は、スライス情報を包含するNR Handover Requestメッセージに基づいて、アドミッション制御を行ってもよい。例えば、ターゲットNR NB３は、ベアラ毎またはフロー毎に、ベアラ又はフローを受け入れるか否かを決定してもよい。さらに又はこれに代えて、ターゲットNR NB３は、スライス情報に基づいて、UE１が接続するネットワークスライス毎のアドミッション制御を行ってもよい。このとき、NR NB３は、各ネットワークスライスを受け入れることが可能か否かを判定してもよい、NR NB３は、受け入れることが不可能な（又は、受け入れない）ネットワークスライスがある場合、当該ネットワークスライスを特定のネットワークスライス（e.g., デフォルト・ネットワークスライス）にマッピングしてもよいし、当該ネットワークスライスを特定のNF（e.g., CUPF）に接続するようにしてもよい。あるいは、NR NB３は、当該ネットワークスライスの受け入れの失敗を決定してもよい。

ステップ３０６では、ターゲットNR NB３は、NR Handover Requestメッセージに包含されているスライス情報を、UEコンテキスト及び無線リソース設定情報（e.g., 無線パラメータ）の生成のために考慮してもよい。

スライス情報から導かれる無線リソース設定情報は、ネットワークスライス毎（又はユースケース毎）の無線（又はRAN）パラメータを含んでもよい。ユースケースは、例えば、enhanced mobile broadband (eMBB)、massive machine-type communications（mMTC）、及びUltra-reliable and low-latency communications（URLLC）を含む。ネットワークスライス毎（又はユースケース毎）の無線パラメータは、基本的な物理チャネル・パラメータ、若しくは基本的なレイヤ２／レイヤ３（L2/L3）設定であってもよい。基本的な物理チャネル・パラメータは、例えば、frame/subframe structure、Transmission Time. Interval (TTI) length、subcarrier spacing、及びPhysical Random Access Channel (PRACH) resourceを含んでもよい。PRACH resourceは、preamble index 若しくは time/frequency resources又はこれら両方であってもよい。基本的なL2/L3設定は、例えば、frame/subframe pattern、及びL2プロトコル・サブレイヤの設定（L2 configuration. E.g., PDCP config, RLC config, or MAC config）を含んでもよい。

さらに、又はこれに代えて、スライス情報から導かれる無線リソース設定情報を指定する（示す）RRCレイヤのシグナリングにおいて、メッセージ構成、情報要素（IE）のフォーマット、パラメータ値、並びに情報の構造定義を示すASN.1（Abstract Syntax Notation One）のエンコード及びデコードの対象、の少なくともいずれかは、スライス毎に異なっていてもよい。

ステップ３０７では、NG Core５内のターゲット制御ノードは、Target to Source Transparent Container を包含するForward Relocation ResponseメッセージをEPC４内のソースMMEに送る。さらに、Forward Relocation Responseメッセージは、ダウンリンク・データフォワーディングのために割り当てられたアドレス（Addresses）及びTEIDを含んでもよい。インダイレクト・ダウンリンク・フォワーディングが使用される場合、当該アドレス及びTEIDは、EPC４内のS-GWへのアドレス及びTEIDであってもよい。ダイレクト・ダウンリンク・フォワーディングが使用される場合、当該アドレス及びTEIDは、ターゲットNR NB３へのアドレス及びTEIDであってもよい。

ステップ３０８では、ソースMMEは、ソースLTE eNB２にTarget to Source Transparent Container を包含するHandover Commandメッセージを送る。Handover Commandメッセージは、さらに、ダウンリンク・データフォワーディングの対象とされるベアラのリスト（bearers subject to data forwarding list）を包含してもよい。“Bearers Subject to Data forwarding list”IEは、例えば、address(es) 及び TEID(s) for user traffic data forwarding、並びにデータフォワーディングの対象とされるフロー（PDU flow(s)）の識別子を含む。ソースLTE eNB２は、“Bearers Subject to Data forwarding list”IEにより指定されたベアラ又はフロー（PDU flow(s)）のためのデータフォワーディングを開始する。

ステップ３０９では、ソースLTE eNB２は、Handover Commandメッセージを包含するRadio Resource Control（RRC）メッセージをUE１に送る。当該Handover Commandメッセージは、ターゲットNR NB３が準備（preparation）フェーズにおいてセットアップした無線リソース設定情報を包含するtransparent containerを含む。当該RRCメッセージは、例えば、Mobility from EUTRA commandメッセージであってもよいし、RRC Connection Reconfigurationメッセージであってもよい。

ステップ３１０では、UE１は、Handover Commandメッセージを包含するRRCメッセージの受信に応答して、ターゲットRAN（i.e., NG RAN）に移動し、Handover Commandメッセージにおいて供給された無線リソース設定情報に従ってハンドオーバを実施する。すなわち、UE１は、bearer-less network（i.e., NG System）に関連付けられたターゲットNR NB３との無線コネクションを確立する。ステップ３１１では、UE１は、ターゲットセルに首尾よく（successfully）同期した後に、Handover Confirm for NRメッセージをターゲットNR NB３に送る。ステップ３１１のメッセージは、NR RRC Connection Reconfiguration Completeメッセージであってもよい。

ステップ３１２では、UE１がターゲットNR NB３に首尾よく（successfully）アクセスした場合に、ターゲットNR NB３は、NR Handover Notifyメッセージを送ることによって、NG Core５内のターゲット制御ノードに知らせる。

ステップ３１３では、NG Core５内のターゲット制御ノードは、UE１がターゲットサイドに到着したことを知り、Forward Relocation Complete Notification メッセージを送ることによって、EPC４内のソースMMEに知らせる。ソースMMEは、Forward Relocation Complete Acknowledge メッセージをターゲット制御ノードに送る。

ステップ３１４では、NG Core５内のターゲット制御ノードは、フロー修正（modification）手順を実施することによって、Inter-RAT ハンドオーバ手順を完了する。例えば、ターゲット制御ノードは、NG Core５内の転送ノードに、セッション（i.e., PDU session）毎のModify Flow Requestメッセージを送信してもよい。Modify Flow Requestメッセージは、フロー識別子（e.g., PDU flow ID）、並びにターゲットNR NB３のアドレス及びダウンリンク（DL）のセッション・エンドポイント識別子（SEID）を包含してもよい。セッション・エンドポイント識別子（SEID）は、例えばTunnel Endpoint Identifier (TEID)であってもよい。NG Core５内の転送ノードは、inter-RAT HOによる転送ノードの再配置（relocation）又はRAT種別の変更をEPC４内のエッジノード（i.e., (e)P-GW）に知らせるために、EPC４内のエッジノード（i.e., eP-GW）と通信してもよい。具体的には、NG Core５内の転送ノードは、セッション（i.e., PDN connection）毎のModify Bearer RequestメッセージをEPC４内のエッジノードに送信してもよい。EPC４内のエッジノードは、Modify Bearer ResponseメッセージをNG Core５内の転送ノードに送信してもよい。NG Core５内の転送ノードは、ターゲット制御ノードにModify Flow Responseメッセージを返信してもよい。

図３Ａ及び図３Ｂに示された手順に従ってハンドオーバが完了した後に、UE１のデータ転送のために以下の経路が使用されてもよい。NR NB３及びNG Core５を含むNG System がNG Core５内のベアラベースド転送をサポートし、ハンドオーバ後のUE１のためにベアラ（e.g., NG-EPS-bearer）が使用される場合、例えば、アップリンク経路及びダウンリンク経路は、（source 又はold）S/P-GWとNG Core５内の（target又はNew）User plane Function（e.g., CUNF）との間のパス（e.g., GTPトンネル又はGREトンネル）を含んでもよい。すなわち、S/P-GWはNG Core５内のUser plane Function（e.g., CUNF）にダウンリンク・データを転送し、NG Core５内のUser plane Function（e.g., CUNF）はS/P-GWにアップリンク・データを転送してもよい。

一方、ハンドオーバ後のUE１のためにベアラ（e.g., NG-EPS-bearer）が使用されない場合、例えば、（source 又はold）S/P-GWと（target又はNew）User plane Function（e.g., NW Slicingの機能を有するSUNF）との間をCUNFが仲介してもよい。すなわち、S/P-GWはNG Core５内のCUNFにダウンリンク・データを転送し、CUNFは、フロー単位制御機能を有する別のUNFにダウンリンク・データを転送してもよい。これに代えて、CUNF を介さずに、S/P-GWとSUNFとの間で直接的にデータ転送が行われてもよい。以下に述べる他のハンドオーバ手順においても、ここで説明されたハンドオーバ後のデータ転送経路が使用されてもよい。

図４Ａ及び図４Ｂは、図２に示された無線通信ネットワークの構成例におけるLTE SystemからNG SystemへのUE１のハンドオーバ手順の一例を示している。図４Ａは、ハンドオーバの準備（preparation）フェーズを示し、図４Ｂは、ハンドオーバの実施（execution）フェーズを示している。

図３Ａ及び図３Ｂに示された手順と同様に、図４Ａ及び図４Ｂに示された手順では、ソース基地局（i.e., LTE eNB２）は、ソース基地局（i.e., LTE eNB２）とコアネットワーク（i.e., NG Core５）との間のインタフェース上でHandover Requiredメッセージを送ることによって、ハンドオーバを開始する。したがって、図３Ａ及び図３Ｂに示された手順と同様に、図４Ａ及び図４Ｂに示された手順は、LTEの“E-UTRAN to UTRAN Iu mode Inter RAT handover”の改良・発展、又はMME relocationを伴う“S1-based handover”の改良・発展であってもよい。

図４Ａのステップ４０１及び４０２の処理は、図３Ａのステップ３０１及び３０２の処理と同様である。ただし、ステップ４０２では、LTE eNB２は、Handover RequiredメッセージをNG Core５に送る。なお、既に説明したとおり、図２のネットワーク構成例では、LTE eNB２を含むE-UTRAN及びNR NB３を含むNG RANは、同じネットワークスライスに接続されもよい。この実装では、LTE eNB２からNR NB３へのUE１のハンドオーバは、１つのネットワークスライス内に生成された１又は複数の論理的な制御ノード（i.e., コントロールプレーン機能）及び１又は複数の論理的な転送ノード（i.e., ユーザプレーン機能）の間のシグナリングによって実現される。この実装では、ステップ４０２のHandover Requiredメッセージは、MMEに相当する新たな又は改良された制御ノードに送られてもよい。

これに代えて、LTE eNB２を含むE-UTRAN及びNR NB３を含むNG RANは、互いに異なるネットワークスライスに接続されてもよい。この実装では、LTE eNB２からNR NB３へのUE１のハンドオーバは、LTE eNB２が接続されるEPCに相当するネットワークスライス・インスタンスとNR NB３が接続される純粋なNG Coreに相当するネットワークスライス・インスタンスとの間のスライス間通信によって実現される。この実装では、ステップ４０２のHandover Requiredメッセージは、LTE eNB２が接続されたネットワークスライス・インスタンス内のMMEに送られてもよい。

図４Ａのステップ４０３～４０５の処理は、図３Ａのステップ３０３～３０７の処理と同様である。図４Ａの手順では、図３Ａに示されたステップ３０３及び３０７の図示が省略されている。ステップ３０３及び３０７に対応する処理は、NG Core５内で行われる。

図４Ｂのステップ４０６～４１１の処理は、図３Ｂのステップ３０８～３１４の処理と同様である。図４Ｂの手順では、図３Ｂに示されたステップ３１３の図示が省略されている。ステップ３１３に対応する処理は、NG Core５内で行われる。

図５は、コアネットワークによって行われる方法の一例（処理５００）を示すフローチャートである。コアネットワークは、図１のEPC４及びNG Core５、又は図２のNG Core５である。ステップ５０１では、コアネットワークは、bearer-based network（LTE）からbearer-less network（5G）へのUE１のハンドオーバを開始するためのHandover RequiredメッセージをソースLTE eNB２から受信する。ステップ５０１は、図３Ａのステップ３０２又は図４Ａのステップ４０２に対応する。

ステップ５０２では、コアネットワークは、bearer-less network内でUE１のために確立される少なくとも１つのセッションに関するフロー情報を包含する(NR) Handover RequestメッセージをターゲットNR NB３に送る。ステップ５０２は、図３Ａのステップ３０５又は図４Ａのステップ４０４に対応する。

ステップ５０３では、コアネットワークは、Target to Source Transparent Containerを包含する(NR) Handover Request AcknowledgeメッセージをターゲットNR NB３から受信する。当該Target to Source Transparent Containerは、bearer-less networkに関連付けられた無線コネクションを確立するためにUE１にとって必要となる無線リソース設定情報を包含する。ステップ５０３は、図３Ａのステップ３０６又は図４Ａのステップ４０５に対応する。

ステップ５０４では、コアネットワークは、Target to Source Transparent Container を包含するHandover CommandメッセージをソースLTE eNB２に送る。ステップ５０４は、図３Ｂのステップ３０８又は図４Ｂのステップ４０６に対応する。

図６は、ターゲットNR NB３によって行われる方法の一例（処理６００）を示すフローチャートである。ステップ６０１では、ターゲットNR NB３は、bearer-less network内でUE１のために確立される少なくとも１つのセッションに関するフロー情報を包含する(NR) Handover Requestメッセージをコアネットワーク（i.e., NG Core５）から受信する。ステップ６０１は、図３Ａのステップ３０５又は図４Ａのステップ４０４に対応する。

ステップ６０２では、ターゲットNR NB３は、Target to Source Transparent Containerを包含する(NR) Handover Request Acknowledgeメッセージをコアネットワークに送る。当該Target to Source Transparent Containerは、bearer-less networkに関連付けられた無線コネクションを確立するためにUE１にとって必要となる無線リソース設定情報を包含する。ステップ６０２は、図３Ａのステップ３０６又は図４Ａのステップ４０５に対応する。

ステップ６０３では、ターゲットNR NB３は、当該無線リソース設定情報に基づいて、bearer-less networkに関連付けられた無線コネクションをUE１のために確立する。ステップ６０３は、図３Ｂのステップ３１０又は図４Ｂのステップ４０８に対応する。

図７は、ソースLTE eNB２によって行われる方法の一例（処理７００）を示すフローチャートである。ステップ７０１では、ソースLTE eNB２は、bearer-based network（LTE）からbearer-less network（5G）へのUE１のハンドオーバを開始するためのHandover Requiredメッセージをコアネットワーク（i.e., EPC４又はNG Core５）に送る。ステップ７０１は、図３Ａのステップ３０２又は図４Ａのステップ４０２に対応する。

ステップ７０２では、ソースLTE eNB２は、Target to Source Transparent Container を包含するHandover Commandメッセージをコアネットワークから受信する。当該Target to Source Transparent Containerは、bearer-less networkに関連付けられた無線コネクションを確立するためにUE１にとって必要となる無線リソース設定情報を包含する。ステップ７０２は、図３Ｂのステップ３０８又は図４Ｂのステップ４０６に対応する。

ステップ７０３では、ソースLTE eNB２は、無線リソース設定情報を包含し且つベアラレス・ネットワークへのハンドオーバを示すmobility commandメッセージ（e.g., Handover Commandメッセージ）をUE１に送る。ステップ７０３は、図３Ｂのステップ３０９又は図４Ｂのステップ４０７に対応する。

図８は、UE１によって行われる方法の一例（処理８００）を示すフローチャートである。ステップ８０１では、UE１は、mobility commandメッセージ（e.g., Handover Commandメッセージ）をソースLTE eNB２から受信する。当該mobility commandメッセージは、bearer-less networkに関連付けられた無線コネクションを確立するためにUE１にとって必要となる無線リソース設定情報を包含する。ステップ８０１は、図３Ｂのステップ３０９又は図４Ｂのステップ４０７に対応する。

ステップ８０２では、UE１は、当該無線リソース設定情報を用いて、bearer-less networkに関連付けられたターゲットNR NB３との無線コネクションを確立する。ステップ８０２は、図３Ｂのステップ３１０又は図４Ｂのステップ４０８に対応する。

本実施形態に係るbearer-based network（LTE）からbearer-less network（5G）への詳細なハンドオーバ手順は、例えば上述された具体例であってもよいが、これらに限定されない。例えば、上述された幾つかのハンドオーバ手順例に示されたメッセージ名は、例示に過ぎない。上述された幾つかのハンドオーバ手順例は、メッセージの順序が異なってもよいし、幾つかのメッセージが省略されてもよいし、追加のメッセージを含んでもよい。

以上の説明から理解されるように、本実施形態で説明されたbearer-based network（LTE）からbearer-less network（5G）へのハンドオーバ手順は、以下を含む：
・コアネットワーク（NG Core５）によって、フロー情報を、ターゲットNR NB３に送ること；
・ターゲットNR NB３によって、bearer-less network（i.e., NG System）に関連付けられた無線コネクション（e.g., RRCコネクション、無線ベアラ）を確立するためにUE１にとって必要となる無線リソース設定情報を、フロー情報に基づいて生成すること；及び
・ターゲットNR NB３によって、ソースLTE eNB２を介してUE１に当該無線リソース設定情報を送ること。
したがって、UE１は、ターゲットNR NB３によってフロー情報に基づいて生成された無線リソース設定情報を用いることにより、bearer-less network（e.g., 5G）に関連付けられたtarget RATのAccess Stratum（AS）レイヤ設定を適切に行うことができる。

なお、既に説明したように、NR NB３及びNG Core５を含むNG Systemは、QoSクラス毎且つPDUセッション毎のベアラを用いるベアラベースド転送をサポートするよう構成されてもよく、データフロー（PDU flow）毎のQoSハンドリング(e.g., パケット破棄)のためにベアラ内のデータフロー（PDU flow）を特定するよう構成されてもよい。例えば、NR NB３は、NR NB３とNG Core５内のユーザプレーン機能の間に設定されたベアラ（e.g., NG3ベアラ）を無線ベアラに関連付け、当該ベアラ（e.g., NG3ベアラ）と当該無線ベアラの間のパケットフォワーディングを行い、さらにベアラ内のデータフロー（PDU flow）毎のQoSハンドリング(e.g., パケット破棄)を行ってもよい。

この場合、本実施形態で説明されたフロー情報は、UE１のためのベアラ（e.g., NG-RAB又はNG3ベアラ）と当該ベアラを介して転送されるUE１の１又は複数のパケットフロー（i.e., PDU flow(s)）との関連付けを示してもよい。言い換えると、NG Core５内の制御ノード（e.g., CPF）は、UE１のためのベアラ（e.g., NG-RAB又はNG3ベアラ）と当該ベアラを介して転送されるUE１の１又は複数のパケットフロー（i.e., PDU flow(s)）との関連付けをNR NB３に知らせるために、フロー情報をNR NB３に送ってもよい。NR NB３は、NG Core５内の制御ノードからフロー情報を受信し、当該フロー情報に従って、NR NB３とNG Core５内のユーザプレーン機能の間に設定されたベアラ（e.g., NG3ベアラ）内のデータフロー（PDU flow）毎のQoSハンドリング(e.g., パケット破棄)を行ってもよい。

＜第２の実施形態＞
本実施形態は、NG System（i.e., bearer-less network）からLTE System（i.e., bearer-based network）へのUE１のハンドオーバ方法を提供する。図９Ａ及び図９Ｂは、図１に示された無線通信ネットワークの構成例におけるNG SystemからLTE SystemへのUE１のハンドオーバ手順の一例を示している。図９Ａは、ハンドオーバの準備（preparation）フェーズを示し、図９Ｂは、ハンドオーバの実施（execution）フェーズを示している。

図９Ａ及び図９Ｂに示された手順では、ソース基地局（i.e., NR NB３）は、ソース基地局（i.e., NR NB３）とコアネットワーク（i.e., NG Core５）との間のインタフェース（又は参照点（reference point））上でHandover Requiredメッセージを送ることによって、ハンドオーバを開始する。したがって、図９Ａ及び図９Ｂに示された手順は、LTEの“UTRAN Iu mode to E-UTRAN Inter RAT handover”の改良・発展であってもよい。あるいは、図９Ａ及び図９Ｂに示された手順は、LTEのMME relocationを伴う“S1-based handover”の改良・発展であってもよい。

ステップ９０１では、UE１は、NR NB３に接続され、コネクテッド状態（e.g., RRC_Connected）である。UE１は、測定設定（Measurement Configuration）をNR NB３から受信し、当該測定設定に従ってNG-RAN cells及びE-UTRAN (LTE) cellsを含む隣接セル測定（neighbor cell measurements）及び異種RAT測定（inter-RAT measurements）を実行し、測定報告（measurement report）をNR NB３に送る。

ステップ９０２では、NR NB３は、LTE eNB２のセルへのinter-RATハンドオーバを決定し、Handover RequiredメッセージをNG Core５内のソース制御ノードに送る。当該Handover Requiredメッセージは、ターゲットLTE eNB２の識別子を包含する。さらに、当該Handover Requiredメッセージは、NRからLTEへのハンドオーバであることを示すハンドオーバ種別 情報要素（Handover Type Information Element (IE)）を包含してもよい。Handover Type IEは、例えば、“NRtoLTE”がセットされる。これに代えて、当該Handover Requiredメッセージは、ターゲットLTE eNB識別子 情報要素（Target LTE eNB Identifier IE）を包含してもよい。当該Handover Requiredメッセージは、Source to Target Transparent Container IEを包含してもよい。

ステップ９０３では、NG Core５内のソース制御ノードは、受信したHandover Requiredメッセージ内のHandover Type IE又はTarget LTE eNB Identifier IEから、当該ハンドオーバの種別がLTEシステムへのInter-RATハンドオーバであることを判定する。NG Core５内のソース制御ノードは、EPC４内のターゲットMMEを選択する。NG Core５内のソース制御ノードは、Forward Relocation RequestメッセージをターゲットMMEに送ることによって、ハンドオーバリソース割り当て手順（Handover resource allocation procedure）を開始する。当該Forward Relocation Requestメッセージは、Mobility Management (MM) Context、及びUE１のためにソースシステム（i.e., NG System）においてアクティブである全てのPDUセッションを包含する。各PDNセッションは、associated APN及びPDU flow Contextsのリストを含む。MM Contextは、PDU flow(s)についての情報、及びセキュリティ関連情報（security related information）を含む。さらに、当該Forward Relocation Requestメッセージは、各PDU flow contextに関連付けられた１又は複数のサービスデータフローを特定するための情報（e.g., SDF templates、又はTraffic Flow Templates（TFTs））を含む。

ステップ９０４では、EPC４内のターゲットMMEは、ベアラベースド・セッションの生成（creation）手順を行う。具体的には、ターゲットMMEは、UE１のためのパケット転送ノード（ゲートウェイ）が再配置（relocated）される必要があることを判定し、EPC４内のターゲット転送ノード（i.e., S-GW）を選択する。ターゲットMMEは、ターゲットS-GWにCreate Session Requestメッセージを送る。当該Create Session Requestメッセージは、各PDU flow contextに関連付けられた１又は複数のサービスデータフローを特定するための情報（e.g., SDF templates、又はTraffic Flow Templates（TFTs））を含む。当該１又は複数のサービスデータフローを特定するための情報は、NG Core５内のソース制御ノードからEPC４内のターゲットMMEに送られるForward Relocation Requestメッセージから導かれる。ターゲットS-GWは、そのローカルリソースを割り当て、Create Session ResponseメッセージをターゲットMMEに返信する。

ステップ９０５では、EPC４内のターゲットMMEは、ターゲットLTE eNB２にHandover Requestメッセージを送る。

ステップ９０６では、ターゲットLTE eNB２は、Handover Requestメッセージの受信に応答して、EPS bearer(s)についての情報及びセキュリティ・コンテキストを含むUEコンテキストを生成（create）し、リソースを割り当てる。そして、ターゲットLTE eNB２は、Target to Source Transparent Containerを包含するHandover Request AcknowledgeメッセージをターゲットMMEに送る。

ステップ９０７では、EPC４内のターゲットMMEは、Target to Source Transparent Container を包含するForward Relocation ResponseメッセージをNG Core５内のソース制御ノードに送る。さらに、Forward Relocation Responseメッセージは、ダウンリンク・データフォワーディングのために割り当てられたアドレス（Addresses）及びTEIDを含んでもよい。インダイレクト・ダウンリンク・フォワーディングが使用される場合、当該アドレス及びTEIDは、NG Core５内の転送ノードへのアドレス及びTEIDであってもよい。ダイレクト・ダウンリンク・フォワーディングが使用される場合、当該アドレス及びTEIDは、ターゲットLTE eNB２へのアドレス及びTEIDであってもよい。

ステップ９０８では、ソース制御ノードは、ソースNR NB３にTarget to Source Transparent Container を包含するHandover Commandメッセージを送る。さらに、Handover Commandメッセージは、ダウンリンク・データフォワーディングの対象とされるフロー（PDU flow(s)）のリスト（flows subject to data forwarding list）を包含してもよい。“Flows Subject to Data forwarding list”IEは、例えば、address(es) 及び TEID(s) for user traffic data forwarding、並びにデータフォワーディングの対象とされるフロー（PDU flow(s)）の識別子を含む。ソースNR NB３は、“flows Subject to Data forwarding list”IEにより指定されたフロー（PDU flow(s)）のためのデータフォワーディングを開始する。

ステップ９０９では、ソースNR NB３は、Handover Commandメッセージを包含するRRCメッセージをUE１に送る。当該Handover Commandメッセージは、ターゲットLTE eNB２が準備（preparation）フェーズにおいてセットアップした無線リソース設定情報を包含するtransparent containerを含む。当該RRCメッセージは、例えば、Mobility from NR commandメッセージであってもよいし、RRC Connection Reconfigurationメッセージであってもよい。

ステップ９１０では、UE１は、Handover Commandメッセージを包含するRRCメッセージの受信に応答して、UE１は、ターゲットRAN（i.e., E-UTRAN）に移動し、Handover Commandメッセージにおいて供給された無線リソース設定情報に従ってハンドオーバを実施する。すなわち、UE１は、bearer-based network（i.e., LTE System）に関連付けられたターゲットLTE eNB２との無線コネクションを確立する。ステップ９１１では、UE１は、ターゲットセルに首尾よく（successfully）同期した後に、Handover Confirm for EUTRAメッセージをターゲットLTE eNB２に送る。ステップ９１１のメッセージは、RRC Connection Reconfiguration Completeメッセージであってもよい。

ステップ９１２では、UE１がターゲットLTE eNB２に首尾よく（successfully）アクセスした場合に、ターゲットLTE eNB２は、Handover Notifyメッセージを送ることによって、EPC４内のターゲットMMEに知らせる。

ステップ９１３では、EPC４内のターゲットMMEは、UE１がターゲットサイドに到着したことを知り、Forward Relocation Complete Notification メッセージを送ることによって、NG Core５内のソース制御ノードに知らせる。ソース制御ノードは、Forward Relocation Complete Acknowledge メッセージをターゲットMMEに送る。

ステップ９１４では、EPC４内のターゲット(e)MMEは、ベアラ修正（modification）手順を実施することによって、Inter-RAT ハンドオーバ手順を完了する。例えば、ターゲットMMEは、EPC４内の(e)S-GWに、セッション（i.e., PDN connection）毎のModify Bearer Requestメッセージを送信してもよい。Modify Bearer Requestメッセージは、ベアラ識別子（e.g., EPS Bearer ID）、並びにターゲットLTE eNB２のアドレス及びダウンリンク（DL）TEIDを包含してもよい。EPC４内の(e)S-GWは、inter-RAT HOによる転送ノードの再配置（relocation）又はRAT種別の変更をNG Core５内のエッジノードに知らせるために、NG Core５内のエッジノードと通信してもよい。具体的には、EPC４内のS-GWは、ベアラレス・セッション（i.e., PDU session）毎のModify Flow RequestメッセージをNG Core５内のエッジノードに送信してもよい。NG Core５内のエッジノードは、Modify Flow ResponseメッセージをEPC４内のS-GWに送信してもよい。EPC４内のS-GWは、ターゲットMMEにModify Bearer Responseメッセージを返信してもよい。

図１０Ａ及び図１０Ｂは、図２に示された無線通信ネットワークの構成例におけるNG SystemからLTE SystemへのUE１のハンドオーバ手順の一例を示している。図１０Ａは、ハンドオーバの準備（preparation）フェーズを示し、図１０Ｂは、ハンドオーバの実施（execution）フェーズを示している。

図９Ａ及び図９Ｂに示された手順と同様に、図１０Ａ及び図１０Ｂに示された手順では、ソース基地局（i.e., NR NB３）は、ソース基地局（i.e., NR NB３）とコアネットワーク（i.e., NG Core５）との間のインタフェース上でHandover Requiredメッセージを送ることによって、ハンドオーバを開始する。したがって、図９Ａ及び図９Ｂに示された手順と同様に、図１０Ａ及び図１０Ｂに示された手順は、LTEの“UTRAN Iu mode to E-UTRAN Inter RAT handover”の改良・発展、又はMME relocationを伴う“S1-based handover”の改良・発展であってもよい。

図１０Ａのステップ１００１～１００５の処理は、図９Ａのステップ９０１～９０７の処理と同様である。図１０Ａの手順では、図９Ａに示されたステップ９０３及び９０７の図示が省略されている。ステップ９０３及び９０７に対応する処理は、NG Core５内で行われる。

図１０Ｂのステップ１００６～１０１１の処理は、図９Ｂのステップ９０８～９１４の処理と同様である。図１０Ａの手順では、図９Ｂに示されたステップ９１３の図示が省略されている。ステップ９１３に対応する処理は、NG Core５内で行われる。

本実施形態に係るbearer-less network（5G）からbearer-based network（LTE）への詳細なハンドオーバ手順は、例えば上述された具体例であってもよいが、これらに限定されない。例えば、上述された幾つかのハンドオーバ手順例に示されたメッセージ名は、例示に過ぎない。上述された幾つかのハンドオーバ手順例は、メッセージの順序が異なってもよいし、幾つかのメッセージが省略されてもよいし、追加のメッセージを含んでもよい。

続いて以下では、上述の複数の実施形態に係るUE１、LTE eNB２、NR NB３、及びコアネットワークノードの構成例について説明する。図１１は、UE１の構成例を示すブロック図である。LTEトランシーバ１１０１は、LTE eNB２と通信するために、LTE RATのPHYレイヤに関するアナログRF信号処理を行う。LTEトランシーバ１１０１により行われるアナログRF信号処理は、周波数アップコンバージョン、周波数ダウンコンバージョン、及び増幅を含む。LTEトランシーバ１１０１は、アンテナ１１０２及びベースバンドプロセッサ１１０５と結合される。すなわち、LTEトランシーバ１１０１は、変調シンボルデータ（又はOFDMシンボルデータ）をベースバンドプロセッサ１１０５から受信し、送信RF信号を生成し、送信RF信号をアンテナ１１０２に供給する。また、LTEトランシーバ１１０１は、アンテナ１１０２によって受信された受信RF信号に基づいてベースバンド受信信号を生成し、これをベースバンドプロセッサ１１０５に供給する。

New Radio（NR）トランシーバ１１０３は、NR NB３と通信するために、NG RATのPHYレイヤに関するアナログRF信号処理を行う。New 5Gトランシーバ１１０３は、アンテナ１１０４及びベースバンドプロセッサ１１０５と結合される。

ベースバンドプロセッサ１１０５は、無線通信のためのデジタルベースバンド信号処理（データプレーン処理）とコントロールプレーン処理を行う。デジタルベースバンド信号処理は、(a) データ圧縮／復元、(b) データのセグメンテーション／コンカテネーション、(c) 伝送フォーマット（伝送フレーム）の生成／分解、(d) 伝送路符号化／復号化、(e) 変調（シンボルマッピング）／復調、及び(f) Inverse Fast Fourier Transform（IFFT）によるOFDMシンボルデータ（ベースバンドOFDM信号）の生成などを含む。一方、コントロールプレーン処理は、レイヤ１（e.g., 送信電力制御）、レイヤ２（e.g., 無線リンク制御、及びhybrid automatic repeat request（HARQ）処理）、及びレイヤ３（e.g., アタッチ、モビリティ、及びパケット通信に関するシグナリング）の通信管理を含む。

例えば、LTEおよびLTE-Advancedの場合、ベースバンドプロセッサ１１０５によるデジタルベースバンド信号処理は、Packet Data Convergence Protocol（PDCP）レイヤ、Radio Link Control（RLC）レイヤ、MACレイヤ、およびPHYレイヤの信号処理を含んでもよい。また、ベースバンドプロセッサ１１０５によるコントロールプレーン処理は、Non-Access Stratum（NAS）プロトコル、RRCプロトコル、及びMAC CEの処理を含んでもよい。

ベースバンドプロセッサ１１０５は、デジタルベースバンド信号処理を行うモデム・プロセッサ（e.g., Digital Signal Processor（DSP））とコントロールプレーン処理を行うプロトコルスタック・プロセッサ（e.g., Central Processing Unit（CPU）、又はMicro Processing Unit（MPU））を含んでもよい。この場合、コントロールプレーン処理を行うプロトコルスタック・プロセッサは、後述するアプリケーションプロセッサ１１０６と共通化されてもよい。

アプリケーションプロセッサ１１０６は、CPU、MPU、マイクロプロセッサ、又はプロセッサコアとも呼ばれる。アプリケーションプロセッサ１１０６は、複数のプロセッサ（複数のプロセッサコア）を含んでもよい。アプリケーションプロセッサ１１０６は、メモリ１１０８又は図示されていないメモリから読み出されたシステムソフトウェアプログラム（Operating System（OS））及び様々なアプリケーションプログラム（例えば、メータリングデータ又はセンシングデータを取得する通信アプリケーション）を実行することによって、UE１の各種機能を実現する。

いくつかの実装において、図１１に破線（１１０７）で示されているように、ベースバンドプロセッサ１１０５及びアプリケーションプロセッサ１１０６は、１つのチップ上に集積されてもよい。言い換えると、ベースバンドプロセッサ１１０５及びアプリケーションプロセッサ１１０６は、１つのSystem on Chip（SoC）デバイス１１０７として実装されてもよい。SoCデバイスは、システムLarge Scale Integration（LSI）またはチップセットと呼ばれることもある。

メモリ１１０８は、揮発性メモリ若しくは不揮発性メモリ又はこれらの組合せである。メモリ１１０８は、物理的に独立した複数のメモリデバイスを含んでもよい。揮発性メモリは、例えば、Static Random Access Memory（SRAM）若しくはDynamic RAM（DRAM）又はこれらの組み合わせである。不揮発性メモリは、マスクRead Only Memory（MROM）、Electrically Erasable Programmable ROM（EEPROM）、フラッシュメモリ、若しくはハードディスクドライブ、又はこれらの任意の組合せである。例えば、メモリ１１０８は、ベースバンドプロセッサ１１０５、アプリケーションプロセッサ１１０６、及びSoC１１０７からアクセス可能な外部メモリデバイスを含んでもよい。メモリ１１０８は、ベースバンドプロセッサ１１０５内、アプリケーションプロセッサ１１０６内、又はSoC１１０７内に集積された内蔵メモリデバイスを含んでもよい。さらに、メモリ１１０８は、Universal Integrated Circuit Card（UICC）内のメモリを含んでもよい。

メモリ１１０８は、上述の複数の実施形態で説明されたUE１による処理を行うための命令群およびデータを含む１又は複数のソフトウェアモジュール（コンピュータプログラム）１１０９を格納してもよい。いくつかの実装において、ベースバンドプロセッサ１１０５又はアプリケーションプロセッサ１１０６は、当該ソフトウェアモジュール１１０９をメモリ１１０８から読み出して実行することで、上述の実施形態で説明されたUE１の処理を行うよう構成されてもよい。

図１２は、上述の実施形態に係るLTE eNB２の構成例を示すブロック図である。図１２を参照すると、LTE eNB２は、LTEトランシーバ１２０１、ネットワークインターフェース１２０３、プロセッサ１２０４、及びメモリ１２０５を含む。LTEトランシーバ１２０１は、UE１を含むLTE RATをサポートするUEsと通信するためにアナログRF信号処理を行う。LTEトランシーバ１２０１は、複数のトランシーバを含んでもよい。LTEトランシーバ１２０１は、アンテナ１２０２及びプロセッサ１２０４と結合される。LTEトランシーバ１２０１は、変調シンボルデータ（又はOFDMシンボルデータ）をプロセッサ１２０４から受信し、送信RF信号を生成し、送信RF信号をアンテナ１２０２に供給する。また、LTEトランシーバ１２０１は、アンテナ１２０２によって受信された受信RF信号に基づいてベースバンド受信信号を生成し、これをプロセッサ１２０４に供給する。

ネットワークインターフェース１２０３は、ネットワークノード（e.g., EPC４内のMME及びS-GW）と通信するために使用される。ネットワークインターフェース１２０３は、例えば、IEEE 802.3 seriesに準拠したネットワークインターフェースカード（NIC）を含んでもよい。

プロセッサ１２０４は、無線通信のためのデジタルベースバンド信号処理（データプレーン処理）とコントロールプレーン処理を行う。例えば、LTEおよびLTE-Advancedの場合、プロセッサ１２０４によるデジタルベースバンド信号処理は、PDCPレイヤ、RLCレイヤ、MACレイヤ、およびPHYレイヤの信号処理を含んでもよい。また、プロセッサ１２０４によるコントロールプレーン処理は、S1プロトコル、RRCプロトコル、及びMAC CEの処理を含んでもよい。

プロセッサ１２０４は、複数のプロセッサを含んでもよい。例えば、プロセッサ１２０４は、デジタルベースバンド信号処理を行うモデム・プロセッサ（e.g., DSP）とコントロールプレーン処理を行うプロトコルスタック・プロセッサ（e.g., CPU又はMPU）を含んでもよい。

メモリ１２０５は、揮発性メモリ及び不揮発性メモリの組み合わせによって構成される。揮発性メモリは、例えば、SRAM若しくはDRAM又はこれらの組み合わせである。不揮発性メモリは、例えば、MROM、PROM、フラッシュメモリ、若しくはハードディスクドライブ、又はこれらの組合せである。メモリ１２０５は、プロセッサ１２０４から離れて配置されたストレージを含んでもよい。この場合、プロセッサ１２０４は、ネットワークインターフェース１２０３又は図示されていないI/Oインタフェースを介してメモリ１２０５にアクセスしてもよい。

メモリ１２０５は、上述の複数の実施形態で説明されたLTE eNB２による処理を行うための命令群およびデータを含む１又は複数のソフトウェアモジュール（コンピュータプログラム）１２０６を格納してもよい。いくつかの実装において、プロセッサ１２０４は、当該１又は複数のソフトウェアモジュール１２０６をメモリ１２０５から読み出して実行することで、上述の実施形態で説明されたLTE eNB２の処理を行うよう構成されてもよい。

図１３は、上述の実施形態に係るNR NB３の構成例を示すブロック図である。図１３を参照すると、NR NB３は、New Radio（NR）トランシーバ１３０１、ネットワークインターフェース１３０３、プロセッサ１３０４、及びメモリ１３０５を含む。NRトランシーバ１３０１は、UE１を含むNG RATをサポートするUEsと通信するためにアナログRF信号処理を行う。NRトランシーバ１３０１は、複数のトランシーバを含んでもよい。NRトランシーバ１３０１は、アンテナ１３０２及びプロセッサ１３０４と結合される。NRトランシーバ１３０１は、変調シンボルデータをプロセッサ１３０４から受信し、送信RF信号を生成し、送信RF信号をアンテナ１３０２に供給する。また、NRトランシーバ１３０１は、アンテナ１３０２によって受信された受信RF信号に基づいてベースバンド受信信号を生成し、これをプロセッサ１３０４に供給する。

ネットワークインターフェース１３０３は、ネットワークノード（e.g., NG Core５内の制御ノード及び転送ノード）と通信するために使用される。ネットワークインターフェース１３０３は、例えば、IEEE 802.3 seriesに準拠したネットワークインターフェースカード（NIC）を含んでもよい。

プロセッサ１３０４は、無線通信のためのデジタルベースバンド信号処理（データプレーン処理）とコントロールプレーン処理を行う。プロセッサ１３０４は、複数のプロセッサを含んでもよい。例えば、プロセッサ１３０４は、デジタルベースバンド信号処理を行うモデム・プロセッサ（e.g., DSP）とコントロールプレーン処理を行うプロトコルスタック・プロセッサ（e.g., CPU又はMPU）を含んでもよい。

メモリ１３０５は、揮発性メモリ及び不揮発性メモリの組み合わせによって構成される。揮発性メモリは、例えば、SRAM若しくはDRAM又はこれらの組み合わせである。不揮発性メモリは、例えば、MROM、PROM、フラッシュメモリ、若しくはハードディスクドライブ、又はこれらの組合せである。メモリ１３０５は、プロセッサ１３０４から離れて配置されたストレージを含んでもよい。この場合、プロセッサ１３０４は、ネットワークインターフェース１３０３又は図示されていないI/Oインタフェースを介してメモリ１３０５にアクセスしてもよい。

メモリ１３０５は、上述の複数の実施形態で説明されたNR NB３による処理を行うための命令群およびデータを含む１又は複数のソフトウェアモジュール（コンピュータプログラム）１３０６を格納してもよい。いくつかの実装において、プロセッサ１３０４は、当該１又は複数のソフトウェアモジュール１３０６をメモリ１３０５から読み出して実行することで、上述の実施形態で説明されたNR NB３の処理を行うよう構成されてもよい。

図１４は、上述の実施形態に係るコアネットワークノード１４００の構成例を示すブロック図である。コアネットワークノード１４００は、例えば、EPC４内のMME、又はNG Core５内の制御ノードである。図１４を参照すると、コアネットワークノード１４００は、ネットワークインターフェース１４０１、プロセッサ１４０２、及びメモリ１４０３を含む。ネットワークインターフェース１４０１は、ネットワークノード（e.g., RANノード、他のコアネットワークノード）と通信するために使用される。ネットワークインターフェース１４０１は、例えば、IEEE 802.3 seriesに準拠したネットワークインタフェースカード（NIC）を含んでもよい。

プロセッサ１４０２は、例えば、マイクロプロセッサ、MPU、又はCPUであってもよい。プロセッサ１４０２は、複数のプロセッサを含んでもよい。

メモリ１４０３は、揮発性メモリ及び不揮発性メモリの組み合わせによって構成される。揮発性メモリは、例えば、SRAM若しくはDRAM又はこれらの組み合わせである。不揮発性メモリは、例えば、MROM、PROM、フラッシュメモリ、若しくはハードディスクドライブ、又はこれらの組合せである。メモリ１４０３は、プロセッサ１４０２から離れて配置されたストレージを含んでもよい。この場合、プロセッサ１４０２は、ネットワークインターフェース１４０１又は図示されていないI/Oインタフェースを介してメモリ１４０３にアクセスしてもよい。

メモリ１４０３は、上述の複数の実施形態で説明されたコアネットワークノード（e.g., EPC４内のMME、又はNG Core５内の制御ノード）による処理を行うための命令群およびデータを含む１又は複数のソフトウェアモジュール（コンピュータプログラム）１４０４を格納してもよい。いくつかの実装において、プロセッサ１４０２は、当該１又は複数のソフトウェアモジュール１４０４をメモリ１４０３から読み出して実行することで、上述の実施形態で説明されたコアネットワークノードの処理を行うよう構成されてもよい。

図１１～図１４を用いて説明したように、上述の実施形態に係るUE１、LTE eNB２、NR NB３、及びコアネットワークノードが有するプロセッサの各々は、図面を用いて説明されたアルゴリズムをコンピュータに行わせるための命令群を含む１又は複数のプログラムを実行する。このプログラムは、様々なタイプの非一時的なコンピュータ可読媒体（non-transitory computer readable medium）を用いて格納され、コンピュータに供給することができる。非一時的なコンピュータ可読媒体は、様々なタイプの実体のある記録媒体（tangible storage medium）を含む。非一時的なコンピュータ可読媒体の例は、磁気記録媒体（例えばフレキシブルディスク、磁気テープ、ハードディスクドライブ）、光磁気記録媒体（例えば光磁気ディスク）、Compact Disc Read Only Memory（CD-ROM）、CD-R、CD-R/W、半導体メモリ（例えば、マスクROM、Programmable ROM（PROM）、Erasable PROM（EPROM）、フラッシュROM、Random Access Memory（RAM））を含む。また、プログラムは、様々なタイプの一時的なコンピュータ可読媒体（transitory computer readable medium）によってコンピュータに供給されてもよい。一時的なコンピュータ可読媒体の例は、電気信号、光信号、及び電磁波を含む。一時的なコンピュータ可読媒体は、電線及び光ファイバ等の有線通信路、又は無線通信路を介して、プログラムをコンピュータに供給できる。

＜第３の実施形態＞
本実施形態では、上述の実施形態で説明されたRRCメッセージ及びRANとコアネットワークとの間の制御メッセージ（i.e., S1及びNG2メッセージ）の具体例が説明される。

図１５Ａ及び図１５Ｂは、Mobility from EUTRA commandメッセージのフォーマットの一例を示している。LTE SystemからNG Systemへのハンドオーバの場合、MobilityFromEUTRACommandメッセージは、“handover”とセットされたpurposeと、NG RANに対応する“ngutra”とセットされたtargetRAT-Typeとを含む。さらに、MobilityFromEUTRACommandメッセージは、targetRAT-MessageContainerを含む。targetRAT-MessageContainerは、ターゲットNR NB３によって生成されたRRCConnectionReconfigurationNRメッセージを含む。さらにまた、targetRAT-Type が“OTHERRAN”、つまり“utra”、“geran”、又は“ngutra”であるとき、MobilityFromEUTRACommandメッセージは、nas-SecurityParamFromEUTRAを含む。

図１６は、LTE eNB２からEPC４内のMMEにS1インタフェース上で送られるHandover Requiredメッセージ（e.g., 図３Ａのステップ３０２）のフォーマットの一例を示している。このHandover Requiredメッセージは、“LTEtoNR”とセットされたHandover Typeと、Source to Target Transparent Containerとを含む。

図１７は、LTE eNB２からNG Core５内の制御ノード（e.g., Common Control plane NF（CCNF））にNG2インタフェース上で送られるHandover Requiredメッセージ（e.g., 図４Ａのステップ４０２）のフォーマットの一例を示している。このHandover Requiredメッセージは、“LTEtoNR”とセットされたHandover Typeと、Source to Target Transparent Containerとを含む。さらに、Handover Requiredメッセージは、CCNF UE NG2AP ID及びeNB UE NG2AP IDを含む。CCNF UE NG2AP IDは、NG2インタフェース上でUE１を識別するために、NG Core５内の制御ノード（CCNF）によって割り当てられた識別子である。eNB UE NG2AP IDは、NG2インタフェース上でUE１を識別するために、LTE eNB２によって割り当てられた識別子である。

図１８～図２０は、Handover Requiredメッセージ内のSource NR NB to Target NR NB Transparent Containerのフォーマットのいくつかの例を示している。図１８に示された例では、Source NR NB to Target NR NB Transparent Containerは、RRC container及びNextGen (NG)-RABs Information Listを含む。RRC containerは、RRC Handover Preparation Informationメッセージを含む。NG-RABs Information Listは、LTE eNB２からNR NB３へハンドオーバされる無線アクセスベアラ（NG-RABs）のリストを示す。図１８に示されたフォーマットは、NR NB３及びNG Core５を含むNG SystemがQoSクラス毎且つPDUセッション毎のベアラを用いるベアラベースド転送をサポートするよう構成される場合に使用されてもよい。ベアラは、ネットワーク機能（Network Functions（NFs））のペアの間、例えば、NR NB３とNG Core５内のユーザプレーン機能の間、又はNG Core５内の２つのユーザプレーン機能の間に設定される。NG SystemのベアラはNG-EPS-bearerと呼ばれてもよく、NG Systemの無線アクセスベアラはNG-RABと呼ばれてもよい。

図１９に示されたSource NR NB to Target NR NB Transparent Containerは、図１８のそれと同様に、RRC container及びNG-RABs Information Listを含む。ただし、図１９に示されたNG-RABs Information Listは、各NG-RABにマッピングされるパケットフロー（PDU flows）のリストを示すFlows Information Listを含む。図１９に示されたフォーマットは、NR NB３及びNG Core５を含むNG Systemが、QoSクラス毎且つPDUセッション毎のベアラを用いるベアラベースド転送をサポートし、且つパケットフロー（PDU flow）毎のQoSハンドリング(e.g., パケット破棄)のためにベアラ内のパケットフロー（PDU flow）を特定するよう構成される場合に使用されてもよい。

図２０に示されたSource NR NB to Target NR NB Transparent Containerは、Sessions Information List及びNG-RABs Information Listのいずれか又は両方を含むことができる。図２０に示されたフォーマットは、NR NB３及びNG Core５を含むNG Systemが、ベアラベースド転送及びフローベースド転送の両方をサポートする場合に使用されてもよい。さらに、図２０に示されたフォーマットは、NR NB３及びNG Core５を含むNG Systemが、フローベースド転送のみをサポートする場合に使用されてもよい。

図２１は、NG Core５からNR NB３にNG2インタフェース上で送られる(NR) Handover Requestメッセージ（e.g., 図３Ａのステップ３０５、及び図４Ａのステップ４０４）のフォーマットの一例を示している。この(NR) Handover Requestメッセージは、CCNF UE NG2AP IDを含む。CCNF UE NG2AP IDは、NG2インタフェース上でUE１を識別するために、NG Core５内の制御ノード（CCNF）によって割り当てられた識別子である。なお、CCNFは一例であり、他のコントロールプレーン・ネットワーク機能又はノードの名称（e.g., CNF、CPF、SMF、MMF）が、CCNFの代わりに使用されてもよい。さらに、この(NR) Handover Requestメッセージは、Security Context及びNAS Security Parameters to NG-UTRANを含む。Security Contextは、例えば、Next Hop parameter（NH）及びNext Hop Chaining Counter parameter（NCC）を示す。NAS Security Parameters to NG-UTRANは、E-UTRANからNG RAN（NG-UTRAN）へのハンドオーバの場合に(NR) Handover Requestメッセージに含まれる。Security Context及びNAS Security Parameters to NG-UTRANは、ネットワークスライス毎にセットされてもよい。

さらに、図２１の例では、(NR) Handover Requestメッセージは、NG-RABs To Be Setup Listを含む。NG-RABs To Be Setup Listは、ターゲットNR NB３においてセットアップされるべき無線アクセスベアラ（NG-RABs）のリストを示す。図２１に示されたフォーマットは、NR NB３及びNG Core５を含むNG SystemがQoSクラス毎且つPDUセッション毎のベアラを用いるベアラベースド転送をサポートするよう構成される場合に使用されてもよい。

図２２は、(NR) Handover Requestメッセージの変形例を示している。図２２の例では、(NR) Handover Requestメッセージは、図２１のそれと同様に、NG-RABs To Be Setup Listを含む。ただし、図２２に示されたNG-RABs To Be Setup Listは、各NG-RABにマッピングされるパケットフロー（PDU flows）のリストを示すFlows Information Listを含む。図２２に示されたフォーマットは、NR NB３及びNG Core５を含むNG Systemが、QoSクラス毎且つPDUセッション毎のベアラを用いるベアラベースド転送をサポートし、且つパケットフロー（PDU flow）毎のQoSハンドリング(e.g., パケット破棄)のためにベアラ内のパケットフロー（PDU flow）を特定するよう構成される場合に使用されてもよい。

図２３は、(NR) Handover Requestメッセージの更なる変形例を示している。図２３に示された(NR) Handover Requestメッセージは、Session To Be Setup List及びNG-RABs To Be Setup Listのいずれか又は両方を含むことができる。Session To Be Setup Listは、ハンドオーバされるUE１の１又は複数のセッションに関する情報を含む。例えば、Session To Be Setup Listは、セッション毎のスライス情報（Slice Information）を含む。図２３に示されたSlice Informationは、上述の実施形態で説明されたスライス情報に対応する。さらに、Session To Be Setup Listは、セッション毎のセッション・エンドポイント識別子（Session Endpoint Identifier（SEID））を含む。図２３に示されたフォーマットは、NR NB３及びNG Core５を含むNG Systemが、ベアラベースド転送及びフローベースド転送の両方をサポートする場合に使用されてもよい。さらに、図２３に示されたフォーマットは、NR NB３及びNG Core５を含むNG Systemが、フローベースド転送のみをサポートする場合に使用されてもよい。

図２４は、Slice Informationのフォーマットの一例を示している。第１の実施形態において詳細に説明したように、Slice Informationは、UE１のために決定（選択）されたネットワークスライスの識別子（i.e., Network Slice Instance ID）、及び当該ネットワークスライスに関連付けられたネットワーク機能又はノードの識別子（i.e., Network Function ID）を含む。Slice Informationは、当該ネットワークスライスの種別情報（i.e., Multi-Dimensional Descriptor）を含んでもよい。さらに、Slice Informationは、モビリティ・クラス（Mobility Class）若しくはセッション・クラス（Session Class）又は両方を含んでもよい。

図２５は、Session Endpoint IDのフォーマットの一例を示している。第１の実施形態において詳細に説明したように、Session Endpoint IDは、GTP-TEID、GRE-TEID、又はネットワーク機能若しくはノードの識別子（NF ID）であってもよい。

図２６は、NR NB３からNG Core５にNG2インタフェース上で送られる(NR) Handover Request Acknowledgeメッセージ（e.g., 図３Ａのステップ３０６、及び図４Ａのステップ４０５）のフォーマットの一例を示している。この(NR) Handover Request Acknowledgeメッセージは、Target to Source Transparent Containerを含む。Target to Source Transparent Containerは、ターゲットNR NB３によって生成された無線リソース設定情報（e.g., 無線パラメータ）を包含する。図２７に示されるように、Target to Source Transparent Containerは、RRC NG-UTRA Handover Command メッセージを包含するRRC Containerを含んでもよい。

さらに、図２６の例では、(NR) Handover Request Acknowledgeメッセージは、NG-RABs Admitted Listを含む。NG-RABs Admitted Listは、リソースがターゲットセルにおいて準備された無線アクセスベアラ（NG-RABs）のリストを示す。図２６に示されたフォーマットは、NR NB３及びNG Core５を含むNG SystemがQoSクラス毎且つPDUセッション毎のベアラを用いるベアラベースド転送をサポートするよう構成される場合に使用されてもよい。

図２８は、(NR) Handover Request Acknowledgeメッセージの変形例を示している。図２８の例では、(NR) Handover Request Acknowledgeメッセージは、図２６のそれと同様に、NG-RABs Admitted Listを含む。ただし、図２８に示されたNG-RABs Admitted Listは、各NG-RABにマッピングされるパケットフロー（PDU flows）のリストを示すFlows Information Listを含む。図２８に示されたフォーマットは、NR NB３及びNG Core５を含むNG Systemが、QoSクラス毎且つPDUセッション毎のベアラを用いるベアラベースド転送をサポートし、且つパケットフロー（PDU flow）毎のQoSハンドリング(e.g., パケット破棄)のためにベアラ内のパケットフロー（PDU flow）を特定するよう構成される場合に使用されてもよい。

図２９は、(NR) Handover Request Acknowledgeメッセージの更なる変形例を示している。図２９に示された(NR) Handover Request Acknowledgeメッセージは、Session Admitted List及びNG-RABs Admitted Listのいずれか又は両方を含むことができる。Session Admitted Listは、リソースがターゲットセルにおいて準備されたUE１の１又は複数のセッションに関する情報を含む。図２９に示されたフォーマットは、NR NB３及びNG Core５を含むNG Systemが、ベアラベースド転送及びフローベースド転送の両方をサポートする場合に使用されてもよい。さらに、図２９に示されたフォーマットは、NR NB３及びNG Core５を含むNG Systemが、フローベースド転送のみをサポートする場合に使用されてもよい。

図３０は、図２９に示されたForwarding Addressのフォーマットの一例を示している。Forwarding Addressは、ダウンリンク・データフォワーディングのための情報（i.e., DL Transport Layer Address及びDL Session Endpoint ID）及びアップリンク・データフォワーディングのための情報（i.e., UL Transport Layer Address及びUL Session Endpoint ID）のいずれか又は両方を含む。

図３１は、EPC４内のMMEからLTE eNB２にS1インタフェース上で送られるS1AP Handover Commandメッセージ（e.g., 図３Ｂのステップ３０８）のフォーマットの一例を示している。このHandover Commandメッセージは、E-RABs Subject to Forwarding Listを含む。E-RABs Subject to Forwarding Listは、データフォワーディングの対象とされるE-RABsを示す。

さらに、E-UTRANから“OTHER RAN”へのハンドオーバであるとき、言い換えるとHandover Type IEが“LTEtoNR（若しくはLTEtoNGUTRAN）”、“LTEtoUTRAN”、又は“LTEtoGERAN”であるとき、S1AP Handover Commandメッセージは、NAS Security Parameters from E-UTRANを含む。NAS Security Parameters from E-UTRANは、E-UTRANからのInter-RATハンドオーバのためのセキュリティ関連情報（security related information）を含む。

図３２は、NG Core５内の制御ノード（e.g., CCNF）からLTE eNB２にNG2インタフェース上で送られるNG2AP Handover Commandメッセージ（e.g., 図４Ｂのステップ４０６）のフォーマットの一例を示している。このHandover Commandメッセージは、NE-RABs Subject to Forwarding Listを含む。NE-RABs Subject to Forwarding Listは、データフォワーディングの対象とされるNextGen E-RABsを示す。ここで、NextGen E-RAB（NE-RAB）は、NG Coreとのインタフェースをサポートするよう拡張されたeLTE eNBを介してUEとNG Core５内のUser plane Function（e.g., CUNF）との間にセットアップされるE-RABである。

＜その他の実施形態＞
上述の実施形態は、各々独立に実施されてもよいし、実施形態全体又はその一部が適宜組み合わせて実施されてもよい。

上述の実施形態で説明されたE-URAN及びNG RANは、Cloud Radio Access Network（C-RAN）コンセプトに基づいて実装されてもよい。C-RANは、Centralized RANと呼ばれることもある。したがって、上述の実施形態で説明されたLTE eNB２及びNR NB３の各々により行われる処理及び動作は、C-RANアーキテクチャに含まれるDigital Unit（DU）又はDU及びRadio Unit（RU）の組み合せによって提供されてもよい。DUは、Baseband Unit（BBU）又はCentral Unit（CU）と呼ばれる。RUは、Remote Radio Head（RRH）、Remote Radio Equipment（RRE）、又はDistributed Unit（DU）とも呼ばれる。DUとRUは、RAN全体で提供されるASレイヤの機能をDUとRUとで分離して提供してもよい。例えば、ASレイヤの一部（レイヤ２／レイヤ３若しくはそれらのサブレイヤ、又はレイヤの一部機能）をDUに配置し、残りのレイヤ（又はレイヤの一部機能）をRUに配置する構成で、DUとRUとが提供されてもよい。すなわち、上述の実施形態で説明されたLTE eNB２及びNR NB３の各々によって行われる処理及び動作は、任意の１又は複数の無線局（又はRANノード）によって提供されてもよい。

NR NB ３は、ASレイヤ（layers）又は機能のDUとRUへの振り分け（allocation）を動的に変更できるように構成されてもよい。言い換えると、NR NB ３は、DUとRUとの間でのASレイヤ（layers）又は機能の分離ポイントを動的に変更できるように構成されてもよい。例えば、NR NB ３は、複数の異なる機能分離オプション（different functional split options）から１つを動的に選択できるように構成されてもよい。この場合、上述したいくつかの実施形態のLTE to NRのHO手順内で、NG Core５は、Forward Relocation Requestメッセージ又はHandover Requiredメッセージの受信に応答して、ASレイヤ又は機能のNR NB３のDUとRUへの振り分けを決定してもよい。これに代えて、NR NB３が、ASサブレイヤ又は機能のNR NB３のDUとRUへの振り分けを決定してもよい。NG Core５又はNR NB ３は、NR NB ３に適用される１つの機能分離オプションを予め定められた複数の機能分離オプションから選択してもよい。

一例において、NR NB ３に適用される機能分離オプションは、Forward Relocation Requestメッセージ又はHandover Requiredメッセージに含まれるE-RAB QoS information IE, e.g. QCI, ARP又はフロー情報などに基づいて決定（選択）されてもよい。さらに又はこれに代えて、NR NB ３に適用される機能分離オプションは、NG Core５若しくはNR NB３により生成されるスライス若しくはスライスに関する情報（スライス情報）に基づいて決定されてもよい。さらに又はこれに代えて、NR NB ３に適用される機能分離オプションは、UE１から送信されたNAS情報に含まれるネットワークスライス支援情報に基づいて決定されてもよい。

また、上述したいくつかの実施形態において、各ノード間で送受信されるメッセージにUE識別子が含まれてもよい。当該UE識別子は、ハンドオーバされるUE１をハンドオーバ手順内で識別するために使用される。

より具体的には、当該UE識別子は、NR NB３とNG Core５のMMEに相当する制御ノードとの間のインタフェース（e.g., Sn インタフェース又はNG2 インタフェース、nは整数）上で使用されるUE識別子であってもよい。このUE識別子は、NR NB UE SnAP ID（NR NB UE Sn Application Protocol Identifier）又はNR NB UE NG2AP IDと表現されてもよい。

これに代えて、当該UE識別子は、NR NB３とLTE eNB２との間のインタフェース（e.g., Xnインタフェース、nは整数）上で使用されるUE識別子であってもよい。このUE識別子は、NR NB UE XnAP IDと表現されてもよい。

これに代えて、当該UE識別子は、NG Core５のMMEに相当する制御ノードとEPC４内のMMEとの間のインタフェース（e.g., Sm インタフェース、mは整数）上で使用されるUE識別子であってもよい。このUE識別子は、例えばeMME UE SmAP IDと表現されてもよい。

これに代えて、当該UE識別子は、NG Core５のMMEに相当する制御ノードとLTE eNB２との間のインタフェース（e.g., Sl インタフェース、lは整数）上で使用され、且つ当該制御ノードによって割り当てられるUE識別子であってもよい。このUEの識別子は、例えばeMME UE SlAP IDと表現されてもよい。

さらに、これらのUE識別子がハンドオーバ手順内において各ノード間で転送されてもよい。なお、上述した各インタフェースを識別するためのSn、NG2、Sm、Sl、及びXnは例示であり、他の表記であってもよい。

さらに、上述した実施形態は本件発明者により得られた技術思想の適用に関する例に過ぎない。すなわち、当該技術思想は、上述した実施形態のみに限定されるものではなく、種々の変更が可能であることは勿論である。

例えば、上記の実施形態の一部又は全部は、以下の付記のようにも記載され得るが、以下には限られない。

（付記１）
ベアラレス・ネットワークに関連付けられたターゲット無線アクセスネットワーク（RAN）ノードであって、
少なくとも１つのメモリと、
前記少なくとも１つのメモリに結合された少なくとも１つのプロセッサと、
を備え、
前記少なくとも１つのプロセッサは、
ベアラベースド・ネットワークから前記ベアラレス・ネットワークへの無線端末のハンドオーバを要求するhandover requestメッセージをコアネットワークから受信するよう構成され、前記handover requestメッセージは、前記無線端末の少なくとも１つのパケットフローを転送するために前記ベアラレス・ネットワーク内で確立される少なくとも１つのセッションに関するフロー情報を含み；
前記handover requestメッセージに応答して、Target to Source Transparent Containerを包含するhandover request acknowledgeメッセージを前記コアネットワークに送信するよう構成され、前記Target to Source Transparent Containerは、前記フロー情報から導かれる無線リソース設定情報を包含し、且つ前記コアネットワークを介して前記ベアラベースド・ネットワークに関連付けられたソースRANノードにフォワードされる；
ターゲットRANノード。

（付記２）
前記無線リソース設定情報は、前記ベアラベースド・ネットワークで使用される前記無線端末のためのベアラと前記ベアラレス・ネットワークで使用される前記無線端末のための少なくとも１つのパケットフローとのマッピングを示す情報を含む、付記１に記載のターゲットRANノード。

（付記３）
前記フロー情報は、前記無線端末の各パケットフローに関して、フロー識別子及びフローQoSパラメータを含む、
付記１又は２のいずれか１項に記載のターゲットRANノード。

（付記４）
ベアラベースド・ネットワークに関連付けられたソース無線アクセスネットワーク（RAN）ノードであって、
少なくとも１つのメモリと、
前記少なくとも１つのメモリに結合された少なくとも１つのプロセッサと、
を備え、
前記少なくとも１つのプロセッサは、
前記ベアラベースド・ネットワークからベアラレス・ネットワークへの無線端末のハンドオーバを開始するためのhandover requiredメッセージをコアネットワークに送信するよう構成され；
Target to Source Transparent Containerを包含するhandover commandメッセージを前記コアネットワークから受信するよう構成され、前記Target to Source Transparent Containerは、前記ベアラレス・ネットワークに関連付けられたターゲットRANノードによって生成され、前記無線端末の少なくとも１つのパケットフローを転送するために前記ベアラレス・ネットワーク内で確立される少なくとも１つのセッションに関連付けられた無線コネクションを確立するために前記無線端末にとって必要となる無線リソース設定情報を包含し；
前記無線リソース設定情報を包含し且つ前記ベアラレス・ネットワークへのハンドオーバを示すmobility commandメッセージを前記無線端末に送信するよう構成されている；
ソースRANノード。

（付記５）
前記無線リソース設定情報は、前記ベアラベースド・ネットワークで使用される前記無線端末のためのベアラと前記ベアラレス・ネットワークで使用される前記無線端末のための少なくとも１つのパケットフローとのマッピングを示す情報を含む、
付記４に記載のソースRANノード。

（付記６）
前記handover commandメッセージは、前記ベアラベースド・ネットワーク内の前記無線端末のためのベアラで転送される少なくとも１つのパケットフローの各々の識別子と、各パケットフローのデータフォワーディングのために割り当てられたアドレス若しくはエンドポイント識別子又はこれら両方とを包含する、
付記４又は５に記載のソースRANノード。

（付記７）
前記少なくとも１つのプロセッサは、前記少なくとも１つのパケットフローの各々の前記識別子と前記アドレス若しくは前記エンドポイント識別子又はこれら両方とを用いて、前記少なくとも１つのパケットフローのデータフォワーディングを行うよう構成されている、
付記６に記載のソースRANノード。

（付記８）
無線端末であって、
少なくとも１つのメモリと、
前記少なくとも１つのメモリに結合された少なくとも１つのプロセッサと、
を備え、
前記少なくとも１つのプロセッサは、
ベアラベースド・ネットワークからベアラレス・ネットワークへのハンドオーバを示すmobility commandメッセージを前記ベアラベースド・ネットワークに関連付けられた無線アクセスネットワーク（RAN）ノードから受信するよう構成され、前記mobility commandメッセージは、前記ベアラレス・ネットワークに関連付けられたターゲットRANノードによって生成され、前記無線端末の少なくとも１つのパケットフローを転送するために前記ベアラレス・ネットワーク内で確立される少なくとも１つのセッションに関連付けられた無線コネクションを確立するために前記無線端末にとって必要となる無線リソース設定情報を包含し；
前記無線リソース設定情報を用いて、前記ベアラレス・ネットワークに関連付けられた前記ターゲットRANノードとの前記無線コネクションを確立するよう構成されている；
無線端末。

（付記９）
前記無線リソース設定情報は、前記ベアラベースド・ネットワークで使用される前記無線端末のためのベアラと前記ベアラレス・ネットワークで使用される前記無線端末のための少なくとも１つのパケットフローとのマッピングを示す情報を含む、
付記８に記載の無線端末。

（付記１０）
ベアラレス・ネットワークに関連付けられたターゲット無線アクセスネットワーク（RAN）ノードにおける方法であって、
ベアラベースド・ネットワークから前記ベアラレス・ネットワークへの無線端末のハンドオーバを要求するhandover requestメッセージをコアネットワークから受信すること、ここで、前記handover requestメッセージは、前記無線端末の少なくとも１つのパケットフローを転送するために前記ベアラレス・ネットワーク内で確立される少なくとも１つのセッションに関するフロー情報を含み；及び
前記handover requestメッセージに応答して、Target to Source Transparent Containerを包含するhandover request acknowledgeメッセージを前記コアネットワークに送信すること、ここで、前記Target to Source Transparent Containerは、前記フロー情報から導かれる無線リソース設定情報を包含し、且つ前記コアネットワークを介して前記ベアラベースド・ネットワークに関連付けられたソースRANノードにフォワードされる；
を備える、方法。

（付記１１）
ベアラベースド・ネットワークに関連付けられたソース無線アクセスネットワーク（RAN）ノードにおける方法であって、
前記ベアラベースド・ネットワークからベアラレス・ネットワークへの無線端末のハンドオーバを開始するためのhandover requiredメッセージをコアネットワークに送信すること；
Target to Source Transparent Containerを包含するhandover commandメッセージを前記コアネットワークから受信すること、ここで、前記Target to Source Transparent Containerは、前記ベアラレス・ネットワークに関連付けられたターゲットRANノードによって生成され、前記無線端末の少なくとも１つのパケットフローを転送するために前記ベアラレス・ネットワーク内で確立される少なくとも１つのセッションに関連付けられた無線コネクションを確立するために前記無線端末にとって必要となる無線リソース設定情報を包含し；及び
前記無線リソース設定情報を包含し且つ前記ベアラレス・ネットワークへのハンドオーバを示すmobility commandメッセージを前記無線端末に送信すること；
を備える、方法。

（付記１２）
無線端末における方法であって、
ベアラベースド・ネットワークからベアラレス・ネットワークへのハンドオーバを示すmobility commandメッセージを前記ベアラベースド・ネットワークに関連付けられた無線アクセスネットワーク（RAN）ノードから受信すること、ここで、前記mobility commandメッセージは、前記ベアラレス・ネットワークに関連付けられたターゲットRANノードによって生成され、前記無線端末の少なくとも１つのパケットフローを転送するために前記ベアラレス・ネットワーク内で確立される少なくとも１つのセッションに関連付けられた無線コネクションを確立するために前記無線端末にとって必要となる無線リソース設定情報を包含し；及び
前記無線リソース設定情報を用いて、前記ベアラレス・ネットワークに関連付けられた前記ターゲットRANノードとの前記無線コネクションを確立すること；
を備える、方法。

（付記１３）
ベアラレス・ネットワークに関連付けられたターゲット無線アクセスネットワーク（RAN）ノードにおける方法をコンピュータに行わせるためのプログラムであって、
前記方法は、
ベアラベースド・ネットワークから前記ベアラレス・ネットワークへの無線端末のハンドオーバを要求するhandover requestメッセージをコアネットワークから受信すること、ここで、前記handover requestメッセージは、前記無線端末の少なくとも１つのパケットフローを転送するために前記ベアラレス・ネットワーク内で確立される少なくとも１つのセッションに関するフロー情報を含み；及び
前記handover requestメッセージに応答して、Target to Source Transparent Containerを包含するhandover request acknowledgeメッセージを前記コアネットワークに送信すること、ここで、前記Target to Source Transparent Containerは、前記フロー情報から導かれる無線リソース設定情報を包含し、且つ前記コアネットワークを介して前記ベアラベースド・ネットワークに関連付けられたソースRANノードにフォワードされる；
を備える、
プログラム。

（付記１４）
ベアラベースド・ネットワークに関連付けられたソース無線アクセスネットワーク（RAN）ノードにおける方法をコンピュータに行わせるためのプログラムであって、
前記方法は、
前記ベアラベースド・ネットワークからベアラレス・ネットワークへの無線端末のハンドオーバを開始するためのhandover requiredメッセージをコアネットワークに送信すること；
Target to Source Transparent Containerを包含するhandover commandメッセージを前記コアネットワークから受信すること、ここで、前記Target to Source Transparent Containerは、前記ベアラレス・ネットワークに関連付けられたターゲットRANノードによって生成され、前記無線端末の少なくとも１つのパケットフローを転送するために前記ベアラレス・ネットワーク内で確立される少なくとも１つのセッションに関連付けられた無線コネクションを確立するために前記無線端末にとって必要となる無線リソース設定情報を包含し；及び
前記無線リソース設定情報を包含し且つ前記ベアラレス・ネットワークへのハンドオーバを示すmobility commandメッセージを前記無線端末に送信すること；
を備える、
プログラム。

（付記１５）
無線端末における方法をコンピュータに行わせるためのプログラムであって、
前記方法は、
ベアラベースド・ネットワークからベアラレス・ネットワークへのハンドオーバを示すmobility commandメッセージを前記ベアラベースド・ネットワークに関連付けられた無線アクセスネットワーク（RAN）ノードから受信すること、ここで、前記mobility commandメッセージは、前記ベアラレス・ネットワークに関連付けられたターゲットRANノードによって生成され、前記無線端末の少なくとも１つのパケットフローを転送するために前記ベアラレス・ネットワーク内で確立される少なくとも１つのセッションに関連付けられた無線コネクションを確立するために前記無線端末にとって必要となる無線リソース設定情報を包含し；及び
前記無線リソース設定情報を用いて、前記ベアラレス・ネットワークに関連付けられた前記ターゲットRANノードとの前記無線コネクションを確立すること；
を備える、
プログラム。

この出願は、２０１６年８月１０日に出願された日本出願特願２０１６－１５８２７９を基礎とする優先権を主張し、その開示の全てをここに取り込む。

１ User Equipment (UE)
２ LTE eNodeB (eNB)
３ New Radio (NR) NodeB (NB)
４ Evolved Packet Core（EPC）
５ NextGen (NG) Core
１１０５ ベースバンドプロセッサ
１１０６ アプリケーションプロセッサ
１１０８ メモリ
１２０４ プロセッサ
１２０５ メモリ
１３０４ プロセッサ
１３０５ メモリ
１４０２ プロセッサ
１４０３ メモリ

Claims (12)

1. 第５世代（5G）コアネットワークと接続するターゲット無線アクセスネットワーク（RAN）ノードであって、
   少なくとも１つのメモリと、
   前記少なくとも１つのメモリに結合された少なくとも１つのプロセッサと、
   を備え、
   前記少なくとも１つのプロセッサは、
   Mobility Management Entity（MME）と接続するソースeNodeBから、5Gコアネットワーク装置と接続する前記ターゲットRANノードへ、前記MMEと前記5Gコアネットワーク装置とをつなぐインターフェースを用いたハンドオーバを無線端末が行う間に、
   前記5Gコアネットワーク装置から、少なくとも１つのPDUセッションに関する情報を含むhandover requestメッセージを受信し、前記少なくとも１つのPDUセッションに関する情報は、フロー識別子及びフローQoSパラメータを含み、
   前記ターゲットRANノードとの無線コネクションを確立するために前記無線端末によって使用される前記無線端末に個別の無線リソース設定情報を、前記少なくとも１つのPDUセッションに関する情報に基づいて生成し、
   Target to Source Transparent Containerを含むhandover request acknowledgeメッセージを前記5Gコアネットワーク装置に送信するよう構成され、前記Target to Source Transparent Containerは前記無線リソース設定情報を含み、
   前記無線リソース設定情報は、前記5Gコアネットワーク装置、前記MME、及び前記ソースeNodeBを介して前記無線端末に送信される、
   ターゲットRANノード。
2. 前記PDUセッションは少なくとも１つのフローを含み、QoSはフローごとに扱われる、請求項１に記載のターゲットRANノード。
3. 前記handover request acknowledgeメッセージは、前記無線リソース設定情報を前記MMEを経由して前記ソースeNodeBにフォワードすることを前記5Gコアネットワーク装置に引き起こす、請求項１又は２に記載のターゲットRANノード。
4. 前記ターゲットRANノードは、NG2インターフェースを介して前記5Gコアネットワーク装置と接続し、
   前記ターゲットRANノードは、NG3インターフェースを介して前記5Gコアネットワーク内のUser Plane Function（UPF）ノードと接続する、
   請求項１乃至３のいずれかに記載のターゲットRANノード。
5. 5Gコアネットワーク装置であって、
   少なくとも１つのメモリと、
   前記少なくとも１つのメモリに結合された少なくとも１つのプロセッサと、
   を備え、
   前記少なくとも１つのプロセッサは、
   Mobility Management Entity（MME）と接続するソースeNodeBから、前記5Gコアネットワーク装置と接続するターゲットRANノードへ、前記MMEと前記5Gコアネットワーク装置とをつなぐインターフェースを用いたハンドオーバを無線端末が行う間に、
   前記MMEからforward relocation requestメッセージを受信し、
   前記forward relocation requestメッセージを受信したあと、少なくとも１つのPDUセッションを生成するための手順を実行し、
   前記PDUセッションを生成するための手順のあと、前記ターゲットRANノードへ前記少なくとも１つのPDUセッションに関する情報を含むhandover requestメッセージを送信し、前記少なくとも１つのPDUセッションに関する情報は、フロー識別子及びフローQoSパラメータを含み、
   前記handover requestメッセージを送信したあと、Target to Source Transparent Containerを含むhandover request acknowledgeメッセージを前記ターゲットRANノードから受信し、前記Target to Source Transparent Containerは前記ターゲットRANノードとの無線コネクションを確立するために前記無線端末によって使用される前記無線端末に個別の無線リソース設定情報を含み、
   handover request acknowledgeメッセージを受信したあと、前記MMEへ前記無線リソース設定情報を含むforward relocation responseメッセージを送信するよう構成され、
   前記無線リソース設定情報は、前記MME及び前記ソースeNodeBを介して前記無線端末に送信され、
   前記無線リソース設定情報は、前記少なくとも１つのPDUセッションに関する情報に基づいて前記ターゲットRANノードにより生成される、
   5Gコアネットワーク装置。
6. 前記forward relocation responseメッセージは、前記無線リソース設定情報を前記ソースeNodeBにフォワードすることを前記MMEに引き起こす、請求項５に記載の5Gコアネットワーク装置。
7. 第５世代（5G）コアネットワークと接続するターゲット無線アクセスネットワーク（RAN）ノードにおける方法であって、
   Mobility Management Entity（MME）と接続するソースeNodeBから、5Gコアネットワーク装置と接続する前記ターゲットRANノードへ、前記MMEと前記5Gコアネットワーク装置とをつなぐインターフェースを用いたハンドオーバを無線端末が行う間に、
   前記5Gコアネットワーク装置から少なくとも１つのPDUセッションに関する情報を含むhandover requestメッセージを受信し、前記少なくとも１つのPDUセッションに関する情報は、フロー識別子及びフローQoSパラメータを含み、
   前記ターゲットRANノードとの無線コネクションを確立するために前記無線端末によって使用される前記無線端末に個別の無線リソース設定情報を、前記少なくとも１つのPDUセッションに関する情報に基づいて生成し、
   Target to Source Transparent Containerを含むhandover request acknowledgeメッセージを前記5Gコアネットワーク装置に送信するよう構成され、前記Target to Source Transparent Containerは前記無線リソース設定情報を含み、
   前記無線リソース設定情報は、前記5Gコアネットワーク装置、前記MME、及び前記ソースeNodeBを介して前記無線端末に送信される、
   方法。
8. 前記PDUセッションは少なくとも１つのフローを含み、QoSはフローごとに扱われる、請求項７に記載の方法。
9. 前記handover request acknowledgeメッセージは、前記無線リソース設定情報を前記MMEを経由して前記ソースeNodeBにフォワードすることを前記5Gコアネットワーク装置に引き起こす、請求項７又は８に記載の方法。
10. 前記ターゲットRANノードは、NG2インターフェースを介して前記5Gコアネットワーク装置と接続し、
    前記ターゲットRANノードは、NG3インターフェースを介して前記5Gコアネットワーク内のUser Plane Function（UPF）ノードと接続する、
    請求項７乃至９のいずれかに記載の方法。
11. 5Gコアネットワーク装置における方法であって、
    Mobility Management Entity（MME）と接続するソースeNodeBから、前記5Gコアネットワーク装置と接続するターゲットRANノードへ、前記MMEと前記5Gコアネットワーク装置とをつなぐインターフェースを用いたハンドオーバを無線端末が行う間に、
    前記MMEからforward relocation requestメッセージを受信すること、
    前記forward relocation requestメッセージを受信したあと、少なくとも１つのPDUセッションを生成するための手順を実行し、
    前記PDUセッションを生成するための手順のあと、前記ターゲットRANノードへ前記少なくとも１つのPDUセッションに関する情報を含むhandover requestメッセージを送信し、前記少なくとも１つのPDUセッションに関する情報は、フロー識別子及びフローQoSパラメータを含み、
    前記handover requestメッセージを送信したあと、Target to Source Transparent Containerを含むhandover request acknowledgeメッセージを前記ターゲットRANノードから受信し、前記Target to Source Transparent Containerは前記ターゲットRANノードとの無線コネクションを確立するために前記無線端末によって使用される前記無線端末に個別の無線リソース設定情報を含み、
    handover request acknowledgeメッセージを受信したあと、前記MMEへ前記無線リソース設定情報を含むforward relocation responseメッセージを送信し、
    前記無線リソース設定情報は、前記MME及び前記ソースeNodeBを介して前記無線端末に送信され、
    前記無線リソース設定情報は、前記少なくとも１つのPDUセッションに関する情報に基づいて前記ターゲットRANノードにより生成される、
    方法。
12. 前記forward relocation responseメッセージは、前記無線リソース設定情報を前記ソースeNodeBにフォワードすることを前記MMEに引き起こす、請求項１１に記載の方法。

Images