WO2018029931A1 - 無線アクセスネットワークノード、無線端末、コアネットワークノード、及びこれらの方法 - Google Patents

無線アクセスネットワークノード、無線端末、コアネットワークノード、及びこれらの方法 Download PDF

Info

Publication number
WO2018029931A1
WO2018029931A1 PCT/JP2017/018227 JP2017018227W WO2018029931A1 WO 2018029931 A1 WO2018029931 A1 WO 2018029931A1 JP 2017018227 W JP2017018227 W JP 2017018227W WO 2018029931 A1 WO2018029931 A1 WO 2018029931A1
Authority
WO
WIPO (PCT)
Prior art keywords
network
information
handover
slice
wireless terminal
Prior art date
Application number
PCT/JP2017/018227
Other languages
English (en)
French (fr)
Inventor
尚 二木
林　貞福
Original Assignee
日本電気株式会社
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 日本電気株式会社 filed Critical 日本電気株式会社
Priority to EP17839006.8A priority Critical patent/EP3499964B1/en
Priority to EP20205291.6A priority patent/EP3796713A1/en
Priority to US16/321,998 priority patent/US11910258B2/en
Priority to CN201780048078.2A priority patent/CN109565732B/zh
Priority to JP2018533427A priority patent/JP6642720B2/ja
Priority to EP21198971.0A priority patent/EP3958615A1/en
Publication of WO2018029931A1 publication Critical patent/WO2018029931A1/ja
Priority to US17/385,428 priority patent/US11765636B2/en
Priority to US18/225,421 priority patent/US20230370928A1/en

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W36/00—Hand-off or reselection arrangements
    • H04W36/14—Reselecting a network or an air interface
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W36/00—Hand-off or reselection arrangements
    • H04W36/0005—Control or signalling for completing the hand-off
    • H04W36/0011—Control or signalling for completing the hand-off for data sessions of end-to-end connection
    • H04W36/0033—Control or signalling for completing the hand-off for data sessions of end-to-end connection with transfer of context information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W36/00—Hand-off or reselection arrangements
    • H04W36/13—Cell handover without a predetermined boundary, e.g. virtual cells
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W36/00—Hand-off or reselection arrangements
    • H04W36/14—Reselecting a network or an air interface
    • H04W36/144—Reselecting a network or an air interface over a different radio air interface technology
    • H04W36/1443—Reselecting a network or an air interface over a different radio air interface technology between licensed networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W36/00—Hand-off or reselection arrangements
    • H04W36/0005—Control or signalling for completing the hand-off
    • H04W36/0011—Control or signalling for completing the hand-off for data sessions of end-to-end connection
    • H04W36/0033—Control or signalling for completing the hand-off for data sessions of end-to-end connection with transfer of context information
    • H04W36/0038—Control or signalling for completing the hand-off for data sessions of end-to-end connection with transfer of context information of security context information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W92/00—Interfaces specially adapted for wireless communication networks
    • H04W92/16—Interfaces between hierarchically similar devices
    • H04W92/20—Interfaces between hierarchically similar devices between access points

Definitions

  • This disclosure relates to wireless communication systems, and more particularly to handover of wireless terminals between different Radio Access Technologies (RATs).
  • RATs Radio Access Technologies
  • 5G 5th generation mobile communication system
  • 5G is a combination of LTE and LTE-Advanced continuous enhancement / evolution and the introduction of a new 5G air interface (new Radio Access Technology (RAT)).
  • the new RAT is, for example, a frequency band higher than the frequency band (eg, 6 GHz or less) targeted for the continuous development of LTE / LTE-Advanced, such as a centimeter wave band of 10 GHz or more and a millimeter band of 30 GHz or more. Support waveband.
  • the fifth generation mobile communication system is also called Next Generation (NextGen) System (NG System).
  • the new RAT for NG System is called New Radio (NR), 5G RAT, or NG RAT.
  • the new radio access network (Radio Access Network (RAN)) and core network for NG System are called NextGen RAN (NG RAN) and NextGen Core (NG Core), respectively.
  • a wireless terminal (User Equipment (UE)) connected to the NG System is called NextGen UE (NG UE).
  • Formal names such as RAT, UE, radio access network, core network, network entity (node), and protocol layer for NG System will be determined in the future as standardization works.
  • LTE Long Term Evolution
  • LTE-Advanced Pro LTE +, or enhanced LTE (eLTE).
  • EPC Evolved Packet Core
  • MME Mobility Management Entity
  • S-GW Serving Gateway
  • PDN Packet Data Network
  • P-GW Packet Data Network Gateway
  • the bearer for each QoS class and PDN connection is RAN (ie, Evolved, Universal, Terrestrial, RAN) and core network (ie, Evolved, Packet, core (EPC). )) Both used.
  • RAN ie, Evolved, Universal, Terrestrial, RAN
  • EPC Evolved, Packet, core
  • EPS Evolved Packet System
  • one or more Evolved Packet System (EPS) bearers are set between the UE and the P-GW in the EPC, and there are multiple QoS classes Service data flows (Service Data Flows (SDFs)) are transferred through one EPS Bearer that satisfies these QoS.
  • SDFs Service Data Flows
  • the SDF is one or a plurality of packet flows that match an SDF template (i.e., “packet” filters) based on a Policy “and” Charging “Control” (PCC) rule. Also, for packet routing, each packet sent through EPS bearer identifies which bearer (ie, General Packet Radio Service (GPRS) Tunneling Protocol (GTP) tunnel) this packet is associated with (identify ) For information.
  • GPRS General Packet Radio Service
  • GTP General Packet Radio Service Tunneling Protocol
  • a radio bearer may be used in NG RAN ⁇ , but it is considered that no bearer is used in the interface between NG Core and NG Core and NG RAN (non-patent document). 1).
  • PDU flows are defined instead of EPS bearer, and one or more SDFs are mapped to one or more PDU flows.
  • the PDU flow between the NG UE and the user plane termination entity in NG Core i.e., entity corresponding to P-GW in EPC
  • the NG System adopts the Flow-based QoS (or per-flow QoS) concept instead of the Bearer-based QoS concept.
  • QoS is handled in units of PDU “flow”.
  • the association between the UE and the data network is called a PDU session (PDU (session).
  • PDU session is a term corresponding to a PDN connection (PDN connection) of LTE and LTE-Advanced. Multiple PDU flows can be set in one PDU session.
  • an end-to-end bearer (eg, EPS bearer) is set between the UE and an edge node (eg, ⁇ ⁇ P-GW) in the core network
  • an edge node eg, ⁇ ⁇ P-GW
  • a system that adopts the Bearer-based QoS concept is called “bearer-based” system or “bearer-based” network.
  • a system that uses a flow-based QoS concept without using a bearer in the core network and the core network and RAN interface, such as NG System is called “bearer-less system” or “bearer-less network”.
  • a radio bearer may be used in a bearer-less RAN.
  • bearer-less is, for example, GTP-less, (PDN) connection-less, tunnel-less, (IP) flow-based, SDF-based, stream-based, or (PDU) session-based.
  • PDN GTP-less
  • IP tunnel-less
  • SDF SDF-based
  • PDU stream-based session-based.
  • the NG System may function as a bearer-based system, and may support both flow-based transfer and bearer-based transfer of user data.
  • NG System supports network slicing (see Non-Patent Document 1).
  • Network slicing uses Network Function Virtualization (NFV) technology and software-defined networking (SDN) technology to enable the creation of multiple virtualized logical networks on top of a physical network.
  • Each virtualized logical network called a network slice or network slice instance, contains logical nodes and functions, and includes specific traffic. And used for signaling.
  • NG RAN or NG Core or both have Slice Selection Function (SSF).
  • SSF Slice Selection Function
  • the SSF selects one or a plurality of network slices suitable for the NG UE based on information provided by at least one of the NG UE and the NG UE.
  • Patent Document 1 discloses a handover from bearer-less network (eg, 5G) to bearer-based network (eg, LTE), and bearer-based network (eg, LTE) to bearer-less network (eg, 5G). Disclosures related to handover to.
  • the source control node ie, Access Access Control Server (ACS) / eMME
  • NG Core 5G core
  • the QoS parameters of 5G service flows are, for example, DiffServ code points (DSCP) values.
  • DSCP DiffServ code points
  • the LTE EPS-bearer-level QoS is, for example, QoS class identifier (QCI) and allocation and retention priority (ARP).
  • QCI QoS class identifier
  • ARP allocation and retention priority
  • the mapping of DSCP values to EPS bearers may be done one to one or n to one.
  • Source ACS / eMME sends APN information including EPS-bearer-level QoS information to target MME.
  • the Target MME sets up GTP tunnels for the UE according to the received APN information.
  • the source MME of the LTE core ie, EPC
  • the target GACS of the 5G core NG Core
  • Target ACS / eMME maps QCI values obtained from LTE (ie, source MME) to 5G QoS parameters (ie, DSCP values), and forwards them to 5G core (NG Core) forwarding nodes (ie, Mobility, Gateway Access Router (M-GW / AR) or Mobility Gateway Edge Router (M-GW / ER)).
  • NG Core 5G core
  • the Target ACS / eMME sets up at least one Generic Routing Encapsulation (GRE) tunnel for sending service flows (i.e., IP packets) of the UE.
  • GRE Generic Routing Encapsulation
  • FIG. 4 of Patent Document 1 describes that a handover procedure from NG System (5G) to LTE System is realized by modification of LTE S1-based handover.
  • Patent Document 1 does not describe that the handover procedure between the NG System (5G) and the LTE System includes the transfer of a handover signaling message on the interface between direct base stations.
  • one of the objectives to be achieved by the embodiments disclosed herein is an apparatus that contributes to providing an Inter-RAT handover procedure involving the transfer of a handover signaling message over a direct base station interface, A method and program are provided. It should be noted that this object is only one of the objects that the embodiments disclosed herein intend to achieve. Other objects or problems and novel features will become apparent from the description of the present specification or the accompanying drawings.
  • a target radio access network (RAN) node associated with the second network includes at least one memory and at least one processor coupled to the at least one memory.
  • the at least one processor receives a handover request message requesting a handover of a wireless terminal from a first network to the second network from a source RAN node in the first network on a direct interface;
  • at least one of slice information and flow information is received from the core network, and communication of the wireless terminal is controlled based on at least one of the slice information and flow information Composed.
  • the slice information relates to a network slice in the second network to which the wireless terminal is connected.
  • the flow information relates to at least one session established in the second network as a bearerless network to transfer at least one packet flow of the wireless terminal.
  • a source radio access network (RAN) node associated with the first network includes at least one memory and at least one processor coupled to the at least one memory.
  • the at least one processor is configured to determine a handover of a wireless terminal from the first network to a second network, and in response to the handover determination, the handover of the wireless terminal to the second network Is sent to the target RAN node in the second network over the direct interface.
  • the at least one processor is further configured to receive a handover request acknowledge message including a transparent container from the target RAN node on the direct interface, including the transparent container and to the second network.
  • a mobility command message indicating the handover of the wireless terminal is transmitted to the wireless terminal.
  • the transparent container contains radio resource setting information necessary for the radio terminal to establish a radio connection associated with the second network.
  • the radio resource setting information includes: (a) first radio resource setting information generated based on slice information related to a network slice in the second network to which the radio terminal is connected; and (b) the radio terminal At least one of second radio resource configuration information generated based on flow information regarding at least one session established in the second network as a bearerless network to transfer at least one packet flow including.
  • the wireless terminal includes at least one memory and at least one processor coupled to the at least one memory.
  • the at least one processor is configured to transfer slice information regarding a network slice in the second network and a network slice in the second network.
  • a message related to handover including at least one of the based radio resource configuration information is configured to be received from a radio access network (RAN) node of the first network.
  • RAN radio access network
  • the core network node includes at least one memory and at least one processor coupled to the at least one memory.
  • the at least one processor transmits slice information regarding a network slice in the second network to which the wireless terminal is connected to the second network. It is configured to send to an associated target radio access network (RAN) node.
  • RAN radio access network
  • a method at a target radio access network (RAN) node associated with a second network is: Receiving a handover request message requesting a handover of a wireless terminal from a first network to the second network from a source RAN node in the first network on a direct interface; In response to receiving the handover request message, receiving at least one of slice information and flow information from a core network, and communication of the wireless terminal based on at least one of the slice information and flow information To control, including.
  • the slice information relates to a network slice in the second network to which the wireless terminal is connected.
  • the flow information relates to at least one session established in the second network as a bearerless network to transfer at least one packet flow of the wireless terminal.
  • a method at a source radio access network (RAN) node associated with a first network is: Determining a handover of a wireless terminal from the first network to a second network; In response to the handover decision, sending a handover request message requesting handover of a wireless terminal to the second network over a direct interface to a target RAN node in the second network; receiving a handover request acknowledge message including a transparent container from the target RAN node on the direct interface; and a mobility command message including the transparent container and indicating a handover to the second network. Sending it to your device, including.
  • the transparent container includes radio resource setting information necessary for the radio terminal to establish a radio connection associated with the second network.
  • the radio resource setting information includes: (a) first radio resource setting information generated based on slice information related to a network slice in the second network to which the radio terminal is connected; and (b) the radio terminal At least one of second radio resource configuration information generated based on flow information regarding at least one session established in the second network as a bearerless network to transfer at least one packet flow including.
  • the program includes a group of instructions (software code) for causing the computer to perform the method according to the above aspect when read by the computer.
  • FIG. 10 is a sequence diagram showing an example of an inter-RAT handover procedure from NG System to LTE System, according to the third embodiment.
  • FIG. 10 is a sequence diagram showing an example of an inter-RAT handover procedure from NG System to LTE System, according to the third embodiment.
  • FIG. 10 is a sequence diagram showing an example of an inter-RAT handover procedure from NG System to LTE System, according to the third embodiment.
  • FIG. 10 is a sequence diagram showing an example of an inter-RAT handover procedure from NG System to LTE System, according to the third embodiment.
  • FIG. 10 is a sequence diagram showing an example of an inter-RAT handover procedure from NG System to LTE System, according to the third embodiment.
  • 10 is a sequence diagram showing an example of an inter-RAT handover procedure from NG System to LTE System, according to the third embodiment. It is a figure which shows the structural example of the radio
  • the plurality of embodiments described below can be implemented independently or in appropriate combinations.
  • the plurality of embodiments have different novel features. Therefore, these multiple embodiments contribute to solving different purposes or problems and contribute to producing different effects.
  • FIG. 1 shows a configuration example of a wireless communication network according to some embodiments including this embodiment.
  • the wireless communication network includes a wireless terminal (UE) 1, an LTE base station (ie, eNB) 2, a New Radio (NR) base station (ie, NR NodeB (NR NB)) 3, and NextGen ( NG) Includes Core5.
  • LTE eNB2 is connected to NG Core5. That is, LTE eNB2 is connected to a control node (ie, Control Plane Function (CPF) node) having at least a part of the functions of MME or MME in NG Core 5 via a control plane interface (eg, NG2 interface).
  • CPF Control Plane Function
  • LTE eNB2 is improved (enhanced) so that it may be connected with NG Core5, and may be called eLTE eNB.
  • the NR NB 3 may be connected to one or more CPF nodes in the NG Core 5 via a control plane interface (e.g., NG2 interface). Further, the NR NB 3 may be connected to one or a plurality of UPF nodes in the NG5Core 5 through a user plane interface (e.g., NG3 interface). Further, UE1 may be connected to one or more CPF nodes in NG Core 5 via a control plane interface (e.g., NG1 interface).
  • the NG1 interface is defined as a logical interface for transferring NAS layer information, and the NAS layer information is transmitted via the NG2 interface and the radio interface (NG ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ Uu) between NR NB3 and UE1. It may be done.
  • NG Core 5 may set up virtualized network slices that provide logical EPC nodes and EPC functions.
  • E-UTRAN including LTE eNB 2 and NG RAN including NR NB 3 may be connected to the same network slice. Instead of this, the E-UTRAN including LTE eNB2 and the NG RAN including NR NB3 may be connected to different network slices.
  • UE1 has the ability to connect to the LTE system provided by LTE
  • NG NextGen
  • the LTE eNB 2 is connected to the NR NB 3 via the direct base station interface 101.
  • the direct inter-base station interface 101 is called an X3 interface, for example.
  • the direct inter-base station interface 101 is used for transferring a signaling message at least between LTE eNB2 and NR NB3.
  • the direct inter-base station interface 101 may be further used for user packet transfer between LTELeNB2 and NR NB3.
  • the control plane protocol structure and user plane protocol structure of the direct inter-base station interface 101 may be the same as those of the X2 interface between LTE and eNB, for example.
  • NG System may include other interfaces in addition to the above NG1, NG2, and NG3 interfaces. The interface is also called a reference point. Between NG and RAN (between different NR and NB) may be connected via an NX2 interface.
  • a CPF node that has one or both of mobility management function (Mobility Management Function: MMF) and session management function (Session Management Function: SMF) is connected to UPF node via control plane interface (eg, NG4 interface). May be.
  • MMF Mobility Management Function
  • SMF Session Management Function
  • UPF node via control plane interface (eg, NG4 interface). May be.
  • Different UPF nodes may be connected via a user plane interface (e.g., NG9 interface).
  • CPF nodes having different functions may be connected via a control plane interface.
  • a CPF node having an MMF and an SMF may be connected to a CPF node having a policy control function (Policy Control Function: PCF) via a control plane interface (e.g., NG7 interface).
  • Policy Control Function Policy Control Function
  • a CPF node having MMF and SMF may be connected to a node having a subscriber data management function (Subscriber Data Management: SDM) via a control plane interface (e.g., NG8 interface).
  • SDM Subscriber Data Management
  • the CPF node may be connected to a node having an application function (Application Function: AF) via a control plane interface (e.g., NG5 interface).
  • Application Function Application Function
  • the UPF node may be connected to an external or local data network (Data Network: DN) via a user plane interface (e.g., ⁇ ⁇ ⁇ NG6 interface).
  • the SMF may include functions for user or terminal authentication and for authorization of services or network slicing. It should be noted that each of the above-described network nodes is referred to as a network function (Network Function (s): NF (s)).
  • the NG System supports data transfer based on the Flow-based QoS (or per-flow QoS) concept described above.
  • the NG System including the NR NB3 and the NG Core5 may be further configured to support bearer-based transfer using a bearer for each QoS class and for each PDU session.
  • An NG System bearer is set between a pair of network functions (Network Functions (NFs)), for example, between user plane functions in NR NB 3 and NG Core 5 or between two user plane functions in NG Core 5. May be.
  • NFs Network Functions
  • the NG System bearer may be set between the UE1 and the user plane function in the NG Core 5 via the NR NB3.
  • the NG System bearer may be called NG-EPS-bearer, and the NG System radio access bearer may be called NG-RAB.
  • An NG System bearer can be used to transfer multiple packet flows (PDU flows).
  • NG-RAB is set between the radio bearer set between UE1 (NG UE) and NR NB3, and the user plane function (eg, Edge Gateway (Edge GW)) in NR NB3 and NG Core5. It may be composed of a bearer (eg, NG3 bearer).
  • NG-EPS-bearer is a core network bearer (eg, NG9 bearer) set between NG-RAB and the user plane function in NG Core5 (between eg, Edge GW and Data Network Gateway (DN GW)).
  • Edge GW is a gateway to the radio access network and corresponds to the user plane function of LTE S-GW.
  • UE1 may be connected to multiple Edge GWs in NG System.
  • DN GW is a gateway to an external network (i.e., Data Network), and corresponds to the user plane function of LTE P-GW.
  • UE1 may be connected to a plurality of DN GWs in the NGLSystem.
  • NG-EPS-bearer may be set between UE1 (NG UE) and slice specific user plane function (Slice specific User Plane NF (SUNF)) in NG Core 5.
  • NG-RAB may be set between UE1 (NG
  • CUNF provides the Edge GW function
  • SUNF provides the DN ⁇ GW function.
  • the CUNF may associate the NG-RAB and the core network bearer (e.g., NG9 bearer). That is, the NG-EPS-bearer may be configured by an NG-RAB between UE1 (NG UE) and CUNF and a core network bearer (e.g., NG9 bearer) between CUNF and SUNF.
  • NG9 bearer e.g., NG9 bearer
  • the NG System that supports bearer-based transfer may be further configured to specify a data flow (PDU flow) in the bearer for QoS handling (e.g., packet discard) for each data flow (PDU flow).
  • PDU flow data flow
  • the NR NB3 associates a bearer (eg, NG3 bearer) set between the user plane function in the NR NB3 and the NG Core5 with the radio bearer, and between the bearer (eg, NG3 bearer) and the radio bearer. Packet forwarding may be performed, and QoS handling (eg, packet discard) may be performed for each data flow (PDU flow) in the bearer.
  • E When LTE eNB2 is connected to NG Core 5 via the NG2 interface, the radio access bearer equivalent to LTE EPS Radio Access Bearer (E-RAB) is defined as NG EPS EPS Radio Access Bearer (NE-RAB)
  • the bearer corresponding to the EPS EPS bearer of LTE may be defined as NG EPS EPS bearer (NEPS bearer).
  • NE-RAB is a bearer (eg, NG3) set between a radio bearer set between UE1 and LTE eNB2 and a user plane function (eg, Edge GW or CUNF) in LTE eNB2 and NG Core5. Bearer).
  • NEPS bearer is a core network bearer (eg, NG9 bearer) set between NE-RAB and user plane functions in NG Core5 (eg, between Edge GW and DN GW, or between CUNF and SUNF). ).
  • the LTE eNB2 connected to the NG System may be configured to specify the data flow (PDU flow) in the NE-RAB for QoS handling (e.g., packet discard) for each data flow (PDU flow).
  • QoS handling e.g., packet discard
  • eNB2 associates the bearer (eg, NG3 bearer) set between the user plane function in LTE eNB2 and NG Core5 with the radio bearer, and between the bearer (eg, NG3 bearer) and the radio bearer Packet forwarding may be performed, and QoS handling (eg, packet discard) may be performed for each data flow (PDU flow) in the bearer.
  • the bearer eg, NG3 bearer
  • Packet forwarding may be performed, and QoS handling (eg, packet discard) may be performed for each data flow (PDU flow) in the bearer.
  • This embodiment provides a handover method of UE1 from LTE System that does not support network slicing to NG System that supports network slicing.
  • 2A and 2B show an example of a handover procedure of UE1 from LTE System to NG System in the configuration example of the wireless communication network shown in FIG.
  • FIG. 2A shows a handover preparation phase and an execution phase
  • FIG. 2B shows a handover completion phase.
  • the procedure shown in FIG. 2A and FIG. 2B involves the transfer of the handover signaling message on the direct inter-base station interface 101 during the handover preparation phase (ie, steps 202 and 203). Similar to “based handover”. However, if only the transfer of the handover signaling message on the direct base station interface 101 is performed, information necessary for relocation of the UE 1 from the LTE system to the NG system is insufficient in the NG RAN. Therefore, in the procedure shown in FIG. 2A and FIG. 2B, signaling (ie, step) between the NR NB3 and the NG Core5 in order to obtain information necessary for the relocation of the UE1 from the LTE system to the NG system. 207, 209, and 210), the handover completion phase has been improved.
  • UE1 is connected to LTE eNB2 and is in a connected state (i.e., RRC_Connected).
  • UE1 receives the measurement configuration (Measurement Configuration) from LTE eNB2, and according to the measurement configuration, neighbor cell measurement (neighbor cell measurement) including E-UTRAN (LTE) cells and NG-RAN cells and radio access technology (Radio Access) Technology) Measurement (inter-RAT measurements) is executed, and a measurement report (measurement report) is sent to LTE eNB2.
  • the measurement setting is included in an RRCRRConnection Reconfiguration message transmitted from the E-UTRAN to the UE, for example.
  • LTE eNB2 determines inter-RAT handover to the cell of NR NB3. In response to the determination of the Inter-RAT handover, LTE eNB2 sends an NR Handover Request message to the target NR NB3 on the direct inter-base station interface 101 (e.g., X3 interface).
  • the direct inter-base station interface 101 e.g., X3 interface
  • the NR Handover Request message in step 202 may include a handover type information element (Handover Type Information Element (IE)) indicating a handover from LTE to NR.
  • IE Handover Type Information Element
  • LTEtoNR is set in Handover Type IE.
  • the NR Handover Request message in Step 202 may include an “NG EPS EPS Radio Access Bearers (NE-RABs) To To Be Setup List information element (IE).
  • NE-RABs To Be Setup List IE is the identifier (ie, RA NE-RAB ID) and QoS parameters (eg, QoS class identifier (QCI), Allocation and retention priority (ARP) for UE1. , Guaranteed Bit Rate (GBR) QoS information).
  • NextGen E-RAB (NE-RAB) communicates with UE1 and User plane Function (eg, Common User plane NF (CUNF)) in UE1 and NG Core5 via eLTE eNB extended to support the interface with NG Core. E-RAB set up in between.
  • CUNF Common User plane NF
  • the NR Handover Request message in step 202 may include a “Handover Preparation Information Information to NR” information element (Information Element (IE)).
  • the “Handover Preparation Information To NR” IE may include support information (assistance information) for facilitating mapping between EPS bearers and packet flows (e.g., PDU flows or SDFs) for UE1.
  • the support information may indicate an identifier or packet filter (e.g., SDF templates, or TFTs) of one or more SDFs mapped to each EPS bearer.
  • the support information may be sent from UE1 to LTE eNB2 by RRC message. Further, the support information may be transmitted as an information element (IE) including parameters of the RRC layer, or may be transmitted as an IE of the RRC layer including information of the NAS layer (eg, NAS Info IE). Good.
  • IE information element
  • the “Handover Preparation Information to NR” IE may include security-related information.
  • Security-related information includes security parameters used by the target NR NB3 for derivation of Access Stratum (AS) security keys.
  • the security parameter is a base key for deriving a security key (temporary key) used by the AS layer (ie, a key equivalent to LTE K eNB ), or a parameter for deriving the base key (Eg, ⁇ NH, NCC ⁇ pair).
  • the security parameter may further include UE security capabilities related to NG RAT or NG System.
  • UE security capabilities indicates a ciphering and integrity protection algorithm (algorithms) implemented in UE1.
  • the source LTE eNB2 may derive K eNB * from an unused ⁇ NH, NCC ⁇ pair and send the ⁇ K eNB *, NCC ⁇ pair to the target NR NB3. .
  • Next Hop parameter (NH) and Next Hop Chaining Counter parameter (NCC) are used to derive K eNB according to the vertical key derivation algorithm for the next hop.
  • the source LTE eNB2 may derive K eNB * from the current K eNB according to a horizontal key derivation algorithm and send a ⁇ K eNB *, NCC ⁇ pair to the target NR NB3.
  • the source LTE eNB2 may send an unused ⁇ NH, NCC ⁇ pair to the target NR NB3.
  • the target NR NB3 according vertical key derivation (vertical key derivation) algorithm, unused ⁇ NH, NCC ⁇ received base key from the pair (ie, the key corresponding to the LTE K eNB) and AS keys May be derived.
  • the NR Handover Request message in Step 202 may include assistance information (Assistance Data for Network Slicing) for network slicing.
  • “Assistance Data for Network Slicing” IE includes network slice support information (network slice assistance information) that is support information for facilitating network slicing.
  • the network slice support information may indicate, for example, the type of UE1, the service desired by UE1, or the allowable latency of UE1, or any combination thereof. Instead of this, part or all of the network slice support information may be included in the handover preparation information (or other information elements) of the RRC container (RRC Context IE).
  • the network slice support information () may be generated by an EPC network slice instance in UE1, LTELeNB2, or NG Core5.
  • UE1 may send network slice support information to LTE eNB2 in step 201.
  • the network slice support information may be an information element (IE) indicating an RRC layer parameter or NAS information (NAS (information IE), and this is included in a measurement report (measurement report) sent from UE1 to LTE eNB2. Also good.
  • IE information element
  • NAS information IE
  • the target NR NB3 creates (creates) a UE context based on the NR Handover Request message and allocates resources.
  • the target NR NB3 may determine allowed E-RABs based on the received “E-RABs To Be Setup List” IE.
  • the target NR NB3 has a flow identifier (eg, PDU flow ID) corresponding to each allowed E-RAB, endpoint information of the target NR NB3 for delivery of uplink (UL) PDUs, and downlink (DL) You may determine the endpoint information of target NR
  • the endpoint information of the target NR NB3 for delivery of UL PDUs may be, for example, UL GTP Tunnel Endpoint Identifier (TEID), UL endpoint ID or Internet Protocol (IP) address, or both. .
  • the endpoint information of the target NR NB3 for delivery of DL PDUs may be DL GTP TEID, DL endpoint ID or IP address, or both. Endpoint information for delivery of UL PDUs and DL PDUs is used for UL data forwarding and DL data forwarding, respectively.
  • the target NR NB3 may operate as follows.
  • the security related information includes security parameters for AS security.
  • the target NR NB3 may select an AS security algorithm based on UE security capabilities included in the security parameter.
  • the AS security algorithm includes a ciphering algorithm for Radio Resource Control (RRC) and user plane (UP), and an integrity protection algorithm for RRC.
  • RRC Radio Resource Control
  • UP user plane
  • RRC integrity protection algorithm
  • the target NR NB3 uses RRC ciphering (encryption), UP ciphering (encryption), and temporary keys for RRC integrity protection as a base key (from the security parameters) using the selected security algorithm. ie, a key corresponding to LTE K eNB ).
  • Target NR NB3 generates Target To Source Transparent Container sent to UE1.
  • the Target To Source Transparent Container includes, for example, RRC: HandoverCommand message (Handover Command To NR) including RRCConnectionRecofiguration message and other RRC messages.
  • the target NR NB3 generates a confirmation response (Handover Request Acknowledge) message to the handover request including the Target To Source Transparent Container.
  • the target NR NB3 sends an NR Handover Request Acknowledge message to the source LTE eNB2 over the direct inter-base station interface 101 (e.g., X3 interface).
  • Target To Source Transparent Container includes, for example, radio resource setting information (e.g., radio parameters) set up by the target NR NB3, AS security algorithm identifiers (identifiers) selected by the target NRNCNB3, and an NCC value.
  • the NR Handover Request Acknowledge message may further include the “NE-RABs Admitted list” information element (IE) described above.
  • eNB2 starts the data forwarding for the bearer or flow (PDU
  • the source LTE eNB2 sends a Radio Resource Control (RRC) message including a Handover Command message including the transparent container generated by the target NRNB3 to the UE1.
  • RRC Radio Resource Control
  • the RRC message may be, for example, a Mobility from EUTRA command message or an RRC Connection Reconfiguration message.
  • step 205 UE1 moves to the target RAN (ie, NG RAN) in response to the reception of the RRC message including the Handover Command message, and transparent container (eg, radio resource setting information supplied in the Handover Command message). , AS security algorithm, and NCC value). That is, UE1 establishes a radio connection with target NR NB3 associated with bearer-less network (i.e., NG System).
  • step 206 UE1 sends a Handover Confirm for NR message to the target NR NB3 after successfully synchronizing to the target cell.
  • the message of step 206 may be an NR RRC Connection Reconfiguration Complete message.
  • step 207 when UE1 successfully accesses target NR NB3, target NR NB3 reports NR Path Switch Request message to notify UE1 that the cell has been changed and to request a path switch. Send to Core5.
  • the NR Path Switch Request message may include a path switch type information element (Path Switch Type IE) indicating a path switch from LTE to NR. For example, “LTEtoNR” is set in Path Switch Type IE.
  • the NR Path Switch Request message may include a list of EPS bearers of UE1 that has been switched to the target NR NB3 cell.
  • the control node e.g., CPF in NG Core 5 performs a bearerless session creation procedure. Specifically, the control node determines that the packet forwarding node (gateway) for UE1 needs to be relocated, and the target forwarding node (gateway) for NG System in NG Core5 Select.
  • the target forwarding node (gateway) for NG System is a node corresponding to LTE S-GW.
  • the control node sends a Create Session Request message to the target forwarding node (gateway).
  • the Create Session Request message may include information (e.g., SDF templates, or Traffic Flow Templates (TFTs)) for specifying one or more service data flows associated with each EPS bearer context.
  • TFTs Traffic Flow Templates
  • the information for specifying the one or more service data flows is a network corresponding to a pure NG Core to which NR NB 3 is connected from an MME in a network slice instance corresponding to EPC to which LTE eNB 2 is connected. It may be derived from a message (eg, Forward Relocation Request message) sent to the control node in the slice instance.
  • the target forwarding node (gateway) allocates the local resource and returns a Create Session Response message to the control node.
  • the control node in the NG Core 5 A bearer modification procedure may be performed instead of the generation procedure.
  • the control node (e.g., CPF) in the NG Core 5 may select (reselect) the network slice to be connected to the UE 1 after the handover.
  • the control node in NG Core 5 may perform creation of the selected network slice instance.
  • the control node in NG Core 5 may select a network slice for UE 1 based on the QoS required for UE 1's EPS bearer (s) or SDF (s). Further or alternatively, the NG Core 5 may consider network slice support information (network slice assistance information).
  • the network slice support information assists selection, setting, or approval of a network slice by a control node (e.g., CPF) in the NG Core 5.
  • the network slice support information may be generated by an EPC network slice instance in UE1, LTELeNB2, or NG Core5.
  • the NR Handover Confirm for NR message (step 206) sent from the UE1 to the target NR NB3 may include network slice support information (network slice assistance information), and the target NR NB3 receives the received network slice support information. It may be included in the NR Path Switch Request message (step 207).
  • the network slice support information includes, for example, the type of UE1 (eg, Device Type, UE Category), the use purpose of UE1 (eg, UE Usage Type), the service type desired by UE1 (eg, Requested / Preferred Service Type, Multi- Dimensional (Descriptor (MDD)), slice information selected by UE1 (eg, Selected Slice Type, Selected Slice Identity (ID), Selected Network Function (NF) ID), and slice information (eg, Authorized Slice Type that UE1 has been approved in advance) , “Authorized” Slice “ID”, “Authorized” NF “ID”), and the allowable latency (eg, “Allowed” Latency, “Tolerable” Latency) of UE1 or any combination thereof may be indicated.
  • the type of UE1 eg, Device Type, UE Category
  • the use purpose of UE1 eg, UE Usage Type
  • the service type desired by UE1 eg, Requested / Preferred Service Type, Multi- Dimension
  • the Service Type is, for example, the Type of Use Case (eg, Broadband Communication (enhanced Mobile Broadband: eMBB), High Reliability / Low Latency Communication (Ultra Reliable and Low Latency Communication: URLLC), or Multi-connection M2M Communication (massive Machine Type Communication: mMTC) or equivalent).
  • Slice ID is, for example, slice instance information (Network Slice Instance (NSI) ID), individual network information (Dedicated Core Network (DCN) ID), and network domain name information (Domain Network Name ID (DNN) ID) Any or any combination may be indicated.
  • NTI Network Slice Instance
  • DCN Dedicated Core Network
  • DNN Domain Network Name ID
  • the NF ID includes, for example, a common network function (Common NF (CNF)), a common control plane function (Common Control plane NF (CCNF)), a common user plane function (Common User Plane NF (CUNF)), and a data gateway ( Data Network Gateway (DN GW)) or any combination of identification information (ID) may be indicated.
  • CNF Common Network function
  • CCNF Common Control plane function
  • CUNF Common User Plane NF
  • DN GW Data Network Gateway
  • the control node in the NG Core 5 sends an NR Path Switch Request Acknowledge message to the target NR NB3.
  • the NR Path Switch Request Acknowledge message may include core network information (NG Core Information).
  • the core network information (NG Core Information) may include flow information (Flow Information), slice information (Slice Information), or both.
  • the flow information includes at least one session (ie, PDU session () established in a bearer-less network (ie, NG system) to transfer at least one packet flow (ie, PDU flow (s)) of UE1. s)).
  • the flow information includes a flow identifier (eg, PDU flow ID), a transfer node address (Transport Layer Address) and an uplink (UL) session endpoint identifier (Session Endpoint Identifier (SEID)), and a flow. Includes QoS parameters.
  • the session endpoint identifier (SEID) may be, for example, Tunnel Endpoint Identifier (TEID) or network function (node) identifier (NF ID).
  • TEID may be, for example, GTP-TEID or GRE-TEID.
  • the flow information may further indicate a mapping between EPS bearers and PDU flows for UE1.
  • the flow information may indicate one or a plurality of SDFs mapped to each EPSerbearer of UE1 and a flow identifier (e.g., PDU flow ID) assigned to each of the one or more SDFs.
  • the flow information may include priority information (priority indicator), flow type information (flow type indicator), or flow class (Flow Class).
  • the priority information may indicate a relative priority between a plurality of flows, or may indicate an absolute priority of each flow.
  • the flow type information may indicate, for example, which Use Case or service flow.
  • the flow class may indicate one of predetermined flow types (e.g., loss-less, delay tolerant, delay sensitive, mission critical), for example.
  • the slice information includes information related to the network slice of NG Core5 to which UE1 is connected (connected) after handover, information related to the network slice of NG Core5 that is allowed to connect to UE1, and network slice of NG Core5 to which UE1 can be connected. Contains at least one of the information.
  • the slice information may include identification information of a slice (Network Slice: NS) determined (selected) for UE1, identification information of a network node (NF), slice type information, or any combination thereof.
  • the slice identification information may be, for example, any one or any combination of Slice ID, NSI ID, MDD, DCN ID, and DNN.
  • Network node identification information includes, for example, NF ID, CNF ID, CCNF ID, Slice specific Control plane NF (SCNF) ID, CUNF ID, Slice specific User plane NF (SUNF) ID, UPF ID, ID, and DN GW ID Or any combination.
  • the slice type information may include, for example, Slice Type indicating any one or any combination of Service Type, Service Category,, and Use Case.
  • the slice type information may include a Tenant ID indicating Use ⁇ ⁇ Case or a contract type (Subscription Group, e.g.
  • the slice type information may include MDD including Slice type and Tenant ID as elements. Note that the content of the slice information described above may be specified for each network slice. Therefore, when UE1 is simultaneously connected to a plurality of network slices, the slice information may include a plurality of sets of information corresponding to the number of network slices to which UE1 is connected.
  • the slice information may further include a mobility class (Mobility Class) or a session class (Session Class) or both.
  • Mobility Class may indicate one of predefined mobility levels (e.g., high mobility, low mobility, no mobility). For example, high mobility has a wider geographical area that supports mobility for UE1 (allows mobility to UE1) than that of low mobility, and the service at the time of handover (PDU session) This means that the degree of continuity requirement is high. No mobility means that the network slice supports mobility only within a limited geographical area for UE1 (allows UE1 to move).
  • Mobility Class may be specified for each UE or may be specified for each network slice.
  • Session Class may indicate one of predefined session types (e.g., Session pre-setup, Session post-setup, No PDU session).
  • Session pre-setup uses PDU session before UE completes moving to the target (cell, beam, other area) in order to maintain service (PDU Session) according to mobility like existing handover. It may indicate that it is required to establish.
  • Session post-setup may indicate that PDU session may be established after the UE moves to the target.
  • Session Class may be specified for each PDU session.
  • Mobility Class and Session Class may be included in Slice Type.
  • Slice Type may include a plurality of attributes including Mobility Class and Session Class. Note that the above flow information may include Mobility Class, Session Class, or both.
  • the target NR NB3 sends an NR DL Information Transfer message carrying the NAS information (e.g., slice information and flow information) received from the NG Core 5 to the UE1.
  • NAS information e.g., slice information and flow information
  • NG System including NR3NB3 and NG Core5
  • bearers eg, NG-EPS-bearer
  • the link path may include a path (eg, GTP tunnel or GRE tunnel) between the (source or old) S / P-GW and the NG Core5 (target or New) User plane Function (eg, CUNF) .
  • S / P-GW transfers downlink data to User plane Function (eg, CUNF) in NG Core5, and User plane Function (eg, CUNF) in NG Core5 is uplinked to S / P-GW -Data may be transferred.
  • User plane Function eg, CUNF
  • CUNF User plane Function
  • the bearer eg, NG-EPS-bearer
  • the bearer eg, NG-EPS-bearer
  • NW Slicing CUNF may mediate between SUNF having the above functions. That is, the S / P-GW may transfer the downlink data to the CUNF in the NG Core 5 and the CUNF may transfer the downlink data to another UNF having a flow unit control function. Alternatively, data transfer may be performed directly between the S / P-GW and SUNF without going through the CUNF IV. In other handover procedures described below, the post-handover data transfer path described here may be used.
  • FIG. 3A and 3B show another example of the handover procedure of UE1 from LTE System to NG System in the configuration example of the wireless communication network shown in FIG.
  • FIG. 3A shows a preparation phase and an execution phase of handover
  • FIG. 3B shows a completion phase of handover.
  • the target NR NB3 performs core network information (eg, flow information and / or slice information) in the handover completion phase (step 209) after the UE1 connects to the target NR NB3. ) Is received from NG Core 5.
  • core network information eg, flow information and / or slice information
  • the target NR ⁇ NB 3 performs the core network information (eg, in the handover preparation phase (step 304) before the handover instruction to the UE 1 by the source LTE 2eNB2).
  • Flow information and / or slice information is received from NG Core 5.
  • step 303 the target NR NB 3 sends a Handover Preparation Request message to the NG Core 5 in response to the reception of the NR Handover Request message (step 302).
  • the handover preparation request (Handover Preparation303Request) message in step 303 may include a handover type information element (Handover Type IE) indicating handover from LTE to NR.
  • Handover Type IE handover type information element
  • the Handover Preparation Request message may include a list of NG EPS bearers of UE1 that is switched to the cell of target NR NB3.
  • the NG Core 5 determines, based on the received Handover Preparation Request message, that the type of handover is an Inter-RAT handover to NR (or NG System). Further, the NG Core 5 sends a Handover Preparation Request Acknowledge message including the core network information and / or security-related information to the target NR NB3.
  • the core network information and security related information are used by the target NR NB3 and UE1 to perform radio resource settings and security related settings for communicating with UE1 in the NG system.
  • the core network information may include slice information.
  • the slice information includes information related to the network slice of NG Core5 to which UE1 is connected (connected) after handover, information related to the network slice of NG Core5 that is allowed to connect to UE1, and network slice of NG Core5 to which UE1 can be connected. Contains at least one of the information.
  • the control node (e.g., CPF) in the NG Core 5 determines (selects) a network slice to be connected to the UE 1 after the handover.
  • the control node (CPF) in NG Core 5 may select a network slice for UE1 based on the QoS required for UE 's EPS bearer (s) or SDF (s).
  • the NG Core 5 may consider network slice support information (network slice assistance information).
  • the network slice support information assists selection, setting, or approval of a network slice by a control node (e.g., CPF) in the NG Core 5.
  • the network slice support information may be generated by an EPC network slice instance in UE1, LTELeNB2, or NG Core5.
  • UE1 may send network slice support information to LTE eNB2 in step 301.
  • the network slice support information may be NAS information (NAS information) and may be included in a measurement report (measurement report) sent from UE1 to LTE eNB2.
  • the source LTE eNB2 may send the network slice support information received from the UE1 to the target NR NB3.
  • the core network information may include flow information (Flow Information).
  • the flow information includes at least one session (ie, PDU session () established in a bearer-less network (ie, NG system) to transfer at least one packet flow (ie, PDU flow (s)) of UE1. s)).
  • flow information includes a flow identifier (eg, PDU flow ID), an address of a forwarding node in NG Core5, and an uplink (UL) session endpoint identifier (Session Endpoint). Identifier (SEID)), as well as flow QoS parameters.
  • SEID uplink
  • SEID Session Endpoint
  • the session endpoint identifier may be, for example, Tunnel Endpoint Identifier (TEID) or network function (node) identifier (NF ID).
  • TEID may be, for example, GTP-TEID or GRE-TEID.
  • the flow information may further indicate a mapping between EPS bearers and PDU flows for UE1.
  • the flow information may indicate one or a plurality of SDFs mapped to each EPSerbearer of UE1 and a flow identifier (e.g., PDU flow ID) assigned to each of the one or more SDFs.
  • the flow information may include priority information (priority indicator), flow type information (flow type indicator), or flow class (Flow Class).
  • the security related information may include Non-Access Stratum (NAS) security configuration information (security configuration) used between the NG Core 5 and the UE 1 in the NG System.
  • the NAS security setting information includes, for example, a NAS security algorithm including ciphering and integrity protection.
  • the NAS security setting information may be NAS Security Transparent Container IE.
  • the NAS security setting information (NAS Security Transparent Container IE) is transparently sent from the target NR NB3 to the UE1 via the source LTE eNB2.
  • the security related information further includes security parameters used by the target NR NB3 for the derivation of Access Stratum (AS) security keys.
  • the security parameter is a base key for deriving a security key (temporary key) used by the AS layer (ie, a key equivalent to LTE K eNB ), or a parameter for deriving the base key (Eg, ⁇ NH, NCC ⁇ pair).
  • the Next Hop parameter (NH) and the Next Hop Chaining Counter parameter (NCC) are used for derivation of KeNB according to a vertical key derivation algorithm.
  • the security parameter may further include UE security capabilities related to NG RAT or NG System.
  • UE security capabilities indicates a ciphering and integrity protection algorithm (algorithms) implemented in UE1.
  • the core network information included in the confirmation message (Handover ⁇ Preparation Request Acknowledge) message for the handover preparation request in step 304 is one or both of the above two examples (ie, slice information and flow information). May be included.
  • the target NR NB3 creates (creates) a UE context and allocates resources in response to receiving a Handover Preparation Request Acknowledge message that includes core network information or security related information or both.
  • the target NR NB3 may operate as follows.
  • the target NR NB3 may perform admission control based on core network information including slice information. For example, the target NR NB3 may determine whether to accept a bearer or a flow for each bearer or for each flow.
  • the target NR ⁇ ⁇ NB3 may perform admission control for each network slice to which the UE1 is connected based on the slice information. At this time, the NR NB3 may determine whether or not each network slice can be accepted.
  • the network slice May be mapped to a specific network slice (eg, default network slice), or the network slice may be connected to a specific NF (eg, CUPF).
  • the NR NB 3 may determine failure to accept the network slice.
  • the target NR NB 3 has the radio resource setting information (eg, the UE 1 necessary for establishing a radio connection (eg, RRC connection, radio bearer) associated with the NG System that supports network slicing. , Radio parameters) may be generated based on slice information (or derived from slice information).
  • the radio resource setting information may include at least one parameter included in the slice information.
  • the radio resource setting information derived from the slice information may include radio (or RAN) parameters for each network slice (or for each use case).
  • Use cases include, for example, enhanced mobile broadband (eMBB), massive machine-type communications (mMTC), and Ultra-reliable and low-latency communications (URLLC).
  • the radio parameters for each network slice (or each use case) may be basic physical channel parameters or basic layer 2 / layer 3 (L2 / L3) settings.
  • Basic physical channel parameters may include, for example, frame / subframe structure, Transmission Time. Interval (TTI) length, subcarrier spacing, and Physical Random Access Channel (PRACH) resource.
  • the PRACH resource may be a preamble index, a time / frequency resource, or both.
  • Basic L2 / L3 settings may include, for example, frame / subframe pattern and L2 protocol sublayer settings (L2 configuration. E.g., PDCP config, RLC config, or MAC config).
  • radio resource setting information derived from slice information a message configuration, an information element (IE) format, a parameter value, and an information structure definition are shown.
  • IE information element
  • At least one of ASN.1 (Abstract Syntax Notation One) encoding and decoding targets may be different for each slice.
  • the target NR NB3 may operate as follows.
  • the target NR NB3 may consider the flow information for generating the UE context and the radio resource setting information. Specifically, the target NR NB3 may generate (create) a UE context including information about the packet flow (i.e., PDU flow (s)) and a security context based on the flow information. Further, the target NR NB3 sets the radio resource setting information necessary for the UE1 to establish the radio connection (eg, RRC connection, radio bearer) associated with the bearer-less network (ie, NG System), and the flow information (Or derived from flow information).
  • the radio connection eg, RRC connection, radio bearer
  • the bearer-less network ie, NG System
  • the radio resource setting information may include at least one parameter included in the flow information.
  • the radio resource setting information includes system information (System Information Block: SIB) in the cell (or mobility area, beam cover area) of the target NR NB3, radio resource setting common to UEs (Common Resource Configuration), or individual UE
  • SIB System Information Block
  • Common Resource Configuration Common Resource Configuration
  • the wireless resource configuration (Dedicated Resource Configuration) may be included.
  • the radio resource setting information indicates a mapping between a bearer (eg, EPS bearer, Data Radio Bearer (DRB)) in the source LTE eNB2 cell and a flow (eg, PDU flow) established in the target NR NB3 cell. Information may be included.
  • a bearer eg, EPS bearer, Data Radio Bearer (DRB)
  • DRB Data Radio Bearer
  • the NG System including NR NB3 and NG Core5 may be configured to support bearer-based forwarding using bearers per QoS class and per PDU session, and QoS handling per data flow (PDU flow). It may be configured to identify the data flow (PDU flow) in the bearer for (eg, packet discard).
  • the NR NB3 associates a bearer (eg, NG3 bearer) set between the user plane function in the NR NB3 and the NG Core5 with the radio bearer, and between the bearer (eg, NG3 bearer) and the radio bearer. Packet forwarding may be performed, and QoS handling (eg, packet discard) may be performed for each data flow (PDU flow) in the bearer.
  • a bearer eg, NG3 bearer
  • the above flow information includes the bearer for UE1 (eg, NG-RAB or NG3 bearer) and one or more packet flows of UE1 transferred via the bearer (ie, PDU flow (s)). May indicate an association.
  • the control node (eg, CPF) in the NG Core 5 has one or more packet flows (ie, UE1, NG-RAB or NG3 bearer) for the UE1 and UE1 transferred via the bearer.
  • PDU flow (s)) to inform the NR NB3 of the flow information
  • the flow information may be sent to the NR NB3.
  • NB3 receives flow information from the control node in NG
  • QoS handling eg, packet discard
  • the target NR NB3 may operate as follows.
  • the security related information includes NAS security setting information (NAS Security Transparent Container IE) and security parameters for AS security.
  • the target NR NB3 may include NAS security setting information (NAS Security Transparent Container IE) in a transparent container sent to the UE1. Additionally or alternatively, the target NR NB3 may select an AS security algorithm based on UE security capabilities included in the security parameters.
  • the AS security algorithm includes a ciphering algorithm for Radio Resource Control (RRC) and user plane (UP), and an integrity protection algorithm for RRC.
  • RRC Radio Resource Control
  • UP user plane
  • the target NR NB3 uses RRC ciphering (encryption), UP ciphering (encryption), and temporary keys for RRC integrity protection as a base key (from the security parameters) using the selected security algorithm. ie, a key corresponding to LTE K eNB ).
  • Target NR NB3 generates Target To Source Transparent Container (RRCConnectionReconfiguration) sent to UE1.
  • the Target To Source Transparent Container includes a HandoverCommand message including, for example, an RRCConnectionRecofiguration message and another RRC message.
  • the target NR NB3 generates an acknowledgment (NR Handover Request Acknowledge) message for the handover request including the Target To Source Transparent Container and the core network context information (NG Core Context IE) including the core network information.
  • NG Core Context IE core network context information
  • the target NR NB3 sends an NR Handover Request Acknowledge message to the source LTE eNB2 over the direct inter-base station interface 101 (e.g., X3 interface).
  • Target To Source Transparent Container includes, for example, radio resource setting information (eg, radio parameters) set up by the target NR ⁇ ⁇ ⁇ ⁇ ⁇ NB3, AS security algorithm identifiers (identifiers) selected by the target NR NB3, and NAS security setting information To do.
  • the core network context information (NG Core Context) may be transmitted to the UE1 transparently to the source LTE eNB2. Additionally or alternatively, part or all of the core network context information may be included in Target ⁇ To Source Transparent Container.
  • the NR Handover Request Acknowledge message may further include the “NE-RABs Admitted list” information element (IE) described above.
  • eNB2 starts the data forwarding for the bearer or flow (PDU
  • step 306 is the same as the processing of step 204 in FIG. 2A.
  • step 307 UE1 moves to the target RAN (ie, NG RAN) in response to the reception of the RRC message including the Handover Command message, and transparent container (eg, radio resource setting information supplied in the Handover Command message). , AS security algorithm, and NAS security setting information).
  • step 308 is similar to the processing in step 206 in FIG. 2A.
  • the NG Core 5 performs a bearerless session creation procedure or a bearer modification procedure.
  • the control node in the NG Core 5 in response to receiving the Handover Preparation Request message in step 303, the control node in the NG Core 5 starts a bearerless session creation procedure or a bearer modification procedure for the UE1. That is, the control node in the NG Core 5 starts a bearerless session creation procedure or a bearer modification procedure for the UE1 prior to the path switch request from the target NR NB3 (step 310).
  • the bearerless session creation or bearer modification in step 309 may be performed similarly to that in step 208 of FIG. 2B.
  • the target NR NB3 sends an NR Path Request message to the NG Core5.
  • the control node in the NG Core 5 completes the Inter-RAT Handover procedure by performing a flow modification procedure.
  • the control node in the NG Core 5 may send a Modify Flow Request message for each session (i.e., PDU session) to the forwarding node in the NG Core 5.
  • the Modify Flow Request message may include a flow identifier (e.g., PDU flow ID), and the target NR NB3 address and downlink (DL) session endpoint identifier (SEID).
  • SEID session endpoint identifier
  • TEID Tunnel Endpoint Identifier
  • Core 5 may return a Modify
  • Core5 sends NR
  • FIG. 4 is a flowchart showing an example (process 400) of a method performed by the target NR NB3.
  • the target NR NB3 receives the Handover Request message from the source LTE eNB2 on the direct inter-base station interface 101.
  • the Handover request message relates to the handover of UE1 from the LTE system to the NG system.
  • Step 401 corresponds to, for example, step 202 in FIG. 2A or step 302 in FIG. 3A.
  • the target NR NB3 receives slice information and / or flow information from the core network (i.e., NG Core5).
  • Step 402 corresponds, for example, to step 209 in FIG. 2B or step 304 in FIG. 3A.
  • the target NR NB3 controls the communication of the UE1 based on at least one of the slice information and the flow information.
  • the target NR NB3 may generate radio resource setting information based on at least one of the slice information and the flow information, and send the radio resource setting information to the UE1.
  • the target NR NB3 may select a network slice for sending a control plane message related to UE1 based on the slice information.
  • the target NR NB3 may forward the UE1 UL user data (PDU flows) to the NG Core5 based on the endpoint information included in the flow information.
  • the target NR NB3 may perform resource scheduling for the UE1 based on the flow QoS parameter included in the flow information.
  • FIG. 5 is a flowchart showing an example (process 500) of a method performed by the source LTE eNB2.
  • the source LTELNB2 sends a Handover ⁇ ⁇ Request message to the target NR NB3 on the direct inter-base station interface 101.
  • the Handover request message relates to the handover of UE1 from the LTE system to the NG system.
  • Step 501 corresponds to, for example, step 202 in FIG. 2A or step 302 in FIG. 3A.
  • the source LTE eNB 2 receives a Handover Request Acknowledge message including a transparent container (RRCConnectionReconfiguration) from the target NR NB 3 on the direct inter-base station interface 101.
  • Step 502 corresponds to, for example, step 203 in FIG. 2A or step 305 in FIG. 3A.
  • the transparent container includes, for example, radio resource setting information set up by the target NR NB 3, identifiers of AS security algorithms selected by the target NR NB 3, and NCC values or NAS security setting information.
  • the source LTE eNB2 sends a mobility command message (e.g., Handover Command message) including the transparent container received from the target NR NB3 and indicating handover to the bearerless network to the UE1.
  • a mobility command message e.g., Handover Command message
  • Step 503 corresponds to step 204 in FIG. 2A or step 306 in FIG. 3A.
  • FIG. 6 is a flowchart showing an example of the method (process 600) performed by the core network (i.e., “NG” Core 5).
  • the process of FIG. 6 may be performed by one control node in NG Core 5 or by two control nodes (i.e., source MME and target control node) in NG Core.
  • the NG Core 5 receives a message (e.g., Handover Preparation Request message or NR Path Switch Request message) indicating a handover or path switch from the LTE system to the NG system from the target NR NB3.
  • Step 601 corresponds to step 207 in FIG. 2B or step 303 in FIG. 3A.
  • step 602 NG Core 5 sends slice information and / or flow information to target NR NB 3.
  • Step 602 corresponds to, for example, step 209 in FIG. 2B or step 304 in FIG. 3A.
  • FIG. 7 is a flowchart showing an example (process 700) of a method performed by UE1.
  • UE1 receives a mobility command message (e.g., Handover Command message) from source LTE eNB2.
  • the mobility command message includes a transparent container (RRCConnectionReconfiguration) from the target NR NB3.
  • the transparent container includes, for example, radio resource setting information, AS security algorithm, and NCC value or NAS security setting information.
  • Step 701 corresponds to, for example, step 204 in FIG. 2A or step 306 in FIG. 3A.
  • step 702 UE1 establishes a wireless connection with the target NR NB3 associated with the NG System according to the information contained in the received transparent container.
  • Step 702 corresponds to, for example, steps 205 and 206 in FIG. 2A or steps 307 and 308 in FIG. 3A.
  • the network may allow the UE 1 to know in advance whether or not the handover target cell (NR cell) supports network slicing.
  • the NR NB3 is a network slicing support information that explicitly or implicitly indicates that network slicing is supported in the NR cell (or that connection to an NG Core capable of network slicing is possible).
  • Explicitly sent network slicing support information indicates a supported network slice (eg, Supported Service Type) or a supported slice type (eg, Supported). Slice Type) may further be included.
  • the implicitly transmitted network slicing support information may include information on radio resource settings that are different for each network slice.
  • the UE 1 may understand that network slicing is supported in the cell by recognizing that at least a part of the received radio resource configuration is specified for each network slice.
  • the information related to the radio resource setting may include physical resource setting information and / or system setting information.
  • the physical resource setting information may include at least one of code, time, frequency, RACH preamble sequence (group).
  • the system setting information may include at least one of subcarrier spacing, sampling rate, TTI, TIsubframe / frame format type.
  • the network slicing support information may be transmitted as NAS layer information or AS layer information. In the former case, UE1 transfers the information received at the AS layer (RRC) to the NAS layer.
  • RRC AS layer
  • the detailed handover procedure from the LTE® System to the NG® System may be, for example, the specific example described above, but is not limited thereto.
  • the message names shown in some example handover procedures described above are merely exemplary.
  • the order of the messages may be different, some messages may be omitted, or additional messages may be included.
  • some handover procedures from the LTE System to the NG System described in this embodiment are related to Inter-RAT with transfer of a handover signaling message on the interface between direct base stations.
  • This is a handover procedure.
  • the target NR NB3 is configured to receive slice information and / or flow information from the core network (ie, NG Core5) and use this information to control UE1 communication. .
  • target NR NB3 can contribute to continuing the communication of UE1 of the connected state handed over from LTE System to NG System.
  • FIG. 8 illustrates an example of a handover procedure of the UE 1 from the LTE System to the NG System in the configuration example of the wireless communication network illustrated in FIG. Note that the handover procedure shown in FIG. 8 is a detail and modification of the handover procedure shown in FIGS. 2A and 2B, and specifically describes the configuration in NG Core 5 and network slice selection by NG Core 5. ing.
  • the NG Core 5 shown in FIG. 8 includes a common network function (Common Network Functions (NFs)) 51, a network function (NFs for Slice A) 52 for a network slice A, and a network function (NFs A for Network Slice B). slice B) 53 and Home Subscriber Server (HSS) 54.
  • NFs Common Network Functions
  • HSS Home Subscriber Server
  • Each network element is a component of a network slice.
  • Each network slice is composed of required network functions (NFs) to provide required communication services (telecommunication services) and network capabilities (network capabilities).
  • NFs network functions
  • Each network element (NF) is a processing function within the network and defines functional behaviors and interfaces.
  • Each network element may be implemented as a network element on dedicated hardware, or may be a software instance that runs on dedicated hardware, as appropriate It may be a virtualized function that is instantiated on the platform.
  • Each network slice may be identified by a Network Slice specific Instance ID (NSI-ID).
  • Each network function (NF) may be identified by a Network Function ID (NF ID).
  • NF ID Network Function ID
  • Common CP-NFs Common control plane network function
  • the NSI-ID may be a combination of Common CP-NF IDs and Slice-specific IDs (i.e., NF IDs for for selected slice).
  • the Common NFs 51 shown in FIG. 8 includes a control plane network function (CP NFs).
  • the Common NFs 51 may further include a user plane network function (UP NFs).
  • NFs for slice A52 includes UP NFs and may include CP NFs.
  • NFs for slice B53 includes UP NFs and may include CP NFs.
  • FIG. 8 shows an example in which the slice selection function (Slice Selection Function (SSF)) is co-located with the Common NFs 51.
  • the SSF may be arranged away from the Common NFs 51.
  • Common NFs 51 exchanges messages with SSF.
  • the SSF selects a network slice associated with UE1.
  • the SSF may associate UE1 with the default network slice, and in addition or alternatively, associate with the network slice (slice type) specified by UE1.
  • the SSF may further perform NAS Node Selection Function (NNSF) to select CP NFs (or CP NFIDs) corresponding to the selected slice.
  • the default network slice may be set for each Public Land Mobile Network (PLMN), RAT, UE usage type, Service type, or Slice type.
  • PLMN Public Land Mobile Network
  • RAT Radio Access
  • the allocation of one or more packet flows of UE1 to a network slice may be performed according to any of the following three examples.
  • an NG System including NR NB3 and NG Core5 supports bearer-based transfer using a bearer for each QoS class and for each PDU session.
  • the NG System bearer may be called NG-EPS-bearer, and the NG System radio access bearer may be called NG-RAB.
  • each bearer is assigned to any network slice.
  • Common NFs 51 communicates with Slice specific User plane NF (s) (SUNF (s)) of the network slice selected for UE1, and sets the bearer of UE1 in the SUNF (s) .
  • SUNF Slice specific User plane NF
  • the NG System including NR NB3 and NG Core5 supports bearer-based transfer using a bearer for each QoS class and for each PDU session.
  • An NG System bearer can be used to transfer multiple packet flows (PDU flows).
  • the NG System is configured to identify the data flow (PDU flow) in the bearer for QoS handling (e.g., packet discard) for each data flow (PDU flow).
  • QoS handling e.g., packet discard
  • each packet flow (e.g., PDU flow) of UE1 is assigned to any network slice in units of flows (PDU flow).
  • the NG System including NR NB3 and NG Core5 supports flow-based transfer of user data.
  • network slicing is set for each PDU session of UE1.
  • a set of a plurality of packet flows (PDU flows) included in one PDU session is allocated to any one network slice.
  • UE1 is handed over from source LTELNB2 to target NR NB3 and is in a connected state (i.e., RRC_Connected) in the cell of target NR NB3.
  • UE1 sends network slice support information (network slice assistance information) to target NR NB3.
  • the network slice support information may indicate, for example, the type of UE1, the service desired by UE1, or the allowable latency of UE1, or any combination thereof.
  • the network slice support information may be NAS information (NAS information) and may be included in a measurement report (measurement report) sent from UE1 to LTE eNB2.
  • UE1 may use RRC Connection Reconfiguration Complete message (e.g., step 206 in Fig. 2A), UL Information Transfer message, or other RRC message to transmit network slice support information. Note that transmission of network slice support information by UE1 may be omitted.
  • Step 802 corresponds to step 207 in FIG. 2B. That is, the target NR NB3 sends an NR Path Switch Request message to the NG Core5.
  • the NR Path Switch Request message includes an EPS Radio Access Bearer (E-RAB) QoS information element (IE).
  • E-RAB QoS IE indicates the E-RAB QoS (e.g., QoS class identifier (QCI), Allocation retention priority (ARP)) of UE1.
  • the NR Path Switch Request message may further include network slice support information (step 801) sent from the NAS layer of UE1.
  • Step 803 the Common NFs 51 performs authentication of the UE1 as necessary.
  • the authentication includes confirmation of an authorized slice (slice authorization) for UE1.
  • slice authorization Common NFs 51 may determine / determine whether or not UE1 is permitted for each slice.
  • the Common / NFs 51 executes slice selection. That is, the Common NFs 51 selects a network slice associated with UE1. In the example of FIG. 8, Common NFs 51 selects slice A for UE1.
  • the slice selection in step 804 may be performed for each service (e.g., EPS bearer / E-RAB, IP flow) performed by UE1 (ongoing) or requested (request). As already described, the slice selection in step 804 may be performed by an SSF arranged away from the Common NFs 51.
  • service e.g., EPS bearer / E-RAB, IP flow
  • Step 805 corresponds to step 208 in FIG. 2B.
  • Common NFs 51 communicates with UP ⁇ ⁇ ⁇ ⁇ NFs (NFs for slice A52) of the selected slice to create a bearerless session in the slice selected for UE1 (here, slice A). If the NG System supports bearer-based transfer of user data and relocation of the transfer node is not necessary, the Common NFs 51 may perform a bearer modification procedure instead of the session generation procedure. Good.
  • Step 806 corresponds to step 209 in FIG. 2B.
  • the Common NFs 51 sends an NR Path Switch Request Acknowledge message to the target NR NB3.
  • CP NFs NFs for slice A52
  • CP NFs NFs for slice A52
  • the NR Path Switch Request Acknowledge message in Step 806 includes information (i.e., “slice information information element (IE)) regarding the network slice selected by the Common NFs 51 (or SSF).
  • Slice information IE includes, for example, an NSI-ID indicating a selected network slice, an NF ID indicating a selected network function (NFs), or a multi-dimensional descriptor (MDD), or any combination thereof. Also good. MDD can be provided by the UE in the RRC signaling layer and the NAS signaling layer. MDD represents a tenant ID (Tenant ID) and a service descriptor (Service Descriptor) / slice type (slice type).
  • the service descriptor / slice type indicates the service or use case (e.g., eMBB, mMTC, URLLC, critical communications (CriC)) associated with UE1 or the selected network slice.
  • Step 807 corresponds to step 210 in FIG. 2B.
  • the target NR NB3 sends an NR DL Information Transfer message carrying the slice information IE received from the NG Core 5 to the UE1.
  • FIGS. 9A and 9B show another example of the handover procedure of UE1 from LTE System to NG System in the configuration example of the wireless communication network shown in FIG.
  • the handover procedure shown in FIGS. 9A and 9B is a detail and modification of the handover procedure shown in FIGS. 3A and 3B, and specifically describes the configuration in NG Core 5 and network slice selection by NG Core 5. is doing.
  • FIG. 8 differences between the procedure of FIG. 8 and the procedures of FIGS. 9A and 9B will be mainly described.
  • UE1 is connected to LTE eNB2 and is in a connected state (i.e., RRC_Connected).
  • UE1 sends network slice support information (network slice assistance information) to LTE eNB2.
  • UE1 may use RRC Connection Reconfiguration Complete message, UL Information Transfer message, or other RRC messages to transmit network slice support information.
  • Step 902 corresponds to step 302 in FIG. 3A. That is, the source LTELeNB3 sends an NR Handover Request message to the target NR NB3.
  • the NR Handover Request message includes E-RAB QoS IE.
  • E-RAB QoS IE indicates the E-RAB QoS (e.g., QoS class identifier (QCI), Allocation retention priority (ARP)) of UE1.
  • the NR Handover Request message may further include network slice support information (step 901) sent from the NAS layer of UE1.
  • Step 903 corresponds to step 303 in FIG. 3A. That is, the target NR NB3 transmits a Handover Preparation Request message to the NG Core5.
  • the Handover Preparation Request message includes the E-RAB QoS IE received from the source LTE eNB2.
  • the Handover Preparation Request message may further include network slice support information (step 801) received from the source LTE eNB2.
  • the processing in steps 904 and 905 is the same as the processing in steps 803 and 804 in FIG. Step 906 corresponds to step 304 in FIG. 3A. That is, the Common NFs 51 sends a Handover Preparation Request Acknowledge message to the target NR NB3.
  • the Handover Preparation Request Acknowledge message includes information (i.e., slice information IE) on the network slice selected by Common NFs 51 (or SSF).
  • Step 907 corresponds to step 305 in FIG. 3A. That is, the target NR NB3 sends an NR Handover Request Acknowledge message to the source LTE eNB2.
  • the transparent container contained in the NR Handover Request Acknowledge message may include slice information IE sent from the Common NFs 51.
  • Step 908 corresponds to step 306 in FIG. 3A. That is, the source LTELeNB3 sends a Radio Resource Control (RRC) message including a Handover Command message including the transparent container generated by the target NR NB3 to the UE1.
  • the RRC message may be, for example, a Mobility from EUTRA command message or an RRC Connection Reconfiguration message.
  • the transparent container that is sent to the UE 1 may include slice information information IE.
  • Steps 909 and 910 correspond to steps 307 and 308 in FIG. 3A. That is, UE1 performs handover to target NR NB3 (step 309), and sends an NR Handover Confirm for NR message to target NR NB3 (step 910).
  • the message in step 910 may be an NR RRC Connection Reconfiguration Complete message.
  • the message of step 910 may include slice information IE.
  • the slice information IE includes an identifier (e.g., NSI-ID, NF IDs, or MDD) for identifying the network slice selected for UE1.
  • the slice information information IE may be NAS information (NAS information) or RRC information (RRC information).
  • any one of option 1 (i.e., steps 911A, 912A, and 913A) and option 2 (i.e., steps 911B, 912B, and 913B) shown in FIG. 9B is executed.
  • the target NR NB3 sends an NR Path Switch Request message to the Common NFs 51 (step 911A).
  • the NR Path Switch Request message may include slice information IE.
  • Step 911A corresponds to step 310 in FIG. 3B.
  • Step 912A corresponds to step 311 in FIG. 3B.
  • Common NFs 51 communicates with UP ⁇ ⁇ ⁇ ⁇ NFs (NFs for slice A52) of the selected slice to create a bearerless session in the slice selected for UE1 (here, slice A). If the NG System supports bearer-based transfer of user data and the relocation of the transfer node is not necessary, the Common NFs 51 may perform a bearer modification procedure instead of the session generation procedure.
  • Step 913A corresponds to step 312 in FIG. 3B.
  • the Common NFs 51 sends an NR Path Switch Request Acknowledge message to the target NR NB3.
  • CP NFs NFs for slice A52
  • CP NFs NFs for slice A52
  • the target NR NB3 determines the network slice (ie, slice A) selected for UE1, and the NR Path Switch Request Acknowledge to the CP NFs of NFs for slice A52 corresponding to the slice A.
  • a message is sent (step 911B).
  • the target NR NB3 may use the slice information IE received from UE1 in step 910 to determine the network slice selected for UE1.
  • the target NR NB3 stores the slice information IE received from the NG Core 5 in step 907 in association with the context of the UE1, and uses the stored slice information IE for the determination in step 911B. Also good.
  • Step 912B corresponds to step 311 in FIG. 3B.
  • the CP NFs of NFs for slice A52 communicate with the UP NFs of NFs for slice A52 in order to create a bearerless session. If NG System supports bearer-based transfer of user data and relocation of transfer nodes is not required, NFs for Slice A 52 can perform a bearer modification procedure instead of the session generation procedure. Good. NFs for slice A52 may communicate with Common NFs 51 as necessary.
  • Step 913B corresponds to step 312 in FIG. 3B.
  • the CP-NFs of NFs-for-slice-A52 sends an NR-Path-Switch-Request-Acknowledge message to the target NR-NB3.
  • the information (eg, NSI-ID, MDD, NFIDs) of the network slice selected for the UE 1 by the Common NFs 51 is transferred from the NG Core 5 to the target NR Can be supplied to. Therefore, for example, the target NR NB3 can know the network slice selected for the UE1.
  • the target NR NB3 may be configured by the Common NFs51 for UE1 to generate or derive information or parameters to be sent to UE1, for example, included in Handover Command (ie, transparent container (RRCConnectionReconfiguration)). Information on the selected network slice can be used.
  • This embodiment provides a handover method of UE1 from NG System to LTE System.
  • 10A and 10B show an example of a handover procedure of UE1 from NG System to LTE System in the configuration example of the wireless communication network shown in FIG.
  • FIG. 10A shows a handover preparation phase and an execution phase
  • FIG. 10B shows a handover completion phase.
  • the procedure shown in FIGS. 10A and 10B is in that it involves the transfer of handover signaling messages (ie, steps 1002 and 1003) on the direct inter-base station interface 101 (eg, X3 interface) during the handover preparation phase. Similar to LTE “X2-based handover”. However, if only the transfer of the handover signaling message on the direct base station interface 101 is performed, information necessary for the relocation of the UE 1 from the LTE system to the NG system is insufficient. Therefore, in the procedure shown in FIG. 12A and FIG. 12B, signaling (ie, step) between LTENBeNB2 and NG Core5 in order to obtain information necessary for relocation of UE1 from the NG system to the LTE system. The handover completion phase has been improved to include 1007 and 1008).
  • UE1 is connected to NR NB3 and is in a connected state (e.g., RRC_Connected).
  • UE1 receives a measurement configuration (Measurement Configuration) from NR NB3, and according to the measurement configuration, neighbor cell measurement (neighbor cell measurement) including heterogeneous RAT measurement (inter-RAT) including NG-RAN cells and E-UTRAN (LTE) cells Measures) and send a measurement report to NRNB3.
  • a measurement configuration Measurement Configuration
  • neighbor cell measurement including heterogeneous RAT measurement (inter-RAT) including NG-RAN cells and E-UTRAN (LTE) cells Measures
  • inter-RAT including NG-RAN cells and E-UTRAN (LTE) cells Measures
  • NR NB3 determines inter-RAT handover to the LTE NB2 cell. In response to the determination of the Inter-RAT handover, the NR NB 3 sends a handover request (Handover Request) message to the target LTE eNB2 on the direct inter-base station interface 101.
  • Handover Request handover request
  • the Handover Request message in Step 1002 may include a handover type information element (Handover Type Information Element (IE)) indicating a handover from NR to LTE.
  • IE Handover Type Information Element
  • NRtoLTE is set in Handover Type IE.
  • Handover request message in Step 1002 may indicate the identifier of the UE1 to be handed over (PDU flow (s)) or bearer (bearer (s)) and QoS parameters (e.g., QCI, ARP).
  • PDU flow s
  • bearer s
  • QoS parameters e.g., QCI, ARP
  • the Handover Request message in Step 1002 may include a “Handover Preparation Information to EUTRA” information element (IE).
  • the “Handover Preparation Information to EUTRA” IE may include security-related information.
  • Security-related information includes security parameters used by the target LTE eNB 2 for derivation of Access Stratum (AS) security keys.
  • the security parameter is a base key (ie, LTE K eNB ) for deriving a security key (temporary key) used by the AS layer, or a parameter (eg, ⁇ NH, NCC ⁇ pair).
  • the security parameter may further include UE security capabilities related to LTE RAT or LTE System.
  • UE security capabilities indicates a ciphering and integrity protection algorithm (algorithms) implemented in UE1.
  • the source NR NB3 derives K eNB * from an unused ⁇ NH, NCC ⁇ pair according to a vertical key derivation algorithm, and ⁇ K eNB *, NCC ⁇ pairs may be sent to the target LTE eNB2.
  • the source LTE eNB2 may derive K eNB * from the current K eNB according to a horizontal key derivation algorithm and send a ⁇ K eNB *, NCC ⁇ pair to the target NR NB3.
  • the target LTE eNB2 creates (creates) a UE context and allocates resources based on the Handover Request message.
  • the target NR NB3 may operate as follows.
  • the security related information includes security parameters for AS security.
  • the target NR NB3 may select an AS security algorithm based on UE security capabilities included in the security parameter.
  • the AS security algorithm includes a ciphering algorithm for Radio Resource Control (RRC) and user plane (UP), and an integrity protection algorithm for RRC.
  • RRC Radio Resource Control
  • UP user plane
  • the target NR NB3 uses RRC ciphering (encryption), UP ciphering (encryption), and temporary keys for RRC integrity protection as a base key (from the security parameters) using the selected security algorithm. ie, LTE (K eNB ).
  • Target To Source Transparent Container includes a HandoverCommand message (Handover Command To EUTRA) including, for example, an RRCConnectionRecofiguration ⁇ ⁇ message and another RRC message.
  • the target LTE eNB2 generates an acknowledgment (NR Handover Request Acknowledge) message to the handover request including the Target To Source Transparent Container.
  • the target LTE eNB2 sends an NR Handover Request Acknowledge message to the source NR NB3 on the direct inter-base station interface 101.
  • Target To Source Transparent Container includes, for example, radio resource setting information (e.g., radio parameters) set up by the target LTE eNB2, identifiers of AS security algorithms selected by the target NR NB3, and NCC values.
  • the Handover Request Acknowledge message may further include a list of bearers subject to downlink data forwarding (bearers subject to data forwarding list).
  • the “Bearers Subject to Data forwarding list” IE includes, for example, address (es), TEID (s) for user traffic data forwarding, and an identifier of a flow (PDU flow (s)) that is a target of data forwarding. Address (es) and TEID (s) for user traffic data forwarding may be the address and TEID to the target NR NB3 on the direct inter-base station interface 101.
  • the source NR NB3 starts data forwarding for the bearer or flow (PDU flow (s)) specified by the "Bearers Subject data forwarding list" IE.
  • the source NR NB3 sends a Radio Resource Control (RRC) message including a Handover Message message including the transparent container generated by the target LTE eNB2 to UE1.
  • RRC Radio Resource Control
  • the RRC message may be, for example, a Mobility from NR command message or an RRC Connection Reconfiguration message.
  • step 1005 UE1 moves to the target RAN (ie, E-UTRAN) in response to receiving the RRC message including the Handover Command message, and sets the transparent container (eg, radio resource setting supplied in the Handover Command message). Information, AS security algorithm, and NCC value). That is, UE1 establishes the radio connection with target LTE
  • step 1006 UE1 sends a Handover Confirm for EUTRA message to target LTE eNB2 after successfully synchronizing to the target cell.
  • the message in step 1006 may be an RRC Connection Reconfiguration Complete message.
  • step 1008 when UE1 has successfully accessed target NR NB3, target LTE eNB2 informs UE1 that the cell has been changed and requests a path switch to send a Switch Request message to NG Core5. Send to.
  • the Path Switch Request message may include a list of EPS bearers (or PDU flows) of UE1 that has been switched to the target LTE eNB2 cell.
  • the control node e.g., MME in NG Core5 performs a bearer-based session creation procedure. Specifically, the control node determines that the packet forwarding node (gateway) for UE1 needs to be relocated, and determines the target forwarding node (ie, S-GW) in NG Core5. select.
  • the control node sends a Create Session Request message to the target S-GW.
  • the Create Session Request message includes information (e.g., SDF templates, or Traffic Flow Templates (TFTs)) for specifying one or more service data flows associated with each PDU flow context.
  • TFTs Traffic Flow Templates
  • NG Core 5 sends a Path Switch Request Acknowledge message to the target LTE eNB2.
  • the Path Switch Request Acknowledge message includes bearer setting information.
  • the bearer setting information includes the address of the forwarding node (after relocation) in NG Core 5 and the uplink (UL) tunnel endpoint identifier (TEID).
  • the control node in the NG Core 5 performs bearer modification (instead of the session generation procedure) in step 1008.
  • bearer modification may be performed.
  • FIG. 11A and 11B show an example of a handover procedure of UE1 from NG System to LTE System in the configuration example of the wireless communication network shown in FIG.
  • FIG. 11A illustrates a handover preparation phase and an execution phase
  • FIG. 11B illustrates a handover completion phase.
  • the target LTE ⁇ ⁇ ⁇ ⁇ ⁇ eNB2 receives bearer setting information from the NG5Core5 in the handover completion phase (step 100) after the UE1 connects to the target LTENBeNB2.
  • the target LTELeNB2 changes the bearer setting information to NG Core5 in the handover preparation phase (step 1104) before the instruction of handover to the UE1 by the source NR NB3. Receive from. Below, this difference is mainly demonstrated.
  • Step 1101 and 1102 The processing of steps 1101 and 1102 is the same as the processing of steps 1001 and 1002 in FIG. 10A.
  • eNB2 sends a Handover * Preparation * Request message to the NG
  • the Handover Preparation Request message in step 1103 may include a handover type information element (Handover Type IE) indicating a handover from NR to LTE.
  • Handover Type IE handover type information element
  • the Handover Preparation Request message may include a list of UE1 PDU flows to be switched to the target LTE eNB2 cell.
  • NG Core 5 determines that the type of handover is an Inter-RAT handover to LTE System based on the received Handover Preparation Request message. Further, the NG Core 5 sends a Handover Preparation Request Acknowledge message including the core network information and / or security-related information to the target LTE eNB2. The core network information and the security related information are used by the target NR NB3 to implement the resource and security related settings for communicating with UE1 in the NG system.
  • the core network information may include bearer setting information (Bearer Config).
  • the bearer setting information relates to at least one EPS bearer configured for UE1.
  • the bearer setting information includes a bearer identifier (e.g., EPS EPS Bearer Identity and E-RAB ID), a forwarding node address and UL TEID in NG Core 5 and bearer QoS parameters (e.g., QCI, ARP).
  • the bearer setting information may indicate a mapping between EPS bearers and PDU flows for UE1.
  • the security related information includes the NAS security setting information of LTE System.
  • the NAS security setting information includes, for example, a NAS security algorithm including ciphering and integrity protection.
  • the NAS security setting information may be NAS Security Transparent Container IE. That is, the NAS security setting information (NAS
  • the security related information further includes security parameters used by the target LTE eNB 2 for derivation of the AS security key.
  • the security parameter is a base key (ie, LTE K eNB ) for deriving a security key (temporary key) used by the AS layer, or a parameter (eg, ⁇ NH, NCC ⁇ pair).
  • the security parameter may further include UE security capabilities related to LTE RAT or LTE System.
  • UE security capabilities indicates a ciphering and integrity protection algorithm (algorithms) implemented in UE1.
  • the target LTE eNB2 creates (creates) a UE context and allocates resources based on a Handover Preparation Request Acknowledge message including core network information or security-related information or both.
  • the target LTE eNB2 may operate as follows.
  • the security related information includes NAS security setting information (NAS Security Transparent Container IE) and security parameters for AS security.
  • the target LTE eNB2 may include NAS security setting information (NAS Security Transparent Container IE) in the transparent container sent to the UE1.
  • the target LTE eNB2 selects an AS security algorithm (ie, ciphering algorithm for ie, RRC and UP, and integrity protection algorithm for RRC) based on UE security capabilities included in the security parameters. May be. Furthermore, the target LTE eNB 2 uses the selected security algorithm to generate a base key (from the security parameters) for temporary keys for RRC ciphering (encryption), UP ciphering (encryption), and RRC integrity protection. ie, K eNB ).
  • AS security algorithm ie, ciphering algorithm for ie, RRC and UP, and integrity protection algorithm for RRC
  • the target LTE eNB2 generates a transparent container (RRCConnectionReconfiguration) sent to the UE1, and generates a Handover Command message (Handover Command to EUTRA message) that includes the transparent container.
  • the transparent container includes, for example, radio resource setting information set up by the target LTE eNB2, identifiers of AS security algorithms selected by the target LTE eNB2, and NAS security setting information.
  • the target LTE eNB2 sends a Handover Command message to the source NR NB3 on the direct inter-base station interface 101.
  • step 1108 the NG Core 5 performs a bearer session creation procedure.
  • Core 5 starts the bearer session creation procedure for UE1 in response to the reception of the HandoverHandPreparation Request message in step 1103. That is, the control node in NG
  • the bearer generation in step 1109 may be performed similarly to that in step 1008 of FIG.
  • the target LTELeNB2 sends a Path Switch Request message to the NG Core5.
  • the control node in the NG Core 5 completes the Inter-RAT Handover procedure by performing a bearer modification procedure.
  • the control node in NG Core 5 may transmit a Modify Bearer Request message for each session (i.e., PDN connection) to the S-GW.
  • the Modify Bearer Request message may include a bearer identifier (e.g., EPS Bearer ID), and the target LTE ⁇ ⁇ ⁇ ⁇ ⁇ eNB2 address and downlink (DL) TEID.
  • the S-GW may return a Modify Bearer Response message to the control node in the NG Core 5.
  • Core 5 sends a Path
  • the detailed handover procedure from the NG System to the LTE System may be, for example, the specific example described above, but is not limited thereto.
  • the message names shown in some example handover procedures described above are merely exemplary.
  • the order of the messages may be different, some messages may be omitted, or additional messages may be included.
  • This embodiment provides a handover method for UE1 from a source NR NB to a target NE NB in an NG system.
  • handover in the NG system is referred to as intra-NR handover.
  • FIG. 12 shows a configuration example of the wireless communication network according to the present embodiment.
  • the radio communication network includes UE1, NR NBs 6 and 7, and NG7Core5.
  • the NR NB 6 may be, for example, a macro base station or a pico base station.
  • the NR NB 7 may be a macro base station or a pico base station.
  • NR NBs 6 and 7 have the same level of coverage, and the two cells of NR NBs 6 and 7 partially overlap.
  • the wireless communication network according to the present embodiment may have a heterogeneous network (HetNet) structure.
  • HetNet heterogeneous network
  • NR NB6 is a macro base station
  • NR NB7 is a pico base station
  • the macrocell of NR NB6 may completely cover the picocell of NR NB7.
  • NR NB6 may be a pico base station and NR NB7 may be a macro base station.
  • NR NB6 and NR NB7 are connected by a direct base station interface 1201.
  • the direct inter-base station interface 1201 is used for transferring signaling messages at least between NR NB6 and NR NB7.
  • the direct inter-base station interface 1201 may be further used for user packet transfer between NR NB6 and NR NB7.
  • the control plane protocol structure and user plane protocol structure of the direct inter-base station interface 1201 may be the same as those of the X2 interface between LTE and eNB, for example.
  • the direct inter-base station interface 1201 is called an NG X2 interface, for example.
  • Some examples of intra-NR handover procedures are described. Some examples described below relate to UE mobility in which a connected UE1 is handed over from a source NR NB6 to a target NR NB7.
  • FIG. 13 shows an example of an intra-NR handover procedure.
  • FIG. 13 shows a case where network slicing is applied to UE1 in both the source cell / source NR NB6 and target cell / target NR NB7.
  • the procedure shown in FIG. 13 involves LTE “X2-based handover” in that it involves the transfer of handover signaling messages on the direct inter-base station interface 101 during the handover preparation phase (ie, steps 1303 and 1304). Similar to.
  • UE1 is connected to source NR NB6 and is in a connected state (i.e., RRC_Connected).
  • the UE1 is applied with network slicing in the source cell / source NR6NB6.
  • UE1 receives a measurement setting (Measurement Configuration) from NR NB6, performs neighbor cell measurement (neighborighcell measurements) according to the measurement setting, and sends a measurement report (measurement report) to NR NB6.
  • a measurement setting Measurement Configuration
  • neighbor cell measurement neighborhborighcell measurements
  • NR NB6 determines intra-NR handover to the cell of NR NB7.
  • the source NR NB6 sends an NR Handover Request message to the target NR NB7 on the direct inter-base station interface 1201.
  • the NR Handover Request message of Step 1303 is a packet flow (ie, PDU flow (s)) or a list of bearers (ie, radio access bearer (s)) (eg, PDU-Flows) to be set up in the target NR NB7.
  • To Be Setup List may be included.
  • the list indicates flow information (Flow Information) of each packet flow.
  • the flow information includes a flow identifier (eg, PDU flow ID), a forwarding node address in NG Core5 and an uplink (UL) session endpoint identifier (Session (Endpoint Identifier (SEID)), and a flow QoS parameter. .
  • the NR Handover Request message in step 1303 may include slice information (slice Information).
  • the slice information relates to one or more network slices to which UE1 is connected (used) in the source cell / source NR NB6.
  • the slice information enables the target NR NB 7 to recognize one or more network slices to which the UE 1 is connected.
  • the slice information may indicate an identifier (e.g., NSI-ID, NF IDs, MDD) of each network slice to which UE1 is connected.
  • the slice information may indicate a UE identifier assigned to UE1 by CP NFs (or a control node corresponding to MME) associated with each network slice.
  • the UE identifier may be an identifier corresponding to the LTE MME UE S1AP ID.
  • a plurality of UE identifiers respectively corresponding to the plurality of network slices may be assigned to UE1.
  • the target NR NB7 creates (creates) a UE context based on the NR Handover Request message and allocates resources.
  • the target NR NB 7 may determine allowed PDU flows based on the received flow information (e.g., PDU-Flows To Be Setup List).
  • the target NR NB 7 recognizes one or more network slices to which the UE 1 is connected based on the received slice information, and recognizes CP NFs (or a control node corresponding to the MME) of each network slice. Good.
  • the target NR NB 7 generates a transparent container (RRCConnectionReconfiguration) sent to the UE1, and generates an NR Handover Request Acknowledge message (Handover Command to NR message) that includes the transparent container.
  • the target NR NB7 sends an NR Handover Request Acknowledge message to the source NR NB6 on the direct inter-base station interface 1201.
  • the transparent container includes, for example, radio resource setting information set up by the target NR NB7.
  • the NR Handover Request Acknowledge message may further include the “PDU-flows Admitted list” information element (IE) described above.
  • the source LTE eNB2 starts data forwarding for the flow (PDU flow (s)) specified by the "PDU-flows Admitted list” IE.
  • the source NR NB6 sends an NR RRC Connection Reconfiguration message to UE1.
  • the RRC Connection Reconfiguration message includes “MobilityControlInfoNR” IE.
  • the “MobilityControlInfoNR” IE is generated by the target NR NB7, and informs the UE1 of settings and information necessary for accessing the target cell / target NR NB7.
  • Step 1306 UE1 moves from the source cell / source NR NB6 to the target cell / target NR NB7 in response to receiving the NR RRC Connection Reconfiguration message.
  • step 1307 UE1 successfully synchronizes with the target cell, and then sends an NR RCC Connection Reconfiguration Complete message containing the Handover Confirm for NR message to the target NR NB7.
  • the Handover Confirm for NR message or NR RRC Connection Reconfiguration Complete message may include network slice support information (network slice assistance information) or slice configuration information (slice configuration).
  • step 1308 when UE1 successfully accesses target NR NB7, target NR NB7 sends an NR Path Switch Request message NG to inform UE1 that the cell has been changed and to request a path switch. Send to Core5.
  • the NR Path Switch Request message may include a list of bearers (i.e., E-RAB) or packet flows (i.e., PDU flow (s)) of UE1 switched to the cell of the target NR NB7. More specifically, the NR Path Switch Request message may include “E-RAB / Flow to be switched in Downlink (DL) List” IE.
  • the NR Path Switch Request message in step 1308 may include slice information. The slice information indicates one or more network slices that the UE1 desires to connect (use) in the target cell / target NR NB7.
  • NG Core 5 performs a flow modification procedure.
  • the control node in the NG Core 5 may send a Modify Flow Request message for each session (i.e., PDU session) to the forwarding node in the NG Core 5.
  • the Modify Flow Request message may include a flow identifier (e.g., PDU flow ID), and the target NR NB3 address and downlink (DL) session endpoint identifier (SEID).
  • SEID may be, for example, Tunnel Endpoint Identifier (TEID).
  • Core 5 may return a Modify
  • step 1310 the control node in the NG Core 5 sends an NR Path Switch Request Acknowledge message to the target NR NB3.
  • the NR Path Switch Request Request Acknowledge message includes "E-RAB / Flow Switch to Switch Up Link (UL) List IE" May be.
  • the “E-RAB / Flow-to-be-switched-in-UL-List” IE is a new uplink transport layer address and endpoint identifier for each bearer (ie, E-RAB) or flow (ie, PDU-flow) Indicates. If the NG System supports bearer-based transfer of user data, the control node in the NG Core 5 may perform a bearer modification procedure in step 1310 instead of the session generation procedure.
  • the control node of NG Core5 may decide to change the network slice for UE1, and no network slice is permitted to UE1. May be determined.
  • the NR Path Switch Request Acknowledge message at step 1310 may include Slice IE indicating the network slice for the modified UE1.
  • the NR Path Switch Request Acknowledge message in step 1310 may indicate that no network slice is allowed for UE1.
  • the target NR NB3 may send an NR DL Information Transfer message carrying the NAS information (e.g., Slice information IE) received from the NG Core 5 to the UE1.
  • NAS information e.g., Slice information IE
  • FIG. 14 shows an example of an intra-NR handover procedure.
  • the handover procedure shown in FIG. 14 is a detail and modification of the handover procedure shown in FIG. 13, and specifically describes the configuration in NG Core 5 and the signaling in NG Core 5.
  • the specific configuration of the NG Core 5 shown in FIG. 14 is the same as that shown in FIG. In other words, the NG Core 5 includes Common NFs 51, NFs for slice A52, NFs for slice B53, and HSS54.
  • Step 1401 corresponds to step 1301 in FIG.
  • slice A and slice B are selected for UE1.
  • Step 1402 corresponds to steps 1302 to 1307 in FIG. 13 and includes a handover preparation phase and a handover execution phase.
  • FIG. 14 shows case A (steps 1403 to 1406) and case B (steps 1407 to 1410).
  • CP NFs e.g., Session Management Function (SMF) or Mobility Management Function (MMF)
  • SMF Session Management Function
  • MMF Mobility Management Function
  • the CP NFs e.g., SMF or MMF
  • the flow correction or bearer correction
  • Step 1403 corresponds to step 1308 in FIG.
  • the target NR NB7 sends an NR Path Switch Request message to the Common NFs 51.
  • the NR Path Switch Request message may include “E-RAB / Flow to be switched in Downlink (DL) List” IE.
  • the NR Path Switch Request message may include slice information. The slice information indicates one or more network slices that the UE1 desires to connect (use) in the target cell / target NR NB7.
  • Steps 1404 and 1405 correspond to step 1309 in FIG.
  • the CP NFs of Common NFs51 triggers flow correction (or bearer correction) on NFs for slice A52 and NFs for slice B53.
  • Step 1406 corresponds to step 1310 in FIG.
  • NFs51 sends NR
  • the NR / Path / Switch / Request / Acknowledge message may include “E-RAB / Flow / be / switched / in / UL / List” IE.
  • Step 1407 corresponds to step 1308 in FIG.
  • the NR NB3 receives the CP NFs (ie, NFs for slice A52 of CP NFs and Fs for slice) of one or more network slices that the UE1 wishes to connect (use) in the target cell / target NR NB7.
  • CP NFs ie, NFs for slice A52 of CP NFs and Fs for slice
  • NR Path Switch Request message is sent to each of B53 CP (NFs).
  • the target NR NB7 determines (selects) one or more network slices to which the NR Handover Request message should be sent based on the slice information contained in the NR Handover Request message (steps 1402, 1303) received from the source NR NB6.
  • the target NR NB7 sends an NR Handover Request message based on the network slice support information or slice information included in the NR RRC Connection Reconfiguration Complete message (or Handover Confirm for NR message) received from the UE1.
  • One or more network slices to be determined may be determined (selected).
  • Steps 1408 and 1409 correspond to step 1309 in FIG.
  • NFs for slice A52 performs flow correction (or bearer correction) in slice A.
  • NFs for slice B53 executes flow correction (or bearer correction) in slice B.
  • Step 1410 corresponds to step 1310 in FIG.
  • CP NFs of NFs for slice A52 and CP NFs of Fs for slice B53 each send an NR Path Switch Request Acknowledge message to the target NR NB7.
  • FIG. 15 shows an example of an intra-NR handover procedure.
  • FIG. 15 shows a case where network slicing is not applied to UE1 in source cell / source NR NB6, but network slicing is applied to UE1 in target cell / target NR NB7.
  • step 1501 UE1 is connected to the source NR NB6 and is in a connected state (i.e., RRC_Connected). The UE1 is not applied with network slicing in the source cell / source NR NB6.
  • Steps 1502 to 1507 are basically the same as steps 1302 to 1507 in FIG.
  • the NR Handover Request message in step 1503 may not include slice information.
  • the NR RRC Connection Reconfiguration Complete message (or Handover Confirm for NR message) in step 1507 may include network slice support information.
  • the network slice support information may be NAS information (NAS information) or RRC information (RRC information).
  • Steps 1508 to 1510 are a handover completion phase and are basically the same as steps 1308 to 1510 in FIG. However, in step 1509, NG Core 5 further executes slice selection for UE1.
  • the NR Path Switch Request message in Step 1508 may include network slice support information sent from the UE 1.
  • the NR Path Switch Request Acknowledge message in step 1510 may include slice information.
  • the slice information relates to one or more network slices selected for UE1 by NG Core5.
  • Step 1511 corresponds to step 1311 in FIG.
  • Transfer message of step 1511 may carry the slice information sent from NG
  • FIG. 16 shows an example of an intra-NR handover procedure.
  • the handover procedure shown in FIG. 16 is a detail and modification of the handover procedure shown in FIG. 15, and specifically describes the configuration in NG Core 5 and the signaling in NG5Core 5.
  • the specific configuration of the NG Core 5 shown in FIG. 16 is the same as that shown in FIG.
  • Step 1601 corresponds to step 1501 in FIG.
  • Step 1602 corresponds to steps 1502 to 1507 in FIG. 15, and includes a handover preparation phase and a handover execution phase.
  • UE1 may send network slice support information to target NR NB7 during step 1602 or before step 1602.
  • UE1 may send the network slice support information using an NR RRC Connection Reconfiguration Complete message (or Handover Confirm for NR message).
  • Step 1603 corresponds to step 1308 in FIG.
  • the target NR NB 7 sends an NR Path Switch Request message to the Common NFs 51.
  • the NR Path Switch Request message may include “E-RAB / Flow to be switched in Downlink (DL) List” IE.
  • the NR Path Switch Request message may include network slice support information.
  • the Common NFs 51 performs authentication of UE1 as necessary.
  • the authentication includes confirmation of an authorized slice (slice authorization) for UE1.
  • slice authorization Common NFs 51 may determine / determine whether or not UE1 is permitted for each slice.
  • FIG. 16 shows the service (services (s)) when at least one network slice is granted to UE1, or at least one network slice is ongoing or requested by UE1. The case where it is applicable (applicable) is shown. Accordingly, in step 1605, the Common NFs 51 performs slice selection. In the example of FIG. 16, Common NFs 51 selects slice A for UE1. The slice selection in step 1605 may be performed for each service (e.g., EPS bearer / E-RAB, IP flow) performed by UE1 (ongoing) or requested (request). The slice selection in step 1605 may be performed by an SSF arranged away from the Common NFs 51.
  • service e.g., EPS bearer / E-RAB, IP flow
  • Step 1606 corresponds to Step 1509 in FIG.
  • Common NFs 51 communicates with NFsNFfor Slice A52 of the slice selected for UE1 (here, slice A) to perform flow modification (or bearer modification).
  • Common NFs 51 and NFs for Slice A 52 transfer the UE 1 packet flow (ie, PDU flow (s)) or the bearer uplink and downlink transfer points from the common network slice (ie, Common NFs 51) to slice A (ie, , NFs for slice A52).
  • Step 1607 corresponds to step 1510 in FIG.
  • the Common NFs 51 sends the NR Path Switch Request Acknowledge message to the target NR NB7.
  • CP NFs NFs for slice A52
  • the NR Path-Switch Request-Acknowledge message in step 1607 may include "E-RAB / Flow-to-be-switched-in-UL List" IE.
  • the NR Path Switch Request Acknowledge message in Step 1607 may include slice information.
  • the slice information enables the target NR NB 7 to recognize one or more network slices selected by the NG Core 5 for the UE1.
  • the slice information may indicate an identifier (e.g., NSI-ID, NF IDs, MDD) of each network slice.
  • the slice information may indicate a UE identifier assigned to UE1 by CP NFs (or a control node corresponding to MME) associated with each network slice.
  • the UE identifier may be an identifier corresponding to the LTE MME UE S1AP ID.
  • a plurality of UE identifiers respectively corresponding to the plurality of network slices may be assigned to UE1.
  • Step 1608 corresponds to step 1511 in FIG.
  • the NR DL Information Transfer message may carry all or part of the slice information sent from the NG Core 5.
  • FIG. 17 shows an example of an intra-NR handover procedure.
  • FIG. 17 shows a case where network slicing is applied to UE1 in the source cell / source NR NB6, but network slicing is not applied to UE1 in the target cell / target NR NB7.
  • step 1701 as in step 1301 of FIG. 13, UE1 is applied with network slicing in the source cell / source NR NB6.
  • the processing in steps 1702 to 1711 is the same as the processing in steps 1302 to 1311 in FIG.
  • step 1709 NG Core 5 determines that network slicing is not applied to UE1 in the target cell / target NR NB7, and sets the packet flow of UE1 or the uplink and downlink transfer points of bearers to slices A and B (ie , NFs for slice A52 and NFs for slice B53) to the common network slice (ie, Common NFs51).
  • the NR Path Switch Request Acknowledge message in step 1710 may include information that explicitly or implicitly indicates that network slicing is not applied to UE1.
  • the NR DL Information Transfer message in step 1711 may also include information that explicitly or implicitly indicates that network slicing is not applied to UE1.
  • FIG. 18 shows an example of an intra-NR handover procedure.
  • the handover procedure shown in FIG. 18 is a detail and modification of the handover procedure shown in FIG. 17, and specifically describes the configuration in NG Core 5 and the signaling in NG5Core 5.
  • the specific configuration of NG Core 5 shown in FIG. 18 is the same as that shown in FIG.
  • the processing in steps 1801 to 1803 is the same as the processing in steps 1401 to 1403 in FIG.
  • the Common NFs 51 performs authentication of the UE1 as necessary.
  • the authentication includes confirmation of an authorized slice (slice authorization) for UE1.
  • slice authorization Common NFs 51 may determine / determine whether or not UE1 is permitted for each slice.
  • Common NFs 51 is not applicable to services (services (s)) that either network slice is not allowed by UE1, or that any network slice is ongoing or requested by UE1 (Not applicable) is determined.
  • Steps 1805 and 1806 correspond to step 1709 in FIG.
  • the CP NFs of Common NFs51 moves the UE1 packet flow or bearer uplink and downlink transfer points from slices A and B (ie, NFs for slice A52 and NFs for slice B53) to the common network slice ( ie, Common NFs51), the flow correction (or bearer correction) is triggered to NFs for slice A52 and NFs for slice B53.
  • Steps 1807 and 1808 correspond to steps 1710 and 1711 in FIG.
  • the Common / NFs 51 sends an NR / Path / Switch / Request / Acknowledge message to the target NR / NB7.
  • the target NR NB7 sends an NR DL Information Transfer message to UE1.
  • the NR Path Switch Request Acknowledge message and NR DL Information Transfer message may include information that explicitly or implicitly indicates that network slicing is not applied to UE1.
  • Intra-NR handover procedures described in this embodiment enable handover of UE1 in a wireless communication network that supports network slicing.
  • some Intra-NR handover procedures described with reference to FIG. 15 to FIG. 18 indicate that UE1 in the case where network slicing is not applied to one of the source cell / source NR NB6 and target cell / target NR NB7. Can be handed over.
  • FIG. 19 is a block diagram illustrating a configuration example of UE1.
  • the LTE transceiver 1901 performs analog RF signal processing related to the LTE-RAT PHY layer in order to communicate with the LTE-eNB2.
  • Analog RF signal processing performed by LTE transceiver 1901 includes frequency up-conversion, frequency down-conversion, and amplification.
  • LTE transceiver 1901 is coupled with antenna 1902 and baseband processor 1905.
  • the LTE transceiver 1901 receives modulation symbol data (or OFDM symbol data) from the baseband processor 1905, generates a transmission RF signal, and supplies the transmission RF signal to the antenna 1902. Also, the LTE transceiver 1901 generates a baseband received signal based on the received RF signal received by the antenna 1902 and supplies this to the baseband processor 1905.
  • modulation symbol data or OFDM symbol data
  • the New Radio (NR) transceiver 1903 performs analog RF signal processing on the PHY layer of NG RAT in order to communicate with the NR NB3.
  • New 5G transceiver 1903 is coupled with antenna 1904 and baseband processor 1905.
  • the baseband processor 1905 performs digital baseband signal processing (data plane processing) and control plane processing for wireless communication.
  • Digital baseband signal processing consists of (a) data compression / decompression, (b) data segmentation / concatenation, (c) ⁇ transmission format (transmission frame) generation / decomposition, and (d) transmission path encoding / decoding.
  • E modulation (symbol mapping) / demodulation
  • IFFT Inverse Fast Fourier Transform
  • control plane processing includes layer 1 (eg, transmission power control), layer 2 (eg, wireless link control, hybrid automatic response request (HARQ) processing), and layer 3 (eg, attachment, mobility, and packet communication). Communication management).
  • the digital baseband signal processing by the baseband processor 1905 includes signal processing of the Packet Data Convergence Protocol (PDCP) layer, Radio Link Control (RLC) layer, MAC layer, and PHY layer. But you can.
  • the control plane processing by the baseband processor 1905 may include Non-Access-Stratum (NAS) protocol, RRC protocol, and MAC CE processing.
  • NAS Non-Access-Stratum
  • the baseband processor 1905 includes a modem processor (eg, Digital Signal Processor (DSP)) that performs digital baseband signal processing and a protocol stack processor (eg, Central Processing Unit (CPU), or Micro Processing Unit that performs control plane processing. (MPU)).
  • DSP Digital Signal Processor
  • MPU Micro Processing Unit that performs control plane processing.
  • a protocol stack processor that performs control plane processing may be shared with an application processor 1906 described later.
  • the application processor 1906 is also called a CPU, MPU, microprocessor, or processor core.
  • the application processor 1906 may include a plurality of processors (a plurality of processor cores).
  • the application processor 1906 executes a system software program (Operating System (OS)) and various application programs (for example, a communication application for obtaining metering data or sensing data) read from the memory 1908 or a memory (not shown). By doing so, various functions of UE1 are realized.
  • OS Operating System
  • the baseband processor 1905 and the application processor 1906 may be integrated on a single chip, as shown by the dashed line (1907) in FIG.
  • the baseband processor 1905 and the application processor 1906 may be implemented as one System on Chip (SoC) device 1907.
  • SoC System on Chip
  • An SoC device is sometimes called a system Large Scale Integration (LSI) or chipset.
  • the memory 1908 is a volatile memory, a nonvolatile memory, or a combination thereof.
  • the memory 1908 may include a plurality of physically independent memory devices.
  • the volatile memory is, for example, Static Random Access Memory (SRAM), Dynamic RAM (DRAM), or a combination thereof.
  • the non-volatile memory is a mask Read Only Memory (MROM), Electrically Erasable Programmable ROM (EEPROM), flash memory, hard disk drive, or any combination thereof.
  • the memory 1908 may include an external memory device accessible from the baseband processor 1905, the application processor 1906, and the SoC 1907.
  • Memory 1908 may include an embedded memory device integrated within baseband processor 1905, application processor 1906, or SoC 1907.
  • the memory 1908 may include a memory in a Universal Integrated Circuit Card (UICC).
  • UICC Universal Integrated Circuit Card
  • the memory 1908 may store one or a plurality of software modules (computer programs) 1909 including an instruction group and data for performing processing by the UE 1 described in the above-described embodiments.
  • the baseband processor 1905 or the application processor 1906 may be configured to perform the processing of UE1 described in the above-described embodiment by reading the software module 1909 from the memory 1908 and executing it. .
  • FIG. 20 is a block diagram illustrating a configuration example of LTE eNB2 according to the above-described embodiment.
  • LTE eNB 2 includes an LTE transceiver 2001, a network interface 2003, a processor 2004, and a memory 2005.
  • the LTE transceiver 2001 performs analog RF signal processing to communicate with UEs supporting LTE RAT including UE1.
  • the LTE transceiver 2001 may include multiple transceivers.
  • LTE transceiver 2001 is coupled with antenna 2002 and processor 2004.
  • the LTE transceiver 2001 receives modulation symbol data (or OFDM symbol data) from the processor 2004, generates a transmission RF signal, and supplies the transmission RF signal to the antenna 2002.
  • the LTE transceiver 2001 generates a baseband reception signal based on the received RF signal received by the antenna 2002, and supplies this to the processor 2004.
  • the network interface 2003 is used to communicate with network nodes (e.g., eaves control node and forwarding node).
  • the network interface 2003 may include, for example, a network interface card (NIC) compliant with IEEE 802.3 series.
  • NIC network interface card
  • the processor 2004 performs digital baseband signal processing (data plane processing) and control plane processing for wireless communication.
  • the digital baseband signal processing by the processor 2004 may include PDCP layer, RLC layer, MAC layer, and PHY layer signal processing.
  • the control plane processing by the processor 2004 may include S1 protocol, RRC protocol, and MAC-CE processing.
  • the processor 2004 may include a plurality of processors.
  • the processor 2004 may include a modem processor (e.g., DSP) that performs digital baseband signal processing and a protocol stack processor (e.g., CPU or MPU) that performs control plane processing.
  • DSP digital baseband signal processing
  • protocol stack processor e.g., CPU or MPU
  • the memory 2005 is configured by a combination of a volatile memory and a nonvolatile memory.
  • the volatile memory is, for example, SRAM or DRAM or a combination thereof.
  • the non-volatile memory is, for example, an MROM, PROM, flash memory, hard disk drive, or a combination thereof.
  • Memory 2005 may include storage located remotely from processor 2004. In this case, the processor 2004 may access the memory 2005 via the network interface 2003 or an I / O interface not shown.
  • the memory 2005 may store one or a plurality of software modules (computer programs) 2006 including an instruction group and data for performing processing by the LTE eNB 2 described in the above-described embodiments.
  • the processor 2004 may be configured to read and execute the one or more software modules 2006 from the memory 2005 to perform the LTE eNB2 processing described in the above embodiment.
  • FIG. 21 is a block diagram illustrating a configuration example of the NR NB 3 according to the above-described embodiment.
  • NR NBs 6 and 7 may also have the configuration of FIG.
  • NR NB 3 includes New Radio (NR) transceiver 2101, network interface 2103, processor 2104, and memory 2105.
  • the NR transceiver 2101 performs analog RF signal processing to communicate with UEs that support NG RAT including UE1.
  • the NR transceiver 2101 may include a plurality of transceivers.
  • NR transceiver 2101 is coupled to antenna 2102 and processor 2104.
  • the NR transceiver 2101 receives the modulation symbol data from the processor 2104, generates a transmission RF signal, and supplies the transmission RF signal to the antenna 2102. Further, the NR transceiver 2101 generates a baseband received signal based on the received RF signal received by the antenna 2102, and supplies this to the processor 2104.
  • the network interface 2103 is used to communicate with a network node (e.g., control node and transfer node in NG Core 5).
  • the network interface 2103 may include, for example, a network interface card (NIC) compliant with IEEE 802.3 series.
  • NIC network interface card
  • the processor 2104 performs digital baseband signal processing (data plane processing) and control plane processing for wireless communication.
  • the processor 2104 may include a plurality of processors.
  • the processor 2104 may include a modem processor (e.g., DSP) that performs digital baseband signal processing and a protocol stack processor (e.g., CPU or MPU) that performs control plane processing.
  • DSP digital baseband signal processing
  • protocol stack processor e.g., CPU or MPU
  • the memory 2105 is configured by a combination of a volatile memory and a nonvolatile memory.
  • the volatile memory is, for example, SRAM or DRAM or a combination thereof.
  • the non-volatile memory is, for example, an MROM, PROM, flash memory, hard disk drive, or a combination thereof.
  • Memory 2105 may include storage located remotely from processor 2104. In this case, the processor 2104 may access the memory 2105 via the network interface 2103 or an I / O interface not shown.
  • the memory 2105 may store one or a plurality of software modules (computer programs) 2106 including an instruction group and data for performing processing by the NR NB 3 described in the above-described embodiments.
  • the processor 2104 may be configured to read and execute the one or more software modules 2106 from the memory 2105 to perform the NR NB3 processing described in the above embodiment.
  • FIG. 22 is a block diagram illustrating a configuration example of the core network node 2200 according to the above-described embodiment.
  • the core network node 2200 is, for example, a control node (e.g., Common NFs51) in the NG Core5.
  • the core network node 2200 includes a network interface 2201, a processor 2202, and a memory 2203.
  • the network interface 2201 is used to communicate with network nodes (e.g., RAN nodes, other core network nodes).
  • the network interface 2201 may include, for example, a network interface card (NIC) compliant with IEEE 802.3 series.
  • NIC network interface card
  • the processor 2202 may be, for example, a microprocessor, MPU, or CPU.
  • the processor 2202 may include a plurality of processors.
  • the memory 2203 is configured by a combination of a volatile memory and a nonvolatile memory.
  • the volatile memory is, for example, SRAM or DRAM or a combination thereof.
  • the non-volatile memory is, for example, an MROM, PROM, flash memory, hard disk drive, or a combination thereof.
  • Memory 2203 may include storage located remotely from processor 2202. In this case, the processor 2202 may access the memory 2203 via the network interface 2201 or an I / O interface not shown.
  • the memory 2203 is one or a plurality of software modules (computer programs) 2204 including a group of instructions and data for performing processing by the core network node (eg, control node in the NG Core 5) described in the above-described embodiments. May be stored.
  • the processor 2202 may be configured to read and execute the one or more software modules 2204 from the memory 2203 to perform the core network node processing described in the above embodiments. .
  • each of the processors included in UE1, LTELNB2, NR NB3, and core network node performs the algorithm described with reference to the drawings on the computer.
  • One or a plurality of programs including a group of instructions for executing the program are executed.
  • the program can be stored and supplied to a computer using various types of non-transitory computer readable media.
  • Non-transitory computer readable media include various types of tangible storage media (tangible storage medium).
  • non-transitory computer-readable media are magnetic recording media (eg flexible disks, magnetic tapes, hard disk drives), magneto-optical recording media (eg magneto-optical discs), Compact Disc Read Only Memory (CD-ROM), CD-ROM R, CD-R / W, semiconductor memory (for example, mask ROM, Programmable ROM (PROM), Erasable PROM (EPROM), flash ROM, Random Access Memory (RAM)).
  • the program may also be supplied to the computer by various types of temporary computer-readable media. Examples of transitory computer readable media include electrical signals, optical signals, and electromagnetic waves.
  • the temporary computer-readable medium can supply the program to the computer via a wired communication path such as an electric wire and an optical fiber, or a wireless communication path.
  • FIG. 23A and FIG. 23B show an example of the format of the Mobility EUTRA command message.
  • the MobilityFromEUTRACommand message includes a purpose set to “handover” and a targetRAT-Type set to “ngutra” corresponding to NG-RAN.
  • the MobilityFromEUTRACommand message includes targetRAT-MessageContainer.
  • targetRAT-MessageContainer includes the RRCConnectionReconfigurationNR message generated by the target NR NB3.
  • targetRAT-Type is “OTHERRAN”, that is, “utra”, “geran”, or “ngutra”
  • the MobilityFromEUTRACommand message includes nas-SecurityParamFromEUTRA.
  • FIG. 24 shows an example of the format of the X3AP: NR Handover Request message sent on the direct inter-base station interface 101 (X3 interface) from the source LTE eNB2 to the target NR NB3 in step 202 of Fig. 2A and step 302 of Fig. 3A. Show.
  • This NR Handover Request message includes the identifier (i.e., Globally Unique CNF ID (GUCNFI)) of the control node (Common NF (CNF)) in the NG Core5. Further, the NR Handover Request message includes UE Context Information.
  • GUIFI Globally Unique CNF ID
  • CNF Common NF
  • FIG. 25 shows an example of the format of UE Context Information.
  • UE Context Information includes NE-RABs To Be Setup List.
  • NE-RABs To Be Setup List indicates a list of radio access bearers (NE-RABs) to be set up in the target NR NB3.
  • the format shown in FIG. 25 may be used when an NG System including NR NB3 and NG Core5 is configured to support bearer-based transfer using a bearer for each QoS class and for each PDU session.
  • the UE Context Information shown in FIG. 25 further includes an RRC Context.
  • RRC Context includes RRC Handover Preparation Information message.
  • RRC Handover Preparation Information message is used by the target NR NB3 to perform resource and security related settings for communicating with UE1 in the NG system.
  • the UE Context Information shown in FIG. 35 may include assistance information for network slicing (Assistance Data for Network Slicing).
  • eNB2 may include Assistance
  • FIG. 26 shows an example of the format of the X3AP: “NR” Handover “Request” Acknowledge message sent from the target NR NB3 to the source LTE eNB on the direct inter-base station interface 101 (X3 interface) in step 203 of FIG. 2A.
  • This NR Handover Command message includes Target to Source Transparent Container.
  • Target to Source Transparent Container includes radio resource setting information (e.g., radio parameters) generated by the target NR NB3.
  • the Target-to-Source-Transparent-Container may include an RRC-Container that contains an RRC-NG-UTRA Handover Command message.
  • the NR Handover Request Acknowledge message includes NE-RABs Admitted List.
  • NE-RABs Admitted List indicates a list of radio access bearers (NE-RABs) whose resources are prepared in the target cell.
  • FIG. 27 shows an example of the format of an X3AP: NR Handover Request Acknowledge message sent on the direct base station interface 101 (X3 interface) from the target NR ⁇ ⁇ ⁇ ⁇ ⁇ NB3 to the source LTE NB at step 305 in Fig. 3A.
  • the format shown in FIG. 27 is different from the format shown in FIG. 26 in that it includes core network context information (NG Core Context).
  • the NG Core Context may be transmitted to the UE1 transparently to the source LTE eNB2.
  • a part or all of the NG Core Context may be included in the Target To Source Transparent Container.
  • FIG. 28 shows an example of the format of NG Core Context.
  • Information includes, for example, slice information and flow information (or PDU session information).
  • FIG. 29 shows an example of the format of Slice Information.
  • Slice Information is a network slice identifier (ie, Network Slice Instance ID) determined (selected) for UE1, and a network function associated with the network slice. Or it contains the identifier of the node (ie, Network Function ID).
  • Slice Information may include type information (i.e., Multi-Dimensional Descriptor) of the network slice.
  • Slice Information may include a mobility class (Mobility Class), a session class (Session Class), or both.
  • FIG. 30 shows an example of the format of Flow Information.
  • Flow Information is at least one session established in NG system to transfer at least one packet flow (ie, PDU flow (s)) of UE1 ( ie, information on (PDU) session (information) List).
  • Flow Information includes a session identifier (e.g., PDU Session ID), an address of a transfer node in NG Core 5 (Transport Layer Address), and an uplink (UL) Session Endpoint ID (SIED).
  • FIG. 31 shows an example of the format of Session Endpoint ID.
  • Session Endpoint ID may be GTP-TEID, GRE-TEID, or a network function or node identifier (NF ID).
  • NF ID network function or node identifier
  • eNB2 may be connected to EPC (enhanced
  • the (e) MME in the eEPC may be connected to a control node (i.e., CPF node) in the NG Core 5 via a control plane interface.
  • one or a plurality of nodes in the eEPC may be connected to one or a plurality of data nodes (i.e., a UPF node) in the NG Core 5 via a user plane interface.
  • the E-URAN and NG RAN described in the above embodiment may be implemented based on the Cloud Radio Access Network (C-RAN) concept.
  • C-RAN is sometimes called Centralized RAN.
  • DU Digital Unit
  • RU Radio Unit
  • DU is called Baseband Unit (BBU) or Central Unit (CU).
  • RU is also referred to as Remote Radio Head (RRH), Remote Radio Equipment (RRE), or Distributed Unit (DU).
  • DU and RU may provide the AS layer function provided in the entire RAN separately in DU and RU.
  • DU and RU may be provided. That is, the processes and operations performed by each of the LTE eNB 2 and the NR NB 3 described in the above embodiment may be provided by any one or a plurality of radio stations (or RAN nodes).
  • NR NB 3 may be configured to dynamically change the allocation of AS layers (layers) or functions to DUs and RUs.
  • 3 may be comprised so that the separation point of AS layer (layers) or function between DU and RU can be changed dynamically.
  • the NR NB 3 may be configured such that one can be dynamically selected from a plurality of different functional separation options.
  • the NG Core 5 responds to the reception of the Handover par Preparation Required message or the NR Path Switch Request message, and the DU of the NR NB3 of the AS layer or function. You may decide to distribute to RU.
  • the NR NB3 may determine the allocation of the AS sublayer or function NR NB3 to the DU and RU.
  • the NG Core 5 or the NR NB 3 may select one function separation option applied to the NR NB 3 from a plurality of predetermined function separation options.
  • the function separation option applied to NR NB 3 is determined (selected) based on E-RAB QoS information IE, eg QCI, ARP or flow information included in the HandoverHandPreparation Required message or NR Path Switch Request message. May be.
  • the function separation option applied to NR NB 3 may be determined based on slices generated by NG Core5 or NR NB3 or information on slices (slice information). Further or alternatively, the function separation option applied to NR ⁇ NB 3 may be determined based on network slice support information included in the NAS information transmitted from UE1.
  • a UE identifier may be included in a message transmitted / received between the nodes.
  • the UE identifier is used to identify UE1 to be handed over in the handover procedure.
  • the UE identifier is a UE identifier used on an interface (eg, Sn interface or NG2 interface, where n is an integer) between the control node corresponding to the MME of NR NB3 and NG Core5. May be.
  • This UE identifier may be expressed as NR NB UE SnAP ID (NR NB UE Sn Application Protocol Identifier) or NR NB UE NG2AP ID.
  • the UE identifier may be a UE identifier used on an interface (e.g., Xn interface, n is an integer) between NR NB3 and LTE NB2.
  • This UE identifier may be expressed as NR NB UE XnAP ID.
  • the UE identifier may be a UE identifier used on an interface (eg, Sm interface, m is an integer) between a control node corresponding to the MME of NG Core 5 and the MME in EPC4. Good.
  • This UE identifier may be expressed as eMME UE SmAP ID, for example.
  • the UE identifier is used on an interface (eg, Sl interface, where l is an integer) between the control node corresponding to the MME of NG Core 5 and LTE eNB2, and is assigned by the control node. It may be an identifier.
  • the identifier of this UE may be expressed as eMME UE SlAP ID, for example.
  • these UE identifiers may be transferred between the nodes in the handover procedure.
  • Sn, NG2, Sm, Sl, and Xn for identifying each interface described above are examples, and other notations may be used.
  • RAN radio access network
  • the slice information includes (a) identification information of a network slice selected for the wireless terminal, (b) type information of a network slice selected for the wireless terminal, or (c) for the wireless terminal.
  • Appendix 3 The target RAN node according to appendix 1 or 2, wherein the slice information includes a mobility class or a session class or both supported by a network slice selected for the wireless terminal.
  • the flow information includes a flow identifier and a flow QoS parameter for each packet flow of the wireless terminal.
  • the target RAN node according to any one of appendices 1 to 3.
  • the at least one processor is configured to receive at least one of the slice information and flow information from the core network in a handover completion phase after the wireless terminal is connected to the target RAN node;
  • the target RAN node according to any one of appendices 1 to 4.
  • the handover request message includes security parameters derived by the source RAN node;
  • the at least one processor is configured to derive an Access Stratum (AS) security key from the security parameters;
  • AS Access Stratum
  • the at least one processor is configured to send a path switch request message to the core network in the handover completion phase;
  • the path switch request message triggers the core network to select or generate a network slice for the wireless terminal;
  • the target RAN node according to appendix 5 or 6.
  • the at least one processor is configured to send a path switch request message to the core network in the handover completion phase;
  • the path switch request message triggers the core network to create a bearerless session for the wireless terminal;
  • the target RAN node according to appendix 5 or 6.
  • the at least one processor is configured to transmit at least one of the slice information and flow information to the wireless terminal;
  • the target RAN node according to any one of appendices 5 to 8.
  • the at least one processor is configured to receive at least one of the slice information and flow information from the core network in a handover preparation phase prior to a handover instruction to the wireless terminal by the source RAN node. Yes, The target RAN node according to any one of appendices 1 to 4.
  • the at least one processor is configured to determine whether to accept a bearer or flow for each bearer or flow of the wireless terminal based on the slice information.
  • the target RAN node according to attachment 10.
  • the at least one processor is configured to determine whether to accept each network slice based on the slice information;
  • the target RAN node according to Supplementary Note 10 or 11.
  • the at least one processor includes, in the handover preparation phase, non-access stratum (NAS) security configuration information and security parameters used by the target RAN node for deriving an access stratum (AS) security key. Configured to receive further from the core network, The target RAN node according to any one of appendices 10 to 12.
  • NAS non-access stratum
  • AS access stratum
  • the at least one processor is configured to send a handover request acknowledge message containing a transparent container to the source RAN node over the direct interface;
  • the transparent container includes predetermined parameters included in at least one of the slice information and flow information, radio resource setting information generated based on at least one of the slice information and flow information, or both. And forwarded to the wireless terminal by the source RAN node, 14.
  • the target RAN node according to any one of appendices 10 to 13.
  • the at least one processor is configured to transmit a request message requesting transmission of at least one of the slice information and flow information to the core network in the handover preparation phase;
  • the request message triggers the core network to select or generate a network slice for the wireless terminal;
  • the target RAN node according to any one of appendices 10 to 14.
  • the at least one processor is configured to transmit a request message requesting transmission of at least one of the slice information and flow information to the core network in the handover preparation phase;
  • the request message triggers the core network to create a bearerless session for the wireless terminal;
  • the target RAN node according to any one of appendices 10 to 14.
  • a source radio access network (RAN) node associated with a first network comprising: At least one memory; At least one processor coupled to the at least one memory; With The at least one processor comprises: Configured to determine a handover of a wireless terminal from the first network to a second network; Responsive to the handover decision, configured to send a handover request message requesting a handover of a wireless terminal to the second network over a direct interface to a target RAN node in the second network; configured to receive a handover request acknowledge message containing a transparent container from the target RAN node on the direct interface; Configured to transmit a mobility command message including the transparent container and indicating a handover to the second network to the wireless terminal;
  • the transparent container includes radio resource setting information required for the radio terminal to establish a radio connection associated with the second network,
  • the radio resource setting information includes: (a) first radio resource setting information generated based on slice information related to a network slice in the second network to which the radio terminal is connected; and (b) the radio terminal At least
  • the at least one processor derives a second security parameter used in the second network from a first security parameter used in the first network, and the second security parameter is set to the handover configured to be included in the request message,
  • the second security parameter is used by the target RAN node for derivation of an Access Stratum (AS) security key in the second network; Source RAN node as described in appendix 17.
  • AS Access Stratum
  • a method in a target radio access network (RAN) node associated with a second network comprising: Receiving a handover request message requesting a handover of a wireless terminal from a first network to the second network from a source RAN node in the first network on a direct interface; In response to receiving the handover request message, receiving at least one of slice information and flow information from a core network, and communication of the wireless terminal based on at least one of the slice information and flow information To control, With The slice information relates to a network slice in the second network to which the wireless terminal is connected, The flow information relates to at least one session established in the second network as a bearerless network to transfer at least one packet flow of the wireless terminal; Method.
  • RAN radio access network
  • a method in a source radio access network (RAN) node associated with a first network comprising: Determining a handover of a wireless terminal from the first network to a second network; In response to the handover decision, sending a handover request message requesting handover of a wireless terminal to the second network over a direct interface to a target RAN node in the second network; receiving a handover request acknowledge message including a transparent container from the target RAN node on the direct interface; and a mobility command message including the transparent container and indicating a handover to the second network.
  • RAN radio access network
  • the transparent container includes radio resource setting information required for the radio terminal to establish a radio connection associated with the second network
  • the radio resource setting information includes: (a) first radio resource setting information generated based on slice information related to a network slice in the second network to which the radio terminal is connected; and (b) the radio terminal At least one of second radio resource configuration information generated based on flow information regarding at least one session established in the second network as a bearerless network to transfer at least one packet flow including, Method.
  • (Appendix 21) A program for causing a computer to perform a method in a target radio access network (RAN) node associated with a second network, The method Receiving a handover request message requesting a handover of a wireless terminal from a first network to the second network from a source RAN node in the first network on a direct interface; In response to receiving the handover request message, receiving at least one of slice information and flow information from a core network, and communication of the wireless terminal based on at least one of the slice information and flow information To control, With The slice information relates to a network slice in the second network to which the wireless terminal is connected, The flow information relates to at least one session established in the second network as a bearerless network to transfer at least one packet flow of the wireless terminal; program.
  • RAN radio access network
  • Appendix 22 A program for causing a computer to perform a method in a source radio access network (RAN) node associated with a first network, The method Determining a handover of a wireless terminal from the first network to a second network; In response to the handover decision, sending a handover request message requesting handover of a wireless terminal to the second network over a direct interface to a target RAN node in the second network; receiving a handover request acknowledge message including a transparent container from the target RAN node on the direct interface; and a mobility command message including the transparent container and indicating a handover to the second network.
  • RAN radio access network
  • the transparent container includes radio resource setting information required for the radio terminal to establish a radio connection associated with the second network
  • the radio resource setting information includes: (a) first radio resource setting information generated based on slice information related to a network slice in the second network to which the radio terminal is connected; and (b) the radio terminal At least one of second radio resource configuration information generated based on flow information regarding at least one session established in the second network as a bearerless network to transfer at least one packet flow including, program.
  • a wireless terminal At least one memory; At least one processor coupled to the at least one memory; With In the handover from the first network to the second network to which the wireless terminal is connected, the at least one processor is configured to transfer slice information regarding a network slice in the second network and a network slice in the second network.
  • a wireless terminal configured to receive a message related to handover including at least one of based radio resource configuration information from a radio access network (RAN) node of the first network.
  • RAN radio access network
  • the at least one processor comprises: Configured to receive from the RAN node a mobility command message indicating a handover from the first network to the second network, wherein the mobility command message is generated by a target RAN node associated with the second network Including radio resource setting information required for the radio terminal to establish a radio connection associated with a network slice in the second network to which the radio terminal is connected; Using the radio resource configuration information, configured to establish the radio connection with the target RAN node associated with the second network; The wireless terminal according to attachment 23.
  • the message regarding the handover further includes flow information regarding at least one session established in the second network to transfer at least one packet flow of the wireless terminal, and a radio resource setting derived from the flow information Including at least one of the information, The wireless terminal according to appendix 23 or 24.
  • a core network node At least one memory; At least one processor coupled to the at least one memory; With In the handover of a wireless terminal from a first network to a second network, the at least one processor transmits slice information regarding a network slice in the second network to which the wireless terminal is connected to the second network. Configured to send to an associated target radio access network (RAN) node; Core network node.
  • RAN radio access network
  • the at least one processor is further configured in the second network to transfer at least one packet flow of the wireless terminal in handover of the wireless terminal from the first network to the second network. Configured to send flow information about the established at least one session to the target RAN node; 27.
  • the core network node according to appendix 26.
  • the at least one processor is configured to send the slice information to the target RAN node in a handover preparation phase prior to a handover instruction to the wireless terminal by a source RAN node. 28.
  • the core network node according to appendix 26 or 27.
  • the at least one processor is configured to send the slice information to the target RAN node in a handover completion phase after the wireless terminal connects to the target RAN node.
  • the core network node according to appendix 26 or 27.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

ターゲットＲＡＮノード（３）は、第１のネットワークから第２のネットワークへの無線端末（１）のハンドオーバ要求メッセージをソースＲＡＮノード（２）からダイレクト・インタフェース（１０１）上で受信したことに応答して、コアネットワーク（５）からスライス情報及びフロー情報のうち少なくとも１つを受信し、スライス情報及びフロー情報のうち少なくとも１つに基づいて、無線端末（１）の通信を制御する。スライス情報は、第２のネットワーク内のネットワークスライスに関する。フロー情報は、無線端末（１）の少なくとも１つのパケットフローを転送するためにベアラレス・ネットワークとしての第２のネットワーク内で確立される少なくとも１つのセッションに関する。これにより、例えば、ダイレクト基地局間インタフェース上でのハンドオーバ・シグナリングメッセージの転送を伴うＲＡＴ間ハンドオーバ手順を提供できる。

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はbearer-based systemとして機能してもよく、ユーザデータのflow-based転送及びbearer-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をセットアップする。
　本件発明者等は、NG System（5G）とLTE Systemとの間のハンドオーバに関して検討を行い、いくつかの課題を見出した。例えば、特許文献１のFig. 4は、NG System（5G）からLTE Systemへのハンドオーバ手順が LTE S1-based handoverの修正（modifications）によって実現されることを記載している。しかしながら、特許文献１は、NG System（5G）とLTE Systemとの間のハンドオーバ手順が、ダイレクト基地局間インタフェース上でのハンドオーバ・シグナリングメッセージの転送を含むことを記載していない。
　したがって、本明細書に開示される実施形態が達成しようとする目的の１つは、ダイレクト基地局間インタフェース上でのハンドオーバ・シグナリングメッセージの転送を伴うInter-RATハンドオーバ手順の提供に寄与する装置、方法、及びプログラムを提供することである。なお、この目的は、本明細書に開示される複数の実施形態が達成しようとする複数の目的の１つに過ぎないことに留意されるべきである。その他の目的又は課題と新規な特徴は、本明細書の記述又は添付図面から明らかにされる。
　一態様では、第２のネットワークに関連付けられたターゲット無線アクセスネットワーク（RAN）ノードは、少なくとも１つのメモリと、前記少なくとも１つのメモリに結合された少なくとも１つのプロセッサとを含む。前記少なくとも１つのプロセッサは、第１のネットワークから前記第２のネットワークへの無線端末のハンドオーバを要求するhandover requestメッセージを前記第１のネットワーク内のソースRANノードからダイレクト・インタフェース上で受信し、前記handover requestメッセージの受信に応答してスライス情報及びフロー情報のうち少なくとも１つをコアネットワークから受信し、前記スライス情報及びフロー情報のうち少なくとも１つに基づいて、前記無線端末の通信を制御するよう構成される。前記スライス情報は、前記無線端末が接続する前記第２のネットワーク内のネットワークスライスに関する。前記フロー情報は、前記無線端末の少なくとも１つのパケットフローを転送するためにベアラレス・ネットワークとしての前記第２のネットワーク内で確立される少なくとも１つのセッションに関する。
　一態様では、第１のネットワークに関連付けられたソース無線アクセスネットワーク（RAN）ノードは、少なくとも１つのメモリと、前記少なくとも１つのメモリに結合された少なくとも１つのプロセッサとを含む。前記少なくとも１つのプロセッサは、前記第１のネットワークから第２のネットワークへの無線端末のハンドオーバを決定するよう構成され、前記ハンドオーバの決定に応答して、前記第２のネットワークへの無線端末のハンドオーバを要求するhandover requestメッセージを前記第２のネットワーク内のターゲットRANノードにダイレクト・インタフェース上で送信するよう構成される。前記少なくとも１つのプロセッサは、さらに、transparent containerを包含するhandover request acknowledgeメッセージを、前記ダイレクト・インタフェース上で前記ターゲットRANノードから受信するよう構成され、前記transparent containerを包含し且つ前記第２のネットワークへのハンドオーバを示すmobility commandメッセージを前記無線端末に送信するよう構成される。前記transparent containerは、前記第２のネットワークに関連付けられた無線コネクションを確立するために前記無線端末にとって必要となる無線リソース設定情報を含む。前記無線リソース設定情報は、（ａ）前記無線端末が接続する前記第２のネットワーク内のネットワークスライスに関するスライス情報に基づいて生成された第１の無線リソース設定情報、及び（ｂ）前記無線端末の少なくとも１つのパケットフローを転送するためにベアラレス・ネットワークとしての前記第２のネットワーク内で確立される少なくとも１つのセッションに関するフロー情報に基づいて生成された第２の無線リソース設定情報のうち少なくとも１つを含む。
　一態様では、無線端末は、少なくとも１つのメモリと、前記少なくとも１つのメモリに結合された少なくとも１つのプロセッサとを含む。前記少なくとも１つのプロセッサは、前記無線端末が接続する第１のネットワークから第２のネットワークへのハンドオーバにおいて、前記第２のネットワーク内のネットワークスライスに関するスライス情報及び前記第２のネットワーク内のネットワークスライスに基づく無線リソース設定情報の少なくとも一方を包含するハンドオーバに関するメッセージを前記第１のネットワークの無線アクセスネットワーク（RAN）ノードから受信するよう構成される。
　一態様では、コアネットワークノードは、少なくとも１つのメモリと、前記少なくとも１つのメモリに結合された少なくとも１つのプロセッサとを含む。前記少なくとも１つのプロセッサは、第１のネットワークから第２のネットワークへの無線端末のハンドオーバにおいて、前記無線端末が接続される前記第２のネットワーク内のネットワークスライスに関するスライス情報を前記第２のネットワークに関連付けられたターゲット無線アクセスネットワーク（RAN）ノードに送るよう構成される。
　一態様では、第２のネットワークに関連付けられたターゲット無線アクセスネットワーク（RAN）ノードにおける方法は、
　第１のネットワークから前記第２のネットワークへの無線端末のハンドオーバを要求するhandover requestメッセージを前記第１のネットワーク内のソースRANノードからダイレクト・インタフェース上で受信すること、
　前記handover requestメッセージの受信に応答して、スライス情報及びフロー情報のうち少なくとも１つをコアネットワークから受信すること、及び
　前記スライス情報及びフロー情報のうち少なくとも１つに基づいて、前記無線端末の通信を制御すること、
を含む。前記スライス情報は、前記無線端末が接続する前記第２のネットワーク内のネットワークスライスに関する。前記フロー情報は、前記無線端末の少なくとも１つのパケットフローを転送するためにベアラレス・ネットワークとしての前記第２のネットワーク内で確立される少なくとも１つのセッションに関する。
　一態様では、第１のネットワークに関連付けられたソース無線アクセスネットワーク（RAN）ノードにおける方法は、
　前記第１のネットワークから第２のネットワークへの無線端末のハンドオーバを決定すること、
　前記ハンドオーバの決定に応答して、前記第２のネットワークへの無線端末のハンドオーバを要求するhandover requestメッセージを前記第２のネットワーク内のターゲットRANノードにダイレクト・インタフェース上で送信すること、
　transparent containerを包含するhandover request acknowledgeメッセージを、前記ダイレクト・インタフェース上で前記ターゲットRANノードから受信すること、及び
　前記transparent containerを包含し且つ前記第２のネットワークへのハンドオーバを示すmobility commandメッセージを前記無線端末に送信すること、
を含む。前記transparent containerは、前記第２のネットワークに関連付けられた無線コネクションを確立するために前記無線端末にとって必要となる無線リソース設定情報を含む。前記無線リソース設定情報は、（ａ）前記無線端末が接続する前記第２のネットワーク内のネットワークスライスに関するスライス情報に基づいて生成された第１の無線リソース設定情報、及び（ｂ）前記無線端末の少なくとも１つのパケットフローを転送するためにベアラレス・ネットワークとしての前記第２のネットワーク内で確立される少なくとも１つのセッションに関するフロー情報に基づいて生成された第２の無線リソース設定情報のうち少なくとも１つを含む。
　一態様では、プログラムは、コンピュータに読み込まれた場合に、上述の態様に係る方法をコンピュータに行わせるための命令群（ソフトウェアコード）を含む。
　上述の態様によれば、ダイレクト基地局間インタフェース上でのハンドオーバ・シグナリングメッセージの転送を伴うInter-RATハンドオーバ手順の提供に寄与する装置、方法、及びプログラムを提供できる。
いくつかの実施形態に係る無線通信ネットワークの構成例を示す図である。 第１の実施形態に係る、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により行われる方法の一例を示すフローチャートである。 第１の実施形態に係るコアネットワークにより行われる方法の一例を示すフローチャートである。 第１の実施形態に係る無線端末により行われる方法の一例を示すフローチャートである。 第２の実施形態に係る、LTE SystemからNG Systemへのinter-RATハンドオーバ手順の一例を示すシーケンス図である。 第２の実施形態に係る、LTE SystemからNG Systemへのinter-RATハンドオーバ手順の一例を示すシーケンス図である。 第２の実施形態に係る、LTE SystemからNG Systemへのinter-RATハンドオーバ手順の一例を示すシーケンス図である。 第３の実施形態に係る、NG SystemからLTE Systemへのinter-RATハンドオーバ手順の一例を示すシーケンス図である。 第３の実施形態に係る、NG SystemからLTE Systemへのinter-RATハンドオーバ手順の一例を示すシーケンス図である。 第３の実施形態に係る、NG SystemからLTE Systemへのinter-RATハンドオーバ手順の一例を示すシーケンス図である。 第３の実施形態に係る、NG SystemからLTE Systemへのinter-RATハンドオーバ手順の一例を示すシーケンス図である。 第４の実施形態に係る無線通信ネットワークの構成例を示す図である。 第４の実施形態に係る、intra-NRハンドオーバ手順の一例を示すシーケンス図である。 第４の実施形態に係る、intra-NRハンドオーバ手順の一例を示すシーケンス図である。 第４の実施形態に係る、intra-NRハンドオーバ手順の一例を示すシーケンス図である。 第４の実施形態に係る、intra-NRハンドオーバ手順の一例を示すシーケンス図である。 第４の実施形態に係る、intra-NRハンドオーバ手順の一例を示すシーケンス図である。 第４の実施形態に係る、intra-NRハンドオーバ手順の一例を示すシーケンス図である。 幾つかの実施形態に係る無線端末の構成例を示すブロック図である。 幾つかの実施形態に係る基地局の構成例を示すブロック図である。 幾つかの実施形態に係る基地局の構成例を示すブロック図である。 幾つかの実施形態に係るコアネットワークノードの構成例を示すブロック図である。 Mobility from EUTRA commandメッセージのフォーマットの一例を示す図である。 Mobility from EUTRA commandメッセージのフォーマットの一例を示す図である。 NR Handover Requestメッセージのフォーマットの一例を示す図である。 UE Context Informationのフォーマットの一例を示す図である。 NR Handover Request Acknowledgeメッセージのフォーマットの一例を示す図である。 NR Handover Request Acknowledgeメッセージのフォーマットの一例を示す図である。 NG Core Contextのフォーマットの一例を示す図である。 Slice Informationのフォーマットの一例を示す図である。 Flow Informationのフォーマットの一例を示す図である。 Session Endpoint IDのフォーマットの一例を示す図である。
　以下では、具体的な実施形態について、図面を参照しながら詳細に説明する。各図面において、同一又は対応する要素には同一の符号が付されており、説明の明確化のため、必要に応じて重複説明は省略される。
　以下に説明される複数の実施形態は、独立に実施されることもできるし、適宜組み合わせて実施されることもできる。これら複数の実施形態は、互いに異なる新規な特徴を有している。したがって、これら複数の実施形態は、互いに異なる目的又は課題を解決することに寄与し、互いに異なる効果を奏することに寄与する。
＜第１の実施形態＞
　図１は、本実施形態を含む幾つかの実施形態に係る無線通信ネットワークの構成例を示している。図１の例では、無線通信ネットワークは、無線端末（UE）１、LTE基地局（i.e., eNB）２、New Radio (NR) 基地局（i.e., NR NodeB (NR NB)）３、及びNextGen (NG) Core５を含む。LTE eNB２は、NG Core５に接続されている。すなわち、LTE eNB２は、コントロールプレーン・インタフェース（e.g., NG2インタフェース）を介してNG Core５内のMME又はMMEの機能の少なくとも一部を有する制御ノード（i.e., Control Plane Function (CPF)ノード）に接続され、ユーザプレーン・インタフェース（e.g., NG3インタフェース）を介してNG Core５内のServing Gateway（S-GW）又はS-GWの機能の少なくとも一部を有するデータノード（i.e., User Plane Function (UPF)ノード）に接続される。このようにLTE eNB２は、NG Core５と接続されるよう改良（enhanced）されていて、eLTE eNBと呼ばれてもよい。
　同様に、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）を介して行われてもよい。
　幾つかの実装において、NG Core５は、論理的なEPCノード（nodes）及びEPC機能（functions）を提供する仮想化されたネットワークスライスをセットアップしてもよい。幾つかの実装において、LTE eNB２を含むE-UTRAN及びNR NB３を含むNG RANは、同じネットワークスライスに接続されもよい。これに代えて、LTE eNB２を含むE-UTRAN及びNR NB３を含むNG RANは、互いに異なるネットワークスライスに接続されてもよい。UE１は、LTE eNB２及びNG Core５によって提供されるLTEシステムに接続する能力を有し、且つNR NB３及びNG Core５によって提供されるNextGen（NG）システムに接続する能力を有する。
　LTE eNB２は、ダイレクト基地局間インタフェース１０１によってNR NB３と接続される。ダイレクト基地局間インタフェース１０１は、例えば、X3インタフェースと呼ばれる。ダイレクト基地局間インタフェース１０１は、少なくともLTE eNB２とNR NB３との間のシグナリング・メッセージの転送のために使用される。ダイレクト基地局間インタフェース１０１は、LTE eNB２とNR NB３との間のユーザパケット転送のためにさらに使用されてもよい。ダイレクト基地局間インタフェース１０１のコントロールプレーン・プロトコル構造及びユーザプレーン・プロトコル構造は、例えば、LTE eNB間のX2インタフェースのそれらと同様であってもよい。
　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からネットワークスライシングをサポートするNG SystemへのUE１のハンドオーバ方法を提供する。図２Ａ及び図２Ｂは、図１に示された無線通信ネットワークの構成例におけるLTE SystemからNG SystemへのUE１のハンドオーバ手順の一例を示している。図２Ａは、ハンドオーバの準備（preparation）フェーズ及び実施（execution）フェーズを示し、図２Ｂは、ハンドオーバの完了（completion）フェーズを示している。
　図２Ａ及び図２Ｂに示された手順は、ハンドオーバ準備フェーズ中のダイレクト基地局間インタフェース１０１上でのハンドオーバ・シグナリングメッセージの転送（i.e., ステップ２０２及び２０３）を伴う点において、LTEの“X2-based handover”と類似する。しかしながら、仮にダイレクト基地局間インタフェース１０１上でのハンドオーバ・シグナリングメッセージの転送のみが行われた場合、LTEシステムからNGシステムへのUE１のリロケーションのために必要となる情報がNG RANにおいて不足する。したがって、図２Ａ及び図２Ｂに示された手順では、LTEシステムからNGシステムへのUE１のリロケーションのために必要となる情報を取得するためにNR NB３とNG Core５との間のシグナリング（i.e., ステップ２０７、２０９、及び２１０）を含むようにハンドオーバ完了フェーズが改良されている。
　ステップ２０１では、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ハンドオーバを決定する。Inter-RATハンドオーバの決定に応じて、LTE eNB２は、NR Handover Requestメッセージをダイレクト基地局間インタフェース１０１（e.g., X3インタフェース）上でターゲットNR NB３に送る。
　ステップ２０２のNR Handover Requestメッセージは、LTEからNRへのハンドオーバであることを示すハンドオーバ種別 情報要素（Handover Type Information Element (IE)）を包含してもよい。Handover Type IEは、例えば、“LTEtoNR”がセットされる。
　さらに、ステップ２０２のNR Handover Requestメッセージは、“NG EPS Radio Access Bearers (NE-RABs) To Be Setup List”情報要素（IE）を包含してもよい。“NE-RABs To Be Setup List”IEは、UE１のための各NE-RABの識別子（i.e., NE-RAB ID）及びQoS parameters（e.g., QoS class identifier (QCI)、Allocation and retention priority (ARP)、Guaranteed Bit Rate (GBR) QoS information）を示す。NextGen E-RAB（NE-RAB）は、NG Coreとのインタフェースをサポートするよう拡張されたeLTE eNBを介してUE１とNG Core５内のUser plane Function（e.g., Common User plane NF (CUNF)）との間にセットアップされるE-RABである。
　さらにまた、ステップ２０２のNR Handover Requestメッセージは、“Handover Preparation Information to NR”情報要素（Information Element (IE)）を包含してもよい。例えば、“Handover Preparation Information to NR”IEは、UE１のためのEPS bearersとパケットフロー（e.g., PDU flows又はSDFs）とのマッピングを容易にするための支援情報（assistance information）を含んでもよい。当該支援情報は、各EPS bearerにマッピングされる１又は複数のSDFsの識別子又はパケットフィルタ（e.g., SDF templates、又はTFTs）を示してもよい。当該支援情報は、UE１からLTE eNB２にRRC messageで送られてもよい。さらに、当該支援情報は、RRCレイヤのパラメータを包含する情報要素（IE）として送信されてもよいし、NASレイヤの情報を包含するRRCレイヤのIE（e.g., NAS Info IE）として送信されてもよい。
　さらに又はこれに代えて、“Handover Preparation Information to NR”IEは、セキュリティ関連（Security-related）情報を含んでもよい。セキュリティ関連（Security-related）情報は、Access Stratum（AS）セキュリティ鍵の導出のためにターゲットNR NB３によって使用されるセキュリティパラメータを含む。当該セキュリティパラメータは、ASレイヤによって使用されるセキュリティ鍵（一時鍵）を導出（derivation）するためのベース鍵（i.e., LTEのKeNBに相当する鍵）、又は当該ベース鍵を導出するためのパラメータ（e.g., ｛NH，NCC｝ペア）を含む。当該セキュリティパラメータは、さらに、NG RAT又はNG Systemに関するUE security capabilitiesを含んでもよい。UE security capabilitiesは、UE１に実装されているciphering and integrity protection アルゴリズム（algorithms）を示す。
　例えば、既存のX2ハンドオーバ手順と同様に、ソースLTE eNB２は、未使用の｛NH，NCC｝ペアからKeNB*を導出し、{KeNB*, NCC} ペアをターゲットNR NB３に送ってもよい。Next Hop parameter（NH）及びNext Hop Chaining Counter parameter（NCC）は、ネクストホップのための垂直方向の鍵導出（vertical key derivation）アルゴリズムに従う KeNBの導出に使用される。あるいは、ソースLTE eNB２は、水平方向の鍵導出（horizontal key derivation）アルゴリズムに従って現在のKeNBからKeNB*を導出し、{KeNB*, NCC} ペアをターゲットNR NB３に送ってもよい。
　あるいは、ソースLTE eNB２は、未使用の｛NH，NCC｝ペアをターゲットNR NB３に送ってもよい。この場合、ターゲットNR NB３は、垂直方向の鍵導出（vertical key derivation）アルゴリズムに従って、受信した未使用の｛NH，NCC｝ペアからベース鍵（i.e., LTEのKeNBに相当する鍵）及びAS keysを導出してもよい。
　さらにまた、ステップ２０２のNR Handover Requestメッセージは、ネットワークスライシングの為の支援情報（Assistance Data for Network Slicing）を含んでもよい。”Assistance Data for Network Slicing” IEは、ネットワークスライシングを容易にするための支援情報であるネットワークスライス支援情報（network slice assistance information）を包含する。ネットワークスライス支援情報は、例えば、UE１の種別、UE１が希望するサービス、若しくはUE１の許容レイテンシ、又はこれらの任意の組合せを示してもよい。なお、これに代えて、ネットワークスライス支援情報の一部又は全ては、RRCコンテナ（RRC Context IE）のハンドオーバ準備情報（又は他の情報要素）に包含されてもよい。ここで、ネットワークスライス支援情報（）は、UE１、LTE eNB２、又はNG Core５内のEPCネットワークスライス・インスタンスによって生成されてもよい。例えば、UE１は、ステップ２０１において、ネットワークスライス支援情報をLTE eNB２に送ってもよい。当該ネットワークスライス支援情報は、RRCレイヤのパラメータを示す情報要素（IE）またはNAS情報（NAS information IE）であってもよく、これがUE１からLTE eNB２へ送られる測定報告（measurement report）に含まれてもよい。
　ステップ２０３では、ターゲットNR NB３は、NR Handover Requestメッセージに基づいて、UEコンテキストを生成（create）し、リソースを割り当てる。ターゲットNR NB３は、受信した“E-RABs To Be Setup List”IEに基づいて、許容される（admitted）E-RABsを決定してもよい。ターゲットNR NB３は、各許容されるE-RABに対応するフロー識別子（e.g., PDU flow ID）、アップリンク（UL）PDUsのデリバリーのためのターゲットNR NB３のエンドポイント情報、及びダウンリンク（DL）PDUsのデリバリーのためのターゲットNR NB３のエンドポイント情報を決定してもよい。UL PDUsのデリバリーのためのターゲットNR NB３のエンドポイント情報は、例えば、UL GTP Tunnel Endpoint Identifier (TEID)であってもよいし、UL endpoint ID若しくはInternet Protocol (IP)アドレス又は両方であってもよい。同様に、DL PDUsのデリバリーのためのターゲットNR NB３のエンドポイント情報は、DL GTP TEIDであってもよいし、DL endpoint ID若しくはIPアドレス又は両方であってもよい。UL PDUs及びDL PDUsのデリバリーのためのエンドポイント情報は、ULデータのフォワーディング及びDLデータのフォワーディングのためにそれぞれ使用される。
　さらに、ステップ２０３のNR Handover Requestメッセージがセキュリティ関連情報を含む場合、ターゲットNR NB３は、以下のように動作してもよい。上述したように、セキュリティ関連情報は、ASセキュリティのためのセキュリティパラメータを含む。ターゲットNR NB３は、セキュリティパラメータに含まれるUE security capabilitiesに基づいて、ASセキュリティアルゴリズムを選択してもよい。ASセキュリティアルゴリズムは、Radio Resource Control（RRC）及びユーザプレーン（UP）のためのcipheringアルゴリズム、並びにRRCのためのintegrity protectionアルゴリズムを含む。さらに、ターゲットNR NB３は、RRC ciphering (encryption)、UP ciphering (encryption)、及びRRC integrity protectionのための一時鍵（temporary keys)を、選択したセキュリティアルゴリズムを用いて、セキュリティパラメータから得られるベース鍵（i.e., LTEのKeNBに相当する鍵）から導出してもよい。
　ターゲットNR NB３は、UE１に送られるTarget To Source Transparent Containerを生成する。当該Target To Source Transparent Containerは、例えば、RRCConnectionRecofiguration message及び他のRRC messageを包含するRRC: HandoverCommand message（Handover Command To NR）を含む。そして、ターゲットNR NB３は、当該Target To Source Transparent Containerを包含するハンドオーバ要求への確認応答（Handover Request Acknowledge）メッセージ生成する。ターゲットNR NB３は、NR Handover Request Acknowledgeメッセージをダイレクト基地局間インタフェース１０１（e.g., X3インタフェース）上でソースLTE eNB２に送る。Target To Source Transparent Containerは、例えば、ターゲットNR NB３によりセットアップされた無線リソース設定情報（e.g., 無線パラメータ）、ターゲットNR NB３により選択されたASセキュリティアルゴリズムの識別子（identifiers）、及びNCC値を包含する。NR Handover Request Acknowledge メッセージは、さらに、上述の“NE-RABs Admitted list”情報要素（IE）を包含してもよい。ソースLTE eNB２は、“NE-RABs Admitted list”IEにより指定されたベアラ又はフロー（PDU flow(s)）のためのデータフォワーディングを開始する。
　ステップ２０４では、ソースLTE eNB２は、ターゲットNR NB３により生成されたtransparent containerを含むHandover Commandメッセージを包含するRadio Resource Control（RRC）メッセージをUE１に送る。当該RRCメッセージは、例えば、Mobility from EUTRA commandメッセージであってもよいし、RRC Connection Reconfigurationメッセージであってもよい。
　ステップ２０５では、UE１は、Handover Commandメッセージを包含するRRCメッセージの受信に応答して、ターゲットRAN（i.e., NG RAN）に移動し、Handover Commandメッセージにおいて供給されたtransparent container（e.g., 無線リソース設定情報、ASセキュリティアルゴリズム、及びNCC値）に従ってハンドオーバを実施する。すなわち、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３は、UE１がセルを変更したことを知らせ且つパススイッチを要求するために、NR Path Switch RequestメッセージをNG Core５に送る。当該NR Path Switch Requestメッセージは、LTEからNRへのパススイッチであることを示すパススイッチ種別 情報要素（Path Switch Type IE）を包含してもよい。Path Switch Type IEは、例えば、“LTEtoNR”がセットされる。さらに、当該NR Path Switch Requestメッセージは、ターゲットNR NB３のセルに切り替えられたUE１のEPS bearersのリストを包含してもよい。
　ステップ２０８では、NG Core５内の制御ノード（e.g., CPF）は、ベアラレス・セッションの生成（creation）手順を行う。具体的には、制御ノードは、UE１のためのパケット転送ノード（ゲートウェイ）が再配置（relocated）される必要があることを判定し、NG Core５内のNG Systemのためのターゲット転送ノード（ゲートウェイ）を選択する。NG Systemのためのターゲット転送ノード（ゲートウェイ）は、LTEのS-GWに相当するノードである。制御ノードは、ターゲット転送ノード（ゲートウェイ）にCreate Session Requestメッセージを送る。当該Create Session Requestメッセージは、各EPS bearer contextに関連付けられた１又は複数のサービスデータフローを特定するための情報（e.g., SDF templates、又はTraffic Flow Templates（TFTs））を含んでもよい。例えば、当該１又は複数のサービスデータフローを特定するための情報は、LTE eNB２が接続されるEPCに相当するネットワークスライス・インスタンス内のMMEからNR NB３が接続される純粋なNG Coreに相当するネットワークスライス・インスタンス内の制御ノードに送られるメッセージ（e.g., Forward Relocation Requestメッセージ）から導かれてもよい。ターゲット転送ノード（ゲートウェイ）は、そのローカルリソースを割り当て、Create Session Responseメッセージを制御ノードに返信する。
　なお、NG SystemがQoSクラス毎且つPDUセッション毎のベアラを用いるベアラベースド転送をサポートし、且つ転送ノードの再配置（relocation）が不要である場合、NG Core５内の制御ノードは、ステップ２０８において、セッション生成手順の代わりにベアラ修正（bearer modification）手順を行ってもよい。
　さらに、ステップ２０８では、NG Core５内の制御ノード（e.g., CPF）は、ハンドオーバ後のUE１に接続させるネットワークスライスを選択（再選択）してもよい。NG Core５内の制御ノードは、選択されたネットワークスライス・インスタンスの生成（creation）を実行してもよい。一例において、NG Core５内の制御ノードは、UE１のEPS bearer(s)又はSDF(s)のために必要なQoSに基づいてUE１のためのネットワークスライスを選択してもよい。さらに又はこれに代えて、NG Core５は、ネットワークスライス支援情報（network slice assistance information）を考慮してもよい。ネットワークスライス支援情報は、NG Core５内の制御ノード（e.g., CPF）によるネットワークスライスの選択、設定、又は承認をアシストする。ネットワークスライス支援情報は、UE１、LTE eNB２、又はNG Core５内のEPCネットワークスライス・インスタンスによって生成されてもよい。例えば、UE１からのターゲットNR NB３に送られるNR Handover Confirm for NRメッセージ（ステップ２０６）は、ネットワークスライス支援情報（network slice assistance information）を含んでもよく、ターゲットNR NB３は、受信したネットワークスライス支援情報をNR Path Switch Requestメッセージ（ステップ２０７）に含めてもよい。
　ネットワークスライス支援情報は、例えば、UE１の種別（e.g., Device Type, UE Category）、UE１のアクセス用途（e.g., UE Usage Type）、UE１が希望するサービス種別（e.g., Requested/Preferred Service Type, 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 Path Switch Request AcknowledgeメッセージをターゲットNR NB３に送る。当該NR Path Switch Request Acknowledgeメッセージは、コアネットワーク情報（NG Core Information）を含んでもよい。コアネットワーク情報（NG Core Information）は、フロー情報（Flow Information）若しくはスライス情報（Slice Information）又はこれら両方を含んでもよい。フロー情報は、UE１の少なくとも１つのパケットフロー（i.e., PDU flow(s)）を転送するためにbearer-less network（i.e., NG system）内で確立される少なくとも１つのセッション（i.e., PDU session(s)）に関する。フロー情報は、フロー識別子（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）のうち１つを示してもよい。
　スライス情報は、ハンドオーバ後にUE１が接続する（接続される）NG Core５のネットワークスライスに関する情報、UE１に接続が許可されるNG Core５のネットワークスライスに関する情報、及びUE１が接続可能なNG Core５のネットワークスライスに関する情報のうち少なくとも１つを含む。
　スライス情報は、UE１のために決定（選択）されたスライス（Network Slice: NS）の識別情報、ネットワークノード（NF）の識別情報、若しくはスライスの種別情報又はこれらの任意の組み合わせを含んでもよい。スライスの識別情報は、例えば、Slice ID, NSI ID, MDD, DCN ID,及びDNNのいずれか又は任意の組み合わせでもよい。ネットワークノードの識別情報は、例えば、NF ID, CNF ID, CCNF ID, Slice specific Control plane NF (SCNF) ID, CUNF ID, Slice specific User plane NF (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、又は両方を含んでもよい。
　ステップ２１０では、ターゲットNR NB３は、NG Core５から受信したNAS情報（e.g., スライス情報、及びフロー情報）を運ぶNR DL Information TransferメッセージをUE１に送る。
　図２Ａ及び図２Ｂに示された手順に従ってハンドオーバが完了した後に、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）フェーズを示し、図３Ｂは、ハンドオーバの完了（completion）フェーズを示している。既に説明した図２Ａ及び図２Ｂの手順では、ターゲットNR NB３は、UE１がターゲットNR NB３に接続した後のハンドオーバ完了フェーズ（ステップ２０９）において、コアネットワーク情報（e.g., フロー情報若しくはスライス情報又はこれら両方）をNG Core５から受信する。これに対して、図３Ａ及び図３Ｂに示された手順では、ターゲットNR NB３は、ソースLTE eNB２によるUE１へのハンドオーバの指示より前のハンドオーバ準備フェーズ（ステップ３０４）において、コアネットワーク情報（e.g., フロー情報若しくはスライス情報又はこれら両方）をNG Core５から受信する。以下では、主にこの相違点について説明する。
　ステップ３０１及び３０２の処理は、図２Ａのステップ２０１及び２０２の処理と同様である。ステップ３０３では、ターゲットNR NB３は、NR Handover Requestメッセージ（ステップ３０２）の受信に応答して、Handover Preparation RequestメッセージをNG Core５に送る。
　ステップ３０３のハンドオーバ準備要求（Handover Preparation Request）メッセージは、LTEからNRへのハンドオーバであることを示すハンドオーバ種別 情報要素（Handover Type IE）を包含してもよい。Handover Type IEは、例えば、“LTEtoNR”がセットされる。さらに、当該Handover Preparation Requestメッセージは、ターゲットNR NB３のセルに切り替えられるUE１のNG EPS bearersのリストを包含してもよい。
　ステップ３０４では、NG Core５は、受信したHandover Preparation Requestメッセージに基づいて、当該ハンドオーバの種別がNR（又はNG System）へのInter-RATハンドオーバであることを判定する。さらに、NG Core５は、コアネットワーク情報若しくはセキュリティ関連（Security-related）情報又はこれら両方を包含するHandover Preparation Request AcknowledgeメッセージをターゲットNR NB３に送る。コアネットワーク情報及びセキュリティ関連情報は、NGシステム内でUE１と通信するための無線リソース設定及びセキュリティ関連設定を実施するためにターゲットNR NB３及びUE１によって使用される。コアネットワーク情報の幾つかの具体例は、以下に説明される。
　一例において、コアネットワーク情報は、スライス情報（Slice Information）を含んでもよい。スライス情報は、ハンドオーバ後にUE１が接続する（接続される）NG Core５のネットワークスライスに関する情報、UE１に接続が許可されるNG Core５のネットワークスライスに関する情報、及びUE１が接続可能なNG Core５のネットワークスライスに関する情報のうち少なくとも１つを含む。NG Core５内の制御ノード（e.g., CPF）は、ハンドオーバ後UE１に接続させるネットワークスライスを決定（選択）する。一例において、NG Core５内の制御ノード（CPF）は、UE１のEPS bearer(s)又はSDF(s)のために必要なQoSに基づいてUE１のためのネットワークスライスを選択してもよい。さらに又はこれに代えて、NG Core５は、ネットワークスライス支援情報（network slice assistance information）を考慮してもよい。ネットワークスライス支援情報は、NG Core５内の制御ノード（e.g., CPF）によるネットワークスライスの選択、設定、又は承認をアシストする。ネットワークスライス支援情報は、UE１、LTE eNB２、又はNG Core５内のEPCネットワークスライス・インスタンスによって生成されてもよい。例えば、UE１は、ステップ３０１において、ネットワークスライス支援情報をLTE eNB２に送ってもよい。当該ネットワークスライス支援情報は、NAS情報（NAS information）であってもよく、UE１からLTE eNB２へ送られる測定報告（measurement report）に含まれてもよい。ソースLTE eNB２は、ステップ３０２において、UE１から受信したネットワークスライス支援情報をターゲットNR NB３に送ってもよい。
　他の例において、コアネットワーク情報は、フロー情報（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５内の転送ノードのアドレス及びアップリンク（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）を含んでもよい。
　また、セキュリティ関連情報は、NG SystemにおいてNG Core５とUE１との間で使用されるNon-Access Stratum（NAS）セキュリティ設定情報（security configuration）を含んでもよい。NASセキュリティ設定情報は、例えば、ciphering and integrity protectionを含むNASセキュリティアルゴリズムを含む。NASセキュリティ設定情報は、NAS Security Transparent Container IEであってもよい。すなわち、NASセキュリティ設定情報（NAS Security Transparent Container IE）は、ターゲットNR NB３からソースLTE eNB２を経由して透過的にUE１に送られる。
　セキュリティ関連情報は、さらに、Access Stratum（AS）セキュリティ鍵の導出のためにターゲットNR NB３によって使用されるセキュリティパラメータを含む。当該セキュリティパラメータは、ASレイヤによって使用されるセキュリティ鍵（一時鍵）を導出（derivation）するためのベース鍵（i.e., LTEのKeNBに相当する鍵）、又は当該ベース鍵を導出するためのパラメータ（e.g., ｛NH，NCC｝ペア）を含む。ここで、Next Hop parameter（NH）及びNext Hop Chaining Counter parameter（NCC）は、垂直方向の鍵導出（vertical key derivation）アルゴリズムに従う KeNBの導出に使用される。当該セキュリティパラメータは、さらに、NG RAT又はNG Systemに関するUE security capabilitiesを含んでもよい。UE security capabilitiesは、UE１に実装されているciphering and integrity protection アルゴリズム（algorithms）を示す。
　ステップ３０４のハンドオーバ準備要求への確認応答（Handover Preparation Request Acknowledge）メッセージに包含されるコアネットワーク情報は、上述した２つの例（i.e., スライス情報及びフロー情報）のうちのいずれか１つ又は両方を含んでもよい。
　ステップ３０５では、ターゲットNR NB３は、コアネットワーク情報若しくはセキュリティ関連情報又は両方を包含するHandover Preparation Request Acknowledgeメッセージの受信に応答して、UEコンテキストを生成（create）し、リソースを割り当てる。
　Handover Preparation Request Acknowledgeメッセージに包含されるコアネットワーク情報がスライス情報を含む場合、ターゲットNR NB３は、以下のように動作してもよい。ターゲットNR NB３は、スライス情報を包含するコアネットワーク情報に基づいて、アドミッション制御を行ってもよい。例えば、ターゲットNR NB３は、ベアラ毎またはフロー毎に、ベアラ又はフローを受け入れるか否かを決定してもよい。さらに又はこれに代えて、ターゲットNR NB３は、スライス情報に基づいて、UE１が接続するネットワークスライス毎のアドミッション制御を行ってもよい。このとき、NR NB３は、各ネットワークスライスを受け入れることが可能か否かを判定してもよい、NR NB３は、受け入れることが不可能な（又は、受け入れない）ネットワークスライスがある場合、当該ネットワークスライスを特定のネットワークスライス（e.g., デフォルト・ネットワークスライス）にマッピングしてもよいし、当該ネットワークスライスを特定のNF（e.g., CUPF）に接続するようにしてもよい。あるいは、NR NB３は、当該ネットワークスライスの受け入れの失敗を決定してもよい。
　さらに又はこれに代えて、ターゲットNR NB３は、ネットワークスライシングをサポートするNG Systemに関連付けられた無線コネクション（e.g., RRCコネクション、無線ベアラ）を確立するために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）のエンコード及びデコードの対象、の少なくともいずれかは、スライス毎に異なっていてもよい。
　Handover Preparation Request Acknowledgeメッセージに包含されるコアネットワーク情報がフロー情報を含む場合、ターゲットNR NB３は、以下のように動作してもよい。ターゲットNR NB３は、フロー情報を、UEコンテキスト及び無線リソース設定情報の生成のために考慮してもよい。具体的には、ターゲットNR NB３は、フロー情報に基づいて、パケットフロー（i.e., PDU flow(s)）についての情報及びセキュリティ・コンテキストを含むUEコンテキストを生成（create）してもよい。さらに、ターゲットNR NB３は、bearer-less network（i.e., NG System）に関連付けられた無線コネクション（e.g., RRCコネクション、無線ベアラ）を確立するためにUE１にとって必要となる無線リソース設定情報を、フロー情報に基づいて生成してもよい（又は、フロー情報から導出してもよい）。無線リソース設定情報は、フロー情報に含まれる少なくとも１つのパラメータを含んでもよい。無線リソース設定情報は、ターゲット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３及び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., パケット破棄)を行ってもよい。
　Handover Preparation Request Acknowledgeメッセージがセキュリティ関連情報を含む場合、ターゲットNR NB３は、以下のように動作してもよい。上述したように、セキュリティ関連情報は、NASセキュリティ設定情報（NAS Security Transparent Container IE）及びASセキュリティのためのセキュリティパラメータを含む。ターゲットNR NB３は、NASセキュリティ設定情報（NAS Security Transparent Container IE）をUE１に送られるtransparent containerに含めてもよい。さらに又はこれに代えて、ターゲットNR NB３は、セキュリティパラメータに含まれるUE security capabilitiesに基づいて、ASセキュリティアルゴリズムを選択してもよい。ASセキュリティアルゴリズムは、Radio Resource Control（RRC）及びユーザプレーン（UP）のためのcipheringアルゴリズム、並びにRRCのためのintegrity protectionアルゴリズムを含む。さらに、ターゲットNR NB３は、RRC ciphering (encryption)、UP ciphering (encryption)、及びRRC integrity protectionのための一時鍵（temporary keys)を、選択したセキュリティアルゴリズムを用いて、セキュリティパラメータから得られるベース鍵（i.e., LTEのKeNBに相当する鍵）から導出してもよい。
　ターゲットNR NB３は、UE１に送られるTarget To Source Transparent Container（RRCConnectionReconfiguration）を生成する。当該Target To Source Transparent Container は、例えばRRCConnectionRecofiguration message及び他のRRC messageを包含するHandoverCommand messageを含む。そして、ターゲットNR NB３は、当該Target To Source Transparent Containerと、コアネットワーク情報を含むコアネットワーク・コンテキスト情報（NG Core Context IE）とを包含するハンドオーバ要求への確認応答（NR Handover Request Acknowledge）メッセージを生成する。ターゲットNR NB３は、NR Handover Request Acknowledgeメッセージをダイレクト基地局間インタフェース１０１（e.g., X3インタフェース）上でソースLTE eNB２に送る。Target To Source Transparent Containerは、例えば、ターゲットNR NB３によりセットアップされた無線リソース設定情報（e.g., 無線パラメータ）、ターゲットNR NB３により選択されたASセキュリティアルゴリズムの識別子（identifiers）、及びNASセキュリティ設定情報を包含する。なお、コアネットワーク・コンテキスト情報（NG Core Context）は、ソースLTE eNB２に透過的に、UE１へ送信されてもよい。さらに、又はこれに代えて、コアネットワーク・コンテキスト情報の一部又は全てが、Target To Source Transparent Containerに包含されてもよい。NR Handover Request Acknowledge メッセージは、さらに、上述の“NE-RABs Admitted list”情報要素（IE）を包含してもよい。ソースLTE eNB２は、“NE-RABs Admitted list”IEにより指定されたベアラ又はフロー（PDU flow(s)）のためのデータフォワーディングを開始する。
　ステップ３０６の処理は、図２Ａのステップ２０４の処理と同様である。ステップ３０７では、UE１は、Handover Commandメッセージを包含するRRCメッセージの受信に応答して、ターゲットRAN（i.e., NG RAN）に移動し、Handover Commandメッセージにおいて供給されたtransparent container（e.g., 無線リソース設定情報、ASセキュリティアルゴリズム、及びNASセキュリティ設定情報）に従ってハンドオーバを実施する。ステップ３０８の処理は、図２Ａのステップ２０６の処理と同様である。
　ステップ３０９では、NG Core５は、ベアラレス・セッションの生成（creation）手順又はベアラ修正（modification）手順を行う。言い換えると、NG Core５内の制御ノードは、ステップ３０３のHandover Preparation Requestメッセージの受信に応答して、UE１のためのベアラレス・セッションの生成（creation）手順又はベアラ修正（modification）手順を開始する。すなわち、NG Core５内の制御ノードは、ターゲットNR NB３からのパススイッチ要求（ステップ３１０）に先立って、UE１のためのベアラレス・セッションの生成（creation）手順又はベアラ修正（modification）手順を開始する。ステップ３０９におけるベアラレス・セッションの生成又はベアラ修正は、図２Ｂのステップ２０８におけるそれと同様に行われてもよい。
　ステップ３１０では、ターゲットNR NB３は、NR Path Switch RequestメッセージをNG Core５に送る。ステップ３１１では、NG Core５内の制御ノードは、フロー修正（modification）手順を実施することによって、Inter-RAT ハンドオーバ手順を完了する。例えば、NG Core５内の制御ノードは、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５内の転送ノードは、NG Core５内の制御ノードにModify Flow Responseメッセージを返信してもよい。ステップ３１２では、NG Core５内の制御ノードは、NR Path Switch Request AcknowledgeメッセージをターゲットNR NB３に送る。
　図４は、ターゲットNR NB３によって行われる方法の一例（処理４００）を示すフローチャートである。ステップ４０１では、ターゲットNR NB３は、Handover Requestメッセージをダイレクト基地局間インタフェース１０１上でソースLTE eNB２から受信する。当該Handover Requestメッセージは、LTEシステムからNGシステムへのUE１のハンドオーバに関する。ステップ４０１は、例えば、図２Ａのステップ２０２又は図３Ａのステップ３０２に対応する。
　ステップ４０２では、ターゲットNR NB３は、スライス情報若しくはフロー情報又はこれら両方をコアネットワーク（i.e., NG Core５）から受信する。ステップ４０２は、例えば、図２Ｂのステップ２０９又は図３Ａのステップ３０４に対応する。
　ステップ４０３では、ターゲットNR NB３は、スライス情報及びフロー情報のうち少なくとも一方に基づいて、UE１の通信を制御する。例えば、ターゲットNR NB３は、スライス情報及びフロー情報のうち少なくとも一方に基づいて無線リソース設定情報を生成し、当該無線リソース設定情報をUE１に送ってもよい。例えば、ターゲットNR NB３は、スライス情報に基づいて、UE１に関するコントロールプレーン・メッセージを送るネットワークスライスを選択してもよい。例えば、ターゲットNR NB３は、フロー情報に含まれるエンドポイント情報に基づいて、UE１のULユーザデータ（PDU flows）のNG Core５へのフォワーディングを行ってもよい。例えば、ターゲットNR NB３は、フロー情報に含まれるフローQoSパラメータに基づいて、UE１へのリソース・スケジューリングを行ってもよい。
　図５は、ソースLTE eNB２によって行われる方法の一例（処理５００）を示すフローチャートである。ステップ５０１では、ソースLTE eNB２は、Handover Requestメッセージをダイレクト基地局間インタフェース１０１上でターゲットNR NB３に送る。当該Handover Requestメッセージは、LTEシステムからNGシステムへのUE１のハンドオーバに関する。ステップ５０１は、例えば、図２Ａのステップ２０２又は図３Ａのステップ３０２に対応する。
　ステップ５０２では、ソースLTE eNB２は、transparent container（RRCConnectionReconfiguration）を包含するHandover Request Acknowledgeメッセージをダイレクト基地局間インタフェース１０１上でターゲットNR NB３から受信する。ステップ５０２は、例えば、図２Ａのステップ２０３又は図３Ａのステップ３０５に対応する。Transparent containerは、例えば、ターゲットNR NB３によりセットアップされた無線リソース設定情報、ターゲットNR NB３により選択されたASセキュリティアルゴリズムの識別子（identifiers）、及びNCC値又はNASセキュリティ設定情報を包含する。
　ステップ５０３では、ソースLTE eNB２は、ターゲットNR NB３から受信したtransparent containerを包含し且つベアラレス・ネットワークへのハンドオーバを示すmobility commandメッセージ（e.g., Handover Commandメッセージ）をUE１に送る。ステップ５０３は、図２Ａのステップ２０４又は図３Ａのステップ３０６に対応する。
　図６は、コアネットワーク（i.e., NG Core５）によって行われる方法の一例（処理６００）を示すフローチャートである。図６の処理は、NG Core５内の１つの制御ノードによって行われてもよいし、NG Core内の２つの制御ノード（i.e., ソースMME及びターゲット制御ノード）によって行われてもよい。ステップ６０１では、NG Core５は、LTEシステムからNGシステムへのハンドオーバ又はパススイッチを示すメッセージ（e.g., Handover Preparation Requestメッセージ、又はNR Path Switch Requestメッセージ）をターゲットNR NB３から受信する。ステップ６０１は、図２Ｂのステップ２０７又は図３Ａのステップ３０３に対応する。
　ステップ６０２では、NG Core５は、スライス情報若しくはフロー情報又はこれら両方をターゲットNR NB３に送る。ステップ６０２は、例えば、図２Ｂのステップ２０９又は図３Ａのステップ３０４に対応する。
　図７は、UE１によって行われる方法の一例（処理７００）を示すフローチャートである。ステップ７０１では、UE１は、mobility commandメッセージ（e.g., Handover Commandメッセージ）をソースLTE eNB２から受信する。当該mobility commandメッセージは、ターゲットNR NB３からのtransparent container（RRCConnectionReconfiguration）を包含する。当該transparent containerは、例えば、無線リソース設定情報、ASセキュリティアルゴリズム、及びNCC値又はNASセキュリリティ設定情報を包含する。ステップ７０１は、例えば、図２Ａのステップ２０４又は図３Ａのステップ３０６に対応する。
　ステップ７０２では、UE１は、受信したtransparent containerに含まれる情報に従って、NG Systemに関連付けられたターゲットNR NB３との無線コネクションを確立する。ステップ７０２は、例えば、図２Ａのステップ２０５及び２０６、又は図３Ａのステップ３０７及び３０８に対応する。
　本実施形態において、ネットワークは、ハンドオーバのターゲットセル（NR cell）がネットワークスライシングをサポートしているか否かをUE１が事前に把握できるようにしてもよい。例えば、NR NB３は、NRセルにおいてネットワークスライシングがサポートされいること（或いは、ネットワークスライシングを可能なNG Coreへの接続が可能であること）を明示的または暗示的に示すネットワークスライシング・サポート情報をシステム情報（e.g., System Information Block Type-x: SIBx. E.g., x = 1）として報知してもよい。明示的に送信されるネットワークスライシング・サポート情報は、サポートされているネットワークスライスを示すために、サポートされているサービス種別（e.g., Supported Service Type）、又は、サポートされているスライス種別（e.g., Supported Slice Type）をさらに含んでもよい。一方、暗示的に送信されるネットワークスライシング・サポート情報は、ネットワークスライス毎に異なる無線リソース設定に関する情報を含んでもよい。UE１は、受信した無線リソース設定の少なくとも一部がネットワークスライス毎に指定されていることを認識することで、当該セルでネットワークスライシングがサポートされていることを理解してもよい。当該無線リソース設定に関する情報は、物理リソースの設定情報若しくはシステム設定情報又はこれら両方を含んでもよい。物理リソースの設定情報は、code, time, frequency, RACH preamble sequence (group)の少なくとも１つを含んでもよい。システム設定情報は、subcarrier spacing, sampling rate, TTI, subframe/frame format typeの少なくとも１つを含んでもよい。ネットワークスライシング・サポート情報は、NASレイヤの情報として送信されてもよいし、ASレイヤの情報として送信されてもよい。前者の場合、UE１はASレイヤ（RRC）で受信した当該情報をNASレイヤに転送する。
　本実施形態に係るLTE SystemからNG Systemへの詳細なハンドオーバ手順は、例えば上述された具体例であってもよいが、これらに限定されない。例えば、上述された幾つかのハンドオーバ手順例に示されたメッセージ名は、例示に過ぎない。上述された幾つかのハンドオーバ手順例は、メッセージの順序が異なってもよいし、幾つかのメッセージが省略されてもよいし、追加のメッセージを含んでもよい。
　以上の説明から理解されるように、本実施形態で説明されたLTE SystemからNG Systemへの幾つかのハンドオーバ手順は、ダイレクト基地局間インタフェース上でのハンドオーバ・シグナリングメッセージの転送を伴うInter-RATハンドオーバ手順である。
これらのハンドオーバ手順では、ターゲットNR NB３は、スライス情報若しくはフロー情報又はこれら両方をコアネットワーク（i.e., NG Core５）から受信し、この情報をUE１の通信を制御するために使用するよう構成されている。これにより、ターゲットNR NB３は、LTE SystemからNG Systemにハンドオーバされたコネクテッド状態のUE１の通信を継続することに寄与できる。
＜第２の実施形態＞
　本実施形態は、第１の実施形態に係るLTE SystemからNG SystemへのUE１のハンドオーバ方法の変形例を提供する。図８は、図１に示された無線通信ネットワークの構成例におけるLTE SystemからNG SystemへのUE１のハンドオーバ手順の一例を示している。なお、図８に示されたハンドオーバ手順は、図２Ａ及び図２Ｂに示されたハンドオーバ手順の詳細化及び変形であり、NG Core５内の構成と、NG Core５によるネットワークスライス選択について具体的に記載している。
　図８に示されたNG Core５は、共通ネットワーク機能（Common Network Functions（NFs））５１、ネットワークスライスＡのためのネットワーク機能（NFs for slice A）５２、ネットワークスライスＢのためのネットワーク機能（NFs for slice B）５３、及びHome Subscriber Server（HSS）５４を含む。
　なお、各ネットワーク要素（NF）は、ネットワークスライスの構成要素である。各ネットワークスライスは、必要とされる（required）通信サービス（telecommunication services）及びネットワーク能力（network capabilities）を提供するために必要なネットワーク機能（NFs）から構成される。各ネットワーク要素（NF）は、ネットワーク内の処理機能（processing function）であり、機能的な振る舞い（functional behaviour）及びインタフェース（interfaces）を定義する。各ネットワーク要素は、個別ハードウェア（dedicated hardware）上のネットワーク要素として実装されてもよいし、個別ハードウェア（dedicated hardware）上で動作（run）するソフトウェア・インスタンスであってもよいし、適切なプラットフォーム上に生成（instantiated）されている仮想化された機能であってもよい。
　各ネットワークスライスは、Network Slice specific Instance ID （NSI-ID）によって識別されてもよい。各ネットワーク機能（NF）は、Network Function ID（NF ID）によって識別されてもよい。共通のコントロールプレーン・ネットワーク機能（Common CP NFs）がある（使用される）場合、NSI-IDは、Common CP NF IDs と Slice specific IDs（i.e., NF IDs for selected slice）との組み合わせでもよい。
　図８に示されたCommon NFs５１は、コントロールプレーン・ネットワーク機能（CP NFs）を含む。Common NFs５１は、さらに、ユーザプレーン・ネットワーク機能（UP NFs）を含んでもよい。NFs for slice A５２は、UP NFsを含み、CP NFsを含んでもよい。同様に、NFs for slice B５３は、UP NFsを含み、CP NFsを含んでもよい。
　図８は、スライス選択機能（Slice Selection Function（SSF））がCommon NFs５１と同じ場所に配置（co-located）される例を示している。しかしながら、SSFは、Common NFs５１から離れて配置されてもよい。この場合、Common NFs５１はSSFとメッセージを交換する。SSFは、UE１に関連付けられるネットワークスライスを選択する。例えば、SSFは、UE１をデフォルト・ネットワークスライスに関連付けてもよいし、さらに又はこれに代えてUE１によって指定されたネットワークスライス（スライスタイプ）に関連付けてもよい。SSFは、さらに、選択されたスライスに対応したCP NFs（or CP NFIDs）を選択するためにNAS Node Selection Function（NNSF）を行ってもよい。ここで、デフォルト・ネットワークスライスは、Public Land Mobile Network（PLMN）毎、RAT毎、UE usage type毎、Service type毎、又は、Slice type毎に設定されていてもよい。
　UE１の１又は複数のパケットフローのネットワークスライスへの割り当ては、以下に示す３つの例のいずれかに従って行われてもよい。第１の例では、NR NB３及びNG Core５を含むNG Systemは、QoSクラス毎且つPDUセッション毎のベアラを用いるベアラベースド転送をサポートする。NG SystemのベアラはNG-EPS-bearerと呼ばれてもよく、NG Systemの無線アクセスベアラはNG-RABと呼ばれてもよい。第１の例では、各ベアラはいずれかのネットワークスライスに割り当てられる。幾つかの実装では、Common NFs５１は、UE１のために選択されたネットワークスライスのSlice specific User plane NF(s) (SUNF(s))と通信し、当該SUNF(s)にUE１のベアラを設定する。
　第２の例では、第１の例と同様に、NR NB３及びNG Core５を含むNG Systemは、QoSクラス毎且つPDUセッション毎のベアラを用いるベアラベースド転送をサポートする。NG Systemのベアラは、複数のパケットフロー（PDU flows）の転送に利用されることができる。第２の例では、NG Systemは、データフロー（PDU flow）毎のQoSハンドリング(e.g., パケット破棄)のためにベアラ内のデータフロー（PDU flow）を特定するよう構成される。第２の例では、UE１の各パケットフロー（e.g., PDU flow）は、フロー（PDU flow）単位でいずれかのネットワークスライスに割り当てられる。
　第３の例では、NR NB３及びNG Core５を含むNG Systemは、ユーザデータのフローベースド転送をサポートする。第３の例では、ネットワークスライシングは、UE１のPDUセッション毎に設定される。言い換えると、１つのPDUセッションに含まれる複数のパケットフロー（PDU flows）のセットがいずれか１つのネットワークスライスに割り当てられる。
　ステップ８０１では、UE１は、ソースLTE eNB２からターゲットNR NB３にハンドオーバされ、ターゲットNR NB３のセルにおいてコネクテッド状態（i.e., RRC_Connected）である。UE１は、ネットワークスライス支援情報（network slice assistance information）をターゲットNR NB３に送る。既に説明したように、当該ネットワークスライス支援情報は、例えば、UE１の種別、UE１が希望するサービス、若しくはUE１の許容レイテンシ、又はこれらの任意の組合せを示してもよい。当該ネットワークスライス支援情報は、NAS情報（NAS information）であってもよく、UE１からLTE eNB２へ送られる測定報告（measurement report）に含まれてもよい。UE１は、ネットワークスライス支援情報を送信するために、RRC Connection Reconfiguration Completeメッセージ（e.g., 図２Ａのステップ２０６）、UL Information Transferメッセージ、又はその他のRRCメッセージを用いてもよい。なお、UE１によるネットワークスライス支援情報の送信は省略されてもよい。
　ステップ８０２は、図２Ｂのステップ２０７に対応する。すなわち、ターゲットNR NB３は、NR Path Switch RequestメッセージをNG Core５に送る。当該NR Path Switch Requestメッセージは、EPS Radio Access Bearer（E-RAB）QoS情報要素（IE）を含む。E-RAB QoS IEは、UE１のE-RABのQoS（e.g., QoS class identifier (QCI)、Allocation and retention priority (ARP)）を示す。当該NR Path Switch Requestメッセージは、さらに、UE１のNASレイヤから送られたネットワークスライス支援情報（ステップ８０１）を包含してもよい。
　ステップ８０３では、Common NFs５１は、必要に応じて、UE１の認証（authentication）を実行する。当該認証は、UE１に許可された（authorized）スライスの確認（slice authorization）を含む。slice authorizationでは、Common NFs５１は、UE１が許可されるか否かをスライス毎に決定／判定してもよい。
　ステップ８０４では、Common NFs５１は、スライス選択を実行する。すなわち、Common NFs５１は、UE１に関連付けられるネットワークスライスを選択する。図８の例では、Common NFs５１は、スライスＡをUE１のために選択する。ステップ８０４のスライス選択は、UE１によって行われている（ongoing）又は要求されている（requested）サービス毎（e.g., EPS bearer/E-RAB、IP flow）に行われてもよい。既に述べたように、ステップ８０４のスライス選択は、Common NFs５１から離れて配置されたSSFによって行われてもよい。
　ステップ８０５は、図２Ｂのステップ２０８に対応する。Common NFs５１は、UE１のために選択されたスライス（ここでは、スライスＡ）においてベアラレス・セッションを生成（creation）するために、選択されたスライスのUP NFs（NFs for slice A５２）と通信する。なお、NG Systemがユーザデータのベアラベースド転送をサポートし、且つ転送ノードの再配置（relocation）が不要である場合、Common NFs５１は、セッション生成手順の代わりにベアラ修正（bearer modification）手順を行ってもよい。
　ステップ８０６は、図２Ｂのステップ２０９に対応する。Common NFs５１は、NR Path Switch Request AcknowledgeメッセージをターゲットNR NB３に送る。Common NFs５１の代わりに、選択されたスライスのCP NFs（NFs for slice A５２）が当該NR Path Switch Request AcknowledgeメッセージをターゲットNR NB３に送ってもよい。
　ステップ８０６のNR Path Switch Request Acknowledgeメッセージは、Common NFs５１（又はSSF）によって選択されたネットワークスライスに関する情報（i.e., slice information情報要素（IE））を含む。Slice information IEは、例えば、選択されたネットワークスライスを示すNSI-ID、選択されたネットワーク機能（NFs）を示すNF IDs、若しくはmulti-dimensional descriptor (MDD)、又はこれらの任意の組合せを包含してもよい。MDDは、RRC シグナリングレイヤ及び NAS シグナリングレイヤの中でUEによって供給されることができる。MDDは、テナントID（Tenant ID）、及びサービス記述子（Service Descriptor）／スライスタイプ（slice type）を表す。サービス記述子／スライスタイプは、UE１又は選択されたネットワークスライスに関連付けられたサービス又はユースケース（e.g., eMBB, mMTC, URLLC, critical communications (CriC)）を示す。
　ステップ８０７は、図２Ｂのステップ２１０に対応する。ターゲットNR NB３は、NG Core５から受信したslice information IEを運ぶNR DL Information TransferメッセージをUE１に送る。
　図９Ａ及び図９Ｂは、図１に示された無線通信ネットワークの構成例におけるLTE SystemからNG SystemへのUE１のハンドオーバ手順の他の一例を示している。図９Ａ及び図９Ｂに示されたハンドオーバ手順は、図３Ａ及び図３Ｂに示されたハンドオーバ手順の詳細化及び変形であり、NG Core５内の構成と、NG Core５によるネットワークスライス選択について具体的に記載している。以下では、図８の手順と図９Ａ及び図９Ｂの手順との相違点について主に説明する。
　ステップ９０１では、UE１は、LTE eNB２に接続され、コネクテッド状態（i.e., RRC_Connected）である。UE１は、ネットワークスライス支援情報（network slice assistance information）をLTE eNB２に送る。UE１は、ネットワークスライス支援情報を送信するために、RRC Connection Reconfiguration Completeメッセージ、UL Information Transferメッセージ、又はその他のRRCメッセージを用いてもよい。
　ステップ９０２は、図３Ａのステップ３０２に対応する。すなわち、ソースLTE eNB３は、NR Handover RequestメッセージをターゲットNR NB３に送る。当該NR Handover Requestメッセージは、E-RAB QoS IEを含む。E-RAB QoS IEは、UE１のE-RABのQoS（e.g., QoS class identifier (QCI)、Allocation and retention priority (ARP)）を示す。当該NR Handover Requestメッセージは、さらに、UE１のNASレイヤから送られたネットワークスライス支援情報（ステップ９０１）を含んでもよい。
　ステップ９０３は、図３Ａのステップ３０３に対応する。すなわち、ターゲットNR NB３は、Handover Preparation RequestメッセージをNG Core５に送信する。当該Handover Preparation Requestメッセージは、ソースLTE eNB２から受信したE-RAB QoS IEを含む。当該Handover Preparation Requestメッセージは、さらに、ソースLTE eNB２から受信したネットワークスライス支援情報（ステップ８０１）を含んでもよい。
　ステップ９０４及び９０５の処理は、図８のステップ８０３及び８０４の処理と同様である。ステップ９０６は、図３Ａのステップ３０４に対応する。すなわち、Common NFs５１は、Handover Preparation Request AcknowledgeメッセージをターゲットNR NB３に送る。当該Handover Preparation Request Acknowledgeメッセージは、Common NFs５１（又はSSF）によって選択されたネットワークスライスに関する情報（i.e., slice information IE）を含む。
　ステップ９０７は、図３Ａのステップ３０５に対応する。すなわち、ターゲットNR NB３は、NR Handover Request AcknowledgeメッセージをソースLTE eNB２に送る。当該NR Handover Request Acknowledgeメッセージに包含されるtransparent containerは、Common NFs５１から送られたslice information IEを含んでもよい。
　ステップ９０８は、図３Ａのステップ３０６に対応する。すなわち、ソースLTE eNB３は、ターゲットNR NB３により生成されたtransparent containerを含むHandover Commandメッセージを包含するRadio Resource Control（RRC）メッセージをUE１に送る。当該RRCメッセージは、例えば、Mobility from EUTRA commandメッセージであってもよいし、RRC Connection Reconfigurationメッセージであってもよい。上述したように、UE１に送られるtransparent containerは、slice information IEを含んでもよい。
　ステップ９０９及び９１０は、図３Ａのステップ３０７及び３０８に対応する。すなわち、UE１は、ターゲットNR NB３へのハンドオーバを実施し（ステップ３０９）、NR Handover Confirm for NRメッセージをターゲットNR NB３に送る（ステップ９１０）。ステップ９１０のメッセージは、NR RRC Connection Reconfiguration Completeメッセージであってもよい。ステップ９１０のメッセージは、slice information IEを含んでもよい。当該slice information IEは、UE１のために選択されたネットワークスライスを特定するための識別子（e.g., NSI-ID、NF IDs、又はMDD）を含む。当該slice information IEは、NAS情報（NAS information）であってもよく、RRC情報（RRC information）であってもよい。
　ハンドオーバ完了フェーズでは、図９Ｂに示されたオプション１（i.e., ステップ９１１Ａ、９１２Ａ、及び９１３Ａ）及びオプション２（i.e., ステップ９１１Ｂ、９１２Ｂ、及び９１３Ｂ）のうちいずれかが実行される。
　オプション１では、ターゲットNR NB３は、NR Path Switch RequestメッセージをCommon NFs５１に送る（ステップ９１１Ａ）。当該NR Path Switch Requestメッセージは、slice information IEを含んでもよい。ステップ９１１Ａは、図３Ｂのステップ３１０に対応する。
　ステップ９１２Ａは、図３Ｂのステップ３１１に対応する。Common NFs５１は、UE１のために選択されたスライス（ここでは、スライスＡ）においてベアラレス・セッションを生成（creation）するために、選択されたスライスのUP NFs（NFs for slice A５２）と通信する。NG Systemがユーザデータのベアラベースド転送をサポートし、且つ転送ノードの再配置（relocation）が不要である場合、Common NFs５１は、セッション生成手順の代わりにベアラ修正（bearer modification）手順を行ってもよい。
　ステップ９１３Ａは、図３Ｂのステップ３１２に対応する。Common NFs５１は、NR Path Switch Request AcknowledgeメッセージをターゲットNR NB３に送る。Common NFs５１の代わりに、選択されたスライスのCP NFs（NFs for slice A５２）が当該NR Path Switch Request AcknowledgeメッセージをターゲットNR NB３に送ってもよい。
　これに対してオプション２では、ターゲットNR NB３は、UE１のために選択されたネットワークスライス（i.e., スライスＡ）を判定し、スライスＡに対応するNFs for slice A５２のCP NFsにNR Path Switch Request Acknowledgeメッセージを送る（ステップ９１１Ｂ）。幾つかの実装において、ターゲットNR NB３は、UE１のために選択されたネットワークスライスを判定するために、ステップ９１０においてUE１から受信したslice information IEを使用してもよい。これに代えて、ターゲットNR NB３は、ステップ９０７においてNG Core５から受信したslice information IEをUE１のコンテキストに関連付けて格納しておき、当該格納されたslice information IEをステップ９１１Ｂでの判定に使用してもよい。
　ステップ９１２Ｂは、図３Ｂのステップ３１１に対応する。NFs for slice A５２のCP NFsは、ベアラレス・セッションを生成（creation）するために、NFs for slice A５２のUP NFsと通信する。NG Systemがユーザデータのベアラベースド転送をサポートし、且つ転送ノードの再配置（relocation）が不要である場合、NFs for slice A５２は、セッション生成手順の代わりにベアラ修正（bearer modification）手順を行ってもよい。NFs for slice A５２は、必要に応じて、Common NFs５１と通信してもよい。
　ステップ９１３Ｂは、図３Ｂのステップ３１２に対応する。NFs for slice A５２のCP NFsは、NR Path Switch Request AcknowledgeメッセージをターゲットNR NB３に送る。
　本実施形態に係るLTE SystemからNG Systemへのハンドオーバ手順によれば、UE１のためにCommon NFs５１によって選択されたネットワークスライスの情報（e.g., NSI-ID、MDD、NFIDs）をNG Core５からターゲットNR NB３に供給することができる。したがって、例えば、ターゲットNR NB３は、UE１のために選択されたネットワークスライスを知ることができる。さらに又はこれに代えて、ターゲットNR NB３は、例えば、Handover Command （i.e., transparent container（RRCConnectionReconfiguration））に含めてUE１に送られる情報又はパラメータを生成又は導出するために、UE１のためにCommon NFs５１によって選択されたネットワークスライスの情報を使用することができる。
＜第３の実施形態＞
　本実施形態は、NG SystemからLTE SystemへのUE１のハンドオーバ方法を提供する。図１０Ａ及び図１０Ｂは、図１に示された無線通信ネットワークの構成例におけるNG SystemからLTE SystemへのUE１のハンドオーバ手順の一例を示している。図１０Ａは、ハンドオーバの準備（preparation）フェーズ及び実施（execution）フェーズを示し、図１０Ｂは、ハンドオーバの完了（completion）フェーズを示している。
　図１０Ａ及び図１０Ｂに示された手順は、ハンドオーバ準備フェーズ中のダイレクト基地局間インタフェース１０１（e.g., X3インタフェース）上でのハンドオーバ・シグナリングメッセージの転送（i.e., ステップ１００２及び１００３）を伴う点において、LTEの“X2-based handover”と類似する。しかしながら、仮にダイレクト基地局間インタフェース１０１上でのハンドオーバ・シグナリングメッセージの転送のみが行われた場合、LTEシステムからNGシステムへのUE１のリロケーションのために必要となる情報が不足する。したがって、図１２Ａ及び図１２Ｂに示された手順では、NGシステムからLTEシステムへのUE１のリロケーションのために必要となる情報を取得するためにLTE eNB２とNG Core５との間のシグナリング（i.e., ステップ１００７及び１００８）を含むようにハンドオーバ完了フェーズが改良されている。
　ステップ１００１では、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ハンドオーバを決定する。Inter-RATハンドオーバの決定に応じて、NR NB３は、ハンドオーバ要求（Handover Request）メッセージをダイレクト基地局間インタフェース１０１上でターゲットLTE eNB２に送る。
　ステップ１００２のHandover Requestメッセージは、NRからLTEへのハンドオーバであることを示すハンドオーバ種別 情報要素（Handover Type Information Element (IE)）を包含してもよい。Handover Type IEは、例えば、“NRtoLTE”がセットされる。
　さらに、ステップ１００２のHandover Requestメッセージは、ハンドオーバされるUE１のフロー（PDU flow(s)）又はベアラ（bearer(s)）の識別子及びQoS parameters（e.g., QCI、ARP）を示してもよい。
　さらにまた、ステップ１００２のHandover Requestメッセージは、“Handover Preparation Information to EUTRA”情報要素（IE）を包含してもよい。“Handover Preparation Information to EUTRA”IEは、セキュリティ関連（Security-related）情報を含んでもよい。セキュリティ関連（Security-related）情報は、Access Stratum（AS）セキュリティ鍵の導出のためにターゲットLTE eNB２によって使用されるセキュリティパラメータを含む。当該セキュリティパラメータは、ASレイヤによって使用されるセキュリティ鍵（一時鍵）を導出（derivation）するためのベース鍵（i.e., LTEのKeNB）、又は当該ベース鍵を導出するためのパラメータ（e.g., ｛NH，NCC｝ペア）を含む。当該セキュリティパラメータは、さらに、LTE RAT又はLTE Systemに関するUE security capabilitiesを含んでもよい。UE security capabilitiesは、UE１に実装されているciphering and integrity protection アルゴリズム（algorithms）を示す。
　例えば、既存のX2ハンドオーバ手順と同様に、ソースNR NB３は、未使用の｛NH，NCC｝ペアから垂直方向の鍵導出（vertical key derivation）アルゴリズムに従ってKeNB*を導出し、{KeNB*, NCC} ペアをターゲットLTE eNB２に送ってもよい。あるいは、ソースLTE eNB２は、水平方向の鍵導出（horizontal key derivation）アルゴリズムに従って現在のKeNBからKeNB*を導出し、{KeNB*, NCC} ペアをターゲットNR NB３に送ってもよい。
　ステップ１００３では、ターゲットLTE eNB２は、Handover Requestメッセージに基づいて、UEコンテキストを生成（create）し、リソースを割り当てる。ステップ１００３のNR Handover Requestメッセージがセキュリティ関連情報を含む場合、ターゲットNR NB３は、以下のように動作してもよい。上述したように、セキュリティ関連情報は、ASセキュリティのためのセキュリティパラメータを含む。ターゲットNR NB３は、セキュリティパラメータに含まれるUE security capabilitiesに基づいて、ASセキュリティアルゴリズムを選択してもよい。ASセキュリティアルゴリズムは、Radio Resource Control（RRC）及びユーザプレーン（UP）のためのcipheringアルゴリズム、並びにRRCのためのintegrity protectionアルゴリズムを含む。さらに、ターゲットNR NB３は、RRC ciphering (encryption)、UP ciphering (encryption)、及びRRC integrity protectionのための一時鍵（temporary keys)を、選択したセキュリティアルゴリズムを用いて、セキュリティパラメータから得られるベース鍵（i.e., LTEのKeNB）から導出してもよい。
　そして、ターゲットLTE eNB２は、UE１に送られるTarget To Source Transparent Container（RRCConnectionReconfiguration）を生成する。当該Target To Source Transparent Containerは、例えばRRCConnectionRecofiguration message及び他のRRC messageを包含するHandoverCommand message（Handover Command To EUTRA）を含む。そして、ターゲットLTE eNB２は、当該Target To Source Transparent Containerを包含するハンドオーバ要求への確認応答（NR Handover Request Acknowledge）メッセージを生成する。ターゲットLTE eNB２は、NR Handover Request Acknowledgeメッセージをダイレクト基地局間インタフェース１０１上でソースNR NB３に送る。Target To Source Transparent Containerは、例えば、ターゲットLTE eNB２によりセットアップされた無線リソース設定情報（e.g., 無線パラメータ）、ターゲットNR NB３により選択されたASセキュリティアルゴリズムの識別子（identifiers）、及びNCC値を包含する。
　Handover Request Acknowledge メッセージは、さらに、ダウンリンク・データフォワーディングの対象とされるベアラのリスト（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)）の識別子を含む。Address(es) 及び TEID(s) for user traffic data forwardingは、ダイレクト基地局間インタフェース１０１上でのターゲットNR NB３へのアドレス及びTEIDであってもよい。ソースNR NB３は、“Bearers Subject to Data forwarding list”IEにより指定されたベアラ又はフロー（PDU flow(s)）のためのデータフォワーディングを開始する。
　ステップ１００４では、ソースNR NB３は、ターゲットLTE eNB２により生成されたtransparent containerを含むHandover Commandメッセージを包含するRadio Resource Control（RRC）メッセージをUE１に送る。当該RRCメッセージは、例えば、Mobility from NR commandメッセージであってもよいし、RRC Connection Reconfigurationメッセージであってもよい。
　ステップ１００５では、UE１は、Handover Commandメッセージを包含するRRCメッセージの受信に応答して、ターゲットRAN（i.e., E-UTRAN）に移動し、Handover Commandメッセージにおいて供給されたtransparent container（e.g., 無線リソース設定情報、ASセキュリティアルゴリズム、及びNCC値）に従ってハンドオーバを実施する。すなわち、UE１は、LTE Systemに関連付けられたターゲットLTE eNB２との無線コネクションを確立する。ステップ１００６では、UE１は、ターゲットセルに首尾よく（successfully）同期した後に、Handover Confirm for EUTRAメッセージをターゲットLTE eNB２に送る。ステップ１００６のメッセージは、RRC Connection Reconfiguration Completeメッセージであってもよい。
　ステップ１００８では、UE１がターゲットNR NB３に首尾よく（successfully）アクセスした場合に、ターゲットLTE eNB２は、UE１がセルを変更したことを知らせ且つパススイッチを要求するために、Path Switch RequestメッセージをNG Core５に送る。Path Switch Requestメッセージは、ターゲットLTE eNB２のセルに切り替えられたUE１のEPS bearers（又はPDU flows）のリストを含んでもよい。
　ステップ１００８では、NG Core５内の制御ノード（e.g., MME）は、ベアラベースド・セッションの生成（creation）手順を行う。具体的には、制御ノードは、UE１のためのパケット転送ノード（ゲートウェイ）が再配置（relocated）される必要があることを判定し、NG Core５内のターゲット転送ノード（i.e., S-GW）を選択する。制御ノードは、ターゲットS-GWにCreate Session Requestメッセージを送る。当該Create Session Requestメッセージは、各PDU flow contextに関連付けられた１又は複数のサービスデータフローを特定するための情報（e.g., SDF templates、又はTraffic Flow Templates（TFTs））を含む。ターゲットS-GWは、そのローカルリソースを割り当て、Create Session Responseメッセージを制御ノードに返信する。
　ステップ１００９では、NG Core５は、Path Switch Request AcknowledgeメッセージをターゲットLTE eNB2に送る。当該Path Switch Request Acknowledgeメッセージは、ベアラ設定情報を含む。ベアラ設定情報は、NG Core５内の転送ノード（再配置後）のアドレス及びアップリンク（UL）トンネル・エンドポイント識別子（TEID）を含む。
　なお、NG Systemがユーザデータのベアラベースド転送をサポートし、且つ転送ノードの再配置（relocation）が不要である場合、NG Core５内の制御ノードは、ステップ１００８において、セッション生成手順の代わりにベアラ修正（bearer modification）手順を行ってもよい。
　図１１Ａ及び図１１Ｂは、図１に示された無線通信ネットワークの構成例におけるNG SystemからLTE SystemへのUE１のハンドオーバ手順の一例を示している。図１１Ａは、ハンドオーバの準備（preparation）フェーズ及び実施（execution）フェーズを示し、図１１Ｂは、ハンドオーバの完了（completion）フェーズを示している。既に説明した図１０Ａ及び図１０Ｂの手順では、ターゲットLTE eNB２は、UE１がターゲットLTE eNB２に接続した後のハンドオーバ完了フェーズ（ステップ１００）において、ベアラ設定情報をNG Core５から受信する。これに対して、図１１Ａ及び図１１Ｂに示された手順では、ターゲットLTE eNB２は、ソースNR NB３によるUE１へのハンドオーバの指示より前のハンドオーバ準備フェーズ（ステップ１１０４）において、ベアラ設定情報をNG Core５から受信する。以下では、主にこの相違点について説明する。
　ステップ１１０１及び１１０２の処理は、図１０Ａのステップ１００１及び１００２の処理と同様である。ステップ１１０３では、ターゲットLTE eNB２は、Handover Requestメッセージ（ステップ１１０２）の受信に応答して、Handover Preparation RequestメッセージをNG Core５に送る。
　ステップ１１０３のHandover Preparation Requestメッセージは、NRからLTEへのハンドオーバであることを示すハンドオーバ種別 情報要素（Handover Type IE）を包含してもよい。Handover Type IEは、例えば、“NRtoLTE”がセットされる。さらに、当該Handover Preparation Requestメッセージは、ターゲットLTE eNB２のセルに切り替えられるUE１のPDU flowsのリストを包含してもよい。
　ステップ１１０４では、NG Core５は、受信したHandover Preparation Requestメッセージに基づいて、当該ハンドオーバの種別がLTE SystemへのInter-RATハンドオーバであることを判定する。さらに、NG Core５は、コアネットワーク情報若しくはセキュリティ関連（Security-related）情報又は両方を包含するHandover Preparation Request AcknowledgeメッセージをターゲットLTE eNB２に送る。コアネットワーク情報及びセキュリティ関連情報は、NGシステム内でUE１と通信するためのリソース及びセキュリティ関連設定を実施するためにターゲットNR NB３によって使用される。
　一例において、コアネットワーク情報は、ベアラ設定情報（Bearer Config）を含んでもよい。ベアラ設定情報は、UE１のために設定される少なくとも１つのEPSベアラに関する。ベアラ設定情報は、ベアラ識別子（e.g., EPS Bearer Identity及びE-RAB ID）、NG Core５内の転送ノードのアドレス及びUL TEID、並びにbearer QoS parameters（e.g., QCI、ARP）を含む。当該ベアラ設定情報は、UE１のためのEPS bearersとPDU flowsとのマッピングを示してもよい。
　また、セキュリティ関連情報は、LTE SystemのNASセキュリティ設定情報を含む。NASセキュリティ設定情報は、例えば、ciphering and integrity protectionを含むNASセキュリティアルゴリズムを含む。NASセキュリティ設定情報は、NAS Security Transparent Container IEであってもよい。すなわち、NASセキュリティ設定情報（NAS Security Transparent Container IE）は、ターゲットLTE eNB２からソースNR NB３を経由して透過的にUE１に送られる。
　セキュリティ関連情報は、さらに、ASセキュリティ鍵の導出のためにターゲットLTE eNB２によって使用されるセキュリティパラメータを含む。当該セキュリティパラメータは、ASレイヤによって使用されるセキュリティ鍵（一時鍵）を導出（derivation）するためのベース鍵（i.e., LTEのKeNB）、又は当該ベース鍵を導出するためのパラメータ（e.g., ｛NH，NCC｝ペア）を含む。当該セキュリティパラメータは、さらに、LTE RAT又はLTE Systemに関するUE security capabilitiesを含んでもよい。UE security capabilitiesは、UE１に実装されているciphering and integrity protection アルゴリズム（algorithms）を示す。
　ステップ１１０５では、ターゲットLTE eNB２は、コアネットワーク情報若しくはセキュリティ関連（Security-related）情報又は両方を包含するHandover Preparation Request Acknowledgeメッセージに基づいて、UEコンテキストを生成（create）し、リソースを割り当てる。Handover Preparation Request Acknowledgeメッセージにがセキュリティ関連情報を含む場合、ターゲットLTE eNB２は、以下のように動作してもよい。上述したように、セキュリティ関連情報は、NASセキュリティ設定情報（NAS Security Transparent Container IE）及びASセキュリティのためのセキュリティパラメータを含む。ターゲットLTE eNB２は、NASセキュリティ設定情報（NAS Security Transparent Container IE）をUE１に送られるtransparent containerに含めてもよい。さらに又はこれに代えて、ターゲットLTE eNB２は、セキュリティパラメータに含まれるUE security capabilitiesに基づいて、ASセキュリティアルゴリズム（i.e., RRC及びUPのためのcipheringアルゴリズム、並びにRRCのためのintegrity protectionアルゴリズム）を選択してもよい。さらに、ターゲットLTE eNB２は、RRC ciphering (encryption)、UP ciphering (encryption)、及びRRC integrity protectionのための一時鍵（temporary keys)を、選択したセキュリティアルゴリズムを用いて、セキュリティパラメータから得られるベース鍵（i.e., KeNB）から導出してもよい。
　そして、ターゲットLTE eNB２は、UE１に送られるtransparent container（RRCConnectionReconfiguration）を生成し、当該transparent containerを包含するHandover Command メッセージ（Handover Command to EUTRAメッセージ）を生成する。Transparent containerは、例えば、ターゲットLTE eNB２によりセットアップされた無線リソース設定情報、ターゲットLTE eNB２により選択されたASセキュリティアルゴリズムの識別子（identifiers）、及びNASセキュリティ設定情報を包含する。ターゲットLTE eNB２は、Handover Command メッセージをダイレクト基地局間インタフェース１０１上でソースNR NB３に送る。
　ステップ１１０６～ステップ１１０８の処理は、図１０のステップ１００４～ステップ１００６の処理と同様である。ステップ１１０９では、NG Core５は、ベアラ・セッションの生成（creation）手順を行う。言い換えると、NG Core５内の制御ノードは、ステップ１１０３のHandover Preparation Requestメッセージの受信に応答して、UE１のためのベアラ・セッションの生成（creation）手順を開始する。すなわち、NG Core５内の制御ノードは、ターゲットLTE eNB２からのパススイッチ要求（ステップ１１１０）に先立って、UE１のためのEPSベアラの生成（creation）手順を開始する。ステップ１１０９におけるベアラ生成は、図１０のステップ１００８におけるそれと同様に行われてもよい。
　ステップ１１１０では、ターゲットLTE eNB２は、Path Switch RequestメッセージをNG Core５に送る。ステップ１１１１では、NG Core５内の制御ノードは、ベアラ修正（modification）手順を実施することによって、Inter-RAT ハンドオーバ手順を完了する。例えば、NG Core５内の制御ノードは、S-GWに、セッション（i.e., PDN connection）毎のModify Bearer Requestメッセージを送信してもよい。Modify Bearer Requestメッセージは、ベアラ識別子（e.g., EPS Bearer ID）、並びにターゲットLTE eNB２のアドレス及びダウンリンク（DL）TEIDを包含してもよい。S-GWは、NG Core５内の制御ノードにModify Bearer Responseメッセージを返信してもよい。ステップ１１１２では、NG Core５内の制御ノードは、Path Switch Request AcknowledgeメッセージをターゲットLTE eNB２に送る。
　本実施形態に係るNG SystemからLTE Systemへの詳細なハンドオーバ手順は、例えば上述された具体例であってもよいが、これらに限定されない。例えば、上述された幾つかのハンドオーバ手順例に示されたメッセージ名は、例示に過ぎない。上述された幾つかのハンドオーバ手順例は、メッセージの順序が異なってもよいし、幾つかのメッセージが省略されてもよいし、追加のメッセージを含んでもよい。
＜第４の実施形態＞
　本実施形態は、NGシステム内でのソースNR NBからターゲットNE NBへのUE１のハンドオーバ方法を提供する。以下では、NGシステム内でのハンドオーバをintra-NR ハンドオーバと呼ぶ。
　図１２は、本実施形態に係る無線通信ネットワークの構成例を示している。図１２の例では、無線通信ネットワークは、UE１、NR NBs６及び７、並びにNG Core５を含む。NR NB６は、例えば、マクロ基地局であってもよいし、ピコ基地局であってもよい。同様に、NR NB７は、マクロ基地局であってもよいし、ピコ基地局であってもよい。図１２の例では、NR NBs６及び７は、同程度のカバレッジを持ち、NR NBs６及び７の２つのセルは部分的にオーバラップしている。しかしながら、本実施形態に係る無線通信ネットワークは、Heterogeneous Network（HetNet）構造を有してもよい。例えば、NR NB６はマクロ基地局であり、NR NB７はピコ基地局であり、NR NB６のマクロセルは、NR NB７のピコセルを完全にカバーしてもよい。これとは反対に、NR NB６はピコ基地局であり、NR NB７はマクロ基地局であってもよい。
　NR NB６とNR NB７との間は、ダイレクト基地局間インタフェース１２０１によって接続される。ダイレクト基地局間インタフェース１２０１は、少なくともNR NB６とNR NB７との間のシグナリング・メッセージの転送のために使用される。ダイレクト基地局間インタフェース１２０１は、NR NB６とNR NB７との間のユーザパケット転送のためにさらに使用されてもよい。ダイレクト基地局間インタフェース１２０１のコントロールプレーン・プロトコル構造及びユーザプレーン・プロトコル構造は、例えば、LTE eNB間のX2インタフェースのそれらと同様であってもよい。ダイレクト基地局間インタフェース１２０１は、例えば、NG X2インタフェースと呼ばれる。
　以下では、intra-NR ハンドオーバ手順の幾つかの例を説明する。以下に説明される幾つかの例は、コネクテッド状態のUE１がソースNR NB６からターゲットNR NB７にハンドオーバされるUEモビリティに関する。
　図１３は、intra-NR ハンドオーバ手順の一例を示している。図１３は、ソースセル／ソースNR NB６及びターゲットセル／ターゲットNR NB７の両方でUE１にネットワークスライシングが適用されるケースを示している。図１３に示された手順は、ハンドオーバ準備フェーズ中のダイレクト基地局間インタフェース１０１上でのハンドオーバ・シグナリングメッセージの転送（i.e., ステップ１３０３及び１３０４）を伴う点において、LTEの“X2-based handover”と類似する。
　ステップ１３０１では、UE１は、ソースNR NB６に接続され、コネクテッド状態（i.e., RRC_Connected）である。UE１は、ソースセル／ソースNR NB６においてネットワークスライシングを適用されている。ステップ１３０２では、UE１は、測定設定（Measurement Configuration）をNR NB６から受信し、当該測定設定に従って隣接セル測定（neighbor cell measurements）を実行し、測定報告（measurement report）をNR NB６に送る。
　ステップ１３０３では、NR NB６は、NR NB７のセルへのintra-NRハンドオーバを決定する。Intra-NRハンドオーバの決定に応じて、ソースNR NB６は、NR Handover Requestメッセージをダイレクト基地局間インタフェース１２０１上でターゲットNR NB７に送る。
　ステップ１３０３のNR Handover Requestメッセージは、ターゲットNR NB７でセットアップされるべきUE１のパケットフロー（i.e., PDU flow(s)）又はベアラ（i.e., radio access bearer(s)）のリスト（e.g., PDU-Flows To Be Setup List）を包含してもよい。当該リストは、各パケットフローのフロー情報（Flow Information）を示す。当該フロー情報は、フロー識別子（e.g., PDU flow ID）、NG Core５内の転送ノードのアドレス及びアップリンク（UL）のセッション・エンドポイント識別子（Session Endpoint Identifier（SEID））、並びにフローQoSパラメータを含む。
　ステップ１３０３のNR Handover Requestメッセージは、スライス情報（slice Information）を包含してもよい。当該スライス情報は、ソースセル／ソースNR NB６においてUE１が接続している（利用している）１又はそれ以上のネットワークスライスに関する。当該スライス情報は、UE１が接続している１又はそれ以上のネットワークスライスを認識することをターゲットNR NB７に可能とする。例えば、当該スライス情報は、UE１が接続している各ネットワークスライスの識別子（e.g., NSI-ID、NF IDs、MDD）を示してもよい。さらに又はこれに代えて、当該スライス情報は、各ネットワークスライスに関連付けられたCP NFs（又はMMEに相当する制御ノード）によってUE１に割り当てられたUE識別子を示してもよい。当該UE識別子は、LTEのMME UE S1AP IDに相当する識別子であってもよい。UE１が複数のネットワークスライスに接続している場合、複数のネットワークスライスにそれぞれ対応する複数のUE識別子がUE１に割り当てられてもよい。
　ステップ１３０４では、ターゲットNR NB７は、NR Handover Requestメッセージに基づいて、UEコンテキストを生成（create）し、リソースを割り当てる。ターゲットNR NB７は、受信したフロー情報（e.g., PDU-Flows To Be Setup List）に基づいて、許容される（admitted）PDU flowsを決定してもよい。ターゲットNR NB７は、受信したスライス情報に基づいて、UE１が接続している１又はそれ以上のネットワークスライスを認識し、各ネットワークスライスのCP NFs（又はMMEに相当する制御ノード）を認識してもよい。
　そして、ターゲットNR NB７は、UE１に送られるtransparent container（RRCConnectionReconfiguration）を生成し、当該transparent containerを包含するNR Handover Request Acknowledge メッセージ（Handover Command to NRメッセージ）を生成する。ターゲットNR NB７は、NR Handover Request Acknowledgeメッセージをダイレクト基地局間インタフェース１２０１上でソースNR NB６に送る。Transparent containerは、例えば、ターゲットNR NB７によりセットアップされた無線リソース設定情報を含む。NR Handover Request Acknowledge メッセージは、さらに、上述の“PDU-flows Admitted list”情報要素（IE）を包含してもよい。ソースLTE eNB２は、“PDU-flows Admitted list”IEにより指定されたフロー（PDU flow(s)）のためのデータフォワーディングを開始する。
　ステップ１３０５では、ソースNR NB６は、NR RRC Connection ReconfigurationメッセージをUE１に送る。当該RRC Connection Reconfigurationメッセージは、“MobilityControlInfoNR”IEを含む。“MobilityControlInfoNR”IEは、ターゲットNR NB７により生成され、ターゲットセル／ターゲットNR NB７にアクセスするために必要な設定及び情報をUE１に知らせる。
　ステップ１３０６では、UE１は、NR RRC Connection Reconfigurationメッセージの受信に応答して、ソースセル／ソースNR NB６からターゲットセル／ターゲットNR NB７に移動する。ステップ１３０７では、UE１は、ターゲットセルに首尾よく（successfully）同期した後に、Handover Confirm for NRメッセージを包含するNR RRC Connection Reconfiguration CompleteメッセージをターゲットNR NB７に送る。当該Handover Confirm for NRメッセージ又はNR RRC Connection Reconfiguration Completeメッセージは、ネットワークスライス支援情報（network slice assistance information）又はスライス設定情報（slice configuration）を包含してもよい。
　ステップ１３０８では、UE１がターゲットNR NB７に首尾よく（successfully）アクセスした場合に、ターゲットNR NB７は、UE１がセルを変更したことを知らせ且つパススイッチを要求するために、NR Path Switch RequestメッセージをNG Core５に送る。当該NR Path Switch Requestメッセージは、ターゲットNR NB７のセルに切り替えられたUE１のベアラ（i.e., E-RAB）又はパケットフロー（i.e., PDU flow(s)）のリストを包含してもよい。より具体的には、当該NR Path Switch Requestメッセージは、“E-RAB/Flow to be switched in Downlink (DL) List”IEを包含してもよい。ステップ１３０８のNR Path Switch Requestメッセージは、スライス情報（slice information）を包含してもよい。スライス情報は、ターゲットセル／ターゲットNR NB７においてUE１が接続（利用）することを希望する１又はそれ以上のネットワークスライスを示す。
　ステップ１３０９では、NG Core５は、フロー修正（modification）手順を実施する。例えば、NG Core５内の制御ノードは、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５内の転送ノードは、NG Core５内の制御ノードにModify Flow Responseメッセージを返信してもよい。
　ステップ１３１０では、NG Core５内の制御ノードは、NR Path Switch Request AcknowledgeメッセージをターゲットNR NB３に送る。NG Core５がトンネルのアップリンク転送ポイント（tunnels of uplink termination point）を変更した場合、当該NR Path Switch Request Acknowledgeメッセージは、“E-RAB/Flow to be switched in Uplink(UL) List”IEを包含してもよい。“E-RAB/Flow to be switched in UL List”IEは、各ベアラ（i.e., E-RAB）又はフロー（i.e., PDU flow）のための新しいアップリンク・トランスポート・レイヤ・アドレス及びエンドポイント識別子を示す。NG Systemがユーザデータのベアラベースド転送をサポートする場合、NG Core５内の制御ノードは、ステップ１３１０において、セッション生成手順の代わりにベアラ修正（bearer modification）手順を行ってもよい。
　なお、ステップ１３０８のNR Path Switch Requestメッセージの受信に応答して、NG Core５の制御ノードは、UE１のためのネットワークスライスの変更を決定してもよいし、いずれのネットワークスライスもUE１に許可されないことを判定してもよい。これに応じて、ステップ１３１０のNR Path Switch Request Acknowledgeメッセージは、変更されたUE１のためのネットワークスライスを示すSlice information IEを包含してもよい。あるいは、ステップ１３１０のNR Path Switch Request Acknowledgeメッセージは、いずれのネットワークスライスもUE１に許可されないことを示してもよい。
　ステップ１３１１では、ターゲットNR NB３は、NG Core５から受信したNAS情報（e.g., Slice information IE）を運ぶNR DL Information TransferメッセージをUE１に送ってもよい。
　図１４は、intra-NR ハンドオーバ手順の一例を示している。図１４に示されたハンドオーバ手順は、図１３に示されたハンドオーバ手順の詳細化及び変形であり、NG Core５内の構成と、NG Core５内のシグナリングについて具体的に記載している。図１４に示されたNG Core５の具体的構成は、図８に示されたそれと同様である。すなわち、NG Core５は、Common NFs５１、NFs for slice A５２、NFs for slice B５３、及びHSS５４を含む。
　ステップ１４０１は、図１３のステップ１３０１に対応する。ここでは、一例として、UE１のためにスライスＡ及びスライスＢが選択されている。ステップ１４０２は、図１３のステップ１３０２～１３０７に対応し、ハンドオーバ準備フェーズ及びハンドオーバ実行フェーズを含む。
　図１４は、ケースＡ（ステップ１４０３～１４０６）及びケースＢ（ステップ１４０７～１４１０）を示している。ケースＡ及びケースＢのいずれか１つが実行される。ケースＡでは、Common NFs５１内のCP NFs（e.g., Session Management Function（SMF）又はMobility Management Function（MMF））が、全てのUE１のためのスライスに対してフロー修正（又はベアラ修正）をトリガーする。これに対して、ケースＢでは、各スライスのCP NFs（e.g., SMF又はMMF）がそのスライスのフロー修正（又はベアラ修正）をトリガーする。
　まずケースＡについて説明する。ステップ１４０３は、図１３のステップ１３０８に対応する。ステップ１４０３では、ターゲットNR NB７は、NR Path Switch RequestメッセージをCommon NFs５１に送る。既に説明したように、当該NR Path Switch Requestメッセージは、“E-RAB/Flow to be switched in Downlink (DL) List”IEを包含してもよい。さらに、当該NR Path Switch Requestメッセージは、スライス情報（slice information）を包含してもよい。スライス情報は、ターゲットセル／ターゲットNR NB７においてUE１が接続（利用）することを希望する１又はそれ以上のネットワークスライスを示す。
　ステップ１４０４及び１４０５は、図１３のステップ１３０９に対応する。ステップ１４０４及び１４０５では、Common NFs５１のCP NFsは、NFs for slice A５２及びNFs for slice B５３にフロー修正（又はベアラ修正）をトリガーする。
　ステップ１４０６は、図１３のステップ１３１０に対応する。ステップ１４０６では、Common NFs５１は、NR Path Switch Request AcknowledgeメッセージをターゲットNR NB７に送る。既に説明したように、当該NR Path Switch Request Acknowledgeメッセージは、“E-RAB/Flow to be switched in UL List”IEを包含してもよい。
　次に、ケースＢについて説明する。ステップ１４０７は、図１３のステップ１３０８に対応する。ステップ１４０７では、NR NB３は、ターゲットセル／ターゲットNR NB７においてUE１が接続（利用）することを希望する１又はそれ以上のネットワークスライスのCP NFs（i.e., NFs for slice A５２のCP NFs及びFs for slice B５３のCP NFs）のそれぞれにNR Path Switch Requestメッセージを送る。ターゲットNR NB７は、ソースNR NB６から受信したNR Handover Requestメッセージ（ステップ１４０２、１３０３）に包含されているスライス情報に基づいて、NR Handover Requestメッセージを送るべき１又はそれ以上のネットワークスライスを決定（選択）してもよい。これに代えて、ターゲットNR NB７は、UE１から受信したNR RRC Connection Reconfiguration Completeメッセージ（又はHandover Confirm for NRメッセージ）に包含されているネットワークスライス支援情報又はスライス情報に基づいて、NR Handover Requestメッセージを送るべき１又はそれ以上のネットワークスライスを決定（選択）してもよい。
　ステップ１４０８及び１４０９は、図１３のステップ１３０９に対応する。ステップ１４０８では、NFs for slice A５２は、スライスＡ内のフロー修正（又はベアラ修正）を実行する。ステップ１４０９では、NFs for slice B５３は、スライスＢ内のフロー修正（又はベアラ修正）を実行する。
　ステップ１４１０は、図１３のステップ１３１０に対応する。ステップ１４１０では、NFs for slice A５２のCP NFs及びFs for slice B５３のCP NFsのそれぞれが、NR Path Switch Request AcknowledgeメッセージをターゲットNR NB７に送る。
　図１５は、intra-NR ハンドオーバ手順の一例を示している。図１５は、ソースセル／ソースNR NB６ではUE１にネットワークスライシングが適用されないが、ターゲットセル／ターゲットNR NB７ではUE１にネットワークスライシングが適用されるケースを示している。
　ステップ１５０１では、UE１は、ソースNR NB６に接続され、コネクテッド状態（i.e., RRC_Connected）である。UE１は、ソースセル／ソースNR NB６においてネットワークスライシングを適用されていない。
　ステップ１５０２～１５０７は、図１３のステップ１３０２～１５０７と基本的に同様である。ただし、ステップ１５０３のNR Handover Requestメッセージは、スライス情報（slice information）を包含しなくてもよい。一方、ステップ１５０７のNR RRC Connection Reconfiguration Completeメッセージ（又はHandover Confirm for NRメッセージ）は、ネットワークスライス支援情報を包含してもよい。ネットワークスライス支援情報は、NAS情報（NAS information）であってもよく、RRC情報（RRC information）であってもよい。
　ステップ１５０８～ステップ１５１０は、ハンドオーバ完了フェーズであり、図１３のステップ１３０８～１５１０と基本的に同様である。ただし、ステップ１５０９では、NG Core５は、UE１のためのスライス選択をさらに実行する。NG Core５によるスライス選択を支援するために、ステップ１５０８のNR Path Switch Requestメッセージは、UE１から送られたネットワークスライス支援情報を包含してもよい。ステップ１５１０のNR Path Switch Request Acknowledgeメッセージは、スライス情報（slice information）を包含してもよい。当該スライス情報は、NG Core５によってUE１のために選択された１又はそれ以上のネットワークスライスに関する。
　ステップ１５１１は、図１３のステップ１３１１に対応する。ステップ１５１１のNR DL Information Transferメッセージは、NG Core５から送られたスライス情報を運んでもよい。
　図１６は、intra-NR ハンドオーバ手順の一例を示している。図１６に示されたハンドオーバ手順は、図１５に示されたハンドオーバ手順の詳細化及び変形であり、NG Core５内の構成と、NG Core５内のシグナリングについて具体的に記載している。図１６に示されたNG Core５の具体的構成は、図８に示されたそれと同様である。
　ステップ１６０１は、図１５のステップ１５０１に対応する。ステップ１６０２は、図１５のステップ１５０２～１５０７に対応し、ハンドオーバ準備フェーズ及びハンドオーバ実行フェーズを含む。なお、UE１は、ステップ１６０２の間に、又はステップ１６０２の前に、ネットワークスライス支援情報をターゲットNR NB７に送ってもよい。例えば、UE１は、NR RRC Connection Reconfiguration Completeメッセージ（又はHandover Confirm for NRメッセージ）を用いてネットワークスライス支援情報を送ってもよい。
　ステップ１６０３は、図１３のステップ１３０８に対応する。ステップ１６０３では、ターゲットNR NB７は、NR Path Switch RequestメッセージをCommon NFs５１に送る。既に説明したように、当該NR Path Switch Requestメッセージは、“E-RAB/Flow to be switched in Downlink (DL) List”IEを包含してもよい。さらに、当該NR Path Switch Requestメッセージは、ネットワークスライス支援情報を包含してもよい。
　ステップ１６０４では、Common NFs５１は、必要に応じて、UE１の認証（authentication）を実行する。当該認証は、UE１に許可された（authorized）スライスの確認（slice authorization）を含む。slice authorizationでは、Common NFs５１は、UE１が許可されるか否かをスライス毎に決定／判定してもよい。
　図１６は、少なくとも１つのネットワークスライスがUE１に許可されている場合、又は少なくとも１つのネットワークスライスがUE１によって行われている（ongoing）又は要求されている（requested）サービス（services(s)）に適用できる（applicable）場合について示す。したがって、ステップ１６０５では、Common NFs５１は、スライス選択を実行する。図１６の例では、Common NFs５１は、スライスＡをUE１のために選択する。ステップ１６０５のスライス選択は、UE１によって行われている（ongoing）又は要求されている（requested）サービス毎（e.g., EPS bearer/E-RAB、IP flow）に行われてもよい。ステップ１６０５のスライス選択は、Common NFs５１から離れて配置されたSSFによって行われてもよい。
　ステップ１６０６は、図１５のステップ１５０９に対応する。Common NFs５１は、フロー修正（又はベアラ修正）を実行するめに、UE１のために選択されたスライス（ここでは、スライスＡ）のNFs for Slice A５２と通信する。これにより、Common NFs５１及びNFs for Slice A５２は、UE１のパケットフロー（i.e., PDU flow(s)）又はベアラのアップリンク及びダウンリンク転送ポイントを共通ネットワークスライス（i.e., Common NFs５１）からスライスＡ（i.e., NFs for slice A５２）に切り替える。
　ステップ１６０７は、図１５のステップ１５１０に対応する。Common NFs５１は、NR Path Switch Request AcknowledgeメッセージをターゲットNR NB７に送る。Common NFs５１の代わりに、選択されたスライスのCP NFs（NFs for slice A５２）が当該NR Path Switch Request AcknowledgeメッセージをターゲットNR NB７に送ってもよい。既に説明したように、ステップ１６０７のNR Path Switch Request Acknowledgeメッセージは、“E-RAB/Flow to be switched in UL List”IEを包含してもよい。
　さらに、ステップ１６０７のNR Path Switch Request Acknowledgeメッセージは、スライス情報を包含してもよい。当該スライス情報は、UE１のためにNG Core５により選択された１又はそれ以上のネットワークスライスを認識することをターゲットNR NB７に可能とする。例えば、当該スライス情報は、各ネットワークスライスの識別子（e.g., NSI-ID、NF IDs、MDD）を示してもよい。さらに又はこれに代えて、当該スライス情報は、各ネットワークスライスに関連付けられたCP NFs（又はMMEに相当する制御ノード）によってUE１に割り当てられたUE識別子を示してもよい。当該UE識別子は、LTEのMME UE S1AP IDに相当する識別子であってもよい。UE１が複数のネットワークスライスに接続している場合、複数のネットワークスライスにそれぞれ対応する複数のUE識別子がUE１に割り当てられてもよい。
　ステップ１６０８は、図１５のステップ１５１１に対応する。当該NR DL Information Transferメッセージは、NG Core５から送られたスライス情報の全て又は一部を運んでもよい。
　図１７は、intra-NR ハンドオーバ手順の一例を示している。図１７は、ソースセル／ソースNR NB６ではUE１にネットワークスライシングが適用されるが、ターゲットセル／ターゲットNR NB７ではUE１にネットワークスライシングが適用されないケースを示している。
　ステップ１７０１では、図１３のステップ１３０１と同様に、UE１は、ソースセル／ソースNR NB６においてネットワークスライシングを適用されている。ステップ１７０２～１７１１の処理も、図１３のステップ１３０２～１３１１の処理と同様である。ただし、ステップ１７０９では、NG Core５は、ターゲットセル／ターゲットNR NB７においてネットワークスライシングがUE１に適用されないことを決定し、UE１のパケットフロー又はベアラのアップリンク及びダウンリンク転送ポイントをスライスＡ及びＢ（i.e., NFs for slice A５２及びNFs for slice B５３）から共通ネットワークスライス（i.e., Common NFs５１）に切り替える。したがって、ステップ１７１０のNR Path Switch Request Acknowledgeメッセージは、UE１にネットワークスライシングが適用されないことを明示的または暗示的に示す情報を包含してもよい。ステップ１７１１のNR DL Information Transferメッセージも、UE１にネットワークスライシングが適用されないことを明示的または暗示的に示す情報を包含してもよい。
　図１８は、intra-NR ハンドオーバ手順の一例を示している。図１８に示されたハンドオーバ手順は、図１７に示されたハンドオーバ手順の詳細化及び変形であり、NG Core５内の構成と、NG Core５内のシグナリングについて具体的に記載している。図１８に示されたNG Core５の具体的構成は、図８に示されたそれと同様である。
　ステップ１８０１～１８０３における処理は、図１４のステップ１４０１～１４０３における処理と同様である。ステップ１４０４では、Common NFs５１は、必要に応じて、UE１の認証（authentication）を実行する。当該認証は、UE１に許可された（authorized）スライスの確認（slice authorization）を含む。slice authorizationでは、Common NFs５１は、UE１が許可されるか否かをスライス毎に決定／判定してもよい。Common NFs５１は、いずれのネットワークスライスもUE１に許可されていないこと、又はいずれのネットワークスライスもUE１によって行われている（ongoing）又は要求されている（requested）サービス（services(s)）に適用できない（not applicable）ことを判定する。
　ステップ１８０５及び１８０６は、図１７のステップ１７０９に対応する。ステップ１８０５及び１８０６では、Common NFs５１のCP NFsは、UE１のパケットフロー又はベアラのアップリンク及びダウンリンク転送ポイントをスライスＡ及びＢ（i.e., NFs for slice A５２及びNFs for slice B５３）から共通ネットワークスライス（i.e., Common NFs５１）に切り替えるために、NFs for slice A５２及びNFs for slice B５３にフロー修正（又はベアラ修正）をトリガーする。
　ステップ１８０７及び１８０８は、図１７のステップ１７１０及び１７１１に対応する。ステップ１８０７では、Common NFs５１は、NR Path Switch Request AcknowledgeメッセージをターゲットNR NB７に送る。ステップ１８０８では、ターゲットNR NB７は、NR DL Information TransferメッセージをUE１に送る。NR Path Switch Request Acknowledgeメッセージ及びNR DL Information Transferメッセージは、UE１にネットワークスライシングが適用されないことを明示的または暗示的に示す情報を包含してもよい。
　以上の説明から理解されるように、本実施形態で説明された幾つかのIntra-NRハンドオーバ手順は、ネットワークスライシングをサポートする無線通信ネットワークにおけるUE１のハンドオーバを可能とする。特に、図１５～図１８を参照して説明された幾つかのIntra-NRハンドオーバ手順は、ソースセル／ソースNR NB６及びターゲットセル／ターゲットNR NB７のうちの一方にネットワークスライシングが適用されないケースにおけるUE１のハンドオーバを可能とする。
　続いて以下では、上述の複数の実施形態に係るUE１、LTE eNB２、NR NB３、NR NB６、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., 制御ノード及び転送ノード）と通信するために使用される。ネットワークインターフェース２００３は、例えば、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 NBs６及び７も、図２１の構成を有してもよい。図２１を参照すると、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３の処理を行うよう構成されてもよい。
　図２２は、上述の実施形態に係るコアネットワークノード２２００の構成例を示すブロック図である。コアネットワークノード２２００は、例えば、NG Core５内の制御ノード（e.g., Common NFs５１）である。図２２を参照すると、コアネットワークノード２２００は、ネットワークインターフェース２２０１、プロセッサ２２０２、及びメモリ２２０３を含む。ネットワークインターフェース２２０１は、ネットワークノード（e.g., RANノード、他のコアネットワークノード）と通信するために使用される。ネットワークインターフェース２２０１は、例えば、IEEE 802.3 seriesに準拠したネットワークインタフェースカード（NIC）を含んでもよい。
　プロセッサ２２０２は、例えば、マイクロプロセッサ、MPU、又はCPUであってもよい。プロセッサ２２０２は、複数のプロセッサを含んでもよい。
　メモリ２２０３は、揮発性メモリ及び不揮発性メモリの組み合わせによって構成される。揮発性メモリは、例えば、SRAM若しくはDRAM又はこれらの組み合わせである。不揮発性メモリは、例えば、MROM、PROM、フラッシュメモリ、若しくはハードディスクドライブ、又はこれらの組合せである。メモリ２２０３は、プロセッサ２２０２から離れて配置されたストレージを含んでもよい。この場合、プロセッサ２２０２は、ネットワークインターフェース２２０１又は図示されていないI/Oインタフェースを介してメモリ２２０３にアクセスしてもよい。
　メモリ２２０３は、上述の複数の実施形態で説明されたコアネットワークノード（e.g., 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., NG2メッセージ）、及びソース基地局とターゲット基地局の間の制御メッセージ（i.e., X3メッセージ）の具体例が説明される。
　図２３Ａ及び図２３Ｂは、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２からターゲットNR NB３にダイレクト基地局間インタフェース１０１（X3インタフェース）上で送られるX3AP: NR Handover Requestメッセージのフォーマットの一例を示している。このNR Handover Requestメッセージは、NG Core５内の制御ノード（Common NF (CNF)）の識別子（i.e., Globally Unique CNF ID（GUCNFI））を含む。さらに、このNR Handover Requestメッセージは、UE Context Informationを含む。
　図２５は、UE Context Informationのフォーマットの一例を示している。図２５の例では、UE Context Informationは、NE-RABs To Be Setup Listを含む。NE-RABs To Be Setup Listは、ターゲットNR NB３においてセットアップされるべき無線アクセスベアラ（NE-RABs）のリストを示す。図２５に示されたフォーマットは、NR NB３及びNG Core５を含むNG SystemがQoSクラス毎且つPDUセッション毎のベアラを用いるベアラベースド転送をサポートするよう構成される場合に使用されてもよい。
　図２５に示されたUE Context Informationは、さらに、RRC Contextを含む。RRC Contextは、RRC Handover Preparation Information messageを含む。RRC Handover Preparation Information messageは、NGシステム内でUE１と通信するためのリソース及びセキュリティ関連設定を実施するためにターゲットNR NB３によって使用される。
　さらにまた、図３５に示されたUE Context Informationは、ネットワークスライシングの為の支援情報（Assistance Data for Network Slicing）を含んでもよい。ソースLTE eNB２は、UE１又はNG Core５から受信したAssistance Data for Network Slicing をE Context Informationに含めてもよい。
　図２６は、図２Ａのステップ２０３においてターゲットNR NB３からソースLTE eNBにダイレクト基地局間インタフェース１０１（X3インタフェース）上で送られるX3AP: NR Handover Request Acknowledgeメッセージのフォーマットの一例を示している。このNR Handover Commandメッセージは、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メッセージは、NE-RABs Admitted Listを含む。NE-RABs Admitted Listは、リソースがターゲットセルにおいて準備された無線アクセスベアラ（NE-RABs）のリストを示す。
　図２７は、図３Ａのステップ３０５においてターゲットNR NB３からソースLTE eNBにダイレクト基地局間インタフェース１０１（X3インタフェース）上で送られるX3AP: NR Handover Request Acknowledgeメッセージのフォーマットの一例を示している。図２７に示されたフォーマットは、コアネットワーク・コンテキスト情報（NG Core Context）を含む点で図２６に示されたフォーマットと異なる。NG Core Contextは、ソースLTE eNB２に透過的に、UE１へ送信されてもよい。さらに、又はこれに代えて、NG Core Contextの一部又は全てが、Target To Source Transparent Containerに包含されてもよい。図２８は、NG Core Contextのフォーマットの一例を示している。第１の実施形態で説明したように、NG Core Informationは、例えば、スライス情報、及びフロー情報（又はPDUセッション情報）を含む。
　図２９は、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）又は両方を含んでもよい。
　図３０は、Flow Informationのフォーマットの一例を示している。第１の実施形態において詳細に説明したように、Flow Informationは、UE１の少なくとも１つのパケットフロー（i.e., PDU flow(s)）を転送するためにNG system内で確立される少なくとも１つのセッション（i.e., PDU session(s)）に関する情報（PDU session Information List）を含む。Flow Informationは、セッション識別子（e.g., PDU Session ID）、並びにNG Core５内の転送ノードのアドレス（Transport Layer Address）及びアップリンク（UL）のSession Endpoint ID（SIED）を含む。
　図３１は、Session Endpoint IDのフォーマットの一例を示している。第１の実施形態において詳細に説明したように、Session Endpoint IDは、GTP-TEID、GRE-TEID、又はネットワーク機能若しくはノードの識別子（NF ID）であってもよい。
＜その他の実施形態＞
　上述の実施形態は、各々独立に実施されてもよいし、実施形態全体又はその一部が適宜組み合わせて実施されてもよい。
　上述の実施形態は、LTE eNB２及びNR NB３が共にNG Core５に接続されるネットワークの構成例に基づいて説明された。これに代えて、LTE eNB２は、NG Systemとのインターワーキングするよう改良されたEPC（enhanced EPC（eEPC））に接続されてもよい。eEPC内の(e)MMEは、コントロールプレーン・インタフェースを介してNG Core５内の制御ノード（i.e., CPFノード）に接続されてもよい。さらに、eEPC内の１又は複数のノードは、ユーザプレーン・インタフェースを介してNG Core５内の１又は複数のデータノード（i.e., UPFノード）に接続されてもよい。
　上述の実施形態で説明された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５は、Handover Preparation Requiredメッセージ又はNR Path Switch Requestメッセージの受信に応答して、ASレイヤ又は機能のNR NB３のDUとRUへの振り分けを決定してもよい。これに代えて、NR NB３が、ASサブレイヤ又は機能のNR NB３のDUとRUへの振り分けを決定してもよい。NG Core５又はNR NB ３は、NR NB ３に適用される１つの機能分離オプションを予め定められた複数の機能分離オプションから選択してもよい。
　一例において、NR NB ３に適用される機能分離オプションは、Handover Preparation Requiredメッセージ又はNR Path Switch Requestメッセージに含まれる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メッセージを前記第１のネットワーク内のソースRANノードからダイレクト・インタフェース上で受信するよう構成され、
　前記handover requestメッセージの受信に応答して、スライス情報及びフロー情報のうち少なくとも１つをコアネットワークから受信するよう構成され、
　前記スライス情報及びフロー情報のうち少なくとも１つに基づいて、前記無線端末の通信を制御するよう構成され、
　前記スライス情報は、前記無線端末が接続する前記第２のネットワーク内のネットワークスライスに関し、
　前記フロー情報は、前記無線端末の少なくとも１つのパケットフローを転送するためにベアラレス・ネットワークとしての前記第２のネットワーク内で確立される少なくとも１つのセッションに関する、
ターゲットRANノード。
（付記２）
　前記スライス情報は、（ａ）前記無線端末のために選択されたネットワークスライスの識別情報、（ｂ）前記無線端末のために選択されたネットワークスライスの種別情報、若しくは（ｃ）前記無線端末のために選択されたネットワークスライスに関連付けられたネットワークノード又はネットワーク機能の識別情報、又はこれらの任意の組合せを含む、
付記１に記載のターゲットRANノード。
（付記３）
　前記スライス情報は、前記無線端末のために選択されたネットワークスライスがサポートするモビリティ・クラス若しくはセッション・クラス又は両方を含む、付記１又は２に記載のターゲットRANノード。
（付記４）
　前記フロー情報は、前記無線端末の各パケットフローに関して、フロー識別子及びフローQoSパラメータを含む、
付記１～３のいずれか１項に記載のターゲットRANノード。
（付記５）
　前記少なくとも１つのプロセッサは、前記無線端末が前記ターゲットRANノードに接続した後のハンドオーバ完了フェーズにおいて、前記スライス情報及びフロー情報のうち少なくとも１つを前記コアネットワークから受信するよう構成されている、
付記１～４のいずれか１項に記載のターゲットRANノード。
（付記６）
　前記handover requestメッセージは、前記ソースRANノードによって導出されたセキュリティパラメータを含み、
　前記少なくとも１つのプロセッサは、前記セキュリティパラメータからAccess Stratum（AS）セキュリティ鍵を導出するよう構成されている、
付記５に記載のターゲットRANノード。
（付記７）
　前記少なくとも１つのプロセッサは、前記ハンドオーバ完了フェーズにおいて、path switch requestメッセージを前記コアネットワークに送信するよう構成され、
　前記path switch requestメッセージは、前記無線端末のためのネットワークスライスを選択又は生成するよう前記コアネットワークをトリガーする、
付記５又は６に記載のターゲットRANノード。
（付記８）
　前記少なくとも１つのプロセッサは、前記ハンドオーバ完了フェーズにおいて、path switch requestメッセージを前記コアネットワークに送信するよう構成され、
　前記path switch requestメッセージは、前記無線端末のためのベアラレス・セッションを生成するよう前記コアネットワークをトリガーする、
付記５又は６に記載のターゲットRANノード。
（付記９）
　前記少なくとも１つのプロセッサは、前記スライス情報及びフロー情報のうち少なくとも１つを前記無線端末に送信するよう構成されている、
付記５～８のいずれか１項に記載のターゲットRANノード。
（付記１０）
　前記少なくとも１つのプロセッサは、前記ソースRANノードによる前記無線端末へのハンドオーバの指示より前のハンドオーバ準備フェーズにおいて、前記スライス情報及びフロー情報のうち少なくとも１つを前記コアネットワークから受信するよう構成されている、
付記１～４のいずれか１項に記載のターゲットRANノード。
（付記１１）
　前記少なくとも１つのプロセッサは、前記スライス情報に基づいて、前記無線端末のベアラ毎またはフロー毎に、ベアラ又はフローを受け入れるか否かを決定するよう構成されている、
付記１０に記載のターゲットRANノード。
（付記１２）
　前記少なくとも１つのプロセッサは、前記スライス情報に基づいて、各ネットワークスライスを受け入れることが可能か否かを決定するよう構成されている、
付記１０又は１１に記載のターゲットRANノード。
（付記１３）
　前記少なくとも１つのプロセッサは、前記ハンドオーバ準備フェーズにおいて、Non-Access Stratum（NAS）セキュリティ設定情報と、Access Stratum（AS）セキュリティ鍵の導出のために前記ターゲットRANノードによって使用されるセキュリティパラメータとを前記コアネットワークからさらに受信するよう構成されている、
付記１０～１２のいずれか１項に記載のターゲットRANノード。
（付記１４）
　前記少なくとも１つのプロセッサは、transparent containerを包含するhandover request acknowledgeメッセージを、前記ダイレクト・インタフェース上で前記ソースRANノードに送信するよう構成され、
　前記transparent containerは、前記スライス情報及びフロー情報のうち少なくとも１つに含まれる所定のパラメータ若しくは前記スライス情報及びフロー情報のうち少なくとも１つに基づいて生成された無線リソース設定情報又はこれら両方を包含し、且つ前記ソースRANノードによって前記無線端末に向けてフォワードされる、
付記１０～１３のいずれか１項に記載のターゲットRANノード。
（付記１５）
　前記少なくとも１つのプロセッサは、前記ハンドオーバ準備フェーズにおいて、前記スライス情報及びフロー情報のうち少なくとも１つの送信を要求する要求メッセージを前記コアネットワークに送信するよう構成され、
　前記要求メッセージは、前記無線端末のためのネットワークスライスを選択又は生成するよう前記コアネットワークをトリガーする、
付記１０～１４のいずれか１項に記載のターゲットRANノード。
（付記１６）
　前記少なくとも１つのプロセッサは、前記ハンドオーバ準備フェーズにおいて、前記スライス情報及びフロー情報のうち少なくとも１つの送信を要求する要求メッセージを前記コアネットワークに送信するよう構成され、
　前記要求メッセージは、前記無線端末のためのベアラレス・セッションを生成するよう前記コアネットワークをトリガーする、
付記１０～１４のいずれか１項に記載のターゲットRANノード。
（付記１７）
　第１のネットワークに関連付けられたソース無線アクセスネットワーク（RAN）ノードであって、
　少なくとも１つのメモリと、
　前記少なくとも１つのメモリに結合された少なくとも１つのプロセッサと、
を備え、
　前記少なくとも１つのプロセッサは、
　前記第１のネットワークから第２のネットワークへの無線端末のハンドオーバを決定するよう構成され、
　前記ハンドオーバの決定に応答して、前記第２のネットワークへの無線端末のハンドオーバを要求するhandover requestメッセージを前記第２のネットワーク内のターゲットRANノードにダイレクト・インタフェース上で送信するよう構成され、
　transparent containerを包含するhandover request acknowledgeメッセージを、前記ダイレクト・インタフェース上で前記ターゲットRANノードから受信するよう構成され、
　前記transparent containerを包含し且つ前記第２のネットワークへのハンドオーバを示すmobility commandメッセージを前記無線端末に送信するよう構成され、
　前記transparent containerは、前記第２のネットワークに関連付けられた無線コネクションを確立するために前記無線端末にとって必要となる無線リソース設定情報を含み、
　前記無線リソース設定情報は、（ａ）前記無線端末が接続する前記第２のネットワーク内のネットワークスライスに関するスライス情報に基づいて生成された第１の無線リソース設定情報、及び（ｂ）前記無線端末の少なくとも１つのパケットフローを転送するためにベアラレス・ネットワークとしての前記第２のネットワーク内で確立される少なくとも１つのセッションに関するフロー情報に基づいて生成された第２の無線リソース設定情報のうち少なくとも１つを含む、
ソースRANノード。
（付記１８）
　前記少なくとも１つのプロセッサは、前記第１のネットワークで使用される第１のセキュリティパラメータから、前記第２のネットワークで使用される第２のセキュリティパラメータを導出し、前記第２のセキュリティパラメータを前記handover requestメッセージに含めるよう構成され、
　前記第２のセキュリティパラメータは、前記第２のネットワークでのAccess Stratum（AS）セキュリティ鍵の導出のために前記ターゲットRANノードによって使用される、
付記１７に記載のソースRANノード。
（付記１９）
　第２のネットワークに関連付けられたターゲット無線アクセスネットワーク（RAN）ノードにおける方法であって、
　第１のネットワークから前記第２のネットワークへの無線端末のハンドオーバを要求するhandover requestメッセージを前記第１のネットワーク内のソースRANノードからダイレクト・インタフェース上で受信すること、
　前記handover requestメッセージの受信に応答して、スライス情報及びフロー情報のうち少なくとも１つをコアネットワークから受信すること、及び
　前記スライス情報及びフロー情報のうち少なくとも１つに基づいて、前記無線端末の通信を制御すること、
を備え、
　前記スライス情報は、前記無線端末が接続する前記第２のネットワーク内のネットワークスライスに関し、
　前記フロー情報は、前記無線端末の少なくとも１つのパケットフローを転送するためにベアラレス・ネットワークとしての前記第２のネットワーク内で確立される少なくとも１つのセッションに関する、
方法。
（付記２０）
　第１のネットワークに関連付けられたソース無線アクセスネットワーク（RAN）ノードにおける方法であって、
　前記第１のネットワークから第２のネットワークへの無線端末のハンドオーバを決定すること、
　前記ハンドオーバの決定に応答して、前記第２のネットワークへの無線端末のハンドオーバを要求するhandover requestメッセージを前記第２のネットワーク内のターゲットRANノードにダイレクト・インタフェース上で送信すること、
　transparent containerを包含するhandover request acknowledgeメッセージを、前記ダイレクト・インタフェース上で前記ターゲットRANノードから受信すること、及び
　前記transparent containerを包含し且つ前記第２のネットワークへのハンドオーバを示すmobility commandメッセージを前記無線端末に送信すること、
を備え、
　前記transparent containerは、前記第２のネットワークに関連付けられた無線コネクションを確立するために前記無線端末にとって必要となる無線リソース設定情報を含み、
　前記無線リソース設定情報は、（ａ）前記無線端末が接続する前記第２のネットワーク内のネットワークスライスに関するスライス情報に基づいて生成された第１の無線リソース設定情報、及び（ｂ）前記無線端末の少なくとも１つのパケットフローを転送するためにベアラレス・ネットワークとしての前記第２のネットワーク内で確立される少なくとも１つのセッションに関するフロー情報に基づいて生成された第２の無線リソース設定情報のうち少なくとも１つを含む、
方法。
（付記２１）
　第２のネットワークに関連付けられたターゲット無線アクセスネットワーク（RAN）ノードにおける方法をコンピュータに行わせるためのプログラムであって、
　前記方法は、
　第１のネットワークから前記第２のネットワークへの無線端末のハンドオーバを要求するhandover requestメッセージを前記第１のネットワーク内のソースRANノードからダイレクト・インタフェース上で受信すること、
　前記handover requestメッセージの受信に応答して、スライス情報及びフロー情報のうち少なくとも１つをコアネットワークから受信すること、及び
　前記スライス情報及びフロー情報のうち少なくとも１つに基づいて、前記無線端末の通信を制御すること、
を備え、
　前記スライス情報は、前記無線端末が接続する前記第２のネットワーク内のネットワークスライスに関し、
　前記フロー情報は、前記無線端末の少なくとも１つのパケットフローを転送するためにベアラレス・ネットワークとしての前記第２のネットワーク内で確立される少なくとも１つのセッションに関する、
プログラム。
（付記２２）
　第１のネットワークに関連付けられたソース無線アクセスネットワーク（RAN）ノードにおける方法をコンピュータに行わせるためのプログラムであって、
　前記方法は、
　前記第１のネットワークから第２のネットワークへの無線端末のハンドオーバを決定すること、
　前記ハンドオーバの決定に応答して、前記第２のネットワークへの無線端末のハンドオーバを要求するhandover requestメッセージを前記第２のネットワーク内のターゲットRANノードにダイレクト・インタフェース上で送信すること、
　transparent containerを包含するhandover request acknowledgeメッセージを、前記ダイレクト・インタフェース上で前記ターゲットRANノードから受信すること、及び
　前記transparent containerを包含し且つ前記第２のネットワークへのハンドオーバを示すmobility commandメッセージを前記無線端末に送信すること、
を備え、
　前記transparent containerは、前記第２のネットワークに関連付けられた無線コネクションを確立するために前記無線端末にとって必要となる無線リソース設定情報を含み、
　前記無線リソース設定情報は、（ａ）前記無線端末が接続する前記第２のネットワーク内のネットワークスライスに関するスライス情報に基づいて生成された第１の無線リソース設定情報、及び（ｂ）前記無線端末の少なくとも１つのパケットフローを転送するためにベアラレス・ネットワークとしての前記第２のネットワーク内で確立される少なくとも１つのセッションに関するフロー情報に基づいて生成された第２の無線リソース設定情報のうち少なくとも１つを含む、
プログラム。
（付記２３）
　無線端末であって、
　少なくとも１つのメモリと、
　前記少なくとも１つのメモリに結合された少なくとも１つのプロセッサと、
を備え、
　前記少なくとも１つのプロセッサは、前記無線端末が接続する第１のネットワークから第２のネットワークへのハンドオーバにおいて、前記第２のネットワーク内のネットワークスライスに関するスライス情報及び前記第２のネットワーク内のネットワークスライスに基づく無線リソース設定情報の少なくとも一方を包含するハンドオーバに関するメッセージを前記第１のネットワークの無線アクセスネットワーク（RAN）ノードから受信するよう構成される、無線端末。
（付記２４）
　前記少なくとも１つのプロセッサは、
　前記第１のネットワークから前記第２のネットワークへのハンドオーバを示すmobility commandメッセージを前記RANノードから受信するよう構成され、前記mobility commandメッセージは、前記第２のネットワークに関連付けられたターゲットRANノードにより生成され、前記無線端末が接続される前記第２のネットワーク内のネットワークスライスに関連付けられた無線コネクションを確立するために前記無線端末にとって必要となる無線リソース設定情報を包含し；
　前記無線リソース設定情報を用いて、前記第２のネットワークに関連付けられた前記ターゲットRANノードとの前記無線コネクションを確立するよう構成されている、
付記２３に記載の無線端末。
（付記２５）
　前記ハンドオーバに関するメッセージは、さらに、前記無線端末の少なくとも１つのパケットフローを転送するために前記第２のネットワーク内で確立される少なくとも１つのセッションに関するフロー情報、及び前記フロー情報から導かれる無線リソース設定情報
のうち少なくとも一方を含む、
付記２３又は２４に記載の無線端末。
（付記２６）
　コアネットワークノードであって、
　少なくとも１つのメモリと、
　前記少なくとも１つのメモリに結合された少なくとも１つのプロセッサと、
を備え、
　前記少なくとも１つのプロセッサは、第１のネットワークから第２のネットワークへの無線端末のハンドオーバにおいて、前記無線端末が接続される前記第２のネットワーク内のネットワークスライスに関するスライス情報を前記第２のネットワークに関連付けられたターゲット無線アクセスネットワーク（RAN）ノードに送るよう構成される、
コアネットワークノード。
（付記２７）
　前記少なくとも１つのプロセッサは、さらに、前記第１のネットワークから前記第２のネットワークへの前記無線端末のハンドオーバにおいて、前記無線端末の少なくとも１つのパケットフローを転送するために前記第２のネットワーク内で確立される少なくとも１つのセッションに関するフロー情報を前記ターゲットRANノードに送るよう構成される、
付記２６に記載のコアネットワークノード。
（付記２８）
　前記少なくとも１つのプロセッサは、ソースRANノードによる前記無線端末へのハンドオーバの指示より前のハンドオーバ準備フェーズにおいて、前記スライス情報を前記ターゲットRANノードに送るよう構成される、
付記２６又は２７に記載のコアネットワークノード。
（付記２９）
　前記少なくとも１つのプロセッサは、前記無線端末が前記ターゲットRANノードに接続した後のハンドオーバ完了フェーズにおいて、前記スライス情報を前記ターゲットRANノードに送るよう構成される、
付記２６又は２７に記載のコアネットワークノード。
　この出願は、２０１６年８月１０日に出願された日本出願特願２０１６－１５８２８２を基礎とする優先権を主張し、その開示の全てをここに取り込む。
１　User Equipment (UE)
２　LTE eNodeB (eNB)
３　New Radio (NR) NodeB (NB)
５　NextGen (NG) Core
６　New Radio (NR) NodeB (NB)
７　New Radio (NR) NodeB (NB)
１９０５　ベースバンドプロセッサ
１９０６　アプリケーションプロセッサ
１９０８　メモリ
２００４　プロセッサ
２００５　メモリ
２１０４　プロセッサ
２１０５　メモリ
２２０２　プロセッサ
２２０３　メモリ

Claims (29)

  1. 　第２のネットワークに関連付けられたターゲット無線アクセスネットワーク（RAN）ノードであって、
    　少なくとも１つのメモリと、
    　前記少なくとも１つのメモリに結合された少なくとも１つのプロセッサと、
    を備え、
    　前記少なくとも１つのプロセッサは、
    　第１のネットワークから前記第２のネットワークへの無線端末のハンドオーバを要求するhandover requestメッセージを前記第１のネットワーク内のソースRANノードからダイレクト・インタフェース上で受信するよう構成され、
    　前記handover requestメッセージの受信に応答して、スライス情報及びフロー情報のうち少なくとも１つをコアネットワークから受信するよう構成され、
    　前記スライス情報及びフロー情報のうち少なくとも１つに基づいて、前記無線端末の通信を制御するよう構成され、
    　前記スライス情報は、前記無線端末が接続する前記第２のネットワーク内のネットワークスライスに関し、
    　前記フロー情報は、前記無線端末の少なくとも１つのパケットフローを転送するためにベアラレス・ネットワークとしての前記第２のネットワーク内で確立される少なくとも１つのセッションに関する、
    ターゲットRANノード。
  2. 　前記スライス情報は、（ａ）前記無線端末のために選択されたネットワークスライスの識別情報、（ｂ）前記無線端末のために選択されたネットワークスライスの種別情報、若しくは（ｃ）前記無線端末のために選択されたネットワークスライスに関連付けられたネットワークノード又はネットワーク機能の識別情報、又はこれらの任意の組合せを含む、
    請求項１に記載のターゲットRANノード。
  3. 　前記スライス情報は、前記無線端末のために選択されたネットワークスライスがサポートするモビリティ・クラス若しくはセッション・クラス又は両方を含む、請求項１又は２に記載のターゲットRANノード。
  4. 　前記フロー情報は、前記無線端末の各パケットフローに関して、フロー識別子及びフローQoSパラメータを含む、
    請求項１～３のいずれか１項に記載のターゲットRANノード。
  5. 　前記少なくとも１つのプロセッサは、前記無線端末が前記ターゲットRANノードに接続した後のハンドオーバ完了フェーズにおいて、前記スライス情報及びフロー情報のうち少なくとも１つを前記コアネットワークから受信するよう構成されている、
    請求項１～４のいずれか１項に記載のターゲットRANノード。
  6. 　前記handover requestメッセージは、前記ソースRANノードによって導出されたセキュリティパラメータを含み、
    　前記少なくとも１つのプロセッサは、前記セキュリティパラメータからAccess Stratum（AS）セキュリティ鍵を導出するよう構成されている、
    請求項５に記載のターゲットRANノード。
  7. 　前記少なくとも１つのプロセッサは、前記ハンドオーバ完了フェーズにおいて、path switch requestメッセージを前記コアネットワークに送信するよう構成され、
    　前記path switch requestメッセージは、前記無線端末のためのネットワークスライスを選択又は生成するよう前記コアネットワークをトリガーする、
    請求項５又は６に記載のターゲットRANノード。
  8. 　前記少なくとも１つのプロセッサは、前記ハンドオーバ完了フェーズにおいて、path switch requestメッセージを前記コアネットワークに送信するよう構成され、
    　前記path switch requestメッセージは、前記無線端末のためのベアラレス・セッションを生成するよう前記コアネットワークをトリガーする、
    請求項５又は６に記載のターゲットRANノード。
  9. 　前記少なくとも１つのプロセッサは、前記スライス情報及びフロー情報のうち少なくとも１つを前記無線端末に送信するよう構成されている、
    請求項５～８のいずれか１項に記載のターゲットRANノード。
  10. 　前記少なくとも１つのプロセッサは、前記ソースRANノードによる前記無線端末へのハンドオーバの指示より前のハンドオーバ準備フェーズにおいて、前記スライス情報及びフロー情報のうち少なくとも１つを前記コアネットワークから受信するよう構成されている、
    請求項１～４のいずれか１項に記載のターゲットRANノード。
  11. 　前記少なくとも１つのプロセッサは、前記スライス情報に基づいて、前記無線端末のベアラ毎またはフロー毎に、ベアラ又はフローを受け入れるか否かを決定するよう構成されている、
    請求項１０に記載のターゲットRANノード。
  12. 　前記少なくとも１つのプロセッサは、前記スライス情報に基づいて、各ネットワークスライスを受け入れることが可能か否かを決定するよう構成されている、
    請求項１０又は１１に記載のターゲットRANノード。
  13. 　前記少なくとも１つのプロセッサは、前記ハンドオーバ準備フェーズにおいて、Non-Access Stratum（NAS）セキュリティ設定情報と、Access Stratum（AS）セキュリティ鍵の導出のために前記ターゲットRANノードによって使用されるセキュリティパラメータとを前記コアネットワークからさらに受信するよう構成されている、
    請求項１０～１２のいずれか１項に記載のターゲットRANノード。
  14. 　前記少なくとも１つのプロセッサは、transparent containerを包含するhandover request acknowledgeメッセージを、前記ダイレクト・インタフェース上で前記ソースRANノードに送信するよう構成され、
    　前記transparent containerは、前記スライス情報及びフロー情報のうち少なくとも１つに含まれる所定のパラメータ若しくは前記スライス情報及びフロー情報のうち少なくとも１つに基づいて生成された無線リソース設定情報又はこれら両方を包含し、且つ前記ソースRANノードによって前記無線端末に向けてフォワードされる、
    請求項１０～１３のいずれか１項に記載のターゲットRANノード。
  15. 　前記少なくとも１つのプロセッサは、前記ハンドオーバ準備フェーズにおいて、前記スライス情報及びフロー情報のうち少なくとも１つの送信を要求する要求メッセージを前記コアネットワークに送信するよう構成され、
    　前記要求メッセージは、前記無線端末のためのネットワークスライスを選択又は生成するよう前記コアネットワークをトリガーする、
    請求項１０～１４のいずれか１項に記載のターゲットRANノード。
  16. 　前記少なくとも１つのプロセッサは、前記ハンドオーバ準備フェーズにおいて、前記スライス情報及びフロー情報のうち少なくとも１つの送信を要求する要求メッセージを前記コアネットワークに送信するよう構成され、
    　前記要求メッセージは、前記無線端末のためのベアラレス・セッションを生成するよう前記コアネットワークをトリガーする、
    請求項１０～１４のいずれか１項に記載のターゲットRANノード。
  17. 　第１のネットワークに関連付けられたソース無線アクセスネットワーク（RAN）ノードであって、
    　少なくとも１つのメモリと、
    　前記少なくとも１つのメモリに結合された少なくとも１つのプロセッサと、
    を備え、
    　前記少なくとも１つのプロセッサは、
    　前記第１のネットワークから第２のネットワークへの無線端末のハンドオーバを決定するよう構成され、
    　前記ハンドオーバの決定に応答して、前記第２のネットワークへの無線端末のハンドオーバを要求するhandover requestメッセージを前記第２のネットワーク内のターゲットRANノードにダイレクト・インタフェース上で送信するよう構成され、
    　transparent containerを包含するhandover request acknowledgeメッセージを、前記ダイレクト・インタフェース上で前記ターゲットRANノードから受信するよう構成され、
    　前記transparent containerを包含し且つ前記第２のネットワークへのハンドオーバを示すmobility commandメッセージを前記無線端末に送信するよう構成され、
    　前記transparent containerは、前記第２のネットワークに関連付けられた無線コネクションを確立するために前記無線端末にとって必要となる無線リソース設定情報を含み、
    　前記無線リソース設定情報は、（ａ）前記無線端末が接続する前記第２のネットワーク内のネットワークスライスに関するスライス情報に基づいて生成された第１の無線リソース設定情報、及び（ｂ）前記無線端末の少なくとも１つのパケットフローを転送するためにベアラレス・ネットワークとしての前記第２のネットワーク内で確立される少なくとも１つのセッションに関するフロー情報に基づいて生成された第２の無線リソース設定情報のうち少なくとも１つを含む、
    ソースRANノード。
  18. 　前記少なくとも１つのプロセッサは、前記第１のネットワークで使用される第１のセキュリティパラメータから、前記第２のネットワークで使用される第２のセキュリティパラメータを導出し、前記第２のセキュリティパラメータを前記handover requestメッセージに含めるよう構成され、
    　前記第２のセキュリティパラメータは、前記第２のネットワークでのAccess Stratum（AS）セキュリティ鍵の導出のために前記ターゲットRANノードによって使用される、
    請求項１７に記載のソースRANノード。
  19. 　第２のネットワークに関連付けられたターゲット無線アクセスネットワーク（RAN）ノードにおける方法であって、
    　第１のネットワークから前記第２のネットワークへの無線端末のハンドオーバを要求するhandover requestメッセージを前記第１のネットワーク内のソースRANノードからダイレクト・インタフェース上で受信すること、
    　前記handover requestメッセージの受信に応答して、スライス情報及びフロー情報のうち少なくとも１つをコアネットワークから受信すること、及び
    　前記スライス情報及びフロー情報のうち少なくとも１つに基づいて、前記無線端末の通信を制御すること、
    を備え、
    　前記スライス情報は、前記無線端末が接続する前記第２のネットワーク内のネットワークスライスに関し、
    　前記フロー情報は、前記無線端末の少なくとも１つのパケットフローを転送するためにベアラレス・ネットワークとしての前記第２のネットワーク内で確立される少なくとも１つのセッションに関する、
    方法。
  20. 　第１のネットワークに関連付けられたソース無線アクセスネットワーク（RAN）ノードにおける方法であって、
    　前記第１のネットワークから第２のネットワークへの無線端末のハンドオーバを決定すること、
    　前記ハンドオーバの決定に応答して、前記第２のネットワークへの無線端末のハンドオーバを要求するhandover requestメッセージを前記第２のネットワーク内のターゲットRANノードにダイレクト・インタフェース上で送信すること、
    　transparent containerを包含するhandover request acknowledgeメッセージを、前記ダイレクト・インタフェース上で前記ターゲットRANノードから受信すること、及び
    　前記transparent containerを包含し且つ前記第２のネットワークへのハンドオーバを示すmobility commandメッセージを前記無線端末に送信すること、
    を備え、
    　前記transparent containerは、前記第２のネットワークに関連付けられた無線コネクションを確立するために前記無線端末にとって必要となる無線リソース設定情報を含み、
    　前記無線リソース設定情報は、（ａ）前記無線端末が接続する前記第２のネットワーク内のネットワークスライスに関するスライス情報に基づいて生成された第１の無線リソース設定情報、及び（ｂ）前記無線端末の少なくとも１つのパケットフローを転送するためにベアラレス・ネットワークとしての前記第２のネットワーク内で確立される少なくとも１つのセッションに関するフロー情報に基づいて生成された第２の無線リソース設定情報のうち少なくとも１つを含む、
    方法。
  21. 　第２のネットワークに関連付けられたターゲット無線アクセスネットワーク（RAN）ノードにおける方法をコンピュータに行わせるためのプログラムを格納した非一時的なコンピュータ可読媒体であって、
    　前記方法は、
    　第１のネットワークから前記第２のネットワークへの無線端末のハンドオーバを要求するhandover requestメッセージを前記第１のネットワーク内のソースRANノードからダイレクト・インタフェース上で受信すること、
    　前記handover requestメッセージの受信に応答して、スライス情報及びフロー情報のうち少なくとも１つをコアネットワークから受信すること、及び
    　前記スライス情報及びフロー情報のうち少なくとも１つに基づいて、前記無線端末の通信を制御すること、
    を備え、
    　前記スライス情報は、前記無線端末が接続する前記第２のネットワーク内のネットワークスライスに関し、
    　前記フロー情報は、前記無線端末の少なくとも１つのパケットフローを転送するためにベアラレス・ネットワークとしての前記第２のネットワーク内で確立される少なくとも１つのセッションに関する、
    非一時的なコンピュータ可読媒体。
  22. 　第１のネットワークに関連付けられたソース無線アクセスネットワーク（RAN）ノードにおける方法をコンピュータに行わせるためのプログラムを格納した非一時的なコンピュータ可読媒体であって、
    　前記方法は、
    　前記第１のネットワークから第２のネットワークへの無線端末のハンドオーバを決定すること、
    　前記ハンドオーバの決定に応答して、前記第２のネットワークへの無線端末のハンドオーバを要求するhandover requestメッセージを前記第２のネットワーク内のターゲットRANノードにダイレクト・インタフェース上で送信すること、
    　transparent containerを包含するhandover request acknowledgeメッセージを、前記ダイレクト・インタフェース上で前記ターゲットRANノードから受信すること、及び
    　前記transparent containerを包含し且つ前記第２のネットワークへのハンドオーバを示すmobility commandメッセージを前記無線端末に送信すること、
    を備え、
    　前記transparent containerは、前記第２のネットワークに関連付けられた無線コネクションを確立するために前記無線端末にとって必要となる無線リソース設定情報を含み、
    　前記無線リソース設定情報は、（ａ）前記無線端末が接続する前記第２のネットワーク内のネットワークスライスに関するスライス情報に基づいて生成された第１の無線リソース設定情報、及び（ｂ）前記無線端末の少なくとも１つのパケットフローを転送するためにベアラレス・ネットワークとしての前記第２のネットワーク内で確立される少なくとも１つのセッションに関するフロー情報に基づいて生成された第２の無線リソース設定情報のうち少なくとも１つを含む、
    非一時的なコンピュータ可読媒体。
  23. 　無線端末であって、
    　少なくとも１つのメモリと、
    　前記少なくとも１つのメモリに結合された少なくとも１つのプロセッサと、
    を備え、
    　前記少なくとも１つのプロセッサは、前記無線端末が接続する第１のネットワークから第２のネットワークへのハンドオーバにおいて、前記第２のネットワーク内のネットワークスライスに関するスライス情報及び前記第２のネットワーク内のネットワークスライスに基づく無線リソース設定情報の少なくとも一方を包含するハンドオーバに関するメッセージを前記第１のネットワークの無線アクセスネットワーク（RAN）ノードから受信するよう構成される、無線端末。
  24. 　前記少なくとも１つのプロセッサは、
    　前記第１のネットワークから前記第２のネットワークへのハンドオーバを示すmobility commandメッセージを前記RANノードから受信するよう構成され、前記mobility commandメッセージは、前記第２のネットワークに関連付けられたターゲットRANノードにより生成され、前記無線端末が接続される前記第２のネットワーク内のネットワークスライスに関連付けられた無線コネクションを確立するために前記無線端末にとって必要となる無線リソース設定情報を包含し；
    　前記無線リソース設定情報を用いて、前記第２のネットワークに関連付けられた前記ターゲットRANノードとの前記無線コネクションを確立するよう構成されている、
    請求項２３に記載の無線端末。
  25. 　前記ハンドオーバに関するメッセージは、さらに、前記無線端末の少なくとも１つのパケットフローを転送するために前記第２のネットワーク内で確立される少なくとも１つのセッションに関するフロー情報、及び前記フロー情報から導かれる無線リソース設定情報
    のうち少なくとも一方を含む、
    請求項２３又は２４に記載の無線端末。
  26. 　コアネットワークノードであって、
    　少なくとも１つのメモリと、
    　前記少なくとも１つのメモリに結合された少なくとも１つのプロセッサと、
    を備え、
    　前記少なくとも１つのプロセッサは、第１のネットワークから第２のネットワークへの無線端末のハンドオーバにおいて、前記無線端末が接続される前記第２のネットワーク内のネットワークスライスに関するスライス情報を前記第２のネットワークに関連付けられたターゲット無線アクセスネットワーク（RAN）ノードに送るよう構成される、
    コアネットワークノード。
  27. 　前記少なくとも１つのプロセッサは、さらに、前記第１のネットワークから前記第２のネットワークへの前記無線端末のハンドオーバにおいて、前記無線端末の少なくとも１つのパケットフローを転送するために前記第２のネットワーク内で確立される少なくとも１つのセッションに関するフロー情報を前記ターゲットRANノードに送るよう構成される、
    請求項２６に記載のコアネットワークノード。
  28. 　前記少なくとも１つのプロセッサは、ソースRANノードによる前記無線端末へのハンドオーバの指示より前のハンドオーバ準備フェーズにおいて、前記スライス情報を前記ターゲットRANノードに送るよう構成される、
    請求項２６又は２７に記載のコアネットワークノード。
  29. 　前記少なくとも１つのプロセッサは、前記無線端末が前記ターゲットRANノードに接続した後のハンドオーバ完了フェーズにおいて、前記スライス情報を前記ターゲットRANノードに送るよう構成される、
    請求項２６又は２７に記載のコアネットワークノード。
PCT/JP2017/018227 2016-08-10 2017-05-15 無線アクセスネットワークノード、無線端末、コアネットワークノード、及びこれらの方法 WO2018029931A1 (ja)

Priority Applications (8)

Application Number Priority Date Filing Date Title
EP17839006.8A EP3499964B1 (en) 2016-08-10 2017-05-15 Radio access network node, wireless terminal, core network node, and methods for these
EP20205291.6A EP3796713A1 (en) 2016-08-10 2017-05-15 Radio access network node, radio terminal, core network node, and method therefor
US16/321,998 US11910258B2 (en) 2016-08-10 2017-05-15 Radio access network node, radio terminal, core network node, and method therefor
CN201780048078.2A CN109565732B (zh) 2016-08-10 2017-05-15 无线接入网节点、无线终端、核心网节点及其方法
JP2018533427A JP6642720B2 (ja) 2016-08-10 2017-05-15 無線アクセスネットワークノード、無線端末、及び方法
EP21198971.0A EP3958615A1 (en) 2016-08-10 2017-05-15 Radio access network node, radio terminal, core network node, and method therefor
US17/385,428 US11765636B2 (en) 2016-08-10 2021-07-26 Radio access network node, radio terminal, core network node, and method therefor
US18/225,421 US20230370928A1 (en) 2016-08-10 2023-07-24 Radio access network node, radio terminal, core network node, and method therefor

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2016158282 2016-08-10
JP2016-158282 2016-08-10

Related Child Applications (2)

Application Number Title Priority Date Filing Date
US16/321,998 A-371-Of-International US11910258B2 (en) 2016-08-10 2017-05-15 Radio access network node, radio terminal, core network node, and method therefor
US17/385,428 Continuation US11765636B2 (en) 2016-08-10 2021-07-26 Radio access network node, radio terminal, core network node, and method therefor

Publications (1)

Publication Number Publication Date
WO2018029931A1 true WO2018029931A1 (ja) 2018-02-15

Family

ID=61162088

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2017/018227 WO2018029931A1 (ja) 2016-08-10 2017-05-15 無線アクセスネットワークノード、無線端末、コアネットワークノード、及びこれらの方法

Country Status (5)

Country Link
US (3) US11910258B2 (ja)
EP (3) EP3499964B1 (ja)
JP (5) JP6642720B2 (ja)
CN (4) CN114040455A (ja)
WO (1) WO2018029931A1 (ja)

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110278591A (zh) * 2018-03-14 2019-09-24 中兴通讯股份有限公司 地址协同方法、装置、基站、smf网元及存储介质
JPWO2018131414A1 (ja) * 2017-01-10 2019-11-07 株式会社Ｎｔｔドコモ 通信制御装置及び通信制御方法
WO2020018444A1 (en) * 2018-07-20 2020-01-23 Google Llc Network slicing for wlan
JPWO2019064383A1 (ja) * 2017-09-27 2020-10-22 富士通株式会社 基地局装置、端末装置、無線通信システム、及び無線通信方法
US10959133B2 (en) 2016-08-12 2021-03-23 China Academy Of Telecommunications Technology Method and device for processing quality of service parameter in handover scenario
JP2021525978A (ja) * 2018-05-31 2021-09-27 オッポ広東移動通信有限公司Ｇｕａｎｇｄｏｎｇ Ｏｐｐｏ Ｍｏｂｉｌｅ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ｃｏｒｐ．， Ｌｔｄ． 端末機能取得方法および装置、コンピュータ記憶媒体
EP3787342A4 (en) * 2018-06-22 2021-09-29 Huawei Technologies Co., Ltd. COMMUNICATION PROCEDURE AND RADIO CALL PROCEDURE, DEVICE AND SYSTEM

Families Citing this family (82)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113676972A (zh) 2016-08-10 2021-11-19 日本电气株式会社 无线接入网节点及其方法
EP3499966A4 (en) 2016-08-10 2019-06-19 Nec Corporation RADIO ACCESS NETWORK NODE, WIRELESS TERMINAL, AND ASSOCIATED METHODS
EP3499964B1 (en) 2016-08-10 2021-06-23 Nec Corporation Radio access network node, wireless terminal, core network node, and methods for these
BR112018017081B1 (pt) 2016-08-10 2024-01-30 Nec Corporation Nó ran alvo, nó de rede principal 5g de uma rede principal 5g, método em um nó ran alvo, e método de um nó de rede principal 5g de uma rede principal 5g
WO2018034042A1 (ja) * 2016-08-17 2018-02-22 株式会社Ｎｔｔドコモ 通信制御装置及び通信制御方法
CN108024294B (zh) 2016-11-02 2020-08-07 中兴通讯股份有限公司 切换方法及装置
US11039380B2 (en) * 2016-11-03 2021-06-15 Lg Electronics Inc. Method for moving from NGS to EPS in wireless communication system and apparatus therefor
WO2018124761A1 (ko) * 2016-12-29 2018-07-05 엘지전자 주식회사 무선 통신 시스템에서 빔을 지원하는 방법 및 장치
JP6808809B2 (ja) 2017-01-05 2021-01-06 エルジー エレクトロニクス インコーポレイティド ＱｏＳフロー対ＤＲＢマッピングに対する規則を送信する方法及び装置
CN110248382B (zh) 2017-01-05 2020-09-08 华为技术有限公司 信息传输的方法和装置
CN109561485B (zh) 2017-01-06 2020-01-17 华为技术有限公司 一种通信方法、接入网设备、核心网设备和用户设备
US11228949B2 (en) * 2017-01-06 2022-01-18 Samsung Electronics Co., Ltd. Intra-RAT handover for next generation system
US10470199B2 (en) * 2017-01-10 2019-11-05 Htc Corporation Device and method of handling a PDU session in inter-system mobility between a LTE system and a NR/5G system
WO2018134483A1 (en) * 2017-01-23 2018-07-26 Nokia Technologies Oy Method and apparatus for complementary and equivalent network slice deployment in a network environment
WO2018146056A1 (en) * 2017-02-07 2018-08-16 Telefonaktiebolaget Lm Ericsson (Publ) Bearer translation
EP3361777B1 (en) * 2017-02-09 2022-02-09 HTC Corporation Device and method for handling evolved long-term evolution network
US10952176B2 (en) * 2017-03-17 2021-03-16 Samsung Electronics Co., Ltd. AF influenced PDU session management and subscription procedures
MX2019012510A (es) * 2017-04-20 2019-12-02 Guangdong Oppo Mobile Telecommunications Corp Ltd Metodo de comunicacion, dispositivo de red de acceso y dispositivo terminal.
US10582432B2 (en) 2017-05-04 2020-03-03 Comcast Cable Communications, Llc Communications for network slicing using resource status information
ES2908270T3 (es) * 2017-05-08 2022-04-28 Huawei Tech Co Ltd Método y dispositivo para movimiento entre sistemas de comunicación
WO2018219352A1 (en) * 2017-06-02 2018-12-06 Fg Innovation Ip Company Limited Methods, devices, and systems for service-driven mobility management
US10708830B2 (en) * 2017-06-06 2020-07-07 Lg Electronics Inc. Method and cell for determining handover of PDU session
KR102224248B1 (ko) * 2017-06-09 2021-03-08 삼성전자주식회사 통신 시스템에서 PDU(Protocol Data Unit) 세션을 설립하는 방법
US11553388B2 (en) * 2017-06-16 2023-01-10 Htc Corporation Device and method of handling mobility between long-term evolution network and fifth generation network
WO2019003106A1 (en) * 2017-06-26 2019-01-03 Telefonaktiebolaget Lm Ericsson (Publ) REFRESHMENT OF A SECURITY CONTEXT FOR A MOBILE DEVICE
CN109429276B (zh) * 2017-06-30 2021-03-30 华为技术有限公司 通信方法及装置
EP3662698B1 (en) 2017-08-02 2023-09-27 Sony Group Corporation Methods and apparatus for supporting integrity protection in handovers
CN115397037A (zh) * 2017-08-11 2022-11-25 北京三星通信技术研究有限公司 建立双连接的方法及装置
CN109392004B (zh) * 2017-08-11 2021-09-21 华为技术有限公司 通信方法、基站、终端设备和系统
US11153813B2 (en) 2017-08-11 2021-10-19 Comcast Cable Communications, Llc Network slice for visited network
US10764789B2 (en) 2017-08-11 2020-09-01 Comcast Cable Communications, Llc Application-initiated network slices in a wireless network
KR102329925B1 (ko) 2017-08-14 2021-11-23 삼성전자 주식회사 4g/5g 동시 등록된 이동 통신 단말을 위한 네트워크 이동시 데이터 동기화 제공 방안
WO2019066692A1 (en) * 2017-09-26 2019-04-04 Telefonaktiebolaget Lm Ericsson (Publ) MANAGING SECURITY CONTEXTS AND PROVIDING KEY DERIVATION DURING INTERCELLULAR TRANSFER IN A WIRELESS COMMUNICATION SYSTEM
WO2019065059A1 (ja) * 2017-09-27 2019-04-04 ソニー株式会社 通信装置、通信方法及びコンピュータプログラム
CN109560952B (zh) * 2017-09-27 2021-04-09 华为技术有限公司 一种网络切片管理方法及设备
CN109729603B (zh) * 2017-10-29 2020-11-10 宏达国际电子股份有限公司 处理无线存取技术的无线承载配置的装置及方法
WO2019098912A1 (en) * 2017-11-17 2019-05-23 Telefonaktiebolaget Lm Ericsson (Publ) Notification control over ran interfaces
US10681593B2 (en) 2017-11-30 2020-06-09 At&T Intellectual Property I, L.P. Session transfer for packet data network connection
CA3026841A1 (en) 2017-12-08 2019-06-08 Comcast Cable Communications, Llc User plane function selection for isolated network slice
US11252628B2 (en) * 2018-01-09 2022-02-15 Htc Corporation Device and method for handling new radio capabilities
KR102492562B1 (ko) * 2018-01-12 2023-01-27 삼성전자주식회사 네트워크 보안을 위한 장치 및 방법
RU2763449C1 (ru) * 2018-06-04 2021-12-29 Телефонактиеболагет Лм Эрикссон (Пабл) Индикатор базовой сети и обработка обеспечения безопасности для передачи обслуживания
US11271846B2 (en) 2018-10-22 2022-03-08 Oracle International Corporation Methods, systems, and computer readable media for locality-based selection and routing of traffic to producer network functions (NFs)
US10778527B2 (en) * 2018-10-31 2020-09-15 Oracle International Corporation Methods, systems, and computer readable media for providing a service proxy function in a telecommunications network core using a service-based architecture
US10999447B2 (en) * 2018-11-02 2021-05-04 Ofinno, Llc Charging control in roaming scenario
US11057811B2 (en) * 2018-12-14 2021-07-06 T-Mobile Usa, Inc. Bearer selection for dual connectivity cellular systems
WO2020165665A1 (en) * 2019-02-11 2020-08-20 Nokia Technologies Oy Enhanced mobility in cellular deployments with network slicing
US11252093B2 (en) 2019-06-26 2022-02-15 Oracle International Corporation Methods, systems, and computer readable media for policing access point name-aggregate maximum bit rate (APN-AMBR) across packet data network gateway data plane (P-GW DP) worker instances
US10819636B1 (en) 2019-06-26 2020-10-27 Oracle International Corporation Methods, systems, and computer readable media for producer network function (NF) service instance wide egress rate limiting at service communication proxy (SCP)
US11159359B2 (en) 2019-06-26 2021-10-26 Oracle International Corporation Methods, systems, and computer readable media for diameter-peer-wide egress rate limiting at diameter relay agent (DRA)
BR112021026874A2 (pt) * 2019-07-03 2022-02-22 Koninklijke Philips Nv Sistema de comunicação celular e seu método de uso, dispositivo retransmissor, entidade retransmissora de rede e produto de programa de computador
EP3994917A4 (en) * 2019-07-04 2023-01-11 Nokia Technologies Oy PROACTIVE V2X COMMUNICATION SWITCHING FROM SIDE LINK TO CELLULAR CONNECTION
US10833938B1 (en) 2019-07-31 2020-11-10 Oracle International Corporation Methods, systems, and computer readable media for network function (NF) topology synchronization
US11323413B2 (en) 2019-08-29 2022-05-03 Oracle International Corporation Methods, systems, and computer readable media for actively discovering and tracking addresses associated with 4G service endpoints
US11082393B2 (en) 2019-08-29 2021-08-03 Oracle International Corporation Methods, systems, and computer readable media for actively discovering and tracking addresses associated with 5G and non-5G service endpoints
US11018971B2 (en) 2019-10-14 2021-05-25 Oracle International Corporation Methods, systems, and computer readable media for distributing network function (NF) topology information among proxy nodes and for using the NF topology information for inter-proxy node message routing
US11102138B2 (en) 2019-10-14 2021-08-24 Oracle International Corporation Methods, systems, and computer readable media for providing guaranteed traffic bandwidth for services at intermediate proxy nodes
US11425598B2 (en) 2019-10-14 2022-08-23 Oracle International Corporation Methods, systems, and computer readable media for rules-based overload control for 5G servicing
WO2021102841A1 (zh) * 2019-11-28 2021-06-03 华为技术有限公司 一种基于网络切片的数据传输方法、装置和系统
CN111130895B (zh) * 2019-12-27 2022-08-09 天津瑞能电气有限公司 一种基于dsp的ren协议主站实现方法
US11224009B2 (en) 2019-12-30 2022-01-11 Oracle International Corporation Methods, systems, and computer readable media for enabling transport quality of service (QoS) in 5G networks
CN113132142B (zh) * 2019-12-31 2022-08-09 华为技术有限公司 用于获取网络切片标识的方法和装置
US11026149B1 (en) * 2020-01-31 2021-06-01 Dish Wireless Llc Systems and methods for reducing slice access failures
WO2021207932A1 (zh) * 2020-04-14 2021-10-21 华为技术有限公司 数据传输方法及装置
CN111526551B (zh) * 2020-04-17 2022-03-22 维沃移动通信有限公司 一种小区接入方法、设备及系统
US11528334B2 (en) 2020-07-31 2022-12-13 Oracle International Corporation Methods, systems, and computer readable media for preferred network function (NF) location routing using service communications proxy (SCP)
US20220046489A1 (en) * 2020-08-05 2022-02-10 Qualcomm Incorporated Techniques for supporting user plane integrity protection in wireless communications
US11290549B2 (en) 2020-08-24 2022-03-29 Oracle International Corporation Methods, systems, and computer readable media for optimized network function (NF) discovery and routing using service communications proxy (SCP) and NF repository function (NRF)
US11483694B2 (en) 2020-09-01 2022-10-25 Oracle International Corporation Methods, systems, and computer readable media for service communications proxy (SCP)-specific prioritized network function (NF) discovery and routing
US11871285B2 (en) * 2020-09-24 2024-01-09 Electronics And Telecommunications Research Institute Handover processing method based slice and device for performing the method
US11570262B2 (en) 2020-10-28 2023-01-31 Oracle International Corporation Methods, systems, and computer readable media for rank processing for network function selection
CN113068227B (zh) * 2020-11-24 2023-10-27 锐捷网络股份有限公司 一种在5g网络中切换切片的方法和基站
US11470544B2 (en) 2021-01-22 2022-10-11 Oracle International Corporation Methods, systems, and computer readable media for optimized routing of messages relating to existing network function (NF) subscriptions using an intermediate forwarding NF repository function (NRF)
US11496954B2 (en) 2021-03-13 2022-11-08 Oracle International Corporation Methods, systems, and computer readable media for supporting multiple preferred localities for network function (NF) discovery and selection procedures
CN115087071B (zh) * 2021-03-16 2024-01-30 中国联合网络通信集团有限公司 切片管理方法、用户设备及存储介质
US11895080B2 (en) 2021-06-23 2024-02-06 Oracle International Corporation Methods, systems, and computer readable media for resolution of inter-network domain names
WO2022266969A1 (zh) * 2021-06-24 2022-12-29 北京小米移动软件有限公司 一种小区的重选方法及其装置
US11950178B2 (en) 2021-08-03 2024-04-02 Oracle International Corporation Methods, systems, and computer readable media for optimized routing of service based interface (SBI) request messages to remote network function (NF) repository functions using indirect communications via service communication proxy (SCP)
US11849506B2 (en) 2021-10-08 2023-12-19 Oracle International Corporation Methods, systems, and computer readable media for routing inter-public land mobile network (inter-PLMN) messages related to existing subscriptions with network function (NF) repository function (NRF) using security edge protection proxy (SEPP)
US20230115367A1 (en) * 2021-10-08 2023-04-13 Dish Wireless L.L.C. Selective handover of cellular device based on network slicing
US20230171099A1 (en) * 2021-11-27 2023-06-01 Oracle International Corporation Methods, systems, and computer readable media for sharing key identification and public certificate data for access token verification
WO2024033973A1 (ja) * 2022-08-08 2024-02-15 日本電気株式会社 通信装置、通信システム、通信方法およびプログラム

Family Cites Families (68)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN2223669Y (zh) 1995-04-26 1996-04-03 戴姆勒机械制造两合公司 螺旋夹钳
EP1723819B1 (en) 2004-03-11 2019-10-16 Nokia Solutions and Networks GmbH & Co. KG A method of packet switched handover
KR101042763B1 (ko) 2005-07-07 2011-06-20 삼성전자주식회사 이기종 시스템 간의 핸드오버 방법 및 장치
US8553643B2 (en) 2005-07-19 2013-10-08 Qualcomm Incorporated Inter-system handover using legacy interface
JP4790438B2 (ja) 2006-02-07 2011-10-12 株式会社エヌ・ティ・ティ・ドコモ パケット多重伝送方法
CN101052208B (zh) * 2006-04-06 2010-10-20 华为技术有限公司 一种切换方法及切换网络
JP4848890B2 (ja) 2006-08-23 2011-12-28 日本電気株式会社 移動通信システム及びその方法並びにそれに用いる基地局
GB0707387D0 (en) 2007-04-17 2007-05-23 Lucent Technologies Inc Single radio VCC:LTE-VMSC anchor solution
WO2009087443A2 (en) * 2007-07-13 2009-07-16 Nortel Networks Limited Quality of service control in multiple hop wireless communication environments
CN101635968A (zh) 2008-07-22 2010-01-27 株式会社Ntt都科摩 切换处理方法、基站及网络通信系统
CN101841824A (zh) * 2009-03-17 2010-09-22 大唐移动通信设备有限公司 一种实现小区切换的方法、系统和中继设备
CN102104927B (zh) 2009-12-21 2014-12-10 中兴通讯股份有限公司 一种对终端进行接入控制的系统及方法
CN102893548B (zh) 2010-04-01 2016-02-24 瑞典爱立信有限公司 用于控制传输载波去激活的方法和设备
CN102215537B (zh) 2010-04-09 2014-06-04 华为技术有限公司 一种切换方法、基站和家庭网关
CN102340772B (zh) 2010-07-15 2014-04-16 华为技术有限公司 切换过程中的安全处理方法、装置和系统
CN102223669B (zh) 2011-06-24 2018-06-12 中兴通讯股份有限公司 创建数据反传通道和分配互联网协议的方法及系统
WO2013033883A1 (zh) 2011-09-05 2013-03-14 华为技术有限公司 处理切换的方法、移动性管理网元、无线接入网元和系统
KR20140132747A (ko) 2012-02-29 2014-11-18 텔레호낙티에볼라게트 엘엠 에릭슨(피유비엘) 공유 네트워크 노드를 위한 회선 교환 호 폴백(ｃｓｆｂ) 서비스 향상 방법 및 장치
EP2645754B1 (en) 2012-03-29 2015-02-25 Mitsubishi Electric R&D Centre Europe B.V. Trust based system and method for performing a handover from a source base station to a target base station
JP5561499B2 (ja) 2012-07-03 2014-07-30 日本電気株式会社 無線通信システムおよびその通信方法
US9578557B2 (en) * 2012-07-06 2017-02-21 Telefonaktiebolaget Lm Ericsson (Publ) Delayed handover signalling in a mobile network
WO2014019123A1 (zh) 2012-07-30 2014-02-06 华为技术有限公司 一种无线接入技术间切换方法、相应设备及通信系统
WO2014022970A1 (zh) 2012-08-07 2014-02-13 华为技术有限公司 切换处理方法及基站
WO2014092626A1 (en) 2012-12-14 2014-06-19 Telefonaktiebolaget L M Ericsson (Publ) Node apparatus and method for establishing auxiliary bearers
US20160057783A1 (en) * 2013-03-26 2016-02-25 Nokia Solutions And Networks Oy Mechanism for Providing Communication Resources for Random Access of a User
WO2014161161A1 (zh) * 2013-04-02 2014-10-09 华为技术有限公司 不同无线接入网的切换方法及装置、系统
US10045384B2 (en) 2013-08-23 2018-08-07 Lg Electronics Inc. Method for managing link failure of user equipment simultaneously connected to multiple rats and device for performing same
WO2015057723A1 (en) 2013-10-14 2015-04-23 Futurewei Technologies, Inc. A method, apparatus and system for implementing pdn connections
US20150229491A1 (en) 2013-12-20 2015-08-13 Dmitry Solovyev Cost-Effective Core System for Mobile Networking
CN111182600B (zh) 2014-01-28 2021-09-07 北京三星通信技术研究有限公司 在无线通信系统中支持ue移动的方法及装置
KR102143792B1 (ko) 2014-01-29 2020-08-12 삼성전자주식회사 단말의 이동성을 보장하면서 효율적으로 세션을 관리하기 위한 방법 및 장치
BR112016015479B1 (pt) 2014-02-06 2022-10-18 Telefonaktiebolaget Lm Ericsson (Publ) Método executado por um ponto de acesso, método executado por um nó de rede de linha de fio, ponto de acesso, nó de rede de linha de fio, meios de armazenamento legíveis por computador e portadoras
US10237791B2 (en) 2014-03-27 2019-03-19 Acer Incorporated Method of updating network detection and selection information and traffic routing information
EP3132622B1 (en) 2014-04-15 2019-09-25 Nokia Solutions and Networks Oy Interworking with bearer-based system
ES2894736T3 (es) 2014-04-23 2022-02-15 Koninklijke Kpn Nv Transferencia vertical mejorada
WO2015169387A1 (en) 2014-05-09 2015-11-12 Nokia Solutions And Networks Oy Handover of machine type communication device to network supporting limited user apparatus capability
CN105376811B (zh) 2014-08-25 2019-03-15 中国电信股份有限公司 在软件化移动网络架构下实现切换的方法和系统
EP3241385B1 (en) 2014-12-30 2019-08-21 LG Electronics Inc. Method for performing inter-menb handover without senb change in wireless communication system
JP6262917B2 (ja) 2015-04-10 2018-01-17 京セラ株式会社 ハンドオーバ手順を制御するための方法及び基地局
US20160353367A1 (en) 2015-06-01 2016-12-01 Huawei Technologies Co., Ltd. System and Method for Virtualized Functions in Control and Data Planes
BR112017023037A2 (pt) * 2015-06-01 2018-07-03 Huawei Tech Co Ltd aparelho e método para funções virtualizadas em planos de controle e de dados.
US10644955B2 (en) 2015-08-21 2020-05-05 Huawei Technologies Co., Ltd. Method and apparatus for network slicing
US10616820B2 (en) * 2015-08-25 2020-04-07 Lg Electronics Inc. Base station connecting method and user equipment performing same
US9775045B2 (en) 2015-09-11 2017-09-26 Intel IP Corporation Slicing architecture for wireless communication
US10506489B2 (en) * 2015-09-18 2019-12-10 Huawei Technologies Co., Ltd. System and methods for network slice reselection
US10536946B2 (en) * 2015-12-08 2020-01-14 Huawei Technologies Co., Ltd. Method and system for performing network slicing in a radio access network
US10772101B2 (en) * 2015-12-08 2020-09-08 Huawei Technologies Co., Ltd. Systems and methods for determining air interface configuration
US10979998B2 (en) 2016-02-05 2021-04-13 Telefonaktiebolaget Lm Ericsson (Publ) Radio network node, communication device and methods performed therein
US10257078B2 (en) * 2016-04-01 2019-04-09 Qualcomm Incorporated Interworking with legacy radio access technologies for connectivity to next generation core network
WO2017171598A1 (en) * 2016-04-01 2017-10-05 Telefonaktiebolaget Lm Ericsson (Publ) Handover in a wireless communication network with network slices
US10277515B2 (en) * 2016-04-04 2019-04-30 Qualcomm Incorporated Quality of service (QOS) management in wireless networks
JP2019096918A (ja) 2016-04-05 2019-06-20 シャープ株式会社 端末装置、基地局装置、ＭＭＥ（Ｍｏｂｉｌｉｔｙ Ｍａｎａｇｅｍｅｎｔ Ｅｎｔｉｔｙ）および通信制御方法
WO2017177364A1 (en) * 2016-04-11 2017-10-19 Telefonaktiebolaget Lm Ericsson (Publ) Method and apparatus for communication over network slices in wireless communication systems
JP6426648B2 (ja) 2016-04-12 2018-11-21 株式会社Ｎｔｔドコモ 動画像予測復号方法及び動画像予測復号装置
US10028128B2 (en) 2016-04-29 2018-07-17 Motorola Mobility Llc Procedures to support network slicing in a wireless communication system
EP3456080A1 (en) 2016-05-10 2019-03-20 Netsia, Inc. System and method for communication between programmable base stations and software-defined radio access network controllers
CN110995773B (zh) 2016-05-24 2021-01-05 华为技术有限公司 QoS控制方法及设备
US9967801B2 (en) 2016-06-10 2018-05-08 Lg Electronics Inc. Method and apparatus for receiving authorization information on network slice
CN109644089B (zh) 2016-06-15 2022-04-26 康维达无线有限责任公司 用于新无线电的无许可上行链路传输
CN113613293B (zh) * 2016-07-01 2024-04-16 交互数字专利控股公司 用于在wtru中所使用的方法及wtru
TWI651950B (zh) * 2016-07-07 2019-02-21 財團法人工業技術研究院 無線接取網路之服務區分方法、無線網路系統及無線接取網路存取點
EP3488632A1 (en) 2016-07-22 2019-05-29 Nokia Technologies Oy Security handling for network slices in cellular networks
US10805168B2 (en) * 2016-07-29 2020-10-13 Lg Electronics Inc. Method and apparatus for performing cell specific procedure or mobility procedure for network slice-based NR in wireless communication system
JP6724232B2 (ja) * 2016-07-29 2020-07-15 エルジー エレクトロニクス インコーポレイティド 無線通信システムにおけるネットワークスライスベースのｎｒのためのセル特定手順を実行する方法及び装置
CN109565729B (zh) * 2016-08-08 2021-02-02 诺基亚技术有限公司 用于5g与lte之间的移动性的端标记处理
CN113676972A (zh) 2016-08-10 2021-11-19 日本电气株式会社 无线接入网节点及其方法
EP3499964B1 (en) 2016-08-10 2021-06-23 Nec Corporation Radio access network node, wireless terminal, core network node, and methods for these
WO2018034042A1 (ja) * 2016-08-17 2018-02-22 株式会社Ｎｔｔドコモ 通信制御装置及び通信制御方法

Non-Patent Citations (4)

* Cited by examiner, † Cited by third party
Title
CATT: "Control plane for support of NR standalone operation", 3GPP TSG-RAN WG2#94 R2- 163468, 14 May 2016 (2016-05-14), XP051095423 *
CHINA MOBILE ET AL.: "Network Slicing Architecture and High-Level Function Definition", 3GPP TSG-SA WG2#115, S2-162365, 17 May 2016 (2016-05-17), XP051115926 *
ETRI: "High-level Functional Architecture for the Network Slicing", 3GPP TSG-SA WG2#114, S2-161833, 6 April 2016 (2016-04-06), XP051086821 *
SAMSUNG: "Assignment of CP and UP network functions during an MM procedure", 3GPP TSG-SA WG2#116, S2-163297, 5 July 2016 (2016-07-05), XP051121041 *

Cited By (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10959133B2 (en) 2016-08-12 2021-03-23 China Academy Of Telecommunications Technology Method and device for processing quality of service parameter in handover scenario
JPWO2018131414A1 (ja) * 2017-01-10 2019-11-07 株式会社Ｎｔｔドコモ 通信制御装置及び通信制御方法
JP7034098B2 (ja) 2017-01-10 2022-03-11 株式会社Ｎｔｔドコモ 通信制御装置及び通信制御方法
JPWO2019064383A1 (ja) * 2017-09-27 2020-10-22 富士通株式会社 基地局装置、端末装置、無線通信システム、及び無線通信方法
CN110278591B (zh) * 2018-03-14 2021-10-12 中兴通讯股份有限公司 地址协同方法、装置、基站、smf网元及存储介质
US11968576B2 (en) 2018-03-14 2024-04-23 Zte Corporation Address coordination method, device, base station, SMF network element and storage medium
US11595867B2 (en) 2018-03-14 2023-02-28 Zte Corporation Address coordination method, device, base station, SMF network element and storage medium
CN110278591A (zh) * 2018-03-14 2019-09-24 中兴通讯股份有限公司 地址协同方法、装置、基站、smf网元及存储介质
JP2021525978A (ja) * 2018-05-31 2021-09-27 オッポ広東移動通信有限公司Ｇｕａｎｇｄｏｎｇ Ｏｐｐｏ Ｍｏｂｉｌｅ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ｃｏｒｐ．， Ｌｔｄ． 端末機能取得方法および装置、コンピュータ記憶媒体
JP7317865B2 (ja) 2018-05-31 2023-07-31 オッポ広東移動通信有限公司 端末機能取得方法および装置、コンピュータ記憶媒体
EP3787342A4 (en) * 2018-06-22 2021-09-29 Huawei Technologies Co., Ltd. COMMUNICATION PROCEDURE AND RADIO CALL PROCEDURE, DEVICE AND SYSTEM
US10575230B2 (en) 2018-07-20 2020-02-25 Google Llc Network slicing for WLAN
US11737003B2 (en) 2018-07-20 2023-08-22 Google Llc Network slicing for WLAN
WO2020018444A1 (en) * 2018-07-20 2020-01-23 Google Llc Network slicing for wlan

Also Published As

Publication number Publication date
JP7088342B2 (ja) 2022-06-21
US20210352549A1 (en) 2021-11-11
CN114025395A (zh) 2022-02-08
EP3499964B1 (en) 2021-06-23
CN109565732A (zh) 2019-04-02
EP3499964A4 (en) 2019-08-14
JP2021073832A (ja) 2021-05-13
EP3796713A1 (en) 2021-03-24
JP6844679B2 (ja) 2021-03-17
CN114040456A (zh) 2022-02-11
US11910258B2 (en) 2024-02-20
US11765636B2 (en) 2023-09-19
JP2023129544A (ja) 2023-09-14
US20190191348A1 (en) 2019-06-20
JP6642720B2 (ja) 2020-02-12
CN114040455A (zh) 2022-02-11
EP3499964A1 (en) 2019-06-19
US20230370928A1 (en) 2023-11-16
CN109565732B (zh) 2021-10-22
JP2022120001A (ja) 2022-08-17
EP3958615A1 (en) 2022-02-23
JPWO2018029931A1 (ja) 2019-06-06
JP7327588B2 (ja) 2023-08-16
JP2020039182A (ja) 2020-03-12

Similar Documents

Publication Publication Date Title
JP6844679B2 (ja) 無線アクセスネットワークノード、無線端末、及び方法
JP7359231B2 (ja) ターゲット無線アクセスネットワークノード及びその方法
JP7036268B2 (ja) ターゲット無線アクセスネットワークノード、５ｇコアネットワークノード、及びこれらの方法
WO2018029932A1 (ja) 無線アクセスネットワークノード、無線端末、及びこれらの方法

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 17839006

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2018533427

Country of ref document: JP

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 2017839006

Country of ref document: EP

Effective date: 20190311