JP7318779B2 - マスター無線アクセスネットワークノード、ａｍｆ、及びこれらの方法 - Google Patents

Description

本開示は、無線通信システムに関し、特に無線端末が異なる無線アクセスネットワークノードによって運用される複数のセルを同時に使用するデュアルコネクティビティ動作（dual-connectivity operation）に関する。

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

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

また、本明細書で使用される“LTE”との用語は、特に断らない限り、5G Systemとのインターワーキングを可能とするためのLTE及びLTE-Advancedの改良・発展を含む。5G 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のネットワーク又は論理的エンティティに関する用語は、特に断らない限り、5G 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（E-UTRAN））及びコアネットワーク（i.e., 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）ための情報を包含する。また、QoS Class Identifier（QCI）がQoSクラスの情報として用いられる。3GPP仕様は、各QCIとこれに関連付けられるQoS特性（例えば、パケットと伝送遅延に関する要求（i.e., Packet Delay Budget））の間の関係を規定している。

これに対して、5G Systemでは、無線ベアラがNG-RAN において使用されるかもしれないが、5GC内及び5GCとNG-RANの間のインタフェースにおいてベアラは使用されないことが検討されている。具体的には、EPS bearerの代わりにPDU flowsが定義され、１又は複数のSDFsは、１又は複数のPDU flowsにマップされる。5G UEとNG Core内のユーザプレーン終端エンティティ（i.e., EPC内のP-GWに相当するエンティティ）との間のPDU flowは、EPS Bearer-based QoSコンセプトにおけるEPSベアラに相当する。PDU flowは、5G system内でのパケットフォワーディング及び処理（treatment）の最も微細な粒度（finest granularity）に対応する。すなわち、5G Systemは、Bearer-based QoSコンセプトの代わりにFlow-based QoS（or per-flow QoS）コンセプトを採用する。Flow-based QoS コンセプトでは、QoSはPDU flow単位で取り扱われる（handled）。5G systemのQoSフレームワークでは、PDU flow は、N3インタフェースのトンネルのService Data Unitをカプセル化（encapsulating）するヘッダー内のPDU flow IDによって特定される。N3インタフェースは、5GCとgNB（i.e., NG-RAN）の間のユーザプレーン・インタフェースである。5G UEとデータネットワークとの間の関連付け（association）は、PDUセッション（PDU session）と呼ばれる。PDUセッションは、LTE及びLTE-AdvancedのPDNコネクション（PDN connection）に相当する用語である。複数のPDU flowsが１つのPDUセッション内に設定されることができる。3GPP仕様は、5G Systemのために、LTEのQCIに相当する5G QoS Indicator（5QI）を規定する。

なお、PDU flow は、“QoS flow”とも呼ばれる。QoS flowは、5G system内でのQoS処理（treatment）の最も微細な粒度（finest granularity）である。PDU session内の同一のN3マーキング値を有するユーザプレーントラフィックがQoS flowに対応する。N3マーキングは、上述のPDU flow IDに対応し、QoS flow Identity（QFI）とも呼ばれ、さらにFlow Identification Indicator（FII）とも呼ばれる。ここで、少なくとも仕様に規定される各5QIとこれと同じ値（番号）を持つ対応するQFIとの間には１対１の関係がある（i.e., one-to-one mapping）。

図１は、5G systemの基本アーキテクチャを示している。UEは、gNBとの間に１又はそれ以上のシグナリング無線ベアラ（Signalling Radio Bearers（SRBs））及び１又はそれ以上のデータ無線ベアラ（Data Radio Bearers（DRBs））を確立する。5GC及びgNBは、UEのためのコントロールプレーン・インタフェース及びユーザプレーン・インタフェースを確立する。5GCとgNB（i.e., RAN）の間のコントロールプレーン・インタフェースは、N2インタフェース、NG2インタフェース、又はNG-cインタフェースと呼ばれ、Non-Access Stratum（NAS）情報の転送、及び5GCとgNB間の制御情報（e.g., N2 AP Information Element）に使用される。5GCとgNB（i.e., RAN）の間のユーザプレーン・インタフェースは、N3インタフェース、NG3インタフェース、又はNG-uインタフェースと呼ばれ、UEのPDUセッション内の１又はそれ以上のPDU flowsのパケット（packets）の転送に使用される。

なお、図１に示されたアーキテクチャは、複数の5Gアーキテクチャ・オプション（又は配置シナリオ（deployment scenarios））の１つに過ぎない。図１に示されたアーキテクチャは、“Standalone NR (in NextGen System)”又は“オプション２”と呼ばれるアーキテクチャである。3GPPは、さらに、E-UTRA及びNR無線アクセス技術（E-UTRA and NR radio access technologies）を使用するマルチ接続動作（multi-connectivity operation）のための幾つかのネットワーク・アーキテクチャを検討している。マルチ接続動作の代表例が、１つのマスターノード（Master node (MN)）と１つのセカンダリノード（Secondary node (SN)）が互いに連携して１つのUEと同時に通信するデュアル接続（Dual Connectivity (DC)）である。E-UTRA及びNR無線アクセス技術を使用するデュアル接続動作は、Multi-RAT Dual Connectivity (MR-DC)と呼ばれる。MR-DCは、E-UTRAノード及びNRノード（E-UTRA and NR nodes）の間のデュアル接続（connectivity）である。

MR-DCでは、E-UTRAノード（i.e., eNB）及びNRノード（i.e., gNB）のうち一方がマスターノード（Master node (MN)）として動作し、他方がセカンダリノード（Secondary node (SN)）として動作し、少なくともMNがコアネットワークに接続される。MNは１又はそれ以上のMaster Cell Group（MCG）セルをUEに提供し、SNは１又はそれ以上のSecondary Cell Group（SCG）セルをUEに提供する。MR-DCは、“MR-DC with the EPC” 及び“MR-DC with the 5GC”を含む。

MR-DC with the EPCは、E-UTRA-NR Dual Connectivity (EN-DC)を含む。EN-DCでは、UEはMNとして動作するeNB及びSNとして動作するgNBに接続される。さらに、eNB（i.e., Master eNB）はEPCに接続され、gNB（i.e. Secondary gNB）はX2 interfaceを介してMaster eNBに接続される。

MR-DC with the 5GCは、NR-E-UTRA Dual Connectivity (NE-DC)及びNG-RAN E-UTRA-NR Dual Connectivity (NG-EN-DC)を含む。NE-DCでは、UEはMNとして動作するgNB及びSNとして動作するeNBに接続され、gNB（i.e., Master gNB）は5GCに接続され、eNB（i.e. Secondary eNB）はXn interfaceを介してMaster gNBに接続される。一方、NG-EN-DCでは、UEはMNとして動作するeNB及びSNとして動作するgNBに接続され、eNB（i.e., Master eNB）は5GCに接続され、gNB（i.e. Secondary gNB）はXn interfaceを介してMaster eNBに接続される。

図２、図３、及び図４は、上述した３つのDCタイプ、すなわちEN-DC、NE-DC、及びNG-EN-DCのネットワーク構成をそれぞれ示している。さらに、5G Systemは、２つのgNBsの間のデュアルコネクティビティをサポートする。本明細書では、２つのgNBsの間のデュアルコネクティビティは、NR-NR DCと呼ばれる。図５は、NR-NR DCのネットワーク構成を示している。

図６は、上述した３つのMR-DCタイプ並びにNR-NR DCがサポートするSRBs及びDRBsを示している。なお、図６は、現在3GPPにて議論中の3GPP Release 15においてサポートされるベアラタイプを例示している。したがって、これらのDCタイプによってサポートされるベアラタイプは図６と異なってもよい。

MCG SRBは、MCGセルにおいてUEとMNとの間に確立されるSRBであり、MNによって生成されるRadio Resource Control Protocol Data Units（RRC PDUs）は、MCG SRBでトランスポートされることができる。SNによって生成されるRRC PDUsは、MN及びMCG SRBを介してUEにトランスポートされることができる。これに代えて、SNは、SNによって生成されるRRC PDUsをUEとSNとの間で直接的にトランスポートするために、SCGセルにおいてUEとSNとの間のSRB（SCG SRB）を確立することができる。SCG SRB は、例えば、SRB3と呼ばれる。MCG split SRBは、MCG SRBを介してトランスポートされることができるRRC PPUsの複製（duplication）を行い、同じRRC PDUsがMCGセルとSCGセルの両方においてトランスポートされることを可能にする。

MCGベアラは、その無線プロトコルがMCGにのみ配置されるユーザプレーンベアラである。MCGスプリットベアラは、その無線プロトコルがMNにおいてスプリットされ、MCG及びSCGの両方に属するユーザプレーンベアラである。SCGベアラは、その無線プロトコルがSCGにのみ配置されるユーザプレーンベアラである。SCGスプリットベアラは、その無線プロトコルがSNにおいてスプリットされ、SCG及びMCGの両方に属するユーザプレーンベアラである。MCGスプリットベアラおよびSCGスプリットベアラは、PDCP data PDUsの複製（duplication）を行い、同じPDCP data PDUsがMCGセルとSCGセルの両方においてトランスポートされることを可能にする。

なお、NR（i.e., gNB及びUE）のレイヤ２機能は、LTE（i.e., eNB及びUE）のレイヤ２機能と同一ではない。例えば、NRのレイヤ２は、Service Data Adaptation Protocol（SDAP）サブレイヤ、Packet Data Convergence Protocol（PDCP）サブレイヤ、Radio Link Control（RLC）サブレイヤ、及びMedium Access Control（MAC）サブレイヤの４サブレイヤを含む。NR PDCPサブレイヤでは、DRBsのためのPDCP Sequence Number（SN）のサイズが12ビット又は18ビットであり、これはLTEのPDCP SNサイズ（i.e., 7ビット、12ビット、15ビット、又は18ビット）のサブセットである。ただし、LTE eNBが5GCに接続される場合、LTE（i.e., eNB及びUE）のレイヤ２はSDAPサブレイヤを含む。一方、NR gNBがEN-DCでSNとして運用される場合、NR（i.e., gNB及びUE）のレイヤ２は、SDAPサブレイヤを実装しなくてもよい。これに代えて、NR gNBがEN-DCでSNとして運用される場合、NR（i.e., gNB及びUE）のレイヤ２は、SDAPサブレイヤがこれを通過するPDUsに対してトランスペアレントであるように実装されてもよい。すなわち、SDAPサブレイヤにはTransparent Modeが実装されてもよい。

SDAPサブレイヤの主要なサービス及び機能は、QoS flowとデータ無線ベアラ（DRB）の間のマッピング、並びにダウンリンク（DL）及びアップリンク（UL）パケットへのQoS flow Identity （QFI）のマーキングを含む。SDAPの１つの（single）プロトコルエンティティは、各個（each individual）PDUセッションのために設定される（DCを除いて）。DCの場合、２つのエンティティが設定されることができる（i.e., １つはMCGのためでありもう１つはSCGのため）。

図７は、上述した5GCのnon-DC QoSアーキテクチャを示している(非特許文献１を参照)。各UEのために、5GCは１又はそれ以上のPDUセッションを確立する。各UEのために、NG-RANは、PDUセッション毎に（per PDU session）１又はそれ以上のDRBsを確立する。NG-RANは、異なるPDUセッションに属するパケット（packets）を異なるDRBにマップする。言い換えると、NG-RANは、異なるPDUセッションに属するQoS flows（i.e., 該QoS flowsで送信されるパケット（packets））を同じDRBへとマップしない。したがって、NG-RANは、PDU Session establishmentにおいて、5GCによって示された各PDUセッションのために少なくとも１つのデフォルトDRBを確立する。non-DCの場合、１つのPDUセッションに属する複数のQoSフローのパケット（packets）は、NG-RANノード（i.e., gNB）と5GC内のユーザプレーン機能（user plane function(UPF)）の間に設定されるNG-Uトンネルを介してデリバリーされる。NG-Uトンネルは、例えばGeneral Packet Radio Service (GPRS) Tunnelling Protocol（GTP）トンネルである。NG-Uトンネルの5GC内の終点ノードは、user plane gateway（UPGW）とも呼ばれる。5GCのQoSコンセプトでは、5GCは、１つのPDUセッション内のQoSレベルが互いに異なる複数のQoSフローを１つのNG-Uトンネルで転送することを許容する。NG-Uトンネルは、N3トンネル、NG3トンネル、又はPDUトンネル、PDUセッション・トンネルとも呼ばれる。

非特許文献２、３、及び４は、NG-RANにおいてDCが実行される場合に、5GC内のUPF（UPGW）における１つのPDUセッションのためのNG-Uリソース（resources）をスプリットするオプションを提案している。ここでのDCは、NR-NR DC並びにMR-DC with the 5GC（e.g.., NE-DC及びNG-EN DC）を含む。具体的には、5GシステムにおけるDCでは、２つのNG-Uトンネルが１つのPDUセッションのために同時にサポートされることが必要とされる。一方のNG-UトンネルはUPF（UPGW）とマスターノード（Master Node（MN））の間に設定され、もう１つのNG-UトンネルはUPF（UPGW）とセカンダリノード（Secondary Node（SN））の間に設定される。本明細書では、このような構成をPDUセッション・スプリットと呼ぶ。すなわちPDUセッション・スプリットは、２つ又はそれ以上のNG-Uトンネルが１つのPDUセッションのために同時にサポートされる構成と定義することができる。言い換えると、PDUセッション・スプリットは、１つのPDUセッション内の一部がMNに送られ、残りがSN(s)に送られることを許容する構成と定義することができる。

3GPPで検討されているPDUセッション・スプリットでは、MNが、MNを介して転送されていた１つのPDUセッションの複数のQoSフローのうちの一部をSNに移す。図８は、非特許文献３及び４に開示されたQoSフローのMNからSNへの移動を示している。図８の例では、MNを介して転送されていた１つのPDUセッションの２つのQoSフロー８０１及び８０２のうちQoSフロー８０２がSNに移される。MNからSNに移されたQoSフロー８０２は、UPF（UPGW）とSNの間に設定されたNG-Uトンネル８２２を介して転送される。すなわち、5GシステムにおけるDCでは、１つのPDUセッションの異なるQoSフロー８０１及び８０２が、異なる２つのNG-Uトンネル８２１及び８２２を介してMNとSNに同時に送られる必要がある。なお、MNに送られるQoSフロー８０１はMCGフローと呼ばれることがあり、SNに送られるQoSフロー８０２はSCGフローと呼ばれることがある。

3GPP TS 38.300 V0.4.1 (2017-06)、"3rd Generation Partnership Project; Technical Specification Group Radio Access Network; NR; NR and NG-RAN Overall Description; Stage 2 (Release 15)", June 2017 3GPP Tdoc R2-1703252, Samsung, "NR + NR DC: QOS Architecture", 3GPP TSG-RAN WG2 Meeting #97 bis, April 2017 3GPP Tdoc R3-171711, Ericsson, "PDU Session Split at UPF", 3GPP TSG-RAN WG3 Meeting #96, May 2017 3GPP Tdoc R3-171898, NTT DOCOMO, INC., "Response to R3-171711 (PDU Session split at UPF)", 3GPP TSG-RAN WG3 Meeting #96, May 2017

非特許文献２、３、及び４は、PDUセッション・スプリットのためにMN（e.g., MgNB）とコアネットワーク（e.g., 5GC）の間のシグナリング又は調整（coordination）が必要とされることを開示している。さらに、非特許文献２、３、及び４は、PDUセッション・スプリットのためにMN（e.g., MgNB）とSN（e.g., SgNB）の間のシグナリング又は調整（coordination）が必要されることを開示している。しかしながら、非特許文献２、３、及び４は、PDUセッション・スプリットのためのシグナリングの詳細を開示していない。したがって、PDUセッション・スプリットをどのように行うか明確でない。

本明細書に開示される実施形態が達成しようとする目的の１つは、PDUセッション・スプリットの無線通信ネットワークへの実装に寄与する装置、方法、及びプログラムを提供することである。なお、この目的は、本明細書に開示される複数の実施形態が達成しようとする複数の目的の１つに過ぎないことに留意されるべきである。その他の目的又は課題と新規な特徴は、本明細書の記述又は添付図面から明らかにされる。

第１の態様では、マスター無線アクセスネットワーク（RAN）ノードは、メモリ及び前記メモリに結合された少なくとも１つのプロセッサを含む。前記少なくとも１つのプロセッサは、無線端末とコアネットワーク内のユーザプレーン機能との間に既に確立済みの第１のPDUセッションの修正要求をコアネットワーク内のコントロールプレーン機能に送るよう構成される。前記修正要求は、前記既に確立済みの第１のPDUセッションに関してPDUセッション・スプリットが必要とされることを暗示的又は明示的に示す。前記修正要求は、前記既に確立済みの第１のPDUセッションに関連付けられた複数のQuality of Service（QoS）フローのうち特定の１又はそれ以上のQoSフローを、前記ユーザプレーン機能と前記マスターRANノードの間の第１のトンネルから前記ユーザプレーン機能とセカンダリRANノードの間の第２のトンネルに移動するように前記ユーザプレーン機能を制御することを前記コントロールプレーン機能に引き起こす。

第２の態様では、コアネットワークに配置されるコントロールプレーン・ノードは、メモリ及び前記メモリに結合された少なくとも１つのプロセッサを含む。前記少なくとも１つのプロセッサは、無線端末と前記コアネットワーク内のユーザプレーン機能との間に既に確立済みの第１のPDUセッションの修正要求をマスター無線アクセスネットワーク（RAN）ノードから受信するよう構成される。前記修正要求は、前記既に確立済みの第１のPDUセッションに関してPDUセッション・スプリットが必要とされることを暗示的又は明示的に示す。前記少なくとも１つのプロセッサは、さらに、前記修正要求の受信に応答して、前記既に確立済みの第１のPDUセッションに関連付けられた複数のQuality of Service（QoS）フローのうち特定の１又はそれ以上のQoSフローを、前記ユーザプレーン機能と前記マスターRANノードの間の第１のトンネルから前記ユーザプレーン機能とセカンダリRANノードの間の第２のトンネルに移動するように前記ユーザプレーン機能を制御するよう構成される。

第３の態様では、セカンダリ無線アクセスネットワーク（RAN）ノードは、メモリ及び前記メモリに結合された少なくとも１つのプロセッサを含む。前記少なくとも１つのプロセッサは、無線端末のためのデュアルコネクティビティのためのリソースを割り当てるよう要求するノード間メッセージをマスターRANノードから受信するよう構成される。前記ノード間メッセージは、さらに、前記無線端末とコアネットワーク内のユーザプレーン機能との間に既に確立済みの第１のPDUセッションにPDUセッション・スプリットが適用されることを暗示的又は明示的に示す。前記PDUセッション・スプリットは、前記第１のPDUセッションに関連付けられた複数のQuality of Service（QoS）フローのうちの１又はそれ以上の第１のQoSフローが前記ユーザプレーン機能と前記マスターRANノードの間の第１のトンネルを介して転送され、前記複数のQoSフローのうちの１又はそれ以上の第２のQoSフローが前記ユーザプレーン機能と前記セカンダリRANノードの間の第２のトンネルを介して転送される構成を含む。

第４の態様では、無線端末は、メモリ及び前記メモリに結合された少なくとも１つのプロセッサを含む。前記少なくとも１つのプロセッサは、デュアルコネクティビティのためのセカンダリセルグループ設定を示すRRCコネクション再構成メッセージをマスター（RAN）ノード又はセカンダリRANノードから受信するよう構成される。前記RRCコネクション再構成メッセージは、さらに、前記無線端末とコアネットワーク内のユーザプレーン機能との間に既に確立済みの第１のPDUセッションにPDUセッション・スプリットが適用されることを暗示的又は明示的に示す。前記PDUセッション・スプリットは、前記第１のPDUセッションに関連付けられた複数のQuality of Service（QoS）フローのうちの１又はそれ以上の第１のQoSフローが前記ユーザプレーン機能と前記マスターRANノードの間の第１のトンネルを介して転送され、前記複数のQoSフローのうちの１又はそれ以上の第２のQoSフローが前記ユーザプレーン機能とセカンダリRANノードの間の第２のトンネルを介して転送される構成を含む。

第５の態様では、マスター無線アクセスネットワーク（RAN）ノードにおける方法は、無線端末とコアネットワーク内のユーザプレーン機能との間に既に確立済みの第１のPDUセッションの修正要求をコアネットワーク内のコントロールプレーン機能に送ることを含む。前記修正要求は、前記既に確立済みの第１のPDUセッションに関してPDUセッション・スプリットが必要とされることを暗示的又は明示的に示す。

第６の態様では、コアネットワークに配置されるコントロールプレーン・ノードにおける方法は、無線端末と前記コアネットワーク内のユーザプレーン機能との間に既に確立済みの第１のPDUセッションの修正要求をマスター無線アクセスネットワーク（RAN）ノードから受信することを含む。前記修正要求は、前記既に確立済みの第１のPDUセッションに関してPDUセッション・スプリットが必要とされることを暗示的又は明示的に示す。さらに、当該方法は、前記既に確立済みの第１のPDUセッションに関連付けられた複数のQuality of Service（QoS）フローのうち特定の１又はそれ以上のQoSフローを、前記ユーザプレーン機能と前記マスターRANノードの間の第１のトンネルから前記ユーザプレーン機能とセカンダリRANノードの間の第２のトンネルに移動するように前記ユーザプレーン機能を制御することを含む。

第７の態様では、セカンダリ無線アクセスネットワーク（RAN）ノードにおける方法は、無線端末のためのデュアルコネクティビティのためのリソースを割り当てるよう要求するノード間メッセージをマスターRANノードから受信することを含む。前記ノード間メッセージは、さらに、前記無線端末とコアネットワーク内のユーザプレーン機能との間に既に確立済みの第１のPDUセッションにPDUセッション・スプリットが適用されることを暗示的又は明示的に示す。

第８の態様では、無線端末における方法は、デュアルコネクティビティのためのセカンダリセルグループ設定を示すRRCコネクション再構成メッセージをマスター（RAN）ノード又はセカンダリRANノードから受信することを含む。前記RRCコネクション再構成メッセージは、さらに、前記無線端末とコアネットワーク内のユーザプレーン機能との間に既に確立済みの第１のPDUセッションにPDUセッション・スプリットが適用されることを暗示的又は明示的に示す。

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

上述の態様によれば、PDUセッション・スプリットの無線通信ネットワークへの実装に寄与する装置、方法、及びプログラムを提供できる。

5G Systemの基本アーキテクチャを示す図である。 EN-DCのネットワーク構成を示す図である。 NE-DCのネットワーク構成を示す図である。 NG-EN-DCのネットワーク構成を示す図である。 NR-NR DCのネットワーク構成を示す図である。 3GPPにて議論中の３つのDCタイプによってサポートされるベアラタイプを示すテーブルである。 5G Systemのnon-DC QoSアーキテクチャを示す図である。 5G SystemのNR-NR DC QoSアーキテクチャを示す図である。 幾つかの実施形態に係る無線通信ネットワークの構成例を示す図である。 第１の実施形態に係るマスターノードの動作の一例を示すフローチャートである。 第１の実施形態に係るコントロールプレーン機能エンティティの動作の一例を示すフローチャートである。 第１の実施形態に係るPDUセッション・スプリットに関するシグナリングの一例を示すシーケンス図である。 “PDU Session Request To Be Modified List”情報要素（Information Element（IE））のフォーマットの一例を示す図である。 “PDU Session Request To Be Modified List”IEのフォーマットの一例を示す図である。 “PDU Session Request To Be Modified List” IEのフォーマットの一例を示す図である。 第１の実施形態に係るPDUセッション・スプリットに関するシグナリングの一例を示すシーケンス図である。 “PDU Session Request To Be Setup List”IEのフォーマットの一例を示す図である。 第２の実施形態に係るコントロールプレーン機能エンティティの動作の一例を示すフローチャートである。 第２の実施形態に係るPDUセッション・スプリットに関するシグナリングの一例を示すシーケンス図である。 第４の実施形態に係るコントロールプレーン機能エンティティの動作の一例を示すフローチャートである。 第４の実施形態に係るPDUセッション・スプリットに関するシグナリングの一例を示すシーケンス図である。 第５の実施形態に係るマスターノードの動作の一例を示すフローチャートである。 第５の実施形態に係るPDUセッション・スプリットに関するシグナリングの一例を示すシーケンス図である。 第７の実施形態に係るマスターノードの動作の一例を示すフローチャートである。 第７の実施形態に係るPDUセッション・スプリットに関するシグナリングの一例を示すシーケンス図である。 第７の実施形態に係る無線端末の動作の一例を示すシーケンス図である。 第８の実施形態に係るPDUセッション・スプリットに関するシグナリングの一例を示すシーケンス図である。 第８の実施形態に係るPDUセッション・スプリットに関するシグナリングの一例を示すシーケンス図である。 幾つかの実施形態に係るマスターノードの構成例を示すブロック図である。 幾つかの実施形態に係る無線端末の構成例を示すブロック図である。 幾つかの実施形態に係るコントロールプレーン機能エンティティの構成例を示すブロック図である。

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

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

以下に示される複数の実施形態は、NR-NR DC及びMR-DC with the 5GCを主な対象として説明される。しかしながら、これらの実施形態は、その他のRATsを使用するDCアーキテクチャをサポートする他の無線通信システムに適用されてもよい。

＜第１の実施形態＞
図９は、本実施形態を含む幾つかの実施形態に係る無線通信ネットワークの構成例を示している。図９の例では、無線通信ネットワークは、マスターノード（MN）１、セカンダリノード（SN）２、UE３、及びコアネットワーク４を含む。図９に示された無線通信ネットワークは、NR-NR DC又はMR-DC with the 5GCをサポートする。すなわち、MN１及びSN２の各々は、NRノード（i.e., gNB）又はE-UTRAノード（i.e., eNB）である。MN１及びSN２はインタフェース９０１及び９０４を介してコアネットワーク４に接続される。コアネットワーク４は、5GCである。インタフェース９０１及び９０４は、NGインタフェース(i.e., NG-c及びNG-u、NG2及びNG3、又はN2及びN3)である。MN１とSN２の間は、インタフェース９０３によって接続される。インタフェース９０３は、Xnインタフェースである。

コアネットワーク４は、コントロールプレーン機能（control plane function(CPF)）及びユーザプレーン機能（UPF）を含む。コントロールプレーン機能は、例えば、Access and Mobility Management Function（AMF）、Session Management Function（SMF）、及びPolicy Control function（PCF）を含む。コントロールプレーン機能は、１又はそれ以上のコントロールプレーン機能エンティティ（又は１又はそれ以上のコントロールプレーン・ノード）によって提供される。ユーザプレーン機能は、１又はそれ以上のユーザプレーン機能エンティティ（又は１又はそれ以上のユーザプレーンノード）によって提供される。図９の例は、１つのAMF/SMFエンティティ５、及び１つのUPFエンティティ６を示している。AMF/SMFエンティティ５は、AMF若しくはSMF又は両方を提供する。AMF/SMFエンティティ５は、例えば、１若しくはそれ以上のエンティティ、１若しくはそれ以上の物理ノード、又は１若しくはそれ以上のコンピュータを含んでもよい。同様に、UPFエンティティ６も、１若しくはそれ以上のエンティティ、１若しくはそれ以上の物理ノード、又は１若しくはそれ以上のコンピュータを含んでもよい。例えば、UPFエンティティ６はPDUセッション毎にあってもよいし、複数のUPFエンティティ６が１つのPDUセッションのために使用されてもよい。

UE３は、NR-NR DC若しくはMR-DC with the 5GC又は両方をサポートする。すなわち、UE３は、NR無線アクセス技術又はE-UTRA及びNR無線アクセス技術を使用するデュアル接続動作（dual-connectivity operation）をサポートする。UE３は、MN１及びSN２と同時に通信する能力を有する。言い換えると、UE３は、MN１によって提供されるマスターセルグループ（Master Cell Group（MCG））に属するセルをSN２によって提供されるセカンダリセルグループ（Secondary Cell Group（SCG））に属するセルとアグリゲートする能力を有する。MCGは、マスターRATを用いて提供される１又はそれ以上のセルを含む。SCGは、セカンダリRATを用いて提供される１又はそれ以上のセルを含む。MN１とUE３の間のエアインタフェース９０２は、コントロールプレーン・コネクション（e.g., RRCコネクション、シグナリング無線ベアラ（SRBs））及びユーザプレーン・コネクション（e.g., データ無線ベアラ（DRBs））を提供する。一方、SN２とUE３の間のエアインタフェース９０５は、少なくともユーザプレーン・コネクションを含む。エアインタフェース９０５は、コントロールプレーン・コネクションを含んでもよいし、含まなくてもよい。

MN１、SN２、UE３、及びコアネットワーク４は、PDUセッション・スプリットをサポートするよう構成されている。以下では、これらのノード又はエンティティによって行われるPDUセッション・スプリットのための動作が説明される。

図１０は、MN１の動作の一例を示すフローチャートである。ステップ１００１では、MN１は、既に確立済みのPDUセッションの修正要求をコアネットワーク４に送る。当該修正要求は、UE３のために既に確立済みのPDUセッションに関してPDUセッション・スプリットが必要とされることを暗示的又は明示的に示す。ステップ１００２では、MN１は、当該修正要求に対する応答メッセージをコアネットワーク４から受信する。

図１１は、コアネットワーク４の動作の一例を示すフローチャートである。図１１の手順は、AMF/SMFエンティティ５によって行われる。ステップ１１０１では、AMF/SMFエンティティ５は、既に確立済みのPDUセッションの修正要求（これは、PDUセッション・スプリットの要否を暗示的又は明示的に示す）をMN１から受信する。

AMF/SMFエンティティ５は、受信した修正要求を解析し、PDUセッション・スプリットを行う必要があるか否か（又はPDUセッション・スプリットを要求されているか否か）を判定する。すなわち、AMF/SMFエンティティ５は、当該修正要求がPDUセッション・スプリットが必要とされることを示す場合に、UE３のために既に確立済みのPDUセッションが２以上のRANノード（e.g., MN１及びSN２）にスプリットされる必要があることを認識する。

PDUセッション・スプリットが必要とされる場合、AMF/SMFエンティティ５は、既に確立済みのPDUセッションに関連付けられた複数のQoSフローのうち特定の１又はそれ以上のQoSフローを、MN１へのNG-UトンネルからSN２へのNG-Uトンネルに移動するようにUPFエンティティ６を制御する（ステップ１１０２）。幾つかの実装において、AMF/SMFエンティティ５は、MN１へのNG-Uトンネル及びSN２へのNG-Uトンネルを設定するために、これら２つのトンネルに同じPDUセッションIDを重複して使用する（すなわち、同じPDUセッションIDを再利用する）。AMF/SMFエンティティ５は、PDUセッション・スプリットが必要とされている（又はPDUセッション・スプリットを要求されている）PDUセッションに対してスプリットを適用できない場合、それを示す応答メッセージをMN１に返してもよい。

幾つかの実装において、PDU SESSION RESOURCE MODIFY INDICATIONメッセージがステップ１００１（及びステップ１１０１）に示された修正要求の送信のために使用されてもよい。このPDU SESSION RESOURCE MODIFY INDICATIONメッセージは、特定のUEのために確立済みのPDUセッション（session(s)）の修正を要求するためにMN１によって使用される。PDU SESSION RESOURCE MODIFY INDICATIONメッセージは、NG-c（又はN2）インタフェースを介して送られるNG Application Protocol (NGAP)（又はN2 Application Protocol（N2AP））メッセージの１つである。

図１２は、PDU SESSION RESOURCE MODIFY INDICATIONメッセージが使用される例を示している。ステップ１２０１では、MN１は、PDUセッション・スプリット要求を含むPDU SESSION RESOURCE MODIFY INDICATIONメッセージをAMF/SMFエンティティ５に送る。ステップ１２０２では、AMF/SMFエンティティ５は、PDU SESSION RESOURCE MODIFY CONFIRMメッセージをMN１に送る。このPDU SESSION RESOURCE MODIFY CONFIRMメッセージは、ステップ１００２（及びステップ１１０３）に示された応答メッセージに相当する。

一例では、PDU SESSION RESOURCE MODIFY INDICATIONメッセージ内の修正要求は、PDUセッション・スプリットの必要性を明示的に示すPDUセッション・タイプ情報であってもよい。AMF/SMFエンティティ５は、当該PDUセッション・タイプ情報がPDUセッション・スプリットが必要とされる（又は要求される）ことを示す場合に、PDUセッションが２以上のRANノード（e.g., MN１及びSN２）にスプリットされる必要があることを認識してもよい。反対に、当該PDUセッション・タイプ情報がPDUセッション・スプリットが必要とされる（又は要求される）ことを示さない場合に、AMF/SMFエンティティ５は、PDUセッションが他のRANノード（e.g., SN２）に移動される必要があることを認識してもよい。

なお、PDU SESSION RESOURCE MODIFY INDICATIONメッセージは、“PDU Session Request To Be Modified List” 情報要素（IE）を含む。図１３Ａは、“PDU Session Request To Be Modified List”IEのフォーマットの一例を示している。図１３Ａに示されるように、“PDU Session Request To Be Modified List” IEは、“PDU Session Request To Modify Item IEs”IEを含む。“PDU Session Request To Modify Item IEs”IEは、“PDU Session ID” IE及び“DL TNL Information”IEを含む。“PDU Session ID” IEは、修正が必要とされる（又は修正が要求される）各PDUセッションのPDU Session IDを示す。“DL TNL Information”IEは、“PDU Session ID” IE によって特定されるPDUセッションのためのダウンリンク（DL）Transport Network Layer（TNL）アドレス及びTunnel Endpoint Identifier（TEID）を示す。これらDL TNLアドレス及びTEIDは、NG-UトンネルのRANノード（e.g., gNB）側のエンドポイントを特定する。

さらに、図１３Ａの例では、“PDU Session Request To Be Modified List”IEは、必須情報要素（mandatory IEs）の１つとして“Modification Type”IEを含むよう改良されている。“Modification Type”IEは、“PDU Session ID”IEによって特定されるPDUセッションの修正がPDUセッション全体に適用されるか、又は一部に適用されるかを示す。例えば、“Modification Type”IEは、“Modify All”又は“Modify Partially”を示す。“Modification Type”IEが“Modify Partially”にセットされる場合、これはPDUセッションの一部に対する修正（つまり、PDUセッション・スプリットを要求していること）を示し、“PDU Session Request To Be Modified List” IEは、さらに“QoS Flow Request To Be Modified List”IEを含む。“QoS Flow Request To Be Modified List”IEは、MN１からSN２に移される各QoSフローの識別子（i.e., QoS Flow Indicator（QFI））を含む。なお、“QoS Flow Request To Be Modified List”IEは、“QoS Flow To Be Modified List”IE、若しくは“QoS Flow To Modify List”IEでもよい。

図１３Ａの例に代えて、図１３Ｂに示されるように、“PDU Session Request To Be Modified List”IEは、必須情報要素（mandatory IEs）の１つとして“Modification Type Option”IEを含むよう改良されてもよい。“Modification Type Option”IEは、“PDU Session ID” IE によって特定されるPDUセッションの修正がPDUセッション・スプリットであるか否かを示す。例えば、“Type Option”IEは、“All”又は“Split（or Partial）”を示す。“Type Option”IEが“Split（or Partial）”にセットされる場合、“PDU Session Request To Be Modified List” IEは、さらに“QoS Flow Request To Be Modified List”IEを含む。“QoS Flow Request To Be Modified List”IEは、MN１からSN２に移される各QoSフローの識別子（i.e., QoS Flow Indicator（QFI））を含む。

例えば、“Modification Type”IE（図１３Ａ）が“Modify Partially”にセットされている場合、又は“Modification Type Option”IE（図１３Ｂ）が“Split（or Partial）”にセットされている場合、AMF/SMFエンティティ５は、当該PDUセッションが２以上のRANノード（e.g., MN１及びSN２）にスプリットされる必要があること（又は当該PDUセッションをスプリットするように要求されていること）を認識してもよい。一方、“Modification Type”IE（図１３Ａ）が“Modify All”にセットされている場合、又は“Modification Type Option”IE（図１３Ｂ）が“All”にセットされている場合、AMF/SMFエンティティ５は、当該PDUセッションが他のRANノード（e.g., SN２）に移動される必要があること（又は当該PDUセッションを他のRANノードに移動するように要求されていること）を認識してもよい。

さらに、AMF/SMFエンティティ５は、PDUセッション・タイプ情報（e.g., Modification Type IE, or Modification Type Option IE）がPDUセッション・スプリットが必要とされる（又は要求される）ことを示すか否かに応じて、“DL TNL Information”IEに含まれるDL TNLアドレスが当該PDUセッションの新たなDLアドレスであるか又は追加のDLアドレスであるかを判定するよう構成されてもよい。具体的には、“Modification Type”IE（図１３Ａ）が“Modify Partially”にセットされている場合、又は“Modification Type Option”IE（図１３Ｂ）が“Split（or Partial）”にセットされている場合、AMF/SMFエンティティ５は、“DL TNL Information”IEに含まれるDL TNLアドレスが当該PDUセッションの追加のDLアドレス（i.e., 追加されるNG-Uトンネルに対応するSN２のアドレス）であると判定してもよい。一方、“Modification Type”IE（図１３Ａ）が“Modify All”にセットされている場合、又は“Modification Type Option” IE（図１３Ｂ）が“All”にセットされている場合、AMF/SMFエンティティ５は、“DL TNL Information”IEに含まれるDL TNLアドレスが当該PDUセッションの新たなDLアドレスであると判定してもよい。

“Modification Type Option” IE（図１３Ｂ）の値“All”の代わりに“MN”及び“SN”が規定されてもよい。つまり、“Modification Type Option” IEは、“MN”、“SN”、及び“Split（or Partial）”のいずれかにセットされてもよい。例えば、“Modification Type Option” IE が“MN”（又は“SN”）にセットされている場合、AMF/SMFエンティティ５は、当該PDUセッションがMN１（又は“SN２”）に移動される必要があることを認識してもよい。また、“Modification Type Option” IEが“MN”又は“SN”にセットされている場合、AMF/SMFエンティティ５は、“DL TNL Information”IEに含まれるDL TNLアドレスが当該PDUセッションの新たなDLアドレスであると判定してもよい。

これに代えて、AMF/SMFエンティティ５は、“PDU Session Request To Be Modified List” IEが “QoS Flow Request To Be Modified List”IEを含むか否かに応じて、PDUセッション・スプリットが必要とされるか否かを判定してもよい。具体的には、AMF/SMFエンティティ５は、“PDU Session Request To Be Modified List” IE に含まれる“QoS Flow Request To Be Modified List”IEが当該PDUセッションの複数のQoSフローの一部のみを示す場合に、PDUセッション・スプリットが必要とされることを認識してもよい。一方、AMF/SMFエンティティ５は、“QoS Flow Request To Be Modified List”IEが当該PDUセッションの複数のQoSフローの一部のみを示し、且つ“DL TNL Information”IEに含まれるDL TNLアドレスが当該PDUセッションの残りの全てのQoSフローのためのDL TNLアドレスと一致する場合、スプリットされていた当該PDUセッションが１つのRANノードにマージ（統合）されることを認識してもよい。

図１４は、“PDU Session Request To Be Modified List”IEのフォーマットのさらに他の例を示している。図１４の例では、“PDU Session Request To Be Modified List” IEは、オプション要素（optional IEs）の１つとして“Modification Type Option”IEを含み、これが必要に応じて“Split”にセットされるよう改良されている。例えば、“Modification Type Option”IEが“Split”にセットされ且つ“PDU Session Request To Be Modified List”IEに含まれている場合、AMF/SMFエンティティ５は、当該PDUセッションが２以上のRANノード（e.g., MN１及びSN２）にスプリットされる必要があること（又は当該PDUセッションをスプリットするように要求されていること）を認識してもよい。一方、“Modification Type Option”IEが“PDU Session Request To Be Modified List”IEに含まれていない場合、AMF/SMFエンティティ５は、当該PDUセッションが他のRANノード（e.g., SN２）に移動される必要があること（又は当該PDUセッションを他のRANノードに移動するように要求されていること）を認識してもよい。なお、図１４の“Type Option”IEが上述のPDUセッション・タイプ情報に相当してもよい。

これに代えて、図１４の“Modification Type Option”IEは、“Split”及び“Merge（or Unify）”のいずれかにセットされてもよい。例えば、“Modification Type Option”IEが“Split”にセットされている場合、AMF/SMFエンティティ５は、当該PDUセッションが２以上のRANノード（e.g., MN１及びSN２）にスプリットされる必要があることを認識してもよい。一方、“Modification Type Option”IEが“Merge（or Unify）”にセットされている場合、AMF/SMFエンティティ５は、２以上のRANノード（e.g., MN１及びSN２）にスプリットされていた当該PDUセッションが１つのRANノードにマージ（統合）されることを認識してもよい。

“PDU SESSION RESOURCE MODIFY CONFIRM”メッセージは、例えば“PDU Session Confirm To Modify List” 情報要素（IE）を含む。これは、MN１からPDUセッション・スプリットを要求された1つ以上のPDUセッションのうち、AMF/SMFエンティティ５が受け入れた（又はPDUセッション・スプリットが成功した）PDUセッションを示す。さらに、“PDU SESSION RESOURCE MODIFY CONFIRM”メッセージは、AMF/SMFエンティティ５が受け入れなかった（又はPDUセッション・スプリットが成功しなかった）PDUセッションを示す“PDU Session Not Admitted List” IE（又は“PDU Session Failed to Modify List” IE）を含んでもよい。

他の実装において、新たなNGAPメッセージが図１０のステップ１００１（及び図１１のステップ１１０１）に示された修正要求の送信のために定義されてもよい。当該新たなNGAPメッセージは、既に設定済みのPDUセッションをスプリットすることをコアネットワーク４に要求する。言い換えると、当該新たなNGAPメッセージは、既に設定済みのPDUセッションを他のRANノード（e.g., SN２）に追加的にセットアップすることをコアネットワーク４に要求する。例えば、新たなNGAPメッセージの名称は、PDU SESSION RESOURCE SETUP INDICATIONメッセージ又はPDU SESSION RESOURCE ADDITION INDICATIONメッセージであってもよい。また、これに応答するコアネットワーク４からRANノードへのNGAPメッセージの名称は、PDU SESSION RESOURCE SETUP CONFIRMメッセージ又はPDU SESSION RESOURCE ADDITION CONFIRMメッセージであってもよい。

図１５は、新たなNGAPメッセージ（e.g., PDU SESSION RESOURCE SETUP INDICATIONメッセージ）が使用される例を示している。ステップ１５０１では、MN１は、PDUセッション・スプリット要求を含むPDU SESSION RESOURCE SETUP INDICATIONメッセージをAMF/SMFエンティティ５に送る。ステップ１５０２では、AMF/SMFエンティティ５は、PDU SESSION RESOURCE SETUP CONFIRMメッセージをMN１に送る。このPDU SESSION RESOURCE SETUP CONFIRMメッセージは、図１０のステップ１００２（及び図１１のステップ１１０３）に示された応答メッセージに相当する。

PDU SESSION RESOURCE SETUP INDICATIONメッセージは、“PDU Session Request To Be Setup List” 情報要素（IE）を含んでもよい。図１６は、“PDU Session Request To Be Setup List”IEのフォーマットの一例を示している。“PDU Session Request To Be Setup List” IEは、“PDU Session Request To Be Setup Item IEs”IEを含む。“PDU Session Request To Be Setup Item IEs”IEは、“PDU Session ID” IE及び“DL TNL Information”IEを含む。“PDU Session ID” IEは、２以上のRANノードにスプリットされる各PDUセッションのPDU Session IDを示す。“DL TNL Information”IEは、“PDU Session ID” IE によって特定されるPDUセッションのためのDL TNLアドレス及びTEIDを示す。さらに、図１６の例では、“PDU Session Request To Be Setup List”IEは、 “QoS Flow Request To Be Modified List”IEを含む。“QoS Flow Request To Be Modified List”IEは、MN１からSN２に移される各QoSフローの識別子（i.e., QoS Flow Indicator（QFI））を含む。“PDU Session Request To Be Setup List”IEの名称は、“PDU Session Request To Be Added List”IEでもよい。

以上の説明から理解されるように、本実施形態では、MN１は、既に確立済みのPDUセッション修正要求をコアネットワーク４に送るよう構成され、且つ当該確立済みのPDUセッションに関してPDUセッション・スプリットが必要とされることを暗示的又は明示的に示す要求（又は表示又は情報要素）を当該修正要求に含めるよう構成されている。さらに、AMF/SMFエンティティ５は、当該修正要求を受信するよう構成されている。これにより、AMF/SMFエンティティ５は、PDUセッションの修正の際に、当該PDUセッションが２以上のRANノード（e.g., MN１及びSN２）にスプリットされるべきか、あるいは他のRANノード（e.g., SN２）に移されるべきかを適切に判定できる。

なお、本実施形態のPDUセッション・スプリットでは、MN１を介して転送されていたPDUセッションの複数のQoSフローのうちの一部が１以上のSN２に移されてもよい。より具体的には、本実施形態のPDUセッション・スプリットは、UE３のために既にMN１において確立済みのPDUセッションがMN１及び少なくとも１つのSN（SN２を含む）にスプリットされる（split over the MN 1 and at least one SN including the SN 2）ケースを含む。さらに、本実施形態のPDUセッション・スプリットは、UE３のために既にMN１において確立済みのPDUセッションがMN１からSN２に移され、さらに当該移されたPDUセッションがSN２と少なくとも１つの他のSNにスプリットされる（split over the SN 2 and at least one other SN）ケースを含む。

さらに、本実施形態のPDUセッション・スプリットでは、SN２を介して転送されていたPDUセッションの複数のQoSフローのうちの一部がMN１に移されてもよい。より具体的には、本実施形態のPDUセッション・スプリットは、UE３のために既にSN２において確立済みのPDUセッションがSN２及びMN１にスプリットされる（split over the SN 2 and the MN 1）ケースを含む。さらに、本実施形態のPDUセッション・スプリットは、UE３のために既にSN２において確立済みのPDUセッションがSN２からMN１に移され、さらに当該移されたPDUセッションがMN１と少なくとも１つの他のSNにスプリットされる（split over the MN 1 and at least one SN）ケースを含む。

さらにまた、本実施形態のPDUセッション・スプリットでは、MN１及びSN２のうち一方にのみ設定されていたPDUセッションに関連付けられる新たなQoSフローがMN１及びSN２のうちの他方に追加されてもよい。この場合、AMF/SMFエンティティ５は、既に確立済みのPDUセッションの修正要求（これは、PDUセッション・スプリットが必要とされることを暗示的又は明示的に示す）をMN１から受信したことに応答して、既に確立済みのPDUセッションに関連付けられた新たなQoSフローを設定してもよい。このとき、MN１及びSN２は、新たなQoSフローを既存のデータ無線ベアラ（DRB）にマッピングしてもよい。これに代えて、MN１及びSN２は、DRBを新たに確立し、それに新たなQoSフローをマッピングしてもよい。

PDUセッション・スプリットが必要とされる場合、AMF/SMFエンティティ５は、既に確立済みのPDUセッションに関連付けられた複数のQoSフローのうち特定の１又はそれ以上のQoSフローを、MN１へのNG-UトンネルからSN２へのNG-Uトンネルに移動するようにUPFエンティティ６を制御する（ステップ１１０２）。

＜第２の実施形態＞
本実施形態は、PDUセッション・スプリットのための他の改良を提供する。本実施形態に係る無線通信ネットワークの構成例は、図９に示された例と同様である。

本実施形態では、AMF/SMFエンティティ５は、第１の実施形態で説明されたPDUセッション・スプリットのための修正要求の送信よりも前に行われる当該PDUセッションの確立手順において、当該PDUセッションに関してPDUセッション・スプリットが許可されるか否か（又はPDUセッション・スプリットが可能が否か）を示すPDUセッション単位の（on a per-PDU session basis）又はQoSフロー単位の表示をRANノード（e.g., 将来MN１として動作するgNB又はeNB）に送るよう構成される。RANノードは、PDUセッションの確立手順において、当該PDUセッションに関してPDUセッション・スプリットが許可されるか否かを示すPDUセッション単位の（on a per-PDU session basis）又はQoSフロー単位の表示をAMF/SMFエンティティ５から受信するよう構成される。

当該表示は、当該PDUセッションのためのPDUセッション・リソースのセットアップを要求するためにAMF/SMFエンティティ５からRANノードに送られるメッセージに含まれてもよい。

幾つかの実装において、MN１は、DCを開始するときに、PDUセッション・スプリットをコアネットワーク４に要求するか否かを、PDUセッションの確立手順の際に受信済みのPDUセッション・スプリットが許可されるか否かを示す表示に基づいて判定してもよい。

図１７は、本実施形態に係るコアネットワーク４の動作の一例を示すフローチャートである。図１７の手順は、AMF/SMFエンティティ５によって行われる。ステップ１７０１では、AMF/SMFエンティティ５は、UE３のためのPDUセッションの確立をトリガーするNASメッセージを包含するNGAPメッセージをRANノード（e.g., 将来MN１として動作するgNB又はeNB）から受信する。例えば、当該NASメッセージは、コアネットワーク４への初期アタッチ及びデフォルトPDUセッションのセットアップのためのAttach Requestメッセージであってもよい。この場合、当該NGAPメッセージは、INITIAL UE MESSAGEメッセージであってもよい。さらに又はこれに代えて、当該NASメッセージは、新たに（1つ目又は追加の）PDUセッションの確立を要求するためにUE３によって送信されるPDU Session Establishment Requestメッセージであってもよい。この場合、NGAPメッセージは、INITIAL UE MESSAGEメッセージ又はUPLINK NAS TRANSPORTメッセージであってもよい。

ステップ１７０２では、AMF/SMFエンティティ５は、UE３のためのPDUセッションをセットアップするようにUPFエンティティ６を制御する。ステップ１７０３では、AMF/SMFエンティティ５は、当該新たに確立されるPDUセッションのPDUセッション・スプリットが許可されるか否かを判定する。ステップ１７０４では、AMF/SMFエンティティ５は、PDUセッション・スプリットが許可されるか否かを示すPDUセッション・リソースのセットアップ要求メッセージを当該RANノードに送る。

図１８は、PDUセッション確立手順で行われるシグナリングの一例を示すシーケンス図である。ステップ１８０１では、RANノード７（e.g., 将来MN１として動作するgNB又はeNB）は、NGAP: INITIAL UE MESSAGEメッセージ又はNGAP: UPLINK NAS TRANSPORTメッセージをAMF/SMFエンティティ５に送る。ステップ１８０１のNGAPメッセージは、UE３のためのPDUセッションの確立をトリガーするNASメッセージ（e.g., PDU Session Establishment Request）を包含する。

ステップ１８０２では、AMF/SMFエンティティ５は、NGAP:INITIAL CONTEXT SETUP REQUESTメッセージ又はNGAP: PDU SESSION RESOURCE SETUP REQUESTメッセージをRANノード７に送る。ステップ１８０２のNGAPメッセージは、UE３のために確立されるPDUセッションのためのPDUセッション・リソースのセットアップを要求するためにRANノード７に送られる。ステップ１８０２のNGAPメッセージは、当該PDUセッションに関してPDUセッション・スプリットが許可されるか否かを示すPDUセッション単位の（on a per-PDU session basis）又はQoSフロー単位の表示を含む。当該表示は、例えば、“PDU Session Split Permission Indication” IEであってもよいし、“PDU Session Split”IE（これはallowed又はnot-allowedに設定される）であってもよいし、“PDU Session Split Support” IE（これはsupport又はnot-supportに設定される）であってもよい。

以上の説明から理解されるように、本実施形態では、AMF/SMFエンティティ５は、PDUセッションの確立手順において、当該PDUセッションに関してPDUセッション・スプリットが許可されるか否かを示すPDUセッション単位の（on a per-PDU session basis）又はQoSフロー単位の表示をRANノードに送るよう構成される。RANノードは、PDUセッションの確立手順において、当該PDUセッションに関してPDUセッション・スプリットが許可されるか否かを示すPDUセッション単位の（on a per-PDU session basis）又はQoSフロー単位の表示をAMF/SMFエンティティ５から受信するよう構成される。これにより、RANノード（i.e., 将来MN１として動作するgNB又はeNB）は、予めPDUセッション・スプリットが許可されているPDUセッション（又はQoSフロー）についてのみ選択的にPDUセッション・スプリットをコアネットワーク４に要求するよう動作することができる。

なお、本実施形態は、PDUセッション単位又はQoSフロー単位でPDUセッション・スプリットが許可されるか否か（又は可能か否か）を示す表示を使用する例を示した。このことはPDUセッション・スプリットを許可するか否かの判定（又はPDUセッション・スプリットが可能か否かのサポート）をPDUセッション単位又はQoSフロー単位でするようにAMF/SMFエンティティ５を限定するものではない。つまり、当該表示は、確立される（つまり、確立が要求される）PDUセッション毎に（又はQoSフロー毎に）送られるが、当該表示の内容は、AMF/SMFエンティティ５によって制御される複数のPDUセッション及びこれに包含される複数のQoSフローの間で共通であってもよい。

＜第３の実施形態＞
本実施形態は、第２の実施形態の変形例を提供する。本実施形態に係る無線通信ネットワークの構成例は、図９に示された例と同様である。

AMF/SMFエンティティ５は、PDUセッション・スプリットが許可されるか否か（又は可能か否か）を示すUE単位の表示をRANノード７に送ってもよい。この場合、AMF/SMFエンティティ５は、PDUセッション・スプリットを許可するか否かをUE単位で判定してもよい。いくつかの実装において、AMF/SMFエンティティ５は、UE３のためのPDUセッションの確立手順において、PDUセッション・スプリットが当該UE３に許可されるか否かを示すUE単位の表示をRANノード７に送ってもよい。

これにより、RANノード７（i.e., 将来MN１として動作するgNB又はeNB）は、予めPDUセッション・スプリットが許可されているUE３のPDUセッション（又はQoSフロー）についてのみ選択的にPDUセッション・スプリットをコアネットワーク４に要求するよう動作することができる。

＜第４の実施形態＞
本実施形態は、PDUセッション・スプリットのための他の改良を提供する。本実施形態に係る無線通信ネットワークの構成例は、図９に示された例と同様である。

本実施形態では、AMF/SMFエンティティ５は、第１の実施形態で説明されたPDUセッション・スプリットのための修正要求の送信よりも前に行われるRANノード（e.g., 将来MN１として動作するgNB又はeNB）とAMF/SMFエンティティ５との間のシグナリング・コネクション（i.e., NG2/NG-Cインタフェース）をセットアップする又は修正する手順において、PDUセッション・スプリットが許可されるか否か（又はPDUセッション・スプリットが可能か否か）を示す表示を当該RANノードに送るよう構成される。当該RANノードは、AMF/SMFエンティティ５とのシグナリング・コネクションのセットアップ又は修正手順において、PDUセッション・スプリットが許可されるか否か（又はPDUセッション・スプリットが可能か否か）を示す表示をAMF/SMFエンティティ５から受信するよう構成される。

当該表示は、AMF/SMF単位の表示であってもよい。これに代えて、当該表示は、PDUセッション・スプリットの許可若しくは不許可（又は可能若しくは不可能）をUPF毎に示してもよい。さらに又はこれに代えて、当該表示は、PDUセッション・スプリットの許可若しくは不許可（又は可能若しくは不可能）をネットワークスライス毎に示してもよい。

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

したがって、幾つかの実装において、コアネットワーク４は、複数のネットワークスライスを提供してもよい。複数のネットワークスライスは、例えば、それぞれのネットワークスライス上でUE３に提供されるサービス又はユースケースによって区別される。ユースケースは、例えば、広帯域通信（enhanced Mobile Broad Band: eMBB）、高信頼・低遅延通信（Ultra Reliable and Low Latency Communication: URLLC）、及び多接続M2M通信（massive Machine Type Communication: mMTC）を含む。これらは、スライスタイプ（e.g., Slice/Service Type (SST)）と呼ばれる。

さらにMN１若しくはSN２又は両方は、１又はそれ以上のネットワークスライスをサポートしてもよい。言い換えると、１又はそれ以上のネットワークスライスが、MN１及びSN２のセルにおいて使用可能であってもよい。幾つかの実装において、MN１若しくはSN２又は両方は、end-to-endネットワークスライシングをUE３に提供するために、UE３のために選択されたコアネットワーク４のネットワークスライス（Core Network (CN)スライスと呼ぶ）に関連付けられたRANスライス及び無線（radio）スライスをUE３に割り当ててもよい。

AMF/SMFエンティティ５からRANノード（e.g., 将来MN１として動作するgNB又はeNB）に送られる上述の表示がPDUセッション・スプリットの許可又は不許可をネットワークスライス（CNスライス）毎に示すことによって、例えば、以下に示す幾つかの利点がもたらされる。

例えば、MN１は、UE３のためのCNスライス選択を行う際に、各CNスライスがPDUセッション・スプリットを許可しているか否かを考慮してもよい。これにより、例えば、MN１は、将来的にDCを実行する予定があるUE３のために、PDUセッション・スプリットが許可されているCNスライスを選択することができる。

また、例えば、MN１は、予めPDUセッション・スプリットが許可されているCNスライスを利用しているPDUセッションについてのみ選択的にPDUセッション・スプリットをコアネットワーク４に要求することができる。

また、例えば、MN１は、PDUセッション・スプリットが許可されていないCNスライスを利用しているPDUセッションに関してDCを開始する際に、他のCNスライスへ当該PDUセッションを切り替えるようコアネットワーク４に要求することができる。

図１９は、本実施形態に係るコアネットワーク４の動作の一例を示すフローチャートである。図１９の手順は、AMF/SMFエンティティ５によって行われる。ステップ１９０１では、AMF/SMFエンティティ５は、NGインタフェース・セットアップ要求をRANノード（e.g., 将来MN１として動作するgNB又はeNB）から受信する。ステップ１９０２では、AMF/SMFエンティティ５は、PDUセッション・スプリットが許可されるか否か（又はPDUセッション・スプリットが可能か否か）を示すNGインタフェース・セットアップ応答メッセージを当該RANノード（e.g., MN１）に送る。

図２０は、NGセットアップ手順で行われるシグナリングの一例を示すシーケンス図である。NGセットアップ手順は、RANノード７（e.g., 将来MN１として動作するgNB又はeNB）及びAMF/SMFエンティティ５がN2インタフェース（NG-Cインタフェース）上で正しく相互運用（interoperate）することを可能にする。

ステップ２００１では、RANノード７は、NG SETUP REQUESTメッセージをAMF/SMFエンティティ５に送る。ステップ２００２では、AMF/SMFエンティティ５は、NG SETUP RESPONSEメッセージをRANノード７に送る。当該NG SETUP RESPONSEメッセージは、PDUセッション・スプリットが許可されるか否かを示す表示を含む。当該表示は、例えば、“PDU Session Split Permission Indication”IEであってもよいし、“PDU Session Split”IE（これはallowed又はnot-allowedに設定される）であってもよいし、“PDU Session Split Support” IE（これはsupport又はnot-supportに設定される）であってもよい。既に説明したように、当該表示は、PDUセッション・スプリットの許可若しくは不許可（又は可能若しくは不可能）をネットワークスライス（CNスライス）毎に示してもよい。

以上の説明から理解されるように、本実施形態では、AMF/SMFエンティティ５は、NGセットアップ手順において、PDUセッション・スプリットが許可されるか否か（又は可能か否か）を示す表示をRANノードに送るよう構成される。RANノードは、NGセットアップ手順において、PDUセッション・スプリットが許可されるか否かを示す表示をAMF/SMFエンティティ５から受信するよう構成される。これにより、RANノード（i.e., 将来MN１として動作するgNB又はeNB）は、予めPDUセッション・スプリットが許可されている場合にのみPDUセッション・スプリットをコアネットワーク４に要求するよう動作することができる。

＜第５の実施形態＞
本実施形態は、PDUセッション・スプリットのための他の改良を提供する。本実施形態に係る無線通信ネットワークの構成例は、図９に示された例と同様である。

本実施形態では、MN１は、UE３のためのデュアルコネクティビティ（DC）で使用されるPDUセッション（及び該PDUセッションのQoS flow(s)）のためのリソースを割り当てるよう要求するセカンダリセルグループ（SCG）追加要求メッセージをSN２に送るよう構成される。SN２は、当該SCG追加要求メッセージをMN１から受信するよう構成される。さらに、当該SCG追加要求メッセージは、UE３とコアネットワーク４内のUPFエンティティ６との間に既に確立済みのPDUセッションにPDUセッション・スプリットが適用されることを暗示的又は明示的に示す。当該SCG追加要求メッセージは、SgNB ADDITION REQUESTメッセージ（又はSN ADDITION REQUESTメッセージ）であってもよい。

幾つかの実装において、当該SCG追加要求メッセージは、当該PDUセッション又は当該PDUセッションの１又はそれ以上のQoSフローにPDUセッション・スプリットが適用されることを明示的に示すPDUセッション確立タイプ情報（e.g., “PDU Session Establishment Type”情報要素（IE））を含んでもよい。例えば、PDUセッション確立タイプ情報は、SCG追加要求メッセージに含まれるオプション要素（optional IEs）の１つであってもよい。この場合、SN２は、PDUセッション確立タイプ情報がSCG追加要求メッセージに含まれている場合（又はこれが“Split”にセットされている場合）、当該PDUセッションにPDUスプリットが適用されることを認識してもよい。

図２１は、MN１の動作の一例を示すフローチャートである。ステップ２１０１では、MN１は、既に確立済みのPDUセッションの複数のQoSフローのうち一部をSN２に移すために、SCG追加要求メッセージをSN２に送る。当該SCG追加要求メッセージは、UE３のためのDCで使用されるPDUセッション（及び該PDUセッションのQoS flow(s)）のためのリソースを割り当てるよう要求し且つPDUセッション・スプリットを示す。ステップ２１０２では、SN２は、応答メッセージ（e.g., SN ADDITION REQUEST ACKNOWLEDGEメッセージ）をSN２から受信する。

図２２は、SgNB（又はSN）追加準備（addition preparation）手順で行われるシグナリングの一例を示すシーケンス図である。ステップ２２０１では、MN１は、SN ADDITION REQUESTメッセージをSN２に送る。当該SN ADDITION REQUESTメッセージは、“PDU Session ID”情報要素（IE）、“PDU Session Establishment Type” IE及び“QoS Flow List”IEを含む。“PDU Session ID”IEは、MN１（i.e., MCG）からSN２（i.e., SCG）に移されるPDUセッション、AMF/SMFエンティティ５によってUPFエンティティ６からMN１（i.e., MCG）及びSN２（i.e., SCG）にスプリットされるMN１（i.e., MCG）に確立されているPDUセッション、又はSN２（i.e., SCG）に新たに確立されるPDUセッション、のうち少なくともいずれかの識別子を示す。“PDU Session Establishment Type”IEは、SN２に追加されるPDUセッションにPDUセッション・スプリットが適用されているか否かを示す。“QoS Flow List”IEは、SN２に追加されるPDUセッションに含まれ、且つMN１（i.e., MCG）からSN２（i.e., SCG）に移される又はSN２（i.e., SCG）に新たに確立される１又はそれ以上のQoSフローを示す。

なお、当該SN ADDITION REQUESTメッセージは、さらに、必須情報要素（mandatory IEs）の１つとして“Bearer Option”IEを含む。“Bearer Option”IEは、SCGに設定されるべきデータ無線ベアラ（DRB）のタイプ（i.e., SCG bearer、MCG split bearer、又はSCG split bearer）を示す。したがって、上述の“PDU Session Establishment Type”IE及び“QoS Flow List”IEは、SCG bearer又はSCG split bearerを示す“Bearer Option”IEに関連付けられてもよい。言い換えると、上述の“PDU Session Establishment Type”IE及び“QoS Flow List”IEは、SCG bearer又はSCG split bearerを示す“Bearer Option”IEに包含されてもよい。なお、MCG split bearerおよびSCG split bearerは、まとめてSplit bearerとして示されてもよいし、Split bearer anchored at MN (MCG)およびSplit bearer anchored at SN (SCG)と示されてもよい。

当該SN ADDITION REQUESTメッセージは、セカンダリセルグループ（SCG）設定に関連する情報（i.e., RRC: SCG-ConfigInfo）を含む。例えば、当該SCG設定に関連する情報は、MN１からSN２に追加を要求されるDRBのリストを含む。当該DRBリストは、MCGにおけるPDUセッション識別子（i.e., PDU Session ID）、DRB識別子（i.e., DRB Identity）、及び１又はそれ以上のQoSフローの識別子（i.e., QFIs）の関連付けを示す。これに代えて、当該SCG設定に関連する情報は、MN１からSN２に追加を要求されるPDUセッションの識別子（i.e., PDU Session ID）、及び１又はそれ以上のQoSフローの識別子（i.e., QFIs）の関連付けを示してもよい。さらに、当該SCG設定に関連する情報は、PDUセッション・スプリットを明示的に示す情報（e.g., PDUセッション・タイプ情報又はDRBタイプ情報）を含んでもよい。また、SCG設定に関連する情報は、MN１によるUE３のためのマスターセルグループ（MCG）設定（e.g. MCG Configuration）の少なくとも一部を含んでもよい。例えば、MCG設定は、各MCGセルの個別無線リソース設定（e.g., “RadioResourceConfigDedicatedMCG”IE）を含む。各MCGセルの個別無線リソース設定は、既に確立されているDRBのリストを含む。当該DRBリストは、PDUセッション識別子（i.e., PDU Session ID）、DRB識別子（i.e., DRB Identity）、及び１又はそれ以上のQoSフローの識別子（i.e., QFIs）の関連付けを示す。当該MCG設定は、PDUセッション・スプリットを明示的に示す情報（e.g., PDUセッション・タイプ情報又はDRBタイプ情報）を含んでもよい。

ステップ２２０２では、SN２は、SN ADDITION ACKNOWLEDGEメッセージをMN１に送る。当該SN ADDITION ACKNOWLEDGEメッセージは、セカンダリセルグループ（SCG）設定（i.e., RRC: SCG-Config）を含む。当該SCG設定は、追加されるSCGセルリスト（i.e., Primary Secondary Cell（PSCell）及びゼロ又はそれ以上（zero or more）SCG SCell(s)）、及び各SCGセルの個別無線リソース設定（e.g., “RadioResourceConfigDedicatedSCG”IE）を含む。各SCGセルの個別無線リソース設定は、追加されるDRBのリストを含み、当該DRBリストは、PDUセッション識別子（i.e., PDU Session ID）、DRB識別子（i.e., DRB Identity）、及び１又はそれ以上のQoSフローの識別子（i.e., QFIs）の関連付けを示す。当該SCG設定は、PDUセッション・スプリットを明示的に示す情報（e.g., PDUセッション・タイプ情報又はDRBタイプ情報）を含んでもよい。

ここで、PDUセッション識別子の代わりに、又はPDUセッション識別子と共に、当該PDUセッションに関連付けられたSDAPエンティティの識別子（e.g., SDAP Identity, or SDAPレイヤとPDCPレイヤの関連付けを示すService Channel Identity）が使用されてもよい。例えば、Service Channel Identityは、SDAPエンティティと、それに接続される各PDCPエンティティとの間のService Access Point (SAP)として規定されてもよい。また、SDAPエンティティの識別子はMN１によって割り当てられてもよく、MN１はそれをSN ADDITION REQUESTメッセージに含まれる情報要素の１つ（e.g., RRC: SCG-ConfigInfoのSDAP-Config）としてSN２に通知し、SN２がそれを使用してもよい。さらに、PDUセッション・スプリットされた同じPDUセッション識別子に関連付けられたSDAPエンティティには、同じSDAPエンティティの識別子が割り当てられてもよい。

MN１からSN２への１又はそれ以上のQoSフローの移動（i.e., オフローディング）は、DRB単位で行われてもよいし、QoSフロー単位で行われてもよい。DRB単位のオフローディングでは、１つのMCGベアラ又はMCGスプリットベアラの全てのQoSフローがSCGベアラ又はSCGスプリットベアラに移される。当該QoSフローがマッピングされる（含まれる）DRBに対応するSCGベアラ又はSCGスプリットベアラは、SN Additionプロシージャにおいて新規に確立される。このとき、SN２（i.e., SCG）は、MN１（i.e., MCG）におけるQoSフローとDRBの間のマッピング（包含関係）と同一の設定をする。さらに、SN２（i.e., SCG）は、SN Additionプロシージャ中新たにSN２（i.e., SCG）に確立される他のQoSフローも、MN1（i.e., MCG）からSN２（i.e., SCG）に移されるQoSフローと同じDRBにマッピングしてもよい。これに代えて、MN１（i.e., MCG）で同じDRBにマッピングされていた複数QoSフローは、SN２（i.e., SCG）において別々のDRBにマッピングされてもよい。これらのSN２（i.e., SCG）におけるQoSフローとDRBの間のマッピングは、MN１がSN２に指定してもよいし、MN１がMCGにおけるQoSフローとDRBの間のマッピングをSN２に通知して最終的にSN２が決定してもよい。

以上の説明から理解されるように、本実施形態では、MN１は、UE３のためのDCのためのリソースを割り当てるよう要求するSCG追加要求メッセージをSN２に送るよう構成される。SN２は、当該SCG追加要求メッセージをMN１から受信するよう構成される。さらに、当該SCG追加要求メッセージは、UE３とコアネットワーク４内のUPFエンティティ６との間に既に確立済みのPDUセッションにPDUセッション・スプリットが適用されることを暗示的又は明示的に示す。これにより、例えば、以下に示す幾つかの利点がもたらされる。

例えば、SN２は、同じPDUセッションの複数のQoSフローを１つのDRBにマッピングすることが許容されている。したがって、SN２は、同一PDUセッションのPDUセッション・スプリットが適用されたQoSフローとMCGスプリットベアラのQoSフローとを同じDRBマッピングできる。

また、例えば、SN２は、SN２から他のSNにQoSフローをさらに移す場合、又はSN２からMN１にQoSフローを戻す場合に、当該QoSフローにPDUセッション・スプリットが適用されていることを他のSN又はMN１に知らせることができる。

＜第６の実施形態＞
本実施形態は、第５の実施形態に示されたMN1とSN２の間のインタラクションの変形例を提供する。本実施形態に係る無線通信ネットワークの構成例は、図９に示された例と同様である。

MN１は、UE３のためのデュアルコネクティビティ（DC）で使用されるPDUセッション（及び該PDUセッションのQoS flow(s)）のためのリソースを割り当てるため又は修正するための準備を要求するために、SCG追加要求メッセージとは別の基地局間（又はノード間）メッセージ（e.g., XnAPメッセージ）をSN２に送ってもよい。例えば、MN１は、セカンダリセルグループ（SCG）修正準備要求メッセージを送ってもよい。当該SCG修正準備要求メッセージは、SgNB MODIFICATION REQUESTメッセージ（又はSN MODIFICATION REQUESTメッセージ）であってもよい。当該SCG修正準備要求メッセージは、既にUE３のために設定済みの１又はそれ以上のSCGセル（i.e., PSCell、SCG SCell(s)、又はPSCell及びSCG SCell(s)）の修正をSN２に要求する。当該SCG修正準備要求メッセージは、UE３のために既に確立済みのPDUセッションの複数のQoSフローのうち一部をMN１からSN２に移すために使用されることができる。さらに又はこれに代えて、当該SCG修正準備要求メッセージは、UE３のために既に確立済みのPDUセッションの複数のQoSフローのうち一部をSN２からMN１に移すために使用されることができる。この場合、当該SCG修正準備要求メッセージは、既に確立済みのPDUセッションにPDUセッション・スプリットが適用されることを暗示的又は明示的に示してもよい。

第５の実施形態で説明されたのと同様に、MN１からSN２への１又はそれ以上のQoSフローの移動（i.e., オフローディング）は、DRB単位で行われてもよいし、QoSフロー単位で行われてもよい。DRB単位のオフローディングでは、１つのMCGベアラ又はMCGスプリットベアラの全てのQoSフローがSCGベアラ又はSCGスプリットベアラに移される。当該QoSフローがマッピングされる（含まれる）DRBに対応するSCGベアラ又はSCGスプリットベアラは、SN Modificationプロシージャにおいて新規に確立されてもよいし、既に確立済みであってもよい。

同様に、SN２からMN１への１又はそれ以上のQoSフローの移動（i.e., オフローディング）は、DRB単位で行われてもよいし、QoSフロー単位で行われてもよい。DRB単位のオフローディングでは、１つのSCGベアラ又はSCGスプリットベアラの全てのQoSフローがMCGベアラ又はMCGスプリットベアラに移される。当該QoSフローがマッピングされる（含まれる）DRBに対応するMCGベアラ又はMCGスプリットベアラは、SN Modificationプロシージャにおいて新規に確立されてもよいし、既に確立済みであってもよい。

本実施形態で説明されたMN1とSN２の間のインタラクションは、スプリットされたPDUセッション（及び該PDUセッションのQoS flow(s)）を１つのRANノードにマージ（統合）する場合にも適用されることができる。例えば、MN１からSN２へスプリットされたPDUセッションが再びMN１へマージされてもよい。あるいは、MN１からSN２へスプリットされたPDUセッションのMN１に残る全てのQoSフローがSN２へ移されてもよい。同様に、SN２からMN１へスプリットされたPDUセッションが再びSN２へマージされてもよい。あるいは、SN２からMN１へスプリットされたPDUセッションのSN２に残る全てのQoSフローがMN１へ移されてもよい。

なお、SCG修正準備要求メッセージを含むSCG修正のためのSN Modificationプロシージャは、MN１自身から開始（initiate）されてもよい。これに代えて、MN１にSN Modificationプロシージャを行うことを要求するSCG修正要求メッセージを送信することにより、SN２から開始（initiate）されてもよい。当該、SCG修正要求メッセージは、SgNB MODIFICATION REQUIREDメッセージ（又はSN MODIFICATION REQUIREDメッセージ）であってもよい。

さらに、第５の実施形態で説明されたSCG追加要求メッセージに含まれる情報要素が、SCG修正準備要求メッセージ若しくはSCG修正要求メッセージ又は両方に含まれてもよい。さらに、各情報要素の名称または構成は異なってもよい。例えば、“PDU Session Establishment Type”IEは、“PDU Session Modification Type”IEに置き換えられてもよい。また、PDUセッション確立タイプ情報（e.g., “PDU Session Establishment Type”情報要素（IE））は、PDUセッション・スプリットの場合には“Split”にセットされ、スプリットされたPDUセッションをマージ（統合）する場合には“Merge（or Unify）”にセットされてもよい。

ここで、PDUセッション識別子の代わりに、又はPDUセッション識別子と共に、当該PDUセッションに関連付けられたSDAPエンティティの識別子（e.g., SDAP Identity, or SDAPレイヤとPDCPレイヤの関連付けを示すService Channel Identity）が使用されてもよい。例えば、Service Channel Identityは、SDAPエンティティと、それに接続される各PDCPエンティティとの間のService Access Point (SAP)として規定されてもよい。例えば、Service Channel Identityは、SDAPエンティティと、それに接続される各PDCPエンティティとの間のService Access Point (SAP)として規定されてもよい。また、SDAPエンティティの識別子はMN１によって割り当てられてもよく、MN１はそれをSN MODIFICATION REQUESTメッセージに含まれる情報要素の１つ（e.g., RRC: SCG-ConfigInfoのSDAP-Config）としてSN２に通知し、SN２がそれを使用してもよい。さらに、PDUセッション・スプリットされた同じPDUセッション識別子に関連付けられたSDAPエンティティには、同じSDAPエンティティの識別子が割り当てられてもよい。

＜第７の実施形態＞
本実施形態は、PDUセッション・スプリットのための他の改良を提供する。本実施形態に係る無線通信ネットワークの構成例は、図９に示された例と同様である。

本実施形態では、MN１又はSN２は、DCのためのセカンダリセルグループ（SCG）設定を示すRRCコネクション再構成（Reconfiguration）メッセージをUE３に送信するよう構成される。UE３は、当該RRCコネクション再構成メッセージをMN１又はSN２から受信するよう構成される。当該RRCコネクション再構成メッセージは、さらに、MN１（i.e., MCG）からSN２（i.e., SCG）に移される１若しくはそれ以上のQoSフロー、又は１若しくはそれ以上のデータ無線ベアラ（DRB）にPDUセッション・スプリットが適用されることを暗示的又は明示的に示す。言い換えると、当該RRCコネクション再構成メッセージは、UE３とコアネットワーク４との間に既に確立済みのPDUセッションにPDUセッション・スプリットが適用されることを暗示的又は明示的に示す。

一例として、PDUセッション・スプリットを暗示的又は明示的に示すために、RRCコネクション再構成メッセージに含まれるセカンダリセルグループの設定情報（e.g., SCG Configuration）が、PDUセッションに関する情報（e.g., PDUセッション識別子、PDUセッション・タイプ情報）を含んでもよい。例えば、セカンダリセルグループの設定情報は、マスターセルグループ（MCG）で既に確立済みのPDUセッションの識別子（i.e., PDU Session ID）と、当該PDUセッションに含まれ且つMN１（i.e., MCG）からSN２（i.e., SCG）に移される１又はそれ以上のQoSフローと、当該QoSフローを包含するデータ無線ベアラの関連付けを示してもよい。

例えば、PDUセッション・スプリットを暗示的に示すために、セカンダリセルグループ（SCG）の設定情報（e.g., “SCG Configuration” IE）の中の、SCGに確立されるDRB(s)の設定情報（e.g., “DRB-ToAddModSCG” IE）は、PDUセッション識別子（i.e., PDU Session ID）、QoSフロー識別子（i.e., QoS Flow Indicator (QFI)）、及びDRB識別子（i.e., DRB Identity）を含んでもよい。SCGに確立されるDRB(s)の設定情報（e.g., “DRB-ToAddModSCG” IE）は、さらに、対応するDRBタイプの情報（e.g., MCG split, SCG, SCG split）を含んでもよい。

これに代えて、PDUセッション・スプリットを明示的に示すために、SCGの設定情報（e.g., “SCG Configuration” IE）の中の、SCGに確立されるDRB(s)の設定情報（e.g., “DRB-ToAddModSCG” IE）は、PDUセッション・タイプ情報（e.g., PDU-SessionType（“split”に設定））を含んでもよい。PDUセッション・タイプ情報は、PDUセッション・スプリットでない場合には“non-split”に設定されてもよい。これに代えて、PDUセッション・スプリットの場合にのみ、PDUセッション・タイプ情報が含まれてもよい。さらに、DRB(s)の設定情報は、PDUセッション識別子（i.e., PDU Session ID）、QoSフロー識別子（i.e., QoS Flow Indicator (QFI)）、及びDRB識別子（i.e., DRB Identity）、及び、対応するDRBタイプの情報（e.g., MCG split, SCG, SCG split）を含んでもよい。

さらに又はこれに代えて、PDUセッション・スプリットを明示的に示すために、セカンダリセルグループ（SCG）の設定情報（e.g., SCG Configuration）は、MCGにおいて既に確立済みのPDUセッション又は１若しくはそれ以上のQoSフローにPDUセッション・スプリットが適用されることを明示的に示す表示を含んでもよい。当該表示は、例えば、データ無線ベアラタイプ情報であってもよい。データ無線ベアラタイプ情報は、PDUセッション・スプリットが適用されていることを示すデータ無線ベアラタイプ、例えば“PDU session Split (PS) SCG bearer”又は“PDU session Split (PS) SCG split bearer”を示してもよい。

なお、上述のセカンダリセルグループ（SCG）の設定情報（e.g., SCG Configuration）に含まれる全て又は一部の情報要素（IEs）は、SN２により生成され、SN２からMN１に転送されてもよい。さらにMN１は、当該情報要素を透過的に（transparently）UE３へ送信し、UE３がそれをMCGで受信してもよい。

さらに、上述のRRCコネクション再構成（Reconfiguration）メッセージは、マスターセルグループの設定情報（e.g., MCG Configuration）を含んでいてもよい。マスターセルグループの設定情報（e.g., MCG Configuration）は、上述のセカンダリセルグループ（SCG）の設定情報（e.g., SCG Configuration）と共に１つのRRCコネクション再構成（Reconfiguration）メッセージで送信されてもよい。上述のセカンダリセルグループ（SCG）の設定情報（e.g., SCG Configuration）に含まれる情報要素（e.g., PDUセッション識別子及びPDUセッション・タイプ情報）の少なくとも一部は、セカンダリセルグループ（SCG）の設定情報（e.g., SCG Configuration）の代わりに、マスターセルグループの設定情報（e.g., MCG Configuration）に含まれてもよい。例えば、マスターセルグループ（MCG）の設定情報は、マスターセルグループで既に確立済みのPDUセッションの識別子（i.e., PDU Session ID）と、当該PDUセッションに含まれ且つMN１（i.e., MCG）からSN２（i.e., SCG）に移されない１又はそれ以上のQoSフローと、当該QoSフローを包含するデータ無線ベアラの関連付けを示してもよい。

図２３及び図２４は、MN１の動作の一例を示すフローチャートである。ステップ２３０１及びステップ２４０１では、MN１は、DCのためのSCG設定を実行するよう要求し且つPDUセッション・スプリットを示すRRC Connection ReconfigurationメッセージをUE３に送信する。すなわち、RRC Connection Reconfigurationメッセージは、PDUセッション・スプリットの表示とSCG-Configurationを含む。PDUセッション・スプリットの表示は、SCG-Configuration内に包含されてもよい。ステップ２３０２及びステップ２４０２では、MN１は、RRC Connection Reconfiguration Complete メッセージをUE３から受信する。当該RRC Connection Reconfigurationメッセージは、MN１からSN２へスプリットされるMCG Split SRBを用いて、SN２を介して（i.e. SCGセルで）UE３に送信されてもよい。これに代えて、当該RRC Connection Reconfigurationメッセージに含まれる情報のうち、少なくともDCのためのSCG設定を実行するよう要求し且つPDUセッション・スプリットを示す情報を含むSCG RRC Connection Reconfigurationメッセージを、SN２がSCG SRBを用いてUE３に送信してもよい。

図２５は、UE３のNASレイヤ３１とAccess Stratum（AS）レイヤ３２のインタラクションの一例を示している。ASレイヤ３２は、既に確立済みのPDUセッションにPDUセッション・スプリットが適用されることを暗示的または明示的に示す情報を含むRRC Connection Reconfiguration メッセージ（図２４のステップ２４０１）をMN１から受信したなら、PDUセッション・スプリットが適用されることを示す表示（e.g., PDU Session Split Indication）及び対応するPDUセッション識別子（i.e., PDU Session ID）を上位レイヤ（i.e., NASレイヤ３１）に通知する（indicate to upper layer）。このとき、ASレイヤ３２は、QoSフロー識別子（i.e., QoS flow Indicator (QFI)）もNASレイヤ３１に通知してもよい。さらに又はこれに代えて、ASレイヤ３２は、既に確立済みのPDUセッションに属する１又はそれ以上のQoSフローがSCGのDRB（i.e., SCG bearer 又は SCG split bearer）に移されることを示す更新マッピング情報を上位レイヤ（i.e., NASレイヤ３１）に通知してもよい（indicate to upper layer）。これにより、NASレイヤ３１は、同一のPDUセッションに属する複数のQoSフローがMN１（MCG）及びSN２（SCG）にスプリットされていることを認識できる。

これに代えて、MR-DCにおいてPDUセッション・スプリットが暗示的に示される場合には、UE３のASレイヤ３２（e.g., SCG RATのRRCレイヤ）は、データ無線ベアラ（DRB）の確立、当該DRBに対応するQoSフロー識別子、及びPDUセッション識別子を上位レイヤ（UE NASレイヤ３１）に示してもよい。この場合、上位レイヤは、PDUセッション識別子が既にASレイヤ３２（e.g., MCG RATのRRCレイヤ）から示されたPDUセッション識別子と重複している（同一である）ことに基づき、PDUセッション・スプリットされていることを認識してもよい。例えば、UE３のNASレイヤ３１が開始した（トリガーした）PDUセッションの確立要求手順（PDU session establishment request procedure）では、NASレイヤ３１がPDU session IDを付与する。したがって、NASレイヤ３１は、自身が一方のセルグループ（CG）のRAT（e.g., MCG RAT）のASレイヤ３２に既に割り当てたのと同じPDU session IDが別のCGのRAT（e.g., SCG RAT）のASレイヤ３２から示された場合に、PDUセッション・スプリットされていることを認識することができる。

これに代えて、同一のRRC Connection Reconfiguration内のMCG-configuration及びSCG-configurationの各々がPDUセッション識別子を含んでもよい。この場合、UE３は、MCG-configuration内のPDUセッション識別子とSCG-configuration内のPDUセッション識別子とが重複している（同一である）ことに基づき、PDUセッション・スプリットされていることを認識してもよい。一例では、UE ASレイヤ３２がPDUセッション識別の重複に基づきPDUセッション・スプリットを認識し、その後当該PDUセッション識別子又はPDUセッション・スプリットされていることをUE NASレイヤ３１へ通知してもよい。これに代えて、UE NASレイヤ３１は、MCG-configuration内のPDUセッション識別子及びSCG-configuration内のPDUセッション識別子をUE ASレイヤ３２から受信し、これら２つのPDUセッション識別子に基づいてPDUセッション・スプリットされていることを認識してもよい。

ここで、PDUセッション識別子の代わりに、又はPDUセッション識別子と共に、当該PDUセッションに関連付けられたSDAPエンティティの識別子（e.g., SDAP Identity, or SDAPレイヤとPDCPレイヤの関連付けを示すService Channel Identity）が使用されてもよい。既に説明したように、Service Channel Identityは、SDAPエンティティと、それに接続される各PDCPエンティティとの間のService Access Point (SAP)として規定されてもよい。

＜第８の実施形態＞
本実施形態は、PDUセッション・スプリットを伴うNR-NR DCが実行されているときのUEモビリティに関する改良を提供する。本実施形態に係る無線通信ネットワークの構成例は、図９に示された例と同様である。

本実施形態では、以下に示す３つのモビリティシナリオを考える。

１．Change of SgNB
第１のモビリティ・シナリオは、Change of SgNB（又はSgNB Change）である。このシナリオは、3GPP Release 12（LTE-Advanced）のDCでのChange of SeNBシナリオに類似する。すなわち、Change of SgNB手順は、MgNB（i.e., MN１）によって開始され、UEコンテキスト（UE context）をソースSgNB（i.e., SN２）からターゲットSgNBに転送し且つUE内のSCG設定（SCG config）をあるSgNBにより生成（指定）された設定から他のSgNBにより生成（指定）される設定へ変更するために使用される。

MgNB（i.e., MN１）は、SgNB（又はSN）追加準備（addition preparation）手順を使用してターゲットSgNBにUE３のためのリソースを割り当てるよう要求することによってChange of SgNBを開始する。SgNB（又はSN）追加準備手順は、基本的に第５の実施形態（図２１及び２２）に示したとおりである。違いは、MgNBによってターゲットSgNBへ転送されるUEコンテキストが、ソースSgNBにより生成（指定）されたSCG設定を含む点である。SgNB（又はSN）追加準備手順を行なった後に、MgNB（i.e., MN１）は、DL TNL情報（DL TNLアドレス及びTEID）の更新をUPFエンティティ６に知らせるために、第１の実施形態で説明された既に確立済みのPDUセッションの修正要求（PDUセッション・スプリットの要否を示す）のメッセージをAMF/SMFエンティティ５に送ればよい。

２．MgNB to gNB Change
第２のモビリティ・シナリオは、MgNB to gNB Changeである。このシナリオは、3GPP Release 12（LTE-Advanced）のDCでのMeNB to eNB Changeシナリオに類似する。すなわち、MgNB to gNB Change手順は、ソースMgNB（i.e., MN１）及びソースSgNB（i.e., SN２）からターゲットgNBにコンテキストデータを転送するために使用される。

ソースMgNB（i.e., MN１）は、Xn Handover Preparation手順を開始することによって、MgNB to gNB Change手順を開始する。すなわち、ソースMgNB（i.e., MN１）は、Xn: HANDOVER REQUESTメッセージをターゲットgNBに送る。ソースMgNB（i.e., MN１）は、HANDOVER REQUESTメッセージ内のハンドオーバ準備情報（“HandoverPreparationInformation”IE）にSCGの設定情報（SCG configuration）を含める。当該SCGの設定情報は、PDUセッション識別子（i.e., PDU Session ID）、DRB識別子（i.e., DRB Identity）、及び１又はそれ以上のQoSフローの識別子（i.e., QFIs）の関連付けを示す。当該SCG設定は、PDUセッション・スプリットを明示的に示す情報（e.g., PDUセッション・タイプ情報又はDRBタイプ情報）を含んでもよい。

図２６は、Xn Handover Preparation手順で行われるシグナリングの一例を示すシーケンス図である。ステップ２６０１では、ソースMgNB（i.e., MN１）は、HANDOVER REQUESTメッセージをターゲットgNB８に送る。上述したように、当該HANDOVER REQUESTメッセージは、SCGの設定情報を含む。さらに、当該HANDOVER REQUESTメッセージは、PDUセッション・スプリットを明示的に示す情報（e.g., PDUセッション・タイプ情報又はDRBタイプ情報）を含んでもよい。当該タイプ情報は、SCGの設定情報に含まれてもよい。

３．Inter-MgNB handover without SgNB change
第３のモビリティ・シナリオは、Inter-MgNB handover without SgNB changeである。このシナリオは、3GPP Release 12（LTE-Advanced）のDCでのInter-MeNB handover without SeNB changeシナリオに類似する。すなわち、Inter-MgNB handover without SgNB change手順は、ハンドオーバ中にSgNBを追加するターゲットMgNBへソースMgNB（i.e., MN１）からコンテキストデータを転送するために使用される。

ソースMgNB（i.e., MN１）は、Xn Handover Preparation手順を開始することによって、Inter-MgNB handover without SgNB change手順を開始する。すなわち、ソースMgNB（i.e., MN１）は、Xn: HANDOVER REQUESTメッセージをターゲットMgNBに送る。ソースMgNB（i.e., MN１）は、HANDOVER REQUESTメッセージ内のハンドオーバ準備情報（“HandoverPreparationInformation”IE）にSCG設定（“SCG configuration”IE）を含める。さらに、ソースMgNB（i.e., MN１）は、HANDOVER REQUESTメッセージ内の“UE Context Reference at the SgNB”IE内に、SgNB UE XnAP ID and SgNB IDを含める。これらSgNB UE XnAP ID and SgNB IDは、SgNB（i.e., SN２）のXnインタフェースにおいてUE３に関するデータ及びシグナリングメッセージを識別するために使用される。

“SCG configuration”IE又は“UE Context Reference at the SgNB”IEは、PDUセッション・スプリットを明示的に示す情報（e.g., PDUセッション・タイプ情報又はDRBタイプ情報）を含んでもよい。図２６に示した例と同様に、ソースMgNB（i.e., MN１）は、HANDOVER REQUESTメッセージをターゲットMgNB８に送ってもよい。当該HANDOVER REQUESTメッセージは、“SCG configuration”IE及び“UE Context Reference at the SgNB”IEを含む。さらに、当該HANDOVER REQUESTメッセージは、PDUセッション・スプリットを明示的に示す情報（e.g., PDUセッション・タイプ情報又はDRBタイプ情報）を含んでもよい。当該タイプ情報は、“SCG configuration”IE又は“UE Context Reference at the SgNB”IEに含まれてもよい。

なお、MgNB to gNB Change手順では、ソースMgNB（i.e., MN１）へのNG-Uトンネル及びソースSgNB（i.e., SN２）へのNG-UトンネルをターゲットgNBへのNG-Uトンネルに変更するために、ターゲットgNBは、各PDU sessionのDL GTPトンネル（i.e., NG-U（又はN3）トンネル）のPath switchをAMF/SMFエンティティ５に要求し、AMF/SMFエンティティ５がNG-U（又はN3）Path Switch手順を実行する。さらに、Inter-MgNB handover without SgNB change手順でも、ソースMgNB（i.e., MN１）へのNG-UトンネルをターゲットMgNBへのNG-Uトンネルに変更するために、ターゲットgNBは、NG-U（又はN3）のPath switchをAMF/SMFエンティティ５に要求し、AMF/SMFエンティティ５がNG-U（又はN3） Path Switch手順を実行する。

NG-U（又はN3） Path Switch手順は、3GPP Release 12（LTE-Advanced）のDCでのS1 Path Switch手順に類似する。すなわち、図２７に示されるように、ターゲット(M)gNB８は、AMF/SMFエンティティ５にPATH SWITCH REQUESTメッセージを送る。当該PATH SWITCH REQUESTメッセージは、PDUセッション・スプリットを明示的に示すタイプ情報（e.g., PDUセッション・タイプ情報又はQoSフロー・タイプ情報）を含んでもよい。または、ターゲット(M)gNB８は、NG-U（又はN3）のPath Switchの要求を、１つのPDU sessionからスプリットされたNG-U（又はN3）毎に行ってもよい。

MgNB to gNB Change手順において当該タイプ情報を含むPATH SWITCH REQUESTメッセージを受信した場合、AMF/SMFエンティティ５は、PDUセッション・スプリットが適用されていたソースMgNB（i.e., MN１）へのNG-Uトンネル及びソースSgNB（i.e., SN２）へのNG-UトンネルをターゲットgNB８へのNG-Uトンネルに変更することを決定する。一方、Inter-MgNB handover without SgNB change手順において当該タイプ情報を含むPATH SWITCH REQUESTメッセージを受信した場合、AMF/SMFエンティティ５は、PDUセッション・スプリットが適用されていたソースMgNB（i.e., MN１）へのNG-UトンネルをターゲットMgNB８へのNG-Uトンネルに変更することを決定するとともに、ターゲットMgNB８へのNG-UトンネルにPDUセッション・スプリットが適用されることを認識する。

これに代えて、PATH SWITCH REQUEST メッセージは、ハンドオーバ前に確立されたPDU session及び当該PDU sessionのQoSフローとこれらに対応するRANノード（ソースMgNB１、SgNB２）との関係が維持されることを明示的に示す情報要素を含んでもよい。当該情報要素は、例えば、“relative PDU session mapping kept” IEであってもよい。言い換えると、AMF/SMFエンティティ５は、当該情報要素を受信することで、ソースMgNB１に確立されていたPDU session及び当該PDU sessionのQoSフローがターゲットMgNB８において確立されること、及びSgNB２に確立されたPDU session及び当該PDU sessionのQoSフローがそのままSgNB２に維持されることを認識することができる。

＜第９の実施形態＞
上述の複数の実施形態は、各々独立に実施されてもよいし、適宜組み合わせて実施されてもよい。例えば、既に説明したように、MN１は、第５の実施形態で説明されたSN ADDITIONプロシージャ又は第６の実施形態で説明されたSN MODIFICATIONプロシージャに従って、PDUセッション・スプリットが適用されるPDUセッションのためのリソース割り当てをSN２に要求してもよい。その後に、MN１は、第１の実施形態で説明されたように、既に確立済みのPDUセッションの修正要求をAMF/SMFエンティティ５に送信してもよい。

さらに又はこれに代えて、MN１は、AMF/SMFエンティティ５から新規QoSフローの追加を要求された場合に、当該新規QoSフローをMN１（MCG）のDRBへmappingするのではなく、当該新規QoSフローをSN２（SCG）のDRBへ直接的にmappingしてもよい。より具体的には、AMF/SMFエンティティ５は、UE３のために既に確立済みのPDUセッションへの新規QoSフローの追加を要求するためにNGAP: PDU SESSION RESOURCE MODIFY REQUESTメッセージをMN１に送信する。当該NGAPメッセージの受信に応答して、MN１は、第５の実施形態で説明されたSN ADDITIONプロシージャ又は第６の実施形態で説明されたSN MODIFICATIONプロシージャに従って、当該新規QoSフローのためのリソース割り当てをSN２に要求してもよい。SN２は、当該新規QoSフローのために新規SCGベアラを確立してもよいし、当該新規QoSフローを既存のSCGベアラにマップしてもよい。言い換えると、SN２は、当該新規QoSフローがマップされるSCGにベアラをSN２が決定してもよい。例えば、NR-NR DCでは、MN１又はSN２が新規QoSフローとSCGベアラのマッピングを決定し、MR-DCでは、SN２が当該マッピングを決定してもよい。SN ADDITIONプロシージャ又はSN MODIFICATIONプロシージャの後に、MN１は、第１の実施形態で説明された手順に従って、既に確立済みのPDUセッションの修正要求をAMF/SMFエンティティ５に送信してもよい。

続いて以下では、上述の複数の実施形態に係るMN１、SN２、UE３、及びAMF/SMFエンティティ５の構成例について説明する。図２８は、上述の実施形態に係るMN１の構成例を示すブロック図である。SN２の構成も図２８に示されたそれと同様であってもよい。図２８を参照すると、MN１は、Radio Frequencyトランシーバ２８０１、ネットワークインターフェース２８０３、プロセッサ２８０４、及びメモリ２８０５を含む。RFトランシーバ２８０１は、UE３を含むUEsと通信するためにアナログRF信号処理を行う。RFトランシーバ２８０１は、複数のトランシーバを含んでもよい。RFトランシーバ２８０１は、アンテナアレイ２８０２及びプロセッサ２８０４と結合される。RFトランシーバ２８０１は、変調シンボルデータをプロセッサ２８０４から受信し、送信RF信号を生成し、送信RF信号をアンテナアレイ２８０２に供給する。また、RFトランシーバ２８０１は、アンテナアレイ２８０２によって受信された受信RF信号に基づいてベースバンド受信信号を生成し、これをプロセッサ２８０４に供給する。

ネットワークインターフェース２８０３は、ネットワークノード（e.g., SN２、CPノード５、UPノード６）と通信するために使用される。ネットワークインターフェース２８０３は、例えば、IEEE 802.3 seriesに準拠したネットワークインターフェースカード（NIC）を含んでもよい。

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

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

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

図２９は、UE３の構成例を示すブロック図である。Radio Frequency（RF）トランシーバ２９０１は、MN１及びSN２と通信するためにアナログRF信号処理を行う。RFトランシーバ２９０１は、複数のトランシーバを含んでもよい。RFトランシーバ２９０１により行われるアナログRF信号処理は、周波数アップコンバージョン、周波数ダウンコンバージョン、及び増幅を含む。RFトランシーバ２９０１は、アンテナアレイ２９０２及びベースバンドプロセッサ２９０３と結合される。RFトランシーバ２９０１は、変調シンボルデータ（又はOFDMシンボルデータ）をベースバンドプロセッサ２９０３から受信し、送信RF信号を生成し、送信RF信号をアンテナアレイ２９０２に供給する。また、RFトランシーバ２９０１は、アンテナアレイ２９０２によって受信された受信ＲＦ信号に基づいてベースバンド受信信号を生成し、これをベースバンドプロセッサ２９０３に供給する。

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

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

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

アプリケーションプロセッサ２９０４は、CPU、MPU、マイクロプロセッサ、又はプロセッサコアとも呼ばれる。アプリケーションプロセッサ２９０４は、複数のプロセッサ（複数のプロセッサコア）を含んでもよい。アプリケーションプロセッサ２９０４は、メモリ２９０６又は図示されていないメモリから読み出されたシステムソフトウェアプログラム（Operating System（OS））及び様々なアプリケーションプログラム（e.g., 通話アプリケーション、WEBブラウザ、メーラ、カメラ操作アプリケーション、音楽再生アプリケーション）を実行することによって、UE３の各種機能を実現する。

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

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

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

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

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

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

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

図２８、図２９、及び図３０を用いて説明したように、上述の実施形態に係るMN１、SN２、UE３、及びAMF/SMFエンティティ５が有するプロセッサの各々は、図面を用いて説明されたアルゴリズムをコンピュータに行わせるための命令群を含む１又は複数のプログラムを実行する。このプログラムは、様々なタイプの非一時的なコンピュータ可読媒体（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）によってコンピュータに供給されてもよい。一時的なコンピュータ可読媒体の例は、電気信号、光信号、及び電磁波を含む。一時的なコンピュータ可読媒体は、電線及び光ファイバ等の有線通信路、又は無線通信路を介して、プログラムをコンピュータに供給できる。

＜その他の実施形態＞
上述の実施形態は、主にNR-NR DCの例に関して説明された。これらの実施形態に示された装置の構成および動作は、MR-DC with the 5GCのために使用されることができる。

上述の実施形態は、MN１とSN２間で送信される情報要素（e.g., SCG-Config）及びメッセージがLTE DCを想定した名称および構成を持つ例を提供した。しかしながら、NR-NR DCの情報要素及びメッセージの名称及び構成は、LTE DCのそれと同一でなくてもよい。例えば、SCG-Configに含まれる少なくとも一部の情報要素は、MN１とSN２間のXnインタフェースの情報要素として規定されてもよい。さらに、DCの形態（e.g., NR-NR DC, MR-DC with the 5GC（e.g., NG-EN-DC, NE-DC））によって、情報要素の名称及び構成が異なってもよい。例えば、NR-NR DCではMNとSNが共にNRのRRC protocolを使用するが、MR-DCではMN及びSNが互いに異なるRRC protocol（つまりLTEのRRC protocol及びNRのRRC protocol）を使用する。そのため、MR-DCでは、MNとSNがお互いにPDUセッション識別子、包含されるQoSフロー、及びDRB識別子の組み合わせを知っていればよいかもしれない。

上述の実施形態は、Dual Connectivityの例に関して説明された。しかしながら、Multi Connectivity（MC）において適用されてもよい。例えば、上述の実施形態は、１つのUEとの通信において、１つのMNに対して２つのSN（e.g., SN２－１及びSN２－２）が存在する場合、３つのN3トンネル（NG-Uトンネル）が１つのPDUセッションのために同時にサポートされる構成に適用されてもよい。言い換えると、１つのPDUセッションが、MN１、SN２－１、及びSN２－２へとスプリットされてもよい。これに代えて、１つのPDUセッションが、２つのSN２－１及びSN２－２へスプリットされてもよいし、MN１及び２つのSNのうちの１つ（SN２－１又はSN２－２）へスプリットされてもよい。このように、上述の実施形態は、MCにおいて、１つのPDUセッションが３以上のRAN nodes（i.e., MN及びSNs）へスプリットされる構成（つまり、１つのPDUセッションに対応する３以上のN3トンネル（NG-Uトンネル）が設定される構成）へ拡張されることが可能である。

上述の実施形態は、NR-NR DCまたはMR-DCの機能をサポートしているUE３がPDUセッション・スプリットの機能をサポートすることを前提としていた。しかしながら、NR-NR DCまたはMR-DCの機能をサポートするがPDUセッション・スプリットの機能をサポートしないUEが存在してもよい。例えば、PDUセッション・スプリットの（機能の）サポートを示す端末能力（e.g., PDU session split support, PDU-SessionTypeSplit）が規定されもよい。

PDUセッション・スプリットのサポートを示す端末能力は、UE ASレイヤの能力（UE AS Capability, e.g. UE radio access capability）であってもよいし、UE NASレイヤの能力（UE NAS Capability, e.g. UE network capability）であってもよい。当該端末能力がUE ASレイヤの能力である場合、UE３は当該端末能力を示す情報要素をRRCメッセージでMN１へ送信してもよい。一方、当該端末能力がUE NASレイヤの能力である場合、UE３は当該端末能力を示す情報要素をNASメッセージでAMF/SMFエンティティ５へ送信してもよい。

これに代えて、当該端末能力がUE NASレイヤの能力である場合、AMF/SMFエンティティ５がMN１に当該端末能力を通知してもよい。AMF/SMFエンティティ５からMN１への当該端末能力の通知は、UE単位で行われてもよい。

これに代えて、AMF/SMFエンティティ５は、UE３のためのPDUセッションにPDUセッション・スプリットが許可されるか否かを判定するために、当該UE３が当該端末能力を有するか否かを考慮してもよい。例えば、AMF/SMFエンティティ５は、PDUセッションの確立手順において、当該UE３又は加入者情報サーバ（e.g., Home Subscriber Server (HSS)）から当該端末能力を示す情報要素を受信してもよい。そして、AMF/SMFエンティティ５は、受信された情報要素を考慮して、当該UE３のためのPDUセッションに関してPDUセッション・スプリットが許可されるか否かを判定してもよい。言い換えると、AMF/SMFエンティティ５は、各UEの端末能力に基づいて、PDUセッション・スプリットを許可するか否かをUE単位で判定してもよい。

これにより、MN１またはAMF/SMFエンティティ５は、UE３のPDUセッション・スプリットの能力を考慮して、当該UE３のためのPDUセッションが確立（マップ）される１又はそれ以上のRANノードを適切に決定することができる。或いは、AMF/SMF AMF/SMFエンティティ５は、MN１からのPDUセッション・スプリットの要求を許可するか否かを適切に決定することができる。

上述の実施形態で説明されたMN１及びSN２は、Cloud Radio Access Network（C-RAN）コンセプトに基づいて実装されてもよい。C-RANは、Centralized RANと呼ばれることもある。したがって、上述の実施形態で説明されたMN１及びSN２の各々により行われる処理及び動作は、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）、又はTransmission and Reception Point（TRP）とも呼ばれる。すなわち、上述の実施形態で説明されたMN１及びSN２の各々によって行われる処理及び動作は、任意の１又は複数の無線局（又はRANノード）によって提供されてもよい。

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

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

１ マスターノード（MN）
２ セカンダリノード（SN）
３ User Equipment (UE)
４ コアネットワーク
５ コントロールプレーン（CP）ノード
６ ユーザプレーン（UP）ノード
７ RANノード
８ ターゲットgNB
２８０１ RFトランシーバ
２８０４ プロセッサ
２８０５ メモリ
２９０１ RFトランシーバ
２９０３ ベースバンドプロセッサ
２９０４ アプリケーションプロセッサ
２９０６ メモリ
３００２ プロセッサ
３００３ メモリ

Claims (10)

1. マスター無線アクセスネットワーク（RAN）ノードであって、
   メモリと、
   前記メモリに結合された少なくとも１つのプロセッサと、
   を備え、
   前記少なくとも１つのプロセッサは、
   無線端末とコアネットワーク内のUPF（User Plane Function）との間で確立されるPDUセッションのスプリットが許可されるか否か又はスプリットが可能か否かを示す第一の情報を含むPDU Session Resource Setup Requestメッセージを前記コアネットワーク内のAMF（Access and Mobility Management Function）から受信し、
   前記PDUセッションの修正を要求するPDU Session Resource Modify Indicationメッセージを前記コアネットワーク内の前記AMFに送るよう構成され、
   前記PDU Session Resource Modify Indicationメッセージは、前記PDUセッションを複数のトンネルにスプリットすることを前記コアネットワークに示すために用いられ、
   前記PDU Session Resource Modify Indicationメッセージは、前記PDUセッションのスプリットに対応づけられたQuality of Service（QoS）フローのリストを含む、
   マスターRANノード。
2. 前記第一の情報は、スプリットが許可されるか否か又はスプリットが可能か否かを示すPDUセッション単位又はQoSフロー単位の表示である、
   請求項１に記載のマスターRANノード。
3. 前記第一の情報は、前記PDUセッションのスプリットの許可又は不許可をネットワークスライス毎に示す、
   請求項１又は２に記載のマスターRANノード。
4. 前記マスターRANノードは、NextGen Radio Access Network（NG-RAN）ノードであり、前記コアネットワークは5Gコアネットワークである、
   請求項１～３のいずれか１項に記載のマスターRANノード。
5. 前記PDUセッションを複数のトンネルにスプリットすることは、当該PDUセッションに関連付けられた複数のQoSフローのうち１又はそれ以上のQoSフローを、前記コアネットワーク内のUPFと前記マスターRANノードの間の第１のトンネルから前記コアネットワーク内のUPFといずかのセカンダリRANノードの間の第２のトンネルに移動すること、又は、前記第２のトンネルから前記第１のトンネルに移動することを含む、
   請求項１～４のいずれか１項に記載のマスターRANノード。
6. コアネットワークに配置されるAMF（Access and Mobility Management Function）であって、
   メモリと、
   前記メモリに結合された少なくとも１つのプロセッサと、
   を備え、
   前記少なくとも１つのプロセッサは、
   無線端末と前記コアネットワーク内のUPF（User Plane Function）との間で確立されるPDUセッションのスプリットが許可されるか否か又はスプリットが可能か否かを示す第一の情報を含むPDU Session Resource Setup Requestメッセージをマスター無線アクセスネットワーク（RAN）ノードに送信し、
   前記PDUセッションの修正を要求するPDU Session Resource Modify Indicationメッセージを前記マスターRANノードから受信するよう構成され、
   前記PDU Session Resource Modify Indicationメッセージは、前記PDUセッションを複数のトンネルにスプリットすることを前記コアネットワークに示すために用いられ、
   前記PDU Session Resource Modify Indicationメッセージは、前記PDUセッションのスプリットに対応づけられたQuality of Service（QoS）フローのリストを含む、
   AMF。
7. 前記第一の情報は、スプリットが許可されるか否か又はスプリットが可能か否かを示すPDUセッション単位又はQoSフロー単位の表示である、
   請求項６に記載のAMF。
8. 前記コアネットワークは5Gコアネットワークである、
   請求項６又は７に記載のAMF。
9. マスター無線アクセスネットワーク（RAN）ノードにおける方法であって、
   無線端末とコアネットワーク内のUPF（User Plane Function）との間で確立されるPDUセッションのスプリットが許可されるか否か又はスプリットが可能か否かを示す第一の情報を含むPDU Session Resource Setup Requestメッセージを前記コアネットワーク内のAMF（Access and Mobility Management Function）から受信すること、及び
   前記PDUセッションの修正を要求するPDU Session Resource Modify Indicationメッセージを前記AMFに送ること、
   を備え、
   前記PDU Session Resource Modify Indicationメッセージは、前記PDUセッションを複数のトンネルにスプリットすることを前記コアネットワークに示すために用いられ、
   前記PDU Session Resource Modify Indicationメッセージは、前記PDUセッションのスプリットに対応づけられたQuality of Service（QoS）フローのリストを含む、
   方法。
10. コアネットワークに配置されるAMF（Access and Mobility Management Function）における方法であって、
    無線端末と前記コアネットワーク内のUPF（User Plane Function）との間で確立されるPDUセッションのスプリットが許可されるか否か又はスプリットが可能か否かを示す第一の情報を含むPDU Session Resource Setup Requestメッセージをマスター無線アクセスネットワーク（RAN）ノードに送信すること、及び
    前記PDUセッションの修正を要求するPDU Session Resource Modify Indicationメッセージを前記マスターRANノードから受信すること、
    を備え、
    前記PDU Session Resource Modify Indicationメッセージは、前記PDUセッションを複数のトンネルにスプリットすることを前記コアネットワークに示すために用いられ、
    前記PDU Session Resource Modify Indicationメッセージは、前記PDUセッションのスプリットに対応づけられたQuality of Service（QoS）フローのリストを含む、
    方法。

Images